[U-Boot-Users] [PATCH] 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
diff -ruNb u-boot-0.3.0-orig/CREDITS u-boot-0.3.0/CREDITS --- u-boot-0.3.0-orig/CREDITS Wed Apr 16 10:56:20 2003 +++ u-boot-0.3.0/CREDITS Thu Apr 17 14:32:28 2003 @@ -286,3 +286,7 @@ E: azu@sysgo.de D: Overall improvements on StrongARM, ARM720TDMI; Support for Tuxscreen; initial PCMCIA support for ARM W: www.elinos.com + +N: Pantelis Antoniou +E: panto@intracom.gr +D: NETVIA board support, ARTOS support. diff -ruNb u-boot-0.3.0-orig/README u-boot-0.3.0/README --- u-boot-0.3.0-orig/README Wed Apr 16 10:56:20 2003 +++ u-boot-0.3.0/README Thu Apr 17 14:31:16 2003 @@ -343,7 +343,8 @@ CONFIG_GTH, CONFIG_RPXClassic, CONFIG_rsdproto, CONFIG_IAD210, CONFIG_RPXlite, CONFIG_sbc8260, CONFIG_EBONY, CONFIG_sacsng, CONFIG_FPS860L, - CONFIG_V37, CONFIG_ELPT860, CONFIG_CMI + CONFIG_V37, CONFIG_ELPT860, CONFIG_CMI, + CONFIG_NETVIA
ARM based boards: ----------------- @@ -1726,7 +1727,7 @@ FPS850L_config Sandpoint8240_config sbc8260_config GENIETV_config TQM823L_config PIP405_config GEN860T_config EBONY_config FPS860L_config - ELPT860_config cmi_mpc5xx_config + ELPT860_config cmi_mpc5xx_config NETVIA_config
Note: for some board special configuration names may exist; check if additional information is available from the board vendor; for @@ -2036,8 +2037,8 @@
* Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD, 4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, - LynxOS, pSOS, QNX; - Currently supported: Linux, NetBSD, VxWorks, QNX). + LynxOS, pSOS, QNX, ARTOS; + Currently supported: Linux, NetBSD, VxWorks, QNX, ARTOS). * Target CPU Architecture (Provisions for Alpha, ARM, Intel x86, IA64, MIPS, MIPS, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit; Currently supported: PowerPC). diff -ruNb u-boot-0.3.0-orig/common/cmd_bootm.c u-boot-0.3.0/common/cmd_bootm.c --- u-boot-0.3.0-orig/common/cmd_bootm.c Wed Apr 16 10:56:20 2003 +++ u-boot-0.3.0/common/cmd_bootm.c Wed Apr 16 13:24:15 2003 @@ -31,6 +31,7 @@ #include <image.h> #include <malloc.h> #include <zlib.h> +#include <environment.h> #include <asm/byteorder.h> #if (CONFIG_COMMANDS & CFG_CMD_DATE) || defined(CONFIG_TIMESTAMP) #include <rtc.h> @@ -104,6 +105,9 @@ int do_bootvx ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[] ); int do_bootelf (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[] ); #endif /* CFG_CMD_ELF */ +#ifdef CONFIG_PPC +static boot_os_Fcn do_bootm_artos; +#endif
image_header_t header;
@@ -326,6 +330,12 @@ addr, len_ptr, verify); break; #endif /* CFG_CMD_ELF */ +#ifdef CONFIG_PPC + case IH_OS_ARTOS: + do_bootm_artos (cmdtp, flag, argc, argv, + addr, len_ptr, verify); + break; +#endif }
SHOW_BOOT_PROGRESS (-9); @@ -705,6 +715,88 @@ (*loader) (gd->bd, img_addr, consdev, cmdline); }
+#ifdef CONFIG_PPC + +/* Function that returns a character from the environment */ +extern uchar (*env_get_char)(int); + +static void +do_bootm_artos (cmd_tbl_t *cmdtp, int flag, + int argc, char *argv[], + ulong addr, + ulong *len_ptr, + int verify) +{ + DECLARE_GLOBAL_DATA_PTR; + ulong top; + char *s, *cmdline; + char **fwenv, **ss; + int i, j, nxt, len, envno, envsz; + bd_t *kbd; + void (*entry)(bd_t *bd, char *cmdline, char **fwenv, ulong top); + image_header_t *hdr = &header; + + /* + * 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)); + + /* first find number of env entries, and their size */ + envno = 0; + envsz = 0; + for (i = 0; env_get_char(i) != '\0'; i = nxt + 1) { + for (nxt = i; env_get_char(nxt) != '\0'; ++nxt) + ; + envno++; + envsz += (nxt - i) + 1; /* plus trailing zero */ + } + envno++; /* plus the terminating zero */ + debug ("## %u envvars total size %u ", envno, envsz); + + top = (top - sizeof(char **)*envno) & ~0xF; + fwenv = (char **)top; + debug ("## fwenv at 0x%08lX ", top); + + top = (top - envsz) & ~0xF; + s = (char *)top; + ss = fwenv; + + /* now copy them */ + for (i = 0; env_get_char(i) != '\0'; i = nxt + 1) { + for (nxt = i; env_get_char(nxt) != '\0'; ++nxt) + ; + *ss++ = s; + for (j = i; j < nxt; ++j) + *s++ = env_get_char(j); + *s++ = '\0'; + } + *ss++ = NULL; /* terminate */ + + entry = (void (*)(bd_t *, char *, char **, ulong))ntohl(hdr->ih_ep); + (*entry)(kbd, cmdline, fwenv, top); +} +#endif + + #if (CONFIG_COMMANDS & CFG_CMD_BOOTD) int do_bootd (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) { @@ -826,6 +918,7 @@ case IH_OS_VXWORKS: os = "VxWorks"; break; case IH_OS_QNX: os = "QNX"; break; case IH_OS_U_BOOT: os = "U-Boot"; break; + case IH_OS_ARTOS: os = "ARTOS"; break; default: os = "Unknown OS"; break; }
diff -ruNb u-boot-0.3.0-orig/include/image.h u-boot-0.3.0/include/image.h --- u-boot-0.3.0-orig/include/image.h Wed Apr 16 10:56:20 2003 +++ u-boot-0.3.0/include/image.h Wed Apr 16 10:56:51 2003 @@ -45,6 +45,7 @@ #define IH_OS_PSOS 15 /* pSOS */ #define IH_OS_QNX 16 /* QNX */ #define IH_OS_U_BOOT 17 /* Firmware */ +#define IH_OS_ARTOS 18 /* ARTOS */
/* * CPU Architecture Codes (supported by Linux) diff -ruNb u-boot-0.3.0-orig/tools/mkimage.c u-boot-0.3.0/tools/mkimage.c --- u-boot-0.3.0-orig/tools/mkimage.c Wed Apr 16 10:56:20 2003 +++ u-boot-0.3.0/tools/mkimage.c Wed Apr 16 10:56:51 2003 @@ -92,6 +92,7 @@ { IH_OS_PSOS, "psos", "pSOS", }, { IH_OS_QNX, "qnx", "QNX", }, { IH_OS_U_BOOT, "u-boot", "U-Boot", }, + { IH_OS_ARTOS, "artos", "ARTOS", }, { -1, "", "", }, };
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
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
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
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
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
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
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
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
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
diff -ubrN u-boot-0.3.0-orig/CREDITS u-boot-0.3.0-artos/CREDITS --- u-boot-0.3.0-orig/CREDITS Mon Apr 21 10:10:04 2003 +++ u-boot-0.3.0-artos/CREDITS Mon Apr 21 09:58:36 2003 @@ -286,3 +286,7 @@ E: azu@sysgo.de D: Overall improvements on StrongARM, ARM720TDMI; Support for Tuxscreen; initial PCMCIA support for ARM W: www.elinos.com + +N: Pantelis Antoniou +E: panto@intracom.gr +D: NETVIA board support, ARTOS support. diff -ubrN u-boot-0.3.0-orig/README u-boot-0.3.0-artos/README --- u-boot-0.3.0-orig/README Mon Apr 21 10:10:04 2003 +++ u-boot-0.3.0-artos/README Mon Apr 21 09:58:36 2003 @@ -343,7 +343,8 @@ CONFIG_GTH, CONFIG_RPXClassic, CONFIG_rsdproto, CONFIG_IAD210, CONFIG_RPXlite, CONFIG_sbc8260, CONFIG_EBONY, CONFIG_sacsng, CONFIG_FPS860L, - CONFIG_V37, CONFIG_ELPT860, CONFIG_CMI + CONFIG_V37, CONFIG_ELPT860, CONFIG_CMI, + CONFIG_NETVIA
ARM based boards: ----------------- @@ -1726,7 +1727,7 @@ FPS850L_config Sandpoint8240_config sbc8260_config GENIETV_config TQM823L_config PIP405_config GEN860T_config EBONY_config FPS860L_config - ELPT860_config cmi_mpc5xx_config + ELPT860_config cmi_mpc5xx_config NETVIA_config
Note: for some board special configuration names may exist; check if additional information is available from the board vendor; for @@ -2036,8 +2037,8 @@
* Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD, 4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, - LynxOS, pSOS, QNX; - Currently supported: Linux, NetBSD, VxWorks, QNX). + LynxOS, pSOS, QNX, ARTOS; + Currently supported: Linux, NetBSD, VxWorks, QNX, ARTOS). * Target CPU Architecture (Provisions for Alpha, ARM, Intel x86, IA64, MIPS, MIPS, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit; Currently supported: PowerPC). diff -ubrN u-boot-0.3.0-orig/common/cmd_bootm.c u-boot-0.3.0-artos/common/cmd_bootm.c --- u-boot-0.3.0-orig/common/cmd_bootm.c Mon Apr 21 10:10:04 2003 +++ u-boot-0.3.0-artos/common/cmd_bootm.c Mon Apr 21 10:11:52 2003 @@ -31,6 +31,7 @@ #include <image.h> #include <malloc.h> #include <zlib.h> +#include <environment.h> #include <asm/byteorder.h> #if (CONFIG_COMMANDS & CFG_CMD_DATE) || defined(CONFIG_TIMESTAMP) #include <rtc.h> @@ -104,6 +105,9 @@ int do_bootvx ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[] ); int do_bootelf (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[] ); #endif /* CFG_CMD_ELF */ +#if defined(CONFIG_ARTOS) && defined(CONFIG_PPC) +static boot_os_Fcn do_bootm_artos; +#endif
image_header_t header;
@@ -326,6 +330,12 @@ addr, len_ptr, verify); break; #endif /* CFG_CMD_ELF */ +#ifdef CONFIG_ARTOS + case IH_OS_ARTOS: + do_bootm_artos (cmdtp, flag, argc, argv, + addr, len_ptr, verify); + break; +#endif }
SHOW_BOOT_PROGRESS (-9); @@ -705,6 +715,99 @@ (*loader) (gd->bd, img_addr, consdev, cmdline); }
+#if defined(CONFIG_ARTOS) && defined(CONFIG_PPC) + +/* Function that returns a character from the environment */ +extern uchar (*env_get_char)(int); + +static void +do_bootm_artos (cmd_tbl_t *cmdtp, int flag, + int argc, char *argv[], + ulong addr, + ulong *len_ptr, + int verify) +{ + DECLARE_GLOBAL_DATA_PTR; + ulong top; + char *s, *cmdline; + char **fwenv, **ss; + int i, j, nxt, len, envno, envsz; + bd_t *kbd; + void (*entry)(bd_t *bd, char *cmdline, char **fwenv, ulong top); + image_header_t *hdr = &header; + + /* + * Booting an ARTOS kernel image + application + */ + + /* this used to be the top of memory, but was wrong... */ +#ifdef CONFIG_PPC + /* get stack pointer */ + asm volatile ("mr %0,1" : "=r"(top) ); +#endif + debug ("## Current stack ends at 0x%08lX ", top); + + top -= 2048; /* just to be sure */ + if (top > CFG_BOOTMAPSZ) + top = CFG_BOOTMAPSZ; + top &= ~0xF; + + debug ("=> set upper limit to 0x%08lX\n", top); + + /* 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)); + + /* first find number of env entries, and their size */ + envno = 0; + envsz = 0; + for (i = 0; env_get_char(i) != '\0'; i = nxt + 1) { + for (nxt = i; env_get_char(nxt) != '\0'; ++nxt) + ; + envno++; + envsz += (nxt - i) + 1; /* plus trailing zero */ + } + envno++; /* plus the terminating zero */ + debug ("## %u envvars total size %u ", envno, envsz); + + top = (top - sizeof(char **)*envno) & ~0xF; + fwenv = (char **)top; + debug ("## fwenv at 0x%08lX ", top); + + top = (top - envsz) & ~0xF; + s = (char *)top; + ss = fwenv; + + /* now copy them */ + for (i = 0; env_get_char(i) != '\0'; i = nxt + 1) { + for (nxt = i; env_get_char(nxt) != '\0'; ++nxt) + ; + *ss++ = s; + for (j = i; j < nxt; ++j) + *s++ = env_get_char(j); + *s++ = '\0'; + } + *ss++ = NULL; /* terminate */ + + entry = (void (*)(bd_t *, char *, char **, ulong))ntohl(hdr->ih_ep); + (*entry)(kbd, cmdline, fwenv, top); +} +#endif + + #if (CONFIG_COMMANDS & CFG_CMD_BOOTD) int do_bootd (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) { @@ -826,6 +929,9 @@ case IH_OS_VXWORKS: os = "VxWorks"; break; case IH_OS_QNX: os = "QNX"; break; case IH_OS_U_BOOT: os = "U-Boot"; break; +#ifdef CONFIG_ARTOS + case IH_OS_ARTOS: os = "ARTOS"; break; +#endif default: os = "Unknown OS"; break; }
diff -ubrN u-boot-0.3.0-orig/include/configs/NETVIA.h u-boot-0.3.0-artos/include/configs/NETVIA.h --- u-boot-0.3.0-orig/include/configs/NETVIA.h Mon Apr 21 10:10:04 2003 +++ u-boot-0.3.0-artos/include/configs/NETVIA.h Mon Apr 21 10:04:14 2003 @@ -345,4 +345,6 @@ /* Ethernet at SCC2 */ #define CONFIG_SCC2_ENET
+#define CONFIG_ARTOS /* include ARTOS support */ + #endif /* __CONFIG_H */ diff -ubrN u-boot-0.3.0-orig/include/image.h u-boot-0.3.0-artos/include/image.h --- u-boot-0.3.0-orig/include/image.h Mon Apr 21 10:10:04 2003 +++ u-boot-0.3.0-artos/include/image.h Mon Apr 21 10:01:50 2003 @@ -45,6 +45,7 @@ #define IH_OS_PSOS 15 /* pSOS */ #define IH_OS_QNX 16 /* QNX */ #define IH_OS_U_BOOT 17 /* Firmware */ +#define IH_OS_ARTOS 18 /* ARTOS */
/* * CPU Architecture Codes (supported by Linux) diff -ubrN u-boot-0.3.0-orig/tools/mkimage.c u-boot-0.3.0-artos/tools/mkimage.c --- u-boot-0.3.0-orig/tools/mkimage.c Mon Apr 21 10:10:04 2003 +++ u-boot-0.3.0-artos/tools/mkimage.c Mon Apr 21 10:10:50 2003 @@ -92,6 +92,7 @@ { IH_OS_PSOS, "psos", "pSOS", }, { IH_OS_QNX, "qnx", "QNX", }, { IH_OS_U_BOOT, "u-boot", "U-Boot", }, + { IH_OS_ARTOS, "artos", "ARTOS", }, { -1, "", "", }, };
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
participants (2)
-
Pantelis Antoniou -
Wolfgang Denk