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

[Wolfgang Denk]

In message <20070704093242.GI3361 at leda.ptxnet.pengutronix.de> you wrote:
>
> I don't understand what's so damn complicated about setting up SDRAM.

I could reply that I don't understand this either, but that would  be
simply  arrogant.  Just  go  back  through  the  U-Boot  mailing list
archives for some time and you will see  that  90%  or  more  of  the
fundamental  problems  where  U-Boot  is not running at all, or where
U-Boot or Linux are  crashing  randomly  are  caused  by  incorrectly
initialized memory and/or memory controllers.

> This is one of the most basic things during lowlevel development.

It may be basic, but it is still not trivial.

> Usually this part is about 20 lines in my bdi config. Transfering this
> into some lines Assembler or C code is a piece of cake. If you have to

This depends highly on which sort of processor and memory  controller
you are dealing with. Correctly setting up the memory controller even
on  a  CPU  as old and simple as the MPC8xx is something I definitely
don't want to do in assembler, and I bet  you  don't  either  if  you
tried.

> read some i2c data to get initialization settings, you have to do some
> bits more and I understand that one wants to have some putc/puthex to
> check if sane values are read. But again, this is lowlevel work and once
> it's running can forget about this.

Again, I disgree. We have  to  support  the  whole  lifetime  of  the
product,  from  board bring-up through field service. It makes a huge
difference whether a board simply sits there as a  brick  or  whether
you can see that it startedworking and stops at step N.

> All this has _nothing_ to do with production boards. Here the SDRAM
> initialization and relocation just work. If not, you're doomed anyway.

They may work,  or  they  may  not  work.  Board  break,  chips  die.
Supporting   the  field  service  guys  with  useful  diagnostics  is
important to me.

> At the moment (PPC-)U-Boot does 90% of the whole initialization while
> running from Flash. All these serial read functions for the environment
> are just a pain. Do you really want to do the same thing for the device
> tree? Setting up things in SRAM and then copy them to SDRAM, possibly
> with relocation fixups is a pain. Setting up a preliminary environment
> in flash and relocate this complex thing afterwards with all this
> global_data handling is what I would call complicated and error prone.

So what is your suggestion when it comes to the request of being able
to use exactly the same binary image of U-Boot on a set of differenty
configured boards? OK, some things might be dealt  with  by  probing,
but  there  will always be situations where probing doesn't work. For
example to find out if the attached LCD display is color or  b/w,  or
if  the  orientation  is  landscape  or portrait. We had a discussion
about this on IRC before, and there was kind of a consensus  that  it
makes sense to use the device tree for such run-time configuration.

Which solution do you suggest instead?


> Doing this is not a design criteria, it is one main design flaw in
> U-Boot. If you insist on doing it, we don't need to talk about a
> redesign, just leave everything like it is.

Come on.

> Note that in my tree there is one single entrypoint for all
> architectures, and the only thing needed to enter it is working RAM.

You have the big advantage of starting with a minimal set of  similar
boards in more or less trivial configuration. Things will become more
difficult if you add more boards and support for more features.

> This is straight forward: Everyone should be able to provide working
> RAM. If not, again you're doomed.

Agreed.

> If you need some debugging output to get to that point, well that's
> fine, but these are putc/puthex and _not_ printf. They are not compiled
> in in production code and therefore do not need quiet console checking.

Please try to accept that this is not only debug output, and that
early output if production systems is important.

> Don't make things more complicated as they are. The earlier you enter a
> common entry point in U-Boot the more you can actually trust the code,
> since from there on it's common for _all_ architectures and the code
> will be best reviewed.

Agreed.

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
Due to lack of disk space, this fortune database has been discontinued.