build: add support for OpenWrt-Imagebuilder and non-gluon style firmware-images #1946
Conversation
…e for other types of firmwares ignored changes in MAkefile defining this FLAG (to "1") disables / skips some things * including gluon-core packages * strict inclusion of some packages * per device sepecific kernel build * a gluon specific target/generic_gluon will be considered
this module gets selected automatically; by its depenging modules
this option depends on kmod-ath, which is not avail on all targets. So use try_config() to set this option, to prevent error on check_config.
This reverts commit 4219f0e9af9ee7fec74b31b48c7bd615eec6847f.
This will just build packages, without adding them into an image.
… of usb_net_rndis
by defaulting to nil
even the whole batman-adv package is build as module it still depends on crc16. As batman-adv is only modulear the lib-crc16 is also modular, bit this fails on build.
this moves the transformation of "dev.options.packages" and "site_packages(dev.image)" to a string ps packages from the main code. As the main-code gets a single string with all packages, it does not need to evaluate the pkg-sources again.
it returns a table with all boards of a target and a list of packages for each board.
this script creates a file $GLUON_TMPDIR/§TARGET with following syntax: > board1: "packages" > board2: "packages" > ... this list can be used to build the final images with the imagebuilder
…efor other types of firmwares" reenable setting of * CONFIG_TARGET_DEVICE_%s_DEVICE_%s * CONFIG_TARGET_DEVICE_PACKAGES_%s_DEVICE_%s * CONFIG_TARGET_PER_DEVICE_ROOTFS=y to fix building of initramfs. This way we also honor the devices-packages, and e.g. remove the ath9k-ct drivers in favor of ath9k. Else it causes double inclusion of drivers and results in file-conflicts.
|
@SvenRoederer because of #1950 you need to rebase this, please. |
rotanid
added
0. type: enhancement
|
@rotanid Rebasing is on my ToDo since some times, after having seen PR1950 was merged. But It seems the idea of this PR will get no veto, so it's worth spending my time on it again. |
|
I think this PR does far too many things at once - I'd like to see it as inspiration of things we should support eventually, not as a concrete proposal for an implementation. So IMO rebasing this is rather low-priority, if useful at all. |
rotanid
added
the
2. status: blocked
@NeoRaider From the comment it is a request for comments and I think it is really well-thought-through, but I admit it's a bit much to grasp. Unfortunately I don't know the Makefiles that well, because I'd love to see this. Please have a look at it. |
|
@SvenRoederer Can you please have a look at PR #2172? I think it will be cleaner if you could somehow adapt the Freifunk Berlin image builder to this approach. What other conflicts in the generic config file do you see? Can you make them configurable like GLUON_SPEZIALIZE_KERNEL with your packages so that you don't need a custom file for Freifunk Berlin anymore? |
|
@CodeFetch @lemoer slowly keeping up with my time and happy to see PR #2172. Will have a close look at it, as it seem to provide half of the way this PR a going for. |
|
Marking as draft, given the fact that we can't, won't merge this as is. |
|
Closing as per successor #2172 |
For Freifunk Berlin we are in need of a way to define some device-specific packages (freifunk-berlin/firmware#696). Instead of inventing a new way for such definition, a PR was made to reuse code of the gluon build-framework (freifunk-berlin/firmware#765). This PR is about upstreaming the changes.
The Freifunk Brerlin firmware differs in some points from Freifunk Gluon. The major points are:
Based on 1.) and 2.) there is (currently) no use of the gluon-packages, but some other external feeds. There are also some CONFIG-options of OpenWrt which are incompatible between both firmwares. For this reason the file
targets/generic_gluonwas split fromtargets/genericand an additionaltargets/generic_ffberlinwas added. Thegeneric-file contains just some very common settings and thegeneric_*-files provide the build-type specific settings. With theFOREIGN_BUILD-flag the Makefile can control whichgeneric-*-file is included in addition to thegeneric-file.Imagebuilder-support:
Freifunk Berlin is using a two-phases based process (compilation, image-assembly) of creating the firmware-images. In the 1st phase all relevant packages are build and an imagebuilder.tar.xz is created.
In the 2nd phase this OpenWrt-Imagebuilder is used to assemble the firmware-images by combining the previously built kernel and packages. As for Gluon the list of packages is generated from
targets/generic*,targets/$GLUON_TARGET, the Makefile and the site-conf. In contrast to Gluon this list of packages is not fix stored in the OpenWrt-config on a per board-basis, as it needs to be provided to the imagebuilder later.This is archived by the new
scripts/target_config_profile.lua, which generates a per GLUON_TARGET file containing the packagelist per board. This script uses the new function 'target_config_lib.lua.get_pkglist()' which is reusing the existing code of building the packagelist.The code of this PR is just cherry-picked from the above mentioned PR and currently a working prototype to be commented.It also still contains a lot of debug-output.
A welcome side-effect of the original PR is that it will be more easy to share code between both projects regarding the build-framework and device-support. As mentioned I only had to cherry-pick from the Freifunk-Berlin Repo without copy-paste of code.