Broadcast Engineer at BellMedia, Computer history buff, compulsive deprecated, disparate hardware hoarder, R/C, robots, arduino, RF, and everything in between.
5793 stories
·
5 followers

Linux Fu: UEFI Booting

1 Share

Unless your computer is pretty old, it probably uses UEFI (Unified Extensible Firmware Interface) to boot. The idea is that a bootloader picks up files from an EFI partition and uses them to start your operating system. If you use Windows, you get Windows. If you use Linux, there’s a good chance you’ll use Grub which may or may not show you a menu. The problem with Grub is you have to do a lot of configuration to get it to do different things. Granted, distros like Ubuntu have tools that go through and do much of the work for you and if you are satisfied with that, there’s no harm in using Grub to boot and manage multiple operating systems.

An alternative would be rEFInd, which is a nice modern UEFI boot manager. If you are still booting through normal (legacy) BIOS, the installation might be a hassle. But, in general, rEFInd, once installed, just automatically picks up most things, including Windows, Mac, and Linux operating systems and kernels. The biggest reasons you might change the configuration is if you want to hide some things you don’t care about or change the visual theme.

Basics

A UEFI computer stores boot information in nonvolatile RAM. You can examine this and even make some changes using the Linux utility efibootmgr:


$ efibootmgr
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004,0003,0001,0002,0005,0006
Boot0001* UEFI OS
Boot0002* UEFI:CD/DVD Drive
Boot0003* ubuntu
Boot0004* rEFInd Boot Manager
Boot0005* UEFI:Removable Device
Boot0006* UEFI:Network Device

Generally, you won’t want to directly add or delete things using this tool, even though you can. Usually, your operating system takes care of all that. However, it is a pain to pick one partition over the other if you, for example, boot Windows and Linux. You can see from the above dump that I don’t do this, at least not on this computer. However, I do often boot from a removable disk or have multiple kernels or even operating systems installed in different places.

Grub can handle all this, of course. Especially if you use a distribution with a lot of tools, they will scan, looking for things, and rebuild your grub configuration. But if that configuration ever goes bad and you forget to build, look out! Time to boot from a rescue disk, more than likely. Grub is both a boot loader and a boot menu. But rEFInd is a boot menu manager only.

Pros and Cons

There are several reasons you might opt for rEFInd. The biggest practical reason is that it scans for bootable items on every boot. It is also nice looking and can support touchscreens and mice, but not both at the same time. There was an Ask Ubuntu post where the author of rEFInd listed the pros and cons between his code and Grub. His advantages list include:

  • Scans for new kernels on every boot
  • Eye candy
  • Reliable booting fo Windows with secure boot active
  • Able to launch BIOS-mode bootloaders
  • Ability to speed up installs if you don’t install Grub at all
  • Strict enforcement of secure boot policies

Of course, there are also some downsides. Grub is the “official” way to handle things for most distributions and you can assume distros and tools will be compatible with it. It relies primarily on a single developer. Grub is easier to use with networking, LVM, and RAID booting, although these are possible with rEFInd, too. Because rEFInd scans on each boot, there is a brief pause when you boot, of course.

It is possible to have rEFInd boot into Grub, and that can be useful sometimes, but in general, you’ll want to use rEFInd instead of the Grub menus. One exception is if you want an emergency USB drive with rEFInd on it, that might be useful since it can mostly configure itself.

Install

If you use a distro that can handle Ubuntu PPAs, installing the program is simple.


sudo apt-add-repository ppa:rodsmith/refind
sudo apt-get update
sudo apt-get install refind

You can also find detailed instructions on installing in special cases on the project’s website. Once you install, you probably don’t have to do anything, but you might want to browse the configuration file (something like /boot/efi/EFI/refind/refind.conf). There you can adjust a few things like timeouts, default kernel options, and the like. There are quite a few options, but most of them are commented out.

You can also make manual entries, much like Grub. There are several examples in the default configuration file, but you’ll notice they all have the disabled keyword in them, so you would remove that keyword after making changes to suit you. You can also pick a text-based mode, the default screen resolution, and other parameters. I changed the line to show some tools (like reboot or boot into BIOS setup) that were not on by default. In many cases, you won’t need any changes at all.

If you see entries on the screen you don’t want, highlight them and press the minus sign. Don’t worry, you can manage the “hidden tags” using a menu if you change your mind later.

Be warned that while the system does support secure boot, if you use it, it may need a little tweaking. Here’s the good news. If it doesn’t work, just change the boot order back to boot Grub first and you can troubleshoot from there.

Themes

One fun thing you can do is get different themes for the program. These are just collections of artwork used as the banner and as icons for different distributions. For some reason, the program didn’t automatically pick up my Neon with the Neon logo, even though it was present. My simple solution was to replace the default Tux penguin with a copy of the Neon logo.

I’ve read that pressing F10 will screenshot rEFInd, but apparently, I don’t have the latest version, so I had to rely on my phone to take an old-school screenshot. You can see why I changed the penguin logo.

 

The tools along the bottom let you run a memory test, or reboot and shut down. You can also launch an EFI shell or alter the EFI boot order.

Low Risk

Any time you dink with the booting of your computer, you are taking a risk. However, if you install with Grub, you can always leave it as an option from rEFInd. If you get in big trouble, Grub is still there and you can boot from a rescue medium and use efibootmgr to pick your default Grub setup. The documentation for rEFInd has a good writeup on what the author calls “boot coups” when an operating system — looking at you, Windows — presumptively takes over booting.

If you don’t dual boot, you can probably stick with Grub. It is nice to have a more modern-looking boot menu, but it isn’t that compelling. But if you dual boot with Windows, Mac, or other EFI-capable operating systems, or even if you change kernels often, you should really check out rEFInd.

For some specialized cases, you might want to check out a specialized fork of rEFInd, which offers certain additional features. You can find out more about the differences on its home page.

If you want more technical details on UEFI, here you go. Of course, as Scotty famously said, “The more they overthink the plumbing, the easier it is to stop up the drain.” UEFI is a big attack target, and it has been hit before.

Read the whole story
tekvax
6 days ago
reply
Burlington, Ontario
Share this story
Delete

What Else Is An M.2 WiFi Slot Good For?

1 Share

Many mainboards and laptops these days come with a range of M.2 slots, with only a subset capable of NVME SSDs, and often a stubby one keyed for ‘WiFi’ cards. Or that’s what those are generally intended to be used for, but as [Peter Brockie] found out when pilfering sites like AliExpress, is that you can get a lot of alternate expansion cards for those slots that have nothing to do with WiFi.

Why this should be no surprise to anyone who knows about the M.2 interface is because each ‘key’ type specifies one or more electrical interfaces that are available on that particular M.2 slot. For slots intended to be used with NVME SSDs, you see M-keying, that makes 4 lanes of PCIe available. The so-called ‘WiFi slots’ on many mainboards are keyed usually for A/E, which means two lanes of PCIe, USB 2.0, I2C and a few other, rather low-level interfaces. What this means is that you can hook up any PCIe or or USB (2.0) peripheral to these slots, as long as the bandwidth is sufficient.

What [Peter] found includes adapter cards that add Ethernet (1 Gb, 2.5 Gb), USB 2.0 ports, SIM card (wireless adapter?), an SFP fiber-based networking adapter, multiple M.2 to 2+ SATA port adapters, tensor accelerator chips (NPUs) and even a full-blown M.2 to x16 PCIe slot adapter. The nice thing about this is that if you do not care about using WiFi with a system, but you do have one of those ports lounging about uselessly, you could put it to work for Ethernet, SFP, SATA or other purposes, or just for hooking up internal USB devices.

Clearly this isn’t a market that has gone unexploited for very long, with a bright outlook for one’s self-designed M.2 cards. Who doesn’t want an FPGA device snuggled in a PCIe x2 slot to tinker with?

(Thanks to [RebootLoop] for the tip!)

Read the whole story
tekvax
6 days ago
reply
Burlington, Ontario
Share this story
Delete

Inside Globus, a Soviet-Era Analog Space Computer

2 Shares

Whenever [Ken Shirriff] posts something, it ends up being a fascinating read. Usually it’s a piece of computer history, decapped and laid bare under his microscope where it undergoes reverse engineering and analysis to a degree that should be hard to follow, but he still somehow manages to make it understandable. And the same goes for this incredible Soviet analog flight computer, even though there’s barely any silicon inside.

The artifact in question was officially designated the “Индикатор Навигационный Космический,” which roughly translates to “space navigation indicator.” It mercifully earned the nickname “Globus” at some point, understandable given the prominent mechanized globe the device features. Globus wasn’t actually linked to any kind of inertial navigation inputs, but rather was intended to provide cosmonauts with a visual indication of where their spacecraft was relative to the surface of the Earth. As such it depended on inputs from the cosmonauts, like an initial position and orbital altitude. From there, a complicated and absolutely gorgeous gear train featuring multiple differential gears advanced the globe, showing where the spacecraft currently was.

Those of you hoping for a complete teardown will be disappointed; the device, which bears evidence of coming from the time of the Apollo-Soyuz collaboration in 1975, is far too precious to be taken to bits, and certainly looks like it would put up a fight trying to get it back together. But [Ken] still manages to go into great depth, and reveals many of its secrets. Cool features include the geopolitically fixed orbital inclination; the ability to predict a landing point from a deorbit burn, also tinged with Cold War considerations; and the instrument’s limitations, like only supporting circular orbits, which prompted cosmonauts to call for its removal. But versions of Globus nonetheless appeared in pretty much everything the Soviets flew from 1961 to 2002. Talk about staying power!

Sure, the “glass cockpit” of modern space vehicles is more serviceable, but just for aesthetics alone, we think every crewed spacecraft should sport something like Globus. [Ken] did a great job reverse-engineering this, and we really appreciate the tour. And from the sound of it, [Curious Marc] had a hand in the effort, so maybe we’ll get a video too. Fingers crossed.

Thanks to [saintaardvark] for the tip.

Read the whole story
tekvax
6 days ago
reply
Burlington, Ontario
Share this story
Delete

Generating PAL Video With A Heavily Overclocked Pi Pico

1 Share

Barely a week goes by without another hack blessing the RP2040 with a further interfacing superpower. This time it’s the turn of the humble PAL standard composite video interface. As many of us of at least a certain vintage will be familiar with, the Phase Alternate Line (PAL to friends) standard was used mainly in Europe (not France, they used SECAM like Russia, China, and co) and Australasia, and is a little different from the much earlier NTSC standard those in the US may fondly recollect. Anyway, [Fred] stresses that this hack isn’t for the faint-hearted, as the RP2040 needs one heck of an overclock (up to 312 MHz, some 241% over stock) to be able to pull off the needed amount of processing grunt. This is much more than yet another PIO hack.

The dual cores of the RP2040 are really being pushed here. The software is split into high and low-level functions, with the first core running rendering the various still images and video demos into a framebuffer. The second core runs in parallel and deals with all the nitty-gritty of formatting the frame buffer into a PAL-encoded signal, which is then sucked out by the DMA and pushed to the outside world via the PIO. There may be a few opportunities for speeding the code up even more, but [Fred] has clearly already done a huge amount of work there, just to get it working at all. The PIO code itself is very simple but is instructive as a good example of how to use multiple chained DMA channels to push data through the PIO at the fastest possible rate.

Beyond the Pico PCB, the only extra hardware needed was a resistor-ladder DAC implemented on a solderless breadboard. [Fred] needed a couple of goes to get the correct DAC resistor values, the first version was built on a small prototyping PCB, but unfortunately, the peak voltage was only 1 V, so it was necessary to build a second version (hence the breadboard) to get it to the correct 1.25 V.

We’ve covered video hacks on diminutive hardware many a time, even going into some details of the various standards, like this piece on just why is NTSC so odd? But as time marches on, video standards have gone through vast changes to get to where we are now.

via Adafruit.

Read the whole story
tekvax
6 days ago
reply
Burlington, Ontario
Share this story
Delete

Translating and Broadcasting Spoken Morse Code

1 Share

When the first radios and telegraph lines were put into service, essentially the only way to communicate was to use Morse code. The first transmitters had extremely inefficient designs by today’s standards, so this was more a practical limitation than a choice. As the technology evolved there became less and less reason to use Morse to communicate, but plenty of amateur radio operators still use this mode including [Kevin] aka [KB9RLW] who has built a circuit which can translate spoken Morse code into a broadcasted Morse radio signal.

The circuit works by feeding the signal from a microphone into an Arduino. The Arduino listens for a certain threshold and keys the radio when it detects a word being spoken. Radio operators use the words “dit” and “dah” for dots and dashes respectively, and the Arduino isn’t really translating the words so much as it is sending a signal for the duration of however long each word takes to say. The software for the Arduino is provided on the project’s GitHub page as well, and uses a number of approaches to make sure the keyed signal is as clean as possible.

[Kevin] mentions that this device could be used by anyone who wishes to operate a radio in this mode who might have difficulty using a traditional Morse key and who doesn’t want to retrain their brain to use other available equipment like a puff straw or a foot key. The circuit is remarkably straightforward for what it does, and in the video below it seems [Kevin] is having a blast using it. If you’re still looking to learn to “speak” Morse code, though, take a look at this guide which goes into detail about it.

Thanks to [Dragan] for the tip!

Read the whole story
tekvax
6 days ago
reply
Burlington, Ontario
Share this story
Delete

Homebrew Telephone Exchange Keeps the Family in Touch, in the House and Beyond

1 Share

It doesn’t happen often, but every once in a while we stumble upon someone who has taken obsolete but really cool phone-switching equipment and built a private switched telephone in their garage or basement using it. This private analog phone exchange is not one of those, but it’s still a super cool build that’s probably about as ambitious as getting an old step-by-step or crossbar switch running.

Right up front, we’ll stipulate that there’s absolutely no practical reason to do something like this. And hacker [Jon Petter Skagmo] admits that this is very much a “because I can” project. The idea is to support a bunch of old landline phones distributed around the house, and beyond, in a sort of glorified intercom system. The private exchange is entirely scratch-built, with a PIC32 acting as the heart of the system, performing such tasks as DTMF decoding, generating ring voltage, and even providing a CAN bus interface to his home automation system.

The main board supports five line interface daughterboards, which connect each phone to the switch via an RJ11 jack. The interface does the work of detecting when a phone goes off-hook, and does the actual connection between any two phones. A separate, special interface card provides an auto-patch capability using an RDA1846S RF transceiver module; with it, [Jon Petter] can connect to any phone in the system from a UHF handy-talkie. Check out the video below for more on that — it’s pretty neat!

We just love everything about this overengineered project — it’s clearly a labor of love, and the fit and finish really reflect that. And even though it’s not strictly old school, POTS projects like this always put us in the mood to watch the “Speedy Cutover” video one more time.

Read the whole story
tekvax
15 days ago
reply
Burlington, Ontario
Share this story
Delete
Next Page of Stories