zador.blood.stained

@Igor @wildcat_paris
Maybe it's best to move all device-specific discussion to separate topics for each device (A13-SOM, Clearfog(s), XU4)? This topic is already 7 pages long and it's hard to keep track of things that are going here. I mean also moving messages that are already here, this forum engine should support that.

The latter. RPi-Monitor showed me values between 1.16W when idle and 1.84W when running iozone or sysbench (both too low). But since this might be my mistake I'll double check later. BTW: I stumbled accross this an hour ago: https://github.com/ssvb/linux-sunxi/commit/c0a2252427800aad66fafc27951579e58d84fbf2

It's probably related to different device class ("power supply" vs "sensor" or "hwmon"). I'll add multiplier in the next version for the sake of consistency.

For me SBC named "something pi" is clearly targeted for Raspberry Pi audience, especially for people that are buying a new toy to play with for a week and forget about it later.
For these people news like "something-else pi" now supports kernel 4.4 doesn't mean anything,
while "something-else pi" version 2 is released, now with 4 cores instead of 2 (2 GB RAM instead of 1, 64 bit instead of 32 or something similar) would cause a reaction like "shut up and take my money  ".
 
Raspberry Pi isn't perfect, for example there aren't public datasheets for BCM2835/BCM2836, and most of software support, I believe, is still done by the community. I wouldn't call it "stable for years" either. But compared to some boards discussed here in "Free" forum section, it's still great.

@Tido
Just to clarify.
Raspberry Pi came into this world as a new concept, a (relatively cheap) single-board computer that has GPIO, SPI, I2C and other interfaces to be used somewhere where Arduino won't be enough, and at the same time it can run Linux distribution with a lightweight desktop environment and hardware video acceleration. They worked hard to get software support for the community and now community is working for them.
Link I provided just shows that community is not all-powerful and issues like this probably would be resolved much quicker with support from Broadcom.
 
Now market is saturated with all kinds of SBCs, Raspberry Pi is still a major player here, and other companies that want to get profit sometimes use "dirty" tricks like not spending money on software support or naming their brand similar to another.
 
TL;DR Raspberry Pi probably wouldn't fly without software support, but companies that are trying to get a piece of this market now may decide to spare some money on this.

For me SBC named "something pi" is clearly targeted for Raspberry Pi audience, especially for people that are buying a new toy to play with for a week and forget about it later.
For these people news like "something-else pi" now supports kernel 4.4 doesn't mean anything,
while "something-else pi" version 2 is released, now with 4 cores instead of 2 (2 GB RAM instead of 1, 64 bit instead of 32 or something similar) would cause a reaction like "shut up and take my money  ".
 
Raspberry Pi isn't perfect, for example there aren't public datasheets for BCM2835/BCM2836, and most of software support, I believe, is still done by the community. I wouldn't call it "stable for years" either. But compared to some boards discussed here in "Free" forum section, it's still great.

Looks like u-boot 2016.01 was released, will check changelog later.
 
Edit: Nothing interesting apart from Lamobo-R1 support, so it's minus one u-boot patch.

Unfortunately (for the community) from business perspective for SBC manufacturers investing money in software support won't give as much feedback in money/revenue as investing, for example, in marketing - advertisements, paid and free samples reviews and so on. At least in a short term perspective.
In a long term, when perception of company's name associates more and more with crappy support, they can simply rename their company and new boards to "something-else pi" and start from scratch with "clean" karma.

AXP202/209 sysfs interface patch for axp20x MFD drvier in mainline kernel
 
 
âžœ ~ % ls /sys/power/axp_pmu/{ac,vbus,battery,charger,pmu,control,ocv_curve} /sys/power/axp_pmu/ocv_curve /sys/power/axp_pmu/ac: amperage connected used voltage /sys/power/axp_pmu/battery: amperage capacity charge charging connected power ts_voltage voltage /sys/power/axp_pmu/charger: amperage cell_activation charging low_power /sys/power/axp_pmu/control: battery_rdc disable_fuel_gauge set_vbus_direct_mode charge_rtc_battery reset_charge_counter /sys/power/axp_pmu/pmu: overheat temp voltage /sys/power/axp_pmu/vbus: amperage connected strong used voltage âžœ ~ %  Shortlog:
 
 
 
How to test:
Patches for next and dev branches are included in Armbian build framework, use standart procedures to build and install new kernel.
.. or you can download this prebuilt kernel for next branch.
Latest version of the patch, basic documentation and battery calibration utility are available on GitHub.
 
TODO list:
Find and fix bugs.
Check if can be converted into a separate kernel module, preferrably power supply class driver.
 
Limitations:
AXP202/AXP209 only for now.
Things are implemented according to datasheet and my understanding of it.
 
Default settings for main battery according to datasheet:
Target voltage: 4.2V
Charging current: 500mA/1200mA (?)
 
Defaut settings for RTC battery:
Charging: disabled by default.
Target voltage: 3.0V
Charging current: 200uA
 
Standart disclaimer:
Code looks simple enough, but i wouldn't recommend using it on production environment yet. Bugreports are welcome, but I'm not responsible for kernel panics, lost data and exploded PMUs.
 
 

@all
FYI, kernel 4.4.0 is out
 
Tested USB OTG on cubietruck; OTG autodetect and vbus (automatically enabling power on OTG port when OTG cable is plugged in) works with some extra kernel modules, will upload my kernel config later.
As a side-effect, I can use onboard miniUSB port as a serial console (only after systemd starts necessary getty service, of course).
Onboard audio works if DMA driver is loaded via /etc/modules or if it's compiled as built-in.
 
Edit: extras for /etc/modules:
# sunxi musb OTG sunxi # serial gadget (old) driver - required g_serial # ACM - for serial port emulation usb_f_acm Edit 2: For Debian Jessie (or stretch) gadget serial device name is /dev/ttyGS0, so command to enable it would be
sudo systemctl enable getty@ttyGS0.service

@all
FYI, kernel 4.4.0 is out
 
Tested USB OTG on cubietruck; OTG autodetect and vbus (automatically enabling power on OTG port when OTG cable is plugged in) works with some extra kernel modules, will upload my kernel config later.
As a side-effect, I can use onboard miniUSB port as a serial console (only after systemd starts necessary getty service, of course).
Onboard audio works if DMA driver is loaded via /etc/modules or if it's compiled as built-in.
 
Edit: extras for /etc/modules:
# sunxi musb OTG sunxi # serial gadget (old) driver - required g_serial # ACM - for serial port emulation usb_f_acm Edit 2: For Debian Jessie (or stretch) gadget serial device name is /dev/ttyGS0, so command to enable it would be
sudo systemctl enable getty@ttyGS0.service

@all
FYI, kernel 4.4.0 is out
 
Tested USB OTG on cubietruck; OTG autodetect and vbus (automatically enabling power on OTG port when OTG cable is plugged in) works with some extra kernel modules, will upload my kernel config later.
As a side-effect, I can use onboard miniUSB port as a serial console (only after systemd starts necessary getty service, of course).
Onboard audio works if DMA driver is loaded via /etc/modules or if it's compiled as built-in.
 
Edit: extras for /etc/modules:
# sunxi musb OTG sunxi # serial gadget (old) driver - required g_serial # ACM - for serial port emulation usb_f_acm Edit 2: For Debian Jessie (or stretch) gadget serial device name is /dev/ttyGS0, so command to enable it would be
sudo systemctl enable getty@ttyGS0.service

It didn't apply or it was force overwritten, There shouldn't be -P option now.

@Zador
 
  I just forgot to remove/comment the line with "losetup -P" otherwise the process is fine -- my BAD
 

Then it may be 
KERNEL_DEV='https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux' or
KERNEL_DEV='https://github.com/torvalds/linux.git'

I see... losetup -P option must be missing in Trusty   Will fix in a moment
 
Edit: Fixed
 
Edit 2: Tested. Should work if boot partition size is increased to 32M to have enough space for 2 copies of zImage (I mean for all devices that have FAT /boot partition).
 
@wildcat_paris
 
 

Clearfog PRO with R1 in the back
 
After a day of playing, I am running full featured Armbian, Debian Wheezy, built with Armbian script from sources. We had to fix few things in U-boot and upgraded kernel to .82 but generally it was easy to boot the board. Of course SolidRun also provide some basic images.
 
Three(3) phys, USB and PCI is detected in kernel 3.10.82 - I don't have much hardware to plug in so I can't do much tests at this point. There is no CPU governor (yet?), so I assume it's running full speed (1.6Ghz) all the time. There are dip switches on the board to set cpu / dram speed ...
____ _ __ / ___| | ___ __ _ _ __ / _| ___ __ _ | | | |/ _ \/ _` | '__| |_ / _ \ / _` | | |___| | __/ (_| | | | _| (_) | (_| | \____|_|\___|\__,_|_| |_| \___/ \__, | |___/ Welcome to ARMBIAN (Debian wheezy 3.10.94-marvell) Last login: Sat Jan 9 10:11:28 2016 from desktop Load: 0.00, 0.01, 0.05 - Board: 64.6°C - Memory: 973Mb root@armada:~# Waiting for:
I decided to drop idea to put an AC card into the board since it's simply too problematic and expensive (66USD). This card doesn't have support in legacy kernel, in 4.4 have no idea if everything else already works + I have only one AC device in the lab. The Wireless card I choose is not fresh new but it's cheap (14USD) and reported working on Linux: Atheros AR5BXB112 AR9380 450Mbps. If I get stability and around real 300Mbps is good enough.
 
M2 drive. I'll put one 128G INSSD128GM.26M2242 TRANSCEND MTS400 128GB SSD SATA3 M.2 2242 TS128GMTS400 which should be big enough for most cases.
 
Mpci2sata for one ordinary SATA. 
 
SFP module. Haven't found the proper one yet.
 
With Armbian tools it's possible to build (I collect and fix all patches) and should be possible to boot kernel 4.3.3 and 4.4 - next.
 
Network performance (over TP link switch). 
Windows desktop -> Clearfog [ 3] 0.0-10.0 sec 1.09 GBytes 938 Mbits/sec [ 3] 0.0-10.0 sec 1.07 GBytes 922 Mbits/sec [ 3] 0.0-10.0 sec 1.09 GBytes 938 Mbits/sec Clearfog -> Windows desktop [ 4] 0.0-10.0 sec 1.04 GBytes 889 Mbits/sec [ 5] 0.0-10.0 sec 1.02 GBytes 878 Mbits/sec [ 4] 0.0-10.0 sec 1.03 GBytes 882 Mbits/sec To be continued ...
 
Edit #1: Board boots with 4.3.3 / Eth: no, USB: yes, mPci: yes
Edit #2: Jessie image download
Edit #3: Legacy kernel upgraded to 3.10.94
Edit #4: Network performance
Edit #5: If eth0 connected to gigabit, + cca. 2°C more heat on CPU in idle
Edit #6: mSATA is working with patched U-boot
Edit #7: mSATA and mPCI can be enabled in any combination. Tested one wireless card ...
Edit #8: boot time when installed to low performance 32Gb mSATA, power -> Login prompt <= 10s, (-3s waiting at u-boot) = cca. 7sec
Edit #9: I2C working out of the box. Tested with display, communication is slow. Perhaps only the settings
Edit #10: USB somehow buggy on current legacy kernel. I was trying to use Temper to collect temperature ... it worked once, next reading hang the device and I need to unplug / plug. Haven't debug. USB flash memory working normal.
Edit #11: Added cpu freq scalling 800/1600Mhz -> less heat in idle
Edit #12: Kernel 4.3.3 & 4.4 / Eth: yes, USB: yes, mPci: yes, mSata: yes ... and doing preliminary testing with Atheros AR9380 N wireless card // Kernel not ready yet
Edit:#13: Added mSATA to SATA card, patch a driver to unlock cheap - (consumer grade!, 13 USD shipped) AR9380 AR5BXB112 wireless card to operate at 5Ghz. Running STABLE
Edit:#14: Booting from m2 120G SATA drive
Edit:#15: Measuring temperature on the edge of heatsink = 39-42 while ambient is around 20.
Edit:#16: Added external 2.5 inch mechanical SATA drive powered from Clearfog +5V from header

@wildcat_paris
It's optional and disabled by default, so unless you added EXPERIMENTAL_DEBOOTSTRAP=yes, it was the old process.

@Igor renamed odroid name several times, guess he forgot to rename kernel config files:
linux-odroidxu-default.config -> linux-odroidxu4-default.config and so on.

Try executing this:
cd /usr/src/linux-headers-4.3.3-sunxi make scripts and if there are no errors then repeat your module compilation
 
Edit: I see only mt7601u in mainline source tree, don't know if it supports this wireless module.

I didn't try kernel compilation since u-boot failure terminated script before that.
I don't think that any device is designed to use soft-float u-boot with hard-float kernel, it's either this or that.
 
Manual compilation is working, but it won't work in Armbian build script since you need to change "arm-linux-gnueabihf-" to "arm-linux-gnueabi-" in make parameter, and possibly compilation target and u-boot file name for packaging. Plus this patch is required.
 
Edit: I'm referring to this page for make targets.

@Igor, what do you think about moving MAINTAINER, MAINTAINERMAIL, GPG_PASS and maybe ROOTPWD to configuration.sh or to main.sh - to keep compile.sh small and simple, I don't think these options are useful to people who just want to compile new kernel.

@wildcat_paris
Bug, already fixed, but didn't push changes to github, partly because it actually doesn't break anything.

cd /usr/src/linux-headers-4.3.3-sunxi make scripts And try again.
 
BTW: this driver is already inside kernel.

Try executing this:
cd /usr/src/linux-headers-4.3.3-sunxi make scripts and if there are no errors then repeat your module compilation
 
Edit: I see only mt7601u in mainline source tree, don't know if it supports this wireless module.