NAND Testing - 05-25 Update: New LK, Recovery.img, Kernel Updates through Recovery - Page 131

**[ACL]** · #**1301** (**permalink**) 02-21-2011, 02:22 AM

I guess its time to find more test guinea pigs and see if they suffer the same issue. maybe we can find a pattern to this.

I've been chewing away at more kernel upgrades so keep an eye on the autobuilds since there will be more now.. Got clocks finalized for the camera patch. Also we are able to fully shut down the sdcard clocks which will save power. Haret has to have that thing on so thats always been a drag.

**natemcnutty** · #**1302** (**permalink**) 02-21-2011, 02:49 AM

Quote:

Originally Posted by Lmiller1708

Lol my wife is the same way right now too... but have to keep them happy.

Nate can you up your table... or more of your math. Remebmer the magic number is 64.

So, here's kind of breakdown of what I understand (and there's a lot I'm probably not getting fully). I just got back and I'll be starting on this soon.

Here is what we currently have:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
000001B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 ................
000001C0  01 00 23 3F 01 18 02 00 00 00 3E 06 00 00 00 00  ..#?......>.....
000001D0  01 19 23 3F 01 1B 40 06 00 00 00 00 00 00 00 00  ..#?..@.........
000001E0  01 1C 25 3F 01 1C 40 06 00 00 40 00 00 00 00 00  ..%?..@...@.....
000001F0  01 1D 04 3F FF FF 80 06 00 00 00 00 00 00 55 AA  ...?ÿÿ€.......Uª

0x1BF
This is the First Head of the partition.

0x1C0-0x1C1
These are the first sector and first track. If the value of 0x1C0 is 8X, then add 200 to the value of 0x1C1. 0x1C1 is the starting partition address.

0x1C2
This is the partition type. 20 is boot, 23 is RAWFS, 25 is IMGFS, and 04 is FAT. Technically, we only need 23 and 25.

0x1C3
This is the last head.

0x1C4-0x1C5
These are the last sector and last track. If the value of 0x1C3 is 8X, then add 200 to the value of 0x1C4. 0x1C4 is the ending partition address.

0x1C6-0x1C9
This value is little endian for the starting sector. You reverse the value so that 40 06 00 00 would become 00000640. This is where XIP traditionally starts from. Also, the first partition's LBA is always 00000002, so if we remove the boot partition, XIP now starts there.

0x1CA-0x1CD
This value is also little endian for the number of sectors in the partition. For example, 3E 06 00 00 becomes 0000063E which means we have 1598 sectors. Since our MSFLASH starts at 0x800, we have 2K sector size; this means 0000063E is 3196 KB in size.

Here is what I'm thinking of right now:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
000001B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02  ................
000001C0  01 00 23 3F 01 37 02 00 00 00 FE 06 00 00 00 00  ..#?.7....þ.....
000001D0  01 38 25 3F 01 38 00 07 00 00 40 00 00 00 00 00  .8%?.8....@.....
000001E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA  ..............Uª

This basically says only create 2 partitions, RAWFS starting at 00000002, having a size of 6FE (which gives us 3580 KB of XIP space) which ends at 700. Then we insert our blank IMGFS at 700 having a size of 40 which results in a total size of 128 KB for that partition.

Finally, we have to update the MSFLASH section to point to the correct location. It looks like we have this correct already, but I'm putting this here for reference. First, the code:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000800  4D 53 46 4C 53 48 35 30 00 00 00 00 54 00 00 00  MSFLSH50....T...
00000810  00 00 00 00 00 00 00 00 00 00 00 00 1C 00 00 00  ................
00000820  40 00 00 00 00 00 02 00 00 00 00 00 01 00 00 00  @...............
00000830  00 00 00 00 00 00 00 00 01 00 00 00 40 00 00 00  ............@...
00000840  00 00 02 00 02 00 00 00 02 00 00 00 00 00 00 00  ................
00000850  00 00 00 00 FF FF FF FF 40 00 00 00 00 00 02 00  ....ÿÿÿÿ@.......

0x800 is the start of MSFLSH50 region, so we have 800 (64 KB) for our sector block.

0x81C-0x81F
This is start block of the IMGFS which we need to set based on our partition sizes (see below the definitions).

0x820-0x823
This is little endian for the number of sectors per block. Above is 00000040.

0x824-0x828
This is little endian for the LBA restriction. Above is 00020000.

To find the Start Block of IMGFS, we need to divide the IMGFS Partition Start Address by the LBA restriction.

The IMGFS partition start address is 380000, and the LBA restriction is 20000. IMGFS/LBA = 1C

I'll be trying this in a few minutes, but I figured I'd share my "research" thus far

**natemcnutty** · #**1303** (**permalink**) 02-21-2011, 03:23 AM

Well, great in theory, but apparently not in practice. Still have the same problem as before. Back to the drawing board.

**[ACL]** · #**1304** (**permalink**) 02-21-2011, 03:38 AM

Quote:

Originally Posted by natemcnutty

Well, great in theory, but apparently not in practice. Still have the same problem as before. Back to the drawing board.

holy shish kabob.. i thought you were up to something there for a second

How about going the vogue approach. Lmiller and I never got it working so we moved on, but maybe its worth another shot.

Bottomline is that vogue attaches the initrd in tinboot. But back when we tried it our initrd was big but now we managed to shrink it enough so it might work. Worse case this is also a change for you to test your new busybox.

I made some commits to the kernel but nothing that will make anyone notice anything so no new autobuilds tonight. Hopefully tomorrow i finish the setcpu support so we can over clock via app now.

**natemcnutty** · #**1305** (**permalink**) 02-21-2011, 04:08 AM

Quote:

Originally Posted by [ACL]

holy shish kabob.. i thought you were up to something there for a second

How about going the vogue approach. Lmiller and I never got it working so we moved on, but maybe its worth another shot.

Bottomline is that vogue attaches the initrd in tinboot. But back when we tried it our initrd was big but now we managed to shrink it enough so it might work. Worse case this is also a change for you to test your new busybox.

I made some commits to the kernel but nothing that will make anyone notice anything so no new autobuilds tonight. Hopefully tomorrow i finish the setcpu support so we can over clock via app now.

I'll give that a try again. I did try attaching it through tinboot previously, but not since I tried changing the partition layout.

Edit: No dice. I just don't get why that partition layout works for you and LMiller, but it doesn't work for arrrghhh or myself. I would blame VZW, but arrrghhh has the rhod400 like you guys. Well, I'll play with it more tomorrow. I now know more than I ever wanted to know about the NAND partition tables, and I have a feeling I'm going to have to learn more to get this working.

**Lmiller1708** · #**1306** (**permalink**) 02-21-2011, 09:16 AM

Quote:

Originally Posted by natemcnutty

I'll give that a try again. I did try attaching it through tinboot previously, but not since I tried changing the partition layout.

Edit: No dice. I just don't get why that partition layout works for you and LMiller, but it doesn't work for arrrghhh or myself. I would blame VZW, but arrrghhh has the rhod400 like you guys. Well, I'll play with it more tomorrow. I now know more than I ever wanted to know about the NAND partition tables, and I have a feeling I'm going to have to learn more to get this working.

Thanks for the Tips Nate! I never changed the MSFLSH50 region and redid some of my math with the start and last sectors.

I have a Rhod500 also, so it's not that...

I will soon try my wife's rhod500!

I have attached a build with my most recent partition table, and of course it works for me.

Give it a try!

EDIT: Wrong NBH... I will up the correct one in a min.

Attached...

**arrrghhh** · #**1307** (**permalink**) 02-21-2011, 03:27 PM

Don't mean to derail this thread, but ACL have you looked at calibrating the screen from the SPL values? They seem to work... See this post from highlandsun.

**Lmiller1708** · #**1308** (**permalink**) 02-21-2011, 03:30 PM

Quote:

Originally Posted by arrrghhh

Don't mean to derail this thread, but ACL have you looked at calibrating the screen from the SPL values? They seem to work... See this post from highlandsun.

arrrghhh What version is your SPL?