[okl4-developer] Hello world on arm926ejs....
Hugues Balp
hugues.balp at free.fr
Thu Nov 13 10:55:56 EST 2008
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...
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 same occur when I test the elf image okl4_3.0/build/image.elf
which seems to be different from the one located in "images" directory.
The elf headers seems when I run the command readelf -a (they are the
same for both files named image.elf and the entry point address differ
for the boot image )
But the following error is thrown when I read the entire list of symbols
with the command readelf -h
......
2151: 8000f908 640 OBJECT GLOBAL DEFAULT 6 hello-stream_packet
2152: 8000f880 12 OBJECT GLOBAL DEFAULT 6 hello-malloc_mutex
No version information found in this file.
Notes at offset 0x000528df with length 0x0000031e:
Owner Data size Description
readelf: Warning: corrupt note found at offset 0 into core notes
readelf: Warning: type: 1, namesize: 00000011, descsize: 00000300
Concerning the okl4_3.0/build/images/image.out, I have tried it
with the entry point adress 0x4100000. In that case no error is raised
but the process enter in an infinite loop without performing anything....
So I attach to this mail also the three images in order for you to be
able to
investigate a little if possible.
Thanks in advance,
Hugues Balp.
Peter Howard wrote:
> On Wed, 2008-11-12 at 18:28 +0100, Hugues Balp wrote:
>
>> Hello everybody,
>>
>>
>
> Hello Hugues
>
>
>> I first want to thank you for the good job that has been made around the
>> OKL4 micro-kernel.
>> I' ve just registered to this mailing list after having downloaded OKL4
>> v3.0 and
>> performed some installations and tests with the hello world example for
>> arm926ejs targets...
>>
>> Nevertheless I encountered a number of problems during installation and
>> compilation phases....
>> So I have now a number of questions and hope you will help me to
>> understand what happens
>> on my system...
>>
>> The first target I wanted to test is called versatile ( with an
>> arm926ejs processor ).
>>
>> So following the instructions of the OKL4 wiki, either in Prerequisite
>> page as in the one
>> dedicated to the release 3.0, I have downloaded first the precompiled
>> SDK for arm926ejs
>> target so as the arm-linux crosstool proposed in URL
>> http://www.ertos.nicta.com.au/downloads/tools/arm-linux-3.4.4.tar.gz
>>
>>
>
> This toolchain is out of date. You need to build your own toolchain via
> crosstool as described on http://wiki.ok-labs.com/Release/3.0 (though I
> gather from comments below that you have already done that).
>
>
>> After some installation steps I got the following error when trying to
>> compile as follow
>> the singlecell example delivered within the sdk:
>>
>> cd $OKL4_SDK_ROOT/okl4/arm926ejs/examples/singlecell
>> make clean
>> make
>>
>> The complete listing of the error is joined to this mail.
>> The error deals with* internal relocation errors* due to
>> incompatibilities between binary libraries *ABI versions* as described below
>>
>> "ERROR: build.micro-debug/src/hello.o is compiled for EABI version 0,
>> whereas build.micro-debug/bin/hello is compiled for version 4"
>>
>> What is amazing is to observe that ABI versions differ within the
>> supplied precompiled sdk-arm926ejs itself, as illustrated by the
>> following commands:
>>
>> cd $OKL4_SDK_ROOT
>> find . -name "*.o" -exec ls {} \; -exec readelf -h {} \; | egrep
>> "Flags|arm926ejs"
>> ./kernel/arm926ejs/micro-debug/object/arm926ejs.o
>> Flags: 0x200, GNU EABI, software FP
>> ./kernel/arm926ejs/micro-debug/object/versatile.o
>> Flags: 0x200, GNU EABI, software FP
>> ./kernel/arm926ejs/micro-debug_no_console/object/arm926ejs.o
>> Flags: 0x200, GNU EABI, software FP
>> ./kernel/arm926ejs/micro-debug_no_console/object/versatile.o
>> Flags: 0x200, GNU EABI, software FP
>> ./kernel/arm926ejs/micro-benchmark/object/arm926ejs.o
>> Flags: 0x200, GNU EABI, software FP
>> ./kernel/arm926ejs/micro-benchmark/object/versatile.o
>> Flags: 0x200, GNU EABI, software FP
>> ./kernel/arm926ejs/micro-production/object/arm926ejs.o
>> Flags: 0x200, GNU EABI, software FP
>> ./kernel/arm926ejs/micro-production/object/versatile.o
>> Flags: 0x200, GNU EABI, software FP
>> ./kernel/arm926ejs/micro-tracebuffers/object/arm926ejs.o
>> Flags: 0x200, GNU EABI, software FP
>> ./kernel/arm926ejs/micro-tracebuffers/object/versatile.o
>> Flags: 0x200, GNU EABI, software FP
>> ./okl4/arm926ejs/micro-debug/libs/crt0.o
>> Flags: 0x4000000, Version4 EABI
>> ./okl4/arm926ejs/examples/singlecell/hello/build.micro-debug/src/hello.o
>> Flags: 0x200, GNU EABI, software FP
>> ./okl4/arm926ejs/micro-production/libs/crt0.o
>> Flags: 0x4000000, Version4 EABI
>> ./okl4/arm926ejs/nano-production/libs/crt0.o
>> Flags: 0x4000000, Version4 EABI
>> ./okl4/arm926ejs/nano-debug/libs/crt0.o
>> Flags: 0x4000000, Version4 EABI
>>
>>
>
> This is intentional. At this point in time the OKL4 kernel itself is
> built to an older EABI standard, whereas the user-space code is built to
> EABI-v4.
>
>
>
>> Another thing that I don't understand in the above error message comes
>> from the fact that
>> the file build.micro-debug/src/hello.o is really a binary object file,
>> as illustrated by the following "file" command output: ELF 32-bit
>> LSB relocatable, ARM, version 1, not stripped
>> whereas the item build.micro-debug/bin/hello isn't really a file.
>> Indeed the only file that resides in directory
>> $OKL4_SDK_ROOT/okl4/arm926ejs/examples/singlecell/hello/build.micro-debug/bin
>> is an XML file named hello.xml.
>> So I imagine there is a binary file generated from this XML file ? I
>> that true ?....
>>
>> Another thing to add is that the error is the same either when I use the
>> arm-linux toolchain referenced in the OKL4 wiki Prerequisite page
>> or with a self compiled crosstool chain with support for eabi ( as
>> documented in the mailin-list archive ).
>>
>
> Just to clarify - the toolchain you built is crosstool 0.43 with OKL's
> EABI patch? Looking at your crosstool config file I think not, as it
> shows you building with gcc 3.4.5 whereas it should be using gcc 4.2.4
>
> The example builds with our "internal" toolchain. I'm doing a scratch
> rebuild of crosstool from the wiki to confirm that we haven't stuffed
> anything up there. I'll post a followup when it's built.
>
>
>> You can also refer to the joined configuration file of this toolchain.
>>
>> To sum up I am just wondering me how I can get rid of this problem ?
>>
>> I will send to you later other questions around the compilation of OKL4
>> itself and its required crosstool chains....
>>
>> Thanks in advance for your help,
>>
>>
> Hoping my help helps.
>
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: arm-unknown-linux-gnueabi.crosstoolconfig.txt
Url: http://lists.okl4.org/pipermail/developer/attachments/20081112/154dd42b/attachment.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.elf
Type: application/octet-stream
Size: 374432 bytes
Desc: not available
Url : http://lists.okl4.org/pipermail/developer/attachments/20081112/154dd42b/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.boot
Type: application/octet-stream
Size: 370336 bytes
Desc: not available
Url : http://lists.okl4.org/pipermail/developer/attachments/20081112/154dd42b/attachment-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.elf
Type: application/octet-stream
Size: 374432 bytes
Desc: not available
Url : http://lists.okl4.org/pipermail/developer/attachments/20081112/154dd42b/attachment-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: weaver.xml
Type: text/xml
Size: 2952 bytes
Desc: not available
Url : http://lists.okl4.org/pipermail/developer/attachments/20081112/154dd42b/attachment.bin
More information about the Developer
mailing list