Device tree bindings for linux ramoops use

[Rob Herring]

On 01/05/2012 10:39 PM, Olof Johansson wrote:
> Hi,
> 
> I'm considering how to best describe the data that ramoops needs in
> the device tree.
> 
> The idea is really about describing a memory area that is (likely to
> be) nonvolatile across reboots. Said area is not to be included in the
> regular memory map of the system (i.e. not covered by /memory).
> 
> I have a few options on where to do it. It's not really a hardware
> device per se, so it's a gray area for the device tree alltogether.
> 
> How about something like?
> 
> compatible = "linux,ramoops"
> linux,ramoops-start = <start address of preserved ram>
> linux,ramoops-size = ...
> linux,ramoops-record-size = ...
> linux,ramoops-include-oopses = ... (this one is a bit of a corner
> case, it's truly a software setting -- probably leave it out)
> 
> Anybody have a better idea?

Since all those settings are already settable on the kernel command as
module parameters, can't you use that? Perhaps we need the bootloader to
append cmd line options rather than replace as I think u-boot does.

There is a need for a (typically) on-chip RAM binding which then gets
carved up into multiple uses. These could be properties of the RAM binding.

Rob

> I could do a platform-specific binding that describes the nonvolatile
> ram area as a separate "device", and then have some platform code that
> translates that into the ramoops platform pdata parameters (since it
> can't really be assumed that ramoops has ownership of the whole
> area/device). That seems pretty awkward too though, and I'm not sure
> it buys us a whole lot.
> 
> 
> -Olof
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss