| Message ID | 1443029143-22313-4-git-send-email-ryan.harkin@linaro.org |
|---|---|
| State | New |
| Headers | show |
On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote: > As config migrates from board config files to Kconfig, when adding > CONFIG_SYS_BOOTM_LEN to a platform, I decided to add > Kconfig support for CONFIG_SYS_BOOTM_LEN. > > Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > CC: Masahiro Yamada <yamada.m@jp.panasonic.com> > CC: Simon Glass <sjg@chromium.org> > CC: Linus Walleij <linus.walleij@linaro.org> Thanks for trying to do this. The problem however is that you need to use tools/moveconfig.py so that all of the other boards (which is a lot) get updated too, otherwise they fail to build. Since that's kind of a big thing, can you split this series into a v2 of things which really should be in before the release, and then nice cleanups like this which can go in once the merge window is open again? Thanks!
Thanks Tom. On 28 September 2015 at 16:10, Tom Rini <trini@konsulko.com> wrote: > On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote: > > > As config migrates from board config files to Kconfig, when adding > > CONFIG_SYS_BOOTM_LEN to a platform, I decided to add > > Kconfig support for CONFIG_SYS_BOOTM_LEN. > > > > Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org> > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > > CC: Masahiro Yamada <yamada.m@jp.panasonic.com> > > CC: Simon Glass <sjg@chromium.org> > > CC: Linus Walleij <linus.walleij@linaro.org> > > Thanks for trying to do this. The problem however is that you need to > use tools/moveconfig.py so that all of the other boards (which is a lot) > get updated too, otherwise they fail to build. > Yes, I just read another email on the list about using moveconfig.py. That's a big job, as you say. > Since that's kind of a big thing, can you split this series into a v2 of > things which really should be in before the release, and then nice > cleanups like this which can go in once the merge window is open again? Thanks! > So I should post a v2 that uses CONFIG_SYS_BOOTM_LEN like all the other boards for now? Then submit a new series to use moveconfig.py to Kconfig? I already tried using moveconfig.py for this and it fails on every instance, from what I can tell. I think the other board configs using the shift operation makes this tricky. I guess there are two options: make Kconfig support complex values (eg. to allow << operators, etc.) or convert all the other boards to use absolute values. Of course, another option is to leave it alone. > > -- > Tom >
On Mon, Sep 28, 2015 at 04:35:09PM +0100, Ryan Harkin wrote: > Thanks Tom. > > On 28 September 2015 at 16:10, Tom Rini <trini@konsulko.com> wrote: > > > On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote: > > > > > As config migrates from board config files to Kconfig, when adding > > > CONFIG_SYS_BOOTM_LEN to a platform, I decided to add > > > Kconfig support for CONFIG_SYS_BOOTM_LEN. > > > > > > Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org> > > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > > > CC: Masahiro Yamada <yamada.m@jp.panasonic.com> > > > CC: Simon Glass <sjg@chromium.org> > > > CC: Linus Walleij <linus.walleij@linaro.org> > > > > Thanks for trying to do this. The problem however is that you need to > > use tools/moveconfig.py so that all of the other boards (which is a lot) > > get updated too, otherwise they fail to build. > > > > Yes, I just read another email on the list about using moveconfig.py. > That's a big job, as you say. > > > > Since that's kind of a big thing, can you split this series into a v2 of > > things which really should be in before the release, and then nice > > cleanups like this which can go in once the merge window is open again? > > Thanks! > > > > So I should post a v2 that uses CONFIG_SYS_BOOTM_LEN like all the other > boards for now? Then submit a new series to use moveconfig.py to Kconfig? Yeah, for this release at least. > I already tried using moveconfig.py for this and it fails on every > instance, from what I can tell. I think the other board configs using the > shift operation makes this tricky. > > I guess there are two options: make Kconfig support complex values (eg. to > allow << operators, etc.) or convert all the other boards to use absolute > values. Of course, another option is to leave it alone. Well, if you can convince the Kconfig folks to take shift operations as valid values on numeric inputs I bet other projects would appreciate it. But it might be easier to start with a "simple" script that finds all of the configs that define it to a shifted value and use printf to convert it to hex. Then moveconfig.py should be able to convert.
Hi, On 28-09-15 17:10, Tom Rini wrote: > On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote: > >> As config migrates from board config files to Kconfig, when adding >> CONFIG_SYS_BOOTM_LEN to a platform, I decided to add >> Kconfig support for CONFIG_SYS_BOOTM_LEN. >> >> Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org> >> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> >> CC: Masahiro Yamada <yamada.m@jp.panasonic.com> >> CC: Simon Glass <sjg@chromium.org> >> CC: Linus Walleij <linus.walleij@linaro.org> > > Thanks for trying to do this. The problem however is that you need to > use tools/moveconfig.py so that all of the other boards (which is a lot) > get updated too, otherwise they fail to build. No, just no, not more polluting of defconfig files with things which really belong in a per SoC file not a per board file. I think we can fix the "make savedefconfig" warnings by doing something like this in a per SoC Kconfig file: if ARCH_SUNXI defconfig SYS_BOOTM_LEN default 0x0f000000 if ARCH_SUNXI endif The second "if ARCH_SUNXI" is necessary to stop the script calling "make savedefconfig" for all boards to clean the defconfig files from complaining. Please let set per SoC defaults this way rather then turning the defconfig files in a mixture of board / soc settings where as they should really only select the SoC and then contain board specific settings on top of that. Regards, Hans
On Mon, Sep 28, 2015 at 09:22:35PM +0200, Hans de Goede wrote: > Hi, > > On 28-09-15 17:10, Tom Rini wrote: > >On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote: > > > >>As config migrates from board config files to Kconfig, when adding > >>CONFIG_SYS_BOOTM_LEN to a platform, I decided to add > >>Kconfig support for CONFIG_SYS_BOOTM_LEN. > >> > >>Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org> > >>Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > >>CC: Masahiro Yamada <yamada.m@jp.panasonic.com> > >>CC: Simon Glass <sjg@chromium.org> > >>CC: Linus Walleij <linus.walleij@linaro.org> > > > >Thanks for trying to do this. The problem however is that you need to > >use tools/moveconfig.py so that all of the other boards (which is a lot) > >get updated too, otherwise they fail to build. > > No, just no, not more polluting of defconfig files with things which really > belong in a per SoC file not a per board file. Well, we should be putting SoC/arch-specific stuff into the defaults and also using this as a chance to look at places where defaults differ pointlessly. But, I also hear your concern. I see Masahiro has been working with merge_config.sh from the kernel in the kernel. How crazy would it be to re-work things (in some cases..) to have a merge in the config process so that there could be a sunxi-common config fragment. Or can/should we really just use default foo if Y in more places.
Hi, On 28-09-15 23:12, Tom Rini wrote: > On Mon, Sep 28, 2015 at 09:22:35PM +0200, Hans de Goede wrote: >> Hi, >> >> On 28-09-15 17:10, Tom Rini wrote: >>> On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote: >>> >>>> As config migrates from board config files to Kconfig, when adding >>>> CONFIG_SYS_BOOTM_LEN to a platform, I decided to add >>>> Kconfig support for CONFIG_SYS_BOOTM_LEN. >>>> >>>> Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org> >>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> >>>> CC: Masahiro Yamada <yamada.m@jp.panasonic.com> >>>> CC: Simon Glass <sjg@chromium.org> >>>> CC: Linus Walleij <linus.walleij@linaro.org> >>> >>> Thanks for trying to do this. The problem however is that you need to >>> use tools/moveconfig.py so that all of the other boards (which is a lot) >>> get updated too, otherwise they fail to build. >> >> No, just no, not more polluting of defconfig files with things which really >> belong in a per SoC file not a per board file. > > Well, we should be putting SoC/arch-specific stuff into the defaults Agreed, but where, do we add a long list of: default FOO if ARCH_BAR To the Kconfig file where the actual CONFIG_SOMETHING gets defined, or do we add it to board/bar/Kconfig ? Currently we've a bit of a mix, I personally prefer the board/bar/Kconfig version as that puts everything for one SoC(-family) in one place and it helps avoiding merge conflicts. > and > also using this as a chance to look at places where defaults differ > pointlessly. > > But, I also hear your concern. I see Masahiro has been working with > merge_config.sh from the kernel in the kernel. How crazy would it be > to re-work things (in some cases..) to have a merge in the config > process so that there could be a sunxi-common config fragment. Either we then ask the user to take an extra step during building (not a good idea IMHO), or we somehow need to automate this, which is hard because figuring out which foo_common_config fragment belongs to which board_defconfig file is going to be hard and / or will involve a long list of hardcoded values in a Makefile or some such. > Or > can/should we really just use default foo if Y in more places. I believe that this is the better option, currently board/sunxi/Kconfig already has: config SYS_CLK_FREQ default 912000000 if MACH_SUN7I default 1008000000 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN8I config SYS_CONFIG_NAME default "sun4i" if MACH_SUN4I default "sun5i" if MACH_SUN5I default "sun6i" if MACH_SUN6I default "sun7i" if MACH_SUN7I default "sun8i" if MACH_SUN8I default "sun9i" if MACH_SUN9I Apparently these are not a problem for the script which is used to rewrite all the defconfig-s, where as in the past having: config CMD_FOO default y in board/sunxi/Kconfig was a problem (it caused the script to emit a ton of warnings IIRC) so I guess that doing something like: config FOO default bar if ARCH_SUNXI Will workaround the script issuing all kind of warnings, and then we can keep per SoC(-family) defaults in board/foo/Kconfig. Regards, Hans
diff --git a/Kconfig b/Kconfig index 05a34f7..7783a13 100644 --- a/Kconfig +++ b/Kconfig @@ -190,6 +190,13 @@ config SYS_CLK_FREQ help TODO: Move CONFIG_SYS_CLK_FREQ for all the architecture +config CONFIG_SYS_BOOTM_LEN + hex "Max uImage length" + help + Normally compressed uImages are limited to an uncompressed size of + 8 MBytes. If this is not enough, you can define CONFIG_SYS_BOOTM_LEN + to adjust this setting to your needs. + endmenu # Boot images source "common/Kconfig"