orangecms

Speedy Distro Porting via the cpu Command

Last year, I ported oreboot to the Allwinner D1 SoC that is found on the Nezha SBC and many other boards now. For a boot loader environment, I chose to embed LinuxBoot, and then partitioned an SD card with two root filesystems for testing: OpenWrt, which is small and just ran right away, and openSUSE, which required some extra effort. I was happy to see a new D1 board advertised with openSUSE support, though the process of getting there was tedious enough that I wanted to find an

orangecms

SoC

The SoC is unlabeled but turns out to be an Allwinner T3/R40 aka sun8iw11p1.

The device is presumably also known as ShareVDI R1 (Pro).

See also:

• https://www.sharevdi.com/list/81.html
• https://sharevdi.en.made-in-china.com/product/AZaJPvBEqxcz/China-Low-Price-Thin-Client-1GB-RAM-8GB-Flash-Linux-Mini-PC-Station.html
• Debian on Allwinner

orangecms

#!/bin/sh

_REGS=`echo RomProtect{0,1,2,3} SPICntrl0 SPIRestrictedCmd{,2} AltSPICS`

for r in $_REGS; do
    chipsec_util.py reg read $r
done

dmidecode -t bios -t system

orangecms

During the last two years, I have collected ARM and RISC-V gadgets and development boards. What I realized is that many of them run systems far off mainline Linux, and quite often do the vendors not publish the sources. However, when able to get serial output, I can fix that. And that is where many engineers start with regular development, so we are in the same boat.

Now how do the original drivers work? Applications in existing products often have userspace or hybrid drivers, which opens up a door. We can emulate the app, e.g., in QEMU, and monitor I/O accesses. Then we can write our own driver. But that is a tedious and time consuming process, the most inconvenient step being

orangecms

#!/bin/sh

set -e

_NAME=u-root-nezha
_DIR=/tmp/$_NAME
_FLAGS=-build=bb

# Get u-root, module workaround is necessary as of now
# see also https://github.com/u-root/u-root#warning-go-modules-are-a-work-in-progress-warning

orangecms

^AWelcome to oreboot
^AWelcome to oreboot
## Loading payload
Running payload entry 0x40100000
[rustsbi] RustSBI version 0.2.0-alpha.4
.______       __    __      _______.___________.  _______..______   __
|   _  \     |  |  |  |    /       |           | /       ||   _  \ |  |
|  |_)  |    |  |  |  |   |   (----`---|  |----`|   (----`|  |_)  ||  |
|      /     |  |  |  |    \   \       |  |      \   \    |   _  < |  |
|  |\  \----.|  `--'  |.----)   |      |  |  .----)   |   |  |_)  ||  |

orangecms

Modern SE and Terminology (t9y, [ti-nee])

Motivated by Bryan Cantrill, who brought up the abbreviation o11y for observability and is well known for his work on DTrace and blogging about his views on software, here are further ideas and thoughts on modern software engineering, explaining desirable properties of a software project and working with it for continuous improvement, longevity, and general sustainability, from cooperation to long-term maintenance.

orangecms

Howto

https://padcom.aplaline.com/2015/12/running-lcdproc-on-digispark.html

DigiSpark I2C

Micronucleus ATtiny bootloader

https://gist.github.com/Ircama/22707e938e9c8f169d9fe187797a2a2c#flashing-the-micronucleus

orangecms

"Id"	"Designator"	"Package"	"Quantity"	"Designation"	"Supplier and ref"
1	"U2,U1"	"JOYSTICK_W_BUTTON"	2	"JOYSTICK_W_BUTTON"
2	"SW2,SW1"	"SW_PUSH-12mm"	2	"SW_Push"
3	"H22,H21,H20,H19,H18,H17,H16,H15,H12,H11,H10,H9,H8,H7,H6,H5"	"MountingHole_2.1mm"	16	"MountingHole"
4	"J11,J10,J9,J4"	"PinHeader_2x10_P2.54mm_Vertical"	4	"Conn_02x10_Odd_Even"
5	"R9,R20,R19,R18,R17,R16,R15,R13,R12,R11,R10,R8,R7,R6"	"R_1210_3225Metric_Pad1.30x2.65mm_HandSolder"	14	"27"
6	"C8,C9,C7,C6,C5,C4,C3,C1"	"C_1206_3216Metric_Pad1.33x1.80mm_HandSolder"	8	"100n"
7	"TP3,TP2,TP1"	"TestPoint_Pad_D1.0mm"	3	"TestPoint"
8	"R21,R14,R2"	"R_1210_3225Metric_Pad1.30x2.65mm_HandSolder"	3	"100"

orangecms

IPL g8c8fea1
D-05
HW Reset
SPI 54M
64MB
BIST0_0001-OK
MXP found at 0x00020000
offset:00010000
Checksum OK