Mark, Once you put the image onto an SD card, there is a boot partition that you can access from Linux and Windows. You can modify the kernel commandline for example there.
Also you have simple files that form the "Linux kernel". You can manipulate those with all the tools you have for manipulating files. copy move rename, whatever.
The one you want to change is "kernel.img".
There are more elaborate instructions around for building your own kernel for raspberry pi than my concise version above. Search for "raspberry pi compile kernel git" or something like that.
I googled it for you. Instructions are here.
Thanks Roger, but I tried this from Windows already. First I downloaded the latest kernel.img straight from the firmware gitrepo into the boot partition, but after that the RPi was worse and provided no video output at all. Then I tried downloading all the contents of the firmware directory from the gitrepo and copying into the boot partition, same result.
...suggests that the Python script imagetool-uncompressed.py needs to me used at some stage during the building of kernel.img, and I don't know whether the version in the gitrepo has this done.
...also says I need to copy the image file into /lib/modules which is not accessible from Windows. I wonder if I can access /lib/modules if I connected the SD card via a USB card reader to a Linux host?
Chris, good suggestion, but alas I've exhausted that option already!
Mind you, a helpful chap called Tim says he's solved the problem with the same SDHC that I have. I've asked him how he updated the firmware on his card, because the steps I think I should take didn't work for me. We'll see if I get a response to that.
Ok, I have got it working on Arch Linux and Debian. So I can confirm that the SanDisk Extreme Pro 16GB SDHC (class 10 card) can be made to work. Here is how I did it:
1) I wrote the Arch Linux image to the SD card from Windows using Win32DiskImager. I could have done this with dd in Linux just the same. Then safely eject the drives.
2) I downloaded the latest firmware from github as a ZIP file: https://github.com/raspberrypi/firmware/zipball/master and unzipped it.
3) I connected the SD card via my USB card reader to my Red Hat Linux VM. This mounted /media/disk and /media/disk-1.
4) I copied the necessary files across from the new firmware location:
# cd <top_level_firmware_source>
# cp boot/*.bin boot/*.elf boot/*.img /media/disk/.
# cp /media/disk/arm192_start.elf /media/disk/start.elf
# cp -R modules/* /media/disk-1/lib/modules/.
5) Safely unmount the media, plug into RPi and power on.
As a bonus, the latest firmware also fixed the problem I had with regards the display originally being too wide for my widescreen TV. So all is now well with the world ... I hope these instructions may be of help to someone else.
Wow! that's fantastic that you got it working.
I think the conventional wisdom was betting against you.
For example, in this thread:
one poster on May 11 at 9:31am says:
"There is already a posting from a chap who can’t get his Pi to boot but wants to upgrade the firmware."
and at 9:49 he says:
"If a card won’t work in the Pi how would you get the new firmware on it. A sort of Catch 22!"
The next step may be to do some benchmarking to see if
the RPi is taking any advantage of the class 10 speed.
There are some existing benchmarks at:
by the way, for anyone else trying to debug their RPi,
the conventional wisdom is to start with a minimal configuration,
preferably a working configuration, and add one thing at a time.
Sort of like playing mastermind, where you get yourself really
confused if you change multiple pegs in your guess.
Following that strategy, you would first want to know that your RPi
worked with a verified SD card, then you would want to know that
the procedure for updating to the latest firmware worked with that
same SD card, and then you would try your class 10 card with the
known working latest firmware.
I need to take advantage of the latest SD driver code submitted to the RPi firmware:
I'm hoping it will help me get my particular SD card to work.
I was using debian6-13-04-2012 and the win32diskimager.
Does anyone know how debian6-13-04-2012.img was built, and how I go about modifying it (or rebuilding it) with the latest firmware?