[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPnjgZ25xoXsi74XYY0E8ucQiowQqPdZgUHrfVNAYWKZEYODHg@mail.gmail.com>
Date: Wed, 29 Nov 2023 12:02:57 -0700
From: Simon Glass <sjg@...omium.org>
To: Ahmad Fatoum <a.fatoum@...gutronix.de>
Cc: linux-arm-kernel@...ts.infradead.org,
Masahiro Yamada <masahiroy@...nel.org>,
Tom Rini <trini@...sulko.com>,
lkml <linux-kernel@...r.kernel.org>,
U-Boot Mailing List <u-boot@...ts.denx.de>,
Catalin Marinas <catalin.marinas@....com>,
Nathan Chancellor <nathan@...nel.org>,
Nick Terrell <terrelln@...com>,
Nicolas Schier <nicolas@...sle.eu>,
Will Deacon <will@...nel.org>, linux-kbuild@...r.kernel.org,
Pengutronix Kernel Team <kernel@...gutronix.de>
Subject: Re: [PATCH v7 2/2] arm64: boot: Support Flat Image Tree
Hi Ahmad,
On Wed, 29 Nov 2023 at 11:59, Ahmad Fatoum <a.fatoum@...gutronix.de> wrote:
>
> Hi,
>
> a few more comments after decompiling the FIT image:
>
> On 29.11.23 18:21, Simon Glass wrote:
> > + with fsw.add_node('kernel'):
> > + fsw.property_string('description', args.name)
> > + fsw.property_string('type', 'kernel_noload')
>
> The specification only says no loading done, but doesn't explain what it
> means for a bootloader to _not_ load an image. Looking into the U-Boot commit
> b9b50e89d317 ("image: Implement IH_TYPE_KERNEL_NOLOAD") that introduces this,
> apparently no loading means ignoring load and entry address?
>
> I presume missing load and entry is something older U-Boot versions
> were unhappy about? Please let me know if the semantics are as I understood,
> so I can prepare a barebox patch supporting it.
Oh, see my previous email.
>
> > + fsw.property_string('arch', args.arch)
> > + fsw.property_string('os', args.os)
> > + fsw.property_string('compression', args.compress)
> > + fsw.property('data', data)
> > + fsw.property_u32('load', 0)
> > + fsw.property_u32('entry', 0)
> > +
> > +
> > +def finish_fit(fsw, entries):
> > + """Finish the FIT ready for use
> > +
> > + Writes the /configurations node and subnodes
> > +
> > + Args:
> > + fsw (libfdt.FdtSw): Object to use for writing
> > + entries (list of tuple): List of configurations:
> > + str: Description of model
> > + str: Compatible stringlist
> > + """
> > + fsw.end_node()
> > + seq = 0
> > + with fsw.add_node('configurations'):
> > + for model, compat in entries:
> > + seq += 1
> > + with fsw.add_node(f'conf-{seq}'):
> > + fsw.property('compatible', bytes(compat))
>
> The specification says that this is the root U-Boot compatible,
> which I presume to mean the top-level compatible, which makes sense to me.
>
> The code here though adds all compatible strings from the device tree though,
> is this intended?
Yes, since it saves needing to read in each DT just to get the
compatible stringlist.
>
> > + fsw.property_string('description', model)
> > + fsw.property_string('type', 'flat_dt')
> > + fsw.property_string('arch', arch)
> > + fsw.property_string('compression', compress)
> > + fsw.property('compatible', bytes(compat))
>
> I think I've never seen a compatible for a fdt node before.
> What use does this serve?
It indicates the machine that the DT is for.
Regards,
Simon
Powered by blists - more mailing lists