jh7110.dtsi: fix wrong offset for fwcfg, and make whole QSPI be available

[strlcat]

Fix typo in fwcfg offset (0xF00000 -> 0xF0000), so Linux uboot-tools can access fwcfg block to modify boot configuration from userspace.

While we're at it, let's repartition QSPI into more handy style, by applying table from https://doc-en.rvspace.org/VisionFive2/Boot_UG/JH7110_SDK/boot_address_allocation.html.

[vali-um]

It would be great if this could be merged.
If access to the qspi as one complete block is underiable at least the fix for the correct spi regions as described in the documentation would be great.

--- a/arch/riscv/boot/dts/starfive/jh7110.dtsi       2023-04-25 12:18:33.840079960 +0000
+++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi    2023-04-25 12:21:37.123148082 +0000
@@ -372,13 +372,16 @@
                                        #size-cells = <1>;
 
                                        spl@0 {
-                                               reg = <0x0 0x40000>;
+                                               reg = <0x0 0x80000>;
+                                       };
+                                       uboot-env@f0000 {
+                                               reg = <0xf0000 0x10000>;
                                        };
                                        uboot@100000 {
-                                               reg = <0x100000 0x300000>;
+                                               reg = <0x100000 0x400000>;
                                        };
                                        data@f00000 {
-                                               reg = <0xf00000 0x100000>;
+                                               reg = <0x600000 0x1000000>;
                                        };
                                };
                        };

[MichaIng]

Only suggestion I have is to keep the current region paths the same, so that existing guides and scripts to e.g. update U-Boot, remain valid and do not start to e.g. attempt writing the U-Boot image to the env region. I.e. keep the order:

1. SPL
2. U-Boot image
3. env
4. data (is there a perspective use for this, actually?)

It does not represent the order of the address spaces, but it does not break anything.

[vali-um]

You are absolutely right, i'll create a seperate pull request for this...
Would be a shame if someone bricked their system just bc they were overwriting env with compiled uboot following documentation at https://doc-en.rvspace.org/VisionFive2/Quick_Start_Guide/VisionFive2_SDK_QSG/updating_spl_and_u_boot%20-%20vf2.html#updating_spl_and_u_boot-vf2__section_zpj_cqt_yvb

4.: documentation states "Reseved" [sic]
I think one can use for whatever they want, it's just rw nand flash. I'm not sure future use is planned but exposing parts of it to linux was most likely a typo:

Fix typo in fwcfg offset (0xF00000 -> 0xF0000),

[MichaIng]

I think one can use for whatever they want, it's just rw nand flash. I'm not sure future use is planned but exposing parts of it to linux was most likely a typo:

It's not that important, but I was just wondering which name fits best for this region. It looks like reg = <0xf00000 0x100000>; => reg = <0xf0000 0x10000>; was indeed a typo and hence this "data" region was intended to be for the U-Boot environment. The name "env" however fits better for the U-Boot environment. But I'm not sure whether "data" or "bootdata" is a good name for this currently unused region, as it sounds like it was in use. Probably "reserved" (following the docs) or even "unused" makes more sense. So admins get from cat /proc/mtd that they may be creative using this space for whatever they can think of.