Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - rory

Pages: [1]
1
Zodiac FX Firmware / Re: github build problem
« on: December 08, 2016, 12:03:51 AM »
Hi Paul,

Updated Makefile attached.

Regards
Rory

2
Zodiac FX Firmware / Re: github build problem
« on: December 07, 2016, 08:52:03 AM »
Update: I managed to get the firmware to build. I see Makefile hasn't been updated for 5 months, so I assume it has fallen out of step with ZodiacFX.cproj (last change 3 days ago). I have tried to update it to make it consistent with ZodiacFX.cproj, but it's quite possible I missed something. I can see now that telnet.[ch] is not so much missing as dropped (not required).

The lines I added to Makefile (I am assuming anyone familiar with make will know where these go):

 src/http.o \
 src/flash.o \

 src/ASF/sam/services/flash_efc/flash_efc.o \
 src/ASF/sam/drivers/efc/efc.o \


I removed references to telnet.[ch]:

 src/telnet.c \

 src/telnet.h \


Under the source code dependencies section, remove the dependencies for telnet.c and add the following for http.c:

src/http.c: \
 src/http.h \
 src/lwip/include/lwip/tcp.h \
 src/lwip/include/lwip/err.h \
 src/timers.h \
 src/command.h \
 src/trace.h \
 src/config/config_zodiac.h \
 src/openflow/openflow.h \
 src/eeprom.h \
 src/flash.h


I ran into one more problem when building - it appears the stack needs more RAM than is available. In the recent changes to ZodiacFX.cproj I found a change to the linker configuration, so I added this as well:

# Limit stack size
LDFLAGS += -Wl,--defsym,__stack_size__=0x1400


With this final change, the build succeeds and I get a new ZodiacFX.bin.

Paul, do you know of any other changes in ZodiacFX.cproj that need to be carried over to Makefile to bring it fully in sync?

Regards
Rory

3
Zodiac FX Firmware / github build problem
« on: December 07, 2016, 01:57:56 AM »
HI Paul,

Great to see v0.69 firmware out, and have successfully connected to an OpenDaylight controller using it.

I did notice when I tried to build v0.69 (on Ubuntu 14.04) with the current github repository source, it failed with an error relating to efc.h. I'd say it's a fairly minor thing, but for comparison I tried backing up to v0.68, which also failed for a different reason - no telnet.[ch] in the src/ directory. This is easily remedied by just bringing forward a copy from an earlier release - after this the build succeeds. So it seems somehow (for v0.68) telnet.[ch] went missing from the repo even though it is still technically required for the build to succeed. I imagine there is an additional similar issue in v0.69.

I think your copy may build successfully because you have all the files required locally, but some of these seem to have been removed or weren't added to the github repo. Would be very grateful if you could maybe do a clean clone in an empty directory from the github repo followed by make to see if you have the same problem, and maybe see what's missing in the repo.

Regards
Rory

4
Zodiac FX General / Sending FLOW_REMOVED on flow timeout
« on: September 20, 2016, 06:49:20 AM »
Hi Paul,

Using ryu as SDN controller in OpenFlow 1.0 mode, I get a connection from ZodiacFX as expected. In my handler for SWITCH_FEATURES I call a method to add a flow, using the following code:

Code: [Select]
mod = datapath.ofproto_parser.OFPFlowMod(
    datapath=datapath, cookie=0,
    command=ofproto.OFPFC_ADD, idle_timeout=20, hard_timeout=40,
    priority=0, buffer_id=ofproto.OFP_NO_BUFFER,
    out_port=ofproto.OFPP_NONE,
    flags=ofproto.OFPFF_SEND_FLOW_REM, match=match, actions=actions)
datapath.send_msg(mod)

The main thing to note here is the idle_timeout of 20 seconds and that I've set the flag to send FLOW_REMOVED when the flow expires.

As I don't have any traffic going through the switch at all, I expected that I would receive a FLOW_REMOVED message after 20 seconds but none appeared.

Taking a look at the code, I believe this is handled in of_helper.c: flow_timeouts(). I think the cause of the problem is the flag being compared is taken directly from the FLOW_MOD message (which is bid-endian) and read on a little-endian architecture. So even though the flag is set, the comparison fails.

To check this, I used ntohs():

Code: [Select]
if (flow_match[i].idle_timeout != OFP_FLOW_PERMANENT && flow_counters.lastmatch > 0 && ((totaltime/2) - flow_counters.lastmatch) >= ntohs(flow_match.idle_timeout))                       
{
    if (ntohs(flow_match.flags) &  OFPFF10_SEND_FLOW_REM) flowrem_notif10(i,OFPRR10_IDLE_TIMEOUT);

Now I receive a FLOW_REMOVED notification.

There is similar code further down in the function to which this could also apply.

Regards
Rory

Pages: [1]