This converts 3 usages of this option to the non-SPL form, since there is
no SPL_FASTBOOT defined in Kconfig
Signed-off-by: Simon Glass <sjg@chromium.org>
Set splash screen related env variables. Default splash source is
set to mmc where user is expected to keep bmp in compressed format
with name ti.gz on first partition of mmc.
Splash file will be uncompressed to DDR at address 0x82000000 and
splash position is set to middle of screen.
Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Use .env file for setting board related environment variables,
in place of am62x_evm.h file. Except for BOOTENV settings, as
config_distro_boot.env file doesn't exist.
Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Splash screen function needs splash source information
to load image and display it, splash_location provides
the necessary info, Set default_splash_location to MMC
at partition 1:1. Probe DSS for splash screen display.
Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Add the board_init_f API for SPL and run the platform-required SoC
initialization.
Add the functionality for board name-based DTB selection from FIT
within SPL. This will make it easier to utilise one defconfig for
both the EVM and the SK.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Update the board_fit_config_name_match() to choose the right dtb
based on the board name read from EEPROM.
Also restrict multpile EEPROM reads by verifying if EEPROM is already
read
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
J721S2 EVM has EEPROM populated at 0x50. AM68 SK has EEPROM populated at
next address 0x51 in order to be compatible with RPi. So start looking
for TI specific EEPROM at 0x50, if not found look for EEPROM at 0x51.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Update setup_board_eeprom_env() to choose the right board name
for am68-sk.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
At this point, the remaining places where we have a symbol that is
defined as CONFIG_... are in fairly odd locations. While as much dead
code has been removed as possible, some of these locations are simply
less obvious at first. In other cases, this code is used, but was
defined in such a way as to have been missed by earlier checks. Perform
a rename of all such remaining symbols to be CFG_... rather than
CONFIG_...
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Before this was named just evm, which doesn't match the naming
of the other TI board file directory and makes it look like a
common directory for evms. Name this omap3evm.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Derald Woods <woods.technical@gmail.com>
EEPROM detection logic in ti_i2c_eeprom_get() involves figuring out
whether addressing is 1-byte or 2-byte. There are currently different
behaviours seen across boards as documented in commit bf6376642f
("board: ti: common: board_detect: Fix EEPROM read quirk"). Adding to
the list, we see that there are 2-byte EEPROMs that read properly
with 1-byte addressing with no offset.
For ti_i2c_eeprom_am6_get where eeprom parse operation is dynamic, the
earlier commit d2ab2a2baf ("board: ti: common: board_detect: Fix
EEPROM read quirk for AM6 style data") tried to resolve this by running
ti_i2c_eeprom_get() twice. However this commit along with its former
commit fails on J7 platforms where EEPROM successfully return back the
header on 1-byte addressing and continues to do so until an offset is
introduced. So the second read incorrectly determines the EEPROM as
1-byte addressing.
A more generic solution is introduced here to solve
this issue: 1-byte read without offset and 1-byte read with offset. If
both passes, it follows 1-byte addressing else we proceed with 2-byte
addressing check.
Tested on J721E, J7200, DRA7xx, AM64x
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Fixes: d2ab2a2baf (board: ti: common: board_detect: Fix EEPROM read quirk for AM6 style data)
Fixes: bf6376642f (board: ti: common: board_detect: Fix EEPROM read quirk)
Tested-By: Matwey V. Kornilov <matwey.kornilov@gmail.com>
The functions board_fit_image_post_process() and board_tee_image_process()
are not actually board specific (despite their names). Any board using the
OMAP2 family can use these functions. Move them to boot-common.c.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS 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>
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>
The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE
and this makes it imposible to use CONFIG_VAL().
Rename it to resolve this problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is not needed and we should avoid typedefs. Use the struct instead
and rename it to indicate that it really is a legacy struct.
Signed-off-by: Simon Glass <sjg@chromium.org>
The situation is similar to commit bf6376642f ("board: ti: common:
board_detect: Fix EEPROM read quirk"). This is seen on a variant of
eeproms seen on some BeagleBone-AI64 which now has a mix of both 1 byte
addressing and 2 byte addressing eeproms.
Unlike the am335x (ti_i2c_eeprom_am_get) and dra7
(ti_i2c_eeprom_dra7_get) which use constant data structure which allows
us to do a complete read of the data, the
am6(ti_i2c_eeprom_am6_get) eeprom parse operation is dynamic.
This removes the option of being able to read the complete eeprom data
in one single shot.
Fortunately, on the I2C bus, we do see the following behavior: In 1
byte mode, if we attempt to read the first header data yet again, the
misbehaving 2 byte addressing device acts in constant addressing mode
which results in the header not matching up and follow on attempt at 2
byte addressing scheme grabs the correct data.
This costs us an extra ~3 milliseconds, which is a minor penalty
compared to the consistent image support we need to have.
Reported-by: Jason Kridner <jkridner@beagleboard.org>
Fixes: a58147c2db ("board: ti: common: board_detect: Do 1byte address checks first.")
Signed-off-by: Nishanth Menon <nm@ti.com>
Commit 37dc958947 ("global_data.h: Change ram_top type to phys_addr_t")
changed type of ram_top member from ulong to phys_addr_t but did not
changed types in board_get_usable_ram_top() function which returns value
for ram_top.
So change ulong to phys_addr_t type also in board_get_usable_ram_top()
signature and implementations.
Fixes: 37dc958947 ("global_data.h: Change ram_top type to phys_addr_t")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
There are three different kinds of EEPROM possibly present on boards.
1. 1byte address. For those we should avoid 2byte address in order
not to rewrite the data. Second byte of the address can potentially
be interpreted as the data to write.
2. 2byte address with defined behaviour. When we try to use 1byte
address they just return "FF FF FF FF ... FF"
3. 2byte address with undefined behaviour (for instance, 24LC32AI).
When we try to use 1byte address, then their internal read
pointer is changed to some value. Subsequential reads may be
broken.
To gracefully handle both case #1 and case #3 we read all required
data from EEPROM at once (about 80 bytes). So either all the data is
valid or we fallback to 2byte address.
Cc: Nishanth Menon <nm@ti.com>
Fixes: a58147c2db ("board: ti: common: board_detect: Do 1byte address checks first.")
Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/
Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Acked-by: Nishanth Menon <nm@ti.com>
The first AM6x device was the AM654x, but being the first we named it
just AM6, since more devices have come out with this same prefix we
should switch it to the normal convention of using the full name of the
first compatibility device the series. This makes what device we are
talking about more clear and matches all the K3 devices added since.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This is no longer needed as the SA2UL can now be shared with Linux.
Leave the SA2UL DT node enabled.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
We have different dtbs for the Lite and Extended WiFi variants of the
SanCloud BBE.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The SanCloud BBE Lite has a Micron Authenta flash device connected to
the spi0 bus.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Do 1 byte address checks first prior to doing 2 byte address checks.
When performing 2 byte addressing on 1 byte addressing eeprom, the
second byte is taken in as a write operation and ends up erasing the
eeprom region we want to preserve.
While we could have theoretically handled this by ensuring the write
protect of the eeproms are properly managed, this is not true in case
where board are updated with 1 byte eeproms to handle supply status.
Flipping the checks by checking for 1 byte addressing prior to 2 byte
addressing check prevents this problem at the minor cost of additional
overhead for boards with 2 byte addressing eeproms.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Due to supply chain issues, we are starting to see a mixture of eeprom
usage including the smaller 7-bit addressing eeproms such as 24c04
used for eeproms.
These eeproms don't respond well to 2 byte addressing and fail the
read operation. We do have a check to ensure that we are reading the
alternate addressing size, however the valid failure prevents us
from checking at 1 byte anymore.
Rectify the same by falling through and depend on header data comparison
to ensure that we have valid data.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The eeprom data area is much bigger than the data we intend to store,
however, with bad programming, we might end up reading bad records over
and over till we run out of eeprom space. instead just exit when 10
consecutive records are read.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Call into k3-ddrss driver to fixup device tree and resize
the available amount of DDR if ECC is enabled.
A second fixup is required from A53 SPL to take the fixup
as done from R5 SPL and apply it to DT passed to A53 U-boot,
which in turn passes this to the OS.
Signed-off-by: Georgi Vlaev <g-vlaev@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Use the appropriate fdtdec_setup_mem_size_base() call in
dram_init() and fdtdec_setup_bank_size() in dram_bank_init()
to pull these values from DT, where they are already available,
instead of hardcoding them.
Signed-off-by: Georgi Vlaev <g-vlaev@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
While configuring SerDes, errors could be encountered, in these cases,
return instead of going ahead. This is will help in booting even if
configuration of SerDes fails.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
We want to keep all of the default values for SPL_LDSCRIPT in the same
place both for overall clarity as well as not polluting unrelated config
files.
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>
The origin of this patch is the breaking of am335x-hs boot
due to commit e41651fffd ("dm: Support parent devices with of-platdata")
HS boards have less SRAM for SPL and so this commit increased memory usage beyond am335x limit.
This commit added 10 driver binding pass and am335x boot only if one pass is done.
SPL try to do more than one pass due to eth_cpsw failing.
Since HS SPL does not need network (and NET is already disabled in config),
the easiest fix is to "remove" eth_cpsw from SPL by testing if NET is enabled.
Signed-off-by: Corentin LABBE <clabbe@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Andrew Davis <afd@ti.com>
Add am62x_evm_r5_defconfig for R5 SPL and am62x_evm_a53_defconfig for
A53 SPL and U-Boot support.
To keep the changes to minimum. Only UART And SD boot related configs
are included. This should serve as good starting point for new board
bringup with AM62x.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
[trini: Migrate a number of CONFIG symbols, have re-tested]
Tested-by: Georgi Vlaev <g-vlaev@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Add basic support for AM62 SK. This has 2GB DDR.
Note that stack for R5 SPL is in OCRAM @ 0x7000ffff so that is away from
BSS and does not step on BSS section
Add only the bare minimum required to support UART and SD.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
On j721e, its not possible to use OSPI0 and HBMC simultaneously as they
are muxed within the Flash Subsystem hence disable HBMC by default and
keep OSPI enabled. Bootloader will fixup DT when it detects HyperFlash
mux selection instead of OSPI.
Also updated detect_enable_hyperflash to use correct GPIO when checking
hypermux selection state:
* J7200 - hypermux sel connected to WKUP_GPIO0_6
* J721E - hypermux·sel·connected·to·WKUP_GPIO0_8
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
The Sancloud BeagleBone Enhanced Extended WiFi (BBE Extended WiFi) has
its own devicetree file and the board can be identified by the 2nd
letter of the config string within the common EEPROM.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
The Sancloud BeagleBone Enhanced Lite (BBE Lite) has its own devicetree
file and the board can be identified by the 2nd letter of the config
string within the common EEPROM.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
Call into k3-ddrss driver to fixup device tree and resize the available
amount of DDR if ECC is enabled.
A second fixup is required from A53 SPL to take the fixup as done from
R5 SPL and apply it to DT passed to A53 U-boot, which in turn passes
this to the OS.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Use the appropriate fdtdec_setup_mem_size_base and
fdtdec_setup_bank_size calls in dram_init and dram_bank_init to pull
these values from DT, where they are already available, instead of
hardcoding them.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Initialization and power on operations of links have been moved under the
link device in the Sierra SerDes driver. Also, the UCLASS of
sierra_phy_provider has been changed to UCLASS_MISC.
Therefore, fix the probing of SerDes0 instance accordingly.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Georgi Vlaev <g-vlaev@ti.com>
The PMIC enables power to the MMC card by default, but depending
on the state it was left when restarted, it's possible the MMC
may be powered down.
This patch patch explicitly tells the twl4030 to power the MMC.
Based on commits [1][2].
[1] 64fd2d2614
[2] 27b6534491
Signed-off-by: Romain Naour <romain.naour@gmail.com>
