Hi Maxime, On Wed, Jan 31, 2018 at 7:36 PM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > Hi Julian, > > On Wed, Jan 31, 2018 at 07:29:13PM +1100, Julian Calaby wrote: >> Hi Maxime, >> >> On Wed, Jan 31, 2018 at 7:21 PM, Maxime Ripard >> <maxime.rip...@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: > > It's not really stupid :)
Well it is, because I completely missed the UEFI case =) >> 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? > > The thing is, we're not using the DT for the SPL, and the DT size > we're discussing about is the one in the main U-Boot binary. > >> I'm guessing that the SPL wants to patch the DT we pass to Linux, >> would we be able to handle that using overlays? > > In a "standard" setup (or at least the one you described), U-Boot will > patch, or apply the overlay to, the DT provided by Linux, not its own, > so even if we prevent the overlay usage on U-Boot's own, the only > downside would be that the UEFI case Andre was describing would not > work with overlays anymore. So essentially I'm proposing a fix for a problem that doesn't exist. I'll leave it at this. Thanks for replying, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
