Re: [PATCH 3/3] arm64: boot: Support Flat Image Tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 31, 2023 at 04:03:18PM +0900, Masahiro Yamada wrote:
> On Tue, Oct 31, 2023 at 1:12 AM Tom Rini <trini@xxxxxxxxxxxx> wrote:
> >
> > On Mon, Oct 30, 2023 at 03:35:34PM +0000, Russell King (Oracle) wrote:
> > > On Sun, Oct 29, 2023 at 05:46:12AM +1300, Simon Glass wrote:
> > > > Hi Masahiro,
> > > >
> > > > Sure, but that is a separate issue, isn't it? We already support
> > > > various boot targets in arm64 but not one that includes the DTs, so
> > > > far as I can see. The old arm 'uImage' target is pretty out-of-date
> > > > now.
> > >
> > > Does that mean it can be removed? ;)
> > >
> > > I've NAK'd FIT support on 32-bit Arm in the past, and I remain of the
> > > opinion that boot loader specific packaging of the kernel should not
> > > be in the kernel but should be external to it - even more so given the
> > > multi-platform nature of 32-bit Arm kernels.
> >
> > I'll point it out here rather than Simon. As part of
> > https://github.com/open-source-firmware FIT is a standard and not "boot
> > loader specific". And one of the points of a FIT image is that you can
> > easily support multi-platform kernels in a single file (without
> > optimizing things further, at a cost in tens of milliseconds on a Pi 3
> > anyhow) and with user-controlled security.
> >
> > --
> > Tom
> 
> 
> 
> It is a copy of the document in U-Boot.
> 
> The file was split into two, but the content is the same.
> 
> 
> [original in U-Boot]
> https://github.com/u-boot/u-boot/blob/v2023.10/doc/usage/fit/source_file_format.rst
> 
> 
> [flat-image-tree]
> https://github.com/open-source-firmware/flat-image-tree/blob/v0.8/source/chapter1-introduction.rst
> https://github.com/open-source-firmware/flat-image-tree/blob/v0.8/source/chapter2-source-file-format.rst

Yes, it would have been a bad idea to change a 15 year old format as
part of getting it included in some standards, and we'd also recently
cleaned it up to rST. Similar comments would I expect be true of turning
grub.cfg in to extlinux.conf and all of the organizations that has moved
along, and anything else that wasn't developed by committee at some
Standards organization.

-- 
Tom



[Index of Archives]     [Linux&nblp;USB Development]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite Secrets]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux