[U-Boot-Users] Cleanup output of MPC83xx boards

[U-Boot-Users] Cleanup output of MPC83xx boards

[Wolfgang Denk]

Dear Kim,

I would like to suggest to clean up the output printed by most
MPC83xx boards a bit. What do you think about a patch like this one:

@@ ...
 {
        u32 msize = 0;
 
-       puts ("Initializing\n");
        msize = fixed_sdram ();
-       puts ("   DDR RAM: ");
 
        return msize;
 }

I think something like this should be applied toi the following files:

	board/sbc8349/sbc8349.c
	board/mpc832xemds/mpc832xemds.c
	board/mpc8360emds/mpc8360emds.c
	board/freescale/mpc8323erdb/mpc8323erdb.c
	board/mpc8349itx/mpc8349itx.c
	board/mpc8349emds/mpc8349emds.c
	board/mpc8313erdb/sdram.c

Also, if I understand this correctly, these  files  use  a  hardwired
memory  size.  I this correct? Do you have any plans to bring this in
line  with  the  normal  U-Boot  design  philisophy  which  uses  the
memsize() function to automatically detect and adjust for the size of
memory  really  present on a board, allowing to use the same image on
differing configurations?

Thanks, and best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)
        O, throw away the worser part of it,
        And live the purer with the other half.

[U-Boot-Users] Cleanup output of MPC83xx boards

[Timur Tabi]

Wolfgang Denk wrote:
> Dear Kim,
> 
> I would like to suggest to clean up the output printed by most
> MPC83xx boards a bit. What do you think about a patch like this one:
> 
> @@ ...
>  {
>         u32 msize = 0;
>  
> -       puts ("Initializing\n");
>         msize = fixed_sdram ();
> -       puts ("   DDR RAM: ");
>  
>         return msize;
>  }

Kim is really the one to be answering this, but I'll chime in since I'm reading email now.

I'm all for making 83xx more like other boards where it makes sense.  Unfortunately, I am personally not really aware of what other boards do, or what the U-Boot norm is, so I would need to be told on a case-by-case basis what is different about 83xx.

> I think something like this should be applied toi the following files:
> 
> 	board/sbc8349/sbc8349.c
> 	board/mpc832xemds/mpc832xemds.c
> 	board/mpc8360emds/mpc8360emds.c
> 	board/freescale/mpc8323erdb/mpc8323erdb.c
> 	board/mpc8349itx/mpc8349itx.c
> 	board/mpc8349emds/mpc8349emds.c
> 	board/mpc8313erdb/sdram.c
> 
> Also, if I understand this correctly, these  files  use  a  hardwired
> memory  size.  I this correct? 

I think so.  There is a define for the memory size, but off the top of my head, I think it's only use to saw the LAWBAR.

> Do you have any plans to bring this in
> line  with  the  normal  U-Boot  design  philisophy  which  uses  the
> memsize() function to automatically detect and adjust for the size of
> memory  really  present on a board, allowing to use the same image on
> differing configurations?

I don't know of any plans, but then, I didn't know it was a problem.

[U-Boot-Users] Cleanup output of MPC83xx boards

[Wolfgang Denk]

Dear Tiur,

in message <46BF39E1.2010904@freescale.com> you wrote:
>
> > -       puts ("Initializing\n");
> >         msize = fixed_sdram ();
> > -       puts ("   DDR RAM: ");
> >  
> >         return msize;
> >  }
> 
> Kim is really the one to be answering this, but I'll chime in since I'm reading email now.
> 
> I'm all for making 83xx more like other boards where it makes sense.  Unfortunately, I am personally not really aware of what other boards do, or what the U-Boot norm is, so I would need to be told on a case-by-case basis what is different about 83xx.

Can you please restrict your line length to some 70 characters or so?
Thanks.

U-Boot "norm" is that the common framework will print "DRAM:  " before
it starts the memory sizing and testing, and the size it found once
that completed. That makes some nicely aligned output like here:

	CPU:   MPC5200 v1.2, Core v1.1 at 396 MHz
	       Bus 132 MHz, IPB 132 MHz, PCI 66 MHz
	Board: TQM5200 (TQ-Components GmbH)
	       on a STK52xx carrier board
	I2C:   85 kHz, ready
	DRAM:  64 MB
	FLASH: 32 MB
	In:    serial
	Out:   serial
	Err:   serial

In the code above, "Initializing\n" and " DDR RAM:  "  strings  break
this; then it looks like this:

	CPU: MPC5121e rev. 1.0, Core e300c4 at 264 MHz, CSB at 132 MHz
	Board: ADS5121 rev. 0x0001 (CPLD rev. 0x03)
	       Watchdog enabled
	I2C:   ready
	DRAM:  Initializing
	   DDR RAM: 256 MB
	FLASH: 64 MB
	In:    serial
	Out:   serial
	Err:   serial

This looks not only ugly, but the "Initializing" and "DDR RAM:"
strings also don't add any  new information, so let's get rid of
these.

> > I think something like this should be applied toi the following files:
> > 
> > 	board/sbc8349/sbc8349.c
> > 	board/mpc832xemds/mpc832xemds.c
> > 	board/mpc8360emds/mpc8360emds.c
> > 	board/freescale/mpc8323erdb/mpc8323erdb.c
> > 	board/mpc8349itx/mpc8349itx.c
> > 	board/mpc8349emds/mpc8349emds.c
> > 	board/mpc8313erdb/sdram.c
> > 
> > Also, if I understand this correctly, these  files  use  a  hardwired
> > memory  size.  I this correct? 
> 
> I think so.  There is a define for the memory size, but off the top of my head, I think it's only use to saw the LAWBAR.
> 
> > Do you have any plans to bring this in
> > line  with  the  normal  U-Boot  design  philisophy  which  uses  the
> > memsize() function to automatically detect and adjust for the size of
> > memory  really  present on a board, allowing to use the same image on
> > differing configurations?
> 
> I don't know of any plans, but then, I didn't know it was a problem.

It is not a problem in terms of  malfunction,  but  it  violates  the
design  rules,  and  there  is  IMHO  no  good  reason to give up the
flexibility that's built into U-boot  here.  Also,  the  memory  size
function  serves  as  a  very simple but prettu efficient memory test
that will help to detect 95% of all typical RAM related manufacturing
problems. When U-Boot prints "DRAM:  0 MB" you know exactly where  to
look at.

See also http://www.denx.de/wiki/UBoot/DesignPrinciples

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A consultant is a person who borrows your watch, tells you what  time
it is, pockets the watch, and sends you a bill for it.

[U-Boot-Users] Cleanup output of MPC83xx boards

[Kim Phillips]

On Sun, 12 Aug 2007 18:25:27 +0200
Wolfgang Denk <wd@denx.de> wrote:

> Dear Kim,
> 
> I would like to suggest to clean up the output printed by most
> MPC83xx boards a bit. What do you think about a patch like this one:
> 
the problem is some boards spit out other memory diagnostic
information, such as:

---
   DDR DIMM: data bus width is 64 bit without ECC
   DDRC ECC mode: OFF
   SDRAM on Local Bus is NOT available!
---

I can abbreviate the above to have the entire DRAM line show something
like "DRAM: 64-bit, ECC off, 256MB\n".  Let me know if you have
objections.

> Also, if I understand this correctly, these  files  use  a  hardwired
> memory  size.  I this correct? Do you have any plans to bring this in

afaict, yes.

> line  with  the  normal  U-Boot  design  philisophy  which  uses  the
> memsize() function to automatically detect and adjust for the size of
> memory  really  present on a board, allowing to use the same image on
> differing configurations?

Thanks for the info.  Some boards have fixed mem, some don't, but in
either case I'll have to add this to my TODOLIST.

Kim

[U-Boot-Users] Cleanup output of MPC83xx boards

[Wolfgang Denk]

Dear Kim,

in message <20070813135529.2e92d4ea.kim.phillips@freescale.com> you wrote:
>
> I can abbreviate the above to have the entire DRAM line show something
> like "DRAM: 64-bit, ECC off, 256MB\n".  Let me know if you have
> objections.

Looks good to me.

> > line  with  the  normal  U-Boot  design  philisophy  which  uses  the
> > memsize() function to automatically detect and adjust for the size of
> > memory  really  present on a board, allowing to use the same image on
> > differing configurations?
> 
> Thanks for the info.  Some boards have fixed mem, some don't, but in
> either case I'll have to add this to my TODOLIST.

Even with fixed memory size the use of  memsize()  is  often  a  food
idea,  as  it  perorms  some  basic  memory  testing (see my previous
message to Timur).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I don't mind criticism. You know me. I've  never  been  one  to  take
offence  at  criticism. No one could say I'm the sort to take offence
at criticism -- Not twice, anyway. Not without blowing bubbles.
                                  - Terry Pratchett, _Witches Abroad_

[U-Boot-Users] Cleanup output of MPC83xx boards

[Stefan Roese]

Hi Kim,

On Monday 13 August 2007, Kim Phillips wrote:
> the problem is some boards spit out other memory diagnostic
> information, such as:
>
> ---
>    DDR DIMM: data bus width is 64 bit without ECC
>    DDRC ECC mode: OFF
>    SDRAM on Local Bus is NOT available!
> ---
>
> I can abbreviate the above to have the entire DRAM line show something
> like "DRAM: 64-bit, ECC off, 256MB\n".  Let me know if you have
> objections.

On some 4xx boards I generate this output:

DRAM:  512 MB (ECC not enabled, 533 MHz, CL4)

It's using the function board_add_ram_info() enabled via the 
CONFIG_ADD_RAM_INFO option. Perhaps we could define this function as weak 
too, to loose some more #ifdef's.

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
=====================================================================