Loading test-kernel fails on Raspberry Pi 1 Model B
thrimbor opened this issue · comments
I tried using rpi-boot with the test-kernel on my Pi, but it fails with the following error:
Welcome to Rpi bootloader
Compiled on Jun 26 2013 at 14:45:19
ARM system type is c42
EMMC: vendor 99, sdversion 2, slot_status 0
SD: found a valid version 3.0x SD card
MBR: found valid MBR on device emmc0
FAT: volume label:
FAT: found a FAT32 filesystem on emmc0_0
EXT2: found an ext2 filesystem on emmc0_1
MBR: found total of 2 partition(s)
MAIN: device list: emmc0_1(ext2) emmc0_0(FAT32)
MAIN: Found bootloader configuration: /boot/rpi-boot.cfg
MULTIBOOT: unable to allocate a chunk between 0x00100000 and 0x001004b0 for section 1
cfg_parse: multiboot failed with -1
I tried both my self-built version (current master) and the precompiled version from the link you posted on osdev.org (http://www.johncronin.org.uk/rpi-boot-latest.tar.bz2).
The SD card used is a 4GB SanDisk Class 4, which has proven to be stable in combination with the Pi in the past. Before copying the files onto the card, I flashed a 2016-05-27-raspbian-jessie-lite image to it.
I also tried using an original raspbian image, but then rpi-boot couldn't find it's config file, maybe it has something to do with the boot partition being FAT16 on this image, while it's FAT32 on the lite-image.
Ok, I took some more time looking into this, and it seems that at least the multiboot problem isn't rpi-boots' fault. I uploaded the debug log here, and after playing with the sourcecode a bit it seems that rpi-boot can't allocate a chunk because there are no memory-ATAGs. I decided to try out older firmware files for the Pi, and indeed, the firmware files from about the mid of 2013 make it all work, I uploaded the log (with ATAG_DEBUG enabled) here.
However, I have not enough knowledge about this to have an idea about the exact cause.
Hi, thanks for looking into this a bit. It seems like the rpi firmware has recently changed to not using ATAGs but rather the device tree database by default. There appears to be a script in the rpi linux source (https://raw.githubusercontent.com/raspberrypi/linux/rpi-4.4.y/scripts/mkknlimg) which adds a trailer to the end of the rpi-boot binary image that causes the firmware to revert to the old ATAG behaviour. You can save it to the rpi-boot source directory and run ./mkknlimg kernel.img kernel.img after it has finished compiling and then try that version. It dumps something about 'is this a valid kernel?' but still seems to add the appropriate trailer. I'd appreciate if you could feed back if this is successful as I don't have an rpi here to test at the moment. Thanks.
Hi,
I tried the script, but the resulting kernel.img still wouldn't work with the newer firmware files. If I don't use the script, rpi-boot seems to get nonsense-ATAGs, if I use the script, the ATAG-pointer is zero.
I also found this mailing list post which seems to indicate that removing the dtb-files makes the bootloader fall back to ATAGs, but that didn't work either, the ATAG-pointer still was zero.
However, I read that the ATAGs normally reside at 0x100, so I inserted a "atags = 0x100;" in main.c and to my surprise it did work! So the ATAGs are there, but from what I read about device trees, r2 contains a pointer to the device tree, so that's why I get these "Unknown ATAG" warnings.
I'm afraid that, in the end, there might be no way around device tree support, but I'm not even sure how one would detect whether the firmware is using the device tree or ATAGs.
Just to confirm, with the new firmware, and the patched kernel.img, r2 (i.e. the atags parameter passed to main()) is zero but the atags reside at 0x100? In which case I suppose a temporary hack is: if(atags == 0) atags=0x100; But you're right, at some point device tree needs to be implemented (also for rpi2 support as mentioned in another issue here).
Yes, exactly.
Now that my Pi runs again, I tried exactly that. I formatted the first partition on the SD card, copied the files from the 2016-05-27-raspbian-jessie image onto it, added "if(atags == 0) atags = 0x100;" to rpi-boots' main, built it, ran mkknlimg over the resulting kernel.img, copied it onto the card together with the config and test-kernel, and after putting it into the Pi it ran absolutely fine.
Unfortunately, it didn't work out of the box with a raspbian image, because rpi-boot can't find its config file on the FAT16 partition.
Thanks. I have pushed the relevant changes to the repository. I've had reports of fat16 not working properly before but haven't been able to replicate it. I'll look into it a bit further.
I've just pushed full device tree support so that now the addresses for devices come from there if available. Tested with the raspi2 emulation in qemu and a physical rpiv1 I have here. Unfortunately I'm unable to replicate fat16 issues here. Could you provide any further info?
Amazing! Works fine on my Pi.
Concerning the FAT16 problem:
I managed to track it down. My assumption was that FAT16 causes it because the raspbian images use FAT16 and wouldn't work, and the problem vanished when reformatting the partition as FAT32. But I didn't notice that another detail changed when reformatting: The volume label.
The raspbian images use the volume label "boot" for the FAT-partition, which is the same name as the directory containing the config file. fat_read_dir doesn't check for the volume-label bit, so fat_read_directory gets two entries named boot: The directory, and the volume label. But because it sees the volume label first (and of course the volume label didn't have the directory bit set) it returns with an ENOTDIR.
Long story short, adding a simple "if(buf[ptr + 11] & 0x08) continue;" to fat_read_dir to check for the volume-label bit gets rid of the problem. I verified this on my Pi to make sure it works, and indeed I can now boot with rpi-boot from a boot-partition that comes straight from the raspbian image I used.
Perfect. Thanks. I must have missed that bit of the specification when I did the fat driver. I've added the relevant changes to the repository (actually incorporated with the long file name check because both set 0x8).
Thanks, it now runs fine out of the box, so I'll close this issue.