<karlp>
probably making a new pr, rathr than push -f to the old branch?
<f00b4r0>
^
<karlp>
they're marked as a first time contributor
<karlp>
they closed the old ones at least, rather than leaving them dangling :)
<f00b4r0>
they have nfc, quite obviously
<karlp>
second one cleans up first one, third one fixes sob line.
<robimarko>
I blame Github for people not knowing how to fixup existing PR
<robimarko>
As they make it so easy to open or close one
<karlp>
who cares? the pr was closed already by the submitter.
<karlp>
do you get upset when people don't include the correct in-reply-to and msgid tags in email? it's the same thing.
<karlp>
or in this case, if they'd sent as v1, v2, v3 emails even correctly formatted, and threaded? would that make everyones' teeth whiter and take out the garbage for them?
KGB-2 has quit [Remote host closed the connection]
KGB-2 has joined #openwrt-devel
<mrkiko>
Obi-Wan: out of curiosity, is there a specific reason why we are not using the latest ath11k ipq8074 firmware? And was wondering if trying a new one can cause permanent issues to the board or something or if I may try
<f00b4r0>
stintel: good laugh this morning: I just got visionfive's tracking number for the device I received a month ago ;)
<stintel>
LOL
<f00b4r0>
in an email aptly titled "VisionFive 2 Shipping Notice"
<Znevna>
maybe you're getting an extra one
<Znevna>
:P
<f00b4r0>
no, the tracking is for the delivered one
<stintel>
> According to our shipper, your VisionFive 2 package has been suceesfully delivered.
<stintel>
same here :)
<\x>
is that the 1 FE + 1 GbE?
<stintel>
yeah :(
<stintel>
really looking forward to next gen risc-v stuff, the vf2 is almost fast enough to be usable as desktop
<Habbie>
like a pi3? or a 4?
nitroshift has joined #openwrt-devel
<nitroshift>
morning guys
<stintel>
iirc it was going to be more on Pi4 level
<stintel>
nitroshift: o/
<nitroshift>
stintel, o/
<stintel>
neighbour :)
<nitroshift>
hell yeah! :D
<stintel>
> SiFive's new core to succeed the Performance P550 will reportedly improve performance by 50% and the company says it outperform an Arm Cortex-A78.
<robimarko>
mrkiko: Until QCA finally makes regdb.bin public for IPQ8074 2.7 can be used on some boards only
<robimarko>
Those with newer BDF-s that have properly populated regulatory info
<mrkiko>
robimarko: thanks
<mrkiko>
robimarko: now, is the nbg7815 running openwrt master respecting regulatory domains ?
<robimarko>
mrkiko: I dont have that device, but it probably has a bit outdated and more restrictive regulatory rules in BDF than the current ones
<robimarko>
This is reason number 2 why I have been bothering QCA to make the damn regdb.bin public for all chipsets
<robimarko>
So you can update the regulatory rules without having to update the damn BDF, it took them 2-3 years to finally figure out that is crazy
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
<mrkiko>
robimarko: asking just to not "hurt" neightbour networks; and asking because sometimes experiencing some issues with Apple devices (that might not be related to firmware at all). In dmesg I can see messages like: at11k C000...peer not found xx:xx:xx......
<robimarko>
mrkiko: You are not gonna hurt the neighbors as it does respect regulatory info, its just that its mostly more restrictive than the current rules
<mrkiko>
robimarko: good, thanks
<Obi-Wan>
mrkiko: I guess the question was not for me?
<mrkiko>
Obi-Wan: oops, sorry - mistyped
<robimarko>
How does OpenWrt handle HW eMMC partitions currently?
<robimarko>
I am not really familiar with that
<stintel>
I don't think there's generic support for that
<stintel>
git grep -E 'mmcblk.?boot'
<stintel>
only mediatek/mt7623 has something related to it
<stintel>
I wanted to look into it also, but haven't found the time yet
<robimarko>
Thanks, I have a client asking questions about that but I have not had to deal with them so far
<dwfreed>
they exist, openwrt does not use them
<dwfreed>
you can see them as mmcblk*boot*
<robimarko>
Yeah, I know they exist but I did not use them so far
<robimarko>
I remember some discussions regarding trying to use them in OpenWrt so I wanted to know the current state
<robimarko>
Thanks
<robimarko>
dhewg: Can I poke at you regarding the VRX modem driver?
<neggles>
i am yet to see anything actually make use of mmc bootparts
<neggles>
the eMMC standard requires them to exist but only requires them to be 128KiB
<neggles>
and it's only mandatory from eMMC 4.1 on up
<dhewg>
robimarko: you can try, but jan would be the expert about the driver sources
<mrkiko>
and mmc gives me the impression of one of these things you can't play with very much - looking at the mmc tool it seems some things you can do are actually irreversible or something if I understood it right
<neggles>
correct
<neggles>
you can carve an eMMC up into multiple chunks/LUNs but it's a one-time process
<neggles>
and it's not mandatory to support it
<mrkiko>
wondering why they did it that way
<neggles>
there's a whole bunch of nice features in the eMMC spec, especially eMMC 5.1, but almost nothing is mandatory to implement and the things which are, are usually kneecapped
<dhewg>
I know about the pci patch, but I don't have the issue it's fixing. I don't think it's clear when exactly it's happening, might be a hw revision or something like that
<mrkiko>
neggles: and I guess that's true especially for router's emmcs - that you're not supposed to touch anyway :D
<neggles>
IMO, JEDEC want eMMC to have all the features eUFS has, but the manufacturers don't want things to be mandatory because that drives the price up
<neggles>
so you get a chicken-and-egg thing; manufacturers don't want to build in features nobody will use, but nobody can use the features because they can't count on them being there
<neggles>
and half the point of using eMMC is the ability to use whichever chip you can get your hands on that meets your capacity/speed/endurance requirements
<robimarko>
dhewg: Yeah, about the PCI patch
<robimarko>
I really, really dont like it
<neggles>
it's also rare for SoC BROMs to implement loading from emmc bootparts, for the same reason, and even when they *do* exist they're usually 4MB which is a bit crap.
<robimarko>
And I am not seeing why its required, if its searching for the specific PCI ID, just patch the driver
<neggles>
may as well just boot from mmcblk0@64s... 1-bit mmc mode is not significantly harder to implement than bootpart mode
<mrkiko>
neggles: infact, I have yet to see a device with emmc but no spi flash to boot from :D
<neggles>
oh there's plenty
<neggles>
RK356x devices, bunch of allwinners
<mrkiko>
neggles: plenty of devices with emmc only ?
<neggles>
yup
<neggles>
Soquartz for example
<neggles>
and even the quartz64s with SPI come with them blank
<dhewg>
robimarko: yeah, it's not a beauty by far ;) And maybe your suggestion works, but I still think jan is more competent in that area, so let him try that (noticed the mail)
<mrkiko>
neggles: and in that case the bootrom should implement something or simply the flash isn't easily visible from kernel ?
<dhewg>
he's got testers that are affected anyway
<neggles>
mrkiko: most SoCs released in the last several years - at least ones i've touched/looked at - are capable of booting from SPI NOR, SPI NAND, SD card, or MMC, usually with a handful of different orders configurable via bootselect straps and/or eFuses
<neggles>
thing is, if you can boot from an SD card, you can boot from eMMC...
<robimarko>
dhewg: My gripe is that we need to keep it pretty much forever so
nixuser has joined #openwrt-devel
<dhewg>
I think that's given
<neggles>
e.g. rk35xx chips will look for their TPL at offset 0x8000 into the eMMC/SD card
<dhewg>
I don't have details on how the hw works, does is it possible that the vrx chip acts differently with another pci id?
<robimarko>
dhewg: No idea, that is what I asked basically
<dhewg>
It may be a avm custom vrx chip too
<robimarko>
Cause, if changing the root device PCI ID "fixes" it
<neggles>
mrkiko: oh, right - the quartz64 SPI flash just shows up as /dev/mtd0, but from factory it's blank
<robimarko>
Then you can just patch the driver to look for another PCI ID
<dhewg>
yeah maybe, but there's also a firmware that might play a role, and we can't change that
<dhewg>
assuming binary fw patching is a no-go
<neggles>
binpatch all the things!
<neggles>
(probably don't binpatch all the things)
<neggles>
usually the BROM search order goes SPI NAND -> SPI NOR -> eMMC -> SD -> usb downloader mode
<mrkiko>
neggles: but you're clearly referring to allwinner-style bootroms or so, I've never seen a so-friendly router bootrom
<neggles>
it depends; there's usually a pin or two on the SoC that control boot options/order, and usually eFuses to lock it down even furhter
<mrkiko>
neggles: got it
<neggles>
usually qcom router SoCs are locked down to "whatever the manufacturer ended up using"
<neggles>
the NXP layerscape chips have more options than you can count...
<mrkiko>
neggles: so in reality, the capabilities would be there but not accessible and then you end up having to solder uart and so on
<neggles>
I mean, usually you only have one real option anyway, whatever's been soldered to the board
<robimarko>
QCA SoC-s boot from whatever is set by the bootstrap pins
<neggles>
do the router SoCs have an equivalent of EDL mode? 🤔
<robimarko>
Yes
<robimarko>
However, bootstrap must be set to USB mode
<robimarko>
Or SBL needs to be corrupted
<neggles>
IIRC once you've set up secure boot it's all moot anyway, part of that is usually blowing efuses to force exactly one boot option
<robimarko>
USB mode should still work as long as SBL is corrupt
<robimarko>
But, it wont work if for example U-boot is corrupted
<robimarko>
And you need the original signed binaries off course
<robimarko>
Plus QSahara etc
nitroshift has quit [Remote host closed the connection]
nitroshift has joined #openwrt-devel
<mrkiko>
you need original signed binaries for qsee & friends, but u-boot isn't signed for example in ipq8007x or am I wrong?
<robimarko>
You need signed binaries only if secure boot is enabled
<mrkiko>
ah, ok
<robimarko>
Otherwise you can use use the default prebuilt ones
<robimarko>
And U-boot is signed if secure boot is enabled
<robimarko>
SBL verifies it
<mrkiko>
and what's the role of QSEE in general? I know is secure execution environ,ment or something, but I never understood if it stays somehow resident or not when openwrt is running
<robimarko>
Its TrustZone implementation and its always running
<mrkiko>
is this the case even in ipq4019 ?
<robimarko>
Yes
<mrkiko>
uh - didn't know that. But guess we have no driver for that and so talking with it is not as easy at the moment
<robimarko>
You are talking with it
<mrkiko>
or does it work via SMC or something
<\x>
neggles: hah, I know that sed line
<robimarko>
Via SCM
<robimarko>
On ARMv8 QCA SoC-s QSEE/TZ provides PSCI as well
<robimarko>
It does quite a lot of things
<mrkiko>
so they covered part of ATF spec via their own stuff in a sense. What do we talk with QSEE for ? to understand it's scope in system architecture
<robimarko>
For everything that is "secure"
<neggles>
\x: 😆
<robimarko>
ATF isnt a spec
<robimarko>
You can provide PSCI however you want, even via U-boot directly
<neggles>
qcom SoCs are constantly lying to you fwiw
<robimarko>
Regarding what?
<neggles>
well, maybe not all of them. but ye olde hypervisor
<robimarko>
Now they have a fancy new one called Gunyah
<neggles>
"you don't have low-level hardware access and you never will" - qualcomm
<mrkiko>
robimarko: ok, but in "typcal" openwrt usage, I guess the services we use the most are crypto related. Or do we use it also to access eth/wifi phys or something?
<neggles>
"we provide the illusion of low-level hardware access"
<\x>
you can say the same to most cpu manufacturers
<robimarko>
mrkiko: Not really
<\x>
Intel ME, AMD PSP, ARM TZ
<\x>
wew
<neggles>
eh not really
<neggles>
those don't intercept peripherals and for the most part can be disabled or shoved out of the way
<robimarko>
In theory all of those should be optional
<\x>
AMD one will never be optional, an ARM chip handles memory and pcie training so when x86 comes out of reset, no cache as ram happens, its just yeah, memory and pcie is ready
<\x>
so theres no way you can remove that hehe
<neggles>
no, but you don't have to interact with it after it's done setting things up
<robimarko>
ATF is getting damn hard to ignore though
<neggles>
qcom uses their hypervisor nonsense to present semi-standardized MMIO interfaces to hardware/peripherals, at least in android SoCs
<neggles>
(and to stop you from being able to read the bootrom)
<robimarko>
I would say they have a lite version of that on router SoC-s
<robimarko>
But its far from smartphone SoC-s
<neggles>
...and to stop you from working out that HEXAGON, SDM, and the GPU are *not* behind the hypervisor and have full unrestricted unmonitorable access to the entire physical memory map
<neggles>
~you should be afraid of the modem in your phone~
<robimarko>
Well, there arent really alternatives
<neggles>
robimarko: it's far from the smartphone SoCs *so far*
<mrkiko>
eheh yes; but I guess also a bug in ath11k firmware can simply corrupt the memory of my nbg7815 all the way ...
<\x>
yeah ril is whats stopping a lot of those msmxxxx-mainline thing to be usable
<robimarko>
mrkiko: Nope
<robimarko>
Its living in a carved out reserved memory
<robimarko>
neggles: So far they did not bother to carry over a lot of relatively old smartphone things
<mrkiko>
robimarko: oh! Nice to know. They kinda implemented an IOMMU in a sense
<robimarko>
Probably to keep them cheap
<neggles>
also because they don't have to hide widevine keys
<robimarko>
mrkiko: They did not implement anything, its just a kernel feature
<neggles>
the SDX in your average qcom smartphone runs its own I Can't Believe It's Not Linux operating system, is directly exposed to the public internet, and people quite regularly report RCEs on the thing; it is quite possible to remotely exploit an SDX in a persistent fashion that's nearly undetectable, and will not be wiped on a factory reset of the
<neggles>
device...
<robimarko>
Though, I guess it could still try and use more RAM than mapped
<neggles>
(this is why apple keeps the SDX behind a dedicated IOMMU in their devices)
<mrkiko>
robimarko: it's a kernel feature but I guess there should be some hw enforcement to make it effective
<robimarko>
mrkiko: Not really
<neggles>
just the usual buffer overflow prevention stuff
<robimarko>
Its kind of you carve out memory space and load it into
<robimarko>
It is ioremapped though so in theory it shouldnt be able to overlfow
<robimarko>
neggles: Yes, modems are scary
<neggles>
attempting to write outside that area should cause a panic/oops
<robimarko>
They remind me of Intel ME
<robimarko>
Completely autonomous with acess to everything
<neggles>
i'm much less scared of ME/PSP/etc
<robimarko>
Well, you shouldnt be
<neggles>
they're not directly attached to the internet
<robimarko>
Thats the catch, ME is
<neggles>
no it's not
<neggles>
it's on my LAN
<robimarko>
Fair point, but its not like you are always gonna use it behind a good firewall
<mrkiko>
and nothing stops it from performing outgoing connections if your PC can
<neggles>
no, but just being behind NAT is enough to stop bots enumerating things
<neggles>
and the network-enabled features of ME are almost entirely disabled in non-vPro builds
<neggles>
plus there's always the HAP bit
<robimarko>
That is fine as long as you are controlling the network
<robimarko>
But you never used it in an airport or so?
<robimarko>
Those vPRO features are basically perfect for exploiting
<mrkiko>
It's mindboggling how many opportunities those things would give you if only they where free/open-source software. But clearly reality is different...
<mrkiko>
i.e.: in accessibility terms
<neggles>
robimarko: assuming vPro is enabled :P most consumer boards don't have it turned on
<neggles>
and vPro is only a significant risk if you have it and don't configure it
<robimarko>
neggles: There is still a lot, a lot of "business" notebooks with vPRO
<neggles>
mmhm, and that is why we configure it on all our clients' systems :)
<neggles>
all my vpro equipped systems are attached to a meshcentral instance i run (similar setup at work, just integrated with our RMM), mTLS authentication, no inbound connections accepted, blah blah
<robimarko>
Well, that still leaves plenty of those that are not configured
<neggles>
indeed
<neggles>
to be fair the default configuration for the past 7? ish? years is locked way the heck down
<robimarko>
That is counting that there isnt a nice CVE
<robimarko>
My point being that ME, modems and whatever crap is running autonomously all the time is scray
<neggles>
it's not optimal, no
<neggles>
mrkiko: fun fact: intel ME runs minix
<robimarko>
That just makes it worse
<neggles>
worse was the fact that they spent 8 years with every vPro-equipped system defaulting to "network enabled, network access enabled, username admin, password admin"
<robimarko>
Cause, why not
<neggles>
at least these days you have to physically touch the system to enable that stuff
<mrkiko>
neggles: ehehe yeah I knew
<neggles>
just... ugh. there's a reason the US DoD made intel put the HAP mode in there.
<neggles>
a CSME 12 source code leak would be cool :P
<neggles>
or whatever version it's up to now
<karlp>
re emmc bootparts, I know they're not well used in openwrt right now, emmc is moslty just "an sdcard" btu I'm using it for our new hardware to put uboot and uboot-env on bootparts,
<neggles>
speaking of cursed intel shit, have y'all seen MaxLinear's new router chips?
<karlp>
so the plain user partition is jsut data, I don't need any fat partitions or anything.
<mrkiko>
but my perspective on these things is that - most of modern hw has these things, so you should do your best to make it secure but you know in a sense it's built to be vulnerable to some people
<karlp>
but yeah, lots of people not using it because it's not commonly used...
<robimarko>
neggles: What amalgamation is MaxLinear up to now?=
<dhewg>
nbd: thx for the mt76 bump, on a sucky ipq4019 usb attached mt7921u adapter that close to doubled throughput, nice one!
<\x>
oooo
<\x>
i need to try that sometime dhewg
<nbd>
dhewg: cool!
<\x>
is VHT over 2.4GHz working on mt7921u
<dhewg>
PAGE_POOL eh
<\x>
need mt76 patched ei
<neggles>
well they bought The Artists Formerly Known As Lantiq off intel a little while back as you probably know
<stintel>
I was just building a new image for my eap615 APs :)
<neggles>
and they've got some shiny new router SoCs targeting wifi 7 / XGS-PON
<dhewg>
also took a leap of faith, mold linked image running live on primary router atm. but non-lto for now
<neggles>
which have four atom cores. as far as i can tell they're Goldmont
<stintel>
hmm, >800Mbps with my s21u connected to eap615 with latest mt76 bump - looks like the GbE is now going to become the bottleneck :P
<neggles>
i have an mt7921u usb stick which does 6ghz, only 6ghz device i have right now apart from the cambium AP and the Cursed Aerohive thanks to intel's BS
<neggles>
plugging it into my test NUC makes the ethernet flap...
<dhewg>
oh I bet a mt7921u performs better on anything not ipq40xx
<Znevna>
yay we have LEDs for mt7915, thank you, nbd :)
<neggles>
does current openwrt still do octeons
<stintel>
we need to track down a performance regression between 5.10 and 5.15
<neggles>
yes
<dhewg>
\x: looks simiar? ~24MB/s without -R, stable 20MB/s with from a client
<neggles>
stintel: oh?
<stintel>
neggles: actual network b/w dropped a lot
<neggles>
oof :/
<stintel>
ehr, s/b\/w/throughput/
<neggles>
i've got a xirrus XD2-240 here which is a dual core oct iii
<stintel>
seen it on snic10e and iirc Habbie saw it too on erlite
<neggles>
there's a huge number of them available 2nd hand for $30-40 right now
<\x>
so still so far only the mediatek addon cards/usb can do wifi 6e?
<Habbie>
stintel, yes
<neggles>
broadcom wifi, but it's minipcie cards, going to put two 4x4 7916AN cards into it if i can make it work
<neggles>
need to harass my cambium account manager for a gpl tarball
<jow>
nbd: a while ago you added bonding device support to netifd
<neggles>
stintel: hmm interesting. wonder if it's just oct+/oct2 or oct3 as well
<neggles>
guess i'll have to find out
<\x>
neggles just buy a thinkpad x200, three mini pcie slots, two fullsize, one half
<robimarko>
\x: QCA has 6E cards as well
<neggles>
\x: oh no no i've already done a cursed thing
<\x>
theyre like 20$ if you look hard enough
<robimarko>
No idea about availability, MTK is probably best bet
<neggles>
i put two MT7916DAN cards into an aerohive AP330, freescale P1020
<\x>
issue is that cpu is like dual core penryn
<jow>
nbd: the type name chosen for it is "bonding" which does not correspond to the kernel name ("bond") is not consistent with e.g. "bridge" either (which we don't call "bridging")
<\x>
but its not an issue for 1GbE
<jow>
nbd: would you mind renaming the type to just "bond" ?
<jow>
maybe coupled with a config fixup to change bonding to bond internally
<Borromini>
stintel: did you get mt7621 running reliably with 5.15?
<Borromini>
IIRC you were onto some PPP issues with 5.15 and mt7621?
csharper20051 has quit [Ping timeout: 480 seconds]
<Mangix>
rmilecki: ping
<stintel>
Borromini: ppe
<stintel>
Borromini: that's fixed
<rmilecki>
Mangix: i'm going to sleep, please ping me tomorrow
<Borromini>
stintel: alright, cool.
<Borromini>
hopefully someone bumps ramips to 5.15 so we can watch things break. All my MT7261 stuff tested fine on 5.15 except for the odd radio not coming up (there's fixes for that)
<stintel>
that pinned issue is becoming like a forum thread
<stintel>
lots of random reports of broken stuff
<stintel>
sigh
<Borromini>
which one?
<fda>
hey developers, you missed the new dropbear verison 3 months ago
<stintel>
I created a separate issue for the ppe thing and it was fixed within 2 weeks or so
<fda>
i think i had this some times: "Fix long standing incorrect compression size check. Dropbear (client or server) would erroneously exit with "bad packet, oversized decompressed" when receiving a compressed packet of exactly the maximum size."
<Borromini>
stintel: neat, other than that i didn't hear too many complaints about 5.15 on ramips. I haven't dared test my MT7620/MT7628 devices yet though :^)
<Borromini>
don't feel like whipping out serial
<stintel>
my EAP615-Wall and Unifi Switch Flex are running 5.15 also without issues
<fda>
Borromini: thx! there are so much PRs
<stintel>
Unifi 6 Lite not, I didn't get to flashing it while I was in Belgium
<Borromini>
stintel: yeah EAP615 worked fine, EAP235 needed a fixup for one of the radios not coming up.
<stintel>
and I rather not do it remote, at least not without being able to test locally first
<Borromini>
i hear ya.
<stintel>
Borromini: yeah that's a weird thing. the fix for 5.15 breaks things on 5.10
<Borromini>
ok :-/
<stintel>
so no matter what we do first, we introduce a regression that we need to fix later
<stintel>
this sucks
<Borromini>
so we drop 5.10 :^)
<Borromini>
#yolo
<stintel>
I'd be inclined to take the fix first, yes, as the plan is to drop 5.10 I'd say breaking 5.10 to fix 5.15 is favored
<fda>
fritzbox 7320 has still 5.10!
<Borromini>
the breakage will be limited to master no, so...
<Borromini>
there's something to be said for it
<fda>
the dropbear PR is really huge, i did not expect this by dropbear changelog
<stintel>
Borromini: let me look into merging those 2 PRs
<Borromini>
cool, thanks.
<Borromini>
fda: i think the Dropbear PR does some housekeeping as well in addition to bumping (housekeeping related to the bump though from what I can tell)
<Borromini>
gotta go
<stintel>
hmm
<stintel>
sleep() and delay() etc
<stintel>
probably better that an expert looks at this
<dhewg>
"some housekeeping"? have you looked at that thing?
<dhewg>
that PR is like a new arch for ssh
<Borromini>
dhewg: i am by no means an expert ;)
<Borromini>
and feel free to weigh in of course
<Borromini>
later guys
Borromini has quit [Quit: leaving]
groz has joined #openwrt-devel
<fda>
i think the "Use modern crypto only [BREAKS COMPATIBILITY]" option is a good idea
robimarko has quit [Quit: Leaving]
<fda>
but the scripting skills are beginner: dumb_stat() { ls -Lln "$1" | tr -s '\t ' ' ' ; } -- dumb_stat_owner() { dumb_stat "$1" | cut -d ' ' -f 3 ; } -- much easier ist the "stat" command: stat -c %U
hanetzer has quit [Quit: WeeChat 3.8]
<dhewg>
I don't doubt the PR works as-is, but there're so many things it'll take days to test it
<dhewg>
it should probably spit into bump with required changes and other additions
<dhewg>
just imagine the hord of pitchforks if ssh access breaks ;)
<slh>
dhewg: mt7921au (in STA mode) can do around 750-800 MBit/s on 5 GHz (on 6 GHz currently only half of that with mt76), using an ivy-bridge Intel c1037u
<dhewg>
nice, but I expected it to run far from it's potential on ipq40xx, that soc seems especially bad at usb thoughput