This function obtains lots of error codes and then throws them away.
Update it to return the error, moving the image pointer to an
argument.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This function only uses one argument and just needs to know the name of
the command which called it. Adjust the function to use only what it
needs. This will make it easier to call from a non-command context.
Tidy up the function comment while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This function does not modify its first argument, so mark it const. Also
move the comments to the header file and expand them to provide more
useful information.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Move this code and image_get_kernel() higher in the file to avoid the
need for a forward declaration.
No attempt is made to remove #ifdefs or adjust the code in any other
way.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Move the argument decoding to the caller, to avoid needing to pass the
command-line arguments.
Add a function comment while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This function does not use its arguments. Drop them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
bootmeth_efi doesn't allocate any buffer to load efi in any case.
enable static buffer flag for all cases.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>
While booting with efi, if fdt isn't available externally,
just use the built-in one.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>
We need to set boot->fname before calling efi_set_bootdev
otherwise this crashes as bflow->fname is null.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>
bootmeth_efi sets up bootp_arch which is read later in bootp.c
Currently bootp_arch is being set as integer string and being
read in bootp.c as hex, this sends incorrect arch value to dhcp server
which in return sends wrong file for network boot.
For ARM64 UEFI Arch value is 0xb (11), here we set environment as 11
and later is read as 0x11 and 17 is sent to dhcp server.
Setting it as hex string fixes the problem.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>
EFI applications can be very large and thus used to cause boot failures
when malloc() space was exhausted.
A recent changed fixed this by using the kernel_addr_r environment var
as the address of the buffer. However, it still frees the buffer when
the bootflow is discarded.
Fix this by introducing a flag to indicate whether the buffer was
allocated, or not.
Note that kernel_addr_r is not the last word here. It might be better
to use lmb to place images. But there is a lot of refactoring to do
before we can remove the environment variables. The distro scripts rely
on them so it is safe for bootstd to do so too.
Fixes: 6a8c2f9781 bootstd: Avoid allocating memory for the EFI file
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported by: Simon Glass <sjg@chromium.org>
Reported by: Shantur Rathore <i@shantur.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Shantur Rathore <i@shantur.com>
During bootstd scanning for bootdevs, if bootdev_hunt_drv() encounters
a device not found error (e.g. ENOENT), let it return a successful status
so that bootstd will continue scanning the next devices, not stopping
prematurely.
Background:
During scanning for bootflows, it's possible for bootstd to encounter a
faulty device controller. Also when the same u-boot is used for another
variant of the same board, some device controller such as SATA might
not exist.
I've found this issue while converting the Marvell Sheevaplug board to
use bootstd. This board has 2 variants, the original Sheevaplug has MMC and
USB only, but the later variant comes with USB, MMC, and eSATA ports. We
have been using the same u-boot (starting with CONFIG_IDE and later with DM
CONFIG_SATA) for both variants. This worked well with the old
envs-scripting booting scheme.
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In order for a predefined "preboot" or "bootcmd" to be executed by the
running system we must have a command line. Add CMDLINE as a
dependency.
Signed-off-by: Tom Rini <trini@konsulko.com>
As this particular bootmeth requires the command line and assorted
commands to function, make sure we have CMDLINE enabled.
Signed-off-by: Tom Rini <trini@konsulko.com>
In order to use bootmeth_cros, at least on non-X86, we need to be able
to start any type of kernel that the "bootm" code paths can handle. Add
these objects to the required list for this option.
Signed-off-by: Tom Rini <trini@konsulko.com>
This particular option is required for booting all image types,
regardless of if we are starting an OS via command line or something
else. Move the question for SYS_BOOTM_LEN to be by the question for
LEGACY_IMAGE_FORMAT, as that's where our generic OS questions start.
Signed-off-by: Tom Rini <trini@konsulko.com>
We split BOOT_DEFAULTS to have BOOT_DEFAULTS_FEATURES and
BOOT_DEFAULTS_CMDS that in turn list general features or commands that
we want enabled when BOOT_DEFAULTS is selected. We only select
BOOT_DEFAULTS_CMDS if CMDLINE is set.
Signed-off-by: Tom Rini <trini@konsulko.com>
The implementation of DISTRO_DEFAULTS is done in environment scripts and
requires the command line in order to work. Because of this, select
CMDLINE here.
Signed-off-by: Tom Rini <trini@konsulko.com>
Make AUTOBOOT depend on CMDLINE since it is mostly meaningless without it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Today, the bootmeth for using the EFI loader via bootefi depends on
calling the bootefi command directly, so make this in turn depend on
CMD_BOOTEFI.
Signed-off-by: Tom Rini <trini@konsulko.com>
This has a typo which makes the method inoperable. Correct it so that
'bootflow read' works correctly for ChromeOS.
Signed-off-by: Simon Glass <sjg@chromium.org>
Two bugs have appeared:
- arguments can have an equals sign embedded in them, which must be
considered part of the value
- arguments must fully match the name; partial matches should be
ignored
Fix these and add a test to cover both.
Signed-off-by: Simon Glass <sjg@chromium.org>
Enable the bootflow based on this bootmeth if the BootOrder EFI
variable is set.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEgWII69YpahbL5iK5gS8AYozs+qIFAmU7j50ACgkQgS8AYozs
+qIh8w/+O4UjT0sG1NLwmyV7U1Ypk+EyYaE6wmSWzpsJLfH/YvtObBJOYRuXxRVh
J9lkgCsw8Ct1ZNCrp8iVO+Dz1DtV8+QvTecrUHZqcOhTYDaqxXnlvEH2/EUhgo5T
9a/ZaDtOP1mKz754C4G6G363+iRCvbcqDECeKg9VYxfWCo1cINOmqyQCqlGxFT+h
PKiB5VzUpN/K/yiie+Hr42/+6XaykAUjUvEWeyKOsRmYY4lNiK22vG/puE42bFTh
catXwTE2a7x+yzPKkdhR0UGvDUlIKET2kF6mi+pYN2h/cSUxWTzbP/OxcU9yJOnm
qJiRZ+Woez1I7ul6ln4ci2kiWc3CTYFXfctwrBJPuJ/EO+2EEb3oHqG2S3Fc9VBZ
N17flHW7XZHEQbNexlUhk9cRpCwRuSA5OJXwW+IZIuydgNeo3xF0iYvipbjkEGgW
BBkt8PH+ivTLjEz6Gcmquvo1fHGJLHRIPg7DNb0phGHviuC0zlDJ7N5DZk0CpkiT
36siV9xK4X6qvWkOTa6Ldw60e4tN9nv3VG30uXtPHi3XdOkKfNkyIuqO/5BkkQPt
6yEc9IYXYoWNKDVUGme5+xszZp1sSvqltajG9VVNupt958dFyOSgS5aNa6B4UsWX
3XfndP1/s2bezUHoQx5zjraapKVrqBFLkGeTlCDUD+mEgP440G8=
=gvDs
-----END PGP SIGNATURE-----
Merge tag 'tpm-next-27102023' of https://source.denx.de/u-boot/custodians/u-boot-tpm
bootX measurements and measurement API moved to u-boot core:
Up to now, U-Boot could perform measurements and EventLog creation as
described by the TCG spec when booting via EFI.
The EFI code was residing in lib/efi_loader/efi_tcg2.c and contained
both EFI specific code + the API needed to access the TPM, extend PCRs
and create an EventLog. The non-EFI part proved modular enough and
moving it around to the TPM subsystem was straightforward.
With that in place we can have a common API for measuring binaries
regardless of the boot command, EFI or boot(m|i|z), and contructing an
EventLog.
I've tested all of the EFI cases -- booting with an empty EventLog and
booting with a previous stage loader providing one and found no
regressions. Eddie tested the bootX part.
Eddie also fixed the sandbox TPM which couldn't be used for the EFI code
and it now supports all the required capabilities. This had a slight
sideeffect in our testing since the EFI subsystem initializes the TPM
early and 'tpm2 init' failed during some python tests. That code only
opens the device though, so we can replace it with 'tpm2 autostart'
which doesn't error out and still allows you to perfom the rest of the
tests but doesn't report an error if the device is already opened.
There's a few minor issues with this PR as well but since testing and
verifying the changes takes a considerable amount of time, I prefer
merging it now.
Heinrich has already sent a PR for -master containing "efi_loader: fix
EFI_ENTRY point on get_active_pcr_banks" and I am not sure if that will
cause any conflicts, but in any case they should be trivial to resolve.
Both the EFI and non-EFI code have a Kconfig for measuring the loaded
Device Tree. The reason this is optional is that we can't reason
when/if devices add random info like kaslr-seed, mac addresses etc in
the DT. In that case measurements are random, board specific and
eventually useless. The reason it was difficult to fix it prior to this
patchset is because the EFI subsystem and thus measurements was brought
up late and DT fixups might have already been applied. With this
patchset we can measure the DT really early in the future.
Heinrich also pointed out that the two Kconfigs for the DTB measurements
can be squashed in a single one and that the documentation only explains
the non-EFI case. I agree on both but as I said this is a sane working
version, so let's pull this first it's aleady big enough and painful to
test.
Add a configuration option to measure the boot through the bootm
function. Add the measurement state to the booti and bootz paths
as well.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Ilias: Added some info on Kconfig explaining this is when booting !EFI
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add ahci sata bootdev and corresponding hunting function.
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
When the boot_targets environment variable is used with the distro-boot
scripts, each device is included individually. For example, if there
are three mmc devices, then we will have something like:
boot_targets="mmc0 mmc1 mmc2"
In contrast, standard boot supports specifying just the uclass, i.e.:
boot_targets="mmc"
The intention is that this should scan all MMC devices, but in fact it
currently only scans the first.
Update the logic to handle this case, without required BOOTSTD_FULL to
be enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Date Huang <tjjh89017@hotmail.com>
Reported-by: Vincent Stehlé <vincent.stehle@arm.com>
Reported-by: Ivan Ivanov <ivan.ivanov@suse.com>
Tested-by: Ivan T.Ivanov <iivanov@suse.de>
The current logic for "bootflow mmc" is flawed since it checks the
uclass of the bootdev instead of its parent, the media device. Correct
this and add a test that covers this scenario.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Ivan T.Ivanov <iivanov@suse.de>
This commit was intended to allow all bootdevs in each boot_targets
entry to be scanned. However it causes bad ordering with bootdevs, e.g.
scanning Ethernet bootdevs when it should be keeping to mmc.
Revert it so we can try another approach.
This reverts commit e824d0d0c2.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Ivan T.Ivanov <iivanov@suse.de>
When the boot_targets environment variable is used with the distro-boot
scripts, each device is included individually. For example, if there
are three mmc devices, then we will have something like:
boot_targets="mmc0 mmc1 mmc2"
In contrast, standard boot supports specifying just the uclass, i.e.:
boot_targets="mmc"
The intention is that this should scan all MMC devices, but in fact it
currently only scans the first.
Update the logic to handle this case, without required BOOTSTD_FULL to
be enabled.
I believe at least three people reported this, but I found two.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Date Huang <tjjh89017@hotmail.com>
Reported-by: Vincent Stehlé <vincent.stehle@arm.com>
Add textline to the list of objects which tthe expo builder can build.
This allows them to be provided in the description.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present cedit only supports menu keys. For textline objects we need
to insert normal ASCII characters.
We also need to handle backspace, which is ASCII 9.
In fact, expo does not make use of all the menu keys, so partition
them accordingly and update the logic to support normal ASCII
characters, too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide an implementation for textlines in the scene code, so that they
are displayed correctly. Provide a way to have a border around the
textline, with the internal part being the same colour as the
background. This looks more natural.
Signed-off-by: Simon Glass <sjg@chromium.org>
This object needs special handling when it is opened, to set up the CLI
and the vidconsole context. Add special support for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
A textline is a line of text which can be edited by the user. It has a
maximum length (in chracters) but otherwise there are no restrictions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add the CLI state, a buffer to hold the old value of the text being
edited and a place to save vidconsole entry context. These will be use
by the textline object.
Set an upper limit on the maximum number of characters in a textline
object supported by expo, at least for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
So far only menus have a background. When other object types are
rendered, they may have a background too. Make this code more generic
so it will be usable by new object types.
Signed-off-by: Simon Glass <sjg@chromium.org>
When the devicetree is too small for the property being written, we need
to expand the devicetree and retry the write.
Put this logic into a function so it can be reused.
Signed-off-by: Simon Glass <sjg@chromium.org>
So far only menus can be highlighted. With the coming addition of
text lines we need to be able to highlight other objects. Add a function
to determine whether an object can be highlighted.
Signed-off-by: Simon Glass <sjg@chromium.org>
In a lot of cases menus are the only objects which are have their own
behaviour in the cedit, e.g. to move between menus. With expo expanding
to support text, this is no-longer true.
Use a switch() statement so that we can simply insert a new 'case' for
the new object types.
Signed-off-by: Simon Glass <sjg@chromium.org>
When building an expo fails, show some information about which node
caused the problem. Use -ENOENT consistently when the ID is missing.
This makes it easier for the user to debug things.
Signed-off-by: Simon Glass <sjg@chromium.org>
This uses ARRAY_SIZE() but does not include the header file which declares
it. Fix this, so that command.h can be included without common.h
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
When 'usb stop' is run, doing 'bootflow scan' does not run the USB hunter
again so does not see any devices. Fix this by telling bootstd about the
state of USB.
Signed-off-by: Simon Glass <sjg@chromium.org>
The problem was, that zboot() didn't work because of missing
ramdisc size.
Signed-off-by: Thomas Mittelstaedt <thomas.mittelstaedt@de.bosch.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The StarFive JH7110 base boards require a header to be prefixed to the SPL
binary image. This has previously done with a vendor tool 'spl_tool'
published under a GPL-2-or-later license. Integrate this capability into
mkimage.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tested-by: Chanho Park <chanho61.park@samsung.com>
Tested-by: Milan P. Stanić <mps@arvanta.net>
This is not needed, so drop it. Also use a capital 'O' for the option,
while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
We need CONFIG_OF_LIBFDT to be able to do fdt fixups, so add that
condition.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Standard boot has been in place for a while now. Quite a few problems
have been found and fixed. It seems like a good time to mark the
script-based approach as deprecated and encourage people to use standard
boot.
Update the DISTRO_DEFAULTS Kconfig to encourage people to move to
standard boot, which is able to boot Linux distributions automatically.
Add a short migration guide to make this easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
These don't relate to booting. Move them out of there and into the same
place as the other related settings.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This option already depends on FIT, so put it under the same umbrella, so
that it appears in the FIT menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
All boards which actually define this address enable SPL_LOAD_FIT, or at
least just rely on the default value of 0. So drop the dependency.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This is a major feature with a lot of options. Give it its own menu to
tidy up the 'make menuconfig' display. Drop the 'depends on FIT' pieces
which are now unnecessary, since they are now bracketed by an 'if FIT'.
Leave CONFIG_TIMESTAMP out since it affects legacy images too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Phrases like 'Enable support for' are pointless since this is an option
which enables things. Drop that part so it is easier to follow.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Move more options relating to fixing up a device tree into the new
devicetree-fixup menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This relates to booting, so move it there. Create a new Kconfig menu for
things related to devicetree fixup.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This relates to booting since it fixes up the devicetree for the OS. Move
it into the boot/ directory.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The last user of the NEEDS_MANUAL_RELOC has been removed in commit
26af162ac8 ("arch: m68k: Implement relocation")
Remove now unused NEEDS_MANUAL_RELOC code.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The last user of the NEEDS_MANUAL_RELOC has been removed in commit
26af162ac8 ("arch: m68k: Implement relocation")
Remove now unused NEEDS_MANUAL_RELOC code.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The new name makes it clearer that this is for a full spy, with access to
the context and the event data.
Signed-off-by: Simon Glass <sjg@chromium.org>
The existing distro scripts check extlinux and scripts before EFI. Adjust
the default ordering to do the same, to avoid breaking existing flows.
Add some documentation, mentioning that this order will likely change in
future.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Da Xue <da@libre.computer>
The Kconfig references a readme file that's moved and
converted to rst so update the reference.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The existing ChromiumOS bootmeth only supports reading a single kernel
partition, either 2 or 4. In fact there are normally two options
available.
Use the GUID to detect kernel partitions, with the BOOTMETHF_ANY_PART
flag, so that bootstd does not require a valid filesystem before calling
the bootmeth.
Tidy up and improve the logging while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
[trini: Add missing select of PARTITION_TYPE_GUID]
Signed-off-by: Tom Rini <trini@konsulko.com>
Some bootmeths support scanning a partition without a filesystem on it.
Add a flag to support this.
This will allow the ChromiumOS bootmeth to find kernel partition, which
are stored in a special format, without a filesystem.
Signed-off-by: Simon Glass <sjg@chromium.org>
This field is only present when a CONFIG is set. To avoid annoying #ifdefs
in the source code, add an accessor. Update the only usage.
Note that the accessor is optional. It can be omitted if it is known that
the option is enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a command to read edit settings from CMOS RAM, using the cedit
definition to indicate which registers and bits are used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a command to write cedit settings to CMOS RAM so that it can be
preserved across a reboot. This uses a simple bit-encoding, where each
field has a 'bit position' and a 'bit length' in the schema.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a command to read cedit settings from environment variables so that
they can be restored as part of the environment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a command to write cedit settings to environment variables so that
they can be stored with 'saveenv'.
Signed-off-by: Simon Glass <sjg@chromium.org>
Support writing settings from an expo into a file in FDT format. It
consists of a single node with a two properties for each sceneitem,
one with tag ID chosen by the user and another for its text value.
Signed-off-by: Simon Glass <sjg@chromium.org>
Split out the code which prepares the cedit for use, so we can call it
from a test.
Add a log category while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Before adding more functions to this interface, create a new header for
the configuration editor.
Fix up the expo header guard while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
The caller reads the ID but menu_build() does this again. Add the ID as
a parameter to avoid this. Return the object created so that the caller
can adjust it.
Signed-off-by: Simon Glass <sjg@chromium.org>
For some operations it is necessary to process all objects in an expo.
Provide an iterator to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
As it is only called in bootmeth_efi.c
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Support booting ChromiumOS on ARM devices using FIT. Add an entry into the
boot implementation which does not require a command line. This can be
expanded over time as the bootm code is refactored.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some bootflows (such as EFI and ChromiumOS) delay reading the kernel until
it is needed to boot. This saves time when scanning and avoids needing to
allocate memory for something that may never be used.
To permit reading of these files, add a new 'bootflow read' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the two new functions to separate reading of the ChromiumOS info from
the partition from actually reading the kernel and booting it.
Signed-off-by: Simon Glass <sjg@chromium.org>
The code to read the ChromiumOS information from the partition is
currently all in one function.
Create a new function which reads the kernel, assuming that the metadata
has been parsed.
For now this function is not used. Future work will plumb it in.
Signed-off-by: Simon Glass <sjg@chromium.org>
The code to read the ChromiumOS information from the partition is
currently all in one function. It reads the entire kernel, which is
unnecessary unless it is to be booted.
Create a new function which reads just the minimum required data from the
disk, then obtains what it needs from there.
For now this function is not used. Future work will plumb it in.
Signed-off-by: Simon Glass <sjg@chromium.org>
