| 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> 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).
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
| |
now installed from the shared directory.
|
| |
|
|
| |
information to this file to be more like the gen68360.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
moves pieces of the pc386 bsp up to a shared level for all i386 BSPs
and modifies the i386ex BSP to use those shared pieces. Serial remote
debugging is included for both targets. Erik's notes:
There are several workarounds in it:
1) #define NEXT_GAS is hardcoded in pc386/start/start.s
2) #define NEXT_GAS is hardcoded in i386ex/start/start.s
3) #define NEW_GAS is hardcoded in pc386/start16.s
4) #undef __assert and redeclare _assert hardcoded in console.c for
both pc386 and i386ex due to my egcs1.1b ~ newlib problem. Should have
modified t-rtems.cfg ( no time )
I've tested pc386 with both video and serial consoles and GDB remote.
All work fine, except that GDB acts weird. ( re: other posting)
I hope this will work for you. It took quite some time to locate the
autoconf error. The remainder was just grunt work.
Unfortunately, I think I've unwound the removal of the IBMPCInitVideo
stuff. Sorry. I REALLY can't spend more time... I've been at this
conversion to 4.0 locally and updating the release since Sept. 8th, and
have yet to compile my network driver.... This is as much as I can do
right now.
I look forward to the next patch to really test i368ex. I did make sure
that the sample tests worked for pc386.
|
| |
|
|
|
| |
I have reworked the ethernet driver for the BSP pc386 and
here is the patch to apply.
|
| | |
|
| |
|
|
| |
inline with the new IRQ structure.
|
| |
|
|
| |
<raguet@crf.canon.fr> to make their patches work together.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Here is a patch for KA9Q stack.
This patch contains an Ethernet Driver for Western Digital,
some fixes for the UDP and TCP protocols (for endian conversion)
and some little programs which allow the test of UDP and TCP
sockets via Ethernet.
I have tested that on an Intel machine. If someone can test it
on a big-endian machine, ...
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Here is a enhanced version of my previous patch. This patch enables
to potentially share the new interrupt management code for all Intel targets
(pc386, go32 and force386) bsp.
Note : this patch is complete only for pc386. It still needs to
be completed for go32 and force386. I carrefully checked
that anything needed is in for force386 (only some function
name changes for IDT manipulation and GDT segment
manipulation). But anyway I will not be able to test any
of theses targets...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<qqi@world.std.com>). Unfortunately after merging these,
the pc386 will not boot using grub for for. It still does not
work using netboot for me. Here is his summary of changes:
rtems/c/src/lib/libbsp/i386/pc386/Makefile.in
Added support for new sub-directory
rtems/c/src/lib/libbsp/i386/pc386/bsp_specs
Made possible to build COFF image
rtems/c/src/lib/libbsp/i386/pc386/console/console.c
Added support for serial consoles, selectable by patching
binary image, added __assert(), use _IBMPC_inch_sleep()
instaed of _IMBPC_inch()
rtems/c/src/lib/libbsp/i386/pc386/console/inch.c
Added _IMBPC_inch_sleep()
rtems/c/src/lib/libbsp/i386/pc386/console/outch.c
Oops - just formatting
rtems/c/src/lib/libbsp/i386/pc386/include/Makefile.in
Added support for new files
rtems/c/src/lib/libbsp/i386/pc386/include/bsp.h
Added support for new features
rtems/c/src/lib/libbsp/i386/pc386/include/pc386uart.h
New file: definitions for serial ports
rtems/c/src/lib/libbsp/i386/pc386/include/pcibios.h
New file: definitions for PCI BIOS
rtems/c/src/lib/libbsp/i386/pc386/pc386dev/Makefile.in
New file: makefile in new directory
rtems/c/src/lib/libbsp/i386/pc386/pc386dev/i386-stub-glue.c
New file: i386-stub interface
rtems/c/src/lib/libbsp/i386/pc386/pc386dev/i386-stub.c
New file: i386-stub itself
rtems/c/src/lib/libbsp/i386/pc386/pc386dev/pc386uart.c
New file: serial ports
rtems/c/src/lib/libbsp/i386/pc386/pc386dev/pcibios.c
New file: PCI BIOS support
rtems/c/src/lib/libbsp/i386/pc386/start/start.s
Commented out DEBUG_EARLY stuff, everything is working fine
rtems/c/src/lib/libbsp/i386/pc386/start/start16.s
Cleaned up
rtems/c/src/lib/libbsp/i386/pc386/startup/bspstart.c
Added call to console_resereve_resources
rtems/c/src/lib/libbsp/i386/pc386/startup/exit.c
Added support for serial console
rtems/c/src/lib/libbsp/i386/pc386/startup/ldsegs.s
Fixed typo in comments
rtems/c/src/lib/libbsp/i386/pc386/tools/Makefile.in
Changed to reflect cnages in code
rtems/c/src/lib/libbsp/i386/pc386/tools/bin2boot.c
Trivialized, problem - I do not know how to make patch
remove obsolete files - there are a lot of them there
rtems/c/src/lib/libbsp/i386/pc386/tools/binpatch.c
New file: utility to do binary patches
rtems/c/src/lib/libbsp/i386/pc386/wrapup/Makefile.in
Added support for new directory
rtems/make/custom/pc386.cfg
Add COFF image building
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The breakdown:
* CC_FOR_TARGET and CXX_FOR_TARGET were not correctly re-read
from autoconf's configuration cache (config.cache)
* If <target>-[gcc|g++] was not found while running configure,
the config macros tried to use other (wrong) compilers (e.g. cc).
Changes:
* New RTEMS_PROG_CC macro (aclocal/prog-cc.m4).
* New RTEMS_PROG_CXX macro (aclocal/prog-cxx.m4)
* Moved a shell script fragment from configure.in to a
new m4-autoconf macro (New file: aclocal/tool-prefix.m4)
* Minor changes to configure.in
I tested it with linux/posix (native gcc/primary libc) and
sh-rtems/gensh1 on a linux host and didn't notice any bugs
related to the problems mentioned above. There seem to be
more bugs with the posix bsp, but I consider them minor as
the build run completed successfully. It is just too late
for me to attempt to fix them now.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
> 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.
|
| |
|
|
|
| |
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/).
|
