關(guān)于一個需求，請各位大牛指導，感激涕零~

ljpdxj

數(shù)字電視系統(tǒng)中，bin file包括bootloader和主代碼（主系統(tǒng)，比如Linux Kernel）兩部分，他們都是獨自編譯完成的系統(tǒng)。

因為產(chǎn)品的規(guī)格：bootloader要提供USB Upgrade，OTA Upgrade(數(shù)字電視碼流攜帶升級用bin file)

所以bootloader包含了OSD Driver/USB Driver/Tuner/...， Demod/demux/FS/...等等內(nèi)容，

而OSD Driver/USB Driver/Tuner/...， Demod/demux/FS/...在主代碼中又存在一份，這部分內(nèi)容大概200K的樣子（已經(jīng)被壓縮過）

項目提出需求，要求bootloader和主代碼可用共用此部分代碼。(補充說明：即要求節(jié)約flash中rom bin的size==〉flash rom bin中只有一份)

問題來了？如何完成此需求？

我當前只想到可以使用ELF loader，在bootloader和主代碼中分別都使用ELF loader來加載該common module部分

不過我又擔心：
1、主代碼中如果使用ELF動態(tài)加載，開機時其速度會不會比之前不使用ELF加載慢很多（如果慢會影響諸多問題，比如導致OSD出來慢，節(jié)目開畫慢，USB設(shè)備識別慢等）；
2、common module壓縮都200K的樣子，其ELF lib會比較大，且如果使用LEF Loader，那么此common comdule的lib必須是一個原生的可以被鏈接的ELF，雖然我們還會對其壓縮(parse ELF file，分Section壓縮)，但因為包括了很多在動態(tài)鏈接時需要使用的信息，此部分Size會不會就快接近200K的樣子了？如果這樣我豈不是白用功？

壓力十分大，請各位大牛指導，我該如何設(shè)計才好？請問有沒有其他比較好的解決方案？或者大家有類似的需求如何完成的？感激不盡~

starwing83

系統(tǒng)有沒有MMU？能不能這樣？在bootloader里面固定內(nèi)存做個函數(shù)指針表，然后將這200K初始化到一塊固定內(nèi)存地址，然后初始化這個表，然后跑bootloader，進主系統(tǒng)時，剔除掉這塊內(nèi)存（就當不存在了），然后主系統(tǒng)的這套東西使用固定內(nèi)存表的內(nèi)容靜態(tài)鏈接？

就是不知道你用的啥工具鏈，這樣的話似乎得自己寫鏈接腳本了，如果是Linux Kenerl指不定還得改內(nèi)核，你看著辦吧……

ljpdxj

回復 2# starwing83


感謝樓上的回復，
我在補充說明發(fā)帖時沒說清楚的重點：
需求目的就是節(jié)約flash rom bin size，也即是這部分common module在flash rom bin里面只有一份。
系統(tǒng)沒有MMU，
toolchain為gcc eCos mips，
鏈接腳本改起來倒easy，

你的意思是，在bootloader和主系統(tǒng)的ld里面把這部分common module的VMA設(shè)置為相同，
再構(gòu)建一個table，放入bootloader要使用到的函數(shù)指針，

也想過這樣操作，但如何解決Sync的問題成為難點，
假設(shè)某時間升級主系統(tǒng)時把common module里面的某函數(shù)原型變了，
bootloader每次起來必定crash

想想都頭疼。。。

pppStar

這個需求有難度！沒想到什么好辦法

不過我想未必需要從bootloader著手，也許可以
1.可以從linux系統(tǒng)著手，找找上面的庫是不是有debug的版本，沒strip掉？
2.找硬件工程師換個大點的flash塊

ljpdxj

回復 4# pppStar

感謝回復，需求提出的目的就是為了減小flash size，節(jié)約硬件成本。。。
同時：系統(tǒng)的代碼一般來說都是純二進制的代碼，objcopy -o binary
除了LEF Loader的Lib除外，這部分一定不能strip,因為要動態(tài)鏈接。