Igor

RaspberryPi needs FAT partition and some people even thinks that this is a special feature, which prevents boot failures and similar crap Having boot FAT here is the "as compatible to Rpi as possible" crap even it does not create gain. TBH, there is some gain, for Windows folks, to edit boot environment ... but this, I believe, exists and works properly only on Armbian ... which has EXT4 by default Exactly. For Allwinner boards, check this: http://linux-sunxi.org/Boot_Process Then it can be SD card slot problem. Friendly ARM usually uses stock u-boot, which do not check if SD card is present, our (mainline) checks that. Serial console is a must to proceed.

You need to tell Network manager that you will use this adaptor. Did you try the armbian-config way?

Usually, the best diagnostics would be a serial console to those three pins ... the second one is enabled at USB OTG port, but it's available after the system is up. Why there should be a FAT partition? This is Linux and we use only one ext4. Did you use Etcher for writing to SD card? Is card reliable? Perhaps this problem:

I don't think this is hardware related. Hmm ... is it working if you connect your Orange via cable? Try removing /etc/network/interfaces and reboot. Also, try modern NEXT kernel.

I have one spare XU4 and can send you if it helps? Send me shipping address on PM and note if you need a PSU too. Shell we better switch to 4.14.y (DEV branch at this time) with this? In any case, we should make a switch NEXT from 4.9 to 4.14. .. after deep testing this time

apt install armbian-firmware-full should solve this problem.

you need to adjust root= parameter to match your new media. use some other computer and determine with blkid, change and boot.

It is virtually the same board as Neo (you can start with their images) and gpio handling is pretty generic. http://linux-sunxi.org/Fex_Guide http://linux-sunxi.org/GPIO https://forum.armbian.com/search/?&q=gpio Just read and try.

I am not sure what you are trying to achieve, but I2C LCD display certainly works on Opi Zero. You need to enable I2C bus with overlay and use appropriate drivers for your LCD. In my case, I use display library from @Larry Bank https://github.com/bitbank2/oled_96 I would propose to start with our normal build. RT is considered experimental feature and we don't deal with it very much and also not support. The (modern) kernel for H3 is fragile already without and we still label it "testing", not yet "stable". I have no idea how you could build a kernel 4.13.9-rt1-sunxi in first place. We are at 4.14.y for some time. Use our latest official kernel/build and enable only those you need. Below on the picture, you can see real-world example - some mini project on my desk with Opi Zero and OLED display, which is working perfectly fine with http://ix.io/WTy

Without armbianmonitor -u and detail description of your hardware which can't be detected, you are wasting time.

Development branch https://github.com/armbian/build/tree/development/packages/bsp/common/etc/network is moving completely towards Network manager, 1st boot setup with it was successfully tested. Worked with wireless and ethernet, with normal and predicted interfaces. It can be further expanded to the hidden network connection ..., but problems are expected on Jessie due to an old version of NM. The main problem with this topics issue is that wifi drivers for Tinker's onboard wifi are not in the best shape and if you want to use wpasuppliant to connect, you need to tell network manager to unmanage that particular wifi interface. @bulletim3 Checking this part of the script might give you some clues.

This is the best what I can give you: https://github.com/search?q=8723 ... check which looks best supported, most updated. Remember to blacklist the one inside the kernel when you get to the testing part.

There could be some possibly better drivers out there at github.com (need to search) and someone needs to test them ... once they are tested, we can move them inside the kernel tree and replace this one. If you ask us to do all the work, you will wait months.

Nand (EMMC) has no role in this problem. Just insert and remove SD card 20-40 times ... this usually helps. Stock OS does not check (this sensor) if SD card is present, others do. Wrote on mobile

Most likely yours SD card slot is slightly broken. Read posted link again. It cointains hints how to solve this problem. Worse case you need to replace SD card slot. Wrote on mobile

If you can't boot our images from SD card but you can stock, then this might be the problem: https://forum.armbian.com/topic/3945-mmc-no-card-present-error-on-allwinner-boards/ But if you can and, here above is a screen of the boot, then some other problem might be present. Can you check serial console output?

This is not possible to work but hardware video acceleration is apparently possible to achieve on a modern kernel, but it is some work: http://forum.solid-run.com/viewtopic.php?f=8&t=1573&start=530#p22805 http://forum.solid-run.com/viewtopic.php?f=10&t=1156&start=550#p22839

It is exactly the same on all boards. If 1st hit does not give you answer, proceed to second ...

Can you also provide logs with armbianmonitor -u ?

1. Armbian version is tied to our build script and to get idea and information when a certain package was built. Sources are mostly elsewhere. 2. Kernel version depends ... it is tied to armbian version - when it was built. The same goes with kernel configs: https://github.com/armbian/build/tree/master/config/kernel You can see this in the release documentation and here https://github.com/armbian/build/releases (not very updated) We don't do this for development versions. They are as is. 3. ALSA is tied to userspace, Ubuntu or Debian. If you go with Jessie, it's Jessie latest, Ubuntu latest, ... we don't touch ALSA 4. Also Upstream. We always use latest upstream distribution packages with those exceptions - we use patched or more recent versions: https://github.com/armbian/build/tree/master/packages/extras-buildpkgs I hope this helps you somehow. I know it's not the best way but this way is manageable.

Well, whole kernel tree was changed so its hard to provide a complete changelog. In any case, we didn't plan to write any scientific documents about this, only a brief what works now and what still needs fixes. In general. The kernel has too many functions to be checked by 1-2 (amateur) person. Audio/alsa/RT functionality of the kernel is not our core business and we don't know much about. You are on your own here. If you have troubles with building kernel, check manual once again and if you can't proceed, append a question in https://forum.armbian.com/forum/20-development/

You are using one of the first test build made by Helios team. Fan driver, which bothers you, was changed and you might be missing some scripts which are not part of the update process. Perhaps @gprovost could provide you details hints how to solve this but it looks something went wrong also with a kernel image update or you made some manual changes to the system? ii linux-dtb-mvebu 5.41 armhf Linux DTB, version 4.4.115-mvebu ii linux-image-mvebu 5.37 armhf Linux kernel, version 4.4.107-mvebu If you can, I would suggest starting with the latest official armbian.

Try disabling ramlog to see if that helps.

There are more images out there and some early builds might have troubles with upgrading. First type: armbianmonitor -u that we know little more about what you are talking about.

Just beware the differences between Ubuntu and Debian userspace. They are different enough to make troubles in install scripts.