Re: Device tree bindings for linux ramoops use

On 1/6/2012 6:33 AM, Olof Johansson wrote:

Hi,

On Fri, Jan 6, 2012 at 5:25 AM, Rob Herring[off-list ref]  wrote:

quoted

On 01/05/2012 10:39 PM, Olof Johansson wrote:

quoted

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.

I'm not so sure that's a good idea. The command line will snowball
into a 2KB string pretty quickly if we start doing that. It's already
crazy long on our systems here.

quoted

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.

Sounds like describing it in a separate memory node is a good start,
and then possibly partitions underneath there.

So, even for the case of nonvolatile-memory, it could be done with a
device node in parallel with the memory nodes on the system, and then
possibly the ramoops node underneath of there. For iram, similarly the
main iram range is covered by the iram device node, and if you need to
partition it further, do it with subnodes similar to how mtd bindings
work. Sounds reasonable, no?

Yes.  That is exactly what I do for memory mapped FLASH.  One or more 
top-level (child of the root) nodes describe all of the addressable 
FLASH.  Then subordinate nodes describe partitions that are used for 
specific purposes.

If there are multiple identical FLASH chips that are treated as a 
combined space, it sometimes makes sense to have a single top-level 
FLASH node, as with /memory, instead of multiple nodes.

-Olof
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss