<re_irc>
<willeml> Well, I got gdb going, and narrowed it down to the "bx" instruction (after that instruction it just freezes) that's the branch instruction to actually start executing the OS code.
<re_irc>
Trying to write a bootloader for stm32f7...
<re_irc>
<willeml> And the problem is that the registers are not getting set correctly...
<re_irc>
<James Munns> What are you doing to jump to the application?
<re_irc>
<willeml> I am using "cortex_m::asm::bootstrap"
<re_irc>
<dirbaio> there "r1" has already got the wrong value?
<re_irc>
<willeml> according to the "info registers" in gdb r0 is "0x88888888" and r1 is "0x88888888" which are the wrong values
<re_irc>
<dirbaio> maybe troubleshoot your XIP settings
<re_irc>
<James Munns> that sounds like "everything is broken already"
<re_irc>
<dirbaio> sounds like they don't match well with the qspi flash chip you have
<re_irc>
<dirbaio> like, you read once and you get back valid data, you read again and you don't
<re_irc>
<willeml> And now I am trying without reading twice
<re_irc>
<willeml> Read works with my code, but not with the stuff in bootload
<re_irc>
<James Munns> Also, it'd be interesting to see what happens if you set a breakpoint on that asm line, if you're single stepping asm to get there
<re_irc>
<James Munns> (so: don't single step, set a breakpoint and then run to that line from start)
<re_irc>
<willeml> I have a breakpoint set on "lib::__bootload" which is the where the asm is
<re_irc>
<James Munns> sometimes having the debugger single step can mask hard faults and stuff
<re_irc>
<willeml> I guess I will just add a +22 or whatever
<re_irc>
<dirbaio> willeml: make a "stress test" in your code that reads random addrs from the flash
<re_irc>
<dirbaio> and check it always reads correct data
<re_irc>
<willeml> So random read, not sequential read of individual bytes separately?
<re_irc>
<James Munns> you can also "break 0x08000488" or something like that
<re_irc>
<dirbaio> something like that
<re_irc>
<dirbaio> dunno
<re_irc>
<dirbaio> like, sounds like XIP mapping is not working right
<re_irc>
<dirbaio> if that doesn't work, bootload won't work for sure
<re_irc>
<dirbaio> for i in 0..1000 { ((FLASH_ADDR + (i*4321 % FLASH_SIZE)) as *const u8).read_volatile() }
<re_irc>
then read addr 0 and 1 again, and print them to see if they're still OK or return 0x8888_8888
<re_irc>
<dirbaio> for i in 0..1000 { ((FLASH_ADDR + (i*4321 % FLASH_SIZE)) as *const u8).read_volatile() } then read addr 0 and 4 again, and print them to see if they're still OK or return 0x8888_8888
<re_irc>
<James Munns> willeml what happens if you break RIGHT BEFORE that ISB instruction?
<re_irc>
<willeml> So at isb or at msr?
<re_irc>
<James Munns> AT 480
<re_irc>
<James Munns> (so don't execute the ISR)
<re_irc>
<dirbaio> there's no point in debugging "bootload" if XIP doesn't work :P
<re_irc>
<James Munns> yeah
<re_irc>
<willeml> James Munns: Registers are the same
<re_irc>
<James Munns> gotcha
<re_irc>
<willeml> I will try the stress test
<re_irc>
<James Munns> What flash part are you using?
<re_irc>
<James Munns> that seems to be the issue you have? But not much info there...
<re_irc>
<James Munns> Did you enable QE mode on your flash part?
<re_irc>
<willeml> QE mode?
<re_irc>
<James Munns> Quad mode
<re_irc>
<James Munns> "Quad Enable"
<re_irc>
<willeml> I enabled QPI
<re_irc>
<James Munns> Locally? Did you also send a quad enable command?
<re_irc>
<James Munns> (some chips you have to tell them to go into quad mode before they'll do it)
<re_irc>
<willeml> Yeah, I sent it the enable QPI command
<re_irc>
<willeml> "0x38"
<re_irc>
<James Munns> does your chip support that mode?
<re_irc>
<willeml> Yes
emerent has quit [Ping timeout: 248 seconds]
<re_irc>
<willeml> (there is a C++ OS using it)
<re_irc>
<James Munns> gotcha!
<re_irc>
<willeml> Well, now something is completely broken, more broken than it was yesterday... "(0x90000000u32 as *const u32).read_volatile()" doesn't work
emerent has joined #rust-embedded
<re_irc>
<James Munns> btw 0x38 is the "quad program command"
<re_irc>
<James Munns> you probably need to do a write to register 0x06 first to enable QE in the status register
<re_irc>
<James Munns> 0x02 command to register 0x06 should do it
<re_irc>
<wembly> is there a 4pin resistive touch screen driver i'm just completely missing/not finding on crates.io?
<re_irc>
<willeml> There is some other config of the qspi.dcr and qspi.cr
<re_irc>
<James Munns> (0x02 is the value, 0x06 is the address)
<re_irc>
<James Munns> It might be worth reading back register 0x06 (Status Register 2), and see what it is
<re_irc>
<James Munns> (should be a 16 bit value)
<re_irc>
<willeml> Oh, I am using volatile write enable (0x50) instead of write enable (0x06) as the address
<re_irc>
<James Munns> What flash chip are you using?
<re_irc>
<willeml> AT25SF641
<re_irc>
<willeml> 8MB Adesto QSPI flash
<re_irc>
<James Munns> looking...
<re_irc>
<firefrommoonlight> yruama_lairba: use defmt::println!;
<re_irc>
<firefrommoonlight> I guess more line teh "println!" normal macro, but that's the functionality I think most people use in most programming languagse
<re_irc>
<firefrommoonlight> Ie, in Python, JS, embedded Rust and Desktop rust, it's that with teh new line every time for me
<re_irc>
<yruama_lairba> firefrommoonlight: i meaned there is not variant without the newline
<re_irc>
<James Munns> willeml 0x50 enables write, but not Quad mode
<re_irc>
<firefrommoonlight> I don't mean to suggest "This is the way I do it, you should be happy with it too!", but... I'm genuinely curious what you use "print!()" for, especially given that reaction
<re_irc>
<dirbaio> printing a single line in "parts" probably
<re_irc>
<firefrommoonlight> (The flip side of this is I'm considering what I'm missing...)
<re_irc>
<firefrommoonlight> Hmm.. I guess I would use a println for that too, but with multiple "{}" sections
<re_irc>
<firefrommoonlight> Btw, for anyone who forgot about or missed the update... You can now use "println!", "format!" etc with Python F-string style var-in-brackets
<re_irc>
<James Munns> which... is mind boggling because it works
<re_irc>
<willeml> Haha, code that works but shouldn't, always confusing but kindof nice
<re_irc>
<dirbaio> why is it wrong?
<re_irc>
<James Munns> (I send a 0x06 opcode to write the status register, which is wrong, and should be 0x01)
<re_irc>
<James Munns> AND I ask the nrf to send the write enable for me, so it's sending "0x06 0x06 [ SR1 ] [SR2 ]" instead of "0x06 0x01 [ SR1 ] [ SR2 ]"
<re_irc>
<willeml> Well, all my code is completely borked, even my dfu usb thing doesn't work anymore... just crashes
<re_irc>
<James Munns> Same on willeml's part
<re_irc>
<dirbaio> I think they're just different
<re_irc>
<James Munns> That first screenshot is from the chip you linked
<re_irc>
<James Munns> I think you might have an off by one bit error :p
<re_irc>
<dirbaio> do I??
<re_irc>
<dirbaio> 0x40 is bit 6 isn't it
<re_irc>
<James Munns> oh
<re_irc>
<dirbaio> 🤣
<re_irc>
<dirbaio> don't scare me more
<re_irc>
<James Munns> why is your msb/lsb order reversed?
<re_irc>
<dirbaio> where do you see it's reversed?
<re_irc>
<willeml> msb/lsb order?
<re_irc>
<James Munns> yeah, maybe its just different
<re_irc>
<James Munns> yeah, I thought it was reversed
<re_irc>
<James Munns> but its not
<re_irc>
<James Munns> it's just different
<re_irc>
<James Munns> (0x40 vs 0x02, it's a palindrome :p)
<re_irc>
<James Munns> see
<re_irc>
<dirbaio> ahh 🤣
<re_irc>
<James Munns> shoulda gone to bed 15 minutes ago
<re_irc>
<James Munns> no more thinking about qspi tonight
<re_irc>
<dirbaio> I see now
<re_irc>
<dirbaio> lolololol
<re_irc>
<James Munns> good luck willeml :p
<re_irc>
<willeml> lol, thanks, and gn
<re_irc>
<James Munns> I'm just reducing the SNR of this conversation
<re_irc>
<willeml> SNR?
<re_irc>
<James Munns> signal to noise ratio
<re_irc>
<willeml> Oh haha
<re_irc>
<willeml> Ok I got it working again, I have to do the init of flash before I init the clocks... But it does not hold up to the stress test dirbaio posted.
<re_irc>
<dirbaio> nice!! 🔥
<re_irc>
<dirbaio> at least you can repro it easier now
<re_irc>
<willeml> I spoke to soon, it's entirely random... Now it dosen't work again, zero changes to the code
fabic has quit [Ping timeout: 272 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 272 seconds]
cr1901_web has joined #rust-embedded
<re_irc>
<jannic> willeml: do your power cycle your board between attempts? Config written to the flash chip might not be reset, otherwise.
<re_irc>
<willeml> I don't, that's probably it
<re_irc>
<willeml> jannic: I just tried, now it works again, but only the first 2 memory mapped reads work, the second ones fail... At least that's one problem solved! Unfortunately power cycling the board is not easy as it's on a battery... I guess I need to figure out how to properly reset the flash.
<re_irc>
However, I guess that's only needed because the procedure should be compatible with many different flash chips. If you target one specific chip, there's probably a simpler reset sequence.
cr1901_web has quit [Quit: Client closed]
aspe has joined #rust-embedded
fabic has quit [Ping timeout: 260 seconds]
aspe has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
fabic has joined #rust-embedded
dreamcat4 has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
fabic has joined #rust-embedded
explore has joined #rust-embedded
fabic has quit [Ping timeout: 276 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 276 seconds]
dreamcat4 has quit [Quit: Connection closed for inactivity]
<re_irc>
<Chris [pwnOrbitals]> Hey everyone, does anyone have experience with picolibc ? One of my C dependencies needs it and I’m struggling to get it working, I managed to build it using the Meson crate but struggling to link with it
<re_irc>
<Chris [pwnOrbitals]> * can’t manage
fabic has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
fabic has quit [Ping timeout: 260 seconds]
fabic has joined #rust-embedded
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<Chris [pwnOrbitals]> (got it working, linker arguments weirdnesses)
<re_irc>
<James Munns> (interested in both "folks who work at a company that would sponsor/contract this work", or "hobbyists who want to hack along on a specific Cortex-A chip")
<re_irc>
<James Munns> Or, if anyone knows any Application-format RISC-V chips (like 500MHz-1GHz, 64+MB of RAM), that are available and documented, I'm open to those too :D
<re_irc>
<James Munns> Only one I've found is the MangoPi with an Allwinner D1s, but I don't know if those are actually shipping yet (or have any available docs?)
<re_irc>
<adamgreig> FPGA when :D
<re_irc>
<adamgreig> make a custom async-friendly cpu 🤔
<re_irc>
<James Munns> Oh, good point, a Zynq might be interested too
<re_irc>
<adamgreig> probably not going to win on cost though
<re_irc>
<James Munns> I guess I'll learn how to make CPUs after I feel satisfied with writing an OS.
<re_irc>
<adamgreig> room meeting time again! agenda is https://hackmd.io/IOn0qQx3RcyImCSQHRu5jg, please add anything you would like to announce or discuss, we'll start in 5 min
<re_irc>
<adamgreig> James Munns: i found https://nandgame.com/ today so i guess making cpus it is
<re_irc>
<thejpster> I got a couple of FPGA boards here that I just found out are now in LiteX.
<re_irc>
<James Munns> Oh neat? Is that like a web version of nand2teris?
<re_irc>
<James Munns> * nand2tetris?
<re_irc>
<adamgreig> i think the end point is not quite as far along as tetris
<re_irc>
<adamgreig> but you do make a little computer and it is all fun click and drag stuff
<re_irc>
<adamgreig> starting two a couple relays for your first nand gate, heh
<re_irc>
<adamgreig> * with
<re_irc>
<thejpster> The Neotron 9X was a SAM9X60D5M. SDRAM stacked in the package, so no fancy routing required.
<re_irc>
<adamgreig> ok, let's start! fairly short agenda I think. couple of announcements, svd2rust 0.24 is out, and we now have automatic release and prerelease binaries available to download off the github releases page https://github.com/rust-embedded/svd2rust/releases/tag/v0.24.0
<re_irc>
<adamgreig> does anyone have anything else to announce?
<re_irc>
<therealprof> I haven't checked, do we have any material for a newsletter?
<re_irc>
<adamgreig> hm, nothing on the draft
<re_irc>
<therealprof> Hm, indeed.
<re_irc>
<adamgreig> on the cortex-m front there's a new PR for a 0.7.5 release that would allow using inline-asm on stable and backports a bugfix from 0.8; the PR's ready for review but I haven't gotten around to actually testing it yet https://github.com/rust-embedded/cortex-m/pull/441 (though CI passes)
<re_irc>
<therealprof> It's been a while.
<re_irc>
<therealprof> adamgreig: LGTM but I don't have time to try it.
<re_irc>
<adamgreig> yea, I expect we could comb through some old minutes to dig up some items for a newsletter too
<re_irc>
<therealprof> I think James Munns posted a few blog posts meanwhile.
<re_irc>
<adamgreig> I'll report back when I get a chance to test but if anyone else does first, even better. It's a pretty small code change at least
<re_irc>
<therealprof> That would be good material. 😉
<re_irc>
<therealprof> Could also go through the last few TWIR, there were a number of embedded posts.
<re_irc>
<therealprof> Not sure why people announce there but not in the embedded newletter. E.g. there was at least one super interesting one about LoRaWAN by tweedegolf.
<re_irc>
<adamgreig> I guess that TWIM has a couple more readers than the REWG newsletter
<re_irc>
<therealprof> Sure, but more is better, no? ;))
<re_irc>
<adamgreig> I don't have anything to report on the other cortex-m PRs from last week, if I can get some testing of the 0.7.5 PR in I'll try to at least push a couple of those along
<re_irc>
<therealprof> * 😉
<re_irc>
<eldruin> we could also go over the r-e twitter feed and have a look at the RTs
cr1901_ has joined #rust-embedded
<re_irc>
<therealprof> At least the frequency of the newsletter is low enough that people interested in embedded are less likely to miss interesting things.
<re_irc>
<eldruin> we should put the CTCFT in the newsletter as well, along with the recording link
<re_irc>
<therealprof> Right.
<re_irc>
<eldruin> maybe James Munns and/or dirbaio write a blog post about that as well?
cr1901 has quit [Ping timeout: 248 seconds]
<re_irc>
<therealprof> I noticed that embedded currently seems to pick up some steam. Plenty of bugreports in cargo-binutils, discovery and various other crates lately.
<re_irc>
<therealprof> Getting the word out certainly can't harm.
<re_irc>
<therealprof> "defmt" is unfortunately causing a ton of trouble at the moment.
<re_irc>
<thejpster> Oh no. In what way?
<re_irc>
<therealprof> Seems probe-rs related tooling is expecting defmt 0.3 but e.g. the discovery book is using 0.2.
<re_irc>
<therealprof> Also e.g. the microbit crate is still using 0.2 due to "rubble" having a hard dependency on 0.2 and for some reason the examples can't use different versions of the crates which confused the heck out of me earlier today...
<re_irc>
<thejpster> Deps on examples are a pain generally.
<re_irc>
<therealprof> Not sure why but the build is complaining about linking problems. Maybe "defmt" is playing some linker tricks to get stuff done?
dc740 has joined #rust-embedded
<re_irc>
<thejpster> It does involve magic - the host tool has to dip into the ELF to find your strings, and such like. I could believe that linking multiple incompatbile versions was barred using linker foo.
<re_irc>
<therealprof> It's a bit annoying to have hard dependencies in such middleware crates.
<re_irc>
<therealprof> It's a lot more annoying that simply the presence of such an example can break everything.
<re_irc>
<adamgreig> I guess ideally rubble needs updating first, then?
<re_irc>
<adamgreig> and then microbit and discovery?
<re_irc>
<adamgreig> 0.3's been out for a while, but it is a breaking change and has the same issue as PACs and cortex-m etc of only being able to exist once per build
<re_irc>
<therealprof> I don't think discovery is blocked by rubble. Can't find the issue though, maybe it was on another repo.
<re_irc>
<therealprof> "cargo-binutils" also seems to make problems again lately on some systems.
<re_irc>
<eldruin> discovery will be blocked by microbit though
<re_irc>
<therealprof> Hm, could be.
<re_irc>
<therealprof> Who knew that examples could be so intrusive. 😅
<re_irc>
<thejpster> I mean better that than examples that live off in a dark corner and go bit rotten?
<re_irc>
<therealprof> Rubble seems to be rather dormant, though. Maybe we should just take the hit and remove the "ble-beacon" example and move on.
<re_irc>
<adamgreig> is it possible to rework to use the softdevice crates instead?
<re_irc>
<therealprof> No idea, doesn't sound trivial to me. Also, softdevice... meh.
<re_irc>
<adamgreig> anything to report on the embedded-hal front in the last ten mins or so?
<re_irc>
<eldruin> nothing from me
<re_irc>
<adamgreig> 👍️ OK, any last minute items from anyone?
<re_irc>
<adamgreig> let's wrap up there then, thanks everyone!
<re_irc>
<thejpster> Apropos nothing, I see Arm now do AWS instances with their hardware simulator installed