Errors when trying to run the Virt Aarch64 demo with Linux + FreeRTOS

[robertoxmed]

I am currently trying to run Bao with the Linux and FreeRTOS example for QEMU's virt on aarch64 (baremetal sample works in the current state with the next branch).

export PLATFORM=qemu-aarch64-virt
export DEMO=linux+freertos

Compilation

The cross compiler (aarch64-none-elf- v10.3) will fail when trying to compile the icc_sre_el2 register. A MR has been proposed to fix this.

Running

I am unsure if FreeRTOS is actually running when launching the QEMU machine and jumping to Bao's address.

I have the following output on QEMU's UART:

=> go 0x50000000
## Starting application at 0x50000000 ...
Bao Hypervisor
BAO ERROR: no handler for abort ec = 0x20

After logging to Linux and echoing to /dev/baoipc0

BAO WARNING: Unknown system call fid 0x1

When I cat on /dev/baoipc0 I see some random characters

# cat /dev/baoipc0
��#

[simonevallifuoco]

Hi, I am experiencing the same issues. I had the same compile error with the icc_sre_el2 register and fixed it following this solution. Then I was able to launch qemu and encountered the same error: => go 0x50000000 Starting application at 0x50000000 ... Bao Hypervisor BAO ERROR: no handler for abort ec = 0x20

Have you fixed this issue yet? Anyone has suggestions?

[sandro2pinto]

Apologies for the inconsistence. Fix coming soon.

[simonevallifuoco]

Thank you, @sandro2pinto. Since we'd like to run bao in dual guest mode as soon as possible, could you please tell us which stable versions/branches of freeRTOS_over_bao, bao_demos and bao should we clone/checkout to, in order to correctly configure the system?

[josecm]

@robertoxmed @simonevallifuoco so sorry for the delay in getting to this. So the problem was that I have been updating bao and the baremetal/freertos repo's and not the demos, so some inconsistencies came up. I've been working on updating this for the past week. And hopefully, everything is working now.

I've updated some of the tool's versions including the aarch64 toolchain to 11.2 and qemu to 7.2.0 (but for arm, 7.1.0 should work also). So, after you pull the changes, also fully delete the 'wrkdir' to make sure everything is freshly fetched with the latest versions.

I'd appreciate it if you could let me know if it is working for you now. Also, if you run into any issues again, I'll try to be quicker with the answer.

[simonevallifuoco]

@josecm thanks for your help and your work!

Anyway, I am trying to run bao with linux+freertos demo on qemu following the new guide. I made a new debian 11.6 VM in order to avoid conflicts with the older files. Everything works fine until the step B.5) Build Firmware and Deploy: at the Qemu Aarch64 Virt, step 3) Build TF-A, where I am getting the following output when running the command make PLAT=qemu bl1 fip BL33=$BAO_DEMOS_WRKDIR/imgs/$PLATFORM/u-boot.bin QEMU_USE_GIC_DRIVER=QEMU_GICV3:

If it can be useful, I am using the following tools versions: gcc-arm-11.2-2022.02-x86_64-aarch64-none-elf make 4.3 dtc 1.6.0 gcc 10.2.1 ninja 1.10.1

[robertoxmed]

Hello, thanks a lot for the update.

I have the same error as mentioned before with version 11.2 of GCC-arm.

Nonetheless, if I use 10.3.1 the demo builds and works after I do the FreeRTOS tweak.

[josecm]

@robertoxmed @simonevallifuoco Thanks for bearing with me and the prompt replies.

Yeah, it seems because the error that option is fixing only appears on toolchain version 12, the option to remove the error is also only available in 12. I should I've seen that coming.

@robertoxmed The issue with version 10 is that it does not recognize ICC sysregs by name. So indeed if you stick with GCC version 10, you will need that tweak for building freertos or the baremetal app.

Anyways, I've fixed the trusted-firmware problem that the '--no-warn-rwx-segments' option was trying to fix in another way (by removing the option that turns linker warnings into errors). It should now work with version 11 of the toolchain as well :crossed_fingers:. Please delete arm-trusted-firmware from 'wrkdir/srcs' and retry.

[simonevallifuoco]

Thank you @josecm , everything works fine now!