[U-Boot-Users] hang up after start_here

[U-Boot-Users] hang up after start_here

[Laurent Mohin]

Hello all,

I'm designing a custom board build around a 405GPr processor. I'm in my 
third prototype phase, and I've problem with one board which hang during 
Linux booting.
I've debugged and found that the board hangs in start_here function and 
doesn't reach the early_init function.

Because the problem appears on only one of my boards out of 16, I suspect 
a hardware problem, and because it occurs just after mmu initialisation 
and caches enabling, I suspect more especially sdram accesses.

I want to know if anybody has encountered a similar problem and if the 
diagnostic was the same.

Kernel version is 2.4.18 from Montavista.

Thanks for help,

Laurent

[U-Boot-Users] hang up after start_here

[Wolfgang Denk]

In message <OFE8EA1A87.9A7B8A06-ONC1256D86.0028950A-C1256D86.002D5CE3@se.wavetek.com> you wrote:
> 
> I've debugged and found that the board hangs in start_here function and 
> doesn't reach the early_init function.
> 
> Because the problem appears on only one of my boards out of 16, I suspect 
> a hardware problem, and because it occurs just after mmu initialisation 
> and caches enabling, I suspect more especially sdram accesses.
> 
> I want to know if anybody has encountered a similar problem and if the 
> diagnostic was the same.

This is a standard problem, which can show up in many forms.  My  bet
is  that  your  SDRAM initialization sequence is incomplete / broken.
Remember that it is NOT sufficient to set up the  mmeory  controller,
you must also intialize the SDRAM chips themself.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"What is wanted is not the will to believe, but the will to find out,
which is the exact opposite." - Bertrand Russell, _Sceptical_Essays_,
1928

[U-Boot-Users] hang up after start_here

[S. Hebbar]

Hello,

I am having the exact same problem. It doesn't return to start_here label 
after executing RFI instruction. (linux-2.4.20)

linux-2.4.20/arch/ppc/kernel/start.S ==>

turn_on_mmu:
  mfmsr r0
  ori r0,r0,MSR_DR|MSR_IR
  mtspr SRR1,r0
  lis r0,start_here at h
  ori r0,r0,start_here at l
  mtspr SRR0,r0
  SYNC
  RFI       /* enables MMU */


I have 128Meg or SDRAM  on a MPC8260 board.
The initialization sequence in U-BOOT is as follows.

void initdram()
{
#define CFG_SDRAM_BASE 0x0
#define CFG_IMMR 0x60000000

  int i;
  int      size;
  int      cpu_type=0;
  volatile immap_t *immap  = (immap_t *)CFG_IMMR;
  volatile memctl8260_t *memctl = &immap->im_memctl;
  volatile uchar c = 0;
  volatile uchar *ramaddr = (uchar *)(CFG_SDRAM_BASE) + 0x110;


/* Set OR1 and OR2 values */
memctl->memc_or1 = 0xf8002940;
memctl->memc_br1 = 0x00000041;


/*
* Quote from 8260 UM (10.4.2 SDRAM Power-On Initialization, 10-35):
*
* "At system reset, initialization software must set up the
*  programmable parameters in the memory controller banks registers
*  (ORx, BRx, P/LSDMR). After all memory parameters are configured,
*  system software should execute the following initialization sequence
*  for each SDRAM device.
*
*  1. Issue a PRECHARGE-ALL-BANKS command
*  2. Issue eight CBR REFRESH commands
*  3. Issue a MODE-SET command to initialize the mode register
*
*  The initial commands are executed by setting P/LSDMR[OP] and
*  accessing the SDRAM with a single-byte transaction."
*
* The appropriate BRx/ORx registers have already been set when we
* get here. The SDRAM can be accessed at the address CFG_SDRAM_BASE.
*/

  memctl->memc_psrt = psrt;
  memctl->memc_mptpr = mptpr;;

  memctl->memc_psdmr = (ulong) psdmr | PSDMR_OP_PREA;
  *ramaddr = c;

  memctl->memc_psdmr = (ulong) psdmr | PSDMR_OP_CBRR;
  for (i = 0; i < 8; i++)
    *ramaddr = c;

  memctl->memc_psdmr = (ulong) psdmr | PSDMR_OP_MRW;
  *ramaddr = c;

 memctl->memc_psdmr = (ulong) psdmr | PSDMR_OP_NORM | PSDMR_RFEN;
 *ramaddr = c;


I have turned off Data cache in U-BOOT. If I enabel D-CACHE, the code hangs
in U-BOOT itself. 

Any help is very much appreciated.

Regards,
Hebbar.


\ <OFE8EA1A87.9A7B8A06-ONC1256D86.0028950A-C1256D86.002D5CE3@se.wavetek.com> 
you wrote:
>
> I've debugged and found that the board hangs in start_here function and
> doesn't reach the early_init function.
>
> Because the problem appears on only one of my boards out of 16, I suspect
> a hardware problem, and because it occurs just after mmu initialisation
> and caches enabling, I suspect more especially sdram accesses.
>
> I want to know if anybody has encountered a similar problem and if the
> diagnostic was the same.

This is a standard problem, which can show up in many forms.  My  bet
is  that  your  SDRAM initialization sequence is incomplete / broken.
Remember that it is NOT sufficient to set up the  mmeory  controller,
you must also intialize the SDRAM chips themself.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"What is wanted is not the will to believe, but the will to find out,
which is the exact opposite." - Bertrand Russell, _Sceptical_Essays_,
1928

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

[U-Boot-Users] hang up after start_here

[Laurent Mohin]

Wolfgang,

thanks for your reply.
How can you bet that my initialization sequence is incomplete?
I remember you that it works on 15 boards out of 16. 

Laurent





Wolfgang Denk <wd@denx.de>
Sent by: wd at denx.de
18/08/03 10:39

 
        To:     "Laurent Mohin" <laurent.mohin@acterna.com>
        cc:     linuxppc-embedded at lists.linuxppc.org, u-boot-users at lists.sourceforge.net
        Subject:        Re: [U-Boot-Users] hang up after start_here


In message 
<OFE8EA1A87.9A7B8A06-ONC1256D86.0028950A-C1256D86.002D5CE3@se.wavetek.com> 
you wrote:
> 
> I've debugged and found that the board hangs in start_here function and 
> doesn't reach the early_init function.
> 
> Because the problem appears on only one of my boards out of 16, I 
suspect 
> a hardware problem, and because it occurs just after mmu initialisation 
> and caches enabling, I suspect more especially sdram accesses.
> 
> I want to know if anybody has encountered a similar problem and if the 
> diagnostic was the same.

This is a standard problem, which can show up in many forms.  My  bet
is  that  your  SDRAM initialization sequence is incomplete / broken.
Remember that it is NOT sufficient to set up the  mmeory  controller,
you must also intialize the SDRAM chips themself.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"What is wanted is not the will to believe, but the will to find out,
which is the exact opposite." - Bertrand Russell, _Sceptical_Essays_,
1928

[U-Boot-Users] hang up after start_here

[Frank Robbins]

Is this  Motorola MPC8XX family?

If so ...
I would suggest that if you don't turn on the MMU and the cache it may
work.... normally indicating a SDRAM problem

What are you doing to set the mode and CAS latency on your SDRAM IC's .

There is no Pure SDRAM controller on this processor family you have to do
some of the work to get SDRAM running

Once the cache and MMU are on then the chip will really ROCK the SDRAM hence
strange failures.



Regards

Frank Robbins



Analogue & Micro Ltd,
9 Clytha Park Road
Newport
South Wales
NP20 4US
United Kingdom (Great Britain)
Email : Frank.Robbins at Analogue-Micro.com
Email : Frank at Analogue-Micro.com

http://www.Analogue-Micro.com

Tel: 44 (0)1633 666787
Fax: 44 (0)1633 666788


----- Original Message ----- 
From: "Laurent Mohin" <laurent.mohin@acterna.com>
To: "Wolfgang Denk" <wd@denx.de>
Cc: <linuxppc-embedded@lists.linuxppc.org>;
<u-boot-users@lists.sourceforge.net>; <wd@denx.de>
Sent: Tuesday, August 19, 2003 8:51 AM
Subject: Re: [U-Boot-Users] hang up after start_here


>
> Wolfgang,
>
> thanks for your reply.
> How can you bet that my initialization sequence is incomplete?
> I remember you that it works on 15 boards out of 16.
>
> Laurent
>
>
>
>
>
> Wolfgang Denk <wd@denx.de>
> Sent by: wd at denx.de
> 18/08/03 10:39
>
>
>         To:     "Laurent Mohin" <laurent.mohin@acterna.com>
>         cc:     linuxppc-embedded at lists.linuxppc.org,
u-boot-users at lists.sourceforge.net
>         Subject:        Re: [U-Boot-Users] hang up after start_here
>
>
> In message
> <OFE8EA1A87.9A7B8A06-ONC1256D86.0028950A-C1256D86.002D5CE3@se.wavetek.com>
> you wrote:
> >
> > I've debugged and found that the board hangs in start_here function and
> > doesn't reach the early_init function.
> >
> > Because the problem appears on only one of my boards out of 16, I
> suspect
> > a hardware problem, and because it occurs just after mmu initialisation
> > and caches enabling, I suspect more especially sdram accesses.
> >
> > I want to know if anybody has encountered a similar problem and if the
> > diagnostic was the same.
>
> This is a standard problem, which can show up in many forms.  My  bet
> is  that  your  SDRAM initialization sequence is incomplete / broken.
> Remember that it is NOT sufficient to set up the  mmeory  controller,
> you must also intialize the SDRAM chips themself.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
> "What is wanted is not the will to believe, but the will to find out,
> which is the exact opposite." - Bertrand Russell, _Sceptical_Essays_,
> 1928
>
>
> ** Sent via the linuxppc-embedded mail list. See
http://lists.linuxppc.org/
>

[U-Boot-Users] hang up after start_here

[Laurent Mohin]

Franck,

No it's an IBM 405GPr processor which includes a SDRAM controller instead 
of the UPM of the MPC8XX. 
The mode and CAS latency of my SDRAM IC's are set by the controller 
itself. Once enabled, it performs an initalization procedure including 
issuing the mode register write command to each bank.

By the way, what is the easiest way to turn MMU and caches OFF?

Laurent





"Frank Robbins" <Frank.Robbins@Analogue-Micro.com>
19/08/03 11:24

 
        To:     "Wolfgang Denk" <wd@denx.de>, "Laurent Mohin" <laurent.mohin@acterna.com>
        cc:     <linuxppc-embedded@lists.linuxppc.org>, 
<u-boot-users@lists.sourceforge.net>, <wd@denx.de>
        Subject:        Re: [U-Boot-Users] hang up after start_here


Is this  Motorola MPC8XX family?

If so ...
I would suggest that if you don't turn on the MMU and the cache it may
work.... normally indicating a SDRAM problem

What are you doing to set the mode and CAS latency on your SDRAM IC's .

There is no Pure SDRAM controller on this processor family you have to do
some of the work to get SDRAM running

Once the cache and MMU are on then the chip will really ROCK the SDRAM 
hence
strange failures.



Regards

Frank Robbins



Analogue & Micro Ltd,
9 Clytha Park Road
Newport
South Wales
NP20 4US
United Kingdom (Great Britain)
Email : Frank.Robbins at Analogue-Micro.com
Email : Frank at Analogue-Micro.com

http://www.Analogue-Micro.com

Tel: 44 (0)1633 666787
Fax: 44 (0)1633 666788


----- Original Message ----- 
From: "Laurent Mohin" <laurent.mohin@acterna.com>
To: "Wolfgang Denk" <wd@denx.de>
Cc: <linuxppc-embedded@lists.linuxppc.org>;
<u-boot-users@lists.sourceforge.net>; <wd@denx.de>
Sent: Tuesday, August 19, 2003 8:51 AM
Subject: Re: [U-Boot-Users] hang up after start_here


>
> Wolfgang,
>
> thanks for your reply.
> How can you bet that my initialization sequence is incomplete?
> I remember you that it works on 15 boards out of 16.
>
> Laurent
>
>
>
>
>
> Wolfgang Denk <wd@denx.de>
> Sent by: wd at denx.de
> 18/08/03 10:39
>
>
>         To:     "Laurent Mohin" <laurent.mohin@acterna.com>
>         cc:     linuxppc-embedded at lists.linuxppc.org,
u-boot-users at lists.sourceforge.net
>         Subject:        Re: [U-Boot-Users] hang up after start_here
>
>
> In message
> 
<OFE8EA1A87.9A7B8A06-ONC1256D86.0028950A-C1256D86.002D5CE3@se.wavetek.com>
> you wrote:
> >
> > I've debugged and found that the board hangs in start_here function 
and
> > doesn't reach the early_init function.
> >
> > Because the problem appears on only one of my boards out of 16, I
> suspect
> > a hardware problem, and because it occurs just after mmu 
initialisation
> > and caches enabling, I suspect more especially sdram accesses.
> >
> > I want to know if anybody has encountered a similar problem and if the
> > diagnostic was the same.
>
> This is a standard problem, which can show up in many forms.  My  bet
> is  that  your  SDRAM initialization sequence is incomplete / broken.
> Remember that it is NOT sufficient to set up the  mmeory  controller,
> you must also intialize the SDRAM chips themself.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
> "What is wanted is not the will to believe, but the will to find out,
> which is the exact opposite." - Bertrand Russell, _Sceptical_Essays_,
> 1928
>
>
> ** Sent via the linuxppc-embedded mail list. See
http://lists.linuxppc.org/
>

[U-Boot-Users] hang up after start_here

[Kenneth Johansson]

On Tue, 2003-08-19 at 09:51, Laurent Mohin wrote:
> Wolfgang,
> 
> thanks for your reply.
> How can you bet that my initialization sequence is incomplete?
> I remember you that it works on 15 boards out of 16. 
> 
> Laurent

It's a common error on the motorola parts however that particular
problem is impossible to get on the IBM chip. you can still have the
timing to fast and wrong mode for the chip but thats it.

I say throw the card away :)

-- 
Kenneth Johansson	
Ericsson AB                       Tel: +46 8 719 70 20
Tellusborgsv?gen  90              Fax: +46 8 719 29 45
126 25 Stockholm                  ken at switchboard.ericsson.se