public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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.

  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