headers
Kornel Mas³owski | 2 Jan 2004 13:31
Picon
Favicon

__NETDEVTAB__

How ecos initialize __NETDEVTAB__?
maslow
Permalink | Reply | 1 comment |
headers
Gary Thomas | 2 Jan 2004 13:35
Favicon

Re: __NETDEVTAB__

On Fri, 2004-01-02 at 05:31, Kornel Mas³owski wrote:
> How ecos initialize __NETDEVTAB__?

These entries are populated by using the NETDEVTAB_ENTRY macro.  
See examples in some of the ethernet low-level driver files, e.g. 
  .../packages/devs/eth/powerpc/fec/current/src/if_fec.c

--

-- 
Gary Thomas <gary <at> mlbassoc.com>
MLB Associates
Permalink | Reply | 0 comments |
headers
Bart Veer | 2 Jan 2004 19:40
Favicon

Re: serial port reading!

>>>>> " " == asif  <" <asif <at> inbox.net>> writes:

     > Hi Folks,

     > Iam trying to send data to serial port thru minicom (on
     > LINUX).Ultimately i my ecos read utility should read this.If i
     > use only one port for this how can i exactly do this as i have
     > one port on my target which is being occupied by GDB.Jonathan
     > some time back mentioned that stub would provide multiplexing
     > between diagnostic and debug ports..i have also read from
     > Jonathan's mail about simple thread usage instead of
     > cyg_user_start.

I suspect you have misunderstood what was meant by multiplexing. The
current code allows you to call printf() or other diagnostic functions
in this scenario. On the eCos side that data is intercepted, encoded
in appropriate packets as per the gdb protocol, and then sent out of
the serial port like any other gdb packet. On the host-side gdb
detects the packet type and will display the printf() output to the
user.

There is no mainstream support for having a separate application on
the host receiving data via the serial line, or sending data to the
target. The serial port is owned by gdb on the host-side, and by gdb
stubs on the target side. If your application needs to use the serial
line then gdb will have to use some other communication mechanism,
e.g. ethernet.

Having said that, there is one host-side program which may be a step
towards achieving what you are after: ser_filter. That program is
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Maurer | 5 Jan 2004 11:42
Picon
Favicon

Re: Anyone working on Keil MCB2114 (Philips LPC) port?

Hello Ashwin,

are there already any news about your port to LPC2106 ?
Is it possible to get a preview (tarball or something else) of your port ?

Greetings and thanks,

          Martin

----- Original Message -----

I have ported ecos to LPC2106 and will be shortly releasing the port after
completing the paper work.
It true it has a very small flash (120k) and ram (64k) but ecos works on it.

Regards,
Ashwin
----- Original Message -----
From: "Ren Jie" <netmars <at> citiz.net>
To: <ecos-devel <at> sources.redhat.com>
Sent: Wednesday, December 24, 2003 9:32 AM
Subject: Re: Anyone working on Keil MCB2114 (Philips LPC) port?

> I am wondering whether the Philips' LPC2xxx series ARM7TDMI chips are
capable of eCos.It has few RAM and Flash embedded.And what kind of tasks
could LPC2xxx do?
> Has anybody ported eCos to LPC2xxx?And how about its performance?
>
> Ren
> ----- Original Message -----
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daly, Jeffrey | 7 Jan 2004 22:34
Picon
Favicon

Flash mapping questions

Hi there, I'm in the process of implementing flash support for my
platform, Intel IXP2800 (XScale) and having some problems deciding how
to implement it correctly.  Basically my problem is that the IXP2800 has
2 modes of accessing the flash address space....(We only support 8 bit
flash)  The first mode is '32 bit' mode, where 4 byte accesses are made
and byte packed for each fetch in order to return an ARM instruction.
This is always done LE, in other words, for a fetch of an instruction
from address 0x0, address 0x0,0x1,0x2,0x3 are fetched and are packed in
the order: 0x3:0x2:0x1:0x0 to go back to the NPU.  This is fine for
running in both LE/BE mode, the code just needs to be programmed into
the flash correctly (may need byte swapping depending on the mode of
programming, XScale or external programmer)  The second mode of
operation is what we call 'byte read mode' where only a single byte
operation happens for a given access.  This is not a problem when
running code in LE mode (haven't done it yet, but I'm pretty confident)
However, as this is a networking platform and mostly needs to access
network data BE, the default support is for BE.

The issue is how the io/flash subsystem works.  The code is executing
out of flash (and thus in my system needs to be in '32 bit mode') until
the actual flash operations happen.  The actual flash manipulation code
is linked to run from RAM space.  Everything here is cool too, the
problem is that the '8 bit' mode of flash in order to program the flash
writes to the correct physical address requested, but when we go back to
32 bit mode, the endianness is always LE.  So for BE code, when we want
to say copy 4 bytes of flash from address 0x10000 to flash at address
0x0, let's say the data is 0x00112233, the 0x00 data is written to flash
byte address 0x0, 0x11 written to 0x11, etc.....  But as stated above,
when we switch back to 32 bit mode (in order to continue to be able to
execute from ROM) reading flash address 0x0 (memcmp() for example) will
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thomas Schrein | 9 Jan 2004 14:11

Re: [ECOS] Will gcc3.3 will work with eCos?.

Dear Ashwin,

I am new at the list and I am interested working with ecos on the LPC2106.

Can you give me some info about your port of ecos to the LPC2106 ?
What is the footprint ?
Where can I get the port ?
Did you ever compared ecos with rtems, especially regarding the LPC2106 ?

I had been working for 10 years in the sales management and coming now back to the
uC technics to continue my former job as desiger of uC Hw and SW. So I am
interessed in small footprint RTOS working in small but flexible HW.

My first project is a billing system for small aircrafts. The onboard unit has to
be small and cheap but should have also the oportunity to be expanded in the future.

ThanX in advane
Thomas

Date: Wed, 24 Dec 2003 16:20:56 +0530
Subject: Re: Anyone working on Keil MCB2114 (Philips LPC) port?
References: <3FD14DBD.2020804 <at> larwe.com> <20031223172932.GL30669 <at> arobas.net>
<001301c3c9d2$bb010ff0$6500a8c0 <at> marionb>

--------------------------------------------------------------------------------

I have ported ecos to LPC2106 and will be shortly releasing the port after
completing the paper work.
It true it has a very small flash (120k) and ram (64k) but ecos works on it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Schrein | 9 Jan 2004 14:12

Re: [ECOS] Will gcc3.3 will work with eCos?.

Dear Ashwin,

I am new at the list and I am interested working with ecos on the LPC2106.

Can you give me some info about your port of ecos to the LPC2106 ?
What is the footprint ?
Where can I get the port ?
Did you ever compared ecos with rtems, especially regarding the LPC2106 ?

I had been working for 10 years in the sales management and coming now back to the
uC technics to continue my former job as desiger of uC Hw and SW. So I am
interessed in small footprint RTOS working in small but flexible HW.

My first project is a billing system for small aircrafts. The onboard unit has to
be small and cheap but should have also the oportunity to be expanded in the future.

ThanX in advane
Thomas

Date: Wed, 24 Dec 2003 16:20:56 +0530
Subject: Re: Anyone working on Keil MCB2114 (Philips LPC) port?
References: <3FD14DBD.2020804 <at> larwe.com> <20031223172932.GL30669 <at> arobas.net>
<001301c3c9d2$bb010ff0$6500a8c0 <at> marionb>

--------------------------------------------------------------------------------

I have ported ecos to LPC2106 and will be shortly releasing the port after
completing the paper work.
It true it has a very small flash (120k) and ram (64k) but ecos works on it.
(Continue reading)

Permalink | Reply | 1 comment |
headers
zydla | 9 Jan 2004 16:24

ecos to IBM SPRUCE

Hi,

Has anyone ported ECOS to IBM SPRUCE (PPC750+CPC700)?
For variant HAL porting, I will start from the existing ppc60x package, but for platform HAL porting, still
no idea.
Please give some help, thanks.

zydla
1/9/2004 4:23PM
Permalink | Reply | 0 comments |
headers
Peter Dennett | 9 Jan 2004 20:37

Re: ecos to IBM SPRUCE

I am interested in eCos on
the PPC750 with CPC710 (SBS
CK3 board).  This is very much
like SPRUCE.  I am not sure 
how I can help but I will if
I can.  The group I am working
with is based out of CERN.  We
also have a SPRUCE and a custom
board based on the SPRUCE.

Peter

----- Original Message ----- 
From: "zydla" <zydla <at> swissinfo.org>
To: <ecos-devel <at> sources.redhat.com>
Sent: Friday, January 09, 2004 9:24 AM
Subject: ecos to IBM SPRUCE

> Hi,
> 
> Has anyone ported ECOS to IBM SPRUCE (PPC750+CPC700)?
> For variant HAL porting, I will start from the existing ppc60x package, but for platform HAL porting,
still no idea.
> Please give some help, thanks.
> 
> zydla
> 1/9/2004 4:23PM
Permalink | Reply | 0 comments |
headers
Aaron Richardson | 14 Jan 2004 21:42
Picon
Favicon

Re: Flash mapping questions

Are you starting with the Intel redboot version taken from 1_24?

It appears that Intel has changed at least their licensing at the following 
link from what I started from.

http://developer.intel.com/design/network/swsup/bootmonitor.htm

I started from the v1_24 redboot and was able to get roughly 80%-90% of the 
code ported so that it would work with ecos and would compile with the newer 
ecos/redboot.

I do remember that the flash was a problem.  And I dont think I fixed it 
fully.  I have since been moved to another project and the ecos port remains 
shelved currently.  I might have time to figure out what I did to the flash 
if you havent fixed it yet.

Are you planning on releasing your port back to ecos?

Aaron

On Wednesday 07 January 2004 03:34 pm, Daly, Jeffrey wrote:
> Hi there, I'm in the process of implementing flash support for my
> platform, Intel IXP2800 (XScale) and having some problems deciding how
> to implement it correctly.  Basically my problem is that the IXP2800 has
> 2 modes of accessing the flash address space....(We only support 8 bit
> flash)  The first mode is '32 bit' mode, where 4 byte accesses are made
> and byte packed for each fetch in order to return an ARM instruction.
> This is always done LE, in other words, for a fetch of an instruction
> from address 0x0, address 0x0,0x1,0x2,0x3 are fetched and are packed in
> the order: 0x3:0x2:0x1:0x0 to go back to the NPU.  This is fine for
(Continue reading)

Permalink | Reply | 0 comments |

Gmane