[U-Boot] [linux-sunxi] Re: [PATCH 0/3] sunxi: sun8i-emac: Update DT bindings

Wed Jan 31 08:29:13 UTC 2018

Hi Maxime,

On Wed, Jan 31, 2018 at 7:21 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Hi,
>
> On Mon, Jan 29, 2018 at 10:38:25AM +0000, Andre Przywara wrote:
>> On 29/01/18 09:58, Maxime Ripard wrote:
>> > On Mon, Jan 29, 2018 at 09:44:44AM +0000, Andre Przywara wrote:
>> >> On 29/01/18 08:51, Maxime Ripard wrote:
>> >>> On Mon, Jan 29, 2018 at 01:15:19AM +0000, Andre Przywara wrote:
>> >>>> The existing sun8i-emac driver in U-Boot uses some preliminary bindings,
>> >>>> which matched our own DTs. Now that the Linux kernel got a driver, lets
>> >>>> update our probe code to handle those Linux DTs as well.
>> >>>> The first patch adds the missing compatible strings for the pinctrl drivers,
>> >>>> which is needed for using the sunxi_name_to_gpio() lookup function.
>> >>>> Patch 2/3 updates the pinctrl parser used in the sun8i-emac driver, to cope
>> >>>> with the new, generic Allwinner pinctrl bindings.
>> >>>> The final patch extends the probe routine in the Ethernet driver to deal
>> >>>> with both the old and the new bindings.
>> >>>
>> >>> Thanks for posting this
>> >>>
>> >>>> This series allows to copy in the DTs from the latest kernel. Unfortunately
>> >>>> right now updating the DTs for the H5 and A64 breaks the build, as the
>> >>>> resulting binary (which embeds the DT) gets to large and triggers our new
>> >>>> image size check.
>> >>>
>> >>> Sigh...
>> >>>
>> >>>> As the H5 and H3 share most of the DT, we can't just update the H3
>> >>>> DTs either. Hopefully we find some neat trick to work around that.
>> >>>
>> >>> Is it just because of the DT size, or because there's more code?
>> >>
>> >> My impression the code itself is always growing a tiny bit over the
>> >> weeks, but this time around it's really the DT update.
>> >> The current A64 .dtbs in U-Boot are around 8KB, mainline is at 13KB.
>> >> Similar for the H5: going from 9.5KB to 14.5KB.
>> >>
>> >> Since you did a pretty good job already in identifying the code hogs, I
>> >> couldn't find *easy* mitigations over the weekend.
>> >> One possible fix is to remove the second .dtb in the Pine64 case, for
>> >> which I sent a patch Friday night.
>> >
>> > Since the DT is fed to the C preprocessor, we could also put some
>> > #ifdef 0 around the nodes that are never used by U-Boot (like the
>> > clocks, timer, psci, dma, GIC, RTC, RSB, etc.)
>>
>> Well yes, U-Boot itself actually only requires a *tiny* .dtb (I think
>> /aliases, /chosen, the reg of USB and Ethernet). But to be honest I
>> don't want to go there. First it would be a constant churn to keep this
>> up-to-date,
>
> I'm not too worried about the churn, it would be there only for the
> time until we fully migrate to the FAT environment, so one-two release
> now. And we're not syncing the DT very often these days (now that we
> have support for the EMAC and USB that is all U-Boot cares about).
>
>> but more importantly for proper UEFI boot we just reuse U-Boot's
>> .dtb to pass it on to the kernel. That is actually the purpose of
>> this whole exercise. That already works today (at least for A64),
>> but would benefit from some updates.
>>
>> So I would refrain from tinkering with U-Boot's .dtbs.
>
> That sucks :/
>
>> > This should give us some room.
>> >
>> >> Another thing that stuck out is the sha256 checksum. It's "default y" if
>> >> you have FIT. We need FIT for the SPL loader - but we don't do or need
>> >> the checksum there.
>> >> Some people do FIT loading for the kernel and initrd in U-Boot proper, I
>> >> suppose, but I am not sure how many depend on SHA256 checksums in their
>> >> images.
>> >
>> > I think there was someone (Tom?) that said that it was useful in some
>> > circumstances?
>>
>> Yes, I clearly see that it is *useful*, but I wonder how many people
>> would actually miss it today? We would bring it back once we dumped
>> ENV_IS_IN_MMC, so it's only temporarily.
>
> His words were stronger actually, and he said that we want to keep it.
>
>> I think we can just disable it in some defconfigs, to avoid collateral
>> damage to other boards.
>> If people have a special need, they can always disable the MMC env and
>> enable stuff at their likings, it's just the standard "make
>> .._defconfig; make" process that needs to be fixed with some band-aids
>> for now.
>
> I really don't want to go down the "let's fix each defconfig when we
> find out it broke", this is very likely to be broken with no-one
> noticing.
>
> Is this issue happening when you sync the whole DT, and would it break
> if you just convert the EMAC binding?
>
> Otherwise, we might try to revive the DTC garbage collection of unused
> nodes patches. This would prevent us from using the overlays on such a
> DT, but that doesn't like like an unfair tradeoff.

Stupid question:

As I understand it, the boot process is SPL => Full U-Boot => Linux.

Would it therefore be possible to use a cut-down DT for the SPL (just
the bits it cares about) then use a full one afterwards?

I'm guessing that the SPL wants to patch the DT we pass to Linux,
would we be able to handle that using overlays?

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/