1. Prepare crypto common code
2. Support list
- SHA
- ECC
NOTE: AES/RSA are to support in other works
NOTE: Compared to M487, M467's SHA supports context save & restore (DMA Cascade mode) and so no software fallback is needed.
NOTE: M467's ECC, following M487, goes partial-module replacement and it can just improve primitives e.g. point addition/doubling by 2X,
and cannot improve high level point multiplication because MbedTLS doesn’t open it.
To improve performance best, full-module replacement is needed.
NOTE: Continuing above, add support for Montgomery curve
1. For GCC, support multi-block .data/.bss initialization
2. HyperRAM is mapped to two regions: 0x0A000000 and 0x80000000
According to default system address map, 0x0A000000 is located at 'Code' region and 0x80000000 at 'RAM' region.
With MPU enabled on Mbed OS, 'Code' region is write-never and 'RAM' region execute-never.
0x80000000 is chosen because 'RAM' regioin is naturally for HyperRAM.
3. Configurable multi-function pins for HBI
4. To locate code/data at external HyperRAM:
- Specify __attribute__((section(".text.nu.exthyperram"))) for RO/.text/readonly section type
Invoke mbed_mpu_manager_lock_ram_execution()/mbed_mpu_manager_unlock_ram_execution() to run HyperRAM code
- Specify __attribute__((section(".data.nu.exthyperram"))) for RW/.data/readwrite section type
- Specify __attribute__((section(".bss.nu.exthyperram"))) for ZI/.bss/zeroinit section type
5. Add readme
1. Based on alpha version BSP (85564a2716548e7b6d6a79a490c6d94a24cf9bcf)
2. Continuing above, tweak BSP:
(1) Add EPWM_ConfigOutputChannel2() to enable below 1Hz and below 1% duty cycle for PWM output (m460_epwm.h/c).
(2) Add dummy RTC_WaitAccessEnable() for consistency with previous ports (m460_rtc.h).
3. Target NuMaker-M467HJ V0.1 board temporarily
4. Support Arduino UNO form factor for NUMAKER_IOT_M467 target
5. Enable export to Keil/IAR project
- tools/arm_pack_manager/index.json
- tools/export/iar/iar_definitions.json
RFC3315 specifies the following: "The relay agent MAY send the Interface-id
option to identify the interface on which the client message was received.
If a relay agent receives a Relay-reply message with an Interface-id
option, the relay agent relays the message to the client through the
interface identified by the option."
The current implementation of the DHCP relay reply handling, the interface
ID field from the server response is ignored. Managing the interface ID
is very important especially as DHCP requests/replies use link-local
addresses. The consequence of this is that the interface must always be
specified because the routing layer cannot guess the correct interface.
Moreover, Mbed provides a mechanism to enable/disable the interface ID
option on a DHCP relay instance, so it is important to fully support it.
The reason why this issue has not been discoverd until now is that the DHCP
relay is mainly used on systems that use only one interface (such as Wi-SUN
routers). By default, when no interface ID is specified for the socket, the
latter will choose 6loWPAN interface by default. This means that if two
interfaces are used on the same device, the 6loWPAN interface is always
selected.
The commit adds code to retrieve the interface-id value contained within
the DHCP relay reply message and write it to a control message header
that is added to the socket message. This tells the socket which
interface to choose. If the interface-id option is not enabled on the
relay, this procedure is simply ignored.
NominalPrescaler value needs to be as high as possible to ensure a good approximation of the target CAN speed.
Previous usage of macro IS_FDCAN_DATA_TSEG1 refers to (unsupported by Mbed ) FDCAN CAN controller settings and leads to too low prescaler values.
Usage Macro IS_FDCAN_NOMINAL_TSEG1 yields optimum results.
See also correct macro usage in line #158.
Fix an issue where CellularContext::do_connect_with_retry() does not call NSAPI_STATUS_GLOBAL_UP callback and validate_ip_address() on successful connect after failed try in blocking mode.
Fix an issue where CellularContext::do_connect_with_retry() does not call NSAPI_STATUS_GLOBAL_UP callback on successful connect after failed try in blocking mode.
Trying to inherit the STM32F412xE target makes the linker fail, since
__CRASH_DATA_RAM_START__ is not present. Comparing LD scripts with the
STM32F412xG (which has active targets) it seems that the xE variant has
missed some updates somewhere. Since the LD scripts are otherwise
identical, copying the (working) ones from STM32F412xG seems to do the
trick.
Also added flash_data.h which was missing and needed here and there
(copied from xG and updated to fit the xE flash layout).
cyliangtw
Chun-Chieh Li
YannCharbon
Martin Kojtal
Deepak V. Shreshti
Michał Majcherski
Jerome Coutant
Danny Goossen
Charles
chdelfs
Saeed Kazemi
Andreas Reichle
yutotnh
Henrik Persson
byq77
mbedmain
xiaohuizhang98
Jason Reiss