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

Prepare v2017.11-rc4

2017-11-06T23:25:37+00:00

Signed-off-by: Tom Rini

cosmetic: rmobile: renesas spelled wrong

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

Renesas was spelled wrong.

Signed-off-by: Chris Brandt

Do not attempt to use the systemwide libfdt

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

U-Boot bundles a patched copy of libfdt, so it's wrong to attempt to
include it . This breaks the build for me when I have dtc
fully installed in my host -- as happened earlier tonight with
Buildroot, for example.

There are several other occurrences throughout the code where ' include style is being used -- IMHO wrongly.

Signed-off-by: Jan Kundrát

m68k: doc: update outdated documentation

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

Update m68k documentation to reflect the current ColdFire
architecture support status.

Signed-off-by: Angelo Dureghello

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

tools: image: fix message when fail to add verification data for config

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

This function is called when signing configuration nodes.  Adjust
the error message.

I do not know why we do not need to show the error message in case of
ENOSPC.  Remove the if-conditional that seems unnecessary.

Signed-off-by: Masahiro Yamada

tools: image: allow to sign image nodes without -K option

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

If -K option is missing when you sign image nodes, it fails with
an unclear error message:

  tools/mkimage Can't add hashes to FIT blob: -1

It is hard to figure out the cause of the failure.

In contrast, when you sign configuration nodes, -K is optional because
fit_config_process_sig() returns successfully if keydest is unset.
Probably this is a preferred behavior when you want to update FIT with
the same key; you do not have to update the public key in this case.

So, this commit changes fit_image_process_sig() to continue signing
without keydest.  If ->add_verify_data() fails, show a clearer error
message, which has been borrowed from fit_config_process_sig().

Signed-off-by: Masahiro Yamada

tools: image: fix "algo" property of public key for verified boot

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

The "algo_name" points to a property in a blob being edited.  The
pointer becomes stale when fit_image_write_sig() inserts signatures.
Then crypto->add_verify_data() writes wrong data to the public key
destination.

Signed-off-by: Masahiro Yamada

test/py: regenerate persistent GPT image if code changes

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

test_gpt generates a persistent disk image which can be re-used across
multiple test runs. Currently, if the Python code that generates the disk
image change, the image is not regenerated, which could cause test
failures e.g. if a test was updated to expect some new partition name or
size, yet the persistent disk image contained the old name or size. This
change introduces functionality to regenerate the disk image if the
instructions to generate the image have changed.

Signed-off-by: Stephen Warren