[U-Boot] [PATCH 16/17] sunxi: Store the device tree name in the SPL header

[Simon Glass]

Hi Andre,

On 26 March 2017 at 19:18, André Przywara <andre.przywara at arm.com> wrote:
> On 08/03/17 21:01, Simon Glass wrote:
>
> Hi Simon,
>
> many thanks for the review, finally found some time to look at this.
> I have finished the needed rework (including documentation) and will
> post something after some testing and some sleep ;-)
>
>> On 28 February 2017 at 19:25, Andre Przywara <andre.przywara at arm.com> wrote:
>>> From: Siarhei Siamashka <siarhei.siamashka at gmail.com>
>>>
>>> This patch updates the mksunxiboot tool to optionally add
>>> the default device tree name string to the SPL header. This
>>> information can be used by the firmware upgrade tools to
>>> protect users from harming themselves by trying to upgrade
>>> to an incompatible bootloader.
>>>
>>> The primary use case here is a non-removable bootable media
>>> (such as NAND, eMMC or SPI flash), which already may have
>>> a properly working, but a little bit outdated bootloader
>>> installed. For example, the user may download or build a
>>> new U-Boot image for "Cubieboard", and then attemept to
>>> install it on a "Cubieboard2" hardware by mistake as a
>>> replacement for the already existing bootloader. If this
>>> happens, the flash programming tool can identify this
>>> problem and warn the user.
>>>
>>> The size of the SPL header is also increased from 64 bytes
>>> to 96 bytes to provide enough space for the device tree name
>>> string.
>>> [Andre: split patch to remove OF_LIST hash feature]
>>>
>>> Signed-off-by: Siarhei Siamashka <siarhei.siamashka at gmail.com>
>>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>>> ---
>>>  arch/arm/include/asm/arch-sunxi/spl.h | 19 +++++++++++---
>>>  include/configs/sunxi-common.h        |  8 +++---
>>>  scripts/Makefile.spl                  |  3 ++-
>>>  tools/mksunxiboot.c                   | 49 ++++++++++++++++++++++++++++++++---
>>>  4 files changed, 67 insertions(+), 12 deletions(-)
>>
>> Can this code move into mkimage as a new image type? This is what
>> rockchip does. It feels like this tool should be subsumed. If that
>> doesn't work, perhaps binman?
>
> Interesting, I wasn't aware that mkimage can do more than legacy and
> FIT. Indeed that sounds useful, especially as mkimage seems to be
> packaged separately and is available in some distros.
>
> So I hacked something up, but that needs some more love.
> I am tempted to drop (or split) this patch from this series for now,
> since this extension here and the move to mkimage could be treated
> separately from the SPL FIT code.

Yes that's fine, whatever works for you. I like using mkimage since it
is supposed to me the tool we use to make binary files (with binman as
a way of building the whole firmware image).

Regards,
SImon