Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: KeithA on January 10, 2024, 03:02:21 PM
-
I have always found the combination of a Raspberry Pi Zero W and piCore a very useful platform for projects such as remote controllers and a mini NAS. To start a project I initially connect the RPi0W to my router using a USB to LAN adapter so I can SSH into the Pi from PuTTY running on a laptop then use the tce commands to install wifi on the Pi. Once I have wireless connectivity, the USB to LAN adapter can be removed leaving me with a remote wirelessly connected Pi. This worked with piCore13 but with piCore14 I cannot connect via LAN to my router so am unable to use tce commands to install wifi onto the Pi.
As a workaround I downloaded the extensions and their dependencies for firmware-rpi-wifi, wifi and wireless-6.1.68-piCore from the repository http://tinycorelinux.net/14.x/armv6/tcz/ (http://tinycorelinux.net/14.x/armv6/tcz/) to a USB Flash and transferred them on to the Pi using a similar method as described in the topic: How to get wifi working on Raspberry Pi Zero 2 W ? https://forum.tinycorelinux.net/index.php/topic,26659.html (https://forum.tinycorelinux.net/index.php/topic,26659.html) and I got wifi working on a RPi0W with piCore14.
I've done some investigation and comparing the diagnostic messages dmesg from the Pi for piCore13 and piCore14, although in both cases the USB to LAN adapter is recognised correctly, piCore13 dmesg has the two lines:
[ 6.639085] cdc_ether 1-1.1:2.0 eth0: register 'cdc_ether' at usb-20980000.usb-1.1, CDC Ethernet Device, 00:e0:4b:36:2d:b3
[ 6.639416] usbcore: registered new interface driver cdc_ether
These lines are missing in piCore14.
Listing the loaded kernel modules with lsmod for piCore13 and piCore14 shows cdc_ether present for piCore13.
tc@box:~$ lsmod
Module Size Used by Not tainted
squashfs 40960 3
cdc_ether 16384 0
raspberrypi_hwmon 16384 0
zram 24576 1
zsmalloc 28672 1 zram
But not for piCore14.
An old post https://forum.tinycorelinux.net/index.php/topic,20082.html (https://forum.tinycorelinux.net/index.php/topic,20082.html) Topic: Pi Zero usb LAN adapter, suggested installing the module net-usb-KERNEL-piCore. This is a single extension with no dependencies so I manually copied the two files net-usb-6.1.68-piCore.tcz and net-usb-6.1.68-piCore.tcz.md5.txt to RPi0w with piCore14's uSD storage partition extensions folder /mnt/mmcblk0p2/tce/optional and added the line net-usb-6.1.68-piCore.tcz to the onboot list file /mnt/mmcblk0p2/tce/onboot.lst
It worked, cdc_ether is back. The Pi connects to the router and I can SSH my way in and tce download and install wifi. This is much easier than the first method of manually downloading and copying over twenty files to the Pi. Still not ideal though.
I know piCore is a minimal operating system which you customise by installing extensions but expecting users to manually download extensions and copy them to a pi is expecting a bit much, especially for beginners. There are plenty of pitfalls and I'm sure I fell down them all.
A plea to the hard working experts who maintain piCore: Earlier versions of piCore supported cdc_ether for USB-LAN adapter connectivity, is there any possibility it could be re-introduced for the benefit of Raspberry Pi Zero W users? Many thanks.
-
@KeithA: Thanks for reaching out!
Speaking from personal experience with the RasPi line, I found a solution quite some time ago which may help you with your projects.
Note: This is a one-time necessity for each major release of piCore, though you may wish to tweak it to your needs before calling it complete.
This is being posted in hopes to assist those in similar situations with piCore as it solves a good deal of issues under one roof.
Think of this as the "Universal piCore Boot Image" for RasPi 4, 3, 2, 1, Zero and Zero-2
From your regular PC (or laptop!):
- Download piCore 14's zip file and extract the picore#.img file
- Using your preferred method, "install" the image file onto a USB stick, SD card, etc. that you can erase without worrying about what's on it
- Once installed, open the device on your PC and COPY all of the files from that FAT32 partition onto your computer into a directory called piCore14 (you can erase the USB/SD - it served it's purpose.)
- Replace the config.txt in your PC's directory with the one provided below
- Replace the cmdline.txt with the one provided below
- Create COPIES of the new cmdline.txt naming them cmdline_pi0.txt, cmdline_pi02.txt (for the Pi Zero 2W), cmdline_pi1.txt and so on up to pi4, they're all listed in config.txt, one for each RasPi hardware device. RasPi5 is not supported in this image.
- Create an empty text file here and rename it to bootmmc.sh
- In your PC's directory where cmdline###.txt and config.txt files are, create a new directory called tce. Inside that, create another one called optional.
- Download firmware and support files from the piCore repository (http://repo.tinycorelinux.net/14.x/armv7/tcz/) and place them inside /tce/optional/
cmdline.txt
zswap.compressor=lz4 zswap.zpool=z3fold console=tty1 root=/dev/ram0 rootwait quiet nortc loglevel=3 noembed tce=LABEL=piCore14* What ever you format/name the SD card must match to what's listed here as tce=LABEL=piCore14
config.txt
# For more options and information see
# http://www.raspberrypi.org/documentation/configuration/config-txt.md
# Some settings may impact device functionality. See link above for details
#
# For Device-tree overlays, please reference overlays/README on the boot partition.
#
[PI0]
initramfs rootfs-piCore-14.1.gz,modules-6.1.68-piCore.gz followkernel
kernel kernel6168.img
cmdline=cmdline_pi0.txt
[PI02]
initramfs rootfs-piCore-14.1.gz,modules-6.1.68-piCore-v7.gz followkernel
kernel kernel6168v7.img
cmdline=cmdline_pi02.txt
[PI1]
initramfs rootfs-piCore-14.1.gz,modules-6.1.68-piCore.gz followkernel
kernel kernel6168.img
cmdline=cmdline_pi1.txt
[PI2]
initramfs rootfs-piCore-14.1.gz,modules-6.1.68-piCore-v7.gz followkernel
kernel kernel6168v7.img
cmdline=cmdline_pi2.txt
[PI3]
initramfs rootfs-piCore-14.1.gz,modules-6.1.68-piCore-v7.gz followkernel
kernel kernel6168v7.img
cmdline=cmdline_pi3.txt
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
#dtoverlay=vc4-kms-v3d
[PI4]
initramfs rootfs-piCore-14.1.gz,modules-6.1.68-piCore-v7l.gz followkernel
kernel kernel6168v7l.img
cmdline=cmdline_pi4.txt
# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1
dtoverlay=vc4-kms-v3d-pi4
max_framebuffers=2
[ALL]
# Run as fast as firmware / board allows
arm_boost=1
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
#dtoverlay=vc4-fkms-v3d
Finally, wipe out your intended Micro-SD card and create a single, primary partition on it (say 512MB for a little extra elbow room) and format it FAT32 with a name/label of piCore14 Once formatted, simply COPY your files from this directory on your PC onto the newly formatted SD partition and properly eject the SD card to ensure it writes and releases from the PC.
Boot the SD card from your RasPi. Type in the following command to check it:
readlink /etc/sysconfig/tcedirIf it returns /mnt/mmcblk0p1/tce we're in business. If it returns /tmp/tce something went wrong above.
Edit /opt/bootsync.sh and bootlocal.sh to create a "universal" start-up that does everything you want it to do whether it's fired up on a Pi4 or a PiZero. Disregard the USB WiFi for the moment as this is specific to a single device, not "all" of them. In addition, inside bootlocal.sh right after the # line that says to add things "here" add the following lines as being the first thing(s) bootlocal.sh does:
mount /mnt/mmcblk0p1 >/dev/null 2>&1
. /mnt/mmcblk0p1/bootmmc.sh
Entering filetool.sh -b should back up changes you've made to bootlocal.sh and/or bootsync.sh onto the SD card.
sudo poweroff when you're done tweaking and have backed up the system for ALL RasPi types of devices. Eject the SD card and put it back into your PC.
COPY the files from the SD card's partition back into your existing PC directory, overwrite everything when prompted and then set that directory aside. Again, you can wipe the SD card as it has served its purpose. Your PC/laptop now contains everything you need for any of the supported devices. Simply follow the creation instructions below:
- Insert an appropriate SD card into your PC
- Remove all SD partitions, create a single partition >128MB
- Format the partition FAT32 and label it to match the cmdline###.txt tce=LABEL=something
- COPY the contents from your PC to the SD card
- EDIT the config/cmdline files if necessary to accommodate your needs
- EDIT the bootmmc.sh file to execute start-up needs (see below)
- EJECT the SD and insert/boot your RasPi with it
Now, for your USB WiFi needs... Create an SD card as described above.
EDIT the SD card's bootmmc.sh file from your PC OR the Pi -- up to you, and add
su -c "tce-load -i net-usb-KERNEL.tcz" tc
Hope this helps!
-
In regards to whether or not include usb-net-KERNEL there's a level of inconvenience if we do, or if we don't.
A) If we INCLUDE drivers specific to a given hardware layout, everyone who does NOT have that layout would have to recompile the kernel in order to rid themselves of all the unnecessary content; and those percentages are pretty large.
B) If we do NOT INCLUDE hardware-specific drivers (like the many, many USB devices on the market) it may in fact be a pain for some users who rely on those devices to get online in order to download drivers (etc.) but we can't predict how each user is going to put their devices to work.
NOTE: You CAN, however, build your own customized kernel with what ever drivers you wish to have as part of it and alleviate the need for driver extensions completely - with the understanding of A/B above. It's not all that difficult to do, but does take quite a while to compile on a Pi.
The main goal is to include the required basics (in this case, all of the hardware devices that come built into the RasPi 0,1,2,3,4,0-2 and I think the 400/SOM series are in there as well. (For example, we have a couple USB Ethernet dongles we use while flashing RasPi-Zero boards... the drivers aren't built in because the other hundred or so images we used throughout the year don't have need for it and would otherwise just add bloat to the kernel.)
-
My usb Ethernet modules do not use that module, so moving that one module to the initrd is not going to help everyone. If you plug in a usb Ethernet device, you need the net-usb modules package.
-
Hi CentralWare, Thanks for your prompt and very detailed response.
I agree with you absolutely that piCore should avoid creeping bloat. I usually use piCore in copy mode to provide uSD card resilience and regard ram, especially the miserly 512 MB on the Raspberry Pi Zero W, as a valuable resource not to be squandered.
However, I think there are two considerations to be made in this case.
The first is that given a Raspberry Pi Zero W and piCore14 there is no way of accessing the piCore repository over the internet without "cheating"
and many users will be put off using piCore by this inability to plug and play.
The second is that I'm not asking for anything new. I'm asking for a feature that was present in piCore13 and dropped in piCore14 to be re-introduced.
Incidentally, Raspberry Pi Zero 2W and piCore64-14 will connect to my router through a USB to LAN adapter. No problem there
Many thanks for your help.
-
True, piCore 13.1 (Only 32 bit) did have a few net-usb drivers added to the initrd, however it was not a complete set. And like I mentioned previously, it did not support any of my USB based network devices. So when I packaged piCore14, I packaged it the same way I have been doing the 64bit version....putting all usb network drivers in an extension.
I remember the early piCore versions, when including ssh by default was a big conversation.
As for piCore64 working. If you have a network device that uses the similar chipsets to what raspberry pi puts on their boards, then you just get lucky, since they build ethernet support for their chips in the kernel. I use Raspberry pi configs and package everything the same way.
Where to draw the line in what we put on the image.
-
As for piCore64 working. If you have a network device that uses the similar chipsets to what raspberry pi puts on their boards, then you just get lucky, since they build ethernet support for their chips in the kernel. I use Raspberry pi configs and package everything the same way.
@KeithA: The instruction sheet I sent earlier was to create a universal image that can be used for virtually any flavor of RasPi (except Pi5 - which is being treated as a completely different monster for the moment) the problem is, you're asking for all of the USB network drivers out there to be included in the universal piCore release... but even if that were done, you STILL would need to go online and "cheat" in order to get wifi, wireless* and wpa_supplicant downloaded to the device in order for the device to then be able to go online for itself and grab anything else it may need.
@Paul_123: Keith brings up a good point for the Pi-0, Pi-0W, Pi0-2 (which have no NIC) and the bigger Pi3/4 which have NICs, but not necessarily users who have a router/switch/hub nearby whereas there's a reasonably simple method we could support NICs/WiFi without touching the existing boot image. (Take the typical USB ether/wifi drivers, wifi*, wireless* and wpa* extensions and CPIO them into an add-on image which can be downloaded onto the SD card via Linux OR Windows (since it's FAT/32) and can be added to the RasPi config in the same manner.) We may not have a fool-proof image for every single USB or HAT based Ethernet or Wireless device on the planet, but in theory, it should cover the majority!) Even if this were just the means to get the device "online" so the end-user can tweak it to their needs and remove it later, it does seem, to me, like a worthwhile venture.
@Rich, @bmarkus, @Paul_123:
If everyone is in agreement with this concept, I still have a few things on my plate that take precedence but I can add the task for later in the month unless someone volunteers for the job. @KeithA LOL... You made this mess! You're going to help test it! :) If you're okay with that, we'll be in contact when the image and how-to instructions are available. Send me a list of the Pi devices you currently have access to and I'll have someone here put a bench together with the remainder. Again, we're aiming at Zero through 4 for the time being; not Pi5. We no longer have a RasPi "One" in-house; testing for that far back will have to rely on anyone who still does.
NOTE: This process is purely theoretical; the outcome should be a success but promises cannot be made until it is a reality.
-
Hi CentralWare
... (Take the typical USB ether/wifi drivers, wifi*, wireless* and wpa* extensions and CPIO them into an add-on image which can be downloaded onto the SD card via Linux OR Windows (since it's FAT/32) and can be added to the RasPi config in the same manner.) ...
Just a thought, but wouldn't rolling a copy of the contents of those extensions
into an AllWireless.tcz extension accomplish the same thing?
... Even if this were just the means to get the device "online" so the end-user can tweak it to their needs and remove it later, it does seem, to me, like a worthwhile venture.
...
Then the user can download what they think they need, remove AllWireless.tcz
from onboot.lst , reboot and test. If they find they missed something, add
AllWireless.tcz back to onboot.lst , reboot, download what they need.
This way they can do everything with the apps tools instead of mounting
partition 1 and fooling with command.txt or whatever the boot config is called.
-
Hi CentralWare,
Count me in, I would be delighted to help. The Raspberry Pis I have are:
RPiZeroW v1.1
RPi(1) v1.2
RPi2 v1.1
RPi3B+
RPi4B
Since I rarely use the Raspberry Pi 1, I would be more than happy to donate it to the piCore team if it will be of use.
-
Just a thought, but wouldn't rolling a copy of the contents of those extensions into an AllWireless.tcz extension accomplish the same thing?
Friday Evening: (Before the massive back to back outages/brown-outs caused my UPS units to say "I quit!")
@Rich, the only problem with extensions via piCore on the Raspberry Pi is how to GET the extension ONTO the device - on CERTAIN devices especially.
Hardware specs:
With Pi-4 down to Pi-1 there's an Ethernet port which some users can put to use in order to get things moving forward if they know how to wire in.
For the Pi-Zero-W and Pi-Zero-2, WiFi and BT are the only built in modes of connectivity. Pi-3 and Pi-4 are happy campers... they can go either direction.
Pi 1 and 2 are Ether only. For the Pi-Zero... without the "W" (for wireless) you're without connectivity completely unless you OTG a USB Ethernet or WiFi.
For ALL of the listed units, USB dongles are optional in one fashion or another. NONE with WiFi support WiFi with the initial cpio.
piCore specs:
The piCore image consists of a primary FAT/32 partition and a second, tiny EXT partition (which is expanded later to what ever the max SD card size is -- makes fdisk-ing "automated" for the user.) The FAT partition contains only the necessary files and overlays to act as a hardware boot-loader, a config file which take place of BIOS settings and a cmdline file which steps in for syslinux/grub settings. Being a FAT partition, permissions are "very limited" at best so there's no resemblance of /opt (for bootsync/local), there's no tce directory (so nowhere to PUT AllWireless.tcz if we wanted to) and the only hopeful if we HAD to follow that path is the not-fool-proof "auto search for a tce folder on any block device" in tc-config BUT requires a more intimate knowledge by the user of how to manually set up tce/optional, tce/ondemand and tce/onboot.lst from outside world (ie: PC/laptop) AND becomes an obstacle for if/when the second partition is resized - with the intention of eventually becoming the "real" tce.
UPDATE: It's now Saturday morning and to quote the movie Hook
Smee: I've just had an apostrophe.
Captain Hook: I think you mean an epiphany.
Smee: No... lightning has just struck my brain.
Captain Hook: Well, that must hurt.
What about "Best of Both Worlds?"
We update our piCore DISK image to contain both the normal picore-##.gz cpio, our wireless.gz add-on cpio, the kernel and the normal Pi-Only stuff.
We're now adding ###MB of bloat to a user who does NOT need wirless, BUT, to rid ourselves of that bloat, there's two reasonably simple steps:
- Remove wireless.gz from config.txt in the FAT partition.
- Delete the file wireless.gz from the FAT partition.
ALL of which can be done before the SD card is even placed into the RasPi device.
Additionally, this technically COULD be somewhat automated - say, in tc-config we if [ $RASPI == "Pi-2" ]; then ASK TO DELETE THESE CHANGES; fiLOL - sorry, intended for point, not actual verbiage.
For Pi-1 through Pi-4 we can launch piNoWiFi.sh which asks them if they want to remove the wireless extension, per-se' and we only pester once after the initial setup.
For everyone else, it's likely a vital component save for Pi-Zero (non-wireless) who more times than not these days get used for non-networking purposes in the first place, so an easy launch manually of piNoWiFi.sh tends to this, too. Or so says my Apostrophe! :)
Thoughts and suggestions requested!
-
Hi CentralWare
In Tinycore there's a Core and a CorePlus. Why not just
simplify the process and make a piCorePlus that includes the
wireless extensions. Users that need the help can then download
piCorePlus and those that don't can download piCore. The
piCorePlus users can then delete the extensions they don't need.
No custom cpios and no custom extensions that way.
-
@Rich: Being that piCore currently comes in four flavors (three of which are really viable) we would technically be doubling this -- not that this isn't the solution in the end.
Think of the differences between x86 and x86_64 - each has its own core, coreplus, etc.
With Raspberry, it's very similar: armv6, armv7, (armv7l) and now aarch64, all home to picore-####.zip (containing an .img file to burn onto SD as described previously.)
I'm sorry to say that I'm not entirely certain as to who is in charge of the piCore releases these days (bmarkus, Paul_123, etc.) so their input would be ideal as I cannot predict how much of a pain it would be to double that work-load.
ASSUMING arm 6, 7 and aarch cannot share the same wireless drivers, three cpio modules would be required (where I think 7L would function on the same arm7 drivers, but I'd have to confirm.) As such, the same should be said about creating entire releases for each - I just cannot confirm how much effort this would entail. It may be as simple as extracting the existing .IMG file, adding the contents of the mentioned extensions and re-packaging the image with a new file name.
-
The 32bit images require 3 different kernels/modules. That’s why I separated the modules initrd from the rest of initrd, to avoid too much duplication. To add WiFi or net usb, requires all 3 variants of each extension. Plus you need to add all of the network firmware packages.
It’s very easy to do, but adds a lot to the image.
-
Hi Paul_123
... It’s very easy to do, but adds a lot to the image.
It did the same for x86:
Core-14.0.iso 12-Apr-2023 13:12 17870848
CorePlus-14.0.iso 12-Apr-2023 13:12 260046848But it provided those without a wired connection another option.
@Rich: Being that piCore currently comes in four flavors (three of which are really viable) we would technically be doubling this -- not that this isn't the solution in the end ...
Yes, but armv6, armv7, and armv7l repos all use the same piCore-14.1.0.zip file.
-
Yes, but armv6, armv7, and armv7l repos all use the same piCore-14.1.0.zip file.
Sorry, I was trying to word things so that it was easier to visualize the comparative between piCore and TinyCore. ALL of the different kernels and cpios are inside the zip/img for Pi-0 through Pi-4.
@Paul_123, how challenging would this be in aarch64? (Sorry to say I haven't even opened it yet; too much still on the plate before unboxing the Pi-5.)
-
@Paul_123: I'm heading into the shop this afternoon and grabbing some test boxes (Pi-0W, Pi-2, Pi-3 and Pi-4) to start a Pi bench at home; this has turned into something "...I just have to do/see for myself..." as my notes are not matching the config/cmdline in 14.x armv# for piCore (zswap changes, for example, that have taken place in the last couple releases which I'm guessing thanks to COVID/Silicon issues, I just haven't kept up with as we don't usually bench projects to use RasPi BCM27xx units anymore unless someone specifically insists.)
- If you don't mind, please send along a copy of your arm6/7/7l 14x.6.1.25 build script(s)
- release/src : safe to assume busybox for armv7l is exact as armv7 ?
- If the notes/scripts don't mention it, a link to our specific overlays/firm/boot used, please.
- Just for grins, please repeat the above for aarch64; I'll grab a Pi-5 while I'm at it*
* We have modular cases we print for the RasPi bench units -- Pi-5 hasn't been fitted for it's Tux yet! :)
-
I have a switch on the wall by my bench, I just hang the boads off a short ethernet cable.
32 bit (* means it is a 64 bit processor running in 32 bit mode)
- armv6 kernel = Pi models A,B,A+,B+,Zero, ZeroW, CM
- armv7 kernel = Pi models 2B, 2Bv1.2*, 3B*, 3A+*, 3B+*, Zero2W*, CM2, CM3*
- armv7l kernel = Pi model 4B*, 400*, CM4*, CM4S*, CM4io*
64 bit
- aarch64 kernel = Pi models 2Bv1.2*, 3B*, 3A+*, 3B+*, Zero2W*, CM3, 4B, 400*, CM4*, CM4S*, CM4io, 5
- aarch64_16k kernel = Pi model 5 (Experimental kernel with 16k paging, requires extensions squashed with 16k blocksize)
Notes:
- All code contained in all 32 bit initrd and repos is compiled with flags -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp.
- All code on 64 bit initrd and repos is compiled with flags -march=armv8-a+crc -mtune=cortex-a72
- Processors running in 64bit mode can run 32bit code, but we don't fully support this, as it is quite difficult to manage repo usage
- Kernel source is https://github.com/raspberrypi/linux with very few changes (kernel name and a few squashfs related patches) kernel source is uploaded the TC repo. The kernel source provides all board dtb files and overlays
- Rpi Boot Firmware comes from https://github.com/raspberrypi/firmware/tree/master/boot (bootcode.bin, fixup*, start*)
I'm not sure what hoops you are thinking of, but if we do this, we would not modify the initrd's, all we would do is add the following extensions to the image and load in onboot.lst. It adds about 12MB to the image.
- net-usb-KERNEL (all kernels, the image supports)
- wireless-KERNEL (all kernels the image supports)
- firmware-(atheros, brcmwifi, mediatek, ralinkwifi, rpi-wifi, rtlwifi, ti-connectivity)
- wpa_supplicant
- wireless_tools
- wifi
Adding wifi connection OOTB is feasible, but would require reworking the wifi.sh scripts, as it regenerates wpa_supplicant.conf from a saved file in the tc home directory. There is not provisions for a user supplied wpa_supplicant.conf.
-
If we do this, I didn't care whether or not wireless/drivers/etc. were even loaded (onboot) -- as long as they're inside the image, KeithA's issue is tended to as would those who own Zero/Zero-2 or any device at all if they're not able to wire into the router/hub/switch/etc. (It would be a simple task to add a short wiki instructing how to launch wireless on Pi-0/Pi-0-2/etc. as the resources would already be in their hands, it's then just a matter of turning everything on without having to download all of the necessary TCZs remotely and copy them onto the SD card manually... something some of these people haven't even done on their own desktop/laptop machines.)
* Kernel -- I know the git repo, but had hopes you knew which (commit) ID# 14x was built from (file dates don't correlate to a specific release and I avoid "assumption" when ever possible -- thus I'm guessing/assuming the AUG-11 commit as the file dates for TCL's kernels are only a week and a half older than that.)
The kernel source provides all board dtb files and overlays
-- thanks, this is probably what I need for the above question.
As for adding wireless to Pi images, my first suggestion was to simply create a stand-alone cpio and have it load along with modules.gz
My way of thinking (I've not personally had to build piCore completely from scratch so I may be off a bit here) was to create a single wireless.gz and theoretically (depending on what I found for arm6/7/7l compile flags) the drivers and apps for wifi "should" be a single file shared between the three different releases as the files in question "should" be the same regardless of which unit they're being used on, especially since they're compiled as kernel modules from the same kernel core. (To prove any of this I would have to build everything from the ground floor to "properly" test, thus my inquiries. I could easily cheat and just copy all the binaries (firmware) from piCore, extract and repack as needed for "wireless.gz", etc. -- just figured if I'm going to put the toes in the water, might as well jump in!? :) )
From what you said in your notes, though, there's a chance the Pi-4 would possibly need a separate wireless.gz built IF the modules were affected by the -march difference. Maybe.
Regardless, Thanks again and take care!
~TJ~
-
I find the hurdles to start are.
1) Only other machine is Windows based
2) No keyboard/monitor
3) No ethernet adapter
From what you said in your notes, though, there's a chance the Pi-4 would possibly need a separate wireless.gz built IF the modules were affected by the -march difference. Maybe.
All Kernel modules are kernel specific. You cannot use 6.1.25-piCore-v7 on a pi4.