public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Graeme Russ <graeme.russ@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] testing x86 builds on the fly
Date: Sun, 07 Aug 2011 10:54:32 +1000	[thread overview]
Message-ID: <4E3DE248.5030408@gmail.com> (raw)
In-Reply-To: <CAJaTeTp8Mndoex+OY_9hMKj=fB-HyVu9y8PBiUzbNSCZ=hFQag@mail.gmail.com>

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

  reply	other threads:[~2011-08-07  0:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-06 11:22 [U-Boot] testing x86 builds on the fly Mike Frysinger
2011-08-06 12:49 ` Marek Vasut
2011-08-06 23:43   ` Mike Frysinger
2011-08-07  0:54     ` Graeme Russ [this message]
2011-08-07 10:21       ` Graeme Russ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E3DE248.5030408@gmail.com \
    --to=graeme.russ@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox