RE: [ECOS] FW: [ECOS] New IMMR address not recognized

["Cusson, Pascal" <pascal dot cusson at analog dot com>]

Hi Paul,
   Sorry, I forgot to mention, I commented out all printf in the two
thread program. Since I took out the initialization of the everything
related to printfs, it would work anyway. When I execute the two threads
program, it works fine (without the printfs of course). It is only when
I put something like *(unsigned int*)0xf00108c0 =0, then gdb stop at
that line and gives me a segmentation fault.

Pascal

-----Original Message-----
From: Paul Fine [mailto:pfine@delcomsys.com]
Sent: Friday, November 08, 2002 8:52 AM
To: Cusson, Pascal; ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] FW: [ECOS] New IMMR address not recognized


The two threads example spits out text on the serial port, which,
through 
the HAL, uses variables and registers which are in the memory space 
controlled by the IMMR.  The SCC registers and the buffer descriptors
are 
both in that space.

Is it the unmodified two threads code that causes the segmentation
fault, 
or is it code that you have modified?  If it is your code, what does
that 
code look like?

At 03:58 PM 11/7/2002 -0500, Cusson, Pascal wrote:
>Hi Paul,
>    First of all, thank you very much for looking into this. This must
be
>one of my last show stopper. Attached with this email are the files I
>modified. As I said before, I basically changed all appearance of
0x0470
>by 0xF000 in all three files plus the associated .h files under the
>include directory. I also commented out all bl calls meant to
initialize
>the fpga, sdram, memory, etc. All the initialization I need is done
>though my JTAG which is my SDRAM.
>
>    I also tried your last advice not to set the NHR bit. I basically
>commented the first few lines on the hal_platform_init function. That
>didn't do a thing.
>
>    The software I use at this point in time is the two threads example
>given in the eCos manual. It works fine but I cannot change anything in
>my mapped registers. I get a memory segmentation fault. However, once a
>stop it, I can modify the registers through my JTAG no problem.
>
>    The thing that is weird is that all the register configuration done
>in hal_aux.c goes fine. It is once I get in my application that I can't
>access the registers anymore. As if the mapped register were unmapped
>somehow. Could it be a memory mapping issue in eCos ?
>
>Once again, thanks for you help,
>
>Best regards,
>
>Pascal
>
>
>-----Original Message-----
>From: Paul Fine [mailto:pfine@delcomsys.com]
>Sent: Thursday, November 07, 2002 11:32 AM
>To: Cusson, Pascal; Cusson, Pascal; Patrick Doyle
>Cc: ecos-discuss@sources.redhat.com
>Subject: RE: [ECOS] New IMMR address not recognized
>
>
>I guess that I am a little confused.
>
>You boot your board using JTAG, including initializing the SDRAM and
>setting the IMMR so that the Internal Memory Mapped Registers have a
>base
>of 0xF0000000.
>
>Now I am going to start to guess what you did.
>
>You built an eCos kernel using the ts6 target (which is our custom
>board,
>which you probably don't have, but if you do, let me know).  You then
>built
>your application against the eCos kernel.  You made some changes to the
>kernel, specifically in ts6.S, which contains the assembly language
>function "hal_hardware_init".  I assume that you then load the
>application
>into SDRAM using JTAG, and step through the hal_hardware_init code
>single
>step (also using JTAG) so that you see the internal registers changing
>in
>the 0xF000xxxx memory space.
>
>You then let the code run, and at some point it crashes with a
>segmentation
>fault on trying to write to an internal memory mapped register.
>
>The hal_hardware_init function for ts6
>          1) checks the NHR bit in the HID0 to see if the IMMR and
SDRAM
>(and other stuff) needs to be initialized due to a hard reset.
>          2) If NHR is not set, then 0x04700000 is loaded to the IMMR,
>assuming that the hard reset value for the IMMR is 0x0F000000.
>          3) The NHR bit of the HID0 is set, and the rest of the
>initialization is done.
>
>If you are initializing the IMMR and SDRAM via JTAG, but not setting
the
>
>NHR bit, that could be a problem, since the init code will try to redo
>what
>you did via JTAG.  I am surprised that it gets past where the we write
>to
>the IMMR, since you moved the IMMR.
>
>At 10:10 AM 11/7/2002 -0500, Cusson, Pascal wrote:
> >Hi Paul,
> >    First I am not using the RedBoot. I am using a JTAG to boot my
>board.
> >The JTAG configures the IMMR as well as the SDRAM. I have been using
> >that configuration for about 2 months and without any problem. From
>what
> >I have tried, I cannot access any of the registers. All of them give
me
> >a signal error - > IGSIGV which display a Segmentation Fault in
> >Insight(gdb).
> >
> >   The strange thing here is that in
hal/powerpc/ts6/current/src/ts6.S
>I
> >set a few register and they all get set properly when I read them
back
> >with my JTAG. Once I get my application running, I get the
segmentation
> >fault on any attempt to read or write a mapped register.
> >
> >   One more thing, I can write at address 0x04700000 which should
give
>a
> >segmentation fault since my IMMR is at address 0xf0000000 and not
> >0x04700000 anymore. I can confirm this through my JTAG
> >
> >    The code was originally written for an IMMR at 0x04700000 but for
> >memory reason and because of my previous application, I had to move
the
> >IMMR at 0xF0000000.
> >
> >    It looks like somehow, the addresses 0xf0000000 are blocked. Is
>there
> >such a mechanism in eCos ?
> >
> >If you can think of anything, please let me know.
> >
> >Best regards,
> >
> >Pascal
> >
> >-----Original Message-----
> >From: Paul Fine [mailto:pfine@delcomsys.com]
> >Sent: Thursday, November 07, 2002 9:33 AM
> >To: Cusson, Pascal; Patrick Doyle
> >Cc: ecos-discuss@sources.redhat.com
> >Subject: Re: [ECOS] New IMMR address not recognized
> >
> >
> >Pascal,
> >
> >Is it just one specific register in the 0xF001xxxx memory space that
> >causes
> >the segmentation fault, or is it any memory address in the range?
> >
> >You can read the value of the IMMR.  For instance, at the RedBoot
> >prompt, I
> >can type
> >
> >          RedBoot> x -b 0x047101a8 -4 -l 4
> >          047101A8: 04700011
> >          RedBoot>
> >
> >The upper 16 bits (0470) tell me that the internal memory mapped
> >registers
> >are at base 0x04700000.  The lower 16 bits give version information.
> >
> >If the value of the IMMR that you read is similar to the one I am
> >showing
> >here, then I am not surprised that writing to an address in the range
> >0xF001xxxx crashes the PPC.
> >
> >How are you changing the IMMR?  Are you loading code with RedBoot?
> >
> >
> >At 03:44 PM 11/6/2002 -0500, Cusson, Pascal wrote:
> > >Hi Patrick,
> > >    I have a small question for you on the 8260 port you gave me. I
>am
> > > trying to make my IMMR 0xF0000000 instead of 0x04700000. The
reason
> >being
> > > that it is the default on my board and that my entire application
>uses
> >
> > > 0xF0000000.
> > >
> > >    So far I have modified all files containing 0x04700000 under
> > > powerpc/mpc8260 and powerpc/ts6. However, when writing one of the
> > > register at address 0xf001xxxx, I get a segmentation fault.
Meaning
>I
> >am
> > > not writing in at a valid address. However I can write at address
> > > 0x04700000 no problem. Is there something else I need to modify in
> >eCos ?
> > >
> > >Thanks for you help
> > >
> > >Pascal
> > >
> > >--
> > >Before posting, please read the FAQ:
>http://sources.redhat.com/fom/ecos
> > >and search the list archive:
>http://sources.redhat.com/ml/ecos-discuss
> >
> >Paul Fine
> >Senior Member of Technical Staff
> >Delphi Communication Systems, Inc.
>
>--
>Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
>and search the list archive: http://sources.redhat.com/ml/ecos-discuss

--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss