Jump to content

source EXTRAWIFI


balbes150
 Share

Recommended Posts

In recent weeks, I have been testing a new approach to using the source code for external WiFi modules (RTL). Previously, I regularly got build environment crash issues due to unpredictable source updates for EXTRAWIFI. These sources are scattered in different places and absolutely do not  predictably change, breaking the kernel build. I'm tired of tracking such situations and regularly spending time creating emergency patches to restore the build process (or having to temporarily disable the EXTRAWIFI build). I compiled and placed all the sources in one controlled GIT. I still have them my GIT, but if your decide to switch to a new version of the build, it is advisable to transfer them to the Armbian shared resource in the future. The advantages of this option - full control the process of updating source, no need to create and change a bunch of different patches in the build system, eliminates the problem of correct encodings in the source code (when creating the patch turns into a quest with many unknowns), it is possible to have several stable and working versions of the source code for different kernel versions, further it is possible to simplify the patch adding the source code to build kernel, restricted to "dumb" copying (source code pre-fix and does not require complex manipulatsy). As new versions are released, you can slowly check their compatibility, add the necessary fixes to the source code, and only after checking, include the new code in the use of the General build system. This is a test version of the code.

 

 

https://github.com/150balbes/build/blob/armbian-tv/lib/compilation-prepare.sh

 

https://github.com/150balbes/wifi

 

P.S. By the way, I checked the build of all the modules with the source code for Rockchip-legacy, it was enough to add only two new options and all the modules are assembled normally.

Link to comment
Share on other sites

When discussing a problem make sure to provide full logs!

I am not sure how much time is saved this way.

On one side you save some time by not having to deal with regressions introduced in updated WiFi drivers.

But on the other hand you have to invest time to frequently check for new drivers and manually put port stuff over....

Link to comment
Share on other sites

1 час назад, Werner сказал:

I am not sure how much time is saved this way.

On one side you save some time by not having to deal with regressions introduced in updated WiFi drivers.

But on the other hand you have to invest time to frequently check for new drivers and manually put port stuff over....

Have you ever tried to catch bugs and create patches for these modules ? It is much easier for me to devote my time to updating the source code once a month (or 1-2 weeks) (when I know exactly what I need to do and know exactly where to expect possible problems) than to find out in emergency mode why the build process that just worked suddenly crashes and the mass build process of all images breaks down.

Link to comment
Share on other sites

4 hours ago, balbes150 said:

do not  predictably change


We have a very simple solution for this - instead of telling which branch attaching can be done directly to commit as example:
 

KERNELBRANCH='commit:ab9dfda232481dcfaf549ce774004d116fc80c13'


We keep this WiFi functionality well maintained as is and breaking things is a very rare event.

Link to comment
Share on other sites

This topic is not a special case with WIFI drivers.

There can be no simple solution.

The decision depends on the goal we set for ourselves.

On 12/11/2020 at 4:50 PM, TRS-80 said:

Is the goal to save time?  Or to provide a reliable distribution? 

A look at the root of the situation

Link to comment
Share on other sites

 Share

×
×
  • Create New...