On Sun, Feb 21, 2010 at 04:18:38PM -0700, Brandon Bennett wrote:
> > On Sat, Feb 20, 2010 at 9:05 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> >> Should a kernel fail during boot, I'd suspect it doesn't like one of
> >> the apm/pcibios callbacks, or it doesn't like one of the
> >> smbios/mptable/acpi tables. You could try compiling the SeaBIOS code
> >> (see http://seabios.org/Download ) and increasing the debugging by
> >> …
[View More]modifying src/config.h. Specifically, you could increase
> >> CONFIG_DEBUG_LEVEL, and set DEBUG_HDL_pcibios32 and DEBUG_HDL_apm to
> >> 1. Also, you could try disabling some of the features to see if that
> >> prevents the fault (eg, disabling CONFIG_ACPI / CONFIG_SMBIOS /
> >> CONFIG_MPTABLE).
> >
>
> I have narrowed it down to SMBIOS. If I disable CONFIG_SMBIOS the
> image boots up fine.
Gleb, have you seen this thread?
Some of the recent changes to smbios that look like possible culprits
are:
Make SMBIOS table pass MS SVVP test
Use MaxCountCPUs during building of per cpu tables.
Add malloc_high/fseg() and rework bios table creation to use them.
There were other changes, but the comments indicate they were only
ports of changes already in bochs. I suppose it's also possible the
lack of smbios is turning off some other feature in the guest (eg,
acpi) that's the real culprit.
-Kevin
[View Less]
I have tried SeaBIOS 0.5.1 on Bochs cvs with FreeDOS 1.0 Final boot floppy.
Loading from floppy was utterly slow and then FreeDOS dumped
Invalid Opcode at 0013 0000 0202 800F 01F3 20F4 10AA 10AA 109A 0000 0000 0000 00
00
Bad or missing Command Interpreter: A:\COMMAND.COM A:\ /E:2048 /F /MSG /P=A:\FRE
EDOS\FDAUTO.BAT
Enter the full shell command line:
Bochs log has
00477945139i[BIOS ] Booting from Floppy...
00510608951i[BIOS ] Booting from 0000:7c00
05264161428i[FDD ] controller reset in …
[View More]software
05445136148i[FDD ] controller reset in software
05625186768i[FDD ] controller reset in software
05803824012i[FDD ] controller reset in software
05985259728i[FDD ] controller reset in software
05985285461i[CPU0 ] LOCK prefix unallowed (op1=0x53, attr=0x0, mod=0x0, nnn=0)
Same floppy and Bochs version work fine and fast with Bochs BIOS.
Any clues?
- Sebastian
[View Less]
On Mon, Feb 22, 2010 at 02:56:22AM +0000, Natalia Portillo wrote:
> Ok, QEMU is absolutely unable to boot nextstep/openstep, while using
> SeaBIOS.
>
> Changing to old Bochs BIOS, makes it work, however no video is
> output (until NeXT starts using VESA).
Hi Natalia,
Is nextstep/openstep something that can be freely downloaded?
It would help if you can extract some SeaBIOS debugging info. I've
uploaded a SeaBIOS image with the debug level set to 8 and serial
debugging …
[View More]enabled. It is at:
http://linuxtogo.org/~kevin/SeaBIOS/test/bios.bin-0.5.1-debug-20100228
Can you use this image with qemu, add "-serial file:mylog" to qemu's
command line, and forward the resulting "mylog" file back?
Also, please include the full qemu command line that you used.
Thanks,
-Kevin
[View Less]
I found that the QEMU USB keyboard support does not work properly with
the Set_Idle command. Once a non-zero value is given to Set_Idle,
then the keyboard reports an event on every poll - not based on the
time issued in the Set_Idle command.
I changed the code (see patch below) and it works for me. I'm not
that familiar with the qemu internals, so I'm not sure if this is the
best way to implement this feature.
-Kevin
diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index 4f320d7..bf456bb 100644
--…
[View More]- a/hw/usb-hid.c
+++ b/hw/usb-hid.c
@@ -66,6 +66,7 @@ typedef struct USBHIDState {
int kind;
int protocol;
uint8_t idle;
+ int64_t next_idle_clock;
int changed;
void *datain_opaque;
void (*datain)(void *);
@@ -630,6 +631,11 @@ static void usb_keyboard_handle_reset(USBDevice *dev)
s->protocol = 1;
}
+static void usb_hid_set_next_idle(USBHIDState *s, int64_t curtime)
+{
+ s->next_idle_clock = curtime + (get_ticks_per_sec() * s->idle * 4) / 1000;
+}
+
static int usb_hid_handle_control(USBDevice *dev, int request, int value,
int index, int length, uint8_t *data)
{
@@ -795,6 +801,7 @@ static int usb_hid_handle_control(USBDevice *dev, int request, int value,
break;
case SET_IDLE:
s->idle = (uint8_t) (value >> 8);
+ usb_hid_set_next_idle(s, qemu_get_clock(vm_clock));
ret = 0;
break;
default:
@@ -813,9 +820,10 @@ static int usb_hid_handle_data(USBDevice *dev, USBPacket *p)
switch(p->pid) {
case USB_TOKEN_IN:
if (p->devep == 1) {
- /* TODO: Implement finite idle delays. */
- if (!(s->changed || s->idle))
+ int64_t curtime = qemu_get_clock(vm_clock);
+ if (!s->changed && (!s->idle || s->next_idle_clock - curtime > 0))
return USB_RET_NAK;
+ usb_hid_set_next_idle(s, curtime);
s->changed = 0;
if (s->kind == USB_MOUSE)
ret = usb_mouse_poll(s, p->data, p->len);
[View Less]
This patch series adds the ability to boot from USB flash drives. The
first seven patches are just cleanups. The eighth adds the MSC
support.
This is only preliminary support - I've booted under qemu using a
"-usbdevice disk:foo" drive, and I've also booted my epia-cn with
seabios and coreboot. However, handling of error conditions and
timers still needs to be improved. Also, the current support is UHCI
only (no ohci).
Further testing on real hardware would be appreciated.
-Kevin
Kevin …
[View More]O'Connor (8):
Dynamically allocate each drive_g with malloc_fseg().
Move common "command data block" functions to new file blockcmd.c.
Don't require a valid physical cylinders/heads/spt for logical
mapping.
Fix off by one error in strtcpy.
Minor - arrange struct drive_s to clarify field roles.
USB UHCI cleanups.
Introduce helper functions for finding USB end-points.
Initial support for booting from USB drives.
Makefile | 4 +-
src/ata.c | 36 +++-----
src/biosvar.h | 6 +-
src/block.c | 69 ++++++---------
src/blockcmd.c | 78 +++++++++++++++++
src/blockcmd.h | 19 ++++
src/boot.c | 2 +-
src/cdrom.c | 69 ++++-----------
src/config.h | 6 +-
src/disk.h | 33 +++----
src/floppy.c | 7 +-
src/usb-hid.c | 26 ++----
src/usb-msc.c | 261 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
src/usb-msc.h | 25 ++++++
src/usb-uhci.c | 142 +++++++++++++++++++++++++++++--
src/usb-uhci.h | 4 +-
src/usb.c | 81 +++++++++++++++++-
src/usb.h | 6 ++
src/util.c | 2 +-
19 files changed, 706 insertions(+), 170 deletions(-)
create mode 100644 src/blockcmd.c
create mode 100644 src/usb-msc.c
create mode 100644 src/usb-msc.h
[View Less]
Hi All,
I have an Intel/Truxton (Tolapai/EP80579) type platform that I am
using coreboot and seabios on. Up to now I have been using a
pre-compiled binary from Kevin's download site:
http://linuxtogo.org/~kevin/SeaBIOS/seabios-0.5.1.tar.gz
and that has been working fine. (The coreboot is modified to
support some changes on this particular hardware platform).
Now the problem is that I want to generate seabios binaries from
source. And I can't seem to be able to compile a working one.
My …
[View More]host build system is a Ubuntu 9.10 x86_64 install (using the most
up to date packages). This a gcc-4.4.1 and binutils-2.20 setup.
If I get the source seabios-0.5.1 package from Kevin's download
page and compile that I end up with a bios.bin.elf that is:
-rwxr-xr-x 1 gerg gerg 1048716 2010-02-17 15:11 bios.bin.elf
Hmm, rather large :-) The actual contents maybe ok:
out/bios.bin.elf: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00013000 000ed000 000ed000 000ed000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
The file offset is looking bad here.
If I instead use a binutils-2.18 "ld" that I have lying around
(doing "make LD=i386-linux-ld") then I end up with a more
reasonable sized bios.bin.elf of 82060 bytes. But this bios.bin.elf
just hangs after being loaded by coreboot on my target.
I tried compiling this same seabios version (0.5.1) on an older
Fedora Core 9 system (also an x86_64 install), and again that produced
a non-working bios.bin.elf.
I also got the latest seabios git tree and tried that. I also couldn't
get a working seabios binary using that either.
What versions of gcc/binutils do others use?
Does anyone have any ideas where by building could be going wrong?
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg(a)snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
[View Less]