From: Jerry Van Baren <gvb.uboot@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] Fix initrd booting
Date: Tue, 07 Aug 2007 09:54:57 -0400 [thread overview]
Message-ID: <46B879B1.4020207@gmail.com> (raw)
In-Reply-To: <11864192383459-git-send-email-afleming@freescale.com>
Hi Andy,
I'm not sure if you are aiming this at u-boot-fdt, which would be
logical, or if you are aiming this at u-boot-testing (or other). Care
to clarify?
Andy Fleming wrote:
> The device tree needs to be passed to Linux within CFG_BOOTMAPSZ.
> The current code places the device tree right before the initrd
> if it exists, and that will usually be closer to the end of
> memory. Instead, we should always put the device tree right
> before the bd_info structure, thus ensuring it is within
> CFG_BOOTMAPSZ.
>
> We do, however, allow for FDTs in uImages to shoot themselves in
> the foot by requesting a location outside of CFG_BOOTMAPSZ.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
> common/cmd_bootm.c | 20 ++++++++------------
> 1 files changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> index a6499e8..d12ef76 100644
> --- a/common/cmd_bootm.c
> +++ b/common/cmd_bootm.c
> @@ -753,10 +753,7 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int flag,
> #else
> if (*(ulong *)of_flat_tree == OF_DT_HEADER) {
> #endif
> -#ifndef CFG_NO_FLASH
> - if (addr2info((ulong)of_flat_tree) != NULL)
> - of_data = (ulong)of_flat_tree;
> -#endif
> + of_data = (ulong)of_flat_tree;
Is this right? The logic in bootm *in general* and specifically here is
hard to figure out, but the way I'm puzzling it out...
1) If of_data is *not* NULL, it is used as the indicator that the blob
must be relocated.
2) The above is saying that, if there is flash (not defined CFG_NO_FLASH
gaak) and if of_flat_tree points into flash (addr2info returns a
pointer), then of_data is set which makes #1 true.
As I read it, this causes the blob to be copied to RAM if it is in
flash, which is necessary since we cannot add/rewrite nodes and
properties in a flash copy.
Your change causes the blob to _always_ be relocated. Not necessarily
bad, but is it always good? I'm not a bootm expert by any means, and I
suspect the complexity grew substantially over time, but in the mucking
about I did, I did not dare to change the logic. :-/
> } else if (ntohl(hdr->ih_magic) == IH_MAGIC) {
> printf("## Flat Device Tree Image at %08lX\n", hdr);
> print_image_hdr(hdr);
[snip]
Thanks,
gvb
next prev parent reply other threads:[~2007-08-07 13:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-06 16:53 [U-Boot-Users] [PATCH] Fix initrd booting Andy Fleming
2007-08-07 13:54 ` Jerry Van Baren [this message]
2007-08-07 14:36 ` Wolfgang Denk
2007-08-07 19:12 ` Andy Fleming
2007-08-07 19:21 ` Wolfgang Denk
2007-08-08 2:28 ` Jerry Van Baren
-- strict thread matches above, loose matches on Subject: below --
2007-05-17 23:08 Andy Fleming
2007-06-01 22:09 ` Andy Fleming
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46B879B1.4020207@gmail.com \
--to=gvb.uboot@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.