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

Dennis Gilmore
2013-12-06T22:44:20Z

Hi Wolfgang,

El Fri, 06 Dec 2013 21:37:59 +0100
Wolfgang Denk <wd@denx.de> escribi?:
> Dear Tom,
>
> In message <20131206162854.GX420@bill-the-cat> you wrote:
> >
> > > But this is crap. The meaning of these variables has been
> > > wel-defined for a long, long time. "fdt_addr" is the FDT address
> > > in NOR flash (or similar memory except system RAM); "fdt_addr_r"
> > > is the FDT address when loaded to system RAM (hence the "_r" in
> > > the variable name).
> >
> > It's a well defined and widely ignored in ARM convention then.
> > We've got lots of 'fdt_addr' meaning RAM and no 'fdt_addr_r' and
> > then in both ARM and PowerPC 'fdtaddr' being presumably RAM.
>
> I think it's actually OK to omit the "_r" in NOR-less systems. The
> number of devices with actual NOT flash is decreasing, and if you can
> be sure that there is no such memory device available, then it is
> just overhead to always carry the "_r" suffice around, knowing all
> the time that there will never be any other option than RAM to store
> that data.
>
> I do not complain if such systems use a simplified setup without the
> "_r".
>
> What I don't like to see is to have "fdt_addr_r" and "fdt_addr" used
> with a new, totally different meaning.
>
>
> I don't know where the spelling "fdtaddr" is coming from; I would
> consider it one of the many "non-standard" variants (assuming we agree
> that there is actually something like a "standard"). Note that there
> is no "fdtaddr_r" anywhere.
fdtaddr is highly prevalent in the configs

grep -r fdtaddr include/configs/|wc -l
390

more so than fdt_addr

grep -r fdt_addr include/configs/|wc -l
278

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.

> > I would say that 'fdt_addr' being the system provided DT, even when
> > not found on memory-mapped flash and 'fdt_addr_r' being the user
> > provided one is a logical extension.
>
> Um... you enter completely new terms here - "system provided" and
> "user provided". I cannot see how a "user provided" DTB in NOR flash
> would fit in such a concept, nor how this would work on systems with
> NOR if a "system provided" DTB gets loaded into RAM from a DHCP
> server.
>
> I understand that you are trying to give the old names a new
> definition that would magically cover the suggested use, but this is
> extremely thin ice. I recommend not to try that.

greping through the doc directory of git I am unable to find any
reference to this convention you speak of.

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.

cmd_pxe.c clearly specifies what it thinks the addresses are for

fdt_addr_r - location in RAM at which 'pxe boot' will store the
fdt blob it retrieves from tftp. The retrieval is possible if
'fdt' label is defined in pxe file and 'fdt_addr_r' is set. If
retrieval is possible, 'fdt_addr_r' will be passed to bootm
command to boot the kernel.

fdt_addr - the location of a fdt blob. 'fdt_addr' will be passed
to bootm command if it is set and 'fdt_addr_r' is not passed to
bootm command.

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.

when pxe booting or installing on an arm system we do not want to put a
fdt line in the config file, because we do not want to have to have
the knowledge in the installer to work out what dtb file we want. that
really is a job for u-boot to provide, but we do have the option to if
its needed for some reason.

I was purely working with what is in front of me.

Dennis