paul- wrote:
> You cannot do this.
>
> >
Code:
> >
> pcp_make_module_extension -k 5.10-42-pcpTEST -e 88XXauTEST
>
> >
>
> The kernel name that you use in the build scripts, must match the name
> of the kernel shown when you run `uname -r` i
paul- wrote:
> Im not following, because -KERNEL is precisely what should be in
> onboot. The word KERNEL gets replaced in the extension loader by the
> running kernel name.
I'm missing something here, because my 8.0.0 system did not load the
extension until after I changed onboot from 88XX-
Braklet wrote:
>
> Problem: I fumble-fingered my onboot.lst entry, so it couldn't read my
> new WiFi driver extension. Chalk this up to pilot error, duh.
Don't know how much of my own ignorance I want to put on display, but I
have a related script change request
Restarted with my 8.0.0 SD, monitor and KB.
The extension loading phase was MUCH faster than with my 7.0.1 SD,
leading me to believe something critical is not loading.
Console output reflects my migrated 7.0.1 configuration in 8.0.0. The
system thinks it enables WiFi and wlan0. Console keeps
paul- wrote:
>
> Did you make this change to the driver source when you downloaded it?
> https://github.com/aircrack-ng/rtl8812au#for-raspberry-rpi
I followed your README here https://github.com/piCorePlayer/pCP-Kernels
The result is the same: all Makefile CONFIG_PLATFORM* options are n
exce
I rebuilt my wireless driver extension on my pCP 7 system, installed and
rebooted back into pCP 7. Here are the associated directories for both
7 and 8 kernels:
Code:
tc@piCorePorch:/$ sudo find / -name "*pcpCore*" -type d -print
/lib/modules/5.10.42-pcpCore
/lib/m
Braklet wrote:
>
> I expected to find a 8812au driver module in /lib/modules, but did not.
> Is 8812au built into the pCP kernel?
>
Expanded my search, and found the associated driver module:
/usr/local/lib/modules/5.4.83-pcpCore/kernel/drivers/net/wireless/realtek/rtl8812au
/u
Here is the specific USB WiFi dongle model I use:
https://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/au/wireless_adapters_ac600_dual-band/ew-7811utc
I fired up my pCP 7, the dongle works great. Here's some driver-related
stuff:
dmesg:
[4.652782] usb 1-1.3: new high-s
paul- wrote:
>
> lsmod
>
> and then run dmesg, and look towards the end, there should be a section
> that shows the detection of the wifi chipeset. Need to see the USB
> identifiers. :
Thanks for the response, sorry for the delay. (My pCP is remote and not
always accessible.)
Di
Braklet wrote:
>
> Do you think it's worth rebuilding my extension using "-e 88XXau" ?
I tried it, no change. No LED activity from the WiFi USB dongle.
Have to ponder my next course of action.
Br
paul-1, is the extension name critical in loading? I used "88XX" as my
extension name, and got these extensions as a result:
88XX-5.10.42-pcpCore.tcz
88XX-5.10.42-pcpCore.tcz.md5.txt
But the actual driver name is "88XXau.ko" in the contents:
D:\Devices\Raspberry
Pi\piCorePorch-Images\PCP-8812
Sadly, my wireless drivers didn't work after the 8.0.0 upgrade. The
LEDs on my pCP Pi B+ showed CPU activity, but the WiFi dongle never
recovered any LED activity, indicating no drivers.
I'm pulling an SD image now, in case I want to debug further. I will
restore the 7.0.1 image I took a coupl
paul- wrote:
>
> Then obviously move it to the proper location.
Hi paul-1, your instructions worked a treat. Here's what I now have in
/mnt/mmcblk0p2/tce/optional:
Code:
tc@piCorePorch:/mnt/mmcblk0p2/tce/optional$ ls -al 88*
-rw-r--r--1 tc staff 95
paul- wrote:
> The wifi driver does indeed take forever to compile on a piZero. Anyway
> I found the problem
>
I will give this a go tomorrow. Thanks very much, paul! I do
appreciate your help with this, pCP allows me to maintain my now
decades-old LMS ecosystem.
-
And if it isn't obvious, THANK YOU for all the work you have put into
pCP, and dealing with all this stuff. Probably time for another project
contribution...
Braklet's Profile: http://forums.slimdevices.com/member.php?use
paul- wrote:
> I'm concerned about the error. It seems part of the install script from
> the source package did not pickup the new kernel name, and used the
> running kernel name. The extension may have no contents. However the
> compiled driver should still be sitting on the persistent disk.
paul- wrote:
> Rebooting is fine, since you are on 7.0.1. The new kernel drivers
> would not be used anyway. I'm concerned about the error. It seems part
> of the install script from the source package did not pickup the new
> kernel name, and used the running kernel name. The extension ma
I rebooted back into 7.0.1 with my new driver in onboot.lst, and
wireless came back up. (This is a headless system, wifi only.)
I will probably shut it down, take a SD card image, and then attempt a
8.0.0 in-situ upgrade.
But I am still very interested in swapping to in-tree USB WLAN hardware,
paul- wrote:
> If you have an x86_64 ubuntu system, you could also cross compile the
> driver. I use a x86_64 system to compile all of the pCP kernels.
I have set up cross-compile environments for OpenWrt and work with Yocto
and buildroot occasionally, so I'm not completely clueless there. B
Editing the quote...
paul- wrote:
> there is a chance you are running low of ram.
> You can look at the drivers in the extension wireless-KERNEL.tcz and see
> the list of drivers.
> What are your wifi specs? I don't have a good feel of the AC and AX
> chipsets that work. (Since I use the
I have dealt with the vagaries of Ralink and Realtek chipsets for many
years now, so I endorse the decision to remove problematic drivers from
the piCorePlayer distribution.
However, this puts me in a quandry. I'm happily running pCP 7.0.1 on a
RPi B+ with a Realtek-based USB dongle using the 8
jeroen2 wrote:
>
> >
Code:
> > #!/bin/sh
> #things to do at startup
> /usr/local/bin/irexec /home/tc/.lircrc &
>
> >
On a whim, I followed @jeroen2's suggestion:
* Commented out my /home/tc/.profile invocation of "/usr/local/bin
irexec -d
jeroen2 wrote:
> When I tried that it seemed to have an issue with finding the lircrc
> file. Since I already had a startup .sh script, I added it there with
> the lircrc path:
> >
Code:
> > /usr/local/bin/irexec /home/tc/.lircrc &
>
> >
Wonder
paul- wrote:
> The url encoding is correct, it gets decoded at run time, it's the best
> way to preserve spaces and such.
>
> I'll have to see what is so special about irexec as to why it doesn't
> want to run from a shell script.
OK, I can see how the encoding would help, it just wasn't clear
paul- wrote:
> Some processes may not like being backgrounded and then trying to
> daemonize. You likely don't need to use the "-d". Or you can just put
> what you want in a script, then put the script name in user commands.
Removing the "-d" daemonize option from the USER_COMMAND irexec
inv
OK, I managed to get irexec running daemonized at boot. To do so, I had
to add it to /home/tc/.profile (excerpt):
Code:
if [ -f "$HOME/.ashrc" ]; then
export ENV="$HOME/.ashrc"
. "$HOME/.ashrc"
fi
# Can't start irexec from Tweaks->User Command, try it here
On a tip from
https://www.brianlinkletter.com/persistent-configuration-changes-in-tinycore-linux/,
I manually edited /usr/local/etc/pcp/pcp.cfg and removed the
percent-encoding from USER_COMMAND_1:
USER_COMMAND_1="/usr/local/bin/irexec -d"
I then made this configuration persistent:
sudo fileto
Per Ralphy's suggestion, I found that running irexec daemonized allows
me to invoke custom scripts via IR remote. I added irexec to
Tweaks->User commands, but irexec never survives reboot:
30907
I find nothing in Main->Diagnostics indicating that it started. Irexec
invocation is in pcp.cfg, p
28 matches
Mail list logo
