Each entry of the EFI memory descriptors occupies map->desc_size,
not sizeof(struct efi_mem_desc).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present in dram_init_banksize() it ignores conventional memory
above 4GB. This leads to wrong DRAM size is printed during boot.
Remove such limitation.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Enable PRE_CONSOLE_BUFFER so that the full boot output can be viewed
on the video console for the EFI payload.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The use_uart assignment should follow immediately after the call to
exit_boot_services(), in case we want some debug output after that.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since commit bb0bb91cf0 ("efi_stub: Use efi_uintn_t"), EFI x86
64-bit payload does not work anymore. The call to GetMemoryMap()
in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since
the payload itself is still 32-bit U-Boot, efi_uintn_t gets wrongly
interpreted as int, but it should actually be long in a 64-bit EFI
environment.
This changes the x86 __kernel_size_t conditionals to use compiler
provided defines instead. That way we always adhere to the build
environment we're in and the definitions adjust automatically.
Fixes: bb0bb91cf0 ("efi_stub: Use efi_uintn_t")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently efi.h determines a few bits of its environment according to
config options. This falls apart with the efi stub support which may
result in efi.h getting pulled into the stub as well as real U-Boot
code. In that case, one may be 32bit while the other one is 64bit.
This patch changes the conditionals to use compiler provided defines
instead. That way we always adhere to the build environment we're in
and the definitions adjust automatically.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: added some comments to describe the __x86_64__ check]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
For boards that don't route serial port pins out, it's quite common
to attach a USB keyboard as the input device, along with a monitor.
However USB is not automatically started in the generic efi payload
codes. This uses a payload specific last_stage_init() to start the
USB bus, so that a USB keyboard can be used on the U-Boot shell.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The generic efi payload currently does not enumerate the PCI bus,
which means peripherals on the PCI bus are not discovered by their
drivers. This uses board_early_init_r() to do the PCI enumeration.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
With driver model philosophy, we should avoid explicitly calling
driver initialization routine during boot. This updates the ram
init sequence table to exclude the IDE initialization for DM BLK.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The default vesa mode was changed since commit 55b4e1b7d9
("x86: Change default FRAMEBUFFER_VESA_MODE of some boards") for
better VxWorks compatibility but with the changes QEMU video console
no longer works. This is because QEMU's vgabios implements the VESA
mode 8:8:8 as 24bpp without an alpha channel, which U-Boot's video
console driver currently does not support yet.
We need change to real 32bpp in order to make it work again. QEMU
vgabios implements the custom 32bpp VESA mode starting from 0x140
(320x200x32) to 0x147 (1600x1200x32). Set it to 0x144 (1024x768x32).
Fixes: 55b4e1b7d9 ("x86: Change default FRAMEBUFFER_VESA_MODE of some boards")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
car.o can only be used with start.o, not with start64.o.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Previous rename of efi-x86 target missed the MAINTAINERS update,
which caused the buildman warnings:
WARNING: no status info for 'efi-x86_app'
WARNING: no maintainers for 'efi-x86_app'
This updates the board MAINTAINERS to reflect the up-to-date info.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that the clock-frequency information has been moved to the
driver, more DT sync is possible.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
In Linux, the clock rate of the UART is given by the clock driver.
If you try to follow that in U-Boot, you would end up with adding
more u-boot,dm-pre-reloc properties, and also the clock driver would
be too big for SPL, which is used for UniPhier ARMv7 platform.
The current solution is to add 'clock-frequency' property to the
UART nodes, but it does not exist in the DT files in Linux. I do
not want to let DT diverge for U-Boot.
Check the SoC compatible and set the clock rate according to it.
This will be helpful to sync DT between Linux and U-Boot.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Enable the on-chip ethernet driver for uniphier_{v7,v8}_defconfig.
Disable the on-board SMC911x because it has not migrated to the
driver model yet - it is not possible to enable DM and non-DM
drivers at the same time.
The CONFIG_SMC911X for uniphier_ld4_sld8_defconfig is still kept
because the on-chip ethernet driver for LD4, sLD8 is not supported
yet.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
A single urgent fix to make sure green and red are not swapped
in OSs that make use of EFI GOP frame buffers to display pictures
(such as efifb in Linux).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJbK8MMAAoJECszeR4D/txgqZQQAIpDTRQkWrrmiWh+h08pGMVp
k38tx84O+iToYnpQA4zH5g0QrbpzgOtvVjQJ39QTxn5p+tPYSmXkUTS5jtxppu+o
LszVHP+reQfHlL+1aV2TMsf5e1V+uoNkG3ZEJXfHxjz6VYu1vYw2psAD23vKH0PO
yOL6o5unJWYdIocNbniGwWKNYyVbiVHcBN2ErHLMRvLKeTXTJr4OZKt98sSO60Pb
p/z9sO1o1Wgwm/aiV1cD91cAItaVZD/m9cFoqOwnbwjDEM6dlRFsEhy0JLTnH/MQ
qH9wIy1W9EdON3arjfvcDejRUlX3+7uf113GyWsHPzN/p7Lm9M02UlqT5jk8njf8
TD9k5QMW6rxDsO4Pu2+zHwU38kaMLv5htJNWrcj2fOm1GDo1q0sRlTp7v6r9I5BH
KwkR69ZPDPnDj+9ApWkYVRbTzhzu+OoUbVnbB/WYTY4j0jxkW8jEh1e1yIrqlmUA
sxjPLhbWFn+PpwDzIZzLIqdSJsxX7jzqzGtmAxsmqquAqKNu3KJUn6PTJ1cLhxbD
I7qH/gHzWBLHCv/nL+/oMin9AC6UYep2zcsJMXfiTIrFSTjuWGvq4wy/WGaZG4mQ
IyrsuZ9YXDobmiV+5mNxMCvUJs31z+g20EG0+1In3C1DTpjj77t/qS4ZzKbaPwYL
DhgNUrdvlKtdMYpbWbEs
=MrHq
-----END PGP SIGNATURE-----
Merge tag 'signed-efi-2018.07' of git://github.com/agraf/u-boot
Patch queue for efi - 2018-06-21
A single urgent fix to make sure green and red are not swapped
in OSs that make use of EFI GOP frame buffers to display pictures
(such as efifb in Linux).
We store pixels as BGRA in memory, as can be seen from struct efi_gop_pixel.
So we need to expose the same format to UEFI payloads to actually have them
use the correct colors.
Reported-by: Fabian Vogt <fvogt@suse.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
As many targets are now commonly built with gcc-6 or later (which
defaults to a newer C standard than older compilers), certain C
constructs are now being used as they produce more readable code. And
while all compilers that we support building with support the C11
standard (and GNU11) they do not default to that standard. Ensure that
we pass along -std=gnu11 when building.
Signed-off-by: Tom Rini <trini@konsulko.com>
Enable USB on all Amlogic Meson GXL based board.
Enable Regulator support on all boards.
Enable ADC support on the LibreTech-CC board.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Use the clk framework to initialize clocks from drivers that need them
instead of having hardcoded frequencies and initializations from board
code.
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Introduce a basic clock driver for Amlogic Meson SoCs which supports
enabling/disabling clock gates and getting their frequency.
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
The SARADC driver was merged after the following commit :
commit d35812368a ("regmap: change regmap_init_mem() to take ofnode instead udevice")
Thus breaking build, this patch fixes the regmap_init_mem accordingly.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
BOOT2 partition is empty and free for using to store the environment.
Use that instead of the default user partition.
Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
cpu_cmd() is reading cpu number via simple_strtoul() which is always
unsigned type.
Platform code implementations are not expecting that nr can be negative
and there is not checking in the code for that too.
This patch is using u32 type for cpu number to make sure that platform
code get proper value range.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
The ARM64 has 2 MiB alignment requirement for the kernel. When using
fitImage, this requirement may by violated, the kernel will thus be
executed from unaligned address and fail to boot. Do what booti does
and run booti_setup() for kernel_noload images on arm64 to obtain a
suitable aligned address to which the image shall be relocated.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Bin Chen <bin.chen@linaro.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Tom Rini <trini@konsulko.com>
Add option to the booti_setup() which indicates to it that the caller
requires the image to be relocated to the beginning of the RAM and
that the information whether the image can be located anywhere in RAM
at 2 MiB aligned boundary or not is to be ignored. This is useful ie.
in case the Image is wrapped in another envelope, ie. fitImage and not
relocating it but moving it would corrupt the envelope.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Bin Chen <bin.chen@linaro.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-By: Bin Chen <bin.chen@linaro.org>
At present the code overruns the bar[] array. Fix this.
At the same time, drop the leading / from the "/spl" path so that we can
run U-Boot SPL with:
spl/u-boot-spl
rather than requiring:
/path/to/spl/u-boot-spl
Reported-by: Coverity (CID: 131199)
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Move the strdup() call so that it is only done when we know we will bind
the device.
Reported-by: Coverity (CID: 131216)
Signed-off-by: Simon Glass <sjg@chromium.org>
The current code might succeed on the first allocation and fail on the
second. Separate the checks to avoid this problem.
Of course, free() will never fail and the chances that (when allocating
two small areas) one will succeed and one will fail are just as remote.
But this keeps coverity happy.
Reported-by: Coverity (CID: 131226)
Signed-off-by: Simon Glass <sjg@chromium.org>
This loop never actually exits, but the way the code is written this is
not obvious. Add an explicit error check.
Reported-by: Coverity (CID: 131280)
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Add explicit init of region to NULL per LLVM warning]
Signed-off-by: Tom Rini <trini@konsulko.com>
Add regulator nodes and pinmux settings to the SDHI3 on E3 Ebisu
and enable HS200 mode on it.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Both the RAVB and SH ether driver now support parsing the PHY reset
GPIOs from both the PHY nodes and the MAC nodes, move the reset GPIOs
back into the PHY nodes to minimize DT difference between U-Boot and
Linux.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
The recent DTs have the PHY reset GPIO in the PHY node rather than
the ethernet MAC node, support extracting the PHY reset GPIO info
from both the PHY node and ethernet MAC node.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Joe Hershberger <joe.hershberger@ni.com>
The recent DTs have the PHY reset GPIO in the PHY node rather than
the ethernet MAC node, support extracting the PHY reset GPIO info
from both the PHY node and ethernet MAC node.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Joe Hershberger <joe.hershberger@ni.com>
The RAVB only supports 100Full and 1000Full operation, it does not support
10Full or any Half-duplex modes. The PHY could still advertise those features
though, so filter out the PHY features accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Joe Hershberger <joe.hershberger@ni.com>
