NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Booting arguments for NetBSD under qemu



So a quick test with qemu 1.7.1 and 2.0.0:

NetBSD 5.2.2 -nographic attaches the framebuffer as tcx0:

% qemu-system-sparc -boot d -m 256 -hda disk.img -cdrom
sparccd-5.2.2.iso -nographic
[...]
tcx0 at sbus0 slot 3 offset 0x800000 level 5 (ipl 9): SUNW,tcx, 1024 x
768, id 0, rev 0, sense 0
tcx0: attached to /dev/fb0

NetBSD 6.1.4 -nographic panics in the same way as your 6.1.3 experience:

% qemu-system-sparc -m 256 -hda disk.img -cdrom NetBSD-6.1.4-sparc.iso
-boot d -nographic
[...]
tcx0 at sbus0 slot 3 offset 0x800000 level 5 (ipl 9) (8bit only
TCX)tcx0: SUNW,tcx, 1024 x 768, id 0, rev 0, sense 0system[0]: trap
0x29: pc=0xf00abe2c sfsr=0xb6 sfva=0x8fc
cpu0: data fault: pc=0xf00abe2c addr=0x8fc
sfsr=0xb6<PERR=0x0,LVL=0x0,AT=0x5,FT=0x5,FAV,OW>
panic: kernel fault

NetBSD 6.1.4 without -nographic boots fine (albeit with black text on
a dark grey background). Specifically it attaches the framebuffer as:

% qemu-system-sparc -m 256 -hda disk.img -cdrom NetBSD-6.1.4-sparc.iso
-boot d -nographic
[...]
genfb0 at sbus0 slot 3 offset 0x800000 level 5 (ipl 9)

qemu-2.0.0 introduces the option to emulate a cg3 rather than a tcx. so...:

% qemu-system-sparc -m 256 -hda disk.img -boot d -c
drom NetBSD-6.1.4-sparc.iso -nographic -vga cg3
[...]
cgthree0 at sbus0 slot 3 offset 0x0 level 9: SUNW,501-1415, 1024 x 768
cgthree0: attached to /dev/fb0

So an immediate workaround to enable running NetBSD-6.x would be to
update to qemu-2.0.0 and use "-vga cg3", meanwhile someone can have a
poke at NetBSD and see why -nographic and emulated tcx have issues...
:)


On 21 April 2014 11:31, Andreas Gustafsson <gson%gson.org@localhost> wrote:
> Torbjörn Granlund wrote:
>> David Brownlee <abs%absd.org@localhost> writes:
>>
>>   > (NetBSD 6.1.3 causes a crash in also this newer qemu.)
>>
>>   That is the more interesting question - have you submitted a bug
>>   report for that?
>>
>> To whom?
>
> I'd say to both.  I think it would be useful both for future versions
> of NetBSD to run under today's qemu, and for future versions of qemu
> to be able to run today's version of NetBSD.
> --
> Andreas Gustafsson, gson%gson.org@localhost


Home | Main Index | Thread Index | Old Index