Thanks Marc, I shall try the very first alternative for the time being. Cheers, Ramesh
> On 28 Oct 2015, at 10:10, Marc Welz <m...@ska.ac.za> wrote: > >> >> I use an ancient version of the core package, and here is the help on on >> tg_tap - no mention of a gateway here... >> >> tap_start(self, tap_dev, device, mac, ip, port) method of >> corr.katcp_wrapper.FpgaClient instance >> Program a 10GbE device and start the TAP driver. >> >> @param self This object. >> @param device String: name of the device (as in simulink name). >> @param tap_dev String: name of the tap device (a Linux identifier). If >> you want to destroy a device later, you need to use this name. >> @param mac integer: MAC address, 48 bits. >> @param ip integer: IP address, 32 bits. >> @param port integer: port of fabric interface (16 bits). >> >> Please note that the function definition changed from corr-0.4.0 to >> corr-0.4.1 to include the tap_dev identifier. > > Hmmm ... there are three options: > > * Try to set the gateway manually - do serveral wordreads of the gbe0 > register, and then write the gateway into the 0xc offset. This is > probably the quickest way of getting it going, but will only route > gateware traffic > > * try and extend tcpborphserver to add routing functionality, using > the code from the new tcpborphserver3 as a guide. That is some effort > and involves cross-compiling - and might also need a matching update > to the corr package > > * backport the mmap driver from roach2 to roach1 - that is the biggest > chunk of work and involves a bit of kernel hacking, and you > personally might not be up for it - but if anybody else on the list > has the energy it it would mean that the roach2 and roach1 userland > could be pretty much merged, and things like multicast support would > be available on roach1, in addition to the other fixes and features > (.fpg files, etc) > > regards > > marc > > >> >> Cheers, >> Ramesh >> >> >> >> >>
