Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test other models #31

Open
alyssarosenzweig opened this issue Jan 8, 2017 · 17 comments
Open

Test other models #31

alyssarosenzweig opened this issue Jan 8, 2017 · 17 comments

Comments

@alyssarosenzweig
Copy link
Contributor

alyssarosenzweig commented Jan 8, 2017

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
Copy link
Owner

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
Copy link
Contributor Author

alyssarosenzweig commented Jan 14, 2017 via email

@christinaa
Copy link
Owner

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
Copy link
Contributor

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
Copy link
Owner

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
Copy link
Contributor Author

87bf321 should solve this.

@ghost
Copy link

ghost commented Apr 3, 2017

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
Copy link

Icekhaos commented May 8, 2017

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

@a-v-s
Copy link

a-v-s commented Jun 25, 2017

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
Copy link
Contributor Author

alyssarosenzweig commented Jun 25, 2017 via email

@a-v-s
Copy link

a-v-s commented Jun 25, 2017

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
Copy link
Contributor Author

alyssarosenzweig commented Jun 25, 2017 via email

@a-v-s
Copy link

a-v-s commented Jun 25, 2017

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
Copy link

NF3RN0 commented Nov 20, 2018

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
Copy link
Owner

You should be able to edit it now.

@NF3RN0
Copy link

NF3RN0 commented Nov 20, 2018

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants