u-boot.git/disk, branch v2017.11-rc4

disk: part_dos: fix part_get_info_extended() function

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

The check in part_get_info_extended() for a successful partition
searching misses a condition for extended partition. In case of
(ext_part_sector == 0), we should anyway mark the partition as found,
even if it's an extended partition, i.e. (is_extended(pt->sys_ind) == 0).
Otherwise, the extended partition (type 0x0f) will never be identified,
and the following recursive call to part_get_info_extended() will get a
wrong 'part_num' and 'which_part' parameter.  In the end, all those
partitions in extended table will not be identified.

Let's add the missing OR condition of (ext_part_sector == 0) for
is_extended() check to fix the problem.

The issue is discovered by running fastboot flash to an extended
partition on eMMC.

  $ fastboot flash mmcsda5 cache.img
  target reported max download size of 536870912 bytes
  sending 'mmcsda5' (18796 KB)...
  OKAY [  2.144s]
  writing 'mmcsda5'...
  FAILED (remote: cannot find partition)
  finished. total time: 2.261s

Signed-off-by: Shawn Guo

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

iso: Reduce verbosity on test and info calls

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

The test and info callbacks into the partition callback struct are
used by the "part list" command on the command line. That command
is used by the distro script.

With verb=1 set, "part list" thus throws a lot of warnings about
partitions it can't find when an upper layer searches for partitions.

So let's reduce verbosity to bring it to the same level of noise
as the other partition targets.

Signed-off-by: Alexander Graf

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

disk: Provide API to get partition by name for specific type

2017-10-06T15:28:17+00:00

There is already existing function part_get_info_by_name().
But sometimes user is particularly interested in looking for only
specific partition type. This patch implements such an API that
provides partition searching by name for specified partition type.

Signed-off-by: Sam Protsenko 
Reviewed-by: Simon Glass

disk: part_dos: Use the original allocation scheme for the SPL case

2017-10-05T14:45:33+00:00

Since commit ff98cb90514d ("part: extract MBR signature from partitions")
SPL boot on i.MX6 starts to fail:

U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
Trying to boot from MMC1
(keep in loop)

Use the original allocation scheme for the SPL case, so that MX6 boards
can boot again.

This is a temporary solution to avoid the boot regression.

Signed-off-by: Fabio Estevam 
Acked-by: Rob Clark 
Tested-by: Peter Robinson

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

EFI: find EFI system partition by legacy MBR partition type

2017-09-18T21:53:56+00:00

The UEFI spec allows an EFI system partition (ESP, with the bootloader or
kernel EFI apps on it) to reside on a disk using a "legacy" MBR
partitioning scheme.
But in contrast to actual legacy disks the ESP is not marked as
"bootable" using bit 7 in byte 0 of the legacy partition entry, but is
instead using partition *type* 0xef (in contrast to 0x0b or 0x0c for a
normal FAT partition). The EFI spec isn't 100% clear on this, but it even
seems to discourage the use of the bootable flag for ESPs.
Also it seems that some EFI implementations (EDK2?) even seem to ignore
partitions marked as bootable (probably since they believe they contain
legacy boot code).
The Debian installer [1] (*not* mini.iso), for instance, contains such an
MBR, where none of the two partitions are marked bootable, but the ESP
has clearly type 0xef.
Now U-Boot cannot find the ESP on such a disk (USB flash drive) and
fails to load the EFI grub and thus the installer.

Since it all boils down to the distro bootcmds eventually calling
"part list -bootable" to find potential boot partitions, it seems logical
to just add this "partition type is 0xef" condition to the is_bootable()
implementation.

This allows the bog standard arm64 Debian-testing installer to boot from
an USB pen drive on Allwinner A64 boards (Pine64, BananaPi-M64).
(Ubuntu and other distribution installers don't have a legacy MBR, so
U-Boot falls back to El Torito there).

[1] https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/
Signed-off-by: Andre Przywara 
Reviewed-by: Alexander Graf 
Signed-off-by: Alexander Graf