<hurricos>
Dare I try boot a kernel with symbols compmiled in?
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
minimal has quit []
spacewrench has quit [Remote host closed the connection]
spacewrench has joined #openwrt-devel
<Grommish>
Grrrr.. arm with vfp = musleabihf?
<hurricos>
hf? no
<hurricos>
Uhh
<hurricos>
I'm dumb
<hurricos>
yes
<hurricos>
it is hf
<Grommish>
Thanks.. I really wish ARM had standardized their stuff
<Grommish>
NEON = hf?
<Slimey>
lol hi
<Grommish>
Slimey: Hey hey
victhor has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
spacewrench has quit [Read error: Connection reset by peer]
spacewrench has joined #openwrt-devel
<Grommish>
Anyone know an ARM soft-float target offhand?
<slh>
kirkwood
<Grommish>
slh: Thanks!
<slh>
pretty much anything <ARMv7 (with the notable exception of the early generation RPi, those were untypically ARMv6 hardfloat)
<Grommish>
I need a non-hf arm target.. hmm
<Grommish>
kirkwood is coming up musleabihf
<Grommish>
Maybe just the device I picked
<slh>
hmm, I would have sworn that it's softfloat - but I never had one
<Grommish>
Which doesn't make any sense, so i guess my logic is wrong
<Grommish>
slh: Turns out it was both my logic AND the cluster that in ARM targets.. some use CPU_TYPE, some use CPU_SUBTYPE, some use FEATURES all to set hard-float or not
<Grommish>
It's crazy
<dwfreed>
yeah, the scattering of meaning there is kind of frustrating
<Grommish>
I think I've got most of it figured out, but every time I think that, something else throws a curve :D Ah well
<Grommish>
Is the forum being super slow the past few days for anyone else?
indy has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
danitool has joined #openwrt-devel
dangole has joined #openwrt-devel
rmilecki has joined #openwrt-devel
<karlp>
Grommish: soft float cortex-a is kinda odd, it's really just an abi choice, I don't know of any off the top of my head
<karlp>
optional hw on A9, might be able to find an impl, but what for? this is rust bringup?
<karlp>
arm soft existing is jsut legacy from debian trying to support armv4 and armv5 crap for way past their use by date with a single software image isn't it?
<karlp>
some of the SAMA5D3x's have neon but not vfp
<Grommish>
karlp: Yes, the ARM targets are spread to hell and back on how they define hf vs not.. CONFIG_CPU_TYPE, CONFIG_CPU_SUBTYPE, and FEATURES
<Grommish>
Right now, arm/armv7 should be supported.. arm9/arm11 should be supported under arm
<karlp>
you're going to try and support armv6 stuff then hey? have fun :)
<Grommish>
I just redirect to the correct tuple.. I stopped trying to create custom ones because of how often they change the format
<Grommish>
So, if OpenWrt reports it correct and rust-lang has an existing tuple, should be fine
<Grommish>
arm, armebv7r, armv5te, armv6, armv7, armv7a, armv7r, armv7s is what it shows
<Grommish>
Remember! I'm to naive to know better :p
<karlp>
"it" being what? openwrt?
<karlp>
or are those rust'soptions?
<Grommish>
those are the existing rust tuple archs for arm
<Grommish>
It even has a armv7_apple_ios tuple for some reason *shrug* some freebsd and android ones but most are musl/gnu
<karlp>
yeah, that's armv7s == armv7_apple_ios.
<Grommish>
I am having to figure out all the different ways OpenWrt targets define wanting a hf and it never seems to end
<karlp>
just say it's only hf, and let people who manage to find a hf target, _and_ want to run rust on it figure out the exception paths.
<Grommish>
I don't think I would ever get it accepted into packages if I did that
<\x>
do you have any idea on why ipq4019 doesnt want to work with pcie 1.1 devices?
<\x>
I tried running an mt7612 in it, it didnt start, same with a 4965agn and the only thing ciommon is they run pcie 1.1
<\x>
but I'll still try to replace that pcie reflock 0 ohm solder bridge to something of a higehr resistance, but it would be nice if you have any idea or is it a known issue?
tmn505 has quit [Remote host closed the connection]
<robimarko>
\x: Hi, unfortunatelly I dont remember a case of PCIe 1.1 not working
<robimarko>
I might have a 1.1 card to test at home
valku has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
<fda>
jow: when i flash an image by luici i get this message: https://pastebin.com/BVDQrAcJ beside that flashing works! this is only with avm7320, my other devices dont show this message. i cant say when it started, but that are months - maybe since i started with openwrt
<fda>
btw, the theme has only colors changed
minimal has joined #openwrt-devel
victhor has quit [Ping timeout: 480 seconds]
dangole has joined #openwrt-devel
victhor has joined #openwrt-devel
<fda>
i noticed the new "Storage usage" section on overview. Why "usage"? Or why not "Memory usage" but only "Memory"?
victhor has quit [Ping timeout: 480 seconds]
snh has joined #openwrt-devel
<Slimey>
hi
victhor has joined #openwrt-devel
<karlp>
Grommish: just fyi, node never supported mips in the past, but we still happily had node in packages for years
snh_ has quit [Ping timeout: 480 seconds]
<karlp>
so I don't see any reason there should be a problem with "rust on arm will only support arm targets thave support hard float at this point in time"
<jow>
until people come along and want to rewrite base services in rust :)
<jow>
in contrast to node it wants to be a systems language
<jow>
nbd: there's multiple reports about people upgrading hostapd-common in 21.02 and losing their wireless
<neggles>
Grommish: NEON =/= HF, annoyingly - NEON *is* hardware and *does* do FP, but it can't be used for regular old FP math. GCC also won't use it at all unless you specifically tell it to because it does ~things~ to subnormal numbers - not sure what rustc does. Might I suggest using just CPU_SUBTYPE, defaulting to softfloat, and maybe dropping in a PR
<neggles>
to fixup missing CPU_SUBTYPEs?
<neggles>
if you want a softfloat target, at91/sam9x
<jow>
the root cause is that they don't upgrade&restart wpad along with it
<neggles>
appears the mxs target and oxnas target are also softfloat CPUs
<jow>
we should probably consider adding EXTRA_DEPENDS to the various wpad, hostapd & wpa-supplicant flavors to depend on the specific version of the hostapd-common package
<karlp>
jow: people who want to rewrite base services can deal with that then? :) it would have to come into core at that point anyway, it doesn't seem like a big reason to try and hold it out?
<jow>
karlp: it was just a snarky remark, I don't care really. As you correclty pointed out it is no blocker
<karlp>
ok :)
<jow>
modern software ecosystems are increasingly becoming x86/arm only anyway
<jow>
portability is hard, let's go use node
<nbd>
the rust gcc codegen backend is making progress
<nbd>
once that's usable, i actually plan on looking into using rust for openwrt component development
<neggles>
it doesn't seem particularly hard to detect *most* current definitions of hardfloat; if (CPU_TYPE ~= "arm*j*") { hardfloat=1 } elseif (CPU_SUBTYPE ~= '*vfp*') { hardfloat=1 } else { hardfloat=0 }
spacewrench has joined #openwrt-devel
<karlp>
using jazelle to indicate hardfloat? cute :)
<neggles>
...oops
<neggles>
s/j/f
<neggles>
some targets are missing cpu_subtype despite being a VFP-equipped cortex; I'd argue the fix for that is to define CPU_SUBTYPE properly for those targets :P
<karlp>
I would personalyl err on the side of "if you're not on this single list of targets, you get hardfloat"
<karlp>
so that future stuff all works out of the box too.
<jow>
nbd: sounds good. Personally I won't bother looking until it supports mips
<nbd>
right, and we also have exotic targets like ARC
<neggles>
karlp: the problem is the assortment of A8/A9 chips which don't have HF
<nbd>
which are unlikely to get supported in rust without gcc backend
<neggles>
it's optional on those :/
<jow>
or MPC85xx, that one-off powerpc thing
<karlp>
neggles: as best I can tell, it was only optional on A9, and there's really very very very few that chose to not include it...
<neggles>
karlp: optional on A8 as well, and even when it's implemented, A8 uses "vfp-lite" - it can run all the instructions, but it takes 10x as many clocks as A9 VFP...
<neggles>
probably still faster than softfloat mind you.
<karlp>
that's the one where people argue back and forth abotu hand assembly soft float being faster or slower ithan vfplite in certain cases isn't it?
<nbd>
and i'm actually very interested in using rust for core stuff like ubus at some point
<karlp>
silly pixel peeping
<nbd>
for memory safety / security reasons
<neggles>
think so. also most future chips/targets are likely to be aarch64 where the whole thing is moot
<jow>
sure, it makes sense for that. I'd argue it also makes even more sense to start with things like uhttpd, rpcd etc.
<nbd>
and i think that being able to use serde for blobmsg would be really nice
<neggles>
afaik there are no 64-bit ARM A cores with no HF :P
<jow>
before converting stuff like ubus that *everyone* relies upon to run openwrt
<nbd>
i think step 1 is to make a blob/blobmsg crate for rust
<nbd>
then libubus
<nbd>
i'd prefer to do that with native rust code instead of just writing bindings
Gaspare has quit [Quit: Gaspare]
<jow>
bah, I hate this terminilogy
<jow>
cargo, crate, rust
tmn505 has joined #openwrt-devel
<nbd>
:)
victhor has quit [Ping timeout: 480 seconds]
<jow>
clippy
<neggles>
you could flip the logic, if (CPU_TYPE starts with arm and doesn't contain an f) { you get softfloat } else if (CPU_SUBTYPE is present and doesn't contain vfp) {you get softfloat} else {you get hardfloat, and your target's makefile needs an extra line added if that doesn't work}
indy has joined #openwrt-devel
<hurricos>
\x: check out your MSI settings
<neggles>
though the build system must already be making the softfloat/hardfloat call *somewhere* for existing packages, surely there's something reusable in there
<hurricos>
or try running the kernel with cmdline option pci=nomsi
victhor has joined #openwrt-devel
<\x>
hurricos: how do I do that? can I just add that on dts?
<\x>
[ 1.370804] qcom-pcie 40000000.pci: Phy link never came up
<\x>
:(
victhor has joined #openwrt-devel
Guest7149 has quit [Ping timeout: 480 seconds]
victhor has quit [Ping timeout: 480 seconds]
victhor has joined #openwrt-devel
victhor has quit [Ping timeout: 480 seconds]
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
<f00b4r0>
blogic: ping?
victhor has joined #openwrt-devel
<dwfreed>
f00b4r0: it's best to poke people with your actual question
noltari_ has quit [Ping timeout: 480 seconds]
Gaspare has joined #openwrt-devel
victhor_ has joined #openwrt-devel
victhor has quit [Ping timeout: 480 seconds]
fda- has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
victhor_ is now known as victhor
<fda->
jow: thx for quick "usage" removal!
Gaspare has quit [Quit: Gaspare]
Gaspare has joined #openwrt-devel
<fda->
luci error/stack track on flash: could it be a timeout? the old and slow avm7320 does un upload an image file: write to flash, could take more than 1 minute. and then the 1st start after flash takes 70-90 seconds due to overlay-fs rebuild
<hauke>
the build is failing since some time in build bot
<Habbie>
opkg install /..../netifd.ipk where /..../ is a network path
<Habbie>
never again
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
Borromini has quit [Quit: leaving]
<Habbie>
is there an official github mirror of netifd?
<rmilecki>
hauke: oh, wonderfu
<rmilecki>
thank you!
<rmilecki>
hauke: i didn't see that problem locally as I don't use CONFIG_BUILDBOT=y
<rmilecki>
hauke: if that fixes buildbot, please push that!
<hauke>
ok
<hauke>
rmilecki: does BCM4908 has no PCI(e) support?
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<rmilecki>
hauke: it has, I didn't develop PCIe driver changes to support BCM4908 yet
<rmilecki>
hauke: so I don't know how much sense it makes to have/remove "pcie" from features
<rmilecki>
hardware has such feature, it's just unsupported at the moment
<hauke>
ok
<hauke>
rmilecki: this script would activate the feature flag automatically when the kernel configuration option is set: scripts/target-metadata.pl
rmilecki has quit [Ping timeout: 480 seconds]
danitool has quit [Ping timeout: 480 seconds]
dedeckeh has quit [Remote host closed the connection]
<slh>
hauke: regarding PR#4036, DSA for ipq806x - it works reliably and stands on its own. for performance reasons the multi cpu-port PR is wanted, but PR#4036 is fully functional and there are no known issues (it just needs multi cpu-port support, to recover full speed); I'll respond the accordingly to the PR as well (tested on nbg6817 (ipq8065) and g10 (ipq8064)). the LED patch is kind of optional and
<slh>
afaik pending further upstream/ mainline changes
<hauke>
slh: getting the LED support accepted upstream is hard
<hauke>
thanks for the update
<slh>
yes, but ansuel is trying hard
<hauke>
yes
<slh>
we didn't have LED support so far, so that isn't a regression
<hauke>
ok that is good to know
<hauke>
Is the only regression the multi CPU port support?
<slh>
afaik, yes - that drops performance figures
<slh>
I've been running PR#4036 since ~april, and with the multi cpu-port patches (PR#4717) for about 2 months now on those two devices nbg6817/ g10 and slightly complex VLAN configurations. it works nicely
<slh>
fortunately ipq806x devices are rather uniform in this regard, all using qca8337 and behaving very similar, with relatively few special (DTS-) differences