Cherrypick from master 2000-04-28 17:42:16 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'New files added on 4.5 branch.':
c/src/libnetworking/memory.h
c/src/libnetworking/sys/un.h
feedback from Eric Norum <eric@skatter.usask.ca> on static and
dynamic RAM sizing issues while still having as much shared
code as possible across the m68k BSPs.
Cherrypick from master 2000-04-05 13:27:52 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'New file. Copied from i386ex BSP as missing from submission.':
c/src/lib/libbsp/m68k/mvme167/network/Makefile.am
c/src/lib/libbsp/m68k/mvme167/network/netexterns.h
c/src/lib/libbsp/m68k/mvme167/network/network.c
c/src/lib/libbsp/m68k/mvme167/network/uti596.h
make/custom/Cygwin-posix.cfg
Ralf's description of the patch follows:
Now that make VARIANT=xxx has prooven not to be simple enough, I made up
my mind to change again the internals of the mechanism being used to
handle variants:
With the patch below, I introduce the indirection step I had mentioned
in one of my recent mails to translate settings of VARIANT.
The trick is to use the contents of VARIANT as keyword to lookup another
internal keyword (VARIANT_V), which then is used as keyword to lookup
values for setting ARCH, LIB_VARIANT, LIBSUFFIX_VA and AM_CFLAGS from
ARCH_$(VARIANT_V)_V etc. (cf automake/local.am).
This means, at first to translate
VARIANT=[optimize|OPTIMIZE] into VARIANT_V=OPTIMIZE
VARIANT=[debug|DEBUG] into VARIANT_V=DEBUG
VARIANT=[profile|PROFILE] into VARIANT_V=PROFILE
VARIANT=<anything> into VARIANT_V=<anything>
=> perform keyword conversion to uppercase and reduction from 6 to 3+1
internal keywords.
$(VARIANT_V) then is used to lookup make variables from other tables
(eg. CFLAGS_*_V). Eg. ARCH is set up this way:
ARCH_OPTIMIZE_V = o-optimize
ARCH_DEBUG_V = o-debug
ARCH_PROFILE_V = o-profile
ARCH__V = $(ARCH_OPTIMIZE_V)
ARCH = $(ARCH_$(VARIANT_V)_V)
Note the ARCH__V variable. When VARIANT=<anything> is passed to make,
VARIANT_V=<anything> will be set, resulting into ARCH =
$(ARCH_$(<anything>)_V) = $(ARCH__V) = $(ARCH_OPTIMIZE_V), ie. falling
back to OPTIMIZE.
=> o- or o-<anything> should never popup anymore.
The patch contains:
* make uninstall will only work if called from below
<target_alias>/c/<BSP> of if all BSPs in RTEMS_BSP_LIST have been built
previously (c/Makefile will choke otherwise). Not perfect but better
than nothing.
The patch contains:
* Many small cleanups wrt. make VARIANT=[DEBUG|PROFILE] support
* several modifications to make/custom/*.cfg
* Merger with the mvme2307.cfg you had posted two weeks ago (Please
check it, I did not check it against to version you posted today).
* Added a check to the toplevel configure.in to refuse building inside
of the source tree.
The patch contains:
* build variants support
* Reworked make-exe custom/*.cfg for all targets (Should be
self-explanatory, may still be incomplete)
* Several fixes to custom/*.cfgs related to setting debug flags
* Fixes to some bsp_specs for BSPs which apparently have never been
build with debugging before ;)
* pc386.cfg fix attempts (cf. my mail from earlier today)
* Updated ampolish (No need to run it, the patch contains the result
from having applied it)
Known bugs/deficiencies related to this work:
* "make [clean|distclean]" support is still incomplete (e.g. "make
clean" does not delete all Depends-o-*)
* Completely untested for linux/posix and hppa.
* Build failures of i960 BSPs (make VARIANT=DEBUG) - I guess, they are
not related to this patch.
* Successfully tested for all sh, sparc, i386, ppc, m68k BSPs (make
VARIANT=DEBUG)
* make VARIANT=PROFILE not supported by all BSPs (I don't care :)
* make VARIANT=DEBUG failures below tests/ for some BSPs (e.g. gensh1),
because of the tests's binaries being too large to fit into the target
memory layout.
a floating point support problem discovered with the mvme2307 BSP.
A floating point not available exception would occur when trying
to switch to a new thread with the floating point attribute.
Floating point instructions were disabled, but floating point
loads and stores were needed to save and/or restore the context.
not large enough to support high baud rates.
brg_spd[] is an array which stores the baud rates, for which one of the 4
available BRG dividers has been set. The array is used for deciding if a
BRG devider may be reused.
> 1. What baud_rate and divisor is causing this to fail?
divisor is dependent on the system clock (Cpu_table.clock_speed), and gets
calculated in m860_get_brg_cd.
m860_get_brg_clk fails for any baudrates > (2^16-1), as those baudrates are
truncated to 16 bit which is the size of a short. In fact, as it has been a
short and not an unsigned short, it will fail at any baudrate >(2^15-1). In
any case, it failed for my application, which required 250000 Baud.
that addresses the following:
* Duplicate variables in Makefiles (many Makefile.ams below c/src/test
are affected systematically)
* Erroniously using local.am instead of host.am in host-Makefile.am
(Only host Makefile.ams should be affected; Erroniously using local.am
in host-Makefiles doesn't desturb much)
* use '.' instead of '$pwd' in ./bootstrap (using $pwd does not work if
$pwd is a symlink on linux).
* Broken CVS Ids somewhere
* Removing redundant/obsolete make variables from *.cfg files.
Except of the last item from the list above, most parts of this patch
are fairly harmless, sometimes even cosmetical.
As mentioned before, this patch also contains a new ampolish script.
This script features:
* Pretty printing of Makefile.ams (eg. removal of trailing spaces,
removal of duplicate empty lines, pretty printing make variables, etc.).
* Some syntactical checks on the contents of Makefiles.am
* Proper handling of Automake conditionals
FYI:
* Applying tools/update/rtems-polish.sh -am completely reformats all
Makefile.am resulting into a very large (~500k) diff.
* Applying tools/update/rtems-polish.sh -am twice, finally does not
reformat the Makefile.ams anymore.
* Many parts of the patch above result from merging back issues which
have shown when applying this new ampolish (i.e. partially result from
extracting the essentials of reformating being proposed by applying it
on Makefile.ams).
Though this ampolish is a very nice tool, IMHO, I am hestitant if you
should apply (i.e. run tools/update/rtems-polish.sh -am) it to the
sources before the release, because
* the resulting diff is fairly large
* I am not 100% sure it doesn't break anything.
However, applying it after the release would result into compatibility
problems in applying patches ;)
I would suggest that you might consider trying it locally, then to
examine the diff and then to decide whether to apply it in general or
not.
Joel's Comments:
As Ralf points out, this patch is problematic in that applying it before
a release could break things but applying it afterwards will result in
patches being unusable for Makefiles. My inclination is to forge ahead
and apply it.
It seems to me I have found a bug in m860_smc_initialize(). This
function lives in
c/src/lib/libcpu/powerpc/mpc860/console-generic/console-generic.c.
The following lines are supposed to set the simode register with the
baud rate generator index, which has been returned from m860_get_brg_clk().
(line 386 of console-generic.c)
/*
* Put SMC in NMSI mode, connect SMC to BRG
*/
m860.simode &= ~0x7000 << ((port-1) * 8);
m860.simode |= brg << (12 + ((port-1) * 8));
This works well for port == 1 (SMC1), however for SMC2 (port == 2) it
fails. First, the simode register consists of 2 16bit parts (one for
SMC1 and SMC2 respectively), hence the shift count is wrong. Second ~0x7000
(which is 0xffff8fff is shifted left and pulls 0 from the right, which
kills the SMC1 entries, when written back to the simode register.
Substitute those lines by:
m860.simode &= ~(0x7000 << ((port-1) * 16));
m860.simode |= brg << (12 + ((port-1) * 16));
I have checked snapshot 20000218a which still contains the bug.
Also affected is libcpu/powerpc/mpc821/console_generic.c, which is a
cut&paste&substitue decendant of the mpc860 console-generic.c.
CVS: ----------------------------------------------------------------------
CVS: Enter Log. Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS: Tag: rtems-4-5-branch
CVS: console-generic.c
CVS: ----------------------------------------------------------------------
It seems to me I have found a bug in m860_smc_initialize(). This
function lives in
c/src/lib/libcpu/powerpc/mpc860/console-generic/console-generic.c.
The following lines are supposed to set the simode register with the
baud rate generator index, which has been returned from m860_get_brg_clk().
(line 386 of console-generic.c)
/*
* Put SMC in NMSI mode, connect SMC to BRG
*/
m860.simode &= ~0x7000 << ((port-1) * 8);
m860.simode |= brg << (12 + ((port-1) * 8));
This works well for port == 1 (SMC1), however for SMC2 (port == 2) it
fails. First, the simode register consists of 2 16bit parts (one for
SMC1 and SMC2 respectively), hence the shift count is wrong. Second ~0x7000
(which is 0xffff8fff is shifted left and pulls 0 from the right, which
kills the SMC1 entries, when written back to the simode register.
Substitute those lines by:
m860.simode &= ~(0x7000 << ((port-1) * 16));
m860.simode |= brg << (12 + ((port-1) * 16));
I have checked snapshot 20000218a which still contains the bug.
Also affected is libcpu/powerpc/mpc821/console_generic.c, which is a
cut&paste&substitue decendant of the mpc860 console-generic.c.
that fixes numerous miscellaneous issues most related to the debug and
profile build stanzas:
Fix for the "make debug" (1) issue and an analogous issue with "make
profile" (untested).
* Fixes to mcp750.cfg (make debug, directories) (2)
* Updates/minor fixes for shgen (3)
* Updates some custom/*.cfgs to use $(LINK.c) instead of $(CC)
* Leftovers from rtems-rc-4.5.0-[0|1].diff which somehow did not make it
into cvs.
* Cleanups to the perlscripts below tools/update/
* Some unsorted minor fixes.
Footnotes/Remarks:
(1) Tested for all m68k, sh, sparc, unix and selected i386, ppc BSPs.
Known problems: I can't build the debug variant for the m68k/mvme162 and
m68k/mvme162lx (segmentation fault - signal 11 :)
(2) Tested by building the BSP, but I doubt the debug-variant is
functional. The flags used for the debug variant should be checked by
knowledgeable persons and probably at runtime #:o)
(3) I have updated shgen to use getopt_long (it should fall back to
getopt if not available), enhanced the options, cleaned up some minor
tweaks and added help2man support (rough automatic man-page generation).
Technical notes:
* make debug and make profile now work similar in target Makefile.ams as
they did in old autoconf-Makefile.ins using leaf.cfg. Unlike the rules
in leaf.cfg these Makefile.am also recurse once on themselves in
directory Makefiles before or after recursing into subdirectories, not
only in leaf-directories.
To implement this behavior, I renamed the former automake/local.am into
automake/host.am and extended local.am to provide this recursion.
I.e. host.am implements the non-self-recursive variant, while local.am
now implements the self-recursive behavior.
=> all Makefile.ams exploiting build-variants are supposed to include
local.am
=> all Makefile.ams not exploiting build-variants should include host.am
=> Rules of thumb:
- Only include one of both, either local.am or host.am into a
Makefile.am.
-Target-Makefile.ams should include local.am
-Host-Makefile.ams should include host.am (Probably, you now understand
the naming)
- There are exceptions from these rules :)
* Now, make debug|profile|all are independent of each other. However,
each of them however triggers preinstall.
* "make install" still decends into the subdirectories but does not
trigger "all|profile|debug|preinstall" in target Makefile.am anymore.
Besides triggering "install"-rules in some selected Makefile.ams, it
only packs $(PROJECT_ROOT) into a tarballs and unpacks it to $(prefix).
=> "make install" alone is not enough to install RTEMS, now use
make RTEMS_BSP=<bsps> [all] [debug] [profile]
make RTEMS_BSP=<bsp> install
I consider this to be a step back wrt. exploiting automake mechanisms,
and expect this to be reverted if we abandon building target variants in
favour of the standard convention of optionally overriding flags from
the command line (i.e. instead of "make debug", GNU standards favor
"make CFLAGS=<options> --prefix=<location>")
that fixes numerous miscellaneous issues most related to the debug and
profile build stanzas:
Fix for the "make debug" (1) issue and an analogous issue with "make
profile" (untested).
* Fixes to mcp750.cfg (make debug, directories) (2)
* Updates/minor fixes for shgen (3)
* Updates some custom/*.cfgs to use $(LINK.c) instead of $(CC)
* Leftovers from rtems-rc-4.5.0-[0|1].diff which somehow did not make it
into cvs.
* Cleanups to the perlscripts below tools/update/
* Some unsorted minor fixes.
Footnotes/Remarks:
(1) Tested for all m68k, sh, sparc, unix and selected i386, ppc BSPs.
Known problems: I can't build the debug variant for the m68k/mvme162 and
m68k/mvme162lx (segmentation fault - signal 11 :)
(2) Tested by building the BSP, but I doubt the debug-variant is
functional. The flags used for the debug variant should be checked by
knowledgeable persons and probably at runtime #:o)
(3) I have updated shgen to use getopt_long (it should fall back to
getopt if not available), enhanced the options, cleaned up some minor
tweaks and added help2man support (rough automatic man-page generation).
Technical notes:
* make debug and make profile now work similar in target Makefile.ams as
they did in old autoconf-Makefile.ins using leaf.cfg. Unlike the rules
in leaf.cfg these Makefile.am also recurse once on themselves in
directory Makefiles before or after recursing into subdirectories, not
only in leaf-directories.
To implement this behavior, I renamed the former automake/local.am into
automake/host.am and extended local.am to provide this recursion.
I.e. host.am implements the non-self-recursive variant, while local.am
now implements the self-recursive behavior.
=> all Makefile.ams exploiting build-variants are supposed to include
local.am
=> all Makefile.ams not exploiting build-variants should include host.am
=> Rules of thumb:
- Only include one of both, either local.am or host.am into a
Makefile.am.
-Target-Makefile.ams should include local.am
-Host-Makefile.ams should include host.am (Probably, you now understand
the naming)
- There are exceptions from these rules :)
* Now, make debug|profile|all are independent of each other. However,
each of them however triggers preinstall.
* "make install" still decends into the subdirectories but does not
trigger "all|profile|debug|preinstall" in target Makefile.am anymore.
Besides triggering "install"-rules in some selected Makefile.ams, it
only packs $(PROJECT_ROOT) into a tarballs and unpacks it to $(prefix).
=> "make install" alone is not enough to install RTEMS, now use
make RTEMS_BSP=<bsps> [all] [debug] [profile]
make RTEMS_BSP=<bsp> install
I consider this to be a step back wrt. exploiting automake mechanisms,
and expect this to be reverted if we abandon building target variants in
favour of the standard convention of optionally overriding flags from
the command line (i.e. instead of "make debug", GNU standards favor
"make CFLAGS=<options> --prefix=<location>")
