Le 08/01/2011 14:17, Aneesh V a écrit : >> Why use pointers here rather than weak functions? > > In fact, I hadn't thought about it. Maybe I was biased by the Linux > implementation.The only reason I can think of is that pointer gives the > flexibility of doing this assignment at run-time. Let's say we had a > multi-platform u-boot that detects the SOC at run-time?
I know we consider multi-board u-boot binaries when boards are variant of a given SoC, that's one reason why we wanted relocation. I'm not sure about multi-SoC when SoC is a variant of a given cpu, though. Wolfgang, your opinion? >>> +void flush_cache(unsigned long start, unsigned long size) >>> +{ >>> + flush_dcache_range(start, start + size); >>> +} >> >> This function is the only one which is defined to something non-empty >> when CONFIG_SYS_NO_DCACHE is defined. Why is it not in the big #ifndef >> for dcache above ? > > Although this function is non-empty, flush_dcache_range() is in turn > empty. Effect will be the same, right? Yes the effect is the same, but your patch results in a non-trivially empty function; I'd prefer it to be visibly empty when we compile without cache support. >>> diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk >>> index 49ac9c7..7f9b171 100644 >>> --- a/arch/arm/cpu/armv7/config.mk >>> +++ b/arch/arm/cpu/armv7/config.mk >>> @@ -23,7 +23,7 @@ >>> PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float >>> >>> # Make ARMv5 to allow more compilers to work, even though its v7a. >>> -PLATFORM_CPPFLAGS += -march=armv5 >>> +PLATFORM_CPPFLAGS += -march=armv7-a >> >> Did you check that this does not break any board using armv7? > > I checked only Codesourcery tool chain. > Linux kernel build for a v7 architecture processor uses armv7-a. Is it > not fair to assume that the toolchain used for bootloader also supports > it? Do we have to support those out-dated compilers? Just because Linux uses armv7-a for a v7 arch does not mean we must have it for u-boot. For starters, U-boot does not always boot Linux. :) As for out-dated compilers, that's the question I'm asking: do we consider e.g. ELDK 4.2 as outdated or not? It won't accept armv7-a. >>> +/* some utility macros */ >>> +#define mask(start, end) \ >>> + (((1<< ((end) - (start) + 1)) - 1)<< (start)) >>> + >>> +#define mask_n_get(reg, start, end) \ >>> + (((reg)& mask(start, end))>> (start)) >> >> Seeing as these functions are only used in the ARMv7 cache C file, they >> should be moved there. > > I plan to use a modified version of mask_n_get() and its set couterpart > mask_n_set() in my subsequent works in more files. > > Can I keep it here itself or should I move it to an OMAP specific > header file or can I move it to a more generic header file? Please > suggest. They're very generic actually. I think they should go to a gereric bit manipulation header, and be named a... bit... more explicitly. For instance, the name 'mask' does not show that the macro creates a range of 'one' bits from start to end. > Best regards, > Aneesh Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot