c0rnelius
Members
-
Joined
-
Really anyone here with a little patch and git know how could attempt to do a PR and add it to the legacy branch, which is still 6.12.y. Everything one would need is sitting in the deb builder and in armbian./build. Not sure Armbian would let you just add it to legacy though? Maybe. Why don't I? I don't want anything to do with supporting the REV2 beyond the efforts I've made. The REV1 was a curious buy, as I was already working on the BPI-M4-Zero and wanted another H618 to work on that had an ETH port. Also, it was only like $25 at the time.
-
-
-
-
It is actually a multi-layered problem. 1) Different DRAM (u-boot is different on both REVS) 2) Out-of-tree ethernet driver 3) Out-of-tree wireless driver The last good source for those drivers were linux-6.12.y. Armbian last I checked was on 6.18.y and up? I personally don't have time to mess with the drivers to get them up to snuff and even if I did, I'm not sure I could. Plus I only have the REV1. Anyway, that's the gist of it.
-
-
-
-
I would suggest using a better SD card. G12B:BL:6e7c85:2a3b91;FEAT:E0F83180:402000;POC:F;RCY:0;EMMC:0;READ:0;0. bl2_stage_init 0x01 bl2_stage_init 0x81 hw id: 0x0000 - pwm id 0x01 bl2_stage_init 0xc1 bl2_stage_init 0x02 L0:00000000 L1:20000703 L2:00008067 L3:14000000 B2:00402000 B1:e0f83180 TE: 53694 BL2 Built : 19:23:21, Sep 18 2020. g12b g9fde858 - gongwei.chen@droid11-sz Board ID = 12 Set A53 clk to 24M Set A73 clk to 24M Set clk81 to 24M A53 clk: 1200 MHz A73 clk: 1200 MHz CLK81: 166.6M smccc: 00011aa2 eMMC boot @ 0 sw8 s board id: 12 Load FIP HDR DDR from eMMC, src: 0x00010200, des: 0xfffd0000, size: 0x00004000, part: 0 Get wrong ddr fw magic! Error!! fw parse done PIEI prepare done 00000000 emmc switch 1 ok 00000000 emmc switch 2 ok NO find ddr boot_info from eMMC fastboot data verify result: 255 Cfg max: 12, cur: 1. Board id: 255. Force loop cfg LPDDR4 probe LPDDR4_PHY_V_0_1_22-Built : 14:57:26, Sep 1 2020. g12b g3c95fed - gongwei.chen@droid11-sz ddr clk to 1608MHz 00000000 emmc switch 0 ok dmc_version 0001 Check phy result INFO : End of CA training INFO : End of initialization INFO : Training has run successfully! Check phy result INFO : End of initialization INFO : End of read enable training INFO : End of fine write leveling INFO : End of read dq deskew training INFO : End of MPR read delay center optimization INFO : End of Write leveling coarse delay INFO : End of read delay center optimization INFO : Training has run successfully! Check phy result INFO : End of initialization INFO : End of MPR read delay center optimization INFO : End of write delay center optimization INFO : End of read delay center optimization INFO : End of max read latency training INFO : Training has run successfully! 1D training succeed Check phy result INFO : End of initialization INFO : End of 2D read delay Voltage center optimization INFO : End of 2D read delay Voltage center optimization INFO : End of 2D write delay Voltage center optimization INFO : End of 2D write delay Voltage center optimization INFO : Training has run successfully! soc_vref_reg_value 0x 0000001d 0000001c 0000001b 0000001e 0000001c 0000001c 0000001d 0000001c 0000001c 0000001a 0000001a 0000001b 00000019 0000001f 0000001b 0000001c 0000001b 0000001e 0000001c 0000001e 0000001a 0000001c 0000001c 0000001b 0000001c 0000001c 0000001b 0000001d 0000001d 0000001c 0000001b 0000001c dwc_ddrphy_apb_wr((0<<20)|(2<<16)|(0<<12)|(0xb0):0004 dram_vref_reg_value 0x 0000004d 2D training succeed auto size-- 65535DDR cs0 size: 2048MB DDR cs1 size: 2048MB DMC_DDR_CTRL: 00e00024DDR size: 3928MB cs0 DataBus test pass cs1 DataBus test pass cs0 AddrBus test pass cs1 AddrBus test pass non-sec scramble use zero key ddr scramble enabled 100bdlr_step_size ps== 403 result report boot times 0Enable ddr reg access 00000000 emmc switch 3 ok Authentication key not yet programmed get rpmb counter error 0x00000007 00000000 emmc switch 0 ok Load FIP HDR from eMMC, src: 0x00010200, des: 0x01700000, size: 0x00004000, part: 0 Load BL3X from eMMC, src: 0x00078200, des: 0x01768000, size: 0x000bea00, part: 0 0.0;M3 CHK:0;cm4_sp_mode 0 MVN_1=0x00000000 MVN_2=0x00000000 [Image: g12b_v1.1.3390-6ac5299 2019-09-26 14:10:05 luan.yuan@droid15-sz] OPS=0x10 ring efuse init chipver efuse init 29 0b 10 00 01 25 0c 00 00 0c 37 32 34 54 31 50 [0.778675 Inits done] secure task start! high task start! low task start! run into bl31 NOTICE: BL31: v1.3(release):4fc40b1 NOTICE: BL31: Built : 15:58:17, May 22 2019 NOTICE: BL31: G12A normal boot! NOTICE: BL31: BL33 decompress pass ERROR: Error initializing runtime service opteed_fast <debug_uart> U-Boot 2026.01 (Jan 15 2026 - 07:25:48 -0500) bpi-m2s Model: BananaPi M2S SoC: Amlogic Meson G12B (A311D) Revision 29:b (10:2) DRAM: 2 GiB (total 3.8 GiB) Core: 401 devices, 31 uclasses, devicetree: separate MMC: mmc@ffe05000: 0, mmc@ffe07000: 1 Loading Environment from nowhere... OK PCIE-0: Link up (Gen1-x1, Bus0) In: usbkbd,serial Out: vidconsole,serial Err: vidconsole,serial Net: eth0: ethernet@ff3f0000 starting USB... Starting the controller USB XHCI 1.10 Bus usb@ff500000: 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 8133 bytes read in 2 ms (3.9 MiB/s) ## Executing script at 08000000 U-boot default fdtfile: amlogic/meson-g12b-a311d-bananapi-m2s.dtb Current variant: 211 bytes read in 1 ms (206.1 KiB/s) Current fdtfile after armbianEnv: amlogic/meson-g12b-a311d-bananapi-m2s.dtb Mainline bootargs: root=UUID=45e1ab7d-9528-4d3b-8b8e-27c59e112250 rootwait rootfstype=ext4 splash=verbose console=ttyAML0,115200 console=tty1 consoleblank=0 coherent_pool=2M loglevel=1 ubootpart=fe959640-01 libata.force=noncq usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cgroup_enable=memory 25338901 bytes read in 1073 ms (22.5 MiB/s) 42338816 bytes read in 1792 ms (22.5 MiB/s) 80849 bytes read in 6 ms (12.8 MiB/s) Working FDT set to 4080000 232 bytes read in 5 ms (44.9 KiB/s) Applying kernel provided DT fixup script (meson-fixup.scr) ## Executing script at 32000000 ## Loading init Ramdisk from Legacy Image at 13000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 25338837 Bytes = 24.2 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 04080000 Booting using the fdt blob at 0x4080000 Working FDT set to 4080000 Loading Ramdisk to 7e7d5000, end 7ffff3d5 ... OK Loading Device Tree to 000000007e758000, end 000000007e7d4fff ... OK Working FDT set to 7e758000 Starting kernel ... Armbian 26.2.1 Trixie ttyAML0 bananapim2s login: root Password: _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v26.2.1 for Banana Pi M2S running Armbian Linux 6.18.15-current-meson64 Packages: Debian stable (trixie) Performance: Load: 12% Uptime: 1m Memory usage: 5% of 3.68G CPU temp: 44°C Usage of /: 5% of 29G Commands: Configuration: armbian-config Monitoring : htop root@bananapim2s:~#
-
Here is an IMG with just u-boot flash to it; https://github.com/pyavitz/binary/releases/download/images/k1-spacemit-boot.img Using it will bypass the SPI and allow you to boot from USB NVME EMMC. Granted, an Armbian IMG would need to have already been flashed or transferred to one of them. It could be useful if say, you b0rked the SPI and wanna attempt to fix it or to use the SD card as a chainload mech to boot into the NVMe.
-
I don't own an OPI RV2, but I do have a few K1's. I suggest trying without that NVMe attached as it may be a contributing factor to boot fails. Technically correct. But I've seen some peps attempt some odd things and then wonder why it doesn't work. With serial attached, stop auto boot with the SPACEBAR. From there run `nvme` and you'll be provided with options. Are you suggesting you wanna bypass SPI by using an SD card to boot into say an NVMe or USB? Should be easy enough. Partition an SD card with an 4MiB offset and flash the u-boot bins to it. U-boot should then check for what ever is available to boot from; USB SD NVME MMC. If there is no extlinux.conf, boot.scr or *.efi to boot from on the SD, it will look else where.
-
Some NVMe's just don't play nice with some units. I have one such NVMe, which is why I rarely try to use it. Also u-boot is not set up to look for an infinite amount of $devnum. Currently it is hard coded to look for nvme 0:1. So I suggest moving the NVMe to the first available. According to the boot log you have more than one PCIE link up [ 1.438] PCIE-0: Link up (Gen2-x2, Bus0) <-- Thats where you want to attach the NVMe [ 1.600] PCIE-2: Link up (Gen2-x2, Bus2) Honestly though. It looks like the NVMe you are trying to use isn't compat.
-
The armbian boot loader is diff than the vendors. It checks for specific things in a particular order. nvme_devtype=nvme nvme_devnum=0 nvme_bootpart=1 autoboot=if test -e ${devtype} ${devnum}:${distro_bootpart} /extlinux/extlinux.conf; then \ sysboot ${devtype} ${devnum}:${distro_bootpart} any 0x2000000 /extlinux/extlinux.conf; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot/extlinux/extlinux.conf; then \ sysboot ${devtype} ${devnum}:${distro_bootpart} any 0x2000000 /boot/extlinux/extlinux.conf; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot.scr; then \ load ${devtype} ${devnum}:${distro_bootpart} 0x2000000 /boot.scr; source 0x2000000; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot/boot.scr; then \ load ${devtype} ${devnum}:${distro_bootpart} 0x2000000 /boot/boot.scr; source 0x2000000; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} EFI/BOOT/BOOTRISCV64.EFI; then \ load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} EFI/BOOT/BOOTRISCV64.EFI; bootefi ${kernel_addr_r}; \ fi; nvme part; \ setenv devtype $nvme_devtype; \ setenv devnum $nvme_devnum; \ setenv distro_bootpart $nvme_bootpart; \ if test -e ${devtype} ${devnum}:${distro_bootpart} /extlinux/extlinux.conf; then \ sysboot ${devtype} ${devnum}:${distro_bootpart} any 0x2000000 /extlinux/extlinux.conf; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot/extlinux/extlinux.conf; then \ sysboot ${devtype} ${devnum}:${distro_bootpart} any 0x2000000 /boot/extlinux/extlinux.conf; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot.scr; then \ load ${devtype} ${devnum}:${distro_bootpart} 0x2000000 /boot.scr; source 0x2000000; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot/boot.scr; then \ load ${devtype} ${devnum}:${distro_bootpart} 0x2000000 /boot/boot.scr; source 0x2000000; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} EFI/BOOT/BOOTRISCV64.EFI; then \ load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} EFI/BOOT/BOOTRISCV64.EFI; bootefi ${kernel_addr_r}; \ fi; bootcmd=echo "Loading K1-X Environment ..."; \ echo ""; \ echo "Running NVMe Scan ..."; \ nvme scan; \ run autoboot SD takes priority. After that it checks for an eMMC and if nothing on the eMMC is found it can use, it then moves on to check the NVMe. What this means? If the unit has an SPI, it needs to be updated with the Armbian boot loader. If the bootloader finds an extlinux.conf, boot.scr or *.EFI on the eMMC it will attempt to boot from it. I have a BPI-F3 which has no SPI. What I do in that case is boot from SD, format the eMMC and transfer the install to the NVMe. I then flash u-boot to the eMMC and wham oh. System boots from NVMe. In the case of an SPI, its the same. As long as it doesn't find anything of use on the eMMC your good.
-
Here is an example of an overlay for adding an RTC to the radxa zero /dts-v1/; /plugin/; / { compatible = "radxa,zero", "amlogic,g12a"; fragment@0 { target-path = "/"; __overlay__ { aliases { rtc0 = &rtc; }; }; }; fragment@1 { target = <&i2c3>; __overlay__ { #address-cells = <1>; #size-cells = <0>; rtc: rtc@68 { compatible = "dallas,ds1307"; reg = <0x68>; wakeup-source; }; }; }; __overrides__ { rtc = <0>,"+0"; addr = <&rtc>, "reg:0"; }; }; Key bits here: * aliases (some of these AML units have vrtc on rtc0, so it may need to be set to rtc1) * i2c# (this should be obvious) * compatible string * wakeup-source The i2c-dev module must be force loaded in some cases. If it isn't hard coded into the kernel, you can add it to /etc/modules
-
https://forums.kali.org/ There is an arm64 section.
