Commit graph

4 commits

Author SHA1 Message Date
Marek Vasut
d51b38762d ARM: imx: Reinstate decode ECSPI env location from i.MX8M ROMAPI tables
Decode ECSPI boot device in env_get_location() from i.MX8M ROMAPI tables.
This is necessary to correctly identify env is in SPI NOR when the system
boots from SPI NOR attached to ECSPI.

This reinstates change from commit:
e26d0152d6 ("ARM: imx: Decode ECSPI env location from i.MX8M ROMAPI tables")
which has been dropped in commit:
b0a284a7c9 ("imx: move get_boot_device to common file")

Fixes: b0a284a7c9 ("imx: move get_boot_device to common file")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
2023-01-30 23:23:01 +01:00
Peng Fan
787f04bb6a imx: add USB2_BOOT type
Add USB2_BOOT type for i.MX8ULP and i.MX9

Signed-off-by: Peng Fan <peng.fan@nxp.com>
2022-07-26 11:29:00 +02:00
Peng Fan
b0a284a7c9 imx: move get_boot_device to common file
i.MX8MN/P/ULP supports ROM API, they have almost same get_boot_device
implementation, so move to a common file. And when support i.MX9,
no need to include the other function copy.

Since sys_proto.h is included in imx_romapi.c, there will be build
warning for i.MX8M because wdog_regs not defined, so include imx-regs.h
in i.MX8M sys_proro.h

Signed-off-by: Peng Fan <peng.fan@nxp.com>
2022-07-26 11:29:00 +02:00
Rasmus Villemoes
748da8abb0 imx8: add rom api wrappers
The ROM API is thoroughly undocumented, but apparently passing the xor
of the real arguments as an extra argument is required [1]. Also, we
need to do the "save gd/restore gd" dance. These are both error-prone,
and lead to a lot of code duplication.

Since both imx8m[np] and imx8ulp SOCs have this, add a separate
translation unit which is included precisely when the new
CONFIG_IMX8_ROMAPI symbol is set, which provide convenience wrappers
that take care of computing the xor value as well as doing the gd
dance, and that thus have a more intuitive API. Subsequent patches
will make use of these to reduce boilerplate.

[1] One wonders, for example, if the check is only applied to the
lower 32 bits, or if we're implicitly relying on all 64-bit pointer
values we're passing effectively have 0 in the upper 32 bits.

Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
2022-07-25 15:35:34 +02:00