Hi, This is a ping to revive this patch and the next one in the series: "[PATCH 3/3] vexpress64: store env in flash"
Patch 1/3 was resent separately and has been merged. This patch (and the subsequent one in the series) hasn't been Reviewed-by or Acked-by anyone, but in a thread for patch 3/3 in this series, Tom Rini and I had this conversation: Tom> The host tools are not board-independent as they include a copy of the Tom> target board env. Keep that in mind. Me> So that means we can't use #error in the target board include file Me> (eg. vexpress_aemv8a.h) to indicate that no board was set, correct? Tom> Correct. So if Juno wants to use the NOR flash and therefore, the host tools, then first we need this patch to remove the #error statements. Thanks, Ryan. On 27 October 2015 at 12:29, Ryan Harkin <[email protected]> wrote: > On 27 October 2015 at 11:36, Linus Walleij <[email protected]> wrote: >> On Wed, Oct 21, 2015 at 11:54 AM, Ryan Harkin <[email protected]> wrote: >> >>> This patch allows vexpress64 targets to be compiled when >>> CONFIG_SYS_FLASH_CFI is enabled. >> >> I can't see what this has to do with enabling CFI? > > The errors happen when I enable CFI on Juno or FVP. Enabling CFI > support includes envcrc.c into the build, which then includes > include/config.h, which in turn includes > include/configs/vexpress_aemv8a.h, but without a board defined, > despite building a Juno or FVP configuration. I don't really know why > the board isn't defined at that point. > > Looking deeper into why envcrc is included into the build, it was > another #define that included it. > > I can see that tools/Makefile adds envcrc if CONFIG_BUILD_ENVCRC is > defined, which in turn is enabled if ENVCRC-y is defined, which seems > to happen if CONFIG_ENV_IS_IN_FLASH is defined. > > So my comment is wrong. > >> >>> I considered using #warning instead of #error, but this just clutters up >>> the build output and hides real warnings. >>> >>> Without this patch, you see errors during compilation like this: >>> >>> include/configs/vexpress_aemv8a.h:42:2: error: #error "Unknown board >>> variant" >>> #error "Unknown board variant" >> >> The #error is there because noone could answer the question I >> posed: what AEMv8 boards are there that are neither FVP nor >> Juno? > > AEMv8 may be the wrong term anyway. I *think* AEMv8 really only > refers to one flavour of the FVP: AEMv8 is an representation of the > complete ARMv8 architecture, not of a specific CPU variant such as > Cortex A57, which omits some of the arch. > > Everything we're including in this vexpress_aemv8a file is really more > like just vexpress64, with variants inside it for Juno and FVP. > > And with a bit of code to detect and handle the platform differences, > we could probably create a single binary that works on everything > covered by this config. Although I think the #define for the CFI base > address could be a sticking point there. > > Currently, ARM have: > > Models: > - FVP Foundation models > - FVP AEMv8 models > - FVP Cortex A57/A53 models > > ^ the same binary runs on all three, although I never test on Cortex > models. There is a semihosting variant and I've created a DRAM > variant. > > Real boards: > - Juno R0 > - Juno R1 > > ^ the same binary runs on both > > There are no other public platforms, to my knowledge. ARM have some > internal models that have different peripheral sets, CPU > configurations, etc... but these aren't covered by the public code at > all. > >> >> So what board variant are you compiling for here? I suspect a >> non-upstream thingofabob? Maybe there is a better way to cater >> for that than this magic catch-all? > > I was building for Juno. > > >> >> Yours, >> Linus Walleij _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
