Building OMV automatically for a bunch of different ARM dev boards

  • Uploading the new image now

    Thank you!


    BTW: I installed the cloudshell-lcd service more or less by accident (simulating a connected Cloudshell 2) and just noticed that my XU4 got noisy (in a cabinet so I didn't take notice earlier). The fan starts every few seconds. Reason: the amazingly inefficient /bin/cloudshell-lcd script. This keeps the A15 cores up at 2.0 GHz all the time, prevents the CPU cores entering power saving states and led to 'idle' temperature increasing by a whopping 8°C.


    I don't know why it's necessary to check every single second the temperature of connected disks (preventing them to spin-down) or the kernel version or whether the distro is Debian or Ubuntu or even the hostname (WTF?). Until this gets fixed the best you could do with this script is a


    Code
    systemctl disable cloudshell-lcd

    (fortunately this is only installed on XU4 with Cloudshell 2 connected)

  • The ads7846 module consumes a full cpu even with cloudshell-lcd disabled. Load never drops below 1.0. I'm not home to see if the fan stops when you rmmod ads7846.

    omv 5.5.1 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • The ads7846 module consumes a full cpu even with cloudshell-lcd disabled

    That's really bad (fortunately my XU4 is not affected since no such display connected). Maybe it helps to adjust /proc/irq/147/smp_affinity so only the little cores are kept busy doing nothing?


    In the meantime I realized that the 'package' odroid-cloudshell just adds one single file to the installation:


    Code
    root@odroidxu4:~# cat /etc/modprobe.d/odroid-cloudshell.conf
    options fbtft_device name=hktft9340 busnum=1 rotate=270 speed=35000000

    And cloudshell-lcd is just the ressource hungry script + service definition (lacking taskset prefix to keep this stuff on the little cores) while cloudshell2-fan 'package' is more or less just a wrapper around one i2cset call. I'm somewhat confused...


    Anyway: Installation of odroid-cloudshell package by default is wrong but I won't change it any more since affected users (using other SPI displays with their XU4) should be familiar enough with diagnosing/fixing module calling options. And I really hope that cloudshell-lcd script gets fixed soon upstream by @kyle1117 so an update will fix affected Cloudshell 2 installations.

  • Just adding "ads7846" into /etc/modprobe.d/blacklist-odroid.conf solved the issue.
    I don't know why the useless touchscreen ads7846 driver module loaded automatically since there is no touch layer on the TFT LCD.
    I hope @kyle1117 will fix the issue soon and add an option to display "htop" outputs. It will be really cool. :)

  • Just adding "ads7846" into /etc/modprobe.d/blacklist-odroid.conf solved the issue.

    @kyle1117 can you please add this to the odroid-cloudshell package? I won't touch anything XU4 related for the next time (already wasted too much time with board and Cloudshell gimmick) and maybe forever (will soon get a Rock64 dev sample with 4 GB DRAM, USB3 and native Gigabit Ethernet so if performance there looks promising and RK3328's USB3 IP doesn't show problems there's no reason to look back at XU4 anyway)


    BTW: I call Cloudshell a gimmick since the advertised LCD feature is obviously 'monitoring'. But monitoring 'solutions' that affect the behaviour of the system so badly (keeping one CPU core busy with a useless touch display driver if Cloudshell is connected and keeping the A15 cores all the time at 2000 MHz due to an insanely high load caused by the /bin/cloudshell-lcd script) are counterproductive. Monitoring that completely changes the system's behaviour is... just weird to remain polite.

  • Is there any benchmark result of the RK3328 USB 3.0?

    Nothing available yet. By looking into https://github.com/rockchip-li…nel/tree/release-4.4-3328 it seems same Synopsys Designware USB3 IP is used as in Exynos so maybe similar problems. It's way too early for any numbers but since Rockchip does a pretty good job in the meantime pushing their code also upstream I'm rather confident that this board won't suck (also RGMII attached Gigabit Ethernet instead of USB3 attached as on XU4 is an advantage and I hope there's no internal USB3 hub on the board).


    Due to the generic OMV creation routine added to Armbian's build system at least it's ensured that as soon as there's community Linux support somewhat stable for new devices an OMV image with good settings can be created automagically from scratch (that was also my main motivation to be prepared for Marvell EspressoBin now and both Rock64 and Allwinner H6 boards later)

  • EspressoBin seems to have only one SATA port unfortunately. We might need to plug an add-on board into the PCIe slot to attach more HDDs.

    Sure, you can add 2 or even 4 SATA ports via mPCIe there (details and also performance numbers). Armada 3720 is AFAIK connected with 2.5GbE to the internal Topaz switch so if set up correctly accumulated throughput with this board when using 3 GbE clients in parallel will be above 260 MB/s (to be confirmed, unfortunately none of the EspressoBin users I know come back with test results, they all seem to use their boards already productive)


    The older Cortex-A9 based Armada 38x are known to both saturate a 2.5GbE line (search Solid-Run forum) and 3 x SATA 3 in parallel (over 1500 MB/s with 3 fast SSD). Since Marvell re-used the respective engines on 3720 this shouldn't change that much (please keep in mind that those Marvell SoCs are designed for exactly this use case: NAS and routers unlike the tablet, TV box or smartphone SoCs you find on all the normal SBC)


    Even more important: you get NAS grade and not toy grade hardware with Marvell SoCs and can avoid USB for storage entirely (no hassles with crappy cables/connectors as on some USB3 equipped SBC or crappy firmware in USB-to-SATA bridges) but should keep in mind that internal SATA connectors are rated/specified for 50 matings max (and that cheap SATA cables are always 'great' to introduce troubles, that's why you always immediately check SMART attribute 199 after attaching any SATA connector/cable while running an initial iozone/fio benchmark)


    Edit: I already mentioned the 'ARM based NAS board overview' in this thread but it seems it's better to repeat that: https://forum.armbian.com/inde…net-for-10/#comment-31957 (Marvell Armada 38x based Helios4 might be an interesting alternative if you really need 4 SATA devices at once but in those parts of the world where you get HP Microservers cheap -- which is the case for central Europe for example -- I would prefer such a Microserver since if I start to think about such use cases I start to care about data integrity and then using modern FS like ZFS or btrfs implementing checksumming and ECC memory are mandatory for me)

  • Is there anything else special to be done for booting these new 4.9 Armbian images? I wrote OMV_3_0_76_Odroidxu4_4.9.28 and it does not fully boot. Could it be because I did not plug my XU4 into an ethernet? I connected it only via UART.




    U-Boot 2012.07 (May 19 2017 - 09:22:50) for Exynos5422



    CPU: Exynos5422 Rev0.1 [Samsung SOC on SMP Platform Base on ARM CortexA7]
    APLL = 800MHz, KPLL = 800MHz
    MPLL = 532MHz, BPLL = 825MHz



    Board: HardKernel ODROID
    DRAM: 2 GiB
    WARNING: Caches not enabled



    TrustZone Enabled BSP
    BL1 version: ▒/▒▒▒
    VDD_KFC: 0x44
    LDO19: 0xf2



    Checking Boot Mode ... SDMMC
    MMC: S5P_MSHC2: 0, S5P_MSHC0: 1
    MMC Device 0: 15.4 GiB
    MMC Device 1: [ERROR] response error : 00000006 cmd 8
    [ERROR] response error : 00000006 cmd 55
    [ERROR] response error : 00000006 cmd 2
    *** Warning - bad CRC, using default environment



    In: serial
    Out: serial
    Err: serial
    Net: No ethernet found.
    Press quickly 'Enter' twice to stop autoboot: 0
    there are pending interrupts 0x00000001



    ** Unable to use mmc 0:1 for fatload **
    Loading file "/boot/boot.ini" from mmc device 0:1 xxa1
    10171 bytes read
    Loading boot.ini from ext4 0:1
    Find boot.ini file from FAT/Ext4 Area!!
    boot.ini command = setenv rootdev "UUID=b137c027-10cf-41d5-8a72-fd546b628157"
    boot.ini command = setenv initrd_high "0xffffffff"
    boot.ini command = setenv fdt_high "0xffffffff"
    boot.ini command = setenv macaddr "00:1e:06:61:7a:55"
    boot.ini command = setenv bootrootfs "console=tty1 loglevel=1 root=${rootdev} rootwait rw fsck.repair=yes"
    boot.ini command = setenv vout "hdmi"
    boot.ini command = setenv cecenable "false" # false or true
    boot.ini command = setenv governor "performance"
    boot.ini command = setenv HPD "true"
    boot.ini command = setenv hdmi_tx_amp_lvl "31"
    boot.ini command = setenv hdmi_tx_lvl_ch0 "3"
    boot.ini command = setenv hdmi_tx_lvl_ch1 "3"
    boot.ini command = setenv hdmi_tx_lvl_ch2 "3"
    boot.ini command = setenv hdmi_tx_emp_lvl "6"
    boot.ini command = setenv hdmi_clk_amp_lvl "31"
    boot.ini command = setenv hdmi_tx_res "0"
    boot.ini command = setenv hdmi_phy_control "hdmi_tx_amp_lvl=${hdmi_tx_amp_lvl} hdmi_tx_lvl_ch0=${hdmi_tx_lvl_ch0} hdmi_tx_lvl_ch1=${hdmi_tx_lvl_ch1} hdmi_tx_lvl_ch2=${hdmi_tx_lvl_ch2} hdmi_tx_emp_lvl=${hdmi_tx_emp_lvl} hdmi_clk_amp_lvl=${hdmi_clk_amp_lvl} hdmi_tx_res=${hdmi_tx_res} HPD=${HPD} vout=${vout}"
    boot.ini command = ext4load mmc 0:1 0x40008000 /boot/zImage || fatload mmc 0:1 0x40008000 zImage || ext4load mmc 0:1 0x40008000 zImage
    Loading file "/boot/zImage" from mmc device 0:1 xxa1
    6250928 bytes read
    boot.ini command = ext4load mmc 0:1 0x42000000 /boot/uInitrd || fatload mmc 0:1 0x42000000 uInitrd || ext4load mmc 0:1 0x42000000 uInitrd
    Loading file "/boot/uInitrd" from mmc device 0:1 xxa1
    5310096 bytes read
    boot.ini command = if ext4load mmc 0:1 0x00000000 "/boot/.next"; then echo "Found mainline kernel configuration"; ext4load mmc 0:1 0x44000000 /boot/dtb/exynos5422-odroidxu4.dtb || fatload mmc 0:1 0x44000000 dtb/exynos5422-odroidxu4.dtb || ext4load mmc 0:1 0x44000000 dtb/exynos5422-odroidxu4.dtb; else echo "Found legacy kernel configuration"; ext4load mmc 0:1 0x44000000 /boot/dtb/exynos5422-odroidxu3.dtb || fatload mmc 0:1 0x44000000 dtb/exynos5422-odroidxu3.dtb || ext4load mmc 0:1 0x44000000 dtb/exynos5422-odroidxu3.dtb; fi
    Loading file "/boot/.next" from mmc device 0:1 xxa1
    0 bytes read
    Found mainline kernel configuration
    Loading file "/boot/dtb/exynos5422-odroidxu4.dtb" from mmc device 0:1 xxa1
    61024 bytes read
    boot.ini command = if test "${fdtloaded}" != "true"; then ext4load mmc 0:1 0x44000000 exynos5422-odroidxu4.dtb; fi
    Loading file "exynos5422-odroidxu4.dtb" from mmc device 0:1 xxa1
    ** File not found exynos5422-odroidxu4.dtb
    ext4load - load binary file from a Ext4 filesystem



    Usage:
    ext4load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
    to address 'addr' from ext4 filesystem
    boot.ini command = fdt addr 0x44000000
    boot.ini command = if test "${cecenable}" = "false"; then fdt rm /cec@101B0000; fi
    boot.ini command = setenv bootargs "${bootrootfs} ${videoconfig} smsc95xx.macaddr=${macaddr} governor=${governor} ${hdmi_phy_control} ${extraargs}"
    boot.ini command = bootz 0x40008000 0x42000000 0x44000000
    ## Loading init Ramdisk from Legacy Image at 42000000 ...
    Image Name: uInitrd
    Image Type: ARM Linux RAMDisk Image (gzip compressed)
    Data Size: 5310032 Bytes = 5.1 MiB
    Load Address: 00000000
    Entry Point: 00000000
    ## Flattened Device Tree blob at 44000000
    Booting using the fdt blob at 0x44000000
    Using Device Tree in place at 44000000, end 44011e5f



    Starting kernel ...





    EDIT: It had to be connected to ethernet to work, at least on first boot. I was able to boot it afterwards and I made a few tests.

    Riddle me this, riddle me that
    Who is afraid of the big, black bat?
    I write on a blog (Romanian mostly)
    Testing (latest) OMV 4.x on an oDroid H2 (currently with kernel 4.19.x)

    Edited once, last by tmihai20: Found the fix ().

  • Nothing special. I followed this instruction and it worked out of the box.
    http://odroid.com/dokuwiki/doku.php?id=en:xu4_cloudshell_omv
    It was worth to use the Etcher for validated flashing OS image.


    My serial console output is here for your comparison. There seems to be nothing different since someone blocked the serial console output from the Kernel.
    If the blue led keeps flashing like heart beat, just try to access the omv web ui after connecting your Ethernet. it should work.


    You have to update the system with Update-Management menu.
    Kyle1117 fixed few annoying issues with his updated packages yesterday.

  • It had to be connected to ethernet to work, at least on first boot.

    Yes, due to the new way these OMV images are created for ARM boards (fully automated in a chroot environment so no one has logged in ever here) a few final installation steps are done on first boot and this requires network access. And I didn't thought missing network could be an issue since a NAS without the N (network) is useless anyway :)


    In case you run into XU4 issues please report them at the vendor forum.

  • Just out of curiosity: Is there any [pre]release (image-file) for the Orange Pi PC 2 yet? I found one* for the Nano Pi Neo 2 (and these are sharing the same H5-SoC) - so that's why I'm asking ;)


    Great to see this nice synergy between ARMBIAN & OMV - both project's who create stunning quality without commercial interest and sharing there code world wide! Big UP :thumbsup:You are awesome!



    *found it here: http://kaiser-edv.de/tmp/NumpU8/

  • Just out of curiosity: Is there any [pre]release (image-file) for the Orange Pi PC 2 yet?

    Unfortunately not since situation with mainline kernel is still too much WiP and legacy kernel (Allwinner's 3.10.65) is such a mess that no one will touch it. Status: https://www.armbian.com/orange-pi-pc2/


    Main issue currently is that the Ethernet driver Armbian uses on A64, H3 and H5 mainline images is unmaintained (sun8i-emac) and the new variant (dwmac-sun8i) is not part of our kernel sources yet (details). Once this is resolved (maybe with 4.12) and we got cpufreq working again maybe we will switch support level from dev to next and as soon as that happens I'll immediately roll out OMV images and ping @ryecoaaron to upload them on sourceforge.


    Currently you would need to build an OMV image yourself (uncomment InstallOpenMediaVault function in userpatches/customize-image.sh and follow instructions). Which is a bit sad since I agree that Orange Pi PC 2, NanoPi NEO 2 and the other GbE equipped H5 boards are pretty awesome OMV targets given their performance, count of real USB ports and especially low price.

  • Yes, due to the new way these OMV images are created for ARM boards (fully automated in a chroot environment so no one has logged in ever here) a few final installation steps are done on first boot and this requires network access. And I didn't thought missing network could be an issue since a NAS without the N (network) is useless anyway :)
    In case you run into XU4 issues please report them at the vendor forum.

    I am very aware of that and of your discussions. I just wanted to test the new image and I only have one network cable there, for my PC. I had it connected via UART to check for messages as soon as it booted. The old image did not need network, nobody mentioned it and I think the other users should know to have this forum with actual issues.

    Riddle me this, riddle me that
    Who is afraid of the big, black bat?
    I write on a blog (Romanian mostly)
    Testing (latest) OMV 4.x on an oDroid H2 (currently with kernel 4.19.x)

  • The old image did not need network, nobody mentioned it

    That is true but that image was fully configured and not truly fresh. This new image is definitely an improvement. I will update the readme for people who want to try the image without networking.

    omv 5.5.1 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Why can't we report the XU4 OMV issues at this OMV forum?

    OMV issues can and should be reported here, the various XU4 and Cloudshell 2 issues -- see https://forum.armbian.com/inde…findComment&comment=32340 -- on their forum. Maybe someone over there will care about, maybe not. I'm not involved any more since it's such a waste of time dealing with micro communities fighting against anything that's new to them (does not only apply to ODROID community but is a general syndrome of such micro communities and vendor forums)


    @tmihai20: Armbian provides kernel upgrades from time to time (or if necessary, see 'Dirty Cow' for the last such example) via 'apt upgrade'. Maybe in two weeks we roll out a new major version and then you'll get the update.

  • Anyone here with access to Cloudshell 2 with 2 disks inside able to do a quick check of all 3 JMS561 modes (RAID-0, RAID-1 and JBOD) providing the output of the following script?

    Bash
    #!/bin/bash
    check() {
    for disk in /dev/sd[a-z] ; do smartctl -d sat -q noserial -x -i -r ioctl,2 $disk ; done
    lsusb -v
    lsusb -t
    }
    check | curl -F 'sprunge=<-' http://sprunge.us

    Output will look like http://sprunge.us/ZITZ (data gets pasted to sprunge.us automatically).


    Unfortunately Debian policies prevent inclusion of /usr/sbin/update-smart-drivedb script so it's a good idea to manually update /var/lib/smartmontools/drivedb/drivedb.h before by


    Code
    wget https://raw.githubusercontent.com/mirror/smartmontools/master/drivedb.h

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!