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

Mon Apr 2 11:39:46 UTC 2018

On 02/04/18 08:40, Jagan Teki wrote:

Hi Jagan,

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

You mean something like:
$ fatload mmc 0 $fdt_addr_r $fdtfile

I think that works already and some distros use it.
But my point is that distros don't need to ship DTs at all. Actually
this is the EFI boot flow: The UEFI firmware provides the DT. Firmware
is device specific anyway, so just bundling up the DT is a no-brainer.
So when using the EFI boot flow there is no canonical way for the OS to
provide a .dtb (leave alone the grub DT hack, which is just that: a hack).
This might not be be a strong argument if you think of Linux, because it
carries all DTs. But for instance I can boot FreeBSD with that method
(mainline Linux DTs in U-Boot) just fine. FreeBSD doesn't have DTs for
ARM64 systems, as no other supported ARM64 platform require them.

And also this allows to boot boards which a particular (distribution
provided!) kernel just didn't support. Sometimes DTs are just not
upstreamed, or miss a certain release. But technically it's just the DT
that is different, and the kernel would run just fine on that board.
Think Pine64-LTS or the Olimex laptop, plus any other boards for which
nobody cared so far. And now run them on the new Ubuntu 18.04 LTS.

> Because this make few
> development struggles for U-Boot project like (few of the comments are

I don't get what's the "struggle" here. We have a canonical DT source:
the Linux kernel. We sync those files over from time to time. U-Boot
should not use its own (conflicting) bindings in the first place anyway.
So fixing this up in U-Boot, if needed, is good in any case, and mostly
not hard to do. For all the nodes that U-Boot doesn't care about at all
(video, audio) it's a no-brainer anyway.

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

What's to maintain? The patches I sent copy all the .dts and .dtsi files
verbatim from Linux. I mentioned the Linux commit in the later
revisions, I think.

> - It becomes more patches for each-and-every sync.

??? What's the problem with that? If you are concerned about churn: We
can have *one* DT update patch for every kernel release, that's about 4
patches a year.
And review-wise this is really easy, as you could rely on the Linux
review, possibly do some testing to see if it breaks something in
U-Boot. If it does, chances are that U-Boot had a bug and would need to
be updated anyway.

> - We can compare the sync with Linux dt and simply apply on U-Boot
> which look not good to project growing.

This sounds like actual work, compared to just copy the .dts files.

> - Increase size(though it 10KB increase) it becomes unnecessary size
> from U-Boot point-of-view

But that's the DT file, not the code size. Yes, it contributes to the
overall image size, but as mentioned before: You need the full blown DT
file anyway.

I see that this is a departure from the strict embedded use case, where
everything gets bundled into one gigantic image for a particular board.
But maintaining those images (per distribution!) for all the boards out
there is just a maintenance nightmare and technically not necessary.

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

Thanks, that would be much appreciated!

>> 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?"

That thread can be very short: Yes, it is. :-D

Cheers,
Andre