headers
Mark Salter | 1 Mar 2003 01:07
Picon
Favicon

Re: MIPS32 gdb vectors question

>>>>> Tim Michals writes:

> Since gdb 5.3 define NUM_REGS as 90, should this also be defined in
> mips_stubs as 90 also? Instead 107?

It does use 90. The only time it uses 107 is when CYGPKG_HAL_MIPS_GDB_REPORT_CP0
is defined. Bart's recent patch turned off CYGPKG_HAL_MIPS_GDB_REPORT_CP0 in
the default case.

--Mark

--

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
Permalink | Reply | 0 comments |
headers
Jonathan Larmour | 1 Mar 2003 01:26
Favicon

Re: Question about building reboot on RedHat 8.0 system using ecosconfig

Louis Gagne wrote:
> /home/lgagne/ecoscvs/ecos/packages/devs/serial/powerpc/quicc/current/cdl/ser_qui
> cc_smc.cdl, package CYGPKG_IO_SERIAL_POWERPC_QUICC_SMC
>     Property include_files, missing arguments.
> Package CYGPKG_IO_SERIAL_POWERPC_QUICC_SMC, 1 error
> occurred while reading in the CDL data.
> 
> I am running ecosconfig 1.3.1.
> 
> Is there an incompatibility problem between this
> version of ecosconfig and RedHat 8.0?

Don't know about such a specific incompatibility but definitely don't use 
the 1.3.1 tools: use the tools from 
http://sources.redhat.com/ecos/anoncvs.html

"ecosconfig new mbx redboot" works for me with those.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

--

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
Permalink | Reply | 2 comments |
headers
Christopher Faylor | 1 Mar 2003 07:27
Picon
Favicon

Re: [eCos v1.3.1/net] Old-style path convention results in Run Tests error

On Fri, Feb 28, 2003 at 03:00:04PM +0000, Jonathan Larmour wrote:
>Cabeze de Vaca wrote:
>>
>>One year later, is this the definitive answer to this problem? Is
>>there anything else a beginner could do to resolve this issue, or is
>>it a lost cause? Should we just abandon v1.3.1/net altogether?
>
>Yes, 1.3.1/net is too far from the current state of the art (hence the 
>upcoming 2.0 release!). So instead use anoncvs and the tools from 
>http://sources.redhat.com/ecos/anoncvs.html
>
>>One of the proposed solutions was to switch to an older version of
>>Cygwin, but I'm not sure if such a version is still circulating around
>>the Internet.
>
>It isn't any more. Cygwin unfortunately only releases the last two 
>versions of the DLL. This is causing us problems right now as both cygwin 
>1.3.19 and 1.3.20 have significant problems (in fact two in 1.3.20, one of 
>which is easily corrected and has already been reported on the cygwin 
>lists, and the other is still being investigated).

I don't see any problem reports from you in the cygwin mailing list wrt
1.3.20.

What are these issues you are referring to?

cgf

--

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
(Continue reading)

Permalink | Reply | 5 comments |
headers
Bart Veer | 1 Mar 2003 12:36
Favicon

Re: [eCos v1.3.1/net] Old-style path convention results in Run Tests error

>>>>> "cgf" == Christopher Faylor <cgf <at> redhat.com> writes:

    <snip>
    >> It isn't any more. Cygwin unfortunately only releases the last
    >> two versions of the DLL. This is causing us problems right now
    >> as both cygwin 1.3.19 and 1.3.20 have significant problems (in
    >> fact two in 1.3.20, one of which is easily corrected and has
    >> already been reported on the cygwin lists, and the other is
    >> still being investigated).

    cgf> I don't see any problem reports from you in the cygwin
    cgf> mailing list wrt 1.3.20.

    cgf> What are these issues you are referring to?

The problem was only detected a day ago, and it is not clear yet
whether it is a cygwin or a gcc problem. If you are interested, the
details are as follows:

1) you build a target toolchain, based around gcc 3.2.1, on XP using
   cygwin 1.3.18. (1.3.19 should not be used for this because gdb will
   use the cygwin version of vasprintf() rather than the libiberty
   one, and the resulting gdb will fail on any system that still uses
   1.3.19).

2) that toolchain appears to work fine on XP and W2K using cygwin
   1.3.19 or 1.3.20, i.e. the two versions currently readily
   available.

3) it also works fine on W98 using cygwin 1.3.19
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nick Garnett | 1 Mar 2003 11:42
Favicon

Re: HD file system?

"Eric Verlind" <eric.verlind <at> streamconcept.be> writes:

[Please keep the discussion on the ecos-discuss list so others may
benefit from the mail exchange.]

> Could you please elaborate on your statement about the license? Could we
> take for instance the network driver for our pet Ethernet chip, which is not
> on the list of supported devices, from Linux and use it as a starting point
> for an eCos version?
> 

Anything from Linux is pure GPL, eCos is GPL with an exception. The
exception allows non-GPL code to be linked directly with eCos to make
a single executable. Pure GPL does not allow that. Importing any GPL
code into eCos would effectively nullify the exception, reverting it
to pure GPL. We don't want that.

Aside from that issue, eCos network drivers are very different from
Linux ones, and there may not be very much code that could be used. I
have certainly looked at Linux drivers in the past when the details of
some controller were unclear from the documentation, but I have always
been very careful not to just cut-n-paste code across.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

--

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
(Continue reading)

Permalink | Reply | 3 comments |
headers
Eric Verlind | 1 Mar 2003 14:33
Picon

Re: HD file system?

Okay, that's important to realise.

Suppose my company has its own code S, which is containing the company's
patented IP, constituting the basis of the company's existence. With that we
make a product called P, which consists of a single, statically linked image
with eCos used as OS. How sure can I be that patents of my company relating
to S are not endangered?

What about modifications to the code of eCos itself. Suppose that we make
modifications to -for example- the scheduler and build in a special,
patented, scheduling scheme of our own. How secure would that be from
exposal?

Thanks,

Eric

----- Original Message -----
From: "Nick Garnett" <nickg <at> ecoscentric.com>
To: "Eric Verlind" <eric.verlind <at> streamconcept.be>
Cc: <ecos-discuss <at> sources.redhat.com>
Sent: Saturday, March 01, 2003 11:42 AM
Subject: Re: [ECOS] HD file system?

> "Eric Verlind" <eric.verlind <at> streamconcept.be> writes:
>
> [Please keep the discussion on the ecos-discuss list so others may
> benefit from the mail exchange.]
>
> > Could you please elaborate on your statement about the license? Could we
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonathan Larmour | 1 Mar 2003 14:39
Favicon

Re: [eCos v1.3.1/net] Old-style path convention results in Run Tests error

Christopher Faylor wrote:
> On Fri, Feb 28, 2003 at 03:00:04PM +0000, Jonathan Larmour wrote:
> 
>>It isn't any more. Cygwin unfortunately only releases the last two 
>>versions of the DLL. This is causing us problems right now as both cygwin 
>>1.3.19 and 1.3.20 have significant problems (in fact two in 1.3.20, one of 
>>which is easily corrected and has already been reported on the cygwin 
>>lists, and the other is still being investigated).
> 
> 
> I don't see any problem reports from you in the cygwin mailing list wrt
> 1.3.20.

Indeed. The last time I reported problems about cygwin there I was a) told 
to report it somewhere else, because I wasn't sure where the problem 
originated; and b) told some of the problems must be brokenness in my 
installation. So to prevent a reoccurence in future, I (well, Bart 
actually in this case) are unlikely to be reporting any problems in future 
to the cygwin list unless and until we have a full bug report and fix 
already prepared. Of course, this may mean the report is delayed.

> What are these issues you are referring to?

The "easily corrected" one is: 
<http://sources.redhat.com/ml/cygwin/2003-02/msg01781.html> or 
<http://sources.redhat.com/ml/cygwin/2003-02/msg00958.html> or several 
other posts, the "fix" being to do the chmod in /usr/bin. This only 
affects existing cygwin users that upgrade AFAIK.

The second problem is an internal compiler error on Windows 98 with an
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Larmour | 1 Mar 2003 17:48
Favicon

Re: HD file system?

Nick Garnett wrote:
> "Eric Verlind" <eric.verlind <at> streamconcept.be> writes:
> 
>>Could you please elaborate on your statement about the license? Could we
>>take for instance the network driver for our pet Ethernet chip, which is not
>>on the list of supported devices, from Linux and use it as a starting point
>>for an eCos version?
> 
> Anything from Linux is pure GPL, eCos is GPL with an exception. The
> exception allows non-GPL code to be linked directly with eCos to make
> a single executable. Pure GPL does not allow that. Importing any GPL
> code into eCos would effectively nullify the exception, reverting it
> to pure GPL. We don't want that.

To be clear... We won't accept code into the public eCos distribution. 
*You* can use GPL code with ecos though. But in that case eCos's GPL 
exception doesn't apply - everything becomes fully GPL'd, including your 
application.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

--

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Larmour | 1 Mar 2003 23:45
Favicon

Re: HD file system?

Eric Verlind wrote:
> Okay, that's important to realise.
> 
> Suppose my company has its own code S, which is containing the company's
> patented IP, constituting the basis of the company's existence. With that we
> make a product called P, which consists of a single, statically linked image
> with eCos used as OS. How sure can I be that patents of my company relating
> to S are not endangered?

If you are using eCos with the eCos licence (the GPL *with* the exception) 
then that's okay. If you incorporate any GPL'd code, e.g. from Linux in 
your application, then everything must be distributed including your 
application.

And about patents, the GPL says: "we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all."

and
"For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program."

So you could write the program incorporating GPL'd code.... you "just" 
wouldn't be able to give it to anyone!

> What about modifications to the code of eCos itself. Suppose that we make
> modifications to -for example- the scheduler and build in a special,
> patented, scheduling scheme of our own. How secure would that be from
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Faylor | 2 Mar 2003 06:30
Picon
Favicon

Re: [eCos v1.3.1/net] Old-style path convention results in Run Tests error

On Sat, Mar 01, 2003 at 11:36:22AM +0000, Bart Veer wrote:
>>>>>> "cgf" == Christopher Faylor <cgf <at> redhat.com> writes:
>
>    <snip>
>    >> It isn't any more. Cygwin unfortunately only releases the last
>    >> two versions of the DLL. This is causing us problems right now
>    >> as both cygwin 1.3.19 and 1.3.20 have significant problems (in
>    >> fact two in 1.3.20, one of which is easily corrected and has
>    >> already been reported on the cygwin lists, and the other is
>    >> still being investigated).
>
>    cgf> I don't see any problem reports from you in the cygwin
>    cgf> mailing list wrt 1.3.20.
>
>    cgf> What are these issues you are referring to?
>
>The problem was only detected a day ago, and it is not clear yet
>whether it is a cygwin or a gcc problem. If you are interested, the
>details are as follows:
>
>1) you build a target toolchain, based around gcc 3.2.1, on XP using
>   cygwin 1.3.18. (1.3.19 should not be used for this because gdb will
>   use the cygwin version of vasprintf() rather than the libiberty
>   one, and the resulting gdb will fail on any system that still uses
>   1.3.19).
>
>2) that toolchain appears to work fine on XP and W2K using cygwin
>   1.3.19 or 1.3.20, i.e. the two versions currently readily
>   available.
>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane