Hello Alexander,
i have been trying to make HelenOS (Revision 1517) working with AT91SAM9260EK
from Atmel (CPU: arm926ej-s)
Well, the first thing that strikes me here is that this CPU is ARMv5TEJ,
but HelenOS has been so far only tested on ARMv4. I don't know from the
top of my head what are the differences between these two
microarchitectures, but they might possibly explain the issues.
Not even speaking about the system architecture of the CPU which might
be also slightly different from what the kernel expects now.
1) OPTIMIZATION flag set by several Makefiles in boot and kernel makes the
toolchain generating not executable code?
Could you please explain in more detail? What do you mean by "generating
not executable code"? What is it generating then? Again, this could just
mean that the ARMv4 and ARMv5TEJ are not perfectly compatible.
BTW: What toolchain do you use? HelenOS's cross-compiler toolchain or
some other?
2) The CPU hangs just after activating the MMU in boot module.
My actual solution is to exclude the highest 256MB (from 0xf0000000 to
0xffffffff) from mapping down to 0x70000000 to 0x7fffffff.
Why is it necessary to mirror user-address-space (lower 2GB) to
kernel-address-space (upper 2GB) __entirely__?
Well, it's hard to tell just from your description what might be
happening in the CPU, maybe some ARM expert can help here. But again,
this can signify that the system architecture of the CPU differs from
what the code expects (being written for ARMv4).
3) image.bin (and uImage.bin too) produced by Makefile from image.boot can't be
executed?..
My actual solution is hand-made: arm-..-objcopy -O binary image.raw image.bin.
The image.bin and uImage.bin are created specifically for GTA02 (Neo
Freerunner). It would be quite surprising for me if it just booted
without any changes.
4) At last the kernel can be booted. I have implemented an assembler function
named early_printchar() which is really must have to trace
the kernel boot process, before having console input/output initialized. The
kernel code has been peppered now with
printf("%s, %d\n", __FUNCTION__, __LINE__)
A hint: You don't have to add such tracing lines manually into the code.
Provided you have implemented early character output, you can make use
of the CONFIG_LOG ("Detailed kernel logging") and CONFIG_TRACE ("Kernel
function tracing") configuration options.
So, i ran out of steam. Is here something wrong with MMU
initialization/activation sequence or similar?
I hate to repeat it, but the MMU code is most likely perfectly fine for
ARMv4, but at the same time it might be plainly wrong for ARMv5TEJ. A
closer examination of the CPU specs is needed here.
My code modifications can be posted when required -(approx. 10,000 lines).
I am afraid that without physical access to the same or similar hardware
(or an emulator of the hardware) no one can just magically help you. We
might look into the specs, if time permits.
Anyway, thanks for your experimentation and your email!
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
