From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Sun, 07 Aug 2011 20:21:21 +1000 Subject: [U-Boot] testing x86 builds on the fly In-Reply-To: <4E3DE248.5030408@gmail.com> References: <201108061449.02748.marek.vasut@gmail.com> <4E3DE248.5030408@gmail.com> Message-ID: <4E3E6721.1020002@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 Mike, Marek, On 07/08/11 10:54, Graeme Russ wrote: > Hi Mike, Marek, > > On 07/08/11 09:43, Mike Frysinger wrote: >> On Sat, Aug 6, 2011 at 05:49, Marek Vasut wrote: >>> On Saturday, August 06, 2011 01:22:38 PM Mike Frysinger wrote: >>>> disclaimer: i have like 0 u-boot experience on x86. but i cant find >>>> README's in the src to answer my questions. >>>> >>>> the PIC support on x86 is finished right ? so does that mean we can >>>> take a u-boot.bin, tftp it to a running system into external memory, >>>> and then boot that on the fly purely for testing purposes ? A little more explanation... I did once have full PIC support for x86 when loaded with SDRAM already initialised - It would figure out were it was loaded in relation to TEXT_BASE and perform the required adjustments during the relocation phase). But this functionality was removed when the Cache-As-RAM implementation was introduced. [snip] > Now it would be fairly trivial to add a parameter passed by the 'go' > command which sets a flag in global data that would tell board_init_f to > not perform SDRAM init which is on my todo list (see below) Well I just looked at the code and the warm reset entry point sets GD_FLG_WARM_BOOT in gd->flags so you could easily bypass SDRAM initialisation by doing a test in the arch specific dram_init_f() int dram_init_f(void) { if (gd->flags | GD_FLG_WARM_BOOT) return 0; ... } Regards, Graeme