Re: [ECOS] Porting to AT91 - problems with ARM/vectors.S

Re: [ECOS] Porting to AT91 - problems with ARM/vectors.S

[Andreas Bürgel]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

Gary Thomas wrote:

> > If I exchange following instruction
> >> ldr     pc,.reset_vector                // 0x00
> > with
> >> b reset_vector
> > everything works fine even without any comment-signs before vectors.S
> > stuff.
> > I don't understand _why_ the original load-instruction doesn't work in
> > my case but it's a fact. (Mulder? Scully? ...)
> 
> Look closely at the definition of .reset_vector

I do so, but hey - where are my glasses?
The .text-section starts at 0x1000060 and even this word (0x1000060) is
stored at address 0x1000020 (aka .reset_vector). I think that's the
problem. After the reset the ROM starts at 0x0, so you have to jump to
the physical (= logical) address 0x0000060 (not 0x1000060!) to enter
PLATFORM_SETUP1. This is the reason why "b reset_vector" works, because
it jumps _relative_.

> Did you define "CYGHWR_HAL_ARM_HAS_MMU" by any chance?

"CYGHWR_HAL_ARM_HAS_MMU" is definitly not defined, nowwhere. But if I
define it,
0x0000080 - I wonder why - is stored at 0x1000020 which means a jump
somewhere right into my PLATFORM_SETUP1 but _not_ the beginning.


-- 
--------------------------------------------------
Andreas Bürgel   Software Engineer
ab@genologic.de  GenoLogic GmbH, Dortmund, Germany

[ECOS] Porting to AT91 - problems with ARM/vectors.S

[Andreas Bürgel]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

Hi,

now I'm able to substantiate my problem. If I modify the beginning of
vectors.S as following (replacing some instructions with NOPs)
PLATFORM_SETUP1 - and some of the following code - gets executed.

.code	32
.section ".vectors","ax"
.global	__exception_handlers
__exception_handlers:
ldr	pc,.reset_vector		// 0x00
ldr	pc,.undefined_instruction	// 0x04
ldr	pc,.software_interrupt		// 0x08 start && software int
//ldr	pc,.abort_prefetch		// 0x0C
nop;
//ldr	pc,.abort_data			// 0x10
nop;
.word	0				// unused
//ldr	pc,.IRQ				// 0x18
//ldr	pc,.FIQ				// 0x1C
nop; nop;

// The layout of these pointers should match the vector table above
since
// they are copied in pairs.
	.global	vectors
vectors:
UNMAPPED_PTR(reset_vector)			// 0x20
PTR(undefined_instruction)			// 0x24
PTR(software_interrupt)				// 0x28
PTR(abort_prefetch)				// 0x2C
//PTR(abort_data)					// 0x30
nop;
.word	0				// 0x34
PTR(IRQ)					// 0x38
PTR(FIQ)					// 0x3c
PTR(start) // This is copied to 0x28 for bootup // 0x40
	   // location 0x40 is used for storing DRAM size if known
	   // for some platforms.
// Other vectors
.balign 16      // Should be at 0x50
.balign 32

.text	
// Startup code which will get the machine into supervisor mode
.global	reset_vector
.type	reset_vector,function
reset_vector:
...

As you can see I had to uncomment ldr pc,.{abort_prefetch, abort_data,
IRQ, FIQ}.
If I leave any of them untouched, PLATFORM_SETUP1 is never reached.
Using the CVS-version of vectors.S doesn't help much.
BTW, why aren't the cdl-files included in the CVS-tree?
 
--------------------------------------------------
Andreas Bürgel   Software Engineer
ab@genologic.de  GenoLogic GmbH, Dortmund, Germany