<neggles>
hurricos: you had a meraki with an LS1043 coming yeah? it looks like the smartfusion2 that's on there is not cisco's doing, it's part of the LS1043A-QDS reference design which the MX67/MX68 models are based off
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Spr0cket has joined #openwrt-devel
Grommish has quit [Remote host closed the connection]
<arnd>
neggles: I'm trying not to get close to any of those
<arnd>
neggles: also note that names are intentionally confusing: that Dell machine you found is a ThunderX, which is the server cousin of Octeon TX but is quite different in the details
<neggles>
arnd: yeah, same ARM cores as the Octeon TX (CN8xxx) but not as the Octeon TX2 (which are also not the same cores as in a ThunderX2...)
<arnd>
the chip in the solid-run board is an Octeon TX2 but is not related to Octeon TX, ThunderX or ThunderX2. This is in fact the successor to Armada 7040
<arnd>
The bigger Octeon TX2 (92xx, 96xx, 98xx) are apparently derived from Octeon TX and are yet another core type that is not used anywhere else
<neggles>
the bigger octeon TX2s use the ThunderX2 core, yes
<lemmi>
we have a couple of those solid run boards on ordern. i currently have the gt8k with armada 8040 on the bench. i expect the tx2 to do even better. double memory bandwidht and all
<neggles>
the CN9130's acceleration engines etc - aka the annoying bits that cause all the havoc - are the same as its bigger brothers
<neggles>
and the specifics of ThunderX vx ThunderX2 vs A72 vs A76 ARM cores are not hugely relevant when all is said and done
<lemmi>
without a lot of tuning we managed to route about 330kpps. i have yet to test xdp offload. i expect this to work much better with that
<neggles>
there's a CPU performance impact, sure, but it's the other bits of the SoC which are problematic driver-wise
<neggles>
the A8040 and the CN9130 are a very weird/interesting pair of SoCs
<lemmi>
they kind of are. too bad the debian kernel forgot the frequency scaling options, so i don't really know the true idle power draw from the A8040. currently it sits at 7W and 12-14W full throttle
<arnd>
neggles: one aspect that may be relevant fore the cores is that the ThunderX core in TX1 is not just slow but also full of bugs. The Vulcan cores in ThunderX2 are much better but you won't find them in Octeon TX2. I would expect the cores in cn92xx/cn96xx/cn98xx to be better than the ThunderX cores, but they probably have a lot of the same problems and won't be as fast as a Cortex-A72
<neggles>
the ThunderX2 stand-alone server CPUs were very good, supposedly, but almost none of them made it into the wild
<arnd>
also, I have not seen any kernel sources for cn92xx/cn96xx/cn98xx, and there is very little upstream support
<neggles>
they are supported in octeon sdk 5.1, which is pretty long in the tooth, but marvell just refuse to give me a more up to date version
<neggles>
jackasses
cmonroe has joined #openwrt-devel
<arnd>
agreed, ThunderX2 was fine, and ThunderX3 promised to be even nicer, but that's all gone even from their web pages, I suppose they decided they could not compete with the neoverse roadmap in the end
<neggles>
A8040 has some more serdes lanes and half the RAM bus width
<neggles>
oh wow okay apparently the CN9130 is an MCM
<neggles>
and the difference between the 9130/9131/9132 models is how capable the 'southbridge' die is
<arnd>
it's the number of I/O dies
<neggles>
ah, uh, nope
<neggles>
it's
<neggles>
it's external chips
<arnd>
7040 has one I/O chip, 8040 has two
<neggles>
the 9131 is a 9130 + an 88F8215
<neggles>
9132 is two 88F8215
<lemmi>
yep
<neggles>
so the 9131/9132 are not actually "a thing"
<neggles>
welp. good to see octeons are still weird.
<lemmi>
although i haven't really looked into what that "moca" bus is, that connects them
<neggles>
weeeeeeird.
<neggles>
i'm gonna have to buy one of those solidrun 9130 boards to play with sooner or later
Grommish_ is now known as Grommish
<neggles>
but for now I have qualcomms to dissect
<arnd>
neggles: I think the way it works is that 9130/9131/9132 have 1/2/3 cp115 dies in the package in the same way taht 7040/8040 have one or two cp110 dies
amaumene has quit [Read error: Connection reset by peer]
<neggles>
arnd: the datasheet implies otherwise - it says the CN9130 is a single HFCBGA 24x24mm package, and the 9131 is the same with an extra 88F8215 TFBGA 12x12mm package
<neggles>
two extra for the 9132
<arnd>
they also had 7080 8080 and even 8160 with eight or 16 cpu cores before they acquired cavium and cancelled them, but I don't know if those just had extra cpu dies or were larger chips with more cores
<neggles>
solidrun have a CEx7 board that's 9130/31/32
<neggles>
and, yep, there's the 88F8215s
amaumene has joined #openwrt-devel
<neggles>
now to play a fun game called "did nokia disable JTAG/UART on this"
duke2 has joined #openwrt-devel
<duke2>
hey
Tapper has quit [Read error: Connection reset by peer]
<Grommish>
neggles: Another round of "Poke n Pray"?
<neggles>
Grommish: pretty much
<neggles>
I can see something that looks like a data out...
<duke2>
i want to use my intel hd4400 on openwrt for hw encoding, downloaded the intel driver and tried to compile on openwrt. but many deps missing. probably not the "correct" way?
felix has quit []
felix has joined #openwrt-devel
<neggles>
duke2: heh, I doubt you will have much luck getting intel graphics drivers with QSV support running on openwrt, though it does look like a few people have done it
amaumene has quit [Quit: amaumene]
rsalvaterra has quit [Quit: rsalvaterra]
<neggles>
duke2: that said, you might be able to make it work if you build a custom image with a custom kernel config
<neggles>
why do you want hw encoding on openwrt?
rsalvaterra has joined #openwrt-devel
<duke2>
thanks for the answer. i want to run a jellyfin instance on it
<duke2>
which, from my understanding works based of the i915 driver? which openwrt has included?
<arnd>
neggles: ok, that's really interesting, so the cn9132 "chip" actually is same same package as cn9130 with one cpu die and one cp115 die inside, but has the extra two cp115 dies in separate packages.
<neggles>
duke2: ...why do you want to run jellyfin on openwrt?
<neggles>
arnd: yep! so that's... weird and fun
<arnd>
I think AMD did something similar when they reused their I/O die from the EPYC chips as the chipset for their high-end ryzen
nitroshift_ has joined #openwrt-devel
<neggles>
arnd: IIRC it was that the X570 PCH is the same die as the IO die inside the Ryzen 5000 AM4 CPUs
<arnd>
that sounds right, yes
<neggles>
I guess high-speed serdes is high-speed serdes
paper_ has quit [Ping timeout: 480 seconds]
<neggles>
duke2: by which I mean, what kind of system are you running OpenWRT on that you want to put jellyfin on it? a router is not a media server
PtitGNU_ has joined #openwrt-devel
slh_ has joined #openwrt-devel
fblaese_ has joined #openwrt-devel
karlp has joined #openwrt-devel
niyawe_ has joined #openwrt-devel
digitalcircuits has joined #openwrt-devel
digitalcircuits is now known as digitalcircuit
svanheule_ has joined #openwrt-devel
hexa- has quit [Ping timeout: 480 seconds]
Rondom_ has joined #openwrt-devel
Rondom is now known as Guest1241
<duke2>
it's a x86 processor, 4200u + 16gb ram
Rondom_ is now known as Rondom
svanheule has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
xdarklight has quit [Ping timeout: 480 seconds]
Guest1241 has quit [Ping timeout: 480 seconds]
nitroshift has quit [Ping timeout: 480 seconds]
slh64 has quit [Ping timeout: 480 seconds]
fblaese has quit [Ping timeout: 480 seconds]
PtitGNU has quit [Ping timeout: 480 seconds]
niyawe has quit [Ping timeout: 480 seconds]
oftc has joined #openwrt-devel
srslypascal has joined #openwrt-devel
<neggles>
i smell a netsplit
<duke2>
netsplit or whhat :x
oftc is now known as Guest1242
<neggles>
duke2: but are you intending to use it as a router, or as a media server?
<neggles>
i am afraid you're going to say "both"
<duke2>
haha
Guest1242 is now known as xdarklight
<neggles>
those things are not things you do in the same place
<neggles>
(at least not without getting VMs and/or containers involved)
<duke2>
it's not connected to the internet, it's just a gateway to seperate all the android crap + smart tvs from my actual workstations
<duke2>
and because all other gpu's are in use in the vm's/wormstations i thought i could use the hd4400 for that
<neggles>
okay, that's, less terrible
Habbie has joined #openwrt-devel
<neggles>
the bad news is that a broadwell-U chip's QSV decoder/encoder... kind of sucks
<neggles>
no HEVC support at all :(
<duke2>
h264 should do it too?
<neggles>
it will do non-HDR h.264 yes but it can't even decode HEVC so if you throw any HEVC content at it, you're gonna have a bad time
<duke2>
kinda forgot about the other direction :P
<stintel>
at this point if it's for media I would only get something that does HEVC and AV1
<neggles>
you need kaby lake or newer to get proper HEVC support with 10-bit
<neggles>
skylake gets you 8-bit HEVC and partial decode accel for 10-bit
<neggles>
none of the intel chips do AV1 yet
Tapper has joined #openwrt-devel
<neggles>
but the overwhelming majority of ...linux ISOs... are HEVC still anyway
<neggles>
HEVC/AVC*
danitool has joined #openwrt-devel
<neggles>
duke2: in any case, while you can probably get it to work without a huge amount of hassle - custom image ought to do it - it will probably not be worth the effort, especially not when you can just put debian/whatever on the thing and drop in some iptables/nftables rules (assuming you don't have anything particularly heinous in terms of network
<neggles>
config)
lemmi has joined #openwrt-devel
<neggles>
ugh i think this stupid QCA SoC is 1.8V I/O
Shiz has joined #openwrt-devel
<neggles>
booooooooooo
Tapper has quit [Read error: Connection reset by peer]
<duke2>
hm, i'm using a wifi card on it and i really like the openwrt performance with it for a vr headset
Tapper has joined #openwrt-devel
<duke2>
was kind of hard to get 600 mbit/s stable
<duke2>
i'm probably better of adding another gpu to my server and passthrough a small gpu to it for the media server
paper_ has joined #openwrt-devel
<neggles>
yeah, that poor little ULV dual-core is not going to be a great media server
hexa- has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<neggles>
it does look like if you have the i965 drivers and all the other video support stuff installed, you should be able to make the VAAPI driver work, but you'll probably run into musl libc incompatibilities
<neggles>
just because you *can*, doesn't mean you *should*, though :P
<rsalvaterra>
neggles: Tiger Lake does AV1.
<duke2>
yeah, considering the lack of newer codec support, i probably shouldn't
<neggles>
rsalvaterra: does it? i thought only gen12 had AV1 decode
<duke2>
neggles: thanks for leading me into the right direction / saving me a lot of time :)
<rsalvaterra>
neggles: I'd really love to move to arm64 hardware for my LibreELEC media player. I want something with fully open drivers and support for 4k HDR AV1, but I believe it's a bit early for that. I'd love to be proven wrong, though. :)
<neggles>
rsalvaterra: RK3588?
<neggles>
might be a while before that has properly open drivers (depending on your definition of open)
<neggles>
duke2: no problem :) if *I* won't learn from my past mistakes at least someone else can :P
<rsalvaterra>
That's a nice SoC, yes. But I want some officially supported box based on it.
<rsalvaterra>
Has anyone ever managed to get PulseAudio to do the isochronous remote playback thing? I remember reading about it somewhere, years ago. Could be used to, say, get a RPi to drive rear speakers in sync with the rest of the system wirelessly.
<duke2>
are those SoC gpu's fast enough to encode videos? (running a media server on it?)
<neggles>
duke2: oh yes
Tapper has quit [Read error: Connection reset by peer]
<neggles>
especially the shiny new rockchips
<neggles>
but it varies from SoC to SoC, and the quality of the output varies as well
<stintel>
yesterday I linked firewall zones to my network zones and then the memory usage started increasing
<stintel>
on the snic10e
<arnd>
there is usually a separate video encoder on the soc, it doesn't use the normal GPU
<neggles>
stintel: well that doesn't make any dang sense
<duke2>
might be an alternative to adding a gpu, which costs idle more power than the whole SoC :p
<neggles>
and yes, arnd is right, technically the video encode/decode is not part of the GPU
<neggles>
it's a separate "VPU" block, same as with NVENC on an nVidia GPU - separate, dedicated silicon
<neggles>
arnd: the rockchip VPU has mainline support though (in staging, at least, but also decode only)
<arnd>
https://linux-sunxi.org/Cedrus shows support for the video code on allwinner chips, they have a ton of progress but encoding is only supported on the older chips at the moment
<neggles>
if you want encode/decode you'll end up having to use vendor-provided android BSPs, probably, or find a mediatek chip
<arnd>
neggles: ah good, I missed that going in
<neggles>
drivers/staging/media/rkvdec
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
danitool has joined #openwrt-devel
<hgl>
any idea why my openwrt 21.02.1 returns /sda2 from `cat /sys/block/loop0/loop/backing_file`, without the /dev?
<Grommish>
If I'm using PKG_SOURCE_URL to pull down a PKG_SOURCE but need to change the filename is uses in dl/, is there a PKG_ for it?
<hgl>
nbd, in this line (https://git.openwrt.org/?p=project/fstools.git;a=blob;f=libfstools/rootdisk.c;h=9f2317f14e8d8f12c71b30944138d7a6c877b406;hb=HEAD#l186), rootdev should be something like /dev/sda2 right? however my /sys/block/loop0/loop/backing_file reports the backing file is /sda2, any idea where the discrepancy comes from? My openwrt 21.02.1 works without issues, I'm just trying to understand how things work. (git blame says you're the last
<hgl>
author of that line)
<stintel>
so I was actually looking into ordering some rockpi hardware
<Grommish>
aparcar: ping
<stintel>
is there a combo of sbc + poe hat in a nice case? looking for alternatives for the OC200
<aparcar>
Grommish: pong
mitome has joined #openwrt-devel
<aparcar>
mangix: second pong btw
<Guest9490>
test
mitome has quit []
<Grommish>
aparcar: I'm wanting to pul ldown the rust tarball instead of clone the git repo. The filename is simply "v1.58.1.tar.gz", which is how it's stored in dl/.. Is there a way to get the build system to save it as a separate filename?
<aparcar>
separate as in rust-v1.58.1.tar.gz for example?
<Grommish>
aparcar: Yes, so it doesn't just leave it as dl/v1.58.1.tar.gz hehe
<Grommish>
PKG_SOURCE_SUBDIR takes care of it if I'm cloning the git, but...
<aparcar>
download.mk should give it a nice name by default
<stintel>
but I think libs/openpgm/Makefile could do what you need
<Grommish>
aparcar: Ok, I was being dense about using the codeload URI, however, it's still an issue for anyone not using github I suppose
mitome has joined #openwrt-devel
<aparcar>
Grommish: in those cases you can define the folder manually if I recall correctly, if you're keen to know how I can do some searching later
<Grommish>
aparcar: Nah, not worth the deep dig.. I know you can use PKG_SOURCE_SUBDIR to define the final filename if I use git to clone the repo, but codeload presented a proper filename
jow_laptop has joined #openwrt-devel
jow_laptop is now known as jow
eduardo010174 has joined #openwrt-devel
mitome_ has joined #openwrt-devel
mitome_ has quit [Remote host closed the connection]
<neggles>
arnd / lemmi: the Armada 8040 is 28nm / 2.0GHz, the CN9130 is 16nm and 2.2GHz
<neggles>
so there IS an actual difference :P
robimarko has joined #openwrt-devel
<lemmi>
and memory bus is twice as wide
<robimarko>
CN9130 is the Armada 7040 successor
<neggles>
armada 8040 successor*
<robimarko>
Its obviously refined
<robimarko>
And memory controller has been replaced competely
<neggles>
they dumped octeon peripherals into the thing
<robimarko>
9130 is not 8040 replacement, its 7040
<robimarko>
It has the exact number of SERDES lanes and combinations
<neggles>
the press release from the 9130's release says it is the 8040 replacement
<robimarko>
9131/2 etc can be seen as 8040 replacement
<neggles>
9130/9131/9132 are the same SoC with extra external IO chips
<robimarko>
Yeah
<robimarko>
They just have additional CP115-s
<neggles>
we had this discussion slightly earlier :P it's weird, but good
wingman2 has joined #openwrt-devel
<robimarko>
Forget what the press release states, you cant replace the 8040 with 50% of its SERDES lanees
<neggles>
well you can when you bolt two 88F8215s on
<robimarko>
But they consolidated them both into a cheap to expand series
<robimarko>
And like you said, slapped on various Octeon stuff
<robimarko>
But they dont really have anything to do with Octeon TX (The original one)
<neggles>
if the 88F8215 "coprocessors" are essentially just octeon TX without the actual processor part (so just the peripherals/accelerators) that would not surprise me
<robimarko>
They are just I/O dies
<neggles>
not the same die, but the same IP
<neggles>
and yeah, the original ThunderX cores are bad and best left dead
<robimarko>
CP115 is just the updated CP110
<robimarko>
They dont seem to have anything to do with Octeons at all
<neggles>
the packet processors inside them are almost a carbon copy of the packet processors in an octeon 8000
<neggles>
but shinier and newer
<robimarko>
That wouldnt surprise me at all
<robimarko>
BTW, have you ever seen the MoChi interface used?
<lemmi>
ah mochi it's calles. not moca^^
<robimarko>
I am stupid, thats the interface that the additional CP115 as attached via
<neggles>
seems Marvell bought Cavium for the stuff wrapped around the octeon, not the octeon itself which is not really surprising
<robimarko>
Well Cavium had good IP
<robimarko>
Its just that their cores were crap
<neggles>
MIPS is dead/dying, mostly; ThunderX bad, ThunderX2 good but not any better than an A72, ThunderX3 looked promising but
<robimarko>
I doubt that there will ever be TX3
<neggles>
oh no it's quite dead, never made it out of ES stages
<robimarko>
Marvell has axed that for sure
<neggles>
the 88F8215 is kind of a modernized NitroX in some ways
<neggles>
cavium have come full circle, from external accelerator to SoC to external accelerator again :P
<robimarko>
Have you seen the big TX2 SoC-s in the wild?
<neggles>
yep!
<neggles>
Sophos' XGS appliances
<neggles>
XGS 2100 has a 16-core Octeon TX2
<robimarko>
Oh nice
<robimarko>
The only thing I ever saw was a press PDF from somebody pitching us storage appliances I think
<robimarko>
And they also used the 16 core TX2
<neggles>
all of the XGS appliances are a ryzen embedded + an octeon TX2
<neggles>
the small ones use a CN9130, the bigger ones use the various big TX2s
<stintel>
pricy too :P
<neggles>
sophoses are nowhere near as expensive as they appear.
<robimarko>
Well they aint really cheap also
<neggles>
the hardware's free if you buy one of their two 3-year license bundles
<neggles>
the cheaper one works out at somewhat cheaper than the bare hardware
<neggles>
sophos pricing is intensely frustrating though because unless you're a reseller like the company i work for, you're going to have *no clue* how much you expect to actually pay
<robimarko>
I really hate those contact us prices
<neggles>
the octeon is used for TLS inspection, forwarding acceleration, DPI, zero-day protection, and also *as the NIC*
mirko has joined #openwrt-devel
PtitGNU_ is now known as PtitGNU
PtitGNU has quit [Quit: Quassel terminated!]
PtitGNU has joined #openwrt-devel
<neggles>
robimarko: yeah, me too T_T
<neggles>
FWIW, the pricing is set by sophos, plus whatever margin the reseller drops on, so it's fairly consistent at least
<wingman2>
Hi everyone.
<wingman2>
So i was looking into trying to work on a luci app and get it pulled.
<robimarko>
Yeah, but having no reference price publicly
<robimarko>
To me its like contact us, let us scope you and decide what to pay
<neggles>
robimarko: there are quite a few resellers with public pricing, and in this case it's not a let us scope you (unless you have a shady reseller) but
<robimarko>
I get it, but we have been burned or almost burned by reseller only stuff before
<neggles>
yeah
<robimarko>
I honestly couldnt belive the price difference
<neggles>
fwiw, XGS 87W is AU$404 and XGS 2100 is AU$1823 (buy price for a mid-tier reseller)
<robimarko>
neggles: Those seem reasonable actually
<neggles>
robimarko: that's without licensing, but three years of their "standard protection" bundle comes out to within $50 of that price, and comes with the hardware free
<robimarko>
Thats reasonable
<neggles>
but yeah enterprise hardware pricing is all BS and lies. especially cisco. we have a standing no-questions-asked discount on everything cisco sells that varies from 45-65%
<neggles>
and if an order is over $10-15k or so, well, recently we had a $200k sale where the average discount off sticker price was 73%
<robimarko>
That is where my stance stems from
<robimarko>
Cisco and the others
<neggles>
Dell likes to do it the other way around, amusingly
minimal has joined #openwrt-devel
<neggles>
you give them your spec, they quote you, and then you tell them what the quote needs to come down to for you to buy it
<stintel>
:P
<neggles>
seriously, i got a $70k order dropped to $50k by agreeing to send a PO within 24h if they could hit that target
<robimarko>
That seems like a quite unique way
<neggles>
the other secret with Dell is to always buy things in december.
<stintel>
wingman2: I think if you look at the LuCI apps available in its repo, the project seems to be very willing to accept contributions
<stintel>
granted the review comments are addressed properly :)
<neggles>
robimarko: it does help make it feel less like "we think you can afford it, so we're giving you less of a discount"
<neggles>
got four entire EPYC 7502P servers out of that deal
<robimarko>
Yeah, seems more like a negotiation than just a quote
<neggles>
"deal registration" is always a negotiation - the reg itself serves two purposes, if you're the reseller who registers the deal, dell won't talk to anyone else for that particular customer/order
<neggles>
the other purpose being allowing you to negotiate
<wingman2>
stintel: just clarifying you mean openwrt right and not that fork that i posted a link to?
<neggles>
wingman2: he does, yes :) for the immediate future you can always host your own opkg repo on github though
<neggles>
robimarko: then you get the fun game of playing your two vendors off against each other to see who wins :P went back and forth with mellanox a few times on that same dell deal, mellanox $16k, dell $15k, mellanox $13k, dell $12k, mellanox decided they were done playing and came in at $9k
bluse-blue[m] has joined #openwrt-devel
<stintel>
:)
<neggles>
dell straight-up told me to buy the mellanoxes :P
<stintel>
and private persons / one man companies will rarely get such prices :(
<neggles>
that depends on how much the sticker price of the gear you want to buy is, and whether you make friends with a reseller
<stintel>
anyone know what's up with dslreports.com's speedtest? it's weeks that I am unable to do a proper test as I cannot reach all of their servers
<robimarko>
Basically the sticker price is nothing more than a really rough starting point
<neggles>
enterprise hardware sticker prices are useful for one thing only: comparing rough price differences between vendors
<neggles>
as a general rule, take whatever public price you can find, cut it in half
<neggles>
and if you go to a small reseller like us, well, I've gotten a $13k sticker server for a 3-man business cut down to $6500
<neggles>
if you make friends with a bigger one, they can tack you on to another customer's big order to get the same discount they're getting
<neggles>
but oh my god, none of this should be necessary, and i hate it
<neggles>
though, stintel, we just became a reseller partner of the local huawei enterprise hardware distributor :D
<neggles>
anyway i'm talking too much about off-topic things again which means it is time to sleep, sorry >.<
<stintel>
neggles: Huawei has some nice hardware and their prices are not crazy
<stintel>
but nobody wants to use it :P
<neggles>
I am quite happy to use their stuff if it can do the job and is reasonably priced, but once again no public pricing
<neggles>
should have price list access in the next few days, and I am lead to believe they've got some very nice NFR/internal use only discounts available
<stintel>
I've done a freelance project once for my supplier, one of the owners is an ex classmate, I'm pretty sure I'm getting OK prices from them ;)
<neggles>
i'm sure you are, but that doesn't help *me* ;P
<robimarko>
It would be interesting to see the prices for their IPQ807x AP-s
<robimarko>
Cause they have some really good HW
<robimarko>
But they are either unobtanium here or no prices are publiuc
robimarko has quit [Remote host closed the connection]
pavlix has joined #openwrt-devel
<stintel>
I have the AP7060DN
<stintel>
8x8 5GHz 4x4 2.4GHz 10GbE uplink. the specs are quite awesome, too bad it's QCA
<arnd>
neggles: where do you see 88F8215 being related to NitroX? From the .dts files in the kernel it appears to be using the exact same compatible="marvell,armada-7k-pp22" device in the a7040. in fact the entire .dtsi file is shared between cp110 and cp115, with macros abstracting the addressing differences.
<arnd>
obvious cn92xx and higher would be NitroX based because they are derived from OcteonTX, but as far as I can tell there has been zero reuse of components between the two product liens
<neggles>
arnd: I am referring to the accelerator IP inside the chip, which has Cavium/Octeon heritage AFAIK - and the Octeon started out as a NitroX crypto accelerator IP block with a CPU in it, it's just kinda funny
<arnd>
(oh, correction regarding what I said earlier: cn10 is evidently based on the OcteonTX CN8xxx/CN92xx/CN96xx/CN98xx line, not the Armada/CN91xx line)
<neggles>
but you may be right on the CP115
<neggles>
i haven't looked too closely at the drivers but there seems to be a lot of commonality in interfacing
<neggles>
and FWIW the sophoses with the CN9130 and the bigger ones with the CN83xx (turns out they're not CN92|6|8, my bad) run the same image on their ARMs
wingman2 has left #openwrt-devel [#openwrt-devel]
wingman2 has joined #openwrt-devel
<arnd>
neggles: the dts file tells me that the crypto engine in cn91xx/cp115 is compatible="inside-secure,safexcel-eip197b", same as a7040
<robimarko>
Well, EIP is just off the shelf IP
<robimarko>
Its rather common
<neggles>
yeah, the DTS tells you how the interface works
<neggles>
it doesn't tell you what you're actually passing back and forth
<wingman2>
I can't beleive I accidentaly left after posting that
<neggles>
wingman2: it did seem rather odd
<neggles>
(for the record, the Sophos XGS 2100/2300 use a CN8360, 3100 and 3300 use a CN8365, and the smaller models seem to use a CN9130)
<arnd>
I'm not surprised they run the same image, both SoC lines have been in mainline for a while, even if they need extra patches for cn8xxx, a generic kernel should just run in armada/cn91xx
<neggles>
same acceleration app as well
<robimarko>
Yeah, just supply the correct DTB and it should just work
<neggles>
give it 2 more years and i'll have a decommissioned XGS2100 I can poke around inside and compare :P
<neggles>
I wonder if there's a way to get a console on the OS running in the octeon...
<robimarko>
They have it for sure
<neggles>
I have found some suspicious shell scripts
<neggles>
robimarko: ...this has the toolchain in it
<neggles>
ok, sophos, you do you i guess
<robimarko>
Oh, if they have the TX SDK in it then its first
<neggles>
I'll have to dump this thing's firmware and poke around
<neggles>
probably nothing hugely useful, but who knows
<neggles>
hah, okay
<neggles>
all but two CPU cores are pinned to DPDK apps
<neggles>
arnd: i take it back, seems like you're right, there are three separate app startup scripts - armada, octtx, octtx2 - and the armada one has a different kernel module
<arnd>
ok
<arnd>
fwiw, my impression is that the three kernel drivers for octeon (drivers/crypto/marvell/octeontx, drivers/crypto/marvell/octeontx2, and drivers/crypto/marvell/octeontx/) should have really been the same driver to start with, the hardware is similar enough
<neggles>
*it's Octeons all the way down, people*
<arnd>
we recently discussed that 42e6f351dcb0 ("crypto: marvell - CRYPTO_DEV_OCTEONTX2_CPT should depend on ARCH_THUNDER2") was done in error as well, it should have depended on ARCH_THUNDER rather than ARCH_THUNDER2, as the latter is for Vulcan/ThunderX2 not Octeon
<arnd>
I even made a patch to rename CONFIG_ARCH_THUNDER to CONFIG_ARCH_OCTEON, but I need to resend that for inclusion
<aparcar>
jow: do you have an idea why those printf messages are not printed at all? It works for the warning when e.g. .config is outdated (that's where I stole the code from)
<f00b4r0>
in case anyone has already solved this: is there a way to make dropbear ssh client completely quiet (for use in scripts), i.e. prevent it from priting "caution" messages?
<aparcar>
rsalvaterra does a bunch of dropbear stuff
<dwmw2_gone>
My Fritzbox 7530 arrived. I'll plug it into the test VDSL line and try to get it working
SamantazFox__ is now known as SamantazFox
minimal has quit [Ping timeout: 480 seconds]
<rsalvaterra>
aparcar: A bunch of rejected stuff, though. :)
<rsalvaterra>
I carry some patches catering to my whims, yes.
<rsalvaterra>
f00b4r0: As far as making it silent, I've never investigated the possibility.
<svlobanov>
hi. which OS is used to build official images/snapshots/packages? I know, that ubuntu20.04 x86_64 is used for CI, but I could find info what is used for images/snapshots/packages