Dolf Andringa

Hi all, I have a few orange pi zero's and recently on 2 I had an issue with wifi AP that I am trying to properly understand. I have read some of the discussion regarding the wifi chip on the opi0 and that's not a great chip. I thoroughly agree with people that say that if you pay bottom dollar for a board, don't expect top dollar performance. And especially don't come complaining on a public FOSS forum. The only thing I am trying to do is understand the error and see if there is anything I can do to improve it. I use my orange pi zero's with a basic (custom) armbian image that starts up with a wifi AP briefly, so I can ssh in and do some config. Afterwards I reboot it and either turn wifi off altogether, or just connect as a wifi client using wpa_supplicant/ `/etc/network/interfaces.d`. So no heavy wifi AP usage. This has been working fine so far, but with 2 recent boards I couldn't connect to the wifi, and upon inspection of the logs, it showed these errors: [ 21.667120] random: crng init done [ 21.667157] random: 7 urandom warning(s) missed due to ratelimiting [ 21.692073] xradio AP-WRN: ap restarting! [ 21.731438] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 33.782692] vcc3v0: disabling [ 33.782721] vcc5v0: disabling [ 56.852083] xradio TXRX-WRN: received frame has no key status [ 56.852107] xradio TXRX-WRN: dropped received frame [ 56.852208] xradio TXRX-WRN: received frame has no key status [ 56.852218] xradio TXRX-WRN: dropped received frame [ 56.855392] xradio TXRX-WRN: received frame has no key status [ 56.855413] xradio TXRX-WRN: dropped received frame [ 56.861510] xradio TXRX-WRN: ***skb_queue_tail [ 56.973724] xradio TXRX-WRN: ***skb_queue_tail [ 57.028068] xradio TXRX-WRN: ***skb_queue_tail [ 57.040336] xradio TXRX-WRN: ***skb_queue_tail [ 57.042775] xradio TXRX-WRN: received frame has no key status [ 57.042789] xradio TXRX-WRN: dropped received frame [ 57.198022] xradio TXRX-WRN: ***skb_queue_tail [ 57.198644] xradio TXRX-WRN: received frame has no key status [ 57.198669] xradio TXRX-WRN: dropped received frame [ 57.198740] xradio TXRX-WRN: received frame has no key status [ 57.198752] xradio TXRX-WRN: dropped received frame [ 57.199236] xradio TXRX-WRN: received frame has no key status [ 57.199249] xradio TXRX-WRN: dropped received frame [ 57.199662] xradio TXRX-WRN: received frame has no key status [ 57.199672] xradio TXRX-WRN: dropped received frame [ 57.273269] xradio TXRX-WRN: ***skb_queue_tail [ 57.398636] xradio TXRX-WRN: ***skb_queue_tail Can anybody explain what these errors actually mean? Is this indicative of an actual hardware error on the board? Or could it be caused by something else? I did update my base image recently (using the same `customize_image.sh`), or could it be something locally on my wifi that can cause these errors? ---- EDIT ---- After diving into the driver source (well, at least one of the versions), I found this piece of code that seems to trigger the message: void xradio_rx_cb(struct xradio_vif *priv, struct wsm_rx *arg, struct sk_buff **skb_p) { . . . . . . . if (unlikely(early_data)) { spin_lock_bh(&priv->ps_state_lock); /* Double-check status with lock held */ if (entry->status == XRADIO_LINK_SOFT) { skb_queue_tail(&entry->rx_queue, skb); dev_warn(priv->hw_priv->pdev, "***skb_queue_tail\n"); } else ieee80211_rx_irqsafe(priv->hw, skb); spin_unlock_bh(&priv->ps_state_lock); } else { ieee80211_rx_irqsafe(priv->hw, skb); } *skb_p = NULL; I am not very familiar with the linux networking drivers/stack, but from what I understand, a wifi frame comes in over a socket, causing the rx callback to be called, which does a bunch of stuff, ending with checking some status (on the wifi chip? or on the frame?) concludes that the status is XRADIO_LINK_SOFT, which I guess means it isn't able to do something, and queues the frame back on the receive socket buffer/queue (and warns about it)? So does anyone know what that status means? And if there is anything that could cause it? Cheers, Dolf.

basically, instead of doing a `improved_git checkout ....` , we could replace it with a `git submodule update --init`, and then depending on a config option, followed by the `improved_git checkout....` if we want the HEAD of all dependencies (default) or stick with whatever commit the submodule points at. It would allow the master branch to always point to HEAD of whatever repos/branch we depend on, while the release branches would be able to point to specific commits/branches/tags of the dependencies.

Hmm, maybe I can indeed spend some time on that. Do you guys have an opinion about using git submodules? Instead of just checking out the kernel and other repositories, they could be added as submodules to armbian-build, which would mean they would always check out the same commit.

Yeah, but master is always the "latest and greatest". But with all the different optional combinations of hardware and software, there is no guarantee that works on all of those as well, especially with older hardware. I usually prefer using a "stable"/"working" tag/version, and only upgrade to a newer version if/when needed. Right now master gives me (different) trouble as well, but I guess I have no option now if version 2020.11 is broken with the mainline kernel to deal with the issue master gives me. But would it not be an option to use specific "known good" commits of the kernel srouce in combination with armbian-build tags? Instead of just always checking out the "latest" mainline kernel? It would be really nice to have tags in time where you know a specific combination of kernel, armbian and hardware version works, and you can just check that out again later if needed. For me everything worked until I removed my caches, which kicked off a kernel recompile (as expected), but clearly with a different kernel or toolchain version than before, because now it won't compile anymore., while before it did.

By default when I build armbian on master, it downloads the toolchains from the china mirror for me, but those always fail to verify the gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz with gpg BAD SIGNATURE. If I change to ARMBIAN_MIRROR="https://minio.k-space.ee/armbian/dl/" the issue disappears.

I am trying to build an updated image for an orange pi zero using the mainline buster headless. I tried on an ubuntu 20.04 VM (on a fedora host) and on a natively ubuntu20.04 installed laptop. Both fail to compile the kernel with the same error. Below is my compile config file and my compilation.log is attached. Any ideas what is going wrong here? I know I don't have the make terget in CLEAN_LEVEL, but I even tried when completely removing the whole armbian-build folder and cloning a fresh repos and removing all apt-cache-ng cache. So it's not due to that. # Read build script documentation https://docs.armbian.com/Developer-Guide_Build-Options/ # for detailed explanation of these options and for additional options not listed here KERNEL_ONLY="no" # leave empty to select each time, set to "yes" or "no" to skip dialog prompt KERNEL_CONFIGURE="no" # leave empty to select each time, set to "yes" or "no" to skip dialog prompt CLEAN_LEVEL="oldcache" # comma-separated list of clean targets: "make" = make clean for selected kernel and u-boot, # "debs" = delete packages in "./output/debs" for current branch and family, # "alldebs" = delete all packages in "./output/debs", "images" = delete "./output/images", # "cache" = delete "./output/cache", "sources" = delete "./sources" # "oldcache" = remove old cached rootfs except for the newest 8 files DEST_LANG="en_US.UTF-8" # sl_SI.UTF-8, en_US.UTF-8 # advanced EXTERNAL_NEW="prebuilt" # compile and install or install prebuilt additional packages INSTALL_HEADERS="no" # install kernel headers package LIB_TAG="master" # change to "branchname" to use any branch currently available. USE_TORRENT="yes" # use torrent network for faster toolchain and cache download ARMBIAN_MIRROR="https://minio.k-space.ee/armbian/dl/" DOWNLOAD_MIRROR="" # set to "china" to use mirrors.tuna.tsinghua.edu.cn CARD_DEVICE="" # device name /dev/sdx of your SD card to burn directly to the card when done BOARD="orangepizero" BRANCH="current" RELEASE="buster" BUILD_DESKTOP="no" BUILD_MINIMAL="yes" compilation.log

I have a raspi hat (rak2245) that has 2 versions: a pi-hat version that has a 40 pin-header on it for raspberry pi's , but also a smaller stamp edition. It uses spi and uart to communicate with the pi. I have it running without issues on my orange pi zero, even though the pinheader is a little too large. And via a breadboard I can access all pins just fine. But since I am making my own PCB anyway, I am interested in using the stamp version. The only difference between the stamp and the pi-hat version (aside from the form-factor and pin-out) is that the pi-hat version has an additional eeprom chip to tell the rapsberry pi about the function of the pins apparently. Now I wonder if that chip is just a convenience or if I can actually do without it. I am comfortable making my own device tree overlay files to indicate pin functions. I've done it with spi before to add additional CS pins on the orange pi zero. So my question is, would that likely be enough to get the stamp version running, or would leaving out the eeprom chip likely make it not work (without serious driver development work)? Cheers.

The issue is that I then need to keep my fork up-to-date with the parent repository from that point onwards. I would prefer to just be able to checkout armbian-build and trust it is up-to-date. It is exactly the same reasoning why the customize-image.sh script is there, instead of directly modifying the scripts like lib/general.sh.

Is there a way, without having to fork the armbian/build repos, to modify the first run service? I would like to add some stuff. It would be awesome if there is a way to provide an extra script that is run after the end of the armbian-first-run service. Maybe an additional parameter in armbian_first_run.txt that can provide the path to a script that gets run? Or is there a way I am overlooking that can achieve this already?

Awesome, thanks.

I am building my own armbian image using the armbian build environment. A substantial part of the image creation time is occupied by over-and-over recompiling the kernel. Sure, it does go faster the 2nd time, but it still takes a lot of time. The goal for me is not to make a custom kernel. I am totally happy with the kernel. The goal for me is to modify the rest of the image. They installed software, config, etc. Is there a way to reuse an existing kernel for this, instead of rebuilding a new one each time? Cheers, Dolf.

OK, lol, I figured it out. I created a file (in my homedir on the orangepi) called spi-double-spidev-cs.dt` with the folliowing content: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&spi1>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; spidev@0 { reg = <0>; /* Chip Select 0 */ compatible = "spidev"; spi-max-frequency = <1000000>; status = "okay"; }; spidev@1 { reg = <1>; /* Chip Select 1 */ compatible = "spidev"; spi-max-frequency = <1000000>; status = "okay"; }; }; }; }; Then I enabled that overlay with `armbian-add-overlay spi-double-spidev-cs.dts`. This automatically compiles the overlay and adds it to `/boot/armbianEnv.txt`. Just make sure you add the following parameter to `/boot/armbianEnv.txt` as well: param_spidev_spi_bus=1

I want to drive 2 SPI devices on my orangepi zero. I enabled `spi-spidev` and `spi-add-cs1` overlays and set `param_spidev_spi_bus` to 1. But by I still get only `/dev/spi1.0` available. When I add `param_spidev_spi_cs=1`, I get `/dev/spi1.1` but `/dev/spi1.0` disappears. Do I see it correctly that I can choose *either* `/dev/spi1.0` *or* `/dev/spi1.1` but not both with that overlay? How can I activate both cs pins? There are a bunch of example custom files out there, but none are meant specifically for the setup where I need spi1 (instead of spi0) and need to use a GPIO pin for cs1. And I can't really find any docs on how to write my own overlay. So any help is appreciated.

Jeez, why didn't I think of that. Answers are obvious when someone else gives them Thanks!

Cool. Thanks. I am testing everything on ubuntu xenial (vm) and developing to for ubuntu xenial. So thats fine. Question though: I am running into networking related problems that cause the compile.sh to fail. Is there a way for me to chroot into the system where customize-image.sh script is being executed so I can debug the issue? Normally chrooting won't work on a different architecture (at least as far as I have tried) but it looks like it is being used by the build process. I see the lib/chroot-buildpackages.sh script but have a hard time figuring out how exactly it is used and how I can use it to enter the chroot manually.