Re: [PATCH v2] char drivers: Ram oops/panic logger
Il 13/03/2010 00:31, Jamie Lokier ha scritto: 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 I agree, but the bootloader should be aware of it. I mean, usually bootloaders at boot, reset the RAM, so you have to tell to the bootloader that you are using a piece of RAM as persistent RAM, for example U-Boot has got a specific option CONFIG_PRAM. I don't know if all the process can be completely transparent to the admin in all situations. Marco -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] char drivers: Ram oops/panic logger
Il 12/03/2010 23:48, Andrew Morton ha scritto: On Wed, 10 Mar 2010 13:15:25 +0100 Marco Stornelli marco.storne...@gmail.com wrote: 2010/3/10 Yuasa Yoichi yu...@linux-mips.org: 2010/3/10 Marco Stornelli marco.storne...@gmail.com: 2010/3/10 Yuasa Yoichi yu...@linux-mips.org: 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? Yes. 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? For my test I used the program devmem2 to dump the log. In general, you can read the memory via /dev/mem. There's an header plus a timestamp of the log. The memory is initialized with blank spaces and the size of the record is fixed at 4k, so if a program/script doesn't find the header at next 4k, it means there's garbage and it can stop the read operation. 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. Yes, it can be an option. My first idea was to write a general driver, with an address in input that it can be related to the reserved RAM as an NVRAM in the system, however it can be a good idea, why not. Marco -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] char drivers: Ram oops/panic logger
On Fri, Mar 12, 2010 at 23:48, Andrew Morton a...@linux-foundation.org wrote:
On Wed, 10 Mar 2010 13:15:25 +0100
Marco Stornelli marco.storne...@gmail.com wrote:
2010/3/10 Yuasa Yoichi yu...@linux-mips.org:
2010/3/10 Marco Stornelli marco.storne...@gmail.com:
2010/3/10 Yuasa Yoichi yu...@linux-mips.org:
Hi,
2010/3/10 Marco Stornelli marco.storne...@gmail.com:
Ramoops, like mtdoops, can log oops/panic information but in RAM.
What is different from mtdoops + mtd-ram?
Yoichi
It can be used in a very easy way with persistent RAM for systems
without flash support. For this systems, with this driver, it's no
more needed add to the kernel the mtd subsystem with advantage in
footprint as I said in the description.
right.
But,
In addition, you can save
flash space and store this information only in RAM. I think it's very
useful for embedded systems.
CONFIG_MTD_RAM uses only RAM.
I think there's no big difference about this point.
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?
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?
On Amiga, `debug=mem' enables something like that, cfr. git grep dmesg
arch/m68k.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
