[jojobas]

It's a shame phones didn't get anything similar to BIOS back in a day.

Imagine if every laptop manufacturer had not a couple of incompatible sensors, but a whole unique boot system only allowing you to boot a crippled version of Windows ME.

[mjg59]

There's a lot of UEFI in the phone ecosystem, it's not the BIOS later that's missing - it's the ACPI layer.

[mschuster91]

I've never seen UEFI in any mainstream Android device.

The problem is... in the x86 world, even the most modern systems around still ship with decades of garbage. INT 10h and VBE, every x86 system still speaks it - either directly in the card, or emulated in BIOS/UEFI compatibility layers, so even a basic "hello world" can get video output, 09h/16h gives you keyboard input, 13h gives you disk I/O, 14h a serial port.

That means that at least the initial bringup for a second-stage bootloader is incredibly easy, less than 40 lines of assembler code [1]. And when you write a tiny operating system, as long as you're content with that basic foundation of 640x480 and text output, it will run on any x86 compatible PC or server.

On anything ARM, that's outright impossible to do and that is a large part of the problem. ARM is power efficient, but it comes at a serious cost. The low level bringup will be handled by the board's ROM, similar to PC BIOS/EFI, but after control is passed to the OS it gets different - all the OS gets is the devicetree stating "here's the memory addresses and interfaces of the hardware in the system", but you still need to write drivers for each and every individual thing from the bottom up, there is no framework for even most basic hardware interactions.

[1] https://gist.github.com/MyCatShoegazer/38dc3ee7db9627ff3a20e...

[mjg59]

I have many x86 devices that don't provide a CSM, so no, it's untrue that it will run on any arbitrary x86 device. You can do something similar running entirely inside the UEFI boot services environment - and that'll work just as well on any of the large number of UEFI-based ARM phones.

[hexagonwin]

isn't uefi used for all the modern qcom devices..?

[nrclark]

Yes it is. It can be hard to spot if you don’t know it’s there though.

[sim04ful]

What's 09h/16h ?

[mschuster91]

09h is keyboard interrupt, the utter basic interface [1] that only gives you scancodes and that's it, 16h is the extended interface [2] that you need to deal with if you want to read/set shift and other special keys [3].

[1] http://www.techhelpmanual.com/106-int_09h__keyboard_interrup...

[2] http://www.techhelpmanual.com/228-int_16h__keyboard_services...

[3] http://www.techhelpmanual.com/58-keyboard_shift_status_flags...

[snuxoll]

Yeah, the requirement to build and provide device trees for most mobile devices is the huge issue. For all of the garbage we have gotten from buggy ass ACPI tables on assorted PC’s, it’s absolutely true that it solved a lot of headaches with hardware discovery/enumeration.

It’s really too bad that ARM had adopted ACPI as part of their SystemReady certification. It does work, and not reinventing the wheel is always a wise where feasible, but I think we could absolutely push something better.