Mark pinctrl_wdog as u-boot,dm-spl to clean up board code,
The set_wdog_reset() function is not necessary as this is handled by
the imx_watchdog.c driver due to the 'fsl,ext-reset-output' property
being set.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Enable CONFIG_DM_SERIAL. uart3 and its pinmux was already
marked with u-boot,dm-spl.
Move preloader_console_init after spl_early_init to make sure driver
model work.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
I was trying to employ lpddr4_mr_read() to something similar to what
the imx8mm-cl-iot-gate board is doing for auto-detecting the RAM
type. However, the version in drivers/ddr/imx/imx8m/ddrphy_utils.c
differs from the private one used by that board in how it extracts the
byte value, and I was only getting zeroes. Adding a bit of debug
printf'ing gives me
tmp = 0x00ffff00
tmp = 0x00070700
tmp = 0x00000000
tmp = 0x00101000
and indeed I was expecting a (combined) value of 0xff070010 (0xff
being Manufacturer ID for Micron). I can't find any documentation that
says how the values are supposed to be read, but clearly the iot-gate
definition is the right one, both for its use case as well as my
imx8mp-based board.
So lift the private definition of lpddr4_mr_read() from the
imx8mm-cl-iot-gate board code to ddrphy_utils.c, and add a declaration
in the ddr.h header where e.g. get_trained_CDD() is already declared.
This has only been compile-tested for the imx8mm-cl-iot-gate
board (since I don't have the hardware), but since I've merely moved
its definition of lpddr4_mr_read(), I'd be surprised if it changed
anything for that board.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Tested-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Reviewed-by: Fabio Estevam <festevam@denx.de>
In arch/arm/mach-imx/imx8m/soc.c there's an implementation of
board_fix_fdt() introduced by commit 35bb60787b. Remove the
redundant one to avoid failed to build from source when enabling
CONFIG_OF_BOARD_FIXUP.
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: uboot-imx <uboot-imx@nxp.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Add a structure which defines the information that is needed for
executing capsule updates on a platform. Some information in the
structure like the dfu string is used for making the update process
more robust while some information like the per platform image GUIDs
is used for fixing issues. Initialise this structure in the board
file, and use the information for the capsule updates.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
The serial number is located at offset 0x14 of the EEPROM
under i2c0 bus at address 0x54.
To print the serial number in Linux:
SERNUM=$(cat /proc/device-tree/serial-number)
echo $SERNUM
Signed-off-by: Fabio Estevam <festevam@denx.de>
Currently, the DDR type is retrieved by iteracting inside an array
of possible DDR types.
This may take saveral attempts, which slows the overall U-Boot process
and does not provide a good user experience:
U-Boot SPL 2021.07 (Feb 28 2022 - 06:39:32 +0000)
DDRINFO: Cfg attempt: [ 1/6 ]
DDRINFO(M): mr5-8 [ 0xff000010 ]
DDRINFO(T): mr5-8 [ 0x5000010 ]
resetting ...
U-Boot SPL 2021.07 (Feb 28 2022 - 06:39:32 +0000)
DDRINFO: Cfg attempt: [ 2/6 ]
DDRINFO(M): mr5-8 [ 0xff000010 ]
DDRINFO(T): mr5-8 [ 0x1061010 ]
resetting ...
U-Boot SPL 2021.07 (Feb 28 2022 - 06:39:32 +0000)
DDRINFO: Cfg attempt: [ 3/6 ]
DDRINFO(M): mr5-8 [ 0xff000010 ]
DDRINFO(T): mr5-8 [ 0xff000010 ]
Normal Boot
WDT: Not starting
Trying to boot from MMC2
NOTICE: BL31: v2.5(release):v2.5
NOTICE: BL31: Built : 07:12:44, Jan 24 2022
Improve the boot time by retrieving the correct DDR information from
the EEPROM:
U-Boot SPL 2022.04-rc4-00045-g6d02bc40d58c (Mar 19 2022 - 08:22:29 -0300)
DDRINFO(D): Kingston 4096G
DDRINFO(M): mr5-8 [ 0xff000010 ]
DDRINFO(E): mr5-8 [ 0xff000010 ]
Normal Boot
WDT: Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from MMC2
NOTICE: BL31: v2.5(release):v2.5
NOTICE: BL31: Built : 22:28:11, Mar 15 2022
Based on the original code from Compulab's U-Boot.
Tested on a imx8mm-cl-iot-gate board populated with 4GB of RAM.
Signed-off-by: Fabio Estevam <festevam@denx.de>
imx8mm-cl-iot-gate supports multiple DDR sizes and models.
The DDR type can be retrieved from the EEPROM, so add SPL code
that can be used to get the DDR information.
Based on the original code from Compulab's U-Boot.
Signed-off-by: Fabio Estevam <festevam@denx.de>
This is supposed to be a build-system flag. Move it there so we can
define it before linux/kconfig.h is included.
Signed-off-by: Simon Glass <sjg@chromium.org>
Extension boards can be added to Compulab's iot-gate-imx8mm.
We implement extension board manager for detecting the extension
boards.
Signed-off-by: Uri Mashiach <uri.mashiach@compulab.co.il>
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: uboot-imx <uboot-imx@nxp.com>
When purchasing imx8mm-cl-iot-gate it is able to customize the
memory size. It could be 1GB, 2GB and 4GB. We implement
board_phys_sdram_size() to detect the memory size for usage.
Signed-off-by: Ying-Chun Liu (PaulLiu) <paulliu@debian.org>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Frieder Schrempf <frieder.schrempf@kontron.de>
Cc: uboot-imx <uboot-imx@nxp.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Currently imx8mm-cl-iot-gate_defconfig fails to produce a working boot
binary due to the lack of fip.bin:
" BINMAN all
Image 'main-section' is missing external blobs and is non-functional: blob-ext
Some images are invalid"
To make the build process more consistent with the other i.MX8M targets,
split the defconfig in two:
- imx8mm-cl-iot-gate_defconfig: standard defconfig that only
requires ATF / DDR firmware.
- imx8mm-cl-iot-gate-optee_defconfig: "more advanced" defconfig that
requires ATF / Optee / mbedtls / DDR firmware.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Tested-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
- Provide a default Kconfig value of the default script
- Largely continue to define this via the board Kconfig file
- For the boards that select a script based on defconfig rather than
TARGET, keep this within the defconfig.
Signed-off-by: Tom Rini <trini@konsulko.com>
