<neggles>
i mean, you should be compiling with ARCH=aarch64 for aarch64 platforms
<Grommish>
neggles: I do,but, the question is how to take CPU_SUBTYPE and turn it into --target-features -C +vfp4 for example
<neggles>
which should be arm64-openwrt-linux-musl no? or aarch64-openwrt-linux-musl
<Grommish>
aarch64
<Grommish>
but, arm/arm5/a5m6/arm7 is all just 'arm'
<Grommish>
And, which arm targets requires HF vs not
<Grommish>
because there is musleabi and musleabihf
<Grommish>
I just don't know enough about arm yet to deal with it, so I'm putting it off
<rsalvaterra>
stintel: Heh, so it happened to you too. :P
<neggles>
Grommish: um, so, `rustc --target=arm-unknown-linux-gnueabi --print target-cpus` gives you every core we have as a target cpu
<stintel>
rsalvaterra: I had seen it before
<neggles>
so you can just throw CPU_TYPE at it
<Grommish>
neggles: rustc understands it.
<Grommish>
neggles: OpenWrt does not
<Grommish>
neggles: OpenWrt reports ALL arm/armv5/armv6/armv7 ARCH as "arm"
<rsalvaterra>
stintel: Yeah, you told me at the time. It's still a weird error, though…
<neggles>
Grommish: well yes, because that's the ARCH
<stintel>
rsalvaterra: yours was segfault though, no ?
<Grommish>
CPU_TYPE will rquire a huge list
<Grommish>
SUB-TYPE looks more promising
<Grommish>
because it outlines the actual vfp/neon
<Grommish>
neggles: OpenWrt generates REAL_TARGET_GNU_NAME that I'm using to make the native tuples
<neggles>
i mean, you can't really compile for anything other than the explicit CPU_TYPE if you want performance, there's wild differences in instruction set between an arm926ej and a cortex-a15
<neggles>
and packages get compiled for each target/subtarget anyway don't they?
<Grommish>
neggles: Now you see the issue.. I was talking with dangole about the ARM situation and while he agrees its FUBAR, there isn't much to do about it
<Grommish>
neggles: The package does, the toolchain doesn't
<Grommish>
and the toolchain has to support it, even if I later turn it on at compile time
<neggles>
right, but rustc supports all of those different CPU_TYPEs in a single tuple/build
<Grommish>
those are the internal Tier1/2 Tuples for "arm".. Rust splits it out to armv6 and armv7
<Grommish>
but OpenWrt doesn't and its part of rules.mk or the include/
<neggles>
`rustc --target=arm-unknown-linux-musleabi --print target-cpus` prints out everything from xscale to neoverse-n2 ?
<Grommish>
neggles: and not a single arm-openwrt-linux-musl
<neggles>
well i assume that's because my rustc is not aware of that tuple, but isn't that just going to be a minor variation on arm-unknown-linux-musleabi / arm-unknown-linux-musleabihf?
<neggles>
i feel like i'm missing something
<Grommish>
neggles: They'll be mostly a straight clone, but that doesn't hellp.. Openwrt's $(REAL_GNU_TARGET_NAME) is set by the build system.. for any ARM, it's set to "arm-openwrt-linux-muslxxxx" (I'd have to check the ABI reporting when I get there)
<Grommish>
neggles: RustC breaks ARM targets out by revision levefl, OpenWrt doesn't
<Grommish>
OpenWrt uses CPU_SUBTYPE and FEATURES to set the revision/abi
<Grommish>
rather than just setting a standardized LLVM tuple
<Grommish>
Otherwise, this would be easy
<Grommish>
I'll be better way to demonstrate once I finish with aarch64 and can mvoe to a arm's target directly
<Grommish>
neggles: rustc --print target-list
<Grommish>
Those are the "native" tuples since you don't have the PR (although depending on how old your rustup is, the mips64-openwrt-linux-musl might be there already)
<Grommish>
I have to reference, or create, a target, but, everything ends up "arm-openwrt-linux-musleabi
<neggles>
Grommish: see what confuses me is, it shows a compiler backend feature for each cortex core type at least; and if it has all these target CPUs in the list I would assume it knows what features to flip for each target CPU?
<Grommish>
or just -musl.. I'd have to check.. If you are running the rust pr locally, run a make V=sc package/feeds/packages/rust/host/{clean,configure} and look at --target
<Grommish>
stintel: tested it on a mips_24kc/mipsel_24kc
<neggles>
i mean the softfloat stuff :P
<Grommish>
neggles: Habbie tested it on a 19.07 mips or mipsel
<Grommish>
neggles: They ran your test suite
<Grommish>
neggles: I can't convince anyone to build the toolchain :D
<neggles>
"test suite" :P
<neggles>
I will build the toolchain, yolo
<neggles>
but, what happens if you pass it `arm-unknown-linux-musleabi` as a tuple with --target-cpu='cortex-a53' then? and perhaps more relevantly, what are the rust-in-kernel folk doing? 'ARCH=arm' always for kernel
<Grommish>
neggles: Be my guest :D I updated the PR today, though I'm still testing aarch64
<Grommish>
I'll have to push that patch later
<Grommish>
neggles: I'd assume the rust-in-kernel folks are following the proper tuple naming convention
<Grommish>
neggles: But, to change it now would require changing all the arm targets in some form or another, and I'm not interested in doing it if I don't HAVE to, and no one else will or probably approve it
<Grommish>
it would have to go thru so many conversations I'm not even bothering to look into it unless I can't do it any other way
<jow>
I guess you'll end up with something like that, just for rust: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=scripts/config.guess
<Grommish>
jow: I've got mips/mipsel/mips64 and probably aarch64, but arm and it's reporting is going to cause issues
<Grommish>
Ideally, they'd all be changed to reflect arm/armv5/armv6/armv7 as the ARCH rather than as a CONFIG_ARMv7 or CPU_SUBTYPE/FEATURES
<Grommish>
but again, Not interested unless I have literally no other option because I feel it would be a waste of time trying to convince the tree-wide change to be tested and integrated
<jow>
maintaining a simple plaintxt mapping files or a conversion script seems like the more pragmatic course of action
<neggles>
they are definitely, only using the 'arm' tuple in the kernel
<Grommish>
jow: I tried that too and it got so convulted even Daniel wa having issues :D
<neggles>
they kind of have to? it has to match the backend tuple for the rest of the kernel, no?
<Grommish>
neggles: But, until I get into it and see what pieces I have to work with, I won't know for sure.. which is why i was avoid it heh
<Grommish>
neggles: I also want to look at how to nest these so it can install the dist that it builds if its available (or in the future, download it from the buildbot), and then fall back to compiling if it can't
<neggles>
i mean, based on --print-target-cpus and --print-target-features, the `arm-blah-blah` target includes the `armv6` and up tuples... and it definitely never passes 'v6' or anything like that to rustc
<neggles>
all the more specific tuples seem to exist so you can build a smaller toolchain if you only need to support one of them
<neggles>
i am aware that these exist *internally within the compiler/toolchain* but that doesn't mean it needs to be given it explicitly in use
<Grommish>
Ok, so.. How do I set a features: "+soft-float,+strict-align".to_string(), AND features: "+strict-align,+v6".to_string(), in the same tuple?
<Grommish>
Which is from armv7 and arm
<Grommish>
Or the +vfp4-neon feature? without tanking everything else?
<Grommish>
Without having to do manual table edits inside every rust package, not just the toolchain
<Grommish>
because the package has to know the rust tuple for --target/host/buil
<Grommish>
er build
<Grommish>
I figure I can turn everything on, then disable on compile-time based on CPU_SUBTYPE or FEATURES or whatever
<Grommish>
because unless I split things out by hand, it all goes to arm-openwrt-linux-musl by rote of the build system
<Grommish>
the toolchain is based on the arch, not the target
<neggles>
I know, but if you look at `rustc --target=arm-unknown-linux-musleabi --print target-features` it lists every feature as being available
<neggles>
is it not just a case of building a toolchain for that tuple and/or the musleabihf tuple then passing appropriate --target-cpu and/or --target-features at build time?
<Grommish>
neggles: I was asking about turning everything on and then disabling it on compile time, and you told me it would be bad ;p
<neggles>
it would be bad for the output packages running on the device, not the toolchain :P
<Grommish>
So, say I had a tuple with target-options for +vfp3,+vfp4,+vfp4-neon, etc in the TUPLE (and thus, toolchain) and then turn them off via RUSTFLAGS target-options?
<Grommish>
for whichever target doesn't need whatever
<Grommish>
Which I should be able to do via the CPU_SUBTYPE, no?
<neggles>
when you build the toolchain you specify what tuples to support right?
<neggles>
that seems obvious but i take nothing for granted
<neggles>
you can pass more than one tuple to --target
<Grommish>
neggles: You can if you have experimental -Z on
<Grommish>
neggles: But I didn't see a reason for multi-target because it would just build them and it isn't needed for most poeple
<Grommish>
neggles: I start at the bare repo and build stage0/stage1/stage2
<neggles>
hmmm
<Grommish>
neggles: I can't use rustup :D
<neggles>
the windows dist is built with, `--build=x86_64-pc-windows-msvc --host=x86_64-pc-windows-msvc --target=x86_64-pc-windows-msvc --enable-full-tools --enable-profiler`
<neggles>
and it supports every single toolchain output tuple
<Grommish>
You're using rustup though, yes?
<neggles>
no i am looking at the command they run in github actions ci
<Grommish>
Right, I build out dist because their install is junk
<Grommish>
$(PYTHON) x.py install I could never get to work right
<neggles>
but for this part, --target is the target the toolchain will run on, not the targets the toolchain can build for, no?
<Grommish>
neggles: --target is the cross,--host is the host, --build is the build tuple
<Grommish>
neggles: so --target/--host for Mips64 would try to build rustc/cargo for mips64
<Grommish>
if you leavge --build as x86_64
<Grommish>
I'm havin LLVM issues with generating rustc/cargo for mips64, so I ditched it for now.. You can see the CONFIGURATION_ARGS for future dealings
<neggles>
I assume there's a reason for whole new target tuple specs rather than just the existing arm-unknown-linux-musleabi[hf] specs
<Grommish>
neggles: *shrug* Dunno, but it's been the major issue with arm I've been facing and how to deal with it
<Grommish>
I literally found it easier to upstream the tuple rather than try to table-sort
danitool has quit [Ping timeout: 480 seconds]
<Namidairo>
oof, someone asking for a bootloop fix backport just a few hours after branching
philipp64 has quit [Quit: philipp64]
<Slimey>
how does the persistent /var option work? I enabled it but after sysupgrade /var still goes to temp
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
srslypascal has quit [Quit: Leaving]
danitool has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
Strykar_ has joined #openwrt-devel
Strykar has quit [Ping timeout: 480 seconds]
Strykar_ is now known as Strykar
philipp64 has joined #openwrt-devel
philipp64 has quit [Quit: philipp64]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<stintel>
is there a way to lookup "call" from commands[] using the caller of ubus_cli_error ? then I could drop the cmd argument from ubus_cli_error
<stintel>
could also just hardcode "call" in the printf as we currently only call it from ubus_cli_call
<jow>
no way to lookup
<stintel>
too bad
<jow>
at least not without restructuring a lot of the surrounding code
<stintel>
ok, should I just remove the cmd argument and hardcode call instead?
<stintel>
although this error function could be used to improve error logging about other calls too
goliath has joined #openwrt-devel
Misanthropos has joined #openwrt-devel
cant_compile_openwrt has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
<cant_compile_openwrt>
This may be a dump question: is there a switch/flag/whatever to influence which gcc compiler is used to compile the toolchain (not the gcc compiler in the toolchain itself)? gcc on my system points towards a gcc11 which is not supported on the old 19.07.7 i am attempting to build, gcc10 and gcc9 would also be avaliable.
<jow>
cant_compile_openwrt: make distclean; CC=gcc9 CXX=g++9 make
<cant_compile_openwrt>
Thanks jow!
enyc has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
cant_compile_openwrt has quit [Quit: is of compiling openwrt]
hexa- has quit [Quit: WeeChat 3.3]
hexa- has joined #openwrt-devel
SherlockDomes has joined #openwrt-devel
kenny has quit [Remote host closed the connection]
kenny has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
goliath has joined #openwrt-devel
lmore377 has quit [Remote host closed the connection]
lmore377_ has joined #openwrt-devel
minimal has joined #openwrt-devel
snh_ has joined #openwrt-devel
snh has quit [Ping timeout: 480 seconds]
snh has joined #openwrt-devel
snh_ has quit [Read error: Connection reset by peer]
SherlockDomes has quit [Ping timeout: 480 seconds]
cotequeiroz has quit [Remote host closed the connection]
lmore377_ has quit [Read error: Connection reset by peer]
lmore377 has joined #openwrt-devel
Misanthropos has quit [Ping timeout: 480 seconds]
Misanthropos has joined #openwrt-devel
<Grommish>
Anyone want to help me with ARM arch stuff, but can work with someone who knows almost nothing about it and how it related to the build system? Example: BCM57xx target, does this target actually require "+v7,+thumb2,+soft-float,-neon"?
<Grommish>
jow: If I export a variable in my rust/host section, would that make that variable available to the rest of the build system down the line? A rust package would have had to call rust/host at some point, so if I set target/host arch variable in rust/host and export them, would the poackage be able to use them?
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
eduardo010174 has quit [Remote host closed the connection]
eduardo010174 has joined #openwrt-devel
Tapper has joined #openwrt-devel
Borromini has joined #openwrt-devel
<jow>
Grommish: not sure, I suggest to introduce a "rust.mk" which exports macros as needed
<jow>
Grommish: take a look at python.mk for inspiration
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<tmn505>
Grommish: I would go with suggestion from jow, also You'll need to famirialise Yourself with how the build system sets the gcc options for each target/subtarget.
<tmn505>
And BTW to view result how buildsystem sets flags download toolchain from snapshots from known arm target, unpack it and run this command from the root of the toolchain: find . -name "configargs.h" -exec cat "{}" \;
<Grommish>
tmn505: That issue isn't the gcc flags, it's how openwrt reports it's tuples for arm targets. I'm looking for a way to reduce having ot put a nasty hacky "lets figure out which arm-openwrt-llinux-musl this actually " logic in every package that would need rust :(
rua has joined #openwrt-devel
<Grommish>
tmn505: the r8000 is a bcm57xx armv7 target that reports as arm, relying on the CPU_SUBTYPE and FEATURES and whatnot to figure out what is needs as far as float/fpu/etc
<tmn505>
the only way I see it, You'll have to map that per target no way aroud it
<Grommish>
tmn505: at that point, I'd just fix openwrt to report correctly. If the energy and time has to be spent, it's best to do it where it counts :/
<Grommish>
but I'm no there yet
<yolo>
buildroot is just a build system while openwrt has so many goodies(ubox,ubus,etc), what about the idea to make openwrt also generic for non-router usecases, e.g. buildroot+uci|ubox|ubus|simple-luci ?
<Grommish>
in thgeory, I can check CONFIG_arm_v7=y to split out at least the armv7 targets, but thats still ugly
cotequeiroz has joined #openwrt-devel
<yolo>
or another way around, adding all openwrt goodies to buildroot, somehow I just came out this thought, someone probably already did that
<Grommish>
yolo: Anyone who is significantly skills enough to consider it would also have to create the target
<Grommish>
yolo: Unless you wanted to mockup a qemu or x86_64 target
<tmn505>
or simply map TARGET_imx6 to the tuple that rust understands
<Grommish>
tmn505: What tree is that under
<yolo>
i always feel the uci/ubox/ubus/etc are hidden gems for other embedded 'frameworks'
<yolo>
anyway, i will keep thinking, qemu will the the start
<tmn505>
target/linux/imx6
<Grommish>
Yes, but that is the device name
<Grommish>
if you know offhand
<tmn505>
Grommish: sorry that changed recently, it's target/linux/imx
<Grommish>
I needed the boardname to find the tree :) BOARDNAME:=NXP i.MX with Cortex-A9
<Grommish>
One sec
<tmn505>
target/linux/imx/cortexa9/target.mk
<Grommish>
Yeah.. NXP targets
<Grommish>
I need to set the target, build the toolchains for gcc, then i can get the exported tuple
<tmn505>
not exactly, You don't need to build it
<Grommish>
I'm going to guess openwrt puts it as: arm-openwrt-linux-muslgnueabi
<Grommish>
Which is an issue as a ArmV7 SOC
<tmn505>
yes
<Grommish>
It should be reporting as armv7-openwrt-linux-muslgnueabi
<tmn505>
but You can't map tuple to tuple
<Grommish>
I am creating the tuples, so, yes I can as long as Openwrt reports it correctly :D
<Grommish>
Because everything is funneled into 'arm-openwrt-linux-musleabi' right now
<tmn505>
then You are in for some pain
<Grommish>
or potentially the hf version
<Grommish>
tmn505: Yep. I know, Dnaiel G knows.. I've been avoiding it
<Grommish>
I'm looking for an easier way because doing it correctly probably isn't worth the effort or hassle of dealing with the comments
<Grommish>
but, I'm just now getting into the arm targets, so we'll see
<tmn505>
Ok I've got probably dumb but simple solution for Your problem
<Grommish>
I'm about getting it to work and then making it work proper.. hit me
<Grommish>
This was the best we were able to come up.. remember, it's arch based, not TARGET based, though it has to be BOTH in OpenWrt because it doesn't split them out
<Grommish>
The target defines the arch settings rather than the arch being set and the target meeting the arch
<Grommish>
That works for userspace stuff, but not so well for toolchains
<Grommish>
But, I'm just bemoaning at this point :) Let me build this NXP target and see what's what
<Grommish>
Will you test the output when its done?
<tmn505>
that's the point, arch based detection won't be sufficient in that case, You'll need to do it per target
<tmn505>
unless we start differentiate between armv5 and armv7 in OpenWrt buildroot
<Grommish>
tmn505: Yes, but I also need a way to keep it centralized to the rust-host package, or it'll have to be included in every package
<Grommish>
tmn505: Well, that was the other options I was avoiding
<Grommish>
tmn505: CONFIG_arm_v7 does exist, and I was asking about exporting variables, and will look at the python model to see how they do it
<tmn505>
yeah, I think that's the way forward
<Grommish>
My biggest issue is that first time I run a target, it's a 5-6 hour build for everything that needs to be done if I change rust, it's a 4 hours rebuild :D, so it just takes a while. I'm always looking for a better way though
<tmn505>
don't build it. did You see my previous messages at the beginning?
<Grommish>
Yes, but I still need to build the gcc toolchain, and I need to deal with rust to the point I can pull the configuration
<Grommish>
gcc toolchainf rom nothing is about 1.5 hours or so
<tmn505>
haven't You tried to use SDK?
<Grommish>
Once I can grab the rust config, which requires the gcc toolchain to generate, I can start on rust itself, creating the tuples
<Grommish>
tmn505: I build everything from source
<Grommish>
tmn505: Otherwise, you couldn't PR anything
<Grommish>
I also can't use rustup, if you were thinking that :)
<Grommish>
for various and sundry reasons
<tmn505>
I always start with SDK but if rustup is meant as part of toolchain, then yes, source is the only option
<Grommish>
tmn505: Because rustup had issues I couldn't over-come. but, it does mean I can create the openwrt tuples and upstream them
<Grommish>
So not a total loss.. Ideally, teh build system would generate the rust-lang toolchains and people would just pull them down adn install them.. It's already setup for it in my Makefile
Gaspare has joined #openwrt-devel
<Grommish>
tmn505: I created a OpenWrt rust-lang SDK? :D
Tapper has quit [Ping timeout: 480 seconds]
<tmn505>
How? Anyway good luck, fortunately I don't need anything rust related on my router yet.
<Grommish>
tmn505: I create distro installation archives and then use those to do the actual install into STAGING_DIR_HOST because their installation stuff is lacking outside of a default system location
<Grommish>
if you're interested in my hackery to get where I am
<Grommish>
tmn505: and rust-lang is open to me generating and upstreaming Tier 3 tuples.. I already have a mips64-openwrt-linux-musl in their repo
<tmn505>
well, I don't like to delve in toolchains/compilators to much, since that's complete voodoo for me
<Grommish>
Oh, me too.. I just am stubborn beyond reason at times
<Grommish>
Ironically, the reason i wanted this was Suricata6, and Suricata6 is broken for cross-compilng.. But, rustc/cargo is integrated into openWrt for the Mips64/mips/mipsel/aarch64 arches that I've tested
<tmn505>
So almost there, i hope You'll succede.
<Grommish>
arm is the issue for sure.. and thanks :)
<tmn505>
Just powerpc, arc* and arm 32-bit left.
<Grommish>
PPC wa being a pain with LLVM, but I think I know how to fix that now
<Grommish>
or rather.. PowerPC64
<tmn505>
no love for powerpc32?
<Grommish>
It wasn't haven't the issue :)
<Grommish>
PowerPC64 requires a -D__PPC__ in order for LLVM to know what it was?
<Grommish>
and OpenWrt didn't do that
<Grommish>
I didn't know where to put that at the time and I just havern't circled back yet
<Grommish>
My only test bed is an Octeon3 MIPS64 device, so I started there and had issues with MIPS64 needng Kernel Float enabled
<tmn505>
Don't You have any mips32 access point, what's diving Your WiFi?
<tmn505>
*driving
<Grommish>
My device is an Itus Shield.. No Wifi..
<Grommish>
I have a Zyxel device my ISP wants me to use that I have setup as a Dumb AP
<Grommish>
but the Itus is my outward facing device
<tmn505>
if that zyxel is behind Shiled is that simple ap or router with modem?
<Grommish>
Dumb AP.. It just handles the radios.. DNS/DHCP/etc is handled by the Shield
<Grommish>
I have a wired-backhaul to the Sheld and 3 extra LAN ports if I really need it
<tmn505>
so probably that zyxel can be ported to OpenWrt, weird is that Your ISP requires You to use it.
<Grommish>
I've got FTTH and the CPE drops a Cat6 cable to my device. They don't limit what I can do with it and actually provide up to 4 pulic IPv4 IPs if I put a switch upstream of the Shield
<tmn505>
ah, that's great my ISP gives me black box without acces to it, so not much fancy stuff ic can do with OpenWrt