R4Pro is completely different board. Do not use R4 dts for R4Pro. Base dt and overlays are already upstream,but only mgmt port is working related to network. Sd/emmc,nand,pcie is additional working so far
I understand, but I handle overlays a bit different on my images. They are .dts files and bpir-toolbox command handles them to create 1 single .dtb. It does use the original base .dtb that matches the specific board.
The overlays I am talking about are:
more BPIR4/* BPIR4-*/*
::::::::::::::
BPIR4/bootargs.dts
::::::::::::::
/dts-v1/;
/plugin/;
&{/} {
chosen {
bootargs = "earlycon=uart8250,mmio32,0x11000000";
};
};
::::::::::::::
BPIR4/memory.dts
::::::::::::::
/dts-v1/;
/plugin/;
&{/} {
memory {
device_type = "memory";
};
};
::::::::::::::
BPIR4/nand-changes.dts
::::::::::::::
/dts-v1/;
/plugin/;
#define MTK_PUPD_SET_R1R0_00 100
&spi0_flash_pins {
conf-pu {
pins = "SPI0_CS", "SPI0_HOLD", "SPI0_WP";
drive-strength = <8>;
bias-pull-up = <MTK_PUPD_SET_R1R0_00>;
};
conf-pd {
pins = "SPI0_CLK", "SPI0_MOSI", "SPI0_MISO";
drive-strength = <8>;
bias-pull-down = <MTK_PUPD_SET_R1R0_00>;
};
};
&spi_nand {
spi-cs-setup-delay-ns = <15>;
spi-cs-hold-delay-ns = <15>;
/* remove from main .dtb as overlay file cannot delete a property */
//fdtput -d /soc/spi@11007000/flash@0/partitions/partition@0 read-only
};
::::::::::::::
BPIR4-EMMC/emmc-enable.dts
::::::::::::::
/dts-v1/;
/plugin/;
&mmc0 {
pinctrl-names = "default", "state_uhs";
pinctrl-0 = <&mmc0_pins_emmc_51>;
pinctrl-1 = <&mmc0_pins_emmc_51>;
bus-width = <8>;
max-frequency = <200000000>;
cap-mmc-highspeed;
mmc-hs200-1_8v;
mmc-hs400-1_8v;
hs400-ds-delay = <0x12814>;
vqmmc-supply = <®_1p8v>;
vmmc-supply = <®_3p3v>;
non-removable;
no-sd;
no-sdio;
status = "okay";
};
::::::::::::::
BPIR4-SDMMC/sdmmc-enable.dts
::::::::::::::
/dts-v1/;
/plugin/;
#define GPIO_ACTIVE_LOW 1
&mmc0 {
pinctrl-names = "default", "state_uhs";
pinctrl-0 = <&mmc0_pins_sdcard>;
pinctrl-1 = <&mmc0_pins_sdcard>;
cd-gpios = <&pio 12 GPIO_ACTIVE_LOW>;
bus-width = <4>;
max-frequency = <52000000>;
cap-sd-highspeed;
vmmc-supply = <®_3p3v>;
vqmmc-supply = <®_3p3v>;
// no-mmc;
status = "okay";
};
I suspect that for these specific overlays, there is no difference in R4 and R4Pro.
The user can easily modify/change/append or create new ones in text format. Then run bpir-toolbox --write2dtb or --write2atf again.
The sdmmc overlay is different as on r4pro i cannot get full speed (52 mhz) working with my sandisk cards
Btw 6.19 generates full dtb for R3,R4 and R4Pro in mainline through kernel buildchain.R4Pro also has pcie overlays to switch slots between key-m (default) and key-b
The R4 Lite? (And more characters)
A perfect example of when to use the text based tweaking of overlays ![]()
R4Lite has issues with emmc because dat5 is also used as cd-gpio which requires 4-bit mode in atf,uboot and linux
Yep I copied that part for now, about dat5
I meant also I saw the pci lane switch on the R4 lite if I remember correctly.
Yes,pcie lanes can be splitted across both mpci slots or 2 lanes on one slot which is reported to be better for be14, but this is only theoretical, no idea how to test this completely.
I guess only with a custom card, as 2 lanes is not according to any standard.
I had suggested at one point if BPI could provide an adapter mpcie-2-lanes to a m.2 key x that does have 2+ lanes as standard. The answer was not negative, but have not seen one
It would really be useful @sinovoip , since the R4 Lite is not the first board that this can help users.
of course we can do r4lite dts with 1+1 lane as default and set 2-lane with overlay…currently afair i did it vice versa because of default usage with be14
I saw that default is 1 mcpie with 2 lanes, without applying any overlay on it.
Then I noticed 2 overlays, one for 1 mpcie with 2 lanes, and another one for 2 mpcie wit each 1 lane.
I guess the first overlay would not be needed as this already the default setup? Or maybe you need it for some other combination?
Right,i created a overlay for both versions independ of default setting to allow easy switching just by changing default in dts
I see U-Boot needed 2 gpio-hog for the pcie switch of the R4-Pro, so I’m adding that too.
As pcie2 cannot be used due to missing xsphy driver in uboot only one slot (cn14) can be used in uboot and so basicly the second gpio-hog is not needed (commented out in my source)
Thanks,
Trying out the building now, it is so much more easy to test and open a file in the chroot, when all files in the chroot are not owned by root anymore, but all files are owned now by the normal user.
Still debootstrap/pacman build the rootfs, but the root user is mapped.
So now the script can build an image entirely from scratch without using sudo.
I need to test this some more, but eventually all prebuild images will be build using this method.