Re: Launch(UINT32 pFunc) function at startup.s

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Where does your OALStartUp call come from?
Can you confirm that the function is really called?


"sathiyakeerthi" <sathiyakeerthi@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A58DCEB5-89C9-4457-A0FA-C9FBF2A35E3B@xxxxxxxxxxxxxxxx
Hi ,
Thanks for you deatiled reply.now the problem is not Jump to the physical
launch address. because the LEDs are not glowing inside the OAL startup
module. and How can i find that i am succesfully jumb to kernelstart ?
here i have given the startup.s file.. please go through this file and
suggest me.


File: startup.s
;
; Kernel startup routine for the Intel Mainstone II board.
;
;------------------------------------------------------------------------------
INCLUDE kxarm.h
INCLUDE bulverde.inc
INCLUDE sandgateii.inc
INCLUDE xlli_Bulverde_defs.inc


IMPORT KernelStart

TEXTAREA

;------------------------------------------------------------------------


; Include memory configuration file with g_oalAddressTable
;
INCLUDE oemaddrtab_cfg.inc

;-------------------------------------------------------------------------------
;
; OALStartUp: OEM OAL startup code.
;
; Inputs: None.
;
; On return: N/A.
;
; Register used: r0
;
;-------------------------------------------------------------------------------
;
ALIGN
LEAF_ENTRY OALStartUp

; Initialize the hex LEDs on the Mainstone II board. These use GPIOs
which were
; configured in the OALXScaleSetFrequencies callback during clock
initialization.
;
bl Init_HexLEDs

; Compute the OEMAddressTable's physical address and
; load it into r0. KernelStart expects r0 to contain
; the physical address of this table. The MMU isn't
; turned on until well into KernelStart.
;
add r0, pc, #g_oalAddressTable - (. + 8)
mov r11, r0
b KernelStart
nop
nop
nop
nop
nop
nop

STALL
b STALL ; Spin forever.


;-------------------------------------------------------------------------------
;
; Init_HexLEDs: Initializes the Mainstone II board logic to enable the hex
LEDs.
;
; Inputs: None.
;
; On return: N/A.
;
; Register used: r0-r3
;
;-------------------------------------------------------------------------------
;
ALIGN
Init_HexLEDs

;;;;;;;;;;;;;;;;Glow all led106;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
ldr r4,=0x40E00000
mov r1,#0x1E00
str r1, [r4,#0x124]

mov r1,#0x1E00
str r1, [r4,#0x10c]

mov r1,#0x1E00
str r1, [r4,#0x118]


;;;;;;;;;;;;;;;;;;;;;END;;;;;;;;;;;;;;;;;;;;;;;;;;;;SATHIYA

IF Interworking :LOR: Thumbing
bx lr
ELSE
mov pc, lr ; Return to caller.
ENDIF



;-------------------------------------------------------------------------------
;-------------------------------------------------------------------------------

LTORG ; insert a literal pool here.

;
; TURN_ON_BTB - Enables the Branch Target Buffer
;
; Turn on the BTB via cp15.1[11] - Uses r0
;
;
LEAF_ENTRY TURN_ON_BTB

mcr p15, 0, r0, c7, c5, 0 ; flush the icache & BTB
mrc p15, 0, r0, c1, c0, 0
orr r0, r0, #0x800
mcr p15, 0, r0, c1, c0, 0

IF Interworking :LOR: Thumbing
bx lr
ELSE
mov pc, lr ; return
ENDIF


END

;------------------------------------------------------------------------------



"voidcoder" wrote:

Basically the flow looks like this:

1. Bootloader jumps to !OS! StartUp function. Note in some
BSPs the same StartUp code is shared between the bootoader
and OS startup code. In that case the flow is controled
using preprocessor conditional statements or just simple
PC address checking.

2. StartUp function turns off MMU and caches (if needed).

3. StartUp function performs some additional configuration,
eg. default I/O configuration, default core clock and voltage,
default memory controller settings, switching CPU to supervisor
mode, etc etc etc. This part is platform specific.

Note on some platforms the same StartUp function handles
all sort of resets, including "resume" etc. So you may find
some conditional branching here, depending on the
actual reset reason ...

4. StartUp function jumps to kernel initialization function
KernelStart. For ARM based devices this function takes
one 32-bit parameter: pointer to OAMAddressTable,
passed via R0 register. Something like this:

IMPORT KernelStart

add r0, pc, #OEMAddressTable - (. + 8)
b KernelStart

5. Kernel initializes the first level pages and turns on MMU
and caches.

6. Kernel configures stacks for each mode as it must be prepared
to handle interrupts once you turn the interrupts on in your
OEMInit().

7. Kernel calls OEMInitDebugSerial() function to give you a
chance to initialize the debug serial port.

8. Kernel calls OEMInit() function, where you normally perform
the following actions:

- Perform any sort of hardware initialization, that can not be
handled later by the device drivers or just needed at earlier
boot phase.

- Configure the system timer.

- Initialize KITL connection.

- Anything else (platform specific)

- Configure the interrupt controller, setup interrupt mapping tables,
and finally, unmask system tick interrupt.

- return the control to the kernel.


"sathiyakeerthi" <sathiyakeerthi@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:2455CD3B-8676-4B59-B546-98E56E0C7EEC@xxxxxxxxxxxxxxxx
Greatttt, Now LED can glow in Launch function. Thanks for you help. I need
more help regarding launch the image.now i can understand that i am inside
the launch function. ie.
please explain ,what will happen after this launch function ? from where
the OAL startup function was called? (There are 2 OAL startup functions in
OAL directry and eboot directry, so i confused)
i feel till now not Jump to the physical launch address. please let me
know
solution.


thanks
sathiya.

"Voidcoder" wrote:

Well, your address seems to be ok. But I think MMU is still
ON when you jump to Launch() function. Are you sure that
you can access MAINSTONEII_GPIO_HIGH::0x40E00000
(!physical address!) at this point? Note this is only possible
if you have a corresponding virtual memory mapping.

My guess is that CPU registers are mapped to a different
location, at least your OEM address table shows:

DCD 0x84500000, 0x40000000, 32 ; Memory-mapped registers

So your MAINSTONEII_GPIO_HIGH (Virtual Cached) =
0x84500000 + 0x00E00000 = 0x85300000

Normally virtual memory is configured as follow:

0x80000000 - 0x9FFFFFFF -> CACHED
0xA0000000 - 0xBFFFFFFF -> UNCACHED

In order to convert your address to uncached you have to
set "uncached" bit 0x20000000.

MAINSTONEII_GPIO_HIGH (Virtual Uncached) =
Virtual Cached + 0x20000000 =
0x85300000 + 0x20000000 =
0xA5300000


Your led blinking code at this point
(with MMU turned ON):

;;;;;;;;;;;;;;;;Glow all led;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
ldr r4,=0xA5300000 ; (Virtual Uncached)
mov r1,#0x1E00
str r1, [r4,#0x124]

mov r1,#0x1E00
str r1, [r4,#0x10c]

mov r1,#0x1E00
str r1, [r4,#0x118]



"sathiyakeerthi" <sathiyakeerthi@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:BFF9B708-ADB4-4AC9-8CEE-68E91653C54A@xxxxxxxxxxxxxxxx

Hello Mr. Voice coder,

Thanks. As your Guidance I have checked the startup address in
Kern.map,
kernkitl.map, kernkitl.map, kernkitlprof.map.

0001:00000000 StartUp 00011000
oal_startup_pxa27x:startup.obj


My entry point address is 0x80101000(physical 0xA0101000)

My led program is working correctly with another functions in
startup.s,
but not with launch () function.

MAINSTONEII_GPIO_HIGH EQU 0x40E00000

I am getting the given below in my hyperterminal.
.
.
.
.
ROMHDR at Address 80100044h
Download successful!
Jumping to image at 0x80101000 (physical 0xA0101000)...
!OEMEthGetFrame
Got EDBG_CMD_JUMPIMG
Got EDBG_CMD_CONFIG, flags:0x0000000F

here stoped(nothing happend after this)<<<


Here i have given config.bib and oemaddress table.
config.bib
-----------
MEMORY

IF IMGFLASH!

; Name Start Size Type
; ------- -------- -------- ----
RSVD 80000000 000FF000 RESERVED
ARGS 800FF000 00001000 RESERVED
NK 80100000 03000000 RAMIMAGE
RAM 83100000 00F00000 RAM
ENDIF

IF IMGFLASH

RSVD 80000000 000FF000 RESERVED
ARGS 800FF000 00001000 RESERVED
NK 86600000 03000000 RAMIMAGE
RAM 80100000 03F00000 RAM
ENDIF
; Reserve ZBANK virtual block (No physical memory
; is required to back this virtual range).
;
ZBANK 96500000 00100000 RESERVED


CONFIG

IF IMGFLASH !
AUTOSIZE=ON
ENDIF

KERNELFIXUPS=ON

; @CESYSGEN IF !NK_NKNOCOMP
COMPRESSION=ON
; @CESYSGEN ENDIF !NK_NKNOCOMP
; @CESYSGEN IF NK_NKNOCOMP
COMPRESSION=OFF
; @CESYSGEN ENDIF NK_NKNOCOMP

IF IMGPROFILER
PROFILE=ON
ELSE
PROFILE=OFF
ENDIF

;
; ROMFLAGS is a bitmask of options for the kernel
; ROMFLAGS 0x0001 Disallow Paging
; ROMFLAGS 0x0002 Not all KMode
; ROMFLAGS 0x0010 Trust Module only
;
IF IMGTRUSTROMONLY
IF IMGNOTALLKMODE
ROMFLAGS=12
ELSE
ROMFLAGS=10
ENDIF
ELSE
IF IMGNOTALLKMODE
ROMFLAGS=02
ELSE
ROMFLAGS=00
ENDIF
ENDIF

g_oalAddressTable
-------------------------
DCD 0x80000000, 0xA0000000, 64 ; SANDGATEII: SDRAM
(64MB).
DCD 0x84000000, 0x5C000000, 1 ; InternalSRAM
DCD 0x84100000, 0x58000000, 1 ; Internal memory PM
registers.
DCD 0x84200000, 0x4C000000, 1 ; USB host controller.
DCD 0x84300000, 0x48000000, 1 ; Memory controller.
DCD 0x84400000, 0x44000000, 1 ; LCD controller.
DCD 0x84500000, 0x40000000, 32 ; Memory-mapped
registers
DCD 0x88500000, 0x0C000000, 1 ; SANDGATEII: Ethernet
controller.
DCD 0x88600000, 0x04000000, 32 ; Secondary flash
(32MB).
DCD 0x8A600000, 0x00000000, 1 ; nCS0: Boot Flash
(64MB).
DCD 0x00000000, 0x00000000, 0 ; end of table









.

Relevant Pages

  • [PATCH -mm] kexec jump -v9
    ... Jumping between the original kernel and the kexeced kernel. ... Backup/restore memory used by both the original kernel and the ... of original system via ordinary kexec load then jump back. ... The following user-space tools can be used with kexec jump: ...
    (Linux-Kernel)
  • [PATCH 1/3 -mm] kexec based hibernation -v6: kexec jump
    ... This patch implements the functionality of jumping between the kexeced ... kernel and the original kernel. ... A jump back protocol for kexec is defined and documented. ... extern asmlinkage long compat_sys_kexec_load(unsigned long entry, ...
    (Linux-Kernel)
  • [PATCH 1/3 -mm] kexec jump -v8 : kexec jump basic
    ... This patch implements the functionality of jumping between the kexeced ... kernel and the original kernel. ... A jump back protocol for kexec is defined and documented. ... extern asmlinkage long compat_sys_kexec_load(unsigned long entry, ...
    (Linux-Kernel)
  • [PATCH 1/4 -mm] kexec based hibernation -v7 : kexec jump
    ... This patch implements the functionality of jumping between the kexeced ... kernel and the original kernel. ... A jump back protocol for kexec is defined and documented. ... extern asmlinkage long compat_sys_kexec_load(unsigned long entry, ...
    (Linux-Kernel)
  • [PATCH 1/2 -mm] kexec based hibernation -v5: kexec jump
    ... This patch implements the functionality of jumping between the kexeced ... kernel and the original kernel. ... A jump back protocol is defined and documented. ... void machine_kexec_cleanup ...
    (Linux-Kernel)