Re: [U-Boot] [PATCH v3 12/15] env: Allow to build multiple environments in Kconfig
On 01.02.2018 20:47, Maxime Ripard wrote:
On Thu, Feb 01, 2018 at 11:06:14AM +0100, Simon Goldschmidt wrote:
On 23.01.2018 21:17, Maxime Ripard wrote:
Now that we have everything in place in the code, let's allow to build multiple environments backend through Kconfig.
Reviewed-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Lukasz Majewski lukma@denx.de Reviewed-by: Simon Glass sjg@chromium.org Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
I get a build error when enabling CONFIG_ENV_IS_IN_SPI_FLASH and CONFIG_ENV_IS_IN_MMC at the same time.
Is that happening in any of the current defconfig right now? Or is it only when you add more environments?
No, this is with my own config. I'm trying out the new feature :-)
The build error is in host tools, not in U-Boot or SPL itself. In fact, this is not specific to CONFIG_ENV_IS_IN_SPI_FLASH but to the combination of CONFIG_ENV_IS_IN_MMC and any of the environments marked as ENVCRC- in tools/Makefile.
The actual error is that the compiler does not know standard types in efi.h and mmc.h, e.g.: In file included from include/blk.h:11:0, from include/part.h:10, from include/mmc.h:16, from include/environment.h:168, from ./tools/../env/embedded.c:16, from tools/env/embedded.c:2: include/efi.h:32:2: error: unknown type name ‘u8’ u8 b[16]; ^~
I can't think of a correct fix right now...
I'm not sure what it could be either, that file looks like it would need a quite big rework, in order to be able to operate properly.
Do you actually need those? Maybe we can just disable those in Kconfig to forbid such a combination?
I planned to have the environment in both SPI flash and eMMC to be able to use a common U-Boot binary accross multiple boards.
I don't need 'tools/envcrc' though. And this is where the build error is.
Maybe we could disable the combination for 'tools/envcrc' only?
Simon
On Sat, Feb 03, 2018 at 10:23:12AM +0000, Goldschmidt Simon wrote:
On 01.02.2018 20:47, Maxime Ripard wrote:
On Thu, Feb 01, 2018 at 11:06:14AM +0100, Simon Goldschmidt wrote:
On 23.01.2018 21:17, Maxime Ripard wrote:
Now that we have everything in place in the code, let's allow to build multiple environments backend through Kconfig.
Reviewed-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Lukasz Majewski lukma@denx.de Reviewed-by: Simon Glass sjg@chromium.org Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
I get a build error when enabling CONFIG_ENV_IS_IN_SPI_FLASH and CONFIG_ENV_IS_IN_MMC at the same time.
Is that happening in any of the current defconfig right now? Or is it only when you add more environments?
No, this is with my own config. I'm trying out the new feature :-)
The build error is in host tools, not in U-Boot or SPL itself. In fact, this is not specific to CONFIG_ENV_IS_IN_SPI_FLASH but to the combination of CONFIG_ENV_IS_IN_MMC and any of the environments marked as ENVCRC- in tools/Makefile.
The actual error is that the compiler does not know standard types in efi.h and mmc.h, e.g.: In file included from include/blk.h:11:0, from include/part.h:10, from include/mmc.h:16, from include/environment.h:168, from ./tools/../env/embedded.c:16, from tools/env/embedded.c:2: include/efi.h:32:2: error: unknown type name ‘u8’ u8 b[16]; ^~
I can't think of a correct fix right now...
I'm not sure what it could be either, that file looks like it would need a quite big rework, in order to be able to operate properly.
Do you actually need those? Maybe we can just disable those in Kconfig to forbid such a combination?
I planned to have the environment in both SPI flash and eMMC to be able to use a common U-Boot binary accross multiple boards.
I don't need 'tools/envcrc' though. And this is where the build error is.
Maybe we could disable the combination for 'tools/envcrc' only?
Apparently, envcrc is used to generate the CRC of an embedded environment image inside the U-Boot image, which would be triggered in some specific cases.
I'm not sure we can disable it without breaking use cases.
in this particular case, it seems that the u8 typedef is done at the architecture level, and efi.h doesn't include asm/types.h that define it. Maybe it's as simple as that. Otherwise, it includes linux/types.h that defines uint8_t, we can use that instead.
Maxime
On 05.02.2018 14:32, Maxime Ripard wrote:
On Sat, Feb 03, 2018 at 10:23:12AM +0000, Goldschmidt Simon wrote:
On 01.02.2018 20:47, Maxime Ripard wrote:
On Thu, Feb 01, 2018 at 11:06:14AM +0100, Simon Goldschmidt wrote:
On 23.01.2018 21:17, Maxime Ripard wrote:
Now that we have everything in place in the code, let's allow to build multiple environments backend through Kconfig.
Reviewed-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Lukasz Majewski lukma@denx.de Reviewed-by: Simon Glass sjg@chromium.org Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
I get a build error when enabling CONFIG_ENV_IS_IN_SPI_FLASH and CONFIG_ENV_IS_IN_MMC at the same time.
Is that happening in any of the current defconfig right now? Or is it only when you add more environments?
No, this is with my own config. I'm trying out the new feature :-)
The build error is in host tools, not in U-Boot or SPL itself. In fact, this is not specific to CONFIG_ENV_IS_IN_SPI_FLASH but to the combination of CONFIG_ENV_IS_IN_MMC and any of the environments marked as ENVCRC- in tools/Makefile.
The actual error is that the compiler does not know standard types in efi.h and mmc.h, e.g.: In file included from include/blk.h:11:0, from include/part.h:10, from include/mmc.h:16, from include/environment.h:168, from ./tools/../env/embedded.c:16, from tools/env/embedded.c:2: include/efi.h:32:2: error: unknown type name ‘u8’ u8 b[16]; ^~
I can't think of a correct fix right now...
I'm not sure what it could be either, that file looks like it would need a quite big rework, in order to be able to operate properly.
Do you actually need those? Maybe we can just disable those in Kconfig to forbid such a combination?
I planned to have the environment in both SPI flash and eMMC to be able to use a common U-Boot binary accross multiple boards.
I don't need 'tools/envcrc' though. And this is where the build error is.
Maybe we could disable the combination for 'tools/envcrc' only?
Apparently, envcrc is used to generate the CRC of an embedded environment image inside the U-Boot image, which would be triggered in some specific cases.
I'm not sure we can disable it without breaking use cases.
I didn't want to suggest removing envcrc. I'd rather wanted to somehow prevent including "mmc.h" when compiling for envcrc... Anyway, that would be a hack to make it work for me.
in this particular case, it seems that the u8 typedef is done at the architecture level, and efi.h doesn't include asm/types.h that define it. Maybe it's as simple as that. Otherwise, it includes linux/types.h that defines uint8_t, we can use that instead.
Digging into this again, it seems clear that this doesn't work since 'u8' is meant for kernel space while user space should use '__u8'. Envcrc *is* userspace, so using uint8_t everywhere makes more sense.
Simon
On Tue, Feb 06, 2018 at 09:24:02AM +0100, Simon Goldschmidt wrote:
in this particular case, it seems that the u8 typedef is done at the architecture level, and efi.h doesn't include asm/types.h that define it. Maybe it's as simple as that. Otherwise, it includes linux/types.h that defines uint8_t, we can use that instead.
Digging into this again, it seems clear that this doesn't work since 'u8' is meant for kernel space while user space should use '__u8'. Envcrc *is* userspace, so using uint8_t everywhere makes more sense.
Yes, but the offending variable is in include/efi.h, which would be included by both (but probably not intentionally in the envcrc case).
Maxime
participants (3)
-
Goldschmidt Simon -
Maxime Ripard -
Simon Goldschmidt