diff mbox

[U-Boot,1/6] add README.distro file

Message ID 1395353581-5839-2-git-send-email-dennis@ausil.us
State Changes Requested
Delegated to: Tom Rini
Headers show

Commit Message

Dennis Gilmore March 20, 2014, 10:12 p.m. UTC
Add documentation on how to setup a system to use the generic distro
configs and boot commands. This spells out what is needed to make a
system conformant, but does not limit the board to only the defaults.

Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
 doc/README.distro | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 doc/README.distro

Comments

Tom Rini March 21, 2014, 6:48 p.m. UTC | #1
On Thu, Mar 20, 2014 at 05:12:56PM -0500, Dennis Gilmore wrote:

> Add documentation on how to setup a system to use the generic distro
> configs and boot commands. This spells out what is needed to make a
> system conformant, but does not limit the board to only the defaults.
> 
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>

[snip]
> +suggested mapping:
> +For suggestions on memory locations for arm systems  you must follow the
> +guidelines specified in Documentation/arm/Booting in the Linux kernel tree.
> +For other architectures you must follow the guidelines for the architecture.

Can you add something about what this means?  ie below base+128MB for
kernel, because of this if possible base+128MB for fdt, fdt+512KB for
ramdisk. And mention bootm_size to limit the relocation pool as well.  

Thanks!
Stephen Warren March 25, 2014, 8:24 p.m. UTC | #2
On 03/20/2014 04:12 PM, Dennis Gilmore wrote:
> Add documentation on how to setup a system to use the generic distro
> configs and boot commands. This spells out what is needed to make a
> system conformant, but does not limit the board to only the defaults.

> diff --git a/doc/README.distro b/doc/README.distro

> +There is some memory addresses you will need to define in
> +CONFIG_EXTRA_ENV_SETTINGS
> +fdt_addr:
> +Optional, If specified a dtb to boot the system must be available at the given
> +address.

Perhaps add "when the kernel is booted"? To avoid someone putting it
somewhere that will get over-written between when U-Boot starts and the
kernel is booted.

> +fdt_addr_r:
> +Mandatory, This is the location where the sysboot/pxeboot with load the dtb to,

s/with/will/ Both here and other place(s).

> +using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux
> +config file. The location can be anywhere in ram it just needs to not overlap
> +with anything, allowing 1 megabyte seems to be a safe option.

Related to Tom's comments, I think saying that the location doesn't
matter isn't quite true. For example, an ARM zImage assumes it's located
with the first 128M of RAM, and will decompress the image to the start
of RAM. If the DTB was located in the decompression target region, it
would at least need to be moved by the decompressor (wasted effort) or
perhaps just get blindly over-written (boot fails).

> +ramdisk_addr_r:
> +Mandatory, This is the location where the sysboot/pxeboot with load the
> +initramfs to, using the initrd option in the pxe/extlinux config file, the
> +location of the initramfs does not matter, there needs to be enough room to be
> +able to store any image. Making the image the last item stored should allow for
> +any initramfs to fit and not overwrite anything else.

"last item" could refer to time not space. Perhaps s/Making the image
the last item stored/Placing the image higher in RAM than any other image/

> +kernel_addr_r:
> +Mandatory, This is the location where the sysboot/pxeboot with load the kernel
> +to,using the kernel option in the pxe/extlinux config file, the location of the
> +kernel needs to 

That sentence isn't complete.

> +You should not set initrd_high and fdt_high to 0xffffffff as the user should
> +not need to edit the memory locations having the initramfs and dtb being
> +relocatable is best to ensure the system will boot in all situations. 

Perhaps CONFIG_SYS_BOOTMAPSZ is worth a mention too. The commit
description for 7f1b767aea94 "ARM: tegra: define CONFIG_SYS_BOOTMAPSZ"
might be useful when writing this part of the document.

> +booting your system
> +-------------------
> +in the most simplest form CONFIG_BOOTCOMMAND just needs one line
> +
> +"for target in ${boot_targets}; do run bootcmd_${target}; done "
> +
> +you can run any setup before going through the targets for example run a
> +command to set "fdtfile" variable for the dtb for your board.

Isn't this automatic based on using config_distro_defaults.h? It seems
like it should be, and it is were, you wouldn't need this section of
this document at all; it's happen automatically.
Stephen Warren March 25, 2014, 8:40 p.m. UTC | #3
On 03/21/2014 12:48 PM, Tom Rini wrote:
> On Thu, Mar 20, 2014 at 05:12:56PM -0500, Dennis Gilmore wrote:
> 
>> Add documentation on how to setup a system to use the generic distro
>> configs and boot commands. This spells out what is needed to make a
>> system conformant, but does not limit the board to only the defaults.
>>
>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> 
> [snip]
>> +suggested mapping:
>> +For suggestions on memory locations for arm systems  you must follow the
>> +guidelines specified in Documentation/arm/Booting in the Linux kernel tree.
>> +For other architectures you must follow the guidelines for the architecture.
> 
> Can you add something about what this means?  ie below base+128MB for
> kernel, because of this if possible base+128MB for fdt, fdt+512KB for
> ramdisk. And mention bootm_size to limit the relocation pool as well.  

I'm biased, but I like the explanations in
include/configs/tegraNN-common.h:-)
Tom Rini March 28, 2014, 3:42 p.m. UTC | #4
On Tue, Mar 25, 2014 at 02:24:14PM -0600, Stephen Warren wrote:
> On 03/20/2014 04:12 PM, Dennis Gilmore wrote:
[snip]
> > +You should not set initrd_high and fdt_high to 0xffffffff as the user should
> > +not need to edit the memory locations having the initramfs and dtb being
> > +relocatable is best to ensure the system will boot in all situations. 
> 
> Perhaps CONFIG_SYS_BOOTMAPSZ is worth a mention too. The commit
> description for 7f1b767aea94 "ARM: tegra: define CONFIG_SYS_BOOTMAPSZ"
> might be useful when writing this part of the document.

I would swear (and I just dug up the notes from the last time I was
looking at this) that no, CONFIG_SYS_BOOTMAPSZ is not sufficient because
it doesn't cover the ramdisk case, which is important for generic
distro, unless you also add in initrd_high=top-of-lowmem-value or know
it'll be in an always-good spot and set it to 0xffffffff.
Stephen Warren March 28, 2014, 4:11 p.m. UTC | #5
On 03/28/2014 09:42 AM, Tom Rini wrote:
> On Tue, Mar 25, 2014 at 02:24:14PM -0600, Stephen Warren wrote:
>> On 03/20/2014 04:12 PM, Dennis Gilmore wrote:
> [snip]
>>> +You should not set initrd_high and fdt_high to 0xffffffff as the user should
>>> +not need to edit the memory locations having the initramfs and dtb being
>>> +relocatable is best to ensure the system will boot in all situations. 
>>
>> Perhaps CONFIG_SYS_BOOTMAPSZ is worth a mention too. The commit
>> description for 7f1b767aea94 "ARM: tegra: define CONFIG_SYS_BOOTMAPSZ"
>> might be useful when writing this part of the document.
> 
> I would swear (and I just dug up the notes from the last time I was
> looking at this) that no, CONFIG_SYS_BOOTMAPSZ is not sufficient because
> it doesn't cover the ramdisk case, which is important for generic
> distro, unless you also add in initrd_high=top-of-lowmem-value or know
> it'll be in an always-good spot and set it to 0xffffffff.

Isn't that a bug? In other words, shouldn't CONFIG_SYS_BOOTMAPSZ affect
a ramdisk too?
Tom Rini March 28, 2014, 4:25 p.m. UTC | #6
On Fri, Mar 28, 2014 at 10:11:20AM -0600, Stephen Warren wrote:
> On 03/28/2014 09:42 AM, Tom Rini wrote:
> > On Tue, Mar 25, 2014 at 02:24:14PM -0600, Stephen Warren wrote:
> >> On 03/20/2014 04:12 PM, Dennis Gilmore wrote:
> > [snip]
> >>> +You should not set initrd_high and fdt_high to 0xffffffff as the user should
> >>> +not need to edit the memory locations having the initramfs and dtb being
> >>> +relocatable is best to ensure the system will boot in all situations. 
> >>
> >> Perhaps CONFIG_SYS_BOOTMAPSZ is worth a mention too. The commit
> >> description for 7f1b767aea94 "ARM: tegra: define CONFIG_SYS_BOOTMAPSZ"
> >> might be useful when writing this part of the document.
> > 
> > I would swear (and I just dug up the notes from the last time I was
> > looking at this) that no, CONFIG_SYS_BOOTMAPSZ is not sufficient because
> > it doesn't cover the ramdisk case, which is important for generic
> > distro, unless you also add in initrd_high=top-of-lowmem-value or know
> > it'll be in an always-good spot and set it to 0xffffffff.
> 
> Isn't that a bug? In other words, shouldn't CONFIG_SYS_BOOTMAPSZ affect
> a ramdisk too?

No, because it's a per-arch thing on if you can have a ramdisk in high
memory or not (and then the kernel deals with it), iirc.  I _think_ this
is one of those cases where ARM is much more strict about things than
other architectures, but I lack the easy access to other platforms that
I used to have.
diff mbox

Patch

diff --git a/doc/README.distro b/doc/README.distro
new file mode 100644
index 0000000..435c578
--- /dev/null
+++ b/doc/README.distro
@@ -0,0 +1,76 @@ 
+/*
+ * (C) Copyright 2014 Red Hat Inc.
+ *
+ * SPDX-License-Identifier:     GPL-2.0+
+ */
+
+Generic distro configuration
+----------------------------
+
+configuring
+-----------
+To configure a board to run the generic distro setup and enable generic distros
+to easily support your board.
+
+you will need to include a pair of headers to enable the boot environment and
+configuration options needed. It is best to only include when not doing an
+SPL build.
+
+#ifndef CONFIG_SPL_BUILD
+#include <config_distro_defaults.h>
+#include <config_distro_bootcmd.h>
+#endif
+
+There is some memory addresses you will need to define in
+CONFIG_EXTRA_ENV_SETTINGS
+fdt_addr:
+Optional, If specified a dtb to boot the system must be available at the given
+address.
+
+fdt_addr_r:
+Mandatory, This is the location where the sysboot/pxeboot with load the dtb to,
+using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux
+config file. The location can be anywhere in ram it just needs to not overlap
+with anything, allowing 1 megabyte seems to be a safe option.
+
+ramdisk_addr_r:
+Mandatory, This is the location where the sysboot/pxeboot with load the
+initramfs to, using the initrd option in the pxe/extlinux config file, the
+location of the initramfs does not matter, there needs to be enough room to be
+able to store any image. Making the image the last item stored should allow for
+any initramfs to fit and not overwrite anything else.
+
+kernel_addr_r:
+Mandatory, This is the location where the sysboot/pxeboot with load the kernel
+to,using the kernel option in the pxe/extlinux config file, the location of the
+kernel needs to 
+
+pxe_addr_r:
+Mandatory, used by the PXE code to hold the pxelinux config file. The location
+can be anywhere in ram it just needs to not overlap with anything, allowing 1 
+megabyte seems to be a safe option.
+
+scriptaddr:
+Mandatory, used to load boot.scr to The location can be anywhere in ram it just
+needs to not overlap with anything, allowing 1 megabyte seems to be a safe
+option.
+
+suggested mapping:
+For suggestions on memory locations for arm systems  you must follow the
+guidelines specified in Documentation/arm/Booting in the Linux kernel tree.
+For other architectures you must follow the guidelines for the architecture.
+
+make sure you also include BOOTCMDS_COMMON in CONFIG_EXTRA_ENV_SETTINGS
+
+You should not set initrd_high and fdt_high to 0xffffffff as the user should
+not need to edit the memory locations having the initramfs and dtb being
+relocatable is best to ensure the system will boot in all situations. 
+
+booting your system
+-------------------
+in the most simplest form CONFIG_BOOTCOMMAND just needs one line
+
+"for target in ${boot_targets}; do run bootcmd_${target}; done "
+
+you can run any setup before going through the targets for example run a
+command to set "fdtfile" variable for the dtb for your board.