<gnarface>
apritzel: the debian one i think, lemme verify
<apritzel>
I see the kernel loading that, but then get: SIOCSIFFLAGS: Operation not permitted
<gnarface>
hmm, what's that mean?
<apritzel>
and wlan0 stays down
<gnarface>
oh, odd
<gnarface>
it works for me here
<gnarface>
i have two of them in fact
<gnarface>
i am using the packaged one, maybe not important but i note that it's actually just a symlink to rtl8723bu_nic.bin
<apritzel>
yes, same here
<gnarface>
i did notice i needed a lot of extra power to make it actually work though
<apritzel>
I set it up on a Pine-H64, so it's the H6, which requires two regulators, and the 32K OSC fanout
<gnarface>
not all the time, but it does need to be able to pull at least about 7A from the power source at power up time for a brief few seconds, and without that the wifi device doesn't seem to initialize at all at a hardware level
<apritzel>
I mean the WiFi modules is connected to two AXP rails: CLDO2 and CLDO3
<gnarface>
i actually had to upgrade to pine64 desk powers to find something that could do it, the regular cellphone charger i'd been using before to power the board sans-wifi couldn't handle it
<apritzel>
the rtl8723 driver seems happy, I see the interface, and a MAC address
<gnarface>
but you can't "up" it? not even with a static ip?
<apritzel>
I have a 5V/4A PSU connected via the barrel plug
<gnarface>
oh, hmm. i don't think these boards even have barrel plugs
<apritzel>
whenever I try this, I see it loading the firmware, but the telling me off about "Operation not permitted"
<apritzel>
yes, the original Pine64 boards didn't, but the Pine64-LTS and later board do
<gnarface>
ah
<gnarface>
you're using the r8723bs driver from staging, right?
<apritzel>
yes
<gnarface>
it might matter but i'm still on kernel 5.18.16
<apritzel>
from 6.8-rc5
<apritzel>
(I know, that's already a week old, sorry)
<gnarface>
where are you seeing "Operation not permitted" appear?
<gnarface>
in dmesg?
<apritzel>
no, on the terminal, output by the respective userland tool, so ifconfig or ip or iw
gamiee has joined #linux-sunxi
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
<gnarface>
apritzel: hmm, what release of what distro are you using? could it be a bug in the userspace there?
<gnarface>
did you say gentoo...?
<gnarface>
not seeing anything like that here on devuan, though i'm not exactly at the bleeding edge of anything, i also didn't do anything special except cross-build a kernel from the debian source package
<gnarface>
(a necessity because devuan doesn't have a kernel for this device and at the time debian wasn't shipping a working on either)
<apritzel>
I am on Debian 12
<gnarface>
working one*
<gnarface>
is 12 bookworm?
<gnarface>
current stable?
<gnarface>
hmm, yes
<gnarface>
should be fine, that's weird
<gnarface>
could it be some silly snafu like something else is already reserving it somehow? like network-manager or something?
eldondev has quit [Ping timeout: 480 seconds]
<gnarface>
i've got no gui installed on mine, and the network config is just what i've typed into /etc/network/interfaces
<apritzel>
similar here, just serial console. Nothing touches the Wifi. I can try to add it into /etc/network/interfaces ...
<apritzel>
what was your bandwidth? On my Remix Mini PC (same A64 and same 8723) I seem to get about 3.2 MByte/s
chewitt has joined #linux-sunxi
jernej has quit [Ping timeout: 480 seconds]
<apritzel>
so incoming it peaks about 4MiB/s, outgoing about 5MiB/s. iw reports "tx bitrate: 72.2 MBit/s"
gamiee has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
retpolanne has joined #linux-sunxi
etpolanner has joined #linux-sunxi
gamiee has joined #linux-sunxi
jernej has joined #linux-sunxi
gamiee has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
etpolanner has quit [Ping timeout: 480 seconds]
retpolanne has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
retpolanne has joined #linux-sunxi
retpolanne has quit [Remote host closed the connection]
retpolanne has joined #linux-sunxi
etpolanner has joined #linux-sunxi
apritzel has joined #linux-sunxi
etpolanner has quit [Remote host closed the connection]
retpolanne has quit [Remote host closed the connection]
<libv>
it is amazing how much webrot there is for A10/A10s/A13 stuff
<libv>
very hard to find android images which have not dropped off the web
<libv>
yeah, i know, it has been 12ys
<libv>
but still
<libv>
pretty astounding
bauen1 has joined #linux-sunxi
<wingrime-ww>
it's also impressive how allwinner produce chips with +12ys arm cores
vagrantc has joined #linux-sunxi
<libv>
they are really milking that license
<libv>
on the other hand, the a20 would still be useful today for the fosdem video box, anything that requires just FullHD and nothing more
<libv>
gotta love archive.org, the only way i can still find some ancient images
<wingrime-ww>
video decoder on more recent ic's can easly handle 4k video, still beeing painfully slow to handle modern android
<libv>
i know, but the amount of work needed to get the whole stack to where it works together is pretty prohibitive
<apritzel>
wingrime-ww: Allwinner seems to aim at a market where they basically need Linux for TCP and WiFi, and the Arm cores are more or less DMA controllers for an ISP, NPU, or video codec
<libv>
i burned 1.5 man years on the fosdem video box already
<libv>
with the a20 being as well supported as it was in 2019
<wingrime-ww>
it would be nice get same level of support on A523, but it need atleast BSP for reference
<libv>
between finding nonsense in the kms support, only found by my usecases apparently, the 24bit rgb capture over csi2, g2d/mixer support for planar rgb to nv12 conversion, and the h264
<libv>
and then random board bringup stuff
<wingrime-ww>
apritzel: that niche on esp32 that does not need linux for that
<libv>
if i would have to do it all over again, i would forgo allwinner altogether and probably go for rockchip rk5388
<libv>
no dicking around with an external hdmi decoder for a start
<wingrime-ww>
rockchip atleast have decent performance cores
<apritzel>
wingrime-ww: I am pretty optimistic we can get a decent support level on the A523, but it needs people contributing to mainline
<apritzel>
that seems to be a problem lately, and is also a difference compared to the A20 times
<wingrime-ww>
I also don't expect aw changed much in A523
<apritzel>
wingrime-ww: in what respect? Do you mean the peripherals changed? Or the kind of software support?
<apritzel>
Their upstream support is as non-existent as back in the days, but I found that the BSP quality improved much lately. The A523 code I have seen is pretty usable, actually.
<wingrime-ww>
apritzel: allwinner don't change anything in hw side without good reason to do this
<apritzel>
if only they wouldn't have slapped a GPL3 license header in front of the clock driver :-(
<apritzel>
wingrime-ww: over the past few years we figured that AW loves to changes tiny little things that just break compatibility, and that are a major nuisance in upstreaming
<apritzel>
examples for the H616 for instance are the USB PHY f**kup, the thermal device needing some random bit cleared in some unrelated register, or the Mali GPU needing another bit cleared in the PRCM block
apritzel_ has joined #linux-sunxi
<wingrime-ww>
I wonder why don't they see profit to have good malinline software stack, there is many ic on market but good software is primary show stopper
<apritzel>
all those things needed major pull-ups to integrate properly in the mainline kernel, and took a lot of time to upstream
<apritzel>
I think they primarily sell Android, and (at least so far) got away with just hacking stuff into their BSP as if there would be no tomorrow
wasutton- has quit [Ping timeout: 480 seconds]
wasutton3 has joined #linux-sunxi
wasutton3 has quit [Ping timeout: 480 seconds]
KREYREN_ is now known as KREYREN_oftc
KREYREN_oftc has quit [Quit: Leaving]
KREYREN_oftc has joined #linux-sunxi
retpolanne has joined #linux-sunxi
apritzel_ has quit [Ping timeout: 480 seconds]
hramrach has quit [Remote host closed the connection]
evgeny_boger has quit [Remote host closed the connection]
<gnarface>
apritzel: sorry, you were already disconnected yesterday by the time i saw that message. i see similar peaks for tx bitrate but it maxes at 2MiB actual throughput
<gnarface>
apritzel: what do you see in your dmesg for the SD speed rating?
<gnarface>
still "high speed?"
<apritzel>
gnarface: yes, I also tried adding the uhs properties, and saw them being parsed correctly (caps was reading 0xc19cf or so)
<gnarface>
so, i'm told we should be reliably getting at least 6MiB out of this
<apritzel>
I need to deep dive into the MMC spec to find the part where the device tells what it support, but I am pretty sure at this point that it's High Speed only
<apritzel>
gnarface: are you using ssh/scp? Or anything involving serious crypto? I figured sometimes that this limits throughput. I used netcat for testing
<apritzel>
the max 5MB/s were just in a non-ideal spot, WiFi-wise. I can check how it looks like when being closer to the router
<gnarface>
apritzel: heh, no i'm well aware of the cpu bottleneck imposed on scp. i tested with netcat and Steam, which are two of the things that can most reliably max out other routing points at other places in my LAN
<gnarface>
apritzel: and i tested this within 4 feet of the router in direct line-of-sight
<gnarface>
(for Steam i tested both Remote Play and just regular patch downloading)
<gnarface>
Steam managed to push 2MiB through it almost reliably. netcat was actaully only coming in at like 1.6 average
<gnarface>
Steam needed 3MiB minimum to establish a reliable stream though, and it shows when it's not getting that
<gnarface>
so, maybe something is wrong with the driver then i guess and this is all a red herring though. based on the tip i was given about SD speeds i was sure this was it, but it seems like i was mislead about the ratings being in MB instead of Mb
<gnarface>
when i thought that "high speed" was 25 megabits not megabytes , the fact i was getting 20 megabits from the wifi with occasional bursts to 25 megabits seemed like a conspicuous correlation
<gnarface>
... especially since the "iw dev wlan0 station dump" on both ends was telling me tx speeds in the high 50's to low 70's, and rx was showing mid 40's to low 50's
<apritzel>
so I got definitely almost 40 Mbit/s out of it, which I consider not too bad, given the radio link speed of 72, the bad location of the device, and the poor quality of the chip and antenna in general
<gnarface>
hmm, yea if i could get 40 that would be plenty for my purposes
<gnarface>
are you just using the stock antenna?
<gnarface>
the little wire?
<gnarface>
maybe i should try a newer kernel
<apritzel>
but all of this was on some other device (Remix Mini PC), though the same WiFi chip and also an A64, so platform-wise very similar
<apritzel>
I will try to replicate this setup on the Pine64 board later
<gnarface>
alright, thanks for looking into this
<gnarface>
i wonder if hostapd could be slowing it down, or something to do with spectrum crowding from other routers in the building....
<apritzel>
palmer: the FEL protocol is (presumably) the same, and the D1 shares the SoC ID with the T113-s3
<apritzel>
so on that level the chip looks like a supported one
<apritzel>
only that for loading U-Boot we require some code to be uploaded and executed, to save the BROM stacks from getting overwritten
<apritzel>
at the moment we only have ARM code in sunxi-fel, to upload and handle the save/restore
<apritzel>
so someone needs to refactor sunxi-fel to support multiple architectures, then plug in the respective RISC-V code
<palmer>
ya, IIUC those two are sort of the same chip -- at least at some level
<palmer>
and sounds like sunxi-fel definately wouldn't support the D1, then
<apritzel>
we had some stab at this multi-arch refactor, to support some older chip with ARMv5
<apritzel>
but it turned out we can go with ARMv5 for all SoCs, so we didn't need it back then
<palmer>
makes sense
<apritzel>
I actually have some branch called "notonlyarm" ;-)
<palmer>
;)
<palmer>
just poking around quickly it looks like there's a few Arm routines that'd need to change, but IDK if there's something deeper
<palmer>
also not really sure it's worth it, at least just for the D1. That's kind of a wacky chip
<apritzel>
some routines are rather easy, to dump registers for instance
<apritzel>
the whole BROM stack save/restore is quite some involved dance, though
<apritzel>
and required some code on the U-Boot side as well
<apritzel>
dunno if smaeul had some patches for that
<apritzel>
and yeah, wacky and sad little lonely fella
<palmer>
;)
<retpolanne>
will test xfel, thanks :)
* apritzel
still can't believe they did a single core only
<palmer>
I assume it was just some sort of experiment? The RISC-V side is really odd, it's got Arm bits floating around
<apritzel>
yes, it feels like the wanted to just be part of the RISC-V party, which admittedly worked out to some degree, in some areas the chip is quite popular, it seems?
<palmer>
for a while it was pretty much the only chip around
<palmer>
and ya, I guess it worked well enough ;)
<apritzel>
retpolanne: oh, one thing, I think xfel does not support loading mainline U-Boot. At least not in the same way as sunxi-fel
<apritzel>
but I think you can init the DRAM with a command, then upload SBI and U-Boot proper and execute?
<apritzel>
(just don't ask me how)
<retpolanne>
i completely forgot about SBI, thanks
warpme has quit []
Jookia has quit [Remote host closed the connection]