MTD and 28F128J3A

MTD and 28F128J3A

[Stefan Stürke]

Hi,

I have a problem with the 28F128J3A flash during system reboot.

Environment:

- mpc8270
- linuxppc_2_4_devel (snapshot from the denx ppc tree based on 2.4.25)
- mtd version included in that tree
- a jffs2 file system is mounted on the flash

Problem:

When I reboot the system, I get a kernel panic right after the jump to 
the reset vector in m8260_gorom().

Using my BDI2000 I was able to find out that the kernel panic occurred
because 8260_gorom tries to execute some code in Flash (this is
correct because the bootloader is also located in that flash) but the
Flash is in query mode at this time. So the correct code could not be
read by the processor

So my question: Why is the flash left in query mode?
I found that also in normal operation the flash is in query mode after
writing to it. Is this ok? (I have no problems during normal operation).
What can I do to leave the query mode before reboot?

When I use the same hardware platform with another flash type
AMD29LV128M I have no problems during reboot.

One difference I can think of is, that in the case of the
28F128J3A the chips/cfi_cmdset_0001 driver is used, while in the case
of the AMD29LV128M the chips/cfi_cmdset_0002 driver is used.
Any ideas?

Thanks in advance,
Stefan

-- 
Stefan Stürke

Re: MTD and 28F128J3A

[Jaap-Jan Boor]

Stefan,

what I did is force a checkstop the will result in a processor
reset before executing 'm8260_gorom()' (this should also reset
your flash devices) by adding the following code to
m8260_machine_restart():

static void
m8260_restart(char *cmd)
{
        extern void m8260_gorom(bd_t *bi, uint addr);
        uint    startaddr;

#ifdef CONFIG_MYSYSTEM
        unsigned long hid0;
        // Need interrupts off to force checkstop
        cli();
        // Checkstop reset enable
        ((immap_t *)IMAP_ADDR)->im_clkrst.car_rmr |= 0x01;
        // Force a checkstop by turning on parity which is not
        // implemented
        hid0 = mfspr(HID0);
        hid0 |= 0x30000000;
        mtspr(HID0, hid0);
#else
        /* Most boot roms have a warmstart as the second instruction
         * of the reset vector.  If that doesn't work for you, change
         * this or the reboot program to send a proper address.
         */
        startaddr = 0xff000104;

        if (cmd != NULL) {
                if (!strncmp(cmd, "startaddr=", 10))
                        startaddr = simple_strtoul(&cmd[10], NULL, 0);
        }

        m8260_gorom((unsigned int)__pa(__res), startaddr);
#endif
}

Jaap-Jan


On Thu, 2004-08-19 at 13:46, Stefan Stürke wrote:
> Hi,
> 
> I have a problem with the 28F128J3A flash during system reboot.
> 
> Environment:
> 
> - mpc8270
> - linuxppc_2_4_devel (snapshot from the denx ppc tree based on 2.4.25)
> - mtd version included in that tree
> - a jffs2 file system is mounted on the flash
> 
> Problem:
> 
> When I reboot the system, I get a kernel panic right after the jump to 
> the reset vector in m8260_gorom().
> 
> Using my BDI2000 I was able to find out that the kernel panic occurred
> because 8260_gorom tries to execute some code in Flash (this is
> correct because the bootloader is also located in that flash) but the
> Flash is in query mode at this time. So the correct code could not be
> read by the processor
> 
> So my question: Why is the flash left in query mode?
> I found that also in normal operation the flash is in query mode after
> writing to it. Is this ok? (I have no problems during normal operation).
> What can I do to leave the query mode before reboot?
> 
> When I use the same hardware platform with another flash type
> AMD29LV128M I have no problems during reboot.
> 
> One difference I can think of is, that in the case of the
> 28F128J3A the chips/cfi_cmdset_0001 driver is used, while in the case
> of the AMD29LV128M the chips/cfi_cmdset_0002 driver is used.
> Any ideas?
> 
> Thanks in advance,
> Stefan
-- 
J.G.J. Boor                       Anton Philipsweg 1
Software Engineer                 1223 KZ Hilversum
AimSys bv                         tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum   mailto:jjboor@aimsys.nl

Re: MTD and 28F128J3A

[Jaap-Jan Boor]

I got it from here:

http://lists.linuxppc.org/linuxppc-embedded/200312/msg00164.html

On Thu, 2004-08-19 at 14:48, Jaap-Jan Boor wrote:
> Stefan,
> 
> what I did is force a checkstop the will result in a processor
> reset before executing 'm8260_gorom()' (this should also reset
> your flash devices) by adding the following code to
> m8260_machine_restart():
> 
> static void
> m8260_restart(char *cmd)
> {
>         extern void m8260_gorom(bd_t *bi, uint addr);
>         uint    startaddr;
> 
> #ifdef CONFIG_MYSYSTEM
>         unsigned long hid0;
>         // Need interrupts off to force checkstop
>         cli();
>         // Checkstop reset enable
>         ((immap_t *)IMAP_ADDR)->im_clkrst.car_rmr |= 0x01;
>         // Force a checkstop by turning on parity which is not
>         // implemented
>         hid0 = mfspr(HID0);
>         hid0 |= 0x30000000;
>         mtspr(HID0, hid0);
> #else
>         /* Most boot roms have a warmstart as the second instruction
>          * of the reset vector.  If that doesn't work for you, change
>          * this or the reboot program to send a proper address.
>          */
>         startaddr = 0xff000104;
> 
>         if (cmd != NULL) {
>                 if (!strncmp(cmd, "startaddr=", 10))
>                         startaddr = simple_strtoul(&cmd[10], NULL, 0);
>         }
> 
>         m8260_gorom((unsigned int)__pa(__res), startaddr);
> #endif
> }
> 
> Jaap-Jan
> 
> 
> On Thu, 2004-08-19 at 13:46, Stefan Stürke wrote:
> > Hi,
> > 
> > I have a problem with the 28F128J3A flash during system reboot.
> > 
> > Environment:
> > 
> > - mpc8270
> > - linuxppc_2_4_devel (snapshot from the denx ppc tree based on 2.4.25)
> > - mtd version included in that tree
> > - a jffs2 file system is mounted on the flash
> > 
> > Problem:
> > 
> > When I reboot the system, I get a kernel panic right after the jump to 
> > the reset vector in m8260_gorom().
> > 
> > Using my BDI2000 I was able to find out that the kernel panic occurred
> > because 8260_gorom tries to execute some code in Flash (this is
> > correct because the bootloader is also located in that flash) but the
> > Flash is in query mode at this time. So the correct code could not be
> > read by the processor
> > 
> > So my question: Why is the flash left in query mode?
> > I found that also in normal operation the flash is in query mode after
> > writing to it. Is this ok? (I have no problems during normal operation).
> > What can I do to leave the query mode before reboot?
> > 
> > When I use the same hardware platform with another flash type
> > AMD29LV128M I have no problems during reboot.
> > 
> > One difference I can think of is, that in the case of the
> > 28F128J3A the chips/cfi_cmdset_0001 driver is used, while in the case
> > of the AMD29LV128M the chips/cfi_cmdset_0002 driver is used.
> > Any ideas?
> > 
> > Thanks in advance,
> > Stefan
-- 
J.G.J. Boor                       Anton Philipsweg 1
Software Engineer                 1223 KZ Hilversum
AimSys bv                         tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum   mailto:jjboor@aimsys.nl

Re: MTD and 28F128J3A

[Stefan Stürke]

Jaap-Jan Boor wrote:
> Stefan,
> 
> what I did is force a checkstop the will result in a processor
> reset before executing 'm8260_gorom()' (this should also reset
> your flash devices) by adding the following code to
> m8260_machine_restart():
> 

[snip]

Thank you, nice idea. I just tested it but unfortunatly at
my hardware the reset pin of the flash is only triggered
by power on reset and not by processor reset. So the
checkstop just kills the processor but it still can not
read valid code from flash :-(

Of course as 'dirty' solution I could write a 0xFF to
the flash device before executing 'm8260_gorom()'.
In this way the problem should be solved.

But I am afraid that the code in cfi_cmset_0001 has a bug
leaving the chip in query mode after writing to it. And that
this bug has side effects which I can't see know but which will
be seen by our customers.
Has anybody ever heard of such behavior of cfi_cmset_0001?

Thanks again
Stefan

-- 
Stefan Stürke

Re: MTD and 28F128J3A

[Josh Boyer]

On Thu, 2004-08-19 at 10:33, Stefan Stürke wrote:

> Thank you, nice idea. I just tested it but unfortunatly at
> my hardware the reset pin of the flash is only triggered
> by power on reset and not by processor reset. So the
> checkstop just kills the processor but it still can not
> read valid code from flash :-(

I had a situation like that once.  Some may tell you that it's a broken
board design, which is mostly true.  But we don't always have a say in
the design of the boards we use ;).

> 
> Of course as 'dirty' solution I could write a 0xFF to
> the flash device before executing 'm8260_gorom()'.
> In this way the problem should be solved.
> 
> But I am afraid that the code in cfi_cmset_0001 has a bug
> leaving the chip in query mode after writing to it. And that
> this bug has side effects which I can't see know but which will
> be seen by our customers.
> Has anybody ever heard of such behavior of cfi_cmset_0001?

Is it in CFI query mode, or in Read Status mode?  I have seen it be left
in Read Status mode after a write, but never CFI query mode.

Leaving it in Read Status mode shouldn't have any side effects during
runtime operation, since the MTD code expects that.  It's probably more
efficient anyway, since the code can't be sure of what the next
operation will be.

To solve your reset issue, you could do what you said above.  Or you can
put the chip in Read Array mode after every write is completed (erase
too for that matter).  That won't catch all the corner cases though.

josh

Re: MTD and 28F128J3A

[Jaap-Jan Boor]

On Thu, 2004-08-19 at 17:49, Josh Boyer wrote:
> On Thu, 2004-08-19 at 10:33, Stefan StÃŒrke wrote:
> 
> > Thank you, nice idea. I just tested it but unfortunatly at
> > my hardware the reset pin of the flash is only triggered
> > by power on reset and not by processor reset. So the
> > checkstop just kills the processor but it still can not
> > read valid code from flash :-(
> 
> I had a situation like that once.  Some may tell you that it's a broken
> board design, which is mostly true.  But we don't always have a say in
> the design of the boards we use ;).
> 
> > 
> > Of course as 'dirty' solution I could write a 0xFF to
> > the flash device before executing 'm8260_gorom()'.
> > In this way the problem should be solved.
> > 
> > But I am afraid that the code in cfi_cmset_0001 has a bug
> > leaving the chip in query mode after writing to it. And that
> > this bug has side effects which I can't see know but which will
> > be seen by our customers.
> > Has anybody ever heard of such behavior of cfi_cmset_0001?
> 
> Is it in CFI query mode, or in Read Status mode?  I have seen it be left
> in Read Status mode after a write, but never CFI query mode.

Yes, that's what I also see. That should be ok.

> 
> Leaving it in Read Status mode shouldn't have any side effects during
> runtime operation, since the MTD code expects that.  It's probably more
> efficient anyway, since the code can't be sure of what the next
> operation will be.
> 
> To solve your reset issue, you could do what you said above.  Or you can
> put the chip in Read Array mode after every write is completed (erase
> too for that matter).  That won't catch all the corner cases though.
> 
> josh
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
-- 
J.G.J. Boor                       Anton Philipsweg 1
Software Engineer                 1223 KZ Hilversum
AimSys bv                         tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum   mailto:jjboor@aimsys.nl

Re: MTD and 28F128J3A

[Stefan Stürke]

Josh Boyer wrote:
...

> Is it in CFI query mode, or in Read Status mode?  I have seen it be left
> in Read Status mode after a write, but never CFI query mode.

Sorry, you are right, the flash is in Read Status mode.

> 
> Leaving it in Read Status mode shouldn't have any side effects during
> runtime operation, since the MTD code expects that.  It's probably more
> efficient anyway, since the code can't be sure of what the next
> operation will be.

Ok, I just implemented my 'dirty fix' and it works for my hardware :-)

Thanks again for your help,
Stefan

-- 
Stefan Stürke