10:40 <IoT-Maker> PaulFertser: I loaded the vxworks image into Ghidra for inspection. But because lack of knowledge, i couldn't figure out how to determine in Ghidra if the ELF file is statically or dynamically linked.

10:41 <IoT-Maker> PaulFertser: I found emba which does automatic analysis. It inspected the vxworks [ELF] file and says: /logs/firmware/bin/vxworks: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, with debug_info, not stripped

10:46 <IoT-Maker> PaulFertser: In openocd i set arm core_state arm (I guess that is what you mean "If the instruction you run first is in ARM mode then you need to make sure PSR is in ARM too")

11:15 <PaulFertser> IoT-Maker: this looks like a userspace app so how do you plan to run it without the OS kernel?

11:16 <PaulFertser> Or is it the kernel itself?

11:18 <IoT-Maker> PaulFertser: It's the first time i have to do with vxworks stuff. I tought it's all in the vxworks image and i just have to swap the files or for testing purpose, load the ELF image to ram and run it.

11:20 <IoT-Maker> If loading to ram won'T work, i would replace the vxworks image in NOR-flash and hope u-boot will pick it up and run it.

11:20 <PaulFertser> IoT-Maker: either way for loading ELF you shouldn't just copy it byte-by-byte to a random RAM location.

11:21 <PaulFertser> IoT-Maker: you can load ELF to RAM with "load_image" with OpenOCD but you need to take care yourself to set PC to the entry point and to fulfill all the expectations of the image.

11:22 <PaulFertser> IoT-Maker: so you have u-boot working there?

11:22 <PaulFertser> Then you should be able to see what exactly it loads and how exactly.

11:25 <IoT-Maker> Yes, Marvell style u-boot starts, loads vxworks which is stuck at some point waiting for something from linux i guess which starts to load. I can enter the linux side, but vxworks side doesn't finish boot process, there is no shell at the end.

11:26 <IoT-Maker> To me it looks like the linux side was updated during firmwareupdate but the vxworks side not. It's the old vxworks image that starts i guess.

11:30 <IoT-Maker> PaulFertser: This is u-boot's printenv output https://bpa.st/WY7Q this is vxworks bootlog https://bpa.st/GWEQ and this is the linux bootlog https://bpa.st/EXWQ

11:32 <IoT-Maker> PaulFertser: this are the files i can see in u-boot https://bpa.st/KWIA i added some comments

11:50 <IoT-Maker> There is no network and only few commands available in Marvel u-boot: https://bpa.st/N7RA

11:51 <PaulFertser> IoT-Maker: does u-boot have "loady" probably?

11:51 <PaulFertser> IoT-Maker: or you can just upload something to RAM location and then ask U-boot to run it.

11:52 <PaulFertser> ("just upload" I mean via JTAG)

11:52 <PaulFertser> IoT-Maker: my idea is to load the tweaked code by any means and then continue with u-boot.

11:59 <IoT-Maker> PaulFertser: loady command is present

12:00 <PaulFertser> IoT-Maker: so you can just Y-modem load anything to RAM by just serial alone.

12:01 <PaulFertser> Also it looks like this device can just boot from USB mass storage.

12:02 <PaulFertser> By running flashboot_g0

12:07 <IoT-Maker> I guess that is the 8bay hdd storage. There is no USB port exposed

12:12 <IoT-Maker> There are some pin holes that could fit to a USB Port https://postimg.cc/1863T79m/a6d81787

12:15 <IoT-Maker> Or it'S one more Ethernet port. i don't know.

12:19 <PaulFertser> IoT-Maker: ok then, just loady to $image_loc_Vx and run flashboot_g0

13:46 <RolfNoot> I got the problem with the 'stdio' references. Line 29 of configuration.h (FILE *open_file_from_path...) depends on helper/command.h -> helper/jim-nvp.h -> jimtcl/jim.h

13:47 <RolfNoot> The OpenOCD version has #include <stdio.h> on line 74 of jim.h while the official version doesn't have it there

14:16 <PaulFertser> RolfNoot: OpenOCD doesn't apply any patches to jimtcl

14:17 <PaulFertser> RolfNoot: so newer version of jimtcl lacks it and that breaks OpenOCD?

14:18 <PaulFertser> RolfNoot: in 41f431f30cc6118ef982c6374914810cd07a8106 they removed it

14:19 <PaulFertser> Yes, OpenOCD shouldn't depend on stdio.h getting include via jimtcl and should include it explicitly where needed.

15:08 <RolfNoot> PaulFertser: exactly, that's why I wanted to mention it

15:13 <PaulFertser> RolfNoot: good catch, please feel free to send a patch :)

15:14 <RolfNoot> PaulFertser: thank you, will do :-)