[U-Boot] testing x86 builds on the fly

[U-Boot] testing x86 builds on the fly

[Mike Frysinger]

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 ?

burning to flash is both horribly slow and dangerous :x.
-mike

[U-Boot] testing x86 builds on the fly

[Marek Vasut]

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 ?
> 
> burning to flash is both horribly slow and dangerous :x.

You want to use uboot as a bios replacement? Won't coreboot be better for that 
(which would in turn load uboot if needed) ?

> -mike
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] testing x86 builds on the fly

[Mike Frysinger]

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 ?
>>
>> burning to flash is both horribly slow and dangerous :x.
>
> You want to use uboot as a bios replacement? Won't coreboot be better for that
> (which would in turn load uboot if needed) ?

for now i'd like to stick to u-boot and fall back to coreboot only if
necessary (because u-boot cant do what i desire).  this behavior is
possible on Blackfin systems already ... i test all the time there by
doing 'tftp 0 u-boot.bin;go 0'.
-mike

[U-Boot] testing x86 builds on the fly

[Graeme Russ]

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 ?

No quite - Now that DRAM init has been moved into C code in board_init_f
(i.e. used Cache-as-Ram) you need to be a bit careful. For the eNET, I have
SRAM were I can load u-boot.bin and do a simple tftp/go combo since SRAM is
not clobbered during SDRAM init (refer to the two eNET board definitions in
boards.cfg - they have different text bases)

The real-mode reset entry point for a Flash image is 16 bytes from the end
of u-boot.bin. This switches the CPU into protected mode and then jumps to
the beginning of u-boot.bin which is where the 32-bit protected mode entry
point is. So the 'go' address == tftp load address == TEXT_BASE

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)

>>>
>>> burning to flash is both horribly slow and dangerous :x.
>>
>> You want to use uboot as a bios replacement? Won't coreboot be better for that
>> (which would in turn load uboot if needed) ?
> 
> for now i'd like to stick to u-boot and fall back to coreboot only if
> necessary (because u-boot cant do what i desire).  this behavior is
> possible on Blackfin systems already ... i test all the time there by
> doing 'tftp 0 u-boot.bin;go 0'.
> -mike

Well my plan is to make U-Boot the x86 u-boot image a multiboot image
(apparently a trivial header anywhere in the first 8k of the image). I can
then use GRUB to launch U-Boot. I already have a USB key with GRUB
installed which boots on my old VIA EPIA board, so it's a simple matter of
copying the new U-Boot image onto the USB key, insert and reboot. BIOS will
do the SDRAM init for me until I can figure out how to

When I have a U-Boot image that I'm happy with, I'll flash it

Now if only I could find some time ;)

Regards,

Graeme

[U-Boot] testing x86 builds on the fly

[Graeme Russ]

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