ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #rust-embedded
edm_ has quit [Ping timeout: 250 seconds]
Darius has quit [Ping timeout: 250 seconds]
Darius has joined #rust-embedded
edm_ has joined #rust-embedded
Darius has quit [Ping timeout: 250 seconds]
Darius has joined #rust-embedded
<re_irc> <@sjm42:matrix.org> Hello, I am trying to build just a simple hello bin for RTL8196E that has a MIPS-1 cpu of type RLX4181 and boy, this is hairy
<re_irc> <@sjm42:matrix.org> These two resources gave some hints:
<re_irc> <@sjm42:matrix.org> As you might guess, I am trying to make binaries for these silvercrest gateways with Rust.
<re_irc> I have the RTL gcc/uclibc toolchain installed, and I end up with linker error saying that I am missing "__tls_get_addr"
<re_irc> <@sjm42:matrix.org> Any ideas? I am quite stuck now.
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc> <@sjm42:matrix.org> = note: /home/sjm/.xargo/lib/rustlib/mips-unknown-linux-uclibc/lib/libstd-f68280f0d2989796.rlib(std-f68280f0d2989796.std.4d2d537436f0861c-cgu.14.rcgu.o): In function `std::io::stdio::print_to_buffer_if_capture_used::h98dacb7e58a3bd4d':
<re_irc> std.4d2d537436f0861c-cgu.14:(.text._ZN3std2io5stdio31print_to_buffer_if_capture_used17h98dacb7e58a3bd4dE+0x48): undefined reference to `__tls_get_addr'
<re_irc> std.4d2d537436f0861c-cgu.14:(.text._ZN3std2io5stdio31print_to_buffer_if_capture_used17h98dacb7e58a3bd4dE+0x54): undefined reference to `__tls_get_addr'
<re_irc> std.4d2d537436f0861c-cgu.14:(.text._ZN3std2io5stdio31print_to_buffer_if_capture_used17h98dacb7e58a3bd4dE+0x7c): undefined reference to `__tls_get_addr'
<re_irc> std.4d2d537436f0861c-cgu.14:(.text._ZN3std2io5stdio31print_to_buffer_if_capture_used17h98dacb7e58a3bd4dE+0x80): undefined reference to `__tls_get_addr'
<re_irc> /home/sjm/.xargo/lib/rustlib/mips-unknown-linux-uclibc/lib/libstd-f68280f0d2989796.rlib(std-f68280f0d2989796.std.4d2d537436f0861c-cgu.14.rcgu.o): In function `_ZN3std2io5stdio14OUTPUT_CAPTURE7__getit17h1d848c294bceb1dcE.llvm.2625439778906430369':
<re_irc> std.4d2d537436f0861c-cgu.14:(.text._ZN3std2io5stdio14OUTPUT_CAPTURE7__getit17h1d848c294bceb1dcE.llvm.2625439778906430369+0x2c): undefined reference to `__tls_get_addr'
<re_irc> /home/sjm/.xargo/lib/rustlib/mips-unknown-linux-uclibc/lib/libstd-f68280f0d2989796.rlib(std-f68280f0d2989796.std.4d2d537436f0861c-cgu.14.rcgu.o):std.4d2d537436f0861c-cgu.14:(.text._ZN3std2io5stdio14OUTPUT_CAPTURE7__getit17h1d848c294bceb1dcE.llvm.2625439778906430369+0x34): more undefined references to `__tls_get_addr' follow
<re_irc> collect2: ld returned 1 exit status
<re_irc> <@sjm42:matrix.org> " "has-elf-tls": true," <-- modified that line to false and retried, after cleaning up ".xargo" directory, and it did not help. I have no idea what that actually does.
<re_irc> <@sjm42:matrix.org> That line was found in "mips32-unknown-linux-uclibc.json" file
<re_irc> <@sjm42:matrix.org> Oh, and this TLS probably refers to "Thread-Local Storage" and not to Transport Layer Security... how nice to overload TLAs this way.
<re_irc> <@sjm42:matrix.org> https://www.uclibc.org/docs/tls.pdf <-- found this...
edm_ is now known as edm
<re_irc> <@sjm42:matrix.org> Oh well, tried to examine the libraries provided with the RTL toolchain. Looks hairy still.
<re_irc> sjm@ritsa:~/work/rsdk-4.4.7-4181-EB-2.6.30-0.9.30-m32u-140129/lib$ for a in *.a; do echo $a; nm $a|grep tls_get_addr||true; done
<re_irc> libc.a
<re_irc> libcrypt.a
<re_irc> libcrypt_pic.a
<re_irc> libc_pic.a
<re_irc> libdl.a
<re_irc> libdl_pic.a
<re_irc> libgcc.a
<re_irc> libgcc_eh.a
<re_irc> 00000190 T __emutls_get_address
<re_irc> libgcc_pic.a
<re_irc> 00000190 T __emutls_get_address
<re_irc> libgprof.a
<re_irc> libm.a
<re_irc> libm_pic.a
<re_irc> libnsl.a
<re_irc> libnsl_pic.a
<re_irc> libpthread.a
<re_irc> nm: ptlongjmp.o: no symbols
<re_irc> nm: ptclock_gettime.o: no symbols
<re_irc> nm: ptclock_settime.o: no symbols
<re_irc> libpthread_nonshared.a
<re_irc> libpthread_pic.a
<re_irc> nm: ptclock_gettime.oS: no symbols
<re_irc> nm: ptclock_settime.oS: no symbols
<re_irc> libresolv.a
<re_irc> libresolv_pic.a
<re_irc> librt.a
<re_irc> librt_pic.a
<re_irc> libstdc++.a
<re_irc> libstdc++_pic.a
<re_irc> libsupc++.a
<re_irc> libthread_db.a
<re_irc> td_thr_tls_get_addr.o:
<re_irc> 00000000 T td_thr_tls_get_addr
<re_irc> libthread_db_pic.a
<re_irc> td_thr_tls_get_addr.os:
<re_irc> 00000000 T td_thr_tls_get_addr
<re_irc> libutil.a
<re_irc> libutil_pic.a
<re_irc> uclibc_nonshared.a
<re_irc> <@juliand:fehler-in-der-matrix.de> xargo is no longer maintained, maybe there are some issues now. See https://github.com/japaric/xargo/issues/193#issuecomment-1149707441
<re_irc> <@sjm42:matrix.org> Is there any nice instructions how to migrate from xargo?
<re_irc> <@sjm42:matrix.org> Now just blindly tried this... I have no idea if my "mips-unknown-linux-uclibc.json" was actually used.
<re_irc> sjm@ritsa:~/git/Rust/00test/hello$ cargo build -Z build-std --target mips-unknown-linux-uclibc
<re_irc> Compiling rustc-std-workspace-alloc v1.99.0 (/home/sjm/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-alloc)
<re_irc> Compiling rustc-demangle v0.1.21
<re_irc> Compiling panic_abort v0.0.0 (/home/sjm/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/panic_abort)
<re_irc> Compiling panic_unwind v0.0.0 (/home/sjm/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/panic_unwind)
<re_irc> Compiling gimli v0.27.2
<re_irc> Compiling hashbrown v0.13.1
<re_irc> Compiling object v0.30.1
<re_irc> Compiling std_detect v0.1.5 (/home/sjm/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/stdarch/crates/std_detect)
<re_irc> Compiling miniz_oxide v0.6.2
<re_irc> error: Undefined temporary symbol $BB6_15
<re_irc> error: could not compile `rustc-demangle` (lib) due to previous error
<re_irc> warning: build failed, waiting for other jobs to finish...
<re_irc> <@juliand:fehler-in-der-matrix.de> Not sure whether a lot of migration is needed if you don't use std. Maybe replacing xargo with cargo does the trick.
<re_irc> <@juliand:fehler-in-der-matrix.de> Hmm that doesn't look great. Unfortunately I can't help you with this. Maybe someone else here has experience with that platform.
<re_irc> <@sjm42:matrix.org> Well I actually am trying to use std, namely uclibc
<re_irc> <@sjm42:matrix.org> That is the whole point of using this silvercrest zigbee gateway that was 12.50€ and could be repurposed for other stuff... if I only get to compile stuff for it.
<re_irc> <@sjm42:matrix.org> Not going to revert to just writing C :D
kenny has quit [Quit: WeeChat 3.8]
kenny has joined #rust-embedded
kenny has quit [Quit: WeeChat 3.8]
kenny has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
<re_irc> <@rin_shima:cryptty.tk> Hey guys, so I'm still working on it today. After some debugging I stumbled upon a "AddressNack" error returned from the VL53L0X library I used. So I tried the following snippet:
<re_irc> "let mut data: [u8; 1] = [0]; rprintln!("{:#?}", handler.write_then_read(0x52, &[0xC0], &mut data))"
<re_irc> This time it returned a DMABufferNot inDataMemory error. What does it mean? And should I scrap EasyDMA and use TWI interface instead (though it seems that only a TWIM interface is provided in nrf-hal)? Thanks!
<re_irc> <@rin_shima:cryptty.tk> Hey guys, so I'm still working on it today. After some debugging I stumbled upon an "AddressNack" error returned from the VL53L0X library I used. So I tried the following snippet:
<re_irc> let mut data: [u8; 1] = [0];
<re_irc> rprintln!("{:#?}", handler.write_then_read(0x52, &[0xC0], &mut data))
<re_irc> This time it returned a DMABufferNot inDataMemory error. What does it mean? And should I scrap EasyDMA and use TWI interface instead (though it seems that only a TWIM interface is provided in nrf-hal)? Thanks!
<re_irc> <@jamesmunns:beeper.com> nrf requires that DMA data is in RAM, not flash. your "&[0xC0]" is going to be a constant in flash
<re_irc> <@jamesmunns:beeper.com> let mut data_out: [u8; 1] = [0];
<re_irc> let mut data_in: [u8; 1] = [0];
<re_irc> should probably work
<re_irc> rprintln!("{:#?}", handler.write_then_read(0x52, &data_in, &mut data))
<re_irc> data_in.copy_from_slice(&[0xC0]);
<re_irc> <@rin_shima:cryptty.tk> : Oh... So how do you place the data in RAM?
<re_irc> <@jamesmunns:beeper.com> the embedded_hal interfaces will do the copy to ram for you automatically
<re_irc> <@rin_shima:cryptty.tk> Hey guys, so I'm still working on it today. After some debugging I stumbled upon an "AddressNack" error returned from the VL53L0X library I used. So I tried the following snippet to further debug:
<re_irc> let mut data: [u8; 1] = [0];
<re_irc> rprintln!("{:#?}", handler.write_then_read(0x52, &[0xC0], &mut data))
<re_irc> This time it returned a DMABufferNot inDataMemory error. What does it mean? And should I scrap EasyDMA and use TWI interface instead (though it seems that only a TWIM interface is provided in nrf-hal)? Thanks!
<re_irc> <@jamesmunns:beeper.com> > should I scrap EasyDMA
<re_irc> There's literally no way NOT to use easydma on the nrf52, btw
<re_irc> <@jamesmunns:beeper.com> You could also use "copy_write_then_read" instead of "write_then_read" - that's what the embedded-hal impls will do if the data is not in ram
<re_irc> <@jamesmunns:beeper.com> Or you could use "embedded_hal::blocking::i2c::WriteRead"'s "write_read()" function
<re_irc> <@sjm42:matrix.org> So it seems this beast has a MIPS-1 cpu and cannot handle MIPS32 binaries and I cannot figure out how to output MIPS-1 binaries with Rust.
<re_irc> <@sjm42:matrix.org> The gcc toolchain works since I was able to create a C binary with it for MIPS-1 just fine.
<re_irc> <@jamesmunns:beeper.com> Which target did you use?
<re_irc> <@jamesmunns:beeper.com> It seems from some searching that one of the "mipsel" targets (list here) might work? https://doc.rust-lang.org/nightly/rustc/platform-support.html
<re_irc> <@sjm42:matrix.org> "rustc -Z unstable-options --print target-spec-json --target mips-unknown-linux-musl" <-- this is listing mips32r2 by default
<re_irc> <@sjm42:matrix.org> of course I tried to edit the json and then use xargo and all
<re_irc> <@sjm42:matrix.org> Tried mips, mips1 and mips-1 and... no.
<re_irc> <@jamesmunns:beeper.com> There's a target like "mipsel-sony-psx" which someone mentioned used MIPS-I
<re_irc> <@sjm42:matrix.org> I always get mips32r2 binary out
<re_irc> <@sjm42:matrix.org> It looks like I have to build my own rustc from source and create my special target?
<re_irc> <@jamesmunns:beeper.com> nah, you should be able to use the json, if you have "mips-unknown-linux-musl.json" in the same folder as you are running
<re_irc> <@jamesmunns:beeper.com> rustc -Z unstable-options --print target-spec-json --target mipsel-sony-psx
<re_irc> {
<re_irc> "arch": "mips",
<re_irc> warning: MIPS-I support is experimental
<re_irc> "cpu": "mips1",
<re_irc> "env": "psx",
<re_irc> "data-layout": "e-m:m-p:32:32-i8:8:32-i16:16:32-i64:64-n32-S64",
<re_irc> "exe-suffix": ".exe",
<re_irc> "features": "+soft-float",
<re_irc> "is-builtin": true,
<re_irc> "linker": "rust-lld",
<re_irc> "linker-flavor": "ld.lld",
<re_irc> "llvm-abiname": "o32",
<re_irc> "llvm-args": [
<re_irc> "-mno-check-zero-division"
<re_irc> ],
<re_irc> "llvm-target": "mipsel-sony-psx",
<re_irc> "max-atomic-width": 0,
<re_irc> "panic-strategy": "abort",
<re_irc> "relocation-model": "static",
<re_irc> "target-pointer-width": "32",
<re_irc> "vendor": "sony"
<re_irc> }
<re_irc> <@jamesmunns:beeper.com> Are you running linux on that target, or bare metal ?
<re_irc> <@sjm42:matrix.org> The target has Linux, yes. Kernel version 3.10 it seems, with busybox and dropbear sshd.
<re_irc> <@sjm42:matrix.org> Also that psx is little endian while this one is big endian.
<re_irc> <@jamesmunns:beeper.com> so, you _should_ be able to dump the target json of mipsel-sony-psx and something like mips-unknown-linux-gnu, then you'll need to sorta "merge" them to fit the target you want
<re_irc> <@jamesmunns:beeper.com> and save it in a file like "mipsrtl-unknown-linux-gnu.json"
<re_irc> <@jamesmunns:beeper.com> then in your project folder, make a the folder + folder ".cargo/config.toml", and have it contain something like:
<re_irc> [build]
<re_irc> target = "mipsrtl-unknown-linux-gnu"
<re_irc> [unstable]
<re_irc> build-std = ["core", "alloc", "std"]
<re_irc> <@jamesmunns:beeper.com> cargo now has "built in" ability to rebuild the stdlib for a given target (if you are using nightly)
<re_irc> <@jamesmunns:beeper.com> so then you should be able to just do a "cargo +nightly build"
<re_irc> <@jamesmunns:beeper.com> and it'll autobuild the stdlib based on your target spec, like you were trying to use xargo.
<re_irc> <@sjm42:matrix.org> Yeah, I have nightly installed and using it already, that is no big deal
<re_irc> <@sjm42:matrix.org> So cargo should read my json, and also I actually should make up my own target string?
<re_irc> <@jamesmunns:beeper.com> Yeah, if you specify a target that isn't "built in", it'll look for a JSON file with that name, and use that as a custom target
<re_irc> <@sjm42:matrix.org> " "llvm-abiname": "o32""
<re_irc> <@sjm42:matrix.org> what would that be...
<re_irc> <@jamesmunns:beeper.com> _that_ I can't help you much with, I'd probably steal MOST of the values out what rustc dumps for "mips-unknown-linux-gnu"
<re_irc> <@jamesmunns:beeper.com> but change the CPU stuff to look more like "mipsel-sony-psx"
<re_irc> <@jamesmunns:beeper.com> (so it uses mips1 instead of mips2, but is still big endian, etc.)
<re_irc> <@sjm42:matrix.org> Yeah, I probably gotta 1) make up my own target name and 2) take psx target as the base and modify it as big endian and also everything that does not make sense for me...
<re_irc> <@jamesmunns:beeper.com> Yup! If you can find someone else who has gotten clang to build binaries for that target, they will have figured all of these values out too
<re_irc> <@jamesmunns:beeper.com> might be worth a search.
<re_irc> <@jamesmunns:beeper.com> But at least you don't have to rebuild the compiler after every change!
<re_irc> <@sjm42:matrix.org> RUSTFLAGS='-C target-feature=+crt-static' cargo build -Zbuild-std
<re_irc> Compiling core v0.0.0 (/home/sjm/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
<re_irc> Compiling compiler_builtins v0.1.91
<re_irc> Compiling libc v0.2.143
<re_irc> Compiling unwind v0.0.0 (/home/sjm/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/unwind)
<re_irc> Compiling memchr v2.5.0
<re_irc> Compiling std v0.0.0 (/home/sjm/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std)
<re_irc> Compiling hello v0.1.0 (/home/sjm/git/Rust/00test/hello)
<re_irc> error: Error loading target specification: Could not find specification for target "mips-silvercrest-linux-uclibc". Run `rustc --print target-list` for a list of built-in targets
<re_irc> <@sjm42:matrix.org> And yes, I do have a json file with the same name...
<re_irc> <@sjm42:matrix.org> So I ran cargo with strace and is is actually probing the right file. What gives...
<re_irc> <@sjm42:matrix.org> "error: Error loading target specification: Could not find specification for target "mipsrtl-unknown-linux-uclibc". Run "rustc --print target-list" for a list of built-in targets"
<re_irc> <@sjm42:matrix.org> Tried renaming it and tested cargo and xargo... no.
<re_irc> <@sjm42:matrix.org> "target/mips-unknown-linux-uclibc/release/hello: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, not stripped"
<re_irc> <@sjm42:matrix.org> this is what I get with using an overlapping name with my json
<re_irc> <@sjm42:matrix.org> OK I have to use the target as a _filename_ :D
<re_irc> <@jamesmunns:beeper.com> ohhh, yeah, sorry, thats my bad
<re_irc> <@sjm42:matrix.org> LLVM ERROR: Cannot select: 0x7f40a8b1a620: ch = MipsISD::Sync 0x7f40a8b224d0:1, Constant:i32<0>
<re_irc> 0x7f40a8b22700: i32 = Constant<0>
<re_irc> In function: _ZN5hello4main17h4f40438b4366bca2E
<re_irc> error: could not compile `hello` (bin "hello")
<re_irc> <@sjm42:matrix.org> That is what I get with ""max-atomic-width": 32" in the json
<re_irc> <@sjm42:matrix.org> If I use "0" as in the psx target, well, the std compilation fails miserably.
<re_irc> <@jamesmunns:beeper.com> yeah, you probably need max-atomic-width, with something like "use-cas: false"?
<re_irc> <@sjm42:matrix.org> error[E0432]: unresolved import `core::sync::atomic::AtomicUsize`
<re_irc> --> /home/sjm/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/stdarch/crates/std_detect/src/detect/cache.rs:8:5
<re_irc> |
<re_irc> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `AtomicUsize` in `sync::atomic`
<re_irc> 8 | use core::sync::atomic::AtomicUsize;
<re_irc> For more information about this error, try `rustc --explain E0432`.
<re_irc> error: could not compile `std_detect` (lib) due to previous error
<re_irc> warning: build failed, waiting for other jobs to finish...
<re_irc> error[E0432]: unresolved import `alloc::sync`
<re_irc> --> /home/sjm/.cargo/registry/src/index.crates.io-6f17d22bba15001f/gimli-0.27.2/src/read/dwarf.rs:2:12
<re_irc> |
<re_irc> 2 | use alloc::sync::Arc;
<re_irc> | ^^^^ could not find `sync` in `alloc`
<re_irc> error[E0432]: unresolved import `alloc::sync`
<re_irc> --> /home/sjm/.cargo/registry/src/index.crates.io-6f17d22bba15001f/gimli-0.27.2/src/read/abbrev.rs:4:12
<re_irc> |
<re_irc> 4 | use alloc::sync::Arc;
<re_irc> | ^^^^ could not find `sync` in `alloc`
<re_irc> <@sjm42:matrix.org> This is what I get with 0
<re_irc> <@jamesmunns:beeper.com> yeah, std assumes a target that supports atomics
dc740 has joined #rust-embedded
<re_irc> <@jamesmunns:beeper.com> does mips1 support atomic compare and swap operations?
<re_irc> <@jamesmunns:beeper.com> or only load/store ops?
<re_irc> <@sjm42:matrix.org> Well I must admit I have absolutely no idea of such low level things of mips-1
<re_irc> <@sjm42:matrix.org> warning: target json file contains unused fields: atomic_cas
<re_irc> <@sjm42:matrix.org> haha
<re_irc> <@jamesmunns:beeper.com> ""atomic-cas": false,"
<re_irc> <@jamesmunns:beeper.com> sorry
<re_irc> <@jamesmunns:beeper.com> silly renaming of "-"/"_"
<re_irc> <@sjm42:matrix.org> Oh yeah, well, still std is not happy with atomics
<re_irc> <@sjm42:matrix.org> Even after I fixed the name to atomic-cas
<re_irc> <@jamesmunns:beeper.com> I can't remember if "std" requires CAS though - it might. If it does, then you will need to either:
<re_irc> - try skipping std, and just make a no_std/core binary to see if it works
<re_irc> - You'll need to fork rustc and add some tweaks for your target
<re_irc> <@jamesmunns:beeper.com> rtil
<re_irc> <@sjm42:matrix.org> Or I just forget about the sad story about MIPS-1 and head for the new disappointments. :D
<re_irc> <@sjm42:matrix.org> The whole point of trying to compile Rust for this wildly obsolete piece of sh*t hardware was to run binaries under Linux and that means std too.
<re_irc> <@jamesmunns:beeper.com> so
<re_irc> <@jamesmunns:beeper.com> linux assumes you have atomics, afaik
<re_irc> <@sjm42:matrix.org> It would have been nice to run "whatever" on such 12.50€ hardware that has ethernet.
<re_irc> <@jamesmunns:beeper.com> armv5te uses "kernel provided" atomics
<re_irc> <@sjm42:matrix.org> When using no_std well I have a metric f*ckton of raspi picos, for starters.
<re_irc> <@jamesmunns:beeper.com> but honestly, to get rust support for a "new" (or old but not yet supported), you will have to figure out some of the low level details to tell Rust what to do
<re_irc> <@sjm42:matrix.org> Or nRF52840 or a few different STM32 chips, and esp8266 + esp32 including c3 with RISC-V
<re_irc> <@sjm42:matrix.org> Well I have those. Maybe I should get disappointed with ESP32 next :D
<re_irc> <@jamesmunns:beeper.com> there's almost certainly a way to do it, it just depends on what your interest is.
<re_irc> <@jamesmunns:beeper.com> esp32 has pretty good support :D
<re_irc> <@sjm42:matrix.org> Yeah but there is no linux kernel around...
<re_irc> <@jamesmunns:beeper.com> There are also a lot of very cheap arm and risc-v boards, I think some that have ethernet?
<re_irc> <@sjm42:matrix.org> It would have been _so_ nice to be able to write some networking code for that silly MIPS-1
<re_irc> <@sjm42:matrix.org> For example, run a matrix or slack bot on it
<re_irc> <@sjm42:matrix.org> Just for lulz
<re_irc> <@jamesmunns:beeper.com> Its definitely possible, you just have to find a "time/effort/hardware" budget balance that works for you :D
<re_irc> <@sjm42:matrix.org> Maybe I will just burn the extra silvercrest boxes with fire and try to forget the sadness.
<re_irc> <@sjm42:matrix.org> I have one running as a zigbee gateway for homeassistant and another as a backup hardware... and two more because I _thought_ I could _possibly_ compile whatever-rust for it since it is Linux and MIPS cpu after all, right... oh yeah, right. Well, sigh.
<re_irc> <@sjm42:matrix.org> The zigbee briding software found at github is written in C and compiled with the RTL provided toolchain. I was naively assuming it cannot be that hard to build with rust too.
<re_irc> <@sjm42:matrix.org> Maybe I will next try to figure out which cheap gear have openwrt support... I have a few unused old boxes to be slaughtered
<re_irc> <@sjm42:matrix.org> The zigbee/tcp bridging software found at github is written in C and compiled with the RTL provided toolchain. I was naively assuming it cannot be that hard to build with rust too.
<re_irc> <@jamesmunns:beeper.com> its not impossible. it's up to you whether you want to make it happen or not. Most of the tier3 targets were done by volunteers, like you, who wanted support for their targets.
<re_irc> <@jamesmunns:beeper.com> it's no worries if that's not the challenge you want, but it's also not impossible.
<re_irc> <@sjm42:matrix.org> Yes... I _totally_ understand that and this is the very spirit of open source and I have appreciated it 30+ years already. Have been using Linux from 1992.
<re_irc> <@sjm42:matrix.org> Hmm is there _anything_ I could still try? Perhaps I should now try to see what kind of atomics support MIPS-1 provides? Well, and when LLVM was fooled to think that yeah we have atomics up to 32 bit, the "cannot select" error was because it could not find any machine instructions to actually do it?
<re_irc> <@sjm42:matrix.org> Hmm, but when this sony-psx is stating "no atomics here" well, they have their own "enviroment" string that is "psx" so... that platform has their own stdlib or something?
<re_irc> <@sjm42:matrix.org> https://docs.rs/psx/latest/psx/
<re_irc> <@jamesmunns:beeper.com> armv5te uses linux kernel helpers: https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt
<re_irc> <@jamesmunns:beeper.com> : I don't know what causes that llvm issue - it could be a misconfig of your target json, or it could be a bug in llvm, I'm not sure
<re_irc> <@sjm42:matrix.org> Well my guess is that since I was just fooling around with the params and just made it up, the LLVM error was all legit since that cannot be actually done because atomics are not there.
<re_irc> <@jamesmunns:beeper.com> yeah, at least on armv5te, the atomic intrinsics are provided by glibc (or libgcc? not sure?), which calls the kernel helpers
<re_irc> <@sjm42:matrix.org> The psx docs mention a feature "nightlier": For when nightly rustc isn’t bleeding edge enough. This enables features requiring changes that aren’t in upstream LLVM yet. Using this requires building and patching LLVM as part of the rustc build. Currently this enables Atomic* up to 16-bits and fences.
<re_irc> <@jamesmunns:beeper.com> but you're getting an llvm error, not a linking error
<re_irc> <@sjm42:matrix.org> Well... that is quite a strong hint at GTFO no atomics here.
<re_irc> <@sjm42:matrix.org> Yeah, I get LLVM error when I lie about the max atomic size.
<re_irc> <@jamesmunns:beeper.com> I'm outta ideas and gotta run, but interested if you figure out how to make more progress later!
<re_irc> <@sjm42:matrix.org> When I just put this into my json cpu description with a straight face:
<re_irc> "atomic-cas": true,
<re_irc> "max-atomic-width": 32,
<re_irc> <@sjm42:matrix.org> ...then I get the LLVM error:
<re_irc> 0x7f28f1f02700: i32 = Constant<0>
<re_irc> In function: _ZN5hello4main17h735e0885f3fb8c54E
<re_irc> warning: MIPS-I support is experimental
<re_irc> LLVM ERROR: Cannot select: 0x7f28f1eeb620: ch = MipsISD::Sync 0x7f28f1f024d0:1, Constant:i32<0>
<re_irc> error: could not compile `hello` (bin "hello")
<re_irc> <@sjm42:matrix.org> This "MipsISD::Sync" stuff smells like I was immediately caught lying.
<re_irc> <@sjm42:matrix.org> Well this doc is talking about atomics, and it mentions "...then implement all of the atomic and sync functions expected by LLVM as #[no_mangle] unsafe extern "C". "
dc740 has quit [Remote host closed the connection]
cr1901 has quit [Quit: Leaving]
cr1901 has joined #rust-embedded