On Fri, Dec 06, 2013 at 04:26:51PM +0100, Wolfgang Denk wrote:
Dear Dennis Gilmore,
In message 20131206084854.0e0da0cd@adria.ausil.us you wrote:
Wolfgang Denk wd@denx.de escribi=F3:
Dear Dennis Gilmore, =20 In message 1386296295-28658-3-git-send-email-dennis@ausil.us you wrote:
- "fdt_addr=0x11000000\0" \
- "fdt_addr=0x11100000\0" \
- "fdt_addr_r=0x11200000\0" \
Why would you need fdt_addr and fdt_addr_r ? This makes no sense. Two different values would only be needed if there was NOR flash available where we could read the FDT from without loading it to RAM first. AFAIK ther ewill never be variants of the Wandboard with NOR flash, so you will always have to load the FDT to RAM first - thus the destinction makes no sense.
please go and read the cmd_pxe.c file it specifies the use of the two variables. one is for a system provided dtb and the other is for a user provided dtb
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.
Arbitariry redefining this meaning is counterproductive and confusing.
If cmd_pxe.c uses incorrect names, then please fix the bug there.
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.
If we want to set some new rules on these variables we're going to live with for a long while and really document and enforce (see above about fdt_addr/fdt_addr_r/fdtaddr current usage), OK, sure.