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. >> +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? Thanks, Ahmad > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
