Device tree bindings for linux ramoops use

Device tree bindings for linux ramoops use

[Olof Johansson]

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?

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

Re: Device tree bindings for linux ramoops use

[Mitch Bradley]

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.

>
> 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-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>

Re: 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-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Device tree bindings for linux ramoops use

[Olof Johansson]

On Thu, Jan 5, 2012 at 11:22 PM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 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.


-Olof

Re: Device tree bindings for linux ramoops use

[Olof Johansson]

Hi,

On Fri, Jan 6, 2012 at 5:25 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 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.

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.


> 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?


-Olof

Re: Device tree bindings for linux ramoops use

[Mitch Bradley]

On 1/6/2012 6:33 AM, Olof Johansson wrote:
> Hi,
>
> On Fri, Jan 6, 2012 at 5:25 AM, Rob Herring<robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>  wrote:
>> 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.
>
> 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.
>
>
>> 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
>

Re: Device tree bindings for linux ramoops use

[Jamie Iles]

On Fri, Jan 06, 2012 at 08:28:51AM -0800, Olof Johansson wrote:
> On Thu, Jan 5, 2012 at 11:22 PM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 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

Re: Device tree bindings for linux ramoops use

[Olof Johansson]

On Fri, Jan 6, 2012 at 8:58 AM, Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org> wrote:
> On Fri, Jan 06, 2012 at 08:28:51AM -0800, Olof Johansson wrote:
>> On Thu, Jan 5, 2012 at 11:22 PM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 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?

Only the ramoops-include-oopses is really the runtime configuration,
so that alone in /chosen could be a good idea. But I would rather have
the "partition" described as a device with a compatible field that the
driver can bind against.


-Olof

Re: Device tree bindings for linux ramoops use

[Jamie Iles]

On Fri, Jan 06, 2012 at 09:47:22AM -0800, Olof Johansson wrote:
> On Fri, Jan 6, 2012 at 8:58 AM, Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org> wrote:
> > On Fri, Jan 06, 2012 at 08:28:51AM -0800, Olof Johansson wrote:
> >> On Thu, Jan 5, 2012 at 11:22 PM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 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?
> 
> Only the ramoops-include-oopses is really the runtime configuration,
> so that alone in /chosen could be a good idea. But I would rather have
> the "partition" described as a device with a compatible field that the
> driver can bind against.

I can see why that would be nice too, but to me this feels different to 
say MTD partitions as it really is Linux specific and it doesn't seem 
unreasonable that someone may want to include ramoops support when 
debugging something, but for another application, use the whole of the 
onchip RAM as a buffer.  Requiring modifications for the DT on identical 
hardware platforms but different applications doesn't feel quite right 
to me.  Seeing as chosen is special that doesn't feel too bad.

Jamie

Re: Device tree bindings for linux ramoops use

[Grant Likely]

On Fri, Jan 06, 2012 at 05:53:57PM +0000, Jamie Iles wrote:
> On Fri, Jan 06, 2012 at 09:47:22AM -0800, Olof Johansson wrote:
> > On Fri, Jan 6, 2012 at 8:58 AM, Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org> wrote:
> > > On Fri, Jan 06, 2012 at 08:28:51AM -0800, Olof Johansson wrote:
> > >> On Thu, Jan 5, 2012 at 11:22 PM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 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?
> > 
> > Only the ramoops-include-oopses is really the runtime configuration,
> > so that alone in /chosen could be a good idea. But I would rather have
> > the "partition" described as a device with a compatible field that the
> > driver can bind against.
> 
> I can see why that would be nice too, but to me this feels different to 
> say MTD partitions as it really is Linux specific and it doesn't seem 
> unreasonable that someone may want to include ramoops support when 
> debugging something, but for another application, use the whole of the 
> onchip RAM as a buffer.  Requiring modifications for the DT on identical 
> hardware platforms but different applications doesn't feel quite right 
> to me.  Seeing as chosen is special that doesn't feel too bad.

I agree.  This is pretty low level core stuff.  The actual ramoops
region could be anywhere as Olof says; in regular ram, in sram,
somewhere else, but the common case is really just memory mapped ram
that Linux needs to be told "hands off".  I would be fine with
properties in /chosen and using /memreserve/ sections to inhibit the
kernel from using them if they are in main memory.  There can still be
nodes for the actual device, but that doesn't need to be explicitly
connected to the ramoops properties in /chosen.  Implicitly by base
address is fine by me.

g.

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

Re: Device tree bindings for linux ramoops use

[Grant Likely]

On Thu, Jan 05, 2012 at 08:39:50PM -0800, 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 = ...

I'm not a fan of using separate start & size properties.  I'd rather
see a 'reg' type property like "linux,ramoops-mem = <start size>;",
but doing it in separate properties does may early boot code easier to
write.  I assume that is why the initrd start and size values are
passed separately.

I can probably be convinced either way though.

g.

Re: Device tree bindings for linux ramoops use

[Mitch Bradley]

On 1/6/2012 12:09 PM, Grant Likely wrote:
> On Thu, Jan 05, 2012 at 08:39:50PM -0800, 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 = ...
>
> I'm not a fan of using separate start&  size properties.  I'd rather
> see a 'reg' type property like "linux,ramoops-mem =<start size>;",
> but doing it in separate properties does may early boot code easier to
> write.  I assume that is why the initrd start and size values are
> passed separately.

Separate properties admit the possibility of errors where one is present 
but not the other.  I prefer atomicity.  It's either there, with all the 
information, or it isn't.

>
> I can probably be convinced either way though.
>
> g.
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>

Re: Device tree bindings for linux ramoops use

[Grant Likely]

On Fri, Jan 6, 2012 at 3:24 PM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> wrote:
> On 1/6/2012 12:09 PM, Grant Likely wrote:
>>
>> On Thu, Jan 05, 2012 at 08:39:50PM -0800, 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 = ...
>>
>>
>> I'm not a fan of using separate start&  size properties.  I'd rather
>>
>> see a 'reg' type property like "linux,ramoops-mem =<start size>;",
>> but doing it in separate properties does may early boot code easier to
>> write.  I assume that is why the initrd start and size values are
>> passed separately.
>
>
> Separate properties admit the possibility of errors where one is present but
> not the other.  I prefer atomicity.  It's either there, with all the
> information, or it isn't.

.... I was /going/ to argue that having a single property requires
parsing #{address,size}-cells whereas passing separately does not...
but thinking about it more that isn't actually true (although the
cells size could be inferred when using separate properties).  So,
yes, I agree with Mitch.  A single property is better.

g.

Re: Device tree bindings for linux ramoops use

[Rob Herring]

On 01/06/2012 04:05 PM, Grant Likely wrote:
> On Fri, Jan 06, 2012 at 05:53:57PM +0000, Jamie Iles wrote:
>> On Fri, Jan 06, 2012 at 09:47:22AM -0800, Olof Johansson wrote:
>>> On Fri, Jan 6, 2012 at 8:58 AM, Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org> wrote:
>>>> On Fri, Jan 06, 2012 at 08:28:51AM -0800, Olof Johansson wrote:
>>>>> On Thu, Jan 5, 2012 at 11:22 PM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 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?
>>>
>>> Only the ramoops-include-oopses is really the runtime configuration,
>>> so that alone in /chosen could be a good idea. But I would rather have
>>> the "partition" described as a device with a compatible field that the
>>> driver can bind against.
>>
>> I can see why that would be nice too, but to me this feels different to 
>> say MTD partitions as it really is Linux specific and it doesn't seem 
>> unreasonable that someone may want to include ramoops support when 
>> debugging something, but for another application, use the whole of the 
>> onchip RAM as a buffer.  Requiring modifications for the DT on identical 
>> hardware platforms but different applications doesn't feel quite right 
>> to me.  Seeing as chosen is special that doesn't feel too bad.
> 
> I agree.  This is pretty low level core stuff.  The actual ramoops
> region could be anywhere as Olof says; in regular ram, in sram,
> somewhere else, but the common case is really just memory mapped ram
> that Linux needs to be told "hands off".  I would be fine with
> properties in /chosen and using /memreserve/ sections to inhibit the
> kernel from using them if they are in main memory.  There can still be
> nodes for the actual device, but that doesn't need to be explicitly
> connected to the ramoops properties in /chosen.  Implicitly by base
> address is fine by me.
> 

Using actual system RAM will not work. Ramoops uses ioremap which is
forbidden on RAM (at least for ARM). /memreserve/ doesn't unmap the RAM,
but just doesn't allocate it. So you would have to lie to Linux and save
some RAM. There's also the issue that most likely main memory is not
preserved across resets.

So practically speaking, we are talking about an auxiliary RAM device.

I personally like the partition scheme and then device nodes like video
accelerators or audio h/w can be given portions of the RAM.

Rob

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

Re: Device tree bindings for linux ramoops use

[Olof Johansson]

On Fri, Jan 6, 2012 at 2:38 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> On 01/06/2012 04:05 PM, Grant Likely wrote:
>> On Fri, Jan 06, 2012 at 05:53:57PM +0000, Jamie Iles wrote:
>>> On Fri, Jan 06, 2012 at 09:47:22AM -0800, Olof Johansson wrote:
>>>> On Fri, Jan 6, 2012 at 8:58 AM, Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org> wrote:
>>>>> On Fri, Jan 06, 2012 at 08:28:51AM -0800, Olof Johansson wrote:
>>>>>> On Thu, Jan 5, 2012 at 11:22 PM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 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?
>>>>
>>>> Only the ramoops-include-oopses is really the runtime configuration,
>>>> so that alone in /chosen could be a good idea. But I would rather have
>>>> the "partition" described as a device with a compatible field that the
>>>> driver can bind against.
>>>
>>> I can see why that would be nice too, but to me this feels different to
>>> say MTD partitions as it really is Linux specific and it doesn't seem
>>> unreasonable that someone may want to include ramoops support when
>>> debugging something, but for another application, use the whole of the
>>> onchip RAM as a buffer.  Requiring modifications for the DT on identical
>>> hardware platforms but different applications doesn't feel quite right
>>> to me.  Seeing as chosen is special that doesn't feel too bad.
>>
>> I agree.  This is pretty low level core stuff.  The actual ramoops
>> region could be anywhere as Olof says; in regular ram, in sram,
>> somewhere else, but the common case is really just memory mapped ram
>> that Linux needs to be told "hands off".  I would be fine with
>> properties in /chosen and using /memreserve/ sections to inhibit the
>> kernel from using them if they are in main memory.  There can still be
>> nodes for the actual device, but that doesn't need to be explicitly
>> connected to the ramoops properties in /chosen.  Implicitly by base
>> address is fine by me.
>>
>
> Using actual system RAM will not work. Ramoops uses ioremap which is
> forbidden on RAM (at least for ARM). /memreserve/ doesn't unmap the RAM,
> but just doesn't allocate it. So you would have to lie to Linux and save
> some RAM. There's also the issue that most likely main memory is not
> preserved across resets.

The way to handle this is to have u-boot or whatever firmware you use,
completely remove that range from the memory node. Or leave it out of
the memory map.

In practice, we have had excellent results with regular RAM contents
being preserved across reboots. I was skeptical at first as well, but
it's not a problem in reality. Of course, firmware needs to be
adjusted such that it does not clear that memory range on reboot.
Chrome OS uses this both on x86 and ARM.

> So practically speaking, we are talking about an auxiliary RAM device.

Sure, it's a separate region of RAM that is not used by the rest of the system.

> I personally like the partition scheme and then device nodes like video
> accelerators or audio h/w can be given portions of the RAM.

Me too.


-Olof

Re: Device tree bindings for linux ramoops use

[Mitch Bradley]

On 1/6/2012 12:55 PM, Olof Johansson wrote:
> On Fri, Jan 6, 2012 at 2:38 PM, Rob Herring<robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>  wrote:
>>
>>
>> On 01/06/2012 04:05 PM, Grant Likely wrote:
>>> On Fri, Jan 06, 2012 at 05:53:57PM +0000, Jamie Iles wrote:
>>>> On Fri, Jan 06, 2012 at 09:47:22AM -0800, Olof Johansson wrote:
>>>>> On Fri, Jan 6, 2012 at 8:58 AM, Jamie Iles<jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org>  wrote:
>>>>>> On Fri, Jan 06, 2012 at 08:28:51AM -0800, Olof Johansson wrote:
>>>>>>> On Thu, Jan 5, 2012 at 11:22 PM, Mitch Bradley<wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>  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?
>>>>>
>>>>> Only the ramoops-include-oopses is really the runtime configuration,
>>>>> so that alone in /chosen could be a good idea. But I would rather have
>>>>> the "partition" described as a device with a compatible field that the
>>>>> driver can bind against.
>>>>
>>>> I can see why that would be nice too, but to me this feels different to
>>>> say MTD partitions as it really is Linux specific and it doesn't seem
>>>> unreasonable that someone may want to include ramoops support when
>>>> debugging something, but for another application, use the whole of the
>>>> onchip RAM as a buffer.  Requiring modifications for the DT on identical
>>>> hardware platforms but different applications doesn't feel quite right
>>>> to me.  Seeing as chosen is special that doesn't feel too bad.
>>>
>>> I agree.  This is pretty low level core stuff.  The actual ramoops
>>> region could be anywhere as Olof says; in regular ram, in sram,
>>> somewhere else, but the common case is really just memory mapped ram
>>> that Linux needs to be told "hands off".  I would be fine with
>>> properties in /chosen and using /memreserve/ sections to inhibit the
>>> kernel from using them if they are in main memory.  There can still be
>>> nodes for the actual device, but that doesn't need to be explicitly
>>> connected to the ramoops properties in /chosen.  Implicitly by base
>>> address is fine by me.
>>>
>>
>> Using actual system RAM will not work. Ramoops uses ioremap which is
>> forbidden on RAM (at least for ARM). /memreserve/ doesn't unmap the RAM,
>> but just doesn't allocate it. So you would have to lie to Linux and save
>> some RAM. There's also the issue that most likely main memory is not
>> preserved across resets.
>
> The way to handle this is to have u-boot or whatever firmware you use,
> completely remove that range from the memory node. Or leave it out of
> the memory map.
>
> In practice, we have had excellent results with regular RAM contents
> being preserved across reboots. I was skeptical at first as well, but
> it's not a problem in reality. Of course, firmware needs to be
> adjusted such that it does not clear that memory range on reboot.
> Chrome OS uses this both on x86 and ARM.


DRAM tends to hold its data for a good fraction of a second, so if the 
memory controller is quickly re-initialized to the point of running 
refresh cycles, you win.

You also have to worry about memory change due to auto-probing for the 
memory size.

But, yeah, it can usually be made to work if you control the firmware.


>
>> So practically speaking, we are talking about an auxiliary RAM device.
>
> Sure, it's a separate region of RAM that is not used by the rest of the system.
>
>> I personally like the partition scheme and then device nodes like video
>> accelerators or audio h/w can be given portions of the RAM.
>
> Me too.
>
>
> -Olof
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
>