This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: idt mips board port question


> A patch has been submitted for for ROM configuration.

great , thank you


> The ldi files are used for the configuration tool, are
> you using this option?

i check that the ldi & h files in /include/pkgconf are the same ones
that appear in the configuration tool under memory layout : mem layout
 linker script fragment and memory layout header file
>
> Also, are you using flash in a ROM configuration?
>
yes . When i use the the binutils to dissassemble the build , i expected to
see
an address starting at 0x9fc00000 .
a romram config is also acceptable.

I am investigating  a crash that seems to occur in the /src/16c550c.c file :
after a
delay function is called , it goes in what seems to be an endless loop in
cache. Unfortunately , my logic analyser cannot see the bus activity when
cache is used. Any hints of what can cause this ?????


I am hoping the patch will help solve this problem. I applied the previously
published patch from march 10.

> For a ROMRAM configuration, ROM is really a RAM image.
>  Look at the target.ld file for memory location.  A
> simple macro is used based on the pc to determine
> which kseg the code is running from.  The copy routine
> and jump is in platform.inc in the idt79s334a/include
> directory.

what confuses me is that i expected the dissassembly to produce
some locations in flash to start the board (0x9fc00000 area) and
what i see is only locations in ram 0x80000000
The start locations are relocatable from ram to the rom area of memory
if the initialisation code uses only relative  jumps  or position
independant code ?????

thanks again ,


Henri


> Here is the macro:
> #ifdef CYG_HAL_STARTUP_ROMRAM
>
> .macro lar reg,addr
> .set noat
> move $at,ra # save ra
> la \reg,\addr # get address into register
> la ra,x\@ # get linked address of label
> sub \reg,\reg,ra # subtract it from value
> bal x\@ # branch and link to label
> nop #  to get current actual address
> x\@:
> add \reg,\reg,ra # add actual address
> move ra,$at # restore ra
> .set at
> .endm
>
> #define CYGPKG_HAL_MIPS_LAR_DEFINED
>
> #endif
>
>
>
>
> >
> Hi All,
>
> The idt79s334a platform does not have .ldi and .h
> files in the
> include/pkgconf for use in a conventional rom startup
> environment (like
> several of the other mips platform ) , where upon
> power on the code
> retrieved is from 0x9fc0_0000 cached or 0xbfc0_0000
> uncached.The .ldi file
> in the version 2.0 release and in the cvs show the rom
> area at an address in
> ram at 0x8020_0000.
>
> Is this is a scheme where  an existing monitor
> handles power up to load
> redboot at this ram address prior to relocation ????
>
> Has it been tested in the case where the ldi and h
> files are edited for
> conventional rom startup from 0x9fc0_0000 ???? It
> might be less confusing to
> put those files in the cvs since its common to expect
> rom operation to mean
> that the unit actually starts from rom when power is
> applied .
>
> A similar question applies to the romram configuration
> , where only the ram
> area is shown in the .ldi file
>
> thanks
>
> Henri
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com
>


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]