Hardware issue overheating while booting and fail to boot

[dukla2000]

This is all intriguing and I wish we could resolve what is wrong. But I would figure a warranty claim on your vendor is the pragmatic route. My reason for coming to this conclusion is the success/failure of the serial connection: success in that you are getting output, failure because it is gibberish. You can aim them at this thread to prove what has been tried!

Re: Bullet64 and dukla2000:
So, I found the serial connection (just to be clear, it is a usb-TTL adapter), and some interesting results were encountered.
First, I followed the the guide from the wiki here (https://forum.pine64.org/showthread.php?tid=6387 ).

I have not done a serial connection myself but everything I have read around the ROCKPro64 indicates that is the best guide and 1.5M is absolutely the correct setting.

I then tried to enter OTG mode, and it looks like the recovery button and the LEDs work. However, the I don't see anything when connected via a usb (tried it in linux and windows) and according to the wiki "In all cases the USB device made available at the host has device ID 18d1:d00d. " That ID does not appear when I use "lsusb" to search the attached usb devices. (If there is a different command I should be using please let me know)

I did this myself last night and then wrote that section in the wiki - yup I did a plain lsusb. Again a success/fail result!! For completeness I used the USB-C connector on my ROCKPro64 so I know that works. But I cannot confirm the top USB2 actually works - I copied that into the wiki from elsewhere and it could be wrong.

On the 1-flash option I also had pcmanfm open, and a few  seconds after the red LED came on the boot and linux-root partitions from my ROCKPro64 appeared in pcmanfm (same as if I plug in a USB disk). Nothing appeared in pcmanfm on the 2, 3 and 4 blink options.

I did have 2nd thoughts afterwards that the 4 blink LED options may only work if you have a ayufan bootable image on either the eMMC or an SDcard when powering on. My to-do list includes a trial with only a blank SDcard - in particular to test if I can get rkflash to work directly for a laugh.

Just in case, I will attempt to erase the spi boot flash as you suggested (as soon as a clean up one of my other sd cards to use during that process), and will update on the results when I have them.

As I was writing the wiki and learning from the schematic and trying to phrase it simply, I think my conclusion is (as per the wiki) that the 2 jumpers are perfectly legit suppression options. If you can try with first disable SPI, then with both could be an option?


A last check: a chap on IRC last night seemed to have a duff ROCKPro64 that would not boot. His observation was that the ethernet transceiver chip (between the RJ45 socket and the CPU, has no number on the wiki exploded diagram) was getting too hot to touch after a few seconds. That is at odds with mine (generally just warm), but may be a common symptom of failure?

[DIDquest]

Not every usb-TTL adapter works with 1500000. I have tested three before i found an working adapter.

But i think your board isn't dead. The last image looks good.

1. Erase SPI or set the jumper.
2. Flash an new image to an working sd-card

But the main part is to get an working UART connection. Without it, it's hard to find the problem.

When I erased the SPI flash (at least I think it was erased, I cant see the register values or view it in some other manner to verify it). I used the u-boot-erase-spi-rockpro64.img.xz image, flashed it to a secondary SD card, and then I inserted it and powered it on. The indicator LED lit up and began flashing in 1 second intervals as described in https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md (Although this process is described for the Rock64, the directory it links to contains versions for the rockpro64, so it should work... right?)   which links to https://github.com/ayufan-rock64/linux-u-boot/releases/tag/2017.09-rockchip-ayufan-1033-gdf02018479

Because this appeared to be working so well, I took that same SD card (used for erasing the spi), and then burned the latest RockPro64 linux image to it. (Part of me was hoping that because this SD card is just a standard 16gb class 10, and not an extended capacity SD card like I was using before, maybe there was a problem with the board recognizing the extended capacity card. I have heard of that sort of thing happening in different contexts, so it was worth a shot). However this had no effect and the LED did not come on this time.

Yup, a working UART connection would be super helpful...

...
I have not done a serial connection myself but everything I have read around the ROCKPro64 indicates that is the best guide and 1.5M is absolutely the correct setting.
...

I then tried to enter OTG mode, and it looks like the recovery button and the LEDs work. However, the I don't see anything when connected via a usb (tried it in linux and windows) and according to the wiki "In all cases the USB device made available at the host has device ID 18d1:d00d. " That ID does not appear when I use "lsusb" to search the attached usb devices. (If there is a different command I should be using please let me know)

I did this myself last night and then wrote that section in the wiki - yup I did a plain lsusb. Again a success/fail result!! For completeness I used the USB-C connector on my ROCKPro64 so I know that works. But I cannot confirm the top USB2 actually works - I copied that into the wiki from elsewhere and it could be wrong.
...
As I was writing the wiki and learning from the schematic and trying to phrase it simply, I think my conclusion is (as per the wiki) that the 2 jumpers are perfectly legit suppression options. If you can try with first disable SPI, then with both could be an option?
...
A last check: a chap on IRC last night seemed to have a duff ROCKPro64 that would not boot. His observation was that the ethernet transceiver chip (between the RJ45 socket and the CPU, has no number on the wiki exploded diagram) was getting too hot to touch after a few seconds. That is at odds with mine (generally just warm), but may be a common symptom of failure?

1. Thanks for confirming the 1.5M baud rate it checks one more thing off the list of possible problems.
2. I used the top USB 2.0 port, but I will try it again with the type c connector just in-case
3. I am not sure that when I tried the 2 jumper suppression, I was doing it correctly. The wiki seemed to say that pins 23 (CLK) and 25 pin (GND) should be connected together. If that is the case, I tried it and it had no effect on the boot behaviour of the SD card. (If I was mistaken, please correct me).
4. I did not try the other flashing modes, but I will give it a shot (just for the sake of curiosity).
5. I allowed the board to heat up again and then touched the chip sitting behind the ethernet jack and it was only peripherally warm. (I think a byproduct of the whole board heating up I think).

As an added treat, I literally just remembered as I was writing this out that one of the other companies that we share our office space with, has several thermal imaging camera modules....so I took some pictures of what happens when I leave the board plugged in (with the fan, which I was powering externally, turned off) for 2 minutes. Please note that the number in the left hand corner is not a temperature value it was a voltage reading coming off the chip, and they didnt have  the conversion calculator handy, so we dont have a temperature to go with it. I doubt any of this will be useful, but I just think it is cool (and something you guys might get a kick out of).

Images 1 and 2 were taken with the heatsink ON
Image 3 is with the heatsink off but the thermal spreading pad still on.

The only think I found surprising was in img1cut.jpg the the PCI bus was hotter than the surrounding components, dispite never having used that port. Although part of me thinks that this would be caused by the tons of lanes that have to go between it and the cpu (or all of the metal pins right there) and the excess plastic which might hold on to the heat longer. I could be wrong about that though.

[dukla2000]

2. I used the top USB 2.0 port, but I will try it again with the type c connector just in-case

Just trying to digest bits of the schematic and it seems to me the 2 OTG ports are connected to the  2 USB3 bits - the USB C and the standard USB-A above it. I do not have a USB-A/USB-A cable so cannot test - if you can check and feedback but methinks the wiki will need a correction.

Fab thermal images

[nJoy.]

Looks like I have same problem, except i never had a chance to boot properly. Brand new board. Just got it yesterday. Any luck on finding solution?