| Message ID | 20170329145120.11863-5-etienne.phelip@savoirfairelinux.com |
|---|---|
| State | Changes Requested |
| Headers | show |
On 29-03-17 16:51, Etienne Phelip wrote: > diff --git a/configs/acmesystems_aria_g25_128mb_defconfig b/configs/acmesystems_aria_g25_128mb_defconfig > index 0ec210f..23bb8b9 100644 > --- a/configs/acmesystems_aria_g25_128mb_defconfig > +++ b/configs/acmesystems_aria_g25_128mb_defconfig > @@ -8,7 +8,6 @@ BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_7=y > BR2_TARGET_GENERIC_ISSUE="Welcome to Aria-G25 Buildroot" > BR2_TARGET_GENERIC_GETTY_PORT="ttyS0" > BR2_TARGET_GENERIC_GETTY_BAUDRATE_115200=y > -BR2_ROOTFS_POST_IMAGE_SCRIPT="board/acmesystems/aria-g25/post-image.sh" > > # Kernel configuration > BR2_LINUX_KERNEL=y > @@ -34,3 +33,4 @@ BR2_TARGET_AT91BOOTSTRAP3_DEFCONFIG="aria-128m" > BR2_PACKAGE_HOST_DOSFSTOOLS=y > BR2_PACKAGE_HOST_GENIMAGE=y > BR2_PACKAGE_HOST_MTOOLS=y > +BR2_GENIMAGE_CFG_FILES="board/acmesystems/aria-g25/genimage.cfg" I'm still not entirely sure if this new option is worthwhile. Without it, you would instead need BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh" BR2_ROOTFS_POST_SCRIPT_ARGS="board/acmesystems/aria-g25/genimage.cfg" Not really complicated either... The only real advantage I see is that it motivates people more to use genimage (which is otherwise a bit hidden). But for that, a paragraph or two in docs/manual/customize-post-image.txt would also work. By the way, even for this series an explanation of the option would be required in that file. What do the others think? Regards, Arnout
Hi Phelip, Am 31.03.2017 um 00:51 schrieb Arnout Vandecappelle: > > I'm still not entirely sure if this new option is worthwhile. Without it, you > would instead need > > BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh" > BR2_ROOTFS_POST_SCRIPT_ARGS="board/acmesystems/aria-g25/genimage.cfg" > > Not really complicated either... The only real advantage I see is that it > motivates people more to use genimage (which is otherwise a bit hidden). But for > that, a paragraph or two in docs/manual/customize-post-image.txt would also > work. By the way, even for this series an explanation of the option would be > required in that file. > > What do the others think? I have a slightly different use case than most genimage configs in buildroot right now. This is, I use genimage's ability to split my customized rootfs into multiple filesystems in order to give them them ro/writeable and other capabilities as appropriate. Thus to preserve ownership and such I need to run genimage under fakeroot. Currently I do this explicitely in a post image script. An improvement I think about is switching to using the post fakeroot integration which buildroot provides since a while. So unless this becomes some kind of option, your proposed change probably wouldnt work for me. What I was thinking about in the past would be a deeper integration of genimage in buildroots filesystem configuration, actually generating the genimage config. But so far it was not worth the effort for me. regards, Andreas > > > Regards, > Arnout >
On 31-03-17 09:46, Andreas Naumann wrote: > Hi Phelip, > > Am 31.03.2017 um 00:51 schrieb Arnout Vandecappelle: >> >> I'm still not entirely sure if this new option is worthwhile. Without it, you >> would instead need >> >> BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh" >> BR2_ROOTFS_POST_SCRIPT_ARGS="board/acmesystems/aria-g25/genimage.cfg" >> >> Not really complicated either... The only real advantage I see is that it >> motivates people more to use genimage (which is otherwise a bit hidden). But for >> that, a paragraph or two in docs/manual/customize-post-image.txt would also >> work. By the way, even for this series an explanation of the option would be >> required in that file. >> >> What do the others think? > > I have a slightly different use case than most genimage configs in buildroot > right now. This is, I use genimage's ability to split my customized rootfs into > multiple filesystems in order to give them them ro/writeable and other > capabilities as appropriate. > Thus to preserve ownership and such I need to run genimage under fakeroot. It would indeed make sense to run genimage under fakeroot, but then it'd need to have some option to extract the tarball first. Actually, that's something that could be added to the genimage.sh script at some point... > Currently I do this explicitely in a post image script. An improvement I think > about is switching to using the post fakeroot integration which buildroot > provides since a while. > > So unless this becomes some kind of option, your proposed change probably > wouldnt work for me. It is certainly optional, you can always call genimage directly from you post-image script. You can also call the genimage.sh script but I don't know if that's useful in your case. > What I was thinking about in the past would be a deeper integration of genimage > in buildroots filesystem configuration, actually generating the genimage config. > But so far it was not worth the effort for me. We have considered that in the past. The problem is that genimage doesn't support some of the options that we do. Otherwise, however, it would be really nice to remove all our messy filesystem handling code and just generate a genimage.cfg file... OTOH we also considered that a full image typically needs more than just a single filesystem, so generating a genimage.cfg for part of the image seems a bit pointless. Regards, Arnout
Hello, On Fri, 31 Mar 2017 00:51:08 +0200, Arnout Vandecappelle wrote: > I'm still not entirely sure if this new option is worthwhile. Without it, you > would instead need > > BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh" > BR2_ROOTFS_POST_SCRIPT_ARGS="board/acmesystems/aria-g25/genimage.cfg" > > Not really complicated either... The only real advantage I see is that it > motivates people more to use genimage (which is otherwise a bit hidden). But for > that, a paragraph or two in docs/manual/customize-post-image.txt would also > work. By the way, even for this series an explanation of the option would be > required in that file. > > What do the others think? I agree that the new option doesn't seem really useful. Best regards, Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > Hello, > On Fri, 31 Mar 2017 00:51:08 +0200, Arnout Vandecappelle wrote: >> I'm still not entirely sure if this new option is worthwhile. Without it, you >> would instead need >> >> BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh" >> BR2_ROOTFS_POST_SCRIPT_ARGS="board/acmesystems/aria-g25/genimage.cfg" >> >> Not really complicated either... The only real advantage I see is that it >> motivates people more to use genimage (which is otherwise a bit hidden). But for >> that, a paragraph or two in docs/manual/customize-post-image.txt would also >> work. By the way, even for this series an explanation of the option would be >> required in that file. >> >> What do the others think? > I agree that the new option doesn't seem really useful. I'm not sure. One of the problems with genimage is that it calls a number of external utilities depending on the content of genimage.cfg, and it isn't directly clear what host packages you need to enable to ensure it works. If we add explicit BR2_GENIMAGE_FAT / CPIO / EXT2 / ISO / JFFS2 / UBI / .. options selecting the needed host packages then that would solve that issue. I think the option should select BR2_HOST_PACKAGE_GENIMAGE instead of depending on it though.
On 03-04-17 11:06, Peter Korsgaard wrote: >>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > > > Hello, > > On Fri, 31 Mar 2017 00:51:08 +0200, Arnout Vandecappelle wrote: > > >> I'm still not entirely sure if this new option is worthwhile. Without it, you > >> would instead need > >> > >> BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh" > >> BR2_ROOTFS_POST_SCRIPT_ARGS="board/acmesystems/aria-g25/genimage.cfg" > >> > >> Not really complicated either... The only real advantage I see is that it > >> motivates people more to use genimage (which is otherwise a bit hidden). But for > >> that, a paragraph or two in docs/manual/customize-post-image.txt would also > >> work. By the way, even for this series an explanation of the option would be > >> required in that file. > >> > >> What do the others think? > > > I agree that the new option doesn't seem really useful. > > I'm not sure. One of the problems with genimage is that it calls a > number of external utilities depending on the content of > genimage.cfg, and it isn't directly clear what host packages you need to > enable to ensure it works. If we add explicit BR2_GENIMAGE_FAT / CPIO / > EXT2 / ISO / JFFS2 / UBI / .. options selecting the needed host packages > then that would solve that issue. So, how would you do that? To know which host packages to select, we need to parse the genimage.cfg file. This is not possible from Kconfig.... A long time ago (back in the days we still had ct-ng support), someone posted a huge hack to Kconfig to allow it to call an external program while constructing the Kconfig model. Something like that might work, but it's really a huge change to Kconfig semantics. Regards, Arnout > I think the option should select BR2_HOST_PACKAGE_GENIMAGE instead of > depending on it though. >
Hi, Am 31.03.2017 um 18:34 schrieb Arnout Vandecappelle: > > > On 31-03-17 09:46, Andreas Naumann wrote: >> Hi Phelip, >> >> Am 31.03.2017 um 00:51 schrieb Arnout Vandecappelle: >>> >>> I'm still not entirely sure if this new option is worthwhile. Without it, you >>> would instead need >>> >>> BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh" >>> BR2_ROOTFS_POST_SCRIPT_ARGS="board/acmesystems/aria-g25/genimage.cfg" >>> >>> Not really complicated either... The only real advantage I see is that it >>> motivates people more to use genimage (which is otherwise a bit hidden). But for >>> that, a paragraph or two in docs/manual/customize-post-image.txt would also >>> work. By the way, even for this series an explanation of the option would be >>> required in that file. >>> >>> What do the others think? >> >> I have a slightly different use case than most genimage configs in buildroot >> right now. This is, I use genimage's ability to split my customized rootfs into >> multiple filesystems in order to give them them ro/writeable and other >> capabilities as appropriate. >> Thus to preserve ownership and such I need to run genimage under fakeroot. > > It would indeed make sense to run genimage under fakeroot, but then it'd need > to have some option to extract the tarball first. Actually, that's something > that could be added to the genimage.sh script at some point... > >> Currently I do this explicitely in a post image script. An improvement I think >> about is switching to using the post fakeroot integration which buildroot >> provides since a while. >> >> So unless this becomes some kind of option, your proposed change probably >> wouldnt work for me. > > It is certainly optional, you can always call genimage directly from you > post-image script. You can also call the genimage.sh script but I don't know if > that's useful in your case. True, Phelip's option [RFC 2/4] doesnt take away other options. > >> What I was thinking about in the past would be a deeper integration of genimage >> in buildroots filesystem configuration, actually generating the genimage config. >> But so far it was not worth the effort for me. > > We have considered that in the past. The problem is that genimage doesn't > support some of the options that we do. Otherwise, however, it would be really Are you refering to filesystem-specific options or missing ones like axfs, cloop, cramfs? > nice to remove all our messy filesystem handling code and just generate a > genimage.cfg file... > > OTOH we also considered that a full image typically needs more than just a > single filesystem, so generating a genimage.cfg for part of the image seems a > bit pointless. I dont quite understand. Do you mean combining e.g. a standard and a rescue system? regards, Andreas > > Regards, > Arnout >
On 03-04-17 15:01, Andreas Naumann wrote: >>> What I was thinking about in the past would be a deeper integration of genimage >>> in buildroots filesystem configuration, actually generating the genimage config. >>> But so far it was not worth the effort for me. >> >> We have considered that in the past. The problem is that genimage doesn't >> support some of the options that we do. Otherwise, however, it would be really > > Are you refering to filesystem-specific options or missing ones like axfs, > cloop, cramfs? I'm refering to filesystem-specific options. E.g. AFAIK genimage doesn't allow configuration of ext2 #inodes or reserved blocks, or UBIFS max LEB count or compression. >> nice to remove all our messy filesystem handling code and just generate a >> genimage.cfg file... And my point here is: we could just extend genimage with all those options. Then we can use genimage instead of our rootfs handling. For the most part, the rootfs infra could be reduced to a single genimage.cfg file. But as usual: all that would be nice in a way, but doesn't give us any direct advantage over what we have now, and what we have now works. >> >> OTOH we also considered that a full image typically needs more than just a >> single filesystem, so generating a genimage.cfg for part of the image seems a >> bit pointless. > > I dont quite understand. Do you mean combining e.g. a standard and a rescue system? In practice, you rarely use the .ext2 or .ubifs image produced by Buildroot directly; instead, you'll embed it into a larger image that is a lot more complicated than e.g. the .ubi image offered by Buildroot (because you'd want a writeable data volume in addition to the ubifs rootfs). So if we would use genimage for generating the .ext2 rootfs itself, then in practice you'll often end up running genimage twice: once for the .ext2 rootfs, and a second time to integrate it in a larger image. Coming back to the BR2_GENIMAGE_CFG_FILES option: actually it would make a whole lot more sense if the genimage were executed under fakeroot, because then we no longer need to generate the .ext2 subimage. Still, there is hardly any advantage over having this as an explicit option rather than configuring BR2_ROOTFS_POST_FAKEROOT_SCRIPT="support/scripts/genimage.sh" BR2_ROOTFS_POST_SCRIPT_ARGS="-c path/to/my/genimage.cfg" Regards, Arnout
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: Hi, >> >> What do the others think? >> >> > I agree that the new option doesn't seem really useful. >> >> I'm not sure. One of the problems with genimage is that it calls a >> number of external utilities depending on the content of >> genimage.cfg, and it isn't directly clear what host packages you need to >> enable to ensure it works. If we add explicit BR2_GENIMAGE_FAT / CPIO / >> EXT2 / ISO / JFFS2 / UBI / .. options selecting the needed host packages >> then that would solve that issue. > So, how would you do that? To know which host packages to select, we need to > parse the genimage.cfg file. This is not possible from Kconfig.... I would simply leave it to the user to select the correct sub options. The point is just that explicit sub options are clearer than having to reverse engineer genimage to figure out what programs it executes (and then figure out what host packages provide them). > A long time ago (back in the days we still had ct-ng support), someone posted a > huge hack to Kconfig to allow it to call an external program while constructing > the Kconfig model. Something like that might work, but it's really a huge change > to Kconfig semantics. Argh, lets not go there!
Hi, Am 03.04.2017 um 15:54 schrieb Arnout Vandecappelle: > > > On 03-04-17 15:01, Andreas Naumann wrote: >>>> What I was thinking about in the past would be a deeper integration of genimage >>>> in buildroots filesystem configuration, actually generating the genimage config. >>>> But so far it was not worth the effort for me. >>> >>> We have considered that in the past. The problem is that genimage doesn't >>> support some of the options that we do. Otherwise, however, it would be really >> >> Are you refering to filesystem-specific options or missing ones like axfs, >> cloop, cramfs? > > I'm refering to filesystem-specific options. E.g. AFAIK genimage doesn't allow > configuration of ext2 #inodes or reserved blocks, or UBIFS max LEB count or > compression. There is the option to supply extraargs to the mkfs tools of most of the filesystems. However some sizes and LEBs may remain hardcoded/calculated. Dont know if that would suffice. > > >>> nice to remove all our messy filesystem handling code and just generate a >>> genimage.cfg file... > > And my point here is: we could just extend genimage with all those options. > Then we can use genimage instead of our rootfs handling. For the most part, the > rootfs infra could be reduced to a single genimage.cfg file. > > But as usual: all that would be nice in a way, but doesn't give us any direct > advantage over what we have now, and what we have now works. > ditto > >>> >>> OTOH we also considered that a full image typically needs more than just a >>> single filesystem, so generating a genimage.cfg for part of the image seems a >>> bit pointless. >> >> I dont quite understand. Do you mean combining e.g. a standard and a rescue system? > > In practice, you rarely use the .ext2 or .ubifs image produced by Buildroot > directly; instead, you'll embed it into a larger image that is a lot more > complicated than e.g. the .ubi image offered by Buildroot (because you'd want a > writeable data volume in addition to the ubifs rootfs). > > So if we would use genimage for generating the .ext2 rootfs itself, then in > practice you'll often end up running genimage twice: once for the .ext2 rootfs, > and a second time to integrate it in a larger image. I guess a good integration could avoid that, but I assume it would be difficult to predict the many ways people might want to customize this. In addition I also think the practical problems of somehow having to convert Kconfig options to a genimage config are not worth it (even though augeas, which with I played lately, seems like it might provide an elegant way to do this.) > > > Coming back to the BR2_GENIMAGE_CFG_FILES option: actually it would make a > whole lot more sense if the genimage were executed under fakeroot, because then > we no longer need to generate the .ext2 subimage. > > Still, there is hardly any advantage over having this as an explicit option > rather than configuring > > BR2_ROOTFS_POST_FAKEROOT_SCRIPT="support/scripts/genimage.sh" > BR2_ROOTFS_POST_SCRIPT_ARGS="-c path/to/my/genimage.cfg" In fact, this is almost what i do right now. Just a rootfs.tar is created and subsequently processed by genimage (I have a small patch that allows genimage to be fed with a tar in additin to the input dir). regards, Andreas > > Regards, > Arnout > >
On 05-04-17 08:38, Andreas Naumann wrote: > Hi, > > Am 03.04.2017 um 15:54 schrieb Arnout Vandecappelle: [snip] >> Coming back to the BR2_GENIMAGE_CFG_FILES option: actually it would make a >> whole lot more sense if the genimage were executed under fakeroot, because then >> we no longer need to generate the .ext2 subimage. >> >> Still, there is hardly any advantage over having this as an explicit option >> rather than configuring >> >> BR2_ROOTFS_POST_FAKEROOT_SCRIPT="support/scripts/genimage.sh" >> BR2_ROOTFS_POST_SCRIPT_ARGS="-c path/to/my/genimage.cfg" > > In fact, this is almost what i do right now. Just a rootfs.tar is created and > subsequently processed by genimage (I have a small patch that allows genimage to > be fed with a tar in additin to the input dir). I do think it's nicer to run it under fakeroot, rather than creating a tarball that's not going to be used in the end. Especially because it ties in nicely with any rootfs fixups that need to be done, e.g. splitting over several filesystems. Regards, Arnout
On 04-04-17 23:34, Peter Korsgaard wrote: >>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: > Hi, > > >> >> What do the others think? > >> > >> > I agree that the new option doesn't seem really useful. > >> > >> I'm not sure. One of the problems with genimage is that it calls a > >> number of external utilities depending on the content of > >> genimage.cfg, and it isn't directly clear what host packages you need to > >> enable to ensure it works. If we add explicit BR2_GENIMAGE_FAT / CPIO / > >> EXT2 / ISO / JFFS2 / UBI / .. options selecting the needed host packages > >> then that would solve that issue. > > > So, how would you do that? To know which host packages to select, we need to > > parse the genimage.cfg file. This is not possible from Kconfig.... > > I would simply leave it to the user to select the correct sub > options. The point is just that explicit sub options are clearer than > having to reverse engineer genimage to figure out what programs it > executes (and then figure out what host packages provide them). OK, makes sense. Combined with the other discussion in this thread, long-term I see us evolving towards: - deprecate some of the finer-grain fs tuning options we have now; - always using genimage to generate the target filesystems; - position our fs targets more as a 'quick fix' solution than for production; - make host-e2fsprogs etc. blind options again. With that in mind, I'd tend to move the BR2_GENIMAGE_CFG_FILES option to top of the filesystem menu rather than the Build menu. Although perhaps even better would be to disable the filesystem menu entirely if BR2_GENIMAGE_CFG_FILES is not empty (though that would only be if everything can be built with genimage). Regards, Arnout
Hello, On Wed, 5 Apr 2017 17:02:36 +0200, Arnout Vandecappelle wrote: > Combined with the other discussion in this thread, long-term I see us evolving > towards: > > - deprecate some of the finer-grain fs tuning options we have now; > - always using genimage to generate the target filesystems; > - position our fs targets more as a 'quick fix' solution than for production; > - make host-e2fsprogs etc. blind options again. To be honest, I am not sure I share this long-term view. I like the way things are done today, very modular: we can generate just a filesystem image, optionally use genimage afterwards, etc. So the "always using genimage to generate the target filesystem" is not something that I see as an improvement, for example. Best regards, Thomas
Good morning everyone, ----- Le 5 Avr 17, à 12:14, Thomas Petazzoni thomas.petazzoni@free-electrons.com a écrit : > Hello, > > On Wed, 5 Apr 2017 17:02:36 +0200, Arnout Vandecappelle wrote: > >> Combined with the other discussion in this thread, long-term I see us evolving >> towards: >> >> - deprecate some of the finer-grain fs tuning options we have now; >> - always using genimage to generate the target filesystems; >> - position our fs targets more as a 'quick fix' solution than for production; >> - make host-e2fsprogs etc. blind options again. > > To be honest, I am not sure I share this long-term view. I like the way > things are done today, very modular: we can generate just a filesystem > image, optionally use genimage afterwards, etc. So the "always using > genimage to generate the target filesystem" is not something that I see > as an improvement, for example. To sum things up: - Should I add BR2_GENIMAGE_CFG_FILES or reuse the script in the postimage script - if BR2_GENIMAGE_CFG_FILES is choosen, should it 'depends on' or 'select' BR2_PACKAGE_HOST_GENIMAGE? - should I convert all boards or just the one already in this RFC? Best regards -Etienne
On 10-04-17 15:44, Étienne Phélip wrote: > Good morning everyone, > > ----- Le 5 Avr 17, à 12:14, Thomas Petazzoni thomas.petazzoni@free-electrons.com a écrit : > >> Hello, >> >> On Wed, 5 Apr 2017 17:02:36 +0200, Arnout Vandecappelle wrote: >> >>> Combined with the other discussion in this thread, long-term I see us evolving >>> towards: >>> >>> - deprecate some of the finer-grain fs tuning options we have now; >>> - always using genimage to generate the target filesystems; >>> - position our fs targets more as a 'quick fix' solution than for production; >>> - make host-e2fsprogs etc. blind options again. >> >> To be honest, I am not sure I share this long-term view. I like the way >> things are done today, very modular: we can generate just a filesystem >> image, optionally use genimage afterwards, etc. So the "always using >> genimage to generate the target filesystem" is not something that I see >> as an improvement, for example. > > To sum things up: Peter has the final word in things, and nobody objected anymore to introducing BR2_GENIMAGE_CFG_FILES, so: > - Should I add BR2_GENIMAGE_CFG_FILES or reuse the script in the > postimage script Introduce BR2_GENIMAGE_CFG_FILES. > - if BR2_GENIMAGE_CFG_FILES is choosen, should it 'depends on' or > 'select' BR2_PACKAGE_HOST_GENIMAGE? select BR2_PACKAGE_HOST_GENIMAGE Note that since BR2_GENIMAGE_CFG_FILES is a string option, you can't do that directly. You need to introduce a blind helper option: config BR2_GENIMAGE_CFG_FILES_SELECT bool default y if BR2_GENIMAGE_CFG_FILES != "" select BR2_PACKAGE_HOST_GENIMAGE > - should I convert all boards or just the one already in this RFC? I think you can start converting more boards. But you can already stop before all boards are converted. For each board you should verify that the build result with and without your change is identical! To save build time, you may want to use an external toolchain though... Regards, Arnout
diff --git a/board/acmesystems/aria-g25/post-image.sh b/board/acmesystems/aria-g25/post-image.sh deleted file mode 100755 index 2846f56..0000000 --- a/board/acmesystems/aria-g25/post-image.sh +++ /dev/null @@ -1,14 +0,0 @@ -#!/bin/sh - -BOARD_DIR="$(dirname $0)" -GENIMAGE_CFG="${BOARD_DIR}/genimage.cfg" -GENIMAGE_TMP="${BUILD_DIR}/genimage.tmp" - -rm -rf "${GENIMAGE_TMP}" - -genimage \ - --rootpath "${TARGET_DIR}" \ - --tmppath "${GENIMAGE_TMP}" \ - --inputpath "${BINARIES_DIR}" \ - --outputpath "${BINARIES_DIR}" \ - --config "${GENIMAGE_CFG}" diff --git a/configs/acmesystems_aria_g25_128mb_defconfig b/configs/acmesystems_aria_g25_128mb_defconfig index 0ec210f..23bb8b9 100644 --- a/configs/acmesystems_aria_g25_128mb_defconfig +++ b/configs/acmesystems_aria_g25_128mb_defconfig @@ -8,7 +8,6 @@ BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_7=y BR2_TARGET_GENERIC_ISSUE="Welcome to Aria-G25 Buildroot" BR2_TARGET_GENERIC_GETTY_PORT="ttyS0" BR2_TARGET_GENERIC_GETTY_BAUDRATE_115200=y -BR2_ROOTFS_POST_IMAGE_SCRIPT="board/acmesystems/aria-g25/post-image.sh" # Kernel configuration BR2_LINUX_KERNEL=y @@ -34,3 +33,4 @@ BR2_TARGET_AT91BOOTSTRAP3_DEFCONFIG="aria-128m" BR2_PACKAGE_HOST_DOSFSTOOLS=y BR2_PACKAGE_HOST_GENIMAGE=y BR2_PACKAGE_HOST_MTOOLS=y +BR2_GENIMAGE_CFG_FILES="board/acmesystems/aria-g25/genimage.cfg" diff --git a/configs/acmesystems_aria_g25_256mb_defconfig b/configs/acmesystems_aria_g25_256mb_defconfig index a480287..9b44bbe 100644 --- a/configs/acmesystems_aria_g25_256mb_defconfig +++ b/configs/acmesystems_aria_g25_256mb_defconfig @@ -8,7 +8,6 @@ BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_7=y BR2_TARGET_GENERIC_ISSUE="Welcome to Aria-G25 Buildroot" BR2_TARGET_GENERIC_GETTY_PORT="ttyS0" BR2_TARGET_GENERIC_GETTY_BAUDRATE_115200=y -BR2_ROOTFS_POST_IMAGE_SCRIPT="board/acmesystems/aria-g25/post-image.sh" # Kernel configuration BR2_LINUX_KERNEL=y @@ -34,3 +33,4 @@ BR2_TARGET_AT91BOOTSTRAP3_DEFCONFIG="aria-256m" BR2_PACKAGE_HOST_DOSFSTOOLS=y BR2_PACKAGE_HOST_GENIMAGE=y BR2_PACKAGE_HOST_MTOOLS=y +BR2_GENIMAGE_CFG_FILES="board/acmesystems/aria-g25/genimage.cfg"
Use the new BR2_GENIMAGE_CFG_FILES Kconfig symbol to reduce boilerplate and use the generic genimage wrapper. Signed-off-by: Etienne Phelip <etienne.phelip@savoirfairelinux.com> --- board/acmesystems/aria-g25/post-image.sh | 14 -------------- configs/acmesystems_aria_g25_128mb_defconfig | 2 +- configs/acmesystems_aria_g25_256mb_defconfig | 2 +- 3 files changed, 2 insertions(+), 16 deletions(-) delete mode 100755 board/acmesystems/aria-g25/post-image.sh