The qfw command interface used to depend on X86, this patch removes
this restriction so it can be built for sandbox for testing. For normal
usage, it can only be used with CONFIG_QEMU.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The qfw command interface makes use of CONFIG_LOADADDR and
CONFIG_RAMDISKADDR to setup kernel. But not all boards have these macros,
which causes build problem on those platforms.
This patch fixes this issue.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Make file names consistent with CONFIG_QFW and CONFIG_CMD_QFW
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This patch splits qfw command interface and qfw core function into two
files, and introduces a new Kconfig option (CONFIG_QFW) for qfw core.
Now when qfw command interface is enabled, it will automatically select
qfw core. This patch also makes the ACPI table generation select
CONFIG_QFW.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This patch is part of the qfw refactor work. This patch makes
qemu_fwcfg_present() and qemu_fwcfg_dma_present() public functions.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This patch is part of the qfw refactor work.
The qemu_fwcfg_free_files() function is only used in error handling in
ACPI table generation, let's not make this a core function and move it
to the right place.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This patch is part of the refactor work of qfw. It adds 3 APIs to qfw
core to iterate firmware list.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
- Move the command portion of arch/x86/cpu/qemu/fw_cfg.c into
cmd/qemu_fw_cfg.c
- Move arch/x86/include/asm/fw_cfg.h to include/qemu_fw_cfg.h
- Rename ACPI table portion to arch/x86/cpu/qemu/acpi_table.c
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the MMC subsystem maintains its own list of MMC devices. This
cannot work with driver model, which needs to maintain this itself. Move the
list code into a separate 'legacy' file. The core MMC code remains, and will
be shared with the driver-model implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the SATA command code includes both the command-processing code
and the core SATA functions and data structures.
Separate the latter into its own file, adding functions as needed to avoid
the command code accessing data structures directly.
With this commit:
- All CONFIG option are referenced from the non-command code
- The concept of a 'current SATA device' is confined to the command code
This will make it easier to convert this code to driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the IDE command code includes both the command-processing code
and the core IDE functions and data structures.
Separate the latter into its own file, adding functions as needed to avoid
the command code accessing data structures directly.
With this commit:
- Most CONFIG option are referenced from the non-command code
- The concept of a 'current IDE device' is confined to the command code
This will make it easier to convert this code to driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the SCSI command code includes both the command-processing code
and the core SCSI functions and data structures.
Separate the latter into its own file, adding functions as needed to avoid
the command code accessing data structures directly. This functions use the
new legacy block functions.
With this commit:
- There is no CONFIG option referenced from the command code
- The concept of a 'current SCSI device' is confined to the command code
This will make it easier to convert this code to driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
This option currently enables both the command and the SCSI functionality.
Rename the existing option to CONFIG_SCSI since most of the code relates
to the feature.
Signed-off-by: Simon Glass <sjg@chromium.org>
Since we do not build any board with CONFIG_SUPPORT_EMMC_RPMB , this
piece of code evaded conversion. Fix the following compiler error:
cmd/mmc.c: In function 'do_mmcrpmb':
cmd/mmc.c:316:32: error: 'struct blk_desc' has no member named 'part_num'
original_part = mmc->block_dev.part_num;
^
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Tom Rini <trini@konsulko.com>
I2C_RXTX_LEN from include/i2c.h is not defined if CONFIG_DM_I2C is
enabled. This leads to a compilation error on boards that enable both
CONFIG_CMD_EEPROM and CONFIG_DM_I2C.
To avoid this, we define I2C_RXTX_LEN in cmd/eeprom.c if it is not
already defined.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
This syncs up the current cmd/Kconfig and include/configs/ files with the
only exception being CMD_NAND. Due to how we have used this historically
we need to take further care here when converting.
Signed-off-by: Tom Rini <trini@konsulko.com>
Previously, ret could be used uninitialized if
blk_get_device_part_str() failed. Default to ret being set to -1 so
that we always return an err up if we have a problem and then invert the
logic on testing ums_count as when that is non-zero is the time we can
return 0.
Cc: John Tobias <john.tobias.ph@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
By applying this patch, it will give us some flexibility to expose
a selected partition/s.
e.g:
1. To expose several partitions
ums 0 mmc 0:1,0:6
2. To expose the all partitions
ums 0 mmc 0:0
3. To expose multiple partititions on several devices
ums 0 mmc 0:1,1:6
4. It support legacy format
ums 0 mmc 0
Signed-off-by: John Tobias <john.tobias.ph@gmail.com>
The bootefi cmd today fetches its device tree pointer from either the
location appointed by "fdt addr" with a fallback to the U-Boot control
fdt.
This integration is unusual for U-Boot and diverges from the way we
usually handle parameters to boot commands. So let's pass the fdt
directly into the bootefi command instead and move the control fdt
logic into the distro boot script.
Signed-off-by: Alexander Graf <agraf@suse.de>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Andreas Färber <afaerber@suse.de>
The uEFI spec doesn't dictate where the device tree should live at, but
legacy 32bit ARM grub2 has some assumptions that it may stay at its place
when it's already loaded by the firmware.
So let's put it somewhere where Linux that comes after would happily find
it - around the recommended 128MB line.
Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>
When the user did not pass any device tree or the boot script
didn't find any, let's use the system device tree as last resort
to get something the payload (Linux) may understand.
This means that on systems that use the same device tree for U-Boot
and Linux we can just share it and there's no need to manually provide
a device tree in the target image.
While at it, also copy and pad the device tree by 64kb to give us
space for modifications.
Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>
Whenever we want to tell our payload about a path, we limit ourselves
to a reasonable amount of characters. So far we only passed in device
names - exceeding 16 chars was unlikely there.
However by now we also pass real file path information, so let's increase
the limit to 32 characters. That way common paths like "boot/efi/bootaa64.efi"
fit just fine.
Signed-off-by: Alexander Graf <agraf@suse.de>
The payload gets information on where it got loaded from. This includes
the device as well as file path.
So far we've treated both as the same thing and always gave it the device
name. However, in some situations grub2 actually wants to find its loading
path to find its configuration file.
So let's split the two semantically separte bits into separate structs and
pass the loaded file name into our payload when we load it using "load".
Signed-off-by: Alexander Graf <agraf@suse.de>
When loading an el torito image, uEFI exposes said image as a raw
block device to the payload.
Let's do the same by creating new block devices with added offsets for
the respective el torito partitions.
Signed-off-by: Alexander Graf <agraf@suse.de>
Create CMD_FDT Kconfig entry to have an option to disable fdt command
which is not required for small configuration which requires libfdt
only.
Enable it by default for all targets which enables OF_LIBFDT.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[trini: Fixup flea3/sandbox/id8313/siemens-am33xx/smartweb]
Signed-off-by: Tom Rini <trini@konsulko.com>
Introduce env support for sata device.
1. Implement write_env/read_env/env_relocate_spec/saveenv/sata_get_env_dev
2. If want to enable this feature, define CONFIG_ENV_IS_IN_SATA, and
define CONFIG_SYS_SATA_ENV_DEV or implement your own sata_get_ev_dev.
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stuart Longland <stuartl@vrt.com.au>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Some usb hosts may have failed to probe on "usb start", i.e. an otg
host without an otg-host cable plugged in.
"usb tree" would cause the probe method of these hosts to get called
again, something which should only happen on "usb reset".
This commit fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The dm usb_kbd_remove function() will deregister the usb keyboard for
us on a "usb reset" / "usb stop" so there is no need to manually call
usb_kbd_deregister() in the dm case.
This commit removes usb_kbd_deregister() in the dm case fixing the
following "usb reset" errors:
usb_kbd_remove: warning, ret=-6
device_remove: Device 'usb_kbd' failed to remove, but children are gone
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Call blk_dread, blk_dwrite, blk_derase to ensure that the block cache is
used if enabled and to remove build breakage when CONFIG_BLK is enabled.
Signed-off-by: Eric Nelson <eric@nelint.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Call blk_dread, blk_dwrite, blk_derase to ensure that the block cache is
used if enabled and to remove build breakage when CONFIG_BLK is enabled.
Signed-off-by: Eric Nelson <eric@nelint.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add a block device cache to speed up repeated reads of block devices by
various filesystems.
This small amount of cache can dramatically speed up filesystem
operations by skipping repeated reads of common areas of a block
device (typically directory structures).
This has shown to have some benefit on FAT filesystem operations of
loading a kernel and RAM disk, but more dramatic benefits on ext4
filesystems when the kernel and/or RAM disk are spread across
multiple extent header structures as described in commit fc0fc50.
The cache is implemented through a minimal list (block_cache) maintained
in most-recently-used order and count of the current number of entries
(cache_count). It uses a maximum block count setting to prevent copies
of large block reads and an upper bound on the number of cached areas.
The maximum number of entries in the cache defaults to 32 and the maximum
number of blocks per cache entry has a default of 2, which has shown to
produce the best results on testing of ext4 and FAT filesystems.
The 'blkcache' command (enabled through CONFIG_CMD_BLOCK_CACHE) allows
changing these values and can be used to tune for a particular filesystem
layout.
Signed-off-by: Eric Nelson <eric@nelint.com>
Make sure to call unmap_sysmem() for address allocated by map_sysmem()
before leaving the function; however this patch gives no impact on
the behavior because map_sysmem()/unmap_sysmem() does nothing except
on Sandbox. Sandbox never runs this code because "booti" is a command
for booting ARM64 kernel image.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
Command parsing and processing code is not needed when the command line is
disabled. Remove this code in that case.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Check return value of strdup.
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefan Roese <sr@denx.de>
Cc: Tom Rini <trini@konsulko.com>
The EFI standard defines a simple boot protocol that an EFI payload can use
to access video output.
This patch adds support to expose exactly that one (and the mode already in
use) as possible graphical configuration to an EFI payload.
With this, I can successfully run grub2 with graphical output.
Signed-off-by: Alexander Graf <agraf@suse.de>
