Update of NetBSD on the Raspberry Pi
Time has passed since
the last status update
of NetBSD on the Raspberry Pi, and things
have evolved:
Recent news include drivers for
USB with its many possible devices and display, allowing
X to be ran - check out
the screenshots provided by Jun Ebihara!
There is also
this posting on the port-arm mailinglist
that gives details on
an updates kernel image, Xorg.conf file to get X going
and more news hidden in that thread.
Anyone up for compiling a comprehensive
NetBSD/RaspberryPi webpage,
maybe on
the NetBSD Wiki?
NetBSD on the Raspberry Pi
The
Raspberry Pi
is a pretty recent, cheap ARM-based board, or as the
webpage
says: ``An ARM GNU/Linux box for $25''.
Shipping with today's Windows-for-embedde-boards
operating system (AKA Linux), there's also a port of
NetBSD on its way.
Nick Hudson is at it, and he has posted first
dmesg output
now, showing the machine going to multiuser mode.
The code's not integrated into mainline NetBSD-current yet,
but rest assured that that will happen when the code is ripe.
Good work, Nick!
More dmesg pr0n: NetBDS/Xen with 128 (virtual) CPUs
There was discussion about raising the number of
CPU(core)s supported by NetBSD the other day,
as the current limit of 32 isn't the sky any more
in 2012. In the process, Xen-hacker Manuel Bouyer
suggested using booting NetBSD ins a Xen DomU,
as you can assign up to 128 (virtual) cores to
a DomU.
So, how to go beyone 128 CPUs for testing?
Anyone played with Qemu recently, or even have some decent
hardware at hand? If so, be sure to post dmesg output
(and CC: me)!
Detailled setup instructions are available
on the port-arm mailing list
and
Paul's homepage.
Paul is also looking for feedback on the port, so if
you have a Mini2440 board, give it a spin and report back to Paul!
NetBSD ketchup - news from my mailbox
Here's another bunch of NetBSD-related news that has
been lingering in my inbox for far too long:
Izumi Tsutsui's
NetBSD/cobalt
restore CD is available based on NetBSD versions
5.0.25.1_RC2.
See the
for information on what it is and how to use it.
A negative symbol lookup cache was added
to NetBSD's loader
for shared libraries and shared objects, ld.so_elf, by
Roy Marples:
``I've been researching why Evolution from GNOME takes over 5 minutes to load on my quad core amd64 beast. It boils down to dlsym looking for a symbol that does not exist directly and as such examining every needed library. However, the current implementation does not remember what libraries it as already checked. Normally this isn't a problem, but with the way Evolution is built the search chain is massive.
[...]
With this patch, Evolution (without the patches to and a glib I added to pkgsrc a few days ago) loads in under 2 seconds (5 seconds with initial disk thrashing). ''
The NetBSD Logo
is available in many variants, but a new variant was submitted
via www@ these days by "Tim" - which is actually plain HTML,
no image:
⚑NetBSD Powered!
SafeNet's ProtectDrive is
``a full disk encryption solution that encrypts the entire hard drive of laptops, workstations and servers, as well as USB flash drives, to protect data in the case of the theft or loss of a hardware device.''
How do you implement such preboot authentication and
harddisk encryption software,
esp. if you want to provide thinks like LDAP integration for
the user/key handling and two-factor authentication?
Little is known, but rumors say the 32bit version of the software
is based on NetBSD, as is backed by
this worker bio info:
``Duties: Working on pre-boot restricted environment with loads before operation system and implemented on NetBSD.
Ported and optimized the KDrive X server to NetBSD.
Developed and implemented user secure authentication interface with smart card support.
Environment and tools : NetBSD (3.0), C/C++, FLTK''
A german-language introduction of pkgsrc on OpenSolaris
was given by Michael 'kvedulv' Moll at the Munich
OpenSolaris User Group back in march.
Slides
and a
video
are available.
Are you still looking for a nice small
ARM-based board to start hacking on NetBSD/arm?
The http://www.friendlyarm.net/products/mini2440
may be a good start, esp. after
Paul Fleischer is reaching completion of NetBSD support
for the board. Citing from
his mail to port-arm:
``I have now fairly good (i.e., it works for me) support for the
MINI2440 on NetBSD with support for the following:
- S3C2440 UART
- DM9000 (MAC+PHY)
- S3C2440 SD Controller
- S3C2440 DMA Controller
- S3C2440 IIS Controller
- FriendlyArm 3,5" LCD Display
- S3C2440 USB Host Controller (OHCI)
- S3C2440 Touch Screen
- UDA1341TS audio codec
Currently, support for three things on the S3C2440 are missing:
- S3C2440 NAND Controller
- S3C2440 USB Device Controller
- S3C2440 RTC
I've also created a stage2 bootloader for use with u-boot, which
ensures that the value of bootargs is passed to the NetBSD kernel.
At this point I have only tested the code with the 64Mb version of the
FriendlyArm MINI2440.
While talking about NetBSD on cool hardware:
How about NetBSD/hpcarm on
WILLCOM | W-ZERO3 (WS004SH) mobile devices?
Here is a screenshot of Ebihara-san's WS011SH with CCW screen,
and there is also a video "booting NetBSD/hpcarm on WILLCOM | W-ZERO3(WS004SH)"
posted on YouTube:
Unfilling my inbox: NetBSD news from the past few weeks - ACPI, NUMA, Xen, and more
Herre are some more things that I've caught in my inbox for too long,
and I'm finally finding some time
to sum them up here:
NetBSD's "let's move kernel parts to the userland" RUMP
project is still under heavy development, and in order
to make testing of compatibility after kernel changes easier,
a new command "rumptest" was added to build.sh:
``Basically you say:
Where yourargs are what have you, e.g. '-U -u -o -O /objs'.
The latter builds only the rump kernel libs and uses some ld+awk magic
to figure out if things go right or not. This is to avoid having to
install headers and build libs (which is too slow since a full build is
too slow). The magic is not a substitute for a full build, but it is
n+1 times faster and works probably 99.9% of the time.
The scheme uses a number of predefined component sets
(e.g. tmpfs+vfs+rumpkern) to test linkage. They are currently listed
in build.sh. This area probably needs some work in the future. It would
be nice to autogenerate the combinations somehow.
''
See Antti's
Antti's mail to tech-kern:
on how to tell if things didn't go so well, and what to do in that case.
According to
Wikipedia,
``Non-Uniform Memory Access or Non-Uniform Memory Architecture (NUMA) is a computer memory design used in multiprocessors, where the memory access time depends on the memory location relative to a processor. Under NUMA, a processor can access its own local memory faster than non-local memory, that is, memory local to another processor or memory shared between processors.''
Supporting NUMA in a contemporary (i.e.: Intel centric)
SMP-enabled operating system requires following a bunch
of standards, two of which are
parsing of two tables, the System Resource Affinity Table (SRAT)
and the
System Locality Information Table (SLIT).
Both tables are accessible via
the
Advanced Configuration and Power Interface (ACPI), and according
to the
German-language Wikipedia,
the SRAT is used to assign local memory to local threads
to boost their performance, and the SLIT defines the
"distance" of the nodes among themselves, which is used to
determine the "nearest" memory if local memory is not
enough.
Now, Christop Egger has posted patches to add
an ACPI SLIT parser
and
an ACPI SRAT parser.
See the two postings for
dmesg pr0n from his tests on an 8-node system.
Staying with ACPI and Christoph Egger, he found that even
though the ACPI spec defines an ACPI device for fans,
BIOS vendors and OEMs do their own thing.
To accommodate things like the fan sensor found in
the ACPI Thermal Zone in his HP Pavillion DV9700 laptop
he has
proposed a driver
to extend the acpitz(4) driver with fan information.
That way, envstat(8) can be used to display the ran's
RPMs:
The documentation covers how to enable the
Direct Rendering Manager (DRI), setting up and configuring
Modular X.org, assuring that everything's in place, and
how to get
Compitz going. Mmm, wobbly windows at last! :-)
While we're talking funky desktop stuff: Marc Balmer has
submitted
a patch to get touchpanel support for ums(4).
ums(4) is for USB mice, and in contrast to mice, touch panels need
to deal with absolute numbers, not relative numbers.
Back to the guts of the kernel, another patch suggested
by Christop Egger was for
adding x2apic. What is x2apic?
X2APIC is
``an Intel-only feature but can also be found
in virtual environments with support for CPU apic id's > 0xff.
I.e. Xen 4.0 (not yet released) supports 128 CPUs in HVM guests
with the CPUs enumerated with even apic id's. That means you need
x2apic for the 128th CPU :)
''
Install Mercurial, check out latest Xen
sources, apply a bunch of patches, build and install.
Examples of commands are given, in addition to changes
required for /boot.cfg etc.
Last one for today: Michal Gladecki,
Editor-in-Chief of BSD Magazine
writes:
``We are happy to announce that BSD Magazine is transforming into a free monthly online publication. The online version of BSD Magazine will stay in the same quality and form. It will look like the BSD magazine one is familiar and comfortable with. Please sign up to our newsletter at www.bsdmag.org and get every issue straight to your inbox. Also, you can now download any of the previous issues from our website. The first online issue -- 2/2010 -- is coming out in February. Please spread the word about BSD Magazine. ''
Click!
So much for today. I still have a bunch of news items
in my inbox for next time, but let's call it
good for today.
Unrelated, I've been playing with git a bit over the
past few days, and wile I have a number of questions building up
(which will be subject to tech-repository or so), what I
can say today is that the speed of "git pull" with
NetBSD's git repository and my 1MBit DSL line reminds me
a lot of the times when I used SUP with my 56k modem
- it took forever, too. :-(
Article: Thread scheduling and related interfaces in NetBSD 5.0
Mindaugas Rasiukevicius has worked in the SMP corner of the
NetBSD kernel in the past few months, and he has written
an article that introduces the work done by him and others,
see
his posting
for a bit more information, or
his article directly.
The article introduces real-time scheduling and the scheduling
classes found in NetBSD 5.0, and gives an estimate on the
response timeframe that can be expected for real-time applications.
Setting scheduling policy and priority from a userland
application is shown next, and programming examples for
thread affinity, dynamic CPU sets and processor sets are
shown. Besires C APIs, there are also a number or new commands
in NetBSD 5.0 that can be used to control things from the command
line, e.g. to define scheduling behaviour and manipulate
processor sets. My favourite gem is the CPU used in the
cpuctl(8) example, which is identified as "AMD Engineering Sample". :-)
New hardware support: Gumstix Verde, Lenovo ThinkPad ethernet
After NetBSD supports the
Gumstix boards
for quite some time now, support for the
Gumstix Verde
models is on its way:
Kiyohara Takashi has
posted
that he has realized support for a number of hardware devices, including
USB host mode, LCD, ethernet, and a MicroSD card driver.
While talking about hardware support, an ever changing area is
the devices put into consumer hardware like laptops. So far,
the Intel 82567LM Gigabit card found in machines like the
Dell Optiplex 760 and Lenovo's ThinkPad T400 was not supported.
Support for that is now ported from OpenBSD to NetBSD by
Kouichirou Hiratsuka. See
his posting
for diffs and dmesg output.
SMP on OpenFirmware based PowerPC machines in-tree
There's more to SMP than just Intel- and -compatible machines.
PowerPC-hackers Tim Rightnour and Matt Thomas have added support for SMP on
OpenFirmware based PowerPC machines, i.e. the
NetBSD/ofppc port.
The support is already committed to the NetBSD-current source tree,
and Tim has posted
the dmesg output of a 4-CPU machine, an
IBM 7044-270.
He also notes that this is the first PowerPC machine with
four processors to ever run NetBSD.
Catching up: portability, mult, Freescale i.mx31, fortunes, growfs, SMP, IIJ SEIL/X
I've had a bunch of things sit here, some a bit dated, some brand
new. I'll put them all into one item here due to lazyness:
Following Wikipedia, Portability is
``the general characteristic of being readily transportable from one location to another'', and it's also
a major goal of NetBSD.
Things start to get interesting when looking into details, e.g.
Wikipedia also
states that ``Software is portable when the cost of porting it to a new platform is less than the cost of writing it from scratch. The lower the cost of porting software, relative to its implementation cost, the more portable it is said to be.''
So there's some room for interpretation when defining what is
portable and what is not, and to what extent.
Besides my essay on
What makes an operating system portable,
there was a
posting
to the netbsd-advocacy mailing-list that goes into a few
details on NetBSD's current state of portability.
The posting lists a number of reasons why the author considers
NetBSD to be portable, including the low effort to start new
projects, central maintenance in one source tree, and the efforts
from machine-independent changes to all ports.
After reading about people doing research on how to
assess "security" of operating systems by counting number
of exploits and how quick they are patched, I wonder if
there are some metrics out there to also put "portability"
into numbers.
I've mentioned
the mult project
some time ago. In one of their latest recordings, there's also
a interview with its creator,
Kristaps Dzonsons, on it on
BSDtalk, available in
mp3
and
ogg formats. Thanks to Mark Weinem for the hint!
To give new users hints on how to use NetBSD, Jeremy C. Reed has
started
a netbsd-tips fortune database. It's part of NetBSD-current
and can be run from .login/.profile by running "fortune netbsd-tips".
There's also a
wiki page that allows easy submitting of
new entries. Feel free to contribute your special NetBSD gems!
NetBSD's handling of harddisks and file systems is pretty static
right now - while one can add additional disks to a system,
and even span them using RAIDframe and ccd(4), extending the
filesystem on top of it is a problem. This is being mitigated
by Juan Romero Pardines' port of growfs(8): ``I've just adapted growfs(8) from OpenBSD (they adapted the FreeBSD code),
which is able to grow FFSv1 and FFSv2 filesystems.
I tested growing a partition in FFSv1 and FFSv2 from 1GB to 4GB and the
process was smooth (and fast); after this I ran 'fsck_ffs -yf /fs' and it
found one error that was fixed correctly.''
For more information, including where to get the code and what
to test, see Juan's posting.
There were a few attempts to get logical volume management (LVM)
onto NetBSD, which were not successful so far. This may change
in the future, and when flexible handling of storage volumes,
with growfs(8) will be useful to manage FFS/UFS file system
sitting on top of them.
When needing sources for some Open Source package, I've used
"make extract NO_DEPENDS=1" with pkgsrc in the past. It
seems that was removed without further notice, and
Obata Akio was kind enough to
point out
that this can be done now by using SKIP_DEPENDS=yes.
Mmm, interface stability...
Last but not least a note from the "products based on NetBSD"
department:
Saitoh Masanobu from
IIJ, Japan, has
notified us that
the SEIL/X series that IIJ unveils at AsiaBSDCon 2008 is based on NetBSD.
There's a
brochure on SEIL/X that mentions a long
list of features supported by the machine, including all
state of chw art in routing, bridging, VPN, firewalling,
quality of service and more.
This is made possible by the "SEIL Engine", a software
architecture that's based on NetBSD that allows porting
the application stack to a number of hardware platforms
easily, while offering flexibility to add support for
custom hardware and software modules:
For more information on the SEIL Engine, see IIJ/SEIL's
homepage (Japanese).
and
PDF brochude (English).
Cobalt Qube 2700 progress
Izumi Tsutsui has made progress on getting NetBSD/cobalt
going on the
Cobalt Qube 2700,
the "original" cube and first product released by Cobalt Networks back then.
Interesting nit from the wikipedia page: apparently the "2700" model number
came from the atonic number of cobalt: 27.
The company was later on purchased by Sun Microsystems, which still
has things like
the Qube 2700 manual online.
Izumi got the machine going to a point where it can be
booted from network and the internal IDE disk,
show the dmesg output, and talk to the built-in
LCS display. See Izumi's messages
here and
here
for more information.
Instructions for installing NetBSD on the NSLU2
NetBSD/arm supports installing on the Linksys NSLU2 (also known as "slug")
for some time now. Installation's a bit bumpy though, and after some
experimenting Donald T. Hayford has
posted instructions
for building and installing NetBSD on the NSLU2
(and a minor update), including dmesg pr0n.
NetBSD ported to the IBM 7044-270 (POWER3-II cpu)
PowerPC-hacker Tim Rightnour was at it again, and this time he
has added support for
IBM's 7044-270 POWER3-II based machines
to
NetBSD/ofppc.
See
Tim's posting
for more information including details on the port, status, and
dmesg output.
NetBSD ported to the IBM MCA RS/6000 model 7006
Tim Rightnour has reworked NetBSD's powerpc-ports recently, and
with support from Kevin Bowling and he has announced the
NetBSD port to the IBM MCA RS/6000 model 7006
now, which makes NetBSD the first free Operating System to run on this
class of machines:
``The port was made to an IBM 7006-41T, which is a 601-based machine with MCA.
It has not yet been tested on any other machines, but most other MCA/PowerPC
based machines should be supportable. This port does not yet run on the
7012-3xx class of machines, or any other machine that has a POWER, POWER-RSC,
POWER2 or POWER2-SC CPU. POWER-class machines will require significant CPU
code to be written.
This port does not cover PReP-based IBM RS/6000 machines, for those, please see
port-prep. For OpenFirmware based RS/6000 machines, please see port-ofppc.''
See
Tim's posting
for more information on machines that are likely to run this port with
more or less effort, the state of the port, how to rebuild from NetBSD's
source, and a sample dmesg output.
Rebirth of NetBSD's ofppc port
Tim Rightnour has worked a lot on NetBSD's PowerPC ports recently,
providing infrastructure works for common pieces of hardware found
on several platforms. While there, the NetBSD port to machines
with an OpenFirmware interface to the hardware
was revived, to
allow running NetBSD on machines like the Genesi Pegasos II.
See
Tim's posting
for some more details and a dmesg output of his machine.
NetBSD's new PowerPC-developer Frank Wille also has the port running,
and he
reports
that he has the Pegasos system running in multiuser mode with
no stability problems.
Status: NetBSD on Xen/amd64
Manuel Bouyer has worked on making NetBSD working on Xen on
the amd64 platform, and he has it has made some substantial
progress, see
his status mail.
A
dmesg output
is also available.
Installing *BSD on PX-EH40L (AKA "landisk")
Joel Carnat has written some detailed
instructions on how to get NetBSD/landisk going
on Plextor PX-EH40L, which is the European hardware for
NetBSD/landisk, i.e. a SH4-based machine.
Update: NetBSD on wgt624v3
Jared McNeill has a hobby of
hacking NetBSD in shape
to work on the
Netgear WGT624v3
on and off. He got a working kernel build with
minimal modifications and got the system booting
with working Atheros wlan support now, see the
dmesg output.
Using your Xbox 360 HD DVD drive with NetBSD
Jared McNeill bounced me this gem: The Xbox 360 comes with an external
HD DVD drive that's connected to the Xbox via USB. Using the drive on
a NetBSD box via USB is easy, but accessing the data on the HD DVDs
was not possible so far. After Reinoud Zandijk's
last
round of changes to the UDF filesystem driver to bring it upto UDF 2.60,
the Xbox 360 HD DVDs' data can now be accessed from NetBSD:
Please note that while the HD DVDs' can now be accessed, it is still
encrypted, but it's a start. Jared tells me:
``Basically, the video files on the disc are encrypted and wrapped in an
MPEG
program stream. You need to extract the title key (also encrypted) from the
disc to be able to decrypt the program streams. The video may be either
MPEG2, VC-1, or H.264. I can't remember off the top of my head what formats
are allowed for audio''.
The changes to UDF should theoretically work for BluRay DVDs also, but
this hasn't been confirmed due to lack of hardware - maybe someone can
send some feedback on this? Reinoud has the following to say about this:
``BluRay discs have most likely UDF 2.60 filesystem on them since this is
the first standard that mentions this disc type. For BD-ROM and BD-RE this
should be equal to version 2.50. On BD-R either VAT or logical overwrite is
used but for read-only access this shouldn't differ. Testing it of course
would be good.''
Reinoud also points out that the next points on his roadmap include
optical disc formatting, creating newfs_udf(8), fsck_udf(8) and write
support.
NetBSD/Xbox progress
Andrew Gillham has been working on
a port of NetBSD to the Microsoft Xbox games console,
and he has sent
a status report with request for help
and
dmesg output.
There's also
a test kernel available, with some instructions on how to boot it.
Seems an Xbox with a mod chip is needed, though.
NetBSD/zaurus
Several people are currently working on a port of
NetBSD to the
Sharp Zaurus,
and Nonaka Kimihiro has posted a dmesg about getting to
multiuser now, plus a link to a set of sources. See
his mail to the port-arm list
for more data.
Post mortem debugging, or: what happened before it crashed? (Updated)
So your machine paniced, and as you were running X you have no
clue what went on? Here's a nice way to find out, assuming you have
a kernel crash dump. To ensure the latter, set
kern.dump_on_panic=1 in /etc/sysctl.conf.
Now, what to do with those crashdumps?
% ls -l /var/crash/
total 3183838
-rw-r--r-- 1 root wheel 3 Nov 2 02:09 bounds
-rw-r--r-- 1 root wheel 5 Jun 30 2004 minfree
...
-rw------- 1 root wheel 181265401 Nov 2 02:11 netbsd.26.core.gz
-rw------- 1 root wheel 2162696 Nov 2 02:11 netbsd.26.gz
In /var/crash, "bounds" contains an increasing counter for the
crashdump number (it would be "27" in the above example),
and "minfree" contains the minimum amount of free space
in kilobytes that should keep free - both files are read by
savecore(8) when /etc/rc.conf has "savecore=yes", which is
the default.
The actual crashdump consists of two gzipped files - the
actual memory dump "netbsd.XX.core.gz" and a copy of the
running kernel "netbsd.xx.gz". After uncompressing the
files can be used for looking at the system at the point
of it's panic:
# gunzip netbsd.26*.gz
#
Note that the crashdump may contain sensitive data and is such
only readable by root!
The crashdump can be read by programs that use libkvm to
read through the crashdump's kernel memory, e.g.
gdb(1), dmesg(8), ps(1), fstat(8), ipcs(1), netstat(8), nfsstat(8),
pmap(1), w(1), pstat(8), vmstat(8) etc.,
using the -M and -N switches.
Some examples:
To show the system's message buffer at the time
of the crash:
Attach the GNU debugger gdb(1) to the system crash dumpQ,
to poke around deeply:
% gdb netbsd.26
...
(gdb) target kcore netbsd.26.core
panic: blkfree: freeing free block
#0 0x0ac04000 in ?? ()
(gdb) bt
#0 0x0ac04000 in ?? ()
#1 0xc03084b5 in cpu_reboot ()
#2 0xc02a57aa in panic ()
#3 0xc0313127 in trap ()
#4 0xc0102dfd in calltrap ()
#5 0xc0182544 in db_get_value ()
#6 0xc03058f1 in db_stack_trace_print ()
#7 0xc02a577c in panic ()
#8 0xc0205db7 in ffs_blkfree ()
#9 0xc020b8d5 in ffs_indirtrunc ()
...
Unfortunately there are a number of programs that I
didn't get to work with my crashdump, but that may be
due to its point after/during system shutdown, e.g.
ps(1) didn't work.
Still that should give some start for poking around...
Update: Apparently 'target kcore' was renamed
to 'target kvm' in gdb6, see
this posting.
Quad Dual Core dmesg
George Georgalis is playing with a quad Dual-Core machine,
i.e. 4 CPUs with 2 CPU-cores per CPU. After upgrading to
-current for decent support of his IDE controller, he has
posted an updated dmesg output.
Yummy!
NetBSD on Intel MacMini - report and dmesg
Peter Seebach has given NetBSD on his Intel-based MacMini a try.
Given Apple's different approach to things like BIOS and MBR
partition tables this was a bit funky, but using BootCamp he has
succeeded
and also
posted a dmesg output.
NetBSD/amd64 on Shuttle SN27P2 report
Quentin Garnier has installed NetBSD/amd64 on a Shuttle SN27P2.
Hardware support was pretty good, with some funky experiences in the
land of X - see
Quentin's mail
for the full report, including a link to the
dmesg output.
I guess so much for the "NetBSD is only good for old hardware" nonsense...
Wanna try wedges?
When you want to move a disk between different systems, this may not
be so easy at all: Even if you use the FFS_EI kernel option for endian
independence, the target system is pretty likely to not even see any
partitions as their native disk partitioning scheme is different:
While NetBSD uses a 'disklabel' internally and even manages to map that
onto its native partitions on some systems, on others the firmware
may just not recognize the on-disk structure. This happens when you move disks
between SPARCs, SGIs, PCs, Amigas, Ataris etc. - they all have their
own on-disk schemes, which NetBSD tries to read for the native ports, but
doesn't manage to read for 'foreign' disks.
Now this is where 'wedges' come into play: The idea is to have a library
of partitioning schemes that allow mapping various systems' formats
into a internal disklabel (wedge).
The original idea of this goes back to 1998(!) and was
suggested by Charles Hannum.
Unfortunately the work was never completed, and
Jason Thorpe picked it up in 2004 and mostly completed the work, see
his status report.
Again some bits were left, and this time it's Christos Zoulas who
went to fight the dragon^Wwedge code, and he has some success to report:
``if you want to try wedges on i386/x86_64:
1. cvs update
2. run with the new MAKEDEV in /dev: sh MAKEDEV dk10
3. Add the following to your kernel:
options DKWEDGE_AUTODISCOVER
options DKWEDGE_METHOD_BSDLABEL
options DKWEDGE_METHOD_GPT
options DKWEDGE_METHOD_MBR
4. reboot with the new kernel in single user mode.
5. replace wd/sd in your /etc/fstab with dk
you are all set, you are using wedges.
all your disks are dkN.''
Here is some example dmesg output:
wd0: Returned 7(7) wedges
wd0: Looking for wd0a in wd0j
wd0: Looking for wd0a in wd0i
wd0: Looking for wd0a in wd0h
wd0: Looking for wd0a in wd0g
wd0: Looking for wd0a in wd0f
wd0: Looking for wd0a in wd0b
wd0: Looking for wd0a in wd0a
wd0: Setting boot wedge dk0 (wd0a) at 61705665 133119
opendisk: can't open dev dk1 (19)
opendisk: can't open dev dk2 (19)
opendisk: can't open dev dk3 (19)
opendisk: can't open dev dk4 (19)
opendisk: can't open dev dk5 (19)
opendisk: can't open dev dk6 (19)
boot device: dk0 (wd0)
root on dk0
A bit verbose yet, but that'll change.
You'll need latest NetBSD-current (i.e. 4.99.something) from
today for thist to try (now there's your first "what's new in
NetBSD 5.0" item :-). Please post your experiences to current-users@NetBSD.org!
P.S.: A full dmesg is available
here. Thanks Christos!
Poll: Would YOU like to see NetBSD on a Meshcube? Or on an AVM Fritzbox? (Update #2)
Garrett D'Amore has started working on getting NetBSD
to support the
4G Access Cube (formerly known as Meshcube),
and he's currently running a
poll on the port-mips@ list
to see if there would be enough interest to prod
the manufacturer into sending him hardware to
make sure the port works fine.
As I'm looking for something to hold my DSL line (i.e. to run
PPPoE) with two ethernets, a USB v2.0 (fast!) port
and maybe a harddisk, I'd take one (assuming the
Cube can do that... unfortunately their specs are
not very clear :-/)
If the hardware sounds sexy to you, be sure to send mail to Garrett!
Updates:
First, Martin Husemann has posted a
dmesg output
of his Meshcube, and some of the caveats of the
machine were mentioned: price ($700), USB1.1 only,
no connector for second ethernet(!), funky serial connector.
On the brigt side, Garrett also
offered
to look into getting NetBSD to run on an
AVM Fritzbox,
and with a price of less than 200EUR for
something that has 4* ethernet, USB and WLAN that
sounds pretty good. (Not to mention the support for
DSL, POTS and ISDN on the SoC, but I doubt NetBSD has any
support in that area... yet?). The offer of Garret requires
availability of docs (which I am
hopeful for
the CPU/SoC
as well as for some
Linux sources to peek at),
plus for someone to send him hardware. Any takers for
supporthing this thing? I'd throw in 50EUR, drop me (hubertf@NetBSD.org)
mail if you want to see NetBSD run on this fine hardware, too!
Update #2:
Asking 4G systems about the price of the Meshcube/Accesscube
resulted in them telling me that they don't offer
the hardware any more. Well, I'd prefer a port to the
AVM box anyways. ;))
NetBSD on Olimex CS-EP930x board (Updated)
The
Olimex CS-EP930x boards
are development boards for EP9301 ARM920T microcontrollers with USB,
RS232, ethernet and SD/MMC connectors.
Ivan Vasilev got NetBSD/evbarm booting on such a board, see
the dmesg output
and
his mail netbsd-ports@
for more information.
NetBSD ported to Sun JavaStation Espresso
Julian Coleman wrote to the port-sparc mailing list that
``[w]ith help from uwe@, port-sparc now boots single user on the JavaStation
Espresso. Minor modifications were needed to the PCI and interrupt mapping
code, as the Espresso is very similar to the (already supported) Krups.''
See
Julian's mail
for more information including a dmesg output.
More information on the hardware is available
in the Linux on the Sun JavaStation NC HOWTO,
which tells us that an Espresso is
``extremely rare to find. It was never available for sale in quantities to either the general public or the initial JavaStation deployments, limiting the model's production quantity. To call this "Generation Three" of the JavaStation may be improper, as Espresso is nothing like the generation three JavaStation written about in early Sun marketing literature.
The Espresso was designed as an extension of the Krups. It was geared to sites that wanted a little bit more functionality and expansion capability from their JavaStations: a cross between an NC and a workstation.
Espresso is powered by the same 110Mhz MicroSPARC IIep chip as Krups . It's mainboard is similar to Krups, with the addition of PCI slots and an IDE channel for local hard disks. The IDE on Espresso was not enabled in the demo units. Those who have tried to make it work have concluded the wiring is incorrect, and it requires a hardware rework to get going.
Espresso continues with the PS2 keyboard and PS2 mouse ports from Mr. Coffee and Krups.
Espresso uses the same 168-pin, 3.3V unbuffered EDO DIMMs as Krups. The maximum amount of memory for Espresso is reported to be 96MB. As with the Mr. Coffee and Krups , the number "xx" in the Sun option number refers to the amount of memory shipped with the unit.
For video display, the Espresso uses the PCI-based IGS C2000 framebuffer, along with the same standard VGA port connector as Krups and Mr. Coffee. The on-board audio remains a Crystal CS4231 chip like Krups, and the network interface remains a Sun HappyMeal 10/100 Mbps interface like Krups as well.
Espresso came with the 9-pin serial port and 1/8" audio out and 1/8" audio in jacks of Krups, and a new addition of a parallel port, and a second 9-pin serial port. Espresso also comes with the flash memory to load your OS on and bypass the network boot cycle.
One new addition to the Espresso is a smart card slot. ''
They also have a
picture of the machine.
NetBSD 3.0 boots on PowerMac G5!
Sanjay Lal has ported NetBSD 3.0 to the PowerMac G5.
Diffs are in the process of being cleaned up and will
hopefully be posted soon. In the mean time, there's
a dmesg output available - see
Sanjay's posting to the port-macppc list.
There's also a project to
port NetBSD to the G5 architecture
during NetBSD and Google's Summer-of-Code. We'll see how the
two projects related, and if duplicate work can be avoided
by specifying deliverables for the SoC project appropriately.
Stay tuned!
Port to Xilinx Virtex series FPGAs w/ integrated PowerPC 405
Jachym Holecek has ported NetBSD to the IBM 405 CPU core embedded
in Xilinx Virtex {2-Pro, 4 FX} series FPGAs. See
Jachym's mail
for more details on the supported hardware as well as a
dmesg(8) output showing the list of supported devices.
dmesgs: NetBSD/Xen in qemu
Being a qemu-whore^W^W^Wlazy, I wanted to play with Xen, but
never found the hardware to do so. Once again, qemu came to the
rescue, and following the fine
NetBSD/Xen howto, I managed to setup Xen in
qemu.
Setup and configuration was dead easy, and NetBSD comes with some
excellent infrastructure to setup a machine that starts up multiple
domUs automatically, by simply adding the needed config files into
/usr/pkg/etc/xen.
Harddisk usage of the 1GB disk is, in dom0:
two 180MB disk images for the domU filesystems, mounted via vnd(4).
About 100MB of additional packages are installed to manage Xen plus
some other things pulled in to support that (Python, Perl and lots of
modules), 100MB for X, some 200MB for a full installation of NetBSD
3.0/i386 (used on the Xen kernel) which includes development and
text processing environment, documentation and manpages.
The rest of the disk is dedicated to swap.
The system is setup to use grub as bootloader, which offers booting
either a 'regular' NetBSD/i386 kernel (i.e. no Xen), or the Xen
hypervison, which then boots a NetBSD/Xen kernel, that uses
the NetBSD/i386 userland to boot.
After the system has booted to multiuser mode, started the two
domUs, and after logging in as root, the domU consoles can be
accessed by telnetting to localhost port 9601 and 9602,
respectively. Networking for the domUs is setup in the domU config
files: all domUs, the dom0 plus the physical ethernet interface
are all plugged into a (virtual) switch (implemented via bridge(4)),
which is then bridged to the "normal" ethernet - Voila, network
for all domains!
Installation of a Xen domU with NetBSD works by creating a
harddisk image, and then using the INSTALL_XENU kernel,
which boots right into an installer that can then be
used to install NetBSD on the disk(image). Installation
sets can be fetched using the local network e.g. via
FTP from dom0.
Of course after setting up one domU harddisk image, setting
up the other one is a mere "cp img1 img2", with some small
changes for hostname and SSH keys etc.
In summary, I'm very impressed by the "roundness" of the
Xen integration into NetBSD - no hacking, just add config
files, disk images, and off you go.
nVidia nForce ethernet support
NVidia is not exactly known for opening up specifications for
their hardware, and besides their graphics cards, buyers of
their network cards or mainboards with those cards onboard have a
problem. Support for NVidia's nForce ethernet controllers
as e.g. found in some "Shuttle" computers was a problem for a long
time, but it seems progress is finally there via the
pkgsrc/sysutils/nvnet
package. It's still only available as external driver via a LKM,
but at least that's better than nothing.
A success report with dmesg output
is also available.
Of course having full specs to write a proper driver would be
ways preferred over this.
Anyone got such a system for me (preferably including colocation)?
I'd love to use it to compile binary pkgs for NetBSD
(as we didn't get a blade cluster by HP ;)
7-CPU SunFire V40Z dmesg (Update #1)
I must have missed
this dmesg-excerpt
of a SunFire V40z with a bunch (4?) Dual-Core Opterons
running the world's most portable operating system.
Update #1: Silly me, I've read some subjects about Sun V40Z
this week but couldn't remember or research them when I found and
wrote the above. Thanks to Brett Lymn for pointing me at his mail with
the
complete dmesg of that machine.
Seeing that it takes eight 2GHz CPUs to chew for a full hour before
spitting out a NetBSD release seems pretty tough though...
Time to de-bloat this OS. :)
(In another mail,
Greg Oster posted about a machine with four slightly faster
CPUs, which apparently took about 35 minutes to build a release
without X... am I the only one missing some things here?).
NetBSD on MacMini - dmesg
Apparently the most effort in porting NetBSD to the newly announced
Apple MacMini was getting the hardware. Matt Thomas got one, and
has posted a mail with the dmesg output of NetBSD on the MacMini
to the port-macppc list. Anyone got one for me? :)
NetBSD/amd64 2.0_BETA runs fine on a Sun Fire V20z (updated)
Hauke Fath has confirmed
that NetBSD 2.0_BETA/amd64 works fine on a Sun Fire V20z in SMP mode. Yow!
Paul Fleischer has 
