Andi_ has quit [Remote host closed the connection]
Andi_ has joined #openwrt-devel
genuser1 has joined #openwrt-devel
genuser1 has quit []
mirko has joined #openwrt-devel
Tusker has quit [Remote host closed the connection]
Tusker has joined #openwrt-devel
victhor has quit [Ping timeout: 480 seconds]
danitool has quit [Ping timeout: 480 seconds]
<digitalcircuit>
Belated response to robimarko: Noted! I feel like I'm very close to getting the modern kernel dynamic debug approach working (no need to wait to tinker with files after an initial build), but if I don't sort that out soon, I'll fall back to printk tweaks.
<digitalcircuit>
Maybe there's other stuff I'm missing; I'll give this a few more tries and failing that, disable dynamic debugging to revert to printk/DEBUG flags.
<digitalcircuit>
slh: I've gotten dyndbg properly parsed, but it's not printing the details that dynamic debugging claims it should be: [ 0.004246] dyndbg: applied: func="" file="drivers/mmc/*" module="" format="" lineno=0-0 \n [ 0.004262] dyndbg: processed 1 queries, with 123 matches, 0 errs
<slh>
I fear I won't be of much use re dynamic debugging, but I'm surely interested in what caused this issue
<digitalcircuit>
Yeah. I realize it's kind of silly, but I want to make dyndbg work since it's far nicer (in theory) than having to modify kernel Makefiles after an initial build. And it allows enabling during runtime, too (my initial reason for using it during CPU crash debugging).
<digitalcircuit>
slh: It worked! Just also had to change "loglevel" in bootargs.
<Tusker>
digitalcircuit: sorry I didn't pipe up when I saw you were having dyndbg issues, but my text file that had my notes about dyndbg seem to have disappeared on me, and my memory didn't help out
<digitalcircuit>
Tusker: No worries! I'll need to jot these things down somewhere at some point.
<digitalcircuit>
"CONFIG_KERNEL_DYNAMIC_DEBUG=y" in OpenWRT primary config alongside modifying qcom-ipq8065-nbg6817.dts to set bootargs = "[...existing bootargs...] dyndbg=\"file drivers/mmc/* +p\" dynamic_debug.verbose=1 loglevel=8"; results in the verbose log I was looking for, and this can be done without modifying the Linux kernel files.
<digitalcircuit>
(No need for "dynamic_debugging.verbose=1", but it helps.. debugging debugging)
<Tusker>
i got the t30-w so that I could cross-diagnose the xtm330... but different challenges abound :)
* digitalcircuit
nods!
<digitalcircuit>
I s'pose I wouldn't still be troubleshooting NBG6817 if I wasn't enjoying it at least a bit... Just didn't expect the MMC fault to take over the CPU crash debugging, either.
<dwfreed>
digitalcircuit: the CMD5 failures before are curious
<dwfreed>
but it would be helpful to compare to a successful boot to see if they matter
<digitalcircuit>
dwfreed: Noted! Definitely gonna do a v5.4 successful boot capture - build's already going :)
<Tusker>
strange... how does sysupgrade find mkfs.ext4 but not find mkfs.ext2... luckily mkfs.ext4 -t ext2 works
<Tusker>
OK, sysupgrade works nicely now :)
<dwfreed>
digitalcircuit: trying to identify what generates the MMC commands is, uh, challenging... drivers have so much indirection...
<dwfreed>
I did figure out what cmd 5 is, though: MMC_SLEEP_AWAKE
nitroshift has joined #openwrt-devel
<dwfreed>
digitalcircuit: okay, so that cmd 5 timeout appears to be harmless, looks like it's just sdio probing (obviously not useful on an emmc...)
<dwfreed>
cmd 5 is also used by SD_IO_SEND_OP_COND
<digitalcircuit>
dwfreed: Thanks for looking into this, too! I've got my build, rebooting now and I'll update here once I've captured the logs.
rmilecki has joined #openwrt-devel
<Tusker>
is there an nvmem way to read 17 byte mac addresses to fixup ethX and wlanX ? They are stored in some offset in a partition
<digitalcircuit>
(Well, not the FULL log. I trimmed it after the "Press # and Enter to change debug level" message because it's a ton of stuff. Lesson learned for the future, too... press "4" then "Enter" next time instead of trying to nbg6817-dualboot --toggle-flag && reboot at the console.)
<digitalcircuit>
(The voltage range warning was visible without the extra debugging, too.)
<digitalcircuit>
"Single data transfer rate: up to 52MB/s (using 8 parallel data lines at 52MHz)", "Dual data rate mode (DDR-104) : up to 104MB/s @ 52MHz"
<dwfreed>
interesting
<digitalcircuit>
If the MMC is only switched to 52 MHz much later in the boot process, I might have it in my full v5.4 log (2.0 MiB), but if it happens after you're able to get a root serial console, then I don't have it.
<digitalcircuit>
Either way, it's a difference!
<dwfreed>
there's some further differences, but those may be related to the clock freq
<dwfreed>
it does end up switching to a 52 MHz clock later in your 5.4 log
<dwfreed>
just saw it
<digitalcircuit>
Ah, phew, noted!
<digitalcircuit>
And thank you for looking, too. MMC protocol is far beyond me (for now) :)
<dwfreed>
I've never done MMC protocol before; I'm learning a lot of this as I go
f00b4r0 has joined #openwrt-devel
<digitalcircuit>
Ah, heh, that's encouraging. In that case - it's beyond my current energy level, at least - 3:11 am.. I'm gonna wind down now. But feel free to ping whenever and I'll see anything when I'm back!
<dwfreed>
I'm an hour behind you, I should probably sleep too
danitool has joined #openwrt-devel
mirko has quit [Read error: Connection reset by peer]
mirko has joined #openwrt-devel
Dgrey has joined #openwrt-devel
Tapper has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
decke has joined #openwrt-devel
dangole has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<GuruPrasathGovindarajan[m]>
Do any one why dockerd crashes when I run a run a image with --network="bridge" but doesn't when run it with --network="none" or --network="host"
Grommish has joined #openwrt-devel
eduardo010174 has joined #openwrt-devel
victhor has joined #openwrt-devel
<rmilecki>
hauke: bcm47xx doesn't start booting with kernel 5.10, nothing in serial console, even with early printk
<rmilecki>
hauke: i'll have to bisect kernels between 5.4 and 5.10
<stintel>
rmilecki: I'm seeing the same with amlogic s9xx (my unfinished meson target)
<rmilecki>
stintel: i'll let you know if I find a reason
<rmilecki>
(bcm47xx reason)
<stintel>
I have not tried with gcc11 yet
<Grommish>
stintel: What issues were you having with the ERL?
<stintel>
memleak, reboot within ~8h
<karlp>
jow: is ui.createHandlerFunction meant to be usable from CBI.js stuff? it works, but I don't get the spinner styling and deactivation that I get when it's in a "raw" E() style https://paste.jvnv.net/view/xogUv
<Grommish>
Could it be dnsmasq related? I just ran into dnsmasq memleaking when using adblock block lists
<Grommish>
Where oom-killer would be invoked and then loop, causing it to die
<Grommish>
dl12345 had code to allows dnsmasq to limit the forked processess and keep the oom from happening.. I'm testing it to see if it fixes the issue
<Grommish>
Don't get me wrong, the moment ERL goes official EOL, I'm going to petition to have the -march changed to octeon2 from octeon+, but I'd hate to see it go
<stintel>
Grommish: doubt it, dnsmasq does not run by default on my backup router
<Grommish>
stintel: Ah, ok.. Still, very wierd that it would only effect the ERL?
<stintel>
I can test on the CN6640-SNIC10E-G when back at home in ~2w
<stintel>
or Habbie can help debugging if he's up for it, once I hand my 2 ERLs to him ;)
<stintel>
rmilecki: looks like layerscape also exhibits this behaviour
eduardo010174 has quit [Remote host closed the connection]
<mrkiko>
stintel: rmilecki: probably stupid question but - may this be a size issue?
<rmilecki>
stintel: sure, could be
<rmilecki>
stintel: maybe I'll try building without debug symbols
<rmilecki>
compiling now
<rmilecki>
# CONFIG_KERNEL_KALLSYMS is not set
<stintel>
unfortunately I also cannot test my odroid c2 with 5.10 right now
<stintel>
well I could, but if it fails I can't recover until back home
<mrkiko>
stintel: rmilecki: do we have "control" over u-boot blootloader in layerscape? What's the state of u-boot here? How much closer it it to upstream? Because this changes the probability it can be a size issue here
<stintel>
I have no experience with layerscape, just noticed this in the 22.02 release goals thread
<rmilecki>
mrkiko: no idea about layerscape
<stintel>
but iirc, on the meson target I'm using vanilla u-boot
<stintel>
yep, 2021.07
<stintel>
the not booting could of course have different causes, as they're all completely different architectures
<stintel>
afaik
decke has quit [Quit: Leaving.]
<mrkiko>
sure
<stintel>
actually layerscape is arm as is meson but bcm47xx is mips
<mrkiko>
however, these size issues seems pretty diffuse; I meet this concretely in ramips with LZMA ERROR 1 :D
<stintel>
ah, lovely errors those :)
<stintel>
very useful!
guidosarducci_ has joined #openwrt-devel
<mrkiko>
eheh infact
<mrkiko>
still remember that time; blocktrron connecting UART to R6220 and seeing that error, explaining why my R6220 didn't boot.
<mrkiko>
stintel: and also the "RESET BOARD TO RECOVER" part that tells you there's no way other than powering off :D
<stintel>
I have a new board that requires this :D hifive unmatched
guidosarducci has quit [Ping timeout: 480 seconds]
guidosarducci_ is now known as guidosarducci
<stintel>
grabbing that before it disappears again
rua has joined #openwrt-devel
<rmilecki>
stintel: didn't help
<rmilecki>
stintel: i guess it's some kernel regression
minimal has joined #openwrt-devel
<stintel>
rmilecki: and without any output at all very hard to debug :/
<rmilecki>
stintel: git bisect :)
<stintel>
yeah, from 5.4 to 5.10, within OpenWrt, have fun ;)
<stintel>
let me know in 2 months how far you've come
<stintel>
but actually, with meson, this has decent upstream support, and afaik almost no patches, not in 5.4 nor in 5.10, so for this target it could be relatively easy
<stintel>
I just can't do it this month
Tusker has quit [Remote host closed the connection]
<mrkiko>
stintel: I'm curious, what does that patch does for the Unmatched?
<mrkiko>
stintel: can you elaborate little bit on that?
<stintel>
well, maybe not why it 's needed, can't find the forum post atm
<stintel>
the symptom is: you reboot, and the machine shuts down but doesn't reset, you need to push the reset button for that
<mrkiko>
stintel: thanks!!
<stintel>
actually that series is even better than the gist
<stintel>
ahh but needs a ve34
<stintel>
oops, fat fingers
<stintel>
v3*
<mrkiko>
stintel: thanks!
<stintel>
I would almost consider the unmatched as thin workstation, move my noisy HP Z840 and its UPS out of my office, but browsers weren't properly building for RISC-V yet last time I tried
Grommish_ has joined #openwrt-devel
<stintel>
and the GPU I bought for it is not handling the 5120x1440 resolution very well
<stintel>
rsalvaterra: I cannot confirm nor deny that :D
<rsalvaterra>
Like I usually say, "I neither confirm or deny it. On the contrary." :P
<f00b4r0>
stintel: heh, you got me intrigued for sure. That it is PPC certainly gets a keen eye from me ;)
<stintel>
I'm aiming to push it to master next month
<stintel>
I have one running as my main router since end of July iirc
<f00b4r0>
nice
<f00b4r0>
how big of a power hog is it, if you happen to know? (at the mains plug)
<stintel>
I have not measured unfortunately, I could do that in November - feel free to ping me about it to remind me
<f00b4r0>
will do :)
<f00b4r0>
in the meantime I'll keep an eye on eBay
<stintel>
EOL for !Japan should be end 2022 iirc
<f00b4r0>
that's what it says on the website, yes
* rsalvaterra
still has that benchmarketing thing to do…
<stintel>
so I expect a few of them to land on ebay soon
<stintel>
soonish
<f00b4r0>
makes sense
hubvu_ has joined #openwrt-devel
hubvu has quit [Ping timeout: 480 seconds]
hubvu_ is now known as hubvu
<rsalvaterra>
I'll probably just make a config backup, reset the Omnia and be done with it. My old i3 380 M should be able to easily saturate the 1 GbE link with WireGuard.
fda has joined #openwrt-devel
<Grommish_>
stintel: ping
<stintel>
Grommish_: pong
<Grommish_>
stintel: I found a great big memory leak that I can trigger consistently, but I'm not sure 'where' it's at.. Its on an Octeon3 device.. Suggestions on where to start?
<Grommish_>
stintel: What I thought was a dnsmasq issue doesn't appear to be a dnsmasq issue
<stintel>
Grommish_: I would enable CONFIG_KERNEL_SLABINFO and maybe in the kernel config itself CONFIG_DEBUG_KMEMLEAK
<stintel>
and the slabtop utility
<Grommish_>
stintel: Ok.. I was looking at dnsmasq and adblock being an issue.. I was testing by running a script that called netcat -t 127.0.0.1 53 & in a loop until it hits the number.. If I call the netcat command manually, I get no issue.. I run that script, and the memleak is profound.. I'm going to get vid capture of it because I'm not sure how to explain it correctly :D
guidosarducci has quit [Remote host closed the connection]
guidosarducci_ is now known as guidosarducci
Grommish has joined #openwrt-devel
<mangix>
xdarklight: Makefile uses AUTORELEASE
KGB-0 has quit []
Andi_ has quit [Read error: Connection reset by peer]
Andi_ has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
KGB-0 has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
Tapper1 has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<xdarklight>
mangix: then I don't know why I manually had to remove the package from build dir to get that fix. maybe something random with my tree - thanks for checking
rsalvaterra_ has joined #openwrt-devel
rsalvaterra is now known as Guest3567
rsalvaterra_ is now known as rsalvaterra
eduardo010174 has left #openwrt-devel [#openwrt-devel]
eduardo010174 has joined #openwrt-devel
Guest3567 has quit [Ping timeout: 480 seconds]
<eduardo010174>
For create on pull request for device how it's needed?
danitool has joined #openwrt-devel
eduardo010174_ has joined #openwrt-devel
eduardo010174 has quit [Quit: Page closed]
eduardo010174_ is now known as eduardo010174
Tapper1 has quit [Ping timeout: 480 seconds]
Grommish_ has joined #openwrt-devel
Grommish has quit [Remote host closed the connection]
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
genuser1 has joined #openwrt-devel
<hauke>
rmilecki: brcm47xx has a extra loader, this is also causing problems on some ath79 targets, which has a diffeernt loader
<hauke>
rmilecki: ah sorry, this was about gcc 11
genuser1 has quit []
Tapper has joined #openwrt-devel
rsalvaterra_ has joined #openwrt-devel
rsalvaterra is now known as Guest3572
rsalvaterra_ is now known as rsalvaterra
Guest3572 has quit [Ping timeout: 480 seconds]
<rsalvaterra>
This benchmarking thing is going to take a while…
<stintel>
:)
eduardo010174 has quit [Quit: Leaving]
jbowen has quit [Ping timeout: 480 seconds]
<rsalvaterra>
Especially openssl speed… :P
jbowen has joined #openwrt-devel
<dwfreed>
speed: 5 bits per hour
minimal has quit []
arifre has quit [Remote host closed the connection]
philipp64 has quit [Quit: philipp64]
Acinonyx has joined #openwrt-devel
<stintel>
Grommish_: that's you who's working on surricata and by extension rust, right ?
Acinonyx__ has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 480 seconds]
arifre has joined #openwrt-devel
<mangix>
xdarklight: I'll update the package instead. This fix made it upstream.
<xdarklight>
mangix: great - thanks!
jlsalvador has quit [Read error: No route to host]
Acinonyx has quit [Ping timeout: 480 seconds]
<Grommish_>
stintel: Yes
jlsalvador has joined #openwrt-devel
<stintel>
Grommish_: seeing how simple the llvm-bpf package that was just committed is, makes me wonder if we should aim for having llvm in core and use that to build rust, instead of building llvm as part of rust
<Grommish_>
stintel: LLVM isn't available on all arches, but as long as you assume its a x86_64 or supported ARM, it really doesn't matter on my end of things.. I should be able to define the LLVM on the build as external easy enough
<Grommish_>
I need to rework that entire package now that I know more about the build system
<Grommish_>
it has always been kludge, but I'm sure I can clean it up
pmelange has joined #openwrt-devel
<mangix>
mt7621 looks like it will get an upstream crypto driver soon
<mangix>
too bad it's still slow
<Habbie>
crypto driver for what bits?
<mangix>
hmm? AES and whatnot
<Habbie>
right
<Habbie>
so not for handshakes
<mangix>
uhh what handshakes?
<Habbie>
TLS handshakes, sorry
<Habbie>
for the crypto things i've been trying on weak openwrt devices, TLS handshakes are the big pain point
<Habbie>
0.5sec on the archer c7
<stintel>
ah that's going to suck for DoH/DoT :)
<Habbie>
stintel, ask me how i know!
<Habbie>
(or don't, you already know ;) )
<stintel>
;)
<mangix>
Habbie: wonder how kTLS performs
<Habbie>
mangix, kTLS kicks in after handshake, so that's easy :/
Tapper has quit [Ping timeout: 480 seconds]
<mangix>
after?
<Habbie>
yes
<Habbie>
kTLS expects symmetric material from userspace, and takes it from there
<Habbie>
(i'd love to be wrong here)
<mangix>
hrm weird. Anyway, I don't think you can do better than djb crypto for TLS
<dwfreed>
Habbie: trippeh would know :)
<Habbie>
yeah this was chacha and x25519 and such
<Habbie>
dwfreed, i might have checked with trippeh but i'm not currently sure
<mangix>
Habbie: hardware crypto is mostly for bulk encryption stuff, like VPN or dm-crypt.
<mangix>
mt7621 is still slow though
<Habbie>
mangix, i know, but i always ask in case some new situation is different
<mangix>
slower than archer c7 AFAIK
<mangix>
mips 24k vs 74k
<mangix>
the SMP support is also a joke
jbowen has quit [Quit: leaving]
<Habbie>
like Intel QAT, which really does improve handshakes
<Habbie>
it complicates the interface, though
<Habbie>
while kTLS might simplify the interface in fact
<Habbie>
ack
<mangix>
I have 11 open PRs on github...
<Habbie>
but if it gained decent handshake offload, i might suddenly like it a lot :)
<mangix>
Habbie: so the Archer C7 has many capabilities not implemented in software. No idea about crypto, but for example the hardware supports ethernet checksumming and some other stuff not implemented by the driver. Nobody to work on it.
<Habbie>
mangix, right
<mangix>
qca8k is implementing some switch stuff, but it's still relatively immature.
<Habbie>
mangix, and the stock firmware has all of that? this is not the first time i'm hearing of downsides to putting openwrt on a device
<mangix>
Habbie: good question. So stock Archer C7 firmware has hardware NAT that caps out at ~800mbps. OpenWrt's software flow offload maxes it out AFAIK.
<Habbie>
maxes it out at gbit?
<mangix>
well, ~910 or 920
<mangix>
can't get full gigabit
<mangix>
cause overhead and whatnot
<Habbie>
i often consider 9xx numbers to be 'maxing out'
<mangix>
right
<Habbie>
at that point you need to think about ethernet framing to make sure you're not already at the physical limits, yes
goliath has quit [Quit: SIGSEGV]
<Habbie>
'all this time i have been measuring pps because that was the problem but now i suddenly need big frames'
<mangix>
increasing MTU helps with getting higher numbers.
<mangix>
interestingly enough, the linux networking stack uses an internal MTU of 64k
Tapper has joined #openwrt-devel
<Habbie>
yes, once pps is not the problem
<mangix>
That can be implemented by drivers, but proper GRO needs hardware checksum offloading, which the ethernet driver currently does not support.
<Habbie>
right
<mangix>
and nobody to deal with it.
<Habbie>
so, could it be true that openwrt's 910 maxes out on CPU, while that stock 800 leaves the CPU mostly happy?
<mangix>
Habbie: beats me. stock firmware uses old kernel and hacked up networking stuff.
<Habbie>
ack
<mangix>
Ansuel might be working on getting HNAT working on qca8k. I have no idea.
<Habbie>
if true, it's a choice that might make sense
<mangix>
Habbie: not really. No wireguard with stock firmware.
<Habbie>
sure, every choice has downsides
<mangix>
wireguard is a must for me.
<Habbie>
i also have a few devices running stock kernels with a new userland in a chroot
<Habbie>
which, up to a limit, is a best of both worlds thing
<Habbie>
but wg would not be happy there
<dwfreed>
just use wg-go
<dwfreed>
as long as you can get a tun device, it'll work
<Habbie>
entirely related, i have an openbsd router that needs a reinstall before i can migrate a tunnel to wireguard, but i've decided i want to put an openwrt backup next to it first
<Habbie>
just need to decide on hardware for that
<mangix>
did openbsd get native wireguard? I think I read something like that.
<Habbie>
it did
<Habbie>
unlike freebsd
<mangix>
wonder what the macOS story is
<mangix>
I'm quite shocked that they made a Windows driver/
<dwfreed>
macOS has tun-tap drivers
<Habbie>
that it does
<Habbie>
a lot easier to write portable hacks that way
<mangix>
so userspace
<dwfreed>
so wireguard is an entirely userspace implementation that uses that
<Habbie>
my vpn needs would be served fine in userspace
<mangix>
what's funny is that openvpn's response to wireguard is to write their own kernel driver.
<mangix>
hopefully android 12 for my phone will come with kernel wireguard
<dwfreed>
because the kernel driver is the part that makes wireguard better than the rest, sure...
<Habbie>
lol
<Habbie>
i got a new phone today, but it's on 11 for now
<dwfreed>
not the fact that wireguard is infinitely easier to configure than any other VPN ever made
<mangix>
dwfreed: lower CPU usage
<Habbie>
i wonder if openvpn couldn't replicate that
<dwfreed>
I will have a Pixel 6 Pro in ~ a week
<Habbie>
because openvpn also has a non-CA mode
<mangix>
CPU usage is important for phones
<mangix>
wireguard drains my battery
<Habbie>
is your wg passing a lot of traffic?
<mangix>
nope
<mangix>
I think it just keeps the phone on
<Habbie>
ugh
<Habbie>
yeah that's bad
<dwfreed>
it shouldn't, iirc, wireguard is implemented as a proper VPN app
<Habbie>
dwfreed, that's also what i understood
<Habbie>
it doesn't even ping, right?
<rsalvaterra>
mangix: The MT7621 is faster than the QCA9558, make no mistake. You're comparing a single 720 MHz (OoO, granted) core… to two SMT2 880 MHz in-order cores with 256 kiB of L2$ on top.
Tapper has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
<mangix>
rsalvaterra: no way
<mangix>
maybe with synthetic benchmarks like openssl.
<rsalvaterra>
Maybe the QCA9558 is faster in some single-threaded workloads, but the absence of L2$ will surely hit hard.
tohojo has joined #openwrt-devel
<Slimey>
anyone talks about L2 i think of layer 2
Andi_ has quit [Remote host closed the connection]
Andi_ has joined #openwrt-devel
rmilecki has quit [Ping timeout: 480 seconds]
<mangix>
i think of l2 cache
<rsalvaterra>
L2 - layer 2. L2$ - level two cache.
<mangix>
qca9558 has no l2 cache?
<mangix>
sounds wrong
<rsalvaterra>
mangix: Check the first lines of your dmesg.
<rsalvaterra>
You have 32 kiB of L1D$ and 64 kiB of L1I$.
<mangix>
hrm interesting
<rsalvaterra>
The MT7621 has 32 kiB of L1D$, 32 kiB of L1I$ and 256 kiB of L2$.
<mangix>
I just checked wikidevi. Looks like Ansuel has switches to add to qca8k
Tusker has joined #openwrt-devel
<rsalvaterra>
hauke: I'm trying to wrap my head around the fact I'm seeing better performance with cortexa9+vfpv3-d16 than with cortexa9+neon, in openssl speed, on my Omnia. :|
<Ansuel>
owww s17 that's what is that damn s17 in uboot source
<mangix>
wait a minute
<mangix>
LOL
<slh>
if there are devices using those, they will show up one day - or not, also a solution ;)
<mangix>
Ansuel: QCA8337N is listed as QCA9563 while QCA8337 is listed as IPQ8064. That's gotta be wrong
<mangix>
I thought QCA8337N was used by ipq
<slh>
nope
<Ansuel>
nono
<Ansuel>
ipq have nss so no reason to add hnat as it will be offloaded by special core
<slh>
I don't know of any ipq806x device with QCA8337N, all known ones have QCA8337
<Ansuel>
other soc doesn't have nss so hnat
<mangix>
right
<Ansuel>
anyway no documentation for 8335
<mangix>
Ansuel: no devices in DeviWiki either
<Ansuel>
wow 8075 is VERY new
<Tusker>
would someone mind reviewing a PR I have, so that we can get it into a good shape? - https://github.com/openwrt/openwrt/pull/4697 - I am intested in working out the nvmem way to retrieve ASCII based mac addresses
<Ansuel>
2015 stuff
<Ansuel>
psgmii is this ipq40xx ?
<slh>
yes - and ipq807x, ipq60xx, ipq50xx
<Ansuel>
it an't be we have documentation for the switch in ipq807x
<Ansuel>
wait we don't have documentation.... no regs defined in the pdf -.-'''
<rsalvaterra>
hauke: CPU_SUBTYPE:=neon implies vfpv3 (full, with 32 registers).
<rsalvaterra>
(It's how I'm compiling.)
<rsalvaterra>
According to the GCC documentation, at least.
robimarko has joined #openwrt-devel
<robimarko>
Ansuel: S17 is what QCA calls 8327/8337 in U-boot
<robimarko>
Also, QCA8072/5 are just PSGMII PHY-s
<robimarko>
They are not switches
<hauke>
rsalvaterra: yes I think so too
<Ansuel>
sad
<hauke>
do you have to activate neon support somewhere in openssl?
<rsalvaterra>
hauke: Not really. You just have an option to enable hand-optimised assembly (I have it enabled).
<robimarko>
hauke: Thanks for merging the SFP patches, I will send a patch to backport the Globalscale MOCHAbin instead of using a local DTS as it got merged upstream