sorry to top-post. only way.
"I do not think that you have to pay to CALL the UEFI BIOS...
This is probably for those who WRITE UEFI certified BIOSes?
Or to get some official docs?"
I think the docs are free and are freely available from the
http://www.uefi.org/specs/
the adopter agreement is at http://www.uefi.org/join/
maybe I am over-reacting. I don't know. all the mb mfr's I like to visit
(asrock, msi, asus) still call their firmware a BIOS - I don't know if that's
for user's familiarity, or whether it really is a BIOS.
maybe the requirements for UEFI are staved off for a while yet, but I don't
know
for how long.
books available at http://www.intel.com/intelpress/sum_eshl.htm
________________________________
From: Eric Auer <e.a...@jpberlin.de>
To: Jim Michaels <jmich...@yahoo.com>; freedos-devel@lists.sourceforge.net
Sent: Wed, December 22, 2010 12:56:07 AM
Subject: Re: [Freedos-devel] UEFI+GPT has/is replaced/replacing BIOS?
Hi Jim,
> some BIOSes have already been replaced with UEFI. AMI has been using it for
> years, and now it is the only kind of "BIOS" supported in their diags suite.
> ack! I wanted to have that suite someday for testing systems...
>
> http://www.ami.com/products/product.cfm?CatID=3&SubID=23&ProdID=147
>
> some manufacturers may still use legacy BIOS possibly, but it looks like
things
> are definitely moving towards UEFI+GPT.
>
> for the DOS folk, this is maybe a wake-up call to start implementing
> additional partitioning schemes? (by the way, the last version of fdisk I
used
> is broken, it started creating empty partitions)
Which version is this?
> I still have some utilities that are written in DOS+BIOS calls. so I am not
> sure what to do next. I don't have $2500 lying about to implement UEFI API
> calls (or is it $2500 to implement UEFI rather than call the Interface?).
>What
> think ye?
>
> someone (me?) probably needs to contact UEFI and ask them if calling the API
> requires a $2500 fee or not, and whether or not a .c/.cpp+.h source files are
> available for the Interface.
I do not think that you have to pay to CALL the UEFI BIOS...
This is probably for those who WRITE UEFI certified BIOSes?
Or to get some official docs?
> GPT allows up to 128 partitions on a disk, whereas MBR only allows 4. BIOS
>has
> a limited number of functions, whereas UEFI can have its functionality
>expanded
> by placing it partially on a disk using a certain type of filesystem such as
> FAT32.
MBR allows a chain of infinitely many logical partitions.
It is just that the MBR allows only 4 primary partitions.
> there is a backup copy of the partition table in GPT in case of something
> catastrophic.
>
> The Mac also uses UEFI+GPT.
Well, here are some notes about BASIC GPT / EFI partitioning:
Luckily EFI does not seem to be complicated - EFI partitions
ignore all CHS values and have a partition ID of 0xef, and
classic partitions can coexist with them...
Header, padded to suitable power of 2 size:
qword 0x5452415020494645 / EFI PART
dword 0x00010000 version
dword header size
dword header crc32
dword 0
qword lba address of THIS sector
qword lba address of alternate header(?)
qword first data block of partition?
qword last data block of partition?
16 bytes GUID to uniquely identify disk
qword lba address of GUID partition entry array
dword array size
dword array crc32
padding
Partition entry, 128 bytes each:
16 bytes partition type (0 if unused)
16 bytes GUID to very uniquely identify partition
qword lba address of partition start
qword lba address of partition end
qword attribute bits (only low bit required?)
(high word reserved, middle 47 bits undefined?)
72 bytes UTF-8 (correct?) partition name string
A DOS kernel could easily implement this.
Regards, Eric
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
