[YBA] new kernel ramoops feature anyone?

[Baruch Siach]

Hi Yonatan,

On Tue, Oct 02, 2012 at 01:22:10PM +0200, Jonathan Ben Avraham wrote:
> Dear colleagues,
> I am working on a patch that adds a new feature to the ramoops
> kernel feature.
> 
> The patch is an extension of the current ramoops facility, see
> http://lwn.net/Articles/377890/.
> 
> The patch adds a platform-specific reservation of ramoops memory in
> early boot, so that the ramoops area can be:
> 
> a) at a constant physical RAM address
> b) guaranteed never to be overwritten by the kernel or userspace
> (other than by the ramoops driver that is)
> 
> 
> These two features mean that even for volatile RAM, as long as:
> 
> a) power is maintained
> b) the bootloader does not clear the RAM
> c) subsequent reboots use kernels that have the new feature and
> define the ramoops area at the same RAM address
> 
> then the contents of the ramoops memory is preserved through reboot
> and you can recover the contents of an oops or panic dump that
> happened before the reboot. In fact, you can even log arbitrary data
> in RAM accross reboots.
> 
> 
> Why do you need this great feature so badly?
> 
> You need this feature to help you debug or to monitor various
> drivers and kernel features that oops or panic while in interrupt
> context or on boards where there is no other candidate memory mapped
> device to write to, (i.e. no available NVRAM, no FLASH or no free
> FLASH) and there is no way to write to a device that might be
> protected by a lock or a mutex, such as a write to an EEPROM from
> interrupt context.
> 
> From your experience, does this feature have a chance of being
> accepted into the mainline kernel if implemented for ARM and PPC?

In the light of a recent discussion at the celinux-dev list 
(http://thread.gmane.org/gmane.linux.embedded.celinux.devel/261) I think that 
the celinux-dev list is an appropriate place for this and other embedded Linux 
related questions/discussions.

Specifically, the ramoops module has the "mem_size" and "mem_address" module 
parameter (i.e., you need to set ramoops.mem_size and ramoops.mem_address in 
the kernel command line) that seems to do exactly what you need. Currently, 
ramoops doesn't use the early boot memblock mechanism, so if this code doesn't 
run early enough at boot time, buffer allocation may fail. Adding an 
early_param() to the global kernel parameters namespace and calling 
memblock_reserve() from there might solve the issue. See the 
drivers/video/omap2/vram.c "vram" early_param for an example.

In general, I think that a platform neutral implementation (not ARM or PowerPC 
specific) would greatly increase the chances of any feature being adopted 
upstream.

Just my 2c.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -