This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: problem in vrc437x/idt79s334a ROMRAM code
- From: Tim michals <tcmichals at yahoo dot com>
- To: Andy Dyer <adyer at righthandtech dot com>, ecos-discuss at sources dot redhat dot com
- Date: Tue, 19 Aug 2003 06:31:35 -0700 (PDT)
- Subject: Re: [ECOS] problem in vrc437x/idt79s334a ROMRAM code
Yes you are correct. There could be a two part copy,
also, you need to leave some more room for the
vectors, ie 0x380.
--- Andy Dyer <adyer@righthandtech.com> wrote:
> I'm trying to get redboot working in ROMRAM on my
> tx49 based target
> which doesn't have support for it. I'm looking at
> the file
>
packages/hal/mips/vrc437x/current/include/platform.inc
> for an example
> of how to do it, but it looks wrong to me. I also
> looked at the version
> for idt79s334a which is pretty much the same.
>
> This is specific to "4000" or better class mips -
> it's a bit different
> for "3000" series stuff.
>
>
> The following code snippet is responsible for
> copying the code into
> RAM:
>
>
> #if defined(CYG_HAL_STARTUP_ROMRAM)
> # Having got the RAM working, we must now relocate
> the Entire
> # ROM into it and then continue execution from RAM.
>
> la t0,reset_vector # dest addr
> lar t1,reset_vector # source addr
> la t3,__ram_data_end # end dest addr
> 1:
> lw v0,0(t1) # get word
> sw v0,0(t0) # write word
> addiu t1,t1,4
> addiu t0,t0,4
> bne t0,t3,1b
> nop
>
> la v0,2f # RAM address to go to
> jr v0
> nop
> 2:
> # We are now executing out of RAM!
>
>
> the linker script has this fragment:
>
>
> #elif defined(CYG_HAL_STARTUP_ROMRAM)
>
> /* this version for ROMRAM startup. These are
> actually a */
> /* combination of the ROM and RAM vector locations
> since the code */
> /* starts off in ROM and transfers to RAM during
> startup. */
> #define SECTION_rom_vectors(_region_, _vma_, _lma_)
> \
> .rom_vectors _vma_ : _lma_ \
> {
> \
> KEEP (*(.reset_vector))
> \
> . = ALIGN(0x100);
> \
> KEEP (*(.utlb_vector))
> \
> . = ALIGN(0x80);
> \
> KEEP(*(.other_vector))
> \
> . = ALIGN(0x800);
> \
> } > _region_ =0
>
>
>
>
> I think the problem is that the exception vectors
> are mostly
> copied to the wrong place. In mips it depends on
> the state of the
> status register boot exception vector bit (SR[BEV])
>
> Exception SR[BEV]=0
> SR[BEV]=1
>
> ColdReset, SoftReset, NMI 0xbfc0_0000
> 0xbfc0_0000
> TLB refill, EXL = 0 0x8000_0000
> 0xbfc0_0200
> XTLB refill, EXL = 0 0x8000_0080
> 0xbfc0_0280
> (X = 64 bit TLB)
> Others (common exception) 0x8000_0180
> 0xbfc0_0380
>
> (other versions of mips have some more exceptions
> like
> hardware debuggers and cache exceptions at various
> offsets
> but the base is usually 0xbfc0_0200 or 0x8000_0000,
> depending
> on the BEV bit)
>
> So I think the code above is copying the reset
> vector down to
> where the TLB refill vector should be and the TLB
> vector is at
> 0x8000_0100. The most common exception (interrupts)
> value seems
> to be different from the RAM-only version to munge
> it to 0x8000_0180
> like it should be.
>
> I think what needs to happen is a two-piece copy -
> the exception
> handlers from 0xbfc0_0200 down to 0x8000_0000 until
> end of the last
> one, and a separate copy of the rest of the text and
> data segments.
> The exception handlers currently don't reference
> themselves, so
> should be relocatable in this fashion. Maybe also a
> zero-fill
> between the end of the exception handlers and the
> start of .text.
> And then copy the start of .text to __ram_data_end.
>
> As a related problem for the ROMRAM configurations,
> it looks like
> SR[BEV] is cleared in hal_cpu_init based on the
> value of INITIAL_SR
> well before the actual exception handlers are copied
> down into RAM
> in hal_memc_init.
>
> One more problem looks to be missing handlers for
> some exceptions:
> It looks like xtlb and the cache exceptions present
> on some mips cores
> are ignored. There is no code at those vector
> locations, but the linker
> will fill with 0x00000000 which is a NOP and it
> should fall through to
> whatever is next unless the exception vector is
> greater than base +
> 0x180.
>
> Does this make sense or am I missing something??? I
> would be willing to
> make a patch for tx49 to fix this stuff, but I don't
> have IDT or Vr4300
> based systems to try it out on others.
>
> --
> Andrew Dyer | adyer@righthandtech.com
> Sr. Engineer | (630) 238-0789
> RightHand Technologies | (630) 238-0469 (fax)
> 735 N. Edgewood Ave. |
> Suite D |
> Wood Dale, IL 60191-1261 |
> USA |
>
> --
> Before posting, please read the FAQ:
> http://sources.redhat.com/fom/ecos
> and search the list archive:
> http://sources.redhat.com/ml/ecos-discuss
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.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