When I tried flashing the latest release OpenMediaVault 64bit image to emmc, I got a never ending stream of sector errors. It stopped when I put in an sd card and tried booting again. Later, I connected my external hard drives and UPS. The thing kept redecting all USB devices over and over, and never completing a boot.
I tried booting off microSD withthe Sd to eMMC image, and the first time, it loaded and couldn't complete the dd. I rebooted and did it again, without disconnecting power and this time it worked, but rebooted to the above issues again.
Is the rock64 board still not ready for prime time yet? Do I have a bad eMMC? What is the average airspeed velocity of an unladen swallow?
(03-18-2018, 08:39 PM)Mentaluproar Wrote: When I tried flashing the latest release OpenMediaVault 64bit image to emmc, I got a never ending stream of sector errors. It stopped when I put in an sd card and tried booting again. Later, I connected my external hard drives and UPS. The thing kept redecting all USB devices over and over, and never completing a boot.
I tried booting off microSD withthe Sd to eMMC image, and the first time, it loaded and couldn't complete the dd. I rebooted and did it again, without disconnecting power and this time it worked, but rebooted to the above issues again.
Is the rock64 board still not ready for prime time yet? Do I have a bad eMMC? What is the average airspeed velocity of an unladen swallow?
Ah, but is that the African or European swallow... that is the question!
So, some more detail is needed in order to start working out what is going on. How are you powering the rock64? If via the power adapter and barrel jack, make sure it is plugged in properly... I noticed in another thread someone commented that they had issues and unplugged the connector and plugged in back in... probably wasn't plugged in firmly the first time...
Which image are you actually using? And how are you writing it? Are you using the pine64 installer? Or are you downloading from https://github.com/ayufan-rock64/linux-build/releases and using Etcher, dd, etc? If it's the pine64 installer method, I can't comment as to robustness /validity of the image as I haven't used those images of late.
As far as is it ready for prime time... for general SBC usage, then yes, it is ready for a lot of stuff... I have just recently spun one of my rock64s back up again and am running things like nextcloud and plex server via docker without any issues at all other than ones caused by the PBKAC... 
Probably worth testing the eMMC to ensure there isn't an issue with it also... not sure of the best method... maybe reformatting and partitioning it so it is just single partition, and then running f3 across it? https://fight-flash-fraud.readthedocs.io/en/stable/ There is probably some sort of bulk read and write that can be done with dd or some other tool, but don't know it off the top of my head.
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.
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.
03-19-2018, 07:36 PM
(This post was last modified: 03-19-2018, 08:23 PM by pfeerick.)
(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
pfeerick, that's actually a very good point you're making - stupid me missed that.
A serial output capture indeed confirms that the board is booting from emmc directly and not using the bootloader from SPI flash. Nevertheless the presence of some boot code in the flash seems to influence the boards ability to boot from emmc.
Unfortunately I cannot reproduce the factory default conditions. When I try to boot from emmc after running ayufans 'rock64_erase_spi_flash.sh' the system continues to boot which definitely wasn't the case before having it flashed the first time.
The boot log doesn't provide many pointers to me although the 'Card did not respond to voltage select!' does seem a little suspicious.
I've uploaded the bootlog to https://pastebin.com/Nz6Yh1nn.
03-22-2018, 07:53 PM
(This post was last modified: 03-22-2018, 08:19 PM by Mentaluproar.)
I tried again with an SD card and removed the eMMC. It booted without the weird errors, but it cannot connect to the network. It gets an IP and that's as far as it will go. This is still the 64 bit version I'm poking around with.
EDIT: Tried again with 32 bit on microsd. It boots but is unstable. It cannot get time from NTP or run apt update.
(03-22-2018, 07:53 PM)Mentaluproar Wrote: I tried again with an SD card and removed the eMMC. It booted without the weird errors, but it cannot connect to the network. It gets an IP and that's as far as it will go. This is still the 64 bit version I'm poking around with.
EDIT: Tried again with 32 bit on microsd. It boots but is unstable. It cannot get time from NTP or run apt update.
Try the 'stable' armhf/32bit version => https://github.com/ayufan-rock64/linux-b...mhf.img.xz
did that. That's what the EDIT was about.
(03-23-2018, 05:11 PM)Mentaluproar Wrote: did that. That's what the EDIT was about.
Wasn't sure which version you had actually tried as you said you'd tried a 32bit build but didn't say which one (i.e. 0.5.15 OMV armhf or the one I linked earlier) 
So, we have ascertained so far that you: - are powering a rock64 using the official power supply using the barrel connector, so shouldn't be suffering from undervoltage/underpowering issues
- are getting sector errors when you use the eMMC to boot, but not SD boot, when writing the _same_ image to both the SD card and eMMC (using a USB-eMMC adapter) using etcher on Mac and are not getting verification errors, and are using a version of Etcher newer than 1.2.1 to ensure the false verification bug isn't present
- have also tried the SD to eMMC image, and on the second attempt it was successful (it failed the first time), but it behaved no differently to writing the image directly to the eMMC via etcher
- have tried both the pre-release 0.6.25 64 bit build and the armhf 0.5.15 builds on the eMMC and still get the same sector error images
- are having issues with re-detecting USB devices when you do boot the when you do boot from the SD card
Is all of this correct? The details are important, as if anything is wrong here I/we don't have a correct baseline to work from in identifying what the issue here is.
Can you provide the log messages of these 'sector errors'? Also, the 're-detecting' messages? Perhaps also a full boot log, in order to actually see what is going on? probably using a pastebin service like https://paste.ubuntu.com/ as they'll probably be longer than the forum message limit.
|
