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

[Johan Jonker]

On 7/25/22 13:05, Xavier Drudis Ferran wrote:
> 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.
> 

The pattern for NAND depends on the chip. Have NOT found a good logic for lsb modes other then a lookup list.
No need for a 3rd image as idbloader.img contains everything (header/TPL/SPL/RC4 support) for further processing elsewhere.

Johan