headers
Michael Bergandi | 3 Jan 2011 21:30
Picon

Package versioning requirements for an epk

Can someone explain/confirm the versioning requirements for an epk
package distribution?

From what I can tell, you used to be able to get away with
$PACKAGE/current, but it looks like ecosadmin.tcl might have been
updated to force proper verisioning. The package I am testing does use
'current' as the version directory in the epk, but the ecosadmin.tcl
tool is barking about the package not having a version directory.

Thanks,

--

-- 
Mike
Permalink | Reply | 3 comments |
headers
John Dallaway | 4 Jan 2011 09:33
Picon

Re: Package versioning requirements for an epk

Hi Michael

Michael Bergandi wrote:

> Can someone explain/confirm the versioning requirements for an epk
> package distribution?
> 
> From what I can tell, you used to be able to get away with
> $PACKAGE/current, but it looks like ecosadmin.tcl might have been
> updated to force proper verisioning. The package I am testing does use
> 'current' as the version directory in the epk, but the ecosadmin.tcl
> tool is barking about the package not having a version directory.

Using "current" as a version directory within a .epk file should work,
but the tool is intended for easy distribution of package _releases_ so
version directory names in the "v1_0" style make more sense in the
majority of cases.

For avoidance of doubt, the directory path fragments in ecos.db should
always point to the parent directory of the package version directory.

John Dallaway
eCos maintainer
Permalink | Reply | 1 comment |
headers
Sergei Gavrikov | 4 Jan 2011 15:35
Picon

Re: Package versioning requirements for an epk

Hi Michael,

On Mon, 3 Jan 2011, Michael Bergandi wrote:
> Can someone explain/confirm the versioning requirements for an epk
> package distribution?

The gory details about eCos 'Package Versioning':
http://ecos.sourceware.org/docs-latest/cdl-guide/package.versions.html

> From what I can tell, you used to be able to get away with
> $PACKAGE/current, but it looks like ecosadmin.tcl might have been
> updated to force proper verisioning. The package I am testing does use
> 'current' as the version directory in the epk, but the ecosadmin.tcl
> tool is barking about the package not having a version directory.

In no way I could reproduce this.

Sergei
Permalink | Reply | 0 comments |
headers
Michael Bergandi | 4 Jan 2011 20:22
Picon

Re: Package versioning requirements for an epk

John,

> Using "current" as a version directory within a .epk file should work,
> but the tool is intended for easy distribution of package _releases_ so
> version directory names in the "v1_0" style make more sense in the
> majority of cases.

Well, it only works if you know how to tar the package properly! ;)

I used "tar czvf dummy.epk . ", when I should have used "tar czvf
dummy.epk * " from the root of my package directory. Once I figured
that out, it works fine.

Thanks for confirming it should work with 'current' as the version directory.

--

-- 
Mike
Permalink | Reply | 0 comments |
headers
Michael Bergandi | 4 Jan 2011 22:32
Picon

How can I get the Linux Synthetic Target to use DHCP?

Hi all,

I am doing trying to do some testing and development on a network
application with the synthetic Linux target. I have managed to get the
network interface working with a static IP, but not with DHCP. DHCP
eventually just times out. I built the host tools and ecos on Ubuntu
10.04.1 LTS.

For reference, the following are the commands I used to build the
synthetic target:

$ mkdir synthbuild
$ cd synthbuild
$ ecosconfig new linux
$ ecosconfig add fileio net freebsd_net eth_drivers
$ ecosconfig tree
$ make

Here is a simple hello world network app that I am using to get it working:

/* this is a simple hello world program */
#include "stdio.h"
#include "network.h"
#include "cyg/kernel/kapi.h"

int main(void)
{

  init_all_network_interfaces();
(Continue reading)

Permalink | Reply | 4 comments |
headers
Sergei Gavrikov | 5 Jan 2011 10:45
Picon

Re: How can I get the Linux Synthetic Target to use DHCP?

On Tue, 4 Jan 2011, Michael Bergandi wrote:

> Hi all,
> 
> I am doing trying to do some testing and development on a network
> application with the synthetic Linux target. I have managed to get the
> network interface working with a static IP, but not with DHCP. DHCP
> eventually just times out. I built the host tools and ecos on Ubuntu
> 10.04.1 LTS.
> 
[snip]

> $ ./hello-net -io -t
> /usr/local/libexec/ecos/devs/eth/synth/ecosynth/current/ethernet.tdf
> 
> I eventually get a "BOOTP/DHCP failed on eth0" message.
> 
> Can someone help me fill in the missing pieces?

Hi Michael,

If you use an original 'ethernet.tdf' config file

That is

% egrep -v '(#|^\s*$)' $ECOS_REPOSITORY/devs/eth/synth/ecosynth/current/host/ethernet.tdf

synth_device ethernet {
    eth0 ethertap tap3 00:FE:42:63:84:A5
    max_buffer 32
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michael Bergandi | 5 Jan 2011 17:04
Picon

Re: How can I get the Linux Synthetic Target to use DHCP?

Sergei,

> If you use an original 'ethernet.tdf' config file
>
> That is
>
> % egrep -v '(#|^\s*$)' $ECOS_REPOSITORY/devs/eth/synth/ecosynth/current/host/ethernet.tdf
>
> synth_device ethernet {
>    eth0 ethertap tap3 00:FE:42:63:84:A5
>    max_buffer 32
> }
>
> Let's notice that *ethertap* tap3 interface is used there.

Yes, I get the tap3 created.

tap3      Link encap:Ethernet  HWaddr b2:13:57:48:9e:f3
          inet6 addr: fe80::b013:57ff:fe48:9ef3/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25 errors:0 dropped:0 overruns:0 frame:0
          TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:7650 (7.6 KB)  TX bytes:10945 (10.9 KB)

> Have you configured 'tap3' interface?

$ ifconfig tap3 up
$ ifconfig tap3
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sergei Gavrikov | 5 Jan 2011 18:02
Picon

Re: How can I get the Linux Synthetic Target to use DHCP?

On Wed, 5 Jan 2011, Michael Bergandi wrote:
> Sergei Gavrikov wrote:
> > Well, I can guide how to get it working on Ubuntu, but I doubt that
> > this list is the appropriate place for this.
> 
> That would be great.
> 
> I do think that this and probably the user list is the appropriate
> place to address usage issue resulting from deficiencies in
> documentation. Perhaps I can contribute some documentation once we get
> this worked out.

I catch the world :-)

Michael,

As you could see I redirected the thread to eCos Discuss List
http://ecos.sourceware.org/ml/ecos-discuss/2011-01/msg00013.html
and paste some SYNOPSIS on the subject, I hope (sure) you will get more
hands from community then.

Sergei
Permalink | Reply | 0 comments |
headers
Sergei Gavrikov | 10 Jan 2011 15:13
Picon

RedBoot's TFTP client and dumb TFTP servers

Hi

I tried to get working the QEMU's embedded TFTP server with RedBoot's
FTP client and the RedBoot's 'load' command always wept, -- "illegal
TFTP operation".

I did dig that QEMU's TFTP server has the very simple check for a
transfer mode:

slirp/tftp.c:314

    if (memcmp(&tp->x.tp_buf[k], "octet\0", 6) != 0) {
        tftp_send_error(spt, 4, "Unsupported transfer mode", tp);
        return;
    }

in a contrast, RedBoot sets a binary transfer as 

net/tftp_client.c:95

    fp = "OCTET";
    while (*fp) *cp++ = *fp++;
    *cp++ = '\0';

According the RFC 1350 'THE TFTP PROTOCOL (REVISION 2)'
http://www.ietf.org/rfc/rfc1350.txt

(look at the page 5, please)

the RedBoot's code does not anything wrong (even obsolete RFC 783
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gary Thomas | 10 Jan 2011 15:31
Favicon

Re: RedBoot's TFTP client and dumb TFTP servers

On 01/10/2011 07:13 AM, Sergei Gavrikov wrote:
> Hi
>
> I tried to get working the QEMU's embedded TFTP server with RedBoot's
> FTP client and the RedBoot's 'load' command always wept, -- "illegal
> TFTP operation".
>
> I did dig that QEMU's TFTP server has the very simple check for a
> transfer mode:
>
> slirp/tftp.c:314
>
>      if (memcmp(&tp->x.tp_buf[k], "octet\0", 6) != 0) {
>          tftp_send_error(spt, 4, "Unsupported transfer mode", tp);
>          return;
>      }
>
> in a contrast, RedBoot sets a binary transfer as
>
> net/tftp_client.c:95
>
>      fp = "OCTET";
>      while (*fp) *cp++ = *fp++;
>      *cp++ = '\0';
>
>
> According the RFC 1350 'THE TFTP PROTOCOL (REVISION 2)'
> http://www.ietf.org/rfc/rfc1350.txt
>
> (look at the page 5, please)
(Continue reading)

Permalink | Reply | 2 comments |

Gmane