subaru : 7055 support

[fenugrec]

@rimwall

Add info here

[rimwall]

Thanks. The only changes I have identified are:

• Allowed RAM area for kernel load is 0xFFFF6000 to 0xFFFFDFFF
• RAMJump destination is 0xFFFF6004

I will have a go at creating .s and .lkr files. Nisprog code will also need to be changed (as the kernel load and RAM Jump commands are hard coded to 0xFFFF3000).

[fenugrec]

Probably the same .s file can be used ? The first two NOPs should not be a problem

[rimwall]

I started creating this file in a new branch, but that branch would have ended up with files that still have my edits and not your improved edits in 'ssmk_test'. I guess I first need to get my 'master' the same as your 'master', and then create a 'ssmk_test' branch which is the same as your 'ssmk_test'. I think? Not sure how I do this? Or do I just delete my whole repository, re-fork the master from yours and create a branch in which to make changes...?

In terms of how to do this, it's a little more complicated because the nissan technique puts the erase/write microcodes right at the fixed RAMJump address. So, I think some extra conditional defines will be required in pl_flash_705x_180nm.c that are similar to the conditional defines in platf.h. Then, for Subaru 7055_18, the addresses will be:

• Kernel at 0xFFFF6000 (with 2 x nop at the start)
• Stack at 0xFFFFBFFC (LENGTH = 24K in *.ld file)
• Erase Microcode at (eg) 0xFFFFC000
• Write Microcode at (eg) 0xFFFFC800

Yes, agreed, the same *.s file can be used.

[fenugrec]

I started creating this file in a new branch, but that branch would have ended up with files that still have my edits and not your improved edits in 'ssmk_test'. I guess I first need to get my 'master' the same as your 'master'

Right, that's why usually when you fork a project like this you keep both masters identical, and any "special work" on branches.

There's a few ways to proceed, but I'm not sure how to do it via the github web UI. I always work from the console and control git directly... deleting your branch + recreate your fork is the "sledgehammer" solution, only do this if you're sure you saved all work.

In terms of how to do this, it's a little more complicated because the nissan technique puts the erase/write microcodes right at the fixed RAMJump address

Oops, I hadn't noticed this. Well, there's a few solutions. The one you outline mostly works, but:

* Erase Microcode at (eg) 0xFFFFC000
* Write Microcode at (eg) 0xFFFFC800

FTDAR only lets you select areas between ffff6000 and ffff8800. But it's true that e.g. loading the microcodes at ffff8000-8ffff , leaves a 8kB window ('6000-'7FFF) for the kernel - should be enough for the foreseeable future.

Another solution could be:

• on 7055/7058, set the linker to assume the kernel will run from ffff8000
• change start_ssm.s to do like the nissan kernel and self-move to ffff8000, no matter if it was loaded at '3000 or '6000
• keep current behaviour of loading microcodes at ffff6000,6800 on 7055 and ffff1000,2000 on 7058

[rimwall]

My master is now aligned, with changes in ssmk_test branch

it's true that e.g. loading the microcodes at ffff8000-8ffff , leaves a 8kB window ('6000-'7FFF) for the kernel - should be enough for the foreseeable future.

I've done the edits for this option, seemed less chance of me stuffing it up! See ssmk_test branch in my fork.

[fenugrec]

Merged, thanks !