mtdparts in a pro

[pazos]

I'd like to repartition the nand of a pogoplug pro like this:

1MB (uboot)
2MB (kernel)
~MB (rootfs)

and have a few questions:

Does stage1 bootloader has some type of checksum bits beyond 0x100000 (1MB)?
Can I use mtdparts to provide new partition layer to the kernel?

in kirkwood devices= mtdparts=orion_nand:1M(uboot),2M(kernel),-(rootfs)

14MB seems so big for a boot device ( I know you want to have a flexible booting device ) but I do not want
to keep old pogo filesystem...

about oxnas kernel: i'm planning to build a minimal kernel (without modules) but I've noticed that your config sets almost everything as modules ( as the GMAC driver), why ?

[WarheadsSE]

The GMAC driver requires the firmware built in, and it was kept separate for size. For you needs, Then I would say, don't worry about it and cut stuff down. If you don't want to bother with the pogoplug goods, then you need stage1 + uboot + room for kernel. There are a total of 4 copies of kernels in the NAND at the moment.

We even have NAND-burnable uboot sources available, but we are working on some major upgrades to that at the moment. The kernel & uboot have the parts hard-coded, but they can be ignored in uboot, and changed in the kernel.

[pazos]

Hi WarheadsSE, thanks for reply!

I saw your github account and found two trees of oxnas-uboot: 1.14 & 2011.09

I would know how well supported is the 2011.09 tree and if you have some experience about flashing it on nand

thanks for your time !

[WarheadsSE]

I actually forked that from another fellow, who stopped developing it, but he had previously had some success with non-CE devices. There are plans to migrate the USB code from it into the 2012.X variants.

For now, I'd suggest against futzing with your uboot, and if you are going to do so, use the 1.1.4+ tree as it is at least stable. Test it with chain-loading first.

[ckiick]

Modifying the u-boot MTD partitions is going to be difficult, at best. Certain things have to be in certain places for the built-in PROM and the stage1 bootloader to get uboot up and running. Also, the current layout was designed so that it is possible to revert back to the original firwmare - if you re-arrange things you might lose that ability. We do not have the sources to the stage1 loader, so that cannot be modified. And there are redundant copies of most things in case a block goes bad - which can and does happen with nand memory.

The easiest thing to do would be to shorten the mtd1 partition, making mtd2 bigger by a few meg. You'd have to give up the fallback of having two kernels in nand, and you'd have to trash the original kernel images.
MAKE BACKUPS FIRST. Make several, with and without the oob data, of all mtd devices. If you can, save some of the images in mtd1 separately, to make it easier to write them back. Copy them to multiple remote locations. Trust me, you want backups.

Given the restrictions of PROM and stage1, you should leave the first 11 128K blocks alone. Place the kernel starting at
0x00160000 and end the partition at, say 0x0040000. That would allow you to add 10Meg to the 2nd partition. It's probably
the best you can do right now. You don't have to use a different uboot, just change the boot args to point to the new kernel location. You can't really move uboot anyway because of stage1 compiled in locations.

Here is a map of what's in mtd1, to help you work out the details:
start length what
0x00000000 0x00020000(128K)* encoded stage1 loader
0x00020000 0x00020000(128K)* encoded backup of stage1 loader
0x00040000 0x00020000(128K)* uboot copy 1
0x00060000 0x00020000(128K) uboot spare copy (unused)
0x00080000 0x00020000(128K) uboot spare copy (unused)
0x000a0000 0x00020000(128K)** boot environment
0x000c0000 0x00020000(128K)** spare boot env block (if first is bad)
0x000e0000 0x00020000(128K)** spare boot env block (If second is bad)
0x00100000 0x00020000(128K)* uboot copy 2
0x00120000 0x00020000(128K) uboot spare copy (unused)
0x00140000 0x00020000(128K) uboot spare copy (unused)
0x00160000 0x000a0000(640K) ???/empty/garbage/unused
0x00200000 0x00300000(3M) CE uImage copy 1
0x00500000 0x00300000(3M) alarm uImage copy 1
0x00800000 0x00300000(3M) CE uImage copy 2
0x00b00000 0x00300000(3M) alarm uImage copy 2
0x00e00000 end of partition

* cannot change: required by PROM/stage1
** requires changing uboot

I wouldn't use the spare uboot blocks for two reasons - stage1 might be keeping those in case a block goes bad, and if
you ever want to upgrade uboot you might need the extra space.

have fun

[pazos]

Thanks a lot ckiick, awesome info!!

I've followed your recommendation any modified drivers/mtd/nand/ox820_nand.c accordly. Uploaded a diff file.

You made me think, Is a bad scenario to have just one kernel flashed in nand? AFAIK u-boot suports network kernel downloads via tftp, or i'm wrong?

Anyways is a good thing have some type of rescue kernel for the price of a few eraseblocks