driver/usbloader: rename RKUSBDriver to reflect rkdeveloptool usage #1542
Conversation
|
The support was originally added in #437. Pinging @otavio and @chtavares for their input. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1542 +/- ##
======================================
Coverage 56.5% 56.5%
======================================
Files 168 168
Lines 13111 13111
======================================
Hits 7417 7417
Misses 5694 5694
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
a3f
force-pushed
the
rkdeveloptool-rename
branch
from
25fc0f3 to
d278c0b
Compare
The match list doesn't yet support the RK3399pro (2207:330c). Add it along with the rest of the VID/PIDs listed in rkdeveloptool's udev rule[1] as well as the VID/PID pairs for the newer RK3566 and RK3588[2]. [1]: https://github.com/rockchip-linux/rkdeveloptool/blob/master/99-rk-rockusb.rules [2]: labgrid-project#1542 (comment) Signed-off-by: Ahmad Fatoum <[email protected]>
a3f
force-pushed
the
rkdeveloptool-rename
branch
from
d278c0b to
4aba887
Compare
To interact with a Rockchip SoC in BootROM mode over USB, Rockchip offers the rkdeveloptool, which is among others already packaged in Debian. We currently support this via the RKUSBDriver, which binds to the RKUSBLoader resource, which currently lists a single VID/PID pair. Actually making use of this is where things get confusing: Labgrid will look up the rk-usb-loader key to find rkdeveloptool and then fall back to a binary named `rk-usb-loader`. To my knowledge, no one names their rkdeveloptool that way and `rk-usb-loader` has since become the name of the Rockchip USB loader distributed by barebox. On systems, like the LXA TAC, this is doubly confusing: There's a rk-usb-loader binary, which Labgrid would use by default, but it's not compatible with rkdeveloptool, supports only the RK35xx SoCs barebox supports and is currently not supported by Labgrid at all. Given that RKUSBLoader only supports a single SoC, our documentation is wrong (it references the unrelated barebox' rk-usb-loader) and that our usage of rkdeveloptool goes beyond the BootROM's USB protocol and additionally flashes persistent media by talking to a first stage usb_loader that's uploaded first, I think the best course of action is to rename both the driver and the tool key to reflect that rkdeveloptool is actually used. Signed-off-by: Ahmad Fatoum <[email protected]>
The match list doesn't yet support the RK3399pro (2207:330c). Add it along with the rest of the VID/PIDs listed in rkdeveloptool's udev rule[1] as well as the VID/PID pairs for the newer RK3566 and RK3588[2]. [1]: https://github.com/rockchip-linux/rkdeveloptool/blob/master/99-rk-rockusb.rules [2]: labgrid-project#1542 (comment) Signed-off-by: Ahmad Fatoum <[email protected]>
a3f
force-pushed
the
rkdeveloptool-rename
branch
from
4aba887 to
203206a
Compare
| @@ -87,7 +87,7 @@ def load(self, filename=None): | |||
|
|
|||
| @target_factory.reg_driver | |||
| @attr.s(eq=False) | |||
| class RKUSBDriver(Driver, BootstrapProtocol): | |||
There was a problem hiding this comment.
We usually let the old RKUSBDriver raise a DeprecationWarning and instead use the new driver, i.e. see NetworkUSBStorageDriver.
There was a problem hiding this comment.
This won't work transparently, because I am changing the name of the tool key as well, but I can do this, so users are nudged into the right direction.
|
Sorry for chiming in with something that is not entirely related to those changes. So we sell Rockchip-based SoMs and boards for the last 6-7 years and I've taken interest in labgrid but I've hit a few "weirdnesses" (to me) in that process, that may very well be because I misunderstood how labgrid works. So, my setup is the following:
RKUSBLoader is only matching devices with vendor id 0x2207 and model id 0x110a. I've no clue what that represents as the RK3399, PX30 and RK3588 I work with aren't matching that model id. For now I've just added mines in there but I was wondering if it would make more sense to have parameters for that Resource, à-la AndroidUSBFastboot for example. Otherwise we can simply add more to the matching list over time, not sure it's interesting to bind labgrid updates with Rockchip SoC support? The tool to use to interact with the USB loader on Rockchip needs to run on the executor, but this needs to be specified on the Driver configuration side, which is part of the labgrid-device-config yaml file, which is on PC-B while it's going to run on PC-A. My issue is... there are currently three known tools for USB loading on Rockchip devices, rkdeveloptool, rockusb and this rk-usb-loader. I assume we could have some executors with one binary, and some others with another one. Why would the target conf file need to know on which executor something is going to run? Shouldn't this be related to a Place or the Resource itself? |
I am not sure either, maybe RV11?
I think it's useful anyhow to have the well-known VID/PIDs known to Labgrid. If it's possible to override them, it makes sense to have parameters for it, but the default should be that users add the VIDs/PIDs to Labgrid for shared benefit.
I don't find it unreasonable to update Labgrid when you are interfacing with a new SoC.
I haven't used rockusb so far, but both rkdeveloptool and rk-usb-loader have an incompatile commnad-line interface. For i.MX, there are multiple tools as well and Labgrid handles this by separating the resource ( Best case, both rk-usb-loader and rkdeveloptool are installed into What the client needs to know about though is which driver should handle the resource. This isn't something that we can just leave to the exporter, because the tools tend to have their idiosyncrasies, which leak through the abstraction. Once the driver is configured in your environment YAML though (e.g. with the name of the USB loader binary to use), the rest of Labgrid can interface with it generically via the Boostrap protocol, e.g. in the client it's just |
RV1108 apparently :)
I think it's unnecessary churn for the project and waiting time for people to be able to use labgrid with their yet-unsupported SoC. But that's a perfectly understandable policy, there's such policy for Yocto bbclasses for example, which is implemented in such a way it is very difficult to extend transparently.
rockusb[1] implements a third one :) [1] https://github.com/collabora/rockchiprs/blob/main/rockusb/examples/rockusb.rs though there is an issue by one of the contributors to add short parameters like rkdeveloptool[2]
I'm a bit worried by the rename because if we add support back for rk-usb-loader in the future, we'll have releases with "rk-usb-loader support but actually not really, the only way to use it is to point rk-usb-loader to rkdeveloptool with the tools: from the client config", other releases with "no rk-usb-loader support at all, rkdeveloptool is now through rkdeveloptoolusbdriver" and other releases with "actually now rk-usb-loader works, with the same driver as the releases that didn't work before". Which means we are breaking backward compatibility for the config file format (I don't know what's the stance of the project on that though). [...]
OK, so this means I need to have a huge myconfig.yaml, with all targets, that I maintain in a versioned repo that I could share with other devs I guess. It's a bit difficult for me to wrap my head around the potential sync issues between a place that is handled by the coordinator (and not versioned) and a client config file which could be defining a resource for a target via a place, those necessarily need to be in sync but by being different files, stored and used on different machines. Anyway, nothing related to this MR :) Thanks for the explanation. |
| if match not in [("2207", "110a"), ("2207", "301a"), | ||
| ("2207", "310c"), ("2207", "320b"), | ||
| ("2207", "320a"), ("2207", "320c"), | ||
| ("2207", "330a"), ("2207", "330c"), | ||
| ("2207", "350a"), ("2207", "350b") | ||
| ]: |
There was a problem hiding this comment.
suggestion (non-blocking): please comment on the SoC model those represents
This would make it easier to spot what's supported and what's not.
330c is RK3399
350b is RK3588
I also have:
330d for PX30 (but I can add myself, not an issue)
c.f. https://github.com/rockchip-linux/rkdeveloptool/blob/master/99-rk-rockusb.rules for some model ID
https://elixir.bootlin.com/u-boot/v2024.10/source/drivers/usb/gadget/Kconfig#L69 probably could help too :)
There was a problem hiding this comment.
I didn't do that before, because I didn't know what the original VID/PID was for, but I can annotate them now. Thanks!
Thanks for finding this out.
I'll have to defer to the maintainers what they think should be the policy.
Heh, even more reason to rename the driver to reflect what is supports.
Yes, this is confusing and this PR is rectifying the situation. I hope the impact will be limited as the driver seems not yet widely used evidenced by the single VID/PID match and the wrong documentation. I will add a deprecation warning and fallback as suggested by @Emantor.
Even in a future, where we have drivers for all three host utilities, the name will cease to work, but we got to make a tradeoff between complicating things for everyone or breaking it for existing users. The authors of the change, which are the only users I knew of, are fine with it. I hope such breaking changes will be rare in future.
For test suites, you'll want to check in the environment yaml into the repository alongside the tests anyway. You can customize values with For interactive labgrid-client usage, the client already instantiates drivers by default to match against resources. You still need a config though for the USB loader. Thinking about it, maybe we should change this in the same go: Other bootstrap drivers don't do persistent flashing of the bootstrapped image, maybe we should change the Rockchip USB driver to load only into RAM by default. That way |
|
[...]
RKUSBLoaderDriver was an awfully good name for a driver for rk-usb-loader though ;)
I think we could simply add support for rkdeveloptool in another driver and keep RKUSBLoaderDriver (and maybe even fix its support?). While we won't support an rkdeveloptool in tools:rk-usb-loader anymore, it should be rather easy to warn users of that via doc update and parsing the config and warn/fail if rk-usb-loader containers rkdeveloptool and say "please use RKDevelopToolDriver instead" or something like that. Also, I quickly went trhough the rk-usb-loader script and I think it is the equivalent of Currently RKUSBLoaderDriver allows to flash an image after a special binary has been USB loaded through special commands (for rkdeveloptool, that is Also, I just remembered that I'm therefore wondering if we shouldn't have clear separation of
We could very well use rk-usb-loader for the former and rockusb with the latter, or rkdeveloptool + df-util, etc...
kas is dealing with that with versioning the config format and warning/failing if you're using outdated config format with newer kas. Maybe something to investigate? In any case, if the breaking of backward compatibility is documented somewhere, that's fine to me :)
Thanks, I'll need to finalize some kind of setup, make mistake and learn from them. A bit still too fresh in my head for now.
AFAICT (haven't worked on it), on Rockchip we USB load TPL+SPL but then you have something very limited (proper + TF-A + OP-TEE + ... missing). You have the option of doing rkusb (or rockusb (the protocol) whatever its actual name) via rkdeveloptool to do stuff (write somewhere for example) or using DFU (or probably also fastboot). So, "USB loading" via |
And this name wasn't used before.
That's what I am doing basically
I don't think adding support anew for rk-usb-loader can be considered a fix. But eventually, we may have a driver for it. Note that the current name is
I will look into extending the deprecation warning, so there are messages for both using the old driver name and the old tools key.
I know. That's what the driver in Labgrid currently implements.
The current driver implements the Fastboot and DFU go beyond that and they don't implement
Yes, I am starting to think a rename alone is insufficient. The proper abstraction would be a fastboot/DFU-esque driver that makes available the flashing, erasing, system reset functionality of the USB loader and BootstrapProtocol::load would just do the equivalent of
barebox only emulates SoC-specific USB gadget protocols if it's needed for the prebootloader to chainload barebox proper. The idea is that the tools in barebox
It's documented in the changelog and there will be deprecation warnings along with a fallback for a transitory period. As a counterpoint to kas, docker has made their docker-compose.yml version field obsolete. I don't feel strongly either way, but there are tradeoffs involved and this would need more careful consideration.
rk-usb-loader only supports what barebox supports upstream, which at this time is RK3568 and RK3588. On both of these, it takes only the barebox image and the system boots to shell. I don't know if this is easily doable for older SoCs or this is just a side-effect of the new boot flow on the RK35xx and the RKNS format. (The RK3399 I mention in the PR is not supported in barebox. Getting Labgrid to handle the RK3399 properly is part of my Yak shave to eventually upstream out-of-tree barebox RK3399/PX30 support).
Personally, I'd always go with Fastboot or DFU, so I am not too motivated to implement a driver for the rockusb protocol in full..
That's how we use it. Then a script checks that "$bootsource" = "serial" and then barebox starts a composite gadget with fastboot/DFU and ACM in the background and then flashing is done via that.
Yes, IMXUSBLoader boots to shell. |
Well, if only I had taken the time to double check what I was saying... So I guess that's a +1 for the rename then since we'd probably have a driver named RKUSBLoaderDriver for rk-usb-loader (if anyone wants to implement that :) )?
Agreed.
Thanks for the info. My point being that it depends what one means with 'bootstrapping'. If I'm not mistaken, U-Boot images that are USB loaded only contain TPL+SPL and then is waiting for proper via rockusb/rkusb protocol, fastboot or dfu, no CLI access. I believe it should be possible for fastboot and dfu to upload a file to DRAM and execute it, not sure for rockusb/rkusb though. I seem to recall Collabora is doing that very thing https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/upstream_uboot.md#how-to-create-a-blob-containing-ddr-init-and-spl-for-rockusb So the issue here is that depending on the bootloader (I believe, haven't checked myself), we'd reach or not CLI with a simple
FWIW, I would need to use rkdeveloptool with rockusb support for my board(s) for flashing/erasing/reset since USB gadget isn't working in upstream U-Boot (at the very least on PX30 Ringneck, RK3399 Puma and RK3588 Tiger may be fine), only with the blob, who only supports rockusb commands.
OK. I am not sure this is possible in U-Boot SPL though. And if it is, I doubt it is common on Rockchip boards. I haven't had the need for USB loading upstream U-Boot so far, so have no experience with that.
Thanks for the info!
Is there some documentation available somewhere for this new boot flow for USB aside from the code in Barebox? I was considering making U-Boot generate a USB bootable (TPL+SPL) image but the source code stopped being released a few years ago and no support for RK35xx in it.
I have never built nor used Barebox so all I was and am saying is with respect to U-Boot.
We have some support in upstream U-Boot (though if it is actually properly tested... who knows). FWIW, U-Boot currently doesn't generate a USB bootable image so I doubt many people are generating them by hand using Rockchip host blobs :) (
IIRC, in U-Boot we check if the boot source is USB and then start USB gadget with different functions (DFU/fastboot/rockusb)? But no CLI at that point, everything done in C code at build time. |
Meh. I guess, we can just kick the can down the road by making
I see. Would you like to submit a follow-up PR bringing rockup support in Labgrid to parity with Fastboot? ;)
I don't know of anything besides the code, sorry. I assume either BootROM or DDR blob has logic to continue USB boot into DRAM once RAM is setup.
What does USB-bootable mean? The same barebox image placed on eMMC/SD/SPI can also be loaded via
Never too late to start: https://barebox.org/demo ;)
I see.
For me that's the point of bootstrap. Get a full bootloader running, so I can decide what to do next.
I am grateful, I can use a single binary for everything. |
That would force us to use rkdeveloptool with the rockusb protocol, which for example doesn't implement erasing
What exactly are you suggesting here, I do not understand.
I can explain how that works in U-Boot though :) The BootROM finds magic value which starts the expected header. It loads the DRAM init code in SRAM. The DRAM init stage (either through upstream U-Boot TPL with open-source DRAM init or via the blob provided by Rockchip) init the DRAM and then exits back to BootROM which continues reading from the medium according to info in the header and loads the next stage. In U-Boot, that's SPL. Then SPL loads from the same medium (or a fallback one) a fitImage which contains TF-A, OP-TEE and U-Boot proper. Loads TF-A, executes it. TF-A does its thing, changing the EL before executing into U-Boot proper. You'll notice that we don't do a back-to-bootrom step between SPL and TF-A.
I need to look into Barebox source but I can already tell you that's not the case for U-Boot. We have one image for eMMC/SD and another for SPI. This is required for RK3399 (and older SoCs) because some SoCs have a broken BootROM implementation for the SPI controller which reads only the first half of every sector (what I have been told). I believe this is fine for SoCs with the headerv2 support in BootROM? Also, we allow different location on storage medium depending on whether it's eMMC/SD or SPI (we use that on RK3399 Puma for example, which has a "small" SPI-NOR). Considering Rockchip builds that USB loader (the one passed to
Got it. So, to come clean. I'm currently investigating labgrid for automating U-Boot testing as this is quickly growing out of proportions with everything I need to test. One of the things I need to test is a fallback mechanism for U-Boot itself. Basically, U-Boot TPL+SPL written to medium A, U-Boot proper written to medium B, U-Boot environment loaded from medium B. I have three storage media (not counting USB booting a whole U-Boot though that would be neat for manufacturing stage), so that makes a decent matrix of tests to run :) I'm not asking you to support this use-case, just asking you to try to think about not making it impossible (I am not saying you're suggesting something that is making it impossible!) I've derailed a bit the conversation from the original topic I believe though. Is there something I can help with/needs to be discussed wrt this PR? |
|
I talked with Quentin on IRC to clarify some things. TL;DR: barebox images are more versatile than U-Boot images and have the necessary format and code to be able to be loaded directly into RAM without an intermediate USB loader (which is the only mode rk-usb-loader supports). U-Boot images aren't there yet and that's why the rkdeveloptool support in Labgrid always flashes the bootloader to persistent media first. This clears up my confusion why the bootstrap code flashes the bootloader instead of just loading it into RAM. More details below.
I think what's meant here is that without a USB loader we are forced to only talk to the BootROM.
I still think so, but now less strongly. Unlike barebox, U-Boot doesn't support being loaded completely in RAM and SPL always searches for U-Boot proper on persistent storage. "RAM boot" is smoething they're interested in, but it's not available yet. So the bootstrap driver should retain the ability to flash the bootloader.
Fastboot and DFU implement custom functions for erasing/flashing and a proper Labgrid driver could make all this available without limiting users to the BootstrapProtocol::load API.
After the discussion, I believe that what rk-usb-loader is doing should be doable for the older SoCs as well. rkdeveloptool itself hasn't changed in 5 years and it didn't have to change to support the newer RK35xxx. So once we add support for RK3399/PX30 to barebox, rk-usb-loader may just work (when adding VID/PID). I'll test this in due time, but it's off-topic here.
It's likely barebox lucked out by not supported these old SoCs and inheriting this quirk.
Not a concern for barebox. The image is one piece.
:)
barebox binaries are fine being loaded to start of DRAM and then relocate away from where TF-A needs to be.
Thanks, I will incorporate feedback and the takeaways from our discussions. There will be no loss of functionality. |
|
A last question remains though @otavio & @QSchulz: The Labgrid driver for the rkdeveloptool doesn't use Other bootstrap drivers boot up the SoC directly after bootstrap finishes, so it would be nice for the Rockchip support to behave the same. |
|
Trying to recap here. IssueIt is currently not possible to have U-Boot reach CLI when loaded through USB. This is an issue as that is what bootstrapping seems to mean in labgrid. We therefore need to flash some persistence storage medium. Booting into a U-Boot shell (Rockchip official way)Working with Rockchip-based device traditionally involves the following:
N.B. on EDIT: moved re-enabling storage medium and unforcing USB mode much earlier in the process as it wasn't required to have it intertwined with Forcing USB modeOn all (to my knowledge) but RK3588 and RK3576, all possible storage media are checked by the BootROM, in a specific order. USB mode for the BootROM is always the last step, if no storage medium has a valid header. This means if your device has a valid header on a storage medium but you want to not boot from it, you need to disable it on the HW level. This was typically done in older designs by cutting either the clock or one of the data lanes going to the eMMC chip and/or SPI flashes. This is required to boot into USB mode for the BootROM and is NOT doable via Note that one also needs to remove any existing SD card as since it's a removable storage medium, it's usually not handled by those "disable internal storage media" HW logic. This could be handled via SDMux drivers in labgrid. I could see this as a non-issue for labgrid, forcing you to put the SDMux device into host mode before bootstrapping the device. For RK3588 and RK3576, the media boot order can be selected by inputting a specific voltage on a specific pin of the SoC's ADC. Wanting to boot from a specific medium at some point, means changing this voltage remotely, so an additional step too is required (unless always ever booting from one method which could be possible only for storage media which are entirely remotely flashable, without any interacting with the device). Re-enabling storage mediumOnly applicable for SoCs whose boot order is not selectable via ADC (so far, RK3588 and RK3576 excluded therefore). Because on older SoCs to enter the USB mode of the BootROM one needs to cut data lanes on the HW level, those storage media whose data lanes are cut do NOT work until those data lanes are "uncut". This involves the opposite step as described in the previous step. Unforcing USB modeMostly only applicable for SoCs whose boot order is selectable via ADC (so far, RK3588 and RK3576). Since it is not required to switch back from the USB-only mode in order to flash the storage medium we want to boot from next, the previous step may not be done. If that is the case, then this step needs to update the voltage to the ADC so that the appropriate boot medium is selected after we reset/power cycle the board. SPI erasingCan only say for SPI-NOR flashes on RK3399. Therefore, the following is necessary:
Additional notesU-Boot has many different binaries for different use cases, to be flashed at different offsets:
The latter are the Offset X is not necessarily the same across devices (the BootROM tries multiple offsets on the same medium), nor it is across flashes on the same device (RK3399 Puma uses offset 0 on SPI-NOR and offset 32K on MMC for example). Offset Y is not necessarily the same across devices as it's configurable via defconfig (RK3399 Puma and PX30 Ringneck for example differ from the Rockchip default, which is also not stable across all SoCs). TPL+SPL is not necessarily identical for all storage media (that is the case for SPI-NOR vs MMC for old SoCs such as RK3399 due to an oddity in the BootROM). N.B.: Here, U-Boot proper is a misnomer as it's actually u-boot.itb which is a fitImage containing U-Boot proper (u-boot.bin) + TF-A (bl31.elf) + OP-TEE (tee.elf) So, in short, it's a mess. Questions/TODO
|
So... this could be fine but I am not sure it is fool-proof. On most Rockchip SoCs (not on RK3588 and seemingly not on RK3576), IOs are divided in blocks. Those blocks are powered externally and may have a different voltage applied at runtime than boot time. A typical example would be for SD cards or eMMC where the voltage could be either 1.8V or 3/3.3V depending on the negotiated speed. This is called IO domains in Rockchip world. The issue is that the IO domain needs to be configured accordingly to the power it receives otherwise a) it damages the SoC or b) it simply doesn't work. The second issue is that this power is not controlled by the SoC, but by the PMIC, which I assume is NOT reset when doing a Note that this isn't a theoretical issue, I can tell you for example that PX30 Ringneck cannot currently boot from SD card after an SoC watchdog reset (which doesn't trigger the PMIC) because the power to the IO domain for the SD controller is not matching the one expected by the IO domain as configured by default. I expect that flashing from U-Boot using one of the SD/eMMC speeds which the standard says operates at 1.8V and then using |
|
Thanks for the summary.
I do it on my RK3399 via GPIOs (
This is already supported via the
I am not sure we want to add this complexity into a Bootstrap driver. I think bootstrap should just start U-Boot and then a separate
This can always go into the strategy and doesn't need to be handled by Labgrid itself.
I also think that's a strategy's business. Different boards have different requirements. |
That's the host tool, I was talking about the target binary. So here I was talking about RKUSBDriver's
Yeah but the issue is "just start U-Boot". We cannot reach the CLI right now with only
Or are you suggesting you're simply planning on doing Essentially, "bootstrap" would simply be "load over USB some bootloader, up to you to know what's next after that"? If that is the case, wouldn't this driver just be a glorified "run this command remotely with this argument" on a USB device checked to be of the vendorID+productID we define in there? Considering that essentially nothing but the file path (which is abstracted) and the vendorId+productId are identical, does it really make sense to only have ONE driver for rkdeveloptool, rk-usb-loader and rockusb? Maybe we should rather have three independent drivers which all inherit from a command one which defines the path to the image and vendorId+productId? [...] I guess maybe I'm misinterpreting E.g. it would be perfectly possible to have a valid header with a completely borked TPL on SPI-NOR and have bootstrap always try to flash eMMC (because that's what's put in the config file). So two things: we expect the user to be able to recover from this on their own by e.g. having another config file with the binaries for flashing/erasing on SPI-NOR, or a specific strategy for that. Or we expect the user to always flash on the storage medium which is looked first by the BootROM and rely on the boot order basically being "USB-only" and "normal mode" to be able to hardcode which one is the medium that is always looked first. I think it now boils down to the expectations of what this bootstrap should actually do and if it needs to be consistent in behavior across bootloaders, SoCs and boards? |
|
So, I'm actually wondering if we shouldn't just remove the ability to flash a bootloader with the If what we want from the Do you have something particular in mind? |
To interact with a Rockchip SoC in BootROM mode over USB, Rockchip
offers the rkdeveloptool, which is among others already packaged in
Debian.
We currently support this via the RKUSBDriver, which binds to the
RKUSBLoader resource, which currently lists a single VID/PID pair.
Actually making use of this is where things get confusing:
Labgrid will look up the rk-usb-loader key to find rkdeveloptool and then
fall back to a binary named
rk-usb-loader. To my knowledge, no one namestheir rkdeveloptool that way and
rk-usb-loaderhas since become thename of the Rockchip USB loader distributed by barebox.
On systems, like the LXA TAC, this is doubly confusing: There's a
rk-usb-loader binary, which Labgrid would use by default, but it's not
compatible with rkdeveloptool, supports only the RK35xx SoCs barebox
supports and is currently not supported by Labgrid at all.
Given that RKUSBLoader only supports a single SoC, our documentation is
wrong (it references the unrelated barebox' rk-usb-loader) and that
our usage of rkdeveloptool goes beyond the BootROM's USB protocol and
additionally flashes persistent media by talking to a first stage
usb_loader that's uploaded first, I think the best course of action
is to rename both the driver and the tool key to reflect that
rkdeveloptool is actually used.
I have yet to test the first (rename) commit, but posting it anyway to get some feedback if the rename is ok.