| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> 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).
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
and placed in the right shareable directories.
|
| |
|
|
|
|
|
| |
Fixed bug where only the mbuf associated with the first TX fragment was
being freed.
|
| |
|
|
|
|
| |
to be a problem with overwriting the TX descriptors during an RX.
|
| |
|
|
|
|
|
| |
.s files to .S in conformance with GNU conventions. This is a
minor step along the way to supporting automake.
|
| |
|
| |
|
|
|
|
| |
of the SONIC driver to the new FreeBSD stack instead of KA9Q.
|
|
|
|
| |
a giant packet.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Redid interrupt handler to read imr/isr once and to write the imr once.
|
| |
|
|
|
|
|
| |
Fixed one important bug. After wrapping the RX Descriptors all had the
EOL bit set which resulted in everything slowing down massively.
|
| |
|
| |
|
|
|
|
| |
Problem appears to be on the RX buffer initialization side.
|
| |
|
|
|
|
|
|
| |
promiscuous mode.
It still dies somewhere between 16 and 20 pings.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moved CAM Descriptor types to sonic.h.
CAM memory is now malloced to insure it shares the same upper address bits.
Removed increment of RX interrupt count on TX interrupt path.
Added SONIC_DEBUG_FRAGMENTS and SONIC_DEBUG_CAM conditionals.
Fixed bugs in fragment manipulation. First bug was that the pad overwrote
the last fragment. The second bug was that the link information overwrote
the size of the last fragment.
Rewrote initialization of TDA to simplify it.
|
|
|
|
|
|
|
|
| |
and access routines.
Added revision constants.
Added in_use and EOL field values.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added pointer to RDA to sonic structure.
Added macro names for values used in the in_use field of RDA entries.
Rewrote the RX Descriptor Area initialization loop.
Added a check to barf if this is a Rev B sonic chip.
Enabled check that the CAM was properly loaded.
|
|
|
|
|
|
|
| |
types of debug information.
Removed call to rtems_panic which was based on checking a variable which
was no longer being set.
|
|
|
|
| |
Used existing constants for bits on the register.
|
|
|
|
|
| |
check for the presence of the DUART, SCC, and RTC. The SONIC check
needs to be added in the future as the network driver is libchip'ed.
|
|
|
|
| |
for the Data Configuration Register (DCR).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This primarily included setting the state of the programmable outputs
and the RX and TX FIFO depths.
Moved all of the TX, RX, and RRA data structure initialization to before
the hardware initialization. As part of this, the hardware initialization
was consolidated. More than likely, some of this movement broke stuff.
Used constants added to sonic.h which gave more logical names to some
of the register bit settings.
Switched to calloc to insure the data areas where initialized to 0.
Commented out a panic check in the RX server which may or may not have
been right.
Increased the size of the CAM initialization area. It is possible
that this could be decreased or code added to handle the management
of multiple hardware addresses.
Added sonic read and write register routines which aid greatly in
debugging and provide the core for the eventual movement of this
driver to libchip.
Added debug code to the read and write register routines which can
print the value read from or written to a register. This code also
prints the register name which significantly eases reading the log.
|
|
|
|
| |
help.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Registers are at 8 byte boundaries NOT 4 as initially configured.
|
| |
|