All of lore.kernel.org
 help / color / mirror / Atom feed
* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-24 15:11 ` Grant Likely
  0 siblings, 0 replies; 32+ messages in thread
From: Grant Likely @ 2010-03-24 15:11 UTC (permalink / raw)
  To: David Rusling, Philippe Robin, Dave P Martin, Grant Likely, Jeremy Kerr

Hi all,

Since work is being done to add ARM Flattened Device Tree support to
both Linux and FreeBSD, I think it would be worth while to agree on a
common boot interface for passing a device tree blob from firmware to
the kernel (or in the case of kexec, from the old to new kernels).
I've drafted up something quickly on fdt.secretlab.ca.  The page can
be found here:

http://fdt.secretlab.ca/Boot_Environment#ARM

Feel free to modify the draft on the wiki if you notice any missing
details.  I've also posted the current text below so it is easy to
review and comment on.

(btw, the wiki at fdt.secretlab.ca should be moving to devicetree.org
in the near future, but I'll keep the old domain name around.
devicetree.org will be used to document new device tree bindings in an
OS-agnostic location.)


== ARM ==
See Documentation/arm/Booting and arch/arm/include/asm/setup.h in the
Linux kernel source tree for background information.  Some of the
content of this section is extracted from those files.

'''Draft'''

===Required System State===
*Quiesce all DMA
*CPU register contents
**r0 = 0
**r1 = Linux machine number (as defined in the ARM Linux machine database) or 0
**r2 = physical address of tagged parameter list in system RAM
*IRQs disabled
*MMU off
*Instruction cache either on or off
*Data cache turned off

===Minimal state for Flattened Device Tree Boot===
For FDT booting, the tagged list only needs to contain a single device
tree tag, and the device tree blob could be appended to the end of the
tagged list so that everything resides in the same region of memory.
For example, a minimal tag list may look like this:

<pre>
u32 tag_list[] = {
        0x00000005, /* ATAG_CORE, 5 words */
        0x54410001,
        0x00000000,
        0x00000000,
        0x00000000,

        0x00000004, /* ATAG_DEVTREE, 4 words */
        0x5441000a,
        0xNNNNNNNN, /* Phys address of device tree blob; could simply
be &tag_list + sizeof(taglist)
        0xMMMMMMMM, /* size of device tree blob in bytes */

        0x00000000, /* ATAG_NONE, end of list */
        0x00000000,
};
</pre>

===Tagged List Format===
The ARM tagged list format was designed by Russell King to solve the
problem of passing configuration information from the boot loader to
the kernel.  The tagged list design predates the flattened device
tree.  It is trivial to implement, but is only suitable for passing
the most basic of information.  A large number of ARM boot loaders
already include tagged list support.  While it was originally designed
for ARM Linux, the tagged list design that is inherently Linux
specific.

The tagged list is adopted for FDT booting to maintain compatibility
with the large installed base if existing ARM Linux machines.  There
are two aspects where this is important.  1. Boot loaders modified to
also pass an FDT blob do not become incompatible with existing
operating system images, and 2. operating systems can add FDT blob
support without becoming unbootable on existing non-FDT compatible
boot loaders.

Operating systems are only required to parse the ATAG_DEVTREE tag for
FDT booting.  If an OS understands additional tags, then it is
permissible to use the data in the tags.  However, device tree data
always take precedence over data in the tagged list.  For example, the
presence of a memory node in the device tree overrides the ATAG_MEM
tag.

The tagged list is a series of parameter blocks in contiguous memory.
Each tag consists of a 32 bit size field, a 32 bit tag id, and an
optional block of variable length data.  The size field contains the
total length of the tag in 32 bit words.  The tag id is a predefined
value identifying the data contained by the tag.

The following tag ids are currently defined:
{|+ border="1"
! Name !! Tag ID !! Size !! Description and payload format
|-
| Tag Header || || || Header used by all tags.  The explicit size
field allows an operating system to skip over tags it does not
recognize.
 struct tag_header {
         u32 size; /* tag size in 32bit words */
         u32 tag;
 };
|-
| ATAG_CORE || 0x54410001 || 5 || First tag in tag list
 struct tag_core {
         u32 flags;
         u32 pagesize;
         u32 rootdev;
 };
|-
| ATAG_MEM || 0x54410002 || 4 || Physical memory region
 struct tag_mem32 {
         u32 size;
         u32 start;
 };
|-
| ATAG_VIDEOTEXT || 0x54410003 || 5 || VGA text display
|-
| ATAG_RAMDISK || 0x54410004 || 5 || Location and size of Linux ramdisk image
 struct tag_ramdisk {
         u32 flags;
         u32 size;
         u32 start;
 };
|-
| ATAG_INITRD || 0x54410005 || || Deprecated.  Do not use
|-
| ATAG_INITRD2 || 0x54420005 || 4 || Location and size of Linux initrd image
 struct tag_initrd {
         u32 start;
         u32 size;
 };
|-
| ATAG_SERIAL || 0x54410006 || 4 || 64 bit machine serial number
 struct tag_serialnr {
         u32 low;
         u32 high;
 };
|-
| ATAG_REVISION || 0x54410007 || 3 || 32 bit board revision number
 struct tag_revision {
         u32 rev;
 };
|-
| ATAG_VIDEOLFB || 0x54410008 || 9 ||
|-
| ATAG_CMDLINE || 0x54410009 || 2 || Boot parameter string
 struct {
         char cmdline[1];
 };
|-
| ATAG_FLATTREE || 0x5441000a || 4 || '''DRAFT, not yet approved.'''
Location and size of Flattened Device Tree Blob
 struct {
         u32 start;
         u32 size;
 };
|-
| ATAG_NONE || 0x00000000 || 0 || End of tag list
|}


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-24 15:11 ` Grant Likely
  0 siblings, 0 replies; 32+ messages in thread
From: Grant Likely @ 2010-03-24 15:11 UTC (permalink / raw)
  To: linux-arm-kernel

Hi all,

Since work is being done to add ARM Flattened Device Tree support to
both Linux and FreeBSD, I think it would be worth while to agree on a
common boot interface for passing a device tree blob from firmware to
the kernel (or in the case of kexec, from the old to new kernels).
I've drafted up something quickly on fdt.secretlab.ca.  The page can
be found here:

http://fdt.secretlab.ca/Boot_Environment#ARM

Feel free to modify the draft on the wiki if you notice any missing
details.  I've also posted the current text below so it is easy to
review and comment on.

(btw, the wiki at fdt.secretlab.ca should be moving to devicetree.org
in the near future, but I'll keep the old domain name around.
devicetree.org will be used to document new device tree bindings in an
OS-agnostic location.)


== ARM ==
See Documentation/arm/Booting and arch/arm/include/asm/setup.h in the
Linux kernel source tree for background information.  Some of the
content of this section is extracted from those files.

'''Draft'''

===Required System State===
*Quiesce all DMA
*CPU register contents
**r0 = 0
**r1 = Linux machine number (as defined in the ARM Linux machine database) or 0
**r2 = physical address of tagged parameter list in system RAM
*IRQs disabled
*MMU off
*Instruction cache either on or off
*Data cache turned off

===Minimal state for Flattened Device Tree Boot===
For FDT booting, the tagged list only needs to contain a single device
tree tag, and the device tree blob could be appended to the end of the
tagged list so that everything resides in the same region of memory.
For example, a minimal tag list may look like this:

<pre>
u32 tag_list[] = {
        0x00000005, /* ATAG_CORE, 5 words */
        0x54410001,
        0x00000000,
        0x00000000,
        0x00000000,

        0x00000004, /* ATAG_DEVTREE, 4 words */
        0x5441000a,
        0xNNNNNNNN, /* Phys address of device tree blob; could simply
be &tag_list + sizeof(taglist)
        0xMMMMMMMM, /* size of device tree blob in bytes */

        0x00000000, /* ATAG_NONE, end of list */
        0x00000000,
};
</pre>

===Tagged List Format===
The ARM tagged list format was designed by Russell King to solve the
problem of passing configuration information from the boot loader to
the kernel.  The tagged list design predates the flattened device
tree.  It is trivial to implement, but is only suitable for passing
the most basic of information.  A large number of ARM boot loaders
already include tagged list support.  While it was originally designed
for ARM Linux, the tagged list design that is inherently Linux
specific.

The tagged list is adopted for FDT booting to maintain compatibility
with the large installed base if existing ARM Linux machines.  There
are two aspects where this is important.  1. Boot loaders modified to
also pass an FDT blob do not become incompatible with existing
operating system images, and 2. operating systems can add FDT blob
support without becoming unbootable on existing non-FDT compatible
boot loaders.

Operating systems are only required to parse the ATAG_DEVTREE tag for
FDT booting.  If an OS understands additional tags, then it is
permissible to use the data in the tags.  However, device tree data
always take precedence over data in the tagged list.  For example, the
presence of a memory node in the device tree overrides the ATAG_MEM
tag.

The tagged list is a series of parameter blocks in contiguous memory.
Each tag consists of a 32 bit size field, a 32 bit tag id, and an
optional block of variable length data.  The size field contains the
total length of the tag in 32 bit words.  The tag id is a predefined
value identifying the data contained by the tag.

The following tag ids are currently defined:
{|+ border="1"
! Name !! Tag ID !! Size !! Description and payload format
|-
| Tag Header || || || Header used by all tags.  The explicit size
field allows an operating system to skip over tags it does not
recognize.
 struct tag_header {
         u32 size; /* tag size in 32bit words */
         u32 tag;
 };
|-
| ATAG_CORE || 0x54410001 || 5 || First tag in tag list
 struct tag_core {
         u32 flags;
         u32 pagesize;
         u32 rootdev;
 };
|-
| ATAG_MEM || 0x54410002 || 4 || Physical memory region
 struct tag_mem32 {
         u32 size;
         u32 start;
 };
|-
| ATAG_VIDEOTEXT || 0x54410003 || 5 || VGA text display
|-
| ATAG_RAMDISK || 0x54410004 || 5 || Location and size of Linux ramdisk image
 struct tag_ramdisk {
         u32 flags;
         u32 size;
         u32 start;
 };
|-
| ATAG_INITRD || 0x54410005 || || Deprecated.  Do not use
|-
| ATAG_INITRD2 || 0x54420005 || 4 || Location and size of Linux initrd image
 struct tag_initrd {
         u32 start;
         u32 size;
 };
|-
| ATAG_SERIAL || 0x54410006 || 4 || 64 bit machine serial number
 struct tag_serialnr {
         u32 low;
         u32 high;
 };
|-
| ATAG_REVISION || 0x54410007 || 3 || 32 bit board revision number
 struct tag_revision {
         u32 rev;
 };
|-
| ATAG_VIDEOLFB || 0x54410008 || 9 ||
|-
| ATAG_CMDLINE || 0x54410009 || 2 || Boot parameter string
 struct {
         char cmdline[1];
 };
|-
| ATAG_FLATTREE || 0x5441000a || 4 || '''DRAFT, not yet approved.'''
Location and size of Flattened Device Tree Blob
 struct {
         u32 start;
         u32 size;
 };
|-
| ATAG_NONE || 0x00000000 || 0 || End of tag list
|}


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: RFC: ARM Boot standard for passing device tree blob
  2010-03-24 15:11 ` Grant Likely
@ 2010-03-25 21:04   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 32+ messages in thread
From: Russell King - ARM Linux @ 2010-03-25 21:04 UTC (permalink / raw)
  To: Grant Likely
  Cc: devicetree-discuss, Rafal Jaworowski, Philippe Robin,
	David Rusling, Jeremy Kerr, Dave P Martin, linux-arm-kernel

On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
> Hi all,
> 
> Since work is being done to add ARM Flattened Device Tree support to
> both Linux and FreeBSD, I think it would be worth while to agree on a
> common boot interface for passing a device tree blob from firmware to
> the kernel (or in the case of kexec, from the old to new kernels).
> I've drafted up something quickly on fdt.secretlab.ca.  The page can
> be found here:
> 
> http://fdt.secretlab.ca/Boot_Environment#ARM
> 
> Feel free to modify the draft on the wiki if you notice any missing
> details.  I've also posted the current text below so it is easy to
> review and comment on.
> 
> (btw, the wiki at fdt.secretlab.ca should be moving to devicetree.org
> in the near future, but I'll keep the old domain name around.
> devicetree.org will be used to document new device tree bindings in an
> OS-agnostic location.)
> 
> 
> == ARM ==
> See Documentation/arm/Booting and arch/arm/include/asm/setup.h in the
> Linux kernel source tree for background information.  Some of the
> content of this section is extracted from those files.
> 
> '''Draft'''
> 
> ===Required System State===
> *Quiesce all DMA
> *CPU register contents
> **r0 = 0
> **r1 = Linux machine number (as defined in the ARM Linux machine database) or 0

0 is a valid machine number.  What is your purpose of passing 0?

> **r2 = physical address of tagged parameter list in system RAM
> *IRQs disabled
> *MMU off
> *Instruction cache either on or off
> *Data cache turned off

Would recommend saying "Data cache(s) turned off" so that L2 cache is
included.

> ===Minimal state for Flattened Device Tree Boot===
> For FDT booting, the tagged list only needs to contain a single device
> tree tag, and the device tree blob could be appended to the end of the
> tagged list so that everything resides in the same region of memory.

That's a bad idea.  Sometimes the tagged list can be extended by wrappers
around the kernel, and data placed at the end of the list would be
overwritten.

As the tagged list can encode arbitarily sized data chunks, there's no
reason to use a pointer in the tagged list.  However, there is a problem:
what do you do with a large chunk of data in the tagged list?  You can't
allocate memory to copy it in the kernel because no memory allocators
are up and running...

That's always been the catch-22 with passing binary data blobs to the
kernel.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-25 21:04   ` Russell King - ARM Linux
  0 siblings, 0 replies; 32+ messages in thread
From: Russell King - ARM Linux @ 2010-03-25 21:04 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
> Hi all,
> 
> Since work is being done to add ARM Flattened Device Tree support to
> both Linux and FreeBSD, I think it would be worth while to agree on a
> common boot interface for passing a device tree blob from firmware to
> the kernel (or in the case of kexec, from the old to new kernels).
> I've drafted up something quickly on fdt.secretlab.ca.  The page can
> be found here:
> 
> http://fdt.secretlab.ca/Boot_Environment#ARM
> 
> Feel free to modify the draft on the wiki if you notice any missing
> details.  I've also posted the current text below so it is easy to
> review and comment on.
> 
> (btw, the wiki at fdt.secretlab.ca should be moving to devicetree.org
> in the near future, but I'll keep the old domain name around.
> devicetree.org will be used to document new device tree bindings in an
> OS-agnostic location.)
> 
> 
> == ARM ==
> See Documentation/arm/Booting and arch/arm/include/asm/setup.h in the
> Linux kernel source tree for background information.  Some of the
> content of this section is extracted from those files.
> 
> '''Draft'''
> 
> ===Required System State===
> *Quiesce all DMA
> *CPU register contents
> **r0 = 0
> **r1 = Linux machine number (as defined in the ARM Linux machine database) or 0

0 is a valid machine number.  What is your purpose of passing 0?

> **r2 = physical address of tagged parameter list in system RAM
> *IRQs disabled
> *MMU off
> *Instruction cache either on or off
> *Data cache turned off

Would recommend saying "Data cache(s) turned off" so that L2 cache is
included.

> ===Minimal state for Flattened Device Tree Boot===
> For FDT booting, the tagged list only needs to contain a single device
> tree tag, and the device tree blob could be appended to the end of the
> tagged list so that everything resides in the same region of memory.

That's a bad idea.  Sometimes the tagged list can be extended by wrappers
around the kernel, and data placed at the end of the list would be
overwritten.

As the tagged list can encode arbitarily sized data chunks, there's no
reason to use a pointer in the tagged list.  However, there is a problem:
what do you do with a large chunk of data in the tagged list?  You can't
allocate memory to copy it in the kernel because no memory allocators
are up and running...

That's always been the catch-22 with passing binary data blobs to the
kernel.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: RFC: ARM Boot standard for passing device tree blob
  2010-03-25 21:04   ` Russell King - ARM Linux
@ 2010-03-25 23:40       ` David Gibson
  -1 siblings, 0 replies; 32+ messages in thread
From: David Gibson @ 2010-03-25 23:40 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: devicetree-discuss, Philippe Robin, David Rusling, Jeremy Kerr,
	Dave P Martin, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Thu, Mar 25, 2010 at 09:04:09PM +0000, Russell King - ARM Linux wrote:
> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
> > Hi all,
> > 
> > Since work is being done to add ARM Flattened Device Tree support to
> > both Linux and FreeBSD, I think it would be worth while to agree on a
> > common boot interface for passing a device tree blob from firmware to
> > the kernel (or in the case of kexec, from the old to new kernels).
> > I've drafted up something quickly on fdt.secretlab.ca.  The page can
> > be found here:
> > 
> > http://fdt.secretlab.ca/Boot_Environment#ARM
> > 
> > Feel free to modify the draft on the wiki if you notice any missing
> > details.  I've also posted the current text below so it is easy to
> > review and comment on.
> > 
> > (btw, the wiki at fdt.secretlab.ca should be moving to devicetree.org
> > in the near future, but I'll keep the old domain name around.
> > devicetree.org will be used to document new device tree bindings in an
> > OS-agnostic location.)
> > 
> > 
> > == ARM ==
> > See Documentation/arm/Booting and arch/arm/include/asm/setup.h in the
> > Linux kernel source tree for background information.  Some of the
> > content of this section is extracted from those files.
> > 
> > '''Draft'''
> > 
> > ===Required System State===
> > *Quiesce all DMA
> > *CPU register contents
> > **r0 = 0
> > **r1 = Linux machine number (as defined in the ARM Linux machine database) or 0
> 
> 0 is a valid machine number.  What is your purpose of passing 0?

Presumably a machine number will need to be allocated to mean "use the
device tree instead of fixed machine number info".

> > **r2 = physical address of tagged parameter list in system RAM
> > *IRQs disabled
> > *MMU off
> > *Instruction cache either on or off
> > *Data cache turned off
> 
> Would recommend saying "Data cache(s) turned off" so that L2 cache is
> included.
> 
> > ===Minimal state for Flattened Device Tree Boot===
> > For FDT booting, the tagged list only needs to contain a single device
> > tree tag, and the device tree blob could be appended to the end of the
> > tagged list so that everything resides in the same region of memory.
> 
> That's a bad idea.  Sometimes the tagged list can be extended by wrappers
> around the kernel, and data placed at the end of the list would be
> overwritten.
> 
> As the tagged list can encode arbitarily sized data chunks, there's no
> reason to use a pointer in the tagged list.  However, there is a problem:
> what do you do with a large chunk of data in the tagged list?  You can't
> allocate memory to copy it in the kernel because no memory allocators
> are up and running...

It's not clear that you'll need to copy it particularly soon.  The
libfdt functions we use in the zImage wrapper on powerpc will deal
fine with a device tree accessed in place, or moved about.  They are
built specifically not to assume the existence of an allocater.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-25 23:40       ` David Gibson
  0 siblings, 0 replies; 32+ messages in thread
From: David Gibson @ 2010-03-25 23:40 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Mar 25, 2010 at 09:04:09PM +0000, Russell King - ARM Linux wrote:
> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
> > Hi all,
> > 
> > Since work is being done to add ARM Flattened Device Tree support to
> > both Linux and FreeBSD, I think it would be worth while to agree on a
> > common boot interface for passing a device tree blob from firmware to
> > the kernel (or in the case of kexec, from the old to new kernels).
> > I've drafted up something quickly on fdt.secretlab.ca.  The page can
> > be found here:
> > 
> > http://fdt.secretlab.ca/Boot_Environment#ARM
> > 
> > Feel free to modify the draft on the wiki if you notice any missing
> > details.  I've also posted the current text below so it is easy to
> > review and comment on.
> > 
> > (btw, the wiki at fdt.secretlab.ca should be moving to devicetree.org
> > in the near future, but I'll keep the old domain name around.
> > devicetree.org will be used to document new device tree bindings in an
> > OS-agnostic location.)
> > 
> > 
> > == ARM ==
> > See Documentation/arm/Booting and arch/arm/include/asm/setup.h in the
> > Linux kernel source tree for background information.  Some of the
> > content of this section is extracted from those files.
> > 
> > '''Draft'''
> > 
> > ===Required System State===
> > *Quiesce all DMA
> > *CPU register contents
> > **r0 = 0
> > **r1 = Linux machine number (as defined in the ARM Linux machine database) or 0
> 
> 0 is a valid machine number.  What is your purpose of passing 0?

Presumably a machine number will need to be allocated to mean "use the
device tree instead of fixed machine number info".

> > **r2 = physical address of tagged parameter list in system RAM
> > *IRQs disabled
> > *MMU off
> > *Instruction cache either on or off
> > *Data cache turned off
> 
> Would recommend saying "Data cache(s) turned off" so that L2 cache is
> included.
> 
> > ===Minimal state for Flattened Device Tree Boot===
> > For FDT booting, the tagged list only needs to contain a single device
> > tree tag, and the device tree blob could be appended to the end of the
> > tagged list so that everything resides in the same region of memory.
> 
> That's a bad idea.  Sometimes the tagged list can be extended by wrappers
> around the kernel, and data placed at the end of the list would be
> overwritten.
> 
> As the tagged list can encode arbitarily sized data chunks, there's no
> reason to use a pointer in the tagged list.  However, there is a problem:
> what do you do with a large chunk of data in the tagged list?  You can't
> allocate memory to copy it in the kernel because no memory allocators
> are up and running...

It's not clear that you'll need to copy it particularly soon.  The
libfdt functions we use in the zImage wrapper on powerpc will deal
fine with a device tree accessed in place, or moved about.  They are
built specifically not to assume the existence of an allocater.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: RFC: ARM Boot standard for passing device tree blob
  2010-03-25 23:40       ` David Gibson
@ 2010-03-26  0:23         ` Jeremy Kerr
  -1 siblings, 0 replies; 32+ messages in thread
From: Jeremy Kerr @ 2010-03-26  0:23 UTC (permalink / raw)
  To: David Gibson
  Cc: Russell King - ARM Linux, devicetree-discuss, Philippe Robin,
	David Rusling, Dave P Martin,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r


> > > ===Required System State===
> > > *Quiesce all DMA
> > > *CPU register contents
> > > **r0 = 0
> > > **r1 = Linux machine number (as defined in the ARM Linux machine
> > > database) or 0
> >
> > 0 is a valid machine number.  What is your purpose of passing 0?
> 
> Presumably a machine number will need to be allocated to mean "use the
> device tree instead of fixed machine number info".

I've been using 0xffffffff to indicate that this is a 'device-tree' platform. 
The value isn't really important, just that we agree on something.

Cheers,


Jeremy

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-26  0:23         ` Jeremy Kerr
  0 siblings, 0 replies; 32+ messages in thread
From: Jeremy Kerr @ 2010-03-26  0:23 UTC (permalink / raw)
  To: linux-arm-kernel


> > > ===Required System State===
> > > *Quiesce all DMA
> > > *CPU register contents
> > > **r0 = 0
> > > **r1 = Linux machine number (as defined in the ARM Linux machine
> > > database) or 0
> >
> > 0 is a valid machine number.  What is your purpose of passing 0?
> 
> Presumably a machine number will need to be allocated to mean "use the
> device tree instead of fixed machine number info".

I've been using 0xffffffff to indicate that this is a 'device-tree' platform. 
The value isn't really important, just that we agree on something.

Cheers,


Jeremy

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: RFC: ARM Boot standard for passing device tree blob
  2010-03-25 21:04   ` Russell King - ARM Linux
@ 2010-03-26  3:24       ` Grant Likely
  -1 siblings, 0 replies; 32+ messages in thread
From: Grant Likely @ 2010-03-26  3:24 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: devicetree-discuss, Philippe Robin, David Rusling, Jeremy Kerr,
	Dave P Martin, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Thu, Mar 25, 2010 at 3:04 PM, Russell King - ARM Linux
<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
>> ===Required System State===
>> *Quiesce all DMA
>> *CPU register contents
>> **r0 = 0
>> **r1 = Linux machine number (as defined in the ARM Linux machine database) or 0
>
> 0 is a valid machine number.  What is your purpose of passing 0?

Heh, I forgot to go back and check if 0 was assigned or not.  I just
wanted something that wasn't going to conflict.  How about 0xffffffff
like Jeremy has been using?

>> **r2 = physical address of tagged parameter list in system RAM
>> *IRQs disabled
>> *MMU off
>> *Instruction cache either on or off
>> *Data cache turned off
>
> Would recommend saying "Data cache(s) turned off" so that L2 cache is
> included.

done.

>> ===Minimal state for Flattened Device Tree Boot===
>> For FDT booting, the tagged list only needs to contain a single device
>> tree tag, and the device tree blob could be appended to the end of the
>> tagged list so that everything resides in the same region of memory.
>
> That's a bad idea.  Sometimes the tagged list can be extended by wrappers
> around the kernel, and data placed at the end of the list would be
> overwritten.

Fair enough, I hadn't considered that.

Currently I'm handling the tree blob the same way ramdisks are handled
and waiting until after bootmem_init() to actually access the tree.
That works for the device registration code, but I still rely on the
machine id for probing platform code.  Jeremy has patches that can do
platform probing from device tree data, but last I talked to him it
required the blob to be in the same section of memory as the atags.
ie. between PHYS_BASE and PHYS_BASE+0x4000 IIRC.

> As the tagged list can encode arbitarily sized data chunks, there's no
> reason to use a pointer in the tagged list.  However, there is a problem:
> what do you do with a large chunk of data in the tagged list?  You can't
> allocate memory to copy it in the kernel because no memory allocators
> are up and running...
>
> That's always been the catch-22 with passing binary data blobs to the
> kernel.

Indeed.  Another option I suppose is to extract the needed data from
the tree as part of the wrapper and squirt it into atags.  Then there
would be no problem in waiting until bootmem_init() to reserve the
devicetree memory.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-26  3:24       ` Grant Likely
  0 siblings, 0 replies; 32+ messages in thread
From: Grant Likely @ 2010-03-26  3:24 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Mar 25, 2010 at 3:04 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
>> ===Required System State===
>> *Quiesce all DMA
>> *CPU register contents
>> **r0 = 0
>> **r1 = Linux machine number (as defined in the ARM Linux machine database) or 0
>
> 0 is a valid machine number. ?What is your purpose of passing 0?

Heh, I forgot to go back and check if 0 was assigned or not.  I just
wanted something that wasn't going to conflict.  How about 0xffffffff
like Jeremy has been using?

>> **r2 = physical address of tagged parameter list in system RAM
>> *IRQs disabled
>> *MMU off
>> *Instruction cache either on or off
>> *Data cache turned off
>
> Would recommend saying "Data cache(s) turned off" so that L2 cache is
> included.

done.

>> ===Minimal state for Flattened Device Tree Boot===
>> For FDT booting, the tagged list only needs to contain a single device
>> tree tag, and the device tree blob could be appended to the end of the
>> tagged list so that everything resides in the same region of memory.
>
> That's a bad idea. ?Sometimes the tagged list can be extended by wrappers
> around the kernel, and data placed at the end of the list would be
> overwritten.

Fair enough, I hadn't considered that.

Currently I'm handling the tree blob the same way ramdisks are handled
and waiting until after bootmem_init() to actually access the tree.
That works for the device registration code, but I still rely on the
machine id for probing platform code.  Jeremy has patches that can do
platform probing from device tree data, but last I talked to him it
required the blob to be in the same section of memory as the atags.
ie. between PHYS_BASE and PHYS_BASE+0x4000 IIRC.

> As the tagged list can encode arbitarily sized data chunks, there's no
> reason to use a pointer in the tagged list. ?However, there is a problem:
> what do you do with a large chunk of data in the tagged list? ?You can't
> allocate memory to copy it in the kernel because no memory allocators
> are up and running...
>
> That's always been the catch-22 with passing binary data blobs to the
> kernel.

Indeed.  Another option I suppose is to extract the needed data from
the tree as part of the wrapper and squirt it into atags.  Then there
would be no problem in waiting until bootmem_init() to reserve the
devicetree memory.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: RFC: ARM Boot standard for passing device tree blob
  2010-03-25 21:04   ` Russell King - ARM Linux
@ 2010-03-26 13:37     ` Catalin Marinas
  -1 siblings, 0 replies; 32+ messages in thread
From: Catalin Marinas @ 2010-03-26 13:37 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: devicetree-discuss, Grant Likely, Rafal Jaworowski,
	Philippe Robin, David Rusling, Jeremy Kerr, Dave P Martin,
	linux-arm-kernel

On Thu, 2010-03-25 at 21:04 +0000, Russell King - ARM Linux wrote:
> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
> > ===Required System State===
[...]
> > *IRQs disabled
> > *MMU off
> > *Instruction cache either on or off
> > *Data cache turned off
> 
> Would recommend saying "Data cache(s) turned off" so that L2 cache is
> included.

There are platforms where the L2 cache is turned on by the boot monitor
(secure monitor) and Linux has no control over it (I think OMAP).

-- 
Catalin

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-26 13:37     ` Catalin Marinas
  0 siblings, 0 replies; 32+ messages in thread
From: Catalin Marinas @ 2010-03-26 13:37 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, 2010-03-25 at 21:04 +0000, Russell King - ARM Linux wrote:
> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
> > ===Required System State===
[...]
> > *IRQs disabled
> > *MMU off
> > *Instruction cache either on or off
> > *Data cache turned off
> 
> Would recommend saying "Data cache(s) turned off" so that L2 cache is
> included.

There are platforms where the L2 cache is turned on by the boot monitor
(secure monitor) and Linux has no control over it (I think OMAP).

-- 
Catalin

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: RFC: ARM Boot standard for passing device tree blob
  2010-03-26 13:37     ` Catalin Marinas
@ 2010-03-26 17:43         ` Mitch Bradley
  -1 siblings, 0 replies; 32+ messages in thread
From: Mitch Bradley @ 2010-03-26 17:43 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Russell King - ARM Linux, devicetree-discuss, Philippe Robin,
	David Rusling, Jeremy Kerr, Dave P Martin,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

Catalin Marinas wrote:
> On Thu, 2010-03-25 at 21:04 +0000, Russell King - ARM Linux wrote:
>   
>> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
>>     
>>> ===Required System State===
>>>       
> [...]
>   
>>> *IRQs disabled
>>> *MMU off
>>> *Instruction cache either on or off
>>> *Data cache turned off
>>>       
>> Would recommend saying "Data cache(s) turned off" so that L2 cache is
>> included.
>>     
>
> There are platforms where the L2 cache is turned on by the boot monitor
> (secure monitor) and Linux has no control over it (I think OMAP).
>   

What is the reason for turning off the data caches?  Leaving all caches 
turned on and coherent with one another has always worked well for me at 
the interface from firmware to a booted program.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-26 17:43         ` Mitch Bradley
  0 siblings, 0 replies; 32+ messages in thread
From: Mitch Bradley @ 2010-03-26 17:43 UTC (permalink / raw)
  To: linux-arm-kernel

Catalin Marinas wrote:
> On Thu, 2010-03-25 at 21:04 +0000, Russell King - ARM Linux wrote:
>   
>> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
>>     
>>> ===Required System State===
>>>       
> [...]
>   
>>> *IRQs disabled
>>> *MMU off
>>> *Instruction cache either on or off
>>> *Data cache turned off
>>>       
>> Would recommend saying "Data cache(s) turned off" so that L2 cache is
>> included.
>>     
>
> There are platforms where the L2 cache is turned on by the boot monitor
> (secure monitor) and Linux has no control over it (I think OMAP).
>   

What is the reason for turning off the data caches?  Leaving all caches 
turned on and coherent with one another has always worked well for me at 
the interface from firmware to a booted program.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: RFC: ARM Boot standard for passing device tree blob
  2010-03-26 17:43         ` Mitch Bradley
@ 2010-03-26 18:13             ` Grant Likely
  -1 siblings, 0 replies; 32+ messages in thread
From: Grant Likely @ 2010-03-26 18:13 UTC (permalink / raw)
  To: Mitch Bradley
  Cc: Russell King - ARM Linux, Catalin Marinas, devicetree-discuss,
	Philippe Robin, David Rusling, Jeremy Kerr, Dave P Martin,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Fri, Mar 26, 2010 at 11:43 AM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> wrote:
> Catalin Marinas wrote:
>> On Thu, 2010-03-25 at 21:04 +0000, Russell King - ARM Linux wrote:
>>> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
>>>> *IRQs disabled
>>>> *MMU off
>>>> *Instruction cache either on or off
>>>> *Data cache turned off
>>>
>>> Would recommend saying "Data cache(s) turned off" so that L2 cache is
>>> included.
>>
>> There are platforms where the L2 cache is turned on by the boot monitor
>> (secure monitor) and Linux has no control over it (I think OMAP).
>
> What is the reason for turning off the data caches?  Leaving all caches
> turned on and coherent with one another has always worked well for me at the
> interface from firmware to a booted program.

Data cache off is specified in Documentation/arm/Booting in the Linux
source tree and I used that document as a starting point to get
discussion going.  I don't have a technical argument either way.

Russell, what is the reason for having the data cache off?

g.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-26 18:13             ` Grant Likely
  0 siblings, 0 replies; 32+ messages in thread
From: Grant Likely @ 2010-03-26 18:13 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Mar 26, 2010 at 11:43 AM, Mitch Bradley <wmb@firmworks.com> wrote:
> Catalin Marinas wrote:
>> On Thu, 2010-03-25 at 21:04 +0000, Russell King - ARM Linux wrote:
>>> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
>>>> *IRQs disabled
>>>> *MMU off
>>>> *Instruction cache either on or off
>>>> *Data cache turned off
>>>
>>> Would recommend saying "Data cache(s) turned off" so that L2 cache is
>>> included.
>>
>> There are platforms where the L2 cache is turned on by the boot monitor
>> (secure monitor) and Linux has no control over it (I think OMAP).
>
> What is the reason for turning off the data caches? ?Leaving all caches
> turned on and coherent with one another has always worked well for me at the
> interface from firmware to a booted program.

Data cache off is specified in Documentation/arm/Booting in the Linux
source tree and I used that document as a starting point to get
discussion going.  I don't have a technical argument either way.

Russell, what is the reason for having the data cache off?

g.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: RFC: ARM Boot standard for passing device tree blob
  2010-03-26 18:13             ` Grant Likely
@ 2010-03-26 19:30               ` Nicolas Pitre
  -1 siblings, 0 replies; 32+ messages in thread
From: Nicolas Pitre @ 2010-03-26 19:30 UTC (permalink / raw)
  To: Grant Likely
  Cc: Russell King - ARM Linux, Catalin Marinas, devicetree-discuss,
	Philippe Robin, David Rusling, Mitch Bradley, Jeremy Kerr,
	Dave P Martin, linux-arm-kernel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1652 bytes --]

On Fri, 26 Mar 2010, Grant Likely wrote:

> On Fri, Mar 26, 2010 at 11:43 AM, Mitch Bradley <wmb@firmworks.com> wrote:
> > Catalin Marinas wrote:
> >> On Thu, 2010-03-25 at 21:04 +0000, Russell King - ARM Linux wrote:
> >>> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
> >>>> *IRQs disabled
> >>>> *MMU off
> >>>> *Instruction cache either on or off
> >>>> *Data cache turned off
> >>>
> >>> Would recommend saying "Data cache(s) turned off" so that L2 cache is
> >>> included.
> >>
> >> There are platforms where the L2 cache is turned on by the boot monitor
> >> (secure monitor) and Linux has no control over it (I think OMAP).
> >
> > What is the reason for turning off the data caches?  Leaving all caches
> > turned on and coherent with one another has always worked well for me at the
> > interface from firmware to a booted program.
> 
> Data cache off is specified in Documentation/arm/Booting in the Linux
> source tree and I used that document as a starting point to get
> discussion going.  I don't have a technical argument either way.
> 
> Russell, what is the reason for having the data cache off?

At least on machines with a VIVT cache, you need to have the MMU enabled 
for the data cache to be enabled.  That means a page table set up 
somewhere in memory, and then the kernel would need to know where that 
page table is not to overwrite it until the kernel has set its own page 
table, etc.  This makes the booting requirements more complex for very 
little gain.

So by mandating that the MMU be off (implying that the dcache has to be 
disabled too) then the kernel can set it up without restrictions.


Nicolas

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-26 19:30               ` Nicolas Pitre
  0 siblings, 0 replies; 32+ messages in thread
From: Nicolas Pitre @ 2010-03-26 19:30 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, 26 Mar 2010, Grant Likely wrote:

> On Fri, Mar 26, 2010 at 11:43 AM, Mitch Bradley <wmb@firmworks.com> wrote:
> > Catalin Marinas wrote:
> >> On Thu, 2010-03-25 at 21:04 +0000, Russell King - ARM Linux wrote:
> >>> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
> >>>> *IRQs disabled
> >>>> *MMU off
> >>>> *Instruction cache either on or off
> >>>> *Data cache turned off
> >>>
> >>> Would recommend saying "Data cache(s) turned off" so that L2 cache is
> >>> included.
> >>
> >> There are platforms where the L2 cache is turned on by the boot monitor
> >> (secure monitor) and Linux has no control over it (I think OMAP).
> >
> > What is the reason for turning off the data caches? ?Leaving all caches
> > turned on and coherent with one another has always worked well for me at the
> > interface from firmware to a booted program.
> 
> Data cache off is specified in Documentation/arm/Booting in the Linux
> source tree and I used that document as a starting point to get
> discussion going.  I don't have a technical argument either way.
> 
> Russell, what is the reason for having the data cache off?

At least on machines with a VIVT cache, you need to have the MMU enabled 
for the data cache to be enabled.  That means a page table set up 
somewhere in memory, and then the kernel would need to know where that 
page table is not to overwrite it until the kernel has set its own page 
table, etc.  This makes the booting requirements more complex for very 
little gain.

So by mandating that the MMU be off (implying that the dcache has to be 
disabled too) then the kernel can set it up without restrictions.


Nicolas

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: RFC: ARM Boot standard for passing device tree blob
  2010-03-26 19:30               ` Nicolas Pitre
@ 2010-03-26 19:52                   ` Grant Likely
  -1 siblings, 0 replies; 32+ messages in thread
From: Grant Likely @ 2010-03-26 19:52 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Russell King - ARM Linux, Catalin Marinas, devicetree-discuss,
	Philippe Robin, David Rusling, Jeremy Kerr, Dave P Martin,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Fri, Mar 26, 2010 at 1:30 PM, Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org> wrote:
> On Fri, 26 Mar 2010, Grant Likely wrote:
>
>> On Fri, Mar 26, 2010 at 11:43 AM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> wrote:
>> > Catalin Marinas wrote:
>> >> On Thu, 2010-03-25 at 21:04 +0000, Russell King - ARM Linux wrote:
>> >>> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
>> >>>> *IRQs disabled
>> >>>> *MMU off
>> >>>> *Instruction cache either on or off
>> >>>> *Data cache turned off
>> >>>
>> >>> Would recommend saying "Data cache(s) turned off" so that L2 cache is
>> >>> included.
>> >>
>> >> There are platforms where the L2 cache is turned on by the boot monitor
>> >> (secure monitor) and Linux has no control over it (I think OMAP).
>> >
>> > What is the reason for turning off the data caches?  Leaving all caches
>> > turned on and coherent with one another has always worked well for me at the
>> > interface from firmware to a booted program.
>>
>> Data cache off is specified in Documentation/arm/Booting in the Linux
>> source tree and I used that document as a starting point to get
>> discussion going.  I don't have a technical argument either way.
>>
>> Russell, what is the reason for having the data cache off?
>
> At least on machines with a VIVT cache, you need to have the MMU enabled
> for the data cache to be enabled.  That means a page table set up
> somewhere in memory, and then the kernel would need to know where that
> page table is not to overwrite it until the kernel has set its own page
> table, etc.  This makes the booting requirements more complex for very
> little gain.
>
> So by mandating that the MMU be off (implying that the dcache has to be
> disabled too) then the kernel can set it up without restrictions.

I could change the statement to something like, "virtually tagged or
indexed data cache(s) must be off", or drop the statement entirely
since it is implied by the requirement that the MMU must be off.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-26 19:52                   ` Grant Likely
  0 siblings, 0 replies; 32+ messages in thread
From: Grant Likely @ 2010-03-26 19:52 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Mar 26, 2010 at 1:30 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Fri, 26 Mar 2010, Grant Likely wrote:
>
>> On Fri, Mar 26, 2010 at 11:43 AM, Mitch Bradley <wmb@firmworks.com> wrote:
>> > Catalin Marinas wrote:
>> >> On Thu, 2010-03-25 at 21:04 +0000, Russell King - ARM Linux wrote:
>> >>> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
>> >>>> *IRQs disabled
>> >>>> *MMU off
>> >>>> *Instruction cache either on or off
>> >>>> *Data cache turned off
>> >>>
>> >>> Would recommend saying "Data cache(s) turned off" so that L2 cache is
>> >>> included.
>> >>
>> >> There are platforms where the L2 cache is turned on by the boot monitor
>> >> (secure monitor) and Linux has no control over it (I think OMAP).
>> >
>> > What is the reason for turning off the data caches? ?Leaving all caches
>> > turned on and coherent with one another has always worked well for me at the
>> > interface from firmware to a booted program.
>>
>> Data cache off is specified in Documentation/arm/Booting in the Linux
>> source tree and I used that document as a starting point to get
>> discussion going. ?I don't have a technical argument either way.
>>
>> Russell, what is the reason for having the data cache off?
>
> At least on machines with a VIVT cache, you need to have the MMU enabled
> for the data cache to be enabled. ?That means a page table set up
> somewhere in memory, and then the kernel would need to know where that
> page table is not to overwrite it until the kernel has set its own page
> table, etc. ?This makes the booting requirements more complex for very
> little gain.
>
> So by mandating that the MMU be off (implying that the dcache has to be
> disabled too) then the kernel can set it up without restrictions.

I could change the statement to something like, "virtually tagged or
indexed data cache(s) must be off", or drop the statement entirely
since it is implied by the requirement that the MMU must be off.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: RFC: ARM Boot standard for passing device tree blob
  2010-03-26 17:43         ` Mitch Bradley
@ 2010-03-26 23:00             ` Russell King - ARM Linux
  -1 siblings, 0 replies; 32+ messages in thread
From: Russell King - ARM Linux @ 2010-03-26 23:00 UTC (permalink / raw)
  To: Mitch Bradley
  Cc: Catalin Marinas, devicetree-discuss, Philippe Robin,
	David Rusling, Jeremy Kerr, Dave P Martin,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Fri, Mar 26, 2010 at 07:43:20AM -1000, Mitch Bradley wrote:
> What is the reason for turning off the data caches?  Leaving all caches  
> turned on and coherent with one another has always worked well for me at  
> the interface from firmware to a booted program.

With the data caches on, you need the MMU to be setup and operational.
That's impractical when you're passing control between differing pieces
of software which may have different ideas about how to setup the MMU
and where to place the page tables.  If you accidentally overwrite the
page tables, things quickly become undebuggable.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-26 23:00             ` Russell King - ARM Linux
  0 siblings, 0 replies; 32+ messages in thread
From: Russell King - ARM Linux @ 2010-03-26 23:00 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Mar 26, 2010 at 07:43:20AM -1000, Mitch Bradley wrote:
> What is the reason for turning off the data caches?  Leaving all caches  
> turned on and coherent with one another has always worked well for me at  
> the interface from firmware to a booted program.

With the data caches on, you need the MMU to be setup and operational.
That's impractical when you're passing control between differing pieces
of software which may have different ideas about how to setup the MMU
and where to place the page tables.  If you accidentally overwrite the
page tables, things quickly become undebuggable.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: RFC: ARM Boot standard for passing device tree blob
  2010-03-26 19:52                   ` Grant Likely
@ 2010-03-26 23:03                       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 32+ messages in thread
From: Russell King - ARM Linux @ 2010-03-26 23:03 UTC (permalink / raw)
  To: Grant Likely
  Cc: Nicolas Pitre, Catalin Marinas, devicetree-discuss,
	Philippe Robin, David Rusling, Jeremy Kerr, Dave P Martin,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Fri, Mar 26, 2010 at 01:52:24PM -0600, Grant Likely wrote:
> I could change the statement to something like, "virtually tagged or
> indexed data cache(s) must be off", or drop the statement entirely
> since it is implied by the requirement that the MMU must be off.

1. We're not going down the path of having differing conditions for
   different caches; to do so would mean that we'd need to have two
   entirely different sets of code to handle booting in the kernel.

2. No ARM CPU supports having the D-cache enabled without the MMU; the
   data cache needs to be told via the page tables what can be cached
   and what can't - it needs to be told that RAM can cached but IO
   devices must not be.

In short, the MMU must always be off, which in turn means the D-cache
must always be disabled.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-26 23:03                       ` Russell King - ARM Linux
  0 siblings, 0 replies; 32+ messages in thread
From: Russell King - ARM Linux @ 2010-03-26 23:03 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Mar 26, 2010 at 01:52:24PM -0600, Grant Likely wrote:
> I could change the statement to something like, "virtually tagged or
> indexed data cache(s) must be off", or drop the statement entirely
> since it is implied by the requirement that the MMU must be off.

1. We're not going down the path of having differing conditions for
   different caches; to do so would mean that we'd need to have two
   entirely different sets of code to handle booting in the kernel.

2. No ARM CPU supports having the D-cache enabled without the MMU; the
   data cache needs to be told via the page tables what can be cached
   and what can't - it needs to be told that RAM can cached but IO
   devices must not be.

In short, the MMU must always be off, which in turn means the D-cache
must always be disabled.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RE: RFC: ARM Boot standard for passing device tree blob
  2010-03-26 23:03                       ` Russell King - ARM Linux
@ 2010-03-29 11:24                         ` Dave P. Martin
  -1 siblings, 0 replies; 32+ messages in thread
From: Dave P. Martin @ 2010-03-29 11:24 UTC (permalink / raw)
  To: 'Russell King - ARM Linux', Grant Likely
  Cc: Nicolas Pitre, Catalin Marinas, devicetree-discuss,
	Philippe Robin, David Rusling, Mitch Bradley, Jeremy Kerr,
	linux-arm-kernel

Hi

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk] 
> Sent: 26 March 2010 23:04
> To: Grant Likely
> Cc: Nicolas Pitre; Mitch Bradley; Catalin Marinas; 
> devicetree-discuss; Philippe Robin; David Rusling; Jeremy 
> Kerr; Dave P Martin; linux-arm-kernel@lists.infradead.org
> Subject: Re: RFC: ARM Boot standard for passing device tree blob

[...]

> 2. No ARM CPU supports having the D-cache enabled without the MMU; the
>    data cache needs to be told via the page tables what can be cached
>    and what can't - it needs to be told that RAM can cached but IO
>    devices must not be.
> 
> In short, the MMU must always be off, which in turn means the 
> D-cache must always be disabled.

Further to this, it's worth pointing out that some systems have external
caches (such as non-architected L2 cache etc.) which are not integrated into
the the CPU.  If we allow D-cache to be turned on at all, we would have to
be clear that external caches must be turned off or configured in a very
precise way in order to avoid breaking the kernel's bootstrap process.  This
is especially important when assumptions about the cache arrangement are not
fixed at build time (in the device tree context, such assumptions generally
won't be completely fixed).  There's a potential world of problems here---
it seems best avoided.

It could be worth clarifying that the L1 I-cache is the _only_ cache which
is permitted to be enabled at kernel entry, and that all other caches in the
system must be disabled.

Cheers
---Dave

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-29 11:24                         ` Dave P. Martin
  0 siblings, 0 replies; 32+ messages in thread
From: Dave P. Martin @ 2010-03-29 11:24 UTC (permalink / raw)
  To: linux-arm-kernel

Hi

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk] 
> Sent: 26 March 2010 23:04
> To: Grant Likely
> Cc: Nicolas Pitre; Mitch Bradley; Catalin Marinas; 
> devicetree-discuss; Philippe Robin; David Rusling; Jeremy 
> Kerr; Dave P Martin; linux-arm-kernel at lists.infradead.org
> Subject: Re: RFC: ARM Boot standard for passing device tree blob

[...]

> 2. No ARM CPU supports having the D-cache enabled without the MMU; the
>    data cache needs to be told via the page tables what can be cached
>    and what can't - it needs to be told that RAM can cached but IO
>    devices must not be.
> 
> In short, the MMU must always be off, which in turn means the 
> D-cache must always be disabled.

Further to this, it's worth pointing out that some systems have external
caches (such as non-architected L2 cache etc.) which are not integrated into
the the CPU.  If we allow D-cache to be turned on at all, we would have to
be clear that external caches must be turned off or configured in a very
precise way in order to avoid breaking the kernel's bootstrap process.  This
is especially important when assumptions about the cache arrangement are not
fixed at build time (in the device tree context, such assumptions generally
won't be completely fixed).  There's a potential world of problems here---
it seems best avoided.

It could be worth clarifying that the L1 I-cache is the _only_ cache which
is permitted to be enabled at kernel entry, and that all other caches in the
system must be disabled.

Cheers
---Dave

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: RFC: ARM Boot standard for passing device tree blob
  2010-03-29 11:24                         ` Dave P. Martin
@ 2010-03-30  0:26                           ` Jamie Lokier
  -1 siblings, 0 replies; 32+ messages in thread
From: Jamie Lokier @ 2010-03-30  0:26 UTC (permalink / raw)
  To: Dave P. Martin
  Cc: 'Russell King - ARM Linux',
	Nicolas Pitre, Catalin Marinas, devicetree-discuss, Grant Likely,
	Philippe Robin, David Rusling, Mitch Bradley, Jeremy Kerr,
	linux-arm-kernel

Dave P. Martin wrote:
> Hi
> 
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk] 
> > Sent: 26 March 2010 23:04
> > To: Grant Likely
> > Cc: Nicolas Pitre; Mitch Bradley; Catalin Marinas; 
> > devicetree-discuss; Philippe Robin; David Rusling; Jeremy 
> > Kerr; Dave P Martin; linux-arm-kernel@lists.infradead.org
> > Subject: Re: RFC: ARM Boot standard for passing device tree blob
> 
> [...]
> 
> > 2. No ARM CPU supports having the D-cache enabled without the MMU; the
> >    data cache needs to be told via the page tables what can be cached
> >    and what can't - it needs to be told that RAM can cached but IO
> >    devices must not be.
> > 
> > In short, the MMU must always be off, which in turn means the 
> > D-cache must always be disabled.
> 
> Further to this, it's worth pointing out that some systems have external
> caches (such as non-architected L2 cache etc.) which are not integrated into
> the the CPU.  If we allow D-cache to be turned on at all, we would have to
> be clear that external caches must be turned off or configured in a very
> precise way in order to avoid breaking the kernel's bootstrap process.  This
> is especially important when assumptions about the cache arrangement are not
> fixed at build time (in the device tree context, such assumptions generally
> won't be completely fixed).  There's a potential world of problems here---
> it seems best avoided.
> 
> It could be worth clarifying that the L1 I-cache is the _only_ cache which
> is permitted to be enabled at kernel entry, and that all other caches in the
> system must be disabled.

Catalin said that on some platforms, the L2 cache is unavoidably
enabled by the time of kernel boot and it cannot be turned off.
So the above cannot be satisfied.

-- Jamie

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-30  0:26                           ` Jamie Lokier
  0 siblings, 0 replies; 32+ messages in thread
From: Jamie Lokier @ 2010-03-30  0:26 UTC (permalink / raw)
  To: linux-arm-kernel

Dave P. Martin wrote:
> Hi
> 
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk] 
> > Sent: 26 March 2010 23:04
> > To: Grant Likely
> > Cc: Nicolas Pitre; Mitch Bradley; Catalin Marinas; 
> > devicetree-discuss; Philippe Robin; David Rusling; Jeremy 
> > Kerr; Dave P Martin; linux-arm-kernel at lists.infradead.org
> > Subject: Re: RFC: ARM Boot standard for passing device tree blob
> 
> [...]
> 
> > 2. No ARM CPU supports having the D-cache enabled without the MMU; the
> >    data cache needs to be told via the page tables what can be cached
> >    and what can't - it needs to be told that RAM can cached but IO
> >    devices must not be.
> > 
> > In short, the MMU must always be off, which in turn means the 
> > D-cache must always be disabled.
> 
> Further to this, it's worth pointing out that some systems have external
> caches (such as non-architected L2 cache etc.) which are not integrated into
> the the CPU.  If we allow D-cache to be turned on at all, we would have to
> be clear that external caches must be turned off or configured in a very
> precise way in order to avoid breaking the kernel's bootstrap process.  This
> is especially important when assumptions about the cache arrangement are not
> fixed at build time (in the device tree context, such assumptions generally
> won't be completely fixed).  There's a potential world of problems here---
> it seems best avoided.
> 
> It could be worth clarifying that the L1 I-cache is the _only_ cache which
> is permitted to be enabled at kernel entry, and that all other caches in the
> system must be disabled.

Catalin said that on some platforms, the L2 cache is unavoidably
enabled by the time of kernel boot and it cannot be turned off.
So the above cannot be satisfied.

-- Jamie

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RE: RFC: ARM Boot standard for passing device tree blob
  2010-03-30  0:26                           ` Jamie Lokier
@ 2010-03-30 13:32                               ` Dave P. Martin
  -1 siblings, 0 replies; 32+ messages in thread
From: Dave P. Martin @ 2010-03-30 13:32 UTC (permalink / raw)
  To: 'Jamie Lokier'
  Cc: 'Russell King - ARM Linux',
	Nicolas Pitre, Catalin Marinas, devicetree-discuss,
	Philippe Robin, David Rusling, Jeremy Kerr,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

Hi,

> -----Original Message-----
> From: Jamie Lokier [mailto:jamie-yetKDKU6eevNLxjTenLetw@public.gmane.org] 
> Sent: 30 March 2010 01:27

[...]

> > It could be worth clarifying that the L1 I-cache is the 
> _only_ cache 
> > which is permitted to be enabled at kernel entry, and that 
> all other 
> > caches in the system must be disabled.
> 
> Catalin said that on some platforms, the L2 cache is 
> unavoidably enabled by the time of kernel boot and it cannot 
> be turned off.
> So the above cannot be satisfied.

OK, good catch--- that slipped my mind.

I think the real requirement is that the kernel needs to be able to do
I-side/D-side synchronisation at L1 (so that the kernel decompression phase
works).  Other than this, we shouldn't need to do anything except access RAM
until the device tree framework has discovered the cache configuration.

So it seems adequate to require that:

* The MMU must be off

* For architected caches (i.e., those managed via CP15 operations):
	* I-caches may be turned on
	* D-caches and unified caches must be clean, invalidated and turned
off

* For non-architectured caches (those managed via implementation-specific
mechanisms):
      * Wherever possible, these caches should be clean, invalidated and
turned off.  Otherwise:
	* external unified caches must be clean and invalidated (the common
case)
	* external Harvard caches must be clean, invalidated and turned off
(don't know if we have observed external Harvard caches in any design)

I'll try and get additional clarification from my side on whether we're
missing any important issue here.

Cheers
---Dave

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-30 13:32                               ` Dave P. Martin
  0 siblings, 0 replies; 32+ messages in thread
From: Dave P. Martin @ 2010-03-30 13:32 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

> -----Original Message-----
> From: Jamie Lokier [mailto:jamie at shareable.org] 
> Sent: 30 March 2010 01:27

[...]

> > It could be worth clarifying that the L1 I-cache is the 
> _only_ cache 
> > which is permitted to be enabled at kernel entry, and that 
> all other 
> > caches in the system must be disabled.
> 
> Catalin said that on some platforms, the L2 cache is 
> unavoidably enabled by the time of kernel boot and it cannot 
> be turned off.
> So the above cannot be satisfied.

OK, good catch--- that slipped my mind.

I think the real requirement is that the kernel needs to be able to do
I-side/D-side synchronisation at L1 (so that the kernel decompression phase
works).  Other than this, we shouldn't need to do anything except access RAM
until the device tree framework has discovered the cache configuration.

So it seems adequate to require that:

* The MMU must be off

* For architected caches (i.e., those managed via CP15 operations):
	* I-caches may be turned on
	* D-caches and unified caches must be clean, invalidated and turned
off

* For non-architectured caches (those managed via implementation-specific
mechanisms):
      * Wherever possible, these caches should be clean, invalidated and
turned off.  Otherwise:
	* external unified caches must be clean and invalidated (the common
case)
	* external Harvard caches must be clean, invalidated and turned off
(don't know if we have observed external Harvard caches in any design)

I'll try and get additional clarification from my side on whether we're
missing any important issue here.

Cheers
---Dave

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: RFC: ARM Boot standard for passing device tree blob
  2010-03-26 17:43         ` Mitch Bradley
@ 2010-03-31  1:10           ` Ben Dooks
  -1 siblings, 0 replies; 32+ messages in thread
From: Ben Dooks @ 2010-03-31  1:10 UTC (permalink / raw)
  To: Mitch Bradley
  Cc: Russell King - ARM Linux, Catalin Marinas, devicetree-discuss,
	Philippe Robin, David Rusling, Jeremy Kerr, Dave P Martin,
	linux-arm-kernel

On Fri, Mar 26, 2010 at 07:43:20AM -1000, Mitch Bradley wrote:
> Catalin Marinas wrote:
>> On Thu, 2010-03-25 at 21:04 +0000, Russell King - ARM Linux wrote:
>>   
>>> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
>>>     
>>>> ===Required System State===
>>>>       
>> [...]
>>   
>>>> *IRQs disabled
>>>> *MMU off
>>>> *Instruction cache either on or off
>>>> *Data cache turned off
>>>>       
>>> Would recommend saying "Data cache(s) turned off" so that L2 cache is
>>> included.
>>>     
>>
>> There are platforms where the L2 cache is turned on by the boot monitor
>> (secure monitor) and Linux has no control over it (I think OMAP).
>>   
>
> What is the reason for turning off the data caches?  Leaving all caches  
> turned on and coherent with one another has always worked well for me at  
> the interface from firmware to a booted program.

Dealing with cache maintainace early in the kernel is difficult, you
end up with piles of ASM replicated from the arm mm to deal with
coherency, code modification due to decompression, etc.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* RFC: ARM Boot standard for passing device tree blob
@ 2010-03-31  1:10           ` Ben Dooks
  0 siblings, 0 replies; 32+ messages in thread
From: Ben Dooks @ 2010-03-31  1:10 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Mar 26, 2010 at 07:43:20AM -1000, Mitch Bradley wrote:
> Catalin Marinas wrote:
>> On Thu, 2010-03-25 at 21:04 +0000, Russell King - ARM Linux wrote:
>>   
>>> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
>>>     
>>>> ===Required System State===
>>>>       
>> [...]
>>   
>>>> *IRQs disabled
>>>> *MMU off
>>>> *Instruction cache either on or off
>>>> *Data cache turned off
>>>>       
>>> Would recommend saying "Data cache(s) turned off" so that L2 cache is
>>> included.
>>>     
>>
>> There are platforms where the L2 cache is turned on by the boot monitor
>> (secure monitor) and Linux has no control over it (I think OMAP).
>>   
>
> What is the reason for turning off the data caches?  Leaving all caches  
> turned on and coherent with one another has always worked well for me at  
> the interface from firmware to a booted program.

Dealing with cache maintainace early in the kernel is difficult, you
end up with piles of ASM replicated from the arm mm to deal with
coherency, code modification due to decompression, etc.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

^ permalink raw reply	[flat|nested] 32+ messages in thread

end of thread, other threads:[~2010-03-31  1:10 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-24 15:11 RFC: ARM Boot standard for passing device tree blob Grant Likely
2010-03-24 15:11 ` Grant Likely
2010-03-25 21:04 ` Russell King - ARM Linux
2010-03-25 21:04   ` Russell King - ARM Linux
     [not found]   ` <20100325210409.GH24984-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2010-03-25 23:40     ` David Gibson
2010-03-25 23:40       ` David Gibson
2010-03-26  0:23       ` Jeremy Kerr
2010-03-26  0:23         ` Jeremy Kerr
2010-03-26  3:24     ` Grant Likely
2010-03-26  3:24       ` Grant Likely
2010-03-26 13:37   ` Catalin Marinas
2010-03-26 13:37     ` Catalin Marinas
     [not found]     ` <1269610665.807.51.camel-uqmqopRKlSLZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2010-03-26 17:43       ` Mitch Bradley
2010-03-26 17:43         ` Mitch Bradley
     [not found]         ` <4BACF238.3040405-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2010-03-26 18:13           ` Grant Likely
2010-03-26 18:13             ` Grant Likely
2010-03-26 19:30             ` Nicolas Pitre
2010-03-26 19:30               ` Nicolas Pitre
     [not found]               ` <alpine.LFD.2.00.1003261435460.694-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-03-26 19:52                 ` Grant Likely
2010-03-26 19:52                   ` Grant Likely
     [not found]                   ` <fa686aa41003261252u7dc31bb6nca2e77ae8feb4355-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-03-26 23:03                     ` Russell King - ARM Linux
2010-03-26 23:03                       ` Russell King - ARM Linux
2010-03-29 11:24                       ` Dave P. Martin
2010-03-29 11:24                         ` Dave P. Martin
2010-03-30  0:26                         ` Jamie Lokier
2010-03-30  0:26                           ` Jamie Lokier
     [not found]                           ` <20100330002638.GI9876-yetKDKU6eevNLxjTenLetw@public.gmane.org>
2010-03-30 13:32                             ` Dave P. Martin
2010-03-30 13:32                               ` Dave P. Martin
2010-03-26 23:00           ` Russell King - ARM Linux
2010-03-26 23:00             ` Russell King - ARM Linux
2010-03-31  1:10         ` Ben Dooks
2010-03-31  1:10           ` Ben Dooks

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.