guidol

There is a major forum upgrade + 2 bug fix upgrade waiting. I hope some of those troubles will be gone after that. I already started with theme adjustments and testing, but due to family duties I am grounded for few days  Switch to updated version perhaps in upcoming weekend.

Yes, most of the devices are controlled by the DTB file, in fact, I compiled the 'staging' wifi driver and played around with enabling WIFi in the  new DTB.  I actually added the wrong DTB to that tar.gz after all was said and done, like you noticed, sorry about that.  I was kinda rushed when I put that up.  I did compile a few more kernels and was talking to some devs about trying to get some help with getting devices enabled correctly in the DTB.
 
I actually have a DTB that works for enabling vga framebuffer, ethernet and wifi however ends up breaking USB (assuming your powering through pins, you can actually connect a USB device) and the staging driver in 4.12.y is trash and the kernel panics when you inset the WiFi driver.
 
Glad to hear you found a working dtb for your needs, supposedly there were a few in the packages as you noticed with different things enabled.
 
As I get time I will probably compile a few more kernels and work on the DTB and will post back here if I come up with something better. Though glad to hear what I provided gave you a good start!
 
Cheers!

@guidol Good news and medium good news.
Here is u-boot, kernel and dtb needed to enable eth0 and have it work:
https://licheepizero.us/licheepizero.linux-4.12.with.vga.and.eth0.tar.gz
 
http://prntscr.com/nhuq6f
http://prntscr.com/nhupqd
http://prntscr.com/nhupv3
 
The uboot has vga and eth0 enabled, however, the current versions of the WiFi module that are around do not work with this kernel and while VGA is in the uboot, it isn't active in the kernel in this.
 
If your goal is to boot up and have eth0 up and access, this should work for you.
 
I am going to test building 4.14.y and 4.13.y branch to see if the WiFi driver is incorporated at any point, the github repos are not very specific about whats been updated and my attempts to build the driver seperately have so far failed for the 4.12.y repo I used to generate this.
 
This should at least be enough to get you started.  Once i test a bit more I will upload my .config and provide a link as well.
 
Cheers!

Hey Guys,
 
I spent time over the past two days updating https://licheepizero.us and if you visit the site and use the navigation at the top right I have added some simple how-tos for certain things as well as have included better links to the resources you need.  This includes the dock.dtb file your looking for, if you look through the wifi setup page, I believe it is linked at the bottom: https://licheepizero.us/setup-wifi-for-licheepi-zero
 
As some of the Chinese resources have been slowly going down, I am trying to replicate the how-tos into English and add pages so that they will not be lost.
 
If you guys come up with anything that would be good to keep on there that I am missing, please PM me here or send me info using the Feedback form on the page.
 
Also if you get stuck on something, I will try to keep checking back here and offer suggestions as I can.
 
@guidol if you get stuck and your familiar with IRC you can come on Freenode irc network and join #H3Droid and I will be happy to try and help you some with getting things working, as I know just how frustrating the thing can be.
 
Have a great weekend!
 
Cheers!

with the armiban-build-system I did build some dev-images.
Sometimes I see in other threads, that later build images have newer kernel or package versions.
 
While trying apt update && apt upgrade I didnt get these newer packages
 
So my first try was to use the armbian-build-system and do use the function for creating u-boot and kernel
that will give me some .debs in ./build/output/debs/ like this:
linux-u-boot-dev-nanopineo2_5.82_arm64.deb linux-dtb-dev-sunxi64_5.82_arm64.deb linux-image-dev-sunxi64_5.82_arm64.deb linux-headers-dev-sunxi64_5.82_arm64.deb linux-source-dev-sunxi64_5.82_all.deb install these (mostly I didnt do that for the headers and source) with dpkg -i will result in higher package numbers,
but not for the armbian / bsp-kernel version
 
for getting here the right version I have to compile (again) - now - the a whole OS-image to get 
linux-stretch-root-dev-nanopineo2_5.82_arm64.deb in ./build/output/debs/stretch
 
If you did install also this .deb with dpkg -i I do get the right/higer armbian/bsp-kernel-version:
 
Welcome to ARMBIAN 5.82 user-built Debian GNU/Linux 9 (stretch) 5.0.7-sunxi64
package bsp-kernel[5.82] u-boot[5.82] dtb[5.82] firmware[5.79] config[5.81]
 
armbian-config does update via apt update && apt upgrade
 
I try to update this way because I didnt want to use a whole new OS-image and reconfigure it.
 
But I think it isnt the right way to update, when I have to compile 2 times on to get the root-deb
 
Is there another way to generate this file?
And is there a way to not generate the headers and source .debs?
The source .deb take a while because it is getting as big as 370MB
 
Is there a better way or does nobody other like me update this way?
 

thank you, now it`s clear for me

https://github.com/armbian/build/commit/21478fed593057961737e83e2e12f78c60cd9974

Ja, sag einfach Bescheid ob es geklappt hat in der Bretagne

Here's some photos of my M4 with SATA hat and 4 SSD's in a drive case - all working beautifully

- to build engine (EXPERT="yes")
- repository update with the purpose for adding it (armbian-config and armbian-firmware update everywhere)

Finally I got the reason.
It seemed that it is a bug in armbian mainline kernel.
The LOSC_OUT_GATING_EN register does not be enabled to output the 32.768kHz clock to the wlan module.
This clock is used as a low power clock in BCM SoCs. If the clock is missing, the module will down after it enter low power mode and never wake up.
I don't know why AP6212 can work fine without this 32k clock.
 
And finally I build a very simple patch to solve this problem:
diff -ur a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c --- a/drivers/rtc/rtc-sun6i.c 2019-04-14 16:19:50.749519000 +0800 +++ b/drivers/rtc/rtc-sun6i.c 2019-04-15 22:29:13.670404000 +0800 @@ -215,6 +215,9 @@ /* Switch to the external, more precise, oscillator */ writel(SUN6I_LOSC_CTRL_KEY | SUN6I_LOSC_CTRL_EXT_OSC, rtc->base + SUN6I_LOSC_CTRL); + + writel(SUN6I_LOSC_OUT_GATING_EN, + rtc->base + SUN6I_LOSC_OUT_GATING); /* Yes, I know, this is ugly. */ sun6i_rtc = rtc;  

This time was at least controlled offline  and according to my info, there were no troubles. There will be some further actions - adding redundant this and that - to prevent (unplanned) downtime in the future. 

Awesome news. And everyone can still be an old school guy using interfaces file 

Ok, I think I got it!  Had to learn a little bit about device trees in the process.  BUT...here's what I did (and BTW -- I did this all directly on the PC2):
 
Step 1: Grab a copy of the Linux source:
$ sudo apt install linux-source-4.19.20-next-sunxi64 This will dump the Linux source tarballs (and a config file) into /usr/src.
 
Step 2: Unzip the tarball, and copy in the config file:
$ cd /usr/src $ sudo mkdir linux $ sudo chown `whoami`:`whoami` linux $ cd linux $ tar xvf ../linux-source-4.19.20-sunxi64.tar.xz $ xzcat ../linux-sunxi64-next_4.19.20_5.75_config.xz >.config Step 3: Download the attached patch and apply it:
$ patch -p1 <OrangePiPC2.patch Step 4: Build the new DTB:
$ make dtbs You should find your new DTB under arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dtb.
 
Step 5: Copy the new DTB into your DTBs folder:
$ sudo cp arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dtb /boot/dtb/allwinner Step 6: Reboot!
$ sudo reboot The PC2 will now throttle automatically when temps start getting too high!
OrangePiPC2.patch

Because the kernel is running from the same RAM is used, but not counted. And also some RAM has been reserved for graphics. Using a buildroot similar to Squonk42's setup I've got ~56M of RAM available and ~40M free with just logging, a dhcp client and dropbear running.

at this time there is only a pre-support with OS-images:
https://dl.armbian.com/orangepi3/
 
but support is getting beter from day to day

@guidol here is for reference the minimal buildroot guide for the Lichee Pi Zero for comparison
https://github.com/Squonk42/buildroot-licheepi-zero-old/wiki/Build-system-–-Installation
 
https://github.com/Squonk42/buildroot-licheepi-zero
 
https://github.com/Squonk42/buildroot-licheepi-zero-old/wiki/Fresh-image-–-Booting
 
https://hackaday.io/project/134065-funkey-zero/log/144796-linux-distribution
 
 
 
 
 
 
 
 
 
 
 

Hah I did found something....after @kamma did tell it would be OK with the PineA64-deconfig....

It seems that the deactivated usb@1c19000 allwinner,sun8i-a33-musb has to be activated as status = "okay";
and in dr_mode = "host"; like on the pine64
 
I changed the sun50i-a64-nanopi-a64.dts and compiled it back to .dtb and did put it in /boot/dtb/allwinner and reboot.
 
see config here in hidden spoiler:
 
Now the NanoPi A64 does recognize the USB-Stick at the upper port.
 
[    1.856580] sun4i-usb-phy 1c19400.phy: failed to get clock usb0_phy
[    2.129298] usb_phy_generic usb_phy_generic.0.auto: usb_phy_generic.0.auto supply vcc not found, using dummy regulator
[    2.129351] usb_phy_generic usb_phy_generic.0.auto: Linked as a consumer to regulator.0
[    2.129630] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[    2.129639] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 5
[    2.129813] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.00
[    2.129821] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.129826] usb usb5: Product: MUSB HDRC host driver
[    2.129832] usb usb5: Manufacturer: Linux 5.0.7-sunxi64 musb-hcd
[    2.129837] usb usb5: SerialNumber: musb-hdrc.1.auto
[   82.404779] usb 3-1: new high-speed USB device number 2 using ehci-platform
[   82.562191] usb 3-1: New USB device found, idVendor=0930, idProduct=6545, bcdDevice= 1.10
[   82.562202] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   82.562206] usb 3-1: Product: TransMemory-Mx
[   82.562211] usb 3-1: Manufacturer: TOSHIBA
[   82.562215] usb 3-1: SerialNumber: C03FD55EAF4CEFC050138484
[   82.563032] usb-storage 3-1:1.0: USB Mass Storage device detected
[   82.570592] scsi host0: usb-storage 3-1:1.0
[   89.518200] usb 3-1: USB disconnect, device number 2
[   92.721680] usb 1-1: new high-speed USB device number 3 using ehci-platform
[   92.879376] usb 1-1: New USB device found, idVendor=0930, idProduct=6545, bcdDevice= 1.10
[   92.879387] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   92.879391] usb 1-1: Product: TransMemory-Mx
[   92.879395] usb 1-1: Manufacturer: TOSHIBA
[   92.879400] usb 1-1: SerialNumber: C03FD55EAF4CEFC050138484
[   92.880125] usb-storage 1-1:1.0: USB Mass Storage device detected
[   92.883967] scsi host0: usb-storage 1-1:1.0
[ 1054.498911] usb 1-1: USB disconnect, device number 3

@kamma @martinayotte @Igor Thanks - was a nice teamwork

@kamma @martinayotte @Igor Thanks - was a nice teamwork

i can confirm, that @guidol's patch is working !!!

Presuming this is not a brand-new install, correct?
 
How are you able to edit /etc/shadow?
 
If you are already logged in as root you can just use 'passwd' to change the passwd.  When running as root you do not need to provide the existing password to change a password.
 
If you can login as a user with 'sudo' access, you can use 'sudo -i' to gain a root shell then follow the step above.
 
If you have mounted your SD card on another linux instance, you should be able to use:
passwd -R <path_to_mount_point> root <path_to_mount_point> is where you have your SD card mounted (not the full path to the passwd/shadow files)
 
 

What would be this second patch for the U-Boot "reset" ?
 
EDIT : for the "reboot" patch, I'm confirming : it works ! Thanks a lot to both @froezus and @megi !!!
EDIT2 : tested on all my H6, OPiOne+/OPiLite2/OPi3 ... And patch committed in Armbian !

@froezus Nice! Thank you. I've changed your patch, so that it uses R_WDOG only on H6.
 
https://megous.com/dl/tmp/0001-Fix-reset-issue-on-H6-by-using-R_WDOG.patch
 
It's still a hack, but at least it doesn't touch other SoCs.
 
U-boot will also need patching, because it doesn't use ATF for reset.
 
I tested it on Opi3, and it works. :))

Thanks, I'm on ARMBIAN 5.75 stable Debian GNU/Linux 9 (stretch) 4.19.20-sunxi64.
I'll try to move to the dev image.