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

Wolfgang Denk wrote:

In message 474B14C2.8030708@ge.com you wrote:

...

Passing bd_t via the device tree is evil and should die (it probably is

Agreed.

...

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

Ummm ... what would it be good for?

...

variables than fw_printenv. The problem with this concept currently is that

In which way is that better? One significant drawback is that such access would necessarily be read-only, while with fw_setenv you can modify the environment.

But really, why would an additional copy be better? TO me it seems just a waste of CPU cycles and memory footprint.

...

I would propose we keep the ability to embed the env variables in the blob, positioning ourselves to improving (a) and (b) going forward.

I fail to see any benefit from doing that...

Best regards, Wolfgang Denk

Hi Wolfgang,

I'm just having a hard time letting go of my dream of FDT world domination, starting with using a blob to hold the u-boot env variables. :-)

If we ever /do/ have an option to store env variables in a blob, we won't need to have (the current) extra code to jam the non-FDT env variables into the blob anyway. ;-)

I don't have any problem removing both the bd_t *and* the env embedding "features" since the former is evil and the latter is unused.

Best regards, gvb