[RSB PATCH] Added qemu 4.1.0 as bare target

[Chris Johns]

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