After splitting rootfs images to BACKUP and ACTIVE, the "factory"
u-boot also needs to update the former.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Test case:
The fitImage gets corrupted:
truncate -c -s 3M fitImage
run tftp_mmc_fitImg
setenv boot_os y
reset
[board shall hang in SPL with
"Trying to boot from MMC1" information]
Then after X seconds WDT is causing board to reset. After N boot attempts
we enter recovery mode.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
To enter the special mode, one needs to short cut two pads with e.g. screw
driver.
After power up the SPL will execute u-boot in which proper actions will be
taken.
It is worth noting that we do not alter envs (even the BOOT_FROM variable)
and unconditionally go to recovery.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
The SPI-NOR partition information has been updated to store
swupdate-kernel-FIT just after envs as well as two times larger
swupdate-initramfs image.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
This is a prerequisite patch to combine SWUpdate and Linux recovery
initramfs images.
It removes the support for it.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Since display5 is now supporting boot counting, we can just reset the
board when bootm fails (i.e. it doesn't boot the fitImage kernel for
any reason).
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Force booting through u-boot proper when environment error encountered
(as a result of either broken SPI-NOR or erased envs).
Signed-off-by: Lukasz Majewski <lukma@denx.de>
It may be necessary to update the content of the whole SPI-NOR memory at
once with using a single command (tftp_sf_img).
Signed-off-by: Lukasz Majewski <lukma@denx.de>
To test if this partition is present - one needs to write:
display5 > sf probe; mtdparts
display5 > sf erase factory +0x100000
Signed-off-by: Lukasz Majewski <lukma@denx.de>
When BOOT_FROM = FACTORY, then the LEG's factory setup is performed.
This code relies on boot_nfs u-boot command, so it shall be adjusted
appropriately (e.g. provide proper fitImage file).
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Currently when EFI application boots, it says:
CPU: x86_64, vendor <invalid cpu vendor>, device 0h
Fix this by calling x86_cpu_init_f() in arch_cpu_init().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
To avoid confusion, let's rename the efi-x86 target to efi-x86_app.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This turns on the EFI framebuffer driver support so that a graphics
console can be of additional help.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds a DM video driver for U-Boot as the EFI payload. The driver
makes use of all necessary information from the passed EFI GOP info
to create a linear framebuffer device, as if it were initialized by
U-Boot itself.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
If UEFI BIOS has the graphics output protocol (GOP), let's pass its
information to U-Boot payload so that U-Boot can utilize it (eg:
an EFI framebuffer driver).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that we have generic EFI payload support, drop EFI-specific test
logics in BayTrail Kconfig and codes, and all BayTrail boards too.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that we have generic EFI payload support for all x86 boards,
drop the QEMU-specific one.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
It is possible to create a generic EFI payload for all x86 boards.
The payload is configured to include as many generic drivers as
possible. All stuff that touches low-level initialization are not
allowed as such is the EFI BIOS's responsibility. Platform specific
drivers (like gpio, spi, etc) are not included.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds arch_cpu_init() to the payload codes, in preparation for
supporting a generic efi payload.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present the EFI application and payload support codes in the x86
directory is distributed in a hybrid way. For example, the Kconfig
options for both app and payload are in arch/x86/lib/efi/Kconfig,
but the source codes in the same directory get built only for
CONFIG_EFI_STUB.
This refactors the codes by consolidating all the EFI support codes
into arch/x86/cpu/efi, just like other x86 targets.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since commit f3b5056c4e ("efi_loader: split README.efi into two
separate documents"), the original README.efi was renamed to
README.u-boot_on_efi, but x86 doc still refers to the old one.
This updates the x86 doc to reference both README.u-boot_on_efi and
README.uefi.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
UEFI specifies the calling convention used in Microsoft compilers;
first arguments of a function are passed in (%rcx, %rdx, %r8, %r9).
All other compilers use System V ABI by default, passing first integer
arguments of a function in (%rdi, %rsi, %rdx, %rcx, %r8, %r9).
These ABI also specify different sets of registers that must be preserved
across function calls (callee-saved).
GCC allows using the Microsoft calling convention by adding the ms_abi
attribute to a function declaration.
Current EFI implementation in U-Boot specifies EFIAPI for efi_main()
in the test apps but uses default calling convention in lib/efi.
Save efi_main() arguments in the startup code on x86_64;
use EFI calling convention for _relocate() on x86_64;
consistently use EFI calling convention for efi_main() everywhere.
Signed-off-by: Ivan Gorinov <ivan.gorinov@intel.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Fix warning when compiling cherryhill.dts with latest DTC:
"Warning (avoid_unnecessary_addr_size): /pci/pch@1f,0: unnecessary
#address-cells/#size-cells without "ranges" or child "reg" property"
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The V3M Eagle uses flash with 128 kiB or 256 kiB sectors,
disable the 4k sector support.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Turning the cache off can help when experimenting with bare metal
applications, enable the cache command on V3M Eagle to make that
easier.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Fix the CPGWPR/CPGWPCR register address on V3M Eagle to unlock
access to the CPG clock control registers.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Add EtherAVB PHY reset on V3M Eagle to let the AVB driver unreset the PHY.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Add EtherAVB pinmux node on V3M Eagle to set the pinmux configuration.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Add device tree nodes for the Renesas RPC HF/QSPI controller
to R8A77990 E3.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Here we just add a tool for HSDK flashable images preparation
together with extensive documentation for HSDK board.
This will help real-life users to update U-Boot on the board.
HSDK board has preloader that reads SPI flash pages and searches
for a special image header to fetch and load binary.
Add tool, make target (bsp-generate) to generate
update script and u-boot binary image with header for preloader.
Also add script to default environment to apply updates.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This function is used only inside this driver that's why should be
static.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This issue was found when OF_LIVE was enabled that there are scrambled
chars on the console like this:
Chip ID: zu3eg
Watchdog: Started��j� sdhci@ff160000: 0, sdhci@ff170000: 1
In: serial@ff010000
I found a solution for this problem exactly the same as I found later in
serial_msm fixed by:
"serial: serial_msm: initialize uart only before relocation"
(sha1: 7e5ad796bc)
What it is happening is that output TX fifo still contains chars to be
sent and _uart_zynq_serial_init() resets TX fifo even in the middle of
transfer.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Change logic and put char to fifo till there is a space in output fifo.
Origin logic was that output fifo needs to be empty. It means only one
char was in output queue.
Also remove unused ZYNQ_UART_SR_TXEMPTY macro.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Coding style is checking to use BIT macros instead of shifts.
The patch is also fixing the rest of macros which should be BITs instead
of hex numbers.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Lukasz Majewski
Bin Meng
Ivan Gorinov
Tom Rini
Marek Vasut
Alexey Brodkin
Eugeniy Paltsev
Michal Simek