When I wanted to integrate Unikernel into an embedded system in a good way, I needed equipment that could run RTOS and Linux at the same time, so I ported it as the title suggests.
I feel that there are many FreeRTOS independent boot configurations when porting for Raspberry Pi, but this time FreeRTOS allows you to boot with Linux at the same time after kicking from u-boot.
It would be very easy if you bring an i.MX8M or ZynqMP SoC that already has an implementation that runs RTOS and Linux at the same time, but if you use Raspberry Pi, it should save you money and acquire knowledge.
You can find it here (https://github.com/TImada/raspi4_freertos). See README.md for how to build and use it.
The base implementation is @eggman's [FreeRTOS] for Raspberry Pi 3 (https://qiita.com/eggman/items/2b6eb18b297673bab6c0). Thank you for the efforts of our predecessors m (_ _) m.
As described in detail in Raspberry Pi stub code commentary article, the memory area up to 0xD8 --0xF7 is 8 bytes. Each one is labeled spin_cpuX: X = 0,1,2,3. If you want to kick the binary with CPU core # 3, write the start address of the vector table to spin_cpu3 (= address 0xF0) and issue the SEV instruction, and CPU core # 3 will start working properly.
In this porting, the vector table address writing to address 0xF0 was left to the u-boot mw command, but when this command is executed on CPU core # 0, the writing result stays in the cache and is stored in physical memory. There was a situation where it was not reflected (Alee ...). CPU core # 3 sets the program counter by looking at the value at address 0xF0, but if the value is not reflected in the physical memory, the value at address 0xF0 remains 0x0. At this time, CPU core # 3 has a stub code implemented so that the WFE instruction is issued and a nap is taken.
To solve this problem, it would be nice if u-boot's dcache flush command could be used, but u-boot included in Ubuntu 20.04 LTS for Raspberry Pi 4B did not have this command, so u-boot I had to recompile ...
If you kick Linux after kicking the FreeRTOS sample from the u-boot prompt, Linux will set GIC for Linux and the GIC configuration you set earlier in FreeRTOS will be overwritten (especially the problem). It was a rewrite of the GIC Distributor settings by Linux). If that happens, the tick timer and UART interrupts will not come in.
So, this time, I implemented a mechanism on the FreeRTOS side to detect the timing when Linux finishes the GIC Distributor setting, and FreeRTOS resets the GIC setting again after Linux finishes the GIC setting. Detection mechanism is a busy loop x2 process that is not friendly to the earth. Eventually we will have to rethink the method.
If you are familiar with it, you may have already noticed it. Actually, if you use UART1 (mini UART) on the FreeRTOS side, you don't need to implement the UART2 part because UART1 was already in the base implementation.
Yes, of course I knew it, but I dared to do it. Smile.
Ported remoteproc / rpmsg so that Linux and FreeRTOS can communicate.
Recommended Posts