u-boot.git/disk/part_efi.c, branch v2018.09

efi_loader: avoid initializer element is not constant

2018-06-14T08:52:14+00:00

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 
Signed-off-by: Alexander Graf

disk: efi: Correct backing up the MBR boot code

2018-06-05T14:33:57+00:00

In commit e163a931af34 ("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 
Cc: Alejandro Hernandez 
Tested-by: Andy Shevchenko

SPDX: Convert all of our single license tags to Linux Kernel style

2018-05-07T13:34:12+00:00

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

Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig

2018-02-09T00:09:03+00:00

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 
[trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE]
Signed-off-by: Tom Rini

disk: efi: correct the allocation size for mbr header in stack

2017-11-30T03:30:50+00:00

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

gpt: Use cache aligned buffers for gpt_h and gpt_e

2017-11-06T14:59:01+00:00

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

disk: efi: correct the overlap check on GPT header and PTE

2017-10-23T21:27:48+00:00

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 
Tested-by: Stephen Warren 
Signed-off-by: Patrick Delaunay

part_efi: In is_gpt_valid() check argument validity before allocation

2017-10-16T13:42:51+00:00

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

treewide: replace with error() with pr_err()

2017-10-04T15:59:44+00:00

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:

// 
@@@@
-error
+pr_err
 (...)
// 

Signed-off-by: Masahiro Yamada 
Reviewed-by: Simon Glass 
[trini: Re-run Coccinelle]
Signed-off-by: Tom Rini

part: extract MBR signature from partitions

2017-09-20T08:20:19+00:00

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 
[separated from efi_loader part, and fixed build-errors for non-
 CONFIG_EFI_PARTITION case]
Signed-off-by: Rob Clark 
Signed-off-by: Alexander Graf