<minimal>
stintel: so the reason why setting the quality figure in the kernel module makes a difference is that yes entropy is copied from the hwrng by the kernel but it is not "credited" (as so the entropy_available value doesn't increase). Setting the quality value above 0 means it will be credited (and so on older kernels stop things blocking)
<stintel>
ok
<stintel>
neggles: probably not dts related my oc200 problem :/
<neggles>
stintel: dang
<stintel>
and I'm not even sure what I was running before I upgraded
<stintel>
ah, found it in prometheus, 5.10.92
<stintel>
so at least I know it was on 5.10 already
<neggles>
should I rebase and see if mine also breaks?
<stintel>
your paste showed 5.10.107 already - was this a different device maybe?
<neggles>
hmm, so i'm on 5.10.107, we're at .109 now
<neggles>
that log is from my oc200
<stintel>
ah, yeah if you don't mind testing / potentially breaking it?
<neggles>
bridging the missing 0R resistors was not super fun :P
<stintel>
oh I hate this hardware already
<neggles>
sure
<neggles>
yeah
<stintel>
but it beats a rpi + poe hat + case + sd card
<neggles>
I got it for 90AUD
<neggles>
a pi 3b+ isn't much cheaper
<neggles>
it is *maddening* that it's only got a 100mbps switch in it :(
<stintel>
100Mbps is plenty for my use of the thing
<neggles>
yeah not a problem for many use cases, and i'm sure it was just cost-cutting but it *feels* like they did it to discourage repurposing the thing :P
<rsalvaterra>
Try as we might to choose sane defaults (and they do become saner after that commit), choosing the size of the conntrack hash table will always have to be an administrative decision.
KGB-1 has quit [Server closed connection]
KGB-1 has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
cbeznea has joined #openwrt-devel
cbeznea has quit []
cbeznea has joined #openwrt-devel
Slimey has quit [Read error: Connection reset by peer]
Slimey has joined #openwrt-devel
danitool has joined #openwrt-devel
xdarklight has quit [Server closed connection]
xdarklight has joined #openwrt-devel
<ynezz>
stintel: you should use UUIDs, not rely on device probing order
<neggles>
ynezz: there's only one eMMC though, and the 2nd SDHCI controller is disabled
<neggles>
and on my oc200 at least, u-boot won't save env vars
ekathva has joined #openwrt-devel
felix has quit []
Tapper has quit [Ping timeout: 480 seconds]
blocktrron has quit [Ping timeout: 480 seconds]
felix has joined #openwrt-devel
indy has quit [Server closed connection]
indy has joined #openwrt-devel
<hanetzer>
neggles: still around
<neggles>
hanetzer: why yes
<neggles>
yes i am
<neggles>
what forbidden Octeon knowledge do you seek
<hanetzer>
system controllers and points of similarity between the 71xx and 73xx
<neggles>
you have an ER-I/USG-XG, don't you
<hanetzer>
ubquiti edgerouter 4
<neggles>
ER-4 uses a 7130 doesn't it?
<neggles>
yes; afaik there's... *mostly* working support for the ER-4 in mainline
<hanetzer>
yeh
<neggles>
the CN70x0/71x0 and CN72x0/73x0 are similar in terms of overall architecture and drivers should be largely cross-compatible
ekathva has quit [Ping timeout: 480 seconds]
<neggles>
but, well, what's your specific Q? "how do I build something vaguely useful using this GPL tarball or info from it" ?
<stintel>
ynezz: that would require changing u-boot env, tricky on oc200
<neggles>
credit where it's due to hurricos and stintel for the octeon SDK stuff :P
<neggles>
don't talk to stintel about octeons, though. he's suffered enough.
<neggles>
:P
<neggles>
hanetzer: thing about the MIPS octeons is, they're... Special. and not really the good kind. your usual SoC has an application processor in the middle with a bunch of accelerators and IO glued to the sides over various buses (usually some kind of AXI)
<hanetzer>
right.
<neggles>
but Octeon's grandad is the NitroX line of crypto accelerators; rather than being a processor that grew accelerators, the Octeon kind of came about as an accelerator with a processor glued to the side of it.
<neggles>
as a result, the CPUs cannot do jack shit without the accelerators.
<hanetzer>
kind of how the raspi socs boot thru their gpus?
<neggles>
kind of, but, so much worse
<neggles>
they also initially were not running linux; linux was kind of added on later
<stintel>
I might take an octeon to the shooting range next time and use it as a target
blocktrron has joined #openwrt-devel
<neggles>
since they started life as programmable accelerator cards, they originally ran user-provided baremetal applications loaded over the PCIe bus from the host - using Cavium Simple Executive to manage the loading and running of said applications
<neggles>
when cavium added u-boot and linux to the mix, they pretty much just copy-pasted the baremetal cavium executive code into u-boot/linux to make it work. end result: oh god. it's. it's a huge mess.
<hanetzer>
neggles: so no 'octeon programmer's guide' in the wild that you know of?
<neggles>
check the octeon-sdk-51 repo
<neggles>
docs subdir
<neggles>
that repo needs git-lfs enabled for you to download all of it btw
ekathva has joined #openwrt-devel
<hanetzer>
never used. quickstart?
blocktrron has quit []
<neggles>
install git-lfs
<neggles>
and its uh
<neggles>
ah okay for a regular clone it should pull automagically
<neggles>
*please* do not fork that repo - if you fork it, github will charge *me* for bandwidth whenever someone clones your fork...
<hanetzer>
heh
<neggles>
jerks.
<hanetzer>
not finding anything that resembles a full datasheet for the soc
blocktrron has joined #openwrt-devel
<neggles>
you won't.
<neggles>
marvell don't hand that info out, at all, as far as I can tell.
<neggles>
sets up a docker image/environment with the octeon SDK kernel sources + toolchain in a way that works
<neggles>
i made it to build edgerouter kernel modules but it's useful for other stuff as well
<neggles>
the most detailed documentation you'll find on how it all works internally/at a register/peripheral level is buried in the kernel sources and SDK example applications
robje has quit [Server closed connection]
<neggles>
stintel: probably about the most useful thing you could do with an snic10e :P
<hanetzer>
you're aware of mainline u-boot for the octeon 73xx, and two of its boards?
robje has joined #openwrt-devel
<neggles>
yes; that support is... well frankly it's kinda broken
<neggles>
there's mainline-ish support for the Itus Shield - Grommish will show up aaaaaany second now ;) - which is a CN7030
<neggles>
but nothing about an octeon's boot process is normal. IIRC you even need one of their accelerator units up and running to get a UART out of the thing...
<neggles>
the CN7360, for example, can be found inside the EdgeRouter Infinity/USG-XG-8 (same board), where it boots from SPI flash like you'd expect, but it can also be found inside LiquidIO SmartNICs which boot over PCIe from their host
<neggles>
I don't quite remember but I think the mainline u-boot support only really covered the latter?
SamantazFox has quit [Server closed connection]
<hanetzer>
well, I lack the hw to test, but there's two boards and one seems to be the latter and the other the former
SamantazFox has joined #openwrt-devel
<neggles>
ah the EBB7304 yes
<neggles>
at last check the mainline support is still missing DDR initialization code amongst other things
<hanetzer>
primary goal in this is running 'normal' debian on it as an openwisp2 controller but apparently the usual mechanism for it won't work on these :P
<neggles>
that's what I wanted to do with this USG-XG-8, but... not really gonna happen. the octeon-ethernet driver in mainline linux is still a dumpster fire, openwrt is having weird transient memory leak issues on kernels > 5.4 which we still can't work out what the heck causes
<hanetzer>
blerg.
<neggles>
so the question becomes
<neggles>
is it worth it to you, to lose hours/days/weeks of your life to trying to make this work
<neggles>
rather than just buying something with an armada 7040/8040 or Literally Anything That Is Not A MIPS Octeon
<hanetzer>
I heh. well, I already lost hours/days/weeks of my life over hisilicon devices
<neggles>
(n.b. none of this applies to the Octeon TX2 series, and only kind of applies to Octeon TX)
<neggles>
well if you can make do with openwrt's kernel 5.4 and retaining the existing u-boot
<neggles>
getting a debian userland up and running is doable
<stintel>
neggles: since you soldered the missing components on your oc200, can I assume you didn't try my idea to patch the RSA pub key in the NOR so we can flash signed openwrt images ?
<neggles>
stintel: I did not, though i did do a full eMMC dump
<neggles>
just some random aes values inside the omada .jars, but i think it's unrelated
<hanetzer>
but yeah. if the java is what touches on the mmc, well, you can easily decrypt them for the most part.
<hanetzer>
erm. decompile.
<neggles>
they appear to get overwritten before they're used for anything
<neggles>
i thiiiiink that little bit of data on mmcblk0boot0 is encryption key it's using for securing comms to/from the controlled devices or something
<neggles>
but i found the firmware upgrade handling stuff
<hanetzer>
I did something similar with hisilicon; they had their chip parameters inside encrypted files, used an eclipse based tool to do the work, so I loaded the jar in jython and decrypted them with that :)
<hanetzer>
(chip parameters in this case being arm shellcode sent over uart to initiate their bootrom's serial-based flashing tool)
<neggles>
heh one of these .jars is not even obfuscated/minified
Tapper has joined #openwrt-devel
<hanetzer>
sucks when you misplace your usb-serial adapter :/
<stintel>
having more than one helps ;)
<neggles>
there are three different USB-UART adapters on my desk right now :P
<hanetzer>
well, I have an rj45 one, a db-9(?) one, and one with headers I can't find that I need :)
<stintel>
I need to get some USB to RJ45 ones
<neggles>
yeah, see, what'll happen next is you'll go "ugh, fine" and buy 1-2 more $3 adapters from aliexpress or similar, then it'll turn up 3 hours later :P
<stintel>
so I can leave them plugged in at all times
<hanetzer>
neggles: yerp.
<neggles>
why do they always have to use the stupid flat cisco cables for those?
<neggles>
it's infuriating
<hanetzer>
eh, I like those.
jow has quit [Server closed connection]
jow has joined #openwrt-devel
<hanetzer>
if I bust the end I can easily strip it and put a new jack on :)
<neggles>
they're big and chonky and heavy and inflexible, and you only need to do that because you can't put a boot on it to protect the tab!
<neggles>
I ended up making my own out of a USB-RS232 PCB and a 28awg patch cable
Atomicly| has joined #openwrt-devel
<hanetzer>
neggles: good point.
<neggles>
RJ45 retermination is a solved problem, too - pull-thru connectors
AtomiclyCursed has quit [Ping timeout: 480 seconds]
Atomicly| is now known as AtomiclyCursed
<neggles>
hanetzer: you're right, it's an aes container, 'private-data' gets saved in there
<neggles>
encrypted/decrypted by 'tpcrypt'
<neggles>
oh hey found the binary that checks firmware signatures. /usr/bin/rsa_check
<hanetzer>
heh. well, I do know a thing or two about a thing or two
<stintel>
soooooo I need aliases { mmc0 = ... };
<hanetzer>
easy enough
srslypascal is now known as Guest845
<neggles>
do you? i still can't get mine to come up as the wrong one
srslypascal has joined #openwrt-devel
<neggles>
story checks out though
<stintel>
neggles: I suspect we might have different u-boot versions, and that is messing things up - last night when I changed root to mmcblk1p1 then booted all of a sudden kernel detected it as mmcblk0
<neggles>
'cause if sdhci1 is disabled there shouldn't ever be an mmcblk1
<stintel>
I even tried /delete-node/ &sdhci1;
<stintel>
verified by decompiling dtb even
<neggles>
...wtf
<stintel>
anyway, let's hope the alias does its thing
Guest845 has quit [Ping timeout: 480 seconds]
<neggles>
stintel: good news, rsa_check does indeed read out the rsa pubkey from the spi flash
<hanetzer>
found it.
<neggles>
but did you buy another one first? :P
<stintel>
grrr
<stintel>
alias doesn't work
<neggles>
stintel: and there appears to be no other sanity checking, the webui dumps a summary of the firmware file to /tmp/sysinfo/tddp.json and tells rsa_check to check the signature in said json against the pubkey in flash
Atomicly| has joined #openwrt-devel
<hanetzer>
neggles: no, but I did pull up an amazon page to encourage it :)
<neggles>
i see no obvious reason why "replace the key in spi flash then upload from recovery" wouldn't work, possibly wouldn't even need to be recovery
<hanetzer>
*no reason yet*
<neggles>
well it does do some checks against a few other files on the filesystem, but they're all in tmpfs
<neggles>
(and recovery doesn't)
<hanetzer>
where it was: plugged into the usb port on the back of my pc
<neggles>
classic
AtomiclyCursed has quit [Ping timeout: 480 seconds]
Atomicly| is now known as AtomiclyCursed
_lore_ has quit [Server closed connection]
_lore_ has joined #openwrt-devel
<f00b4r0>
what's the policy on ath10k-ct-smallbuffers: is it for <=64MB or some higher number?
<hanetzer>
neggles: non-obvious reasons are the death of devices :)
<neggles>
hanetzer: I can dream :P
<stintel>
neggles: problem is that they u-boot also has a signature :P
<stintel>
or checksum, don't recall
<stintel>
so updating just the RSA pub key results in u-boot not booting
<stintel>
well I need to order a .5 EUR flash chip from US :/
<neggles>
1.8v really cramps my style
<stintel>
not sure I want to deal with customs for such a silly order
mrkiko has quit [Server closed connection]
<neggles>
why not just desolder/dump/reuse this one? or do you not have one of those little 3.3V-1.8V converters
romany has quit [Server closed connection]
<stintel>
it's already desoldered and one of the legs broke off from reading it with a clamp too often (I don't have a test socket)
romany has joined #openwrt-devel
<neggles>
ah.
<neggles>
that'd do it
<stintel>
I have a few OC200, my first one is without flash and also missing a PCB trace to that flash, I nuked the chip by reading it with a 3.3V programmer
<stintel>
one is in production, with a ttl header and the missing components
<stintel>
and the 3rd one has been modded by svanheule, he desolderded the chip and soldered an smt socket on the pb
<stintel>
pcb*
<stintel>
I messed up the latter by writing it from Linux in quad SPI mode (don't trust datasheets!)
<neggles>
oops
<stintel>
quad SPI does not work
<stintel>
so rendered it unbootable
<stintel>
tried to recover from that by removing the chip from the socket and writing it with a clamp, but 3M clamps are shit, refused to work, tried too many times and broke a leg
<stintel>
this device is a nightmare
<stintel>
but I have them and ... well sourcing a RPi + PoE HAT + case that fits that + reliable uSD (does that even exist) ... it's just a pain
floof58 has quit [Quit: floof58]
<neggles>
reliable microSDs do exist, but they're $$$$ - e.g. dell vFlash ones
<neggles>
which are 100% overprovisioned pSLC
floof58 has joined #openwrt-devel
mrkiko has joined #openwrt-devel
<stintel>
and probably impossible to source :P
<neggles>
dell will quite happily sell you one
<neggles>
but a 32GB is about US$120
<neggles>
or something stupid like that, anyway
<neggles>
could use one of the eMMC-to-microSD adapter things pine64/odroid etc. sell, but, again, $$$
<stintel>
:D
<neggles>
and that doesn't do much to help with the Pi's SD controller sometimes going "hahaha go away"
<neggles>
may be a good idea to order some of those lil zif sockets/level shifters/etc they sell for CH341As, in one go so you only have to deal with customs once?
<stintel>
yes, I was about to do that but then there is confusion between medium and wide using the same mil, I just gave up
<neggles>
there's only two SO-8 socket types they sell, really - 150mil and 200mil
<neggles>
almost all SPI flash is 200mil ("wide" in aliexpress parlance)
<neggles>
150 is usually TPMs and i2c
<stintel>
and there is also the fact I'm not great at soldering
<neggles>
the secret to being good at soldering is good leaded solder and a flux pen or five - if you're not sure if you have enough flux, add more. then when you think you've got enough, add a little more again :P
<neggles>
and a $100 hot air pencil, though you can get away with solder wick and a TS-100 with a chisel tip for this stuff
<neggles>
the solder in those kits melts at 58C, melt it across all the pins on one side at once and they lift
<neggles>
if you put it back on with 63/37 tin:lead solder, getting it back off again is easy - the hard part is dealing with the factory lead-free stuff's ludicrous melting points :(
robimarko has joined #openwrt-devel
awgh_ has joined #openwrt-devel
<aparcar[m]>
jow thanks for the ucode updates
mva has quit [Server closed connection]
mva has joined #openwrt-devel
awgh has quit [Ping timeout: 480 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
sorinello has quit [Ping timeout: 480 seconds]
<stintel>
neggles: looks like I needed to alias mmc0 to the sdhci0 node, not the mccard one
<neggles>
stintel: ah yes, it wants the controller, not the eMMC
<neggles>
technically the mmc-card node isn't needed at all
<f00b4r0>
neggles: too much flux, especially of the wrong kind, can also have adverse consequences :)
srslypascal has quit [Quit: Leaving]
srslypascal has joined #openwrt-devel
guifipedro_ has joined #openwrt-devel
<neggles>
f00b4r0: this is true, too much tack flux is bad, but i did say flux pen :P
<neggles>
and "no-clean" flux is bad
valku has joined #openwrt-devel
Forst has quit [Server closed connection]
Forst has joined #openwrt-devel
KGB-2 has quit [Server closed connection]
KGB-2 has joined #openwrt-devel
owrt-2203-builds has quit [Server closed connection]
owrt-2203-builds has joined #openwrt-devel
owrt-2102-builds has quit [Server closed connection]
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
Nei has joined #openwrt-devel
Rado has joined #openwrt-devel
<Rado>
Hello, Guys ! Any dev around with some spare minutes ? Need some help
sorinello has joined #openwrt-devel
<stintel>
just ask your question
hanetzer has quit [Quit: WeeChat 3.4.1]
<Rado>
Hi, and thanks. Ehm, brand-newly bought RAX120 v2, where I cannot for the life of me figure out, how can I add mods that I want and which will survive a reboot
<Rado>
Damn thing is still on Chaos Calmer and uses an overlay - even righting to the overlay doesn't preserve anything
<Rado>
For those about to rock... (Chaos Calmer, RAX120-V1.2.3.28+r49254)
<Rado>
LOL
<stintel>
that's not OpenWrt, we can't help you with that
<Rado>
You're joking, right ? It is modified by Netgear OpenWRT
<stintel>
which is not OpenWrt
<stintel>
it's based on an ancient version of OpenWrt which has been EOL for many years, with vendor added patches we know nothing about
<stintel>
so no, I'm not joking, it's not OpenWrt and we can't help you with that
<Rado>
I know, but still people use what's inside to report to OWRT-Devs and help port to real OWRT, no ?
<Rado>
Can't you help me with finding how to make a change and preserve it over an overlayfs ?
<stintel>
we might be able to assist with porting the device to real OpenWrt, yes, but that depends on the device
matteo has quit [Ping timeout: 480 seconds]
<Rado>
Sure, that's something I'd like to help with - dumping out anything from the current config and provide it for everyone interested / developing on this model
<stintel>
yeah well I figured already from "For those about to rock" that it's qsdk based
<stintel>
at that point I'm out :)
<Rado>
Biggest trouble for me is I can't figure out where persistent changes can be stored (yet). As mentioned, I found the overlay, but still changes donot survive a reboot (thanks to Netgear, ofc)
YSC has quit [Server closed connection]
Ansuel has joined #openwrt-devel
YSC has joined #openwrt-devel
<f00b4r0>
stintel: :)
<Rado>
And THANKS a lot for the link, f00b4r0 - appreciated, buddy
<Ansuel>
My 2 cent... once you manage to make persistent change... then what? compile from the gpl source and make your kmod ? a bit uselss... anyway AFAIK support for that is a nono as netgear is an early adopter and the wifi firmware doesn't work with the current ath11k (and i assume it will never work)
<Rado>
Ehm, just to mod some configs to my liking - f.e., to add an init-script for WoL, nothing major
<stintel>
yeah I have a 500+ EUR brick like that myself
<stintel>
I'm done sending money to qca
tmn505 has quit [Server closed connection]
<Rado>
LOL, Netgear are so TYPICAL in that
tmn505 has joined #openwrt-devel
<Ansuel>
stintel just sell it :D (or make it new abusing amazon and sell it as new)
<Ansuel>
fk all the warranty policity they are not right from the start...
<Rado>
Well, I remember there used to be similar "nono" situations, like with the mwlwifi-source at WRT1900AC, but things went great some years later (when the vendour released the source)...
<Rado>
So I am not hopeless all of us with such a "brick" will remain like this forever...
<Ansuel>
sure and now... check the situation of mvebu platform
<Ansuel>
no idea how but ipq806x have better stupport than mvebu
<Ansuel>
one user send me an email asking me to install arch on ipq806x and he manage to do it in less than a day LOL
<Rado>
My WRT1900AC works great with latest stable build
<Ansuel>
with mainline kernel
<Rado>
That's why, after 7+ years with using OWRT on 2+ diff boxes, I finally decided to come over and ask such questions... and eventually help further development
<Rado>
I guess I was wrong with that
<Ansuel>
Rado but no wpa3 and with an old kernel :( we just started working on 5.15 and we encountered some strange problems... i'm pretty negativre about oem early adopting stuff especially if it's something from qcom where it's a miracle if they provide correct support for their upstream drivers
al has quit [Server closed connection]
al has joined #openwrt-devel
<Rado>
:/
<Rado>
Damn
<Ansuel>
my personal advice is to keep using the product and check sometime if openwrt made some progress... once someone manage to make a good SoC working, just sell the device a buy the correct product :(
<Rado>
:/
<Ansuel>
sorry for being a bit rude but we need to be honest about all this situation :(
<Rado>
I want to keep using the product, hence I'm here :D Little help with the storage ? :/
<stintel>
if you want WiFi6 on OpenWrt, get something MediaTek based
<Ansuel>
mount output 100% they are using some script to remount the overlay as ro or they are mounting the overlay to tmpfs
<Ansuel>
problem is having root access aka finfing a rce vulnerability to access mount commands
<stintel>
unfortunately there are many half-assed WiFi6 MediaTek devices, using an 802.11n 2.4GHz chip and only 802.11ax on 5GHz
<Ansuel>
stintel fun stuff considering the good part of wifi ax was on 2.4 optimization...
<stintel>
:)
<f00b4r0>
stintel: I have one of those. (and weird trouble with the ax side which I will try to produce a test case for)
<f00b4r0>
Rado: stintel and Ansuel tried to politely tell you this is not Netgear's support channel. Nobody is going to help you deal with this completely hacked out obsolete firmware :P
hexa- has quit [Server closed connection]
<Rado>
Ok, I won't spam anymore
hexa- has joined #openwrt-devel
<stintel>
while you might find someone here who ran into this issue and can help you, it's really off-topic
<Rado>
Ok, have a nice day
<stintel>
maybe we should have openwrt-offtopic channel or so
<f00b4r0>
heh
Rado has left #openwrt-devel [#openwrt-devel]
<f00b4r0>
then we'd have to triage and redirect people :)
<Ansuel>
rip :(
<stintel>
oh, someone from Bulgaria :P
<Ansuel>
at least I give him an hint of why any changes were discharged :D
<f00b4r0>
Ansuel: unfortunately I don't think he got the cue :)
<Ansuel>
sad for him and for everyone that got stolen by netgear using off the spec SoC
<Ansuel>
they sold wip board to the main public for real... that should be illegal...
<Ansuel>
well time to rip bye all
Ansuel has quit [Quit: Probably my PC crashed or time to sleep.]
niyawe has quit [Server closed connection]
niyawe has joined #openwrt-devel
<Slimey>
heh
<robimarko>
Ansuel: If its RAX120 v2 then it should be supportable
<robimarko>
As v2 uses the IPQ8074A aka v2 revision
<robimarko>
v1 of that board was pretty much public testing of pre-draft 802.11ax
<robimarko>
Anyway, IPQ807x is I would say rather usable on 5.15
<robimarko>
So, I am preping for a PR
<robimarko>
However, what is the opinion towards SSDK and NSS-DP which are currently required for wired networking?
<stintel>
kill it with fire :P
<robimarko>
We agree on that
<robimarko>
I have a special kind of hate for that
<stintel>
is it in the process of being upstreamed or is that junk that will never be upstreamable?
<robimarko>
NSS-DP is kind of decent, nothing too hacky there
<robimarko>
SSDK on the other hand is rather shitty code
* Slimey
pours a bag of Cheerios into stintel
<Slimey>
make heart strong
<robimarko>
I ma upstreaming IPQ807x
slh64 has quit [Server closed connection]
<robimarko>
But wired networking is not upstreamable
slh64 has joined #openwrt-devel
<robimarko>
Until somebody has a lot of time to write proper ethernet and DSA drivers
<stintel>
is it GPL-2 compatible ?
slh has quit [Server closed connection]
slh has joined #openwrt-devel
<robimarko>
Yes, its all GPL-v2 or dual BSD/GPL-v2
floof58 has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
<stintel>
so given that and the fact that many people are eagerly waiting to run OpenWrt on their QCA shitboxes and there isn't really an alternative atm ... I would be inclined to not vote against it
<stintel>
probably a good idea to start a thread about this on the ML
floof58 has joined #openwrt-devel
<robimarko>
Yeah, I could do that
<hauke>
robimarko: are all the firmware files we need for ipq807x licensed under a redistributable license?
* f00b4r0
whispers about #4679, hides
<robimarko>
hauke: We only need ath11k FW
<robimarko>
And thats public
<hauke>
nice
<robimarko>
Older versions are in linux-firmware
<robimarko>
While QCA has newer ones on Kalles github and in their QUIC repo as well
<robimarko>
I can start a thread on the ML
<hauke>
is there no need for a packet processor FW?
<robimarko>
No
<hauke>
good
<robimarko>
Only the NSS cores/crypto EIP block requires FW
<robimarko>
But those are completely optional
<robimarko>
You loose offloading though, but the code is utter crap for that
<robimarko>
Really intrusive kernel changes
<hauke>
which EIP is in there?
<robimarko>
EIP197
<hauke>
thnaks
<robimarko>
I dont know if it was modified by QCA, if not in theory it can be supported by the in kernel driver
<aparcar[m]>
norris: ideas to fix up the chromium target?
<robimarko>
Was there a time when SSDK and GMAC drivers from QCA were used for IPQ806x?
<robimarko>
Probably years ago
<hauke>
robimarko: EIP-197 is very common
tohojo has quit [Server closed connection]
tohojo has joined #openwrt-devel
<hauke>
I think this IP core is normally integarted in the offload datapath and that probably needs some adaption
lynxis has quit [Server closed connection]
lynxis has joined #openwrt-devel
<robimarko>
hauke: The thing is that it acts like its own thing in QCA drivers as well
<robimarko>
They are using the standard 4 EIP blobs for it
<robimarko>
And register the ALGOS to NSS core as well as to the kernel
<robimarko>
Unfortunately, I dont think they used the version that has ChaCha and Poly support though
<hauke>
normally a sillicon vendor gets source code for driver and FW from the IP vendor
<robimarko>
This one looks and smells like 100% QCA-s doing
<robimarko>
This is the version for all of the current QCA SoC-s
<hauke>
ok could be that they did their own driver
<hauke>
anyway I have never used an EIP 197
<robimarko>
Me neither
<robimarko>
I know that newer Armadas should have it
<robimarko>
Though I have newer tried using it
Habbie has quit [Server closed connection]
Habbie has joined #openwrt-devel
floof58_ has joined #openwrt-devel
floof58_ has quit []
floof58_ has joined #openwrt-devel
floof58 is now known as Guest864
floof58_ is now known as floof58
Guest864 has quit [Ping timeout: 480 seconds]
Misanthropos has joined #openwrt-devel
mirko has quit [Server closed connection]
mirko has joined #openwrt-devel
<norris>
aparcar: not really at the moment. Can't reproduce, and even the builder is flaky. Was kinda hoping there was some kind of builder issue...
<norris>
Do you have any ideas?
<Tapper>
Hi people is there any one here that has ksmbd working? I would like to know because I don't know if it is me or I have found a bug. I don't want to post a issue if it is just me being a dumbass
<norris>
aparcar: not really. Can't reproduce, and even the builder is flaky. Was kinda hoping it was just a builder issue...
<norris>
Oops double post. Sorry, flaky connection
<norris>
ynezz: thanks! I'll see if I can get a real match at what exactly is doing that. but that sounds like something coming out of openssl. it also sounds like it might be a kernel mismatching issue -- that openssl was expecting a getrandom(2) syscall but couldn't get it
<ynezz>
indeed, but it's quite interesting that only this util is able to trigger that issue
<norris>
(and that could explain machine to machine differences, even in the presence of docker. docker doesn't ensure everyone is running the same kernel)
<ynezz>
I've tried it outside of the docker as well, the issue is same
<norris>
oh, cool(?)
<norris>
do we have many other host tools using openssl like this?
<norris>
I only see one other one in firmware-utils
<norris>
ynezz: btw, what kernel is the builder on, if you don't mind sharing?
<norris>
getrandom() has been around for a while...
Larhzu has quit [Server closed connection]
Larhzu has joined #openwrt-devel
<ynezz>
3.16.85-34
<ynezz>
:P
<norris>
yikes!
noltari has quit [Server closed connection]
<Slimey>
heh
noltari has joined #openwrt-devel
<ynezz>
it's probably not worth the hassle, so I'm going to remove the builders
<ynezz>
or rather move them to some older releases
bookworm has quit [Server closed connection]
bookworm_ has joined #openwrt-devel
<ynezz>
we've lost bunch of OSUOSL builders recently so the build resources are scarce
<f00b4r0>
ynezz: I could restart mine, it still works with 1 dead HDD, but the uplink bandwidth is currently awful (1Mbps) so not sure it would help much: upload time is likely to be greater than build time
<norris>
ynezz: hmm, well I haven't gotten super far in there, but it seems like openssl *should* be able to fall back to /dev/{u,}random and the likes. it's possible we (or debian) are doing something that tells openssl not to use that fallback.
<norris>
but if y'all will "fix" this by using a slightly less ancient kernel, that's OK with me too :)
hanetzer has joined #openwrt-devel
c0sm1cSlug has quit [Server closed connection]
c0sm1cSlug has joined #openwrt-devel
<f00b4r0>
ynezz: ha, I just checked again: I'll be eligible to FTTH in 3 weeks. There's hope :)
<stintel>
weeeeeeee
<ynezz>
f00b4r0: fingers crossed :)
<f00b4r0>
ynezz: :) That machine currently builds ath79 in under 30mn, and used to build in about an hour when running buildbot through a VM with a full NUMA node reserved (it's a 2-node system with E5-2680). So it should help a bit
<ynezz>
norris: yeah, don't waste more time on this, would be nice to update the PR with our findings and let Christian to unblock that target
<ynezz>
norris: it currently still builds probably due to the fact, that we would need to reload buildbot configuration in order to remove the source-only targets
<f00b4r0>
I might be amenable to the idea of running on bare metal to speed things up even more, given current electricity prices ;P
<Grommish>
stintel: Literally no traffic in or out except for the console, something is still odd
<Grommish>
I'll just have to stop killing services one at a time and see what causes it, I suppose :(
<Grommish>
s/stop/start
Slimey has quit [Quit: AdiIRC is updating to v4.2]
<yolo>
https://postimg.cc/wyX4yqq5/6814b2df somehow my make menuconfig gave me this messed up interface plus I never never move cursor to the first line in menuconfig, not sure what happened, anyone seen this?
<yolo>
s/never never/could never/
Slimey has joined #openwrt-devel
<yolo>
tried buildroot, same, something is wrong with my terminal probably
<rsalvaterra>
I stand by the 2048 divider hack. :P
svanheule has quit [Remote host closed the connection]
svanheule has joined #openwrt-devel
<aparcar[m]>
let's do it
<yolo>
i got a risc-v board from sifive(unmatched, the "newest"), a quick search did not turn up anyting info, but is riscv64 an 'officially' supported arch in openwrt yet
<yolo>
nezha(I failed to grab one board and it stopped shipping due to chip shortage) does have openwrt sdk ready for download, that shall help the porting. which chip/board is this git for initially. thanks for the info.
<hauke>
the allwinner SDK is broken like the QSDK
<hauke>
I am not sure which is wrose
<yolo>
:)
<yolo>
just checked out buildroot for risc-v, interestingly buildroot still defaults to uclibc-ng instead of musl
hanetzer has quit [Ping timeout: 480 seconds]
<rsalvaterra>
aparcar[m]: Let's see what the author says first, maybe he wants to update his pull request accordingly.
<mangix>
./configure: line 15398: gt_TYPE_WCHAR_T: not found <-- looks familiar
<jow>
looks like missing local macro
<jow>
welcome to the wonderful world of autohell
<jow>
automatically causing problems since 1991
<mangix>
replacing patch-libtool with libtool didn't fix it. let's see if updating tools/libtool does
<jow>
I don't think mindlessly bumping libtool is a solution here
<jow>
openwrt's libtool and libtool patches specifically added code to pick up host libraries and blacklisting default paths like /lib and /usr/lib leaking in
<jow>
one faulty *.pc or *.la file sources somewhere during the build process is enough to sneak in a stray -L/usr/lib and libtool starts randomly linking in host stuff