Integrate nxp uuu into labgrid.

[atline]

This PR to add nxp uuu support to labgrid, we use uuu to flash images to i.mx boards.

Description

Some considerations here:

• I notice there is realization for uuu driver here, but it's really not how we use it in NXP internal, see official example, also how we use it in lava
• Usually user need to use uuu to remotely flash a bootloader into broken board, so labgrid-client uuu added.
• We don't design uuu resource based on udev, this is because uuu will be separated into several stages: SDP, FB, etc. For SDP, uuu will use usb2.0 protocol, while for FB, if the board connected to a usb3.0, uuu will use usb3.0 protocol. That means the otg path may jump from 3:8 to 2:8 during uuu run. But if we use udev method we are not able to get some like uuu -m 3:8 -m 2:8 before run uuu, so we choose to statically specify ["3:8", "2:8"].
• In our scenario, some boards not directly linked to exporter, so a NetworkUUU could be specified for such case.
• When use ssh to call uuu, we will have to allocate a pseudo terminal there as when uuu flash, it will has a progress bar. Without -t, the screen will be chaos.

Local test here:

Checklist

• [√] Documentation for the feature
• [√] Tests for the feature
• [√] The arguments and description in doc/configuration.rst have been updated
• [√ ] CHANGES.rst has been updated
• [√ ] PR has been tested

[jluebbe]

I see some issues with this PR, which we'll need to discuss.

The UUU resource doesn't support the normal udev matching, which means that the client can't know whether the device is actually available or not. So, await_resource cannot be used with it, which makes some more complex test cases unreliable, as they would need to rely only on timing.

The UUU resource mixes multiple protocols, which already have existing resources in labgrid (IMXUSBLoader, AndroidFastboot).

What's the benefit of using UUU to handle the Fastboot phase (instead of the standard fastboot tool)?

I'd prefer to keep the stages (bootloader upload & flashing) separate, as otherwise you don't have a chance to capture and interact with the bootloader. What is the benefit of mixing that in UUU?

The UUUDriver tries to push any argument that is a file to the exporter. Isn't there a better way to give the arguments more structure, so the driver knows what is happening?

Did you try to use the existing IMXUSBLoader & AndroidFastboot resources with a new UUUDriver?

[atline]

I see some issues with this PR, which we'll need to discuss.

[A] Yes, thanks for reply, I'm new to this project, so please guide me :)

The UUU resource doesn't support the normal udev matching, which means that the client can't know whether the device is actually available or not. So, await_resource cannot be used with it, which makes some more complex test cases unreliable, as they would need to rely only on timing.

[A]

• I never touch the concept await_resource, pretty new to learn labgrid detail :) . But if we use NetworkSerialPort or PDUDaemon, could labgrid assure the resource actually available or not? So, looks UUU without udev is not the only exception, you have more exceptions already?
• Why we not based on udev?
  • We have a hybrid farm in NXP, lava for CI test(support release, nightly and kernelCI), while labgrid for engineer debug(support power cycle, console, and maybe UUU later), and they share 1 board.
  • But when we deploy exporter on the same board server which lava-worker also on it, it frequently meet this problem, looks lava's pexpect on serial port results in a heavy IO. It's not just happens on one machine, so now we move the labgrid exporter to a separate machine, pretty stable now. Then, we need client not ssh to exporter, but ssh to a specified board server to operate UUU. If that is the case, could we benifit from udev? Exporter even don't know the board...
  • We can't get next -m 3:8 -m 2:8 with udev, of course you suggest not to flash with UUU, use fastboot.

The UUU resource mixes multiple protocols, which already have existing resources in labgrid (IMXUSBLoader, AndroidFastboot).

[A] Depends on if we use udev.

What's the benefit of using UUU to handle the Fastboot phase (instead of the standard fastboot tool)?

[A]

• Much simpler. When board broken, the i.mx board will automatically switch to serial download mode, Then with just one command, uuu will interact with ROM to download a valid bootloader and flash it. Meanwhile, for most of i.mx8 and later i.mx9 chip, we will have BCU support, which could switch the jumper automatically with software, that will be our main solutions later to automate i.mx test.
• And, uuu is also a test target here, guys may need to use labgrid to directly operate uuu to verify flash function ok or not.
• The embeded uuu script will default combine all modes, users will have to separate them with customized uuu script. As a tool in farm, I hope user's life much simple when use the tool.
• In our local release, some legacy's board even don't have fastboot command in uboot. Meanwhile, internal, most of guys use this tool, seldom to use fastboot as UUU is much easier.

I'd prefer to keep the stages (bootloader upload & flashing) separate, as otherwise you don't have a chance to capture and interact with the bootloader. What is the benefit of mixing that in UUU?

[A]

• What we need to interact with the bootloader? For our cases, we use it to recover boards, you know in a boardfarm, guys may corrupt the boards, we just need to use it recover that. And for detail interact with bootloader, after flash it with UUU, we could open the serial to interact with uboot. For more detail check, we even could write our own UUUScript, not use the Embedded -b emmc uuu script. In customized uuu script, you still could control not to use FB.
• And I'm not sure, does you suggestion works on a pretty new board without bootloader?

The UUUDriver tries to push any argument that is a file to the exporter. Isn't there a better way to give the arguments more structure, so the driver knows what is happening?

[A] What we usually used is next:

If we have an accurate control, that means we will need to add special arguments for bootloader & rootfs? Is my understanding correct? My initial thought is: the command could have the same usage as the one if we not use labgrid, then everyone could quickly run any uuu command just as no labgrid there. You know when use fastboot, it could just use labgrid -p place fastboot boot boot.bin without change the habit of non-labgrid user. But for uuu, the file numbers are not fixed, so I don't know how to handle that better.

Did you try to use the existing IMXUSBLoader & AndroidFastboot resources with a new UUUDriver?

[A] No, same as previous, I guess it depends on if we based on udev...... Or, if it's acceptable to afford 2 options: one based on udev to get the exact "usb path" if we link the board directly to exporter, for what you mentioned "await resource"; another one not based on udev to fix our current scenario? It that, I will have a try with IMXUSBLoader although I'm not quite sure what it is... Sorry, currently I just use power and console with labgrid...

[atline]

There is another team in NXP which use labgrid, we're contacting now to possible align something internal, other guys may back with other solution.