Is MOVDQA possible in real mode (16 bit)?
Bernhard Schornak
I'm writing a boot manager at the moment. It resides in the first
cylinder of the first HD and is
plain 16 bit code. It reads the partition tables (including extended
partitions) of HDs reported
by the BIOS, evaluates their boot sectors and offers a list of all
bootable partitions to start. It
has to store *some* data, so I want to use XMM registers to move
gathered drive parameters
to a table. This table includes the standard partition tables as well
as 'exotic' drive information
like IBM's LVM (stored in the last sector of cylinders containing an
MBR or EBR). I use one
32.768 byte memory block for reading 63 sectors in one gulp, evaluate
them and copy usable
info in a second memory block - there are > 600 k of free memory to
waste. ;)
Now the big question: Is it possible to use XMM registers (I want to
use MOVDQA) in real
mode? The AMD manual has some possible errors listed for real mode, so
it should. Ok, I
cannot cross segment boundaries and such, but I neither found anything
about segment
register(s) I can (or have to) use for addressing nor any related
information. Perhaps,
someone is willing to enlighten me?
Greetings from Augsburg
Bernhard Schornak
James Harris
On 24 Dec, 16:38, Bernhard Schornak
<schor...@MUNGED.microcosmotalk.com> wrote:
> I'm writing a boot manager at the moment. It resides in the first
> cylinder of the first HD and is
> plain 16 bit code. It reads the partition tables (including extended
> partitions) of HDs reported
> by the BIOS, evaluates their boot sectors and offers a list of all
> bootable partitions to start.
Interesting. I have thought about something similar. Some of my
comments are from that perspective - but I will get back to the XMM
issue.
Partition ids may be confusing to the user. How would you name them in
the menu? Whatever the name they could perhaps be sorted by last use.
This would need some storage of state between boots so is not
straightforward.
Also ideally the boot manager would fit in the MBR. Then there's no
issues of how much of the first cylinder is available or in use. The
second sector could perhaps be used to store the date and time of last
boot. The same code in each disk's MBR would allow the same system
behaviour regardless of which disk got booted by the BIOS.
> It
> has to store *some* data, so I want to use XMM registers to move
> gathered drive parameters
> to a table. This table includes the standard partition tables as well
> as 'exotic' drive information
> like IBM's LVM (stored in the last sector of cylinders containing an
> MBR or EBR). I use one
> 32.768 byte memory block for reading 63 sectors in one gulp, evaluate
> them and copy usable
> info in a second memory block - there are > 600 k of free memory to
> waste. ;)
I'd keep the MBR boot code relatively simple: moving itself and then
loading the partition boot sector to 0x7c00. Does it need to do all
you mention? If necessary it could provide a table of subroutines that
the partition boot sector can call to get other data.
If you don't provide callable routines could you instead provide a
small table of data at a fixed location such as 0x8000 rather than
passing the data in XMM registers?
>
> Now the big question: Is it possible to use XMM registers (I want to
> use MOVDQA) in real
> mode? The AMD manual has some possible errors listed for real mode, so
> it should. Ok, I
> cannot cross segment boundaries and such, but I neither found anything
> about segment
> register(s) I can (or have to) use for addressing nor any related
> information. Perhaps,
> someone is willing to enlighten me?
To my surprise movdqa does seem to be permitted in real mode. However
if you use it your code won't work on anything prior to a certain CPU
generation - apparently a Pentium 4 or Pentium M.
For the addressing why not just try and see what your assembler will
accept?
James
P.S. Can you do something about your posting line length? It seems to
wrap far too late.
P.P.S. Have added alt.os.development.
Bernhard Schornak
James Harris wrote:
>
> > I'm writing a boot manager at the moment. It resides in the first
> > cylinder of the first HD and is plain 16 bit code. It reads the
> > partition tables (including extended partitions) of HDs reported
> > by the BIOS, evaluates their boot sectors and offers a list of all
> > bootable partitions to start.
>
> Interesting. I have thought about something similar. Some of my
> comments are from that perspective - but I will get back to the XMM
> issue.
>
> Partition ids may be confusing to the user. How would you name them in
> the menu? Whatever the name they could perhaps be sorted by last use.
> This would need some storage of state between boots so is not
> straightforward.
>
> Also ideally the boot manager would fit in the MBR. Then there's no
> issues of how much of the first cylinder is available or in use. The
> second sector could perhaps be used to store the date and time of last
> boot. The same code in each disk's MBR would allow the same system
> behaviour regardless of which disk got booted by the BIOS.
>
Well, IBOOT (the IDEOS boot manager) is thought to load *any* OS found
on *any* drive supported by the BIOS. Such a thing never fits into the
MBR nor into three or four sectors. The pseudo-graphical character set
alone eats up one or two sectors. Actually, IBOOT is the first code
for IDEOS (Intelligent Design Easy2use Operating System). 'Easy2use'
is the most important issue this boot manager has to support. Rather
than using fixed ini-files or scripts, it finds all bootable
partitions at boot time and offers a list of OS's to start. The user
can select any of these choices, set a boot timer, define a default OS
to start or get a short help page describing IBOOT's features. IBOOT
uses LBA addressing, allowing to boot from cylinders > 1,023, as well.
> > It has to store *some* data, so I want to use XMM registers to move
> > gathered drive parameters to a table. This table includes the
> > standard partition tables as well as 'exotic' drive information
> > like IBM's LVM (stored in the last sector of cylinders containing an
> > MBR or EBR). I use one 32.768 byte memory block for reading 63
> > sectors in one gulp, evaluate them and copy usable info in a second
> > memory block - there are > 600 k of free memory to waste. ;)
>
> I'd keep the MBR boot code relatively simple: moving itself and then
> loading the partition boot sector to 0x7c00. Does it need to do all
> you mention? If necessary it could provide a table of subroutines that
> the partition boot sector can call to get other data.
>
> If you don't provide callable routines could you instead provide a
> small table of data at a fixed location such as 0x8000 rather than
> passing the data in XMM registers?
>
Probably not. IBOOT creates an IDEOS partition table residing in
cylinders 02...09 on each drive. It holds drive data and partition
parameters of up to 31 possible partitions. IDEOS uses 128 bit LBA,
suitable for some future generations of harddisks. Each entry in the
table holds the start LBA and size of this partition, system
parameters and a drive/volume name with up to 15 characters. When an
IBM LVM is found, the names are copied to the corresponding entries in
IDEOS' partition table. IBOOT sits between the partition table and the
LVM sector, leaving 53 sectors for code and data. That's sufficient
for huge help texts. While gathering partitions, the raw MBR/EBR chain
is copied via MOVDQU => MOVDQA (partition tables are unaligned per
definition). After all drives are through, raw data are evaluated and
stored in the IDEOS partition table. Using these, the boot sectors of
all partitions are loaded and evaluated for bootable content. If they
match with several criteria, the partition is added to the list of
bootable volumes.
> > Now the big question: Is it possible to use XMM registers (I want to
> > use MOVDQA) in real mode? The AMD manual has some possible errors
> > listed for real mode, so it should. Ok, I cannot cross segment
> > boundaries and such, but I neither found anything about segment
> > register(s) I can (or have to) use for addressing nor any related
> > information. Perhaps, someone is willing to enlighten me?
>
> To my surprise movdqa does seem to be permitted in real mode. However
> if you use it your code won't work on anything prior to a certain CPU
> generation - apparently a Pentium 4 or Pentium M.
>
> For the addressing why not just try and see what your assembler will
> accept?
Got me... I will toy around with some sample code. Unfortunately, I
cannot test raw binaries starting at offset 0 on any OS. Either this
baby runs at once, or it will be a mess to debug it. Perhaps I try to
do some beginner's Windoze stuff - I still use eCS (formerly known as
OS/2) as my main platform. Windoze is booted for games and Linux for
frustration... ;) At the moment I try to figure out how to write code
with fasm - far away from my good old AS. Masm C-style syntax sucks as
well as LETNi's arabic back to forth style (they're all terrorists, I
bet ;).
> P.S. Can you do something about your posting line length? It seems to
> wrap far too late.
I hope I got this right, now. I'm posting via GoogleGroups at the
moment - worlds away from the sophisticated SeaMonkey news client.
Actually, I used less than 80 lines per row (hard CRLF's). Seems
Gooogle's HTML generator 'optimised' them. Trying with endless lines
now, so the generator should be happy with it.
> P.P.S. Have added alt.os.development.
Thank you. Aren't they bored enough? (BIG grin... ;)
Bernhard Schornak
On 24 Dez., 20:26, James Harris wrote:
> > It reads the partition tables (including extended
> > partitions) of HDs reported by the BIOS, evaluates
> > their boot sectors and offers a list of all bootable
> > partitions to start.
>
> Interesting. I have thought about something similar. Some of my
> comments are from that perspective - but I will get back to the XMM
> issue.
>
> Partition ids may be confusing to the user. How would you name them in
> the menu? Whatever the name they could perhaps be sorted by last use.
> This would need some storage of state between boots so is not
> straightforward.
No ID's, because ecCS (formerly OS/2) HPFS, Windoze NTFS and some
other IFS (installable filesystems) use 0x07 as 'unique' identifier.
My code evaluates the boot sector of each found partition to determine
if there is a boot loader or if we found just another partition
containing user data. Using LBA addressing, it is capable to find (and
start) bootable partitions beyond cylinder 1,023, as well. The
evaluated data are passed to the user in a pseudo-graphical interface
with buttons showing e.g. "drive: 00 Volume: 01 Linux", and so on.
> Also ideally the boot manager would fit in the MBR. Then there's no
> issues of how much of the first cylinder is available or in use. The
> second sector could perhaps be used to store the date and time of last
> boot. The same code in each disk's MBR would allow the same system
> behaviour regardless of which disk got booted by the BIOS.
It doesn't. I do it like LILO or GRUB, using the first cylinder (minus
one for IBM's LVM). Because this is thought to be the boot loader for
IDEOS (Intelligent Design Easy Operating System), it creates IDEOS
partition tables on all drives. These occupy 8 sectors for 32 entries.
The first entry describes the entire drive, leaving room for up to 31
partitions. IDEOS uses 128 bit LBA addressing by default, so it
probably will take a while until hardware reaches these limit. Each
partition table entry defines the start and end of this partition
(LBA), the status and some other info and a drive/volume name with up
to 31 characters. All in all, the code (plus text) has to fit into 53
sectors = 27136 byte. That's sufficient to include a lot of text... ;)
> > It has to store *some* data, so I want to use XMM registers to move
> > gathered drive parameters to a table. This table includes the
> > standard partition tables as well as 'exotic' drive information
> > like IBM's LVM (stored in the last sector of cylinders containing
> > an MBR or EBR). I use one 32.768 byte memory block for reading 63
> > sectors in one gulp, evaluate them and copy usable info in a second
> > memory block - there are > 600 k of free memory to waste. ;)
>
> I'd keep the MBR boot code relatively simple: moving itself and then
> loading the partition boot sector to 0x7c00. Does it need to do all
> you mention? If necessary it could provide a table of subroutines that
> the partition boot sector can call to get other data.
>
> If you don't provide callable routines could you instead provide a
> small table of data at a fixed location such as 0x8000 rather than
> passing the data in XMM registers?
Sorry, it is not a boot 'loader', but a boot 'manager'. In concurrence
to all boot managers I've seen until now, IBOOT is 'intelligent' and
looks for bootable OS's at boot time, then offers them in a pseudo-
graphical interface with several control options 'on board'. You can
define a timer as well as a default OS to start. When the timer
crosses zero, the default OS is started automatically. Compared
against other boot managers, only the old OS/2 boot manager can
compete with this. Its con is that it occupies the first partition,
eating 7 MB of the drive's capacity, while IBOOT doesn't need its own
partition.
The boot loader itself is just a 179 byte fragment in the MBR, calling
INT13 two times. First it tests if LBA addressing is supported, then
it loads sectors 0a...3E to 3000:0000. The error messages occupy about
80 of those 179 byte...
> > Now the big question: Is it possible to use XMM registers (I want to
> > use MOVDQA) in real mode? The AMD manual has some possible errors
> > listed for real mode, so it should. Ok, I cannot cross segment
> > boundaries and such, but I neither found anything about segment
> > register(s) I can (or have to) use for addressing nor any related
> > information. Perhaps, someone is willing to enlighten me?
>
> To my surprise movdqa does seem to be permitted in real mode. However
> if you use it your code won't work on anything prior to a certain CPU
> generation - apparently a Pentium 4 or Pentium M.
>
> For the addressing why not just try and see what your assembler will
> accept?
>
> James
You're right. I will toy around with sample code for a while. IDEOS is
an AMD64 OS, it should run on recent machines, only. Intelligent
Design
unleashes the real powers of AMD's three execution pipes by providing
push and pop free code, avoiding dependencies (if possible) hindering
parallel execution in all three pipes, and a lot of other optimising
techniques.
>
> P.S. Can you do something about your posting line length? It seems to
> wrap far too late.
Sorry for that. I'm using GoogleGroups at the moment and I'm not too
familiar with it. Poor thing is that you cannot see a preview of the
real output before you send the post. I probably made the mistake to
use hard line breaks instead of letting Google's engine do the
formatting. Should be better now? (SeaMonkey's plain text interface is
superior to html!)
> P.P.S. Have added alt.os.development.
Thank you. Maybe anyone is interested in the 21st centuries OS? (Very
big grin... ;)
Bernhard Schornak
Bernhard Schornak wrote:
<snip>
Sorry for the double post. I thought Google swallowed my
first post, so I wrote a second reply.
wolfgang kern
Bernhard Schornak asked:
My answer is Yes,
> I'm writing a boot manager at the moment. It resides in the first
> cylinder of the first HD and is
> plain 16 bit code. It reads the partition tables (including extended
> partitions) of HDs reported
> by the BIOS, evaluates their boot sectors and offers a list of all
> bootable partitions to start. It
> has to store *some* data, so I want to use XMM registers to move
> gathered drive parameters
> to a table. This table includes the standard partition tables as well
> as 'exotic' drive information
> like IBM's LVM (stored in the last sector of cylinders containing an
> MBR or EBR). I use one
> 32.768 byte memory block for reading 63 sectors in one gulp, evaluate
> them and copy usable
> info in a second memory block - there are > 600 k of free memory to
> waste. ;)
> Now the big question: Is it possible to use XMM registers (I want to
> use MOVDQA) in real mode?
Yes, as long XMM is enabled and memory wont cross segment borders.
> The AMD manual has some possible errors listed for real mode, so
> it should. Ok, I
> cannot cross segment boundaries and such, but I neither found anything
> about segment register(s) I can (or have to) use for addressing
> nor any related information. Perhaps, someone is willing to enlighten me?
Realmode segments are limited to 64 K, due to 16 bit of course :)
The value in segment-registers is shifted left by 4 bits and added
to the offset, ie:
CS:IP = 7c00:0000...FFFF mean a code range from 0007_C000..0008_BFFF.
Same for DS,ES,FS,GS data-segments and also the SS stack-segment.
The default segment for XMM<->Mem is DS, but Seg-override will work too.
> Greetings from Augsburg
> Bernhard Schornak
Welcome back!
It's been a while we heared from you, hope you did well.
Still riding your truck all over the continent ?
btw: merry X-days!
__
wolfgang
Bernhard Schornak
wolfgang kern wrote:
>> The AMD manual has some possible errors listed for real mode, so
>> it should. Ok, I cannot cross segment boundaries and such, but I
>> neither found anything about segment register(s) I can (or have
>> to) use for addressing nor any related information. Perhaps,
>> someone is willing to enlighten me?
>
> Realmode segments are limited to 64 K, due to 16 bit of course :)
> The value in segment-registers is shifted left by 4 bits and added
> to the offset, ie:
>
> CS:IP = 7c00:0000...FFFF mean a code range from 0007_C000..0008_BFFF.
> Same for DS,ES,FS,GS data-segments and also the SS stack-segment.
Yes. Using it properly, we can access any address below 1MB,
even if our code resides in a simple .com file. Toyed around
with this stuff before I changed to OS/2. We can do a lot of
funny things when segment registers are used the right way.
> The default segment for XMM<->Mem is DS, but Seg-override will work too.
Thanks a lot - that's exactly what I wanted to know. I think
I know AMD's manuals by heart, but I didn't find this infor-
mation anywhere.
> Welcome back!
> It's been a while we heared from you, hope you did well.
> Still riding your truck all over the continent ?
Hello Wolfgang!
I was offline for some years, no chance to get access to the
internet. Got an USB stick lately. Yeehaa! No big traffic at
the moment, I'm unemployed for some years now (that's why my
internet provider decided to switch my DSL line off).
> btw: merry X-days!
Merry winter solstice and a happy new year!
Bernhard Schornak
J de Boyne Pollard
JH> Also ideally the boot manager would fit in the MBR. Then
JH> there's no issues of how much of the first cylinder is
JH> available or in use. The second sector could perhaps be
JH> used to store the date and time of last boot.
It's been a bad idea for some considerable time now to make boot
managers operate in the same way as MBR viruses operate. This is not
least because it makes them fall foul of the measures that people take
to combat MBR viruses. It's also the case that code has no business
assuming that it can just use, willy-nilly, the second and subsequent
sectors of the disc. This is the 21st century. Partitioning doesn't
necessarily *have* unallocated space holes that one can drop the code
for a boot manager, or for a computer virus, into. Indeed, it's a
real possibility nowadays that the second sector is *where the
partition table is*. The correct way to go about things has been, for
some time now, to properly allocate space for a boot manager and
properly record that allocation in the partition table, so that there
are no more of the "Editing my partition table overwrote my boot
manager and now my system is unbootable!" problems that so many people
have experienced over decades past. GRUB is now finally capable of
doing this, as of quite recently. IBM's BootManager did it from the
get-go.
JH> Partition ids may be confusing to the user. How would you
JH> name them in the menu?
A convention for giving display names to partitions in the MBR
partitioning scheme has been around since the early 1990s. IBM's
BootManager was where it originated. Essentially, each MBR gains an
additional table, extending the traditional partition table with an
additional flag byte and an 8-character name field. (Of course, the
partition table in the EFI partitioning scheme contained a name field
in each partition table entry right from the start, without requiring
that names be bolted on as an afterthought.) These are the partition
names displayed by DFSEE's PART command, for example (and by my
PARTLIST and DASDPART utilities, and of course by IBM's FDISK, and by
IBM's BootManager and its derivatives).
J de Boyne Pollard
BS> Its con is that it occupies the first partition, eating 7 MB of
the
BS> drive's capacity, while IBOOT doesn't need its own partition.
As explained, that's actually a point in favour of the former, since
it prevents the damage that you'll find your approach subject to, as
many before you have done. It's the 21st century. We don't write
boot managers like MBR viruses any more. (-:
BS> I do it like LILO or GRUB, [...]
As mentioned, GRUB is now, finally, capable of using a proper
partition to reserve space for its second-stage portions, as IBM's
BootManager does.
BS> [...] it creates IDEOS partition tables on all drives. These
BS> occupy 8 sectors for 32 entries. [...]
Don't reinvent the wheel. If you want an improved partition table
mechanism, use the EFI one. Not only has it already been invented,
but you'll find that there already exist other people's tools that can
interoperate with it, which of course won't be the case with a roll-
one's-own partition table mechanism. If you want to auto-convert from
the MBR scheme to some other scheme, convert to the EFI scheme. Note
that you don't need to write to the disc at all in order to use an
enhanced partition table layout *in memory*, in a boot manager.
Maxim S. Shatskih
> Don't reinvent the wheel. If you want an improved partition table
> mechanism, use the EFI one.
aka GUID partition table (GPT). IIRC it is publicly documented.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
Bernhard Schornak
J de Boyne Pollard wrote:
> BS> I do it like LILO or GRUB, [...]
>
> As mentioned, GRUB is now, finally, capable of using a proper
> partition to reserve space for its second-stage portions, as IBM's
> BootManager does.
My GRUB from the latest DEBIAN distribution does use the
scheme I mentioned in my posting. Actually, I have -not-
seen -any- bootmanager (except IBM's) working in another
way. Okay, I work with OS/2 since 1993 and had no reason
to use another bootmanager. I tested some LILOs and GRUB
on the fly, just to have a look at how they work. Forget
about GRUB - it's malware...
> BS> [...] it creates IDEOS partition tables on all drives. These
> BS> occupy 8 sectors for 32 entries. [...]
>
> Don't reinvent the wheel. If you want an improved partition table
> mechanism, use the EFI one. Not only has it already been invented,
> but you'll find that there already exist other people's tools that can
> interoperate with it, which of course won't be the case with a roll-
> one's-own partition table mechanism. If you want to auto-convert from
> the MBR scheme to some other scheme, convert to the EFI scheme. Note
> that you don't need to write to the disc at all in order to use an
> enhanced partition table layout *in memory*, in a boot manager.
I do not support proprietary systems. As I have to get a
license before I am allowed to view any EFI documents, I
don't think it is an alternative. Are there any free do-
cuments regarding definitions you mention in your post?
Does it support 128 bit LBAs? Something fit for the 21st
century should be prepared for rapid growth of mass sto-
rage. My concept keeps pace... ;)
AMD is not mentioned on the EFI homepage. My code is op-
timised for AMD64 and runs best on AMD machines - no AMD
board supports EFI.
J de Boyne Pollard
JdeBP> As mentioned, GRUB is now, finally, capable of using a
JdeBP> proper partition to reserve space for its second-stage
JdeBP> portions, as IBM's BootManager does.
BS> My GRUB from the latest DEBIAN distribution does use
BS> the scheme I mentioned in my posting. Actually, I have
BS> -not- seen -any- bootmanager (except IBM's) working in
BS> another way. [...] Forget about GRUB - it's malware...
Then either you haven't looked too closely at the GRUB documentation,
or your GRUB is an older version. Read the GRUB documentation for
what it calls the "BIOS Boot partition".
JdeBP> Don't reinvent the wheel. If you want an improved
JdeBP> partition table mechanism, use the EFI one. [...]
BS> I do not support proprietary systems.
Yes, you do, else you wouldn't be supporting the MBR partitioning
scheme either. I suspect that that is not your real reason but post-
hoc justification, given the error that you then proceeded to state:
BS> As I have to get a license before I am allowed to view
BS> any EFI documents, I don't think it is an alternative.
One doesn't have to get licences for anything. There's freely
available documentation of the EFI partitioning scheme available from
many places, from the official specification to articles on Apple
Developer Connection and Microsoft TechNet. As M. Shatskih said, it's
publicly documented. One could probably even work out how it works
just from the source code for the GPT fdisk (<URL:http://
rodsbooks.com./gdisk/>), without looking at any of that public
documentation. (I've not tried, myself, though. I just read the
specification.)
BS> AMD is not mentioned on the EFI homepage.
BS> My code is optimised for AMD64 and runs
BS> best on AMD machines
BS> no AMD board supports EFI.
Those are irrelevant. We are talking about a disc partitioning
scheme, not processor instruction sets. Mainboard support is
irrelevant, too. After all, if it *were* relevant, you'd have the
same issue, that no mainboard supports it, with your roll-your-own
partitioning scheme, since no mainboards support that, either. Yet
you aren't complaining that no mainboard supports your roll-your-own
partitioning scheme. The irony is that disk partitioning schemes are
largely irrelevant to mainboards, which don't have to know anything
about disc partitions for x86-style load-and-run-the-MBR
bootstrapping. Those mainboard firmwares that *do* understand and
deal in disc partitioning schemes *use EFI firmwares* and understand
the EFI partitioning scheme just fine. So where it actually is
relevant in the first place, one finds that the mainboards have the
support. (-:
As above, it appears that you are looking for post-hoc rationales to
prop up a decision made for other reasons. But those rationales
simply don't hold water. One doesn't have to get licences. The
association with Microsoft, IBM, et al. of the partitioning scheme
that you *already* deal in doesn't seem to be an obstacle to you.
There's ample documentation for the EFI partitioning scheme publicly
available. Mainboards have very little to do with disc partitioning
schemes. Processor instruction sets have nothing to do with disc
partitioning schemes. And (if the mentions of GPT fdisk, Microsoft,
and Apple didn't give this away) there are publicly available tools
(GPT fdisk, GNU parted, Intel's/Microsoft's "diskpart", and my
DASDPART, for starters) and operating systems (Windows NT and MacOS X)
that put the EFI partitioning scheme into practical use on a daily
basis.
As I said, don't reinvent the wheel. A wheel already exists, here,
that will interoperate with other people's tools and softwares.
And as I also said, one doesn't need to auto-convert partitioning
schemes, or indeed write to disc, if all that one is doing is
constructing temporary data structures on the fly in memory.
Bernhard Schornak
J de Boyne Pollard schrieb:
>
> JdeBP> As mentioned, GRUB is now, finally, capable of using a
> JdeBP> proper partition to reserve space for its second-stage
> JdeBP> portions, as IBM's BootManager does.
>
> BS> My GRUB from the latest DEBIAN distribution does use
> BS> the scheme I mentioned in my posting. Actually, I have
> BS> -not- seen -any- bootmanager (except IBM's) working in
> BS> another way. [...] Forget about GRUB - it's malware...
>
> Then either you haven't looked too closely at the GRUB documentation,
> or your GRUB is an older version. Read the GRUB documentation for
> what it calls the "BIOS Boot partition".
Whenever I find some spare time to search for it.
> JdeBP> Don't reinvent the wheel. If you want an improved
> JdeBP> partition table mechanism, use the EFI one. [...]
>
> BS> I do not support proprietary systems.
>
> Yes, you do, else you wouldn't be supporting the MBR partitioning
> scheme either. I suspect that that is not your real reason but post-
> hoc justification, given the error that you then proceeded to state:
>
> BS> As I have to get a license before I am allowed to view
> BS> any EFI documents, I don't think it is an alternative.
>
> One doesn't have to get licences for anything. There's freely
> available documentation of the EFI partitioning scheme available from
> many places, from the official specification to articles on Apple
> Developer Connection and Microsoft TechNet. As M. Shatskih said, it's
> publicly documented. One could probably even work out how it works
> just from the source code for the GPT fdisk (<URL:http://
> rodsbooks.com./gdisk/>), without looking at any of that public
> documentation. (I've not tried, myself, though. I just read the
> specification.)
Looking at the GUID thingy, the entire concept is
designed to simplify DRM and user tracking. While
32 byte per entry are reserved for GUID's, only 2
quadwords are reserved for the most important in-
formation: Start and size of a partition. It took
less than twenty years until the original MBR en-
coding reached its end and another 10 years until
we reached the limit of 32 bit LBA addressing. It
is foreseeable that we reach the 64 bit limit set
by GPT within the next 15 or 20 years. How can it
be a 'concept for the 21st century' if it defines
its own death within the next 20 years?
Think open, not narrow minded!
> BS> AMD is not mentioned on the EFI homepage.
> BS> My code is optimised for AMD64 and runs
> BS> best on AMD machines
> BS> no AMD board supports EFI.
>
> Those are irrelevant.
Not for more than 90% of all PC users.
> We are talking about a disc partitioning
> scheme, not processor instruction sets. Mainboard support is
> irrelevant, too. After all, if it *were* relevant, you'd have the
> same issue, that no mainboard supports it, with your roll-your-own
> partitioning scheme, since no mainboards support that, either. Yet
> you aren't complaining that no mainboard supports your roll-your-own
> partitioning scheme. The irony is that disk partitioning schemes are
> largely irrelevant to mainboards, which don't have to know anything
> about disc partitions for x86-style load-and-run-the-MBR
> bootstrapping. Those mainboard firmwares that *do* understand and
> deal in disc partitioning schemes *use EFI firmwares* and understand
> the EFI partitioning scheme just fine. So where it actually is
> relevant in the first place, one finds that the mainboards have the
> support. (-:
EFI and GPT still are no international standards.
In general, it is nothing more or less than
<http://www.openfirmware.org/>
OpenFirmware PCs are on the market, as well.
> As above, it appears that you are looking for post-hoc rationales to
> prop up a decision made for other reasons. But those rationales
> simply don't hold water. One doesn't have to get licences. The
> association with Microsoft, IBM, et al. of the partitioning scheme
> that you *already* deal in doesn't seem to be an obstacle to you.
> There's ample documentation for the EFI partitioning scheme publicly
> available. Mainboards have very little to do with disc partitioning
> schemes. Processor instruction sets have nothing to do with disc
> partitioning schemes. And (if the mentions of GPT fdisk, Microsoft,
> and Apple didn't give this away) there are publicly available tools
> (GPT fdisk, GNU parted, Intel's/Microsoft's "diskpart", and my
> DASDPART, for starters) and operating systems (Windows NT and MacOS X)
> that put the EFI partitioning scheme into practical use on a daily
> basis.
>
> As I said, don't reinvent the wheel. A wheel already exists, here,
> that will interoperate with other people's tools and softwares.
A bootmanager is not a partitioning tool. It just
has to start one of the available bootable parti-
tions, nothing else. IDEOS' partition table isn't
reinvention of something, it's a useful extension
for existing PCs, regardless of the installed OS.
Unlike GPT, it is cooperative. It doesn't require
expensive hardware and works with non-'EFI aware'
operating systems. With 128 bit LBA support, it's
fit for the next four or five decades.
> And as I also said, one doesn't need to auto-convert partitioning
> schemes, or indeed write to disc, if all that one is doing is
> constructing temporary data structures on the fly in memory.
That's something I consider. I just hate to waste
valuable resources with outdated mechanisms.
For the remaining parts: Your arguments could not
covince me of GPT or the (U)EFI stuff. As long as
Intel is the main actor and beneficiary, it never
will be my thing. I am not the AMD fanatic, but I
support whatever undercuts the dominant positions
of Intel and Microsoft. I surely will have a look
at the OpenFirmware documents, but GPT already is
history. Its specs define sudden death within the
next two decades - a typical example for 'genuine
Intel'. Let's meet at the burial in 2030... ;)
Greetings from Augsburg + happy new year!
Bernhard Schornak