[PATCH] schemas: Add schema for firmware logs

[Ard Biesheuvel]

On Thu, 9 Feb 2023 at 19:05, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Jan,
>
> On Wed, 8 Feb 2023 at 01:15, Jan Lübbe <jlu at pengutronix.de> wrote:
> >
> > On Tue, 2023-02-07 at 11:39 -0700, Simon Glass wrote:
> > > Hi Jan,
> > >
> > > On Tue, 7 Feb 2023 at 08:39, Jan Lübbe <jlu at pengutronix.de> wrote:
> > > >
> > > > On Tue, 2023-02-07 at 06:38 -0700, Simon Glass wrote:
> > > > > Hi Jan,
> > > > >
> > > > > On Tue, 7 Feb 2023 at 04:56, Jan Lübbe <jlu at pengutronix.de> wrote:
> > > > >
> > [snip]
> > > > > Thanks for the pointer. I had a look at this. How do you deal with
> > > > > updating a filesystem that might be corrupt? Is that even a good idea,
> > > > > if the purpose of it is to collect data from a kernel crash?
> > > >
> > > > This uses only the ramoops "backend" in pstore, so no filesystems are involved.
> > > > If I remember correctly, ramoops in the kernel just discards any data that is
> > > > too corrupted to process. Barebox should behave the same, as the code was ported
> > > > from the kernel.
> > >
> > > Yes...actually I found that U-Boot has pstore too, but it does not
> > > support writing the console into it. I suppose it would be easy
> > > enough, but it seems that U-Boot's pstore is not as advanced.
> > > >
> >
> > > > > We are working on a firmware 'Transfer List' which is a simple data
> > > > > structure to communicate through the different firmware phases. Since
> > > > > U-Boot is the last one, in this case, I suppose it could do the
> > > > > ramoops thing and add files for each of the firmware phases.
> > > >
> > > > For passing logs "forward" to the next step in the boot chain, this should work
> > > > as well and could be more explicit than the ramoops console. One benefit would
> > > > be that keeping the logs from each step separate, right?
> > >
> > > Yes. But we can't use this to pass it to the kernel.
> > >
> >
> > Hmm, because we would need to reserve space for the text memory regions, which
> > couldn't be used by the kernel later?
>
> Because the transfer list does not get passed to the kernel. We don't
> want to invent another way to pass info to Linux, since we already
> have FDT, ACPI and cmdline. In fact I have a horrible suspicion that
> someone added a structured cmdline a bit like an FDT but in text...
>

Yes, the tracing folks in Linux cooked up 'bootconfig' without
involving a single person that was already active in boot
architecture, boot loaders, firmware, etc. I was quite shocked by that
as well.

It seems to be another hierarchical key/value pair store, used for
passing a large set of command line arguments which may otherwise
exceed the maximum length of the kernel command line. It is appended
to the initrd by the boot loader. Android have already started using
it as well.

-- 
Ard.