Testing a Galileo Board in 2026, Part 2 of X

This is less a Part 2 than an interregnum on a walkthrough plan for booting an OS on my 2014-era 1st gen Galileo board that I purchased earlier this year. While it's a lot more productive to write code or actually get the board to boot, talking about what I'm doing might actually interest people who are late bloomers to this hobby (for lack of a better word).

I am hoping it doesn't take me all summer, but if it does, it will be a Summer of Code.

In the past few days, I have discovered some other hobbyists testing the Galileo board as recently as 2024 and 2025 (and likely 2026 too), who encountered some issues with SSHing into their system, both via the USB to Serial adapter, and via a LAN connection. There are various reasons why this might be, and since I am running an update on Rocky Linux 9.5, I have not included links to save bandwidth on a limited connection.

But the gist of the issue is that SSHing into the Galileo board may return a "connection refused" error. There can be multiple reasons for this. One is that SSH isn't installed on that particular image or it's not enabled. First, the minimal linux image isn't quite sufficient to run a more featured OS. Thus the first objective is to properly flash a working distro. I have found several, including a Debian 3.8 distro, which appears most promising, although some of its spinners have encountered issues with it, even returning to the original Yocto blend. This is a classic example of "the more you know," the more capable a hacker one can be. I am quite annoyed at myself because I remember thinking back to when I was 16, and seemed to be more creative with finding fixes to a PC than I do now. But that's not all. What I've started to think about is how different the Galileo/Edison boards are from the Raspberry Pi, and the things I like and don't like about both of them.

 While both the Pi and The Galileo have a bootloader, it is not readily accessible without a microSD card. This differentiates them from a x86 motherboard where a firmware is installed regardless if an OS is installed or not. It's a convenient recovery method when trying to set the right mode for a hard drive (e.g. AHCI or legacy IDE), or enabling the first drive to boot (such as USB before drive C: or D:). I often prefer to dual boot on separate drives, rather than separate partitions, in case there is some aggressive OS that likes to overtake the boot process (it seems Windows always tries to place itself first on an autoboot once a drive is selected first). I have installed CoreBoot on a Chromebook, which I find quite satisfactory (although sometimes it lags, possibly due to a slow SSD on board).

Since the Raspberry Pi is marketed as an educational board, it might make sense that it features a helpful coprocessor to facilitate booting. While I didn't bother to buy a Raspberry Pi until 2020 (I had long known about it since 2011, and even met Upton in NYC at the Queens Maker Faire), I didn't even know until 2023 or 2024 that it had a not-so-secret (or no longer secret) VideoCore IV processor that begins the boot process: https://news.ycombinator.com/item?id=12743235

From Fuzix developer David Givens:

"The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. At power on, a boot ROM loads an embedded OS image into the VC4 processor. That then sets up the hardware, powers up the ARM, and loads the OS image into that. The VC4 then continues running in the background servicing RPCs from the ARM.

What this is is a replacement VC4 operating system image which just fires up the ARM with an embedded image, sets it running, and then halts (assuming I'm understanding the docs correctly); so it can't (yet) actually load an OS into the ARM from disk or respond to RPCs etc.

In practical terms, this is the biggest, most difficult step forward towards running an almost completely open system on the RPi. (It could also be used as the core of a proper operating system running on the VC4 itself, which could be rather interesting.)"

Reading up on the history of why this was developed, I can see the practical reasons for it (in reverse order) :

david-given on Oct 19, 2016 | root | parent | next [–] I've written some bare-metal stuff on the Pi (somewhere I've got a 90% finished port of Fuzix for it), and oh god yes, that's so true. Being able to do complex stuff like set up a framebuffer by making a simple RPC call to the VC4, passing in a pointer and a descriptor block saying 'this big, please', is so much better than having to do it yourself. But this firmware doesn't contain code to initialise the GPU, it does contain initialisation code for one rather important peripheral, which is the DRAM. The VC4 has been pretty well reverse engineered for a while (I did one of the early C compiler ports for it), but the big missing piece was figuring out how to initialise the RAM. Without that, everything had to fit in the 128kB of built-in SRAM. This firmware's a huge step forward.

makomk on Oct 19, 2016 | root | parent | next [–] In practical terms, this seems to be quite a long way from running a completely open system - the VC4 is responsible for initializing a whole bunch of critical and I believe undocumented hardware that's required to enable any of the peripherals, and this doesn't. Basically, a whole bunch of stuff that'd be implemented by drivers on (say) most Allwinner SoCs I've looked at instead relies on the blob. This is probably part of the reason the Raspberry Pi has relatively good mainline kernel support - they don't have to deal with months of LKML hell to get basic things like clocking and power management working every time they release a new chip because that's all handled in the blob. Many moons ago, I took acting classes. Even though I am not actively auditioning for acting right now, I have, even before I had any interest in acting, a photographic memory (or maybe videographic). I remember other actors lines because I observed these movies so closely. I could recite almost any fact from the Donkey Kong Country 2 strategy guide, even though I didn't purchase the game until much later. I often trained or planned for things I never bought or did, such as making a list of translated Japanese SNES role playing games I wanted to play on notecards.   So a couple film and TV references booted up from cold Seagate brain storage this morning when I thought of a movie that I rented in my high school years- Annie Hall, and Seinfeld (The Contest) episode to analogize what the Video Core processor is to like a standard Pentium or AMD motherboard. From an Annie Hall review, "My enjoyment of this film really comes down to the filmmaking techniques used. There are some true moments of brilliance in Annie Hall. Besides all the framing being spot on, two scenes come to my mind. The first scene is when Annie separates herself from her body as she and Alvy are about to have sex. Alvy persuades Annie to not smoke marijuana before they have sex, solely because he’s a selfish prick and does not like it. Annie states that she needs it to be able to enjoy the experience, but ultimately gives in. Her soul, or personality as it were, separates from her physical body and sits down in a chair next to the bed, showing that Alvy has her body but her mind is wandering. It is a genius visual." In the Seinfeld episode "The Contest", when Elaine, Jerry and George are on the plane, the temporary loss of altitude causes them to reveal, or almost reveal some of their secrets. Jerry proclaims, "I cheated!" before the plane regains engine capabilities. Now, this might be the most unusual comparison of a processor that was optimized for over a decade before it was used as a way to jumpstart and bypass a lot of firmware issues that many systems have in supporting mainline linux or whatever OS they're using, but I can't help but think that implementing a GPU with 32MB of RAM to boot up a Raspberry Pi is a bit of a kludge, and kind of like cheating. If my memory serves me correctly, I think Alvy said that too- about marijuana. Obviously, it's not a rudimentary kludge, as it has been refined over the years, and finely chiseled away to reach its purpose. But it's still a kludge, and maybe not ideal as an educational tool that teaches simplicity. Of course, at the time, this might have been the most economical and practical solution of all, outside of a more resourced competitor, such as Intel. The 8-bit Arduino boards prior to ~2011 were more simplistic in their functionality, and didn't need the extra lift. Of course, there is also limited capabilities in an Arduino, which had several versions released, for this reason. This topic has also been discussed at length on many forums, and doesn't need much more analysis. However, I have long wondered about the lack of common bootloaders on ARM, and this 2016 discussion reveals a lot more about it: yalogin on Oct 19, 2016 | root | parent | prev | next [–] > Traditionally ARMs have never used any kind of common boot process because they come out of the embedded world where every system is bespoke --- the focus is always on individual products, rather than building a platform. This is something I did not know. In the mobile world the boot happens in the UEFI mould right? So when someone licenses from ARM they get to design their own boot sequence? pjc50 on Oct 19, 2016 | root | parent | next [–] Mobile doesn't have UEFI either. Usually what happens is the processor has some minimal boot ROM that can initialise the Flash (and enforce signed boot!), and then it just loads a chunk of Flash into RAM and jumps to it. nanolith on Oct 19, 2016 | root | parent | prev | next [–] Well, it's two different use cases. PCs are platforms, and they have common components and optional peripherals. Embedded systems are completely custom designs that rarely have common components. Everything is driven by BOM cost, and if you don't need something, you don't add it. Booting such a system is highly dependent upon the board configuration and the peripherals that are needed. Furthermore, vendors have different boot-up requirements. Some boot loaders perform proprietary system checks before loading the RTOS. Some boot loaders need to be able to upgrade firmware from an image on-chip, in flash, or fed into it over SPI or a UART. Some boot loaders are little more than a jump table decoder that just jumps to the currently active firmware image on the chip. Creating a universal boot loader with enough flexibility for each of these situations is harder than just implementing a boot loader for a particular electronics product or product family. david-given on Oct 19, 2016 | root | parent | next [–] There's a bit of a trend to embed a tiny ROM in the processor itself that's got just enough intelligence to bootstrap an image off various peripherals. The Broadcom parts work like this for the VC4; the boot ROM can talk to an SD card, parse a FAT filesystem, and load and run the second-stage loader (bootcode.bin). But Allwinner chips do this too, and they're even smart enough to try several different media types (including SATA, IIRC!). Ditto Tegra parts. I imagine that if you're a major customer you get to choose the contents of the boot ROM. From a hacker perspective, it's brilliant, because the devices are completely unbrickable. It doesn't matter how broken they get, you can't change the ROM, which means that you always have ability to get something working. But, of course, they all have entirely different APIs. The VC4 just dumps an image into memory, sets a couple of registers, and jumps to it, and I imagine the others all do the same thing. koytch on Oct 19, 2016 | root | parent | next [–] The only upside of this is unbrickability. Having the boot ROM inside the CPU means you are stuck forever with whatever bugs there are in it. Been there. I do think there are benefits to an "unbrickable" co-processor that can still access the needed components commonly/frequently sought out, but it does create a milquetoast impression/reality that the system isn't fully open/rootable, like Coreboot UEFI/BIOS firmware allows. Maybe since it is educational software, the shadow core is like the bumper bowling of System on a Chips, where anything that goes sideways will get corrected with a new microSD card at the very most of costs. That said, knowing what one knows now, and in a new decade of computing with several open Silicon options, creating a system on a chip that is energy aware represents a different way of thinking about computing. A transparent system is not only open source/libre, but it has an intrinsic system monitor of physical signals that reveal its operations. This is why I want to integrate a solar power manager so much- one can witness the direct correlation of power input, to computation output. The user is not separated by a silkscreen of glitz, but directly able to interact with the performance of the chip, and made aware of the variable collection/generation of photovoltaic or other energy harvesting system. This awareness is self reinforcing, to the extent that the system is responsive and functional, therefore on-chip energy harvesting adds an additional dimension to the interactivity, not to mention granular monitoring and control of computational output- for practical or leisurely use. When a system has a super assistant coprocessor, it will sometimes feel like learning to drive a car, but never testing out a stick shift. I have driven a stick shift before, with the guidance of a relative, but I have never purchased a stick shift car, simply because I didn't want to bother with the dexterity or responsibility of having to shift gears in potentially dynamic traffic conditions. With a system on a chip however, even in mobile platforms, that critical hand off the boot process to the ARM chip from the Video Core IV is less crucial and time sensitive. I have all summer to learn. One of the applications I plan to install on the Galileo is X11 Forwarding. This is a feature that can be enabled on SSH, but I am more curious how well it will run on the Pentium because I have very little knowledge on the amount of Video RAM it (the Galileo board) contains, and how much, if any, is shared with the system RAM (256). My Raspberry Pi 0 shares 32MB of system RAM with the GPU, therefore leaves around 477MB remaining for the OS. This can also be toggled but I have noticed that the default on lighter distros. On my Rpi 3B+, with 1GB RAM, up to 256MB can be set (if I remember correctly). Optimizing VRAM on the Pi Zero: "How to Adjust GPU Memory" "Enter the desired VRAM amount (e.g., 16 or 32 for headless setups, or 128 for heavy emulation like RetroPie)." (Side note: I have noticed many more websites using a CloudFlare or bot-detection screen before I can access them. On a slow connection, I find this incredibly annoying. Enabling cookies can sometimes minimize this, but it also allows website operators to share its visitor data with its hundreds, if not thousands of trusted partners. I've heard the saying in life, that one really only has 5 trusted friends. More than that and you never really know them. Why then, do websites often want to share data with hundreds of advertisers? Anubis is a lighter weight alternative to Cloudflare, and I recommend that, from Techaro.) Having granular control over a CPU and system really allows one to determine and optimize its performance. When I had a Pentium 1 in 1996, I was dependent on a 1MB Cirrus Logic video RAM for all of my OS needs. It was onboard the Packard Bell motherboard, although if I really wanted to, I could have upgraded the GPU with a PCI or ISA card, to 2MB, apparently. The system was already becoming obsolete to newer systems in stores, but I wasn't a slow learner, nor was the system really useless. In comparison, an educational board today might feature 1GB of video RAM, and 8GB of system RAM. I find it hard to believe that all that RAM is necessary to learn how a system works. Of course, newer generations will need modern computers to program robotic arms in the next electric pickup truck of the 21st century, and they will have nostalgic memories 30 years from now how every MB of that GB of VRAM was needed on their credit card sized computer system. For me, it was every KB of that 1MB of VRAM. Hence the SoC I'd like to develop wouldn't need 16MB of VRAM, let alone 32 or 256MB. I am sure there is someone before me who rightly would point out that in the 70s and 80s (and even the 60s), that many CPUs had no VRAM, no HDD, and little to no SRAM. Yes, that is true. and they probably looked at 1KB of VRAM like the way I look at 1MB of VRAM. Sorry people from the Silent Generation, I know you'd like to speak up, and I sympathize with you, since I sound like a brat. You're right, systems today already have more than they need, use far less power, and can probably run everything I want it to, except they have very bespoke bootloaders. Things I will be testing/researching this week. Does the Galileo use a 2D video accelerator, or 3D? Can it emulate 3D entirely on the CPU? Can it run Xwindow server, and then allow me to set up X11 forwarding so I can use a VNC-like window to observe the Galileo booting up Debian with say, LXDE, or Xfce? Action Retro's Youtube channel got Tiny Core Linux to run on a Pentium smoothly with 128MB of RAM, although I am not sure how much that Pentium system included with video RAM. There may be other distros that use even less VRAM while still capable of booting a 3.x-7.x kernel. But fbdev or other Xwindowless server might be too difficult for what I'm trying to do. Since the Rpi includes HDMI out, it's far easier to test the GPU. The Galileo doesn't have one of these, although SPI could be configured to display to various SPI displays. I don't have that patience, since it will be an accomplishment alone if I can boot my Galileo firmware and get linux or an RTOS to load. So far, I was able to connect it to my router on an intranet only (it displayed an IP address- 192.168.1.3, but instead of clanton, it displays <unknown>. It's possible the firmware is bricked, but most likely it just has an OS that isn't really interacting with anything it was programmed for. It also probably has a custom firmware from the person who sold it to me. I am just hoping it's not bricked. It probably can be recovered. I will try Rawrite32, which I read can be used to dd the image to SD. While I have Rocky Linux installed, most tutorials for the Galileo use debian as the host/client to talk to the SSH server on the Galileo, so I will need to convert some of the instructions like "apt" to "dnf" for some installaitons. Why I installed Rocky instead of Debian-based linux is kind of a long story, but it doesn't have to do with any former protestations on systemd, but rather bandwidth and finding the first OS that "works." For example I spent all of yesterday morning writing Linux Mint 20, 16 and Ubuntu 16 to an SD card, only for one of my PCs to notice a laundry list of device descriptor errors and an initramfs image no where to be found on an SD card, even after completing a full format. Using 4 different image writers, Rpi Imager, Balena, Rufus, and Unetbootin, I gave up on Those linux distros for now. One little peeve of Rocky 9.5 is that every time it boots up, it casually reminds me that I'm using an x86_64v2 system and that it won't be supported in the future (I know that, and as of 10.1, they dropped it). I don't mind that, although I wish I could save a second of boot time to see that splash screen hidden.    The only thing it didn't detect was a newer 5GHz wireless usb driver, so I luckily had a 2.4Ghz TP-Link USB adapter that it was plug and play. I installed Fedora way back in 2009 or 2010 (when it was 32 bit too), and recall it often worked out of the box, almost as well as Debian, and sometimes better than it. For now I am enjoying the integration of Wayland and my GPU, which has desktop animation support out of the box (the Compiz like wobble transitions and whatnot). Part 3 may be posted when I actually have something to report. Ideally it will be something like SSH returning a ping other than "connection refused." Or a SSH window to Windows 95 or 2000, or a window to Xserver. That is why I title some of my Youtube videos, like this one 2 of X, since I don't know how many parts there will be, and often don't retroactively update the X to a number after I post the last in each series of videos. Edit: The darn Hacker News HTML elements/ blocks that I inserted into the post midway had the unintended (but common) effect of indenting my paragraphs after one of the quotes with the same alignment, so I was only able to insert a line break to indicate where I begin writing. Until I can figure out how to clear up the paragraph indents, it may require a closer reading. Sorry (I don't have an assistant to help me with this, and I probably should use less formatted pages to avoid this trap). Fixed.