08:28 <PaulFertser> IoT-Maker: so what does u-boot say about that image you upload?

08:29 <PaulFertser> IoT-Maker: probably you're indeed not extracting it from the right offset. You can use u-boot to make a dump of the image from flash that it's not complaining about for comparison.

08:30 <IoT-Maker> PaulFertser: it complains ## No elf image at address 0x20000000 or whatever address it is loaded to

08:31 <PaulFertser> IoT-Maker: I suggest you try "md" to see how the image starting at 0x20000000 looks.

08:33 <IoT-Maker> PaulFertser: i already got a dump and it has the same MD5 sum as the file on the drobo device. I want to understand why it does not load the file to the address i entered

08:33 <PaulFertser> IoT-Maker: I mean compare dump of the file that it's able to load to the one you're loading, both taken by u-boot.

08:34 <PaulFertser> IoT-Maker: if you're using OpenOCD to load that ELF file for processing by u-boot then you need to specify an offset and treat it as binary.

08:35 <PaulFertser> IoT-Maker: because by default OpenOCD parses the ELF and loads loadable sections by itself.

08:35 <PaulFertser> That's why "it ignores 0x20000000"

08:36 <IoT-Maker> why do i need an offset? U-boot loads it to 0x20000000, why i can't do the same?

08:37 <IoT-Maker> ah

08:42 <IoT-Maker> i can upload the working vxworks image to wetransfer if anyone want to have a look into it.

08:59 <PaulFertser> IoT-Maker: 0x20000000 _is_ offset

08:59 <PaulFertser> IoT-Maker: WAIT

09:00 <PaulFertser> image_loc_Vx=2000000 this is not 0x20000000

09:00 <PaulFertser> This is 0x02000000

09:00 <PaulFertser> So you should be uploading raw binary there and then doing "bootvx $image_loc_Vx"

09:10 <IoT-Maker> PaulFertser: it loads it to 0x03000000 https://bpa.st/MUFA

09:11 <PaulFertser> IoT-Maker: that's because it's treating it as ELF, not binary.

09:12 <PaulFertser> IoT-Maker: "load_image /home/<user>/minicom_log/jtag/vxworks 0x02000000 bin" to force binary

09:19 <IoT-Maker> https://bpa.st/LW6A ok, its at 0x02000000 now, it says it loads it but it stuck at some point

09:20 <PaulFertser> IoT-Maker: so it least it accepts it now.

09:23 <PaulFertser> IoT-Maker: I suggest you try the same trick with the image extracted from flash to have a reference.

09:23 <PaulFertser> IoT-Maker: probably the method itself is missing something or probably the new image is not suitable yet.

09:24 <PaulFertser> IoT-Maker: I also see bootline when it's booting has extra ;UBOOT-2.33 s=#/romfs/runesa.vxe

09:24 <IoT-Maker> I already do this with this file.

09:24 <IoT-Maker> I will try td_bootargs_confab; run flashload_g0; bootvx 0x02000000 now

09:25 <PaulFertser> IoT-Maker: did you run "td_bootargs_confab" ?

09:25 <PaulFertser> " run flashload_g0 " will overwrite whatever you loaded to RAM though

09:33 <IoT-Maker> https://bpa.st/2TRQ tried td_bootargs_confab; bootvx 0x02000000 this time

09:35 <PaulFertser> IoT-Maker: another idea is to try manually running td_bootargs_confab; run flashload_g0; then halting, uploading to RAM, then resuming and doing bootvx 0x02000000

09:35 <PaulFertser> And samething but without halting/uploading/resuming.

10:41 <IoT-Maker> PaulFertser: It needs to do the whole process. Just loading the vximage now works. But after loading vxworks stuff it has to turn on linux stuff. I guess /romfs/runesa.vxe does some magic.

10:42 <PaulFertser> IoT-Maker: so some progress?

10:47 <IoT-Maker> I was looking into the firmware file for runesa.vxe. As i wrote before, the firmare file has 2 ELF images. And this command is present in both. What is interesting, the second ELF image uses runesa.vxe and runesa_prev.vxe to copy the images to flash memory, rename it and stuff. I think thats the part of the firmware update process.

10:49 <IoT-Maker> PaulFertser: I will do some tests later this day. Thanks for your patience so far.

10:50 <PaulFertser> IoT-Maker: best of luck, and I hope you manage to finally update it soon.

10:51 <PaulFertser> Looks like you're advancing there

18:05 <IoT-Maker> Oh wow, i just loaded the whole firmwarefile to 0x02000000 and did vxload 0x0200022c because the first ELF image in the firmware file has an offset of 0x22c. It startet and stuck with the info: ## Starting vxWorks at 0x01000000 ...

18:07 <IoT-Maker> I did that in U-boot and it suck there. I switched over to my openocd shell and did: resume 0x0200022c and it just startet to load vxworks. Thats the log.

18:07 <IoT-Maker> To my surprise i ended in a vxworks shell this time!!!

18:11 <bencoh> neat \o/

19:29 <PaulFertser> IoT-Maker: wow

19:29 <PaulFertser> IoT-Maker: sometimes experimenting doing "silly" things really pays off!

19:30 <PaulFertser> IoT-Maker: so supposedly you should be able to fully update now by regular means?

19:45 <IoT-Maker> I have to figure out how this vxworks stuff works and what commands i need to enable network and drive access. It's my first contact to vxworks.

19:48 <IoT-Maker> For the record, i did bootvx not vxload as i wrote in my comment at 19:05:05