Fixed coding standard error in several files. Use of while( is incorrect; a space is required between while and (. Also ran tools/nxstyle and fix thoses complaints as well in most files.
Changes to comply with coding standard. Mostly focused on files with missing space after keyword in if(, switch(, and for(. Offending files also got changes to comply with tools nxstyle. If there were logs of nxstyle complaints, the file also got a taste of tools/indent.sh. Still need to fix occurrences of while( with missing space. There are a lot of them.
sched/init/nx_bringup.c: Fix a naming collision.
sched/init: Rename os_start() to nx_start()
sched/init: Rename os_smp* to nx_smp*
sched/init: Rename os_bringup to nx_bringup
sched/init: rename all internal static functions to begin with nx_ vs os_
Commit 8b63d0230936bd7d6bd94f4c76b9402946f69b21 was reverted. This related commit must now also be reverted to avoid compilation errors.
This reverts commit e8270defc9b26f7a7199288fa9ba203a96ed63d4.
- Avoids the use of up_aesinitialize() entirely, which resolves dependency problems, because this function does not make sure that an actual hardware aes implementation was made available: each SoC is now responsible to ensure the AES hardware is initialized before first use. This applies to lpc43xx, stm32 and sam34.
- Remove definitions of the NEVER used aes_init and aes_update operations. The new AES API will be more suitable.
- Change the unusual naming in stm32 (avoiding possible naming clashes)
- Change the unusual naming in sam34 (avoiding possible naming clashes)
- Add some FAR to pointers and enforce the 80 col limit in stm32 and sam
In addition to the problems that were previously identified there were a few other bits and pieces outstanding;
* Timing was dependent on CPU speed rather than absolute time
* End of transfer handling was a bit mixed up
* It's possible for data to still be in the FIFO (i.e. not have reached
the card) when a next write is requested, so we need to wait for that to
complete
* Interrupt Status could be carried over from one transfer episode to the
next, corrupting progress
* Multi-descriptor DMA writing simply wasn't implemented, but there were no
indications ... it just failed silently
* Clocks were wrongly configured - way too fast because there is no primary divider on LPC4330
This is fixed by means of changing the definitions in the board.h file. I've edited the one for the lpc4330-xplorer board because I'm actually working with Versiboard and don't want to contribute that config just yet while I've still got the drains up on it.
* The LPC43_SDMMC_DELAY register was not being set
I suspect, in the 'real world', it's possible to get away without setting this, but I've added a register definition, default value and register access macros into arch/arm/src/lpc43xx/chip/lpc43_scu.h and then used them in arch/arm/src/lpc43xx/lpc43_sdmmc.c.
* The LPC43_SDMMC_BLKSIZ and LPC43_SDMMC_BYTECNT registers had the wrong values.
The management have already implemented a rather nice block level interface for the stm32 so I've just re-used that to write to these registers as required. I'm slightly nervous that accessing the configuration registers (SCR being the prime example) which has a much smaller block size may not be being done in the right way but it does seem to work correctly, so let's assume it's all OK until someone tells me otherwise.
These fixes have been tested with DMA-based read/write on a LPC4330. Speed via nsh is pretty low but I'm assuming that's just a buffering/implementation issue for now.
arch/arm/src/lpc43xx: Fix ethernet TX_EN pin definitions
TX_EN on LPC43xx can be routed via P0.1 and PC.4 in both
MII and RMII mode.
Before, P0.1 was hardcoded for MII and PC.4 was hardcoded for RMII.
Also, the definitions used inconsistent naming (TXEN vs. TX_EN).
Approved-by: GregoryN <gnutt@nuttx.org>
arch/arm/src/lpc43xx: Make WWDT usable again
LPC43xx WWDT driver was not updated when irq_dispatch grew an argument
flag in b3222bbc8a18af33eef38a147165ee1999124b21.
Also fixes two typos and a naming inconsistency (WWDT vs. WWDG).
Approved-by: GregoryN <gnutt@nuttx.org>
This makes the user interface a little hostile. People thing of an MTU of 1500 bytes, but the corresponding packet is really 1514 bytes (including the 14 byte Ethernet header). A more friendly solution would configure the MTU (as before), but then derive the packet buffer size by adding the MAC header length. Instead, we define the packet buffer size then derive the MTU.
The MTU is not common currency in networking. On the wire, the only real issue is the MSS which is derived from MTU by subtracting the IP header and TCP header sizes (for the case of TCP). Now it is derived for the PKTSIZE by subtracting the IP header, the TCP header, and the MAC header sizes. So we should be all good and without the recurring 14 byte error in MTU's and MSS's.
Squashed commit of the following:
Trivial update to fix some spacing issues.
net/: Rename several macros containing _MTU to _PKTSIZE.
net/: Rename CONFIG_NET_SLIP_MTU to CONFIG_NET_SLIP_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes).
net/: Rename CONFIG_NET_6LOWPAN_MTU to CONFIG_NET_6LOWPAN_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes).
net/: Rename CONFIG_NET_ETH_MTU to CONFIG_NET_ETH_PKTSIZE. This is not the MTU which does not include the size of the link layer header. This is the full size of the packet buffer memory (minus any GUARD bytes).
net/: Rename the file d_mtu in the network driver structure to d_pktsize. That value saved there is not the MTU. The packetsize is the memory large enough to hold the maximum packet PLUS the size of the link layer header. The MTU does not include the link layer header.
arch/arm: Remove support for CONFIG_ARMV7M_CMNVECTOR. It is now the only vector support available. Also remove CONFIG_HAVE_CMNVECTOR. That no longer signifies anything."
arch/arm/src/stm32: This commit removes support for the dedicated vector handling from the STM32 architecture support. Only common vectors are now supported.
