Rock64 4Gb variant bricked
#11
(09-07-2018, 05:02 PM)z4v4l Wrote: 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.
  Reply
#12
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. Big Grin 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.
  Reply
#13
(09-07-2018, 05:08 PM)t4_4t Wrote: 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 ....
  Reply
#14
(09-07-2018, 09:39 PM)magare Wrote:
(09-07-2018, 05:08 PM)t4_4t Wrote: 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'

==================================
  Reply
#15
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.
  Reply
#16
(09-08-2018, 03:19 PM)t4_4t Wrote: 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
  Reply
#17
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"
  Reply
#18
(09-08-2018, 05:28 PM)t4_4t Wrote: 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
  Reply
#19
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.
  Reply
#20
(09-08-2018, 10:25 PM)t4_4t Wrote: 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.

Wink
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
Shocked Rock64 - Reboots after few minutes addezai 2 181 04-22-2021, 07:03 PM
Last Post: addezai
  Python GPIO Library for the Rock64 (R64.GPIO) Leapo 36 35,108 04-17-2021, 08:59 AM
Last Post: theophile
Question Hardware issues with Rock64 grobbs 10 905 04-08-2021, 05:24 AM
Last Post: t4_4t
  Rock64 Long Term stability ramprasad 4 1,424 03-16-2021, 07:23 PM
Last Post: Rocklobster
  Rock64 No Audio - Solved wbecks 11 14,404 03-15-2021, 03:15 PM
Last Post: lowry
  Safest way to send shutdown signal to headless Rock64 SMB server? bmurphr1 3 841 03-14-2021, 06:01 PM
Last Post: clach04
  Rock64 as a router (OpenWRT,etc) bob-anon 2 1,337 03-12-2021, 01:16 AM
Last Post: arkadione
  Rock64 enable 1-wire to read DS18B20 or Dallas temperature sensor Perry 2 1,014 02-12-2021, 08:02 PM
Last Post: Perry
  Will Mobian Run On Rock64? Porcupine 1 490 01-13-2021, 12:39 PM
Last Post: tophneal
  Rock64 v2 as Openmediavault server - buffers / shutdown problems helpmerock 2 858 12-29-2020, 09:46 AM
Last Post: helpmerock

Forum Jump:


Users browsing this thread: 3 Guest(s)