[U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux

Mon Apr 2 11:20:32 UTC 2018

> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de
> X-Spam-Level: 
> X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_BLOCKED,
> 	RCVD_IN_MSPIKE_H2,T_DKIM_INVALID autolearn=unavailable autolearn_force=no
> 	version=3.4.0
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>  d=amarulasolutions.com; s=google;
>  h=mime-version:in-reply-to:references:from:date:message-id:subject:to
>  :cc; bh=YkmnJ4f8gswV/zdKXGgZZi3cOHA/u5TzVeZb8Z/ynV8=;
>  b=Ka9rvIk1fRVYG7dk1LcAKGpptBUy0Lslma6br3u86kHyhqUWX4jrejwIxeyarUX55j
>  b5Eg/WB42EXQy+YevPQExPVg6lotXw/MIW29Mlpfz0jx/rMaggmlQgBysrcrRIhXuF6G
>  jPwbxSSC+5SdpmqITMoZ/SfNw5yvm+bDtF+Ng=
> X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>  d=1e100.net; s=20161025;
>  h=x-gm-message-state:mime-version:in-reply-to:references:from:date
>  :message-id:subject:to:cc;
>  bh=YkmnJ4f8gswV/zdKXGgZZi3cOHA/u5TzVeZb8Z/ynV8=;
>  b=UPnApuQQyEN/WUPFWWQrdu5FftMAfdDazgVyVN2S2iC0pH/axqntMeuqQuw4jh0vYw
>  nrPiq2C782iEL9G6pQFkQvd6TFfDWwOHEFKI2qDFh+jvevI1PqbczszK848UesC0Ffhu
>  1EyJs8EyNo+1INdrF+VoXydce9YGE3+1y/QQZqIzdP8bVQPGOMO35D+COkScUL5XM3db
>  ReT+WTNMJTWFtXn2bitNbmNJ2T+VljWu8Mrfdynko6X/enwxn5PG60fGT+O1CxaQm5Wi
>  rq6LdlzlkpBvHuKnsh4GXg5C0TEkcCbSmGJUCFe2GyreN1GuIdUx5+VL/Ed28o9XXUuz
>  j5Aw==
> X-Gm-Message-State: ALQs6tCUT9TZd8LpHLCq6AdaTP3iaKD4jfo6CI02WEkLZXWz3Dbn7XLI
>  ErHktqFhgHBKqVEkoeQ5pFJtGVHcKPQAV9qFuRSNMQ==
> X-Google-Smtp-Source: AIpwx48S4/pROvhPMN3NiY9jiXuePYKxMegMCj2pjibZUFA9w1Eq9C1Wvb82pWzc5krxAWkki5uYN2yvs3AQprOF/O0=
> X-Received: by 10.107.200.204 with SMTP id y195mr7833975iof.252.1522654806745; 
>  Mon, 02 Apr 2018 00:40:06 -0700 (PDT)
> From: Jagan Teki <jagan at amarulasolutions.com>
> Date: Mon, 2 Apr 2018 13:10:06 +0530
> Cc: Maxime Ripard <maxime.ripard at bootlin.com>,
>         U-Boot-Denx <u-boot at lists.denx.de>,
>         linux-sunxi <linux-sunxi at googlegroups.com>,
>         Jagan Teki <jagan at openedev.com>
> X-Former-Content-Transfer-Encoding: base64
> Sender: "U-Boot" <u-boot-bounces at lists.denx.de>
> X-XS4ALL-DNSBL-Checked: mxdrop304.xs4all.net checked 81.169.180.215 against DNS blacklists
> X-CNFS-Analysis: v=2.3 cv=T56iscCQ c=1 sm=0 tr=0
>  a=ONADgqKa62I6zSSZ3CeWOA==:117 a=ONADgqKa62I6zSSZ3CeWOA==:17
>  a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Kd1tUaAdevIA:10 a=-uNXE31MpBQA:10
>  a=jJxKW8Ag-pUA:10 a=7CQSdrXTAAAA:8 a=YfCOm-DyAAAA:8 a=bhBFqEExS3OXt8833KMA:9
>  a=vhG5JYZ5BD7PDyiA:21 a=QEXdDO2ut3YA:10 a=a-qgeE7W1pNrGK8U0ZQC:22
>  a=zQLMK8awuJ6_Hvp-_9Ux:22
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam-Score: -0.4 () DKIM_SIGNED, RP_MATCHES_RCVD, T_DKIM_INVALID,
> 	T_HEADER_FROM_DIFFERENT_DOMAINS
> X-XS4ALL-Spam: NO
> Envelope-To: mark.kettenis at xs4all.nl
> 
> Hi Andre,
> 
> On Thu, Mar 29, 2018 at 2:49 PM, Andre Przywara <andre.przywara at arm.com> wrote:
> > Hi,
> >
> > On 29/03/18 09:51, Jagan Teki wrote:
> >> Hi Andre,
> >>
> >> On Wed, Mar 14, 2018 at 7:26 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> >>> A minor update to the v3 version sent earlier this month.
> >>> I reworked patch 09 to drop the direct MMC environment for 32-bit Allwinner
> >>> boards as well and keep the current MMC offset.
> >>> For now I also dropped the two patches changing (back) the MMC regulator.
> >>> I still believe they are good to have and keep them as U-Boot specific
> >>> .dtsi files in my tree, possibly posting them later again.
> >>>
> >>> As the previous version, this combines the EMAC DT support update with
> >>> an update of the full Linux kernel DTs for all H3, H5 and A64 boards.
> >>>
> >>> Patch 01 leaves some hint in the README how to avoid the situation
> >>> when overrunning U-Boot's image size on 64-bit boards.
> >>> The old v2 EMAC DT update series is in patches 02-08, it prepares U-Boot's
> >>> EMAC driver for using the new DT binding used in Linux, also updates
> >>> the DTs to the new EMAC DT node already.
> >>>
> >>> Changes to sync the whole of U-Boot's DT files for the H3, H5 and A64 SoCs
> >>> to those from Linux are in the following patches. However this first requires
> >>> lifting the space limit we currently have due to the raw MMC environment.
> >>> Patch 09 disables that for all sunxi boards, to give us finally some
> >>> space. Patches 10 and 11 consequently revert the disabling of features we
> >>> saw a few weeks ago to migitate the size problem.
> >>>
> >>> Patches 12-19 then bring in the Linux DTs, split by SoCs, with the .dtsi
> >>> files first, then the board files.
> >>>
> >>> Merging the H3 and H5 device tree files brings in significant changes,
> >>> also to the structure of the .dtsi files. However U-Boot's own DT usage
> >>> is pretty limited, so it doesn't matter.
> >>>
> >>> The huge benefit of syncing the DTs is that we can use U-Boot's DT copy
> >>> to directly pass it to the kernel, avoiding to actually load a .dtb file
> >>> from somewhere. To allows seamless and automatic UEFI booting, so
> >>> distribution installer images should just work (TM).
> >>>
> >>> As a goodie the final patch brings in the actual SoPine + baseboard DT
> >>> files, which we were completely missing so far.
> >>>
> >>> This is based on sunxi/master (2d53018a0ef2).
> >>>
> >>> Cheers,
> >>> Andre.
> >>>
> >>> Changelog v3 .. v4:
> >>> - remove MMC environment for all Allwinner boards (including 32 bit ones)
> >>> - keep MMC environment offset to the old values
> >>> - drop DT adjustments to use fixed MMC regulator
> >>>
> >>> Changelog v2 .. v3:
> >>> 01: added, was on the list before
> >>> 02: drop redundant H5 line
> >>> 03-08: unchanged
> >>> 09-20: added
> >>>
> >>> Changelog v1 .. v2:
> >>> 01, 02, 03: unchanged
> >>> 04, 05, 06, 07: added
> >>>
> >>> Andre Przywara (19):
> >>>   sunxi: README.sunxi64: Add hint about non-debug of ARM Trusted
> >>>     Firmware
> >>>   sunxi: gpio: add missing compatible strings
> >>>   net: sun8i-emac: support new pinctrl DT bindings
> >>>   net: sun8i-emac: add support for new EMAC DT binding
> >>>   arm: dts: sunxi: update A64 to new EMAC binding
> >>>   arm: dts: sunxi: update H3 to new EMAC binding
> >>>   arm: dts: sunxi: update H5 to new EMAC binding
> >>>   net: sun8i-emac: remove support for old binding
> >>>   sunxi: disable direct MMC environment
> >>>   sunxi: revert disabling of features
> >>>   Revert "sunxi: Pine64: temporarily remove extra Pine64 non-plus DT"
> >>>   sunxi: DT: A64: update device tree file for Allwinner A64 SoC
> >>>   sunxi: DT: A64: update board .dts files from Linux
> >>>   sunxi: DT: update device tree files for Allwinner H3 and H5 SoCs
> >>>   sunxi: DT: H5: update board .dts files from Linux
> >>>   sunxi: DT: H3: update board .dts files from Linux
> >>>   sunxi: DT: H3: update libre-cc board .dts file
> >>>   sunxi: DT: H2+: update Opi-zero .dts
> >>>   sunxi: DT: A64: add proper SoPine baseboard device tree
> >>
> >> I agree that we have space for now with U-Boot proper since we removed
> >> MMC raw, but why we need to Sync all the dts nodes from Linux?
> >
> > The main reason for me is to allow passing U-Boot's DT to Linux - or any
> > other OS, for that matter. This happens already automatically with the
> > distro defaults UEFI boot: just put in an UEFI enabled USB pen drive
> > (distro installers) and U-Boot will boot from there - without any user
> > interaction or special boot script, without the OS providing any DTs.
> >
> > Conceptually there is only one DT for each board. The fact that U-Boot
> > has deviated has no technical reason, it's just not being updated.
> >
> >> it is costing some space right?
> >
> > We don't care about this so much anymore. For practical reasons it would
> > be good to stay below 984KB (from after the SPL till 1MB, where the
> > first partition normally starts). Adding like 10 KB to the image size is
> > nothing in there, especially when looking at the benefits - automatic
> > boot of any OS.
> >
> >> becuase
> >> - most of the nodes doesn't have proper drivers yet example: clock,
> >> reset, spi, axp803 and some include files and etc
> >> - Few nodes like mmc1 from bananpi-m64 doesn't need from U-Boot point-of-view
> >
> > Yes, U-Boot itself does not use those - but it doesn't hurt either. We
> > don't need to invent some notion of U-Boot DT. The DT is not an OS
> > configuration file, it's a hardware description.
> >
> >> What I'm trying to say is we should anyway sync to Linux bindings and
> >> dts files, but that could be like step-by-step based on the relevant
> >> driver support with proper testing this way we can monitor the "Size"
> >> instead of adding unneeded(for now) and untested once now struggling
> >> to think about size constraints later.
> >
> > I hope we will never have to deal with hard size constraint for U-Boot
> > proper anymore. I would like to judge any increase in size by its
> > benefit. And booting random UEFI enabled OSes out of the box is a very
> > good rationale for adding 10KB to the image size.
> >
> > Keep in mind: Eventually you have to load this DT anyway, so effectively
> > you will save on the image size, because you avoid duplication. Actually
> > the OS does not need to carry all supported DTs, because the only one
> > needed is provided by U-Boot.
> 
> If I understood correctly, look like all comments from your side for
> syncing full Linux dts have benefit with automatic boot of OS.
> 
> This feature make U-Boot to have full Linux dts inside, Can't we
> implement automatic-boot-of-os distro to grab Linux dtb during
> commands stage like other distro does? Because this make few
> development struggles for U-Boot project like (few of the comments are
> repeated from previous mail, but I'm trying to group them all)
> - Unnecessary to maintain nodes which are not required for bootloader
> and which doesn't have proper dt drivers.
> - It becomes more patches for each-and-every sync.
> - We can compare the sync with Linux dt and simply apply on U-Boot
> which look not good to project growing.
> - Increase size(though it 10KB increase) it becomes unnecessary size
> from U-Boot point-of-view

This is not just about booting Linux.  And even if it was, it means
that you can only boot on hardware for which a full device tree is
included in your distro.  So a new board that comes with a usable
U-Boot in SPI flash still won't work since the right device tree isn't
there.

So I Agree with Andre, U-Boot should provide the full device tree if
possible.  That doesn't mean it shouldn't try to load a device tree
from the boot media if there is one.  That way users can easily
update/tweak their device tree without re-flashing the complete
firmware.

> >> If are fine with this please re-work based on above points and resend
> >> the next version otherwise please comment.
> >
> > I wonder if we could just merge the first few patches now, up until and
> > including 11/19. The EMAC DT binding deviation we have at the moment is
> > really annoying and those patches do not increase the size.
> 
> Will re-check and apply all OK.
> 
> >
> > We can have a separate discussion about the rest, if you really like.
> 
> Worth to have thread with subject like "Full DT sync from Linux is required?"
> 
> Jagan.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 