wifi on Linx 7 (rtl8723bs)

[mdt01]

Thanks. I will look at how it is working in Ubuntu using lsmod and dmesg tomorrow.

I know these devices are prone to hardware failures, but I have a large number of them obtained at low price and they will do the job nicely if the wifi can be enabled. As you say, it shouldn't be a hardware issue we are dealing with here as the wifi works fine under Windows or Ubuntu.

The output from modinfo on r8723bs is shown below.

Code: [Select]

tc@box:~$ modinfo r8723bs
filename:       /lib/modules/4.19.10-tinycore64/kernel/net/wireless/r8723bs.ko
author:         Realtek Semiconductor Corp.
description:    Realtek Wireless Lan Driver
license:        GPL
parm:           rtw_decrypt_phy_file:Enable Decrypt PHY File
parm:           rtw_load_phy_file:PHY File Bit Map
parm:           rtw_phy_file_path:The path of phy parameter
parm:           rtw_tx_pwr_by_rate:0:Disable, 1:Enable, 2: Depend on efuse
parm:           rtw_tx_pwr_lmt_enable:0:Disable, 1:Enable, 2: Depend on efuse
parm:           rtw_hiq_filter:0:allow all, 1:allow special, 2:deny all
parm:           rtw_notch_filter:0:Disable, 1:Enable, 2:Enable only for P2P
parm:           rtw_80211d:Enable 802.11d mechanism
parm:           rtw_max_roaming_times:The max roaming times to try
parm:           ifname:The default name to allocate for first interface
parm:           rtw_ant_num:Antenna number setting
parm:           rtw_btcoex_enable:Enable BT co-existence mechanism
parm:           rtw_ips_mode:The default IPS mode
version:        v4.3.5.5_12290.20140916_BTCOEX20140507-4E40
alias:          sdio:c*v024CdB723*
alias:          sdio:c*v024Cd0626*
alias:          sdio:c*v024Cd0623*
alias:          sdio:c*v024Cd0523*
alias:          acpi*:OBDA8723:*
srcversion:     9F5053931B4FCB925397E4C
depends:        mmc_core,cfg80211
intree:         Y
vermagic:       4.19.10-tinycore64 SMP mod_unload
tc@box:~$


[mdt01]

I have attached dmesg.txt and lsmod.txt files from TinyCore64 and Ubuntu_16.04 respectively on the same device. While obviously much more gets loaded in Ubuntu I have not spotted any clues. The wifi can be seen to go through the appropriate connection steps in Ubuntu whereas it gets no further than loading the module in TinyCore.

For what it is worth, in Windows the wifi card sits on the Intel SD Host Controller.

I came across an old post about patching to enable this wifi device and I notice that much of the patching was done to the drivers/mmc/host/sdhci.c, drivers/mmc/host/acpci.c and drivers/mmc/host/pci.c files. As the post is very old, is it correct to assume that should all now be incorporated in the current kernel? https://watchmysys.com/blog/2015/12/arch-linux-and-sdio-wifi-on-a-bay-trail-tablet/

I wondered about going back to a slightly older kernel in case some regression has occurred, but it looks like TinyCore64 10.0 and 10.1 have the same kernel number. I looked at dCore64 but it looks like the kernel is the same as TinyCore64.

It would be good to get this working. I would be up for some debugging by adding debug print statements etc., if someone did not mind pointing me in the right direction and doing some hand holding. My programming experience is mainly C++ and CUDA on Windows, so I am comfortable with working through difficult debugging issues but would need help with the Linux/driver/kernel related aspects.

[curaga]

mmc1: SDHCI controller on ACPI [80860F14:00] using ADMA

This is the key line, from the ubuntu dmesg. Your sdio controller is not detected under TC for some reason. First try running "sudo modprobe sdhci-pci", and if it gives any info in dmesg. If that doesn't help any, then it'd be debug prints (printk()) into sdhci-acpi.c in the kernel, building that module, and replacing TC's module with yours (sudo rmmod sdhci-acpi; sudo modprobe sdhci-acpi).

[mdt01]

Thanks. After the line you pointed out I can see, in the Ubuntu dmesg but not in TC dmesg, the lines shown below.

Code: [Select]

[    3.917759] mmc0: SDHCI controller on ACPI [INT33BB:00] using ADMA
[    3.938433] hidraw: raw HID events driver (C) Jiri Kosina
[    3.939807] mmc1: SDHCI controller on ACPI [80860F14:00] using ADMA
[    3.960861] i2c_hid i2c-FTSC1000:00: i2c-FTSC1000:00 supply vdd not found, using dummy regulator
[    3.967060] mmc2: SDHCI controller on ACPI [80860F14:02] using ADMA
[    3.977002] mmc0: new high speed SDIO card at address 0001

INT80860F14 features in Ubuntu but not TC dmesg. Could the SDIO card referred to be the wifi?

I was not sure when you said "First try running sudo modprobe sdhci-pci" whether you meant sdhci-pci or sdhci-acpi, but doing either of these does not give any additional information in dmseg and has no effect on the wifi not being found.

I have found sdhci-acpi.c (in /home/tc/tmp/linux-4.19.10/drivers/mmc/host) and would like to use printk() to see what goes on, but due to my lack of Linux experience I don't know how to build just that module - there must be some very basic make or GCC invocation needed, but I am used to using Visual Studio in Windows so I don't know to do that bit - would you mind explaining?

Meanwhile: I came across this post in another disto's forum: https://bbs.archlinux.org/viewtopic.php?id=193180 , posts #4 to #11.

The posters seem to have got the same wifi working on a similar BayTrail platform by enabling a kernel setting " CONFIG_PINCTRL_BAYTRAIL=y ", as well as building the driver as we have done. When I look through the TC kernel settings with make menuconfig (as in Reply #8 of this thread), I can find the CONFIG_PINCTRL_BAYTRAIL setting through the menu under Device Drivers -> Pin controllers -> Intel BayTrail GPIO pin control. It is not enabled currently. It can only be set to Y or N, not M, so does this mean I would have to enable it then recompile the whole kernel to test it. Does that sound worth trying?

[curaga]

Yes, enabling that pinctrl setting is worth a try. Set it to Y, since it enables some other options not currently enabled, and run "make bzImage". Then you can copy the file arch/x86/boot/bzImage to your bootloader's dir, and use it in place of our vmlinuz.

Such a change may invalidate our shipped modules, in which case you'd need to build the modules as well, and pack them up. However do test first.

edit: the kernel build system is smart enough to detect changes, so if you have already ran "make modules", running it again will only build changed files. So no need to dig up the commands to only build one module.

[mdt01]

Thanks. Enabling CONFIG_PINCTRL_BAYTRAIL did not help.

I am out of time to work on this for a while now. I will do some debugging with PrintK() if I get time, or I might see if I can strip things out of the version of Ubuntu that is working on this hardware to minimize memory use in that way.

Thanks for the support.

[labeas]

I also need a RTL8723bs driver, & have no intentions of trying to compile one.
But didn't your thread start about ARM-based?
I'd prefer the wifi-files for TC64, but could manage for 32bit - I think.
Perhaps it was bad to buy latest chinese-cheapo-Wintel ?

[labeas]

I had a look at the MASSIVE ubuntu article mentioned:
http://linuxiumcomau.blogspot.com/2017/06/customizing-ubuntu-isos-documentation.html
and without understanding about "spindown" ..etc., noted several mentions
about <Intel Atom>; almost implying that the atom doesn't behave like a normal
x86. That's the first factor that I HAD considered when debugging this multi-
core atom problematic Laptop.
 Have any TC users fixed this RTL8723bs - UEFI problem ?

[Juanito]

Your link seems to suggest that you need a 32-bit UEFI boot loader for an atom - have you tried that?

I assume you’d need the grub2-multi extension from the 32-bit core repo to write the boot loader.

Something analogous to:

Code: [Select]

sudo grub-install --target=i386-efi --boot-directory=/mnt/sdc1/EFI/BOOT --efi-directory=/mnt/sdc1 --removable

[labeas]

> Your link seems to suggest that you need a 32-bit UEFI boot loader
AFAIR I've confirmed that *THE* TC64 <grub2-multi> booter, which this
whole project centres around, DOES boot 32bit "core" V10; apart from
the TC64:V10kernel & v7.2;apps.

> I assume you’d need the grub2-multi extension from the 32-bit core
> repo to write the boot loader.
Doesn't the one that I'm using boot both 64 & 32bit kernels?

> Something analogous to:
> Code: [Select]
>  sudo grub-install --target=i386-efi --boot-directory=/mnt/sdc1/EFI/BOOT --efi-directory=/mnt/sdc1 --removable
I've read that <grub can't just have the *.cfg edited; it needs the
alterations to be INSTALLED>. This doesn't match the original instructn
and thread about the <line break problem in the *.cfg>.
Have YOU actually used it ?!

If I could get the URLs for the rtl8723bs firmware and the other *.tcz
for the wifi, we could perhaps close this problem. I'll search for them.
BTW a simple SEQUENCE of steps, with each one CONFIRMING its output, is
better than a smartass-automatic-popup-menu based wifi-connector, for
such PROBLEMATIC tasks.
 

[Juanito]

Your posts are very difficult to read - I understood that you could not boot tinycore on your atom using a 64-bit uefi bootloader.

If you can boot tinycore on your atom then use the "lspci" command to double-check what wifi hardware you have.

If you cannot boot tinycore on your atom then perhaps it is because a 32-bit uefi bootloader is required.

..and yes, I use a 64-bit uefi bootloader to boot both 32-bit and 64-bit tinycore.

[labeas]

 quote chars as used by non-tech-writers have SPECIAL-MEANING in IT.
-------
The atom DOES boot with <our grub2dos>.
Finally there's strong evidence that it requires <rtl8723bs> driver.
Rich gave the URL to wget the 2 files for Ver10.
After I wGot the 2 files, using the V7.2-wifi-capableSys, I plugged
the Atom'sUSBstik to copy the files, and noticed that the <grub2dos
Atom'sUSBstik> could also boot the V7.2laptop, which previously had
failed. This diverted my attention. Then the local?national Wifi
failed for 2 days.
My InstallScript uses `ls` which does alphabetic ordering, so that;
firmware*tcz IS installed before wi*tcz.
In fact NOW on this V7.2: `df` shows the alpha ordering of /dev/loop*
 

[mdt01]

I am posting this here on this old thread as it is the solution to the previously unresolved opening question of the thread.

I now have the rtl18723bs wifi working.

(The post below is split into sections as I keep getting an error - presumably it is too long!)

To recap what was discussed before:

I have some Linx 7 and Linx 10 devices which have Bay Trail Atom Z3735G/F processors and rtl8723bs wifi. I am using TinyCore64.

When I tried 18 months ago with TC10 and kernel 4.19.10 we could not get the wifi card recognised. I had correctly installed the appropriate firmware-rtlwifi and wifi extensions but running sudo wifi.sh always reported "No wifi devices found".

It was pointed out that the rtl8723bs driver is in staging so I needed to compile it as a module and load this as an extension, but the wifi card was still not found after that. It appeared that there was an issue with the support for the SDIO bus on which the card sits, as there were messages relating to this in dmesg from Ubuntu (which was finding the card) which were not present in dmesg from TinyCore64. I tried a few kernel settings but ran out of time to work on it at that stage.

I have come back to this now and followed the same procedures but with the latest TC12 with the 5.10.3 kernel and it works. The wifi is found and connects. There are positive messages in dmesg about the SDIO bus which were not there before.

It looks like there have been some changes either in the TinyCore64 config or in the kernel (or both) which have improved the SD card support and done the trick.

Many thanks to whoever made those changes.

[mdt01]

So, to summarize the procedure that works:

Download and set up TinyCore64 v 12 with 5.10.3 kernel. I needed it installed to SSD with persistent home and opt directories and a swap file, otherwise it kept falling over for lack of memory when compiling modules.

Install firmware-rtlwifi and wifi extension. Run wifi.sh.  -- It will not work at this point.

Install  compiletc, bc, bash, perl5, ncursesw-dev, elfutil-dev.

Download:
http://tinycorelinux.net/12.x/x86_64/release/src/kernel/config-5.10.3-tinycore64
http://tinycorelinux.net/12.x/x86_64/release/src/kernel/linux-5.10.3-patched.txz

run:

Code: [Select]

tar xf linux-5.10.3-patched.txz
cd linux-5.10.3
make mrproper
cp /home/tc/config-5.10.3-tinycore ./.config
make menuconfig
In menuconfig find Device Drivers | Staging Drivers|rtl8723bs, set to m, save and exit menuconfig
make modules

Make modules takes about 4 hours as it has to make all the modules. I needed TC64 fully installed with persistent home and opt directories and a swap file otherwise it kept falling over for lack of memory.

[mdt01]

To test:

Code: [Select]

sudo mkdir /lib/modules/5.10.3-tinycore64/kernel/drivers/net/wireless
sudo cp tmp/linux-5.10.3/drivers/staging/rtl8723bs/r8723bs.ko /lib/modules/5.10.3-tinycore64/kernel/drivers/net/wireless
sudo depmod -a
sudo modprobe r8723bs

When that works, to connect on boot make an extension to install the r8723bs.ko module to /lib/modules/5.10.3-tinycore64/kernel/drivers/net/wireless. Add it to onboot.lst, followed by the firmware-rtlwifi and wifi extensions.

In file /opt/bootlocal.sh add the line:

/usr/local/bin/wifi.sh -a 2>&1  > temp/wifi.log

Reboot – hopefully it works now.

I am not sure I have got the hang of formatting my posts – feel free to edit and tidy them up or correct any errors.

Thanks again for the previous advice.