Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug in physmem.c?

37 views
Skip to first unread message

Michael Reim

unread,
Jun 12, 2006, 6:16:55 AM6/12/06
to
Hello experts

This is not an easy one...

My system crashes and I found that this is due to an error in physmem.c.
Maybe someone can confirm this to be a bug or someone can tell me what am I
doing wrong.

My system has RAM from 0x30000000 to 0x31000000 and from 0x40000000 to
0x41000000.

GetContiguousPages gets called with parameters (1,0,0) and as a result in
pfi it gets the following values:
pfi->paStart = 0x31000000
pfi->paEnd = 0x31000000
pfi->paRealEnd = 0x31000000
pfi->pUseMap = 0x81000000
This leads to ixTotal = 0.
There is no memory at 0x31000000, so this may be correct, but the following
loop
for (ixStart = 0; ixStart <= (ixTotal - dwPages); ) {
is now an endless loop (with dwPages=1), because all variables are declared
as uint!!!

The next thing I see is that when ixStart=0x7ff, the loop calls Phys2Virt
with an address of 0x317ff000, which gives NULL, because this is not a valid
address. Anyway GetContiguousPages doesn't test the result for NULL and
calls KCall with this invalid address. The system halts and KCall doesn't
come back!

Maybe I did something wrong, so here is my OEMAddressTable:
OEMAddressTable
;;;-------------------------------------------------------------
;;; Virt Addr Phys Addr MB
;;;-------------------------------------------------------------
DCD 0x80000000, 0x30000000, 16
DCD 0x81000000, 0x40000000, 16
DCD 0x88000000, 0x10000000, 16
DCD 0x8c000000, 0x20000000, 16
DCD 0x8d000000, 0x70000000, 4
DCD 0x91000000, 0x00200000, 1
DCD 0x92000000, 0x00300000, 1
DCD 0x9ff00000, 0xfff00000, 1


My device is a PB5.0 custom device on ARM9.


TIA
--
Michael Reim
reim AT helmut-fischer DOT de


Steve Maillet (eMVP)

unread,
Jun 12, 2006, 7:57:26 AM6/12/06
to
What is your BIB file settings? NOTE: Base RAM *MUST* be contiguous. So to
support the 2 non-contiguous regions you identified your BIB file must
account for that AND your OAL code needs to report to the kernel where
additional non contiguous regions are located.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com


Michael Reim

unread,
Jun 12, 2006, 10:20:41 AM6/12/06
to
Hello Steve

Please see my comments below.

"Steve Maillet (eMVP)" <nos...@EntelechyConsulting.com> schrieb im
Newsbeitrag news:u4Ofhdhj...@TK2MSFTNGP02.phx.gbl...


> What is your BIB file settings?

MEMORY
BLDR 80020000 00040000 RESERVED ; Bldr + Bldr RAM
ETHBUF 80060000 00004000 RESERVED ; EMAC Buffers
DRV_GLB 80068000 00001000 RESERVED ; Boot Args
ETH 80069000 00000800 RESERVED ; Ethernet Buffer
EDBG 80070000 00020000 RESERVED ; EthDbg Buffers
NK 80090000 00f60000 RAMIMAGE
RAM 80ff0000 00010000 RAM
ENDIF


> AND your OAL code needs to report to the kernel where additional non
> contiguous regions are located.

BOOL OEMGetExtensionDRAM(LPDWORD lpMemStart, LPDWORD lpMemLen)
{
*lpMemStart = 0x81000000;
*lpMemLen = 0x01000000;
return TRUE;
}


Anything else that I need to do?

Ross Jordan [MSFT]

unread,
Jun 12, 2006, 2:26:07 PM6/12/06
to
Can you post (or send me) the output of 'viewbin -o nk.bin'?

Thanks,
Ross


"Michael Reim" <nospa...@REMOVENOSPAMANDCAPShelmut-fischer.denospam> wrote
in message news:erB2ltij...@TK2MSFTNGP05.phx.gbl...

Michael Reim

unread,
Jun 13, 2006, 1:35:07 AM6/13/06
to
Hello Ross

The output of 'viewbin -o nk.bin' is too large to attach to this message,
so I'm posting only the header of the file. But I try to send you the
complete
output personally.

ViewBin... nk.bin
Image Start = 0x30090000, length = 0x00EE4D18
Start address = 0x30091000
Checking record #103 for potential TOC (ROMOFFSET = 0xB0000000)
Found pTOC = 0x80f73b34
ROMOFFSET = 0xB0000000

ROMHDR ----------------------------------------
DLL First : 0x01F301F3
DLL Last : 0x02000000
Physical First : 0x80090000
Physical Last : 0x80F74D18
RAM Start : 0x80F80000
RAM Free : 0x80FFF000
RAM End : 0x81000000
Kernel flags : 0x00000000
Prof Symbol Offset : 0x00000000
Num Copy Entries : 6
Copy Entries Offset : 0x80D7EF1C
Num Modules : 95
Num Files : 52
MiscFlags : 0x00000002
CPU : 0x01c2 (Thumb)
Extensions : 0x80099CC0


Looking at it I think the problem might be that the first contiguous RAM is
very small (0x1000)?
But anyway, I think that GetContiguousPages should handle it properly.

--
Michael Reim
reim AT helmut-fischer DOT de


"Ross Jordan [MSFT]" <rjo...@nospam.microsoft.com> schrieb im Newsbeitrag
news:e1hRt2kj...@TK2MSFTNGP02.phx.gbl...

Dean Ramsier

unread,
Jun 13, 2006, 8:40:55 AM6/13/06
to
You'll never get CE to boot on that miniscule amount of RAM. I didn't
notice earlier that you only had 64K allocated. Change your config.bib to
use the second section of RAM for the RAM section, the one that you are now
declaring with OEMGetExtensionDRAM().

Note that NK and RAM sections can be physically discontiguous from each
other, they just can't be physically discontiguous within themselves.
You'll need to update OEMGetExtensionDRAM() to return FALSE, and make sure
that you don't have AUTOSIZE turned on as well.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Michael Reim" <nospa...@REMOVENOSPAMANDCAPShelmut-fischer.denospam> wrote
in message news:O86Zjsqj...@TK2MSFTNGP05.phx.gbl...

Michael Reim

unread,
Jun 19, 2006, 7:39:46 AM6/19/06
to
Hello Dean

I did what you suggested, but now the system hangs on an earlier stage.
It looks like it's hanging somwhere in ethdbg.c in function StartKitl.

Here is some output of viewbin:


Image Start = 0x30090000, length = 0x00EE4D18
Start address = 0x30091000

Checking record #102 for potential TOC (ROMOFFSET = 0xB0000000)


Found pTOC = 0x80f73b34
ROMOFFSET = 0xB0000000

ROMHDR ----------------------------------------
DLL First : 0x01F301F3
DLL Last : 0x02000000
Physical First : 0x80090000
Physical Last : 0x80F74D18

RAM Start : 0x81000000
RAM Free : 0x8107F000
RAM End : 0x82000000


Kernel flags : 0x00000000
Prof Symbol Offset : 0x00000000
Num Copy Entries : 6

Copy Entries Offset : 0x80DEBF4C


Num Modules : 95
Num Files : 52
MiscFlags : 0x00000002
CPU : 0x01c2 (Thumb)
Extensions : 0x80099CC0

And please see below the serial debug output.

Do you have any idea what is going on now?

--
Michael Reim
reim AT helmut-fischer DOT de

Debug output:
Init Debug Serial OK!
Windows CE Kernel for ARM (Thumb Enabled) Built on Jun 24 2004 at 18:21:58
ProcessorType=0920 Revision=0
sp_abt=ffff5000 sp_irq=ffff2800 sp_undef=ffffc800 OEMAddressTable = 80091028
Windows CE Firmware Init
Boot Args @0x80068800, signature 0x544f4f42
+OALInterruptInit
+OALIntrMapInit
-OALIntrMapInit
+SOCPioIntrInit()
+OALIntrStaticTranslate(16, 1)
-OALIntrStaticTranslate
-OALInterruptInit(rc = 1)
InitClock...
uHALr_InitTimers
uHALir_DisableTimer(0)
uHALir_DisableTimer(1)
uHALir_DisableTimer(2)
uHALir_DisableTimer(3)
uHALir_DisableTimer(4)
InitClock: scheduler period 1 ms, increment 33
InitClock: frequency 32768
SetSysTimerInterval TC_CMR=0x1, TC_SR=70000
RTC_From_8564_To_CPU: 13:15:7 19.6.2006
RRRTODOOEMSetRealTime: 13:15:7 19/6/2006
Initialize driver globals area...
Firmware Init Done.
+OEMKitlInit
Changed KITL zone mask to 0x0000FFFF
+InitEther
+OEMEthInit
INFO: EDBG using AT91 controller.
+EDBG:AT91Init
EDBG:AT91Init in kernel
EDBG:AT91Init using I/O range at 0xBFFBC000
AT91_EmacReadPhy n°1! OK
AT91_EmacReadPhy n°2! OK
EDBG:AT91Init Reading MAC address 0x00000100 0x00000302 0x00000504
-EDBG:AT91Init
Debug Ethernet card initialized, MAC Address:00:01:02:03:04:05
VBridge:: built on [Jun 24 2004] time [18:28:30]
.VBridgeInit()...TX = [16384] bytes -- Rx = [16384] bytes
.Tx buffer [0xA105BC80] to [0xA105FC80].
.Rx buffer [0xA105FCA0] to [0xA1063CA0].
.VBridge:: NK add MAC: [0-1-2-3-4-5]
.-OEMEthInit
Using device name: FMP1001029
Device FMP1001029, IP 192.168.1.198, Port 981
Calling EdbgInitDHCP
-InitEther
-OEMKitlInit

!Kitl buffer specified by OAL is not required, ignore...
ProcessRecvFrame: Received Unhandled frame
ProcessRecvFrame: Received Unhandled frame
ProcessRecvFrame: Received Unhandled frame
ProcessRecvFrame: Received Unhandled frame
ProcessRecvFrame: Received Unhandled frame
ProcessRecvFrame: Received Unhandled frame
ProcessRecvFrame: Received Unhandled frame
ProcessRecvFrame: Received Unhandled frame


"Dean Ramsier" <ramsie...@nospam.com> schrieb im Newsbeitrag
news:OzsGTauj...@TK2MSFTNGP02.phx.gbl...

Dean Ramsier

unread,
Jun 19, 2006, 5:09:11 PM6/19/06
to
Is the RAM actually set up properly? You can access all of it cleanly from
the loader, etc? The change that you just made shouldn't have decreased
functionality as long as the RAM was actually ok...

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Michael Reim" <nospa...@REMOVENOSPAMANDCAPShelmut-fischer.denospam> wrote
in message news:eKLZSU5k...@TK2MSFTNGP04.phx.gbl...

Michael Reim

unread,
Jun 20, 2006, 10:32:23 AM6/20/06
to
Hello Dean

Yes, RAM is working.
I tested it with the release version of this platform.

Where I can't be sure is, whether I have all the necessary components
included in the image.
Because I had to remove some components in order to fit the debug image into
16MB RAM.
Looking at my debug output, do you think that I'm missing a component or an
environment variable for KITL to work?

--
Michael Reim
reim AT helmut-fischer DOT de

"Dean Ramsier" <ramsie...@nospam.com> schrieb im Newsbeitrag
news:OzXbNS%23kGH...@TK2MSFTNGP05.phx.gbl...

Dean Ramsier

unread,
Jun 20, 2006, 12:16:35 PM6/20/06
to
kitl doesn't require anything outside of itself. As long as IMGNOKITL is
not set you should have everything you need from the OS.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Michael Reim" <nospa...@REMOVENOSPAMANDCAPShelmut-fischer.denospam> wrote
in message news:ecILaZHl...@TK2MSFTNGP03.phx.gbl...

0 new messages