headers
阎淼 | 1 Jul 2008 17:07
Picon

problem with termios

Hi,
  I am debugging my program using gdb downloaded from here:
  http://www.slac.stanford.edu/~strauman/rtems/gdb/index.html

  I connected gdb through /dev/console, baud rate is 9600. I found
that termios rawInBuf always overflow, when gdb sending data to rtems,
I print out the following message:

  termios recv buffer overflow! 1 chars dropped
  termios recv buffer overflow! 1 chars dropped
  termios recv buffer overflow! 32 chars dropped
  termios recv buffer overflow! 1 chars dropped
 ......

  I increased rtems_termios_raw_input_size to 163840 (160 KB), still
it overflows!!

  Following is part of serial driver code:

    /* rx interrupt */
    else if((isrStatus == IIR_RDA) || (isrStatus == IIR_TIMEOUT))
    {
	i = 0;
        do
        {
            ST16552_REG_READ(uart_data[0], RBR, ch);
	    buf[i++] = ch;
            ST16552_REG_READ(uart_data[0], LSR, pollStatus);

        } while ((i < 32) && ((pollStatus & LSR_DR) != 0));
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel Sherrill | 1 Jul 2008 18:09
Gravatar

NetBSD License Change

Hi,

It looks like the NetBSD Foundation has dropped
the advertising clause from their license.

http://www.netbsd.org/changes/#2clause

More details are here:

http://www.netbsd.org/about/redistribution.html

This has no immediate impact on RTEMS.  This
mostly opens another potential source when
looking for code.  Neither newlib nor RTEMS
will accept code with the advertising clause.

I assume it will take them some time to
propagate this change through their tree.
And if the NetBSD Foundation does not hold
the copyright, then it is possible there will
still be code in the tree with the clause.

--

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

_______________________________________________
rtems-users mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel Sherrill | 1 Jul 2008 18:10
Gravatar

License Question

Hi,

Looking for opinions on the license for this
collection of CRC software.  

http://www.lammertbies.nl/comm/software/index.html

> The software on this page is believed to function as described in the 
> document present in each archive file. All archive files are in ZIP 
> format.
>
> Use this software at your own risk. Lammert Bies can not be held 
> responsible for any damage, financial loss or injuries resulting from 
> using the software found here. If such problems are encountered using 
> this software, please send me a mail message describing the problem 
> and the software will either be updated, or removed from this website.
>
My gut feeling is that I need to ask the author
for a real license.  This doesn't seem to be one.

--

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

_______________________________________________
rtems-users mailing list
rtems-users@...
http://rtems.rtems.org/mailman/listinfo/rtems-users
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel Sherrill | 1 Jul 2008 20:24
Gravatar

Branching 4.9

Hi,

I would like to branch 4.9 within the next two
weeks.  If you have modifications outstanding
against the CVS head and would like to see them
make the 4.9 release series, now is the time to
speak up.  The window is closing.

There are a couple of tool issues on the table
so I expect there will be some tool revisions
along the way but yum makes that easy to deal
with. Thanks Ralf.

--

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

_______________________________________________
rtems-users mailing list
rtems-users@...
http://rtems.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 3 comments |
headers
Ralf Corsepius | 2 Jul 2008 19:16
Favicon

Re: Branching 4.9

On Tue, 2008-07-01 at 13:24 -0500, Joel Sherrill wrote:

> There are a couple of tool issues on the table
> so I expect there will be some tool revisions
> along the way but yum makes that easy to deal
> with.

Like any RTEMS branch, branching will have to be accompanied by a
version bump (4.9->4.10) on CVS-HEAD, which should be accompanied by a
tool version bump.

Ralf

_______________________________________________
rtems-users mailing list
rtems-users@...
http://rtems.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 2 comments |
headers
Fabrício de Novaes Kucinskis | 2 Jul 2008 20:34
Picon
Favicon

Problem using Region Manager with very small segments

Hello all,

I have an ERC32 application, in which I create a Region with length = 512
bytes and page_size = 8 bytes.

The RTEMS User Manual says that the page_size shall be a multiple of four
greater or equal four, but if I try to create a region with page_size = 4 I
got a "RTEMS_INVALID_PAGE_SIZE" error. Using page_size = 8 there is no error
but, when I ask for a segment of, say, 5 bytes, I got a 12 byte-segment, and
not a 8 byte-segment, as would be expected.

Furthermore, I'm having a weird problem, and that's the main reason for this
call for help: normally I ask for segments of 2 to 16 bytes. The application
seems to work properly, but sometimes I got a RTEMS_INVALID_SIZE error (do
not confuse with RTEMS_UNSATISFIED). 

The strange thing here is that I got this error when asking for a three-byte
segment, when only two segments of no more than 24 bytes are allocated.
RTEMS_INVALID_SIZE should occur only when the size of the segment is zero or
greater than the maximum segment possible, which is not the case.

I checked, and my application doesn't write outside the segments boundaries,
so I don't think the region is corrupted. Could be then some problem with
the segment's overhead? The manual states that there is an overhead for each
segment, but it lacks information about the size of such overhead. I know it
is not possible to calculate the number of bytes available in a region, but
what is the overhead per segment?

Any help or additional information will be greatly appreciated.
Thanks in advance and best regards,
(Continue reading)

Permalink | Reply | 5 comments |
headers
bimal varghese | 3 Jul 2008 08:26
Picon

rtems package for debian

hai every one I wish to join the rtems debian package development team.

_______________________________________________
rtems-users mailing list
rtems-users@...
http://rtems.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 0 comments |
headers
Joel Sherrill | 3 Jul 2008 14:45
Gravatar

Re: Problem using Region Manager with very small segments

Please send me some (simple) code that reproduces this and I
will look into it.

--joel

Fabrício de Novaes Kucinskis wrote:
> Hello all,
>
>
> I have an ERC32 application, in which I create a Region with length = 512
> bytes and page_size = 8 bytes.
>
> The RTEMS User Manual says that the page_size shall be a multiple of four
> greater or equal four, but if I try to create a region with page_size = 4 I
> got a "RTEMS_INVALID_PAGE_SIZE" error. Using page_size = 8 there is no error
> but, when I ask for a segment of, say, 5 bytes, I got a 12 byte-segment, and
> not a 8 byte-segment, as would be expected.
>
> Furthermore, I'm having a weird problem, and that's the main reason for this
> call for help: normally I ask for segments of 2 to 16 bytes. The application
> seems to work properly, but sometimes I got a RTEMS_INVALID_SIZE error (do
> not confuse with RTEMS_UNSATISFIED).
>
> The strange thing here is that I got this error when asking for a three-byte
> segment, when only two segments of no more than 24 bytes are allocated.
> RTEMS_INVALID_SIZE should occur only when the size of the segment is zero or
> greater than the maximum segment possible, which is not the case.
>
> I checked, and my application doesn't write outside the segments boundaries,
> so I don't think the region is corrupted. Could be then some problem with
> the segment's overhead? The manual states that there is an overhead for each
> segment, but it lacks information about the size of such overhead. I know it
> is not possible to calculate the number of bytes available in a region, but
> what is the overhead per segment?
>
> Any help or additional information will be greatly appreciated.
> Thanks in advance and best regards,
>
>
> Fabrício de Novaes Kucinskis - DEA / INPE
> -----------------------------------------------
> Onboard Data Handling Group - SUBORD
> Aerospace Electronics Division
> Brazilian National Institute for Space Research
>
> _______________________________________________
> rtems-users mailing list
> rtems-users@...
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   

--

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

_______________________________________________
rtems-users mailing list
rtems-users@...
http://rtems.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 4 comments |
headers
Joel Sherrill | 3 Jul 2008 15:01
Gravatar

Re: Branching 4.9

Ralf Corsepius wrote:
> On Tue, 2008-07-01 at 13:24 -0500, Joel Sherrill wrote:
>
>   
>> There are a couple of tool issues on the table
>> so I expect there will be some tool revisions
>> along the way but yum makes that easy to deal
>> with.
>>     
>
> Like any RTEMS branch, branching will have to be accompanied by a
> version bump (4.9->4.10) on CVS-HEAD, which should be accompanied by a
> tool version bump.
>   
Yes.  And just to be clear I meant that I expected at least one
if not two updates to the 4.9 tools.  For updated SUSE support
and whatever becomes of the m68k/coldfire  multilib discussion.
> Ralf
>
>
>   

--

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

_______________________________________________
rtems-users mailing list
rtems-users@...
http://rtems.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 1 comment |
headers
Ralf Corsepius | 3 Jul 2008 15:32
Favicon

Re: Branching 4.9

On Thu, 2008-07-03 at 08:01 -0500, Joel Sherrill wrote:
> Ralf Corsepius wrote:
> > On Tue, 2008-07-01 at 13:24 -0500, Joel Sherrill wrote:
> >
> >   
> >> There are a couple of tool issues on the table
> >> so I expect there will be some tool revisions
> >> along the way but yum makes that easy to deal
> >> with.
> >>     
> >
> > Like any RTEMS branch, branching will have to be accompanied by a
> > version bump (4.9->4.10) on CVS-HEAD, which should be accompanied by a
> > tool version bump.
> >   
> Yes.  And just to be clear I meant that I expected at least one
> if not two updates to the 4.9 tools. 
Not unlikely, but the 4.9 tools actually are independent from the
branching the RTEMS source-tree.

To me, the critical point in branching is having rtems-4.10 toolchains
ready soon enough.

In an ideal world, they would be in place when the RTEMS source-tree is
being branched. In real world, this will take a finite amount of time
and which will cause a couple of temporary "hick-ups".

>  For updated SUSE support
As you know, SuSE-11.0 is a problem. 
SuSE's has changed it's rpm data format in a way such that
RH/Fedora-based distros can't read them anymore, and RH has made clear
they are not interested in adding support for SuSE's rpm changes in
released versions of Fedora nor RHEL. It's even unclear if future
RH/Fedora's rpm will be able to read SuSE rpms, because SuSE's work is
based on unreleased alpha versions of external libraries which so far do
not exist in Fedora/RH.

That said, ATM, it seems very unlikely, we will be able to provide
SuSE-11.0 based rpms any time soon. For now, I resort to feeding RTEMS's
SuSE-11.0 repos with SuSE-10.3 rpms.

> and whatever becomes of the m68k/coldfire  multilib discussion.
Yes, but that's one amongst several discussions affecting the
RTEMS-4.9's toolchain, independently from branching.

Ralf

_______________________________________________
rtems-users mailing list
rtems-users@...
http://rtems.rtems.org/mailman/listinfo/rtems-users
Permalink | Reply | 0 comments |

Gmane