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 register to comment.
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.
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.
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.
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 ?
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.
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.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, 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.
Heh…
It installed ROMgly?
It’s the bootloader, dumbass
A bootloader is not the BIOS, dipshit.
There is a bios, but it is hidden really well for the user experience
