[U-Boot-Users] Proposal for patch to configure network parameters

[U-Boot-Users] Proposal for patch to configure network parameters

[Ulf Samuelsson]

U-Boot has  a number of network parameters like

CONFIG_HOSTNAME
CONFIG_IPADDR
CONFIG_GATEWAYIP
CONFIG_NETMASK
etc.

While these can be defined in an "include/configs/<board>.h",
it would be nice to be able to define this in a separate file
since they are really not board specific.
They are more dependent on the network where the machine is built.

Such a file  I.E: "include/custom.h",  would get included by
the automatically generated "config.h", after the board specific file
is included, to allow it to override any values.

In the normal distribution, this file would be empty so it will not affect
any current boards.

This would allow you to automatically analyse your machine
to find out your host ipaddress, and add an appropriate
ipaddr, netmask, gatewayip etc and overwrite the file with a custom
default network configuration before you build.

There may be other things which you want to set depending
on your host environment.

In short patches would be something similar to:

+++include/custom.h
+ #

+++mkconfig
   echo "#include <configs/$1.h>" >>config.h
+ echo "#include <custom.h>" >>config.h
   exit 0

If the idea seems acceptable, I will go ahead and generate the real patches.

Best Regards
Ulf Samuelsson

[U-Boot-Users] Proposal for patch to configure network parameters

[Timur Tabi]

Ulf Samuelsson wrote:
> U-Boot has  a number of network parameters like
> 
> CONFIG_HOSTNAME
> CONFIG_IPADDR
> CONFIG_GATEWAYIP
> CONFIG_NETMASK
> etc.
> 
> While these can be defined in an "include/configs/<board>.h",
> it would be nice to be able to define this in a separate file
> since they are really not board specific.

I agree that these don't belong in the board config file.  In fact, I don't see why they 
should be board-specific at all.  The U-Boot code in denx.de should have a config.h 
somewhere that specifies these, but we should probably not encourage board maintainers to 
have their own versions.

> This would allow you to automatically analyse your machine
> to find out your host ipaddress, and add an appropriate
> ipaddr, netmask, gatewayip etc and overwrite the file with a custom
> default network configuration before you build.

I don't think it makes sense to claim that the network properties are somehow tied to a 
board.  Are there boards out there that have to have certain IP addresses?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Proposal for patch to configure network parameters

[Wolfgang Denk]

In message <46292528.80907@freescale.com> you wrote:
>
> I don't think it makes sense to claim that the network properties are somehow tied to a 
> board.  Are there boards out there that have to have certain IP addresses?

At least there were some, but I won't tell who it was. As  far  as  I
know, this is just a tiny speck in history.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A Vulcan can  no  sooner  be  disloyal  than  he  can  exist  without
breathing.
	-- Kirk, "The Menagerie", stardate 3012.4

[U-Boot-Users] Proposal for patch to configure network parameters

[Ben Warren]

On Fri, 2007-04-20 at 15:40 -0500, Timur Tabi wrote:
> Ulf Samuelsson wrote:
> > U-Boot has  a number of network parameters like
> > 
> > CONFIG_HOSTNAME
> > CONFIG_IPADDR
> > CONFIG_GATEWAYIP
> > CONFIG_NETMASK
> > etc.
> > 
> > While these can be defined in an "include/configs/<board>.h",
> > it would be nice to be able to define this in a separate file
> > since they are really not board specific.
> 
> I agree that these don't belong in the board config file.  In fact, I don't see why they 
> should be board-specific at all.  The U-Boot code in denx.de should have a config.h 
> somewhere that specifies these, but we should probably not encourage board maintainers to 
> have their own versions.
> 
If these network parameters really need default values, it's probably
better to initialize environment variables using
CONFIG_EXTRA_ENV_SETTINGS, or something like that.  I expect that almost
every board that U-boot gets loaded on will have these values
overwritten anyway to fit in whatever network it ends up in.

regards,
Ben

[U-Boot-Users] Proposal for patch to configurenetwork parameters

[Ulf Samuelsson]

> On Fri, 2007-04-20 at 15:40 -0500, Timur Tabi wrote:
>> Ulf Samuelsson wrote:
>> > U-Boot has  a number of network parameters like
>> >
>> > CONFIG_HOSTNAME
>> > CONFIG_IPADDR
>> > CONFIG_GATEWAYIP
>> > CONFIG_NETMASK
>> > etc.
>> >
>> > While these can be defined in an "include/configs/<board>.h",
>> > it would be nice to be able to define this in a separate file
>> > since they are really not board specific.
>>
>> I agree that these don't belong in the board config file.  In fact, I 
>> don't see why they
>> should be board-specific at all.  The U-Boot code in denx.de should have 
>> a config.h
>> somewhere that specifies these, but we should probably not encourage 
>> board maintainers to
>> have their own versions.
>>
> If these network parameters really need default values, it's probably
> better to initialize environment variables using
> CONFIG_EXTRA_ENV_SETTINGS, or something like that.  I expect that almost
> every board that U-boot gets loaded on will have these values
> overwritten anyway to fit in whatever network it ends up in.
>

I think everyone so far is missing the point.
My proposal is just to allow the u-boot developer to customize his/her build
with environment variables generated outside the u-boot source tree.

It does not specify what the user is doing with this new flexibility.

Doing it this way is the "clean" way in my opinion,
but If Wolfgang is going to complain, then I just
have to do it anyway, but outside U-boot.

It is very easy to just copy an "include/config/<board>.h" file
from outside u.-boot to "include/configs", adding the extra stuff
I need at the end of that file.

Even if WD does not like fixed IP configuration there are other use for this

If you have a board with multiple memories, and you can store
you environment in all of them, then you can use this function to
define where the environment is instead of having multiple board files.
It is really a pin to maintain multiple board files for this purpose alone.


> regards,
> Ben
>
>


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR

[U-Boot-Users] Proposal for patch to configurenetwork parameters

[Wolfgang Denk]

In message <028f01c78396$318ebe80$01c4af0a@Glamdring> you wrote:
>
> I think everyone so far is missing the point.

Maybe.

> My proposal is just to allow the u-boot developer to customize his/her build
> with environment variables generated outside the u-boot source tree.

Understood.

My position is that it is a bad thing to built any  information  from
outside the U-Boot source tree into the U-Boot image.

If you need different images, you  are  doing  something  wrong.  The
varying  information  should  be  handled outside the (then constant)
U-Boot image.

> If you have a board with multiple memories, and you can store
> you environment in all of them, then you can use this function to
> define where the environment is instead of having multiple board files.
> It is really a pin to maintain multiple board files for this purpose alone.

Now this is a completely new topic. So far  you  were  talking  about
network parameter settings, now it's multiple memories.

Can we please keep these things separated?

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Whoever undertakes to set himself up as a judge of Truth  and  Know-
ledge is shipwrecked by the laughter of the gods."  - Albert Einstein

[U-Boot-Users] Proposal for patch to configurenetwork parameters

[Ulf Samuelsson]

>> I think everyone so far is missing the point.
>
> Maybe.
>
>> My proposal is just to allow the u-boot developer to customize his/her 
>> build
>> with environment variables generated outside the u-boot source tree.
>
> Understood.
>
> My position is that it is a bad thing to built any  information  from
> outside the U-Boot source tree into the U-Boot image.
>
> If you need different images, you  are  doing  something  wrong.  The
> varying  information  should  be  handled outside the (then constant)
> U-Boot image.

No, I think you need to understand my situation.
I want to develop a building system which I can ship to multiple persons
Each person will need a customized set of environment variables.
    Once they have done this configuration (using make menuconfig outside 
U-Boot)
    the u-boot compile time configuration will not change - ever.
No person is likely to have the same set of configuration.
This configuration is only used at initial production to get access to the 
tftp server


>
>> If you have a board with multiple memories, and you can store
>> you environment in all of them, then you can use this function to
>> define where the environment is instead of having multiple board files.
>> It is really a pin to maintain multiple board files for this purpose 
>> alone.
>
> Now this is a completely new topic. So far  you  were  talking  about
> network parameter settings, now it's multiple memories.
>
> Can we please keep these things separated?

They are not separated, both networking and environment are but examples
on how you can use the patch.
None of them are part of the patch.


>
> Thanks.
>
> Best regards,
>


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR
link: www.avrfreaks.net 

[U-Boot-Users] Proposal for patch to configurenetwork parameters

[Wolfgang Denk]

In message <02d201c783a5$a2a65240$01c4af0a@Glamdring> you wrote:
>
> No, I think you need to understand my situation.

I think I do. Been there, done that before.

> This configuration is only used at initial production to get access to the 
> tftp server

There are easier ways to get there.

> They are not separated, both networking and environment are but examples
> on how you can use the patch.
> None of them are part of the patch.

In fact you can use this to modify U-Boot in arbitray  ways,  without
allowing  a user who looks at the source code to see what's going on.
If this is your intention, than the patch is evil, as  it  inherently
opens doors and gates for GPL violations.

I say no.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Brontosaurus Principle: Organizations  can  grow  faster  than  their
brains  can manage them in relation to their environment and to their
own physiology: when this occurs, they are an endangered species.
                                                - Thomas K. Connellan

[U-Boot-Users] Proposal for patch to configurenetwork parameters

[Ulf Samuelsson]

>
>> This configuration is only used at initial production to get access to 
>> the
>> tftp server
>
> There are easier ways to get there.
>
>> They are not separated, both networking and environment are but examples
>> on how you can use the patch.
>> None of them are part of the patch.
>
> In fact you can use this to modify U-Boot in arbitray  ways,  without
> allowing  a user who looks at the source code to see what's going on.
> If this is your intention, than the patch is evil, as  it  inherently
> opens doors and gates for GPL violations.
>
> I say no.
>


If that is your opinion, I will just apply the patch to my own u-boot 
then...



Best Regards
Ulf Samuelsson

[U-Boot-Users] Proposal for patch to configurenetwork parameters

[Ulf Samuelsson]

>> No, I think you need to understand my situation.
>
> I think I do. Been there, done that before.
>
>> This configuration is only used at initial production to get access to 
>> the
>> tftp server
>
> There are easier ways to get there.
>
>> They are not separated, both networking and environment are but examples
>> on how you can use the patch.
>> None of them are part of the patch.
>
> In fact you can use this to modify U-Boot in arbitray  ways,

No I can use it for *configuring* it in a different way than available
with the current board configs.
By the rules of the game, any such additions becomes GPL.

I guess this means that you would be against configuring U-boot with Eclipse 
as well...


> without
> allowing  a user who looks at the source code to see what's going on.
> If this is your intention, than the patch is evil, as  it  inherently
> opens doors and gates for GPL violations.
>
> I say no.
>

There is already a wide open door for GPL violations called "editing the 
source"
so this does not change anything.
Just makes life difficult for people with honest intentions.

Best Regards
Ulf Samuelsson 

[U-Boot-Users] Proposal for patch to configurenetwork parameters

[Timur Tabi]

Ulf Samuelsson wrote:

> No, I think you need to understand my situation.
> I want to develop a building system which I can ship to multiple persons
> Each person will need a customized set of environment variables.

Is there a way to build an flash-able image that contains all the 
environment variables?  You could then take this image, write it to 
flash, and the next time U-Boot boots, it will have the new environment 
variables.

(Frankly, though, I'm also having a hard time understanding what Ulf is 
saying).

[U-Boot-Users] Proposal for patch to configurenetwork parameters

[Wolfgang Denk]

In message <462BBDF2.5080608@freescale.com> you wrote:
>
> > No, I think you need to understand my situation.
> > I want to develop a building system which I can ship to multiple persons
> > Each person will need a customized set of environment variables.
> 
> Is there a way to build an flash-able image that contains all the 
> environment variables?  You could then take this image, write it to 
> flash, and the next time U-Boot boots, it will have the new environment 
> variables.

Yes, ther eis. There are actually many possible  solutions.

Example 1: You can put all settings you want in a  script,  create  a
script  image  from  it,  and place this in the flash sector directly
following the U-Boot image (which means you can just cat  the  images
and write them to flash in a single programming operation). Have your
default  bootcmd run this script using the autoscr command. Note that
the script can then also define a new bootcmd setting.

Example 2: You can put your U-Boot environment in the flash sector(s)
directly following the U-Boot image ...

Etc.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Heavier than air flying machines are impossible.
                    -- Lord Kelvin, President, Royal Society, c. 1895

[U-Boot-Users] Proposal for patch to configurenetwork parameters

[Timur Tabi]

Wolfgang Denk wrote:

> Yes, ther eis. There are actually many possible  solutions.
> 
> Example 1: You can put all settings you want in a  script,  create  a
> script  image  from  it,  

How do I create a script image?  I couldn't find instructions in the README.

> and place this in the flash sector directly
> following the U-Boot image (which means you can just cat  the  images
> and write them to flash in a single programming operation).

cat the images together?  Doesn't that assume that u-boot.bin is 
sector-aligned?

> Have your
> default  bootcmd run this script using the autoscr command. Note that
> the script can then also define a new bootcmd setting.
> 
> Example 2: You can put your U-Boot environment in the flash sector(s)
> directly following the U-Boot image ...

Wait, isn't this the same as example 1?

[U-Boot-Users] Proposal for patch to configurenetwork parameters

[Ulf Samuelsson]

> Ulf Samuelsson wrote:
>
>> No, I think you need to understand my situation.
>> I want to develop a building system which I can ship to multiple persons
>> Each person will need a customized set of environment variables.
>
> Is there a way to build an flash-able image that contains all the 
> environment variables?  You could then take this image, write it to flash, 
> and the next time U-Boot boots, it will have the new environment 
> variables.
>
> (Frankly, though, I'm also having a hard time understanding what Ulf is 
> saying).
>

Yes, I have a command "defenv" which will reinitialize a board to "factory 
default" environment..

One of the environment variables "config" is a command which will download a 
board specific configuration script
"autoscript.<board>" from the server and run it using "autoscr".
.
The board specific configuration can contain the real ethernet MAC address 
and other stuff, but the default
environment .must set a prelmininary ethernet address to allow the server 
communication to be set up.


Best Regards
Ulf Samuelsson

[U-Boot-Users] Proposal for patch to configure network parameters

[Ulf Samuelsson]

> Ulf Samuelsson wrote:
>> U-Boot has  a number of network parameters like
>>
>> CONFIG_HOSTNAME
>> CONFIG_IPADDR
>> CONFIG_GATEWAYIP
>> CONFIG_NETMASK
>> etc.
>>
>> While these can be defined in an "include/configs/<board>.h",
>> it would be nice to be able to define this in a separate file
>> since they are really not board specific.
>
> I agree that these don't belong in the board config file.  In fact, I 
> don't see why they should be board-specific at all.  The U-Boot code in 
> denx.de should have a config.h somewhere that specifies these, but we 
> should probably not encourage board maintainers to have their own 
> versions.
>
>> This would allow you to automatically analyse your machine
>> to find out your host ipaddress, and add an appropriate
>> ipaddr, netmask, gatewayip etc and overwrite the file with a custom
>> default network configuration before you build.
>
> I don't think it makes sense to claim that the network properties are 
> somehow tied to a board.  Are there boards out there that have to have 
> certain IP addresses?
>

If you setup serverip to point at your PC for board test&manufacture then 
you can do:

setenv bootcmd     tftp 21000000 autoscript.myboard     ;     autoscr 
21000000

in your default (compile time) configuration.

Connect Ethernet
Power Up
autoscript is downloaded and executed
LED starts to blink when ready.
Power Down
Next board...

The autoscript.myboard is regenerated for every new board so they get a new 
"ethaddr"
and other custom features..

I really do not see the harm in this.


> -- 
> Timur Tabi
> Linux Kernel Developer @ Freescale
>


Best Regards
Ulf Samuelsson

[U-Boot-Users] Proposal for patch to configure network parameters

[Wolfgang Denk]

In message <02b301c78397$9909dfd0$01c4af0a@Glamdring> you wrote:
>
> > I don't think it makes sense to claim that the network properties are 
> > somehow tied to a board.  Are there boards out there that have to have 
> > certain IP addresses?
> 
> If you setup serverip to point at your PC for board test&manufacture then 
> you can do:
> 
> setenv bootcmd     tftp 21000000 autoscript.myboard     ;     autoscr 
> 21000000
> 
> in your default (compile time) configuration.
> 
> Connect Ethernet
> Power Up
> autoscript is downloaded and executed
> LED starts to blink when ready.
> Power Down
> Next board...
> 
> The autoscript.myboard is regenerated for every new board so they get a new 
> "ethaddr"
> and other custom features..
> 
> I really do not see the harm in this.

But to do this, no changes to the U-Boot code are  needed.  Just  set
your  default network configuration in the board config file, and you
are all set.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Pain is a thing of the mind.  The mind can be controlled.
	-- Spock, "Operation -- Annihilate!" stardate 3287.2

[U-Boot-Users] Proposal for patch to configure networkparameters

[Ulf Samuelsson]

>> The autoscript.myboard is regenerated for every new board so they get a 
>> new
>> "ethaddr"
>> and other custom features..
>>
>> I really do not see the harm in this.
>
> But to do this, no changes to the U-Boot code are  needed.  Just  set
> your  default network configuration in the board config file, and you
> are all set.

The whole purpose of the patch is to allow me to change the default
network configuration *WITHOUT* updating the board file.

Everything is going to be handled by scripts getting their input from 
graphic entry.

Scripts are very good at *generating* files.
They are exceptionally bad in patching files which can change over time.


>
> Best regards,
>
> Wolfgang Denk
>


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR
link: www.avrfreaks.net 

[U-Boot-Users] Proposal for patch to configure network parameters

[Wolfgang Denk]

In message <024c01c78381$d7866f00$01c4af0a@Glamdring> you wrote:
> U-Boot has  a number of network parameters like
> 
> CONFIG_HOSTNAME
> CONFIG_IPADDR
> CONFIG_GATEWAYIP
> CONFIG_NETMASK
> etc.
> 
> While these can be defined in an "include/configs/<board>.h",
> it would be nice to be able to define this in a separate file
> since they are really not board specific.

Actually these parameters  (and  more,  like  MAC  addresses)  should
*never* be set at all in the U-Boot configuration. They exist for (1)
hysterical  reasons  I'm  not  going to explain, and (2) because some
(paying!) customer insisted on having such a feature.

Normally, you should use other methods to customize your system - the
U-Boot binary image for a board should always be independent of  such
settings.

> Such a file  I.E: "include/custom.h",  would get included by
> the automatically generated "config.h", after the board specific file
> is included, to allow it to override any values.
> 
> In the normal distribution, this file would be empty so it will not affect
> any current boards.

I think I'm going to resist such a change. By making it easier to use
this stuff, more people will use it, i. e. evil will spread.

> This would allow you to automatically analyse your machine
> to find out your host ipaddress, and add an appropriate
> ipaddr, netmask, gatewayip etc and overwrite the file with a custom
> default network configuration before you build.

There are other, better ways to implement what you want  to  do.  For
example,  you  can  put  such  information  in a separate location in
flashand make U-Boot to auto-initialize  these  variable  from  these
default  settings  in case the environment does not contain any other
settings yet, etc.

> If the idea seems acceptable, I will go ahead and generate the real patches.

Please don't.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I dislike companies that have a we-are-the-high-priests-of-hardware-
so-you'll-like-what-we-give-you attitude. I like commodity markets in
which iron-and-silicon hawkers know that they exist to  provide  fast
toys for software types like me to play with..."    - Eric S. Raymond

[U-Boot-Users] Proposal for patch to configure networkparameters

[Ulf Samuelsson]

> In message <024c01c78381$d7866f00$01c4af0a@Glamdring> you wrote:
>> U-Boot has  a number of network parameters like
>>
>> CONFIG_HOSTNAME
>> CONFIG_IPADDR
>> CONFIG_GATEWAYIP
>> CONFIG_NETMASK
>> etc.
>>
>> While these can be defined in an "include/configs/<board>.h",
>> it would be nice to be able to define this in a separate file
>> since they are really not board specific.
>
> Actually these parameters  (and  more,  like  MAC  addresses)  should
> *never* be set at all in the U-Boot configuration. They exist for (1)
> hysterical  reasons  I'm  not  going to explain, and (2) because some
> (paying!) customer insisted on having such a feature.
>

Why should you care if the customer sets a configuration value at compile
time or dynamically?
By setting things at compile time, you allow the board to boot up,
download a script which gets executed by "autoscr"
This script will sets the REAL values for the network.
Obviously the values should only be used until manually changed.

I.E: if you do

setenv ipaddr 10.10.10.10

then this should override the  CONFIG_IPADDR value.

Not sure, if this is your problem.

> Normally, you should use other methods to customize your system - the
> U-Boot binary image for a board should always be independent of  such
> settings.
>

Assume you have no serial communication available...
How do you reconfigure the system?

Can you explain how to download the environment using the network
if you are not allowed to compile in the network parameters?


>
> There are other, better ways to implement what you want  to  do.  For
> example,  you  can  put  such  information  in a separate location in
> flashand make U-Boot to auto-initialize  these  variable  from  these
> default  settings  in case the environment does not contain any other
> settings yet, etc.
>

I think that U-Boot needs to test the environment to see if it is valid
or not, and only use these values if environment is invalid.
I do not think that I need to have it in a separate area.
Incidently, if the initial value is in a separate segment, then
you can overwrite this later with other values.


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR
link: www.avrfreaks.net 

[U-Boot-Users] Proposal for patch to configure networkparameters

[Wolfgang Denk]

In message <027c01c78394$16500590$01c4af0a@Glamdring> you wrote:
>
> Why should you care if the customer sets a configuration value at compile
> time or dynamically?

I don't care about this.

> By setting things at compile time, you allow the board to boot up,
> download a script which gets executed by "autoscr"
> This script will sets the REAL values for the network.
> Obviously the values should only be used until manually changed.

OK, in such a configuration you can  add  the  values  to  the  board
config file, as there is no need to change them frequently, right?

> Not sure, if this is your problem.

No.

> Assume you have no serial communication available...
> How do you reconfigure the system?

We are not talking about reconfiguration, but about how to initialize
the default environment. These are two different things.

> Can you explain how to download the environment using the network
> if you are not allowed to compile in the network parameters?

You don't have to download such parameters. 

Please  feel  free  to  set  these  values  somewhere  during   board
production,  but  you  better  not embed them into the default U-Boot
image. There are several methods to initialize such parameters  which
are much cleaner. For example, some boards use some hardware ID block
which  gets  written separately from the U-Boot image, which then can
contain board specific parameters like serial  number,  MAC  address,
and - if you like - additional default netowrk configuration.



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Der Dativ ist dem Genitiv sein Tod.

[U-Boot-Users] Proposal for patch to configure networkparameters

[Ulf Samuelsson]

link: www.avrfreaks.net
----- Original Message ----- 
From: "Wolfgang Denk" <wd@denx.de>
To: "Ulf Samuelsson" <ulf@atmel.com>
Cc: <u-boot-users@lists.sourceforge.net>
Sent: Saturday, April 21, 2007 12:59 AM
Subject: Re: [U-Boot-Users] Proposal for patch to configure 
networkparameters


> In message <027c01c78394$16500590$01c4af0a@Glamdring> you wrote:
>>
>> Why should you care if the customer sets a configuration value at compile
>> time or dynamically?
>
> I don't care about this.
>
>> By setting things at compile time, you allow the board to boot up,
>> download a script which gets executed by "autoscr"
>> This script will sets the REAL values for the network.
>> Obviously the values should only be used until manually changed.
>
> OK, in such a configuration you can  add  the  values  to  the  board
> config file, as there is no need to change them frequently, right?
>
>> Not sure, if this is your problem.
>
> No.
>
>> Assume you have no serial communication available...
>> How do you reconfigure the system?
>
> We are not talking about reconfiguration, but about how to initialize
> the default environment. These are two different things.
>
>> Can you explain how to download the environment using the network
>> if you are not allowed to compile in the network parameters?
>
> You don't have to download such parameters.
>
> Please  feel  free  to  set  these  values  somewhere  during   board
> production,  but  you  better  not embed them into the default U-Boot
> image. There are several methods to initialize such parameters  which
> are much cleaner. For example, some boards use some hardware ID block
> which  gets  written separately from the U-Boot image, which then can
> contain board specific parameters like serial  number,  MAC  address,
> and - if you like - additional default netowrk configuration.


Why do you need to separate something which NEVER is going to be written 
again?
There is a cost involved with doing multiple programming steps and those 
should be minimized.

Even if you have multiple servers you can still allocate a duplicated IP 
address
to a network port on each server which is a point to point connection to the
board to be produced.

If there is a need to change these values, a simple recompile will fix that.

And still: The proposed patch will not do anything with network parameters
It will allow people to generate whatever config variables outside U-boot.

How they use this, you will not be aware of so I really do not understand
why you are against the patch.

The only thing the patch does is to add
#include <custom.h>
in the config.h

and then an empty custom.h is created
to make sure that it does not crash compiles of existing boards.
.
The patch has really nothing to do with networking,
so I suggest we stop discussing networking configuration
and start discussing the patch.

Are you against giving developers freedom?


Best Regards
Ulf Samuelsson

[U-Boot-Users] Proposal for patch to configure networkparameters

[Wolfgang Denk]

In message <02cc01c783a4$3a489920$01c4af0a@Glamdring> you wrote:
>
> Why do you need to separate something which NEVER is going to be written 
> again?

I don't.

> There is a cost involved with doing multiple programming steps and those 
> should be minimized.

I never said anything about multiple programming steps.  Please  feel
free  to  attach your hardware information block (or whatever you are
going to call it) at the end of the U-Boot image (using "cat" or "dd"
or similar) or insert it into some known to be unused area or ...

> And still: The proposed patch will not do anything with network parameters
> It will allow people to generate whatever config variables outside U-boot.

Right. And this is something I consider a bad thing.  The  configura-
tion  of U-Boot shall be done in U-Boot, and visible to everybody who
sees the U-Boot source code.

Last but not least, this is also a GPL issue.

> How they use this, you will not be aware of so I really do not understand
> why you are against the patch.

Just because of this: because I am not aware what people insert  into
GPLed code.

> The patch has really nothing to do with networking,

But that was your introduction for it, wasn't it?

> Are you against giving developers freedom?

Are you against making your changes available under GPL?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The first 90% of a project takes 90% of the time, the last 10%  takes
the other 90% of the time.

[U-Boot-Users] Proposal for patch to configure networkparameters

[Ulf Samuelsson]

>> Why do you need to separate something which NEVER is going to be written
>> again?
>
> I don't.
>
>> There is a cost involved with doing multiple programming steps and those
>> should be minimized.
>
> I never said anything about multiple programming steps.  Please  feel
> free  to  attach your hardware information block (or whatever you are
> going to call it) at the end of the U-Boot image (using "cat" or "dd"
> or similar) or insert it into some known to be unused area or ...
>

What is automatically generated is is 100% *outside* the patch
and we should stop that part of the discussion.

>> And still: The proposed patch will not do anything with network 
>> parameters
>> It will allow people to generate whatever config variables outside 
>> U-boot.
>
> Right. And this is something I consider a bad thing.  The  configura-
> tion  of U-Boot shall be done in U-Boot, and visible to everybody who
> sees the U-Boot source code.
>

Forcing people to do thing *your* way is against the GPL spirit.

Lets face it, everyone knows that the current way of configuring u-boot is 
horrible.
I am not at all interested  having novice users start doing this and then
calling me in frustration.

> Last but not least, this is also a GPL issue.
>
>> How they use this, you will not be aware of so I really do not understand
>> why you are against the patch.
>
> Just because of this: because I am not aware what people insert  into
> GPLed code.
>

GPL does not mean that *you* need to be aware and approve each and every 
change.
It means that if someone is interested in finding out how things
are done, they should have access to source.

>> The patch has really nothing to do with networking,
>
> But that was your introduction for it, wasn't it?

Yes, but there are a number of different uses for the patch.

>
>> Are you against giving developers freedom?
>
> Are you against making your changes available under GPL?

No, I am generating the added stuff from "buildroot" (buildroot.uclibc.org)
"buildroot" *is* GPL.

The whole purpose of my work is that I want to ship GPL source

I do not build any equipment. I do not ship any hardware.

I just try to make the embedded Linux design flow more accessible
to anyone that is interested. U-Boot is only a small part of that.

You can check out what I am doing on www.at91.com : project = AT91 buildroot

There I am collecting all the different things neeeded to get a board 
running for the novice.

Basically you should download this to a directory and then type

make B=at91rm9200df board
make

and then have everything ready a couple of hours later in
the "binaries/at91rm9200df" in buildroot.

By everything I mean:

Initial bootstrap (dataflashboot,flashboot,nandflashboot)
U-boot
script for u-boot autoscr
linux kernel
jffs2 file system
ext2 file system

The U-boot shall not have to be configured by the user using *manual* u-boot 
commands.

Instead the user will configure everything in buildroot using the "make 
menuconfig" interface
and the script should download and configure the board, flashing the kernel 
and ramdisk
and set the bootcmd.

It should allow for regenerating the script with a unique ethaddr.

Really nothing sinister about this.

############################################
Your argument that you want stuff to be GPL and this will help you is not 
valid.

I hope You agree that you cannot control what people put in their 
include/configs/<board>.h files.
Thus you have no more protection against people not releasing their code 
with
the patch as you have without the patch.

The effect of not approving the patch, is that you make life more difficult
for people which are in 100% compliant with GPL rules in order
to avoid making it easier for people that want to be non-compliant.


Since I am copying the u-boot config file from the buildroot source anyway I 
can always
append the stuff on the fly.

This is not a good approach since it become more difficult to do a good 
"make distclean".
A clean "make distclean" would in this case consist of:

    echo    "#"    > include/custom.h

Without the patch I will be forced to add some kind of header to my 
additions
and let make distclean scan all the <board>.h files for this header and 
remove
everything after that header.
Not a nice approach...


>
> Best regards,
>
> Wolfgang Denk
>


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR
link: www.avrfreaks.net 

[U-Boot-Users] Proposal for patch to configure networkparameters

[Robert Schwebel]

On Sat, Apr 21, 2007 at 08:05:19AM +0200, Ulf Samuelsson wrote:
> Lets face it, everyone knows that the current way of configuring
> u-boot is horrible.

yup

> GPL does not mean that *you* need to be aware and approve each and
> every change.

Well, he is the maintainer. Like it or not, he *is*. Live with it or
fork and show that you can do it better.

> I just try to make the embedded Linux design flow more accessible to
> anyone that is interested. U-Boot is only a small part of that.

I don't understand why you need changes in u-boot in order to achieve
this. We use the same scenario for quite some time in PTXdist; ptxdist
has a view of "per project" vs. "per user" vs. "per board" properties,
so if you for example what to change something for the root filesystem,
you use

	ptxdist menuconfig

To change user specific options, e.g. proxy, use

	ptxdist setup

and, what you need here, is

	ptxdist boardsetup

which brings up a Kconfig dialog which lets you chose things like IP
address, netmask, nfsroot path, currently connected serial port etc. So
if you setup a board, simply do the changes in the user dialogs and run

	ptxdist test setenv

This starts an expect script [1] which automatically connects to your
u-boot console, cleans up whatever environment it finds there and
re-programs from a well defined project environment, consisting of
"project" dependend parts plus the information you entered in the step
above. The user doesn't have to cope with complex quoting rules , 0x vs
non-0x and all the inconveniences the u-boot interface has.

All that without any change to u-boot code.

> I hope You agree that you cannot control what people put in their 
> include/configs/<board>.h files.

Well, this is open source. I cannot imagine that Wolfgang will control
whatever you might want to do. You are perfectly free to do what you
want. That doesn't change the fact that he is the maintainer and he
decides what comes into his tree.

Robert 

[1] Yes, expect is tcl and uggly as hell. But there is nothing better
    available out there, at least not without major founding, and it
    somehow works.
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

[U-Boot-Users] Proposal for patch to configure networkparameters

[Ulf Samuelsson]

> On Sat, Apr 21, 2007 at 08:05:19AM +0200, Ulf Samuelsson wrote:
>> Lets face it, everyone knows that the current way of configuring
>> u-boot is horrible.
>
> yup
>
>> GPL does not mean that *you* need to be aware and approve each and
>> every change.
>
> Well, he is the maintainer. Like it or not, he *is*. Live with it or
> fork and show that you can do it better.

Just seems easier for a camel to pass the famous hole in the needle
than to get a patch in to u-boot.
Have been trying to split a file into two parts for 3-4 months
and that has caused endless emails to and from.

Just enjoy working with people that takes an objective view.

>
> To change user specific options, e.g. proxy, use
>
> ptxdist setup
>
> and, what you need here, is
>
> ptxdist boardsetup
>

I have looked at ptxdist and felt it was a little too much in a flux for my 
taste.
It seems more advanced than buildroot that I am basing myself on.
If I was working on this as a full time job, I would probably use ptxdist
instead of buildroot.

> which brings up a Kconfig dialog which lets you chose things like IP
> address, netmask, nfsroot path, currently connected serial port etc. So
> if you setup a board, simply do the changes in the user dialogs and run
>
> ptxdist test setenv
>

I want the configuration to be done without serial port communication
Connect to Ethernet, wait for LED to blink, next board....

According to Wolfgang, this promotes other people's evil doings
and you must select a non-efficient solution if you want to use main tree 
u-boot.

Best Regards
Ulf Samuelsson

[U-Boot-Users] Proposal for patch to configure networkparameters

[Robert Schwebel]

On Sun, Apr 22, 2007 at 07:30:00AM +0200, Ulf Samuelsson wrote:
> Just seems easier for a camel to pass the famous hole in the needle
> than to get a patch in to u-boot.  Have been trying to split a file
> into two parts for 3-4 months and that has caused endless emails to
> and from.

while listen_to_arguments; do
	change patch until everybody is happy
done

> Just enjoy working with people that takes an objective view.

Objective views are an illusion of management :-) Technology is
different. And OSS gives you all the possibilities, including the chance
to review your own argumentation :-)

> I have looked at ptxdist and felt it was a little too much in a flux
> for my taste. It seems more advanced than buildroot that I am basing
> myself on. If I was working on this as a full time job, I would
> probably use ptxdist instead of buildroot.

Well, PTXdist has stable releases since 2002, and yes, it is developing
at a high pace. That's how open source projects evolve. One can whine
about things which are not there or one can ask for features or one can
contribute patches or buy support. That's no different with ptxdist,
u-boot or any other project out there. By the way, 0.10.6 is a very
stable version. But that's probably something to discuss on another
mailing list.

> I want the configuration to be done without serial port communication
> Connect to Ethernet, wait for LED to blink, next board....
> 
> According to Wolfgang, this promotes other people's evil doings and
> you must select a non-efficient solution if you want to use main tree
> u-boot.

Well, we have done similar things in the past. You will always have
things in your patch stacks which are not for upstream, due to several
reasons (no time to do things right, crappy intermediate projects who
don't provide clean patches, quick hacks, features which are not
implementable in a modular way etc.). That's why PTXdist projects make
it possible to add arbitrary patch stacks to any packst. You can start
with a vanilla version, add your 17 ready-for-upstream patches plus your
very-personal-one-which-is-not-ready to the queue and 'ptxdist go'. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

[U-Boot-Users] Proposal for patch to configure networkparameters

[Ulf Samuelsson]

> On Sun, Apr 22, 2007 at 07:30:00AM +0200, Ulf Samuelsson wrote:
>> Just seems easier for a camel to pass the famous hole in the needle
>> than to get a patch in to u-boot.  Have been trying to split a file
>> into two parts for 3-4 months and that has caused endless emails to
>> and from.
>
> while listen_to_arguments; do
> change patch until everybody is happy
> done
>

In this case, my goal is to create a useable way of configuration
for limited parts of U-boot outside U-boot.

Wolfgang just stated that he will not accept any patch making that 
possible,.
The only allowed way to configure is within u-boot.

It is very difficult if the very principle of the patch is unacceptable.

Wolfgang has said (1 year ago or so) that he wants all configuration
in one place, so Kconfig is out unless you have a single Kconfig file
covering all cpus/board/versions etc.
I disagree with that principle, so I believe that I am the wrong person
to suggest or implement any configuration for U-boot, because
I cant imagine any such patch that Wolfgang will accept.

We just dont think alike.

>
> Well, we have done similar things in the past. You will always have
> things in your patch stacks which are not for upstream, due to several
> reasons (no time to do things right, crappy intermediate projects who
> don't provide clean patches, quick hacks, features which are not
> implementable in a modular way etc.).

> That's why PTXdist projects make
> it possible to add arbitrary patch stacks to any packst.
> You can start with a vanilla version, add your 17 ready-for-upstream 
> patches plus your
> very-personal-one-which-is-not-ready to the queue and 'ptxdist go'.

Which is good and completely different to Wolfgangs approach
to make it as difficult as possible to maintain out of tree patches
in the hope that no nonGPL versions of u-boot will appear.

Personally I see this as insisting to have the drivers door of a car  locked
at all times to avoid theft while not caring about the other doors,
allowing easy access for thieves, but forcing the driver to enter any
door except his own.

> Robert
> -- 


Best Regards
Ulf Samuelsson

[U-Boot-Users] Proposal for patch to configure networkparameters

[Wolfgang Denk]

In message <001901c784ba$97f07450$01c4af0a@Glamdring> you wrote:
>
> > while listen_to_arguments; do
> > change patch until everybody is happy
> > done
> 
> In this case, my goal is to create a useable way of configuration
> for limited parts of U-boot outside U-boot.

This is reasonable.

> Wolfgang just stated that he will not accept any patch making that 
> possible,.
> The only allowed way to configure is within u-boot.

This is not so different from Linux, btw. The only way to configure a
Linux kernel is by doing this inside the Linux source tree.

> It is very difficult if the very principle of the patch is unacceptable.

There is usually more than one way to do things.

> Wolfgang has said (1 year ago or so) that he wants all configuration
> in one place, so Kconfig is out unless you have a single Kconfig file
> covering all cpus/board/versions etc.

I admit that I don't like Kconfig. But then, I'm  also  unhappy  with
what  we have now. Ideas for a beter solution are welcome, but please
let's discuss concepts before submitting patches.

> We just dont think alike.

This is perfectly normal. We can still try to work with each other.

> Which is good and completely different to Wolfgangs approach
> to make it as difficult as possible to maintain out of tree patches
> in the hope that no nonGPL versions of u-boot will appear.

I don't see how I could do anything against out of tree patches  even
if I wanted, nor am I aware that I ever tried.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Lots of folks confuse bad management with destiny.   -- Frank Hubbard

[U-Boot-Users] Proposal for patch to configure networkparameters

[Ulf Samuelsson]

> In message <001901c784ba$97f07450$01c4af0a@Glamdring> you wrote:
>>
>> > while listen_to_arguments; do
>> > change patch until everybody is happy
>> > done
>>
>> In this case, my goal is to create a useable way of configuration
>> for limited parts of U-boot outside U-boot.
>
> This is reasonable.
>
>> Wolfgang just stated that he will not accept any patch making that
>> possible,.
>> The only allowed way to configure is within u-boot.
>
> This is not so different from Linux, btw. The only way to configure a
> Linux kernel is by doing this inside the Linux source tree.

No, the way buildroot works is that you decompress a linux kernel and patch 
it.
Then you can copy  $(LINUX26_KCONFIG) (defined by buildroot make 
menucconfig)
to the $(LINUX26_DIR)/.config.

$(LINUX26_KCONFIG) is of course generated by doing make xconfig inside the 
linux kernel
and then copying it to the buildroot directory.

This method meet my need to easily be able to select a working configuration 
for Linux.

I am doing the same for u-boot. A file is copied to 
include/configs/<board>.h
but there are somethings which always needs to change for a new user,
and these things need to be configured using buildroot "make menuconfig"
>
> I admit that I don't like Kconfig. But then, I'm  also  unhappy  with
> what  we have now. Ideas for a beter solution are welcome, but please
> let's discuss concepts before submitting patches.

One of my main requirements is a consistent interface and ideally
everything is using the same configuration system.
The problem with using Kconfig is that it generates a single .config file.
It would be nice if it could generate one .config per package.
buildroot, linux, u-boot, busybox.

>> We just dont think alike.
>
> This is perfectly normal. We can still try to work with each other.
>
>> Which is good and completely different to Wolfgangs approach
>> to make it as difficult as possible to maintain out of tree patches
>> in the hope that no nonGPL versions of u-boot will appear.
>
> I don't see how I could do anything against out of tree patches  even
> if I wanted, nor am I aware that I ever tried.

You don't allow u-boot to have hooks for out of tree patches.
To be successful, there needs to exists a number of place holders
where the developer have total control and simply can copy in out of tree 
stuff.
Relying on patching existing files makes upgrading your out of tree 
structure
unneccessary time consuming.

Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR

[U-Boot-Users] Proposal for patch to configure networkparameters

[Wolfgang Denk]

In message <003801c784e0$7923d280$01c4af0a@Glamdring> you wrote:
>
> > This is not so different from Linux, btw. The only way to configure a
> > Linux kernel is by doing this inside the Linux source tree.
> 
> No, the way buildroot works is that you decompress a linux kernel and patch 
> it.

For a board that is fully supported by the kernel.org Linux  tree  no
patching is required, right?

> Then you can copy  $(LINUX26_KCONFIG) (defined by buildroot make 
> menucconfig)
> to the $(LINUX26_DIR)/.config.

And then you run thek kernel's config tool and make system. That's
what I mean when I said you do this inside the Linux source tree.

> This method meet my need to easily be able to select a working configuration 
> for Linux.

Agreed.

> I am doing the same for u-boot. A file is copied to 
> include/configs/<board>.h

Yes, that would be the equivalent, and should equally well.

> but there are somethings which always needs to change for a new user,
> and these things need to be configured using buildroot "make menuconfig"

OK. And here is where the problem starts: there is  no  easy  way  to
generate  a  "include/configs/<board>.h"  from  the "make menuconfig"
step.

Seems we're back at the technical level now, and I'm happy about this.

> One of my main requirements is a consistent interface and ideally
> everything is using the same configuration system.

Agreed.

> The problem with using Kconfig is that it generates a single .config file.
> It would be nice if it could generate one .config per package.
> buildroot, linux, u-boot, busybox.

Agreed.

> > I don't see how I could do anything against out of tree patches  even
> > if I wanted, nor am I aware that I ever tried.
> 
> You don't allow u-boot to have hooks for out of tree patches.

It seems we are using a different terminology here. To me, a patch is
something which you applly using the "patch" progarm  or  some  other
automated way like an "sed" or "perl" script etc.

And of course there is nothing I can do against  doing  this.  I  can
express my opinion that I don't like this because I think that better
solutions should be possible, but I cannot stoip you from doing it.

Note, that no "hooks" are needed for doing this.

> To be successful, there needs to exists a number of place holders
> where the developer have total control and simply can copy in out of tree 
> stuff.
> Relying on patching existing files makes upgrading your out of tree 
> structure
> unneccessary time consuming.

I fail to see where there is a  significant  difference  between  the
Linux  kernel and U-Boot: you can patch either of the source trees to
your liking, and when you copy a  "$(LINUX26_DIR)/.config"  file  for
Linux before running "make oldconfig" and "make uImage" you will copy
a "include/configs/<board>.h" file with U-Boot before you run "make".


The only difference, and I agree that it is  a  significant  one,  is
that you cannot easily auto-generate "include/configs/<board>.h" from
a  Kconfig  based  configuration system. You would need at least some
helper script, but even this should be straightforward to implement.


Instead of doing this, which fixes the problem for you while  leaving
the  rest  of the U-Boot community in the dark, we could also discuss
if there is a way to make U-Boot configuration easier for all of us.

It seems you prefer the first approach, while I am  looking  for  the
latter.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I have the simplest tastes.  I am always satisfied with the best.
                                                       -- Oscar Wilde

[U-Boot-Users] Proposal for patch to configure networkparameters

[Ulf Samuelsson]

> I fail to see where there is a  significant  difference  between  the
> Linux  kernel and U-Boot: you can patch either of the source trees to
> your liking, and when you copy a  "$(LINUX26_DIR)/.config"  file  for
> Linux before running "make oldconfig" and "make uImage" you will copy
> a "include/configs/<board>.h" file with U-Boot before you run "make".
>
>
> The only difference, and I agree that it is  a  significant  one,  is
> that you cannot easily auto-generate "include/configs/<board>.h" from
> a  Kconfig  based  configuration system. You would need at least some
> helper script, but even this should be straightforward to implement.
>

I consider it acceptable to have  "include/configs/<board>.h" to be constant 
for most users
of my S/W; but the networking environment will be different.
This is different for each user.
The memory configuration is also different.

>
> Instead of doing this, which fixes the problem for you while  leaving
> the  rest  of the U-Boot community in the dark, we could also discuss
> if there is a way to make U-Boot configuration easier for all of us.
>

This is a major undertaking and a long term project, which I have no chance 
of driving.
If someone decides that u-boot should be configured as part of the buildroot
configuration, then I can contribute.

Buildroot will allow me to create the contents of the board.h file in an 
incremental fashion
if I let the automatically generated info override the board.h files.  I 
like that.
I do not need to test any boards that I do not have access to.

> It seems you prefer the first approach, while I am  looking  for  the 
> latter.

I am not sure I agree that I keep everyone in the dark since I publish the 
source of my buildroot tree.
I would not have any problem providing this and my Atmel customized U-boot 
to you for inclusion in your ftp site.


> Best regards,
>
> Wolfgang Denk
>


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR

[U-Boot-Users] Proposal for patch to configure networkparameters

[Wolfgang Denk]

In message <000901c784eb$0f3b8b50$01c4af0a@Glamdring> you wrote:
>
> I consider it acceptable to have  "include/configs/<board>.h" to be constant 
> for most users
> of my S/W; but the networking environment will be different.
> This is different for each user.
> The memory configuration is also different.

Things like  serial  number,  MAC  address  etc.  fall  in  the  same
category.  All  other manufacturers I know handle this in a different
way; see my explanation earlier. So far, nobody else complained  that
any problems doing that.

> > Instead of doing this, which fixes the problem for you while  leaving
> > the  rest  of the U-Boot community in the dark, we could also discuss
> > if there is a way to make U-Boot configuration easier for all of us.
> 
> This is a major undertaking and a long term project, which I have no chance 
> of driving.

Not necessarily driving, but contibuting.

> If someone decides that u-boot should be configured as part of the buildroot
> configuration, then I can contribute.

Tailoring U-Boot for buildroot would be the wrong approach. We  don't
want  to create any such dependencies. Instead, we should try to come
up with a solution that works well for all users, no matter  if  they
use buildroot or ptxdist or whatever.

> Buildroot will allow me to create the contents of the board.h file in an 
> incremental fashion
> if I let the automatically generated info override the board.h files.  I 
> like that.

You did not comment on my argument that you can do this already  now,
in a similar way you do it for Linux.

> I do not need to test any boards that I do not have access to.

I am aware that this is your position.

> I am not sure I agree that I keep everyone in the dark since I publish the 
> source of my buildroot tree.

Substitute "everyone" by "everyone who does not use the same too  set
like  you  (i.  e.  buildroot)",  and you can see what I mean. If you
want, that is.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Overdrawn?  But I still have checks left!

[U-Boot-Users] Proposal for patch to configure networkparameters

[Wolfgang Denk]

In message <000b01c7849f$f2050430$01c4af0a@Glamdring> you wrote:
>
> I want the configuration to be done without serial port communication
> Connect to Ethernet, wait for LED to blink, next board....

This is a perfectly valid requirement. It pops up with  many  vendors
who  use U-Boot on their boards. Many actually use this in production
today.

Some read data from a special flash area, others run a script  stored
in  flash.  Some  leave this script in the flash after production and
eventually use it for example to implement reset to factory defaults,
others  erase  or  overwrite  it  or  use  self-deleting  environment
variables for a run-once setup.

> According to Wolfgang, this promotes other people's evil doings
> and you must select a non-efficient solution if you want to use main tree 
> u-boot.

I agree with you that  the  way  how  U-Boot  gets  configured  needs
improvement,  but  instead  of implementing some "backdoor" to inject
configuration information from a tool that lives outside  the  U-Boot
tree we should try and improve the U-Boot code.

You are welcome to contribute  to  this,  but  please  let's  discuss
design  and implementations first, before submitting patches that may
lead to discussions that are frustrating for both sides.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I used to be indecisive, now I'm not sure.

[U-Boot-Users] Proposal for patch to configure network parameters

[Timur Tabi]

Wolfgang Denk wrote:

> Actually these parameters  (and  more,  like  MAC  addresses)  should
> *never* be set at all in the U-Boot configuration. They exist for (1)
> hysterical  reasons  I'm  not  going to explain, and (2) because some
> (paying!) customer insisted on having such a feature.

Could you post a list of configuration parameters that you'd rather not see in a board 
header file?  When I created MPC8349ITX.h, I just followed the example of other 83xx 
boards.  I defined the network CONFIG_ options, because I thought that a flash-default 
setting would be useful.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Proposal for patch to configure network parameters

[Wolfgang Denk]

In message <462946CF.1000807@freescale.com> you wrote:
> 
> Could you post a list of configuration parameters that you'd rather not see in a board 
> header file?  When I created MPC8349ITX.h, I just followed the example of other 83xx 
> boards.  I defined the network CONFIG_ options, because I thought that a flash-default 
> setting would be useful.

At least partially it's a matter of taste. I tend to rather make sure
that a user of the board sees that he must provide  his  own  network
configuration  by providing no default setting, rather then having to
deal with nasty network issues because several boards share the  same
IP or - even worse - MAC addresses.


Just use common sense. Anything that is board-specific  should  never
be  set  in  the  board  config file because that would mean that all
boards would share this property in the default configuration.

An absolute no-no is CONFIG_ETH*ADDR.

Similar, attempts to define a standard setting for "serial#" are
seriously broken.

I also consider it bad design to set CONFIG_IPADDR an CONFIG_HOSTNAME


Note that you *can* do all these things, if you know exactly what you
are doing - that's whey the feature is there. But shipping boards  to
customer  with  all  set  to  the  same  MAC  address is a felony and
deserves serious punishment (hello Andrea!). 


Ulf was (originally) asking for a customization feature; of course it
makes sense to customize boards during production, for example to set
board-specific values for MAC address, serial number, etc.  But  this
can, and should, be done without creating different U-Boot images.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are three things I always forget. Names, faces -  the  third  I
can't remember.                                         - Italo Svevo

[U-Boot-Users] Proposal for patch to configure networkparameters

[Ulf Samuelsson]

>> Could you post a list of configuration parameters that you'd rather not 
>> see in a board
>> header file?  When I created MPC8349ITX.h, I just followed the example of 
>> other 83xx
>> boards.  I defined the network CONFIG_ options, because I thought that a 
>> flash-default
>> setting would be useful.
>
> At least partially it's a matter of taste. I tend to rather make sure
> that a user of the board sees that he must provide  his  own  network
> configuration  by providing no default setting, rather then having to
> deal with nasty network issues because several boards share the  same
> IP or - even worse - MAC addresses.
>
>
> Just use common sense. Anything that is board-specific  should  never
> be  set  in  the  board  config file because that would mean that all
> boards would share this property in the default configuration.
>
> An absolute no-no is CONFIG_ETH*ADDR.
>
> Similar, attempts to define a standard setting for "serial#" are
> seriously broken.
>
> I also consider it bad design to set CONFIG_IPADDR an CONFIG_HOSTNAME
>
>
> Note that you *can* do all these things, if you know exactly what you
> are doing - that's whey the feature is there. But shipping boards  to
> customer  with  all  set  to  the  same  MAC  address is a felony and
> deserves serious punishment (hello Andrea!).

I am not shipping *any* boards to anyone, so I dont have the problem...

If you want to avoid misuse of the feature, you could actually reserve a 
specific
ethaddr for production use in a point to point configuration
and check for this ethaddr when you boot.
If you have this ethaddr, then you will not boot, and will instead print an 
error message...

>
> Ulf was (originally) asking for a customization feature; of course it
> makes sense to customize boards during production, for example to set
> board-specific values for MAC address, serial number, etc.  But  this
> can, and should, be done without creating different U-Boot images.
>

Again, none of these values are BOARD specific.
The board specific values are set using "autoscr"
but you can't tftp down a script without an ethaddr, can you?

Again, very little of the discussion is still about the patch itself.


The reason for the patch , is that I would want to be able to generate some
arbitrary configuration items using scripts (or even by a simple copy)
and I do not want to modify any board.h files to do this.

Is this really a bad thing?



> Best regards,
>
> Wolfgang Denk
>
> -- 


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR
link: www.avrfreaks.net 

[U-Boot-Users] Proposal for patch to configure network parameters

[Andreas Schweigstill]

Hello!

Wolfgang Denk schrieb:
 > But shipping boards  to
 > customer  with  all  set  to  the  same  MAC  address is a felony and
 > deserves serious punishment (hello Andrea!).

Oh, are you talking about some old DSL modems from Deutsche Telekom or
HP printservers? ;-)

With best regards
Andreas Schweigstill

-- 
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstra?e 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/

[U-Boot-Users] Proposal for patch to configure network parameters

[Timur Tabi]

Wolfgang Denk wrote:

> Just use common sense. Anything that is board-specific  should  never
> be  set  in  the  board  config file because that would mean that all
> boards would share this property in the default configuration.

> An absolute no-no is CONFIG_ETH*ADDR.

$ grep CONFIG_ETH.*ADD include/configs/MPC8349ITX.h
#define CONFIG_ETHADDR          00:E0:0C:00:8C:01
#define CONFIG_ETH1ADDR         00:E0:0C:00:8C:02

Oops.

Although, to be honest, this is very handy for me because these are the 
MAC addresses that have been assigned to the MPC8349E-mITX board in our 
lab.  This way, every time I build an image, it's guaranteed to have the 
right MAC addresses.  I don't need to run some kind of script to set up 
my variables.

Is there some easy way for me to specify personalized config options at 
build time?

> Note that you *can* do all these things, if you know exactly what you
> are doing - that's whey the feature is there. But shipping boards  to
> customer  with  all  set  to  the  same  MAC  address is a felony and
> deserves serious punishment (hello Andrea!).

I agree, but if every board has the same flash image, how do we specify 
a different MAC address for each one?

> Ulf was (originally) asking for a customization feature; of course it
> makes sense to customize boards during production, for example to set
> board-specific values for MAC address, serial number, etc.  But  this
> can, and should, be done without creating different U-Boot images.

I don't see how.  Not every company has a manufacturing process that 
allows that.  This is especially true for reference boards, which aren't 
supposed to be used in a public environment anyway.

[U-Boot-Users] Proposal for patch to configure network parameters

[Wolfgang Denk]

In message <462BC189.2040502@freescale.com> you wrote:
>
> Although, to be honest, this is very handy for me because these are the 
> MAC addresses that have been assigned to the MPC8349E-mITX board in our 
> lab.  This way, every time I build an image, it's guaranteed to have the 
> right MAC addresses.  I don't need to run some kind of script to set up 
> my variables.

I understand that it may be handy for you, but it may be a  debugging
nightmare for your users, and it may generate a lot of support calls.

> Is there some easy way for me to specify personalized config options at 
> build time?

Use a script to auto-install your board. Expect is a great  tool.  Or
at least make sure that these settings never go out to a customer, i.
e. make sure they are fixed during production (probably when you save
serial  numbers  etc.).  But  IMHO it's definitely better not to have
these build in at all.

> I agree, but if every board has the same flash image, how do we specify 
> a different MAC address for each one?

Normally you do this during production. It depends  how  your  boards
are  manufactured  and tested - if testing includes to boot the board
at least once, then this is where you can add such customization.

> I don't see how.  Not every company has a manufacturing process that 

See all my previous postings.

> allows that.  This is especially true for reference boards, which aren't 
> supposed to be used in a public environment anyway.

Ummm... all Freescale reference boards  that  make  their  way  to  a
customer run in a "public environment".

Anyway - there are standards which shold be adhered to, and they make
it pretty clear that you must not use the same MAC address  for  more
than one board.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Perfection is reached, not when there is no longer anything  to  add,
but when there is no longer anything to take away.
                                           - Antoine de Saint-Exupery

[U-Boot-Users] Proposal for patch to configure networkparameters

[Ulf Samuelsson]

>
> I understand that it may be handy for you, but it may be a  debugging
> nightmare for your users, and it may generate a lot of support calls.
>

One of the main driving forces behind my efforts is to reduce the number of
support phone calls, by significantly reducing the complexity of getting a 
board
up and running.

>> Is there some easy way for me to specify personalized config options at
>> build time?
>
> Use a script to auto-install your board. Expect is a great  tool.

Expect is Linux specific. I want to be able to do things using
tools as simple as Hyperterminal, or even without serial line at all.

> at least make sure that these settings never go out to a customer,

> i. e. make sure they are fixed during production (probably when you save
> serial  numbers  etc.).  But  IMHO it's definitely better not to have
> these build in at all.
>
>> I agree, but if every board has the same flash image, how do we specify
>> a different MAC address for each one?

> Ummm... all Freescale reference boards  that  make  their  way  to  a
> customer run in a "public environment".

If  you, like me, dont deliver any boards, then you do not have this 
problem.
It is the reponsibility of the user of the S/W to ensure that it is
used in a restricted environment like production or development
where the MAC address can be selected at random.


Best Regards
Ulf Samuelsson

[U-Boot-Users] Proposal for patch to configure networkparameters

[Wolfgang Denk]

In message <005c01c78528$c4831720$01c4af0a@Glamdring> you wrote:
>
> > Use a script to auto-install your board. Expect is a great  tool.
> 
> Expect is Linux specific. I want to be able to do things using

No. Expect is based on tcl, and tcl is available for other host
environments, too, including Solaris, HP-UX and Windows.

> tools as simple as Hyperterminal, or even without serial line at all.

AFAIK even HT understands some form of "scripting".

Without serial line, you can  use  one  of  the  other  approaches  I
explained  several  times  during  the  last  two days. They work for
others, and theycould work  for  you,  too,  it  you  tried.  Without
chnages to the code, mind you.

> If  you, like me, dont deliver any boards, then you do not have this 
> problem.

Indeed, it's a SEP instead - Somebody Else's Problem.

> It is the reponsibility of the user of the S/W to ensure that it is
> used in a restricted environment like production or development
> where the MAC address can be selected at random.

Making life easy for you and difficult for the user is  only  one  of
the many possible ways of working. It's not my preferred way.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It's hard to think of you as the end result of millions of  years  of
evolution.

[U-Boot-Users] Proposal for patch to configure networkparameters

[Ulf Samuelsson]

m?n 2007-04-23 klockan 01:57 +0200 skrev Wolfgang Denk:
> In message <005c01c78528$c4831720$01c4af0a@Glamdring> you wrote:
> >
> > > Use a script to auto-install your board. Expect is a great  tool.
> > 
> > Expect is Linux specific. I want to be able to do things using
> 
> No. Expect is based on tcl, and tcl is available for other host
> environments, too, including Solaris, HP-UX and Windows.
> 
> > tools as simple as Hyperterminal, or even without serial line at all.
> 
> AFAIK even HT understands some form of "scripting".

Since U-Boot does have a enviroment area. the natural place
to put compile time initialization is in the environment area
and compile the environment as a separate entity which is linked
to the environment. You can define a sector in the <board>.lds.
It will not handle "reset to factory defaults" though.

Then you can have compile time initialization AND 
if you so choose, you could during production decide
to first program u-boot into the flash, and then afterwards
modify the environment.
On a dataflash that is easy, since the minimium erase block is 1056
bytes and you have several blocks in the environment area.

Doing it this way, still require you to *create* the environment data
Until there is a configuration method which allows your
grandmother to get networking running my proposed patch is still useful.



> Without serial line, you can  use  one  of  the  other  approaches  I
> explained  several  times  during  the  last  two days. They work for
> others, and theycould work  for  you,  too,  it  you  tried.  Without
> chnages to the code, mind you.
> 
> > If  you, like me, dont deliver any boards, then you do not have this 
> > problem.
> 
> Indeed, it's a SEP instead - Somebody Else's Problem.
> 
> > It is the reponsibility of the user of the S/W to ensure that it is
> > used in a restricted environment like production or development
> > where the MAC address can be selected at random.
> 
> Making life easy for you and difficult for the user is  only  one  of
> the many possible ways of working. It's not my preferred way.

My goal is to make it easier for the user, and I hopefully 
will at a later stage will have a small application which
will generate a board specific script which can be installed
on the production PC and run once per board.

Currently the ethernet address is already set by u-boot.
It is set to 00:00:00:00:00:00, making it impossible 
to communicate over ethernet.


> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot-Users] MPC8343 I2C problem

[Monstr at seznam.cz]

HI,
I am trying to port U-BOOT to board with MPC8343 and I have problem with reading data from I2C. Iprobe command  detects EEPROM memory  but after imd 50 0 20 a read only 0xff values. In EEPROM memory is stored configuration words. And configuration word is strored properly because after unplug BDI board starts fine and we can reading memory via OS. I tryied to change SPEED too.

Best regards
Michal Simek

#define  CONFIG_HARD_I2C		/* I2C with hardware support*/
#ifdef CONFIG_HARD_I2C
#undef	CONFIG_SOFT_I2C			/* I2C bit-banged */
#define CONFIG_FSL_I2C
#define CONFIG_I2C_MULTI_BUS
#define CONFIG_I2C_CMD_TREE
//#define CFG_I2C_SPEED		400000		/* I2C speed and slave address - 400kHz */
#define CFG_I2C_SPEED		100000		/* I2C speed and slave address - 100kHz */
#define CFG_I2C_SLAVE		0x7F
#define CFG_I2C_OFFSET		0x3000		/* prvni I2C interface - posun od IMMR */
#define CFG_I2C2_OFFSET		0x3100		/* druhy I2C interface - posun od IMMR */
#define CFG_I2C_EEPROM_ADDR		0x50	/* I2C0, Board EEPROM */
#define CFG_I2C_EEPROM_ADDR_LEN 	2
#endif



U-Boot 1.2.0 (Apr 23 2007 - 08:31:58) MPC83XX

Clock configuration:
  Coherent System Bus:  264 MHz
  Core:                 396 MHz
  Local Bus Controller: 264 MHz
  Local Bus:             66 MHz
  DDR:                  264 MHz
  SEC:                   88 MHz
  I2C1:                  88 MHz
  I2C2:                 264 MHz
  TSEC1:                 88 MHz
  TSEC2:                 88 MHz
  USB MPH:               88 MHz
  USB DR:                88 MHz
CPU: MPC8343E, Rev: 11 at 396 MHz


=> iprobe
Valid chip addresses: 50
=> imd 50 0 20
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
=> imd 50.0 0 20
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
=> imd 50.1 0 20
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
=> imd 50.2 0 20
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
=>

[U-Boot-Users] MPC8343 I2C problem

[Timur Tabi]

Monstr at seznam.cz wrote:
> HI,
> I am trying to port U-BOOT to board with MPC8343 and I have problem with reading data from I2C. Iprobe command  detects EEPROM memory  but after imd 50 0 20 a read only 0xff values. In EEPROM memory is stored configuration words. And configuration word is strored properly because after unplug BDI board starts fine and we can reading memory via OS. I tryied to change SPEED too.

On 83xx boards, CFG_I2C_SPEED is not used.  This is a known bug that I intend to fix one 
day.  The actual speed value that is programmed into the controller is hard-coded and is 
somewhat conservative.  See function i2c_init().

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] MPC8343 NET without PHY

[Monstr at seznam.cz]

Hi,
We are use on development board Vitesse switch connected via RGMII. I look at MPC8349ITX which use the similar switch but only for one TSEC2 interface and via GMII. 

Can MPC8349ITX load files via TSEC2? 

Does U-BOOT support communication via RGMII?

And howto turn off PHY detection?

Net:   TSEC0: PHY id ffff is not supported!
TSEC0: No PHY found
TSEC1: PHY id ffff is not supported!
TSEC1: No PHY found
TSEC0, TSEC1


My current setting is below.
Best regards,
Michal Simek

#ifdef CONFIG_TSEC_ENET
#define CONFIG_NET_MULTI 	1	/* support for multiple interface */
#define CONFIG_MPC83XX_TSEC1	1	/* TSEC1 */
#define CONFIG_MPC83XX_TSEC2	1	/* TSEC2 */
#define CONFIG_GMII		1	/* MII PHY management */

#ifdef CONFIG_MPC83XX_TSEC1
#define CONFIG_MPC83XX_TSEC1_NAME	"TSEC0"
#define CFG_TSEC1_OFFSET		0x24000
#define CFG_TSEC1			(CFG_IMMR + CFG_TSEC1_OFFSET)
#define TSEC1_PHY_ADDR			0
#define TSEC1_PHYIDX			0
#define CONFIG_ETHPRIME			"TSEC0" /* Options are: TSEC[0-1] */
#endif /* CONFIG_MPC83XX_TSEC1 */

#ifdef CONFIG_MPC83XX_TSEC2
#define CONFIG_MPC83XX_TSEC2_NAME	"TSEC1"
#define CFG_TSEC2_OFFSET		0x25000
#define CFG_TSEC2			(CFG_IMMR + CFG_TSEC2_OFFSET)
#define TSEC2_PHY_ADDR			1
#define TSEC2_PHYIDX			0

#ifndef CONFIG_ETHPRIME
#define CONFIG_ETHPRIME			"TSEC0" /* Options are: TSEC[0-1] */
#endif /* CONFIG_ETHPRIME */

#endif /* CONFIG_MPC83XX_TSEC2 */
#endif /* CONFIG_TSEC_ENET */

[U-Boot-Users] MPC8343 NET without PHY

[Timur Tabi]

Monstr at seznam.cz wrote:

> Can MPC8349ITX load files via TSEC2? 

The U-Boot that is on the MPC8349ITX BSP supports TSEC2.  The reason is that you need to 
load some proprietary binary firmware in order to the Vitesse 7385 working, and we can't 
distribute that firmware in U-Boot itself.

> And howto turn off PHY detection?
> 
> Net:   TSEC0: PHY id ffff is not supported!
> TSEC0: No PHY found
> TSEC1: PHY id ffff is not supported!
> TSEC1: No PHY found
> TSEC0, TSEC1

Have you tried the generic PHY patch?

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/23766/match=generic+phy

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Proposal for patch to configure networkparameters

[Wolfgang Denk]

In message <1177306991.4872.25.camel@elrond.sweden.atmel.com> you wrote:
>
> Since U-Boot does have a enviroment area. the natural place
> to put compile time initialization is in the environment area
> and compile the environment as a separate entity which is linked
> to the environment. You can define a sector in the <board>.lds.
> It will not handle "reset to factory defaults" though.
> 
> Then you can have compile time initialization AND 
> if you so choose, you could during production decide
> to first program u-boot into the flash, and then afterwards
> modify the environment.
> On a dataflash that is easy, since the minimium erase block is 1056
> bytes and you have several blocks in the environment area.

It's good that we have an agreement here. This is exactly what I
proposed to you a couple of times before.

> Doing it this way, still require you to *create* the environment data
> Until there is a configuration method which allows your
> grandmother to get networking running my proposed patch is still useful.

I cannot follow this conclusion, though.

> My goal is to make it easier for the user, and I hopefully 
> will at a later stage will have a small application which
> will generate a board specific script which can be installed
> on the production PC and run once per board.
> 
> Currently the ethernet address is already set by u-boot.
> It is set to 00:00:00:00:00:00, making it impossible 
> to communicate over ethernet.

This is making it difficult to the user. I guess  each  board  has  a
real  MAC  address,  so  why  don't  you use this one? [Also, IMO not
setting the MAC address at all is still better than setting it  to  a
non-working value.]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Murder is contrary to the laws of man and God.
	-- M-5 Computer, "The Ultimate Computer", stardate 4731.3

[U-Boot-Users] Proposal for patch to configure networkparameters

[Ulf Samuelsson]

m?n 2007-04-23 klockan 10:59 +0200 skrev Wolfgang Denk:
> In message <1177306991.4872.25.camel@elrond.sweden.atmel.com> you wrote:
> >
> > Since U-Boot does have a enviroment area. the natural place
> > to put compile time initialization is in the environment area
> > and compile the environment as a separate entity which is linked
> > to the environment. You can define a sector in the <board>.lds.
> > It will not handle "reset to factory defaults" though.
> > 
> > Then you can have compile time initialization AND 
> > if you so choose, you could during production decide
> > to first program u-boot into the flash, and then afterwards
> > modify the environment.
> > On a dataflash that is easy, since the minimium erase block is 1056
> > bytes and you have several blocks in the environment area.
> 
> It's good that we have an agreement here. This is exactly what I
> proposed to you a couple of times before.
> 

AFAIK; U-Boot currently do not support this, 
and the method still does not support reverting to factory defaults.
If someone implements this, I'd be happy to adopt it,
I am not going to do that work though.
I see no immediate benefit over a "factory default" command.


> > Doing it this way, still require you to *create* the environment data
> > Until there is a configuration method which allows your
> > grandmother to get networking running my proposed patch is still useful.
> 
> I cannot follow this conclusion, though.

The goal of the patch is to be able to define U-boot
environment variables outside the <board>.h files.

The environment should be changable by anyone
capable of programming a VHS video but without
any knowledge of U-boot.

Due to lack of good configuration in u-boot,
I have selected to generate the needed configuration
in buildroot, but I am sure that other build systems
like ptxdist/Eclipse could use the same.

A furster restriction, is that I do not want the user
to use hard to understand packages like "expect" 
to configure the board.
I also want a method to do configuration without
connecting a serial port at all.
Only port needed is Ethernet.

Your worry about "bad" ethernet configurations beeing
propagated to users can be handled by refusing to boot
if the ethernet address is within a certain range of values.
U-Boot should always allow "experimental" ethaddr variables
to be overwritten.
It is not done right now, but it is probably not hard to implement.

This still allows connecting to a host and downloading
the real configuration 

when I configure my buildroot system.
A maintainable way to do this, is




> > My goal is to make it easier for the user, and I hopefully 
> > will at a later stage will have a small application which
> > will generate a board specific script which can be installed
> > on the production PC and run once per board.
> > 
> > Currently the ethernet address is already set by u-boot.
> > It is set to 00:00:00:00:00:00, making it impossible 
> > to communicate over ethernet.
> 
> This is making it difficult to the user. I guess  each  board  has  a
> real  MAC  address,  so  why  don't  you use this one? [Also, IMO not
> setting the MAC address at all is still better than setting it  to  a
> non-working value.]
> 
No, Atmel does not ship AT91 boards with a MAC address.
They are shipped with the MAC address cleared.
I dont like that, but this is the way it is.
It is the buyers reponsibility to get a MAC address.
Since I am not shipping any boards, I do not set any boards
to a non-working value.

My buildroot allows the customer to set the ethaddr to a fixed value
or leave it empty, but he should be able to change that to a real value
at the manufacturing site.


> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot-Users] Proposal for patch to configure networkparameters

[Wolfgang Denk]

In message <1177320294.4872.95.camel@elrond.sweden.atmel.com> you wrote:
>
> > It's good that we have an agreement here. This is exactly what I
> > proposed to you a couple of times before.
> 
> AFAIK; U-Boot currently do not support this, 

Yes,  of  course  it  does.  Just  configure  your  board  that  your
environment  sector(s) is (are) directly adjacent to the U-Boot image
(i. e. after it on ARM). U-Boot does not care where  the  code  comes
from. You just need a small tool to create the environment image; the
code in tools/env/ needs only minimal tweaking to do this.

> and the method still does not support reverting to factory defaults.

Right. For this purpose, it's much better to use a script image which
is placed in a flash sector, so you can run a  'autoscr"  command  to
install the default settings.


But I'm repeating myself. I described all of this before. Several
times actually.

> If someone implements this, I'd be happy to adopt it,

Go for it. It's all at your hands. Just use it.

> I am not going to do that work though.

No work needs to be done.

Please try to understand that you are not the  first  one  who  needs
such  features, and that solutions already exist. The are just diffe-
rent from your proposed patch, but IMHO that does  not  automatically
mean that they are worse or less powerful.

> The goal of the patch is to be able to define U-boot
> environment variables outside the <board>.h files.

I described at least two different ways to solve this problem without
changing the U-Boot code.

> Due to lack of good configuration in u-boot,
> I have selected to generate the needed configuration
> in buildroot, but I am sure that other build systems
> like ptxdist/Eclipse could use the same.

Configuration is a different issue than setting up the environment.

> A furster restriction, is that I do not want the user
> to use hard to understand packages like "expect" 
> to configure the board.

We were talking about the initial installation of the software during
production. Also, the user does not need much understanding to use  a
script  you  give to him. Actually the buildroot code you use is much
more complicated than the required expect script would  be.  If  your
user  is  supposed  to  be  clever  enought  o  run buildrot, then he
isprobably also clever enough to  run  another  script  (which  might
actually be integrated in your build / install steps).

> I also want a method to do configuration without
> connecting a serial port at all.
> Only port needed is Ethernet.

See above.

> Your worry about "bad" ethernet configurations beeing
> propagated to users can be handled by refusing to boot
> if the ethernet address is within a certain range of values.
> U-Boot should always allow "experimental" ethaddr variables
> to be overwritten.

Please adhere to standards.

> It is not done right now, but it is probably not hard to implement.

U-Boot assumes that you install valid MAC addresses as required by the
standard. In addition to that, it follows the good old rule:

"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn

> No, Atmel does not ship AT91 boards with a MAC address.
> They are shipped with the MAC address cleared.

No comment.



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In the future, you're going to get computers as prizes  in  breakfast
cereals.  You'll  throw  them out because your house will be littered
with them.                                             - Robert Lucky

[U-Boot-Users] Proposal for patch to configure networkparameters

[Ulf Samuelsson]

If anyone wants to see how it works in practice,
then running the attached script will download my
new buildroot, and build a complete set of functions
to get a board running with Linux.


It will build
at91-bootstrap-2.3 with my private additions
u-boot-1.2.0	   with my private additions
linux-2.6.20.4	   maxim + experimental patches
rootfs (jffs2)
rootfs (ext2)

for the following configurations:
at91rm9200df*      at91rm9200ek running from dataflashcard
at91sam9260dfc	   at91sam9260ek running from dataflashcard
at91sam9261ek*	   at91sam9261 running from internal dataflash
at91sam9263ek	   at91sam9263ek running from dataflashcard

Only the two boards marked '*' have been run on actual H/W yet,
the other two boards will be tested when I get my boards back.

Don't try to get support for these things from Atmel
since they do not know anything about the internals.

The stuff is also available at:
 www.at91.com 
in the AT91 Buildroot project.
--------------------------------------------------------------


#!/bin/bash
TOPDIR=`pwd`
BUILDROOT=buildroot-atmel
BUILDROOT_VER=2007-04-22
BUILDROOT_SOURCE=${BUILDROOT}-${BUILDROOT_VER}.cpio.bz2
BUILDROOT_SITE=ftp://at91dist:distrib at 81.80.104.162/AT91_Third_Party_Design_Flow/Linux_Host/Source
DL_DIR=${TOPDIR}/Source
UNZIP=bzcat

function	prepare_directories()
{
	mkdir	-p	/tftpboot
	mkdir	-p	/usr/local/arm
	mkdir	-p	/usr/local/install/downloads
}

function	get_buildroot()
{
	if ! [ -d ${BUILDROOT} ] ; then
		mkdir -p ${DL_DIR}
		wget	-P ${DL_DIR}	${BUILDROOT_SITE}/${BUILDROOT_SOURCE}
		${UNZIP}	${DL_DIR}/${BUILDROOT_SOURCE} | cpio -idv
	fi
}

function	make_board()
{
	cd	${BUILDROOT}
	echo	"building board $1"
	make 	B=$1 board
	make	$2
	make	saveconfig
	cd	${TOPDIR}
}

function	make_all_boards()
{
	make_board	at91rm9200df	$1
	make_board	at91sam9260dfc	$1
	make_board	at91sam9261ek	$1
	make_board	at91sam9263ek	$1
}


prepare_directories
get_buildroot
make -C ${BUILDROOT} menuconfig
make_all_boards	source
make_all_boards


-- 
Best Regards
Ulf Samuelsson

-------------- next part --------------
A non-text attachment was scrubbed...
Name: make_boards.sh
Type: application/x-shellscript
Size: 969 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070423/be8b93b8/attachment.bin 

[U-Boot-Users] Proposal for patch to configure networkparameters

[Ulf Samuelsson]

> I agree, but if every board has the same flash image, how do we specify
> a different MAC address for each one?
>

Shipping

>> Ulf was (originally) asking for a customization feature; of course it
>> makes sense to customize boards during production, for example to set
>> board-specific values for MAC address, serial number, etc.  But  this
>> can, and should, be done without creating different U-Boot images.
>
I do not expect any person to need more than one image, and
I do not expect that two different companies does not need to have
exactly the same image as other companies.

I do not plan to deliver binaries, only source,. so noone will be able to 
use this
without rebuilding the u-boot.
Anyone not modifying the configuration files will get the "default" binary.
Anyone not explictly running the "defenv" command will not see any of the
configuration created using buildroot.

> I don't see how.  Not every company has a manufacturing process that
> allows that.  This is especially true for reference boards, which aren't
> supposed to be used in a public environment anyway.
>
>


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57