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

Fri Feb 2 21:42:57 UTC 2018

Hi,

On Thu, Feb 01, 2018 at 09:53:22AM +0000, Andre Przywara wrote:
> > ie, removing only nodes marked as such that are not referenced
> > anywhere in your tree (typically pinctrl nodes). It should totally be
> > usable from Linux, since the usable part of the DT will remain
> > untouched.
> > 
> > As I was saying, the only noticeable "glitch" would be that you don't
> > have nodes in the base DT anymore that used to be there, and overlays
> > won't be able to apply properly if they depended on those nodes.
> > 
> > However, that's not really bad, because:
> >   - U-Boot doesn't build its DT with the overlay support anyway
> >   - Linux in itself is pretty dumb when it comes to applying overlays
> >     at the moment, so there's not a lot of things you can do. The only
> >     user in tree (as far as I'm aware) is the FPGA manager, but it
> >     doesn't really apply to our SoCs.
> 
> Yeah, that makes sense and would be fine for me. However I am not sure
> it will gain us enough to be significant.
> My impression is that the DT growth is mostly due to the AXP803 nodes. A
> lot of them are unreferenced as well, would that be covered by that
> method also?

Only the nodes marked as such can be removed if they are unreferenced,
and unfortunately, while the pinctrl nodes are harmless to remove, the
AXP nodes have a side effect. Indeed, if the regulator node isn't in
the DT anymore, the kernel will not disable it if it's unused. So I'm
not sure it would be a good idea :/

> >> So what about this plan:
> >> - We need to do something *now* about the breakage of the 64-bit sunxi
> >> *_defconfigs, which do not build with origin/master (for me). I tried
> >> GCC 7.1.0, 7.3.0 and 6.4.0, also the actual merge point of the sunxi
> >> branch in addition to origin/master.
> >> The fix I sent (remove the Pine64 "non-plus" .dtb from the FIT image)
> >> was supposed do the trick, but in contrast to my test on Friday doesn't
> >> work (anymore?). bananapi_m64_defconfig for instance fails also (with a
> >> single .dtb).
> > 
> > Yes, we should definitely merge that patch.
> > 
> >> Can someone confirm this? Maybe it's worth to see what made U-Boot
> >> proper grow in the last few days/weeks?
> > 
> > I guess I'm (at least partially) to blame with the introduction of the
> > FAT environment...
> > 
> > How much size do we need?
> 
> I saw it being off by roughly 3KB, unfortunately. But that is my
> particular setup here, I think that differs with compiler versions and
> what not.
> Plus I just realised that ATF is of course also part of the .itb, and
> more or less by accident I had a slightly bigger version pointed to by
> my bl31.bin link (being 5KB bigger than usual).
> So sorry for the noise, with the standard 32K ATF image sunxi64 boards
> with one .dtb build fine. Well, 936 bytes below the limit ;-).

Ok, good. I guess one of the related discussion would be to add the
bl31 binary to our travis-ci build, so that we actually catch those
kind of issues.

> It's just the Pine64 double .dtb that needs fixing immediately.

Ack. Consider it merged.

> > I've looked at the gains we could have with the dtc patch mentionned
> > above if we flag all the PIO nodes, and its roughly around 500-800
> > bytes for an A64 DTS. Would it be enough?
> 
> So not for the issue I reported yesterday, but that seems to be moot now.
> That's why I was originally suggesting SHA256, which gives us 8KB, so
> some room for the inevitable growth here and there, even after the merge
> window. We might keep that in mind for emergency cases ;-)

Yay, two bullets left :)

> >> - Regardless of this we take the patches from this series, so U-Boot
> >> *can* deal with both DTs.
> > 
> > We should merge those patches, but I don't get why we should maintain
> > the compatibility with the old bindings. Yes, I know what you are
> > going to say, but the deal that was made about those bindings when
> > they were introduced was that we would simply update those bindings
> > when Linux would have decided.
> > 
> > And not maintain any kind of compatibility. Apparently, that deal has
> > changed without consulting or notifying anyone. Great.
> > 
> > And since most of that discussion has been around using the U-Boot DT
> > from Linux, I'm not even sure what the pro would be to keep the old
> > binding around.
> 
> You could have saved your breath ;-)
> I am totally fine with removing support for the old binding. And (in
> contrast to Linux!) I would like to consider U-Boot the source of the
> .dtb, so we can do changes.
> And indeed the old bindings were never agreed upon.
> 
> The reason I kept them in is simply to not break bisectability. The
> moment you remove the support, you break the board's boot. This is
> easily fixed with a follow up patch to update the DT, but unless you
> want to squash code and DT changes into one patch, we should keep them,
> at least for some commits.
> This is especially true if we don't know yet when the DT will be updated.
> 
> Solutions I see:
> 1) We keep support for the old bindings in. Once we merged the DT update
> (which could be months away, possibly, due to the size issue), we add a
> patch to remove support for the old bindings.
> 2) We queue those patches, plus update just the nodes affected (EMAC +
> respective pinctrl nodes) to the Linux ones *now*. This should not
> increase the size of the DT. Then we can immediately add a patch to
> remove support for the old binding. So we have this double support in
> for just two commits or so.
> 
> I guess there is not much to say against 2), I am happy to send patches
> for that.

2 definitely works for me

> >> - We wait with any DT updates until we remove the MMC environment
> >> support, so that we have enough space to give U-Boot the proper .dts.
> >>
> >> What is the current plan for the MMC environment? Remove it (or not
> >> enable it by default) in 2018.05?
> > 
> > Not enabling it by default in 2018.05, and removing the migration code
> > later on seems like a good idea yes.
> > 
> >> Having the support for both DT bindings in the EMAC driver *now* would
> >> allow people to build their own firmware, *configuring* out the MMC
> >> environment already and not suffer from any limits anymore.
> > 
> > I understand your frustration, and honestly, it frustrates me even
> > more to see that the hunt of config option and the discussion we had a
> > month ago are already rendered useless, and we need to do it again.
> 
> I know what you mean!
> 
> So quick summary:
> - I update this series to add one patch to update just the EMAC DT node,
> plus one patch to remove support for the old binding.
> - DT sync with Linux is postponed for now until we can afford the size.
> - We queue the Pine64 non-plus .dtb patch, to fix the build for
> pine64_plus_defconfig.
> - We keep an eye on the build size for the next weeks, to spot
> regressions, especially before the 2018.03 release.

Yep

> - We start chilling the champagne for the day MMC env support gets
>   disabled.

It's already in a cool place.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180202/a5a7e5d9/attachment.sig>