[U-Boot-Users] Board/driver bragging list proposal
Hi Wolfgang and the rest of the Gang,
This is a good opportunity for me to trot out a thought I've been thinking for a while, but have not been able to put together as a cohesive proposal. It would be nice, and the new wiki makes it achievable, to have a feature list where people could identify what whas available and what they felt were the best features (and which implmentations should be steered clear of) which would serve as guidance for newcomers. Some of this information is in the README file, but it is hard to keep up to date and tends to not warn of lesser implmentations nor point out good implementation.
Before the wiki, it would have been impossible for one person (Wolfgang) to maintain.
With the wiki, it still may not work, because people may not contribute and there is a risk of people getting into "my implementation is better than your implementation" fights. Hopefully we are all smarter than that.
Another problem is organization: should we organize by processor and board (which is intuitive but not necessarily the best for looking up information) or by feature (flash type, ethernet interface type, SDRAM type, etc.), or by both? Probably both of the above :-/.
Perhaps we can start a wiki documentation branch by having each board maintainer make an entry for their board in a list, branching to a short description of the board and a list of the features. The list of features could then branch to a description of that feature, many of which would be shared by several boards as they use the same driver.
This is a crude diagram of what I'm thinking...
board1 --> CPU: MPC8260 Flash AMDxxxx ----> AMDxxxx flash driver description (shared with board 1,3) SDRAM ------------> SDRAM support (fixed type, no auto config) FCC ethernet -----> FCC ethernet driver description (shared with board 1,2,3)
board2 --> CPU: MPC8260 Flash Intelxxxx --> Intelxxxx flash driver description SDRAM ------------> SDRAM support (e.g. DIMM with auto config) (shared with board 2,3) FCC ethernet -----> FCC ethernet driver description (shared with board 1,2,3)
board3 --> CPU: MPC8260 Flash AMDxxxx ----> AMDxxxx flash driver description (shared with board 1,3) SDRAM ------------> SDRAM support (e.g. DIMM with auto config) (shared with board 2,3) FCC ethernet -----> FCC ethernet driver description (shared with board 1,2,3)
Then, for instance, if a legacy board does a poor job of implementing a feature (I'm thinking of the 8245 Sandpoint implementation of I2C, for instance), whoever enters the information or whoever gets burned by it later could enter a warning note for future reference. Likewise, if a board does something New and Improved and Better than Sliced Bread, the proud implementer could enter brag a bit (and potentially be "modded down" by others in the future :-).
There currently is a board selection box in the DULG wiki http://www.denx.de/twiki/bin/view/DULG/BoardSelect but it only has two boards listed and displays the Denx documentation, not really what I have in mind. Also, I am thinking more of a whole page list of boards so the user can see all of them (preferably with a feature summary) at once to give him more of a clue where to start.
Once some basic driver information is in, we could also make a top level driver index page, pointing to the drivers so a user could directly look up (all) then AMDxxxx flash drivers, for instance.
Now the problem is, I'm not that familiar with the Denx wiki (sorry, Wolfgang, I just haven't had the time to crawl through it) so I don't know if I'm proposing something that already exists. If it doesn't exist, I don't know the best place to splice in my proposal. Also, the proposal will only be successful if most or all the board supporters kick in some effort.
gvb
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Thursday, November 06, 2003 6:35 AM To: Richard Klingler Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] current simple 8260 platform as start...
Dear Richard,
in message 20031106104512.A52892263@joshua.klingler.net you wrote:
All boards use SDRAM, Flash, and Ethernet. Either you
chose a board
randomly, or you must be more specific.
I'll try (o;
- 4 * MT48LC4M16A2 SDRAM
bus width?
- CF interface
How implemented?
- SO-DIMM interface
- BCM6020 DSL
- PCMCIA option
How implemented?
So you do have a couple of "fancy periphals".
Sorry, but it is not that easy to recommend a specific board without precise knowledge of your hardware. Even if you sent me the schematics (which I would need) I wouldn't have the time (for free) to dig into 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@denx.de An expert is a person who avoids the small errors while sweeping on to the grand fallacy.
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************
Hi,
in message 8039970AF146314597457D3B51A68B382E0429@cossmgmbx02.email.corp.tld you wrote:
This is a good opportunity for me to trot out a thought I've been thinking
Actually it is not. You are a couple of weeks early.
Now I have to explain a few ideas in the public which I rather had more time to think about internally.
for a while, but have not been able to put together as a cohesive proposal. It would be nice, and the new wiki makes it achievable, to have a feature list where people could identify what whas available and what they felt were the best features (and which implmentations should be steered clear of) which would serve as guidance for newcomers. Some of this information is in the README file, but it is hard to keep up to date and tends to not warn of lesser implmentations nor point out good implementation.
I agree.
Before the wiki, it would have been impossible for one person (Wolfgang) to maintain.
With the wiki, it still may not work, because people may not contribute and there is a risk of people getting into "my implementation is better than your implementation" fights. Hopefully we are all smarter than that.
When we decided to use a wiki it was one of our intentions to allow board maintainers to take care about the documentation for their own boards.
Another problem is organization: should we organize by processor and board (which is intuitive but not necessarily the best for looking up information) or by feature (flash type, ethernet interface type, SDRAM type, etc.), or by both? Probably both of the above :-/.
The setup as is now is organized by boards. This may be non perfect in all situations, but I am convinced that everything else would be worse.
Perhaps we can start a wiki documentation branch by having each board maintainer make an entry for their board in a list, branching to a short description of the board and a list of the features. The list of features could then branch to a description of that feature, many of which would be shared by several boards as they use the same driver.
Please wait a bit.
There currently is a board selection box in the DULG wiki http://www.denx.de/twiki/bin/view/DULG/BoardSelect but it only has two boards listed and displays the Denx documentation, not really what I have in mind. Also, I am thinking more of a whole page list
Wait, wait, wait.
What you may have missed, and what is not directly obvious, is the fact that this "DENX documentation" actually uses a constant text framework (which is augmented with a lot of conditional text modules) and a set of include files. The include files contain for example all the examples in the document. These include files are automatically generated when we run our regression tests for U-Boot.
The idea is: you build a new version of U-Boot, you run the regression test suite, which not only tells you if the new version is working OK, but which also automagically creates a new version of the documentation which matches EXACTLY the code that has been running on your board...
The problem at the moment is that our regression test suite (a set of TCL / expect scripts) is not in a state which I would like to proesent to the public; also it is much too painful to add support for new boards.
We are working on a better solution.
Once this is ready, everybody (not only a board maintainer, but really _everybody_ who cares) will be able to set up and run the regression tests for his own board, and (if he wants) submit the test results to the wiki.
This would allow for a lot of nice features:
* You will be able to see which version of U-Boot was the last one running successfully on a specific board.
* Problems in a specific implementation will show up more easily - we have a pretty well-equipped test lab, but we cannot nor do we want to test on all existing boards ;-)
...
You may also have noticed that we took over maintenance for the orphaned Embedded PowerPC HOWTO file. It has been converted into a wiki, too. I can easily imagine to merge both resources into a more general document. I can imagine to give hardware vendors an easy way to enter their U-Boot / Linux capable hardware into this documentation system. Of course maintainers of code (U-Boot, Linux, additional packages, ...) could enter their information there, too.
Now the problem is, I'm not that familiar with the Denx wiki (sorry, Wolfgang, I just haven't had the time to crawl through it) so I don't know if I'm proposing something that already exists. If it doesn't exist, I
Nothing exists in a working state, but we have some plans that target into a very similar direction.
don't know the best place to splice in my proposal. Also, the proposal will only be successful if most or all the board supporters kick in some effort.
Actually no. My idea is to provide an easy mechanism so that every- body who cares can contribute, and those who don't want just don't. If somebody checks and sees that board XXX has been verified to run the latest version of U-boot just a couple of days ago, while the last successful test of board YYY is 2 years old, and test resutls for board ZZZ have never been submittet at all this too gives some valuable information about the quality of community support for these boards.
Arghhh... Sorry, I probably missed many things we have been discussing internally. Detlev, maybe you can fill in some more of this?
In any case - these are just ideas. Some of this is under work actually, but please do not expect to see something ripe for distribution soon.
Best regards,
Wolfgang Denk
I like this proposal: the information I'm looking for is along the lines of "we have new hardware using CPU X, Flash Y and Ethernet Z". What code should we copy & modify? It's not just what boards support X, Y, Z: that information is availble by using find/grep. It's what boards do things the "right" way, and which ones are older/hackier/more hardcoded.
Bryan
Good evening (o;
I choosed the "atc" platform (o;
Needs some flash adjustments though... At least for the first compilation try not bad:
U-Boot 1.0.0 (Nov 7 2003 - 14:20:49)
MPC8260 Reset Status: External Soft, External Hard
MPC8260 Clock Configuration - Bus-to-Core Mult 2.5x, VCO Div 2, 60x Bus Freq 40-120, Core Freq 100-240 - dfbrg 0, corecnf 0x06, busdf 3, cpmdf 1, plldf 0, pllmf 1 - vco_out 200000000, scc_clk 50000000, brg_clk 50000000 - cpu_clk 125000000, cpm_clk 100000000, bus_clk 50000000
CPU: MPC8260 (HiP3 Rev 01, Mask A.1 1K22A-XC) at 125 MHz Board: VDSL-OR1 DRAM: 32 MB Top of RAM usable for U-Boot at: 02000000 Reserving 154k for U-Boot at: 01fd9000 Reserving 128k for malloc() at: 01fb9000 Reserving 76 Bytes for Board Info at: 01fb8fb4 Reserving 72 Bytes for Global Data at: 01fb8f6c Stack Pointer at: 01fb8f48 New Stack Pointer is: 01fb8f48 Now running in RAM - U-Boot at: 01fd9000 FLASH: ## Unknown FLASH on Bank 0 - Size = 0x00000000 0 kB In: serial Out: serial Err: serial U-Boot relocated to 01fd9000 Net: FCC2 ETHERNET ### main_loop entered: bootdelay=5
### main_loop: bootcmd="version;echo;bootp;setenv bootargs root=/dev/nfs rw nfsroot=$(serverip):$(rootpa th) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname)::off;bootm" Hit any key to stop autoboot: 0
nice weekend rick
In message <r02000200-1028-3C5058F7114211D887C400039387ACB6@[10.0.1.1]> you wrote:
Good evening (o;
Hello!
I choosed the "atc" platform (o;
Say thanks to Promess then :-)
Needs some flash adjustments though... At least for the first compilation try not bad:
...
Hit any key to stop autoboot: 0
Ummm... ahh... be VERY careful. There must be some VERY, VERY nasty bug somewhere if a board boots that far on first try. It will raise it's ugly head later. It's just not normal to boot through all the init sequences on the first attempt. It never happens to me :-(
Best regards,
Wolfgang Denk
In message 1068217254.667.420.camel@boom you wrote:
I like this proposal: the information I'm looking for is along the lines of "we have new hardware using CPU X, Flash Y and Ethernet Z". What code should we copy & modify? It's not just what boards support X, Y, Z: that information is availble by using find/grep. It's what boards do things the "right" way, and which ones are older/hackier/more hardcoded.
Who is the judge? Who decides what is good and what not?
Do we install a committee to resolve conflicts?
Wolfgang Denk
participants (4)
-
Bryan Larsen -
Richard Klingler -
VanBaren, Gerald (AGRE) -
Wolfgang Denk