[U-Boot-Users] [PATCH] ARTOS boot support for u-boot

[U-Boot-Users] [PATCH] ARTOS boot support for u-boot

[Pantelis Antoniou]

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 

[U-Boot-Users] Re: [PATCH] ARTOS boot support for u-boot

[Wolfgang Denk]

Dear Pantelis,

in message <3E9E9B5C.30904@intracom.gr> 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.

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

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

> o Two level access password support.

What do you mean with "two level"?

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

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

> o UDP-based same-LAN terminal access.

OK.

> o Factory testing framework.

Please see the existing POST code.

> o More DHCP parameters support.

Which ones are you missing?

> o CDP support.

CDP = Cisco Discovery Protocol? 

> o DHCP lease time information passed to the loaded kernel.

OK.

> 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

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

[U-Boot-Users] Re: [PATCH] ARTOS boot support for u-boot

[Pantelis Antoniou]

Wolfgang Denk wrote:

>Dear Pantelis,
>
>in message <3E9E9B5C.30904@intracom.gr> 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.
>
No, thank you...

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

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

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

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

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

>
>>o UDP-based same-LAN terminal access.
>>
>
>OK.
>
>
>>o Factory testing framework.
>>
>
>Please see the existing POST code.
>
Thanks, I'll check it.

>
>>o More DHCP parameters support.
>>
>
>Which ones are you missing?
>
Some VoIP specific, and some Cisco specific ones.

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

>
>>o DHCP lease time information passed to the loaded kernel.
>>
>
>OK.
>
>
>>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
>
>
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

[U-Boot-Users] Re: [PATCH] ARTOS boot support for u-boot

[Wolfgang Denk]

Dear Pantelis,

in message <3E9EBB5B.4030609@intracom.gr> you wrote:
> 
> >>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.

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.

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

OK, but which of this part needs new or modified code? All  this  can
be done with U-Boot as is now.

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

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

> 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?)

> 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

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

[U-Boot-Users] Re: [PATCH] ARTOS boot support for u-boot

[Pantelis Antoniou]

Wolfgang Denk wrote:

>Dear Pantelis,
>
>in message <3E9EBB5B.4030609@intracom.gr> you wrote:
>
>>>>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.
>>
>
>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.

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

>
>>>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.
>
>
>>>>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.
>
Oh well, it's pretty light weight for what it does ;)

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

>>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
>
>
I know, and I appreciate it.

Regards

Pantelis

[U-Boot-Users] Re: [PATCH] ARTOS boot support for u-boot

[Wolfgang Denk]

Hi,

in message <3E9FA26F.3000906@intracom.gr> 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.


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


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


> 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

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

[U-Boot-Users] Re: [PATCH] ARTOS boot support for u-boot

[Pantelis Antoniou]

Wolfgang Denk wrote:

>Hi,
>
>in message <3E9FA26F.3000906@intracom.gr> 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.
>
>
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.

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

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

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

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

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

>
>Best regards,
>
>Wolfgang Denk
>
>
Regards

Pantelis

[U-Boot-Users] Re: [PATCH] ARTOS boot support for u-boot

[Wolfgang Denk]

In message <3E9FD3EE.4090402@intracom.gr> 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.

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

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

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


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

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

> 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

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

[U-Boot-Users] [PATCH] ARTOS boot support for u-boot

[Wolfgang Denk]

Dear Pantelis,

in message <3E9E9B5C.30904@intracom.gr> 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:

> +	/*
> +	 * Booting an ARTOS kernel image + application
> +	 */
> +
> +	/* place data at the top of memory */
> +	top = gd->bd->bi_memstart + gd->bd->bi_memsize;
> +
> +	/* 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);
^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +	/* 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

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

[U-Boot-Users] [PATCH] ARTOS boot support for u-boot

[Pantelis Antoniou]

Wolfgang Denk wrote:

>Dear Pantelis,
>
>in message <3E9E9B5C.30904@intracom.gr> 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:
>  
>
Correct.

>  
>
>>+	/*
>>+	 * Booting an ARTOS kernel image + application
>>+	 */
>>+
>>+	/* place data at the top of memory */
>>+	top = gd->bd->bi_memstart + gd->bd->bi_memsize;
>>+
>>+	/* 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);
>>    
>>
>^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  
>
>>+	/* 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
>
>  
>
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 

[U-Boot-Users] [PATCH] ARTOS boot support for u-boot

[Wolfgang Denk]

Dear Pantelis,

in message <3EA39F0C.2050509@intracom.gr> 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

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