[okl4-developer] Hello world on arm926ejs....

[Peter Howard]

On Thu, 2008-11-13 at 00:55 +0100, Hugues Balp wrote:
> Thanks for your prompt reply...
> 
> Yes you are true, I used an older version of the crosstool chain.
> In fact I had some problems the first time I tried to compile crosstool 
> with gcc-4.2.4-glibc-2.7
> and specially with the binutils-2.18, so I tried then an older version ( 
> gcc-3.4.5-glibc-2.3.6 )
> that was marked ok for the script "arm-softfloat" in the buildlogs of 
> the crosstool web site.
> at the URL http://kegel.com/crosstool/current/buildlogs.
> 
> At present I have understood what happened by looking at the compilation 
> logs...
> Some tests on the availability of the makeinfo tool where true, some 
> other false...
> So I have commented the bugged test in the file 
> crosstool-0.43/binutils-2.18/missing
> 
> Another thing was that I didn't have the gawk tool on my host.
> 
> Now I have just succeded in recompiling from scratch the crosstool-0.43 
> with gcc-4.2.4-glibc-2.7
> with the patch "crosstool-eabi-0.43.patch" provided in the OKL4 wiki.
> My new version of the crosstool chain is configured as shown in the 
> joined file.
> 
> Nevertheless the same error occur when I retry to compile the hello worl 
> example
> with this new crosstool chain and the precompiled SDK...
> 

I think we should persevere with the SDK options for reasons that will
hopefully be clear from my comments further below.  With the newly-built
crosstool, can you try building from a clean sdk tree (i.e. remove the
untarred version and untar it again)?



> So I have decided for another test to compile the source code of OKL4 as 
> follows:
>  
>    tar -zxvf okl4_3.0.tar.gz
>    cd okl4_3.0
>    tools/build.py machine=versatile project=examples example=hello 
> VERBOSE_STR=true
> 
> The compilation was successful and I got an elf image file for the hello 
> world example.
> My problem now is to test it correctly, because it doesn't seem to work 
> properly.
> 
> Indeed I have uploaded and compiled the source code of qemu including 
> some modifications for okl4
> ( the new option -start-addr )... and then tried the new image as 
> follows (as documented in the wiki):
> 
> qemu-system-arm -M versatileab -start-addr 0x07900000 -nographic -kernel 
> okl4_3.0/build/images/image.elf
> 
> You can see here a fatal error from qemu at boot time...
> 
> qemu: fatal: Trying to execute code outside RAM or ROM at 0x08000000
> 
> R00=00000000 R01=00000000 R02=00000000 R03=00000000
> R04=00000000 R05=00000000 R06=00000000 R07=00000000
> R08=00000000 R09=00000000 R10=00000000 R11=00000000
> R12=00000000 R13=00000000 R14=00000000 R15=08000000
> PSR=400001d3 -Z-- A svc32
> Aborted
> 


The configuration of the full source build system is _very_ complicated;
that complexity was one of the motivators for moving to the SDK form of
distribution. 

For example with versatile: the correct build line would be

tools/build.py machine=versatile project=examples example=hello kdb_serial=True


And the invocation line for qemu would be wrong as it applies to a
slightly different configuration which we use for the SDK.  So the nano
address (0x04100000) is the correct one for that build, not the micro
one.

We've just brushed the surface of the configuration options, and only
for versatile.  Certain other archs need kdb_serial=True, some don't.

I'd _strongly_ recommend that you stick with the SDK.  There's a lot
less to worry about, especially at the start.  


-- 
Peter Howard <peterh at ok-labs.com>