Re: [U-Boot] [PATCH 0/3] sunxi: sun8i-emac: Update DT bindings
Hi, On Thu, Feb 01, 2018 at 09:53:22AM +, 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. > > So
Re: [U-Boot] [PATCH 0/3] sunxi: sun8i-emac: Update DT bindings
Hi, On 01/02/18 08:26, Maxime Ripard wrote: > Hi Andre, > > On Wed, Jan 31, 2018 at 01:40:23PM +, Andre Przywara wrote: >>> 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. >> >> Well, what's the point in updating the DT if we then deviate from it >> again? I would rather suggest to postpone the DT update, until we ditch >> the MMC environment. The whole reason I wanted the update is to pass it >> on to Linux, so garbage collection will kill that purpose. > > Not really, the garbage collection I had in mind is: > https://patchwork.kernel.org/patch/3840371/ Ah, OK, sorry. Did miss that. > 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? >> 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 ;-). It's just the Pine64 double .dtb that needs fixing immediately. > 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 ;-) >> - 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
Re: [U-Boot] [PATCH 0/3] sunxi: sun8i-emac: Update DT bindings
Hi Andre, On Wed, Jan 31, 2018 at 01:40:23PM +, Andre Przywara wrote: > > 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. > > Well, what's the point in updating the DT if we then deviate from it > again? I would rather suggest to postpone the DT update, until we ditch > the MMC environment. The whole reason I wanted the update is to pass it > on to Linux, so garbage collection will kill that purpose. Not really, the garbage collection I had in mind is: https://patchwork.kernel.org/patch/3840371/ 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. > 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'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? > - 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. > - 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. > It would just be the _defconfig build which keeps compatibility, for > users who care. We do agree on that :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] sunxi: sun8i-emac: Update DT bindings
Hi, On 31/01/18 08:21, Maxime Ripard wrote: > Hi, > > On Mon, Jan 29, 2018 at 10:38:25AM +, Andre Przywara wrote: >> On 29/01/18 09:58, Maxime Ripard wrote: >>> On Mon, Jan 29, 2018 at 09:44:44AM +, Andre Przywara wrote: On 29/01/18 08:51, Maxime Ripard wrote: > On Mon, Jan 29, 2018 at 01:15:19AM +, 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. Yeah, that's probably true. Looks we are really running out of silver bullets :-( > 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. Well, what's the point in updating the DT if we then deviate from it again? I would rather suggest to postpone the DT update, until we ditch the MMC environment. The whole reason I wanted the update is to pass it on to Linu
Re: [U-Boot] [PATCH 0/3] sunxi: sun8i-emac: Update DT bindings
Hi, On Mon, Jan 29, 2018 at 10:38:25AM +, Andre Przywara wrote: > On 29/01/18 09:58, Maxime Ripard wrote: > > On Mon, Jan 29, 2018 at 09:44:44AM +, Andre Przywara wrote: > >> On 29/01/18 08:51, Maxime Ripard wrote: > >>> On Mon, Jan 29, 2018 at 01:15:19AM +, 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. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] sunxi: sun8i-emac: Update DT bindings
Hi, On 29/01/18 09:58, Maxime Ripard wrote: > On Mon, Jan 29, 2018 at 09:44:44AM +, Andre Przywara wrote: >> Hi, >> >> On 29/01/18 08:51, Maxime Ripard wrote: >>> Hi, >>> >>> On Mon, Jan 29, 2018 at 01:15:19AM +, 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, 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. > 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. 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. Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] sunxi: sun8i-emac: Update DT bindings
On Mon, Jan 29, 2018 at 09:44:44AM +, Andre Przywara wrote: > Hi, > > On 29/01/18 08:51, Maxime Ripard wrote: > > Hi, > > > > On Mon, Jan 29, 2018 at 01:15:19AM +, 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.) 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? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] sunxi: sun8i-emac: Update DT bindings
Hi, On 29/01/18 08:51, Maxime Ripard wrote: > Hi, > > On Mon, Jan 29, 2018 at 01:15:19AM +, 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. 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. Disabling this buys us another 8KB, which would more than offset the DT grow. What do you think? Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] sunxi: sun8i-emac: Update DT bindings
Hi, On Mon, Jan 29, 2018 at 01:15:19AM +, 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? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
