This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

SuperH DTF connection protocol


We, here at what will be SuperH, Inc., want to add support for a new
target - probably to be called 'sh-elfdtf'.

The DTF (Data TransFer) protocol uses the SH4 (& 5) debug port to allow
communication with an embedded target. It is basically the same idea as
the GDB trap system currently used in newlib for SH, but also works on
silicon.

So question 1 is: Would it be acceptable for us to add support for such a
thing, and what would we have to do, and what tests would it have to pass, 
to get the changes accepted?

However, this is where the problems start. The DTF sources have three
parts: the target side, the host side and some shared stuff used on both
sides. The host stuff is propriatory and will not be GPLed under any
circumstances. We understand that the target and shared stuff will have to
be GPLed in order for it to be used with newlib. The problem is that, in
order to keep the host and target code syncronised correctly, we are loath
to include even the target code in newlib directly, but would rather
include it only in sources available directly from us (i.e. there isn't
any reason why anybody (without both halves) would want to change it and 
we would rather they weren't tempted).

This leaves us with a few options so the next question is: which would
you, the newlib maintainers, prefer?

1. We make the changes, but then just don't add the DTF sources to CVS.
Newlib will still build for the elfdtf target, but programs built with it
won't link.

2. As for (1) but we put an error message at configure time if the DTF
sources are not present. This will make it difficult for others to test
it, but would be preferable for us.

3. We put in minimal support for the target (say in configure.host), thus
hardly changing the newlib sources, and then supply the DTF sources as an
add-on (similar to linuxthreads for Glibc).

or

4. We are forced to put the full target-side sources into newlib so that
it will always build and programs can be linked (though they still won't
run without a DTF host program). This is the least favourite option.

Are there any other options? Perhaps there are - whatever, we need to get
this resolved somehow.

TIA

------------------------------------------------------------------------
|  Andrew Stubbs,                   |  E-mail: Andrew.Stubbs@st.com    |
|  STMicroelectronics Ltd.,         |  or      stubbsa@bristol.st.com  |
|  1000 Aztec West,                 |                                  |
|  Almondsbury,                     |  Tel:    +44 (0)1454 462325      |
|  Bristol, BS32 4SQ, U.K.          |  Fax:    +44 (0)1454 617910      |
------------------------------------------------------------------------



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]