From: "Huang, Ying" <ying.huang@intel.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andi Kleen <ak@suse.de>,
"Eric W. Biederman" <ebiederm@xmission.com>,
akpm@linux-foundation.org, Yinghai Lu <yhlu.kernel@gmail.com>,
Chandramouli Narayanan <mouli@linux.intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC -mm 2/2] i386/x86_64 boot: document for 32 bit boot protocol
Date: Tue, 18 Sep 2007 09:13:23 +0800 [thread overview]
Message-ID: <1190078003.12429.8.camel@caritas-dev.intel.com> (raw)
In-Reply-To: <46EE9D66.1030705@zytor.com>
On Mon, 2007-09-17 at 08:29 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> > This patch defines a 32-bit boot protocol and adds corresponding
> > document.
> > +
> > +In addition to read/modify/write kernel header of the zero page as
> > +that of 16-bit boot protocol, the boot loader should fill the
> > +following additional fields of the zero page too.
> > +
> > +Offset Type Description
> > +------ ---- -----------
> > + 0 32 bytes struct screen_info, SCREEN_INFO
> > + ATTENTION, overlaps the following !!!
> > + 2 unsigned short EXT_MEM_K, extended memory size in Kb (from int 0x15)
> > + 0x20 unsigned short CL_MAGIC, commandline magic number (=0xA33F)
> > + 0x22 unsigned short CL_OFFSET, commandline offset
> > + Address of commandline is calculated:
> > + 0x90000 + contents of CL_OFFSET
> > + (only taken, when CL_MAGIC = 0xA33F)
> > + 0x40 20 bytes struct apm_bios_info, APM_BIOS_INFO
> > + 0x60 16 bytes Intel SpeedStep (IST) BIOS support information
> > + 0x80 16 bytes hd0-disk-parameter from intvector 0x41
> > + 0x90 16 bytes hd1-disk-parameter from intvector 0x46
> > +
> > + 0xa0 16 bytes System description table truncated to 16 bytes.
> > + ( struct sys_desc_table_struct )
> > + 0xb0 - 0x13f Free. Add more parameters here if you really need them.
> > + 0x140- 0x1be EDID_INFO Video mode setup
> > +
> > +0x1c4 unsigned long EFI system table pointer
> > +0x1c8 unsigned long EFI memory descriptor size
> > +0x1cc unsigned long EFI memory descriptor version
> > +0x1d0 unsigned long EFI memory descriptor map pointer
> > +0x1d4 unsigned long EFI memory descriptor map size
> > +0x1e0 unsigned long ALT_MEM_K, alternative mem check, in Kb
> > +0x1e4 unsigned long Scratch field for the kernel setup code
> > +0x1e8 char number of entries in E820MAP (below)
> > +0x1e9 unsigned char number of entries in EDDBUF (below)
> > +0x1ea unsigned char number of entries in EDD_MBR_SIG_BUFFER (below)
> > +0x290 - 0x2cf EDD_MBR_SIG_BUFFER (edd.S)
> > +0x2d0 - 0xd00 E820MAP
> > +0xd00 - 0xeff EDDBUF (edd.S) for disk signature read sector
> > +0xd00 - 0xeeb EDDBUF (edd.S) for edd data
> > +
> > +After loading and setuping the zero page, the boot loader can load the
> > +32/64-bit kernel in the same way as that of 16-bit boot protocol.
> > +
> > +In 32-bit boot protocol, the kernel is started by jumping to the
> > +32-bit kernel entry point, which is the start address of loaded
> > +32/64-bit kernel.
> > +
> > +At entry, the CPU must be in 32-bit protected mode with paging
> > +disabled; the CS and DS must be 4G flat segments; %esi holds the base
> > +address of the "zero page"; %esp, %ebp, %edi should be zero.
>
> This is just replicating the "zero-page.txt" document, which can best be
> described as a "total lie" -- compare with the actual structure.
OK, I will check the actual structure, and change the document
accordingly.
Best Regards,
Huang Ying
next prev parent reply other threads:[~2007-09-18 1:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-17 8:26 [RFC -mm 2/2] i386/x86_64 boot: document for 32 bit boot protocol Huang, Ying
2007-09-17 15:29 ` H. Peter Anvin
2007-09-18 1:13 ` Huang, Ying [this message]
2007-09-18 1:48 ` H. Peter Anvin
2007-09-18 2:56 ` Huang, Ying
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=1190078003.12429.8.camel@caritas-dev.intel.com \
--to=ying.huang@intel.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mouli@linux.intel.com \
--cc=yhlu.kernel@gmail.com \
/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.