[GSoC] Help needed for the continuation of project RPi4B

[Joel Sherrill]

On Mon, Jul 11, 2022 at 11:13 AM Noor Aman <nooraman5718 at gmail.com> wrote:

> Hello, I wanted some help on my project and what do I need to do next.
> Here is a summary of what I have done so far.
>
> ---- TESTING ----
> - Tested bare-metal from https://rpi4os.com, worked good
> - (Suggested by Alan) Tested VxWorks from
> https://www.windriver.com/products/vxworks, it worked fine too.
> - Tested the Looking aon the rpi4b, modified the linkercmds to point at
> address 0x200000, 0x80000 and 0xFE000000 (Tried all three of them), loaded
> it using openocd, it was getting stuck at the
>
> arm_pl011_write_polled (base=<optimized out>, c=13 '\r') at
> ../../../bsps/shared/dev/serial/arm-pl011.c:79
> while ((regs->uartfr & PL011_UARTFR_TXFF) != 0)
>
> after manually adding serial uart address through GDB, the code jumps to
> 0x200.
>

If so, what address is it really at? Looking at
https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf on page
148 of the PDF, I would expect the PL011 to be at these addresses:

 • UART0: 0x7e201000
 • UART2: 0x7e201400
 • UART3: 0x7e201600
 • UART4: 0x7e201800
 • UART5: 0x7e201a00

Looking at the a72/console source, I see it is using
BSP_A72_QEMU_VPL011_BASE as the base address of the UART which doesn't
match the Pi4

$ grep -r BSP_A72_QEMU_VPL011_BASE
console/console.c:  .regs = (volatile pl011 *) BSP_A72_QEMU_VPL011_BASE,
include/bsp.h:#define BSP_A72_QEMU_VPL011_BASE 0x9000000

Assuming I found the right SoC documentation, that is an obvious reason the
console fails.


> ---- CODE -----
> - Made a basic abi.yml, bsp*.yml, linkercmds.yml for rpi4b under
> spec/build/aarch64
> - copied some of the files from a72 like bspstarthooks.c and tm27.h into
> bsps/aarch64/raspberrypi4b
>

Reasonable but I think you need console/console.c from a72 and make sure
the address, etc. is correct for the Pi 4.


>
> ---- ANOMALIES ----
> - Some registers are failing to show in the gdb, some of them are ESR_EL1,
> ELR_EL2 and SPSR_EL3, are they required?
>

Not an expert here but those are protection level related and system
registers. I'm not surprised you can't see them in gdb. If you need them to
have specific values, someone else will have to chime in.


> - So in order to cross check, I'm trying to use RPi4B qemu build (Custom
> fork). Not tested yet. I'm planning to do this in a qemu machine. Any other
> suggestions?
>

If this qemu is vaguely close, it may make it easier to debug. But your
peripheral addresses need to be correct for the hardware.

You can also look at the qemu machine code specific to the Pi 4 and should
be able to easily see what address each peripheral is at.


> - trying to use u-boot. One thing to note is that even with U-boot, you'll
> have to use the bootcode.bin from the 1.20200212 tag. This is mentioned in
> the VxWorks README. Alan once mentioned about not being able to boot the
> RPI zero 2, because of this issue. Is there any problem using old
> Bootcode.bin?
>

No way to know without trying but focus on the Pi 4 and don't worry about
other variants having issues with this bootcode.bin. You need it to work
once for you on the Pi 4. More needs to work before this is a worry.


> - tested the christinaa/rpi-open-firmware, didnt work as expected
>
>
> ---- QUESTIONS ----
> - Would there be any gain from using U-boot? As this is just a Second
> stage bootloader.
>

My gut is that it would be a distraction at this point.

>
> - What should be my next step?
>

Make sure you have the right address for peripherals. I think at least the
UART is wrong. But you did get to the console code polling data out so you
probably have the basic memory map right. Just need to focus on peripherals
now.



> - Any recommendations which will help me for the project?
>
> I know I'm a bit slow in this project. My sincere apologies for that. My
> college is still open and we are at the end of the semester so it's a bit
> inconvenient to adjust my time for both. Semester time was reduced from 6
> months to 4 months. I think we might not get vacation this year in order to
> adjust the timing like it was before Covid. So please bear with me a bit :)
>

Sometimes this type of work is just frustrating and slow. What in
retrospect is one setting wrong can take an unfortunate amount of time to
discover.

Covid has been challenging. I shifted to primarily work from home long
term/permanently.  It has certainly required everyone to be flexible.

--joel


> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20220711/6c623e17/attachment.htm>