matteobp Posted November 27, 2017 Posted November 27, 2017 Hi all. I have a Rock64 board with 1GB RAM. I downloaded this imagehttps://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 herehttps://github.com/ayufan-rock64/linux-build/releases The only images that works are the 0.5.10 downloaded herehttps://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
nachoparker Posted November 28, 2017 Posted November 28, 2017 I tried to generate a debian stretch image and I had the same issue. Apparently there's people using this image and it works https://github.com/ayufan-rock64 Hopefully we can get an Armbian image soon!
Christian_ Posted December 3, 2017 Posted December 3, 2017 @matteobp which build are you using? The image built on 21/11 boots correctly on my Rock64 board. Maybe you can extract some info from serial console, as explained here: https://forum.pine64.org/showthread.php?tid=5029
chrisf Posted December 3, 2017 Posted December 3, 2017 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
matteobp Posted December 5, 2017 Author Posted December 5, 2017 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
tkaiser Posted December 5, 2017 Posted December 5, 2017 On 27.11.2017 at 4:36 PM, matteobp said: I wrote it on the SD card (Samsung EVO 16GB) using both Etcher and dd command 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).
matteobp Posted December 5, 2017 Author Posted December 5, 2017 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
tkaiser Posted December 5, 2017 Posted December 5, 2017 4 minutes ago, matteobp said: I have also Windows system Then please use Etcher on Windows (again: Etcher on Linux is currently as crappy as dd or Win32DiskImager since NOT IMPLEMENTING VERIFY)
matteobp Posted December 5, 2017 Author Posted December 5, 2017 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
matteobp Posted December 6, 2017 Author Posted December 6, 2017 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.
TonyMac32 Posted December 7, 2017 Posted December 7, 2017 On 12/5/2017 at 8:22 AM, tkaiser said: 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). Well crap.
valant Posted December 9, 2017 Posted December 9, 2017 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.
TonyMac32 Posted December 9, 2017 Posted December 9, 2017 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. 2
tkaiser Posted December 9, 2017 Posted December 9, 2017 On 7.12.2017 at 1:27 AM, TonyMac32 said: Well crap. Should be fixed now in latest release: https://forums.resin.io/t/etcher-v1-2-1-release/2265 1
zador.blood.stained Posted December 9, 2017 Posted December 9, 2017 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. 1
matteobp Posted December 11, 2017 Author Posted December 11, 2017 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 . 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
Rar9 Posted December 12, 2017 Posted December 12, 2017 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 . 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.
boobypi Posted December 12, 2017 Posted December 12, 2017 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?
pfeerick Posted December 14, 2017 Posted December 14, 2017 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
matteobp Posted January 10, 2018 Author Posted January 10, 2018 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.
matteobp Posted January 15, 2018 Author Posted January 15, 2018 No one can help me? Why does the armbian image work for some people and doesn't work for other people like me? Thanks.
Xalius Posted January 15, 2018 Posted January 15, 2018 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?
matteobp Posted January 15, 2018 Author Posted January 15, 2018 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
chrisf Posted January 15, 2018 Posted January 15, 2018 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.
DeterminedOpier Posted February 20, 2018 Posted February 20, 2018 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.
TonyMac32 Posted February 21, 2018 Posted February 21, 2018 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.
DeterminedOpier Posted February 23, 2018 Posted February 23, 2018 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.
MunkeyBalls Posted April 10, 2018 Posted April 10, 2018 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
Igor Posted April 10, 2018 Posted April 10, 2018 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.
MunkeyBalls Posted April 10, 2018 Posted April 10, 2018 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?
Recommended Posts