Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
WIP
You own a Windows RT device and want to give it a new life? Congratulations you came to the right place.
Windows RT was limited from the beginning. It didn't allow to run 3rd party desktop apps and therefore you weren't able to run your favorit apps. On the one hand it was Microsofts fault as they closed down the desktop for 3rd party apps. On the other hand Windows RT devices run on ARM32 processors. This means that the CPU speaks another language than your desktop x86/AMD64 CPU. 3rd Party apps need to be compatible with ARM32. But due to the closed System no company ported their Application to Windows RT. Most if not all program you which currently run on Windows RT were ported by hobbyists or were taken from other Platforms like Windows Mobile. Thefore most Windows RT devices ended up in a draw and were forgotten.
Most people paid a lot of money for them but now they are reasonably cheap but they aren't more useful than 8 years ago. App support is getting worse day by day. The only browser you get is Internet Explorer and it already doesn't work with most famous pages.
However the look and feel of the devices is great and they still have some power left. The battery life is great thanks to the early mentioned ARM processor.
We like to show you some solutions. Some are ready for daily use others are for tech nerds who love to play with it.
But first we have to solve a problem created by Microsoft: Secure Boot.
Secure Boot is a really nice thing in theory. It prevents attackers from booting malware on your PC. Your UEFI firmware checks the signature of the EFI app which will be booted. In Most cases this a bootloader which will load your OS like Windows Bootmanager or GRUB2. Most UEFI systems only accept files signed by Microsoft. This is a problem if you want to boot a 3rd party unsigned OS like Linux. On Desktop system you could add the secure boot key of your Linux distribution creator and you are safe. The other alternative is to disable secure boot. This is much easier but opens a small window were attackers can take control over your PC. Microsoft being Microsoft and didn't gave us an option to disable secure boot on Windows RT devices.
Luckily there are there are a few exploits which deal with secure boot on ARM32 devices. First there was a secure boot bypass which allowed to boot test-signed Windows Bootmanager apps. It was followed by another exploit which is able to disable secure boot entirely. Disabling secure boot only works on Surface RT and Surface 2.
Instruction for bypassing or disableing secure boot can be found below.
The first solution is Windows 10. Yes you heard right Windows 10 runs on Windows RT devices. And by Windows RT devices we mean all of them: Surface RT, Surface 2, Asus Vivo Tab RT, Lenovo Ideapad Yoga 11 and so on. But there's a catch: it isn't an official build. It was leaked 5 years ago. This brings some pros and cons with it. It comes with Microsoft's Edge Browser which is newer but also starts to struggle with newer pages. You also get access to a larger library of apps which might be something you are looking for.
Linux runs on pretty much anything and so it does on Windows RT devices. They run on Nvidia Tegra SoC's (System on Chip). These SoC's have are mainlined and therefore and run plain Linux but they aren't fully supported. For example they are lacking OpenGL/3D hardware acceleration. There are a few more problems caused by the UEFI firmware running on Windows RT devices. Firmware prevents Linux from managing power settings and other essential stuff like: CPU Voltage/Frequency Scaling, L2 Cache, Regulator management.
Linux apps are still limited to ARM apps but the selection is much bigger as long as you look for traditional Linux desktop apps.
Not all devices can run Linux very well. Some are better supported than others. Furthermore there are different ways to boot those devices. One way is to use the UEFI firmware which is easy and doesn't requires any special equipment other than an USB drive. The other way is booting via APX which requires a x86 Linux PC and a USB A-to-A cable every time you want to boot your device.
In most cases you will decide to boot via UEFI whether it be related to the fact that you need your Host every time you want to boot or the fact that you have no USB A-to-A cable. But why do we mention APX if it is more annoying than UEFI booting? Let us explain with a little analogy.
You have an older timer. It looks nice but it isn't the fastest car anymore. Also something is broken and you can only drive in 2nd gear. Not very fast but you eventually reach your destination. You want to stop the car but the motor keeps running using fuel.
You have the same old timer but it ain't broken. It can shift gears to go faster or slower to save energy. The motor can be stopped but you need jumper cables everytime want to start it.
Currently supported devices are: Surface RT, Lenovo ideapad yoga 11, Asus Vivotab RT and Surface 2
It is pretty well supported it just misses some features like bluetooth and microphones.
Is is pretty well supported too. It is mainted by another group
It has some hardware support but somethings are still missing. We would appreciate if you are willing to test somethings. Feel free to contact us at discord :)
Any ARM32 distro can be used. Most popular are postmarketOS and Raspberry Pi OS. Arch, Void, Ubuntu, Kali were reported to work too.
See below for more informations:
No attempts at porting Android were made so far.
THIS IS A TEMPORARY INSTALL GUIDE, CLEANER AND MORE DETAILED ONE IS IN WORKS SORRY FOR INCONVENIENCES
Now that you know which tablet you got, pay closer attention on the exact installation method as it may differ.
Brain with more than 2 braincells, pair of hands and reading skills
Recovery image restored tablet with no updates installed (no WiFi turned on)
Before continuing, this is the most crucial part to get the tablets running on Windows 10.
Sometimes you have to clear the eMMC to proceed, this can only happen when you've updated past a point where jailbreaks no longer work or you used Alexen's guide
Assuming there is nothing on there you need to keep do the following from WinRE command prompt, you can use the same BMR or Media Builder USB to get to command prompt. Power off, insert USB with your recovery files and boot from it by holding vol down while powering on. Once its booted do this:
At command prompt type the following:
Power off, insert USB with your recovery files and boot from it by holding vol down while powering on. Once its booted do this:
Plug the drive into your tablet and boot off of it by pressing Power
and holding Volume down
Follow the on-screen guide and you're good to go!
Point 1:
Jailbreak:
Follow to set up jailbreak on your device
Generate an image using
Get the most out of your Surface RT and other Windows RT devices. Install Linux or Windows 10 on ARM32.
Current Hardware support: Type-/TouchCover, (Touch-)Screen, USB, SD Card, eMMC, HDMI, Buttons(Vol+/-, PWR, Windows), (UART-A), WiFi, Audio
Any ARM32 distro works
Booting Linux from UEFI is possible.
You can boot Linux with a tethered exploit (better performance) or UEFI. You will be able to use the Raspberry Pi OS Desktop, postmarketOS or any other ARM32/ARMHF distro. You can interact with it via Touchscreen, Type-/TouchCover and USB peripherals (Keyboard, Mouse, USB-Ethernet)
Join our Discord server down below!
This section deals with different Boot processes on Surface RT/2
Boot process can be divided in 2 different sections.
First comes the SoC boot process. This prepares the SoC to execute more capable firmware/bootloaders which will eventually load a Operating System.
Once the UEFI Firmware is loaded it needs to decide which files should be booted next.
Prepare USB: format it as FAT32 and copy your files
Insert USB into your Surface
Hold Vol-Down
Press PWR
Wait until the Surface logo shows and wait some more seconds
Release Vol-Down
To boot unsigned non Microsoft UEFI Apps you need to apply Yahallo first
Connect your Tegra3/4 via an USB A-to-A cable to an USB 3.0 Port of your PC
Hold Vol-Up
Press PWR
Release Vol-Up
it should immediately boot into APX mode
Use your payload sender to send data (Fusée Gelée)
Newer PCs can use an USB Type C cable instead of USB A-to-A cable
Boot process of Tegra SoC's from PowerOn to Bootrom to Bootloader
Every Tegra SoC contains a small built in ROM. Tegra3 has one which is 48kB in size. This ROM is called BootRom.
The Bootrom is responsible for initial SoC setup. The code stored in bootrom will execute on the Boot and Power Management Processor (BPMP) which is a ARM7TDMI(ARMv4T) CPU. Until DRAM is setup it can only use iRam which is only 64kB in size. After DRAM setup it will load a Bootloader to DRAM and transfers control to it.
Checks fuse or strap to decide which boot device should be used.
Try to read a valid signed BCT
Set up DRAM according to BCT
Load a hashed Bootloader specified in BCT and execute it
If no valid Bootloader is found it enters USB recovery mode (RCM/APX)
From there its the firmware job to setup the main CPU (ARMv7-Cortex-A9) and transfer control to the main CPU. This part of the firmware/bootloader is called Secondary ProgramLoader (SPL).
On a stock Surface RT/2 this bootloader is UEFI TianoCore EDK2 which provides the UEFI API.
USB recovery mode can be exploited. See Fusée Gelée
http://http.download.nvidia.com/tegra-public-appnotes/tegra-boot-flow.html
WIP
APX Mode (NVIDIA USB Recovery Mode) can be used to run Fusee Gelee or to use Nvidia tools to flash the hardware. https://forum.xda-developers.com/showpost.php?p=77286176&postcount=85
Note - you will need a USB3 port on your development computer.
Power off the SurfaceRT or RT2 (not sleep mode!)
When the device is shut off, plug in a USB type A into the Surface, and a USB type A (or type C depending on your development device) into your development computer.
Hold VOL-UP; Press PWR and release it. Release VOL-UP if dmesg -Tw
shows:
Once connected in APX mode, you can use NVidia tools or a precompiled Fusee Gelee on your device. Nvflash v2.6 - https://docs.toradex.com/103464-nvfl...ry-toolset.zip NvFlash tool for getting uid - https://web.archive.org/web/20160318...ools-win32.zip
Connect USB - A-to-A cable Write 0x00000002 to 0x7000E450 <- sets bit in PMC-register to indicate to boot to RCM Write 0x00000010 to 0x7000E400 <- reboot This should force reset in RCM Mode
Boot UEFI Shell as normal. use this startup.nsh
To get your platform key use this command in the tegra30-debrick directory.sudo ./fusee-launcher/fusee-launcher.py –-tty ./fusee-launcher/dump-sbk-via-usb.bin
Add the -P parameter at the end to specify the product_id if "No TegraRCM device found" is the output. For the Surface RT 1 this is 7130.
This will output a lot of things. Look for the line with hello world, after that line something like this b'e57de3bab6cb499d874d5772cb219f0101042c20'
should show up. Remove the b, the two ' and the last 8 remaining characters. This is your platform key. It is used to encrypt and decrypt the BCT and the firststage bootloader
work in progress.
Looks like UARTA is using the ULPI pins as noted here (https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-tegra/tegra30/pinmux.c#L238) So we know we can setup our UARTA and UARTD on the ULPI pins
#if defined UARTA
/* set pinmux for uart-a (nexus 7) */
reg_write(PINMUX_BASE, PINMUX_AUX_ULPI_DATA0_0, 0b00000110); /* tx */
reg_write(PINMUX_BASE, PINMUX_AUX_ULPI_DATA1_0, 0b00100110); /* rx */
#elif defined UARTD
/* set pinmux for uart-d (ouya */
reg_write(PINMUX_BASE, PINMUX_AUX_ULPI_CLK_0, 0b00000110); /* tx */
reg_write(PINMUX_BASE, PINMUX_AUX_ULPI_DIR_0, 0b00100110); /* rx */
#endif
Boot process of Tegra SoC's from Firmware to Operating System
UEFI Firmware is loaded by the BootRom which loads the UEFI Firmware.
UEFI Firmware will setup hardware like Display, USB, etc.
After hardware setup it will transfer control to /efi/boot/bootarm.efi
bootarm.efi has to be signed with the Microsoft SecureBootKey (SBK)
https://forum.xda-developers.com/showpost.php?p=82555449&postcount=126
coherixmatts - "This has been helpful to me, as I was able to quickly test changes to the BCD file. Changing the BCD file allowed me to replace test.efi with bootshim.efi from here: http://github.com/imbushuo/boot-shim/releases
Instead of loading EFI files like test.efi, this alternative loads ELF files. That isn't necessarily so exciting, but this BootShim also unloads elements of the original SecureBoot restricted UEFI. They are using this on Lumia devices (particularly the 950XL) to load a modified version of UEFI. After that, it seems they can boot most anything." This thread also seems interesting for reference https://github.com/rhboot/shim/issues/138
In the Surface RT UEFI there is a bug which prevents the display from working. This is because the standard GOP (Graphical Ouput Protocol) isn't hooked up to the Surface RT's display. This was fixed in the Surface RT 2.
UEFI can be set to require a trusted chain from boot to execution of OS - aka a Root of Trust. On the Surface RT/2, UEFI is setup to require a trusted chain "secure boot".
This was the main issue for development of other OS's on the Surface RT/2 hardware.
Secure Boot means that we are unable to replace the "bootarm.efi" bootloader with our own bootloader like GRUB as it needs to be signed by Microsoft.
Microsoft is unwilling or unable to provide the key to "unlock" the Surface RT/2 hardware, so we are "stuck" with using their bootloader. There are two possible options to bypass this - Yahallo and Test Certificate bypass.
A "golden key" bypass which allows us to insert a trusted test certificate into the UEFI Bios allows us to use a signed shim to boot into our own EFI loader (instead of booting into Windows). We still load Microsoft's signed bootarm.efi, which then loads a shim, to load Grub/EFI shell, which can then finally load a Kernel.
Further info on this bootmanager exploit bypass is here
A new, easier method for enabling test signing was discovered. It involves the same techniques, but you only need to boot from a USB twice, you don't even need a windows installed. (An EFI partition could be required, this needs to be verified)
Grab the ZIP file from here, extract it to your USB, and boot your Surface device from it. A menu should show up where you have several options (Install Golden Keys, Uninstall Golden Keys, Apply Yahallo, Undo Yahallo). Select "Install Golden Keys" to enable test signing (You have to use a USB keyboard to select an entry). Your device should reboot and you need to accept a warning.
With this you can also easily disable secure boot with the help of yahallo. Just make sure test signing is enabled and you can select "Apply Yahallo" in the menu to disable secure boot.
You can get further explanation of the tool / USB setup in the development section.
Note: This only works when you downgraded to Windows RT 8.0 you can brick your device if you use Windows RT 8.1.
Down in this section there is a download for the "golden key" you need to install it, by running InstallPolicy.cmd as admininistrator on your SurfaceRT. It is important that you don't run the file off a USB drive, copy it to your desktop. After running the file you need to reboot, a menu should open which should enable you to enable testsigning. Accept it. After the reboot open up a cmd, again with administrator privilegs and run the following command:
Reboot again, now testsigning should be enabled.
To use the test signing to boot from USB you need to extract the files from the usb-boot-setup.zip to the root of a FAT32 formated USB-drive. This setup doesn't include any bootable files, to add one place it into the root directory and name it BOOT.efi. Further reading on how the bootflow works at UEFI Boot Sequence.
Root of Trust combination with keys and certificates. Using SecureBoot your firmware will check if the operating system you are trying to boot and your bootloader are trusted by you. On each boot-up UEFI firmware will inspect what you are trying to boot and if it's not trusted a security violation will be triggered.
PK: The Platform Key, the master one, the ring to rule them all. The holder of a PK can install a new PK and update the KEK.
KEK: Key Exchange Key is a secondary key used to sign EFI executables directly or a key used to sign the db and dbx databases.
db: The signature databse is a list with all allowed signing certificates or criptografy hashes to allowed binaries. We will use THIS db key to sign our Linux Kernel.
dbx: The dark side of the db. Inverse db. "not-good-db". You name it. It's the list containing all keys that are not allowed.
https://news.knowledia.com/US/en/articles/secure-your-boot-process-uefi-secureboot-efistub-luks2-lvm-2fe5ab6e432ac7b6d0bb773cebe0363c41bef83c https://wiki.ubuntu.com/UEFI/SecureBoot/Signing https://bentley.link/secureboot/ https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd https://lwn.net/Articles/632528/ [The bootstrap process on EFI systems] https://community.arm.com/developer/ip-products/system/f/embedded-forum/7016/uefi-on-arm-v8-based-linux-embedded-system https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html http://weng-blog.com/2017/07/21/ARMv8-UEFI-manual-boot.html
https://ubuntu.com/blog/how-to-sign-things-for-secure-boot https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot
Fusee Gelee (translates to Frozen Rocket) is a coldboot launcher. The exploit takes advantage of a USB software stack that is provided inside the BootROM. This stack contains a copy operation that allows for control from attackers. By creating your own USB control request, attacks can use this vulnerability to gain control of the Boot and Power Management Processor (BPMP).
This allows attackers to gain control of the system before any of privilege restrictions are put in place, essentially giving full access to the device. Allowing for the loading of arbitrary code and extraction of secrets.
This vulnerability is completely unpatchable, so the only way to fix this vulnerability is to recall and replace existing SKUs. It affects most of the Tegra devices that were produced before the exploit was published. This includes Surface RT and Surface RT2 and other Tegra3/4 devices.
To use this exploit you need
A payload - a binary file which gets executed
A payload sender - a program which transfers the payload to the device memory.
pyusb
There is a precompiled payload for the Nexus 7 2012 that we can repurpose for the Surface RT (Tegra 3).
The payload provided in this repository has been tested many times, but proceed at your own risk.
You will need to clone this repository into a new directory, including the submodule here:
Once the payload and exploit are downloaded, here are the steps all the way up to flashing an unsigned bootloader:
Connect a USB-A to USB-A cable from your Surface RT to a USB 3.0 port on your host machine.
Boot into APX mode.
Press and hold Volume Up & Power for about 3 seconds
Release the Power button
Release the Volume Up button
lsusb should show a Nvidia device with id 0955:7130
cd
into the tegra30_debrick
directory
Run the commandsudo ./fusee-launcher/fusee-launcher.py ./payload/uart_payload_n7.bin -V 0955 -P 7130
This will send the uart_payload to the Surface RT, and patch the getSecurityMode function to always return 3, allowing us to use nvflash.
Run the commandsudo ./utils/nvflash_v1.13.87205 --getbct --bct surfacert.bin --configfile ./utils/flash.cfg
This will read the surfacert bct, which is a required input for many nvflash commands.
Finally, we can run arbitrary code using the following command:
sudo ./utils/nvflash_v1.13.87205_miniloader_patched --setbct --bct surfacert.bin --configfile ./utils/flash.cfg --bl u-boot.bin --go
Further tweaking is needed to get a functioning bootloader, with the above steps, and the compiled nvidia fork of u-boot located here (Driver Packages - Cardhu), the webcam light turns on.
Once the L4T R16 u-boot.bin is flashed, you will then need to press and hold the Power button for around 10 seconds to fully power off the tablet. Then you can repeat the above steps to re-attempt flashing.
24 / Dec / 2021
Removed old installation guide, created a temporary one and moved tablet hardware overlook out from Windows 10 category
LY
08 / Dec / 2021
Add prebuilt linux binaries
L
04 / Dec / 2021
Add UEFI Privilege Escalation Exploit Documentation after being stuck as draft for months
L
29 / Nov / 2021
CTS
20 / Oct / 2021
Added information about prebuilt uboot to APX boot Linux page.
L
24 / Sept / 2021
Updated front page. Added Changelog, Get Started
CTS, L
24 / Sept / 2021
Merged Linux APX and EFI booting
CTS, L
16 / Sep / 2021
Add new Linux prebuilt binaires
L
07 / Sep / 2021
Add new Linux prebuilt binaries. They finally support WiFi
L
29 / Aug / 2021
Initial Lenovo Ideapad Yoga 11 update. This adds information about Linux
L, CTS
27 / Aug / 2021
FAT32 isn't FAT32. Tell about the USB drive issue
L
27 / Aug / 2021
Removed misleading information for RPI OS. Files on the FAT32 are only required for APX booting
L
27 / Aug / 2021
Add information about the MADT / APIC table and add usage information for it (ACPI Parking Protocol)
L
26 / July / 2021
Rewrite to Surface RT2 specifications tab and moved to Hardware
LY
10 / July / 2021
Reworked Linux section. EFI booting was moved away from development section
L
09 / July / 2021
Updated EFI linux compiling information and added prebuilt EFI kernels
L
09 / July / 2021
Updated main page
L
05 / July / 2021
CTS
21 / June / 2021
LY
20 / June / 2021
Update RPI UART setup
L
15 / June / 2021
Updated ACPI Tables for sRT
CTS
15 / June / 2021
Added Special Boot modes
CTS
15 / June / 2021
Added Touch/Type/Power Covers page
NCRC
14 / June / 2021
Updated images on the battery page
NCRC
12 / June / 2021
Added battery info for Surface RT
LY
10 / June / 2021
Updated Power Supply Pinout
NCRC, L
22 / May / 2021
Added basic information about the Replay Protected Memory Block (RPMB) on emmc
L
22 / May / 2021
Added information about an easier way of applying Yahallo and enabling test signing
L
19 / May / 2021
Added information about the Windows RT 8 Update Kit and the Windows 10 Build 15035 Mod Kit
L
19 / May / 2021
L
18 / May / 2021
Updated Surface RT2 Specifications
LY
05 / Apr / 2021
Added a Yahallo Undo
L
02 / Apr / 2021
Added instructions for GDB Debugging qemu and integrating it into VSCode
L
02 / Apr / 2021
Added Qemu emulation instuctions
L
02 / Apr / 2021
LY, L
25 / Mar / 2021
Added a Yahallo guide
LY
22 / Feb / 2021
Updated latest SMP progress and corrected EFI linux boot information
L
18 / Feb / 2021
Added reference to latest EFI booting progress
L
05 / Feb / 2021
L
03 / Feb / 2021
Added latest info about EFI boot
L
31 / Jan / 2021
Added a writeup about trying to get rid trustzone and uefi
29 / Jan / 2021
Complete revision of Surface RT section
CTS
22 / Jan / 2021
Refined Flash chip page
JB
22 / Jan / 2021
Added U-Boot log
L
21 / Jan / 2021
Added Linux Feature list
CTS
21 / Jan / 2021
Added Distros/RaspiOS & updated Root filesystem
CTS
02 / Jan / 2021
Added Windows 10 section and a link to a spreadsheet with tested games
L
30 / Dec / 2020
Added a temporary EFI linux booting page
L
04 / Dec / 2020
Moved stuff from the development section to the corresponding pages
CTS
30 / Nov / 2020
L
28 / Nov / 2020
Added Jailbreak Exploits page
LG
27 / Nov / 2020
Added BCT
L
26 / Nov / 2020
Added dumping sbk and added how to tell that BCT is stored on SPI flash
L
26 / Nov / 2020
Added SPI flash
L
26 / Nov / 2020
Added GPIOs in Linux
L
20 / Nov / 2020
Added Gpios
CTS
19 / Nov / 2020
Added Compile Section for SSDT
L
19 / Nov / 2020
Added the ACPI Tables for Surface RT
CTS
13 / Nov / 2020
Added notes in Secure Boot page regarding development focus
LS
11 / Nov / 2020
Added Boot Linux and updated all pages in SurfaceRT/Linux
CTS
08 / Nov / 2020
Added uboot bootscript
CTS
03 / Nov / 2020
Added and cleaned specs information on Surface RT and Surface 2
AF
03 / Nov / 2020
Added PSU page and section
LS
31 / Oct / 2020
Added WindRE/WIM Install files and ported over Recovery Toolkit page
JB, AF
29 / Oct / 2020
Added Pinmux dump
CTS
28 / Oct / 2020
LS, L
25 / Oct / 2020
Added more pdf datasheet links to Hardware Section
LS
21 / Oct / 2020
finished UART
CTS
21 / Oct / 2020
General housekeeping in Development section
LS
21 / Oct / 2020
Frontpage -> updated project status
CTS
21 / Oct / 2020
SurfaceRT -> added Linux section (devicetree, uboot, kernel, rootFS)
CTS
21 / Oct / 2020
SurfaceRT/Hardware -> cleaned / added i2c findings
CTS
20 / Oct / 2020
Updated status - Linux is booting on the SurfaceRT over serial
LS, CTS
20 / Oct / 2020
Added Hardware Chipsets in Hardware Specifications Page for SurfaceRT
LS
20 / Oct / 2020
Added updated Kernel config parameters in Kernel dev page
LS
19 / Oct / 2020
Added Kernel Log for Partial Boot. Serious progress was made today!
LS, CTS
19 / Oct / 2020
Added TX / RX pins to UART page
LS, CTS
19 / Oct / 2020
Added link to NVIDIA CBT tools on BCT Table Page
LS
19 / Oct / 2020
Updated Home Page to have changelog and project status
LS
19 / Oct / 2020
Updated Kernel page to note standard vs EFI kernel compilation
LS
19 / Oct / 2020
Updated u-Boot page to note successful serial output from u-Boot, and updated instructions
LS
16 / Oct / 2020
Added Tegra SoC Boot Process, initial uBoot pages
LS
13 / Oct / 2020
Added Kernel compilation notes
LS
12 / Oct / 2020
Added initial content and notes
LS, CTS, JB
abbreviation
nickname
AF
Alexenferman
CTS
CrackTheSurface
JB
Jukebox
L
Leander
LG
lgibson02
LS
Loz
LY
LeYuuki
NCRC
NeonCatRC
The Exploit starts in App.c. App.c transfers controll to DeviceLut.c It will compare the UEFI version to some entrys in a lookupTable In case of sRT it will apply a display fix first. DeviceLut.c transfers control to Exploit.c
We suggest to only apply this if you need it. In most cases it is not necessary. At the moment you gain no advantage.
Prerequisites to start with the process!
Working USB drive formatted as FAT32
Surface RT/2 with 50% or more battery, can be plugged in
Yahallo files to boot from
Windows Boot Manager exploit, this one is important!!!
Prepare the USB drive and format as FAT32, doesn't matter if it's MBR or GPT. In my case I name the drives after their capacity.
Extracting the files, make sure the folder contents are on your USB drive's root directory (example: E:\ [stuff is here])
Once the files are copied over, unplug the drive from your PC and power off your Surface. Once powered off plug in the USB drive and boot from it by pressing power and holding volume down at the same time.
That's it! Exploit has been done and all you have to do is power off your tablet and turn back on. From my case at first it refused to display anything so I suggest leaving it for 5 minutes at most. Since SecureBoot is now disabled you can boot unsigned code like Linux, which is work in progress.
To re-enable secureboot replace the "Yahallo.efi" file on your USB with the file bellow, make sure the naming is correct.
Enabling secure boot brings you no advantage at all, you only restirct yourself with what you can do.
The CPU will load the boot setup, and then load up UEFI "bios". UEFI will then load /efi/boot/bootarm.efi (which needs to be signed with a secureboot-key) into ram and pass it control to then load other stuff in turn. We haven't been able to sign our own stuff yet ( if we could then we could just install uboot and bypass all the pain!). So.. we use Microsoft's, aka WindowsBootManager (/efi/boot/bootarm.efi) to eventually load our boot tool (i.e. grub2)
Microsoft's bootarm.efi checks for
efi/microsoft/boot/bcd (boot configuration data)
(which then loads our special "jailbreak" policy), then loads a test.efi shim, which finally loads a secondary EFI file - i.e. GRUB2 or uefi shell placed in the root.
The special FAT32 requirment of this device.
For a long time it has been thought that only some USB drives work on these devices. Now the issue is known: FAT32 isn't FAT32.
Windows's FAT32 is actually W95 FAT32 (LBA). But Linux creates proper FAT32. So a USB drive that is formatted with Linux won't work for these devices, because the UEFI firmware doesn't support proper FAT32.
Here is a comparison from the two possible partitions (Program used is Gnome Disks):
Type, (here german "Inhalt") doesn't matter. The parition type is meaningful.
Here is are steps to achive this with diskpart:
In the Start menu, type cmd
, and then click the entry for the cmd program.
At the command prompt, enter diskpart
(you have to approve this operation as an administrator). The prompt line should now display "DISKPART".
Enter list disk
. lists your drives.
Enter select disk X
, where X is the number of your selected disk.
(MAKE SURE TO SELECT THE CORRECT ONE!!!).
Enter clean
. wipes the selected drive partition table.
Enter create partition primary
. creates a partition and marks it as primary.
Enter select partition 1
. selects the partition number 1 (primary).
Enter active
. sets it as active (makes it bootable).
Enter format fs=fat32 quick
. formats the drive as FAT32 partition table (quick at the end indicates quick format).
Enter assign
. assigns the drive to a mount point.
Enter exit
.
Open a terminal and run this command to locate the right device:
Use fdisk
command accordingly:
sudo fdisk /dev/sdX
; X
stands for the right disk letter something in the region of b
, c
or d
Type o to change the partition table type to dos
When the command runs type d and enter to delete the existing partition, then
Type n to create new partition
Accept the defaults when ask for the partition type
and size
(assuming that is desirable),
Type p to see what you have done,
Type t to change the file system type,
Type c to create a W95 FAT32 (LBA)
partition,
Repeat step 2.5
, i.e. 5
above to see the created partition,
Type a to activate that partition so it automounts,
Type w to write the changes to disk
Format the again from the terminal:
Note: i
represents the partition number in this case it should be 1
Eject and replug the device
Refer to in the dev section to get further information about it.
You can easily disable secure boot by booting the . Just download the ZIP, extract it to your USB and boot it. Select the options with an USB keyboard. For further information how to setup the USB go to the more detailed explanation bellow.
More details can be found in the and in the .
According to a device will initially start up and look for a particular file based on the architecture of the system: As we need to bypass the standard boot, we use the jailbreak to hack the process using a supplemental policy, which enables testsignmode.
/boot.efi Hardcoded bootloader boots "bootarm.efi"(1: windows bootmanager) Bootmanager loads BCD (2) Bootmanager loads SecureBootDebug.efi, and the SecureBootDebugPolicy.p7b Then loads a test.efi (lolhax? shim) [this can be changed to our own shim, eg ] Which finally loads our boot.efi
More detail here -
(although we use GRUB2, the boot process is quite similar, and this is worth a read!)
Source:
Further development of Windows RT has been abandoned on the Surface RT/2 devices, which means that many devices are lingering away unused in drawers around the world, waiting for new life.
The hardware in the Surface RT/2 is still quite acceptable to be used as a tablet even many years after they were abandoned by Microsoft. For those interested in Windows RT on the Surface RT/2 a newer Windows 10 build can be installed. Instructions for updating a Surface RT/2 to Windows 10* or RT 8.0/8.1 can be found here -
https://windows-rt-devices.gitbook.io/windows/tools/windows-media-builder
*NOTE! No this will not install a full x86 build!
Discusses Microsoft's strict lock-down on running Win32 applications.
If you've used Windows RT for any length of time you have probably already realized that trying to run a traditional Windows executable is not possible under a stock configuration. If you do try and run one you will probably see a message like the following.
There are two reasons why this happens. The first reason is that Windows RT uses a completely different type of CPU architecture to the one used on standard Windows. Rather than using the x86/x64 from Intel or AMD, Windows RT instead uses the 32-bit ARMv7 architecture. So since almost every Windows executable on the internet is compiled for x86/x64 so do they all fail to work under Windows RT.
This may arguably have been trivial for software developers to solve were it not for the next major problem. If you do get your hands on an ARMv7 compiled executable and try to run it, you will see something like the next following message.
This is caused by another difference Windows RT has to standard Windows which is what is called the minimum signing level. This level is set in the kernel and cannot be changed as far as we know. It goes like this:
Allowing only for Microsoft code to run in the context of Win32 completely cut off any third party support for the system in this area. Third party developers were instead expected to write their software for the Windows Store.
Over the years there have been a couple of exploits for bypassing the aforementioned signing requirement. Since all are quite vaguely named, I shall refer to them only by their author. Here are all known exploits...
#
Level
Description
0
Unsigned
This is the value found on standard Windows machines. It allows any executable to be ran.
4
Authenticode
Would only allow for an executable to be ran if it were signed by a verified publisher. You could not run applications with a "Unknown Publisher".
8
Microsoft
This is what Windows RT is set to. Only code signed to run by Microsoft is able to be ran by a user.
12
Windows
Would lock any executable from running except those included with the Windows install.
Exploit
Date
Description
January 10 2013
The earliest known exploit. Works by using Windows Symbolic Debugger (cdb.exe
) to change the minimum signing level loaded in RAM. Requires two minute system up time to work properly and may sometimes cause a BSOD.
October 14 2015
bcdedit /set '{current}' loadoptions '/TÅ…STSIGNING'
enables test signing mode. Works around /testsigning
option being blocked because blocked options are checked for before they are passed to ntoskernel.exe.
Once passed ntoskernel.exe
truncates unicode down to 8-bits and Å…
becomes E.
Recovery ToolKit is a collection of scripts and files that make modifying the internal disk a breeze
To let the toolkit make adjustments to the storage of the RT device we have to boot onto a Windows 8.0 recovery environment. If you plan to do these you should first turn off any bit-locker encryption on the RT device.
Prepared recovery images that include the scripts and files are provided below. The base image is 500MiB but has to be supplied with an install file to apply. These are separated to the recovery image. Different regions are there to give the correct language, keyboard and culture options. Different regions should work on the hardware.
Booting into the recovery mode is done by following these steps
Switch off your device
Press and hold the volume down button
Press the power button
Release the volume down button after the surface logo appears
Wait about 2-3 minutes for the recovery environment to load (depending on usb stick speed)
Once loaded up in recovery you are asked to select a language and keyboard layout, do so. Proceed to then select the Troubleshoot and Advanced Options to get a CMD window. Execute the following command in the terminal window.
You will be greeted with a verification question that bit-locker is turned off. Once confirmed you are presented with the main menu.
You can navigate the menu's by entering the number of the corresponding menu item. 0 will always bring you up in the menu tree.
In automated installs you can wipe, automatically partition and install a .wim file that was put in the sources folder of the recovery. For Windows 8.0 this file is named Install.wim, these should also come with a CreatePartitions-UEFI.txt file to partition the disk with. Windows 10 only requires a file named Install_10_15035.wim and uses the /sources diskpart script.
Partitioning automates the wiping and partitioning of your device. It can format using the CreatePartitions-UEFI.txt in the sources folder or use the 2 default scripts provided in the Scripts folder. 4K is there because it was provided in the original source. Normally no 4K disks are used in known devices.
Installs executes dism with an .wim image out of the sources folder on the recovery disk. Respectively called Install.wim and Install_10_15035.wim.
Under boot you can copy over the boot EFI files to be able to boot Windows RT, add installed windows version to the boot manager and copy a broken copy of grub over to the efi partition and put it as boot manager instead. Using the copy efi options will copy a version of the windows boot manager to the S partition. This is necessary to boot any windows version. Windows 8.0 is happy with the recovery efi. Windows 10 requires a espefi for reasons. The grub is version 2.02 and is the only non windows environment the surface has booted in. The grub install comes with a config that has quite a flew automatic boot discovery options and basic actions. The grub config is unable currently to boot windows itself, so it makes it useless in that sense. Only do this if you intend to use or modify the configuration.
Under unlock you can apply bcdedit commands for testsigning and the secureboot soft disable to allow our self signed binaries.
Windows Recovery Environment (WinRE) and Windows RT Installation Files
Insider Preview (Mirror)
To be investigated, needs recovery images and test devices
To be investigated, needs recovery images and test devices
Here is a link to a website which holds recovery images for other devices that run Windows RT. If this link doesn't work anymore please contact us on the discord server.
Linux for Surface RT
Each way of booting has it's own advantages and disadvantages. EFI is easy to boot but has bad performance and power effiency. APX needs more special hardware to boot but performs much better.
EFI booting is the easier way of booting Linux.
No L2 Cache, no cpuidle (bad performance)
No power related features (no PMIC regulators)
USB drive
APX booting needs some special hardware.
No Wi-Fi
Dynamic Voltage Frequency Scaling (best performance)
USB A-to-A cable (straight: D+ -> D+, D- -> D-
)
µSD Card
Linux PC (x86)
USB-A host
2 GB DDR3 RAM
HDMI (with audio)
Vol+/-, PWR, Windows Buttons
Hall effect lid sensor (close tCover to suspend the device)
Hardware Acceleration (3D)
Bluetooth
Camera
Windows 10 on ARM32 runs on Surface RT and Surface 2
Despite previous statements to the contrary, Microsoft announced that ARMv7 Surface devices would remain on Windows RT 8.1 in January 2015. Following this announcement the devices were effectively abandoned.
Although this build is not generally considered suitable for daily use, it has attracted some interest from the remaining users of ARMv7 devices as an unofficial upgrade from Windows RT.
The last known version of the Store to provide somewhat normal functionality is 11706.1001.26.0.
Although it is possible to install more recent versions of the Microsoft Store it will only function to install updates for apps that are manually installed or apps already purchased and available on the users account, the purchase and installation of new apps directly from recent versions of the store on this build will not work.
This build omits certain apps that were either not available for ARM (ARMv7) processors at the time or were simply excluded from the build for other reasons. Although the included apps are limited there are numerous additional apps still available as well as updates for the preinstalled apps that are compatible with this build.
In its original release the following provisioned apps are included:
The provisioned apps may be updated to the following versions:
The following apps can be installed on this build to provide a more complete and standard experience, these apps can be installed on this build without modification however it should be noted that some are and will become inoperable as the services they rely on are retired.
Internet Explorer 11 is not installed or included in the Windows image as a Feature on Demand package by default however it is available as a separate optional package on the installation media in \sources\sxs which can be installed by running the command below:
This build supports all versions of Office 2013 RT which were previously included with Windows RT, if installed on this build Windows Update will work to provide any available updates for Office 2013 RT. Activating this version of Office requires license modification.
Most software that was recompiled for jailbroken Windows RT devices will run on this build.
Following the leak of this build to BetaArchive, two pre-prepared images have been distributed for Surface devices in both Chinese and English languages.
An image released in January 2020 has had its Edition modified to Windows RT 10 and Version increased to 1703 whilst retaining the original build number.
A highly modified image based on this build was released in May 2020 which has had its build number modified to 17763, while this image does contain components from later builds likely obtained from Windows PE it is in fact still build 15035.
(, , Backlight)
(+UHS-I mode)
(+ hotplug detection)
CPU and case temperature sensor
: only output (headphone & speakers)
During a security breach at Microsoft in early 2017 build 15035 of Windows 10 Creators Update was obtained, this build eventually leaked to on 24th November 2019. This build is currently the only leaked Windows 10 client build available for ARMv7 processors.
by , used under / Desaturated from original
A list of tested games can be found ("Cobs" @ )
A list of desktop apps ported to Windows RT can be found (@ )
by , used under / Desaturated from original
by , used under / Desaturated from original
App | Version | Date |
Alarms & Clock | 2017.203.236.0 | 2017-02-09 |
Calculator | 2017.131.1904.0 | 2017-02-09 |
Messaging | 3.2.2001.0 | 2017-02-09 |
Microsoft Edge | 40.15035.0.0 | 2017-02-09 |
Feedback Hub | 1.1611.3471.0 | 2017-02-09 |
People | 2017.203.2255.0 | 2017-02-09 |
Settings | 6.2.0.0 | 2017-02-09 |
Tips | 4.5.6.0 | 2017-02-09 |
View 3D Preview | 1.1701.30049.0 | 2017-02-09 |
Voice Recorder | 2017.130.1208.0 | 2017-02-09 |
Xbox | 2017.113.1250.0 | 2017-02-09 |
App | Version | Date |
Alarms & Clock | 10.1705.1303.2000 | 2018-09-08 |
Calculator | 10.1705.21204.0 | 2019-05-01 |
Messaging | 3.37.23004.1000 | 2019-05-22 |
Microsoft Edge | N/A | N/A |
Feedback Hub | 1.1712.1141.0 | 2018-04-26 |
People | 10.2.2791.2000 | 2018-09-08 |
Settings | N/A | N/A |
Tips | 5.12.2691.2000 | 2018-09-08 |
View 3D Preview | N/A | N/A |
Voice Recorder | 10.1705.1302.2000 | 2018-09-08 |
Xbox | 48.70.21001.0 | 2020-10-22 |
App | Version | Date |
App Installer | 1.0.32912.0 | 2019-10-19 |
Camera | 2017.727.40.2000 | 2018-09-08 |
Groove Music | 10.18052.11111.0 | 2018-06-05 |
Mail and Calendar | 16005.11001.20116.0 | 2018-11-26 |
Maps | 5.1705.1391.2000 | 2018-09-08 |
Money | 4.26.12334.0 | 2018-08-22 |
Movies & TV | 10.18052.10711.0 | 2018-06-04 |
News | 4.25.11802.0 | 2018-07-03 |
Lens | 16.0.32001.0 | 2020-10-01 |
OneDrive | 17.30.3.0 | 2018-07-01 |
OneNote | 16001.11629.20028.0 | 2019-05-05 |
Photos | 2017.35063.44410.1000 | 2018-09-07 |
Remote Desktop | 10.1.1148 | 2020-01-03 |
Skype | 12.1815.210.1000 | 2018-10-03 |
Solitaire Collection | 4.4.6132.0 | 2019-06-14 |
Sports | 4.25.11802.0 | 2018-07-03 |
Store | 11811.1001.27.0 | 2019-03-26 |
Sway | 18.2003.51105.0 | 2020-03-12 |
To-Do | 1.48.21892.0 | 2019-07-08 |
Weather | 4.26.12153.0 | 2018-08-09 |
Whiteboard | 20.11020.5479.0 | 2020-11-13 |
Wireless Display Adapter | 3.4.137.1000 | 2019-06-07 |
Windows 10 Build 15035 contains a few notable bugs:
The User Account Control user interface is broken, leading to issues starting programs requiring administrative privileges. Disabling UAC using the registry is mandatory to run these programs, this can be achieved by applying the registry entry below:
Cameras will not work even with the appropriate app and drivers installed due a missing registry entry, this can be resolved by applying the registry entry below:
Using Microsoft Management Console (MMC) snap-ins can cause a BSOD error (PANIC_STACK_SWITCH). This issue occurs most commonly with Event Viewer and Task Scheduler while occurring somewhat less frequently with Disk Management however it may manifest at random with any MMC snap-in.
The Screen Brightness setting does not persist after a reboot and Automatic Brightness does not always function correctly.
Night Mode does not function correctly.
The background colour for windows is gray instead of white.
This build is for the most part compatible with drivers originally intended for Windows RT aside from the following exceptions:
This build technically does not support NVIDIA Tegra processors, like the ones found in the Surface RT and Surface RT 2. The sdbus driver, responsible for providing an interface layer with the eMMC dropped support for the NVIDIA storage controller during Windows 10 development. You can however replace the driver with the one from Windows RT 8.1 build 9600.16384 to make the build boot on Surface tablets. On the Surface RT 2 (may also apply to Surface RT), using a version of sdbus newer than 9600.16384 will conflict with the nvpep driver causing a BSOD error (IRQL_NOT_LESS_OR_EQUAL) on boot. Later versions of the Surface RT 2 USB recovery media in particular may contain version 9600.16497 of sdbus driver which will trigger the error.
This build does not support legacy touch drivers built for Windows 8 RTM. Loading these drivers will cause the OS to register touch inputs in the top left corner of the screen.
Numerous issues are caused when attempting to use this build beyond its expiry date due to various digital signatures being outside of the validity period, this is normal and is by design once the build reaches its expiry date or when installed after it. Examples of some of the issues caused by installing or running this build with current date set are listed below.
The legacy Windows Defender UI (MSASCui.exe) is not functional and will terminate with a critical error (0x800b0101).
The Diagnostics Troubleshooting Wizard is not functional and will terminate with a critical error (0x800b0101).
Neither Microsoft Print To PDF or Microsoft XPS Document Writer will be available after installation. Should these be required both drivers can be manually installed from \Windows\System32\spool\tools
and overriding the Driver Signature Enforcement Check when prompted.
Although it is not an edition of Windows RT, this build has inherited some of the restrictions present in Windows RT. When certain Windows RT restrictions were established they were applied not by SKU but were instead applied to a specific architecture, in this case ARM (ARMv7). Issues known to be caused by this are:
User defined start-up programs are not available.
Incoming Remote Desktop connections are not available.
by , used under / Desaturated from original
APX and EFI Devicetree for Surface RT.
Please be careful with random device trees. They could contain wrong power management settings which could destroy your board.
Why do we need 2 different devicetrees for the same device?
APX can use the full potential of the device. Therefore APX can boot with the full devicetree which enables all currently supported features.
UEFI Firmware on the other hand blocks access to some power related features like PMIC regulators, L2 Cache and Dynamic Voltage Frequency Scaling. Therefore UEFI devicetree only removes features from the APX devicetree and only adds features which are currently UEFI exclusive. Furthermore the UEFI devicetree provides fixed regulators which in place of the PMIC regulators which are needed by other features. (e.g. µSD voltage switching from 3V3 to 1V8)
APX can boot normal and UEFI kernels. UEFI can only boot UEFI kernels. Therefore we use UEFI kernel for both methods of booting. This simplyfies development, testing and distributing kernel Images for both boot methods.
Visit the main Linux page for a short comparison between EFI vs. APX Linux
Building a Kernel is an advanced process for most beginners. If you just want to use Linux on your Surface RT you should go with the prebuilt binaries. If you want to help developing you need to compile the kernel on your own.
If you don't want to compile a kernel yourself, just use the prebuilt binaries. They are built everytime new hardware support is added. These images additionally include a lot of USB drivers and are digitally signed.
Get information on how to compile a working Linux kernel. You can either use mainline linux
, or grate-driver/linux
(based on Linux-next with experimental changes for tegra devices).
There are branches for all devices.
Use the master tree to only get tested and stable features for all devices:
https://github.com/Open-Surface-RT/grate-linux/
Use the device speccific branches for your device:
https://github.com/Open-Surface-RT/grate-linux/tree/surface-rt
https://github.com/Open-Surface-RT/grate-linux/tree/surface-2
https://github.com/Open-Surface-RT/grate-linux/tree/lenovo-ideapad-yoga-11
For information on how to boot your kernel, visit the Booting page.
Prebuilt binaries for APX/EFI linux
All zImage files that have (signed)
at the end, are digitally signed by @Leander. Here is the certificate file:
All files built include a lot of USB device drivers, so features like USB RNDIS will work.
For booting take the zip bellow, extract to USB and place your desired zImage and devicetree file onto the USB (don't rename). For more information visit the Booting.
You may want to change the line that begins with zImage
! Kernel files are distributed in a long name for archival sake so double check if you renamed it to just zImage
. root=/dev/mmcblk1p2
is the second partition of the SD card, change this if you want to use a different device/partition. RPI OS is a recommended distro, as it runs smooth
root=/dev/mmcblk0p2
is a location set to internal storage (eMMC) second partition, set it to this after cloning the installation over to internal storage.
root=/dev/sda2
is a second partition for USB only boot, set it to this if you want to USB boot only
mmc
stands for the storage type, more specifically a MMC memory module like eMMC storage or a SD card.
mmcblk[]0[]
would be used to specify the exact partition in a boot configuration file, for example root filesystem partition, in this case it can be mmcblk[]p2
for typical Linux distros.
0p[]
is used for internal storage definition as it's the primary MMC module
1p[]
is used for external MMC storage like a SD card
Typical Linux distro consists of two partitions; small FAT32 formatted boot partition with kernel stuff and a main root partition which contains the entire filesystem. Root file system is formatted as EXT4 in most cases!
In this case mmcblk[]p1
is a FAT32 boot partition and mmcblk[]p2
is a root file system.
sda[]
is used to define a USB drive's partition as it's considered an external media.
In our case sda1
would be FAT32 boot partition and sda2
a root file system.
Modules are required for features like WiFi. Make sure to extract them to the root of your root filesystem. The lib folders of the ZIP and of the root filesystem should merge. The modules are not required for booting, you can extract them while the system is running on your Surface RT. (E.g. When you are not able to extract the modules to a EXT4 filesystem on your main PC)
The latest binaries and modules of kernel, devicetree, modules can be found below.
Write to USB disk with e.g. rufus/etcher and boot.
No support for older builds. Use at your own risk.
Since the beginning of July 2021 our changes to the Linux kernel are upstreamed to grate-driver/linux. For pull requests we created our own fork:
This fork contains the latest changes. Eventually they will be merged to grate at some point.
This means you can either use grate-driver/linux
, without the need of modifying the kernel source, or you can use mainline
Linux, with the need of applying patches.
You should be able to use the latest versions without problems.
You can get it on Github:
git clone https://github.com/torvalds/linux.git --depth=1
or use .tar files from kernel.org
https://www.kernel.org/
grate-driver/linux has these patches already included.
Go to ./arch/arm/boot/dts
, create a file with the name tegra30-microsoft-surface-rt-efi.dts
and paste the contents of the code block in the devicetree sub-section.
Search for dtb-$(CONFIG_ARCH_TEGRA_3x_SOC) +=
in the Makefile (same directory), there you can see a few lines which begin with tegra30
, add a line with the devicetree file name you created above, but instead of the extension .dts use .dtb. Be aware that you will need to add a backslash (\) at the end of the previous line. Here is a picture how it should look like:
Open up a terminal and cd into your linux-5.12.3 directory. Then download the patch from bellow and run git apply 0001-Add-ACPI-Parking-Protocol-for-arm32-devices.patch
This should add ACPI Parking Protocol to your kernel and allows you to use SMP.
The patch doesn't follow kernel coding conventions. This will eventually be fixed.
This patch was created from commit c0a5652f from grate-driver/linux. The changes in the devicetree were removed. (Created with git format-patch -1 c0a5652f
) Rungit apply 0001-WIP-ARM-tegra-Add-Type-Touch-Power-Cover-support-for.patch
to apply the patch.
This patch was created from commit e2a2772b from grate-driver/linux. (Create with git format-patch -1 e2a2772b
) Run git apply 0001-i2c-GPIO-based-hotplug-gate.patch
to apply the patch.
Commonly used kernel parameters
microsoft-surface-rt.dtb
for APX booting
microsoft-surface-rt-efi.dtb
for EFI booting
Specifies the root filesystem which should be used.
/dev/mmcblk0pN
eMMC partition N
/dev/mmcblk1pN
µSD Card partition N
/dev/sdaN
USB partition N
tty0
for normal console (internal screen+tCover/USB keyboard)
ttyS0,115200n8
for serial console at 115200 Baud, no parity bit, 8bits (need uart access)
You can specify multiple console= options on the kernel command line. Output will appear on all of them. The last device will be used when you open /dev/console
. So, for example:
defines that opening /dev/console
will get you the current foreground virtual console, and kernel messages will appear on both the VGA console and the 2nd serial port (ttyS1 or COM2) at 9600 baud.
Note that you can only define one console per device type (serial, video). - https://www.kernel.org/doc/html/latest/admin-guide/serial-console.html
Waits for root filesystem. Some root filesystems will be mounted after the kernel finished initalizing hardware. Thats the case for USB. eMMC/SD seems to work without this parameter.
EFI doesn't support CPU idle therefore it must be disabled for efi booting. You shouldn't use this param for APX booting.
Configure and build Linux kernel for Surface RT
First run the command make ARCH=arm tegra_defconfig
This will create a standard kernel config for tegra SoC's.
Open the file .config
in the kernel source directory with your favorite text editor and paste the following at the end of the file
CONFIG_EFI_STUB=y
CONFIG_EFI=y
CONFIG_I2C_HID_OF=y
CONFIG_I2C_HOTPLUG_GPIO=y
CONFIG_BATTERY_CHARGER_SURFACE_RT=y
CONFIG_MWIFIEX=m
CONFIG_MWIFIEX_SDIO=m
CONFIG_SND_SOC_TEGRA_WM8962=y
CONFIG_HID_MICROSOFT=y
Note that some drivers (Wi-Fi) are built as modules. See exporting modules below to use them.
To build the kernel use the command make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j $(nproc)
- $(nproc)
sets the number of threads to your CPU core count
This command can take a while depending on your computer's speed. (5+ minutes)
Note: If you get asked what configuration you want to choose, just press enter, this will take the standard value.
If compiling was successful you should see some output similar to this:
(This doesn't need to be a the end of the log. Scroll up a bit ;) )
CALL scripts/checksyscalls.sh
CALL scripts/atomic/check-atomics.sh
CHK include/generated/compile.h
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready
The output kernel image is located at arch/arm/boot/zImage
The output device tree is located at
EFI:arch/arm/boot/dts/tegra30-microsoft-surface-rt-efi.dtb
.
APX:arch/arm/boot/dts/tegra30-microsoft-surface-rt.dtb
.
You can create a .sh script in kernel root to speed up your workflow
Some drivers will be built as modules. This reduces the kernel image size.
The module folder needs to be placed on the rootfilesystem in /lib/modules
.
Some drivers need to be built as module. For example the Wi-Fi driver. Wi-Fi needs a firmware which will be send to the Wi-Fi SoC at the time the hardware is probed. This can happen before the root filesystem is mounted. Therefore the driver can't load the firmware. If wifi is built as module it won't be loaded before the root filesystem was mounted.
This command will place the modules folder next to your Linux kernel folder.
You need to copy the modules after: - Modifying the kernel source for the first time - Every git commit - Editing a driver which is built as module (obvious?)
Boot an EFI-based Linux kernel on your Surface RT.
There is a premade ZIP below.
Most people use UEFI shell to chainload an EFI linux kernel. Using UEFI shell gives the option to easily specify and modify the kernel command line.
Place UEFI shell onto your bootable USB drive (as efi/boot/bootarm.efi) and place the zImage and the tegra30-microsoft-surface-rt-efi.dtb files onto the root of your usb drive.
You will need to create a startup script for UEFI shell:
root=/dev/mmcblk0p2
is a location set to internal storage (eMMC) second partition, set it to this after cloning the installation over to internal storage.
root=/dev/sda2
is a second partition for USB only boot, set it to this if you want to USB boot only
With the USB drive set up, a distro installed and secure boot disabled, you are ready to boot linux.
Shut the device off
Plug in your USB drive
Boot from the USB
Hold the volume down button
Press the power button for a second
Wait until the surface logo appears
Release volume down
You should see kernel logs onscreen (after a short while (15 seconds), wait for 1 minute if nothing happens try again)
With the method shown above, you will need your USB always on hand to boot linux. You can also install these boot files on the internal storage.
The easiest method is to just clean the windows boot files from the EFI partition, and replace them with the contents of your USB drive.
This will make you unable to boot Windows!
It is possible to make Windows and Linux dual-boot. For example, you can use GRUB.
Replace the contents of your startup.nsh on the USB with the following:
After booting, it will copy the devicetree, zImage and the startup-system.nsh over to the EFI partition on the internal storage. Fill your startup-system.nsh with the linux boot commands. (The commands you normally have in your startup.nsh)
This method is also useful for updating the device tree and zImage, if you already have existing linux files there.
A Surface RT with secure boot disabled. Visit for more information on how to disable it.
A USB drive, formatted as FAT32 with either MBR or GPT. The partition doesn't require being marked as EFI system partition. Be aware that .
A root filesystem/distro on your SD card (recommended)/internal storage/USB. See .
There are .
You may want to use different bootloaders, like .
You may want to change the line that begins with zImage
. It is the kernel command line. root=/dev/mmcblk1p2
is the second partition of the sdcard, change this if you want to use a different device/partition. is a recommended distro, as it runs smooth
See for further information.
Extract this ZIP to your USB, and add your zImage and device tree to it. You can find precompiled binaries .
If you have any issues, feel free to contact us on .
Boot Linux on Surface RT
UEFI boot gives you instructions on how to boot Linux using the UEFI firmware.
APX boot gives you instructions on how to boot Linux using the fusee gelee exploit. It's more complicated than UEFI boot as you need a second computer with the correct files.
Sometimes you need to edit the preconfigured kernel command line. Kernel parameters will give you a brief overview and tell you possible configuration options.
Boot linux on your Surface RT using the Fusée Gelée exploit.
APX booting is for advanced users. Visit the main Linux page for a short comparison between EFI vs. APX Linux
You should read all the the sub-sections before you start. The subsections are logical ordered from top to bottom
Get the latest and tested Devicetree for APX boot.
As we bypass all the firmware with APX boot, someone needs to setup memory and load Linux. Uboot is used for this.
Get prebuilt binaires for Das U-Boot if you don't want to compile it yourself.
Get a Linux kernel for APX.
Linux without any root filesystem is useless for the end-user. Get instructions on how to get one.
Fusée Gelée is the exploit used to bypass the security checks for APX mode. Get information on how to execute the exploit in order to boot linux.
Booting linux with APX mode is rather complicated. You can find a little summary and final instructions here:
Send a payload which patches a security fuse temporarily (until next power off). Uses original nvflash to read the BCT from Device.
BootConfigTable for the Surface This defines SDRAM configuration, as well as bootloader location. Described here (with compiler / decompiler) https://github.com/NVIDIA/cbootimage-configs
Send and launch fusee exploit binary over usb, using python script.
Send and launch custom bootloader binary over usb, using modified NvFlash to bypass security checks.
(Experimental) Loading a bootloader binary and executing at specific memory address by adding --setentry 0x80808000 0x80808000 before --bl. 0x80808000 for example, is the memory address for the factory UEFI SPI-Flash bootloader. The factory bootloader binary is obtained by using the decryption script with the relevant SBK and dump of the SPI-Flash memory.
aka. Distro
There are still a few distros out there which support ARM32
Archlinux
Fedora
Lubuntu 16.04
... (append it pls)
Downloads for older and probably dated builds can be found here: https://berryboot.alexgoldcheidt.com/images/
To make use of hardware acceleration we need to use grate-driver Following distros support grate-driver out of box:
Archlinux
PostmarketOS
Linux comes in all different flavors just like ice cream, you can choose whatever fits you. For ease anything Debian based is recommended, advanced users can look for Arch or Fedora. Difference is how commands work but deep down everything is nearly same.
There are two ways of booting Linux, APX payload or EFI boot, this time let's focus on EFI.
Prepare SD card with any Distro of your choice You can use Balena etcher, Rufus, Raspberry imager etc. Doesn't matter which one
Prepare a FAT32 formatted USB drive with EFI and kernel files, they are linked below, extract to root directory
Put the SD card in your Surface
Turn off tablet, complete shutdown and not sleep mode
Plug in the USB drive you prepared
Turn on by holding volume down key, release it when the logo appears
Let it boot. If it does it will go past the kernel log and load a distro of your choice. It should be safe to unplug the USB once Distro has loaded up. (The distro could have mounted the USB, so be careful with that)
Boot Linux on Surface RT. Setup is a bit tedious but once the setup is complete it is very easy to use.
To boot Linux on Surface RT we use the Fusée Gelée cold boot exploit. See Fusée Gelée for further information.
Read all pages of the Linux topic carefully before you try to boot Linux
Extract BCT from your device
Build U-Boot with correct devicetree
Create a U-Boot boot script
Build Linux with correct devicetree
Build Root Filesystem for ARM32
Create/Get BootToolChain
Place zImage, devicetree and boot.scr on first partition
extract rootfs.tar on second partition
Insert SD Card into the SurfaceRT
Go to to your BootToolChain directory
place your U-Boot 'u-boot-dtb-tegra.bin' in ./u-boot
If you have UART access you should see U-Boot boot process
Linux should be booted and be accessible via UART and/or show HDMI/Screen Console
Enjoy and fix issues.
If you have UART access you should see U-Boot boot process
Linux should be booted and be accessible via UART and/or show HDMI Console
Enjoy and fix issues.
postmarketOS for Surface RT
https://wiki.postmarketos.org/wiki/Microsoft_Surface_RT_(microsoft-surface-rt)
Currently there are no prebuilt images available. Please build your own image using pmbootstrap.
U-Boot for Surface RT.
You can use U-boot for tegra
git clone https://github.com/OE4T/u-boot-tegra; cd u-boot-tegra
or U-boot Mainline
git clone https://gitlab.denx.de/u-boot/u-boot.git; cd u-boot
THIS IS VERY IMPORTANT!!! If you skip this step you can damage your device Use the devicetree below. Don't use the devicetree from Linux.
Replace the content of ./arch/arm/dts/tegra30-cardhu.dts
with following code:
Now you can build U-Boot:
make cardhu_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
Now you should find the file./u-boot-dtb-tegra.bin
This your Uboot Image which contains the SPL and Uboot.
Booting Linux from UART is tedious and you may don't have UART access. To automate the boot process a boot script can be used. Create a file:
Compile it using:
mkimage -A arm -O linux -a 0 -e 0 -T script -C none -n "SurfaceRT Boot Script" -d boot.script boot.scr
Place boot.scr
on the SD Card next to the kernel.
Tip: Don't hit any key to stop autoboot
At the moment both UHS-I SD cards and non UHS Cards are supported. UHS Cards operate at higher speeds and use 1.8V instead of 3.3V. (1.8V now works, we found LDO5 in the PMIC which handles SD signaling voltage)
Use GParted or similar tool to create 2 partitions on your SD Card. First partition FAT16/32 - 255MiB Second partition EXT4
Install Raspberry Pi OS on your Surface RT
Make sure that Secure boot is disabled before you try to boot Linux.
Installing Raspberry Pi OS is very easy in comparison to some other distros.
It can be done on a Windows or Linux host and therefore is easily accessible for everyone.
Place the efi folder
, startup.nsh
, zImage
, and tegra30-microsoft-surface-rt-efi.dtb
files onto the "boot"/fat32 partition of the USB drive. Confirming any overwrites.
If you are using Linux you can do this before booting RaspiOS for the first time on your host machine.
If you are using Windows you need to boot RaspiOS on Surface RT and copy the modules on from e.g another Fat32 USB to the root filesystem. You need to reboot once to load the modules correctly.
You need to install RaspiOS on USB first
It is only recommended to install it on eMMC if you really want to use it on eMMC. Otherwise you will wear out your eMMC unnecessarily.
Taken from Discord user Misterobots
:
Once Raspberry Pi OS has booted from USB.
Go to Start menu
-> Accessories
-> SD Card Copier
.
Select the USB drive as the "From".
Select the eMMC (mine was MBG4GA) as the "To".
Check the box that says "New Partition UUIDs". Click Start
Edit the startup.nsh
(on the eMMC boot partition, that was just copied to) and change the root=/dev/sda2
to root=/dev/mmcblk0p2
. Then save.
Once the Copy has finished (with no errors), shutdown the Surface RT, remove the USB drive, then power on the Surface RT normally. (do not hold Vol. down)
This should get you booted from eMMC with both boot and rootfs on the eMMC.
If you want to install Raspi OS on eMMC do the steps below after booting from eMMC.
There is only one thing to do after you can see the desktop.
Open the Terminal and enter sudo raspi-config
Choose Advanced Options
Choose Expand Filesystem
Now your SD Card / eMMC is writable and can use all of its space.
The default plugin always shows 0% charge left. Use the "Battery Monitor" plugin instead. It should be already installed
Unlike KDE, GNOME, MATE or XFCE, Raspberry Pi OS running LXDE does not seem to have any plugin to control the brightness. However, it is supported in the kernel level.
Create the following udev rule so that this tool can be run without `sudo`.
Reboot.
Now you can run the software with rpi-backlight-gui
. You can also create a desktop shortcut. Create the file `~/.local/share/applications/rpi-backlight.desktop`
with the following contents.
The left SanDisk Card is UHS-I (SDXC-I) and has SpeedClass 3 (3 in U) and VideoClass30 (V30) See The right (Intenso) Card is an old Class10 (10 in C) SD card which works.
Use this
Grab all the "standard files" from - (, , ).
Use (sudo apt install rpi-imager
) to image a USB drive as you normally would.
Edit the startup.nsh
file on the USB drive to show as below. For further information about can be found here
Download the modules and firmware - - and place them in the root directory /
. This is important. Without modules some features like Wifand i or CPU Temperature Sensor won't work.
Insert the USB Drive into the Surface RT and
Download the tool using `pip`.
See for more details.
The Root Filesystem contains all the necessary binaries your system needs to boot
There are two ways to get these binaries : Build your own root filesystem with Buildroot or similar tools : Get a premade root filesystem (distro)
pro | contra |
Very small (few MB) | You need to install all packages by yourself |
Boots very fast | For advanced users |
pro | contra |
Many packages preinstalled | Large (up to few GB) |
Community support | Bloated |
Easy for beginners (except Arch) |
RootFileSystem for Surface RT
Download Buildroot from https://buildroot.org/download.html
unpack it
open directory in terminal
type: make menuconfig
-> Target options
-> configure for ARM. (see picture)
There are maybe better choices but it works at the moment.
Type: make
wait for 15-20 minutes. A lot of stuff is downloaded and compiled.
When finished you will find ./output/images/rootfs.tar
target packages: libraries -> hardware handling -> libgpiod[*] -> install tools[*]
Make sure that you have Yahallo applied. See here
Make you that you copied the modules forlder to /lib/modules
Make sure that the kernel version and the modules version do match
Get the modules folder name and compare it to uname -r
See the for further information
Large image of PCB Teardown with photos of board and setup
Release Date | October 2012 |
Display | Screen: 10.6" 1366x768 16:9 Display - LTL106AL01-002 (1368x768) LVDS Backlight WLED 12V; Screen Input Voltage: 3.3V |
SoC | Nvidia Tegra 3 T30 |
CPU | Quad core Cortex-A9 @ 1.3 GHz |
Core architecture | ARMv7/ARMhf 32-bit |
RAM | Micron 2RE22 D9QBJ 2 GB DDR3 SDRAM |
Storage | - Samsung KLMBG4GE4A NAND Flash - 64GB or 32GB capacity |
Camera | 1.2MP Rear and 1.2MP Front |
Operating System | Windows RT 8.0 (Upgradable to Windows RT 8.1) |
Battery | Samsung Li-ion: 7.4V at a 31.5 Wh |
Technical Reference Manual
Nvidia provides a TRM (Technical Reference Manual). You can download the latetest TRM from Nvidias page here but you need to register an developer account.
https://developer.nvidia.com/embedded/tegra-3-reference
Page 20ff. Lists some Alternate pin functions. https://www.data-modul.com/sites/default/files/products/Colibri%20T30%20Tegra3%201GB_specification_12004760.pdf
https://pinout.torizon.io/ Even better information about GPIO Special functions
Inside the device is a OEM connector labeld J14 that probably served as development and debug access for components of the device.
Open your device according to this IFIXIT Guide:
https://de.ifixit.com/Teardown/Microsoft+Surface+Teardown/11275
The pads are coated with a solder mask. The solder mask can be removed carefully with a sharp object.
Be careful you don't want to cut any traces. This could damage and destroy your device! Pad size is 0.5mm
If you can identify some pins feel free to update this Schematic template
Surface RT UART-A access
To properly debug Linux a serial console is needed. Tegra30 has 5 hardware UART ports. They are called UART-A/B/C/D/E
UART-A is on the ULPI data pins on the SoC (https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-tegra/tegra30/pinmux.c#L25)
UART-A TX can be found on J14. It transmits data at 1.8V UART-A RX can be found on J14. It receives data at 1.8V
Below you can see where you can find the UARTA TX, RX pad.
GND from Surface RT must be connected to GND of your UART adapter. If you use fusee gelee your devices are connected via USB-GND. If not you must find suitable GND on sRT.
To use UART you need i.e. a usb-uart adapter, a raspberry pi, arduino, etc... A "silicon labs cp210x usb to uart bridge" was used in testing. This is a 3V3 chip which is 5V tolerant. Receiving a 1.8V signal works fine. But sending 3.3V to a 1.8V input is dangerous.
Be careful when you remove the soldermask (green layer covering the copper). You dont want to cut the trace or short it to any trace below! These pads are very tiny, soldering them is hard without skill and good equipment. It's recommened to use small solid core wire. if you use stranded wire (like i did) only use 2-3 strands. Cut off the rest. Secure your wires with good tape.
A Fusée Gelée payload which initializes UART-A with Baud: 115200, Bits: 8, Stopbits: 1, Parity:None
was used to find it.
After initialisation its spams data to the transmit buffer.
We took an oscilloscope and checked that there isn't a pin which provides more than 5V (max of uart adapter).
After this we probed every pin with a usb uart adapter and minicom. After a few seconds we found the corresponding TX-pad.
Top left: dmesg -Tw
show that sRT is booted in APX mode. Also shows if it gets disconnected.
Bottom left: Fusee Gelee launcher with payload and ProductID (see dmesg)
Top right: Minicom output
Bottom right: Fusee gelee payload source code
At this time we got uboot booting. We got output from uboot over UART-A-TX so we only had to bring an TX signal from pc to the RX pad on surfaceRT.
One educated guess later we found RX next to TX.
Uboot told us that 1
isn't a valid command. after this we tried help
and and got a solid answer
ICs which are used in the Surface RT
Connect 3.3/5V UART hardware to a 1.8V device using a voltage divider
We recommend buying suitable 1.8V equipment
3.3V: Z1 = 20k; Z2 = 20k
5.0V: z1 = 20k; Z2 = 47k
These values should be safe even if the resistors vary by 5%
Test the output Voltage before you send data to 1.8V ports
Connection of Z2 to GND is very important. If it has a bad connection Vout can get close to Vin
You need to have a common GND. The easiest method is connecting UART-GND and SRT-GND.
Raspberry Pi's use 3.3V UART. Surface RT only uses 1.8V.
Raspberry Pi can receive 1.8V signals without a problem. But the Surface doesn't want to receive a 3.3V Signal. Therefore we need a levelshifter. A simple and cheap solution is to use a voltage divider, as shown above.
Boot loader for the RT1 is written on a Winbond W25Q32VIP. This is a 32MBit (4K Byte) SPI flash chip that operates in Single mode and comes in an 8 pin WSON 6X5-MM package. Its contents are locked in because of the P variation in its name that specifies the OTP (Write Once) feature in the chip. This means the contents can't be replaced. We can however replace the entire chip.
Below is the pinout for Single mode operation of the chip.
Replacing the chip is not to be taken lightly. It requires a hot air station to remove as it is a surface mounted package with a big ground pane in the center. Beside this there are multiple components close to the chip that need to stay in place.
Begin by the shield covering the SOC, Memory and flash chips. This will come of very easily with little force. Take your time doing this.
Once removed we have an overview over the most important components
To make the flash chip better accessible, the metal that held the shield in place can be bent back slightly. To help the desoldering the back of the PCB should be pre-heated at a low temp before starting work on the front. This will help with removing the chip and its big ground pane. Then start heating the flash chip itself at a low flow to not disturb the components around it. Make sure to heat it properly as forcing the chip off will break the pads on the PCB.
Use a to get TX 3.3V / 5V down to 1.8V
See for further on information on how to setup your RPI.
Before starting it is recommended to dump the contents of the chip as it contains unique configuration aspects for the device. Check the on how to do this
IC
Datasheet(s)
Cypress Semiconductor CY8C20466A
TI MSP430G2402 Microcontroller
belongs to "ATMEL: mXT1386E - TouchController"
Atmel UC3L microprocessor
Pin | Name | I/O | Function |
1 | /CS | I | Chip Select Input |
2 | DO | O | Data Output |
3 | /WP | I | Write Protect Input |
4 | GND | Ground |
5 | DI | I | Data Input |
6 | CLK | I | Serial Clock Input |
7 | /HOLD | I | Hold Input |
8 | VCC | Power Supply (3.3V) |
Setup your Raspberry Pi to communicate with the SurfaceRT.
To enable the UART on your Raspberry Pi to be used as host you need to configure it:
sudo raspi-config
Go to 5 - interfacing options
Go to P6 - serial
Would you like a login shell to be accessible over serial?
Answer: 'No'
Would you like the serial port hardware to be enabled?
Answer: 'Yes'
Reboot your Raspberry Pi.
See Raspberry Pi for information on how to physically connect your RPI and your SRT.
To establish a UART-Connection to the Surface RT use
RPI2: minicom -b 115200 -D /dev/ttyAMA0
RPI_Zero minicom -b 115200 -D /dev/ttyS0
To escape from minicom use STRG+A and then X.
Further information: https://www.raspberrypi.org/documentation/configuration/uart.md
Letter number | dec range start | hex range start | Letter |
0 | 0 | 0x00 | A |
1 | 8 | 0x08 | B |
2 | 16 | 0x10 | C |
3 | 24 | 0x18 | D |
4 | 32 | 0x20 | E |
5 | 40 | 0x28 | F |
6 | 48 | 0x30 | G |
7 | 56 | 0x38 | H |
8 | 64 | 0x40 | I |
9 | 72 | 0x48 | J |
10 | 80 | 0x50 | K |
11 | 88 | 0x58 | L |
12 | 96 | 0x60 | M |
13 | 104 | 0x68 | N |
14 | 112 | 0x70 | O |
15 | 120 | 0x78 | P |
16 | 128 | 0x80 | Q |
17 | 136 | 0x88 | R |
18 | 144 | 0x90 | S |
19 | 152 | 0x98 | T |
20 | 160 | 0xA0 | U |
21 | 168 | 0xA8 | V |
22 | 176 | 0xB0 | W |
23 | 184 | 0xB8 | X |
24 | 192 | 0xC0 | Y |
25 | 200 | 0xC8 | Z |
26 | 208 | 0xD0 | AA |
27 | 216 | 0xD8 | BB |
28 | 224 | 0xE0 | CC |
29 | 232 | 0xE8 | DD |
30 | 240 | 0xF0 | EE |
32/64GB internal eMMC
I2C Devices which can be found in the Surface RT
i2c-0 i2c 7000c000.i2c I2C adapter - LVDS DDC (according to cardhu devicetree) - access on J14 i2c-1 i2c 7000c400.i2c I2C adapter - daughter board (touch controller; touch/typeCover) - access MAYBE on DaughterBoard Testpoints i2c-2 i2c 7000c500.i2c I2C adapter - nothing - dont care i2c-3 i2c 7000c700.i2c I2C adapter - HDMI DDC - Via HDMI-port i2c-4 i2c 7000d000.i2c I2C adapter - PMIC - not found :(
I2C addresses on Bus - 0: 0x00; 0x28 - 1: 0x2D; 0x39; 0x5B - 2: - 3: depends on HDMI display - 4: 0x0A; 0x1A; 0x2D; 0x4A; 0x4C; 0x60
Access to I2C Bus 0 can be found on .
Technical information about Type/Touch Covers for Surface RT/2
HID over I2C
Address: 0x00
Bus speed: 400kHz
HID_Descriptor: 0x0041
ACPI Device: SNMU
Power:
Bridge IC: PMIC.REG1: 1.8V
tCover Power: PMIC.REG3: 2.8V
HID Interrupt: O5 Hotplug Interrupt: S0
The tCover I2C address is 0x00. This address is reserved for general call
.
Linux doesn't allow I2C Slaves to use this address therefore the I2C driver must be patched to allow 0x00 as valid Slave address.
i2c-hotplug-gpio
is a grate driver and doesn't work in mainline.
if we take a look at the ACPI table we see several GpioIO functions.
Identifying the Volume keys is easy. We can dump the GPIO-Controller from UEFI shell while a volume key is pressed or released.
We see that we changed something with a button press. Nice! We see that 1 Byte has changed from 0xC0 to 0x80 at address 0x438 In binary: 1100 0000 -> 1000 0000 => Bit 6 has changed.
Lets take a look at 0x438
Now we know that we changed Pin6 in Port S => Vol-Down is connected to PS6
S is the 19th letter of the Alphabet counting from 1 (A=1, B=2, C=3,...) S is the 18th letter of the Alphabet counting from 0 (A=0, B=1, C=2,...) TRM tells us that every port has 8 pins. So lets multiply 18 by 8 which equals 144 and add our PinOffset: 6 144+6 = 150 Convert 150 from dec to hex: 0x96
We can match the 4 GPIOs to the SurfaceHomeButtonDriver. We can see that Windows knows 4 Interrupts. At the moment we dont know how to map the WindowsIRQ to ACPI-IRQ or LinuxIRQ
Linux enumerates GPIO in the same way as ACPI:
portNumber * 8 + pinOffset (+ gpioControllerOffset)
(gpioControllerOffset is 0 on tegra 3)
We know that we deal with:
Vol-Down: 0x96 / 150d
Vol-Up: 0x97 / 151d
We guess 0x97 because it is a normal shared interrupt.
The other 2 interrupts are WakeUp Interrupts which should belong to the Power/WindowsButton
include libgpiod
in your root filesystem
type gpiomon <BUS> <Gpio-Number>
Press the button a few times you should see the gpio chaning in realtime
first we must set the pins to GPIO mode. Tegra standard is SFIO mode. 0x6000 d000 is the GPIO Controller base 0x0000 0408 is PortS CNF register. We want to set pin 6/7 to GPIO mode -> 0b1100 0000 -> 0xC0
we can write memory with devmem
devmem 0x6000d408 8 0xC0
Now the GPIO Controller treats PS6/7 as GPIO
cd /sys/class/gpio
ls ./
should show export, gpiochip0, unexport
gpiochip0 is the gpio controller; 0 tells the offset
we can export a pin to userspace
echo 150 > export
echo 151 > export
Now we can use PS6/7
check the direction with
cat gpio150/direction
it should show "in"
but you can set it with echo in > gpio150/direction
Now we can read the value
cat gpio150/value
this should return 1
if you press VOL-Down it should return 0
This tells us that the pin is pulled up and active_low.
Now remove the gpio from userspace that it can be used by drivers again
echo 150 > unexport
echo 151 > unexport
HID over I2C
Address: 0x28
Bus speed: 400kHz
HID_Descriptor: 0x0001
ACPI Device: SNMU
Cover
Generation
VendorID / hex
ProductID / hex
Touch
1
045E
079A
Type
1
045E
079C
Touch
2
045E
07A7
Type
2
045E
07A9
Power
1
045E - tbc
07DA - tbc
related to Surface Home Buttone Driver
Cypress touch sensor config?? MSP430??
HID over I2C
Address: 0x5b
Bus speed: 400kHz
HID_Descriptor: 0x0000
ACPI Device: TOUA
http://ww1.microchip.com/downloads/en/DeviceDoc/mXT1386E_2v4_Datasheet_BX.pdf
ACPI tells that the device TOUA uses I2C-2@400kHz with an address of 0x5b
HID Interrupt: K2
Normal I2c
Address: 0x0A
Surface RT uses the Embedded Controller Topology. The controller is located at 0xa.
That means that there must be an IC somewhere which interacts with the Charger and the Fuelgauge and provide an interface to both of them to the SoC.
The Charger and the Fuelgauge are exposed through 0xa which provides an ACPI interface.
The ACPI BAT0
device deals with the Fuelgauge.
The ACPI ADP0
device deals with the Charger.
The ACPI methods like _BIX, _BTS, ... provide all the necessary information about the battery and the charger.
They can be decrypted by reading the ACPI Spec p. 492 10.2 Control Method Batteries
https://wiki.ubuntu.com/Kernel/Reference/Battery "(Control Method) Batteries and ACPI are tied together in quite a complex way. Generally, the battery state information is transmitted over a SMBUS bus to the embedded controller, a.k.a. EC, which in turn interfaces to the OS via ACPI methods. These methods can interrogate the embedded controller for battery state information ..."
Battery <-- EC <--> BIOS ACPI Methods <--> OS
Since there is no ACPI implementation for ARM32 and we need to replace the ACPI Methods with a custom driver. all Necessary information can be found in the SSDT0000 ACPI table
The Embedded Controller directly interacts with the Charger and the Fuelgauge.
BQ28400
https://www.ti.com/lit/ug/sluu431/sluu431.pdf https://www.ti.com/lit/ds/symlink/bq28400.pdf?ts=1625607689401&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FBQ28400
BQ24725A
The Embedded Controller topology prevents the use of SmartBatterySystem (SBS) and requires an ACPI or custom driver. ACPI isn't (fully) implemented on ARM32 therefore we need a custom driver which resembels the ACPI methods.
https://uefi.org/sites/default/files/resources/ACPI_5_0_Errata_B.pdf
Normal I2C
Address: 0x1A
https://statics.cirrus.com/pubs/proDatasheet/WM8962_Rev4.4.pdf
The I2C address seems to be 0x34 but that's the 8 Bit address. Shift the address 1 to the right (>>1) and you get 0x1A as 7Bit address
Wolfson WM7220 Microphones
SMBus SBS
Address: 0x4C
https://www.onsemi.com/pdf/datasheet/nct1008-d.pdf
The Slave address and the ManufacturerID register do match. + This sensor is also found on Cardhu.
Integrated Device Technology V103 LVDS encoder - IDTV103
Tegra 3 only supports a parallel interface or SPI LCD, DVI, an HDMI HDTV, RGB monitor or a MIPI DSI LCD.
Surface RT uses a LVDS Display. Therefore an translator is needed.
They used a Integrated Device Technology V103 LVDS encoder https://datasheetspdf.com/pdf-file/696938/IntegratedDeviceTechnology/V103/1
The converter is transparent to the SoC and does its job without any configuration. It only needs power and the PowerDown pin set to LOW
B2 - power down
If we set this pin to LOW from UEFI Shell new information can't be send from the SoC to the display. In this case the image fades out.
https://www.panelook.com/LTL106AL01-002_Samsung_10.6_LCM_overview_19126.html
Many tools exist which can decode EDID.
On Ubuntu you can use edid-decode
.
The ouput is below...
You can also use this EDID reader page
WIP At the we use a samsung display with same resolution and similar timings which works. But to optimize the devicetree someone has to decode EDID to panel-timings
https://elixir.bootlin.com/linux/latest/source/include/drm/drm_modes.h#L201
https://glenwing.github.io/docs/VESA-DMT-1.12.pdf page 57
Controlling the following GPIOs from UEFI Shell gave the result below. The GPIOs were extracted from ACPI
GPIO
Backlight
Logo
Note
Function
B2
Y
N
Image fades out
LVDS power down
DD0
N
Y
Logo can bee seen with
external light source
backlight power
DD2
N
N
Display is dead
panel power
H0
N
Y
PWM brightness control
PWM brightness
Pin
2/3 Panel VDD
GPIO DD2
25 BL_PWM
GPIO H0
26 Backlight enable
GPIO DD0
28/29/30 LED Anode
Always connected to 12V
The Boot rom starts and loads the firmware from a SPI-Flash.
Information about the battery pack and BMS
A battery pack requires a reliable BMS. Without it you can't control and balance the cells, leading to fire hazards.
???
Specifications
Title
Manufacturer
Samsung
Capacity
31.5Wh
Voltage
7.4V
Model number
P21GK3
Information of the SPI flash
Dump the SPI flash by using the linux command line tool dd
.
Command: dd if=/dev/mtd0 of=mtd0
This will dump the SPI flash to the file mtd0.
This is what the SPI flash device tree entry looks like.
The first 6128 bytes are the BCT, encrypted with your platform key. The loader for UEFI is located at 0x0100000.
To check it yourself,
To encrypt the BCT you got form nvflash use the following script, and replace <platform key> with your platform key.
Example usage: ./encrypt.sh surfacert.bct surfacert-encrypted.bct
To check if it is really the same, create a hexdump of your SPI flash dump and encrypted BCT. Your encrypted BCT should match the first 6128 bytes of the SPI flash dump.
The files are encrypted and board specific. You cant use them on your Surface RT
A dump from @Leander's Surface RT. Here is the platform key of the used Surface RT: 28a5d126adf421e6a39bfc8f7ff32308
The following script processes a SPI dump. It extracts and decrypts the BCT & Bootloader
Boot Configuration Table
To decompile your BCT into a configuration file, use the tool bct_dump.
Usage: bct_dump <your-bct-file>
Tip you can add > <output-file>
to reroute the output to a file.
You can compile your bct.cfg file by using the tool cbootimage.
Usage: cbootimage -s tegra30 -t 30 -gbct <input-bct-configuration-file> <output-bct-file>
Example: cbootimage -s tegra30 -t 30 -gbct surfacert-custom.bct.cfg surfacert-custom.bct
To generate a image file with your BCT and provided bootloader, again use cbootimage.
Usage: cbootimage -d -s tegra30 -t 30 <input-config-file> <output-image-file>
Example: cbootimage -d -s tegra30 -t 30 surfacert.config surfacert.output
<input-config-file> is a file controlling how the .img file should be created. It has the following structure:
Example:
Doing this will create a image file of your BCT and the bootloader you provided. The BCT will automatically updated with the correct sizes and hashes.
The boot configuration table contains information about which bootloader to boot. On the Surface RT it is stored on the SPI flash. Go to , to dump it directly from SPI. Or do it with nvflash (recommended): sudo ./utils/nvflash_v1.13.87205 --getbct --bct surfacert.bin --configfile ./utils/flash.cfg
Replay Protected Memory Block partition on the internal emmc
This part of the emmc is meant to be only read and written by trusted software.
As it turns out you can read this partition on some devices. It is possible if you have a "CMD12" emmc. If it is a "CMD13" emmc it doesn't work. Read operations happen from within linux, also information about the emmc is gathered there, use the following commands:
The extcsd.txt file will contain extcsd information of your emmc, the rpmb.img file will contain the RPMB dump, if dumping works.
If you happen to do this process contact @utf-4096 on our discord server, as he is interested in this information (if dumping worked and in the extcsd info).
Current (May 2021) sample size of the above information is 3, so it may not apply to you.