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