80386

One always remembers their first love. For me, that was i386DX running at screaming 40 MHz.

So, why am I having this senior moment remembering things from my youth? Well, Ken Shirriff decided to spend a bit of time, some acid, and a lot of patience in order to reverse engineer i386 processor logic cells. It’s a fascinating read.

So, for all i386 afficienados, here are a few of his articles to read (in order of my choosing):

• Reverse engineering standard cell logic in the Intel 386 processor
• Examining the silicon dies of the Intel 386 processor
• Inside the Intel 386 processor die: the clock circuit
• Two interesting XOR circuits inside the Intel 386 processor
• Reverse engineering the barrel shifter circuit on the Intel 386 processor die
• A CT scanner reveals surprises inside the 386 processor’s ceramic package
• Here be dragons: Preventing static damage, latchup, and metastability in the 386

Full Windows on USB Drive

While I am primarily a Linux user these days, I do need Windows occasionally. And on my Framework laptop, I find using Storage Expansion Card (essentially an USB drive) a perfect medium for it. I already wrote about Windows To-Go installation. But what if I wanted something more substantial? A full installation maybe?

Well, we can do that with the help of a few manual commands.

To start, we boot Windows 11 (or 10) off the USB as we normally would. However, instead of proceeding with the normal install, we press Shift+F10 to get into the command prompt.

First, we start with partitioning using the diskpart utility. I opted for a bit simpler partition setup than what Windows would generate normally. Most notably, there is no recovery partition. If you want one, you can just follow Microsoft’s instructions once system is up and running.

Within diskpart, the first task is to select the disk. Make sure it is the USB disk on which you want to install Windows. Failure to do so will surely damage something. Once the disk is cleaned, we follow with the creation of a few basic partitions before exiting the tool back to the command prompt.

LIST DISK
SELECT DISK 

CLEAN
CONVERT GPT

CREATE PARTITION EFI SIZE=100
FORMAT QUICK FS=fat32
ASSIGN LETTER S

CREATE PARTITION MSR SIZE=128

CREATE PARTITION PRIMARY
FORMAT QUICK FS=ntfs
ASSIGN LETTER W

LIST VOLUME
EXIT

Now we can install Windows using a combo of dism (to copy the Windows image) and bcdboot (to sort out EFI boot). Please note that if you already have Windows installed, the source files will most probably be on drive D: instead of C:. Depending on how the bootable USB was created, you might also need to change install.wim to install.esd. If the installation contains multiple editions, you can select which one you want using the /Index:N parameter.

DISM /Get-WimInfo /WimFile:C:\Sources\install.wim
DISM /Apply-Image /ImageFile:C:\sources\install.wim /Index:1 /ApplyDir:W:\
BCDBOOT W:\Windows /s S: /f UEFI

Once both commands are done, exit the installation process and reboot into our new installation. If it’s not a default boot location, make sure to press F12 to select it.

And that’s it - now you have Windows on a completely separate drive without any intermingling with the Linux installation.

Linux USB Auto-Suspend for FTDI

As I was playing with a few FTDI devices of mine, I noticed each was pulling 100 mA or more. Considering they were intended for use in a laptop, that made me worry a bit. Darn IC should have suspend and these numbers should not be the norm. So I went to investigate on how to reduce this a bit.

The first tool is, of course, lsusb. Using lsusb -tv I got the following output:

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M`
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 3: Dev 60, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
        ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
    |__ Port 7: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
        ID 0bda:5634 Realtek Semiconductor Corp.
    |__ Port 7: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
        ID 0bda:5634 Realtek Semiconductor Corp.
    |__ Port 9: Dev 4, If 0, Class=Vendor Specific Class, Driver=, 12M
        ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd.
    |__ Port 10: Dev 5, If 0, Class=Wireless, Driver=btusb, 12M
        ID 8087:0026 Intel Corp. AX201 Bluetooth
    |__ Port 10: Dev 5, If 1, Class=Wireless, Driver=btusb, 12M
        ID 8087:0026 Intel Corp. AX201 Bluetooth
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
        ID 0bc2:ab30 Seagate RSS LLC
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub

Device I wanted to analyze was at bus 3, port 3. This knowledge allowed me to check its power level.

cat /sys/bus/usb/drivers/usb/3-3/power/level

Value on that was returned immediately confirmed what I suspected. The port standby was disabled. Another test was to write auto inside the same file and current consumption fell down after 2-3 seconds (essentially, USB standby timeout), as expected.

Unfortunately, as soon as the device was plugged back in, it reset its behavior to always-on. Well, udev rules to the rescue.

Only, I already had FTDI udev rules present on my system (/etc/udev/rules.d/99-libftdi.rules). It seems that one of the tools I used (ftdidev library being the prime suspect) already installed some rules. Any rules I add to that file might get overwritten eventually. So, I decided to create a new file for both FT232R and X Series chips.

cat << EOF | sudo tee /etc/udev/rules.d/42-ftdi.rules
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTR{power/control}:="auto"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", ATTR{power/control}:="auto"
EOF

This will turn on auto standby handling for my FTDI devices while making sure that subsequent rule doesn’t overwrite it (thus :=). Exactly what I needed to make my laptop battery happy.

To apply this without reboot, you can use the following command:

sudo udevadm control --reload-rules && sudo udevadm trigger

Avalonia Workaround for ShowDialog Focus

As I was working on a Linux C# application, I was kinda annoyed with the new dialog not having keyboard control. The window would actually display correctly on top of its owner, but it would never take the keyboard focus onto itself. Thus, no keyboard control. A bit of searching also showed that this was already a known issue, sitting pretty for a while now.

But thankfully, the workaround is rather simple. From within your code, just attach (or override) to your Activated event and manually select the button.

Activated += delegate { button.Focus(); };

With this, Avalonia will switch focus to the new window, and everything else will work as expected.

Reading DDR4 SPD Information on Supermicro M11SDV

Viewing DIMM SDP data under Linux is usually a trivial affair. On my Framework (gen 11) laptop, this went something like this:

sudo apt install i2c-tools
sudo modprobe eeprom
sudo modprobe i2c-i801
sudo decode-dimms

However, on my Supermicro M11SDV server with AMD Epyc 3000 processor, this didn’t work. No matter what I did, nothing would show. After messing around a bit, I found the solution on Unraid forum.

First, I needed to find where is SPD actually listening. The easiest way to determine this is to first list all I2C buses and then search for devices between I2C addresses 0x50 and 0x57:

sudo i2cdetect -l
sudo i2cdetect -y 0 0x50 0x57
sudo i2cdetect -y 1 0x50 0x57
sudo i2cdetect -y 2 0x50 0x57

For my motherboard, I actually found output on bus number 2. It looked something like this:

Warning: Can't use SMBus Quick Write command, will skip some addresses
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:
10:
20:
30:
40:
50: 50 51 52 53 -- -- -- --
60:
70:

Once the bus is found, we just need to load the ee1004 module that works on AMD board. This has to be repeated for each I2C address that was found. Do note that the path contains the I2C bus number (in my case i2c-2).

sudo modprobe ee1004
echo ee1004 0x50 | sudo tee /sys/bus/i2c/devices/i2c-2/new_device
echo ee1004 0x51 | sudo tee /sys/bus/i2c/devices/i2c-2/new_device
echo ee1004 0x52 | sudo tee /sys/bus/i2c/devices/i2c-2/new_device
echo ee1004 0x53 | sudo tee /sys/bus/i2c/devices/i2c-2/new_device

And now finally we can run decode-dimms again and read all that lovely SPD data.