Added Subaru commands, for review/merge

[rimwall]

See ssmk_test branch in my fork. One thing needs fixing: the kernel load address is hard-coded as 0xFFFF3000. This needs to be made variable based on 7055/7058. Open to ideas on the most efficient way? One option might be (for Subaru) to have 'setdev' command set a variable to 0xFFFF3000 or 0xFFFF6000 (this variable unused for Nissan). And 'sprunkernel' command would check this variable has been initialised before proceeding.

[fenugrec]

I merged your work mostly as-is (note, I added a seperate ssmprog.ini instead of modifying nisprog.ini) , and then reworked the backend code somewhat. i.e.

what was all bundled in np_backend.c can be more logically split as a
function of "what runs on the ECU" :
 - Nissan stock ROM : np_backend
 - Subaru stock ROM : ssm_backend
 - npkern (regardless of ECU) : npk_backend

For 7055/7058 : I added a field to flashdevices[], so it should be possible in cmd_sprunkernel() to do something like e.g.

    const struct flashdev_t *fdt = nisecu.flashdev;
    if (!fdt) {
        printf("device type not set. Try \"setdev ?\"\n");
        return CMD_FAILED;
    }
     switch (fdt->mctype) {
   case SH7055:
 ....

( See npk_backend.h, .c)

[rimwall]

Fantastic! Quite a bit of work in that, thanks very much. It's much neater now.

I've added the code and tested it. Also some minor changes in nisprog and npkern (see branches under each repo).

Let me know if you're happy with those changes and then we're ready to let the folks on RR know, along with a request for some SH7055 testing volunteers.

[fenugrec]

I'll take a closer look later but for now I notice this change

       load_addr = 0xFFFF3000;
...
-   if (sub_sid34_reqdownload(0xFF3000, pl_len)) {
+   if (sub_sid34_reqdownload(load_addr, pl_len)) {

so you changed from a FFxxxx format to FFFFxxxx - does this matter ?

[rimwall]

Yes, I did that to improve readability. Both SID 0x34 and SID 0x36 only use the lower 3 bytes of the address because they assume the highest byte is 0xFF.

[fenugrec]

In your sid31 code, what does this mean txdata[2]=0x01; // this should be 0x01 - intentionally wrong so ECU doesn't do jump ?

[rimwall]

Ah, good pickup, only the comment is incorrect. It came from when I wanted to get through all the SID commands to get ready to jump, but not actually jump because the kernel wasn't ready. I have deleted this comment in my branch.

[fenugrec]

Merged, thanks!