What is the modified IJ9 nb0? Do you mean the one-language nb0? I think it's probably not important for that one-language nb0 since it won't make a request for language setup.
The size of original pda.nb0.os.nb has to be fixed 1B2000000 in order to make it works with osnbtool. However, I have tried to reduce the size of pda.nb0.os.nb.new by cutting off those FFFFFFFF to minimal and it works. This increases our storage space to >120 MB.
Thank you for your information. Do you have any good news on building ROM and relocation yet?
Rodrigofd - you said you have successfully compiled the new buildos and relocate tools. Are they ready for testing?
One comment: it doesn't matter for 'langpack' section, if .os.nb file grows or shrinks... sections inside NB0 file are delimited by size indicator in each section header (first 0x100 bytes) ...
so NB0 format is:
| 0x100 byte header 1 | variable size section 1 | 0x100 header 2 | variable size section 2 | ...
Up to now, we only know NB0 files to have one first mandatory section : OS.NB OS image (which includes three partitions: boot, xip and imgfs) , and optional second section, langpack, which is a standard disk image (can be mounted as a disk, e.g. with virtual dvd-rom drive)
And NB0 section headers have standard format :
offset 0x4 has section size;
offset 0x8 has block count (where each block is of 0x1F800 size)
offset 0xC has a 32-bit, simple modular checksum
rest are random strings, but in the case of multilanguage roms, one of those is a multi-string that details included language packs...(we should mess with rest of header anyway..)
So NB0 format is no longer an issue at all, the source of all problems is the OS.NB file, which, apparently , current Weisun' OSNBTOOL has serious trouble both in decompressing (why do we have to resize original file?) .. and more buggy, recompressing (it modifies some OS.NB values that cause unbootable ROMs... E.G. the famous 0x1EA dword pointed out by WES)
I have JUST finished writing a simplified tool that unpacks Omnia2 NB0 file, and buils a dump... and the other way round: pack a dump, into a flashable NB0 file, doing all known adjustments, like resizing, checksums, 0x1EA patching and so.
I am also re-coding PKGTOOL and BUILDOS tools, originally created by BEPE, to fit our own needs.
However, the MAJOR remaining issue we have is a proper module rellocation tool....
Wes you're right in your assumptions, removing modules would only create memory holes, but shouldn't affect rom stability, of course leaving less ram.
We can ignore it for this first attemps, but it's definitely not a good option!!! official roms already are awful short on memory.
Without reloc, any module addition will certainly break down ROM... maybe, for testing, converting such module to a standard file would make it work, but again, not in a permanent choice....
Do any of you have precise technical knowledge of how module relocation works? So maybe i can write our own tool...