On Fri, Dec 06, 2013 at 09:37:59PM +0100, Wolfgang Denk wrote: > 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.
Right. So the rule is "fdt_addr means the [shipped] DT in NOR, if present. fdt_addr_r means the [shipped] DT in system RAM." > 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. Well, "fdt_addr" still means the shipped DT and "fdt_addr_r" still means a DT loaded into system RAM. The only change is that fdt_addr may also be a system RAM address. > 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" comes from somewhere along the line someone not going "Hey, you forgot a _ in your env" since it means what fdt_addr_r means or fdt_addr means when you lack NOR/similar flash for a DT. > > 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. "system provided" or "shipped" or what have you for the vendor provided DT, which previously would have been in NOR, for fdt_addr when you also have fdt_addr_r. And I believe the answer to the second question is that yes, the shipped or system provided DTB would end up in fdt_addr, so long as whatever "grab the provided default DT" puts it there. > 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. Well, lets see if we can't convince you around. Or get some better names to use for these use cases. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
