OEMAddressTable ... Query ?

Hello All,

I am trying to run WINCE XIP in Flash using one the EBOOT menu options
:- "Launch an existing Flash resident image".

I have been able to modify the appropriate bib files and pass the
control to the Kernel but it is giving the following output and just
hangs in there :-

Windows CE Kernel for ARM (Thumb Enabled) Built on Jun 24 2004 at
18:25:00
ProcessorType=0411 Revision=7
sp_abt=ffff5000 sp_irq=ffff2800 sp_undef=ffffc800 OEMAddressTable =
9ca48960

By the way, I am working on MainstoneII BSP.

I would like to know as to whether we have to modify the address of the
OEMAddressTable when we run the kernel XIP ... in flash or the above
output indicates something else ?

If anyone could provide me any pointers in this regard ... it would be
a great help ... !

Warm regards,
Swapnil.

Tom
Thu Oct 27 10:31:01 CDT 2005

Switching between a RAM based image and an XIP image does not typically
require changes to OEMAddressTable. It does require the correct region and
ROMSTART/ROMSIZE definitions in CONFIG.BIB, however. Perhaps try posting
your OEMAddressTable and CONFIG.BIB file for our review.

Tom Gensel (eMVP)

WindowsCE_Developer
Thu Oct 27 11:23:53 CDT 2005

Hello Tom,

Thanks for your reply ... !

I am posting my OEMAddressTable and Config.bib ... If you could have a
look at it ... it would be a great help ... !

Config.bib :-

MEMORY

; Name Start Size Type
; ------- -------- -------- ----
RSVD 80000000 000FF000 RESERVED
ARGS 800FF000 00001000 RESERVED
NK 9CA40000 00500000 RAMIMAGE
RAM 83100000 00F00000 RAM

; Reserve ZBANK virtual block (No physical memory
; is required to back this virtual range).
;
ZBANK 96500000 00100000 RESERVED

CONFIG

AUTOSIZE=OFF
KERNELFIXUPS=ON
ROMSTART=9CA40000
ROMWIDTH=32
ROMSIZE=500000

OEMAddressTable -

g_oalAddressTable
DCD 0x80000000, 0xA0000000, 64 ; 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 0x9A600000, 0x14000000, 1 ; MAINSTONEII: nCS5:
eXpansion board header.
DCD 0x9A700000, 0x10000000, 1 ; MAINSTONEII: nCS4:
SMSC 91C111 Ethernet controller.
DCD 0x9A800000, 0x0A000000, 1 ; MAINSTONEII: nCS2
(upper half): 2MB SRAM.
DCD 0x9A900000, 0x08000000, 1 ; MAINSTONEII: nCS2
(lower half): Board registers (FPGA).
DCD 0x9AA00000, 0x04000000, 32 ; MAINSTONEII: nCS1:
Secondary flash (32MB).
DCD 0x9CA00000, 0x00000000, 32 ; MAINSTONEII: nCS0:
Boot Flash (32MB).
DCD 0x9EA00000, 0x50000000, 1 ; BULVERDE: Camera
peripheral interface.

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

I am loading my OS image (NK.nb0) at 0x9CA40000 (Physical Address -
00040000).Also, I have modifed the OEMLaunch function accordingly to
jump to this address.

If u could provide any pointers regarding the same ... it would be a
great help ... !

Warm regards,
Swapnil.

Dean
Thu Oct 27 11:56:09 CDT 2005

I don't see a problem here. It might be your MMU code that is failing.
Note that the uncached SDRAM virtual address matches the SDRAM physical
address. That could be hiding an error in the code the is turning the MMU
on and off. Now that you've switched over to flash addresses that don't
line up virtual/physical, it's more difficult to get that code correct.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"WindowsCE_Developer" <swapnilstud@gmail.com> wrote in message
news:1130430233.936665.284020@g44g2000cwa.googlegroups.com...
> Hello Tom,
>
> Thanks for your reply ... !
>
> I am posting my OEMAddressTable and Config.bib ... If you could have a
> look at it ... it would be a great help ... !
>
> Config.bib :-
>
> MEMORY
>
> ; Name Start Size Type
> ; ------- -------- -------- ----
> RSVD 80000000 000FF000 RESERVED
> ARGS 800FF000 00001000 RESERVED
> NK 9CA40000 00500000 RAMIMAGE
> RAM 83100000 00F00000 RAM
>
> ; Reserve ZBANK virtual block (No physical memory
> ; is required to back this virtual range).
> ;
> ZBANK 96500000 00100000 RESERVED
>
> CONFIG
>
> AUTOSIZE=OFF
> KERNELFIXUPS=ON
> ROMSTART=9CA40000
> ROMWIDTH=32
> ROMSIZE=500000
>
> OEMAddressTable -
>
> g_oalAddressTable
> DCD 0x80000000, 0xA0000000, 64 ; 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 0x9A600000, 0x14000000, 1 ; MAINSTONEII: nCS5:
> eXpansion board header.
> DCD 0x9A700000, 0x10000000, 1 ; MAINSTONEII: nCS4:
> SMSC 91C111 Ethernet controller.
> DCD 0x9A800000, 0x0A000000, 1 ; MAINSTONEII: nCS2
> (upper half): 2MB SRAM.
> DCD 0x9A900000, 0x08000000, 1 ; MAINSTONEII: nCS2
> (lower half): Board registers (FPGA).
> DCD 0x9AA00000, 0x04000000, 32 ; MAINSTONEII: nCS1:
> Secondary flash (32MB).
> DCD 0x9CA00000, 0x00000000, 32 ; MAINSTONEII: nCS0:
> Boot Flash (32MB).
> DCD 0x9EA00000, 0x50000000, 1 ; BULVERDE: Camera
> peripheral interface.
>
> DCD 0x00000000, 0x00000000, 0 ; end of table
>
> I am loading my OS image (NK.nb0) at 0x9CA40000 (Physical Address -
> 00040000).Also, I have modifed the OEMLaunch function accordingly to
> jump to this address.
>
> If u could provide any pointers regarding the same ... it would be a
> great help ... !
>
> Warm regards,
> Swapnil.
>

Tom
Thu Oct 27 12:34:02 CDT 2005

I agree with Dean; I see nothing here to explain your lockup. Perhaps you
might elaborate on your changes to OEMLaunch. Assuming you JTAG'd your image
into flash, did your JTAG utility verify the entire image?

As a side note, if you want, you could move your RAM start address down to
80100000 and increase its size to 03F0000 to make use of the extra RAM
you're not using for NK now. And make sure your OS image fits in the 5MB
you've allowed for it. The Mainstone has 32MB of boot flash less what's
needed for EBOOT, so you're free to increase the size of your ROM and
RAMIMAGE region to more than just 5MB.

Tom Gensel (eMVP)

"Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
news:eU$QNdx2FHA.2444@TK2MSFTNGP09.phx.gbl...
>I don't see a problem here. It might be your MMU code that is failing.
>Note that the uncached SDRAM virtual address matches the SDRAM physical
>address. That could be hiding an error in the code the is turning the MMU
>on and off. Now that you've switched over to flash addresses that don't
>line up virtual/physical, it's more difficult to get that code correct.
>
> --
> Dean Ramsier - eMVP
> BSQUARE Corporation
>
>

WindowsCE_Developer
Fri Oct 28 03:18:05 CDT 2005

Hello Dean and Tom,

Thanks for your replies ... !

When I flashed my image throught JTAG, it did verify the entire image
... !
Also, the changes that I did to OEMLaunch is regarding the
dwLaunchAddress variable, pointing it to 9CA40000, the OALVATOPA
converts this correspondingly to 00040000(which is stored in the
variable PhysAddress which is used finally in OEMLaunch to call the
function Launch(PhysAddress).), where my JTAGed flashed image(NK.nb0)
resides.

I believe I had to to make these changes only to OEMLaunch ...

Also, I will implement the changes suggested by you regarding the RAM
entry ... and look into the MMU code as suggested by Dean ....

Looking forward for your reply ...

Warm regards,
Swapnil.

WindowsCE_Developer
Fri Oct 28 06:45:19 CDT 2005

Hello All,

I have managed to take the Kernel one more step ahead in execution -

Now I am getting the following output:-

Windows CE Kernel for ARM (Thumb Enabled) Built on Jun 24 2004 at
18:25:00
ProcessorType=0411 Revision=7
sp_abt=ffff5000 sp_irq=ffff2800 sp_undef=ffffc800 OEMAddressTable =
9ca45974
Sp=ffffc7cc

Sp=ffffc7cc is the last print statement in the ARMInit function, which
is executed after the OEMInit() and KernelFindMemory() function. In my
OS image I have not included the KITL support ... so how do I now as to
where exactly has my code reached in the Kernel execution since I will
not get any shell prompt on the Hyperterminal ... right ... ?

If anoyone could provide pointers to me in this regard it would be a
great help ... !

Warm regards,
Swapnil.

Dean
Fri Oct 28 08:00:20 CDT 2005

If this is a debug build, you should continue to get debug messages over
serial even without kitl. Note that they will only come on your terminal
program, not in the PB window.

Are you sure you don't have a problem with image size, as Tom suggested?
How big is the image you are trying to build? If you did one of the
standard kitchen sink builds that come by default, it could easily be
20-40MB which is far larger than what you originally had allocated in your
config.bib file...

--
Dean Ramsier - eMVP
BSQUARE Corporation


"WindowsCE_Developer" <swapnilstud@gmail.com> wrote in message
news:1130499919.240338.174000@o13g2000cwo.googlegroups.com...
> Hello All,
>
> I have managed to take the Kernel one more step ahead in execution -
>
> Now I am getting the following output:-
>
> Windows CE Kernel for ARM (Thumb Enabled) Built on Jun 24 2004 at
> 18:25:00
> ProcessorType=0411 Revision=7
> sp_abt=ffff5000 sp_irq=ffff2800 sp_undef=ffffc800 OEMAddressTable =
> 9ca45974
> Sp=ffffc7cc
>
> Sp=ffffc7cc is the last print statement in the ARMInit function, which
> is executed after the OEMInit() and KernelFindMemory() function. In my
> OS image I have not included the KITL support ... so how do I now as to
> where exactly has my code reached in the Kernel execution since I will
> not get any shell prompt on the Hyperterminal ... right ... ?
>
> If anoyone could provide pointers to me in this regard it would be a
> great help ... !
>
> Warm regards,
> Swapnil.
>

WindowsCE_Developer
Fri Oct 28 08:11:49 CDT 2005

Hello Dean,

If it a Retail build ... is there any way that I can get a shell prompt
or something for a Tiney Kernel image ... since when I went through the
source code and its execution cycle ... I found that it had reached its
final stage ... I was thinking of trying to include a simple Hello
World application in the OS image or may be configure the Debug LED's
to glow ... and then execute that application when the OS image boots
... Am i thinking on the right direction ... ?

Warm regards,
Swapnil.

Dean
Fri Oct 28 12:51:31 CDT 2005

Sure, do anything you like. One option is to blink an LED in an simple
application. Write the app, include it in the image via the bib file, add
it to the Launch key in the registry. That will cause it to be
automatically launched.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"WindowsCE_Developer" <swapnilstud@gmail.com> wrote in message
news:1130505109.372474.306080@g14g2000cwa.googlegroups.com...
> Hello Dean,
>
> If it a Retail build ... is there any way that I can get a shell prompt
> or something for a Tiney Kernel image ... since when I went through the
> source code and its execution cycle ... I found that it had reached its
> final stage ... I was thinking of trying to include a simple Hello
> World application in the OS image or may be configure the Debug LED's
> to glow ... and then execute that application when the OS image boots
> ... Am i thinking on the right direction ... ?
>
> Warm regards,
> Swapnil.
>