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

[Robert Schwebel]

On Wed, Jul 04, 2007 at 09:36:55PM +0200, Wolfgang Denk wrote:
> 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?

v2 was designed in a way to make exactly that choice possible, in a
quite flexible way.

> 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

Should be no problem with Sascha's design.

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

These ones are problematic.

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

That's the idea, yes.

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

Yep, agreed. Please go ahead and make suggestions.

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

Yes, we noticed. So either nobody read the code, or it must be really
good :-)

> Agreed. The printf() thingy is just a problem that needs a  solution,
> it  is  not  a  killing  point.

Could you elaborate on how these pluggable-ram boards are used in real
life? For all of our boards it would surely be enough to have a compile
time switch which declares one of the serial ports the early-debug
console, plus hardcode a baudrate on it. That would be configurable, so
somebody who wants to have it switched on in a production system has the
choice, and someone who doesn't need it because a shipped board is never
changing again could configure it off.

> It is not the only one - as mentioned
> above, there are other things which I see difficult to  implement  in
> the new code,

Let's identify the problematic cases. At the moment I see these:

- pluggable memory -> should be fixable by more intelligent ram probing
  code

- debug-output-before-sdram

- debug-output-before-sdram-on-console-taken-from-$COMPLICATED_DEVICE

> 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 ;-)

Well, that's easy. Everybody who wants to have his board supported in v2
just sends a patch. Everybody who doesn't care, does not, and it doesn't
matter, because if he does not care, why should the community do the
work instead? v1 would still be available for reference, if somebody
decides later to go the v2 way.

> Please note that what you seem to  consider  corner  cases  are  real
> problems  for some of our customers.

Well, I learned that one of the most important things in this business
is to tell customers that if they do braindamaged decisions, it has
implications. So if somebody designs a board with pluggable ram but
without beeper, it could have the implication that one doesn't see
anything. If a board can only initialize it's RAM without loading an
FPGA from software, it's doomed anyway. My very personal decision is
that there are projects out there who are so painful that it's probably
better if somebody else does them, because I don't want to let my team
feel the pain and I don't want to leave the customer with the bad
feeling that we didn't do a high quality solution for him.

But I surely understand your argument.

Note that, if these special cases are really rare, there's also the
possibility that, for features where there's no good solution, the
people continue to use v1.

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

Sorry, our experience is different.

Ok, so let's stop the discussion here, I assume I've understood your
arguments. Please let's continue with the "problematic cases" list above
and try to find solutions.

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9