Hi Rob, On Mon, 6 Feb 2023 at 16:32, Rob Herring <robh@xxxxxxxxxx> wrote: > > +boot-architecture > > On Mon, Feb 6, 2023 at 3:25 PM Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > > > Hi Rob, > > > > On Mon, 6 Feb 2023 at 10:15, Rob Herring <robh@xxxxxxxxxx> wrote: > > > > > > On Sat, Feb 4, 2023 at 6:04 AM Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > > > > > > > Hi Peter, > > > > > > > > On Sat, 4 Feb 2023 at 02:36, Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > Does it make sense to devise something that is compatible with the > > > > > kernel's pstore [1] mechanism? > > > > > > > > Possibly...can you please be a little more specific? > > > > > > Peter is talking about the same thing I suggested on IRC. > > > > > > pstore == ramoops > > > > Oh, I only looked at the DT binding as I thought that was what you > > were talking about on irc. > > The binding is called ramoops as it's for the RAM backend for pstore. > > My suggestion was either using/extending ramoops or following its > design as a reserved memory region. All you would need to extend the > ramoops binding is a new property to define the size of your data. OK I see. > > > For pstore, isn't the point that Linux wants to save stuff to allow > > debugging or collection on reboot? What does that have to do with > > console logs from firmware? That seems like a different thing. Or are > > you suggesting that we add a pstore driver into U-Boot? It is quite a > > lot of code, including compression, etc. It might be easier for Linux > > to write the data into pstore when it starts up? > > Originally ramoops was just what you described. It has grown to > multiple backends and types of records (hence the rename to pstore). > If you just add a new subsection within the pstore region, then I > think the existing kernel infrastructure will support reading it from > userspace. Maybe new types have to be explicitly supported, IDK. > > U-boot being able to read pstore wouldn't be a terrible feature to > have anyways if your boot crashes before anything else is up to get > the output. Note I'd guess the ram backend doesn't do compression as > supporting slightly corrupted ram is a feature which wouldn't work. I actually meant U-Boot writing to pstore...as that is the only way that the console data could be provided to the kernel, as I understand it. Another question is how U-Boot could write thie information if the pstore backend is not RAM? > > > I think any new DT binding is premature and pstore/ramoops was just a > suggestion to consider. This needs wider consideration of how to > handle all the various (boot) firmware logs. I've added the > boot-architecture list for a bit more visibility. OK. Regards, SImon
