<dangole>
Grommish: congrats! this works on arm_cortex-a7_neon-vfpv4. draws some mandelbrot in ASCII art, looks cool ;)
<Grommish>
Woot! I built it with a Cortex-A9 target, but that's just a naming issue.. Yay! Ok.. So.. Now to figure out the rest of them and test the sf ARmv7
<Grommish>
dangole: Thank you so much for testing it
<dangole>
Grommish: i hope that it's really just naming. also be aware that this is full-features vfpv4. it may not work on vfpv3, or the d16 and/or fp16 variants.
<dangole>
Grommish: but never the less, it's a big step forward!
<Grommish>
dangole: "+v7,+vfp3,-d32,+thumb2,-neon" is what that Toolchain builds
<Grommish>
dangole: and "+v7,+thumb2,+soft-float,-neon" for the soft-float
<Grommish>
dangole: I can work on making it pick the correct vfp in the future though, I'm sure
minimal has quit [Quit: Leaving]
<dangole>
Grommish: we will need quite a bunch of hard-float variants for all the combinations of vfp3/4, d32/d16, fp32/fp16, with and without neon.... so better have some more people test this also esp. on mvebu/cortexa9 (ie. Linksys WRTxxxxAC devices)
<Grommish>
dangole: Yeah.. finding testing peeps is difficult
<dangole>
Grommish: for the WRT1900AC and WRT3200AC there should be plenty. @rsalvaterra for example ;)
<Grommish>
dangole: I may just build a HF with all the instructions and then selecitvely choose which one the target needs, but I;m still looking at how to potentially do that
<dangole>
Grommish: i guess the only good solution will be to introduce target tuples for each arch we build. see https://downloads.openwrt.org/snapshots/packages/ for the current list (each folder represents one arch)
<Grommish>
dangole: Wouldn't work
<Grommish>
dangole: It takes me 4-5 hours compile time for each toolchain.. It isn't feasible to do it for that
<dangole>
Grommish: i guess that's the price of using LLVM. Obviously you won't have to build it all locally, just make sure the tuples exist and let the buildbots do their job.
<dangole>
Grommish: we also build GCC for each of them...
<Grommish>
dangole: I don't have access to them, so I am doing everything locally :) And that's ok, but if you do it for "each target", then every time OpenWrt adds a new target tree, rust had to be updated
<dangole>
Grommish: and to not make the buildbots explode we can out-source the Rust toolchain just like we did for the eBPF toolchain (also LLVM-based, similar build-time...)
<Grommish>
dangole: I'll keep poking at it and see what I can find though
<Grommish>
If I can limit to an arch, then I will.. I should be able to
<dangole>
Grommish: you don't need access to them. and of course, every time we add a new CPU subtype (unlikely to happen for 32-bit ARM), some things need to be updated. that's the reality.
<dangole>
Grommish: what I'm trying to say is: once the tuples are in all in place and correct (and that can be reviewed by human), we can merge the PR and then buildbots will pick it up
<dangole>
Grommish: you can try to go for the minimum common feature set of all ARMv7 with some kind of hardfloat, but that will be very limited and esp. if you include the older ARMv7 SoCs we support, there may not be much overlap.
<Grommish>
dangole: Actually, I should be able to add all the instructions and then selectively enable them on package compile
<Grommish>
dangole: But I don't know what that might do to things like.. size
<dangole>
Grommish: that'd be great. if it's just the size of the toolchain, then never mind ;)
<Grommish>
dangole: But since its' 533MB for the host install and 44mb for each target, size isn't an issue
<dangole>
Grommish: yeah, that's quite moderate for what it is
<Grommish>
dangole: I'll go back to digging and see what I can find.. vfp, vfp3, vfpv3-d16, neon, neon-vfp4.. Which did I miss?
<dangole>
Grommish: looks complete. 'arm1176jzf-s_vfp' is ARMv6 (not ARMv7), so that's again a whole different story. (that's old RasbPi 1)
<Grommish>
dangole: I think I sent you a mesasge about the possibliy of adding a CONFIG_arm_v5 and CONFIG_arm_v6 flags similar to CONFIG_arm_v7
<Grommish>
I've got armv5 and armv6 native tuples to model off of
<dangole>
Grommish: ah yes. it's safe to assume of CONFIG_arm=y and CONFIG_arm_v7 is unset, then you are dealing with v5/v6 (which isn't a bit difference).
<dangole>
Grommish: kernel also only decides between v5/v6 on one hand and v7 on the other hand
<dangole>
Grommish: v5 can be neglected, that's really old sluggish things
<Grommish>
dangole: So, I need an arm, arm-hf, armv5/armv6, armv7/armv7-hf? Do the v5/v6 have SF/HF variants?
<Grommish>
PowerPC/PPC64 is looking more and more tempting :D
<dangole>
Grommish: what would just 'arm' be then?
<Grommish>
dangole: *shrug* I assumed there were legacy ARM devices prior to the v5/6/7
<Grommish>
dangole: I know nothing of ARM :)
<Grommish>
and not much more about Mips64
<dangole>
Grommish: nah, there are pre-v5 ARM CPUs, but those are mostly microcontrollers and not running openwrt
<dangole>
Grommish: for v6 we do have both, soft-float and hard-float (before mentioned 'arm1176jzf-s_vfp') targets
<Grommish>
dangole: Ok, so I don't need an arm-openwrt-linux-muslxxx tuple
<Grommish>
Or, I can set it to be the armv5/v6
<Grommish>
which will be easier I think
<dangole>
Grommish: v5 would basically be only xscale, and that's softfloat. never mind ARMv4, we got 'gemini' target, but i'd skip that for now...
<Grommish>
Actually.. I don't think I need to change any of the code.. It checks for Arm, then Armv7, then FEATURES fpu
<dangole>
Grommish: v5 is still in use, because of kirkwood, SheevaPlug and such, but also some home routers use that SoC.
<Grommish>
it'll leave it arm if it isn't CONFIG_arm_v7=y and it'll set muslgnueabihf if it has FEATURES:= fpu
<dangole>
Grommish: the difficulty is really just the different FPU implementations on ARMv7, all the mess with different numbers of registers, different version of FPU intruction set, plus NEON or non-NEON...
<Grommish>
So the Rpi1 should report as arm-openwrt-linux-muslgnueabihf
<dangole>
Grommish: yes. for Rpi1 that's true
<Grommish>
dangole: I built the IMX used it to build the float-test you ran.. it reported as armv7-openwrt-linux-muslgnueabihf
<Grommish>
dangole: So now it's figuring out various instruction sets, like you mentioned
floof58 has quit [Remote host closed the connection]
floof58 has joined #openwrt-devel
noltari_ has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
Thagabe has quit [Quit: Connection closed for inactivity]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<Grommish>
rsalvaterra: ping. Would you have a suggestion on which MPC85xx target I should target for.. PowerPC64 I guess?
<neggles>
Grommish: hello yes hi i can do that
<neggles>
oh dangole beat me to it
<Grommish>
neggles: I've got a question into the rust devs about enabling all of the instructions and then selectively disabling the ones aren't needed for a giving target at the package level
<neggles>
but toolchain-wise, it should be possible for you to build a single host toolchain that can build code for *any* of the targets
<Grommish>
neggles: If I can do something liek the abover, then I can just selectively enable what the target needs with CPU_SUBTYPE
<Grommish>
neggles: when the target pckage gets built on the far end.. the toolchain would allow for all of it
<Grommish>
I woul still separate hf and sf, though I don't think I technically _have_ to.
<Grommish>
Right now, everyone who has tested has reported successon the armv7_hf, though its set for vfp3 only
<Grommish>
Cortex A7/A9/15 so far
Thagabe has joined #openwrt-devel
<Grommish>
neggles: features: "+v7,+vfp3,-d32,+thumb2,-neon".to_string(), is what I built the current armv7_hf chain with
<Namidairo>
why is that -neon and +neon
<Grommish>
Because I'm just collecting flags at this point
<Grommish>
In order to later eliminate the un-needed ones
<Namidairo>
i think neon might not do much outside of some handwritten functions unless automatic vectorization is on
<Grommish>
I don't have answer yet for questions like: if I define +vfp3 and +vfp4 and -neon, do I need to explicitly define vfp4-neon
<Namidairo>
I also think it's sometimes slower depending on the case
<Grommish>
and I probably won't need them both.. I'm assuming the -neon is disabling the instructions, so if I default that on, the targets already call -neon I guess if they don't need it
<Grommish>
But, I know nothing about the arm arch, so it's all new to me :)
<Grommish>
neggles: I put the bare bins on that github repo BTW, some poeple were getting arch errors because of how ipk works
danitool has quit [Ping timeout: 480 seconds]
<neggles>
yeah opkg tuples are weird
<neggles>
Grommish: i'm just sorting out my local rust build env so i can test my theory before i go making proclaimations :P
nitroshift has joined #openwrt-devel
GNUmoon has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
dedeckeh has joined #openwrt-devel
<neggles>
Grommish: okay so a multi-target toolchain is a bit of a bitch, but it's quite doable
<neggles>
and, you shouldn't need to bother with specifying features= directly, just use `--target-cpu=$(CPU_TYPE)`
<Grommish>
neggles: Well, then I just need to enable the features in the toolchain and that should be easy enoug
<neggles>
the problem is that you need to have a musl version for each target arch
<Grommish>
neggles: and if you're right, then using the --target-cpu should pick the right features?
<neggles>
so this would only really work with a precompiled multitarget toolchain
<neggles>
yes'm
<neggles>
that's the point of --target-cpu :P
<Grommish>
I already break it down by target arch rather than target, so that's what I need, yes
<Grommish>
I need ALL of the possible instruction sets and just set them to be included in the toolchain that's built and just --target-cpu on the user-package
<neggles>
yeah that's what i am currently pegging all 24 cores of my buildbox making
<Grommish>
neggles: I won't even need to change the rust Makefile
<neggles>
though in retrospect i should've built a smaller number of targets to test a theory
<neggles>
but details
<Grommish>
neggles: That would be fantastic if it works out that way and solve a whole lotta issues
<neggles>
yeah you'd have to do an s/openwrt/unknown but
<neggles>
that hardly matters
<Grommish>
neggles: No i don't
<Grommish>
neggles: I upstream the tuples ;p
<neggles>
*why*
<neggles>
what is different about them?
<Grommish>
neggles: It means I don't have to play cross-table, and, it simplifies LLVM down the line
<Grommish>
It's easier to just upstream the tuples and be done with it, and makes me the maintainer for future changes that need to be done.. It's easier to do that than the OpenWrt packages sometimes
<Grommish>
a Toer 3 change takes almost no time to incorporate on a tuple no one else is aware of
<Grommish>
And, it means I can do whatever I like, like overloading a toolchain with available instructions
<Grommish>
because the native armv7_hf only uses vfp3
danitool has joined #openwrt-devel
<neggles>
I fail to see how using the mips64-openwrt-linux-musl tuple is any different to using mips64-unknown-linux-muslabi64 with `-C target-feature=+soft-float` ?
<eduardo010174>
Switzerland for a long time maintained total banking secrecy. Today, it's not like that anymore.
<aiyion>
oh nice, wireless appears to be working as well.
<aiyion>
Gotta say, adding this device is a lot more fun than the port of the onion omega was.
xback has joined #openwrt-devel
<xback>
ynezz: ping
<xback>
ynezz: I'm seeing in your staging tree that you're working on imx target
<xback>
ynezz: on Ventana boards, it looks like USB doesn't work anymore since the bump to kernel 5.10
<xback>
ynezz: does your target have usb? and if yes, do they function?. thanks
<ynezz>
xback: I can check it later, but IIRC it used to work
<ynezz>
but it's another good point for QA, should probably consider adding sata/usb/pcie on devices which allow that and test for it during runtime testing
sanjay has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
<aiyion>
I looked through the datasheet of the ec25-eux and am under the impression, it supports qmi.
<aiyion>
What I'd expect from the device would be to show up as usb device, create like 4 ttyUSB devices and be configurable from there.
<aiyion>
it does not register as usb device below /sys/kernel/debug/usb/devices though:
Rayyan_ has quit [Remote host closed the connection]
aparcar_ has quit [Remote host closed the connection]
_0x4a6f_ has quit [Remote host closed the connection]
aparcar has joined #openwrt-devel
_0x4a6f has joined #openwrt-devel
Rayyan has joined #openwrt-devel
Rayyan is now known as Guest44
Guest44 is now known as Rayyan
SherlockDomes has joined #openwrt-devel
<sanjay>
Is snapshot build recommended for Tplink Archer A6 v3. The one under releases seems to perform poorly on 5Ghz
tchebb has quit [Ping timeout: 480 seconds]
aparcar has quit [Remote host closed the connection]
_0x4a6f has quit [Remote host closed the connection]
Rayyan has quit [Remote host closed the connection]
sanjay has quit [Remote host closed the connection]
aparcar has joined #openwrt-devel
_0x4a6f has joined #openwrt-devel
Rayyan has joined #openwrt-devel
Rayyan is now known as Guest54
<hauke>
Pepes: I haven't send a message to openwrt-announce yesterday
<Pepes>
Yeah, I realized it once I posted it here. Mea culpa. I thought that the message should be mentioned in announce as well
sanjay has joined #openwrt-devel
sanjay has quit [Remote host closed the connection]
sanjay has joined #openwrt-devel
sanjay has quit [Remote host closed the connection]
arjun_ has joined #openwrt-devel
<arjun_>
Any ideas on how to make spi boot to fail. I need to trigger Tplink recovery page for Archer A6 v3
<aiyion>
What are my chances that there is/are one or more gpios controlling the lte modem?
Misanthropos has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
arjun_ has quit [Remote host closed the connection]
<enick_479>
jow: I want to learn more about ucode, do you have ideas for low hanging fruits on what shell for lua stuff to replace with it?
Guest54 is now known as Rayyan
Borromini has joined #openwrt-devel
SherlockDomes has quit [Ping timeout: 480 seconds]
<jow>
enick_479: the various rpcd exec plugins for example
<enick_479>
jow: thanks
Misanthropos has joined #openwrt-devel
cotequeiroz has quit [Remote host closed the connection]
<aiyion>
found it. theres a gpio to enable the device.
danitool has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
Borromini has joined #openwrt-devel
<aiyion>
how does one properly specify gpio-export defaultstates?
<aiyion>
currently the system boots in the wrong state
Lynx- has joined #openwrt-devel
<hurricos>
aiyion: gpio-hog
<hurricos>
though, I'm sorry. GPIO hog *completely* hogs the line
<hurricos>
that'
<hurricos>
... that's to say, you cannot alter it any further, I don't believe.
<hurricos>
For your use case (LTE modem that needs to stay up), it sounds like the right application.
<aiyion>
thanks hurricos
<hurricos>
If later there ends up being a device tree binding for that device you can always change it to actually use what the driver expects so the driver can bring the device into the right state / reset it if it needs to reset the device
<Lynx->
anyone care to test my CAKE bandwidth adaptation script?
<aiyion>
I'm not sure about the 'stay up'-part though;
<hurricos>
same way that's done with ethernet
<hurricos>
stay high, I meant.
<Lynx->
(For LTE, etc.)
<hurricos>
or stay low
<aiyion>
the vendor used scripts to restart it
<hurricos>
I see. If you need to reproduce that behavior -- changing the state of the GPIO away from what it's set to by the hog -- you won't be able to.
<aiyion>
Mhm, maybe there's no need to restart it
<hurricos>
fingers crossed. you may also consider looking around to see if there are already bindings for the reset line of LTE modems
<aiyion>
haven't found them yet ^^
<hurricos>
heheheh
<hurricos>
gpio-hog will do you fine.
<hurricos>
best of luck
<aiyion>
thank you.
<mangix>
is the latest release of 21.02 cut yet?
<dwfreed>
it's been tagged, but I believe builds are still running and it hasn't been announced yet
<aiyion>
hurricos: do you by any chance know, what "state_default" is good for?
cmonroe_ has joined #openwrt-devel
AtomiclyCursed has joined #openwrt-devel
<mangix>
philipp64: seems fine to me
dedeckeh has quit [Quit: Page closed]
<aiyion>
hurricos: hogging works fine, just configured the LTE modem :)
<Borromini>
Grommish: ping
<Grommish>
Borromini: pong
<Borromini>
still same link you'd like to test?
<Borromini>
i'm about to switch to my 'workstation' for irc
<Grommish>
Borromini: https://github.com/Itus-Shield/float_test .. you can grab your arch, though if your using armv7, you'll probably need to get the bare bin (by sf/hf) because ipk might throw an arch error
<Borromini>
what do you mean with sf/hf?
snh has quit [singleton.oftc.net coherence.oftc.net]
<Grommish>
Although with Armv7 in flux, I wouldn't worry about it at this point
<Grommish>
Borromini: Whether your target has an FPU
<Borromini>
ok
<Borromini>
i'll unpack the ipk then thanks
<Grommish>
Borromini: That works! I built it on an A9 target, so if you have one that reads as compatible you can jut intall the ipk
<Grommish>
but some folks had issues with opkg reporting an incompat arch
snh has joined #openwrt-devel
<Borromini>
ok yes i remember some ugliness being thrown at me yesterday on the CLI :)
<Borromini>
brb switching systems
Borromini has quit [Quit: leaving]
Borromini has joined #openwrt-devel
<Borromini>
re
<aiyion>
wb
GNUmoon has joined #openwrt-devel
<Borromini>
ty
<Borromini>
Grommish: i see you added ARMv7 binaries, will grab those