rpi-open-firmware
rpi-open-firmware copied to clipboard
christinaa
Test other models
Development is primarily occuring on Raspberry Pi 2 Model B Rev 1.1 boards at the moment. Other boards need to be tested for at least feature parity. I don't think we've decided if the extra features on the later models should be supported (bring-up for integrated radios, for instance).
| 1 A | 1+ A | 1 B | 1+ B | 2 B | 3 B | CM | Zero |
|---|---|---|---|---|---|---|---|
| partial | untested | untested | untested | yes | yes | untested | untested |
rPi3 is compatible so that should be of no concern. The biggest concern comes from rPi1 where we use a BCM2709+ memory map (0x3F for MMIOs) while the standard specifies a different range. We could detect it via version and set up the memory map accordingly to support vanilla rPi1 kernels.
You would need to check the CPUID and based on a CPUID bit of the VPU either map at 0x20 (rPi1) or 0x3F (rPi2+). Currently we just map at the latter.
In addition to the mapping, there are also the MMIO accesses of the firmware itself. So either we need to build different binaries (#define ARM_PERIPH_BASE differently for each), or add a runtime variable for the base address.
I think on the ARM side something like g_MMIOBase would work as a constant offset and we could just pass it in the firmware data section when loading stuff on the ARM. That way we would still be able to use a single bootcode.bin build for all versions of RPi.
I have a pi0 and have successfully been able to boot, what is the testing procedure to state whether or not it works?
Caveat: so far I have only booted via USB with no SD card. As bootcode.bin does not know about this it panics trying to identify the SD card. I will test with an SD card as soon as I know the procedure to get a go/no-go for a platform.
I have a Raspberry Pi 1 B, the old model wit 256 MB RAM. It runs up to where it jumps to the kernel and then nothing appears in the console. Do I need to make any adjustments besides replacing the bootcode.bin file to test? A different kernel/device tree/cmdline.txt?
This is expected; the BCM2835 used in the original RPi has a different memory map than the newer models. Accomodating this cleanly is not a big deal, but it has not been done yet.
In the mean time, try changing 0x3F000000 to 0x20000000 on line 24 of hardware.h and rebuilding.
Still getting no response from the kernel. I am wondering about the device tree and cmdline.txt, as I understand this project uses the simple UART rather then the PL11 UART. The cmdline specifies ttyAMA0 as console, which is the PL11 UART. Should I make adjustment to use the simple UART?
AFAIK Linux does not support the simple UART, hence why the full UART is initialised instead. (This was changed around January to enable earlyprintk)
From what I've read, there should be support for it on the rpi3. However as the rpi1 used a different kernel it might not be in there.
Anyhow, I have downloaded the latest binaries from the raspberry pi repo, just to be sure (as I was using ArchLinuxARM binaries before) This is what my output looks like: rpi-boot.log.txt
So I have built and tested the bootloader for the Zero and 3. So far I have been able to successfully get the bootloader to boot on both, but a kernel successfully loads on the RPI 3 (with a kernel panic), which at this point of the project that is expected.
On both models I have create a busybox initramfs and included this source with the kernel compilation. I would like to note that I am not entirely confident that I have built the initramfs properly.
@bobbybee I have tried your 87bf321 to try and get the RPI Zero to load the kernel but nothing has worked. I have used the mainline kernel and the librepi/linux I am getting almost the same result as @a-v-s on a RPI Zero:
"Uncompressing Linux... done, booting the kernel."
This is where it is crashing for me on the zero.
Here are my logs for both the RPI 3 and Zero:
The only kernel that did boot for the RPI 3 was from @bobbybee 's repo librepi/linux, the .config I used was from @christinaa website. Again it did boot, but there was a panic.
@christinaa @bobbybee Is it possible to open the wiki portion of this repo? I would like to add step-by-step instructions (from compiling the VC4 toolchain to boot) so that others can test and reproduce their own bootloaders.
Thank you @christinaa.
I did another quick test with a 3B+, (not the original 3B):
The result was (almost) exactly the same as the RPI-3 log above, the bootloader worked and the kernel panicked. This was what I predicted to happen, the processors are almost identical.
Here is my log for the 3B+:
