[U-Boot-Users] u-boot hangs after relocating itself to ram

[U-Boot-Users] u-boot hangs after relocating itself to ram

[Andre Puschmann]

Hey folkes,
I have ported u-boot to a custom board based on a freescale mpc5200. I
can successfully copy u-boot into flash using the connected bdi2000 and
we get some output on the debug port. It seems that the board crashes
right after relocation to ram (see output). I already
read the regarding faq entry but I'm not sure if this problem has
something to do with faulty sdram initialization.

this is the output than comes up on the console:

20030.56> U-Boot 1.1.6-ge4bbd8da-dirty (Nov 27 2006 - 18:46:24)
20030.56>
20030.56> CPU:   MPC5200 v1.2, Core v1.1 at 396 MHz
20030.56>        Bus 132 MHz, IPB 66 MHz, PCI 33 MHz
20030.57> Board: MPC5200 ECU
20030.57> I2C:   85 kHz, ready
20030.57> DRAM:   8 MB
20030.57> FLASH:


I'm using eldk 4.0 + insight to debug the problem. I can single-step
through the code up to the point where it branches to sdram.
After relocation I loaded a new symbol file width offset 0x7d8000, since
this is the dest-address for relocate_code().

If I continue running from that point on the board crashes at 0x7dc314
which is in function loadtask(). In assembler the code looks like this:
"0x7dc314	<loadtask+48>:		lwz     r11,-32768(r30)"


Can this be a sdram related problem or what might cause this behavior?

Any comments and suggestions are more than welcome.


Best regards,


Andr? Puschmann

[U-Boot-Users] u-boot hangs after relocating itself to ram

[Wolfgang Denk]

In message <ekhurb$vvk$1@sea.gmane.org> you wrote:

> I have ported u-boot to a custom board based on a freescale mpc5200. I
> can successfully copy u-boot into flash using the connected bdi2000 and
> we get some output on the debug port. It seems that the board crashes
> right after relocation to ram (see output). I already
> read the regarding faq entry but I'm not sure if this problem has
> something to do with faulty sdram initialization.

Guess why the FAQ is there?

> Can this be a sdram related problem or what might cause this behavior?

Please re-read the FAQ.

> Any comments and suggestions are more than welcome.

The FAQ is based on (a)  a  lot  of  experience  and  (b)  a  lot  of
questions from engineers who've been there before you. Don't ignore
it.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
As long as we're going to reinvent the wheel again, we might as  well
try making it round this time.                        - Mike Dennison

[U-Boot-Users] u-boot hangs after relocating itself to ram

[Jerry Van Baren]

Andre Puschmann wrote:
> Hey folkes,
> I have ported u-boot to a custom board based on a freescale mpc5200. I
> can successfully copy u-boot into flash using the connected bdi2000 and
> we get some output on the debug port. It seems that the board crashes
> right after relocation to ram (see output). I already
> read the regarding faq entry but I'm not sure if this problem has
> something to do with faulty sdram initialization.
> 
> this is the output than comes up on the console:
> 
> 20030.56> U-Boot 1.1.6-ge4bbd8da-dirty (Nov 27 2006 - 18:46:24)
> 20030.56>
> 20030.56> CPU:   MPC5200 v1.2, Core v1.1 at 396 MHz
> 20030.56>        Bus 132 MHz, IPB 66 MHz, PCI 33 MHz
> 20030.57> Board: MPC5200 ECU
> 20030.57> I2C:   85 kHz, ready
> 20030.57> DRAM:   8 MB
> 20030.57> FLASH:
> 
> I'm using eldk 4.0 + insight to debug the problem. I can single-step
> through the code up to the point where it branches to sdram.
> After relocation I loaded a new symbol file width offset 0x7d8000, since
> this is the dest-address for relocate_code().
> 
> If I continue running from that point on the board crashes at 0x7dc314
> which is in function loadtask(). In assembler the code looks like this:
> "0x7dc314	<loadtask+48>:		lwz     r11,-32768(r30)"
> 
> Can this be a sdram related problem or what might cause this behavior?
> 
> Any comments and suggestions are more than welcome.
> 
> Best regards,
> Andr? Puschmann

If it _isn't_ a SDRAM related problem, I suggest you look into what is 
going on in loadtask+48 (source and also disassemble it using the cross 
flavor of objdump).  -32768 is integer for "the largest negative number 
you can represent" and I would be suspicious that it is a reference to a 
variable that is undefined or too far distant to be reached relative to 
r30.  What is r30 in this context and what is it trying to access?

gvb

[U-Boot-Users] u-boot hangs after relocating itself to ram

[Andre Puschmann]

Wolfgang Denk wrote:
> In message <ekhurb$vvk$1@sea.gmane.org> you wrote:
> 
>> I have ported u-boot to a custom board based on a freescale mpc5200. I
>> can successfully copy u-boot into flash using the connected bdi2000 and
>> we get some output on the debug port. It seems that the board crashes
>> right after relocation to ram (see output). I already
>> read the regarding faq entry but I'm not sure if this problem has
>> something to do with faulty sdram initialization.
> 
> Guess why the FAQ is there?
> 
>> Can this be a sdram related problem or what might cause this behavior?
> 
> Please re-read the FAQ.
> 
>> Any comments and suggestions are more than welcome.
> 
> The FAQ is based on (a)  a  lot  of  experience  and  (b)  a  lot  of
> questions from engineers who've been there before you. Don't ignore
> it.

Hello,
I really admire the experience of all those engineers and don't wanna
spam the list.
I read the FAQ many times and double-checked the sdram initialization as
well as compared it with other code.

But I still didn't find the problem and I'm still hanging at this point.

Are there any other configuration parts that are necessary to know at
this point of u-boot loading?


here is the dram init-code I'm using:
<code>
#define SDRAM_MODE 0x00CD0000 /* burst_len = 8, cas = 3, wrt_str set */
#define SDRAM_CONTROL 0x504F0000
#define SDRAM_CONFIG1 0x62322900
#define SDRAM_CONFIG2 0x88C70004

/* configure SDRAM start/end */
*(vu_long *)MPC5XXX_SDRAM_CS0CFG = 0x00000016;  /* 8MB at 0x00000000 */
*(vu_long *)MPC5XXX_SDRAM_CS1CFG = 0x00000000;	/* disabled */

/* setup config registers */
*(vu_long *)MPC5XXX_SDRAM_CONFIG1 = SDRAM_CONFIG1;
*(vu_long *)MPC5XXX_SDRAM_CONFIG2 = SDRAM_CONFIG2;

/* unlock mode register */
*(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL | MODE_EN);

/* precharge all banks */
*(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL | MODE_EN | SOFT_PRE);

/* set mode register */
*(vu_long *)MPC5XXX_SDRAM_MODE = SDRAM_MODE;

/* precharge all banks */
*(vu_long *)MPC5XXX_SDRAM_CTRL = SDRAM_CONTROL | MODE_EN | SOFT_REF;

/* auto refresh */
*(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL | MODE_EN | SOFT_REF);

/* set mode register */
*(vu_long *)MPC5XXX_SDRAM_MODE = SDRAM_MODE;

/* normal operation */
*(vu_long *)MPC5XXX_SDRAM_CTRL = SDRAM_CONTROL;
</code>


> 
> Best regards,
> 
> Wolfgang Denk
> 

Thanks for your help.


Andre

[U-Boot-Users] u-boot hangs after relocating itself to ram

[Jerry Van Baren]

Andre Puschmann wrote:
> Wolfgang Denk wrote:
>> In message <ekhurb$vvk$1@sea.gmane.org> you wrote:
>>
>>> I have ported u-boot to a custom board based on a freescale mpc5200. I
>>> can successfully copy u-boot into flash using the connected bdi2000 and
>>> we get some output on the debug port. It seems that the board crashes
>>> right after relocation to ram (see output). I already
>>> read the regarding faq entry but I'm not sure if this problem has
>>> something to do with faulty sdram initialization.
>> Guess why the FAQ is there?
>>
>>> Can this be a sdram related problem or what might cause this behavior?
>> Please re-read the FAQ.
>>
>>> Any comments and suggestions are more than welcome.
>> The FAQ is based on (a)  a  lot  of  experience  and  (b)  a  lot  of
>> questions from engineers who've been there before you. Don't ignore
>> it.
> 
> Hello,
> I really admire the experience of all those engineers and don't wanna
> spam the list.
> I read the FAQ many times and double-checked the sdram initialization as
> well as compared it with other code.
> 
> But I still didn't find the problem and I'm still hanging at this point.
> 
> Are there any other configuration parts that are necessary to know at
> this point of u-boot loading?
> 
> 
> here is the dram init-code I'm using:
> <code>
> #define SDRAM_MODE 0x00CD0000 /* burst_len = 8, cas = 3, wrt_str set */
> #define SDRAM_CONTROL 0x504F0000
> #define SDRAM_CONFIG1 0x62322900
> #define SDRAM_CONFIG2 0x88C70004
> 
> /* configure SDRAM start/end */
> *(vu_long *)MPC5XXX_SDRAM_CS0CFG = 0x00000016;  /* 8MB at 0x00000000 */
> *(vu_long *)MPC5XXX_SDRAM_CS1CFG = 0x00000000;	/* disabled */
> 
> /* setup config registers */
> *(vu_long *)MPC5XXX_SDRAM_CONFIG1 = SDRAM_CONFIG1;
> *(vu_long *)MPC5XXX_SDRAM_CONFIG2 = SDRAM_CONFIG2;
> 
> /* unlock mode register */
> *(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL | MODE_EN);
> 
> /* precharge all banks */
> *(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL | MODE_EN | SOFT_PRE);
> 
> /* set mode register */
> *(vu_long *)MPC5XXX_SDRAM_MODE = SDRAM_MODE;
> 
> /* precharge all banks */
> *(vu_long *)MPC5XXX_SDRAM_CTRL = SDRAM_CONTROL | MODE_EN | SOFT_REF;
> 
> /* auto refresh */
> *(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL | MODE_EN | SOFT_REF);
> 
> /* set mode register */
> *(vu_long *)MPC5XXX_SDRAM_MODE = SDRAM_MODE;
> 
> /* normal operation */
> *(vu_long *)MPC5XXX_SDRAM_CTRL = SDRAM_CONTROL;
> </code>
> 
> 
>> Best regards,
>>
>> Wolfgang Denk
>>
> 
> Thanks for your help.
> 
> 
> Andre

Is the instruction that is crashing correct?  When you dump the 
equivalent location in flash, is that same exact instruction there?  If 
you look at the offending location in SDRAM with your debugger, do you 
see the same instruction as when it crashes?  (Debuggers tend to read 
memory slowly, so it may read the right value where an instruction fetch 
may misread the value.)

If it is a SDRAM problem, the answer to the above questions will likely 
be "no" - this is indicating SDRAM has been corrupted.  This could be 
due to an initialization problem, but could be a flaky board (layout 
problems).  Can you run your board at a slower clock rate?

If the culprit instruction is identical in flash, it is very likely a 
configuration/code issue, not a SDRAM initialization or board layout issue.

gvb

[U-Boot-Users] u-boot hangs after relocating itself to ram

[Andre Puschmann]

Jerry Van Baren wrote:
> Andre Puschmann wrote:
>> Wolfgang Denk wrote:
>>> In message <ekhurb$vvk$1@sea.gmane.org> you wrote:
>>>
>>>> I have ported u-boot to a custom board based on a freescale mpc5200. I
>>>> can successfully copy u-boot into flash using the connected bdi2000 and
>>>> we get some output on the debug port. It seems that the board crashes
>>>> right after relocation to ram (see output). I already
>>>> read the regarding faq entry but I'm not sure if this problem has
>>>> something to do with faulty sdram initialization.
>>> Guess why the FAQ is there?
>>>
>>>> Can this be a sdram related problem or what might cause this behavior?
>>> Please re-read the FAQ.
>>>
>>>> Any comments and suggestions are more than welcome.
>>> The FAQ is based on (a)  a  lot  of  experience  and  (b)  a  lot  of
>>> questions from engineers who've been there before you. Don't ignore
>>> it.
>> Hello,
>> I really admire the experience of all those engineers and don't wanna
>> spam the list.
>> I read the FAQ many times and double-checked the sdram initialization as
>> well as compared it with other code.
>>
>> But I still didn't find the problem and I'm still hanging at this point.
>>
>> Are there any other configuration parts that are necessary to know at
>> this point of u-boot loading?
>>
>>
>> here is the dram init-code I'm using:
>> <code>
>> #define SDRAM_MODE 0x00CD0000 /* burst_len = 8, cas = 3, wrt_str set */
>> #define SDRAM_CONTROL 0x504F0000
>> #define SDRAM_CONFIG1 0x62322900
>> #define SDRAM_CONFIG2 0x88C70004
>>
>> /* configure SDRAM start/end */
>> *(vu_long *)MPC5XXX_SDRAM_CS0CFG = 0x00000016;  /* 8MB at 0x00000000 */
>> *(vu_long *)MPC5XXX_SDRAM_CS1CFG = 0x00000000;	/* disabled */
>>
>> /* setup config registers */
>> *(vu_long *)MPC5XXX_SDRAM_CONFIG1 = SDRAM_CONFIG1;
>> *(vu_long *)MPC5XXX_SDRAM_CONFIG2 = SDRAM_CONFIG2;
>>
>> /* unlock mode register */
>> *(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL | MODE_EN);
>>
>> /* precharge all banks */
>> *(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL | MODE_EN | SOFT_PRE);
>>
>> /* set mode register */
>> *(vu_long *)MPC5XXX_SDRAM_MODE = SDRAM_MODE;
>>
>> /* precharge all banks */
>> *(vu_long *)MPC5XXX_SDRAM_CTRL = SDRAM_CONTROL | MODE_EN | SOFT_REF;
>>
>> /* auto refresh */
>> *(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL | MODE_EN | SOFT_REF);
>>
>> /* set mode register */
>> *(vu_long *)MPC5XXX_SDRAM_MODE = SDRAM_MODE;
>>
>> /* normal operation */
>> *(vu_long *)MPC5XXX_SDRAM_CTRL = SDRAM_CONTROL;
>> </code>
>>
>>
>>> Best regards,
>>>
>>> Wolfgang Denk
>>>
>> Thanks for your help.
>>
>>
>> Andre
> 
> Is the instruction that is crashing correct?  When you dump the 
> equivalent location in flash, is that same exact instruction there?  If 
> you look at the offending location in SDRAM with your debugger, do you 
> see the same instruction as when it crashes?  (Debuggers tend to read 
> memory slowly, so it may read the right value where an instruction fetch 
> may misread the value.)

Well, I can't check this for now, since I don't have the system here.
But I will do this tomorrow.
I already checked if the code is the same after relocation to ram but I
just compared some few bytes.
To debug code after relocation one have to calculate an offset to find
the right symbols. Is this address the same that is given to
relocate_code() in board_init_f(), since it doesn't follows the equation
offered in the regarding faq-entry? I have an 0x8000 additional offset.
0x800000(2MB) - 0x30000(192kb) = 0x7d0000
But 0x7d8000 is given as destination address to relocate_code(). I am
asking just to be sure to debug the right way.

> 
> If it is a SDRAM problem, the answer to the above questions will likely 
> be "no" - this is indicating SDRAM has been corrupted.  This could be 
> due to an initialization problem, but could be a flaky board (layout 
> problems).  Can you run your board at a slower clock rate?
> 
> If the culprit instruction is identical in flash, it is very likely a 
> configuration/code issue, not a SDRAM initialization or board layout issue.
> 

I will check this tomorrow but I guess the sdram initialization should
be ok, since it is working (the same parameters) with another os that
also uses caches and dma for a long while.

> gvb
> 

Thank you very much.


Andre


> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[U-Boot-Users] u-boot hangs after relocating itself to ram

[Andre Puschmann]

Hello everybody,
yesterday I solved my problem. It was a faulty sdram initialization.
But still don't know why the values I used before didn't work.
But its  kind of robustness that the systems works with the values
assumed not to work.
Anyway, thank you for your help.


Best regards,


Andre



Andre Puschmann wrote:
> Hey folkes,
> I have ported u-boot to a custom board based on a freescale mpc5200. I
> can successfully copy u-boot into flash using the connected bdi2000 and
> we get some output on the debug port. It seems that the board crashes
> right after relocation to ram (see output). I already
> read the regarding faq entry but I'm not sure if this problem has
> something to do with faulty sdram initialization.
> 
> this is the output than comes up on the console:
> 
> 20030.56> U-Boot 1.1.6-ge4bbd8da-dirty (Nov 27 2006 - 18:46:24)
> 20030.56>
> 20030.56> CPU:   MPC5200 v1.2, Core v1.1 at 396 MHz
> 20030.56>        Bus 132 MHz, IPB 66 MHz, PCI 33 MHz
> 20030.57> Board: MPC5200 ECU
> 20030.57> I2C:   85 kHz, ready
> 20030.57> DRAM:   8 MB
> 20030.57> FLASH:
> 
> 
> I'm using eldk 4.0 + insight to debug the problem. I can single-step
> through the code up to the point where it branches to sdram.
> After relocation I loaded a new symbol file width offset 0x7d8000, since
> this is the dest-address for relocate_code().
> 
> If I continue running from that point on the board crashes at 0x7dc314
> which is in function loadtask(). In assembler the code looks like this:
> "0x7dc314	<loadtask+48>:		lwz     r11,-32768(r30)"
> 
> 
> Can this be a sdram related problem or what might cause this behavior?
> 
> Any comments and suggestions are more than welcome.
> 
> 
> Best regards,
> 
> 
> Andr? Puschmann
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV