Odroid XU4 - can't start OpenMediaVault 4

    • OMV 4.x
    • Resolved
    • Moan wrote:

      With that logic we shouldn't be using 90% of devices, because they have parts produced in China.This "MIXZA TOHAOLL" has many good reviews. After all I did some tests and it seems to work fine. No fake size, no damaged files. Most likely it only had problems to work with kernel 4.9.

      This is not about the logic "because something is from China". Only to provide all possible technical details at once in order to avoid unnecessary chasing after your own tail. I'm not surprised that @tkaiser has a rough approach to many problems of users where usually problem is in psu / sd / rpi.

      Kernel compatibility with SD card. I have not heard about it. It's good to know something new. I wonder exactly what effect a particular sd card has on a particular kernel?
    • JohnStiles wrote:

      Kernel compatibility with SD card. I have not heard about it

      Three areas:
      • u-boot: when having to use a horribly outdated vendor bootloader (does not apply to any OMV/Armbian image since we're using mainline but to the majority of all the other ARM images out there) there can be compatibility issues that need patches/fixes. I can't recall this being a problem with SD cards but with rather similar eMMC modules where the code is only ready for MMC version 4.x and as such refuses to work with eMMC 5.x modules. Vice versa exists too and some MMC storage will only work with the smelly vendor BSP drivers but not with upstream mainline code.
      • kernel: exactly same as above
      • Device-tree: this is not directly kernel but settings that always have to match kernel version. And as such sh*t happens (see the lost cpufreq steps after applying the moronic Armbian kernel update to 4.19 a while ago). A relevant setting is called drive strength and this amperage value can make the difference between SD card working flawlessly or not booting at all or something in between. As such a 'kernel update' can easily break or fix things here.
      No idea whether any of this applies to the situation here. Just meant as some food for thought.
    • tkaiser wrote:

      Three areas:
      • u-boot: when having to use a horribly outdated vendor bootloader (does not apply to any OMV/Armbian image since we're using mainline but to the majority of all the other ARM images out there) there can be compatibility issues that need patches/fixes. I can't recall this being a problem with SD cards but with rather similar eMMC modules where the code is only ready for MMC version 4.x and as such refuses to work with eMMC 5.x modules. Vice versa exists too and some MMC storage will only work with the smelly vendor BSP drivers but not with upstream mainline code.
      • kernel: exactly same as above
      • Device-tree: this is not directly kernel but settings that always have to match kernel version. And as such sh*t happens (see the lost cpufreq steps after applying the moronic Armbian kernel update to 4.19 a while ago). A relevant setting is called drive strength and this amperage value can make the difference between SD card working flawlessly or not booting at all or something in between. As such a 'kernel update' can easily break or fix things here.
      No idea whether any of this applies to the situation here. Just meant as some food for thought.

      Interesting.


      I would rather not expect such problems in 2019.
      In these times, rather the compatibility of the cards should rather be solidly resolved. Well, but ... the realities and theoretical assumptions do not always go hand in hand. :)

      So for the peace of mind, it is always good to give a specific sd card because maybe someone knows about its compatibility. imho :)
    • Users Online 1

      1 Guest