| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
|
| |
for the network driver attach entry point.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) In my haste to add C++ constructor/destructors to the 68360
linkcmds scripts I managed to break all existing 68360 programs.
Linker scripts which actually produce a working executable are
contained below. The problem was that the constructor/destructors
weren't included before the etext symbol.
On top of that Eric and I appear to have problems with attachments:
2) In deciphering the above problem I think I stumbled across the
reason you've had with patches mailed from me. I noticed that the
linkcmds (and linkcmds.bootp) scripts in the latest distribution have
a control-M (carriage return) at the end of each line. Could you
check the files below before installing them in the distribution and
see that there aren't returns in the files? Maybe if I send
everything as a tar attatchment things will work better.
|
| |
|
|
| |
properly reflect the const on the buffer pointer being passed in.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
interpreted at the right point per Eric Norum's discovery:
The problem with the my previous `fix' for adding linker commands
was with the ordering of the options to the linker.
For example, to make a larger heap size, the application Makefile would
CFLAGS_LD = -Wl,--defsym -Wl,HeapSize=0x40000
The command passed to the linker would be :
m68k-rtems-ld .... -T xxx/linkcmds .... --defsym HeapSize=0x40000 .....
This doesn't work because the script in linkcmds inserts a default
value for HeapSize if HeapSize is not defined by the time the linker
looks at the linkcmds script.
The solution seems to be to move the -T linkcmds%s in the bsp_specs
file out of the link specfication and into the lib specification -- a
little unorthodox, perhaps, but it seems to work!
|
| | |
|
| |
|
|
| |
switch which lets the user specify a different linker script.
|
| |
|
|
|
| |
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).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Change label names so they can be seen from the debugger.
Provide a start symbol -- gets rid of a loader warning message.
|
| | |
|
| |
|
|
|
|
| |
to lib/include.
Went to using a PROJECT_INCLUDE variable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Enable 68360 watchdog. The watchdog control register is a
`write-once' register, so the watchdog has to be enabled in the boot
roms if it is to be used at all. To make the change transparent I
added a default feed of the watchdog to the clock interrupt handler.
This can be overridden if the application wants to handle the
watchdog. The only difficulty with this change is that an
application has to either include the clock driver or handle the
watchdog explicitely. I don't think this is much of a problem since
I am pretty sure that almost every application includes the clock
driver.
|
| | |
|
| |
|
|
|
|
| |
Enable SDMA operation during FREEZE. It seems that
disabling SDMA during freeze makes the SMC channels
work erratically.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Also, I ran across a nasty problem the first time I tried
downloading and running an application compiled with the new
snapshot. To make a very long story short, the `start' in
...../m68k/gen6860/start360/start360.s must not be global. The
change is simple -- just remove the
.globl start
from start360.s.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
of switching to the modified GNU GPL.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
returned an error to using a single shared copy of this file.
|
| |
|
|
| |
implementation as all m68k BSPs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
was done based on the 3.6.0 release and had to be autoconf'ed locally.
It is turned on is the bsp enables it and it is not explicitly disabled
via the configure option --disable-tcpip. As many warnings as possible
were removed locally after the code was merged. Only the gen68360
and mvme136 bsps were compiled this way.
The ka9q port and network driver were submitted by Eric Norum
(eric@skatter.USask.Ca).
The network demo programs are not included in the tree at this point.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GNU autoconf. This is the first large step in allowing an RTEMS
user to perform a one-tree build (per crossgcc FAQ) including RTEMS
in the build process. With this change RTEMS is configured in
built in the same style as the GNU tools, yet retains the basic
structure of its traditional Makefiles (ala Tony Bennett).
Jiri Gaisler (jgais@wd.estec.esa.nl) deserves (and received)
a big thank you for doing this.
There are still issues to be resolved but as of this commit, all target
which can be built on a linux host have been using a modified version
of the source Jiri submitted. This source was merged and most targets
built in the tree before this commit.
There are some issues which remain to be resolved but they are primarily
related to host OS dependencies, script issues, the use of gawk
for hack_specs, and the dependence on gcc snapshots. These will
be resolved.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
up to 2.6
|
| | |
|
| |
|
|
| |
should be undone when the m68k-coff cross toolset is updated next time.
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
Contact information:
W. Eric Norum
Saskatchewan Accelerator Laboratory
107 North Road
University of Saskatchewan
Saskatoon, Saskatchewan, CANADA
S7N 5C6
|
