Re: Converting ARMV4I BSP into ARMV4
From: Dean Ramsier (ramsiernospam_at_nospam.com)
Date: 07/09/04
- Next message: Dean Ramsier: "Re: Development time for Windows CE BSP on ARM platform ?"
- Previous message: remcow: "Re: just cut the kitl cord and my ethernet stopped working"
- In reply to: Jacek: "Re: Converting ARMV4I BSP into ARMV4"
- Next in thread: Steve Maillet \(eMVP\): "Re: Converting ARMV4I BSP into ARMV4"
- Reply: Steve Maillet \(eMVP\): "Re: Converting ARMV4I BSP into ARMV4"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 8 Jul 2004 22:55:15 -0400
Different answers due to different understanding of the problem. Both are
correct, and both anwer part of your question. He said your problem wasn't
because of ARMV4/V4I. I agree, and add that your failure is because of the
libraries/features difference between the two OS versions.
Yes, PPC is WindowsCE. However, every CE port is custom. PPC has a number
of libraries that are custom to PPC, and not duplicated on the regular CE
builds. In the application space, there are differences in
capability/features. In driver space, it's all pretty much the same thing.
My main point was that you can't expect PPC applications in general to run
on CE because those two are incompatible. Some applications will work, but
only if the application does not make use of PPC specific
features/libraries.
Your ARMV4/ARMV4I problem is a tools problem, not an application problem.
As Bill said, the ARMV4 apps will be fine on an ARMV4I OS build (or at least
they won't fail due to CPU mismatch).
Note that the whole point of an SDK is that it must match the exact OS build
of the device. You should not be able to build an application that won't
run on your system if the SDK you use was built for your device. You can't
use a PPC SDK and expect the app to run on both platforms. Don't think of
an SDK as a comprehensive library of all OS functionality - that's the wrong
use of an SDK. There is a generic PPC SDK only because Microsoft requires
every PPC device to have a specified set of OS components. It's not an
option to leave something out. Therefore, they can release a single SDK
that will work with every PPC device. You don't have that benefit with any
other CE device.
-- Dean Ramsier - eMVP "Jacek" <jacek@nospam.com> wrote in message news:9b4re01aqn29bv8bdsr6d8jle9c8c06bac@4ax.com... > You are right that I am confused about ARMV4 versus ARMV4I, and I am > trying to get some help to understand this problem better. After > scanning previous posting, I don't think that I am the only one > confused, since similar questions are answered both ways - e.g., look > at your answer and Bill's. You both guys know much more than I know > about CE, yet your answers differ greatly. > > However, I am not too sure if I understand your statement about two > different OSes. I would be clear on that if I was comparing VxWorks > to WinCE - different calling conversions, different image layout, etc. > However, PPC is derivative of CE. I see it as the same base OS with > different libraries (where some libraries might not exist on the other > platform, or some entries in the libraries might not be implemented). > Therefore, Bill statement was true, when he said that he can run some > device drivers. > > I see SDK that is provided for the platform only as comprehensive > library set, that you link your app against, and eventually might get > some unresolved issues there (if you try to use non existing > functionality). > > At least, this is how I understand it right now. > > We are not trying to build CE image that will run _everything_ written > for PPC device. We have just one (few) app that we try to see if we > can run. I dumped these apps, and don't see any imports that I should > not be able to provide with CE platform. Right now, I cannot run that > app on the image provided with dev system we bought (ARMV4I). I can > run them partially, when I cut different ARMV4I CE image adding some > libraries. However, I cannot debug anything using eVC debugger due to > the CPU mismatch (ARMV4 versus 4I). So, I am struggling to get ARMV4 > clean BSP mostly in order to be able to use eVC debugger. > > Thanks, > Jacek > > On Thu, 8 Jul 2004 10:36:16 -0400, "Dean Ramsier" > <ramsiernospam@nospam.com> wrote: > > >You're confused about the actual problem. It isn't ARMV4/ARMV4I. The > >problem is you are mixing two different OSes. PocketPC is a specific > >implementation of CE. When you build a platform in PB, you're building a > >different implementation of CE. It is not true in CE that one application > >can run on multiple different CE devices like what happens on the desktop. > > > >In general, applications must be targeted to the specific device that they > >are going to run on. That's why you need to create an SDK for a specific > >device. PPC is a specific device, but you can't build a PPC device. > > > >You can build a CE device and include as many OS features as you need (such > >as aygshell, etc). Depending on the app you're trying to run, this might be > >enough. However, it's not true that you will be able to run every single > >PPC application on your custom CE device. > > > >-- > >Dean Ramsier - eMVP > > > > > >"Jacek" <jacek@nospam.com> wrote in message > >news:9euoe0h2vpb8fvkn3qus4n4rdv4imaucna@4ax.com... > >> One thing is just CPU (instruction set), the second is OS type > >> (libraries needed). You have mentioned device drivers that usually > >> are 'clean' apps that require only core OS support. Therefore, they > >> run on your box. On the other hand, UI apps are linking to variuos > >> libraries that might not be provided (or if provided, then not fully > >> implemented) by the WinCE image. Therefore, in my case, I was > >> struggling with manually copying aygshell, etc. to no avail. However, > >> after I built new ARMV4I platform that included these libs, my demo > >> app (eVC, MFC based) started. However, I still couldn't run third > >> party app I need to run (hung during the startup process). > >> > >> Another problem with CPU mismatch is that I cannot use eVC debugger. > >> When I try to debug any app, it complains about that mismatch, and at > >> the end refuses to start the app. > >> > >> So, not being able to debug our apps, and seeing that third party app > >> crashing during the startup, I feel that the only option is to clone > >> that BSP from ARMV4I to ARMV4. I did that, and created an image > >> (several) of ARMV4 WinCE, but box doesn't want to come up with these > >> images. I get it up to UI level, but it looks like it is dead - touch > >> screen panel doesn't work. > >> > >> Platform Builder doesn't complain about code mismatch (thinks that > >> everything is ARMV4 only). So, I am not sure if there are any flags > >> that I have to play with in PB to specify that this BSP that it is > >> ARM4 not 4I? Or after BSP cloning, PB should already resolve these > >> issues? > >> > >> jacek > >> > >> On Thu, 1 Jul 2004 21:03:54 -0400, "bill" <poddw@yahoo.com> wrote: > >> > >> >Something isn't right about your description. You can run ARMV4 > >applications > >> >on an ARMV4I box. We make an ARMV4I box and we use PPC 2003 drivers for > >> >things such as plug-in ethernet cards and PCMCIA cards. Even USB drivers. > >> > > >> >"Jacek" <jacek@nospam.com> wrote in message > >> >news:4sm8e0pk2f2flrj60qaljh3abai2jio2ef@4ax.com... > >> >> We have bought pxa255 development system that has only ARMV4I BSP, and > >> >> WinCE 4.2 image built on the top of it. Our problem is that we need > >> >> to run on that system third party PocketPC 2003 application that we > >> >> cannot modify. > >> >> > >> >> Even if we also copy aygshell.dll, and few other libraries to the app > >> >> folder, nothing that is built for Pocket PC 2003 (like a generic app) > >> >> works on this system. Therefore, we would like to convert that BSP to > >> >> ARMV4 (to be able to build a platform with aygshell). > >> >> > >> >> Will it be feasible to use Platform Builder 'clone BSP' feature to get > >> >> ARMV4 BSP from the provided ARMV4I BSP, or do we need to modify > >> >> individual files, and without help of development system provider it > >> >> will not work. Provided BSP is basically a copy of Intel's > >> >> development platform. > >> >> > >> >> Jacek > >> > >
- Next message: Dean Ramsier: "Re: Development time for Windows CE BSP on ARM platform ?"
- Previous message: remcow: "Re: just cut the kitl cord and my ethernet stopped working"
- In reply to: Jacek: "Re: Converting ARMV4I BSP into ARMV4"
- Next in thread: Steve Maillet \(eMVP\): "Re: Converting ARMV4I BSP into ARMV4"
- Reply: Steve Maillet \(eMVP\): "Re: Converting ARMV4I BSP into ARMV4"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
|
