Jump to content

Recommended Posts

Posted (edited)

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

Edited by mikaey
Added note about how I have the TTL debugger hooked up
Posted
1 hour ago, mikaey said:

Or do I maybe just have a bad USB-to-TTL debugger?

Which baud rate did you choose ?

All RockChip SoC are defaulting to 1500000 baud ...

 

EDIT : Sorry, I didn't look at your screenshot right ...

So, maybe the eMMC has Android installed by default and choose a different baud rate.

This Android U-Boot maybe doesn't provide option to stop and boot from eMMC.

 

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

Posted
54 minutes ago, martinayotte said:

you will have to find TP50265 and TP50272 test points and short them together

Yay! /s

 

Ok, let me give that a shot.

Posted
4 minutes ago, mikaey said:

Ok, let me give that a shot.

I've done that the first time I got OrangePi-RK3399 using a twesser, holding it carefully, while pluging the power.

Once Armbian U-Boot is installed on eMMC, you won't need to do that again, since this U-Boot allowed to be stop at command prompt, you can then switch to SDCard using "setenv devnum 1; run mmc_boot".

I've not done it on OPi4 since I didn't received mine yet ...

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

Posted
18 minutes ago, mikaey said:

No luck.  These are the two contacts we're talking about, right?

I don't know since I didn't received my board yet ...

The important test point is TP50265, the other one is GND, but GND could be find elsewhere.

So, you can get an alligator cable attach to some other GND and on the other end use an attached needle to touch TP50265.

Posted

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?

Posted
13 hours ago, mikaey said:

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

 

Let me help to translate :)

 

TTL.png

Posted
14 hours ago, mikaey said:

BTW -- I didn't have to connect TP50625 to anything to get it to boot off the SD card.

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

Because eMMC has the priority against SDCard ... Except if you short TP50265 ...

Posted
On 12/21/2019 at 4:07 PM, martinayotte said:

Because eMMC has the priority against SDCard

Maybe I'm wrong, but on all the RK33xx I've seen, the priority is SD card over eMMC. The primary idbloader is taken from eMMC and everything else starts using from SD card.

Posted
11 hours ago, gounthar said:

Doesn't work that way on my two OrangePi RK3399, but it's that way on my Renegade Elite.

It is interesting to look at the implementation of this option. Show the system startup UART log from eMMC (without SD card connection) and the second system startup log from SD card.

Posted
22 hours ago, balbes150 said:

The primary idbloader is taken from eMMC

That is why ... If the original primary idbloader isn't looking at presence of SDCard, there is no other choice of disabling the eMMC.

Posted
16 hours ago, martinayotte said:

If the original primary idbloader isn't looking at presence of SDCard, there is no other choice of disabling the eMMC

I have not seen such an option yet (blocking the launch exclusively for eMMC). So I am interested to look at the UART log with such a lock.  :)

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

Posted
On 12/21/2019 at 1:16 AM, mikaey said:

I ordered an Orange Pi 4 a couple weeks ago, and it showed up on Wednesday. 

Are you able to get display from the hdmi output?

I got mine too. Run debian & ubuntu using orangepi image. Got no display from hdmi although the os boot up and running :( 

Posted

After some tests,  I think orangepi image not supporting wide screen monitor.

hdmi - wide screen monitor : no display

hdmi - 16-9 monitor : ok

hdmi - dvi-  16-9 monitor  : ok

hdmi - vga -  16-9 monitor  :  no display

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines