OESF Portables Forum
General Forums => General Discussion => Topic started by: spartan on January 05, 2005, 11:55:27 pm
-
Has anyone had any luck running something other than Linux on their Zaurus models?
To keep this as brief as possible, I need a simple program that transfers control from Linux protected userspace mode to kernel unprotected mode--starts in Linux on the Zaurus, then dirtly transfers control to an entrypoint inside an executable/bootloader.
Why? Windows CE isn't just feasible, it's so simple it's disgusting. For all intensive purposes I have a straightforward, feature-packed ROM ready for anything that uses the XScale processors, with Internet Explorer and DirectX, a huge number of video codecs, and the professional engineering of Microsoft. As a proof of concept (and to keep my difficult-to-restore C3000 clean), I would sincerely prefer a program that transfers control from Linux to anything, technically it doesn't matter.
I understood that such programs are as simple as...
void main() {
 int ptr;
 ptr = (Linux equivalent of ReadFile)(Path to executable);
 (Kernel unprotect function)(TRUE);
 (Compiler assembly directive) {
  jmp ptr;
 }
}
I've only had luck finding programs that transfer control from Windows CE to Linux, not the other way around. I don't have a Linux cross-compiler, being a Windows user. If someone were to compile this seemingly straightforward application, it would be greatly appreciated. However, that is for a different forum.
Now admitedly this sounds like blasphemy, but it's just being used as a proof of concept.
Added: The ROM information is attached.
Added: The only thing I need the the program for is specifically for testing on the C3000. For any other non-harddisk model, one should be able to flash the ROM image directly on. It can't get any more bloated than 32MBs with literally everything enabled. I already configured the Japanese keyboard layout support (the rest is plug-and-play), but I haven't tested it, so that's basically an unwise thing to do!
-
...and the professional engineering of Microsoft.
I hope you've got your flame-proof suit on
-
Best take that up to the linux-arm mailing list.
-
For all intensive purposes I have a straightforward, feature-packed ROM ready for anything that uses the XScale processors, with Internet Explorer and DirectX, a huge number of video codecs, and the professional engineering of Microsoft.
Really? So you've written and integraded Windows CE drivers for the custom display, touchscreen, SD card, and power management hardware in the Zaurus? And of course I assume you've built your WinCE kernel specifically for the Zaurus hardware memory map?
Excuse my sarchasm, but there's simply no such thing as a WinCE build that will run on any device with an Xscale processor. PDAs and other embedded devices are not like PCs. They don't have an industry standard architecture, they don't have a plug and play BIOS, they don't even have consistant memory maps. CE builds have to be targeted to a specific hardware platform. That's why you can't, for example, flash a Toshiba PocketPC with an iPaq ROM image.
Now, with enough knowledge of the Zaurus hardware obtained via reverse engineering (because Sharp hasn't published enough of the details), it is theoretically possible to create a compatible version of WinCE. But in the hundred or so times I've seen various flavors of this question asked, not once has anyone actually accomplished that task.
I won't touch the comments regarding the quality of WinCE other than to say that I've been developing military and telecom grade embedded systems since 1989 and after seeing the internals of PalmOS, WinCE, and Linux, choosing the Linux was a no-brainer.
-
I don't have a Linux cross-compiler, being a Windows user.
You could just install ZGCC on on your Zaurus, since what you want should be fairly small.
-
Thanks Tom--I'll try that. But, my C++ programming skills are certainly nothing amazing!
While you make an excellent point about memory mappings (there doesn't appear to be anything I can change about that, or if it's a problem), Kopsis, you come to an even more important conclusion: "embedded devices are not like PCs". The great advantage of system-on-chip solutions like the Xscale processor is it's simplicity to program.
Firstly, no driver programming is necessary on the PXA270 on the C3000--I couldn't confidently say the same for the PXA255 or PXA250. Broad Support Packages, the most important feature of Windows CE, handle the hardware details. The system works so perfectly because the processor is the videocard, the soundcard, the USB controller, the flash controller, the memory controller, the storage controller, the UART/GPIO controller, and even power controller of the entire system. Everything gets handled on behalf of the processor, which is why it is in fact so simple to deploy Windows CE.
Perhaps those who have previously invisioned deploying Windows CE imagined a kernel-build system, with specific tweaks needed for everything to work and versioning control to perform. With the amount that Intel and Microsoft are so deeply in bed, Platform Builder for CE .Net 4.2 handles all the work for much more than just the Xscale processor.
Just like in the Windows computer world, the issue isn't features like Windows Media Player or Internet explorer: the competition makes cheaper, faster, or prettier hardware.
The emphasis technology-wise lies in the SoC (system-on-chip) nature of embedded computers. The same could be done, just as easily, if the Zaurus ran a Texas Instruments OMAP processor or one of the new Samsung competitive products.
In response to why I am personally considering Windows CE, it's really down to the same reasons why there's Mozilla and Firefox, Gnome and KDE, Debian and Redhat: I have a choice, and I can make it free of charge! Remember, I'm sure people are interested in this, and on such a wonderful hardware platform like the Zaurus models, I came here for help.
-
Everything gets handled on behalf of the processor, which is why it is in fact so simple to deploy Windows CE.
A more correct statement is that most everything can be handled by the processor. That does not mean that it is. I've seen a number of PXA270 designs that evolved from PXA255 designs and chose not to use many of the SOC features because doing so would add significant extra development (taking stuff out of a hardware design is often as much work as putting it in).
Even on new designs, not everyone follows the "reference design". Hardware designers have to deviate to add value and differentiate their products. In fact I led one PXA270 design where we opted not to use the built-in display controller because the limited range of displays it supported did not meet our application requirements. And even if the deviation is as trivial as selecting which GPIOs are going to be used as keypad input, it's still a deviation and it means you're going to have to tailor the BSP to fit the hardware. Yes, the PXA270 means potentially less BSP customization, but expecting the reference platform BSP to "just work" on any PXA270 based device is highly unrealistic.
-
Remember, I'm sure people are interested in this
Are you forgetting that the Zaurus is almost exclusively a geek-only model here? As for the quality of Windows CE, and Windows in general, I merely point to those with computer expertise. I'll not deny that Windows is certainly useful for many people, but I just don't see the point to this at all, as people buy the Zaurii for a reason. I won't disagree with your statement that it's a matter of choice, but remember, without Linux, the actual devices aren't as good as some of their competitors. The main attraction is Linux, at least for me, and the hardware comes second.
EDIT: If you're still serious about it, then you'd be better off in a Japanese Zaurus forum. There'd be more interest there, as it's more then a geek tool there.
-
However, as a geek, I would love to get CE running on my Z.
Just for fun.
A dual boot would be cool too. CE on an SD card anyone?
-
To say the least, examining the kernel source, namely the GPIO bit flags, battery drivers, and hardware key support (crazy things like the "screen close" button), is a monumental task. To implement Windows CE 4.2 on the C3000 is far less feasible, in fact, than on earlier models because of the CE-friendly file system configuration. I agree that it's very difficult to get right. My main safe testing requirement is still a kernel mode jump program. That way, I can at least feel comfortable trashing my Zaurus.
-
Doesn't Platform Builder for CE do this for you already?
John
-
Why do you want CE on a zaurus?
If you want CE, you can get much better hardware than the zaurus for less money with CE already installed. (Loox 720, Axim x50v etc)
The only reason I can think of is that there is no decent windows CE machine with a good keyboard.
-
Why do you want CE on a zaurus?
If you want CE, you can get much better hardware than the zaurus for less money with CE already installed. (Loox 720, Axim x50v etc)
The only reason I can think of is that there is no decent windows CE machine with a good keyboard.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=62555\")
Well now with the Olympus release, you can also get much worse hardware (in terms of screen) for much MORE money with WinCE installed, without the keyboard to boot.
See [a href=\"https://www.oesf.org/forums/index.php?showtopic=10421]Thread here[/url]
Just resurrected this thread to ask a question...
How come Olympus is able to have one hardware which supporst both WinCE and Qtopia (the question that the parent poster had asked) ? I havent really checked up the Olympus hardware chip, but is it significantly different ?
Ps: Not that I am interested in WinCE alongside Qtopia, but as a hypothetical possibility ....
-
It's not about having hardware to support the software, but rather having the software support the hardware.
In terms of getting WinCE to work with a device, you need the source code to tweak drivers etc to work with your device. This requires an expensive commercial license that comes with a hefty NDA agreement from Microsoft.
Of course with Linux and GPL Qtopia it's much easier and cheaper as it's all open source. If it wasn't for this I doubt you'd see a Linux/Qtopia option for the Olympus device.
-
It's not about having hardware to support the software, but rather having the software support the hardware.
Exactly! What people don't seem to understand is that every manufacturer of a handheld device has to take the source code for someone's operating system (WinCE, Linux, Symbian, PalmOS, etc.) and change it to work with their hardware. That is difficult, specialized work. I've seen embedded development houses quote six figure prices to develop a WinCE board support package (BSP) for a new hardware platform. And then of course, you can't distribute WinCE without paying Microsoft a fee for every copy that goes out the door.
But there's an even bigger reason that few vendors offer an OS "choice" on their devices ... support costs! Unless you've actually sold PDA hardware or software, you can't even begin to imagine the number of hours that go into customer support. And the more choices you give the customer, the worse it gets.
Let's say you offer a device with WinCE with no "approved" way to modify the OS. Most of your support requests will be generic WinCE questions and you can pass the buck to Microsoft. Now let's say you offer an alternative Linux distro for customers to flash. First off you get a batch of support questions from people who want help deciding which OS they should use. You also get the inevitable percentage of customers who will have problems flashing (usually their fault but don't try to tell them that).
Those who do get Linux going will have questions and problems that you have to field because if you try to pass the buck to Trolltech or Metrowerks (companies your customer has never heard of) you're going to look really incompetent (no one ever looks bad for blaming Microsoft ). Sure you can offer Linux as an "unsupported" alternative but then most customers won't go anywhere near it (what percentage of iPaqs saw Familiar installed by the original purchaser?). Especially the first time a customer has a problem with the "unsupported" software and starts posting long rants about all their difficulties.
So as a PDA maker that wants to support the Linux community, you can:
1) Make a strictly Linux device (Zaurus approach). This is a tough sell but can work -- at least in some markets. I think it's safe to say the Zaurus is a success in Japan.
2) Open your hardware specs to the community so they can port Linux themselves (Compaq + Familiar approach). The risk here is that you open your hardware specs to your competition and risk competing with less expensive clones (since they don't have to amortize as much development cost).
3) Offer WinCE and Linux (Olympus approach). You dramatically increase your support costs for a very marginal increase in sales. This "might" work for Olympus who appears to be targeting vertical markets, but is highly impractical for the consumer electronics world.
4) Forget Linux and suffer the loud but small wrath of the offended community.
You're the CEO and there are millions of dollars (plus your incentive pay and possibly your job) on the line ... what call do you make?
-
It's not about having hardware to support the software, but rather having the software support the hardware.
Exactly! What people don't seem to understand is that every manufacturer of a handheld device has to take the source code for someone's operating system (WinCE, Linux, Symbian, PalmOS, etc.) and change it to work with their hardware. That is difficult, specialized work. I've seen embedded development houses quote six figure prices to develop a WinCE board support package (BSP) for a new hardware platform. And then of course, you can't distribute WinCE without paying Microsoft a fee for every copy that goes out the door.
But there's an even bigger reason that few vendors offer an OS "choice" on their devices ... support costs! Unless you've actually sold PDA hardware or software, you can't even begin to imagine the number of hours that go into customer support. And the more choices you give the customer, the worse it gets.
Let's say you offer a device with WinCE with no "approved" way to modify the OS. Most of your support requests will be generic WinCE questions and you can pass the buck to Microsoft. Now let's say you offer an alternative Linux distro for customers to flash. First off you get a batch of support questions from people who want help deciding which OS they should use. You also get the inevitable percentage of customers who will have problems flashing (usually their fault but don't try to tell them that).
Those who do get Linux going will have questions and problems that you have to field because if you try to pass the buck to Trolltech or Metrowerks (companies your customer has never heard of) you're going to look really incompetent (no one ever looks bad for blaming Microsoft ). Sure you can offer Linux as an "unsupported" alternative but then most customers won't go anywhere near it (what percentage of iPaqs saw Familiar installed by the original purchaser?). Especially the first time a customer has a problem with the "unsupported" software and starts posting long rants about all their difficulties.
So as a PDA maker that wants to support the Linux community, you can:
1) Make a strictly Linux device (Zaurus approach). This is a tough sell but can work -- at least in some markets. I think it's safe to say the Zaurus is a success in Japan.
2) Open your hardware specs to the community so they can port Linux themselves (Compaq + Familiar approach). The risk here is that you open your hardware specs to your competition and risk competing with less expensive clones (since they don't have to amortize as much development cost).
3) Offer WinCE and Linux (Olympus approach). You dramatically increase your support costs for a very marginal increase in sales. This "might" work for Olympus who appears to be targeting vertical markets, but is highly impractical for the consumer electronics world.
4) Forget Linux and suffer the loud but small wrath of the offended community.
You're the CEO and there are millions of dollars (plus your incentive pay and possibly your job) on the line ... what call do you make?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=65123\"][{POST_SNAPBACK}][/a][/div]
Your point 1) is that Zaurus is a tough sell but works in some markets. The only reason it does not work in all markets is that Sharp decided to not really support and push it. If I'm Sharp CEO with job on the line I release the following machine worldwide and support it:
sl-c960:
Same specs as 3000 with the following addons:
wifi, phone/grps, gps, bluetooth, 256 meg ram (possibly add new 10G hitachi harddrive), better outdoor screen
I also replace most of sharp software/applications with best of breed opensource stuff (browse these forums to find them - ie. use ko/ka/ompi etc for the best PIM available anywhere etc).
This PDA/Phone would be untouchable by anything else in the phone/pda world - you would have the highest end of the phone/pda market exclusively to yourself for a very long time. Contrary to popular beliefs the highest end of phone/pda market is large enought to easily make this very profitable (just look at how small the market share of Apple (desktop) is but even the few percent they have it is good enough to support them for all these years. There are more than enough unix/linux/mac/anti ms geeks out there to make it happen.
-
Apple also had the art and education community for a *long* time to support their high-end boxes.
Open source applications is often the best, but what about support? Support is a surprisingly big deal in the consumer and business world. Many Linux companies make their money solely on support. I don't know if all of the open-source developers (many of them working part time as a hobby) could make the transition to having a full support staff to answer a question when Joe Newbie can't figure out how to use the PIM stuff.
Having said that, I think there is a sufficient geek-factor market in the US for a Linux PDA. Nerds spend money on gizmos after all. The major bitch-factor on the Slashdot-type forums about the SL-6000L initially was the high price, I don't think too many people would bitch at the $379 closeout price. I also think the clamshell would've gone over so much better than the brick design.
-
One fairly major reason for running wince on a zaurus would be I could finally have some maps on my zaurus !
The only serious application I can't run on my z is a route planner program (yes I use one, yes I'd like to have one in my pocket). Presumably with wince running this would be possible ?
-
Interesting discussion. Dave (Kopsis) is spot on and I'm sure has more experience of these issues than anyone else on this board so take heed.
As far as I understand it the CE platform builder will do a lot for you basically chainning all the XIP (eXecute In Place) regions together that give the levels of granularity to a CE build (add office apps etc. or not), however, driver support is going to be crucial particularly surrounding things like the GPIO map associated with power control to devices as well as actually setting up data transfers etc.
I think there is potentially more mileage in taking the 'familiar' linux distribution targetting one of the devices and extracting the hardware map that would match a CE image (if indeed the mapping was comprehensive enough to support the CE image) and attempting to produce some kind of 'VMWare' type solution that worked on native execution of ARM instructions and exceptions to handle a virtualisation of the hardware maps.
Three potential problems immediately spring to mind though.
i. I'm well aware of the x86 capability to trap on IO and memory access to routines capable of providing hardware emulation so it's easy to envisage this kind of capability on x86 processors. I don't have that kind of visibility as to what is practical at such a low level on the ARM processor and indeed if necessary kernel endpoints are available that may expose such a capability for an emulator.
ii. The Hardware map needed to run Linux may not include all the pre-requisites that are needed to run the original CE image. There is probably some stuff there to ensure that CE is running on the original target. Stuff that Linux just doesn't care about. This may be a showstopper.
iii. It's likely to be extremely dodgy ground from a licensing perspective since it would mean firstly owning the specific device that matched the familiar distribution that you were going to use as your base for virtualisation (probably H3600 would be a good target) and even then there may be a licensing issue with running that OS on different hardware (actually almost certainly).
If you proceeded on your current plans to produce a native environment then licensing is also going to be a factor. It's fine as far as I understand it to use a licensed version of platform builder for OEM development and prototyping in house. The next stage in distribution is to approach Microsoft to sort out the per device licensing of the distribution which you may or may not get.
In fact it will be interesting to see if both the Qtopia and CE versions of the Olympus product actually appear on the market. It's M$ usual practice to insist on 'vendor loyalty' and 'commitment to the partnership'. Olympus may, however, be big and ugly enough to pull it off.
- Andy
-
However, as a geek, I would love to get CE running on my Z.
Just for fun.
A dual boot would be cool too. CE on an SD card anyone?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=62403\"][{POST_SNAPBACK}][/a][/div]
Well, as a geek I would even consider it vice versa.. love running a Z ROM on a CE
A dual boot would not be needed. Just a ".exe" which is a Linux kernel hosted on WinCE + a Zaurus file system. Would run on *any* WinCE device, even those that have not yet been released. What a dream!
If someone is interested: I have created a first experiment version (0.01 or even less) of a "PocketTux.exe" that does handle some Linux system calls. What is missing is real scheduling, loading of files, memory mapping etc. and really running an Linux executable. Therefore the 0.01 version.
Needs the (free) MS Embedded VisualC++ tools for compiling. The concept itself is not new - there is a Linux kernel somewhere (I forgot the name of the project) available that runs on Windows.
-- hns
-
dhns, sounds like you are headed towards to CoLinux (Co-operative Linux) type solution.
Good luck, I have always thought that there was a reasonable amount of merit in this to get the important stuff from Linux. Establishing bandwidth between the Linux environment and the host OS (CE) for games and such like may be difficult.... there again maybe not. Produce a CE based X Server talking to a CoLinux environment running on the CE device....
Your problems would be...
i. Decide on a virtual platform envoronment that offers all the features you need. (exposes the host storage and IO + Graphics + Input etc. etc. etc.)
ii. Develop a HAL (Hardware Abstraction Layer) around that environment that handles properly things like hot ejection of media that you get with CE but not with Linux.
iii. Write the Linux specific stuff to interface with the host HAL and borrow a lot from the original CoLinux project....
Possibly easier to port CyGWin to CE and start there.... depends what you want Linux for at the end of the day..... do you need Linux or do you just want GNU stuff ???
There again you are still at the mercy of M$, HP or whoever, with your base OS... 6 months later you find there's a newer smaller model and they have discontined sales of your model of CE device and you can't get that feature that you really want on your device because the vendor isn't going to offer a flash upgrade to the next version of CE (disgruntled ex Casio E105, E115, Compaq 3660, Compaq/HP 3970 owner).
-
I think there is potentially more mileage in taking the 'familiar' linux distribution targetting one of the devices and extracting the hardware map that would match a CE image (if indeed the mapping was comprehensive enough to support the CE image) and attempting to produce some kind of 'VMWare' type solution that worked on native execution of ARM instructions and exceptions to handle a virtualisation of the hardware maps.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=65540\"][{POST_SNAPBACK}][/a][/div]
There's certainly merit to this approach. Though I doubt you'd need the step of extracting a CE hardware virtualization target from Familiar. CE "out of the box" provides "reference" BSPs that support a fairly generic hardware platform. If you have enough of the CE kernel and driver code (and that's a mighty big "if") it would be possible to stub out the low level operations with calls to virtualization services that implement the operations with Linux system facilities.
The biggest problem with tricks like that is that running two operating systems requires two operating systems worth of resources. Storage and CPU aren't such a big deal but RAM becomes a major issue. I use both coLinux and vmWare extensively and they are truly wonderful if you have enough RAM. An SL-C750 or newer might have enough RAM to pull this off, but I think it would be a tight squeeze.
Going the other way (virtualizing Linux on CE) seems like more of a stretch given that the CE kernel is way less sophisticated and featurefull than the Linux kernel. I could maybe see getting uCLinux (no MMU/virtual memory) running that way, but a full kernel just seems like too much of a stretch. coLinux barely pulls that trick off on a full blown NT kernel (it still can't effectively virtualize the framebuffer, serial ports, USB, etc.). I'm pretty sure that vmWare "cheats" and takes advantage of virtualization features in the X86 architecture.
It makes for an interesting roundtable discussion, but I can't see anyone committing the level of effort needed to take projects like this to completion. For most folks, 95% percent of their application software needs can be met by one platform alone (CE for some folks, Linux for others). In most cases they'd get a better ROI on their time investment by writing (or porting) the 5% of stuff they're missing on their preferred platform PDA software is really not hard to write (at least not for people with the expertise to create virtualization software). OS hacking is fun (I've been known to do it for a living ) but app software gives more bang for the buck.
-
The only reason I can think of is that there is no decent windows CE machine with a good keyboard.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=62555\"][{POST_SNAPBACK}][/a][/div]
the new T-Mobile MDA-IV is like an 860 only with a phone built in.
-
3) Offer WinCE and Linux (Olympus approach). You dramatically increase your support costs for a very marginal increase in sales. This "might" work for Olympus who appears to be targeting vertical markets, but is highly impractical for the consumer electronics world.
I have been wondering why Olmpus chose to offer the device with a choice of OS. As you say, I reckon they'd sell 98% as WinCE, 2% as Linux. Now, if you could dual-boot, then there'd be more interest. If the linux one was a lof cheaper, then it'd appeal to some people - turn it into a dual-boot system by acquiring the ROM image of the WinCE version.
I wonder if it is because they ported linux to the device for testing/development purposes whilst verifying the hardware and realised that they might be able to sell a few more of them that way? Or, they had a specific customer who wanted a PDA linux computer and reckoned they might as sell the product more widely?
Hmm.
Paul
-
I have been wondering why Olmpus chose to offer the device with a choice of OS. As you say, I reckon they'd sell 98% as WinCE, 2% as Linux. Now, if you could dual-boot, then there'd be more interest. If the linux one was a lof cheaper, then it'd appeal to some people - turn it into a dual-boot system by acquiring the ROM image of the WinCE version.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=65967\"][{POST_SNAPBACK}][/a][/div]
Note that neither OS being offered is viable for consumers. WinCE.NET doesn't include things like Pocket Outlook, Pocket Word, Pocket Excel, etc. It's little more than an OS kernel and drivers intended for embedded (single purpose) devices. Qtopia 1.7 is quite a bit more complete but still doesn't include much in the way of apps beyond just the basic PIM stuff. Take all the Sharp developed and third-party apps off your Zaurus and how useful would it be? Remember that past studies have shown that the fraction of consumers who purchase PDAs and don't install a single piece of third party software can be as high as 50%!
Olympus expects businesses to buy the hardware and load it up with a single "enterprise app" that the customer is going to develop themselves. Offering both OS choices in this case makes sense since the end user will likely see nothing more than a single application and won't have a clue (or care) what OS is actually running.