Test other models
alyssarosenzweig opened this issue · 17 comments
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.
87bf321 should solve this.
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 on me a Raspberry Pi 1 B+. Will test.
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?
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?
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.
You should be able to edit it now.
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+:
I've got a Zero W, need any testing?