| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
I use the m68k/efi332 BSP together with a home made board. After some
time of debugging I found that the m68020 CPU is used to build rtems.
This is not correct, because the 68332 does not have some of the 68020
features (no separate int stack ...). It is necessary to change this to
mcpu32. After a clean/make everything works fine.
|
|
with libchip.
|
|
Please find attached a new i386ex.cfg. It has been altered to change
the files that get generated with the .nxe extension to .coff. This
change is necessary to align the file names generated by "make-exe" to
the those referred to in the GDB.HOWTO found in the
i386/shared/comm directory. It has been successfully tested on ticker (
without GDB), and base_sp( with GDB ) . I just set a breakpoint and
continue...
|
|
|
|
cosmetic things.
|
|
As mentioned in other mails before, there is are minor inconsistencies in the
posix custom/*cfg files.
Linux-posix.cfg sets RTEMS_BSP=posix
FreeBSD-posix.cfg sets RTEMS_BSP=posix
Solaris-posix.cfg first sets RTEMS_BSP=posix, later it sets
RTEMS_BSP=solaris2
1. Setting RTEMS_BSP=posix is redunant to settings in default.cfg
2. The solaris variant of setting RTEMS_BSP is merely non-functional.
The patch attached to this mail should clean up this issue.
The patch was tested by building the posix bsp under
i686-pc-linux-glibc1/glibc2 and Solaris2.6 (I did not run any
rtems program, however) The HPUX9 and FreeBSD configuration files
were adapted in analogy to the solaris and linux configurations.
|
|
|
|
Here's a patch to get rid of the `#define RTEMS__mcpu32p__ 1' when
gen68360.cfg is being used as a companion for gen68360_040.cfg. The
old version worked because of the order of the conditional tests in
m68k.h (the check for __mc68040__ is before the test for
RTEMS__mcpu32p__) , but I think it might have been a little confusing
to others just getting started.
|
|
Finally I am through: I have found the last bugs that made RTEMS-
4.0-beta3 start on my ppc403 board from ROM. So now the '403
support is up to date again.
Roughly I have added the following features:
- support for the on-chip interrupt controller (in a separate module)
- interrupt support for the console device
- termios support for the console device
==============================================
Since the BSP behaivour changed in some details (console no
longer is polling, other memory layout etc) I have created a new
BSP "helas403" rather than changing the "papyrus" BSP. The old
"polled" console driver still sticks around in "console.c.polled"
To get the BSP up and running, I had to create the new BSP files
(derived from papyrus). Besides that, the following source areas
have been changed:
- c/src/lib/libcpu/powerpc/ppc403: changes to console driver, small
changes to clock driver, new "ictrl" interrupt controller driver
- c/src/exec/score/cpu/powerpc/ppc.h: some small changes
(added ppc403 characteristics like a exception vector prefix
register, some special register definitions). I am quite sure, they
are compatible with the existing sources, although I did not check
- c/src/exec/score/cpu/powerpc/cpu.c: There is one severe
limitation in the exception entries: Due to the current code
arrangement, the "branch absolute" to the ISR handler may only
jump to the first 128MByte or the last 128MByte of the 4GByte
address range. When the ppc403 is running out of ROM, the ROM
functions are located in the last 128MByte (0xFFF00000 and up).
These addresses were not handled correctly (sign reduced) in
"install_raw_handler". The change I added should work on existing
ppc BSPs aswell...
- c/src/lib/libc/termios.c: During my tests, I added one change you
sent me, so this patch will already be incorporated in the current
source tree.
There are some smaller changes, see the attached diff file.
=========================================
Concerning the GNU toolchain:
I tried several tool chains. Finally I almost succeeded with
egcs-1.0.3a with patch egcs-1.0.3-rtems-diff-19980527
I had to add the following lines to the egcs files. Without them
configure complaint that the cross compiler could not generate
executable output.
- additional lines needed in egcs distribution in file
gcc/config/rs6000/rtems.h:
+++ lines start
#undef STARTFILE_DEFAULT_SPEC
#define STARTFILE_DEFAULT_SPEC "ecrti.o%s"
#undef ENDFILE_DEFAULT_SPEC
#define ENDFILE_DEFAULT_SPEC "ecrtn.o%s"
++++ lines end
As far as I have seen in the Changelog of egcs, you have recently
sent two patches affecting the powerpc support, but they were
added in the wrong order.... :-(
egcs-19980628 with patch egcs-19980628-rtems-diff-19980707 does
not work!
I used binutils 2.9.1 with patch binutils-2.9.1-rtems-diff-19980515
(binutils 2.8.1 does not work, internal error in gas)
and newlib-1.8.0 with patch newlib-1.8.0-rtems-diff-19980707
Finally I had to poke a line in the "bit" script, since, on my LINUX
machine, the GNU make is only available as "make", not as
"gmake"...
For all the tools and newlib I selected configuration "powerpc-
rtems".
--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler Herbststrasse 8
D-82178 Puchheim Germany
email: td@imd.m.isar.de
|
|
I found that my 68040/68360 test programs would not run even after
I fixed the `wrong BSP' problem.
It seems that there's a bug in the interrupt handling code for
processors with hardware interrupt stacks (e.g. 68040). The wrong
status register was getting pushed on the stack for the `return
from exception' to call _ISR__Dispatch. This ended up making
the context switch code run on the interrupt stack, so interrupt-driven
context switches would always fail.
I guess that no one has tried running any of the RTEMS-4.0 snapshots
on a 68040 machine!
Anyhow, here are the patches for
1) gen68360.cfg --- to fix the `wrong-BSP' problem.
2) m68k/cpu_asm.s --- to fix the hardware interrupt stack problem.
With these patches in place, the network demo programs run on my
68040/68360 system. The paranoia program runs with no failures,
defects nor flaws.
|
|
of the SONIC driver to the new FreeBSD stack instead of KA9Q.
|
|
Here is another patch to hopefully enhance rtems' configuration.
Motivation: Try to support other c-compilers besides gcc (I tried to
build rtems under Solaris using sun's WSPro c-compiler).
Here is a couple of small patches concerning the host compiler
configuration, which fix/work-around the worst problems when using sun's
WSPro c-compiler.
Changes:
* Replaced make/compilers/gcc.cfg with make/compilers/gcc.cfg.in, ie.
gcc.cfg is generated by configure now.
* Removed a line containing a hard-coded "gcc" from gcc.cfg (BUG-fix).
* Add -g to host compiler flags only if configure reported -g to work
* Add -Wall to host compiler flags only if configure reported that the
host compiler is gcc (WSPro's cc chokes on -Wall).
* Some modifications to make/Makefile.in
* Adapted make/custom/default.cfg to the new location of gcc.cfg
BTW, gcc.cfg/gcc.cfg.in seems to be full of unused code (DEBUG-VARIANTS
etc.) which deserves to be cleaned up, IMO.
IMO, a similar patch should be applied to gcc-target-default.cfg
|
|
|
|
|
|
It fixes netboot build problem, KA9Q configuration
for pc386, some compiler wardning, it also removed some stuff
ifdef'ed with '#if 0'.
|
|
|
|
|
|
|
|
|
|
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, ...
|
|
Changes to make/custom/gensh1.cfg. Needed for shgen support
|
|
Switched PPC_USE_SPRG to "0" so RTEMS use of sprg would not conflict with
any possible sprg usage by the DY-4 ROM monitor.
|
|
read from and write to a floppy.
|
|
Geoffroy Montel <g_montel@yahoo.com>.
|
|
I had trouble merging his original patch and this corrected a reject.
|
|
<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
|
|
made no attempt to divide the comments up and place them with just
the appropriate files. Here is an excerpt from Ralf's email:
Changes including comments on changes I made after cycling through
all the targets:
* Added ranlib support. Now all targets use "ranlib" instead of "ar -s"
to build an index for a library. If ranlib isn't detected during
configuration, check if ar -s is working and try "ar -s" instead of
* Removed $(XXX_FOR_TARGET) from make/target.cfg.in, use $(XXX) instead now.
* gcc-target-default.cfg: LINK_XXXX-defines reworked to solve the -l
problem under posix (cf gcc-target-default.cfg)
* rtems-glom replaced by Makefile-rules inside of the wrapup/Makefile.in
that has been using rtems-glom until now.
* Removed CCC and friends in gcc-target-default.cfg, as they have been
breaking CXX support.
* Removed CONFIG.$(TARGET_ARCH).CC lines from several custom/*.cfg
files, because this is now set in custom/default.cfg.
* Added aclocal/ar-s.m4, check whether "ar -s" is working
* Added aclocal/cygwin.m4 and aclocal/exeext.m4.
* Reworked aclocal/canonicalize-tools.m4: Added ar -s check; fixes for
problems when XXX_FOR_TARGET is given via environment variables (didn't
work for gcc until now), adding cygwin check, improved autoconf-cache
handling.
* Removed -l from make rule dependencies. LINK_LIBS is now allowed to
contain -L and -l. LINK_OBJS and LINK_FILES must not contain -L or -l.
gcc28 make-exe rules now link using $(LINK_OBJS) $(LINK_LIBS) => Almost
all custom/*.cfg are modified. This is very likely to break something
because of typos or having missed to edit a file.
Open problems, known bugs, things I didn't do:
* custom/p4000.cfg seems to be out of date and requires to be reviewed.
(JRS NOTE: It is subordinate p4650 and p4600 -- both of which build ok
after minor changes.)
* custom/psim.cfg needs to be reviewed, I added some changes to it, I am
insecure about.
(JRS NOTE: psim had a minor problem endif/endef swapped but runs fine.)
* rtems-glom.in can now be removed.
* gcc*.cfg files "make depend" rules don't honor language specific flags
(e.g CXXFLAGS is ignored for *.cc) - Nothing to worry about now, but may
cause problems for hosts/targets not using gcc or rtems-add-ons that use
external packages.
* AFAIS, the no_bsp BSP can't be build anymore, i.e. configure refused
to configure for it whatever I tried.
* The toplevel and toplevel+1 README files are quite out-dated
* cygwin.m4 isn't of much use for rtems. In most cases (cf.
aclocal/*.m4) it is worked around by directly using $host_os. I think
I'll remove it soon after the next snapshot
* Before release the cygwin patch needs to be tested under cygwin. I may
have broken/missed something (esp. the sed-pattern to convert \\ into /
may be broken).
* You should try to build/run the posix-BSP under solaris - I don't
expect problems, but I am not 100% sure, esp. with regard to ranlib/ar -s.
* You should consider to convert all make/compilers/*.cfg files into
make/compilers/*.cfg.in files and let autoconf generate the *.cfg. This
may help getting rid of some if/then/else statements and help
hard-coding some defines into those files in future and shouldn't
disturb now.
* Not having installed libc.a/libm.a on a host may still break building
rtems, esp. when using -disable-gcc28 as the gcc27-configuration scheme
directly accesses libc.a and libm.a. The problem should not appear when
using gcc28 because it references libc/libm only through -lc and -lm
which may be static or dynamic (I didn't test this).
* shgen is not yet included (I didn't yet have enough time to integrate it).
* I know about a few more configure-probs (esp. cross-checking
--enable-* flags).
+ warn/refuse to configure when --enable-libcdir and
--enable-gcc28 are given.
+ force --enable-libcdir when --disable-gcc28 is given
* Replaced KSHELL with @KSH@ in some shell scripts generated by configure.in.
* Added a dependency to aclocal/*.m4 in the toplevel Makefile => configure
and aclocal.m4 will now be rebuild when any aclocal/*.m4 file is changed
* Some changes to aclocal/gcc-pipe.m4 and aclocal/gcc-specs.m4
* Replaced i[[3456]]86-unknown-freebsd2.[[12]] with i[[3456]]86-*freebsd2.*
in configure.in, as I suppose there might exist a variety of valid vendors
(2nd field of the name-tripple)
* Disabled override MAKEFLAGS in toplevel Makefile.in - Potential
side-effects are not really clear to me.
* In mvme162.cfg, $(LINK_LIBS) is missing in the CC line in gcc28's make-exe
rule (yet another one I missed to edit). Just append $(LINK_LIBS) to
the "CC" line, like I hopefully did to ALL other custom/*.cfg files.
* the problem with mvme162lx.cfg is a follow-up problem of the
mvme162.cfg-bug.
* mvme162/console and idp/console had variables named Buffer which
conflicted with similarly named variables in some tests.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cleaned up command line macro definitions.
Per patch from Ralf Corsepius UNIX ports always needs C++ for rtems-ctor.cc.
|
|
|
|
build. It does not link successfully for him. It does not compile
for me locally.
|
|
lets the makefile work in both cases.
|
|
|
|
|
|
|
|
Modified gcc 2.8 style link rule to provide start address correctly.
|
|
|
|
|
