RKUSBDriver: allow to specify the offset at which the image should be flashed

[QSchulz]

Description

RKUSBDriver flashes an image onto a storage medium. Typically, on eMMC the starting offset is 0x40 (i.e. 64 blocks of 512KiB, iow 32KiB) to leave enough room for a partition table before but it doesn't have to. Barebox's update mechanism (bbu/CONFIG_BAREBOX_UPDATE) specifies multiple possible offsets for Rockchip: 0x40 to 0x44[1].

Additionally, it is possible (on RK3399 at the very least) to have the first stage bootloader at offset 0 on SPI-NOR flashes. This is currently the choice made for Theobroma Systems's Puma RK3399 SoM in U-Boot.

Let's give the user the ability to provide an offset from the configuration file.

[1] https://github.com/barebox/barebox/blob/master/arch/arm/mach-rockchip/bbu.c#L19-L24

Checklist

• The arguments and description in doc/configuration.rst have been updated
• PR has been tested

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 55.6%. Comparing base (4398da7) to head (d209eca).

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@          Coverage Diff           @@
##           master   #1703   +/-   ##
======================================
  Coverage    55.6%   55.6%           
======================================
  Files         172     172           
  Lines       13471   13472    +1     
======================================
+ Hits         7500    7501    +1     
  Misses       5971    5971           

Flag	Coverage Δ
3.10	55.6% <100.0%> (+<0.1%)	⬆️
3.11	55.6% <100.0%> (+<0.1%)	⬆️
3.12	55.6% <100.0%> (+<0.1%)	⬆️
3.13	55.6% <100.0%> (+<0.1%)	⬆️
3.9	55.7% <100.0%> (+<0.1%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jluebbe]

Hmm, the BootstrapProtocol shouldn't flash anything, just load to RAM and execute. Isn't that possible for RockChip?

Flashing protocols are often more complex, which is why AndroidFastbootDriver and DFUDriver don't use a common protocol.

[QSchulz]

Hmm, the BootstrapProtocol shouldn't flash anything, just load to RAM and execute.

That's the case today though, https://github.com/labgrid-project/labgrid/blob/master/labgrid/driver/usbloader.py#L141-L145 does that, c.f. https://github.com/rockchip-linux/rkdeveloptool/blob/master/main.cpp#L51

Isn't that possible for RockChip?

No, but yes.

You enter USB mode uploading in BootROM (MaskROM button pressed while resetting for example, or holding all flashed boot media in reset). Then you upload a binary to volatile memory with rkdeveloptool/rockusb/whatever, c.f. https://github.com/rockchip-linux/rkdeveloptool/blob/master/main.cpp#L48. (It's actually two binaries, one into SRAM via 0x471 and one into DDR via 0x472 once the binary executed from SRAM has returned to BootROM I believe).

For now the db file is still a blob from Rockchip from their rkbin repo, there have been patches sent to upstream U-Boot for generating a binary that allows to upload TPL and SPL via this tool and then start rockusb/dfu/fastboot to upload the rest (U-Boot proper FIT I believe). I am not sure if we can flash from the SPL via dfu/fastboot but I guess we could.

In any case, regardless of the binary, this wouldn't be enough to reach U-Boot CLI as far as I know (haven't tested on upstream U-Boot). This differs from barebox as far as I've been told?

So you then need to communicate with the db binary over another protocol, typically RockUSB protocol with the blob or upstream, but can be DFU/fastboot for upstream as far as I know.

Flashing protocols are often more complex, which is why AndroidFastbootDriver and DFUDriver don't use a common protocol.

We would still need (for U-Boot at least) to upload another binary (U-Boot proper FIT) once running the SPL to reach a CLI and be able to boot into Linux I guess? I guess this would be part of RKUSBDriver and we would have another class for flashing?