<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Firmware on tsvinc</title>
		<link>https://tsvinc.dev/tags/firmware/</link>
		<description>Recent content in Firmware on tsvinc</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Fri, 16 Oct 2026 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://tsvinc.dev/tags/firmware/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>The pin template was for a different plug</title>
				<link>https://tsvinc.dev/posts/tuya-plug-openbeken-grid-canary/</link>
				<pubDate>Fri, 16 Oct 2026 00:00:00 +0000</pubDate>
				<guid>https://tsvinc.dev/posts/tuya-plug-openbeken-grid-canary/</guid>
				<description>&lt;p&gt;The smart plug&#39;s vendor app put its energy monitoring behind a subscription. The metering chip inside measures voltage alongside current and power all the same, whatever the app agrees to show. I wanted that voltage. Read off a plug on wall power, it says whether the grid is up, and my &lt;a href=&#34;https://tsvinc.dev/posts/bluetti-ac180-ups-over-bluetooth/&#34;&gt;power-station UPS&lt;/a&gt; needed exactly that: a second opinion on the grid from something not behind a battery.&lt;/p&gt;&#xA;&lt;p&gt;So the plug had to leave Tuya&#39;s firmware for &lt;a href=&#34;https://github.com/openshwprojects/OpenBK7231T_App&#34;&gt;OpenBeken&lt;/a&gt;, an open firmware for the Beken chips in most Tuya plugs. That took one evening. Getting the pins right took the next day, because the template I borrowed was for a different plug, and the plug&#39;s own leftover settings were the only thing that knew.&lt;/p&gt;</description>
			</item>
			<item>
				<title>No BIOS image, so I diffed the NVRAM</title>
				<link>https://tsvinc.dev/posts/no-bios-image-diff-nvram/</link>
				<pubDate>Sat, 10 Oct 2026 00:00:00 +0000</pubDate>
				<guid>https://tsvinc.dev/posts/no-bios-image-diff-nvram/</guid>
				<description>&lt;p&gt;flashrom got two attempts at the GEEKOM A9 Mega&#39;s SPI flash. Both were read-only: &lt;code&gt;-r&lt;/code&gt;, run twice, so the two dumps could be hashed against each other before anyone trusted them. The package was Fedora 45&#39;s &lt;code&gt;flashrom-1.6.0-6.fc45&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Attempt one, Secure Boot on.&lt;/strong&gt; The kernel is in lockdown, and lockdown takes raw port I/O away from userspace: &lt;code&gt;ioperm&lt;/code&gt; and &lt;code&gt;iopl&lt;/code&gt; are on its refusal list. flashrom never reaches the chip.&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Attempt two, Secure Boot off.&lt;/strong&gt; flashrom runs, and names the chipset &amp;quot;AMD FP4&amp;quot;. The CPU is a Ryzen AI Max+ 395, family 0x1A, model 0x70: Strix Halo. Whatever flashrom thinks it is talking to, it is not this. It fails to lift the ROM protection, changes nothing, and segfaults.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
