raschid

Yeah. XR819-Wifi stopped working with stretch and buster, but still works with bionic.
 
Here's my syslog with a buster build:
ov 30 16:45:56 localhost NetworkManager[1116]: <info> [1575132356.6690] wifi-nl80211: (wlan0): using nl80211 for WiFi device control Nov 30 16:45:58 localhost NetworkManager[1116]: <info> [1575132358.1449] device (wlan0): driver supports Access Point (AP) mode Nov 30 16:45:58 localhost NetworkManager[1116]: <info> [1575132358.1555] manager: (wlan0): new 802.11 WiFi device (/org/freedesktop/NetworkManager/Devices/4) Nov 30 16:45:58 localhost NetworkManager[1116]: <info> [1575132358.1656] device (wlan0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external') Nov 30 16:45:58 localhost kernel: [ 34.419112] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Nov 30 16:45:58 localhost kernel: [ 34.423469] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Nov 30 16:45:58 localhost NetworkManager[1116]: <info> [1575132358.1790] device (wlan0): set-hw-addr: set MAC address to AA:88:8F:8F:8F:AF (scanning) Nov 30 16:45:58 localhost NetworkManager[1116]: <info> [1575132358.2924] device (wlan0): supplicant interface state: init -> starting Nov 30 16:45:58 localhost wpa_supplicant[1115]: Could not set interface wlan0 flags (UP): Invalid argument Nov 30 16:45:58 localhost wpa_supplicant[1115]: nl80211: Could not set interface 'wlan0' UP Nov 30 16:45:58 localhost wpa_supplicant[1115]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0 Nov 30 16:45:58 localhost wpa_supplicant[1115]: Could not set interface wlan0 flags (UP): Invalid argument Nov 30 16:45:58 localhost wpa_supplicant[1115]: WEXT: Could not set interface 'wlan0' UP Nov 30 16:45:58 localhost wpa_supplicant[1115]: wlan0: Failed to initialize driver interface Nov 30 16:45:58 localhost NetworkManager[1116]: <error> [1575132358.3304] sup-iface[0x1175c18,wlan0]: error adding interface: wpa_supplicant couldn't grab this interface. Nov 30 16:45:58 localhost NetworkManager[1116]: <info> [1575132358.3309] device (wlan0): supplicant interface state: starting -> down Nov 30 17:21:39 localhost NetworkManager[1116]: <warn> [1575134499.3085] device (wlan0): re-acquiring supplicant interface (#1).  

Thanks actually I am not trying the get sound to work right now - I would like to understand why I does not function as it is supposed to, though ...

and dont forget to raise the volume with
alsamixer

 
and save the setting with
alsactl store

"current" on an OPi zero also seems to be missing analog audio at this time - so this is not specific to this board.
 

@guidol, thank you for the kind hint - I updated the link.
I added a cpu voltage regulator node to the device tree - oddly enough to build a viable kernel there seems to have to be one ... although this box reportedly does not have anything remotely resembling a PMIC (still working on that ...).
Regarding the overlays: the IR overlay seems to be missing while the audio overlay appears to have been compiled for another kernel version ('bad magic'). No idea how armbian generates overlays, sorry. But IR is "OKed" in the DTS and should work anyway.

Mine (red PCB, v1.2) is running 5.3 - but with a modified device tree if I remember correctly. I'll check ..

You are right ... and out of luck for now:
https://github.com/armbian/build/issues/1003#issuecomment-394987272
 
you could try a recent nightly build:
https://dl.armbian.com/orangepizero/
 
One BananaPi running a recent kernel (Armbian 5.45 / kernel 4.17.0 rc7) has been up and running for 12 days now ...

Have a look at this:
https://forum.armbian.com/topic/6386-lime2-mainline-kernel-with-debian-9-stretch-becomes-unresponsive-forced-reboot-required/?page=2&tab=comments#comment-55225
 

I have spent a lot of time on this and latest package should fix that, hopefully:
 
https://patchwork.kernel.org/patch/10128825/
 

after all, you know that you do not have to. so I asked through curiosity

Yes. Changes to packaging method upstream. It is getting fixed. Check my last commits to developmebt branch for quick fix.

Wrote on mobile

I completely agree. I think, if a desire to be more minimalist exists, that we create those images specifically labelled as such, for devices that fit the case (OPi IoT, nanopi NEO, Duo, etc).  Otherwise I don't see the value.
 
My honest reaction to the discussion is that it fits perfectly with the "What is Armbian?" discussion.  I don't think playing games to save a few megabytes fits something we really care about, it isn't really our problem if an extreme subset of users wants to pull the 512 MB SD card out of their 10 year old Sandisk Sansa MP3 player and want to put Linux on it...
 
There are 2 main deliverables that I see:  A build system for people to make their flavor of Debian for their needs, and our pre-packaged images.  IMHO, if we want to make it more "lean", this can be an option available in the build system deliverable, and if we want to make questionably valuable tiny images, then we can do that in parallel with the current desktop and server images.

Did you build your kernel with the armbian build system? Like this:
# git clone --depth 1 https://github.com/armbian/build # cd build # ./compile.sh BOARD=sunvell-r69 Use the <NEXT> kernel. There have been changes recently to DRAM timing which have increased stability.
To transfer the OS from SD-Card to eMMC use $sudo armbian-config. There is an option in the "Systems"-menu to transfer the OS to the internal eMMC.

Well it took me longer than i hoped but i have managed to forward port icenowys code for TVE on the H2+/H3 to mainline armbian.  It seems to work totally fine, with a few caveats.
First: Sample images of it in action -> https://imgur.com/a/vXQEM
Second: the patch itself -> https://github.com/stevenj/h3-tve/tree/v0.0.11
Third a prebuilt image for Orange Pi Zero: -> https://github.com/stevenj/h3-tve/releases/tag/v0.0.11
 
Howto:
just put the patch into userpatches for the sunxi-next kernel, and build.  it should apply cleanly. Its for H2+/H3.  I have only tried it on a orange pi zero, but it should work on all H2+/H3 boards.
 
You then need to edit /boot/armbianEnv.txt
add tve to overlays to enable it.  the driver will only run and enable tv out when the tv out devices are specifically enabled, so i created an overlay which does this.  If you want to turn TV out off, just remove tve from the overlays line.
My armbianEnv.txt overlays looks like this:
overlays=usbhost2 usbhost3 tve If you want copious amounts of DRM debug info in your logs, add this as well:
extraargs=drm.debug=0xF Its not needed, unless you really want the debug info.
 
Notes:
1. The default mode is PAL, with 720x576 resolution.  Thats outside of normal PAL displayable area, and so the screen overscans.
I dont know how to correct this, although its mostly just annoying with terminals.
I also don't know how to change the video mode to NTSC.
 
2. The standard font is a bit thin for composite video, and causes slight strobing and color impurity.  Its because PAL needs pixels to be a certain MINIMUM width or color information can not be properly encoded.
A way to resolve this is use :
# apt-get install fbterm ... $ fbterm -s 20 This will run a terminal which is easy to change the font, and pick a bigger one.  its much easier to read.  Look at the help for fbterm to work out everything it can do.
 
3. I used the program "fim" to display the test images.  there are others for doing stuff on the terminal.
 
4. I haven't tried X.  I am not interested in running an X terminal on a TV, but it should probably work fine.
 
Other than that it all seems good.  I originally tested my hardware with the legacy kernel, and the image quality from this patch seems superior to what the legacy kernel produces. (legacy was noisy)
 
The only other thing you need to know is Orange Pi Zero is missing filter circuity from its Composite Output, the most important thing you need to do is put a 50 ohm resistor between the signal and GND.  i soldered one inside my RCA connector, it fits fine and isn't too difficult.  IF you don't do this the image will bloom and look like total crap, so you have been warned.
 
As this patch allows TVE to be enabled/disabled through use of the Device Tree overlays, i think it should be fine if the Armbian devs want to include it.  I am happy to clean out some of the debug messages i added if they are interested in making a standard part of the build.  If not, its easy enough to build your own image, just follow the guides on how to rebuild armbian.
 
EDIT: I need to mention, all props go to Icenowy Zheng who wrote the original driver.  I just tweaked the device tree stuff and got it in a state where it can apply cleanly to the armbian mainline kernel and build system.
Original code is here:
https://github.com/Icenowy/linux/tree/tve-v2

Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 17:17:45: 1008MHz 0.11 7% 4% 3% 0% 0% 0% 36.2°C 0/7 same build (4.14.20-sunxi). Ambient temp: 21 degs.
 

Good news but still odd: the legacy image's FEX file indicates a DRAM clock of 576MHz. Never mind, I created a pull request with an updated u-boot patch which should solve the issue for other users as well.
Thx for raising the issue and the extensive testing
 

Good news but still odd: the legacy image's FEX file indicates a DRAM clock of 576MHz. Never mind, I created a pull request with an updated u-boot patch which should solve the issue for other users as well.
Thx for raising the issue and the extensive testing
 

I did build the image with this patch as Armbian_5.40_Sunvell-r69_Debian_stretch_next_4.14.17_RAM_408Mhz.img
and now all the others cards (8GB Ultra and 32GB Exteme) DO boot again in the first try
ARMBIAN 5.40 user-built Debian GNU/Linux 9 (stretch) 4.14.17-sunxi Linux sunvell-r69 4.14.17-sunxi #6 SMP Wed Feb 7 11:31:13 +03 2018 armv7l GNU/Linux I didnt want to copy the OS to eMMC, because for future purposes I want to leave the original Android there.
As I have the case closed I dont want to open these clips again - because Iam afraid they could break in a additional try

@guidol: Does the boot-stability improve, when you replace build/patch/u-boot/u-boot-sunxi/add-sunvell-r69.patch with the attached file (reduces DRAM clck to 408)?
If stability improves, could you copy the OS to eMMC via armbian-config and check boot-stability?
add-sunvell-r69.patch

Mainline kernel vers. 4.14.17 also works quite well (supporting eth, wifi, both usb-ports, emmc, ir, audio, ...). You could build it yourself with the armbian build system (https://docs.armbian.com/Developer-Guide_Build-Preparation/)
# git clone --depth 1 https://github.com/armbian/build # cd build # ./compile.sh BOARD=sunvell-r69 for media stuff you better stay with the legacy kernel though ...

Mainline kernel vers. 4.14.17 also works quite well (supporting eth, wifi, both usb-ports, emmc, ir, audio, ...). You could build it yourself with the armbian build system (https://docs.armbian.com/Developer-Guide_Build-Preparation/)
# git clone --depth 1 https://github.com/armbian/build # cd build # ./compile.sh BOARD=sunvell-r69 for media stuff you better stay with the legacy kernel though ...

Hmmm, I've never thought that e/n/i is particularly complicated. Like most of GNU/Linux it's a powerful tool, possible to get wrong but it's also a solid part of the Linux learning experience. Isn't that also what Armbian is at least partially about? Even Netplan, which is slated to replace ifupdown in 18.04, is largely based on e/n/i (state your desired outcome) principles rather than NM (coddle you from any chance of mishap) principles.
 
And the fact that boards like the Orange Pi Zeroes, etc, open up the world of Linux to more people is something to be celebrated, surely?
 
However, if this is the way things ust be then there's a couple of issues/suggestions:
 
1. The "standard" Ubuntu/Debian way of disabling Network Manager appears to be broken (at least in H3 5.35 Dev):
$ sudo systemctl stop NetworkManager.service $ sudo systemctl disable NetworkManager.service Following these (man page) commands good ol' Network Manager is somehow re-enabled on the next boot. I had to take slightly more drastic step of:
mv /lib/systemd/system/NetworkManager.service /lib/systemd/system/NetworkManager.service.BAK after the previous steps to actually slay the vampire. I don't know whether this is due to Armbian's integration of NM into its basic tools or what.
 
 
2. The description in /e/n/i needs to be more balanced
 
It sounds like it was written by someone fuming at the ears. It should, of course, emphasise the benefits of NM but should also point out that for any vaguely interesting routing set up (say you want to play with LXD and create neat bridges, VLANs or whatever) then it should contain clear and working instructions on how to disable NM (since the standard Debian way doesn't seem to work). Maybe even better would be to add into armbianconfig. I'll investigate if I have time!  

### meminfo: MemTotal: 1024100 kB MemFree: 901772 kB This looks odd. AFAIK the OPi Zero only comes with 256M or 512M.
 
 

Feedback and requests appreciated, obviously I don't have infinite resources and time, but ideas are always good.
 
Also, there is a test image specifically for the Duo, so far so good.  https://www.armbian.com/nanopi-duo/

Good catch !
Those lines were there when we were on 4.11.x ...
That means nobody seen that those were missing in NEXT 4.13 !