On 08/12/2021 12:31, Peter Robinson wrote: > I thought there was a different process for the chtomebooks than the > usual rockchip route. Do the rockchip chomebooks support writing to a > space in SPI and chainloading like some of the other arm chtomebooks > did (I think tegra/samsung but my memory fades there)? I think it > would be useful to document the rockchip chromebook options somewhere > so that people that are interested in using the U-Boot option have > some resources, we've had a few queries over the time around that.
What I usually do is exactly that, chainloading from an SPI region called RW_LEGACY. This is the predecessor of the 'altfw' feature mentioned in doc/chromium/overview.rst, there's a link there that leads to some information about this as well. In short it goes like this: - Build U-Boot with CONFIG_OF_EMBED=y (or do some objcopy/elfedit magic to merge dtb into u-boot ELF) - cbfstool "u-boot.cbfs" create -s "$((2 * 1024 * 1024))" -m arm64 - cbfstool "u-boot.cbfs" add-payload -f "u-boot" -n payload -c lzma - dd if="u-boot.cbfs" of="u-boot.cbfs.rom" bs=2M seek=3 count=1 - sudo flashrom -p linux_mtd --fmap -i RW_LEGACY -w "u-boot.cbfs.rom" - Reboot and press CTRL+L on Chrome OS developer mode screen There's also the doc/chromium/chainload.rst process which packs U-Boot as if it's the Chrome OS kernel on a disk. I couldn't manage to boot U-Boot that way, but I somewhat automated that process with binman. I think I can automate the RW_LEGACY image as well but haven't tried it. I could document what I know as is, but wanted to do it after I get those files automated during upstream build, as things should be quite simple after that.
