We don't need to enable USB or i8042 for the app. Enable only serial for
now.
Series-to: concept
Cover-letter:
bootctl: Expand bootctl to include a new UI
The current bootctl UI is fairly basic, just supporting a keyboard menu
with text.
Now that expo supports a mouse, add a more interesting UI, with more
graphical elements. Provide a way to switch between this and the simple
UI.
This series also includes some small test improvements, along with a
patch to remove a blob from a bloblist.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Unfortunately we cannot do this yet, as when booting with QEMU the
devicetree is provided at the start of memory. Until we have a built-in
way to handle copying this, we must retain the fdt_addr variable.
This reverts commit acc02734be265e92ec88ace5ac097ccb3099d40f.
Signed-off-by: Simon Glass <sjg@chromium.org>
This variable is not needed in the ARM app and can be confusing since
there might not be memory at this location. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
The compatible string cannot be detected on the host so is not shown by
fupdtool. Add a simple text file to provide the mapping.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide some CHIDs for the app, so it can locate the compatible strings.
These are taken from Stubble commit bac4edb14be, with the original files
generated by running 'fwupdtool hwids' on each device.
Signed-off-by: Simon Glass <sjg@chromium.org>
When running under QEMU the FDT is available at the start of RAM. Set
fdt_addr to this address, so that the FDT can be passed onto the OS.
If the OS provides its own devicetree, that is used instead of the QEMU
one.
Signed-off-by: Simon Glass <sjg@chromium.org>
When the app is booting a kernel without using EFI, it must first exit
the boot services provided by EFI. Add a hook for this, using
bootm_final()
Signed-off-by: Simon Glass <sjg@chromium.org>
This patches tidies up a few things in the recently added EFI app for
ARM:
- Use 0 as the value for SYS_LOAD_ADDR
- Reword help for TARGET_EFI_ARM_APP64
- Do the same for x86-app targets, for consistency
- Delete efi-arm_app32 MAINTAINERS entry since there is no such thing
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Caleb Connolly <caleb.connolly@linaro.org>
Introduce an EFI app for arm64 and update the documentation.
Provide a value for LOAD_ADDR to avoid a link error.
Signed-off-by: Simon Glass <sjg@chromium.org>
We don't need to manually add the PE header, since binutils has support
for this now. Remove it to simplify the file.
Set the link-target to efi-app-aarch64 so that binutils knows what to
do. Add rules to pick up the arm64 files.
Make some updates to the link-script for arm64, so this all works:
- Pass .hash .eh_frame and .reloc sections through to objcopy
- Put RELA pieces into a single section
- Put linker lists into .data
- Embed the dtb
Add a config.mk fragment into the baord directory.
Note that it does not seem to be possible to use this approach with
32-bit ARM, so this is left alone.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present only x86 supports the EFI app and (apart from Qualcomm) the
payload. In preparation for supporting 64-bit ARM more generally, rename
the existing ARCH_EFI option to ARCH_EFI_X86, using that to define a
generic ARCH_EFI which will be enabled for all architectures.
Signed-off-by: Simon Glass <sjg@chromium.org>
The 'vendor' concept comes from arch/x86. Rather than letting this
spread around the tree, rename it to ARCH_EFI.
While EFI is not quite an architecture in the strict sense, it is
similar to sandbox in that it sits somewhat above the CPU architecture.
Signed-off-by: Simon Glass <sjg@chromium.org>
So far only x86 supports the EFI app. ARM is going the same way, so
allow these options to be enabled for 64-bit ARM too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Since we plan to support the EFI app and payload on 64-bit ARM too,
rename the x86 target.
Adjust the Kconfig rules to allow non-x86 builds to be added.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the efi-x86_payload* platforms and remove
the otherwise empty file.
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the efi-x86_app* platforms and remove
the otherwise empty file.
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of reviewing a new platform, Daniel Schwierzeck noted that we
can have an empty Makefile in the board directory and don't need an
empty board.c file as well. Further with further cleanup in the
Makefile we can now omit the Makefile entirely. Remove a number of now
unnecessary board.c and Makefiles.
Signed-off-by: Tom Rini <trini@konsulko.com>
Use the common include. Drop the unnecessary changes, since missing
stdio drivers will be ignored.
Drop everything from the config.h file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
In a few cases we have MAINTAINERS entries that are missing obvious
paths or files. Typically this means a board directory that did not list
itself, but in a few cases we have a Kconfig file or similar.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE
and this makes it imposible to use CONFIG_VAL().
Rename it to resolve this problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current EFI video driver only works when running in the stub. In that
case the stub calls boot services (before jumping to U-Boot proper) and
copies the graphics info over to the efi table. This is necessary because
the stub exits boot services before jumping to U-Boot.
The app maintains access to boot services throughout its life, so does not
need to do this. Update the driver to support calling boot services
directly.
Enable video output for the app. Note that this uses the
EFI_GRAPHICS_OUTPUT_PROTOCOL protocol, even though it mentions vesa.
A sample qemu command-line for this case is:
qemu-system-x86_64 -bios /usr/share/edk2.git/ovmf-ia32/OVMF-pure-efi.fd
-drive id=disk,file=try.img,if=none,format=raw -nic none
-device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Most modern platforms use 64-bit EFI so it is useful to have a U-Boot app
that runs under that. Add a (non-functional) build for this.
Note that --whole-archive causes the gcc 9.2 linker to crash, so disable
this for now. Once this is resolved, things should work.
For now, avoid mentioning the documentation for the 64-bit app, since it
does not work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
start.S does nothing and can be safely removed. Makefile is still being used
by the build system, so simply drop the rule from it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
A number of board function belong in init.h with the others. Move them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
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>
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>
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>
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>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
This is architecture-dependent early initialization hence should
be put in the platform Kconfig.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We don't need this anymore - we can use device tree and the new pinconfig
driver instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
