From c99e4f4e73645a806151bd8412ef3e738dd5b765 Mon Sep 17 00:00:00 2001 From: Sebastian Huber Date: Tue, 24 Apr 2018 06:19:15 +0200 Subject: bsps: Remove obsolete documentation This patch is a part of the BSP source reorganization. Update #3285. --- c/src/lib/libbsp/MERGE.PROCEDURE | 69 ---------------------------------------- c/src/lib/libbsp/README | 42 ------------------------ 2 files changed, 111 deletions(-) delete mode 100644 c/src/lib/libbsp/MERGE.PROCEDURE delete mode 100644 c/src/lib/libbsp/README diff --git a/c/src/lib/libbsp/MERGE.PROCEDURE b/c/src/lib/libbsp/MERGE.PROCEDURE deleted file mode 100644 index ee797b5146..0000000000 --- a/c/src/lib/libbsp/MERGE.PROCEDURE +++ /dev/null @@ -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/.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 .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. - -========================================================================= - diff --git a/c/src/lib/libbsp/README b/c/src/lib/libbsp/README deleted file mode 100644 index 9197f84bd1..0000000000 --- a/c/src/lib/libbsp/README +++ /dev/null @@ -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. - -- cgit v1.2.3