Rock64 4Gb variant bricked

[magare]

oh, I forgot totally to say that you need to attach USB cable into the OTG port! I told I did it with another rockchip board. and to my shame I cannot say now what exactly of them is OTG. you need to find it out. it's important.
But now when I looked into the rockchips' boot sequence, it doesn't look as optimistic as I thought. because USB OTG interface is tried at the end if nothing succeeded, oppositely to what I thought. Fortunately, for rk3328, but NOT for rk3399, ROM code tries eMMC first. So preparing a properly flashed eMMC module could save your board. If the problem is in the partially working/screwed up SPI NOR flash code.
For rk3399, spi is checked before eMMC and SD which is uh oh. because it can brick the board.
Forget about the rkdevtools, in short, :lol: use an eMMC module. if that doesn't work (but don't be hasty). that means the problem is not in SPI NOR flash.

Thanks for all the suggestions.

The top USB on the board is the OTG one.
I don't think I can try that eMMC port as I don't have a eMMC drive.

Looks the board is pretty well bricked already so the next step is towards the rubbish bin. :-)


Thanks for your time.

[z4v4l]

don't give up. try rkdevtools. the problem with it I cannot help you much (because I am not yet familiar with the Rock64 way of doing it) is what is needed to enter that MASK ROM mode or how rockchip calls it. This link talks about how to get into that mode having FW somewhere. for SPI you need "to short spi signal to GND". On my settopbox the job was done by holding some magical "fw upgrade button" at the power on for some time. On Rock64 I am sure there is the way too. rkdevtool utility connects to the board and hopefully is able to cammand rom code to erase that freaking NOR flash.

[magare]

It sounds difficult.

In the state where the serial console is connected, there are the following disadvantages.

TX from the serial console becomes the voltage source ("rock 64" RX)
A small amount of voltage will remain even when the power is turned off.
Since the residual voltage value depends on the individual difference of "rock 64" and the driving ability of "TX"
There are reports that due to the above, reset does not work well and "boot" fails.

If you are lucky (unless it is broken), you still have the possibility of "booting" by removing the serial console TX.

For details, please refer to.
https://forum.pine64.org/showthread.php?tid=5008
- -
I do not have any more information that I know is useful to you.
I wish you good luck.

Yahooooo ... 

I can see the board is alive :-)

I see booting messages .... Got a login prompt ....

[magare]

It sounds difficult.

In the state where the serial console is connected, there are the following disadvantages.

TX from the serial console becomes the voltage source ("rock 64" RX)
A small amount of voltage will remain even when the power is turned off.
Since the residual voltage value depends on the individual difference of "rock 64" and the driving ability of "TX"
There are reports that due to the above, reset does not work well and "boot" fails.

If you are lucky (unless it is broken), you still have the possibility of "booting" by removing the serial console TX.

For details, please refer to.
https://forum.pine64.org/showthread.php?tid=5008
- -
I do not have any more information that I know is useful to you.
I wish you good luck.

Yahooooo ... 

I can see the board is alive :-)

I see booting messages .... Got a login prompt ....

Thinks guys.

So what I did was:

1. Power off the board
2. Short pin 20 and 21 to skip the spi loading.
3. Inserted an SD card with stretch-minimal-rock64-0.7.9-1067-arm64.img.xz flushed on.
4. connect Rx and ground to the Serial to TTL cable
5. Power on the card
6. Watch all the booting messages on the console
7. SSH to the board.
8. Have a beer and burp loud.
9. That is it folks.

Just not sure if I need to have 20 and 21 short all the time or I shall try to fix the SPI u-boot.

Will see and will post any news.

Thanks a lot for the help you guys.

Cheers!

---

If you are curious why I can't flush the SPI here is the output:

DDR version 1.13 20180428
ID:0x805 Y
In
LPDDR3
786MHz
Bus Width=32 Col=11 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=4096MB
ddrconfig:7
OUT

U-Boot SPL 2017.09-g03a332b (May 27 2018 - 18:34:41)
setup_ddr_param 1
booted from SD
Trying to boot from MMC2
NOTICE: BL31: v1.3(debug):9d3f591
NOTICE: BL31: Built : 14:39:02, Jan 17 2018
NOTICE: BL31:Rockchip release version: v1.3
INFO: ARM GICv2 driver initialized
INFO: Using opteed sec cpu_context!
INFO: boot cpu mask: 1
INFO: plat_rockchip_pmu_init: pd status 0xe
INFO: BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR: Error initializing runtime service opteed_fast
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x200000
INFO: SPSR = 0x3c9


U-Boot 2017.09-g03a332b (May 27 2018 - 18:34:56 +0000), Build: jenkins-linux-build-rock-64-239

Model: Pine64 Rock64
DRAM: 4 GiB
MMC: rksdmmc@ff520000: 0, rksdmmc@ff500000: 1
*** Warning - bad CRC, using default environment

In: serial@ff130000
Out: serial@ff130000
Err: serial@ff130000
Model: Pine64 Rock64
misc_init_r
cpuid=55524b5030363030300000000015210a
serial=8377a0df90b44e3
Net: eth0: ethernet@ff540000
Hit any key to stop autoboot: 0
Card did not respond to voltage select!
mmc_init: -95, time 9
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:6...
Found U-Boot script /boot.scr
reading /boot.scr
268 bytes read in 1 ms (261.7 KiB/s)
## Executing script at 00500000
SF: unrecognized JEDEC id bytes: 00, 00, 00
Failed to initialize SPI flash at 0:0 (error -2)
No SPI flash selected. Please run `sf probe'

==================================

[t4_4t]

I guessed from the following two writes of you,
that it is in a serious situation that can not even get the "u-boot" log.
Is it now that you were able to get out of that situation?

> Looks like the board is bricked.
> TTL serial to UART on 6, 8, 10 does not show anything.

If so, I think that the next step you need is to erase "SPI-FLASH-ROM".
What are the steps you need next?

---
*)
I am not a resident belonging to the English-speaking country
Therefore, if difficult expressions (such as emotional expressions etc.) are used,
I can not understand their true intention.

[magare]

I guessed from the following two writes of you,
that it is in a serious situation that can not even get the "u-boot" log.
Is it now that you were able to get out of that situation?

> Looks like the board is bricked.
> TTL serial to UART on 6, 8, 10 does not show anything.

If so, I think that the next step you need is to erase "SPI-FLASH-ROM".
What are the steps you need next?

---
*)
I am not a resident belonging to the English-speaking country
Therefore, if difficult expressions (such as emotional expressions etc.) are used,
I can not understand their true intention.

Yes, It may sound a bit confusing but no mater what I as not able to boot the board until I connected the TTL to TX and earth and disconnected RX , In that mode you can only monitor the log messages but cannot have any input (if I am not mistaken). That did some something and made the board boot or I just did not realise before the board is actually able to boot ( I was monitoring the DHCP log on my server for a DHCP request on the MAC address).

The board now boots with the 21 and 20 pins short and that is fine with me. The only issue I see so far is that there is no activity LED on the NIC.

I have also attempted to erase and re-flash the SPI ROM without success and the log messages are posted in my previous post,

Looks like either the image files I used are corrupt (but that is ruled out as I tried with another version of the image) or the board just can't boot from spi image files. I can't think of anything else.

Thanks a lot for you help. Much appreciated.

Cheers

[t4_4t]

OK.
Currently, I will proceed with the premise that you are logged in and able to operate.

To clarify the story, The "OS-Image" to be used is
limited to "stretch-minimal-rock64-0.7.9-1067-arm64.img.xz", that is presented earlier.

---
The following explains flash erasing and writing concretely
After logging in, unclamp Pin 21 and Pin 20.
All operations are done with root privilege.

The time required for work is,
"Erase" about 15 seconds, and "Write" about 10 seconds.


"Erase"

Code:

# ls /dev/mtd*
ls: cannot access '/dev/mtd*': No such file or directory

# enable_dtoverlay mtd spi@ff190000 disabled
 ....(message out)

# enable_dtoverlay mtd spi@ff190000 okay
 ....(message out)

# ls /dev/mt*
/dev/mtd0  /dev/mtd0ro  /dev/mtdblock0

# flash_erase /dev/mtd0 0 0

"Writing"

Code:

# dd of=/dev/mtd0 if=./xxx.img bs=4K

*If xxx.img is necessary, pick it directly from u-boot-rockchip-rock64-xxx.deb of the following url and use it.
https://github.com/ayufan-rock64/linux-u-boot/releases
 Example)
 "u-boot-rockchip-rock64-2017.09-rockchip-ayufan-1033-gdf02018479.deb"

"Erase & Writing"

Code:

# mkdir u-boot; cd u-boot;
# wget https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rockchip-ayufan-1033-gdf02018479/u-boot-rockchip-rock64-2017.09-rockchip-ayufan-1033-gdf02018479.deb

# dpkg -x u-boot-rockchip-rock64-2017.09-rockchip-ayufan-1033-gdf02018479.deb ./tmp
# find ./tmp -name "*.img"
./tmp/usr/lib/u-boot-rock64/rksd_loader.img

# flash_erase /dev/mtd0 0 0
# dd of=/dev/mtd0 if=./tmp/usr/lib/u-boot-rock64/rksd_loader.img bs=4K

good luck.

---

Sorry, it was a mistake again.
x "stretch-minimal-rock64-0.7.9-1067-arm64.img.xz" -> o "bionic-minimal-rock64-0.7.9-1067-arm64.img.xz"

[magare]

OK.
Currently, I will proceed with the premise that you are logged in and able to operate.

To clarify the story, The "OS-Image" to be used is
limited to "stretch-minimal-rock64-0.7.9-1067-arm64.img.xz", that is presented earlier.

---
The following explains flash erasing and writing concretely
After logging in, unclamp Pin 21 and Pin 20.
All operations are done with root privilege.

The time required for work is,
"Erase" about 15 seconds, and "Write" about 10 seconds.


"Erase"

Code:

# ls /dev/mtd*
ls: cannot access '/dev/mtd*': No such file or directory

# enable_dtoverlay mtd spi@ff190000 disabled
 ....(message out)

# enable_dtoverlay mtd spi@ff190000 okay
 ....(message out)

# ls /dev/mt*
/dev/mtd0  /dev/mtd0ro  /dev/mtdblock0

# flash_erase /dev/mtd0 0 0

"Writing"

Code:

# dd of=/dev/mtd0 if=./xxx.img bs=4K

*If xxx.img is necessary, pick it directly from u-boot-rockchip-rock64-xxx.deb of the following url and use it.
https://github.com/ayufan-rock64/linux-u-boot/releases
 Example)
 "u-boot-rockchip-rock64-2017.09-rockchip-ayufan-1033-gdf02018479.deb"

"Erase & Writing"

Code:

# mkdir u-boot; cd u-boot;
# wget https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rockchip-ayufan-1033-gdf02018479/u-boot-rockchip-rock64-2017.09-rockchip-ayufan-1033-gdf02018479.deb

# dpkg -x u-boot-rockchip-rock64-2017.09-rockchip-ayufan-1033-gdf02018479.deb ./tmp
# find ./tmp -name "*.img"
./tmp/usr/lib/u-boot-rock64/rksd_loader.img

# flash_erase /dev/mtd0 0 0
# dd of=/dev/mtd0 if=./tmp/usr/lib/u-boot-rock64/rksd_loader.img bs=4K

good luck.

---

Sorry, it was a mistake again.
x "stretch-minimal-rock64-0.7.9-1067-arm64.img.xz" -> o "bionic-minimal-rock64-0.7.9-1067-arm64.img.xz"

Perfect !!! 

After enabling the device tree overlay and re-flashing the SPI area everything works fine again !!!

Thank you so much for your time and effort !!!

Cheers

[t4_4t]

Unfortunately, since two troubles simultaneously occurred,
I think that I got stuck in the depth.

1. flashing "SPI-FLASH-ROM" trouble.
2. boot issue (When connected Serial-Console:TX to rock64:RX)
---
For section 2, its workaround is also described at
  https://forum.pine64.org/showthread.php?tid=5008
But, it may be difficult for someone who does not have hardware experience.

Anyway, Congratulations.

[magare]

Unfortunately, since two troubles simultaneously occurred,
I think that I got stuck in the depth.

1. flashing "SPI-FLASH-ROM" trouble.
2. boot issue (When connected Serial-Console:TX to rock64:RX)
---
For section 2, its workaround is also described at
  https://forum.pine64.org/showthread.php?tid=5008
But, it may be difficult for someone who does not have hardware experience.

Anyway, Congratulations.