Funny how we still call it a CD image, are there actually any AArch64 Windows laptops with a CD drive? Can you even boot from an external CD drive on such laptops?
I'm pretty sure that even x86 UEFI cannot boot from CDs/DVDs (unless they are in BIOS emulation mode). This is the reason why physical retail Windows 10 images are in a read-only USB.
Update: some enterprise UEFI setups do boot from DVDs but the ISO should be a hybrid type (aka must have EFI-style partitions).
UEFI supports bootable DVDs, although they use an extension of El Torrito. See section 13.3.2.1 of the UEFI Specification, Version 2.8.
> To boot from a CD-ROM or DVD-ROM in the boot services environment, an EFI System partition is stored in a “no emulation” mode as defined by the “El Torito” specification.
This was chosen specifically to allow polyglot ISO files that can both be booted bh UEFI and legacy BIOS. The implementation of tools to create such polyglot files are, to say the least, interesting. The tools effectively generate both a FAT and ISO partition, each having its own file information table, but sharing the actual file contents.
Matthew Garrett wrote about this, about a decade ago. It turns out you can create an iso/usb hybrid image that boots correctly on all combinations of BIOS/UEFI, optical disc/usb drive, and PC/Mac.
Dreamcast uses El Torito for booting as well, I bet you could make that work too. Possible issues are that I don't know if the Dreamcast will inspect multiple boot images to find an appropriately labeled one, and I don't know if the other platforms will accept a bootable disc that's prepared for Dreamcast (must have at least two sessions, first session audio, second session data with el torito for booting)
Ultimately they had to if they wanted BIOS to be able to boot CD-ROMs. The BIOS boot sequence sticking around for so long is an unfortunate consequence of it becoming a decentralized standard outside of any one vendor's control, and so the only way to make it all work was for vendors to agree, and the solutions wouldn't be obvious or trivial in most cases because that boot sequence is incredibly primitive and full of assumptions coherent in a system with two floppy drives and maybe a disk if you were lucky.
But I'm sure the bad blood was measurable, especially for the higher-ups.
UEFI doesn't much care what sort of storage medium something is on, so long as it is capable of reading it and it has a valid EFI partition. It is much less picky than BIOS, for which the El Torito standard had to be invented, and can be implemented easily on disks that use that format for dual-use. I haven't encountered UEFI implementations that don't support optical disks but I imagine it is possible there are some laptop vendors that might not have implemented optical drive support.
That is sort of an interesting question on its own. Those born after 2000 didn't know anything about the "Save Icon" ( Floppy Disc ). And those born after 2010s, might never have seen a CD or DVD.
A CD is like a DVD with only sound. A DVD is like a Blu Ray but can't hold as much. A Blu Ray is what your PlayStation/Xbox games come on. Given the popularity of game consoles and that most of them still use optical media, I don't think CD/DVDs are things that a young person would be unfamiliar with. Unlike floppy disks which have no equivalent or use for average people these days.
That's kind of horrifying in itself, considering I don't think there's a viable alternative for (WORM) mid-to-long term data storage most people have access to.
Of course, in practice with optic media you may stumble upon varying forms of bit rot, scratches or recording errors so it's definitively not the be-all and end-all, but still, I've got CDs recorded 30 years ago I can still read in modern systems and that I won't wipe by accident.
Blu-ray's are still reasonably common, though they are slowly disappearing as well and I don't think there will ever be a successor. Fact is that write-once read-many is just not considered a very valuable property by itself, and as rewritable storage is becoming cheaper (if only by economies of scale) it'll displace them.
I didn't know one could run Linux on ARM64/AArch64 Windows laptops. I assumed they were "Windows Only" at a firmware level (Secure Boot forced on without any ability to opt-out or some form of signed MS only bootloader support)
Between this and Marcan42 on Twitter working on Linux for M1 Macs, I'm hopeful that ARM64 Linux devices will slowly start to creep in further
The MS requirements for Windows require secure-boot enabled by default and only with the MS key. It is optional whether OEMs allow secure-boot to be disabled and/or set to a mode where other signing keys can be added.
When secure boot started to go mainstream there was a lot of FUD that it was really just a mechanism to lock out alternative OSes.
The reality is that hardware manufactures do not care what OS you run, as long as it doesn’t result in costly hardware returns or endless support calls. This is why hardware typically has options to disable OS-specific. secure boot, but it requires some technical steps that average users won’t accidentally stumble upon.
The M1 macs were never locked down, either. Apple has said that Microsoft can make Windows builds for them if they’d like. Linux on M1 macs is only a matter of time.
Secure boot is a net win for everyone. Having an option to disable it lets the 0.01% of people who want to run Linux use the hardware too.
>When secure boot started to go mainstream there was a lot of FUD that it was really just a mechanism to lock out alternative OSes.
It wasn't just FUD. Microsoft has changed their tune on this over the years, but it used to be that their certification requirements mandated that users could not disable secure boot on ARM devices: https://arstechnica.com/information-technology/2012/01/micro...
If that were still their policy today, it would make projects like this nearly impossible.
From what I've been made to understand by friends at Apple all they have to do is figure out iBoot. They suspect we'll have linux on M1 macs within the next 6 months.
There have been discussions that ARM based machines will have UEFI forced to enabled Secure Boot with a key that doesn't let Linux bootloaders run, so this would not be the same. x86 laptops and PCs generally allow replacing the boot key, or disabling Secure Boot altogether.
You're thinking of 32-bit ARM machines. The 64-bit ARM software story is very different and I have yet to find an arm64 laptop that can't boot a different OS.
Someone will almost definitely get Linux running on the Mac, but only because of talented people working on it for free (which is both a shame and slightly concerning given how some people seem to be completely suckered in by Apple)
Agreed. The claim is "The reason behind it is that EFI variables are stored on UFS, while firmware and OS cannot share the UFS device."
Ok, but why can't it use the EFI runtime services to write to the efi vars, like Windows' bcdedit does? After all, bypassing the firmware to write the vars should actually be riskier, as to my knowledge UEFI does not mandate any specific format for them in NVRAM, so a vendor very much could use a custom format if they wanted, even though almost everybody just uses a modified version of the reference implementation.
I think that probably answers my question. There is a raw memory space for efivars that is accessible by the kernel but might also be under control of lower-level runtime services. If that is truly the case then I agree with you, the kernel should default to using the efi runtime to modify the efivars.
On Windows, Qualcomm uses the SCM driver to hook the Get/SetVariable implementation and replace it with their own.
The UEFI standard SetVariable implementation is nonfunctional and the GetVariable one is at the same state since ExitBootServices.
This is due to the fact that the firmware and the OS cannot control the storage device at the same time. The issue isn't seen on most x86 PCs since those use a separate SPI flash chip for the UEFI.
