For CONFIG_ENV_FAT_INTERFACE != 'mmc' a link error
env/fat.c:93: undefined reference to `mmc_initialize'
occurs if CONFIG_MMC_SUPPORT is not enabled.

Fixes: 26862b4a ("env: mmc/fat/ext4: make sure that the MMC sub-system
is initialized before using it")
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.
Signed-off-by: NSiva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Since commit 8e14ba7b ("gpio: omap_gpio: Add DM_FLAG_PRE_RELOC
flag") omap GPIO gets bound before relocation.  Unfortunately due to
this, on at least the beaglebone black, the pre-relocation memory pool
gets exhausted before probing the serial port. This then causes u-boot
to panic as CONFIG_REQUIRE_SERIAL_CONSOLE is set...

Resolve this by resizing the default size of the pre-relocation malloc
pool for AM335X platforms.
Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>

We enabled CONFIG_ISO_PARTITION by default for distro boot, so that U-Boot
could load distro images that usually get shipped as iso images. These images
usually come with a board agnostic boot environment.

However, there is very little point in having ISO support enabled (for anyone
really) in SPL, as the whole idea of SPL is to load U-Boot proper which again
is board specific. So the fact that we enable ISO support in U-Boot proper does
not mean at all that we want ISO support in U-Boot SPL.

Hence, let's remove the Kconfig dependency. Along the way, let's also clean up
all those default configs that disabled SPL ISO support.
Signed-off-by: NAlexander Graf <agraf@suse.de>

We only use coreboot as a target on x86 platforms, since on ARM platforms
U-Boot always runs as the primary boot loader. Rename the coreboot-x86
platform to reflect this.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

This updates the doc of booting VxWorks, like loading an x64 kernel,
and how to make VxWorks graphics console driver work.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>

On VxWorks x86 its bootline address is at a pre-defined offset @
0x1200. If 'bootaddr' is not passed via environment variable, we
assign its value based on the kernel memory base address.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>

Exit the 'bootvx' command if bootline address is not specified.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>

There is a small duplication in do_bootvx() that does the bootline
copy. Refactor this a little bit to make it simpler.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

When booting from EFI BIOS, VxWorks bootloader stores the EFI GOP
framebuffer info at a pre-defined offset @ 0x6100. When VxWorks
kernel boots up, its EFI console driver tries to find such a block
and if the signature matches, the framebuffer information will be
used to initialize the driver.

However it is not necessary to prepare an EFI environment for
VxWorks's EFI console driver to function (eg: EFI loader in
U-Boot). If U-Boot has already initialized the graphics card and
set it to a VESA mode that is compatible with EFI GOP, we can
simply prepare such a block for VxWorks.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

If video initialization fails, the "Video:" output message will be
mixed with the next console log. Change to print out such message
only when everything is OK, which improves the boot log readability.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This changes some boards' default FRAMEBUFFER_VESA_MODE to use 32-bit
pixel format for better VxWorks compatibility.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This changes the default FRAMEBUFFER_VESA_MODE to use 32-bit pixel
format for better VxWorks compatibility.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

If CONFIG_FRAMEBUFFER_SET_VESA_MODE is not set, don't switch
graphics card to VESA mode. This applies to both native mode
and emulator mode of running the VGA BIOS.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This adds a very simple ELF64 loader via program headers, similar
to load_elf_image_phdr() that we already have.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This adds ELF header, program header and section header structure
defines for the 64-bit ELF image.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Fix various style violations in elf.h
- use correct comment format if the comment fits in just one line
- remove the ending period for the one-line comment
- use tab for the indention instead of space
- put the opening brace at the same line of a typedef/union
- remove <name> in a 'typedef struct' for consistency
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NChristian Gmeiner <christian.gmeiner@gmail.com>

This changes 'struct e820entry' to 'struct e820_entry' to conform
with the coding style.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NChristian Gmeiner <christian.gmeiner@gmail.com>

This fixes the following checkpatch warning:

  warning: Prefer 'unsigned int' to bare use of 'unsigned'
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NChristian Gmeiner <christian.gmeiner@gmail.com>

This changes 'struct e820info' to 'struct e820_info' to conform
with the coding style.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NChristian Gmeiner <christian.gmeiner@gmail.com>

VxWorks bootloader stores its size at a pre-defined offset @ 0x5004.
Later when VxWorks kernel boots up and system memory information is
retrieved from the E820 table, the bootloader size will be subtracted
from the total system memory size to calculate the size of available
memory for the OS.

Explicitly clear the bootloader image size otherwise if memory
at this offset happens to contain some garbage data, the final
available memory size for the kernel is insane.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

At present two environment variables 'e820data'/'e820info' are required
to boot a VxWorks x86 kernel, but this is superfluous. The offset of
these two tables are actually at a fixed offset from the kernel memory
base address and we can provide the kernel memory base address to U-Boot
via only one variable 'vx_phys_mem_base'.

Note as it name indicates, the physical address should be provided.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NChristian Gmeiner <christian.gmeiner@gmail.com>

This corrects a typo and updates several places for clarity.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NChristian Gmeiner <christian.gmeiner@gmail.com>

The commit 3f70a6f5 ("x86: Add clr/setbits functions")
introduced the {read|write}_ macros to manipulate data.

Those macros are not used by any code in the u-boot project (despite the
io.h itself). Other architectures use io.h with {in|out}_* macros.

This commit brings some unification across u-boot supported architectures.
Signed-off-by: NLukasz Majewski <lukma@denx.de>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Add readq() and writeq() definitions for x86.

Please note: in 32-bit code readq/writeq will generate two 32-bit
memory access instructions instead of one atomic 64-bit operation.
Signed-off-by: NIvan Gorinov <ivan.gorinov@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Make the cfi_flash driver compatible with a live device tree.
Signed-off-by: NMario Six <mario.six@gdsys.cc>
Signed-off-by: NStefan Roese <sr@denx.de>

Signed-off-by: NTom Rini <trini@konsulko.com>

These changes bring mainline back into line with the configurations
that were originally set in our stable BSP.
Signed-off-by: NJon Nettleton <jon@solid-run.com>
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>

Each imx image is created by a separate sub-make and during this process
the mkimage config file is run though cpp.

The cpp output is to the same file no matter what imx image is being
created.

This means if two imx images are generated in parallel they will attempt
to independently produce the same pre-processed mkimage config file at
the same time.

Avoid the problem by making the pre-processed config file name unique
based on the imx image it will be used in.  This way each image will
create a unique config file and they won't clobber each other when run
in parallel.

This should fixed the build bug referenced in b5b0e4e3 ("imximage:
Remove failure when no IVT offset is found").

Cc: Breno Lima <breno.lima@nxp.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NTrent Piepho <tpiepho@impinj.com>
Tested-by: NFabio Estevam <fabio.estevam@nxp.com>

This platform has been marked as orphaned since September 2013, remove.
Signed-off-by: NTom Rini <trini@konsulko.com>

This platform has been marked as orphaned since September 2013, remove.
Signed-off-by: NTom Rini <trini@konsulko.com>

Replace fatload with the fs generic loading interface ('load' command).
Signed-off-by: NVanessa Maegima <vanessa.maegima@nxp.com>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>

Working with HAB on the i.MX7 we've encountered a case where a board that
successfully authenticates u-boot when booting Linux via OPTEE subsequently
fails to properly bring up the RTC.

The RTC registers live in the low-power block of the Secure Non-Volatile
Storage (SNVS) block.

The root cause of the error has been traced to the HAB handing off the
SNVS-RTC in a state where HPCOMR::NPSWA_EN = 0 in other words where the
Non-Privileged Software Access Enable bit is zero. In ordinary
circumstances this is OK since we typically do not run in TZ mode, however
when we boot via HAB and enablng TrustZone, it is required to set
HPCOMR::NPSWA_EN = 1 in order for the upstream Linux driver to have
sufficient permissions to manipulate the SNVS-LP block.

On our reference board it is the difference between Linux doing this:

root@imx7s-warp-mbl:~# dmesg | grep rtc
snvs_rtc_enable read 0x00000000 from SNVS_LPLR @ 0x00000034
snvs_rtc_enable read 0x00000021 from SNVS_LPCR @ 0x00000038
snvs_rtc_enable read 0x00000000 from SNVS_HPLR @ 0x00000000
snvs_rtc_enable read 0x80002100 from SNVS_HPCOMR @ 0x00000004
snvs_rtc 30370000.snvs:snvs-rtc-lp: rtc core: registered
         30370000.snvs:snvs-rtc-lp as rtc0
snvs_rtc 30370000.snvs:snvs-rtc-lp: setting system clock to2018-04-01 00:51:04 UTC (1522543864)

and doing this:

root@imx7s-warp-mbl:~# dmesg | grep rtc
snvs_rtc_enable read 0x00000000 from SNVS_LPLR @ 0x00000034
snvs_rtc_enable read 0x00000020 from SNVS_LPCR @ 0x00000038
snvs_rtc_enable read 0x00000001 from SNVS_HPLR @ 0x00000000
snvs_rtc_enable read 0x00002020 from SNVS_HPCOMR @ 0x00000004
snvs_rtc 30370000.snvs:snvs-rtc-lp: failed to enable rtc -110
snvs_rtc: probe of 30370000.snvs:snvs-rtc-lp failed with error -110
hctosys: unable to open rtc device (rtc0)

Note bit 1 of LPCR is not set in the second case and is set in the first
case and that bit 31 of HPCOMR is set in the second case but not in the
first.

Setting NPSWA_EN in HPCOMR allows us to boot through enabling TrustZone
and continue onto the kernel. The kernel then has the necessary permissions
to set LPCR::SRTC_ENV (RTC enable in the LP command register) whereas in
contrast - in the failing case the non-privileged kernel cannot do so.

This patch adds a simple init_snvs() call which sets the permission-bit
called from soc.c for the i.MX7. It may be possible, safe and desirable to
perform this on other i.MX processors but for now this is only tested on
i.MX7 as working.
Signed-off-by: NBryan O'Donoghue <bryan.odonoghue@linaro.org>

By using this file one can avoid cluttering <board>.h file with u-boot
HUSH commands necessary for booting target device.

With such approach the commands are stored only in one place and can be
reused if needed.
Signed-off-by: NLukasz Majewski <lukma@denx.de>
Reviewed-by: NStefano Babic <sbabic@denx.de>

This commit provides support for Kieback & Peter GmbH IMX6Q based
TPC board.

U-boot console output:

U-Boot SPL 2018.05-rc1-00005-g631e2d01fd (Apr 04 2018 - 21:16:24 +0200)
Trying to boot from MMC1

U-Boot 2018.05-rc1-00005-g631e2d01fd (Apr 04 2018 - 21:16:24 +0200)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 37C
Reset cause: POR
Board: K+P KP_IMX6Q_TPC i.MX6Q
       Watchdog enabled
I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Net:   FEC [PRIME]
Autoboot in 3 seconds

Enable display backlight only if a message needs to be displayed.
The kernel re-initializes the backlight, which results in some
unwanted artifacts.
Signed-off-by: NIan Ray <ian.ray@ge.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>