martinayotte

I've been working on the rtl8189fs patches for Mainline.
 
Althouth the source code change between Legacy and Mainline is pretty trivial, preparing good and nice patches becomes a tedious task :
 
- First, the original patch in Legacy contains tons of DOS file formatted (strange for a Linux driver, shame on Realtek) and even dos2unix failed on some files because of binaries character (probably Chinese), I had to edit many files because I wouldn't "signed-off" such ugly thing. (btw, maybe that dos2unix job should be done one Legacy to make it cleaner)
 
- It is a quick big patch, but about the same size as the one in Legacy, about 10MB of text file.
 
- Even after applying the patch, we still need to have some other patches, one for DefConfig in Igor's lib/config and one for DTS which I will work on tomorrow ...
 
- Then, lots of testing need to be done, especially that I need to figured out that everything is working in the fresh build environment, then a PR will be sent to Igor.

I've been working on the rtl8189fs patches for Mainline.
 
Althouth the source code change between Legacy and Mainline is pretty trivial, preparing good and nice patches becomes a tedious task :
 
- First, the original patch in Legacy contains tons of DOS file formatted (strange for a Linux driver, shame on Realtek) and even dos2unix failed on some files because of binaries character (probably Chinese), I had to edit many files because I wouldn't "signed-off" such ugly thing. (btw, maybe that dos2unix job should be done one Legacy to make it cleaner)
 
- It is a quick big patch, but about the same size as the one in Legacy, about 10MB of text file.
 
- Even after applying the patch, we still need to have some other patches, one for DefConfig in Igor's lib/config and one for DTS which I will work on tomorrow ...
 
- Then, lots of testing need to be done, especially that I need to figured out that everything is working in the fresh build environment, then a PR will be sent to Igor.

I've been working on the rtl8189fs patches for Mainline.
 
Althouth the source code change between Legacy and Mainline is pretty trivial, preparing good and nice patches becomes a tedious task :
 
- First, the original patch in Legacy contains tons of DOS file formatted (strange for a Linux driver, shame on Realtek) and even dos2unix failed on some files because of binaries character (probably Chinese), I had to edit many files because I wouldn't "signed-off" such ugly thing. (btw, maybe that dos2unix job should be done one Legacy to make it cleaner)
 
- It is a quick big patch, but about the same size as the one in Legacy, about 10MB of text file.
 
- Even after applying the patch, we still need to have some other patches, one for DefConfig in Igor's lib/config and one for DTS which I will work on tomorrow ...
 
- Then, lots of testing need to be done, especially that I need to figured out that everything is working in the fresh build environment, then a PR will be sent to Igor.

I've been working on the rtl8189fs patches for Mainline.
 
Althouth the source code change between Legacy and Mainline is pretty trivial, preparing good and nice patches becomes a tedious task :
 
- First, the original patch in Legacy contains tons of DOS file formatted (strange for a Linux driver, shame on Realtek) and even dos2unix failed on some files because of binaries character (probably Chinese), I had to edit many files because I wouldn't "signed-off" such ugly thing. (btw, maybe that dos2unix job should be done one Legacy to make it cleaner)
 
- It is a quick big patch, but about the same size as the one in Legacy, about 10MB of text file.
 
- Even after applying the patch, we still need to have some other patches, one for DefConfig in Igor's lib/config and one for DTS which I will work on tomorrow ...
 
- Then, lots of testing need to be done, especially that I need to figured out that everything is working in the fresh build environment, then a PR will be sent to Igor.

I've been working on the rtl8189fs patches for Mainline.
 
Althouth the source code change between Legacy and Mainline is pretty trivial, preparing good and nice patches becomes a tedious task :
 
- First, the original patch in Legacy contains tons of DOS file formatted (strange for a Linux driver, shame on Realtek) and even dos2unix failed on some files because of binaries character (probably Chinese), I had to edit many files because I wouldn't "signed-off" such ugly thing. (btw, maybe that dos2unix job should be done one Legacy to make it cleaner)
 
- It is a quick big patch, but about the same size as the one in Legacy, about 10MB of text file.
 
- Even after applying the patch, we still need to have some other patches, one for DefConfig in Igor's lib/config and one for DTS which I will work on tomorrow ...
 
- Then, lots of testing need to be done, especially that I need to figured out that everything is working in the fresh build environment, then a PR will be sent to Igor.

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.

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 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 !

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 !

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.

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.

Of course, I would try to put 2 litters of milk in a 750ml bottle ...
 
But the beauty of "tar piped in another tar" is that you can even do it across SSH.
(For full backup, you still need to be aware of not including backup of special folders, such as "/lost+found" or "/proc" )
 
Or course, the rsync method is good too !

For the patches, since most were already applied, I've applied manually the 0001-ethernet-add-sun8i-emac-driver.patch follow by 0005-ethernet-add-sun8i-emac-driver.patch, but both looks the same.
 
For iperf, you will be deceived ... I didn't provide any options except -c/-s, tested on both directions, first thru the R8188eu Wifi  :
root@orangepipc:~# iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local 10.111.111.73 port 5001 connected with 10.111.111.11 port 43820 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.3 sec 39.8 MBytes 32.5 Mbits/sec ^Croot@orangepipc:~# iperf -c 10.111.111.11 connect failed: Connection refused root@orangepipc:~# iperf -c 10.111.111.11 ------------------------------------------------------------ Client connecting to 10.111.111.11, TCP port 5001 TCP window size: 43.8 KByte (default) ------------------------------------------------------------ [ 3] local 10.111.111.73 port 56344 connected with 10.111.111.11 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 45.2 MBytes 37.8 Mbits/sec and then thru eth0 :
root@orangepipc:~# iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local 10.111.111.80 port 5001 connected with 10.111.111.11 port 53540 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.4 sec 11.6 MBytes 9.41 Mbits/sec root@orangepipc:~# iperf -c 10.111.111.11 ------------------------------------------------------------ Client connecting to 10.111.111.11, TCP port 5001 TCP window size: 43.8 KByte (default) ------------------------------------------------------------ [ 3] local 10.111.111.73 port 56346 connected with 10.111.111.11 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 28.5 MBytes 23.7 Mbits/sec So, lets keep Champagne for another day, and open simple Sparkling wine instead ...

About the build process, I've noticed that /tmp folder of my workstation is always becoming RO for other groups/users, so after "sudo ./compile.sh" finished, I always need to do a "sudo chmod a+rw /tmp"

Here are the patches I've prepared for getting I2C and SPI on OrangePiPC under 4.4.4.
 
BTW, Tkaiser, I wouldn't been able to add the last I2C (TWI_R where the PMIC is attached) because lack of PL* pins in the current H3 pinctrl.
I would'nt like start new task for that since the mainline guys already working to have another H3 R_PinCtrl : https://lkml.org/lkml/2016/2/1/150
orangepipc-patches.zip

Yes, that was my intention, but unfortunately, it doesn't seem to be an easy task. I will try to dig further ...

About the build process, I've noticed that /tmp folder of my workstation is always becoming RO for other groups/users, so after "sudo ./compile.sh" finished, I always need to do a "sudo chmod a+rw /tmp"

"Time" is always the "missing ingredient" ...
But at least, there is some existing documentation, although a bit outdated : http://linux-sunxi.org/I2Cdev
Maybe I will try to get chance to contribute in this page by adding some testing python code for controlling a GPIO expander such MCP23017.
 
EDIT : For SPI, there is a simlar page : http://linux-sunxi.org/SPIdev
 
EDIT2 : I've ran successfully this quick SPI test : https://raw.githubusercontent.com/loboris/OrangePI-Kernel/master/linux-3.4/Documentation/spi/spidev_test.c

Hi Igor,
Hi TKaiser,
 
Seeing those progress and commits, I've decided to jump into the bandwagon ! :-)
I've compiled an image using Armbian-4.4.1 for OrangePi-PC, write it to a microsd and try it out.
It boot properly, although boot is not very verbose, I presume it is on purpose.
I decided next to get some networking using RTL8188 dongle : it wasn't seen in lsusb at first, I've connected it to vertical USB, but placing into the dual one, it worked !
I've then look at the GPIO using orangepi_PC_gpio_pyH3-master, it work too !
But for I2C bus, none are detected, so maybe there is something to tweak in the kernel configs, I will digg more ...
 
BTW, I wasn't able to verify the clock speed, it is not in /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq anymore. Where should I look ?
(in the dmesg log, I can see "cpu cpu0: failed to get cpu0 clock: -2")
 
Thanks for all your work,
 
EDIT : For I2C, I've compared kernel configs with my previous Loboris's build, and they look Ok, so it is maybe a bug ... :-(