Grant Likely wrote:
> On 7/3/07, Rune Torgersen <runet@...> wrote:
>>> I think it is a good idea to at least default to spitting out
>>> *something* on boot. Just in case RAM is hooped.
>> Console output before RAM is initialized is EXTREMELY important. I thin
>> on our boards, 90% of the output on boot is before RAM is initalized.
>> And when you try to bring up a new board, you definetly need it.
> Hmmm.... okay, so what does that output consist of? I can be
> convinced that pre-RAM output is necessary, but why is it 90%?
Maybe because the remaining 10% is really, really small? ;-)
One technique I've used in the past that has worked well is to output
successive characters at critical points in the code. (It became known
around here as "alphabet soup.") If the board stopped spitting out
characters prematurely, you have a clue what is wrong.
I also attempted to dump the registers on an error (test result
information being held in the registers). Depending on the error, this
might not be successful, but if it is successful, you can glean quite a
bit of information from the registers and what test was running at the
time of the failure.
* Still helpful identifying problems
* Minimal start up delay (generally don't have to wait for the UART
since you are throwing out single characters with tests in between)
* Only need a very simple character put routine (plus a slightly more
elaborate register dump if supported). In this concept, putchar()
is good, puts() is acceptable, and printf() is evil.
* Cryptic - need a secret decoder ring to figure out what test
was being run and what the registers are telling you.
* Depending on how cryptic the output is, it may be totally useless for
certain classes of misconfigurations
I would assert, with no proof to back that assertion, that most of the
current text output could be deferred to after RAM was initialized. For
instance, we don't really need to know what processor version and mask
before RAM is initialize, do we?
From Rune's email with my 0.02 cents interspersed ...
> U-Boot 1.1.4 (Apr 17 2007 - 13:30:37)
Defer to after RAM reloc
> MPC8260 Reset Status: External Soft, External Hard
Can be represented with a single character and a secret decoder ring
> MPC8260 Clock Configuration
> - Bus-to-Core Mult 4.5x, VCO Div 2, 60x Bus Freq 22-65 , Core Freq
> - dfbrg 0, corecnf 0x17, busdf 5, cpmdf 1, plldf 0, pllmf 5
> - vco_out 597196800, scc_clk 149299200, brg_clk 149299200
> - cpu_clk 447897600, cpm_clk 298598400, bus_clk 99532800
> - pci_clk 49766400
One or two of these may be useful, but even that is debatable.
* Some of these, if wrong, will cause complete board failure and the
above won't be printed anyway.
* Most can be deferred till after RAM reloc
> CPU: MPC8280 (HiP7 Rev 14, Mask 1.0 1K49M) at 447.897 MHz
> Board: Innovative Systems AP2, CPU1
> Build: $SvnTreeRevision: 89 $
Defer till after RAM reloc
> Watchdog enabled
> UPMs: Configured
> FPGA: (cfgaddr 0xff810000)............ Status = OK Altera ID: 0x110b
> I2C: ready
> DRAM: DIMM socket probe: Slot1 = 1, Slot2 =1
> SDRAM configuration read from SPD
> Size per side = 256MB
> Organization: 4 sides, 4 banks, 10 Columns, 13 Rows, Width = 64
> Refresh rate = 13, CAS latency = 2, Using Page Based interleave
> EAMUX = 0
> Total size: 1024 MB
This is very useful information and where I would expect most
misconfiguration failures to show up.
If RAM doesn't work and the "alphabet soup" identifies that RAM is where
things stopped working, manufacturing typically debugs these types of
problems by simply replacing the RAM DIMM regardless of how detailed
your printed information is. :-/
If RAM works enough (and it often does work enough), a summary could be
printed before relocation to RAM and full information printed after
> !!! Skipping Memtest (SkipMemtest env varable set) !!!
> Now running in RAM - U-Boot at: 0ff97000
We are running! Start spewing the detailed information!