NetBSD 7.0 is released
The NetBSD Project is pleased to announce NetBSD 7.0, the fifteenth major
release of the NetBSD operating system.
The last release is quite some time ago, but given a philosophy of
"it is ready when it is ready" and the amount of work that
went into it, this is a very good reason to celebrate!
official release announcement
for a long list of hilights and harder to notice changes.
Also, there is an article on
What to expect in NetBSD 7
which also describes many of the new features, changes
and bugfixes in NetBSD 7.
Interview with Jeff Rizzo on NetBSD 7.0
The polish Sektor BSD page has
an interview with Jeff Rizzo on NetBSD 7.0
online. With the NetBSD 7.0 release around the corner, this is good timing!
The interview is available in both english and polish language, and starts
off a series of NetBSD-related interviews.
Have a look!
Of course it runs ... pkgsrc - NASA's Pleiades Supercomputer
flew by on twitter, thanks to imil:
NASA uses pkgsrc on their Pleiades supercomputer.
the NASA page,
``Pleiades, one of the world's most powerful supercomputers, represents NASA's state-of-the-art technology for meeting the agency's supercomputing requirements, enabling NASA scientists and engineers to conduct modeling and simulation for NASA missions. This distributed-memory SGI ICE cluster is connected with InfiniBand in a dual-plane hypercube technology.
The system contains the following types of Intel Xeon processors: E5-2680v3 (Haswell), E5-2680v2 (Ivy Bridge), E5-2670 (Sandy Bridge), and X5670 (Westmere). Pleiades is named after the astronomical open star cluster of the same name. ''
The system architecture consists of 163 racks of machines
from SGI (still alive!) with Suse Linux as their operating system. Check
for all the juicy details!
More information on
Using Software in the NetBSD Packages Collection (pkgsrc)
is available from the NASA Knowledge base.
And you'd think NASA using NetBSD would be the last
cool thing they do. :-)
[Tags: nasa, pkgsrc, pleiades]
Interview with NetBSD's Christos Zoulas
DragonFly BSD Digest
that there is an
interview with Christos Zoulas
The interview is available in
Christos us currently a mamber of the boards of directors of
the NetBSD Foundation, as well as the foundation's
secretary and treasurer. Besides the administrative tasks
he has a long history of technical involvement in the project,
like the Core group that he is also a member of.
Liste to the interview to learn more!
[Tags: bsdtalk, christos]
Making my RPI serial console work, or: fixing a hardware problem in software
Some time ago I get a Raspberry Pi, but never really got it working:
I don't have a HDMI display, and wanted to use the serial console.
Unfortunately the "official" RPI-serial-to-USB cable had an annoying
effect for me: while I saw output just fine, I wasn't able to type
anything! Funny enough, this was not only in NetBSD but also Debian.
Which took the blame from NetBSD :)
Picture 1 shows the cabling.
So the blame was on the RPI-USB-to-serial cable, and I looked into making
my own. I have a standard USB-to-serial adapter, but that one cannot
be connected pin-by-pin to the RPI, as they use different voltage
levels. While the "standard" serial UART protocol (RS-323) encodes 0s and 1s as
5V and -5V, the RPI uses TTL voltage between 0 and 3.3V - a simple 1:1
connection sounds like a bad idea. Converters like the MAX3232 are
available: it connects the TX and RX lines and adjusts the voltage
levels. To operate, power and ground are provided by the RPI. After
frobbing this together (see picture 2)
I found out that - surprise - the problem was not in the cable either,
as my home-made cable also did not work for input, only for output.
After some detour (frobbing the image-build process to make me an
image that not only has working DHCP and SSH, but that actually let's
me log in), I got the crucial hint what was going on:
Having lines for sending and receiving data is nice, but what if one
end's receiver is full and wants to signal that? This is called "flow
control", and apparently with no lines for that, hardware
flow control is not an option. In theory there is a software
solution (sending XON/XOFF bytes), which requires equal settings on
both sides. Apparently the RPI doesn't do that either, and with the
default settings on my NetBSD host to wait for an XON before sending
data, things didn't match up - no XON from the RPI, no data going to
it. Plain and simple - if you know what's going on.
The fix was easy, and thanks go to
Domelevo Entfellner for the hint: disable flow control in my
terminal program (kermit). So with a simple "set flow none", things
work like a charm now. Voila, another hardware problem fixed in
How to look at serial interface parameters from NetBSD? Use the
command. Here's the default output for my USB-to-serial interface
attached to ttyU0:
# stty -f /dev/ttyU0
ispeed 0 baud; ospeed 9600 baud;
lflags: echoe echoke echoctl
oflags: onocr onlret
cflags: cs8 -parenb
The difference is obvious when running the same command while kermit
runs with proper settings in a different window:
# stty -f /dev/ttyU0
speed 115200 baud;
lflags: -icanon -isig -iexten -echo echoe echoke echoctl
iflags: -icrnl -ixon -ixany ignbrk ignpar
oflags: -opost onocr onlret
cflags: cs8 -parenb clocal
Not only is the speed different, but most important "-ixon" tells the
interface to not wait for an XON on input (iflags) before transmitting
For reference sake, here is my .kermitrc that I use:
# cat .kermrc
# Raspberry PI
set carrier-watch off
set line /dev/ttyU0
set flow none # disable hardware flow control
set speed 115200
#set speed 9600
Picture 1: The standard RPI-USB-to-serial cable (click to enlarge)
Picture 2: My own USB-to-serial adapter using a MAX3232 chip (click to enlarge)
[Tags: hardware, hubertf, max3232, raspberrypi, rs323, serial, stty, tty, ucom, usb]
NetBSD on NVIDIA Jetson TK1 (Tegra K1)
I'm losing count of all those spiffy ARM systems that NetBSD
runs on, but here's a fancy one to take note.
Quoting shamelessly from
Jared McNeill's email,
``Jetson TK1 is a Tegra K1 (quad core Cortex-A15) development board from NVIDIA. Possibly the fastest ARM board that NetBSD supports now.
Still working on HDMI, and need to track down an issue that prevents eMMC from working (but the SD card slot works fine). The board is also capable of USB3 but for now we have routed the USB ports to the USB2 controller.''
Besides being a nice ARM platform, it should not go unnoticed
that besides the quad-core ARM Cortex-A15 CPU, the system also
has a NVIDIA Kepler GPU with a whopping 192 CUDA cores.
Any takers to get those going with NetBSD?
More information is available on
the NVIDIA Jetson TK1 page
NVIDIA's embedded computing developers' site .
Also, check out the
information on how to buy a Jetson TK1 DevKit.
Now who's first to
upload their dmesg? :-)
[Tags: jetson, nvidia, tegra, tk1]
BSD dmesg collection service
I'm always into serious dmesg pr0n,
and apparently there's a hub collecting those
that I've missed so far, ran by the fine folks from NYCBUG:
By default it lists the latest submissions of a number of
BSD variants, but it's also possible to just get
everyone's favourite easily.
To submit a dmesg of NetBSD running on your favourite
hardware (or software / virtualization, of course),
a webpage to add your own dmesg.
statistics are available.
Check it out!
New binary releases for NetBSD on Raspberry Pi, including 7.0 RC1
NetBSD runs on many machnes, and the Raspberry Pi is one of them.
Getting the stock distribution is not that easy, and to help
in getting things going, Jun Ebihara is providing
ready-made images for quite some time.
There are images available that are
based on the latest development snapshot,
NetBSD-curent, and with the NetBSD 7.0 release
around the corner, there is also
an image based on NetBSD 7.0 Release Candidat 1.
the NetBSD wiki
for many more details,
and if you use your RPI for any cool hacks, be sure
[Tags: arm, pkgsrc, raspberrypi, Releases]
Announcing first Release Candidate for NetBSD 7.0 (7.0_RC1)
The NetBSD-7 release branch is in preparation for quite some
time now, and now
the first release candidate of NetBSD 7.0 is available.
Release engineer Soren Jabson writes:
``Many changes have been made since 6.0. Here are a few highlights:
Binaries of NetBSD 7.0_RC1 are available for download at:
- Greatly improved support for modern Intel and Radeon graphics hardware
through a port of the Linux DRM/KMS code. Most X.Org components have
been updated as well.
- ARM multiprocessor support
- Support for new ARM boards, some of which are listed below:
- Raspberry Pi 2
- BeagleBone Black
- Banana Pi
- Cubieboard 2
- Merii Hummingbird
- Marvell ARMADA XP
- GlobalScale MiraBox
- Sharp Netwalker PC-Z1
- GPT support in sysinst
- Lua kernel scripting
- Multiprocessor USB stack
- Many improvements to NPF, the NetBSD packet filter
- GCC 4.8.4 (and optionally, LLVM/Clang 3.6.1)
Those who prefer to build from source can either use the netbsd-7-0-RC1
tag or follow the netbsd-7 branch.
Please help us out by testing 7.0_RC1. We love any and all feedback.
Report problems through the usual channels (submit a PR or write to the
appropriate list). More general feedback is welcome at
releng@NetBSD.org. Your input will help us put the finishing touches on
what promises to be a great release! ''
Dell Networking OS 9 powered by NetBSD
I've stumbled across this somewhere on Facebook in the
japanese version, but this information is
available in english as well
from the Dell website:
``Designed to deliver high performance in the largest and most demanding IT environments in the world, Dell Networking OS 9 has been tested and hardened to meet stringent requirements for reliability, scalability and serviceability. OS 9 supports the full portfolio of Dell Networking data center switch products and enables you to build cost-effective, end-to-end networks while reducing operational complexity.
OS 9 leverages a distributed multiprocessor architecture that ensures reliability and delivers scalable protocols in each Dell Networking product line. Dell Networking E-Series and Z-Series route processor modules (RPMs) are designed with separate control-plane CPUs for Layer 2, Layer 3 and management functions, with distributed processing on line-card CPUs. Dell Networking C-Series RPMs and S-Series switches and routers use one control-plane CPU, with distributed processing on C-Series line cards and S-Series stack members.
The NetBSD kernel provides a stable operating system and performs efficient resource management via the HAL architecture, allowing it to deliver superior levels of concurrency, memory allocation and process scheduling. All other applications run as independent and modular processes in their own protected memory space.''
I guess this came in to dell via
Force 10 Networks,
which has a
track record of using NetBSD.
[Tags: dell, force10, Products]
Grab the RSS-feed,
or go back to my regular NetBSD page
Disclaimer: All opinion expressed here is purely my own.
No responsibility is taken for anything.