forked from Imagelibrary/rtems
bsps: Remove obsolete documentation
This patch is a part of the BSP source reorganization. Update #3285.
This commit is contained in:
@@ -1,69 +0,0 @@
|
|||||||
When adding a BSP to the RTEMS tree, there is usually some cleanup
|
|
||||||
to be done.
|
|
||||||
|
|
||||||
=========================================================================
|
|
||||||
|
|
||||||
Add an entry to ACKNOWLEDGEMENTS.
|
|
||||||
|
|
||||||
Send letter with permission to distribute the BSP with RTEMS.
|
|
||||||
|
|
||||||
Verify all test link.
|
|
||||||
|
|
||||||
Remove compilation warnings.
|
|
||||||
|
|
||||||
Make sure that all files submitted are really intended to do into
|
|
||||||
the distribution. For example, you may have a myfile.S produced by
|
|
||||||
gcc -S myfile.c.
|
|
||||||
|
|
||||||
=========================================================================
|
|
||||||
This section of the file describes how to run the acpolish script to
|
|
||||||
check Makefile style and construction compliance.
|
|
||||||
|
|
||||||
The BSP's still apply RTEMS's old autoconf configuration. The only thing
|
|
||||||
that have changed are some details inside the Makefile.ins and some details
|
|
||||||
in make/custom/<bsp>.cfg. Acpolish should be able to convert 4.0.0
|
|
||||||
Makefile.in into new style Makefile.ins. However, sometimes acpolish has
|
|
||||||
problems/contains bugs, which require manual intervention. There is no tool
|
|
||||||
to adapt a BSP's <bsp>.cfg, but this shouldn't be a problem for you.
|
|
||||||
|
|
||||||
Therefore, this is my coarse recipe to merge BSPs is:
|
|
||||||
|
|
||||||
1. Copy a BSP's files and directories to appropriate directories.
|
|
||||||
|
|
||||||
2. Manually run acpolish on each Makefile.in and check the output, eg:
|
|
||||||
cd some_subdir
|
|
||||||
/path_to_RTEMS/tools/update/acpolish < Makefile.old > Makefile.new
|
|
||||||
|
|
||||||
Check Makefile.new for correctness, evtl. edit it, then re-run acpolish
|
|
||||||
again:
|
|
||||||
/path_to_RTEMS/tools/update/acpolish < Makefile.new > Makefile.in
|
|
||||||
|
|
||||||
Compare Makefile.new against Makefile.in. These must not differ, if they
|
|
||||||
do, edit Makefile.new until the Makefile.in generated by re-running
|
|
||||||
acpolish on Makefile.new does not differ from the freshly generated
|
|
||||||
Makefile.in. If they differ permanently, then you probably are affected
|
|
||||||
bugs in acpolish (This happens for some styles of conditionals).
|
|
||||||
|
|
||||||
This sounds much worser than it actually is, because the bugs in acpolish
|
|
||||||
only hit very seldom. Furthermore, BSPs normally only contain a few
|
|
||||||
Makefile.ins, therefore individually running acpolish should be tolerable.
|
|
||||||
|
|
||||||
3. If a BSP contains tools, you have to convert its configuration to
|
|
||||||
automake manually. Typically these tools are rather simple, therefore a
|
|
||||||
tool's configuration applies standard automake Makefile.ams and
|
|
||||||
configure.ins. RTEMS should contain enough examples which could serve as
|
|
||||||
templates for this (My advice: Try to avoid preinstallation and
|
|
||||||
installation to the temporary installation tree whenever possible; Don't
|
|
||||||
forget to add all sources which do not get installed by automake
|
|
||||||
to automake's EXTRA_DIST, e.g. noinst_SCRIPTS, noinst_DATA have to be added
|
|
||||||
to EXTRA_DIST.
|
|
||||||
|
|
||||||
Please let me know if you meet problems and if we/I can fix them. I
|
|
||||||
consider acpolish to be an internal developer's and maintainer's helper
|
|
||||||
script, which was never intended to be of general use, which is why I am
|
|
||||||
not much concerned about bugs in it.
|
|
||||||
|
|
||||||
Ralf.
|
|
||||||
|
|
||||||
=========================================================================
|
|
||||||
|
|
||||||
@@ -1,42 +0,0 @@
|
|||||||
Board Support Package library
|
|
||||||
|
|
||||||
This directory contains the source for the libbsp.a library.
|
|
||||||
For each supported board $(RTEMS_BSP) there is a standard
|
|
||||||
set of functions which must be provided in the BSP:
|
|
||||||
|
|
||||||
+ start up initialization
|
|
||||||
+ exit support
|
|
||||||
+ set vector
|
|
||||||
+ console IO support
|
|
||||||
+ drivers
|
|
||||||
|
|
||||||
In addition, the BSP also determines the memory usage by providing
|
|
||||||
any necessary linker scripts.
|
|
||||||
|
|
||||||
There are also "generic" drivers in this directory. Currently
|
|
||||||
they are shmdr and stubdr.
|
|
||||||
|
|
||||||
Some of the supplied generic drivers (for example, shared memory) require
|
|
||||||
target board specific support routines.
|
|
||||||
|
|
||||||
NOTE: The library libbsp.a is actually built by $(RTEMS_BSP)/wrapup/Makefile.
|
|
||||||
|
|
||||||
To execute all of the test in the RTEMS Tests Suites the following
|
|
||||||
device drivers must be supplied:
|
|
||||||
|
|
||||||
+ Clock Tick
|
|
||||||
+ IO Driver Support
|
|
||||||
+ Timer
|
|
||||||
+ Shared Memory Driver Support
|
|
||||||
|
|
||||||
The Timer Driver is used only by the Timing Test Suite (c/src/tests/tmtests/*).
|
|
||||||
These tests are used to generate the execution times for RTEMS found in the
|
|
||||||
flyers. It is recommended that these tests be run to verify a port to a new
|
|
||||||
CPU or with a newly developed BSP. Looking at the times as compared to a
|
|
||||||
known CPU and target can yield insights into potential performance problems
|
|
||||||
in either the port, the BSP, or the target hardware.
|
|
||||||
|
|
||||||
The Shared Memory Support is only required to execute the Multiprocessor
|
|
||||||
Test Suite (c/src/tests/mptests/*). Multiprocessing is not a required part
|
|
||||||
of a BSP.
|
|
||||||
|
|
||||||
Reference in New Issue
Block a user