Hi, On Tue, Dec 5, 2023 at 3:16 AM Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > > Hello, > > On 04.12.23 18:52, Doug Anderson wrote:> On Sat, Dec 2, 2023 at 8:37 AM Simon Glass <sjg@xxxxxxxxxxxx> wrote: > >> On Thu, 30 Nov 2023 at 19:04, Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > >>> On 30.11.23 21:30, Simon Glass wrote: > >>>> On Wed, 29 Nov 2023 at 12:54, Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > >>>>> On 29.11.23 20:44, Simon Glass wrote: > >>>> I don't have an example to hand, but this is the required mechanism of > >>>> FIT. This feature has been in place for many years and is used by > >>>> ChromeOS, at least. > >>> > >>> I see the utility of a FIT configuration with > >>> > >>> compatible = "vendor,board-rev-a", "vendor,board-rev-b"; > >>> > >>> I fail to see a utility for a configuration with > >>> > >>> compatible = "vendor,board", "vendor,SoM", "vendor,SoC"; > >>> > >>> Any configuration that ends up being booted because "vendor,SoC" was matched is > >>> most likely doomed to fail. Therefore, I would suggest that only the top level > >>> configuration is written into the FIT configurations automatically. > >> > >> Firstly, I am not an expert on this. > >> > >> Say you have a board with variants. The compatible string in U-Boot > >> may be something like: > >> > >> "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron", > >> "rockchip,rk3288"; > >> > >> If you then have several FIT configurations, they may be something like: > >> > >> "google,veyron-brain-rev0", "google,veyron-brain", "google,veyron", > >> "rockchip,rk3288"; > >> "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron", > >> "rockchip,rk3288"; > >> "google,veyron-brain-rev2", "google,veyron-brain", "google,veyron", > >> "rockchip,rk3288"; > >> > >> You want to choose the second one, since it is a better match than the others. > > Now imagine, you are building a kernel that has no DT support for the Veyron, > but instead has support for the Phytec RK3288 PCM-947: > > phytec,rk3288-pcm-947", "phytec,rk3288-phycore-som", "rockchip,rk3288 > > As far as I understand U-Boot code, A veyron U-Boot would boot the Phytec DT > if CONFIG_FIT_BEST_MATCH is set, although it's a bad match and a boot failure > should rather have occurred. On depthcharge the bootloader never matches on just a SoC name. > >> +Doug Anderson who knows a lot more about this than me. > > > > Hopefully this is all explained by: > > > > https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html > > Thanks Doug, this was helpful. The missing information to me was that > depthcharge only compares the top-level board compatible in addition > to runtime generated board compatibles, unlike what U-Boot seems to do. > > barebox only compares its top-level compatible against the FIT configuration > compatibles, so adding a full compatible list to the configuration nodes as done > by this series should be ok there as well. I think U-Boot could run into > issues though as described above. > > Out of curiosity: I only heard about Depthcharge before as exploitation toolkit > for U-Boot. Can you point me at some documentation on what the Depthcharge bootloader > does what U-Boot (which was presumably used before?) doesn't? I can only assume that the depthcharge you're talking about is different. The one used by Chromebooks is basically: https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/main I assume you're asking: why are we using depthcharge in ChromeOS instead of U-Boot? There was much discussion about this back in the day. From what I recall, part of the reason was that folks wanted the boot flow to be a bit more standard between x86 Chromebooks and ARM Chromebooks. x86 Chromebooks were using coreboot for the initial hardware booting and then needed a 2nd stage to actually load Linux and ended up creating depthcharge. ...and then we switched to the same model for ARM boards. I didn't personally make that decision and I'm also not on the firmware team, so that's about all I'll say on the topic. ;-) Oh, hmmm. Searching found me: https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/custom-firmware/ ...which pointed at: https://www.chromium.org/chromium-os/2014-firmware-summit/ChromeOS%20firmware%20summit%20-%20Depthcharge.pdf -Doug
