[Samsung Galaxy SL i9003] dhiru1602:
There is a problem with this. I assume 1480000 should be 0x1480000. Since 1480000 is decimal and would fall somewhere in the SBL or PARAM region that would hard brick the device.

You could use MTDPART_OFS_APPEND, but I have decided to manually map the blocks based on the SBL partition information so that I could edit the offset and sizes easily, I will have more control and I could avoid mapping to blocks that contain the SBL PBL, PARAM or EFS.

==== PARTITION INFORMATION ====
ID : IBL+PBL (0x0)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 0
NO_UNITS : 1
===============================
ID : PIT (0x1)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1
NO_UNITS : 1
===============================
ID : EFS (0x14)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 2
NO_UNITS : 40
===============================
ID : SBL (0x3)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 42
NO_UNITS : 5
===============================
ID : SBL2 (0x4)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 47
NO_UNITS : 5
===============================
ID : PARAM (0x15)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 52
NO_UNITS : 30
===============================
ID : NORMALBOOT (0x5)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 82
NO_UNITS : 32
===============================
ID : RECOVERY (0x8)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 114
NO_UNITS : 32
===============================
ID : SYSTEM (0x16)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 146
NO_UNITS : 1334
===============================
ID : USERDATA (0x17)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1480
NO_UNITS : 312
===============================
ID : CACHE (0x18)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1792
NO_UNITS : 140
===============================
ID : FOTA (0x9)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1932
NO_UNITS : 2
===============================
ID : MODEM (0xa)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1934
NO_UNITS : 70
===============================

The above is the SBL partition table output. The FIRST_UNIT determines the starting block on the partition and NO_UNITS determines the number of blocks as a multiple of 256kb. For example, PBL starts at 0 = start of the Onenand and the size is 1 block = 1 * 256k.

This kind of approach makes it easier for me to map the partitions. Also, we need a reservoir partition for bml_over_mtd utility that we need to use inorder to convert the partitions to MTD. It's always hard to work with Hexadecimal and it's a mess to keep counting the size of each partition and how much you have reserve for the next partition. Since I know that the maximum size of the Onenand is 2047 blocks = 2047 * 256k = 524032k = 512mb, I could make sure that the partitions are within the available space by adding the last partition FIRST_UNIT and NO_UNITS since they both are at a 256k resolution.

This is what I have done. Basically the Boot partition holds the kernel, which starts at 82 block as indicated by the SBL. Hence I have used 82*SZ_256k and its 32*SZ_256K blocks big. The next partition starting block would be 82+32=114 block, which is indeed the starting block for the recovery partition.

static struct mtd_partition onenand_partitions[] = {
{
.name	= "boot",
.offset	= (82*SZ_256K),
.size	= (32*SZ_256K), //113
},
{
.name	= "recovery",
.offset	= (114*SZ_256K),
.size	= (32*SZ_256K), //145
},
{
.name	= "datadata",
.offset	= (146*SZ_256K),
.size	= (1688*SZ_256K), //1833
},
{
.name	= "cache",
.offset = (1834*SZ_256K),
.size	= (70*SZ_256K), //1903
},
{ /* we should consider moving this before the modem at the end
that would allow us to change the partitions before without
loosing ths sensible data*/
.name	= "efs",
.offset	= (1904*SZ_256K),
.size	= (50*SZ_256K), //1953
},
{ /* the modem firmware has to be mtd5 as the userspace samsung ril uses
this device hardcoded, but I placed it at the end of the NAND to be
able to change the other partition layout without moving it */
.name	= "radio",
.offset	= (1954*SZ_256K),
.size	= (64*SZ_256K), //2017
},
{ /* The reservoir area is used by Samsung's Block Management Layer (BML)
to map good blocks from this reservoir to bad blocks in user
partitions. A special tool (bml_over_mtd) is needed to write
partition images using bad block mapping.
Currently, this is required for flashing the "boot" partition,
as Samsung's stock bootloader expects BML partitions.*/
.name	= "reservoir",
.offset	= (2018*SZ_256K),
.size	= (30*SZ_256K), //2047
},

};

And look at how the partitions are mapped. Notice that the offsets are the same as that of the stock and what you wanted me to use.

<5>0x000001480000-0x000001c80000 : "boot"
<5>0x000001c80000-0x000002480000 : "recovery"
<5>0x000002480000-0x00001ca80000 : "datadata"
<5>0x00001ca80000-0x00001dc00000 : "cache"
<5>0x00001dc00000-0x00001e880000 : "efs"
<5>0x00001e880000-0x00001f880000 : "radio"
<5>0x00001f880000-0x000020000000 : "reservoir"

The current partition layout that is in my github is not final. I was planning to have the Kernel, Recovery, System, Radio, EFS and Reservoir on the Onenand. The Data is on the MMC by default and I would move the Cache to the 312mb partition on the MMC that is currently empty. It's a lot big for the cache but does it really matter? What matters is the proper utilization of space on the Onenand.

Model: MMC SEM04G (sd/mmc)
Disk /dev/block/mmcblk0: 3959MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 32.8kB 1634MB 1634MB primary fat32 lba
2 1634MB 1946MB 312MB primary fat16 lba
3 1946MB 3959MB 2013MB primary ext4 lba

I am trying to determine the proper size of the Modem partition. If I find that the modem doesn't fit, I will move it to system/vendor/modem probably and place a symlink there.

While converting the partitions, EFS will be copied off the BML block and will be copied over to the MTD partition and mounted as /efs. This is to ensure the safety of the efs.