[BPI-R4] Imagebuilder R4 ArchlinuxArm

1 minute google search: [SOLVED] pacman 7 - landlock is not supported by the kernel! / Pacman & Package Upgrade Issues / Arch Linux Forums

I guess it maybe this one:

https://bbs.archlinux.org/viewtopic.php?id=311058

edit pacman.conf and uncomment DisableSandbox this should fix the issue unless you want to config the kernel with landlock

I’ve added the -S or --disable-sandbox option to the build script. Users without landlock can use it to build an archlinuxarm image.

I’ve also added landlock support to the bpi-kernel, so it can be used when running on the bpi router board.

See:

Added more boards to the script. I do not own this hardware (yet), so I can only partly check it for bugs.

Added R4 Lite, R4 Pro 4E and R4 Pro 8X.

This is in very early stage. mt7987 (R4 Lite) ATF and U-Boot not tested at all.

R4 pro is mainly based on standard R4. Device tree overlays borrowed from R4, also the wired network setup, so this may need some manual changes to function properly.

Still no hostapd.conf for any R4 board…

Expect many changes and some bugs…

For now only build with script, no prebuild images.

1 Like

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 = <&reg_1p8v>;
  vmmc-supply = <&reg_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 = <&reg_3p3v>;
  vqmmc-supply = <&reg_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 :wink:

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)