Why, instead of safely entering a BIOS setup, does the cell phone brick when installing the Custom ROM wrongly? Wouldn’t this protection be better for users? I mean, this could be done through ADB.
Also, do you think it’s possible that this way of doing things will come to the computer, with ARM hoping to gain a good share of the market and all?
You must log in or # to comment.
Phones don’t brick with installing a ROM wrong just the same PCs don’t brick when you fail to install an OS correctly on it. It just doesn’t have a bootable OS on it.
Most phones have a download mode / fastboot which does exactly what you’re asking for. You can pretty much always reflash a valid OS with fastboot.
BIOS on PCs is used for compatibility because most hardware manufacturers want to be compatible with existing operating systems. ARM does support UEFI.
Phones just don’t have UEFI, because 99.999% of the time it will run only one operating system: the manufacturer’s flavor of Android. Skipping an UEFI makes it boot faster because it can load directly into the Linux kernel which will initialize the hardware and already knows the precise hardware it’s expecting to be present through its device tree. Chromebooks do that on x86 as well: they skip the firmware part and boot into Linux as early as possible, because it boots faster and it’s a ton of code you don’t need when you can just let Linux deal with it. Both are purpose built to run Linux, there’s no point wasting time with a whole firmware interface nobody should ever need. Fastboot is a perfectly fine low-level bootloader interface that lets you flash ROMs just fine.
I found this very interesting detailed writeup from a developer of Asahi Linux about the difference in the boot process from an Intel UEFI and the current Apple silicon, starting at the M1. Mind you, this is from 2021, and surely some things have changed in respect to the M3, but this can give folks a general idea of maybe what to expect from BIOS/UEFI alternatives in the ARM chip space.
Comment from Hackernews: https://news.ycombinator.com/item?id=26114417
More detailed writeup on Github: https://github.com/AsahiLinux/docs/wiki/M1-vs.-PC-Boot
Apple is Apple, it’s not a super great example. They already had iBoot from the iPhones and iPads that they just adapted for the laptops, which is also what the M chips are. Apple’s firmware has always been rather quirky compared to more standard machines.
If you look at the cloud, like AWS and their Graviton instances, they use plain old regular UEFI but ARM, which then can load GRUB and the kernel as usual there. Completely generic and basically the same as x86_64 UEFI. You can load any generic ARM distro there. We already know what ARM PCs would look like.
The main thing here isn’t really x86 vs ARM, it’s embedded vs PCs. You can totally have non-BIOS and non-UEFI compatible machines with x86 CPUs in them, but I only saw this being done embedded in devices, in my case those were industrial machines. With ARM you’ll also see U-boot which is common in stuff like routers and IoT devices because it’s fairly easy to get working and can be controlled with serial ports. But for PCs, it’s gonna be UEFI if anything because Windows support. In the end, CPU is CPU, it runs code.
Why not UEFI everywhere then? Because it’s overkill most of the time, and orders of magnitude more code and complexity which you just don’t need for a router. Your router can start executing its operating system directly from flash. You know in advance where the kernel is located, you don’t need to start initializing PCIe devices and a SATA controller and scan disks for GPT headers and find an EFI partition formatted as FAT32 to find an executable to load into memory and execute, no graphics card to initialize, no keyboard and mouse to monitor for menu, no menus to display because there’s no options, etc. UEFI firmwares aren’t small. The arm64 OVMF firmware for QEMU is a whopping 64MB, that’s more flash than my router even have.
A bootloader is a bootloader is a bootloader be it grub or legacy or uefi or coreboot. However most hardware that isn’t a phone or an appliance, be it firewall or smartfridge have a BIOS which might be the nature of the original question.
Why’s it so goddamned hard to put desktop linux on my phone.
A functional desktop Linux is hard. Getting desktop Linux to boot and run stuff isn’t that hard in itself.
The problem is mostly drivers. They’re made for Android specifically, and often for that device specifically as well, so getting them working outside of Android is hard. The second problem is of course manufacturer obstacles, they really don’t want you to do that.
Technically getting a kernel and a working framebuffer is fairly “easy”, because it’s mostly already there, you could just replace the initramfs and run whatever init and software you want. It’s getting the GPU to do stuff that’s a lot harder. WiFi is alright but cellular is a complete nightmare. A lot of those are Java native libraries, which makes it non-trivial to use outside of the Android Framework. But all the kernel stuff, you already have ready to steal right from the manufacturer, or you can take the ones LineageOS uses. It’s only a matter of getting a useful userspace.
And the phone landscape on Linux isn’t that interesting, so people’s attention have been around improving Android itself as it’s much more capable and mature, and is open-source. If Android was closed source we’d have Linux phones already, but for many FOSS entheusiasts, Android is fine and much better polished.
If you’re lucky, PostmarketOS might support your device well. If you’re less lucky you might get a kernel that boots but you can only get a serial shell to it over USB. If you’re unlucky, nothing exists, and you have to do it yourself.
Oh hey sorry, I agree on all those points. I run a hacked kernel on my phone from the Ubuntu touch days. I know what a binary blob is. I was joking that the OP was asking asking the desktop linux on a phone question.
RISC-V may be of interest to you
Phones just don’t have UEFI, because 99.999% of the time it will run only one operating system: the manufacturer’s flavor of Android.
And the manufacturers very much want to keep it that way.
They do not want you to be able to make those changes, and intentionallyput roadblocks in your way.
Unified Extensible Firmware Interface isn’t how we spell planned obsolescence and that doesn’t add up to infinite profit sooooo yeah.
Can’t have you replacing the OS on that thing. Adding security patches and a new battery on that. Just wouldn’t be fair to us billionaires and our R&D department. We have to justify all this labor somehow.
You can replace the OS on most Android devices.
Specifically- devices made by Google have been unlocked allowing replacement of the software.
You still have to put together a working kernel and drivers, environment, etc.
Not much stopping folks from doing that though.
GrapheneOS, Ubuntu, and others have made headway for some devices.
Each device potentially uses different hardware implementation and features.
Graphene is targeting only google pixel devices.
Ubuntu touch and Ubuntu phone have been picked up by I think postmarketOS
I think AOSP is the best bet for the largest majority of Android users.
Kernel dev is a fun hobby.
Or, maybe writing firmware and code that doesn’t make money is the opposite of profit.
Where is the incentive to write code that reduces security and costs money they won’t recover ?
There is a BIOS - a Basic Input Output System, usually made by the SoC manufacturer that acts as a bootloader shim to get the Android bootloader going (fastboot/recovery menu level here) which then loads the Android kernel. It’s the same as UEFI or the legacy BIOS, but it does not come with a configuration utility which is the menu that most people think of when they think of “BIOS” I.e. “going into the bios”.
A BIOS does not inherently have to have a configuration utility.
Unlike an UEFI implementation on modern AMD64 systems, the typical ARM bootrom is a masked rom written to flash-once memory.
This bootrom performs the same vital functions as a bios though, i.e. sending key instructions and data (including setup of requirements) to the processor for it to start executing the bootloader program off of memory, in this case the android bootloader.
Contrary to popular belief and the top comment ITT at the time of initially writing this, android does not use the Linux kernel, it’s based on an LTS Linux kernel, but highly modified with patches to form the ACKs. https://source.android.com/docs/core/architecture/kernel
Without the config utility the ARM SoC BIOS is largely hidden from the user, but the veil is lifted when it fails in spectacular ways: https://en.m.wikipedia.org/wiki/Qualcomm_EDL_mode
A BIOS does not inherently have to have a configuration utility.
This right here.
My first PC (a 386 circa 1989) did not have a built-in config utility. It had a bootable floppy disk that could configure the BIOS settings. I think all it could change was the system time and the CHS values of the hard drive(s).
Kinda funny how we’ve somewhat returned to that. Modern EFIs typically let you change settings from within your OS. I remember having a motherboard in like 2011 or 2012 with a great GUI that let me tweak everything. I’d set an overclock in the OS and just reboot for it to take effect.
Not sure why more boards don’t offer this anymore other than maybe security. But like with cryptic ass programs I can still change bios settings.
There is a bios, but it is hidden really well for the user experience
Why, instead of safely entering a BIOS setup
effiency and lawsuits, phones has embedded hardware, its a bit op to have that initial hardware calls for a embedded hardware system.
BIOS is initally an IBM tech
_does the cell phone brick when installing the Custom ROM wrongly? _
Android is based on linux, that includes the partitioned bootloader (mostly grub on linux and fastboot on android, they’re not technically the same but the idea is somewhat related) if that partition is messed up then its most likely not to boot
Wouldn’t this protection be better for users? I mean, this could be done through ADB.
Android is owned by a corporation, I dont think that will be their primary objective
Also, do you think it’s possible that this way of doing things will come to the computer, with ARM hoping to gain a good share of the market and all?
ARM is mostly a cpu design corporation that offers license fee to other companies to manufacture thier cpu designs, they’re everywhere. It depends on thier licensees what to add to make profit.
As somebody who’s fucked up with custom ROMs several times and made bricks out of my phone, they are soft bricks and can be fixed. Sometimes it’s not easy, but it can be fixed.
I dunno. I have a 2017 flagship that will no longer even boot to fastboot after accidentally disconnecting the cable during a flash.
Which phone. There’s usually a hidden firmware flashing feature. I had to use that when an update failed on a OnePlus phone. I’ve only ever used ones for snapdragon based phones, never tried anything else.
Essential Ph1. The flashing tool isn’t out there anywhere as far as I can find
It has a snapdragon CPU so you’d have to try to find how to get it into EDL mode and potentially a cable for it. With my oneplus phone I rescued the other day I was able to use a regular cable, but that was also with their proprietary software.
Will it boot into fast boot when starting up with like pressing the volume up or volume down key at boot? Because as long as you can get into fast boot, you can fix it.
Yea, it won’t boot to fastboot
Oh wow, then you’ve managed to break it more than I have ever broken a device. Oopse
ACKSHUALLY
Most modern PCs don’t have a BIOS, either.
They have a UEFI, a Unified Extensible Firmware Interface.
*pushes glasses up nose.
Don’t bother giving me a wedgie, I can do it myself.
I think you just gave me a wedgie because I thought UEFI was the same… But reflecting, I don’t think I have had to use the BIOS since I used Windows 98…
Bios died out around 2010. It lasted a good long time. Your could argue a boot menu is bios and you’ve probably interacted with that at some point.
Also nobody stopped calling it a bios. Every motherboard I’ve owned with a UEFI has called it a “UEFI bios”.
I switched to a Linux OS in '08 and haven’t really paid attention since. I’ve done a little partition work but I’m no superuser… I probably have a UEFI and don’t know it. My days of using the bible are gone haha
That’s not a guarantee.
UEFI uses GUID Partition Tables (GPT) instead of a Master Boot Record (MBR) and needs an EFI partition.
I personally recall Linux in 08 had pretty abysmal UEFI/GPT support. I’d say support didn’t become as good until about 2015-2016ish.
So you very well may still be using traditional MBRs if you haven’t really changed your setup.
Especially since a lot of UEFIs come with a compatability layer to mimic BIOS and allow some backward compatability.
Late reply since I’ve been in the field - I no longer have to worry about partition space for kernels, that is nice. Using mobile rn but I will look when I get on my computer.
Bios died out around 2010
My Acer Predator from 2019: “I’m about to blow this man’s mind”
A thin client from Asus circa 09? Uefi, no problem. A 3k Acer gaming laptop from 19? We can’t fit something so cutting-edge into the budget!
Your machine has an EFI.
If your machine shipped with windows 8 or above (starting in like 2012) it came with an EFI. You can use the legacy compatibility mode still in all motherboards. Finally starting some time soon they might be dropping legacy bios compatibility mode. But if your machine can boot from an NVME SSD it’s got an EFI.
Love this
They all do, but it’s usually custom made by the SoC vendor. Although I wish we had a standard like UEFI on phones…
ARM doesn’t specify a standard firmware interface like x86 PCs do.
I mean, they could, but ARM comes from a different era, where interoperability isn’t a requirement and devices are disposable instead of upgradeable.
There no incentive, no IBM PC to be compatible with, not even an Apple, Macintosh, Conmodore Amiga or Atari ST to make peripherals for. ARM devices, even the rPi, are one-and-done.
They’re an embedded device, plain and simple. Among other things, this means that there’s not a layer that handes off the hardware in a ready state to the OS, and not even an ACPI to tell them what and where the hardware is, the OS needs to already know via a device tree.
Because ARM was built to be cheap.
BIOS nowadays is basically a bootloader shim in EEPROM. The majority of the ARM ecosystem wanted flexible and cheap devices. This promoted the use of a small ROM loader burned into the device and a removal of basically all EEPROM from the SoC.
The flexibility came back through the use of a secondary bootloader layer normally stored in the devices primary storage. Most manufacturers use u-boot or coreboot on an SD card or eMMC. Android standardized this as part of their partitioning scheme. All devices have a dedicated bootloader partition housing the secondary bootloader and any additional boot artifacts.
Then phones became wildly expensive and invalidated most of this.
Also, do you think it’s possible that this way of doing things will come to the computer, with ARM hoping to gain a good share of the market and all?
It already has. Most of what ARM is doing to be cheap was already pioneered by PowerPC.
ARM EBBR specifications attempt to standardize this boot flow somewhat, introducing a standard EFI shell in u-boot. This does not solve the dependency on the secondary bootloader, and it doesn’t prevent people from shooting themselves in the foot. It just makes distro interactions with the secondary bootloader more standardized.
If we are speaking of android phones, they don’t have a bios, but they have a bootloader. The bootloader starts the kernel or the recovery, and it can be used to unbrick a device, by reflashing or flashing stock. if you fuck up the bootloader flashing, or disable oem unlocking again and then the phone fucks up, that is the only time the phone can be truly bricked. as for your second statement, the successor to BIOS is UEFI, and UEFI has arm support.
Also, do you think it’s possible that this way of doing things will come to the computer, with ARM hoping to gain a good share of the market and all?
Judging by the way Raspberry Pi works, as an ARM SoC computer, it’s already this way: no visible BIOS nor UEFI, just the Operating System being loaded from the SD Card. Technically, you need something to load the OS (i.e. initialize the
mmcblkdevice, request reading of the partition scheme, request reading the files inside the first FAT32 partition, and so on) so there’s technically a “BIOS” (Basic Input/Output System), although not a visible one, let alone an interactable one.Think of installing a custom ROM on a phone like installing a custom BIOS ROM on PC, both are actually not damaging to the device if they fail but require specialized equipment to recover.
Also, some phones and motherboards support special low level recovery modes when a rom fails to boot, but it’s usually not easy or documented.
Cell phones do not have a BIOS like traditional PCs; instead, they use a bootloader, which serves a similar purpose. The bootloader initializes hardware and loads the operating system, but it is specific to each device’s hardware, limiting compatibility with different operating systems. This lack of a standardized BIOS-like system makes it difficult for users to install alternative operating systems and leads to fragmentation in the mobile ecosystem. Manufacturers may avoid implementing a BIOS to reduce costs and maintain control over software updates.
Heh…
It installed ROMgly?
