[U-Boot-Users] Proposal for patch to configure network parameters
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
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?
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
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
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@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@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR
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
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@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@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR link: www.avrfreaks.net
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
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
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
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).
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
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?
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
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
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
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@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@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR link: www.avrfreaks.net
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
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@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@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR link: www.avrfreaks.net
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
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
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
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@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@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR link: www.avrfreaks.net
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.
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
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
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
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
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@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@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR
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
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@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@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR
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
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
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.
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
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@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@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR link: www.avrfreaks.net
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
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.
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
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
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
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
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 ................ =>
Monstr@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().
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 */
Monstr@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+...
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
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
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
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@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
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@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
participants (8)
-
Andreas Schweigstill -
Ben Warren -
Monstr＠seznam.cz -
Robert Schwebel -
Robert Schwebel -
Timur Tabi -
Ulf Samuelsson -
Wolfgang Denk