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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.