headers
Tue Brems Olesen | 2 Feb 2004 14:26
Picon
Picon

Porting eCos to Cogent CSB337


Hello,

Comping from a project where eCos was ported to a PowerPC 405cr based
prototype board, I am now starting to port eCos to Cogent's CSB337 board
(has an ARM920T CPU).

I found that the eCos port to the aaed2000 board at least has a similar
CPU, so i intend to look at that port as a starting point for the work

I was wondering if anyone on this list has ported (or, is porting) eCos
to the CSB337 board? If so, i'd appreciate to know.

Cheers,

--Tue

--

-- 
Tue Brems Olesen          | phone: +45 6133 5015 / +45 9633 0865
Strubjerg 32, 3. th       | mail: tue  at  aye  dot  dk
9400 Nørresundby, Denmark | homepage: http://www.aye.dk
Permalink | Reply | 0 comments |
headers
sebastien Couret | 2 Feb 2004 16:24
Picon

DHCP server package

Hi All,

I have ported the uDHCP DHCP server to eCOS. 

I think this can be usefull , because for the momemt there is no DHCP server 
package available with eCOS.

As told in the FAQ, my contribution got the form of an epk package under GPL.

I would like to have feedback, comments , bug reports  and so on , from all 
of you that could find it usefull.

On the other hand, Can someone of you explain me how can this package 
integrate the eCOS CVS ? and what is the process to follow ?
Attachment (DHCPelios.epk): application/x-gzip, 24 KiB
Permalink | Reply | 2 comments |
headers
Andrew Lunn | 2 Feb 2004 16:28
Picon

Re: DHCP server package

On Mon, Feb 02, 2004 at 04:24:36PM +0100, sebastien Couret wrote:
> Hi All,
> 
> I have ported the uDHCP DHCP server to eCOS. 
> 
> I think this can be usefull , because for the momemt there is no DHCP server 
> package available with eCOS.
> 
> As told in the FAQ, my contribution got the form of an epk package under GPL.
> 
> I would like to have feedback, comments , bug reports  and so on , from all 
> of you that could find it usefull.
> 
> On the other hand, Can someone of you explain me how can this package 
> integrate the eCOS CVS ? and what is the process to follow ?

GPL code cannot be integrated in the eCos CVS. The GPL license for
uDHCP would mean that all of eCos had to be distributed as GPL. This
would also mean that all of the application would also have to be
GPL. We don't want this, since people use eCos for writing commercial
applications. 

eCos uses a modified GPL license. The modification stops the GPL
spreading from the licensed file to other files. So this allows people
to do commercial applications with eCos.

You should make it clear to anybody you distribute your epk to that
its GPL and not the modified GPL used by the rest of eCos.

    Andrew
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alex Schuilenburg | 2 Feb 2004 17:16
Favicon

Re: Porting eCos to Cogent CSB337

Brems Olesen wrote:
> 
> Hello,
> 
> Comping from a project where eCos was ported to a PowerPC 405cr based
> prototype board, I am now starting to port eCos to Cogent's CSB337 board
> (has an ARM920T CPU).
> 
> I found that the eCos port to the aaed2000 board at least has a similar
> CPU, so i intend to look at that port as a starting point for the work
> 
> I was wondering if anyone on this list has ported (or, is porting) eCos
> to the CSB337 board? If so, i'd appreciate to know.

eCos has been ported to the CSB337 board and is available from us 
(eCosCentric) as an eCosPro release.  It is not available from anoncvs.

If you would like further information regarding eCosPro, see 
http://www.ecoscentric.com/ecos/ecospro.shtml.  If you would like 
additional or pricing information, email info <at> ecoscentric.com or call us 
(numbers below).

HTH
-- Alex

Managing Director / CEO                           eCosCentric Limited
http://www.ecoscentric.com/              The eCos and RedBoot experts
Phone: +44 1223 291156                         Fax:  +44 7779 032911

>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Larmour | 2 Feb 2004 18:10
Favicon

Re: DHCP server package

Andrew Lunn wrote:
> On Mon, Feb 02, 2004 at 04:24:36PM +0100, sebastien Couret wrote:
> 
>>Hi All,
>>
>>I have ported the uDHCP DHCP server to eCOS. 
>>
>>I think this can be usefull , because for the momemt there is no DHCP server 
>>package available with eCOS.
>>
>>As told in the FAQ, my contribution got the form of an epk package under GPL.
>>
>>I would like to have feedback, comments , bug reports  and so on , from all 
>>of you that could find it usefull.
>>
>>On the other hand, Can someone of you explain me how can this package 
>>integrate the eCOS CVS ? and what is the process to follow ?
> 
> 
> GPL code cannot be integrated in the eCos CVS. The GPL license for
> uDHCP would mean that all of eCos had to be distributed as GPL. This
> would also mean that all of the application would also have to be
> GPL. We don't want this, since people use eCos for writing commercial
> applications. 

What we can do though is make it available on the contribution download 
page, <http://ecos.sourceware.org/contrib.html>. If this is okay by you 
then mail me or Andrew the EPK off list and we'll put something up on that 
page with your name in lights!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tue Brems Olesen | 10 Feb 2004 23:47
Picon
Picon

Re: Porting eCos to Cogent CSB337


On Tue, 10 Feb 2004 22:37:12 +0000, 
"Michael Anburaj" <embeddedeng <at> hotmail.com> wrote:

> 
> Hi Tue,
> 
> Sorry for the late response.
> 
> My port or any other ARM9 port is a good starting point. Or better you
> can simple copy the whole thing & replace the platform specifics
> accordingly.
> 

Hi again,

I am currently working on the AAED2000 port, to make it run on the
CSB337 board. Though a port for the CSB337 board is available from
eCosCentric (and others), i'll try to make one myself, in the interest
of gaining experience with the porting process.

In a very simple setting, i've managed to get eCos to boot and run basic
applications. 

However, it seems that the AAED2000 board (and also the SMDK2401 board)
are using UARTs which are addressed differently from the ones on the
CSB337 board. In my setting, i'll be using the UARTs available on the
AT91RM9200 Chip. Today, i discovered that these UARTs are supported by
drives in the AT91 port of eCos. Hence, my current goal is to combine
the modified AAED2000 port and the AT91 drivers, and see how far that
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonathan Larmour | 11 Feb 2004 02:18
Favicon

Re: RAM disk

asif wrote:
> Hi ,
> 
> I would like to have RAM file system on my target.I want to create it
> dynamically for various reasons.am trying to use mount.but i couldn't
> succeed.can any one give info on this as to how to proceed.

Which aspect is created dynamically? ramfs ordinarily just allocates memory 
itself out of the heap, although the CDL settings can change that.

Have you seen the test in fs/ram/VERSION/tests/fileio1.c? That has an 
example of invoking mount if that helps.

Jifl
--

-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
Visit us at Embedded World 2004, Nürnberg, Germany, 17-19 Feb, Stand 12-449
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
Permalink | Reply | 0 comments |
headers
Jonathan Larmour | 11 Feb 2004 02:25
Favicon

Re: redboot set_comm_baud_rate question

Jani Monoses wrote:
> Hi
> I just want to make sure is the code below intended to be a retry
> of setting of the baudrate if the first attempt fails or a conditional
> setting of it if it's already at the requested value in which case it
> should have been a GETBAUD operation instead of the first SETBAUD.

Definitely looks like a buglet to me. Fixed as per below.

Jifl

Index: ChangeLog
===================================================================
RCS file: /cvs/ecos/ecos/packages/redboot/current/ChangeLog,v
retrieving revision 1.177
diff -u -5 -p -r1.177 ChangeLog
--- ChangeLog	4 Feb 2004 15:44:15 -0000	1.177
+++ ChangeLog	11 Feb 2004 01:25:07 -0000
 <at>  <at>  -1,5 +1,10  <at>  <at> 
+2004-02-11  Jonathan Larmour  <jifl <at> eCosCentric.com>
+
+	* src/main.c (set_comm_baud_rate): Get current rate with GETBAUD
+	not SETBAUD!
+
  2004-02-04  Gary Thomas  <gary <at> mlbassoc.com>

  	* cdl/redboot.cdl: Do not build with "common" interrupt stack
  	support.  This can cause problems when running programs (via
  	the "go" command) as interrupts will corrupt RedBoot's stack.
Index: src/main.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Larmour | 11 Feb 2004 02:30
Favicon

Re: ecos to IBM SPRUCE

zydla wrote:
> 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.

Sorry for the late reply, but since you intend to use the ppc60x variant
HAL it seems appropriate to base it on a PPC60x platform, like the csb281.

And of course don't forget the porting guide in the eCos HAL documentation.

Jifl
--

-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
Visit us at Embedded World 2004, Nürnberg, Germany, 17-19 Feb, Stand 12-449
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
Permalink | Reply | 0 comments |
headers
Jonathan Larmour | 11 Feb 2004 03:05
Favicon

Re: Flash mapping questions

Gary Thomas wrote:
> [CYGSEM_IO_FLASH_READ_INDIRECT conflicts with CYGBLD_BUILD_REDBOOT_WITH_ZLIB ]
> Having "zlib" included let's you keep compressed images in FIS.  It's
> also necessary if you want to download compressed images and have
> RedBoot uncompress them on the fly. It's probably not too hard to get
> around this problem, I just didn't have the time when I added the
> "indirect" support.

[Old mail I know, I'm just going through my old stuff a bit]

This particular port aside, not supporting compressed FIS images is fair 
enough, but preventing compressed download should be easy to avoid, as per 
the attached patch. It's so easy I feel I'm missing something? Let me know 
if not and I'll commit :-).

Jifl

2004-02-11  Jonathan Larmour  <jifl <at> eCosCentric.com>

	* cdl/redboot.cdl: Bring CYGNUM_REDBOOT_LOAD_ZLIB_BUFFER under
	CYGBLD_BUILD_REDBOOT_WITH_ZLIB. Add CYGPRI_REDBOOT_ZLIB_FLASH to
	control whether decompression can be used with flash images.
	* src/flash.c: Use CYGPRI_REDBOOT_ZLIB_FLASH instead of
	CYGPKG_COMPRESS_ZLIB.
	* src/load.c: Use CYGBLD_BUILD_REDBOOT_WITH_ZLIB in place of
	CYGPKG_COMPRESS_ZLIB.
	* src/main.c: only set fis_zlib_common_buffer if
	CYGPRI_REDBOOT_ZLIB_FLASH.

Index: cdl/redboot.cdl
(Continue reading)

Permalink | Reply | 4 comments |

Gmane