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

Thu Mar 9 10:48:12 UTC 2017

On Mon, Mar 06, 2017 at 10:48:15AM -0500, Tom Rini wrote:
> 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.

Yes, and this is definitely something that can be done easily, using
all the common flashing methods already out there.

> 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...

I guess there's a difference between allowing its usage and making it
mandatory.

Anyway, if both of you agree on this, let's enable FIT. But the doc
definitely needs to be updated, and this should be enabled by default
in Kconfig, not duplicated across all the defconfigs.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170309/30395c65/attachment.sig>