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

Wolfgang Denk
2007-07-04T13:34:45Z

In message <20070704093242.GI3361@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.