* Support for armv7-m_dcache control via parameter
The FORCE_F7_DCACHE parameter can be set to
0 - (default) if Eratta exits turn dcache off else leave it on
1 - Force it off
2 - Force it on
At boot the system will disable the d-cache if the silicon
has the 1259864 Data corruption in a sequence of Write-Through
stores and loads eratta.
Post nsh script execution the FORCE_F7_DCACHE paramater
will be used to set the d-cache to the state indicated
above.
* The build is built with SPI4. At run time the signal GPIO_8266_GPIO2 it tested. If it is low the SPI4 is configured. If it is high SPI4 is not configured.
* board_common: Add Notion of Board has bus manifest
Upstream changes defer the board reset based on the vaule of
CONFIG_BOARD_RESET_ON_ASSERT
0 (or not defined) Do not reset on assert
>= 1 reset if assertion is in an interrupt handler or the idle task
>= 2 on any asertion.
up_assert is called from up_hardfault or an asertion failure.
Part 1 of up_assert will call out to the board_crashdump
Part 2 on return from board_crashdump will then perform
the reset.
board_crashdump needs a chunk of ram to save the complete
context in. It uses &_sdata which is the lowest memory and
it will corrupt that memeory. We can therfore can not allow
return to the OS, as it could depend on that area of RAM.
So all boards need to do a reset at the end of board_crashdump
This commit is the groundwork to fix the power LED
blinking on V5
Background:
----------
Early boards only had an AMBER LED that was used to
indicate a High Load condition.
This change defines the new logical inteface
the LED_<color> should not be used in application
code moving forward, only the minipulator macros
should be used.
Logical usage Legacy default
------------------------+-------------
BOARD_OVERLOAD_LED | LED_RED
Later boards defined BOARD_HAS_CONTROL_STATUS_LEDS
and added the use of a BLUE and GREEN LED that were
used as follows:
Logical usage Legacy default
------------------------+-------------
BOARD_ARMED_LED | LED_BLUE
BOARD_ARMED_STATE_LED | LED_GREEN
With this PR a board may now define _only_ a subset
the leds and map them at the board level to the
color LED it wants to use.
Logical usage Legacy default
------------------------+-------------
BOARD_OVERLOAD_LED | LED_RED
when BOARD_HAS_CONTROL_STATUS_LEDS is defined
BOARD_ARMED_LED | LED_BLUE
BOARD_ARMED_STATE_LED | LED_GREEN
If any of the BOARD_{OVERLOAD|ARMED|ARMED_STATE}_LED are not
defined. The code output generates a null action for that
LED.
David Sidrane