Greg,
I tried a patch in kernel/sched.c, __wake_up_common:
...
if( curr->func == NULL || (curr->func(curr, mode, sync, key) &&
(flags & WQ_FLAG_EXCLUSIVE) &&
!--nr_exclusive) ) {
break;
}
...
Now jffs2 can be initialized on our flash S29GL064AR4. Also a test file
remains
persistent after re-power our system.
I this patch right? My feeling is that something should be done in mtd!
Regards
Teun Grinwis
> Van: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Teun Grinwis
> Verzonden: dinsdag 15 mei 2007 8:53
> Aan: uClinux development list
> Onderwerp: RE: [uClinux-dev] RE: jffs2 on MCF5208 custom board
>
>
> Hi Greg,
> It is no HW fault, since primary I did extended tests on all memory r/w.
> Also dBUG boot sw is running correctly.
>
> After some further investigation, the real problem is a NULL ptr function
> call, see below:
>
> - in cfi_cmdset_0002.c, do_erase_oneblock
> put_chip( map, chip, adr ); is called.
>
> - in cfi_cmdset_0002.c, put_chip
> wake_up( &chip->wq ); is called
>
> - in kernel/sched.c, __wake_up
> __wake_up_common( q, mode, nr_exclusive, 0, key ) is called
>
> - in kernel/sched.c, __wake_up_common, here ERROR, func == NULL
>
> static void __wake_up_common(wait_queue_head_t *q, unsigned int mode,
> int nr_exclusive, int sync, void *key)
> {
> struct list_head *tmp, *next;
>
> list_for_each_safe(tmp, next, &q->task_list) {
> wait_queue_t *curr;;
> unsigned flags;
> curr = list_entry(tmp, wait_queue_t, task_list);
> flags = curr->flags;
> if (curr->func(curr, mode, sync, key) &&
>
> ^^^^^^^^^^ ERROR, curr->func = NULL
>
> (flags & WQ_FLAG_EXCLUSIVE) &&
> !--nr_exclusive)
> break;
> }
> }
> ------------------------------------------------
> Why is reason curr->func = NULL? I do not have knowledge about mtd.
> ------------------------------------------------
> Tx for info.
>
> Regards,
> Teun
> > -----Oorspronkelijk bericht-----
> > Van: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Greg Ungerer
> > Verzonden: dinsdag 15 mei 2007 3:31
> > Aan: uClinux development list
> > Onderwerp: Re: [uClinux-dev] RE: jffs2 on MCF5208 custom board
> >
> >
> > Hi Teun,
> >
> > Teun Grinwis wrote:
> > > Late reply, went away some weeks,
> > >
> > > I currently do not run apps XIP.
> > >
> > > Our custom board concerning flash, is equal design as on Intec
> > 5208EVB with
> > > the diff that the flash is S29GL064AR4 iso AM29BDD160G,
> >
> > Could this be a hardware fault?
> > Has the hardware been validated?
> >
> > Regards
> > Greg
> >
> >
> >
> > > My MTD partitions are as follows (btw i did not change flash
> > name string):
> > >
> > > ------------------------
> > > Am29BDD160G 2.5v flash device (2MB): Found 1 x16 devices at 0x0
> > in 16-bit
> > > bank
> > > Amd/Fujitsu Extended Query Table at 0x0040
> > > cfi_send_gen_cmd():,40 cmd=98 addr=00000055 base=00000000 build
> > > addr=000000aa cm
> > > d_val=00000008
> > > cfi_send_gen_cmd():,41 cmd=f0 addr=00000000 base=00000000 build
> > > addr=00000000 cm
> > > d_val=00000040
> > > cfi_send_gen_cmd():,42 cmd=ff addr=00000000 base=00000000 build
> > > addr=00000000 cm
> > > d_val=00000040
> > > Using buffer write method
> > > number of CFI chips: 1
> > > cfi_cmdset_0002: Disabling erase-suspend-program due to code
> brokenness.
> > >
> > > Creating 3 MTD partitions on "Am29BDD160G 2.5v flash device (2MB)":
> > >
> > > 0x00000000-0x00040000 : "dBUG (256K)"
> > > mtd: Giving out device 2 to dBUG (256K)
> > >
> > > 0x00040000-0x000c0000 : "User FS (512K)"
> > > mtd: Giving out device 3 to User FS (512K)
> > >
> > > 0x000c0000-0x00200000 : "Kernel + RootFS (1280K)"
> > > mtd: Giving out device 4 to Kernel + RootFS (1280K)
> > > m520xevb ram probe(0x40150020,de000,4): de000 at 40150020
> > >
> > > m520xevb ram probe(0x40150020,de000,4): de000 at 40150020
> > > do_map_probe(): name=map_ram <5>Creating 1 MTD partitions on "RAM":
> > > 0x00000000-0x000de000 : "Romfs"
> > > mtd: Giving out device 5 to Romfs
> > > init_m520x: Root filesystem maj:31 mtdblock:5
> > > ----------------------------
> > >
> > > I mount jffs2 on "User FS", addresses 0x40000 - 0xc0000
> > >
> > > I can run my image successful on the EVB see attached file
> > Log_uclinux_evb.
> > >
> > > I started all from a clean flash, erase flash, program dBUG, dn
> > image.bin,
> > > exec image.
> > >
> > > When starting on EVB, jffs2 is initializing "User FS" by MTD
> > > do_erase_oneblock,
> > > MTD do_write_oneword(s) 0x..0 - 0x..a for all sectors in "User
> > FS", startup
> > > successful.
> > >
> > > When starting on custom board *** ILLEGAL INSTRUCTION ***
> > occurs after the
> > > first
> > > MTD do_erase_oneblock(), see attached file
> Log_uclinux_ads4010, startup
> > > unsuccessful.
> > >
> > > It seems that the error has something todo with (erase) timing
> > ?? since in
> > > call trace:
> > > ...
> > > BUG: pdflush/9, lock held at task exit time!
> > > [403b6446] {alloc_super}
> > > .. held by: pdflush: 9 [402b2330, 115]
> > > ... acquired at:
> > >
> > > After further investigation it seems that in
> > > cfi_cmdset_0002.c:do_erase_oneblock,
> > > the code execution does not reach: spin_unlock(chip->mutex).
> > >
> > > Any suggestions, are welcome.
> > >
> > > Thanks in advance,
> > > Teun Grinwis
> > >
> > >
> > >> -----Oorspronkelijk bericht-----
> > >> Van: Teun Grinwis [mailto:[EMAIL PROTECTED]
> > >> Verzonden: donderdag 10 mei 2007 11:15
> > >> Aan: Teun
> > >> Onderwerp: jffs2 on MCF5208 custom board
> > >>
> > >>
> > >>
> > >> Hi Teun,
> > >>
> > >> Teun Grinwis wrote:
> > >>> Hello all,
> > >>> Can someone give hint where to start debug searching ??
> > >>>
> > >>> I use distribution 20060511 2.16.16-uc0 on custom MCF 5208 board.
> > >>> With flash, S29GL064AR4. Debug for mtd, jffs2 set to noisy.
> > >>>
> > >>> When I mount a mtdblock on jffs2 I got the following error:
> > >>>
> > >>> See below.
> > >>> Command: mount -t jffs2 /dev/mtdblock3 /mnt
> > >>> Command:
> > >>> Command:
> > >>> Execution Finished, Exiting
> > >>> mtdblock: read on "Romfs" at 0x3d400, size 0x200
> > >>> ......
> > >> Your root filesystem isn't also on the same flash
> > >> as the JFFS2 you are trying to mount is it?
> > >>
> > >> If you where running apps XIP then this would be a problem.
> > >>
> > >> Regards
> > >> Greg
> > >>
> > >>
> > ------------------------------------------------------------------------
> > >>
> > >> _______________________________________________
> > >> uClinux-dev mailing list
> > >> uClinux-dev@uclinux.org
> > >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > >> This message was resent by uclinux-dev@uclinux.org
> > >> To unsubscribe see:
> > >> http://mailman.uclinux.org/mailman/options/uclinux-dev
> >
> > --
> > ------------------------------------------------------------------------
> > Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
> > Secure Computing Corporation PHONE: +61 7 3435 2888
> > 825 Stanley St, FAX: +61 7 3891 3630
> > Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev@uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev@uclinux.org
> > To unsubscribe see:
> > http://mailman.uclinux.org/mailman/options/uclinux-dev
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
