Tiny Core Linux
Tiny Core Base => Corepure64 => Topic started by: mdt01 on September 27, 2019, 01:11:14 PM
-
Hi
I wonder if anyone can help with this? I have some Linx 7 tablets for a project. They have an atom processor and originally came with Windows 8.1 (32 bit) and have been running Windows 10 (32 bit) fine. I would like to run a 64 bit program so need a 64 bit OS. They only have 32 bit efi so Windows 64 will not load but I have been using Ubuntu_16.04 64 bit thanks to the methods of Linuxium detailed here: http://linuxiumcomau.blogspot.com/2017/06/customizing-ubuntu-isos-documentation.html (http://linuxiumcomau.blogspot.com/2017/06/customizing-ubuntu-isos-documentation.html) .
Ubuntu works fine but uses a lot of the availabe 1GB of RAM, leaving not much for my program which becomes very slow due to lots of swapping to disk. I would like more free memory to use, so TinyCore64 seems ideal.
I have managed to boot TinyCore64 (from USB so far) by borrowing the modified 32-64 boot_efi file from Linuxium's method and it mostly seems to work except I can't get the wifi working. A usb-ethernet adaptor is giving me internet access for now but I need the wifi for operational use.
I have followed the steps detailed in the wifi setup instructions but the wifi is not found.
The wifi device is a RTL8723bs. It works fine under Windows or Ubuntu.
Specifically I have tried the following:
Boot with no wifi extensions loaded
Load firmware-rtlwifi extension
Load the wifi extension, which also loads wireless_tools, wireless -4.19.10-tinycore64, libiw, wpa_supplicant-dbus, openssl and libnl
Run sudo wifi.sh which reports : No wifi devices found
Run iwconfig which reports: dummy0 no wireless extensions, eth0 no wireless extensions, lo no wireless extensions, tun10 no wireless extensions, ip_vti0 no wireless extensions.
dmesg | tail -20 gives :
loop: module loaded
zram0: detected capacity change from 0 to 213274624
random: mkswap: uninitialized urandom read (16 bytes read)
Adding 208272k swap on /dev/zram0. Priority:-2 extents:1 across:208272k SSFS
squashfs: version 4.0 (2009/01/31) Phillip Lougher
FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
random: crng init done
r8152 1-1.4.2:1.0 eth0: carrier on
ACPI: AC: found native INT33F4 PMIC, not loading
ACPI: AC: found native INT33F4 PMIC, not loading
ACPI: AC: found native INT33F4 PMIC, not loading
ACPI: AC: found native INT33F4 PMIC, not loading
ACPI: AC: found native INT33F4 PMIC, not loading
ACPI: AC: found native INT33F4 PMIC, not loading
ACPI: AC: found native INT33F4 PMIC, not loading
ACPI: AC: found native INT33F4 PMIC, not loading
ACPI: AC: found native INT33F4 PMIC, not loading
ACPI: AC: found native INT33F4 PMIC, not loading
ACPI: AC: found native INT33F4 PMIC, not loading
I also tried the wicd method which shows the usb ethernet connection but says no wirless device found.
Any help would be much appreciated.
Thanks
Martin
-
Hi, mdt01!
Looks strange, firmware-rtlwifi.tcz includes binaries for your rtl8723bs. Do you load this extension manually or it stands first in your onboot.lst?
You can load then pci-utils.tcz and list your devices using
lspcior
lspci -v to see more details including driver in use, maybe with some grepping.
Also You can use lshw.tcz for
sudo lshw -c network
Good luck!
-
By the way, what the use of running 64-bit on 1G RAM?
Can the efi correction disturb something?
-
Thanks jazzbiker
I have tried loading firmware-rtlwifi.tcz onboot, first in the onboot.lst, or manually and it makes no difference.
Interestingly lspci, lspci -v or even lspci -vv gives nothing about the wifi device or driver. lsusb finds only the wired usb-ethernet device and driver.
I can't find lshw.tcz in the app browser - could lshw be in another extension or have I missed something?
I can run sudo lshw on Ubuntu on the same machine and it finds wlan0. I don't inderstand the output of lshw but it looks like the wlan0 is listed separately at the end rather than under the pci section. I wonder if it is on some other bus - I don't know enough about computer architecture to understand the possibilities.
I know it sounds odd wanting to run a 64 bit os on a machine with 1GB RAM, but part of my project works best with a windows binary which was compiled in 64 bit and running this in WINE on Ubuntu does the job nicely apart from the Ubuntu OS using up so much memory which slows it down bigtime. I don't think the 64 bit os on 32 bit efi should be the issue as I think I undertand that Linux takes over once you have got it to boot.
It works OK on Ubuntu - I wonder if they have more drivers/firmware and if there is a way I can figure out how Ubuntu is making it work - but I am not that knowledgeable about Linux internals.
Thanks for your help.
-
Hi mdt01
... Interestingly lspci, lspci -v or even lspci -vv gives nothing about the wifi device or driver. lsusb finds only the wired usb-ethernet device and driver. ...
Maybe you need to update the PCI database:
use "sudo update-pciids" to get the latest pci device data from the web
note that the full gnu versions of gzip and curl are required for the above
add usr/local/share/hwdata/pci.ids.gz to your backup to keep the update
This was from the .info file of the 32 bit version. This note is missing from the 64 bit .info file.
I can't find lshw.tcz in the app browser - could lshw be in another extension or have I missed something?
It doesn't appear to exist in the 64 bit repository.
It works OK on Ubuntu - I wonder if they have more drivers/firmware and if there is a way I can figure out how Ubuntu is making it work - but I am not that knowledgeable about Linux internals.
If you run:
lsmodyou'll get a list of loaded drivers.
-
Hi, mdt01!
I didn't took into consideration earlier, but rtl8723bs is described as "SDIO wlan controller". Maybe this means that it is connected not to PCI bus but to SDIO interface? I don't know what to do with this, maybe try to run 32-bit TinyCore and use lshw.
p.s. there exists usbutils.tcz with lsusb...
and You can run Ubuntu and refine all information in it, using all this ls*** utils, and then try to achieve the same in TinyCore.
-
The rtl8723bs driver is still in staging. That means it's bad quality, we don't enable staging drivers. You would have to build it yourself in order to use it.
-
Thanks for all the replies. I will work through the suggestions.
It sounds like building the driver myself is the place to start. I will read around how to do that and come back when I get stuck!
-
Hi mdt01
... I will read around how to do that and come back when I get stuck!
Install compiletc, bc, bash, perl5, and ncurses-dev.
Download:
http://tinycorelinux.net/10.x/x86_64/release/src/kernel/config-4.19.10-tinycore64
http://tinycorelinux.net/10.x/x86_64/release/src/kernel/linux-4.19.10-patched.txz
Then:
$ tar xf linux-3.8.13-patched.txz
$ cd linux-3.8.13-patched
$ make mrproper
$ cp /tmp/config-3.8.13-tinycore ./.config
$ make menuconfig
[set nvidia module to "m"]
$ make modules
..and then gzip the nv module and make your own personal extension of it.
Notes: Replace 3.8.13 with 4.19.10 in the above directions. Ignore the references to nvidia and nv, they refer to a video driver.
Running make modules took approximately 4 hours on my Dell E310 with 1Gig of RAM.
-
Hi mdt01
In make menuconfig the menu path you want to follow is drivers->staging->rtl8723bs.
-
Hi, I am still working on the above, with a bit of a gap as the rest of life took over for a while.
I have built the RTL8723BS module as per the instructions above, and I end up with a file called r8723bs.ko.
Before trying to figure out how to make my own extension containing this I wanted to test it, so I followed some of the suggestions in this thread http://forum.tinycorelinux.net/index.php/topic,21939.msg137251.html#msg137251 (http://forum.tinycorelinux.net/index.php/topic,21939.msg137251.html#msg137251).
Specifically I have done:
sudo mkdir /lib/modules/4.19.10-tinycore64/kernel/drivers/net/wireless
sudo cp tmp/linux-4.19.10/drivers/staging/rtl8723bs/r8723bs.ko /lib/modules/4.19.10-tinycore64/kernel/drivers/net/wireless
sudo depmod -a
sudo modprobe r8723bs
sudo depmod -a adds a line to modules.dep which reads:
kernel/drivers/net/wireless/r8723bs.ko: kernel/drivers/mmc/core/mmc_core.ko.gz
sudo modprobe r8723bs returns:
modprobe: can't load module r8723bs (kernel/drivers/net/wireless/r8723bs.ko): unknown symbol in module or unknown parameter.
My programming experience is mostly on Windows so I am a relative newbie to Linux - am I doing this bit right or what should I look at next?
Many thanks.
-
Was the wireless-KERNEL extension loaded? If not, load it and try the modprobe command again.
-
"dmesg" will tell you more about the symbols.
-
Thanks. Loading the wifi extension including the wireless-KERNEL extension gets rid of the modprobe error message and dmesg now shows messages implying that the r8723bs module has loaded. However, with this and the relevant firmware-rtlwifi extension loaded then still no wifi device is detected.
I updated the PCI Database as suggested above, but the RTL8723bs is still not detected with lspci. Reading about the RTL8723bs indicates that it has an SDIO interface. Could there be another module that I need to load to support this interface?
I came across this thread which seems to indicate another user got this RTL8723bs wifi working, but it is not clear from the thread what the successful steps were : http://forum.tinycorelinux.net/index.php?topic=19622.msg121742#msg121742 (http://forum.tinycorelinux.net/index.php?topic=19622.msg121742#msg121742).
I have the same RTL8723bs wifi working in Ubuntu. Running lsmod in Ubuntu lists the following:
sudo lsmod
Module Size Used by
binfmt_misc 20480 1
nls_iso8859_1 16384 2
joydev 24576 0
dwc3 114688 0
snd_soc_sst_bytcr_rt5640 24576 1
ulpi 16384 1 dwc3
udc_core 49152 1 dwc3
extcon_axp288 16384 0
axp288_fuel_gauge 20480 0
axp288_charger 20480 0
axp20x_pek 16384 0
intel_rapl 20480 0
intel_soc_dts_thermal 16384 0
axp288_adc 16384 0
gpio_keys 20480 0
intel_powerclamp 16384 0
coretemp 16384 0
kvm 598016 0
irqbypass 16384 1 kvm
punit_atom_debug 16384 0
crct10dif_pclmul 16384 0
crc32_pclmul 16384 0
ghash_clmulni_intel 16384 0
pcbc 16384 0
aesni_intel 188416 0
aes_x86_64 20480 1 aesni_intel
crypto_simd 16384 1 aesni_intel
glue_helper 16384 1 aesni_intel
cryptd 24576 3 crypto_simd,ghash_clmulni_intel,aesni_intel
intel_cstate 20480 0
cdc_ether 16384 0
hid_multitouch 20480 0
usbnet 45056 1 cdc_ether
r8152 61440 0
input_leds 16384 0
mii 16384 2 usbnet,r8152
snd_soc_rt5670 131072 0
snd_soc_rt5645 143360 0
lpc_ich 24576 0
mei_txe 20480 0
snd_intel_sst_acpi 16384 1
mei 94208 1 mei_txe
dwc3_pci 16384 0
snd_soc_rt5640 114688 2 snd_soc_sst_bytcr_rt5640
snd_intel_sst_core 53248 1 snd_intel_sst_acpi
snd_soc_rl6231 16384 3 snd_soc_rt5670,snd_soc_rt5640,snd_soc_rt5645
snd_soc_sst_atom_hifi2_platform 102400 3 snd_intel_sst_core
snd_soc_acpi 16384 2 snd_soc_sst_bytcr_rt5640,snd_intel_sst_acpi
snd_soc_acpi_intel_match 20480 1 snd_intel_sst_acpi
snd_soc_core 241664 5 snd_soc_sst_bytcr_rt5640,snd_soc_rt5670,snd_soc_rt5640,snd_soc_sst_atom_hifi2_platform,snd_soc_rt5645
snd_hdmi_lpe_audio 24576 1
snd_compress 20480 1 snd_soc_core
ac97_bus 16384 1 snd_soc_core
snd_pcm_dmaengine 16384 1 snd_soc_core
snd_pcm 98304 8 snd_soc_sst_bytcr_rt5640,snd_soc_rt5670,snd_soc_rt5640,snd_hdmi_lpe_audio,snd_soc_sst_atom_hifi2_platform,snd_soc_core,snd_soc_rt5645,snd_pcm_dmaengine
snd_seq_midi 16384 0
snd_seq_midi_event 16384 1 snd_seq_midi
mac_hid 16384 0
snd_rawmidi 32768 1 snd_seq_midi
dw_dmac 16384 0
dw_dmac_core 24576 1 dw_dmac
soc_button_array 16384 0
dptf_power 16384 0
snd_seq 65536 2 snd_seq_midi,snd_seq_midi_event
int3406_thermal 16384 0
processor_thermal_device 16384 0
int3403_thermal 16384 0
int340x_thermal_zone 16384 2 int3403_thermal,processor_thermal_device
intel_soc_dts_iosf 16384 2 intel_soc_dts_thermal,processor_thermal_device
r8723bs 602112 0
snd_seq_device 16384 3 snd_seq,snd_seq_midi,snd_rawmidi
int3400_thermal 16384 0
snd_timer 32768 2 snd_seq,snd_pcm
acpi_thermal_rel 16384 1 int3400_thermal
intel_int0002_vgpio 16384 0
intel_cht_int33fe 16384 0
cfg80211 626688 1 r8723bs
axp20x_i2c 16384 0
axp20x 24576 1 axp20x_i2c
snd 81920 13 snd_seq,snd_seq_device,snd_timer,snd_compress,snd_hdmi_lpe_audio,snd_soc_sst_atom_hifi2_platform,snd_soc_core,snd_pcm,snd_rawmidi
kxcjk_1013 20480 0
soundcore 16384 1 snd
industrialio_triggered_buffer 16384 1 kxcjk_1013
kfifo_buf 16384 1 industrialio_triggered_buffer
acpi_pad 180224 0
industrialio 69632 5 axp288_adc,industrialio_triggered_buffer,kfifo_buf,axp288_fuel_gauge,kxcjk_1013
8250_dw 16384 0
parport_pc 32768 0
ppdev 20480 0
lp 20480 0
parport 49152 3 parport_pc,lp,ppdev
autofs4 40960 2
overlay 77824 0
uas 24576 0
usb_storage 69632 2 uas
hid_generic 16384 0
usbhid 49152 0
mmc_block 36864 4
i915 1630208 63
i2c_algo_bit 16384 1 i915
drm_kms_helper 172032 1 i915
syscopyarea 16384 1 drm_kms_helper
sysfillrect 16384 1 drm_kms_helper
sysimgblt 16384 1 drm_kms_helper
fb_sys_fops 16384 1 drm_kms_helper
drm 401408 6 drm_kms_helper,i915
video 45056 2 int3406_thermal,i915
i2c_hid 24576 0
hid 114688 4 i2c_hid,usbhid,hid_multitouch,hid_generic
sdhci_acpi 16384 0
sdhci 49152 1 sdhci_acpi
pwm_lpss_platform 16384 0
pwm_lpss 16384 1 pwm_lpss_platform
[EDIT]: Added code tags. Rich
-
The firmware-rtlwifi extension needs to be loaded first.
What does the last ten lines of dmesg say?
-
Thanks. I am booting with no wifi related extensions loaded then doing the following:
tce-load -i firmware-rtlwifi
tce-load -i wifi
sudo mkdir /lib/modules/4.19.10-tinycore64/kernel/net/wireless
sudo cp /home/tc/tmp/linux-4.19.10/drivers/staging/rtl8723bs/r8723bs.ko /lib/modules/4.19.10-tinycore64/kernel/net/wireless
sudo depmod -a
sudo modprobe r8723bs
sudo wifi.sh
which returns "No wifi devices found!"
The last few lines of dmesg are:
ACPI: AC: found native INT33F4 PMIC, not loading
ACPI: AC: found native INT33F4 PMIC, not loading
platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
platform regulatory.0: Falling back to syfs fallback for: regulatory.db
r8723bs: module is from the staging directory, the quality is unknown, you have been warned.
RTL8723BS: module init start
RTL8723BS: rtl8723bs v4.3.5.5_12290.20140916_BTCOEX20140507-4E40
RTL8723BS: rtl8723bs BT-Coex version = BTCOEX20140507-4E40
RTL8723BS: module init ret =0
cfg80211: failed to load regulatory.db
[EDIT]: Added code tags. Rich
-
If you load the crda extension before the firmware does that help?
-
Thanks, but loading the crda extension first has not helped.
Still "No wifi devices found!" and the last 10 lines of dmesg are identical to those shown above.
-
Not sure if this helps, but I noticed the lshw extension is now available on the 64 bit TC version so I ran it on TinyCore64 where the wifi is not found and compared it to the same command on Ubuntu where the wifi is found:
TinyCore64 output:
tc@box:~$ sudo lshw -c network
*-network:0 DISABLED
description: Ethernet interface
physical id: 1
logical name: dummy0
serial: e6:18:c3:b1:ab:77
capabilities: ethernet physical
configuration: broadcast=yes driver=dummy driverversion=1.0
*-network:1
description: Ethernet interface
physical id: 2
logical name: eth0
serial: 00:e0:4c:68:c2:d7
size: 100Mbit/s
capacity: 1Gbit/s
capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8152 driverversion=v1.09.9 duplex=full ip=192.168.1.6 link=yes multicast=yes port=MII speed=100Mbit/s
Ubuntu 16.04 output:
mdt01@Ubuntu16:~$ sudo lshw -c network
*-network:0
description: Wireless interface
physical id: 1
logical name: wlan0
serial: 08:d8:33:6b:9d:b4
capabilities: ethernet physical wireless
configuration: broadcast=yes driver=rtl8723bs ip=192.168.1.17 multicast=yes wireless=IEEE 802.11bgn
*-network:1
description: Ethernet interface
physical id: 2
logical name: enx00e04c68c2d7
serial: 00:e0:4c:68:c2:d7
size: 100Mbit/s
capacity: 1Gbit/s
capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8152 driverversion=v1.09.9 duplex=full ip=192.168.1.6 link=yes multicast=yes port=MII speed=100Mbit/s
-
You could try using rfkill to enable wifi.
-
Thanks. Regrettably no progress with rfkill.
-
Does it list your WiFi as disabled?
-
The wifi was not listed at all
-
Hi mdt01
Thanks. I am booting with no wifi related extensions loaded then doing the following:
tce-load -i firmware-rtlwifi
tce-load -i wifi
sudo mkdir /lib/modules/4.19.10-tinycore64/kernel/net/wireless
sudo cp /home/tc/tmp/linux-4.19.10/drivers/staging/rtl8723bs/r8723bs.ko /lib/modules/4.19.10-tinycore64/kernel/net/wireless
sudo depmod -a
sudo modprobe r8723bs
sudo wifi.sh ...
After you do that, do this:
dmesg > dmesg.txt
lsmod > lsmod.txtand attach those files to your next post.
-
Thanks. Files attached.
-
If you load the crda extension and copy /usr/local/lib/crda/regulatory.bin to /usr/local/lib/firmware before loading r8723bs does that help?
or maybe: If you have kernel version 4.15 or newer, the regulatory database format and location has been changed. It is now loaded using the same mechanism as the firmware files. The new files can be found at https://kernel.googlesource.com/pub/scm/linux/kernel/git/sforshee/wireless-regdb/ and you'll need two files, regulatory.db and regulatory.db.p7s. Place them into /lib/firmware/ directory.
-
When I copy regulatory.db* to /usr/local/lib/firmware I get this:
$ dmesg
...
platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
platform regulatory.0: Falling back to syfs fallback for: regulatory.db
Intel(R) Wireless WiFi driver for Linux
Copyright(c) 2003- 2015 Intel Corporation
iwlwifi 0000:02:00.0: enabling device (0000 -> 0002)
iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-7260-17.ucode failed with error -2
iwlwifi 0000:02:00.0: Falling back to syfs fallback for: iwlwifi-7260-17.ucode
iwlwifi 0000:02:00.0: loaded firmware version 17.459231.0 op_mode iwlmvm
iwlwifi 0000:02:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144
iwlwifi 0000:02:00.0: base HW address: a0:a8:cd:2c:3e:13
ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
..so that looks like the way to go?
-
Thanks. The second method in the above two posts, i.e. getting the files from the link in reply#25 and copying regulatory.* to /usr/local/lib/firmware before loading r8723bs gets rid of the "cfg80211: failed to load regulatory.db" message. The last few lines of dmesg are now:
...
platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
platform regulatory.0: Falling back to syfs fallback for: regulatory.db
r8723bs: module is from the staging directory, the quality is unknown, you have been warned.
RTL8723BS: module init start
RTL8723BS: rtl8723bs v4.3.5.5_12290.20140916_BTCOEX20140507-4E40
RTL8723BS: rtl8723bs BT-Coex version = BTCOEX20140507-4E40
RTL8723BS: module init ret =0
However, the wifi is still not detected. sudo wifi.sh still says "No wifi devices found!" and iwconfig says "no wireless extensions".
This wifi module has an SDIO interface whereas most have a pci or pci-e interface, including Juanito's "Intel(R) Dual Band Wireless AC 7260".
Could there be something that supports the SDIO interface that we are missing?
-
You could check the tinycore lsmod with the other distro lsmod line by line to see if an sdio related driver is loaded.
What does modinfo rtl8732bs show?
-
No, there is no generic sdio part that could be missing; a lot of supported wireless drivers have sdio options enabled. Tracking why the driver does not find your card would probably involve some kernel debugging, adding debug prints in the driver, etc.
edit: Well, unless the sdio host controller driver of your device was also in staging.
edit 2: Ubuntu's dmesg may have some clues too.
Also, this device seems to be one of the buggy ones:
https://en.wikipedia.org/wiki/Silvermont#Erratum
The USB, SD and LPC parts of the chip may die starting from 18 months of use. Yours has clearly not yet died if it works under Ubuntu, but good to keep in mind.
-
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.
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:~$
-
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/ (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.
-
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).
-
Thanks. After the line you pointed out I can see, in the Ubuntu dmesg but not in TC dmesg, the lines shown below.
[ 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 (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?
-
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.
-
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.
-
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 ?
-
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 ?
-
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: sudo grub-install --target=i386-efi --boot-directory=/mnt/sdc1/EFI/BOOT --efi-directory=/mnt/sdc1 --removable
-
> 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.
-
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.
-
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*
-
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.
-
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:
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.
-
To test:
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.