Andrew Morton wrote: > > I meant with the "classic" use of mtdoops, therefore with a flash > > partition without use MTD_RAM. Using MTD_RAM, it's more or less the > > same thing, with the exception of "where" you want deploy the log. For > > example: if in your system you have got a nvram you can use it without > > problem, you need to specify the address of the nvram to the module. > > Very simple. I think it's a small driver but very useful, feedback > > from other embedded guys are welcome. > > Seems sensible to me. If you have a machine whose memory is persistent > across reboots then you reserve an arbitrary 4k hunk of memory for > collecting oops traces, yes? Me too, I think it's a great idea which sounds simpler to use than MTD-RAM. > What tools are used for displaying that memory on the next boot? How > do those tools distinguish between "valid oops trace" and "garbage > because it was just powered on"? A magic signature? > > Should the kernel provide the 4k of memory rather than (or in addition > to) requiring that the system administrator reserve it and tell the > kernel about it? That'd be a matter of creating a linker section which > isn't cleared out by the startup code. It's good if there's an option to make the location not vary between kernels, and be known to the bootloader. Then you can debug kernels which always crash during boot, by either booting into another kernel which works and looking at the oops, or by a bootloader command to dump it. That'd be fine if the kernel link scripts choose the address, as long as it's consistent between different compiles and similar configurations. That'd be a bit simpler than the admin having to know the memory map well enough to choose an address. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
