00:41 <c4017w_> Woohoo, it finally all works!

09:13 <_franck_> would it be possible to have binarybuffer.h functions endian aware ? For example, I'd like to use buf_to_hex_str on big endian datas in a buffer without an prior buffer manipulation to swap endian.

10:20 <rue_mohr> https://twitter.com/RueNahcMohr/status/1416341551286951939

19:37 <guessnbl> I am trying to "flash write_image erase nuttx.bin 0x08000000" an stm32f103 minimum blue pill board, following some instructions here https://github.com/apache/incubator-nuttx/tree/master/boards/arm/stm32/stm32f103-minimum

19:38 <guessnbl> I get "no flash bank found for address 88000000" which seems strange because the target I am using specifies (and flash list seems to agree) that I have a flash bank starting at 0x08000000. Seems like a base/prefix address is being added in?

19:39 <guessnbl> "flash bank $_FLASHNAME stm32f1x 0x08000000 0x20000 0 0 $_TARGETNAME"

19:53 <PaulFertser> guessnbl: still have issues?

19:53 <PaulFertser> guessnbl: why are you using flash write_image instead of the "program" helper?

19:53 <PaulFertser> guessnbl: how big is nuttx.bin?

19:53 <guessnbl> mmm... no particular reason. pretty sure I get the same error.

19:54 <guessnbl> I am actually flashing something much smaller.

19:54 <PaulFertser> guessnbl: please share -d3 log of an attempt somewhere.

19:54 <guessnbl> ok. will do!

19:58 <guessnbl> I found the problem. My loader script has the incorrect location for flash. Would that do it? ;)

19:59 <guessnbl> yep. fixed my flash memory region in ld script and flash works :) problem solved. Thanks for the rubber duck-ing.

20:01 <guessnbl> success. My program is running. "(7) r7 (/32): 0xDEADBEEF"

20:01 <PaulFertser> guessnbl: then the bin file would be huge

20:01 <guessnbl> am following this example but using openocd instead of other tools: https://vivonomicon.com/2018/04/02/bare-metal-stm32-programming-part-1-hello-arm/

20:02 <PaulFertser> guessnbl: btw, I recommend to always use "program" and "elf" files directly. This way you avoid many issues like stale "bin" or "hex" files, wrong offset when you manually specify it etc.

20:02 <guessnbl> cool. will do. :) the instructions are a bit old I think.

20:02 <PaulFertser> guessnbl: alternatively, you can flash right from "gdb" by simple "load". And GDB will auto-reload the elf if you do "make" or change the elf otherwise.

20:03 <PaulFertser> I mean you can type "make" right into gdb prompt.

20:05 <guessnbl> right. I am not too experienced just yet. Mostly just following existing instructions, not knowing all the possibilities. Cool. :)

20:14 <guessnbl> PaulFertser thanks for chiming in. Super happy I have a nice little tiny program running. :) Can't quite get gdb working with openocd in this case but debugging/halt/reg etc in openocd are good enough for me "for now".

20:14 <guessnbl> Cheers :)

20:15 <PaulFertser> guessnbl: enjoy :) gdb usually works nicely, just do "tar ext :3333" there, "file <your.elf>" and that's it. You can use "load", continue/c, press C-c to halt etc.

20:18 <guessnbl> that worked! I was trying to do "target extended-remote :4444" ah... I see, "tar ext" is short for that and I was using the telnet port and not the gdb port right? :)

20:18 <guessnbl> (obv not thinking about what I was doing) :)

20:22 <PaulFertser> guessnbl: exactly

20:23 <guessnbl> radical. now I can happily progress with learning more assembly/raw firmware on stm32f103 min board :) I've done nuttx stuff before but want to practice with ld/asm more. :)

20:23 <guessnbl> cheers.

21:52 <karlp> damnit, they left before we could tell them to stop copying shitty legacy "omg, asm!" bare metal crap tutorials

22:05 <guessnbl> karlp: yeah, if you have some better tutorials send them my way. :) thanks.

22:08 <karlp> basically, consider what the goal is, and why and how you found something.

22:08 <karlp> and what the roadmap is.

22:08 <karlp> what sort of tutorial are you really looking for?

22:09 <karlp> the pain is that people try and expoand this "minimal" examples and then run into pain.

22:09 <karlp> pain² even.

22:09 <guessnbl> yeah, the roadmap is me learning how to load and interact with a device (openocd etc) and programming low-level (asm/C) :) pretty much fitting the bill so far and definitely appreciate the help.

22:09 <guessnbl> mm... right... good point. re: pain^2

22:10 <guessnbl> I am mostly interested in reverse engineering chips and booting sequences, so lots of practice/knowledge around memory, interfaces, bringup, that sort of thing is where I play.

22:11 <karlp> so, cortex-m banner feature was not requiring asm for startup, so anyone who just goes and does that is doign things old school for no reason.

22:11 <karlp> and that linker script is completel useless if you want to start _doign_ anything.

22:11 <guessnbl> well yeah, I've fiddled with linker scripts before for sure :) much more complex certainly.

22:12 <karlp> sounds like you might be luycky enough to know when that blog post will run out of steam, lots don't

22:12 <guessnbl> right on. :) I appreciate the wisdom of experience from ya for sure.

22:13 <PaulFertser> guessnbl: in this case https://blog.zapb.de/ would be of interest to you

22:13 <karlp> PaulFertser: how?

22:14 <karlp> there's 4 articles total, one of them is promo for the coming article.

22:14 <PaulFertser> karlp: it's directly related to reverse engineering chips with plenty of details

22:14 <PaulFertser> And guessnbl wants to learn that.

22:14 <PaulFertser> And https://blog.includesecurity.com/2015/11/firmware-dumping-technique-for-an-arm-cortex-m0-soc/

22:15 <guessnbl> appreciate it. more sources is cool. :)

22:15 <guessnbl> my RE target is mediatek SoCs, 2g->LTE :p but I have this real life that keeps getting in the way ;)

22:15 <guessnbl> have used openocd a bunch in the past with nuttx and osmocom-bb :gratitude:

22:16 <PaulFertser> osmocom-bb !

22:16 <guessnbl> yes. :) I have a sciphone dream g2 laying around that needs some open source baseband :p