Hi Maxime,
On Wed, Jan 31, 2018 at 7:21 PM, Maxime Ripard maxime.ripard@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,