From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] 64-bit x86 U-Boot?
Date: Mon, 1 Feb 2016 08:14:46 +0100 [thread overview]
Message-ID: <20160201081446.378e1f5b@lilith> (raw)
In-Reply-To: <CAPnjgZ12X0JdvKPY7Ggkq84On83FK2Z3FLOwFXA55+=99Dh=Hg@mail.gmail.com>
Hello Simon,
On Sun, 31 Jan 2016 19:20:31 -0700, Simon Glass <sjg@chromium.org>
wrote:
> Hi Bin,
>
> At present U-Boot supports booting a 64-bit kernel directly. It can
> also be loaded as a 64-bit payload from EFI. But it cannot be built as
> a 64-bit boot loader.
>
> I took a bit of a look at this. It looks like we need to stay in
> 32-bit mode until the FSP is loaded. Also, to get to 64-bit mode I'm
> pretty sure we need page tables, which means we need somewhere to put
> them!
>
> Looking at the board_f init sequence, it seems that arch_cpu_init() is
> the earlist we could switch to 64-bit. We'd need to grab some memory
> from somewhere to do this - I wonder if this can be CAR? There is no
> SRAM on x86 chips I think.
>
> For non-FSP devices we don't init the RAM until much later -
> dram_init(). That means that a significant portion of the init
> sequence would be 32-bit code. I'm not sure that will work.
>
> I suppose one option is to only go to 64-bit mode when relocating. But
> then we end up with lots of code that needs to run in 32-bit and
> 64-bit.
>
> Do you have any ideas on this?
How about starting with implementing the last option, i.e. switch to 64
bits when DDR is available, mainline that, then progressively work your
way toward an earlier switch?
> Regards,
> Simon
Amicalement,
--
Albert.
next prev parent reply other threads:[~2016-02-01 7:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-01 2:20 [U-Boot] 64-bit x86 U-Boot? Simon Glass
2016-02-01 7:14 ` Albert ARIBAUD [this message]
2016-02-02 3:58 ` Simon Glass
2016-02-02 7:25 ` Bin Meng
2016-02-02 9:53 ` Albert ARIBAUD
2016-02-02 15:02 ` Bin Meng
2016-02-03 4:31 ` Simon Glass
2016-02-03 4:42 ` Bin Meng
2016-02-04 17:41 ` Tom Rini
2016-02-05 5:41 ` Bin Meng
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=20160201081446.378e1f5b@lilith \
--to=albert.u.boot@aribaud.net \
--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