Bengies Top 10 for 2023, Barely

O, 2023, what happened?

Besides getting older and slower, the Bengies drive-in movie theatre had bad weather (fog, in December?) and a slew of R-rated flicks we skipped and a few kiddie flicks also given the slip. Still, the Scout Camp-In continues despite the usual suspect challenges (high staff turnover, slow tech progress).

Here are my annual "10 Best Movies I Watched At The Bengies" where "watched" is at least part of the film, if not the whole thing. 

Yes, let's start at 

Number One,

a Ten in Ten of Ten, including the crowd on a weeknight. For fun, we printed our pre-paid ticket order on pink paper. Plenty of folks dressed up, and the happy crowd made for more fun. The snickering jokes about Ken 

Hocus Pocus, in the rain, a second time on the big screen, is Number Two.

Number Three

Guardians 3

https://chaos.social/@jspath55/110392830400706164

The sequel to the sequel, which seemed almost like the same plot, with ennui for the raccoon that doesn't know it is a raccoon. Self -denial runs deep.

Four, and Counting

Indiana Jones & the Dial of Destiny

Phoned in...

Whatever "The Boogeyman" was. we skipped it. PG-13 or no.

And 5 Through 10

The Flash and the Spider Verse

https://chaos.social/@jspath55/110589657062948842

First time I recall a double feature with DC and Marvel! The Flash didn't bring back sixth-grade memories of science lab as I expected. (5,6)

Wonderful Life / Elf

Of these two, let's say I split the difference arriving late and leaving early. Elf was not as much of a wince as I recalled, though minimal dosing helped. And because I had other plans, did not stay through It's A Wonderful Life once the alternate reality began. Seemed a bit like now, sadly. (7,8)

Rebel Without A Cause / Forbidden Planet

https://chaos.social/@jspath55/110498676821941834

To round out the 10, two movies from the 1950s, around the time the Bengies opened, shown on their Drive-In Anniversary special--"FORBIDDEN PLANET" stars Walter Pidgeon, Anne Francis, Leslie Nielsen AND Robby the Robot.

The Under 11

TMN Turtles, unshelled. All right, the Scouts liked it I guess.

Last, and Twelfth, like Iscariot:

Gran Turismo. I definitely asked for Barbie to play, but instead of a somewhat socially conscious show, we got another salute to burning petroleum and continuing our carbon dioxide emissions.

2022 (last year's write up, and links to past Top Tens)

jspath55.blogspot.com/2022/12/bengies-top-10-2022.html

NetBSD 10 RC1 Review

 

Upgrades from earlier 10.0 beta images went easily except for the Raspberry Pi systems with the kernel in a different place. 

 WIFI

• amd – external
• i386 - none
• pi4 – no wifi, hard-wire ok
• pi3 – no wifi; hard-wire ok
• pi02w – wifi yes; hard-wire added
• pi0w – wifi yes

 Automated Test Framework

I kicked off periodic user test suite cases, noting the minimum and maximum errors per platform. The Pi4 worked best, and the 0W the worst as I never completed a full run, trying various scratch write media to avoid stall-outs on basic shell command runs.

 When the platform would allow full tests runs more than one a day I set up cron jobs; the fastest tested had 60 or so when I stopped the cron.

    3 failed test cases.

    4 failed test cases.

    3 failed test cases.

    3 failed test cases.

    6 failed test cases.

    4 failed test cases.

    4 failed test cases.

    3 failed test cases.

• amd – (2/7)
• i386 - (0/3)
• pi4 – (1/4)
• pi3 – none yet
• pi02w – November 26 last run (16 / 20)
• pi0w – 30 (one good run)

The variation in failures from phase to phase I've called Heisenbergars, elsewhere.

X11

I had 2 minor regressive behaviors after RC1 tests compared to earlier betas, where the AMD machine had flaky screen text. I need to recheck the cables since it went onto a floor mount instead of desk level. The other slowness was on a new Pi4 install, where I struggled through getting the latest UEFI version on an SD card, and ending up with a working install, and 8GB (don't forget to set that last in the UEFI menus). Comparing the CPU temperature to other Pi 4s, it may work better with a running fan. More tests later; the last straw was launching QGIS (except with a Postgre 14 client for package sanity).

WIFI

I guess the fix for using wifi, at least on the Pi 4, is external dongles. The Pi3 worked for me at one point, but the dmesg tempts with "almost, almost":

[     3.368964] bwfm0: Found Firmware file: brcmfmac43455-sdio.bin

[     3.388965] bwfm0: NVRAM file default:    brcmfmac43455-sdio.txt

[     3.388965] bwfm0: NVRAM file model-spec: brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt

[     3.388965] bwfm0: Found NVRAM file: brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt

[     3.388965] bwfm0: CLM file default:    brcmfmac43455-sdio.clm_blob

[     3.388965] bwfm0: CLM file model-spec: brcmfmac43455-sdio.raspberrypi,3-model-b-plus.clm_blob

[     4.999119] bwfm0: CHIPACTIVE

[     5.099132] bwfm0: address ..:..:..:..:..

[     5.099132] bwfm0: wl0: Mar  1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4

The ifconfig shows recognition of the wifi circuit but wpa supplicant stumbles.

bwfm0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

pi4:

Also, almost

[     2.447895] bwfm0: NVRAM file default:    brcmfmac43455-sdio.txt

[     2.447895] bwfm0: NVRAM file model-spec: brcmfmac43455-sdio.Raspberry Pi 4 Model B.txt

[     2.447895] bwfm0: autoconfiguration error: NVRAM file not available

[     2.447895] bwfm0: CLM file default:    brcmfmac43455-sdio.clm_blob

[     2.447895] bwfm0: CLM file model-spec: brcmfmac43455-sdio.Raspberry Pi 4 Model B.clm_blob

Avenza on the Trail

I got to use the Avenza-hosted Reservation map for the first time onsite in early December 2023 while winter camping with a Scout troop. They needed basic map and compass tutoring, and adding the digital version in sequence reinforces the concepts.

This story is generally chronological for my one-day observations, by site.

Conowingo / Pine Grove

I camped in the field near the "X" shown on this screenshot.  I did a polygon line drawing around the cabin, trying to figure out about the projected skewness. This is my own geoPDF, with a scale of 1:250 and has 150 dpi.

The screenshot was from Friday evening, where I had 95% battery to start.

Flagpole and former memorial sign.

A control point of sorts; someone knows which sign was here, presumably now at RHQ.

Flint Ridge

Latrine surveying. I walked around the pad, taking measurements and images with camera and the Avenza app. In the morning, the power level was at 86% and here shows 81%

Chimney was photographed and geo-tagged. I was definitely *not* inside. Not 9AM yet and 77% power level.

The Dam and the Yellow Trail

Turning on tracking and measuring a few hundred feet left battery at 72%.

I did a track with Avenza, then viewed it later with Google Earth. Interesting.

Frontier

This site has only an official entrance across a bridged stream.

The blue line is a "get there from here" option. Straight line, probably helpful but not guaranteed a safe route! I was not on the bridge here.

Red trail 

Camp entrance

I only posted two screen shots above, from between 10 am and 1PM; the battery level dropped from 70 to under 60%. When I returned to my tent I plugged in an external battery, and by 5PM the phone was back to 100%.

Et cetera

I experimented with a 1:8000 scale, 600 dpi geoPDF with both the official camp map and the unofficial OSM layer.

.

I needed to allow "all the time" location access to Avenza to have the "show a route" function work. Other operations usually work with allowing access "just the once," though often Avenza will claim "not on map" and I needed to stop/start the app. Maybe a bug.

The blue dot can dance around, showing where the app thinks you are, and shows a shrinking diameter as more satellite signals are locked in. My testing was partly the squiggles of the original transformed map image, the delay and aberrations of the Android device (iPhone testers needed too), and the time needed to get a "good enough" spot for a place on the earth.

Saga of QGIS Tutorial--NetBSD stumble at the finish line

Previously*, I wrangled QGis version 3.28 or better on Raspberry Pi's trying to complete pertinent tutorial lessons and hitting local software application limits. I had success with OpenSUSE and FreeBSD (on x86 hardware). My next focus was NetBSD on a Pi4 (with the full 8GB), after upgrading the package system (in fits and starts) to the Q3 2023 release. 

* https://jspath55.blogspot.com/2023/09/tiling-for-geo-map-referencing-in-qgis.html

https://jspath55.blogspot.com/2023/10/qgis-tutorial-torture-track.html

Just because it says BETA doesn't mean this is a flaky OS. The tiny box just takes everything I can throw at it; my main challenge is getting all the pieces talking nice (and doing a valid GEO PDF at the end).

$ uname -a

NetBSD nb 10.0_BETA NetBSD 10.0_BETA (GENERIC64) #0: Sat Sep  9 15:02:43 UTC 2023  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/GENERIC64 evbarm

[     1.000000] NetBSD 10.0_BETA (GENERIC64) #0: Sat Sep  9 15:02:43 UTC 2023

[     1.000000]         mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/GENERIC64

[     1.000000] total memory = 8024 MB

[     1.000000] avail memory = 7735 MB

[     1.000000] simplebus0 at armfdt0: Raspberry Pi Foundation Raspberry Pi 4 Model B

[     2.425653] bwfm0: Firmware file model-spec: brcmfmac43455-sdio.Raspberry Pi 4 Model B.bin

The PkgSrc has a current enough version (between Rasbian and Windows), and all the ducks included.

$ ldd /usr/pkg/bin/qgis
/usr/pkg/bin/qgis:
        -lqgis_app.3.28.7 => /usr/pkg/lib/libqgis_app.so.3.28.7
        -lqwt.6 => /usr/pkg/qwt-6.1.5/lib/libqwt.so.6
        -lexecinfo.0 => /usr/lib/libexecinfo.so.0
        -lelf.2 => /usr/lib/libelf.so.2
        -lc.12 => /usr/lib/libc.so.12
        -lgcc_s.1 => /usr/lib/libgcc_s.so.1
        -lQt5PrintSupport.5 => /usr/pkg/qt5/lib/libQt5PrintSupport.so.5
        -lQt5Widgets.5 => /usr/pkg/qt5/lib/libQt5Widgets.so.5
        -lQt5Gui.5 => /usr/pkg/qt5/lib/libQt5Gui.so.5
        -lQt5Core.5 => /usr/pkg/qt5/lib/libQt5Core.so.5
        -lz.1 => /usr/lib/libz.so.1
        -ldouble-conversion.3 => /usr/pkg/lib/libdouble-conversion.so.3
        -lstdc++.9 => /usr/lib/libstdc++.so.9

Summing up:

$ qgis --version

QGIS 3.28.7-Firenze 'Firenze' (exported)

Steps for tutorial section 14 (part: "14.3.6. basic Follow Along: Joining the Forest Stand Data")

https://docs.qgis.org/3.28/en/docs/training_manual/forestry/stands_digitizing.html#basic-fa-digitize-the-forest-stands

1. Clicking on the table on the right side lights up the areas on the left. Huzzah. Tiny sliver of badly-drawn border there as I could not (did not) locate the "fix overlaps" routine). Next lesson.

QGIS Attributes table - Pi 4 NetBSD 10

The attributes link is a huge step in correlating pictures to numbers, as it were.

2. Filter on the far left (funnel icon) where I selected by a routine just 2 subsets. Heads above manually clicking to select, and saved for future changes.

QGIS Filter - Pi4 NetBSD 10

3. A tree view of attributes rather than a grid view, 

QGIS attributes / Tutorial document

Zoom

The lessons worked, as far as an academic follow-the-book exercise went. I knew the parts I skipped or didn't complete, learning enough to see applicability to a few real-world projects.

The export to a georeferenced PDF is almost there but the NetBSD packages I installed omitted a GDAL subset.

GDAL PDF driver was not built with PDF read support. A build with PDF read support is required for GeoPDF creation.

Back to the package manual. And the mailing support lists with a reasonable question.

Next lesson: Elevations with topographic or other sources, or a dive into database storage/retrieval.

QGIS tutorial torture track

 I tried to follow the QGIS Forestry tutorial (link below) on a couple Raspberry Pi's (would have liked to use only one but meh). I got up to vector-to-polygon and then stalled on the first day hands-on. In 2 weeks there's a QGIS conference in town I'm attending; consider this my study hall.

Previously: jspath55.blogspot.com/2023/09/tiling-for-geo-map-referencing-in-qgis.html

Wherein I list the QGIS versions within reach. Odd to have this many flavors, so let's do the taste test, starting with the Pi with the newest version, running on OpenSUSE. 

The OS is missing something in the Perl layer which results in error messages and missing menus. Until I can track them down or they reappear with an unrelated app upgrade.

Tutorial link:

https://docs.qgis.org/3.28/en/docs/training_manual/forestry/index.html

The learning here is use the filter (search) field to enter the coordinate reference system (the other CRS, not the can't remember stuff one) with numbers. I missed one of the transformations as the version I used had slightly different field text.

Geo-referencing was easy until I misread something, throwing off the mark. Easily seen by the result, and I skipped to the next lesson by keying in the exact values instead of trying the visual drop the claw-grab protocol.

Very nice to have the answers in the margins, so to speak.

The skewed first version:

Maxwell Smart voice: "missed it by that much."

Gnu Imp

Sigh. Crashed on tutorial section trying to select by color.

Bang, Zoom, to the Moon, or as my Brit friends might say, "Cloud-cuckoo-land."

12:33:55

12:34:01

Fortunately, only the user session/window manager died, not the whole OS as it might look.

Switched over to another PI running Rasbian (but QGIS 3.10) that had Gnu Imp which worked, to a fault.

Gnu Imp - Lower Left of Map

More results in the green goo.

Not the ideal output the tutorial has, but the steps are workable. Later attempts to move to polygonal spaces failed as the Raspbian was missing parts, or I cannot find them yet, and the OpenSUSE needs the python hooks re-hooked to shape up the shape files.

SQL FUN

Something was in the wrong mode.

ERROR 1: sqlite3_exec(DROP TRIGGER rtree_states_provinces_geom_update3) failed: attempt to write a readonly database

ERROR 1: sqlite3_exec(CREATE TRIGGER "rtree_disputed_borders_geom_update3" AFTER UPDATE ON "disputed_borders" WHEN OLD."fid" != NEW."fid" AND (NEW."geom" NOTNULL AND NOT ST_IsEmpty(NEW."geom")) BEGIN DELETE FROM "rtree_disputed_borders_geom" WHERE id = OLD."fid"; INSERT OR REPLACE INTO "rtree_disputed_borders_geom" VALUES (NEW."fid",ST_MinX(NEW."geom"), ST_MaxX(NEW."geom"),ST_MinY(NEW."geom"), ST_MaxY(NEW."geom")); END) failed: trigger "rtree_disputed_borders_geom_update3" already exists

FILE TIFFing

tutorial-pi400/rautjarvi_green_georef.tif: TIFF image data, little-endian, direntries=29, height=4561, bps=362, compression=none, PhotometricIntepretation=RGB, name=U:\Dropbox\GISMOOD_KESKUS_prj2014\0-13004-002-Simosol-online_gis_materials\1-mets\303\244materiaalit\0-mets\303\244materiaalit\ex1-map digi, description=Groovy Green Goo, orientation=upper-left, width=2014

C.R.S.

"Multiple operations are possible for converting coordinates between these two Coordinate Reference Systems. Please select the appropriate conversion operation, given the desired area of use, origins of your data, and any other constraints which may alter the "fit for purpose" for particular transformation operations."

"An alternative, ballpark-only transform was used when transforming coordinates between EPSG:2392 - KKJ / Finland zone 2 and EPSG:3067 - ETRS89 / TM35FIN(E,N). The results may not match those obtained by using the preferred operation:

Possibly an incorrect choice of operation was made for transformations between these reference systems. Check the Project Properties and ensure that the selected transform operations are applicable over the whole extent of the current project."

Tiling for Geo Map Referencing in QGIS

 

Q GIS

JPEG to TIFF to PDF

 QGIS on X11

I needed to convert a JPEG image into a georeferenced PDF, which I was able to do, finding things to fix later along the path.

The issue with starting at the top is the image is too big to share cleanly, so breaking the problem into parts led to tiles showing a fraction of the big picture.

Source of data I used to feed into QGIS were a history file of geo-tagged Panoramio images (such as this one of Oest Chapel; just kidding it's the Marble Hill campsite latrine).

QGIS versions

Turns out the Raspberry Pi 4 (aka 400) factory warranty operating system has an older QGIS release than other systems I tried to use. Windows had 3.32.2-Lima, OpenSUSE had QGIS 3.32.0-Lima, and a couple *BSD were at  qgis-3.28.11 or so. Raspbian had QGIS 3.10.14-A Coruña.

Thus, I worked on OpenSUSE and Windows. Would have like to do more on FreeBSD as that box has the best processors in the house. On the downside, OpenSUSE didn't have Viking, and I couldn't build the venerable XPaint (was able to use screengrab for the docs here in the house).

The "Georeferencer" button is either there or it isn't. I've looked on the older versions and despite the copious documentation pages the function escapes me.

One note I read said you could get away with only 3 control points; the program insisted on at least 4 per run. I used 10 in an earlier projection reference which was tedious but not too complex.

The icons are a little fuzzy to me and I tend to use the pull-down menus. Maybe after doing a few dozen I'll get the shortcuts down.

Georeference and the GCP table

The above image shows a map (loaded from a JPEG file) with 4 control points in the table at the bottom. I've circled those points on the image as there are no text labels in this view.

For this example, I chose the northeast (more or less) corners of a couple buildings - the main warehouse, and Prospect cabin, and the corner of the pool, and about where the water tower is. Even though the spots seem pretty close, there is definite warpage of the trails on different map levels.

After running the referencer code a TIFF image file is produced that contains the geotagging needed to correct use.

Broad_Creek 2023_225dpi-01-OEST-CHAPEL_modified.tif:     

TIFF image data, little-endian, direntries=16, height=477, bps=206, compression=none, PhotometricInterpretation=RGB, width=615

Broad_Creek_2023_225dpi-01-SAFFRAN-QM-TILE_modified.tif: 

TIFF image data, little-endian, direntries=16, height=506, bps=206, compression=none, PhotometricInterpretation=RGB, width=508

The PDF production

I have not set the geo-PDF as a default so must check both of these boxes to get a PDF.

Then it just works.

Loading in Avenza is the best test, even better to run it within the map borders to get the location shown.

Mini vision quest upstream

 I intended to test getting elevations as well as latitude/longitude with a slightly better
than my Coolpix along a stream/drainage channel. Ended up seeing a small vision of what the streambed looked like before we disturbed it.

This figure was taken from the NPS publication on their web site - https://www.nps.gov/hamp/learn/upload/EOA-Hampton-TracingLivesFinalReport-508.pdf - (page 143) and shows "property" and water channels from around 1800 (?). From prior to the Loch Raven Reservoir being created. Arrows show an almost southerly direction on 3 unnamed tributaries of the then-named Petersons Run (I have not located that name on recent maps but haven't looked too far yet).

Researching landmarks/placemarks/benchmarks I found a 1938 "monument" by the USC & GS (then-named) in the vicinity. So I started there in an elevation quest (to level-set one might say). 

My bookmark (pin) is:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">
<Placemark>
<name>BM Hampton</name>
<Point>
<coordinates>-76.59533879999999,39.4293622,0</coordinates>
</Point>
</Placemark>
</kml>

The records show the location is obscured.

 

I found a lot of topo data from the JHU Sheridan Libraries site

• JScholarship Home
• Library (Sheridan) General Collections
• Maps and Atlases
• Maryland State, County and Baltimore City Atlases 

 - https://jscholarship.library.jhu.edu/handle/1774.2/36112

Enough to get to the monument later, after the stream stomp. Good conditions for a field inspection given the lack of recent rain. More dry footing, and on the flip side, good mosquito breeding conditions. Not to mention poison ivy growth spurts.

The most downstream section goes into a culvert under a state/county highway, and I walked "up" from there. I'd been on the banks, obscured by overgrowth, before, just not at waters-edge.

Small pebbles, gravel, rocks, and at one stretch, broken-up concrete rubble fill (more or less). Not until I reached a section of shale (?) outcropping did I understand I was on land undisturbed by people. And by people, yes, white people.

I adjusted this image by 3 degrees once I spotted the building window that is unnaturally plumb.

And realized the streambed formerly went toward where the building and parking lot are now. Those streams that went southward can't anymore, though the sinkholes and disappearing streamflow says otherwise.

 Also see: https://www.baltimorecountymd.gov/departments/environment/watersheds/index.html

Beta Testing NetBSD 10; the Intermittent Result Set

After running sets of tests on the NetBSD 10.0 beta release, I had opened about 2 dozen problem reports of varying severity, and thought it time to take stock. Some have been closed, many have identified solutions, and a few are head scratchers. 

Full test cycle on an ARM soc

I set up a cron job to run the /usr/tests/ suite on a Pi 02W; it was taking a few hours to complete which allowed 8 hour restarts. The slice is roughly 8 hours, and includes CPU temperature, interrupts, and memory. Sorry I cut off the scale here.

This image is from 48 hours and shows CPU core temperature (Celsius) during the automated test cycle

The range goes from 45 to 50 with no tests running, then maxes to 60 at points.

Reviewing the test results (failures, in other words) reveals a few issues worth opening tickets, as did reading up on the test algorithms and reference pages. The aspect that intrigued me primarily were tests that did not pass or fail consistently. A typical case is running out of memory caused by creating sample data of variable dimensions. Side effects of this, for example:

[ 61059.604145] UVM: pid 12801 (h_libarchive), uid 0 killed: out of swap

Sometimes this is visible with vmstat commands:

 0 0     7960 330868    0   0   0    0    0    0  0 8519   18  36  0 0 100
 0 0     7960 330868    0   0   0    0    0    0  0 8521   18  38  0  0 100
Mon May  1 23:24:01 UTC 2023
 procs    memory      page                       disk faults      cpu
 r b      avm    fre  flt  re  pi   po   fr   sr l0   in   sy  cs us sy id
 1 0     1968 337656   47   0   0    0    4    4  1 8503  184  67  0  1 99
 1 0    10828 328948 7245   0   0    0    0    0 99 9117 5113 989  7 13 80
 2 0    19112 320688 2576   0   0    0    0    0 42 9392 4107 1979 12 16 72
 0 0     8568 331328 1534   0   0    0    0    0 89 8919 1788 949  1  5 95
 0 0     7896 332000  201   0   0    0    0    0  0 8534  254  44  0  0 100
 0 0     7896 332000    0   0   0    0    0    0  0 8527   18  36  0  0 100

Given those results are not indicative of system faults, looking at the other test case failures and sorting them by fixed/workarounds/etc, I have 3 that I don't know the root cause, and that's all of consequence. Two of them are wifi-relates and the third is a failure to compile profiling data into an an executable on a 32-bit Pi 02W. 

One of the intermittent has corresponding out-of-memory messages (57291). While it's a low priority issue because the tests would pass with more storage space, there is probably a way to avoid runaway space requests and still have useful tests.

Tickets with unknown root cause:

1. misc/57303 [serious/medium]: ATF unit test usr.sbin/tcpdump/t_tcpdump fails when wireless active on amd64
2. toolchain/57321 [non-critical/medium]: ATF test case usr.bin/cc/t_hello:hello_profile fails on RPI02W/evbarm only
3. bin/57366 [serious/medium]: Automated test usr.sbin/tcpdump/t_tcpdump:promiscuous fails on Rpi3 with wifi active

Tickets with known cause/workaround:

• kern/57185 [non-critical/medium]: Python build fails on 10_BETA due to no entropy on Atom CPU system
• misc/57286 [serious/medium]: Unit test fs/tmpfs/t_vnode_leak fails in ATF Tests suite
• misc/57291 [serious/medium]: Unit test for lib/libc/regex/t_exhaust fails in ATF Tests suite with signal 9
• lib/57314 [serious/medium]: 
• ATF unit tests fail on 3 of 7 cases in program lib/libc/c063/t_utimensat on evbarm/Rpi 02W
• kern/57320 [serious/medium]: ATF test case kernel/t_magic_symlinks:machine_arch fails on RPI02W/evbarm only [?]
• lib/57331 [serious/medium]: Automated unit test lib/libc/net/t_servent:servent fails on amd64 only
• misc/57361 [non-critical/medium]: Automated test t_archive fails 2 test cases on an Rpi3

Tickets fixed:

• misc/57284 [serious/medium]: Unit test for envstat fails in ATF Tests suite on one machine
• kern/57319 [serious/medium]: ATF test case kernel/t_magic_symlinks fails as non-root instead of showing expected fail message

Tickets with intermittent pass/fail results:

• misc/57291 [serious/medium]: Unit test for lib/libc/regex/t_exhaust fails in ATF Tests suite with signal 9
• kern/57345 [serious/medium]: Automated test kernel/kqueue/t_empty fails intermittently on an amd64 machine
• toolchain/57351 [serious/medium]: Automated test usr.bin/c++/t_tsan_vptr_race:vptr_race fails intermittently on an amd64 machine
• kern/57371 [serious/medium]: Automated test fs/vfs/t_vnops:nfs_rename_reg_nodir fails intermittently on Rpi3 and Rpi4
• kern/57385 [serious/medium]: Automated test case for puffs file system fails intermittently on different architectures

Documentation tickets:

• misc/57318 [non-critical/low]: Minor typos in an automated test case - atf/tools/atf-run_test
• misc/57332 [non-critical/low]: Replace 'http' with 'https' on netbsd.org links found in man pages
• misc/57343 [non-critical/low]: Typo in automated test rumpkern/t_vm.c  ('this' should say 'thus')
• misc/57344 [non-critical/low]: WIki page for evbarm port missing rpi4 mention
• misc/57347 [non-critical/low]: Several man pages have obsolete file location references under /usr/share/doc
• misc/57397 [non-critical/low]: Minor comment typos in t_vnops.c test program

Upsizing a Pi Zero (2W) to a Pi 3 Footprint

Recently I learned, and was intrigued, by two products from WaveShare, both enabling a small footprint Raspberry Pi Zero (2W in my case) to fill a Raspberry Pi 3 case by including a suite of adapters, plugs, and sockets. With the uninspiring brand name, "Raspberry Pi Zero [] to 3B Adapter." 

Raspberry Pi Zero To 3B Adapter, Alternative Solution for Raspberry Pi 3 Model B/B+

Raspberry Pi Zero 2W To 3B Adapter, Alternative Solution for Raspberry Pi 3 Model B/B+

Since I have 2 Pi's running NetBSD 10 BETA, I decided to try each version in a different system. Pictures follow; the basic difference between the A and B versions is the former may work with the vanilla Pi Zero while the latter probably doesn't.

Good/Bad/Ugly...

The "A" Board

Good: Cheaper of the 2 boards. HDMI full size socket (though now what do you do with the micro-HDMI already at hand?)

Bad: Does not relocate the microSD socket, making case adjustments necessary. See images.

Ugly: Ethernet is 100 BT.

Assembly is a little challenging for two hands, as the three connections for power, USB, and video must be made simultaneously. The connections seemed firm and sound once made, but I'd want to be careful not to torque the board any when joining to the Pi. I wouldn't think you would change this once plugged on (I don't plan to) either.

Access to the 40 pin bus is not obstructed as the board design wraps the opposite side.

NetBSD compatibility

Once I powered up the combined boards and booted a previously running system, I was happy to see the startup succeeded, with the provided RealTek ethernet stack working fine with NetBSD (some versions don't, or seem to only provide 100BT while claiming gigabit).

The USB V2 ports were fine; given the Zero doesn't have USB-3 I wouldn't expect an add-on board to provide accelerated throughput.

The "B" Board

Good: Includes an audio jack. Really good: Providing a micro-USB socket in the expected Pi3 location, somehow rewiring the onboard socket to an outboard one (I wonder what happens if you try to put chips in both sockets?) The funny aspect of this feature was that it went unremarked in the online feature set.

Bad: Case fit was a little tight; tolerances are fair. The connections were different than the A board, as only the HDMI port  is plugged in, while other connections get routed through "Pogo" pins. It sounded dubious (to me, who grew up reading Pogo in the comics) and I'm happily converted.

Ugly: Really can't see any downsides yet. Well, to be fair, being unable to access on-board wireless is a downside, requiring external wired or wireless dongles which might (or might not) work well under NetBSD.

Wifi on a pi3 with NetBSD?

http://mail-index.netbsd.org/port-arm/2019/08/31/msg006102.html

https://wiki.netbsd.org/ports/evbarm/raspberry_pi/

• RPI3 and RPI0W builtin WiFi - bwfm(4)
• "Note that the built-in WiFi in the RPI3 is not yet supported."

FreeBSD doesn't (yet) support Pi Wifi either - see https://wiki.freebsd.org/arm/Raspberry%20Pi

NetBSD compatibility

As this board appears to include an identical ethernet adapter logic as the "A" board, this system also rebooted with no issues (other than the usual DHCP name shuffling due to alternate MAC addresses than earlier adapters.

The "B" board has an audio jack, which the other does not. Though it seemed to be a valid device, my first tests playing music were failures of varying degrees. VLC/MPG123 worked once, then got really choppy. Error logs filled with messages.

Errors/messages:

A

[     5.502165] ure0: Realtek (0x0bda) USB 10/100 LAN (0x8152), rev 2.10/20.00, addr 6

B

[     3.828299] ure0: Realtek (0x0bda) USB 10/100 LAN (0x8152), rev 2.10/20.00, addr 4

[     4.428379] uaudio0 at uhub1 port 6 configuration 1 interface 0

[     4.438382] uaudio0: Solid State System Co.,Ltd. (0x0c76) USB PnP Audio Device (0x1203), rev 1.10/1.00, addr 5

Mar 25 23:00:00 b /netbsd: [ 5929.7443850] uaudio0: pintr error: IOERROR

Mar 25 23:00:00 b /netbsd: [ 5929.7443850] uaudio0: uaudio_chan_pintr: count(40) != size(1920), status(13)

Wrap-Up

The Pi Zero started out as a $5 computer.... [ raspberrypi.com/news/raspberry-pi-zero/ ]

Then it crept up a bit with the more powerful 2W. OK, it tripled at $15, but that doesn't include a necessary power supply, much less nice to have features like USB ports (mainboard has one, in the micro style). Spending as much or more on an expansion board needs justification, or at least a comparison between features versus price. I like the "all-in-one" feel of the expanded system in a tidy case, compared to a board with plugs hanging out left right and center.

Images

A

Top view. I left off a fan as the Zero is not a heat source of consequence.

Side view, showing the plastic frame cut away to allow the microSD card to stick out where it is on the Zero, but in a Three case.

The cutaway.

B

Zero, screwed in on top of the adapter board.

Can't close the case with the SD card on the Zero.

The closed case with the card in the new location.

It fits!

The end. For now.