Reset vector of 8641

[ravindrakulkarn]

The reset vector of 8641 is mentioned as 0xFFFF0100 in the data sheet (section 2.2.6 of MPC8641DRM.pdf)

it says

the e600 cores fetch their reset vectors by performing

a burst read from effective address 0x0_FFF0_0100 and begin executing with the instruction at effective

address 0x0_FFF0_0100.

However the u-boot-2010.09 code assumes the  reset vector at 0xefff0100

See the extract of u-boot.map below.

Please explain this discrepancy in the reset vector.

Note: The HPCN board, uses default boot configuration (does not use i2c boot eeprom).

.text           0xeff00000    0x48e24

  arch/powerpc/cpu/mpc86xx/

start.o(.text)
.text          0xeff00000     0x2714 arch/powerpc/cpu/mpc86xx/start.o
                0xeff0011c                _start_of_vectors
                0xeff02648                setup_ccsrbar
                 0xeff00004                version_string
                0xeff02408                relocate_code
                0xeff023f8                in32
                0xeff02100                early_bats
                 0xeff023f0                in16r
                0xeff026c0                unlock_ram_in_cache
                0xeff023b8                in8
                0xeff02400                in32r
                0xeff023c8                out16
                 0xeff0262c                enable_ext_addr
                0xeff023e8                in16
                0xeff02208                disable_addr_trans
                0xeff02228                transfer_to_handler
                0xeff00100                _start
                0xeff023a4                dc_read
                0xeff023d8                out32
                0xeff023a8                get_pvr
                 0xeff023d0                out16r
                0xeff020ac                invalidate_bats
                0xeff023c0                out8
                0xeff01fa4                _end_of_vectors
                 0xeff023e0                out32r
                0xeff02578                trap_init
                0xeff00110                _start_warm
                0xeff021e4                clear_tlbs
                0xeff023b0                get_svr
  arch/powerpc/cpu/mpc86xx/traps.o(.text)

[scottwood]

The address that U-Boot is linked at is the address it will be running C code at, prior to relocation to RAM.  It is not the actual address that the first instructions execute at.  Those early instructions will set up a mapping at the address where flash is eventually meant to reside, and jump there.

[ravindrakulkarn]

Thanks Scoot.

May I request you some more elaboration please.

However, The first instruction to be executed must be at address

0xFFFF_0x0100 according to the data sheet.

but the map file shows it at 0xEFF0_0100, then which code will map this

address (efff00100) to the real reset vector?

or am I missing something grossly?

Also I checked the linker command line, there is no change in start

instruction ( option "-e").

On Thu, Dec 6, 2012 at 12:15 AM, Scott Wood

[scottwood]

Just because the linker thinks an instruction is at 0xeff00100 doesn't mean it won't work when the code is actually located at 0xfff00100 -- except to the extent that any addresses contained in the code will point to the wrong place, but the early asm code is careful to avoid such problems.

The "early_bats" function establishes an effective-address mapping at 0xeff00000 that points to 0xfff00000, and then the code branches to an address in that region.  Later on the flash gets physically mapped at 0xeff00000.

[ravindrakulkarn]

Hi Scott

I find that the MPC8640 is actually getting to 0xFFF00800 address as against 0xFFFF0100 mentioned in the data sheets, Any clue? help why is this difference?

I am using USB TAP from Freescale , and there is no init script and default reset configuration, no Alt boot, no EEPROM.

Thanks

[scottwood]

The reset vector in the manual is 0xfff0_0100, not 0xffff_0100.  0xfff0_0800 is the floating point unavailable vector.  Are you sure that 0xfff0_0800 is the very first thing you see executed?  Maybe you've got a floating point instruction (or bad instruction that decodes as floating point) at 0xfff0_0100?

[ravindrakulkarn]

That was good help, Scott, Thanks

On Tue, Jan 15, 2013 at 11:52 PM, Scott Wood