7 7
Burkhard Kneiseler

Odroid XU4 - Ubuntu Xenial doesn't run on eMMC

Recommended Posts

I'm running armbian 5.24 actually on odroid-xu4 with emmc (boot on it and running on it).

Actually, the things i done for that was to go on ameridroid web site and find the subject who talk about "recover emmc boot".

Then from there, for xu4 device, there is an image to download of android-4, then install it on a micro sd card, then put it with emmc on the odroid, boot and wait for led OFF (one minute around...), then power off, remove emmc, install with dd then armbian image, then put back on odroid, switch jumper on emmc boot, and boot... that's all folks. It works great for me.

My image of armbian is very modern (kernel is 4.x...) and is used by openmediavault (kind of easy NAS who can use more than 2TB HDD/partitions, better than max2play who run kodi but can not mount storage device more than 2Tb... for a media station...).

Hope that help people to find a solution (try it and tell us).

Share this post


Link to post
Share on other sites

Thanks Jerome!

 

The eMMC media is booting correctly after following the procedure. But the automatic partition resizing

doesn't seem to work?

 

df -hm

 

shows:

/dev/mmcblk0p1      3703  1366      2267  38% /

 

for a 16 GB eMMC media

 

There is no /boot mount point entry as well...

 

How can I resize the root partition correctly?

 

This is what gparted shows when I plug in the cardreader on my notebook

with gparted booted from a live CD:

Partition    File System   Size        Used      Unused
unallocated  unallocated   4.00 MiB    --        --
/dev/sdb1    ext4          3.70 GiB    1.44 GiB  2.27 GiB
/dev/sdb2    unknown       10.82 GiB   --        --
unallocated  unallocated   150.28 MiB  --      --

 

 

I've taken Jerome's description and put it into a section based form:

 

01. Download the Android-4.4.4... image
    https://dn.odroid.com/5422/ODROID-XU3/Android/4.4.4_Alpha_4.9_May-17-2017/android-4.4.4-alpha-4.9-sd2emmc_installer-odroidxu3-20170517.img.zip
    from https://forum.odroid.com/viewtopic.php?f=53&t=6173

02. Extract the .zip file

03. Attach the micro SD-Card to your computer and flash the image
    android-4.4.4-alpha-4.9-sd2emmc_installer-odroidxu3-20170517.img
    to it

04. Remove power from the XU4
    Attach the micro SD-Card AND the eMMC media to the XU4 and put the
    boot mode selector switch into SD mode

05. Attach power to the XU4
    Let it boot. The blue LED stays on for about a minute. When the blue
    LED goes off or the XU4 shuts itself down, remove power from the XU4 again.
    You won't see any output if you've connected a monitor via HDMI during
    this time!

06. Remove the micro SD-Card AND the eMMC media from the XU4 and attach the eMMC
    media to the computer again.
    Flash your preferred armbian image to the eMMC media.
    E.g. the openmediavault from
    https://sourceforge.net/projects/openmediavault/files/Odroid-XU3_XU4/OMV_3_0_76_Odroidxu4_4.9.28.7z/download

07. Attach the eMMC media to the XU4 again and put the boot mode selector
    switch into eMMC mode. Do not attach the micro SD-Card

08. Attach power to the XU4 and let it boot...

 

 

Share this post


Link to post
Share on other sites
39 minutes ago, highend said:

But the automatic partition resizing doesn't seem to work?

 

Since you're talking about the OMV Armbian variant it is resizing but to 3.7GB by design (that's how @ryeaaron built all his OMV ARM images before and I followed his convention): https://github.com/armbian/build/blob/b0d4931a5bcba66288a4ff6180186699fefcb947/scripts/customize-image.sh.template#L111

 

The remaining capacity is there as /dev/mmcblk0p2 so you can do whatever you want with it (eg. share it with Samba for frequently used data to prevent spinning up sleeping disks or as a btrfs filesystem with maximum transparent file compression to store logs or whatever). If you want 'traditional' Armbian behaviour with rootfs resize to the maximum you would need to remove /root/.rootfs_resize prior to first boot.

Share this post


Link to post
Share on other sites

Thank you tkaiser!

 

I've resized everything manually via gparted now but the next time I'll have to do this procedure (if ever...) I'll

remove the /root/.rootfs_resize before I finally boot up the eMMC media at the end.

Share this post


Link to post
Share on other sites
7 minutes ago, Kosmatik said:

So I just freshly built Debian kernel 4.9.44 and it again doesn't boot from emmc :( 

SD card boots fine.


You need to update boot loader in any case. Recent eMMC cards have updated bootloader and it works out of the box ... we will provide updating eMMC from armbian-config, but it's not implemented yet. You will need to boot once from SD card with attached eMMC and update boot loader on eMMC from menu (or manually). Than you are done and you can either write IMG to eMMC or install via our nand-sata-install utility.

 

BTW. We solved only low level problem and boot loader, once you have the system running on eMMC is being updated.

 

Share this post


Link to post
Share on other sites
18 hours ago, Igor said:


You need to update boot loader in any case. Recent eMMC cards have updated bootloader and it works out of the box ... we will provide updating eMMC from armbian-config, but it's not implemented yet. You will need to boot once from SD card with attached eMMC and update boot loader on eMMC from menu (or manually). Than you are done and you can either write IMG to eMMC or install via our nand-sata-install utility.

 

BTW. We solved only low level problem and boot loader, once you have the system running on eMMC is being updated.

 

 

EDIT: Just compiled 4.9.46 and it worked.

 

Sorry I should've said this. I had 4.9.37 running fine from emmc, updating it to 4.9.44 caused it to not boot.

 

I've tried uncommenting boot.ini setting to update emmc again, but that did not help.

Share this post


Link to post
Share on other sites

I think my question fits in here:

Did anyone try to install rootfs on a hdd using nand-sata-install?

I plan on buying xu4 + cloudshell 2 installing 2 hdds. First I thought I get N eMMC module but user meveric from odroid forum told me, that write speed is better if rootfs is on hdd. Acording to him read and write speed is ~ 130 MB/s if running from hdd. And from eMMC read speed is like 190 MB/s but write speed is waay lower, 35-75 MB/s.

 

Gesendet von meinem ONE E1003 mit Tapatalk

 

 

 

 

Share this post


Link to post
Share on other sites
23 minutes ago, trohn_javolta said:

I plan on buying xu4 + cloudshell 2 installing 2 hdds

 

Good luck! In my humble opinion this is one of the worst combinations possible

 

24 minutes ago, trohn_javolta said:

Acording to him read and write speed is ~ 130 MB/s if running from hdd. And from eMMC read speed is like 190 MB/s but write speed is waay lower, 35-75 MB/s.

.

Funny numbers. Obviously the result from sequential benchmarks. For the rootfs random IO performance is way more important and I would be really surprised if spinning rust can beat Hardkernel's pretty fast eMMC here. But with Armbian it shouldn't matter that much anyway since we use a couple of optimizations to reduce writes to the rootfs anyway (10 min commit interval, /var/log buffered to RAM, on desktop images profile-sync-daemon and browser cache in RAM, on the OMV image -- which is just a Debian next Armbian image with an optimized OMV install on top -- it's even a lot more stuff that will be buffered in RAM and only written to the rootfs every hour or on shutdown/reboot)

 

BTW: https://github.com/armbian/documentation/commit/ba9ca62ced76b46076e7f0cff5f3a01957117105

Share this post


Link to post
Share on other sites

Quick iozone benchmark with Hardkernel's red 16GB eMMC module on ODROID-XU4:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    15188    17623    20108    19593    14499    17071
          102400      16    32269    34309    47927    47609    40564    33184
          102400     512    41923    41838    97742    99609    96272    40443
          102400    1024    41208    41125   100828   101495   100518    40068
          102400   16384    38858    37916   145011   144954   144665    39192

Though my benchmark is somewhat stupid since I'm running OMV on the eMMC transferred with nand-sata-install and using btrfs as filesystem which by default uses transparent file compression (which is another way to reduce wear on the media of course and speeds up writes to disk):

/dev/mmcblk0p3 / btrfs rw,noatime,nodiratime,compress=lzo,ssd,space_cache,commit=600,subvolid=5,subvol=/ 0 0

But on the rootfs the most important performance metric is random IO with rather small blocksizes and HDDs totally suck here for obvious reasons (rotating platters, moving heads, waiting half a rotation on average for a random sector to appear below the drive's heads). This is a 2.5" HDD (7200 rpm) on my HC1 (ext4 formatted). Random IO performance with small block sizes is magnitudes lower than Hardkernel's eMMC:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    11623    12880    16891    17099      668     1155
          102400      16    41366    44853    46099    46464     2577     4961
          102400     512    89816    87068    94534    97074    39159    43801
          102400    1024    87287    84807    91958    98266    56494    55865
          102400   16384    73295    76457    91464    94123    91582    79349

And you should always keep in mind how HDDs work:

  1. They're twice as fast when they're emtpy compared when they're full (detailed explanation)
  2. Especially when used for the rootfs fragmentation can become an issue after some time on a small partition and then performance further drops down

Share this post


Link to post
Share on other sites
45 minutes ago, tkaiser said:

on the OMV image -- which is just a Debian next Armbian image with an optimized OMV install on top -- it's even a lot more stuff that will be buffered in RAM and only written to the rootfs every hour or on shutdown/reboot

 

That's how it looks like:

root@odroidxu4:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             10M     0   10M   0% /dev
tmpfs           399M  6.9M  392M   2% /run
/dev/mmcblk0p3   15G  565M   14G   4% /
tmpfs           997M     0  997M   0% /dev/shm
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
tmpfs           997M     0  997M   0% /sys/fs/cgroup
/dev/mmcblk0p1   56M   21M   31M  41% /boot
tmpfs           997M     0  997M   0% /tmp
folder2ram      997M  6.3M  991M   1% /var/log
folder2ram      997M     0  997M   0% /var/tmp
folder2ram      997M     0  997M   0% /var/lib/openmediavault/rrd
folder2ram      997M  740K  997M   1% /var/spool
folder2ram      997M   15M  983M   2% /var/lib/rrdcached
folder2ram      997M  8.0K  997M   1% /var/lib/monit
folder2ram      997M     0  997M   0% /var/lib/php5
folder2ram      997M  4.0K  997M   1% /var/lib/netatalk/CNID
folder2ram      997M  468K  997M   1% /var/cache/samba
tmpfs           200M     0  200M   0% /run/user/0

Everything with frequent write access is stored in RAM and saved only hourly to eMMC. With Armbian or the Armbian based OMV image normally you won't notice any performance difference whether the rootfs is on a slow SD card, the fast eMMC or a HDD. 

 

Only tasks that force continually 'sync to disk' (eg installing a ton of updates with 'apt upgrade') will perform very differently.

Share this post


Link to post
Share on other sites
3 hours ago, tkaiser said:

 

:o.... so much info in so little link. Thanks for that....For me as a beginner the XU4 Cloudshell 2 combination seemed perfect + on their website they advertise copy speeds via network of ~ 100 mb/s and nothing about loose connections etc..

Well, now I'm exactly where I started off....

Btw. thx also for the insight about sd,hdd and emmc performance. This all confirmes my decision to stay with armbian as os. But now I again don't know which hardware I should use. Pardon me to get off topic but since it seems to me that you're the "diy nas" expert here I want to ask for your advice :rolleyes:

 

I have too much devices lying around (probably you have more lying around :D) and plan to replace them with...well..idealy one SBC and an enclosure:

-) WD My Cloud 6TB, single bay NAS (I'm unhappy with the os, I just needed a new HDD and it was a good offer)
-) "old" 3TB HDD in external USB 3.0 enclosure hooked up to NAS via USB port
-) Hummingboard i2eX (you're probably familiar to that board) working as my home server
-) dirt cheap S905X china box running libreelec working as my media center

I think I will stay with the S905X box, it works really good with libreelec. All other devices should be replaced.

I would like to take my two hdd's, put them in a case along with a SBC and use  this as a NAS/homesever combo. File transfer of ~ 100-110 mb/s via gigabit lan would be really nice.
The homeserver is running dl/torrent servers like transmission, nzbget, jdownloader2 | managers like sickrage,radarr,htpcmanager and also unrar at a decent decompressing speed would be nice.


All of that + NAS functionallity...... Do you think it's doable or am I dreaming of an "egg-laying wool-milk-sow"?

The Rock64 seems promising, but do you think it will be able to handle the homeserver jobs?

 

Share this post


Link to post
Share on other sites
2 hours ago, trohn_javolta said:

the XU4 Cloudshell 2 combination seemed perfect + on their website they advertise copy speeds via network of ~ 100 mb/s and nothing about loose connections etc..

Well, for the +100 MB/s you need a good OS image taking care of settings (those images that don't care about settings/versions perform really low as NAS) and I really hope Hardkernel now ships with a better USB cable to interconnect both devices. If you can solve the USB3 connection hassles then XU4 is not the worst choice to be combined with 2 USB3/UAS capable disk enclosures (the internal USB3 hub doesn't matter when you connect HDDs, that's only a performance drop noticable with SSDs).

 

Besides XU4 you've currently not that many options if it's about really fast storage and 2 HDDs at the same time. ROCK64 would need an external USB3 hub, those mPCIe equipped boards combined with an ASM 106x or Marvell 88SE9215 are an option or Helios4. Next year will get more interesting since a few more boards with good storage capabilities will be available.

Share this post


Link to post
Share on other sites
2 hours ago, tkaiser said:

Next year will get more interesting since a few more boards with good storage capabilities will be available.

Which ones will be interesting in your opinion?

 

Helios4 looks interesting but I may not even need 2 hdds...Maybe I'll swap hdds and sell the wd my cloud with 3tb hdd in it.

Is there a 1 hdd solution that comes to your mind? I also thought of buying the odroid hc1, the hdd enclosure has an esata port, maybe I could hook up the external hdd to the sata port of the hc1 with sata to esata cable.. Unfortunately I saw that there's no "omv armbian" image for the hc1, .. I don't know if I can do that myself. But the hc1 should be as powerful as the xu4, it has the same SoC. Only cooling worries me here.

 

Edit: Ok, just found your thread on omv forum where you state the xu4 name image is also for hc1/hc2/mc1 and read that hardkernel wants to release odroid hc2 for a 3,5" hdd by the end of this month.

I will post following questions in this thread, fits better.

Share this post


Link to post
Share on other sites
3 minutes ago, trohn_javolta said:

Unfortunately I saw that there's no "omv armbian" image for the hc1, .. I don't know if I can do that myself. But the hc1 should be as powerful as the xu4, it has the same SoC. Only cooling worries me here.

 

XU4 and HC1 are fully software compatible (check the readme) and heat dissipation on HC1 is WAY BETTER than with XU4. But you're limited to 2.5" disks here and should keep in mind that Hardkernel already announced a HC2 without that much details (so maybe using the same JMS561 as on Cloudshell 2 minus the interconnection problems -- better ask in their forum).

 

Wrt new boards being interesting for NAS use cases:

  • Pine folks want to provide something called 'Cloudmedia Transformer' (same idea as XU4 vs. HC1, the Transformer is a 100% software compatible ROCK64 + JMS578 on the PCB in an heat emitting metal enclosure that fits a 2.5" HDD, they also thought about a 3.5" variant)
  • Similar to 'Le Potato' a so called 'Le Fly' also with RK3328 might appear (the bottom one here)
  • A bunch of RK3399 devices will be available (all with PCIe 2.x x4 and USB3), I expect software support next year on par with RK3328
  • EspressoBin might have stable software support next year (you can use the native SATA port there and add mPCIe SATA cards with 2 or even 4 additional real SATA ports)
  • Allwinner H6 boards with both PCIe (single lane, PCIe 2.x) and USB3 will appear (see here and keep in mind that Banana Pi people also have an H6 board in the works)
  • Banana Pi R2 might be ready next year (MTK software support looks promising so maybe next year when mainline kernel support matured we'll support the board)

The GnuBees are not listed by intention.

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
7 7