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 22:28:01 -0400 [thread overview]
Message-ID: <46B92A31.60703@gmail.com> (raw)
In-Reply-To: <20070807192119.6E2143535CD@atlas.denx.de>
Wolfgang Denk wrote:
> Dear Andy,
>
> in message <2acbd3e40708071212y6396de53l49b8b48e6aab9a5f@mail.gmail.com> you wrote:
>> On e500, the blob *must* be in the low 16M of memory. MUST. The low
>> 16M is all that is mapped, and the kernel will not map more than that
>> until it reads the blob. Certainly, it doesn't *always* need to be
>> relocated. It's been a while since I created this patch, but I
>
> I think the blob should only be copied (to me "relocate" involves more
> complex operations than just copying) when necessary.
>
> And I guess this restriction is also true for ramdisk images, or am I
> wrong?
>
> In any case, I think it wouldbe a good idea if the 16M limit was not
> hard wired, but could be overwritten using the "initrd_high" variable
> like we can do for ramdisks.
>
> What do you think?
>
>> I probably need to respin it, though. I haven't updated it since I
>> first created it, and you may have changed the fdt code, since.
>
> Thanks.
>
> Best regards,
>
> Wolfgang Denk
Hi Andy, Wolfgang,
The chunk I questioned was:
> @@ -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;
> } else if (ntohl(hdr->ih_magic) == IH_MAGIC) {
> printf("## Flat Device Tree Image at %08lX\n", hdr);
> print_image_hdr(hdr);
Hi Andy,
IMHO, you are abusing unrelated logic to force the blob to be copied.
Why not directly add the logic you want rather than removing the flash
logic (warning, untested code):
#ifdef CFG_BOOTMAPSZ
/*
* The blob MUST be within CFG_BOOTMAPSZ, flag it to
* be copied if not.
*/
if (of_flat_tree >= CFG_BOOTMAPSZ)
of_data = of_flat_tree;
#endif
Best regards,
gvb
P.S. The way of_data is used makes my head hurt - combined
boolean/address masquerading as an int used by various unrelated
snippets of logic (all uncommented) to achieve a single goal.
next prev parent reply other threads:[~2007-08-08 2:28 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
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 [this message]
-- 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=46B92A31.60703@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox