<SArpnt[m]>
i read the rust embedded book and at the entry point step it seems to expect a crate to already exist for a particular use case
<SArpnt[m]>
how would i go about compiling for a system where i know the technical details and could write assembly for it but there isn't a rust crate
K900 has joined #rust-embedded
<K900>
Is there an LLVM target?
<SArpnt[m]>
i'm not too experienced with compiler internals, this is the first project im working on where that doesnt get abstracted away somewhere
<SArpnt[m]>
im trying to develop for the nintendo ds which has 2 arm cpus
<SArpnt[m]>
rust already has the targets armv4t-none-eabi and armv5te-none-eabi, and i csn compile a static lib that works
<SArpnt[m]>
i cant compile a dynamic lib with it and if i try to compile a bin its just an empty elf file
<SArpnt[m]>
i have been wstching that tooling for a long time it does not work
<K900>
What about it doesn't work?
<SArpnt[m]>
i have tried to reverse engineer both devkotpro and blocksds and its all terrible
<SArpnt[m]>
i want to try aomething thay doesnt involve an existing sdk
<SArpnt[m]>
besides this is something im curious about anyways
<K900>
Then you'll probably need to at least write a custom linker script
<K900>
Or possibly even a custom linker to produce a binary in the right format the hardware expects
<SArpnt[m]>
if i write 6502 assembly i just get the code, no elf or anything
<SArpnt[m]>
i have seen a gba rust tutorial that demonstrates a custom linker script to generate a rom directly but i can't quite translate that over since the rom file has binaries for 2 cpus
<SArpnt[m]>
should i write 2 linker scripts and combine the results from both with another too?
<SArpnt[m]>
s/too/tool/
<K900>
It's really hard to tell without already knowing what the common approach there is
<K900>
Or even what the file format actually is
<K900>
Or how it's loaded
<SArpnt[m]>
i can get into it tommorrow i need sleep
<AlexandrosLiarok>
Is there any crate for defining registers for external devices ?
<AlexandrosLiarok>
device-driver looks nice.
IlPalazzo-ojiisa has joined #rust-embedded
<dirbaio[m]>
<SArpnt[m]> "should i write 2 linker scripts..." <- Yeah the way you'd do it is have two Rust projects for arm9 and arm7, build two elf's and then run ndstool to convert them to a .nds rom
<dirbaio[m]>
The nds rom format is more complex than gba, you can't really get the linker to do everything for you
<SArpnt[m]>
<dirbaio[m]> "Yeah the way you'd do it is have..." <- my issue is i don't understand how they're getting an elf in the first place
<SArpnt[m]>
i can only get those elffs when using specifically the linker provided in their toolchains in the way they are using it
<SArpnt[m]>
and i do really mean i have it down to exactly one gcc command with 3 static libraries, my main funciton, their libnds, their libc
<dirbaio[m]>
Rust outputs an elf by default, you don't have to do anything special
<SArpnt[m]>
if i build a bin the elf is empty, and i can't build a dynamic library for these targets
<dirbaio[m]>
Ah so you do get an elf but it's empty?
<SArpnt[m]>
if i build my rust project with cargo as a [[bin]] i get an elf, but if i run `size` on the elf it has nothing in it
<dirbaio[m]>
maybe you're missing the entrypoint, or "KEEP(..)" ?
<SArpnt[m]>
it seems to just be header and such
<SArpnt[m]>
i can't find a way to make an entrypoint
<SArpnt[m]>
i've tried to reverse engineer both ndstool and the custom toolchain linker from the sourcecode and they make no sense
<dirbaio[m]>
The linker optimizes out everything thats unused
<SArpnt[m]>
there's also absolutely no documentation on their linking step and no projects i can find where anyone uses any custom linker or settings and it works
<dirbaio[m]>
If you have no entrypoint or KEEP it'll think everything is unused
<SArpnt[m]>
how am i supposed to specify an entrypoint?
<dirbaio[m]>
You need to tell it "this thing is not unused because I tell you so, now keep that and everything reachable from it"
<SArpnt[m]>
feature(start) doesn't work
<dirbaio[m]>
In the linker script
<dirbaio[m]>
There's the ENTRYPOINT instruction
<SArpnt[m]>
a gcc spec file is gcc specific and would need to be redone for a different linker right
<SArpnt[m]>
the linker script is specified only in the spec file they use
<dirbaio[m]>
In rust you can specify it with the -T linker flag
<SArpnt[m]>
-T is the ld scripting language not the spec file
thejpster[m] has joined #rust-embedded
<thejpster[m]>
this is one downside of cortex-m-rt magically dropping a linker script in the right place - it's not obvious it's happening; wheras in any C project the linker script has to be right there with the source code
<SArpnt[m]>
the linker scripts in devkitpro and blocksds are hidden behind a complex web of files and come with the toolchain including the custom compilers and such
<dirbaio[m]>
I think you can get away without the spec file
<SArpnt[m]>
i'm testing right now to see what i can remove
<dirbaio[m]>
Just specify things directly yourself
<SArpnt[m]>
but the linker isn't specified manually it's in the spec file
<dirbaio[m]>
I dunno if you can use spec files with rust-lld
<SArpnt[m]>
and i haven't worked with spec files before
<SArpnt[m]>
i'm pretty sure spec files are specific to gcc
<SArpnt[m]>
i'm trying to move things out of the specfile but i can't find any settings that does what this does
<thejpster[m]>
It should be `"HardFault" => Exception::HardFault(parse_macro_input!(args)),`
<thejpster[m]>
we've silently broken everyone who was using the exception frame argument to the hard fault handler, and no-one will no about it until they get a hardfault, where the argument will be an invalid reference.
<thejpster[m]>
* we've silently broken everyone who was using the exception frame argument to the hard fault handler, and no-one will know about it until they get a hardfault, where the argument will be an invalid reference causing a CPU lock-up state.
<xiretza[cis]>
(maybe I'm missing something though, there seem to be two conflicting versioning schemes at play)
<thejpster[m]>
ahh, the tags do have a "compare..." button now. That helps.
<thejpster[m]>
adamgreig: can you publish cortex-m-rt-macros, and then yank cortex-m-rt 0.7.4 and publish 0.7.5 which uses the correct version of the macro crate?
ragarnoy[m] has quit [Quit: Idle timeout reached: 172800s]
<chrysn[m]>
Thanks thejpster for pointing the hard fault thing out to us in RIOT-rs, I'd have missed that. Out of curiosity: Are you so well aware of what we're doing there, or did it just show up on an elaborate grep through reverse dependencies?
ivmarkov[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has quit [Remote host closed the connection]
M-[m] has quit [Quit: Idle timeout reached: 172800s]
pkoevesdi[m] has joined #rust-embedded
<pkoevesdi[m]>
Hey. Maybe somebody can help me debugging this: I successfully made a rust program using / demonstrating the OCTOSPI on a STMH730. Now I wanted to make this into a flash algorithm. The same initialization that works on the stand alone program: let dp = pac::Peripherals::take().unwrap();... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/otbEuEnXThNLzOKRtoZkaYPu>)
<pkoevesdi[m]>
* Hey. Maybe somebody can help me debugging this: I successfully made a rust program using / demonstrating the OCTOSPI on a STMH730. Now I wanted to make this into a flash algorithm. The same initialization that works on the stand alone program:let dp = pac::Peripherals::take().unwrap();... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ybktvelCdDFJPymQZrEHDYhr>)