Hi Wolfgang, El Sat, 07 Dec 2013 00:16:16 +0100 Wolfgang Denk <w...@denx.de> escribió: > Dear Dennis, > > In message <20131206164420.36e5f...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot