Hi,
On Tue, Dec 5, 2023 at 3:16 AM Ahmad Fatoum a.fatoum@pengutronix.de wrote:
Hello,
On 04.12.23 18:52, Doug Anderson wrote:> On Sat, Dec 2, 2023 at 8:37 AM Simon Glass sjg@chromium.org wrote:
On Thu, 30 Nov 2023 at 19:04, Ahmad Fatoum a.fatoum@pengutronix.de wrote:
On 30.11.23 21:30, Simon Glass wrote:
On Wed, 29 Nov 2023 at 12:54, Ahmad Fatoum a.fatoum@pengutronix.de 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/hea...
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-dev...
...which pointed at:
https://www.chromium.org/chromium-os/2014-firmware-summit/ChromeOS%20firmwar...
-Doug