christinaa / rpi-open-firmware

Open source VPU side bootloader for Raspberry Pi.
Other
1.13k stars 111 forks source link

Test other models #31

Open alyssarosenzweig opened 7 years ago

alyssarosenzweig commented 7 years ago

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
christinaa commented 7 years ago

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.

alyssarosenzweig commented 7 years ago

Shouldn't the macros take care of this?

christinaa commented 7 years ago

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.

vamposdecampos commented 7 years ago

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.

christinaa commented 7 years ago

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.

alyssarosenzweig commented 7 years ago

87bf3214eb1acf423061c08b83977208fc41dff7 should solve this.

ghost commented 7 years ago

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.

Icekhaos commented 7 years ago

I have on me a Raspberry Pi 1 B+. Will test.

a-v-s commented 7 years ago

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?

alyssarosenzweig commented 7 years ago

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.

a-v-s commented 7 years ago

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?

alyssarosenzweig commented 7 years ago

AFAIK Linux does not support the simple UART, hence why the full UART is initialised instead. (This was changed around January to enable earlyprintk)

a-v-s commented 7 years ago

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

NF3RN0 commented 5 years ago

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:

RPI-Zero Log RPI-3 Log

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.

christinaa commented 5 years ago

You should be able to edit it now.

NF3RN0 commented 5 years ago

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+:

RPI-3-B-Plus Log

Anonymous941 commented 1 year ago

I've got a Zero W, need any testing?