From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Mon, 26 Nov 2007 13:47:30 -0500 Subject: [U-Boot-Users] actual stxxtc board maintainer? In-Reply-To: <53D5B784-D81B-454B-B40B-CC4BF255B4C6@kernel.crashing.org> References: <6835AAF4-5F51-4807-AC73-FC357F84628F@kernel.crashing.org> <2FE6F7CC-C9F6-4484-88F4-6C6A23CCDFC9@embeddedalley.com> <53D5B784-D81B-454B-B40B-CC4BF255B4C6@kernel.crashing.org> Message-ID: <474B14C2.8030708@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Kumar Gala wrote: > On Nov 26, 2007, at 12:00 PM, Dan Malek wrote: > >> On Nov 26, 2007, at 8:58 AM, Kumar Gala wrote: >> >>> I see Dan Malek's name listed as the maintainer. I'm wondering who >>> actually cares about this board? >> Well, I do care. :-) I still use them. >> Pantelis did most of the kernel + u-boot FDT work >> with this board. It was one of the first boards >> that used FDT properly. >> >>> ask because this board is one of two that define: >>> CONFIG_OF_HAS_BD_T >>> CONFIG_OF_HAS_UBOOT_ENV >>> >>> However I'm under the believe that these options aren't really used >>> or need by this board (i know they aren't needed for the other). >> I don't know what those mean any more. There were >> a couple of iterations of passing information with >> nicely formatted records before the FDT turned into >> what it is today. They may have been used for that. > > They were mechanisms to pass the full u-boot environment and bd_t as > nodes in the device tree. I'm not aware of any in tree kernel support > that actually uses this information. > > Does the stxxtc use it? > > - k Passing bd_t via the device tree is evil and should die (it probably is already dead, it just doesn't know it yet). Anything in linux that is using bd_t variables through the device tree should be fixed: the values formerly passed through bd_t should already be available in existing properties, or else they should be made available. That is the whole reason for FDT - to replace bd_t. Passing the u-boot env via the device tree seems like a very useful thing to keep. IMHO, this is a better way of accessing the u-boot variables than fw_printenv. The problem with this concept currently is that a) It isn't fully developed/adopted b) The device tree passed to linux doesn't lend itself to writing (a RAM copy is passed, not a pointer to the flash-based original) so we don't have an equivalent to fw_setenv. I would propose we keep the ability to embed the env variables in the blob, positioning ourselves to improving (a) and (b) going forward. Best regards, gvb