Dolf Andringa

  • Content Count

    17
  • 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. 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
  2. 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.
  3. 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?
  4. 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.
  5. 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
  6. 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
  7. 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
  8. Jeez, why didn't I think of that. Answers are obvious when someone else gives them Thanks!
  9. 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 u
  10. Why didn't I think of that. Much better idea. You are awesome @Igor. Thanks for all the quick replies.
  11. 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.
  12. 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.
  13. 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.