Loading device tree overlays on VF2

VisionFive 2 （English Forum)
1

In the process of getting a adafruit gps board, expecially pps, to work on VF2 i experimented with dt overlays a bit.

the overlay i got working:

/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/starfive,jh7110-pinfunc.h>
/ {
    compatible = "starfive,visionfive-v2", "starfive,jh7110";

    //gpio
    fragment@0 {
        target-path = "/soc/gpio@13040000";
        __overlay__ {
            pps_pins: pps_pins@12 {
                pps_pins0 {
                    starfive,pins = <PAD_GPIO55>;
                    starfive,pinmux = <PAD_GPIO55_FUNC_SEL 1>; // pin mux no special function
                    //starfive,pinmux = <PAD_GPIO55_FUNC_SEL 0>; // pin mux no special function
                    starfive,pin-ioconfig = <IO(GPIO_IE(1) | GPIO_PU(0))>; // gpio in, no pullup
                    starfive,pin-gpio-din = <GPI_NONE>; // no special pin function
                    starfive,pin-gpio-doen = <OEN_HIGH>;
                };
            };
        };
    };


    //pps
    fragment@1 {
        target-path = "/soc";
        __overlay__ {
            pps: pps@12 {
                compatible = "pps-gpio";
                pinctrl-names = "default";
                pinctrl-0 = <&pps_pins>;
                gpios = <&gpio 55 0>;
                status = "okay";
            };
        };
    };
};

For this to work the devicetree has to be compiled with symbols (dtc option “-@”), otherwise “&pps_pins” has to be raplaced with the raw hex phandle for the gpio node.

If anyone has improvements/hints for this I’d be thankful, unfortunately there is few documentation on the Variables used for dt by starfive and it’s a guessing game with existing dts and the JH7110 datasheet to get things to work…

On kernels compiled with CONFIG_OF_OVERLAY and CONFIG_CONFIGFS (default for the vf2 kernel i think) one can load the compiled dtbos from linux, (example for the icludeded uart3_i2c.dtbo):

# mkdir /sys/kernel/config/device-tree/overlays/uart3
# cat /boot/dtb/starfive/vf2-overlay/vf2-overlay-uart3-i2c.dtbo > /sys/kernel/config/device-tree/overlays/uart3/dtbo

Trying to load the overlays can also be loaded via the distro boot mechanism by specifying dtoverlays with their full path in extlinux/extlinux.conf:

fdtoverlays /boot/dtb/starfive/vf2-overlay/vf2-overlay-pps-gpio.dtbo

resulted in an error message about the fdtoverlay_addr_r
If i set this to an adress in between the range for fdt_addr_r and ramdisk _add_r in uboot (there should be enough space…) it just works:

env set fdtoverlay_addr_r 0x48050000
env save

adding an fdtoverlay_addr_r to the distibuted u-boot out of the box would be a great addition :slight_smile:

3 Likes
2

That’s brilliant. I was hoping to be able to test a Uputronics u-blox GPS Hat on the Visionfive 2. You’ve given me the info I needed. Now to find the time to do it.

3

thats great :slight_smile:
just noticed the overlay is set up for pin 7 on the header, not as indicated by the pps nodes on 12. thats a leftover from previous tests…
pin 12 would be GPIO38

2 Likes
4

Will be there with next bootloader release: VisionFive 2: Add default device tree overlay address by MichaIng · Pull Request #44 · starfive-tech/u-boot · GitHub

5 Likes
5

thats great news, thanks for your work

2 Likes
6

As some distros that use extlinux to boot (e.g. armbian) don’t have the capability to get the right amount of RAM some (me) are stuck with only 4G of RAM.

So i created a device tree overlay to do a fixup and get all 8G:

/dts-v1/;
/plugin/;
/ {
    compatible = "starfive,visionfive-v2", "starfive,jh7110";

    //memory 8G
    fragment@0 {
        target-path = "/";
        __overlay__ { 
            memory@40000000 {
                device_type = "memory";
                reg = <0x0 0x40000000 0x2 0x0>;
            };
        };
    };
};

For all I know this should just work and testing with memtester in linux there are no complaints (loaded via extlinux dtoverlays).

I’m not sure this is the best way to do it but i couldn’t figure out how to set the memory from uboot… as far as i can tell other boot commands run fdt memory ${memory_addr} ${memory_size}; after laoding the dtb, but the distro boot mechanism just loads the provided dtb and i don’t know if its possible to interfere there and correct the memory size

3 Likes
7

Btw, for upstream u-boot+under review u-boot eth support patch, u-boot would automatically read eeprom for ddr size and modify dtb to correct size.

1 Like
8

You mean the way the current StarFive images do, rewriting the dtb file (which naturally then needs to have a hardcoded path and name) on every boot? I find this a highly problematic behaviour and don’t think that such would be merges into upstream U-Boot.

Not sure how other SBCs have no problem with different RAM sizes, but if it is not possible without changing the device tree on VisionFive 2, then this needs to be solved with an additional device tree or overlay.

9

Actually modifying device tree passing to kernel is a widely used operation in upstream u-boot. After a simple search in upstream code, I found more than 20 boards are using this method, and there’s a specific function designed for this. [v5,00/17] Basic StarFive JH7110 RISC-V SoC support - Patchwork

10

Can you give a link to related code parts? The linked review and what I see and know is about modifying the loaded in-memory device tree used by U-Boot itself, but not the on-disk .dtb file later loaded by the kernel.

It has already the practical issue that U-Boot then needs to know the partition and path of the device tree, which will be different on different distros. And it breaks booting from read-only filesystem as well as the (often) policy of distros to not modify files shipped by packages as long as not clearly marked as config files or variable data directory structures, i.e. usually anything outside of /etc and /var. And if anything goes wrong with this .dtb file write, a powerloss, I/O error due to bad physical connectivity, filesystem corruption, bad blocks, …, then the system may become unbootable.

11

Seems they are only modifying dtb in memory, not dtb file inside upstream series. I think I mistook your meaning, sorry.

2 Likes
12

For reference: Help needed, my dtb file got overwritten

2 Likes