Lpc2000

Hi,

thank you very much for your explanation and the provided source code,
but I think you misunderstood me. I have written the routines _write_r
and _read_r and so on. I compiled these new written functions and
build my own small library called libosarm.a . If I disassemble this
library there is the correct assembler code inside. But if I link my
project with arm-elf-gcc $FLAGS -o tst *.o -Wl,-verbose -losarm I can
see that the linker opens my library, but after that he opens libc.a
and shows the errors.

regards, miru

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>
> miruffer wrote:
> 
> >Hi,
> >
> >thank you for your answer. I look at your scripts and have seen that
> >you use the flag --disable-newlib-supplied-syscalls. I have rebuilt my
> >GNU Toolchain. 
> >When the linker links my project, there are the errors shown below.
> >
> >  
> >
> 
> Absolutely correct.  You've done it the right way.  Now, if you want to 
> know what can be done with those missing routines, also get a copy of 
> the RDCF2 filesystem source (also from my site).  *You* provide those 
> functions: write_r, open_r, etc..
> 
> 
>
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(writer.o):
> >In function `_write_r':
> >../../../../../newlib-1.13.0/newlib/libc/reent/writer.c:58: undefined
> >reference to `_write'
>
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(closer.o):
> >In function `_close_r':
> >../../../../../newlib-1.13.0/newlib/libc/reent/closer.c:53: undefined
> >reference to `_close'
>
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(fstatr.o):
> >In function `_fstat_r':
> >../../../../../newlib-1.13.0/newlib/libc/reent/fstatr.c:62: undefined
> >reference to `_fstat'
>
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(lseekr.o):
> >In function `_lseek_r':
> >../../../../../newlib-1.13.0/newlib/libc/reent/lseekr.c:58: undefined
> >reference to `_lseek'
>
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(readr.o):
> >In function `_read_r':
> >../../../../../newlib-1.13.0/newlib/libc/reent/readr.c:58: undefined
> >reference to `_read'
>
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libstdc++.a(eh_personality.o):
> >
> >
> >
> >All the functions he can't find, are exsisting in my own libary the
> >linker had opend before. I can't understand that.
> >
> >
> >  
> >
> When you compile newlib, without the stubs, it assumes that it will be 
> dealing with an operating system which would provide a call entry 
> structure to perform device I/O.   Since you are not using an operating 
> system, such as Linux, you have to provide that last bit of code to 
> bridge between the library (abstraction) and your hardware (reality).
> 
> The newlib, nor any library, is intended to provide a "final
solution".  
> They cannot, hardware varies from environ to environ.  It is up to you, 
> ultimately, to see that the "operating system" provide a means to move 
> the data stream coming out of the library over to the hardware.  With 
> something like Linux, we do this be means of the various hardware
driver 
> code and the SysCalls.  When you don't have an operating system, the 
> same requirement still exists to physically connect the data stream
from 
> the library to the hardware.
> 
> This is what the RDCF2 code is about.  It illustrates how to do device 
> (hardware) interfacing to newlib, so that you can use filestreams such 
> as: fopen(), fread(), fwrite(), fgetc(), etc..  I only provided code to 
> interface to an SD drive.  The application that I'm building does not 
> require, nor tolerate, file streams to the serial port(s).  Having said 
> that, you can add a device "UARTx" to the device table, then add
another 
> file identical in structure to that of 'mmc_module.c'.  Take a look at 
> that file, at the bottom is the DEVICE_TABLE_ENTRY struct which
provides 
> the entry points to get work done.  This is the "final link" between 
> newlib and the hardware.  The write_r, read_r, open_r code I provide is 
> the mechanism to handle multiple data streams and to direct those 
> streams to the various hardware.
> 
> I had taken a general purpose approach to implementing the stub code.  
> There are two key elements of the interfacing process: adding a new 
> device to the DeviceTable array, adding a new module which contains the 
> implementation of the device entry.  The code in between, all those 
> ending in "*_r.c" do not need to be altered.
> 
> 1. devices.c contains the device table.
> 2. sysdefs.h contains the device IDs.
> 3. mmc_module.c illustrates the implementation of the device.
> 
> You simply add your new module code and make an entry into the
device table.
> 
> I see that this may be confusing to a first time user of libraries on 
> embedded systems.  All embedded system libraries function in
essentially 
> the same manner.  Ultimately, there has to be "bridging code"
written by 
> the end-user to provide a link between the hardware and the library.
> 
> While you could get deep inside the guts of newlib and hack your way 
> into getting the write() function to give you an output you desire, I 
> would advise against it.
> 
> 
> TomW
> 
> 
> 
> -- 
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
>