mkfwimage.c image size limit

[freezer2k]

Hi,


This is from mkfwimage.c

.name = "RS",
.kern_start = 0xbf030000,
.kern_entry = 0x80060000,
.firmware_max_length= 0x00640000,


I built a trunk image, total size about 6.7MB

With thise size, mkfwimage fails to build the final .bin image. If i cut down the rootfs to like 2MB (total 2.8MB), it builds fine.

So it looks like firmware_max_length limits the image size to something about 4-6MB.

Can this be changed? Can i harm the RS if i flash a 10-16MB image?

[freezer2k]

I changed max_length to 0x00F42400 (16M bytes), now image building works at least.


Can i flash it without danger?

[freezer2k]

okay,

tried it.


Looks like redboot doesn't accept images >6MB for flashing?

tftp works fine, no errors. But no actual flashing seems to happen. The device doesn't reboot for minutes, and i can send the image again with no errors as well. However, even after waiting 10minutes and then do manual reboot, there's still the old image on the device.

Any info about this from the devs? I don't see why it shouldn't be possible to flash images up to 15-16MB!?

[UBNT-Mike.Taylor]

Hi freezer2k,

The maximum size for the rootfs cannot actually be the size of all available flash - since you have to account for the rest of the partitions in the flash.

Flash is divided into 64k blocks, and the sizes of other partitions must be deducted.
RedBoot takes 3
Kernel takes 14
Cfg takes 2
Redboot config/FIS take 1

"rootfs" and "data"
"data" is always 4M and rootfs is everything left (between "kernel" and "data" partitions).

The idea is to mount "data" to a local path (depending on your application) and the contents will not perish along with the mini-fo filesystem contents if you are forced to upgrade the read-only portion of rootfs via RedBoot/tftp.

If you know you will not need this ability, then you can merge the space in "data" with "rootfs" using RedBoot.

WARNINGS:

1) This change will need to be performed after EVERY factory recovery/reset, however, since our recovery tool will recreate the default flash layout.

2) The recovery procedure can be used to reverse this change. If you reverse this process using RB commands, you must make sure that mini-fo re-initilizes the rootfs_data partition entirely as it will be corrupted.

INSTRUCTIONS:

1) Connect to RedBoot

2) Run "fis list"


Name FLASH addr Mem addr Length Entry point
RedBoot 0xBF000000 0xBF000000 0x00030000 0x00000000
kernel 0xBF030000 0x80060000 0x000E0000 0x80060000
rootfs 0xBF110000 0xBF170000 0x00560000 0x00000000
data 0xBFBD0000 0xBFBD0000 0x00400000 0x00000000
cfg 0xBFFD0000 0xBFFD0000 0x00020000 0x00000000
FIS directory 0xBFFF0000 0xBFFF0000 0x0000F000 0x00000000
RedBoot config 0xBFFFF000 0xBFFFF000 0x00001000 0x00000000


3) Find the FLASH addr of "rootfs" (in my case 0xbf110000)

4) Add the lengths of rootfs and data (in my case 0x560000+0x400000 = 0x960000) for the new rootfs length.

5) Delete data partition (destructive + erase) with fis delete data


RedBoot> fis delete data
Delete image 'data' - continue (y/n)? y
... Erase from 0xbfbd0000-0xbffd0000: ................................................................
... Erase from 0xbfff0000-0xc0000000: .
... Program from 0x83ff0000-0x84000000 at 0xbfff0000: .
RedBoot>


6) Delete rootfs partition (NON-destructive) with fis delete -n rootfs


RedBoot> fis delete -n rootfs
Delete image 'rootfs' - continue (y/n)? y
... Erase from 0xbfff0000-0xc0000000: .
... Program from 0x83ff0000-0x84000000 at 0xbfff0000: .
RedBoot>


7) Re-create rootfs partition (NON-destructive) with a command similar to the one depicted, substituting value from step #3 for -b and -f and substituting value from step #4 for -l

example: fis create -n -b 0xbf110000 -f 0xbf110000 -l 0x960000 -e 0x00000000 rootfs


RedBoot> fis create -n -b 0xbf110000 -f 0xbf110000 -l 0x960000 -e 0x00000000 rootfs
... Erase from 0xbfff0000-0xc0000000: .
... Program from 0x83ff0000-0x84000000 at 0xbfff0000: .
RedBoot>


8) Reset with "reset" command

During reset, you should see MTD partition dump indicating the expanded sizes and increased length of rootfs_data. Example:

BEFORE:


7 RedBoot partitions found on MTD device spi0.0
Creating 7 MTD partitions on "spi0.0":
0x00000000-0x00030000 : "RedBoot"
0x00030000-0x00110000 : "kernel"
0x00110000-0x00bd0000 : "rootfs"
mtd: partition "rootfs" set to be root filesystem
mtd: partition "rootfs_data" created automatically, ofs=5D0000, len=600000
0x005d0000-0x00bd0000 : "rootfs_data"
0x00bd0000-0x00fd0000 : "data"
0x00fd0000-0x00ff0000 : "cfg"
0x00ff0000-0x00fff000 : "FIS directory"
0x00fff000-0x01000000 : "RedBoot config"


AFTER:


6 RedBoot partitions found on MTD device spi0.0
Creating 6 MTD partitions on "spi0.0":
0x00000000-0x00030000 : "RedBoot"
0x00030000-0x00110000 : "kernel"
0x00110000-0x00fd0000 : "rootfs"
mtd: partition "rootfs" set to be root filesystem
mtd: partition "rootfs_data" created automatically, ofs=5D0000, len=A00000
0x005d0000-0x00fd0000 : "rootfs_data"
0x00fd0000-0x00ff0000 : "cfg"
0x00ff0000-0x00fff000 : "FIS directory"
0x00fff000-0x01000000 : "RedBoot config"


9) Reset mini-fo filesystem using "mtd unlock /dev/mtd3" and "mtd erase /dev/mtd3 -r" to make sure blocks are available to JFFS2 partition on rootfs_data (mtd3)


root@RouterStation:/# mtd unlock /dev/mtd3
Unlocking /dev/mtd3 ...
root@RouterStation:/# mtd erase /dev/mtd3 -r
Unlocking /dev/mtd3 ...
Erasing /dev/mtd3 ...
Rebooting ...
Terminated