| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've gone through and cleaned up the TFTP driver so that it fits
into the libio system. Here's the comment from the new driver:
/*
* Usage:
*
* To open `/bootfiles/image' on `hostname' for reading:
* fd = open ("/TFTP/hostname/bootfiles/image", O_RDONLY);
*
* The `hostname' can be a symbolic name or four
* dot-separated decimal values.
*
* To open a file on the host which supplied the BOOTP
* information just leave the `hostname' part empty:
* fd = open ("/TFTP//bootfiles/image", O_RDONLY);
*
*/
You can `fopen' TFTP files the same way:
fp = fopen (fullname, "r");
nread = fread (cbuf, sizeof cbuf[0], sizeof cbuf, fp);
The diff's are included below. I've also modified the TFTP demo
program and the bootstrap PROM example. They should be on my ftp
site `soon'.
The one thing I don't like is the way I had to do an end-run on the
libio routines to get errno passed back from my driver to the
application (since there are some errno codes that don't map to RTEMS
status codes). My approach was to set errno in the driver and have
the driver routine return an RTEMS status code that I `know' isn't in
the errno_assoc[] in libio.c.
Perhaps there should be an RTEMS_TRANPARENT_ERRNO status code (or
something similar) which driver routines could return to indicate
that the driver routine has set errno and that the libio routines
shouldn't attempt to map the returned status code to errno.
Actually, I think the entire I/O system needs looking at -- as
you've already mentioned. The hacks I've dropped in to syscalls.c to
make fstat work, for example, are *not* shining examples of good
code......
|
| |
|
|
| |
"gmake debug".
|
| | |
|
| |
|
|
|
|
|
|
|
| |
of BSS size. The conversion from a count of u8's to a count of
u32's was shifting in the wrong direction. This error had been in
the start code a long time. It had not caused problems because
the BSS is typically much smaller than the C heap which typically
follows it in memory. Plus since this code was executed at start
time, all that really happened was an extra zeroing of some memory.
|
| |
|
|
|
| |
the atexit routines on the global reentrancy structure were not
invoked. But it does not seem like a 100% correct solution.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here is the result of my nightly work to get RTEMS_ROOT=$srcdir working
with different shells and relative/absolute paths.
What I did is relatively simple in principle:
Instead of setting RTEMS_ROOT in configure.in and then let configure
substitute @RTEMS_ROOT@ inside the Makefiles, I now let each Makefile
set RTEMS_ROOT from each Makefile's @top_srcdir@ value.
The difference is subtile, but with enormous side effects:
- If RTEMS_ROOT is set in configure, then the same single value will be
propagated to all Makefiles. This breaks using relative paths, as the
relative path to the root of the source tree is used inside of all
subdirectory Makefiles.
- Now each Makefile.in sets RTEMS_ROOT = @top_srcdir@. top_srcdir is
computed individually by configure for each single Makefile.in, hereby
receiving the correct value, no matter if relative or absolute paths are
used.
To get this working, I needed to remove setting RTEMS_ROOT from
target.cfg.in, because this overrides the value of RTEMS_ROOT from each
individual Makefile.
Furthermore, I removed RTEMS_CUSTOM from the Makefiles and replaced all
"include $(RTEMS_CUSTOM)" directives with"include
$(RTEMS_ROOT)/make/custom/$(RTEMS_BSP)". Perhaps you don't like this,
but I think, to have one variable less is clearer and easier to
understand than having several variables refering to the next one.
I enclose a small patch to this mail, which
- fixes the config.h problem (to finally clearify misunderstands)
- removes assignment/subsitution of RTEMS_ROOT from configure.in
- contains a workaround for the application Makefile's RTEMS_ROOT
problem (reported by Eric)
- removes some unused lines from the toplevel Makefile.in
- removes assignment of RTEMS_ROOT from make/target.cfg.in
|
| | |
|
| |
|
|
| |
by Ralf Corsepius
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
With this in place, it is possible to fdopen a TCP stream socket and
getc/fprintf/etc. on the STDIO stream!
|
| |
|
|
|
|
|
|
|
|
| |
> RTEMS is under CVS control and has been since rtems 3.1.16 which was
> around May 1995. So I just to add the $Id$. If you notice other files
> with missing $Id$'s let me know. I try to keep w\up with it.
Now that you have asked -- I'll attach a list of files lacking an RCS-Id to
this mail. This list has been generated by a little sh-script I'll also
enclose.
|
| |
|
|
|
|
| |
+ major and minor number elements in rtems_termios_open.
+ arg->ioctl_return in rtems_termios_ioctl routine.
|
| |
|
|
| |
for the network driver attach entry point.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) In my haste to add C++ constructor/destructors to the 68360
linkcmds scripts I managed to break all existing 68360 programs.
Linker scripts which actually produce a working executable are
contained below. The problem was that the constructor/destructors
weren't included before the etext symbol.
On top of that Eric and I appear to have problems with attachments:
2) In deciphering the above problem I think I stumbled across the
reason you've had with patches mailed from me. I noticed that the
linkcmds (and linkcmds.bootp) scripts in the latest distribution have
a control-M (carriage return) at the end of each line. Could you
check the files below before installing them in the distribution and
see that there aren't returns in the files? Maybe if I send
everything as a tar attatchment things will work better.
|
| |
|
|
| |
properly reflect the const on the buffer pointer being passed in.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
interpreted at the right point per Eric Norum's discovery:
The problem with the my previous `fix' for adding linker commands
was with the ordering of the options to the linker.
For example, to make a larger heap size, the application Makefile would
CFLAGS_LD = -Wl,--defsym -Wl,HeapSize=0x40000
The command passed to the linker would be :
m68k-rtems-ld .... -T xxx/linkcmds .... --defsym HeapSize=0x40000 .....
This doesn't work because the script in linkcmds inserts a default
value for HeapSize if HeapSize is not defined by the time the linker
looks at the linkcmds script.
The solution seems to be to move the -T linkcmds%s in the bsp_specs
file out of the link specfication and into the lib specification -- a
little unorthodox, perhaps, but it seems to work!
|
| | |
|
| |
|
|
| |
switch which lets the user specify a different linker script.
|
| |
|
|
| |
just in this directory.
|
| |
|
|
|
| |
any directory in the build tree. The only variable which must be set
before the command "gmake" is invoked is RTEMS_BSP (e.g. RTEMS_BSP=erc32).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
<pmcnr@camoes.rnl.ist.utl.pt> and Jose Rufino <ruf@asterix.ist.utl.pt>
of NavIST (http://pandora.ist.utl.pt/).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
