Passing boot logs to Linux?

[Daniel Golle]

On Thu, Dec 21, 2023 at 12:55:20AM +0100, Dragan Simic wrote:
> On 2023-12-21 00:27, Csókás Bence wrote:
> > Not every system has eMMC/uSD, and as you said, these arguments don't
> > hold for a 4 MB SPI NAND, for example, one you might find in an OpenWrt
> > router for example. Whereas RAM is quite cheap nowadays.
> 
> I see, but I also wonder how many such OpenWrt routers are still used these
> days, and, even more importantly, how many of them are regularly updated and
> can be expected to actually use this new feature?

Avoid flash writes is a very important matter, even on systems with
128 MiB of SPI-NAND flash which is by far the most common setup you
find on off-the-shelf plastic routers and access points nowadays.

Especially also as those devices often come without a local console,
having U-Boot's output prepended to dmesg on boot would be a very big
win.

> 
> Please, don't get me wrong, I still support having both options available,
> but I'm also wondering about the target demographic.
> 
> > > > Plus, I don't want the console subsystem to depend on any file/disk
> > > > operations/drivers.
> > > 
> > > Well, the console would still work as usual even if logging to disk
> > > would fail for any reason, which is similar to the serial console
> > > still
> > > working if the graphical console fails.  Moreover, if the disk fails,
> > > the system isn't be able to boot, so any RAM-based console logs
> > > would be
> > > lost in that case.  All this makes the RAM-based logging no more
> > > resilient to disk failures.
> > 
> > Correction: if disk *reads* fail, as well as writes, then the system
> > will not boot. However, typical failure of Flash media is that it
> > becomes read-only.
> 
> That's a good point, but having a read-only root filesystem usually also
> means having a non-operational system that can only have its stored data
> salvaged.  Unless the system is specifically crafted to survive such
> scenarios, of course.

... which holds true for any decent embedded OS, which at least allows
limited remote access and some kind of recovery even in this situation.

> 
> > > I still think that using disk-based pstore is a better option.  Just
> > > as
> > > you don't want to wear out your flash disks with 30-40 KB of data, I
> > > also don't want to waste 30-40 KB of RAM.
> > 
> > As I said, you could just unload the log after you're done processing
> > it. 40 KB RAM is less, than what `sshd` uses, for instance (860k on my
> > laptop, but it can probably be less, maybe even 10x less, so 80-90k?),
> > so you could, in your init, process the in-RAM log, then unload it, then
> > start your other services, thereby reclaiming that RAM.
> 
> Using pstore should have that unloading already covered, and the already
> existing systemd service is there to perform the archiving to the primary
> filesystem, if desired so.  It would all need to be tested in detail, of
> course.

pstore/ramoops uses a statically assigned reserved memory region, so in
the moment you want to use that feature you loose that amount of RAM (a
few kB, so it doesn't really matter on modern systems).
As in: there is *no* dynamic allocation.

Imho using pstore/ramoops (which is a more or less Linux-specific
debugging feature, meant to store one or more timestamped logs of
crashes) might not be the most suitable choice. I understand the
advantages of using existing infrastructure, but on the other hand
we don't need most of the complexity of pstore for the task.

What I'd like to see is having a couple of log lines from U-Boot
prepended to Linux' dmesg buffer, and for that we anyway will have to
come up with a way to hand over that buffer. Another reserved-memory
region would be one way, embedding the buffer as a blob into the
/chosen/ section of the device tree would be another way.