RAMDISK problem

[Joao Vicente]

Hi Gerald

> Dumb questions:
> * What memory address is it writing to on the 37th write when
> it crashes?

My problem is that I dont really know what address the core is trying to write to when the exception occurs.
As I mentioned in the previous message, the write() calls _syscall3() macro which will perform the write operation, but early  in that macro the assembly 'sc' instruction is called.
As I cannot step through 'sc', I cannot go further on investigating at what write access the exception occurs.
My question is then:

How do I even find out what is the start address of the file associated with the file descritor?

> * Can you read and write that memory from the command line?
> * If you zero the memory before doing the load, what is in
> that memory area
>   a) Before it crashes (set a breakpoint after say 30 writes)
>   b) After it crashes?
> * Is the memory area close to a power-of-two address -- could you
>     have a memory map problem where you think you have x Kbytes but
>     the hardware/MMU is only properly decoding x/2 Kbytes or
> x/4 Kbytes?
>
> Given the repeatability, this sounds like a hardware problem
> or a software configuration problem (loading over top of
> important information like the stack or the currently
> executing program or off the end of real memory, off the end
> of the memory that is validly mapped via the BATs, etc.).
>
> gvb

Best regards

Joao Vicente



>
>
> > -----Original Message-----
> > From: Joao Vicente [mailto:joao.vicente at spectel.com]
> > Sent: Wednesday, November 19, 2003 2:13 PM
> > To: Wolfgang Denk
> > Cc: linuxppc-embedded at lists.linuxppc.org
> > Subject: RE: RAMDISK problem
> >
> >
> >
> > Hi
> >
> > I have gone through the SDRAM initialisation, and the init
> > sequence, on u-boot, and I dont seem to find any discrepancies.
> > I am using a Micron MTLSDT464HG-10EC3 DIMM, and I have it
> > initialised as follows.
> >
> > #define CFG_BR3_PRELIM  ((CFG_SDRAM_BASE & BRx_BA_MSK)  |\
> > 			 BRx_PS_64                      |\
> > 			 BRx_MS_SDRAM_P                 |\
> > 			 BRx_V)
> >
> > #define CFG_OR3_PRELIM  ((~(CFG_GLOBAL_SDRAM_LIMIT-1) &
> > ORxS_SDAM_MSK) |\
> >       ORxS_PMSEL                     |\
> >       ORxS_BPD_4                     |\
> >       ORxS_ROWST_PBI0_A9             |\
> >       ORxS_NUMR_12)
> >
> > #define CFG_PSDMR_PRELIM (PSDMR_BSMA_A14_A16  |\
> >       PSDMR_SDA10_PBI0_A9               |\
> >       PSDMR_RFRC_3_CLK                  |\
> >       PSDMR_PRETOACT_1W                 |\
> >       PSDMR_ACTTORW_1W                  |\
> >       PSDMR_LDOTOPRE_1C                 |\
> >       PSDMR_WRC_2C                      |\
> >       PSDMR_CL_2)
> >
> > On the SDRAM init sequence
> >
> > 	*sdmr_ptr = sdmr | PSDMR_OP_PREA;
> > 	*base = c;
> >
> > 	*sdmr_ptr = sdmr | PSDMR_OP_CBRR;
> > 	for (i = 0; i < 8; i++)
> > 		*base = c;
> >
> > 	*sdmr_ptr = sdmr | PSDMR_OP_MRW;
> > 	*(base + CFG_MRS_OFFS) = c;	/* setting MR on
> > address lines */
> >
> > 	*sdmr_ptr = sdmr | PSDMR_OP_NORM | PSDMR_RFEN;
> > 	*base = c
> >
> > I am setting the Mode Register Set Command to
> > #define CFG_MRS_OFFS	0x00000110
> >
> > which sets:
> > Programmable burst mode
> > Burst Length = 4
> > Burst Type = Sequential (also tried interleaved)
> > CAS latency = 2
> >
> > I have also confirmed that the uP is (Write) bursting from
> > the first time write() is called (and even before that) by
> > measuring the pulse width on WEx, verifying that it's pulse
> > is 4x the width of a normal write sequence.
> >
> > I have also debugged further, and I got much closer to the
> > exception point.
> >
> > crd_load() 			(from ./init/do_mounts.c)
> > |_ gunzip()
> >    |_ inflate()
> >       |_ inflate_block()
> >          |_ inflate_dynamic()
> >             |_ inflate_codes()
> >                |_ flush_output()
> >                   |_ flush_window()
> >                      |_write(crd_outfd, window, outcnt)
> >
> > The last function call before the exception seems to be
> > writing a decompressed 32k'outcount' chunk of data pointed by
> >  'window' onto a targey file specified by the crd_outfd file
> > descriptor.
> >
> > Notice the system ALLWAYS crashes after the 37th time the
> > write() function is called.
> > This also points more onto a software/configuration fault
> > than a burst problem with SDRAM (correct me if I am wrong)
> >
> > Another problem is that write() function will invoke
> > static inline _syscall3(int,write,int,fd,const char
> *,buf,off_t,count)
> >
> > Early in this call the assembly 'sc' instruction will be
> > executed which prevents me from stepping through the call,
> > and  finding out exactly at what point the exception occurs.
> >
> > I would appeciate suggestions onto carrying out debugging
> > from this point, or any other suggestions on how to fix the
>  problem.
> >
> > Thanks in advance
> >
> > Joao Vicente
> >
> > > -----Original Message-----
> > > From: Wolfgang Denk [mailto:wd at denx.de]
> > > Sent: Wednesday, November 12, 2003 7:46 PM
> > > To: Joao Vicente
> > > Cc: linuxppc-embedded at lists.linuxppc.org
> > > Subject: Re: RAMDISK problem
> > >
> > >
> > > Dear Joao,
> > >
> > > in message
> > > <DEF39A0710293E489D45B10E06645CBD026719AB at dub-msx1.spectelcorp
> > > .com> you wrote:
> > > >
> > > > The SDRAM parameters used for initialisation have been
> > > fully verified
> > >
> > > Parameters is one thing, the init sequence is  another
> > story.  Boith
> > > are  required,  or you will see strange crashes as soon as
> > the system
> > > starts using burst mode heavily.
> > >
> > > > with this board, as we have used them with another RTOS,
> > without any
> > > > problem.
> > >
> > > That does not mean anything. Really. We have seen boards
> > that used to
> > > run pSOS+ for years without problem, but would crash
> > reliably  under
> > > Linux. The problems went away after fixing the RAM initialization.
> > >
> > > Your problem is a FAQ on the PPCboot / U-Boot mailing lists.
> > >
> > > > Aditionaly I ran the u-boot mtest utility on sections of
> > the RAM to
> > > > ensure the configuration was good.
> > >
> > > Again, that doesn't mean anything, as this test performs
> > simple  read
> > > / write cycles. It will not cause any accesses in burst mode.
> > >
> > > > I believe that rules out bad SDRAM configuration.
> > >
> > > I disagree. I've seen this too many times before.
> > >
> > > > I thought that could give me an idea if inflate was writing
> > > outside the
> > > > valid
> > > > virtual address range.
> > >
> > > I think you're on the wrong track. But I may be wrong, of course.
> > >
> > > Best regards,
> > >
> > > Wolfgang Denk
> > >
> > > --
> > > Software Engineering:  Embedded and Realtime Systems,
> > Embedded Linux
> > > Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email:
> > wd at denx.de
> > > "Just Say No."   - Nancy Reagan
> > > "No."            - Ronald Reagan
> > >
> >
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/