08:57 <IoT-Maker> i want to load a firmwareimage to ram and run the system with it. In openocd i did: load_image /home/<user>/minicom_log/img/release.B810i.2-0-1.tdf 0x20000000. Is there anything to do other than just reset run?

09:04 <IoT-Maker> I tried resume 0x20000000 and it seems it starts from nor-flash

09:22 <PaulFertser> IoT-Maker: resume should do the thing. But in Cortex-M you do not have actual branch instruction at the beginning, you have the stack pointer and reset vector pointer.

09:22 <PaulFertser> Which need to be taken care of.

09:23 <IoT-Maker> it's a Cortex-A, Marvell ARMADA XP ARM7 SoC

09:28 <IoT-Maker> Hmm, the first ELF image in this firmwarefile has an offset of 0x22c, maybe i have to resume at 0x2000022c then?

09:34 <PaulFertser> IoT-Maker: yes, you need to resume to the entry point.

09:35 <PaulFertser> IoT-Maker: you can also set $pc manually and then do "step" few times to see how it goes.

09:38 <IoT-Maker> There is a SPI flash with u-boot on it. It seems thats where it starts from. Then it loads default system from nor-flash. Even if i resume from 0x2000022c.

09:40 <PaulFertser> IoT-Maker: resume doesn't toggle reset so it shouldn't do that.

09:40 <PaulFertser> IoT-Maker: set pc manually and see how it goes step by step

09:56 <RolfNoot> PaulFertser: contrib/cross* isn't for MacOS, right?

09:57 <PaulFertser> RolfNoot: why not? It automates the steps that should be applicable to any system.

09:57 <PaulFertser> If you have a cross-compiler for it.

09:58 <RolfNoot> PaulFertser: readlink -f isn't working on MacOs

09:58 <PaulFertser> RolfNoot: the script has readlink -m

09:59 <RolfNoot> readlink: illegal option -- m

09:59 <IoT-Maker> ok, i'm beginner, i had to check what pc mean, programm counter, i read: get_reg {pc sp} and the result was: pc 0xffff0928 sp 0x00000000. I did set_reg {pc 0x2000022c} and load the image to that address

09:59 <PaulFertser> RolfNoot: also, I'm not sure if "fully native" macOS build is supported at all, people build OpenOCD for macOS via brew or macports. So cross-compiling should be performed with the same environment I think.

09:59 <karlp> you should load the image to the same place you downloaded it from. you don't want to offset it...

10:01 <RolfNoot> PaulFertser: that makes sense. I was just wondering if it's documented and easily to use. I was looking for it to do quick tests.

10:04 <PaulFertser> RolfNoot: but you still have some additional environment on macOS, so why not use it for cross-compiling?

10:05 <RolfNoot> PaulFertser: you mean a VM?

10:06 <PaulFertser> RolfNoot: I mean Homebrew or MacPorts or Gentoo prefix or similar.

10:07 <RolfNoot> PaulFertser: yes, I can install readlink wit MacPorts, but there's one built in as well. It's cumbersome to set all the paths

10:08 <PaulFertser> RolfNoot: probably there's a more standard way than readlink -m that can work on macOS natively.

10:08 <PaulFertser> But you still need all the other parts like pkg-config and cross-compiler etc.

10:08 <RolfNoot> PaulFertser: Yes, those are already installed

10:09 <RolfNoot> readlink -f is supported on MacOS though, so maybe it's easy to change the script

10:10 <PaulFertser> RolfNoot: yes, -f sounds appropriate for the job too

10:11 <RolfNoot> PaulFertser: I will check if that works probably later today.

10:17 <karlp> what about realpath?

10:18 <karlp> oh, nvm, that's coreutils only, whtever

10:18 <karlp> I'll just keep using that myself by hand :)

11:14 <IoT-Maker> Tried different ways now. load_image to 0x0, set_reg {0x22c} resume at 0x22c, load_image to 0x20000000 set_reg{pc 0x2000022c} and resume from 0x2000022c, stepping from both addresses. But it always starts from SPI-flash. And after two trials it does a soft reset or something that turns the device off. This is the serial port log https://bpa.st/MHIQ

12:47 <IoT-Maker> If i set_reg {pc 0x2000022c] and do a step, the next get_reg {pc} show me 0xffff000c addresses. Is that normal? I expected an 0x2000... address. https://bpa.st/5YSA

12:53 <IoT-Maker> BootROMstarts at 0xFFF00000

12:55 <PaulFertser> Have you checked disassembly for 0x2000022c ?

12:55 <PaulFertser> And is PSR in the right mode (ARM)?

15:56 <IoT-Maker> PaulFertser what is PSR and how can i set it's mode? I read there is thumb mode or arm mode. The forum posts i found was about developing/recompiling software. But in my case i only have a firmware file. I opened it with Malcat which show me 4 modules inside. Two of them marked as ELF. First one fits to the size of the SPI flash (Device is a Drobo B810i NAS) and the second ELF module looks like vxworks image. Third

15:56 <IoT-Maker> one is a jffs2 (linux-)image.

15:56 <PaulFertser> IoT-Maker: PSR is the special register. If the instruction you run first is in ARM mode then you need to make sure PSR is in ARM too.

15:57 <PaulFertser> IoT-Maker: ELF files can not be uploaded to a RAM location as is. You need an ELF loader.

15:59 <IoT-Maker> Ok, so i have to extract the ELF files, write it to nor-flash and change some u-boot variables i guess.

16:01 <PaulFertser> IoT-Maker: are those elf files relocatable? Do they use shared objects?

16:01 <PaulFertser> IoT-Maker: OpenOCD can load ELF files on its own but that's mostly used for microcontroller code linked fully statically.

16:09 <IoT-Maker> PaulFertser: I don't know if they use shared objectes. It's my first vxworks device. I just try do fix a failed firmware update. I know the linux jffs2 part was extracted from firmware and installed on the device but vxworks not.

16:10 <PaulFertser> IoT-Maker: you probably want to inspect that ELF file with radare2 or Ghidra first.

16:12 <IoT-Maker> firmwarefile is this one https://files.drobo.com/webrelease/b810i/B810i_Firmware_2-0-1.zip there is only one single tdf file inside.

16:30 <RolfNoot> Still building with contrib/cross-build is very cumbersome on MacOS

16:32 <RolfNoot> I think the script is quite outdated or not compatible with newer releases

16:32 <RolfNoot> I will move to native building, guess that works better

16:33 <RolfNoot> Some problems I run into:

16:34 <RolfNoot> building libFTDI: Could NOT find LibUSB (missing: LIBUSB_LIBRARIES LIBUSB_INCLUDE_DIR)

16:34 <RolfNoot> while the script had just built LibUSB without issues

16:35 <RolfNoot> when building Capstone: i686-w64-mingw32-gcc: fout: unrecognized command-line option ‘-arch’

16:37 <PaulFertser> This script is used by ST to build their Windows binaries.

16:37 <PaulFertser> And probably by riscv fork too.

16:38 <RolfNoot> when building libjaylink: Users/rolf/openocd-cross/libjaylink/config.guess: No such file or directory

16:38 <RolfNoot> and /Users/rolf/openocd-cross/libjaylink/configure: No such file or directory

16:39 <RolfNoot> while libjaylink is cloned into /Users/rolf/openocd-cross/libjaylink

16:40 <RolfNoot> PaulFertser: Okay, probably they made changes or use other sources / versions.

16:40 <RolfNoot> PaulFertser: maybe it will work better on Linux as well

16:40 <PaulFertser> Probably it assumes you have released versions which has "configure" file.

16:41 <PaulFertser> As the script doesn't run autoreconf for those additional libraries.

16:41 <RolfNoot> yes, so I need to bootstrap

16:53 <RolfNoot> the script seems to build without libftdi, only cross-compiling is slow. Will check if I can set -j12 for the compiler

17:18 <PaulFertser> RolfNoot: yes, just set MAKE_JOBS prior to running

17:18 <PaulFertser> export MAKE_JOBS=$(nproc)

21:54 <RolfNoot> PaulFertser: thanks, that works