From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Tue, 03 Jul 2007 15:19:33 -0400 Subject: [U-Boot-Users] U-Boot-NG ? In-Reply-To: References: <20070630020850.22A711B2CB9@mercury.denx.de> <20070702164755.GC3361@leda.ptxnet.pengutronix.de> <1183402971.3393.2.camel@loki> <1183406087.3393.11.camel@loki> <20070703110242.GG3361@leda.ptxnet.pengutronix.de> <46597312D56D2A47A3A6E9C1D0D9B7AEB0C4F2@kpladc0001.konzeptpark.intra> <20070703175856.GB8839@pengutronix.de> Message-ID: <468AA145.8090404@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Grant Likely wrote: > On 7/3/07, Rune Torgersen 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