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

Jerry Van Baren gerald.vanbaren at smiths-aerospace.com
Tue Jul 3 21:19:33 CEST 2007


Grant Likely wrote:
> On 7/3/07, Rune Torgersen <runet at 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 = 64
> bits
>         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




More information about the U-Boot mailing list