64bit computing on a budget

With all that Dec Alpha talk, and how hard it is to get hardware, and how seemingly exclusionary it is, I thought I would try to touch on a more available 64bit ‘risc’ platform, for the masses!

While a couple years ago I had touched on running Windows 10 on the Raspberry Pi 4, in the brave new world of 2023 getting ahold of a pi4 is expensive, hard to find, and kind of depressive, which lead me to this (old) but exciting project, the Renegade Project!

Long story short, there exists enough drivers & information to facilitate a port to the Snapdragon 845, a 64bit System On a Chip( SOAC!), meaning that if you have a device with this chip it *can* be slightly possible to install Windows 10 onto it.

system compatibility matrix, for ants.

Glancing at the system matrix, to me the glaring hole is Charging. 3 systems outright support it, all of them from Xiaomi, the Xiaomi Mix 2s, Xiaomi Mix 3 & the Xiaomi PocoPhone F1. Looking around eBay to start this adventure I found a PocoPhone F1!

Getting the Phone

This seemed like a good start, 29.99, 128GB of flash storage, and I’d later learn 6GB of RAM. The first problem came from Xiaomi. Turns out that the phone was still locked, the seller had neglected to logout from his Xiaomi account. Even worse though he had forgotten his login and password. Calling Xiaomi support was basically worthless. Without unlocking the phone on a reset to root the phone lead me to this:

Locked!

I got lucky however after talking to the seller, he agreed to go above and beyond and we were able to unlock the phone together. So everything went well. If you do buy one of these phones used, MAKE SURE TO CHECK THE XIOAMI login id! It has to be unlocked and blank so you can register it and get the unlock. It will require a valid email & phone number + sim for it to send/receive SMS codes.

Access to the site is very up & down, so I archived what I had downloaded to unlock the phone here. miflash_unlock_en_7.6.602.42.7z

I should add that we’ve cleared the first few hurdles of precuring the device and unlocking it. And I’m glossing over stuff. Getting to this point was not easy and took a week. The unlock process is not intuitive, and I’m sure many phones are sold out there that have their google access wiped, but have not been logged out all the way, or the flash erased. I can’t show you mine as I ended up erasing Android but be aware of this!

Getting ready for Windows

Basically on the Android side there is three main modes, the boot, the recovery and the ‘fastboot’ mode. Holding power & down brings you to fastboot, where using the fastboot tool you can load an image from your PC into ram and execute it. EDK2 UEFI firmware, is the first part or the renegade project you’ll encouter. It’s really powerful, allowing you to not only boot into Windows, but it also supports a linux disk target mode, allowing you to partition and access the flash directly from a PC. Naturally this is SUPER dangerous, and backup your modem files!

With the phone unlocked softbooting E2DK you can put it into a target disk mode, connect it to a pc and partition away!

disk mode… for ants!

The guide (section 1.2) advices pushing the disk tools to the phone booted up in twrp-3.7.0_9-0-beryllium.img. Honestly its easier to just partition it on your computer. HOWEVER if you were to use Windows, there is a slight issue:

The device may no longer be able to boot into fastboot mode

I ran into this issue and thought I had bricked my phone. I was actually in the middle of researching how to do a physical hard reset, and place it into EDL mode (taking it apart and finding which pads to short, when I found this section of the troubleshooting guide, where it’s the partition names. So instead, I ended up doing the partitioning on a Virtual Machine using VMware and Ubuntu.

(parted) print
print
Model: SAMSUNG KLUDG4U1EA-B0C1 (scsi)
Disk /dev/block/sda: 123GB
Sector size (logical/physical): 4096B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name        Flags
 1      24.6kB  41.0kB  16.4kB               switch
 2      41.0kB  73.7kB  32.8kB               ssd
 3      73.7kB  524kB   451kB                bk01
 4      524kB   786kB   262kB                bk02
 5      786kB   1049kB  262kB                bk03
 6      1049kB  1573kB  524kB                keystore
 7      1573kB  2097kB  524kB                frp
 8      2097kB  4194kB  2097kB               bk04
 9      4194kB  8389kB  4194kB               misc
10      8389kB  16.8MB  8389kB               logfs
11      16.8MB  33.6MB  16.8MB               oops
12      33.6MB  50.3MB  16.8MB               devinfo
13      50.3MB  67.1MB  16.8MB               bk05
14      67.1MB  134MB   67.1MB  ext4         persist
15      134MB   201MB   67.1MB  ext4         persistbak
16      201MB   268MB   67.1MB               logdump
17      268MB   403MB   134MB                minidump
18      403MB   1275MB  872MB   ext4         cust
19      1275MB  1342MB  67.1MB               recovery
20      1342MB  1611MB  268MB   ext4         cache
21      1611MB  123GB   121GB                userdata

Before I did anything, this is what the phone partition table looked like. It’s an exceptional amount. The new parted v 3.0 that is recommended to use, doesn’t support the resize command so I had to manually do the numbers after destroying partition 21.

Originally, I had made a 32Gb partition to keep some Android functionality but somewhere it just stopped booting. But I didn’t care.

rm 21
mkpart userdata ext4 1611MB 32G
mkpart esp fat32 32G 32.5G
set 22 esp on
mkpart win ntfs 32.5GB 123G

21      1611MB  32.0GB  30.4GB  ext4         userdata
22      32.0GB  32.5GB  499MB   fat32        esp         boot, esp
23      32.5GB  123GB   90.5GB  ntfs         win         msftdata

Obviously dont follow this. I’m only providing output as an example.

If I were more patient, I guess I would have dd’d the entire phone to get a full entire backup. But I didn’t get this phone to run Android, so I really don’t care.

There is a LOT of disks being presented to Windows, in case you ever wondered how those 128GB flash devices get sold with only 114GB of user space.

So many partitions!

And even that 112GB is actually usable!

Remember the system partition needs the boot,esp flags, and the windows partition is msftdata. Also make sure the partition names are either single words, or NO words. Spaces will kill the fastboot mode.

I put all the disks that are presented in offline mode, so I don’t get confused. Make sure you are going to mess with the right volumes when formatting after the partitioning. This is NOT for the novice, it would be easy to not only brick the phone but screw up your existing install. If you have physical disks attached you don’t absolutely need, remove them or put them offline to make sure you don’t screw up.

I used diskpart to select the appropriate volumes and format them.

select disk 8
select volume 5
format quick fs=fat32 label="System"
assign letter="S"
select volume 6
format quick fs=ntfs label="Windows"
assign letter="W"

This isn’t a guide, just a reflection of what I went through.

With the disk now formatted, it’s a matter of selecting an OS to install.

I had really bad luck picking random versions of Windows, so I looked until I could find a confirmed working version in this video, Rodando o Windows 10 ARM nativamente em um Dispositivo Android (Pocophone F1 + UEFI). Long story short, it’s Windows build 210521-1658 with version 0.4 of the bootloader. Long story short I messed with LOTS of Windows on ARM driver sets, before I finally had the brave idea to just load it with no drivers:

booted

But that image is far too stale, and expires out very quickly, reducing any useful functionality once it’s connected to the internet. So it’s something that probably could be fixed, but it’s far easier to just grab an image that’s newer.

The x86_64 image I’m using now is 19045.3031, so I guessed to pick something comparable on ARM64. I used something called 19045.3031_arm64_en-us_professional, although it too was out of date, but Windows update brought it up to 22H2 19045.3086 . I had tried the downloader tool and apply all the updates offline, but I had issues. I suspect now in retrospect it was drivers.

Another thing I learned the hard way is that some of these images have multiple OS images installed. I guess it’s de-duplication, along with compression, but be sure to index the image first! I accidentally installed a Home version. Yuck.

dism /Get-ImageInfo /imagefile:install.wim

Index : 1
Name : Windows 10 Home
Description : Windows 10 Home
Size : 17,706,743,995 bytes

Index : 4
Name : Windows 10 Pro
Description : Windows 10 Pro
Size : 17,836,320,420 bytes

So just don’t go wildly apply image #1. I wasted too much time on that one.

But in the release I’m using it’s image #1. I checked. Trust me.

dism /apply-image /ImageFile:10.0.21390.1.co_release.210521-1658_arm64fre\install.wim /index:4 /ApplyDir:W:\

The S volume needs to be populated with the UEFI boot files. I had foolishly thought the boot.wim file would include the boot files, but instead bcdboot can set it up based on the location of a Windows install.

bcdboot W:\Windows /s S: /f UEFI

The next thing to do is install the drivers.

I was lucky enough to get some insight into some driver combination to work, and I came up with this much:

minimal 2210.1-fix
USB beryllium v2.0rc2
FG beryllium v2.0rc2

The key of course is that there is a minimal set in 2210.1-fix that will bring the system up with working USB. The FG package brings in enough of the power management to know the battery status.

dism /Image:W: /Add-Driver /Driver:drivers /Recurse

The drivers are not signed, so that means we need to change a bunch of boot flags. I also turned on debugging so have Windows dump core files, so you can run analysts on them with Windgb.

S:
cd S:\EFI\Microsoft\Boot
bcdedit /store BCD /set "{default}" testsigning on
bcdedit /store BCD /set "{default}" nointegritychecks on
bcdedit /store BCD /set "{default}" recoveryenabled no
bcdedit /store BCD /set "{default}" debug on

Of course the catch being that with no drivers loaded it’s in a super basic mode, with no USB, no touch screen, no power management, no wifi no nothing. So it’s a brick. But at least we’ve reproduced enough to show that you can boot Windows.

Sadly, loading all the drives from 2210.1-fix or beryllium v2.0rc2 lead to this:

the cracked glass adds to the feeling.

Add in a much needed OTG adapter and a mouse or keyboard, and you can complete the installation.

However, since I left off the majority of the device drivers as I didn’t want to spend forever trying to track it down, I used a random USB to Ethernet adapter and thankfully It just worked!

Accessing the phone over RDP.

I added a fancy USB 3.0 ‘dock’ with USB-C connector that you can plug a charger into, so that not only can the phone stay connected to power, but there is room for the Ethernet. It also has HDMI, perhaps is the drivers were more stable, it could be a viable desktop? And I have what I wanted, which was a non Intel/AMD 64bit platform that is hopefully more reliable than the Alpha64 platform, and maybe something to do some kind of contrast of the past vs future

This was NOT a simple thing to go through. I would be extremely hesitant to advise other people to follow suit. But in the off chance anyone who wants to do it, might have a better idea of what is involved.

Read the Troubleshooting guide & the Installation guide. Keep notes! I would have absolutely given up, without keeping notes.

Even simple tracking of disasters like this at least helped me along:

210521-1658
10.0.21390.1.co_release.210521-1658_arm64fre
boot-beryllium Version 0.4.1.img
boot-beryllium-ebbg Release - 2210.1.img
boot-beryllium-ebbg Release - 2210.1.img

boot-beryllium-ebbg Release - 2210.1.img

boot-beryllium-ebbg Release - 2210.1.img

boot-beryllium-ebbg Release - 2210.1.img
no drivers

no drivers

v1.1.1


v1.1


FocalTechTouch v2.0rc1


v2.0rc1
INTERNAL_POWER_ERROR

installer


SYSTEM THREAD EXCEPTION NOT HANDLED


SYSTEM THREAD EXCEPTION NOT HANDLED

installer


SYSTEM THREAD EXCEPTION NOT HANDLED

Sorry the table doesn’t format well.

TL;DR don’t do it, unless you don’t mind spending too much time on this. Get a used Surface X instead.

Space Cadet 3D Pinball reverse engineered!

With all the controversy over 64bit pinball, and where and how things appeared, then disappeared to the discovery that the x64 version was a thing, but it was left off the install manifest but shipped on CD, along with my simple script to just extract it, the problem was that ARM32/64 users were left in the cold.

Don’t get me wrong, the original 32bit exe runs fine under emulation, but who wants emulation when you can have NATIVE CODE?! You’d have to try to find the source code (lol good luck!) or reverse engineer the program. And that’s what happened, enter:

k4zmu2a/SpaceCadetPinball: Decompilation of 3D Pinball for Windows – Space Cadet (github.com)

64bit ARM Pinball!

I’m using Visual Studio 2019 to build this, and it was great it *just worked*. Hurray!

There is also a rebuild going on for SDL to bring Space Cadet Pin Ball to Linux and beyond. The only downside is that it uses a number of ‘new C++ features’ locking out older platforms. I’d done some work to dumb it down although there is a bit of this new fangled C++ I’m unsure of what is going on. So that means, unfortunately Itanium users are left in the dark, as Visual Studio 2010 is too old.

Running VMWare ESXi on Raspberry PI

(This is a guest post by Antoni Sawicki aka Tenox)

Just for fun with virtualization I wanted to try out VMWare ESXi for ARM64, most specifically Raspberry PI. ESXi for ARM has been around for a couple of years now. Since PI4 packs 8GB of RAM and has a reasonably fast CPU it can be a worthwhile experience. Also more OSes for Raspberry PI are now available in UEFI boot mode.

Not going to go through exact installation steps as these are all around the web and youtube. Just to summary you will need to download an image from VMWare website as well as bunch of UEFI firmware files from github and combine it all together on to a SD card. When you boot it you will go through an install process which is straightforward. You can overwrite install media and use it as the target so no need for multiple SD cards. Once it boots you will see familiar ESXi boot screen:

ESXi booting on Raspberry PI 4

In order to get it going you will obviously need to add some storage. You can use NFS, iSCSI or locally attached USB drive. For the latest you need to disable USB arbitrator.

# /etc/init.d/usbarbitrator stop
# chkconfig usbarbitrator off

What can it run?

ESXi ARM only officially supports only UEFI boot based OSes. Fortunately this is a default option for Ubuntu PI, Free/Net/OpenBSD also work and so does Windows. But what about OSes that use U-Boot? Since ESXi-ARM Fling 1.1 you can boot oses in a “direct” mode with no UEFI! This is a huge step, but unfortunately as of today it doesn’t support UEFI-less VGA, only a serial port. Hopefully this can be fixed in future. I would love to have a RISC OS and/or Plan 9 VM. On the other hand Plan 9 supports EFI boot so an image could be made.

Windows guest install was also much easier than I expected. Thanks to UUP dump you basically roll your own bootable ISO. I think it’s actually easier to get it going on ESXi than natively on RPI hardware or QEMU.

Windows 10 Guest VM on ESXi Fling Raspberry PI

NIC driver obviously did not work by default, but there is a VMXNET3 ARM64 driver in the wild:

VMXNET3 for Windows 10 ARM64 on ESXi Fling on Raspberry PI

What is it good for?

Right now probably just for fun. But I can easily see datacenters filled in with ARM servers running ESXi. Future is bright and free of Intel! Personally I will keep it around for development purposes if I need to make builds for ARM on various OSes.

Interestingly enough you can even run VMWare ESXi ARM on QEMU with nested virtualization!

Also this is the official VMWare ESXi ARM Blog worth checking for future updates.

Elijah Miller’s NEC v30 on a Pi hat

v30 on a board

While talking about home brew 8080 and 8086 systems on Discord an ebay search brought me to Elijah’s store page where this small little curiosity was up for sale. It’s literally just a NEC v30 on a Raspberry Pi hat, for a mere $15 USD! Interestingly enough the v30 can operate at 3.3v meaning no special hardware is required to interface to the GPIO bus on a Pi. This reminds me so much of the CP/M cartridge for the Commodore 64, and the price being so right I quickly ordered one and eagerly awaited to 2 weeks shipping to Asia.

While I have Pi 4’s that I run Windows 10 on to drive some displays & power point, I wanted to use the slightly faster Pi400 for this. The Pi400 has a compatible GPIO expansion port so just like a cartridge it’s a simple matter of slotting the card, powering up and building the software. While there is an included binary, it’s a 32bit one, and I’m running Manjaro on the Pi400 for a similar look/feel as the PineBook Pro. Anyways the dependences are SDL2, and an odly named ‘wiringPi’ library that allows C programs to interface to the GPIO.

You can download the emulator over on homebrew8088, specifically the Raspberry Pi Second Project. The last ‘ver 2’ download has the project configured for a v30 which is an 8086 analogue, unlike the v20 which is an 8088. When physically interfacing to the processor things like this really matter!

With the emulator built it was pretty simple to fire it up, and boot into MS-DOS:

first boot!

I have to admit I was a little startled at first as I really had no idea if this was going to work at all. I’d spoken to an engineer friend and he was saying plugging a CPU directly into the GPIO bus, and toggling connections to actually emulate the board was both crazy and that without any electrical buffers it’d most likely either fry the processor and maybe the Pi as well. I suspect this being low voltage may be sparing both, although I have no EE so I’m not going to pretend to know.

Loading up Norton SI confirms what Elijah had posted on Ebay is that it runs very slowly about 1/3rd the speed of an XT. Now I may not know anything about hardware but this seemed at least something a profiler could at least tell me what is going on, and if someone like me helicoptering in on the shoulder of giants could see something.

gcc -I/usr/include/SDL2 -pg -O2 *.cpp -o pi -lSDL2 -lwiringPi -lpthread -lstdc++

This will build a profiled version of the emulator that’ll let us know which functions are being called both the number of times, and how much time to do so. Not knowing anything but having profiled other emulators, the usual pattern is that you spend most time fetching and possibly translating memory; Both in feeding instructions and pushing/popping data from stack and pointers. Waiting is usually for initialisation and for IO.

Once you’ve run your profiled executable, it’ll dump a binary file gmon.out which you can then use gprof to format to a text file like this:

gprof pi gmon.out > report.txt

And then looking at the report you can see where the top time, along with top calls are. Some things just take a while to complete and other well they get called far too often.

Each sample counts as 0.01 seconds. % cumulative self self total
time seconds seconds calls s/call s/call name
39.91 0.71 0.71 286883 0.00 0.00 Print_Char_9x16(SDL_Render er*, int, int, unsigned char)
16.30 1.00 0.29 1 0.29 1.02 Start_System_Bus(int)
12.37 1.22 0.22 1100374 0.00 0.00 Data_Bus_Direction_8086_OUT()
7.87 1.36 0.14 5954106 0.00 0.00 CLK()

As expected Start_System_Bus takes 1 second, followed by 1,100,374 calls to set the Data_Bus_Direction_8086_OUT (no doubt the Pi needs to alternate between reading and writing to the CPU), followed by 5,954,106 ticks of the CLK function. Of course the real culprit is Print_Char_9x16 which was called 286,883 times, and is responsible for nearly 40% of the tuntime!

Obviously for a simple MS-DOS boot the screen should not be calling any print char anywhere near this many times. Clearly something is amiss. Not knowing anything I added a simple counter to block at the top of the Print_Char_9x16 function to let it only execute 1:1000 times, and I got this:

Obviously it’s not right, which means that the culprit really isn’t Print_Char_9x16 but rather what is calling it. It was a simple change to each of the Mode functions to only render a fraction of the time, and I changed it to a define to let me fire it more often. This is a simple diff, assuming WordPress doesn’t screw it up. It’s not pretty but it gets the job done.

$ diff -ruN ver2/vga.cpp ver2-j/vga.cpp 
--- ver2/vga.cpp	2020-07-29 10:36:51.000000000 +0800
+++ ver2-j/vga.cpp	2021-06-04 01:51:33.546124473 +0800
@@ -1,5 +1,9 @@
 #include "vga.h"
 
+static int do9x16 = 0;
+#define VIDU 5000
+
+
 void Print_Char_18x16(SDL_Renderer *Renderer, int x, int y, unsigned char Ascii_value)
 {
 	for (int i = 0; i < 9; i++)
@@ -23,6 +27,12 @@
 
 void Mode_0_40x25(SDL_Renderer *Renderer, char* Video_Memory, char* Cursor_Position)
 {
+do9x16++;
+if(do9x16>VIDU)
+        {do9x16=0;}
+else
+        {return;}
+
 	int index = 0; 
 	for (int j = 0; j < 25; j++)
 	{
@@ -36,6 +46,7 @@
 	Print_Char_18x16(Renderer, (Cursor_Position[0] * 18), (Cursor_Position[1] * 16), 0xDB);
 	SDL_RenderPresent(Renderer);	
 }
+
 void Print_Char_9x16(SDL_Renderer *Renderer, int x, int y, unsigned char Ascii_value)
 {
 	for (int i = 0; i < 9; i++)
@@ -57,6 +68,12 @@
 }
 void Mode_2_80x25(SDL_Renderer *Renderer, char* Video_Memory, char* Cursor_Position)
 {
+do9x16++;
+if(do9x16>VIDU)
+        {do9x16=0;}
+else
+        {return;}
+
 	int index = 0; 
 	for (int j = 0; j < 25; j++)
 	{
@@ -102,6 +119,12 @@
 
 void Graphics_Mode_320_200_Palette_0(SDL_Renderer *Renderer, char* Video_Memory)
 {
+do9x16++;
+if(do9x16>VIDU)
+        {do9x16=0;}
+else
+        {return;}
+
 	SDL_RenderClear(Renderer);
 			int index = 0; 				
 			for (int j = 0; j < 100; j++)
@@ -156,6 +179,12 @@
 }
 void Graphics_Mode_320_200_Palette_1(SDL_Renderer *Renderer, char* Video_Memory)
 {
+do9x16++;
+if(do9x16>VIDU)
+        {do9x16=0;}
+else
+        {return;}
+
 	SDL_RenderClear(Renderer);
 			int index = 0; 
 			for (int j = 0; j < 100; j++)

While it feels more responsive on the console, it’s still incredibly slow. SI was returning the same speed which means that although we aren’t hitting the screen anywhere near as often it’s still doing far too much. Is it really a GPIO bus limitation? Again I have no idea. But the next function of course is the clock.

First I tried dividing the usleep in half thinking that maybe it’s not getting called enough. And running SI revealed that I’d gone from a 0.3 to a 0.1! Obviously this is not the desired effect! So instead of a divide I multiplied it by four:

diff -ruN ver2/timer.cpp ver2-j/timer.cpp 
--- ver2/timer.cpp	2020-08-12 00:32:13.000000000 +0800
+++ ver2-j/timer.cpp	2021-06-04 02:06:25.505904407 +0800
@@ -7,7 +7,7 @@
 {
    while(Stop_Flag != true)
    {
-      usleep(54926); 
+      usleep(54926*4); 
       IRQ0();
    }
 }

Now re-running SI I get this:

Norton SI with clock multiplied by four

Now it’s scoring a 1.5! Obviously these are all ‘magic numbers’ and tied to the Pi400 and more importantly I haven’t studied the code at all, I’m not trying to disparage or anything, if anything it’s just a quick example why profiling your code can be so important! At the same time trying to run games is so incredibly slow I don’t even know if my changes had any actual impact to speed as emulation of benchmarks can be such a finickie thing.

My goto game, Battletech 3025 Crescent Hawks Inception loads to the first splash but then seems to hang. I could be impatient or there could be further issues but I’m just some impatient tourist with a C compiler…

With my changes and re-running the profiler I now see this:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  us/call  us/call  name    
 95.41    129.23   129.23 22696621     5.69     5.69  Read_Memory_Array(unsigned long long, char*, int)
  2.90    133.15     3.92                             Start_System_Bus(int)
  0.88    134.34     1.19 64369074     0.02     0.02  CLK()
  0.30    134.74     0.40                             keyboard()
  0.16    134.96     0.22   412873     0.53     0.53  Print_Char_9x16(SDL_Render
er*, int, int, unsigned char)
  0.08    135.07     0.11 11273939     0.01     0.01  Data_Bus_Direction_8086_OUT()

Which is now what I expect with the bulk of the emulation now calling Read_Memory, with the Clock following that and of course our tamed screen renderer (although its still called far too much!) with the Data_Bus_Direction being further down the list. No doubt some double buffering and checking what changed in between calls would go a LONG way to optimise it, just as would actually studying the source code.

The one cool thing about this is that if I wanted to write a PC emulator this way gives me the confidence that the CPU is not only 100% cycle accurate, but it’s 100% bug for bug accurate since we are using a physical processor.

And again for $15 USD + Shipping I cannot recommend this enough!

Pinebook Pro first impressions

Pinebook Pro

So yes, it’s most certainly built from a MacBook Air looking frame. But it’s not the same build materials, which of course is to be expected as these are far cheaper. Unlike the other ARM book I have, this one doesn’t have a GPRS modem, and as of this moment doesn’t natively run Windows. Which with it’s paltry 4GB of RAM and 64GB of disk space is just as well.

adding a 32bit runtime

Just as the MIPS64 had it’s weirdisims, the ARM64 is in the same seat. I didn’t see anything all that clear on Manjaro, and 32bit, at the same time debootstrap is available in the repo, allowing you to quickly install a 32bit Debian userland to chroot into. It’s pretty much the same steps as before, with the only real change being to use the armhf processor family giving a 32bit tree.

Maybe it’s my overall familiarity with Debian, but I find the environment far easier to deal with. Well that and of course many things just build so much nicer in 32bit mode, than 64bit mode sadly. It’s a shame that many distros don’t seem to include a matching 32bit/64bit libset but here we are.

Another plus is that Debian has far more robust mirrors world wide, and downloading components and updates is FAR faster than Manajro.

Loose clips?!

In the first week however disaster struck as I had it ‘sleeping’ one night and plugged in to charge, and when I opened the lid, I got nothing. The charging led showed RED for some reason like it was still charging, and no matter what I tried on the keyboard it just would not turn on.

Searching online didn’t give me much other than people saying that they were replacing the built in flash and didn’t seat it correctly. Did my kids or cat knock it over when I wasn’t looking? Was it on the edge of not being seated from shipping? I have no idea.

Lid off!

Well as much as I love opening new stuff, it was acting dead so I guess nothing to lose. That said the screws come off pretty easily but there is 2 sizes as the ones up front are super short. With the lid off you can see that the battery is 2x the size of the motherboard. And yeah of course it being ARM, its very raspberry pi – ish. And I guess it’s really no surprise.

The mainboard

On the mainboard there is 2 push buttons, and 2 sliding jumpers. One is hidden beneath the black tape. I hit the reset button, and slid both sliders up and down and then pressed down on the 64GB chip. I flipped it over to see if that did anything, and surprisingly it’d turn itself on!

I quickly shut it down, and screwed it back together. And I’ve been using it daily over the last week without any further issues with it powering on. Again I have no idea what was wrong but at least it seemed easy enough to open up and hit some buttons. Which brings me to the overall feel:

Build quality

It’s really hard to slam the PineBook Pro. It has incredibly lofty goals, and for the pricepoint it’s absolutely insanely good value. The body has been molded from what at best could be called an ‘inspired by the Mac Book Air’ but it’s the keyboard and trackpoint where it falls short. The keys have too much travel for their own good, and seem to twist a little giving a klunk as they don’t depress quite right. I have had issues with the arrow keys trying to play DooM via DOSBox. And I’ve become so spoilt with backlit keys, that although I know how to touchtype I still look from time to time.

The trackpoint is miserable, it’s constantly jumping the mouse (no palm detection)? and it just doesn’t glide or click ‘right’. But I know I’m being 100% unfair as I’m comparing this to a laptop that is 5x the price. I’ve written this and other stuff on the laptop and it’s just been so jumpy at times for seemingly no reason when I type it’ll jump and click at the worst possible moments.

The flip side is that FPS stuff is impossible as the keyboard and trackpoint won’t deliberately work at the same time. And I have no idea how to go about dealing with that. I guess use an external mouse.

Another stupid low point is the speakers. They are so tinny which I guess is to be expected, but they are so quite. I guess I should play test tones, and get some app to measure dB, but comparing it to anything else again just seems so unfair.

That said the screen is AMAZING. I had worried that the screen was going to be terrible, but no the screen is an absolute high point of the machine.

Battery life has been pretty good, and from opening it up, it’s no surprise as it does have a massive battery. They do include clips to bypass the battery all together if you want to run it from DC mains 100%. The only issue I have had with battery life is that Manjaro doesn’t seem to have hibernation support. And many times I put it to sleep when I go to sleep it’ll wake up with zero percent remaining. I don’t see that as a fault of the physical build, rather the OS.

Software and FSF flailings?

I don’t know much about Manjaro but it’s default setup sure feels a lot like the way Debian felt when they were under pressure to keep all non-free stuff segregated and partitioned away from users. The problem as it’s always been is that popular software has almost always been commercial, especially for normal uses. Turning on Community and Contributions should really be the default setting with people who want to be FSF pure having to click the button giving normal people the best possible experience. As an old person who’s been hearing about the ‘year of the Linux desktop’ is at hand back in 1997 (Va Linux et al), and been an on and off user since SLS, it’s always about the users. All the plugins and bookmarks and shared data stuff I have is on Chromium and having to hunt down how to turn it on sucked, as I was moments away from just doing the usual ‘user’ thing of wiping the install because I can’t find an app.

Distro shopping has been the worst thing to plague Linux since it was apparent that Linus wasn’t going to bless us a userland, unlike BSD. I know some see it as a strength but it’s always been such a critical weakness for the user. Oddly enough the circle has come around to bite enough people that Docker is a thing to deal with dependency and distro hell.

Games!

Well without a doubt visit astr0baby’s blog and enjoy some good hand holding to get a bunch of open stuff built. It’s toally worth it. And incredible to play 64bit Duke Nukem 3D!

Is it worth it?

Well if you want non x86 on the go, the price simply cannot be beat. However the default Linux install is alien to me, but I’m trying to learn to deal with it. And of course the weird power on issue really precludes this from normal people. I’d recommend it to anyone comfortable with Linux and a screwdriver. If you are 100% hardware focused it’s a laptop, no GPIO so it’s going to be a little bit of a bummer. If you are scared of opening it up, you may find like I did that you very well might have to. However for anyone in the middle absolutely.

“Normies” this isn’t the laptop you want. .. I’d say “yet” as I’m sure that build quality will only improve, just as software will hopefully get a bit more friendly for adding stuff like Chrome (what a mission to get it installed!).

Final ramblings

Years ago in college we joked that 30 years in the future you could get a quad processor Dec Alpha as a bundle in with a box of cereal. That a computer would be an impulse purchase at the supermarket. It seemed so laughable but a given as manufacturing and acceptance of that internet thing was a given. But that was the future from 30 years ago.

The future is now!

GCC 2.5.8 failure on 32bit ARM

This is really nothing more than a placeholder for me… Unless someone else knows the answer, then it’s really ‘how not to cross compile GCC’.

First I’m using the EMX’ified version of GCC from my MinGW to EMX cross. It didn’t require that much massaging to get it to build, the usual unzip as ascii to convert text, and in no time I can build cc1.


root@pinepro:/src/emx/src/gcc-2.5.8# file cc1
cc1: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=42c0c8de7175edade7614dc92d5d13e4421e0e6f, with debug_info, not stripped

and it crashes in what has to be a 2020 most unfortunte name

Reading symbols from cc1...done.
(gdb) r
Starting program: /src/emx/src/gcc-2.5.8/cc1 

Program received signal SIGSEGV, Segmentation fault.
0x004f6b84 in rtx_cost (x=<error reading variable: Cannot access memory at address 0xff7efff0>, 
    outer_code=<error reading variable: Cannot access memory at address 0xff7effec>) at cse.c:667
667     {
(gdb) 

Yes, it really crashes in rtx_cost. Good thing there isn’t a super popular card from Nvidia that is currently being short squeezed by crypto miners right now called the RTX where everyone is looking for a good price. 😐

I had then been thinking perhaps it’s because I’m using GCC 8.3.0, maybe it’s introducing some new and exciting bug? So I cross compiled GCC 4.1.2 as follows:

./configure --target=armeb-linux --host=armeb-linux --build=armeb-linux

Keeping in mind that my knowledge of ARM is pretty much nill, especially on Linux. The compile went mostly okay, just have to remember the gnu inline macro’s as needed from back in the day (-fgnu89-inline) and while it builds, it is insisting on using collect2 which of course is screwing things up. And of course I don’t want it as my system compiler. As a hack I found system gcc 8 can link things fine as I didn’t want to spend all day messing with GCC/collect2

I copied xgcc, cc1 and cpp from 4.1.2 into a /412 directory, and rebuilt 2.5.8 with the following shell:

make CC="/412/xgcc -B/412 -g -O0  -I. \
-I./config \
-I/usr/lib/gcc/arm-linux-gnueabihf/8/include \
-I/usr/local/include \
-I/usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed \
-I/usr/include/arm-linux-gnueabihf \
-I/usr/include" cc1

As you can see the cross wasn’t picking up the right include paths, so I just cheated, and dumped them from 8, and just copied them into this script. I re-ran the build and had 2 issues,

/412/xgcc -B/412 -g -O0  -I. -I./config -I/usr/lib/gcc/arm-linux-gnueabihf/8/include -I/usr/local/include -I/usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed -I/usr/include/arm-linux-gnueabihf -I/usr/include -c  -DIN_GCC   -g -std=gnu89     -I. -I. -I./config local-al.c

....

/tmp/ccMguyhs.s: Assembler messages:
/tmp/ccMguyhs.s:5001: Error: selected processor does not support `fltd f1,r3' in ARM mode
/tmp/ccMguyhs.s:5025: Error: selected processor does not support `fltd f0,r3' in ARM mode
/tmp/ccMguyhs.s:5026: Error: selected processor does not support `dvfd f1,f1,f0' in ARM mode
/tmp/ccMguyhs.s:5027: Error: selected processor does not support `ldfd f0,.L489' in ARM mode
/tmp/ccMguyhs.s:5028: Error: selected processor does not support `mufd f0,f1,f0' in ARM mode

and so on. Also failing was global.c Again the same weird instruction/asm mix being triggered. Other than those two, cc1 will build, but unsurprisingly:

Reading symbols from cc1...done.
(gdb) r
Starting program: /src/emx/src/gcc-2.5.8/cc1 

Program received signal SIGSEGV, Segmentation fault.
0x004f6b84 in rtx_cost (x=<error reading variable: Cannot access memory at address 0xff7efff0>, 
    outer_code=<error reading variable: Cannot access memory at address 0xff7effec>) at cse.c:667
667     {
(gdb) 

Well, at least it’s consistent?

Or a fun way to kill a couple hours.

**EDIT I went ahead and looked in the 4.1 source for ARM stuff..

root@pinepro:/src/gcc-4.1.2# grep arm config*|grep linux
grep: config: Is a directory
configure:  arm*-*-linux-gnueabi)
configure.in:  arm*-*-linux-gnueabi)

it didn’t like the gnueabihf stuff one bit.

I tried to rebuild as linux-gnueabi

./configure --target=arm-linux-gnueabi --host=arm-linux-gnueabi --build=arm-linux-gnueabi

make LANGUAGES=c HOST_CFLAGS='-fgnu89-inline' CFLAGS='-fgnu89-inline'

And then re-built GCC 2.5.8 with the same error, but slightly further into the program:

Starting program: /src/emx/src/gcc-2.5.8/cc1

Program received signal SIGSEGV, Segmentation fault.
0x004f2a20 in rtx_cost (x=0x41, outer_code=PLUS) at cse.c:679
679       code = GET_CODE (x);
(gdb) bt
#0  0x004f2a20 in rtx_cost (x=0x41, outer_code=PLUS) at cse.c:679
#1  0x004f2e20 in rtx_cost (x=0x60c3f8, outer_code=SET) at cse.c:736
#2  0x004ac2dc in init_expmed () at expmed.c:87
#3  0x0045ae28 in compile_file (name=0x5c96ec "stdin") at toplev.c:1648
#4  0x0045f6fc in main (argc=1, argv=0xfffefd04, envp=0xfffefd0c) at toplev.c:3569
(gdb)

The positive thing is that there was no weird register errors while compiling, and it built 100% normally…? “arm-linux-gnueabihf” almost seems right, specs needs fixing to point to “/lib/ld-linux-armhf.so.3” instead of “/lib/ld-linux.so.3” along with the linker target.

Windows 10 on the Raspberry Pi 4

As far as computers go, Raspberry Pi’s are cheap. The latest (and vastly incompatible) Pi4 is no real exception. Now you’d think Microsoft would want to get WoA (Windows on ARM) into as many hands as possible to get people to port apps to the new cpu architecture. But that is not the case.

As of this moment there is no real desktop machines, the only route to go is with the laptops, which are the few models from Lenovo, HP, Acer and Microsoft themselves. Brand new these things are not cheap, and of course people find out quickly enough that the emulation just isn’t quite there (not all that surprising) and of course the lack of native apps doesn’t help. It’s that chicken/egg problem that can only be solved by getting hardware into people’s hands.

Developers!

So getting back to to the Pi, on ETA Prime’s channel I saw this video, which quickly went over how to get Windows 10 up and running in no time flat.

On the Discord look for the #download-links and look for build 0.2.1 After you extract it, the image should be about 10GB

10,100,932,608 build 0.2.1.img

With a MD5 checksum of: aad51a0e02ba947d24d543ff8ed612b0

Use etcher to write the image to the SD. It took me about 5 minutes to do so. No bigge. I unplugged the SD/IDE/USB adapter thing I’m using, plugged it back in, and used Windows disk manager to expand the partition to take up the rest of the disk. It’s not terribly complicated to setup.

SSD Flashed
Right click and select Extend
The default option will consume the entire disk

After that slap in the SD to your Pi4 and away you go. Or so I first thought.

Realistically you also need:

  • A USB Hub
  • A USB Ethernet adapter (I have some cheapo no name realtek)
  • A USB audio card
  • A mini HDMI to regular human sized HDMI cables/adapters
  • a 5Amp USB charger for extra power!

As I found out rather quickly that the only peripherals that are working is the USB ports. However the USB controller has some DMA bug where it can’t xfer higher than 3GB which caps the current memory ceiling to 3GB.

Otherwise the Pi will think and reboot a few times, and about 15-30 minutes later (I didn’t time it, I walked out) you’ll be up and running Windows 10 on ARM!

It’s heavily customized in that when Windows boots up it is only consuming about 1GB of RAM. So that gives us just under 2GB for user programs. GREAT! Included is the setup program for the latest beta of Microsoft Edge (with the chromium engine) so at least you can actually hit web sites. However Google doesn’t like it, so if you are going to try to watch anything with DRM it will not work.

While many people complain about STEAM, game compatibility, really what on earth were you expecting? Naturally people will want to know how fast it is, and well… It’s not. Although it does have 4 cores, running at 1.5Ghz, there is barely any cache (well compared to an i7/Xeon), and it’s clearly not a power house of a box. The only real test of a machine like this is going to be native stuff. And speaking of, it’s nice that my previous builds for ARM still work! The sales guy that borrwed the ASUS should be back soon so I can do some side by side comparisons of how slow they are.

In addition to DOSBox, Neko98, and frontvm, I managed to get MAME 0.36 cross compiled and I had to disable the DirectX input and output, as although they do compile they have issues on the Pi4. So it’s GDI all the way. That said, it does run:

This isn’t the port you want, or the platform to play it on. I’m using the command line Visual C++ tools to build this, and MAME 0.37 drifted to being more of a MinGW thing, and I just don’t feel like fighting the build process.

Another point of fun, is that this processor & OS does have x86 compatibility you can take things to the extreme with OTVDM, and run Win16 based programs on Windows 10 for ARM! Not that I would know why you want Excel 3.0, but rest assured, it works fine.

Hit:1 http://ports.ubuntu.com/ubuntu-ports bionic InRelease
Get:2 http://ports.ubuntu.com/ubuntu-ports bionic-updates InRelease [88.7 kB]
Get:3 http://ports.ubuntu.com/ubuntu-ports bionic-backports InRelease [74.6 kB]
Err:1 http://ports.ubuntu.com/ubuntu-ports bionic InRelease
Unknown error executing apt-key

The platform supports WSL, so I went ahead and installed Ubuntu 18 & 20… and both have one apparently known catastrophic failure on the Pi’s. When trying to update packages the updater crashes. The fault is apparently in dirmngr, or the usual Linux bandaid of switching distros. There doesn’t appear to be any ‘fix’ to this, so if anyone knows what to do, I’m all ears. Also don’t enable WSL2, it’ll hang at the bootloader. I ended up having to reflash the disk.

In my quick conclusion, is this the RISC Windows workstation of the future? No, not really. It’s more the $50(+peripherals) tyre kicker edition. It’s a cheap way into the platform, to see what the fuss is all about. This machine feels like a low end i3, the CPU just isn’t there, it’s only a BCM2711 Cortex-A72, so there isn’t all that much to be expected. On the other hand it’s FAR FAR FAR cheaper than something like the Surface X. If you have the hardware it’s worth checking out if you are interested in non x86 Windows. Otherwise you aren’t going to miss much.

So Apple is finally moving to ARM

Dawning of a new era. Again.

Details don’t seem to be anywhere near as complete as I’d like them for now, but the long speculated move to ARM has finally begun. Interestingly enough, it’s the end of OS X 10.x as now we have version 11, currently named macOS Big Sur:

I guess the more interesting thing will be the emulation in the new Rosetta2, if this is actual emulation or is this going to be relying on LLVM’s intermediary byte-code, allowing a user experience more akin to Java.

With the move to ARM, this will spell the end of the Hackintoshes. Which is a shame, as the best way to experience OS X, most certainly has been on non Apple hardware. I guess time will tell regarding the adoption of the desktops, but as always since the introduction of the Apple Store & Apps, computers have accounted for a negligible fraction of Apple’s sales. Even sales of iPads surpass those of all the computers combined.

The upcoming transition kit will be a Mac mini sporting the A12Z SoC, 16GB of memory and a 512GB SSD. This is the same processor in the current iPad Pro.

The Transition Kit is $500 USD, however it’s invite only. You can try your luck here at:

https://developer.apple.com/programs/universal/

Sorry?

Naturally I was denied the opportunity to give them $500.

I suppose as time goes on more and more details will become available. I’m sure there will be a race to get Qemu to run Big Sur, although Im sure the retail product will be signed and encrypted, and Apple will consolify their ecosystem.

On the gaming side, however being able to run iOS apps on the desktop means that the Mac is now a serious gaming contender for the casual market. Can apple bridge the Candy Crush gap where Microsoft failed with RT?

Bare Metal Vice

From the site:

BMC64 is a bare metal fork of VICE’s C64 emulator optimized for the Raspberry Pi. It has 50hz/60hz smooth scrolling, low video/audio latency and a number of other features that make it perfect for building your own C64 replica machine.

I had to pick up some bits and bobs as there is some circuits I wanted to try to build, and oddly enough the electronic store I went to had some Pi’s! I bought 2 zero’s and 2 three’s! They aren’t cheap, sadly but I honestly doubt any zero’s actually ever sold for  Â£5, and these cost me $168! Each! (just under £20!).

Anyways since I had nothing to do with these things, I already ordered a 1541 hat for the Commodore 64c, so I’ll need a 3 for that, but I was looking around and ran into the bmc64!

You do have to drop in your BIOS files manually, which is the only tedious bit, then dump over your taps’ and d64’s. My 3 boots up in a few seconds straight to the BASIC screen, like it’s 1983!

I was expecting it to be a lot of work, and it really was a SNAP. Not that I have any shortage of machines, or tiny machines to run VICE, but this running on metal is honestly kind of exciting.

I’d have loaded it on the zero, but it uses some mini HDMI port, and all I have is regular HDMI cables. I also picked up some heat sinks for the CPU’s as no doubt, no idle loops means it’ll get toasty.

It’s something I’d encourage people to check out, if anything to see how versatile a bare metal program can be for the pi’s.. Although apparently they screwed up the 4, it’s too different from the 0/2/3 for some reason.

Pitty.

Cross compiling SDL 1.2.15 for ARM Win32

I was getting this fun error:

C:\proj\ss\SDL-1.2.15\VisualC\SDL>link /dll -out:sdl.dll *.obj winmm.lib dxguid.lib gdi32.lib user32.lib advapi32.lib dxguid.lib uuid.lib dxguid.lib Version.res
Microsoft (R) Incremental Linker Version 14.24.28315.0
Copyright (C) Microsoft Corporation. All rights reserved.

Creating library sdl.lib and object sdl.exp
SDL_dx5events.obj : error LNK2001: unresolved external symbol GUID_SysMouse
SDL_dx5events.obj : error LNK2001: unresolved external symbol GUID_SysKeyboard
SDL_dx5events.obj : error LNK2019: unresolved external symbol IID_IDirectInputDevice2A referenced in function DX5_DInputInit
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_XAxis
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_YAxis
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_ZAxis
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_RxAxis
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_RyAxis
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_RzAxis
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_Slider
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_Key
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_POV
sdl.dll : fatal error LNK1120: 12 unresolved externals

Which was NOT easy to track down. Thankfully while amputating and chasing the origin of GUID_Key, I ran across this: cboard.cprogramming.com

I have read various texts that state you must
Code:?

1#define INITGUID

And yes, you do!

In the file SDL-1.2.15\src\video\windx5\directx.h I just added it to the top, and now it’ll build the hacky DLL!

Maybe it’s something for Visual C++ version 19? I don’t know.

Anyway the advantage is now I have full audio for DosBOX!

Luckily updating binaries wasn’t too hard.