On Thu, Aug 05, 2021 at 11:09:36AM -0700, Atish Patra wrote:

On Thu, Aug 5, 2021 at 1:13 AM Emil Renner Berthing [off-list ref] wrote:

quoted

On Thu, 5 Aug 2021 at 04:30, Drew Fustini [off-list ref] wrote:

quoted

On Wed, Aug 04, 2021 at 02:13:47PM -0700, Palmer Dabbelt wrote:

quoted

On Wed, 04 Aug 2021 13:54:16 PDT (-0700), atishp@atishpatra.org wrote:

quoted

On Wed, Aug 4, 2021 at 1:33 PM Palmer Dabbelt [off-list ref] wrote:

quoted

On Thu, 15 Jul 2021 19:17:23 PDT (-0700), bmeng.cn@gmail.com wrote:

quoted

On Tue, Jul 13, 2021 at 2:34 PM Drew Fustini [off-list ref] wrote:

quoted

Add DT binding documentation for the StarFive JH7100 Soc [1] and the
BeagleV Starlight JH7100 board [2].

[1] https://github.com/starfive-tech/beaglev_doc
[2] https://github.com/beagleboard/beaglev-starlight

Signed-off-by: Drew Fustini <redacted>
---
v4 changes:
- removed JH7100 SoC revision number after discussion with Geert

v3 changes:
- added revision number for the board and soc after question from Palmer

v2 changes:
- removed "items:" entry that only had "const: starfive,jh7100"
- correct typo in Description:

Results of running checks:
  $ make -j8 ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- dt_binding_check \
    DT_SCHEMA_FILES=Documentation/devicetree/bindings/riscv/starfive.yaml
    CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
    DTEX    Documentation/devicetree/bindings/riscv/starfive.example.dts
    SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
    DTC     Documentation/devicetree/bindings/riscv/starfive.example.dt.yaml
    CHECK   Documentation/devicetree/bindings/riscv/starfive.example.dt.yaml
  $ make -j8 ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- dtbs_check \
    DT_SCHEMA_FILES=Documentation/devicetree/bindings/riscv/starfive.yaml
    SYNC    include/config/auto.conf.cmd
    UPD     include/config/kernel.release
    SCHEMA  Documentation/devicetree/bindings/processed-schema.json
    DTC     arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dtb
    DTC     arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dt.yaml
    DTC     arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dt.yaml
    DTC     arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dt.yaml
    CHECK   arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dt.yaml
    CHECK   arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dt.yaml
    CHECK   arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dt.yaml

The dts file is from vendor repo and is being cleaned up right now in
preperation for submitting to the mailing list:
https://github.com/starfive-tech/linux/tree/beaglev/arch/riscv/boot/dts/starfive

 .../devicetree/bindings/riscv/starfive.yaml   | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/starfive.yaml

Reviewed-by: Bin Meng <redacted>

Thanks.  This is on for-next, as Rob suggested taking it via the RISC-V
tree.

Given that beagleV starlight mass production is cancelled [1], are we
still upstreaming the support for this ?

I'm not sure, but I wasn't quite sure where to have that discussion.  I
figured that the boards exist so there's no reason to shoot this down, given
that it's just the vendor DT list.  At a bare minimum there's out of tree
support for this, so having the DT strings defined seems sane as that's a
defacto interface with bootloaders.

Maybe this is more of a question for Drew: I think we were all OK working
through the issues with the first-run chip when there was going to be a lot
of them, but with such a small number produced I'm not sure if there's going
to be enough interested to take on all that effort.

I'm not quite sure where we stand on support for this: at some point there
were some ideas floating around as to a way to support it without major
software changes (allocating into the non-caching regions).  If that pans
out then I'm fine handling this, at least from the RISC-V side, but if we're
going to have to go through all the ISA/SBI stuff then it's probably not
worth it.  Also not sure if there are a bunch of starfive-specific drivers
that would be needed to make this boot, in which case it's probably best to
wait for whatever comes next.

I think that the discontinued beta prototype could be useful as a native
build host for those of you that have it and don't have an Unmatched.

Also according to this statement [1], they're still planning on
producing new boards with the JH7100 (same chip as on the BeagleV
prototype) at the end of Q3 and the JH7110 further in the future, so I
still think it'd make sense to support those.

[1]: https://www.design-reuse.com/news/50402/starfive-open-source-single-board-platform-q3-2021.html

quoted

quoted

The arch_sync_dma RFC from Atish [1] is key to the board running
mainline. Most of the peripherals (USB, SD card, ethernet) are already
supported by upstream Cadence and Synopsys drivers. However, the vendor
kernel used ifdef's to flush the L2 cache at several points in those
drivers and subsystem cores because the peripherals are on a non-cache
coherent interconnect.

Without the proposed solution from Atish that uses the non-cached DDR
alias, then only serial console would work on mainline (assuming the
system is running from a ramdisk that the vendor uboot loaded).

We need the clock patches as well. If there is an agreed effort to
upstream the clock patches
and other bare minimum patches, I am happy to revise the DMA patches as well.

However, I am not sure all the patches should be beagleV or
starfive/starlight given the new announcement
from StarFive. Does anybody know if they are going to mass produce the
exact same SBC (JH7100) or some variant of it ?

Maybe we should defer upstreaming until we see the new board ? We
probably don't want two different versions of upstreaming support
for the same board!

The JH7100 was produced through MPW (multi-project wafer) runs and not
as a full mask set for mass production. I don't know what quantity will
exist beyond the 300 used on the beaglev starlight beta prototypes.

Thanks,
Drew

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv