[U-Boot-Users] actual stxxtc board maintainer?

[U-Boot-Users] actual stxxtc board maintainer?

[Kumar Gala]

I see Dan Malek's name listed as the maintainer.  I'm wondering who  
actually cares about this board?

I 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).

- k

[U-Boot-Users] actual stxxtc board maintainer?

[Dan Malek]

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.

Thanks.

	-- Dan

[U-Boot-Users] actual stxxtc board maintainer?

[Kumar Gala]

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

[U-Boot-Users] actual stxxtc board maintainer?

[Jerry Van Baren]

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

[U-Boot-Users] actual stxxtc board maintainer?

[Wolfgang Denk]

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 itr be good for?

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

In which way is that better? One significan 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Everything should be made as simple as possible, but not simpler."
                                                    - Albert Einstein

[U-Boot-Users] LIBFDT: bd_t and env embedding (was actual stxxtc board maintainer?)

[Jerry Van Baren]

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

[U-Boot-Users] LIBFDT: bd_t and env embedding (was actual stxxtc board maintainer?)

[Wolfgang Denk]

In message <474C12AF.4000905@ge.com> you wrote:

[Full quote deleted. Link to "How do I quote correctly in Usenet?"
suppressed.]

> 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. :-)

We will feed your dreams.

Please be prepared to review and comment on the new image format
postings I expect to sees really soon now...

> 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.  ;-)

Why would you want to store environment variables in a FDT blob?

In nearly all cases  they  serve  pretty  much  completely  different
purposes, and they can be accessed through different methods.

> 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.

Then we at least agreee on that :-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I find this a nice feature but it is not according to  the  documen-
tation. Or is it a BUG?"   "Let's call it an accidental feature. :-)"
                       - Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>