[U-Boot-Users] Board/driver bragging list proposal

[U-Boot-Users] Board/driver bragging list proposal

[VanBaren, Gerald]

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 at denx.de]
> Sent: Thursday, November 06, 2003 6:35 AM
> To: Richard Klingler
> Cc: u-boot-users at 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 at 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 at 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.
******************************************

[U-Boot-Users] Board/driver bragging list proposal

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"The question of whether a computer can think is no more  interesting
than the question of whether a submarine can swim"
                                                - Edsgar W.  Dijkstra

[U-Boot-Users] Board/driver bragging list proposal

[Bryan Larsen]

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

[U-Boot-Users] Board/driver bragging list proposal

[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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Newer disks don't have a rectangular layout anymore,  but  Unix  (and
SunOS) still assumes this.     - Peter Koch in <koch.779356598@rhein>

[U-Boot-Users] Board/driver bragging list proposal

[VanBaren, Gerald]

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de]
> Sent: Friday, November 07, 2003 1:58 PM
> To: Bryan Larsen
> Cc: VanBaren, Gerald (AGRE); u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] Board/driver bragging list proposal 
> 
> 
> 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
 
Well, the wiki premise is that /everybody/ is the judge and the wiki will settle down with the proper answer.  That is taking quite a lot on faith, especially with something that is pretty subjective and is subject to a lot of ownership-pride.  That is what I was alluding to when I wrote:
  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.

gvb

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