Re: Kernel Debugger Problem
From: Clinton D. Britt (ClintonDBritt_at_discussions.microsoft.com)
Date: 09/20/04
- Next message: Jeff Kelley [MS]: "Re: NDISUIO - NIC_STATISTICS"
- Previous message: David Hurst: "ddi_ragexl can't be loaded on CE 5.0"
- In reply to: Steve Maillet \(eMVP\): "Re: Kernel Debugger Problem"
- Next in thread: Steve Maillet \(eMVP\): "Re: Kernel Debugger Problem"
- Reply: Steve Maillet \(eMVP\): "Re: Kernel Debugger Problem"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 20 Sep 2004 14:11:03 -0700
Hi Steve,
Well , I guess we are going to have to stand divided on this issue. We spent
a lot of time, and effort on our platform architecture. I think that my
co-workers and I feel that luck was not a big factor in our design.
We created a boot loader that boots CE and other OS platforms that we sell
for our platforms. We “must” know what the OS is before we boot it. We also
are real big on security. We want only our authorized images to be placed on
our devices. We allow the images to be loaded via serial, Ethernet, and
PCCard. They all use the same mechanics to load the image. We also have a
three step booting process that prevents us from making a "brick" out of our
device. These pieces can be loaded in the same fashion, and use the header to
distinguish what unit it is. This is better than making a separate boot
process for every transfer method and OS/module type. This is the ONLY way I
know of to handle this type of process. So, in short, every module we load
has to have a Rockwell specific header on it. Since we wanted to use the
existing desktop tools like PB and ESHELL to transfer the image, we had to
find a way to add what we needed to the transfer. These tools only allow a
single file to download with a fixed file name (CE 5.0 and ESHELL do allow
the name to be changed). This concern is more important when debugging a RAM
image. CE is not the only platform we allow to debug out of RAM. Again, we
needed a standard method for working with many images.
I must take exception to your statement about getting lucky with an
unsupported method. We have taken great care to design a boot process which
best supports our customers needs. Microsoft supplies the boot loader as
sample code, and as such it is largely unsupported. We have worked with
Microsoft on many issues and they have seen our implementation without making
any comment about it being a problem of any kind. Many manufacturers put
their own spin on the boot loader to suit their needs. We have done the same.
In any case, do we have a problem now? Yes. But this is what happens when you
design software, not everyone designs things exactly the way you may have
intended it. We feel we used ingenuity not luck to produce a very stable and
versitle platform.
I appreciate your input, really! But at this point I really need some
constructive suggestions. I also have submitted this to MS premier support,
and hope they can come up with some alternatives..
Again, thanks for your time, patience, suggestions, and effort….
Clinton D. Britt
Rockwell Automation
"Steve Maillet (eMVP)" wrote:
> You got lucky in it working in the past. (Quite frankly - I have no idea how
> as PB expects the BIN file signature at the beginning and a bunch of
> information from the BIN file structure.) It's never been officially
> supported debugging anything but a valid OS image file.
>
> You say you can't even download using the windows CE PB EBOOT protocols
> without having the header? Why not? That would take some re-write of the
> available download support.
>
> It's sounds like you've gotten yourself into a bind relying on
> unsupported/undocumented behavior that was never actually intended and that
> behavior is now different. It's difficult to say what the best solution is
> without a more thorough review of the complete scenario.
>
>
> --
> Steve Maillet
> EmbeddedFusion
> www.EmbeddedFusion.com
>
> Do have an opinion on the effectiveness of Microsoft Windows Mobile and
> Embedded newsgroups? Let us know!
> https://www.windowsembeddedeval.com/community/newsgroups
>
>
>
- Next message: Jeff Kelley [MS]: "Re: NDISUIO - NIC_STATISTICS"
- Previous message: David Hurst: "ddi_ragexl can't be loaded on CE 5.0"
- In reply to: Steve Maillet \(eMVP\): "Re: Kernel Debugger Problem"
- Next in thread: Steve Maillet \(eMVP\): "Re: Kernel Debugger Problem"
- Reply: Steve Maillet \(eMVP\): "Re: Kernel Debugger Problem"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|