| Message ID | 20241111020808.38974-1-hal.feng@starfivetech.com |
|---|---|
| Headers | show |
| Series | Support OF_UPSTREAM for StarFive JH7110 | expand |
Hi Hal, On Mon, 11 Nov 2024 at 07:53, Hal Feng <hal.feng@starfivetech.com> wrote: > > This patchset add OF_UPSTREAM support for StarFive JH7110 based boards. > All the JH7110 based boards can use the DT from upstreaming linux kernel. > The v1.3b board device tree is set as the default device tree. Support > CONFIG_MULTI_DTB_FIT and the SPL selects the correct U-Boot dtb using the > EEPROM information. > I am encountering an issue with my Milk-V CM. I am unable to use the SD card with the CM4 IO board. The onboard SPI switch does not support a boot configuration switch, so the default boot is set to eMMC. Please suggest a method to flash an image onto the eMMC on the CM board. I have tried the instructions to update the firmware using [1] https://milkv.io/docs/mars/compute-module/boot Thank you so much for your help. Thanks -Anand --------EEPROM INFO-------- Vendor : MILK-V Product full SN: MARC-V10-2340-D004E016-00000812 data version: 0x2 PCB revision: 0xc1 BOM revision: A Ethernet MAC0 address: 6c:cf:39:00:85:6b Ethernet MAC1 address: 6c:cf:39:00:85:6c --------EEPROM INFO-------- starfive_7110_pcie pcie@940000000: Starfive PCIe bus probed. starfive_7110_pcie pcie@9c0000000: Starfive PCIe bus probed. In: serial@10000000 Out: serial@10000000 Err: serial@10000000 Net: Could not fetch index Could not fetch index eqos_probe_resources() failed: -22 Could not fetch index eqos_probe_resources() failed: -22 eth1: ethernet@16040000 starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... Resetting EP 0... 3 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Working FDT set to ff725a10 Hit any key to stop autoboot: 0 StarFive # mmc info Device: mmc@16010000 Manufacturer ID: 15 OEM: 0 Name: AJTD4R Bus Speed: 45333334 Mode: MMC High Speed (52MHz) Rd Block Len: 512 MMC version 5.1 High Capacity: Yes Capacity: 14.6 GiB Bus Width: 8-bit Erase Group Size: 512 KiB HC WP Group Size: 8 MiB User Capacity: 14.6 GiB WRREL Boot Capacity: 4 MiB ENH RPMB Capacity: 4 MiB ENH Boot area 0 is not write protected Boot area 1 is not write protected StarFive # mmc rescan StarFive # mmc rescan StarFive # StarFive # mmc part ## Unknown partition table type 0
Hi Anand, On Wed, Nov 13, 2024 at 8:42 PM Anand Moon <linux.amoon@gmail.com> wrote: > > Hi Hal, > > On Mon, 11 Nov 2024 at 07:53, Hal Feng <hal.feng@starfivetech.com> wrote: > > > > This patchset add OF_UPSTREAM support for StarFive JH7110 based boards. > > All the JH7110 based boards can use the DT from upstreaming linux kernel. > > The v1.3b board device tree is set as the default device tree. Support > > CONFIG_MULTI_DTB_FIT and the SPL selects the correct U-Boot dtb using the > > EEPROM information. > > > > I am encountering an issue with my Milk-V CM. I am unable to use the > SD card with the CM4 IO board. > The onboard SPI switch does not support a boot configuration switch, > so the default boot is set to eMMC. Mars CM and Mars CM Lite are not able to boot from eMMC and SD Card. There is transistor logic on Mars CM and Mars CM Lite which only allows UART or SPI NOR Flash depending on the state of nRPIBOOT. Perhaps you are thinking of SPI NOR Flash boot of JH7110 which is jumping execution to SPI NOR Flash offset 0 where, presumed it is where you have U-Boot SPL? From then U-Boot SPL may load U-Boot Main payload depending on the state of configuration switch, so then UART for UART setting, or SPI NOR Flash at 0x100000 offset for SPI NOR Flash setting. U-Boot Main may then execute as normal including SD Card or eMMC. This is distinct from the concept of JH7110 zeroth boot loader in mask ROM loading from SD Card or eMMC. > > Please suggest a method to flash an image onto the eMMC on the CM board. This will not work with the OF_UPSTREAM patch set of topic (yet) because simply Mars CM and Mars CM Lite devicetree do not exist upstream. You may use U-Boot stable release v2024.10 as a recovery tool to flash U-Boot v2024.10 into SPI NOR Flash which, exclusive of this OF_UPSTREAM patch series, has some runtime fix-up adjusting the Milk-V Mars devicetree for Mars CM or Mars CM Lite depending on EEPROM content. For that to work you will also need to verify and perhaps adjust the EEPROM content of your Mars CM for accuracy per the advisory from Milk-V; from what information you have shared you may have a 4GB RAM model with 16GB eMMC and if that is accurate then no change to the EEPROM content is needed. When you have for example U-Boot v2024.10 installed to SPI NOR Flash and it does have the fix-up at runtime to allow functional eMMC, then you may use any of the methods available to that version of U-Boot: 1. You can load data from TFTP to DRAM address for write operation onto the eMMC directly but you will have to invent some scripting to do the required math between byte counts and block unit offsets. 2. You can load an OS from TFTP to DRAM and boot; for example the Debian debian-installer netinst Linux kernel and initial ramdisk. 3. There is not any working JH7110 on-CPU USB driver in U-Boot v2024.10 so the use of USB (as a reasonable person would attempt) is not possible. Patches exist for this and is something that will be possible in future but not yet. You will note that if your Mars CM is installed to a carrier board that has additionally a VL805 USB controller on the PCI bus then USB may actually work because the VisionFive2 has this same PCI+VL805 for USB. It is not typical though for CM4 carrier boards... but I recall reading that they do exist so worth a mention here. > > I have tried the instructions to update the firmware using > [1] https://milkv.io/docs/mars/compute-module/boot Milk-V USB flash tool at the link loads a closed-source SPL binary via JH7110 UART configuration that postures as a USB endpoint (using the JH7110 on-CPU USB function) and the companion software that talks to it is "compiled" closed-source python. Make your own conclusion... mine is that U-Boot+TFTP is good enough and preferentially it is open source. See: https://docs.u-boot.org/en/v2024.10/board/starfive/milk-v_mars_cm.html https://github.com/geerlingguy/sbc-reviews/issues/22#issuecomment-1908676618 https://milkv.io/docs/mars/compute-module/update-eeprom > > Thank you so much for your help. > > Thanks > -Anand > > --------EEPROM INFO-------- > Vendor : MILK-V > Product full SN: MARC-V10-2340-D004E016-00000812 > data version: 0x2 > PCB revision: 0xc1 > BOM revision: A > Ethernet MAC0 address: 6c:cf:39:00:85:6b > Ethernet MAC1 address: 6c:cf:39:00:85:6c > --------EEPROM INFO-------- > > starfive_7110_pcie pcie@940000000: Starfive PCIe bus probed. > starfive_7110_pcie pcie@9c0000000: Starfive PCIe bus probed. > In: serial@10000000 > Out: serial@10000000 > Err: serial@10000000 > Net: Could not fetch index > Could not fetch index > eqos_probe_resources() failed: -22 > Could not fetch index > eqos_probe_resources() failed: -22 > eth1: ethernet@16040000 > starting USB... > Bus xhci_pci: Register 5000420 NbrPorts 5 > Starting the controller > USB XHCI 1.00 > scanning bus xhci_pci for devices... Resetting EP 0... > 3 USB Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > Working FDT set to ff725a10 > Hit any key to stop autoboot: 0 > StarFive # mmc info > Device: mmc@16010000 > Manufacturer ID: 15 > OEM: 0 > Name: AJTD4R > Bus Speed: 45333334 > Mode: MMC High Speed (52MHz) > Rd Block Len: 512 > MMC version 5.1 > High Capacity: Yes > Capacity: 14.6 GiB > Bus Width: 8-bit > Erase Group Size: 512 KiB > HC WP Group Size: 8 MiB > User Capacity: 14.6 GiB WRREL > Boot Capacity: 4 MiB ENH > RPMB Capacity: 4 MiB ENH > Boot area 0 is not write protected > Boot area 1 is not write protected > StarFive # mmc rescan > StarFive # mmc rescan > StarFive # > StarFive # mmc part > ## Unknown partition table type 0 I will say on-topic that although it is a regression in functionality for U-Boot from the v2024.10 stable release to apply OF_UPSTREAM series, the absence of Mars CM and Mars CM Lite should not be blockers for OF_UPSTREAM patch set. It is time to submit these upstream (to Linux kernel) which is not our problem here, and besides this there are more JH7110 board support devicetree being accepted upstream which are not represented here now. The missing functionality will be restored after this is done. All users who want to have working Mars CM and Mars CM Lite should stay with U-Boot stable version v2024.10, and to focus on contributing with Linux upstream for these boards. -E
Am 14. November 2024 18:37:10 MEZ schrieb E Shattow <lucent@gmail.com>: >Hi Anand, > >On Wed, Nov 13, 2024 at 8:42 PM Anand Moon <linux.amoon@gmail.com> wrote: >> >> Hi Hal, >> >> On Mon, 11 Nov 2024 at 07:53, Hal Feng <hal.feng@starfivetech.com> wrote: >> > >> > This patchset add OF_UPSTREAM support for StarFive JH7110 based boards. >> > All the JH7110 based boards can use the DT from upstreaming linux kernel. >> > The v1.3b board device tree is set as the default device tree. Support >> > CONFIG_MULTI_DTB_FIT and the SPL selects the correct U-Boot dtb using the >> > EEPROM information. >> > >> >> I am encountering an issue with my Milk-V CM. I am unable to use the >> SD card with the CM4 IO board. >> The onboard SPI switch does not support a boot configuration switch, >> so the default boot is set to eMMC. > >Mars CM and Mars CM Lite are not able to boot from eMMC and SD Card. >There is transistor logic on Mars CM and Mars CM Lite which only >allows UART or SPI NOR Flash depending on the state of nRPIBOOT. > >Perhaps you are thinking of SPI NOR Flash boot of JH7110 which is >jumping execution to SPI NOR Flash offset 0 where, presumed it is >where you have U-Boot SPL? > >From then U-Boot SPL may load U-Boot Main payload depending on the >state of configuration switch, so then UART for UART setting, or SPI >NOR Flash at 0x100000 offset for SPI NOR Flash setting. The switch controls from where SPL is loaded by the boot ROM. It is not difficult to let SPL try loading main U-Boot from multiple different sources like SD-card and NVMe should this be desired. Cf. https://docs.u-boot.org/en/latest/usage/spl_boot.html#target-binaries. But that is beyond the scope of this series. Best regards Heinrich > >U-Boot Main may then execute as normal including SD Card or eMMC. This >is distinct from the concept of JH7110 zeroth boot loader in mask ROM >loading from SD Card or eMMC. > >> >> Please suggest a method to flash an image onto the eMMC on the CM board. > >This will not work with the OF_UPSTREAM patch set of topic (yet) >because simply Mars CM and Mars CM Lite devicetree do not exist >upstream. > >You may use U-Boot stable release v2024.10 as a recovery tool to flash >U-Boot v2024.10 into SPI NOR Flash which, exclusive of this >OF_UPSTREAM patch series, has some runtime fix-up adjusting the Milk-V >Mars devicetree for Mars CM or Mars CM Lite depending on EEPROM >content. > >For that to work you will also need to verify and perhaps adjust the >EEPROM content of your Mars CM for accuracy per the advisory from >Milk-V; from what information you have shared you may have a 4GB RAM >model with 16GB eMMC and if that is accurate then no change to the >EEPROM content is needed. > >When you have for example U-Boot v2024.10 installed to SPI NOR Flash >and it does have the fix-up at runtime to allow functional eMMC, then >you may use any of the methods available to that version of U-Boot: > >1. You can load data from TFTP to DRAM address for write operation >onto the eMMC directly but you will have to invent some scripting to >do the required math between byte counts and block unit offsets. >2. You can load an OS from TFTP to DRAM and boot; for example the >Debian debian-installer netinst Linux kernel and initial ramdisk. >3. There is not any working JH7110 on-CPU USB driver in U-Boot >v2024.10 so the use of USB (as a reasonable person would attempt) is >not possible. Patches exist for this and is something that will be >possible in future but not yet. You will note that if your Mars CM is >installed to a carrier board that has additionally a VL805 USB >controller on the PCI bus then USB may actually work because the >VisionFive2 has this same PCI+VL805 for USB. It is not typical though >for CM4 carrier boards... but I recall reading that they do exist so >worth a mention here. > >> >> I have tried the instructions to update the firmware using >> [1] https://milkv.io/docs/mars/compute-module/boot > >Milk-V USB flash tool at the link loads a closed-source SPL binary via >JH7110 UART configuration that postures as a USB endpoint (using the >JH7110 on-CPU USB function) and the companion software that talks to >it is "compiled" closed-source python. Make your own conclusion... >mine is that U-Boot+TFTP is good enough and preferentially it is open >source. > >See: > >https://docs.u-boot.org/en/v2024.10/board/starfive/milk-v_mars_cm.html > >https://github.com/geerlingguy/sbc-reviews/issues/22#issuecomment-1908676618 > >https://milkv.io/docs/mars/compute-module/update-eeprom > >> >> Thank you so much for your help. >> >> Thanks >> -Anand >> >> --------EEPROM INFO-------- >> Vendor : MILK-V >> Product full SN: MARC-V10-2340-D004E016-00000812 >> data version: 0x2 >> PCB revision: 0xc1 >> BOM revision: A >> Ethernet MAC0 address: 6c:cf:39:00:85:6b >> Ethernet MAC1 address: 6c:cf:39:00:85:6c >> --------EEPROM INFO-------- >> >> starfive_7110_pcie pcie@940000000: Starfive PCIe bus probed. >> starfive_7110_pcie pcie@9c0000000: Starfive PCIe bus probed. >> In: serial@10000000 >> Out: serial@10000000 >> Err: serial@10000000 >> Net: Could not fetch index >> Could not fetch index >> eqos_probe_resources() failed: -22 >> Could not fetch index >> eqos_probe_resources() failed: -22 >> eth1: ethernet@16040000 >> starting USB... >> Bus xhci_pci: Register 5000420 NbrPorts 5 >> Starting the controller >> USB XHCI 1.00 >> scanning bus xhci_pci for devices... Resetting EP 0... >> 3 USB Device(s) found >> scanning usb for storage devices... 1 Storage Device(s) found >> Working FDT set to ff725a10 >> Hit any key to stop autoboot: 0 >> StarFive # mmc info >> Device: mmc@16010000 >> Manufacturer ID: 15 >> OEM: 0 >> Name: AJTD4R >> Bus Speed: 45333334 >> Mode: MMC High Speed (52MHz) >> Rd Block Len: 512 >> MMC version 5.1 >> High Capacity: Yes >> Capacity: 14.6 GiB >> Bus Width: 8-bit >> Erase Group Size: 512 KiB >> HC WP Group Size: 8 MiB >> User Capacity: 14.6 GiB WRREL >> Boot Capacity: 4 MiB ENH >> RPMB Capacity: 4 MiB ENH >> Boot area 0 is not write protected >> Boot area 1 is not write protected >> StarFive # mmc rescan >> StarFive # mmc rescan >> StarFive # >> StarFive # mmc part >> ## Unknown partition table type 0 > >I will say on-topic that although it is a regression in functionality >for U-Boot from the v2024.10 stable release to apply OF_UPSTREAM >series, the absence of Mars CM and Mars CM Lite should not be blockers >for OF_UPSTREAM patch set. It is time to submit these upstream (to >Linux kernel) which is not our problem here, and besides this there >are more JH7110 board support devicetree being accepted upstream which >are not represented here now. The missing functionality will be >restored after this is done. > >All users who want to have working Mars CM and Mars CM Lite should >stay with U-Boot stable version v2024.10, and to focus on contributing >with Linux upstream for these boards. > >-E
Hi E Sattow, I realize now that my question was outside the scope of the patches series. Thank you for providing more details. On Thu, 14 Nov 2024 at 23:07, E Shattow <lucent@gmail.com> wrote: > > Hi Anand, > > On Wed, Nov 13, 2024 at 8:42 PM Anand Moon <linux.amoon@gmail.com> wrote: > > > > Hi Hal, > > > > On Mon, 11 Nov 2024 at 07:53, Hal Feng <hal.feng@starfivetech.com> wrote: > > > > > > This patchset add OF_UPSTREAM support for StarFive JH7110 based boards. > > > All the JH7110 based boards can use the DT from upstreaming linux kernel. > > > The v1.3b board device tree is set as the default device tree. Support > > > CONFIG_MULTI_DTB_FIT and the SPL selects the correct U-Boot dtb using the > > > EEPROM information. > > > > > > > I am encountering an issue with my Milk-V CM. I am unable to use the > > SD card with the CM4 IO board. > > The onboard SPI switch does not support a boot configuration switch, > > so the default boot is set to eMMC. > > Mars CM and Mars CM Lite are not able to boot from eMMC and SD Card. > There is transistor logic on Mars CM and Mars CM Lite which only > allows UART or SPI NOR Flash depending on the state of nRPIBOOT. > > Perhaps you are thinking of SPI NOR Flash boot of JH7110 which is > jumping execution to SPI NOR Flash offset 0 where, presumed it is > where you have U-Boot SPL? > > From then U-Boot SPL may load U-Boot Main payload depending on the > state of configuration switch, so then UART for UART setting, or SPI > NOR Flash at 0x100000 offset for SPI NOR Flash setting. > > U-Boot Main may then execute as normal including SD Card or eMMC. This > is distinct from the concept of JH7110 zeroth boot loader in mask ROM > loading from SD Card or eMMC. > > > > > Please suggest a method to flash an image onto the eMMC on the CM board. > > This will not work with the OF_UPSTREAM patch set of topic (yet) > because simply Mars CM and Mars CM Lite devicetree do not exist > upstream. > > You may use U-Boot stable release v2024.10 as a recovery tool to flash > U-Boot v2024.10 into SPI NOR Flash which, exclusive of this > OF_UPSTREAM patch series, has some runtime fix-up adjusting the Milk-V > Mars devicetree for Mars CM or Mars CM Lite depending on EEPROM > content. > > For that to work you will also need to verify and perhaps adjust the > EEPROM content of your Mars CM for accuracy per the advisory from > Milk-V; from what information you have shared you may have a 4GB RAM > model with 16GB eMMC and if that is accurate then no change to the > EEPROM content is needed. > > When you have for example U-Boot v2024.10 installed to SPI NOR Flash > and it does have the fix-up at runtime to allow functional eMMC, then > you may use any of the methods available to that version of U-Boot: > > 1. You can load data from TFTP to DRAM address for write operation > onto the eMMC directly but you will have to invent some scripting to > do the required math between byte counts and block unit offsets. > 2. You can load an OS from TFTP to DRAM and boot; for example the > Debian debian-installer netinst Linux kernel and initial ramdisk. > 3. There is not any working JH7110 on-CPU USB driver in U-Boot > v2024.10 so the use of USB (as a reasonable person would attempt) is > not possible. Patches exist for this and is something that will be > possible in future but not yet. You will note that if your Mars CM is > installed to a carrier board that has additionally a VL805 USB > controller on the PCI bus then USB may actually work because the > VisionFive2 has this same PCI+VL805 for USB. It is not typical though > for CM4 carrier boards... but I recall reading that they do exist so > worth a mention here. > Yes, I need to set up TFTP boot to resolve my issue. Let me give this a try. > > > > I have tried the instructions to update the firmware using > > [1] https://milkv.io/docs/mars/compute-module/boot > > Milk-V USB flash tool at the link loads a closed-source SPL binary via > JH7110 UART configuration that postures as a USB endpoint (using the > JH7110 on-CPU USB function) and the companion software that talks to > it is "compiled" closed-source python. Make your own conclusion... > mine is that U-Boot+TFTP is good enough and preferentially it is open > source. > > See: > > https://docs.u-boot.org/en/v2024.10/board/starfive/milk-v_mars_cm.html > > https://github.com/geerlingguy/sbc-reviews/issues/22#issuecomment-1908676618 Cool, thanks for sharing this link. This blog shares almost all the cases needed to resolve my issue so I will try it. > > https://milkv.io/docs/mars/compute-module/update-eeprom > > > > > Thank you so much for your help. > > > > Thanks > > -Anand > > > > --------EEPROM INFO-------- > > Vendor : MILK-V > > Product full SN: MARC-V10-2340-D004E016-00000812 > > data version: 0x2 > > PCB revision: 0xc1 > > BOM revision: A > > Ethernet MAC0 address: 6c:cf:39:00:85:6b > > Ethernet MAC1 address: 6c:cf:39:00:85:6c > > --------EEPROM INFO-------- > > > > starfive_7110_pcie pcie@940000000: Starfive PCIe bus probed. > > starfive_7110_pcie pcie@9c0000000: Starfive PCIe bus probed. > > In: serial@10000000 > > Out: serial@10000000 > > Err: serial@10000000 > > Net: Could not fetch index > > Could not fetch index > > eqos_probe_resources() failed: -22 > > Could not fetch index > > eqos_probe_resources() failed: -22 > > eth1: ethernet@16040000 > > starting USB... > > Bus xhci_pci: Register 5000420 NbrPorts 5 > > Starting the controller > > USB XHCI 1.00 > > scanning bus xhci_pci for devices... Resetting EP 0... > > 3 USB Device(s) found > > scanning usb for storage devices... 1 Storage Device(s) found > > Working FDT set to ff725a10 > > Hit any key to stop autoboot: 0 > > StarFive # mmc info > > Device: mmc@16010000 > > Manufacturer ID: 15 > > OEM: 0 > > Name: AJTD4R > > Bus Speed: 45333334 > > Mode: MMC High Speed (52MHz) > > Rd Block Len: 512 > > MMC version 5.1 > > High Capacity: Yes > > Capacity: 14.6 GiB > > Bus Width: 8-bit > > Erase Group Size: 512 KiB > > HC WP Group Size: 8 MiB > > User Capacity: 14.6 GiB WRREL > > Boot Capacity: 4 MiB ENH > > RPMB Capacity: 4 MiB ENH > > Boot area 0 is not write protected > > Boot area 1 is not write protected > > StarFive # mmc rescan > > StarFive # mmc rescan > > StarFive # > > StarFive # mmc part > > ## Unknown partition table type 0 > > I will say on-topic that although it is a regression in functionality > for U-Boot from the v2024.10 stable release to apply OF_UPSTREAM > series, the absence of Mars CM and Mars CM Lite should not be blockers > for OF_UPSTREAM patch set. It is time to submit these upstream (to > Linux kernel) which is not our problem here, and besides this there > are more JH7110 board support devicetree being accepted upstream which > are not represented here now. The missing functionality will be > restored after this is done. > Alright, I will now flash v2024.10 to address the issue > All users who want to have working Mars CM and Mars CM Lite should > stay with U-Boot stable version v2024.10, and to focus on contributing > with Linux upstream for these boards. > Go that. > -E Thanks -Anand
This patchset add OF_UPSTREAM support for StarFive JH7110 based boards. All the JH7110 based boards can use the DT from upstreaming linux kernel. The v1.3b board device tree is set as the default device tree. Support CONFIG_MULTI_DTB_FIT and the SPL selects the correct U-Boot dtb using the EEPROM information. Changes since v3: - Add detection for Milk-V Mars CM (lite) boards in patch 13. Changes since v2: - Drop patch 1, because the riscv of_upstream Makefile is created by Conor in commit 239e4705099c. - Drop phy0 rx delay for milkv u-boot dtsi in patch 9. - Add a Fixes tag for patch 13. - In patch 14, the PCB version is only obtained when the product_id is VF7110. Improve the commit messages. Changes since v1: - Drop patch 12. - Modify patch 11 and add three new patches to support CONFIG_MULTI_DTB_FIT. The SPL selects the correct U-Boot dtb using the EEPROM information. History: v3: https://lore.kernel.org/all/20241105034328.56439-1-hal.feng@starfivetech.com/ v2: https://lore.kernel.org/all/20241028015847.42344-1-hal.feng@starfivetech.com/ v1: https://lore.kernel.org/all/20240930155919.111738-1-hal.feng@starfivetech.com/ Hal Feng (13): dts: starfive: Switch to using upstream DT riscv: dts: jh7110: Drop redundant devicetree files dt-bindings: Remove StarFive JH7110 clock and reset definitions riscv: dts: jh7110: Make u-boot device trees adapting to upstream DT clk: starfive: jh7110: Sync clock definitions with upstream dt-bindings pcie: starfive: Make the driver compatible with upstream DT riscv: dts: jh7110: Move common code to the new jh7110-common-u-boot.dtsi riscv: dts: jh7110: Add u-boot device tree for JH7110 based boards board: starfive: spl: Drop the unneeded DT modification code configs: visionfive2: Enable MULTI_DTB_FIT for JH7110 based board DT riscv: dts: jh7110: Support multiple DTBs in a Fit image board: starfive: spl: Fix the wrong use of CONFIG_IS_ENABLED() board: starfive: spl: Support multiple DTBs for JH7110 based boards arch/riscv/cpu/jh7110/Kconfig | 1 + arch/riscv/dts/Makefile | 1 - arch/riscv/dts/jh7110-common-u-boot.dtsi | 204 +++++ arch/riscv/dts/jh7110-milkv-mars-u-boot.dtsi | 10 + .../dts/jh7110-pine64-star64-u-boot.dtsi | 6 + .../jh7110-starfive-visionfive-2-u-boot.dtsi | 117 --- ...10-starfive-visionfive-2-v1.2a-u-boot.dtsi | 6 + ...10-starfive-visionfive-2-v1.3b-u-boot.dtsi | 14 + .../dts/jh7110-starfive-visionfive-2.dts | 11 - .../dts/jh7110-starfive-visionfive-2.dtsi | 380 --------- arch/riscv/dts/jh7110-u-boot.dtsi | 36 +- arch/riscv/dts/jh7110.dtsi | 761 ------------------ board/starfive/visionfive2/spl.c | 391 +-------- configs/starfive_visionfive2_defconfig | 4 +- drivers/clk/starfive/clk-jh7110-pll.c | 6 +- drivers/clk/starfive/clk-jh7110.c | 44 +- drivers/pci/pcie_starfive_jh7110.c | 59 +- .../dt-bindings/clock/starfive,jh7110-crg.h | 258 ------ .../dt-bindings/reset/starfive,jh7110-crg.h | 183 ----- 19 files changed, 366 insertions(+), 2126 deletions(-) create mode 100644 arch/riscv/dts/jh7110-common-u-boot.dtsi create mode 100644 arch/riscv/dts/jh7110-milkv-mars-u-boot.dtsi create mode 100644 arch/riscv/dts/jh7110-pine64-star64-u-boot.dtsi delete mode 100644 arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi create mode 100644 arch/riscv/dts/jh7110-starfive-visionfive-2-v1.2a-u-boot.dtsi create mode 100644 arch/riscv/dts/jh7110-starfive-visionfive-2-v1.3b-u-boot.dtsi delete mode 100644 arch/riscv/dts/jh7110-starfive-visionfive-2.dts delete mode 100644 arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi delete mode 100644 arch/riscv/dts/jh7110.dtsi delete mode 100644 include/dt-bindings/clock/starfive,jh7110-crg.h delete mode 100644 include/dt-bindings/reset/starfive,jh7110-crg.h base-commit: 9c25cd563179cf32cf3b119d5ae78ef8348d0335