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

[Sascha Hauer]

On Wed, Jul 04, 2007 at 03:34:45PM +0200, Wolfgang Denk wrote:
> 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.

Ack

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

Well, after passing the common entry point you are free to do what you
want. You can read the device tree then, register devices according to
it, whatever. Before passing this entry point you cannot. It's not
portable. 

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

I know that things will get more difficult. This is a reason more why
should strictly draw a line between a stage 1 (no sdram, no printf, no
environment) and a fully sophisticated stage 2.

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

I do. How about this?
Specify _one_ early console. hardcoded port, hardcoded baudrate. This is
used for early output and - if requested - for debugging purposes. Delay
all the rest after passing the common entry point.
There is only one thing we had to tell customers: Either you want early
console in which case you cannot connect a modem/other fancy device to
this port, or you do not want early console, in which case you are blind
when the board does not start.

Regards,
  Sascha

-- 
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord     http://www.pengutronix.de