More Help required ARM PXA255, PB5.0 Kernel startup
grolo
group:
However, I have now found out that one reason for this problem is that
the TLB is not written with the right alignment:
Here are some lines of armtrap.s in the private section of the kernel
code
WINCE500\PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM:
KDataArea
PTs % 0x4000 ; space for first-level page table
ExceptionVectors
% 0x0400 ; space for exception vectors
% 0x0400 ; space for interrupt stack
% 0x0100 ; space for FIQ stack
% 0x0700 ; space for Abort stack
KPage % 0x0c00 ; space for kernel stack & KDataStruct
HighPT % 0x0400 ; space for 2nd level page table to map
0xFFF00000
KDEnd % 0
The Array PTs is reserved for the TLB. According to the PXA255 Manual,
the CP15 Register TTBR can only hold addresses which define the upper
18 Bits (16 k alignment), but the base address passed to the CP15_TTBR
is 0xA05BB000, which is rounded down to 16k Alignment 0xA05B8000. This
of yourse fails while executing.
NK.exe .pdata starts at 8eb3b000, which is probably the reason why the
misalignment occures.
My question: How can I force 16 k alignment of the Arrays without
having to compile private code ?
Has anyone discovered the same problems with PB5.0 on XScale platforms
?
After trying to place the array to a properly aligned memory region, I
retried ... the TLB then was in place but however, the TURN ON of the
MMU failed again.
There is an issue within the help topics of PB:
"If a device with an XScale CPU hangs when executing the instruction
that enables MMU, you can attempt to isolate the problem by including
an identity mapping for FLASH memory in OEMAddressTable. If the
identity mapping allows execution to continue past the failed MMU
instruction, then this indicates that the problem is specific to the
XScale CPU. Although the identity mapping can get you past the MMU
enable instruction, it is likely to cause the system to crash later in
the boot process when virtual memory is accessed.
Once you identify that this is the XScale specific issue, you can
workaround this problem by performing the following steps:
1. Create the identity mapping in the first call to OEMARMCacheMode.
You can determine if it is the first call by testing whether the
instruction counter is a physical address, in which case MMU is not
enabled yet.
2. In OEMInitDebugSerial, remove the identity mapping.
"
We use strataflash (two 16 MB units) and I remapped it onto itself, but
it failed again.
I am completely stuck now and need some advice.
Thank you.
grolo
grolo wrote:
> A couple of weeks ago I have posted the following question to this
> group:
PROBLEM SOLVED, but not without recompiling Private PD code. Here is my
feedback to M$ support:
------------------------------------------------------------------------------------
Platform Builder 5.0:
PXA255, WINDOWS CE5.0 MMU Problems at kernel startup
Dears Sirs
I have discovered major problems building a BSP for our Platform with
Platform Builder
5.0. The reason was the activation of the MMU in armtrap.s. After
having spend hours
and hours debugging the code, I found out that the array 'PTs' was not
aligned to
16 k, which is a requirement for the PXA255 (only 18 MSBs used).
I had to compile the private code supplied with PB5.0, and made the
following changes:
C:\WINCE500\PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM\armtrap.s
;-----------------------------------------------------------------------
; .KDATA area is used to reserve physical memory for the above
structures.
AREA |.KDATA|,DATA,NOINIT
EXPORT ExceptionVectors
;
; BEGIN kth...@xpaneon.de FIX
;
ALIGN 0x4000 ;;; Assert alignment to 16 k !!!!!!!!
;
; END kth...@xpaneon.de FIX
;
KDataArea
PTs % 0x4000 ; space for first-level page table
ExceptionVectors
% 0x0400 ; space for exception vectors
% 0x0400 ; space for interrupt stack
% 0x0100 ; space for FIQ stack
% 0x0700 ; space for Abort stack
KPage % 0x0c00 ; space for kernel stack & KDataStruct
HighPT % 0x0400 ; space for 2nd level page table to map
0xFFF00000
KDEnd % 0
And : here we go, it works. The machine passes the point of MMU
activation.
I would suggest to fix this problem or to give (me) a workaround
suggestion without having to
modify private code. Thank you !!
When searching the internet for workarounds and fixes, I have
discovered that others
have had this particual problem aswell, but answers could not be found.
------------------------------------------------------------------------------------
Dean Ramsier
done (which spans the life of the product line). I'd say you have a problem
with one of your sources files confusing the linker, and the startup code
isn't in the location it should be...
--
Dean Ramsier - eMVP
BSQUARE Corporation
"grolo" <kth...@xpaneon.de> wrote in message
news:1159350024.5...@d34g2000cwd.googlegroups.com...
grolo
Dean Ramsier wrote:
> This should not be a problem - it has never been one on any xscale code I've
> done (which spans the life of the product line). I'd say you have a problem
> with one of your sources files confusing the linker, and the startup code
> isn't in the location it should be...
Maybe you are right ... Therefore : Is there a possibility to get it
into place without changin' private code ?
I mean: If the linker is confused ... how can I find out what confuses
the poor devil ?
Maybe it's the 'makeimg'-Tools that is confused ... or both. However, I
did not find the reason of the confusion. I can work with the modified
private code to get up the platform so far .... I will face this
problem later.
I have two weeks off for vacation and will need a couple of weeks to
bring up the platform, so this will be a topic maybe in early 2006.
BTW: the fact that the problem did not appear with others (and it DID
... ) does not mean that there isn't a problem. Only the probability
that the problem is caused by me is very high. Maybe it's this option
in the SOURCES file of KERNKITL:
EXEBASE=0x8C580000
I did not find out what it's for or whether it causes the failure or
not, but the code does not work at all without it.
grolo
Dean Ramsier wrote:
> This should not be a problem - it has never been one on any xscale code I've
It is defenitely THE PROBLEM. I've debugged and analyzed the TLB and
after my fix it worked fine.
The question is only: Is my solution the right solution or not or which
is the cause of the problem. I suspect it's not, but I can't find the
right solution (which is very time consuming), so I will have to live
with the workaround.
Dean Ramsier
worried about your solution because there is a great deal of position
dependent code in the private tree. All of those labels in armtrap.s are in
defined locations, it's not an option to simply get the first level page
table aligned on a 16 kb boundary. It must be located at it's defined
address. Something is wrong with your build that is causing the linker to
be unable to locate this code sequence properly. What that is, I don't
know.
--
Dean Ramsier - eMVP
BSQUARE Corporation
"grolo" <kth...@xpaneon.de> wrote in message
news:1159524059.7...@i42g2000cwa.googlegroups.com...
grolo
Dean Ramsier wrote:
> I don't disagree this is causing the problem on your platform. I'd be very
> worried about your solution because there is a great deal of position
> dependent code in the private tree. All of those labels in armtrap.s are in
We will see .... I'm bringing up the platform. (After 2 weeks of
vacation)
It's not the final solution anyway, because we cannot publish modified
private code. However, I gives me a chance to go on with the platform
integration.
> defined locations, it's not an option to simply get the first level page
> table aligned on a 16 kb boundary. It must be located at it's defined
> address. Something is wrong with your build that is causing the linker to
> be unable to locate this code sequence properly. What that is, I don't
> know.
Can't tell either ... I did not yet find out how to convice the linker
to locate the code at the right place.