| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
configure scripts did not match on the default value of --enable-tests.
|
| | |
|
| | |
|
| | |
|
