Add defconfig and board support for HiFive Unmatched.
Signed-off-by: Green Wan <green.wan@sifive.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Rick Chen <rick@andestech.com>
A lot of entries were using spaces instead of tab for alignment that's why
it is good to fix it to use the same style everywhere.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This reverts commit 38d6b7ebda.
struct global_data contains a pointer to the bd_info structure. This
pointer was populated spl_set_bd() to a pre-allocated bd_info in the
".data" section. The referenced commit replaced this mechanism to one
that uses malloc(). That new mechanism is only used if SPL_ALLOC_BD=y.
which very few boards do.
The result is that (struct global_data)->bd is NULL in SPL on most
platforms. This breaks falcon mode, since arch_fixup_fdt() tries to
access (struct global_data)->bd and set the "/memory" node in the
devicetree. The result is that the "/memory" node contains garbage
values, causing linux to panic() as it sets up the page table.
Instead of trying to fix the mess, potentially causing other issues,
revert to the code that worked, while this change is reworked.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
In preparation to add SiFive Unmatched board support, let's rename
the existing fu540 board to unleashed.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
The _SUPPORT suffix is from an earlier time and interferes with use of
the CONFIG_IS_ENABLED() macro. Rename the option to drop the suffix.
Tidy up the TODO that prompted this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some systems (e.g. x86 APL) run SPL from read-only memory. The device
instances created by dtoc are therefore not writeable. To make things work
we would need to copy the devices to read/write memory.
To avoid this, add an option to use a separate runtime struct for devices,
just as is done for drivers. This can be used to hold information that
changes at runtime, avoiding the need for a copy.
Also add a Kconfig option for read-only SPL, which selects this feature.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
This commit add an option TPL_BOOTCOUNT_LIMIT to
use bootcount on TPL.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
H616 supports and needs bigger SPL than 32 KiB, mostly due to big DRAM
driver and need for PMIC configuration, which pulls several drivers which
are not needed otherwise.
spl_mmc_get_uboot_raw_sector() will now compare pre-configured size with
that, reported in SPL header. If size in header is bigger, it will use
that value instead.
In the process of function rework, also add missing function argument.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Samuel Holland <samuel@sholland.org>
It turns out that there are at least 2 other SoCs which have basically
the same memory map, similar clocks and other features as H6. It's very
likely that we'll see more such SoCs in the future. In order to ease
porting to new SoCs and lower ifdef clutter, introduce common symbol for
them.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
CONFIG_HANDOFF is used in u-boot proper to locate handoff info from SPL
during pre-relocation init (in setup_spl_handoff). Add explicit dependency
on CONFIG_SPL, to fix the following build error when CONFIG_HANDOFF &&
!CONFIG_SPL:
common/board_f.c: In function ‘setup_spl_handoff’:
common/board_f.c:283:4: error: ‘gd_t {aka struct global_data}’
has no member named ‘spl_handoff’
gd->spl_handoff = bloblist_find(BLOBLISTT_SPL_HANDOFF,
^~
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This uses up space in the SPL binary but it always starts as zero. Also
some boards cannot support data in TPL (e.g. Intel Apollo Lake).
Use malloc() to allocate this structure instead, by moving the init a
little later, after malloc() is inited. Make this function optional since
it pulls in malloc().
This reduces the TPL binary size on coral by about 64 bytes
Signed-off-by: Simon Glass <sjg@chromium.org>
CONFIG_{SPL,TPL}_SIZE_LIMIT are defined as hex (SPL_SIZE_LIMIT was
converted in b51882d0 ("spl: Convert CONFIG_SPL_SIZE_LIMIT to hex"), but
there are still places that reference integer values. Change those to hex
as well. Also, update the Makefile to check for 0x0 instead of 0.
This also fixes the following build error when CONFIG_SPL_SIZE_LIMIT
is set by menuconfig to 0x0:
...
spl/u-boot-spl.bin exceeds file size limit:
limit: 0 bytes
actual: 0x80f0 bytes
excess: 0x80f0 bytes
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Some boards, specifically 64-bit Allwinner boards (sun50i), are
extremely limited on SPL size. One strategy that was used to make space
was to remove the FIT "os" property parsing code, because it uses a
rather large lookup table.
However, this forces the legacy FIT parsing code path, which requires
the "firmware" entry in the FIT to reference the U-Boot binary, even if
U-Boot is not the next binary in the boot sequence (for example, on
sun50i boards, ATF is run first).
This prevents the same FIT image from being used with a SPL with
CONFIG_SPL_FIT_IMAGE_TINY=n and CONFIG_SPL_ATF=y, because the boot
method selection code looks at `spl_image.os`, which is only set from
the "firmware" entry's "os" property.
To be able to use CONFIG_SPL_ATF=y, the "firmware" entry in the FIT
must be ATF, and U-Boot must be a loadable. For this to work, we need to
parse the "os" property just enough to tell U-Boot from other images, so
we can find it in the loadables list to append the FDT, and so we don't
try to append the FDT to ATF (which could clobber adjacent firmware).
So add the minimal code necessary to distinguish U-Boot/non-U-Boot
loadables with CONFIG_SPL_FIT_IMAGE_TINY=y. This adds about 300 bytes,
much less than the 7400 bytes added by CONFIG_SPL_FIT_IMAGE_TINY=n.
Acked-by: Patrick Wildt <patrick@blueri.se>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
ATF support was all the time based on FIT image support but this dependency
is not recorded anywhere.
For !SPL_FIT && SPL_ATF there is compilation error:
common/spl/spl.c: In function 'board_init_r':
common/spl/spl.c:689:26: error: 'struct spl_image_info' has no member named 'fdt_addr'
689 | spl_fixup_fdt(spl_image.fdt_addr);
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
The patch does sed 's/SPL_FPGA_SUPPORT/SPL_FPGA/g' but also fixing Makefile
and zynqmp.c to simplify if/endif logic in zynqmp.c.
This change is mostly done to be able to use CONFIG_IS_ENABLED macro and
obj-$(CONFIG_$(SPL_)FPGA) in Makefile. For them symbols need to be in sync.
And removing one line from Topic Miami boards which is not needed because
symbol is not enabled via Kconfig.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add support for SquashFS filesystem. Right now, it does not support
compression but support for zlib will be added in a follow-up commit.
Signed-off-by: Joao Marcos Costa <joaomarcos.costa@bootlin.com>
In some cases SPL needs to be able to erase but TPL just needs to read.
Allow these to have separate settings for SPI_FLASH_TINY.
Signed-off-by: Simon Glass <sjg@chromium.org>
This converts the following to Kconfig:
CONFIG_SPL_NAND_DRIVERS
CONFIG_SPL_NAND_ECC
CONFIG_SPL_NAND_SIMPLE
Signed-off-by: Adam Ford <aford173@gmail.com>
This change allows more fine tuning of driver model based SPI support in
SPL and TPL. It is now possible to explicitly enable/disable the DM_SPI
support in SPL and TPL via Kconfig option.
Before this change it was necessary to use:
/* SPI Flash Configs */
#if defined(CONFIG_SPL_BUILD)
#undef CONFIG_DM_SPI
#undef CONFIG_DM_SPI_FLASH
#undef CONFIG_SPI_FLASH_MTD
#endif
in the ./include/configs/<board>.h, which is error prone and shall be
avoided when we strive to switch to Kconfig.
The goal of this patch:
Provide distinction for DM_SPI support in both U-Boot proper and SPL (TPL).
Valid use case is when U-Boot proper wants to use DM_SPI, but SPL must
still support non DM driver.
Another use case is the conversion of non DM/DTS SPI driver to support
DM/DTS. When such driver needs to work in both SPL and U-Boot proper, the
distinction is needed in Kconfig (also if SPL version of the driver
supports OF_PLATDATA).
In the end of the day one would have to support following use cases (in
single driver file - e.g. mxs_spi.c):
- U-Boot proper driver supporting DT/DTS
- U-Boot proper driver without DT/DTS support (deprecated)
- SPL driver without DT/DTS support
- SPL (and TPL) driver with DT/DTS (when the SoC has enough resources to
run full blown DT/DTS)
- SPL driver with DT/DTS and SPL_OF_PLATDATA (when one have constrained
environment with no fitImage and OF_LIBFDT support).
Some boards do require SPI support (with DM) in SPL (TPL) and some only
have DM_SPI{_FLASH} defined to allow compiling SPL.
This patch converts #ifdef CONFIG_DM_SPI* to #if CONFIG_IS_ENABLED(DM_SPI)
and provides corresponding defines in Kconfig.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Tested-by: Adam Ford <aford173@gmail.com> #da850-evm
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
[trini: Fixup a few platforms]
Signed-off-by: Tom Rini <trini@konsulko.com>
The current recommendation for best security practice from the US government
is to use SHA384 for TOP SECRET [1].
This patch adds support for SHA384 and SHA512 in the hash command, and also
allows FIT images to be hashed with these algorithms, and signed with
sha384,rsaXXXX and sha512,rsaXXXX
The SHA implementation is adapted from the linux kernel implementation.
[1] Commercial National Security Algorithm Suite
http://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm
Signed-off-by: Reuben Dowle <reuben.dowle@4rf.com>
Add U-Boot proper sector start offset for SiFive FU540.
This value is based on the partition layout supported
by SiFive FU540.
u-boot.itb need to write on this specific offset so-that
the SPL will retrieve it from here and load.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Pragnesh Patel <pragnesh.patel@sifive.com>
Add a new configuration CONFIG_SPL_SDP_USB_DEV to specify the
usb index for spl sdp driver, so that we change use different device.
The default value is 0.
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The CONFIG_SPL_FORCE_MMC_BOOT config flag is not needed as its behavior
is the correct one in all cases; using spl_boot_device() instead of the
boot_device parameter will lead to inconsistency issues, for example,
when a board_boot_order() is defined. In fact, this is the reason the
parameter was introduced in the first place, in commit 2b1cdafa9f
("common: Pass the boot device into spl_boot_mode()").
This reverts commit 772b55723b.
Link: https://lists.denx.de/pipermail/u-boot/2020-April/405979.html
Signed-off-by: Harald Seiler <hws@denx.de>
Two nearly concurrent commits (d4d65e112 and bcee8d676) added a
SPL_DM_GPIO symbol. Resolve the duplication in favor of the version
in drivers/gpio/Kconfig.
Signed-off-by: Joel Johnson <mrjoel@lixil.net>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
The default SPL / TPL linker script is in the $(ARCH) directory. The
way we use this today works but isn't ideal. With an update to Kconfig
to re-sync with the Linux Kernel, we need to escape the '$' here so that
it will end up being evaluated by make.
Cc: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
For Allwinner SoCs the CONFIG_SYS_SPI_U_BOOT_OFFS value is not really a
board choice: The boot ROM only loads the SPL from offset 0 of the SPI
NOR flash, and loads at most 32KB. This is a similar situation as on MMC,
so consequently we create our "joint" image (SPL + U-Boot proper) with
that 32KB offset during the build.
So define the value of this symbol to be 32KB by default for every
Allwinner SoC. This removes the definition of this symbol from the
_defconfig files, and avoids every board to define this over and over
again.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
- Clearfog: Fix SD booting (Baruch)
- Misc updates to MMC handling in SPL to support booting from
main data partition (vs hardware boot partition) on MVEBU (Baruch)
On Armada 38x platforms the ROM code loads SPL from offset 0 of eMMC
hardware boot partitions. When there are no boot partitions (i.e. SD
card) the ROM skips the first sector that usually contains the (logical)
partition table. Since the generated .kwb image contains the main U-Boot
image in a fixed location (0x140 sectors by default), we end up with the
main U-Boot image in offset of 1 sector. The current workaround is to
manually set CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR to 0x141 to
compensate for that.
This patch uses the run-time detected boot partition to determine the
right offset of the main U-Boot partition. The generated .kwb image is
now compatible with both eMMC boot partition, and SD card main data
partition.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Rename CONFIG_SPL_DMA_SUPPORT to CONFIG_SPL_DMA. This allows to use
macros such as CONFIG_IS_ENABLED() that allow conditional compilation of
code for SPL and U-Boot.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add an option for building cache drivers in SPL.
Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
In commit <db4080d56dec>, SPL_FSL_PBL is removed from the configs of
some LayerScape platforms. Actually, SPL_FSL_PBL is needed for SD/NAND
boot on LS1021A/LS1043A/LS1046A to create boot binary having SPL binary
in PBI format concatenated with u-boot binary. SPL_FRAMEWORK is used on
these platforms too.
Signed-off-by: Alison Wang <alison.wang@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
When ax25-ae350 try to enable v5l2 cache
driver in SPL configuration, it need this
option for cache support in SPL.
Signed-off-by: Rick Chen <rick@andestech.com>
Cc: KC Lin <kclin@andestech.com>
Cc: Alan Kao <alankao@andestech.com>
This define indicates if DM_GPIO shall be supported in SPL. This allows
proper operation of DM converted GPIO drivers in SPL, which use
boards.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Right now enabling SPL_FRAMEWORK will also enable it for the TPL in all
cases, making the TPL bigger. There may be cases where the TPL is really
size constrained due to its underlying ram size.
Therefore introduce a new TPL_FRAMEWORK option and make the relevant
conditionals check for both. The default is set to "y if SPL_FRAMEWORK"
to mimic the previous behaviour where the TPL would always get the
SPL framework if it was enabled in SPL.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
As SPL_SPI_FLASH_SUPPORT cannot work without SPL_SPI_SUPPORT, fix
dependencies to prevent enabling SPI flash support without basic SPI
support.
Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
We have the ability to enforce a maximum size for SPL but not yet for TPL.
Add a new option for this.
Document the size check macro while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Loading U-Boot on i.MX8QXP MEK board is broken since recent changes
in spl_mmc:
U-Boot SPL 2019.10-00162-gff5bd397e4 (Oct 18 2019 - 15:50:45 +0200)
Normal Boot
WDT: Not found!
Trying to boot from MMC2_2
Load image from MMC/SD 0x46400
spl: mmc partition switch failed
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
The newly added CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION option
is selected automatically and overrides the EXT_CSC_PART_CONFIG
configurations with default value, always selecting the eMMC boot
partition 1. Boards which place U-Boot image in other partitions
became not bootable.
Fix this by making the eMMC HW boot partition selection optional.
Fixes: 17241ea054 (spl: mmc: Add option to set eMMC HW boot partition)
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
This define indicates if DM_SPI shall be supported in SPL. This allows
proper operation of DM converted SPI drivers in SPL, which use
#if !CONFIG_IS_ENABLED(DM_SPI) to also support not yet DM/DTS converted
boards.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
This change allows setting pre-defined eMMC boot partition for SPL eMMC
booting. It is necessary in the case when one wants to boot (through falcon
boot) from eMMC after loading SPL from other memory (like SPI-NOR).
Signed-off-by: Mans Rullgard <mans@mansr.com>
[lukma: Edit the commit message]
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Andreas Dannenberg <dannenberg@ti.com>
This commit add a generic function board_init_f that
only initialize some device (for example serial). It
avoid to define a board function only to launch the
serial configuration.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
This change tries to fix the following problem:
- The board boots (to be more precise - ROM loads SPL) from a slow SPI-NOR
memory.
As a result the spl_boot_device() will return SPI-NOR as a boot device
(which is correct).
- The problem is that in 'falcon boot' the eMMC is used as a boot medium to
load kernel from its partition.
Calling spl_boot_device() will break things as it returns SPI-NOR device.
To fix this issue the new CONFIG_SPL_FORCE_MMC_BOOT Kconfig flag is
introduced to handle this special use case. By default it is not defined,
so there is no change in the legacy code flow.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
