A Debian Squeeze reference root filesystem is now available on the downloads page. This image has been put together by Gray and Dom and contains LXDE, Midori, development tools and example source code for multimedia functions.

This disc image is not the one we expect people to be using as standard (that’s from Fedora, and has some other exciting stuff bundled with it, which we hope to be putting up over the next few days). This is the file system that the Cambridge Raspberry Pi staff have been using for demos, testing, providing to with alpha boards to third-party developers and so on.

I found one gdiskdump, I got a deb file i downloaded. It should be good for us terminal challenged In the Cyberland. I'm getting better with the cl but, I always get mixed up on my syntax! The memory isn't what it was

I loaded Fedora 14 on a Vitrual machine. I put the unzipped img file in Documents, opened a terminal window typed cd Documents (enter) then typed su (enter) and put in my password (you won't see the password or any "*" or anything) and press enter again. Then type:

sudo dd if=debian6-17-02-2012.img of=/dev/sdb bs=1M

Press enter.

(credit Carlos on February 17, 2012 at 11:08 pm)

I had to wait about 5 minutes (maybe longer - no feedback) before the cursor came back. You will have to eject the SD card and reinsert it and it should look something like this:

I'm assuming that as you are loading a virtual Linux system and then using that to copy the image to an SD card, you are probably using Windows. There is a WinDD equivalent so really don't need to go through all the Fedora virtual machine stuff.

I have been using .deb based systems for too long to be bothered changing to Fedora I think. Considering the scale or the Raspberry Pi launch is there any chance Debian might be recompiled with hardfloat or Canonical might be convinced to build an ARMv6 target?

[EDIT: I just read a bit of background on Canonical's lack of helpfulness and I am starting to think they have lost the plot completely. I withdraw that suggestion.]

I have been using .deb based systems for too long to be bothered changing to Fedora I think.

I feel the same way as you. If I had my Druthers, Ubuntu would be the premier distro of the RPi, but failing that, I would want Debian as the "runner up", not Fedora. I started with Redhat 4.1 way back in the day, but once I moved from Redhat to Debian a few years later, and beheld the power of APT, there was no going back (to an RPM-based distro).

Considering the scale or the Raspberry Pi launch is there any chance Debian might be recompiled with hardfloat or Canonical might be convinced to build an ARMv6 target?

Surely there is a chance.

I know this is some Pi-in-the-Sky dreaming, but I hope some Debian-friendly philanthropist (other than Mark Shuttleworth) out there (or Debian-friendly software consultancy looking to do some "sponsoring" for the sake of some awesome, inexpensive PR) with, say, $700ish to invest (and some SysAdmin skills) builds a cluster of, say, 10 Raspberry Pi's, then politely invites key Debian ARM porting developers (like, say Riku Voipio, Martin Michlmayr, and/or Aurelien Jarno from Debian) to remotely log into said cluster to possibly do the building of all the Debian package repositories for ARMv6.

I mean come on, doesn't anyone want to be the first to brag about having the "Cheapest Debian Cluster Ever"? Think of it: a whole cluster for the price of one half-decent PC! Never mind the millions that Mark Shuttleworth invested, this is some serious bang for the buck. I think this would generate some serious geek "street cred".

Can anyone speak to just how much real-world performance is actually lost due to Debian not being natively compiled for ARMv6 (like the Fedora remix is?)

Aargh. From a bit of reading at Debian''s website, it looks like it could be quite a bad performance loss (at least whenever one is doing anything that heavily relies on floating point operations):

"Genesi USA, Inc. did a proof-of-concept rebuild of Ubuntu karmic (9.10)'s armel port with the hard-floating. They noticed important wins (in the order of 40% performance improvement) in floating-point heavy applications/libraries such as mesa, with a Cortex-A8 CPU."

Note: The Cortex-A8 mentioned above is ARMv7, whereas the Raspberry Pi is only ARMv6. So that''s not an apples-to-apples comparison. I''m still awaiting to see a fair comparison of hardfloat-vs-no-hardfloat on the Raspberry Pi's ARMv6.

So what hope is there of Debian officially compiling hardfloat support for the RasPi?

It would seem none, at the moment. Maybe we should all petition them to include it? We''d have to act fast, before Debian's upcoming freeze occurs "sometime in the middle of 2012".

The current situation seems to go something like this: Even though the Raspberry Pi''s ARMv6 processor has "hardware floating point" (the CPU feature is called "VFP"), Debian''s current, official "ARM EABI" port (for Debian 6) unfortunately does not compile support for VFP in!

In other words, once all the new Rasberry Pi users install Debian for the first time, as it currently stands, they might be disappointed to discover that their floating point hardware functionality just sits there, affectively unusable. All floating point operations (think "Multimedia") will instead be done using software-based emulation, incurring a substantial loss in performance. Am I right on this?

To make matters worse, Debian is cooking up a new official port for the ARM, called "ArmHardFloatPoint", which they hope to officially include in Debian 7. But it will only cover ARMv7 (which have VFP), and above (think BeagleBone). So, as it stands, the Raspberry Pi will "miss the boat," since it's only ARMv6.

Failing convincing Debian to officially include support for the Raspberry Pi's hardware floating point in Debian 7, the only other option will be to make an "unofficial" port (akin to how there is a "Remix" of Fedora for the Raspberry Pi. This would necessitate a group of avid Raspberry Pi fans making (or getting access to) their own build cluster (like Seneca College did), and rebuilding all the Debian packages, compiling for the ARMv6 with hardware float support. Then they would also have to make their own package repositories, security update packages (in a timely, consistent manner), website, etc. That might be a lot of work!

Any corrections or additions to the above would be most appreciated.

In summary: perhaps I''ll just think twice about using some different compile-optimized distro on the Raspberry Pi, after all. I''m starting to warm up to Puppy, since it's been painstakingly designed specifically to run nicely in 256 MB RAM (for a long time now).

FYI, I did already establish that the performance impact of softfloat/softfp/hardfloat is broadly comparable between ARMv7 and ARMv6. Whichever CPU you use, it's a *big* difference if you have an FP-heavy workload.

Specifically, I developed a tiny benchmark using my TrimSlice (ARMv7) and measured a big difference there. I then managed to get someone with a beta board to run it, and they got numbers that were entirely consistent with my expectations.

This led fairly directly to the Gentoo hardfloat thread further down this section of the forum. It also convinced Broadcom to release a hardfloat version of the GPU interface libraries, which are needed for compatibility with a hardfloat distro and which should benefit in terms of performance too.

The numbers:

- Expect a tenfold improvement in FP performance for moving away from softfloat (to softfp or hardfloat) on a VFP-equipped CPU.

- Expect a threefold reduction in function call overhead for functions with floating-point arguments and/or return values, when moving from softfp to hardfloat.

- For a trivial function that computes a dot-product between two 2 vectors, total performance was roughly doubled when moving from softfp to hardfloat.

Inlining gave even more performance, mostly because some of the calculation could be hoisted out of the innermost loop, but that was actually a smaller effect. The raw function-call overhead in the hardfloat case was simply the BX LR instruction to return with.

Good news for Debian fans: It would seem that the Debian ARM porters are now actively discussing (on the "Debian port to ARM" mailing list) how to go about making some kind official Debian port for the Raspberry Pi. Unfortunately, as of yet, none of them have any Raspberry Pi hardware (or remote login access to any). Hint: Anyone wanting to help them out by allowing them the use of their Raspberry Pi for compiling packages would probably be helpful and appreciated!