On Fri, Jan 06, 2012 at 08:28:51AM -0800, Olof Johansson wrote:
> On Thu, Jan 5, 2012 at 11:22 PM, Mitch Bradley <w...@firmworks.com> wrote:
> >
> > On 1/5/2012 6: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?
> >
> >
> > If it is addressable, it should appear as a device node underneath the node
> > that creates the address space in which it appears, and the start and size
> > should be described by a "reg" property.
>
> A yes, of course.
>
> I got on the wrong track due to the lack of use of resources in the
> linux platform_driver.
But you still need some ramoops specific configuration though right?
Could this be represented with a generic binding for the onchip RAM as
has already proposed then inside the chosen node something like:
chosen {
ramoops {
linux,ramoops-record-size = <12>;
linux,ramoops-include-oopses = <1>;
/* phandle to ram, offset, size */
linux,ramoops-ram = <&iram 0x1000 0x200>;
};
};
to decouple the runtime configuration from the hardware binding?
Jamie
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
