From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Wed, 8 Mar 2017 14:01:23 -0700 Subject: [U-Boot] [PATCH 16/17] sunxi: Store the device tree name in the SPL header In-Reply-To: <1488335129-12363-17-git-send-email-andre.przywara@arm.com> References: <1488335129-12363-1-git-send-email-andre.przywara@arm.com> <1488335129-12363-17-git-send-email-andre.przywara@arm.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Andre, On 28 February 2017 at 19:25, Andre Przywara wrote: > From: Siarhei Siamashka > > 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 > Signed-off-by: Andre Przywara > --- > 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? - Simon