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

From eLinux.org
Revision as of 05:18, 17 May 2012 by Hisaomunakata (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Summary
Support same log buffer or tracing buffer in both bootloader and kernel
Proposer
Tim Bird - Sony Network Entertainment

Description

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 http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;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 http://elinux.org/Grabserial 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?

Scope

Unknown

Contractor Candidates

No one so far.

Comments