Re: eboot.bib question



I think that there is something wrong with that code. I think that
OALPAtoVA uses global variable(s) which have not been set up yet. You need
to call KernelRelocate first. Also do you have g_oalAddressTable defined
correctly?



--
Bruce Eitman (eMVP)
Senior Engineer
beitman AT applieddata DOT net

Applied Data Systems
www.applieddata.net
An ISO 9001:2000 Registered Company
Microsoft WEP Gold-level Member

"Alli Dem" <Alli.dem@xxxxxxxxx> wrote in message
news:%23F$8DYxFIHA.2372@xxxxxxxxxxxxxxxxxxxxxxx
Hi,
last eboot.bib is like this.
RAM 80000000 00001000 RAM
EBOOT 80002000 00008000 RAMIMAGE

CONFIG
BOOTJUMP=NONE
AUTOSIZE=OFF
COMPRESSION=OFF
PROFILE=OFF
KERNELFIXUPS=ON
ROMFLAGS=0
ROMSTART=80002000
ROMSIZE=8000
ROMWIDTH=32

i made a lot of checks and make all inits again. StartUp jumps to
OALStartUp and it jumps to main.c but it resets at main.
void _main(void)
{
volatile BULVERDE_GPIO_REG *pGPIO_REGS;
pGPIO_REGS = (volatile BULVERDE_GPIO_REG
*)OALPAtoVA(BULVERDE_BASE_REG_PA_GPIO, FALSE); //---> resets here
pGPIO_REGS->GPSR0 |= ( XLLP_GPIO_CIF_DD7 | XLLP_GPIO_SSPCLK2);
}
MMU is on.

i create stack on StartUp before jumping to OalStartUp
ldr r0, =0xA0030000
ldr r1, =10000
add sp, r0, r1

is there something wrong with this code.

Thanks





"Dean Ramsier" <ramsiernospam@xxxxxxxxxx> wrote in message
news:O5Q4COwFIHA.4476@xxxxxxxxxxxxxxxxxxxxxxx
You have no free RAM, which is different from no RAM. You probably are
using RAM in the section between 80000000 and 80001000. The bootloader
doesn't likely make use of any free RAM so that shouldn't be a problem.

However, the addresses look wrong. I don't have your eboot.bib
available,
but it appears from the log that the addresses might not be 64K aligned.
Please make sure that your RAM section and your RAMIMAGE section are
aligned on 64K boundaries. This is definitely a problem for OS builds,
not sure if it is for bootloader or not. But you need to be safe and
align them at 64K.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"JSS" <jsilengo@xxxxxxxxx> wrote in message
news:1193261378.660044.147790@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Is it ok that RAM section has zero length? I mean from log file:

"Physical Start Address: 80001000
Physical End Address: 80005018
Start RAM: 80000000
Start of free RAM: 80001000
End of RAM: 80001000 "

It seems that bib file has something wrong, doesnt it?

JSS

On Oct 22, 11:58 am, "Alli Dem" <Alli....@xxxxxxxxx> wrote:
it is 16 KB

Warning: Record starting at fffff040 is outside of rom range,
skipping...
Warning: Record starting at fffff048 is outside of rom range,
skipping...
output.txt
Copying C:\WINCE500\platform\TEST001\target\ARMV4I\retail\eboot.exe to
C:\WINCE500\platform\TEST001\target\ARMV4I\retail\nk.exe for debugger
Found pTOC at 0000115c
No imports for nk.exe
Processing eboot

MODULES Section
Module Section Start Length psize vsize Filler
---------------------- -------- --------- ------- ------- ------- ------
nk.exe .text 80002000 4096 2560 2464
o32_rva=00001000
nk.exe text 80003000 8192 5120 5012
o32_rva=00002000
nk.exe .pdata 80005000 4096 512 24
o32_rva=00005000
nk.exe .data 800029a0 71 71 856
FILLER->80000000
nk.exe E32 800029e8 112 FILLER
nk.exe O32 80002a58 96 FILLER

MODULES Section
Module Section Start Length psize vsize Filler
---------------------- -------- --------- ------- ------- ------- ------
nk.exe FileName 80002ab8 7 FILLER

Unfilled ROM holes (address, length):
80005018 4072 80004394 3180 80002ac0 1344
total space 8596 in 3 ranges

Writing C:\WINCE500\platform\TEST001\target\ARMV4I\retail\eboot.bin
Table of contents 80002b14 00000020 ( 32)
Writing ROM signature and TOC pointer at 80001040
Kernel data copy section 80002b34 00000010 ( 16)
ROM Header 80002ac0 00000054 ( 84)

First DLL code Address: 04000000
Last DLL code Address: 04000000
First DLL Address: 02000000
Last DLL Address: 02000000
Physical Start Address: 80001000
Physical End Address: 80005018
Start RAM: 80000000
Start of free RAM: 80001000
End of RAM: 80001000
Number of Modules: 1
Number of Copy Sections: 1
Copy Section Offset: 80002b34
FileSys 4K Chunks/Mbyte: 128 <2Mbyte 128 2-4Mbyte 0 4-6Mbyte 0
>6Mbyte
CPU Type: 01c2h
Miscellaneous Flags: 0002h
Total ROM size: 00004018 ( 16408)
Starting ip: 80002000
Raw files size: 00000000
Compressed files size: 00000000
Compacting bin file...
Writing sre file...
Writing rom file...
First 4294963200 bytes of rom empty
Start 80001040 Len 00000008
Start 80001048 Len 00000004
Start 80002000 Len 00000ac0
Start 80002ac0 Len 00000054
Start 80002b14 Len 00000030
Start 80003000 Len 00001394
Start 80005000 Len 00000018
Creating rom file
C:\WINCE500\platform\TEST001\target\ARMV4I\retail\eboot.nb0
Done!

"Dean Ramsier" <ramsiernos...@xxxxxxxxxx> wrote in message

news:ODfVkULFIHA.2268@xxxxxxxxxxxxxxxxxxxxxxx



How big is your bootloader? Dump the output of romimage to a text
file
and post it.

romimage eboot.bib >output.txt

--
Dean Ramsier - eMVP
BSQUARE Corporation

"Alli Dem" <Alli....@xxxxxxxxx> wrote in message
news:OeLNhDLFIHA.5360@xxxxxxxxxxxxxxxxxxxxxxx
Hi,
it is a standart mainstone ii eboot file. i just modify .c files to
reduce size.
startup.s

INCLUDE kxarm.h
INCLUDE bulverde.inc
INCLUDE mainstoneii.inc
INCLUDE image_cfg.inc

INCLUDE xlli_Bulverde_defs.inc
INCLUDE xlli_Mainstone_defs.inc

TEXTAREA

IMPORT _main
IMPORT OALVAtoPA
IMPORT OALPAtoVA

; Included within the text section in order that a relative offset
can
be
; computed in the code below.
;
INCLUDE oemaddrtab_cfg.inc

ALIGN

LEAF_ENTRY OALStartUp
....

---------------------------------------------------------------------------­----------------------------
oemaddrtab_cfg.inc
ALIGN
g_oalAddressTable

DCD 0x80000000, 0xA0000000, 32 ; MAINSTONEII: SDRAM
(64MB).
DCD 0x84000000, 0x5C000000, 1 ; BULVERDE: Internal
SRAM
(64KB bank 0).
DCD 0x84100000, 0x58000000, 1 ; BULVERDE: Internal
memory PM registers.
DCD 0x84200000, 0x4C000000, 1 ; BULVERDE: USB host
controller.
DCD 0x84300000, 0x48000000, 1 ; BULVERDE: Memory
controller.
DCD 0x84400000, 0x44000000, 1 ; BULVERDE: LCD
controller.
DCD 0x84500000, 0x40000000, 32 ; BULVERDE:
Memory-mapped
registers (peripherals).
DCD 0x86500000, 0x3C000000, 64 ; BULVERDE: PCMCIA S1
common memory space.
DCD 0x8A500000, 0x38000000, 64 ; BULVERDE: PCMCIA S1
attribute memory space.
DCD 0x8E500000, 0x30000000, 32 ; BULVERDE: PCMCIA S1
I/O
space.
DCD 0x90500000, 0x2C000000, 64 ; BULVERDE: PCMCIA S0
common memory space.
DCD 0x94500000, 0x28000000, 64 ; BULVERDE: PCMCIA S0
attribute memory space.
DCD 0x98500000, 0x20000000, 32 ; BULVERDE: PCMCIA S0
I/O
space.
DCD 0x9A500000, 0xE0000000, 1 ; MAINSTONEII:
Zero-bank
(in reserved slot - no physical memory required).
DCD 0x9CA00000, 0x00000000, 32 ; MAINSTONEII: nCS0:
Boot
Flash (32MB).
DCD 0x9EA00000, 0x50000000, 1 ; BULVERDE: Camera
peripheral interface.

DCD 0x00000000, 0x00000000, 0 ; end of table

"Dean Ramsier" <ramsiernos...@xxxxxxxxxx> wrote in message
news:edLTR0KFIHA.1316@xxxxxxxxxxxxxxxxxxxxxxx
Where are the header files included? Do you have an alignment
problem
of some kind (declaring data that isn't dword aligned for example,
followed by code)? The problem is likely in the include of
oemaddrtab_cfg.inc, something wrong with that file...

--
Dean Ramsier - eMVP
BSQUARE Corporation

"Alli Dem" <Alli....@xxxxxxxxx> wrote in message
news:%23j$WLVKFIHA.3360@xxxxxxxxxxxxxxxxxxxxxxx

Hi,
yes. OALStartup has a
bl OpenLedB line.
when i remove import and incluse lines. led blinks. otherwise code
resets.

interesting enough ?
Thanks

"voidcoder" <voidco...@xxxxxxxxx> wrote in message
news:uksySOKFIHA.3360@xxxxxxxxxxxxxxxxxxxxxxx

Hm, so you are saying that after removing those
lines your bootloader still compiles OK
(OALVAtoPA/OALPAtoVA and address table are not
referenced in your code) but it starts jumping
to OALStartUp as expected? A bit hard to believe...

--
Oleg

Alli Dem wrote:
hi,
OALStartup code resets when
IMPORT OALVAtoPA
IMPORT OALPAtoVA
INCLUDE oemaddrtab_cfg.inc

lines added.. if i comment out them OALStartUp works.
do you have any suggestion.

Thanks

"voidcoder" <voidco...@xxxxxxxxx> wrote in message
news:OWDLfYADIHA.5976@xxxxxxxxxxxxxxxxxxxxxxx
Hi Alli,

have you found anything interesting yet?

--
Oleg

Alli Dem wrote:
BootImage:
romimage $(ROMIMAGE_FLAGS) etest.bib

!IF "$(WINCEREL)"=="1"
copy
$(_PLATFORMROOT)\$(_TGTPLAT)\target\$(_TGTCPU)\$(WINCEDEBUG)\etest.nb0
$(_FLATRELEASEDIR)
copy
$(_PLATFORMROOT)\$(_TGTPLAT)\target\$(_TGTCPU)\$(WINCEDEBUG)\etest.bin
$(_FLATRELEASEDIR)
!ENDIF

"voidcoder" <voidco...@xxxxxxxxx> wrote in message
news:OenFX5zCIHA.1208@xxxxxxxxxxxxxxxxxxxxxxx
BTW, what do you have in your bootloader's
makefile.inc?

- Oleg

voidcoder wrote:
Have no ideas. There are no special settings
or whatever.

I don't see any differences compared to the
"working" bootloaders. The config is identical,
except of the /MAP linker switch, which should
not be a problem of course.

LDEFINES=-subsystem:native /DEBUG /DEBUGTYPE:CV /FIXED:NO
/MAP

- Oleg

Alli Dem wrote:
how can i fix this.

"voidcoder" <voidco...@xxxxxxxxx> wrote in message
news:%23j7shxxCIHA.4836@xxxxxxxxxxxxxxxxxxxxxxx
ldr r0, =GoPhysical
ldr r1, =0x80000000
ldr r2, =0xA0000000
goes to 0x20011018.
ldr r7, =OALStartUp ; r7 is 0x00011C8C
It appears that your code is built to run from 0x00000000+
and not from 0x80000000+ as expected. In both cases with
=GoPhysical and =OALStartUp you should get something like
0x801D0000 + code offset!

- Oleg

Alli Dem wrote:
Hi,
i debug with jtag using xdb.
ldr r0, =GoPhysical
ldr r1, =0x80000000
ldr r2, =0xA0000000
sub r0, r0, r1
add r0, r0, r2

goes to 0x20011018.
i remove them.

ldr r7, =OALStartUp ; r7 is 0x00011C8C
b OALStartUp ; b pc+3180 pc is a01d0818
and it goes to A01d148C
but oalstartup is starting at A01D0EAC.

"voidcoder" <voidco...@xxxxxxxxx> wrote in message
news:evuWsfOBIHA.4656@xxxxxxxxxxxxxxxxxxxxxxx
Ops, I meant "StartUp"! Assuming you are
jumping from IPL with everything configured
and MMU turned on, your bootloader's StartUp
function may look

...

read more »- Hide quoted text -

- Show quoted text -








.



Relevant Pages

  • Re: eboot.bib question
    ... Unfilled ROM holes: ... attribute memory space. ... RAM 80000000 00001000 RAM ... OALStartUp and it jumps to main.c but it resets at main. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: eboot.bib question
    ... Record starting at fffff040 is outside of rom range, ... attribute memory space. ... to OALStartUp as expected? ... ldr r1, =0x80000000 ...
    (microsoft.public.windowsce.platbuilder)
  • Re: eboot.bib question
    ... Unfilled ROM holes: ... Writing ROM signature and TOC pointer at 80002040 ... attribute memory space. ... RAM 80000000 00001000 RAM ...
    (microsoft.public.windowsce.platbuilder)
  • Re: eboot.bib question
    ... RAM 80000000 00001000 RAM ... ldr r0, =0xA0030000 ... Record starting at fffff040 is outside of rom range, ... attribute memory space. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: x86 code compression
    ... > In my project i just got 128kb memory space for my x86-ROM-code. ... RAM at boot time. ... so you could run a 256k code segment with just 128k ROM ... More information and a free downloadable test version of On Time RTOS-32 is ...
    (comp.arch.embedded)

Loading