RomRaider

Any update on that reflash app?

User interfaces are hard, kernels are hard.

so tl;dr no.

If someone has the kernel from ECUflash for the CAN based Subarus which I think do also use an SH7055, it may be helpful..

User Interface I can help with. Kernel i can not
A 7055 or 7058 kernel would be amazing if there were one out there though.

I had to make a 7055/7058 kernel for reflashing Nissans over the K line. It can probably be repurposed for your ECUs much easier than writing one from scratch.
https://github.com/fenugrec/npkern

let me take a look at this. Bytes are bytes no matter how you send em. CAN IMO is easier to deal with, and I know how to send info that way no issue.

I think the main challenge with CAN will be splitting and ordering longer packets into the 8-byte frames; npkern takes 128-byte chunks while reflashing.

The main file you'll changing is cmd_parser.c which is pretty hardcoded to use iso14230 format of SID requests+replies (which could perfectly well be sent as iso15765 aka iso-TP traffic with minor tweaks).

Also probably some housekeeping in main.c and platf_7055.c according to your ECU needs (external supervisors to deal with and whatnot).

But first and most fun, need to handle the cpu jump-to-RAM handover ; see start_705x.s

The code is GPL'd so you're welcome to hack at it; file issues on github if you want to discuss details. Heck if it can be done cleanly we could even merge it into one codebase.

Yeah, I had a quick look on Saturday night pretty late but my eyes started to roll into the back of my head around 1am. Still a lot to take in, and I haven't done a whole lot of professional work with Renesas processors so every step of code is a long process of understanding.

It looks like this is a compiled app that you can run to flash stuff, this right now IMO is the biggest limiting factor for me personally just because I have REALLY good CAN tools, and I just need compiled code in a .bin file to upload to a module to prove out the functionality of a kernel and reflash process. J2534/serial integration came come next in my head. That process in my head may just be fuzzy because I still find it hard to comprehend the bootloader receiving code and executing it (i do app software, okay!).

For sure, the first step is to get "arbitrary code execution" working - sending a payload and validating that it runs. For me that was a handful of bytes just to crash the CPU and watch it timeout + reset with a logic analyzer, but it was enough to confirm I was running from RAM.

Next step would be sending CAN heartbeats from a minimal kernel just to see if can stay operational and stable (and debug any external supervisor/watchdog circuits that need to be tended)

I was able to upload what I thought was the kernel sent by a known good flash tool, but I kept getting some UDS upload errors... so I think I need to get past that first.

Thanks for the insight, someday I'll have more time for this project

I'm also going down the rabbit hole of ECU disassembly/modification for an 06 Shinka, mostly in Ghidra/HEW.

I'll try to contribute anything pertinent as I come across it.
There's so much surface area to look through on the ROM I've found myself off on tangents instead of getting to the meat and potatoes of adding in another RPM based switched output...

EDIT: nevermind I am a moron.

bump anyways I guess!

Finally had some time to get my build enviornment setup.. running into an issue compiling cmdparser... looks like it includes npk_ver.h which looks for a "version.h" file which I don't see in git and obviously not in my folder stucture

Not too sure of the purpose of this, but my guess is just a hard written version number in the binary or is the cal ID of the module the kernel is looking for?

I just hardcoded it to some char so the compiler was happy.. but.. yeah..

Also: Not too sure which 7055 target I need to compile for. 350nm or 180nm?? Is there a part number on the processor that'll tell me which one it is?

It should get generated automatically when you run cmake (needs git to produce the version string).




https://nissanecu.miraheze.org/wiki/Sh_docs

Short story : "7055SF (0.18um), ~ 2003 onwards ? " . Before 2003 is ~guaranteed to be 350nm. Hard to tell for 2003-2005 IMO.

In any case it's impossible to flash / brick with the wrong kernel, the code is completely different and npk should report a "wrong silicon" error.

ah yep.. not using git.. figured that was the case. If it's just a git sha it uses then I don't care about hardcoding it right now.

and of course there's docs that I didn't read LOL. Perfect.

Trying to now to get some code written but as usual I am lost in the sauce.

Dumb questions to confirm what I assume I know.

This kernel gets sent to the ECM via a flash tool of some sort using Transfer Data (0x36) or whatever method. The tool is then going to send this kernel, and the kernel will handle the rest of the incoming sent data from the tool?? Am i understand that process correctly?

I'm just getting lost as to where the bootloader and the kernel handle things from a conceptual level.

Pretty much. On Nissan: (https://nissanecu.miraheze.org/wiki/Fir ... _execution )

- SID 27 exchange
- SID 34 80 RequestDownload;
- SID 36 TransferData, send the kernel encrypted with the "sid 36" key; ECU decrypts+copies to &RAMjump (often FFFF8438 but varies)
- SID 37 TransferExit
- SID BF 00 ReqRamJumpCheck
- SID BF 01 ReqRamJump : jumps to &RAMjump !

Then npkern takes complete control, changes comms speed, and accepts a custom set of commands (SID 34, BC, etc) for erasing and reflashing, sill with basic iso14230 framing. Supported commands are documented in iso_cmds.h