On Mon, 2023-02-06 at 17:32 -0600, Rob Herring wrote:
+boot-architecture
On Mon, Feb 6, 2023 at 3:25 PM Simon Glass sjg@chromium.org wrote:
Hi Rob,
On Mon, 6 Feb 2023 at 10:15, Rob Herring robh@kernel.org wrote:
On Sat, Feb 4, 2023 at 6:04 AM Simon Glass sjg@chromium.org wrote:
Hi Peter,
On Sat, 4 Feb 2023 at 02:36, Peter Robinson pbrobinson@gmail.com 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.
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.
This is basically how it works in Barebox. It can display the pstore contents after a kernel crash and also (optionally) log to the pstore/ramooms console log. Slight RAM corruption can be handled by using error correcting codes.
It's not perfect, of course, but still very useful.
Regards, Jan
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.