[PATCH] support T13 EDD3.0 spec
Some guests (such as Linux) expect BIOS to behave according to T13 EDD3.0 spec. T13 spec is much better then Phoenix since it provides more information about interface and device paths. This patch adds support for the spec. If guest provides buffer with enough space for T13 EDD info return EDD according to T13 spec otherwise use Phoenix one. Signed-off-by: Gleb Natapov <gleb@redhat.com> diff --git a/src/disk.c b/src/disk.c index f7bfe9c..fb7833a 100644 --- a/src/disk.c +++ b/src/disk.c @@ -503,6 +503,7 @@ static void disk_1348(struct bregs *regs, struct drive_s *drive_g) { u16 size = GET_INT13DPT(regs, size); + u16 t13 = size == 74; // Buffer is too small if (size < 26) { @@ -553,8 +554,9 @@ disk_1348(struct bregs *regs, struct drive_s *drive_g) // EDD 2.x int bdf; - u16 iobase1; - u64 device_path; + u16 iobase1 = 0; + u64 device_path = 0; + u8 channel = 0; SET_INT13DPT(regs, size, 30); if (type == DTYPE_ATA || type == DTYPE_ATAPI) { u16 ebda_seg = get_ebda_seg(); @@ -573,6 +575,7 @@ disk_1348(struct bregs *regs, struct drive_s *drive_g) iobase1 = GET_GLOBALFLAT(chan_gf->iobase1); bdf = GET_GLOBALFLAT(chan_gf->pci_bdf); device_path = slave; + channel = GET_GLOBALFLAT(chan_gf->chanid); u16 options = 0; if (type == DTYPE_ATA) { @@ -613,8 +616,6 @@ disk_1348(struct bregs *regs, struct drive_s *drive_g) SET_INT13DPT(regs, dpte_segment, 0); SET_INT13DPT(regs, dpte_offset, 0); bdf = GET_GLOBAL(drive_g->cntl_id); - device_path = 0; - iobase1 = 0; } if (size < 66) { @@ -632,17 +633,20 @@ disk_1348(struct bregs *regs, struct drive_s *drive_g) SET_INT13DPT(regs, host_bus[0], 'P'); SET_INT13DPT(regs, host_bus[1], 'C'); SET_INT13DPT(regs, host_bus[2], 'I'); - SET_INT13DPT(regs, host_bus[3], 0); + SET_INT13DPT(regs, host_bus[3], ' '); u32 path = (pci_bdf_to_bus(bdf) | (pci_bdf_to_dev(bdf) << 8) | (pci_bdf_to_fn(bdf) << 16)); + if (t13) + path |= channel << 24; + SET_INT13DPT(regs, iface_path, path); } else { // ISA SET_INT13DPT(regs, host_bus[0], 'I'); SET_INT13DPT(regs, host_bus[1], 'S'); SET_INT13DPT(regs, host_bus[2], 'A'); - SET_INT13DPT(regs, host_bus[3], 0); + SET_INT13DPT(regs, host_bus[3], ' '); SET_INT13DPT(regs, iface_path, iobase1); } @@ -651,7 +655,7 @@ disk_1348(struct bregs *regs, struct drive_s *drive_g) SET_INT13DPT(regs, iface_type[0], 'A'); SET_INT13DPT(regs, iface_type[1], 'T'); SET_INT13DPT(regs, iface_type[2], 'A'); - SET_INT13DPT(regs, iface_type[3], 0); + SET_INT13DPT(regs, iface_type[3], ' '); } else { SET_INT13DPT(regs, iface_type[0], 'S'); SET_INT13DPT(regs, iface_type[1], 'C'); @@ -663,10 +667,18 @@ disk_1348(struct bregs *regs, struct drive_s *drive_g) SET_INT13DPT(regs, iface_type[6], 0); SET_INT13DPT(regs, iface_type[7], 0); - SET_INT13DPT(regs, device_path, device_path); + if (13) { + SET_INT13DPT(regs, t13.device_path[0], device_path); + SET_INT13DPT(regs, t13.device_path[1], 0); + + SET_INT13DPT(regs, t13.checksum + , -checksum_far(regs->ds, (void*)(regs->si+30), 43)); + } else { + SET_INT13DPT(regs, phoenix.device_path, device_path); - SET_INT13DPT(regs, checksum - , -checksum_far(regs->ds, (void*)(regs->si+30), 35)); + SET_INT13DPT(regs, phoenix.checksum + , -checksum_far(regs->ds, (void*)(regs->si+30), 35)); + } disk_ret(regs, DISK_RET_SUCCESS); } diff --git a/src/disk.h b/src/disk.h index f31de73..10a0051 100644 --- a/src/disk.h +++ b/src/disk.h @@ -63,9 +63,18 @@ struct int13dpt_s { u8 host_bus[4]; u8 iface_type[8]; u64 iface_path; - u64 device_path; - u8 reserved3; - u8 checksum; + union { + struct { + u64 device_path; + u8 reserved3; + u8 checksum; + } phoenix; + struct { + u64 device_path[2]; + u8 reserved3; + u8 checksum; + } t13; + }; } PACKED; #define GET_INT13DPT(regs,var) \ -- Gleb.
On Wed, Jan 05, 2011 at 05:18:38PM +0200, Gleb Natapov wrote:
Some guests (such as Linux) expect BIOS to behave according to T13 EDD3.0 spec. T13 spec is much better then Phoenix since it provides more information about interface and device paths. This patch adds support for the spec. If guest provides buffer with enough space for T13 EDD info return EDD according to T13 spec otherwise use Phoenix one.
I think Sebastian has looked at this as well.
Signed-off-by: Gleb Natapov <gleb@redhat.com> diff --git a/src/disk.c b/src/disk.c index f7bfe9c..fb7833a 100644 --- a/src/disk.c +++ b/src/disk.c @@ -503,6 +503,7 @@ static void disk_1348(struct bregs *regs, struct drive_s *drive_g) { u16 size = GET_INT13DPT(regs, size); + u16 t13 = size == 74;
// Buffer is too small if (size < 26) { @@ -553,8 +554,9 @@ disk_1348(struct bregs *regs, struct drive_s *drive_g) // EDD 2.x
int bdf; - u16 iobase1; - u64 device_path; + u16 iobase1 = 0; + u64 device_path = 0; + u8 channel = 0; SET_INT13DPT(regs, size, 30); if (type == DTYPE_ATA || type == DTYPE_ATAPI) { u16 ebda_seg = get_ebda_seg(); @@ -573,6 +575,7 @@ disk_1348(struct bregs *regs, struct drive_s *drive_g) iobase1 = GET_GLOBALFLAT(chan_gf->iobase1); bdf = GET_GLOBALFLAT(chan_gf->pci_bdf); device_path = slave; + channel = GET_GLOBALFLAT(chan_gf->chanid);
u16 options = 0; if (type == DTYPE_ATA) { @@ -613,8 +616,6 @@ disk_1348(struct bregs *regs, struct drive_s *drive_g) SET_INT13DPT(regs, dpte_segment, 0); SET_INT13DPT(regs, dpte_offset, 0); bdf = GET_GLOBAL(drive_g->cntl_id); - device_path = 0; - iobase1 = 0; }
if (size < 66) { @@ -632,17 +633,20 @@ disk_1348(struct bregs *regs, struct drive_s *drive_g) SET_INT13DPT(regs, host_bus[0], 'P'); SET_INT13DPT(regs, host_bus[1], 'C'); SET_INT13DPT(regs, host_bus[2], 'I'); - SET_INT13DPT(regs, host_bus[3], 0); + SET_INT13DPT(regs, host_bus[3], ' ');
What if we're not in t13 mode? Should this be: u8 fillchar = t13 ? ' ' : 0; SET_INT13DPT(regs, host_bus[3], fillchar); [...]
+ if (13) {
That looks like a typo. -Kevin
On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote:
On Wed, Jan 05, 2011 at 05:18:38PM +0200, Gleb Natapov wrote:
Some guests (such as Linux) expect BIOS to behave according to T13 EDD3.0 spec. T13 spec is much better then Phoenix since it provides more information about interface and device paths. This patch adds support for the spec. If guest provides buffer with enough space for T13 EDD info return EDD according to T13 spec otherwise use Phoenix one.
I think Sebastian has looked at this as well.
Yes, I saw the thread. You suggested there to handle both specs simultaneously and this is what I did here.
Signed-off-by: Gleb Natapov <gleb@redhat.com> diff --git a/src/disk.c b/src/disk.c index f7bfe9c..fb7833a 100644 --- a/src/disk.c +++ b/src/disk.c @@ -503,6 +503,7 @@ static void disk_1348(struct bregs *regs, struct drive_s *drive_g) { u16 size = GET_INT13DPT(regs, size); + u16 t13 = size == 74;
// Buffer is too small if (size < 26) { @@ -553,8 +554,9 @@ disk_1348(struct bregs *regs, struct drive_s *drive_g) // EDD 2.x
int bdf; - u16 iobase1; - u64 device_path; + u16 iobase1 = 0; + u64 device_path = 0; + u8 channel = 0; SET_INT13DPT(regs, size, 30); if (type == DTYPE_ATA || type == DTYPE_ATAPI) { u16 ebda_seg = get_ebda_seg(); @@ -573,6 +575,7 @@ disk_1348(struct bregs *regs, struct drive_s *drive_g) iobase1 = GET_GLOBALFLAT(chan_gf->iobase1); bdf = GET_GLOBALFLAT(chan_gf->pci_bdf); device_path = slave; + channel = GET_GLOBALFLAT(chan_gf->chanid);
u16 options = 0; if (type == DTYPE_ATA) { @@ -613,8 +616,6 @@ disk_1348(struct bregs *regs, struct drive_s *drive_g) SET_INT13DPT(regs, dpte_segment, 0); SET_INT13DPT(regs, dpte_offset, 0); bdf = GET_GLOBAL(drive_g->cntl_id); - device_path = 0; - iobase1 = 0; }
if (size < 66) { @@ -632,17 +633,20 @@ disk_1348(struct bregs *regs, struct drive_s *drive_g) SET_INT13DPT(regs, host_bus[0], 'P'); SET_INT13DPT(regs, host_bus[1], 'C'); SET_INT13DPT(regs, host_bus[2], 'I'); - SET_INT13DPT(regs, host_bus[3], 0); + SET_INT13DPT(regs, host_bus[3], ' ');
What if we're not in t13 mode? Should this be: u8 fillchar = t13 ? ' ' : 0; SET_INT13DPT(regs, host_bus[3], fillchar);
Phoenix does not specify padding. Are you sure phoenix has to have zero padding?
[...]
+ if (13) {
That looks like a typo.
Oops. Will resend. -- Gleb.
On Thu, Jan 06, 2011 at 07:09:27AM +0200, Gleb Natapov wrote:
On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote:
- SET_INT13DPT(regs, host_bus[3], 0); + SET_INT13DPT(regs, host_bus[3], ' ');
What if we're not in t13 mode? Should this be: u8 fillchar = t13 ? ' ' : 0; SET_INT13DPT(regs, host_bus[3], fillchar);
Phoenix does not specify padding. Are you sure phoenix has to have zero padding?
I think RBIL documented 0s. It may not be important. -Kevin
On Thu, Jan 06, 2011 at 08:41:11AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 07:09:27AM +0200, Gleb Natapov wrote:
On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote:
- SET_INT13DPT(regs, host_bus[3], 0); + SET_INT13DPT(regs, host_bus[3], ' ');
What if we're not in t13 mode? Should this be: u8 fillchar = t13 ? ' ' : 0; SET_INT13DPT(regs, host_bus[3], fillchar);
Phoenix does not specify padding. Are you sure phoenix has to have zero padding?
I think RBIL documented 0s. It may not be important.
What is RBIL? -- Gleb.
On Thu, Jan 06, 2011 at 03:53:57PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 08:41:11AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 07:09:27AM +0200, Gleb Natapov wrote:
On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote:
- SET_INT13DPT(regs, host_bus[3], 0); + SET_INT13DPT(regs, host_bus[3], ' ');
What if we're not in t13 mode? Should this be: u8 fillchar = t13 ? ' ' : 0; SET_INT13DPT(regs, host_bus[3], fillchar);
Phoenix does not specify padding. Are you sure phoenix has to have zero padding?
I think RBIL documented 0s. It may not be important.
What is RBIL?
Sorry - Ralph Brown's interrupt list: http://www.cs.cmu.edu/~ralf/files.html -Kevin
On Thu, Jan 06, 2011 at 09:00:00AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 03:53:57PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 08:41:11AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 07:09:27AM +0200, Gleb Natapov wrote:
On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote:
- SET_INT13DPT(regs, host_bus[3], 0); + SET_INT13DPT(regs, host_bus[3], ' ');
What if we're not in t13 mode? Should this be: u8 fillchar = t13 ? ' ' : 0; SET_INT13DPT(regs, host_bus[3], fillchar);
Phoenix does not specify padding. Are you sure phoenix has to have zero padding?
I think RBIL documented 0s. It may not be important.
What is RBIL?
Sorry - Ralph Brown's interrupt list:
Ah, I have it, just didn't know it is called RBIL :). Do you want me to resend with fillchar = t13 ? ' ' : 0; or space should be good enough? -- Gleb.
Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 09:00:00AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 03:53:57PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 08:41:11AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 07:09:27AM +0200, Gleb Natapov wrote:
On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote:
> - SET_INT13DPT(regs, host_bus[3], 0); > + SET_INT13DPT(regs, host_bus[3], ' ');
What if we're not in t13 mode? Should this be: u8 fillchar = t13 ? ' ' : 0; SET_INT13DPT(regs, host_bus[3], fillchar);
Phoenix does not specify padding. Are you sure phoenix has to have zero padding?
I think RBIL documented 0s. It may not be important.
What is RBIL?
Sorry - Ralph Brown's interrupt list:
Ah, I have it, just didn't know it is called RBIL :).
Do you want me to resend with fillchar = t13 ? ' ' : 0; or space should be good enough?
I suggest to keep the current behaviour if a buffer size of 66 bytes is supplied; this patch would then be a no-op for buffers < 74. Sebastian
On Thu, Jan 06, 2011 at 10:04:38PM +0100, Sebastian Herbszt wrote:
Do you want me to resend with fillchar = t13 ? ' ' : 0; or space should be good enough? I suggest to keep the current behaviour if a buffer size of 66 bytes is supplied; this patch would then be a no-op for buffers <
Gleb Natapov wrote: 74.
I could go either way here, but I think Sebastian has a point about not changing callers with buffer=66. So, I'd say add (t13 ? ' ' : 0). Thanks. -Kevin
On Thu, Jan 06, 2011 at 04:24:13PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 09:00:00AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 03:53:57PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 08:41:11AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 07:09:27AM +0200, Gleb Natapov wrote:
On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote:
> - SET_INT13DPT(regs, host_bus[3], 0); > + SET_INT13DPT(regs, host_bus[3], ' ');
What if we're not in t13 mode? Should this be: u8 fillchar = t13 ? ' ' : 0; SET_INT13DPT(regs, host_bus[3], fillchar);
Phoenix does not specify padding. Are you sure phoenix has to have zero padding?
I think RBIL documented 0s. It may not be important.
What is RBIL?
Sorry - Ralph Brown's interrupt list:
Ah, I have it, just didn't know it is called RBIL :).
Do you want me to resend with fillchar = t13 ? ' ' : 0; or space should be good enough?
I just tested winxp, and it doesn't seem to call 1348 with a size bigger than 26 bytes. So, thinking about it further, I'm not sure it matters - the spec isn't clear and I don't know of anything that would care. (To be clear, I think we should support the 66 byte buffer size, however I'm not sure the padding matters.) Sebastian - do you know of anything that calls 1348 with a buffer size that could observe the difference? -Kevin
On Thu, Jan 06, 2011 at 08:24:39PM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 04:24:13PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 09:00:00AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 03:53:57PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 08:41:11AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 07:09:27AM +0200, Gleb Natapov wrote:
On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote: > > - SET_INT13DPT(regs, host_bus[3], 0); > > + SET_INT13DPT(regs, host_bus[3], ' '); > > What if we're not in t13 mode? Should this be: > u8 fillchar = t13 ? ' ' : 0; > SET_INT13DPT(regs, host_bus[3], fillchar); > Phoenix does not specify padding. Are you sure phoenix has to have zero padding?
I think RBIL documented 0s. It may not be important.
What is RBIL?
Sorry - Ralph Brown's interrupt list:
Ah, I have it, just didn't know it is called RBIL :).
Do you want me to resend with fillchar = t13 ? ' ' : 0; or space should be good enough?
I just tested winxp, and it doesn't seem to call 1348 with a size bigger than 26 bytes. So, thinking about it further, I'm not sure it matters - the spec isn't clear and I don't know of anything that would care. (To be clear, I think we should support the 66 byte buffer size, however I'm not sure the padding matters.)
Windows7 also calls it only with 26 bytes. Grub calls it with 66 bytes buffer.
Sebastian - do you know of anything that calls 1348 with a buffer size that could observe the difference?
-Kevin
-- Gleb.
Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 04:24:13PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 09:00:00AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 03:53:57PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 08:41:11AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 07:09:27AM +0200, Gleb Natapov wrote:
On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote: > > - SET_INT13DPT(regs, host_bus[3], 0); > > + SET_INT13DPT(regs, host_bus[3], ' '); > > What if we're not in t13 mode? Should this be: > u8 fillchar = t13 ? ' ' : 0; > SET_INT13DPT(regs, host_bus[3], fillchar); > Phoenix does not specify padding. Are you sure phoenix has to have zero padding?
I think RBIL documented 0s. It may not be important.
What is RBIL?
Sorry - Ralph Brown's interrupt list:
Ah, I have it, just didn't know it is called RBIL :).
Do you want me to resend with fillchar = t13 ? ' ' : 0; or space should be good enough?
I just tested winxp, and it doesn't seem to call 1348 with a size bigger than 26 bytes. So, thinking about it further, I'm not sure it matters - the spec isn't clear and I don't know of anything that would care. (To be clear, I think we should support the 66 byte buffer size, however I'm not sure the padding matters.)
Sebastian - do you know of anything that calls 1348 with a buffer size that could observe the difference?
I think syslinux and FreeDOS call 1348 - will check their buffers later. I have tested 1348 on VMware Player 3.0.0 build-203739. It runs PhoenixBIOS 4.0 Release 6.0, VMware BIOS build 314. Results: Input Buffer length -> Output Buffer length 1a -> 1a 1e -> 1e 42 -> 1e (looks like it doesn't support 42!) 4a -> 4a (wrong output buffer length, should be 1e; uses space padding) Will do more tests later. Sebastian
On Sat, Jan 08, 2011 at 01:48:00PM +0100, Sebastian Herbszt wrote:
Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 04:24:13PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 09:00:00AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 03:53:57PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 08:41:11AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 07:09:27AM +0200, Gleb Natapov wrote: > On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote: > > > - SET_INT13DPT(regs, host_bus[3], 0); > > > + SET_INT13DPT(regs, host_bus[3], ' '); > > > > > > > What if we're not in t13 mode? Should this be: > > u8 fillchar = t13 ? ' ' : 0; > > SET_INT13DPT(regs, host_bus[3], fillchar); > > > > > > Phoenix does not specify padding. Are you sure phoenix has to have zero > padding? > > > I think RBIL documented 0s. It may not be important. > > What is RBIL? Sorry - Ralph Brown's interrupt list: http://www.cs.cmu.edu/~ralf/files.html Ah, I have it, just didn't know it is called RBIL :).
Do you want me to resend with fillchar = t13 ? ' ' : 0; or space should be good enough?
I just tested winxp, and it doesn't seem to call 1348 with a size bigger than 26 bytes. So, thinking about it further, I'm not sure it matters - the spec isn't clear and I don't know of anything that would care. (To be clear, I think we should support the 66 byte buffer size, however I'm not sure the padding matters.)
Sebastian - do you know of anything that calls 1348 with a buffer size that could observe the difference?
I think syslinux and FreeDOS call 1348 - will check their buffers later.
I have tested 1348 on VMware Player 3.0.0 build-203739. It runs PhoenixBIOS 4.0 Release 6.0, VMware BIOS build 314. Results: Input Buffer length -> Output Buffer length 1a -> 1a 1e -> 1e 42 -> 1e (looks like it doesn't support 42!) 4a -> 4a (wrong output buffer length, should be 1e; uses space padding)
Will do more tests later.
RBIL mention that: Dell machines using PhoenixBIOS 4.0 Release 6.0 fail to correctly handle this function if the flag word at DS:[SI+2] is not 0000h on entry Make sure to have it set to zero in you testing. May be VMware's build has the same problem. -- Gleb.
Gleb Natapov wrote:
On Sat, Jan 08, 2011 at 01:48:00PM +0100, Sebastian Herbszt wrote:
Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 04:24:13PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 09:00:00AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 03:53:57PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 08:41:11AM -0500, Kevin O'Connor wrote: > On Thu, Jan 06, 2011 at 07:09:27AM +0200, Gleb Natapov wrote: > > On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote: > > > > - SET_INT13DPT(regs, host_bus[3], 0); > > > > + SET_INT13DPT(regs, host_bus[3], ' '); > > > > > > > > What if we're not in t13 mode? Should this be: > > > u8 fillchar = t13 ? ' ' : 0; > > > SET_INT13DPT(regs, host_bus[3], fillchar); > > > > > > > Phoenix does not specify padding. Are you sure phoenix has to have zero > > padding? > > > > I think RBIL documented 0s. It may not be important. > > > What is RBIL? Sorry - Ralph Brown's interrupt list: http://www.cs.cmu.edu/~ralf/files.html Ah, I have it, just didn't know it is called RBIL :).
Do you want me to resend with fillchar = t13 ? ' ' : 0; or space should be good enough?
I just tested winxp, and it doesn't seem to call 1348 with a size bigger than 26 bytes. So, thinking about it further, I'm not sure it matters - the spec isn't clear and I don't know of anything that would care. (To be clear, I think we should support the 66 byte buffer size, however I'm not sure the padding matters.)
Sebastian - do you know of anything that calls 1348 with a buffer size that could observe the difference?
I think syslinux and FreeDOS call 1348 - will check their buffers later.
I have tested 1348 on VMware Player 3.0.0 build-203739. It runs PhoenixBIOS 4.0 Release 6.0, VMware BIOS build 314. Results: Input Buffer length -> Output Buffer length 1a -> 1a 1e -> 1e 42 -> 1e (looks like it doesn't support 42!) 4a -> 4a (wrong output buffer length, should be 1e; uses space padding)
Will do more tests later.
RBIL mention that: Dell machines using PhoenixBIOS 4.0 Release 6.0 fail to correctly handle this function if the flag word at DS:[SI+2] is not 0000h on entry Make sure to have it set to zero in you testing. May be VMware's build has the same problem.
I cleared the buffer on each test. Here are the resulting buffers: 1a 00: 1a 00 01 00 ff 3f 00 00 - 0f 00 00 00 3f 00 00 00 10: 00 00 40 01 00 00 00 00 - 00 02 -- -- -- -- -- -- 1e 00: 1e 00 01 00 ff 3f 00 00 - 0f 00 00 00 3f 00 00 00 10: 00 00 40 01 00 00 00 00 - 00 02 c6 00 40 00 -- -- 42 00: 1e 00 01 00 ff 3f 00 00 - 0f 00 00 00 3f 00 00 00 10: 00 00 40 01 00 00 00 00 - 00 02 c6 00 40 00 -- -- 4a 00: 4a 00 01 00 ff 3f 00 00 - 0f 00 00 00 3f 00 00 00 10: 00 00 40 01 00 00 00 00 - 00 02 c6 00 40 00 dd be 20: 2c 00 00 00 50 43 49 20 - 41 54 41 20 20 20 20 20 30: 00 07 01 00 00 00 00 00 - 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 - 00 bf -- -- -- -- -- -- Sebastian
On Sun, Jan 09, 2011 at 02:10:51PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
On Sat, Jan 08, 2011 at 01:48:00PM +0100, Sebastian Herbszt wrote:
Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 04:24:13PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 09:00:00AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 03:53:57PM +0200, Gleb Natapov wrote: > On Thu, Jan 06, 2011 at 08:41:11AM -0500, Kevin O'Connor wrote: > > On Thu, Jan 06, 2011 at 07:09:27AM +0200, Gleb Natapov wrote: > > > On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote: > > > > > - SET_INT13DPT(regs, host_bus[3], 0); > > > > > + SET_INT13DPT(regs, host_bus[3], ' '); > > > > > > > > > What if we're not in t13 mode? Should this be: > > > > u8 fillchar = t13 ? ' ' : 0; > > > > SET_INT13DPT(regs, host_bus[3], fillchar); > > > > > > > > Phoenix does not specify padding. Are you sure phoenix has to have zero > > > padding? > > > > > I think RBIL documented 0s. It may not be important. > > > > What is RBIL? > Sorry - Ralph Brown's interrupt list: > http://www.cs.cmu.edu/~ralf/files.html Ah, I have it, just didn't know it is called RBIL :).
Do you want me to resend with fillchar = t13 ? ' ' : 0; or space should be good enough?
I just tested winxp, and it doesn't seem to call 1348 with a size bigger than 26 bytes. So, thinking about it further, I'm not sure it matters - the spec isn't clear and I don't know of anything that would care. (To be clear, I think we should support the 66 byte buffer size, however I'm not sure the padding matters.)
Sebastian - do you know of anything that calls 1348 with a buffer size that could observe the difference?
I think syslinux and FreeDOS call 1348 - will check their buffers later.
I have tested 1348 on VMware Player 3.0.0 build-203739. It runs PhoenixBIOS 4.0 Release 6.0, VMware BIOS build 314. Results: Input Buffer length -> Output Buffer length 1a -> 1a 1e -> 1e 42 -> 1e (looks like it doesn't support 42!) 4a -> 4a (wrong output buffer length, should be 1e; uses space padding)
Will do more tests later.
RBIL mention that: Dell machines using PhoenixBIOS 4.0 Release 6.0 fail to correctly handle this function if the flag word at DS:[SI+2] is not 0000h on entry Make sure to have it set to zero in you testing. May be VMware's build has the same problem.
I cleared the buffer on each test. Here are the resulting buffers:
1a 00: 1a 00 01 00 ff 3f 00 00 - 0f 00 00 00 3f 00 00 00 10: 00 00 40 01 00 00 00 00 - 00 02 -- -- -- -- -- --
1e 00: 1e 00 01 00 ff 3f 00 00 - 0f 00 00 00 3f 00 00 00 10: 00 00 40 01 00 00 00 00 - 00 02 c6 00 40 00 -- --
42 00: 1e 00 01 00 ff 3f 00 00 - 0f 00 00 00 3f 00 00 00 10: 00 00 40 01 00 00 00 00 - 00 02 c6 00 40 00 -- --
4a 00: 4a 00 01 00 ff 3f 00 00 - 0f 00 00 00 3f 00 00 00 10: 00 00 40 01 00 00 00 00 - 00 02 c6 00 40 00 dd be 20: 2c 00 00 00 50 43 49 20 - 41 54 41 20 20 20 20 20 30: 00 07 01 00 00 00 00 00 - 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 - 00 bf -- -- -- -- -- --
So what about making Seabios to pad with spaces too? -- Gleb.
On Sun, Jan 09, 2011 at 06:17:13PM +0200, Gleb Natapov wrote:
On Sun, Jan 09, 2011 at 02:10:51PM +0100, Sebastian Herbszt wrote:
I cleared the buffer on each test. Here are the resulting buffers:
Thanks!
So what about making Seabios to pad with spaces too?
Given the recent investigation, that seems like the right way. -Kevin
Kevin O'Connor wrote:
On Sun, Jan 09, 2011 at 06:17:13PM +0200, Gleb Natapov wrote:
On Sun, Jan 09, 2011 at 02:10:51PM +0100, Sebastian Herbszt wrote:
I cleared the buffer on each test. Here are the resulting buffers:
Thanks!
So what about making Seabios to pad with spaces too?
Given the recent investigation, that seems like the right way.
-Kevin
Result summary: PhoenixBIOS 4.0 Release 6.0, VMware BIOS build 314 1a, 1e, 4a + space padding AMIBIOS, V3.02 Release 08/15/2007 1a, 1e, 42 + space padding Award Modular BIOS v4.51PG 1a, 1e, 42 + space padding AMIBIOS, P2.60, 10/20/2004 no EDD 3.0 support? Sebastian
Sebastian Herbszt wrote:
Kevin O'Connor wrote:
On Sun, Jan 09, 2011 at 06:17:13PM +0200, Gleb Natapov wrote:
On Sun, Jan 09, 2011 at 02:10:51PM +0100, Sebastian Herbszt wrote:
I cleared the buffer on each test. Here are the resulting buffers:
Thanks!
So what about making Seabios to pad with spaces too?
Given the recent investigation, that seems like the right way.
-Kevin
Result summary:
PhoenixBIOS 4.0 Release 6.0, VMware BIOS build 314 1a, 1e, 4a + space padding
AMIBIOS, V3.02 Release 08/15/2007 1a, 1e, 42 + space padding
Award Modular BIOS v4.51PG 1a, 1e, 42 + space padding
AMIBIOS, P2.60, 10/20/2004 no EDD 3.0 support?
Few more: Phoenix SecureCore Server Version 6.00 1a, 1e, 4a + space padding Phoenix cME FirstBIOS Desktop Pro Version 5.00 1a, 1e, 4a + space padding HP System BIOS 786G6 v01.03 1a, 1e Sebastian
Sebastian Herbszt wrote:
Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 04:24:13PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 09:00:00AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 03:53:57PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 08:41:11AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 07:09:27AM +0200, Gleb Natapov wrote: > On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote: > > > - SET_INT13DPT(regs, host_bus[3], 0); > > > + SET_INT13DPT(regs, host_bus[3], ' '); > > > > What if we're not in t13 mode? Should this be: > > u8 fillchar = t13 ? ' ' : 0; > > SET_INT13DPT(regs, host_bus[3], fillchar); > > > Phoenix does not specify padding. Are you sure phoenix has to have zero > padding?
I think RBIL documented 0s. It may not be important.
What is RBIL?
Sorry - Ralph Brown's interrupt list:
Ah, I have it, just didn't know it is called RBIL :).
Do you want me to resend with fillchar = t13 ? ' ' : 0; or space should be good enough?
I just tested winxp, and it doesn't seem to call 1348 with a size bigger than 26 bytes. So, thinking about it further, I'm not sure it matters - the spec isn't clear and I don't know of anything that would care. (To be clear, I think we should support the 66 byte buffer size, however I'm not sure the padding matters.)
Sebastian - do you know of anything that calls 1348 with a buffer size that could observe the difference?
I think syslinux and FreeDOS call 1348 - will check their buffers later.
I have tested 1348 on VMware Player 3.0.0 build-203739. It runs PhoenixBIOS 4.0 Release 6.0, VMware BIOS build 314. Results: Input Buffer length -> Output Buffer length 1a -> 1a 1e -> 1e 42 -> 1e (looks like it doesn't support 42!) 4a -> 4a (wrong output buffer length, should be 1e; uses space padding)
Will do more tests later.
AMIBIOS V3.02 Release 08/15/2007 1a 00: 1a 00 00 00 ff 3f 00 00 - 10 00 00 00 3f 00 00 00 10: 30 60 38 3a 00 00 00 00 - 00 02 -- -- -- -- -- -- 1e 00: 1e 00 00 00 ff 3f 00 00 - 10 00 00 00 3f 00 00 00 10: 30 60 38 3a 00 00 00 00 - 00 02 c0 4e d0 ea -- -- 42 00: 42 00 00 00 ff 3f 00 00 - 10 00 00 00 3f 00 00 00 10: 30 60 38 3a 00 00 00 00 - 00 02 c0 4e d0 ea dd be 20: 24 00 00 00 50 43 49 20 - 41 54 41 20 20 20 20 20 30: 00 1f 20 00 00 00 00 00 - 00 00 00 00 00 00 00 00 40: 00 ae -- -- -- -- -- -- - -- -- -- -- -- -- -- -- 4a 00: 42 00 00 00 ff 3f 00 00 - 10 00 00 00 3f 00 00 00 10: 30 60 38 3a 00 00 00 00 - 00 02 c0 4e d0 ea dd be 20: 24 00 00 00 50 43 49 20 - 41 54 41 20 20 20 20 20 30: 00 1f 20 00 00 00 00 00 - 00 00 00 00 00 00 00 00 40: 00 ae -- -- -- -- -- -- - -- -- -- -- -- -- -- -- Sebastian
Sebastian Herbszt wrote:
Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 04:24:13PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 09:00:00AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 03:53:57PM +0200, Gleb Natapov wrote:
On Thu, Jan 06, 2011 at 08:41:11AM -0500, Kevin O'Connor wrote:
On Thu, Jan 06, 2011 at 07:09:27AM +0200, Gleb Natapov wrote: > On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote: > > > - SET_INT13DPT(regs, host_bus[3], 0); > > > + SET_INT13DPT(regs, host_bus[3], ' '); > > > > What if we're not in t13 mode? Should this be: > > u8 fillchar = t13 ? ' ' : 0; > > SET_INT13DPT(regs, host_bus[3], fillchar); > > > Phoenix does not specify padding. Are you sure phoenix has to have zero > padding?
I think RBIL documented 0s. It may not be important.
What is RBIL?
Sorry - Ralph Brown's interrupt list:
Ah, I have it, just didn't know it is called RBIL :).
Do you want me to resend with fillchar = t13 ? ' ' : 0; or space should be good enough?
I just tested winxp, and it doesn't seem to call 1348 with a size bigger than 26 bytes. So, thinking about it further, I'm not sure it matters - the spec isn't clear and I don't know of anything that would care. (To be clear, I think we should support the 66 byte buffer size, however I'm not sure the padding matters.)
Sebastian - do you know of anything that calls 1348 with a buffer size that could observe the difference?
I think syslinux and FreeDOS call 1348 - will check their buffers later.
Freedos - 30 syslinux - 66 GRUB2 - 66 Linux - 74 Sebastian
participants (3)
-
Gleb Natapov -
Kevin O'Connor -
Sebastian Herbszt