-
Notifications
You must be signed in to change notification settings - Fork 111
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
Comments
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 |
Shouldn't the macros take care of this?
|
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 |
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. |
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. |
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: |
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. @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? |
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).
The text was updated successfully, but these errors were encountered: