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_ret
>
> I 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 <[email protected]
> <mailto:[email protected]>> 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
>
>
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
