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