• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map






Everything posted by mikaey

  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 I don't put it under any sort of heavy CPU load. But if I start running anything CPU-intensive (such as compiling software), it'll run for a few minutes before rebooting. I suspect that the CPU is overheating and the thermal protection code is tripping -- cause if I run htop while the compile job is going, I can see the CPU temperature rise until it hits 94°C, after which it reboots. It kinda looks like not all of the cores are throttling down -- at the point that it rebooted, the big cores were running at 408MHz, but the LITTLE cores were still running at 1.51GHz. I'm not sure what to do here. I've done a side-by-side comparison of the DTS's for the two, and I can't see any meaningful differences between the two -- but then again, I'm not familiar with DTS's enough to really know what I'm looking at. I've also tried several different kernel versions with no luck. Can anyone give me any pointers?
  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 have to deal with issues like this.
  4. mikaey

    Orange Pi 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. mikaey

    Orange Pi 4

    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, it also spits out a bunch of errors b/c the filesystem is read-only...but whatever.) With the SD card? Here's what I get: �DDR Version 1.14 20180803 In Channel 0: LPDDR4,50MHz CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x4D MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0x1 MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size= LPDDR4,50MHz CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x4D MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CSMR4=0x1 MR5=0x1 MR8=0x8 MR12=0x4D MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 Bus Width=32 Col=10 Bank=8 Row=15/1S=2 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x7MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x7R19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR 0 training pass! channel 1 training pass! change freq to 400MHz 0,1 channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel change freq to 800MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = Boot1: 2018-08-06, version: 1.15 CPUId = 0x0 ChipType = 0x10, SdmmcInit=2 0 BootCapSize=100000 UserCapSize=14910MB FwPartOfmmc0:cmd5,20 SdmmcInit=0 0 BootCapSize=0 UserCapSize=15193MB FwPartOffset=2000 , 0 StorageInit ok = 182421 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 GPT 0x3190d20 signature is wrong LoadTrust Addr:0x4000 No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0xa69c4 RunBL31 0x10000 NOTICE: BL31: v1.3(debug):f947c7e NOTICE: BL31: Built : 20:19 BTW -- I didn't have to connect TP50625 to anything to get it to boot off the SD card. So...next step -- maybe try to build a new U-Boot?
  6. mikaey

    Orange Pi 4

    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. mikaey

    Orange Pi 4

    Yay! /s Ok, let me give that a shot.
  8. mikaey

    Orange Pi 4

    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 "rk3399-mid" that appears in device manager. I tried grabbing the image for the OPi RK3399, flashing that to an SD card, and trying to boot from that. I still get garbage, it takes less than 30 seconds for things to calm down, and I don't get any device showing up in device manager. So the question is, has anyone else run into this? If so, what do you do about it? Or do I maybe just have a bad USB-to-TTL debugger? Edited to add: Let me just say that Xunlong's manuals aren't much help here w.r.t. figuring out how to hook up the TTL lines. (They show a picture where they've labelled which pins are which, but the labels are all in Chinese -- and I'm a stinking monolingual American.) But I was able to figure out which one was the ground pin by looking at the traces on the board/using a multimeter. As far as the TX/RX lines -- the configuration I have them in is the only one that produces any data at all:
  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.xz >.config Step 3: Download the attached patch and apply it: $ patch -p1 <OrangePiPC2.patch Step 4: Build the new DTB: $ make dtbs You should find your new DTB under arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dtb. Step 5: Copy the new DTB into your DTBs folder: $ sudo cp arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dtb /boot/dtb/allwinner Step 6: Reboot! $ sudo reboot The PC2 will now throttle automatically when temps start getting too high! OrangePiPC2.patch
  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...)