Hi Gabe,
On 05/11/11 09:33, Gabe Black wrote:
The early startup code is in arch/x86/cpu/start.S or start16.S depending on the state of the CPU when u-boot is entered, and this code is called back into at various points during startup. You can see that those callbacks stubbed out where there's a label and then a jump back immediately after it, for instance here:
+board_init16:
jmp board_init16_retI have no problem merging the commits, but I'll wait for Graeme to weigh in since it's a little easier to merge them than to unmerge them.
Well I guess that is my cue ;)
I agree that this should be a single commit. I have a few other comments...
I'm just about to send through another patchset (today) which will probably impact on your patches - In particular I am adding more config granularity to deal with the horrible mess that is board_init_r(). Now that the merge window is closed, I will create a 'next' branch which you can work from.
Since coreboot is doing all the low level initialisation, I don't see the need for any of the 16-bit start code (start_16.S). Let's look at CONFIG_SKIP_LOWLEVEL_INIT. I don't know how to _not_ compile a source file based on a define using the COBJS-$(CONFIG_<blah>) style.
Also, we may be performing a completely unnecessary relocation - I think we should be able to start at board_init_r(), but there may be some board_init_f() functions that we may still need to call. This seems a very close parallel to IPL/SPL - Have a look at what they do
From what I can gather, the likely scenario is that U-Boot will always be
loaded by coreboot on the chromebook, and it's likely that other coreboot motherboards may want to do the same. Therefore can you change: board/chromebook-x86/coreboot to: board/coreboot/chromebook-x86/
Regarding the empty functions, I know they are required to keep the linker happy. I see two options:
1) #ifdef the call sites 2) create weak stubs
I'm open to debate on the preferred approach
Regards,
Graeme
Gabe
On Fri, Nov 4, 2011 at 3:24 PM, Mike Frysinger <vapier@gentoo.org mailto:vapier@gentoo.org> wrote:
i'm not terribly familiar with what it takes to make an x86 board, but i don't see anything jumping out of this patch. i would note however that you should merge the boards.cfg update into this patch. merging one or the other doesn't make much sense, and there's no reason to keep them split. > +void setup_pcat_compatibility() should be "(void)" -mike