Hi Greg,

>> Still seems a lot like a memory setup problem.
>> Is this your own design board?
Yes we have designed our board.
This board is derived from a previous one based on a Coldfire 5307.
We 've only changed the processor (pin to pin compatible), 1.8V power supply
was anticipated.

>> Does any other software run reliably on it when fitted with the 5407?
No there's no other software running on the board.
We are trying to run the kernel under the control of gdb.

>> I would double check your SDRAM register setup on that.
The kernel is loaded via the BDM bus, the init of the SDRAM is also done
under the control of gdb.
Here is the extract concerning SDRAM init of our gdbinit file.


        #-----------------------------
        # MBAR BASE ADDRESS
        #-----------------------------
        set $mbar  = 0x10000001

        #----------------------------- 
        # RAMBAR BASE ADDRESS
        #-----------------------------
        set $rambar = 0x20000035
        set $rambar1 = 0x20000821

        #-----------------------------
        # SDRAM REGISTERS
        #-----------------------------
        set $dcr   = $mbar - 1 + 0x100
        set $dacr0 = $mbar - 1 + 0x108
        set $dmr0  = $mbar - 1 + 0x10c
        set $dacr1 = $mbar - 1 + 0x110
        set $dmr1  = $mbar - 1 + 0x114

        #-----------------------------
        # PARTICULAR CASE OF SDRAM
        # COMMAND WORDS WITCH USE
        # ADDRESS BUS AS DATA
        #-----------------------------
        set $PrechCmd  = 0x00000000
        set $ModRegCmd = 0x00001800


          # Power-Up Sequence
          set *((short*) $dcr)        = 0x8011
          set *((long*)  $dacr0)      = 0x00002324
          set *((long*)  $dmr0)       = 0x01FC0001

          # Precharge Sequence
          set *((long*)  $dacr0)      = 0x0000232C
          set *((short*)  $PrechCmd)  = 0xBABE

         # Refresh Sequence
          set *((long*)  $dacr0)      = 0x0000A324

          # Wait at least 8 auto refresh cycles occur
          printf "Another DRAM setup delay\n"

          # Mode Register Initialization Sequence
          set *((long*)  $dacr0)      = 0x0000A364
          set *((short*)  $ModRegCmd) = 0xBABE


We developped our bootloader which is written on the first sector of the
flash. This software is working correctly with the same SDRAM init written
in a crt0.S file.
We can also run the bootloader under the control of gdb, in this case the
same gdbinit file is used (see above), the soft (bootloader) is also running
correctly.
The boot loader can run a RAM test without problems. A pattern is written
and checked 100ms later.  the test covers the whole RAM.


SDRAM used is a MICRON component (MT48LC16M16A2)


What we 've notice is :
 1) All the pages are linked to the second zone (ZONE[1]) in
free_area_init_core function. i.e. page->flags > 0x10000000.
 2) When function __free_pages_ok wants to free the page (apparently the
first to be freed) this page seems to be linked to the firts zone (ZONE[0]).
i.e. page->flags = 0 !

We are not able to catch who's reseting page->flags.


Regards
Bruno


> ----- Original Message ----- 
> From: "Greg Ungerer" <[EMAIL PROTECTED]>
> To: "uClinux development list" <[email protected]>
> Sent: Tuesday, December 11, 2007 7:28 AM
> Subject: Re: [uClinux-dev] Kernel panic: BUG! while booting Coldfire 5407
>
>
> > Hi Bruno,
> >
> > Etudes RESEAUX - Site Provence wrote:
> >> I am using a 2.4.x version kernel.
> >>
> >> I have sepcified 32MB memory (CONFIG_RAM32MB=y)
> >>
> >> Concerning the Bogomips, the last traces where obtained whith a try
where
> >> the cache was disabled.
> >> When enabled it looks like this
> >>
> >>  uClinux/COLDFIRE(m5407)
> >>  COLDFIRE port done by Greg Ungerer, [EMAIL PROTECTED]
> >>  Coldfire was last reset by a hard reset.
> >>  Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
> >>  On node 0 totalpages: 8192
> >>  zone(0): 0 pages.
> >>  zone(1): 8192 pages.
> >>  zone(2): 0 pages.
> >>  Kernel command line:
> >>  Calibrating delay loop... 118.37 BogoMIPS
> >>  kernel BUG at page_alloc.c:208!
> >>  Kernel panic: BUG!
> >>  In idle task - not syncing
> >
> > Still seems a lot like a memory setup problem.
> > Is this your own design board?
> > Does any other software run reliably on it when fitted with the 5407?
> >
> > I would double check your SDRAM register setup on that.
> >
> > Regards
> > Greg
> >
> >
> >> ----- Original Message ----- 
> >> From: "Greg Ungerer" <[EMAIL PROTECTED]>
> >> To: "uClinux development list" <[email protected]>
> >> Sent: Friday, November 30, 2007 2:00 AM
> >> Subject: Re: [uClinux-dev] Kernel panic: BUG! while booting Coldfire
5407
> >>
> >>
> >>> Hi Etudes,
> >>>
> >>> Etudes RESEAUX - Site Provence wrote:
> >>>> I have 2 boards which are identical except for the processor.
> >>>> One is based on a Coldfire 5307, the second is based on a Coldfire
> >>>> 5407.
> >>>>
> >>>> I have no problem to boot the 5307 board using a kernel built for
> >>>> Coldfire 5307, but I can't boot with the 5407 board using a kernel
> >>>> built
> >>>> for Coldfire 5407.
> >>>>
> >>>> Here is the error on the console :
> >>>>
> >>>>  uClinux/COLDFIRE(m5407)
> >>>>  COLDFIRE port done by Greg Ungerer, [EMAIL PROTECTED]
> >>>> <mailto:[EMAIL PROTECTED]>
> >>>>  Coldfire was last reset by a hard reset.
> >>>>  Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
> >>>>  On node 0 totalpages: 8192
> >>>>  zone(0): 0 pages.
> >>>>  zone(1): 8192 pages.
> >>>>  zone(2): 0 pages.
> >>>>  Kernel command line:
> >>>>  Calibrating delay loop... 2.11 BogoMIPS
> >>>>  kernel BUG at page_alloc.c:208!
> >>>>  Kernel panic: BUG!
> >>>>  In idle task - not syncing
> >>>>
> >>>>
> >>>> I try this, with cache enabled and disabled, it always failed on line
> >>>> 208 of pages_alloc.c
> >>>>
> >>>> The processor seems top be correctly set, my (own) boot loader works
> >> well.
> >>>> I am using the uClinux-dist-20070130 distro.
> >>>> I am using the m68k-uclinux-tools-20061214 tool-chain.
> >>> Which kernel version is this, 2.4.x or 2.6.x?
> >>>
> >>> It sort of seems a little like a memory problem.
> >>> What memory size have you specified?
> >>> Or did you select to auto-size RAM?
> >>>
> >>> The Bogomips number looks completely wrong too.
> >>> Something odd there.
> >>>
> >>> Regards
> >>> Greg
> >>>
> >>>
>
>>> ------------------------------------------------------------------------
> >>> 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
> >>> [email protected]
> >>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> >>> This message was resent by [email protected]
> >>> To unsubscribe see:
> >>> http://mailman.uclinux.org/mailman/options/uclinux-dev
> >>>
> >>
> >> _______________________________________________
> >> uClinux-dev mailing list
> >> [email protected]
> >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> >> This message was resent by [email protected]
> >> 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
> > [email protected]
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by [email protected]
> > To unsubscribe see:
> > http://mailman.uclinux.org/mailman/options/uclinux-dev
> >
> >
>
>
>

_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Reply via email to