aboutsummaryrefslogtreecommitdiff
path: root/board/st/common
AgeCommit message (Collapse)Author
2020-07-07board: st: move type-c stusb1600 controller code in a driverPatrick Delaunay
Migrate the ST Microelectronics STUSB160X Type-C controller code in a generic I2C driver in st/common, based on Linux one in : drivers/usb/typec/stusb160x.c This patch simplifies the stm32mp1 board code and allows to reuse this STUSB160X driver in other boards. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-07-07board: st: stm32mp1: increase teed partitionPatrick Delaunay
With TEE 3.7.0, the partition teed (OP-TEE pageable code and data) need to increase up to 512KB in NOR device. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-07-07board: stm32mp1: update vddcore in SPLPatrick Delaunay
For board using STPMIC1, the vddcore is provided by BUCK1 of STPMIC1 and need to be updated for 800MHz support and only after the clock tree initialization. The VDDCORE voltage value is provided by clock driver, saved in global variable opp_voltage_mv and udpated in SPL board_early_init_f(), just after clock tree initialization. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-07-07board: st: stpmic1: add function stpmic1_initPatrick Delaunay
Add a function stmpic_init to early initialize the PMIC STPMIC1 - keep vdd on during the reset cycle (to avoid issue when backup battery is absent) - Check if debug is enabled to program PMIC according to the bit This patch allows to remove the compilation of spl.c file from stm32mp1 board in dh_stm32mp1. CONFIG_SPL_BOARD_INIT is removed as the new function is called earlier in SPL, in the function board_early_init_f. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-07-07board: st: create common file stpmic1.cPatrick Delaunay
Move function board_ddr_power_init() in a new file stpmic1 in board/st/common to avoid duplicated code in each board using stpmic1 Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-05-18command: Remove the cmd_tbl_t typedefSimon Glass
We should not use typedefs in U-Boot. They cannot be used as forward declarations which means that header files must include the full header to access them. Drop the typedef and rename the struct to remove the _s suffix which is now not useful. This requires quite a few header-file additions. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18part: Drop disk_partition_t typedefSimon Glass
We should not be using typedefs and these make it harder to use forward declarations (to reduce header file inclusions). Drop the typedef. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-14stm32mp: stm32prog: adapt the MTD partitionsPatrick Delaunay
Dynamically adapt the MTD partitions in NOR/NAND/SPI-NAND when stm32prog command detects in the parsed flash layout files: - a fsbl partition in NOR. - a tee partition in NOR/NAND/SPI-NAND Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-05-14stm32mp: add the command stm32progPatrick Delaunay
Add a specific command stm32prog for STM32MP soc family witch allows to program the boot devices with the tool STM32CubeProgrammer (http://www.st.com/STM32CubeProg). This command uses the same UART STM32 protocol than MCU STM32 with or USB with DFU protocol v1.1 (ithe MCU ST extension are no supported). The executed actions are based on a tab separated value file with a stm32 header, the FlashLayout file (https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout). This file is parsed by the U-Boot command to: - initialize the devices - create the partition table on each device - initialize the DFU backend to access to not volatile memory (NOR/NAND/SD/eMMC) or to virtual device (OTP/PMIC) Up to STM32PROG_MAX_DEV (5) devices can be updated with a FlashLayout. The communication between U-Boot and STM32CubeProgrammer is done with the specific alternate configuration (see "AN5275: USB DFU/USART protocols used in STM32MP1 Series bootloaders" for details). The command stm32prog is executed when a boot from USB is detected (selected with bootpins) and we can program the boot devices with a simple command (on Windows or Linux): PC $> STM32_Programmer_CLI -c port=usb1 -w flaslayout.tsv 1/ the ROM code loads TF-A in embedded RAM (DFU or uart) 2/ TF-A loads flashlayout file and U-Boot in DDR (DFU or uart) 3/ U-Boot executes the stm32prog command (DFU or uart) Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-05-14board: stm32mp1: adapt MTD partition for BOOT from NOR or NANDPatrick Delaunay
Dynamically adapt the MTD partitions in NAND and SPI-NAND when boot from NOR or NAND/SPI-NAND is detected. This patch avoids to define the save MTD partition name for NOR and NAND devices and issue with latest kernel: only the needed MTD partitions are defined. For boot from NOR 1/ bootloader (TF-A, U-Boot and OP-TE) in NOR 2/ one large UBI partition in NAND For boot from NAND 1/ bootloader (TF-A, U-Boot and OP-TE) in MTD raw partition 2/ one large UBI partition Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-05-14stm32mp1: dynamically detect op-tee presencePatrick Delaunay
Activate OP-TEE driver for trusted and optee defconfig. This driver allows detection of TEE presence for boot from flash; CONFIG_STM32MP1_OPTEE is also removed. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-05-14stm32mp1: move MTDPART configuration in KconfigPatrick Delaunay
This patch reduces the stm32mp1 environment size and builds dynamically the MTD partitions with information from defconfig (CONFIG_MTDPARTS_...). Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-05-14stm32mp1: dynamically build DFU_ALT_INFOPatrick Delaunay
This patch reduces the stm32mp1 environment size and builds dynamically the DFU board configuration with gpt and mtd partitions and information from defconfig (CONFIG_DFU_ALT_RAM0). Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-05-14board: stm32mp1: move set_dfu_alt_info in st common directoryPatrick Delaunay
Move the stm32mp1 common code set_dfu_alt_info() in common directory, this patch reduce the maintenance effort on this generic part (not board dependent). Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-05-14board: stm32mp1: move board_get_mtdparts in st common directoryPatrick Delaunay
Move the stm32mp1 common code board_get_mtdparts() in common directory, this patch reduce the maintenance effort on this generic part (not board dependent). Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-03-24board: stm32mp1: add finished good in board identifier OTPPatrick Delaunay
Update the command stboard to support the updated coding of OTP 59 with finished good. The ST product codification have several element - "Commercial Product Name" (CPN): type of product board (DKX, EVX) associated to the board ID "MBxxxx" - "Finished Good" or "Finish Good" (FG): effective content of the product without chip STM32MP1 (LCD, Wifi, …) - BOM: cost variant for same FG (for example, several provider of the same component) For example - commercial product = STM32MP157C-EV1 - Finished Good = EVA32MP157A1$AU1 Booth information are written on board and these information is also saved in OTP59: bit [31:16] (hex) => Board id, MBxxxx bit [15:12] (dec) => Variant CPN (1....15) bit [11:8] (dec) => Revision board (index with A = 1, Z = 26) bit [7:4] (dec) => Variant FG : finished good (NEW) bit [3:0] (dec) => BOM (01, .... 255) The updated command is: stboard [-y] <Board> <VarCPN> <Revision> <VarFG> <BOM> And the displayed STMicroelectronics board identification is: Board: MB<Board> Var<VarCPN>.<VarFG> Rev.<Revision>-<BOM> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-03-24board: stm32mp1: stboard: lock the OTP after programmingPatrick Delaunay
Lock the OTP used for board identification for the ST boards after programming. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Acked-by: Patrice Chotard <patrice.chotard@st.com>
2020-03-24board: stm32mp1: read OTP in command stboardPatrick Delaunay
Read the value directly from the OTP and no more of the shadows to avoid the need of reboot after stboard command to have correct value. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Acked-by: Patrice Chotard <patrice.chotard@st.com>
2020-03-24board: stm32mp1: update command stboard on misc_write resultPatrick Delaunay
Update management of misc_write, which now return length of data after the commit 8729b1ae2cbd ("misc: Update read() and write() methods to return bytes xfered") Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Acked-by: Patrice Chotard <patrice.chotard@st.com>
2020-01-17stm32mp1: split board and SOC support for STM32MP15x familyPatrick Delaunay
Split the board and SOC support for STM32MP15x family and prepare the introduction of new boards with STM32MP15x. This path define the 2 configurations: - STM32MP15x: STM32MP15x soc support (new) - TARGET_ST_STM32MP15x: STMicroelectronics board support (choice) Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-01-17stm32mp1: move stboard command in board/st/common directoryPatrick Delaunay
Move the ST command in board/st/common, as this command is only used by ST board. Prepare the support in U-Boot of boards with STM32MP15x SOC but not STMicroelectronics. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>