Making RockPro64 a NetBSD Server
The time has come to upgrade my SunBlade 2500s to something more power friendly and faster. I'd already removed one CPU and thus half the ram from two of these systems to reduce their power consumption, but it's still much higher than it could be.
After much searching, I've decided on Pine64's RockPro64 4GiB ram model (technically, only 3.875GiB ram.) Pine64 make SBCs, laptops, phones, and various other mostly ARM gadgets, and the RockPro64 has the fastest CPU they ship (Rockchip RK3399), and can use a small "NAS Case", that is sufficient to house 2 HDDs and, at a stretch, upto 6 SSDs (cooling would become quite an issue at this point.)
In my SATA setup, I have 3 SSDs with a JMicron 585 card in the PCIe slot, two SSDs in the NAS case SSD region, and the third is in the HDD region with an adapter. I have used two SATA power splitters to convert the NAS case's 2 SATA power ports into 4, with the 4th one also powering a Noctua case fan. The cabling is not great with this, with enough SATA power cabling for 6 devices to lay. Probably a bespoke power cable to connect to the RockPro64 would make this nicer and probably improve cooling slightly, but I'm just using off-the-shelf components for now.
In the last year or so I've been working on making NetBSD/arm64 big-endian more featureful. In particular, I've added support for:
- other-endian access disklabels, FFS file-systems in the NetBSD libsa
- the "look 64 sectors later" for RAIDFrame partitions in MI efiboot (the x86 specific efiboot has more extensive support for this that should be ported over)
- other-endian access to RAIDFrame labels in the kernel
- updated the U-Boot package and featureset to include AHCI/SATA support, workaround some bugs and fix the newer U-Boot SPI loader location, and figured out how to default loading from either SATA or NVMe
There are not too many special actions needed for this sort of setup compared to a normal NetBSD or Arm system. While I built my installations by hand, the standard NetBSD Arm images are suitable for this task. It's easiest to start from an SD card with the RockPro64 u-boot installed. There are two U-Boot images available, one for SD/eMMC, and one for SPI (there is an odd problem with the early SPI loader that requires a portion of the image to be different.) The pkgsrc package for sysutils/u-boot-rockpro64 version 2022.01 has these suggested methods for installing the U-Boot image (this package should be buildable on any supported pkgsrc platform).
To install U-Boot into the SD/eMMC card (can run on any system, the image must be written at 32KiB into the device):
# dd if=/usr/pkg/share/u-boot/rockpro64/rksd_loader.img seek=64 of=/dev/rld0c
To install U-Boot into the SPI flash (must be run on the host, and lives at the very start of the device:
# dd if=/usr/pkg/share/u-boot/rockpro64/rkspi_loader.img bs=64k of=/dev/spiflash0
When booting from NVMe or SATA, one must drop to the U-Boot prompt and adjust the "boot_targets" value to put scsi* (SATA) or nvme* ahead of the mmc* and usb* options.
The original value for me:
=> printenv boot_targets boot_targets=mmc1 usb0 mmc0 nvme0 scsi0 pxe dhcp sf0
Which is then adjusted and saved with eg:
=> setenv boot_targets nvme0 scsi0 mmc1 usb0 mmc0 pxe dhcp sf0 => saveenv Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done OK
(In this list, mmc1 is the SD slot, mmc0 is the eMMC card, pxe and dhcp are netbooting, and sf0 attempts to load further U-Boot scripts from SPI.)
There are some minor issues with the RockPro64. It has no ability to use ECC memory. It only comes with 1 PCIe 4x slot, and Rockchip errata limited this to PCIe 1.x (though no NetBSD users encounted any issues with PCIe 2.x enabled, and this can be forced back on via a DTS patch.) It is possible to use a PCIe bridge (I have never done this, though I would like to try in the future) to enable more devices for booting, or to enable both a network and storage device.
[0 comments]
Public NetBSD IRC chat channels moved to Libera
Due to the unfortunate situation regarding changes in administration on freenode.net, and the resulting chaos, we have decided to move the public NetBSD IRC channels from freenode to irc.libera.chat.
This includes:
- #NetBSD - general discussion
- #netbsd-code - development discussion
- #pkgsrc - pkgsrc (primarily development) discussion
You can find information on connecting to Libera at https://libera.chat/
[Read More] [1 comment]
Allen K. Briggs Memorial Scholarship
Allen Briggs was one of the earliest members of the NetBSD community, pursuing his interest in macBSD, and moving to become a NetBSD developer when the two projects merged. Allen was known for his quiet and relaxed manner, and always brought a keen wisdom with him; allied with his acute technical expertise, he was one of the most valued members of the NetBSD community.
He was a revered member of the NetBSD core team, and keenly involved in many aspects of its application; from working on ARM chips to helping architect many projects, Allen was renowned for his expertise. He was a distinguished engineer at Apple, and used his NetBSD expertise there to bring products to market.
Allen lived in Blacksburg Virginia with his wife and twin boys and was active with various community volunteer groups. His family touched the families of many other NetBSD developers and those friendships have endured beyond his passing.
We have received the following from Allen's family and decided to share it with the NetBSD community. If you can, we would ask you to consider contributing to his Memorial Scholarship.
https://www.ncssm.edu/donate/distance-education/allen-k-briggs-88-memorial-scholarship
The Allen K. Briggs Memorial Scholarship is an endowment to provide scholarships in perpetuity for summer programs at the North Carolina School of Science & Math, which Allen considered to be a place that fundamentally shaped him as a person. We would love to invite Allen's friends and colleagues from the BSD community to donate to this cause so that we can provide more scholarships to students with financial need each year. We are approximately halfway to our goal of $50K with aspirations to exceed that target and fund additional scholarships.
Two quick notes on donating: Important! When donating, you must
select "Allen K. Briggs Memorial Scholarship" under designation
for the donation to be routed to the scholarship If you have the
option to use employer matching (i.e., donating to NCSSM through
an employer portal to secure a match from your employer), please
email the NCSSM Foundation's Director of Development, April Horton
(april.horton@ncssm.edu), after donating to let her know you want
your gift and employer match to go to the Allen K. Briggs Memorial
Scholarship Thanks in advance for your help. I'd be happy to answer
any questions you or any others have about this.
Default window manager switched to CTWM in NetBSD-current
For more than 20 years, NetBSD has shipped X11 with the "classic" default window manager of twm. However, it's been showing its age for a long time now.
In 2015, ctwm was imported, but after that no progress was made. ctwm is a fork of twm with some extra features - the primary advantages are that it's still incredibly lightweight, but highly configurable, and has support for virtual desktops, as well as a NetBSD-compatible license and ongoing development. Thanks to its configuration options, we can provide a default experience that's much more usable to people experienced with other operating systems.
[Read More] [8 comments]
GSoC Reports: Benchmarking NetBSD, third evaluation report
This report was written by Apurva Nandan as part of Google Summer of Code 2020.
This blog post is in continuation of GSoC Reports: Benchmarking NetBSD, first evaluation report and GSoC Reports: Benchmarking NetBSD, second evaluation report blogs, and describes my progress in the final phase of GSoC 2020 under The NetBSD Foundation.
In the third phase, I upgraded to the latest stable version Phoronix Test Suite (PTS) 9.8.0 in pkgsrc-wip, resolved the TODOs and created patches for more test-profiles to fix their installation and runtime errors on NetBSD-current.
[Read More] [1 comment]
GSoC Reports: Benchmarking NetBSD, second evaluation report
This report was written by Apurva Nandan as part of Google Summer of Code 2020.
This blog post is in continuation of GSoC Reports: Benchmarking NetBSD, first evaluation report blog and describes my progress in the second phase of GSoC 2020 under The NetBSD Foundation.
In this phase, I worked on the automation of the regression suite made using Phoronix Test Suite (PTS) and its integration with Anita.
The automation framework consists of two components Phoromatic server, provided by Phoronix Test Suite in pkgsrc, and Anita, a Python tool for automating NetBSD installation.
[Read More] [0 comments]
GSoC Reports: Benchmarking NetBSD, first evaluation report
This report was written by Apurva Nandan as part of Google Summer of Code 2020.
My GSoC project under NetBSD involves developing an automated regression and performance test framework for NetBSD that offers reproducible benchmarking results with detailed history and logs across various hardware & architectures.
To achieve this performance testing framework, I am using the Phoronix Test Suite (PTS) which is an open-source, cross-platform automated testing/benchmarking software for Linux, Windows and BSD environments. It allows the creation of new tests using simple XML files and shell scripts and integrates with revision control systems for per-commit regression testing.
[Read More] [0 comments]
Announcing Google Summer of Code 2020 projects
We are very happy to announce
The NetBSD Foundation Google Summer of Code 2020 projects:
- Apurva Nandan - Benchmark NetBSD
- Jain Naman - Curses library automated testing
- Nikita Gillmann - Make system(3) and popen(3) use posix_spawn(3) internally
- Ayushi Sharma - Enhance the syzkaller support for NetBSD
- Aditya Vardhan Padala - Rumpkernel Syscall Fuzzing
- Nisarg Joshi - Fuzzing the network stack of NetBSD in a rumpkernel environment
- Jason High - Extending the functionality of the netpgp suite
The community bonding period - where students get in touch with mentors and community - started on May 4 and will go on until June 1. The coding period will be June 1 to August 24.
Please welcome all our students and a big good luck to students and mentors!
A big thank you to Google and The NetBSD Foundation organization mentors and administrators!
Looking forward to having another nice Google Summer of Code!
[2 comments]
Porting wine to amd64 on NetBSD, third evaluation report
This report was written by Naveen Narayanan as part of Google Summer of Code 2019.
This report encompasses the progress of the project during the third coding period. You can make sense of the overall progress of the project by going through the first evaluation report and second evaluation report.
Wine-4.4 (released on Mar 2019) is working fine on amd64
and i386. I have been able to use a script as a workaround for
the problem of setting LD_LIBRARY_PATH. My patch for
setting guard size to 0 and hence, precluding Wine from
segfaulting, that got upstreamed, can be
found here.
I have updated the package to the latest development version of
Wine which is Wine-4.13 (released on Aug 2019). I have
added support to Wine pkgsrc packages to run tests using make
test, and at the time of writing, they are failing. I have also
noticed them fail on Linux non-pkgsrc environment and hence, will
require further investigation. Initially, they were disabled
owing to pkgsrc setting FORTIFY_SOURCE which is a macro that
provides support for detecting buffer overflows. In pkgsrc, the
wip/wine* packages honor PKGSRC_USE_FORTIFY variable passing
_FORTIFY_SOURCE macro accordingly. Programs compiled with
FORTIFY_SOURCE substitute wrappers for commonly used libc
functions that don't do bounds checking regularly, but could in some
cases. Wine unconditionally disables that via their configure
script because for some platforms that triggered false positives
in the past. However, in my experience, no false positive were
found.
Porting wine to amd64 on NetBSD, second evaluation report
This report was written by Naveen Narayanan as part of Google Summer of Code 2019.
This report encompasses the progress of the project during the second coding period.
As getting Wine to work with WoW64 support was of foremost
importance, my focus was on compat32 dependency packages without
which Wine's functionality would be limited and more importantly
untestable. Initially, being unaware of what to expect, I just
wanted Wine to run, at the earliest. So, with outmost support from
mentors, the consensus was to install libs from 32-bit packages to
${PREFIX}/lib/32 and ignore everything else that came with the
respective packages.
Implementation of DRM ioctl Support for NetBSD kernel
This report was prepared by Surya P as a part of Google Summer of Code 2019
Enabling support of DRM ioctls in linux emulation.
[Read More] [3 comments]
Porting NetBSD to HummingBoard Pulse, Part 1
This report was written by Saurav Prakash as part of Google Summer of Code 2019.
My venture into the first phase of The Google Summer of Code is nearing an end. The experience was enriching in every dimension, and the learning exposure I was subjected to was genuinely worthwhile. Here is a brief report on the work I have performed during this coding period.
[Read More] [0 comments]
![[NetBSD Logo]](/tnf/resource/NetBSD-headerlogo.png)