On Fri, Oct 18, 2024 at 08:57:02AM -0600, Simon Glass wrote:
Hi Tom,
On Thu, 17 Oct 2024 at 21:14, Tom Rini trini@konsulko.com wrote:
On Thu, Oct 17, 2024 at 05:23:54PM -0600, Simon Glass wrote:
Add an image type for the extlinux.cfg file, which U-Boot supports reading.
Signed-off-by: Simon Glass sjg@chromium.org
boot/image.c | 1 + include/image.h | 1 + 2 files changed, 2 insertions(+)
diff --git a/boot/image.c b/boot/image.c index abac254e026..cf16fb7fbf7 100644 --- a/boot/image.c +++ b/boot/image.c @@ -183,6 +183,7 @@ static const table_entry_t uimage_type[] = { { IH_TYPE_FDT_LEGACY, "fdt_legacy", "legacy Image with Flat Device Tree ", }, { IH_TYPE_RENESAS_SPKG, "spkgimage", "Renesas SPKG Image" }, { IH_TYPE_STARFIVE_SPL, "sfspl", "StarFive SPL Image" },
{ IH_TYPE_EXTLINUX_CFG, "extlinux_cfg", "Extlinux configuration" }, { -1, "", "", },};
This whole part of the series feels like we're abusing IH_TYPE_ far past what it's used for. Especially the command line string one. It seems like the main use is to be able to later on print something human friendly. Please try and figure out some other way to do that. Thanks.
Yes I had the same thought, particularly with cmdline, as you say.
The obvious alternative is to just have a string which communicates the type. Then I can use IH_TYPE_INVALID, perhaps, with an extra string indicating what it really is.
But one advantage of the approach in this patch is that, for bootmeths which include a cmdline, it can be identified and added as a file. That includes zimage and ChromiumOS, but not EFI. It will allow me to get rid of the cmdline in struct bootflow, perhaps.
Yeah, this all sounds like IH_TYPE is the wrong direction to expand. Where you're grabbing these things from is where you might get a hint as to what these things are and that's where to take the store the knowledge for later.