[U-Boot-Users] BDI2000 with ppc440epx.
Leonid
Leonid at a-k-a.net
Thu May 1 17:31:44 CEST 2008
Hi, Stefan:
Thank you very much for your answer, it shows that our minds are working
alike :-). I didn't know what the problem is but I did exactly the thing
you suggest - put indefinite loop in the nand_boot() function with
condition, checking some address in RAM. I set breakpoint after this
loop and them modify memory via BDI and get my breakpoint!
The issue I am investigating is that CPU ceased to boot from NAND flash
when we switched from NAND01GW3B2AZA6 ST Micro flash to another
NAND01GW3B2BZA6. They are presumably the same (page, block size, etc...)
only word 3 is 0 for first and 0x80 fort second.
However nand_boot identifies second block of the flash (and only second
block!) as bad and doesn't copy it to RAM. If I ignore bad block,
everything works fine and also "nand ..." u-boot command doesn't see any
bad blocks.
Thanks,
Leonid.
-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de]
Sent: Thursday, May 01, 2008 5:35 AM
To: u-boot-users at lists.sourceforge.net
Cc: Leonid
Subject: Re: [U-Boot-Users] BDI2000 with ppc440epx.
On Wednesday 30 April 2008, Leonid wrote:
> I have some problem with AMCC PPC440epx CPU when it boots from NAND.
>
> I am using sequoia.cfg file. If I do "reset halt" on BDI and then
"go",
> CPU doesn't boot. If I do "reset run" it boots OK.
>
> That points on some potential problem in .cfg file. OK, I removed
entire
> [INIT] section, but situation didn't change.
Yes.
> Moreover, when I set breakpoint to the function which surely is
invoked
> and do "reset run", I don't hit breakpoint (CPU boots till the end).
Right. This is because of the icache being used for the code read from
NAND by
the IPL (see below).
> Do you have any idea what I may be doing wrong?
Not really. It is not easy to debug a NAND booting system. This is
because of
the 4k code being loaded into the icache and run from there. What I am
always
doing while debugging NAND booting 4xx systems is, integrate some
infinite
loops after the suspicious code. Or just load different values into one
(unused) register in the very early starting phase to see how far the
PPC
gets.
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
=====================================================================
More information about the U-Boot
mailing list