How do Android devices lock to a certain bootloader.

Lets say I want to run FreeBSD on my Arm powered ChromeBox.

I have to enter recovery mode then diagnostic mode yadda yadda yadda.

Why can't u-boot be install directly on these devices. How do they lock themselves? Is this recovery button involved?
Something in the SPI-ROM?

RK3399 for example. We have u-boot and good support yet and Android devices with this chip can not run FreeBSD.

How do manufacturers tie a board to a certain bootloader? What makes this tick? Do they burn eFuses so only certain loaders work?

How can we reuse RK3399 Android boxes on FreeBSD?
 
There seems to be a bunch of u-boot configs for chrome devices.

chromebit_mickey_defconfig
chromebook_bob_defconfig
chromebook_coral_defconfig
chromebook_jerry_defconfig
chromebook_kevin_defconfig
chromebook_link64_defconfig
chromebook_link_defconfig
chromebook_minnie_defconfig
chromebook_samus_defconfig
chromebook_samus_tpl_defconfig
chromebook_speedy_defconfig
chromebox_panther_defconfig
 
Carriers often lock down the bootloaders on android devices and it should be illegal to do so. I cannot say whether uboot supports your particular platform, but yes, the controller could have an efuse popped to keep you from overwriting it, even with a JTAG.
 
I bought the Face X2 with RK3399 and it advertised Linux or Android. But shipped with Android.

I bricked it trying to install Ubuntu in bootmask mode. Its not broke just awaiting proper servicing.

I am temped to buy another. Go slower this time. No hope for screen working so kinda waste.

 
the controller could have an efuse popped to keep you from overwriting it, even with a JTAG.
I doubt they blow an efuse, that would also prevent the manufacturer from ever updating it.

I wonder if thats how they lock it. They slap a chip in the middle to work with recovery rom and the button.
If I look at the FPGA dev board (CMOD-A7) I have, it uses a FTDI FT2232HQ for USB-UART. It can act as a 'standard' com port, but it's also used to program the FPGA. So there's indeed likely a chip in between that arbitrates between UART and programming modes. With a bit more complicated chip you could probably do a signature verification on the firmware being loaded, if the code isn't signed with a particular key it'll prevent you from writing to a specific bit of the firmware.
 
I doubt they blow an efuse, that would also prevent the manufacturer from ever updating it.
Actually it is common on locked devices to blow the efuse for boot methods.
iMX6/7/8 does. It's an OEM thing. Users would never do it. But they can.

if the code isn't signed with a particular key
This is getting close I believe. Key on chip like TPM.
Does it coordinate with ATF.
Arm Trusted Firmware? I at grasping at straws now..
ATF is used on Android too I have noticed.
 
I doubt they blow an efuse, that would also prevent the manufacturer from ever updating it.
Even better. You need to buy a new one since updating is impossible because of *checks excuse rolodex* security measures.

As long as there is no law requiring the update being done under any circumstances, this will continue. And if it is mandatory, you need to visit the local genius bar to have it done. For some iCash, of course. For security reasons.
 
i don't know about phones but the tv boxes seem to have u-boot
all sbcs i have work with u-boot but one mediatek based (orange pi iot) which uses little kernel (but seems to support u-boot too)
 
Can you give the generic name for Androd rk3399 TV Box? Like X96
Any with nvme slot? What u-boot target do you use? evb or generic?
 
don't know about any current model just what i found on the armbian forum
Magicsee N6 Max
some versions of X99 or X99 max

i don't have one
 
re-blowing an efust to protect the bootloader. When was the time you had to update a bootloader? They are generally extremely stable and don't require maintenance. Also, as is the case with Verizon, they contain a static bootloader password to keep users from modiying the configuration. If the bootloader code was modifyable then a user coupld resumably use a JTAG and change that password. secure mode on modern devices is a PITA. Even to use it correctly is painful, so hacking it is even much harder.
 
Back
Top