Database Info

Digital & Analogue DAQ

Please, does anyone have any advice?
I’ve just bought a T-Mobile VERIO (aka K-JAM, HTC Wizard etc), and I’ve also bought a PPC-compatible visual basic (NSBASIC/CE – it’s brilliant!).
I very much want to access the “outside world” for the purpose of data acquisition (instrumentation and control).
On a desktop PC, this is easy; there are a whole range of software and hardware products (many are free-ware) which provide access under VB to parallel and serial ports. From there on it’s relatively easy to knock together some suitable circuitry to provide digital and analogue I/O.
My new PPC has only a mini-USB and a SD socket (plus of course the Bluetooth and WIFI). There are no serial or parallel ports, like there are on the desktop PC.
So PLEASE, how do I do it? How do I access (or synthesise) a suitable port for general purpose DAQ?
I can’t believe I’m the only geek with an interest in this. Come on guys; where are you all???

[Q] How Android Works - OS and Versions

I know this is an incredibly newbish question, but I'd flipped through various forums and articles and googled it and still don't quite seem to understand it.
My question is why is android dependent upon manufacturer's release?
Take for example, a desktop computer.
OS
This is the core of the device and the UI between the user and the hardware.
Applications talk to the OS to instruct the hardware to do stuff.
Microsoft and Apple makes the OS.
ex. Windows 7, Mac OS, Linux.
Hardware
Asus, Nvidia, Realtek, marvell make the hardware.
ex. video, LAN, sound etc.
Hardware Bundler
Dell, Alienware, Gateway, Acer
They take commercial hardware and some OEM hardware and assemble it in a way that many consumers will buy their bundle.
For 99.9% of us, not counting Synapse, this is the only way the hardware is packaged together.
Device Standards
Collectively, the manufactures work together to determine certain industry standards ex. ATX, PCI-E, SATA 3, USB 3.0 etc...
Drivers
The manufacturers also make drivers so the OS can make use of their hardware.
Compatibility Is Determined by Driver Support
If the driver exists to talk to a given OS, then the hardware will work.
Not all hardware manufacturers will code for every OS out there.
ex. USB works on all OS because it's more established, but not every sound card will work on a Linux system.
Bringing it home...
So if Microsoft releases Windows 8, and as long as Nvidia releases a driver that works with that OS, then the video card will work.
Can you help me understand how the android phone architecture is so different that it's no longer
OS <-> Driver <-> Hardware?
Sorry for not getting it.

Culverin said:
Can you help me understand how the android phone architecture is so different that it's no longer
OS <-> Driver <-> Hardware?
Click to expand...
Click to collapse
It isn't different, it's exactly as you written. But manufacturers usually don't release sources of drivers, neither binaries for newer versions of OS. Also many manufacturers add protection against installing your own software into "their" device.
Android is open, but many manufacturers of Android devices - aren't.

Many devices just like????

You say manufacturers, are you referring to components such as the modem (???), video encoding/decoding chip (tegra), sound chip (wolfson)? NFC chip?
Aren't these drivers publicly available?
How else would small companies be able to develop low volume items such as these?
http://www.bigboxstore.com/computers/android-tablet-pcs
http://cheapandroidtablet.org/
When a company, samsung for example, makes a phone.
They start tying all the components together and making them talk to each other.
How "custom" are the "motherboard bios"?
Is that what you are saying by the manufacturers add protection?
Like at the "bios" level?
As for things like this...
http://www.engadget.com/2011/01/27/sony-announces-playstation-suite/
Does that mean Sony is banking on Google making it more standardized?

Culverin said:
You say manufacturers, are you referring to components such as the modem (???), video encoding/decoding chip (tegra), sound chip (wolfson)? NFC chip?
Click to expand...
Click to collapse
I mean both components manufacturers and phone manufacturers.
Usually there are problems with Wifi, GPS, GPU support, camera, etc. Many alpha-stage ports have problems with these things.
Culverin said:
Aren't these drivers publicly available?
Click to expand...
Click to collapse
Do you mean sources? Manufacturers rarely release sources of drivers, even on a PC. This is the reason, why there are problems with some devices on linux systems.
Culverin said:
How else would small companies be able to develop low volume items such as these?
Click to expand...
Click to collapse
I'm not sure, but they have to buy a license to use these components in their devices anyway, so I guess they get sources of drivers too, but they can't release them.
Culverin said:
How "custom" are the "motherboard bios"?
Is that what you are saying by the manufacturers add protection?
Like at the "bios" level?
Click to expand...
Click to collapse
"BIOS" or just "boot phase software" is usually 100% custom - there are no standard solutions I know of.
Let's imagine you have bought a new PC with some preinstalled OS. You don't have administrator rights on it, you can't boot from other device than HDD and if you want to update your system, you have to use special software, which has administrator rights, but it checks whether updates were created by device manufacturer. This is more or less how most of phones work.
Culverin said:
Does that mean Sony is banking on Google making it more standardized?
Click to expand...
Click to collapse
I'm not sure what do you mean?

Culverin said:
I know this is an incredibly newbish question, but I'd flipped through various forums and articles and googled it and still don't quite seem to understand it.
My question is why is android dependent upon manufacturer's release?
Click to expand...
Click to collapse
Because individual makers add their own hardware.
Can you help me understand how the android phone architecture is so different that it's no longer
OS <-> Driver <-> Hardware?
Sorry for not getting it.
Click to expand...
Click to collapse
It still is. Android OS is JUST THE BIOS, in your example. The VXDs/drivers are made by different manufacturers (hardware level drivers) and loaded at system time.
You can load a plain Android OS, but it won't be able to talk to the phone's hardware except in a very general sense. You can touch screen, launch apps, but no phone, and only generic camera without special resolution support and such. It won't be able to do data or phone at all. That requires special VXDs (or their linux equivalent, I'm a Windows guy). Not all phones have the same buttons, or the same screen rez, or the same keyboard, and so on.
That's why there are various experimental Gingerbread ROMs out there already, but they don't work that well, because nobody had debugged the "drivers" for the hardware yet.
And if nobody release the source of the drivers (even for the earlier versions) nobody can use that to figure out if they are compatible with the next OS rev. Binary hacking is way too difficult.

Zune Driver for ARM to allow USB phone connection

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).

Dual Boot Tegra 3 Vivo Tab

I haven't seen many definitive answers on this. Since the Vivo Tab RT runs a Tegra 3 processor, would it be possible to boot some sort of android onto this tablet?

amccue said:
I haven't seen many definitive answers on this. Since the Vivo Tab RT runs a Tegra 3 processor, would it be possible to boot some sort of android onto this tablet?
Click to expand...
Click to collapse
At this stage no. The Vivotab does not run an android bootloader, it runs a UEFI system, and the UEFI bootloader is locked down to only run stuff signed by microsoft

lilstevie said:
At this stage no. The Vivotab does not run an android bootloader, it runs a UEFI system, and the UEFI bootloader is locked down to only run stuff signed by microsoft
Click to expand...
Click to collapse
Any prospects for the future? or is it too unpopular with the devs?

Bypassing the "secure boot" feature that MS uses to lock out other OSes would be a major breakthrough, far above and beyond the typical effort required to support a new device with Android. This isn't a case of "oh, it's hard to port to UEFI", it's a case of "MS has deliberately used a UEFI feature to block support for other operating systems."

The best chance is something along the lines of kexec or haret to boot into Linux once code signing has been defeated by the jailbreak. I don't know if kexec was ever ported to smp arm, but it would definitely need to be rewritten to run on Windows.

In theory yes the vivotab could run android. The hardware powering a windows RT device is no different from any other android tablet.
In practise no. As said above UEFI is in the way. When a workaround for that is found then you may be able to run android but it might be a long long time until someone does find that workaround.

SixSixSevenSeven said:
In theory yes the vivotab could run android. The hardware powering a windows RT device is no different from any other android tablet.
In practise no. As said above UEFI is in the way. When a workaround for that is found then you may be able to run android but it might be a long long time until someone does find that workaround.
Click to expand...
Click to collapse
After finding a way to sidestep secureboot (UEFI is not in itself an obsticle just one of its features is a hinderance) someone will still need to spend the time porting the linux kernel

lilstevie said:
After finding a way to sidestep secureboot (UEFI is not in itself an obsticle just one of its features is a hinderance) someone will still need to spend the time porting the linux kernel
Click to expand...
Click to collapse
Linux for tegra 3 devices has been around for ages.
touchscreen drivers etc might be an issue yes but the kernel itself will run quite happily on the tegra 3. Ubuntu for various pieces of tegra developer hardware exists etc. Plenty of android devices out there.
Yes its no seemless but the kernel itself doesnt need porting. Just drivers, might be complicated via the fact that the touch screen and a few other peripherals are apparently done via i2c in RT devices which is a little unusual.

SixSixSevenSeven said:
Linux for tegra 3 devices has been around for ages.
touchscreen drivers etc might be an issue yes but the kernel itself will run quite happily on the tegra 3. Ubuntu for various pieces of tegra developer hardware exists etc. Plenty of android devices out there.
Yes its no seemless but the kernel itself doesnt need porting. Just drivers, might be complicated via the fact that the touch screen and a few other peripherals are apparently done via i2c in RT devices which is a little unusual.
Click to expand...
Click to collapse
Have you dealt with Tegra kernels? yes the linux kernel exists for tegra, but it hasn't been ported to the vivotab, pinmux et al tend to change between each of the devices, a kernel that works on one tegra device is 99% not going to work on another.

lilstevie said:
Have you dealt with Tegra kernels? yes the linux kernel exists for tegra, but it hasn't been ported to the vivotab, pinmux et al tend to change between each of the devices, a kernel that works on one tegra device is 99% not going to work on another.
Click to expand...
Click to collapse
I still wouldn't think the kernel is the big problem... people can get a kernel started and nuzzle it and its drivers until it works perfectly. UEFI is the Big Problem.
What I think would be a short term solution however is to take advantage of the existing jailbreak to run another bootloader (wouldn't even have to be as complex as a "kexec" as was suggested... just abandon Windows completely...) Does the payload sent as part of the jailbreak give us low enough level access, or does that still trip the Windows kernel into panicking and blue screening?

The latest version (1.20) allows kernel-mode code to run at the highest privileges. With that being said, I have no idea how Windows will try to hold on once Linux has been given control (watchdogs, interrupt handlers, etc will all need to be cleaned out)

My understanding of the suggestion was to create an NT kernel-mode driver that basically acts as a Linux bootloader, removign the Windows code from scheduling (and eventually overwriting it in RAM) entirely. That's likely to be a very complex project, but it's a sort of a cool idea. You'd still need to have Windows around for the actual boot process (which is appropriate, the term coming from "bootstrapping") since the UEFI won't start any bootloader except Microsoft's and I doubt that it will allow specifying the GRUB stage 1 loader or similar (although it just might... really doubt it though). Instead, we'd have to boot Windows, unlock kernel-mode code, and start this pseudo-reboot-into-Linux driver.

GoodDayToDie said:
My understanding of the suggestion was to create an NT kernel-mode driver that basically acts as a Linux bootloader, removign the Windows code from scheduling (and eventually overwriting it in RAM) entirely. That's likely to be a very complex project, but it's a sort of a cool idea. You'd still need to have Windows around for the actual boot process (which is appropriate, the term coming from "bootstrapping") since the UEFI won't start any bootloader except Microsoft's and I doubt that it will allow specifying the GRUB stage 1 loader or similar (although it just might... really doubt it though). Instead, we'd have to boot Windows, unlock kernel-mode code, and start this pseudo-reboot-into-Linux driver.
Click to expand...
Click to collapse
That's precisely my suggestion.
I'd like to think that it would be easy enough to just load the Linux kernel to RAM and mark the pages as executable, along with clearing any watchdogs/CPU caches then just set PC to the address the Linux kernel is at, but the sensible part in me knows that I'm probably oversimplifying far too much.

netham45 said:
That's precisely my suggestion.
I'd like to think that it would be easy enough to just load the Linux kernel to RAM and mark the pages as executable, along with clearing any watchdogs/CPU caches then just set PC to the address the Linux kernel is at, but the sensible part in me knows that I'm probably oversimplifying far too much.
Click to expand...
Click to collapse
Another thing I'd think about is how to tell you were successful in abandoning the Windows kernel and have successfully taken control of the CPU. This sounds like you pretty much would require some way of tapping in to a serial debug port or something to be able to tell the difference between Windows being truly departed versus arbitrarily freezing up. Before even really trying to run a kernel (since it's highly unlikely it would boot and be useful on the first try), it would be important to do some basic tests to make sure we've successfully and completely taken over hardware.
So the first of such attempts should be to run some little bit of ARM assembly to "do something" and be able to verify the results... I imagine trying to include an entire slew of instructions to make the GPU do something would be a little much, so my question is, does the Surface have some kind of internal testing connection for a serial device connected, probably provided by the Tegra, that would be reasonably easy to send data out to? We probably would need this anyway since the first few kernel attempts most likely would be failures to complete the boot cycle, probably before the GPU could be initialized.

southbird said:
, does the Surface have some kind of internal testing connection for a serial device connected, probably provided by the Tegra, that would be reasonably easy to send data out to?
Click to expand...
Click to collapse
It has at least 3 that I know of. The tegra 3 has at least 2 hardware UARTs, I think it might have more (most ARM SoC's do). It also has i2c which is being used for accessing the accelerometer in all windows RT devices. The tegra 3 has an SPI too. Its just a case of can we get at any of those.
The 3rd is on the bluetooth module. Most bluetooth modules support the serial port profile which specifically emulates a UART connection. Windows 7 and 8 (maybe RT, I dont know) even have built in functionality in the control panel to assign a bluetooth adaptor (either internal or USB) a COM number and it can then be addressed as a serial port provided it is paired with another device also supporting SPP. I think SPP is one of the most basic profiles and supported by just about all bluetooth radios. The ones in the surface should be capable of supporting it, its just whether windows RT provides access to it or not. With the kernel mode interface it might be possible to start interfacing with it again.

SixSixSevenSeven said:
It has at least 3 that I know of. The tegra 3 has at least 2 hardware UARTs, I think it might have more (most ARM SoC's do). It also has i2c which is being used for accessing the accelerometer in all windows RT devices. The tegra 3 has an SPI too. Its just a case of can we get at any of those.
The 3rd is on the bluetooth module. Most bluetooth modules support the serial port profile which specifically emulates a UART connection. Windows 7 and 8 (maybe RT, I dont know) even have built in functionality in the control panel to assign a bluetooth adaptor (either internal or USB) a COM number and it can then be addressed as a serial port provided it is paired with another device also supporting SPP. I think SPP is one of the most basic profiles and supported by just about all bluetooth radios. The ones in the surface should be capable of supporting it, its just whether windows RT provides access to it or not. With the kernel mode interface it might be possible to start interfacing with it again.
Click to expand...
Click to collapse
That's fine and dandy if Windows can support the serial mode of Bluetooth, but I'm talking about verifying success of having kicked Windows out... so we won't have that facility when we get that far. The hardware UART is really the direction that you would want to go, some low-level thing that can be easily accessed by assembler to show life initially and in the long term some kernel output from Linux.

I'd be interested in seeing what the pins on the keyboard dock can do. Does anyone know of a documented pinout for those?

netham45 said:
Is the bus that the keyboard attaches to input/output, or just input? I believe it's an I2C bus, but I'm not 100% on that.
Click to expand...
Click to collapse
Your not the only one interested in that
My guess judging by the fact it has 6 contacts is that it is not simply 1 bus.
It is already in microsofts documentation that accelerometers, gyroscopes etc will all connect to new windows 8 tablet devices via i2c. We know that the keyboard contains an accelerometer to detect whether it should be classed as in use or not. i2c requires 2 wires. That leaves us with 4 contacts left.
Both the keyboard and accelerometer also need power. Common voltages for an accelerometer are 3.3V and 5V. My guess is that the keyboard would be happier at 5V, then MS could also source that 5V power from the USB driver circuitry. They could have either regulated that 5V down to 3.3V or used a native 5V accelerometer. Either way there must be a ground and either %v or 3.3V supply. So thats 2 more pins down.
Leaves us with 2 unaccounted for and both the mouse and keyboard also unaccounted for. The mouse simply needs to return a few X and Y co-ordinates. I think the i2c bus for the accelerometer has plenty of bandwidth open for that purpose so thats the mouse down. From what I have read, the touch cover keyboard doesnt have the normal n-key rollover issue of standard USB keyboards and can return a huge number of simultaneous keypresses. Now, I dont think the i2c has enough bandwidth to deal with both mouse, accelerometer and a huge list of active keys so from that I deduce that the keyboard has its own bus. However we only have 2 wires left for it.
My first assumption would be that it was a PS/2 keyboard as many laptop keyboards at some point between going from a key matrix to the CPU are actually PS/2 devices and the PS/2 protocol is conductive to no n-key rollover. At first I dismissed this as we dont have enough pins, there are 6 on the surface and 6 on a PS/2 connector. But I decided to lookup the pinout anyway.
data
not connected
ground
+5 V DC at 275 mA
clock
not connected
So from that in a 6 pin PS/2 connector there are actually only 4 pins in use (some systems then had a second clock and second data on the 2 unused pins so that you could connect 2 keyboards or a keyboard and a mouse via a splitter cable). Of these 4 in use pins we have a +5V and a ground. Well we already have a ground and I already deduced there to be either 5V or 3.3V supplies. This reinforces that there may be a 5V supply. This then cuts 2 of them out of the equation leaving us with 2 connectors left over on the surface and 2 connectors left over for a PS/2 device.
So my guess is that the surface has the following pins (not necessarily in order):
+5V
GND
SDA
SCL
PS/2 Clock
PS/2 Data
It is also plausible that the keyboard could be a USB device. Again, this would only need 2 connectors. UART and i2c I wouldnt say are likely but are plausible options too but I maintain that the keyboard probably has its own i2c bus. It could be entirely proprietary.
that said. If the keyboard and mouse shared a bus that would explain 1 thing. Currently whenever you are typing on the keyboard you cannot move the mouse. It may well be then that the 2 wires I have assigned for PS/2 could be another i2c and that there is not enough bandwidth to register both keyboard and mouse down it so they just transmit keyboard data. Or it could be a modified PS/2 that allows the mouse and keyboard to be accessed via the same connector.
I am dead certain that my first 4 pins are correct (although not in the correct order). If there is indeed an i2c or 2 then that opens up some interesting options. Hell, it would be cool to see someone interface other keyboards to the surface via that bottom connector, or the touch cover to other computers (its a pretty portable keyboard after all).
Without actual hardware and some sort of datalogging multimeter I cant test my theories but I think they are sound.
southbird. I was more on about accessing the bluetooth radio directly rather than via windows. It is an accessible UART without any hardware hacking.

SixSixSevenSeven said:
It has at least 3 that I know of. The tegra 3 has at least 2 hardware UARTs, I think it might have more (most ARM SoC's do). It also has i2c which is being used for accessing the accelerometer in all windows RT devices.
Click to expand...
Click to collapse
Tegra 3 has 4 UART connections labeled A, B, C, and D. This is pretty standard of ARM cores. I2C is not that out of the ordinary either, usually most devices communicate using it. Up until recently ARM SoCs have not supported transports normally used in x86 pc's (PCI et al) and as such they are still not used, most touchscreens communicate over I2C, as well as various sensors (Gyro, ALS, Accelerometer, etc).
Honestly I think the biggest thing to watch out for is the UEFI subsystem interaction, UEFI isn't dropped away once a kernel loads, it remains running at all times, and usually has some level of involvement in communication between kernel space and raw hardware. When flushing out the windows kernel one will have to make sure that they are not tickling uefi into restarting the system, or that there isn't a watchdog running between the kernel and the efi framework.

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Seems that it's an I2C bus.

Boot from SD card

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.