The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This board is behind on several mandatory DM migrations and is missing
OF_CONTROL support that makes other conversions impossible. Remove it.
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Nikita Kiryanov <nikita@compulab.co.il>
Cc: Uri Mashiach <uri.mashiach@compulab.co.il>
Signed-off-by: Tom Rini <trini@konsulko.com>
Rename the sections used to implement linker lists so they begin with
'__u_boot_list' rather than '.u_boot_list'. The double underscore at the
start is still distinct from the single underscore used by the symbol
names.
Having a '.' in the section names conflicts with clang's ASAN
instrumentation which tries to add redzones between the linker list
elements, causing expected accesses to fail. However, clang doesn't try
to add redzones to user sections, which are names with all alphanumeric
and underscore characters.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
This option is used as part of configuring the default environment for a
number of platforms. However, it is always set to 1 and the only time
it is part of Kconfig, it is used in a hard-coded manner. Hard-code the
value in the environment instead.
Signed-off-by: Tom Rini <trini@konsulko.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>
Since cm_t35 was removed, CONFIG_CM_T3X does not exist. This lets us
simplify the code in board/compulab/common/eeprom.c a bit.
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Nikita Kiryanov <nikita@compulab.co.il>
Signed-off-by: Tom Rini <trini@konsulko.com>
With the exceptions of ds109, ds414, icnova-a20-swac, nokia_rx51 and
stemmy, disable ATAG support. A large number of platforms had enabled
support but never supported a kernel so old as to require it. Further,
some platforms are old enough to support both, but are well supported by
devicetree booting, and have been for a number of years. This is
because some of the ATAGs related functions have been re-used to provide
the same kind of information, but for devicetree or just generally to
inform the user. When needed still, rename these functions to
get_board_revision() instead, to avoid conflicts. In other cases, these
functions were simply unused, so drop them.
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Phil Sutter <phil@nwl.cc>
Cc: Stefan Bosch <stefan_b@posteo.net>
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_POWER_I2C
CONFIG_POWER_LEGACY
They are handled at the same time due to a dependency between them.
Update the Makefile rule to use legacy power only in U-Boot proper.
Unfortunately a separate rule is needed in SPL to be able to build
legacy power. Add SPL related symbols for both, to allow for SPL-only
usage.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[trini: More SPL related cleanups, reword commit message]
Signed-off-by: Tom Rini <trini@konsulko.com>
This option is used in pre-driver model code and much of it has never
been converted to driver model.
We want to add a new option to enable power support, so we can use a
simple rule in the Makefile. Rename this one, which is really about
a particular implementation of power.
Also update the pmic.h header file so it either includes the legacy
API or the driver model one.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Rename these options so that CONFIG_IS_ENABLED can be used with them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[trini: Fixup some incorrect renames]
Signed-off-by: Tom Rini <trini@konsulko.com>
- 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>
The omap24xx I2C driver uses its own CONFIG namespace for common I2C
variables. Rather than convert more of them to Kconfig, rename these to
the common I2C ones and remove the entirely unused functionality. As
part of this, we make the am335x_shc platforms consistent with their
intended speed values.
Signed-off-by: Tom Rini <trini@konsulko.com>
First, we convert CONFIG_SYS_I2C_LEGACY to Kconfig. Next, as you cannot
have SYS_I2C_LEGACY and DM_I2C at the same time, introduce
CONFIG_SPL_SYS_I2C_LEGACY so that we can enable the legacy option only
in SPL. Finally, for some PowerPC cases we also need
CONFIG_TPL_SYS_I2C_LEGACY support. Convert all of the existing users to
one or more symbols.
Signed-off-by: Tom Rini <trini@konsulko.com>
- Rename usages of CONFIG_SYS_DEF_EEPROM_ADDR to CONFIG_SYS_I2C_EEPROM_ADDR
based on current usage.
- Convert CONFIG_SYS_I2C_EEPROM_ADDR, CONFIG_SYS_I2C_EEPROM_ADDR_LEN,
CONFIG_SYS_I2C_EEPROM_BUS, CONFIG_CONFIG_SYS_EEPROM_SIZE
CONFIG_SYS_EEPROM_PAGE_WRITE_BITS and CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS
to Kconfig. We move these symbols around a bit and add appropriate
dependencies to them. In some cases, we now add a correct default value
as well.
Signed-off-by: Tom Rini <trini@konsulko.com>
It is a pain to have to specify the value 10 in each call. Add a new
dectoul() function and update the code to use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is quite confusing that CONFIG_SYS_I2C selects the legacy I2C and
CONFIG_DM_I2C selects the current I2C. The deadline to migrate I2C is less
than a year away.
Also we want to have a CONFIG_I2C for U-Boot proper just like we have
CONFIG_SPL_I2C for SPL, so we can simplify the Makefile rules.
Rename this symbol so it is clear it is going away.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Historically, the reset_cpu() function had an `addr` parameter which was
meant to pass in an address of the reset vector location, where the CPU
should reset to. This feature is no longer used anywhere in U-Boot as
all reset_cpu() implementations now ignore the passed value. Generic
code has been added which always calls reset_cpu() with `0` which means
this feature can no longer be used easily anyway.
Over time, many implementations seem to have "misunderstood" the
existence of this parameter as a way to customize/parameterize the reset
(e.g. COLD vs WARM resets). As this is not properly supported, the
code will almost always not do what it is intended to (because all
call-sites just call reset_cpu() with 0).
To avoid confusion and to clean up the codebase from unused left-overs
of the past, remove the `addr` parameter entirely. Code which intends
to support different kinds of resets should be rewritten as a sysreset
driver instead.
This transformation was done with the following coccinelle patch:
@@
expression argvalue;
@@
- reset_cpu(argvalue)
+ reset_cpu()
@@
identifier argname;
type argtype;
@@
- reset_cpu(argtype argname)
+ reset_cpu(void)
{ ... }
Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
The current macro is a misnomer since it does not declare a device
directly. Instead, it declares driver_info record which U-Boot uses at
runtime to create a device.
The distinction seems somewhat minor most of the time, but is becomes
quite confusing when we actually want to declare a device, with
of-platdata. We are left trying to distinguish between a device which
isn't actually device, and a device that is (perhaps an 'instance'?)
It seems better to rename this macro to describe what it actually is. The
macros is not widely used, since boards should use devicetree to declare
devices.
Rename it to U_BOOT_DRVINFO(), which indicates clearly that this is
declaring a new driver_info record, not a device.
Signed-off-by: Simon Glass <sjg@chromium.org>
We use 'priv' for private data but often use 'platdata' for platform data.
We can't really use 'pdata' since that is ambiguous (it could mean private
or platform data).
Rename some of the latter variables to end with 'plat' for consistency.
Signed-off-by: Simon Glass <sjg@chromium.org>
The Linux coding style guide (Documentation/process/coding-style.rst)
clearly says:
It's a **mistake** to use typedef for structures and pointers.
Besides, using typedef for structures is annoying when you try to make
headers self-contained.
Let's say you have the following function declaration in a header:
void foo(bd_t *bd);
This is not self-contained since bd_t is not defined.
To tell the compiler what 'bd_t' is, you need to include <asm/u-boot.h>
#include <asm/u-boot.h>
void foo(bd_t *bd);
Then, the include direcective pulls in more bloat needlessly.
If you use 'struct bd_info' instead, it is enough to put a forward
declaration as follows:
struct bd_info;
void foo(struct bd_info *bd);
Right, typedef'ing bd_t is a mistake.
I used coccinelle to generate this commit.
The semantic patch that makes this change is as follows:
<smpl>
@@
typedef bd_t;
@@
-bd_t
+struct bd_info
</smpl>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
DM, DM_SPI and other driver model migration deadlines
are expired for this board.
Remove it.
Cc: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
DM, DM_SPI and other driver model migration deadlines
are expired for this board.
Remove it.
Cc: Dmitry Lifshitz <lifshitz@compulab.co.il>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.
Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is bad practice to include common.h in other header files since it can
bring in any number of superfluous definitions. It implies that some C
files don't include it and thus may be missing CONFIG options that are set
up by that file. The C files should include these themselves.
Update some header files in arch/arm to drop this.
Signed-off-by: Simon Glass <sjg@chromium.org>
