On 1/6/2012 12:55 PM, Olof Johansson wrote:
On Fri, Jan 6, 2012 at 2:38 PM, Rob Herring<robherri...@gmail.com> 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<ja...@jamieiles.com> 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<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?
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@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
