[okl4-developer] OKLinux on x86

[Geoffrey Lee]

On Tue, Nov 11, 2008 at 03:42:31PM +0100, Henning Schild wrote:
> Am Tue, 11 Nov 2008 06:40:48 +1100
> schrieb Geoffrey Lee <glee at ok-labs.com>:
> 
> I bootet all three releases on Qemu and on Hardware. All of them
> only worked on Qemu.
> For Qemu i used build/images/c.img and for Hardware i used grub with a
> config similar to build/images/grub/menu.lst. My only change to that
> config is the location of image.elf. And i am using a different version
> of grub, but that should not be a problem. As you said, it should fail
> earlier if it was a bootloader problem.
> All images where built with the latest toolchain available:
> http://www.ertos.nicta.com.au/downloads/tools/arm-linux-3.4.4.tar.gz
> 
> In my first tries i patched tools/build.py to use "python" (2.5.2
> on my system) instead of "python2.4". Then i used a machine with
> python2.4 to build the releases. As i expected the problem is not
> related to the version of python. I could built all releases with a
> recent version of python, maybe you can drop the dependency for the old
> version some day.
> 
> > It might be a good idea at this point to break into the debugger
> > (Ctrl-k).  Once you are in the debugger, you can turn on tracepoints.
> > Hit r for the tracepoint menu then E to turn on tracepoints, then
> > you can enable all tracepoints or just some specific ones (hit ? for
> > help).  That'll tell you what the system is doing.
> 
> It tells what the system is doing. Before i go on reading code or docs
> i will post the nonzero values maybe someone has an idea. This are the
> values of OKLinux hanging several minutes:
> 
> > 11   INTERRUPT                     n      n    17847 
> > 12   IPC_TRANSFER                  n      n      127 
> > 22   SYSCALL_INTERRUPT_CONTROL     n      n    17847 
> > 23   SYSCALL_IPC                   n      n    53789 
> > 35   TIMESLICE_EXPIRED             n      n       57 
> 

There seems to be some activity on the system, so it is alive.
I can't speak for the older releases but I've definitely booted
2.1 on hardware.

What is the exact command line you used to build OK Linux and OKL4?  
Have you made any modifications, both source code and any supporting
infrastructure?

On the 2.1 release, the hardware serial device is shared between the kernel
debugger and a userlevel driver used by OK Linux.  This may be causing
some issues.  Can you try building a production build by 
appending enable_debug=False to the build command line, and see if you
get any output?  The initial dmesg output and the OKL4 banner will
go missing because the kernel serial driver will be compiled out.

Otherwise, some trace output context might be quite useful in resolving
this issue.

> Henning

	-gl

> 

--