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/79030a486128bdb6888059113711a6.... 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