我繼承的一個項目使用了一個非常舊的buildroot版本,但我想將它改爲使用僅在稍後的buildroot版本中添加的功能。如何將buildroot安裝程序更新到更高版本?
是否有更新的buildroot安裝使用後釋放的一種簡單的方法?
例如如果我保存了一個defconfig文件並在稍後的buildroot版本中導入該文件,那麼這樣做是正常的,還是有實際的原因,爲什麼不呢?是否還需要額外的配置文件(例如內核,busybox等)?謝謝!
我繼承的一個項目使用了一個非常舊的buildroot版本,但我想將它改爲使用僅在稍後的buildroot版本中添加的功能。如何將buildroot安裝程序更新到更高版本?
是否有更新的buildroot安裝使用後釋放的一種簡單的方法?
例如如果我保存了一個defconfig文件並在稍後的buildroot版本中導入該文件,那麼這樣做是正常的,還是有實際的原因,爲什麼不呢?是否還需要額外的配置文件(例如內核,busybox等)?謝謝!
第
事實上,這更糟。
您可以從舊的默認配置文件開始使用較新的Buildroot版本,但您需要仔細檢查產生的配置,以確定棄用的軟件包和軟件包的版本與您可能添加到應用軟件的任何應用軟件不兼容Buildroot文件系統。某些軟件包(例如opencv)的名稱會隨着時間而改變,所以您需要仔細觀察生成的.config文件以確保您需要的所有軟件包都在那裏。
如果你在Buildroot中建立了一個工具鏈或者Linux內核(通常這樣做,但通常不是很好的做法),那麼你需要確保新的配置被設置爲構建舊版本的內核和編譯器。這些可能太舊了,無法在較新版本的Buildroot中構建一些軟件包。
如果您升級在您升級Buildroot裏面同時內核,那麼你就需要移植舊的內核配置文件到新的內核版本。由於內核配置選項會頻繁更改,因此您可能需要從defconfig開始,然後使用make menuconfig手動添加所需的配置。
Busybox的是有點不易揮發,所以有機會的話,你的舊的配置會工作。
如果你的舊Buildroot裏面的配置使用postbuild或postimage腳本,則需要對其進行審查,但我的猜測是,他們將不再需要任何的變化。
你應該每週至少分配這個工作,也許更多,這取決於配置的複雜性。請記住,如果由於某個特定SoC的補丁程序而被迫使用較老的供應商內核,例如BSC9131的Freescale 2.6.33.9內核,那麼如果不進行6至12次數月的工作將供應商的內核補丁移植到更新的內核版本。
乾杯。
可能沒有*「直接更新buildroot安裝程序以使用更高版本」*。您還必須考慮是否要更新工具,軟件包和內核。這些都將在新版本的Buildroot中默認爲不同的(並且可能被棄用的)版本。在嘗試更新之前,您將需要所有源代碼更改的補丁文件。我用'sdiff'來比較這種更新的舊配置文件和新配置文件。 – sawdust
如果您修改了busybox.config和uclibc.config,您還需要kernel.config。 – arved