Werner

For those who couldn't made it, meeting logs: https://freenode.irclog.whitequark.org/armbian/2020-04-04 Meeting summary goes directly into Jira issues/bugs and the actual work. 
 
Thank you all for attending the meeting!

I've done a fresh "git clone" to get rid of the issue.
I'm now doing a new a new "tour of my Allwinner garden" with 5.6.1, and then I will do some commits ...

Our next release date is coming and perhaps its time to discuss what to push into 20.05, what not, resolve open questions and distract from most used keyword for past few weeks.
 
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @count-doku @chwe @ning @lanefu @gprovost @aprayoga @5kft
@JMCC @Werner @karabek @martinayotte @tkaiser @selfbg @Siraj ... to name just a few which might find this move useful  
 
I am preparing a meeting on IRC in Saturday at 1 pm GMT - this is reasonable good timing for US / EU folks. The idea behind this meeting is that (ideally) everyone, who will be present, quickly present (in alphabetical nick order) what they are working (not working on anything is equally legit) on followed by a discussion. If a feature, project or a fix can be pushed into this release. Plus answer and decide on other open questions. You are welcome to expand this with a PR/change document directly. This way we could - on a long run - improve all project parameters.

As my example -  what I am currently working and IMHO could be implemented by 20.05:
 
- setting up auto test facility, software and hardware which is a great support tool for making releases. It is already helping me finding bugs.
- merging mainstream kernel config in the non-hardware areas could go into this release
- firmware split up with @ning
 
... more Jira's during a week.
 
Ideally it would be that prior to this meeting you write into Jira what you are working and join discussion about your task/project/idea with a link - who does not have access shall PM to @lanefu or @Igor - reviewing and prioritising goes faster and better with Jira.
 
Welcome!

`SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612]` is tested to work.

As we know, the PCIe on H6 is buggy, which doesn't offer linear address, and Linux cannot support such kind of configuration.
 
However, the Cortex-A53 cores used by H6 supports virtualization, which can be used to change the order of the address space.
 
Recently, I tried to make use of virtualization to provide linear mapping of PCIe, and I succeed in making an Intel 6205 wireless card working.
 
The hypervisor code is at https://github.com/Icenowy/aw-el2-barebone . It's intended to start before U-Boot, and located at 0x40010000.
 
A U-Boot fork that is patched to load the hypervisor is at https://github.com/Icenowy/u-boot/tree/h6-load-hyp , and a kernel that utilizes the wrapped PCIe (and patched to reserve memory for the hypervisor) is at https://github.com/Icenowy/linux/tree/h6-pcie-wrapped .
 
In order to let the hypervisor start before U-Boot, BL31 needs to be built with `PRELOADED_BL33_BASE=0x40010000` in make parameter -- this will change the EL2 entrypoint to the hypervisor. Mainline ATF from ARM works.
 
Contributions to the hypervisor is welcomed.
 
(In addition, abusing virtualization in such way will prevent us from using KVM. But I think more people will want PCIe instead of KVM, right?)

Keep us updated

I just received this little guy:
 
https://www.ebay.de/itm/USB-Li-Po-18650-5V-1A-Lithium-Battery-Protection-Boost-Step-up-Charger-Board/153077054028?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2648
 
Connect one or multiple 18650 cells to it and it will act as UPS. Working very well.
 

I installed it and let everything as it is. Two things I don't like:
1a. To start flashing or writing, the button says in german: Ausschreiben (terrible translation),  just 'Schreiben'  would be much better
1b. When it finished it says. Done. Picture (Bild) written successfully instead of 'Abbild'.  I wonder if a human did the translation.
2. It doesn't remember the window size. It is good it starts small, but I have 24" and I like to see the path-to-the-folder I am about to write.
 
It lists the right devices: I attached an USB-Stick and an SDcard and only these two I was able to choose
And finally, it wrote the Kubuntu 20.04  2,3Gb within 1 min and this inlcudes the writing-verification to my understanding   2300/60 = 38MB/s  
Aside from being fast, Zero-Load on the CPU
 
In opposite to Etcher, it is not ejected at the end of the process. Well, if USBImager ensures proper termination of the process it shouldn't harm if the user unplugs it before ejecting it.
 

Actually, I managed to get it to work, thanks to this thread and the author (It only applies to the H5 SoC from what I know..)
https://forum.armbian.com/topic/9043-rtl8723bs-bluetooth/
 
And yes, I understand that Armbian is still being developed and not in anyway be perfect yet.
But still, I really appreciate everyone's work to make this incredible OS for SBCs.
 
Once again, thank you for helping me out You really saved my life

It is listed now: https://www.friendlyarm.com/index.php?route=product/product&product_id=282

You have wiped out your input voltage circuit. To be brutally sincere you've probably destroyed the board.
 
That being said, take a look at the schematics -
http://wiki.espressobin.net/tiki-index.php?page=Schematics
select your model ...
 
scroll down to page 14 and look at U9 - the regulator ... if all you did was wipe that out, you could replace it. You will need hot air soldering equipment and skills.
 
HOWEVER, it's my experience that when over voltage is applied to a regulator, many times it fails by passing the power rather than blocking it. There is a good chance that 19 volts was applied to many 1.8 and 3.3 v circuits. In that case your board is toast.
 
Mark it up to expensive education ... we've all done it. Most of us have plugged 12v into 5v boards that have no regulation. In that case the board is also toast.

We usually get stuff before mass production which under current condition might be problematic. I have to talk to FA to get my prediction confirmed.

I have 25 boards in the automated testing facility ATM  and this is how the report (with bugs) looks like:
 

#me too ... soon after the power connector died    https://forum.armbian.com/topic/6909-pi-factor-power-solution/?tab=comments#comment-52516
But some day I will amend the power-HAT from @TonyMac32  cut out the middle part in KiCAD and see if I can get it manufactured in China. So this great board, with the gorgeous heat sink gets back to live :-D
 

+ updates to: rockpis, rockchip64 and odroidxu4 legacy kernel

Aight, got it.
The value is name CONFIG_QFMT_V2 and CONFIG_QFMT_V1 which are not set.
 
I'll try to see if it throws errors at build and if not I push a new config which will include both modules.
 
And no. I am an amateur just like most users here
 
 
Edit: Pushed

Who mentioned overkill? 

I usually use those, and usually oriented properly:

Then your sd card is either corrupted or not written correctly or not properly detected by your board. When an SD card is inserted it should boot from it.
I assume the OPi3 with EMMC comes with an Chinese Android written to it...
 
 

There's an issue with Panfrost and Mesa 19.3 that causes X11 to crash in "OsLookupColor" which you may run into on Armbian on RK3399 devices; it can be solved by enabling the experimental branch in your /etc/apt/sources.list by adding the following line:
 
deb http://deb.debian.org/debian experimental main contrib non-free  
You can then run 'apt update' and install experimental branch packages with 'apt -t experimental install <package>'. To fix the crash in X11, update the following from experimental:
libegl-mesa0 libgbm1 libgl1-mesa-dri libglapi-mesa libglx-mesa0 mesa-va-drivers mesa-vdpau-drivers mesa-vulkan-drivers This should allow X11 to run properly.
 
Thanks to zackw at the Pine64 forums (Original post: https://forum.pine64.org/showthread.php?tid=8915&pid=61701#pid61701 )

Hey folks,
 
we really would like to see more of you to hang out in our chat.
 
All contributors to the project, regardless if forums staff, contributor on Github or well known and longtime active user here in the forums, are free to register a nickname through Nickserv services provided by Freenode and drop me a small message to get voice permission in our channel.
If you have questions about that you get more details on nickname registration here https://freenode.net/kb/answer/registration or just put them down below.
 
Looking forward to see you over there

We mainly know what is wrong. What we don't have are expensive resources to fix things. At least not with the speed "you" desire.
 

https://github.com/armbian/autotests
https://www.lavasoftware.org/about.html
https://kernelci.org/
 
If you want to do something truly useful for the project, ask what is here to do, not to assume you know what is best thing to do. Perhaps rework this application? You will contribute and learn a lot.

I dont know what exactly happens and what this causes. As stated XR819 is known to be unstable or even considerable broken by design (like PCIe on H6 but at least it works somehow). I own the board by myself but the first thing I did was removing the wireless antenna as I did not need it
Anyway. Sure you can script yourself some kind a watchdog that checks by pinging a host outside every second or so and when a disconnect happens do something like ifdown/ifup if that helps or do forcefully rmmod and modprobe the wireless module to recover it  (if that works at all, no idea). You have to try around by yourself. Maybe you can come up with something nice.