On Thursday 16 July 2009 22:08:27 Matthias Fuchs wrote:
OK. But if your "sbe" command is "better" than the current bootstrap one, then let's see if it makes sense to use your command as the common one.
Dirk's approach is very generic. Putting nothing but the EEPROM data and a descriptive table into the board file is what we need.
I'm aware of this, since I suggested to Dirk to implement it this way. ;)
I only suggest to add an additional label to each entry that is used instead of using numbers and I'd to pass this label as argument instead of the a number. One could use the numbers as labels also :-)
Ack.
When you do no pass the argument we could either print the descriptive texts as menu (as DIrk did so far) and wait for input or just print the texts as kind of help and the must supply an argument if he want to change something (I prefer the latter).
Yes, just printing all available config options when called without parameter is what I prefer as well. Something like this:
=> 4xx_config (or 4xx_bootstrap) Available configurations: Name CPU PLB OPB EBC Boot-Location 1 333 133 66 66 NOR 2 333 133 66 66 NAND 3 333 133 66 66 PCI 4 400 133 66 66 NOR 5 400 133 66 66 NAND 6 400 160 80 53 NOR ...
The board maintainer could of course use real "names" instead of the numbers here.
Does you command support more features? What's the main difference?
Much simpler. Just call sbe with a descriptive argument like a CPU frequency or something like '667-66' on a 440EPx target with 66Mhz PCI clock or 'sr-test-only' for something you will remove later :-). This has two advantages over just using numbers: You can remove configurations without making the following configs in the table moving to the front and its a little more secure meaning you have to type a couple of valid character to reconfigure the clocking. Just using "bootstrap 5" is error-prone.
Ack.
Well, I like my syntax and behavior, but I do not want to totally dismiss Dirk's idea as long as I can keep my sbe command :-)
Seems that "your" command is not so bad. ;) I'll take a look at it tomorrow. Perhaps we can use some of your ideas in such a new common (PPC4xx) implementation. :)
My implementation is nothing but ar if-!strcmp-else-if-!strcmp implementation. But putting things together is a good idea.
Yes, the implementation itself is non-optimal. I'll send an updated version of Dirk's patch with the "new" user interface and a new command-naming (hopefully) today.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================