<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 11, 2022 at 11:13 AM Noor Aman <<a href="mailto:nooraman5718@gmail.com">nooraman5718@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello, I wanted some help on my project and what do I need to do next.<br>Here is a summary of what I have done so far.<br><br>---- TESTING ----<br>- Tested bare-metal from <a href="https://rpi4os.com" target="_blank">https://rpi4os.com</a>, worked good<br>- (Suggested by Alan) Tested VxWorks from <a href="https://www.windriver.com/products/vxworks" target="_blank">https://www.windriver.com/products/vxworks</a>, it worked fine too.<br>- 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 <br>     <br>      arm_pl011_write_polled (base=<optimized out>, c=13 '\r') at ../../../bsps/shared/dev/serial/arm-pl011.c:79          <br>   while ((regs->uartfr & PL011_UARTFR_TXFF) != 0)<br><br>after manually adding serial uart address through GDB, the code jumps to 0x200.<br></div></blockquote><div><br></div><div>If so, what address is it really at? Looking at <a href="https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf">https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf</a> on page 148 of the PDF, I would expect the PL011 to be at these addresses:<br><br> • UART0: 0x7e201000 </div><div> • UART2: 0x7e201400</div><div> • UART3: 0x7e201600</div><div> • UART4: 0x7e201800</div><div> • UART5: 0x7e201a00   <br></div><div><br></div><div>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</div><div><br></div><div>$ grep -r BSP_A72_QEMU_VPL011_BASE<br>console/console.c:  .regs = (volatile pl011 *) BSP_A72_QEMU_VPL011_BASE,<br>include/bsp.h:#define BSP_A72_QEMU_VPL011_BASE 0x9000000<br></div><div><br></div><div>Assuming I found the right SoC documentation, that is an obvious reason the console fails.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>---- CODE -----<br>- Made a basic abi.yml, bsp*.yml, linkercmds.yml for rpi4b under spec/build/aarch64<br>- copied some of the files from a72 like bspstarthooks.c and tm27.h into bsps/aarch64/raspberrypi4b<br></div></blockquote><div><br></div><div>Reasonable but I think you need console/console.c from a72 and make sure the address, etc. is correct for the Pi 4.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>---- ANOMALIES ----<br>- Some registers are failing to show in the gdb, some of them are ESR_EL1, ELR_EL2 and SPSR_EL3, are they required?<br></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">- 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?<br></div></blockquote><div><br></div><div>If this qemu is vaguely close, it may make it easier to debug. But your peripheral addresses need to be correct for the hardware.</div><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">- 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?<br></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">- tested the christinaa/rpi-open-firmware, didnt work as expected<br><br><br>---- QUESTIONS ----<br>- Would there be any gain from using U-boot? As this is just a Second stage bootloader.</div></blockquote><div><br></div><div>My gut is that it would be a distraction at this point. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"> <br>- What should be my next step?<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">- Any recommendations which will help me for the project?<br><br>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 :)</div></blockquote><div><br></div><div>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.</div><div><br></div><div>Covid has been challenging. I shifted to primarily work from home long term/permanently.  It has certainly required everyone to be flexible. </div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>