[U-Boot-Users] U-Boot-NG ?

[Wolfgang Denk]

Dear Robert,

in message <20070704184312.GI25364 at pengutronix.de> you wrote:
>
> You have a better overview than I - can you estimate how many of the
> platforms u-boot supports are "embedded system like", i.e. SoC cpu,
> soldered RAM & NAND/NOR flash, vs. "PC like", i.e.  you-need-to-initi-
> alize-the-north-and-southbridge-first-before-you-get-access-to-ttyS0?

In terms of board configurations most of them are "embedded" type. In
terms vof number of shipping systems the embedded ones outnumber  the
others by a really, really huge factor.

> We agree on the fact that it is a pretty good feature to have early
> debugging, even before anything else works. It's just that, at the
> moment, it has the implication that the whole inner mechanics of u-boot
> cannot follow a simple device model, as proposed by our v2 code.

I wouldn't go as far as to say that. Maybe if  the  one-size-fits-all
approach  does not work (at least not without hurting), then there is
still potential for a _compatible_  second  approach?  Who  says  the
"first  step"  *must*  be  as  small  as  4  kB,  and  *must* be in a
separately linked image, and *must* not link higher  level  functions
from  the  "real"  U-Boot?  Maybe  both is possible, so everybody can
select the config he likes and be happy?

The thing is that there are many requirements which are pretty
complicated and sometimes contradicting:

- systems booting from NAND or dataflash etc. may require a very small
  primary bootstrap loader
- systems with very limited resources may need a primary bootstrap
  loader that unpacks the compressed U-Boot image
- dynamic switching of the console device may require early access to
  the device tree
- allowing for a configurable console baudrate or for software-
  adjustable CPU clock rates may require early access to the
  environment
etc. etc.

What I would like to acchieve is an open  discussion  where  none  of
these  requirements  gets  excluded just because it does not fit into
the currently preferred design model. Until a few  days  ago  we  had
only  one  code  base  to  complain  about.  Now  - thanks to Saschas
excellent work - we have two different implementations which  we  can
compare.  This  is an excellent chance to evaluate positions, to find
out what's good in one design  or  the  other,  and  what  should  be
avoided.

If any feature is possible in the old design but leads to ugly code or
other issues, we should not simply drop it, but instead discuss how it
could be adapted for the other esign based on clean and beautiful (TM)
code.


> the next days and Sascha can show you some of the goodies. The longer
> one plays with the code, the more one gets the impression that it is
> simply plain elegant. It just makes POFF! and most of the spagetti code

I agree with that. And as far as I remember the previous discussion,
nobody ever raised any concerns or whatever.

> It would be a pita if the whole design wouldn't work just because of
> this early printk issue. So I hope we find a solution anybody can live
> with.

Agreed. The printf() thingy is just a problem that needs a  solution,
it  is  not  a  killing  point. It is not the only one - as mentioned
above, there are other things which I see difficult to  implement  in
the new code, not to mention the huge effort that will be needed just
to port a small fraction of the currently actively used boards. But it
wouldn't be software if all was easy and just working ;-)

> > Define "corner case".
> 
> Use cases which obviously never happened here but seem to be common to
> you. 

Please note that what you seem to  consider  corner  cases  are  real
problems  for some of our customers. And I have seen more than enough
casesmyself when a board stopped after printing "RAM: " (very often!)
or "Flash: " (still quie frequently). Please blieve me that  I  don't
want  to  discuss  this  to deat by raising artifical arguments. I am
serious.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Veni, Vidi, VISA:
        I came, I saw, I did a little shopping.