Posted by noreply@blogger.com (Zibri) on under mobileme, firmwares, google, background processes, different path, android, big brother, orwell, big picture | 
I'm worried.What can seem a nice feature is somethingreally dangerous.Not allowing background processesand forcing everything to pass thru theApple Push Notification Serveris something Orwell already imagined.Think about all your dataflowing through Apple and you will startto get the big picture.Add to that mobileme, another big brotherkeeping everything about you.Now, this would be nice if it were an optionalfeature. But it's not.It's the only way.With the iPhone, Apple is showing theywant to keep control of everything.I hope the industry will take a differentpath and won't emulate them.Every day I'm getting more interestedin google android and more open softwares/firmwares.
Tagi: mobileme, firmwares, google, background processes, different path, android, big brother, orwell, big picture
Posted by planetbeing on under clock timer, iphe, day clock, versis, linux kernel, cpu x86, boot menu, linux drivers, mmu, android, opti, whirl, wi fi, graft, spi, knowledge gained from, many things, timers, vic, clocks |
I've been getting a lot of questions from people that seem to reflect a basic misunderstanding of what it takes to port an operating system onto a new platform. People seem to think that just by writing, say, a boot menu, means that we can stick Android or Windows or whatever onto a device because we can have a menu option for it.
Here's what it takes for an
operating system to run on a device:
- The code must be designed for the right CPU. (x86, ARM, PPC)
- The code must be able to interact with the hardware in the way it expects.
Now, there are versions of Linux compiled in ARM (which the iPhone uses), there are even versions of Windows Mobile that are compiled in ARM. Why can't I, then, just stick Windows Mobile or Android (or another flavor of Linux) onto the iPhone and give it a whirl?
Because the code cannot interact with the hardware! That is, there are no Linux drivers or Windows Mobile drivers for the hardware that's on the iPhone. We're not even talking about things like the wi-fi won't work or anything silly like that. We're talking about big things, like not being able to start because it doesn't uncompress itself into RAM properly. We're talking about freezing the first time it has to wait for something to happen because it doesn't know how to run the hardware clocks and timers (which is CRITICAL for computers) and doesn't know when to start again.
Thus , if I tried to take some distribution of Linux or Windows or whatever, stick it in memory and start it, absolutely nothing will happen. That's right: nothing. There will be no output because it doesn't know how to run the display, or the USB, or serial. It probably won't even get to the first line of code that tells it to output something because so many things are broken.
So how can we get Linux to boot on the iPhone?By teaching it how to run the hardware. We take the knowledge gained from getting that boot menu to display and graft it into the Linux kernel. It took an unbelievable amount of devices just to get the boot menu display: clock, timer, vic, mmu, spi, i2c, gpio, system controller, pmu, nor, uart, usb, lcd, buttons. Some of those may seem obvious to you, some work in the background to support the other devices. But all of those had to be reverse engineered and all of them will have to transplanted into the Linux kernel to even get something half-assed booting.
If all of those devices were required to get something as simple as boot menu up, can you imagine what would happen if you tried to boot an operating system that did not know how to run ANY of those devices?
We cannot modify the Windows Mobile kernel because it's closed source, and so there's no way to get it to run on the iPhone.
The critical misunderstanding, I think, is that people think somehow that the OS "sits on top" of the boot menu, and talks to the hardware through the boot menu. Therefore, you can have an "emulation layer" that lets Windows or Linux or whatever talk to the hardware, without having to alter Windows or Linux itself. This is completely false. An operating system, by definition, has direct access to the hardware. Nothing sits between it and the hardware. Once iBoot has loaded the iPhone OS, you can go ahead and wipe it clean from the NOR and the OS will keep running as usual. It's not "running", it's not used or loaded in any way except during the boot process.
The iPhone will never run Windows Mobile directly (virtualization would be possible albeit it would crawl on the iPhone). It will run Linux once we write the drivers for it based on our knowledge of the hardware. Android uses the Linux kernel, though they do modify it to a certain extent. Since the only really hardware dependent parts of an OS is in the kernel, presumably once we install the necessary drivers, Android will run just as well as Linux runs. However, not having even looked at Android's source yet, I really don't have a truly educated opinion at the moment, but let's just say that it's one of this project's primary goals.
Sorry this is so long, but intelligent explanations tend to be long.
P.S. Another question people ask a lot is how long will it take. I can't truly give a good answer to that, because it's sort of dependent on the schedules of the people who work on it, and it also depends on how fast it'll take to write the Linux drivers, and how many unexpected problems crop up. It could go really unexpectedly fast, or we could hit a roadblock. I think outside observers, just reading the commit logs and reading the blog has as much information as I do on how fast things are progressing, so you're free to come up with your own conclusions on how long it will take.
Tagi: clock timer, iphe, day clock, versis, linux kernel, cpu x86, boot menu, linux drivers, mmu, android, opti, whirl, wi fi, graft, spi, knowledge gained from, many things, timers, vic, clocks
Posted by planetbeing on under th project, source release, comex, modern computer, serial cable, c code, iboot, android, descriptor, data structures, nutshell, comm, usb 2, bugs, samsung, developers |
Just a post to indicate things are inching forward slightly. I've been working on debugging USB communications and it seems a lot more stable now. I was basically forced to because my old code only works on computers without usb 2.0, so that ruled out being able to easily work on this project with anything approaching a modern computer. The problem was that I avoided reading the official USB specs (those things are usually overly locutious) and tried to learn instead from sites such as USB in a Nutshell. Unfortunately the driver then failed to properly respond to the device qualifier descriptor which led to epic fail in USB 2.0. The embarrassing thing is iBoot does send this descriptor, but I figured it must be a vendor specific one at the time.
Cmw made me a cable that let's me do serial and USB comm at the same time, which helped a lot in working out the bugs. I'd say it's fairly reliable now; enough for other developers without a serial cable to come in. So how about it, guys?
I've also started to scratch the surface of the NAND driver. Unfortunately, even the lowest level functions are enormously complex. The higher level wear leveling code and data structures even aside. A great deal of it seems to belong to Samsung, since I've found some creepily similar C code lurking around online. Unfortunately, I can't find a complete enough copy of it.
And yes, I'm aware of Android and their source release and yes, I know what you're thinking.
Tagi: th project, source release, comex, modern computer, serial cable, c code, iboot, android, descriptor, data structures, nutshell, comm, usb 2, bugs, samsung, developers
Posted by on under fcc inquiry, phil schiller, dell latitude, video debut, fcc rules, net neutrality, megasoma, networking device, designer glasses, iphe, google, social networking, unboxing, twitter, kill switch, gripes, bold text, android, comcast, htc |
The daily roundup: here's what you might've missed originally appeared on Engadget on Fri, 18 Sep 2009 23:34:00 EST. Please see our terms for use of feeds.
Permalink |
Email this |
Comments
Tagi: fcc inquiry, phil schiller, dell latitude, video debut, fcc rules, net neutrality, megasoma, networking device, designer glasses, iphe, google, social networking, unboxing, twitter, kill switch, gripes, bold text, android, comcast, htc
Posted by on under microsoft rep, iphe, harmful behavior, latter scenario, kill switch, fri, iphone, android, compas, technica, alarms, last time, fears, nbsp, peace, microsoft |
Earlier this week the internet alarms rang loud with word that Microsoft had added an app "kill switch" to its upcoming Windows Mobile 6.5 platform. Of course, such a kill switch is not unprecedented, as both the
Android and
iPhone platforms have their own variant. A Microsoft rep recently relayed a message of peace to assuage fears, telling
Ars Technica that the vast majority of app rejections won't cause a remote uninstall, and it'll only be used if the app "exhibits harmful behavior or unforeseen effects" -- not that we're entirely assured by the latter scenario, but wording aside, it does echo statements from the aforementioned companies that have so far been very conservative with its use (i.e. we can't recall a single instance of its use). "While we hope to avoid this scenario," he said, "we will make refunds available in such cases." Only time will tell just how trigger happy Microsoft gets, assuming they ever use it. Hey, just be happy we know about it -- remember the last time we were surprised to
discover such a feature?
Filed under: Cellphones
Windows Mobile 6.5 joins the ranks of iPhone and Android with its own app kill switch originally appeared on Engadget on Fri, 18 Sep 2009 17:57:00 EST. Please see our terms for use of feeds.
Read |
Permalink |
Email this |
Comments
Tagi: microsoft rep, iphe, harmful behavior, latter scenario, kill switch, fri, iphone, android, compas, technica, alarms, last time, fears, nbsp, peace, microsoft
