NetBSD Bloghttps://blog.netbsd.org/tnf/feed/entries/atom2024-03-17T12:20:22+00:00Apache Roller (incubating)https://blog.netbsd.org/tnf/entry/netbsd_10_0_beta_availableNetBSD 10.0 BETA availableNia Alarie2022-12-20T18:19:04+00:002022-12-21T09:08:32+00:00<p>After nearly <a href="https://www.youtube.com/watch?v=fNlxFh43V-w">3 whole years</a> of development (work started on NetBSD 10 in late 2019), BETA snapshots have finally been published for interested users to test. More changes will be backported from the development branch over the next few months before we tag a final release, so the BETA images will keep getting updated.</p><p>After nearly <a href="https://www.youtube.com/watch?v=fNlxFh43V-w">3 whole years</a> of development (work started on NetBSD 10 in late 2019), BETA snapshots have finally been published for interested users to test. More changes will be backported from the development branch over the next few months before we tag a final release, so the BETA images will keep getting updated.</p>
<h3>What to expect</h3>
<p>While NetBSD 10.0 is expected to be a major milestone on performance, especially on multi-core systems, currently the BETA builds have some extra kernel diagnostics enabled that may reduce performance somewhat.</p>
<p>Among the features you can expect to find in NetBSD 10 are reworked cryptography, including compatibility with WireGuardⓇ, automatic swap encryption, new disk encryption methods, and CPU acceleration in the kernel. In hardware support, there are updated GPU drivers from Linux 5.6, support for more ARM hardware (including Rockchip RK356X, NXP i.MX 8M, Amlogic G12, <a href="https://wiki.netbsd.org/ports/evbarm/apple/">Apple M1</a>, and Raspberry Pi 4), support for new security features found in the latest ARM CPUs, and support for Realtek 2.5 gigabit and new Intel 10/25/40 gigabit ethernet adapters. compat_linux has been ported to AArch64 and DTrace has been ported to MIPS. For retrocomputing enthusiasts, there's improved multiprocessor support on Alpha, and more iMac G5 support. The Xen hypervisor support has received a major rework. There are various new userspace programs, including blkdiscard(8) to manually TRIM a disk, aiomixer(1) to control audio volume, realpath(1), and fsck_udf(8). And loads more...</p>
<p>There are many little details that might be relevant to admins when upgrading from NetBSD 9, so <strong>wait and read the final release announcement before you upgrade any production systems</strong>. Please note that networking setups using tap(4) as a bridge endpoint must be modified to use vether(4) instead, and compat_linux is no longer built into the kernel for security reasons (load it as a module instead). DisplayPort and HDMI audio is now enabled in the default x86 kernel, so you might need to change the default audio device with audiocfg(1) if you're not getting any sound output. blacklistd(8) was renamed to blocklistd(8).</p>
<h3>Downloads</h3>
<ul>
<li> <a href="https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/images/NetBSD-10.0_BETA-amd64-install.img.gz">Installation / USB stick image for 64-bit x86 (hybrid UEFI/BIOS image)</a>. Use gunzip and dd to write an .img.gz file on Unix, or Rawrite32 on Windows.</li>
<li> <a href="https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/images/NetBSD-10.0_BETA-amd64-bios-install.img.gz">Installation / USB stick image for 64-bit x86 (legacy BIOS only)</a></li>
<li><a href="https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/images/NetBSD-10.0_BETA-i386-install.img.gz">Installation / USB stick image for 32-bit x86</a></li>
<li><a href="https://armbsd.org">For images for various ARM devices, see armbsd.org</a>. All Arm boards without UFEI or Raspberry Pi firmware also require U-Boot to be written the SD card separately when using a generic image.</li>
<li> <a href="https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/evbarm-earmv6hf/binary/gzimg/rpi.img.gz">Live image for Raspberry Pi 0 or 1</a></li>
<li> <a href="https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/evbmips-mips64eb/binary/gzimg/octeon.img.gz">Live image for Cavium Octeon</a> (also needs U-Boot)</li>
<li> <a href="https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/images/NetBSD-10.0_BETA-amd64.iso">CD/DVD image for 64-bit x86</a> (for actual CD/DVDs and virtual machines only)</li>
<li> <a href="https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/images/NetBSD-10.0_BETA-i386.iso">CD/DVD image for 32-bit x86</a></li>
<li> <a href="https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/images/NetBSD-10.0_BETA-evbarm-aarch64.iso">CD/DVD image for 64-bit Arm virtual machines</a></li>
<li> <a href="https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/images/NetBSD-10.0_BETA-sparc64.iso">CD/DVD image for SPARC64</a></li>
<li> <a href="https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/images/NetBSD-10.0_BETA-alpha.iso">CD/DVD image for Alpha</a></li>
<li> <a href="https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/images/">More? (e.g. Apple PowerPC/68K, Amiga, Dreamcast, PA-RISC, SGI MIPS, SPARC32, VAX...)</a></li>
</ul>
<h3>Packages</h3>
<p>Third-party software is available from <a href="https://pkgsrc.org">pkgsrc</a>, as ever. <a href="http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/10.0_2022Q3/">Binary packages are available for amd64</a>, and I hope to publish binaries for i386 shortly.</p>
<h3>Reporting bugs</h3>
<p><a href="http://www.netbsd.org/cgi-bin/sendpr.cgi?gndb=netbsd"><strong>You can report bugs here!</strong></a></p>https://blog.netbsd.org/tnf/entry/wayland_on_netbsd_trials_andWayland on NetBSD - trials and tribulationsNia Alarie2020-09-28T17:34:22+00:002020-09-28T17:34:22+00:00<p>After I posted about the <a href="https://blog.netbsd.org/tnf/entry/default_window_manager_switched_to">new default window manager</a> in NetBSD I got a few questions, including "when is NetBSD switching from X11 to Wayland?", Wayland being X11's "new" rival. In this blog post, hopefully I can explain why we aren't yet!</p><p>After I posted about the <a href="https://blog.netbsd.org/tnf/entry/default_window_manager_switched_to">new default window manager</a> in NetBSD I got a few questions, including "when is NetBSD switching from X11 to Wayland?", Wayland being X11's "new" rival. In this blog post, hopefully I can explain why we aren't yet!</p>
<p>Last year (and early this year) I was responsible for porting the first working Wayland compositor to NetBSD - <a href="https://github.com/michaelforney/swc">swc</a>. I chose it because it looked small and hackable. You can try it out by installing the <code>velox</code> window manager from pkgsrc.</p>
<a href="http://ftp.netbsd.org/pub/NetBSD/misc/nia/images/wayland-laptop.jpg"><img src="http://ftp.netbsd.org/pub/NetBSD/misc/nia/images/wayland-laptop.jpg" style="max-width: 750px;"
alt="A Wayland compositor running on my NetBSD laptop, with a few applications like Luakit and Dungeon Crawl Stone Soup open."
title="A Wayland compositor running on my NetBSD laptop, with a few applications like Luakit and Dungeon Crawl Stone Soup open."></a>
<h2>Difficulties</h2>
<p>In a Wayland system, the "compositor" (display server) is responsible for managing displays, input, and window management. Generally, this means a lot of OS-specific code is contained there.</p>
<p>Wayland does not define protocols for features X11 users expect, like screenshots, screen locking, or window management. Either you implement these inside the compositor (lots of work that has to be redone), or you define your own protocol extension.</p>
<p>The Wayland "reference implementation" is a small set of libraries that can be used to build a compositor or a client application. These libraries currently have hard dependencies on Linux kernel APIs like <code>epoll</code>. In pkgsrc we've patched the libraries to add <a href=https://man.netbsd.org/kqueue.2>kqueue(2)</a> support, but the patches haven't been accepted upstream. Wayland is written with the assumption of Linux to the extent that every client application tends to <code>#include <linux/input.h></code> because Wayland's designers didn't see the need to define a OS-neutral way to get mouse button IDs.</p>
<p>So far, all Wayland compositors but swc have a hard dependency on libinput, which only supports Linux's input API (also cloned in FreeBSD). In NetBSD we have an entirely different input API - <a href="https://man.netbsd.org/wscons.4">wscons(4).</a> wscons is actually fairly simple to write code for, someone just needs to go out there and do it. You can use my code in swc as a reference. :)</p>
<p>In general, Wayland is moving away from the modularity, portability, and standardization of the X server.</p>
<h2>Is it ready for production?</h2>
<p>No, but you can play with it.</p>
<ul>
<li>swc has some remaining bugs and instability.</li>
<li>swc is incompatible with key applications like Firefox, but others like Luakit work, as do most things that use Qt5, GTK3, or SDL2. Not being able to run X11 applications currently is quite limiting.</li>
<li>Other popular compositors are not yet available. Alternatively, someone could write some new ones.</li>
<li>You need a supported GPU or SoC with kernel modesetting, since safe software fallbacks don't work here. So far, I've only tested this with Intel GPUs.</li>
</ul>
<h2>Task list</h2>
<ul>
<li>Adding support for wscons to more Wayland compositors and persuading developers to accept the patches.</li>
<li>Persuading developers not to add hard dependencies on <code>epoll</code> and instead use an abstraction layer like libevent.</li>
<li>Updating the NetBSD kernel DRM/KMS stack. This is a difficult undertaking that involves porting code from the Linux kernel (a very fast moving target).
<ul>
<li>Getting support for newer DRM versions</li>
<li>Getting support for atomic modesetting</li>
<li>Getting support for Glamor X servers (for running X11 applications inside wayland, etc)</li>
<li>Newer AMDGPU drivers, etc</li>
</ul>
</li>
<li>Adding support for basic (non-DRMKMS) framebuffers to a Wayland compositor. X11 can run from a basic unaccelerated NetBSD framebuffer, but this isn't yet possible in any Wayland compositor.</li>
<li>Extending swc to add more features and fix bugs.</li>
</ul>
<p>I've decided to take a break from this, since it's a fairly huge undertaking and uphill battle.
Right now, X11 combined with a compositor like picom or xcompmgr is the more mature option.</p>
https://blog.netbsd.org/tnf/entry/vax_port_needs_helpVAX port needs helpmartin2020-06-05T09:53:43+00:002020-06-05T09:53:43+00:00<p>Looking for volunteers to help VAX gcc, now collecting bounties...</p><p>The VAX is the oldest machine architecture still supported by NetBSD.</p>
<p>The support for it sometimes causes heated discussions, but it also has benefits:<p>
<ul>
<li>It uses a pre-IEEE 754 version of floating point numbers, while all other (later) architectures use some variant of IEEE 754 floating point in hardware or emulate it.</li>
<li>By today's standards all machines are slow and have little memory.</li>
</ul>
<p>This are severe challenges for a general purpose operating system like NetBSD, but also provides reality checks for our claim to be a very portable operating system.</p>
<p>Unfortunately there is another challenge, totally outside of NetBSD, but affecting the VAX port big time: the compiler support for VAX is ... let's say sub-optimal. It is also risking to be dropped completely by gcc upstream.</p>
<p>Now here is where people can help: there is a <a href="https://www.bountysource.com/issues/91495157-vax-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases">bounty campaign</a> to finance a gcc hacker to fix the hardest and most immediate issue with gcc for VAX. Without this being resolved, gcc will drop support for VAX in a near future version.</p>https://blog.netbsd.org/tnf/entry/towards_backtracing_through_signal_trampolinesTowards backtracing through signal trampolines and fresh libc++Michał Górny2020-03-09T18:27:16+00:002020-03-09T18:27:16+00:00<p>Upstream describes LLDB as <em>a next generation, high-performance debugger</em>.
It is built on top of LLVM/Clang toolchain, and features great
integration with it. At the moment, it primarily supports debugging C,
C++ and ObjC code, and there is interest in extending it to more
languages.</p>
<p>In February 2019, I have started working on LLDB, as contracted by the NetBSD
Foundation. So far I've been working on reenabling continuous
integration, squashing bugs, improving NetBSD core file support,
extending NetBSD's ptrace interface to cover more register
types and fix compat32 issues, fixing watchpoint and threading support,
porting to i386.</p>
<p>During the last month, I've finally managed to create proper reproducers
(and tests) for the remaining concurrent signal delivery problems.
I have started working on backtracing through signal trampolines,
and prepared a libc++ update.</p>
<p>Upstream describes LLDB as <em>a next generation, high-performance debugger</em>.
It is built on top of LLVM/Clang toolchain, and features great
integration with it. At the moment, it primarily supports debugging C,
C++ and ObjC code, and there is interest in extending it to more
languages.</p>
<p>In February 2019, I have started working on LLDB, as contracted by the NetBSD
Foundation. So far I've been working on reenabling continuous
integration, squashing bugs, improving NetBSD core file support,
extending NetBSD's ptrace interface to cover more register
types and fix compat32 issues, fixing watchpoint and threading support,
porting to i386.</p>
<p>During the last month, I've finally managed to create proper reproducers
(and tests) for the remaining concurrent signal delivery problems.
I have started working on backtracing through signal trampolines,
and prepared a libc++ update.</p>
<h2>NetBSD concurrent signal updates</h2>
<p>While finishing the last report, I was trying to reproduce some
of the concurrent test failures in LLDB with plain <code>ptrace()</code>. I've
finally managed to do that and therefore discover the factor causing
all my earlier attempts to fail — concurrent signal delivery works fine
unless the signal is actually delivered to the process and handled
by it.</p>
<p>Let me explain this a bit. When a signal is delivered to a debugged
process (or one of its threads), it is stopped and the debugger receives
stopping signal via <code>waitpid()</code>. Now, if the debugger wishes the signal
to be delivered to the process (thread), it needs to pass the signal
number as an argument to <code>PT_CONTINUE</code>. If it neglects to do so (passes
<code>0</code>), the signal is discarded.</p>
<p>My tests so far were doing precisely that — discarding the signal.
However, once I modified them to pass it back, they started failing
similarly to how LLDB tests are failing.</p>
<p>Whenever the debugged program receives concurrent signals to different
threads and the debugger requests their delivery, the process is stopped
with some of the signals multiple times. Curiously enough, during my
testing every signal to a thread was reported at least once which means
no signals were lost. I suspect that in an attempt to deliver pending
concurrent signals the kernel is passing them again to the debugger
rather than to the process itself.</p>
<p>I've used this research to extend testing of concurrent behavior.
More specifically, I have:</p>
<ol>
<li>
<p><a href="https://github.com/NetBSD/src/commit/621c8f0bf2051b2a80537acf693d92960d4ad1f2">Made signal concurrency test into a reusable factory</a>.</p>
</li>
<li>
<p><a href="https://github.com/NetBSD/src/commit/439b02d8f92d4190f0d9fcca02aaabd20025e7be">Started testing passing signal back to the process</a>.</p>
</li>
<li>
<p><a href="https://github.com/NetBSD/src/commit/bfa10db9bf4a95c47fc75a1e7f02416e479fe189">Extended the test to verify that signal is actually being delivered</a>.</p>
</li>
<li>
<p><a href="https://github.com/NetBSD/src/commit/ef48a87db881e60f1ef18729ee03180820dbffd4">Included catching newly-created processes in the test</a>.</p>
</li>
<li>
<p><a href="https://github.com/NetBSD/src/commit/ceafbcd7368be1e55351eb0780a2a77853aea0da">Added concurrent breakpoints to the test</a>.</p>
</li>
<li>
<p><a href="https://github.com/NetBSD/src/commit/810551337c40d4331f51e113eebb66b70ec3542b">Added concurrent watchpoints to the test</a>.</p>
</li>
<li>
<p>Finally, <a href="https://github.com/NetBSD/src/commit/67b43d84f162c9158341b950c46e0d38cb5e3815">started testing combination of simultaneous signals, breakpoints and watchpoints</a>.</p>
</li>
</ol>
<h2>Research into backtrace through signal trampoline</h2>
<p>The most important of the remaining tasks was to enhance LLDB with
NetBSD signal trampoline support.</p>
<h3>Signal trampolines on NetBSD</h3>
<p>Signal trampolines are shortly covered by <a href="https://www.netbsd.org/docs/internals/en/chap-processes.html#signal">Signal delivery chapter
of NetBSD Internals</a>.</p>
<p>When a signal is delivered to a running program, the system needs to
interrupt its execution and run its defined signal handler. Once
the signal handler finishes, the program execution resumes where it left
off. How this is achieved differs from system to system.</p>
<p>On NetBSD, so-called signal trampoline is used. The kernel (this is
done by <code>sendsig_siginfo()</code> e.g. in <a href="https://github.com/NetBSD/src/blob/trunk/sys/arch/amd64/amd64/machdep.c#L591">amd64/machdep.c</a>
function on newer ABIs) saves the program context and executes the
signal handler. When the signal handler returns, it returns to a
trampoline function defined by the libc that restores the saved context
and therefore resumes the program execution.</p>
<p>From debugger's perspective, the backtrace for a process interrupted
in midst of a signal handler ends on this trampoline function. However,
it is often considered useful to be able to know the status
of the process just before the signal was received — and therefore,
the point where program execution will continue. The goal in this point
was to make LLDB aware of NetBSD's trampoline design and capable
of locating and using the saved context to produce full backtrace.</p>
<h3>The two possible solutions</h3>
<p>There are two approaches to implementing signal trampoline handling:</p>
<ol>
<li>
<p>Explicitly detecting and processing signal trampolines in debugger.</p>
</li>
<li>
<p>Adding CFI code to signal trampoline implementation in order to store
the necessary information in libc itself.</p>
</li>
</ol>
<p>GDB on NetBSD is currently using the first approach. The code (found
in
<a href="https://github.com/NetBSD/src/blob/trunk/external/gpl3/gdb/dist/gdb/nbsd-tdep.c#L42">nbsd-tdep.c</a>
and e.g.
<a href="https://github.com/NetBSD/src/blob/trunk/external/gpl3/gdb/dist/gdb/amd64-nbsd-tdep.c#L34">amd64-nbsd-tdep.c</a>)
explicitly establishes whether the current frame corresponds to a signal
trampoline, finds the saved context and processes it.</p>
<p>Long-term, the second approach is preferable. Instead of explicitly
writing platform-specific code, we add CFI annotations to the trampoline
code (e.g. in
<a href="https://github.com/NetBSD/src/blob/trunk/lib/libc/arch/x86_64/sys/__sigtramp2.S#L40">__sigtramp2.S</a>).
Those annotations are consumed by the toolchain and used to construct
frame information inside the executable that can be afterwards consumed
by the debugger.</p>
<p>Both approaches are therefore roughly equivalent. The main difference
is that approach 1. stores platform-specific logic in the debugger,
while approach 2. stores it in the executable for all debuggers to
consume.</p>
<h2>libc++ update</h2>
<p>Another task to undergo during this period was to update libc++
in NetBSD src tree. It was last imported in 2015, to the version
roughly corresponding to LLVM 3.7 release. This version is dated
and has some bugs, particularly it is prone to miscompilation due
to undefined behavior (e.g. <a href="https://bugs.llvm.org/show_bug.cgi?id=28469">segfault in
std::map</a>). I've decided
to upgrade to the commit corresponding to the most recent LLVM/Clang update.</p>
<h3>max_align_t visibility</h3>
<p>The first problem I've hit after upgrading is that <a href="https://github.com/NetBSD/src/blob/trunk/include/stddef.h#L70">max_align_t</a>
is declared on NetBSD only for C11/C++11. However, <a href="https://github.com/llvm/llvm-project/blob/01f3a59fb3e2542fce74c768718f594d0debd0da/libcxx/include/cstddef#L52">on NetBSD libc++
is exposing it
unconditionally</a>.</p>
<p>Kamil Rytarowski proposed to <a href="https://mail-index.netbsd.org/tech-userlevel/2020/02/26/msg012269.html">expose max_align_t unconditionally</a>
in our headers as well. Joerg Sonnenberger on the other hand wants
to <a href="https://reviews.llvm.org/D73245">change libc++ instead</a>.</p>
<h3>Missing errno constants</h3>
<p>Another issue I've found is that NetBSD is missing the two errno
constants for robust mutexes: <code>EOWNERDEAD</code> and <code>ENOTRECOVERABLE</code>.
While libc++ has a <a href="https://github.com/llvm/llvm-project/blob/01f3a59fb3e2542fce74c768718f594d0debd0da/libcxx/include/errno.h#L35">hack to redefine them when missing</a>,
it seemed a better idea to assign them on our end.</p>
<p>I've learned that adding errno constants involves a few changes
besides adding new constants:</p>
<ol>
<li>
<p>Adding mapping to Linux compat in
<a href="https://github.com/NetBSD/src/blob/trunk/sys/compat/linux/common/linux_errno.c#L39">sys/compat/linux/common/linux_errno.c</a>.</p>
</li>
<li>
<p>Adding descriptions to manpage
<a href="https://github.com/NetBSD/src/blob/trunk/lib/libc/sys/intro.2#L94">lib/libc/sys/intro.2</a>.</p>
</li>
<li>
<p>Adding messages to
<a href="https://github.com/NetBSD/src/blob/trunk/lib/libc/nls/C.msg">libc catalogs</a>.</p>
</li>
<li>
<p>Enabling appropriate features in libstdc++.</p>
</li>
<li>
<p>Adding new error codes to <a href="https://github.com/NetBSD/src/blob/trunk/external/cddl/osnet/lib/libdtrace/errno.d">libdtrace</a>.</p>
</li>
<li>
<p>Adding errno mapping to NFS support in
<a href="https://github.com/NetBSD/src/blob/trunk/sys/nfs/nfs_subs.c#L205">sys/nfs/nfs_subs.c</a>.</p>
</li>
</ol>
<p>While at it, I've made sure to make it harder to accidentally miss doing
some of that in the future. Notably:</p>
<ol>
<li>
<p>I've added ATF tests to make sure that libc catalogs stay in sync
with errno and signal descriptions in code.</p>
</li>
<li>
<p>I've added a script to autogenerate libdtrace errno lists.</p>
</li>
<li>
<p>I've added a compile-time assertion that NFS errno mapping covers
all values.</p>
</li>
</ol>
<p>The complete list of commits:</p>
<ol>
<li>
<p><a href="https://github.com/NetBSD/src/commit/36d0d3594983300a3baa4074b7d3d35e165344d8">Sync errno messages between catalog and errno.h</a></p>
</li>
<li>
<p><a href="https://github.com/NetBSD/src/commit/c264623dd4dd0db25569aac3f47849d0f6e3d053">Sync signal messages between catalog and sys_siglist</a></p>
</li>
<li>
<p><a href="https://github.com/NetBSD/src/commit/bc3c28f3cb831317d05975061327099749e31555">Add tests for missing libc catalog entries</a></p>
</li>
<li>
<p><a href="https://github.com/NetBSD/src/commit/0386174f7f42a796d0d28c71e5da5d3122353033">PR standards/44921: Add errno consts for robust mutexes</a></p>
</li>
<li>
<p><a href="https://github.com/NetBSD/src/commit/ced00efa4311ec8415c85b8d4bca57cfd38cc1f3">Enable EOWNERDEAD & ENOTRECOVERABLE in libstdc++</a></p>
</li>
<li>
<p><a href="https://github.com/NetBSD/src/commit/040d5b808e49e2895644c9f0f285df507d8601cd">Update dtrace errno.d mapping and add a script for it</a></p>
</li>
<li>
<p><a href="https://github.com/NetBSD/src/commit/81266638adb11c7c0720b28bafc1fa8e5665b5ca">Update NFS errno mapping and add assert for correctness</a></p>
</li>
</ol>
<h3>The update</h3>
<p>I have sent <a href="https://mail-index.netbsd.org/tech-toolchain/2020/03/09/msg003742.html">libc++ update to 01f3a59fb3e2542fce74c768718f594d0debd0da</a>
to the mailing list for review. The proposed patch set includes:</p>
<ol>
<li>
<p>Adjust the cleanup script for the new version.</p>
</li>
<li>
<p>Cleaning up extraneous files from the old import (to make the diff
clearer).</p>
</li>
<li>
<p>Importing the new version and updating Makefiles.</p>
</li>
<li>
<p>Moving headers to standard <code>/usr/include/c++/v1</code> location for better
interoperability.</p>
</li>
<li>
<p>Moving libc++ to apache2 license group.</p>
</li>
</ol>
<h2>Future plans</h2>
<p>This is the final month of my contract and therefore I would like
to primarily focus on importing LLDB into src tree. As time permits,
I will continue attempting to improve support for backtracing through
signal trampolines.</p>
<p>The exact list of remaining tasks in my contract follows:</p>
<ol>
<li>
<p>Add support to backtrace through signal trampoline and extend the support to
libexecinfo, unwind implementations (LLVM, nongnu). Examine adding CFI
support to interfaces that need it to provide more stable backtraces (both
kernel and userland).</p>
</li>
<li>
<p>Add support for aarch64 target.</p>
</li>
<li>
<p>Stabilize LLDB and address breaking tests from the test suite.</p>
</li>
<li>
<p>Merge LLDB with the base system (under LLVM-style distribution).</p>
</li>
</ol>
<h2>This work is sponsored by The NetBSD Foundation</h2>
<p>The NetBSD Foundation is a non-profit organization and welcomes any
donations to help us continue funding projects and services
to the open-source community. Please consider visiting the following URL
to chip in what you can:</p>
<p><a href="https://netbsd.org/donations/#how-to-donate">https://netbsd.org/donations/#how-to-donate</a></p>
https://blog.netbsd.org/tnf/entry/lldb_watchpoints_xstate_in_ptraceLLDB: watchpoints, XSTATE in ptrace() and core dumpsMichał Górny2019-07-07T08:08:36+00:002019-07-07T08:08:36+00:00<p>Upstream describes LLDB as <em>a next generation, high-performance debugger</em>.
It is built on top of LLVM/Clang toolchain, and features great
integration with it. At the moment, it primarily supports debugging C,
C++ and ObjC code, and there is interest in extending it to more
languages.</p>
<p>In February, I have started working on LLDB, as contracted by the NetBSD
Foundation. So far I've been working on reenabling continuous
integration, squashing bugs, improving NetBSD core file support
and lately extending NetBSD's ptrace interface to cover more register
types and fix compat32 issues. You can read more about that in my
<a href="https://blog.netbsd.org/tnf/entry/xsave_and_compat32_kernel_work>">May 2019</a>
report.</p>
<p>In June, I have finally finished the remaining <code>ptrace()</code> work
for xstate and got it merged both on NetBSD and LLDB end (meaning it's
going to make it into NetBSD 9). I have also worked on debug register
support in LLDB, effectively fixing watchpoint support. Once again
I had to fight some upstream regressions.</p><p>Upstream describes LLDB as <em>a next generation, high-performance debugger</em>.
It is built on top of LLVM/Clang toolchain, and features great
integration with it. At the moment, it primarily supports debugging C,
C++ and ObjC code, and there is interest in extending it to more
languages.</p>
<p>In February, I have started working on LLDB, as contracted by the NetBSD
Foundation. So far I've been working on reenabling continuous
integration, squashing bugs, improving NetBSD core file support
and lately extending NetBSD's ptrace interface to cover more register
types and fix compat32 issues. You can read more about that in my
<a href="https://blog.netbsd.org/tnf/entry/xsave_and_compat32_kernel_work>">May 2019</a>
report.</p>
<p>In June, I have finally finished the remaining <code>ptrace()</code> work
for xstate and got it merged both on NetBSD and LLDB end (meaning it's
going to make it into NetBSD 9). I have also worked on debug register
support in LLDB, effectively fixing watchpoint support. Once again
I had to fight some upstream regressions.</p>
<h2>ptrace() XSTATE interface</h2>
<p>In the previous report, <a href="https://blog.netbsd.org/tnf/entry/xsave_and_compat32_kernel_work#initial-xsave-work>">I was comparing two approaches to resolving
unpredictable XSAVE data offsets</a>.
Both solutions had their merits but I eventually went with having
a pair of requests with a single predictable, extensible structure.
As a result, I have implemented two new <code>ptrace()</code> requests:</p>
<ul>
<li>
<p><code>PT_GETXSTATE</code> that obtains full FPU state and stores it in <code>struct xstate</code>,</p>
</li>
<li>
<p><code>PT_SETXSTATE</code> that updates FPU state as requested from <code>struct xstate</code>.</p>
</li>
</ul>
<p>The main features of this API are:</p>
<ol>
<li>
<p>It provides single call to obtain all supported XSAVE components. This is
especially useful for YMM or ZMM registers whose contents are split between
disjoint XSAVE components.</p>
</li>
<li>
<p>It provides a <code>xs_rfbm</code> bitfield that clearly indicates which XSAVE
components were available, and which can be used to issue partial updates
via <code>PT_SETXSTATE</code>.</p>
</li>
<li>
<p>It requires the caller to explicitly specify structure size. As a result,
new fields (= component types) can be added to it without breaking
compatibility with already built programs.</p>
</li>
<li>
<p>It provides identical API to i386 and amd64 programs, removing the need for
code duplication.</p>
</li>
<li>
<p>It provides backwards compatibility with FSAVE- and FXSAVE-only systems,
with <code>xs_rfbm</code> clearly indicating which fields were filled.</p>
</li>
<li>
<p>It can replace disjoint <code>PT_GETFPREGS</code> and <code>PT_GETXMMREGS</code> APIs on i386/amd64
with a single convenient method.</p>
</li>
</ol>
<p>From user's perspective, the main gain is ability to read YMM (AVX) registers.
The code supports ZMM (AVX-512) registers as well but I have not been able to
test it due to lack of hardware. That said, if one of the readers is running
NetBSD on AVX-512 capable CPU and is willing to help, please contact me and I'll
give you some tests to run.</p>
<p>The two relevant commits are:</p>
<ul>
<li>
<p><a href="https://github.com/NetBSD/src/commit/581c569ad68f9fc81d2a310b7ef758e9895a9f40">Fetch XSAVE area component offsets and sizes when initializing x86 CPU</a>
that obtains the necessary offsets and stores them in kernel,</p>
</li>
<li>
<p><a href="https://github.com/NetBSD/src/commit/be907e72edaf1f27cb9717ac68139b84c4eb699c">Implement PT_GETXSTATE and PT_SETXSTATE</a>
that adds the new calls along with tests.</p>
</li>
</ul>
<p>The two new calls are covered by tests for reading and writing MM (MMX), XMM
(SSE) and YMM (AVX) registers. I have also done some work on ZMM (AVX-512) test
but I did not complete it due to aforementioned lack of hardware.</p>
<p>On the LLDB end, the change was preceded with some bugfixes and cleanup
suggested by Pavel Labath. The relevant commits are:</p>
<ul>
<li>
<p><a href="https://github.com/llvm/llvm-project/commit/a984404f6b54984c3a2fff0c86a3b89588c3d939">[lldb] [Process/NetBSD] Fix error handling in register operations</a>,</p>
</li>
<li>
<p><a href="https://github.com/llvm/llvm-project/commit/a644b04b8cd80e5a7aa4185610fe01570b9827de">[lldb] [Process/NetBSD] Remove unnecessary FPU presence checks for x86_64</a>,</p>
</li>
<li>
<p><a href="https://github.com/llvm/llvm-project/commit/d687fa7d023ab897d2ced58555f9f480f26d72a2">[lldb] [Process/NetBSD] Remove unnecessary register buffer abstraction</a>,</p>
</li>
<li>
<p><a href="https://github.com/llvm/llvm-project/commit/8805829289202e282f931e1ab9af60c5fecb2712">[lldb] [Process] Introduce common helpers to split/recombine YMM data</a>,</p>
</li>
<li>
<p><a href="https://github.com/llvm/llvm-project/commit/2b2ad9342e65042baefc379e4a70774d8e538e84">[lldb] [Process/NetBSD] Support reading YMM registers via PT_*XSTATE</a>.</p>
</li>
</ul>
<h2>XSTATE in core dumps</h2>
<p>The <code>ptrace()</code> XSTATE supports provides the ability to introspect registers
in running programs. However, in order to improve the support for debugging
crashed programs the respective support needs to be also added to core dumps.</p>
<p>NetBSD core dumps are built on ELF file format, with additional process
information stored in ELF notes. Notes can be conveniently read
via <code>readelf -n</code>. Each note is uniquely identified by a pair of name and numeric
type identifier. NetBSD-specific notes are split into two groups:</p>
<ul>
<li>
<p>process-specific notes (shared by all LWPs) use <code>NetBSD-CORE</code> name
and successive type numbers defined in <code>sys/exec_elf.h</code>,</p>
</li>
<li>
<p>LWP-specific notes use <code>NetBSD-CORE@nn</code> where <em>nn</em> is LWP number, and type
numbers corresponding to <code>ptrace()</code> requests.</p>
</li>
</ul>
<p>Two process-specific notes are used at the moment:</p>
<ol>
<li>
<p><code>ELF_NOTE_NETBSD_CORE_PROCINFO</code> containing process information — including
killing signal information, PIDs, UIDs, GIDs…</p>
</li>
<li>
<p><code>ELF_NOTE_NETBSD_CORE_AUXV</code> containing auxiliary information provided
by the dynamic linker.</p>
</li>
</ol>
<p>The LWP-specific notes currently contain register dumps. They are stored
in the same format as returned by <code>ptrace()</code> calls, and use the same numeric
identifiers as <code>PT_GET*</code> requests.</p>
<p>Previously, only <code>PT_GETREGS</code> and <code>PT_GETFPREGS</code> dumps were supported. This
implies that i386 coredumps do not include MMX register values. Both requests were
handled via common code, with a TODO for providing machdep (arch-specific) hooks.</p>
<p>My work on core dumps involved three aspects:</p>
<ol>
<li>
<p>Writing ATF tests for their correctness.</p>
</li>
<li>
<p>Providing machdep API for injecting additional arch-specific notes.</p>
</li>
<li>
<p>Injecting <code>PT_GETXSTATE</code> data into x86 core dumps.</p>
</li>
</ol>
<p>To implement the ATF tests, I've used <code>PT_DUMPCORE</code> to dump core into
a temporary file with predictable filename. Afterwards, I've used libelf
to process the ELF file and locate notes in it. The note format I had to
process myself — I have included a reusable function to find and read specific
note in the tests.</p>
<p>Firstly, I wrote a test for process information. Then, I refactored register
tests to reduce code duplication and make writing additional variants much
easier, and created matching core dump tests for all existing <code>PT_GET*</code> register
tests. Finally, I implemented the support for dumping <code>PT_GETXSTATE</code>
information.</p>
<p>Of this work, only the first test was merged. The relevant commits and patches
are:</p>
<ul>
<li>
<p><a href="https://github.com/NetBSD/src/commit/4428941850bbc00bd772264bbc0ffdbe1534ae51">Add a test for verifying procinfo note inside coredumps</a>,</p>
</li>
<li>
<p><a href="http://mail-index.netbsd.org/tech-kern/2019/07/05/msg025243.html">Include XSTATE note in x86 core dumps</a>,</p>
</li>
<li>
<p><a href="http://mail-index.netbsd.org/tech-kern/2019/07/04/msg025240.html">Fix alignment when reading core notes</a>,</p>
</li>
<li>
<p><a href="http://mail-index.netbsd.org/tech-kern/2019/07/05/msg025242.html">Combine x86 register tests into unified test function</a>,</p>
</li>
<li>
<p><a href="http://mail-index.netbsd.org/tech-kern/2019/07/04/msg025241.html">Add tests for reading registers from x86 core dumps</a>.</p>
</li>
</ul>
<h2>LLDB debug register / watchpoint support</h2>
<p>The next item on my TODO was fixing debug register support in LLDB.
There are six debug registers on x86, and they are used to support
up to four hardware breakpoints or watchpoints (each can serve
as either). Those are:</p>
<ul>
<li>
<p>DR0 through DR3 registers used to specify the breakpoint or watchpoint
address,</p>
</li>
<li>
<p>DR6 acting as status register, indicating which debug conditions have
occurred,</p>
</li>
<li>
<p>DR7 acting as control register, used to enable and configure breakpoints
or watchpoints.</p>
</li>
</ul>
<p>DR4 and DR5 are obsolete synonyms for DR6 and DR7.</p>
<p>For each breakpoint, the control register provides the following options:</p>
<ol>
<li>
<p>Enabling it as global or local breakpoint. Global breakpoints remain active
through hardware task switches, while local breakpoints are disabled on task
switches.</p>
</li>
<li>
<p>Setting it to trigger on code execution (breakpoint), memory write or memory
write or read (watchpoints). Read-only hardware watchpoints are not
supported on x86, and are normally emulated via read/write watchpoints.</p>
</li>
<li>
<p>Specifying the size of watched memory to 1, 2, 4 or 8 bytes. 8-byte
watchpoints are not supported on i386.</p>
</li>
</ol>
<p>According to my initial examination, watchpoint support was already present
in LLDB (most likely copied from relevant Linux code) but it was not working
correctly. More specifically, the accesses were reported as opaque tracepoints
rather than as watchpoints. While the program was correctly
stopped, LLDB was not aware which watchpoint was triggered.</p>
<p>Upon investigating this further, I've noticed that this happens specifically
because LLDB is using local watchpoints. After switching it to use global
watchpoints, NetBSD started reporting triggered watchpoints correctly.</p>
<p>As a result, new branch of LLDB code started being used… and turned out
to segfault. Therefore, my next goal was to locate the invalid memory use
and correct it. In this case, the problem lied in the way thread data was
stored in a list. Specifically, the program wrongly assumed that the list
index will match LWP number exactly. This had two implications.</p>
<p>Firstly, it suffered from off-by-one error. Since LWPs start with 1, and list
indexes start with 0, a single-threaded program crashed trying to access past
the list. Secondly, the assumption that thread list will be always in order
seemed fragile. After all, it relied on LWPs being reported with successive
numbers. Therefore, I've decided to rewrite the code to iterate
through thread list and locate the correct LWP explicitly.</p>
<p>With those two fixes, some of the watchpoint tests started passing. However,
some are still failing because we are not handling threads correctly yet.
According to earlier research done by Kamil Rytarowski, we need to copy debug
register values into new LWPs as they are created. I am planning to work
on this shortly.</p>
<p>Additionally, NetBSD normally disallows unprivileged processes from modifying
debug registers. This can be changed via enabling
<code>security.models.extensions.user_set_dbregs</code>. Since LLDB tests are normally run
via unprivileged users, I had to detect this condition from within LLDB test
suite and skip watchpoint tests appropriately.</p>
<p>The LLDB commits relevant to this topic are:</p>
<ul>
<li><a href="https://github.com/llvm/llvm-project/commit/43cf5ae48a0c823d40d78e24cafce4ef6dfa76a9">[lldb] [test] Skip watchpoint tests on NetBSD if userdbregs is disabled</a>,</li>
<li><a href="https://github.com/llvm/llvm-project/commit/d3d2edf901de87f40f311dc5b9150acc54a77ef3">[lldb] [test] Watchpoint tests can be always run as root on NetBSD</a>,</li>
<li><a href="https://github.com/llvm/llvm-project/commit/baf64b65056954a887e54e55e4f76f3a12230682">[lldb] [Process/NetBSD] Fix segfault when handling watchpoint</a>,</li>
<li><a href="https://github.com/llvm/llvm-project/commit/0856721e3a06aaf2423186a6b4f97dea03c64c13">[lldb] [Process/NetBSD] Use global enable bits for watchpoints</a>.</li>
</ul>
<h2>Regressions caught by buildbot</h2>
<p>Finally, let's go over the regressions that were caught by our buildbot instance
throughout the passing month:</p>
<ul>
<li>
<p><a href="https://reviews.llvm.org/rL362280">[COFF, ARM64] Add CodeView register mapping</a> broke LLDB builds due to API
incompatibility; fixed by the author: <a href="https://reviews.llvm.org/rL362349">[COFF, ARM64] Fix CodeView API change
for getRegisterNames</a>;</p>
</li>
<li>
<p><a href="https://reviews.llvm.org/rL362986">Implement deduction guides for map/multimap</a> broke libc++ builds with trunk clang;
recommitted with a fix as <a href="https://reviews.llvm.org/rL363968">[libc++] Take 2: Implement CTAD for map
and multimap</a>;</p>
</li>
<li>
<p><a href="https://reviews.llvm.org/rL363101">Fix a crash in option parsing</a> broke LLDB
tests on NetBSD due to relying on specific <code>getopt_long()</code> output (bug?);
fixed by <a href="https://reviews.llvm.org/rL364317">Options: Correctly check for missing arguments</a>;</p>
</li>
<li>
<p><a href="https://reviews.llvm.org/rL364216">[ABI] Implement Windows ABI for x86_64</a>
broke NetBSD at runtime by omitting NetBSD from list of platforms using SysV
ABI; I've fixed it via <a href="https://reviews.llvm.org/rL364503">[lldb] [Plugins/SysV-x86_64] NetBSD is also using
SysV ABI</a>;</p>
</li>
<li>
<p><a href="https://reviews.llvm.org/rL363707">Implement xfer:libraries-svr4:read packet</a> changed internal LLDB API, breaking NetBSD
plugin builds; I've fixed it via <a href="https://reviews.llvm.org/rL363827">[lldb] [Process/NetBSD] Fix constructor
after r363707</a>;</p>
</li>
<li>
<p><a href="https://reviews.llvm.org/rL364751">Revert "Implement xfer:libraries-svr4:read packet"</a> changed the API back and broke NetBSD
again; I've reverted my change to fix it: <a href="https://reviews.llvm.org/rL364776">Revert "[lldb] [Process/NetBSD]
Fix constructor after r363707"</a>;</p>
</li>
<li>
<p><a href="https://reviews.llvm.org/D64163">Change LaunchThread interface to return an expected</a> broke builds, most likely due to GCC
incompatibility; not fixed yet.</p>
</li>
</ul>
<h2>Future plans</h2>
<p>Since Kamil has managed to move the kernel part of threading support forward,
I'm going to focus on improving threading support in LLDB right now. Most
notably, this includes ensuring that LLDB can properly handle multithreaded
applications, and that all thread-level actions (stepping, resuming,
signalling) are correctly handled. As mentoned above, this also includes
handling watchpoints in threads.</p>
<p>Of course, I am also going to finish the work on XSTATE in coredumps,
and handle any possible bugs I might have introduced in my earlier work.</p>
<p>Afterwards I will work on the remaining TODO items, that are:</p>
<ol>
<li>
<p>Add support to backtrace through signal trampoline and extend the support to
libexecinfo, unwind implementations (LLVM, nongnu). Examine adding CFI
support to interfaces that need it to provide more stable backtraces (both
kernel and userland).</p>
</li>
<li>
<p>Add support for i386 and aarch64 targets.</p>
</li>
<li>
<p>Stabilize LLDB and address breaking tests from the test suite.</p>
</li>
<li>
<p>Merge LLDB with the base system (under LLVM-style distribution).</p>
</li>
</ol>
<h2>This work is sponsored by The NetBSD Foundation</h2>
<p>The NetBSD Foundation is a non-profit organization and welcomes any
donations to help us continue funding projects and services
to the open-source community. Please consider visiting the following URL
to chip in what you can:</p>
<p><a href="https://netbsd.org/donations/#how-to-donate">https://netbsd.org/donations/#how-to-donate</a></p>
https://blog.netbsd.org/tnf/entry/adapting_triforceafl_for_netbsd_partAdapting TriforceAFL for NetBSD, Part 1Kamil Rytarowski2019-06-26T13:54:08+00:002019-06-26T13:54:08+00:00Prepared by Akul Pillai as part of GSoC 2019.
<p>The first coding period of The Google Summer of Code has come to an end. It has been a great experience so far and I got the opportunity to learn a lot of new stuff. This is a report on the work I have during this coding period.</p>Prepared by Akul Pillai as part of GSoC 2019.
<p>The first coding period of The Google Summer of Code has come to an end. It has been a great experience so far and I got the opportunity to learn a lot of new stuff. This is a report on the work I have during this coding period.</p>
<h2 id="about-triforceafl">About TriforceAFL</h2>
<p><a href="https://github.com/nccgroup/TriforceAFL">TriforceAFL</a> is a modified version of AFL that supports fuzzing using QEMU's full system emulation. This offers several advantages such as the fact that pieces of the kernel need not be recompiled with AFL or that the kernel does not need to be built with coverage support. More details on other advantages, design and implementation of TriforceAFL can be found <a href="https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2016/june/project-triforce-run-afl-on-everything/">here</a>.</p>
<p>The <a href="https://github.com/nccgroup/TriforceLinuxSyscallFuzzer">TriforceLinuxSyscallFuzzer</a> and the <a href="https://github.com/nccgroup/TriforceOpenBSDFuzzer">TriforceOpenBSDSyscallFuzzer</a> are syscall fuzzers built on top of TriforceAFL. The end goal of this project is to adapt TriforceAFL for NetBSD syscall fuzzing.</p>
<h2 id="adapted-triforceafl-for-pkgsrc-wip">Adapted TriforceAFL for pkgsrc-wip</h2>
<p>One of the end goals of the project is to make the fuzzer available as a pkgsrc package. To do so, TriforceAFL had to be first ported to pkgsrc. TriforceAFL uses qemu, so the appropriate patches to qemu for NetBSD were applied and few other minor issues resolved. The working package is now available in <a href="https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=tree">pkgsrc-wip</a>.</p>
<h2 id="the-netbsd-syscall-fuzzer">The NetBSD Syscall Fuzzer</h2>
<p>TriforceNetBSDSyscallFuzzer can be now used to perform system call fuzzing of NetBSD kernels using AFL and QEMU. The setup scripts and the driver program are functioning. The syscalls list has been updated for NetBSD and basic input generation works. Documentation detailing the process of setup(of the NetBSD installation/kernel image), building and fuzzing along with the code is available on <a href="https://github.com/akulpillai/TriforceNetBSDSyscallFuzzer">github</a>.</p>
<p>The fuzzer functions properly and detects crashes which can be reproduced using the driver. Although it can severely benefit from better input generation and optimisation. This will be the focus in the next coding period.</p>
<img src="https://netbsd.org/~kamil/gsoc_2019/triforceafl_2019_06_26.png">
<h2 id="summary">Summary</h2>
<p>In the coming weeks, the work of optimizing the fuzzer is to be done, so that it is more efficient at catching bugs, I am looking forward to doing so and making TriforceNetBSDSyscallFuzzer available on NetBSD through pkgsrc.</p>
<p>Lastly I would like to thank my mentor, Kamil Rytarowski for always helping me through the process and guiding me whenever I needed any help.</p>
https://blog.netbsd.org/tnf/entry/using_acme_sh_for_letUsing acme.sh for Let's Encrypt certificates on pkgsrc.org serversS.P.Zeidler2018-09-17T22:06:04+00:002018-09-17T22:06:04+00:00Peter Wemm's <a href="https://blog.crashed.org/letsencrypt-in-freebsd-org/">writeup</a> about using acme.sh for FreeBSD.org served as inspiration, but I chose to do a few things different:
<ul>
<li> using DNS alias mode with sub-domains dedicated to ACME verification
<li> delegating the sub-domains to the servers where the certificate will be needed
<li> using bind on the servers where the certificate will be needed (where it was running as resolver already anyway)
<li> using dns_nsupdate (i.e. dynamic DNS) to add the challenge to the ACME subzone.
</ul>
Appropriately restricted, that gives the following addition to named.conf on the target server (with an update key named acme-ddns):
<pre>
options {
....
allow-update { localhost; };
....
};
zone "acme-www.pkgsrc.org" {
type master;
file "acme/acme-www.pkgsrc.org";
update-policy {
grant acme-ddns name _acme-challenge.acme-www.pkgsrc.org. TXT;
};
};
</pre>
And last but not least, deployment of certificates via make, i.e. completely independent of acme.sh.
<p>
Due to all of the above, acme.sh does not need to tentacle about in the filesystem and can run as a plain user in a chroot. It's not a tiny chroot, though (20M), since acme.sh needs a bunch of common shell tools:
<ul><li>awk basename cat chmod cp curl cut date egrep/grep head mkdir mktemp mv nsupdate od openssl printf readlink rm sed sh sleep stat tail touch tr uname, and their shared libs, /libexec/ld.elf_so and /usr/libexec/ld.elf_so;
<li>under the chroot /etc a resolv.conf, the CA cert for Let's Encrypt (mozilla-rootcert-60.pem) and to make openssl complain less an empty openssl.cnf
<li>and in the chroot /dev: null, random and urandom.
</ul>
<p>
I call both the acme.sh --cron job and the certificate deployment make from daily.local, which adds the output to the daily mail and makes it easy to keep an eye on things.https://blog.netbsd.org/tnf/entry/finishing_leftover_tasks_from_googleFinishing leftover tasks from Google Summer of CodeKamil Rytarowski2018-09-03T23:34:00+00:002018-09-04T16:20:00+00:00Over the past month, I was coordinating and coding the remaining post-GSoC tasks. This mostly covers work around honggfuzz and sanitizers.Over the past month, I was coordinating and coding the remaining post-GSoC tasks.
This mostly covers work around honggfuzz and sanitizers.
<p>
<h1>honggfuzz ptrace(2) features</h1>
<p>
I've introduced new ptrace(2) tests verifying attaching to a stopped process.
This is an important scenario in debuggers, the ability to call a ptrace(2)
operation with the PT_ATTACH argument with a process id (PID) of a process entity that is stopped.
In typical circumstances PT_ATTACH causes an executing process to stop and emit SIGSTOP for the tracer.
An already stopped process is a special case as we cannot stop it again.
Not every UNIX-like kernel can handle this scenario in a sensible way, and the modern solution is to keep the process stopped
(rather than e.g... resumed) and emit a new signal SIGSTOP to the debugger (rather than e.g. not emitting anything).
There used to be complex workarounds for mainstream kernels in debuggers such as GDB to workaround kernel bugs
of attaching to a stopped process.
<p>
honggfuzz is a security oriented, feedback-driven, evolutionary, easy-to-use fuzzer with interesting analysis options.
This piece of software is developed by a Google employee, however the product is not an official Google software.
honggfuzz uses on featured platforms ptrace(2) to monitor crash signals in traced processes.
I've implemented a new backed in the fuzzer for NetBSD using its ptrace(2) API.
The backend is designed to follow the existing scenarios and features in Linux & Android:
<ul>
<li>Attaching to a manually stopped process, optionally spawned by the fuzzer.</li>
<li>Option to attach to a selected process over its PID.</li>
<li>Crash instruction decoding with aid of a disassembler (capstone for NetBSD).</li>
<li>Ability to monitor multiple processes with an arbitrary number of threads.</li>
<li>Monitor forks(2) and vforks(2) events, however unused in the current fuzzing model.</li>
<li>Concurrent execution of multiple processes.</li>
<li>Timeout of long-lasting (hanging?) processes in persistent mode (limit: 0.25[sec]).</li>
</ul>
<p>
There are few missing features:
<ul>
<li>Intel BTS - hardware assisted tracing</li>
<li>Intel PT - hardware assisted tracing</li>
<li>hp libunwind - unwinding stack of a traced process for better detection of unique crashes</li>
</ul>
<p>
<h1>Sanitizers</h1>
<p>
I've started researching Kernel Address Sanitizer, checking the runtime internals and differences between its version ABIs.
My intention was to join efforts with Siddharth (GSoC student) and head with a sanitzier for EuroBSDCon 2018 in Romania.
However, Maxime Villard decided to join the efforts a little bit earlier and he managed to get quickly a functional bare version for NetBSD/amd64.
In the end we have decided to leave the kASan work to Maxime for now and let Siddharth to work on a kCov (SanitizerCoverage) device.
SanCov is a feature of compilers, designed as an aid for fuzzers to ship interesting information from a fuzzing point of view of a number of
function calls, comparisons, divisions etc.
Successful userland fuzzers (such as AFL, honggfuzz) use this feature as an aid in determining of new code-paths.
It's the same with a renowned kernel fuzzer - syzkaller.
<p>
While, I'm helping Siddharth to port a kcov(4) device to NetBSD, I've switched to the remaining pending tasks in userland sanitizers.
I've managed to switch the sanitizers from syscall(2) and __syscall(2) - indirect system call API - calls to libc routines.
The approach of using an indirect generic interface didn't work well in the NetBSD case, as there is the need to handle multiple ABIs,
Endians, CPU architectures, and the C language ABI is not a good choice to serialize and deserialize arbitrary function arguments
with various types through a generic interface.
The discussion on the rationale is perhaps not the proper place, and every low-level C developer is well aware of the problems.
It's better to restrict the discussion to the statement that it's not possible (not trivial) to call in a portable way
all the needed syscalls, without the aid of per-case auxiliary switches and macros.
There are also some cases (such as pipe(2)) when is is not possible to express the system call semantics
with syscall(2)/__syscall(2).
<p>
I've switched these routines to use internal libc symbols when possible.
In the remaining cases I've used a fallback to libc's versions of the routines, with aid of indirect function pointers.
I'm trying to detect the addresses of real functions with dlsym(3) calls.
In the result, I've switched all the uses of syscall(2) and __syscall(2) and observed no regressions in tests.
<p>
I'm also in the process of deduplication of local patches to sanitizers.
My current main focus is to finish switching syscall(2) and __syscall(2) to libc routines (patch pending upstream),
introduce a new internal version of sysctl(3) that bypasses interceptors (partially merged upstream) and
introduces new interceptors for sysctl(3) calls.
This is a convoluted process in the internals with the goal to make the sanitizers more reliable across NetBSD targets and manage to sanitize
less trivial examples such as rumpkernels.
The RUMP code uses internally a modified and private versions of sysctl*() operations and we still must keep the internals in order and properly
handle the RUMP code.
<p>
<h1>Merged commits</h1>
<p>
The NetBSD sources:
<p>
<ul>
<li>Merge FreeBSD improvements to the man-page of timespec_get(3)</li>
<li>Remove unused symbols from sys/sysctl.h</li>
<li>Add a new ATF ptrace(2) test: child_attach_to_its_stopped_parent</li>
<li>Add await_stopped() in t_ptrace_wait.h</li>
<li>Add a new ATF test parent_attach_to_its_stopped_child</li>
<li>Add a new ATF ptrace(2) test: tracer_attach_to_unrelated_stopped_process</li>
<li>Drop a duplicate instruction line [libpthread]</li>
<li>Mark kernel-asan as done (by maxv)</li>
<li>TODO.sanitizers: Mark switch of syscall(2)/__syscall(2) to libc done</li>
</ul>
<p>
The LLVM sources:
<p>
<ul>
<li>Introduce new type for inteceptors UINTMAX_T</li>
<li>Add internal_sysctl() used by FreeBSD, NetBSD, OpenBSD and MacOSX</li>
<li>Improve portability of internal_sysctl()</li>
<li>Try to fix internal_sysctl() for MacOSX</li>
<li>Try to unbreak internal_sysctl() for MacOSX</li>
</ul>
<p>
<h1>Summary</h1>
<p>
I'm personally proud of the success of the reliability of the ptrace(2) backend in the renowned honggfuzz fuzzer.
NetBSD was capable to handling all the needed features and support all of them with an issue-free manner.
Once, I will address the remaining ptrace(2) issues on my TODO list - the NetBSD kernel will be capable to host more software
in a similar fashion, and most importantly a fully featured debugger such as GDB and LLDB, however without the remaining hiccups.
<p>
We are also approaching another milestone with the sanitizers' runtime available in the compiler toolchain: sanitizing rumpkernels.
It is already possible to execute the rump code against a homegrown uUBSan runtime, but we are heading now to execute the code under the default
runtime for the remaining sanitizers (ASan, MSan, TSan).
<p>
For the record, it has been reported that kUBSan has been ported from NetBSD to at least two kernels: FreeBSD and XNU.
<p>
<h1>Plan for the next milestone</h1>
<p>
I'm in preparation for my visit to EuroBSDCon (Bucharest, Romania) in September and GSoC Mentor Summit & MeetBSDCa in October (California, the U.S.).
I intend to rest during this month and still provide added value to the project, porting and researching missing software dedicated for developers.
Among others, I'm planning to research the HP libunwind library and if possible, port it to NetBSD.
<p>
<h2>This work was sponsored by The NetBSD Foundation.</h2>
<p>
The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:
<p>
<a href="http://netbsd.org/donations/#how-to-donate">http://netbsd.org/donations/#how-to-donate</a>
https://blog.netbsd.org/tnf/entry/netbsd_on_allwinner_socs_updateNetBSD on Allwinner SoCs Updatejmcneill2017-11-08T02:46:15+00:002017-11-08T10:28:56+00:00<p>
<img src="//www.netbsd.org/~jmcneill/allwinner.jpg" style="width: 83px; height: 83px; float: right;">
Since the <a href="https://blog.netbsd.org/tnf/entry/porting_netbsd_to_allwinner_h3">last update</a>, we've made a number of improvements to the NetBSD Allwinner port. The <i>SUNXI</i> kernel has grown support for 8 new SoCs, and we added many new device drivers to the source repository.
</p><p>
<img src="//www.netbsd.org/~jmcneill/allwinner.jpg" style="width: 83px; height: 83px; float: right;">
Since the <a href="https://blog.netbsd.org/tnf/entry/porting_netbsd_to_allwinner_h3">last update</a>, we've made a number of improvements to the NetBSD Allwinner port. The <i>SUNXI</i> kernel has grown support for 8 new SoCs, and we added many new device drivers to the source repository.
</p>
<h4>Supported systems</h4>
<ul>
<li>
As of November 2017, we now support the following Allwinner SoCs with the SUNXI kernel: A10, A13, A20, A31, A64, A80, A83T, GR8, H2+, H3, H5, and R8. An up-to-date list of supported SoCs with example boards is maintained on the <a href="https://wiki.netbsd.org/ports/evbarm/allwinner/?updated#index1h1">NetBSD/allwinner wiki page</a>.
</li>
<li>
Here's <a href="https://pbs.twimg.com/media/DJYA7SCXUAEvEQk.jpg">NetBSD running on a 14" Pinebook</a> from <a href="https://www.pine64.org/?page_id=3707">Pine64</a>. Since the keyboard and touchpad are connected internally to a USB controller, the device is fully functional.
</li>
<li>
A bit more effort was required to get <a href="https://pbs.twimg.com/media/DIRGmsOXcAEJu-j.jpg">NetBSD running on a PocketCHIP</a> from <a href="https://getchip.com/pages/pocketchip">NextThing Co</a>. The keyboard is wired to an I2C keypad controller, so a new <i>tcakp(4)</i> keyboard driver was required. The touchscreen is supported by the Allwinner port's <i>sunxits</i> driver and can be calibrated with the <a href="//man.NetBSD.org/tpctl.8">tpctl(8)</a> utility.
</li>
<li>
Many more devices are supported, including (but not limited to) boards from <a href="http://nanopi.io">FriendlyARM (NanoPi)</a>, <a href="https://www.olimex.com/Products/OLinuXino/open-source-hardware">Olimex (OLinuXino)</a>, <a href="https://www.pine64.org">Pine64</a>, <a href="http://www.banana-pi.org">Sinovoip (BananaPi)</a>, and <a href="http://www.orangepi.org">Xunlong (OrangePi)</a>.
</li>
</ul>
<h4>Device driver support</h4>
<p>
In addition to the countless machine-independent device drivers already in NetBSD, the following Allwinner-specific devices are supported:
</p>
<h5>Audio codec</h5>
<p>
The built-in analog audio codec is supported on the following SoCs with the <i>sunxicodec</i> driver: A10, A13, A20, A31, GR8, H2+, H3, and R8.
</p>
<h5>Ethernet</h5>
<p>
Ethernet is supported on all applicable Allwinner SoCs. Three ethernet drivers are available:
<ul>
<li>Fast Ethernet MAC (EMAC) as found in A10 and A20 family SoCs</li>
<li>Gigabit Ethernet MAC (GMAC) as found in A20, A31, and A80 family SoCs</li>
<li>Gigabit Ethernet MAC (EMAC) as found in A64, A83T, H2+, and H3 family SoCs</li>
</ul>
</p>
<h5>Framebuffer</h5>
<p>
Framebuffer console support is available wherever it is supported by U-Boot using the <i>simplefb(4)</i> driver.
</p>
<h5>Thermal sensors</h5>
<p>
Thermal sensors are supported on A10, A13, A20, A31, A64, A83T, H2+, and H3 SoCs.
</p>
<h5>CPU frequency and voltage scaling</h5>
<p>
On A10, A20, H2+, and H3 SoCs, dynamic CPU frequency and voltage scaling support is available when configured in the device tree. In addition, on H2+ and H3 SoCs, the kernel will automatically detect when the CPU temperature is too high and throttle the CPU frequency and voltage to prevent overheating.
</p>
<h5>Touch screen</h5>
<p>
The touch screen controller found in A10, A13, A20, and A31 SoCs is fully supported. The <a href="//man.NetBSD.org/tpctl.8">tpctl(8)</a> utility can be used to calibrate the touch screen and has been updated to support standard wsdisplay APIs.
</p>
<h5>Other drivers</h5>
<p>
A standard set of devices are supported across all SoCs (where applicable): DMA, GPIO, I2C, interrupt controllers, RTC, SATA, SD/MMC, timers, UART, USB, watchdog, and more.
</p>
<h4>U-Boot</h4>
<p>
A framework for U-Boot packages has been added to pkgsrc, and <a href="http://pkgsrc.se/search.php?so=u-boot">U-Boot packages</a> for many boards already exist. </p>
<h4>What now?</h4>
<p>
There are a few missing features that would be nice to have:
<ul>
<li>Wi-Fi (SDIO). There are a lot of different wireless chips used on these boards, but the majority seem to be either Broadcom or Realtek based. We recently ported OpenBSD's <i>bwfm(4)</I> driver to support the USB version of the Broadcom Wi-Fi controllers, with an expectation that SDIO support will follow at some point in the future.</li>
<li>NAND controller. Most boards have eMMC and/or microSD slots, but this would be really useful for the CHIP / CHIP Pro / PocketCHIP family of devices.</li>
<li>64-bit support for sun50i family SoCs</li>
<li>Readily available install images. A prototype <a href="http://www.invisible.ca/arm/">NetBSD ARM Bootable Images</a> site is available with a limited selection of supported boards.</li>
</ul>
</p>
<h5>More information</h5>
<p>
<ul>
<li><a href="http://mail-index.netbsd.org/port-arm/">port-arm mailing list</a></li>
<li><a href="https://wiki.netbsd.org/ports/evbarm/allwinner/">NetBSD Allwinner wiki page</a></li>
</ul>
</p>https://blog.netbsd.org/tnf/entry/porting_netbsd_to_allwinner_h3Porting NetBSD to Allwinner H3 SoCsjmcneill2017-07-09T12:31:04+00:002017-07-10T14:17:58+00:00<p>
<img src="//www.netbsd.org/~jmcneill/quad-core-H3.jpg" style="width: 83px; height: 83px; float: right;">
A new <i>SUNXI</i> evbarm kernel has appeared recently in NetBSD -current with support for boards based on the <a href="http://www.allwinnertech.com/index.php?c=product&a=index&id=47">Allwinner H3</a> system on a chip (SoC). The H3 SoC is a quad-core Cortex-A7 SoC designed primarily for set-top boxes, but has managed to find its way into many single-board computers (SBC). This is one of the first evbarm ports built from the ground up with <a href="https://en.wikipedia.org/wiki/Device_tree">device tree</a> support, which helps us to use a single kernel config to support many different boards.
</p><p>
<img src="//www.netbsd.org/~jmcneill/quad-core-H3.jpg" style="width: 83px; height: 83px; float: right;">
A new <i>SUNXI</i> evbarm kernel has appeared recently in NetBSD -current with support for boards based on the <a href="http://www.allwinnertech.com/index.php?c=product&a=index&id=47">Allwinner H3</a> system on a chip (SoC). The H3 SoC is a quad-core Cortex-A7 SoC designed primarily for set-top boxes, but has managed to find its way into many single-board computers (SBC). This is one of the first evbarm ports built from the ground up with <a href="https://en.wikipedia.org/wiki/Device_tree">device tree</a> support, which helps us to use a single kernel config to support many different boards.
</p>
<p style="clear: both;">
To get these boards up and running, first we need to deal with low-level startup code. For the SUNXI kernel this currently lives in <a href="http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/evbarm/sunxi/">sys/arch/evbarm/sunxi/</a>. The purpose of this code is fairly simple; initialize the boot CPU and initialize the MMU so we can jump to the kernel. The initial MMU configuration needs to cover a few things -- early on we need to be able to access the kernel, UART debug console, and the device tree blob (DTB) passed in from U-Boot. We wrap the kernel in a U-Boot header that claims to be a Linux kernel; this is no accident! This tells U-Boot to use the Linux boot protocol when loading the kernel, which ensures that the DTB (loaded by U-Boot) is processed and passed to us in <i>r2</i>.
</p>
<p>
Once the CPU and MMU are ready, we jump to the generic ARM FDT implementation of <i>initarm</i> in <a href="http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/evbarm/fdt/fdt_machdep.c">sys/arch/evbarm/fdt/fdt_machdep.c</a>. The first thing this code does is validate and relocate the DTB data. After it has been relocated, we compare the <i>compatible</i> property of the root node in the device tree with the list of ARM platforms compiled into the kernel. The Allwinner sunxi platform code lives in <a href="http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/sunxi/sunxi_platform.c">sys/arch/arm/sunxi/sunxi_platform.c</a>. The sunxi platform code provides SoC-specific versions of code needed early at boot. We need to know how to initialize the debug console, spin up application CPUs, reset the board, etc.
</p>
<p>
Instead of writing H3-specific code for spinning up application CPUs, I took advantage of U-Boot's <a href="http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/index.html">Power State Coordination Interface</a> implementation. A <a href="http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/arm/psci.c">psci(4)</a> driver was added and the <i>allwinner,sun8i-h3</i> platform code was modified to use this code to start up all processors.
</p>
<p>
With a bit of luck, we're now booting and enumerating devices. Apart from a few devices, almost nothing works yet as we are missing a driver for the CCU. The CCU in the Allwinner H3 SoC controls PLLs and most of the clock generation, division, muxing, and gating. Since there are many similarities between Allwinner SoCs, I opted to write generic CCU code and then SoC-specific frontends. The resulting code lives in <a href="http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/sunxi/">sys/arch/arm/sunxi/</a>; generic code as <i>sunxi_ccu.c</i> and H3-specific code in <i>sun8i_h3_ccu.c</i>.
</p>
<p>
Now we have a CCU driver, we can attach a <a href="http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/sunxi/sunxi_com.c">com(4)</a> and have a valid console device.
</p>
<p>
After this, it's a matter of writing drivers and/or adapting existing code to attach to <i>fdtbus</i> based on the bindings used in the DTB. For cases where we had a compatible driver in the <a href="http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/allwinner/">old Allwinner port</a>, I opted to make a copy of the code and FDT-ize it. A few reasons for this -- 1) the old drivers have CCU-specific code with per-SoC ifdefs scattered throughout, 2) I didn't want to break existing kernels, and 3) long term goal is to move the SoCs supported by the old code over to the new code (this process has already started with the Allwinner A31 port).
</p>
<p>
So what do we get out of this? This is a step towards being able to ship a <i>GENERIC</i> evbarm kernel. I developed the H3 port on two boards, the <a href="http://www.friendlyarm.com/index.php?route=product/product&product_id=132">NanoPi NEO</a> and <a href="http://www.orangepi.org/orangepiplus2e/">Orange Pi Plus 2E</a>, but since then users on <a href="http://mail-index.netbsd.org/port-arm/">port-arm@</a> have been reporting success on many other H3 boards, all from a single kernel config. In addition, I've added support for other Allwinner SoCs (sun8i-a83t, sun6i-a31) to the kernel and have tested booting the same kernel across all 3 SoCs.
</p>
<p>
Orange Pi Plus 2E boot log is below.
</p>
<pre>
U-Boot SPL 2017.05 (Jul 01 2017 - 17:11:09)
DRAM: 2048 MiB
Trying to boot from MMC1
U-Boot 2017.05 (Jul 01 2017 - 17:11:09 -0300) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
I2C: ready
DRAM: 2 GiB
MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
In: serial
Out: serial
Err: serial
Net: phy interface7
eth0: ethernet@1c30000
starting USB...
USB0: USB EHCI 1.00
USB1: USB OHCI 1.0
USB2: USB EHCI 1.00
USB3: USB OHCI 1.0
USB4: USB EHCI 1.00
USB5: USB OHCI 1.0
scanning bus 0 for devices... 2 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 4 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
reading netbsd.ub
6600212 bytes read in 334 ms (18.8 MiB/s)
reading sun8i-h3-orangepi-plus2e.dtb
16775 bytes read in 49 ms (334 KiB/s)
## Booting kernel from Legacy Image at 42000000 ...
Image Name: NetBSD/sunxi 8.99.1
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6600148 Bytes = 6.3 MiB
Load Address: 40008000
Entry Point: 40008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 43000000
Booting using the fdt blob at 0x43000000
Loading Kernel Image ... OK
Loading Device Tree to 49ff8000, end 49fff186 ... OK
Starting kernel ...
[ Kernel symbol table missing! ]
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 8.99.1 (SUNXI) #304: Sat Jul 8 11:01:22 ADT 2017
jmcneill@undine.invisible.ca:/usr/home/jmcneill/netbsd/cvs-src/sys/arch/evbarm/compile/obj/SUNXI
total memory = 2048 MB
avail memory = 2020 MB
sysctl_createv: sysctl_create(machine_arch) returned 17
armfdt0 (root)
fdt0 at armfdt0: Xunlong Orange Pi Plus 2E
fdt1 at fdt0
fdt2 at fdt0
cpus0 at fdt0
cpu0 at cpus0: Cortex-A7 r0p5 (Cortex V7A core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB/32B 2-way L1 VIPT Instruction cache
cpu0: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu0: 512KB/64B 8-way write-through L2 PIPT Unified cache
vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
cpu1 at cpus0
cpu2 at cpus0
cpu3 at cpus0
gic0 at fdt1: GIC
armgic0 at gic0: Generic Interrupt Controller, 160 sources (150 valid)
armgic0: 16 Priorities, 128 SPIs, 7 PPIs, 15 SGIs
fclock0 at fdt2: 24000000 Hz fixed clock
ffclock0 at fdt2: x1 /1 fixed-factor clock
fclock1 at fdt2: 32768 Hz fixed clock
sunxigates0 at fdt2
sunxiresets0 at fdt1
gtmr0 at fdt0: Generic Timer
armgtmr0 at gtmr0: ARMv7 Generic 64-bit Timer (24000 kHz)
armgtmr0: interrupting on irq 27
sunxigpio0 at fdt1: PIO
gpio0 at sunxigpio0: 94 pins
sunxigpio1 at fdt1: PIO
gpio1 at sunxigpio1: 12 pins
sun8ih3ccu0 at fdt1: H3 CCU
fregulator0 at fdt0: vcc3v3
fregulator1 at fdt0: gmac-3v3
fregulator2 at fdt0: vcc3v0
fregulator3 at fdt0: vcc5v0
sunxiusbphy0 at fdt1: USB PHY
/soc/dma-controller@01c02000 at fdt1 not configured
/soc/codec-analog@01f015c0 at fdt1 not configured
/clocks/ir_clk@01f01454 at fdt2 not configured
sunxiemac0 at fdt1: EMAC
sunxiemac0: interrupting on GIC irq 114
rgephy0 at sunxiemac0 phy 0: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 5
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
rgephy1 at sunxiemac0 phy 1: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 5
rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
psci0 at fdt0: PSCI 0.1
gpioleds0 at fdt0: orangepi:green:pwr orangepi:red:status
gpiokeys0 at fdt0: sw4
sunximmc0 at fdt1: SD/MMC controller
sunximmc0: interrupting on GIC irq 92
sunximmc1 at fdt1: SD/MMC controller
sunximmc1: interrupting on GIC irq 93
sunximmc2 at fdt1: SD/MMC controller
sunximmc2: interrupting on GIC irq 94
ehci0 at fdt1: EHCI
ehci0: interrupting on GIC irq 106
ehci0: 1 companion controller, 1 port
usb0 at ehci0: USB revision 2.0
ohci0 at fdt1: OHCI
ohci0: interrupting on GIC irq 107
ohci0: OHCI version 1.0
usb1 at ohci0: USB revision 1.0
ehci1 at fdt1: EHCI
ehci1: interrupting on GIC irq 108
ehci1: 1 companion controller, 1 port
usb2 at ehci1: USB revision 2.0
ohci1 at fdt1: OHCI
ohci1: interrupting on GIC irq 109
ohci1: OHCI version 1.0
usb3 at ohci1: USB revision 1.0
ehci2 at fdt1: EHCI
ehci2: interrupting on GIC irq 110
ehci2: 1 companion controller, 1 port
usb4 at ehci2: USB revision 2.0
ohci2 at fdt1: OHCI
ohci2: interrupting on GIC irq 111
ohci2: OHCI version 1.0
usb5 at ohci2: USB revision 1.0
/soc/timer@01c20c00 at fdt1 not configured
/soc/watchdog@01c20ca0 at fdt1 not configured
/soc/codec@01c22c00 at fdt1 not configured
com0 at fdt1: ns16550a, working fifo
com0: console
com0: interrupting on GIC irq 32
sunxirtc0 at fdt1: RTC
/soc/ir@01f02000 at fdt1 not configured
cpu3: Cortex-A7 r0p5 (Cortex V7A core)
cpu3: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu3: 32KB/32B 2-way L1 VIPT Instruction cache
cpu3: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu3: 512KB/64B 8-way write-through L2 PIPT Unified cache
vfp3 at cpu3: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
cpu1: Cortex-A7 r0p5 (Cortex V7A core)
cpu1: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu1: 32KB/32B 2-way L1 VIPT Instruction cache
cpu1: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu1: 512KB/64B 8-way write-through L2 PIPT Unified cache
vfp1 at cpu1: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
cpu2: Cortex-A7 r0p5 (Cortex V7A core)
cpu2: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu2: 32KB/32B 2-way L1 VIPT Instruction cache
cpu2: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu2: 512KB/64B 8-way write-through L2 PIPT Unified cache
vfp2 at cpu2: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
sdmmc0 at sunximmc0
sdmmc1 at sunximmc1
sdmmc2 at sunximmc2
uhub0 at usb0: Generic (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
uhub1 at usb2: Generic (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
uhub2 at usb3: Generic (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
uhub3 at usb1: Generic (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
uhub4 at usb4: Generic (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
uhub5 at usb5: Generic (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
ld2 at sdmmc2: <0x15:0x0100:AWPD3R:0x00:0xec19649f:0x000>
sdmmc0: SD card status: 4-bit, C10, U1, V10
ld0 at sdmmc0: <0x27:0x5048:2&DRP:0x07:0x01c828bc:0x109>
ld2: 14910 MB, 7573 cyl, 64 head, 63 sec, 512 bytes/sect x 30535680 sectors
ld0: 15288 MB, 7765 cyl, 64 head, 63 sec, 512 bytes/sect x 31309824 sectors
(manufacturer 0x24c, product 0xf179, standard function interface code 0x7)at sdmmc1 function 1 not configured
ld2: mbr partition exceeds disk size
ld0: 4-bit width, High-Speed/SDR25, 50.000 MHz
ld2: 8-bit width, 52.000 MHz
urtwn0 at uhub0 port 1
urtwn0: Realtek (0xbda) 802.11n NIC (0x8179), rev 2.00/0.00, addr 2
urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R, address e8:de:27:16:0c:81
urtwn0: 1 rx pipe, 2 tx pipes
urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
boot device: ld0
root on ld0a dumps on ld0b
root file system type: ffs
kern.module.path=/stand/evbarm/8.99.1/modules
WARNING: clock lost 6398 days
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!
Sat Jul 8 11:05:42 ADT 2017
Starting root file system check:
/dev/rld0a: file system is clean; not checking
Not resizing /: already correct size
swapctl: adding /dev/ld0b as swap device at priority 0
Starting file system checks:
/dev/rld0e: 22 files, 32340 free (8085 clusters)
random_seed: /var/db/entropy-file: Not present
Setting tty flags.
Setting sysctl variables:
ddb.onpanic: 1 -> 1
Starting network.
Hostname: sunxi
IPv6 mode: host
Configuring network interfaces:.
Adding interface aliases:.
Waiting for DAD to complete for statically configured addresses...
Starting dhcpcd.
Starting mdnsd.
Building databases: dev, utmp, utmpx.
Starting syslogd.
Mounting all file systems...
Clearing temporary files.
Updating fontconfig cache: done.
Creating a.out runtime link editor directory cache.
Checking quotas: done.
Setting securelevel: kern.securelevel: 0 -> 1
Starting virecover.
Checking for core dump...
savecore: no core dump
Starting devpubd.
Starting local daemons:.
Updating motd.
Starting ntpd.
Jul 8 11:05:58 sunxi ntpd[595]: ntp_rlimit: Cannot set RLIMIT_STACK: Invalid argument
Starting sshd.
Starting inetd.
Starting cron.
Sat Jul 8 11:06:02 ADT 2017
NetBSD/evbarm (sunxi) (console)
login:
</pre>https://blog.netbsd.org/tnf/entry/lldb_sanitizing_the_debugger_sLLDB: Sanitizing the debugger's runtimeKamil Rytarowski2017-06-06T15:18:20+00:002017-06-06T16:32:58+00:00This month I started to work on correcting of the ptrace(2) layer,
as test suites used to trigger failures on the kernel side.
This finally ended up sanitizing the LLDB runtime as well, addressing
LLDB and NetBSD userland bugs.This month I started to work on correcting of the ptrace(2) layer,
as test suites used to trigger failures on the kernel side.
This finally ended up sanitizing the LLDB runtime as well, addressing
LLDB and NetBSD userland bugs.
<p>
It turned out that more bugs were unveiled and this is not the final report on LLDB.
<p>
<h1>The good</h1>
<p>
Besides the greater enhancements this month I performed a cleanup in the ATF <b>ptrace</b>(2) tests again.
Additionally I have managed to unbreak the LLDB Debug build and to eliminate compiler warnings in the NetBSD Native Process Plugin.
<p>
It is worth noting that LLVM can run tests on NetBSD again,
the patch in gtest/LLVM has been installed by Joerg Sonnenberg and a more generic one has been submitted to the upstream googletest repository.
There was also an improvement in <b>ftruncate</b>(2) on the LLVM side (authored by Joerg).
<p>
Since LLD (the LLVM linker) is advancing rapidly, it improved support for NetBSD and it can link a functional executable on NetBSD.
I submitted a patch to stop crashing it on startup anymore.
It was nearly used for linking LLDB/NetBSD and it spotted a real linking error... however there are further issues that need to be addressed in the future.
Currently LLD is not part of the mainline LLDB tasks - it's part of improving the work environment.
This linker should reduce the linking time - compared to GNU linkers - of LLDB by a factor of 3x-10x and save precious developer time.
As of now LLDB linking can take minutes on a modern amd64 machine designed for performance.
<p>
<h2>Kernel correctness</h2>
<p>
I have researched (in pkgsrc-wip) initial support for multiple threads in the NetBSD Native Process Plugin.
This code revealed - when running the LLDB regression test-suite - new kernel bugs.
This unfortunately affects the usability of a debugger in a multithread environment in general and explains
why GDB was never doing its job properly in such circumstances.
<p>
One of the first errors was asserting kernel panic with <b>PT_*STEP</b>, when a debuggee has more than a single thread.
I have narrowed it down to lock primitives misuse in the <b>do_ptrace</b>() kernel code.
The fix has been committed.
<p>
<h2>LLDB and userland correctness</h2>
<p>
LLDB introduced support for <b>kevent</b>(2) and it contains the following function:
<p>
<pre>
Status MainLoop::RunImpl::Poll() {
in_events.resize(loop.m_read_fds.size());
unsigned i = 0;
for (auto &fd : loop.m_read_fds)
EV_SET(&in_events[i++], fd.first, EVFILT_READ, EV_ADD, 0, 0, 0);
num_events = kevent(loop.m_kqueue, in_events.data(), in_events.size(),
out_events, llvm::array_lengthof(out_events), nullptr);
if (num_events < 0)
return Status("kevent() failed with error %d\n", num_events);
return Status();
}
</pre>
<p>
It works on FreeBSD and MacOSX, however it broke on NetBSD.
<p>
Culprit line:
<p>
<pre>
EV_SET(&in_events[i++], fd.first, EVFILT_READ, EV_ADD, 0, 0, 0);
</pre>
<p>
FreeBSD defined <b>EV_SET</b>() as a macro this way:
<p>
<pre>
#define EV_SET(kevp_, a, b, c, d, e, f) do { \
struct kevent *kevp = (kevp_); \
(kevp)->ident = (a); \
(kevp)->filter = (b); \
(kevp)->flags = (c); \
(kevp)->fflags = (d); \
(kevp)->data = (e); \
(kevp)->udata = (f); \
} while(0)
</pre>
<p>
NetBSD version was different:
<p>
<pre>
#define EV_SET(kevp, a, b, c, d, e, f) \
do { \
(kevp)->ident = (a); \
(kevp)->filter = (b); \
(kevp)->flags = (c); \
(kevp)->fflags = (d); \
(kevp)->data = (e); \
(kevp)->udata = (f); \
} while (/* CONSTCOND */ 0)
</pre>
This resulted in heap damage, as <b>keyp</b> was incremented every time a value was
assigned to <b>(keyp)-></b>.
<p>
Without GCC asan and ubsan tools, finding this bug would be much more time consuming,
as the random memory corruption was affecting unrelated lambda function in a different part of the code.
<p>
To use the GCC sanitizers with packages from pkgsrc, on NetBSD-current, one has to use one or both of these lines:
<p>
<pre>
_WRAP_EXTRA_ARGS.CXX+= -fno-omit-frame-pointer -O0 -g -ggdb -U_FORTIFY_SOURCE -fsanitize=address -fsanitize=undefined -lasan -lubsan
CWRAPPERS_APPEND.cxx+= -fno-omit-frame-pointer -O0 -g -ggdb -U_FORTIFY_SOURCE -fsanitize=address -fsanitize=undefined -lasan -lubsan
</pre>
<p>
While there, I have fixed another - generic - bug in the LLVM headers.
The <b>class Triple</b> constructor hadn't initialized the <b>SubArch</b> field,
which upsetting the GCC address sanitizer.
It was triggered in LLDB in the following code:
<pre>
void ArchSpec::Clear() {
m_triple = llvm::Triple();
m_core = kCore_invalid;
m_byte_order = eByteOrderInvalid;
m_distribution_id.Clear();
m_flags = 0;
}
</pre>
<p>
I have filed a patch for review to address this.
<p>
<h1>The bad</h1>
<p>
Unfortunately this is not the full story and there is further mandatory work.
<p>
<h2>LLDB acceleration</h2>
<p>
The <b>EV_SET</b>() bug broke upstream LLDB over a month ago, and during this period the debugger
was significantly accelerated and parallelized.
It is difficult to declare it definitely, but it might be the reason why the tracer's runtime broke
due to threading desynchronization.
LLDB behaves differently when run standalone, under <b>ktruss</b>(1) and
under <b>gdb</b>(1) - the shared bug is that it always fails in one way or another, which isn't trivial to debug.
<p>
<h1>The ugly</h1>
<p>
There are also unpleasant issues at the core of the Operating System.
<p>
<h2>Kernel troubles</h2>
<p>
Another bug with single-step functions
that affects another aspect of correctness - this time with reliable execution of a program -
is that processes die in non-deterministic ways when single-stepped.
My current impression is that there is no appropriate translation between process and thread (LWP) states
under a debugger.
<p>
These issues are sibling problems to unreliable <b>PT_RESUME</b> and <b>PT_SUSPEND</b>.
<p>
In order to be able to appropriately address this,
I have diligently studied this month the <i>Solaris Internals</i> book to get a better image of
the design of the NetBSD kernel multiprocessing, which was modeled after this commercial UNIX.
<p>
<h1>Plan for the next milestone</h1>
<p>
The current troubles can be summarized as data races in the kernel and at the same time in LLDB.
I have decided to port the LLVM sanitizers, as I require the Thread Sanitizer (tsan).
Temporarily I have removed the code for tracing processes with multiple threads to
hide the known kernel bugs and focus on the LLDB races.
<p>
Unfortunately LLDB is not easily bisectable
(build time of the LLVM+Clang+LLDB stack, number of revisions), therefore the debugging has to be performed
on the most recent code from upstream trunk.
<p>
<h2>This work was sponsored by The NetBSD Foundation.</h2>
<p>
The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:
<p>
<a href="http://netbsd.org/donations/#how-to-donate">http://netbsd.org/donations/#how-to-donate</a>https://blog.netbsd.org/tnf/entry/netbsd_7_1_rc2_availableNetBSD 7.1_RC2 availablesnj2017-02-24T06:50:33+00:002017-02-24T06:50:33+00:00NetBSD 7.1_RC2 is now available, bringing numerous security fixes.<p>The second release candidate of NetBSD 7.1 is now available for download at:</p>
<p><a href="http://cdn.NetBSD.org/pub/NetBSD/NetBSD-7.1_RC2/">http://cdn.NetBSD.org/pub/NetBSD/NetBSD-7.1_RC2/</a></p>
<p>Those of you who prefer to build from source can continue to follow the netbsd-7 branch or use the netbsd-7-1-RC2 tag.</p>
<p>Most changes made since <a href="https://blog.netbsd.org/tnf/entry/netbsd_7_1_rc1_available">7.1_RC1</a> have been security fixes. See <a href="http://cvsweb.netbsd.org/bsdweb.cgi/src/doc/Attic/CHANGES-7.1?rev=1.1.2.156&content-type=text/x-cvsweb-markup&only_with_tag=netbsd-7">src/doc/CHANGES-7.1</a> for the full list.</p>
<p>Please help us out by testing 7.1_RC2. 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.</p>https://blog.netbsd.org/tnf/entry/pkgsrc_50th_release_interviews_ryopkgsrc 50th release interviews - Ryo ONODERAKamil Rytarowski2016-06-08T06:45:05+00:002016-06-08T06:45:05+00:00<p>The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.</p>
<p>The NetBSD team has prepared series of interviews with the authors. The next one is with Ryo ONODERA, a Japanese developer maintaining large C++ packages.</p>
<p>The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.</p>
<p>The NetBSD team has prepared series of interviews with the authors. The next one is with Ryo ONODERA, a Japanese developer maintaining large C++ packages.</p>
<p><b>Hi Ryo, please introduce yourself.</b></p>
<p>Hi,<br>
I am hobbyist.<br>
I maintain some large C++ packages, however my knowledge about recent C++ is poor.<br>
My current home work is to learn modern C++.</p>
<p><b>First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?</b></p>
<p>I am very glad to commit some changes for this remarkable 50th release.<br>
I feel 50 releases is very long history.<br>
The pkgsrc should be improved for next 100th anniversary.</p>
<p><b>What are the main benefits of the pkgsrc system?</b></p>
<p>The pkgsrc helps building from source.<br>
Building from source is interesting and I have learned many things from it. It is worth for experiencing.</p>
<p>I like up-to-date software.<br>
And I believe many people like latest software.<br>
Recently security concerns us.<br>
Sharing the recipe for latest software is getting worth, I believe.</p>
<p><b>Where and how do you use pkgsrc?</b></p>
<p>My laptop and home NAS run NetBSD/amd64.<br>
And of course I uses pkgsrc.<br>
And some day-job FreeBSD/amd64 servers also use pkgsrc.</p>
<p><b>What are the pkgsrc projects you are currently working on?</b></p>
<p>I am user of Mozilla Firefox (pkgsrc/www/firefox) and LibreOffice (pkgsrc/misc/libreoffice).<br>
I need latest ones. And I will keep them up-to-date.</p>
<p><b>If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?</b></p>
<p>I feel Fortran support is not so powerful. This should be improved.<br>
And Chromium browser should be ported to NetBSD.<br>
If I setup great machine, I will try to do it.</p>
<p><b>Do you have any practical tips to share with the pkgsrc users?</b></p>
<p>Good <code>/etc/mk.conf</code> or <code>/usr/pkg/etc/mk.conf</code> improve your pkgsrc experience.<br>
At least,<br>
<code>WRKOBJDIR=/usr/tmp/pkgsrc</code><br>
and<br>
<code>MASTER_SITE_OVERRIDE=http://ftp.XX.netbsd.org/pub/pkgsrc/distfiles/</code><br>
should improve your pkgsrc experience.</p>
<p><b>What's the best way to start contributing to pkgsrc and what needs to be done?</b></p>
<p>Updating simple package is good start point. For example, Font package or simple C software.<br>
I recommend to get commit bit for pkgsrc-wip.<br>
Committing your idea to the repository is invaluable experience.</p>
<p><b>Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków (1-3 July)?</b></p>
<p>Sadly, I cannot do long distance travel...<br>
If video streaming is provided, I will watch it carefully!</p>
<p>Thank you.<br>
Please use and contribute the pkgsrc!</p>
https://blog.netbsd.org/tnf/entry/pkgsrc_50th_release_interviews_jonathanpkgsrc 50th release interviews - Jonathan PerkinKamil Rytarowski2016-06-07T05:41:23+00:002016-06-07T05:41:23+00:00<p>The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.</p>
<p>The NetBSD team has prepared series of interviews with the authors. The next one is with Jonathan Perkin, a developer in the Joyent team.</p><p>The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.</p>
<p>The NetBSD team has prepared series of interviews with the authors. The next one is with Jonathan Perkin, a developer in the Joyent team.</p>
<p><b>Hi Jonathan, please introduce yourself.</b></p>
<p>Hello! Thirty-something, married with 4 kids. Obviously this means life
is usually pretty busy! I work as a Software Engineer for Joyent, where
we provide SmartOS zones (also known as "containers" these days) running
pkgsrc. This means I am in the privileged position of getting paid to
work full-time on what for many years has been my hobby.</p>
<p><b>First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?</b></p>
<p>I've been involved in pkgsrc since 2001, which was a few years before we
started the quarterly releases. Back then and during the early 2000s
there was a significant amount of work going into the pkgsrc
infrastructure to give it all the amazing features that we have today, but
that often meant the development branch had some rough edges while those
features were still being integrated across the tree.</p>
<p>The quarterly releases gave users confidence in building from a stable
release without unexpected breakages, and also helped developers to
schedule any large changes at the appropriate time.</p>
<p>At Joyent we make heavy use of the quarterly releases, producing new
SmartOS images for each branch, so for example our 16.1.x images are based
on pkgsrc-2016Q1, and so on.</p>
<p>Reaching the 50th release makes me feel old! It also makes me feel proud
that we've come a long way, yet still have people who want to be involved
and continue to develop both the infrastructure and packages.</p>
<p>I'd also like to highlight the fantastic work of the pkgsrc releng team,
who work to ensure the releases are kept up-to-date until the next one is
released. They do a great job and we benefit a lot from their work.</p>
<p><b>What are the main benefits of the pkgsrc system?</b></p>
<p>For me the big one is portability. This is what sets it apart from all
other package managers (and, increasingly, software in general), not just
because it runs on so many platforms but because it is such a core part of
the infrastructure and has been constantly developed and refined over the
years. We are now up to 23 distinct platforms, not counting different
distributions, and adding support for new ones is relatively easy thanks
to the huge amount of work which has gone into the infrastructure.</p>
<p>The other main benefit for me is the buildlink infrastructure and various
quality checks we have. As someone who distributes binary packages to end
users, it is imperative that those packages work as expected on the target
environment and don't have any embarrassing bugs. The buildlink system
ensures (amongst other things) that dependencies are correct and avoids
many issues around build host pollution. We then have a number of QA
scripts which analyse the generated package and ensure that the contents
are accurate, RPATHs are correct, etc. It's not perfect and there are
more tests we could write, but these catch a lot of mistakes that would
otherwise go undetected until a user submits a bug report.</p>
<p>Others for me are unprivileged support, signed packages, multi-version
support, pbulk, and probably a lot of other things I've forgotten and take
for granted!</p>
<p><b>Where and how do you use pkgsrc?</b></p>
<p>As mentioned above I work on pkgsrc for SmartOS. We are probably one of
the biggest users of pkgsrc in the world, shipping over a million package
downloads per year and rising to our users, not including those
distributed as part of our images or delivered from mirrors. This is
where I spend the majority of my time working on pkgsrc, and it is all
performed remotely on a number of zones running in the Joyent Public
Cloud. The packages we build are designed to run not just on SmartOS but
across all illumos distributions, and so I also have an OmniOS virtual
machine locally where I test new releases before announcing them.</p>
<p>As an OS X user, I also use pkgsrc on my MacBook. This is generally where
I perform any final tests before committing changes to pkgsrc so that I'm
reasonably confident they are correct, but I also install a bunch of
different packages from pkgsrc (mutt, ffmpeg, nodejs, jekyll, pstree etc)
for my day-to-day work. I also have a number of Mac build servers in my
loft and at the Joyent offices in San Francisco where I produce the binary
OS X packages we offer which are starting to become popular among users
looking for an alternative to Homebrew or MacPorts.</p>
<p>Finally, I have a few Linux machines also running in the Joyent Public
Cloud which I have configured for continuous bulk builds of pkgsrc trunk.
These help me to test any infrastructure changes I'm working on to ensure
that they are portable and correct.</p>
<p>On all of these machines I have written infrastructure to perform builds
inside chroots, ensuring a consistent environment and allowing me to work
on multiple things simultaneously. They all have various tools installed
(git, pkgvi, pkglint, etc) to aid my personal development workflow. We
then make heavy use of GitHub and Jenkins to manage automatic builds when
pushing to various branches.</p>
<p><b>What are the pkgsrc projects you are currently working on?</b></p>
<p>One of my priorities over the past year has been on performance. We build
a lot of packages (over 40,000 per branch, and we support up to 4 branches
simultaneously), and when the latest OpenSSL vulnerability hits it's
critical to get a fix out to users as quickly as possible. We're now at
the stage where, with a couple of patches, we can complete a full bulk
build in under 3 hours. There is still a lot of room for improvement
though, so recently I've been looking at slibtool (a libtool replacement
written in C) and supporting dash (a minimal POSIX shell which is faster
than bash).</p>
<p>There are also a few features we've developed at Joyent that I continue to
maintain, such as our multiarch work (which combines 32-bit and 64-bit
builds into a single package), additional multi-version support for MySQL
and Percona, SMF support, and a bunch of other patches which aren't yet
ready to be integrated.</p>
<p>I'm also very keen on getting new users into pkgsrc and turning them into
developers, so a lot of my time has been spent on making pkgsrc more
accessible, whether that's via our pkgbuild image (which gives users a
ready-made pkgsrc development environment) or the developer guides I've
written, or maintaining our https://pkgsrc.joyent.com/ website. There's
lots more to do in this area though to ensure users of all abilities can
contribute meaningfully.</p>
<p>Most of my day-to-day work though is general bug fixing and updating
packages, performing the quarterly release builds, and maintaining our
build infrastructure.</p>
<p><b>If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?</b></p>
<p>More users and developers! I am one of only a small handful of people who
are paid to work on pkgsrc, the vast majority of the work is done by our
amazing volunteer community. By its very nature pkgsrc requires constant
effort updating existing packages and adding new ones. This is something
that will never change and if anything the demand is accelerating, so we
need to ensure that we continue to train up and add new developers if we
are to keep up.</p>
<p>We need more documentation, more HOWTO guides, simpler infrastructure,
easier patch submission, faster and less onerous on-boarding of
developers, more bulk builds, more development machines. Plenty to be
getting on with!</p>
<p>Some technical changes I'd like to see are better upgrade support, launchd
support, integration of a working alternative pkg backend e.g. IPS, bmake
IPC (so we don't need to recompute the same variables over and over), and
many more!</p>
<p><b>Do you have any practical tips to share with the pkgsrc users?</b></p>
<p>Separate your build and install environments, so e.g. build in chroots or
in a VM then deploy the built packages to your target. Trying to update a
live install is the source of many problems, and there are few things more
frustrating than having your development environment be messed up by an
upgrade which fails part-way through.</p>
<p>For brand new users, document your experience and tell us what works and
what sucks. Many of us have been using pkgsrc for many many years, and
have lost your unique ability to identify problems, inconsistencies, and
bad documentation.</p>
<p>If you run into problems, connect to Freenode IRC #pkgsrc, and we'll try
to help you out. Hang out there even if you aren't having problems!</p>
<p>Finally, if you like pkgsrc, tell your friends, write blog posts, post to
Hacker News etc. It's amazing to me how unknown pkgsrc is despite being
around for so long, and how many people love it when they discover it.</p>
<p>More users leads to more developers, which leads to improved pkgsrc, which
leads to more users, which...</p>
<p><b>What's the best way to start contributing to pkgsrc and what needs to be done?</b></p>
<p>Pick something that interests you and just start working on it. The great
thing about pkgsrc is that there are open tasks for any ability, from
documentation fixes all the way through adding packages to rewriting large
parts of the infrastructure.</p>
<p>When you have something to contribute, don't worry about whether it's
perfect or how you are to deliver it. Just make it available and let us
know via PR, pull request, or just mail, and we can take it from there.</p>
<p><b>Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków (1-3 July)?</b></p>
<p>I am hoping to. If so I usually give a talk on what we've been working on
at Joyent over the past year, and will probably do the same.</p>
https://blog.netbsd.org/tnf/entry/pkgsrc_50th_release_interviews_bennypkgsrc 50th release interviews - Benny SiegertKamil Rytarowski2016-06-06T06:00:07+00:002016-06-06T06:00:07+00:00<p>The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.</p>
<p>The NetBSD team has prepared series of interviews with the authors. The next one is with Benny Siegert, a developer active in the release engineering team.</p><p>The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.</p>
<p>The NetBSD team has prepared series of interviews with the authors. The next one is with Benny Siegert, a developer active in the release engineering team.</p>
<p><b>Hi Benny, please introduce yourself.</b></p>
<p>I came to pkgsrc to my work on MirBSD. MirBSD only had a handful of
developers, so there was not enough manpower to maintain our own ports
tree -- not that we didn't try! In the end, we decided to support
pkgsrc, and I joined the NetBSD project as a developer, in an
amazingly quick and painless process.</p>
<p>My dayjob is as an SRE at Google; luckily, Google allows me to use my
20% time to work on pkgsrc. Working in this job has changed my
perspective on computing. I try to apply some of the SRE principles
(automate repetitive work, discipline in bug tracking, etc.) to my
work in pkgsrc.</p>
<p><b>First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?</b></p>
<p>Wow, 50 releases already! I find it remarkable how pkgsrc has
continued on a stable growth trajectory all these years. And together,
we have built one of the best and most advanced package collections.</p>
<p><b>What are the main benefits of the pkgsrc system?</b></p>
<p>pkgsrc runs on almost any platform that you are likely to use, from
NetBSD, other BSDs, commercial Unixes, Linux and Mac OS. Whatever the
platform, you have the same huge choice of up-to-date packages. You
can install them with a single command. That's pretty compelling.</p>
<p><b>Where and how do you use pkgsrc?</b></p>
<p>These days, I mostly use pkgsrc on NetBSD and Mac OS X. On the Mac,
pkgsrc may not be the most popular package collection but it still
works amazingly well. (By the way, I applaud the team behind
saveosx.org for making an effort to make pkgsrc more widely known
among Mac users.)</p>
<p><b>What are the pkgsrc projects you are currently working on?</b></p>
<p>By accident, I ended up being the maintainer of the pkgsrc stable
branch :) I am the one who handles most of the security updates to the
stable release.</p>
<p>As a fan of the Go programming language (and a contributor to the
project), I work on making software written in Go easy to use in
pkgsrc. There is infrastructure (go-package.mk) for packaging Go
software easily.</p>
<p><b>If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?</b></p>
<p>I would love to have more modern tooling. Gnats for bugs and CVS for
the repository are both outdated. But this is an ongoing discussion.</p>
<p>I would also like to have a more rigorous handling of security fixes.
The vulnerability DB is great and kept very well; on the other hand
actually fixing the vulnerabilities is sometimes neglected,
particularly for packages that not many people use.</p>
<p><b>Do you have any practical tips to share with the pkgsrc users?</b></p>
<p>- If you are on a machine where you do not have root access (such as a
shared Linux machine), you can bootstrap pkgsrc in unprivileged mode.
This way, everything builds and installs without needing to use root
rights.</p>
<p>- Read up on "pkg_admin audit" and use it regularly, to find when you
have packages with security problems installed.</p>
<p><b>What's the best way to start contributing to pkgsrc and what needs to be done?</b></p>
<p>pkgsrc-wip has a really low barrier to entry. Try to make your own
package for something simple and put it in wip.</p>
<p>Look in pkgsrc/doc/TODO, it contains some suggestions for things you
may want to work on. There is also a long list of suggested package
updates in there, you can send a PR with patch for these.</p>
<p>Finally, if you run "pkg_admin audit", as I suggested above, and
discover that pkgsrc does not contain a fix for a given vulnerability,
you can try to find a patch and submit it via PR. I would be more than
happy to apply it :)</p>
<p><b>Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków
(1-3 July)?</b></p>
<p>pkgsrcCon is a fantastic conference. I am not 100% sure yet if I can
make it but I will try to.</p>https://blog.netbsd.org/tnf/entry/pkgsrc_50th_release_interviews_thomaspkgsrc 50th release interviews - Thomas KlausnerKamil Rytarowski2016-06-02T06:26:48+00:002016-06-02T06:31:40+00:00<p>The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.</p>
<p>The NetBSD team has prepared series of interviews with the authors. The 3rd one is with Thomas Klausner, a developer well known for his maintainership of the pkgsrc-wip project.</p><p>The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.</p>
<p>The NetBSD team has prepared series of interviews with the authors. The 3rd one is with Thomas Klausner, a developer well known for his maintainership of the pkgsrc-wip project.</p>
<p><b>First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?</b></p>
<p>I'm very glad that pkgsrc that so many people find pkgsrc useful and
like working on it, both on pkgsrc itself and pkgsrc-wip.</p>
<p><b>What are the main benefits of the pkgsrc system?</b></p>
<p>Get packages installed on your system, and keep them up-to-date, and
don't worry about the underlying operating system.</p>
<p><b>Where and how do you use pkgsrc?</b></p>
<p>I use pkgsrc on my desktop machine at home and on various servers.</p>
<p><b>What are the pkgsrc projects you are currently working on?</b></p>
<p>Currently I have no single big project. I regularly try to keep a
couple of hundred packages up-to-date, and to feed back patches
upstream, so more software builds out-of-the-box. This also has the
advantages of making updates easier, and spreading awareness of pkgsrc
and NetBSD. Recently I've been more focusing on pushing upstream the
pkgsrc patches for firefox.</p>
<p><b>If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?</b></p>
<p>A recent issue is that we need to add a framework for PaX security
features; luckily, this is already implemented and just needs merging.
Longer term I think our binary package tools could use some love and
fresh code.</p>
<p><b>Do you have any practical tips to share with the pkgsrc users?</b></p>
<p>If you build your packages yourself, then use pkgtools/mksandbox to
create sandboxes and run bulk builds inside them using pkgtools/pbulk.
It makes life in general and updates in particular so much easier!</p>
<p><b>What's the best way to start contributing to pkgsrc and what needs to be done?</b></p>
<p>The easiest way is to start using pkgsrc on your own machines. Once
you feel comfortable with that you'll probably notice that you want to
update a package, or add a new one. If you reach that point, visit
<a href="http://pkgsrc.org/wip/">http://pkgsrc.org/wip/</a> to get commit access to the pkgsrc wip
repository.</p>
<p>If you need help, contact the pkgsrc-users mailing list or visit us in
#pkgsrc on freenode!</p>
<p><b>Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków (1-3 July)?</b></p>
<p>Definitely! I'm looking forward to meeting other pkgsrc developers
again or for the first time, and to many interesting talks.</p>
<p>Cheers,<br>
Thomas</p>
https://blog.netbsd.org/tnf/entry/64bit_arm_hardware_arrived64-bit ARM boards received from Rikomagicmartin2015-09-30T16:25:04+00:002015-10-02T07:03:02+00:00<p><a href="http://www.rikomagic.com">Rikomagic</a> was kind enough to provide engineering samples of their <a href="http://www.rikomagic.com/en/product/showpro_id_73_pid_20.html">RKM MK68</a> systems and documentation to a few NetBSD developers to assist in improving the aarch64 port.</p><p>Recently my <a href="http://www.rikomagic.com/en/product/showpro_id_73_pid_20.html">RKM MK68</a> machine arrived - a few NetBSD developers have got an engineering sample, kindly provided by Rikomagic, arranged by even more kind cooperation by Christophe Prévotaux from the <a href="https://www.bitrig.org">Bitrig Project</a>.</p>
<p>
It is a nice, small 8 core 64 bit arm machine:<p>
<img src="http://www.netbsd.org/~martin/rkm/mk68.jpg" /></p>
<!---- mirrored from: http://www.rikomagic.com/public/product/20150706/20150706113655_60644.jpg -->
<p>
Rikomagic provided some documentation, and they have been nice and responsive to our questions for more, so full support for this nice piece of hardware should be a matter of time only.</p>
<p>
It will require merging some changes for aarch64 that Matt Thomas already made, which also include a switch of mips to the generic pmap implementation - and unfortunately do not yet work on some mips variants.</p>
<p>
I plan to use my machine, once it runs NetBSD, to do regular test runs (of course).
But there are a lot of other things to do first, starting with soldering the serial console.</p>
<p>
However, I am about to leave for <a href="https://2015.eurobsdcon.org">EuroBSDCon 2015</a>, so this will have to wait until next week.</p>
<p>
P.S.: I am also still hoping for a 64bit tegra k1 based Chromebook (with free enough boot loader to run NetBSD). I need to replace my aging (huge and heavy) amd64 notebook finally!
</p>https://blog.netbsd.org/tnf/entry/netbsd_on_the_nvidia_jetsonNetBSD on the NVIDIA Jetson TK1jmcneill2015-07-25T18:28:38+00:002015-07-25T20:08:26+00:00<p>NetBSD is now running on the NVIDIA Jetson TK1 development kit. The <a href="https://developer.nvidia.com/jetson-tk1">NVIDIA Jetson TK1</a> is a quad-core ARMv7 development board that features an NVIDIA Tegra K1 (32-bit) SoC (quad-core Cortex-A15 @ 2.3GHz), 2GB RAM, gigabit ethernet, SATA, HDMI, mini-PCIE, and more.</p><p>The <a href="https://developer.nvidia.com/jetson-tk1">NVIDIA Jetson TK1</a> is a quad-core ARMv7 development board that features an NVIDIA Tegra K1 (32-bit) SoC (quad-core Cortex-A15 @ 2.3GHz), 2GB RAM, gigabit ethernet, SATA, HDMI, mini-PCIE, and more.</p>
<p>Since my <a href="http://mail-index.netbsd.org/port-arm/2015/05/31/msg003223.html">last status update</a> on the port, HDMI video and audio support have been added along with a handful of stability fixes.</p>
<p>NetBSD -current includes support for this board with the <i>JETSONTK1</i> kernel. The following hardware is supported:</p>
<ul>
<li>Cortex-A15 (multiprocessor)</li>
<li>CPU frequency scaling</li>
<li>ARM generic timer</li>
<li>Clock and reset controller</li>
<li>GPIO controller</li>
<li>MPIO / pinmux controller</li>
<li>Memory controller</li>
<li>Power management controller</li>
<li>I2C controller</li>
<li>UART serial console</li>
<li>Watchdog timer</li>
<li>SDMMC controller</li>
<li>USB 2.0 controller</li>
<li>AHCI SATA controller</li>
<li>HD audio controller (HDMI audio)</li>
<li>HDMI framebuffer console</li>
<li>PCI express controller, including mini-PCIE slot</li>
<li>On-board Realtek 8111G gigabit ethernet</li>
<li>Serial EEPROM</li>
<li>Temperature sensor</li>
<li>RF kill switch</li>
<li>Power button</li>
</ul>
<p>Of course, Xorg works too:</p>
<a href="http://www.netbsd.org/~jmcneill/IMG_20150725_153519.jpg">
<img src="http://www.netbsd.org/~jmcneill/IMG_20150725_153519.jpg" style="width: 100%;">
</a>
<p>See the <a href="http://wiki.netbsd.org/ports/evbarm/tegra/">NetBSD/evbarm on NVIDIA Tegra wiki page</a> for more details.</p>
<pre>
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 7.99.20 (JETSONTK1) #189: Sat Jul 25 12:47:31 ADT 2015
jmcneill@megatron.local:/Users/jmcneill/netbsd/src/sys/arch/evbarm/compile/obj/JETSONTK1
total memory = 2047 MB
avail memory = 2021 MB
sysctl_createv: sysctl_create(machine_arch) returned 17
timecounter: Timecounters tick every 10.000 msec
mainbus0 (root)
cpu0 at mainbus0 core 0: 2292 MHz Cortex-A15 r3p3 (Cortex V7A core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: sctlr: 0xc51c7d
cpu0: actlr: 0x80000041
cpu0: revidr: 0
cpu0: mpidr: 0x80000000
cpu0: isar: [0]=0x2101110 [1]=0x13112111 [2]=0x21232041 [3]=0x11112131, [4]=0x10011142, [5]=0
cpu0: mmfr: [0]=0x10201105 [1]=0x40000000 [2]=0x1240000 [3]=0x2102211
cpu0: pfr: [0]=0x1131 [1]=0x11011
cpu0: 32KB/64B 2-way L1 PIPT Instruction cache
cpu0: 32KB/64B 2-way write-back-locking-C L1 PIPT Data cache
cpu0: 2048KB/64B 16-way write-through L2 PIPT Unified cache
vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
vfp0: mvfr: [0]=0x10110222 [1]=0x11111111
cpu1 at mainbus0 core 1
cpu2 at mainbus0 core 2
cpu3 at mainbus0 core 3
armperiph0 at mainbus0
armgic0 at armperiph0: Generic Interrupt Controller, 192 sources (183 valid)
armgic0: 32 Priorities, 160 SPIs, 7 PPIs, 16 SGIs
armgtmr0 at armperiph0: ARMv7 Generic 64-bit Timer (12000 kHz)
armgtmr0: interrupting on irq 27
timecounter: Timecounter "armgtmr0" frequency 12000000 Hz quality 500
tegraio0 at mainbus0: Tegra K1 (T124)
tegracar0 at tegraio0: CAR
tegracar0: PLLX = 2292000000 Hz
tegracar0: PLLC = 88000000 Hz
tegracar0: PLLE = 292968 Hz
tegracar0: PLLU = 480000000 Hz
tegracar0: PLLP0 = 408000000 Hz
tegracar0: PLLD2 = 594000000 Hz
tegragpio0 at tegraio0: GPIO
gpio0 at tegragpio0 (A): 8 pins
gpio1 at tegragpio0 (B): 8 pins
gpio2 at tegragpio0 (C): 8 pins
gpio3 at tegragpio0 (D): 8 pins
gpio4 at tegragpio0 (E): 8 pins
gpio5 at tegragpio0 (F): 8 pins
gpio6 at tegragpio0 (G): 8 pins
gpio7 at tegragpio0 (H): 8 pins
gpio8 at tegragpio0 (I): 8 pins
gpio9 at tegragpio0 (J): 8 pins
gpio10 at tegragpio0 (K): 8 pins
gpio11 at tegragpio0 (L): 8 pins
gpio12 at tegragpio0 (M): 8 pins
gpio13 at tegragpio0 (N): 8 pins
gpio14 at tegragpio0 (O): 8 pins
gpio15 at tegragpio0 (P): 8 pins
gpio16 at tegragpio0 (Q): 8 pins
gpiobutton0 at gpio16 pins 0: Power button
gpio17 at tegragpio0 (R): 8 pins
gpio18 at tegragpio0 (S): 8 pins
gpio19 at tegragpio0 (T): 8 pins
gpio20 at tegragpio0 (U): 8 pins
gpio21 at tegragpio0 (V): 8 pins
gpio22 at tegragpio0 (W): 8 pins
gpio23 at tegragpio0 (X): 8 pins
gpiorfkill0 at gpio23 pins 7
gpio24 at tegragpio0 (Y): 8 pins
gpio25 at tegragpio0 (Z): 8 pins
gpio26 at tegragpio0 (AA): 8 pins
gpio27 at tegragpio0 (BB): 8 pins
gpio28 at tegragpio0 (CC): 8 pins
gpio29 at tegragpio0 (DD): 8 pins
gpio30 at tegragpio0 (EE): 8 pins
tegratimer0 at tegraio0: Timers
tegratimer0: default watchdog period is 10 seconds
tegramc0 at tegraio0: MC
tegrapmc0 at tegraio0: PMC
tegraxusbpad0 at tegraio0: XUSB PADCTL
tegrampio0 at tegraio0: MPIO
tegrai2c0 at tegraio0 port 0: I2C1
tegrai2c0: interrupting on irq 70
iic0 at tegrai2c0: I2C bus
seeprom0 at iic0 addr 0x56: AT24Cxx or compatible EEPROM: size 256
titemp0 at iic0 addr 0x4c: TMP451
tegrai2c1 at tegraio0 port 1: I2C2
tegrai2c1: interrupting on irq 116
iic1 at tegrai2c1: I2C bus
tegrai2c2 at tegraio0 port 2: I2C3
tegrai2c2: interrupting on irq 124
iic2 at tegrai2c2: I2C bus
tegrai2c3 at tegraio0 port 3: I2C4
tegrai2c3: interrupting on irq 152
iic3 at tegrai2c3: I2C bus
ddc0 at iic3 addr 0x50: DDC
tegrai2c4 at tegraio0 port 4: I2C5
tegrai2c4: interrupting on irq 85
iic4 at tegrai2c4: I2C bus
com3 at tegraio0 port 3: ns16550a, working fifo
com3: console
tegrartc0 at tegraio0: RTC
sdhc2 at tegraio0 port 2: SDMMC3
sdhc2: interrupting on irq 51
sdhc2: SDHC 4.0, rev 3, DMA, 48000 kHz, 3.0V 3.3V, 4096 byte blocks
sdmmc2 at sdhc2 slot 0
ahcisata0 at tegraio0: SATA
ahcisata0: interrupting on irq 55
ahcisata0: AHCI revision 1.31, 2 ports, 32 slots, CAP 0xe620ff01<PSC,SSC,PMD,ISS=0x2=Gen2,SAL,SALP,SSNTF,SNCQ,S64A>
atabus0 at ahcisata0 channel 0
hdaudio0 at tegraio0: HDA
hdaudio0: interrupting on irq 113
hdafg0 at hdaudio0: NVIDIA Tegra124 HDMI
hdafg0: HDMI00 8ch: Digital Out [Jack]
hdafg0: 8ch/0ch 48000Hz PCM16*
audio0 at hdafg0: full duplex, playback, capture, mmap, independent
ehci0 at tegraio0 port 0: USB1
ehci0: interrupting on irq 52
ehci0: EHCI version 1.10
ehci0: switching to host mode
usb0 at ehci0: USB revision 2.0
ehci1 at tegraio0 port 1: USB2
ehci1: interrupting on irq 53
ehci1: EHCI version 1.10
ehci1: switching to host mode
usb1 at ehci1: USB revision 2.0
ehci2 at tegraio0 port 2: USB3
ehci2: interrupting on irq 129
ehci2: EHCI version 1.10
ehci2: switching to host mode
usb2 at ehci2: USB revision 2.0
tegrahost1x0 at tegraio0: HOST1X
tegradc0 at tegraio0 port 0: DISPLAYA
tegradc1 at tegraio0 port 1: DISPLAYB
tegrahdmi0 at tegraio0: HDMI
tegrahdmi0: display connected
no data for est. mode 640x480x67
tegrahdmi0: connected to HDMI display
genfb0 at tegradc1 output tegrahdmi0
genfb0: framebuffer at 0x9ab00000, size 1920x1080, depth 32, stride 7680
wsdisplay0 at genfb0 kbdmux 1
wsmux1: connecting to wsdisplay0
wsdisplay0: screen 0-3 added (default, vt100 emulation)
tegrapcie0 at tegraio0: PCIE
tegrapcie0: interrupting on irq 130
pci0 at tegrapcie0 bus 0
pci0: memory space enabled, rd/line, rd/mult, wr/inv ok
ppb0 at pci0 dev 0 function 0: vendor 10de product 0e12 (rev. 0xa1)
ppb0: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x2 @ 5.0GT/s
ppb0: link is x1 @ 2.5GT/s
pci1 at ppb0 bus 1
pci1: memory space enabled, rd/line, wr/inv ok
athn0 at pci1 dev 0 function 0athn0: Atheros AR9285
athn0: rev 2 (1T1R), ROM rev 13, address 00:17:c4:d7:d0:58
athn0: interrupting at irq 130
athn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
athn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
ppb1 at pci0 dev 1 function 0: vendor 10de product 0e13 (rev. 0xa1)
ppb1: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x1 @ 5.0GT/s
ppb1: link is x1 @ 2.5GT/s
pci2 at ppb1 bus 2
pci2: memory space enabled, rd/line, wr/inv ok
re0 at pci2 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet (rev. 0x0c)
re0: interrupting at irq 130
re0: Ethernet address 00:04:4b:2f:51:a2
re0: using 512 tx descriptors
rgephy0 at re0 phy 7: RTL8251 1000BASE-T media interface, rev. 0
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
cpu2: 2292 MHz Cortex-A15 r3p3 (Cortex V7A core)
cpu2: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu2: sctlr: 0xc51c7d
cpu2: actlr: 0x80000040
cpu2: revidr: 0
cpu2: mpidr: 0x80000002
cpu2: isar: [0]=0x2101110 [1]=0x13112111 [2]=0x21232041 [3]=0x11112131, [4]=0x10011142, [5]=0
cpu2: mmfr: [0]=0x10201105 [1]=0x40000000 [2]=0x1240000 [3]=0x2102211
cpu2: pfr: [0]=0x1131 [1]=0x11011
cpu2: 32KB/64B 2-way L1 PIPT Instruction cache
cpu2: 32KB/64B 2-way write-back-locking-C L1 PIPT Data cache
cpu2: 2048KB/64B 16-way write-through L2 PIPT Unified cache
vfp2 at cpu2: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
vfp2: mvfr: [0]=0x10110222 [1]=0x11111111
cpu1: 2292 MHz Cortex-A15 r3p3 (Cortex V7A core)
cpu1: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu1: sctlr: 0xc51c7d
cpu1: actlr: 0x80000040
cpu1: revidr: 0
cpu1: mpidr: 0x80000001
cpu1: isar: [0]=0x2101110 [1]=0x13112111 [2]=0x21232041 [3]=0x11112131, [4]=0x10011142, [5]=0
cpu1: mmfr: [0]=0x10201105 [1]=0x40000000 [2]=0x1240000 [3]=0x2102211
cpu1: pfr: [0]=0x1131 [1]=0x11011
cpu1: 32KB/64B 2-way L1 PIPT Instruction cache
cpu1: 32KB/64B 2-way write-back-locking-C L1 PIPT Data cache
cpu1: 2048KB/64B 16-way write-through L2 PIPT Unified cache
vfp1 at cpu1: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
vfp1: mvfr: [0]=0x10110222 [1]=0x11111111
cpu3: 2292 MHz Cortex-A15 r3p3 (Cortex V7A core)
cpu3: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu3: sctlr: 0xc51c7d
cpu3: actlr: 0x80000040
cpu3: revidr: 0
cpu3: mpidr: 0x80000003
cpu3: isar: [0]=0x2101110 [1]=0x13112111 [2]=0x21232041 [3]=0x11112131, [4]=0x10011142, [5]=0
cpu3: mmfr: [0]=0x10201105 [1]=0x40000000 [2]=0x1240000 [3]=0x2102211
cpu3: pfr: [0]=0x1131 [1]=0x11011
cpu3: 32KB/64B 2-way L1 PIPT Instruction cache
cpu3: 32KB/64B 2-way write-back-locking-C L1 PIPT Data cache
cpu3: 2048KB/64B 16-way write-through L2 PIPT Unified cache
vfp3 at cpu3: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
vfp3: mvfr: [0]=0x10110222 [1]=0x11111111
uhub0 at usb0: Tegra EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub0: 1 port with 1 removable, self powered
uhub1 at usb2: Tegra EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub1: 1 port with 1 removable, self powered
uhub2 at usb1: Tegra EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub2: 1 port with 1 removable, self powered
ahcisata0 port 0: device present, speed: 3.0Gb/s
ld1 at sdmmc2: <0x27:0x5048:SD64G:0x30:0x01ce4def:0x0dc>
ld1: 59504 MB, 7585 cyl, 255 head, 63 sec, 512 bytes/sect x 121864192 sectors
ld1: 4-bit width, bus clock 48.000 MHz
wd0 at atabus0 drive 0
wd0: <OCZ-AGILITY3>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA)
uhidev0 at uhub0 port 1 configuration 1 interface 0
uhidev0: Logitech USB Receiver, rev 2.00/29.00, addr 2, iclass 3/1
ukbd0 at uhidev0: 8 modifier keys, 6 key codes
wskbd0 at ukbd0 mux 1
wskbd0: connecting to wsdisplay0
uhidev1 at uhub0 port 1 configuration 1 interface 1
uhidev1: Logitech USB Receiver, rev 2.00/29.00, addr 2, iclass 3/1
uhidev1: 17 report ids
ums0 at uhidev1 reportid 2: 16 buttons, W and Z dirs
wsmouse0 at ums0 mux 0
uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0
uhid2 at uhidev1 reportid 16: input=6, output=6, feature=0
uhid3 at uhidev1 reportid 17: input=19, output=19, feature=0
boot device: ld1
root on ld1a dumps on ld1b
mountroot: trying smbfs...
mountroot: trying ntfs...
mountroot: trying nfs...
mountroot: trying msdos...
mountroot: trying ext2fs...
mountroot: trying ffs...
root file system type: ffs
kern.module.path=/stand/evbarm/7.99.20/modules
WARNING: preposterous TOD clock time
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!
init: copying out path `/sbin/init' 11
WARNING: module error: vfs load failed for `compat', error 2
WARNING: module error: vfs load failed for `compat', error 2
WARNING: module error: vfs load failed for `compat', error 2
WARNING: module error: vfs load failed for `compat', error 2
WARNING: module error: vfs load failed for `compat', error 2
WARNING: module error: vfs load failed for `compat', error 2
re0: link state UP (was UNKNOWN)
athn0: link state UP (was UNKNOWN)
</pre>https://blog.netbsd.org/tnf/entry/ci20_status_updateCI20 status updatemacallan2015-06-11T18:15:11+00:002015-06-11T18:15:11+00:00Some more hardware support has been added including ohci, ethernet and I2C, also all RAM is usable now.<br>
I didn't really have much time to work on more hardware support on CI20 but it's been a while since the last post so here's what I've got:<br>
<ul>
<li>drivers for on-chip ehci and ohci have been added. Ohci works fine, ehci for some reason detects all high speed devices as full speed and hands them over to ohci. No idea why.
<li>I2C ports work now, including the onboard RTC. You have to hook up your own battery though.
<li>we're no longer limited to 256MB, all RAM is usable now.
<li>onboard ethernet is supported by the dme driver.
</ul>
There's also an unfinished driver for the SD/MMC ports.<br>
The RTC is a bit funny - according to the manual there's a Pericom RTC on iic4 addr 0x68 - not on my preproduction board. I've got something that looks like a PCF8563 at addr 0x51, and so do the production boards that I know of. Some pins on one of the expansion connectors seem to be for a battery but I haven't been able to confirm that yet. Either way, since the main connector is supposed to be Raspberry Pi compatible any RTC module for the RPi should Just Work(tm), with the appropriate line added to the kernel config.<br>
Some more work has been done under the hood, like some preparations for SMP support.<p>
Here's the obligatory boot transcript, complete with incomplete drivers and debug spam:<br>
<pre>
U-Boot SPL 2013.10-rc3-g9329ab16a204 (Jun 26 2014 - 09:43:22)
SDRAM H5TQ2G83CFR initialization... done
U-Boot 2013.10-rc3-g9329ab16a204 (Jun 26 2014 - 09:43:22)
Board: ci20 (Ingenic XBurst JZ4780 SoC)
DRAM: 1 GiB
NAND: 8192 MiB
MMC: jz_mmc msc1: 0
In: eserial3
Out: eserial3
Err: eserial3
Net: dm9000
ci20# dhcp
ERROR: resetting DM9000 -> not responding
dm9000 i/o: 0xb6000000, id: 0x90000a46
DM9000: running in 8 bit mode
MAC: d0:31:10:ff:7e:89
operating at 100M full duplex mode
BOOTP broadcast 1
DHCP client bound to address 192.168.0.47
*** Warning: no boot file name; using 'C0A8002F.img'
Using dm9000 device
TFTP from server 192.168.0.44; our IP address is 192.168.0.47
Filename 'C0A8002F.img'.
Load address: 0x88000000
Loading: #################################################################
##############################################
369.1 KiB/s
done
Bytes transferred = 1621771 (18bf0b hex)
ci20# bootm
## Booting kernel from Legacy Image at 88000000 ...
Image Name: evbmips 7.99.18 (CI20)
Image Type: MIPS NetBSD Kernel Image (gzip compressed)
Data Size: 1621707 Bytes = 1.5 MiB
Load Address: 80020000
Entry Point: 80020000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
subcommand not supported
ci20# g 80020000
## Starting application at 0x80020000 ...
pmap_steal_memory: seg 0: 0x6bf 0x6bf 0xffff 0xffff
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 7.99.18 (CI20) #20: Thu Jun 11 13:06:41 EDT 2015
ml@blackbush:/home/build/obj_evbmips32/sys/arch/evbmips/compile/CI20
Ingenic XBurst
total memory = 1024 MB
avail memory = 997 MB
mainbus0 (root)
cpu0 at mainbus0: 1200.00MHz (hz cycles = 120000, delay divisor = 12)
cpu0: Ingenic XBurst (0x3ee1024f) Rev. 79 with unknown FPC type (0x330000) Rev. 0
cpu0: 32 TLB entries, 16MB max page size
cpu0: 32KB/32B 8-way set-associative L1 instruction cache
cpu0: 32KB/32B 8-way set-associative write-back L1 data cache
com0 at mainbus0: Ingenic UART, working fifo
com0: console
apbus0 at mainbus0
JZ_CLKGR0 3f587fe0
JZ_CLKGR1 000073e0
JZ_SPCR0 00000000
JZ_SPCR1 00000000
JZ_SRBC 00000002
JZ_OPCR 000015e6
JZ_UHCCDR c0000000
dwctwo0 at apbus0 addr 0x13500000 irq 21: USB OTG controller
ohci0 at apbus0 addr 0x134a0000 irq 5: OHCI USB controller
ohci0: OHCI version 1.0
usb0 at ohci0: USB revision 1.0
ehci0 at apbus0 addr 0x13490000 irq 20: EHCI USB controller
48352 46418
UHCCDR: c0000000
UHCCDR: 60000017
caplength 10
ehci0: companion controller, 1 port each: ohci0
usb1 at ehci0: USB revision 2.0
dme0 at apbus0 addr 0x16000000: DM9000 Ethernet controller
jzgpio at apbus0 addr 0x10010000 not configured
jzgpio at apbus0 addr 0x10010100 not configured
jzgpio at apbus0 addr 0x10010200 not configured
jzgpio at apbus0 addr 0x10010300 not configured
jzgpio at apbus0 addr 0x10010400 not configured
jzgpio at apbus0 addr 0x10010500 not configured
jziic0 at apbus0 addr 0x10050000 irq 60: SMBus controller
iic0 at jziic0: I2C bus
jziic1 at apbus0 addr 0x10051000 irq 59: SMBus controller
iic1 at jziic1: I2C bus
jziic2 at apbus0 addr 0x10052000 irq 58: SMBus controller
iic2 at jziic2: I2C bus
jziic3 at apbus0 addr 0x10053000 irq 57: SMBus controller
iic3 at jziic3: I2C bus
jziic4 at apbus0 addr 0x10054000 irq 56: SMBus controller
iic4 at jziic4: I2C bus
pcf8563rtc0 at iic4 addr 0x51: NXP PCF8563 Real-time Clock
jzmmc0 at apbus0 addr 0x13450000 irq 37: SD/MMC controller
25227 24176
jzmmc0: going to use 25227 kHz
MSC*CDR: 80000000
sdmmc0 at jzmmc0
jzmmc1 at apbus0 addr 0x13460000 irq 36: SD/MMC controller
25227 24176
jzmmc1: going to use 25227 kHz
MSC*CDR: 20000018
sdmmc1 at jzmmc1
jzmmc2 at apbus0 addr 0x13470000 irq 35: SD/MMC controller
25227 24176
jzmmc2: going to use 25227 kHz
MSC*CDR: 00000000
sdmmc2 at jzmmc2
jzfb at apbus0 addr 0x13050000 not configured
JZ_CLKGR0 2c586780
JZ_CLKGR1 000060e0
usb2 at dwctwo0: USB revision 2.0
starting timer interrupt...
jzmmc_bus_clock: 400
sh: 6 freq: 394
sdmmc0: couldn't identify card
sdmmc0: no functions
jzmmc_bus_clock: 0
sh: 7 freq: 197
jzmmc_bus_clock: 400
sh: 6 freq: 394
sdmmc1: couldn't identify card
sdmmc1: no functions
jzmmc_bus_clock: 0
sh: 7 freq: 197
jzmmc_bus_clock: 400
sh: 6 freq: 394
sdmmc2: couldn't identify card
sdmmc2: no functions
jzmmc_bus_clock: 0
sh: 7 freq: 197
uhub0 at usb0: Ingenic OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1 at usb1: Ingenic EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub2 at usb2: Ingenic DWC2 root hub, class 9/0, rev 2.00/1.00, addr 1
PS_LS(1): 00001801
port1: 00001801
port2: 00000000
ehci0: handing over full speed device on port 1 to ohci0
umass0 at uhub2 port 1 configuration 1 interface 0
umass0: Generic Mass Storage Device, rev 2.00/1.05, addr 2
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <Single, Flash Reader, 1.00> disk removable
sd0: fabricating a geometry
sd0: 15193 MB, 15193 cyl, 64 head, 32 sec, 512 bytes/sect x 31116288 sectors
root on sd0a dumps on sd0b
sd0: fabricating a geometry
/: replaying log to memory
kern.module.path=/stand/evbmips/7.99.18/modules
pid 1(init): ABI set to O32 (e_flags=0x70001007)
Thu Jun 11 07:15:08 GMT 2015
uhub3 at uhub0 port 1: Terminus Technology USB 2.0 Hub [MTT], class 9/0, rev 2.00/1.00, addr 2
Starting root file system check:
/dev/rsd0a: file system is journaled; not checking
/: replaying log to disk
umass1 at uhub3 port 5 configuration 1 interface 0
umass1: LaCie P'9220 Mobile Drive, rev 2.10/0.06, addr 3
scsibus1 at umass1: 2 targets, 1 lun per target
sd1 at scsibus1 target 0 lun 0: <ST950032, 5AS, 0003> disk fixed
sd1: 465 GB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors
swapctl: adding /dev/sd1b as swap device at priority 0
Starting file system checks:
/dev/rsd0e: file system is journaled; not checking
/dev/rsd0g: file system is journaled; not checking
/dev/rsd0f: 1 files, 249856 free (31232 clusters)
/dev/rsd1e: file system is journaled; not checking
random_seed: /var/db/entropy-file: Not present
Setting tty flags.
Setting sysctl variables:
ddb.onpanic: 1 -> 0
Starting network.
Hostname: ci20
IPv6 mode: autoconfigured host
Configuring network interfaces: dme0.
Adding interface aliases:.
add net default: gateway 192.168.0.1
Waiting for DAD to complete for statically configured addresses...
/usr: replaying log to disk
Building databases: dev, dev, utmp, utmpx.
Starting syslogd.
Starting rpcbind.
Mounting all file systems...
/stuff: replaying log to disk
/home: replaying log to disk
Clearing temporary files.
Updating fontconfig cache: done.
Checking quotas: done.
/etc/rc: WARNING: /etc/exports is not readable.
/etc/rc.d/mountd exited with code 1
Setting securelevel: kern.securelevel: 0 -> 1
Starting virecover.
Checking for core dump...
savecore: no core dump
Starting local daemons:.
Updating motd.
Starting ntpd.
Starting sshd.
Starting mdnsd.
Jun 11 03:23:01 ci20 mdnsd: mDNSResponder (Engineering Build) starting
Starting inetd.
Starting cron.
The following components reported failures:
/etc/rc.d/mountd
See /var/run/rc.log for more information.
Thu Jun 11 03:23:02 EDT 2015
NetBSD/evbmips (ci20) (console)
login:
</pre>https://blog.netbsd.org/tnf/entry/netbsd_ported_to_hardkernel_odroidNetBSD ported to Hardkernel ODROID-C1jmcneill2015-03-18T23:11:24+00:002015-03-18T23:11:24+00:00<p>NetBSD was recently ported to the Hardkernel ODROID-C1. The <a href="http://www.hardkernel.com/main/products/prdt_info.php?g_code=G141578608433">Hardkernel ODROID-C1</a> is a quad-core ARMv7 development board that features an Amlogic S805 SoC (quad-core Cortex-A5 @ 1.5GHz), 1GB RAM and gigabit ethernet for $35 USD.</p><p>The <a href="http://www.hardkernel.com/main/products/prdt_info.php?g_code=G141578608433">Hardkernel ODROID-C1</a> is a quad-core ARMv7 development board that features an Amlogic S805 SoC (quad-core Cortex-A5 @ 1.5GHz), 1GB RAM and gigabit ethernet for $35 USD.</p>
<p>The ODROID-C1 is the first Cortex-A5 board supported by NetBSD. Matt Thomas (<i>matt@</i>) added initial Cortex-A5 support to the tree, and based on his work I added support for the Amlogic S805 SoC.</p>
<p>NetBSD -current (and soon 7.0) includes support for this board with the <i>ODROID-C1</i> kernel. The following hardware is supported:</p>
<ul>
<li>Cortex-A5 (multiprocessor)</li>
<li>CPU frequency scaling</li>
<li>L2 cache controller</li>
<li>Interrupt controller</li>
<li>Cortex-A5 global timer</li>
<li>Cortex-A5 watchdog</li>
<li>UART console</li>
<li>USB OTG controller</li>
<li>Gigabit ethernet</li>
<li>SD card slot</li>
<li>Hardware random number generator</li>
</ul>
<p>More information on the <a href="https://wiki.netbsd.org/ports/evbarm/odroid-c1/">NetBSD/evbarm on Hardkernel ODROID-C1 wiki page</a>.</p>
<pre>
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 7.99.5 (ODROID-C1) #350: Wed Mar 18 19:45:17 ADT 2015
Jared@Jared-PC:/cygdrive/d/netbsd/src/sys/arch/evbarm/compile/obj/ODROID-C1
total memory = 1024 MB
avail memory = 1008 MB
sysctl_createv: sysctl_create(machine_arch) returned 17
mainbus0 (root)
cpu0 at mainbus0 core 0: 1512 MHz Cortex-A5 r0p1 (Cortex V7A core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB/32B 2-way L1 VIPT Instruction cache
cpu0: 32KB/32B 4-way write-back-locking-C L1 PIPT Data cache
cpu0: 512KB/32B 8-way write-back L2 PIPT Unified cache
vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
cpu1 at mainbus0 core 1
cpu2 at mainbus0 core 2
cpu3 at mainbus0 core 3
armperiph0 at mainbus0
armgic0 at armperiph0: Generic Interrupt Controller, 256 sources (245 valid)
armgic0: 32 Priorities, 224 SPIs, 5 PPIs, 16 SGIs
a9tmr0 at armperiph0: A5 Global 64-bit Timer (378 MHz)
a9tmr0: interrupting on irq 27
a9wdt0 at armperiph0: A5 Watchdog Timer, default period is 12 seconds
arml2cc0 at armperiph0: ARM PL310 r3p3 L2 Cache Controller (disabled)
arml2cc0: cache enabled
amlogicio0 at mainbus0
amlogiccom0 at amlogicio0 port 0: console
amlogiccom0: interrupting at irq 122
amlogicrng0 at amlogicio0
dwctwo0 at amlogicio0 port 0: USB controller
dwctwo1 at amlogicio0 port 1: USB controller
awge0 at amlogicio0: Gigabit Ethernet Controller
awge0: interrupting on irq 40
awge0: Ethernet address: 00:1e:06:c3:7e:be
rgephy0 at awge0 phy 0: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 6
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
rgephy1 at awge0 phy 1: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 6
rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
amlogicsdhc0 at amlogicio0 port 1: SDHC controller
amlogicsdhc0: interrupting on irq 110
usb0 at dwctwo0: USB revision 2.0
usb1 at dwctwo1: USB revision 2.0
cpu3: 1512 MHz Cortex-A5 r0p1 (Cortex V7A core)
cpu3: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu3: 32KB/32B 2-way L1 VIPT Instruction cache
cpu3: 32KB/32B 4-way write-back-locking-C L1 PIPT Data cache
cpu3: 512KB/32B 8-way write-back L2 PIPT Unified cache
vfp3 at cpu3: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
cpu2: 1512 MHz Cortex-A5 r0p1 (Cortex V7A core)
cpu2: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu2: 32KB/32B 2-way L1 VIPT Instruction cache
cpu2: 32KB/32B 4-way write-back-locking-C L1 PIPT Data cache
cpu2: 512KB/32B 8-way write-back L2 PIPT Unified cache
vfp2 at cpu2: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
cpu1: 1512 MHz Cortex-A5 r0p1 (Cortex V7A core)
cpu1: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu1: 32KB/32B 2-way L1 VIPT Instruction cache
cpu1: 32KB/32B 4-way write-back-locking-C L1 PIPT Data cache
cpu1: 512KB/32B 8-way write-back L2 PIPT Unified cache
vfp1 at cpu1: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
sdmmc0 at amlogicsdhc0
uhub0 at usb0: vendor 0000 DWC2 root hub, class 9/0, rev 2.00/1.00, addr 1
uhub1 at usb1: vendor 0000 DWC2 root hub, class 9/0, rev 2.00/1.00, addr 1
ld0 at sdmmc0: <0x03:0x5344:SU08G:0x80:0x1cda770b:0x0ca>
ld0: 7580 MB, 3850 cyl, 64 head, 63 sec, 512 bytes/sect x 15523840 sectors
ld0: 4-bit width, bus clock 50.000 MHz
uhub2 at uhub1 port 1: vendor 05e3 USB2.0 Hub, class 9/0, rev 2.00/32.98, addr 2
uhub2: multiple transaction translators
boot device: ld0
root on ld0f dumps on ld0b
root file system type: ffs
kern.module.path=/stand/evbarm/7.99.5/modules
WARNING: no TOD clock present
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!
Wed Mar 18 22:45:46 UTC 2015
Starting root file system check:
/dev/rld0f: file system is clean; not checking
Starting file system checks:
/dev/rld0e: 5 files, 52556 free (13139 clusters)
random_seed: /var/db/entropy-file: Not present
Setting tty flags.
Setting sysctl variables:
ddb.onpanic: 1 -> 0
Starting network.
Hostname: empusa
IPv6 mode: host
Configuring network interfaces:.
Adding interface aliases:.
Waiting for DAD completion for statically configured addresses...
Starting dhcpcd.
Building databases: dev, utmp, utmpx.
Starting syslogd.
Mounting all file systems...
Clearing temporary files.
Updating fontconfig cache: done.
Creating a.out runtime link editor directory cache.
Checking quotas: done.
Setting securelevel: kern.securelevel: 0 -> 1
Starting virecover.
Starting local daemons:.
Updating motd.
Starting ntpd.
Starting sshd.
Starting mdnsd.
Mar 18 22:46:07 empusa mdnsd: mDNSResponder (Engineering Build) starting
Starting inetd.
Starting cron.
Wed Mar 18 22:46:08 UTC 2015
NetBSD/evbarm (empusa) (console)
login:
</pre>
https://blog.netbsd.org/tnf/entry/raspberry_pi_2_support_addedRaspberry PI 2 support addedNick Hudson2015-03-09T12:19:54+00:002015-03-09T15:27:40+00:00<p>Initial support is now available for the Raspberry PI 2.</p><p>Recent commits just added support for the Raspberry Pi 2 inside NetBSD.</p>
<p>It comes with all the peripherals and GPU acceleration features that are available on the first Raspberry Pi, together with a Cortex A7 processor capable of running at 900MHz.</p>
<p>Head directly to the installation notes available in <a href="https://wiki.netbsd.org/ports/evbarm/raspberry_pi/">Raspberry Pi's entry in the NetBSD Wiki</a> for a quick way to get your system up and rolling.</p>
<p>Stay tuned for multiprocessor support!</p>
<pre>
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 7.99.5 (RPI2) #6: Fri Mar 6 16:33:41 GMT 2015
nick@zoom:/wrk/commit/obj.evbearmv7hf-el/wrk/commit/src/sys/arch/evbarm/compile/RPI2
total memory = 944 MB
avail memory = 928 MB
sysctl_createv: sysctl_create(machine_arch) returned 17
timecounter: Timecounters tick every 10.000 msec
mainbus0 (root)
cpu0 at mainbus0 core 0: 600 MHz Cortex-A7 r0p5 (Cortex V7A core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: isar: [0]=0x2101110 [1]=0x13112111 [2]=0x21232041 [3]=0x11112131, [4]=0x10011142, [5]=0
cpu0: mmfr: [0]=0x10101105 [1]=0x40000000 [2]=0x1240000 [3]=0x2102211
cpu0: pfr: [0]=0x1131 [1]=0x11011
cpu0: 32KB/32B 2-way L1 VIPT Instruction cache
cpu0: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu0: 512KB/64B 8-way write-through L2 PIPT Unified cache
vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
vfp0: mvfr: [0]=0x10110222 [1]=0x11111111
cpu1 at mainbus0 core 1: disabled (unresponsive)
cpu2 at mainbus0 core 2: disabled (unresponsive)
cpu3 at mainbus0 core 3: disabled (unresponsive)
obio0 at mainbus0
bcmicu0 at obio0
armgtmr0 at obio0: ARMv7 Generic 64-bit Timer (19200 kHz)
armgtmr0: interrupting on irq 99
timecounter: Timecounter "armgtmr0" frequency 19200000 Hz quality 500
bcmmbox0 at obio0 intr 65: VC mailbox
vcmbox0 at bcmmbox0
vchiq0 at obio0 intr 66: BCM2835 VCHIQ
bcmpm0 at obio0: Power management, Reset and Watchdog controller
bcmdmac0 at obio0: DMA0 DMA2 DMA4 DMA5 DMA8 DMA9 DMA10
bcmrng0 at obio0: RNG
plcom0 at obio0 intr 57
plcom0: txfifo disabled
plcom0: console
genfb0 at obio0: switching to framebuffer console
genfb0: framebuffer at 0x3d6fa000, size 1280x1024, depth 32, stride 5120
wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation)
wsmux1: connecting to wsdisplay0
wsdisplay0: screen 1-3 added (default, vt100 emulation)
sdhc0 at obio0 intr 62: SDHC controller
sdhc0: interrupting on intr 62
dwctwo0 at obio0 intr 9: USB controller
bcmspi0 at obio0 intr 54: SPI
spi0 at bcmspi0: SPI bus
bsciic0 at obio0 intr 53: BSC0
iic0 at bsciic0: I2C bus
bsciic1 at obio0 intr 53: BSC1
iic1 at bsciic1: I2C bus
bcmgpio0 at obio0: GPIO [0...31]
gpio0 at bcmgpio0: 32 pins
bcmgpio1 at obio0: GPIO [32...53]
gpio1 at bcmgpio1: 22 pins
usb0 at dwctwo0: USB revision 2.0
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
sdhc0: SD Host Specification 3.0, rev.153
sdhc0: using DMA transfer
sdmmc0 at sdhc0 slot 0
uhub0 at usb0: vendor 0000 DWC2 root hub, class 9/0, rev 2.00/1.00, addr 1
uhub0: 1 port with 1 removable, self powered
ld0 at sdmmc0: <0x03:0x5344:SL08G:0x80:0x0bcb2d39:0x08a>
ld0: 7580 MB, 3850 cyl, 64 head, 63 sec, 512 bytes/sect x 15523840 sectors
ld0: 4-bit width, bus clock 50.000 MHz
uhub1 at uhub0 port 1: vendor 0424 product 9514, class 9/0, rev 2.00/2.00, addr 2
uhub1: multiple transaction translators
uhub1: 5 ports with 4 removable, self powered
usmsc0 at uhub1 port 1
usmsc0: vendor 0424 product ec00, rev 2.00/2.00, addr 3
usmsc0: Ethernet address b8:27:eb:13:82:0f
ukphy0 at usmsc0 phy 1: OUI 0x00800f, model 0x000c, rev. 3
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
boot device: ld0
root on ld0a dumps on ld0b
mountroot: trying nfs...
mountroot: trying msdos...
mountroot: trying ext2fs...
mountroot: trying ffs...
root file system type: ffs
kern.module.path=/stand/evbarm/7.99.5/modules
vchiq: local ver 6 (min 3), remote ver 6.
vcaudio0 at vchiq0: auds
vchiq_get_state: g_state.remote->initialised != 1 (0)
vchiq: vchiq_initialise: videocore initialized after 1 retries
WARNING: no TOD clock present
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!
</pre>https://blog.netbsd.org/tnf/entry/ci20_reaches_userlandCI20 reaches userlandmacallan2015-03-07T16:00:37+00:002015-03-07T16:00:37+00:00My CI20 now makes it to userland, with root and ethernet via USB.<br>My CI20 now makes it to userland, with root and ethernet via USB. Here's the transcript:
<pre>
U-Boot SPL 2013.10-rc3-g9329ab16a204 (Jun 26 2014 - 09:43:22)
SDRAM H5TQ2G83CFR initialization... done
U-Boot 2013.10-rc3-g9329ab16a204 (Jun 26 2014 - 09:43:22)
Board: ci20 (Ingenic XBurst JZ4780 SoC)
DRAM: 1 GiB
NAND: 8192 MiB
MMC: jz_mmc msc1: 0
In: eserial3
Out: eserial3
Err: eserial3
Net: dm9000
ci20# dhcp
ERROR: resetting DM9000 -> not responding
dm9000 i/o: 0xb6000000, id: 0x90000a46
DM9000: running in 8 bit mode
MAC: d0:31:10:ff:7e:89
operating at 100M full duplex mode
BOOTP broadcast 1
DHCP client bound to address 192.168.0.47
*** Warning: no boot file name; using 'C0A8002F.img'
Using dm9000 device
TFTP from server 192.168.0.44; our IP address is 192.168.0.47
Filename 'C0A8002F.img'.
Load address: 0x88000000
Loading: #################################################################
#######################################
347.7 KiB/s
done
Bytes transferred = 1519445 (172f55 hex)
ci20# bootm
## Booting kernel from Legacy Image at 88000000 ...
Image Name: evbmips 7.99.5 (CI20)
Image Type: MIPS NetBSD Kernel Image (gzip compressed)
Data Size: 1519381 Bytes = 1.4 MiB
Load Address: 80020000
Entry Point: 80020000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
subcommand not supported
ci20# g 80020000
## Starting applicatipmap_steal_memory: seg 0: 0x3b3 0x3b3 0xffff 0xffff
Loaded initial symtab at 0x80304754, strtab at 0x8032d934, # entries 10499
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 7.99.5 (CI20) #170: Sat Mar 7 10:43:03 EST 2015
ml@blackbush:/home/build/obj_evbmips32/sys/arch/evbmips/compile/CI20
Ingenic XBurst
total memory = 256 MB
avail memory = 247 MB
mainbus0 (root)
cpu0 at mainbus0: 1200.00MHz (hz cycles = 120000, delay divisor = 12)
cpu0: Ingenic XBurst (0x3ee1024f) Rev. 79 with unknown FPC type (0x330000) Rev. 0
cpu0: 32 TLB entries, 16MB max page size
cpu0: 32KB/32B 8-way set-associative L1 instruction cache
cpu0: 32KB/32B 8-way set-associative write-back L1 data cache
com0 at mainbus0: Ingenic UART, working fifo
com0: console
apbus0 at mainbus0
dwctwo0 at apbus0: USB controller
jzgpio at apbus0 not configured
jzfb at apbus0 not configured
usb0 at dwctwo0: USB revision 2.0
starting timer interrupt...
uhub0 at usb0: vendor 0000 DWC2 root hub, class 9/0, rev 2.00/1.00, addr 1
uhub1 at uhub0 port 1: vendor 1a40 USB 2.0 Hub [MTT], class 9/0, rev 2.00/1.00, addr 2
uhub1: multiple transaction translators
umass0 at uhub1 port 1 configuration 1 interface 0
umass0: LaCie P'9220 Mobile Drive, rev 2.10/0.06, addr 3
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <ST950032, 5AS, 0003> disk fixed
sd0: 465 GB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors
umass1 at uhub1 port 2 configuration 1 interface 0
umass1: Apple Inc. iPod, rev 2.00/0.01, addr 4
scsibus1 at umass1: 2 targets, 1 lun per target
sd1 at scsibus1 target 0 lun 0: <Apple, iPod, 1.62> disk removable
uhidev0 at uhub1 port 4 configuration 1 interface 0
uhidev0: vendor 04d9 VISENTA V1, rev 1.10/1.00, addr 5, iclass 3/1
ukbd0 at uhidev0: 8 modifier keys, 6 key codes
wskbd0 at ukbd0 (mux ignored)
uhidev1 at uhub1 port 4 configuration 1 interface 1
uhidev1: vendor 04d9 VISENTA V1, rev 1.10/1.00, addr 5, iclass 3/1
uhidev1: 3 report ids
ums0 at uhidev1 reportid 1: 3 buttons, W and Z dirs
wsmouse0 at ums0 (mux ignored)
uhid0 at uhidev1 reportid 2: input=2, output=0, feature=0
uhid1 at uhidev1 reportid 3: input=1, output=0, feature=0
sd1: fabricating a geometry
sd1: 7601 MB, 950 cyl, 64 head, 32 sec, 4096 bytes/sect x 1946049 sectors
uhub2 at uhub1 port 6: vendor 03eb Standard USB Hub, class 9/0, rev 1.10/3.00, addr 6
axe0 at uhub2 port 1
axe0: D-LINK CORPORAION DUB-E100, rev 2.00/10.01, addr 7
axe0: Ethernet address 00:80:c8:37:00:e1
ukphy0 at axe0 phy 3: OUI 0x0009c3, model 0x0005, rev. 4
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
root on sd0a dumps on sd0b
kern.module.path=/stand/evbmips/7.99.5/modules
WARNING: no TOD clock present
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!
init: copying out path `/sbin/init' 11
pid 1(init): ABI set to O32 (e_flags=0x70001007)
Thu Mar 5 18:27:33 UTC 2015
Not checking /: fs_passno = 0 in /etc/fstab
swapctl: adding /dev/sd0b as swap device at priority 0
Starting file system checks:
random_seed: /var/db/entropy-file: Not present
Setting tty flags.
Setting sysctl variables:
ddb.onpanic: 1 -> 0
Starting network.
Hostname: ci20
IPv6 mode: autoconfigured host
Configuring network interfaces: axe0.
Adding interface aliases:.
add net default: gateway 192.168.0.1
Waiting for DAD to complete for statically configured addresses...
axe0: link state UP (was UNKNOWN)
Building databases: dev, utmp, utmpx.
Starting syslogd.
Starting rpcbind.
Mounting all file systems...
Clearing temporary files.
Checking quotas: done.
Setting securelevel: kern.securelevel: 0 -> 1
Starting virecover.
Checking for core dump...
savecore: no core dump
Starting local daemons:.
Updating motd.
Starting sshd.
Starting inetd.
Starting cron.
Thu Mar 5 18:27:55 UTC 2015
NetBSD/evbmips (ci20) (console)
login:
</pre>https://blog.netbsd.org/tnf/entry/raspberry_pi_gpu_acceleration_inRaspberry Pi GPU acceleration in NetBSD 7jmcneill2015-01-30T10:30:22+00:002015-01-30T11:51:08+00:00<p>With the latest updates to NetBSD 7, the <a href="https://wiki.netbsd.org/ports/evbarm/raspberry_pi/">Raspberry Pi</a> port now supports hardware acceleration using the built-in Broadcom VideoCore IV GPU. This enables 3D graphics acceleration and hardware accelerated video playback, a first for NetBSD/arm.</p><p>
With the latest updates to NetBSD 7, the <a href="https://wiki.netbsd.org/ports/evbarm/raspberry_pi/">Raspberry Pi</a> port now supports hardware acceleration using the built-in Broadcom VideoCore IV GPU. This enables 3D graphics acceleration and hardware accelerated video playback, a first for NetBSD/arm.
</p>
<p>
The <a href="http://pkgsrc.se/misc/raspberrypi-userland">misc/raspberrypi-userland</a> package in pkgsrc includes the client libraries to get started. Some packages have been created to take advantage of this already, with more on the way:
</p>
<ul>
<li>OMXPlayer: <a href="http://pkgsrc.se/multimedia/omxplayer">multimedia/omxplayer</a> for video playback</li>
<li>GStreamer: <a href="http://pkgsrc.se/multimedia/gst-plugins1-omx">multimedia/gst-plugins1-omx</a> for decode, and <a href="http://pkgsrc.se/multimedia/gst-plugins1-egl-opengl">multimedia/gst-plugins1-egl-opengl</a> for a video sink</li>
<li>ioquake3: <a href="http://pkgsrc.se/games/ioquake3-raspberrypi">games/ioquake3-raspberrypi</a></li>
</ul>
<p>
For both omxplayer and ioquake3, make sure that the user running them has permissions to /dev/vchiq. In addition, ioquake3 needs permissions to /dev/wsmouse.
</p>
<pre>
# usermod -G wheel jmcneill
# chmod 660 /dev/vchiq /dev/wsmouse
</pre>
<p>
The default GPU memory allocation may not be sufficient for ioquake3. Add <i>gpu_mem=128</i> or <i>gpu_mem=192</i> to /boot/config.txt if you run into any issues.
</p>
<p>
More information can be found on the <a href="https://wiki.netbsd.org/ports/evbarm/raspberry_pi/">NetBSD Wiki</a>.
</p>https://blog.netbsd.org/tnf/entry/the_state_of_accelerated_graphics1The State of Accelerated Graphics on NetBSD/sparc, updatedmacallan2015-01-07T11:40:40+00:002015-01-07T11:40:40+00:00This is an update to <a href="https://blog.netbsd.org/tnf/entry/the_state_of_accelerated_graphics">this post</a>.<br>
Some new drivers were added ( cgtwelve, mgx ), others got improvements ( SX acceleration, support for 8bit tcx ).This is an update to <a href="https://blog.netbsd.org/tnf/entry/the_state_of_accelerated_graphics">this post</a>.<br>
Some new drivers were added ( cgtwelve, mgx ), others got improvements ( SX acceleration, support for 8bit tcx ).<br>
<ul><li>Sun CG3 - has kernel support and works in X with the wsfb driver, the hardware doesn't support a hardware cursor or any kind of acceleration so we won't bother with a dedicated X driver. The hardware supports 8 bit colour only.</li>
<li>Sun CG6 family, including GX, TGX, XGX and their plus variants - supported with acceleration in both the kernel and X with the suncg6 driver. Hardware cursor is supported, the hardware supports 8 bit colour only.</li>
<li>Sun ZX/Leo - has accelerated kernel support but no X yet. The sunleo driver from Xorg should work without changes but doesn't support any kind of acceleration yet. The console runs in 8 bit, X will support 24 bit.</li>
<li>Sun BW2 - has kernel support, should work with the wsfb driver in X.The board doesn't support a hardware cursor or any kind of acceleration. Hardware is monochrome only.</li>
<li>Weitek P9100 - found in Tadpole SPARCbook 3 series laptops, supported with acceleration in both the kernel and X with the pnozz driver. Hardware cursor is supported. The console runs in 8 bit, X can run in 8, 16 or 24 bit colour.</li>
<li>Sun S24/TCX - supported with acceleration in both the kernel and X with the suntcx driver. A hardware cursor is supported ( only on S24, the 8bit TCX's DAC doesn't support it ).The console runs in 8 bit, X in 8 or 24 bit.</li>
<li>Sun CG14 - supported with acceleration ( using the new sx driver ) and hardware cursor in both the kernel and X. The console runs in 8 bit, X in 24 bit. The X driver supports some xrender acceleration as well.</li>
<li>Fujitsu AG-10e - supported with acceleration in both the kernel and X, a hardware cursor is supported. The console runs in 8 bit, X in 24 bit.</li>
<li>IGS 1682 found in JavaStation 10 / Krups - supported, but the chip lacks any acceleration features. It does support a hardware cursor though which the wsfb driver can use. Currently X is limited to 8 bit colour alhough the hardware supports up to 24bit.</li>
<li>Sun CG12 / Matrox SG3 - supported without acceleration in both the kernel and X. The console runs in monochrome or 8 bit, X in 24 bit.</li>
<li>Southland Media Systems (now Quantum 3D) MGX - supported with acceleration as console, X is currently limited to wsfb in 8 bit. No hardware cursor support in the driver yet .</li>
</ul>
<p>All boards with dedicated drivers will work as primary or secondary heads in X, boards which use wsfb will only work in X when they are the system console. For example, you can run an SS20 with a cg14 as console, an AG-10e and two CG6 with four heads.</p>
<p>There is also a generic kernel driver ( genfb at sbus ) which may or may not work with graphics hardware not listed here, depending on the board's firmware. If it provides standard properties for width, height, colour depth, stride and framebuffer address it should work but not all boards do this. For example, the ZX doesn't give a framebuffer address and there is no reason to assume it's the only one. Also, there is no standard way to program palette registers via firmware, so even if genfb works colours are likely off. X should work with the wsfb driver, it will likely look a bit odd though.</p>
<p>Boards like the CG8 have older, pre-wscons kernel support and weren't converted due to lack of hardware. They seem to be pretty rare though, in all the years I've been using NetBSD/sparc I have not seen a single user ask about them.</p>
<p>Finally, 3rd party boards not mentioned here are unsupported for lack of hardware in the right hands.<br>
Graphics hardware supported by NetBSD/sparc64 which isn't listed here should work the same way when running a 32bit userland but this is mostly untested.</p>
https://blog.netbsd.org/tnf/entry/so_they_sent_me_aSo they sent me a CI20macallan2014-11-23T14:55:55+00:002014-11-23T14:55:55+00:00When I found out that Ingenic is giving away some of their <a href="http://www.elinux.org/MIPS_Creator_CI20">MIPS Creator CI20</a> boards I applied, and to my surprise they sent me one. Of course, the point was to make NetBSD work on it. I just finished the first step.<br>When I found out that Ingenic is giving away some of their <a href="http://www.elinux.org/MIPS_Creator_CI20">MIPS Creator CI20</a> boards I applied, and to my surprise they sent me one. Of course, the point was to make NetBSD work on it. I just finished the first step.<p>
That is, make it load a kernel, identify / setup the CPU, attach a serial console. This is what it looks like:<p>
U-Boot SPL 2013.10-rc3-g9329ab16a204 (Jun 26 2014 - 09:43:22)<br>
SDRAM H5TQ2G83CFR initialization... done<br>
<br>
<br>
U-Boot 2013.10-rc3-g9329ab16a204 (Jun 26 2014 - 09:43:22)<br>
<br>
Board: ci20 (Ingenic XBurst JZ4780 SoC)<br>
DRAM: 1 GiB<br>
NAND: 8192 MiB<br>
MMC: jz_mmc msc1: 0<br>
In: eserial3<br>
Out: eserial3<br>
Err: eserial3<br>
Net: dm9000<br>
ci20# dhcp<br>
ERROR: resetting DM9000 -> not responding<br>
dm9000 i/o: 0xb6000000, id: 0x90000a46 <br>
DM9000: running in 8 bit mode<br>
MAC: d0:31:10:ff:7e:89<br>
operating at 100M full duplex mode<br>
BOOTP broadcast 1<br>
DHCP client bound to address 192.168.0.47<br>
*** Warning: no boot file name; using 'C0A8002F.img'<br>
Using dm9000 device<br>
TFTP from server 192.168.0.44; our IP address is 192.168.0.47<br>
Filename 'C0A8002F.img'.<br>
Load address: 0x88000000<br>
Loading: #################################################################<br>
##############<br>
284.2 KiB/s<br>
done<br>
Bytes transferred = 1146945 (118041 hex)<br>
ci20# bootm<br>
## Booting kernel from Legacy Image at 88000000 ...<br>
Image Name: evbmips 7.99.1 (CI20)<br>
Image Type: MIPS NetBSD Kernel Image (gzip compressed)<br>
Data Size: 1146881 Bytes = 1.1 MiB<br>
Load Address: 80020000<br>
Entry Point: 80020000<br>
Verifying Checksum ... OK<br>
Uncompressing Kernel Image ... OK<br>
subcommand not supported<br>
ci20# g 80020000<br>
## Starting applicatpmap_steal_memory: seg 0: 0x30c 0x30c 0xffff 0xffff<br>
Loaded initial symtab at 0x802502d4, strtab at 0x80270cb4, # entries 8323<br>
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,<br>
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014<br>
The NetBSD Foundation, Inc. All rights reserved.<br>
Copyright (c) 1982, 1986, 1989, 1991, 1993<br>
The Regents of the University of California. All rights reserved.<br>
<br>
NetBSD 7.99.1 (CI20) #113: Sat Nov 22 09:58:39 EST 2014<br>
ml@blackbush:/home/build/obj_evbmips32/sys/arch/evbmips/compile/CI20<br>
Ingenic XBurst<br>
total memory = 1024 MB<br>
avail memory = 1001 MB<br>
kern.module.path=/stand/evbmips/7.99.1/modules<br>
mainbus0 (root)<br>
cpu0 at mainbus0: 1200.00MHz (hz cycles = 120000, delay divisor = 12)<br>
cpu0: Ingenic XBurst (0x3ee1024f) Rev. 79 with unknown FPC type (0x330000) Rev. 0<br>
cpu0: 32 TLB entries, 16MB max page size<br>
cpu0: 32KB/32B 8-way set-associative L1 instruction cache<br>
cpu0: 32KB/32B 8-way set-associative write-back L1 data cache<br>
com0 at mainbus0: Ingenic UART, working fifo<br>
com0: console<br>
<br>
root device: <br>
<br>
What works:<p>
<ul>
<li>CPU identification and setup</li>
<li>serial console via UART0</li>
<li>reset ( by provoking a watchdog timeout )</li>
<li>basic timers - enough for delay(), since the CPUs don't have MIPS cycle counters</li>
<li>dropping into ddb and poking around</li>
</ul><p>
What doesn't work (yet):<p>
<ul>
<li>interrupts</li>
<li>everything else</li>
</ul><br>
Biggest obstacle - believe it or not, the serial port. The on-chip UARTs are mostly 16550 compatible. Mostly. The difference is one bit in the FIFO control register which, if not set, powers down the UART. So throwing data at the UART by hand worked but as soon as the com driver took over the line went dead. It took me a while to find that one.<br>
https://blog.netbsd.org/tnf/entry/working_arm_multiprocessor_supportARM multiprocessor supportmartin2014-11-06T13:48:48+00:002014-11-06T16:37:20+00:00NetBSD now supports multiple cores on various ARM SoCs.Those following the source-changes mailing list closely may have noticed several evbarm kernels getting "options MULTIPROCESSOR" in the last few days. This is due to those configurations now running properly in SMP mode, thanks to work mostly done by Matt Thomas and Nick Hudson.<p>
The list of supported multiprocessor boards currently is:
<ul>
<li>Banana Pi (BPI)</li>
<li>Cubieboard 2 (CUBIEBOARD)</li>
<li>Cubietruck (CUBIETRUCK)</li>
<li>Merrii Hummingbird A31 (HUMMINGBIRD_A31)</li>
<li>CUBOX-I</li>
<li>NITROGEN6X</li>
</ul>
<p>
Details how to create bootable media and various other information for the Allwinner boards can be found on the <a href="http://wiki.netbsd.org/ports/evbarm/allwinner/">NetBSD/evbarm on Allwinner Technology SoCs</a> wiki page.
<p>
The release engineering team is discussing how to bring all those changes into the netbsd-7 branch as well, so that we can call NetBSD 7.0 "the ARM SoC release".<p>
While multicore ARM chips are mostly known for being used in cell phones and tablet devices, there are also some nice "tiny PC" variants out there, like the <a href="http://docs.cubieboard.org/tutorials/cubietruck/start">CubieTruck</a>, which originally comes with a small transparent case that allows piggybacking it onto a 2.5" hard disk:<p>
<img src="http://docs.cubieboard.org/_media/products/a20-cubietruck.png" /><br>
<small>Image from <a href="http://www.cubieboard.org">cubieboard.org</a> under <a href="http://creativecommons.org/licenses/by-sa/3.0/">creative commons</a> license.</small><p>
This is nice to put next to your display, but a bit too tiny and fragile for my test lab - so I reused an old (originally mac68k cartridge) SCSI enclosure for mine:<p>
<a href="http://www.netbsd.org/~martin/cubie_in_scsi_enclosure.jpg"><img src="http://www.netbsd.org/~martin/cubie_in_scsi_enclosure.jpg" width="80%"></a><br>
<small>Image by myself under <a href="http://creativecommons.org/licenses/by-sa/3.0/">creative commons</a> license.</small><p>
This machine is used to run regular tests for big endian (!) arm, the results are gathered <a href="http://www.netbsd.org/~martin/evbearmv7hf-atf/">here</a>. Running it big-endian is just a way to trigger more bugs.<p>
The last test run logged on the page is already done with an SMP kernel. No regressions were found so far, and the other bugs (sligtly more than 30 failures in the test run is way too much) will be addressed one by one.<p>
Now happy multi-ARM-ing everyone, and I am looking forward to a great NetBSD 7.0 release!<p>https://blog.netbsd.org/tnf/entry/the_playstation2_port_is_backThe playstation2 port is backmartin2014-03-31T11:27:37+00:002014-03-31T11:29:19+00:00After not having a usable compiler for a few years, the playstation2 port is returning, now that gcc 4.9 (gcc-current in NetBSD terms) re-acquired support for the R5900 CPUIn 2009 the playstation2 port was removed from the NetBSD sources, since it had not been compilable for months and no modern enough compiler was available.<p>
Due to a strange series of events the code changes needed to support the (slightly unusual) MIPS CPU used in the playstation2 had never been merged into gcc nor binutils mainline. Only recently this has been fixed. Unfortunately the changes have not been pulled up to the gcc 4.8.3 branch (which is available in NetBSD-current), so an external toolchain from pkgsrc is needed for the playstation2.<p>
To install this toolchain, use a pkgsrc-current checkout and cd to cross/gcc-mips-current, then do "make install" - that is all.<p>
Work is in progress to bring the old code up to -current. Hopefully a bootable NetBSD-current kernel will be available soon.<p>https://blog.netbsd.org/tnf/entry/sx_support_addedSX support addedmacallan2013-07-03T04:32:54+00:002015-06-11T18:14:09+00:00Support for Sun's SX rendering engine ( found in the SparcStation 20 and 10SX's memory controllers ) has been added, both for the console and X. Both drivers support basic acceleration ( block copy, rectangle fill, character drawing in the kernel ), the Xorg driver also supports Xrender acceleration. This probably makes SX the oldest supported hardware which can do that.<p>Support for Sun's SX rendering engine ( found in the SparcStation 20 and 10SX's memory controllers ) has been added, both for the console and X. Both drivers support basic acceleration ( block copy, rectangle fill, character drawing in the kernel ), the Xorg driver also supports Xrender acceleration. This probably makes SX the oldest supported hardware which can do that.
<p>
SX is more or less a vector processor built into a memory controller. The 'or less' part comes from the fact that it can't actually read instructions from memory - the CPU has to feed them one by one. This isn't quite as bad as it sounds - SX has plenty of registers ( 128 - eight of them have special functions, the rest is free for all ) and every instruction takes a count to operate on several subsequent registers or memory locations ( ALU ops can use up to 16, memory accesses up to 32 ). SX supports some parallelism too - the ALUs can do up to two 16bit multiplications and two other arithmetic or logical ops per clock cycle ( 32bit multiplications use both ALUs ). The thing runs at 50MHz - not a whole lot by today's standards but it can be a significant help to any CPUs you can put into these machines.
<p>
The kernel part hs been committed a while ago ( see cgfourteen at obio ), always runs in 8bit colour with everything ( scrolling, character drawing etc. ) done by SX. Substantially faster than software only operation.
<p>
The Xorg driver ( xf86-video-suncg14 that is, it needs a recent cgfourteen kernel driver to map SX registers ) uses EXA, by default it enables basic acceleration ( Solid and Copy, hardware cursor support has been added years ago ), Xrender acceleration is incomplete and can be enabled by adding Options "Xrender" "true" to the cg14's device section in xorg.conf. For now it implements what's needed for anti-aliased font drawing, assembling alpha maps in video memory and operations KDE3 uses for drawing icons, buttons and so on. As it is now KDE3 looks mostly right - there are a few rendering errors ( for example the corners of the white frame in Konqueror's startup page, also some text is drawn with red and blue channels switched ) but nothing that would interfere with functionality.
<p>
Speed isn't great ( well, the hardware is 20 years old ) but the improvement over unaccelerated X is more than noticeable. Some benchmark numbers, all taken on an SS20 with a single 125MHz HyperSPARC:<br>
<ul>
<li>x11perf -comppixwin went from 26.3 to 93.7
<li>x11perf -compwinwin went from 8.8 to 93.5
<li>x11perf -aaftext went from about 4000 ( 5000 with shadow fb but that's technically cheating since not everything is drawn into video memory ) to 16000</ul><br>
There is still room for improvement - for now all Xrender operations work on one pixel at a time, SX has enough registers to do at least four in most cases. Also, functionality is added as needed whenever I run into it, so other things are likely broken ( I know gtk2 is, but that's easy to fix ) which is why Xrender acceleration is disabled by default.<p>
https://blog.netbsd.org/tnf/entry/thylacine_usb_driverThylacine USB driverBlog Import2013-04-28T00:00:00+00:002013-04-28T00:00:00+00:00Zorro attachment code for <a href="//man.NetBSD.org/slhci.4">slhci(4)</a> driver was added. Thylacine USB card is now supported. However, so far only keyboards and mice work reliably. To use them instead of standard Amiga keyboard and mouse wscons kernel is required. https://blog.netbsd.org/tnf/entry/xm6i_ver_0_41XM6i ver 0.41Blog Import2013-04-25T00:00:00+00:002013-04-25T00:00:00+00:00
<a class="ulink" href="http://xm6i.org/" target="_top">XM6i</a> version 0.41
has been released.
Now XM6i supports MC68881 FPU emulation and
the performance of NetBSD/x68k on XM6i is notably improved.
XM6i's FPU emulation code was based on NetBSD/m68k FPE sources,
and then the XM6i developments also <a class="ulink" href="http://mail-index.NetBSD.org/source-changes/2013/04/20/msg043131.html" target="_top">improve
NetBSD/m68k FPE implementation</a>.