| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
I'd like to make the following change which adds the m360 structure
information to the debugging symbols in the final executable. This
makes it much easier to use the debugger to look at the elements of
the m360 structure.
|
|
|
|
| |
on BSPs that install there own tools.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
register support to this driver.
|
| |
|
|
|
|
|
|
| |
Emmanuel Raguet <raguet@crf.canon.fr> to eliminate a problem
during the boot process on the pc386 BSP. On fast PC's the
calibration routine would hand.
|
|
|
|
|
|
| |
Problem: Sometimes the output file "FOO.BT" is smaller that the second
image.
Solution: Opening files, input/output, in "binary mode".
|
|
|
|
| |
Ralf Corsepius <corsepiu@faw.uni-ulm.de>.
|
|
|
|
|
|
|
|
|
|
|
| |
With my most recent automake patch (automake II) we could even simplify more
files below make/, because the host-compiler related parts of those files
aren't used anymore :-.
Whatsoever, the patch below should fix this problem.
Note: This is a mere bug fix, it doesn't move any of the variables involved
to target.cfg nor does it try to eliminate any variable.
|
|
|
|
|
| |
network interface names. This change does not introduce any
compatibility problems.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
description follows:
Description:
* automake for *all* tool subdirectories (Makefile.am, configure.in etc.)
* autogen now also considers CONFIG_HEADER (generates stamp-h.ins and
config.h.ins)
* c/src/tests/tools/generic/difftest and
c/src/tests/tools/generic/sorttimes generated by configure scripts
* c/update-tools/ampolish, beautifier for Makefile.ams, similar to
acpolish
* rtems-polish.sh added to c/update-tools/ + ampolish support
* New subdirectory ./automake, contains automake -Makefile fragments to
support RTEMS make "debug, debug_install, profile, profile_install" for
native Makefile.ams (== ignore these make targets).
* aclocal/rtems-top.m4's RTEMS_TOP now reads the automake makefile
variable VERSION from RTEMS ./VERSION file.
* ./configure.in uses the macros from aclocal + support for the tools'
configure scripts
Remarks:
* To run rtems-polish.sh, "cd <rtems-source-tree>;
./c/update-tools/rtems-polish.sh"
* AFAIS, now all native subdirectories are converted to automake (Please
drop me a note, if I forgot something).
* Unless you notice something fatal, IMO the time has come for a public
try (== snapshot). I do not intend to send more automake related patches
within, say 2 weeks, to give these patches time to settle and to give me
some time to think on how to continue.
* The patch assumes installation to the new main installation directory
[$(prefix)].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is the most scary of all proposals I've been mailing to you
this week until now.
It consists of 3 parts:
1. a patch
2. a perl script (acpolish)
3. a shell script wrapper to invoke the perl-script.
The perl-script reads in each Makefile.in and modifies them
("polishes/beautifies" them :-).
These modifications are not easy to describe:
Basically, it hard-codes some automake Makefile-variables and rules into
RTEMS autoconf-Makefile.ins (Note: autoconf vs. automake!!) and converts
some settings/variables to configure scripts' requirements (Yes,
plural).
E.g. it adds the automake standard variables $top_builddir and $subdir,
adds dependency rules for automatic re-generation of Makefiles from
Makefile.in, adds support variables for relative paths to multiple
configure scripts etc.
The patch is a one-line patch to enable the support of the new features
added by acpolish.
The shell script is a wrapper which pokes around inside of the source
tree for Makefile.ins and invokes acpolish on all autoconf-Makefile.ins.
acpolish is designed to be able to run several times on the same
Makefile.in and may once become a more general tool to convert RTEMS
Makefile.in to automake. Therefore, I'd like to keep it inside of source
tree. (e.g. as contrib/acpolish or c/update-tools/acpolish). However, it
doesn't make sense to export it outside of RTEMS.
To apply this:
cd <source-tree>
patch -p1 -E < <path-to-patch>/rtems-rc-19990318-1.diff
tar xzvf <path-to>/rtems-rc-polish.tar.gz
./rtems-polish.sh
./autogen
Note: The path contrib/acpolish is hard-coded into rtems-polish.sh, if
you decide to put it in an alternative place, please modify
rtems-polish.sh to reflect this change.
Later:
cvs rm make/rtems.cfg (It isn't used anymore)
cvs add contrib
cvs add contrib/acpolish
cvs commit
I've tested this intensively, but naturally I can't exclude bugs.
Ralf.
PS.: Most probably, this is the last "Towards automake" patch. The next
one probably will be a real automake patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This one once again changes the scheme to preinstall bsp_specs.
It moves generating PROJECT_ROOT/lib/bsp_specs to
libbsp/<cpu>/<bsp>/wrapup/Makefile.in.
I.e. it decentralizes generation of bsp_specs to a bsp-dependent
directory, because preinstalling bsp_specs in a centralized Makefile
like it has been done until now does not harmonize well with spliting
the toplevel configure script in cpu and bsp-dependent configure scripts
and automake.
First apply the patch (rtems-rc-19990318-0.diff) below, then run the
reorg-bsp_specs.sh script.
IMO, this one is comparatively harmless and eases automake support
significantly.
|
|
|
|
|
|
| |
Erik Ivanenko pointed out a problem in the ne2000.c driver I
submitted: it did not work correctly with bootp. Here is a patch,
based on a patch he sent me.
|
|
|
|
|
|
|
|
|
|
|
| |
problems that prevented the 19990302 snapshot from running on
the efi332.
I'm happy to report that rtems-19990302 is running on the efi332
board. I have enclosed a few minor patches below to the efi332 bsp. All
patches are within that library but one. make/custom/efi332.cfg has a
patch to select the right CPU_CFLAGS (at one time -m68332 was a
problem... -mcpu32 or -m68332 work fine now).
|
|
|
|
| |
that shows up if the BSP uses memory near address 0.
|
|
|
|
| |
in the eth_comm BSP documentation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Comments follow:
Please find attached, the updated network driver. I have verified
that it is working as expected, by timestamping the error messages
generated from the ISR.
If you've taken a look inside, the network driver has a reset thread
in addition to the RX and TX threads. It is possible to avoid the
additional reset thread by allowing the TX driver to time out and then
checking status bits set by the ISR. However, this approach demands
that a transmission is necessary for the NIC to be reset.
Due to Eric V's ISR handling, I suppose that the reset routine could
be called from the "ISR" itself, due to the 8259 interrupt mode, and
that the interrupt is acknowledged prior to running the "ISR".
(Providing that no NIC interrupts are generated during reset -- I
worry about re-entrancy. )
This would be a minor improvement, but you know, I don't want to make
this driver my lifes work.
----------------------------------------------------------------------
----------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> 5) rtems-rc-19990202-1.diff/reorg-install.sh
>
> reorg-install.sh fixes a Makefile variable name clash of RTEMS
> configuration files and automake/autoconf standards.
> Until now, RTEMS used $(INSTALL) for install-if-change. Automake and
> autoconf use $(INSTALL) for a bsd-compatible install. As
> install-if-change and bsd-install are not compatible, I renamed all
> references to install-if-changed to $(INSTALL_CHANGED) and used
> $(INSTALL) for bsd-install (==automake/autoconf standard). When
> automake will be introduced install-if-change will probably be replaced
> by $(INSTALL) and therefore will slowly vanish. For the moment, this
> patch fixes a very nasty problem which prevents adding any automake file
> until now (There are still more).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FP issues on this target:
The default variants of libc, libm and libgcc assume that a 68881
coprocessor is present. Without the FPSP, any floating point operation,
including printf() with a "%f" format specifier, is likely to cause an
unimplemented instruction exception.
The FPSP works with the default variants of libc, libm and libgcc. It does not
work in conjunction with the msoft-float variants. The paranoia test goes into
an infinite loop at milestone 40. I am guessing that floor() is returning an
incorrect value.
The msoft-float variants of libc, libm and libgcc appear to do floating point
I/O properly. They only failed in paranoia. Offhand, I can't think of why they
would conflict with the FPSP, so I think that there is something wrong with the
msoft-float code. It might be my installation.
Given my experiences, I decided to install the FPSP in bsp_start(), and to link
against the default variants of libc, libm and libgcc. This causes the
executables to increase in size by about 60 KB. The README file and the
mvme167.cfg specify how to remove the FPSP, and how to link against the
msoft-float variants of the libraries. This is not what Eric Norum had done: on
my host, his gen68360_040 port links RTEMS code with the msoft-float variants
of libc and libm, and the default variant of libgcc. In this configuration, the
output of printf() with "%f" is garbage on my target.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
that were accidentally not committed earlier. The DECNet driver
is being added as its own directory to avoid forcing the driver to
have to pull in the complete set of network drivers.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both the ne2000 and the wd80x3 are based on the National Semiconductor
8390 chip, so there is a fair amount of overlap between the two
drivers. It would be possible in principle to combine some code into
a separate set of subroutines called by both. In fact, the drivers in
both OpenBSD and Linux work this way. I didn't bother, because for
the relatively simple drivers used by RTEMS, the overlap is not
especially large, and any reasonable use of subroutines would lead to
slightly less efficient code.
This ne2000 driver uses two transmit buffers. While one packet is
being transmitted over the Ethernet, RTEMS will upload another. Since
uploading a packet to the ne2000 is rather slow, I don't think there
is any point to having more than two transmit buffers. However, the
code does make it possible, by changing NE_TX_BUFS, although that
would of course reduce the number of receive buffers.
I suspect that the wd80x3 driver would benefit slightly from copying
the multiple transmit buffer code. However, I have no way to test
that.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> 5) rtems-rc-19990202-1.diff/reorg-install.sh
>
> reorg-install.sh fixes a Makefile variable name clash of RTEMS
> configuration files and automake/autoconf standards.
> Until now, RTEMS used $(INSTALL) for install-if-change. Automake and
> autoconf use $(INSTALL) for a bsd-compatible install. As
> install-if-change and bsd-install are not compatible, I renamed all
> references to install-if-changed to $(INSTALL_CHANGED) and used
> $(INSTALL) for bsd-install (==automake/autoconf standard). When
> automake will be introduced install-if-change will probably be replaced
> by $(INSTALL) and therefore will slowly vanish. For the moment, this
> patch fixes a very nasty problem which prevents adding any automake file
> until now (There are still more).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
./clock/clock.c,v
./console/Makefile.in,v
./console/config.c,v
./console/console.c,v
./console/console.h,v
./console/debugio.c,v
./console/i8042.c,v
./console/i8042_p.h,v
./console/i8042vga.c,v
./console/i8042vga.h,v
./console/ns16550.c,v
./console/ns16550.h,v
./console/ns16550_p.h,v
./console/ns16550cfg.c,v
./console/ns16550cfg.h,v
./console/vga.c,v
./console/vga_p.h,v
./console/z85c30.c,v
./console/z85c30.h,v
./console/z85c30_p.h,v
./console/z85c30cfg.c,v
./console/z85c30cfg.h,v
./include/Makefile.in,v
./include/bsp.h,v
./include/chain.h,v
./include/coverhd.h,v
./include/extisrdrv.h,v
./include/nvram.h,v
./include/pci.h,v
./include/tod.h,v
./network/Makefile.in,v
./network/amd79c970.c,v
./network/amd79c970.h,v
./nvram/Makefile.in,v
./nvram/ds1385.h,v
./nvram/mk48t18.h,v
./nvram/nvram.c,v
./nvram/prepnvr.h,v
./nvram/stk11c68.h,v
./pci/Makefile.in,v
./pci/pci.c,v
./start/Makefile.in,v
./start/start.s,v
./startup/Makefile.in,v
./startup/bspclean.c,v
./startup/bspstart.c,v
./startup/bsptrap.s,v
./startup/device-tree,v
./startup/genpvec.c,v
./startup/linkcmds,v
./startup/rtems-ctor.cc,v
./startup/sbrk.c,v
./startup/setvec.c,v
./startup/spurious.c,v
./startup/swap.c,v
./timer/Makefile.in,v
./timer/timer.c,v
./tod/Makefile.in,v
./tod/cmos.h,v
./tod/tod.c,v
./universe/Makefile.in,v
./universe/universe.c,v
./vectors/Makefile.in,v
./vectors/README,v
./vectors/align_h.s,v
./vectors/vectors.s,v
./wrapup/Makefile.in,v
./Makefile.in,v
./README,v
./STATUS,v
./bsp_specs,v
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
./clock/clock.c,v
./console/Makefile.in,v
./console/config.c,v
./console/console.c,v
./console/console.h,v
./console/debugio.c,v
./console/i8042.c,v
./console/i8042_p.h,v
./console/i8042vga.c,v./console/i8042vga.h,v
./console/ns16550.c,v
./console/ns16550.h,v
./console/ns16550_p.h,v
./console/ns16550cfg.c,v
./console/ns16550cfg.h,v
./console/vga.c,v
./console/vga_p.h,v
./console/z85c30.c,v
./console/z85c30.h,v
./console/z85c30_p.h,v
./console/z85c30cfg.c,v
./console/z85c30cfg.h,v
./include/Makefile.in,v
./include/bsp.h,v
./include/chain.h,v
./include/coverhd.h,v
./include/extisrdrv.h,v
./include/nvram.h,v
./include/pci.h,v
./include/tod.h,v
./network/Makefile.in,v
./network/amd79c970.c,v
./network/amd79c970.h,v
./nvram/Makefile.in,v
./nvram/ds1385.h,v
./nvram/mk48t18.h,v
./nvram/nvram.c,v
./nvram/prepnvr.h,v
./nvram/stk11c68.h,v
./pci/Makefile.in,v
./pci/pci.c,v
./start/Makefile.in,v
./start/start.s,v
./startup/Makefile.in,v
./startup/bspclean.c,v
./startup/bspstart.c,v
./startup/bsptrap.s,v
./startup/device-tree,v
./startup/genpvec.c,v
./startup/linkcmds,v
./startup/rtems-ctor.cc,v
./startup/sbrk.c,v
./startup/setvec.c,v
./startup/spurious.c,v
./startup/swap.c,v
./timer/Makefile.in,v
./timer/timer.c,v
./tod/Makefile.in,v
./tod/cmos.h,v
./tod/tod.c,v
./universe/Makefile.in,v
./universe/universe.c,v
./vectors/Makefile.in,v
./vectors/README,v
./vectors/align_h.s,v
./vectors/vectors.s,v
./wrapup/Makefile.in,v
./Makefile.in,v
./README,v
./STATUS,v
./bsp_specs,v
|
|
|
|
|
|
|
| |
You will find enclosed a patch which contains, for Intel PC386 target :
- an Ethernet driver for DEC21140 device based boards.
- a simple cache management with paging mechanism.
|
| |
|
|
|
|
| |
based board.
|
|
|
|
| |
undefined problem.
|
|
|
|
|
|
| |
portion is now in the libchip tree and the dmv177 configuration is in
the dmv177 bsp. The performance impact of libchip'ing this driver
was minimal.
|