[okl4-developer] OKL4 2.1: Build Option 'VEBOSE_INIT=1 ' doesnot work

[Frank Kaiser]

Hello, Geoffrey

Many thanks for your feedback. I am testing OKL4 version 2.1 which I got
from
http://wiki.ok-labs.com/FrontPage?action=AttachFile&do=get&target=okl4_2
.1.tar.gz. The ATMEL AT91SAM9263 is built around an ARM926EJ-S core.
Since the directory arch/arm/pistachio/cpu/arm926ejs proved to be empty,
I cloned the xscale directory since it comes closest to the core variant
I am using. So far I only had some work to adapt cache.h.
Meanwhile I found out that kmem_t::init() and kmem_t::free() (called by
init) are the only methods using TRACE_INIT() before the initialisation
of the console. After commenting them out 'VERBOSE_INIT=1' behaved as
excpected.
If you point me to the version which you expect not having the problem,
I'll consider retesting it. But for thre time being I prefer to stay
with the current version, until I have finished the hardware migration.
I don't like to change horses as long as the race is ongoing.

Regards
Frank
-----Original Message-----
From: Geoffrey Lee [mailto:glee at ok-labs.com] 
Sent: Monday, June 23, 2008 4:44 AM
To: Frank Kaiser
Cc: developer at okl4.org
Subject: Re: [okl4-developer] OKL4 2.1: Build Option 'VEBOSE_INIT=1 '
doesnot work

On Fri, Jun 20, 2008 at 11:16:41AM +0200, Frank Kaiser wrote:
> Hello

Hi Frank

I've been told by the kernel guys that the issue you see should
have been addressed some time ago.  Can you let us know which version 
of OKL4 you are using, what machine you are building for and
if possible re-test with the latest version to confirm that the
problem has gone away?

	-gl


> 
>  
> 
> I am currently trying to adapt OKL4 to another ARM9 platform which is
ATMEL AT91SAM9263. To get more debug information during the startup
phase I tried the build option 'VERBOSE_INIT=1' (derived from the
content of 'pistachio/SConscript', but undocumented at
http://www.ertos.nicta.com.au/software/kenge/ as many other features),
but found it causing a crash. The reason is that this option activates
the macro TRACE_INIT() which tries to make formatted output to the
kernel console thru function printf(). The point is that the kernel
memory intialisation kmem_t::init() uses this trace macro, and the
memory initialisation is called before Platform::init() (which is
responsible for mapping the IO address space needed by the kernel) and
init_console() (which initialises the serial port for kernel messages)
are called. Trying to output to the console's virtual address while this
address is not yet mapped to the physical address leads to the crash.
> 

--