GitLab

Supported:
 - UART0 (57600)
 - SPI0 (non-DMA)
 - Ethernet
 - LPDDR
 - Env in SPI Flash

definition of CONFIG_MEM_NVM_UBOOT_OFF for those U-boot configuraitons
that do not require that macro.

U-boot to run from eNVM at offset 0x20000:

- to program that U-boot to eNVM: cptf 0x20000 ${loadaddr} ${filesize} 0
- to run that U-boot from eNVM: go 20375

are preformed manually, as per the test plan.

Take into account the delay t_{v(A_NE)} (4.5 ns) before the MCU outputs
the chips select signal A[23].

 * In order to switch the MCG to the PLL Engaged External mode (PEE
mode), it must pass the FLL Bypassed External mode (FBE mode) as an
intermediate step. See section `25.4.1 MCG Mode State Diagram` on page
656 of the K70 Reference Manual.
 * Enable and use the RTC clock for FLL when switching to the
FLL Bypassed External mode (FBE mode). We do this in `clock_fei_to_fbe()`
in `u-boot/cpu/arm_cortexm3/kinetis/clock.c` before switching to
the FBE mode. This is required, because:
   * In order to switch to the PLL Engaged External mode (PEE mode), we
must pass the FLL Bypassed External mode (FBE mode).
   * This FBE mode requires that there is a working FLL reference clock.
   * Only OSC0 clock (clock or oscillator at EXTAL0/XTAL0) or RTC clock
(oscillator at EXTAL32/XTAL32) can be used as reference clock for FLL.
   * In the K**-SOM/DNI-ETH configuration, nothing is connected to
EXTAL0, therefore we have to use the RTC clock as reference clock
for FLL in the FBE mode.
 * Use RTC for FLL reference clock only on K**-SOMs, but not for
TWR-K70F120M. To do that, we add a new U-Boot configuration option
`KINETIS_FLLREF_RTC` that will control usage of RTC for FLL reference
clock and define this configuration option only in
`u-boot/include/configs/k70-som.h`.
 * Use in-MCU 20pF oscillator load.

 * Use external oscillator at EXTAL1/XTAL1 as clock source for the main
PLL on K70-SOM.
 * Do not change clock configuration for TWR-K70F120M.

Either CONFIG_KINETIS_120MHZ or CONFIG_KINETIS_150MHZ must be defined.
The TWR-K70F120M board has a 120MHz K70 MCU.

 * Add build-time U-Boot option CONFIG_KINETIS_120MHZ or
CONFIG_KINETIS_150MHZ to define the maximum core clock rate of the MCU.
 * Use different PLL configurations to reach to maximum clock rates and
performance.
 * Use different LPDDR timings depending on the clock rate.
 * Use different clock dividers for internal flash and external NAND
flash, as required by the respective datasheets.

Kinetis K61 does not have an LCD controller.

Increase NFC clock divider to put the NFC clock below rate limit.

The maximum NFC clock rate (19.23MHz) was calculated as follows:

 1. Assume we do not use NFC fractional divider, for simplicity.

 2. Look at the "RANDOM DATA READ" diagram on page 86 of the NAND flash
datasheet 5277m68a_1gb_nand.pdf and find out that data appear tREA
nanoseconds after RE# goes low. tREA is 16ns, according to the Table 23:
AC Characteristics: Norman Operation (3.3V) from page 78 of the NAND
flash datasheet 5277m68a_1gb_nand.pdf .

 3. Look at "Figure 14. Read data latch cycle timing in non-fast mode"
on page 42 of the MCU datasheet K70P256M120SF3.pdf and find out that
RE# must go high no later than
tIS nanoseconds after the data has appeared. tIS is 11ns for both
120MHz- and 150MHz-limited K70 MCUs, see NFC specifications in the MCU
datasheets: K70P256M120SF3.pdf and K70P256M150SF3.pdf.

 4. Therefore the minimum RE# low pulse width is tREA + tIS = 16ns +
11ns = 27ns.

 5. From the table Table 24. NFC specifications from the MCU datasheet
K70P256M150SF3.pdf we can calculate the minimum
T_L: NFC_RE# pulse width minimum value is T_L + 1 and is also 27ns, as
already calculated. Therefore minimum T_L is 26ns.

 6. Since we assume the NFC clock divider to be integer, the NFC clock
duty cycle is 50%, therefore T_L is half of the clock cycle. Maximum NFC
clock rate is therefore 1.0/2/26ns = 0.01923 GHz = 19.23 MHz.

These strings will follow the selection of CONFIG_KINETIS_K61 or
CONFIG_KINETIS_K70:
 1. Hostname;
 2. U-Boot prompt;
 3. `platform_kinetis=[...]` in kernel parameters line;
 4. Board name.

 are used in cmd_somtest.c module.

Modify timings to support -6 LPDDR parts along with -5 parts.

Actel board (the "Read Array" command there is 0xFF, not 0xF0).

 * Add Makefile target `lpc1850-eval_config`.
 * Set the system prompt to `LPC1850-EVAL> `.
 * Change CONFIG_MEM_NVM_LEN from 128 KBytes to 96 KBytes to match the
size of the largest continuous region of internal SRAM on LPC1850.
 * Adjust clock configuration for the 180MHz maximum core clock rate on
LPC1850: set the PLL1 multiplier value to 15.
 * Adjust SDRAM timings for the 180MHz maximum core clock rate on
LPC1850.
 * Adjust NOR flash timings for the 180MHz maximum core clock rate on
LPC1850.
 * Change default MAC address and IP address of the board defined in the
U-Boot environment.

Fix compiler warning: implicit declaration of function 'lpc18xx_reset_cpu'.

The common Cortex-M reset method does not work on LPC4350 for some
reason. This is why we configure the watchdog timer to reset the MCU for
us.

 * The Boot ROM bootloader loads only the first 32KBytes of U-Boot image
from the external 16-bit NOR flash. We make U-Boot load the remaining
contents of the image.
 * Put all function and data used for bootstrapping in the beginning
of the U-Boot image in sections `.lpc18xx_image_top_text` and
`.lpc18xx_image_top_data`.
 * Configure the boot pins to determine the boot source if the relevant
fields in the One-Time Programmable memory are not set.
 * Configure the remaining EMC pins before reading the whole U-Boot
image. The Boot ROM bootloader forgets to configure some EMC pins.
 * Reload the U-Boot image from NOR flash only when boot source is
`EMC 16-bit`.

 * This 16-byte header is required to boot U-Boot to the Hitex LPC4350 Eval
board over USB0. The same header is required to make the Boot ROM
bootloader boot images larger than 16KBytes from NOR flash.
 * The header will be automatically added to `u-boot.bin` if
CONFIG_LPC18XX_BOOTHEADER is enabled in the U-Boot configuration.

 * Reuse the code from EA-LPC1788's NOR flash support;
 * Improve NOR flash timings;
 * Place U-Boot environment at address 0x20000 (128 KBytes) in NOR
flash. We will store U-Boot image in the first 128 KBytes of NOR flash
when booting from NOR flash.
 * Place Linux kernel image at address 0x40000 (256 KBytes) in NOR
flash. We will store U-Boot image and U-Boot environment in the first
128 KBytes of NOR flash.

 * Write a custom Ethernet driver for LPC18xx/LPC43xx. We know the
Ethernet module is compatible with STM32F, but we do not want to spend
time right now to merge these drivers.
 * Use Ethernet MII mode.
 * Store Ethernet DMA buffers and buffer descriptors in a free region of
internal SRAM.

 * Use M4_CLK/2 = 102MHz for SDRAM clock;
 * Use best-performance timings for SDRAM.

With the former clock configuration procedure, the board used to hang
sometimes. Now U-Boot works stable at 204MHz M4 core frequency.

 - "somtest rtc start" starts the counter
 - "somtest rtc" displays the current counter
 - "somtest rtc stop" stops the counter

 * When Ethernet and/or LCD are extensively utilized, the DDR controller send
command to the memory chip very often, so that sometimes these commands go
back-to-back to one another. In this situation the value of the R2RSAME
parameter is taken into account by the DDR controller.
 * The necessary value for CR37[R2RSAME] was found experimentally. The K70
Reference Manual is very unclear on the exact meanings of delays set by the
fields of the DDR_CR37 register (including R2RSAME).

Import the existing LCD clock configuration done for TWR-K70F120M.

the flash writebuffer, otherwise flash writes are way to slow.

Support the following features:
 * Serial console on USART0.
 * Common pin configuration functions (needed for USART0).
 * Clock configuration: The Cortex-M4 core runs at 204 MHz.
 * `cptf` command is technically available, but has no effect since there is no
internal flash on LPC18x0/LPC43x0 MCUs.
 * The lowest SRAM region (128 KB at 0x10000000) is reserved for the currently
running U-Boot image.

configurable by the CONFIG_CMD_SOMTEST in a2f-som.h

I came up with these timings after experimenting, no underlying theory is
known to us yet.