[U-Boot-Users] Can U-boot Autodetect arch/ppcversusarch/powerpc from info in the uImage?

[Joakim Tjernlund]

On Fri, 2007-12-14 at 00:03 +0100, Joakim Tjernlund wrote:
> > -----Original Message-----
> > From: Jerry Van Baren [mailto:gerald.vanbaren at ge.com] 
> > Sent: den 13 december 2007 19:49
> > To: Wolfgang Denk
> > Cc: joakim.tjernlund at transmode.se; u-boot-users at lists.sourceforge.net
> > Subject: Re: [U-Boot-Users] Can U-boot Autodetect 
> > arch/ppcversusarch/powerpc from info in the uImage?
> > 
> > Wolfgang Denk wrote:
> > > In message 
> > <1197205927.937.51.camel at gentoo-jocke.transmode.se> you wrote:
> > >> Made a new patch with Jerrys comments addressed. Also renamed
> > >> DEFAULT_OF_TREE to CFG_OF_TREE. OK?
> > > 
> > > I still object against this modification.
> > > 
> > >> +#ifdef CFG_OF_TREE
> > >> +	char	*of_flat_tree = CFG_OF_TREE;
> > >> +#else
> > >>  	char	*of_flat_tree = NULL;
> > >> +#endif
> > >>  	ulong	of_data = 0;
> > >>  #endif
> > > 
> > > I hereby NAK this patch for 3 reasons:
> > > 
> > > 1) The patch does not solve a problem. Instead of hardwiring the
> > >    address, you can just pass it as argument to the bootm command
> > >    which seems more straightforward to me
> > > 
> > > 2) The patch causes confusion. Documented behaviour is that "bootm"
> > >    with one or two arguments (kernel address, or kernel plus ramdisk
> > >    addresses) will boot a non-OF enabled kernel. With this patch,
> > >    "bootm" will behave different on systems where the 
> > CFG_OF_TREE has
> > >    been selected - which is usually not known to and cannot be
> > >    checked by the end user, thus causing confusion.
> > > 
> > > 3) With the patch applied and CFG_OF_TREE defined, there is 
> > no way to
> > >    boot a non-OF kernel, thus breaking backward compatibility.
> > > 
> > > Best regards,
> > > 
> > > Wolfgang Denk
> > 
> > FWIIW, #2 and #3 are serious problems that I had not 
> > considered when I 
> > supported Jocke's proposed patch.  Sorry, Jocke, but I have 
> > to side with 
> > Wolfgang in light of those arguments.
> 
> Right and I havn't been able to come up with a solution to that either.
> So I am looking at passing a $dtb to bootm.
> 
> I noticed that I could define dtb i HUSH only by
> dtb=0x12345678
> Is it possible to do that from within board code too?
> 
> If so I don't have to worry about deleting $dtb when downgrading,
> because it will never be saved in the env.
> 
>  Jocke

This is what I came up with to make $dtb a hush variable that don't
end up in the environment:

#define FLAG_PARSE_SEMICOLON (1 << 1)
#define FLAG_EXIT_FROM_LOOP 1
int misc_init_r (void)
{
	char *bootstr, dtb_str[30], workstr[256];

	u_boot_hush_start();
	sprintf(dtb_str, "dtb=0x%lx", (ulong)dt_blob_start);
	/* Set $dtb in local HUSH env.to my OF tree */
	if (parse_string_outer(dtb_str,
			       FLAG_PARSE_SEMICOLON | FLAG_EXIT_FROM_LOOP) != 0) {
		/* Add " - $dtb" to $bootcmd if it is missing */
		bootstr = getenv("bootcmd");
		if (bootstr && !strstr(bootstr, "- $dtb")) {
			strcpy(workstr, bootstr);
			strcat(workstr, " - $dtb");
			setenv("bootcmd", workstr);
		}
	}
	return 0;
}

It is fairly ugly, but it works. Comments?

BTW, whats syntax is preferred in HUSH for variables:
$var or ${var}?

 Jocke