[RSB PATCH] Added qemu 4.1.0 as bare target
Chris Johns
chrisj at rtems.org
Tue Aug 20 07:15:32 UTC 2019
On 20/8/19 4:59 pm, Jiri Gaisler wrote:
>
> On 8/20/19 12:44 AM, Chris Johns wrote:
>> On 20/8/19 6:53 am, Jiri Gaisler wrote:
>>> This patch will add QEMU-4.1.0 as RSB target devel/qemu4.
>> Looks good.
>>
>>> The current devel/qemu target will be preserved.
>> Should devel/qemu just point to qemu4? I am OK with this happening.
> If preserving the current qemu is not necessary, then I can just update devel/qemu to version 4.1.0 and not add devel/qemu4. This probably makes more sense ...
I will leave this for Joel to decide. He would like the engineering manual to
say how tests are run for the various archs/bsps and he would like to know what
each covers.
>>> Builds and installs fine on ubuntu 18.04 x86_64. Build scripts might need tweaks for other platforms.
>> It can be a lot of work depending on how building the support libraries goes. I
>> think we have reached a point where a newer qemu on platforms that can build it
>> is more important and the problem hosts such as MinGW and MacOS can be cleaned
>> up after.
> Agree. On ubuntu, the supporting libraries are not needed at all as they can be installed through the standard package manager.
MSYS2/MinGW had limited support here and I avoid the packages on MacOS because
of the collateral damage they bring, ie the posts about MacOS tools not building
that appear from time to time.
> But building them inside RSB makes it easier for the end-user who does not need to figure out what to install (or read the manual .. :-)
>>> A few patches are still pulled in, currently hosted on gaisler.org but could be moved to Trac ..? Tested with sparc/leon3 bsp, about 10 unexpected fails/timeouts out of 530 tests.
>> Does setting a longer timeout change this? I cannot find a suitable way to
>> adjust the timeout depending on the load.
>
> Not really, the tests are dead-locked somehow. This is probably because of qemu timing behavior. Here is the list of failures:
>
> Failures:
> dl09.exe
> psx12.exe
>
> Timeouts:
> spintrcritical06.exe
> spintrcritical07.exe
> spintrcritical12.exe
> spintrcritical11.exe
> spintrcritical13.exe
> spintrcritical14.exe
> spintrcritical15.exe
> spintrcritical18.exe
> spintrcritical24.exe
>
> It would be great if rtems-test could (optionally) take a timeout value from the bsp file, as some targets need a bit longer delay. (e.g. crypt01.exe fails on sis/RISC-V due to this).
Try creating a ~/.rtemstesterrc file or any file and pass in with --user-config
and add the BSP as a section and the timeout ...
[leon3]
timeout = 30
The INI values are added to the BSP's internal macro map and this should be
picked up when the process is exec'ed ....
https://git.rtems.org/rtems-tools/tree/tester/rt/config.py#n228
Chris
More information about the devel
mailing list