From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dennis Gilmore Date: Fri, 6 Dec 2013 18:09:55 -0600 Subject: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs In-Reply-To: <20131206231616.3E625380BFA@gemini.denx.de> References: <1386296295-28658-1-git-send-email-dennis@ausil.us> <1386296295-28658-3-git-send-email-dennis@ausil.us> <20131206105905.2B359380BFA@gemini.denx.de> <20131206084854.0e0da0cd@adria.ausil.us> <20131206152651.BD940380BFA@gemini.denx.de> <20131206162854.GX420@bill-the-cat> <20131206203759.47710380BFA@gemini.denx.de> <20131206164420.36e5f593@adria.ausil.us> <20131206231616.3E625380BFA@gemini.denx.de> Message-ID: <20131206180955.32ba9f0b@adria.ausil.us> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Wolfgang, El Sat, 07 Dec 2013 00:16:16 +0100 Wolfgang Denk escribi?: > 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... 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 [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