On Thu, 1970-01-01 at 00:00 +0000, Simon Goldschmidt wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > On 06.02.2018 09:20, Joakim Tjernlund wrote: > > On Thu, 1970-01-01 at 00:00 +0000, Simon Goldschmidt wrote: > > > > ..... > > > > Reviewed-by: Andre Przywara <andre.przyw...@arm.com> > > > > Reviewed-by: Simon Glass <s...@chromium.org> > > > > Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com> > > > > --- > > > > env/env.c | 80 > > > > +++++++++++++++++++++++++++++++++++--------------------- > > > > 1 file changed, 50 insertions(+), 30 deletions(-) > > > > > > > > diff --git a/env/env.c b/env/env.c > > > > index 906f28ee50a1..1182fdb545db 100644 > > > > --- a/env/env.c > > > > +++ b/env/env.c > > > > @@ -26,6 +26,41 @@ static struct env_driver *_env_driver_lookup(enum > > > > env_location loc) > > > > return NULL; > > > > } > > > > > > > > +static enum env_location env_locations[] = { > > > > Don't use static/global variables. They cause a lot of relocation work/size > > and is less flexible. > > In this specific case, I think this array should be const anyway, would > that prevent the relocation problems you see?
> > > There is no way to #define ENVL_EEPROM to a function > > when a variable. > > ENVL_EEPROM is an enum value, why would you define it to a function? I got boards that very similar but differ in where/how env. is stored, like different flash so I need to be able to select at runtime how get my env., I haven't looked if this particular area is affected but ideally I would like if all env. related "constants" could be impl. with a function instead. Also, using static/global vars takes more space than simple assignments in code, ideally everything needed early (before reloc/ in SPL) should avoid relocations to save space. Jocke _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot