Dolf Andringa

Members
  • 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 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.
  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 */ 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
  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 I can't really find any docs on how to write my own overlay. So any help is appreciated.
  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 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.
  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 use it to enter the chroot manually.
  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.