[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Dennis Gilmore <dennis@ausil.us>]

Hi Wolfgang,

El Sat, 07 Dec 2013 00:16:16 +0100
Wolfgang Denk <wd@denx.de> escribi?:
> Dear Dennis,
> 
> In message <20131206164420.36e5f593@adria.ausil.us> you wrote:
> > 
> > fdtaddr is highly prevalent in the configs
> 
> Yes, it appears some vendors favoured this name.  I'm temptted to add
> that these very vendors often tend to define thier own ways without
> caring what the community has been using before ;-)
> 
> That doesn't make it any better, though...

Not saying that it does, just pointing out the inconsistency in the
tree today. something we likely should fix.

> > those counts are in my git tree with the proposed patches applied
> > that converted soem systems from fdtaddr to fdt_addr. One of the
> > problems right or wrong is that u-boot is seen as not having any
> > kind of standard, which is what I am trying to fix, at least for
> > use in the generic distro world where we need to have an
> > standardised documented interface.
> 
> Even if you feel differntly, I do appreciate your efforts.  But I'd
> also like to see things done in a consistent way.  And the whole idea
> of using the "_r" names was to show clearly which of the addresses are
> supposed to be in system RAM (with "_r"), and which are not (without).

Thankyou I'm trying to be consistent in the interface between u-boot and
the operating system.

> This parallels function names like board_init_f() ["_f" standing for
> "running from [NOR] flash"] and board_init_r() ["_r" = running from
> system RAM].

which makes some sense in the code, but the  config is defining the
interface to kernel/userland and needs to be consistent regardless of
what is underneath 

> > greping through the doc directory of git I am unable to find any
> > reference to this convention you speak of. 
> 
> Agreed. Noone wrote a document about this, yet.
> 
> > The only references i found was in README.falcon README.pxe and
> > README.commands.spl based on your description it would mean falcon
> > mode could not be implemented on any system not having nand.
> 
> I lost you here.  What makes you think so?
Usage:

spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr ]

which to me based on what you said means everything needs to be in nand

> > cmd_pxe.c clearly specifies what it thinks the addresses are for
> 
> Yes, it does.  But this is confused or incorrect, misusing existing
> names for other purposes.  This should be fixed.

I actually think it is spot on and is how it should be.

> > Which i read as fdt_addr is a system provided dtb, and fdt_addr_r
> > is a user provided one. there is no mention of where exactly they
> > come from.
> 
> Stop.  There has never been any such notion like "system provided" or
> "user provided" before.  You cannot just put new meanings over
> existing terms.  Actually, to me such terms don't even make much
> sense.

from u-boot itself there is not this notion. But from a Distro
perspective its always there and is a really big thing. It really is
important. in 99% of cases we want to have u-boot use a provided dtb
without the need to say so and to have it work. 

Dennis

Dennis