[{"content":"I wrote an introductory article on how the audio subsystem on SBCs work: CODECs, I2S, DTS, whole nine yards. WordPress editor didn\u0026rsquo;t seem to be a very convenient tool for this kind of write up so I gave asciidoc a try and so far liked it.\nLink to the article: https://kernelnomicon.org/texts/sbc-audio.html\n","permalink":"https://kernelnomicon.org/posts/audio-subsystem-hardware-internals/","summary":"\u003cp\u003eI wrote an introductory article on how the audio subsystem on SBCs work: CODECs, I\u003csup\u003e2\u003c/sup\u003eS, DTS, whole nine yards. WordPress editor didn\u0026rsquo;t seem to be a very convenient tool for this kind of write up so I gave asciidoc a try and so far liked it.\u003c/p\u003e\n\u003cp\u003eLink to the article: \u003ca href=\"https://kernelnomicon.org/texts/sbc-audio.html\"\u003ehttps://kernelnomicon.org/texts/sbc-audio.html\u003c/a\u003e\u003c/p\u003e","title":"Audio subsystem hardware internals"},{"content":"Some time ago Filippo Valsorda wrote yubikey-agent, seamless SSH agent for YubiKeys. I really like YubiKeys and worked on the FreeBSD support for U2F in Chromium and pyu2f, getting yubikey-agent ported looked like an interesting project. It took some hacking to make it work but overall it wasn\u0026rsquo;t hard. Following is the roadmap on how to get it set up on FreeBSD. The actual details depend on your system (as you will see)\nThe first step is to set up middleware for accessing smart cards (YubiKey implements CCID smart-card protocol). The pcsc-lite package provides a daemon and a library for clients to communicate with the daemon. ccid is a plugin for pcsc-lite that implements the actual CCID protocol over USB. devd rules are to make the daemon re-scan USB devices on hotplug\nsudo pkg install ccid pcsc-lite sudo mkdir -p /usr/local/etc/devd sudo tee /usr/local/etc/devd/pcscd.conf \u0026lt;\u0026lt; __EOF__ attach 100 { device-name \u0026#34;ugen[0-9]+\u0026#34;; action \u0026#34;/usr/local/sbin/pcscd -H\u0026#34;; }; detach 100 { device-name \u0026#34;ugen[0-9]+\u0026#34;; action \u0026#34;/usr/local/sbin/pcscd -H\u0026#34;; }; __EOF__ sudo service devd restart sudo sysrc pcscd_enable=\u0026#34;YES sudo service pcscd start go and git are build requirements for the app. go get command is required because FreeBSD support was only recently merged into piv-go and the latest release, referenced in go.mod, still does not have it. go install command installs the app in ~/go/bin/. When new version of piv-go is released and yubikey-agent switches to using it, all these commands can be replaced with single go get github.com/FiloSottile/yubikey-agent command.\nsudo pkg install go git git clone https://github.com/FiloSottile/yubikey-agent.git cd yubikey-agent go get github.com/go-piv/piv-go@a3e5767e go build go install The binary is in ~/go/bin/ directory, you can add it to your $PATH to type less.\nThe next step is setting up a Yubikey, it\u0026rsquo;s well documented on the official site. One caveat though is if PIN length is less than 6 chars the setup fails with the somewhat confusing message: \u0026ldquo;‼️ The default PIN did not work.\u0026rdquo;\nThe actual usage of yubikey-agent depends on your setup. First of all, yubikey-agent is a \u0026ldquo;eventually GUI\u0026rdquo; app. At some point, when entering PIN is required it starts pinentry command which task is to present user with a dialog entry, get PIN, and pass it to the app. There are multiple pinentry flavors, with different front-ends: TTY, Qt, GTK. gopass module used in yubikey-agent does not work with plain TTY backend, and requires pinentry to be a GUI app. On Debian/Ubuntu users can switch between flavors and make /usr/bin/pinentry point to either Qt5 or GTK version, but in FreeBSD /usr/local/bin/pinentry is always TTY one. I worked around it by installing pinentry-qt5 package and making symlink.\nsudo pkg install pinentry-qt5 sudo ln -s /usr/local/bin/pinentry-qt5 /usr/local/bin/pinentry If you need /usr/local/bin/pinentry to be TTY version for some other stuff, there may be a problem. How to work around this depends on your requirements. I don\u0026rsquo;t have a ready recipe.\nBecause yubikey-agent is \u0026ldquo;eventually GUI\u0026rdquo; you can either start it in .xsession or .xinitrc files or start it some other way with DISPLAY env variable set. Other than that official documentation is a good source of information on how to use it.\n","permalink":"https://kernelnomicon.org/posts/yubikey-agent-on-freebsd/","summary":"\u003cp\u003eSome time ago \u003ca href=\"https://filippo.io/\"\u003eFilippo Valsorda\u003c/a\u003e wrote \u003ca href=\"https://github.com/FiloSottile/yubikey-agent\"\u003eyubikey-agent\u003c/a\u003e, seamless SSH agent for YubiKeys. I really like YubiKeys and worked on the FreeBSD support for U2F in Chromium and pyu2f, getting yubikey-agent ported looked like an interesting project. It took some hacking to make it work but overall it wasn\u0026rsquo;t hard. Following is the roadmap on how to get it set up on FreeBSD. The actual details depend on your system (as you will see)\u003c/p\u003e","title":"yubikey-agent on FreeBSD"},{"content":"\nWhenever I sit down to work at the coffee shop I\u0026rsquo;ve never been before my preparation routine looks more or less like this: ifconfig wlan0 list scan, copy SSID, vim /etc/wpa_supplicant.conf, service netif restart. The WM I use, i3, does not have fancy network managers that nicely offer you to join available WiFi networks. It\u0026rsquo;s mildly annoying but not annoying enough to actually make me open a browser and go looking for ways to automate this procedure. Implementing such a utility, on the other hand, sounds like a nice weekend project.\nI wanted to try out the Go language for a long time but didn\u0026rsquo;t have a good idea for a project and this WiFi manager tool looked like a good fit to learn how stuff is done there because it required: starting a child process and parsing its output, file I/O, work with strings, TUI elements.\nThe data management bits were easy, the standard library provides all the required functionality, and for TUI framework I picked up termui. Midway through implementation, I realized that the main use case of the framework is to present data, and interacting with the user was not its forte, but I decided to press on and just hack something together. It was just for fun after all. It worked out acceptable in the end.\nWithout further ado, let me introduce Chai-Fi, the minimalistic wpa_supplicant.conf \u0026ldquo;manager\u0026rdquo; for FreeBSD. To be used in coffee shops, guest networks, and other locations. It\u0026rsquo;s got a bunch of stuff hardcoded, not very portable between different TERMs and probably won\u0026rsquo;t look nice with non-Unicode fonts. But hey, it works on my laptop. Who knows, might work on yours\n","permalink":"https://kernelnomicon.org/posts/wpa_supplicant-conf-manager-for-coffee-shops/","summary":"\u003cp\u003e\u003cimg alt=\"https://github.com/gonzoua/chaifi\" loading=\"lazy\" src=\"/uploads/2020/05/screenshot-1024x576.png\"\u003e\u003c/p\u003e\n\u003cp\u003eWhenever I sit down to work at the coffee shop I\u0026rsquo;ve never been before my preparation routine looks more or less like this: \u003ccode\u003eifconfig wlan0 list scan\u003c/code\u003e, copy SSID, \u003ccode\u003evim /etc/wpa_supplicant.conf\u003c/code\u003e, \u003ccode\u003eservice netif restart\u003c/code\u003e. The WM I use, i3, does not have fancy network managers that nicely offer you to join available WiFi networks. It\u0026rsquo;s mildly annoying but not annoying enough to actually make me open a browser and go looking for ways to automate this procedure. Implementing such a utility, on the other hand, sounds like a nice weekend project.\u003c/p\u003e","title":"wpa_supplicant.conf \"manager\" for coffee shops"},{"content":"If you want to jump right into the action check out freebsd-mkova repo. Below are some technical details on what OVA is and its internals.\nIn addition to installation media like DVD or memstick, FreeBSD RE ships FreeBSD releases as a virtual disk image in a number of formats. This is a convenient way when you start your whole VM using bhyve or qemu, as a single CLI command and pass the image location as an argument. It\u0026rsquo;s less handy if you try to create VM using GUI-based tools like VMWare or VirtualBox. You need to create VM and then configure it to use the image as a drive. Not an awful lot of work but still.\nAt my $DAYJOB I came across another way of shipping VM-based products called virtual appliance. Essentially it\u0026rsquo;s a pre-configured virtual machine with disk image included in a self-contained file that can be imported by hypervisor software using couple of mouse clicks or a single command like VBoxManage import. The file format for this kind of deliverables is OVA\nInternally OVA is a tar(1) archive that includes OVF file, disk image or images in VMDK format, and optional manifest (list of files with checksums). OVF file is an XML file with VM description that looks like this. More information on the format can be found at https://www.dmtf.org/standards/ovf.\nSo on the surface, we need to take official VMDK, create XML file and package them both in .tar archive. Unfortunately, there is a problem: VMDK format comes in several flavors and while FreeBSD RE ships monolithic sparse, OVA needs the image in stream-optimized flavor.\nAs the name implies monolithic-sparse format does not have every single sector of the virtual disk in the file, it only stores the data that was written by OS. The standard unit of data on disk is a sector, usually 512 bytes long. VMDK organizes sectors in grains: a sequence of sectors. The size of the grain (in sectors) is defined in the VMDK header as a grainSize field. So if an image is N sectors long there are N/grainSize grains. Only grains with the content that is different from all-zeroes are stored in the image file. To organize fast random access to the stored data in the image VMDK maintains a two-level index: grain directory and grain table. Grain table is a fixed-size array (numGTEsPerGT field in the header) with offsets of the grain in VMDK. If offset is zero it means the grain is not present in the file and its content is all-zeroes. Grain tables\u0026rsquo; offsets, in turn, are stored in grain directory. And again if offset in the directory is zero it means none of the grains in the table is present in the image. The sequence of steps to read sector X from the VMDK is approximately this:\ngrainIdx := [X / grainSize] // Find the grain index gtIdx := [grainIdx / numGTEsPerGt] // Find the grain table index gtOffset := grainDirectory[gtIdx] // Find grain table offset // if gtOffset is zero return empty sector grainTable := readAt(gtOffset) // read grain table data grainOffset := grainTable[X % grainSize] // find grain offset // if grainOffset is zero return empty sector sectorData := readAt(grainOffset + (X % grainSize)) // read sector data The VMDK file layout for monolithic sparse format would look like:\n[header] [imageDescriptor] [GrainDirectory] [GrainTable0] \u0026hellip; [GrainTableN ] [ Grain0 ] [GrainX ] [ GrainY ] \u0026hellip; [ GrainZ\nThe stream-optimized VMDK operates with the same concepts: grain, grain table, grain directory but organizes them differently. Again as the name implies it\u0026rsquo;s optimized for streaming which means no random access to the image file so it lays out elements a bit differently. GD, GT, grains are prefixed with the markers and can be detected as the software reads file from the network. Also, grains can be compressed to save bandwidth. The stream-optimized VMDK layout looks like this:\n[ header ] [imageDescriptor] [GrainMarker] [Grain] \u0026hellip; [GrainMarker] [Grain] [GrainTableMarker] [GrainTable0] \u0026hellip; [GrainDirectoryMarker] [GrainDirectory] [FooterMarker][FinalHeader] [EndOfStreamMarker]\nthe FinalHeader is the copy of the header with the gdOffset field set to point to [GrainDirectory] location\nAs you can see the conversion from monolithic sparse to stream optimized is quite straightforward. I spent some time implementing it over the holiday break, added OVF generation logic and shipped freebsd-mkova. I wanted to write it in Go to practice a new language but was turned off by the XML generation and namespaces support in it, it felt unnecessary verbose and clunky. Will try to find some other project for Go my studies.\n","permalink":"https://kernelnomicon.org/posts/creating-freebsd-ova-files/","summary":"\u003cp\u003eIf you want to jump right into the action check out \u003ca href=\"https://github.com/gonzoua/freebsd-mkova\"\u003efreebsd-mkova\u003c/a\u003e repo. Below are some technical details on what OVA is and its internals.\u003c/p\u003e\n\u003cp\u003eIn addition to installation media like DVD or memstick, FreeBSD RE ships FreeBSD releases as a virtual disk image in a number of formats. This is a convenient way when you start your whole VM using bhyve or qemu, as a single CLI command and pass the image location as an argument. It\u0026rsquo;s less handy if you try to create VM using GUI-based tools like VMWare or VirtualBox. You need to create VM and then configure it to use the image as a drive. Not an awful lot of work but still.\u003c/p\u003e","title":"Creating FreeBSD OVA files"},{"content":"If you\u0026rsquo;re building OVA based on CentOS 7 and your VM is stuck during boot at \u0026ldquo;tsc: Refined TSC clocksource calibration: NNNN.MMM MHz\u0026rdquo; 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:\ndracut --regenerate-all --force --add-drivers \u0026#34;sd_mod mptspi\u0026#34; 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).\n","permalink":"https://kernelnomicon.org/posts/centos-7-vm-boot-issue/","summary":"\u003cp\u003eIf you\u0026rsquo;re building OVA based on CentOS 7 and your VM is stuck during boot at \u0026ldquo;tsc: Refined TSC clocksource calibration: NNNN.MMM MHz\u0026rdquo; 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:\u003c/p\u003e","title":"CentOS 7 VM boot issue"},{"content":"Last two weeks I\u0026rsquo;ve been working on audio support for Firefly-RK3399. Full support requires a number of things that are not quite there or not available in the mainline FreeBSD kernel. The main low-level hardware functionality consists of two parts: I2S block in the SoC and RT5640 audiocodec that converts digital audio to an analog signal. They talk to each other using the I2S protocol. A little bit higher is FDT virtual \u0026ldquo;devices\u0026rdquo; called simple-audio-card. This part is responsible for coordinating the setup of both hardware components: make sure they agree on a number of channels, a number of bits per sample and clock specifics of the I2S protocol. There is no code for it in the FreeBSD kernel, so I had to just hardcode these things in both hardware drivers.\nThe other obviously missing part was I2S clocks in the CRU unit drivers. This was easily fixable by just consulting with RK3399 TRM. Still, having added the clocks support I couldn\u0026rsquo;t get the signal on the physical pin. Thanks to manu@ who pointed out that some stuff might be missing in io-domain and power regulators area it was resolved too after setting bit 1 of GRF_IO_VSEL register\nWith all these bits in place, I was able to get sound out of headphones, but it was distorted. My first instinct was to blame mismatch of clocks/formats between I2S and codec, so I spent two very frustrating days experimenting with setting polarities and data formats just to find out that there is GPIO that controls headphone output on Firefly-RK3399. This is Firefly-specific bit and only referenced in the Firefly fork of the Rockchip fork of the Linux kernel. The way it\u0026rsquo;s implemented loud noises still can pass through the filter to headphones, so at max volume, you can here laud parts as a series of pops and grunts. By manually configuring GPIO4_C5 (gpioc4/pin21) I finally was able to get clear sound out of the Firefly.\nOn the bright side now I know how to convert an I2S stream captured by a Saleae logic analyzer to wav file: https://github.com/roel0/PCM2Wav-py\nThe next step is to check how much work would it take to implement the simple-audio-card part. The (very hacky) WIP is at https://github.com/gonzoua/freebsd/commits/rk3399_audio\n","permalink":"https://kernelnomicon.org/posts/audio-for-rk3399/","summary":"\u003cp\u003eLast two weeks I\u0026rsquo;ve been working on audio support for Firefly-RK3399. Full support requires a number of things that are not quite there or not available in the mainline FreeBSD kernel. The main low-level hardware functionality consists of two parts: I2S block in the SoC and RT5640 audiocodec that converts digital audio to an analog signal. They talk to each other using the I2S protocol. A little bit higher is FDT virtual \u0026ldquo;devices\u0026rdquo; called simple-audio-card. This part is responsible for coordinating the setup of both hardware components: make sure they agree on a number of channels, a number of bits per sample and clock specifics of the I2S protocol. There is no code for it in the FreeBSD kernel, so I had to just hardcode these things in both hardware drivers.\u003c/p\u003e","title":"Audio for RK3399"},{"content":"(Not a FreeBSD topic)\nA 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 \u0026ldquo;No more secrets\u0026rdquo; scene using the only technologies I knew back then: Turbo Pascal running on MS-DOS. It wasn\u0026rsquo;t an exact replica but it was close enough and I was quite happy with the result. The program itself hasn\u0026rsquo;t survived my numerous moves from one apartment to another and got lost along with all the floppy discs sometime in the early aughts.\nRecently 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 \u0026lsquo;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:\nhttps://www.youtube.com/watch?v=_HK2CYF4gWo\n","permalink":"https://kernelnomicon.org/posts/recreating-sneakers-scene/","summary":"\u003cp\u003e(Not a FreeBSD topic)\u003c/p\u003e\n\u003cp\u003eA long time ago, in my teens, I watched movie \u003ca href=\"https://www.imdb.com/title/tt0105435/\"\u003eSneakers\u003c/a\u003e 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 \u003ca href=\"https://www.youtube.com/watch?v=F5bAa6gFvLs\"\u003e\u0026ldquo;No more secrets\u0026rdquo; scene\u003c/a\u003e using the only technologies I knew back then: Turbo Pascal running on MS-DOS. It wasn\u0026rsquo;t an exact replica but it was close enough and I was quite happy with the result. The program itself hasn\u0026rsquo;t survived my numerous moves from one apartment to another and got lost along with all the floppy discs sometime in the early aughts.\u003c/p\u003e","title":"Recreating Sneakers scene"},{"content":"After long hiatus (because $JOB) I\u0026rsquo;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\u0026rsquo;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.\nThe challenging part of the project was not U2F/HID but interfacing ioctl with Python, something I have never done before. It wasn\u0026rsquo;t super complex and I learned about Python\u0026rsquo;s ctype module.\nEven 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\u0026rsquo;t care about the actual signatures/keys:\nimport os from pyu2f import u2f from pyu2f import model ORIGIN = \u0026#39;https://kernelnomicon.org\u0026#39; APP_ID = \u0026#39;wordpress\u0026#39; REGISTRATION_DAT = \u0026#39;registration.dat\u0026#39; 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, \u0026#39;rb\u0026#39;) as f: rd = f.read() else: r = device.Register(APP_ID, b\u0026#39;ABCD\u0026#39;, []) rd = r.registration_data with open(REGISTRATION_DAT, \u0026#39;wb+\u0026#39;) 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\u0026#39;012345678\u0026#39;, [key]) print (response.signature_data) print (response.client_data) The final result is in my fork of pyu2f repo, on freebsd branch.\n","permalink":"https://kernelnomicon.org/posts/freebsd-support-for-pyu2f/","summary":"\u003cp\u003eAfter long hiatus (because $JOB) I\u0026rsquo;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\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003eThe challenging part of the project was not U2F/HID but interfacing ioctl with Python, something I have never done before. It wasn\u0026rsquo;t super complex and I learned about Python\u0026rsquo;s ctype module.\u003c/p\u003e","title":"FreeBSD support for pyu2f"},{"content":"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.\nThere is no datasheet or protocol description, so I used Pimoroni\u0026rsquo;s python library as a reference.\nTo 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.:\nfdt_overlays=\u0026quot;spigen-rpi3\u0026quot;\nI didn\u0026rsquo;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:\n","permalink":"https://kernelnomicon.org/posts/inky-phat-on-freebsdpi/","summary":"\u003cp\u003eAbout a month ago I purchased \u003ca href=\"https://shop.pimoroni.com/products/inky-phat\"\u003eInky pHat\u003c/a\u003e 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.\u003c/p\u003e","title":"Inky pHat on FreeBSD/Pi"},{"content":"I was updating my laptop to the latest HEAD today and noticed that my bash prompt looks ugly in default console color scheme. So what with one thing and another I ended up writing color themes support for vt(4). Just because it was fun thing to do. The idea is that you can redefine any ANSI color in console using variable in /boot/loader.conf, i.e.:\nkern.vt.color.0.rgb=\u0026#34;0,0,0\u0026#34; # color 0 is black # or kern.vt.color.15.rgb=\u0026#34;#ffffff\u0026#34; # color 15 is white Here is how my Tomorrow Night theme looks like:\nkern.vt.color.0.rgb=\u0026#34;#1d1f21\u0026#34; kern.vt.color.1.rgb=\u0026#34;#d77c79\u0026#34; kern.vt.color.2.rgb=\u0026#34;#c2c77b\u0026#34; kern.vt.color.3.rgb=\u0026#34;#f4cf87\u0026#34; kern.vt.color.4.rgb=\u0026#34;#93b2ca\u0026#34; kern.vt.color.5.rgb=\u0026#34;#c0a7c7\u0026#34; kern.vt.color.6.rgb=\u0026#34;#9ac9c4\u0026#34; kern.vt.color.7.rgb=\u0026#34;#d0d2d1\u0026#34; kern.vt.color.8.rgb=\u0026#34;#d0d2d1\u0026#34; kern.vt.color.9.rgb=\u0026#34;#d77c79\u0026#34; kern.vt.color.10.rgb=\u0026#34;#c2c77b\u0026#34; kern.vt.color.11.rgb=\u0026#34;#f4cf87\u0026#34; kern.vt.color.12.rgb=\u0026#34;#93b2ca\u0026#34; kern.vt.color.13.rgb=\u0026#34;#c0a7c7\u0026#34; kern.vt.color.14.rgb=\u0026#34;#9ac9c4\u0026#34; kern.vt.color.15.rgb=\u0026#34;#ffffff\u0026#34; It works only with framebuffer-based console like efifb or i915kms. Patch: console-color-theme.diff\n","permalink":"https://kernelnomicon.org/posts/color-themes-supportwhack-for-vt4/","summary":"\u003cp\u003eI was updating my laptop to the latest HEAD today and noticed that my bash prompt looks ugly in default console color scheme. So what with one thing and another I ended up writing color themes support for vt(4). Just because it was fun thing to do. The idea is that you can redefine any ANSI color in console using variable in /boot/loader.conf, i.e.:\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ekern.vt.color.0.rgb=\u0026#34;0,0,0\u0026#34; # color 0 is black\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e# or\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ekern.vt.color.15.rgb=\u0026#34;#ffffff\u0026#34; # color 15 is white\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eHere is how my Tomorrow Night theme looks like:\u003c/p\u003e","title":"Color themes support^Whack for vt(4)"},{"content":"Last year I got my hands on Minnowboard Turbot (courtesy of Frank H.) and spent some time working on communications protocols support for it. Below is short summary of what works and what doesn\u0026rsquo;t.\nMinnowboard Turbot is Atom-base SoC, and standard x86 part (HDMI, network, USB) FreeBSD just works on it. The board has expansion connector that exposes I2C, SPI, and GPIO pins and can be used to talk to peripheral devices. Short summary of header pins can be found on developer.microsoft.com.\nGPIO GPIO functionality on Minnowboard provided by bytgpio(4) driver (name was chosen to match OpenBSD one). There are three banks, but the most accessible is the third one available via /dev/gpioc2. All GPIO pins on the expansion header are pin number in this bank. So to set pin \u0026ldquo;GPIO 0\u0026rdquo; on the picture to HIGH you would use gpioc -f /dev/gpioc2 0 1.\nTo use some GPIO peripheral that has FreeBSD kernel driver you will have to describe it using hints in /boot/loader.conf. For instance there is LED D2 that is attached to pin 22. So to expose it through gpioled(4) interface you\u0026rsquo;d add following lines to /boot/loader.conf:\ngpioled_load=\u0026#34;YES\u0026#34; bytgpio_load=\u0026#34;YES\u0026#34; hint.gpioled.0.at=\u0026#34;gpiobus2\u0026#34; # pin 22: (1 \u0026lt;\u0026lt; 22) hint.gpioled.0.pins=\u0026#34;0x400000\u0026#34; hint.gpioled.0.name=\u0026#34;D2\u0026#34; SPI Driver for SPI support on Minnowboard is intelspi. Hardware supports all four SPI modes and clock frequency configuration but the driver doesn\u0026rsquo;t (yet). So it\u0026rsquo;s always mode 0 and frequency is hardcoded to 10MHz. To access it from userland you\u0026rsquo;d use spigen driver for now. As with gpio peripherlas, you\u0026rsquo;d have to add spigen via hints:\nintelspi_load=\u0026#34;YES\u0026#34; hint.spigen.0.at=\u0026#34;spibus0\u0026#34; There is no spigen module, so it has to be enabled in kernel config:\ndevice spibus device spigen I2C I2C driver is ig4(4). There are two I2C buses, the one that is accessible from expansion header is iicbus0. As with previous two protocols devices should be defined by hints. For example:\nig4_load=\u0026#34;YES\u0026#34; hint.ds3231.0.at=\u0026#34;iicbus0\u0026#34; # 0x68 in 8-bit format # for example only, hasn\u0026#39;t been tested hint.ds3231.0.addr=\u0026#34;0xd0\u0026#34; There is no ds3231 module so again, you need to enable it in kernel:\ndevice iicbus device ds3231 To use I2C from userland via /dev/iicN you\u0026rsquo;ll need to load iic(4) module.\n","permalink":"https://kernelnomicon.org/posts/minnowboard-turbot-gpio-i2c-and-spi/","summary":"\u003cp\u003eLast year I got my hands on Minnowboard Turbot (courtesy of Frank H.) and spent some time working on communications protocols support for it. Below is short summary of what works and what doesn\u0026rsquo;t.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://wiki.minnowboard.org/MinnowBoard_Turbot\"\u003eMinnowboard Turbot\u003c/a\u003e is Atom-base SoC, and standard x86 part (HDMI, network, USB) FreeBSD just works on it. The board has expansion connector that exposes I2C, SPI, and GPIO pins and can be used to talk to peripheral devices. Short summary of header pins can be found on \u003ca href=\"https://developer.microsoft.com/en-us/windows/iot/docs/pinmappingsmbm\"\u003edeveloper.microsoft.com\u003c/a\u003e.\u003c/p\u003e","title":"Minnowboard Turbot: GPIO, I2C, and SPI"},{"content":"Over years I accumulated fair number of devices I have no real use for. I ordered them either on impulse, or to add couple of $$$ to the bill to get free delivery. So in order to get at least some value from those purchases I put together goofy demo using two of such devices: I2C temperature sensor breakout from Sparkfun and 128x32 SPI OLED display from Adafruit.\nI wrote two libraries to talk to TMP102 (chip in which temp sensor is based) over I2C and to SSD1306(OLED display chip) over SPI and several demos simple enough to put together in one day but flashy enough to excite my inner child and bring fond memories of MSDOS days. The SPI chip requires this fix in kernel. Userland SPI API provides only very basic functionality but luckily it was enough to talk to SSD1306.\nTMP102 is I2C-only device but SSD1306 uses two signals in addition to standard SPI ones and GND/VCC: Data/Command switch and Reset. I connected them to GPIO pins 23 and 24 on my RPi. SSD1306 code is based on Adafruit\u0026rsquo;s Python library and supports only one model so far, but can easily be extended to support all three of them.\nCode: https://github.com/gonzoua/freebsd-embedded-demos Video:\nhttps://youtu.be/CRHSU83VVaY\n","permalink":"https://kernelnomicon.org/posts/accessing-i2c-and-spi-from-userland/","summary":"\u003cp\u003eOver years I accumulated fair number of devices I have no real use for. I ordered them either on impulse, or to add couple of $$$ to the bill to get free delivery. So in order to get at least some value from those purchases I put together goofy demo using two of such devices: \u003ca href=\"https://www.sparkfun.com/products/11931\"\u003eI2C temperature sensor breakout\u003c/a\u003e from Sparkfun and \u003ca href=\"https://www.adafruit.com/products/661\"\u003e128x32 SPI OLED display\u003c/a\u003e from Adafruit.\u003c/p\u003e\n\u003cp\u003eI wrote two libraries to talk to TMP102 (chip in which temp sensor is based) over I2C and to SSD1306(OLED display chip) over SPI and several demos simple enough to put together in one day but flashy enough to excite my inner child and bring fond memories of MSDOS days. The SPI chip requires \u003ca href=\"https://svnweb.freebsd.org/base?view=revision\u0026amp;revision=310170\"\u003ethis fix\u003c/a\u003e in kernel. Userland SPI API provides only very basic functionality but luckily it was enough to talk to SSD1306.\u003c/p\u003e","title":"Accessing I2C and SPI from userland"},{"content":"If you\u0026rsquo;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:\ninit_uart_clock=3000000 ","permalink":"https://kernelnomicon.org/posts/raspberry-pi-uart0-default-frequency/","summary":"\u003cp\u003eIf you\u0026rsquo;re trying to boot FreeBSD with latest RaspberryPi firmware - be aware that \u003ca href=\"https://github.com/raspberrypi/firmware/commit/d0bc6ce8e2ae7850959fed4edb0695f3cddfb96a\"\u003ethis commit\u003c/a\u003e 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:\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003einit_uart_clock=3000000\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e","title":"Raspberry Pi UART0 default frequency"},{"content":"If you\u0026rsquo;re trying to install half-sized mini-PCIe wifi card in Jetson TK1, be aware, that the board has rfkill feature that is enabled by default. rfkill is hardware or software controlled switch that enables/disables RF signal on the wifi card itself. In case of mini-PCIe it\u0026rsquo;s controlled by level on pin 20 of the card. On Jetson TK-1 that pin is connected to GPIO X.7 pin. So to enable wifi on the board you need to run something like:\ngpioctl -cN gpio_X.7 OUT gpioctl -N gpio_X.7 1 ","permalink":"https://kernelnomicon.org/posts/rfkill-on-jetson-tk1/","summary":"\u003cp\u003eIf you\u0026rsquo;re trying to install half-sized mini-PCIe wifi card in Jetson TK1, be aware, that the board has rfkill feature that is enabled by default. rfkill is hardware or software controlled switch that enables/disables RF signal on the wifi card itself. In case of mini-PCIe it\u0026rsquo;s controlled by level on pin 20 of the card. On Jetson TK-1 that pin is connected to GPIO X.7 pin. So to enable wifi on the board you need to run something like:\u003c/p\u003e","title":"rfkill on Jetson TK1"},{"content":"You can get source for current kernel FDT blob by running following command\nsysctl -b hw.fdt.dtb | dtc -I dtb -O dts Edit 27/10/2017: added -O option, looks like it\u0026rsquo;s required in newer dtc\n","permalink":"https://kernelnomicon.org/posts/debugging-tip-checking-kernel-dtb-from-userland/","summary":"\u003cp\u003eYou can get source for current kernel FDT blob by running following command\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003esysctl -b hw.fdt.dtb | dtc -I dtb -O dts\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eEdit 27/10/2017: added -O option, looks like it\u0026rsquo;s required in newer dtc\u003c/p\u003e","title":"Debugging tip: checking kernel DTB from userland"},{"content":"Update (11/29/2016): DTB overlay no longer required. PSCI monitor will patch in-memory DTB to add psci node. Commit\nShort version of how to get RPi3 with SMP support Build GENERIC arm64 kernel for your image, not GENERIC-UP Copy https://people.freebsd.org/~gonzo/arm/rpi3-smp/u-boot.bin and https://people.freebsd.org/~gonzo/arm/rpi3-smp/armstub8.bin to FAT partition on SD card. Copy https://people.freebsd.org/~gonzo/arm/rpi3-smp/psci.dtbo to overlays directory on FAT partition Edit config.txt: change value of device_tree_address and add psci overlay. These two lines should be there: device_tree_address=0x4000 Reboot device. It should boot with all four cores enabled and reboot should work too. Long version of what\u0026rsquo;s in those .bin/.dtbo files Boot sequence for PSCI monitor on RPi3 looks like this:\nentry point is called at EL3 monitor performs some CPU-specific initializations monitor sets up exceptions vector with SMC handler monitor reserves memory so it\u0026rsquo;s not going to be overwritten by next boot stage monitor drops to EL2, passes control to next boot stage First problem arises at step #1. If you generate binary and boot it using kernel parameter in config.txt by the time control is passed to entry point CPU is already at EL2. It\u0026rsquo;s because VideoCore firmware does not pass control directly to kernel but runs some built-in code prior to that which is called ARM stub. Good news - that built-in code can be overridden. The history behind ARM stubs can be found in this thread. And source code for default ARMv8 stub is in armstub8.S file. It can be overridden either by adding armstub=NNN.bin line to config.txt or by copying stub to armstub8.bin file on FAT partition, this file is loaded automatically if it\u0026rsquo;s present.\nDefault stub performs some initialization and runs following pseudocode on each CPU:\nvoid *spin_entry[4]; drop_to_el2(); if (current_cpu == 0) boot_kernel(); else { while (spin_entry[current_cpu] == 0) { wait_for_events(); } jump_to(spin_entry[current_cpu]); } It\u0026rsquo;s a good starting point so I added exception vector that jumps to PSCI handler routine, and PSCI entry points for PSCI_VERSION, CPU_ON, SYSTEM_REBOOT, SYSTEM_OFF, SYSTEM_RESET.\nSo far so good. Back to memory reservation. My initial idea was for PSCI to edit DTB blob. Either add one more memreserve block that starts at 0x0 and 16Kb long or edit /memory node and cut 16Kb from first reg pair. I ended up implementing both of these approaches and neither worked. Because on RPi3 boot sequence looks like: u-boot -\u0026gt; loader.efi -\u0026gt; kernel. All memory information is passed to kernel via EFI and this part of DTB is just ignored. And U-Boot does not care about FDT either. It gets available memory size by querying VideoCore directly using mailbox API and then initializes on DRAM bank: [0..dram_size].\nAfter short while of heavy thinking I ended up with just passing amount of reserved memory as the second argument of U-Boots entry function and then using that amount to start DRAM bank range with. Hackish but works.\nNow there is a matter of VideoCore-loaded FDT blob. Most of the FreeBSD images out there have device_tree_address=0x100 line in config.txt. This is reasonable value so FDT blob does not overlap with u-boot. Unfortunately new ARM stub with PSCI functionality is larger than 0x100 bytes and now overlaps with it. So device_tree_address has to be bumped to 0x4000. But U-Boot has 0x100 hardcoded as default so config.txt and u-boot now out of sync. On the other hand ARM stub (default and PSCI-enabled) does pass FDT blob address as the first argument to entry function. So u-boot can set value of fdt_addr_r to correct address dynamically.\nPSCI: check, U-Boot: check. There is one more missing part. FreeBSD kernel identifies presence of PSCI by checking for FDT node with \u0026ldquo;arm,psci-0.2\u0026rdquo; compatibility string. Obviously there is no such thing in original dtb file. PSCI monitor adds this node dynamically by patching DTB blob in-memory before passing control to U-Boot. It would be natural to make PSCI monitor patch FDT blob and add this new node but I wasn\u0026rsquo;t up to the task of implementing it in assembler. I took the low road and just created DTB overlay with psci node. That\u0026rsquo;s why psci.dtbo and \u0026ldquo;dtoverlay=psci\u0026rdquo; line in config.txt are required. I\u0026rsquo;m planning to add C files to PSCI monitor and implement dynamic DTB patching but for now overlay should do.\nSource code for all the stuff in this post: rpi3-psci-monitor and u-boot patches.\nPrecompiled bits: rpi3-smp\n","permalink":"https://kernelnomicon.org/posts/quest-for-smp-on-raspberry-pi-3-part-ii/","summary":"\u003cp\u003e\u003cstrong\u003eUpdate (11/29/2016): DTB overlay no longer required. PSCI monitor will patch in-memory DTB to add psci node. \u003ca href=\"https://github.com/gonzoua/rpi3-psci-monitor/commit/0d65e734e5d03f91bc10451c4f510f60e5b90bc5\"\u003eCommit\u003c/a\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003ch3 id=\"short-version-of-how-to-get-rpi3-with-smp-support\"\u003eShort version of how to get RPi3 with SMP support\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eBuild GENERIC arm64 kernel for your image, not GENERIC-UP\u003c/li\u003e\n\u003cli\u003eCopy \u003ca href=\"https://people.freebsd.org/~gonzo/arm/rpi3-smp/u-boot.bin\"\u003ehttps://people.freebsd.org/~gonzo/arm/rpi3-smp/u-boot.bin\u003c/a\u003e and \u003ca href=\"https://people.freebsd.org/~gonzo/arm/rpi3-smp/armstub8.bin\"\u003ehttps://people.freebsd.org/~gonzo/arm/rpi3-smp/armstub8.bin\u003c/a\u003e to FAT partition on SD card.\u003c/li\u003e\n\u003cli\u003eCopy \u003ca href=\"https://people.freebsd.org/~gonzo/arm/rpi3-smp/psci.dtbo\"\u003ehttps://people.freebsd.org/~gonzo/arm/rpi3-smp/psci.dtbo\u003c/a\u003e to \u003ccode\u003eoverlays\u003c/code\u003e directory on FAT partition\u003c/li\u003e\n\u003cli\u003eEdit config.txt: change value of device_tree_address and add psci overlay. These two lines should be there:\u003c/li\u003e\n\u003c/ul\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003edevice_tree_address=0x4000\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cul\u003e\n\u003cli\u003eReboot device. It should boot with all four cores enabled and reboot should work too.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"long-version-of-whats-in-those-bindtbo-files\"\u003eLong version of what\u0026rsquo;s in those .bin/.dtbo files\u003c/h3\u003e\n\u003cp\u003eBoot sequence for PSCI monitor on RPi3 looks like this:\u003c/p\u003e","title":"Quest for SMP on Raspberry Pi 3, part II"},{"content":"Getting SMP support for RPI3 took some time and was interesting learning experience. So I share bits of what I learned here.\nFreeBSD/arm boot start on one CPU (called primary) the rest of CPUs are \u0026ldquo;on hold\u0026rdquo;. At some point in boot sequence non-primary CPUs are forced to call mpentry() function. The way CPU is forced to call mpentry is platform-dependent. RPi2 for instance passes mpentry and argument to VideoCore using mailbox interface and then VideoCore kicks ARM CPU in action. So most of SoC has their own implementation of platform_mp_start_ap platform API method.\nFreeBSD/arm64 takes more standardized approach. It relies on secure monitor to provide this functionality. To explain what secure monitor is I need to diverge a bit into Aarch64 architecture. Aarch64 has four Exception Levels: EL3, EL2, EL1, EL0. Higher level acts as a \u0026ldquo;kernel\u0026rdquo; to the lower level. Most usual roles for exception levels are:\nEL3 - Secure Monitor EL2 - Hypervisor EL1 - OS kernel EL0 - userland apps\nJust like userland can request kernel service through syscal lower exception level can request service from higher one through syscall-like mechanism. On Aarch64 it\u0026rsquo;s SMC, HVC, SVC instruction to get to EL3, EL2, EL1 respectively. There are multiple services that EL1 can request from Hypervisor or Secure Monitor but one of them is PSCI (Power State Coordination Interface). It\u0026rsquo;s an API to control CPUs and power states of the system. Full spec can be found here.\nSMP support on FreeBSD/arm64 requires Secure Monitor and there is no such thing for Raspberry Pi 3. Normally it\u0026rsquo;s a piece of software that is provided as a part of SoC. Stage 1 boot loader resides in secure ROM and every subsequent boot stage can be verified using certificates. There are regions of memory where secure monitor is loaded that can not be accessed from non-secure exception levels. No such thing on RPi3 either.\nThere were 3 options to get PSCI on RPi3: write \u0026ldquo;bare metal\u0026rdquo; implementation from the scratch, add it to U-Boot or port existing open source secure monitor to RPi3. Since U-Boot was already a part of the setup I looked up if there was PSCI support for it. There was for ARMv7 in the mainline and for AMRv8 as a patchset with generic PSCI framework and implementation for one of the platforms. Framework relied on the existence of secure memory region which is not a thing on RPi3 so I went for another option: port existing monitor.\nReference implementation of SM is ARM Trusted Firmware. It\u0026rsquo;s very well documented and easily extendable but the problem was that just like with U-Boot it made assumptions about memory layout that were not true for RPi3 and were not easy to change in the ATF code.\nAt this point bare metal PSCI emulation looked like less work than the other two options and I started experimenting with really low level stuff. I will write my progress up in the next blog post.\n","permalink":"https://kernelnomicon.org/posts/quest-for-smp-on-raspberry-pi-3/","summary":"\u003cp\u003eGetting SMP support for RPI3 took some time and was interesting learning experience. So I share bits of what I learned here.\u003c/p\u003e\n\u003cp\u003eFreeBSD/arm boot start on one CPU (called primary) the rest of CPUs are \u0026ldquo;on hold\u0026rdquo;. At some point in boot sequence non-primary CPUs are forced to call mpentry() function. The way CPU is forced to call mpentry is platform-dependent. RPi2 for instance passes mpentry and argument to VideoCore using mailbox interface and then VideoCore kicks ARM CPU in action. So most of SoC has their own implementation of platform_mp_start_ap platform API method.\u003c/p\u003e","title":"Quest for SMP on Raspberry Pi 3"},{"content":"I\u0026rsquo;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.\n","permalink":"https://kernelnomicon.org/posts/mfc-tracking-tool-filters/","summary":"\u003cp\u003eI\u0026rsquo;ve just added extended filters to \u003ca href=\"http://mfc.kernelnomicon.org\"\u003ehttp://mfc.kernelnomicon.org\u003c/a\u003e. Now filter can be either committer, or path, or both. Path is indicated by adding @ character to the beginning, so \u003ccode\u003egonzo\u003c/code\u003e means all commits by gonzo, \u003ccode\u003e@sys/arm\u003c/code\u003e means all commits to sys/arm directory, and \u003ccode\u003egonzo@sys/arm\u003c/code\u003e 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: \u003ccode\u003e@sys/arm  @boot/efi\u003c/code\u003e means all commits to sys/arm plus all commits to boot/efi directory.\u003c/p\u003e","title":"MFC tracking tool filters"},{"content":"raspberrypi-userland git repo was synced to the latest upstream code base: https://github.com/gonzoua/userland/tree/freebsd\n","permalink":"https://kernelnomicon.org/posts/raspberry-pi-userland-update/","summary":"\u003cp\u003eraspberrypi-userland git repo was synced to the latest upstream code base: \u003ca href=\"https://github.com/gonzoua/userland/tree/freebsd\"\u003ehttps://github.com/gonzoua/userland/tree/freebsd\u003c/a\u003e\u003c/p\u003e","title":"Raspberry Pi userland repo update"},{"content":"Next week I plan to do bunch of MFCs for ARM and evdev stuff and to make it less of an ordeal I made this tool to track what\u0026rsquo;s merged and what\u0026rsquo;s not: mfc.kernelnomicon.org. It provides basic functionality I thought I would need for this process:\nNavigator for HEAD commits with visual representation of MFC state: \u0026ldquo;no mfc scheduled\u0026rdquo;, \u0026ldquo;ready for mfc\u0026rdquo;, \u0026ldquo;waiting for \u0026lsquo;mfc after\u0026rsquo; date\u0026rdquo;, \u0026ldquo;merged\u0026rdquo; Basic filtering: by author name, by two states: \u0026ldquo;waiting\u0026rdquo;, and \u0026ldquo;ready\u0026rdquo; \u0026ldquo;MFC basket\u0026rdquo; - manage set of commits I would like to merge back in one go Generate svn command and change log for selected \u0026ldquo;MFC basket\u0026rdquo; Stack used: Django + Bootstrap3 + jQuery\nGitHub project: mfctracker\n","permalink":"https://kernelnomicon.org/posts/mfc-tracking-web-tool/","summary":"\u003cp\u003eNext week I plan to do bunch of MFCs for ARM and evdev stuff and to make it less of an ordeal I made this tool to track what\u0026rsquo;s merged and what\u0026rsquo;s not: \u003ca href=\"http://mfc.kernelnomicon.org\"\u003emfc.kernelnomicon.org\u003c/a\u003e. It provides basic functionality I thought I would need for this process:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eNavigator for HEAD commits with visual representation of MFC state: \u0026ldquo;no mfc scheduled\u0026rdquo;, \u0026ldquo;ready for mfc\u0026rdquo;, \u0026ldquo;waiting for \u0026lsquo;mfc after\u0026rsquo; date\u0026rdquo;, \u0026ldquo;merged\u0026rdquo;\u003c/li\u003e\n\u003cli\u003eBasic filtering: by author name, by two states: \u0026ldquo;waiting\u0026rdquo;, and \u0026ldquo;ready\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u0026ldquo;MFC basket\u0026rdquo; - manage set of commits I would like to merge back in one go\u003c/li\u003e\n\u003cli\u003eGenerate svn command and change log for selected \u0026ldquo;MFC basket\u0026rdquo;\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eStack used: Django + Bootstrap3 + jQuery\u003c/p\u003e","title":"MFC tracking web-tool"},{"content":"Raspberry Pi 3 limited support was committed to HEAD. Most of drivers should work with upstream dtb, RNG requires attention because callout mode seems to be broken and there is no IRQ in upstream device tree file. SMP is work in progress. There are some compatibility issue with VCHIQ driver due to some assumptions that are true only for ARM platform.\nSD card layout is the same as for RPi and RPi2 but boot chain is different. All ARM64 supported by FreeBSD up to now used EFI as boot environment. RPi 3 has only VC firmware and whatever it can spin off, e.g. u-boot. So it seemed easier to enable EFI API in U-Boot instead of porting ubldr to arm64. There were some hiccups with netbooting, (see patch) but otherwise it was OK. U-Boot port and crochet config for Pi 3 should be committed \u0026ldquo;real soon\u0026rdquo;(tm).\nFor those who would like to try it ASAP Shawn Webb put together instruction on how to get bootable SD image.\n","permalink":"https://kernelnomicon.org/posts/raspberry-pi-support-in-head/","summary":"\u003cp\u003eRaspberry Pi 3 limited support was committed to HEAD. Most of drivers should work with upstream dtb, RNG requires attention because callout mode seems to be broken and there is no IRQ in upstream device tree file. SMP is work in progress. There are some compatibility issue with VCHIQ driver due to some assumptions that are true only for ARM platform.\u003c/p\u003e\n\u003cp\u003eSD card layout is the same as for RPi and RPi2 but boot chain is different. All ARM64 supported by FreeBSD up to now used EFI as boot environment. RPi 3 has only VC firmware and whatever it can spin off, e.g. u-boot. So it seemed easier to enable EFI API in U-Boot instead of porting ubldr to arm64. There were some hiccups with netbooting, (see \u003ca href=\"https://people.freebsd.org/~gonzo/arm/patches/u-boot-rpi3-uefi-netboot.diff\"\u003epatch\u003c/a\u003e) but otherwise it was OK. U-Boot port and crochet config for Pi 3 should be committed \u0026ldquo;real soon\u0026rdquo;(tm).\u003c/p\u003e","title":"Raspberry Pi support in HEAD"},{"content":"Short summary of couple of frustrating hours I spent trying to get my RPi3 netbooting:\nU-Boot - 2016.09 raspberrypi/firmware/boot - ec63df146f454e8cab7080380f9138246d877013\narmstub.bin, armstub7.bin, armstub8.bin - NOT REQUIRED. There are tens of google results mentioning these files along with some dd magic - they all obsolete. Aforementioned version of firmware does not require them. 64-bit mode is controlled by arm_control variable in config.txt (see below). If 64-bit mode requested default kernel name becomes kernel8.img, and kernel load address becomes 0x80000. U-Boot uses correct default load address so no need for any additional parameters or hacks.\nBuilding u-boot:\n# gmake ARCH=arm CROSS_COMPILE=aarch64-none-elf- CONFIG_EFI=y rpi_3_defconfig # gmake ARCH=arm CROSS_COMPILE=aarch64-none-elf- CONFIG_EFI=y Boot partition:\nCopy all files/dirs from firmware/boot to your FAT partition (let\u0026rsquo;s say it\u0026rsquo;s mounted at /mnt/fat) Copy u-boot.bin to kernel8.img on your FAT partition Create config.txt with following content: arm_control=0x200 enable_uart=1 If you want to keep u-boot.bin name and not use kernel8.img, add following ling:\nkernel=u-boot.bin Unmount and boot RPi3. You should see U-Boot output on both serial console and HDMI.\nDefault U-Boot build uses mini-uart. So if for some reason you want to use PL011 instead, patch include/configs/rpi.h and make sure that CONFIG_BCM283X_MU_SERIAL is not defined and CONFIG_PL01X_SERIAL is defined instead.\nconfig.txt in this case should look like:\narm_control=0x200 dtoverlay=pi3-disable-bt ","permalink":"https://kernelnomicon.org/posts/64-bit-u-boot-on-raspberry-pi-3/","summary":"\u003cp\u003eShort summary of couple of frustrating hours I spent trying to get my RPi3 netbooting:\u003c/p\u003e\n\u003cp\u003eU-Boot - 2016.09\n\u003ca href=\"https://github.com/raspberrypi/firmware/boot\"\u003eraspberrypi/firmware/boot\u003c/a\u003e - ec63df146f454e8cab7080380f9138246d877013\u003c/p\u003e\n\u003cp\u003earmstub.bin, armstub7.bin, armstub8.bin - NOT REQUIRED. There are tens of google results mentioning these files along with some dd magic - they all obsolete. Aforementioned version of firmware does not require them. 64-bit mode is controlled by arm_control variable in config.txt (see below). If  64-bit mode requested default kernel name becomes kernel8.img, and kernel load address becomes 0x80000. U-Boot uses correct default load address so no need for any additional parameters or hacks.\u003c/p\u003e","title":"64-bit U-Boot on Raspberry Pi 3"},{"content":"Few weeks ago evdev support was finally committed to HEAD. Project started a part of SoC 2014 by Jakub Klama and then picked up, finished and submitted by Vladimir Kondratiev. It\u0026rsquo;s drop-in compatible with Linux API which means all you need to do is add #ifdef _FreeBSD around respective includes and existing code (if it\u0026rsquo;s otherwise cross-compatible with FreeBSD) should just work. Which is the case for Qt and to lesser extent for tslib. Hardware support is still moving target, FreeBSD has evdev-compatible drivers for USB keyboards, USB mice, TI\u0026rsquo;s AM33xx touchscreen controller and Raspberry Pi\u0026rsquo;s official touchscreen. Only the latter device supports multitouch and Vladimir submitted patch required to get it working. To my knowledge it\u0026rsquo;s the first multitouch touchscreen ever working on FreeBSD so I decided to record demo to save this moment for generations to come. Well, not really. Mostly to brag and to let people know that it\u0026rsquo;s possible and encourage them to make stuff and experiment with FreeBSD, ARM, and Qt.\nDemo below is standard imagegestures example built using latest dev branch of Qt.\nhttps://youtu.be/-XQk_SiaFnw\n","permalink":"https://kernelnomicon.org/posts/multitouch-support-on-ft5406/","summary":"\u003cp\u003eFew weeks ago evdev support was finally committed to HEAD. Project \u003ca href=\"https://wiki.freebsd.org/SummerOfCode2014/evdev_Touchscreens\"\u003estarted\u003c/a\u003e a part of SoC 2014 by Jakub Klama and then picked up, finished and submitted by Vladimir Kondratiev. It\u0026rsquo;s drop-in compatible with Linux API which means all you need to do is add #ifdef _\u003cem\u003eFreeBSD\u003c/em\u003e around respective includes and existing code (if it\u0026rsquo;s otherwise cross-compatible with FreeBSD) should just work. Which is the case for \u003ca href=\"https://codereview.qt-project.org/#/c/172829/\"\u003eQt\u003c/a\u003e and to lesser extent for \u003ca href=\"https://github.com/kergoth/tslib/pull/42\"\u003etslib\u003c/a\u003e. Hardware support is still moving target, FreeBSD has evdev-compatible drivers for USB keyboards, USB mice, TI\u0026rsquo;s AM33xx touchscreen controller and Raspberry Pi\u0026rsquo;s official touchscreen. Only the latter device supports multitouch and Vladimir submitted patch required to get it working. To my knowledge it\u0026rsquo;s the first multitouch touchscreen ever working on FreeBSD so I decided to record demo to save this moment for generations to come. Well, not really. Mostly to brag and to let people know that it\u0026rsquo;s possible and encourage them to make stuff and experiment with FreeBSD, ARM, and Qt.\u003c/p\u003e","title":"Multitouch support on FT5406"},{"content":"Dear Future Me,\nI guess you came here googling for \u0026ldquo;FreeBSD PXE UEFI\u0026rdquo; trying to find out how to netboot your x86 dev box. Or arm64 box. Who knows what you\u0026rsquo;re hacking on in the future. To do that you need follow these simple steps:\nPut loader.efi to tftpboot dir Configure dhcpd along these lines: host amd64 { hardware ethernet b8:ae:ed:77:88:99; filename \u0026#34;loader.efi\u0026#34;; option root-path \u0026#34;/src/FreeBSD/tftproot/amd64\u0026#34;; 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=\u0026#34;YES\u0026#34; That\u0026rsquo;s pretty much it.\nTake care\n","permalink":"https://kernelnomicon.org/posts/netbooting-freebsd-with-pxeuefi/","summary":"\u003cp\u003eDear Future Me,\u003c/p\u003e\n\u003cp\u003eI guess you came here googling for \u0026ldquo;FreeBSD PXE UEFI\u0026rdquo; trying to find out how to netboot your x86 dev box. Or arm64 box. Who knows what you\u0026rsquo;re hacking on in the future. To do that you need follow these simple steps:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePut loader.efi to tftpboot dir\u003c/li\u003e\n\u003cli\u003eConfigure dhcpd along these lines:\u003c/li\u003e\n\u003c/ul\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-gdscript3\" data-lang=\"gdscript3\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ehost amd64 {\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        hardware ethernet  b8:ae:ed:\u003cspan style=\"color:#ae81ff\"\u003e77\u003c/span\u003e:\u003cspan style=\"color:#ae81ff\"\u003e88\u003c/span\u003e:\u003cspan style=\"color:#ae81ff\"\u003e99\u003c/span\u003e;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        filename \u003cspan style=\"color:#e6db74\"\u003e\u0026#34;loader.efi\u0026#34;\u003c/span\u003e;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        option root\u003cspan style=\"color:#f92672\"\u003e-\u003c/span\u003epath \u003cspan style=\"color:#e6db74\"\u003e\u0026#34;/src/FreeBSD/tftproot/amd64\u0026#34;\u003c/span\u003e;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        fixed\u003cspan style=\"color:#f92672\"\u003e-\u003c/span\u003eaddress \u003cspan style=\"color:#ae81ff\"\u003e192.168\u003c/span\u003e\u003cspan style=\"color:#f92672\"\u003e.\u003c/span\u003e\u003cspan style=\"color:#ae81ff\"\u003e10.102\u003c/span\u003e;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        option routers \u003cspan style=\"color:#ae81ff\"\u003e192.168\u003c/span\u003e\u003cspan style=\"color:#f92672\"\u003e.\u003c/span\u003e\u003cspan style=\"color:#ae81ff\"\u003e10.1\u003c/span\u003e;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e}\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cul\u003e\n\u003cli\u003eMake sure root-path is in /etc/exports.\u003c/li\u003e\n\u003cli\u003eIf you use MINIMAL-derived config add your NIC driver to /boot/loader.conf:\u003c/li\u003e\n\u003c/ul\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-gdscript3\" data-lang=\"gdscript3\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eif_re_load\u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e\u003cspan style=\"color:#e6db74\"\u003e\u0026#34;YES\u0026#34;\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eThat\u0026rsquo;s pretty much it.\u003c/p\u003e","title":"Netbooting FreeBSD with PXE/UEFI"},{"content":"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 \u0026ldquo;real computer\u0026rdquo; - 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\u0026rsquo;t think much of it and happily typed dd if=/dev/zero of=/dev/mmcsd0 bs=128m. Well\u0026hellip; 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:\nDefault eMMC partition looks like this:\nTegra124 (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 \u0026#34;APP\u0026#34; attrs: 0x0001000000000001 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 7369c667-ff51-ec4a-29cd-baabf2fbe346 2 0x01c17000 0x01c18fff \u0026#34;DTB\u0026#34; attrs: 0x0002000000000001 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: f854c27c-e81b-8de7-765a-2e63339fc99a 3 0x01c19000 0x01c38fff \u0026#34;EFI\u0026#34; attrs: 0x0003000000000001 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: b70d3266-5831-5aa3-255d-051758e95ed4 4 0x01c39000 0x01c3afff \u0026#34;USP\u0026#34; attrs: 0x0004000000000001 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: c6cdb2ab-b49b-1154-0e82-7441213ddc87 5 0x01c3b000 0x01c3cfff \u0026#34;TP1\u0026#34; attrs: 0x0005000000000001 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: a13ee970-e141-67fc-3e01-7e97eadc6b96 6 0x01c3d000 0x01c3efff \u0026#34;TP2\u0026#34; attrs: 0x0006000000000001 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 2a5c388f-b0ec-fb3b-32af-3c54ec18db5c 7 0x01c3f000 0x01c40fff \u0026#34;TP3\u0026#34; attrs: 0x0007000000000001 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 43fe1a02-fafb-3aaa-fb29-d1e6053c7c94 8 0x01c41000 0x01c41fff \u0026#34;WB0\u0026#34; attrs: 0x0008000000000001 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 61bed875-f989-bb5c-a899-0f95b1ebf1b3 9 0x01c42000 0x01d58fff \u0026#34;UDA\u0026#34; 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 \u0026ldquo;Temporary Placeholder\u0026rdquo; 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\u0026rsquo;s place ubldr to TP1:\n# newfs_msdos /dev/gpt/TP1 # mount_msdosfs /dev/gpt/TP1 /mnt # cp ubldr.tk1 /mnt/ # umount /mnt Then populate rootfs:\n# newfs /dev/gpt/APP # mount /dev/gpt/APP /mnt Then build/install stuff: \u0026hellip; buildworld, buildkernel. installworld, distribution and installkernel with DESTDIR=/mnt \u0026hellip;\nCreate /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.\n/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:\nTegra124 (Jetson TK1) # setenv bootcmd \u0026#39;fatload mmc 0:5 $loadaddr ubldr.tk1; bootelf\u0026#39; Tegra124 (Jetson TK1) # saveenv Saving Environment to MMC... Writing to MMC(0)... done Tegra124 (Jetson TK1) # boot That\u0026rsquo;s it. Also if I need to revert back to netbooting TK1 I can just set loaderdev to \u0026ldquo;net\u0026rdquo; in u-boot:\nTegra124 (Jetson TK1) # setenv loaderdev net; boot ","permalink":"https://kernelnomicon.org/posts/untethering-jetson-tk1/","summary":"\u003cp\u003eNormally 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 \u0026ldquo;real computer\u0026rdquo; - 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\u0026rsquo;t think much of it and happily typed dd if=/dev/zero of=/dev/mmcsd0 bs=128m. Well\u0026hellip; 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:\u003c/p\u003e","title":"Untethering Jetson-TK1"},{"content":"I spent Labor Day weekend laboring on VBox shared folders support for FreeBSD. It\u0026rsquo;s been some time since I worked on it last time so I had to refresh my memory first. Things have moved on since then - VBox in ports was updated to version 5, but fortunately Li-Wen synced up freebsd-vboxfs repo to the latest version. After three days of laid-back hacking I am glad to announce that following VOPs are kind of implemented (in no particular order): lookup, access, readdir, read, getattr, readlink, remove, rmdir, symlink, close, create, open, write. \u0026ldquo;Kind of implemented\u0026rdquo; means that I was able to mount directory, traverse it, read file, calculate md5 sums and compare with host\u0026rsquo;s md5sum, create/remove directories, unzip zip file, etc but I doubt it would survive stress-test. Locking is all wrong at the moment and read/write VOPs allocate buffers for every operation.\nI hit a roadblock with rename VOP: it involves some non-trivial locking logic and also there is a problem with cached paths. VBox hypervisor operates on full paths so we cache them in vboxfs nodes, but if one of parent directories is renamed, all cached names should be modified accordingly. I am going to tackle these two problems once I have long enough stretch of time time sit and concentrate on task.\n","permalink":"https://kernelnomicon.org/posts/virtualbox-shared-folders-progress-report/","summary":"\u003cp\u003eI spent Labor Day weekend laboring on VBox shared folders support for FreeBSD. It\u0026rsquo;s been some time since I worked on it last time so I had to refresh my memory first. Things have moved on since then - VBox in ports was updated to version 5, but fortunately Li-Wen synced up \u003ca href=\"https://github.com/lwhsu/freebsd-vboxfs\"\u003efreebsd-vboxfs\u003c/a\u003e repo to the latest version. After three days of laid-back hacking I am glad to announce that following VOPs are kind of implemented (in no particular order): lookup, access, readdir, read, getattr, readlink, remove, rmdir, symlink, close, create, open, write. \u0026ldquo;Kind of implemented\u0026rdquo; means that I was able to mount directory, traverse it, read file, calculate md5 sums and compare with host\u0026rsquo;s md5sum, create/remove directories, unzip zip file, etc but I doubt it would survive stress-test. Locking is all wrong at the moment and read/write VOPs allocate buffers for every operation.\u003c/p\u003e","title":"VirtualBox Shared Folders: progress report"},{"content":"Looks like my attempt to cheap out on SSD for TK1 has backfired. I went for the cheapest SSD available in local store (Toshiba Q300) but when I tried to checkout FreeBSD sources to the drive I got bunch of WRITE_FPDMA_QUEUED timeouts and system locked up. The same thing happened when I tried to perform checkout on Linux. The drive itself was OK, it survived \u0026ldquo;svn co \u0026hellip;/head\u0026rdquo; and dd when connected using USB-to-SATA adapter.\nI believe the problem was that TK1 SATA voltage was out of Toshiba\u0026rsquo;s tolerance range. I replaced Q300 with Samsung EVO 850 and was able to checkout sources and finish buildworld using SSD for src/obj storage.\n","permalink":"https://kernelnomicon.org/posts/jetson-tk1-freebsd-and-ssd/","summary":"\u003cp\u003eLooks like my attempt to cheap out on SSD for TK1 has backfired. I went for the cheapest SSD available in local store (Toshiba Q300) but when I tried to checkout FreeBSD sources to the drive I got bunch of WRITE_FPDMA_QUEUED timeouts and system locked up. The same thing happened when I tried to perform checkout on Linux. The drive itself was OK, it survived \u0026ldquo;svn co \u0026hellip;/head\u0026rdquo; and dd when connected using USB-to-SATA adapter.\u003c/p\u003e","title":"Jetson TK1, FreeBSD, and SSD"},{"content":"I finally got around to BSDify my Jetson TK1. Here is short summary of what is involved. And to save you some scrolling here are artifacts obtained from whole ordeal: https://people.freebsd.org/~gonzo/arm/jetson-tk1/\nU-Boot First of all - my TK1 didn\u0026rsquo;t have U-Boot. Type of bootloader depends on the version of Linux4Tegra TK1 comes with. Mine had L4T R19, with some kind of \u0026ldquo;not u-boot\u0026rdquo; bootloader. My first attempt was to use tegrarcm tool, it uses libusb, so it\u0026rsquo;s possible to build it on FreeBSD with some elbow grease, but once I tried to run it - it gave me cryptic errors and USB is not my strong skill so I took low road and installed Ubuntu VM. For what is\u0026rsquo;s worth I got the same kind of error on Ubuntu.\nNext step was to use official update procedure described in http://developer.download.nvidia.com/embedded/L4T/r21_Release_v4.0/l4t_quick_start_guide.txt. Since I wasn\u0026rsquo;t going to boot Linux on the board I didn\u0026rsquo;t need sample rootfs. So the whole procedure was:\nGo to L4T R21.4 page Download Tegra124_Linux_R21.4.0_armhf.tbz2 Unpack it Connect microUSB port on device to Linux VM Get device into recover mode: power cycle, press and hold recovery button, press and release power button, release recovery button Run ./flash.sh jetson-tk1 mmcblk0p1, this should rewrite eMMC flash on the board and after reboot you will get u-boot prompt on serial console FreeBSD At this point you can boot FreeBSD on TK1. I use netboot for most of my device so in this case it was: build and deploy world to /src/FreeBSD/tftproot/tk1, build and install kernel to the same directory, copy /src/FreeBSD/tftproot/tk1/boot/kernel/kernel to kernel.TK1 in tftproot directory, add entry do DHCP config and restart DHCP server. Entry looks like this:\nhost tk1 { hardware ethernet 00:04:4b:49:08:9e; fixed-address 192.168.10.98; filename \u0026#34;kernel.TK1\u0026#34;; option root-path \u0026#34;/src/FreeBSD/tftproot/tk1\u0026#34;; option root-opts \u0026#34;nolockd\u0026#34;; option routers 192.168.10.1; } And also you need to add this to sys/arm/conf/JETSON-TK1 before building kernel:\noptions BOOTP options BOOTP_NFSROOT options BOOTP_COMPAT options BOOTP_NFSV3 On the device you just run \u0026ldquo;dhcp; bootelf\u0026rdquo; and voila - it just works.\nubldr Next step was to get ubldr running. I prefer suing ubldr because it gives more control over boot process accessible from booted FreeBSD system. ubldr requires U-Boot with API support, so I had to rebuild U-Boot from sources provided by nvidia with added #define CONFIG_API and all standard patches from sysutils/u-boot-* ports. Build procedure is standard:\nexport ARCH=arm export CROSS_COMPILE=arm-linux-gnueabihf- make jetson-tk1_config make It will generate multiple files, u-boot-dtb-tegra.bin is the one you want.\nTo reflash board with non-standard u-boot run ./flash.sh -L /path/to/u-boot-dtb-tegra.bin jetson-tk1 mmcblk0p1\nBack to ubldr. It was easy to build and load it. Build script:\n#!/bin/sh export TARGET=arm export TARGET_ARCH=armv6 export SRCROOT=/src/FreeBSD/wip export MAKEOBJDIRPREFIX=/src/FreeBSD/obj export MAKESYSPATH=$SRCROOT/share/mk set -x set -e buildenv=`make -C $SRCROOT TARGET_ARCH=armv6 buildenvvars` eval $buildenv make -C $SRCROOT/sys/boot -m $MAKESYSPATH obj eval $buildenv make -C $SRCROOT/sys/boot -m $MAKESYSPATH clean eval $buildenv make -C $SRCROOT/sys/boot -m $MAKESYSPATH UBLDR_LOADADDR=0x80600000 all sudo cp /src/FreeBSD/obj/arm.armv6/src/FreeBSD/wip/sys/boot/arm/uboot/ubldr /src/FreeBSD/tftpboot/ubldr.TK1 Obviously, kernel.TK1 in DHCP config needs to be replaced with ubldr.TK1. 0x80600000 is some value I came up with by looking at u-boot default environment. Something not high enough to overlap with kernel and not low enough to overlap with u-boot.\nAnd that\u0026rsquo;s where thing got hairy. To load ubldr and then netboot kernel, you need to set u-boot env loaderdev variable first: setenv loaderdev net; saveenv. And then do the same thing as above: dhcp; bootelf. Unfortunately I got this:\n## Starting application at 0x81000098 ... Consoles: U-Boot console Compatible U-Boot API signature found @0xffa3e410 FreeBSD/armv6 U-Boot loader, Revision 1.2 (gonzo@eb3.bluezbox.com, Mon Jun 27 19:59:22 PDT 2016) DRAM: 2048MB MMC: no card present MMC Device 2 not found MMC Device 3 not found MMC: no card present MMC: no card present MMC: no card present MMC: no card present MMC: no card present MMC: no card present MMC Device 2 not found Number of U-Boot devices: 3 U-Boot env: loaderdev=\u0026#39;net\u0026#39; Found U-Boot device: disk Found U-Boot device: net Booting from net0: panic: arp: no response for 192.168.10.1 --\u0026gt; Press a key on the console to reboot \u0026lt;-- Rebooting... resetting ... After some heavy thinking and code digging problem was narrowed down to u-boot network driver drivers/net/rtl8169.c. Instead of returning 0 on success and negative value on error it returns number of bytes sent on success and zero on error. Which confused ubldr into thinking nothing is sent, so recv part of exchange was never invoked. After fixing this issue kernel was loaded just fine but hang right afert\nUsing DTB compiled into kernel. Kernel entry at 0x0x80800100... Kernel args: (null) Logn story short - it was caused by enabled D-Cache so I had to add\n#ifndef CONFIG_SPL_BUILD #define CONFIG_SYS_DCACHE_OFF #define CONFIG_CMD_CACHE #endif to u-boot config and go through rebuild/reflash cycle again. After this whole boot chain went through right to login prompt.\nMy next goal is to make TK1 self-contained box: get base system installed on eMMC and use attached SSD as scratch disk for swap and builds.\n","permalink":"https://kernelnomicon.org/posts/freebsd-on-jetson-tk1/","summary":"\u003cp\u003eI finally got around to BSDify my Jetson TK1. Here is short summary of what is involved. And to save you some scrolling here are artifacts obtained from whole ordeal: \u003ca href=\"https://people.freebsd.org/~gonzo/arm/jetson-tk1/\"\u003ehttps://people.freebsd.org/~gonzo/arm/jetson-tk1/\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/uploads/2016/06/IMG_2064-e1467143789207.jpg\"\u003e\u003cimg alt=\"Jetson TK1\" loading=\"lazy\" src=\"/uploads/2016/06/IMG_2064-e1467143789207-768x1024.jpg\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"u-boot\"\u003eU-Boot\u003c/h2\u003e\n\u003cp\u003eFirst of all - my TK1 didn\u0026rsquo;t have U-Boot. Type of bootloader depends on the version of Linux4Tegra TK1 comes with. Mine had L4T R19, with some kind of \u0026ldquo;not u-boot\u0026rdquo; bootloader. My first attempt was to use tegrarcm tool, it uses libusb, so it\u0026rsquo;s possible to build it on FreeBSD with some elbow grease, but once I tried to run it - it gave me cryptic errors and USB is not my strong skill so I took low road and installed Ubuntu VM. For what is\u0026rsquo;s worth I got the same kind of error on Ubuntu.\u003c/p\u003e","title":"FreeBSD on Jetson TK1"},{"content":"Few weeks back Ralf Nolden, who is *BSD champion in Qt community, urged me to clean-up and submit my Qt5-related projects to upstream and scfb platform plugin was picked as a test dummy. It took 12 iterations to get things right, along the way plugin was renamed to bsdfb, but eventually patch has been merged.\nNext two candidates are bsdkeyboard and bsdsysmouse input plugins.\n","permalink":"https://kernelnomicon.org/posts/bsdfb-platform-plugin-merged-to-qt-dev-branch/","summary":"\u003cp\u003eFew weeks back Ralf Nolden, who is *BSD champion in Qt community, urged me to clean-up and submit my Qt5-related projects to upstream and \u003ca href=\"https://github.com/gonzoua/qt-platform-scfb\"\u003escfb platform plugin\u003c/a\u003e was picked as a test dummy. It took  \u003ca href=\"https://codereview.qt-project.org/#/c/159316/\"\u003e12 iterations\u003c/a\u003e to get things right, along the way plugin was renamed to bsdfb, but eventually patch has been \u003ca href=\"https://github.com/qtproject/qtbase/commit/1542d8881fc5ccbc5918cd4acbe4091ebbd24508\"\u003emerged\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eNext two candidates are \u003ca href=\"https://github.com/gonzoua/qt5-bsd-input\"\u003ebsdkeyboard and bsdsysmouse input plugins\u003c/a\u003e.\u003c/p\u003e","title":"bsdfb platform plugin merged to Qt dev branch"},{"content":"Two months ago I tried to setup dev environment using FreeBSD Vagrant box just to find out that FreeBSD does not support VirtualBox shared folders. After some googling I found Li-Wen Hsu\u0026rsquo;s github repository with some work in this area. Li-Wen and Will Andrews has already done major chunk of work: patches to VirtualBox build system, skeleton VFS driver, API to talk to hypervisor but hit a block with some implementation details in VirtualBox\u0026rsquo;s virtual-memory compatibility layer. Will provided very comprehensive analysis of the problem.\nLi-Wen was occupied with some other projects so he gave me his OK to work on shared folder support on my own. Will\u0026rsquo;s suggestion was easy to implement - lock only userland memory, like Solaris driver does. VFS part was more complicated though: fs nodes, vnode, their lifecycle and locking is too hairy for drive-by hacking. I used tmpfs as a reference to learn some VFS magic, but a lot of things are still obscure. Nevertheless after few weeks of tinkering first milestone has been achieved: I can mount/unmount shared VirtualBox folder and navigate mounted filesystem without immediate kernel panic. Next goal (if time permits): stable and non-leaking read-only filesystem.\n","permalink":"https://kernelnomicon.org/posts/virtualbox-shared-folders-one-vop-at-a-time/","summary":"\u003cp\u003eTwo months ago I tried to setup dev environment using FreeBSD Vagrant box just to find out that FreeBSD does not support VirtualBox shared folders. After some googling I found Li-Wen Hsu\u0026rsquo;s github \u003ca href=\"https://github.com/lwhsu/freebsd-vboxfs\"\u003erepository\u003c/a\u003e with some work in this area. Li-Wen and Will Andrews has already done major chunk of work: patches to VirtualBox build system, skeleton VFS driver, API to talk to hypervisor but hit a block with some implementation details in VirtualBox\u0026rsquo;s virtual-memory compatibility layer. Will provided \u003ca href=\"https://github.com/lwhsu/freebsd-vboxfs/blob/master/vboxvfs/vboxvfs_prov.c#L131\"\u003every comprehensive analysis\u003c/a\u003e of the problem.\u003c/p\u003e","title":"VirtualBox Shared Folders: One VOP at a Time"},{"content":"To those who do not track FreeBSD commit messages: I committed gpiokeys driver to -CURRENT as r299475. The driver is not enabled in any of the kernels but can be built as a loadable module.\nFor now it stays disconnected from main build because it breaks some MIPS kernel configs. Configs in question include \u0026ldquo;modules/gpio\u0026rdquo; as part of MODULES_OVERRIDE variable and since gpiokeys can be built only with FDT-enabled kernel the build fails.\ngpiokeys can be used as a base for more input device driver: \u0026ldquo;gpio-keys-polled\u0026rdquo; and \u0026ldquo;gpio-matrix-keypad\u0026rdquo;. I do not have hardware to test this at the moment. If you do and you\u0026rsquo;re looking for small FreeBSD project to work on - here you go.\nNext step on my ToDo list is to try tricking people into committing evdev patch, which at the moment is the only requirement for unlocking touchscreen support.\n","permalink":"https://kernelnomicon.org/posts/gpiokeys-support-committed/","summary":"\u003cp\u003eTo those who do not track FreeBSD commit messages: I committed gpiokeys driver to -CURRENT as \u003ca href=\"https://svnweb.freebsd.org/base?view=revision\u0026amp;revision=299475\"\u003er299475\u003c/a\u003e. The driver is not enabled in any of the kernels but can be built as a loadable module.\u003c/p\u003e\n\u003cp\u003eFor now it stays disconnected from main build because it breaks some MIPS kernel configs. Configs in question include \u0026ldquo;modules/gpio\u0026rdquo; as part of MODULES_OVERRIDE variable and since gpiokeys can be built only with FDT-enabled kernel the build fails.\u003c/p\u003e","title":"gpiokeys support committed"},{"content":"Qt 5.6 is finally out so I thought I\u0026rsquo;d give it a spin on my Raspberry Pi. Previously I used cross-compilation but this time I thought I\u0026rsquo;d spend some time in trying to create ports Qt modules. There is Qt 5.5.1 in ports and it\u0026rsquo;s nicely split into sub-ports and most of gory details are hidden in bsd.qt.mk library. The problem with it is it\u0026rsquo;s highly coupled with Xorg stuff and I didn\u0026rsquo;t find easy way to squeeze non-desktop use cases into current infrastructure. So I just created new custom devel/qt56 port.\nIn order to get it done as fast as possible I took several shortcuts: all the stuff is installed to /usr/local/qt5 directory, there is no meta-port for submodules to share common part yet. Also besides base the only module I packaged (I was particularly interested in it) was QtMultimedia. Should be fairly easy to fix last 2 items though.\nQt layer for UI provider is called QPA: Qt Platform Abstraction. There are quite a few of them but I am familiar and interested in two: plain framebuffer and eglfs. Plain framebuffer stock QPA plugin is called linuxfb and naturally we can\u0026rsquo;t use it for FreeBSD. Luckily there is a lot of similarities between Linux fb and syscons(or vt) fb (you can\u0026rsquo;t get very innovative with framebuffer) so writing QPA support for scfb was easy. It can be used with any generic SoC with framebuffer support: AM335x(beaglebone black), i.MX6(Wandboard), NVIDIA Tegra, Pi.\nelgfs is full-screen OpenGL mode. OpenGL implementation depends on SoC vendor, e.g. Pi\u0026rsquo;s library is provided by raspberrypi-userland port. If we had OpenGL support for AM335x it would have been provided by PowerVR userland libraries. As far as I understand eglfs can\u0026rsquo;t be made universal: each implementation has its own quirks so you have to specify target OpenGL vendor during build time. So far we support eglfs only for Raspberry Pi thanks to Broadcom\u0026rsquo;s open-sourcing kernel drivers and userland libraries.\nThen there is question of input. When you start your application from console you have several options to get user\u0026rsquo;s input: keyboard, mouse, touchscreen. Common way to do this on Linux is through evdev which is a universal ways to access these kinds of devices. There is effort to get this functionality on FreeBSD so when it\u0026rsquo;s there stock input plugins could be used as-is. Until then there are two non-standard plugins by yours truly: bsdkeyboard and bsdsysmouse.\nscfb, bsdysmouse, and bsdkeyboard are included in experimental ports as patches.\nAll in all experience of getting Qt 5.6 running on FreeBSD/Pi was smooth. And to make this post more entertining here are two demos running on my Pi2 with official touchscreen.\nQt demo player with visualizer (src): https://youtu.be/OlZmzSgMKOo\nOpenGL demo with Qt logo in it (src): https://youtu.be/3-sdJG9wA3k\n","permalink":"https://kernelnomicon.org/posts/qt-5-6-is-here-and-it-runs-on-freebsdpi/","summary":"\u003cp\u003eQt 5.6 is finally out so I thought I\u0026rsquo;d give it a spin on my Raspberry Pi. Previously I used cross-compilation but this time I thought I\u0026rsquo;d spend some time in trying to create ports Qt modules. There is Qt 5.5.1 in ports and it\u0026rsquo;s nicely split into sub-ports and most of gory details are hidden in bsd.qt.mk library. The problem with it is it\u0026rsquo;s highly coupled with Xorg stuff and I didn\u0026rsquo;t find easy way to squeeze non-desktop use cases into current infrastructure. So I just created new \u003ca href=\"https://github.com/gonzoua/experimental-freebsd-ports\"\u003ecustom devel/qt56 port\u003c/a\u003e.\u003c/p\u003e","title":"Qt 5.6 is here and it runs on FreeBSD/Pi"},{"content":"Being able to power cycle ARM boards remotely (without spending a lot of $$$) was on my wish list for way to long, so I finally got around to put something together. The obvious way to do this is power relay controlled by GPIO + remotely accessible GPIO port. For the former I picked up this relay by Digital Loggers. It was four ports, only two of them are connected at a time, you can switch selected pair by setting control port level. For a controller part I picked up RIoTBoard but actually any ARM board with sshd running on it and user-accessible GPIO pin would do.\nOn riotboard there are several GPIO pins available on J13 expansion port. You can find values in board\u0026rsquo;s user manual. Just in case you don\u0026rsquo;t know (and it\u0026rsquo;s not in manual) pin 1 on the port marked with white triangle, if you look at port so that pin 1 is in top-left corner, next to it on the right is pin 2, and right under it is pin 3. So it goes like: [ 1 2 ] [ 3 4 ] [ 5 6 ] \u0026hellip; and so on \u0026hellip;\nI used GPIO4_16 (pin 5). You need to connect GND and GPIO pin to relay\u0026rsquo;s control port. Polarity does not matter in this case. For port control you can use gpioctl utility. But first we need to identify this pin on FreeBSD\u0026rsquo;s side. For each GPIO bank FreeBSD has /dev/gpiocX device node, where X starts from zero. But it\u0026rsquo;s not uncommon for SoC vendors to start numbering GPIO banks from 1. riotboard\u0026rsquo;s vendor is one of them so GPIO4 is actually controlled through /dev/gpioc3. By default pin 16 is configured as input, so you need to change it to out:\n# gpioctl -f /dev/gpioc3 -c 16 OUT and then you can start giving orders to relay:\n# gpioctl -f /dev/gpioc3 16 0 # gpioctl -f /dev/gpioc3 16 1 # gpioctl -f /dev/gpioc3 -t 16 Demo video: https://youtu.be/jsWATafJZ_I\n","permalink":"https://kernelnomicon.org/posts/controlling-ac-power-using-gpio/","summary":"\u003cp\u003eBeing able to power cycle ARM boards remotely (without spending a lot of $$$) was on my wish list for way to long, so I finally got around to put something together. The obvious way to do this is power relay controlled by GPIO + remotely accessible GPIO port. For the former I picked up \u003ca href=\"http://www.amazon.com/gp/product/B00WV7GMA2\"\u003ethis relay by Digital Loggers\u003c/a\u003e. It was four ports, only two of them are connected at a time, you can switch selected pair by setting control port level. For a controller part I picked up RIoTBoard but actually any ARM board with  sshd running on it and user-accessible GPIO pin would do.\u003c/p\u003e","title":"Controlling AC power using GPIO"},{"content":"Back from vacation and back to work. Once I got RIoTboard up and running next natural step was to wrap up some i.MX6 project I had in \u0026ldquo;almost finished\u0026rdquo; state for months. So now they\u0026rsquo;re in \u0026ldquo;going through review\u0026rdquo; state: drivers for HDMI framer and IPU. They add basic 1024x768 console for iMX6 board. Video mode management requires more sophisticated timers framework, that is being work on as a part of Jetson TK1 port.\n","permalink":"https://kernelnomicon.org/posts/i-mx6-ipu-and-hdmi-drivers/","summary":"\u003cp\u003eBack from vacation and back to work. Once I got RIoTboard up and running next natural step was to wrap up some i.MX6 project I had in \u0026ldquo;almost finished\u0026rdquo; state for months. So now they\u0026rsquo;re in \u0026ldquo;going through review\u0026rdquo; state: drivers for \u003ca href=\"https://reviews.freebsd.org/D4174\"\u003eHDMI framer\u003c/a\u003e and \u003ca href=\"https://reviews.freebsd.org/D4168\"\u003eIPU\u003c/a\u003e. They add basic 1024x768 console for iMX6 board. Video mode management requires more sophisticated timers framework, that is being work on as a part of Jetson TK1 port.\u003c/p\u003e","title":"i.MX6 IPU and HDMI drivers"},{"content":"My career as a trendy videoblogger starts to pay off. Nice people from Newark element14 offered to send me some hardware for experiments (no strings attached) I took them up on their offer and few days later received RIoTboard. It\u0026rsquo;s iMX6 Solo in developer-friendly package, not as compact as Beaglebone but nicely built and comes with more connectors.\nFreeBSD\u0026rsquo;s iMX6 support is very good, so it took two one-line fixes to FreeBSD kernel code to make it work on RIoTboard. The other chunk of work was U-Boot package. Took more time than it should have due to some operator errors. The bring up process is more or less the same as for any other iMX6 system, so it should be really easy to add this board to crochet. Step by step it looks like this (some of the code came from crochet):\nPrepare environment for the build\nexport TARGET=arm export TARGET_ARCH=armv6 export SRCROOT=/src/FreeBSD/head export MAKEOBJDIRPREFIX=/src/FreeBSD/obj export MAKESYSPATH=$SRCROOT/share/mk export KERNCONF=IMX6 Build world and kernel\nmake -j16 -C $SRCROOT buildworld make -C $SRCROOT KERNCONF=$KERNCONF -j16 buildkernel Create and partition SD card image\nIMG=/tmp/SD.img rm -f $IMG dd if=/dev/zero of=$IMG bs=1000000 count=1024 MDUNIT=$(mdconfig -a -f $IMG) DEV=/dev/$MDUNIT gpart create -s mbr $DEV # Create FAT partition FAT_DEV=/dev/${MDUNIT}s1 gpart add -a 63 -b 16384 -s 50m -t \u0026#39;!12\u0026#39; $DEV gpart set -a active -i 1 $DEV newfs_msdos -L \u0026#34;BOOT\u0026#34; -F 16 ${FAT_DEV} # Create UFS partition UFS_DEV=/dev/${MDUNIT}s2 gpart add -t freebsd $DEV gpart create -s BSD $UFS_DEV gpart add -t freebsd-ufs -a 64k $UFS_DEV UFS_PART=/dev/${MDUNIT}s2a newfs $UFS_PART # Turn on Softupdates tunefs -n enable $UFS_PART tunefs -j enable -S 4194304 $UFS_PART # Turn on NFSv4 ACLs tunefs -N enable $UFS_PART mdconfig -d -u $MDUNIT Mount UFS partition\nMDUNIT=$(sudo mdconfig -a -f $IMG) DEV=/dev/$MDUNIT UFS_DEV=/dev/${MDUNIT}s2a sudo mount $UFS_DEV $MNTDIR Install world + kernel\nsudo -E make -C $SRCROOT installworld -DDB_FROM_SRC DESTDIR=$MNTDIR sudo -E make -C $SRCROOT distribution -DDB_FROM_SRC DESTDIR=$MNTDIR sudo -E make -C $SRCROOT installkernel DESTDIR=$MNTDIR Install come configuration. We need hw.fdt.console in loader.conf because riotboard\u0026rsquo;s DTS file does not have stdout-path property in chosen node. In this case FreeBSD falls back to serial0 node but user-accessible UART on RIoTboard is UART2 so as a result no kernel output visible on serial port.\necho \u0026#39;hw.fdt.console=\u0026#34;/soc/aips-bus@02100000/serial@021e8000\u0026#34;\u0026#39; \u0026gt; /tmp/loader.conf cat \u0026gt; /tmp/fstab \u0026lt;\u0026lt;__EOF__ /dev/mmcsd0s2a / ufs rw,noatime 1 1 /dev/mmcsd0s1 /boot/msdos msdosfs rw,noatime 0 0 tmpfs /tmp tmpfs rw,size=31457280 0 0 tmpfs /var/log tmpfs rw,,size=15728640 0 0 tmpfs /var/tmp tmpfs rw,size=5242880 0 0 __EOF__ cat \u0026gt; /tmp/rc.conf \u0026lt;\u0026lt;__EOF__ hostname=\u0026#34;riotboard\u0026#34; sshd_enable=\u0026#34;YES\u0026#34; # minimal network config ifconfig_ffec0=\u0026#34;DHCP\u0026#34; # turn off sendmail sendmail_submit_enable=\u0026#34;NO\u0026#34; sendmail_outbound_enable=\u0026#34;NO\u0026#34; sendmail_msp_queue_enable=\u0026#34;NO\u0026#34; __EOF__ sudo mv /tmp/loader.conf $MNTDIR/boot/loader.conf sudo mv /tmp/fstab $MNTDIR/etc/fstab sudo mv /tmp/rc.conf $MNTDIR/etc/rc.conf sudo mkdir $MNTDIR/boot/msdos Unmount UFS and mount FAT partition\nsudo umount $MNTDIR FAT_DEV=/dev/${MDUNIT}s1 sudo mount -t msdosfs $FAT_DEV $MNTDIR Build and install ubldr, unmount FAT partition\nbuildenv=`make -C $SRCROOT TARGET_ARCH=armv6 buildenvvars` eval $buildenv make -C $SRCROOT/sys/boot -m $MAKESYSPATH obj eval $buildenv make -C $SRCROOT/sys/boot -m $MAKESYSPATH clean eval $buildenv make -C $SRCROOT/sys/boot -m $MAKESYSPATH depend eval $buildenv make -C $SRCROOT/sys/boot -m $MAKESYSPATH UBLDR_LOADADDR=0x12000000 all sudo cp ${MAKEOBJDIRPREFIX}/arm.armv6/${SRCROOT}/sys/boot/arm/uboot/ubldr $MNTDIR sudo umount $MNTDIR Download and install u-boot-riotboard port. Then flash u-boot to the image\nsudo dd if=/usr/local/share/u-boot/u-boot-riotboard/u-boot.imx of=$DEV bs=1k oseek=1 conv=sync Detach md device\nsudo mdconfig -d -u $MDUNIT Configure boot switch selector on board to boot from SD card as described in this document\nInsert SD card to either SD slot or uSD slot. When powered up you should see u-boot prompt\n=\u0026gt; Boot command would look something like:\n=\u0026gt; fatload mmc 0 $loadaddr ubldr =\u0026gt; bootelf For SD slot mmc unit is 0, for uSD it\u0026rsquo;s probably 1, I didn\u0026rsquo;t test.\nBoot log: here\nNext step for me is to get my imx6_video branch up to date and see if I can commit it to HEAD.\n","permalink":"https://kernelnomicon.org/posts/riotboard-support/","summary":"\u003cp\u003eMy career as \u003ca href=\"https://www.youtube.com/playlist?list=PLIlNZLQQ4dQvD_WThzImhmgI5477APYN4\"\u003ea trendy videoblogger\u003c/a\u003e starts to pay off. Nice people from \u003ca href=\"http://www.newark.com\"\u003eNewark element14\u003c/a\u003e offered to send me some hardware for experiments (no strings attached) I took them up on their offer and few days later received \u003ca href=\"http://www.element14.com/community/community/designcenter/single-board-computers/riotboard\"\u003eRIoTboard\u003c/a\u003e. It\u0026rsquo;s iMX6 Solo in developer-friendly package, not as compact as Beaglebone but nicely built and comes with more connectors.\u003c/p\u003e\n\u003cp\u003eFreeBSD\u0026rsquo;s iMX6 support is very good, so it took two one-line fixes to FreeBSD kernel code to make it work on RIoTboard. The other chunk of work was U-Boot package. Took more time than it should have due to some operator errors. The bring up process is more or less the same as for any other iMX6 system, so it should be really easy to add this board to \u003ca href=\"https://github.com/freebsd/crochet\"\u003ecrochet\u003c/a\u003e. Step by step it looks like this (some of the code came from crochet):\u003c/p\u003e","title":"RIoTboard support"},{"content":"Quick update on progress in FreeBSD\u0026rsquo;s support of Raspberry Pi:\nVCHIQ driver was updated to the latest vendor code and bunch of FreeBSD-specific problems was fixed: locking, handling of non-cacheline aligned data Raspberry Pi userland code was updated to the latest vendor code Mikael Urankar created misc/raspberrypi-userland for userland libraries/utilities Mikael also created multimedia/omxplayer port for OMXPlayer, video player developed for RPi. It\u0026rsquo;s also used in Kodi player on Pi. I created misc/ioquake-pi port to make it easier for people to try it out I put together all this stuff on my brand new Pi 2 and recorded demo that showcases, OpenGL, Quake3, omxplayer, camera, and audio. I hope all these ports will be committed/updated before next round of armv6 packages build.\nhttps://youtu.be/NYlvrr6cOpY\n","permalink":"https://kernelnomicon.org/posts/freebsd-on-rpi-2-progress/","summary":"\u003cp\u003eQuick update on progress in FreeBSD\u0026rsquo;s support of Raspberry Pi:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eVCHIQ driver was updated to the latest vendor code and bunch of FreeBSD-specific problems was fixed: locking, handling of non-cacheline aligned data\u003c/li\u003e\n\u003cli\u003eRaspberry Pi userland code was updated to the latest vendor code\u003c/li\u003e\n\u003cli\u003eMikael Urankar created \u003ca href=\"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204388\"\u003emisc/raspberrypi-userland\u003c/a\u003e for userland libraries/utilities\u003c/li\u003e\n\u003cli\u003eMikael also created \u003ca href=\"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204392\"\u003emultimedia/omxplayer\u003c/a\u003e port for OMXPlayer, video player developed for RPi. It\u0026rsquo;s also used in Kodi player on Pi.\u003c/li\u003e\n\u003cli\u003eI created \u003ca href=\"https://github.com/gonzoua/experimental-freebsd-ports/tree/master/games/ioquake3-pi\"\u003emisc/ioquake-pi\u003c/a\u003e port to make it easier for people to try it out\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eI put together all this stuff on my brand new Pi 2 and recorded demo that showcases, OpenGL, Quake3, omxplayer, camera, and audio. I hope all these ports will be committed/updated before next round of armv6 packages build.\u003c/p\u003e","title":"FreeBSD on RPi 2 progress"},{"content":"Received yesterday and had to assembly it first thing today. Display part works like a charm without any system modifications. Haven\u0026rsquo;t researched touchscreen part though.\n","permalink":"https://kernelnomicon.org/posts/official-7-raspberry-pi-touchscreen/","summary":"\u003cp\u003eReceived yesterday and had to assembly it first thing today. Display part works like a charm without any system modifications. Haven\u0026rsquo;t researched touchscreen part though.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/uploads/2015/10/IMG_1330.jpg\"\u003e\u003cimg alt=\"IMG_1330\" loading=\"lazy\" src=\"/uploads/2015/10/IMG_1330-768x1024.jpg\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/uploads/2015/10/IMG_1331.jpg\"\u003e\u003cimg alt=\"IMG_1331\" loading=\"lazy\" src=\"/uploads/2015/10/IMG_1331-1024x768.jpg\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/uploads/2015/10/IMG_1333.jpg\"\u003e\u003cimg alt=\"IMG_1333\" loading=\"lazy\" src=\"/uploads/2015/10/IMG_1333-1024x768.jpg\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/uploads/2015/10/IMG_1334.jpg\"\u003e\u003cimg alt=\"IMG_1334\" loading=\"lazy\" src=\"/uploads/2015/10/IMG_1334-1024x768.jpg\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/uploads/2015/10/IMG_1335.jpg\"\u003e\u003cimg alt=\"IMG_1335\" loading=\"lazy\" src=\"/uploads/2015/10/IMG_1335-1024x768.jpg\"\u003e\u003c/a\u003e\u003c/p\u003e","title":"Official 7\" Raspberry Pi Touchscreen Display and FreeBSD"},{"content":"And yet another demo of 4DCAPE-43T, this time it\u0026rsquo;s touchscreen. On AM335x SoC touchscreen controller is coupled with analog-to-digital converter, for which there is a driver in FreeBSD HEAD: ti_adc. I had to implement touchscreen part and add driver userland communication protocol. For proof of concept I used significantly dumbed-down version of Linux input event protocol. tslib serves as a userland part of the demo. I believe it\u0026rsquo;s de-facto standard for touchscreen devices interface in Linux world. Only two things were changed comparing to stock one: I added bsd-raw input plugin to communicate with kernel and rewrote framebuffer-related routines.\nCode is in 4dcape-43t branch in my work-in-progress GitHub repo and in freebsd branch of tslib fork.\nhttps://youtu.be/8aPUuMG3G9o\n","permalink":"https://kernelnomicon.org/posts/freebsd-bbb-and-4dcape-43t-touchscreen/","summary":"\u003cp\u003eAnd yet another demo of 4DCAPE-43T, this time it\u0026rsquo;s touchscreen. On AM335x SoC touchscreen controller is coupled with analog-to-digital converter, for which there is a driver in FreeBSD HEAD: ti_adc. I had to implement touchscreen part and add driver  userland communication protocol. For proof of concept I used significantly dumbed-down version of \u003ca href=\"http://lxr.free-electrons.com/source/Documentation/input/input.txt#L262\"\u003eLinux input event protocol\u003c/a\u003e. tslib serves as a userland part of the demo. I believe it\u0026rsquo;s de-facto standard for touchscreen devices interface in Linux world. Only two things were changed comparing to stock one: I added bsd-raw  input plugin to communicate with kernel and rewrote framebuffer-related routines.\u003c/p\u003e","title":"FreeBSD, BBB, and 4DCAPE-43T: touchscreen"},{"content":"I like Qt. It runs on everything. More than 10 years ago you could run it on Linux/ARM on Sharp Zaurus and now you can run it on FreeBSD/Pi. I thought it would look neat on LCD screen on BBB and coded small demo player (qt-demo-player sources) just for the fun of it. Stock Qt does not have FreeBSD framebuffer support so I had to hack it up (qt-platform-scfb sources). Also it seems they still consider FreeBSD/clang second class citizen comparing to FreeBSD/gcc which causes some minor POSIX-related incompatibility fallout. But other than that it was smooth sailing, patch against vendor tree is really small. I\u0026rsquo;ll post it later along with build instructions. In addition to scfb platform support Qt console input plugins required: qt5-bsd-input\nDemo was built using cross-compiled Qt 5.5.1, audio support is gstreamer Qt plugin. https://youtu.be/gyYbv0tLq9o\n","permalink":"https://kernelnomicon.org/posts/more-fun-with-baglebone-black-and-4dcape-43t/","summary":"\u003cp\u003eI like Qt. It runs on everything. More than 10 years ago you could run it on Linux/ARM on \u003ca href=\"https://en.wikipedia.org/wiki/Sharp_Zaurus\"\u003eSharp Zaurus\u003c/a\u003e and now you can run it on \u003ca href=\"http://kernelnomicon.org/?p=461\"\u003eFreeBSD/Pi\u003c/a\u003e. I thought it would look neat on LCD screen on BBB and coded small demo player (\u003ca href=\"https://github.com/gonzoua/qt-demo-player\"\u003eqt-demo-player sources\u003c/a\u003e) just for the fun of it. Stock Qt does not have FreeBSD framebuffer support so I had to hack it up (\u003ca href=\"https://github.com/gonzoua/qt-platform-scfb\"\u003eqt-platform-scfb sources\u003c/a\u003e). Also it seems they still consider FreeBSD/clang second class citizen comparing to FreeBSD/gcc which causes some minor POSIX-related incompatibility fallout. But other than that it was smooth sailing, patch against vendor tree is really small. I\u0026rsquo;ll post it later along with build instructions. In addition to scfb platform support Qt console input plugins required: \u003ca href=\"https://github.com/gonzoua/qt5-bsd-input\"\u003eqt5-bsd-input\u003c/a\u003e\u003c/p\u003e","title":"More fun with Beaglebone Black and 4DCAPE-43T"},{"content":"Short demo of FreeBSD running on Beaglebone Black with 4DCAPE-43T\nhttps://www.youtube.com/watch?v=4Vn_L_UzQhc\nI used vendor-provided am335x-boneblack-4dcape-43t.dts file to generate dtb, you can download compiled blob here. The system running on demo is gpiokeys branch of my git repo: . Patch against -head is here.\nIf you\u0026rsquo;re interested only in LCD screen - it\u0026rsquo;s supported by -head but you\u0026rsquo;ll need to either add device gpiobacklight to BEAGLEBONE kernel config or enable LCD backlight manually using gpioctl: gpioctl -f /dev/gpioc1 18 1. gpiokeys is somewhat more complex thing and still WIP, there are some pieces missing in HEAD I had to hack around to make them work. And I haven\u0026rsquo;t started research on touchscreen yet.\n","permalink":"https://kernelnomicon.org/posts/freebsd-bbb-and-4dcape-43t/","summary":"\u003cp\u003eShort demo of FreeBSD running on Beaglebone Black with \u003ca href=\"http://www.4dsystems.com.au/product/4DCAPE_43/\"\u003e4DCAPE-43T\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.youtube.com/watch?v=4Vn_L_UzQhc\"\u003ehttps://www.youtube.com/watch?v=4Vn_L_UzQhc\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eI used vendor-provided am335x-boneblack-4dcape-43t.dts file to generate dtb, you can download compiled blob \u003ca href=\"http://people.freebsd.org/~gonzo/arm/patches/am335x-boneblack-4dcape-43t.dtb\"\u003ehere\u003c/a\u003e. The system running on demo is \u003ca href=\"https://github.com/gonzoua/freebsd/tree/gpiokeys\"\u003egpiokeys branch\u003c/a\u003e of my git repo: . Patch against -head is \u003ca href=\"http://people.freebsd.org/~gonzo/arm/patches/bbb-gpiokeys.diff\"\u003ehere\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eIf you\u0026rsquo;re interested only in LCD screen - it\u0026rsquo;s supported by -head but you\u0026rsquo;ll need to either add \u003ccode\u003edevice gpiobacklight\u003c/code\u003e to BEAGLEBONE kernel config or enable LCD backlight manually using gpioctl: \u003ccode\u003egpioctl -f /dev/gpioc1 18 1\u003c/code\u003e. gpiokeys is somewhat more complex thing and still WIP, there are some pieces missing in HEAD I had to hack around to make them work. And I haven\u0026rsquo;t started research on touchscreen yet.\u003c/p\u003e","title":"FreeBSD, BBB and 4DCAPE-43T"},{"content":"FDT overlay is an extension to FDT format that lets user to modify base FDT run-time: add new nodes, add new properties to existing nodes or modify existing properties. It\u0026rsquo;s useful when you have base board and some extension units like cape/shield for Pi/BBB or loadable FPGA logic for Zynq. I will not go into details you can find internals described on Adafruit or Raspberry Pi websites.\nWhen dealing with overlays there are two options where to handle them: loader or kernel. Managing overlays at kernel level gives more flexibility but requires more related logic, e.g. re-init pinmux after applying overlay, re-run newbus probe/attach. On the other hand loader-level support is quite straightforward and involves nothing but DTB modifications and it\u0026rsquo;s a natural first step to adding FDT overlays to FreeBSD.\nProposed solution is to add fdt_overlays variable that contains coma-separated list of dtbo files, e.g.: \u0026ldquo;bbb-no-hdmi.dtbo,bbb-4dcape-43.dtbo\u0026rdquo;. This variable can be defined either as a loader(8) variable or as a u-boot env variable. During the boot ubldr load base DTB and right before passing control to the kernel it would go through files, load them from /boot/dtb/ direсtory on root partition and apply to the base blob. Final DTB would be passed to kernel.\nYou can find patch and review comments to it on Differential site: D3180. It contains:\nExtension to dtc to generate dynamic symbols and fixup info. ubldr fdt_overlays support As Warner Losh mentioned it\u0026rsquo;s not clear yet how to deal with dynamic symbols support patch. It\u0026rsquo;s not part of official dtc tree though it\u0026rsquo;s accepted by RPi and BBB communities.\n","permalink":"https://kernelnomicon.org/posts/fdt-overlays-in-freebsd/","summary":"\u003cp\u003eFDT overlay is an extension to FDT format that lets user to modify base FDT run-time: add new nodes, add new properties to existing nodes or modify existing properties. It\u0026rsquo;s useful when you have base board and some extension units like cape/shield for Pi/BBB or loadable FPGA logic for Zynq. I will not go into details you can find internals described on \u003ca href=\"https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/device-tree-overlays\"\u003eAdafruit\u003c/a\u003e or \u003ca href=\"https://www.raspberrypi.org/documentation/configuration/device-tree.md\"\u003eRaspberry Pi\u003c/a\u003e websites.\u003c/p\u003e\n\u003cp\u003eWhen dealing with overlays there are two options where to handle them: loader or kernel. Managing overlays at kernel level gives more flexibility but requires more related logic, e.g. re-init pinmux after applying overlay, re-run newbus probe/attach. On the other hand loader-level support is quite straightforward and involves nothing but DTB modifications and it\u0026rsquo;s a natural first step to adding FDT overlays to FreeBSD.\u003c/p\u003e","title":"FDT overlays in FreeBSD"},{"content":"Just quick (and overdue) update: HDMI for BBB is in HEAD as of r284534.\n","permalink":"https://kernelnomicon.org/posts/hdmi-support-for-beaglebone-black/","summary":"\u003cp\u003eJust quick (and overdue) update: HDMI for BBB is in HEAD as of r284534.\u003c/p\u003e","title":"HDMI support for Beaglebone Black"},{"content":"HDMI support for Beaglebone Black is stable now and supports reading EDID, you can get the path here. Before committing it I\u0026rsquo;d like to make interoperability between HDMI framer and FB/LCD drivers as generic as possible and for this I need at least one more system with working HDMI to find common patterns. For this purpose I picked up i.MX6-based Hummingboard and now try to get video output working on it. There is some minor progress but it seems before getting to HDMI/IPU I need to do some work on clock management part of the system. So it\u0026rsquo;s going to be some time before I see first pixels on my monitor.\nI also got 4DCAPE-43, neat Beaglebone Black LCD cape by 4D Systems. Patch (download here) for it is pretty minimal: VT support in kernel config, panel info and pins configuration in dts, and one improvement in GPIO driver (setting default values for OUT GPIO pins). None of the other features except reset button work yet but getting GPIO keyboard working would be an interesting project by itself.\nHere is the picture of cape in action:\n","permalink":"https://kernelnomicon.org/posts/hdmi-progress-and-4dcape-43-support-for-beaglebone-black/","summary":"\u003cp\u003eHDMI support for Beaglebone Black is stable now and supports reading EDID, you can get the path \u003ca href=\"https://people.freebsd.org/~gonzo/arm/patches/bbb-hdmi-20150128.diff\"\u003ehere\u003c/a\u003e. Before committing it I\u0026rsquo;d like to make interoperability between HDMI framer and FB/LCD drivers as generic as possible and for this I need at least one more system with working HDMI to find common patterns. For this purpose I picked up i.MX6-based \u003ca href=\"http://www.solid-run.com/products/hummingboard/\"\u003eHummingboard\u003c/a\u003e and now try to get video output working on it. There is some minor progress but it seems before getting to HDMI/IPU I need to do some work on clock management part of the system. So it\u0026rsquo;s going to be some time before I see first pixels on my monitor.\u003c/p\u003e","title":"HDMI progress and 4DCAPE-43 support for Beaglebone Black"},{"content":"Today for the first time I\u0026rsquo;ve got stable and correctly positioned output on HDMI monitor connected to BeagleBone Black. It involved fixing bug in AM335x LCDC controller, fixing bug in I2C controller, and a lot of experiments with register-pushing. Code requires major clean-up and is not ready for the tree yet. I\u0026rsquo;ll post patch when it\u0026rsquo;s in readable form.\n","permalink":"https://kernelnomicon.org/posts/hdmi-support-for-beaglebone-black-first-milestone/","summary":"\u003cp\u003eToday for the first time I\u0026rsquo;ve got stable and correctly positioned output on HDMI monitor connected to BeagleBone Black. It involved fixing bug in AM335x LCDC controller, fixing bug in I2C controller, and a lot of experiments with register-pushing. Code requires major clean-up and is not ready for the tree yet. I\u0026rsquo;ll post patch when it\u0026rsquo;s in readable form.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/uploads/2015/01/IMG_0650.jpg\"\u003e\u003cimg alt=\"IMG_0650\" loading=\"lazy\" src=\"/uploads/2015/01/IMG_0650-1024x768.jpg\"\u003e\u003c/a\u003e\u003c/p\u003e","title":"HDMI support for Beaglebone Black: first milestone"},{"content":"Build SD card image using crochet-freebsd with option VideoCore enabled. Mount either SD card itself of image to build host\nmount /dev/mmcsd0s2a /pi Checkout Qt5 sources and patch them\ncd /src git clone git://gitorious.org/qt/qt5.git qt5 cd qt5 git checkout 5.4.0 MODULES=qtbase,qtdeclarative,qtgraphicaleffects,qtimageformats,qtquick1,qtquickcontrols,qtscript,qtsvg,qtxmlpatterns ./init-repository --module-subset=$MODULES fetch -q -o - http://people.freebsd.org/~gonzo/arm/rpi/qt5-freebsd-pi.diff | patch -p1 Configure, build and install Qt5 to SD card\n./configure -platform unsupported/freebsd-clang -no-openssl -opengl es2 -device freebsd-rasp-pi-clang -device-option CROSS_COMPILE=/usr/armv6-freebsd/usr/bin/ -sysroot /pi/ -no-gcc-sysroot -opensource -confirm-license -optimized-qmake -release -prefix /usr/local/Qt5 -no-pch -nomake tests -nomake examples -plugin-sql-sqlite gmake -j `sysctl -n hw.ncpu` sudo gmake install You need BSD-specific plugins to enable mouse and keyboard input in EGLFS mode\ncd /src/ git clone https://github.com/gonzoua/qt5-bsd-input.git cd qt5-bsd-input /src/qt5/qtbase/bin/qmake gmake sudo gmake install Build application you\u0026rsquo;d like run and install it. I use one of the examples here\ncd /src/qt5/qtbase/examples/opengl/cube /src/qt5/qtbase/bin/qmake gmake sudo gmake install Unmount SD card, boot Pi, make sure vchiq is loaded\nroot@raspberry-pi:~ # kldload Start application\nroot@raspberry-pi:~ # /usr/local/Qt5/examples/opengl/cube/cube -plugin bsdkeyboard -plugin bsdsysmouse If you see something like this:\nEGL Error : Could not create the egl surface: error = 0x3003 Or this:\nQOpenGLFramebufferObject: Framebuffer incomplete attachment. It means you need to increase GPU memory by setting gpu_mem in config.txt. Amount depends on framebuffer resolution. 128Mb works for me on 1920x1080 display.\nbsdsysmouse plugin uses /dev/sysmouse by default, so you either should have moused running or specify actual mouse device, e.g.:\nroot@raspberry-pi:~ # cube -plugin bsdkeyboard -plugin bsdsysmouse:/dev/ums0 bsdkeyboard uses STDIN as input device, so if you\u0026rsquo;re trying to start app from serial console it should be something like this:\nroot@raspberry-pi:~ # cube -plugin bsdkeyboard -plugin bsdsysmouse \u0026lt; /dev/ttyv0 ","permalink":"https://kernelnomicon.org/posts/qt5-for-freebsdpi/","summary":"\u003cp\u003eBuild SD card image using crochet-freebsd with \u003ccode\u003eoption VideoCore\u003c/code\u003e enabled. Mount either SD card itself of image to build host\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003emount /dev/mmcsd0s2a /pi\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eCheckout Qt5 sources and patch them\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ecd /src\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003egit clone git://gitorious.org/qt/qt5.git qt5\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ecd qt5\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003egit checkout 5.4.0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eMODULES=qtbase,qtdeclarative,qtgraphicaleffects,qtimageformats,qtquick1,qtquickcontrols,qtscript,qtsvg,qtxmlpatterns\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e./init-repository --module-subset=$MODULES\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003efetch -q -o - http://people.freebsd.org/~gonzo/arm/rpi/qt5-freebsd-pi.diff | patch -p1\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eConfigure, build and install Qt5 to SD card\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e./configure -platform unsupported/freebsd-clang -no-openssl -opengl es2 -device freebsd-rasp-pi-clang -device-option CROSS_COMPILE=/usr/armv6-freebsd/usr/bin/ -sysroot /pi/ -no-gcc-sysroot -opensource -confirm-license -optimized-qmake -release -prefix /usr/local/Qt5 -no-pch -nomake tests -nomake examples -plugin-sql-sqlite\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003egmake -j `sysctl -n hw.ncpu`\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003esudo gmake install\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eYou need BSD-specific plugins to enable mouse and keyboard input in EGLFS mode\u003c/p\u003e","title":"Qt5 for FreeBSD/Pi"},{"content":"I\u0026rsquo;ve update ioquake binaries and pushed respective changes to github. New version has support for mouse and keyboard so you can actually play Quake3 on FreeBSD/Pi alas without sound. It should run out of the box on normal console. Make sure you have moused running or specify mouse device by setting Q_MOUSE_DEV environment variable, e.g.:\nenv Q_MOUSE_DEV=/dev/ums0 ioquake3.arm +set s_initsound 0 ","permalink":"https://kernelnomicon.org/posts/update-on-ioquakearm-for-freebsd-controls-support-added/","summary":"\u003cp\u003eI\u0026rsquo;ve update \u003ca href=\"http://people.freebsd.org/~gonzo/arm/ioquake3.arm.tar.gz\"\u003eioquake binaries\u003c/a\u003e and pushed respective changes to github. New version has support for mouse and keyboard so you can actually play Quake3 on FreeBSD/Pi alas without sound. It should run out of the box on normal console. Make sure you have moused running or specify mouse device by setting Q_MOUSE_DEV environment variable, e.g.:\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eenv Q_MOUSE_DEV=/dev/ums0 ioquake3.arm +set s_initsound 0\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e","title":"Update on ioquake/ARM for FreeBSD: controls support added"},{"content":"With stable VCHIQ driver next obvious target was to add VCHIQ-based audio support. So let me introduce to you: vchiq_audio, first take. It\u0026rsquo;s part of vchiq-freebsd repo so if you use Crochet to build SD card image just enable option VideoCore in config file and module will be automatically included.\nFrom shell run kldload vchiq_audio and you\u0026rsquo;re good to do. I believe that audio output is picked up automatically by VideoCore so if you have HDMI connected it\u0026rsquo;s probably going to be HDMI. I do not have device to confirm this. Adding knob to control audio output (auto, headphones, HDMI) is on my ToDo list.\nQuality is not ideal though. From quick tests it seems to work fine on system with rootfs on NFS but there are audio drops on SD-based system while playing mp3 over NFS. I\u0026rsquo;m going to debug and stresstest it more thoroughly next week.\nShort instruction on how to install mpg321 package on RPi:\nenv PACKAGESITE=http://chips.ysv.freebsd.org/packages/11armv6-11armv6/ SIGNATURE_TYPE=none pkg bootstrap mkdir -p /usr/local/etc/pkg/repos cd /usr/local/etc/pkg/repos echo \u0026#39;FreeBSD: { enabled: no }\u0026#39; \u0026gt; FreeBSD.conf cat \u0026gt; chips.ysv.conf \u0026lt;\u0026lt;__EOF__ chips.ysv: { url: \u0026#34;http://chips.ysv.freebsd.org/packages/freebsd:11:armv6:32:el:eabi:softfp\u0026#34;, mirror_type: \u0026#34;http\u0026#34;, signature_type: \u0026#34;none\u0026#34;, enabled: yes } __EOF__ pkg install mpg321 ","permalink":"https://kernelnomicon.org/posts/audio-on-raspberry-pi/","summary":"\u003cp\u003eWith stable VCHIQ driver next obvious target was to add VCHIQ-based audio support. So let me introduce to you: vchiq_audio, first take. It\u0026rsquo;s part of vchiq-freebsd repo so if you use Crochet to build SD card image just enable \u003ccode\u003eoption VideoCore\u003c/code\u003e in config file and module will be automatically included.\u003c/p\u003e\n\u003cp\u003eFrom shell run \u003ccode\u003ekldload vchiq_audio\u003c/code\u003e and you\u0026rsquo;re good to do. I believe that audio output is picked up automatically by VideoCore so if you have HDMI connected it\u0026rsquo;s probably going to be HDMI. I do not have device to confirm this. Adding knob to control audio output (auto, headphones, HDMI) is on my ToDo list.\u003c/p\u003e","title":"Audio on Raspberry Pi"},{"content":"Update: support for keyboard/mouse has been added\nAfter New Year I got back to hacking the VCHIQ stuff (thanks to adrian@ for prodding). Since last time I touched NetBSD folks got it merged to main tree, syncing with latest upstream code and fixing some stupid bugs in my codebase. So I partially merged things back, spent some time on fixing more bugs introduced by yours truly, merged userland bits from latest Broadcom\u0026rsquo;s bits (and fixing some bugs introduced by them). And as a result VCHIQ got stable enough to run ioquake3d on raspberry pi. Well, you can\u0026rsquo;t play it because there is no sound and no mouse support and keyboard support is severely crippled but you can navigate menus and watch demoes.\nHere is short summary of how to get it running:\nGet latest HEAD that includes r276794 Get latest crochet-freebsd Create configuration file for RasspberryPi, make sure that it\u0026rsquo;s configured for 2Gb SD card and has VideoCore enabled. i.e. it contains: option ImageSize 1950mb # for 2 Gigabyte card option VideoCore Build RPi image and flash to SD card mount FreeBSD partition, e.g. mount /dev/mmcsd0s2a /mnt Copy Quake3 PAK files to /baseq3 directory on SD card Download http://people.freebsd.org/~gonzo/arm/ioquake3.arm.tar.gz and copy *.so files to /baseq3 and ioqake3.arm to /usr/bin on SD card Unmount FreeBSD partition and mount boot partiotion, e.g. mount_msdosfs /dev/mmcsd0s1 /mnt Edit config.txt and change gpu_mem value to 64 Unmount SD card and boot it on your Pi Load vchiq module: kldload vchiq Start Quake3: ioqake3.arm +set s_initsound 0 Keyboard support is really broken. TAB and ENTER works, so you can navigate menus. But that\u0026rsquo;s pretty much it.\nioquake3 codebase with my minor changes located here: https://github.com/gonzoua/quake3 I provide pre-compiled binaries because for some reason ioquake3 built with xdev tools crash in qsort (libc incompatibilities?) so I use make buildenv to build it.\nAnd here is photo of demo in action (there are RaspberryPi and ZedBoard on it too, yay!)\n","permalink":"https://kernelnomicon.org/posts/raspberrypi-freebsd-and-ioquake3/","summary":"\u003cp\u003e\u003cstrong\u003eUpdate\u003c/strong\u003e: \u003ca href=\"http://kernelnomicon.org/?p=455\"\u003esupport for keyboard/mouse\u003c/a\u003e has been added\u003c/p\u003e\n\u003cp\u003eAfter New Year I got back to hacking the VCHIQ stuff (thanks to adrian@ for prodding). Since last time I touched NetBSD folks got it merged to main tree, syncing with latest upstream code and fixing some stupid bugs in my codebase. So I partially merged things back, spent some time on fixing more bugs introduced by yours truly, merged userland bits from latest Broadcom\u0026rsquo;s bits (and fixing some bugs introduced by them). And as a result VCHIQ got stable enough to run ioquake3d on raspberry pi. Well, you can\u0026rsquo;t play it because there is no sound and no mouse support and keyboard support is severely crippled but you can navigate menus and watch demoes.\u003c/p\u003e","title":"RaspberryPi, FreeBSD and ioquake3"},{"content":"A week ago Adrian Chadd asked me to take a loot at FreeBSD/MIPS emulation. So last week I\u0026rsquo;ve been busy tidying up stuff in that department and looking up bits of information on various emulators. This morning I finally committed last changeset so now is the time to write up summary.\nEmulators There are two widely used MIPS emulatoes that FreeBSD supports: QEMU and GXemul. Both of them support numerous MIPS devices but we\u0026rsquo;re interested in only two.\nMALTA is more or less standard for MIPS emulation and supported by both emulators. QEMU supports 32 and 64 bit variants with both big and little-endian byte order. So four modes in total. Also for MALTA machine QEMU provides PCNet NIC emulation.\nGXemul supports 32 and 64 bit modes of MALTA but only for little-endian byte order. Big-endian byte order is not supported due to incomplete PCI controller implementation. No NIC support for MALTA machine. Also Gxemul provides so-called oldtestmips emulation mode: generic implementation of abstract MIPS machine with very simplified NIC/disk devices. In theory it should be faster then actual hardware emulation but I haven\u0026rsquo;t got around to benchmarking yet. oldtestmips can be run in 32 and 64 bit mode, but only big-endian byte order is supported.\nDisk images I used raw disk images created by makefs(8) utility. The advantage of raw disk image is that they can be used with both emulators. qemu provides more options in this area but they\u0026rsquo;re out of scope of this article. I created four images for my tests: disk.img, disk64.img, diskel.img, and disk64el.img. 32-bit big-endian, 64-bit big-endian, 32-bit little-endian, 64-bit big-endian. The process looks somewhat like this script:\n#!/bin/sh set -e export TARGET=mips export TARGET_ARCH=mips export SRCCONF=/dev/null export SRCROOT=/src/FreeBSD/head export MAKEOBJDIRPREFIX=/src/FreeBSD/obj/head export DESTDIR=/src/FreeBSD/tftproot/$TARGET_ARCH make -C $SRCROOT buildworld sudo -E mkdir -p /src/FreeBSD/tftproot/$TARGET_ARCH sudo -E make -C $SRCROOT KERNCONF=$KERNCONF DESTDIR=$DESTDIR installworld sudo -E make -C $SRCROOT KERNCONF=$KERNCONF DESTDIR=$DESTDIR distribution # modify /etc/fstab and /etc/rc.conf in $DESTDIR # Create 512Mb disk image with big-endian UFS # For TARGET_ARCH set to mipsel or mips64el use \u0026#34;-B le\u0026#34; switch sudo -E makefs -M 538968064 -B be /src/FreeBSD/disk.img $DESTDIR Change TARGET_ARCH and disk image name accordingly for mipsel/mip64/mips64el targets.\nQEMU As of QEMU 1.6.0 there is one known problem with it: NIC emulation does not work in big-endian mode. See this patch for fix and details. Also, amount of memory limited to 128Mb. Use MALTA kernel config for 32-bit mode and MALTA64 for 64-bit mode.\nCommand lines for various modes/byte orders are:\nqemu-system-mips -M malta -kernel /path/to/mips.mips/MALTA/.../kernel -hda /src/FreeBSD/disk.img -nographic qemu-system-mips64 -M malta -kernel /path/to/mips.mips64/.../MALTA64/kernel -hda /src/FreeBSD/disk64.img -nographic qemu-system-mipsel -M malta -kernel /path/to/mips.mipsel/.../MALTA/kernel -hda /src/FreeBSD/diskel.img -nographic qemu-system-mips64el -M malta -kernel /path/to/mips.mips64el/.../MALTA64/kernel -hda /src/FreeBSD/disk64el.img -nographic GXemul GXemul requires two patches for proper FreeBSD/MIPS emulation. First one implements rdhwr op for reg 29 required by TLS support. The second one fixes UDP packet checksum calculation and required for proper functioning of emulated DHCP server. Both of these patches have been committed upstream but there were no GXemul release after that so they\u0026rsquo;re not available as part of emulators/gxemul port.\nAs with QEMU kernel configs for MALTA are MALTA and MALTA64. And since only little-endian byte order is supported command lines for this emulation mode are:\ngxemul -e malta -C 4Kc -d /home/gonzo/FreeBSD/diskel.img /path/to/mips.mipsel/.../MALTA/kernel gxemul -e malta -d /home/gonzo/FreeBSD/disk64el.img /path/to/mips.mips64el/.../MALTA64/kernel For oldtestmips emulation mode is other way around, only big-endian. And to make things more complicated it\u0026rsquo;s GXEMUL kernel config for 64-bit and GXEMUL32 for 32-bit. So here you are:\ngxemul -M 256 -E oldtestmips -d /home/gonzo/FreeBSD/disk64.img /path/to/mips.mips64/.../GXEMUL/kernel gxemul -M 256 -C 4Kc -E oldtestmips -d /home/gonzo/FreeBSD/disk.img /path/to/mips.mips/.../GXEMUL32/kernel Maximum amount of memory set could be set by -M command-line switch for oldtestmips emulation is 256M. Otherwise physical memory would overlap with memory-mapped regions reserved by devices. There are some preliminary work to work around this limitation but no results yet.\n","permalink":"https://kernelnomicon.org/posts/state-of-freebsdmips-emulation/","summary":"\u003cp\u003eA week ago Adrian Chadd asked me to take a loot at FreeBSD/MIPS emulation. So last week I\u0026rsquo;ve been busy tidying up stuff in that department and looking up bits of information on various emulators. This morning I finally committed last changeset so now is the time to write up summary.\u003c/p\u003e\n\u003ch2 id=\"emulators\"\u003eEmulators\u003c/h2\u003e\n\u003cp\u003eThere are two widely used MIPS emulatoes that FreeBSD supports: \u003ca href=\"http://www.qemu.org\"\u003eQEMU\u003c/a\u003e and \u003ca href=\"http://gxemul.sourceforge.net\"\u003eGXemul\u003c/a\u003e. Both of them support numerous MIPS devices but we\u0026rsquo;re interested in only two.\u003c/p\u003e","title":"State of FreeBSD/MIPS emulation"},{"content":"QEMU support in FreeBSD/armv6 regressed since I tried it last time few months back. Changes in FreeBSD kernel and in QEMU itself revealed bugs that were masked by previous behaviour.\nIn FreeBSD it was r248467: the way memory/IO resources are activated on FDT bus has been changed and it triggered bug in versatile_pci.c\nThe other issue is more complex. It seems that PCI IRQ routing in QEMU was out of sync with real hardware. So after commit 66a96d7018b9cbabb73c9b87b62a37e4cc46580a IRQ numbers assigned to PCI devices by FreeBSD kernel by default were invalid. Authors of QEMU eventually added compatibility knob to fall back to previous logic. So if you\u0026rsquo;re using QEMU 1.5 or later add this option to your command line:\n-global versatile_pci.broken-irq-mapping=1 ","permalink":"https://kernelnomicon.org/posts/update-on-freebsdarmv6-in-qemu/","summary":"\u003cp\u003eQEMU support in FreeBSD/armv6 regressed since I tried it last time few months back. Changes in FreeBSD kernel and in QEMU itself revealed bugs that were masked by previous behaviour.\u003c/p\u003e\n\u003cp\u003eIn FreeBSD it was r248467: the way memory/IO resources are activated on FDT bus has been changed and it triggered bug in versatile_pci.c\u003c/p\u003e\n\u003cp\u003eThe other issue is more complex. It seems that PCI IRQ routing in QEMU was out of sync with real hardware. So after \u003ca href=\"https://github.com/qemu/qemu/commit/66a96d7018b9cbabb73c9b87b62a37e4cc46580a\"\u003ecommit 66a96d7018b9cbabb73c9b87b62a37e4cc46580a\u003c/a\u003e IRQ numbers assigned to PCI devices by FreeBSD kernel by default were invalid. Authors of QEMU eventually added compatibility knob to fall back to previous logic. So if you\u0026rsquo;re using QEMU 1.5 or later add this option to your command line:\u003c/p\u003e","title":"Update on FreeBSD/armv6 in QEMU"},{"content":"It took me two months but I finally got back to hacking on musb driver for FreeBSD (the one that is used in TI AM335x-based devices like Beaglebone or Beaglebone Black). Previous revision turned out not to be ready for production. Here is the new one: beaglebone-usb-20130626.diff. I adopted it to latest HEAD, fixed numerous bugs, added support for SPLIT transactions and USB suspend/resume signalling. There is some cleaning-up to do but unless something major comes up the plan is to commit it over next few days.\n","permalink":"https://kernelnomicon.org/posts/usb-driver-for-freebsdbeaglebone/","summary":"\u003cp\u003eIt took me two months but I finally got back to hacking on musb driver for FreeBSD (the one that is used in TI AM335x-based devices like Beaglebone or Beaglebone Black). Previous revision turned out not to be ready for production. Here is the new one: \u003ca href=\"http://people.freebsd.org/~gonzo/arm/patches/beaglebone-usb-20130626.diff\"\u003ebeaglebone-usb-20130626.diff\u003c/a\u003e. I adopted it to latest HEAD, fixed numerous bugs, added support for SPLIT transactions and USB suspend/resume signalling. There is some cleaning-up to do but unless something major comes up the plan is to commit it over next few days.\u003c/p\u003e","title":"USB driver for FreeBSD/Beaglebone"},{"content":"Quick hint. If you did not disable \u0026ldquo;device sc\u0026rdquo; in kernel config all the message from kernel go to video console. But if something bad happened after kernel started and before framebuffer driver is activated all you\u0026rsquo;ll see would be \u0026ldquo;Kernel args: (null)\u0026rdquo; message on serial console which is not very helpful. So in order to debug this problem and have kernel boot messages on both monitor and serial port without recompiling kernel just add following line to /boot/loader.rc on SD card:\nset boot_multicons=\u0026#34;YES\u0026#34; ","permalink":"https://kernelnomicon.org/posts/raspberry-pi-console/","summary":"\u003cp\u003eQuick hint. If you did not disable \u003cstrong\u003e\u0026ldquo;device sc\u0026rdquo;\u003c/strong\u003e in kernel config all the message from kernel go to video console. But if something bad happened after kernel started and before framebuffer driver is activated all you\u0026rsquo;ll see would be \u003cstrong\u003e\u0026ldquo;Kernel args: (null)\u0026rdquo;\u003c/strong\u003e message on serial console which is not very helpful. So in order to debug this problem and have kernel boot messages on both monitor and serial port without recompiling kernel just add following line to /boot/loader.rc on SD card:\u003c/p\u003e","title":"Raspberry Pi console"},{"content":"I finally got around to finishing the PWM and LCDC driver for AM335x. Everything was committed today. Here is demo on AM335x EVM (I apologize for quality):\n","permalink":"https://kernelnomicon.org/posts/framebuffersyscons-support-for-am335x/","summary":"\u003cp\u003eI finally got around to finishing the PWM and LCDC driver for AM335x. Everything was committed today. Here is demo on AM335x EVM (I apologize for quality):\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/uploads/2013/05/IMG_0049.jpg\"\u003e\u003cimg alt=\"IMG_0049\" loading=\"lazy\" src=\"/uploads/2013/05/IMG_0049-e1369615548914-300x224.jpg\"\u003e\u003c/a\u003e\u003c/p\u003e","title":"Framebuffer/syscons support for AM335x"},{"content":"I\u0026rsquo;m trying to wrap up some project I started working on quite some time ago and this is first chunk of clean-up.\nPatchcontains:\nKernel config for AM335x EVM dts file for AM335x EVM with TFT panel info LCD controller driver with some functionality missing: only 24/32 bit depth and only TFT mode is supported Really simple PWM driver. LCD backlight is controlled through eCAS submodule of PWMSS0 module. I tested it only on evaluation module, although I think with proper panel/pinmux configuration it should work with BeagleBone\u0026rsquo;s LCD caps too. Parts missing: adjusting clock to proper pixel frequency, proper allocation of framebuffer memory.\n","permalink":"https://kernelnomicon.org/posts/work-in-progress-lcd-driver-for-am335x-evaluation-module/","summary":"\u003cp\u003eI\u0026rsquo;m trying to wrap up some project I started working on quite some time ago and this is first chunk of clean-up.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://people.freebsd.org/~gonzo/arm/patches/am335x-pwm-lcd.diff\"\u003ePatch\u003c/a\u003econtains:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eKernel config for AM335x EVM\u003c/li\u003e\n\u003cli\u003edts file for AM335x EVM with TFT panel info\u003c/li\u003e\n\u003cli\u003eLCD controller driver with some functionality missing: only 24/32 bit depth and only TFT mode is supported\u003c/li\u003e\n\u003cli\u003eReally simple PWM driver. LCD backlight is controlled through eCAS submodule of PWMSS0 module.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eI tested it only on evaluation module, although I think with proper panel/pinmux configuration it should work with BeagleBone\u0026rsquo;s LCD caps too.\nParts missing: adjusting clock to proper pixel frequency, proper allocation of framebuffer memory.\u003c/p\u003e","title":"Work in Progress: LCD driver for AM335x evaluation module"},{"content":"Writing new driver for FDT-based device always involves several simple steps:\nwriting generic newbus driver skeleton Checking for compatibility of node in probe routine Allocate memory/IRQ resources in attach routine I can\u0026rsquo;t say for other developers but I just copy existing driver, remove all device-specific stuff and rewrite generic stuff. Which is less time-consuming then writing it from scratch but time-consuming it is. Being huge fan of automation of any kind I decided to let computer do all this dumb work and leave creative part (copy-pasting registers definition from spec to code) to myself. the result is this script.\nDeveloper feeds driver description in YAML format to the script and gets driver skeleton that requires minimal amount of editing to get it compiled. Driver description includes author name, prefix for macroses, prefix for newbus method-functions, FDT compatibility string, driver name and number of IRQ/MEMORY resources. A minute saved is a minute earned.\nYAML example:\nAUTHOR: Oleksandr Tymoshenko \u0026lt;gonzo@freebsd.org\u0026gt; PREFIX: am335x_pwm MACRO_PREFIX: PWM DRIVER: am335x_pwm FDT_COMPATIBLE: ti,am335x-pwm IRQ_RESOURCES: 0 MEM_RESOURCES: 4 ","permalink":"https://kernelnomicon.org/posts/fdt-driver-skeleton-generator/","summary":"\u003cp\u003eWriting new driver for FDT-based device always involves several simple steps:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ewriting generic newbus driver skeleton\u003c/li\u003e\n\u003cli\u003eChecking for compatibility of node in probe routine\u003c/li\u003e\n\u003cli\u003eAllocate memory/IRQ resources in attach routine\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eI can\u0026rsquo;t say for other developers but I just copy existing driver, remove all device-specific stuff and rewrite generic stuff. Which is less time-consuming then writing it from scratch but time-consuming it is. Being huge fan of automation of any kind I decided to let computer do all this dumb work and leave creative part (copy-pasting registers definition from spec to code) to myself. the result is \u003ca href=\"https://github.com/gonzoua/freebsd-misc/tree/master/fdt_skeleton\"\u003ethis script\u003c/a\u003e.\u003c/p\u003e","title":"FDT driver skeleton generator"},{"content":"As it was mentioned in previous post U-Boot can boot FreeBSD kernel directly but this approach doesn\u0026rsquo;t allow a great deal of control over boot process: there is no way to set tunables\u0026rsquo; values or pre-load module. Controlling this stuff requires more knowledge of FreeBSD internal data structures and its boot process then U-Boot holds.\nOn i386 and other Tier1 architectures this task is handled by the loader(8) program. It\u0026rsquo;s last stage boot loader (e.g. it\u0026rsquo;s supposed to pass control to FreeBSD kernel only), highly customizable and scriptable. loader(8) relies on one of the previous stages boot loader to access resources like disks, console, network. For i386 it\u0026rsquo;s BTX and BIOS.\nubldr is implementation of loader(8) for ARM on top of U-Boot. Original code was developed by Semihalf back in 2008 and has been being improved by them and FreeBSD Community since then. Despite it has been around for almost 5 years amount of documentation is shockingly low. I found only these slides from BSDCan 2008.\nOne of the nice feature U-Boot provides is API for stand-alone process. If you don\u0026rsquo;t need full-blown operating system running on your hardware but still want access to SD card/network/console you can request them from U-Boot via syscall-like API that turns boot loader into quasi-OS. Some bits of information on this topic can be found in api/README file in U-Boot sources: here.\nubldr uses U-Boot API to enumerate devices that might be used as a boot source: block (e.g. SD card) or network. For network device it will use BOOTP to try to obtain network/boot data and then mount directory over NFS. For block device it will inspect partition table and try to find suitable partition to use as a root device. Once root is mounted ubldr will perform standard loader(8) magic: get loader-related config from /boot/ directory and act on it.\nThere is no dedicated top-level build target for ubldr so getting it compiled is a little bit tricky. You need to perform whole buildworld cycle before compiling ubldr. Build script would look something like this:\nexport SRCROOT=/src/FreeBSD/head export MAKESYSPATH=$SRCROOT/share/mk export TARGET=arm export TARGET_ARCH=armv6 export MAKEOBJDIRPREFIX=/src/FreeBSD/obj make -C $SRCROOT buildworld buildenv=`make -C $SRCROOT buildenvvars` eval $buildenv make -C $SRCROOT/sys/boot clean eval $buildenv make -C $SRCROOT/sys/boot obj eval $buildenv make -C $SRCROOT/sys/boot UBLDR_LOADADDR=0x2000000 all Meaning of UBLDR_LOADADDR is the same as KERNPHYSADDR in previous post.\nubldr is ELF executable and can be used with bootelf command. Typical boot log is something like this:\n## Starting application at 0x02000054 ... Consoles: U-Boot console Compatible API signature found @7b662a8 Number of U-Boot devices: 2 FreeBSD/armv6 U-Boot loader, Revision 1.2 (gonzo@bsdbox, Fri Apr 19 18:52:33 PDT 2013) DRAM: 128MB Device: disk Device: net /boot/kernel/kernel data=0x3ae624+0x2128c syms=[0x4+0x71ca0+0x4+0x44075] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Waiting for Ethernet connection... done. Using DTB provided by U-Boot. Kernel entry at 0x100100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. ... ","permalink":"https://kernelnomicon.org/posts/netbooting-armmips-devices-ubldr/","summary":"\u003cp\u003eAs it was mentioned in \u003ca href=\"http://kernelnomicon.org/?p=327\"\u003eprevious post\u003c/a\u003e U-Boot can boot FreeBSD kernel directly but this approach doesn\u0026rsquo;t allow a great deal of control over boot process: there is no way to set tunables\u0026rsquo; values or pre-load module. Controlling this stuff requires more knowledge of FreeBSD internal data structures and its boot process then U-Boot holds.\u003c/p\u003e\n\u003cp\u003eOn i386 and other Tier1 architectures this task is handled by the \u003ca href=\"http://www.freebsd.org/cgi/man.cgi?query=loader\u0026amp;sektion=8\"\u003eloader(8)\u003c/a\u003e program. It\u0026rsquo;s last stage boot loader (e.g. it\u0026rsquo;s supposed to pass control to FreeBSD kernel only), highly customizable and scriptable. \u003ca href=\"http://www.freebsd.org/cgi/man.cgi?query=loader\u0026amp;sektion=8\"\u003eloader(8)\u003c/a\u003e relies on one of the previous stages boot loader to access resources like disks, console, network. For i386 it\u0026rsquo;s BTX and BIOS.\u003c/p\u003e","title":"Netbooting ARM/MIPS devices: ubldr"},{"content":"U-Boot is a boot loader. Its task is to get kernel into memory and pass control to it. I will cover only parts of it related to netboot.\nkernel or kernel.bin But before we start loading something we need to know what to load. In previous post I mentioned that there are kernel, kernel.bin, and ubldr files. Let\u0026rsquo;s get into details. First of all: ubldr requires its own post. So there will be one more covering just ubldr. Now kernel and kernel.bin.\nkernel is ELF executable. It means that it\u0026rsquo;s a self-contained file with all the information required to layout its bits in memory. e.g.: this data in file should be copied to address A, and N bytes at address B should be set to zero, code intry point is address X. All this auxiliary information is stored alongside to raw code and data. U-boot (or any other bootloader) reads it, lays out data/code accordingly and passes control to entry point. U-Boot\u0026rsquo;s command for it is bootelf.\nNow, bootelf or ELF support in general is not always available in boot loaders. In this case we load ELF on host machine. Technically it\u0026rsquo;s called \u0026ldquo;convert to binary format\u0026rdquo; but essentially what objcopy utility does is it simulates loading of ELF file into memory and dumps memory region from the lowest address that belongs to loaded executable to the highest one into the kernel.bin file. No auxiliary information is saved - only raw code and data. Without this information it\u0026rsquo;s users responsibility to point which address this memory dump should be loaded at and where to start execution.\nThat\u0026rsquo;s theory in a nutshell. Back to practice.\nU-Boot Network initialization routine depends on the board you\u0026rsquo;re working with. If the ethernet card connected to board over USB (like on Raspberry Pi or Pandaboard) you might need to initialize USB first:\nU-Boot\u0026gt; usb start (Re)start USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found At this point you can either get network settings via DHCP or set them manually. Manual control over network is performed by setting U-Boot environment variables:\nU-Boot\u0026gt; setenv ipaddr 192.168.10.21 U-Boot\u0026gt; setenv netmask 255.255.255.0 U-Boot\u0026gt; setenv gatewayip 192.168.10.1 DHCP also provides information about TFTP server and boot file, we can set them manually too:\nU-Boot\u0026gt; setenv bootfile kernel U-Boot\u0026gt; setenv serverip 192.168.10.1 And now load it\nU-Boot\u0026gt; tftpboot 0x8000 and boot\nU-Boot\u0026gt; bootelf 0x8000 By default tftpboot and bootelf would use loadaddr env variable if it\u0026rsquo;s set so you can combine last two commands to\nU-Boot\u0026gt; setenv loadaddr 0x8000 U-Boot\u0026gt; tftpboot U-Boot\u0026gt; bootelf With DHCP everything above is combined into three commands:\nU-Boot\u0026gt; setenv loadaddr 0x8000 U-Boot\u0026gt; dhcp U-Boot\u0026gt; bootelf If you\u0026rsquo;re booting ELF loadaddr can be any valid address because bootelf will relocate kernel to proper location. Valid range for addresses depends on the board in use.\nWith kernel.bin though you have to specify specific value as a loadaddr. Usually it\u0026rsquo;s KERNPHYSADDR option in kernel config file for ARM and KERNLOADADDR value for MIPS. U-Boot commands sequence would look like:\nU-Boot\u0026gt; setenv bootfile kernel.bin ... U-Boot\u0026gt; setenv loadaddr 0x00100000 U-Boot\u0026gt; dhcp U-Boot\u0026gt; go 0x00100000 uImage, ubldr This is basic stuff I\u0026rsquo;ve been using for several years in my development environment. There are more options though: u-boot application images and bootm command and ubldr. Former is well-documented on Internet and about latter I\u0026rsquo;ll post some information soon.\n","permalink":"https://kernelnomicon.org/posts/netbooting-armmips-devices-kinds-of-kernel-and-u-boot/","summary":"\u003cp\u003e\u003ca href=\"http://www.denx.de/wiki/U-Boot\"\u003eU-Boot\u003c/a\u003e is a boot loader. Its task is to get kernel into memory and pass control to it. I will cover only parts of it related to netboot.\u003c/p\u003e\n\u003ch2 id=\"kernel-or-kernelbin\"\u003ekernel or kernel.bin\u003c/h2\u003e\n\u003cp\u003eBut before we start loading something we need to know what to load. In \u003ca href=\"http://kernelnomicon.org/?p=306\"\u003eprevious post\u003c/a\u003e I mentioned that there are kernel, kernel.bin, and ubldr files. Let\u0026rsquo;s get into details. First of all: ubldr requires its own post. So there will be one more covering just ubldr. Now kernel and kernel.bin.\u003c/p\u003e","title":"Netbooting ARM/MIPS devices: kinds of kernel and u-boot"},{"content":"I was asked to share details about my root-over-NFS setup so here they are. I decided to split how-to in two posts: server/kernel part and u-boot part.\nUsual components in the setup are:\nDHCP server TFTP server NFS server NAT (optional) DHCP server I use net/isc-dhcp42-server as a server. Sample dhcpd.conf:\noption root-opts code 130 = string; # NFS / mount options log-facility local7; subnet 192.168.10.0 netmask 255.255.255.0 { server-name \u0026#34;cinderella.bluezbox.com\u0026#34;; server-identifier 192.168.10.1; option subnet-mask 255.255.255.0; option broadcast-address 192.168.10.255; option domain-name-servers 8.8.8.8; option domain-name \u0026#34;bluezbox.com\u0026#34;; next-server 192.168.10.1; option routers 192.168.10.1; } group { host pandaboard { hardware ethernet 0E:60:33:B1:46:01; fixed-address 192.168.10.90; filename \u0026#34;kernel.PANDA.bin\u0026#34;; option root-path \u0026#34;/src/FreeBSD/nfs/armv6\u0026#34;; option root-opts \u0026#34;nolockd\u0026#34;; } host rpi { hardware ethernet b8:27:eb:f6:08:83; fixed-address 192.168.10.91; filename \u0026#34;ubldr\u0026#34;; option root-path \u0026#34;/src/FreeBSD/nfs/rpi\u0026#34;; option root-opts \u0026#34;nolockd\u0026#34;; } } Config is pretty self-explanatory. I use google\u0026rsquo;s 8.8.8.8 nameserver but you can change it to your very own DNS server. Difference between various filename \u0026ldquo;\u0026hellip;\u0026rdquo; will be explained later.\ndhcpd should be enabled in rc.conf(5)\ndhcpd_enable=\u0026#34;YES\u0026#34; TFTP server TFTP server provides access to all files described in filename \u0026ldquo;\u0026hellip;\u0026rdquo; options so it\u0026rsquo;s better to keep them together. By default it\u0026rsquo;s /tftpboot directory but I have whole drive dedicated to FreeBSD development environment and mounted under /src/FreeBSD mountpoint. So I keep everything there and my TFTP server root is /src/FreeBSD/tftpboot. TFTP server is standard FreeBSD\u0026rsquo;s one and config line in inetd.conf(8) looks like:\ntftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /src/FreeBSD/tftpboot inted should be enabled in rc.conf(5)\ninetd_enable=\u0026#34;YES\u0026#34; NFS Server NFS server is not just one daemon but several services combined. So rc.conf(5) part of config looks like this:\nrpcbind_enable=\u0026#34;YES\u0026#34; rpc_statd_enable=\u0026#34;YES\u0026#34; rpc_lockd_enable=\u0026#34;YES\u0026#34; nfs_server_enable=\u0026#34;YES\u0026#34; mountd_enable=\u0026#34;YES\u0026#34; Filesystems that are exported via NFS listed in exports(5). Mine contains following:\n# Mind mount points obj and nfs are different /usr/ports -maproot=0 -network 192.168.10.0/16 /src/FreeBSD/head /src/FreeBSD/nfs/rpi /src/FreeBSD/nfs/armv6 /src/FreeBSD/nfs/am335x -maproot=0 -network 192.168.10.0/16 Note that you can join several directories into one line only if they belong to the same mount point.\nNAT If you\u0026rsquo;re planning on building ports on the device - you\u0026rsquo;ll need internet access on it. All my devices are restricted to one LAN with laptop acting as a gateway. I use pf(4) for NATing. Config: /etc/pf.conf(5)\next_if=em0 rede=\u0026#34;{192.168.0.0/16}\u0026#34; nat on $ext_if from $rede to any -\u0026gt; ($ext_if) and rc.conf(5)\ngateway_enable=\u0026#34;YES\u0026#34; pf_enable=\u0026#34;YES\u0026#34; pf_rules=\u0026#34;/etc/pf.conf\u0026#34; pf_flags=\u0026#34;\u0026#34; Kernel config FreeBSD kernel should be properly configured in order to be suitable for mounting root over NFS:\noptions NFSCL options NFSCLIENT # NFS v3 options NFS_ROOT options BOOTP_NFSROOT options BOOTP_COMPAT options BOOTP options BOOTP_NFSV3 options BOOTP_WIRED_TO=ue0 BOOTP_WIRED_TO value is SoC-specific. If you do not have full control over your DHCP server (e.g. it\u0026rsquo;s cable modem) and can\u0026rsquo;t specify root-path/root-opts you still can hardcode root location by removing BOOTP_NFSROOT and adding\noptions ROOTDEVNAME=\\\u0026#34;nfs:192.168.10:/src/FreeBSD/nfs/rpi\\\u0026#34; Installation Depending on your boot sequence installation consists of one or two steps.\nNormal system installation, e.g.:\nsudo -E make TARGET_ARCH=armv6 DESTDIR=/src/FreeBSD/nfs/rpi -DDB_FROM_SRC installworld sudo -E make TARGET_ARCH=armv6 DESTDIR=/src/FreeBSD/nfs/rpi -DDB_FROM_SRC distribution And installing kernel copying kernel to tftpboot directory:\nsudo -E make TARGET_ARCH=armv6 DESTDIR=/src/FreeBSD/nfs/rpi -DDB_FROM_SRC installkernel cp /src/FreeBSD/nfs/rpi/boot/kernel/kernel /src/FreeBSD/tftpboot/kernel.RPI In some cases you\u0026rsquo;d want to use kernel.bin instead of kernel (more on it in next post) so second step would look like\nsudo -E make TARGET_ARCH=armv6 DESTDIR=/src/FreeBSD/nfs/rpi -DDB_FROM_SRC KERNEL_EXTRA_INSTALL=kernel.bin installkernel cp /src/FreeBSD/nfs/rpi/boot/kernel/kernel.bin /src/FreeBSD/tftpboot/kernel.RPI.bin And if you\u0026rsquo;re going to use ubldr, there is no need to copy installed kernel anywhere.\nMore details on different types of binaries and boot process in the next post\n","permalink":"https://kernelnomicon.org/posts/netbooting-armmips-devices-server-setup/","summary":"\u003cp\u003eI was asked to share details about my root-over-NFS setup so here they are. I decided to split how-to in two posts: server/kernel part and u-boot part.\u003c/p\u003e\n\u003cp\u003eUsual components in the setup are:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eDHCP server\u003c/li\u003e\n\u003cli\u003eTFTP server\u003c/li\u003e\n\u003cli\u003eNFS server\u003c/li\u003e\n\u003cli\u003eNAT (optional)\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"dhcp-server\"\u003eDHCP server\u003c/h2\u003e\n\u003cp\u003eI use \u003cstrong\u003enet/isc-dhcp42-server\u003c/strong\u003e as a server. Sample dhcpd.conf:\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eoption root-opts code 130 = string; # NFS / mount options\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003elog-facility local7;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003esubnet 192.168.10.0 netmask 255.255.255.0 {\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        server-name \u0026#34;cinderella.bluezbox.com\u0026#34;;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        server-identifier 192.168.10.1;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        option subnet-mask 255.255.255.0;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        option broadcast-address 192.168.10.255;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        option domain-name-servers 8.8.8.8;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        option domain-name \u0026#34;bluezbox.com\u0026#34;;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        next-server 192.168.10.1;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        option routers 192.168.10.1;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e}\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003egroup {\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        host pandaboard {\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e                hardware ethernet 0E:60:33:B1:46:01;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e                fixed-address 192.168.10.90;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e                filename \u0026#34;kernel.PANDA.bin\u0026#34;;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e                option root-path \u0026#34;/src/FreeBSD/nfs/armv6\u0026#34;;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e                option root-opts \u0026#34;nolockd\u0026#34;;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        }\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        host rpi {\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e                hardware ethernet b8:27:eb:f6:08:83;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e                fixed-address 192.168.10.91;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e                filename \u0026#34;ubldr\u0026#34;;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e                option root-path \u0026#34;/src/FreeBSD/nfs/rpi\u0026#34;;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e                option root-opts \u0026#34;nolockd\u0026#34;;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e        }\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e}\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eConfig is pretty self-explanatory. I use google\u0026rsquo;s \u003cstrong\u003e8.8.8.8\u003c/strong\u003e nameserver but you can change it to your very own DNS server. Difference between various \u003cstrong\u003efilename \u0026ldquo;\u0026hellip;\u0026rdquo;\u003c/strong\u003e will be explained later.\u003c/p\u003e","title":"Netbooting ARM/MIPS devices: server setup"},{"content":"Last few weeks I\u0026rsquo;ve been acting as a reviewer for Ganbold Tsagaankhuu\u0026rsquo;s port of FreeBSD for Cubieboard so in order to provide more valuable input and less naysaying I decided to get A10-based device to test his changes. So I ordered Hackberry from miniand.com. I\u0026rsquo;m not great fan of pushing SD cards back and forth so first thing I do with my SoCs is get them netbooting. That\u0026rsquo;s where fun begins.\nLong story short - I had to get latest official u-boot, merge network driver (sunxi_wemac) from hno\u0026rsquo;s u-boot and add some GPIO magic to emac initialization. Namely - configure pin H19 (emac_power) as function 1 and set its value to 1. Only then I got net-related commands working properly.\nIf you\u0026rsquo;re interested in building your own bootable SD card: fetch these files. uEnv.txt and boot.scr are tailored to my needs so you might want to change them. mksd.sh does all the job, just make sure you use proper device name for SD card.\n","permalink":"https://kernelnomicon.org/posts/netbooting-hackberry-a10-allwinner-a10/","summary":"\u003cp\u003eLast few weeks I\u0026rsquo;ve been acting as a reviewer for Ganbold Tsagaankhuu\u0026rsquo;s port of FreeBSD for Cubieboard so in order to provide more valuable input and less naysaying I decided to get A10-based device to test his changes. So I ordered \u003ca href=\"https://www.miniand.com/products/Hackberry%20A10%20Developer%20Board\"\u003eHackberry\u003c/a\u003e from miniand.com. I\u0026rsquo;m not great fan of pushing SD cards back and forth so first thing I do with my SoCs is get them netbooting. That\u0026rsquo;s where fun begins.\u003c/p\u003e","title":"Netbooting Hackberry A10 (Allwinner A10)"},{"content":"I started this smallish project to overcome coder\u0026rsquo;s block and original idea was to implement it in only one scripting language. I chose Python as I believed it had most clear API but then I decided to throw in Perl and Ruby as well. It was more exercise in building C extensions then in actual system programming but it was fun nonetheless. All three sub-projects lack proper documentation but there are examples that should be enough to get started.\nSources available on github.\n","permalink":"https://kernelnomicon.org/posts/accessing-gpio-from-perl-python-and-ruby/","summary":"\u003cp\u003eI started this smallish project to overcome coder\u0026rsquo;s block and original idea was to implement it in only one scripting language. I chose Python as I believed it had most clear API but then I decided to throw in Perl and Ruby as well. It was more exercise in building C extensions then in actual system programming but it was fun nonetheless. All three sub-projects lack proper documentation but there are examples that should be enough to get started.\u003c/p\u003e","title":"Accessing GPIO from Perl, Python, and Ruby"},{"content":"Update 1: Add -DDB_FROM_SRC to install targets Update 2: Add user \u0026ldquo;pi\u0026rdquo; with password \u0026ldquo;raspberry\u0026rdquo; Update 3: Added host system requirements suggested in comments Update 4: Rename bcm2835-rpi-b.dtb to rpi.dtb\nIt\u0026rsquo;s been a while since I posted original build instruction and a lot has change. Here is new version of it with some explanations:\nFirst make sure your host system is configured properly:\nWITHOUT_FORTH= must NOT be set in src.conf msdos support must be available in the kernel geom_md support must be available in the kernel All code has been moved to HEAD. freebsd-pi repository on github serves only historical purpose and I guess will be removed at some point in future. So in order to build image you need sources for -head\nsvn co svn://svn.freebsd.org/base/head TARGET_CPUTYPE is dropped to in favor of TARGET_ARCH=armv6. U-Boot, firmware files and boot process were upgraded too. Current boot chain is as follows:\nPi is powered up and loads firmware files Firmware loads FDT blob defined in config.txt as device_tree variable at address defined as device_tree_address and fixes up fields like memory size, clock frequency and MAC address Firmware loads u-boot and passes control to it U-boot loads boot.scr and executes it Default boot.scr loads ubldr(loader(8)-compatible implementation built over U-Boot API) and passes control ubldr checks FreeBSD partition for /boot/loader.rc, loads it, the loads /boot/kernel/kernel and passes control to it loader.rc should contain \u0026ldquo;fdt addr 0x100\u0026rdquo; command. It will pass FDT blob filled in step #2 to kernel So updated build script will look something like this:\n#!/bin/sh set -e # Change this export GPU_MEM=128 export PI_USER=pi export PI_USER_PASSWORD=raspberry export SRCROOT=/src/FreeBSD/head export MNTDIR=/mnt export MAKEOBJDIRPREFIX=/src/FreeBSD/obj export IMG=/src/FreeBSD/obj/bsd-pi.img export TARGET_ARCH=armv6 export MAKESYSPATH=$SRCROOT/share/mk export KERNCONF=RPI-B if [ -z \u0026#34;$MNTDIR\u0026#34; ]; then echo \u0026#34;MNTDIR is not set properly\u0026#34; exit 1 fi KERNEL=`realpath $MAKEOBJDIRPREFIX`/arm.armv6/`realpath $SRCROOT`/sys/$KERNCONF/kernel UBLDR=`realpath $MAKEOBJDIRPREFIX`/arm.armv6/`realpath $SRCROOT`/sys/boot/arm/uboot/ubldr DTB=`realpath $MAKEOBJDIRPREFIX`/arm.armv6/`realpath $SRCROOT`/sys/$KERNCONF/rpi.dtb make -C $SRCROOT kernel-toolchain make -C $SRCROOT KERNCONF=$KERNCONF WITH_FDT=yes buildkernel make -C $SRCROOT MALLOC_PRODUCTION=yes buildworld buildenv=`make -C $SRCROOT buildenvvars` eval $buildenv make -C $SRCROOT/sys/boot clean eval $buildenv make -C $SRCROOT/sys/boot obj eval $buildenv make -C $SRCROOT/sys/boot UBLDR_LOADADDR=0x2000000 all rm -f $IMG dd if=/dev/zero of=$IMG bs=128M count=8 MDFILE=`mdconfig -a -f $IMG` gpart create -s MBR ${MDFILE} # Boot partition gpart add -s 32m -t \u0026#39;!12\u0026#39; ${MDFILE} gpart set -a active -i 1 ${MDFILE} newfs_msdos -L boot -F 16 /dev/${MDFILE}s1 mount_msdosfs /dev/${MDFILE}s1 $MNTDIR fetch -q -o - http://people.freebsd.org/~gonzo/arm/rpi/freebsd-uboot-20130201.tar.gz | tar -x -v -z -C $MNTDIR -f - cat \u0026gt;\u0026gt; $MNTDIR/config.txt \u0026lt;\u0026lt;__EOC__ gpu_mem=$GPU_MEM device_tree=devtree.dat device_tree_address=0x100 disable_commandline_tags=1 __EOC__ cp $UBLDR $MNTDIR cp $DTB $MNTDIR/devtree.dat umount $MNTDIR # FreeBSD partition gpart add -t freebsd ${MDFILE} gpart create -s BSD ${MDFILE}s2 gpart add -t freebsd-ufs ${MDFILE}s2 newfs /dev/${MDFILE}s2a # Turn on Softupdates tunefs -n enable /dev/${MDFILE}s2a # Turn on SUJ with a minimally-sized journal. # This makes reboots tolerable if you just pull power on the BB # Note: A slow SDHC reads about 1MB/s, so a 30MB # journal can delay boot by 30s. tunefs -j enable -S 4194304 /dev/${MDFILE}s2a # Turn on NFSv4 ACLs tunefs -N enable /dev/${MDFILE}s2a mount /dev/${MDFILE}s2a $MNTDIR make -C $SRCROOT DESTDIR=$MNTDIR -DDB_FROM_SRC installkernel make -C $SRCROOT DESTDIR=$MNTDIR -DDB_FROM_SRC installworld make -C $SRCROOT DESTDIR=$MNTDIR -DDB_FROM_SRC distribution echo \u0026#39;fdt addr 0x100\u0026#39; \u0026gt; $MNTDIR/boot/loader.rc echo \u0026#39;/dev/mmcsd0s2a / ufs rw,noatime 1 1\u0026#39; \u0026gt; $MNTDIR/etc/fstab cat \u0026gt; $MNTDIR/etc/rc.conf \u0026lt;\u0026lt;__EORC__ hostname=\u0026#34;raspberry-pi\u0026#34; ifconfig_ue0=\u0026#34;DHCP\u0026#34; sshd_enable=\u0026#34;YES\u0026#34; devd_enable=\u0026#34;YES\u0026#34; sendmail_submit_enable=\u0026#34;NO\u0026#34; sendmail_outbound_enable=\u0026#34;NO\u0026#34; sendmail_msp_queue_enable=\u0026#34;NO\u0026#34; __EORC__ cat \u0026gt; $MNTDIR/etc/ttys \u0026lt;\u0026lt;__EOTTYS__ ttyv0 \u0026#34;/usr/libexec/getty Pc\u0026#34; xterm on secure ttyv1 \u0026#34;/usr/libexec/getty Pc\u0026#34; xterm on secure ttyv2 \u0026#34;/usr/libexec/getty Pc\u0026#34; xterm on secure ttyv3 \u0026#34;/usr/libexec/getty Pc\u0026#34; xterm on secure ttyv4 \u0026#34;/usr/libexec/getty Pc\u0026#34; xterm on secure ttyv5 \u0026#34;/usr/libexec/getty Pc\u0026#34; xterm on secure ttyv6 \u0026#34;/usr/libexec/getty Pc\u0026#34; xterm on secure ttyu0 \u0026#34;/usr/libexec/getty 3wire.115200\u0026#34; dialup on secure __EOTTYS__ echo $PI_USER_PASSWORD | pw -V $MNTDIR/etc useradd -h 0 -n $PI_USER -c \u0026#34;Raspberry Pi User\u0026#34; -s /bin/csh -m pw -V $MNTDIR/etc groupmod wheel -m $PI_USER PI_USER_UID=`pw -V $MNTDIR/etc usershow $PI_USER | cut -f 3 -d :` PI_USER_GID=`pw -V $MNTDIR/etc usershow $PI_USER | cut -f 4 -d :` mkdir -p $MNTDIR/home/$PI_USER chown $PI_USER_UID:$PI_USER_GID $MNTDIR/home/$PI_USER umount $MNTDIR mdconfig -d -u $MDFILE ","permalink":"https://kernelnomicon.org/posts/building-image-for-raspberry-pi-up-to-date-version/","summary":"\u003cp\u003e\u003cstrong\u003eUpdate 1: Add -DDB_FROM_SRC to install targets\u003c/strong\u003e\n\u003cstrong\u003eUpdate 2: Add user \u0026ldquo;pi\u0026rdquo; with password \u0026ldquo;raspberry\u0026rdquo;\u003c/strong\u003e\n\u003cstrong\u003eUpdate 3: Added host system requirements suggested in comments\u003c/strong\u003e\n\u003cstrong\u003eUpdate 4: Rename bcm2835-rpi-b.dtb to rpi.dtb\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIt\u0026rsquo;s been a while since I posted original \u003ca href=\"http://kernelnomicon.org/?p=164\"\u003ebuild instruction\u003c/a\u003e and a lot has change. Here is new version of it with some explanations:\u003c/p\u003e\n\u003cp\u003eFirst make sure your host system is configured properly:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWITHOUT_FORTH= must NOT be set in src.conf\u003c/li\u003e\n\u003cli\u003emsdos support must be available in the kernel\u003c/li\u003e\n\u003cli\u003egeom_md support must be available in the kernel\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAll code has been moved to HEAD. freebsd-pi repository on github serves only historical purpose and I guess will be removed at some point in future. So in order to build image you need sources for -head\u003c/p\u003e","title":"Building image for Raspberry Pi: up to date version"},{"content":"I synced both vchiq-freebsd and userland to latest and greatest.\nAs I mentioned earlier - OS compatibility shim was removed from upstream sources so I had to create Linux KPI implementation layer which turned out not that awful task because I managed to reuse a lot of code from Max Khon\u0026rsquo;s DAHDI port. I had to implement (in somewhat hackish fashion) kthread API, re-implement semaphores support using condvar and mutex in order to get _interruptible part of API working properly and create dumb implementation of rather small subset of Linux list.h API.\nWith latest code I got pretty much all demos in hello_pi working except hello_jpeg(crashes system) and hello_encode(didn\u0026rsquo;t test). The most exciting bit for me was watching H.264 video playing on Raspberry Pi in hello_video demo. Network throughput still sucks so I had to copy file to tmpfs partition in order to get smooth playback though.\nIf you want to test VCHIQ - in addition to sources you\u0026rsquo;ll need latest firmware files. For demos you\u0026rsquo;ll also have to install freetype2 and manually hack Makefile.include in hello_pi. I\u0026rsquo;m planning to create ports/packages for both drivers and userland some time next week.\nOn the related note: Aleksandr Rybalko got XOrg working on Efika MX Smartbook so FreeBSD/Pi will get graphic interface soon :)\n","permalink":"https://kernelnomicon.org/posts/vchiq-drivers-work-again/","summary":"\u003cp\u003eI synced both \u003ca href=\"https://github.com/gonzoua/vchiq-freebsd\"\u003evchiq-freebsd\u003c/a\u003e and \u003ca href=\"https://github.com/gonzoua/userland\"\u003euserland\u003c/a\u003e to latest and greatest.\u003c/p\u003e\n\u003cp\u003eAs I mentioned earlier - OS compatibility shim was removed from upstream sources so I had to create Linux KPI implementation layer which turned out not that awful task because I managed to reuse a lot of code from Max Khon\u0026rsquo;s \u003ca href=\"http://freebsdfoundation.blogspot.com/2010/10/update-on-dahdi-project.html\"\u003eDAHDI port\u003c/a\u003e. I had to implement (in somewhat hackish fashion) kthread API, re-implement semaphores support using condvar and mutex in order to get _interruptible part of API working properly and create dumb implementation of rather small subset of Linux list.h API.\u003c/p\u003e","title":"VCHIQ drivers work again"},{"content":"I finally got around to setting up experimental pkgng repo for ARM in order to share packages with other ARM developers and users who feel adventurous. And man, was it simple. I have pandaboard that is super-fast comparing to Raspberri Pi so I use it for building ports. There were several installed so I just had to generate packages for them using\npkg create -a command. Then I uploaded all newly generated files to the server, grabbed packages built and shared by Stephen Hurd, removed duplicates with older versions and generated repo.txz by issuing\npkg repo command.\nThen on a raspberry pi I created pkg.conf in which I pointed to my newly created \u0026ldquo;repo\u0026rdquo;, updated metada and installed git:\n# echo \u0026#39;PACKAGESITE: http://people.freebsd.org/~gonzo/arm/pkg/\u0026#39; \u0026gt; /usr/local/etc/pkg.conf # pkg update # pkg install git Pi took some time to push files back and forth over NFS (I use NFS root on my devices) but eventually I got git with all dependencies up and running.\n!!! Please note that packages are not officially provided by FreeBSD Project. They\u0026rsquo;re only for experimental purpose so install them at your own discretion !!!\nThanks to bapt@ for working on this great tool.\n* - some ** - And for other ARM devices\n","permalink":"https://kernelnomicon.org/posts/packages-for-rasberry-pi/","summary":"\u003cp\u003eI finally got around to setting up experimental pkgng repo for ARM in order to share packages with other ARM developers and users who feel adventurous. And man, was it simple. I have pandaboard that is super-fast comparing to Raspberri Pi so I use it for building ports. There were several installed so I just had to generate packages for them using\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003epkg create -a\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003ecommand. Then I uploaded all newly generated files to the server, grabbed packages \u003ca href=\"http://lists.freebsd.org/pipermail/freebsd-arm/2012-December/004493.html\"\u003ebuilt and shared\u003c/a\u003e by Stephen Hurd, removed duplicates with older versions and generated repo.txz by issuing\u003c/p\u003e","title":"Packages(*) for Rasberry Pi(**)"},{"content":"Some time ago I announced port of VCHI driver to FreeBSD. Since then it was re-licensed as BSD/GPL and I had high hopes for bringing it into the tree as a part of sys/contrib. This weekend I finally got around to it but turned out things had changed for worse. VCHI driver used to have this neat OS-abstraction wrapper, so overall porting process was quite simple: implement synch primitives, physical pages management, driver-specific initialization and you\u0026rsquo;re done. But\u0026hellip; The layer was lost with driver update in October. The reason for it - OS compatibility shims are banned from Linux mainline kernel.\nSo now I face two options: create complete port of VCHI driver by replacing linux-specific parts with freebsd-specific code. Or create Linux compatibility shims and try to keep sources as close as possible to upstream. I\u0026rsquo;m going to try latter approach in order to minimize maintenance work. If it doesn\u0026rsquo;t work out - I\u0026rsquo;ll fall back to the former. But with any of these approaches code difference with upstream will be too significant to go to contrib tree and most likely driver will be distributed as a port.\n","permalink":"https://kernelnomicon.org/posts/vchi-driver-part-2/","summary":"\u003cp\u003eSome time ago I \u003ca href=\"http://kernelnomicon.org/?p=185\"\u003eannounced\u003c/a\u003e port of VCHI driver to FreeBSD. Since then it was re-licensed as BSD/GPL and I had high hopes for bringing it into the tree as a part of sys/contrib. This weekend I finally got around to it but  turned out things had changed for worse. VCHI driver used to have this neat OS-abstraction wrapper, so overall porting process was quite simple: implement synch primitives, physical pages management, driver-specific initialization and you\u0026rsquo;re done. But\u0026hellip; The layer was lost with driver update in October. The reason for it - \u003ca href=\"https://github.com/raspberrypi/firmware/issues/130\"\u003eOS compatibility shims are banned from Linux mainline kernel\u003c/a\u003e.\u003c/p\u003e","title":"VCHI driver, part 2"},{"content":"It\u0026rsquo;s been a while since last update on the project status so it might seem as there was no progress in this area. The reality is: there is a bunch of activities happening with various levels of success. So I decided to give kind of end-of-the-year round-up of ongoing projects, plans and obstacles ARM hackers face.\nFirst of all we tried switching default cache type from write-through to write-back type. It should have increased performance but instead opened a can of worms. Memory corruption debugging led to L2 cache driver on Pandaboard, EHCI driver code and subsequently to busdma code. Whole process took quite a few days full of hair-pulling and nagging various people and ended up in committing USB fixes and Ian Lepore\u0026rsquo;s busdma patches. PL310 (L2 cache controller) driver is being tested at this very moment. Original issue (WB caches) still stands and postponed till next year.\nThen there are two projects by Andrew Turner aimed at modernizing FreeBSD/armv6 subsystem: switching to EABI and clang support for ARM. Daisuke Aoyama took both of them and produced working image for Raspberry Pi. He also fixed two issues with event timers on Raspberry Pi so now the platform is much more stable. I ran buildkernel in a loop overnight and by the morning Pi had survived 7 cycles and still was alive and kicking. I also managed to get python built and working on it. Didn\u0026rsquo;t have 100% success with perl 5.14/5.16, ports were built but failed at install stage segfaulting in do_clean_objs function.\nMy Pandaboard survived overnight buildkernel loop with L2 cache disabled, but acting up if I enable it. Investigating.\nThen there are also several platform bring-ups in progress. Alexander Rybalko works on getting FreeBSD running on Efika MX Smartbook. Ganbold Tsagaankhuu hacks on Allwinner 10. Alexander Dutkowski\u0026rsquo;s hardware of choice is BeagleBoard-xM. Ruslan Bukin experiments with Exynos4412 and Thomas Skibo reported about FreeBSD running on Zedboard (Xilinx Zynq-7000).\nBut what about devices/platform we have in tree? I have limited knowledge about some platforms so here is summary of the ones I\u0026rsquo;m aware of. If you have more information on any of these targets (or any other ARM-related projects) - let me know, I\u0026rsquo;ll update post.\nBCM2835 Raspberry Pi the most accessible and therefore the one that gets the most exposure and testing. Pretty stable, considering. Supported devices: USB, network, MMC, GPIO, framebuffer, GPU. The rest is on ToDo list. VCHIQ driver is BSD-licensed now and I\u0026rsquo;m planning on getting it to sys/contrib. Userland bits of OpenGL ES should be added as a port though. (update) LPC32x0 No first hand experience but judging by the code it supports MMC, FB, GPIO and USB Marvel Armada XP I don\u0026rsquo;t have information about this one, sorry Nvidia Tegra2 Just barebone boot stuff. TI AM335x Examples: BeagleBone, TI Sitara EVM. Network was reported working but unstable on BeagleBone. USB is not supported. Haven\u0026rsquo;t tested GPIO yet. TI OMAP3 Example: BeagleBoard-xM. See Alexander Dutkowski\u0026rsquo;s project TI OMAP4 The hw I have - Pandaboard ES. Supported devices: USB, network, MMC, GPIO. Some issues with L2 cache Versatile Platform Board Exists only as emulation target for QEMU. Supported hardware: PCI, network, framebuffer. Seems to be fairly stable, no extensive testing performed. BeagleBone, PandaBoard ad Raspberry Pi images can be built using Tim Kientzle\u0026rsquo;s scripts.\nNot really stellar list of supported peripherals I\u0026rsquo;d say. I tend to blame several things.\nFirst - experimental and unstable state of FreeBSD/armv6 in general. It\u0026rsquo;s no fun adding new hardware support when you\u0026rsquo;re not confident in underlying subsystems stability. \u0026ldquo;I flush cache for this TX descriptor but is it really gets flushed?\u0026rdquo;. Been there, no fun at all. That\u0026rsquo;s why I believe task #1 for nearest future is maximum performance and rock-solid stability of what we have.\nThen there is the case of syscons. It\u0026rsquo;s old, it\u0026rsquo;s inflexible and it\u0026rsquo;s mostly i386-centric. Just until recently most of our so-called embedded targets were headless so there were no pressure from this side to reorganize things. My experience with coding two framebuffer drivers or trying to add PS/2 keyboard support on non-i386 platform was not very pleasant. It\u0026rsquo;s messy and there is a lot of code duplication. newsyscons project may be the way to go, I haven\u0026rsquo;t looked at it yet. We just need someone(tm) to finish it and get into the tree.\nFix these two issues should make bring-up process easier. It leaves us with question of GPU support. But it\u0026rsquo;s different story for different post\u0026hellip;\nHappy New Year, everybody!\n","permalink":"https://kernelnomicon.org/posts/freebsdarmv6-whats-new-and-exciting/","summary":"\u003cp\u003eIt\u0026rsquo;s been a while since last update on the project status so it might seem as there was no progress in this area. The reality is: there is a bunch of activities happening with various levels of success. So I decided to give kind of end-of-the-year round-up of ongoing projects, plans and obstacles ARM hackers face.\u003c/p\u003e\n\u003cp\u003eFirst of all we tried switching default cache type from write-through to write-back type. It should have increased performance but instead opened a can of worms. Memory corruption debugging led to L2 cache driver on Pandaboard, EHCI driver code and subsequently to busdma code. Whole process took quite a few days full of hair-pulling and nagging various people and ended up in committing USB fixes and Ian Lepore\u0026rsquo;s busdma patches. PL310 (L2 cache controller) driver is being tested at this very moment. Original issue (WB caches) still stands and postponed till next year.\u003c/p\u003e","title":"FreeBSD/armv6: what's new and exciting?"},{"content":"vchiq, kernel driver for interfacing ARM with VideoCore is now dual-licensed (BSD/GPL).\nReferences: https://github.com/raspberrypi/firmware/issues/40 https://github.com/raspberrypi/linux/commit/d21d26ebd773ab87888351220739b43a9733233a\n","permalink":"https://kernelnomicon.org/posts/broadcom-switched-vchiq-to-dual-license/","summary":"\u003cp\u003evchiq, kernel driver for interfacing ARM with VideoCore is now dual-licensed (BSD/GPL).\u003c/p\u003e\n\u003cp\u003eReferences:\n\u003ca href=\"https://github.com/raspberrypi/firmware/issues/40\"\u003ehttps://github.com/raspberrypi/firmware/issues/40\u003c/a\u003e\n\u003ca href=\"https://github.com/raspberrypi/linux/commit/d21d26ebd773ab87888351220739b43a9733233a\"\u003ehttps://github.com/raspberrypi/linux/commit/d21d26ebd773ab87888351220739b43a9733233a\u003c/a\u003e\u003c/p\u003e","title":"Broadcom switches vchiq to dual license"},{"content":"[QEMU 1.5 users see this update]\nFirst take at getting FreeBSD/armv6 running in simulators. Simulators are great for tracking down nasty bugs and building packages.\nSo here is support for Versatile Platform Board machine supported by QEMU. Most likely this code will not run on real VersatilePB because I do not have this hardware and timing code (or lack of it) on CLCD driver and Keyboard/Mouse interface (PL050) is pure guesswork.\nBack to gory details:\nBuild You\u0026rsquo;ll need this patch and this script. Apply patch, use script to get freebsd-versatilepb.flash.\nAs for userland - it\u0026rsquo;s fully compatible with Raspberry Pi\u0026rsquo;s userland, or Pandaboard\u0026rsquo;s one. So you can use latest RPi SD card image. As for now it\u0026rsquo;s freebsd-pi-r243778.img.gz (124Mb)\nRun QEMU I believe that at least QEMU 1.2.0 is required. It\u0026rsquo;s still 1.1.1 in ports due to some blockers that prevent upgrade to 1.3.0. This patch updates port to 1.3.0 and it worked for me. Also I tested images with QEMU on windows and OS X - works fine.\nqemu-system-arm -M versatilepb -m 128M -kernel freebsd-versatilepb.flash -cpu arm1176 -hda freebsd-pi-r243778.img Caveats Serial console is off by default, use graphics console. If you need headless mode, rebuild image with \u0026ldquo;device sc\u0026rdquo; and related options disabled or use prebuilt flash image for headless mode root device name is hardcoded so if you\u0026rsquo;re using some other image or building your own - be sure that\u0026rsquo;s ROOTDEV actually match real root Memory size is hardcoded - 128M. For getting this information run-time we\u0026rsquo;ll need uboot and ubldr added to boot chain Prebuilt kernels freebsd-versatilepb.flash (4Mb) freebsd-versatilepb-headless.flash (4Mb) MD5 (freebsd-versatilepb-headless.flash) = 24a41807bf94c5fec0565adcfef48678 MD5 (freebsd-versatilepb.flash) = 085dedae67895ac1d1a7c04c7cda8468\n","permalink":"https://kernelnomicon.org/posts/freebsdarmv6-in-qemu/","summary":"\u003cp\u003e\u003cstrong\u003e[QEMU 1.5 users see \u003ca href=\"http://kernelnomicon.org/?p=395\"\u003ethis update\u003c/a\u003e]\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eFirst take at getting FreeBSD/armv6 running in simulators. Simulators are great for tracking down nasty bugs and building packages.\u003c/p\u003e\n\u003cp\u003eSo here is support for Versatile Platform Board machine supported by QEMU. Most likely this code will not run on real VersatilePB because I do not have this hardware and timing code (or lack of it) on CLCD driver and Keyboard/Mouse interface (PL050) is pure guesswork.\u003c/p\u003e","title":"FreeBSD/armv6 in QEMU"},{"content":"Good news and bad news. Let\u0026rsquo;s start with good ones.\nDaisuke Aoyama tracked down what causes \u0026ldquo;Unrecognized filesystem type\u0026rdquo; error with some SD cards. It is U-Boot using High Speed mode. Root cause is still unknown but as a workaround I just disabled HS mode for SD card in u-boot and updated freebsd-uboot-20121129.tar.gz. Or alternatively you can get uboot-nohs.img and use it to replace uboot.img on your SD card.\nBad news are: installworld for cross-compiled FreeBSD is broken unless you\u0026rsquo;re doing it on the latest HEAD. The reason is utility called mtree(8). It is used to ensure that target filesystem permissions and owners/groups are correct. Owners and groups are described as usernames and group names, not as numeric UIDs/GUIDs and mtree uses getpwXXX family of routines to convert names to numeric values. See the problem already? If new system user is added to latest HEAD and you use old trusty FreeBSD 9.0, there is no way mtree would know about this user. NetBSD solved this problem by introducing -N command-line option that lets you point mtree to the target system\u0026rsquo;s master.passwd and groups. So we need to port this feature to FreeBSD in order to get proper cross-compilation environment. And that\u0026rsquo;s my plan for next few days.\nSo if you see something like this:\nmtree -eU -f /src/FreeBSD/head/etc/mtree/BSD.var.dist -p /mnt/var mtree: line 22: unknown user auditdistd *** [distrib-dirs] Error code 1 Either update to latest HEAD, use mergemaster -p or wait couple of days.\n","permalink":"https://kernelnomicon.org/posts/cross-compilation-hickups/","summary":"\u003cp\u003eGood news and bad news. Let\u0026rsquo;s start with good ones.\u003c/p\u003e\n\u003cp\u003eDaisuke Aoyama tracked down what causes \u0026ldquo;Unrecognized filesystem type\u0026rdquo; error with some SD cards. It is U-Boot using High Speed mode. Root cause is still unknown but as a workaround I just disabled HS mode for SD card in u-boot and updated freebsd-uboot-20121129.tar.gz. Or alternatively you can get \u003ca href=\"http://people.freebsd.org/~gonzo/arm/rpi/uboot-nohs.img\"\u003euboot-nohs.img\u003c/a\u003e and use it to replace uboot.img on your SD card.\u003c/p\u003e\n\u003cp\u003eBad news are: installworld for cross-compiled FreeBSD is broken unless you\u0026rsquo;re doing it on the latest HEAD. The reason is utility called mtree(8). It is used to ensure that target filesystem permissions and owners/groups are correct. Owners and groups are described as usernames and group names, not as numeric UIDs/GUIDs and mtree uses getpwXXX family of routines to convert names to numeric values. See the problem already? If new system user is added to latest HEAD and you use old trusty FreeBSD 9.0, there is no way mtree would know about this user. NetBSD solved this problem by introducing -N command-line option that lets you point mtree to the \u003cstrong\u003etarget\u003c/strong\u003e system\u0026rsquo;s master.passwd and groups. So we need to port this feature to FreeBSD in order to get proper cross-compilation environment. And that\u0026rsquo;s my plan for next few days.\u003c/p\u003e","title":"Cross-compilation hiccups"},{"content":"Long overdue update on how the things are going with FreeBSD on Raspberry Pi. We\u0026rsquo;ve made some good progress so far:\nHans Petter Selasky fixed low-speed interrupt endpoints problem which means we have working USB keyboard now GPIO driver by Luiz Otavio O Souza. So now you can blink OK LED (gpioctl -f /dev/gpioc0 -t 16). Not the most productive activity though. Kernel now obtains information about display resolution, memory layout, MAC address from firmware Framebuffer/syscons support added Some stability fixes for SDHCI/li\u0026gt; Initial port of VCHIQ interface (vchiq-freebsd) Port of userland libraries (userland) Overall stability and performance is still a problem, but it\u0026rsquo;s what we\u0026rsquo;re going to work on next.\nAnd if you missed previous post: freebsd-pi is no more, use HEAD from FreeBSD subversion repository.\nBoot process has been changed and now it looks like: firmware → uboot → ubldr → kernel. So old script for building image is no longer relevant. Here is new one. Tim Kientzle\u0026rsquo;s scripts collection for building images for BeagleBone, Pandaboard and RPi uses more systematic approach but RPi part hasn\u0026rsquo;t caught up to latest boot chain changes yet. Once it is up to date I suggest using Tim\u0026rsquo;s scripts.\nBuilding FreeBSD does not require any additional tools but if you want VideoCore bits you\u0026rsquo;ll need following packages installed:\ndevel/cmake devel/git devel/gmake If you don\u0026rsquo;t need VideoCore binaries, just comment build_videocore and install_videocore calls. This script will also install OpenGL ES hello_triangle demo to /root folder. To run it run perform following steps: `\ncd /root kldload vchiq ./hello_triangle.bin `\nI tried to build Qt5 with OpenGL ES support, but build choked on compile-time assert triggered by FreeBSD using OABI. Good news though: EABI work is almost done, so there is a fat chance we\u0026rsquo;ll see Qt5 with eglfs backend running on FreeBSD in near future.\nYou can try pre-built image (124Mb, MD5 sums). Login is \u0026ldquo;root\u0026rdquo;, no password. Use dd to write it to SD card. U-Boot seems to be somewhat finicky about SD cards, so if you get \u0026ldquo;** Unrecognized filesystem type **\u0026rdquo; message try another card. First boot might take some time because sshd will generate keys. U-Boot output goes to serial port and monitor, FreeBSD console messages go only to monitor, but by the end of boot sequence you should get login prompt on serial.\nThis image is a snapshot of work in progress and by no means a production system.\nUPDATE **** Unrecognized filesystem type **** U-Boot issue seems to be more widespread then I thought. I\u0026rsquo;m working on it.\n","permalink":"https://kernelnomicon.org/posts/freebsd-on-pi-more-stuff/","summary":"\u003cp\u003eLong overdue update on how the things are going with FreeBSD on Raspberry Pi. We\u0026rsquo;ve made some good progress so far:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eHans Petter Selasky fixed low-speed interrupt endpoints problem which means we have working USB keyboard now\u003c/li\u003e\n\u003cli\u003eGPIO driver by Luiz Otavio O Souza. So now you can blink OK LED (gpioctl -f /dev/gpioc0 -t 16). Not the most productive activity though.\u003c/li\u003e\n\u003cli\u003eKernel now obtains information about display resolution, memory layout, MAC address from firmware\u003c/li\u003e\n\u003cli\u003eFramebuffer/syscons support added\u003c/li\u003e\n\u003cli\u003eSome stability fixes for SDHCI/li\u0026gt;\nInitial port of VCHIQ interface (\u003ca href=\"https://github.com/gonzoua/vchiq-freebsd\"\u003evchiq-freebsd\u003c/a\u003e)\u003c/li\u003e\n\u003cli\u003ePort of userland libraries (\u003ca href=\"https://github.com/gonzoua/userland\"\u003euserland\u003c/a\u003e)\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eOverall stability and performance is still a problem, but it\u0026rsquo;s what we\u0026rsquo;re going to work on next.\u003c/p\u003e","title":"FreeBSD on Pi: more stuff"},{"content":"Ran into it recently and decided to post here just in case someone will have this problem too. Do not define both CONFIG_LOADADDR and loadaddr in CONFIG_EXTRA_ENV_SETTINGS. Otherwise environment variables enumeration API(API_ENV_ENUM) will loop forever.\n","permalink":"https://kernelnomicon.org/posts/u-boot-env-variables-iterator/","summary":"\u003cp\u003eRan into it recently and decided to post here just in case someone will have this problem too. Do not define both CONFIG_LOADADDR and loadaddr in CONFIG_EXTRA_ENV_SETTINGS. Otherwise environment variables enumeration API(API_ENV_ENUM) will loop forever.\u003c/p\u003e","title":"U-Boot env variables iterator"},{"content":"So, here is status update on the progress:\nfreebsd-pi github repo has been merged to HEAD and should be considered only as a reference from now on. I repackaged freebsd-pi-uboot-20120806-sd.tar.gz so tar should not complain about uid/guid stuff Hans Peter Selasky and Alexander Rybalko added host mode support for DWC OTG driver Problem with tty on serial port has been fixed. Use 3wire.115200 type for ttyu0 in /etc/ttys Still a lot of stuff to do though. P.S. I\u0026rsquo;ll post updated build script later.\n","permalink":"https://kernelnomicon.org/posts/freebsdpi-update/","summary":"\u003cp\u003eSo, here is status update on the progress:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003efreebsd-pi github repo has been merged to HEAD and should be considered only as a reference from now on.\u003c/li\u003e\n\u003cli\u003eI repackaged \u003ca href=\"http://people.freebsd.org/~gonzo/arm/rpi/freebsd-pi-uboot-20120806-sd.tar.gz\"\u003efreebsd-pi-uboot-20120806-sd.tar.gz\u003c/a\u003e so tar should not complain about uid/guid stuff\u003c/li\u003e\n\u003cli\u003eHans Peter Selasky and Alexander Rybalko added host mode support for DWC OTG driver\u003c/li\u003e\n\u003cli\u003eProblem with tty on serial port has been fixed. Use 3wire.115200 type for ttyu0 in /etc/ttys\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eStill a lot of stuff to do though.\nP.S.\nI\u0026rsquo;ll post updated build script later.\u003c/p\u003e","title":"FreeBSD/Pi update"},{"content":"ARMv6/AMRv7 support is now in main FreeBSD codebase.\nNew goodies:\nGeneral ARMv6/ARMv7 kernel bits (pmap, cache, assembler routines, etc\u0026hellip;) ARM SMP support VFP/Neon support ARM Generic Interrupt Controller driver Improved thread-local storage for cpus \u0026gt;=ARMv6 Two new values for TARGET_ARCH: armv6 and armv6eb Driver for SMSC LAN95XX and LAN8710A ethernet controllers Marvell MV78x60 support (multiuser, ARMADA XP kernel config) TI OMAP4 and AM335x support (multiuser, no GPU or graphics support, kernel configs for Pandaboard and Beaglebone) LPC32x0 support (multiuser, frame buffer works with SSD1289 LCD controller.Embedded Artists EA3250 kernel config) Barebone Nvidia Tegra2 support (timers, interrupts and UART. No kernel config) I\u0026rsquo;m going to re-create Raspberry Pi port off HEAD and start merging least intrusive bits back to the tree.\n","permalink":"https://kernelnomicon.org/posts/projectsarmv6-branch-is-no-more/","summary":"\u003cp\u003eARMv6/AMRv7 support is \u003ca href=\"http://lists.freebsd.org/pipermail/freebsd-hackers/2012-August/040263.html\"\u003enow in main FreeBSD codebase\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eNew goodies:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eGeneral ARMv6/ARMv7 kernel bits (pmap, cache,\nassembler routines, etc\u0026hellip;)\u003c/li\u003e\n\u003cli\u003eARM SMP support\u003c/li\u003e\n\u003cli\u003eVFP/Neon support\u003c/li\u003e\n\u003cli\u003eARM Generic Interrupt Controller driver\u003c/li\u003e\n\u003cli\u003eImproved thread-local storage for cpus \u0026gt;=ARMv6\u003c/li\u003e\n\u003cli\u003eTwo new values for TARGET_ARCH: armv6 and armv6eb\u003c/li\u003e\n\u003cli\u003eDriver for SMSC LAN95XX and LAN8710A ethernet controllers\u003c/li\u003e\n\u003cli\u003eMarvell MV78x60 support (multiuser, ARMADA XP kernel config)\u003c/li\u003e\n\u003cli\u003eTI OMAP4 and AM335x support (multiuser, no GPU or graphics\nsupport, kernel configs for Pandaboard and Beaglebone)\u003c/li\u003e\n\u003cli\u003eLPC32x0 support (multiuser, frame buffer works with SSD1289\nLCD controller.Embedded Artists EA3250 kernel config)\u003c/li\u003e\n\u003cli\u003eBarebone Nvidia Tegra2 support (timers, interrupts and UART.\nNo kernel config)\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eI\u0026rsquo;m going to re-create Raspberry Pi port off HEAD and start merging least intrusive bits back to the tree.\u003c/p\u003e","title":"projects/armv6 branch is no more"},{"content":"This instruction is no longer correct. New version is here Took some time but it seems we\u0026rsquo;re there too :)\nAlexander Rybalko, who works on USB drivers for the platform got remote telnet shell to the device: http://pastebin.com/6NqQLWD2\nHaving fixed serial console for userland applications (two lines change) and after some tweaking of SDHCI driver I got access to multiuser shell too: multiuser.txt Still not usable for putting together distros but stable enough for those who are willing to get their hands dirty with kernel side.\nHere is short how to on getting FreeBSD boot on Raspberry Pi:\nGet sources: git clone git://github.com/gonzoua/freebsd-pi.git cd freebsd-pi git checkout rpi Fetch u-boot files from here: freebsd-pi-uboot-20120806-sd.tar.gz.\nBuild sources and create SD card image with script like this: `#!/bin/sh set -e\nexport TARGET_ARCH=arm export SRCROOT=/usr/home/gonzo/Sources/freebsd-pi export MAKEOBJDIRPREFIX=/usr/home/gonzo/Sources/obj export KERNCONF=RPI-B KERNEL_BIN=`realpath $MAKEOBJDIRPREFIX`/arm.arm/`realpath $SRCROOT`/sys/$KERNCONF/kernel.bin\nmake -C $SRCROOT kernel-toolchain make -C $SRCROOT KERNCONF=$KERNCONF WITH_FDT=yes buildkernel make -C $SRCROOT TARGET_CPUTYPE=armv6 MALLOC_PRODUCTION=yes buildworld\nIMG=bsd-pi.img rm -f $IMG dd if=/dev/zero of=$IMG bs=128M count=8 MDFILE=`mdconfig -a -f bsd-pi.img` gpart create -s MBR ${MDFILE} gpart add -s 32m -t \u0026lsquo;!12\u0026rsquo; ${MDFILE} gpart add -s 896m -t \u0026lsquo;!12\u0026rsquo; ${MDFILE} gpart set -a active -i 1 ${MDFILE} newfs_msdos -L boot -F 16 /dev/${MDFILE}s1 newfs /dev/${MDFILE}s2 mount_msdosfs /dev/${MDFILE}s1 /mnt tar -x -v -z -C /mnt -f freebsd-uboot-sd.tar.gz cp $KERNEL_BIN /mnt umount /mnt mount /dev/${MDFILE}s2 /mnt make -C $SRCROOT DESTDIR=/mnt installworld make -C $SRCROOT DESTDIR=/mnt distribution\nMinimal config echo \u0026lsquo;hostname=\u0026ldquo;freebsd-pi\u0026rdquo;\u0026rsquo; \u0026gt; /mnt/etc/rc.conf echo \u0026lsquo;/dev/mmcsd0s2 / ufs rw 1 1\u0026rsquo; \u0026gt; /mnt/etc/fstab\numount /mnt mdconfig -d -u $MDFILE `\ndd image to SD card, insert it to Raspberry Pi and check serial port for some output\nThere is also U-Boot configuration that uses dhcp/tftp method by default freebsd-pi-uboot-20120806-netboot.tar.gz. It\u0026rsquo;s more suitable for kernel hacking but requires environment setup.\n","permalink":"https://kernelnomicon.org/posts/freebsdpi-setup-howto/","summary":"\u003ch3 id=\"this-instruction-is-no-longer-correct-new-version-is-here\"\u003eThis instruction is no longer correct. New version is \u003ca href=\"http://kernelnomicon.org/?p=275\"\u003ehere\u003c/a\u003e\u003c/h3\u003e\n\u003cp\u003eTook some time but it seems we\u0026rsquo;re there too :)\u003c/p\u003e\n\u003cp\u003eAlexander Rybalko, who works on USB drivers for the platform got remote telnet shell to the device: \u003ca href=\"http://pastebin.com/6NqQLWD2\"\u003ehttp://pastebin.com/6NqQLWD2\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eHaving fixed serial console for userland applications (two lines change) and after some tweaking of SDHCI driver I got access to multiuser shell too: \u003ca href=\"http://people.freebsd.org/~gonzo/arm/rpi/multiuser.txt\"\u003emultiuser.txt\u003c/a\u003e\nStill not usable for putting together distros but stable enough for those who are willing to get their hands dirty with kernel side.\u003c/p\u003e","title":"FreeBSD/Pi setup HowTo"},{"content":"NetBSD reached multiuser on Raspberry Pi! Congratulation to Nick Hudson and all involved.\nFreeBSD is not there yet, but we\u0026rsquo;re not slacking either:\n.\nWell, may be just a little. It\u0026rsquo;s not even single user yet. SDHC support is work in progress. No USB yet, hence no keyboard and no network. Just console output to framebuffer or serial port.\n","permalink":"https://kernelnomicon.org/posts/bsd-pi/","summary":"\u003cp\u003eNetBSD \u003ca href=\"http://mail-index.netbsd.org/port-arm/2012/07/13/msg001367.html\"\u003ereached multiuser\u003c/a\u003e on Raspberry Pi! Congratulation to Nick Hudson and all involved.\u003c/p\u003e\n\u003cp\u003eFreeBSD is not there yet, but we\u0026rsquo;re not slacking either:\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://imgur.com/8pgOk\"\u003e\u003cimg loading=\"lazy\" src=\"http://i.imgur.com/8pgOks.jpg\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e.\u003c/p\u003e\n\u003cp\u003eWell, may be just a little. It\u0026rsquo;s not even single user yet. SDHC support is work in progress. No USB yet, hence no keyboard and no network. Just console output to framebuffer or serial port.\u003c/p\u003e","title":"BSD Pi"},{"content":"New build for Raspberry Pi. ChangeLog:\nNew firmware Improved SD card performance Added USB mass storage devices support Added ext2 filesystem support (painfully slow with SD card, tolerable with USB memory stick) Tarball: raspberry-pi-uboot-20120707.tar.gz\nSD card image (32Mb): raspberry-pi-uboot-20120707.img\n","permalink":"https://kernelnomicon.org/posts/new-u-boot-build/","summary":"\u003cp\u003eNew build for Raspberry Pi. ChangeLog:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eNew firmware\u003c/li\u003e\n\u003cli\u003eImproved SD card performance\u003c/li\u003e\n\u003cli\u003eAdded USB mass storage devices support\u003c/li\u003e\n\u003cli\u003eAdded ext2 filesystem support (painfully slow with SD card, tolerable with USB memory stick)\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eTarball: \u003ca href=\"http://people.freebsd.org/~gonzo/arm/rpi/raspberry-pi-uboot-20120707.tar.gz\"\u003eraspberry-pi-uboot-20120707.tar.gz\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eSD card image (32Mb): \u003ca href=\"http://people.freebsd.org/~gonzo/arm/rpi/raspberry-pi-uboot-20120707.img\"\u003eraspberry-pi-uboot-20120707.img\u003c/a\u003e\u003c/p\u003e","title":"New U-Boot build"},{"content":"Yes, the last step. It doesn\u0026rsquo;t mean that I\u0026rsquo;m abandoning this project. Not at all. It just that it has reached the state I wanted it to reach from the very beginning: fairly stable, flexible u-boot distribution suitable to be used as an environment for OS bring-up. So now it\u0026rsquo;s time to get back to the original idea: get FreeBSD running on Raspberry Pi.\nSo, current state of affairs is raspberry-pi-uboot-20120621.tar.gz. It includes:\nUSB support SD card support (FAT filesystem) Support for built-in USB ethernet Autoimport environment from uEnv.txt Autorun of boot script (boot.scr) Known problems:\ntwo usb start in row without power cycle does not work USB transaction errors when USB device is plugged into R-Pi bootm command is not properly tested Of course there is place for improvements and there will be some bugfixes for this branch. I\u0026rsquo;ll prepare USB driver (and, probably, SDHC) for upstream but it will be background activity and my primary objective for nearest future will be FreeBSD on R-Pi.\n","permalink":"https://kernelnomicon.org/posts/u-boot-for-raspberry-pi-the-last-step/","summary":"\u003cp\u003eYes, the last step. It doesn\u0026rsquo;t mean that I\u0026rsquo;m abandoning this project. Not at all. It just that it has reached the state I wanted it to reach from the very beginning: fairly stable, flexible  u-boot distribution suitable to be used as an environment for OS bring-up. So now it\u0026rsquo;s time to get back to the original idea: get FreeBSD running on Raspberry Pi.\u003c/p\u003e\n\u003cp\u003eSo, current state of affairs is \u003ca href=\"http://people.freebsd.org/~gonzo/arm/rpi/raspberry-pi-uboot-20120621.tar.gz\"\u003eraspberry-pi-uboot-20120621.tar.gz\u003c/a\u003e. It includes:\u003c/p\u003e","title":"U-Boot for Raspberry Pi, the last step"},{"content":"Initial support for SD card has just been pushed to github repo.\nU-Boot 2012.04.01-00479-gb58d9ae-dirty (Jun 20 2012 - 11:47:13) DRAM: 128 MiB WARNING: Caches not enabled MMC: CAPS: 00000000 bcm2835_sdh: 0 Using default environment In: serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. U-Boot\u0026gt; mmcinfo Device: bcm2835_sdh Manufacturer ID: 1b OEM: 534d Name: 00000 Tran Speed: 25000000 Rd Block Len: 512 SD version 2.0 High Capacity: No Capacity: 1.9 GiB Bus Width: 4-bit U-Boot\u0026gt; fatls mmc 0 16528 bootcode.bin 127 cmdline.txt 314691 loader.bin 2047848 start.elf 181196 kernel.img 5 file(s), 0 dir(s) U-Boot\u0026gt; ","permalink":"https://kernelnomicon.org/posts/u-boot-for-raspberry-pi-step-8-sdhc-support/","summary":"\u003cp\u003eInitial support for SD card has just been pushed to github repo.\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-gdscript3\" data-lang=\"gdscript3\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eU\u003cspan style=\"color:#f92672\"\u003e-\u003c/span\u003eBoot \u003cspan style=\"color:#ae81ff\"\u003e2012.04\u003c/span\u003e\u003cspan style=\"color:#f92672\"\u003e.\u003c/span\u003e\u003cspan style=\"color:#ae81ff\"\u003e01\u003c/span\u003e\u003cspan style=\"color:#f92672\"\u003e-\u003c/span\u003e\u003cspan style=\"color:#ae81ff\"\u003e00479\u003c/span\u003e\u003cspan style=\"color:#f92672\"\u003e-\u003c/span\u003egb58d9ae\u003cspan style=\"color:#f92672\"\u003e-\u003c/span\u003edirty (Jun \u003cspan style=\"color:#ae81ff\"\u003e20\u003c/span\u003e \u003cspan style=\"color:#ae81ff\"\u003e2012\u003c/span\u003e \u003cspan style=\"color:#f92672\"\u003e-\u003c/span\u003e \u003cspan style=\"color:#ae81ff\"\u003e11\u003c/span\u003e:\u003cspan style=\"color:#ae81ff\"\u003e47\u003c/span\u003e:\u003cspan style=\"color:#ae81ff\"\u003e13\u003c/span\u003e)\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eDRAM:  \u003cspan style=\"color:#ae81ff\"\u003e128\u003c/span\u003e MiB\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eWARNING: Caches \u003cspan style=\"color:#f92672\"\u003enot\u003c/span\u003e enabled\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eMMC:   CAPS: \u003cspan style=\"color:#ae81ff\"\u003e00000000\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ebcm2835_sdh: \u003cspan style=\"color:#ae81ff\"\u003e0\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eUsing default environment\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eIn:    serial\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eOut:   serial\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eErr:   serial\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eNet:   Net Initialization Skipped\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eNo ethernet found\u003cspan style=\"color:#f92672\"\u003e.\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eU\u003cspan style=\"color:#f92672\"\u003e-\u003c/span\u003eBoot\u003cspan style=\"color:#f92672\"\u003e\u0026gt;\u003c/span\u003e mmcinfo\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eDevice: bcm2835_sdh\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eManufacturer ID: \u003cspan style=\"color:#ae81ff\"\u003e1\u003c/span\u003eb\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eOEM: \u003cspan style=\"color:#ae81ff\"\u003e534\u003c/span\u003ed\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eName: \u003cspan style=\"color:#ae81ff\"\u003e00000\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eTran Speed: \u003cspan style=\"color:#ae81ff\"\u003e25000000\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eRd Block Len: \u003cspan style=\"color:#ae81ff\"\u003e512\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eSD version \u003cspan style=\"color:#ae81ff\"\u003e2.0\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eHigh Capacity: No\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eCapacity: \u003cspan style=\"color:#ae81ff\"\u003e1.9\u003c/span\u003e GiB\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eBus Width: \u003cspan style=\"color:#ae81ff\"\u003e4\u003c/span\u003e\u003cspan style=\"color:#f92672\"\u003e-\u003c/span\u003ebit\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eU\u003cspan style=\"color:#f92672\"\u003e-\u003c/span\u003eBoot\u003cspan style=\"color:#f92672\"\u003e\u0026gt;\u003c/span\u003e fatls mmc \u003cspan style=\"color:#ae81ff\"\u003e0\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    \u003cspan style=\"color:#ae81ff\"\u003e16528\u003c/span\u003e   bootcode\u003cspan style=\"color:#f92672\"\u003e.\u003c/span\u003ebin\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e      \u003cspan style=\"color:#ae81ff\"\u003e127\u003c/span\u003e   cmdline\u003cspan style=\"color:#f92672\"\u003e.\u003c/span\u003etxt\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e   \u003cspan style=\"color:#ae81ff\"\u003e314691\u003c/span\u003e   loader\u003cspan style=\"color:#f92672\"\u003e.\u003c/span\u003ebin\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  \u003cspan style=\"color:#ae81ff\"\u003e2047848\u003c/span\u003e   start\u003cspan style=\"color:#f92672\"\u003e.\u003c/span\u003eelf\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e   \u003cspan style=\"color:#ae81ff\"\u003e181196\u003c/span\u003e   kernel\u003cspan style=\"color:#f92672\"\u003e.\u003c/span\u003eimg\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#ae81ff\"\u003e5\u003c/span\u003e file(s), \u003cspan style=\"color:#ae81ff\"\u003e0\u003c/span\u003e dir(s)\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eU\u003cspan style=\"color:#f92672\"\u003e-\u003c/span\u003eBoot\u003cspan style=\"color:#f92672\"\u003e\u0026gt;\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e","title":"U-Boot for Raspberry Pi, step 8: SDHC support"},{"content":"More progress on the subject:\nI cleaned up sources and pushed new version to github. Stephen Warren submitted patches for R-Pi support to U-Boot mailing list here and here. His version is much cleaner so I spent some time combining his patches with ported USB driver. So now target is called rpi_b and you should use \u0026ldquo;make rpi_b_config\u0026rdquo; instead of \u0026ldquo;make raspberry_pi_config\u0026rdquo; step when building U-Boot from sources. Pre-built binaries are available for download here. ","permalink":"https://kernelnomicon.org/posts/u-boot-for-raspberry-pi-step-7-cleanup/","summary":"\u003cp\u003eMore progress on the subject:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eI cleaned up sources and pushed new version to github.\u003c/li\u003e\n\u003cli\u003eStephen Warren submitted patches for R-Pi support to U-Boot mailing list \u003ca href=\"http://lists.denx.de/pipermail/u-boot/2012-June/125834.html\"\u003ehere\u003c/a\u003e and \u003ca href=\"http://lists.denx.de/pipermail/u-boot/2012-June/125835.html\"\u003ehere\u003c/a\u003e. His version is much cleaner so I spent some time combining his patches with ported USB driver. So now target is called rpi_b and you should use \u0026ldquo;make rpi_b_config\u0026rdquo; instead of \u0026ldquo;make raspberry_pi_config\u0026rdquo; step when building U-Boot from sources.\u003c/li\u003e\n\u003cli\u003ePre-built binaries are available for download \u003ca href=\"http://people.freebsd.org/~gonzo/arm/rpi/rpi-uboot.tar.gz\"\u003ehere\u003c/a\u003e.\u003c/li\u003e\n\u003c/ul\u003e","title":"U-Boot for Raspberry Pi, step 7: cleanup"},{"content":"And finally it works!\nU-Boot 2012.04.01-00306-gecc6e3d-dirty (Jun 15 2012 - 19:05:09) DRAM: 128 MiB WARNING: Caches not enabled Using default environment In: serial Out: serial Err: serial Net: No ethernet found. Raspberry-Pi # usb start (Re)start USB... USB: Core Release: 2.80a scanning bus for devices... 3 USB Device(s) found scanning bus for ethernet devices... 1 Ethernet Device(s) found Raspberry-Pi # dhcp Waiting for Ethernet connection... done. BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 28 *** Unhandled DHCP Option in OFFER/ACK: 28 DHCP client bound to address 192.168.10.21 Using sms0 device TFTP from server 192.168.10.1; our IP address is 192.168.10.21 Filename \u0026#39;kernel.RPI\u0026#39;. Load address: 0x700000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ###################################################### done Bytes transferred = 4597674 (4627aa hex) Raspberry-Pi # ping 192.168.10.1 Waiting for Ethernet connection... done. Using sms0 device host 192.168.10.1 is alive Raspberry-Pi # ","permalink":"https://kernelnomicon.org/posts/u-boot-for-raspberry-pi-step-6-it-lives/","summary":"\u003cp\u003eAnd finally it works!\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eU-Boot 2012.04.01-00306-gecc6e3d-dirty (Jun 15 2012 - 19:05:09)\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eDRAM:  128 MiB\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eWARNING: Caches not enabled\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eUsing default environment\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eIn:    serial\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eOut:   serial\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eErr:   serial\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eNet:   No ethernet found.\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eRaspberry-Pi # usb start\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e(Re)start USB...\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eUSB:   Core Release: 2.80a\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003escanning bus for devices... 3 USB Device(s) found\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e       scanning bus for ethernet devices... 1 Ethernet Device(s) found\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eRaspberry-Pi # dhcp\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eWaiting for Ethernet connection... done.\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eBOOTP broadcast 1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e*** Unhandled DHCP Option in OFFER/ACK: 28\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e*** Unhandled DHCP Option in OFFER/ACK: 28\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eDHCP client bound to address 192.168.10.21\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eUsing sms0 device\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eTFTP from server 192.168.10.1; our IP address is 192.168.10.21\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eFilename \u0026#39;kernel.RPI\u0026#39;.\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eLoad address: 0x700000\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eLoading: #################################################################\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         #################################################################\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         #################################################################\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         #################################################################\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         ######################################################\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003edone\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eBytes transferred = 4597674 (4627aa hex)\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eRaspberry-Pi # ping 192.168.10.1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eWaiting for Ethernet connection... done.\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eUsing sms0 device\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ehost 192.168.10.1 is alive\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eRaspberry-Pi #\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e","title":"U-Boot for Raspberry Pi, step 6: It lives!"},{"content":"OK. No visual progress, but short SitRep: I got control transfers working more stable and got bulk transfer somewhat working: U-Boot sends one packet and receives response, then all bulk transfers end up in STALL state. Investigating.\nBOOTP broadcast 1 ** smsc95xx_send(), len 342, buf 0x7e8db5e BULK -\u0026gt; \u0026lt;3,2\u0026gt; dev = 3 pipe = 2 buf = 07e8db5e size = 350 dir_out = 1 max_hc_xfer_size = 65535, max_hc_pkt_count = 511 xfer_len = 350, num_packets = 6, max = 64, buffer = 07e8db5e(07e8f490) Tx: len = 350, actual = 350, err = 0 ** smsc95xx_recv() BULK -\u0026gt; \u0026lt;3,1\u0026gt; dev = 3 pipe = 1 buf = 07fec698 size = 2048 dir_out = 0 max_hc_xfer_size = 65535, max_hc_pkt_count = 511 xfer_len = 2048, num_packets = 32, max = 64, buffer = 07fec698(07e8f490) Rx: len = 2048, actual = 368, err = 0 packet received packet received Receive from protocol 0x800 Got IP len=346, v=45 DHCPHandler: got packet: (src=67, dst=68, len=318) state: 3 Filtering pkt = 0 DHCPHandler: got DHCP packet: (src=67, dst=68, len=318) state: 3 DHCP: state=SELECTING bp_file: \u0026#34;kernel.RPI\u0026#34; TRANSITIONING TO REQUESTING STATE *** Unhandled DHCP Option in OFFER/ACK: 130 *** Unhandled DHCP Option in OFFER/ACK: 28 DhcpSendRequestPkt: Sending DHCPREQUEST Transmitting DHCPREQUEST packet: len = 342 ** smsc95xx_send(), len 342, buf 0x7e8dace BULK -\u0026gt; \u0026lt;3,2\u0026gt; dev = 3 pipe = 2 buf = 07e8dace size = 350 dir_out = 1 max_hc_xfer_size = 65535, max_hc_pkt_count = 511 xfer_len = 350, num_packets = 6, max = 64, buffer = 07e8dace(07e8f490) Channel halted Tx: len = 350, actual = 0, err = 0 BOOTP broadcast 2 ** smsc95xx_send(), len 342, buf 0x7e8db5e BULK -\u0026gt; \u0026lt;3,2\u0026gt; dev = 3 pipe = 2 buf = 07e8dace size = 350 dir_out = 1 max_hc_xfer_size = 65535, max_hc_pkt_count = 511 xfer_len = 350, num_packets = 6, max = 64, buffer = 07e8dace(07e8f490) Channel halted Tx: len = 350, actual = 0, err = 0 BOOTP broadcast 2 ** smsc95xx_send(), len 342, buf 0x7e8db5e BULK -\u0026gt; \u0026lt;3,2\u0026gt; dev = 3 pipe = 2 buf = 07e8db5e size = 350 dir_out = 1 max_hc_xfer_size = 65535, max_hc_pkt_count = 511 xfer_len = 350, num_packets = 6, max = 64, buffer = 07e8db5e(07e8f490) Channel halted Tx: len = 350, actual = 0, err = 0 ** smsc95xx_recv() BULK -\u0026gt; \u0026lt;3,1\u0026gt; dev = 3 pipe = 1 buf = 07fec698 size = 2048 dir_out = 0 max_hc_xfer_size = 65535, max_hc_pkt_count = 511 xfer_len = 2048, num_packets = 32, max = 64, buffer = 07fec698(07e8f490) HANG at line 533: 00000423 ","permalink":"https://kernelnomicon.org/posts/u-boot-on-raspberry-pi-step-5-more-usb-stuff/","summary":"\u003cp\u003eOK. No visual progress, but short SitRep: I got control transfers working more stable and got bulk transfer somewhat working: U-Boot sends one packet and receives response, then all bulk transfers end up in STALL state. Investigating.\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eBOOTP broadcast 1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e** smsc95xx_send(), len 342, buf 0x7e8db5e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eBULK -\u0026gt; \u0026lt;3,2\u0026gt;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003edev = 3 pipe = 2 buf = 07e8db5e size = 350 dir_out = 1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003emax_hc_xfer_size = 65535, max_hc_pkt_count = 511\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003exfer_len = 350, num_packets = 6, max = 64, buffer = 07e8db5e(07e8f490)\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eTx: len = 350, actual = 350, err = 0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e** smsc95xx_recv()\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eBULK -\u0026gt; \u0026lt;3,1\u0026gt;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003edev = 3 pipe = 1 buf = 07fec698 size = 2048 dir_out = 0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003emax_hc_xfer_size = 65535, max_hc_pkt_count = 511\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003exfer_len = 2048, num_packets = 32, max = 64, buffer = 07fec698(07e8f490)\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eRx: len = 2048, actual = 368, err = 0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003epacket received\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003epacket received\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eReceive from protocol 0x800\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eGot IP\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003elen=346, v=45\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eDHCPHandler: got packet: (src=67, dst=68, len=318) state: 3\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eFiltering pkt = 0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eDHCPHandler: got DHCP packet: (src=67, dst=68, len=318) state: 3\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eDHCP: state=SELECTING bp_file: \u0026#34;kernel.RPI\u0026#34;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eTRANSITIONING TO REQUESTING STATE\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e*** Unhandled DHCP Option in OFFER/ACK: 130\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e*** Unhandled DHCP Option in OFFER/ACK: 28\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eDhcpSendRequestPkt: Sending DHCPREQUEST\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eTransmitting DHCPREQUEST packet: len = 342\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e** smsc95xx_send(), len 342, buf 0x7e8dace\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eBULK -\u0026gt; \u0026lt;3,2\u0026gt;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003edev = 3 pipe = 2 buf = 07e8dace size = 350 dir_out = 1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003emax_hc_xfer_size = 65535, max_hc_pkt_count = 511\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003exfer_len = 350, num_packets = 6, max = 64, buffer = 07e8dace(07e8f490)\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eChannel halted\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eTx: len = 350, actual = 0, err = 0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eBOOTP broadcast 2\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e** smsc95xx_send(), len 342, buf 0x7e8db5e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eBULK -\u0026gt; \u0026lt;3,2\u0026gt;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003edev = 3 pipe = 2 buf = 07e8dace size = 350 dir_out = 1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003emax_hc_xfer_size = 65535, max_hc_pkt_count = 511\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003exfer_len = 350, num_packets = 6, max = 64, buffer = 07e8dace(07e8f490)\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eChannel halted\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eTx: len = 350, actual = 0, err = 0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eBOOTP broadcast 2\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e** smsc95xx_send(), len 342, buf 0x7e8db5e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eBULK -\u0026gt; \u0026lt;3,2\u0026gt;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003edev = 3 pipe = 2 buf = 07e8db5e size = 350 dir_out = 1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003emax_hc_xfer_size = 65535, max_hc_pkt_count = 511\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003exfer_len = 350, num_packets = 6, max = 64, buffer = 07e8db5e(07e8f490)\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eChannel halted\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eTx: len = 350, actual = 0, err = 0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e** smsc95xx_recv()\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eBULK -\u0026gt; \u0026lt;3,1\u0026gt;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003edev = 3 pipe = 1 buf = 07fec698 size = 2048 dir_out = 0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003emax_hc_xfer_size = 65535, max_hc_pkt_count = 511\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003exfer_len = 2048, num_packets = 32, max = 64, buffer = 07fec698(07e8f490)\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eHANG at line 533: 00000423\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e","title":"U-Boot on Raspberry Pi, step 5: More USB stuff"},{"content":"After rather busy weekend I finally got control transaction support for DWC OTG controller working on Raspberry Pi. U-Boot DWC OTG driver is cut-down version of Linux driver that works in polling mode. Stability is not very good at the moment though. And make sure to use latest firmware files. It does matter.\nNext step - bulk transactions.\nRepo: https://github.com/gonzoua/u-boot-pi\nRaspberry-Pi # usb info 1: Hub, USB Revision 1.10 - DWC OTG RootHub - Class: Hub - PacketSize: 8 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 0.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms 2: Hub, USB Revision 2.0 - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0424 Product 0x9512 Version 2.0 Configuration: 1 - Interfaces: 1 Self Powered Remote Wakeup 2mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 1 Interval 255ms 3: Vendor specific, USB Revision 2.0 - Class: Vendor specific - PacketSize: 64 Configurations: 1 - Vendor: 0x0424 Product 0xec00 Version 2.0 Configuration: 1 - Interfaces: 1 Self Powered Remote Wakeup 2mA Interface: 0 - Alternate Setting 0, Endpoints: 3 - Class Vendor specific - Endpoint 1 In Bulk MaxPacket 64 - Endpoint 2 Out Bulk MaxPacket 64 - Endpoint 3 In Interrupt MaxPacket 16 Interval 1ms ","permalink":"https://kernelnomicon.org/posts/u-boot-on-raspberry-pi-step-4-dwc-otg-control-transactions/","summary":"\u003cp\u003eAfter rather busy weekend I finally got control transaction support for DWC OTG controller working on Raspberry Pi. U-Boot DWC OTG driver is cut-down version of Linux driver that works in polling mode. Stability is not very good at the moment though. And make sure to use latest firmware files. It does matter.\u003c/p\u003e\n\u003cp\u003eNext step - bulk transactions.\u003c/p\u003e\n\u003cp\u003eRepo: \u003ca href=\"https://github.com/gonzoua/u-boot-pi\"\u003ehttps://github.com/gonzoua/u-boot-pi\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eRaspberry-Pi # usb info\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e1: Hub,  USB Revision 1.10\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e - DWC OTG RootHub\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e - Class: Hub\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e - PacketSize: 8  Configurations: 1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e - Vendor: 0x0000  Product 0x0000 Version 0.0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e   Configuration: 1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e   - Interfaces: 1 Self Powered 0mA\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     Interface: 0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     - Alternate Setting 0, Endpoints: 1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     - Class Hub\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e2: Hub,  USB Revision 2.0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e - Class: Hub\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e - PacketSize: 64  Configurations: 1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e - Vendor: 0x0424  Product 0x9512 Version 2.0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e   Configuration: 1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e   - Interfaces: 1 Self Powered Remote Wakeup 2mA\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     Interface: 0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     - Alternate Setting 0, Endpoints: 1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     - Class Hub\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     - Endpoint 1 In Interrupt MaxPacket 1 Interval 255ms\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e3: Vendor specific,  USB Revision 2.0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e - Class: Vendor specific\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e - PacketSize: 64  Configurations: 1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e - Vendor: 0x0424  Product 0xec00 Version 2.0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e   Configuration: 1\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e   - Interfaces: 1 Self Powered Remote Wakeup 2mA\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     Interface: 0\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     - Alternate Setting 0, Endpoints: 3\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     - Class Vendor specific\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     - Endpoint 1 In Bulk MaxPacket 64\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     - Endpoint 2 Out Bulk MaxPacket 64\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     - Endpoint 3 In Interrupt MaxPacket 16 Interval 1ms\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e","title":"U-Boot on Raspberry Pi, step 4: DWC OTG, Control transactions"},{"content":"Just a note to myself to keep useful info. Bakul Shah in freebsd-arm quotes R-Pi forum, but I failed to find original.\nStage 1 boot is in the on-chip ROM. Loads stage2 in the L2 cache! Stage 2 is bootcode.bin. Enables SDRAM and loads stage3 Stage 3 is loader.bin. Knows about elf format and load start.elf start.elf loads kernel.img (+ it is the main gpu code). It reads config.txt, cmdline.txt and bcm2835.dtb If the dtb file exists, it is loaded at 0x100 \u0026amp; kernel @ 0x8000 Else if disable_commandline_tags is set load kernel @ 0x0 Else if load kernel @ 0x8000 and put ATAGS at 0x100 See Issue 16 in https://github.com/raspberrypi/linux/issues kernel.img, is the first thing that runs on the ARM processor. And more information on config.txt here\n","permalink":"https://kernelnomicon.org/posts/r-pi-boot-process/","summary":"\u003cp\u003eJust a note to myself to keep useful info.\nBakul Shah in freebsd-arm quotes R-Pi forum, but I failed to find original.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003col\u003e\n\u003cli\u003eStage 1 boot is in the on-chip ROM. Loads stage2 in the L2 cache!\u003c/li\u003e\n\u003cli\u003eStage 2 is bootcode.bin. Enables SDRAM and loads stage3\u003c/li\u003e\n\u003cli\u003eStage 3 is loader.bin.  Knows about elf format and load start.elf\u003c/li\u003e\n\u003cli\u003estart.elf loads kernel.img (+ it is the main gpu code).\nIt reads config.txt, cmdline.txt and bcm2835.dtb\nIf the dtb file exists, it is loaded at 0x100 \u0026amp; kernel @ 0x8000\nElse if disable_commandline_tags is set load kernel @ 0x0\nElse if load kernel @ 0x8000 and put ATAGS at 0x100\nSee Issue 16 in \u003ca href=\"https://github.com/raspberrypi/linux/issues\"\u003ehttps://github.com/raspberrypi/linux/issues\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003ekernel.img, is the \u003cem\u003efirst\u003c/em\u003e thing that runs on the ARM\nprocessor.\u003c/li\u003e\n\u003c/ol\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eAnd more information on config.txt \u003ca href=\"http://elinux.org/RPi_config.txt\"\u003ehere\u003c/a\u003e\u003c/p\u003e","title":"R-Pi Boot process"},{"content":"Finally I received my female/male cables for inter-board connects (my soldering skill is close to zero) and got FTDI-based TTL/USB converter work. I had more luck with it then with my old trusty TTL/RS232 converter. No garbage in linux output, serial input works for u-boot.\nYou can find content of boot partition of SD-card I use here.\nFully functional serial port means that boot-over-serial should work and I do not need to move SD-card between R-Pi and card reader to get new version of u-boot running. So based on this post I managed to automate compile/run/fix cycle to some extent. Not C-Kermit expert here, so the script is lame but it does its work:\n#!/home/gonzo/bin/wermit # Serial port setup. These settings will likely need to be # changed to match the configuration of your workstation # and the ARM board you\u0026#39;re working with. set line /dev/ttyUSB3 set speed 115200 set serial 8n1 # General C-Kermit settings. These probably don\u0026#39;t need to change. set flow-control none set file type bin set carrier-watch off set prefixing all set modem none # load binary input 90 \u0026#34;Raspberry-Pi # \u0026#34; lineout \u0026#34;loadb 0x00000000\u0026#34; # This should be the absolute path to your kernel uImage file. send /home/gonzo/1/kernel.img # This command drops you into a console where you can interact # with the kernel. connect So now when I\u0026rsquo;m working on USB support for R-Pi the development cycle looks like this:\nHack-hack-hack, compile, generate kernel.img, place kernel.img to ~gonzo/1/ power-cycle board, run script Press Enter to trigger file upload and wait for this: ## Total Size = 0x0002b6d0 = 177872 Bytes ## Start Addr = 0x00000000 Issue go 0 command Issue usb start command, wait for results and start over ","permalink":"https://kernelnomicon.org/posts/u-boot-for-raspberry-pi-step-3/","summary":"\u003cp\u003eFinally I received my female/male cables for inter-board connects (my soldering skill is close to zero) and got FTDI-based TTL/USB converter work. I had more luck with it then with my old trusty TTL/RS232 converter. No garbage in linux output, serial input works for u-boot.\u003c/p\u003e\n\u003cp\u003eYou can find content of boot partition of SD-card I use \u003ca href=\"http://people.freebsd.org/~gonzo/r-pi/u-boot-pi.tar.gz\"\u003ehere\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eFully functional serial port means that boot-over-serial should work and I do not need to move SD-card between R-Pi and card reader to get new version of u-boot running. So based on \u003ca href=\"http://blog.mezeske.com/?p=483\"\u003ethis post\u003c/a\u003e I managed to automate compile/run/fix cycle to some extent. Not C-Kermit expert here, so the script is lame but it does its work:\u003c/p\u003e","title":"U-Boot for Raspberry Pi, step 3"},{"content":"I had some issues with console output from U-Boot on my R-Pi but Alexander Rybalko submitted patch that seems to fix them. One more issue that needed to be resolved: mysterious hangs in relocate_code. Some digging revealed that system hangs once PC reaches address 0x100. Some more digging yielded that at this address is used by GPU part of loader to store arguments for kernel.\nSo after tweaking .text offset for u-boot and generating proper image using this tool I finally got:\nmonitor len: 0001A14C ramsize: 08000000 Top of RAM usable for U-Boot at: 08000000 Reserving 104k for U-Boot at: 07fe5000 Reserving 1216k for malloc() at: 07eb5000 Reserving 32 Bytes for Board Info at: 07eb4fe0 Reserving 120 Bytes for Global Data at: 07eb4f68 New Stack Pointer is: 07eb4f58 RAM Configuration: Bank #0: 00000000 128 MiB relocation Offset is: 07fdd000 memcpy(07eb4f68, 03ffff80, 120) relocated relocate_code(07eb4f58, 07eb4f68, 07fe5000) WARNING: Caches not enabled monitor flash len: 00019124 Now running in RAM - U-Boot at: 07fe5000 Using default environment Destroy Hash Table: 07ffb58c table = (null) Create Hash Table: N=66 INSERT: table 07ffb58c, filled 1/67 rv 07eb5264 ==\u0026gt; name=\u0026#34;baudrate\u0026#34; value=\u0026#34;115200\u0026#34; INSERT: free(data = 07eb5008) INSERT: done In: serial Out: serial Err: serial Net: No ethernet found. Raspberry-Pi # Input doesn\u0026rsquo;t work yet though.\n","permalink":"https://kernelnomicon.org/posts/u-boot-for-raspberry-pi-step-2/","summary":"\u003cp\u003eI had some issues with console output from U-Boot on my R-Pi but Alexander Rybalko submitted patch that seems to fix them. One more issue that needed to be resolved: mysterious hangs in relocate_code. Some digging revealed that system hangs once PC reaches address 0x100. Some more digging yielded that at this address is used by GPU part of loader to store arguments for kernel.\u003c/p\u003e\n\u003cp\u003eSo after tweaking .text offset for u-boot and generating proper image using \u003ca href=\"https://github.com/raspberrypi/tools/tree/master/mkimage\"\u003ethis tool\u003c/a\u003e I finally got:\u003c/p\u003e","title":"U-Boot for Raspberry Pi, step 2"},{"content":"Thanks to Robert Watson I got my hands on brand new raspberry pi device (model B) and now trying to get FreeBSD running on it. That turned out to be non-trivial task. For one - there is no way to netboot the board. At least I failed to find it. It seems that initial Linux bring-up was done on evaluation modules with proper bootloader, JTAG support and whatnot and for public use limited boot loader was released. So instead porting FreeBSD on it I face the task of porting U-Boot. Which is not something entirely impossible.\nCPU support is already there. USB ethernet used in R-Pi is very similar to the one that is used on PandaBoard. So the major task is to add DWT OTG driver to U-Boot. But we\u0026rsquo;ll do it step by step.\nStep 1: Boot sequence.\nStock boot loader consists of three binary blobs: bootcode.bin, loader.bin, start.elf. I didn\u0026rsquo;t find exact description of boot process but what I figured so far: they\u0026rsquo;re not ARM binaries, they\u0026rsquo;re ran on GPU. start.elf is responsible for splitting memory between GPU and ARM core. There several versions of it, the only difference is amount of memory allocated for GPU. Details of the GPU part of the boot process are not essential. What is essential is that all these blobs are there to fetch kernel.img from boot partition, place it at physical address 0x00000000 and pass control to this address. The rest is up to instructions in the kernel.img file.\nStep 2: Hello world from U-Boot.\nAfter some hacking I finally got U-Boot printing \u0026ldquo;PI-BOOT\u0026rdquo; from arch_cpu_init. And ofter that it hangs somewhere in serial ports init function. Fun, fun, fun. Git repo: https://github.com/gonzoua/u-boot-pi/tree/rpi (rpi branch).\nBuilding: make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- raspberry_pi_config make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- Looks like boot loader does not like overwriting kernel.img so I created small script that just creates boot partition from scratch: rpi-deploy.sh. I use it on linux and there are some hardcoded values but it should give you the general idea of what needs to be done for deployment.\nMore steps to follow.\n","permalink":"https://kernelnomicon.org/posts/freebsd-on-raspberry-pi-baby-steps/","summary":"\u003cp\u003eThanks to Robert Watson I got my hands on brand new raspberry pi device (model B) and now trying to get FreeBSD running on it. That turned out to be non-trivial task. For one - there is no way to netboot the board. At least I failed to find it. It seems that initial Linux bring-up was done on evaluation modules with proper bootloader, JTAG support and whatnot and for public use limited boot loader was released. So instead porting FreeBSD on it I face the task of porting U-Boot. Which is not something entirely impossible.\u003c/p\u003e","title":"FreeBSD on Raspberry Pi: baby steps"},{"content":"Damjan Marion published nice how-to for getting FreeBSD running on BeagleBone. Using it I managed to get my PandaBoard ES running off SD card. The only modifications to this instructions are:\nUse PANDABOARD kernel config. Stock version is configured to use NFS so it should be modified to use SD card as root. MLO and u-boot.bin binaries are different. I used these. You\u0026rsquo;ll need boot.scr too. Performance is still affected by using write-through caches by default, but this issue should be fixed soon.\nboot log:\nU-Boot SPL 2011.09-rc2 (Oct 06 2011 - 17:56:54) Texas Instruments OMAP4460 ES1.1 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.bin mkimage signature not found - ih_magic = ea000014 Assuming u-boot.bin .. reading u-boot.bin U-Boot 2011.09-rc2 (Oct 06 2011 - 17:56:54) CPU : OMAP4430 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0 Using default environment In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 reading uEnv.txt ** Unable to read \u0026#34;uEnv.txt\u0026#34; from mmc 0:1 ** reading boot.scr 133 bytes read Loaded script from boot.scr Running bootscript from mmc0 ... ## Executing script at 82000000 reading kernel.bin 3634616 bytes read ## Starting application at 0x80200000 ... initarm: console initialized arg1 mdp = 0x00000000 boothowto = 0x00000000 dtbp = 0xc0552060 kernel image addresses: kernbase = 0xc0000000 _etext (sdata) = 0xc04cb00c _edata = 0xc05775b8 __bss_start = 0xc05775b8 _end = 0xc0595ef4 loader passed (static) kenv: no env, null ptr processing avail regions: 80000000-c0000000 -\u0026gt; 80000000-80200000 = 200000 8064b000-c0000000 -\u0026gt; 8064b000-c0000000 = 3f9b5000 fill in phys_avail: region: 0x80000000 - 0x80200000 (0x00200000) region: 0x8064b000 - 0xc0000000 (0x3f9b5000) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #123 r234390:234445M: Wed Apr 18 20:15:54 PDT 2012 gonzo@bsdbox:/src/FreeBSD/obj/armv6/arm.arm/src/FreeBSD/armv6/sys/PANDABOARD arm CPU: Cortex A9-r2 rev 10 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:1 LoUIS:2 Cache level 1: 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 4-way instruction cache Read-Alloc real memory = 1073741824 (1024 MB) avail memory = 1046401024 (997 MB) Texas Instruments OMAP4430 Processor, Revision ES2.3 random device not loaded; using insecure entropy simplebus0: \u0026lt;Flattened device tree simple bus\u0026gt; on fdtbus0 gic0: \u0026lt;ARM Generic Interrupt Controller\u0026gt; mem 0xe8241000-0xe8241fff,0xe8240100-0xe82401ff on simplebus0 gic0: pn 0x390, arch 0x1, rev 0x2, implementer 0x43b nirqs 160 l2cache0: \u0026lt;PL310 L2 cache controller\u0026gt; mem 0xe8242000-0xe8242fff on simplebus0 L2 Cache: 1024KB/32B 16 ways mp_tmr0: \u0026lt;ARM Generic MPCore Timers\u0026gt; mem 0xe8240200-0xe82402ff,0xe8240600-0xe82406ff irq 27,29 on simplebus0 Timecounter \u0026#34;ARM MPCore Timecouter\u0026#34; frequency 504000000 Hz quality 1000 Event timer \u0026#34;ARM MPCore Eventtimer\u0026#34; frequency 504000000 Hz quality 1000 uart0: \u0026lt;16750 or compatible\u0026gt; mem 0xe8020000-0xe8020fff irq 106 on simplebus0 uart0: console (115384,n,8,1) ti_scm0: \u0026lt;TI Control Module\u0026gt; mem 0xd4e6a000-0xd4e6afff on simplebus0 setting internal 4 for usbb1_ulpiphy_stp setting internal 10c for usbb1_ulpiphy_clk setting internal 10c for usbb1_ulpiphy_dir setting internal 10c for usbb1_ulpiphy_nxt setting internal 10c for usbb1_ulpiphy_dat0 setting internal 10c for usbb1_ulpiphy_dat1 setting internal 10c for usbb1_ulpiphy_dat2 setting internal 10c for usbb1_ulpiphy_dat3 setting internal 10c for usbb1_ulpiphy_dat4 setting internal 10c for usbb1_ulpiphy_dat5 setting internal 10c for usbb1_ulpiphy_dat6 setting internal 10c for usbb1_ulpiphy_dat7 omap4_prcm0: \u0026lt;TI OMAP Power, Reset and Clock Management\u0026gt; mem 0xd4e6b000-0xd4e6cfff,0xd4e6d000-0xd4e6dfff,0xd4e6e000-0xd4e75fff on simplebus0 gpio0: \u0026lt;TI General Purpose I/O (GPIO)\u0026gt; mem 0xd4e76000-0xd4e76fff,0xe8055000-0xe8055fff,0xe8057000-0xe8057fff,0xe8059000-0xe8059fff,0xe805b000-0xe805bfff,0xe805d000-0xe805dfff irq 61,62,63,64,65,66 on simplebus0 gpioc0: \u0026lt;GPIO controller\u0026gt; on gpio0 gpiobus0: \u0026lt;GPIO bus\u0026gt; on gpio0 ehci0: \u0026lt;TI OMAP USB 2.0 controller\u0026gt; mem 0xd4e77c00-0xd4e77cff,0xd4e78000-0xd4e786ff,0xd4e79000-0xd4e79fff irq 109 on simplebus0 ehci0: Starting TI EHCI USB Controller ehci0: UHH revision 0x50700100 ehci0: OMAP_UHH_SYSCONFIG: 0x00000014 ehci0: UHH setup done, uhh_hostconfig=0x8000001c usbus0: EHCI version 1.0 usbus0: \u0026lt;TI OMAP USB 2.0 controller\u0026gt; on ehci0 iichb0: \u0026lt;TI I2C Controller\u0026gt; mem 0xe8070000-0xe80700ff irq 88 on simplebus0 iichb0: I2C revision 4.0 iicbus0: \u0026lt;OFW I2C bus\u0026gt; on iichb0 iic0: \u0026lt;I2C generic I/O\u0026gt; on iicbus0 twl0: \u0026lt;TI TWL4030/TWL5030/TWL60x0/TPS659x0 Companion IC\u0026gt; on iicbus0 twl_vreg0: \u0026lt;TI TWL4030/TWL5030/TWL60x0/TPS659x0 Voltage Regulators\u0026gt; on twl0 ti_sdma0: \u0026lt;TI sDMA Controller\u0026gt; mem 0xd4e7a000-0xd4e7afff irq 44,45,46,47 on simplebus0 ti_sdma0: sDMA revision 00010900 ti_mmchs0: \u0026lt;TI MMC/SD/SDIO High Speed Interface\u0026gt; mem 0xe809c000-0xe809cfff irq 115 on simplebus0 mmc0: \u0026lt;MMC/SD bus\u0026gt; on ti_mmchs0 Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 twl0: Found (sub)device at 0x48 twl0: Found (sub)device at 0x49 twl0: Found (sub)device at 0x4a twl0: Found (sub)device at 0x4b ugen0.1: \u0026lt;Texas Instruments\u0026gt; at usbus0 uhub0: \u0026lt;Texas Instruments EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1\u0026gt; on usbus0 mmcsd0: 1886MB \u0026lt;SD Memory Card\u0026gt; at mmc0 30MHz/4bit Root mount waiting for: usbus0 Root mount waiting for: usbus0 uhub0: 3 ports with 3 removable, self powered Root mount waiting for: usbus0 ugen0.2: \u0026lt;vendor 0x0424\u0026gt; at usbus0 uhub1: \u0026lt;vendor 0x0424 product 0x9514, class 9/0, rev 2.00/1.00, addr 2\u0026gt; on usbus0 Root mount waiting for: usbus0 uhub1: 5 ports with 4 removable, self powered ugen0.3: \u0026lt;vendor 0x0424\u0026gt; at usbus0 smsc0: \u0026lt;vendor 0x0424 product 0xec00, rev 2.00/1.00, addr 3\u0026gt; on usbus0 Trying to mousmsc0: chip 0xec00, rev. 0001 nt root from ufs:mmcsd0s2 []... miibus0: \u0026lt;MII bus\u0026gt; on smsc0 ukphy0: \u0026lt;Generic IEEE 802.3u media interface\u0026gt; PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: \u0026lt;USB Ethernet\u0026gt; on smsc0 ue0: Ethernet address: 42:b5:1b:92:2f:fa warning: no time-of-day clock registered, system time will not be set accurately Setting hostuuid: 498c0afe-89d4-11e1-b9b6-42b51b922ffa. Setting hostid: 0x0b54866b. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/mmcsd0s2: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mmcsd0s2: clean, 405764 free (1988 frags, 50472 blocks, 0.4% fragmentation) Mounting local file systems:. Setting hostname: pandaboard. smsc0: chip 0xec00, rev. 0001 ue0: link state changed to DOWN Starting Network: lo0 ue0. lo0: flags=8049\u0026lt;UP,LOOPBACK,RUNNING,MULTICAST\u0026gt; metric 0 mtu 16384 options=3\u0026lt;RXCSUM,TXCSUM\u0026gt; inet 127.0.0.1 netmask 0xff000000 ue0: flags=8843\u0026lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST\u0026gt; metric 0 mtu 1500 options=80001\u0026lt;RXCSUM,LINKSTATE\u0026gt; ether 42:b5:1b:92:2f:fa media: Ethernet autoselect (none) status: no carrier Starting devd. ue0: link state changed to UP Starting dhclient. Can\u0026#39;t find free bpf: No such file or directory exiting. /etc/rc.d/dhclient: WARNING: failed to start dhclient Generating host.conf. Waiting 30s for the default route interface: ............................. Creating and/or trimming log files. Starting syslogd. /etc/rc: WARNING: Dump device does not exist. Savecore not run. ELF ldconfig path: /lib /usr/lib /usr/lib/compat Clearing /tmp (X related). Updating motd:. Generating public/private rsa1 key pair. Your identification has been saved in /etc/ssh/ssh_host_key. Your public key has been saved in /etc/ssh/ssh_host_key.pub. The key fingerprint is: fc:fa:d4:6c:ca:d3:c2:c5:ff:7c:05:e1:50:0c:5f:27 root@pandaboard The key\u0026#39;s randomart image is: +--[RSA1 1024]----+ | .+E o| | ..oo.| | o.. | | . o | | S . . | | . oo .| | .oo+. .| | ++o. ...| | ..+o .+| +-----------------+ Generating public/private dsa key pair. Your identification has been saved in /etc/ssh/ssh_host_dsa_key. Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: cd:16:3a:62:b7:9d:b0:4d:48:c3:93:d1:4a:6a:4f:56 root@pandaboard The key\u0026#39;s randomart image is: +--[ DSA 1024]----+ | .. | | ..oE | | o*o. | | o.+B . | | .o+S = | | . o.X . | | o + | | | | | +-----------------+ Generating public/private rsa key pair. Your identification has been saved in /etc/ssh/ssh_host_rsa_key. Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub. The key fingerprint is: 6b:03:e0:ef:28:66:01:cc:76:8a:88:70:f8:9b:a6:f2 root@pandaboard The key\u0026#39;s randomart image is: +--[ RSA 2048]----+ | | | | |o. . | |++.o . | |*+o . . S | |+.o . . . | | + . + | |. B o . . | |o*E.. . | +-----------------+ Generating public/private ecdsa key pair. Your identification has been saved in /etc/ssh/ssh_host_ecdsa_key. Your public key has been saved in /etc/ssh/ssh_host_ecdsa_key.pub. The key fingerprint is: e4:aa:df:df:d4:9d:19:83:42:79:79:18:b0:b8:cc:27 root@pandaboard The key\u0026#39;s randomart image is: +--[ECDSA 256]---+ | ... | | . o + | | .. + + . | | oo o . o | | SE o . o | | . o .. .=| | . . .o.| | . . o | | ... ... . | +-----------------+ Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Thu Apr 19 04:03:17 UTC 2012 FreeBSD/arm (pandaboard) (ttyu0) login: root Apr 19 04:03:23 pandaboard login: ROOT LOGIN (root) ON ttyu0 FreeBSD 10.0-CURRENT (PANDABOARD) #123 r234390:234445M: Wed Apr 18 20:15:54 PDT 2012 Welcome to FreeBSD! Before seeking technical support, please use the following resources: o Security advisories and updated errata information for all releases are at http://www.FreeBSD.org/releases/ - always consult the ERRATA section for your release first as it\u0026#39;s updated frequently. o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and, along with the mailing lists, can be searched by going to http://www.FreeBSD.org/search/. If the doc package has been installed (or fetched via pkg_add -r lang-freebsd-doc, where lang is the 2-letter language code, e.g. en), they are also available formatted in /usr/local/share/doc/freebsd. If you still have a question or problem, please take the output of `uname -a\u0026#39;, along with any relevant error messages, and email it as a question to the questions@FreeBSD.org mailing list. If you are unfamiliar with FreeBSD\u0026#39;s directory layout, please refer to the hier(7) manual page. If you are not familiar with manual pages, type `man man\u0026#39;. Edit /etc/motd to change this login announcement. pandaboard# uname -a FreeBSD pandaboard 10.0-CURRENT FreeBSD 10.0-CURRENT #123 r234390:234445M: Wed Apr 18 20:15:54 PDT 2012 gonzo@bsdbox:/src/FreeBSD/obj/armv6/arm.arm/src/FreeBSD/armv6/sys/PANDABOARD arm pandaboard# ","permalink":"https://kernelnomicon.org/posts/freebsd-on-arm-devices/","summary":"\u003cp\u003eDamjan Marion published \u003ca href=\"http://people.freebsd.org/~dmarion/beaglebone/creating_bootable_sd_card/\"\u003enice how-to\u003c/a\u003e for getting FreeBSD running on BeagleBone. Using it I managed to get my PandaBoard ES running off SD card. The only modifications to this instructions are:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eUse PANDABOARD kernel config. Stock version is configured to use NFS so it should be modified to use SD card as root.\u003c/li\u003e\n\u003cli\u003eMLO and u-boot.bin binaries are different. I used \u003ca href=\"http://people.freebsd.org/~gonzo/pandaboard/\"\u003ethese\u003c/a\u003e. You\u0026rsquo;ll need boot.scr too.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003ePerformance is still affected by using write-through caches by default, but this issue should be fixed soon.\u003c/p\u003e","title":"FreeBSD on ARM devices"},{"content":"Today I soldered AVR32 adapter for Flyswatter JTAG. Actually it\u0026rsquo;s very simple task - just connect respective pins and make common ground wire. No capacitors, resistors or MOSFETs. Idea was to make it nice and neat but having bought wrong breadboard and soldered first headers in a wrong place I just let it flow and here it is:\nFrom aesthetics point of view suck, but it also works and it\u0026rsquo;s everything I need:\nInfo : JTAG tap: avr32.cpu tap/device found: 0x21e8203f (mfg: 0x01f, part: 0x1e82, ver: 0x2) Warn : JTAG tap: avr32.cpu UNEXPECTED: 0x21e8203f (mfg: 0x01f, part: 0x1e82, ver: 0x2)\n","permalink":"https://kernelnomicon.org/posts/flyswatter-jtag-and-avr32/","summary":"\u003cp\u003eToday I soldered AVR32 adapter for Flyswatter JTAG. Actually it\u0026rsquo;s very simple task - just connect respective pins and make common ground wire. No capacitors, resistors or MOSFETs. Idea was to make it nice and neat but having bought wrong breadboard and soldered first headers in a wrong place I just let it flow and here it is:\u003c/p\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"http://lh6.ggpht.com/_bTtZWrFtKsc/TF9749h_xnI/AAAAAAAAFYI/NgKmDdyq0_8/IMGP9940.JPG\"\u003e\u003c/p\u003e\n\u003cp\u003e \u003c/p\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"http://lh3.ggpht.com/_bTtZWrFtKsc/TF975cHy0SI/AAAAAAAAFYM/Uy6SNPtWw8Q/IMGP9941.JPG\"\u003e\u003c/p\u003e\n\u003cp\u003eFrom aesthetics point of view suck, but it also works and it\u0026rsquo;s everything I need:\u003c/p\u003e","title":"Flyswatter JTAG and AVR32"},{"content":"Back from the land of GUI software. I have bought one more Flyswatter JTAG recently and now have two boards connected to my home box. Unfortunately both Flyswatters got the same USB serial number so stock openocd opens only the first device it stumbles upon. Here is small patch that adds ft2232_index command to OpenOCD FTDI driver that allows to point at specific device to open. Works only with libftdi. In the same directory you can find my configs for AR71XX-based RouterStation Pro and Portwell\u0026rsquo;s CAM-0010 device based on Octeon CN3010\n","permalink":"https://kernelnomicon.org/posts/minor-openocd-fixes/","summary":"\u003cp\u003eBack from the land of GUI software. I have bought one more Flyswatter JTAG recently and now have two boards connected to my home box. Unfortunately both Flyswatters got the same USB serial number so stock openocd opens only the first device it stumbles upon. Here is \u003ca href=\"http://people.freebsd.org/~gonzo/openocd/ftdi_index.diff\"\u003esmall patch\u003c/a\u003e that adds ft2232_index command to OpenOCD FTDI driver that allows to point at specific device to open. Works only with libftdi.  In the same directory you can find my configs for AR71XX-based RouterStation Pro and Portwell\u0026rsquo;s CAM-0010 device based on Octeon CN3010\u003c/p\u003e","title":"Minor OpenOCD fixes"},{"content":"I\u0026rsquo;ve been through writing NIC driver 2.5 times. 0.5 was porting ADM5120 switch driver by Ruslan Ermilov and Vsevolod Lobko from NetBSD. The usual routine for this kind of thing is \u0026ldquo;take existing driver and rewrite it\u0026rdquo;, e.g. copy selected parts or remove unnecessary ones. So I decided that it would be nice to skip \u0026ldquo;remove\u0026rdquo; part of procedure next time.\nAll cards I had to deal with (\u0026ldquo;both\u0026rdquo; wouldn\u0026rsquo;t be that impressive here) had similar design save for registers layout and some quirks. I believe that vast majority of NICs have the same design to some extent: there are circular RX/TX rings of more or less similar structure, interrupt status/mask register, media settings registers, you name it. Not a rocket science.\nSo I took if_arge driver from Atheros AR71XX SoC and replaced hardware-dependent parts with FIXME comments. Also string \u0026ldquo;ARGE\u0026rdquo; was replaced to \u0026ldquo;ADAPTER\u0026rdquo; and \u0026ldquo;arge\u0026rdquo; to \u0026ldquo;adapter\u0026rdquo; so simple s/adapter/xyz/g and s/ADAPTER/XYZ/g would give us a half-baked source base for if_xyz driver.\nIt\u0026rsquo;s yet to be tested whether this approach would be of any good. I\u0026rsquo;m planning to try it in next few days :) Meanwhile you can check sources here.\n","permalink":"https://kernelnomicon.org/posts/writing-freebsd-nic-driver/","summary":"\u003cp\u003eI\u0026rsquo;ve been through writing NIC driver 2.5 times. 0.5 was porting ADM5120 switch driver by Ruslan Ermilov and Vsevolod Lobko from NetBSD. The usual routine for this kind of thing is \u0026ldquo;take existing driver and rewrite it\u0026rdquo;, e.g. copy selected parts or remove unnecessary ones. So I decided that it would be nice to skip \u0026ldquo;remove\u0026rdquo; part of procedure next time.\u003c/p\u003e\n\u003cp\u003eAll cards I had to deal with (\u0026ldquo;both\u0026rdquo; wouldn\u0026rsquo;t be that impressive here) had similar design save for registers layout and some quirks. I believe that vast majority of NICs have the same design to some extent: there are circular RX/TX rings of more or less similar structure, interrupt status/mask register, media settings registers, you name it. Not a rocket science.\u003c/p\u003e","title":"Writing FreeBSD NIC driver"},{"content":"Now I know a little bit more about clang. I can\u0026rsquo;t say it\u0026rsquo;s quite useful for MIPS yet, but it\u0026rsquo;s nice to see some progress in this field. My findings might be inaccurate and any corrections are welcome.\nNo proper cross-compilation so far. Clang team plans to do it \u0026ldquo;right way\u0026rdquo; but so far it\u0026rsquo;s just an item on their ToDo list: Universal driver. There are command-line options like -ccc-host-triple to get target assembler code, but names for assembler/linker are hardcoded to as/ld, which puts some restriction on building target toolchain UPD: -ccc-host-triple does the trick OK\nNo proper march/mabi handlers for MIPS platform. Only ARM and x86 are supported. I managed to build hello world application in semi-automatic mode on RouterStation booted over NFS:\n[root@ /llvm/llvm]# clang -v -fPIC -Wa,-mabi=32,-EB,-KPIC hello.c clang version 1.1 (trunk) Target: mips-unknown-freebsd9.0 Thread model: posix \u0026ldquo;/opt/bin/clang\u0026rdquo; -cc1 -triple mips-unknown-freebsd9.0 -S -disable-free -main-file-name hello.c -pic-level 2 -mdisable-fp-elim -v -resource-dir /opt/lib/clang/1.1 -fmessage-length 0 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-tuAxTl.s -x c hello.c clang -cc1 version 1.1 based upon llvm 2.7svn hosted on mips-unknown-freebsd9.0 #include \u0026ldquo;\u0026hellip;\u0026rdquo; search starts here: #include \u0026lt;\u0026hellip;\u0026gt; search starts here: /opt/lib/clang/1.1/include /usr/local/include /usr/include End of search list. \u0026ldquo;/usr/bin/as\u0026rdquo; -mabi=32 -EB -KPIC -o /tmp/cc-LZzHnl.o /tmp/cc-tuAxTl.s \u0026ldquo;/usr/bin/ld\u0026rdquo; \u0026ndash;eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o /tmp/cc-LZzHnl.o -lgcc \u0026ndash;as-needed -lgcc_s \u0026ndash;no-as-needed -lc -lgcc \u0026ndash;as-needed -lgcc_s \u0026ndash;no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o [root@ /llvm/llvm]# ./a.out Hello world! [root@ /llvm/llvm]# uname -a FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #28: Fri Jan 15 16:50:23 PST 2010 gonzo@figaro.bluezbox.com:/src/FreeBSD/obj/head-mips/mips/src/FreeBSD/head/sys/AR71XX mips [root@ /llvm/llvm]#\nSo it seems to be nice starting point for some minor compiler hacking :)\n","permalink":"https://kernelnomicon.org/posts/freebsdmips-clangllvm/","summary":"\u003cp\u003eNow I know a little bit more about clang. I can\u0026rsquo;t say it\u0026rsquo;s quite useful for MIPS yet, but it\u0026rsquo;s nice to see some progress in this field.  My findings might be inaccurate and any corrections are welcome.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eNo proper cross-compilation so far. Clang team plans to do it \u0026ldquo;right way\u0026rdquo; but so far it\u0026rsquo;s just an item on their ToDo list: \u003ca href=\"http://clang.llvm.org/UniversalDriver.html\"\u003eUniversal driver\u003c/a\u003e. There are command-line options like -ccc-host-triple  to get target assembler code, but names for assembler/linker are hardcoded to as/ld, which puts some restriction on building target toolchain\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eUPD: -ccc-host-triple does the trick OK\u003c/p\u003e","title":"FreeBSD/MIPS \u0026 clang/LLVM"},{"content":"All changes from projects/mips has been merged to HEAD. Kudos go to imp@ for sieving through mergeinfo mess projects/mips has been.\n","permalink":"https://kernelnomicon.org/posts/projectsmips-rip/","summary":"\u003cp\u003eAll changes from projects/mips has been merged to HEAD. Kudos go to imp@ for sieving through mergeinfo mess projects/mips has been.\u003c/p\u003e","title":"projects/mips RIP"},{"content":"Good news: LLVM builds fine on RouterStation Pro with root mounted over NFS.\nBad news: it segfaults on some tests and when trying to build hello world application.\nStay tuned\n","permalink":"https://kernelnomicon.org/posts/freebsdmips-and-llvm/","summary":"\u003cp\u003eGood news: LLVM builds fine on RouterStation Pro with root mounted over NFS.\u003c/p\u003e\n\u003cp\u003eBad news: it segfaults on some tests and when trying to build hello world application.\u003c/p\u003e\n\u003cp\u003eStay tuned\u003c/p\u003e","title":"FreeBSD/mips and LLVM"},{"content":"Since I lent my RS232/USB adapter to a friend it was nice opportunity to experiment with Flyswatter on-board RS232 port. OS X does not support FTDI devices out of the box, but it\u0026rsquo;s not a problem for OpenOCD, which uses generic interface to communicate JTAG board. Things get a little bit more complicated when you\u0026rsquo;re trying to get on-board RS232 port working.\nI started with installing stock drivers from FTDI site. Current version supports Snow Leopard. With these drivers installed system started to detect two COM ports but JTAG part stopped to work as OpenOCD failed to claim USB device.\nLong story short: you\u0026rsquo;ll need to edit kext content to prevent first usb device from being recognized as a virtual COM port. Nothing fancy, simple text editor would do the trick for all you need to edit is plain XML file. Find line FT2232C_A and delete it along with following element. Reload kext using kextunload/kextload and voila - JTAG works, \u0026ldquo;cu -s 115200 -l cu.usbserial-FS000000B\u0026rdquo; works.\n","permalink":"https://kernelnomicon.org/posts/os-x-flyswatter-jtag-rs232/","summary":"\u003cp\u003eSince I lent my RS232/USB adapter to a friend it was nice opportunity to experiment with Flyswatter on-board RS232 port. OS X does not support FTDI devices out of the box, but it\u0026rsquo;s not a problem for OpenOCD, which uses generic interface to communicate JTAG board. Things get a little bit more complicated when you\u0026rsquo;re trying to get on-board RS232 port working.\u003c/p\u003e\n\u003cp\u003eI started with installing stock drivers from \u003ca href=\"http://www.ftdichip.com/Drivers/VCP.htm\"\u003eFTDI site\u003c/a\u003e. Current version supports Snow Leopard. With these drivers installed system started to detect two COM ports but JTAG part stopped to work as OpenOCD failed to claim USB device.\u003c/p\u003e","title":"OS X: Flyswatter, JTAG \u0026 RS232"},{"content":"The best way to learn new technology is to use it. Here is a small project I\u0026rsquo;ve put together while learning Mac OS X/Cocoa development: AudioBookBinder, may be someone will find it useful. This utility takes collection of mp3 files (or any other audio format recognizable by OS X) and binds it to one audiobook(m4b file) suitable for listening on iPod. The initial idea was to make it a GUI app, but I\u0026rsquo;ve been spoiled with command line power for too long.\n","permalink":"https://kernelnomicon.org/posts/tasting-cocoa/","summary":"\u003cp\u003eThe best way to learn new technology is to use it. Here is a small project I\u0026rsquo;ve put together while learning Mac OS X/Cocoa development: \u003ca href=\"http://gonzo.kiev.ua/projects/audiobookbinder/\"\u003eAudioBookBinder\u003c/a\u003e, may be someone will find it useful. This utility takes collection of mp3 files (or any other audio format recognizable by OS X) and binds it to one audiobook(m4b file) suitable for listening on iPod. The initial idea was to make it a GUI app, but I\u0026rsquo;ve been spoiled with command line power for too long.\u003c/p\u003e","title":"Tasting Cocoa"},{"content":"Good news everyone! Last two days I\u0026rsquo;ve been testing FreeBSD/mips by running buildworld on netbooted RouterStation with root mounted over NFS. So far so good, it successfully completed twice.\nA couple of weeks ago arch-dependent part of libthr (both kernel and userland) was implemented and it seems to work. \u0026ldquo;Seems to work\u0026rdquo; means that it passes thr1 and thr2 tests from stress2 and python\u0026rsquo;s test_thread[ing].py. And yes, python and perl build fine on the same board from the ports do work. As bash et al :) Though perl should be built without Perl malloc but it\u0026rsquo;s on my ToDo list.\n","permalink":"https://kernelnomicon.org/posts/is-it-self-hosted-yet/","summary":"\u003cp\u003eGood news everyone! Last two days I\u0026rsquo;ve been testing FreeBSD/mips by running buildworld on netbooted \u003ca href=\"http://wiki.freebsd.org/FreeBSD/mips/UBNT-RouterStation\"\u003eRouterStation\u003c/a\u003e with root mounted over NFS. So far so good, it successfully completed twice.\u003c/p\u003e\n\u003cp\u003eA couple of weeks ago arch-dependent part of libthr (both kernel and userland) was implemented and it seems to work. \u0026ldquo;Seems to work\u0026rdquo; means that it passes thr1 and thr2 tests from stress2 and python\u0026rsquo;s test_thread[ing].py. And yes, python and perl build fine on the same board from the ports do work. As bash et al :) Though perl should be built without Perl malloc but it\u0026rsquo;s on my ToDo list.\u003c/p\u003e","title":"Is it self-hosted yet?"},{"content":"ohloh seems to be unable to grind FreeBSD\u0026rsquo;s svn repo. I\u0026rsquo;ve been watching for its efforts for several days now and commits progress meter resets from time to time:\nhttps://www.ohloh.net/p/freebsd/enlistments\n","permalink":"https://kernelnomicon.org/posts/ohloh-and-freebsd/","summary":"\u003cp\u003eohloh seems to be unable to grind FreeBSD\u0026rsquo;s svn repo. I\u0026rsquo;ve been watching for its efforts for several days now and commits progress meter resets from time to time:\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.ohloh.net/p/freebsd/enlistments\"\u003ehttps://www.ohloh.net/p/freebsd/enlistments\u003c/a\u003e\u003c/p\u003e","title":"ohloh and FreeBSD"},{"content":"http://people.freebsd.org/~gonzo/mips/routerstation.log\nSome issues still pending though. Cache management is major one. Things seemed to work fine in emulation but backfired into face with real hardware. I ran into several \u0026ldquo;random\u0026rdquo; bugs that were narrowed down to caches. More to go :( Also ethernet driver performance is low but it\u0026rsquo;s easier then hunting down ethereal cache matters. Or so I think.\nThis weekend will be dedicated to making openocd work with routerstation, learning debugging and profiling techniques for MIPS hardware and improving FreeBSD/MIPS pieces of DDB.\n","permalink":"https://kernelnomicon.org/posts/singleuser-on-routerstation/","summary":"\u003cp\u003e\u003ca href=\"http://people.freebsd.org/~gonzo/mips/routerstation.log\"\u003ehttp://people.freebsd.org/~gonzo/mips/routerstation.log\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eSome issues still pending though. Cache management is major one. Things seemed to work fine in emulation but backfired into face with real hardware. I ran into several \u0026ldquo;random\u0026rdquo; bugs that were narrowed down to caches. More to go :( Also ethernet driver performance is low but it\u0026rsquo;s easier then hunting down ethereal cache matters. Or so I think.\u003c/p\u003e\n\u003cp\u003eThis weekend will be dedicated to making openocd work with routerstation, learning debugging and profiling techniques for MIPS hardware and improving FreeBSD/MIPS pieces of DDB.\u003c/p\u003e","title":"singleuser on routerstation"},{"content":"Well, I was overly optimistic. OpenOCD can halt CPU, reset, examine registers and perform software breakpoints. Trying to figure out what\u0026rsquo;s wrong with EJTAG support I skimmed the code and the state of it is, well, poor. Current implementation assumes that target is of the same endianness as host. That\u0026rsquo;s why number of HW breakpoints/watchpoints was detected wrong. But even fixing (endianness and breakpoints) and implementing(watchpoints) in hack\u0026rsquo;n\u0026rsquo;slash mode didn\u0026rsquo;t help. I still can\u0026rsquo;t get bp/wp to work. But I\u0026rsquo;ll definitely try. May be next weekend.\n","permalink":"https://kernelnomicon.org/posts/more-on-openocd-and-mipsejtag/","summary":"\u003cp\u003eWell, I was overly optimistic. OpenOCD can halt CPU, reset, examine registers and perform software breakpoints. Trying to figure out what\u0026rsquo;s wrong with EJTAG support I skimmed the code and the state of it is, well, poor. Current implementation assumes that target is of the same endianness as host. That\u0026rsquo;s why number of HW breakpoints/watchpoints was detected wrong. But even fixing (endianness and breakpoints) and implementing(watchpoints) in hack\u0026rsquo;n\u0026rsquo;slash mode didn\u0026rsquo;t help. I still can\u0026rsquo;t get bp/wp to work. But I\u0026rsquo;ll definitely try. May be next weekend.\u003c/p\u003e","title":"More on OpenOCD and MIPS/EJTAG"},{"content":"As it was mentioned earlier now I have new cool toy to play with. Flyswatter JTAG with MIPS14 adapter. Though Tin Can Tools kindly warned me that OpenOCD did not support EJTAG/MIPS I decided to order it and it turned to be a good deal. Why? Because there is EJTAG/MIPS support for OpenOCD as of 0.1.0. Moreover it works really nice with FreeBSD port of libftdi. So all I had to do was to make devel/openocd port and tweak some configs. And that\u0026rsquo;s it. Stock gdb for MIPS is not ready yet, but one can attach, examine registers, single step using telnet interface to daemon:\n[gonzo@figaro:][~/FreeBSD] % telnet localhost 4444 Trying 127.0.0.1\u0026hellip; Connected to localhost. Escape character is \u0026lsquo;^]\u0026rsquo;. Open On-Chip Debugger\nhalt target state: halted target halted due to debug-request, pc: 0x8023b974 reg (0) zero (/32): 0x00000000 (dirty: 0, valid: 1) (1) at (/32): 0x802c0000 (dirty: 0, valid: 1) (2) v0 (/32): 0x00000001 (dirty: 0, valid: 1) (3) v1 (/32): 0x00000000 (dirty: 0, valid: 1) (4) a0 (/32): 0x00000000 (dirty: 0, valid: 1) (5) a1 (/32): 0x00000000 (dirty: 0, valid: 1) (6) a2 (/32): 0x80280b28 (dirty: 0, valid: 1) (7) a3 (/32): 0x00000602 (dirty: 0, valid: 1) (8) t0 (/32): 0x802c10b0 (dirty: 0, valid: 1) (9) t1 (/32): 0x00000000 (dirty: 0, valid: 1) (10) t2 (/32): 0x00000000 (dirty: 0, valid: 1) (11) t3 (/32): 0x00000000 (dirty: 0, valid: 1) (12) t4 (/32): 0x00000000 (dirty: 0, valid: 1) (13) t5 (/32): 0x00000001 (dirty: 0, valid: 1) (14) t6 (/32): 0x00000000 (dirty: 0, valid: 1) (15) t7 (/32): 0x00000000 (dirty: 0, valid: 1) (16) s0 (/32): 0xc082abe0 (dirty: 0, valid: 1) (17) s1 (/32): 0x801312a8 (dirty: 0, valid: 1) (18) s2 (/32): 0x00000000 (dirty: 0, valid: 1) (19) s3 (/32): 0xc0828b20 (dirty: 0, valid: 1) (20) s4 (/32): 0xc0793ea0 (dirty: 0, valid: 1) (21) s5 (/32): 0x00000000 (dirty: 0, valid: 1) (22) s6 (/32): 0x00000000 (dirty: 0, valid: 1) (23) s7 (/32): 0x00000000 (dirty: 0, valid: 1) (24) t8 (/32): 0x02887fa0 (dirty: 0, valid: 1) (25) t9 (/32): 0x00000002 (dirty: 0, valid: 1) (26) k0 (/32): 0x8024e3a0 (dirty: 0, valid: 1) (27) k1 (/32): 0x00000000 (dirty: 0, valid: 1) (28) gp (/32): 0x00000000 (dirty: 0, valid: 1) (29) sp (/32): 0xc0793e30 (dirty: 0, valid: 1) (30) fp (/32): 0x00000000 (dirty: 0, valid: 1) (31) ra (/32): 0x8023b964 (dirty: 0, valid: 1) (32) status (/32): 0x0000ff01 (dirty: 0, valid: 1) (33) lo (/32): 0x0000001c (dirty: 0, valid: 1) (34) hi (/32): 0x00000020 (dirty: 0, valid: 1) (35) badvaddr (/32): 0xc0797dc8 (dirty: 0, valid: 1) (36) cause (/32): 0x40008000 (dirty: 0, valid: 1) (37) pc (/32): 0x8023b974 (dirty: 0, valid: 1)\n","permalink":"https://kernelnomicon.org/posts/jtag-openocd-freebsd/","summary":"\u003cp\u003eAs it was \u003ca href=\"http://bsddev.blogspot.com/2009/02/wip-ubiquitys-router-station.html\"\u003ementioned earlier\u003c/a\u003e now I have new cool toy to play with. Flyswatter JTAG with MIPS14 adapter. Though Tin Can Tools kindly warned me that OpenOCD did not support EJTAG/MIPS I decided to order it and it turned to be a good deal. Why? Because there is EJTAG/MIPS support for OpenOCD as of 0.1.0. Moreover it works really nice with FreeBSD port of libftdi. So all I had to do was to make \u003ca href=\"http://people.freebsd.org/~gonzo/ports/openocd.tar\"\u003edevel/openocd\u003c/a\u003e port and tweak some configs. And that\u0026rsquo;s it. Stock gdb for MIPS is not ready yet, but one can attach, examine registers, single step using telnet interface to daemon:\u003c/p\u003e","title":"JTAG, OpenOCD \u0026 FreeBSD"},{"content":"My SCM of choice for FreeBSD-related projects is SVK (it\u0026rsquo;s much faster then subversion and provides offline access to repo history, easy branching/merging and so on). And my editor of choice is vim. And it turns out vim doesn\u0026rsquo;t highlight svk commit files. What a shame. No bright colors for happy hacker who is about to commit clean and robust code (or break buildworld, whatever). So I spent 20 minutes of tweaking svn.vim and produced this.\nIt\u0026rsquo;s a syntax file for svk-commit* and two functions to place file under/out of SVK control (just like in perforce one can tweak commit file to select which files will be committed and which won\u0026rsquo;t).\n","permalink":"https://kernelnomicon.org/posts/svk-vim/","summary":"\u003cp\u003eMy SCM of choice for FreeBSD-related projects is SVK (it\u0026rsquo;s much faster then subversion and provides offline access to repo history, easy branching/merging and so on). And my editor of choice is vim. And it turns out vim doesn\u0026rsquo;t highlight svk commit files. What a shame. No bright colors for happy hacker who is about to commit clean and robust code (or break buildworld, whatever).  So I spent 20 minutes of tweaking svn.vim and produced \u003ca href=\"http://www.vim.org/scripts/script.php?script_id=2604\"\u003ethis\u003c/a\u003e.\u003c/p\u003e","title":"svk \u0026 vim"},{"content":"So it has been a month since last post about this device and I think it\u0026rsquo;s time to announce current state of affairs.\nAt the moment further progress was blocked with something that looks like memory corruption. It\u0026rsquo;s hard to trace with ktr(4) and printf(9) so I ordered Flyswatter JTAG adapter and MIPS14 adapter from Tin Can Tools. I was warned that Flyswatter/MIPS combination is not supported by OpenOCD but I\u0026rsquo;d better spend some time making it work then tracing obscure memory corruptions in the wild.\n","permalink":"https://kernelnomicon.org/posts/wip-ubiquitys-router-station/","summary":"\u003cp\u003eSo it has been a month since last post about this device and I think it\u0026rsquo;s time to announce current state of affairs.\u003c/p\u003e\n\u003cp\u003eAt the moment further progress was blocked with something that looks like memory corruption. It\u0026rsquo;s hard to trace with ktr(4) and printf(9) so I ordered \u003ca href=\"http://www.tincantools.com/product.php?productid=16134\"\u003eFlyswatter JTAG adapter\u003c/a\u003e and \u003ca href=\"http://www.tincantools.com/product.php?productid=16145\u0026amp;cat=251\u0026amp;page=1\"\u003eMIPS14 adapter\u003c/a\u003e from Tin Can Tools. I was warned that Flyswatter/MIPS combination is not supported by OpenOCD but I\u0026rsquo;d better spend some time making it work then tracing obscure memory corruptions in the wild.\u003c/p\u003e","title":"WIP: Ubiquity's router station"},{"content":"Has just received two books from Amazon.\nThe first one is Beautiful Architecture by fellow FreeBSD developer Diomidis Spinellis and Georgios Gousios. I bought it because software design is not my strongest skill and there is a lot of place for improvement. And learning from real life examples is always better then reading pure theory.\nThe other one is The Productive Programmer by David Bock. Productivity is my sweet spot (well, it\u0026rsquo;s more about cool tips then real productivity boost). This had nice reviews so I decided to give it a try.\n","permalink":"https://kernelnomicon.org/posts/scheduled-for-reading/","summary":"\u003cp\u003eHas just received two books from Amazon.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://www.amazon.ca/Beautiful-Architecture-Diomidis-Spinellis/dp/059651798X/ref=sr_1_3?ie=UTF8\u0026amp;s=books\u0026amp;qid=1235435653\u0026amp;sr=8-3\"\u003e\u003cimg loading=\"lazy\" src=\"http://ecx.images-amazon.com/images/I/311e-9x8UQL._SL500_AA180_.jpg\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eThe first one is Beautiful Architecture by fellow FreeBSD developer Diomidis Spinellis and Georgios Gousios. I bought it because software design is not my strongest skill and there is a lot of place for improvement. And learning from real life examples is always better then reading pure theory.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://www.amazon.ca/Productive-Programmer-David-Bock/dp/0596519788/ref=pd_bxgy_b_img_b?ie=UTF8\u0026amp;qid=1235435653\u0026amp;sr=8-3\"\u003e\u003cimg loading=\"lazy\" src=\"http://ecx.images-amazon.com/images/I/61dx4Iu-fyL._SL500_AA240_.jpg\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eThe other one is The Productive Programmer by David Bock. Productivity is my sweet spot (well, it\u0026rsquo;s more about cool tips then real productivity boost). This had nice reviews so I decided to give it a try.\u003c/p\u003e","title":"Scheduled for reading"},{"content":"In last two months I\u0026rsquo;ve got two new toys: WGT634U from bms@ and Ubiquity Networks\u0026rsquo; Router Station 2 provided by manufacturer. The first one is Broadcom\u0026rsquo;s Sentry5 based and the second one is built on Atheros\u0026rsquo; AR7100 chip. As AR7100 is more advanced technology (and has less obscure design, at least it seams less obscure to me) I decided to pick up this low hanging fruit. So far so good: kernel boots, PCI bridge detects Atheros miniPCI wireless card. GigE driver is on its way.\n","permalink":"https://kernelnomicon.org/posts/freebsdmips-whats-cooking/","summary":"\u003cp\u003eIn last two months I\u0026rsquo;ve got two new toys: WGT634U from bms@ and Ubiquity Networks\u0026rsquo; Router Station 2 provided by manufacturer. The first one is Broadcom\u0026rsquo;s Sentry5 based and the second one is built on Atheros\u0026rsquo; AR7100 chip. As AR7100 is more advanced technology (and has less obscure design, at least it seams less obscure to me) I decided to pick up this low hanging fruit. So far so good: kernel boots, PCI bridge detects Atheros miniPCI wireless card. GigE driver is on its way.\u003c/p\u003e","title":"FreeBSD/mips: what's cooking"},{"content":"Finally I got my hands on new and shiny Lenovo Thinkpad T400. What can I say? It\u0026rsquo;s cool. My only complaint about T60 was its somewhat dim display (yes, I tried to save some money on this vital part and got punished). This time I ordered model with LED backlight and it\u0026rsquo;s worth every dime spent :)\nMy configuration also included Atheros wifi, built-in bluetooth, Intel GMA X4500 graphics (I\u0026rsquo;m not in games, really). Unfortunately 7.1 was able to run wifi. Newer HAL did the trick though and here I am: eating my own dog food - running -CURRENT on a workhorse.\nIntel graphics was kind of disappointment. I expected no problems with this integrated chipset but there were a lot. \u0026ldquo;Ghost\u0026rdquo; video output (or companion display) that was causing mplayer not to run in fullscreen mode (fixed with xrandr). With SWCursor option off text console is garbled when switching to it from X. mplayer is somewhat laggish in full screen mode :( I hope intel driver will be updated soon, meanwhile I\u0026rsquo;ll refrain from watching movies (it should boost my productivity :))\nUPD: It seems that Intel Video artifacts is due to unsymmetrical memory layout (I have 2G + 1G). Windows 7 is affected as well.\n","permalink":"https://kernelnomicon.org/posts/thinkpad-t400-and-freebsd/","summary":"\u003cp\u003eFinally I got my hands on new and shiny Lenovo Thinkpad T400. What can I say? It\u0026rsquo;s cool. My only complaint about T60 was its somewhat dim display (yes, I tried to save some money on this vital part and got punished). This time I ordered model with LED backlight and it\u0026rsquo;s worth every dime spent :)\u003c/p\u003e\n\u003cp\u003eMy configuration also included Atheros wifi, built-in bluetooth, Intel GMA X4500 graphics (I\u0026rsquo;m not in games, really). Unfortunately 7.1 was able to run wifi. Newer HAL did the trick though and here I am: eating my own dog food - running -CURRENT on a workhorse.\u003c/p\u003e","title":"Thinkpad T400 and FreeBSD"},{"content":"And again long pause in blogging. In this 4 months several things happened to me: I relocated to Vancouver, was interviewed and rejected by Microsoft (don\u0026rsquo;t know why they contacted me in the first place), met new people (philip@ and thompa@ among them), saw new places and even got some free time and learned to cook (it turned out to be fun!).\nBeing close(geographically) to PMC-Sierra, major MIPS vendor, I tried to contact them and ask for a donation for FreeBSD/MIPS project. Got no reply, though. Predictable result, but it\u0026rsquo;s better to try and fail then have never try at all.\nRelocations is ideal way to get rid of garbage that has been accumulated through years. Unfortunately Mikrotik RB532, ADM5120-based Edimax device and Linksys WRT54GL were in the \u0026ldquo;garbage\u0026rdquo; I had to left. So it\u0026rsquo;s kind of a loss. But life without wireless AP is miserable (don\u0026rsquo;t blame me, I\u0026rsquo;m just a geek) so new and shiny Linksys wrt160n was bought from nearest Future Shop. And I even managed to solder serial console to it. And it works. I\u0026rsquo;m really bad with soldering iron so it\u0026rsquo;s something I\u0026rsquo;m going to be proud of for the next two years. By the way the process has been documented.\nThough it took some efforts FreeBSD was successfully booted on it! Well, sort of successfully. But I\u0026rsquo;m making progress and going to keep you informed! Stay tuned!\n","permalink":"https://kernelnomicon.org/posts/freebsdmips-something-lost-something-gained/","summary":"\u003cp\u003eAnd again long pause in blogging. In this 4 months several things happened to me: I relocated to Vancouver, was interviewed and rejected by Microsoft (don\u0026rsquo;t know why they contacted me in the first place), met new people (philip@ and thompa@ among them), saw new places and even got some free time and learned to cook (it turned out to be fun!).\u003c/p\u003e\n\u003cp\u003eBeing close(geographically) to PMC-Sierra, major MIPS vendor, I tried to contact them and ask for a donation for FreeBSD/MIPS project. Got no reply, though. Predictable result, but it\u0026rsquo;s better to try and fail then have never try at all.\u003c/p\u003e","title":"FreeBSD/MIPS: something lost, something gained"},{"content":"While waiting for MIPS toolchain import to happen I entertain myself with bugbusting. You should try it sometime. GNATS jungle, small and large bugs are sneaking around, scent of rotten emails in the air. I don\u0026rsquo;t feel like hunting down large bugs. They\u0026rsquo;re dangerous beasts. It\u0026rsquo;s much better to deal with small ones. Pick a (one|two|three|up-to-twenty)-liner and fix it. Then you can bring it home, varnish it and eventually MFC it. Nice outdoor activity for developers :)\nPS\nThe first PR I\u0026rsquo;ve nailed: kern/123685.\n","permalink":"https://kernelnomicon.org/posts/the-joy-of-bugbusting/","summary":"\u003cp\u003eWhile waiting for MIPS toolchain import to happen I entertain myself with bugbusting. You should try it sometime. GNATS jungle, small and large bugs are sneaking around, scent of rotten emails in the air. I don\u0026rsquo;t feel like hunting down large bugs. They\u0026rsquo;re dangerous beasts. It\u0026rsquo;s much better to deal with small ones. Pick a (one|two|three|up-to-twenty)-liner and fix it. Then you can bring it home, varnish it and eventually MFC it. Nice outdoor activity for developers :)\u003c/p\u003e","title":"The Joy of Bugbusting"},{"content":"Long time no blog. Many things have happened during last 6 months: I got a commit bit, FreeBSD/MIPS reached multiuser and started migration from P4 to CVS. Right now we\u0026rsquo;re waiting for toolchain patches to be imported to contrib/binutils properly. So let\u0026rsquo;s prepare to celebrate buildable FreeBSD/MIPS world in a couple of weeks! Meanwhile I\u0026rsquo;m busy with getting latest zaptel (they changed name to DAHDI, actually) drivers to FreeBSD and a couple of side aсtivities like digging into aio code from OpenSolaris/Linux/FreeBSD. Hope to blog more regularly now. Stay tuned.\n","permalink":"https://kernelnomicon.org/posts/bsddev-blog-sitrep/","summary":"\u003cp\u003eLong time no blog. Many things have happened during last 6 months: I got a commit bit, FreeBSD/MIPS reached multiuser and started migration from P4 to CVS. Right now we\u0026rsquo;re waiting for toolchain patches to be imported to contrib/binutils properly. So let\u0026rsquo;s prepare to celebrate buildable FreeBSD/MIPS world in a couple of weeks! Meanwhile I\u0026rsquo;m busy with getting latest zaptel (they changed name to DAHDI, actually) drivers to FreeBSD and a couple of side aсtivities like digging into aio code from OpenSolaris/Linux/FreeBSD. Hope to blog more regularly now. Stay tuned.\u003c/p\u003e","title":"bsddev blog SitRep"},{"content":"Juniper released FreeBSD/MIPS port to public. There are no references to JNPR-specific hardware pieces but a lot of mature code for generic MIPS devices that mips2 tree lacks: VM/pmap, libc, FPU support. Nice gift, thanks JNPR!\n","permalink":"https://kernelnomicon.org/posts/ny-gift-from-juniper/","summary":"\u003cp\u003eJuniper released FreeBSD/MIPS port to public. There are no references to JNPR-specific hardware pieces but a lot of mature code for generic MIPS devices that mips2 tree lacks: VM/pmap, libc, FPU support. Nice gift, thanks JNPR!\u003c/p\u003e","title":"NY gift from Juniper"},{"content":"This weekend I spent writing driver for IDT RC32434 on-board Ethernet adapter. Weird hobby, isn\u0026rsquo;t it? Writing NIC drivers is new to me so I shared my time between reading if_XX sources, reading IDT specs and writing my own code. Task turned out easier then it appeared and 15 minutes ago I managed to mount root over NFS using kr0 interface. Time to get some beer and celebrate!\n","permalink":"https://kernelnomicon.org/posts/rb532-progress/","summary":"\u003cp\u003eThis weekend I spent writing driver for IDT RC32434 on-board Ethernet adapter. Weird hobby, isn\u0026rsquo;t it? Writing NIC drivers is new to me so I shared my time between reading if_XX sources, reading IDT specs and writing my own code. Task turned out easier then it appeared and 15 minutes ago I managed to mount root over NFS using kr0 interface. Time to get some beer and celebrate!\u003c/p\u003e","title":"RB532 progress"},{"content":"Today I managed to get shell prompt on Mikrotik\u0026rsquo;s Routerboard 532. So now we have 3 platforms with single user mode for FreeBSD/mips, not very useful :) The last problem was getting high-level console interface working. I always fell lost when it comes to resource allocation and uart stuff. I should write a couple of posts on these subjects to memorize all details better.\n","permalink":"https://kernelnomicon.org/posts/mikrotik-rb532-single-user-mode/","summary":"\u003cp\u003eToday I managed to get shell prompt on Mikrotik\u0026rsquo;s Routerboard 532. So now we have 3 platforms with single user mode for FreeBSD/mips, not very useful :)  The last problem was getting high-level console interface working. I always fell lost when it comes to resource allocation and uart stuff. I should write a couple of posts on these subjects to memorize all details better.\u003c/p\u003e","title":"Mikrotik RB532 - single user mode."},{"content":"I stumbled over this problem a couple of years ago, ignored it, was punished for my carelessness, came out with hackerish solution and now I know \u0026ldquo;The Right Way\u0026rdquo; to solve this issue. So, the headache starts when you\u0026rsquo;re trying to wakeup userland application polling on a descriptor from INTR_FAST IRQ handler (for 7.X and later that would be interrupt filter). INTR_FAST/interrupt filter routines are usually used for timing-critical tasks and run in IRQ dispatcher context, so no operations that may cause context switch are allowed in this code. Unfortunately selwakeup(9) tries to acquire sellock that leads to a possible context switch and leaves us in a total mess. My solution was handmade kernel thread that has been running through list of channels and performed all dirty work, not the cleanest and easiest to maintain code. \u0026ldquo;Zaptel-bsd take 2\u0026rdquo; utilizes taskqueue(9) interface to work around IRQ handler limitations. There is handler routine:\nstatic void handle_selwakeup(void *context, int pending) { struct selinfo *sel = context; selwakeup(sel); } then selinfo/task structures for every channel:\n... /* thingy for select stuff */ struct selinfo sel; struct task selwakup_task; ... which should be initialized during channel allocation:\n... TASK_INIT(\u0026amp;chan-\u0026gt;selwakup_task, 0, handle_selwakeup, \u0026amp;chan-\u0026gt;sel); ... and used anytime we\u0026rsquo;d like to call selwakeup:\n... taskqueue_enqueue_fast(taskqueue_fast, \u0026amp;timer-\u0026gt;selwakup_task); ... ","permalink":"https://kernelnomicon.org/posts/intr_fast-and-selwakeup/","summary":"\u003cp\u003eI stumbled over this problem a couple of years ago, ignored it, was punished for my carelessness, came out with hackerish solution and now I know \u0026ldquo;The Right Way\u0026rdquo; to solve this issue. So, the headache starts when you\u0026rsquo;re trying to wakeup userland application polling on a descriptor from INTR_FAST IRQ handler (for 7.X and later that would be interrupt filter). INTR_FAST/interrupt filter  routines are usually used for timing-critical tasks and run in IRQ dispatcher context, so no operations that may cause context switch are allowed in this code. Unfortunately \u003ca href=\"http://www.freebsd.org/cgi/man.cgi?query=selwakeup\u0026amp;apropos=0\u0026amp;sektion=0\u0026amp;manpath=FreeBSD+7-current\u0026amp;format=html\"\u003eselwakeup(9)\u003c/a\u003e tries to acquire sellock that leads to a possible context switch and leaves us in a total mess. My solution was handmade kernel thread that has been running through list of channels and performed all dirty work, not the cleanest and easiest to maintain code. \u0026ldquo;Zaptel-bsd take 2\u0026rdquo; utilizes \u003ca href=\"http://www.freebsd.org/cgi/man.cgi?query=taskqueue\u0026amp;apropos=0\u0026amp;sektion=0\u0026amp;manpath=FreeBSD+7-current\u0026amp;format=html\"\u003etaskqueue(9)\u003c/a\u003e interface to work around IRQ handler limitations. There is handler routine:\u003c/p\u003e","title":"INTR_FAST and selwakeup"},{"content":"Sometimes it\u0026rsquo;s desirable to pass some arguments to module to customize its behavior, e.g.: to set/unset verbosity level of debug output, set operation mode etc\u0026hellip; Linux modules can get this information from insmod utility, but kldload is not capable of doing such kind of things. What a pity. But don\u0026rsquo;t get desperate - tunables to the rescue!\nJust like an ordinary command shell (bash, csh, sh) kernel has its own environment, the set of \u0026lt;name, value\u0026gt; pairs. You can get, set, test, unset these variables using getenv, setenv, testenv, unsetenv functions in the kernel and kenv(2) syscall or kenv(1) command in userland. So if you want to set verbosity level for module, you would do something like this:\n# kenv zaptel.debug=1 # kldload ./zaptel.ko and then in module initialization routine:\nstatic int debug = 0; /* Hush-hush */ ... char * value = getenv(\u0026#34;zaptel.debug\u0026#34;); if (value) { debug = strtol(value, NULL, 10); freeenv(value); } Too much code for such a simple task, don\u0026rsquo;t you think? Yeah, like for every common task there are useful macroses defined in kernel headers, you should just find them. Heavy coffeinated kernel hackers knew most of them. In this particular case neat code would look something like that (for statically initialized variable):\nstatic int debug = 0; /* Hush-hush */ TUNABLE_INT(\u0026#34;zaptel.debug\u0026#34;, \u0026amp;debug); or, if debug is the member of structure or local variable:\nsc-\u0026gt;debug = 0; TUNABLE_INT_FETCH(\u0026#34;zaptel.debug\u0026#34;, \u0026amp;sc-\u0026gt;debug); TUNABLE_XXX macroses exist for INT, LONG, ULONG and STR types. TUNABLE_STR unlike the others requires third parameter - maximum size of the string. For a dynamic value retrieval every type has TUNABLE_XXX_FETCH macro defined. Nota bene: if there is no environent variable set with requested name, the value of acceptor variable remains untouched.\n","permalink":"https://kernelnomicon.org/posts/modulekernel-parameters/","summary":"\u003cp\u003eSometimes it\u0026rsquo;s desirable to pass some arguments to module to customize its behavior, e.g.: to set/unset verbosity level of debug output, set operation mode etc\u0026hellip; Linux modules can get this information from insmod utility, but kldload is not capable of doing such kind of things. What a pity. But don\u0026rsquo;t get desperate - tunables to the rescue!\u003c/p\u003e\n\u003cp\u003eJust like an ordinary command shell (bash, csh, sh) kernel has its own environment, the set of \u0026lt;name, value\u0026gt; pairs. You can get, set, test, unset these variables using \u003cstrong\u003egetenv\u003c/strong\u003e, \u003cstrong\u003esetenv\u003c/strong\u003e, \u003cstrong\u003etestenv\u003c/strong\u003e, \u003cstrong\u003eunsetenv\u003c/strong\u003e functions in the kernel and \u003ca href=\"http://www.freebsd.org/cgi/man.cgi?query=kenv\u0026amp;sektion=2\u0026amp;apropos=0\u0026amp;manpath=FreeBSD+7-current\"\u003e\u003cstrong\u003ekenv(2)\u003c/strong\u003e\u003c/a\u003e syscall or \u003ca href=\"http://www.freebsd.org/cgi/man.cgi?query=kenv\u0026amp;sektion=1\u0026amp;apropos=0\u0026amp;manpath=FreeBSD+7-current\"\u003e\u003cstrong\u003ekenv(1)\u003c/strong\u003e\u003c/a\u003e command in userland. So if you want to set verbosity level for module, you would do something like this:\u003c/p\u003e","title":"Module/kernel parameters"},{"content":"Hello. My name is Oleksandr Tymoshenko. I\u0026rsquo;m a software developer. My involvement in FreeBSD project started in 1998 by making static entries in ARP table really static. Though patch hasn\u0026rsquo;t made out of my university\u0026rsquo;s network it was \u0026ldquo;the beginning of a beautiful friendship\u0026rdquo;. My first significant contribution to FreeBSD community (or so I\u0026rsquo;d like to think) was porting of Zaptel drivers from Linux to FreeBSD. About two years ago I happened to work with a MIPS board and got some interest to the architecture. Since then I\u0026rsquo;ve been doing my best trying to bring FreeBSD to this platform and, actually, succeeded to some extent with a help from developers crowd.\nIn this blog I\u0026rsquo;m going to make notes on drivers development and porting process. Mostly for myself - to memorize gotchas and pitfalls which happen from time to time. But I hope that these notes will be of some use to other kernel hacker wannabes.\n","permalink":"https://kernelnomicon.org/posts/introduction/","summary":"\u003cp\u003eHello. My name is Oleksandr Tymoshenko. I\u0026rsquo;m a software developer. My involvement in FreeBSD project started in 1998 by making static entries in ARP table really static. Though patch hasn\u0026rsquo;t made out of my university\u0026rsquo;s network it was \u0026ldquo;the beginning of a beautiful friendship\u0026rdquo;. My first significant contribution to FreeBSD community (or so I\u0026rsquo;d like to think) was porting of  \u003ca href=\"http://www.voip-info.org/wiki/view/Zaptel\"\u003eZaptel drivers\u003c/a\u003e from Linux to FreeBSD. About two years ago I happened to work with a MIPS board and got some interest to the architecture. Since then I\u0026rsquo;ve been doing my best trying to bring FreeBSD to this platform and, actually, succeeded to some extent with a help from developers crowd.\u003c/p\u003e","title":"Introduction"}]