Hi Simon,
On Tue, Nov 27, 2012 at 10:14 AM, Simon Glass sjg@chromium.org wrote:
Hi Wolfgang,
On Mon, Nov 26, 2012 at 3:03 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message 1353961997-32762-3-git-send-email-sjg@chromium.org you
wrote:
+- CONFIG_NO_RESET_CODE
If defined, the x86 reset vector code is excluded. Youwill need
to do this when U-Boot is running from Coreboot.Sorry fr never ending nitpicking - but either this is some x86 specific stuff, then it would probably make sense to have such indication in the name of the define, or it is not, then the comment should be fixed.
+START-$(CONFIG_SYS_X86_RESET_VECTOR) += resetvec.o start16.o
CONFIG_SYS_X86_RESET_VECTOR - is this just another new, undocumented variable?
Yes it is new and undocumented, because it is internal to the x86 implementation and I don't want people to set it.
Or a mismatch between documentation and code?
Well there are now two options:
- The user-facing CONFIG_NO_RESET_CODE option which, if not defined,
asserts CONFIG_SYS_X86_RESET_VECTOR 2. CONFIG_SYS_X86_RESET_VECTOR which is used in the Makefiles
I would rather have a single positive option (CONFIG_SYS_X86_RESET_VECTOR, as series v4). Failing that I would rather have ifneq in the Makefile (and just use CONFIG_NO_RESET_CODE). I am not sure how to have a negative option without an ifneq in the Makefile. I looked pretty hard but could not find an example in U-Boot.
That is the crux of the problem - we want to have a config define which _excludes_ the compilation of some code (in this case the reset vector). This should be expanded to optionally exclude the 16-bit 'Real Mode' code (with the ultimate goal of dropping that code altogether).
My vote would be for a CONFIG_X86_NO_RESET_VECTOR (and CONFIG_X86_NO_REAL_MODE) and just use ifneq in the Makefile
Re CONFIG_NO_RESET_CODE, it probably should be CONFIG_SYS_X86_NO_RESET_CODE, but it would be even better if we could just have one option. I worry that people will be confused by one that they set, which affects another that is set if they don't see the first...In a month I will probably find it confusing.
This is possible a minor point since I think Graeme said that the only other x86 board will move to Coreboot soon.
Actually, I said that the only other x86 board will be dropped from U-Boot as the processor is no longer available.
Regards,
Graeme