tkaiser

@Igor and @zador.blood.stained Justin from Hardkernel just got back to me after testing with their new orange eMMC and a freshly created legacy image and one with 4.9 LTS kernel: "Thank you for the fast updates. We’ve just checked the strobe parameter in those two updates on Kernel 4.9 and 3.10. All of them has the proper strobe-delay value now. Really appreciate your help. But please consider releasing new images since some users can’t update safely because of the instability just in case. In the first boot process(or any time before update), the Orange eMMC could be corrupted due to the wrong strobe-delay." I'm pushing out a new OMV release now (the one Hardkernel tested within the last few hours) and obviously it might help users with this new eMMC avoiding first boot hassles when 'next Armbian release' is also out soon (but I've totally lost track when we wanted to do this). The fixes for the new eMMC appeared in both kernels around Oct 25 (it's just a minor DT tweak in both cases).

Tido is totally right, we can't call a tool in a way a user would be able to understand what it does but we need to behave like primitive files (since in Unix just Everything is a file). So a better name would be partition-something-then-rsync-then-check-then-adjust-uuids-in-bootscript-and-fstab. That's great. @Tido: it's really nice to get the difference explained between cp and mv especially so many decades after using Unix now. And of course it's a copy since we do not wipe out the source for obvious reasons (since if something went wrong the user can recover from this or delete the source on its own later after he decided to stay with the installation on the new media). And of course it's absolutely stupid when a dev tries to tell a moderator (who wants to deal with users obviously) the difference between the 'user perspective' and technical details (that do not matter here). I'm out now.

No it's a file of course if you want to turn a discussion about improving Armbian into something that deals with Unix platitudes. The tool we're talking about is something to move an installation from A to B technically doing a copy and adjusting references later. From a user perspective it's a move. And that's the only thing that matters.

Hmm... yes, I like this even more than symlinking with a different name. This allows to develop a new tool in parallel, writing documentation (more a 'please think about what you're doing' reminder than real documentation) and once it's ready replace basic instructions and phase out support for nand-sata-install. Great idea though that would require that at this point some services (like resize2fs) weren't already running since we want to clone the original image as unmodified as possible to eMMC. Also 'first login' is possible via SSH too and then the whole system is already completely up and running (would be different if we were talking about an initrd scenario with keyboard/display). Let's think about this more but separate it from 'move-armbian' (or whatever it will be called later). Edit: Pine folks for example shipped some time ago images that carried the real image inside and all this did at first boot was just that: overwriting the eMMC with the static image and asking for reboot. I heard few users being not that happy with a wiped out eMMC so such 'eMMC overwrite only images' are most probably also not a viable alternative Edit 2: minimal 'eMMC install' images could be possible, allowing to login, then choosing image to be burned to eMMC from a list, fetched via torrents and finalized. But better keep this whole idea separate from 'move-armbian'

C'mon, please read the threads you're jumping into. It's about dropping NAND support entirely since the structure of the tool's code is the main problem in maintaining it and solving any problems with it. Sure, but we need to change the official name since writing in documentation 'If you want to transfer your installation to eMMC then call nand-sata-install' is as bizarre as writing to 'call drill-hole-in-knee'. What about 'move-os' or 'move-armbian'? @Igor: what's your opinion on this? Are you secretly working on mainline NAND support (and if yes why?) or can we simply drop the idea and clean-up the code base?

Great line for next release notes: Raw NAND support (old Allwinner boards) is deprecated now and will be removed with next release

Just a quick list: It's named completely wrong since it doesn't install anything but transfers an already running installation from one media to another. Main focus on 'without breaking stuff' since transfering a booted/running system is challenging! It's named completely wrong since it's not about NAND and SATA any more (hello Cubieboards and Bananas back in 2014) but eMMC and USB these days (and yeah, SATA too) It's a blind alley: moving the installation from SD card to $somewhere will work. But nand-sata-install is still there, people might want to use it and will fail (though I think that will most probably never happen since once people are happy why should they try to move their installation from USB back to SD card for example) The code is a mess but that's understandable since from day 1 on only WiP and extended, extended, little bit cleaned up, extended, extended again What about being honest and telling users Raw NAND on those horribly outdated Allwinner boards is crap, forget about it. Yeah, you paid for it but it's worse than SD cards and eMMC, it will fail anyway soon if you used it on your old board now many years, there's the incompatiblity between legacy and mainline NAND support and if you're really keen on using NAND these days.... get a CH.I.P. and stop using Armbian Think about what you're doing, eg. putting the rootfs on a HDD has serious drawbacks if users want the disk to spin-down when inactive (some more minimal documentation efforts I refuse to waste time on as long as the tool is named that weird) If I haven't overlooked something that's it. And IMO it's necessary to clean-up the code base (or rewrite from the ground) since everytime I touch this it takes me an awful lot of time to get what this thing does. Then I think let's clean it up now, then I think 'where's my Cubietruck to test this useless NAND stuff', then I think 'ok, workaround mode again, fix it next time'. In summary just an insane waste of time and also dangerous (I believe I ran multiple times this year in nand-sata-install related issues where bootloader/initrd stuff has been updated on the wrong device). If we can agree on dropping NAND support at all IMO it gets immediately easy since a lot of other groundwork we did already in the meantime (the UUID stuff for example or determining optimal mount options for various filesystems) can be combined with a few lines of code dealing in a clear way with the different situations we face with this tool. No need to hurry, this is something for the release after next release. But I would love to get a direct feedback now about in which direction we want to move since my will to touch nand-sata-install in its current state will heavily depend on this

In any case you need to exchange contents of /usr/sbin/nand-sata-install with https://raw.githubusercontent.com/armbian/build/master/packages/bsp/common/usr/sbin/nand-sata-install before continuing. Then nand-sata-install should work. But maybe I messed things up so better wait for @zador.blood.stained either giving an OK or reverting my latest commit (which I would be fine with given that I really get headache every time looking at nand-sata-install code -- I hope we could drop all the NAND stuff and weird exceptions there)

I tested with an OMV image I created today for Hardkernel (so they can test their new eMMC themselves). OMV relying on btrfs as usual. Then tried out nand-sata-install twice and testing with ext4 and btrfs as target: Ext4 target: contents of /boot are not copied, fstab wrong: bogus /boot and /media/mmcboot entries. After fixing both problems manually (rsync and vi) it works: http://sprunge.us/LTSX Btrfs target: rootfs is copied from mmcblk1p2 to sda1 but fstab is created wrong: /media/mmcboot entry gets UUID of old / (mmcblk1p2) instead of ext4 /boot (mmcblk1p1) and the bind mount is wrong too. After fixing the 1st problem manually (exchange UUID in fstab) it works: http://sprunge.us/hJFX In the 2nd case I think these are just two simple bugs (using $root_uuid instead of $sduuid and let /boot point to non-existent /media/mmcboot/boot) so I decided to fix them and limit the target fs choice when the current rootfs is already btrfs to also just btrfs (so no normal Armbian installation using an ext4 rootfs should be affected and those OMV images are condemned to stay with btrfs) . Works now: http://sprunge.us/XIZX

Of course not. If you can post links to interesting posts somewhere in between this 172 pages (!) thread or a github repo with the changes I'll take a look ASAP. Thanks.

Ramspeed? Kernel? The issue is that the firmware blob is lying to the kernel wrt cpufreq (not RAM -- testing with sysbench is excluding RAM 100%). How should something in the kernel fix firmware behaviour? What's the proof of 'All cores now work at 1.5ghz'? The fantasy values returned by /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq?

In case you haven't already you might look through https://github.com/armbian/build/blob/master/config/templates/customize-image.sh.template#L35 to get an idea how to workaround or solve some of the issues when installing not in an already running system but from customize-image.sh. BUT... the above OMV installation routine can be considered a proof of concept and also part of a journey (that ended in the meantime -- see last 2 posts here please). Stuff like this should become part of armbian-config/softy.

Ok, that explains also what I experienced recently with Stretch (which was in fact just one of those OMV btrfs installations upgraded from Jessie to Stretch). I'll have a look into right now. Thanks for the heads-up. You can't do anything here, this bug affects currently all OMV images since they all rely on btrfs for the rootfs (and have therefore a separate ext4 /boot partition) Yes since bleeding-edge and collecting experiences with more modern filesystems providing for awesome features (like snapshots and transparent file compression)

You mean it depends on the source filesystem and not the target?

No, I was talking about touching /boot/script.bin directly for a reason. Since /boot/bin/orangepione.bin (and all other files in this directory) are not under your but our (Armbian's) control. Next update that will be rolled out will overwrite your changes (and this will happen most probably within one week). So overwrite /boot/script.bin with modifications and don't let this be a symbolic link to a file in /boot/bin/ BTW: I second @chwe's concern and would suggest testing your dongle on a good USB3 port (known to provide stable 5.x V at 900 mA -- I tested this a while ago with a couple of laptops and a Banana Pro to be able to measure and with almost all PC laptops power situation on the USB3 ports sucked especially when switching the laptop over to battery)

Maybe there are commercial NTFS drivers available (for ARM) but I would simply drop the idea to use NTFS since as it's implemented in a standard Debian or Ubuntu ('ntfs-3g' package: 'read/write NTFS driver for FUSE') it will always be the worst combination of slow and ressource hungry. I would simply use a 'native' filesystem on Linux (ext4 or btrfs) and if you need something to interchange between different systems maybe ExFAT is a solution (no idea, I stopped this idea years ago when I did some tests with ExFat and UDF and especially the latter turned into a nightmare)

Just as a reference: a new Hardkernel eMMC module is to be released/shipped next week: https://wiki.odroid.com/accessory/emmc/reference_chart#new_orange_emmc_module The needed kernel quirk is already in our 4.9 kernel (just checked it) and I would believe the u-boot we're using is also ready....

In the meantime there's both an Android 7.x 'SDK' out for H3 boards and a new BSP relying on some 4.4 kernel version is said to be ready to release today. No idea who'll look into this (none of the TV box vendors most probably since why should they), maybe the guys behind https://h3droid.com

And this works surprisingly VERY WELL. My Orange Pi powering a Banana Pi (since there we can measure voltage): The Orange Pi is powered through Xunlong's 5V/3A PSU. And this is how it looks wrt voltage on the Banana Pi (the white cable in between is an 20AWG rated MicroUSB cable): ### Current system health: Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St. 11:38:12: 960MHz 0.18 10% 6% 2% 0% 2% 0% 48.9°C 30.1°C 5.14V 0/6 11:38:13: 960MHz 0.18 17% 15% 2% 0% 0% 0% 48.7°C 29.9°C 5.12V 0/6 11:38:14: 960MHz 0.18 25% 20% 1% 0% 3% 0% 48.4°C 29.7°C 5.15V 0/6 11:38:15: 960MHz 0.18 10% 8% 2% 0% 0% 0% 48.4°C 30.0°C 5.16V 0/6 11:38:16: 528MHz 0.18 22% 19% 2% 0% 0% 0% 48.2°C 29.9°C 5.15V 0/6 11:38:18: 960MHz 0.32 10% 6% 2% 0% 1% 0% 49.4°C 30.7°C 5.07V 0/6 11:38:20: 960MHz 0.32 100% 7% 92% 0% 0% 0% 50.3°C 31.0°C 5.10V 0/6 11:38:21: 960MHz 0.32 75% 7% 68% 0% 0% 0% 49.1°C 30.2°C 5.15V 0/6 11:38:23: 960MHz 0.38 16% 11% 0% 0% 4% 0% 49.0°C 30.0°C 5.16V 0/6 11:38:24: 528MHz 0.38 11% 10% 1% 0% 0% 0% 48.6°C 30.2°C 5.10V 0/6 Starting at 11:38:18 a short stress test had been started in the background. Voltage still at 5.07V which is just... great. Adding a host powered SSD to Banana Pi of course led to an instant poweroff. But on the Orange Pi it was just a simple CLI command to get the Banana restarted (without SSD connected of course!): echo 0 > /sys/class/gpio/gpio354/value ; sleep 2 ; echo 1 > /sys/class/gpio/gpio354/value

Tried it out this way and then used the usual GPIO sysfs: root@orangepione:/# echo 354 > /sys/class/gpio/export root@orangepione:/# echo "out" > /sys/class/gpio/gpio354/direction root@orangepione:/# echo 1 > /sys/class/gpio/gpio354/value root@orangepione:/# lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 05e3:0723 Genesys Logic, Inc. GL827L SD/MMC/MS Flash Card Reader Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@orangepione:/# echo 0 > /sys/class/gpio/gpio354/value root@orangepione:/# lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Calculating the respective sysfs node is following the mainline rule here (even with legacy kernel): https://linux-sunxi.org/GPIO

I tried it already. And guess what: this got ignored all the time. Usually someone else is chiming in in the meantime and comes up with suggestions and users happily follow other suggestions just to do $something instead of providing quality information. It doesn't work if it's done by one individual. It needs to become a general policy. But it's just a stupid waste of time to discuss this BS over and over again. Bye.

You can make a backup copy of /boot/script.bin, then use bin2fex, change this line to 'usb_drv_vbus_gpio = ', then use fex2bin and see whether your dongle now reacts to sunxi-pio commands...

Well, same situation here (especially in the evening 2.4GHz close to unusable) but when I tried to do some real measurements I was surprised that 2x2 MIMO made the real difference even in overcrowded 2.4 GHz band (compare the RTL8192CU numbers with the 1T1R stuff): https://forum.armbian.com/topic/3739-wi-fi-performance-and-known-issues-on-sbc/?do=findComment&comment=27158

Maybe worth a try but then this pin should most probably be taken out of control of the respective driver and controlled by sunxi-pio instead. Interested in results

SD Formatter is not needed (only for one specific purpose no one knows about and uses -- search here for 'block erase') and Win32 DiskImager is a horrible tool since it does NOT verify what it tried to write and is the root cause of so much useless support troubles. So what did you do differently now? Followed our documentation and used F3/H2testw to check your SD card and Etcher to burn it?