Miscellaneous

• DVB notes
• Samsung CLP-315W

Introduction

This HOWTO shows how to set up a test environment for debugging the NetBSD kernel with full debug symbols and source using a pair of QEMU virtual machines,

The Host System

You need a computer running NetBSD, Linux, or some other Unix-like OS, with at least 10 gigabytes of available disk space (the "host system"). These instructions have been most recently tested on a NetBSD/amd64 9.2 host system.

Install the following packages from pkgsrc:

• emulators/qemu
• misc/py-anita

If your host system doesn't have pkgsrc, you can use another package system to install qemu, the Python pexpect library, and genisoimage or mkisofs. Also download and install the most recent anita package from http://www.gson.org/netbsd/anita/download/.

The Target System

The target system is the NetBSD system whose kernel you want to debug. The examples below assume NetBSD-current/amd64, but the i386 port will also work; just replace each instance of "amd64" in the commands below by "i386", and "qemu-system-x86_64" by "qemu-system-i386".

Other NetBSD ports should also work in principle, but in practice none of them do, for various reasons: they are either not supported by QEMU, not supported by anita, supported by anita only using install media that lack debug or source sets, fail to install, or have networking issues when run under QEMU.

The host and target system do not need to be the same architecture.

Installing the Target System

Install the target system in a virtual machine, including the debug symbols and source code:

 $ anita --workdir work --disk-size 10G --memory-size 256M \
     --sets kern-GENERIC,modules,base,etc,comp,debug,games,man,misc,tests,text,syssrc,src,sharesrc,gnusrc \
     install http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/amd64/

This will produce a disk image in work/wd0.img.

Booting the VMs

Next, start two qemu virtual machines, one to run the kernel being debugged (the "target VM") and another to run the debugger (the "gdb VM").

The two VMs can run on the same host system and share a single hard disk image. The sharing is made possible by the qemu "-snapshot" option, which ensures that the disk image is treated as read-only by both VMs.

First start the target VM, enabling qemu's built-in GDB target stub on TCP port 1234:

 $ qemu-system-x86_64 -nographic -snapshot -hda work/wd0.img -m 256 -gdb tcp::1234

If you don't want everyone on the Internet to be able to debug your target, make sure incoming connections on port 1234 are blocked in your firewall.

In a second terminal window, start the gdb VM:

 $ qemu-system-x86_64 -nographic -snapshot -hda work/wd0.img -m 256

Log in to the gdb VM as root and set up the network. Use the -w option to dhcpcd to work around PR 56598:

 login: root
 # dhcpcd -w

Start gdb on the gdb VM and connect to the target:

 # gdb /netbsd
 (gdb) target remote my.host:1234

where my.host is the domain name or IP address of the host system. Note that specifying localhost or 127.0.0.1 will not work because they mean the GDB VM itself, not the host.

Now you should be able to get a stack trace and start debugging with full debug symbols and access to the source code:

 (gdb) where
 (gdb) list

Qemu Tips

Here is a couple of useful qemu commands to know:

• Ctrl-a b will send a break which will make the NetBSD VM enter the ddb kernel debugger.

• Ctrl-a c will switch to the qemu monitor where you can enter commands like "quit" to exit qemu, or do things like saving/restoring the VM to/from a file.

Open Sound System for NetBSD

This page shows the progress of the porting of OSSv4 to NetBSD.

Update

It's not known if anyone is continuing to work on a native port of OSSv4, but this page is kept for archival purposes.

NetBSD 10 should have greater compatibility with OSSv4 via the userspace translation layer ossaudio(3), and the native audio system audio(4) is still preferred.

Version

The current version is v4.2 (hg-889)

Status

• DMA: ported (not complete)
• PCI config access: complete
• PCI mapping: ported to bus_space
• INB/OUTB: incomplete (should use bus_space(9))
• module support: WIP
• Locking: ported to mutex(9)
• MALLOC: ported to kmem(9)
• getid: ported to kauth(9)
• pkg: incomplete
• compat_audio: not yet

FAQ

What works?

Loading osscore.kmod works. Loading virtal drivers work.

No functional testing has been done yet.

Who is working on it?

ahoka@

Where to get it?

You will need devel/mercurial and lang/gawk and devel/gmake to build it.

Browse online: http://bitbucket.org/ahoka/oss4-netbsd/

To get it:

hg clone http://bitbucket.org/ahoka/oss4-netbsd

How to build it?

http://www.opensound.com/wiki/index.php/Building_OSSv4_from_source

I use this to build modules:

rm -rf /tmp/ossbuild
mkdir /tmp/ossbuild
cd /tmp/ossbuild

/home/ahoka/mercurial.opensound.com/configure

gmake build

cd prototype/usr/lib/oss/build/
sh install.sh

Proplib is an API/lib to create, handle and store property lists. It was created by Apple but NetBSD also have a clean room implementation in the system, and it's mostly used for implementing sysctl interfaces. It's a somehow limited implementation to make it faster/smaller (maybe extended in the future as demands grow). Here's a little example code to show some of the basics:

This will create a dictionary and store it as an xml file on the disk:

int
main(void)
{
    prop_dictionary_t d;
    bool r;

    d = prop_dictionary_create();

    if (d == NULL)
        goto error;

    r = prop_dictionary_set_cstring(d, "name", "Adam");
    if (!r)
        goto error;
    r = prop_dictionary_set_uint32(d, "year", 1986);
    if (!r)
        goto error;

    r = prop_dictionary_externalize_to_file(d, "test.plist");
    if (!r)
        goto error;

    return EXIT_SUCCESS;

    error :
        fprintf(stderr, "error\n");
        return EXIT_FAILURE;
}

And this will read it and display the values:

int
main(void)
{
    prop_dictionary_t d;
    uint32_t year;
    char *name;
    bool r;

    d = prop_dictionary_internalize_from_file("test.plist");
    if (d == NULL)
        goto error;

    r = prop_dictionary_get_cstring(d, "name", &name);
    if (!r)
        goto error;
    r = prop_dictionary_get_uint32(d, "year", &year);
    if (!r)
        goto error;

    printf("name: %s, year: %u\n", name, year);

    return EXIT_SUCCESS;

    error :
        fprintf(stderr, "error\n");
        return EXIT_FAILURE;
}

Example usage of various NetBSD APIs.

wcfb

wsfb* at pci?

This driver supports some (all?) 3Dlabs Wildcat graphics boards as an unaccelerated framebuffer console in 8 bit colour. It's been tested on ?sparc64 only, with XVR-500 and XVR-1200 boards. Others, like the XVR-600, may or may not work.
Currently it is not possible to run X, mostly because of the insane state we get the hardware in - there are two buffers and WID plane, the WID plane contains garbage so it's unpredictable which pixel is drawn from what buffer and so far nobody could figure out how to access the WID plane. The wcfb driver gets around this by doing every operation on a shadow framebuffer in main memory and then copying the results into both buffers on the graphics board. An ?Xorg driver that does the same has yet to be written.

cgtwelve

cgtwelve* at sbus?

This driver supports Sun CG12 / Matrox SG3 graphics boards.
The card ( if you can call it a card - in fact it's two cards on top of each other which occupy three ?SBus slots ) supports 1, 8, 12 and 24 bit visuals with 2D and 3D acceleration ( which we don't know how to use, yet ), the console runs in 1 bit monochrome since that's what the firmware sets up, ?Xorg with the ?wsfb driver will run in 24 bit colour.

agten

agten* at sbus?

This driver provides an accelerated, 8bit colour console on Fujitsu AG-10e graphics boards with all the usual ?wsdisplay features. ?Xorg support in 24 bit colour is provided by the ?xf86-video-ag10e driver.

genfb

genfb* at pci?
genfb* at sbus?

The genfb driver provides an unaccelerated framebuffer console on graphics cards set up by the firmware ( usually ?OpenFirmware ) but which are otherwise unsupported. Since it has no knowledge of the underlying graphics hardware whatsoever it relies on device properties to tell it where to find the framebuffer and what the current video mode's geometry is, this requires machine dependent code to extract this information and hand it to genfb. Currently this is implemented for ?macppc and ?sparc64.
On ?SBus systems there is no need for any such translation code, but many cards use non-standard properties ( AG-10e for example ), pass wrong parameters ( CG12 claims 32bit depth even though the address property points at a monochrome framebuffer ) and there is no widely supported way to change palette registers, so use of this driver with ?SBus hardware is only recommended if there is absolutely no other driver for your ?SBus graphics card. On ?PCI systems things look much better - the 'color!' method is pretty much universally supported and most cards I have seen so far set their properties in a sane way. Of course there are still exceptions ( Sun's wildcat cards don't provide a sane address property and the PGX32 passes a wrong value in linebytes ) but these seem to be rare on Sun hardware and nonexistent on PCI Macs. Native drivers and/or workarounds exist for all known exceptions.
?Xorg with the ?wsfb driver will run in whatever mode and colour depth the console uses.

The main motivation for writing genfb was to provide a machine independent replacement for ?macppc's ofb driver which supports all the ?wsdisplay goodies and doesn't suffer from ofb's cache problems. It can also be used on ?i386 and ?amd64 where it supersedes the vesafb driver - mode setting via VBE has been moved to machine dependent code.

See also

agten - a driver for the AG-10e
cgtwelve - a driver for the CG12
pm2fb - an accelerated driver for the PGX32
wcfb - a driver for 3Dlabs Wildcat graphics boards