Well, I think I got it figured out, and now that I'm looking at it, I don't understand how ACL and LMiller are actually working, lol. I had two major theories, and they may both be correct. I thought the SPL was requiring us to have specific partitions, especially the fatfs. The other theory was that the fatfs was initializing over the top of our existing data and wiping the device every time we rebooted. A simple fix would be to elimitate the fatfs or make it smaller. Removing it did not work, but making it smaller sure did (edit: but it still requires a substantial size instead of zeroing it out or making it 128KB)
Here's how I got there for anyone interested:
First, I was looking at our previous os.nb.payload and it's partition table. Here's a quick rundown of how it was formatted:
Partition 1 - Type 0x20 (boot) - Size 0x40 (128 KB)
Partition 2 - Type 0x23 (rawfs) - Size 0x6C0 (3456 KB)
Partition 3 - Type 0x25 (imgfs) - Size 0x40 (128 KB) -
Partition 4 - Type 0x04 (fatfs) - Size 0x39040 (467072 KB)
I noticed that the Tinboot portion started at 0x20000 which starts at 128K into NAND. This correlates with the start of the 2nd partition in the table, and if we get rid of the boot partition and start the rawfs partition at offset 0x2, then we need to move the Tinboot payload as well which was not being done.
The second thing I did was a little comparison of each step of the file the way we used to do it. Here's that breakdown:
Code:
Start
01 00 20 3F 01 00 02 00 00 00 3E 00 00 00 00 00
01 01 23 3F 01 1B 40 00 00 00 C0 06 00 00 00 00
01 1C 25 3F 01 1C 00 07 00 00 40 00 00 00 00 00
01 1D 04 3F 81 5D 40 07 00 00 40 90 03 00 55 AA
After osnbtool
01 00 20 3F 01 00 02 00 00 00 3E 00 00 00 00 00
01 01 23 3F 01 1B 40 00 00 00 00 05 00 00 00 00
01 1C 25 3F 01 1C 40 05 00 00 40 00 00 00 00 00
01 1D 04 3F 81 5D 80 05 00 00 40 90 03 00 55 AA
After imgfstonb
01 00 20 3F 01 00 02 00 00 00 3E 00 00 00 00 00
01 01 23 3F 01 1B 40 00 00 00 00 05 00 00 00 00
01 15 25 3F 01 15 40 05 00 00 40 00 00 00 00 00
01 16 04 3F 81 56 80 05 00 00 40 90 03 00 55 AA
After nmberge (no changes this time)
01 00 20 3F 01 00 02 00 00 00 3E 00 00 00 00 00
01 01 23 3F 01 1B 40 00 00 00 00 05 00 00 00 00
01 15 25 3F 01 15 40 05 00 00 40 00 00 00 00 00
01 16 04 3F 81 56 80 05 00 00 40 90 03 00 55 AA
Long story short, the NB tools are changing values and probably doing some alignment that we don't have replicated when we cat them. So, I took one of the NBH's that I generated the old way and started messing around. Here are my results:
Completely removing the fatfs prevents the phone from booting. Setting it to 0x40 (128 KB) in size and adjusting the end block would not let the phone boot. Setting it to 0x4000 (32 MB) boots up just fine. I'll test smaller shortly, but using 32 MB, it boots and keeps all of the data on the NAND because we start our NAND partitions at 64 MB's into the NAND.
My thought is that the SPL is requiring fatfs of at least a specific size. fatfs partition was initializing over the top of where we had our mount points wiping the data every time we restarted. And BINGO, there you have it.
Edit: Here's the partition layout I'm using right now (starting at 3E0)
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
000003E0 01 00 20 3F 01 00 02 00 00 00 3E 00 00 00 00 00 .. ?......>.....
000003F0 01 01 23 3F 01 1B 40 00 00 00 80 05 00 00 00 00 ..#?..@...€.....
00000400 01 17 25 3F 01 17 C0 05 00 00 40 00 00 00 00 00 ..%?..À...@.....
00000410 01 18 04 3F 01 7C 00 06 00 00 00 40 00 00 55 AA ...?.|.....@..Uª