Most of architectures have .text section situated in the very beginning
of U-Boot binary and thus it is very logical that CONFIG_SYS_TEXT_BASE
is used on final linkage step to specify where U-Boot gets linked to.
For that we pass the following construction to the LD:
---------------------------->8-----------------------
xxx-ld ... -Ttext $(CONFIG_SYS_TEXT_BASE) ...
---------------------------->8-----------------------
But there could be exceptions. For example:
1. In case of ARCv2 we want to put vectors table in its own section
.ivt in front of .text section which means we need either add an
offset to CONFIG_SYS_TEXT_BASE to compensate for .ivt or don't
pass "-Ttext" to the LD at all and specify link base in linker
script directly.
2. Some architectures even though have .text section in the very
beginning of the U-Boot image still use different symbols to
specify link-base:
* NIOS2: CONFIG_SYS_MONITOR_BASE (which I really like because
that exactly what makes sense - where out image starts but not
beginning of its .text section which just happened to match the
whole image beginning)
* EXTENSA: CONFIG_SYS_TEXT_ADDR
* X86: Which doesn't use CONFIG_SYS_MONITOR_BASE in case of EFI
otherwise sets explicit link base in u-boot.lds
I think that's good to allow for flexibility and don't require each and
every architecture or even platform to specify CONFIG_SYS_TEXT_BASE as well
as use it to set .text section location.
So let's only pass "-Ttext xxx" for those architectures who don't set
link-base explicitly in their linker scripts.
This patch iaddresses comments for previously sent
https://patchwork.ozlabs.org/patch/867540/.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
These were dropped in [1], after relocation, for their values offset by
reloc_off.
Unconditionally show the HW values and add a '(reloc)' hint for the
offset values showed after relocation.
Also, the LRs' dumps are now formatted the same way the other regs' are.
[1] Commit 082693f4 ("arm64 :show_regs: show the address before relocation")
Signed-off-by: Karl Beldan <karl.beldan+oss@gmail.com>
Fix build after addition of RSA_get0_key() to LibreSSL.
Patch from Theo Buehler and Stuart Henderson.
Signed-off-by: Theo Buehler <tb@openbsd.org>
Signed-off-by: Stuart Henderson <sthen@openbsd.org>
ll_temac driver was used by Xilinx Microblaze big endian and
Xilinx ppc405/ppc440 SoCs.
ppc support was removed by: "powerpc: remove 4xx support"
(sha1: 98f705c9ce)
and Microblaze BE is not tested for a long time that's why this driver
can be removed because none is going to updated it to DM anyway.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Memory banks with address 0 and size 0 are empty and should not be
passed to the OS via device tree.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Do a explicit check for CONFIG_SYS_BIG_ENDIAN and
CONFIG_SYS_LITTLE_ENDIAN to avoid errors on platforms where both
are undefined (x86).
Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com>
Reviewed-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com>
Since memory banks may not be located behind each other we need to add
them separately.
Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com>
Reviewed-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com>
These got removed in config re-syncs due to a Kconfig bug. Add these
back here.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
This seems to have been missed, possibly due to the inability to
enable TI_SECURE_DEVICE on Keystone2 devices previously.
Fixes: bfebc8c965 ("env: Rename getenv_hex(), getenv_yesno(), getenv_ulong()")
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
TI_SECURE_DEVICE is used by both OMAP2+ and Keystone2 family devices,
and so when ARCH_OMAP2PLUS was used to gate off the OMAP2+ Kconfig
Keystone2 family devices lost this config option.
Move this option out of mach-omap2 Kconfig to a spot accessible by both
families. We picked arch/arm/Kconfig over the TI specific board/ti/
location as this option is not specific to our boards but rather our
architecture.
Plus at some point this option can be changed to just
SECURE_DEVICE, as having secure parts is not exclusive to TI and
so other vendors can interpret this option as needed by their device
configurations.
Fixes: a93fbf4a78 ("ARM: omap2+: rename config to ARCH_OMAP2PLUS and consolidate Kconfig")
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
A number of platforms include config_distro_defaults.h but do not enable
CONFIG_DISTRO_DEFAULTS. As they plainly intended to, set that flag and
re-sync config files.
Signed-off-by: Tom Rini <trini@konsulko.com>
MMC card with EXT_CSD_REV value 9 will trigger off-by-one
bug while accessing mmc_versions array. The patch fix that.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
Add DT compatible strings for RCar Gen2 SoCs, so that this driver
can bind with them. Unlike Gen3, which uses 64bit FIFO, the Gen2
uses 16bit FIFO.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
With modern GCC, we get warnings such as:
cmd/jffs2.c: In function 'mtdparts_init':
arch/sh/include/asm/string.h:110:38:
warning: array subscript is above array bounds [-Warray-bounds]
: "0" (__cs), "1" (__ct), "r" (__cs+__n)
~~~~^~~~
This results in a small size reduction as well.
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Currently SPL_LOAD_FIT is unable to boot from nand on
i.MX6QDL platform, so enable only for MMC boards.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
i.MX6 boards still using raw MMC write for SPL and
u-boot-dtb.img along with Falcon mode configurations,
so drop filesystem based write through SPL_EXT_SUPPORT.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Engicam Is.IoT has eMMC and NAND cpu modules where MMC
is common for both, so remove explicit mmc defconfig.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Currently the following devices are using a different definition for ROM
Vector Table addresses:
- i.MX6DQP = All rev
- i.MX6DQ >= rev 1.5
- i.MX6SDL >= rev 1.2
There is no need to create a new RVT macros since the only update were the
RVT base address. Remove HAB_RVT_*_NEW macros and define a new RVT base
address.
More details about RVT base address can be found on processors Reference
Manual and in the following documents:
EB803: i.MX 6Dual/6Quad Applications Processor Silicon Revision 1.2 to 1.3
Comparison
EB804: i.MX 6Solo/6DualLite Application Processor Silicon Revision 1.1
to 1.2/1.3 Comparison
Signed-off-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Write, Check and Set MID commands have been deprecated from the Code
Signing Tool (CST) v2.3.3 and will not be implemented in newer versions
of HAB, hence the following features are no longer available:
- Write Data
- Clear Mask
- Set Mask
- Check All Clear
- Check All Set
- Check Any Clear
- Check Any Set
- Set MID
The inappropriate use of Write Data command may lead to an incorrect
authentication boot flow. Since no specific application has been identified
that requires the use of any of these features, it is highly recommended to
add this check.
Signed-off-by: Utkarsh Gupta <utkarsh.gupta@nxp.com>
Signed-off-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
For proper authentication the HAB code must check if the CSF is valid.
Users must call the csf_is_valid() function to parse the CSF prior to
authenticating any additional images. The function will return a failure
if any of the following invalid conditions are met:
- CSF pointer is NULL
- CSF Header does not exist
- CSF does not lie within the image bounds
- CSF command length zero
Signed-off-by: Utkarsh Gupta <utkarsh.gupta@nxp.com>
Signed-off-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
DCD commands should only be present in the initial boot image loaded by
the SoC ROM. DCD should not be present in images that will be verified
by software using HAB RVT authentication APIs. Newer versions of HAB
will generate an error if a DCD pointer is present in an image being
authenticated by calling the HAB RVT API. Older versions of HAB will
process and run DCD if it is present, and this could lead to an incorrect
authentication boot flow.
It is highly recommended this check is in place to ensure additional HAB
verified images do not include a DCD table.
Signed-off-by: Utkarsh Gupta <utkarsh.gupta@nxp.com>
Signed-off-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Currently it is not possible to run CMD_DEK on i.MX SPL targets:
=> dek_blob 0x12000000 0x12001000 128
The system hangs after running dek_blob because the CAAM clock is being
disabled by the HAB code. There is no need to disable CAAM clock after
authenticating additional boot images, thus keep CAAM clock enabled to
address this issue.
Signed-off-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
This reverts commit edf0093732 for
cm_fx6 iMX.6 Solo module as it causes frequent (around 10 percent of
power cycles) board's hangs.
These hangs happen in SPL when BSS is being initialized in SDRAM -
it appear that variables from BSS contain trash values which lead to board
hangs. Looks like that SDRAM doesn't yet finish initialization in these
cases.
Signed-off-by: Maxim Yu. Osipov <mosipov@ilbers.de>
Reviewed-by: Stefano Babic <sbabic@denx.de>
Based on reading over the GCC manual, passing both -m2a and -m2a-nofpu
are redundant, as -m2a-nofpu will provide functional code for both. As
-m2a-nofpu functions with more toolchains and does what is expected,
switch.
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
When FASTBOOT is activated, only one the supported device is supported in
code at the same time
- CONFIG_FASTBOOT_FLASH_MMC_DEV
- CONFIG_FASTBOOT_FLASH_NAND_DEV
But Today the choice is not exclusive in Kconfig
and that cause Kconfig issue when :
- CONFIG_FASTBOOT, CONFIG_MMC, CONFIG_NAND are activated
- CONFIG_FASTBOOT_FLASH_MMC_DEV = 0
- CONFIG_FASTBOOT_FLASH_NAND_DEV is not activated
The patch add a choice in Kconfig to select the FLASH provider
- CONFIG_FASTBOOT_FLASH_MMC
- CONFIG_FASTBOOT_FLASH_NAND
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Fix two build warnings when building for arm64:
drivers/dfu/dfu_tftp.c: In function ‘dfu_tftp_write’:
drivers/dfu/dfu_tftp.c:59:37: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
ret = dfu_write_from_mem_addr(dfu, (void *)addr, len);
^
and
drivers/dfu/dfu_tftp.c: In function ‘dfu_tftp_write’:
drivers/dfu/dfu_tftp.c:41:8: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘__kernel_size_t {aka long unsigned int}’ [-Wformat=]
debug("%s: image name: %s strlen: %u\n", __func__, sb, strlen(sb));
^
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Lukasz Majewski <lukma@denx.de>
Do the following to make the symbol names less confusing.
sed -i "s/\([TU][^_]\+\)_FUNCTION_DFU/DFU_OVER_\1/g" \
`git grep _FUNCTION_DFU | cut -d ":" -f 1 | sort -u`
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Lukasz Majewski <lukma@denx.de>
Clean up the screaming mess of configuration options that DFU is.
It was impossible to configure DFU such that TFTP is enabled and
USB is not, this patch fixes that and assures that DFU TFTP and
DFU USB can be enabled separatelly and that the correct pieces
of code are compiled in.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Lukasz Majewski <lukma@denx.de>
If SYS_STDIO_DEREGISTER is not selected and USB_KEYBOARD is selected
U-Boot cannot be built due to missing function stdio_deregister_dev.
So USB_KEYBOARD should select SYS_STDIO_DEREGISTER.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The SDP protocol contains multiple 32bit pointers. Add a helper function
to get a valid pointer from these values and use it.
This fixes the following warnings:
drivers/usb/gadget/f_sdp.c: In function ‘sdp_rx_data_complete’:
drivers/usb/gadget/f_sdp.c:347:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
memcpy((void *)sdp->dnl_address, req->buf + 1, datalen);
^
drivers/usb/gadget/f_sdp.c: In function ‘sdp_jump_imxheader’:
drivers/usb/gadget/f_sdp.c:625:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
entry = (void *)headerv2->entry;
^
drivers/usb/gadget/f_sdp.c: In function ‘sdp_handle_in_ep’:
drivers/usb/gadget/f_sdp.c:668:20: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
memcpy(&data[1], (void *)sdp_func->dnl_address, datalen);
^
drivers/usb/gadget/f_sdp.c:679:31: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
status = sdp_jump_imxheader((void *)sdp_func->jmp_address);
^
Signed-off-by: Andre Heider <a.heider@gmail.com>
If some configs are disabled, number of freqs array will not assigned to
correct value with bus_mode.
Synchornize the ordering with enum bus_mode in mmc.h.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
This commit fixes several issues:
- After moving env related code to ./env directory the env_common.o file
is no longer present in the system (has been replaced with built-in.o).
- Use ${OBJCOPY} if available, fallback to system default's objcopy if not
present.
- Extend the script to accept different build directory than current one.
It is extremely handy with OE usage, where source code is separated from
build.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Tested-by: Alex Kiernan <alex.kiernan@gmail.com>
When booting from a non-MMC device, the MMC sub-system may not be
initialized when the environment is first accessed.
We need to make sure that the MMC sub-system is ready in even a non-MMC
boot case.
Therefore, initialize mmc before loading environment from it.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
These ARM boards are in nice shape and still being used a lot
with e.g. QEMU, so I can maintain them.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When using omap_hsmmc without the device model then the allocation
of mmc->priv ends up uninitialised.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Tested-by: Robert Nelson <robertcnelson@gmail.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
The correspondence between mmc versions as used in u-boot and the version
numbers reported in register EXT_CSD_REV is wrong for versions above and
including MMC_VERSION_4_41. All those versions were shifted by one:
real 4.5 hardware appeared to be MMC_VERSION_5_0.
Fix this by adding the missing version in the correspondence table.
Reported-by: eil Eilmsteiner Heribert <eil@keba.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
After settings the speed of the sd with the switch command, a check is
done to make sure that the new speed has been set. The current check has a
masking error: speed are encoded on 4 bits only.
Fix it by masking the upper bits.
This fixes a problem seen with QEmu emulating a vexpress-a15.
Reported-by: Jonathan Gray <jsg@jsg.id.au>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Tested-by: Jonathan Gray <jsg@jsg.id.au>
Since DRA7xx/AM57xx SR1.1 and SR1.0 has errata to limit the frequency of
MMC1 to 96MHz and frequency of MMC2 to 48MHz for AM572x SR1.1, limit the
frequency and disable higher speed modes for those revision.
Also use the recommended IO delays (those tagged with "rev11")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
