Installing DOOM on any device is like hoisting the winner's banner on a fallen fortress. I was asked the question "well, did you start doom?" at least 35 times when they found out that I am fiddling with this calculator. I decided not to disappoint the audience and to achieve the launch of DOOM. Along the way, it became a good test of the equipment performance, as well as revealing unpleasant bugs. So let's go!
Project news
For those wondering how I got DOOM running, they can skip this chapter and skip to the next. It simply presents the current status of the project.
As you remember in the previous parts ( part 1 and part 2 ), I was engaged in putting Linux on a calculator, rebuilding u-boot, kernel, rootfs. Since then, I have been quite closely engaged in the calculator and even thoroughly figured out what was done in u-boot, kernel and device tree. You have to understand that this is my hobby, in my free time from my main work and family, so not everything goes quickly, and sometimes it is somewhat illogical, simply because today there is a mood to do this and not otherwise.
The main news took place thanks to the user Alx2000y, who invited me to a chat in a cart, where people saw their firmware for Xiaomi Gateway on a similar processor. There is even an article on Habré on the topic . The people have already advanced a lot in this topic, incredibly expanding the functionality of the device. And helped me a lot to defeat the nand issue. As you remember, at the very beginning I wiped my nand image out of stupidity. As a result, I got a fairly large number of "virtual" bad sectors, the most unpleasant thing is that the bad sectors were at the very beginning and did not allow u-boot to be written there. Below is a list of bad sectors, most of them are virtual.
=> nand bad Device 0 bad blocks: 00000000 00020000 00040000 00060000 012c0000 04e20000 05280000 094c0000 17b20000 1ff80000 1ffa0000 1ffc0000 1ffe0000 =>
Lenar, from the above chat, helped me a lot, the problem was solved with just two commands in u-boot:
nand erase.chip … nand scrub.chip … Really scrub this NAND flash? <y/N> y
After that, we check the number of bad sectors, and, lo and behold, there are significantly fewer of them!
=> nand bad Device 0 bad blocks: 1ff80000 1ffa0000 1ffc0000 1ffe0000
As a result, I can now load u-boot into sector zero and boot. At the moment, the calculator can be loaded simply by powering on and will be fully loaded with linux, with a working display and the ability to run programs via UART. It even works correctly for DOOM. "But, there is a nuance" (C). Apparently the keyboard driver somehow overlaps with the ubifs driver, and as a result, if you press any key on the keyboard, the calculator instantly hangs. A kernel panic even flew to me once, but I did not think to save it in order to at least find the place of this intersection. So for now, everything works in the initramfs for sure. A video demonstrating the work of loading nand, launching DOOM and freezing was posted in my telegram channel .
From other good news, I tried to put ubuntu on nand, it also works correctly. Packages, of course, cannot be installed, but in general you can work and use it, which is also convenient. But without a working keyboard, these games are still devoid of practical meaning.
In the last part, I complained that u-boot has different behavior when running on nand and from RAM. I spent two days poking around in the u-boot source codes to figure out what was going on. And everything turned out to be trite (even ashamed). The uuu utility, when starting u-boot from memory, passes its environment variables there. More precisely, it calls mfgtool_args and, as a result, the line of the boot environment variable looks like this:
bootargs=rdinit=/linuxrc g_mass_storage.stall=0 g_mass_storage.removable=1 g_mass_storage.file=/fat g_mass_storage.ro=1 g_mass_storage.idVendor=0x066F g_mass_storage.idProduct=0x37FF g_mass_storage.iSerialNumber= mtdparts=gpmi-nand:4m(boot),8m(kernel),1m(dtb),1m(misc),-(rootfs) clk_ignore_unused
Of course, if you boot from nand, then with such parameters ubifs in the fourth section will not be visible. Therefore, after loading u-boot into RAM, I forcibly set the following environment variables to it:
setenv bootargs console=ttymxc0,115200 ubi.mtd=4 root=ubi0:rootfs rootfstype=ubifs mtdparts=gpmi-nand:4m(boot),8m(kernel),1m(dtb),1m(misc),-(rootfs)
And everything works great.
Let me explain why this is needed: if you flash the bootloader into the zero sector, the ability to work through mfgtool (uuu utility) disappears. And at this stage, consisting of development and debugging, it is the main tool. Therefore, it is easier to leave the uuu utility running and load u-boot manually each time.
Launching DOOM
Moving on to the fun part - running DOOM on the calculator. As you can imagine, it was not in vain that I wrote about all the problems in the beginning. You can run DOOM when booting to a NAND flash, there you can put cards of all kinds, all possible versions of DOOM, and in general whatever your heart desires. But when running in RAM, we are limited by the size of the rootfs image at about 15 MB (practice has shown that 16 still rolls). In this regard, I had to select the version of DOOM and make the correct assembly, as well as learn how to work with it.
It turned out that all good things were invented for us long ago, and DOOM can be assembled directly into buildroot without leaving the couch. I found this out when I googled all the possible variants of DOOM for embedded systems and tried to build them. As it turned out, it is enough to run:
make menuconfig
And choose DOOM. This is done in "
Target packages ---> Games --->
"
We have two versions of DOOM at our disposal: chocolate-doom and prboom . After a few experiments, I realized that chocolate-doom doesn't want to fit into initramfs. Unless, if you remove the wad files altogether. I was trying to find cropped wad files that would fit with chocolate doom. But she refused to work with them. As a result, I tried installing the chocolate version on nand (along with prboom), and tried it there. I selected parameters, etc. The experiment resulted in the following launch method:
export SDL_NOMOUSE=1
chocolate-doom -geometry 320x240 -bpp 24 -nomouse
The result disappointed me greatly: this version of doom incorrectly (or, on the contrary, correctly) stretches the screen, leaving wide stripes at the edges of the screen, which I really did not like.
The chocolate version of DOOM. A black stripe is visible below.
At startup, my chocolate doom tells me what window resizing does:
I_InitGraphics: 320x240 mode not supported on this machine. I_InitGraphics: Auto-adjusted to 320x200x32bpp.
Therefore, I settled on prboom. I made the image together with the shared WAD files and the prboom itself , removed all unnecessary things. But, all the same, for a very long time I could not make it work. I read all sorts of manuals, looked for how to configure so that everything would work correctly. The image displays, reacts to buttons, but the screen clumsily stretches and displays color curves. Until I found the ideal launch parameters on some forum.
In general, for our calculator, the prboom launch is as follows: turn off the mouse, and then launch prboom with the following parameters:
export SDL_NOMOUSE=1
/usr/games/prboom -width 320 -height 240 -nosound -vidmode 32bit
The key parameter here:
"-vidmode 32bit"
.
I was looking for suitable parameters for a long time, and only with this everything started. For convenience, I wrote everything down to the d.sh script. Finally everything works, you can even play!
Especially for you, I have prepared an updated assembly of flash_utility with DOOM , which you can run on your calculator even without flashing it, and show your friends, they say, DOOM works in my calculator. It is enough to disassemble the calculator, close the contacts described in the first part and run
sudo uuu doom.uu
At the end of all the steps, you will receive a calculator, with linux and DOOM. To start DOOM, you will need to log in and execute on the calculator:
./d.sh
To summarize
DOOM works! Can I play it? Well, locally, downloading from a computer - you can. It looks cool and beautiful, but in fact, not really what you want to get. It’s really cool when you’re on the subway, grab a calculator and pull it out of your wide legs, turn it on (power saving mode doesn’t work at the moment), and launch DOOM. This is really cool to play in the metro on a calculator in DOOM, Duke Nukem 3D, Quake I, II, III, etc. But the fact remains - DOOM is running on this piece of hardware. But there is still a lot of work to do.
In general, there is not enough at least a small community around this calculator (at least more than me), so that there are problem testers, there is someone to talk to and share, to hear advice. The original author has clearly cooled down to this project, although he did a titanic job. I understand him well, and I can’t reproach him for not wanting to help even with advice on this project. Well, he gave small recommendations, but he was clearly no longer up to him. Therefore, if you have ideas, a calculator, a desire to help, at least with advice, write here or in the cart, I will be glad!
PS Why am I doing this?
Very often they ask me "what for"? I understand intellectually that it is stupid to answer this question, but nevertheless I will answer.
Why is an artist painting a picture or an author writing a book? Let's be honest, 90% of books, paintings and other works may not see the light at all, and of those who see, a fraction of a percent will become known and gain a wide range of readers. Simply put, most creators are doing “useless” work. Moreover, many works never even find their readers, but why should they not? What drives these people? Everything is pretty commonplace. They are driven by a simple feeling:
Simply put, you do it because it's cool and it's rushing. And, oddly enough, in the future it will bring great benefits, although not as obvious as it seems.
Files to download
