Hi,
On Wed Nov 15, 2006 at 20:53:45 +0900, WanKeun Jo wrote:
I've been working on porting DROPS to Bulverde board - PXA270. My senior already made DROPS work on OMAP board before. He worked with L4Linux-2.6.16, but I don't know exact version of fiasco kernel and L4Env packages because they are not specified.
I got all the sources from my senior - not the latest things.. - and have tried them work on Bulverde board.
My status is that I have an unsolvable error in fiasco kernel.
On L4Linux-2.6.16's booting process, one step is "Freeing INITRD", and system halted on that point.
By tracing codes, I got to know while the mem_fpage_unmap() function in l4/kernel/fiasco/src/kern/map_util.cpp executed, the system halted.
And I put "delay codes" into that function's for() {}, and then the system continued to execute and boot succeed. I found this fact after I added printf() into that code in order to debug.
On that point - "Freeing INITRD", whether the boot process goes next step or not depends on how much delay time is put on that code, mem_fpage_unmap(). If I make the delay time a little bit longer, then the system goes to next step at that point, but stops somewhere else after that. If I make the delay time too short, the system never go to next step.
And the mem_fpage_unmap() is called a lot while the system works, but only in the "Freeing INITRD" part, the problem appears.
I think this is a serious timing error, but I can't know what the problem is. I already tried all the combinations of kernel and L4Linux options before.
when I tried to install the latest kernel and l4linux-2.6.18, the halting problem didn't appear. And I found that the latest kernel's mem_fpage_unmap() functions implementation has a lot of changes compared to the kernel I work with.
Could you help me solve this problem??
Please don't say to me "use the latest one".. My senior already succeed on OMAP board with the old versions.
I've never seen this problem personally, so it's hard for me to suggest any sort of fix. Except... well, use the latest source as they seem to work. Maybe we actually fixed the problem with the changes in the kernel. Where is the problem? Bringing your OMAP modifications to the kernel to a recent state should not be a hassle as the modification done in mainline should not overlap with your additions for OMAP. They should both touch different areas.
Adam