Archives For Uncategorized

CentOS 7 VM boot issue

January 10, 2020 — Leave a comment

If you’re building OVA based on CentOS 7 and your VM is stuck during boot at “tsc: Refined TSC clocksource calibration: NNNN.MMM MHz” message do not despair! It means the kernel can not find the root device and just waits for it to pop up. Which is not going to happen. In my case, it was a lack of required drivers loaded boot-time. Following line in an OVA build script resolved the issue:

dracut --regenerate-all --force --add-drivers "sd_mod mptspi" 

This post is just a breadcrumb for people googling for the line from the boot log. Might save you some time (might save future me some time).

Recreating Sneakers scene

September 28, 2019 — Leave a comment

(Not a FreeBSD topic)

A long time ago, in my teens, I watched movie Sneakers and was very impressed by it. It was exactly how I imagined hackers at work: bare PCBs, signal probes, de-scrambling encrypted information right on the screen. I was so impressed by the latter part that I went to re-create a bit of “No more secrets” scene using the only technologies I knew back then: Turbo Pascal running on MS-DOS. It wasn’t an exact replica but it was close enough and I was quite happy with the result. The program itself hasn’t survived my numerous moves from one apartment to another and got lost along with all the floppy discs sometime in the early aughts.

Recently I re-watched the movie and turned out that it holds up pretty well and still fun to watch. I thought that it would be a fun experience to re-create my small demo and check if I still remember any of the Pascal and DOS APIs. Equipped with Pascal for PC book published in ’91, some MS-DOS guides from the internet and a Guinness 4-pack I walked a short walk down the memory lane and it was fun. The result is published on Github. The demo in action:

FreeBSD support for pyu2f

September 22, 2019 — Leave a comment

After long hiatus (because $JOB) I’m trying to find some time to spend on FreeBSD-related projects, looking for small ones that can be done over weekend or a bit more. One of the ideas came from Ed Maste’s twitter: implement FreeBSD support for pyu2f. Since I already spent some time working on FreeBSD U2F support for Chromium it felt like a good small project.

The challenging part of the project was not U2F/HID but interfacing ioctl with Python, something I have never done before. It wasn’t super complex and I learned about Python’s ctype module.

Even more challenging though was to find a code to verify the implementation. Turned out there was no script to run end-to-end test. The closest I managed to find was this code in Xpra project. I used it as a base to write following test that registers app and then signs a pseudo challenge. It only verifies the interface part and doesn’t care about the actual signatures/keys:

import os
from pyu2f import u2f
from pyu2f import model

ORIGIN = 'https://kernelnomicon.org'
APP_ID = 'wordpress'
REGISTRATION_DAT = 'registration.dat'

device = u2f.GetLocalU2FInterface(ORIGIN)

# Try to register new app or read saved registration data if it exists
if os.path.exists(REGISTRATION_DAT):
    with open(REGISTRATION_DAT, 'rb') as f:
        rd = f.read()
else:
    r = device.Register(APP_ID, b'ABCD', [])
    rd = r.registration_data
    with open(REGISTRATION_DAT, 'wb+') as f:
        f.write(rd)

# extract public key, key handle length, and key handle
pubkey = bytes(rd[1:66])
# this is for Python3, use ord(rd[66]) for Python2
khl = rd[66]
key_handle = bytes(rd[67:67 + khl])

# Try to authenticate
key = model.RegisteredKey(key_handle)
response = device.Authenticate(APP_ID, b'012345678', [key])
print (response.signature_data)
print (response.client_data)

The final result is in my fork of pyu2f repo, on freebsd branch.

Inky pHat on FreeBSD/Pi

November 14, 2018 — Leave a comment

About a month ago I purchased Inky pHat from Pimoroni, Pi hat with 220×104 red and black eInk screen. The device has an SPI interface with three additional GPIO signals: reset pin, command/data pin, and busy pin. Reset and busy pins are self-explanatory: the former resets device MCU the latter signals to the Pi whether the MCU is busy handling previous command/data. Command/data signals the type of SPI transaction that is about to be sent to Inky: low means command, high – data. It more or less matches interface to SSD1306 OLED display I played with before.

There is no datasheet or protocol description, so I used Pimoroni’s python library as a reference.

To communicate with the device over SPI, you need to apply spigen device-tree overlay and load spigen driver. For Raspberry Pi 3 you probably need a patch from this review applied. To load overlay add respective dtbo name to the fdt_overlays variable in /boot/loader.conf, e.g.:

fdt_overlays="spigen-rpi3"

I didn’t have any practical purpose for the device in mind so after several failed attempts to output RGB images in two color I ended up writing random ornament generator:

ornament

cat

If you’re trying to boot FreeBSD with latest RaspberryPi firmware – be aware that this commit changed default frequency for UART0 on at least RaspberryPi 2, so to get serial console working in u-boot/ubldr again you need to add this line to config.txt:

init_uart_clock=3000000

You can get source for current kernel FDT blob by running following command

sysctl -b hw.fdt.dtb | dtc -I dtb -O dts

Edit 27/10/2017: added -O option, looks like it’s required in newer dtc

I’ve just added extended filters to http://mfc.kernelnomicon.org. Now filter can be either committer, or path, or both. Path is indicated by adding @ character to the beginning, so gonzo means all commits by gonzo, @sys/arm means all commits to sys/arm directory, and gonzo@sys/arm means all commits by gonzo to sys/arm directory. If there are more then one expression separated by space the result will be all filters OR-ed together: @sys/arm @boot/efi means all commits to sys/arm plus all commits to boot/efi directory.

raspberrypi-userland git repo was synced to the latest upstream code base: https://github.com/gonzoua/userland/tree/freebsd

Dear Future Me,

I guess you came here googling for “FreeBSD PXE UEFI” trying to find out how to netboot your x86 dev box. Or arm64 box. Who knows what you’re hacking on in the future. To do that you need follow these simple steps:

  • Put loader.efi to tftpboot dir
  • Configure dhcpd along these lines:
    host amd64 {
            hardware ethernet  b8:ae:ed:77:88:99;
            filename "loader.efi";
            option root-path "/src/FreeBSD/tftproot/amd64";
            fixed-address 192.168.10.102;
            option routers 192.168.10.1;
    }
    
  • Make sure root-path is in /etc/exports.
  • If you use MINIMAL-derived config add your NIC driver to /boot/loader.conf:
    if_re_load="YES"
    

That’s pretty much it.

Take care

Untethering Jetson-TK1

September 25, 2016 — Leave a comment

Normally I netboot all my ARM devices but in case of Jetson TK1 I thought it would be nice to go and try to make it “real computer” – running by itself, may be use it for some port builds. I added Samsung EVO to it but the plan was to use SSD for builds/source code, and to use either external SD card or eMMC as a root device. TK1 survived buildworld/buildkernel (I had to add swap though, clang is a memory monster) so it was time to populate root device and eMMC was picked as a target. There were some ms-basic-data partitions on eMMC but I didn’t think much of it and happily typed dd if=/dev/zero of=/dev/mmcsd0 bs=128m. Well… Big mistake. Among those partitions was u-boot. And probably earlier stage boot loader as well. So I had to install ubuntu on one of unused machines and re-flash TK1. Luckily no permanent damage was done to the device. After this accident I added a little bit of planning into the process. Here is short summary:

Default eMMC partition looks like this:

Tegra124 (Jetson TK1) #  mmc part

Partition Map for MMC device 0  --   Partition Type: EFI

Part    Start LBA       End LBA         Name
        Attributes
        Type GUID
        Partition GUID
  1     0x00017000      0x01c16fff      "APP"
        attrs:  0x0001000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   7369c667-ff51-ec4a-29cd-baabf2fbe346
  2     0x01c17000      0x01c18fff      "DTB"
        attrs:  0x0002000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   f854c27c-e81b-8de7-765a-2e63339fc99a
  3     0x01c19000      0x01c38fff      "EFI"
        attrs:  0x0003000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   b70d3266-5831-5aa3-255d-051758e95ed4
  4     0x01c39000      0x01c3afff      "USP"
        attrs:  0x0004000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   c6cdb2ab-b49b-1154-0e82-7441213ddc87
  5     0x01c3b000      0x01c3cfff      "TP1"
        attrs:  0x0005000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   a13ee970-e141-67fc-3e01-7e97eadc6b96
  6     0x01c3d000      0x01c3efff      "TP2"
        attrs:  0x0006000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   2a5c388f-b0ec-fb3b-32af-3c54ec18db5c
  7     0x01c3f000      0x01c40fff      "TP3"
        attrs:  0x0007000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   43fe1a02-fafb-3aaa-fb29-d1e6053c7c94
  8     0x01c41000      0x01c41fff      "WB0"
        attrs:  0x0008000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   61bed875-f989-bb5c-a899-0f95b1ebf1b3
  9     0x01c42000      0x01d58fff      "UDA"
        attrs:  0x0009000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   00f7ef05-a1e9-e53a-ca0b-cbd0484764bd

We need two things to make TK1 bootable: place ubldr on flash so u-boot can load it and create rootfs. The latter one is simple: APP partition is the one to be user as root. For the former either of TPx partitions can be used, TP stands for “Temporary Placeholder” and can be used for app-specific tasks. All three TPx are just 4Mb but ubldr is small enough to fit just fine. So let’s place ubldr to TP1:

# newfs_msdos /dev/gpt/TP1
# mount_msdosfs /dev/gpt/TP1 /mnt
# cp ubldr.tk1 /mnt/
# umount /mnt

Then populate rootfs:

# newfs /dev/gpt/APP
# mount /dev/gpt/APP /mnt

Then build/install stuff: … buildworld, buildkernel. installworld, distribution and installkernel with DESTDIR=/mnt …

Create /etc/fstab so kernel would pick up correct rootfs location. I also use nullfs to mount /tmp to the directory on SSD drive, and added swap file on SSD.

/dev/gpt/APP /       ufs     rw,noatime     0       0
/dev/ada0    /src    ufs     rw,noatime     0       0
md99         none    swap    sw,file=/src/swap,late      0       0
/src/tmp     /tmp    nullfs  rw             0       0
# umount /mnt

Reboot to u-boot and set up boot command:

Tegra124 (Jetson TK1) # setenv bootcmd 'fatload mmc 0:5 $loadaddr ubldr.tk1; bootelf'
Tegra124 (Jetson TK1) # saveenv
Saving Environment to MMC...
Writing to MMC(0)... done
Tegra124 (Jetson TK1) # boot

That’s it. Also if I need to revert back to netbooting TK1 I can just set loaderdev to “net” in u-boot:

Tegra124 (Jetson TK1) # setenv loaderdev net; boot