| Message ID | 20180314015715.15615-1-andre.przywara@arm.com |
|---|---|
| Headers | show |
| Series | sunxi: sync H3, H5, A64 DTs from mainline Linux | expand |
Hi Andre, On Wed, Mar 14, 2018 at 7:26 AM, Andre Przywara <andre.przywara@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? it is costing some space right? 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 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. If are fine with this please re-work based on above points and resend the next version otherwise please comment. Jagan.
On Thu, Mar 29, 2018 at 02:21:24PM +0530, Jagan Teki wrote: > Hi Andre, > > On Wed, Mar 14, 2018 at 7:26 AM, Andre Przywara <andre.przywara@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? it is > costing some space right? 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 > > 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. Because it's what we've been asking for for years? But apart from that, I'm not sure I'd want to deal with an endless number of patches adding each and every device on each and every board, using each and every SoC. I know I'd better spend time reviewing and merging things that are of importance, compared to what would basically be noise, especially when we can afford it. Maxime
Hi, On 29/03/18 09:51, Jagan Teki wrote: > Hi Andre, > > On Wed, Mar 14, 2018 at 7:26 AM, Andre Przywara <andre.przywara@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 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. We can have a separate discussion about the rest, if you really like. Cheers, Andre.
Hi, Replying to one part of the mail only, since I agree with everything else. On Thu, Mar 29, 2018 at 10:19:22AM +0100, Andre Przywara wrote: > > 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. I really don't have to deal with it ever again as well, and I really think we'll need to pay more attention to whatever we'll be merging that would enable any option. Given the current craze that everyone thinks their new Kconfig option is so awesome that everyone must want it, that's probably going to be a bit hard to achieve, but if we have a patch coming our way that enables something that is already covered by an option we have, we must say no. A pretty good example would be for example in our current case why do we have DFU and fastboot enabled, while both cover pretty much the same usecase. Or why do we have USB gadget mass storage support on by default, while most of the users probably will never use it. Of course, those options are in, so we can't really remove them now, especially without any strong incentive. But we can prevent any uneeded option from creeping in in the future. Maxime
Hi Andre, On Thu, Mar 29, 2018 at 2:49 PM, Andre Przywara <andre.przywara@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.przywara@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? Because this make few development struggles for U-Boot project like (few of the comments are 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. - It becomes more patches for each-and-every sync. - We can compare the sync with Linux dt and simply apply on U-Boot which look not good to project growing. - Increase size(though it 10KB increase) it becomes unnecessary size from U-Boot point-of-view >> 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. > > 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?" Jagan.
> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de > X-Spam-Level: > X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_BLOCKED, > RCVD_IN_MSPIKE_H2,T_DKIM_INVALID autolearn=unavailable autolearn_force=no > version=3.4.0 > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=amarulasolutions.com; s=google; > h=mime-version:in-reply-to:references:from:date:message-id:subject:to > :cc; bh=YkmnJ4f8gswV/zdKXGgZZi3cOHA/u5TzVeZb8Z/ynV8=; > b=Ka9rvIk1fRVYG7dk1LcAKGpptBUy0Lslma6br3u86kHyhqUWX4jrejwIxeyarUX55j > b5Eg/WB42EXQy+YevPQExPVg6lotXw/MIW29Mlpfz0jx/rMaggmlQgBysrcrRIhXuF6G > jPwbxSSC+5SdpmqITMoZ/SfNw5yvm+bDtF+Ng= > X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=1e100.net; s=20161025; > h=x-gm-message-state:mime-version:in-reply-to:references:from:date > :message-id:subject:to:cc; > bh=YkmnJ4f8gswV/zdKXGgZZi3cOHA/u5TzVeZb8Z/ynV8=; > b=UPnApuQQyEN/WUPFWWQrdu5FftMAfdDazgVyVN2S2iC0pH/axqntMeuqQuw4jh0vYw > nrPiq2C782iEL9G6pQFkQvd6TFfDWwOHEFKI2qDFh+jvevI1PqbczszK848UesC0Ffhu > 1EyJs8EyNo+1INdrF+VoXydce9YGE3+1y/QQZqIzdP8bVQPGOMO35D+COkScUL5XM3db > ReT+WTNMJTWFtXn2bitNbmNJ2T+VljWu8Mrfdynko6X/enwxn5PG60fGT+O1CxaQm5Wi > rq6LdlzlkpBvHuKnsh4GXg5C0TEkcCbSmGJUCFe2GyreN1GuIdUx5+VL/Ed28o9XXUuz > j5Aw== > X-Gm-Message-State: ALQs6tCUT9TZd8LpHLCq6AdaTP3iaKD4jfo6CI02WEkLZXWz3Dbn7XLI > ErHktqFhgHBKqVEkoeQ5pFJtGVHcKPQAV9qFuRSNMQ== > X-Google-Smtp-Source: AIpwx48S4/pROvhPMN3NiY9jiXuePYKxMegMCj2pjibZUFA9w1Eq9C1Wvb82pWzc5krxAWkki5uYN2yvs3AQprOF/O0= > X-Received: by 10.107.200.204 with SMTP id y195mr7833975iof.252.1522654806745; > Mon, 02 Apr 2018 00:40:06 -0700 (PDT) > From: Jagan Teki <jagan@amarulasolutions.com> > Date: Mon, 2 Apr 2018 13:10:06 +0530 > Cc: Maxime Ripard <maxime.ripard@bootlin.com>, > U-Boot-Denx <u-boot@lists.denx.de>, > linux-sunxi <linux-sunxi@googlegroups.com>, > Jagan Teki <jagan@openedev.com> > X-Former-Content-Transfer-Encoding: base64 > Sender: "U-Boot" <u-boot-bounces@lists.denx.de> > X-XS4ALL-DNSBL-Checked: mxdrop304.xs4all.net checked 81.169.180.215 against DNS blacklists > X-CNFS-Analysis: v=2.3 cv=T56iscCQ c=1 sm=0 tr=0 > a=ONADgqKa62I6zSSZ3CeWOA==:117 a=ONADgqKa62I6zSSZ3CeWOA==:17 > a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Kd1tUaAdevIA:10 a=-uNXE31MpBQA:10 > a=jJxKW8Ag-pUA:10 a=7CQSdrXTAAAA:8 a=YfCOm-DyAAAA:8 a=bhBFqEExS3OXt8833KMA:9 > a=vhG5JYZ5BD7PDyiA:21 a=QEXdDO2ut3YA:10 a=a-qgeE7W1pNrGK8U0ZQC:22 > a=zQLMK8awuJ6_Hvp-_9Ux:22 > X-Virus-Scanned: by XS4ALL Virus Scanner > X-XS4ALL-Spam-Score: -0.4 () DKIM_SIGNED, RP_MATCHES_RCVD, T_DKIM_INVALID, > T_HEADER_FROM_DIFFERENT_DOMAINS > X-XS4ALL-Spam: NO > Envelope-To: mark.kettenis@xs4all.nl > > Hi Andre, > > On Thu, Mar 29, 2018 at 2:49 PM, Andre Przywara <andre.przywara@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.przywara@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? Because this make few > development struggles for U-Boot project like (few of the comments are > 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. > - It becomes more patches for each-and-every sync. > - We can compare the sync with Linux dt and simply apply on U-Boot > which look not good to project growing. > - Increase size(though it 10KB increase) it becomes unnecessary size > from U-Boot point-of-view This is not just about booting Linux. And even if it was, it means that you can only boot on hardware for which a full device tree is included in your distro. So a new board that comes with a usable U-Boot in SPI flash still won't work since the right device tree isn't there. So I Agree with Andre, U-Boot should provide the full device tree if possible. That doesn't mean it shouldn't try to load a device tree from the boot media if there is one. That way users can easily update/tweak their device tree without re-flashing the complete firmware. > >> 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. > > > > > 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?" > > Jagan. > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot >
On 02/04/18 08:40, Jagan Teki wrote: Hi Jagan, > On Thu, Mar 29, 2018 at 2:49 PM, Andre Przywara <andre.przywara@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.przywara@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
On 02/04/18 12:20, Mark Kettenis wrote: .... >> 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? Because this make few >> development struggles for U-Boot project like (few of the comments are >> 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. >> - It becomes more patches for each-and-every sync. >> - We can compare the sync with Linux dt and simply apply on U-Boot >> which look not good to project growing. >> - Increase size(though it 10KB increase) it becomes unnecessary size >> from U-Boot point-of-view > > This is not just about booting Linux. And even if it was, it means > that you can only boot on hardware for which a full device tree is > included in your distro. So a new board that comes with a usable > U-Boot in SPI flash still won't work since the right device tree isn't > there. Ah right, I didn't even mention SPI flash in that thread. Thanks! Out of curiosity: what OS are you thinking about? Collecting trophies here ;-) I tried the FreeBSD-current installer the other day, and it worked pretty well. > So I Agree with Andre, U-Boot should provide the full device tree if > possible. That doesn't mean it shouldn't try to load a device tree > from the boot media if there is one. That way users can easily > update/tweak their device tree without re-flashing the complete > firmware. Yes, users should still be able to provide their own DT, if needed. Actually that's what I often do for Linux development myself. Thanks! Andre.
> From: =?UTF-8?Q?Andr=c3=a9_Przywara?= <andre.przywara@arm.com> > Date: Mon, 2 Apr 2018 12:51:50 +0100 > > On 02/04/18 12:20, Mark Kettenis wrote: > > .... > > >> 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? Because this make few > >> development struggles for U-Boot project like (few of the comments are > >> 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. > >> - It becomes more patches for each-and-every sync. > >> - We can compare the sync with Linux dt and simply apply on U-Boot > >> which look not good to project growing. > >> - Increase size(though it 10KB increase) it becomes unnecessary size > >> from U-Boot point-of-view > > > > This is not just about booting Linux. And even if it was, it means > > that you can only boot on hardware for which a full device tree is > > included in your distro. So a new board that comes with a usable > > U-Boot in SPI flash still won't work since the right device tree isn't > > there. > > Ah right, I didn't even mention SPI flash in that thread. Thanks! > > Out of curiosity: what OS are you thinking about? Collecting trophies > here ;-) I tried the FreeBSD-current installer the other day, and it > worked pretty well. OpenBSD. ARMv8-wise, our support for Allwinner A64/H5 and Rockchip RK3399 is pretty decent these days and Rockchip RK3328 is coming along as well. And I'm working on Marvell 8040 support. There is support for ARMv7 as well which includes many of the older Allwinner SoCs. We don't have the resources to build images for all the different boards that are out there though, which probably is the biggest stumbling block for getting OpenBSD to run. Our bootloader is UEFI, so with a recent enough U-Boot in flash the default install.fs image should just work. It does on Rock64! Otherwise you have to know the magic to write the U-Boot image at the right location into that image to make it boot. Cheers, Mark
On 02/04/18 13:47, Mark Kettenis wrote: Hi, >> From: =?UTF-8?Q?Andr=c3=a9_Przywara?= <andre.przywara@arm.com> >> Date: Mon, 2 Apr 2018 12:51:50 +0100 >> >> On 02/04/18 12:20, Mark Kettenis wrote: >> >> .... >> >>>> 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? Because this make few >>>> development struggles for U-Boot project like (few of the comments are >>>> 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. >>>> - It becomes more patches for each-and-every sync. >>>> - We can compare the sync with Linux dt and simply apply on U-Boot >>>> which look not good to project growing. >>>> - Increase size(though it 10KB increase) it becomes unnecessary size >>>> from U-Boot point-of-view >>> >>> This is not just about booting Linux. And even if it was, it means >>> that you can only boot on hardware for which a full device tree is >>> included in your distro. So a new board that comes with a usable >>> U-Boot in SPI flash still won't work since the right device tree isn't >>> there. >> >> Ah right, I didn't even mention SPI flash in that thread. Thanks! >> >> Out of curiosity: what OS are you thinking about? Collecting trophies >> here ;-) I tried the FreeBSD-current installer the other day, and it >> worked pretty well. > > OpenBSD. ARMv8-wise, our support for Allwinner A64/H5 and Rockchip > RK3399 is pretty decent these days and Rockchip RK3328 is coming along > as well. Ah, great! I didn't know that OpenBSD was that far. Do you know of anything missing in the DT or UEFI support from mainline U-Boot? I put firmware images on my Pine64 github repo[1] for A64 and H5 boards, which are based on 2018.03 plus this series, if you want to give it a try. Trying to wrap my around INSTALL.arm64, but you might be faster ;-) Does 6.2 provide enough to work? Or shall I wait till the 15th? > And I'm working on Marvell 8040 support. There is support > for ARMv7 as well which includes many of the older Allwinner SoCs. > We don't have the resources to build images for all the different > boards that are out there though, which probably is the biggest > stumbling block for getting OpenBSD to run. Our bootloader is UEFI, That sounds good! > so with a recent enough U-Boot in flash the default install.fs image Is that the FFS filesystem in the OpenBSD partition of miniroot.fs? Which just contains the bsd.rd kernel + RAM fs? The 6.2 directory didn't have an explicit install.fs image. Cheers, Andre [1] https://github.com/apritzel/pine64/tree/master/images > should just work. It does on Rock64! Otherwise you have to know the > magic to write the U-Boot image at the right location into that image > to make it boot. > > Cheers, > > Mark >
> From: =?UTF-8?Q?Andr=c3=a9_Przywara?= <andre.przywara@arm.com> > Date: Mon, 2 Apr 2018 16:14:29 +0100 > > On 02/04/18 13:47, Mark Kettenis wrote: > > Hi, > > >> From: =?UTF-8?Q?Andr=c3=a9_Przywara?= <andre.przywara@arm.com> > >> Date: Mon, 2 Apr 2018 12:51:50 +0100 > >> > >> On 02/04/18 12:20, Mark Kettenis wrote: > >> > >> .... > >> > >>>> 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? Because this make few > >>>> development struggles for U-Boot project like (few of the comments are > >>>> 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. > >>>> - It becomes more patches for each-and-every sync. > >>>> - We can compare the sync with Linux dt and simply apply on U-Boot > >>>> which look not good to project growing. > >>>> - Increase size(though it 10KB increase) it becomes unnecessary size > >>>> from U-Boot point-of-view > >>> > >>> This is not just about booting Linux. And even if it was, it means > >>> that you can only boot on hardware for which a full device tree is > >>> included in your distro. So a new board that comes with a usable > >>> U-Boot in SPI flash still won't work since the right device tree isn't > >>> there. > >> > >> Ah right, I didn't even mention SPI flash in that thread. Thanks! > >> > >> Out of curiosity: what OS are you thinking about? Collecting trophies > >> here ;-) I tried the FreeBSD-current installer the other day, and it > >> worked pretty well. > > > > OpenBSD. ARMv8-wise, our support for Allwinner A64/H5 and Rockchip > > RK3399 is pretty decent these days and Rockchip RK3328 is coming along > > as well. > > Ah, great! I didn't know that OpenBSD was that far. > Do you know of anything missing in the DT or UEFI support from mainline > U-Boot? I put firmware images on my Pine64 github repo[1] for A64 and H5 > boards, which are based on 2018.03 plus this series, if you want to give > it a try. > Trying to wrap my around INSTALL.arm64, but you might be faster ;-) > Does 6.2 provide enough to work? Or shall I wait till the 15th? 6.3 was released today! Defenitely try that instead of 6.2. > > And I'm working on Marvell 8040 support. There is support > > for ARMv7 as well which includes many of the older Allwinner SoCs. > > We don't have the resources to build images for all the different > > boards that are out there though, which probably is the biggest > > stumbling block for getting OpenBSD to run. Our bootloader is UEFI, > > That sounds good! > > > so with a recent enough U-Boot in flash the default install.fs image > > Is that the FFS filesystem in the OpenBSD partition of miniroot.fs? > Which just contains the bsd.rd kernel + RAM fs? > The 6.2 directory didn't have an explicit install.fs image. Hmm, I meant minirootXX.fs (which for 6.3 is called miniroot63.fs). That is a disk image that can be dd'ed directly to the boot media, i.e. a uSD card. It has an MBR partition table, a partition with a FAT filesystem that has the UEFI bootloader (and Raspberry Pi firmware) and a partition with an OpenBSD disklabel and an FFS filesystem that has the bsd.rd kernel that includes the RAM filesystem. You can simply overwrite the Pine64 firmware that is already on there (in the space before the first partition) with your own firmware. My Pine64 board is dead, but I tried your firmware on my Orange Pi PC 2 and it works fine. Mainline U-Boot works fine as well, but it works better if I stick an updated Linux device tree on the FAT filesystem. I believe that with the current U-Boot device tree only one of the USB ports works.
Hi Andre, On Wed, Mar 14, 2018 at 7:26 AM, Andre Przywara <andre.przywara@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" Can you rebase and fix few checkpatch issue on these 11 patches? Jagan.
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 arch/arm/dts/Makefile | 3 +- arch/arm/dts/axp803.dtsi | 150 +++++ arch/arm/dts/sun50i-a64-bananapi-m64.dts | 161 +++++- arch/arm/dts/sun50i-a64-nanopi-a64.dts | 108 +++- arch/arm/dts/sun50i-a64-olinuxino.dts | 131 ++++- arch/arm/dts/sun50i-a64-orangepi-win.dts | 7 +- arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi | 50 -- arch/arm/dts/sun50i-a64-pine64-plus.dts | 17 +- arch/arm/dts/sun50i-a64-pine64.dts | 178 +++++- arch/arm/dts/sun50i-a64-sopine-baseboard.dts | 150 +++++ arch/arm/dts/sun50i-a64-sopine.dtsi | 142 +++++ arch/arm/dts/sun50i-a64.dtsi | 204 ++++++- arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts | 105 +++- arch/arm/dts/sun50i-h5-nanopi-neo2.dts | 89 ++- arch/arm/dts/sun50i-h5-orangepi-pc2.dts | 170 ++++-- arch/arm/dts/sun50i-h5-orangepi-prime.dts | 164 +++++- arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts | 7 +- arch/arm/dts/sun50i-h5.dtsi | 36 +- arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts | 58 +- arch/arm/dts/sun8i-h3-bananapi-m2-plus.dts | 78 ++- arch/arm/dts/sun8i-h3-libretech-all-h3-cc.dts | 15 +- arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts | 71 +++ arch/arm/dts/sun8i-h3-nanopi-m1.dts | 6 + arch/arm/dts/sun8i-h3-nanopi-neo-air.dts | 1 - arch/arm/dts/sun8i-h3-nanopi-neo.dts | 6 +- arch/arm/dts/sun8i-h3-orangepi-2.dts | 67 ++- arch/arm/dts/sun8i-h3-orangepi-lite.dts | 25 +- arch/arm/dts/sun8i-h3-orangepi-one.dts | 72 ++- arch/arm/dts/sun8i-h3-orangepi-pc-plus.dts | 9 +- arch/arm/dts/sun8i-h3-orangepi-pc.dts | 88 ++- arch/arm/dts/sun8i-h3-orangepi-plus.dts | 37 +- arch/arm/dts/sun8i-h3-orangepi-plus2e.dts | 18 +- arch/arm/dts/sun8i-h3.dtsi | 488 ++--------------- arch/arm/dts/sunxi-h3-h5.dtsi | 698 ++++++++++++++++++++++++ board/sunxi/README.sunxi64 | 6 + cmd/Kconfig | 5 - configs/pine64_plus_defconfig | 1 + configs/sopine_baseboard_defconfig | 2 +- drivers/gpio/sunxi_gpio.c | 3 + drivers/net/sun8i_emac.c | 89 ++- drivers/video/Kconfig | 2 - env/Kconfig | 1 - include/dt-bindings/clock/sun8i-r-ccu.h | 59 ++ include/dt-bindings/reset/sun8i-r-ccu.h | 53 ++ lib/Kconfig | 1 - 45 files changed, 2979 insertions(+), 852 deletions(-) create mode 100644 arch/arm/dts/axp803.dtsi delete mode 100644 arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi create mode 100644 arch/arm/dts/sun50i-a64-sopine-baseboard.dts create mode 100644 arch/arm/dts/sun50i-a64-sopine.dtsi create mode 100644 arch/arm/dts/sunxi-h3-h5.dtsi create mode 100644 include/dt-bindings/clock/sun8i-r-ccu.h create mode 100644 include/dt-bindings/reset/sun8i-r-ccu.h