PCM Hammer P12 development

[antus]

so bytes are the x8 column, words are the x16 column. pcmhammer has bytes. the new chip seems to always be in words. so yes it is a mindfuck. when you put the values there, are you using what pcmhammer needs? or the kernel needs? and does it matter if you use byte or word in the kernel? and if it is in word mode, what needs to change? which I believe was your original question. Ive had fun typing this up and looking at code, but the only two ways to get the answer are trial and error, and/or disassembling the vin save routine (or similar) in the bin and working backwards from the code that erases and re-writes the param block and take the learnings back to understanding the datasheet, then work forward back towards getting the chip id.

[Gampy]

Good choice of word ... And yea it does exactly that to me!

PCMHammer needs that, the kernel is all about bytes!

To write to the chip, the kernel code is going to need changing, it currently writes by byte.

Obviously if I'm not just a dummy here ... I could very well be, never claimed to be the sharpest knife in the drawer!

[antus]

I dont think the mode matters much so long as you address it correctly. your objective is to understand how to get the chip to register the command sequences in the datasheets and once you have that, the rest should fall in to place. which command doesnt matter much, as once you have that result your learnings can be transposed to other commands in the data sheet and the write process.

for example, this is semi-random from the ida file early in the thread. with the AAA AAAA and 5555 554 in there it must line up to the data sheet for one of the commands. and if thats not enough on its own then need to go back a level and find what is being written to the SIM registers first (which really means find the sim registers on this architecture). Im not completely sure that whole file is a write kernel, it looks more like an SDK from freescale with multiple chips in it. So finding the same in the bin would be a more reliable source.

Code: Select all

AM:FFFF2070 sub_FFFF2070:                           ; CODE XREF: sub_FF2476+40↑p
RAM:FFFF2070                                         ; sub_FFFF2478+3E↓p
RAM:FFFF2070
RAM:FFFF2070 arg_2           =  6
RAM:FFFF2070
RAM:FFFF2070                 movem.l d4-d7,-(sp)
RAM:FFFF2074                 move.w  $10+arg_2(sp),d4
RAM:FFFF2078                 movea.l #unk_FFFF2318,a0
RAM:FFFF207E                 moveq   #0,d0
RAM:FFFF2080                 move.w  d4,d0
RAM:FFFF2082                 move.l  (a0,d0.l*4),d4
RAM:FFFF2086                 movea.w #$AAA,a0
RAM:FFFF208A                 move.w  #$AAAA,d5
RAM:FFFF208E                 move.w  d5,(a0)
RAM:FFFF2090                 move.w  #$5555,d1
RAM:FFFF2094                 move.w  d1,($554).w
RAM:FFFF2098                 move.w  #$8080,(a0)
RAM:FFFF209C                 move.w  d5,(a0)
RAM:FFFF209E                 move.w  d1,($554).w
RAM:FFFF20A2                 movea.l d4,a0
RAM:FFFF20A4                 move.w  #$3030,(a0)
RAM:FFFF20A8                 moveq   #$FFFFFFAA,d1
RAM:FFFF20AA                 moveq   #$55,d0 ; 'U'

edit: this is in the bin though, its a starting point.

amd bin.png

it looks like the one with the init sequence the 8080 is chip erase, and the one with init then C0C0 is burst mode, whatever that is. Note how the code is doubling up on the command byte, compared to the datasheet.

[antus]

Not sure if Im speaking the same language but I see the challenge like this:

code2data.png

First, FFFA7E must be one of the sim registers, the one that matters for command mode. first its set to whats needed, but whats in word_ca4 at this time?
Next we prepare AAA for use, then move AAAA in to it. Which is the implementation of what bus cycle 1 is describing. Note that its got nothing to do with 555, so Im thinking byte mode and the datasheet is incomplete, and the P59 data sheet is still valid.
Next we move 5555 in to loc552+2. which is address 554. Datasheet says 55 in to 2AA.
Next its C0C0 to AAAA (which is still in register a0). datasheet says C0 in to 555.

So, pretty sure we have the SIM register, the init sequence.

So if you could fill in the blanks and know what to write to the sim, use the same code, replace the C0s with 90s, then read the top word of the block for manufacturer, or the word after it for device id you'd be winning.
Then write the original flags back in to the SIM to exit command mode.

Still sounds pretty similar to the P59, just need the SIM address mainly.

Also I note that in flash.h from the P59 kernel we have:

#define SIM_BASE 0x00FFFA00
#define SIM_CSBARBT (*(unsigned short *)(SIM_BASE + 0x48)) // CSRBASEREG, boot chip select, chip select base addr boot ROM reg,
// must be updated to $0006 on each update of flash CE/WE states
#define SIM_CSORBT (*(unsigned short *)(SIM_BASE + 0x4a)) // CSROPREG, Chip select option boot ROM reg., $6820 for normal op
#define SIM_CSBAR0 (*(unsigned short *)(SIM_BASE + 0x4c)) // CSBASEREG, chip selects
#define SIM_CSOR0 (*(unsigned short *)(SIM_BASE + 0x4e)) // CSOPREG, *Chip select option reg., $1060 for normal op, $7060 for accessing flash chip
#define HARDWARE_IO (*(unsigned short *)(0xFFFFE2FA)) // Hardware I/O reg

so FFFA7E is damn close to the P59 SIM registers, but different. Maybe just another small tweak to move SIM_BASE.

[Gampy]

You know me, I like to eat one bite at a time, the current bite I'm chewing/choking on is FlashID ...

That table is not needed until write time ... I was just trying to get it ready while waiting for the Read Only test that is out for testing.
I ran out of math skills so I thought I would embarrass myself and ask for help ...

DON'T GET ME WRONG! I'm loving the education you're delivering, DO NOT STOP!
But it's going to take me a bit to digest it!

[antus]

you do need command mode to get the flash id though, which means you need to get all the above right. else command mode wont trigger and you'll get the flash data at the base address instead. or a crash as it fails to leave command mode.

Luckily the road is still pointing to the P59 kernel being fundamentally right, just something needs an update.

Anyway its past the middle of the night again here, and im back to the day job tomorrow so no more posts for tonight. good luck!

[Gampy]

Yup, I agree and I'm chewing as fast as I can ... You've done this a bunch more then I.

[Tazzi]

I believe I figured out the chaos of this stuff when playing with the E38.
Depending if its in byte or word mode affects how the data is sent to the registers.

For instance, address AAA >>1 (shift right 1) is 555 (the address wanted)
If this is word mode, then we have to send word version, which is AAAA (Instead of single AA).

The 2AA address isnt show there, it seems to be saved at loc_552.. But I would assume in the bin it should be: 2AA<<1 (do opposite.. shift left) = 554.
So 554 should be the address used in the bin, then it uses data 5555 (instead of single 55)

same goes for the following commands afterwards.

I did find a fantastic explanation of this a while back from one of the debugger pages online..
Ah ha! Found it: https://www2.lauterbach.com/pdf/flash_diagnosis.pdf
Page 62... conversion of word to byte access ect.

[Tazzi]

I can also personally vouch for how ridiculously particular 68k assembly is for these P series ecus. Playing with E40 (and now P12/P01 to confirm issue), trying to load a word (2bytes) to a A0/6 pointer to memory which results in complete crash.
Here I am trying to be smart.. save a couple opcodes... and noooooooooooooooo... bites me in the ass!!! Apparently you cannot move an "odd" number unless its transferred as a byte only.. (sigh). I am now forced to work with 1 byte at a time to prevent further issues. Now this then is negated if you write as a double word (4 bytes) to the pointer, which is allowed to be odd as well.

This was all explained in jester guides, this one was indicated here: https://mrjester.hapisan.com/04_MC68/Se ... Index.html

Anyways, ASM would cut down the kernel size... but you then run into absolutely bullshit "requirements" such as above. I lost the entire day trying to work out why I couldn't do the above... since emulators show this as being valid but they dont work on the 68k cpus!

[Gampy]

edit: this is in the bin though, its a starting point.

amd bin.png

First, FFFA7E must be one of the sim registers, the one that matters for command mode. first its set to whats needed, but whats in word_ca4 at this time?

word_CA4 = 0xF322
word_CA0 = 0xA332

This was all explained in jester guides, this one was indicated here: https://mrjester.hapisan.com/04_MC68/Se ... Index.html

Mr.J is definitely toolbar button worthy!
Spend much time there.

since emulators show this as being valid but they dont work on the 68k cpus!

I have a great distaste for simulators ... I know they can be good tools, however they can also <bleep> you royally!
I have been ...

Still digesting ya'alls brain food, there is a test out there, a spoofed chip detection version, we'll see where it leads.

Edit;
I have been digging through the datasheets because I remember reading about the reason for the double bytes, AAAA,8080,9090,etc... IIRC, it has to do with word addressing alignment, the commands are byte, the address is word, the byte command is the least significant byte (right (second) (5050)) in the word, the most significant byte is there just to fill the space for alignment, at least that is how I interpreted the datasheets words.
This was a long time ago, so ...