On 02/04/18 08:40, Jagan Teki wrote: Hi Jagan,
> On Thu, Mar 29, 2018 at 2:49 PM, Andre Przywara <andre.przyw...@arm.com> > wrote: >> Hi, >> >> On 29/03/18 09:51, Jagan Teki wrote: >>> Hi Andre, >>> >>> On Wed, Mar 14, 2018 at 7:26 AM, Andre Przywara <andre.przyw...@arm.com> >>> wrote: >>>> A minor update to the v3 version sent earlier this month. >>>> I reworked patch 09 to drop the direct MMC environment for 32-bit Allwinner >>>> boards as well and keep the current MMC offset. >>>> For now I also dropped the two patches changing (back) the MMC regulator. >>>> I still believe they are good to have and keep them as U-Boot specific >>>> .dtsi files in my tree, possibly posting them later again. >>>> >>>> As the previous version, this combines the EMAC DT support update with >>>> an update of the full Linux kernel DTs for all H3, H5 and A64 boards. >>>> >>>> Patch 01 leaves some hint in the README how to avoid the situation >>>> when overrunning U-Boot's image size on 64-bit boards. >>>> The old v2 EMAC DT update series is in patches 02-08, it prepares U-Boot's >>>> EMAC driver for using the new DT binding used in Linux, also updates >>>> the DTs to the new EMAC DT node already. >>>> >>>> Changes to sync the whole of U-Boot's DT files for the H3, H5 and A64 SoCs >>>> to those from Linux are in the following patches. However this first >>>> requires >>>> lifting the space limit we currently have due to the raw MMC environment. >>>> Patch 09 disables that for all sunxi boards, to give us finally some >>>> space. Patches 10 and 11 consequently revert the disabling of features we >>>> saw a few weeks ago to migitate the size problem. >>>> >>>> Patches 12-19 then bring in the Linux DTs, split by SoCs, with the .dtsi >>>> files first, then the board files. >>>> >>>> Merging the H3 and H5 device tree files brings in significant changes, >>>> also to the structure of the .dtsi files. However U-Boot's own DT usage >>>> is pretty limited, so it doesn't matter. >>>> >>>> The huge benefit of syncing the DTs is that we can use U-Boot's DT copy >>>> to directly pass it to the kernel, avoiding to actually load a .dtb file >>>> from somewhere. To allows seamless and automatic UEFI booting, so >>>> distribution installer images should just work (TM). >>>> >>>> As a goodie the final patch brings in the actual SoPine + baseboard DT >>>> files, which we were completely missing so far. >>>> >>>> This is based on sunxi/master (2d53018a0ef2). >>>> >>>> Cheers, >>>> Andre. >>>> >>>> Changelog v3 .. v4: >>>> - remove MMC environment for all Allwinner boards (including 32 bit ones) >>>> - keep MMC environment offset to the old values >>>> - drop DT adjustments to use fixed MMC regulator >>>> >>>> Changelog v2 .. v3: >>>> 01: added, was on the list before >>>> 02: drop redundant H5 line >>>> 03-08: unchanged >>>> 09-20: added >>>> >>>> Changelog v1 .. v2: >>>> 01, 02, 03: unchanged >>>> 04, 05, 06, 07: added >>>> >>>> Andre Przywara (19): >>>> sunxi: README.sunxi64: Add hint about non-debug of ARM Trusted >>>> Firmware >>>> sunxi: gpio: add missing compatible strings >>>> net: sun8i-emac: support new pinctrl DT bindings >>>> net: sun8i-emac: add support for new EMAC DT binding >>>> arm: dts: sunxi: update A64 to new EMAC binding >>>> arm: dts: sunxi: update H3 to new EMAC binding >>>> arm: dts: sunxi: update H5 to new EMAC binding >>>> net: sun8i-emac: remove support for old binding >>>> sunxi: disable direct MMC environment >>>> sunxi: revert disabling of features >>>> Revert "sunxi: Pine64: temporarily remove extra Pine64 non-plus DT" >>>> sunxi: DT: A64: update device tree file for Allwinner A64 SoC >>>> sunxi: DT: A64: update board .dts files from Linux >>>> sunxi: DT: update device tree files for Allwinner H3 and H5 SoCs >>>> sunxi: DT: H5: update board .dts files from Linux >>>> sunxi: DT: H3: update board .dts files from Linux >>>> sunxi: DT: H3: update libre-cc board .dts file >>>> sunxi: DT: H2+: update Opi-zero .dts >>>> sunxi: DT: A64: add proper SoPine baseboard device tree >>> >>> I agree that we have space for now with U-Boot proper since we removed >>> MMC raw, but why we need to Sync all the dts nodes from Linux? >> >> The main reason for me is to allow passing U-Boot's DT to Linux - or any >> other OS, for that matter. This happens already automatically with the >> distro defaults UEFI boot: just put in an UEFI enabled USB pen drive >> (distro installers) and U-Boot will boot from there - without any user >> interaction or special boot script, without the OS providing any DTs. >> >> Conceptually there is only one DT for each board. The fact that U-Boot >> has deviated has no technical reason, it's just not being updated. >> >>> it is costing some space right? >> >> We don't care about this so much anymore. For practical reasons it would >> be good to stay below 984KB (from after the SPL till 1MB, where the >> first partition normally starts). Adding like 10 KB to the image size is >> nothing in there, especially when looking at the benefits - automatic >> boot of any OS. >> >>> becuase >>> - most of the nodes doesn't have proper drivers yet example: clock, >>> reset, spi, axp803 and some include files and etc >>> - Few nodes like mmc1 from bananpi-m64 doesn't need from U-Boot >>> point-of-view >> >> Yes, U-Boot itself does not use those - but it doesn't hurt either. We >> don't need to invent some notion of U-Boot DT. The DT is not an OS >> configuration file, it's a hardware description. >> >>> What I'm trying to say is we should anyway sync to Linux bindings and >>> dts files, but that could be like step-by-step based on the relevant >>> driver support with proper testing this way we can monitor the "Size" >>> instead of adding unneeded(for now) and untested once now struggling >>> to think about size constraints later. >> >> I hope we will never have to deal with hard size constraint for U-Boot >> proper anymore. I would like to judge any increase in size by its >> benefit. And booting random UEFI enabled OSes out of the box is a very >> good rationale for adding 10KB to the image size. >> >> Keep in mind: Eventually you have to load this DT anyway, so effectively >> you will save on the image size, because you avoid duplication. Actually >> the OS does not need to carry all supported DTs, because the only one >> needed is provided by U-Boot. > > If I understood correctly, look like all comments from your side for > syncing full Linux dts have benefit with automatic boot of OS. > > This feature make U-Boot to have full Linux dts inside, Can't we > implement automatic-boot-of-os distro to grab Linux dtb during > commands stage like other distro does? You mean something like: $ fatload mmc 0 $fdt_addr_r $fdtfile I think that works already and some distros use it. But my point is that distros don't need to ship DTs at all. Actually this is the EFI boot flow: The UEFI firmware provides the DT. Firmware is device specific anyway, so just bundling up the DT is a no-brainer. So when using the EFI boot flow there is no canonical way for the OS to provide a .dtb (leave alone the grub DT hack, which is just that: a hack). This might not be be a strong argument if you think of Linux, because it carries all DTs. But for instance I can boot FreeBSD with that method (mainline Linux DTs in U-Boot) just fine. FreeBSD doesn't have DTs for ARM64 systems, as no other supported ARM64 platform require them. And also this allows to boot boards which a particular (distribution provided!) kernel just didn't support. Sometimes DTs are just not upstreamed, or miss a certain release. But technically it's just the DT that is different, and the kernel would run just fine on that board. Think Pine64-LTS or the Olimex laptop, plus any other boards for which nobody cared so far. And now run them on the new Ubuntu 18.04 LTS. > Because this make few > development struggles for U-Boot project like (few of the comments are I don't get what's the "struggle" here. We have a canonical DT source: the Linux kernel. We sync those files over from time to time. U-Boot should not use its own (conflicting) bindings in the first place anyway. So fixing this up in U-Boot, if needed, is good in any case, and mostly not hard to do. For all the nodes that U-Boot doesn't care about at all (video, audio) it's a no-brainer anyway. > repeated from previous mail, but I'm trying to group them all) > - Unnecessary to maintain nodes which are not required for bootloader > and which doesn't have proper dt drivers. What's to maintain? The patches I sent copy all the .dts and .dtsi files verbatim from Linux. I mentioned the Linux commit in the later revisions, I think. > - It becomes more patches for each-and-every sync. ??? What's the problem with that? If you are concerned about churn: We can have *one* DT update patch for every kernel release, that's about 4 patches a year. And review-wise this is really easy, as you could rely on the Linux review, possibly do some testing to see if it breaks something in U-Boot. If it does, chances are that U-Boot had a bug and would need to be updated anyway. > - We can compare the sync with Linux dt and simply apply on U-Boot > which look not good to project growing. This sounds like actual work, compared to just copy the .dts files. > - Increase size(though it 10KB increase) it becomes unnecessary size > from U-Boot point-of-view But that's the DT file, not the code size. Yes, it contributes to the overall image size, but as mentioned before: You need the full blown DT file anyway. I see that this is a departure from the strict embedded use case, where everything gets bundled into one gigantic image for a particular board. But maintaining those images (per distribution!) for all the boards out there is just a maintenance nightmare and technically not necessary. >>> If are fine with this please re-work based on above points and resend >>> the next version otherwise please comment. >> >> I wonder if we could just merge the first few patches now, up until and >> including 11/19. The EMAC DT binding deviation we have at the moment is >> really annoying and those patches do not increase the size. > > Will re-check and apply all OK. Thanks, that would be much appreciated! >> We can have a separate discussion about the rest, if you really like. > > Worth to have thread with subject like "Full DT sync from Linux is required?" That thread can be very short: Yes, it is. :-D Cheers, Andre _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
