ARTOS boot support for u-boot
PATCH 1/1 ARTOS boot support for u-boot
Wolfgang hi
The following patch against u-boot-0.3.0 adds support for booting ARTOS images
using u-boot. ARTOS is a custom in-house operating system in use by my company.
We're in the process of moving some features of our in house boot-loader over to u-boot. I present the features to the mailing list in case someone else
is working in anything similar, and would like to coordinate our efforts.
o VLAN support and TOS configuration and support.
o Two level access password support.
o Different boot-modes.
o Cisco router like command interface with history and command completion.
o UDP-based same-LAN terminal access.
o Factory testing framework.
o More DHCP parameters support.
o CDP support.
o DHCP lease time information passed to the loaded kernel.
Looking forward to hear your suggestions.
Regards
Pantelis
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: u-boot-0.3.0-artos.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20030417/4192894d/attachment.txt
Dear Pantelis,
Quoted 5 lines · in message <[email protected]> you wrote:
The following patch against u-boot-0.3.0 adds support for booting ARTOS images
using u-boot. ARTOS is a custom in-house operating system in use by my company.
Thanks, I'll merge this into the CVS tree ASAP.
Quoted 4 lines
We're in the process of moving some features of our in house boot-loader over to u-boot. I present the features to the mailing list in case someone else
is working in anything similar, and would like to coordinate our efforts.
OK.
Quoted 1 line
o VLAN support and TOS configuration and support.
What exactly do you mean? Please note that U-Boot does not implement, or even attempt to implement, a full TCP/IP stack. We have just the absolutely necessary minimum of UDP.
Quoted 1 line
o Two level access password support.
What do you mean with "two level"?
Quoted 1 line
o Different boot-modes.
Please explain. There already are different boot modes, with a lot of configuration options depending on the specific board.
How good is your German? Can you parse board/lwmon/README.keybd ?
Quoted 1 line
o Cisco router like command interface with history and command completion.
But please do not try to add readline support - the readline lib is way too big...
Quoted 1 line
o UDP-based same-LAN terminal access.
OK.
Quoted 1 line
o Factory testing framework.
Please see the existing POST code.
Quoted 1 line
o More DHCP parameters support.
Which ones are you missing?
Quoted 1 line
o CDP support.
CDP = Cisco Discovery Protocol?
Quoted 1 line
o DHCP lease time information passed to the loaded kernel.
OK.
Quoted 1 line
Looking forward to hear your suggestions.
I don't understand some of your items, or why you need them. Maybe you can explain. But as long as everything can be configured out, so it does not affect the existing code in terms of code size and readability every contribution is welcome.
Best regards,
Wolfgang Denk
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de It's hard to make a program foolproof because fools are so ingenious.
Quoted 4 lines · Wolfgang Denk
Dear Pantelis,
in message <[email protected]> you wrote:
Quoted 8 lines
Quoted 5 lines
The following patch against u-boot-0.3.0 adds support for booting ARTOS images
using u-boot. ARTOS is a custom in-house operating system in use by my company.Thanks, I'll merge this into the CVS tree ASAP.
No, thank you...
Quoted 10 lines
Quoted 6 lines
We're in the process of moving some features of our in house boot-loader over to u-boot. I present the features to the mailing list in case someone else
is working in anything similar, and would like to coordinate our efforts.OK.
Quoted 7 lines
Quoted 2 lines
o VLAN support and TOS configuration and support.
What exactly do you mean? Please note that U-Boot does not implement, or even attempt to implement, a full TCP/IP stack. We have just the absolutely necessary minimum of UDP.
Yes, I understand about that. However our devices when deployed typically operate
on a VLAN, in order to not disrupt the normal IP traffic, or to be granted priority
over the other traffic. The amount of code is minimal, and only very few new environment
variables are needed.
Quoted 6 lines
Quoted 3 lines
o Two level access password support.
What do you mean with "two level"?
By two level I mean that when something is deployed normally there are two access
levels. One level is the user level, which is allowed to view settings and alter
very few parameters. The other level is the administrator level in which it is
permitted to do (almost) anything.
Quoted 7 lines
Quoted 3 lines
o Different boot-modes.
Please explain. There already are different boot modes, with a lot of configuration options depending on the specific board.
Sure. Depending on the deployment method for each site the configuration of the devices differ.
For example when you do a trial deployment it is pretty normal to have every device configured individually by the administration. In normal operation the devices operate using DHCP/TFTP for obtaining their settings. In both of these modes password are honoured, and the booting of the kernel is immediate
Developers in the other hand are working in a
different level and like access to everything including to be able to do a full factory-type resetting of the paramers.
Think of it as simplified run-levels.
Quoted 3 lines
How good is your German? Can you parse board/lwmon/README.keybd ?
My German is not existant unfortunately, but I'll pass it to a collegue who is fluent.
Quoted 7 lines
Quoted 3 lines
o Cisco router like command interface with history and command completion.
But please do not try to add readline support - the readline lib is way too big...
No it is not like readline. It is much more light-weight, the current version
weighs in at about 12k.
Quoted 4 lines
Quoted 3 lines
o UDP-based same-LAN terminal access.
Quoted 8 lines
OK.
Quoted 2 lines
o Factory testing framework.
Please see the existing POST code.
Thanks, I'll check it.
Quoted 6 lines
Quoted 3 lines
o More DHCP parameters support.
Which ones are you missing?
Some VoIP specific, and some Cisco specific ones.
Quoted 6 lines
Quoted 3 lines
o CDP support.
CDP = Cisco Discovery Protocol?
Yes. This is required when the device is ethernet powered by a Cisco switch. CDP is used to inform the switch for the device's power budget requirements.
Quoted 10 lines
Quoted 3 lines
o DHCP lease time information passed to the loaded kernel.
OK.
Quoted 2 lines
Looking forward to hear your suggestions.
Quoted 10 lines
I don't understand some of your items, or why you need them. Maybe you can explain. But as long as everything can be configured out, so it does not affect the existing code in terms of code size and readability every contribution is welcome.
Best regards,
Wolfgang Denk
Forgot one more thing.
DNS lookup capability. Yes I know that it is strange but actually some DHCP options can return hostnames so it is needed.
Most of these features deal with the deployment situation, of possibly hundred
of un-attended or minimally administrated devices. Or with the production requirements of said devices.
Everything will be controlled by a CONFIG_ option, and I'll make every effort to be as unobtrusive as possible to the rest of the code.
Wolfgang you are free to veto anything that you deem unacceptable; the best I can do is to present my case for the inclusion of these features.
Regards
Pantelis
Dear Pantelis,
Quoted 6 lines · in message <[email protected]> you wrote:
Quoted 6 lines
Quoted 3 lines
o Two level access password support.
What do you mean with "two level"?
Quoted 7 lines
By two level I mean that when something is deployed normally there are two access
levels. One level is the user level, which is allowed to view settings and alter
very few parameters. The other level is the administrator level in which it is
permitted to do (almost) anything.
I cannot see a way to implement this without dramatically changing the functionality and code of U-Boot. You cannot easily restrict the user from - for example - overwriting certain environment variables without castrating him from the power of defining his own settings.
I feel when you need such a level of authentification then the boot loader is not the right environment for your task - use an OS.
Quoted 18 lines
Quoted 6 lines
Quoted 2 lines
o Different boot-modes.
Please explain. There already are different boot modes, with a lot of configuration options depending on the specific board.
Sure. Depending on the deployment method for each site the configuration of the devices differ.
For example when you do a trial deployment it is pretty normal to have every device configured individually by the administration. In normal operation the devices operate using DHCP/TFTP for obtaining their settings. In both of these modes password are honoured, and the booting of the kernel is immediate
Developers in the other hand are working in a
different level and like access to everything including to be able to do a full factory-type resetting of the paramers.
Quoted 1 line
Think of it as simplified run-levels.
OK, but which of this part needs new or modified code? All this can be done with U-Boot as is now.
Quoted 4 lines
Quoted 2 lines
How good is your German? Can you parse board/lwmon/README.keybd ?
My German is not existant unfortunately, but I'll pass it to a collegue who is fluent.
Thanks. I guess I should provide an Engish version one day, too. But so far, all our customers who used features like that are from Germany, and insisted on German docs.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
o Cisco router like command interface with history and command completion.
But please do not try to add readline support - the readline lib is way too big...
No it is not like readline. It is much more light-weight, the current version
weighs in at about 12k.
Light-weight? Ummm... that's about 10 times (or more) the size of the existing command line parser.
Quoted 2 lines
DNS lookup capability. Yes I know that it is strange but actually some DHCP options can return hostnames so it is needed.
Really? Which one? (Which RFC?)
Quoted 2 lines
Wolfgang you are free to veto anything that you deem unacceptable; the best I can do is to present my case for the inclusion of these features.
In general I follow the very simple principle that something which is beneficial to one ore more people without hurting others is good and will be added.
Best regards,
Wolfgang Denk
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Prediction is very difficult, especially of the future. - Niels Bohr
Quoted 19 lines · Wolfgang Denk
Dear Pantelis,
Quoted 6 lines · in message <[email protected]> you wrote:
Quoted 6 lines
Quoted 3 lines
o Two level access password support.
What do you mean with "two level"?
Quoted 8 lines
By two level I mean that when something is deployed normally there are two access
levels. One level is the user level, which is allowed to view settings and alter
very few parameters. The other level is the administrator level in which it is
permitted to do (almost) anything.
Quoted 8 lines
I cannot see a way to implement this without dramatically changing the functionality and code of U-Boot. You cannot easily restrict the user from - for example - overwriting certain environment variables without castrating him from the power of defining his own settings.
I feel when you need such a level of authentification then the boot loader is not the right environment for your task - use an OS.
We already use an OS. The problem is that the device's user/person who has physical access to it, is not supposed to be allowed to alter anything in the configuration; especially the network settings, since an error there will render the device unoperable.
Think access control on a router or something similar.
True, it's a problem on how to implement it cleanly. We'll see how that will
turn out. A first simple step will be to have a single password for entering the command mode.
Quoted 20 lines
Quoted 20 lines
Quoted 8 lines
Quoted 4 lines
o Different boot-modes.
Please explain. There already are different boot modes, with a lot of configuration options depending on the specific board.
Sure. Depending on the deployment method for each site the configuration of the devices differ.
For example when you do a trial deployment it is pretty normal to have every device configured individually by the administration. In normal operation the devices operate using DHCP/TFTP for obtaining their settings. In both of these modes password are honoured, and the booting of the kernel is immediate
Developers in the other hand are working in a
different level and like access to everything including to be able to do a full factory-type resetting of the paramers.
Quoted 6 lines
Quoted 2 lines
Think of it as simplified run-levels.
OK, but which of this part needs new or modified code? All this can be done with U-Boot as is now.
Almost nothing actually, it's just a method of managing the existing settings
by using a master switch.
Quoted 19 lines
Quoted 7 lines
Quoted 4 lines
How good is your German? Can you parse board/lwmon/README.keybd ?
My German is not existant unfortunately, but I'll pass it to a collegue who is fluent.
Thanks. I guess I should provide an Engish version one day, too. But so far, all our customers who used features like that are from Germany, and insisted on German docs.
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
o Cisco router like command interface with history and command completion.
But please do not try to add readline support - the readline lib is way too big...
Quoted 8 lines
Quoted 4 lines
No it is not like readline. It is much more light-weight, the current version
weighs in at about 12k.Light-weight? Ummm... that's about 10 times (or more) the size of the existing command line parser.
Oh well, it's pretty light weight for what it does ;)
Quoted 7 lines
Quoted 4 lines
DNS lookup capability. Yes I know that it is strange but actually some DHCP options can return hostnames so it is needed.
Really? Which one? (Which RFC?)
RFC2132
For example:
Option #66 TFTP Server Name
Option #69 SMTP Server Name
Option #70 POP3 Server Name
etc.
I know, only the first one is actually meaningful for a boot loader.
Quoted 4 lines
Quoted 3 lines
Wolfgang you are free to veto anything that you deem unacceptable; the best I can do is to present my case for the inclusion of these features.
Quoted 9 lines
In general I follow the very simple principle that something which is beneficial to one ore more people without hurting others is good and will be added.
Best regards,
Wolfgang Denk
I know, and I appreciate it.
Regards
Pantelis
Hi,
Quoted 5 lines · in message <[email protected]> you wrote:
We already use an OS. The problem is that the device's user/person who has physical access to it, is not supposed to be allowed to alter anything in the configuration; especially the network settings, since an error there will render the device unoperable.
In my opinion U-Boot is not the right user interface for such use, then. It is a monitor program / boot loader, the intention of which is to provide direct access to the hardware. And with direct access to the hardware you can easily work around security measures.
For example, will you disable memory dump/modify commands? Probably not, as they are very useful to the user. So what prevents a user from using "mm" or "mw" to directly modify the working copy of the environment variables in RAM?
I don't know what you want to do, but IMHO you can either prevent use of the U-Boot command line interface completely, or you will have to live with the fact that a user can do things he should not do.
"UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things." - Doug Gwyn
This applies for U-Boot, too.
Quoted 1 line
Think access control on a router or something similar.
Don't allow any access to the U-Boot user interface, then. Run a OS on top of it, and implement a web interface or something like that where the user actions can be controlled on a higher level.
Quoted 4 lines
True, it's a problem on how to implement it cleanly. We'll see how that will
turn out. A first simple step will be to have a single password for entering the command mode.
This has been available since long time ago. See "doc/README.autoboot".
A relatively unintrusive method couldbe to change the "repeatable" field in "struct cmd_tbl_s" into a "flags" field, where 'repeatable' is just one bit, and one (or more) other bit(s) are used to specify a "security" level, to prevent the command from being run if the security level does not match.
Quoted 3 lines
Almost nothing actually, it's just a method of managing the existing settings
by using a master switch.
I'm afraid this won't work as you expect. You will either render U-Boot useless, or add "security" which in fact is just window- dressing.
You allow execution of any some, but not all commands? Be careful, even simple commands can be used to do "critical" things.
I don't need "setenv" to modify the environment. "mm" or "mw" will do.
I don't need "saveenv" to store the settings. "cp" or "eeprom read", "mm" or "mw", "crc32" and "cp" or "eeprom write" will do.
How do you save ypour passwords? Unencrypted in the environment (as it is now the case) ? Guess how long I will need to find them!
You will add encryption? How will you manage passwords onthese boxen then, in case the password was lost? Ah, you will implement a secret master password? OK, I'll look it up in the source code. [And you, you MUST provide the full source code, this is GPL software.]
Sorry, but I really see no easy way to harden a box if you open the U-Boot command line interface to a customer. Change your design. Don't use a chainsaw for jigsaw work.
Best regards,
Wolfgang Denk
Signature · 6 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick- les Worth). Which is to say that Europeans call him by name, but Americans call him by value.
Quoted 25 lines · Wolfgang Denk
Hi,
Quoted 5 lines · in message <[email protected]> you wrote:
We already use an OS. The problem is that the device's user/person who has physical access to it, is not supposed to be allowed to alter anything in the configuration; especially the network settings, since an error there will render the device unoperable.
In my opinion U-Boot is not the right user interface for such use, then. It is a monitor program / boot loader, the intention of which is to provide direct access to the hardware. And with direct access to the hardware you can easily work around security measures.
For example, will you disable memory dump/modify commands? Probably not, as they are very useful to the user. So what prevents a user from using "mm" or "mw" to directly modify the working copy of the environment variables in RAM?
I don't know what you want to do, but IMHO you can either prevent use of the U-Boot command line interface completely, or you will have to live with the fact that a user can do things he should not do.
Quoted 7 lines
"UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things." - Doug GwynThis applies for U-Boot, too.
I believe there's a misunderstanding here. I'm not talking about having bulletproof security. A technical savy user which has physical access to the device will be able to do what ever he/she want.
I just want to prevent casual tampering with the device settings. This is not meant to keep something secret, but rather to keep support costs low.
The two level security is probably overkill, but a single level is necessary in my application.
Quoted 9 lines
Quoted 3 lines
Think access control on a router or something similar.
Don't allow any access to the U-Boot user interface, then. Run a OS on top of it, and implement a web interface or something like that where the user actions can be controlled on a higher level.
Unfortunately the administrator or the support technicians need this access sometimes for troubleshooting, when the web interface is not available because of faulty network settings, or some network topology change.
Quoted 9 lines
Quoted 6 lines
True, it's a problem on how to implement it cleanly. We'll see how that will
turn out. A first simple step will be to have a single password for entering the command mode.This has been available since long time ago. See "doc/README.autoboot".
I see nothing there about a password, and I'm aware of the autoboot feature.
Quoted 9 lines
A relatively unintrusive method couldbe to change the "repeatable" field in "struct
cmd_tbl_s" into a "flags" field, where 'repeatable' is just one bit, and one (or more) other bit(s) are used to specify a "security" level, to prevent the command from being run if the security level does not match.
Nice idea.
Quoted 18 lines
Quoted 5 lines
Almost nothing actually, it's just a method of managing the existing settings
by using a master switch.I'm afraid this won't work as you expect. You will either render U-Boot useless, or add "security" which in fact is just window- dressing.
You allow execution of any some, but not all commands? Be careful, even simple commands can be used to do "critical" things.
I don't need "setenv" to modify the environment. "mm" or "mw" will do.
I don't need "saveenv" to store the settings. "cp" or "eeprom read", "mm" or "mw", "crc32" and "cp" or "eeprom write" will do.
Quoted 9 lines
How do you save ypour passwords? Unencrypted in the environment (as it is now the case) ? Guess how long I will need to find them!
You will add encryption? How will you manage passwords onthese boxen then, in case the password was lost? Ah, you will implement a secret master password? OK, I'll look it up in the source code. [And you, you MUST provide the full source code, this is GPL software.]
The passwords will be stored encrypted.
There will be no master passwords. If the password is lost a button pressed during the boot sequence, or a key sequence will reset the device state to that after it left the factory. It is then up to the administrator to restore the device to functional status.
At a site the passwords are the same for each device. It's not like each device will have it's own different password.
And yes, the full source code will be provided.
Quoted 5 lines
Sorry, but I really see no easy way to harden a box if you open the U-Boot command line interface to a customer. Change your design. Don't use a chainsaw for jigsaw work.
I don't intent to do that. I am not striving for maximum security, just a way to prevent non determined people of messing with their device out of boredom.
Site security is a problem for the resident BOFH.
I just have to provide him/her with the tools to do their job.
Quoted 6 lines
Best regards,
Wolfgang Denk
Regards
Pantelis
Quoted 3 lines · In message <[email protected]> you wrote:
The two level security is probably overkill, but a single level is necessary in my application.
This is already avaiulable right now - it's a config option. You can configure U-Boot such that you need to know the password to be able to interrupt the autoboot procedure.
Quoted 7 lines
Quoted 4 lines
Don't allow any access to the U-Boot user interface, then. Run a OS on top of it, and implement a web interface or something like that where the user actions can be controlled on a higher level.
Unfortunately the administrator or the support technicians need this access sometimes for troubleshooting, when the web interface is not available because of faulty network settings, or some network topology change.
Then give your administrators as much trainung and documentation as is necessary to understand what they are doing, and to recover from bad settings. For example, you can provide a script image which sets the default parameters, and instruct your admins to "run defaults" when necessary. This "default settings script image" can even be made board-specific (if you use some automated mechanism to generate it).
There are so many options available right now - don;t implement new stuff when just combining existing solutions is sufficient.
Quoted 3 lines
Quoted 2 lines
This has been available since long time ago. See "doc/README.autoboot".
I see nothing there about a password, and I'm aware of the autoboot feature.
Read the description for the CONFIG_AUTOBOOT_KEYED config option combined with the CONFIG_AUTOBOOT_DELAY_STR config option and/or the bootdelaykey environment variable.
They name might be a bit strange, but bootdelaykey == password.
Quoted 7 lines
The passwords will be stored encrypted.
There will be no master passwords. If the password is lost a button pressed during the boot sequence, or a key sequence will reset the device state to that after it left the factory. It is then up to the administrator to restore the device to functional status.
If you have this reset option, then what's the problem at all with a dumb admin messing with the settings? Let him reset the box, and restore it to functional status.?
Quoted 2 lines
At a site the passwords are the same for each device. It's not like each device will have it's own different password.
Sounds like "security by obscurity" to me.
Quoted 3 lines
I don't intent to do that. I am not striving for maximum security, just a way to prevent non determined people of messing with their device out of boredom.
Then enable CONFIG_AUTOBOOT_KEYED in your consiguration (means add a simple password protection), and that's all. This will prevent most things at low (zero) cost.
Quoted 2 lines
Site security is a problem for the resident BOFH.
I just have to provide him/her with the tools to do their job.
Keep it simple, though.
Best regards,
Wolfgang Denk
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de "Deliver yesterday, code today, think tomorrow."
PATCH 1/1 ARTOS boot support for u-boot
In reply to Pantelis AntoniouDear Pantelis,
Quoted 5 lines · in message <[email protected]> you wrote:
The following patch against u-boot-0.3.0 adds support for booting ARTOS images
using u-boot. ARTOS is a custom in-house operating system in use by my company.
I will not add the patch for now, as it contains some severe problems:
Quoted 7 lines
(quoted diff) +7
-0+ /* + * Booting an ARTOS kernel image + application + */ + + /* place data at the top of memory */ + top = gd->bd->bi_memstart + gd->bd->bi_memsize; +
Review
Quoted 10 lines
(quoted diff) +10
-0+ /* first check the artos specific boot args, then the linux args*/ + if ((s = getenv("abootargs")) == NULL && (s = getenv("bootargs")) == NULL) + s = ""; + + /* get length of cmdline, and place it */ + len = strlen(s); + top = (top - (len + 1)) & ~0xF; + cmdline = (char *)top; + debug ("## cmdline at 0x%08lX ", top); + strcpy(cmdline, s);
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Review
Quoted 5 lines
(quoted diff) +5
-0+ /* copy bdinfo */ + top = (top - sizeof(bd_t)) & ~0xF; + debug ("## bd at 0x%08lX ", top); + kbd = (bd_t *)top; + memcpy(kbd, gd->bd, sizeof(bd_t));
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You cannot do that. U-Boot copies itself to the top of memory, so you are overwriting U-Boot's data here. It was pure luck if this wrked for you. but the behaviour is completely undefined.
Please implement this in a way that is compatible to U-Boot's memory map.
Also, since this is a proprietary OS with a very limited propagation I would like to ask to make the ARTOS boot code configurable, i. e. add a #define so it can enabled it in the board config file, but will not add to the code size for those systems that don't want it.
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de It seems intuitively obvious to me, which means that it might be wrong. -- Chris Torek
PATCH 1/1 ARTOS boot support for u-boot
Quoted 12 lines · Wolfgang Denk
Dear Pantelis,
Quoted 6 lines · in message <[email protected]> you wrote:
The following patch against u-boot-0.3.0 adds support for booting ARTOS images
using u-boot. ARTOS is a custom in-house operating system in use by my company.
Quoted 4 lines
I will not add the patch for now, as it contains some severe problems:
Correct.
Quoted 40 lines
Quoted 11 lines
(quoted diff) +7
-0+ /* + * Booting an ARTOS kernel image + application + */ + + /* place data at the top of memory */ + top = gd->bd->bi_memstart + gd->bd->bi_memsize; +Review
Quoted 10 lines
(quoted diff) +10
-0+ /* first check the artos specific boot args, then the linux args*/ + if ((s = getenv("abootargs")) == NULL && (s = getenv("bootargs")) == NULL) + s = ""; + + /* get length of cmdline, and place it */ + len = strlen(s); + top = (top - (len + 1)) & ~0xF; + cmdline = (char *)top; + debug ("## cmdline at 0x%08lX ", top); + strcpy(cmdline, s);^^^^^^^^^^^^^^^^^^^^^^^^^^^
Review
Quoted 7 lines
(quoted diff) +5
-0+ /* copy bdinfo */ + top = (top - sizeof(bd_t)) & ~0xF; + debug ("## bd at 0x%08lX ", top); + kbd = (bd_t *)top; + memcpy(kbd, gd->bd, sizeof(bd_t));^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You cannot do that. U-Boot copies itself to the top of memory, so you are overwriting U-Boot's data here. It was pure luck if this wrked for you. but the behaviour is completely undefined.
Please implement this in a way that is compatible to U-Boot's memory map.
Quoted 11 lines
Also, since this is a proprietary OS with a very limited propagation I would like to ask to make the ARTOS boot code configurable, i. e. add a #define so it can enabled it in the board config file, but will not add to the code size for those systems that don't want it.
Best regards,
Wolfgang Denk
Points addressed with this patch.
That it worked the first time was very lucky indeed.
Regards
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: u-boot-0.3.0-artos-v2.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20030421/097e7518/attachment.txt
PATCH 1/1 ARTOS boot support for u-boot
Dear Pantelis,
Quoted 4 lines · in message <[email protected]> you wrote:
Points addressed with this patch.
That it worked the first time was very lucky indeed.
Added to local tree. Will push to public CVS server soon.
Sorry it took so long.
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Philosophy is a game with objectives and no rules. Mathematics is a game with rules and no objectives.