Upgrading the ASRock TRX50 WS Motherboard Firmware

 Computing, Working Notes  No Responses »
Apr 172024
 

Well that was interesting …

So I decided to upgrade the firmware on my ASRock TRX50 WS motherboard tonight. Partially because I had planned on trying it to sort out a mysterious crashing problem (which turned out to be the world’s worst SATA SSD ‘error’), and partially because I’d like to make sure I know how the process works. And funnily enough, finding ASRock’s instructions aren’t so simple.

The first really rather obvious step is to download the firmware from the ASRock support site. This comes down as a ZIP file, which needs to be unpacked :-

  • TRX50-WS_9.03.ROM

This needs to be copied to a USB stick formatted as FAT32, but whilst you’re checking that make sure that the partition type is set to an appropriate value (0x0b is the value I used; the second time), because it turns out that the ASRock firmware won’t recognise a FAT32 filesystem just based on the actual filesystem – it checks the partition types.

But before you shut down and start the upgrade process, record any firmware settings you may have made … for better or worse, the upgrade will reset any changes you have made.

Starting the upgrade is fairly simple – go into Setup, move across to Tools and select the “Instant Flash” option. This will pop up a menu of different firmware version files it has found that are compatible with your motherboard. Select the version you want (in my case it was just one option), and press Return.

After a warning, it’ll start the upgrade process; this consists of :-

  1. A progress bar which slowly progresses to 100%
  2. A reboot which takes you back into the firmware.
  3. A second progress bar which also progresses slowly.
  4. At some point when this has finished, it’ll just sit there for a few minutes and finally start booting with the new firmware.

Of course in my case, the settings reverting to default values resulted in the SlimSAS controllers both being reset to “NVME” rather than “SATA” meaning half my storage array wasn’t present! But it all worked in the end :-

✓ root@pica» dmidecode -s bios-version
9.03

Of course ASRock claim you only do a “BIOS Upgrade” (I hate that word “BIOS” – it’s not really appropriate) when it is absolutely necessary, but an upgrade when it isn’t necessary isn’t a bad idea. Just to get practice.

It should be noted that the firmware should be update-able with fwupdmgr so any urgent updates may well come via that route.

The Missing Sign

The Year Of Linux On The Desktop

 Computing, Linux  No Responses »
Aug 272017
 

Every so often, somebody (or organisation) proclaims that this year is the year of Linux on the desktop. Given the number of times this has occurred, you would have thought that the Cassandras of the Linux world would stop trying to predict it. In fact I am not entirely sure what it is supposed to be – everyone using Linux on the desktop, or just some? And if it is just some people, how many?

It is essentially nonsense – if you use Linux on the desktop, every year is the year of Linux on the desktop; and if you do not, it isn’t.

Assuming you are someone who has more than two brain cells to rub together and are prepared to do some learning, it is perfectly possible to run Linux on the desktop. You can do pretty much everything with Linux that you can do with Windows. In fact the one area that Linux is traditionally weak – upgrading firmware of third party devices (such as media players, wireless mice – is beginning to change with LVMS and fwupd.

To give an example, I was recently upgrading some Logitech wireless mice to eliminate a serious security flaw, and I tried with Windows, OSX, and finally Linux. Both the Windows and OSX methods failed, whereas the Linux method just worked.

In fact even if the Windows method had worked, it would have been a lot more complex. I had to download the Logitech software (admittedly this step would probably be unnecessary if I was used to using the wireless mouse under Windows), know that a firmware upgrade was necessary, download the firmware upgrade, and finally load it into the upgrade tool.

Under Linux? Assuming I had been using some gooey tool like GNOME Software, it would have notified me that an upgrade was available and after a request would have upgraded it for me. I (of course) chose to do it the geeky way from the command-line, but even so running :-

# fwupmgr refresh
# fwupmgr update

… is a great deal simpler than the Windows way. And that is before you consider that with Windows, you need to download a firmware update tool for every device whereas the Linux way it is just one tool.

Of course in practice, the Linux method only works for a handful of devices – of the innumerable Linux machines I run only one has available updates for the desktop computer’s firmware (the Dell at work), and of the peripheral (or not so peripheral) devices only a tiny handful can be upgraded today.

But it is not inconceivable that in the not too distant future, the sensible way to upgrade the firmware of various devices will be to install Linux, and let it do it for you. Particularly if device manufacturers realise that by adopting Linux as the firmware upgrade delivery method, they can save time and effort.

“But I know Windows” – actually you know Windows 7, or Windows XP, or Windows 10; each of which is very different from each other. And whilst Linux has even more variability at first glance, there is actually more commonality between different versions of Linux. Or in other words, the effort of learning Linux in the first place is rewarded by less of a need to completely re-educate yourself every time you upgrade.

This is not intended as encouragement for you to switch to Linux (although if you are involved in IT you should at least be familiar with Linux), but intended as a criticism of the concept of a year of the Linux desktop. It isn’t useful, and what is worse it leads to the false impression of failure – if everyone is not using Linux on the desktop, then Linux has failed.

Linux on the desktop has not failed because I use it on the desktop.

Exploring (U)EFI

 Computing, Linux, Working Notes  No Responses »
Aug 152014
 

This post is likely to change frequently after it first appears as experiments/research/etc. occurs to me.

To get to grips with it, let’s first define the software that is in control of your PC when it first starts as the system firmware rather than the BIOS, as system firmware is a generic term which can refer to BIOS, EFI, UEFI, OpenFirmware, or anything else that someone comes up with.

UEFI (and the older EFI) is a replacement for the legacy BIOS that we’ve been stuck with for decades. Despite advances in almost every aspect of the “PC standard”, the BIOS has hardly advanced at all. To be fair, the user interface has gotten a bit less 1980s, and it of course deals with hardware devices that weren’t even imagined decades ago. But there are still some rather nasty limitations, which UEFI is supposed to resolve.

Of course there are those who claim that UEFI is a complete mess with no redeeming qualities, but the truth is probably somewhere between it being that and the neatest bit of system firmware ever invented.

This posting are my working notes (with the addition of a bit of pointless waffling) on UEFI, given that I’m likely to be found staring at a UEFI shell on a broken server at some point in the future. All experiments (so far) have been carried out with a VirtualBox-powered virtual machine (with UEFI turned on) running Ubuntu server.

Installation

The boot process looks a little different … unsurprisingly. And there’s an error in relation to missing UEFI stuff from the hard disk. But once the CD is booted the process looks the same …

Partitioning: Initially “Guided – use entire disk and set up LVM”

Doesn’t give an opportunity to review the partitioning, but :-

  1. EFISystem (/boot/efi) is roughly 512Mbytes
  2. /boot is roughly 256Mbytes
  3. LVM Volume Group

The Ubuntu installation uses grub as the boot loader, although it’s hardly the only option and there are hints that grub has been known to have issues with EFI. Although this could be “early adopters pain”, and not applicable currently.

GPT Partitions

See the Wikipedia article, but basically GPT replaced the old Master Boot Record partitions. The main advantage is that there are fewer dumb limits with GPT – there is no limit of 4 primary partitions (and no hacks to support extended partitions), but instead a minimum maximum of 128 partitions, which basically translates as the required minimum size of a partition table allows for up to 128 partitions but the partition table can be bigger.  More than you’re likely to need anyway.

Cleverly (if you want to put it that way), GPT can live alongside the old MBR partitions as the GPT starts at block 1 rather than block 0. This has been used by Apple to keep two partition tables so that OSX can use GPT whilst Windows still uses MBR.

Keeping two partition tables in sync is perhaps not the best idea for stability and given the need for backwards compatibility has only a limited useful lifetime, I’d rather live without it. In fact it would be nice if I could fill up the old MBR with stuff that told all MBR tools not to mess around with the partition tables.

In theory, (U)EFI and GPT are independent of each other, but in practice, GPT implies booting from UEFI and MBR implies booting from BIOS (some UEFI implementation switch to a BIOS-compatibility mode when they see an MBR).

The EFI System Partition

(U)EFI requires that to boot, a disk must have an EFI System Partition formatted as FAT. This is used as effectively a replacement for the BIOS boot method of loading code from block 0. This file system is usually mounted under Linux as /boot/efi and contains various files that allow Linux to be booted (more details to be added).

It is perhaps a shame that the EFI standards people didn’t suggest making the EFI system partition part of the on-board firmware. It wouldn’t be impossible (or very expensive) to incorporate a small writeable FAT file system into the motherboard to avoid the need for the EFI partition on one of the storage disks. It is not as if the EFI system partition needs to be very big – Ubuntu configured one as 512Mbytes in size which is vastly larger than required for what is actually installed which adds up to less than 4Mbytes.

EFIBOOTMGR

The tool efibootmgr is for interacting with the EFI boot manager and the EFI variables that control what gets booted in which order :-

# efibootmgr
BootCurrent: 0003
BootOrder: 0003,0000,0001,0002
Boot0000* EFI DVD/CDROM
Boot0001* EFI Hard Drive
Boot0002* EFI Internal Shell
Boot0003* ubuntu

The command has plenty of other options …

You can set the boot order with: efibootmgr -o 0002,0003,0001,0000. So I’ve set the preferred boot order to include the internal shell first … the purpose here is to look into EFI after all.

I also somehow managed to erase the “ubuntu” so re-created that with: efibootmgr -c -L UbuntuServer -l “\EFI\ubuntu\shimx64.efi” (yes unfortunately they use the wrong path separator).

EFI Shell

Is surprisingly limited. And rather too DOS-like for me.

Command Description
help Displays a list of the commands available … which very unhelpfully doesn’t pause at the end of the screen. Can also display additional details of a command if you try help command.
mode Displays a list of the available screen mode commands.
mode x y Sets the screen mode to the size specified (as listed with mode).
cls Clears the screen.
cls ${n} Clears the screen and sets the colours to a set specified by the number (0-7). Don’t bother; most of the choices are nasty.
map Displays teh mapping table showing the block devices (BLK${n}) and the recognised file systems (FS${n}). If you don’t have fs0 you’ve got problems!
fs0: Sets the specified file system as the current file system. This will change the prompt appropriately.
cd ${directory} Changes to the specified directory. Remember that the path separator is the DOS preferred character (\).
ls Lists files in the current directory.
edit ${filename} Edits the specified file (^S saves, ^Q quits), but don’t try editing files ending in .efi!
${filename}.efi Runs the EFI binary from the current directory, and yes that does mean you can boot Ubuntu Server by browsing to the \EFI\ubuntu directory and entering shimx64.efi (as I discovered after breaking the ubuntu boot option).

An Open Letter To Apple/Steve Jobs Regarding Closed iPods (Encrypted Firmware, etc.)

 Computing  No Responses »
Sep 212007
 

Well this is not so much a letter as just a rant because I’m very doubtful that anyone from Apple never mind Steve Jobs is likely to read this. But it is good to get a good rant off your chest and out there (which basically explains this whole site … it is not for you … it is for me). Especially after a few glasses of port!

I currently own an iPod video and have been thinking about buying a Macbook, but I have been doing some rethinking after the announcment of the iPod Classic. It seems that Apple have encrypted the iPod Classic firmware again (the Nano 2g firmware is also encrypted) and have added a hash to iTunes just to make things a little more difficult for those who like to do “unusual” things with their iPods.

I am a Rockbox user (I haven’t even used the normal firmware on my iPod except when I’ve booted it by mistake) mostly because most of my CDs have been encoded in OGG format and I really did not want to re-encode them in any other format because of how long it would take. So Apple have made money out of me because I purchased an iPod; I’m beginning to regret that because Apple seems to be determined to be the kind of business that I don’t want to fund.

First of all there is the encryption of the firmware. I am sure that Apple is aware that hackers have produced not only alternative firmwares but also a utility to patch the default firmware to make interesting changes. So why the encryption ? Obviously to make things difficult for the hackers. In some situations smaller companies may be forced to do something similar because larger companies want to “protect their intellectual property rights”, but Apple is in a dominant position in the portable music player music market … they are the ones who will be dictating the contract terms.

Secondly Apple changed iTunes in an attempt to lock out other music managers. The fact that this protection has been hacked and is no longer a problem is irrelevant … Apple showed their colours by making it difficult to use anything other than iTunes.

A few years ago when it was trendy, Apple embraced the open source model by releasing some of their operating system as open source. Despite apparently trying to improve their operating system by incorporating a open source filesystem (ZFS), they seem to be rapidly retreating from this position. Or at least giving the appearance of doing so. So perhaps their earlier embracement of open source was just a marketing move … something you might expect from Microsoft.

Apple is giving the impression of trying to become a company as user-hostile as Microsoft.