Support same log buffer or tracing buffer in both bootloader and kernel

Revision as of 21:19, 16 May 2012 by Hisaomunakata (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Support same log buffer or tracing buffer in both bootloader and kernel
Tim Bird - Sony Network Entertainment


It would be nice to share log buffer or trace buffers between the bootloader and the kernel, so that either log messages or trace events (respectively) could be coalesced from both sources in a unified view.

This work might be related to work involving using fixed memory locations for kernel buffers. This is done implicitly by Android's RAM-console feature, and by PRAMFS. Alternatively, if performance is not an issue, the kernel could copy messages from the bootloader log buffer into the kernel log buffer at startup.

It appears that U-boot uses a log-buffer format similar to the Linux kernel. (See;a=blob;f=common/cmd_log.c

Note that this is useful for on-box analysis (using 'dmesg' locally, and getting both bootloader and kernel messages). It is obvious that someone with a serial console can see both sets of text messages coalesced, and could use a tool like to get timing information for the text messages. (Although, due to delays in setting up the kernel console device, the timings are inaccurate for a portion of the bootup.)

Handling trace events in a coalesced fashion is a whole other issue.

Related work

  • In 2009 there was a proposal to add an "alternative log buffer" for printk messages
  • Does u-boot support any tracing code similar to ftrace?



Contractor Candidates

No one so far.