Re: [SeaBIOS] Problems with Linux payload
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
Re: [SeaBIOS] problem building from Windows using msys
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
[SeaBIOS] problem building from Windows using msys
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] [PATCH] Ctrl-Break support (INT 1B, etc)
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
Re: [SeaBIOS] Issues with ASRock E350M1
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] Consider a VGA to be active if it responds to either IO or memory access
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
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] non-emulated AHCI hardware
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] non-emulated AHCI hardware
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
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] [PATCH] Add config option to disable MTRRinitialization.
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