Jump to content

Rock64 nightly image


matteobp

Recommended Posts

Hi all.

 

I have a Rock64 board with 1GB RAM.


I downloaded this image
https://dl.armbian.com/rock64/Ubuntu_xenial_default_nightly.7z
and I wrote it on the SD card (Samsung EVO 16GB) using both Etcher and dd command.
But when I power the board, all 3 leds light up and remains on, nothing else happens.

 

I have the same behaviour with the 0.6.0 stretch-minimal image downloaded here
https://github.com/ayufan-rock64/linux-build/releases
The only images that works are the 0.5.10 downloaded here
https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.10
What's wrong? I can exclude problems with power supply (I bought the one they suggested on their site, 5V 3A) and with SD card because I have no problem with 0.5.10 image. I tested both xenial-mate and stretch-minimal (with the XFCE4 desktop environment installed later) images without problems.

 

Thanks in advance.
Matteo

 

Link to comment
Share on other sites

I've had zero problems with my Rock64/4GB on the 171121 nightly build

rock64:~# cat /etc/armbian-release
# PLEASE DO NOT EDIT THIS FILE
BOARD=rock64
BOARD_NAME="ROCK64"
VERSION=5.34.171121
LINUXFAMILY=rk3328
BRANCH=default
ARCH=arm64
IMAGE_TYPE=nightly
BOARD_TYPE=wip
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image

 

Link to comment
Share on other sites

Hi.

I've download the image built on 21/11, but it doesn't still work. I checked also the sha256 code to be sure that the image is not corrupted.

Very strange. Did you burn the SD with Etcher?

I think I have to try with Serial Console, but I have no usb to serial ttl bridge adapter. I want to buy a "CH340g usb to serial ttl bridge adapter". In this post

https://forum.pine64.org/showthread.php?tid=5029

the connection is done with a Pinebook, but I think I can use any PC/notebook, isn't it.

Thanks for support.

Matteo

 

Link to comment
Share on other sites

55 minutes ago, tkaiser said:

 

If this was on Linux then forget about Etcher (and always forget about dd of course). On Linux Etcher is as bad as dd and simply broken since it does NOT verify what it writes (learned this just a few days ago).

 

How can I write an image on SD card with Linux? For my current Armbian on Orange Pi Plus I have always used dd, or dc3dd if I want to see the progress.

For rock64, other tools are suggested, like Etcher and PINE64 Installer (based on Etcher).

I tried dd, Etcher and PINE64 Installer, without success.

By the way, Etcher and PINE64 Installer have an options for verifying.

Can you suggest me another way to burn the rock64 armbian image on SD Card? If needed, I have also Windows system.

Thanks

Matteo

 

 

Link to comment
Share on other sites

Just now, tkaiser said:

 

Then please use Etcher on Windows (again: Etcher on Linux is currently as crappy as dd or Win32DiskImager since NOT IMPLEMENTING VERIFY)

 

Ok, perfect. I'll try and let you know.

Thanks very much

Matteo

 

Link to comment
Share on other sites

No change. :(

I used Etcher on Windows to write the SD card: it doesn't start; all leds on, no hdmi output.

I think I have to wait for the "usb to serial ttl bridge adapter" (already ordered) and check via serial console what is happening.

 

Link to comment
Share on other sites

By the way, looking at the guthub quote, it seems that Etcher does the verifcation on Windows "right" only accidentally, because still they don't specify a very needed in the case FILE_FLAG_NO_BUFFERING flag (not only for the proper verification but for avoiding cash flooding with huge image files nobody will need there more). It works only maybe because Windows flushes cached files frequently for removable devices or doesn't cash large files for them at all (some people love pull off USB thumb drives out in a "surpise removal" fashion).

 

But what's the point of that verification anyway? Aren't data verified at the lower level of disk I/O during writing? For example SD does CRC on every data block, even on commands and responses. Ah, I got it, memory bit flops, right? from the Sun wind radiation. :D

Link to comment
Share on other sites

3 hours ago, valant said:

Ah, I got it, memory bit flops, right? from the Sun wind radiation.

I built a cosmic ray detector once, good chance to play with photomultiplier tubes.  However it's hard to be sure unless you've tuned it right, random gamma events from the long decay chain of Radon, for instance, can make a mess of your data and make you think the cosmos is even noisier than it really is.  The important part about them though, is that they don't come from here, they also don't come from the sun, by and large.  And bit flips in extremely high density media has a lot more to do with the probability of an electron existing where you think it does, or not. 

 

Google things like "hot carrier injection" (Safe for work, I promise ;)), and electron tunneling.  Just because we will it to be so with our machines, sometimes nature gives us a hand gesture we wouldn't want our children to see.  And sometimes, the carriers don't stay "stuck" in jail where they belong.

Link to comment
Share on other sites

8 hours ago, valant said:

But what's the point of that verification anyway?

To catch write errors that are not reported to the writing program.

 

8 hours ago, valant said:

Aren't data verified at the lower level of disk I/O during writing?

Please don't try to tell this to manufacturers of low-end SD cards and USB thumb drives. Writing to block devices doesn't have any feedback mechanism that would ensure that data was written correctly. And while some SD cards were becoming read-only after detecting internal issues, other cards just silently failed to overwrite specific blocks.

 

I use a custom write-with-verify procedure integrated with the Armbian build system, and while when I had issues with the card reader writing was aborted with I/O error, writing to bad SD cards can only be detected by reading back and checksumming the data.

Link to comment
Share on other sites

I think in my case the problem is not the writing: 2 writes with Etcher on Linux and 2 writes with Etcher on Windows with verification on.

Moreover, when I write the ayufan image v. 0.5.15 the board works, while I have the same problem with 0.6.x :huh: :( .

I think there is something missing/wrong with my board. Is there something like "a firmware" to be updated? AFAIK, the image contains everything I need.

Thanks

 

 

Link to comment
Share on other sites

17 hours ago, matteobp said:

Moreover, when I write the ayufan image v. 0.5.15 the board works, while I have the same problem with 0.6.x :huh: :( .

 

I got the same Problem with my rock64  4gb. 
As of today the available Image are all not finished... ayufan image v. 0.5.15 only works only with my Samsung TV but not with my benq Full HD Monitor via hdmi o only get 800x600 resolution.
The 0.6x image wont boot. and the exsisitng 0.5x image won't upgrade to this new build.
I hope they push new builds soon.

Link to comment
Share on other sites

Maybe it's just an issue with miniloader at 0x40 or the shity trust.img - this thing make a 4gb file to write 4MB and i don't understand how it's a feature (i can modify uboot without changing trust.img... :/ ) . On my RK3328 4GB device i wasn't able to boot with the ayufans uboot build script but i'm able to boot using ayufans uboot with rockchip build script. Maybe wrong timing for RAM?

Link to comment
Share on other sites

On 12/12/2017 at 8:44 PM, Rar9 said:

The 0.6x image wont boot. and the existing 0.5x image won't upgrade to this new build.

1

 

Both of these behaviours are to be expected. I've not been following pine64/rock64 development for the last 2/3 months, but I looked at the changelog the other day, and I see in the release notes for ayufan's rock64 builds "0.6.0: Highly experimental", so it's probably a known thing that it will break. You'd have to go onto the forum or IRC to find out more. The thing to realise is that it is still marked a pre-release build, and unless their development structure has changed in the last few months, 'pre-release' (in GitHub parlance)  is considered testing' 'latest' (in GitHub parlance)  is considered beta, and the images available from the pine64 website are the more tested 'stable' versions. The update scripts included with those builds will always default to the 'latest', but you can specify the version you want to update to if you want to force the issue. To see which one it will update to automatically, just go to the latest release tag on GitHub ->  https://github.com/ayufan-rock64/linux-build/releases/latest

Link to comment
Share on other sites

Hi.

The "usb to serial ttl bridge adapter" arrived yesterday, and I tried the 20/11/2017 armbian Rock64 image.

This is the output of the console

 

Spoiler

Welcome to minicom 2.7

OPTIONS: I18n                                                                
Compiled on Feb  7 2016, 13:37:27.                                           
Port /dev/ttyUSB0, 19:51:04                                                  
                                                                             
Press CTRL-A Z for help on special keys                                      
                                                                             
DDR version 1.06 20170424                                                    
In                                                                           
LPDDR3                                                                       
786MHz                                                                       
Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=32 Size=1024MB          
ddrconfig:1                             
OUT                                     
Boot1 Release Time: 2017-05-18, version: 2.43
ChipType = 0x11, 130                    
emmc reinit                             
emmc reinit                             
SdmmcInit=2 20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=7580MB
FwPartOffset=2000 , 0
StorageInit ok = 66705
Raw SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit ret = 0, SecureMode = 0
LoadTrustBL
No find bl30.bin
No find bl32.bin
Load uboot, ReadLba = 2000
Load OK, addr=0x200000, size=0x62f84
RunBL31 0x10000
NOTICE:  BL31: v1.4(debug):203444c
NOTICE:  BL31: Built : 03:20:17, Nov 18 2017
NOTICE:  BL31:Rockchip release version: v1.2
INFO:    ARM GICv2 driver initialized
INFO:    plat_rockchip_pmu_init: pd status 0xe
INFO:    BL31: Initializing runtime services
WARNING: BL31: cortex_a53: errata workaround for 835769 was missing!
WARNING: BL31: cortex_a53: errata workaround for 843419 was missing!
WARNING: BL31: cortex_a53: errata workaround for 855873 was missing!
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9


U-Boot 2017.05-armbian (Nov 20 2017 - 03:24:09 +0100)

Model: Rockchip RK3328 Rock64
DRAM:  rockchip_sdram_size ff1005d0 c280
rank 1 col 10 bk 3 cs0_row 15 bw 2 row_3_4 0
size 40000000
SDRAM base=0, size=40000000
1022 MiB
MMC:   rk3328_mmc_set_clk src_clk_div > 127,con_id:32rk3328_mmc_set_clk src_clk_div > 127,con_id:30rksdmmc@ff0
rk3328_mmc_set_clk src_clk_div > 127,con_id:30rk3328_mmc_set_clk src_clk_div > 127,con_id:30rk3328_mmc_set_clt

In:    serial@ff130000
Out:   serial@ff130000
Err:   serial@ff130000
Net:   Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot:  0
rk3328_mmc_set_clk src_clk_div > 127,con_id:32rk3328_mmc_set_clk src_clk_div > 127,con_id:32Card did not resp!
mmc_init: -95, time 13
MMC Device 0 not found
no mmc device at slot 0
rk3328_mmc_set_clk src_clk_div <= 127,con_id:30rk3328_mmc_set_clk src_clk_div > 127,con_id:30rk3328_mmc_set_cK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
2923 bytes read in 25 ms (113.3 KiB/s)
## Executing script at 00500000
Boot script loaded from mmc 1
166 bytes read in 20 ms (7.8 KiB/s)
"Synchronous Abort" handler, esr 0x96000210
ELR:     3ff90fb4
LR:      3ff8f720
x0 : 000000003df63e10 x1 : 0000000044000000
x2 : 00000000000000a6 x3 : 0000000000000000
x4 : 0000000000000014 x5 : 00000000000000a0
x6 : 0000000000000000 x7 : 0000000000000000
x8 : 0000000000000044 x9 : 0000000000000008
x10: 000000003df63e20 x11: 000000003df59e20
x12: 0000000000000000 x13: 0000000000000200
x14: 000000003df4e76c x15: 00000000ffffffff
x16: 0000000000002080 x17: 0000000000000000
x18: 000000003df54e10 x19: 0000000000000000
x20: 0000000044000000 x21: 000000003df63e10
x22: 000000003ffa8c08 x23: 0000000000000000
x24: 0000000000000000 x25: 000000000000000a
x26: 0000000000000001 x27: 00000000000000a6
x28: 0000000000000000 x29: 000000003df4c680

Resetting CPU ...

"Synchronous Abort" handler, esr 0x96000044
ELR:     3ff7a3a4
LR:      3ff7a380
x0 : 00001443000040c8 x1 : 000000000000eca8
x2 : 0000000000000008 x3 : 00000000ff440000
x4 : 000000003df4c348 x5 : fffffffffffffff8
x6 : 000044ff00000000 x7 : 0000000000000003
x8 : 000000000000005c x9 : 0000000000000008
x10: 000000003df4c1dc x11: 000000003df4e890
x12: 0000000000000005 x13: 0000000000001aa8
x14: 000000003df4c29c x15: 000000003df4e890
x16: 0000000000002080 x17: 0000000000000000
x18: 000000003df54e10 x19: 0000000000000000
x20: 0000000000000000 x21: 000000003df63e10
x22: 000000003ffa8c08 x23: 0000000000000000
x24: 0000000000000000 x25: 000000000000000a
x26: 0000000000000001 x27: 00000000000000a6
x28: 0000000000000000 x29: 000000003df4c3b0

Resetting CPU ...

 

 

and it loops on

"

x0  : ...

x2  : ...

...

x28: ...

Resetting CPU ...

"

I hope that this can help.

 

Thanks.

 

Link to comment
Share on other sites

10 minutes ago, matteobp said:

No one can help me?

Why does the armbian image work for some people and doesn't work for other people like me?

 

 

Thanks.

 

Just to recap, the only image that works on your board is ayufan's 0.5.15 stable build?

Link to comment
Share on other sites

No. With the latest version of 0.6.x (I tried with 0.6.13) it works.

So both ayufan 0.5.15 e 0.6.1x works, at least the debian jessie and debian stretch images.

But I was never able to boot the armbian.

Here you can find the output log taken via console.

 

Thanks

 

Link to comment
Share on other sites

9 hours ago, matteobp said:

Why does the armbian image work for some people and doesn't work for other people like me?

 

Google suggests it can be caused by DDR memory timing issues.

Perhaps the timings are marginal, so due to part tolerances, works for some and not for others. It's my theory for my Espressobin board not working with 800/800MHz CPU/RAM speeds but goes perfect on 1200/750MHz.

 

Link to comment
Share on other sites

I know this was a month ago but I just figured out a problem I was having with dd and it might apply. I was using of=/dev/sda1 instead of just /dev/sda  and when I fixed it, it worked. 

 

Etcher is a complete waste of time and most likely is corrupting the partitions on your disks. I don't know why the parrots keep telling people to use that piece of garbage. On windows, win32diskimager is the only thing that works. I use .9 because 1.0 doesn't render correctly on my windows 10. 

 

Link to comment
Share on other sites

1 hour ago, DeterminedOpier said:

On windows, win32diskimager is the only thing that works.

Win32disk imager is the only tool I have had repeatedly corrupt writes.  Do you have any empirical evidence for your claim?  I use etcher everyday with no failures.

Link to comment
Share on other sites

Yea I don't know why Etcher all of a sudden stopped working on me. I may have been this copy of win10. When I first found it I used it exclusively, then all of a sudden I started getting do you want to format this drive after it was done. Then the cards couldn't be ripped back into images to copy to other machines.  I even tried windows dd to copy them to an image.  But as I said, win32diskimage 1.0 doesn't work on this windows either. I had to try .9, which works.  Could just be an oddity in the chip. 

Link to comment
Share on other sites

I also cannot get the board to boot Armbian.
Tried flashing (from win10) with Etcher (latest version), Rufus, win32diskimage, nothing works

 

I have been able to boot other images, just not armbian (eg. DietPi_Rock64-ARMv8-Stretch, / stretch-minimal-rock64-0.6.25-193-arm64.img / jessie-openmediavault-rock64-0.5.15-136-arm64.img etc)

One thing I noticed is that after writing the image I'm unable to unmount the SDCard or see the created paritions like I can do with the other images.  (I checked the SHA256 using 7zip and the file is ok)

 

Here's the last bit I see when using the serial adapter:

    2.274341] Btrfs loaded, integrity-checker=on
[    2.274483] BTRFS: selftest: Running btrfs free space cache tests
[    2.274529] BTRFS: selftest: Running extent only tests
[    2.274558] BTRFS: selftest: Running bitmap only tests
[    2.274594] BTRFS: selftest: Running bitmap and extent tests
[    2.274634] BTRFS: selftest: Running space stealing from bitmap to extent
[    2.276365] BTRFS: selftest: Free space cache tests finished
[    2.276373] BTRFS: selftest: Running extent buffer operation tests
[    2.276374] BTRFS: selftest: Running btrfs_split_item tests
[    2.276463] BTRFS: selftest: Running find delalloc tests
[    2.285914] mmc0: MAN_BKOPS_EN bit is not set
[    2.290133] mmc_host mmc0: Bus speed (slot 0) = 200000000Hz (slot req 200000000Hz, actual 200000000HZ div = 0)
[    2.290913] dwmmc_rockchip ff520000.dwmmc: All phases bad!
[    2.290918] mmc0: tuning execution failed
[    2.290936] mmc0: error -5 whilst initialising MMC card
[    2.299118] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[    2.299196] mmc1: new high speed SDHC card at address e624
[    2.300184] mmcblk1: mmc1:e624 SC32G 29.7 GiB
[    2.302596]  mmcblk1: p1
[    2.733716] BTRFS: selftest: Running btrfs_get_extent tests
[    2.734132] BTRFS: selftest: Running hole first btrfs_get_extent test
[    2.734194] BTRFS: selftest: Running outstanding_extents tests
[    2.734303] BTRFS: selftest: Running qgroup tests
[    2.734306] BTRFS: selftest: Qgroup basic add
[    2.734430] BTRFS: selftest: Qgroup multiple refs test
[    3.102107] rk-vcodec ff360000.rkvdec: parent devfreq retry
[    3.107899] rockchip-dmc dmc: current ATF version 0x101!
[    3.112559] rockchip-dmc dmc: read tf version 0x101!
[    3.118798] rockchip-dmc dmc: ddr_leakage=9
[    3.123389] rockchip-dmc dmc: ddr_leakage-volt-sel=1
[    3.128577] rockchip-dmc dmc: failed to get vop bandwidth to dmc rate
[    3.133560] devfreq dmc: Couldn't update frequency transition information.
[    3.138867] asoc-simple-card hdmi-sound: i2s-hifi <-> ff000000.i2s mapping ok
[    3.165204] asoc-simple-card sound: rk3328-hifi <-> ff010000.i2s mapping ok
[    3.169592] asoc-simple-card sound: snd-soc-dummy-dai <-> ff010000.i2s mapping ok
[    3.175202] asoc-simple-card spdif-sound: dit-hifi <-> ff030000.spdif mapping ok
[    3.179929] rk-vcodec ff360000.rkvdec: parent devfreq is ok
[    3.184053] rk-vcodec ff360000.rkvdec: rkvdec_leakage=9
[    3.187718] rk-vcodec ff360000.rkvdec: rkvdec_leakage-volt-sel=1
[    3.191787] rk-vcodec ff360000.rkvdec: probe device
[    3.195399] rk-vcodec ff360000.rkvdec: vpu mmu dec ffffffc0f5445c10
[    3.199404] rk-vcodec ff360000.rkvdec: allocator is drm
[    3.203069] rk-vcodec ff360000.rkvdec: checking hw id 3410
[    3.207278] rk-vcodec ff360000.rkvdec: init success
[    3.212892] rk808-rtc rk808-rtc: setting system clock to 2018-04-07 23:28:01 UTC (1523143681)
[    3.216858] of_cfs_init
[    3.220243] of_cfs_init: OK
[    3.234324] I : [File] : drivers/gpu/arm/mali400/mali/linux/mali_kernel_linux.c; [Line] : 415; [Func] : mali_module_init(); s rk_ko_ver is '5', built at '16:03:00', on 'Apr  2 2018'.
[    3.243165] mali-utgard ff300000.gpu: mali_platform_device->num_resources = 9
[    3.247302] mali-utgard ff300000.gpu: resource[0].start = 0x0x00000000ff300000
[    3.251501] mali-utgard ff300000.gpu: resource[1].start = 0x0x00000000ff300000
[    3.255669] mali-utgard ff300000.gpu: resource[2].start = 0x0x0000000000000012
[    3.259803] mali-utgard ff300000.gpu: resource[3].start = 0x0x0000000000000013
[    3.263880] mali-utgard ff300000.gpu: resource[4].start = 0x0x0000000000000014
[    3.267912] mali-utgard ff300000.gpu: resource[5].start = 0x0x0000000000000015
[    3.271917] mali-utgard ff300000.gpu: resource[6].start = 0x0x0000000000000016
[    3.275897] mali-utgard ff300000.gpu: resource[7].start = 0x0x0000000000000017
[    3.279810] mali-utgard ff300000.gpu: resource[8].start = 0x0x0000000000000018
[    3.283600] D : [File] : drivers/gpu/arm/mali400/mali/platform/rk/rk.c; [Line] : 617; [Func] : mali_platform_device_init(); tcific_data to platform_device_of_mali.
[    3.291575] mali-utgard ff300000.gpu: gpu_leakage=9
[    3.295287] mali-utgard ff300000.gpu: gpu_leakage-volt-sel=1
[    3.300808] Mali: Mali device driver loaded
[    3.305302] ALSA device list:
[    3.308694]   #0: HDMI
[    3.311947]   #1: I2S
[    3.315128]   #2: SPDIF
[    3.318483] of_dma_request_slave_channel: dma-names property of node '/serial@ff130000' missing or empty
[    3.322467] ttyS2 - failed to request DMA
[    3.326431] Freeing unused kernel memory: 1152K
Loading, please wait...
starting version 237
[    3.429176] devfreq ff300000.gpu: Couldn't update frequency transition information.
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ..Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
[    5.268130] vendor storage:20160801 ret = -1
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - MALERT!  LABEL=linux-root does not exist.  Dropping to a shell!
Rebooting automatically due to panic= boot argument

 

Link to comment
Share on other sites

9 minutes ago, MunkeyBalls said:

I also cannot get the board to boot Armbian.


Which one you can't boot? They (legacy/stable) are tested, nightly builds are automated builds for developers and might not always work.

Link to comment
Share on other sites

28 minutes ago, Igor said:


Which one you can't boot? They (legacy/stable) are tested, nightly builds are automated builds for developers and might not always work.

 

Sorry, forgot to mention :)

 

Armbian_5.42_Rock64_Debian_stretch_default_4.4.124_desktop

Armbian_5.42.180408_Rock64_Debian_stretch_dev_4.16.0-rc6

 

Started with stable which didn't work and then tried latest nightly RC6 which also didn't work.


I think the log I posted was from the latest nightly, want me to retry with the one from the main download page?

Link to comment
Share on other sites

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

Important Information

Terms of Use - Privacy Policy - Guidelines