Hi Folks.
With both a Zune HD and WP7 devices not supported via USB conenction to a Surface RT, I was thinking there had to be a way to tweak/re-write the ZuneHD / Zune driver files to allow them to be installed on the Surface RT...The ZuneHD is an ARM based device running Windows Embedded - and RT is an evolution of Windows CE you might say.
If so, the earlier regedit hack to allow the WP7 (or ZuneHD) to connect as a USB mass storage device would hopefully be possible, without the full ARM recompile of the Zune software (a near impossible task).
It's ridiculous that pre WP8 devices cannot even be connected via USB to facilitate file transfers "non-cloud" way.....
I tried manually updating drivers on the Surface RT with my ZuneHD connected - pointing at the Zune 4.7 drivers, and it confirmed that they were not ARM compatible.
Cheers,
Sheeds.
...
"tweak/re-write" an x86 kernel-mode driver into an ARM kernel mode driver for installation on a platform that doesn't (currently) permit unsigned drivers at all? You act like you have some idea what an instruction set architecture is, but you say this. If I ran this entire message through a translator to Finnish and then ROT-13'd it, you'd probably have a better chance of understanding the post than of managing to get the existing x86 Zune driver working on RT without a full re-write plus an additional hack to bypass driver signing. The Zune driver isn't exactly open-source... binary emulation *might* work at some point, but it's not practical for a kernel-mode driver (signature checks or not).
There is not, and never was, a hack to allow Zune-like devices to connect using UMS. The hack you're referring to merely un-hid the MTPZ (Media Transfer Protocol, Zune) devices from Windows Explorer. MTP(Z or not) and UMS are not at all the same thing, although they can sometimes be used for some of the same purposes.
We'd have a much better chance of getting Zune to run on RT, actually. That's "just" a matter of emulating an x64 machine for it to run on and passing its system calls through to the real OS and back again. Won't do any good for this use case without the driver, of course.
What does it matter that RT and CE run on the same ISA? The driver that we need is x86/x64 only.
There is basically nothing in common between CE and NT, aside from the fact that they're both portable operating systems from Microsoft and both implement some large portion of the Win32 API. Claiming that "RT is an evolution of Windows CE" is laughably wrong. They probably have less in common than Windows 95 (9x kernel, partially based on Win16 code) and Windows 8 (NT kernel, completely different project that contains no portions of DOS/Win16 except the re-implementation of the shell in NTVDM) - at least Win8 can run (many) Win95 apps. CE is at least as different from each of those as they are from eachother.
At this point, I'd guess that the most practical way to connect Zune on Windows RT would be the following:
a) Use a full x86-machine emulator (Bochs or QEMU, for example).
b) Use one that does JIT and/or dynamic recompilation, so the performance isn't abysmal (not sure what qualifies here...)
c) Install XP on it (no point targeting something newer).
d) Install Zune on the emulated XP.
e) Forward the tablet's USB port to the emulated machine's USB port (not sure if anybody has the ability to do this... currently, we can't even get networking in the emulated machine).
Good luck with that! I actually mean that quite seriously, I have a WP7 device myself and it annoys me that my Surface and it can't communicate except over Bluetooth (and I had to hack the phone to get that much).
GoodDayToDie said:
...
"tweak/re-write" an x86 kernel-mode driver into an ARM kernel mode driver for installation on a platform that doesn't (currently) permit unsigned drivers at all?QUOTE]
LOL - Thanks for the informative reply Luckily I have no delusions of grandeur over the fact that I am A) not a Developer and B) can't code past "hello world"
I was coming from the angle of the old registry hack for WP7 which allowed your phone to work as a USB mass storage file by a simple change via regedit to one of the registry strings associated to the Zune Driver....Certainly ignorant of the finer (and even the coarser) detail of your reply...so thanks for the explanation.
I added a MS Answers post asking why Microsoft cannot provide USB device connection for legacy WP7 and ZuneHD units with Windows RT. Be interesting to see what they or their MVP's reply to this, if at all.
Cheers.
Click to expand...
Click to collapse
Yeah.. asking MS to support the devices is definitely the best approach. We might manage to make a user-mode connection to them using some third-party software talking directly to the USB port on sufficiently hacked RT devices, but that's about the best we'll get.
Also, I really with people would stop calling it a "USB Mass Storage" hack. I've posted to that effect in the relevant forums that I can find, too. This is not now, never was, and (short of custom ROMs or special bootloader modes) never will be a UMS interface to Zune-like devices. The device literally doesn't support it. Please don't confuse Media Transfer Protocol for USB Mass Storage. They are *not* the same. For example, those nicely named music files you see when using the "UMS" hack for WP7/Zune? *THEY DO NOT EXIST* anywhere on the device's filesystem. True, there are files containing the same binary data, but they have names like "2D.mp3" and are stored in a filesystem structure designed to make referencing them in a database faster. MTP exposes a hierarchical storage system (which may, coincidentally, mirror the filesystem although it does not do so on Zune-like devices), but it does *NOT* expose the filesystem/storage (which is what UMS does).
Related
Any chance of someone or a group of great developers putting together android in a format like ubuntu that can be loaded onto the device in question through USB. Ok hear me out all that ubuntu does when installing is configure itself from a compiled database of your hardware specifications. So there are only so many devices out and only so many drivers to run those devices hardware, could we feasibly compile all of them and put them in with an android installation thatr ran from the host computer and installed itself according to what the computer told the installer to do if the computer reads that you have a specific chipset with a 1ghz processor it loads in the files and commands for that and so forth, just an idea, its gotta be possible right? its just an miniature OS............
i just want to know that why android operating system does not work directly in mobile devices
why there is need of development in it to use in all diffrent phones?
why it cant work directly like windows in pc does
and other question all others like bada os, symbien and apple os they all need they also need development or we can use them directly
if sumone didnt understand my question i will explain more
for further explanation>
windows we can install directly in any pc of any company or assembled
but android need development and designed for a seprate product of a specific brand
why?
no1 is intrestd in answring these questions ?
You are just kidding here right?
/Pun intended.
For example
[1] ....
[n] Windows has the complete set of drivers
[n+1] The manufacturer delivers the driver
Fundamentally, you're misunderstanding the situation. Windows does not run on any computer you can throw together. It runs on any computer that you can throw together that matches the evolving, de facto standard that started as the IBM PC.
It won't run on a SPARC Station or a 68k Mac or an IBM 360 or a Wii or a PS3 or, well, a HTC Vision.
Similarly, Android will run on any PC, er phone, er tablet, er, well computer that is basically the same as an existing Android device. The vast majority of the custom development that is, strictly-speaking, necessary for a new device amounts to device drivers. Now, most manufacturers do a lot on top of that to distinguish their product. That's where Sense and MotoBlur and such-like come into play.
A further complication is that storage space and memory are at a heavy premium on these devices. So, it is infeasible to include the incredible variety of drivers and other hardware support that makes a typical Windows or Linux install need several GBs.
Back in the day, when dinosaurs roamed the earth and there were only a handful of PC makers in the world, similar customization was needed. My first PC came with a manufacturer-custom version of DOS 2.1 and Windows 1.1. Is wasn't until at least DOS 3.x (maybe 4.x, that was a long time ago) that a vanilla MS copy had a chance of working. Even then, most peripherals *needed* a custom driver to be used at all. My first mouse is an example. Only way to use it was the Genius Mouse drivers that came with it.
thanks for ur answers guys
There's already a great thread where people are reporting what USB/Bluetooth items will and won't work on the Surface RT.
According to Pluggable, a manufacturer of USB peripherals, the problem lies much deeper: Windows RT doesn't support any USB device requiring a driver, and support may never come. It says:
"Windows RT does not have a Device Driver Development Kit and does not support or allow the installation of drivers. There is currently no Windows Update for Windows RT from which to match and download newly approved drivers for new device types from 3rd parties."
In short, the only devices which will work are devices which have traditionally had in-box support in Windows and never require a 3rd party driver to be installed: USB hubs, USB Mass Storage (USB hard drives and flash drives), USB Audio (headsets and mics), some USB printers, most USB video (webcams), USB HID (keyboards and mice), and a few other special cases.
I knew RT drivers would be a problem; this article implies that the drivers may never be coming at all.
AndyRathbone said:
There's already a great thread where people are reporting what USB/Bluetooth items will and won't work on the Surface RT.
According to Pluggable, a manufacturer of USB peripherals, the problem lies much deeper: Windows RT doesn't support any USB device requiring a driver, and support may never come. It says:
"Windows RT does not have a Device Driver Development Kit and does not support or allow the installation of drivers. There is currently no Windows Update for Windows RT from which to match and download newly approved drivers for new device types from 3rd parties."
In short, the only devices which will work are devices which have traditionally had in-box support in Windows and never require a 3rd party driver to be installed: USB hubs, USB Mass Storage (USB hard drives and flash drives), USB Audio (headsets and mics), some USB printers, most USB video (webcams), USB HID (keyboards and mice), and a few other special cases.
I knew RT drivers would be a problem; this article implies that the drivers may never be coming at all.
Click to expand...
Click to collapse
i think they just have to submit drivers to microsoft to have them work, my canon 5d mk 3 worked out of the box and i've had to install drivers for all my dslr's in windows before
When you plug in an unsupported device, does it at least attempt to search windows update for a driver? Or are all supported drivers included in the device?
Sent from my Galaxy Nexus using Tapatalk 2
Skitals said:
When you plug in an unsupported device, does it at least attempt to search windows update for a driver? Or are all supported drivers included in the device?
Click to expand...
Click to collapse
That's a good question. To control things, I turned on Airplane Mode. Then I plugged in an Easy Transfer Cable.
Surface RT recognized the cable, and USB Transfer Device appeared in Device Manager, but with the yellow exclamation point.
I turned off Airplane Mode, opened the Device Manager's Properties window for the USB Transfer Device, and told it to search automatically for updated driver software.
After visiting Windows Update, it gave me this message: "Windows was unable to find driver software for your device. If you know the manufacturer of your device, you can visit its website and check the support section for driver software."
I'm thinking Windows RT only accepts USB items that the OS natively recognizes: cameras, external storage devices, mice/keyboards, and a few other things. It won't accept anything requiring a third-party driver because Microsoft doesn't want to introduce that as a possible security hole.
I would be surprised if MS would not provide a driver development kit.
WinRT is basically a recompiled version of Win8 for the ARM. So in theory I would be able to take my C/C++ coded driver and run it through an ARM compiler to produce the correct dll.
Just made a quick look around, and I see the essential dll's required to implement a proper windows system driver. So it should work...
draftQ said:
I would be surprised if MS would not provide a driver development kit.
WinRT is basically a recompiled version of Win8 for the ARM. So in theory I would be able to take my C/C++ coded driver and run it through an ARM compiler to produce the correct dll.
Just made a quick look around, and I see the essential dll's required to implement a proper windows system driver. So it should work...
Click to expand...
Click to collapse
Just like you should be able to take your C/C++ desktop app and run it through the ARM compiler and it should work (like Office RT), but it doesn't. MS has it locked down tight. They are going the completely closed ecosystem route... like Apple (iOS).
Its a shame, because it otherwise has the potential of full blown windows 8. No reason we shouldn't have recompiled ARM versions of VLC and other open source desktop apps, but MS is keeping developers in the metro sandbox.
Sent from my Galaxy Nexus using Tapatalk 2
This was incorrect
AndyRathbone said:
There's already a great thread where people are reporting what USB/Bluetooth items will and won't work on the Surface RT.
According to Pluggable, a manufacturer of USB peripherals, the problem lies much deeper: Windows RT doesn't support any USB device requiring a driver, and support may never come. It says:
"Windows RT does not have a Device Driver Development Kit and does not support or allow the installation of drivers. There is currently no Windows Update for Windows RT from which to match and download newly approved drivers for new device types from 3rd parties."
In short, the only devices which will work are devices which have traditionally had in-box support in Windows and never require a 3rd party driver to be installed: USB hubs, USB Mass Storage (USB hard drives and flash drives), USB Audio (headsets and mics), some USB printers, most USB video (webcams), USB HID (keyboards and mice), and a few other special cases.
I knew RT drivers would be a problem; this article implies that the drivers may never be coming at all.
Click to expand...
Click to collapse
Hi gang-
I work for Plugable, not trying to advertise, but just want to share some news.
Then information we're quoted in above turned out to be wrong.
We've updated the post referenced above,
[Update: 11/16/2012] We had previously incorrectly written that device drivers aren’t installable on Windows RT. That’s not right.
Click to expand...
Click to collapse
We've also added a follow up where we explain how to install a driver on a Windows RT device. Here's the new post.
We're very sorry about providing the misleading information, but we'll be working hard towards being open about news and developments.
I'm game to explain how we arrived at the bad findings if anyone's interested: essentially just that Windows Update hadn't found any drivers, and we'd not been able to find any drivers posted at http://catalog.update.microsoft.com, nor other important resources for development and distribution.
dharmapunk said:
Hi gang-
I work for Plugable, not trying to advertise, but just want to share some news.
Then information we're quoted in above turned out to be wrong.
We've updated the post referenced above,
We've also added a follow up where we explain how to install a driver on a Windows RT device. Here's the new post.
We're very sorry about providing the misleading information, but we'll be working hard towards being open about news and developments.
I'm game to explain how we arrived at the bad findings if anyone's interested: essentially just that Windows Update hadn't found any drivers, and we'd not been able to find any drivers posted at http://catalog.update.microsoft.com, nor other important resources for development and distribution.
Click to expand...
Click to collapse
Any ETA (possibility?) of RT drivers for your USB video adapters? Oh, and just bought that Ethernet adapter, thanks for letting us know!
Actually, it does work. You just have to sign the apps with the Microsoft code integrity key. This may give the impression that you can't do it at all, but that's not actually true.
Obviously, this isn't possible for a third-party developer to apply such a signature directly, and MS is generally not fond of signing third-party code. It happens on occasion, though. Consider the Flash Player in IE10 for RT; that's Adobe code, but it's signed with the MS key. Downloading suitably signed EXEs and running them works just fine; for example, the remote debugging server for Windows RT is distributed by MS exactly like any other downloadable EXE, and it works.
In fact, if you somehow manage to put your device in Testsigning mode (which exists in RT and also in x86 versions of Windows, and allows using any trusted signature instead of only the MS signature), you can install your own signing certificate and then run your own compiled and signed desktop apps. Unfortunately, testsigning mode is a bootloader option, and the bootloader for all currently released Windows RT devices prohibits its use (although development devices were found to support it).
@dharmapunk: Any chance this driver is going to show up in Windows Update soon? Since you've obviously already gotten the MS signature, hopefully it will be literally plug-and-play soon...
GoodDayToDie said:
@dharmapunk: Any chance this driver is going to show up in Windows Update soon? Since you've obviously already gotten the MS signature, hopefully it will be literally plug-and-play soon...
Click to expand...
Click to collapse
@GoodDayToDie Sorry, I'm not entirely sure on this- since it's an ASIX developed driver the info I have here is second hand. We anticipated this would be baked into RT's RTM, however for some unknown reason it wasn't.
Sorry I can't be more help here, I'm still looking for ANY WinRT drivers over on catalog.update.microsoft.com.
---------- Post added at 06:05 AM ---------- Previous post was at 06:00 AM ----------
addictivepixels said:
Any ETA (possibility?) of RT drivers for your USB video adapters? Oh, and just bought that Ethernet adapter, thanks for letting us know!
Click to expand...
Click to collapse
Sorry @addictivepixels, I've not heard any news that DisplayLink is close to releasing, or even working on, a WinRT usb graphics driver. I anticipate that will stay only x86/x64 for quite some time. Wish I had better news...
The saga continues...
Hi again-
The saga continues. We’ve been asked to take down the WinRT driver for our ASIX-based USB Ethernet adapter. Seems like it wasn’t supposed to have been released after all, so we’re taking the driver off our website soon- before month's end.
We’ll still be selling the adapter. We’ll still be supporting customers. We’re even keeping the installation instructions that we wrote up on our website.
I hope that this issue can be resolved soon. I want more devices to plug into Surface too!
Since I'm a noob I can't post a link to our new post, however the one the OP listed now has an update notice with a link to further details.
dharmapunk said:
Hi again-
The saga continues. We’ve been asked to take down the WinRT driver for our ASIX-based USB Ethernet adapter. Seems like it wasn’t supposed to have been released after all, so we’re taking the driver off our website soon- before month's end.
We’ll still be selling the adapter. We’ll still be supporting customers. We’re even keeping the installation instructions that we wrote up on our website.
I hope that this issue can be resolved soon. I want more devices to plug into Surface too!
Since I'm a noob I can't post a link to our new post, however the one the OP listed now has an update notice with a link to further details.
Click to expand...
Click to collapse
Is there any chance that we could get the source to said driver? I'd like to poke around it to see if it has any vulnerabilities that'd allow a kernel-mode exploit.
I understand if you can't/don't want to post it.
netham45 said:
Is there any chance that we could get the source to said driver? I'd like to poke around it to see if it has any vulnerabilities that'd allow a kernel-mode exploit.
I understand if you can't/don't want to post it.
Click to expand...
Click to collapse
@netham Other than the driver package in the link in the original post, we haven nothing else to offer. Since I knew our blog post with the driver download was quoted in the original post in this thread, we wanted to warn any customers who might have purchased our USB2-E100 that the driver will be going away soon due to a takedown request.
To be clear, our concern is making certain any customers who purchased the USB2-E100 for use on Windows RT have a chance to download the driver before we take it down.
I'd post the link to our new blog post with details if I could, trying again: http://plugable.com/2012/12/11/windows-rt-surface-usb-ethernet-takedown
The RT driver situation has been odd to say the least - still trying to figure it all out. I've been able to yank some drivers out of my Windows 8 Pro box and manually install them onto the Surface. Outcomes:
I was able to get my Smart Card Reader half functional this way, although there is no current affordance for installing the necessary minidriver that allows the .NET card to fully interoperate with the Surface.
I had the same minidriver issue with my DisplayLink UV+.
I was also able to get my Lumia 900 to mount , but can't get the file system to read past the top level.
More research required...
That is... *very* interesting. Those must be .NET user-mode drivers, because the Surface RT uses the ARM instruction set and is completely incapable of running the typical written-in-C/C++-and-compiled-for-x86/x64 drivers used on "normal" Windows.
Alternatively, the driver may contain a firmware blob that is loaded into the microcontroller of the hardware even though the actual Windows driver code (which would be x86) wouldn't work. The firmware blob won't be x86, it'll be whatever instruction set the device's microcontroller executes.
Don't ever buy Windows RT again, it's a dead end operating system.
well, at a very low price,it's a good device. Kids like them for games and music. Youtube etc . play well on it . Not totally useless but I would of never paid the full price for it.
Hi,
is there a displayLink Software for the RT?? I have an Dockingstation with an extern SCreen and i really would like to use it, but this will only work with DisplayLink Software. So is there a solution for the RT??
Thanks a lot
HandyBesitzer said:
Hi,
is there a displayLink Software for the RT?? I have an Dockingstation with an extern SCreen and i really would like to use it, but this will only work with DisplayLink Software. So is there a solution for the RT??
Thanks a lot
Click to expand...
Click to collapse
Nope- no DDK for WinRT, so no one can make third-party hardware that doesn't fit the preloaded driver set:
http://www.displaylink.com/support/ticket.php?id=335
Well, no public DDK. There's (quite obviously) an internal one, and it has apparently been shared with certain partners, and a copy of it has leaked onto the Internet and been found (and occasionally used) in various places. That said, even if a commercial outfit were willing to entertain the use of such a thing, they would need to get the resulting driver signed by Microsoft for it to be installable on non-"jailbroken" RT devices.
this signing thing is really terrible. is there a chace to get such a driver in future??
GoodDayToDie said:
Well, no public DDK. There's (quite obviously) an internal one, and it has apparently been shared with certain partners, and a copy of it has leaked onto the Internet and been found (and occasionally used) in various places. That said, even if a commercial outfit were willing to entertain the use of such a thing, they would need to get the resulting driver signed by Microsoft for it to be installable on non-"jailbroken" RT devices.
Click to expand...
Click to collapse
Right, so effectively no DDK for general peripheral manufacturers to use unless MS decides otherwise for that device-- hence the situation with USB Ethernet adapters (and the driver that Plugable released then had to pull).
I'm a bit puzzled by the situation-- if MS' concern is that poor drivers would affect the WinRT user experience, then presumably they could enforce a testing process (as they already have w/ WHQL) and only allow driver delivery through Windows Update.
As it stands, WinRT devices, running full-blown Windows, are ironically far less useful in custom applications than iPads, which have all sorts of accessories available. Why wouldn't MS want WinRT to be usable in, say, medical settings? (even iPhones, let alone iPads, can connect to hardware accessories like medical sensors).
Android's also catching up quickly in the accessories space, and it's only a matter of time before iOS/Android destroy any advantage MS had w/ hardware manufacturers, as happened so dramatically in the software space (there are now so many more devs who've worked with iOS and Android than have with modern MS platforms).
Well, for accessories that just need "traditional" data I/O - things like what you might have done over a serial port in days of yore - you can easily use either BlueTooth or the audio jack (although the latter is a real hack, usually used only for very small dongles powered by the audio signal). The iPad is definitely less extensible with third-party hardware (note, accessorizable != extensible) than RT, but I fully agree with you that Microsoft's stance on RT drivers is just plain weird. Keep the pool smallish and/or WHQL-test the crap out of them, but make them available! Those USB ports can and should be a killer feature.
The audio channels available on many consumer devices are often perfect for bit banging various communications protocols. UART "emulation" has often been done on the headset jack with a level shifter and some trickery, often on android devices much less powerful than the surface RT (seen a demo on an 800MHz single core ARMv6 handset). If your willing to sacrifice audio output from your application on the RT (as it is being used for bit banging the UART) then you essentially have a plug and play serial port without any special drivers needed, your application just needs to be able to generate an audio signal and analyse an input. the peripheral will need an external power supply but this is common on many legacy RS232 applications too.
There is the bluetooth serial port profile. Thats often used as a replacement for RS232 or UART. I dont know if windows RT supports it though (someone would have to check).
Another trick I have seen involves a microcontroller with USB capabilities. I have seen examples of people setting a microcontroller to appear as USB mass storage and having a small file system with 1 plain text file. Writing into this text file from windows or linux etc would then cause the microcontroller to perform a particular operation in response. Sensors can also be read by the microcontroller causing it to update the text file too. You essentially have file based GPIO without.
Its all rather hacky but it works technically.
There is also an i2c bus on the RT keyboard connector.
Boot from SD card
This is a placeholder for some work I was doing on booting and alternate copy of Windows RT from SD card
by adding extra entries in the bcd store and a ‘copy’ of windows on the SD card
(or a reinstalled version of Windows RT installed onto the SD card)
Note it actually still boots from the system partition on the internal flash but tries to boot an alternate Windows installation from \windows on the SD card
However having problems getting it to find the SD card volume at boot time
Still working on that
and on how to use the recovery environment to install the OS onto SD card
Best to have a Class 10 SD card
But now moved on to dual booting Windows RT and RT 8.1 (both from internal flash)
http://forum.xda-developers.com/showthread.php?p=43062190#post43062190
Also working on booting a full OS from USB stick
That'd be quite cool. It'd also be an important part of a Linux or Android port to Surface RT. You could make an extremely-stripped-down Windows RT installation that boots just enough to run some exploit automatically. The exploit could load a kernel driver to do the equivalent of kexec() into Linux.
Such an installation on a USB stick could be a bootable Linux live "CD" as well.
Myriachan said:
That'd be quite cool. It'd also be an important part of a Linux or Android port to Surface RT. You could make an extremely-stripped-down Windows RT installation that boots just enough to run some exploit automatically. The exploit could load a kernel driver to do the equivalent of kexec() into Linux.
Such an installation on a USB stick could be a bootable Linux live "CD" as well.
Click to expand...
Click to collapse
Someone just needs to actually come up with that exploit first. I'd totally convert my surface to a Linux device if it was available ... Windows is nice and all, but I love that warm, fuzzy feeling of having full control of hardware I own. I got CyanogenMod on just about every Android device I have, and getting out of the restricted RT arena would be awesome.
southbird said:
Someone just needs to actually come up with that exploit first. I'd totally convert my surface to a Linux device if it was available ... Windows is nice and all, but I love that warm, fuzzy feeling of having full control of hardware I own. I got CyanogenMod on just about every Android device I have, and getting out of the restricted RT arena would be awesome.
Click to expand...
Click to collapse
The general idea behind netham45's exploit (which originates with a Google guy) would actually work for this. If you control the entire boot image, you can make cmd.exe start a script and cdb very early. There exists a modification to the technique to do the exploit without the two-minute instability problem.
If Microsoft doesn't lock out the 8.0 bootarm.efi, this would keep working after 8.1's release--just boot 8.0 to do this part.
The difficult part of this entire thing to me is how the hell to write Linux drivers for hardware we know nothing about.
Myriachan said:
The general idea behind netham45's exploit (which originates with a Google guy) would actually work for this. If you control the entire boot image, you can make cmd.exe start a script and cdb very early. There exists a modification to the technique to do the exploit without the two-minute instability problem.
If Microsoft doesn't lock out the 8.0 bootarm.efi, this would keep working after 8.1's release--just boot 8.0 to do this part.
The difficult part of this entire thing to me is how the hell to write Linux drivers for hardware we know nothing about.
Click to expand...
Click to collapse
Linux for tegra might be a start, think that is now upto tegra 3 specs. But there are still several unknowns like you say. Some disassembly might clear up a few more unknowns (is the screen DSI or LDVS, which interface is used for the storage as there is more than one which would be capable for eMMc usage).
We do know that all the sensors are i2c devices at least.
But yeah, there is alot of work for a community to do in order to port linux to the surface. Not unless microsoft release a few datasheets which they have no reason to. Making matters worse, not all RT devices would be the same so the surface RT would need a different port than dells qualcomm based tablet. Even the tegra based tablets might need a different BSP to each other.
I do think though that if there was linux on the surface RT then I would probably consider getting one. Would at least double the chances at any rate.
SixSixSevenSeven said:
Linux for tegra might be a start, think that is now upto tegra 3 specs. But there are still several unknowns like you say. Some disassembly might clear up a few more unknowns (is the screen DSI or LDVS, which interface is used for the storage as there is more than one which would be capable for eMMc usage).
We do know that all the sensors are i2c devices at least.
But yeah, there is alot of work for a community to do in order to port linux to the surface. Not unless microsoft release a few datasheets which they have no reason to. Making matters worse, not all RT devices would be the same so the surface RT would need a different port than dells qualcomm based tablet. Even the tegra based tablets might need a different BSP to each other.
I do think though that if there was linux on the surface RT then I would probably consider getting one. Would at least double the chances at any rate.
Click to expand...
Click to collapse
I'd imagine focusing on one at a time would keep you from getting overwhelmed, and I would think the stock Microsoft Surface RT is the one that makes the most sense to start with, at least get a proof of concept working. As far as "hardware we know nothing about", the Tegra itself is pretty well documented and I imagine it operates essentially the same as it does anywhere else.
I would imagine stages to doing this:
1) Figure out the exact sequence to stop Windows and disengage the kernel, watchdogs, or whatever else in a stable way to start executing arbitrary code in RAM, with some kind of POC demo, e.g. getting data out over I2C or something, which we ultimately will need to debug a kernel.
2) Once this has been accomplished, start playing with ARM-based Linux bootloaders, with console output happening over I2C or whatever else works. This can allow for just trying to get the kernel to run, even if at first this renders a completely non-interactive device.
3) If you get this far, obviously now it's all about getting the magic mix of drivers...
With an actual kernel running, most likely a lot of hardware would become more easily identifiable, and we could at least figure out where we stand. Of all these things, I imagine #1 is the most difficult to overcome, but there's been some suggestions.
southbird said:
2) Once this has been accomplished, start playing with ARM-based Linux bootloaders, with console output happening over I2C or whatever else works. This can allow for just trying to get the kernel to run, even if at first this renders a completely non-interactive device..
Click to expand...
Click to collapse
I dont think anyone knows the exact pinout but there is i2c on the connector for the touch/type covers, they are themselves i2c devices. If someone knew the pinout, theres your access. Stick some magnets on some card with a few pieces of wire sticking out of it, should be able to hold against the connector. But that doesnt matter so much.
I've heard of linux consoles being accessed over UART (infact I have done this with a raspberry pi) but not i2c. The tegra does have at least 1 UART though (I have a feeling it might have 3 or 4). Whehter you would have to tear a surface apart to get at it though is another matter. I know that several devices actually make the uart externally accessibly via either the USB or audio jacks with a quick pinmux. A nexus 4 for example you stick a certain resistor between the mic and ground channels on its audio jack and I think the left audio channel becomes Tx and right Rx or vice versa. A few android tablets (I think HTC are big on this) use the microUSB, certain resistor value between the sensor and ground lines as is often used for enabling USB host triggers D+ and D- to become Tx and Rx instead. No microUSB on the surface though. My guess if they ran one externally it would either be on the cover connector (there are 5 connected contacts yet only worked out a purpose for 4 of them, then there is 1 pin not connected to anything for some reason, probably future expansion, perhaps this 5th pin enables a UART instead of i2c???) or the audio jack, there might well not be one accessible externally at all :/
I would assume the surface screen is either LDVS or DSI, the prior is more likely to be documented than the latter (DSI isnt even fully standardised, in theory it is but in practise DSI devices are rarely compatible even with the same res, colour depth etc). May well be possible to output direct to that initially.
With the keyboard being i2c it may well be possible to write a driver to use it on linux on an existing device, not sure how well USB-i2c adaptors work but the pi has 2 native i2c buses.
I do agree that the surface is the logical starting point. Its probably sold the most units at any rate and is the first thing people think of when you say windows RT. Other tegra devices would be the most logical to follow on with, qualcomm would perhaps be able to reuse step 1 but step 2 you would likely have to start from scratch all over :/
Oh well, 1 hurdle at a time. Honestly though, the existance of a functioning linux port for the surface would make me tempted to buy one. That or microsoft unlocking RT to literally be windows 8 on ARM not windows 8 stuck in a cage.
southbird said:
1) Figure out the exact sequence to stop Windows and disengage the kernel, watchdogs, or whatever else in a stable way to start executing arbitrary code in RAM, with some kind of POC demo, e.g. getting data out over I2C or something, which we ultimately will need to debug a kernel.
Click to expand...
Click to collapse
There is already a method of running any unsigned EFI file (for example a GRUB loader). But it works only on Asus tablets and requires USB stick inserted on boot and Bitlocker turned off in Windows (as the "trusted boot environment" is broken). I'll publish it later - probably after 8.1 official release, as it can be easily closed by Asus in a next firmware update that may be required for 8.1.