martinayotte

Is that related to this post ? http://forum.armbian.com/index.php/topic/1193-orange-pi-plus-2e-now-available/#entry9732 I can't find the new mecanism, I will have to reboot with my 3.4.112 to figure it out.

Robustness still there today ! (no clues about yesterday) Small unrelated note : The MAC is set randomly each times, so I get different IP from DHCP.

Yes, it is autoloaded, but yesterday too. The difference with yesterday is that "######platform_wifi_power_on:" wasn't appearing. I will do reboot 10 times to confirm robustness ...

For the 4.6.2 dmesg, you can see that it has the SDIO transaction shown, but wlan0 doesn't appear. We can see in the 4.6.0 a line with "######platform_wifi_power_on:", but this line isn't present in the 4.6.2. I will continue investigate today, but I have some other tasks too... EDIT : About the "######platform_wifi_power_on:", it seems that it was some kind of randomness. Today, I've rebooted, and got it printed, and the "wlan0" appeared and worked. So, maybe yesterday, there was a ghost around ... ;-) Issue closed ! lite-462-dmesg.zip lite-460-dmesg.zip

For the 4.6.2 left to be fixed, me too ! Hoping it is not some regression ... Armbian 5.15 will be out soon, I will check that too, because in fact the main thing I'm aware between my 4.6.0 and 4.6.2 was that previous was generic for all H3 and newer is specific for H3-Lite. For Jef's display engine ? I don't know ... Patches take sometime months before getting merged ... I was in touch with him for other reason, I'm not using his display engine since all my boards are headless. He is a nice friendly guy, so don't hesitate to contact him, he has done an update few days ago on his page : http://moinejf.free.fr/opi2/index.html

Got it for 4.6.0, it was the missing "mmc1" in the DTS : [ 5.586907] mmc1: new high speed SDIO card at address 0001 and : [ 12.613221] ######platform_wifi_power_on: [ 13.583977] 29 81 03 CC 00 00 50 00 00 00 04 CC 0A 0C 00 00 [ 13.589991] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF [ 13.595831] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF But, unfortunately, for the 4.6.2, even if I get the same stuff above in dmesg, it still not loading the driver and make the "wlan0" appearing. I will try to figure out, but at least, it is a BIG step toward !!! Thanks, Jernej for all your help !!! (and thanks to provide me the link from JFMoine for his patch, it can help even if I got it, and I've been in touch with Jef a month ago for other issues.)

I got the idea to try it out also on my previous build of 2 week ago, the Armbian_5.12_Orangepih3_Debian_jessie_4.6.0.raw, (the current one was Armbian_5.14_Orangepilite_Debian_jessie_4.6.2.raw), but without much success there too. On both, the 8189fs is never loaded (I have to do a modprobe to get it), and doing "dmesg | grep -i sdio" doesn't show anything while doing it with a Legacy build reveal several lines, samething with "mmc1" or "wifi". On your side, which kind of board and kernel are you using ? EDIT : wait a minute, the DTS doesn't have any "mmc1", I will add it and keep you posted ...

if you comment out the eth0 entry in /etc/network/interface, it should boot quickly.

Of course I did :-) Otherwise, it wouldn't compile ... https://gist.github.com/martinayotte/56287a608a93b5ad7cddcac67d704a4c (BTW, it appears in /proc/device-tree and looks okay, but I don't see anything in dmesg)

Thanks a lot ! It is now compiled without any platform (I had to add CONFIG_LITTLE_ENDIAN in the EXTRA_CFLAGS) The modprobe succeeded, but still no wlan0 ... :-( Is there something else missing in the DTS apart from wifi_pwrseq ?

I've tried without any platform, but the Makefile is choking by saying "No such file or directory"/"recipe for target 'modules' failed". I've diff-ed Hans version and current one, I didn't figure out where is the problem. (I must admit that I'm not a Makefile expert) I've ported all other changes in Hans version into current, it compile fine but only when a platform is defined.

Yes, I've already looked at that document. So, it is maybe question of wording between real "DT overlays" (as you've said, where each drivers will get notified of DT changes) against "DT params changes". At least, if we could get a few steps in that direction, it would be already a nice to have.

@zhao_steven, you can avoid the github checkout if you wish to do incremental builds using "FORCE_CHECKOUT=no".

I've added the "wifi_pwrseq" stuff, but "wlan0" doesn't show up. I think it still related to the "platform" config in Makefile. For now, I don't have much choice to throw the towel ... :-(

I've been looking at that Makefile the whole day (those Makefile are so ugly with tons of ifdef), and unfortunately if no platform is defined, I'm end up with "not build target", so a platform seems to be required. Thank for the "wifi_pwrseq" hint, I will take a look a that tomorrow ...

Thanks for the clue ! Unfortunately, it was producing a module with 2 undefined symbols, extern_wifi_set_enable() and sdio_reinit(). Since it was originally set in the Legacy to use CONFIG_PLATFORM_ARM_SUN8I, I've look at CONFIG_PLATFORM_ARM_SUNxI instead, it is compile and load successfully, but no wlan0. So, I think now it is because the DTS isn't set at all for SDIO, I will have to go back studying that and fixing it ! Not a trivial task finally ...

Ok, for the THS, adding back the 1008000 entry is a kind of ugly workaround : during boot FREQ switch is crashing, but at least it continue to boot completely. I presume that real fix would not be adding it, but change the value at the origin of that 1008000, which is probably in u-boot, but this is outside of my knowledge. @Tkaiser, the patches you mentioned, and even Megi's change doesn't seem to be part of the Armbian build process. Maybe patches are not applied for some reason. @jernej, I started doing what you've said, I got some part done, but now I'm a bit lost about platform files searching for the legacy sys_config.h

@TKaiser, I will try again with tweaked DTS, if it doesn't work, maybe it is Megi's change here : https://github.com/megous/u-boot/commit/85dddd9bbbd2e57aad1718579e552bd936716866 I will also give a try with Hans drivers. (I though first to grab Legacy folders and move then into Mainline, but I presume that would be lost of time)

@tkaiser, I don't see any RTL8189 sources in Mainline, googling didn't provide any clues either. For THS stuff, after reading those threads/issue, I'm still not sure how it should be fixed. Is it simply of adding the 1008000 entry in the DTS ?

But why Wens was telling me that C.H.I.P is already using it with Mainline ? Also Beaglebone is using overlays since awhile, my current kernel on it is beaglebone 4.4.9+. Samething about RaspeberryPi which is using overlays since awhile, my current kernel on it is raspberrypi 4.4.11+. From my early studies in both RaspberryPi and BeagleBone, Nope, the DT overlays isn't loaded by the bootloader, only the plain DTB is loaded at that time. Then, when kernel is started completely, there is a service that simply copy overlays defines in a conf file to be copied into something like /sys/bus/platform/devices/bone_capemgr in case of BeagleBone (I don't remember my recent foundings). Same kind apply to RaspberryPi although I don't remember details. The EndUser can also load new overlays/"capes" from command line at the time he wish just before running a software that actually use those "capes"/i2c/spi peripherals. My next goal is to compile some OrangePi kernel is this flag CONFIG_OF_OVERLAY and see if I can start to upload "dynamic overlays" from UserSpace. If this succeed, then, lot of maintenance tasks, but it will be the way to go, like other boards such RaspberryPi, BeagleBone or C.H.I.P (like Wens emphasised as an example)

I've received my OPi-Lite today ! I didn't get chance to follow every threads, is the RTL8189FTV soon be supported ? Also, I think a bug has been introduced recently : I've build tonight the image Armbian_5.14_Orangepilite_Debian_jessie_4.6.2.raw and it was hanging during boot : [ 7.575548] systemd[1]: Started udev Coldplug all Devices. [ 7.638570] systemd[1]: Mounting FUSE Control File System... [ 7.647639] systemd[1]: Mounted Configuration File System. [ 7.653293] systemd[1]: Starting Apply Kernel Variables... [ 7.670604] systemd[1]: Starting Create Static Device Nodes in /dev... [ 7.690248] systemd[1]: Starting Syslog Socket. [ 7.703836] systemd[1]: Listening on Syslog Socket. [ 7.713512] systemd[1]: Starting Journal Service... [ 7.722884] systemd[1]: Started Journal Service. [ 7.851371] systemd-udevd[227]: starting version 215 [ 8.339502] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 1008000 KHz I've then use the previous image I've built 2 weeks ago, at a time the image still common for all H3, the Armbian_5.12_Orangepih3_Debian_jessie_4.6.0.raw, and it booted properly.

I think there should be some trade-offs somehow. That maybe why Wens suggested me to look at the "dynamic overlays" path, where basic pins will be present in mainline DT, but not activated a special peripherals until some overlays would be loaded.

Hi @tkaiser, Unfortunately, this task isn't finished ... First, all my patches have been submitted to linux-sunxi mainline almost 3 months ago and nothing is merged yet. Several reasons lead to that : patches format, email issues, email headers corrupted, this last one is been solved/workarounded recently : Maxime Ripard told me that my tests using "git send-email" worked but earlier tests with "msmtp" didn't. I should now resend my patches soon as "v5"... Then, still the goal of the patches : kernel gurus which to avoid to beef up DTS, want to keep them as little as possible, claiming it take time to parse it (ridiculous statement here since we are not using 8bits MCU), and peripherals such I2C/SPI should not be enabled on all boards by default, stealing GPIOs (well, there so much GPIOs, is that really important to save them ?). @Wens suggested me strongly to go with overlays like C.H.I.P guys did. So, this is a new task for me : getting familiar with Dynamic Overlays loaded from UserSpace ! I will have to study that , recompile new kernel of the OF flag, tests, overlay prototypes, etc. I hope to met expectation, especially that "time is the missing ingredient" ! Ciao !

Maybe I've been missing something, but to extract the patches from git only requires to do a "git format-patch" with a revisions range.

I don't know if it is related to legacy (I would have to reinstall it to check), but on Mainline, there is no such w1-sunxi driver, only w1-gpio/w1-therm are required. Maybe you can try to comment out the w1-sunxi in /etc/modules-load.d/modules.conf and try again.