Grant Likely wrote:
On 7/3/07, Rune Torgersen runet@innovsys.com 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%?
g.
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.
Advantages: * 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.
Disadvantages: * 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
100-300
- 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
Single character
UPMs: Configured
Single character
FPGA: (cfgaddr 0xff810000)............ Status = OK Altera ID: 0x110b
Single character
I2C: ready
Single character
DRAM: DIMM socket probe: Slot1 = 1, Slot2 =1
Single character
SDRAM configuration read from SPD
Single character
Size per side = 256MB Organization: 4 sides, 4 banks, 10 Columns, 13 Rows, Width = 64bits 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 relocation.
!!! Skipping Memtest (SkipMemtest env varable set) !!!
Single character
Now running in RAM - U-Boot at: 0ff97000
We are running! Start spewing the detailed information!
Best regards, gvb