orangecms

spawn qemu-system-x86_64 -machine accel=kvm -nographic -m 1024 -vga none -net user -net nic,model=virtio -device virtio-scsi-pci,id=scsi -cdrom plan9-gce.iso -boot d
c[?7lSeaBIOS (version ArchLinux 1.14.0-1)



iPXE (http://ipxe.org) 00:02.0 C000 PCI2.10 PnP PMM+3FF914D0+3FEF14D0 C000

Press Ctrl-B to configure iPXE (PCI 00:02.0)...
                                                                               

orangecms

Ref	Qnty	Value	Cmp name	Footprint	Description	Vendor
C1, C3, C4, C5, C6, C7, C8, C9,	8	100n	C	Capacitor_SMD:C_1206_3216Metric_Pad1.33x1.80mm_HandSolder	Unpolarized capacitor

orangecms

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

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

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

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

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

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

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

_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