From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Sat, 05 Nov 2011 12:59:43 +1100 Subject: [U-Boot] [PATCH v2] [x86] Add a basic implementation for a coreboot board In-Reply-To: References: <1320443602-2677-1-git-send-email-gabeblack@chromium.org> <201111041824.24804.vapier@gentoo.org> Message-ID: <4EB4988F.1030507@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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_) 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