-
Posts
3892 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by martinayotte
-
-
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 ?
-
DT overlays is a great feature, but it's not present in mainline (and probably won't be available this year).
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.
-
Absolutely ! (if both SDCards are the same size or if the new one is bigger than the old one.)
Otherwise, you should use the method described in the other thread.
-
The general idea is to first get the bootloader written in the first sectors. So, TKaiser suggestion to "dd" the first 1MB is accomplishing this task.
The second step is to have the partition sized properly with the SDCard size, so either fdisk or gparted can do that, deleting the partition and re-create new one that fit on the card.
Third step is to format this partition, either mkfs.ext4 or gparted can be used.
Fourth step is actually copying the whole rootfs from the orinal SD to the new one, to do that, both needs to be mounted, then a "tar piped in a tar" or "rsync" will copy the whole thing.
Last step is to make sure to securely umount sdcards. Then, enjoy your backup ... :-)
-
Maybe I could help here, if it is not tasks above my capacities.
I could help on the DTS for example if something is missing.
-
In my case, I'm using the https://github.com/duxingkei33/orangepi_PC_gpio_pyH3 derived from pyA20 from Olimex, but I didn't verified all the Pin GPIOs mapping.
-
Orange Pi Lite - now available
in Allwinner sunxi
Posted
Got it for 4.6.0, it was the missing "mmc1" in the DTS :
and :
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.)