Re: [riot-devel] Bringup procedure of a real device

[Bernhard Nägele]

Hello malo,
I love you! That was the missing link - I had totally forgotten the 
hardware address (MAC).
Everything seem now to work well - I have tested ping6 and udp - what a 
wonderful world!


Thanks, thanks, thanks!
Bernhard
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] wrong checksum

[malo]

Hello,

have simple setup with linux rpi2 + rf233 and RIOT os based node with rf233
on other end.
for the moment native linux supports only node so in fact have only 2 nodes
in the network.

on the riot side have
My address is ff02::1
My address is fe80::8a77:6655:4433:2212
My address is ff02::1:ff33:2212

the last one is solicited-node multicast - that is what I need.

The problem I'm seeing is that while pinging from linux side I'm
getting icmpv6: wrong checksum from _calc_csum in gnrc_icmpv6_demux while
trying to receive neighbor solicitation (icmpv6 type 135) from linux. I
know that I should get this message, but with correct checksum:)

I have seen this thread in the mailing list
https://lists.riot-os.org/pipermail/devel/2016-February/003433.html
which seems like is not working for Sebastian.

So the question is, if mentioned setup is supported by the RIOT/linux and
should work?
I'm just waiting for sniffer but maybe somebody can confirm that seen/have
it working.

There may be problem with my riot as well since I have ported RIOT to TI
compiler and using Code Composer Studio to build it. Not to mention that im
using currently unsupported 20bits msp430 cpu.

thanks in advance
wbr
malo
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Bringup procedure of a real device

[Bernhard Nägele]

Hello Malo,
thank you for this hint.
What else has to be changed in an IPv6 network?
Up to now I have only worked with IPv4 under Linux and there the only 
thing which was necessary to change was the

IP-address

Thanks a lot,
Bernhard
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Just another good reason not to implement printf() yourself

[malo]

Hello Oleg,

To make it really usable for alternative printf some cleanup in the
formatting strings would be desirable as well.
since at the mo there is the mix of direct formatting string with macros
like PRIi16...

wbr
malo



On 2 March 2016 at 11:47, Oleg Hahm  wrote:

> Hey Malo!
>
> On Wed, Mar 02, 2016 at 08:51:51AM +0100, malo wrote:
> > that would be even better indeed.
> > something like  #define LOG_PRINTF(...) LOG(LOG_PRINTF, __VA_ARGS__) and
> to
> > forbid to use printf?
>
> Hm, after thinking about this again, it's a bit more difficult, I guess.
> There
> are three types of actions where I see a need for printing strings:
> 1.) logging (something similar to syslog or journal on Linux)
> 2.) debugging
> 3.) some kind of CLI (e.g. our shell)
>
> 1.) should be covered by LOG_* from log.h.
> 2.) is covered by DEBUG()
> 3.) still needs a concept
>
> But in general, I agree that getting rid of printf() all over the code is
> desirable.
>
> Cheers,
> Oleg
> --
> The problem with a SQL security joke is that Sony don't get it.
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Bringup procedure of a real device

[Bernhard Nägele]

Sorry,
I have forgotten to post the forked theads:

ps
pid | name | stateQ | pri | stack ( used) | 
location
  1 | idle | pending  Q |  15 |   256 ( 148) | 
0x2298
  2 | main | running  Q |   7 |  1536 ( 792) | 
0x2398
  3 | pktdump  | bl rx_ |   6 |  1536 ( 256) | 
0x20001924
  4 | 6lo  | bl rx_ |   3 |  1024 ( 468) | 
0x20001f38
  5 | ipv6 | bl rx_ |   4 |  1024 ( 420) | 
0x2e60
  6 | udp  | bl rx_ |   5 |  1024 ( 296) | 
0x200026e4
  7 | at86rfxx | bl rx_ |   3 |  1024 ( 412) | 
0x29f0

| SUM  || |  7424 ( 2792)
>

Thanks for any hint!

Best regards,
Bernhard
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] exhausted Travis

[Oleg Hahm]

Hi Kaspar, Adam, Nick, Cenk, Sebastian (and everyone else who offered her/his
help here)!

On Fri, Mar 04, 2016 at 12:56:06PM +0100, Kaspar Schleiser wrote:
> On 03/04/2016 11:44 AM, smlng wrote:
> >> @all: Do we need a CI-TaskForce?
> I guess we implicitly have people working on it, so yeah, let's formalize.

I agree that this sounds like a good idea. I added an entry to the wiki page
[1]. So, we need two persons who would volunteer to shepherd this task force.
Kaspar, for starters, I listed you as a shepherd, please change this, if you
don't want to lead this task force.

Finally, I wanted to thank all of you who offered help or already contributed
(in terms of hardware resources, manpower, and consulting) for this badly
needed improvement! It's (once again) great to see the power and helpfulness
of this community. Big thanks!

Cheers,
Oleg

[1] https://github.com/RIOT-OS/RIOT/wiki/Task-Forces
-- 
/* When we have more time, we can teach the penguin to say 
 * "By your command" or "Activating turbo boost, Michael".
 */
linux-2.2.16/arch/sparc/prom/sun4prom.c


signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Bringup procedure of a real device

[Bernhard Nägele]

Hello everybody,
I try to bring up a wireless connection between two identical boards, 
both equiped with the at86rf233 module.
At first everything seems to be good - the source was compiled without 
failure, the process list shows all the threads needed for a working 
interface, but when I try to get a contact from one board to the other 
nothing happens.


Is there anyone who can give some hints about the best way to bring up a 
wireless connection with RIOT?


Here is what I have done:
First I flash the gnrc_networking example on both boards. The command 
showed exactly the same on both boards:


> ifconfig
Iface  7   HWaddr: 30:02  Channel: 26  Page: 0  NID: 0x23
   Long HWaddr: 88:77:66:55:44:33:22:12
   TX-Power: 0dBm  State: IDLE  max. Retrans.: 3  CSMA Retries: 4
   AUTOACK  CSMA  MTU:1280  HL:64  6LO  RTR  IPHC
   Source address length: 8
   Link type: wireless
   inet6 addr: ff02::1/128  scope: local [multicast]
   inet6 addr: fe80::8a77:6655:4433:2212/64  scope: local
   inet6 addr: ff02::1:ff33:2212/128  scope: local [multicast]

so far so good. Then I altered the ip-addresses on one board to:

> ifconfig
Iface  7   HWaddr: 30:02  Channel: 26  Page: 0  NID: 0x23
   Long HWaddr: 88:77:66:55:44:33:22:12
   TX-Power: 0dBm  State: IDLE  max. Retrans.: 3  CSMA Retries: 4
   AUTOACK  CSMA  MTU:1280  HL:64  6LO  RTR  IPHC
   Source address length: 8
   Link type: wireless
   inet6 addr: ff02::1/128  scope: local [multicast]
   inet6 addr: fe80::8a77:6655:4433:2214/64  scope: local
   inet6 addr: ff02::1:ff33:2214/128  scope: local [multicast]

then I tried to ping from one board to the other:

> ping6 fe80::8a77:6655:4433:2214

result: no output - the shell output stucks and I have to reboot

A ping to the own address delivers this output, but then the shell 
stucks again:


> ping6 fe80::8a77:6655:4433:2212
12 bytes from fe80::8a77:6655:4433:2212: id=83 seq=1 hop limit=64 time = 
4.892 ms


Is this the normal behaviour of RIOT that the command don't come back to 
the shell?
When the board stucks and I stop it with the debugger it seems the it 
cycles through the Idle-State.


Can anyone give me some hints what I'm doing wrong? How could it be 
found out that there is some traffic in the air?


Thanks a lot and best regards,
Bernhard
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] exhausted Travis

[DipSwitch]

>
> I'd say it is easily customizable, but ask me again after I've added
> support for distributed builds...


Sounds more like fun ;)
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] exhausted Travis

[Kaspar Schleiser]

Hey,

On 03/06/2016 08:19 AM, smlng wrote:
> Yeah, I perfectly understand ... I don't really _like_ Jenkins for its Java 
> "dependencies", too ;-) 
> All in all it works like charm, they even use Github integration ... somehow 
> ... but I know they have some trouble with that, too.
That was my feeling with the available systems.

I'm using buildbot a lot for CI for one of my clients, and it's a bitch
to customize.
I've set up strider a while ago, but at some point it didn't do what we
need, and bam! you have to sip through a nightmare forest of node.js code.

After that experience, I thought, all we need is something that watches
github and then queues builds, spawning a script to build stuff. Can't
be that hard.
So I write something from scratch. It is now a little less than 600
lines of python code, and works like a charm, with perfect github
integration.

I'd say it is easily customizable, but ask me again after I've added
support for distributed builds...

> IMHO a master-slave concept (as in Jenkins) with ability to add worker nodes 
> ... zzZzZZ ... Sweet dreams :) 

We're close! ;)

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Helping out with the CI situation

[Kaspar Schleiser]

Hey,

On 03/06/2016 05:28 AM, Adam Hunt wrote:
> With all the chatter about the CI situation lately I got to wondering if
> there might be some way I could help out. It sound like Kaspar has
> things under control with the new CI system but what about builders; are
> there enough CPU cycles available for the current rate of RIOT
> development, what about future development?

For now, it's a *huge* improvement over travis. As dipswitch already
wrote, build times depend a lot on cache hits.
A change somewhere outside of core can take less than 6 minutes to
build, a change to a core header like thread.h basically forces a full
cold-cache rebuild, taking >30 minutes.
Also, a build that is mostly cache-miss fills the ccache (currently set
at 150gb), and ccache has a weird pruning strategy, as the cache fill
rate goes close to 150g, then drops to <50gb, probably pruning more than
necessary.

Not using ccache at all takes ~22 minutes, so I'm considering either not
using ccache, or disabling it when certain conditions apply, like a diff
in core/include.

I think there's quite a bit room for improvement apart from that:

- the cached builds are SSD IO bound, averaging > 5k transactions per
sec, reading >100MB/s while writing ~20MB/s. Putting the whole cache in
memory seems expensive (anyone has spare 256gb in DDR3 DIMMS?), but a
RAID0 of SSD's would probably speed up things.

- the current build system is horribly inefficient.
While that doesn't matter for builds of one app for one MCU, when
building all ~4000 combinations, it matters.
Like, all RIOT's source files get stat'ed 4k times, every compiler check
gets called 4k times, every "(shell ls blah)", ...

I'm working on an improved build system, but it'll be a while until it
is production ready, if we even decide to step away from make

- less drastic would be a rewrite of compile_test.py + "buildtest" make
target, as that is not parallizing very well.
This is also needed for properly distributing the builds, as with the
current scripts, the smallest "chunk" is basically one MCU group, which
on a quad core box probably takes as much time to build as the worst
case 22minutes.

> Would it be possible for me and/or other members of the community to
> donate CPU time for use as builders?

Sure, as soon as we can make use of it!

> If CI builders could be deployed as VMs, or better yet, Docker images
> (lighter weight) would it be possible for people like me to help
> out?

I agree, Docker is the way to go here.

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel