[PATCH] tester: Add MicroBlaze KCU105 QEMU BSP

[Chris Johns]

On 25/8/21 7:46 am, Alex White wrote:
> On Mon, Aug 23, 2021 at 9:29 PM Chris Johns <chrisj at rtems.org> wrote:
>>
>> Hi,
>>
>> Could you please explain this file?
>>
>> Where is the source?
>>
>> Why would we allow a binay blob into the tester like this?
> 
> Hi Chris,
> 
> Running MicroBlaze tests on QEMU requires an appropriate DTB file to pass to
> QEMU via the "-hw-dtb" flag. There does not appear to be a way to pass the
> device tree source to QEMU.
> 
> This particular DTB comes from Xilinx as part of their KCU105 BSP.

The file you posted has no attribution and that means we cannot accept it. There
is also no source and so the binary blob is not acceptable. Anyway there are
better solutions to solve this.

> It seems most
> sensible to store it next to the tester configuration similar to the other
> device tree files in that directory (psim-device-tree, etc.).

In my view the device tree files are not the same.

> I realize that this is a binary file and the other device tree files in
> tester/rtems/testing/bsps are not, but it seems that this needs to live
> alongside the BSP configuration so that it can be referenced by kcu105_qemu.ini.

I do not agree.

>> This seems specific to a set up or a BSP and not the tester. I am not
>> comfortable with this approach. Have alternative approaches have you considered?
> 
> I am not aware of another way that would ensure consistency with the tester
> configuration. 

The tester is designed to handle this. The user focused INI files:

https://docs.rtems.org/branches/master/user/testing/configuration.html#bsp-and-user-configuration

You provide for your site are imported here:

https://git.rtems.org/rtems-tools/tree/tester/rt/config.py#n468

The key/value pairs are entered into the macro defaults. This means you can add
`%{bsp_qemu_extra_opts}` to the execute command in `qemu.ini` and then you can
create a suitable site specific INI file to match your BSP.

Where you then hold the DTB and the DTS becomes a separate and wider discussion.

> We could require that a user obtain the DTB from elsewhere and
> copy it to the correct directory, but that seems a lot more involved than just
> including the needed file and would be more difficult to keep consistent with
> any future changes that might be needed.

Yes it is more involved but how would the user of the BSP you are doing the work
for handle that same situation for their custom BSP? They cannot post a closed
DTB for their project to this list in the hope we commit it and I would not
suggest to them they create a branch in their repo to hold it. We have 2 roles,
one maintaining RTEMS and BSPs and another developing a suitable eco-system our
users can extend without touching the built tools we provide.

Chris