zador.blood.stained

@gnasch
 
If modprobe doesn't see a module present in kernel tree, you may need to run "depmod" (as root) to update module list that modprobe relies on.

More about NanoPi M3 - USB ports are behind USB hub...
 
Very specific board with high enough price, "Applications" tab on their site tells enough use cases where this price is OK. Unless you need FPGA  or RISC co-processor and you know how to work with this stuff, you don't need this board.
 
Using as headless server: NAS with 2 HDD drives for storing stuff (Samba, rsync, syncthing), headless music server (mpd controlled via IR remote or Android app).
 
Waiting for Ethernet and USB support in mainline kernel, meanwhile it's useful for testing intermediate Armbian releases.
 
Waiting for the bright future (at least mainline u-boot with SPL and basic support in mainline kernel).
 
Turn lights on and off with IR remote using connected IR sensor and nRF24L01+ module
Display stuff (weather forecast, date&time, new e-mail notifications and some other things) on HD44780-compatible LCD display.

Hope for what?
 
For another board with microUSB connector for power input? (Though it can be powered through GPIO pins too)
Or for another SoC with no mainline support in near future (Samsung S5P6818)?
 
I don't see that many common use cases for 8 cores with 1GB RAM, no native SATA or USB 3.0 or at least USB2.0+UAS, especially for its price.

More about NanoPi M3 - USB ports are behind USB hub...
 
Very specific board with high enough price, "Applications" tab on their site tells enough use cases where this price is OK. Unless you need FPGA  or RISC co-processor and you know how to work with this stuff, you don't need this board.
 
Using as headless server: NAS with 2 HDD drives for storing stuff (Samba, rsync, syncthing), headless music server (mpd controlled via IR remote or Android app).
 
Waiting for Ethernet and USB support in mainline kernel, meanwhile it's useful for testing intermediate Armbian releases.
 
Waiting for the bright future (at least mainline u-boot with SPL and basic support in mainline kernel).
 
Turn lights on and off with IR remote using connected IR sensor and nRF24L01+ module
Display stuff (weather forecast, date&time, new e-mail notifications and some other things) on HD44780-compatible LCD display.

This shouldn't affect anything - this is free space checking that works on Xenial, I'll add error silencing in case this is running on Trusty later.
 
If you are experiencing errors with building kernel, then your patch is probably causing this. Wiki info may be outdated. You can add "PROGRESS_LOG_TO_FILE=yes" to compile.sh and then find exact error message in compilation log.

You are using mainline kernel where GPIO numbering is different and FEX settings have no effect.
 
In your case network dies because GPIO 1 maps to PA01, which is used by EMAC core.
 
Please check this page for pin numbering scheme (section "Accessing the GPIO pins through sysfs with mainline kernel"). For example PG02 will be GPIO 194.

Except that BCM2835 in RPI Zero isn't ARMv7, it's ARMv6 (@0:40 in video) 
But it's hard to compare to the board that you can't buy for its price (without additional "starter kit" crap): http://whereismypizero.com/

Except that BCM2835 in RPI Zero isn't ARMv7, it's ARMv6 (@0:40 in video) 
But it's hard to compare to the board that you can't buy for its price (without additional "starter kit" crap): http://whereismypizero.com/

I don't expect any H3 board to survive at full load in a small box made of anything that doesn't conduct heat well or without enough holes at the top and bottom.
 
In same hellish conditions?
 
BTW, please look at your logs and cooler table. You want cores to be killed at 240MHz, but frequency doesn't go lower than 480 probably due to limits defined in /etc/default/cpufrequtils and/or FEX file DVFS table. 
 
Edit; First 5 lines with 240MHz @ 51-52°C are probably due to data collection starting before cpufrequtils applied its settings.

Prebuilt kernel: https://www.dropbox.com/sh/d55gb7gfjpaika3/AAB9LjYI4RqrPBGR0uEXWuWta?dl=0
 
For testing it's recommended to disable userspace corekeeper by editing /etc/rc.local
 
Please also post dmesg log here in spoiler and code blocks or on pastebin or similar service.

I wonder if you're deep enough into intercultural differences to understand anything? At least I'm not and I consider many things that happen in China as a miracle (and I would suspect that's the same regarding us Westerners when looking at us from China).
 
You should be aware that you're not an Allwinner customer and that this whole SBC thing is close to irrelevant for them. The vast majority of their customers produces Android devices and Allwinner supports them as much as they can. Compared to this large Android market the count of Allwinner SoCs used with Linux is laughable (even if you consider customers like Olimex that order tens of thousands for boards used in industrial environment).
 
Considering this I even understand that Open Source proponents inside Allwinner might have a hard time. But it seems there are some since they do release their kernel sources (even if there are some BLOBs inside). Please keep in mind: This whole issue has been discovered since we were able to audit the code (different story is that they could help us with better commit logs and so on but at least looking through nearly all code is possible).
 
I really hope that this incident doesn't stop Allwinner opening even more code (with useable licenses and not just "All rights reserved") since even if the Linux market seems to be small/irrelevant they get so much back from linux-sunxi community (better code, mainline kernel code and also a better reputation since most older Allwinner SoCs run perfectly fine with mainline kernel due to community's work. And support for the most recent ones is progressing nicely. An Armbian image with mainline kernel for H3 boards is not that far away since linux-sunxi community does such a great coding job!).
 
So let's stop speculating/badmouthing and hope for the best instead! 

Orange Pi there is running Armbian, small kernel patch was necessary to enable CDC mode in crappy BSP kernel. USB tethering on smartphones may use other modes (like RNDIS).
 
Once USB OTG controller is supported in mainline, it should work without any patches.

Not my experience, but in this article Orange Pi One is mounted inside a router (running OpenWRT) to offload OpenVPN encryption. It's connected only via USB/CDC, and raw link speed was ~100-120Mbit/s. Even without translation you should get the idea looking at photos and screenshots.

Not my experience, but in this article Orange Pi One is mounted inside a router (running OpenWRT) to offload OpenVPN encryption. It's connected only via USB/CDC, and raw link speed was ~100-120Mbit/s. Even without translation you should get the idea looking at photos and screenshots.

In addition to this (just to have all useful info available here), compared to OPi One it has built-in microphone, 2 USB A sockets and IR Receiver.
Wi-Fi module is Realtek b/g/n of some sort with external antenna (u.FL socket), no "onboard" antenna.

Original BSP kernel is designed for Android, where getting root privileges in "one click" would be very useful for testing and debugging purposes...
... if only there was a simple way (even kernel config symbol!) to disable this for production / public images.

Original BSP kernel is designed for Android, where getting root privileges in "one click" would be very useful for testing and debugging purposes...
... if only there was a simple way (even kernel config symbol!) to disable this for production / public images.

8G Class4

[dvfs_table] pmuic_type = 1 pmu_gpio0 = port:PL06<1><1><2><1> pmu_level0 = 11300 pmu_level1 = 1100 max_freq = 1200000000 min_freq = 480000000 LV_count = 5 LV1_freq = 1200000000 LV1_volt = 1300 LV2_freq = 1008000000 LV2_volt = 1300 LV3_freq = 816000000 LV3_volt = 1100 LV4_freq = 648000000 LV4_volt = 1100 LV5_freq = 480000000 LV5_volt = 1100 This seems to work without any issues after changing minimal frequency in /etc/default/cpufrequtils

BTW: The FriendlyARM folks were the only paying attention to this security flaw and now do it exactly that way: https://github.com/friendlyarm/h3_lichee/commit/5d4d02b1c8f336ba002eed4d97dee3a51ea76cdd

If you create directory for mounting in /tmp and add an entry to fstab, then after reboot your directory in /tmp will not be there and your fstab entry will be incorrect.
 
If you create directory on SD (i.e. in /media or /mnt), as long as your HDD is mounted, writing to HDD won't produce writes to SD card.
 
"mounting" operation itself may update access time on directory (which results in small write to SD) but in Armbian rootfs is mounted with "noatime,nodiratime" options, so it won't try to update access time in this case.

You can build Xenial image with build tools or I can build an image and put in on Dropbox or Google Drive. Do you want legacy or vanilla kernel?
BTW, SSH is always preinstalled.

@leonidy-85
 
What is your build host OS release?
 
In case it is 15.10 Wily (x64) or 16.04 Xenial (x64), you need to install linaro 4.9 toolchain to compile u-boot for C1.
Next to "lib", "userpatches", "output" and "sources" there should be "toolchains" directory.
cd toolchains wget "https://releases.linaro.org/components/toolchain/binaries/4.9-2016.02/arm-linux-gnueabihf/gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf.tar.xz" tar xf gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf.tar.xz and repeat compilation.

1.) I think this should work. Need to check.
2.) we tend to provide basic and clean image so this will remain up to user decision. Not everyone needs samba.

First, boot from SD as usual and check output of "blkid". If your USB drive with rootfs has PARTUUID that looks like this "0004cde8-01", then insert this to your kernel command line in boot.cmd, recompile it and try booting again.