Booting arguments for NetBSD under qemu

[Torbjorn Granlund]

For good reasons (a course I give at KTH) I need to boot NetBSD sparc32
under qemu.

Recent NetBSD sparc32 releases do not cooperate well with qemu.
Therefore I use 5.2. I do not depend on the latest and greatest release
for the present use.

Installation goes like a charm, using this (slightly shortened) command:

qemu-system-sparc -m 256 -hda disk.img -cdrom sparccd-5.2.2.iso \
-boot d -nographic

Ideally,

qemu-system-sparc -m 256 -hda disk.img -nographic

would boot the installed system, but alas, it does not.

Instead, an explicit kernel argument is needed as in,

qemu-system-sparc -m 256 -hda disk.img -kernel netbsd-GENERIC
-nographic

where NetBSD-5.2.2/sparc/binary/kernel/netbsd-GENERIC.gz was used for
the kernel argument.

Unfortunately, this kernel asks for root device, dump device, and a few
more things. This makes automated booting hard.

I have tried hard to find how to pass suitable arguments to the kernel
from qemu, but have not come very far.

Specifically, I have not been able to find documentation of the possible
command line argument of netbsd-GENERIC. I have not found the place in
the kernel sources where kernel command line arguments are handled.

Please help with some advice.


Torbjörn

[Martin Husemann]

Post by Torbjorn Granlund
Recent NetBSD sparc32 releases do not cooperate well with qemu.

Can you share details?

We run automatic tests on qemu for sparc, see:

http://releng.netbsd.org/b5reports/sparc/

but this machine uses an older qemu version.

Post by Torbjorn Granlund
qemu-system-sparc -m 256 -hda disk.img -cdrom sparccd-5.2.2.iso \
-boot d -nographic
Ideally,
qemu-system-sparc -m 256 -hda disk.img -nographic
would boot the installed system, but alas, it does not.

The something went wrong during installation.

Btw, just for fun you might want to look at pkgsrc/misc/py-anita.
running it with the "interactive" command would give you a working system.

(Maybe check pkg options first, you may prefer a newer qemu which is optional
in that pkg.)

Martin

[Torbjorn Granlund]

Post by Torbjorn Granlund
Recent NetBSD sparc32 releases do not cooperate well with qemu.

Can you share details?

Sure. I'm using qemu 1.7.0 from pkgsrc, installed with pkgsrc from
2014-03-08.

Here is the full boot until death:

[Michael]

Hello,

On Fri, 11 Apr 2014 14:00:23 +0200

Post by Martin Husemann

Post by Torbjorn Granlund
Recent NetBSD sparc32 releases do not cooperate well with qemu.

Can you share details?
Sure. I'm using qemu 1.7.0 from pkgsrc, installed with pkgsrc from
2014-03-08.

By the look of it we crash when the tcx driver initializes the hardware.
So, does qemu actually emulate the hardware acceleration and cursor
sprite stuff? The driver will try to use both.
Any chance you could send me the device properties for your emulated
tcx? If there's anything to distinguish it from the real thing I could
just let the driver treat it as a dumb framebuffer when running under
qemu.

have fun
Michael

[Torbjorn Granlund]

Post by Torbjorn Granlund
For good reasons (a course I give at KTH) I need to boot NetBSD sparc32
under qemu.

What's your host (cpu and OS)?

CPU = Intel Sandybridge.

Post by Torbjorn Granlund
Instead, an explicit kernel argument is needed as in,
qemu-system-sparc -m 256 -hda disk.img -kernel netbsd-GENERIC
-nographic

I believe the -kernel option is only for a Linux guest.

Well, it allows me to boot netbsd-sparc32, except that I need to fill in
sd0a every time.


Torbjörn
Please encrypt, key id 0xC8601622

[Ottavio Caruso]

Post by Torbjorn Granlund
For good reasons (a course I give at KTH) I need to boot NetBSD sparc32
under qemu.

What's your host (cpu and OS)?

Post by Torbjorn Granlund
Instead, an explicit kernel argument is needed as in,
qemu-system-sparc -m 256 -hda disk.img -kernel netbsd-GENERIC
-nographic

I believe the -kernel option is only for a Linux guest.

[Torbjorn Granlund]

Torbjorn Granlund <***@gmplib.org> writes:

Installation goes like a charm, using this (slightly shortened) command:

qemu-system-sparc -m 256 -hda disk.img -cdrom sparccd-5.2.2.iso \
-boot d -nographic

Ideally,

qemu-system-sparc -m 256 -hda disk.img -nographic

would boot the installed system, but alas, it does not.

After many trials, and much help here and in private email, I decided to
update qemu from 1.7.0 to 1.7.1. This helped for a plain 5.2.2 install;
it can now boot from the newly installed disk.

Another solution would have been to compile a custom kernel with
adequate default root file system, as suggested by Martin Husemann.
Unfortunately, the currently recommended build.sh method for setting up
a NetBSD cross environment seems to have arrived after 5.2.2, and
building a kernel inside qemu might take a while.

Call me silly, I should have tried upgrading qemu first thing. I
didn't, since my experience is that upgrading qemu never helps (but
downgrading actually often does!).

(NetBSD 6.1.3 causes a crash in alst this newer qemu.)


Torbjörn
Please encrypt, key id 0xC8601622

[Manuel Bouyer]

Post by Torbjorn Granlund
[...]
Another solution would have been to compile a custom kernel with
adequate default root file system, as suggested by Martin Husemann.
Unfortunately, the currently recommended build.sh method for setting up
a NetBSD cross environment seems to have arrived after 5.2.2, and
building a kernel inside qemu might take a while.

no, netbsd-5 has build.sh as well. build.sh appeared in 2001,
the first release to have it was 1.6

[David Brownlee]

Post by Torbjorn Granlund
qemu-system-sparc -m 256 -hda disk.img -cdrom sparccd-5.2.2.iso \
-boot d -nographic
Ideally,
qemu-system-sparc -m 256 -hda disk.img -nographic
would boot the installed system, but alas, it does not.
After many trials, and much help here and in private email, I decided to
update qemu from 1.7.0 to 1.7.1. This helped for a plain 5.2.2 install;
it can now boot from the newly installed disk.
Another solution would have been to compile a custom kernel with
adequate default root file system, as suggested by Martin Husemann.
Unfortunately, the currently recommended build.sh method for setting up
a NetBSD cross environment seems to have arrived after 5.2.2, and
building a kernel inside qemu might take a while.

As lightly oddball variation might be to run through the install as normal, then
- boot qemu with a second virtual disk
- setup the 2nd disk as a RAID1 set with one element, set to
autoconfigure as root
- newfs, mount, copy the install across and install boot blocks
- then reboot with the 2nd disk configured as the only disk - it will
autoconfigure as root with a generic kernel

Somewhat convoluted, but it will Just Work after setup.

Post by Torbjorn Granlund
Call me silly, I should have tried upgrading qemu first thing. I
didn't, since my experience is that upgrading qemu never helps (but
downgrading actually often does!).
(NetBSD 6.1.3 causes a crash in alst this newer qemu.)

That is the more interesting question - have you submitted a bug
report for that?

Of course the real fix would be to see if NetBSD could be tweaked to
pickup the root device from a qemu install automatically, but I think
it would be best to investigate the 6.1.3 panic first...

[Torbjörn Granlund]

(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?

That a particular OS release fails to run under some qemu configuration
does not necessarily mean either is buggy.

And cloaking a feature request as a bug report is not my cup of tea.

But it would be great of somebody would volunteer and make more NetBSD
ports run under qemu!


Torbjörn
Please encrypt, key id 0xC8601622

[Andreas Gustafsson]

Post by David Brownlee

(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.

[David Brownlee]

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...
:)

Post by Andreas Gustafsson

Post by David Brownlee

(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.
--

[Michael]

Hello,

On Mon, 21 Apr 2014 19:32:19 +0100

Post by David Brownlee
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

That's the TCX's hardware cursor position register. Looks like qemu
doesn't actually emulate that part of TCX.

Post by David Brownlee
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...
:)

See above. A proper workaround would be to either add the missing bits
to qemu or find a way for our tcx driver to detect qemu and skip the
hardware that's not actually emulated.

have fun
Michael

[Michael]

Hello,

On Wed, 23 Apr 2014 15:39:42 +0100

Post by Michael
Hello,
On Mon, 21 Apr 2014 19:32:19 +0100

Post by David Brownlee
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

That's the TCX's hardware cursor position register. Looks like qemu
doesn't actually emulate that part of TCX.

The system boots fine when qemu is run "not -nographic", though it
attaches genfb so the tcx specific hardware is not touched...
presumably it might be expected to panic if someone runs X in that
case?

No, the xf86-video-suntcx driver won't attach without the kernel driver.

Should NetBSD be attaching tcx0 rather then genfb0 in the "not -nographic"?

If in the "not -nographics" everything works, why not?

Post by Michael

Post by David Brownlee
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...
:)

See above. A proper workaround would be to either add the missing bits
to qemu or find a way for our tcx driver to detect qemu and skip the
hardware that's not actually emulated.

Would the output of "ofctl -p" give any clues (attached). This is from
a "not -nographic" run from a HEAD kernel.

Actually the diff between "-nographics" and "not -nographics" would be more interesting.

have fun
Michael

[David Brownlee]

Post by Michael
Hello,
On Wed, 23 Apr 2014 15:39:42 +0100

Post by Michael
Hello,
On Mon, 21 Apr 2014 19:32:19 +0100

Post by David Brownlee
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

That's the TCX's hardware cursor position register. Looks like qemu
doesn't actually emulate that part of TCX.

The system boots fine when qemu is run "not -nographic", though it
attaches genfb so the tcx specific hardware is not touched...
presumably it might be expected to panic if someone runs X in that
case?

No, the xf86-video-suntcx driver won't attach without the kernel driver.

Should NetBSD be attaching tcx0 rather then genfb0 in the "not -nographic"?

If in the "not -nographics" everything works, why not?

My question was more "why does NetBSD try to attach tcx0 on a machine
with serial console and genfb on the same machine with graphical
console (albeit an emulated qemu machine). Should it not be trying to
attach tcx in box cases?

Post by Michael

Post by Michael

Post by David Brownlee
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...
:)

See above. A proper workaround would be to either add the missing bits
to qemu or find a way for our tcx driver to detect qemu and skip the
hardware that's not actually emulated.

Would the output of "ofctl -p" give any clues (attached). This is from
a "not -nographic" run from a HEAD kernel.

Actually the diff between "-nographics" and "not -nographics" would be more interesting.

That we can do. The "-nographics" case is with a kernel compiled without tcx0:
- http://sync.absd.org/sparc/qemu-ofctl-nographic.txt
- http://sync.absd.org/sparc/qemu-ofctl.txt

Thats... clever - the only difference to the tcx properties in the
-nographics case is that it is missing 'address'

[Michael]

Hello,

On Wed, 23 Apr 2014 23:41:33 +0100

Post by David Brownlee
My question was more "why does NetBSD try to attach tcx0 on a machine
with serial console and genfb on the same machine with graphical
console (albeit an emulated qemu machine). Should it not be trying to
attach tcx in box cases?

Because tcx was never updated to return a match score higher than 1.
I'll fix that in a minute.
Frankly I'm surprised that people actually use genfb at sbus, given its
lack of colour map control ( thanks to OBP < 3 not having a standard
method to do it... ) ;)

Post by David Brownlee

Post by Michael

Post by Michael

Post by David Brownlee
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...
:)

See above. A proper workaround would be to either add the missing bits
to qemu or find a way for our tcx driver to detect qemu and skip the
hardware that's not actually emulated.

Would the output of "ofctl -p" give any clues (attached). This is from
a "not -nographic" run from a HEAD kernel.

Actually the diff between "-nographics" and "not -nographics" would be more interesting.

- http://sync.absd.org/sparc/qemu-ofctl-nographic.txt
- http://sync.absd.org/sparc/qemu-ofctl.txt
Thats... clever - the only difference to the tcx properties in the
-nographics case is that it is missing 'address'

And that matches real OBP / OF - no need for the firmware to map the
framebuffer if it isn't going to scribble into it.
So qemu doesn't emulate a complete tcx in the -nographics case but it
doesn't really tell us. As a workaround I could check
for /packages/grubfs-files and skip tcx if that node is present and tcx
isn't the console. Looks more like a bug in qemu though.

have fun
Michael

[David Brownlee]

http://mail-index.netbsd.org/netbsd-users/2014/04/thread1.html#014442

Post by Michael
Hello,
On Wed, 23 Apr 2014 23:41:33 +0100

Post by David Brownlee
My question was more "why does NetBSD try to attach tcx0 on a machine
with serial console and genfb on the same machine with graphical
console (albeit an emulated qemu machine). Should it not be trying to
attach tcx in box cases?

Because tcx was never updated to return a match score higher than 1.
I'll fix that in a minute.
Frankly I'm surprised that people actually use genfb at sbus, given its
lack of colour map control ( thanks to OBP < 3 not having a standard
method to do it... ) ;)

I suspect that people have not chosen to do so - they are just picking
up on the default behaviour and didn't know there was a choice :)

With your above change qemu has consistent behaviour with or without
-nographic (which is good). Of course both of them now panic due to
qemu's incomplete implementation, which is less good... but one item
at a time...

Post by Michael

Post by David Brownlee
- http://sync.absd.org/sparc/qemu-ofctl-nographic.txt
- http://sync.absd.org/sparc/qemu-ofctl.txt
Thats... clever - the only difference to the tcx properties in the
-nographics case is that it is missing 'address'

And that matches real OBP / OF - no need for the firmware to map the
framebuffer if it isn't going to scribble into it.
So qemu doesn't emulate a complete tcx in the -nographics case but it
doesn't really tell us. As a workaround I could check
for /packages/grubfs-files and skip tcx if that node is present and tcx
isn't the console. Looks more like a bug in qemu though.

Should someone ping Mark Cave-Ayland <mark.cave-***@ilande.co.uk ?
I'm happy to just cc him into this thread with a few words, but if
someone else has already spoken to him about other items then it may
make more sense for them to raise it...

[David Brownlee]

Post by Michael
Hello,
On Mon, 21 Apr 2014 19:32:19 +0100

Post by David Brownlee
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

That's the TCX's hardware cursor position register. Looks like qemu
doesn't actually emulate that part of TCX.

The system boots fine when qemu is run "not -nographic", though it
attaches genfb so the tcx specific hardware is not touched...
presumably it might be expected to panic if someone runs X in that
case?

Should NetBSD be attaching tcx0 rather then genfb0 in the "not -nographic"?

Post by Michael

Post by David Brownlee
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...
:)

See above. A proper workaround would be to either add the missing bits
to qemu or find a way for our tcx driver to detect qemu and skip the
hardware that's not actually emulated.

Would the output of "ofctl -p" give any clues (attached). This is from
a "not -nographic" run from a HEAD kernel.