[RSB PATCH] Added qemu 4.1.0 as bare target

[Jiri Gaisler]

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  ...
>
>> 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. 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).

Jiri.