lanefu

Uhhhh yeah.. so uhm batteries.   Keyboard is good!

My Tritum h5 board came.   I just built an image from Dev branch using Tony's tritium-5.csc. w/ Kernel 4.14.43     Fired right up..... Even has console login on HDMI.   (although its not returning keystrokes at the console)
 
but I ssh'd in an all is well.    
 
Trying to understand a bit more about regression bug.   I'm running at 1.01ghz.  Is that related to regression bug?   Basically trying to understand on how I can help achieve parity with the Clock on my Opi PC2 or Prime. etc

Correct. A bit strange. There is a dw-hdmi patch that needs a fixup, but I tried to to no effect.

@Igor my support patches for this board do the opposite of the OPi PC2 image I tried, I get debug console with uboot on mine, but no kernel hdmi, the opi image made today has no uboot hdmi but does have kernel.  I'm sure I'm doing something ridiculous...  Any argument about uploading as CSC even though it's headless?  it's only a csc, uboot and kernel patch to add the dts's?

Hi all,
 
Just wanted to share that I got the realtime patch working on an Orange Pi Zero on 4.18.8
I used the armbian build environment and the official RT patch.
 
A few tricky points were the CPU govenor and CPU operating points automatically switching by default, causing the realtime behavior to be really bad (max spikes around 3000 in cpu test).
By patching the device tree to only use a fixed operating point, I achieve the following output:
Linux orangepizero 4.14.8-rt9-sunxi #1 SMP PREEMPT RT Sat Jan 6 14:36:31 CET 2018 armv7l armv7l armv7l GNU/Linux /root/rt-tests/cyclictest -p 80 -t5 –n # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.85 0.49 0.22 4/168 3083 T: 0 ( 3079) P:80 I:1000 C: 3297 Min: 8 Act: 17 Avg: 16 Max: 66 T: 1 ( 3080) P:80 I:1500 C: 2198 Min: 8 Act: 24 Avg: 15 Max: 50 T: 2 ( 3081) P:80 I:2000 C: 1648 Min: 8 Act: 11 Avg: 16 Max: 60 T: 3 ( 3082) P:80 I:2500 C: 1318 Min: 8 Act: 12 Avg: 15 Max: 44 T: 4 ( 3083) P:80 I:3000 C: 1098 Min: 9 Act: 17 Avg: 18 Max: 57  
If anyone is interested, I used this realtime kernel to run a virtual wifi guitar amplifier on the orange pi zero.
I documented the entire thing on http://arre234.blogspot.be/2018/02/linux-portable-wifi-guitar-amp-on.html , including the device tree and cpu govenor stuff.
 
Hope this helps anyone
 
Arnout

@lanefu, for now the 1st is a raid1 samba local share and ovpn seedbox.
I'm very happy with it. 
 
The second one will be a little jeedom box for my home domotic stuffs. 
 

Release the libVA improvements when the kernel driver patch series is ready for submission, sometime next week. read more here: https://bootlin.com/

Hello all.
I've made a video about the Rock64. I've tried different distro's, but Armbian was the best for me.
The only problems I've found was that Synaptic Package Manager didn't work. It crashes when I press the search button. And sometimes surfing was extremely slow. Otherwise it did fix all the problems I've had with the other distro's I've tried.
Thank you for all the great work.

Now I've started my research with the Orange Pi +2, and again Armbian is the best choice.
Greetings, NicoD

Here is my video.

 

This topic is a response to the growing number of kernels, growing number of boards with... "unique properties", and for the increased complexity of some platofrms (aarch64 and the atf, etc).  I think the coherency of the chosen organizational method is starting to fall apart.
 
So just a thought experiment on my part:
 
Currently, we have a sources directory, and the sources file has not just sources, but also executable script functions in it.  We also do our patches per SoC, mostly, but the organization is by the thing being compiled rather than by the target, making finding/adjusting a bit cumbersome in some cases. 
 
I would propose a directory tree looking something like this:
 
├── RK3288 │   ├── kernel │   │   ├── default │   │   ├── dev │   │   └── next │   ├── miqi │   ├── tinkerboard │   │   ├── kernel │   │   │   ├── default │   │   │   ├── dev │   │   │   └── next │   │   └── uboot │   │   ├── default │   │   ├── dev │   │   └── next │   └── uboot │   ├── default │   ├── dev │   └── next └── S905 In this case the organization is by SoC, then by board.  All patches safe for the entire board population get put in the SoC-level kernel and uboot patch folders, anything unsafe (hardkernel-specific patches, Tinker board specific patches) go into the board-level folders.  To reinforce that we want those folder to be "last resort", we could call them "C2_bugs, Tinker_bugs" etc.
 
For our 64-bit targets, the trusted firmware would likewise have it's directory.  I think it might also make for a lower barrier to entry on committing fixes, I still worry about patching things when I don't have all the boards to test on, this way, as a novice or as someone doing something that I can't test on other hardware, I can drop the patch into the board(s) I have, then they can be evaluated by the other devs on the remainder of the hardware.
 
My particular set of boards benefit this way:
 
Tinker board specific patches are many, integrating them safely is one of the biggest reasons we lag the vendor kernel, changes to the architecture files, changes to rk3288.dtsi instead of just to rk3288-minarm.dts, changes to various drivers for specific hardware issues, etc etc etc etc. Differences in gxbb vs gxl Meson64 devices.  Most of these coexist peacefully, but then you have vendor issues with u-boot of the C2, K2, etc (everyone has their own bootloader blobs)  
I'd say we organize bootloader scripts similarly, rather than having executable scripts in the sources file we could place an include in the appropriate board folder covering the specifics. For example, if a board ships with a SPI boot flash, we don't need to burn u-boot, only provide the proper configuration of partitions/etc. That might be the only board in the series (an unusually awesome H3 board, for example).
 
Ideally, at that point, adding a new board would require a new board definition file, and then the proper patches folder. 
 

https://www.cnx-software.com/2018/03/27/turris-mox-is-a-modular-router-with-wifi-ssd-lte-modem-ethernet-and-sfp-fiber-modules-crowdfunding/#comment-552639

I've done some load testing of my first prototype power "mezzanine" board (can't say "hat")    The voltage drop of powering the RPi touchscreen off of the GPIO while the tinker is on micro-USB is insane, I was reading 3.9 Volts on the USB ports when I ran minerd --benchmark.  I may have finally worn out the Micro-USB connector...
 
This is a project for learning the ins and outs of kicad and get an idea of the capabilities of the PCB houses I have reasonably fast access to (Chinese ones unfortunately always get stuck in customs for a week or more on top of the normal shipping and fab times, so the cost savings is lost in time)  I have some more interesting things in mind, but I thought I'd start out (very) small.  The input is protected by the recommended ideal diode circuit from the RPi guys, stress testing didn't even make it warm.  If a better solution is needed, it can obviously be designed, but this is extremely cheap all things considered and that was part of the G&O for this project.
 
By comparison, using this GPIO board to power everything resulted in a minimum 4.8 volts while also powering a USB 2.0 spinning disk HDD. (lower than I'd hoped, I'm going to make some adjustments to see if I can squeeze a bit more out once I get the redesigned version 2 back, I forgot about the temperature rise factor... )
 

 
One of the issues goes back to our friends at RPi, the 5V pins are on the outside edge, so you have to go around the inner row to get to them.  This complicates moving big conductors around somewhat...
 
The chip in the back is a SPI NOR for booting the Tinker (experimental, I threw it in there as an experiment and never actually performed the experiment...)  I'll probably wipe it from the board, perhaps leave an 8-pin SMT-adapter-sized pattern to the SPI for the adventurous.
Power supply used here is the Odroid XU4 supply.  This initial run has no overvoltage or overcurrent protection.  And I need finer tipped soldering iron... 
 
I'll GitHub this one after some cleaning and citation of sources, normal disclaimers for those who want to build one.  I will have moved one of the USB ports though since @chwe happily pointed out that Y-cables don't reach that far to get from the real ports to the power-only ones...  (oops)
 
Boards successfully powered by this configuration (I don't / can't own one of everything... ):
Tinker Board Le Potato NanoPi K2  (Already has a barrel jack, by the way, but you never know, maybe you want the bigger one)

I'm a little disappointed, I would have expected 10 GbE. 
 
To code for the flat memory model Intel SoC:  http://flatassembler.net/

Still not nearly as impressive as the new GPU solutions for Pine64, for people who don't like the Mali 400:


 

I have a second round prototype of a power mezannine board at fab, after some testing I'll let folks know how it goes.  Would be far superior (read, safe) to plumbing unfiltered power to the GPIO.

Thank you for providing dev samples already weeks ago. We've been working 24/7 to support this awesome board from day one!

Hi guys!
Thought I'd let you know about a new board that I've just released - called the mmBoard.
Has all the features that SBC hackers have been wanting, plus more.
 
https://www.mickmake.com/post/announcing-the-mmboard-a-mickmake-sbc-with-all-the-goodies
 
Let me know if there's any questions about it. Would be happy to answer them.
 

And for those who prefer a video, you can check out my video here:
 

I was able to get ROOT rights to Android from Xunlong image(OrangePi OnePlus), and install GAPPS!
1. Remove the boot.img from this firmware
2. Install the Magisk Manager and patch boot.img
3. Turn on USB0 mode in the developer settings
4. Run adb and reboot into the bootloader
5. Flash patched_boot.img via fastboot 
Then install GAPPS manually
patched_boot.img
boot_xunlong.img

Which 'outsourcing'? Allwinner sells hardware. Cheap hardware for special markets. Android tablets back then, $something in between, now smart speakers, dashcams, retro gaming stuff, again tablets and TV boxes. Nintendo's NES Classic sold 2.3 million units in no time. Using a boring A33 SoC with technology from 5 years ago running a smelly 3.4.39 kernel from 5 years ago. Their customers (that's not us) do not care so why should Allwinner care so far?
 
They enable device manufacturers to throw out cheap hardware with somewhat working software with ok-ish margins (their main market) or sometimes enable their customers like Nintendo to sell insanely overpriced/overhyped products where again no-one cares about kernel, software or anything else we would be interested in.
 
For Allwinner there's still no 'Linux market'. Though things might change in the future. But unless there's an incentive to mainline their own hardware and submit code upstream (good luck given the BSP code quality) I doubt anything will change soon or at all. But of course I highly appreciate that they now contribute and react in a very responsive way. As @jernej pointed out in the meantime many requests will be answered positively (and I always chuckle seeing wink, the Allwinner guy, directly contributing to linux-sunxi wiki now -- I never thought this would happen)

This feature cost 30.000 EUR and will be implemented free of charge when it is delivered  You can find detail info on that page.

This is my very dirty script that seems to work for me: https://gist.github.com/renekliment/707ea4a2dc3f11fc15ed8085f506c57e

A20:
@Igor
- legacy kernels should go out due too overall bad kernel quality
- reboot/poweroff problems on some boards
 
H3:
@chwe
- CSI (camera) doesn't work on mainline, gc2035 needs an small script in legacy to start up properly
-
Armlogic:
@TonyMac32
- Mainline support effort is still relatively new.  Things like USB, audio, etc are WIP.
- "Legacy" kernel that is stable is old and EOL (3.14) and I haven't fooled with it.  In that world and all others Amlogic, @balbes150 is the master.
- Newer legacy kernel is still a work in progress (4.9 w/bugs)
- u-boot blobs are lame and make using mainline u-boot difficult (need both legacy 2015 and mainline u-boot to get a working image)
- Lower quality of open source information, all more or less community driven by a very small group, unlike with say Rockchip with a large amount of published info from Rockchip themselves.  Rumor/commits say this may change with newer IoT processors.
 
Freescale:
@Igor
- the legacy kernel is getting obsolete. No point to have it.
- possible to implement hw video acceleration on mainline kernel
- Solidrun has new 4.9 kernel, but can be safely ditched for mainline
 
Rockchip (I suggest only the one we support at the moment, not RK3399):
@chwe
- CSI (tinkerboard, rk3288) is supported (RK 4.4 bsp kernel) by kernel (OV6547 OV5640, imx219 - RPI-cam V1.3 resp. V2) but doesn't show up properly when booting)
@TonyMac32
- Igor and tkaiser are already seeing this, but mkimage/uboot/trust can be finicky.  luckily that's  a "figure it out and move on" situation, but it is likely to cause headaches.
- 4.4 kernel is an increasingly old kernel, now 2 LTS's in the past, however still much better than a lot of others (also has a lot of activity)
- RKwifi is something I don't know the reason for.  I don't know why it exists, I don't know what it does (other than cause problems).  It is a wrapper for some wifi drivers/an rfkill system
- Rockchip likes to use their own subsystems in many things, like the "MPP" system for media playing.  This has different capabilities per SoC, so may not behave predictably to simply be able to say we know how to use it.
 
 Marvell ARMADA:
@Igor
- missing SFP support in mainline
 
Armbian related scripts:
@chwe
- h3consumption is legacy only
-
 
 

Let's try it with an example and lock what happens/if it works...   Such a 'project manager' needs a background in the topic otherwise it's similar to marketing monkey writes product description for *random device*. I suggest we take @zador.blood.stained proposal as a test:
Is it possible to write a proposal what should be done out of it?
 
 
IMHO, it can't be a goal that you have to test all images on your own, otherwise armbian has to reduce the supported boards to much less boards. If you look into DL statistic, there are enough people downloading our images, there must be some interest from the community to report bugs (update or fresh download). Can we start with a 'testgroup lite'? IMHO most important (cause most annoying) is to avoid that the device is not bootable after update. As long as you have SSH access via ETH to the device, broken things can be fixed or at least, a backup of the data can made (I agree you should backup your system before the update - but to be honest, we have to accept that people don't do it). To avoid flooding the forum with a lot of junk from the testers group a small webservice might help:
With a clear statement that we don't suggest that you're test without having a serial console at hand (seems that a lot of user don't think it is necessary to have a usb serial device at home when playing with SBCs - maybe we should 'educate' our 'customers' also in this field....  ). 
 
Is it possible to have a 'board specific' update mechanism? E.g apt-update/upgrade only updates kernel/u-boot only if it's somehow on a 'positive list'? 
 
Internet of shitty Things is the 'new' buzzword...  Since people like @Larry Bank and @sgjava strongly push the GPIO issue, we might have a good solution in 2018.  To avoid  more load for the maintainers and keep Armbian as general as possible, I suggest to solve it similar to the OMV project. Means that we can provide a post installation script for a 'ArmbianIoT' but IMO we should avoid providing it in 'standard Armbian'.
 
A few questions:
Do we have a nightly desktop policy? Why do we provide desktop in nightly images? Does it make sense to provide such images as long as we can't provide 'basic stability'?

https://github.com/armbian/build/commit/f6402803c261b7a683eeb091f62a684bfd1ef8e8
https://github.com/armbian/build/commit/518ef98107a6705ba6649acdb1481cafedc9766d

Software support is not fast food.

Edit: User Space IO depracated. Use Java Periphery instead https://github.com/sgjava/java-periphery
 
https://github.com/sgjava/userspaceio
 
After a lot of work and testing I have produced the User Space IO project! It provides Python 3 and Java 8 bindings for Linux user space GPIO, SPI, I2C, PWM and Serial interfaces. This allows cross SBC and cross language development using a common API. I took two best of breed C APIs for Linux user space libgpiod and c-periphery and produced CFFI bindings for Python and JNA bindings for Java. Since all the bindings closely match the C API it's easy to move from language to language. The side effect of using the Java library is that it should work with many different JVM based languages. How about creating your programs in Kotlin or Scala for instance?
 
GPIO access uses the new gpiod interface and not the deprecated sysfs interface using libgpiod v1.1 (head from git repo). GPIO, SPI, I2C and serial interfaces expose all the low level functionality. I have added some helper methods for handling repetitive functions like building I2C messages, reading words from two registers, etc. You can of course go as low level as you need to. Please use Github to post any issues, pull requests, etc. I have tested Nano Pi Duo for 32 bit and NanoPi Neo +2 for 64 bit compatibility. I'll test more SBCs as I have time. Also, I have deleted https://github.com/sgjava/libgpiod-extra since User Space IO supersedes it.
 
Based of some of the questions I had in the past please note the following:
gpiod_ctxless_event_loop_multiple can handle GPIO interrupts Miscellaneous GPIO request flags GPIOD_LINE_REQUEST_FLAG_OPEN_DRAIN, GPIOD_LINE_REQUEST_FLAG_OPEN_SOURCE, GPIOD_LINE_REQUEST_FLAG_ACTIVE_LOW Non-root access using rc.local. Demo program using hardware PWM to flash LED: