[PATCH v2 1/7] rockchip: generate idbloader.img content for u-boot-rockchip.bin with binman for ARM

[Xavier Drudis Ferran]

Note: I removed a few recipients from Cc: with a quite random criteria, 
just to avoid error messages from the list software that there were 
too many addresses in Cc:. I hope those will get it from the list anyway
and sorry if this is a problem.

 
> I'm sure I'm just missing out on something obvious but cannot find it right
> now.
> I have an issue with the assumption of what u-boot-rockchip.bin is supposed
> to be. What does it actually represent?
> 
> I have three possible boot media on my board: SPI-NOR, eMMC and SD Card.
> Both MMC devices can use the same offsets and images, so that's fine for me
> to have something like u-boot-rockchip-mmc.bin.
> However, SPI-NOR has a different offset for U-Boot proper than MMC devices.
> It would be ridiculous to have two defconfigs with the only difference being
> the value of SPL_PAD_TO option. Hence why there's a u-boot-rockchip-spi.bin
> image now and also why I argue in this patch series that using SPL_PAD_TO is
> incorrect. I replaced SPL_PAD_TO with the formula that was originally used
> to define the padding, see https://source.denx.de/u-boot/u-boot/-/commit/79030a486128bdb6888059113711a6ae66ff89c5.
> I understand this change is not ok, but I cannot use SPL_PAD_TO either. I
> would like to have some opinion/answer on what I asked in the paragraph
> above.

The difference between u-boot-rockchip-mmc.bin and
u-boot-rockchip-spi.bin is not only the offset. The image for SPI has
the parts loaded by bootrom (tpl and spl) written in 8Kb chunks
separated by 8Kb empty space (or something like this, I don't
remember). That's why there are different -T rksd and -T rkspi
options to mkimage. This is so at least for RK3399.

I have no idea whether nand images need this special format or not, 
or whether it depends on the SoC model or what. If it's only the 
offset, then maybe we can avoid a 3rd image and reuse the MMC one. 
I don't know.