[U-Boot-Users] BDI2000 with ppc440epx.
Hi:
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.
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).
Do you have any idea what I may be doing wrong?
Thanks,
Leonid.
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@denx.de =====================================================================
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@denx.de] Sent: Thursday, May 01, 2008 5:35 AM To: u-boot-users@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@denx.de =====================================================================
Hi Leonid,
On Thursday 01 May 2008, Leonid wrote:
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.
Word or byte? You are referring to the offset in the OOB, correct? Are you are using the latest U-Boot version with 2k page size NAND booting support? On large page NAND chips the bad block marker is in byte 0.
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@denx.de =====================================================================
participants (2)
-
Leonid -
Stefan Roese