Beginning to update comments to reflect new organization of the boards/ sub-directory.

This commit is contained in:
Gregory Nutt 2019-08-08 08:46:54 -06:00
parent 1e0987a729
commit 240926c995
29 changed files with 101 additions and 94 deletions

14
TODO
View file

@ -81,9 +81,9 @@ o Task/Scheduler (sched/)
As of this writing, the basic feature implementation is
complete and much of the logic has been verified. The test
harness for the feature exists only for the NXP LPC3131 (see
boards/ea3131/configs/pgnsh and locked directories). There are
some limitations of this testing so I still cannot say that
the feature is fully functional.
boards/arm/lpc31xx/ea3131/configs/pgnsh and locked
directories). There are some limitations of this testing so
I still cannot say that the feature is fully functional.
Status: Open. This has been put on the shelf for some time.
Priority: Medium-Low
@ -987,7 +987,7 @@ o Kernel/Protected Build
by simply reading this variable.
"This one would be easy: Just a change to include/nuttx/userspace.h,
boards/*/kernel/up_userspace.c, libs/libc/,
boards/<arch>/<chip>/<board>/kernel/up_userspace.c, libs/libc/,
sched/sched_addreadytorun.c, and sched/sched_removereadytorun.c.
That would eliminate 59% of the syscalls."
@ -1788,7 +1788,8 @@ o USB (drivers/usbdev, drivers/usbhost)
Title: USB CDC/ACM HOST CLASS DRIVER
Description: A CDC/ACM host class driver has been added. This has been
testing by running the USB CDC/ACM host on an Olimex
LPC1766STK and using the boards/stm3210e-eval/configs/usbserial
LPC1766STK and using the
boards/arm/stm32/stm3210e-eval/configs/usbserial
configuration (using the CDC/ACM device side driver). There
are several unresolved issues that prevent the host driver
from being usable:
@ -2230,7 +2231,8 @@ o File system / Generic drivers (fs/, drivers/)
file being read is smaller than number bytes written to the
file. That test does write small files continuously until
file system is full and even the the error is rare. The
boards/sim/configs/spiffs test can used to demonstrate the error.
boards/sim/sim/sim/configs/spiffs test can used to
demonstrate the error.
Status: Open
Priority: Medium. It is certain a file system failure, but I think that
the exposure in real world uses cases is very small.

View file

@ -32,7 +32,7 @@ o Board specific files. In order to be usable, the chip must be
peripheral LEDs, external peripherals (such as network, USB, etc.).
These board-specific configuration files can be found in the
boards/<board-name>/ sub-directories.
boards/<arch>/<chip>/<board> sub-directories.
This README will address the processor architecture specific files
that are contained in the arch/<arch-name>/ directory. The file

View file

@ -345,8 +345,8 @@ config ARCH_CHIP_STM32H7
STMicro STM32H7 architectures (ARM Cortex-M7).
BEWARE: This is a work-in-progress and not yet ready for general
usage. See boards/nucleo-h743zi/README.txt for the current state
of the port.
usage. See boards/arm/stm32/nucleo-h743zi/README.txt for the
current state of the port.
config ARCH_CHIP_STM32L4
bool "STMicro STM32 L4"

View file

@ -60,11 +60,11 @@
* NOTE:
* 1. Most DM320 memory sections can be programmed to lie at different locations in
* the memory map. Therefore, much of the DM320 physical memory map is really
* board-specific and, as such, really belongs in the boards/<board>/include/board.h
* file rather than here.
* board-specific and, as such, really belongs in the
* boards/arm/dm320/<board-name>/include/board.h file rather than here.
*
* To handle all cases, this file defines a "default" physical memory map, but
* section address for most regions can be overriden if the same setting is
* section address for most regions can be overridden if the same setting is
* defined in the board.h file (These defaults correspond to the product Neuros
* OSD memory configuration).
*

View file

@ -1,5 +1,5 @@
############################################################################
# boards/lpc4330-xplorer/src/Makefile
# arch/arm/src/lpc43xx/spfi/src/Make.defs
#
# Copyright (C) 2015 Gregory Nutt. All rights reserved.
# Author: Gregory Nutt <gnutt@nuttx.org>

View file

@ -83,9 +83,11 @@
/****************************************************************************
* Pre-processor Definitions
****************************************************************************/
/* Configuration ************************************************************/
/* See boards/stm3240g-eval/README.txt for an explanation of the configuration
* settings.
/* See boards/arm/stm32/stm3240g-eval/README.txt for an explanation of the
* configuration settings.
*/
#if STM32_NETHERNET > 1

View file

@ -90,8 +90,9 @@
#define MEMORY_SYNC() do { ARM_DSB(); ARM_ISB(); } while (0)
/* Configuration ************************************************************/
/* See boards/stm3240g-eval/README.txt for an explanation of the configuration
* settings.
/* See boards/arm/stm32/stm3240g-eval/README.txt for an explanation of the
* configuration settings.
*/
#if STM32F7_NETHERNET > 1

View file

@ -92,7 +92,7 @@
/* Configuration ************************************************************/
/* See boards/stm3240g-eval/README.txt for an explanation of the
/* See boards/arm/stm32/stm3240g-eval/README.txt for an explanation of the
* configuration settings.
*/

View file

@ -223,7 +223,7 @@ void up_consoleinit(void);
*
* Description:
* This function must be provided by the board-specific logic in the
* directory boards/<board-name>/src.
* directory boards/avr/at32uc3/<board-name>/src.
*
****************************************************************************/

View file

@ -128,7 +128,7 @@ void up_consoleinit(void);
*
* Description:
* This function must be provided by the board-specific logic in the
* directory boards/<board-name>/src/.
* directory boards/avr/at90usb/<board-name>/src.
*
****************************************************************************/

View file

@ -130,7 +130,7 @@ void up_consoleinit(void);
*
* Description:
* This function must be provided by the board-specific logic in the
* directory boards/<board-name>/src.
* directory boards/avr/atmega/<board-name>/src.
*
****************************************************************************/

View file

@ -234,7 +234,7 @@ void pic32mx_uartconfigure(uintptr_t uart_base, uint32_t baudrate,
*
* Description:
* This function must be provided by the board-specific logic in the directory
* boards/<board-name>/pic32_boot.c.
* boards/mips/pic32mx/<board-name>/src/pic32mx_boot.c.
*
************************************************************************************/

View file

@ -87,7 +87,7 @@ void pic32mz_lowinit(void);
*
* Description:
* This function must be provided by the board-specific logic in the directory
* <nuttx>/boards/<board-name>/pic32mz_boot.c.
* boards/mips/pic32mz/<board-name>/src/pic32mz_boot.c.
*
************************************************************************************/

View file

@ -1,5 +1,6 @@
This directory contains header files common to all SH architectures.
Sub-directories within this directory contain header files unique to
specific SH chip architectures. At configuration time, additional directories
will be linked here: 'build' will be a link to the boards/*/include
directory; 'chip' will be a link to the SH chip sub-directory.
specific SH chip architectures. At configuration time, additional
directories will be linked here: 'build' will be a link to the
boards/renesas/<chip>/<board>/include directory; 'chip' will be a link to
the SH chip sub-directory.

View file

@ -3,5 +3,5 @@ architectures. The 'common' subdirectory contains source files shared by
all Renesas architectures; Source files unique to a specific Renesas chip
architecture are contained in a subdirectory named after the chip. At
configuration time, additional directories will be linked here: 'board'
will be a link to the boards/*/src directory; 'chip' will be a link to
the SH chip sub-directory.
will be a link to the boards/renesas/<chip>/<board>/src directory; 'chip'
will be a link to the SH chip sub-directory.

View file

@ -127,15 +127,15 @@ config SIM_NET_HOST_ROUTE
---help---
Add a host route for the simulation that points to the created tap device. The
simulation will not be able to access the public network unless iptables is
configured to masquerade for it. See boards/sim/NETWORK-LINUX.txt for more
information.
configured to masquerade for it. See boards/sim/sim sim/NETWORK-LINUX.txt
for more information.
config SIM_NET_BRIDGE
bool "Attach to Linux bridge"
---help---
Add the created tap device to the specified bridge. You will need to manually
configure the bridge IP address (if any) and routes that point to the bridge.
See boards/sim/NETWORK-LINUX.txt for more information.
See boards/sim/sim/sim/NETWORK-LINUX.txt for more information.
endchoice
endif

View file

@ -1,7 +1,8 @@
/****************************************************************************
* arch/sim/src/up_internal.h
*
* Copyright (C) 2007, 2009, 2011-2012, 2014, 2016-2017 Gregory Nutt. All rights reserved.
* Copyright (C) 2007, 2009, 2011-2012, 2014, 2016-2017 Gregory Nutt.
* All rights reserved.
* Author: Gregory Nutt <gnutt@nuttx.org>
*
* Redistribution and use in source and binary forms, with or without

View file

@ -166,7 +166,7 @@ extern uint32_t _ebss; /* End+1 of .bss */
*
* Description:
* This function must be provided by the board-specific logic in the
* directory boards/<board-name>/src/.
* directory boards/x86/<chip>/<board>/src/.
*
****************************************************************************/

View file

@ -135,7 +135,7 @@ config ARCH_HAVEHEAD
default n
---help---
Use a board-specific version of the "head" file in the
boards/<board-name>/src directory
boards/z80/z180/<board>/src directory
menu "Z180 Peripheral Support"

View file

@ -16,20 +16,20 @@ z180_rom.asm
Some architectures may have ROM located at address zero. In this case, a
special version of the "head" logic must be used. This special "head"
file is probably board-specific and, hence, belongs in the board-specific
boards/<board-name>/src directory. This file may, however, be used as
a model for such a board-specific file.
boards/z80/z180/<board-name>/src directory. This file may, however, be
used as a model for such a board-specific file.
z180_rom.S is enabled by specifying CONFIG_LINKER_ROM_AT_0000 in the
configuration file.
A board specific version in the boards/<board-name>/src directory can be
used by:
A board specific version in the boards/z80/z180/<board-name>/src
directory can be used by:
1. Define CONFIG_ARCH_HAVEHEAD
2. Add the board-specific head file, say <filename>.asm, to
boards/<board-name>/src
3. Add a file called Make.defs in the boards/<board-name>/src directory
containing the line: HEAD_ASRC = <file-name>.asm
boards/z80/z180/<board-name>/src
3. Add a file called Make.defs in the boards/z80/z180/<board-name>/src
directory containing the line: HEAD_ASRC = <file-name>.asm
Make.defs
This is the standard makefile fragment that must be provided in all

View file

@ -16,20 +16,20 @@ z80_rom.asm
Some architectures may have ROM located at address zero. In this case, a
special version of the "head" logic must be used. This special "head"
file is probably board-specific and, hence, belongs in the board-specific
boards/<board-name>/src directory. This file may, however, be used as
a model for such a board-specific file.
boards/z80/z80/<board-name>/src directory. This file may, however, be
used as a model for such a board-specific file.
z80_rom.S is enabled by specifying CONFIG_LINKER_ROM_AT_0000 in the
configuration file.
A board specific version in the boards/<board-name>/src directory can be
used by:
A board specific version in the boards/z80/z80/<board-name>/src directory
can be used by:
1. Define CONFIG_ARCH_HAVEHEAD
2. Add the board-specific head file, say <filename>.asm, to
boards/<board-name>/src
3. Add a file called Make.defs in the boards/<board-name>/src directory
containing the line: HEAD_ASRC = <file-name>.asm
boards/z80/z80/<board-name>/src
3. Add a file called Make.defs in the boards/z80/z80/<board-name>/src
directory containing the line: HEAD_ASRC = <file-name>.asm
Make.defs
This is the standard makefile fragment that must be provided in all

View file

@ -1312,8 +1312,7 @@ config LCD_LCD1602
HD44780U LCD controller. See also include/nuttx/lcd/hd4478ou.h.
NOTE: There is no common implementation of the LCD1602 driver.
Rather, there are board-by-board implementations. See, for example,
boards/pcblogic-pic32mx/src/up_lcd1602.c.
Rather, there are board-by-board implementations.
config LCD_BACKPACK
bool "PCF8574 LCD Backpack"

View file

@ -62,17 +62,18 @@
* 2. include/nuttx/spi/spi_bitbang.h: This header file provides the
* data types and function prototypes needed to utilize the logic in
* this file.
* 3. boards/<board>/src/<file>: The implementation of the low-level
* bit-bang logic resides in some file in the board source directory.
* This board-specific logic includes the bit-bang skeleton logic
* provided in include/nuttx/spi/spi_bitband.c.
* 3. boards/<arch>/<chip>/<board>/src/<file>: The implementation of the
* low-level bit-bang logic resides in some file in the board source
* directory. This board-specific logic includes the bit-bang skeleton
* logic provided in include/nuttx/spi/spi_bitband.c.
* 4. include/nuttx/spi/spi_bitband.c. Despite the .c extension, this
* really an included file. It is used in this way: 1) The board-
* specific logic in boards/<board>/src/<file> provides some definitions
* then 2) includes include/nuttx/spi/spi_bitband.c. That file will
* then use those definitions to implement the low-level bit-bang
* logic. the board-specific logic then calls spi_create_bitbang()
* in this file to instantiate the complete SPI driver.
* specific logic in boards/<arch>/<chip>/<board>/src/<file> provides
* some definitions then 2) includes include/nuttx/spi/spi_bitband.c.
* That file will then use those definitions to implement the low-level
* bit-bang logic. the board-specific logic then calls
* spi_create_bitbang() in this file to instantiate the complete SPI
* driver.
*
* See include/nuttx/spi/spi_bitband.c for more detailed usage
* information.

View file

@ -69,25 +69,25 @@ fs/unionfs/README.txt
Example Configurations
----------------------
o boards/sim/unionfs - This is a simulator configuration that uses the
Union File System test at apps/examples/unionfs. That test overlays two
small ROMFS file systems with many conflicts in directories and file
names. This is a good platform for testing the Union file System and
apps/examples/unionfs is a good example of how to configure the Union
File System.
o boards/sim/sim/sim/unionfs - This is a simulator configuration that
uses the Union File System test at apps/examples/unionfs. That test
overlays two small ROMFS file systems with many conflicts in
directories and file names. This is a good platform for testing the
Union file System and apps/examples/unionfs is a good example of how to
configure the Union File System.
o boards/lincoln60/thttpd-binfs - This is an example using the THTTPD
web server. It server up content from a Union File System with fixed
content provided by a ROMFS file system and CGI content provided by a
BINFS file system.
o boards/arm/lpc17xx_40xx/lincoln60/thttpd-binfs - This is an example
using the THTTPD web server. It server up content from a Union File
System with fixed content provided by a ROMFS file system and CGI
content provided by a BINFS file system.
You can see how the Union File System content directory is configured
by logic in apps/example/thttpd/.
o boards/olimex-lpc1766stk/thttpd-binfs - This is essentially the same
as the lincoln60 configuration. It does not work, however, because the
LPC1766 has insufficient RAM to support the THTTPD application in this
configuration.
o boards/arm/lpc17xx_40xx/olimex-lpc1766stk/thttpd-binfs - This is
essentially the same as the lincoln60 configuration. It does not work,
however, because the LPC1766 has insufficient RAM to support the THTTPD
application in this configuration.
See the README.txt file in each of these board directories for additional
information about these configurations.

View file

@ -78,12 +78,12 @@
*
* 4. Board-Specific Interfaces.
*
* Any interface which is unique to a board should be prefixed with
* Any interface that is unique to a board should be prefixed with
* the board name, for example stm32f4discovery_. Sometimes the board
* name is too long so stm32_ would be okay too. These should be
* prototyped in boards/<board>/src/<board>.h and should not be used
* outside of that board directory since board-specific definitions
* have no meaning outside of the board directory.
* prototyped in boards/<arch>/<chip><board>/src/<board>.h and should
* not be used outside of that board directory since board-specific
* definitions have no meaning outside of the board directory.
*/
/****************************************************************************

View file

@ -75,21 +75,21 @@
*
* Board related declarations are retained in this header file.
*
* There is also a boards/<board>/include/board.h header file that
* can be used to communicate other board-specific information between
* the architecture logic and even application logic. Any definitions
* which are common between a single architecture and several boards
* should go in this board.h header file; this file is reserved for
* board-related definitions common to all architectures.
* There is also a boards/<arch>/<chip>/<board>/include/board.h header
* file that can be used to communicate other board-specific information
* between the architecture logic and even application logic. Any
* definitions that are common between a single architecture and several
* boards should go in this board.h header file; this file is reserved
* for board-related definitions common to all architectures.
*
* 4. Board-Specific Interfaces.
*
* Any interface which is unique to a board should be prefixed with
* Any interface that is unique to a board should be prefixed with
* the board name, for example stm32f4discovery_. Sometimes the board
* name is too long so stm32_ would be okay too. These should be
* prototyped in boards/<board>/src/<board>.h and should not be used
* outside of that board directory since board-specific definitions
* have no meaning outside of the board directory.
* prototyped in boards/<arch>/<chip>/<board>/src/<board>.h and should
* not be used outside of that board directory since board-specific
* definitions have no meaning outside of the board directory.
*/
#ifndef __INCLUDE_NUTTX_BOARD_H

View file

@ -1,5 +1,5 @@
/****************************************************************************
* boards/nuttx/spi/spi_bitbang.c
* include/nuttx/spi/spi_bitbang.c
*
* Copyright (C) 2013 Gregory Nutt. All rights reserved.
* Author: Gregory Nutt <gnutt@nuttx.org>

View file

@ -81,7 +81,7 @@ force rebuilding of the ROMFS filesystem be removing some files:
make
If you have problems building the simulator on your platform, check out
nuttx/boards/sim/README.txt. You might find some help there.
nuttx/boards/sim/sim/sim/README.txt. You might find some help there.
Here is a sample run. I have not seen any errors in single stepping through
the logic but neither am I certain that everything is working properly:

View file

@ -18,6 +18,6 @@ README
feature, look at apps/examples/module/drivers/Makefile. Kernel symbol
tables are needed to support kernel modules.
Of course, addition board-specific logic in, say, boards/<board>/src
would have to be included to make use of the application-installed symbol
tables.
Of course, addition board-specific logic in, say, at
boards/<arch>/<chip>/<board>/src would have to be included to make use of
the application-installed symbol tables.