Dolf Andringa

  • Content Count

  • Joined

  • Last visited

About Dolf Andringa

  • Rank

Recent Profile Visitors

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

  1. 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 script is there, instead of directly modifying the scripts like lib/
  2. 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?
  3. 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.
  4. 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
  5. 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.
  6. 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 what, and therefore where to go with problems. How are longsleep or sunxi involved in this? In the end, I guess my main question is: is it feasible to have a pine64A+ running no Ubuntu bionic, which I assume requires 4.x kernel, and what problems am I likely to encounter, or do I need to solve? Cheers, Dolf.
  7. Jeez, why didn't I think of that. Answers are obvious when someone else gives them Thanks!
  8. 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 to fail. Is there a way for me to chroot into the system where 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/ script but have a hard time figuring out how exactly it is used and how I can use it to enter the chroot manually.
  9. Why didn't I think of that. Much better idea. You are awesome @Igor. Thanks for all the quick replies.
  10. One more question: to test my build without having to write it to an sd and boot it, I have kvm and qemu-system-arm. Would it be possible to test my image by running an arm vm? Which board should I compile the kernel for in this case so I have a supported processor? qemu-arm doesn't support the Cortex A53 from my pine64. I don't mind compiling the kernel for a different board just for testing, since the only thing I'm doing is building a software installation script that should run regardless of the exact kernel.
  11. Ehrm, maybe I completely missed some docs somewhere and this is a stupid question, but how do I modify the actual image? I went through the whole build process and successfully created an image, but how can I change the software, repositories, etc for the image? Can I drop in a shell or something? Or do I need to modify files somewhere? Just mounting the image and chrooting won't work as I am doing the build on an x64 system.
  12. Thanks for the answer. Ok, makes sense about the maintenance. As a wild thought: Wouldn't something like integrating Ansible or something make sense? That way maintenance would be limited to maintaining ansible roles and playbooks, which wont be incredibly hard. For now, I will just build my own image indeed.
  13. Hi All, I have looked at the "How to build your own image/kernel post", but am wondering what the best way for me is to contribute. Basically, I often use the pine64 running armbian as an IoT control hub/gateway where it is running an install of nginx/php/mysql/mosquito/nodered. The php part is mostly because of phpmyadmin, so nginx comes in that case configured with node-red mounted on / and phpmyadmin on /phpmyadmin. I could create my own image with all this stuff on it, and also configure some default usernames, passwords and wifi setup, but I also noticed the "Software" section in armbian-config. So my question is which of these 3 options would be the easiest to do, and which one (if any) would be most appreciated as contribution back to armbian from me? Create a new image using the standard guide with all my software Somehow modify an existing image with additional software Contribute a new menu item under "Software" of armbian-config that will install the standard setup I have in mind, so it would work with any image