gmane.os.ecos.devel

Re: Updating lwip

Will Wagner — 2013-05-03T08:55:37

Hi Simon & John,

Thanks for the feedback, it is useful for understanding the existing 
changes.

So our plan for updating is as follows:
- move files according to ecos scheme. This is pretty straight forward, 
a number of files are moved and the ipv6 code (that doesn't work) is 
removed.
- drop all ppp changes and go with vanilla 1.4.1 ppp implementation
- drop lwip tests and keep the current ecos ones
- apply patches/changes made to 1.3.2 for ecos and all patches since to 
1.4.1
- follow upgrading instructions for lwip. This will involve a few new 
cdl options and changing a few functions.

After that is will just work :)

No idea how long this is going to take and it's not our top priority, 
fitting it in when we get the chance. Will post some patches once we 
have some progress.

Regards
Will

On 03/05/2013 09:49, Simon Kallweit wrote:

Re: Updating lwip

Simon Kallweit — 2013-05-03T08:49:14

Hi Will,
Hi John,

I'm not actively using eCos anymore since about three years, when I quit 
my job as an embedded developer and started studying computer science. I 
just thought I'd give a shout so you know.

As far as I can remember, the changes in the PPP codebase were primarily 
to get PPP running in sequential (non-threaded) mode, as the code in 1.3 
was not fit for the task and we used eCos on a pretty limited platform 
where we did not want to afford the overhead of using lwIP in threaded 
mode. Also there might have been some additions to allow writing PPP 
dumps in order to debug connection traces in wireshark, but I'm not a 
100% sure if that was commited to the eCos repository at all. In lwIP 
1.4 I think they refactored the PPP code to allow for proper handling in 
sequential mode, so my hacks would get obsolete. I remember that I have 
started porting a 1.4 release candidate back then, but never finished 
the port. I can dig out the sources if this is of any help, but maybe 
it's simpler to jus

Re: Updating lwip

John Dallaway — 2013-05-02T16:29:25

Hi Will

I am sure an upgrade of the eCos lwIP stack to the latest stable
upstream release would be welcomed by many eCos users.

On 01/05/13 19:37, Will Wagner wrote:


The lwIP PPP code currently checked-in to the eCos repository was
contributed by Simon Kallweit. This would explain the substantial
PPP-related changes in your code comparison. It was always the intention
to migrate to the official lwIP PPP sources over time. Ref:

  http://ecos.sourceware.org/ml/ecos-discuss/2010-01/msg00057.html

As with all imports, it is important to minimise changes to the upstream
code as far as possible. That way, future imports become much easier.

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

Re: Updating lwip

Michael Jones — 2013-05-02T13:19:46

Will,

I was not around when this was ported, but I have an LwIP application with SNMP, Telnet, FTP, and HTTP, and I would be willing to test and help with some debugging. I think getting this updated is very high value.

Mike



On May 1, 2013, at 12:37 PM, Will Wagner <will_wagner< at >carallon.com> wrote:

Updating lwip

Will Wagner — 2013-05-01T18:37:34

We are interested in updating to lwip 1.4.1. Has anyone already done any 
work on this?

Have started looking at the difference between upstream 1.3.2 and what 
is check in to ecos. There are quite a lot of differences, although most 
of them are trivial renaming.

Does anyone know what changes were made to the lwip source and why. In 
particular lost of the ppp code has had functions and variables renamed.

Any pointers for the porting process much appreciated.

Thanks
Will

Saving Global Pointer for SPARC

Les G. Miklosy — 2013-04-03T02:41:03

Greetings,

In my repository (1.0.7) it appears only mips includes code for saving 
and restoring the global pointer in hal_arch.h while other platforms do 
not. Is it necessary to save this pointer for SPARC? Does anybody have 
the SPARC code to do this? The macros are CYGARC_HAL_SAVE_GP() AND 
CYGARC_HAL_RESTORE_GP().

Thanks for directions.
Les

Re: FreeBSD TCP/IP stacks update to newer version possible?

Lambrecht Jürgen — 2013-03-29T09:13:27

Why not LwIP? It also has IPv6.
Mark, we are also still using freeBSD, and I still have to evaluate LwIP 
against our needs..
I think it will be more than that..
I don't know really the Kame project, but it was also for FreeBSD, a PC 
network stack. So it must be adapted to embedded use.
Here for example 2 issues that I discovered in the eCos freeBSD port 
that you don't see on a PC:
- by default the maximum fragmented packet size is 9kB (instead of 64kB)
- at ARP request timeout, only 1 packet is buffered. So if you are doing 
network bandwith testing with UDP messages, you will loose packets every 
5 minutes (default ARP timeout)

I was also thinking of doing something like that, but only to add VLAN 
tagging support to eCos.
But I can also use our switch chip to add VLAN tags as workaround. So 
that task is not so urgent anymore...

I am interested in helping, but I have only limited time.

Kind regards,
Jürgen

FreeBSD TCP/IP stacks update to newer version possible?

Max Seidenstuecker — 2013-03-28T16:03:26

Hello everyone,

for a research project our company is aiming to use eCos on the target
hardware. The major requirement is a working IPv6 implementation and
TLS/SSL. In eCos there is a FreeBSD-based TCP/IP stack and an OpenSSL
implementation available.

I see so many changes in the KAME project (FreeBSD IPv6 base) that I
am wondering if the version in eCos is stable enough. Has anyone got a
summary of the changes between 2001 and 2006 where the project
concluded? So we can see if an update is needed or worth doing.

What would the tasks be to update an already ported stack? I would
rate myself as a rookie in the area of network and OS related
programming. But from what I saw in the code it seems like there is an
compatibilty layer (eCos wrapper) provided for easy updates to the
code. Would a copy/paste job and some minor adjustments to the code do
the trick then?

Sincerely,
Max

AW: at91sam9x35

Richard Rauch — 2013-03-20T08:22:30

Hi Andrea,

I do not have a at91sam9x35 hardware on my place, but we have made ports already for Atmel AT91SAM9X25 and AT91SAM9G45.
This ports you are able to find at our Server: www.tiprom.itrgmbh.com

Specially the mentioned ports are located here:

 http://www.tiprom.itrgmbh.com/projects/ecos-on-atmel9g45
and
http://www.tiprom.itrgmbh.com/projects/ecos-on-atmel9x25

This ports differs a bit (because of different customer requests), but we are planning to merge them later on.
Anyway, you could save a lot of time, if you will base your work on this ports.
The peripherials of the Atmel microcontroller are mostly identically, so I assume, you could use most of the drivers without any change!

Best Regards

Richard


Richard Rauch
email: rrauch< at >itrgmbh.de
 
_______________________________________________

ITR GmbH Informationstechnologie Rauch 

web:   http://www.itrgmbh.de
email: info< at >itrgmbh.de
  
Büroaddresse:
Business Terminal West, 3. Stock
Muggenhofer Strasse 136
90429 Nürnberg
phone:+49 (0) 911 / 3

at91sam9x35

Grant Edwards — 2013-03-19T14:29:47

                                                            

Any time the received string and expected string differ that much in
length, it pretty much has to be baud rate.

Have you actually verified that eCos board's baud rate is correct?  By
'verify', I mean hook up an oscilloscope or logic analyzer to the eCos
board's TxD line and measure the baud rate.

--
Grant Edwards

Re: at91sam9x35

Chris Evans — 2013-03-19T04:41:19

Is your parity settings set right? 

Sent from my iPad

On Mar 18, 2013, at 3:25 PM, andrea_91 <andrea.falco1991< at >gmail.com> wrote:

at91sam9x35

andrea_91 — 2013-03-18T22:25:33

hi i'm doing eCos porting on board Atmel: at91sam9x35.
Well, now i did the memory mapping on plf_io.h file and then i created all
other file for dbg port. If i try to debug to see if the dbg port works, on
the putty terminal i see something similar to
"G!ÙV< at >Øt÷TÖåëÅõëõõÑfçfçnçf£Qü", but i'd wanted to write "Hello world\n". I
know that this is a possible error of baud rate but the baud rate on putty
and on ecos are correct(115200).
Have you got some ideas about?



--
View this message in context: http://sourceware-org.1504.n7.nabble.com/at91sam9x35-tp225742.html
Sent from the Sourceware - ecos-devel mailing list archive at Nabble.com.

Re: Cyg_Mutex::check_this() fails

jamescmaki — 2013-03-15T19:12:21

OK I didn't think that through fully.

if (( locked && owner == NULL )

The thread sees locked == true, gets rescheduled, then sees owner == NULL.



--
View this message in context: http://sourceware-org.1504.n7.nabble.com/Cyg-Mutex-check-this-fails-tp222044p225606.html
Sent from the Sourceware - ecos-devel mailing list archive at Nabble.com.

Re: Cyg_Mutex::check_this() fails

jamescmaki — 2013-03-15T17:56:19

Hi Rene,

At this point in the code the scheduler is not locked and the mutex is not
owned. This means that it is a bad idea to be looking at the internal state
of the mutex, i.e., calling CYG_ASSERTCLASS( mx, "Corrupt mutex").

I can reproduce this issue consistently now and I am testing a fix that
changes CYG_ASSERTCLASS to CYG_ASSERT. I am hoping that this will resolve
the problem instead of just moving the failed assert into Cyg_Mutex::lock().

However even if this does fix the problem, I am still wary. From what I can
see, locked and owner are never modified without locking the scheduler. This
means that they are both updated atomically. Because of this, when the
thread in  wait_inner() resumes it should see both of these variables in a
consistent state regardless of whether it holds a lock or not. I am
wondering if this can be explained by reordering and by delaying the check
until the scheduler is locked again it avoids this problem.

-James





--
View this message in context: http://sourceware-org.

IMPORTANT: sourceware.org hardware migration, MARCH 18..22

Frank Ch. Eigler — 2013-03-12T15:36:03

Hi -

Please be aware that **next week**, we will attempt to switch over the
hardware that serves sourceware.org and its aliases (gcc.gnu.org,
ecos.sourceware.org, cygwin.com, etc.) to newer & faster hardware
donated by Red Hat.

The plan is to take down network services next Monday around 14:00Z,
and gradually bring things back up on the new machine, one service at
a time, as quickly as possible.  Since this change involves switching
to a much younger OS and is complicated by many sourceware-specific
services, the overall outage may last up to several days.  We will
prioritize getting source code version control systems up first.

This announcement is being sent to those main mailing lists that have
been recently active; please feel free to share it.  You are welcome
to listen in on irc.freenode.net #overseers during the transition
period.  We appreciate your patience and hope that the new machines
will serve us all well.

- FChE

Re: Problem setting up an ISR for a K60 PORT

Michael Jones — 2013-02-19T14:51:26

I am creating all my threads from cyg_user_start. Each "task" (thread) has its own file and interface (psuedo OO). The overall app has multiple threads, one of them handling telemetry, and a higher priority one handling ALERTB problems using a PMBus (I2C). Once the interrupt works and the DSR is called, the DSR code will do an ARA (get addresses vis I2C), get STATUS_WORD for all address that ALERTed, and then send events so that the alert thread can respond by interacting over the PMBus. I just suspended the thread until I get the ISR to work, then I will add then event and processing code. 

I could do all the work in the DSR as long as I can call I2C from the DSR. However, I am porting an application from MQX and maintaining its structure, and in MQX I don't have a DSR, so in that version the ARA and read of STATUS_WORD is all in the task code.

I tried making some I2C calls from a DSR by using a timer, and the code locked up somewhere. I did not have time to track down the problem. It could have gotten i

Re: Problem setting up an ISR for a K60 PORT

Lambrecht Jürgen — 2013-02-19T08:33:49

Hi Michael,

first of all, I think your message should be sent to ecos-discuss 
instead (so I put it in cc).

I put some comments below - it is a long time ago I coded ISR/DSR, so I 
just looked to some working code of ours to compare.

On 02/19/2013 01:12 AM, Michael Jones wrote:
After our 'interrupt_create', we also have those calls (we use IRQ2 
instead of your PORTA):
   cyg_interrupt_attach(t_intrhandle);
   cyg_interrupt_configure(CYGNUM_HAL_INTERRUPT_IRQ2, TLV_FALSE, TLV_FALSE);
   cyg_interrupt_acknowledge(CYGNUM_HAL_INTERRUPT_IRQ2);
   cyg_interrupt_unmask(CYGNUM_HAL_INTERRUPT_IRQ2);

Why do you call 'cyg_thread_suspend...' ? I do not see code that creates 
a thread. And when I create a thread, I do cyg_thread_create(...); 
cyg_thread_resume(..);.

Why do you need a thread when your code is run by interrupts?
No need for:
   cyg_interrupt_mask(CYGNUM_HAL_INTERRUPT_IRQ2);
   cyg_interrupt_acknowledge(CYGNUM_HAL_INTERRUPT_IRQ2);
?
I guess you still need to add code here.
No need for this at the end:

Problem setting up an ISR for a K60 PORT

Michael Jones — 2013-02-19T00:12:55

I am struggling to setup an ISR/DSR for a PORT on the K60. My goal is to get an ISR/DSR when Pin 19 of PORTA transitions from high to low. This is pin PTA19 of the device.

My non-working code and complete code below.

What the code tries to do is setup PORTA PIN19 as input. Then take the PCR register and set the interrupt to work off a falling edge. 

Then create the ISR/DSR.

When I toggle the pin, nothing happens. 

FYI the hardware works with MQX, so I know the hardware is ok. I use it the same way under MQX where I get an ISR from a negative edge. And I have put a scope on it to make sure there is an edge. So I am quite sure the problem is the code.

This code was generated by trying to understand the Kinetis code, but things were not clear to me. Some macros use __pin to mean different things. So this is my best guess.

Does anyone know how to do this?

PORT SETUP CODE
================

    cyghwr_hal_kinetis_port_t *port_p;

CYGHWR_HAL_KINETIS_GPIO_PIN_DDR_IN(ALERT_PORT, ALERT_PIN);

    // Get addre

Cyg_Mutex::check_this() fails

René Schipp von Branitz Nielsen — 2013-02-13T11:35:24

...Sending this from my private mail account because the eCos mailserver
blocks mail containing confidentiality disclaimers, which I can't prevent
when sending from my work mail account... :( :(

--------------------oOo--------------------

Hello folks,

I have a condition variable, c, tied to a mutex, m, and used like this with
a FIFO, f:

void producer(void)
{
    cyg_mutex_lock(&m);
    copy_to_fifo(&f, some_data);
    cyg_cond_signal(&c);
    cyg_mutex_unlock(&m);
}

void consumer_thread(cyg_addrword_t data) {
    cyg_mutex_lock(&m);
    while (1) {
        while (fifo_empty(&f)) {
            cyg_cond_wait(&c);
        }

        // m is locked here.

        // Empty FIFO.
        while (!fifo_empty(&f)) {
            copy_from_fifo(&f, &some_data);
            cyg_mutex_unlock();

            // Do something with some_data
            ...

            cyg_mutex_lock();
        }
    }
}

The following description refers to line numbers of rev. 1.15 of mutex.cxx.

When the system is under heavy interru

Re: OpenRISC port

Tomas Frydrych — 2013-01-23T10:56:29

Hi,

On 23/01/13 09:36, Piotr Skrzypek wrote:

This is excellent news; I looked what could be done about updating the
ecos orc platform based on the OpenRISC fork about a year ago after the
excellent OpenRISC talk at FOSDEM, but was not able to find out who the
real authors were so that the copyright re-assignment could be done.



I am not a maintainer, but since these are two different architectures,
my inkling would be toward renaming the current architecture to
something like 'hal/openrisk1k' so that later on you can add
'hal/openrisk2k'.

Tomas

OpenRISC port

Piotr Skrzypek — 2013-01-23T09:36:33

Dear eCos Maintainers,

Together with my colleages from Ant Micro, we have updated the
OpenRISC port. We discovered that the OpenRISC HAL was not working
anymore, probably due to ABI change. We have also added few device
drivers. All changes to the code were introduced against the code in
eCos repository. This makes me believe there is no problem with
licensing.

The code still has some identified bugs that should be fixed. Once we
get it done, we would like to contribute the code to the eCos
repostory if possible.

There is one more problem and we seek your advice. Current OpenRISC
architecture is called OpenRISC1000 (aka or1k). There is an update
foreseen. The new architecture will be called OpenRISC2000 (aka or2k)
and it will not be backwards compatible. How should we structure the
HAL directory to take into account the update in the future?

Here is the note about the update:
http://antmicro.com/OpenSource/OpenRISC-eCos

We have a small wiki page that describes the port here:
http://opencores.org/or1k/EC