(03-19-2018, 04:49 PM)wirr Wrote: I've had the same issues trying to run any image from emmc (specifically tested with stretch-minimal 0.5.10, 0.5.15 and 0.6.25) on four different 4GB boards. I've flashed the images to SSD using an odroid adapter and also pine64 USB-emmc. With dd (bs=1M) as well as etcher. Bootloader and initrd are loading fine but no rootfs.
The simple solution was to boot from SD-card, write u-boot to SPI flash using ayufans' rock64_write_spi_flash.sh script and then boot again using emmc.
It seems booting from emmc works well if - and only if - u-boot is run from SPI flash.
Except, and it's a big except, isn't the rock64 boot order eMMC -> SPI NOR Flash -> SD card -> USB? As stated on p14 of the chip TRM?
So I can appreciate that something might be happening when flashing the SPI, but it sounds like there may still be something wrong with your eMMC/image if it is actually running u-boot from the SPI when you have a properly imaged eMMC installed and the eMMC bypass jumper not fitted.
(03-18-2018, 09:02 PM)Mentaluproar Wrote: I used etcher on my mac with the eMMC to usb adaptor, but I had to insert it multiple times before my mac saw it. Still, it passed etcher's verification read and I tried that method twice. I am powering it via barrel jack. I tried mages from both here and github.
Just double check that your version of etcher is up to date... I remember seeing reports that from somewhere around the v1.0.0 to 1.2.1 release where it was fixed that there was an issue with verification not actually verifying properly... but not sure if it affected Mac users or not.
So it sounds like it shouldn't be the image, as the xz images (i.e. Github) have checksumming so a bad download *should* break the image and prevent it from being written, and etcher *should* be verifying the write, implying it isn't the writing of the image or a failure on the part of the eMMC, else it wouldn't be verifying...
I'd try what wirr said as it seems to have worked in that instance, but I still think it's covering up some other problem.
Also, try the armhf image, as last I heard it is still preferred to the arm64 one due to stability and compatibility concerns.
Latest (pre-release, experimental): https://github.com/ayufan-rock64/linux-b...mhf.img.xz
Stable: https://github.com/ayufan-rock64/linux-b...mhf.img.xz