Re: [PATCH 0/4] sunxi: TOC0 image type support
> > I'd like to see one of the parties that had noted the licensing problem > > chime in and explain it again. > > The short of it is the openssl license has an advertising clause, and > the GPL requires no additional terms may be added when distributing > binaries. This is *fine* when distributing source code only, but once a > project such as Debian or some commercial entitry distributes binaries > of u-boot, the license incompatibility is triggered... With OpenSSL 3, which is due shortly, the project will be moving to the Apache 2 license. > A more detailed explanation of the issue: > > https://people.gnome.org/~markmc/openssl-and-the-gpl.html > > > That said, Debian has recently and somewhat quietly decided to declare > openssl as a "system library" which in some opinions works around the > issue. I believe Fedora has used this workaround for quite a while > too. I personally think this is a very weak workaround and have only > reluctantly added openssl support in parts of Debian's u-boot packages, > and sometimes wonder if I shouldn't revert those changes... Fedora has always had OpenSSL as a system library but there's been certain things that can't link against it because of incompatible licenses. > > If someone has the ability, time, resources, etc. to (optionally?) > switch u-boot to using a library that doesn't have any potential license > compatibility issues, that would be ideal, so ideal! But of course, it > requires *someone* to do the *work*. I don't believe *I* have the > requisite skills. It might be too soon to requiring something as new as openssl 3 but it may also end up being the quickest way as openssl3 is parallel installable with older versions. > Another route would be to audit all the current codepaths using openssl > and get permission from all involved copyright holders to add a license > exception expressly permitting linking against openssl. In the past, > this was seen as something between impossible or implausible, due to the > sheer number of potential copyright holders which would need to give > permission to effectively relicense their GPL contributions with this > exception. Maybe the actual affected code paths would limit the number > of people involved enough to make it worth it... maybe not. Again, a > fair amount of work that *someone* would need to do just to even audit > the feasibility of this approach. > > > It is somewhat interesting to explore not adding *new* code to u-boot > that uses openssl by using a different library, and then the old code > might be able to be gradually migrated over to a different library? Last > I did a cursory look, nettle, gnutls and gcrypt seemed the most > promising candidates. I believe libressl has the same licensing issues > as openssl. > > > live well, > vagrant
Re: [PATCH 0/4] sunxi: TOC0 image type support
On 2021-08-22, Tom Rini wrote: > On Sat, Aug 21, 2021 at 09:19:56PM -0500, Samuel Holland wrote: >> On 6/21/21 6:56 PM, Andre Przywara wrote: >> > On Mon, 21 Jun 2021 16:35:37 -0400 >> > Tom Rini wrote: >> >> On Mon, Jun 21, 2021 at 04:43:00PM +0100, Andre Przywara wrote: >> >>> On Sun, 20 Jun 2021 21:55:51 -0500 >> >>> Samuel Holland wrote: >> >>> >> >>> (CC:ing Tom and Simon for the compatibility problem below) >> >>> >> >>> Hi, >> >>> >> This series adds support for the TOC0 image format used by the Allwinner >> secure boot ROM (SBROM). This series has been tested on the following >> SoCs/boards, with the eFuse burnt to enable secure mode: >> - A64: Pine A64 Plus >> - H5: Orange Pi Zero Plus >> - H6: Pine H64 Model B >> - H616: Orange Pi Zero 2 >> >>> >> >>> many thanks for sending this. In general this looks good (will do a >> >>> more thorough review soon), just one thing that bothered me: >> >>> >> >>> This requires OpenSLL 1.1.x. There is nothing really wrong about this, >> >>> but my (admittedly not the freshest) Slackware, but also long term >> >>> distros like RHEL/CentOS (<=7), still come with 1.0.x (headers) only. >> >>> >> >>> I was wondering how important this is? I have the impression that >> >>> embedded developers sometimes use old^Wstable systems, so some people >> >>> might be bitten by it. I think in this case it will affect all user >> >>> trying to build mkimage, regardless of the target platform? >> >>> >> >>> So I wanted to know what to do here? >> >>> - Can we provide some kind of compatibility support? OpenSSL seems >> >>> to provide something: >> >>> https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#Compatibility_Layer >> >>> Haven't tested that fully yet, just downloading that tarball >> >>> does not seem to cut it (or is missing files?). I guess one needs to >> >>> copy some code from the Wiki? >> >>> - Shall we detect missing v1.1.x support (via #if OPENSSL_VERSION_NUMBER >> >>> < 0x1010L) and disable just sunxi_toc0 support in this case? >> >> >> >> There's two things. First, the series should be on top of (sorry!) >> >> https://patchwork.ozlabs.org/project/uboot/patch/20210524202317.1492578-1-mr.nuke...@gmail.com/ >> >> which adds a similar Kconfig option to make building tools easier. >> > >> > So this is on top of Simon's large series? Poor Samuel! Is there a >> > branch somewhere? >> >> Now that all of these have landed, I'm rebasing this series. >> >> >> Second, while I think not supporting openssl 1.0.x is fine, >> > >> > Well, this was not what I was hoping for ;-) >> > I followed the advice on the OpenSSL wiki and now have a rather small >> > compatibility header file, which lets me compile mkimage even against >> > OpenSSL v1.0.2u. It seems like kwbimage.c has similar provisions in >> > place, I guess this could be merged into the external header? >> > Happy to send a patch on top, if this seems useful. >> >> Considering the note from the OpenSSL website: >> >> > Note: The latest stable version is the 1.1.1 series. This is also >> > our Long Term Support (LTS) version, supported until 11th September >> > 2023. All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) >> > are now out of support and should not be used. Users of these older >> > versions are encouraged to upgrade to 1.1.1 as soon as possible. >> and the fact that that I don't have access a system with an old OpenSSL, >> I'm not too interested in spending much effort on it. I will, though, >> happily test a patch if you do send one. > > Since this series came up we now also have: > https://patchwork.ozlabs.org/project/uboot/patch/20210729183121.3798261-1-mr.nuke...@gmail.com/ > > So I would rather not see more old openssl compatibility code added. > >> >> I would like >> >> to again ask for someone to spend the time looking at switching to one >> >> of the GPL-compatible libraries as I'm pretty sure it's been raised a >> >> few times that we can't link with openssl like we do. >> > >> > Why is that? Because Apache is not compatible with GPLv2? The OpenSSL >> > webpage says that: >> > "Can I use OpenSSL with GPL software? >> > On many systems including the major Linux and BSD distributions, yes >> > (the GPL does not place restrictions on using libraries that are part >> > of the normal operating system distribution)." >> > And for mkimage we just build a regular userspace tool, which is linked >> > against the system installed OpenSSL library. From my understanding >> > this is what this quote above means with being permitted? >> > >> > And what would be the alternatives? Take one of the smaller ones and >> > embed them into the code? >> > Otherwise we would probably need to pick something that is widely >> > available and shipped with distros, I guess? Like GnuTLS, >> > libgcrypt, nettle? Maybe LibreSSL? >> > >> > Samuel, do you have an insight what would be a good fit? >> >> My original code was written against
Re: [PATCH 0/4] sunxi: TOC0 image type support
On Sat, Aug 21, 2021 at 09:19:56PM -0500, Samuel Holland wrote: > > Hi Andre, > > On 6/21/21 6:56 PM, Andre Przywara wrote: > > On Mon, 21 Jun 2021 16:35:37 -0400 > > Tom Rini wrote: > >> On Mon, Jun 21, 2021 at 04:43:00PM +0100, Andre Przywara wrote: > >>> On Sun, 20 Jun 2021 21:55:51 -0500 > >>> Samuel Holland wrote: > >>> > >>> (CC:ing Tom and Simon for the compatibility problem below) > >>> > >>> Hi, > >>> > This series adds support for the TOC0 image format used by the Allwinner > secure boot ROM (SBROM). This series has been tested on the following > SoCs/boards, with the eFuse burnt to enable secure mode: > - A64: Pine A64 Plus > - H5: Orange Pi Zero Plus > - H6: Pine H64 Model B > - H616: Orange Pi Zero 2 > >>> > >>> many thanks for sending this. In general this looks good (will do a > >>> more thorough review soon), just one thing that bothered me: > >>> > >>> This requires OpenSLL 1.1.x. There is nothing really wrong about this, > >>> but my (admittedly not the freshest) Slackware, but also long term > >>> distros like RHEL/CentOS (<=7), still come with 1.0.x (headers) only. > >>> > >>> I was wondering how important this is? I have the impression that > >>> embedded developers sometimes use old^Wstable systems, so some people > >>> might be bitten by it. I think in this case it will affect all user > >>> trying to build mkimage, regardless of the target platform? > >>> > >>> So I wanted to know what to do here? > >>> - Can we provide some kind of compatibility support? OpenSSL seems > >>> to provide something: > >>> https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#Compatibility_Layer > >>> Haven't tested that fully yet, just downloading that tarball > >>> does not seem to cut it (or is missing files?). I guess one needs to > >>> copy some code from the Wiki? > >>> - Shall we detect missing v1.1.x support (via #if OPENSSL_VERSION_NUMBER > >>> < 0x1010L) and disable just sunxi_toc0 support in this case? > >> > >> There's two things. First, the series should be on top of (sorry!) > >> https://patchwork.ozlabs.org/project/uboot/patch/20210524202317.1492578-1-mr.nuke...@gmail.com/ > >> which adds a similar Kconfig option to make building tools easier. > > > > So this is on top of Simon's large series? Poor Samuel! Is there a > > branch somewhere? > > Now that all of these have landed, I'm rebasing this series. > > >> Second, while I think not supporting openssl 1.0.x is fine, > > > > Well, this was not what I was hoping for ;-) > > I followed the advice on the OpenSSL wiki and now have a rather small > > compatibility header file, which lets me compile mkimage even against > > OpenSSL v1.0.2u. It seems like kwbimage.c has similar provisions in > > place, I guess this could be merged into the external header? > > Happy to send a patch on top, if this seems useful. > > Considering the note from the OpenSSL website: > > > Note: The latest stable version is the 1.1.1 series. This is also > > our Long Term Support (LTS) version, supported until 11th September > > 2023. All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) > > are now out of support and should not be used. Users of these older > > versions are encouraged to upgrade to 1.1.1 as soon as possible. > and the fact that that I don't have access a system with an old OpenSSL, > I'm not too interested in spending much effort on it. I will, though, > happily test a patch if you do send one. Since this series came up we now also have: https://patchwork.ozlabs.org/project/uboot/patch/20210729183121.3798261-1-mr.nuke...@gmail.com/ So I would rather not see more old openssl compatibility code added. > >> I would like > >> to again ask for someone to spend the time looking at switching to one > >> of the GPL-compatible libraries as I'm pretty sure it's been raised a > >> few times that we can't link with openssl like we do. > > > > Why is that? Because Apache is not compatible with GPLv2? The OpenSSL > > webpage says that: > > "Can I use OpenSSL with GPL software? > > On many systems including the major Linux and BSD distributions, yes > > (the GPL does not place restrictions on using libraries that are part > > of the normal operating system distribution)." > > And for mkimage we just build a regular userspace tool, which is linked > > against the system installed OpenSSL library. From my understanding > > this is what this quote above means with being permitted? > > > > And what would be the alternatives? Take one of the smaller ones and > > embed them into the code? > > Otherwise we would probably need to pick something that is widely > > available and shipped with distros, I guess? Like GnuTLS, > > libgcrypt, nettle? Maybe LibreSSL? > > > > Samuel, do you have an insight what would be a good fit? > > My original code was written against nettle. I switched to OpenSSL > because that was already integrated into U-Boot (oops!), and to use the > ASN.1
Re: [PATCH 0/4] sunxi: TOC0 image type support
Hi Andre, On 6/21/21 6:56 PM, Andre Przywara wrote: > On Mon, 21 Jun 2021 16:35:37 -0400 > Tom Rini wrote: >> On Mon, Jun 21, 2021 at 04:43:00PM +0100, Andre Przywara wrote: >>> On Sun, 20 Jun 2021 21:55:51 -0500 >>> Samuel Holland wrote: >>> >>> (CC:ing Tom and Simon for the compatibility problem below) >>> >>> Hi, >>> This series adds support for the TOC0 image format used by the Allwinner secure boot ROM (SBROM). This series has been tested on the following SoCs/boards, with the eFuse burnt to enable secure mode: - A64: Pine A64 Plus - H5: Orange Pi Zero Plus - H6: Pine H64 Model B - H616: Orange Pi Zero 2 >>> >>> many thanks for sending this. In general this looks good (will do a >>> more thorough review soon), just one thing that bothered me: >>> >>> This requires OpenSLL 1.1.x. There is nothing really wrong about this, >>> but my (admittedly not the freshest) Slackware, but also long term >>> distros like RHEL/CentOS (<=7), still come with 1.0.x (headers) only. >>> >>> I was wondering how important this is? I have the impression that >>> embedded developers sometimes use old^Wstable systems, so some people >>> might be bitten by it. I think in this case it will affect all user >>> trying to build mkimage, regardless of the target platform? >>> >>> So I wanted to know what to do here? >>> - Can we provide some kind of compatibility support? OpenSSL seems >>> to provide something: >>> https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#Compatibility_Layer >>> Haven't tested that fully yet, just downloading that tarball >>> does not seem to cut it (or is missing files?). I guess one needs to >>> copy some code from the Wiki? >>> - Shall we detect missing v1.1.x support (via #if OPENSSL_VERSION_NUMBER >>> < 0x1010L) and disable just sunxi_toc0 support in this case? >> >> There's two things. First, the series should be on top of (sorry!) >> https://patchwork.ozlabs.org/project/uboot/patch/20210524202317.1492578-1-mr.nuke...@gmail.com/ >> which adds a similar Kconfig option to make building tools easier. > > So this is on top of Simon's large series? Poor Samuel! Is there a > branch somewhere? Now that all of these have landed, I'm rebasing this series. >> Second, while I think not supporting openssl 1.0.x is fine, > > Well, this was not what I was hoping for ;-) > I followed the advice on the OpenSSL wiki and now have a rather small > compatibility header file, which lets me compile mkimage even against > OpenSSL v1.0.2u. It seems like kwbimage.c has similar provisions in > place, I guess this could be merged into the external header? > Happy to send a patch on top, if this seems useful. Considering the note from the OpenSSL website: > Note: The latest stable version is the 1.1.1 series. This is also > our Long Term Support (LTS) version, supported until 11th September > 2023. All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) > are now out of support and should not be used. Users of these older > versions are encouraged to upgrade to 1.1.1 as soon as possible. and the fact that that I don't have access a system with an old OpenSSL, I'm not too interested in spending much effort on it. I will, though, happily test a patch if you do send one. >> I would like >> to again ask for someone to spend the time looking at switching to one >> of the GPL-compatible libraries as I'm pretty sure it's been raised a >> few times that we can't link with openssl like we do. > > Why is that? Because Apache is not compatible with GPLv2? The OpenSSL > webpage says that: > "Can I use OpenSSL with GPL software? > On many systems including the major Linux and BSD distributions, yes > (the GPL does not place restrictions on using libraries that are part > of the normal operating system distribution)." > And for mkimage we just build a regular userspace tool, which is linked > against the system installed OpenSSL library. From my understanding > this is what this quote above means with being permitted? > > And what would be the alternatives? Take one of the smaller ones and > embed them into the code? > Otherwise we would probably need to pick something that is widely > available and shipped with distros, I guess? Like GnuTLS, > libgcrypt, nettle? Maybe LibreSSL? > > Samuel, do you have an insight what would be a good fit? My original code was written against nettle. I switched to OpenSSL because that was already integrated into U-Boot (oops!), and to use the ASN.1 generation library (which the code no longer uses). So nettle would work well here because all we need is SHA256 and plain RSA. I don't know about the other image types. Regards, Samuel
Re: [PATCH 0/4] sunxi: TOC0 image type support
On Mon, 21 Jun 2021 16:35:37 -0400 Tom Rini wrote: Hi Tom, > On Mon, Jun 21, 2021 at 04:43:00PM +0100, Andre Przywara wrote: > > On Sun, 20 Jun 2021 21:55:51 -0500 > > Samuel Holland wrote: > > > > (CC:ing Tom and Simon for the compatibility problem below) > > > > Hi, > > > > > This series adds support for the TOC0 image format used by the Allwinner > > > secure boot ROM (SBROM). This series has been tested on the following > > > SoCs/boards, with the eFuse burnt to enable secure mode: > > > - A64: Pine A64 Plus > > > - H5: Orange Pi Zero Plus > > > - H6: Pine H64 Model B > > > - H616: Orange Pi Zero 2 > > > > many thanks for sending this. In general this looks good (will do a > > more thorough review soon), just one thing that bothered me: > > > > This requires OpenSLL 1.1.x. There is nothing really wrong about this, > > but my (admittedly not the freshest) Slackware, but also long term > > distros like RHEL/CentOS (<=7), still come with 1.0.x (headers) only. > > > > I was wondering how important this is? I have the impression that > > embedded developers sometimes use old^Wstable systems, so some people > > might be bitten by it. I think in this case it will affect all user > > trying to build mkimage, regardless of the target platform? > > > > So I wanted to know what to do here? > > - Can we provide some kind of compatibility support? OpenSSL seems > > to provide something: > > https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#Compatibility_Layer > > Haven't tested that fully yet, just downloading that tarball > > does not seem to cut it (or is missing files?). I guess one needs to > > copy some code from the Wiki? > > - Shall we detect missing v1.1.x support (via #if OPENSSL_VERSION_NUMBER > > < 0x1010L) and disable just sunxi_toc0 support in this case? > > There's two things. First, the series should be on top of (sorry!) > https://patchwork.ozlabs.org/project/uboot/patch/20210524202317.1492578-1-mr.nuke...@gmail.com/ > which adds a similar Kconfig option to make building tools easier. So this is on top of Simon's large series? Poor Samuel! Is there a branch somewhere? > Second, while I think not supporting openssl 1.0.x is fine, Well, this was not what I was hoping for ;-) I followed the advice on the OpenSSL wiki and now have a rather small compatibility header file, which lets me compile mkimage even against OpenSSL v1.0.2u. It seems like kwbimage.c has similar provisions in place, I guess this could be merged into the external header? Happy to send a patch on top, if this seems useful. > I would like > to again ask for someone to spend the time looking at switching to one > of the GPL-compatible libraries as I'm pretty sure it's been raised a > few times that we can't link with openssl like we do. Why is that? Because Apache is not compatible with GPLv2? The OpenSSL webpage says that: "Can I use OpenSSL with GPL software? On many systems including the major Linux and BSD distributions, yes (the GPL does not place restrictions on using libraries that are part of the normal operating system distribution)." And for mkimage we just build a regular userspace tool, which is linked against the system installed OpenSSL library. From my understanding this is what this quote above means with being permitted? And what would be the alternatives? Take one of the smaller ones and embed them into the code? Otherwise we would probably need to pick something that is widely available and shipped with distros, I guess? Like GnuTLS, libgcrypt, nettle? Maybe LibreSSL? Samuel, do you have an insight what would be a good fit? Tom, do you have some pointer to previous discussions about this? Cheers, Andre > This isn't a > blocker for the series, just an ask for help with a known problem. > Thanks! >
Re: [PATCH 0/4] sunxi: TOC0 image type support
On Mon, Jun 21, 2021 at 04:43:00PM +0100, Andre Przywara wrote: > On Sun, 20 Jun 2021 21:55:51 -0500 > Samuel Holland wrote: > > (CC:ing Tom and Simon for the compatibility problem below) > > Hi, > > > This series adds support for the TOC0 image format used by the Allwinner > > secure boot ROM (SBROM). This series has been tested on the following > > SoCs/boards, with the eFuse burnt to enable secure mode: > > - A64: Pine A64 Plus > > - H5: Orange Pi Zero Plus > > - H6: Pine H64 Model B > > - H616: Orange Pi Zero 2 > > many thanks for sending this. In general this looks good (will do a > more thorough review soon), just one thing that bothered me: > > This requires OpenSLL 1.1.x. There is nothing really wrong about this, > but my (admittedly not the freshest) Slackware, but also long term > distros like RHEL/CentOS (<=7), still come with 1.0.x (headers) only. > > I was wondering how important this is? I have the impression that > embedded developers sometimes use old^Wstable systems, so some people > might be bitten by it. I think in this case it will affect all user > trying to build mkimage, regardless of the target platform? > > So I wanted to know what to do here? > - Can we provide some kind of compatibility support? OpenSSL seems > to provide something: > https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#Compatibility_Layer > Haven't tested that fully yet, just downloading that tarball > does not seem to cut it (or is missing files?). I guess one needs to > copy some code from the Wiki? > - Shall we detect missing v1.1.x support (via #if OPENSSL_VERSION_NUMBER > < 0x1010L) and disable just sunxi_toc0 support in this case? There's two things. First, the series should be on top of (sorry!) https://patchwork.ozlabs.org/project/uboot/patch/20210524202317.1492578-1-mr.nuke...@gmail.com/ which adds a similar Kconfig option to make building tools easier. Second, while I think not supporting openssl 1.0.x is fine, I would like to again ask for someone to spend the time looking at switching to one of the GPL-compatible libraries as I'm pretty sure it's been raised a few times that we can't link with openssl like we do. This isn't a blocker for the series, just an ask for help with a known problem. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/4] sunxi: TOC0 image type support
On Sun, 20 Jun 2021 21:55:51 -0500 Samuel Holland wrote: (CC:ing Tom and Simon for the compatibility problem below) Hi, > This series adds support for the TOC0 image format used by the Allwinner > secure boot ROM (SBROM). This series has been tested on the following > SoCs/boards, with the eFuse burnt to enable secure mode: > - A64: Pine A64 Plus > - H5: Orange Pi Zero Plus > - H6: Pine H64 Model B > - H616: Orange Pi Zero 2 many thanks for sending this. In general this looks good (will do a more thorough review soon), just one thing that bothered me: This requires OpenSLL 1.1.x. There is nothing really wrong about this, but my (admittedly not the freshest) Slackware, but also long term distros like RHEL/CentOS (<=7), still come with 1.0.x (headers) only. I was wondering how important this is? I have the impression that embedded developers sometimes use old^Wstable systems, so some people might be bitten by it. I think in this case it will affect all user trying to build mkimage, regardless of the target platform? So I wanted to know what to do here? - Can we provide some kind of compatibility support? OpenSSL seems to provide something: https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#Compatibility_Layer Haven't tested that fully yet, just downloading that tarball does not seem to cut it (or is missing files?). I guess one needs to copy some code from the Wiki? - Shall we detect missing v1.1.x support (via #if OPENSSL_VERSION_NUMBER < 0x1010L) and disable just sunxi_toc0 support in this case? Grateful for any opinions. Cheers, Andre > > Samuel Holland (4): > tools: Refactor mkimage linking with OpenSSL > tools: mkimage: Add Allwinner TOC0 support > sunxi: Support both SPL image types > sunxi: Support building a SPL as a TOC0 image > > arch/arm/Kconfig | 1 + > arch/arm/include/asm/arch-sunxi/spl.h | 2 - > arch/arm/mach-imx/mxs/Kconfig | 2 + > arch/arm/mach-mvebu/Kconfig | 1 + > arch/arm/mach-sunxi/Kconfig | 2 + > arch/arm/mach-sunxi/board.c | 20 +- > board/sunxi/Kconfig | 24 + > common/Kconfig.boot | 2 + > common/image.c| 1 + > include/image.h | 1 + > include/sunxi_image.h | 205 > scripts/Makefile.spl | 3 +- > scripts/config_whitelist.txt | 1 - > tools/Kconfig | 3 + > tools/Makefile| 23 +- > tools/mxsimage.c | 3 - > tools/sunxi_toc0.c| 710 ++ > 17 files changed, 976 insertions(+), 28 deletions(-) > create mode 100644 board/sunxi/Kconfig > create mode 100644 tools/sunxi_toc0.c >
[PATCH 0/4] sunxi: TOC0 image type support
This series adds support for the TOC0 image format used by the Allwinner secure boot ROM (SBROM). This series has been tested on the following SoCs/boards, with the eFuse burnt to enable secure mode: - A64: Pine A64 Plus - H5: Orange Pi Zero Plus - H6: Pine H64 Model B - H616: Orange Pi Zero 2 Samuel Holland (4): tools: Refactor mkimage linking with OpenSSL tools: mkimage: Add Allwinner TOC0 support sunxi: Support both SPL image types sunxi: Support building a SPL as a TOC0 image arch/arm/Kconfig | 1 + arch/arm/include/asm/arch-sunxi/spl.h | 2 - arch/arm/mach-imx/mxs/Kconfig | 2 + arch/arm/mach-mvebu/Kconfig | 1 + arch/arm/mach-sunxi/Kconfig | 2 + arch/arm/mach-sunxi/board.c | 20 +- board/sunxi/Kconfig | 24 + common/Kconfig.boot | 2 + common/image.c| 1 + include/image.h | 1 + include/sunxi_image.h | 205 scripts/Makefile.spl | 3 +- scripts/config_whitelist.txt | 1 - tools/Kconfig | 3 + tools/Makefile| 23 +- tools/mxsimage.c | 3 - tools/sunxi_toc0.c| 710 ++ 17 files changed, 976 insertions(+), 28 deletions(-) create mode 100644 board/sunxi/Kconfig create mode 100644 tools/sunxi_toc0.c -- 2.31.1
