ec_ocd.cfg

source [find cpu/arc/arcompact.tcl]
source [find cpu/arc/em.tcl]

set _CHIPNAME arc600
set _TARGETNAME $_CHIPNAME.cpu

jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -expected-id 0x200024b1

target create $_TARGETNAME arc600 -chain-position $_TARGETNAME 

arc jtag wait-until-write-finished on
$_TARGETNAME configure -event reset-assert "arc_arcompact_reset $_TARGETNAME"

arc_arcompact_init_regs

arc jtag wait-until-write-finished on leads to double memory writes for that particular chip, so you have to turn it off (see this). Other than that flash controller behaves exactly as in MEC1618 (datasheet is freely available). I managed to program thit chip using just FT2232H JTAG and some python code to take binary and send it to the controller. It should be possible to write a complete openocd flash driver just using that datasheet, I think

@dossalab hi, could you share some additional details about how to talk with the Flash controller? I've been successful in talking with an MEC5075 with a USB-Blaster, the above configuration file and the arc-2021.09 release of openocd (with a bunch of backported patches to make it build on a newer system), this allowed me to dump the address space where the Flash is mapped. However I'm not able to get the Flash controller to do anything, if I try to erase/program it doesn't do anything and the EC resets after a few seconds, I can't read anything either. Maybe the MEC5075 doesn't have the same register map or (more likely) I'm doing something wrong.

@piernov I'm not really sure if I can help you with this, since it was quite some time ago and I did it only as a part-time gig (I just wanted to fix my poor Thinkpad which got roasted by a faulty charger). After I managed to flash the firmware I just assembled my laptop back and called it a day.

I'm not sure if MEC5075 is different from MEC1633, but it seem to be supported by SVOD - so they managed to talk to the flash somehow....

What exactly did you try so far? May be document that and I'll see if I can spot any potential issues.

@dossalab thanks for your answer. In fact, I managed to do what I want.
I was just not properly initializing the Flash controller after reset. (took a look at the Glasgow implementation to get a hint)

In my case I wanted to put a Dell board in manufacturing mode, so I erased the pages at address 0x47000 and 0x47800, with the following OpenOCD commands:
Warning: do not run this before making a backup!
Always make a backup before erasing/programming anything, you can dump the memory (with dump_image for example) since Flash is mapped at the beginning, just that by default the first 4 kiB are protected but we are not touching these.

reset halt
# Initialize Flash controller
mww 16726288 1
mww 16726280 256
mww 16726284 1792

# Erase first page
mww 16726280 259
mww 16726276 0x47000
mdw 16726284

# Erase second page
mww 16726280 259
mww 16726276 0x47800
mdw 16726284

(sorry for the mix of decimal and hexadecimal)

You need to wait just a little bit between erasing the two pages since the controller is still busy (as indicated by the status register), no too long because the EC will end up resetting after short while when it's halted (there's probably a watchdog somewhere).
Would be nice to have a proper script or Flash driver but this will do for now. For some other purposes I need to program the entire Flash and this will need some more work.

@piernov
Pretty cool! Glad that you figured it out.
My thinkpad still has UUID and machine ID emptied after the reflash, so maybe I'll return to that project some day...
Having OpenOCD as an alternative to closed-source "repair" programmers would definitely benefit some folks out there...

@dossalab
"I managed to program thit chip using just FT2232H JTAG and some python code to take binary and send it to the controller. "
Would you mind sharing that python code please?

@dossalab "I managed to program thit chip using just FT2232H JTAG and some python code to take binary and send it to the controller. " Would you mind sharing that python code please?

I found something, even though it's most likely an initial version. It connects through telnet to a running OpenOCD instance and sends direct reads and writes and talks to the controller... I've given you access in private but if it works fine I'll happily disclose it for the public.
You'll need the correct openocd script with the fix I mentioned before.

The way to go would be to write the 'correct' driver for OpenOCD. May be that's the time....