So I'm waiting for my ARM-USB-OCD-H JTAGGING device to come. I learn that OpenOCD doesn't support the NAND flash controller on the i.MX28 processors. This is disappointing. I also want to say I remember reading something in the programming reference guide that the NAND works in parallel mode. From reading stuff on the internet, from what I can tell, I will not be able to use one of those clips that you just put over the NAND chip and read and write to it directly, in circuit, while the device is on (like the E3 Flasher for the PS3 for example). I think getting this NAND dump is going to be a bit harder than I originally was hoping for.
Anyway, I went back to looking at the GEL files. I see patterns but can't really make sense out of them. I've tried bit shifting them, doing bitwise manipulation on them (AND, OR, XOR) but I can't seem to get anything useful out of. Maybe you guys can make some sense out of it and see something that I just don't? For example, the first 32 bytes of code, I see a pattern...
28 23 10 00 78 B9 FB BB 7C 7D D0 7F 20 BE 82 83 /* Notice here, starting at offset 5, we have 78. If we count up in hex though, we get:
78 79 7A 7B 7C 7D 7E 7F... See how 78, 7C, 7D, and 7F line up? */
83 84 86 87 27 89 8A 8B 28 CA 8E 8F A8 81 31 78 /* We see this again...
86 87 88 89 8A 8B 8C 8D 8E 8F... 86, 87, 89, 8A, 8B, 8E and 8F line up. */
Now, if I create a table, the pattern becomes a bit more clear.
x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF x0 x1 x2 x3
---------------------------------------------------
7x | 28 23 10 00 78 B9 FB BB 7C 7D D0 7F 20 BE 82 83 | 83
8x | 83 84 86 87 27 89 8A 8B 28 CA 8E 8F A8 81 31 78 | 93
9x | AC 85 35 7C B0 89 39 80 B4 8D 3D 84 B8 91 41 88 | A3
Ax | A4 A5 A6 A7 BC 99 49 90 C0 9D 4D 94 A8 EB BA B3 | B3
Bx | 30 F1 BE B7 34 F5 C2 BB 38 F9 C6 BF 3C FD CA C3 | C3
Cx | 40 01 CE C7 20 EB D2 | D3
Cx | CB CC CD CE CF D0 D1 D2 D3 | D3 (continued)
Dx | D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 | E3
Ex | E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 | F3
Fx | F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 01 02 03 | 03
0x | 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 | 13
1x | 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 | 23
2x | 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 | 33
3x | 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 | 43
4x | 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 | 53
5x | 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 | 63
6x | 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 | 73
7x | 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 | 83
8x | 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 | 93
That's the first 285 bytes. Starting at offset 57h, it starts counting up, in a row, from CBh to FFh then 00h to 90h. I use that to create the numbers before and after the |'s. Maybe we're supposed to remove the numbers that match up? I'll give an example. First row,
we see the 7x that I added, so the numbers to remove will start with a 7. Then, the little grid above us tells us what the last number in the row has to be in order for us to remove it. So, we look at:
x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF x0 x1 x2 x3
---------------------------------------------------
7x | 28 23 10 00 78 B9 FB BB 7C 7D D0 7F 20 BE 82 83 | 83
The first number, 28, does it start with a 7? Nope, move on. Does 23 start with a 7? Nope, move on....we keep going to get to 78 at offset 05h. Does that start with a 7? Yup. We look up to see what number it has to end in. In this case, an 8. Does it end in an 8? Yup. Remove it. On to the next ones. We remove 7C, 7D, 7F, 82 and 83. So maybe the first lines in the .GEL file are really
28 23 10 00 B9 FB BB D0 20 BE
You see, I thought I was onto something there for a second, but I can't make sense out of 0x28 0x23 0x10 0x00 0xB9 0xFB 0xBB 0xD0 0x20 0XBE. Maybe someone smarter than me could see something that I'm missing here? Thanks!