[build problems found in Orangepi-r1_bullseye_current]

A followup:

# apt-get --reinstall install linux-headers-current-sunxi

# file /usr/src/linux-headers-5.15.80-sunxi/scripts/dtc/dtc

... ARM, EABI5 ...

shows that this is a problem in the image.

 

On the other hand doing this:

apt-get install wpasupplicant/bullseye-backports

still produces kernel backtraces.

 

And after this:

# apt-get install linux-image-edge-sunxi linux-headers-edge-sunxi linux-dtb-edge-sunxi

reboot

# uname -a
Linux orangepi-r1 6.0.10-sunxi #22.11.1 SMP Wed Nov 30 11:14:43 UTC 2022 armv7l GNU/Linux

I still get kernel backtraces from wpa_supplicant (direct or via nmtui).

The wlan0 interface does work regardless.

[build problems found in Orangepi-r1_bullseye_current]

Hello and Happy New Year,

 

From https://redirect.armbian.com/orangepi-r1/Bullseye_current I downloaded:

Armbian_22.11.1_Orangepi-r1_bullseye_current_5.15.80.img.xz

and installed. I see a file that shouldn't exist:

$ ls -l /*core
-rw-r--r-- 1 root root 16789504 Nov 30 11:55 /qemu_fstype_20221130-195503_13162.core

 

A short while later I found this:

$ armbian-add-overlay /etc/keys-h3.dts
/usr/sbin/armbian-add-overlay: line 62: /lib/modules/5.15.80-sunxi/build/scripts/dtc/dtc: cannot execute binary file: Exec format error
Error: dtc does not support compiling overlays

 

There is a symlink involved:

$ ls -l /lib/modules/5.15.80-sunxi/build
lrwxrwxrwx 1 root root 36 Nov 30 03:13 /lib/modules/5.15.80-sunxi/build -> /usr/src/linux-headers-5.15.80-sunxi

 

and I find:

$ file /usr/src/linux-headers-5.15.80-sunxi/scripts/dtc/dtc
/usr/src/linux-headers-5.15.80-sunxi/scripts/dtc/dtc: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=739474e836a0c8fb69e7d3902622523128d499a4, for GNU/Linux 3.2.0, not stripped

 

... which should be ARM not x86_64.

The most recent find:

Jan  1 06:57:29 jeep wpa_supplicant[2776]: nl80211: kernel reports: Authentication algorithm number required
Jan  1 06:57:30 jeep kernel: [50662.629441] ------------[ cut here ]------------
Jan  1 06:57:30 jeep kernel: [50662.629465] WARNING: CPU: 1 PID: 1930 at net/wireless/nl80211.c:17545 cfg80211_ch_switch_notify+0xc9/0xcc [cfg80211]
Jan  1 06:57:30 jeep kernel: [50662.629817] Modules linked in: 8189es cfg80211 sun4i_gpadc_iio r8152 industrialio rfkill sun8i_thermal uio_pdrv_genirq uio cpufreq_dt usb_f_acm u_serial g_serial libcomposite sunrpc ip_tables x_tables autofs4 pwrseq_simple sunxi phy_generic [last unloaded: 8189es]
Jan  1 06:57:30 jeep kernel: [50662.629926] CPU: 1 PID: 1930 Comm: RTW_CMD_THREAD Tainted: G        W         5.15.80-sunxi #22.11.1
Jan  1 06:57:30 jeep kernel: [50662.629940] Hardware name: Allwinner sun8i Family
Jan  1 06:57:30 jeep kernel: [50662.629954] [<c010cd21>] (unwind_backtrace) from [<c01095fd>] (show_stack+0x11/0x14)
Jan  1 06:57:30 jeep kernel: [50662.629984] [<c01095fd>] (show_stack) from [<c09e1165>] (dump_stack_lvl+0x2b/0x34)
Jan  1 06:57:30 jeep kernel: [50662.630009] [<c09e1165>] (dump_stack_lvl) from [<c011c3f9>] (__warn+0xad/0xc0)
Jan  1 06:57:30 jeep kernel: [50662.630032] [<c011c3f9>] (__warn) from [<c09dadf7>] (warn_slowpath_fmt+0x43/0x7c)
Jan  1 06:57:30 jeep kernel: [50662.630053] [<c09dadf7>] (warn_slowpath_fmt) from [<bf9044b5>] (cfg80211_ch_switch_notify+0xc9/0xcc [cfg80211])
Jan  1 06:57:30 jeep kernel: [50662.630243] [<bf9044b5>] (cfg80211_ch_switch_notify [cfg80211]) from [<bf9ba4d5>] (rtw_cfg80211_ch_switch_notify+0x97/0xd0 [8189es])
Jan  1 06:57:30 jeep kernel: [50662.631126] [<bf9ba4d5>] (rtw_cfg80211_ch_switch_notify [8189es]) from [<bf98de2b>] (rtw_chk_start_clnt_join+0x45/0x7a [8189es])
Jan  1 06:57:30 jeep kernel: [50662.631761] [<bf98de2b>] (rtw_chk_start_clnt_join [8189es]) from [<bf98dff1>] (join_cmd_hdl+0x191/0x254 [8189es])
Jan  1 06:57:30 jeep kernel: [50662.632388] [<bf98dff1>] (join_cmd_hdl [8189es]) from [<bf96e9fb>] (rtw_cmd_thread+0xe5/0x2e4 [8189es])
Jan  1 06:57:30 jeep kernel: [50662.633016] [<bf96e9fb>] (rtw_cmd_thread [8189es]) from [<c0136a73>] (kthread+0x117/0x12c)
Jan  1 06:57:30 jeep kernel: [50662.633346] [<c0136a73>] (kthread) from [<c0100139>] (ret_from_fork+0x11/0x38)
Jan  1 06:57:30 jeep kernel: [50662.633365] Exception stack(0xc433bfb0 to 0xc433bff8)
Jan  1 06:57:30 jeep kernel: [50662.633377] bfa0:                                     00000000 00000000 00000000 00000000
Jan  1 06:57:30 jeep kernel: [50662.633389] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Jan  1 06:57:30 jeep kernel: [50662.633400] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
Jan  1 06:57:30 jeep kernel: [50662.633471] ---[ end trace bb1537dfe65a110c ]---

 

The wlan0 interface seems to work as expected but this is still worrisome. Again, may or may not be related to the build.

 

I'm not sure if the above are related because of some error during the build or if I should report these seperately.

 

Thanks,

Chris

 

[u-boot question: boot 2nd partition?]

I too wanted to boot to a second partition and struggled. The workaround by @richardk sort of fixes of the problem but isn't a general solution. After examining the U-Boot environment (printenv at the u-boot prompt) and /boot/boot.cmd I feel that boot.cmd needs to be patched. If you set the boot flag on the second partition (parted or fdisk, etc.) then U-Boot correctly sets 'distro_bootpart' and thereafter uses '${devnum}:${distro_bootpart}'. I modified boot.cmd to follow the same convention, rebuilt boot.scr and it works.

 

*** a/boot.cmd  2020-03-29 11:47:02.268576905 -0700
--- b/boot.cmd  2020-03-29 11:55:28.541325423 -0700
***************
*** 18,25 ****

  echo "Boot script loaded from ${devtype}"

! if test -e ${devtype} ${devnum} ${prefix}armbianEnv.txt; then
!   load ${devtype} ${devnum} ${load_addr} ${prefix}armbianEnv.txt
    env import -t ${load_addr} ${filesize}
  fi

--- 18,25 ----

  echo "Boot script loaded from ${devtype}"

! if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}armbianEnv.txt; then
!   load ${devtype} ${devnum}:${distro_bootpart} ${load_addr} ${prefix}armbianEnv.txt
    env import -t ${load_addr} ${filesize}
  fi

***************
*** 34,71 ****

  if test "${docker_optimizations}" = "on"; then setenv bootargs "${bootargs} cgroup_enable=memory swapaccount=1"; fi

! load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile}
  fdt addr ${fdt_addr_r}
  fdt resize 65536
  for overlay_file in ${overlays}; do
!   if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-${overlay_file}.dtbo; then
      echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo"
      fdt apply ${load_addr} || setenv overlay_error "true"
    fi
  done
  for overlay_file in ${user_overlays}; do
!   if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then
      echo "Applying user provided DT overlay ${overlay_file}.dtbo"
      fdt apply ${load_addr} || setenv overlay_error "true"
    fi
  done
  if test "${overlay_error}" = "true"; then
    echo "Error applying DT overlays, restoring original DT"
!   load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile}
  else
!   if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-fixup.scr; then
      echo "Applying kernel provided DT fixup script (${overlay_prefix}-fixup.scr)"
      source ${load_addr}
    fi
!   if test -e ${devtype} ${devnum} ${prefix}fixup.scr; then
!     load ${devtype} ${devnum} ${load_addr} ${prefix}fixup.scr
      echo "Applying user provided fixup script (fixup.scr)"
      source ${load_addr}
    fi
  fi

! load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}uInitrd
! load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}Image

  booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

--- 34,71 ----

  if test "${docker_optimizations}" = "on"; then setenv bootargs "${bootargs} cgroup_enable=memory swapaccount=1"; fi

! load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}dtb/${fdtfile}
  fdt addr ${fdt_addr_r}
  fdt resize 65536
  for overlay_file in ${overlays}; do
!   if load ${devtype} ${devnum}:${distro_bootpart} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-${overlay_file}.dtbo; then
      echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo"
      fdt apply ${load_addr} || setenv overlay_error "true"
    fi
  done
  for overlay_file in ${user_overlays}; do
!   if load ${devtype} ${devnum}:${distro_bootpart} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then
      echo "Applying user provided DT overlay ${overlay_file}.dtbo"
      fdt apply ${load_addr} || setenv overlay_error "true"
    fi
  done
  if test "${overlay_error}" = "true"; then
    echo "Error applying DT overlays, restoring original DT"
!   load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}dtb/${fdtfile}
  else
!   if load ${devtype} ${devnum}:${distro_bootpart} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-fixup.scr; then
      echo "Applying kernel provided DT fixup script (${overlay_prefix}-fixup.scr)"
      source ${load_addr}
    fi
!   if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}fixup.scr; then
!     load ${devtype} ${devnum}:${distro_bootpart} ${load_addr} ${prefix}fixup.scr
      echo "Applying user provided fixup script (fixup.scr)"
      source ${load_addr}
    fi
  fi

! load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} ${prefix}uInitrd
! load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} ${prefix}Image

  booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

 

[NanoPi Neo 2 - set input pull-up via Device Tree]

First of all thank you for this post; it helped a lot.

 

But, I've just went through a similar journey and wonder if this is a complete solution. Your 'fragment@0' does what it intends but in my experience it was only half of the solution. My gleanings through various sources indicates that to actually accomplish something a second piece of the puzzle (for arguments sake 'fragment@1') is needed and it must reference the name (or alias?) of 'fragment@0'. I guess the reference could come from some other dts file but, normally, from, at least, another overlay file, or within the same overlay file.

 

The point I'm trying to make is that 'fragment@0' on its own did little. I found that setting 'bias-pull-up' will not result in seeing '1' on a gpio pin without another device-tree node referencing that pin. As far as I can see something like https://forum.armbian.com/topic/6723-gpio-keys-mainline-linux/ with 'fragment@1' referencing 'fragment@0' (through the line 'pinctrl-0 = <&gpio_keys>;' in that instance) only then would apply the 'bias-pull-up'.

 

I'm not advocating for how this appears to me at the moment. I'd rather use a gpio on its own if possible (perhaps there's a 'compatible = XXX' that I haven't found yet).

 

[mounting rw partition along with overlayroot]

The Debian packages bilibop(-*) are what you want. It works with kernels that have either aufs or overlayfs. You must be using initramfs-tools (as opposed to dracut). When your initrd is rebuilt it includes some of its scripts and files that do the magic. Use a normal /etc/fstab. In the bilibop configuration file you can whitelist other partitions that you want mounted normally.

 

You have to put in a kernel command line argument, I like 'lockfs=soft', but other options are available. With lockfs=soft the real rootfs is mounted read-only at either /overlay/ro or /aufs/ro. You can, as root, do something like below if you need to change something permanently:

root@skylight1:~$ mount -o remount,rw /overlay/ro
root@skylight1:~$ chroot /overlay/ro
root@skylight1:/$ .... do your work here
root@skylight1:/$ exit
root@skylight1:~$ mount -o remount,ro /overlay/ro

For simple file edits that's it. But some operations, say 'apt-get install somepackage', will require more work. You'll need to bind mount /dev, /proc and maybe others to /overlay/ro before entering the chroot (and umounting it all later).

 

One caution: if you use lockfs=hard (good for kiosk mode) you can paint yourself into a corner where you can't change the system at all. You'd have to mount your rootfs on another system (if you're working off an SD card) or NFS boot if you're working off of MMC.

 

 The included /usr/share/doc/bilibop* files are pretty good at explaining how it works.