Dolf Andringa

  • Content Count

    23
  • Joined

  • Last visited

About Dolf Andringa

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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.
  3. 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.
  4. 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 ke
  5. 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.
  6. 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 d
  7. 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 eep
  8. 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.
  9. 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?
  10. 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.
  11. 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 */ comp
  12. 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
  13. I've been building armbian xenial images for my pine64+ a few times now and it works well. But I would like to switch to bionic if I can. I find it hard to find a good place of documentation for either the 4.x kernel or ubuntu bionic for armbian, specifically for A64/Pine64 boards. If I google, I see tons of forum posts with specific issues, but no coherent overview of any issues with 4.x kernels? And reading through 2-3 years of replies on some threads is a bit much to find the info I need. So what would or wouldn't work on a 4.x kernel on ubuntu bionic? Also, I am confused about who does wha
  14. Jeez, why didn't I think of that. Answers are obvious when someone else gives them Thanks!