Simon Glass authored 4 years ago and Tom Rini committed 4 years ago

Move this out of the common header and include it only where needed.  In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly.   Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

Gary Bisson authored 4 years ago and Heinrich Schuchardt committed 4 years ago

Fixes fastboot issues when switching from mbr to gpt partition tables.

Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Rasmus Villemoes authored 4 years ago and Tom Rini committed 4 years ago

There's no reason to require an appropriately sized output parameter
for the string, that's error-prone should the table ever grow an
element with a longer string. We can just return the const char*
pointer directly.

Update the only caller accordingly, and get rid of pointless ifdeffery
in the header so that the compiler always sees a declaration and can
thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled
or not.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

Heinrich Schuchardt authored 4 years ago and Tom Rini committed 4 years ago

512 * 2^32 bytes equals 2 tebibytes.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

Simon Glass authored 4 years ago and Tom Rini committed 4 years ago

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

Simon Glass authored 4 years ago and Tom Rini committed 4 years ago

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

Simon Glass authored 4 years ago and Tom Rini committed 4 years ago

We should not be using typedefs and these make it harder to use
forward declarations (to reduce header file inclusions). Drop the typedef.

Signed-off-by: Simon Glass <sjg@chromium.org>

Simon Glass authored 4 years ago and Tom Rini committed 4 years ago

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

Simon Glass authored 4 years ago and Tom Rini committed 4 years ago

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

Up to now for MBR and GPT partitions the info field 'bootable' was set to 1
if either the partition was an EFI system partition or the bootable flag
was set.

Turn info field 'bootable' into a bit mask with separate bits for bootable
and EFI system partition.

This will allow us to identify the EFI system partition in the UEFI
sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Simon Glass authored 5 years ago and Tom Rini committed 5 years ago

Drop inclusion of crc.h in common.h and use the correct header directly
instead.

With this we can drop the conflicting definition in fw_env.h and rely on
the crc.h header, which is already included.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

Urja Rannikko authored 5 years ago and Kever Yang committed 5 years ago

Some ChromeOS devices (atleast veyron speedy) have the first 8MiB of
the eMMC write protected and equipped with a dummy 'IGNOREME' GPT
header - instead of spewing error messages about it, just silently
try the backup GPT.

Note: this does not touch the gpt cmd writing/verifying functions,
those will still complain.

Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Urja Rannikko authored 5 years ago and Kever Yang committed 5 years ago

There were 3 copies of the same sequence, make it into a function.

Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

When building with GCC 9.1 an error occurs:

disk/part_efi.c: In function ‘gpt_verify_partitions’:
disk/part_efi.c:737:49: error: taking address of packed member of
‘struct _gpt_entry’ may result in an unaligned pointer value
[-Werror=address-of-packed-member]
  737 |   gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name,
      |                                         ~~~~~~~~^~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1
make: *** [Makefile:1594: disk] Error 2

Adjust gpt_convert_efi_name_to_char() to accept unaligned strings.

Reported-by: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

In part_get_info_efi() we use the output of print_efiname() to set
info->name[]. The size of info->name is PART_NAME_LEN = 32 but
print_efiname() returns a string with a maximum length of
PARTNAME_SZ + 1 = 37.

Use snprintf() instead of sprintf() to avoid buffer overflow.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Eugeniu Rosca authored 5 years ago and Heinrich Schuchardt committed 5 years ago

Below is what happens on R-Car H3ULCB-KF using clean U-Boot
v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig:

 => ### interrupt autoboot
 => gpt verify mmc 1
 No partition list provided - only basic check
 Verify GPT: success!
 => ### keep calling 'gpt verify mmc 1'
 => ### on 58th call, we are out of memory:
 => gpt verify mmc 1
 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
 GPT: Failed to allocate memory for PTE
 gpt_verify_headers: *** ERROR: Invalid Backup GPT ***
 Verify GPT: error!

This is caused by calling is_gpt_valid() twice (hence allocating pte
also twice via alloc_read_gpt_entries()) while freeing pte only _once_
in the caller of gpt_verify_headers(). Fix that by freeing the pte
allocated and populated for primary GPT _before_ allocating and
populating the pte for backup GPT. The latter will be freed by the
caller of gpt_verify_headers().

With the fix applied, the reproduction scenario [1-2] has been run
hundreds of times in a loop w/o running into OOM.

[1] gpt verify mmc 1
[2] gpt verify mmc 1 $partitions

Fixes: cef68bf9 ("gpt: part: Definition and declaration of GPT verification functions")
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Eugeniu Rosca authored 5 years ago and Heinrich Schuchardt committed 5 years ago

Below is what happens on R-Car H3ULCB-KF using clean U-Boot
v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig:

 => ### interrupt autoboot
 => gpt guid mmc 1
 21200400-0804-0146-9dcc-a8c51255994f
 success!
 => ### keep calling 'gpt guid mmc 1'
 => ### on 59th call, we are out of memory:
 => gpt guid mmc 1
 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
 GPT: Failed to allocate memory for PTE
 get_disk_guid: *** ERROR: Invalid GPT ***
 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
 GPT: Failed to allocate memory for PTE
 get_disk_guid: *** ERROR: Invalid Backup GPT ***
 error!

After some inspection, it looks like get_disk_guid(), added via v2017.09
commit 73d6d18b ("GPT: add accessor function for disk GUID"),
unlike other callers of is_gpt_valid(), doesn't free the memory pointed
out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid()
via alloc_read_gpt_entries().

With the fix applied, the reproduction scenario has been run hundreds
of times ('while true; do gpt guid mmc 1; done') w/o running into OOM.

Fixes: 73d6d18b ("GPT: add accessor function for disk GUID")
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Heinrich Schuchardt authored 6 years ago and Tom Rini committed 6 years ago

Make system_guid const.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

The current name conflicts with the Chrome OS verified boot library, which
prevents it being built. That library uses a string whereas U-Boot uses a
64-bit hex value. Rename this in U-Boot.

Signed-off-by: Simon Glass <sjg@chromium.org>

Masahiro Yamada authored 6 years ago and Tom Rini committed 6 years ago

In int-ll64.h, we always use the following typedefs:

  typedef unsigned int         u32;
  typedef unsigned long        uintptr_t;
  typedef unsigned long long   u64;

This does not need to match to the compiler's <inttypes.h>.
Do not include it.

The use of PRI* makes the code super-ugly.  You can simply use
"l" for printing uintptr_t, "ll" for u64, and no modifier for u32.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

When building with -pedantic the current definition of EFI_GUID() causes
an error 'initializer element is not constant'.

Currently EFI_GUID() is used both as an anonymous constant and as an
intializer. A conversion to efi_guid_t is not allowable when using
EFI_GUID() as an initializer. But it is needed when using it as an
anonymous constant.

We should not use EFI_GUID() for anything but an initializer. So let's
introduce a variable where needed and remove the conversion.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

Sam Protsenko authored 6 years ago and Tom Rini committed 6 years ago

In commit e163a931 ("cmd: gpt: backup boot code before writing MBR")
there was added the procedure for storing old boot code when doing "gpt
write". But instead of storing just backup code, the whole MBR was
stored, and only specific fields were replaced further, keeping
everything else intact. That's obviously not what we want.

Fix the code to actually store only old boot code and zero out
everything else. This fixes next testing case:

    => mmc write $loadaddr 0x0 0x7b
    => gpt write mmc 1 $partitions

In case when $loadaddr address and further memory contains 0xff, the
board was bricked (ROM-code probably didn't like partition entries that
were clobbered with 0xff). With this patch applied, commands above don't
brick the board.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Cc: Alejandro Hernandez <ajhernandez@ti.com>
Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com>

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>

Adam Ford authored 7 years ago and Tom Rini committed 7 years ago

config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE
based on a list of enabled options.  Moving HAVE_BLOCK_DEVICE to
Kconfig allows us to drastically shrink the logic in
config_fallbacks.h

Signed-off-by: Adam Ford <aford173@gmail.com>
[trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE]
Signed-off-by: Tom Rini <trini@konsulko.com>

Patrick Delaunay authored 7 years ago and Tom Rini committed 7 years ago

use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation
in stack to fix alloc issue in is_gpt_valid()

this patch fix also issue for GPT partition handling
with blocksize != 512 in set_protective_mbr()

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

Lukasz Majewski authored 7 years ago and Tom Rini committed 7 years ago

Before this patch one could receive following errors when executing
"gpt write" command on machine with cache enabled:

display5 factory > gpt write mmc ${mmcdev} ${partitions}
Writing GPT:
CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0]
CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8]
CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8]
CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0]
success!

To alleviate this problem - the calloc()s have been replaced with
malloc_cache_aligned() and memset().

After those changes the buffers are properly aligned (with both start
address and size) to SoC cache line.

Signed-off-by: Lukasz Majewski <lukma@denx.de>

Patrick Delaunay authored 7 years ago and Tom Rini committed 7 years ago

the partition starting at 0x4400 is refused with overlap error:
  $> gpt write mmc 0 "name=test,start=0x4400,size=0"
  Writing GPT: Partition overlap
  error!

even if the 0x4400 is the first available offset for LBA35 with default
value:
- MBR=LBA1
- GPT header=LBA2
- PTE= 32 LBAs (128 entry), 3 to 34

And the command to have one partition for all the disk failed also :
  $> gpt write mmc 0 "name=test,size=0"

After the patch :

  $> gpt write mmc 0 "name=test,size=0"
  Writing GPT: success!
  $> part list mmc 0

  Partition Map for MMC device 0  --   Partition Type: EFI

  Part	Start LBA	End LBA		Name
	Attributes
	Type GUID
	Partition GUID
  1	0x00000022	0x01ce9fde	"test"
	attrs:	0x0000000000000000
	type:	ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
	type:	data
	guid:	b4b84b8a-04e3-4000-0036-aff5c9c495b1

And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected

Reviewed-by: Łukasz Majewski <lukma@denx.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

While this goes somewhat against normal coding style we should ensure
that dev_desc is not NULL before we dereference it in allocation of
legacy_mbr.

Reported-by: Coverity (CID: 167292)
Signed-off-by: Tom Rini <trini@konsulko.com>

Masahiro Yamada authored 7 years ago and Tom Rini committed 7 years ago

U-Boot widely uses error() as a bit noisier variant of printf().

This macro causes name conflict with the following line in
include/linux/compiler-gcc.h:

  # define __compiletime_error(message) __attribute__((error(message)))

This prevents us from using __compiletime_error(), and makes it
difficult to fully sync BUILD_BUG macros with Linux.  (Notice
Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().)

Let's convert error() into now treewide-available pr_err().

Done with the help of Coccinelle, excluing tools/ directory.

The semantic patch I used is as follows:

// <smpl>
@@@@
-error
+pr_err
 (...)
// </smpl>

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: Re-run Coccinelle]
Signed-off-by: Tom Rini <trini@konsulko.com>

EFI client programs need the signature information from the partition
table to determine the disk a partition is on, so we need to fill that
in here.

Signed-off-by: Peter Jones <pjones@redhat.com>
[separated from efi_loader part, and fixed build-errors for non-
 CONFIG_EFI_PARTITION case]
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>

Maxime Ripard authored 7 years ago and Tom Rini committed 7 years ago

The current code checks that no partitions overlap with the GPT partition
table using the offset of the first LBA usable for that partition.

This works fine, unless you have a partition entry that is further away
than it usually is and you want to create partitions in the gap between the
GPT header and the GPT partition entries, for example to reflash a
bootloader that needs to be set there.

Rework the test to something a bit smarter that checks whether a partition
would overlap with either the GPT header or the partition entries, no
matter where it is on the disk.

Partitions that do not have a start LBA specified will still start at the
first LBA usable set in the GPT header, to avoid weird behaviours.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Maxime Ripard authored 7 years ago and Tom Rini committed 7 years ago

The gpt_fill_pte will need to access the device block size. Let's pass the
device descriptor as an argument.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Maxime Ripard authored 7 years ago and Tom Rini committed 7 years ago

The start variable is only used inside a loop, and is never affected inside
it, so it's a purely local variable.

In the same way the partition size is accessed several times, so we can
store it in a variable.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Maxime Ripard authored 7 years ago and Tom Rini committed 7 years ago

Both the config option and the DT options specify the offset to set the GPT
at in bytes, yet the code treats those values as block numbers.

Fix that.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

Alison Chaiken authored 7 years ago and Tom Rini committed 7 years ago

In order to read the GPT, modify the partition name strings, and then
write out a new GPT, the disk GUID is needed.  While there is an
existing accessor for the partition UUIDs, there is none yet for the
disk GUID.

Changes since v6: none.

Signed-off-by: Alison Chaiken <alison@peloton-tech.com>

Alison Chaiken authored 7 years ago and Tom Rini committed 7 years ago

Changes since v6: none.

Signed-off-by: Alison Chaiken <alison@peloton-tech.com>

Philipp Tomsich authored 8 years ago and Tom Rini committed 7 years ago

Some architectures require their SPL loader at a fixed address within
the first 16KB of the disk. To avoid an overlap with the partition
entries of the EFI partition table, the first safe offset (in bytes,
from the start of the device) for the entries can be set through
CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig)

When formatting a device with an EFI partition table, we may need to
leave a gap between the GPT header (always in LBA 1) and the partition
entries. The GPT header already contains a field to specify the
on-disk location, which has so far always been set to LBA 2. With this
change, a configurable offset will be translated into a LBA address
indicating where to put the entries.

Now also allows an override via device-tree using a config-node (see
doc/device-tree-bindings/config.txt for documentation).

Tested (exporting an internal MMC formatted with this) against Linux,
MacOS X and Windows.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: __maybe_unused on config_offset to avoid warning]
Signed-off-by: Tom Rini <trini@konsulko.com>

Vincent Tinelli authored 8 years ago and Tom Rini committed 8 years ago

Change GPT UUID string format from UUID to GUID per specification.

Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Vincent Tinelli authored 8 years ago and Tom Rini committed 8 years ago

On some cases the first 440 bytes of MBR are used to keep an additional
information for ROM boot loader. 'gpt write' command doesn't preserve
that area and makes boot code gone.

Preserve boot code area when run 'gpt write' command.

Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com>
Signed-off-by: Brennan Ashton <brn@deako.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Patrick Delaunay authored 8 years ago and Tom Rini committed 8 years ago

We convert CONFIG_PARTITION_UUIDS to Kconfig first.  But in order to cleanly
update all of the config files we must also update CMD_PART and CMD_GPT to also
be in Kconfig in order to avoid complex logic elsewhere to update all of the
config files.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>