bsps: Remove obsolete documentation

This patch is a part of the BSP source reorganization.

Update #3285.
This commit is contained in:
Sebastian Huber
2018-04-24 06:19:15 +02:00
parent 56bd37bfbe
commit c99e4f4e73
2 changed files with 0 additions and 111 deletions

View File

@@ -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.
=========================================================================

View File

@@ -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.