On 26 April 2018 at 15:22, Corentin Labbe clabbe@baylibre.com wrote:

Hello

I want to introduce a devicedict parameter for differentiate mainline/vendor uboot.

Be clear on the terminology here - you're talking about a device dictionary parameter but you're making a change to the device-type.

For example, amlogic boards could work with both, but thet have some differences like uboot prompt.

So for example I have modified lava_scheduler_app/tests/ device-types/meson-gxl-s905x-khadas-vim.jinja2 like this: +{% if use_vendor_uboot %} {% set bootloader_prompt = bootloader_prompt|default('kvim#') %} +{% endif %}

It would seem unusual to have different U-Boot builds determined by the device-type. More likely, at any one time, you have some devices of this type which are mainline and some devices which are vendor.

Therefore, the point to change this is in the device dictionary of each device.

for devices with vendor U-Boot configured: {% set bootloader_prompt = 'kvim#' %}

You should then use device tags to distinguish the devices so that test writers can know which one is in use.

Note that my way is to assume that mainline uboot is the default.

But since non-amlogic boards (imx6q-sabrelite for example) will need the same way for differentiate, having an agreement on the name could be usefull.

Does use_vendor_uboot is good for you ?

No. It sounds like this is the wrong place to do this.

On 27 April 2018 at 14:42, LABBE Corentin clabbe@baylibre.com wrote:

On Thu, Apr 26, 2018 at 03:33:06PM +0100, Neil Williams wrote:

...

On 26 April 2018 at 15:22, Corentin Labbe clabbe@baylibre.com wrote:

...

Hello

I want to introduce a devicedict parameter for differentiate mainline/vendor uboot.

Be clear on the terminology here - you're talking about a device

dictionary

...

parameter but you're making a change to the device-type.

I want to change device-type file by adding an "if" which test a parameter that will be set per device (so in device dictionary).

...

...

For example, amlogic boards could work with both, but thet have some differences like uboot prompt.

So for example I have modified lava_scheduler_app/tests/ device-types/meson-gxl-s905x-khadas-vim.jinja2 like this: +{% if use_vendor_uboot %} {% set bootloader_prompt = bootloader_prompt|default('kvim#') %} +{% endif %}

It would seem unusual to have different U-Boot builds determined by the device-type. More likely, at any one time, you have some devices of this type which are mainline and some devices which are vendor.

Therefore, the point to change this is in the device dictionary of each device.

for devices with vendor U-Boot configured: {% set bootloader_prompt = 'kvim#' %}

You should then use device tags to distinguish the devices so that test writers can know which one is in use.

The problem is that this "set bootloader_prompt = 'kvim#'" is set in the upstream device-type.

Then make that device-type support an override and put the overrides in the device dictionaries, not in the device-type.

There are a lot of examples of doing this already.

{% set bootloader_prompt = uboot_bootloader_prompt|default('kvim#') %}

And this sort of problem is spread for other boards.

Yet each one is moved to the alternate U-Boot build manually by admins, so this is a natural place to make the change to the device dictionary for that updated device.

So instead of moving vendor uboot specific hack on each device, I think it is proper to have all stuff in device type file.

Does my intention is more clear now ?

It's not a hack. It is how the system is designed to work. Devices will change U-Boot build from time to time, that should not require changing the device-type template, only the device dictionaries.

Device-type templates are for settings which apply (as defaults) to every device of that type. The version of U-Boot is not necessarily the same across all devices of that type.

...

...

Note that my way is to assume that mainline uboot is the default.

But since non-amlogic boards (imx6q-sabrelite for example) will need

the

...

...

same way for differentiate, having an agreement on the name could be usefull.

Does use_vendor_uboot is good for you ?

No. It sounds like this is the wrong place to do this.