Partitions with file systems should be accessed via STL devices with no offset - edited table.
Code:
[COLOR=Blue][B]Device Partition Image Offset Size (KiB)[/B][/COLOR]
bml1 MIBIM arm9boot 2048
bml2 OEMSBL1 arm9boot @0x200000 512
bml3 OEMSBL2 [I]{blank}[/I] 512
bml4 APPSBL arm11boot 1024
bml5 AMSS amss 23040
bml6 RECOVER recovery 6144
bml7 EFS2 [I]{radioFS}[/I] 0xA80000 23040
bml8 APPS kernel 6144
[COLOR=Orange]stl9[/COLOR] EFS2APPS system [COLOR=Orange][s]0xA80000[/s][/COLOR] 226304
bml10 FOTA [I]{blank}[/I] 8192
bml11 RFBACKUP [I]{blank}[/I] 512
[COLOR=Orange]stl12[/COLOR] CACHE cache [COLOR=Orange][s]0xA80000[/s][/COLOR] 40960
bml13 PARAM [I]{unknown}[/I] 1024
[COLOR=Orange]stl14[/COLOR] USERDATA userdata 173568
...
Update: Simply hexediting the flash file system header out so that the remaining image matches the contents of the original ODIN images does not seem to work.
The problem is that dumping the BML devices with files systems on them (vs RAW) produces an image that is too large. In the originals, all the files were allocated near the beginning of the ROM, and the rest was zeroed (in NAND flash this means 0xFF). After the update I noticed that files were allocated at the end as well. This means one cannot simply remove the extra zeroed space to make it fit for ODIN.
The STL devices work at a higher level, translating addresses in flash so they can work with normal file systems. Using an STL image instead of the edited BML image may work.
The downside of using STL devices for file system dumps is that they are only enabled on specific partitions. The good thing is these other partitions do not really concern us unless we want to edit the radio code (lets leave this alone).
Unfortunately the error in trying to flash the BML image forced me to ODIN back to the UVIJ6 firmware. Once I receive the update again I will test the new ROM dump and release a no-root-needed ROM update via ODIN if it works.