| Commit message (Collapse) | Author | Files | Lines |
|---|
|
This is an attempt to work-around a couple of nasty bugs in librdbg's
Makefiles and configuration:
Configure and build RTEMS as below:
configure --enable-networking --enable-rdbg --target=i386-rtems
make RTEMS_BSP=i386ex
After a few minutes you will notice that building aborts in librdbg ....
Analysis:
1) librdbg is tried to be built, though librdbg is not supported and the
required directory hierarchy librdbg/i386/i386ex/ is not existant.
The cause for this is incorrect setting of HAS_RDBG in most
make/custom/*.cfg files (except pc386.cfg). At the moment all
custom/*.cfg files (except pc386.cfg) in general are required to contain
HAS_RDBG=no. However, having HAS_NETWORKING=no in most custom/*.cfg
files and the toplevel configure script suppress building librdbg for
all CPUs except of i386.
=> The i386ex BSP falls though this scheme and librdbg is tried to be
build (CPU=i386 and HAS_NETWORKING=yes).
2) The Makefile.ins below lib/librdbg in general support i386/pc386 only
and are not capable to be used for multiple CPUs or BSPs (RPCGEN
generates it's target and bsp-specific files into librdbg/, therefore no
other CPU or BSP can ever be built afterwards). This problem is hidden
until now, because only a single CPU/BSP pair (i386/pc386) is really
supported.
3) The Makefile.ins below lib/librdbg can delete source files due to
improper handling of source files (make clean removes the *.x files in
the source-tree when configuring inside of the source-tree).
The patch below tries to work-around these problems for the i386ex and
the pc386 BSPs. This work-around is rather fragile (it applies rpcgen
-D, I don't know how portable this is) and incomplete (all custom/*.cfg
except of pc386.cfg should contain HAS_RDBG=no), nevertheless it should
work.
|
|
|
|
FYI: I am not talking about using "make -C <dir>", which probably
is much faster on M$ hosts than RTEMS's implementation, but about
removing --enable-gmake-print support and to apply a variant of
automake's subdirectory.
Automake's subdirectory rule seems to be a little bit faster, but I
wouldn't bet on this.
Attached to this mail is my proposal.
After applying the patch, please run
cvs rm aclocal/enable-gmake-print.m4
./autogen
|
|
2) ./c/src/lib/libbsp/i386/go32/startup
> all: ${ARCH} $(SRCS) $(PGM)
> $(INSTALL_CHANGE) ${PROJECT_RELEASE}/lib
>
>
This also is very questionable, because it means "install
$(PROJECT_RELEASE)/$/lib to the void". I think, removing the
INSTALL_CHANGE is the right way to fix it.
|
|
1) ./c/src/lib/libbsp/i386/i386ex/startup/Makefile.in
> preinstall:
> $(INSTALL_CHANGE) ${IMPORT_SRC} .
>
> # ${CP} ${IMPORT_SRC} .
>
>
>
This fragment is broken, because IMPORT_SRC is always empty.
IMO, the fix would be to remove this fragment or to replace it with
test -z "${IMPORT_SRC}" || cp ${IMPORT_SRC} .
if an external shell variable IMPORT_SRC shall be supported by this
Makefile, which IMO should not be done.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Added multiprocessing conditional.
|
|
|
|
|
|
had not yet been debugged.
|
|
|
|
installed.
|
|
|
|
|
|
|
|
|
|
This first one below looked like it only belonged in a
virtual memory environment. The second one was causing
problems without the PROVIDE() - I don't know why.
|
|
defined.
|
|
by Andrew Bray <andy@madhouse.demon.co.uk>.
|
|
Installing of bsp_specs for aliased bsps is broken. Instead of installing
RTEMS_BSP_FAMILY/bsp_specs, RTEMS_BSP/bsp_specs was tried to be installed.
The patch below should fix this problem (tested with mips64orion p4600 and
p4650).
|
|
--enable-tests problem a better way.
|
|
This patch addresses a few minor issues and contains a few (minor)
preparations for automake.
* configure.in: Fix for handing c/src/tests subdirectory handling (FIX)
* aclocal/rtems-top.m4:
+ Add TARGET_SUBDIR and --with-target-subdir (preparation of future
enhancements for cross-compiling)
+ Activate RTEMS_ROOT handling (automake preparation)
* automake/*.am: replace comments "#" with "##" so that comments won't
get included into Makefile.in's anymore
* c/update-tools/* automake support (NEW)
* ./autogen update/enhancement (cf. ./autogen for details)
After applying this patch please run:
./autogen
cvs add c/update-tools/configure.in
cvs add c/update-tools/Makefile.am
cvs add c/update-tools/aclocal.m4
|
|
|
|
Date: Mon, 12 Apr 1999 00:38:04 +0000
From: Brendan Simon <brendan@dgs.monash.edu.au>
To: Jay Monkman <jmonkman@frasca.com>, "joel@OARcorp.com" <joel@oarcorp.com>
Subject: [Fwd: Goof in SMC initialize for mpc860]
Nick Simon reported this bug in the eth_comm BSP sources. I see that it is
still there in the latest snapshot that Joel sent me (thanks). I thought I
better forward this on to you guys.
Brendan.
Nick.SIMON@syntegra.bt.co.uk wrote:
> Sice I believe you're using the same base BSP as I am (you sent it to me) I
> thought I'd mention..
>
> In console-generic.c, in m860_smc_initialize, the receive buffer is malloced
> and assigned to RxBd[port+3]-> buffer - it should be [port-1].
>
> TTFN
B
|
|
|
|
In c/src/exec/score/cpu/powerpc/rtems/score/ppc.h:
A lot of hardware interrupts were omitted. Patch enclosed.
I have also added the 821.
In c/src/exec/score/cpu/powerpc/rtems/score/cpu.h:
My patch adds the 821.
In c/src/exec/score/cpu/powerpc/cpu.c:
I have added the MPC821, and also fixed up for the missing hardware
interrupts. It is also inconsistent with
c/src/lib/libcpu/powerpc/mpc860/vectors/vectors.S. This has been fixed.
In c/src/lib/libcpu/powerpc/mpc860/vectors/vectors.S:
Fixed an inconsistency with cpu.c.
I also include some new files to go with the above patches. These are the
cpu library rtems-19990331/c/src/lib/libcpu/powerpc/mpc821/* and
c/src/exec/score/cpu/powerpc/mpc821.h which are minor modifications of
the 860 equivalents.
Other comments:
The various accesses to the DPRAM on the 860 are done with a linktime
symbol. This could be done dynamically at run time by reading the immr
register, and masking off the lower 16 bits. This takes the same amount
of time as loading an address constant, and the same number of
instructions as well (2).
In c/src/lib/libcpu/powerpc/mpc860/console-generic/console-generic.c:
This will silently fail if you attempt to use SCC1. This is only relevant
if you are not using SCC1 for ethernet.
This file also sets one of port B output pins for each port. This is NOT
generic, it should be in the BSP specific console driver.
|
|
all bsp_specs.
|
|
|
|
|
|
In your various bsp_specs files, even when ecrti.o is defined as a
startfile, ecrtn.o is not defined as an endfile. Instead it seems to
be in the library list - untidy.
|
|
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.
|
|
|
|
sin_port.
|
|
on BSPs that install there own tools.
|
|
the reset of the CPU specific implementations after comment from
Eric Norum.
|
|
<e.norum@sk.sympatico.ca> and concerns from Thomas Doerfler
<td@imd.m.ISAR.de> when he submitted the patch:
Since enabling XON/XOFF has such a major performance hit on `smart' output
devices I think it should be *off* by default. I think some thought should
be given to adding hooks for hardware that can support XON/XOFF without
software intervention, or for hardware like the 68360 SCC's that can use
large buffers, but still handle special characters immediately.
The patch you sent is a very good start, though. I just think that the
software flow control should be off -- to match the way the serial I/O
support has worked up until now.
|
|
|
|
|
|
|
|
Some lines for "documentation":
======================================
One thing should be noted: when XON/XOFF is enabled, the serial
device will always work with one-character buffers, so the interrupt
load for the CPU might get higer, especially on devices like MC68360
and MPC860, where the serial channels are capable of using big
buffers. But, once again, this only happens when XON/XOFF is actually
selected.
Please note that the flag IXON is set by default, so outgoing
XON/XOFF flow control is enabled by default.
XON/XOFF is controlled using the "standard" fields IXON/IXOFF in the
termios structure. The termios flag IXANY is not (yet) supported.
Hardware handshake for the incoming data stream is controlled using
the standard flag CRTSCTS. If this flag is set, whenever the receive
buffer is almost full, the driver function "device.stopRemoteTx()" is
called, when the receive buffer has more space available,
"device.startRemoteTx()" is called again. If the driver does not
provide these interface functions (entries in device structure are
NULL pointers), then these calls are suppressed.
Changes of the flow control options during operation should work at
any time, but this has not been extensively tested.
No changes to the device driver interface are needed.
================================================
One critical point when using this patch might be, that any BSP using
this version of termios will now have outgoing flow control enabled
by default, so the behaviour of these BSPs will change here. The
option IXON has already been set in older termios by default, but it
did not work until this patch. Maybe this option should be switched
off by default, what do you think?
|
|
|
|
|
|
|
|
indicates an internal error.
|
|
|
