Igor

I'll add 8814AU USB (USB3 or external powering might be needed) based wifi dongle with AP support here. Its performance is ofc worse than mPCI based Compex, but still, it performs reasonably well. You can't attach external antennas to this particular model (except if you DIY), but it cost only 23USD shipped. http://s.click.aliexpress.com/e/EyrJ6ai (I got mine even for a few USD less than this). I haven't made a proper multiuser test, so I actually don't know how it performs with lots of clients. With a few, for SOHO usage, it works good enough.

It is possible to build one, minimal Debian or Ubuntu to be used for such purpose (use parameter EXPERT="yes" when building) and it should work. There are no premade images because we don't officially support this hardware.

I am sure you can find it somewhere else, perhaps on Ebay ... but unfortunately, it doesn't work on Espressobin. This is boot log with an attached card: http://ix.io/1l0m I don't have time for testing now, but on more recent BSP kernel looks better: root@espressobin:~# lspci 00:00.0 PCI bridge: ASMedia Technology Inc. Device 1182 01:03.0 PCI bridge: ASMedia Technology Inc. Device 1182 01:07.0 PCI bridge: ASMedia Technology Inc. Device 1182 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07) 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07)

Which kernel version were you using here and there?

On Clearfog this RTL8111 mPCI card works without problems. Out of the box.

Espressobin PCI stack is IMO still somewhere in WIP stage. A year back there were just a few cards recognized, a few operational ... regardless of the kernel driver. Perhaps try here: https://github.com/MarvellEmbeddedProcessors/atf-marvell/issues

Yes, they learned but people need more time Sadly it looks like it is their most popular/sold board

Peeking into manual? https://docs.armbian.com/Developer-Guide_User-Configurations/

You can't. You have to wait until is fixed, donate that we will be able to hire help or fix on your own ... which will be much faster. You can also switch to DEV kernel branch, which should be the same as it was before your upgrade. And remember, nightly kernels comes without support. If they break, nobody will fix them on the spot.

Probably it works with the same image? I don't have Berry around ... https://dl.armbian.com/bananapim2ultra/

It works the latest DEV build out of the box: http://ix.io/1kVR

If you use armbian, this is all done standard way, via packages. We have a post-install script which does the actual update. If you want to understand details about the boot process, peek here .

To build what exactly? What kind of errors do you see?

If you build an image with build tools now, DVFS is partially broken on two cores since sources were switched to Ayufan's repo and they need further adjustments (WIP). Perhaps this is the problem?

Yes, its recommended.

Where did you download this image? Have you read those few lines? Have you checked board FAQ?

Ah. Locate h3disp utility and remove opizero here: https://github.com/armbian/build/blob/master/packages/bsp/h3disp#L75

Try changing 0 to 1 https://github.com/armbian/build/blob/master/config/fex/orangepizero.fex#L329 bin2fex /boot/script.bin /boot/script.fex # convert nano /boot/script.fex # edit fex2bin /boot/script.fex /boot/script.bin #convert back Make sure to make a copy since settings are overwritten at system upgrades.

This command is for manipulating HDMI output. Where did you see one on Orange Zero?

This means somebody made an Armbian image by using our tools. That's all I know.

On 4.14.y DVFS generally works, but not sure if it works in all cases (board from the topic for example).

Something is broken in the regard of DVFS on the modern kernel 4.17.y/4.18.y which we are trying to put together. Currently exploring what the issue is ... in the meantime I also consider reverting NEXT branch back to 4.14.y and leave it there for a while.

Yesterday I adjusted patches that we can build 4.18.y but it crashed exactly on this board on H3 DVFS is missing, Banana/CT Wireless is broken, ... from those impressions I expect quite some work to something stable level. This makes me think: - put 4.14.y back to NEXT, change u-boot to 2018.05 and leave as is even it's not the best option, but people could build it when they needed. 4.18.y is IMO still too far away. - switch 4.18.y to DEV and slowly work on it.

It should be 378. It's some time since 60GB was set Everything is fine. Many new boards and Bionic as a test option on some ... with some cleaning and with some additional logic, this could be brought down. But its some work.

A stable repository will be upgraded when all supported boards are checked for basic functionality. Switching to beta, update and freeze upgrading perhaps? Is it stable? I have no idea.