Rahix
commented
3 years ago Should an OpenSBI build testcase be added to tbot or do you consider such work out of scope for your project?
My stance on any kind of testcase addition is this: If it looks even remotely useful for others, please do consider adding it to upstream! I've created the tbot_contrib module for exactly this purpose. For me, one of the primary goals of this project is to provide a large set of reusable "testcases"/utilities which others can use to quickly build automation for their workflow/test-setup.
So just feel free to send a PR with whatever testcases you have :)
Other RISC-V boards will require to first build OpenSBI and then pass its location to the U-Boot build process (cf. doc/board/emulation/qemu-riscv.rst).
Similar requirements exist for Trusted Firmware on boards like Pine64 A64 LTS where you have to provide TF-A as environment variable BL31.
Right, this will need some changes to the uboot build testcases. As their design did not really prove itself I am planning a rework here anyway. Adding this feature to my list of requirements ...
If you need this working now, let me know, I can prepare some kind of workaround/hack.
For the RISC-V Maixduino board I will need to first build U-Boot and then OpenSBI passing U-Boot as payload:
Other RISC-V boards will require to first build OpenSBI and then pass its location to the U-Boot build process (cf. doc/board/emulation/qemu-riscv.rst).
Similar requirements exist for Trusted Firmware on boards like Pine64 A64 LTS where you have to provide TF-A as environment variable BL31.
Should an OpenSBI build testcase be added to tbot or do you consider such work out of scope for your project?