[U-Boot] [linux-sunxi] Re: [PATCH 14/17] sunxi: Pine64: defconfig: enable SPL FIT support

Tom Rini trini at konsulko.com
Mon Mar 6 15:48:15 UTC 2017


On Mon, Mar 06, 2017 at 03:11:29PM +0000, Andre Przywara wrote:
> Hi,
> 
> On 06/03/17 10:00, Maxime Ripard wrote:
> > On Fri, Mar 03, 2017 at 09:55:25AM +0000, Andre Przywara wrote:
> >> Hi,
> >>
> >> On 03/03/17 09:22, Maxime Ripard wrote:
> >>> On Thu, Mar 02, 2017 at 12:03:20AM +0800, Icenowy Zheng wrote:
> >>>>
> >>>> 2017年3月1日 23:51于 Maxime Ripard <maxime.ripard at free-electrons.com>写道:
> >>>>>
> >>>>> Hi Andre, 
> >>>>>
> >>>>> On Wed, Mar 01, 2017 at 02:25:26AM +0000, Andre Przywara wrote: 
> >>>>>> The Pine64 (and all other 64-bit Allwinner boards) need to load an 
> >>>>>> ARM Trusted Firmware image beside the actual U-Boot proper. 
> >>>>>> This can now be easily achieved by using the just extended SPL FIT 
> >>>>>> loading support, so enable it in the Pine64 defconfig. 
> >>>>>> Also add the FIT image as a build target to 64-bit sunxi board to 
> >>>>>> trigger the respective Makefile rules. 
> >>>>>>
> >>>>>> Signed-off-by: Andre Przywara <andre.przywara at arm.com> 
> >>>>>> --- 
> >>>>>>   configs/pine64_plus_defconfig  | 6 ++++++ 
> >>>>>>   include/configs/sunxi-common.h | 4 ++++ 
> >>>>>>   2 files changed, 10 insertions(+) 
> >>>>>>
> >>>>>> diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig 
> >>>>>> index 7c7d86f..2b47157 100644 
> >>>>>> --- a/configs/pine64_plus_defconfig 
> >>>>>> +++ b/configs/pine64_plus_defconfig 
> >>>>>> @@ -3,9 +3,14 @@ CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y 
> >>>>>>   CONFIG_ARCH_SUNXI=y 
> >>>>>>   CONFIG_MACH_SUN50I=y 
> >>>>>>   CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus" 
> >>>>>> +CONFIG_OF_LIST="sun50i-a64-pine64 sun50i-a64-pine64-plus" 
> >>>>>>   # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set 
> >>>>>>   CONFIG_CONSOLE_MUX=y 
> >>>>>>   CONFIG_SPL=y 
> >>>>>> +CONFIG_FIT=y 
> >>>>>> +CONFIG_SPL_FIT=y 
> >>>>>> +CONFIG_SPL_LOAD_FIT=y 
> >>>>>> +CONFIG_SPL_OF_LIBFDT=y 
> >>>>>
> >>>>> I'm not sure we want to force down that support to all our users. 
> >>>>
> >>>> A64 boards are now unusable without proper ATF.
> >>>
> >>> That's debatable, but that's not really what I meant. What I meant was
> >>> that they're perfectly usable without FIT.
> >>
> >> But this is a defconfig for a certain, and the Pine64 is not really
> >> usable without ATF at the moment in an upstream tree.
> > 
> > Without ATF, yes, but there's no hard dependency between using ATF and
> > FIT. The documentation we have clearly states that, and we had no
> > dependency on FIT before, so there's no reason to *require* it now.
> 
> Sorry, but I still don't get it. Our current options to boot a Pine64
> (and any other A64 board, really) are:
> 1) Use boot0img and a AW provided boot0.bin to build an image using just
> the U-Boot proper (u-boot.bin).
> 2) Use the current SPL and U-Boot proper (in a legacy image file) to
> boot into U-Boot, but missing out on the ATF and thus not being able to
> run Linux.
> 3) Using a FIT image including DTs, U-Boot proper and the ATF to get the
> full glory. This is what this series achieves just after a "make".
> 
> So definitely the ATF depends on the FIT support now, because I consider
> the boot0img method just a (blob-involving) stopgap that is now
> obsolete, and option 2) just being an intermediate step.
> So yes: the documentation is outdated, because I forgot to update
> README.pine64. Shall I send a 18/17 patch now to let people know what
> they should do?
> 
> Am I missing something else here? Or is it indeed the misleading README
> that causes confusion?

I assume, but am not exactly in favor of option 4:
4) dd/objcopy together the various parts of the system (ATF, SPL,
U-Boot) into a binary file that can be written in-place instead.

I fear we're once again starting to verge into the territory where a FIT
image would make a rather nice solution to a given problem (how do we
put N distinct things together in a file for ease of use/etc) but people
see FIT as a "U-Boot thing" and don't want to be tied to that rather
than seeing FIT as just an image format anyone can use.  I'm not sure
what would prevent any other project from dealing with FIT images...

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170306/86b0a5e3/attachment.sig>


More information about the U-Boot mailing list