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: ...
(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. ...
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. ...
About a month ago I purchased Inky pHat from Pimoroni, Pi hat with 220x104 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. ...
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. ...
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: ...