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...
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).
This parallels function names like board_init_f() ["_f" standing for "running from [NOR] flash"] and board_init_r() ["_r" = running from system RAM].
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?
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.
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.
Best regards,
Wolfgang Denk