adopt dts from Linux kernel

[pdp7]

Current u-boot device tree for BeagleV Starlight JH7100 beta board: https://github.com/starfive-tech/u-boot/blob/Fedora_JH7100_upstream/arch/riscv/dts/starfive_jh7100_beagle_v.dts

@esmil has split this up into a more sensible .dtsi and .dts in the beagelv (which is patches on top of mainline):

• https://github.com/starfive-tech/linux/blob/beaglev/arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts
• https://github.com/starfive-tech/linux/blob/beaglev/arch/riscv/boot/dts/starfive/jh7100.dtsi

In order for dts to go upstream into mainline Linux, it must first be accepted into upstream u-boot. Therefore, I recommend adopting what is in @esmil 5.13 linux branch and then keeping these in sync between the starfive-tech u-boot and linux repos.

[pdp7]

@palmer-dabbelt @atishp04 @avpatel @esmil @geertu @lbmeng @trini I would appreciate any thoughts about best strategy to get device tree for starfive-tech linux and u-boot into sync

[trini]

The dts files in U-Boot are expected to be identical to the Linux kernel ones. They can go in before the files are in linux-next with the understanding that it's on the board maintainer to resync any changes that are needed. The only place for (few!) U-Boot specific things are the -u-boot.dtsi files that get automatically included by our build rules.

[pdp7]

@trini thank you. What do you think of the strategy @esmil used? https://github.com/starfive-tech/linux/blob/esmil_starlight/arch/riscv/boot/dts/starfive/

There is jh7100.dtsi for the SoC and then jh7100-starlight.dts for the BeagleV Starlight board

[trini]

@pdp7 @esmil that's likely fine.

[esmil]

Didn't know u-boot policy was to sync with Linux, but that's cool.

@pdp7 Yeah my original motivation for reorganizing the device tree source was to mould it closer to something that might be accepted upstream eventually. My impression is that the sources are only split when necessary. So usually you'll have a dtsi for the SoC and dts files for the different boards using the SoC. Sometimes different boards will share enough that it makes sense to have a common dtsi in the middle though. In this case I guess technically the split is not necessary since there probably won't be any more boards using jh7100, but for the jh7110 I'm sure there'll be plenty different boards/SoMs using the SoC.

I don't think what we have right now is ready for upstreaming, but with contributions from @geertu, Stephen Arnold and hopefully others I'm sure we'll get there. What I've seen happening is that SoC support, device tree scaffolding (vendor prefix etc.) and the most basic drivers go up first and then a cut-down device tree is submitted that only contain nodes used by those drivers. Later further nodes are added along with matching drivers. I think of the starlight branch mostly as a collection of patches so if anyone wants to reorder or rework commits in there to be closer to something that can be upstreamed I'll gladly replace those commits in the starlight branch.

[palmer-dabbelt]

IMO the right way to go about this is to send the DT bindings upstream so we can get them reviewed, that's where most of the focus is. That's not my tree (it's Rob's), but I'm happy to help where I can.

Taking them into u-boot earlier is fine with me, as long as we're all on the same page about them eventually getting updated to follow the schema that get reviewed and merged.

[geertu]

@pdp7 Yeah my original motivation for reorganizing the device tree source was to mould it closer to something that might be accepted upstream eventually. My impression is that the sources are only split when necessary. So usually you'll have a dtsi for the SoC and dts files for the different boards using the SoC. Sometimes different boards will share enough that it makes sense to have a common dtsi in the middle though. In this case I guess technically the split is not necessary since there probably won't be any more boards using jh7100, but for the jh7110 I'm sure there'll be plenty different boards/SoMs using the SoC.

There may be common parts that can be shared between the BeagleV variants with jh7100 and jh7110.

I don't think what we have right now is ready for upstreaming, but with contributions from @geertu, Stephen Arnold and hopefully others I'm sure we'll get there. What I've seen happening is that SoC support, device tree scaffolding (vendor prefix etc.) and the most basic drivers go up first and then a cut-down device tree is submitted that only contain nodes used by those drivers. Later further nodes are added along with matching drivers. I think of the starlight branch mostly as a collection of patches so if anyone wants to reorder or rework commits in there to be closer to something that can be upstreamed I'll gladly replace those commits in the starlight branch.

Indeed. First we need core SoC (CPU, interrupts, clocks) and UART DT bindings and driver support, followed by a minimal .dtsi and .dts, to allow the user to boot into a serial console. CPU, interrupts, and UART are mostly fine, based on existing support. The major missing core part is the clock controller, which is part of the "PCR (Power/Clock/Reset) Management Unit" block. Currently there's no real driver for it, just a set of fixed-factor clocks in the .dtsi.

[esmil]

There may be common parts that can be shared between the BeagleV variants with jh7100 and jh7110.

Good point.

The major missing core part is the clock controller, which is part of the "PCR (Power/Clock/Reset) Management Unit" block. Currently there's no real driver for it, just a set of fixed-factor clocks in the .dtsi.

I'm curious if you think it's ok to upstream without a pinctrl driver and rely u-boot to set up pinmux for us or that's also a missing core part.

[pdp7]

There may be common parts that can be shared between the BeagleV variants with jh7100 and jh7110.

Good point.

The major missing core part is the clock controller, which is part of the "PCR (Power/Clock/Reset) Management Unit" block. Currently there's no real driver for it, just a set of fixed-factor clocks in the .dtsi.

I'm curious if you think it's ok to upstream without a pinctrl driver and rely u-boot to set up pinmux for us or that's also a missing core part.

Hopefully @palmer-dabbelt can comment but I think this is ok.

In fact, my thinking right now is that the initial Linux patch series would just allow serial console to work and the expectation that the kernel and initramfs are loaded into memory by u-boot. It is going to be a challenge I think to get mmc, gmac or usb working upstream due to the L2 cache flush hacks. Thus, I think the simplest route is to expect the rootfs to be loaded into RAM by the u-boot.

As for gpio and pinctrl, I am working on shaping up the gpio driver for RFC to get initial thoughts from Linus W and Bart, and I plan to also seek Linus W advice on the best way to implement pinctrl. To get that started, I was going to describe in detail how the hardware works as it is a bit complicated in my opinion (or maybe that is my bias coming from the land of pinctrl-single).

thanks, drew

[lbmeng]

@pdp7 Did you get enough documentation to start a kernel driver for pinctrl?

[lbmeng]

Indeed. First we need core SoC (CPU, interrupts, clocks) and UART DT bindings and driver support, followed by a minimal .dtsi and .dts, to allow the user to boot into a serial console.

Yes, this should be the expected way to start the upstream work. Note new DT bindings should be reviewed by kernel upstream, not U-Boot. As Tom said, U-Boot just reuse the kernel DT, plus some additional U-Boot one that kernel does not care.

[pdp7]

@pdp7 Did you get enough documentation to start a kernel driver for pinctrl?

Yes, the funcshare settings are in the jh7100 datasheet. It is a bit weird how FMUX works so I want to get Linus W opinion

[geertu]

I'm curious if you think it's ok to upstream without a pinctrl driver and rely u-boot to set up pinmux for us or that's also a missing core part.

I can't speak for RISC-V, but on ARM, we do that all the time. For initial devices, we rely on reset state or U-Boot setup.

1. Initial DTS has no pinctrl support,
2. More initial devices are added to DTS, without pinctrl support,
3. Pinctrl driver is added in kernel version N,
4. Pinctrl support for initial devices is added to DTS in kernel version N+1,
5. More devices are added to DTS, with pinctrl support.

The important part is to avoid introducing regressions due to adding pinctrl support, hence the kernel version sync point between steps 3 and 4.

[davidlt]

Make sure there is a "reset state" on 7100. For example on FU740 things are random (e.g. PWM) and it's up to U-Boot SPL to put them in some initial state.

[geertu]

@pdp7

In fact, my thinking right now is that the initial Linux patch series would just allow serial console to work

I wrote down the full list of steps, from my experience in upstreaming support for Renesas ARM SoCs:

1. Core CPU support

   • DT bindings
   • Drivers => upstreamed through platform maintainers[1]

2. Core interrupt support

   • DT bindings
   • Drivers => upstreamed through interrupt maintainers[1]

3. Core timer support

   • DT bindings
   • Drivers => upstreamed through timer maintainers[1]

4. Core clock support

   • DT bindings
   • DT binding definitions (e.g. clock indices, if not dictated by hardware)
   • Drivers => upstreamed through clock maintainers[1]

5. Other core support (power, reset, ...)

   • DT bindings
   • DT binding definitions
   • Drivers => upstreamed through subsystem maintainers[1][2]

6. UART support

   • DT bindings
   • Drivers => upstreamed through serial maintainers[1]

7. Initial DTS with serial console support

   • SoC .dtsi
   • Board .dts
   • Initial defconfig => upstreamed through platform maintainers[2]

8. Core GPIO and pin control support (usually related to each other)

   • DT bindings
   • Drivers => upstreamed through GPIO and pin control maintainers[1]

9. More hardware driver support

   • DT bindings
   • Drivers => upstreamed through subsystem maintainers[1]

10. More hardware enablement without pin control support

    • SoC .dtsi
    • Board .dts (excl. pin control properties)
    • Defconfig updates => upstreamed through platform maintainers[2]

11. GPIO and pin control enablement (related due to gpio-ranges)

    • Pin controller and GPIO in .dtsi
    • Pin control properties for existing devices in .dts
    • Defconfig updates => upstreamed through platform maintainers[2]

12. More hardware enablement with pin control support

    • SoC .dtsi
    • Board .dts (incl. pin control properties)
    • Defconfig updates => upstreamed through platform maintainers[2]

Steps 1-9 can mostly be done in parallel, as they go through different maintainers.

Dependencies to take into account:

• DTS depends on accepted DT bindings (in another maintainer's branch) How stringent this is depends on whether this is a completely new binding or a major enhancement, or just a trivial addition to a mature binding.
• DTS and drivers may have a hard dependency on DT binding definitions:
  • Ask driver maintainer for a shared branch for DT binding definitions, OR
  • Use hardcoded numbers in DTS, and replace by symbols in the next kernel version.
• Steps 11 and later have a hard dependency on step 8, i.e. they have to wait for the next kernel version.

[1] DT binding updates may be upstreamed through the DT maintainer instead [2] I think in the long run the plan is to upstream all DTS and SoC support through the soc (formerly arm-soc) maintainers

Perhaps I should put this on the elinux.org wiki?

[pdp7]

Perhaps I should put this on the elinux.org wiki?

@geertu yes, I think that would be helpful!

[tekkamanninja]

I am using linux dtb now, https://github.com/starfive-tech/u-boot/commits/Fedora_JH7100_upstream_devel

[MichaelZhuxx]

Verified and close