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] u-boot-x86
Date: Wed, 25 Aug 2010 21:16:47 +1000	[thread overview]
Message-ID: <4C74FB9F.10807@gmail.com> (raw)
In-Reply-To: <AANLkTinh8372fgDaiukRz-+CBS5jYfSNTjvdbK9gR8Xj@mail.gmail.com>

Hi Sk,

Please keep the Cc list intact (specifically U-Boot Users). Although some
of these questions are a little off-topic for the list, there is much
confusion about U-Boot as an embedded boot loader, CoreBoot as a BIOS
replacement which can boot the Linux kernel directly and x86 'Bootloaders'
such as LILO, GRUB etc. Having this information in the mailing list archive
is important

On 25/08/10 17:58, sk ong wrote:
> Graeme,
>  
> Thanks for your response.
>  
> I have not accessed gmail for few days, so I see this late, I will take
> some time to digest and look at coreboot too.
>  
> I do not fully understand, can I ask some questions?

Sure - Questions are always welcome :)

>  
> Board designer of embedded board knows the information, instead of BIOS,
> how does u-boot pass this information to protected-mode entry of linux
> kernel?

The x86 Linux Kernel has two components, a 'Real-Mode' component (which has
access to BIOS but very limited access to memory and devices) and a
'Protected-Mode' component (with no access to BIOS but full access to
memory and devices).

The 'Real-Mode' component of the Linux Kernel 'probes' BIOS (via BIOS
interrupt calls) to build a list of fundamental information (primarily
memory layout) in memory and invokes the 'Protected Mode' component passing
a memory address of the information collected (from BIOS) in Real-Mode

My intent is for U-Boot to replace the 'Real-Mode' component of Linux and
build the necessary information and directly invoke the 'Protected Mode'
component of the Linux Kernel (bypassing Real-Mode entirely). Because an
embedded board designer designs all part of the system (RAM, ROM, device
memory and interrupt maps etc), they can build this information without
needing BIOS.

>  
> Does uboot execute option rom, such as the option rom for PCI/PCIE video
> controller, SATA controller, network controller, etc.?

No (although you could write drivers to do so). I think U-Boot may already
have drivers for common hardware already. Because of the GPL, any device
supported by Linux can be ported to U-Boot be taking the existing Linux
driver code (does need to be modified specifically for U-Boot, but all the
hard work has already been done)

>  
> What are the x86 CPU and board that can run uboot-x86?

Currently U-Boot supports the AMD SC520 'Elan' embedded processor. I am
about to port U-Boot to the VIA EPIA EN1200/1500 boards

>  
> Is there a porting guide if I want to port uboot-x86 to another x86 board?
>  

Unfortunately not

> Can uboot-x86 boot x86 PC Linux like Fedora, Ubuntu, etc.?

U-Boot cannot boot a PC. The VIA EPIA platform is marketed as 'Embedded'
but it is (kind-of) a PC motherboard. PC's are very diverse - BIOS is
intended to create an abstraction between the software and the hardware to
some extent. To boot a PC, U-Boot would need to replace the BIOS and all
the abstraction that entails which would, essentially, mimic coreboot (i.e.
implementing such 'genericness' would be a complete waste of time)

> 
> If uboot-x86 can boot x86 PC Linux, what stop it from booting Windows
> (at least non-ACPI kernel WIndows)?

U-Boot can boot other OS's. I think some have even booted Windows CE (the
embedded version of windows)

>  
> Without in13h in uboot-x86, how MBR/grub/lilo load Linux image from
> storage such as SATA, SD, etc?

Most embedded systems use Flash memory to store the filesystem. U-Boot has
drivers to access file systems on MTD (Flash) devices. U-Boot also has a
wide variety of driver to provide access to various storage devices (as
well as network adapters, Serial ports, USB, video, PCMCIA etc)

>  
> I am looking for uboot, not only for x86 PC, but also for other x86
> embedded OS.

If you are booting a generic, off-the-shelf PC motherboard (Gigabyte, Tyan,
Asus etc) then look at coreboot. If you are creating your own hardware
design, use U-Boot

>  
> Thanks,
> SK
>  
>  
> On Sat, Aug 21, 2010 at 9:42 AM, Graeme Russ <graeme.russ@gmail.com
> <mailto:graeme.russ@gmail.com>> wrote:
> 
>     Hi SK,
> 
>     On 20/08/10 17:42, sk ong wrote:
>     > Hi,
>     >
>     > I notice there is u-boot for x86 architecture in the denx site. I
>     wonder
>     > whether the u-boot-x86 has the legacy BIOS services, such as
>     dispatching
>     > PCI/PCIE device option rom such as video, SATA, etc. Does it have
>     int13,
>     > int15 etc. services for x86 Linux to call during booting phase.
> 
>     The x86 port has an (extremely) limited BIOS primarily to provide
>     INT12 and
>     INT15 for the purpose of determining memory size during the Linux
>     Real-Mode
>     startup procedure.
> 
>     I don't think that Linux actually needs BIOS other than during the
>     initial
>     Real-Mode bootstrap. In an embedded environment, the board designer
>     knows
>     all the information the BIOS would otherwise provide. My goal is to
>     remove
>     the BIOS functionality from U-Boot and use the Protected-Mode entry
>     point
>     of the Linux kernel and avoid the switching back-and-forth between
>     Real and
>     Protected Modes
> 
>     It sounds like you might be looking at using U-Boot for booting a
>     x86 PC.
>     If this is the case, maybe you should take a look at coreboot
>     (http://www.coreboot.org/)
> 
>     Regards,
> 
>     Graeme
> 
> 

  parent reply	other threads:[~2010-08-25 11:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-20  7:42 [U-Boot] u-boot-x86 sk ong
2010-08-21  1:42 ` Graeme Russ
2010-08-22 19:21   ` Robert Schwebel
     [not found]   ` <AANLkTinh8372fgDaiukRz-+CBS5jYfSNTjvdbK9gR8Xj@mail.gmail.com>
2010-08-25 11:16     ` Graeme Russ [this message]
2010-08-25 13:49       ` sk ong
2010-08-25 14:49         ` Graeme Russ
2010-08-25 15:40           ` sk ong
2010-08-27 10:07           ` Detlev Zundel

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=4C74FB9F.10807@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