HISTORY: The start of raspbian (Debian Hard Float (armhf) for RPi)

[emy84]

Hello,

I've read this (entire) post, but i haven't undestood what is armhf. Is this a special set of instructions needed by compilers with FPU support?

Sorry for this "newbie" post.....

[plugwash]

Fundamentally It's a C ABI.

Debian armel uses the "EABI baseline" C ABI (which passes floating point values in integer registers) and uses software floating point. You can build code compatible with debian armel and that use hardware floating point instructions (gcc options "-mfpu=vfp -mfloat-abi=softvfp"), however while certainly an improvement over the defaults this is less than ideal for two reasons, firstly because to remain compatible the compiler has to move floating point values between integer registers and floating point ones for correct parameter passing and secondly because the system libraries are still using software floating point.

Debian armhf uses the "EABI vfp hardfloat" C ABI (which passes floating point values in vfp registers) and the system libaries use hardware floating point. However it can't run on a Pi because it's minimum CPU requirements are set too high (armv7-a, thumb2, vfpv3_d16).

Raspbian armhf uses the "EABI vfp hardfloat" C ABI and is built with compile options that mean it can run on the Pi. Raspbian armhf binaries/librararies can be mixed with debian armhf binaries/libraries but obviously such a mixed system can't run on a Pi. So we have to recompile everything.

[emy84]

Thank you for your explanations.

It's a very interesting project. I'll follow it.... And i'll try to understand something more....

Thank you very much

[mdewey]

Dear emy84,
Did you know there is a project page?
http://www.raspbian.org/
This may help answer some of your questions

Michael

[mpthompson]

OK, back in the saddle again, but exhausted after spending two days in California's gold country as a chaperone with a hundred screaming 10 years olds -- many on their first overnight trip away from their home without their parents. I think we all made it back alive. Whew...

I should be getting some real Raspberry Pi hardware within two days or so from a generous offer from a person living in my neck of the woods. Thank you to everyone for their kind offers over the last few weeks of lending hardware and purchase numbers to help move Raspbian along. According to Element 14 I should be getting my hardware in the next two weeks or so, but I figured I'll take an offer for hardware that is relatively local and doesn't involve international air freight just in case things with Element 14 are delayed.

Thanks to Plugwash's efforts, building has continued to go smoothly for the last two days. About 2500 packages left to go. Things are moving more slowly as we seem to now be hitting the larger applications that take hours or days to build. I'll put a more detailed update this evening.

In addition to trying to push the package build process over the finish line in the coming two weeks, I'll also be trying to revamp the rather simplistic Raspbian website as well as help, where I can, with the people who are working on a Raspbian/Debian installer, packaging the kernel and packaging the Broadcom proprietary libraries. This is where having real Raspberry Pi hardware will be a great help to me.

[mpthompson]

If someone involved with the creation/management of the Raspberry Pi Forums comes across this message, could a specific area for "Raspbian" be created under the "Operating system distributions" area of the Forum? Right now Raspbian posts are being made in the Debian section which is OK, but while Debian and Raspbian are intimately related, they are distinct distributions with Raspbian being a complete rebuild. This could be confusing to new users and there are bound to be Raspbian specific issues and topics in the future that will deserve their own area.

I've tried to send some private messages about this, but I must not be sending them to the right people that can make such a change. Hopefully someone who someone who knows whom to contact will see this help get a Raspbian section created. If Puppy Linux can get their own section, I'm hoping Raspbian can.

[jerry.tk]

I spent a few days experimenting with debian-installer on RasPi. Now when more people are interested in creating Raspbian installer I thought I'd summarize my findings.

1. I wasn't succesful tweaking cmdline.txt to force loading standalone initramfs file (on recompiled kernel with initrd enabled). It has probably something to do with bootloader not supporting loading initrd into memory. Embedding initramfs into kernel works fine as long as it is not compressed.

2. I took versatile board armel netboot installer initrd, unpacked it and embedded into kernel. Armel installer ran just fine using official armel repo and installed Debian was functional.

3. Compiling debian-installer on RasPi didn't work as of yesterday because of some missing udebs.

4. I took armhf efikamx netboot installer image and basically reassembled it using Raspbian udebs (and some debs as well). The installer starts working fine but fails later when installing base system files. See example log here: http://pastebin.com/sbpKtgbe
There are some unmet dependencies when debootstrapping system and I am not sure where to go from here.

I have also uploaded current installer initramfs.cpio here: http://db.tt/VWJCdQGi for interested parties to hack on. It is a bit larger since it contains RasPi firmware binaries (could be probably reduced to bare minimum and updated by rpi-updater after installation).

Jerry

[hexelpdkk]

For kernel packaging, I had considered taking the git source, and adding the debian subdirectory from a standard debian install as a starting point, and then creating the pi specific flavour to build. This would be the most "debian like" package build, but there is a lot of stuff to work through. For example, all the kernel patches are managed in the debian directory.

As an alternative, I'm also taking a look at what package gets built from the clean git source using "make deb-pkg". This might give a simpler path to a usable package.

Any thoughts?

[marsman2020]

4. I took armhf efikamx netboot installer image and basically reassembled it using Raspbian udebs (and some debs as well). The installer starts working fine but fails later when installing base system files. See example log here: http://pastebin.com/sbpKtgbe
There are some unmet dependencies when debootstrapping system and I am not sure where to go from here.

Look an aweful lot like this bug - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515979

Priority of libsigc++-1.2-dev package is "important", but the FTP archive
overrides this to "optional".

The result of this is that unless dak has made its magic, debootstrap will
try to install libsigc++-1.2-dev, and fail because libstdc++-dev is not
present.

[plugwash]

3. Compiling debian-installer on RasPi didn't work as of yesterday because of some missing udebs.

Could you tell us which ones?

4. I took armhf efikamx netboot installer image and basically reassembled it using Raspbian udebs (and some debs as well). The installer starts working fine but fails later when installing base system files. See example log here: http://pastebin.com/sbpKtgbe
There are some unmet dependencies when debootstrapping system and I am not sure where to go from here.

The libsigc++-1.2-dev issue should be fixed now. Please tell us if you still have problems.

[jerry.tk]

3. Compiling debian-installer on RasPi didn't work as of yesterday because of some missing udebs.

Could you tell us which ones?

Sure! I have sent it in PM to Mike the other day but it was probably not so good idea since he was out in the big room with blue ceiling
Anyway:
- netcfg is depending on crypto-modules udeb which seems to be kernel specific.
- util-linux-udeb_xxx_armhf.udeb was missing.
On slightly related note also subversion on Raspbian V3 was failing to download debian-installer sources to RasPi, I had to transfer that from another PC.

4. I took armhf efikamx netboot installer image and basically reassembled it using Raspbian udebs (and some debs as well). The installer starts working fine but fails later when installing base system files. See example log here: http://pastebin.com/sbpKtgbe
There are some unmet dependencies when debootstrapping system and I am not sure where to go from here.

The libsigc++-1.2-dev issue should be fixed now. Please tell us if you still have problems.

Cool, thanks! I will test that today.

[jerry.tk]

Yay! Managed to install Raspbian via netboot installer!

I will work on tweaking installer preseeding now and hopefully I will have some useable installer image soon.

[scep]

If someone involved with the creation/management of the Raspberry Pi Forums comes across this message...

We did find it eventually! Raspbian now has it's own forum

[asb]

Will Thompson has done some work on Debian packaging of the Broadcom libs. It should be a trivial change for armhf:

https://github.com/wjt/firmware/tree/debian

[mkopack]

Hey guys,

I've been giving Raspbian-R3 a go and I keep running into a couple issues I want to share and see if you had some advice.

First off, bear with me, my RPi is at home, I'm at the office, so I'm going off memory here. Sorry if I'm vague or incorrect on specifics.

Also, I'm running in a config where I start the boot off the SD card, and then hand off to an SSD inside a USB enclosure (it actually was cheaper to find a 32GB SSD+USB than a hard drive! Seems like stores only want to sell 500+GB HD these days at $100 a pop!) Not sure if this is causing some of my issues or not. I'm planning to give it another try tonight running totally off the SD card....


I've had the following issues:

1) changing the default keyboard mapping to be US using the dpkg works for console mode, but inside of X it remains the UK layout (which is a bit annoying.

2) I did the install of all the supporting stuff as indicated on the http://www.raspbian.org/HexxehImages page. I then installed midori. When trying to load a page, at random times, the entire system will completely lock up - no response, no mouse, no keyboard, no nothing. I've let it sit there for 10 minutes hoping it was just a pause caused by processing but nope. Had to power cycle.

3) While trying to install some other software, as well as when trying to perform the rpi-update, both from the console (not in X), I've had it where the system just went berzerk, spitting out screen after screen of output, in a repeating pattern, but it was going by so fast I couldn't read any of it, and I couldn't stop it. Again had to power cycle it.


Ideas???

[grumpyoldgit]

I'm just looking at your third issue. My screen has gone completely mad. Scrolling at an amazing speed and cannot read a thing. It is definitely the same pattern repeating itself. I was at tasksel install standard. I had had the silver bar on a blue screen installing software for a long time then the screen went haywire. I will do the command again to see what happens.

[mpthompson]

We did find it eventually! Raspbian now has it's own forum

Thank you, thank you, thank you. We can now stretch out our legs a little.

[plugwash]

2) I did the install of all the supporting stuff as indicated on the http://www.raspbian.org/HexxehImages page. I then installed midori. When trying to load a page, at random times, the entire system will completely lock up - no response, no mouse, no keyboard, no nothing. I've let it sit there for 10 minutes hoping it was just a pause caused by processing but nope. Had to power cycle.

Have you set "vm.min_free_kbytes = 8192" in /etc/sysctl.conf ?

[CargoCult]

I'm just looking at your third issue. My screen has gone completely mad. Scrolling at an amazing speed and cannot read a thing. It is definitely the same pattern repeating itself. I was at tasksel install standard. I had had the silver bar on a blue screen installing software for a long time then the screen went haywire. I will do the command again to see what happens.

I got that as well - adding 'vm.min_free_kbytes = 8192' to /etc/sysctl.conf and rebooting seemed to fix that.

Possibly of note, I saw that hexxeh's Raspbian image has the ARM set to overclock to 800MHz by default, in /boot/config.txt. While mine seems stable at that frequency (I managed to compile a tubocharged Quake 3 last night) I initially wondered if it was the cause of the rampant error-scrolling. Possibly not, however.

[mkopack]

Nope, didn't bother because it seemed to work fine (although I'm such a Linux newb I probably wouldn't know the diff if it had failed!)

I'm also wondering if it was an issue with the SSD because I only had the 1 USB jack plugged into the powered Hub vs both the Data+aux power USB plugs. Was going to try that when I get home tonight.

However, if others are seeing this issue, then that might be a red herring.

I also suspect #2+#3 are the same issue, just that I'm not seeing the console output in #2 because I'm inside X at the time.

[mpthompson]

Ideas???

Unfortunately, I don't have Raspberry Pi hardware yet to look into these issues, but with CargoCult's help I should be getting my hands one within the next two days. In the meantime I hope others that already have hardware can help give you suggestions to overcome these issues.

Often, when trying to track down these problems it's best to log in with ssh from a client such as Putty where you can capture and copy the fault information as it scrolls by. A look at the errors messages will help go a long ways to figuring out what makes the Pi so unhappy when installing new packages.

[mkopack]

Ok, I'll try taking out the OC and putting in that line when I get home... Thanks for the suggestions guys!

[mkopack]

Ideas???

Unfortunately, I don't have Raspberry Pi hardware yet to look into these issues, but with CargoCult's help I should be getting my hands one within the next two days. In the meantime I hope others that already have hardware can help give you suggestions to overcome these issues.

Often, when trying to track down these problems it's best to log in with ssh from a client such as Putty where you can capture and copy the fault information as it scrolls by. A look at the errors messages will help go a long ways to figuring out what makes the Pi so unhappy when installing new packages.

Actually, the last time it happened before I gave up last night, was while I was trying to do the Apt-get install to install the packages needed for installing ROS. I was doing that via SSH into the RPi and the output came up on the RPi's console (which I had up on my other monitor) NOT on the SSH connection, so I couldn't have captured it.

[mpthompson]

Actually, the last time it happened before I gave up last night, was while I was trying to do the Apt-get install to install the packages needed for installing ROS. I was doing that via SSH into the RPi and the output came up on the RPi's console (which I had up on my other monitor) NOT on the SSH connection, so I couldn't have captured it.

I see. I'll see what I can find out about diverting system console information to an ssh connection to aid in diagnosing these types of issues. It can be very frustrating to see such information scroll by too fast to figure out what the heck it's doing. Perhaps someone knows this offhand.

Also, I'll start a troubleshooting section on the wiki where we can keep track of solutions to these problems so that someone doesn't have to look through forum threads for some of the issues that have already been solved.

Is "vm.min_free_kbytes = 8192" in /etc/sysctl.conf the confirmed solution for the scrolling error message problem when using tasksel or apt-get?

[grumpyoldgit]

I'm just looking at your third issue. My screen has gone completely mad. Scrolling at an amazing speed and cannot read a thing. It is definitely the same pattern repeating itself. I was at tasksel install standard. I had had the silver bar on a blue screen installing software for a long time then the screen went haywire. I will do the command again to see what happens.

Attempting to restart resulted in tasksel: apptitude failed (255)
apt-get update resulted in dpkg was interrupted, you must manually run dpkg --configure -a
dpkg --configure -a gave me update-alternatives: warning: forcing reinstallation of alternative /usr/bin/aptitude-curses because link group aptitude is broken
apt-get update then ran through OK
tasksel install standard then ran through OK but a number of mmc0 and mmcblk0 messages were superimposed on the screen during the installation.
I am now continuing with the list of commands.

I have noticed long pauses at commands that relate to usb. On the rpi-update, for example, it pauses at usb 1-1.3: reset low speed USB device number 4 using dwc_otg.
After a couple of minutes or so, it then continues.
Also noticed that rpi-update has completed but the last line of output is

Code: Select all

cp: cannot create regular file ' /opt/vc/sbin/vcfiled': text file is busy