vlad59

Upgraded and it's working fine, I'll get back to you if there are problem

Incredible !
As I said in many other threads, USB-TTL-Serial USB dongle  as described at http://linux-sunxi.org/UART is a MUST for anyone who plays with any SoC boards !!!
Those are afordable, usually around $0.99 on eBay, you should keep several of the in inventory if you have several SoC boards ...
 

I also noticed that a year ago when I switched to mainline on my Banana, IIRC I talked to tkaiser about it and it was a normal side effect. I did not try to change anything about as my banana pi stay mostly idle and only use their CPU when doing compression and that does not happen very often.
 
The max freq is defined in the device tree so you can change it on userland

So I was beat but I can also confirm that a new install is working fine.
 
I'm updating another banana pi that was previously running 5.36 and report back.
 
About the kworker, the problem was diagnosed on linux-sunxi mailing list : https://groups.google.com/forum/#!searchin/linux-sunxi/kworker|sort:date/linux-sunxi/bVEsjQRNVSo/nTa3rpOyAQAJ
 
If you really want to remove this load you can unload the two modules but I don't know if you'll still have thermal protection on your A20. I'm tempted to try it as it does not run too hot.

Still on a banana pi, updating a Stretch 5.35 installation on SATA worked perfectly.

I also have the problem. I tried some quick debugging and watched some kernel logs about network / a20 but found nothing so far.

UK Server deployed. Details PM'd

You're absolutely right. The few hundred people a day downloading these broken and totally untested images (check statistics yourself: https://dl.armbian.com/_download-stats/) are all fooled since these images can't work (broken, untested, 'armbian style'). And only you are brave enough to publicly inform those lazy Armbians about this severe problem. Last image has been released back in June so those lazy Armbians already fooled thousands of poor users with providing broken and untested images. It's almost a miracle that you're the first to tell the truth! Keep on rocking!

This will proove I'm older than you .... but I still use my HP48sx from when I was in the University (as a side note I still works perfectly fine after more than 20 years) .....
 
I'll post a photo of my workbench soon

The problem with these "certifications" is that then people expect everything to work perfectly. This simply isn't possible where someone can install any software with apt-get or compile it themselves. You'll say "Certified for Armbian" and then someone will say "but it doesn't work when I try to compile Firefox from source" which is obvious to anyone that there isn't enough memory, but you said "Certified for Armbian" so they assumed it could do anything.
 
It's too difficult to say "Certified for X" and then expect the user to A. have reasonable expectations, and B. read the list of limitations (e.g. minor software/hardware issues).
 
 
I don't see any problem for people to add support for boards via git. The best solution to avoid dealing with angry users is to not provide stable/nightly builds. If you force someone to compile Armbian from source to support a board, it raises the level of effort and technical knowledge required massively. People who know enough to compile Armbian for a board from git are the kind of people you want to come here.
 
 
I disagree with having any private areas for board support. The reason is simple, it will keep out talented people who don't otherwise know about the hidden areas.
 
I understand you want to avoid having users pile on with "+1" support for cheap shit, but there are easy ways to handle that.
 
I think any discussion among developers about supporting a new board should be publicly visible, if not necessarily open for public comment. IMHO transparency is very important in open source. To have a closed section for making these decisions could potentially remove developers who want to support but are not part of any "inner circle"
 
I would propose that the section is open for all users, but people who abuse it by starting threads full of "+1" are blocked from posting further. If this proves to be too difficult to maintain, then posting is restricted to developers.
 
But my biggest concern is friction. It's hard enough to get developers, but if you make it harder for them to contribute, they simply won't come. Therefore we should be trying to make it as easy as possible for the next developers, who may not be known to us yet, to come and start developing for Armbian too.
 
 
I still stand by my previous statements: Developer(s) commit to supporting a board. If the developer is no longer able to support the board, then someone else takes over. If the board is already "mature" and well supported, then perhaps no one is needed, but this would need to be considered for each board depending on the status.
 
I go back to what I said earlier, I think Armbian should not build stable/nightly builds for "community supported" boards. Make it like the Android ROM scene: you provide the source for popular/well supported devices (e.g. Lineage OS "Official" devices), and other people are free to build their own image from source and post it here if they want (e.g. "Unofficial" builds). But make it more like XDA: there is a dev db listing the source/version/credits, and a big disclaimer that Armbian does not support these, WARRANTY VOID, etc.
 
I think this would actually make more people contribute. Outside of the core devices, someone actually has to build the image themselves, post it here, and maybe provide support. If it gains enough traction, then Armbian could consider officially supporting it.
 
I guess my point, and I don't make it very well, is this: make it easier for developers to contribute. Make it harder for users to download an image with half support. If someone cares enough to build an image from the source and post it here, then that shows some commitment from them.
 
You don't necessarily have to stop supporting every board a vendor sends you. If you just love getting Armbian to boot on the latest hot garbage, then go for it. Why should we stop you? But leave these changes in git. Don't provide users with images they can easily flash.

Yes. Main problems / considerations here are:
We have multiple platforms/SoCs, and most overlays will need modifications / adjustments for each platform Compared to RPi we don't have support for overlay parameters, so instead we use u-boot scripts which have some limitations Compared to RPi SoCs, Allwinner A20, for example, has 4 SPI controllers, 5 I2C controllers and 8 UART controllers, and for I2C/SPI devices we have to support attaching devices to each of potentially available bus/controller So instead of blindly trying to port all existing RPi overlays it will be easier to add them by user requests.

Hey all,
I've been using Allwinner boards for the last couple of years and Armbian+forums have made this a workable thing that I promote to my friends as being The Way To Go instead of being a big fat waste of time. 
Igor + Tkaiser (and anyone else forgive me if I didn't give you a shout) - You fucking rock.  You really do; you've all provided amazing amounts of support for multiple kernels and userspaces and in the face of (at least) bullshit from the chip vendors, yet you are absolutely crucial to them being taken seriously.
The work from Armbian has (for me) made the difference between BananaPi, OrangePi, etc all being an unusable washout of #ShitDidn'tWork, to being something I am excited to build into things and personally promote.
 
Igor, Tkaiser; I've never met you but your work speaks for itself; you give a shit and you keep giving and shit and THANK YOU FOR THAT.
I just donated you some $. If you're still reading this and you're using their work, you might think about doing same.   FWIW; what turned my head is seeing Igor and crew putting _years_ of work into this. 
 
Anyway, much, much, much appreciated. From one to another; good job.
DrTune

Not by switch which means I have to dig into the code - so far I haven't found a proper way. There was only a plugin which removed button Quote all from that footer.
 
It annoys me to 

Instead, we were rewarded. Not many got this privilege.
 
 
 
https://distrowatch.com/weekly.php?issue=20170116#donation

@zador,
maybe a multimedia subsection should be made with a big red warning saying "GPU doesn't decode video" with the link to http://www.cnx-software.com/2013/12/10/most-embedded-gpus-do-not-support-hardware-video-decoding-acceleration-the-vpu-does/
 
This is most detailed description I could find in datasheet:
 
 
Obviously, 10 bit HEVC is not mentioned anywhere. Of course they might just forget to state it, but until I see working 10 bit decoding, I will claim that HW acceleration of 10 bit HEVC is not possible. I'm not sure if CPU is fast enough to do it in SW.
 
@hojnikb,
maybe because they wanted to join 64 bit ARM hype? Easy, take H3 and change 32 bit core with 64 bit, update Mali cores and you are done. As you may noticed, sales are fuelled with marketing bullshit instead of common sense.

Designed a case for it. Available on thingiverse if anyone interested - http://www.thingiverse.com/thing:1918590
 

Armbian PCB

https://www.sendspace.com/filegroup/wOi2h%2FyA2aQMRnrr%2BfGNYA
 
for the png and ans files.
 
and to view it:
 
http://imgur.com/aA4LVrP
 

 
 
by me.
 
=)
 
tell me what you guys think.
 
 
 

is that pin already used for something else ?

So, now I can tell you how to enable LCD in u-boot and DT.
 
First getting the source of armbian from https://github.com/igorpecovnik/lib
Open the file sources/u-boot/v2016.09/configs/Bananapi_defconfig and add:
CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:24,pclk_khz:30000,le:40,ri:40,up:29,lo:13,hs:48,vs:3,sync:3,vmode:0" CONFIG_VIDEO_LCD_POWER="PH12" CONFIG_VIDEO_LCD_BL_EN="PH8" CONFIG_VIDEO_LCD_BL_PWM="PB2" Now LCD is enabled in u-boot. But it will not switch on backlight, because backlight uses pwm and pwm is disabled per default in DT. So you also have to add:
&pwm { pinctrl-names = "default"; pinctrl-0 = <&pwm0_pins_a>, <&pwm1_pins_a>; status = "okay"; }; Ready!
But be aware, LCD only turns on if there is no HDMI Monitor plugged in!!
 
Ok, hopping some one else of you can use this stuff.

Okay Guys,
 
I've got a little success. My display is on now. I think the worst thing I could do, was to let HDMI plugged in and HDMI monitor switched on. Only by luck, I saw, that my display is working when HDMI monitor is switched of.
Now, I will search for the correct solution and post it here soon.
 
Yours Martin

@trewq please share anything that might help others who plan on getting their own neo (mine is on the way ;-))

I should be receiving 2 nanopi Neo in 3 weeks hopefully. I'll make all the tests needed as soon as received.
 
<off topic>I can confirm that my Nanopi M1 work fine even at 744MHz so no need to lower the DRAM settings for them</off topic>

This was actually easy, I only need the dts directory and the kernel headers (they were already installed) and that's it. The compile script look like that :
#!/bin/sh IDE=sun7i-a20-bananapro SRC=$IDE.dts TMP=$IDE.tmp.dts DST=$IDE.dtb cpp -nostdinc -I /usr/src/linux-headers-4.5.2-sunxi/include -undef -x assembler-with-cpp $SRC > $TMP dtc -O dtb -b 0 -o $DST $TMP #rm $TMP I'll check tonight if the DTB I compiled is exactly the same as the one from Armbian.
 
EDIT : An additional interest of having all the DTS files is that you can quickly find the DTB file you're currently using :
root@bananapipro:~/test/dts# grep "`cat /proc/device-tree/model`" *.dts sun7i-a20-bananapro.dts:        model = "LeMaker Banana Pro";

Here is the graph for more than an hour of cpuburnA7 with my Nanopi M1 without heatsink.
 
So my conclusion :
 * No crash also so the setting from Banana Pi M2+ seems good. I'll make a lima_memtest run but I think it'll be fine.
 * The heatsink does help (the CPU stayed mostly at 648MHz with 3 cores with the heatsink and was much erratic without)
 * The Nanopi M1 performance under load is way lower than Orange Pi (see tkaiser post)
 
I think I'll use my NanoPI with Openelec to replace my Raspberry Pi 2. I'll make a test this weekend and ask my daughters to watch Frozen / Any Ghibli movie one or two times on it . That's not what I have planned but that'll do.
 
@tkaiser
Can I make a PR on github to update the nanopim1.fex or do you want to fix differently ?
Should I add the nanopi M1 page on linux-sunxi's Wiki ?
 
That should close the Nanopi case for now unless anybody need another test (once the nanopi are in the hands of my daughters, tests will be way harder to plan)