Changes to get a clean compile with the Kconfig Shenzhou board. Still some link issues

git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@5115 42af7a65-404d-4744-a932-0658087f49c3

1 files changed, 0 insertions, 212 deletions

diff --git a/nuttx/configs/shenzhou/README.txt b/nuttx/configs/shenzhou/README.txt
index a74cefd68..3508bbefe 100755
--- a/nuttx/configs/shenzhou/README.txt
+++ b/nuttx/configs/shenzhou/README.txt
@@ -558,14 +558,6 @@ Shenzhou-specific Configuration Options
     CONFIG_STM32_SPI_DMA - Use DMA to improve SPI transfer performance.
       Cannot be used with CONFIG_STM32_SPI_INTERRUPT.
 
-    CONFIG_SDIO_DMA - Support DMA data transfers.  Requires CONFIG_STM32_SDIO
-      and CONFIG_STM32_DMA2.
-    CONFIG_SDIO_PRI - Select SDIO interrupt prority.  Default: 128
-    CONFIG_SDIO_DMAPRIO - Select SDIO DMA interrupt priority.
-      Default:  Medium
-    CONFIG_SDIO_WIDTH_D1_ONLY - Select 1-bit transfer mode.  Default:
-      4-bit transfer mode.
-
     CONFIG_STM32_PHYADDR - The 5-bit address of the PHY on the board
     CONFIG_STM32_MII - Support Ethernet MII interface
     CONFIG_STM32_MII_MCO1 - Use MCO1 to clock the MII interface
@@ -678,30 +670,6 @@ can be selected as follow:
 
 Where <subdir> is one of the following:
 
-  dhcpd:
-  -----
-
-    This builds the DCHP server using the apps/examples/dhcpd application
-    (for execution from FLASH.) See apps/examples/README.txt for information
-    about the dhcpd example.  The server address is 10.0.0.1 and it serves
-    IP addresses in the range 10.0.0.2 through 10.0.0.17 (all of which, of
-    course, are configurable).
-
-    CONFIG_STM32_CODESOURCERYW=y  : CodeSourcery under Windows
-
-  nettest:
-  -------
-
-    This configuration directory may be used to verify networking performance
-    using the STM32's Ethernet controller. It uses apps/examples/nettest to excercise the
-    TCP/IP network.
-
-    CONFIG_EXAMPLE_NETTEST_SERVER=n                       : Target is configured as the client
-    CONFIG_EXAMPLE_NETTEST_PERFORMANCE=y                  : Only network performance is verified.
-    CONFIG_EXAMPLE_NETTEST_IPADDR=(10<<24|0<<16|0<<8|2)   : Target side is IP: 10.0.0.2
-    CONFIG_EXAMPLE_NETTEST_DRIPADDR=(10<<24|0<<16|0<<8|1) : Host side is IP: 10.0.0.1
-    CONFIG_EXAMPLE_NETTEST_CLIENTIP=(10<<24|0<<16|0<<8|1) : Server address used by which ever is client.
-
   nsh:
   ---
     Configures the NuttShell (nsh) located at apps/examples/nsh.  The
@@ -899,183 +867,3 @@ Where <subdir> is one of the following:
 
     11. This configuration requires that jumper JP22 be set to enable RS-232
        operation.
-
-  nsh2:
-  -----
-
-    This is an alternative NSH configuration.  One limitation of the Shenzhou
-    board is that you cannot have both a UART-based NSH console and SDIO support.
-    The nsh2 differs from the nsh configuration in the following ways:
-
-    -CONFIG_STM32_USART3=y      : USART3 is disabled
-    +CONFIG_STM32_USART3=n
-
-    -CONFIG_STM32_SDIO=n        : SDIO is enabled
-    +CONFIG_STM32_SDIO=y
-
-    Logically, these are the only differences:  This configuration has SDIO (and
-    the SD card) enabled and the serial console disabled. There is ONLY a
-    Telnet console!.
-
-    There are some special settings to make life with only a Telnet
-
-    CONFIG_SYSLOG=y - Enables the System Logging feature.
-    CONFIG_RAMLOG=y - Enable the RAM-based logging feature.
-    CONFIG_RAMLOG_CONSOLE=y - Use the RAM logger as the default console.
-      This means that any console output from non-Telnet threads will
-      go into the circular buffer in RAM.
-    CONFIG_RAMLOG_SYSLOG - This enables the RAM-based logger as the
-      system logger.  This means that (1) in addition to the console
-      output from other tasks, ALL of the debug output will also to
-      to the circular buffer in RAM, and (2) NSH will now support a
-      command called 'dmesg' that can be used to dump the RAM log.
-
-    There are a few other configuration differences as necessary to support
-    this different device configuration. Just the do the 'diff' if you are
-    curious.
-
-    NOTES:
-    1. See the notes for the nsh configuration.  Most also apply to the nsh2
-       configuration.  Like the nsh configuration, this configuration can
-       be modified to support a variety of additional tests.
-
-    2. RS-232 is disabled, but Telnet is still available for use as a console.
-       Since RS-232 and SDIO use the same pins (one controlled by JP22), RS232
-       and SDIO cannot be used concurrently.
-
-    3. This configuration requires that jumper JP22 be set to enable SDIO
-       operation.  To enable MicroSD Card, which shares same I/Os with RS-232,
-       JP22 is not fitted.
-
-    4. In order to use SDIO without overruns, DMA must be used.  The STM32 F4
-       has 192Kb of SRAM in two banks:  112Kb of "system" SRAM located at
-       0x2000:0000 and 64Kb of "CCM" SRAM located at 0x1000:0000. It appears
-       that you cannot perform DMA from CCM SRAM.  The work around that I have now
-       is simply to omit the 64Kb of CCM SRAM from the heap so that all memory is
-       allocated from System SRAM.  This is done by setting:
-
-       CONFIG_MM_REGIONS=1
-
-       Then DMA works fine. The downside is, of course, is that we lose 64Kb
-       of precious SRAM.
-
-    5. Another SDIO/DMA issue.  This one is probably a software bug.  This is
-       the bug as stated in the TODO list:
-
-       "If you use a large I/O buffer to access the file system, then the
-        MMCSD driver will perform multiple block SD transfers.  With DMA
-        ON, this seems to result in CRC errors detected by the hardware
-        during the transfer.  Workaround:  CONFIG_MMCSD_MULTIBLOCK_DISABLE=y"
-
-       For this reason, CONFIG_MMCSD_MULTIBLOCK_DISABLE=y appears in the defconfig
-       file.
-
-    6. Another DMA-related concern.  I see this statement in the reference
-       manual:  "The burst configuration has to be selected in order to respect
-       the AHB protocol, where bursts must not cross the 1 KB address boundary
-       because the minimum address space that can be allocated to a single slave
-       is 1 KB. This means that the 1 KB address boundary should not be crossed
-       by a burst block transfer, otherwise an AHB error would be generated,
-       that is not reported by the DMA registers."
-
-       There is nothing in the DMA driver to prevent this now.
-
-  nxconsole:
-  ----------
-    This is yet another NSH configuration.  This NSH configuration differs
-    from the others, however, in that it uses the NxConsole driver to host
-    the NSH shell.
-
-    Some of the differences in this configuration and the normal nsh configuration
-    include these settings in the defconfig file:
-
-    These select NX Multi-User mode:
-
-      CONFG_NX_MULTIUSER=y
-      CONFIG_DISABLE_MQUEUE=n
-
-    The following definition in the defconfig file to enables the NxConsole
-    driver:
-
-      CONFIG_NXCONSOLE=y
-
-    The appconfig file selects examples/nxconsole instead of examples/nsh:
-
-      CONFIGURED_APPS += examples/nxconsole
-
-    Other configuration settings:
-
-      CONFIG_STM32_CODESOURCERYW=y  : CodeSourcery under Windows
-      CONFIG_LCD_LANDSCAPE=y        : 320x240 landscape
-
-  nxwm
-  ----
-    This is a special configuration setup for the NxWM window manager
-    UnitTest.  The NxWM window manager can be found here:
-
-      trunk/NxWidgets/nxwm
-
-    The NxWM unit test can be found at:
-
-      trunk/NxWidgets/UnitTests/nxwm
-
-    Documentation for installing the NxWM unit test can be found here:
-
-      trunk/NxWidgets/UnitTests/README.txt
-
-    Here is the quick summary of the build steps:
-
-    1. Intall the nxwm configuration
-
-       $ cd ~/nuttx/trunk/nuttx/tools
-       $ ./configure.sh shenzhou/nxwm
-
-    2. Make the build context (only)
-
-       $ cd ..
-       $ . ./setenv.sh
-       $ make context
-       ...
-
-    3. Install the nxwm unit test
-
-       $ cd ~/nuttx/trunk/NxWidgets
-       $ tools/install.sh ~/nuttx/trunk/apps nxwm
-       Creating symbolic link
-        - To ~/nuttx/trunk/NxWidgets/UnitTests/nxwm
-        - At ~/nuttx/trunk/apps/external
-
-    4. Build the NxWidgets library
-
-       $ cd ~/nuttx/trunk/NxWidgets/libnxwidgets
-       $ make TOPDIR=~/nuttx/trunk/nuttx
-       ...
-
-    5. Build the NxWM library
-
-       $ cd ~/nuttx/trunk/NxWidgets/nxwm
-       $ make TOPDIR=~//nuttx/trunk/nuttx
-       ...
-
-    6. Built NuttX with the installed unit test as the application
-
-       $ cd ~/nuttx/trunk/nuttx
-       $ make
-
-  ostest:
-  ------
-    This configuration directory, performs a simple OS test using
-    examples/ostest.  By default, this project assumes that you are
-    using the DFU bootloader.
-
-      CONFIG_STM32_CODESOURCERYW=y  : CodeSourcery under Windows
-
-  telnetd:
-  --------
-
-    A simple test of the Telnet daemon(see apps/netutils/README.txt,
-    apps/examples/README.txt, and apps/examples/telnetd).  This is
-    the same daemon that is used in the nsh configuration so if you
-    use NSH, then you don't care about this.  This test is good for
-    testing the Telnet daemon only because it works in a simpler
-    environment than does the nsh configuration.