Search the Community

Now results with the 16GB SanDisk Extreme Plus SD card. Debug logs here for F2FS and EXT4: F2FS EXT4 iozone 4K random write IOPS 746 764 iozone 4K random read IOPS 1616 1568 iozone 1MB sequential write KB/s 20354 21988 iozone 1MB sequential read KB/s 22474 22548 ioping k iops 1.57 1.55 fio write iops 311 399 fio read iops 934 1197 OMV installation time in sec 862 791 No performance difference between F2FS and ext4 as before, funnily fio numbers again better with ext4 than f2fs (this is a synthetic benchmark trying to emulate a mixed workload of 75% reads and 25% writes) and this time also OMV installation faster with ext4 compared to f2fs.

Resize is supported by the kernel, but the userspace part (in f2fs-tools) is not present in Xenial and I'm not sure if it is present in Stretch. It is definitely present in Debian testing branch, which is ahead of frozen Stretch. Edit: Also not sure if online resize is supported.

Ok a little difficult. Do you know how I can repair the partition enough to get the file off it? root@clearfogpro:~# ls root@clearfogpro:~# ls /media/ root@clearfogpro:~# mkdir /media/emmc root@clearfogpro:~# mount /dev/mmcblk0p1 /media/emmc/ [ 243.366150] UDF-fs: warning (device mmcblk0p1): udf_fill_super: No partition found (2) [ 243.377055] F2FS-fs (mmcblk0p1): Magic Mismatch, valid(0xf2f52010) - read(0x1102d4b) [ 243.384864] F2FS-fs (mmcblk0p1): Can't find valid F2FS filesystem in 1th superblock [ 243.394112] F2FS-fs (mmcblk0p1): Magic Mismatch, valid(0xf2f52010) - read(0x6b636170) [ 243.401972] F2FS-fs (mmcblk0p1): Can't find valid F2FS filesystem in 2th superblock [ 243.409723] F2FS-fs (mmcblk0p1): Magic Mismatch, valid(0xf2f52010) - read(0x1102d4b) [ 243.417513] F2FS-fs (mmcblk0p1): Can't find valid F2FS filesystem in 1th superblock [ 243.425211] F2FS-fs (mmcblk0p1): Magic Mismatch, valid(0xf2f52010) - read(0x6b636170) [ 243.433095] F2FS-fs (mmcblk0p1): Can't find valid F2FS filesystem in 2th superblock mount: wrong fs type, bad option, bad superblock on /dev/mmcblk0p1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so.

Any reason why an XFS kernel driver isn't included in the Armbian images? I'm coming from the RHEL world so I have no idea if it's common for Debian and it's variants to not have XFS support? I'm kind of baffled. root@cubox-i:~# cat /proc/filesystems nodev sysfs nodev rootfs nodev ramfs nodev bdev nodev proc nodev cpuset nodev cgroup nodev cgroup2 nodev tmpfs nodev devtmpfs nodev debugfs nodev securityfs nodev sockfs nodev pipefs nodev rpc_pipefs nodev devpts ext3 ext2 ext4 vfat nodev nfs nodev nfs4 nodev jffs2 nodev autofs fuseblk nodev fuse nodev fusectl f2fs nodev mqueue nodev ubifs btrfs # mount -t xfs /dev/sda1 /srv/esata mount: unknown filesystem type 'xfs'

Kernel 3.4.x is too old for f2fs ... It's enabled in Vanilla (4.x) kernel but that one is not ready yet for H3 based boards.

I did some research and some tests... I can confirm that f2fs is not stable, after mounting I had kernel oops. My friend successfully using btrfs but on ssd drives (no nand). I think I'll try it in near future. Also had some good news! Tests... After system start script generate 300 files in one new directory filled with some text and then restart after short sleep and sync. System was restarted over 50 times (over 15k files was generated). 1. After clean reboot all files where fine (no zero size files) 2. After unclean reboot (echo b >/proc/sysrq-trigger) there was different results depend on ext mount options a. commit=600,data=writeback and journal_data_writeback enebled zero size files was ~8-10% b. commit=5,data=ordered and journal_data_writeback disabled zero size files was ~3% 3. SOLUTION! after writing have to give echo 3 >/proc/sys/vm/drop_caches Of course it take same time to save all data (depends on the amount of data to write) but on that system it was less then one second. So, I my case I can use drop_caches after each write (I do not have them too many) or simply execute periodically.

Well, then I would start with these measures: If it's Cubieboard2 then decrease DRAM clockspeed (for whatever reasons CB2 uses the highest speed possible and it's known that almost no A20 board works really reliable with 480MHz -- most reported problems are related to DRAM clock being too high --> bit flips will lead to all sorts of trouble). @Igor/@Zador: AFAIK something like DRAM reliability testing for Cubieboards has never happened. Decreasing DRAM clock in both fex and Cubieboard2_defconfig from 480MHz to eg. 400MHz might be an idea for future releases Don't use NAND but eMMC where possible Avoid boards that features AXP209 PMU but lack a battery connector If all of the above is no option then think about tweaking ext4 parameters as outlined by Zador Ext4 is a requirement for general purpose OS images (due to necessary filesystem resizing on 1st/2nd boot), it's really realible for most use cases (see page 3 here) and surprisingly it's also faster than alternatives that tried to address performance problems on flash media (F2FS for example).

Armbian by default mounts ext4 rootfs with "commit=600,data=writeback" options, which is optimized for performance and minimizing writes on flash media, but in the event of crash or unclean shutdown this may cause data loss. To shifs settings towards data integrity you may want to use "commit=5,data=ordered" mount options (you may have to also use tune2fs to remove "journal_data_writeback" option from default FS mount options depending on "age" of your image). And what FS should be used by default then? F2FS? Not an option for older kernels + no resize capabilities. BTRFS? Again, mainline is recommended for stability. And another thing - NAND implementation on allwinner devices sometimes can cause troubles by itself, regardless of filesystem it's formatted to.

I tried compile the kernel, but i have this issue: "ccache: FATAL: Could not find compiler "arm-linux-gnueabihf-gcc" in PATH" I see diferent post about this, but i can fix it. i use Vbox and use the ubuntu 14.04 of the download that are in the official tutto of ArmBian y tried too on a Debian Jessie and have same problems. Any helps? Armbian building script, http://www.armbian.com | Author: Igor Pecovnik ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ┌──────────────────────────────────────────────────────────────────────────────┠│ Installing 27 host dependencies... │ │──────────────────────────────────────────────────────────────────────────────│ │ build-essential cpp-4.7-arm-linux-gnueabi cpp-arm-linux-gnueabi │ │ cpp-arm-linux-gnueabihf debian-archive-keyring debian-keyring debootstrap │ │ device-tree-compiler dpkg-dev f2fs-tools g++ g++-4.8 │ │ gcc-4.7-arm-linux-gnueabi gcc-4.7-arm-linux-gnueabi-base │ │ gcc-arm-linux-gnueabi gcc-arm-linux-gnueabihf keyutils libcloog-ppl1 │ │ libdpkg-perl libfile-fcntllock-perl libgcc-4.7-dev-armel-cross │ │ libgcc1-armel-cross libgmpxx4ldbl libgomp1-armel-cross libgssglue1 liblzo2 │ │ libncurses5-dev libnfsidmap2 libppl-c4 libppl13 libssl-dev libstdc++-4.8-d │ │ libtinfo-dev libtirpc1 libusb-1.0-0-dev lzop nfs-common nfs-kernel-server │ │ pigz pkg-config pv qemu-user-static rpcbind u-boot-tools unzip uuid-dev zi │ │ zlib1g-dev │ │ 0 upgraded, 53 newly installed, 0 to remove and 0 not upgraded. │ │ Need to get 98.8 MB of archives. │ │ After this operation, 253 MB of additional disk space will be used. │ │ WARNING: The following packages cannot be authenticated! │ │ aptly E: There are problems and -y was used without --force-yeshe following signatures couldn't be verified because the public key is not available: NO_PUBKEY 9E3E53F19C7DE460 /home/test/lib/general.sh: line 362: update-binfmts: command not found [ o.k. ] Starting Armbian build script [ @host ] [ o.k. ] Building [ Armbian 5.05 Bananapim2 Debian jessie dev ] [ o.k. ] Syncing clock [ host ] [ o.k. ] source downloading [ @host ] [ o.k. ] ... updating [ u-boot ] [ o.k. ] ... updating [ linux-vanilla ] [ o.k. ] ... updating [ sunxi-tools ] [ o.k. ] ... updating [ rt8192cu ] [ o.k. ] ... updating [ sunxi-display-changer ] [ o.k. ] ... updating [ mt7601 ] [ o.k. ] Compiling sunxi tools [ @host & target ] cp: cannot stat ‘fex2bin’: No such file or directory cp: cannot stat ‘bin2fex’: No such file or directory [ o.k. ] Cleaning [ /home/test/sources/u-boot/branchless ] [ o.k. ] Cleaning [ /home/test/sources/linux-vanilla/branchless ] [ o.k. ] Cleaning /home/test/output/debs for [ bananapim2 dev ] [ o.k. ] Started patching process for [ kernel sunxi-dev 4.5.0 ] [ o.k. ] Looking for user patches in [ userpatches/kernel/sunxi-dev ] [ o.k. ] ... 0012-bananapi_r1_dts.patch [ succeeded ] [ o.k. ] ... a20-gmac-txfifo.patch [ succeeded ] [ o.k. ] ... axp20x-sysfs-interface.patch [ succeeded ] [ o.k. ] ... bananapi-codec.patch [ succeeded ] [ o.k. ] ... headers-packing.patch [ succeeded ] [ o.k. ] ... orangepi-mini-codec.patch [ succeeded ] [ o.k. ] ... packaging-dev.patch [ succeeded ] [ o.k. ] ... pcDuino3-nano-codec.patch [ succeeded ] [ o.k. ] ... stmmac-coe-and-bugged-jumbo.patch [ succeeded ] [ o.k. ] Started patching process for [ u-boot u-boot-dev 2016.03 ] [ o.k. ] Looking for user patches in [ userpatches/u-boot/u-boot-dev ] [ o.k. ] ... add-awsom-uboot.patch [ succeeded ] [ o.k. ] ... add-cubieboard4.patch [ succeeded ] [ o.k. ] ... u-boot-02-support-cheap-mmc.patch [ succeeded ] [ o.k. ] Compiling uboot. Please wait. [ 2016.03 ] Armbian building script, http://www.armbian.com | Author: Igor Pecovnik ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┠│ Compiling u-boot... │ │──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│ │ ccache: FATAL: Could not find compiler "arm-linux-gnueabihf-gcc" in PATH │ │ ccache: FATAL: Could not find compiler "arm-linux-gnueabihf-gcc" in PATH │ │ dirname: missing operand │ │ Try 'dirname --help' for more information. │ │ scripts/kconfig/conf --silentoldconfig Kconfig │ │ CHK include/config.h │ │ GEN include/autoconf.mk │ │ ccache: FATAL: Could not find compiler "arm-linux-gnueabihf-gcc" in PATH │ │ make[1]: *** [include/autoconf.mk] Error 1 │ │ make: *** No rule to make target `include/config/auto.conf', needed by `include/config/uboot.release'. Stop. │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ [ o.k. ] Target directory [ /home/test/output/debs/ ] [ o.k. ] Building deb [ linux-u-boot-dev-bananapim2_5.05_armhf.deb ] [ error ] ERROR in function compile_uboot [ common.sh:143 ] [ error ] Building u-boot failed, check configuration [ o.k. ] Process terminated root@ubuntu:/home/test# find / -name 'arm-linux-gnueabihf*' /usr/share/man/man1/arm-linux-gnueabihf-cpp-4.8.1.gz /usr/share/man/man1/arm-linux-gnueabihf-gcc-nm-4.8.1.gz /usr/share/man/man1/arm-linux-gnueabihf-gcov-4.8.1.gz /usr/share/man/man1/arm-linux-gnueabihf-gfortran-4.8.1.gz /usr/share/man/man1/arm-linux-gnueabihf-g++-4.8.1.gz /usr/share/man/man1/arm-linux-gnueabihf-gcc-ranlib-4.8.1.gz /usr/share/man/man1/arm-linux-gnueabihf-gcc-4.8.1.gz /usr/share/man/man1/arm-linux-gnueabihf-gcc-ar-4.8.1.gz /usr/lib/gcc-cross/arm-linux-gnueabihf /usr/arm-linux-gnueabihf /usr/arm-linux-gnueabihf/include/c++/4.8.2/arm-linux-gnueabihf /usr/x86_64-linux-gnu/arm-linux-gnueabihf /usr/bin/arm-linux-gnueabihf-g++-4.8 /usr/bin/arm-linux-gnueabihf-elfedit /usr/bin/arm-linux-gnueabihf-c++filt /usr/bin/arm-linux-gnueabihf-strip /usr/bin/arm-linux-gnueabihf-ld.bfd /usr/bin/arm-linux-gnueabihf-gprof /usr/bin/arm-linux-gnueabihf-gcov-4.8 /usr/bin/arm-linux-gnueabihf-ld /usr/bin/arm-linux-gnueabihf-strings /usr/bin/arm-linux-gnueabihf-gcc-4.8 /usr/bin/arm-linux-gnueabihf-ranlib /usr/bin/arm-linux-gnueabihf-ar /usr/bin/arm-linux-gnueabihf-nm /usr/bin/arm-linux-gnueabihf-addr2line /usr/bin/arm-linux-gnueabihf-objcopy /usr/bin/arm-linux-gnueabihf-ld.gold /usr/bin/arm-linux-gnueabihf-dwp /usr/bin/arm-linux-gnueabihf-gcc-nm-4.8 /usr/bin/arm-linux-gnueabihf-as /usr/bin/arm-linux-gnueabihf-cpp-4.8 /usr/bin/arm-linux-gnueabihf-size /usr/bin/arm-linux-gnueabihf-gcc-ar-4.8 /usr/bin/arm-linux-gnueabihf-gcc-ranlib-4.8 /usr/bin/arm-linux-gnueabihf-readelf /usr/bin/arm-linux-gnueabihf-gfortran-4.8 /usr/bin/arm-linux-gnueabihf-objdump

Since it's recommended to run build system in virtual machine, I don't think that setting apt-cacher address on target systems in build process is a good idea. It's easy enough to set this up manually afterwards. Only thing that prevents switching to ng variant by default is lack of testing and feedback. There may be problems with some boards that have unusual u-boot configuration, or with NAND/USB/SATA install script. Otherwise new process is fast and has some cool features, like FEL boot support and building images with btrfs or f2fs root filesystem.

Thanks. Sunxi-default doen't have F2FS support, it's supported only since kernel version 3.8

I almost finished adding support for building images with F2FS root filesystem (and it's relatively easy to add support for other filesystems, though I don't see the reason to do it for now), but there is small obstacle in the way - partition resizing in firstrun and resize2fs scripts. Igor, can you change these scripts so it's possible to disable resizing operation (while executing everything else, plus if no resizing is needed, you need to start resize2fs script right away at first boot instead of reboot)? Logic for disable resizing can look like this: local root_partition=$(findmnt --target / -o SOURCE -n) local rootfstype=$(blkid -s TYPE -o value $root_partition) if [[ $rootfstype != ext4 ]]; then ... Edit: or it can be just a file, i.e. /etc/.no_rootfs_resize Plus next time you will be checking kernel configs, some of them don't have f2fs enabled or it's enabled as a module, which won't work for rootfs. linux-cubox-default.config(5506): # CONFIG_F2FS_FS is not set linux-guitar-default.config(3334): # CONFIG_F2FS_FS is not set linux-odroid-default.config(3873): CONFIG_F2FS_FS=m linux-odroid-next.config(3481): CONFIG_F2FS_FS=m linux-s500-default.config(3334): # CONFIG_F2FS_FS is not set linux-udoo-default.config(3482): # CONFIG_F2FS_FS is not set linux-udoo-neo.config(3707): # CONFIG_F2FS_FS is not set linux-udoo-next.config(4171): # CONFIG_F2FS_FS is not set

Based on post "http://forum.armbian.com/index.php/topic/120-f2fs-for-rootfs/" Can be added an optional choice to build image with F2FS root? Ext4 filesystem is crap for microSD/SD card and should not be used with expected large writes for example when you are running a mysql database. or tkaiser could you please post your modified compile.sh script for this purpose?

I really don't see the main advantage of F2FS compared to ext4 with a commit interval of 600 seconds Regarding enclosures, heatsinks and fans: If you build the enclosure correctly (standing upright, use of convection, enough airflow) then not even a heatsink might be needed at all. If you look into the LeMaker forums, then a user called cyryllo (?) built a BanaNAS case for the original Banana Pi. That's the only one that doesn't ignore thermal challenges, everything he created later does a really bad job in this area as does *every* commercially available enclosure for Banana Pi/Pro. Again: SoC and PMU, the two parts that might overheat are on the bottom side of the PCB where no airflow at all is possible with this crappy enclosures. That's maybe the only advantage of the Banana Pi M1+ (trying to be a clone of LeMaker's Pro): There SoC and PMU are on the upper PCB side.

I mean combination fixed sized f2fs for at least var folder plus resizeable rest of root folder. I know about poor design of this enclosure and Banana Pro board but few heatsinks plus a fan can do. And for second there is not better solution in same price range if you want protect the board and keep all in a box. It just need stick more aluminium heatsinks from both sides of the board, an active fan cooling and some temp watching script able to lower down cpu clock or shutdown everything if fan stopped working.

Since f2fs is not resizable after the first boot it's not an option to use it as default fs for Armbian. BTW: The enclosures you ordered are crap or at least prone to overheating. On Banana Pi/Pro everything that gets hot is on the lower side of the PCB. The vents are pretty useless. Might look nice but doesn't help at all.

Thank you for your reply first. I ordered 2 sets of hdd enclosure (see link below) + Banana Pro, so I will have chance to choose better storage instead an microSD card. http://www.aliexpress.com/wholesale?catId=0&initiative_id=SB_20151215072412&SearchText=banana+hdd+enclosure Non resizable system ? It is not a problem for me because most writes go to /var folder and Igor's boot stuff is not ready to live on root of separate boot folder and survive upgrades. So I think fastest option is build system with separate var on f2fs and rest of root can be left on resizeable ext4. Sizes can be for example 2GB for var and rest for root. If you want to use an desktop enviroment it is good to have /home folder on f2fs too.

Nope, since all I have is my diff from back then: http://pastebin.com/hidkugaG Please keep in mind that Igor sets a large commit interval for ext4, that you should think about using different storage than SD card if you want to do serious stuff and that F2FS is still not resizable so a general switch to it seems no good idea since you've to know the size of your installation medium prior to running the build script. It should be quite easy to adjust Igor's current build scripts based on the infomations from the aforementioned thread (at least that was my hope and why I documented the stuff in detail).

One solution that's perhaps easier, that doesn't require as much edits to the build environment, is to simply go through the usual compile.sh process (using the default ext4 for root) and convert post installation. This way you don't need to worry about partition resizing, and it gives you the option to encrypt root as well. You'll only want to ensure that the BOOTSIZE parameter is not 0, so that separate /boot and / partitions are created in the image. For the BananaPi, I used 16MB as you did. Once you've put the image on an SD card and gone through the initial boot, use a USB flash drive (or SATA drive) to temporarily mount as root. To do this, create a single ext4 partition on the USB drive, mount it (e.g. mount -t ext4 /dev/sda1 /mnt/usbdrv) and copy the contents of root to it (e.g. rsync -arx / /mnt/usbdrv). Now edit /boot/boot.cmd and set the root device as /dev/sda1 (assuming that's the partition you just copied root to). Rebuild the boot.scr (i.e. mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr) and reboot. You'll notice that the USB drive (or SATA) is now mounted as /root. This allows you to easily re-format the former root partition on the SD card (e.g. /dev/mmcblk0p2) as f2fs, with the ability to optionally encrypt the root partition using cryptsetup before you format it as f2fs. And it will preserve the size of the former ext4 partition, so no need to worry about the possible lack of f2fs resizing. Once you've mounted (e.g. to /mnt/sdcard) and copied the root files back over to the newly formatted /dev/mmcblk0p2 (e.g. rsync -arx / /mnt/sdcard) edit the /etc/fstab file on the sdcard to properly mount root using f2fs (e.g. /mnt/sdcard/etc/fstab) then you can just edit the /boot/bboot.cmd file to point back to /dev/mmcblk0p2, recreate boot.scr, take out the UBS flash drive, and reboot. If you do opt for encryption, you'll need to also edit crypttab (e.g. /mnt/sdcard/etc/crypttab) and edit the boot.cmd to reflect the use of an encrypted root (e.g. root=/dev/mapper/cryptroot cryptdevice=/dev/mmcblk0p2:cryptroot).

Last update: I tried to test the USB3 storage performance of the Guitar. For whatever reasons the Guitar as a host device features one single USB3 port in Micro-B fashion (instead of the well known Type A female port). I ordered an adapter cable and when I connect this with a JMicron JMS567 equipped drive enclosure behind containing my EVO 840 test SSD... nothing happens (only an error message according to dmesg output... maybe related to USB ). [ 282.104622] temp:52 [ 284.104580] temp:52 [ 285.874259] 1803: RX_ERROR status:0x0046832a root@Lemuntu:/home/lemaker# lsusb unable to initialize libusb: -99 Since LeMaker hides somewhere on their web site a warning regarding USB 3.0 ("This version currently supports not perfect for USB3.0, the next version will fix") I won't waste my time any longer with this device and consider USB 3.0 as being broken. To sum it up: this is a SBC with an interesting concept given the hardware would be Open-source hardware (OSH) (which is not the case) but very limited at the time of this writing (both network and storage being slow as hell and consumption unnecessary high). Given the quality of documentation available and the (non existing) availability of development ressources at the time of this writing it's not worth to spend any more time on this. If LeMaker will sometimes in the future release U-Boot and kernel sources and provides a base board containing an internal USB3 hub and both an ASIX AX88179 and a JMicron JMS567 (to provide GBit Ethernet and an UAS / SAT capable USB3-to-SATA bridge) and if LeMaker or the (yet non existing) community manages to fix the issues with Actions Semi's outdated 3.10.37 kernel, then it might be worth a look again (for me). Since there seems to be no efforts regarding mainline kernel support having to use this outdated 3.10.37 kernel means being cut off from important developments like modern filesystems (btrfs, F2FS and so on), basic features (consider broken UAS support over many years in Linux or the USB/ext4 fixes in 3.10.78 LTS) or even device drivers that require a more recent kernel version. Might apply to a bunch of unfixed kernel security flaws as well.

Oh Sorry tkaiser, im reading everything here and thought there was no thread about f2fs yet. My fault. Everything regarding f2fs for CT/BananaPi is already there, thanks!

What do you mean with 'vanilla'? There's legacy (3.4) or mainline (4.x). With the latter it might be an idea. But a much better idea would be avoiding writes at all (write commits only every x minutes, ramlog). For results have a look at http://forum.armbian.com/index.php/topic/243-debian-jessie-on-bananapi-logging-performance/?p=1455 http://forum.armbian.com/index.php/topic/120-f2fs-for-rootfs/ http://www.lemaker.org/thread-15477-1-1.html

You might also run into this error if for whatever reasons the rootfs is set read-only: I made this experience myself when fiddling around with other FS for the rootfs: http://forum.armbian.com/index.php/topic/120-f2fs-for-rootfs/?p=573 In case you're always using the same SD card I would first test whether it's physically ok. Use either H2testw or F3 on Linux or OS X.

Thx, great job. I hope the URL remains since I will link often to it Regarding the filesystems. In my opinion btrfs is only interesting for disk storage (SATA, USB) and for people who know what they do (creating snapshots, transferring these snapshots incrementally using 'btrfs send/receive' to other disks/machines and so on -- all this has drawbacks, for example getting a clue how much space is really available on the disk in question). So regarding btfrs this is more a candidate for nand-sata-install: Allowing to use btrfs for sda1 and recommending to partition the disk prior to that and to use a separate partition for / and for other/media data (since using snapshots this makes backing up everything way more easy). Regarding F2FS: It should be superiour compared to ext4 when used on NAND/SD Cards or other flash based media. But I'm still not convinced whether it's worth the efforts since the resizing problem remains. Would be great to be able to choose it optionally but I doubt that it's ready for your normal OS images. Regarding cpufreq stuff: This remains the same in mainline: You can adjust the sysfs values as you want but all values will be rounded down in 48 MHz steps. BTW: I will try to add a few additional operating points in arch/arm/boot/dts/sun7i-a20.dtsi to slightly 'overclock' some A20 boards: operating-points = < /* kHz uV */ 1200000 1600000 1152000 1550000 1104000 1500000 1056000 1450000 1008000 1450000 960000 1400000 912000 1400000 864000 1300000 720000 1200000 528000 1100000 312000 1000000 144000 900000 >; I'll report back if I find anything interesting (A20 specs say that 1.4V is max.)

This FAT boot partition is solved half way - scripts need to be adjusted manually, the rest works. I thought I left a note in configuration but I didn't Nice job. btrfs should be resizeable but not with resize2fs so this part is solvable. f2fs probably too. On the other hand I manage to write a script manual v1.0 I'll fix this asap. Oh, this is intentionally. Some people want to have fat boot partition to be windows accessible. I'll rather do it configurable then. Not sure out of my head how is this on mainline.