<re_irc>
<Jan Bronicki> how can i know what acutal size gets loaded onto my board?
<re_irc>
<9names (@9names:matrix.org)> The size on board is vector table + text + rodata, the debug symbols aren't loaded onto the target
<re_irc>
<Jan Bronicki> okay but is there a way of getting that measurmenti n a better way?
<re_irc>
<Jan Bronicki> for example without all the useless information
<re_irc>
<Jan Bronicki> and maybe with some units next to the numbers?
<re_irc>
<9names (@9names:matrix.org)> Better is relative. I usually use objcopy -O binary my.bin && ls -lah my.bin but there are probably more appropriate tools
<re_irc>
<adamgreig> Try -B instead of -A
<re_irc>
<therealprof> Or maybe even without any flags?
<re_irc>
<therealprof> text data bss dec hex filename
<re_irc>
<twitchyliquid64> Im trying to get FAPs (flipper application packages) compilable from Rust (Flipper Zero, a cortex m4 who's RTOS supports loading ELF binaries). To do that, I need to compile to a relocatable ELF for target "thumbv7em-none-eabi". I can't work out how to get the linker to not complain about undefined symbols from my "extern "C"" and just treat them as dynamic.
<re_irc>
<twitchyliquid64> Any ideas?
<re_irc>
<James Munns> relocation doesn't work on rust for cortex-m, at least not last time I checked.
<re_irc>
<twitchyliquid64> Hmmm, we could get away with a static elf as long as it called into external functions using "R_ARM_ABS32". I just dont know how to even get "rust-lld" to understand that "furi_message_queue_alloc" is something to be dynamically linked at program start rather than linked at compilation
<re_irc>
>>> referenced by rustc_std_workspace_core.000f9710-cgu.0
<re_irc>
<James Munns> Not sure either. Definitely interested if you find something tho
<re_irc>
<twitchyliquid64> Linker flags and the like in "config/.cargo.toml" dont seem to affect the invocation, im guessing thats at a different layer
<re_irc>
<twitchyliquid64> yeah ill keep digging
<re_irc>
<James Munns> you need to pass them with "-C link-arg=..."
<re_irc>
<James Munns> e.g.
<re_irc>
rustflags = [
<re_irc>
]
<re_irc>
"-C", "link-arg=-Tlink.x",
<re_irc>
<James Munns> or you can pass them through the RUSTFLAGS env var
<re_irc>
<twitchyliquid64> Urgh I had "rustflags" naked instead of in a "[target.'cfg(all(target_arch = "arm", target_os = "none"))']" block so it wasnt being picked up, FML lmao
<re_irc>
<twitchyliquid64> okay now to try everything I had thought I had eliminated again lol
<re_irc>
<therealprof> twitchyliquid64: Didn't they have an example app (or two) for that on GH?
<re_irc>
<twitchyliquid64> Not in rust but they have a bunch in C
<re_irc>
<twitchyliquid64> Ive now got it to complete without error, but the outputted elf is missing code and all the external symbols, so im definitely holding something very wrong
<re_irc>
<therealprof> (no idea how good/useful that is though)
<re_irc>
<twitchyliquid64> Ooooooooo
<re_irc>
<twitchyliquid64> okay looks like his approach is to compile to a staticlib then use the flipperzero-firmware tooling to go th rest of the way
<re_irc>
<twitchyliquid64> thats probably a better idea than trying to get rustc to emit exactly the elf i want
<re_irc>
<therealprof> I might be mixing stuff up. 😅 One hardware project I backed was very explicit about: Hey, this is written in C/C++ but we'll mostly support extensions written in Rust.
<re_irc>
<therealprof> I thought it was flipper but maybe not... Hm, where is my flipper actually?
<re_irc>
<twitchyliquid64> Im actually quite impressed, the plugin system is super simple and they called it "FAP" 😂 (flipper application packages)
<re_irc>
<twitchyliquid64> its just an ELF, and you use the symbol table to link up to functions you can call in the RTOS
<re_irc>
<twitchyliquid64> and theres a magic section with metadata on API version as well as plugin name and icon
<re_irc>
<dirbaio> hm if it uses the "normal" PIC with relocations I think you should be able to produce an elf from rust that works fine
<re_irc>
<dirbaio> because the tock PIC issues are for the "fancy" ropi/rwpi PIC only (?)
<re_irc>
<Jan Bronicki> I need to use an SD card thru SDIO
<re_irc>
<Jan Bronicki> any recommendations? This is my first time doing it. I found a library for SD card but I think its only for SPI? Im really not sure
<re_irc>
<adamgreig> you can use that crate over sdio but you'd have to implement its BlockDevice trait for your SDIO peripheral, it just provides a generic SPI one, aiui
<re_irc>
<Jan Bronicki> if i were to implement it for SDIO could I try to get it merged into that crate so the next person doesnt have to do this too? im really new to all that stuff
<re_irc>
<adamgreig> but not for the embedded-sdmmc crate
<re_irc>
<adamgreig> so you'd have to hook it up yourself, but hopefully it wouldn't be too hard
<re_irc>
<adamgreig> embedded-sdmmc probably wouldn't take changes because they'd be specific to the stm32f4 peripheral, but the stm32f4xx-hal could perhaps take a change to specifically support embedded-sdmmc?
<re_irc>
<dirbaio> if you're going to glue things yourself manually maybe it's worth taking a look at this instead: https://github.com/rafalh/rust-fatfs
<re_irc>
<dirbaio> the FAT implementation there is more mature (supports stuff embedded-sdmmc doesn't)
<re_irc>
<Jan Bronicki> thanks
<re_irc>
<Jan Bronicki> so basically what do I need to do?
<re_irc>
<Jan Bronicki> This is my first time doing it
<re_irc>
<Jan Bronicki> I do have a hal, thats true. What now?
<re_irc>
<Jan Bronicki> oh okay i didnt see that thanks
<re_irc>
<9names (@9names:matrix.org)> It's never explicitly mentioned as the default, so feel free to make a PR to improve the docs to make it easier for the next person to find
<re_irc>
<twitchyliquid64> Got it working!! :D
<re_irc>
<twitchyliquid64> rustflags + an unholy arm-none-eabi-gcc + arm-none-eabi-objcopy incantation