lanefu

I'm not sure what will and won't be a worthy overlay to put directly into Armbian itself with the current script structure, I intend to document the ones I add here, @martinayotte may as well if he's bored.  :-P
 
I will be focusing on RPi GPIO compatibles, since those are nice pre-packaged devices in general.  I have Tinker, RockPi 4, Le Potato/K2/C2, Tritium H2+/3/5, Rock64, Renegade, and some others.
 
Everything here is a placeholder at the moment.
 
Status   Tinker Le Potato Meson64 Renegade Tritium Automation Hat           Generic DAC (Pi)           MCC 118 DAQ           MicroDot PHAT           Inky WHAT (e-ink)           ENC28J60 for Pi                                                

I agree, which is why this is not under normal development as a topic.  There is the reality, however, that people buying RPi-shaped boards want support for RPi peripherals and accessories, so my thought is to discuss ways to support that, while implementing a few on a platform that only has 1 board with gpio anyway (Rockchip).  If it must be that I have a fork of the build system and stuff all of this in "user patches" then so be it, but I think we need to come up with a way to handle this per board rather than per family.

Hi Steve,
 
This is my first post here, I recently stared using Armbian, and it is really good.  I had the same problem with my new Renegade board,  this is the solution:
 
-  Go to https://dl.armbian.com/renegade/archive/ 
 - Get this file: Armbian_5.75_Renegade_Ubuntu_bionic_default_4.4.174_desktop.7z , 174 is the last version that works for Renegade
-  Before upgrading, sudo apt-mark hold linux-image-arm64
 
The version 4.4.180/5.88 has this issue for Renegades, I am investigating.
 

added (tested) preview images for H6 boards based on our sunxi64-dev kernel (5.1.7) hdmi works, network works, dvfs works, ... not all board features works apt upgrades will not be tested bugs are expected. Help in finding and resolving is more then welcomed!  
https://www.armbian.com/download/?tx_soc=h6

Ooopps!
 
Just kidding then!

This weekend I was revising and testing the OV5640 for some A64 boards.
To enable the Camera (OV5640) on NanoPi A64 for the mainline kernel you have to update the following:
* DT
* GPIO-I2C 
Here is the excerpt :
 
Kernel config:
 
CONFIG_I2C_GPIO=m
CONFIG_VIDEO_OV5640=m
CONFIG_VIDEO_SUN6I_CSI=m
 

An RPi is not

1) reliable
2) the most cost-effective
3) worth $35
4) worth any more discussion.

The position of this project stands, we will not support a failure prone, insecure, underperforming, inefficient, abysmally bandwidth throttled device. If an RPi 4 comes out that uses a sane bootloader and a useful SoC then this can be revisited.

Do not continue your personal argument with Tido; it is not value-added, and your positions add nothing other than conflict. Mostly because you have no facts or reason for your position, and instead of trying to formulate something approaching a case for support resort to ad hominem attacks and downright inaccuracies. This is an unofficial warning to stop harassing the team because you aren't getting your way. The next will be official.

Sent from my Pixel using Tapatalk

I see some decent moderator skills here... @Igor @lanefu we should change his official title here..
 
btw. if this thread goes back and forth.. I'll simply close it until the first iteration of a not VC4 based RPi is out (or someone wrote a bootloader which allows to boot without binaries provided by the foundation ).

@FlashBurn @spqr
 
Please find the updated bootloader here (u-boot is unchanged; WTMI is updated to 18.12.1) - it should solve the stability issues and  it works fine on my V5_0_1 EspressoBin (https://pastebin.com/xJCtLXsH). The recovery images are also updated: sata-images and uart-images.
 
Could you please test if your EspressoBin ist stable now and if you can apply the pending cpufreq and xtal kernel patch without creating any further issues ?
 
Edit: links updated ; images are now available through Armbian servers

Hi Igor
 
How about including "webseeds"/"http seeds" in your .torrent files? You already have a lot of mirrors (ex http://mirrors.dotsrc.org/armbian-dl/), so it would be very helpful if your torrent client could also download from all those mirrors.
 
Spec: http://www.bittorrent.org/beps/bep_0019.html

Mini tutorial
I am putting here some notes for posterity
In the current version of armbian (testing H6) I use X11 / Xorg only reaches 1024x768, but my display reaches 1440x900.
To add this new resolution to the list of Settings/Display you have to give these commands:
 
# xrandr --listmonitors
(this command serves to see what it's called, the hdmi output)
 
# cvt 1440 900
(output: 
# 1440x900 59.89 Hz (CVT 1.30MA) hsync: 55.93 kHz; pclk: 106.50 MHz
Modeline "1440x900_60.00"  106.50  1440 1528 1672 1904  900 903 909 934 -hsync +vsync )
 
# xrandr --newmode "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync
 
# xrandr --addmode HDMI-1 1440x900_60.00
 
# xrandr --output HDMI-1 --mode 1440x900_60.00
 
If it works then modify Xorg with:
 
# sudo mcedit /etc/X11/xorg.conf.d/40-monitor.conf
 
Section "Monitor"
Identifier "HDMI-1"
Modeline "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync
Option "PreferredMode" "1440x900"
EndSection
 
# reboot
 
 
 
 

Never connect a VCC contact for USB-TTL. Use only three GND Tx Rx Pins on all models.

Changed posting permission - one need 10 5 posts to post in RK3399 or Allwinner H6 forums.  

BTW, seems like the Lima driver has been accepted for 5.2. Looking forward to seeing it released 

Armbianmonitor: http://ix.io/1IrG Hi,
 
I'm running Armbian Stretch on a Tinker Board and trying to use a one-wire thermometer.  I have this in /boot/armbianEnv.txt:
 
overlays=i2c1 i2c4 spi2 spidev2 uart1 uart2 w1-gpio However, when I boot the board, I see this in dmesg:

 
[Wed May 8 17:38:43 2019] rockchip-pinctrl pinctrl: unable to find group for node w1_pins [Wed May 8 17:38:43 2019] w1-gpio: probe of onewire@0 failed with error -22 Kernel version is Linux tinkerboard 4.19.33-rockchip #5.77 SMP PREEMPT Wed Apr 3 17:06:29 CEST 2019 armv7l GNU/Linux
Any ideas?  I'm using the rockchip-w1-gpio.dtbo that was installed with the system.

Regards,

Dianne.
 

"newest and fastest" quite often ends here:
https://forum.armbian.com/forum/31-sd-card-and-psu-issues/
 
that's why I don't care about such information without actually prove that the used card is really fast (forum search will guide you how you can test it)... Especially when it's about Images we (as armbian team) are not 'in charge'.
 
about which Image do we talk here? switched to Armbian or still on FriendlyElec's image?
 
a short reminder (https://forum.armbian.com/guidelines):
A support question must include the following: Board you use Issue you face Description of your set-up (e.g. powering, connected hardware, used SD-Card) 'sudo armbianmonitor -u' - this gives us some needed logs which makes debugging a way easier!  
besides being in 'Development' not 'Technical Support':
Development A section for more experienced users. For example for SoCs where Armbian support is currently not mature enough for full support, questions related to the build framework and 'Board Bring Up' for new boards we might consider supporting in the future. We can't provide the same level of support for WIP (work in process) SoCs cause kernels for those boards are simply not ready yet. Board Bring Up is mostly for experienced users which want to contribute in support for new boards/SoCs, a *please support random board* without any rational and no interest in contribution for such a support will simply be ignored. If you just want to point us to a new interesting board our water-cooler (General chit chat) is the right place for it.  
btw. @lanefu can you adjust the text there? 'Technical support' isn't anymore.. so the text need some small adjustments..
 
 

Dear moderator, could this topic be moved to the H5 subforum?  It's misfiled under the H2 & H3 subforum.  Thanks in advance.
@lanefu, @Igor
Sorry, I don't know who the other mods are.

I tried to build Mesa with enabled lima and kmsro drivers, seems like this work mostly fine: https://launchpad.net/~russianneuromancer/+archive/ubuntu/drivers (for Ubuntu 19.04 only, due to Mesa 19.0 dependencies).
 
However, attempts to interact with lima via X11 always result in "libEGL warning: DRI2: failed to authenticate".
https://paste.fedoraproject.org/paste/vmKQVPcEURxlcvqkqLDiTw
https://paste.fedoraproject.org/paste/2VbdPxubtS9a-9E~hzZbIA
...and attempts to run glmark2-es2-wayland under Weston reveal that it running on llvmpipe.
 
Testing on NanoPC-M1 with current dev kernel:
~$ dmesg | grep lima [ 9.943493] lima 1c40000.gpu: bus rate = 200000000 [ 9.943506] lima 1c40000.gpu: mod rate = 384000000 [ 9.950490] lima 1c40000.gpu: gp - mali400 version major 1 minor 1 [ 9.950539] lima 1c40000.gpu: pp0 - mali400 version major 1 minor 1 [ 9.950581] lima 1c40000.gpu: pp1 - mali400 version major 1 minor 1 [ 9.950629] lima 1c40000.gpu: l2 cache 64K, 4-way, 64byte cache line, 64bit external bus [ 9.960591] [drm] Initialized lima 1.0.0 20170325 for 1c40000.gpu on minor 1 (full log)
 
I wonder if anyone was able to install Lima from Mesa upstream with current Armbian dev kernel and replicate at least this results?

with the armiban-build-system I did build some dev-images.
Sometimes I see in other threads, that later build images have newer kernel or package versions.
 
While trying apt update && apt upgrade I didnt get these newer packages
 
So my first try was to use the armbian-build-system and do use the function for creating u-boot and kernel
that will give me some .debs in ./build/output/debs/ like this:
linux-u-boot-dev-nanopineo2_5.82_arm64.deb linux-dtb-dev-sunxi64_5.82_arm64.deb linux-image-dev-sunxi64_5.82_arm64.deb linux-headers-dev-sunxi64_5.82_arm64.deb linux-source-dev-sunxi64_5.82_all.deb install these (mostly I didnt do that for the headers and source) with dpkg -i will result in higher package numbers,
but not for the armbian / bsp-kernel version
 
for getting here the right version I have to compile (again) - now - the a whole OS-image to get 
linux-stretch-root-dev-nanopineo2_5.82_arm64.deb in ./build/output/debs/stretch
 
If you did install also this .deb with dpkg -i I do get the right/higer armbian/bsp-kernel-version:
 
Welcome to ARMBIAN 5.82 user-built Debian GNU/Linux 9 (stretch) 5.0.7-sunxi64
package bsp-kernel[5.82] u-boot[5.82] dtb[5.82] firmware[5.79] config[5.81]
 
armbian-config does update via apt update && apt upgrade
 
I try to update this way because I didnt want to use a whole new OS-image and reconfigure it.
 
But I think it isnt the right way to update, when I have to compile 2 times on to get the root-deb
 
Is there another way to generate this file?
And is there a way to not generate the headers and source .debs?
The source .deb take a while because it is getting as big as 370MB
 
Is there a better way or does nobody other like me update this way?
 

Yeah. The bycicle is still the most efficient vehicle mankind ever evented. But it uses our own our own energy for it. But a lot more efficient than running. Not for lazy people.
It's very dangerous since not much good bikeroads in the world.
Ain't nothing perfect. You've just got to make out what you can pack in your bag of guilt Some don't care and ride big pick ups with a chimney for exhaust.
Some want to feel better and buy and electric vehicle. But then plug them into mains. When producing your own energy then it's a lot better.
Energy is everywhere, but we just need to learn how to get it at the places where it's needed. Enough place in the sahara for solar plants, but no people there who ned it. A lot of energy in oceans. Again not where people live(yet).

All the pieces ar available to make great improvements. But whose going to put them together? I don't think Elon Musk. He's just a salesman.

For now I'll keep cycling. Next trip, NicoD's Leaving Europe. (UK)

I've finished all of them. All 4k except the transport one. That would take too long since there are many light sources and bounces.(+10hours) And even then the quality would be less since I've got to lower some things.
And the N2 isn't super stable either.
They are all converted to jpg because the original png's are together 560MB.

My favorite is the under construction one But you can't use that for supported

@lanefu If you need anything more, let me know. I hope people are going to like them, I've already seem them too much. 

Now I can start putting my render farm together to make new animations for my channel.
Cheers.
Armbian Backgrounds JPG.7z

Thanks!  Time = around 6pm CET.
 
We had two hardware failures before the actual planned upgrade  We are using a proverb for describing such mess "when the devil have children ... " 

I've finished the EOL background.


I'm rendering everything in 4K with my N2. I've finished a few.
Here's one with rounded shape.

I'll upload them all together when ready. Cheers.
 

certainly just execute:
root@orangepioneplus:~# systemctl disable NetworkManager root@orangepioneplus:~#ip a |grep ether link/ether 00:2d:fd:1e:f1:e1 brd ff:ff:ff:ff:ff:ff # take note of MAC address root@orangepioneplus:~#vi /etc/network/interfaces ## add or update in to /etc/network/interfaces.d/ auto eth0 iface eth0 inet static address 192.168.10.200 netmask 255.255.255.0 gateway 192.168.10.1 dns-nameservers 192.168.10.2 192.168.10.1 hwaddress ether 00:2d:fd:1e:f1:e1 root@orangepioneplus:~# reboot # wait 5 secs and reconnect to IP address set root@orangepioneplus:~# cat /etc/network/interfaces # tada!  
you guys don't even realise how perfect this weekend started,
once again cheers for all your efforts, it is appreciated a lot!

Hi all.
Here my review video of the new Pine H64 model B.
I also compare it with the Orange Pi 3, and it's older brother the Rock64.

I hope you'll like it.

Thank you.
Greetings, NicoD