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