Jump to content

mikaey

Members
  • Posts

    11
  • Joined

  • Last visited

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

  3. On 12/21/2019 at 7:07 AM, martinayotte said:

    Are you sure that the above log is coming from SDCard U-Boot and not from eMMC U-Boot ?

     

    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.

  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?

  5. 3 hours ago, martinayotte said:

    EDIT2: To boot from SDCard, you will have to find TP50265 and TP50272 test points and short them together, that will disable the eMMC.

    No luck.  These are the two contacts we're talking about, right?  (Stole this from Xunlong's manual)

    image.thumb.png.ca8ff2f7c9c14cef41471e1d1f6ca2cc.png

     

    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.

  6. 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:

     

    image.thumb.png.7312c4045435e287ef825bfcd40c13cd.png

     

    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:

     

    79516989_2543533189260034_2722485103560228864_n.thumb.jpg.a98755c0604415bc9fa39af5147cd63f.jpg

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

  8. Armbianmonitor:

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

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines