headers
Bart Veer | 10 Aug 2004 11:49
Favicon

virtual vectors problem

There is a problem with the current virtual vectors code and there are
two obvious ways of resolving it. I have a personal preference, but
some people may disagree.

In hal/common/current/src/hal_if.c we have the following code:

    //----------------------------------
    // Cache functions
    #ifdef CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_CACHE

    static void
    flush_icache(void *__p, int __nbytes)
    {
        CYGARC_HAL_SAVE_GP();
    #ifdef HAL_ICACHE_FLUSH
        HAL_ICACHE_FLUSH( __p , __nbytes );
    #elif defined(HAL_ICACHE_INVALIDATE)
        HAL_ICACHE_INVALIDATE();
    #endif
        CYGARC_HAL_RESTORE_GP();
    }

    static void
    flush_dcache(void *__p, int __nbytes)
    {
        CYGARC_HAL_SAVE_GP();
    #ifdef HAL_DCACHE_FLUSH
        HAL_DCACHE_FLUSH( __p , __nbytes );
    #elif defined(HAL_DCACHE_INVALIDATE)
        HAL_DCACHE_INVALIDATE();
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jani Monoses | 10 Aug 2004 15:51
Picon

redboot net_io stalls

Hello

I found a problem in redboot's net_io and have a workaround for it but a
proper fix would be better.
When redboot is sent a lot of TCP data its 4 pktbufs can get filled very
shortly: telnet to it and paste a big text to the prompt to see it hang.

The problem is that from time to time net_io calls net_io_flush which waits
until all queued outgoing data is sent.If flush happens when the 4 bufs are
occupied then communication will stall since redboot won't get the host's ACK
(the ACK packets are dropped not having a free pktbuf to stay in). And getc()
is not called to consume the pktbufs until the flush returns.

As a workaround I call __tcp_write instead of __tcp_write_block from flush
so it does not get stuck in __tcp_drain. But this means flush is not a real
flush...

This might be related to the HACK comment in tcp.c which says that sometimes
ACK's were lost.

Jani
Permalink | Reply | 0 comments |
headers
Mark Salter | 10 Aug 2004 16:55
Picon
Favicon

Re: virtual vectors problem

>>>>> Bart Veer writes:

> There is a problem with the current virtual vectors code and there are
> two obvious ways of resolving it. I have a personal preference, but
> some people may disagree.

...

> There are two obvious ways of fixing this situation. The first is to
> make the functions work, requiring some very simple changes. The
> second is to get rid of them completely. There is no eCos code which
> uses these virtual vector calls, and any such code would be better off
> #include'ing hal_cache.h and invoking the proper HAL macros directly.
> The only problem is if there is any non-eCos code, e.g. something in
> the libgloss/newlib world, that sits on top of RedBoot and expects
> these virtual vector functions to exist. Any such non-eCos code will
> never have worked properly in the past, but if we consider this to be
> part of the supported API then we should fix it.

I think that these were probably included because they were part
the old CygMon syscall services. I don't know of any apps that use
them (newlib/libgloss do not), so just removing them should be
fine.

--Mark
Permalink | Reply | 0 comments |
headers
Martin Laabs | 16 Aug 2004 03:43
Picon

loading ecos without bootloader

Hi,

I have a ixp board with a jtag debugger. Now I'd like to load
redboot into the ram and start it there. Because there is no
memory map loaded and the bit 31 of the configuration register
EXP_CNFG0 is not is not cleard and so on  I can't use
the RAM Version. I'd need a RAMRAM version. Is this posible?

Thank you
 Martin Laabs
Permalink | Reply | 1 comment |
headers
Stephan Gatzka | 16 Aug 2004 08:07
Picon
Favicon

Re: loading ecos without bootloader

Hi,

> I have a ixp board with a jtag debugger. Now I'd like to load
> redboot into the ram and start it there. Because there is no
> memory map loaded and the bit 31 of the configuration register
> EXP_CNFG0 is not is not cleard and so on  I can't use
> the RAM Version. I'd need a RAMRAM version. Is this posible?

Often you can configure your JTAG-Debugger to intialize the appropriate 
registers. It should be possible to use the RAM version then.

Greetings,

Stephan
--

-- 
Stephan Gatzka
TU Dresden, Fakultät für Informatik
Institut für Technische Informatik
Professur Mikrorechner
Hans-Grundig-Str. 25
01062 Dresden
email: Stephan.Gatzka <at> inf.tu-dresden.de
Tel.: 0351/463 38473
Fax.: 0351/463 38245
Permalink | Reply | 0 comments |
headers
Wayne Gemmell | 17 Aug 2004 00:04
Picon
Favicon

strcat breaks printf

Hi all

I am writing my first embedded software on ecos. I am also new to C I'm a REAL 
newb. My problem is with the following code...

<code>
 smsBody = malloc(161);
        tmpStr = malloc(100);
        reset_log_read();
        smsBody = "tcc";

        puts("Hello");
        for (j=0;j < 1;j++)
        {
                tmpTime = rec->timestamp;
        puts("Hello");
                sprintf(tmpStr,";%d:%f:%f\0",(unsigned int) tmpTime, 
(float)rec->la,(float) rec->lo);
                printf("tmp : %s\n",tmpStr);
                strcat(smsBody,tmpStr);
        }

        puts("Hello");
</code>

And my output is as follows...

Hello
Hello
tmp : ;78453:-2614.993896:2822.247070
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alex Schuilenburg | 17 Aug 2004 01:03
Favicon

Re: strcat breaks printf

Wayne Gemmell wrote:

> Hi all
> 
> I am writing my first embedded software on ecos. I am also new to C I'm a REAL 
> newb. My problem is with the following code...
> 
> <code>
>  smsBody = malloc(161);
>         tmpStr = malloc(100);
>         reset_log_read();
>         smsBody = "tcc";

This is your problem.  You are setting smsBody to point to a static 
string and throwing away the malloc'ed memory.  What you want is
           strcpy(smsBody,"tcc");

> 
>         puts("Hello");
>         for (j=0;j < 1;j++)
>         {
>                 tmpTime = rec->timestamp;
>         puts("Hello");
>                 sprintf(tmpStr,";%d:%f:%f\0",(unsigned int) tmpTime, 
> (float)rec->la,(float) rec->lo);
>                 printf("tmp : %s\n",tmpStr);
>                 strcat(smsBody,tmpStr);

This is where you overwrite the contents of what is in memory after the 
static "tcc" string.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Curtis Whitley | 17 Aug 2004 15:58

RE: strcat breaks printf

One other detail. Normally in C/C++, compiled text strings are automatically
null-terminated.
The code below contains this:  ";%d:%f:%f\0"
It could probably be written as: ";%d:%f:%f"
which would save a byte of "precious" memory!

One exception to this rule (if I recall correctly) is this (note array sizes
in brackets):

static const char is_null_terminated[11]     = { "0123456789" };
static const char is_not_null_terminated[10] = { "0123456789" };

Please correct me if I am wrong on this!!

-----Original Message-----
From: ecos-devel-owner <at> sources.redhat.com
[mailto:ecos-devel-owner <at> sources.redhat.com]On Behalf Of Alex
Schuilenburg
Sent: Monday, August 16, 2004 7:03 PM
To: wayneg <at> ananzi.co.za
Cc: ecos-devel <at> sources.redhat.com
Subject: Re: strcat breaks printf

Wayne Gemmell wrote:

> Hi all
>
> I am writing my first embedded software on ecos. I am also new to C I'm a
REAL
> newb. My problem is with the following code...
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alex Schuilenburg | 17 Aug 2004 17:31
Favicon

Re: strcat breaks printf

Curtis Whitley wrote:

> One other detail. Normally in C/C++, compiled text strings are automatically
> null-terminated.
> The code below contains this:  ";%d:%f:%f\0"
> It could probably be written as: ";%d:%f:%f"
> which would save a byte of "precious" memory!

That is correct.

> 
> One exception to this rule (if I recall correctly) is this (note array sizes
> in brackets):
> 
> static const char is_null_terminated[11]     = { "0123456789" };
> static const char is_not_null_terminated[10] = { "0123456789" };
> 
> Please correct me if I am wrong on this!!

You are correct - kindof.  By fixing the size you are pre-allocating how 
much static memory each will occupy. These are treated more as static 
arrays than as strings.  So
   static const char is_null_terminated[20]     = { "0123456789" };
will in fact occupy 20 characters, the last 10 being null as most 
compilers will pad the remainder of the fixed-size array with zeros. 
Hence you achieve the effect of null terminating the "strings".  I don't 
know if ANSI standards guarantee this for compliant compilers.

-- Alex
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wayne Gemmell | 17 Aug 2004 20:56
Picon
Favicon

Re: strcat breaks printf


> Curtis Whitley wrote:
> > One other detail. Normally in C/C++, compiled text strings are
> > automatically null-terminated.
> > The code below contains this:  ";%d:%f:%f\0"
> > It could probably be written as: ";%d:%f:%f"
> > which would save a byte of "precious" memory!
>i
Not to mention getting rid of irritating compiler warnings...

> > This is your problem.  You are setting smsBody to point to a static
> > string and throwing away the malloc'ed memory.  What you want is
> >            strcpy(smsBody,"tcc");
> >
> >>        puts("Hello");
> >>        for (j=0;j < 1;j++)
> >>        {
> >>                tmpTime = rec->timestamp;
> >>        puts("Hello");
> >>                sprintf(tmpStr,";%d:%f:%f\0",(unsigned int) tmpTime,
> >>(float)rec->la,(float) rec->lo);
> >>                printf("tmp : %s\n",tmpStr);
> >>                strcat(smsBody,tmpStr);
> >
> > This is where you overwrite the contents of what is in memory after the
> > static "tcc" string.

Thanks this fixed the problem. 

Cheers
(Continue reading)

Permalink | Reply | 0 comments |

Gmane