Re: [SeaBIOS] [PATCH] Add config option to disable MTRRinitialization.

[Scott Duplichan]

Sebastian Herbszt wrote:

] 00034041578i[CPU0 ] 0x01fe28e9 wrmsr  : 0F30
] 00034041578e[CPU0 ] exception(): 3rd (13) exception with no resolution, 
shutdown status is 00h,
]
]Stanislav, you happen to know why WRMSR is not recognized here?
]
]Sebastian

If it works like real hardware, it is exception 6 that would tell you the
instruction is not supporteed, not exception 13. Exception 13h during MTRR
initialization is most often because of too many mask bits set when writing
the mask part of a variable MTRR pair (ecx=201,203,...20Fh). Software
should call cpuid function 8008h to find out how many bits can safely be
set in the variable MTRR mask. Setting reserved bits in the fixed MTRRs
might also be able to cause a GP fault.

Thanks,
Scott


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] non-emulated AHCI hardware

[Scott Duplichan]

Scott Duplichan wrote:

]1) When booting a DOS drive, a disk read error occurs at some point
]after autoexec executes.

The revised patch (attached) overcomes this problem. It turns out in
the latter stage of booting, DOS makes a couple of INT13 read requests
with a buffer that is not word aligned. AHCI only supports word aligned
buffers. This was causing the data to be shifted by one byte for these
reads. The patch adds unaligned support for reads only, which is good
enough for the DOS boot problem. The method of this patch actually 
writes one byte beyond the end of the caller's buffer. But the only
OS seen to do this is DOS, so it may be good enough this way.

]2) DOS booting is slower by 100-200 ms. While that isn't much in
]absolute terms, it is a big percentage increase from the 642 ms I
]can get using the IDE interface.

Now AHCI DOS boot is slower than IDE DOS boot by only 40 ms, so
I am satisfied and have switched my project over to AHCI mode.

Thanks,
Scott
  



ahci-002.patch
Description: Binary data
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] non-emulated AHCI hardware

[Scott Duplichan]

Peter Stuge wrote:

]Still it's not nice to write outside the callers buffer. Another OS
]might call same function and SeaBIOS would end up corrupting some
]variable. Ungood. I guess memmove() is the only choice?

]//Peter

I had a couple of ideas for a more sound solution. Debugging them is
a challenge for me because I am new to seabios development and its
method for writing code that works correctly in both 16-bit and
32-bit mode. Anyway, the first method I tried was to allocate a 
temporary I/O buffer that has the proper alignment. While that
creates overhead, it would only be invoked in the rare case of
unaligned request. But then there is the possibility that the
allocation function will not be able to satisfy the request.
Another possibility is splitting the request. The caller's buffer
could handle the bigger part, and a stack buffer could be used for
the remaining part. Yet another possibility is to backup the byte
that gets overwritten by the current patch method and restore it
afterwards. While that is an unreliable method for paged code, it
might work here. The only danger I can think of is if the caller's
buffer is at the end of a physical DRAM range.

Thanks,
Scott


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] non-emulated AHCI hardware

[Scott Duplichan]

Gerd Hoffmann wrote:

]   Hi,
]
] Attached is a two part version of the previous patch. Stage1 is enough
] to get through most OS installs. Stage2 adds unaligned buffer support
] needed for MS-DOS.
]
]Hmm, patch #1 is still a collection of multiple changes, looks a bit 
]like trying this and that until it somehow worked, without figuring 
]which changes where needed to make the box boot.

Thank you for the feedback. This is a pretty harsh assessment of work
that transforms non-functioning code into something usable on real hardware.
Have you ever written code for real hardware or do work strictly with
software models?

]  Also the changelog 
]should describe what was changed and why, not only the effect of the
]change.

These documents will help you understand the changes:
http://download.intel.com/technology/serialata/pdf/rev1_3.pdf
http://www.lttconn.com/res/lttconn/pdres/201005/20100521170123066.pdf

]Polling the IRQ status looks like a sensible thing to do.  Note that 
]there might be multiple bits set in the IRQ status register, so you 
]can't use irqbits == 0x01 to check the status.  qemu fails to boot 
]because of that bug.

Have you considered the possibility that the reason this works on real
hardware and not qemu is that the qemu AHCI model has an erratum?

]  Also it isn't obvious why you are looking for 
]others than the Device to Host Register FIS interrupt.  Care to explain?

I don't understand this question.

]I've attached a patch which switches ahci over to irq status polling, 
]based on your patch.  Works nicely in qemu.  Can you give it a spin on 
]real hardware?

It fails on real (AMD) hardware.

I am surprised by qemu bias of your questions. The type of question I
expected is great to hear it works on AMD hardware, but what about Intel
hardware? My answer would be that I cannot easily test the code on Intel
hardware.

Thanks,
Scott


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH] Consider a VGA to be active if it responds to either IO or memory access

[Scott Duplichan]

Ian Campbell wrote:

]It's not obvious whether the I/O space enable bit in the PCI cfg command
]register is supposed to control the availability of non-PCI registers or
]not. Neither the PCI spec nor the GD-5446 datasheet are particularly
]clear on the matter.

The VGA class code indicates that the legacy I/O ranges are decoded,
when enabled in the command register. True the PCI spec does not spell
this out. But there is really no other way it could work. The BAR 
mechanism does not provide a way to either report or accept programming
for a range such as 3b0-3bb.

]I've just discovered that the ancient pentium box I use as a home
]firewall has a GD 5446 in it (useful to know!), it doesn't have any I/O
]BARS but it does have the I/O bit set in the PCI command register.
]
]It's not clear who was responsible for setting that bit, in general in
]the absence of an I/O BAR the BIOS wouldn't know to do so. I expect that
]either the VGA BIOS is expected to enable it if the hardware it drives
]requires it or that BIOSen special case class=VGA devices and always
]enable I/O for one of them.

BIOS or some other firmware (coreboot) must enable I/O decode in 
the command register for VGA class devices. Option ROMs in general do
not enable it.

]It looks like coreboot always forces this bit on for the VGA device
]which it determines to be the primary, which is good enough for me --
]I'll make a patch to the Xen pci setup code to implement that instead of
]this change to SeaBIOS.

Yes, right here:
http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/devices/pci_devi
ce.c#L619

Thanks,
Scott


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [coreboot] Add IDE_TO_AHCI config

[Scott Duplichan]

Alex Chuang wrote:

]Hi,
]
]Attach my modified files that are used git format-patch format.
]
]Best regards,
]Alex

Hello Alex,

I tested this patch on AMD Persimmon. In SeaBIOS, I enabled your new
IDE_TO_AHCI option, enabled ATA and ATA DMA, and disabled AHCI.

In coreboot, I hid the IDE controller at device 14h function 1 and
enabled the SATA AHCI/IDE controller at device 11h function 0.

Windows 7 installs and device manager reports device 11h function 0
as Standard AHCI 1.0 Serial ATA Controller. This show that the 
feature is working as intended.

Thanks,
Scott


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] Issues with ASRock E350M1

[Scott Duplichan]

Kevin O'Connor wrote:

] I also have USB keyboard problems, but my problem is different. For
] each key I press, it repeats a couple dozen times. I solve the problem
] by adding a 'break' to usb-hid.c:
] 
] for (;;) {
] struct keyevent data;
] int ret = usb_poll_intr(pipe, data);
] if (ret)
] break;
] handle_key(data);
] break; ==
]
]Can you generate and send a log with debug level set to 8 and the
]dprintf in usb-hid.c:handle_key() changed to 8?  Getting timestamps on
]the log (as with tools/readserial.py) would also help.
]
] With this change, I am able to type well enough to get windbg started,
] which is all I needed at the time. But typing is very sluggish. I
] believe the sluggishness is due to use of 8254 periodic interrupt
] polling to service the keyboard.
]
]Yeah - since the loop was disabled there's no longer a queue on USB
]key events.  This means any keys pressed faster than 55ms are dropped.

Hello Kevin,

I decided to try and debug this myself. The attached patch is what I
came up with. Within the limitations of typing abilities, it is now
perfect. No sluggishness and no dropped keys. The head == next check
was failing when it should have passed. The reason is that the
toggleCarry bit is often set in endpoint descriptor dword #2, at least
on AMD hardware. Hopefully this change is compatible with qemu, Intel,
and other OHCI controllers.

Thanks,
Scott


Mask toggleCarry and Halted flags in endpoint descriptor dword #2 so that
the remaining head pointer field is valid for comparing with the next
pointer.

Signed-off-by: Scott Duplichan sc...@notabs.org


--- seabios-0.6.2-original\src\usb-ohci.c   Mon Feb 28 21:10:57 2011
+++ seabios-0.6.2\src\usb-ohci.cSun May 29 02:47:30 2011
@@ -501,7 +501,7 @@
 
 struct ohci_pipe *pipe = container_of(p, struct ohci_pipe, pipe);
 struct ohci_td *tds = GET_FLATPTR(pipe-tds);
-struct ohci_td *head = (void*)GET_FLATPTR(pipe-ed.hwHeadP);
+struct ohci_td *head = (void*)(GET_FLATPTR(pipe-ed.hwHeadP) 
0x0);
 struct ohci_td *tail = (void*)GET_FLATPTR(pipe-ed.hwTailP);
 int count = GET_FLATPTR(pipe-count);
 int pos = (tail - tds + 1) % count;


usb-kb.patch
Description: Binary data
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH] Ctrl-Break support (INT 1B, etc)

[Scott Duplichan]

Kevin O'Connor wrote:

]On Thu, Jul 21, 2011 at 02:49:08AM +0300, Nikolay Nikolov wrote:
] Hi, all,
] 
] I made a patch for proper Ctrl-Break handling. This is useful for
] MS-DOS or compatible operating systems like FreeDOS.

...

] +enqueue_key(0, 0);
]
]RBIL implies the  should be added to the keyboard buffer before
]the int 0x1B - though I'm not really familiar enough to say which is
]really correct.

It looks like Phoenix legacy BIOS and AMI legacy BIOS add the  after
int 1b.

Thanks,
Scott

]
]-Kevin


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] problem building from Windows using msys

[Scott Duplichan]

Building SeaBIOS from Windows using mingw has been broken for
a long time. The problem is that in this environment, line 100
of the makefile:

   $(Q)printf '$(foreach i,$2,#include $(CURDIR)/$i\n)'  $3.tmp.c

creates an include statement that the mingw port of gcc rejects:

   #include /D/coreboot/build/seabios/src/misc.c

Msys converts the Windows drive letter D:\ to a more
Unix-like /D/. But the mingw port of gcc needs D:\, not /d/.
While this problem might not be easy to solve, I did find
a work-around: use relative paths in the include statements
rather than absolute paths. In other words, change makefile
line 100 from this:

   $(Q)printf '$(foreach i,$2,#include $(CURDIR)/$i\n)'  $3.tmp.c
to this:
   $(Q)printf '$(foreach i,$2,#include ../$i\n)'  $3.tmp.c

This solves the problem for Windows. Would it break the build
in Linux environments? If so, I could just use this change
locally. But even that is not easy. The way the coreboot 
makefile is written causes git to enforce use of unmodified
SeaBIOS. To work around this, I tried to make a sed command
to apply this change temporarily. But I cannot figure out
the needed quoting to pass $(CURDIR) to sed without expansion.

Thanks,
Scott
 





___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] problem building from Windows using msys

[Scott Duplichan]

Kevin O'Connor [mailto:ke...@koconnor.net] wrote:

]On Sun, Jun 01, 2014 at 10:31:39PM -0500, Scott Duplichan wrote:
] Building SeaBIOS from Windows using mingw has been broken for
] a long time. The problem is that in this environment, line 100
] of the makefile:
] 
]$(Q)printf '$(foreach i,$2,#include $(CURDIR)/$i\n)'  $3.tmp.c
] 
] creates an include statement that the mingw port of gcc rejects:
] 
]#include /D/coreboot/build/seabios/src/misc.c
] 
] Msys converts the Windows drive letter D:\ to a more
] Unix-like /D/. But the mingw port of gcc needs D:\, not /d/.
] While this problem might not be easy to solve, I did find
] a work-around: use relative paths in the include statements
] rather than absolute paths. In other words, change makefile
] line 100 from this:
] 
]$(Q)printf '$(foreach i,$2,#include $(CURDIR)/$i\n)'  $3.tmp.c
] to this:
]$(Q)printf '$(foreach i,$2,#include ../$i\n)'  $3.tmp.c
]
]Unfortunately, this would break builds where one specifies an OUT
]build directory that isn't a sub-directory of the source code.  (That
]is, a build with make OUT=/a/b/c.)
]
]I've never tried building under Windows, and I'm not really sure how
]to help here.  Does passing the CURDIR via the command-line (as in the
]patch below) improve things?
]
]-Kevin

Well sure enough, this patch solves the problem.

]--- a/Makefile
]+++ b/Makefile
]@@ -112,8 +112,8 @@ endif
] # Do a whole file compile by textually including all C code.
] define whole-compile
] @echo   Compiling whole program $3
]-$(Q)printf '$(foreach i,$2,#include $(CURDIR)/$i\n)'  $3.tmp.c
]-$(Q)$(CC) $1 $(CFLAGSWHOLE) -c $3.tmp.c -o $3
]+$(Q)printf '$(foreach i,$2,#include $i\n)'  $3.tmp.c
]+$(Q)$(CC) -I$(CURDIR) $1 $(CFLAGSWHOLE) -c $3.tmp.c -o $3
] endef
] 
] %.strip.o: %.o


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] Problems with Linux payload

[Scott Duplichan]

Laszlo Ersek [mailto:ler...@redhat.com] wrote:

[snip]

]Can you hex-dump the guest memory too, in both cases, starting from
]0xf4b78+0x18, and from 0x1ffec000+0x18, respectively, for 0x8 bytes?
]This would provide the segment descriptor in each case that the selector
]value 0x18 references.

I thought of the same, but then saw that gdb is actually dumping those:

0018 000f  9b00 DPL=0 CS16 (causes reset)
0018   00c09300 DPL=0 DS   (works)

]In the resetting case, the segment descriptor referenced by selector
]value 0x18 is probably suitable for data segments, but inappropriate for
]the stack segment.

Exactly. In the passing case the selector is for a r/w data segment.
In the failing case, the selector is for an execute/read code segment.
While a code segment selector is valid for some segments, the stack segment
has some special checks:

IF SS is loaded
THEN
IF segment selector is NULL
THEN #GP(0); FI;
IF segment selector index is outside descriptor table limits
or segment selector's RPL ≠ CPL
or segment is not a writable data segment=
or DPL ≠ CPL
THEN #GP(selector); FI;

... So a GP fault. Weird that the load of the new GDT is getting
skipped, but stranger things have happened.
Thanks,
Scott


]Thanks
]Laszlo
]/ducks



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios