From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefan Roese <sr@denx.de>
Date: Wed, 4 Jul 2007 14:49:44 +0200
Subject: [U-Boot-Users] U-Boot-NG ?
In-Reply-To: <20070704122101.GO25364@pengutronix.de>
References: <20070703175856.GB8839@pengutronix.de>
	<200707041356.32051.sr@denx.de>
	<20070704122101.GO25364@pengutronix.de>
Message-ID: <200707041449.44185.sr@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Robert,

On Wednesday 04 July 2007, Robert Schwebel wrote:
> > I'm still a little undecided, if a "simple" output mechanism is
> > enough. Of course you can life with a hardwired baudrate on most
> > systems, so that you don't have to read the environment. But there
> > will be some systems where the user configured a different baudrate
> > and the outputs from the DDR2 init routine will not be readable.
>
> Let's look at the PC architecture, which is really supposed to be
> customized by dummy users. It just makes BEEEP if the memory init goes
> wrong. People designed it this way on purpose. I know that there are
> brain damaged hardware designs in the industry, but please don't let us
> make strategic design decisions based on crappy hardware instead of the
> 95% case. I recognize that it is a good feature for these cases, but
> it's not a good excuse for transferring a straight forward, simple and
> maintainable design into a can of worms.

AFAIK the PC at least supports some kind of beep morse code to differentiate 
between different error sources.

> > If no output on the serial console always means: "problem with
> > memory", than this would be an easy indication for SDRAM problems. But
> > I have seen lots of other errors, that lead to a hangup in the very
> > early boot stage. Most of the time *before* SDRAM is initialized.
>
> Because lots of things are done before the SDRAM is initialized. All
> these would be done later in our design and thus would have access to
> the console.

You're only partly right here. On some platforms there has to happen quite a 
lot before you can begin with the SDRAM setup. Something like TLB setup, 
GPIO-setup, I2C setup comes to my mind right now.

> > Don't get me wrong. I generally like this 2 stage approach. For
> > example it fits the NAND booting support (see nand_spl/*) where a
> > small (4k on 4xx) first stage loader is needed. I'm just a little
> > hesitant about dropping the full featured printf in early boot stages.
>
> I assume the way we do the discussion now is really right - we throw in
> "it can be soooooo easy" ideas, you tell us the corner cases and then we
> iterate until everybody is happy :-)

Yes. Let's continue this way... :-)

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================