[GSoC] Help needed for the continuation of project RPi4B

[Alan Cudmore]

I verified that my RPi400 (RPi4 with keyboard) enables the console on UART
1, the "Mini UART" by default. (0xfe215040)
If I add this line to config.txt on the SD card:
dtoverlay=disable-bt
The console comes up with the PL011 UART on the same pins (0xfe201000)
So if you want to use the PL011 UART as the RTEMS console, make sure you
have the "dtoverlay=disable-bt" line in config.txt.
Without the "dt-overlay=disable-bt" line, the first PL011 UART is used to
communicate with the bluetooth device, and the Mini UART serves as the
serial console.
Alan

On Mon, Jul 11, 2022 at 3:28 PM Joel Sherrill <joel at rtems.org> wrote:

>
>
> 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/38b75dea/attachment-0001.htm>