2013-07-04 127 views
4

我继承的一个项目使用了一个非常旧的buildroot版本,但我想将它改为使用仅在稍后的buildroot版本中添加的功能。如何将buildroot安装程序更新到更高版本?

是否有更新的buildroot安装使用后释放的一种简单的方法?

例如如果我保存了一个defconfig文件并在稍后的buildroot版本中导入该文件,那么这样做是正常的,还是有实际的原因,为什么不呢?是否还需要额外的配置文件(例如内核,busybox等)?谢谢!

+2

可能没有*“直接更新buildroot安装程序以使用更高版本”*。您还必须考虑是否要更新工具,软件包和内核。这些都将在新版本的Buildroot中默认为不同的(并且可能被弃用的)版本。在尝试更新之前,您将需要所有源代码更改的补丁文件。我用'sdiff'来比较这种更新的旧配置文件和新配置文件。 – sawdust

+0

如果您修改了busybox.config和uclibc.config,您还需要kernel.config。 – arved

回答

3

事实上,这更糟。

您可以从旧的默认配置文件开始使用较新的Buildroot版本,但您需要仔细检查产生的配置,以确定弃用的软件包和软件包的版本与您可能添加到应用软件的任何应用软件不兼容Buildroot文件系统。某些软件包(例如opencv)的名称会随着时间而改变,所以您需要仔细观察生成的.config文件以确保您需要的所有软件包都在那里。

如果你在Buildroot中建立了一个工具链或者Linux内核(通常这样做,但通常不是很好的做法),那么你需要确保新的配置被设置为构建旧版本的内核和编译器。这些可能太旧了,无法在较新版本的Buildroot中构建一些软件包。

如果您升级在您升级Buildroot里面同时内核,那么你就需要移植旧的内核配置文件到新的内核版本。由于内核配置选项会频繁更改,因此您可能需要从defconfig开始,然后使用make menuconfig手动添加所需的配置。

Busybox的是有点不易挥发,所以有机会的话,你的旧的配置会工作。

如果你的旧Buildroot里面的配置使用postbuild或postimage脚本,则需要对其进行审查,但我的猜测是,他们将不再需要任何的变化。

你应该每周至少分配这个工作,也许更多,这取决于配置的复杂性。请记住,如果由于某个特定SoC的补丁程序而被迫使用较老的供应商内核,例如BSC9131的Freescale 2.6.33.9内核,那么如果不进行6至12次数月的工作将供应商的内核补丁移植到更新的内核版本。

干杯。

相关问题