There are various ways of adjusting the brightness on laptop panels. If you are running the correct Intel driver, it should be a matter of poking around the sysctl’s.

~% sysctl -a | grep lcd
hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
hw.acpi.video.lcd0.economy: 100
hw.acpi.video.lcd0.fullpower: 100
hw.acpi.video.lcd0.brightness: 60
hw.acpi.video.lcd0.active: 0

From that we know that the correct one to adjust is lcd0.brightness.

~% sudo sysctl hw.acpi.video.lcd0.brightness=50

I’m running Linux. Follow the instructions from Cross building NetBSD on Linux:

===> Successful make release
===> build.sh ended: Fri Nov 4 12:38:00 EDT 2016
===> Summary of results:
build.sh command: ./build.sh -U -u -m amd64 release
build.sh started: Fri Nov 4 10:17:30 EDT 2016
NetBSD version: 7.0.2
MACHINE: amd64
MACHINE_ARCH: x86_64
Build platform: Linux 4.8.6-1-ARCH x86_64
HOST_SH: /usr/bin/sh
MAKECONF file: /etc/mk.conf (File not found)
TOOLDIR path: /home/sinetek/dev/building-netbsd/usr/src/obj/tooldir.Linux-4.8.6-1-ARCH-x86_64
DESTDIR path: /home/sinetek/dev/building-netbsd/usr/src/obj/destdir.amd64
RELEASEDIR path: /home/sinetek/dev/building-netbsd/usr/src/obj/releasedir
Updated makewrapper: /home/sinetek/dev/building-netbsd/usr/src/obj/tooldir.Linux-4.8.6-1-ARCH-x86_64/bin/nbmake-amd64
Successful make release
build.sh ended: Fri Nov 4 12:38:00 EDT 2016
===> .

Then we build a custom configuration file for the kernel.
Drat. The config file for GENERIC already includes urtwn.
Let’s see what we can do poking around. Let’s grab the device id from Linux.

$ lsusb
Bus 001 Device 009: ID 07b8:8179 AboCom Systems Inc

Let’s poke around the driver. I found something interesting in if_urtwn.c.
From /sys/dev/usb/usbdevs.h I see that the constants I want are ABOCOM, and REALTEK RTL8188EU.
Let’s add these in.

diff –git a/sys/dev/usb/if_urtwn.c b/sys/dev/usb/if_urtwn.c
index 379365e..3294e54 100644
— a/sys/dev/usb/if_urtwn.c
+++ b/sys/dev/usb/if_urtwn.c
@@ -167,6 +167,7 @@ static const struct urtwn_dev {
URTWN_RTL8188E_DEV(ELECOM, WDC150SU2M),
URTWN_RTL8188E_DEV(REALTEK, RTL8188ETV),
URTWN_RTL8188E_DEV(REALTEK, RTL8188EU),
+ URTWN_RTL8188E_DEV(ABOCOM, RTL8188EU),
};
#undef URTWN_DEV
#undef URTWN_RTL8188E_DEV

… and the usbdevs:

diff –git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs
index bfe82a2..1bc213f 100644
— a/sys/dev/usb/usbdevs
+++ b/sys/dev/usb/usbdevs
@@ -640,6 +640,7 @@ product ABOCOM XX9 0x4104 XX9
product ABOCOM UFE2000 0x420a UFE2000 USB2.0 Fast Ethernet Adapter
product ABOCOM WL54 0x6001 WL54
product ABOCOM RTL8192CU 0x8178 RTL8192CU
+product ABOCOM RTL8188EU 0x8179 RTL8188EU
product ABOCOM RTL8188CU_1 0x8188 RTL8188CU
product ABOCOM RTL8188CU_2 0x8189 RTL8188CU
product ABOCOM XX10 0xabc1 XX10

Regenerate the correct usb dev headers.

$ TOOL_AWK=awk bmake -f Makefile.usbdevs usbdevs.h

Rebuild the kernel, then rebuild the iso image:

./build.sh -U -u -m amd64 release
./build.sh -U -u -m amd64 iso-image

Test. Mad Success!!

This post is solely concerned with the task of flashing a binary on the Arduino Due. While the Arduino software is great, I like having more control over low-level details.

The Arduino Due is a microcontroller board based on the Atmel SAM3X8E ARM Cortex-M3 CPU. For more information please see the official site.

The board itself has two programming ports. One of them is called the “native” port and is connected directly to the Atmel SAM3X chip. This has a few implications; if a program is already running, the USB port might not be in bootloader mode.

Programming Method

Connect the Arduino Due via the native port. Push the **ERASE** button.
The chip will now default to a programming mode.

Using Bossac

You should have bossac installed on your system. Let’s probe the chip.

~% sudo bossac -i
Password:
Device found on cuaU0
Atmel SMART device 0x285e0a60 found
Device : ATSAM3X8
Chip ID : 285e0a60
Version : v1.1 Dec 15 2010 19:25:04
Address : 524288
Pages : 2048
Page Size : 256 bytes
Total Size : 512KB
Planes : 2
Lock Regions : 32
Locked : none
Security : false
Boot Flash : false

The internal flash is 512KB. Let’s try writing a file.

sudo bossac -e -w -b=1 512k_file_input

Read back the chip, comparing the files, it should be the same.

sudo bossac -r 512k_file_output

Run the basic check.

[sinetek@SEATK0] ~% sha256 512k_file_input 512k_file_output
SHA256 (512k_file_input) = 3d338d950950054ec0d83191ce5e00ed067190af67c2a6eb41547a4bcf3ef1e0
SHA256 (512k_file_output) = 3d338d950950054ec0d83191ce5e00ed067190af67c2a6eb41547a4bcf3ef1e0

That is it for today. In the next installment we’ll make a little blinkylight demo, which will be more exciting!

I wanted to see if the updated NVMe kext in 10.13 (build 17A264c) loads under Sierra. Here is the answer.

$ sudo kextutil IONVMeFamily.kext
(kernel) kxld[com.apple.iokit.IONVMeFamily]: The super class vtable ‘__ZTV18IOTimerEventSource’ for vtable ‘__ZTV21AppleNVMeRequestTimer’ is out of date. Make sure your kext has been built against the correct headers.
(kernel) kxld[com.apple.iokit.IONVMeFamily]: The super class vtable ‘__ZTV18IOTimerEventSource’ for vtable ‘__ZTV21AppleNVMeRequestTimer’ is out of date. Make sure your kext has been built against the correct headers.
(kernel) kxld[com.apple.iokit.IONVMeFamily]: The super class vtable ‘__ZTV18IOTimerEventSource’ for vtable ‘__ZTV21AppleNVMeRequestTimer’ is out of date. Make sure your kext has been built against the correct headers.
(kernel) Can’t load kext com.apple.iokit.IONVMeFamily – link failed.
(kernel) Failed to load executable for kext com.apple.iokit.IONVMeFamily.
(kernel) Kext com.apple.iokit.IONVMeFamily failed to load (0xdc008016).
(kernel) Failed to load kext com.apple.iokit.IONVMeFamily (error 0xdc008016).
Failed to load IONVMeFamily.kext – (libkern/kext) link error.
Check library declarations for your kext with kextlibs(8).

My last adapter got damaged during travel, so I bought a new adapter. Enter the Rosewill N150UB.

In order to get this working on macOS Sierra, download and install the Realtek drivers for the EW7811Un; I had to modify two files to get the Rosewill working.
The procedure is simple, for both RtWlanU.kext and RtWlanU1827.kext, open Info.plist, copy a section for another device, and replace the values as follows.

Vendor:  3034

Device: 65519

Then you can reboot and load the driver with kextutil.

It seems that currently using Linux on hardware fakeraid-based platforms is not so simple.

In short, once you know of a little bug in the SiI 31xx controller series everything becomes much easier. Over there is a guide which can help you installing OpenSUSE/Fedora/Ubuntu on the Revodrive X2. The idea is you install everything but the bootloader, and then setup grub manually.

Thanks a bunch, CoolZero.