-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: