mikaey

  • Content Count

    11
  • Joined

  • Last visited

About mikaey

  • Rank
    Member

Recent Profile Visitors

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

  1. Hey folks, So here's the setup I have: I have an Orange Pi 4B running the Orange Pi 4 image and kernel 5.6.17-rockchip64. I have an Orange Pi 4 running the Orange Pi RK3399 image and kernel 5.4.26-rockchip64 (cause when I got it, the Orange Pi 4 images weren't out yet). The OPi4 is running just fine. I imagine that I'm running the wrong DTB and that not all the hardware is working properly -- but the hardware I need is working just fine. The OPi4B is another story. It'll boot just fine, and it'll run just fine for days/weeks on end -- as long as
  2. I'm having this same issue with the Orange Pi Zero Plus. Did anyone ever figure out what the issue was?
  3. Hey folks, The tl;dr version of my question is "is there a way to stop tmpfs from being used for things like /tmp, /run, etc.?" Essentially I have an OPi Zero running PiAware and graphs1090. Graphs1090 is throwing a bunch of images into a folder under /run, which is causing the amount of free space to drop below 16M. As a result, systemctl refuses to restart some services because there isn't enough free space on /run. So...is there a way to disable the use of tmpfs for folders like /run or /tmp? Honestly, I'd rather just take the hit to the SD card rather
  4. Sorry guys...got locked out of my account :-) So...no, I'm not sure that the log is coming from the SD card specifically. All I know at this point is that the board behaves differently with an SD card vs. without one. Without one, it boots into (what I'm assuming is) Android. With one, it prints out the log I posted earlier and then freezes.
  5. Ok...so the verdict is I have a bad TTL adapter. I have a Rock64 and some jumper wires, and the Rock64 has a UART on it capable of running a 1500000 baud...so I wired up the debug pins on the OPi to the UART on the Rock64 -- and bam, I get stuff that I can at least read. (The only bad thing is that the Rock64 leaks voltage out of the UART pins...so the board tries to power on as soon as you hook it up.) Without the SD card? I think you're right -- it tries to boot into Android. I see a bunch of messages from the kernel, and then it drops into a shell. (Interestingly
  6. No luck. These are the two contacts we're talking about, right? (Stole this from Xunlong's manual) Also, damn, it's hard to hold a pair of tweezers on those two contacts... I've also cycled through every baud rate my TTL adapter supports with no luck.
  7. Yay! /s Ok, let me give that a shot.
  8. Hey folks, I ordered an Orange Pi 4 a couple weeks ago, and it showed up on Wednesday. Last night I started tinkering around with to see if I could get Armbian up and running on it. First thing I did was to hook up my USB-to-TTL debugger to it (no SD card inserted). But when I powered it on, all I'm getting over the serial connection is garbage. With my other OPi's, I'm used to getting U-Boot messages -- but this was far from that: The garbage settles down after about 30 seconds. When I have it hooked up to my Windows machine, I get a new device called
  9. Ok, I think I got it! Had to learn a little bit about device trees in the process. BUT...here's what I did (and BTW -- I did this all directly on the PC2): Step 1: Grab a copy of the Linux source: $ sudo apt install linux-source-4.19.20-next-sunxi64 This will dump the Linux source tarballs (and a config file) into /usr/src. Step 2: Unzip the tarball, and copy in the config file: $ cd /usr/src $ sudo mkdir linux $ sudo chown `whoami`:`whoami` linux $ cd linux $ tar xvf ../linux-source-4.19.20-sunxi64.tar.xz $ xzcat ../linux-sunxi64-next_4.19.20_5.75_config.x
  10. I've got an Orange Pi PC2, and I'm running some pretty CPU intensive tasks on it. However, I'm running into a situation where the processor is overheating and shutting down. I've got a bunch of OPiZero's, and on those I'm used to the kernel automatically throttling the CPU frequency down and/or shutting off cores in response to rising CPU temps -- but I'm not seeing that happen on the PC2 -- it just stays at max CPU speed until it overheats and shuts down. Is there a way to enable that same behavior on the PC2? (I'd rather it throttle down the CPU frequency instead of overheat...)