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
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot