dialog with WindRiver - reasonable response
george najarian
the tools - can anybody tell me if I was being reasonable in my request,
or not? Thanks -
email dialog follows:
---------------------------------
I am limited in my ability to help you.
1) You are using a 3rd party-custom BSP
2) The gdbarm works without the EPI jenni jtag.-Implies that the gdbarm
works.
3) I do not know how gdbarm is built. (I am not part of the development team
that enhanced gdbarm)
My question is how did EPI obtain source code for gdbarm?
(Especially the custom hooks)
Thanks
Jack
-----Original Message-----
From: Najarian, George [mailto:na...@conetcomm.com]
Sent: Monday, February 05, 2001 2:19 PM
To: 'Chow, Jack'
Subject: RE: TSR 227541
so you don't plan on helping me?
-----Original Message-----
From: Chow, Jack [mailto:Jack...@windriver.com]
Sent: Monday, February 05, 2001 11:46 AM
To: 'Najarian, George'
Subject: RE: TSR 227541
I do not have that type of information on hand. (build of gdbarm)
Also, your board does not appear to be supported by Wind River (3rd party or
custom bsp) The bsp was created by another vendor.
Why don't you use the suggestion posted by Luke Diamond
<Dia...@btinternet.com>?
He responded to your post in the comp.os.vxworks to get the canonical gdb
from FSF.
Thanks
Jack
-----Original Message-----
From: Najarian, George [mailto:na...@conetcomm.com]
Sent: Monday, February 05, 2001 1:47 PM
To: 'Chow, Jack'
Subject: RE: TSR 227541
I am using a v1.2 BSP based on this BSP :
/* config.h - ARM PID configuration header */
/* Copyright 1996-1998 Wind River Systems, Inc. */
/*
modification history
--------------------
01a,05oct98,vnk written from pid7t bsp by mBedded Innovations Inc.
*/
/*
This module contains the configuration parameters for the ARM 6910 based
Hydrogen Eval board.
*/
It has been modified by Intel to support their BC6911 based product.
What am I supposed to do if the version of gdbarm that you released is
proprietary and you will not help me debug it?
Can you at least tell me how you build your copy of gdbarm? What tools
and build environment to I use? What do I need to do to capture (and
hopefully
fix) the problem I am seeing?
I want to let you know I am keeping logs of this and am going to post them
to the appropriate newsgroups - I need to to get some opinions on whether
you are
violating the GPL or not by not releasing the source.
I don't think I am asking too much ... just for the level of support that we
already
paid for.
-----Original Message-----
From: Chow, Jack [mailto:Jack...@windriver.com]
Sent: Monday, February 05, 2001 11:18 AM
To: 'Najarian, George'
Subject: RE: TSR 227541
Please get the gdbarm from GPL.
Wind River did make some enhancements off of the freeware version.
Some portion of wind river's gdbarm is considered intellectual property.
Thus, I can not give you the source.
Thanks
Jack
-----Original Message-----
From: Najarian, George [mailto:na...@conetcomm.com]
Sent: Monday, February 05, 2001 1:17 PM
To: 'Chow, Jack'
Subject: RE: TSR 227541
As far as I am concerned, the TSR is still open. Here is the text
from my original request.
------
Tornado license #: 104022.
I am currently trying to find out why the gdbarm debugger is causing an
internal
exception when I try to debug my arm target with the JEENI JTAG EmbeddedIce
debugger. The techs at EPI helped me with the log file that their dll
generated and
told me this is a gdb problem, most likely with an unitialized string. I can
send detailed
information of the failure mode if you are willing tohelp me. If you are
not, then can
you help me build a debugging version of gdbarm so I can trace the exception
when
it happens? I would need the source for gdbarm and instructions on how to
rebuild it.
Thank you for your prompt attention.
------
What I am looking for is a debug version of the gdbarm that you supply with
your toolset,
or the source and build instructions so I can do it myself. Since it is GPL
freeware, there
should not be any issues with you releasing this information.
Thanks.
-----Original Message-----
From: Chow, Jack [mailto:Jack...@windriver.com]
Sent: Monday, February 05, 2001 8:38 AM
To: 'Najarian, George'
Subject: RE: TSR 227541
Can you please let me know what is the current status of this TSR?
Thanks
Jack
-----Original Message-----
From: Najarian, George [mailto:na...@conetcomm.com]
Sent: Thursday, February 01, 2001 4:32 PM
To: 'Chow, Jack'
Subject: RE: TSR 227541
I understand that. What I need and originally requested was instructions
(including the tools used) on how to build gdb for the windriver
environment.
Can you help me with this?
-----Original Message-----
From: Chow, Jack [mailto:Jack...@windriver.com]
Sent: Thursday, February 01, 2001 1:55 PM
To: 'Najarian, George'
Subject: RE: TSR 227541
Actually, I believe that gdbarm is freeware protected by the GNU General
Publifc License (GPL) and you can probably grab the source somewhere.
(maybe Cygnus Solutions).
Since the debugger works without the JENNI JTAG, this is not really a
tornado tools problem.
Thanks
Jack
-----Original Message-----
From: Najarian, George [mailto:na...@conetcomm.com]
Sent: Thursday, February 01, 2001 3:49 PM
To: 'Chow, Jack'
Subject: RE: TSR 227541
I recompile in the JEENI support when I need it. I only
run one debugger environment at a time.
-----Original Message-----
From: Chow, Jack [mailto:Jack...@windriver.com]
Sent: Thursday, February 01, 2001 1:37 PM
To: 'Najarian, George'
Subject: RE: TSR 227541
Just wondering why you are using two separate debuggers. I did not know that
was possible.
Thanks
Jack
-----Original Message-----
From: Najarian, George [mailto:na...@conetcomm.com]
Sent: Thursday, February 01, 2001 3:45 PM
To: 'Chow, Jack'
Subject: RE: TSR 227541
Yes. I do not have any problems when I am running the wdbrpc
interface.
I am attaching a couple of .log files from the error dump when
using the JENNI dll interface.
-----Original Message-----
From: Chow, Jack [mailto:Jack...@windriver.com]
Sent: Thursday, February 01, 2001 1:30 PM
To: 'na...@conetcomm.com'
Subject: RE: TSR 227541
Good afternoon,
My name is Jack and I have been assigned your TSR.
Does the gdbarm work without the JENNI JTAG EmbeddedICE debugger attached?
Thanks
Jack
Jan Djärv
> -----Original Message-----
> From: Chow, Jack [mailto:Jack...@windriver.com]
> Sent: Monday, February 05, 2001 11:18 AM
> To: 'Najarian, George'
> Subject: RE: TSR 227541
> Please get the gdbarm from GPL.
> Wind River did make some enhancements off of the freeware version.
> Some portion of wind river's gdbarm is considered intellectual property.
> Thus, I can not give you the source.
> Thanks
> Jack
If the "enhancements" are linked in the gdbarm executable and if WindRiver
distributed this enhanced gdbarm to you, not giving you the source is clearly a
violation of the GPL. I suggest you take this up with the copyright holder of
GDB proper, which is FSF.
Jan D.
Johan Borkhuis
>I should note that some people at WRS are really helpful. Some of
>them could even be developers for WRS who post helpful messages here
>on occasion. At any rate, I don't think it is bad to `flame' their
>technical support. It is pretty atrocious. I had asked if anyone
>here had positive comments on it. I didn't hear any, but maybe that
>is apathy.
Actually I did not have any negative experiences with the tech support. I
had several SPR's and TSR's, but they were all resolved quickly.
The FAE's I have ben in contact with were always very helpfull.
Groeten,
Johan
--
o o o o o o o . . . _____________________________
o _____ || Johan Borkhuis |
.][__n_n_|DD[ ====_____ | bork...@agere.com |
>(________|__|_[_________]_|__________________________|
_/oo OOOOO oo` ooo ooo 'o!o!o o!o!o`
=== VxWorks FAQ: http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html ===
Jim Way
> I should note that some people at WRS are really helpful. Some of
> them could even be developers for WRS who post helpful messages here
> on occasion. At any rate, I don't think it is bad to `flame' their
> technical support. It is pretty atrocious. I had asked if anyone
> here had positive comments on it. I didn't hear any, but maybe that
> is apathy.
I just want to amplify what you've said about support. The phone-in support
does seem to be less than what I would expect, considering the cost of the
software, licenses, etc. HOWEVER, my experiences with my local sales team
including the FAE (Field Application Engineer) have been positive and
helpful. But my best resource for support has been this user group. Up until
a couple months ago, I was the only person in my department with any vxWorks
experience. This group has become my lifeline.
You are also correct that sometimes WRS developers do respond to posts in
this group.
FWIW, I've been on the receiving side of customer support calls. I
understand how difficult it can be to extract useful information from a
caller. But WRS doesn't make the process any easier by requiring you to
first validate your license, then get a call-back telling you you're
validated, then wait hours/days for a callback from someone to try to help
with your problem. I suspect that they have a two-tiered system where one
group is exclusively phone handlers and the other group is exclusively
development engineering. Perhaps they could benefit from rotating their
development staff through the customer support function (in very short
shifts, of course, of no more than one week at a time). I also don't have
much sense that they divide the incoming calls up between different host
platforms or different target processors, although that *could* be happening
and I just don't see it.
WRS could also help their customers by developing user-focused
documentation. What they have at the moment I describe as "menu
documentation". Here's a list of everything you can do. But what I want is
documentation that answers the question, "How do I ...?". That's the
question I bring to the manuals, and I'm always frustrated in my quest for
knowledge. I know (again from personal experience) that this documentation
takes a long time to develop. I also know that once the customers find it
and learn to trust it, it can dramatically reduce the amount of tech support
that needs to be provided in real-time.
Repeating a complaint (suggestion?) I've made here before, a great start
would be to create a Master Index that spans all the documentation. Too
often I see people chastising to "RTFM". Without a Master Index, how do you
know *which* FM?
The bottom line is, we are smart, motivated, hardworking people who are
trying to use vxWorks as a tool to do our jobs. We don't need to be
spoonfed. We don't need to be belittled or intimidated either.
My $0.02,
Jim
-----------------------------------------
Jim Way, Software Engineer
Datum Austin (Austron Inc.)
voice: 512.721.4170
fax : 512.990.9712
email: jwayATdatumDOTcom (no spam please)
-----------------------------------------
Tornado vxWorks
Jim Thomas
Jim> I just want to amplify what you've said about support. The phone-in
Jim> support does seem to be less than what I would expect, considering
Jim> the cost of the software, licenses, etc.
I never got that far. They never would answer my question about their
requirement that I have a modem hooked to my system for them to use.
Jim> ... HOWEVER, my experiences with my local sales team including the
Jim> FAE (Field Application Engineer) have been positive and helpful.
Presumably that must depend on volume? For those of us who have a couple
of seats and ~10 BSP's it's hard to get a sales droid to answer calls. I
understand economics, but there has to be some response. They still send
me flyers for new products, but I guess they haven't noticed that our
support has lapsed.
Jim> ... FWIW, I've been on the receiving side of customer support calls.
So have I, though it was years ago and the user volume was not huge
(PDP-10). But I answered the phone directly.
Jim> ... But WRS doesn't make the process any easier by requiring you to
Jim> first validate your license, then get a call-back telling you you're
Jim> validated, then wait hours/days for a callback from someone to try to
Jim> help with your problem. I suspect that they have a two-tiered system
Jim> where one group is exclusively phone handlers and the other group is
Jim> exclusively development engineering.
That sounds like three levels. Phone interference, response, and
development?
Jim> ... Tornado vxWorks
Dave Korn
>Repeating a complaint (suggestion?) I've made here before, a great start
>would be to create a Master Index that spans all the documentation. Too
>often I see people chastising to "RTFM". Without a Master Index, how do you
>know *which* FM?
By reading *all* the FMs and familiarising yourself with their contents.
When you first start working under a new OS, you should read, browse and
skim through all the available manuals, to get at least a working view of
what's where. Borrow them from the office overnight, read them on the bus
home, browse through them on the toilet, flip through the pages in your
lunch hour; steep yourself in the knowledge you are trying to acquire. I
suppose you could call it 'method' programming. During the course of all
this you will get a good subconscious knowledge of what's where. You can
skim through or skip over the bits that are most irrelevant to your job;
you'll still know where to find them if you need them. And there are things
that you know in advance you'll need to pay attention to, because they're
the same things that are tricky in all OS's and architectures: how do
interrupts work, and what restrictions do they place on system calls? How
is the scheduling handled? How do you lock task changes and interrupts out?
Where are the clocks/timers and what are they used for? Then there are the
things that are pretty much the same between all OS's: semaphores, file
handles, malloc and free; you can assume you already know how these work and
skip fairly quickly through those bits of the manual. There's no shortcut
for doing your homework.
All this is of course IMO and YMMV, but it's worked for me across a whole
series of OS's and architectures. There's a steep learning curve when
beginning work under a new architecture, but if you take it slow for the
first couple of weeks and take the time to deeply familiarise yourself with
the new system, it will more than repay your effort in terms of better effic
iency later on. Of course, you might be in the situation when your
management throws something new at you and tells you you've got to get it
done in a couple of weeks. Then you're shafted, and your only real option
is to tell them to choose between having it done well-but-slower, or
on-time-but-shit.
I'd be interested to hear any other suggestions people have for adapting
to a new and unknown OS and finding out the pitfalls and gotchas.
DaveK
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.