timada / raspi4_freertos Goto Github PK

This is also no real issue, im just very interested :)
I have a program that uses FreeRTOS on an ARM Cortex A9 processor. There i use for example Ethernet ( #include FreeRTOSIPConfig.h). The corresponding .c is realised in a library.
Now i want to use your FreeRTOS port to run the program on RPi (ARM Cortex A72).
Are all the libraries (with e.g. FreeRTOSIPConfig.c) already ported to the RPi? Or did you "only" ported the uart interface?
I cant find the FreeRTOSIPConfig.h or .c in your repo.

Hi Takayuki,
this is also not an issue.
I want to build this project on Windows (cause we have a simulation and testbench tool (build by windows), running with FreeRTOS on the Zynq board).
I want to use your FreeRTOSRPi4-port to shift this simulation and testbench tool from the Zynq-board to the RPI4 for open source ability. Unfortunately in the first step I have to use windows to build. In the second step, we imagine a linux build variant.
Do you have some hints, or suggestions to build it with windows?
Kind Regards
Nelson

Thx for the FreeRTOS port to RPI4B!

I am able to follow your instructions and placed Ubuntu Linux 22.04 LTS 64bit diesktop on the RPI first. I used the PI imager to do this.

I was also successful building the u-boot bin.

At first I used your instruction to copy the u-boot.bin to kernel8.img in the boot partition of the RPI imaged SD card. But, the desktop botted instead. In the config.txt file I noticed that kernel = vmlinuz file, so I changed it to kernel8.img. It then booted into u-boot image and I was able to get the u-boot prompt.

I then followed your instructions to load the uart.elf that has been copied to the SD card boot partition.

dcache off
fatload mmc 0 0x28000000 uart.elf
dache flush
bootelf 0x28000000

After the bootelf there is no response indicating the start. I just get the u-boot prompt.
I tried to use the u-boot go command at the entry point 0x20001788 and it attempts start, but fails with an rc=0 message.

Any advice or suggestions you can provide of course are appreciated.

Cheers Matt Smith

Thank you for the nice project Takayuki!
I use:
a Virtual Machine Ubuntu 18.04 (like Tlmada)
aarch64-none-elf Cross Compiler
RaspOS Lite (64-bit) on the Pi 4 (8GB RAM)
What I did so far:
I managed to come to step 4/5 (without changing memory region)
I disabled the mmu, but dont change the page table configuration (step3)

Yet, I dont have a USB to UART Converter, so Im writing in the u-boot command line on the RPi4.
I copied the uart.elf file on the SD-card and get into the u-boot prompt.

Step 4:
I loaded the uart.elf file with fatload (boot-partition is in fat):
fatload mmc 0:1 0x28000000 uart.elf
28512 bytes read in 40ms. Everything is fine. Afterwards I flushed the dcache.
But after bootelf 0x28000000 nothing happens.
I thought maybe without UART-connections there is no output, so i continued.
Step 5:
I didnt remove the PL011 and didnt add the memory region 0x20000000 - 0x209FFFFF to the reserved-memory.
I used the modified device tree file from ubuntu 20.04 (as mentioned), compiled it to dtb file an copied it on the SD-card.
After changing the CFLAGS and extendind the cmdline.txt with maxcpus=3, I got to the u-boot prompt to lanch FreeRTOS.

Problem:
Like in step 4 I also couldnt launch FreeRtos in step 5. No output in u-boot.

What I did to solve the problem:
Im dealing with https://elinux.org/RPi_U-Boot#Test_U-Boot to start Freertos (uart.elf with BCM2711-rpi-4-b-rtos.dtb), or RaspOS (start.elf/start4.elf with BCM2711-rpr-4-b.dtb)

Can somebody help me to launch freertos/RaspOS from u-boot?
Thank you in advance
Nelson

Hey there! First of all, thanks for this port, this is enabling some real learning processes here :)

Secondly, this is not an issue perse.
But, because it didn't work out of the box for me, I started code browsing to understand what is going on.
And I found that here you define the base address of the UART2.

However, checking the RPi4's Periherals Document, p147, I noticed that the UART2 address is offset by 0x80000000 on the code.

So, what would be the rationale here? Is it supposed to be 0xFE201400 or 0x7E201400? I know that somehow this is correct, otherwise, people would complain that it is not working =)

Again, thank you so very much for the port.
Kind regards, Paulo.