10:20 <gamiee> Hello. I am working on Flash bank driver for RISC-V chip. To avoid having another assembly code in OpenOCD, I want to re-use BootROM functions for initializing everything necessary for flashing. Sadly, some of the functions uses global variables (stored in RAM), so I will backup the area, write data it needs, and after procedure it will restore it. Is this good? Or I rather should use another approach?

10:23 <Haohmaru> is this the "helper firmware" openocd puts onto the target to make flashing faster?

10:27 <gamiee> Haohmaru: actually I want to avoid "helper firmware" at all, and instead, call BootROM functions (through simple trampoline).

10:28 <Haohmaru> no clue then, i'm unfamiliar with risc-v

10:29 <Haohmaru> stick around till the others wake up

10:30 <gamiee> Haohmaru: I got trampoline working, I am just wondering if this is okay to do, mainly the part, where I backup some RAM areas whose BROM func uses for some information.

10:31 <Haohmaru> *shrug*

10:31 <gamiee> Also, the trampoline is simple and uses existing stuff in OpenOCD. Right now, I am just constructing two instructions, one which jumps to func, and second bkpt (ebreak on RISC-V), writing it to the work-area, and execute it through "run_algorithm" API. Although, I probably will rework this to use PROGBUF, what is small buffer within RISC-V Debug Module, where debug probe can put small instructions to execute, so I don't even need work-area.

10:32 <gamiee> (+ everything executed from progmem is in highest elevation, what is nice)

10:33 <Haohmaru> as i have no clue about most of those details, in overall it sounds okay ;P~

10:44 <karlp> gamiee: most of the flashing algorithms rely on having a defined work area of ram, and we never try and save or back it up,

10:44 <karlp> so I'd say just let the flashing algorithm use globabls if i tneeds them...

10:45 <gamiee> karlp: Hi! So I can treat that when the flashing by openocd happens, it can "modify" anything, as there is expectation that the chip will be reset after flashing is done?

10:46 <karlp> that's always been my understandinga s a user, and it certainly seems inline with existing behaviour as far as I can tell.

10:46 <karlp> at least as far as within the "work area" defined.

10:47 <Haohmaru> if the typical scenario is to (erase the chip? and) flash a new firmware and then run it - the RAM shouldn't make much difference

10:47 <karlp> fwiw, we're going to end up with riscv compiled sources sooner or later anyway, not all rv targets will have bootrom available.

10:47 <karlp> (you can noramlly write the flash helpers in C instead of assembly anyway....)

10:48 <Haohmaru> there may be rare cases where the RAM is used in exotic ways, for example my bootloader uses a small chunk in the beginning of RAM to store a special structure with which it "communicates" with the firmware

10:49 <Haohmaru> thus i don't clear this chunk of ram on reset

10:49 <Haohmaru> but this is "exotic"

10:49 <Haohmaru> and if i'm gonna be poking with debugger, then i'll probably be putting a new bootloader anyway

10:54 <gamiee> when I can use BootROM functions just fine. (and in case of needing to do tiny reg manipulations, I will do that from driver through JTAG).

10:54 <gamiee> karlp , Haohmaru : why I am thinking about this is that in future, there might be things like eFuse manipulation or other features, which might not need reset after them being done, but yeah, generally, reset is expected after flash, so I guess it should be fine and I don't need to do any backups. And yeah, I know I can write loaders in C, but I wanted to generally avoid to write any helpers/loaders to not add into OpenOCD another platform-related code,

10:56 <Haohmaru> no idea about that, but i guess if you want to not disturb the RAM, you could maybe first read the chunk of RAM via openocd, store it in a buffer on openocd's side (aka on the Computer), do your thing, and at the end write it back to the target?

10:57 <gamiee> Haohmaru: that's exactly what I was thinking of doing, backing up the area I will use and might disturb another code. But from this conversation, I think it's not needed, as we expect reset, and if any feature which doesn't need reset will be added, backing up can be added as well.

10:58 <Haohmaru> well, alternatively, someone should point out a usecase/scenario or a situation where you might legitimately need to "write a pile of flash via openocd" without resetting the target

10:59 <Haohmaru> i'm not too familiar with the whole thing so i don't know

10:59 <gamiee> there is scenario when user wants to only read the flash. In that case, we don't need to reset after.

11:00 <Haohmaru> i suspected something like that

11:01 <Haohmaru> oh, actually, now i remember, when i debugged an xmega, and it failed to load the debug symbols (or i failed to supply it properly) the program (the IDE maybe) basically read the whole binary from the target so it can at least show me the "ASM" at the current position and stuff like that

11:03 <Haohmaru> backing up the RAM temporarily into openocd's memory and then restoring it shouldn't be too difficult if the amount of RAM needed is known

11:07 <gamiee> Haohmaru: It's just few bytes which needs to be backed up from RAM. (work-area is in TCM, which is automatically backed up by openocd) So I guess it should be fine.

11:26 <karlp> Haohmaru: it's definitely not required to do a reset after flashing, just common.

11:27 <karlp> sometim es you're flashing a different section...

11:27 <Haohmaru> that too