Shared libraries for CogLinux
mlu
I have sucessfully built and run hello world with statically linked
libraries.
How can i configure my crosstools to support shared libraries.
I run development under Linux (Fedora) and the current toolchain is:
crosstool-0.43/build/arm-linux/gcc-4.0.2-glibc-2.3.2
It seems that the shared libraries on the board are
libuClibc-0.9.28.so
not glibc-2.3.2
Should I install uclibc/buildroot, and if so, how should this be
configured.
Regards
Magnus
Tarun Tuli
libc is in /lib.
You may want to do a "chmod a+x /lib"
-Tarun
mlu
Yes I know, the problem is that
- a program built with the toolchain and without --static cannot use
the libc.so that can found in /lib on the VCMX212
- the ld-linux.so.2 -> ld-uClibc.so.0 cannot load and run a program
built to use shared libraries
So I downloaded a simple hello world program built with the crosstools
toolchain and linked to use shared libraries ( without --static )
Trying to run this ./hello fails with a message "/bin/sh: ./hello:
Permission denied"
- copy ld-2.3.2.so from the directory .../crosstool/gcc-4.0.2-
glibc-2.3.2/arm-linux/arm-linux/lib on my host to /lib on the
VCMX212
- make /lib/ld-linux.so.2 a soft link to /lib/ld-2.3.2.so
Trying to run ./hello again now fails with "./hello: error while
loading shared libraries: libc.so.6: cannot open shared object file:
No such file or directory"
The loader tries to load the program but the shared library is
missing. One step forward
- copy libc-2.3.2.so from the directory .../crosstool/gcc-4.0.2-
glibc-2.3.2/arm-linux/arm-linux/lib on my host to /lib on the
VCMX212
- make /lib/libc.so.6 a soft link to /lib/libc-2.3.2.so
Now the hello program and serveral other small testprograms can be
built to use shared libraries and runs sucessfully.
The new shared library libc-2.3.2.so is fairly large, 1.4 MB but we
can remove 400k of library code from every program built to use this.
There are probably other libraries that must added for special
situations. libm ....
It seems that the system still boots nicely, busybox still works with
the changed lib structure, so I wonder, do we really need the uClibc
stuff ?
I will try some day when I have time to replace the root file system
if I guess wrong :)
Regards,
Magnus
Richard Crowder
Last week Dan uploaded a new PC/MM LCD demo called Bounce. We're all very
grateful to see the demo and the additional features it shows off for the PC
amd MM LCD; Loading/Displaying bitmaps, BitBlt DMA, page flipping, color-key
transparency, TFS data transfer, etc.
In the release notes for the demo Dan mentioned the simple method used, to
use uMon TFS to upload and memory map the bitmap files. He also hinted that
another method could be used, by calling into uMon and asking it to read the
bitmap files. I thought I would have a crack at this, and other challenges
along the way :)
Attached is a Zip file containing the modifications to the Bounce demo. It
includes the required hook into the uMon API, along with a method for
setting up and using uMon's internal memory allocator. Oh yes! :)
The original images used in the bounce demo are used here, so they need to
be uploaded to flash. But for this example the 'sb' uMon script is not
required, and hence missing from this Zip. The application can now use uMon
to read the bitmap files from flash into an extended heap using TFS.
I turned out to be quite straightforward. The uMon manual (found at
http://www.microcross.com/html/micromonitor.html) briefly describes the
necessary steps required to hook into the uMon function table. The Virtual
Cogs CVS has the snapshot of the uMon build flashed onto currently released
boards (v1.8.1 at the time of writing), and within there are further
examples of how to tie the uMon API into your application.
A different CRT startup, Makefile, and link script have been created
(beware, as usual these are work in progress). The main purpose for these is
to allow a new entry point into the application, along with defining a
statically linked application stack (this should really be placed outside at
the top of SDRAM, but another day for that). The link script also has
defines to point to the end of the application space once it is
loaded/expanded into memory. A few additional source files have been added
taken from the uMon CVS, that tie in the uMon API with uMon flashed onto the
MX212.
The new Cstart() function contains the required calls to tie the application
to the uMon API. Once uMon is attached, the main() function is called. NOTE:
One thing to bear in mind is how the application is started up. If you run
the application directly from the uMon prompt, then upon entry to Cstart()
uMon is memory resident and initialised. If however you are loading this via
JTAG, for instance, it can't be guarenteed that uMon is resident and/or
initialised. The preprocessor define WARM_START_UMON is there for this
instance. It gently starts uMon and allows the API calls to be made once
inside main().
Internally uMon has a statically linked portion of memory that is used for
it's own internal memory allocations. It's only tiny, usually 8KB. Very
convieniently uMon also supports extending this heap. Inside VCMX212_Init()
function is a method for retrieving the point in SDRAM0 where the
application ends and free space starts. This is then given to uMon as the
start of the extended heap. mon_malloc/mon_free can then be used from that
point onwards. NOTE: mon_malloc tries to allocate from uMon's internal heap
FIRST before resorting to the extended heap. This is fine if you application
never exits, but if it does exit you need to be leaving the application
cleanly, worrying about fragmentation you've caused, and look into changing
the exit code in Cstart() to warm start uMon for use again (check the uMon
manual for mon_warmstart() input parameters, particularly re-clearing bss).
Back into main(), the function called TFS_ReadFile() shows how to use uMon
TFS to load a file from flash memory. As you can see fairly straightforward
:)
The rest of main() is virtually the same as the original Bounce demo.
Many thanks to Steve Bragg for the additional functions for line, circle,
and font drawing. These have been integrated into LCD. Plus the Foreground
buffers and Background buffer have been abstracted out of main.c, just to
make it tidyier :)
I finished reading the uMon manual earlier. And a few interesting things
have jumped out. Currently I use Olimex JTAG for source level debugging, but
with the uMon API support it is possible to perform release build debugging!
There are API calls that can be used to simulate the uMon prompt, and to
read characters via the application and feed them back into uMon (e.g. being
able to peek/poke memory using uMon commands from within the application,
never exiting, just reading incoming characters, forming the uMon commands,
then the application sending these commands to uMon command line interface
for interpretation, cool!).
Hmm.. Think that's all?
Merry Christmas to you all. Happy COGing, Richard.
PS: Dan. cough/poke/prod/ RobotTest.bin /prod/poke/cough ;)
emma.fi...@csiro.au
I also wanted to use shared libs, so I copied the entire lib directory
from the crosstool onto my SD card and made /lib on the cog a symlink
to the lib directory on the SD card (after making a copy of /lib in
case this broke things). Still boots fine, Busybox still works - I
haven't noticed any difference except that now all the code that needs
those libraries can use them. It's kind of a dodgy hack, but if it
works...
Emma.
Dan Foisy
Thanks for the update - looks great and I can't wait to try it! I'll
post this on the wiki as time permits...
I've updated the wiki for the VC21RB1 Robot COG - both the manual and
some demo software have been updated and posted, respectively. I have a
PC application that will talk to the Robot COG through its serial port
to control all its functions but it's very dirty and I HAVE to clean it
up before posting it. Look for updated code (including code to
communicate with the VCMX212 directly over I2C) late next week. I
apologize for the delay but once you find out what I've been working on,
I'm sure I'll be forgiven (fingers crossed, hope it works!)
Dan
--
Daniel Foisy
President, Virtual Cogs Embedded Systems Inc.
Unit 4, 5694 Highway 7 East, Suite 311
Markham, Ontario, Canada L3P 1B4
www.virtualcogs.com
416-238-2231
"Your future is modular"