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: 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


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