 Hi everyone, thank you for joining. This presentation is about designing a business card that runs Doom, exploring low-cost arm architecture. My name is Ethan Sayer, and I'm a junior at Plano East Senior High School in Plano, Texas. I'm very interested in embedded systems, machine learning, and web development. The inspiration from this project comes from a blog post that I read about someone named George Hilliard who designed and assembled an embedded Linux system in the profile of a business card. It is a total bomb cost of less than $3 and runs Linux with a small build route, a flash drive partition, and a persistence partition. He uses a $1 arm9 SOC from a company called Allwinner, and the SOC is called the F1C100S. George Hilliard's business card inspired me to extend his idea and attempt to design a low-cost business card that runs Doom. Ideally, it would have the profile of a business card and would support some type of LCD screen, as well as six tactile switches to play the game. It should also support gameplay through a port called Chocolate Doom, which is a lightweight lib-SDL based Doom implementation that runs on Linux. Some considerations that should be made when deciding on parts include the cost of the processor, which should be less than $5 to make it affordable enough that these business cards can be given away. It should also be Linux capable and support and fulfill all of the requirements to support a smooth running Linux kernel, which include a moderately high clock speed, as well as an MMU. Additionally, embedded RAM would be preferred because including RAM on a PCB increases the complexity of the board as you have to deal with high-speed signals and maintaining the signal integrity. It should also support small LCDs over the i880 interface or the RGB parallel interface, and it should support USB for powering the device, as well as flashing the spy memory. Over the course of this presentation, we will discuss four different goals of this project. The first goal is choosing the parts and specifications of the PCB, including the processor, flash memory, and peripheral devices. The second goal is testing the chosen processor on a development board to ensure that the software will cross-compile correctly and be compatible with the processor. The third goal is designing and routing a schematic and its corresponding PCB to produce a board with a business card profile. And the fourth goal is the fabrication of this PCB, as well as its assembly and flashing the memory. When researching SBC processors, I found three main categories. So on the lower end, there's a lot of really affordable MIPS or legacy ARM processor types with typically a lower clock speed. In the mid-tier, I found a lot of single and dual-core Cortax-based processors. And then on the higher end, I found a lot of quad-core and even some 64-bit processors that were based on newer and faster Cortax cores. So here's a more holistic look. But for this project, since it's something that I'm going to be giving away, cost in cost is more important than performance, we will focus on the lower end processors. The processor that I thought would work best for this board is an all-winner F1C100S. You can purchase this processor for about $1 to $2. And it's an ARM9-based processor, which means that it is going to be compatible with a lot of existing Linux libraries and existing Linux packages. It also supports many different peripherals, such as SPI, UART, LCD interfaces, touch panel, audio codecs, video processing, and video output as well. The core that is using inside is an ARM926EJS, which runs at 533 MHz. The actual ARM9 architecture for this particular core actually dates back to 2001. But I believe that this specific all-winner chip was designed in about 2012. Another great bonus is that it supports embedded DDR, so depending if you got an F1C100S or an F1C200S, you can get different packages with 16 MB of RAM or 32 MB of RAM. The power consumption of this chip idling with Linux is also very low, only 50 mA compared to 1000 mA on the Raspberry Pi Zero and the Raspberry Pi One. There were several different types of screens I looked at, ranging from 1.7 inches to 3.5 inches. The main determining factor for me was the interface. Most smaller screens only supported i8080 and SPI interface. But the reference designs for the all-winner chip only showed an example implementation for RGB parallel. As such, I made the decision to go with an 18-bit RGB parallel display as it had the best chance of being supported. And on the all-winner reference designs, there'll be more pins than the 18-bit, so I believe there's eight pins for each RGB, so for each color. And so what you can do is, since you're looking for the most significant bit, you can emit the lower pins and just use the higher pins, and that worked out just fine for these screens. In order to test the F1C100S, I found a development board by a company called Cypede. It's called the Lyche Pinano, and they produced this board for about $8 to $10. It includes the F1C100S as well as some important other components, such as the spinor flash and the backlight driver, which can power the backlight of the LCD. There's a good amount of support for this board because it supports U-boot, RT thread, MicroPython, and of course Linux. Although all-winner does not provide these resources directly, there is a great community called the Sanchi Community who has produced a lot of the compatibilities for this particular chip and have ported U-boot and Linux to this processor. In order to prepare the U-boot partition, I downloaded the U-boot source and configured the boot arguments to use MTDBlock3 or the 4th partition as the SquashFS route. The boot CMD should be based on your partitions and the location of the Linux Z-image, which I will discuss on the next slide. You can compile with Make and use the Lyche PDef config, and the output should be a bin file that you can directly flash to the first partition. To prepare the Linux partition, I first cloned the GitHub repository from a developer called iSnowy, who was able to port Linux support to this processor. The manufacturer of the developer board provides config files for the Make configs, so I downloaded those configurations. Additionally, you must also install the ARM Linux GNU Yabi toolchain from Linaro to support cross-compiling to ARM. After running Make config and configuring it with SquashFS and enabling caching block device access, I compiled Linux with Make and cross-compile. In order to prepare the build-root partition, I started with an empty build-root source. After extracting, you can configure build-root to automatically include all dependencies, as well as the binary of the chocolate-doom package. I didn't really know how to use build-root, and so when I compiled it, I got a very large 98 megabyte image size, even after configuring a do-not-include on all packages. So instead, I did it manually and I started with a pre-compiled build-root and manually checked all the dependencies of the chocolate-doom binary by using read-elf-d on the executable, which lists all of the shared libraries that the executable would use. Then I manually copied all of these dependencies from slashlib and slashusrlib to their respective locations on the new build-root. In order for chocolate-doom to run, you need something called a WAD file, which is basically a game cartridge file. I copied the binary to userbin and the game file to usergames and I built the SquashFS with a command called MKSquashFS. The structure of the flash is divided into four different partitions. The Uboot partition is compiled from the Uboot source code with configurations to enable LCD. The second partition is the DTS device tree, or when you compile it, the DTB device tree, which I copied from the compiled Linux directory. The third partition is the Linux kernel, which you can take from arm-arch-arm-slash-boot, and there will be a z-image file there, which you can flash directly. The fourth partition is using the build-root, which as previously mentioned is a SquashFS read-only file system in order to save space for the doom executable and its dependencies. If you wish to have a persistence partition, you can do so by creating what's called an overlay layer with the file system type of JFFS, so that would be your fifth partition. In order to boot from the spinor flash, you can use the DD command to create a partitioned bin or IMG file and flash that single file over USB to the flash. What I ended up doing was flashing each particular partition individually as the read-write speed of those flash memories is very slow. You must also modify the Linux spinor driver by replacing the sector argument and replacing that with a zero. When you compile Linux, it will automatically produce a DTB file from your DTS file, from your device tree file. It will automatically produce a binary version, and you can flash that directly to the second partition. Here's the DTS configuration. You can see at the bottom left, there's a SquashFS as well as a read-write overlay. The SquashFS is going to be read-only, and you can configure the DTS based on how big you want each file system or partition to be. I ended up not including an overlay to save space, but you can do so if you wish, and any other peripherals you can also put into this file. The all-winner chip has a specific flash mode called FEL mode. If the flash or boot location is blank, it will automatically enter this FEL mode. Or if you insert an SD card with a specific file that you can obtain from the Sanji community, it will also trigger this FEL mode. Once you are in FEL mode, you can use USB and a Sanji tool called Sanji-FEL to directly reprogram the flash memory over USB. If you are flashing each partition individually, you can just replace the address at which you want to overwrite in the command line options. If you wanted to flash a single pre-partition image that you created with DD, you could just write by flash-write0 and then write your bin file. But if you, for example, wanted to just edit the Linux kernel, you can specify the start address of the Linux kernel partition and then put your updated Linux kernel file. And it would only rewrite that segment of the flash. To design the PCB and schematics, I used Altium Designer. I consulted the manufacturer data sheets for a lot of the components on the board in order to get access to the footprints and symbols. So the symbols are the drawings that appear on the schematics and the drawings, the footprints are the physical dimensions of the component that appear on the actual PCB. I also used a tool called Component Search Engine, which is an aggregator for a lot of these parts. You can also get a lot of the footprints and symbols from Chinese electronic websites as well. In terms of power, there are four main power rails across the schematic, which are 5 volts for USB raw power, 3.3 volts, 2.5 volts and 1.1 volt for the processor and the DDR RAM. This was my first time using Altium and I found that the net labels, so the red text you're seeing, really helped to keep the schematic tidy. Here are more component wiring schematics. There were many different decoupling capacitors from power rails to ground. My Spinoar Flash is a wind bond model with a capacity of 16 megabytes. And the main other peripheral here is just the LCD connector as well as the LCD backlight driver. Here's some more schematics. I also used switches for the up, left, right, down and B buttons and A and B buttons in the game. In order to connect to the shell, I used a header pin to expose the UR connections, so the UR RX and TX. After routing, here is what the final board render ended up as. I don't really know if this is the proper way to route boards, but I added as much ground as possible on the bottom and top layers to act as a ground plane, as I only have two layer PCBs. So I couldn't use the, if I had a four layer PCB, for example, you could use the second and third layers as power and ground planes. This was my first time, so it was definitely very tedious to place each component and route all of the connections. I do think that for this type of board that is not very complex, a two layer board would probably work best. This is a 3D rendering of the same board, so you can start to see the general locations of the LCD and the buttons start to take place. In total, there's about 30 components. To produce the board as quickly as possible in the United States, it costs about $150 for each PCB. Since I didn't really have the budget to fabricate a PCB for this project, I found a company that could do the boards in something called a bare bone style for about $60. The only catch is that it doesn't come with a solder mask or a silkscreen. This actually made the assembly much harder, as I also did not purchase an SMD stencil, so I had to put small globs of solder paste by hand on each pad for every component. In the future, I would like to try to source the boards with solder mask and silkscreen, as well as an SMD stencil. Finally, I will discuss how I ran Doom on the board. To run Doom, you first have to specify an environmental variable for libSDL, which is the graphics library dependency, to indicate that there is no mouse or keyboard plugged in. And you can use the command line option dash geometry to specify your screen size. So this video shows launching Doom with the freeware Doom game file. And this is just the demo mode, so you can see the game is able to boot up on this LCD. So what's next? In the future, I hope to refine the PCB fabrication and make the profile of the board even smaller, with a thinner screen and overall size. I hope to also attempt I8080 interfacing, as I8080 screens are much cheaper than RGB parallel ones. I also hope to use little VGL to develop a simple graphical interface for switching between a resume and Doom, for example. This was my first Linux board, and I hope to continue designing these boards in the future and work with more powerful SoCs and processors and more complex designs with other peripherals such as RAM and Wi-Fi. Thank you so much for attending. I hope that this presentation was helpful for you in some way or that you enjoyed it. If you would like to contact me, my email is on the screen at ethansoyre.icloud.com. With that, I hope that you enjoy the rest of your conference, and thank you again for attending.