testing and building for RPI

testing and building for RPI

[Michael Richardson]

I ordered the 802.15.4 module for PI's GPIO pins from:
  http://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio

got two of them last week, and I dug the RPI out from behind the
TV. (rasbmc.. nice idea, too slow for me)

I haven't yet gotten to caring if I got the right dtbs file,
as discussed here:
   http://forum.openlabs.co/general-oshw-discussion/6lowpan-kernel-on-rpi/

The current linux-wpan-next tree is based on 4.1-rc1, while it
seems that the rpi kernel patches are not merged yet, and rpi-4.0
is based upon 4.0.1.  I tried rebasing the rpi code upon 4.1-rc1
(with linux-wpan-next), but there were two non-trivial merge errors,
and even when I think I got them, some code fails to compile.
I could share that tree with someone if they wanted to help,
as RPI is gonna have to rebase upon 4.1 at some point.

So, I plan to try the opposite, which is to rebase linux-wpan-next
upon 4.0.1.  I imagine that perhaps there is a tree that I've missed
(or isn't tagged) which was before 4.1-rc1 came out... perhaps not.

The question is therefore: have there been any changes in linux-wpan-next
that got accepted into 4.1, and therefore would be missing if I do a
naive cherry-pick?

Will I have to do some dtbs hacking?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Re: testing and building for RPI

[Varka Bhadram]

On 05/12/2015 01:11 AM, Michael Richardson wrote:

> I ordered the 802.15.4 module for PI's GPIO pins from:
>   http://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio
>
> got two of them last week, and I dug the RPI out from behind the
> TV. (rasbmc.. nice idea, too slow for me)
>
> I haven't yet gotten to caring if I got the right dtbs file,
> as discussed here:
>    http://forum.openlabs.co/general-oshw-discussion/6lowpan-kernel-on-rpi/
>
> The current linux-wpan-next tree is based on 4.1-rc1, while it
> seems that the rpi kernel patches are not merged yet, and rpi-4.0
> is based upon 4.0.1.  I tried rebasing the rpi code upon 4.1-rc1
> (with linux-wpan-next), but there were two non-trivial merge errors,
> and even when I think I got them, some code fails to compile.
> I could share that tree with someone if they wanted to help,
> as RPI is gonna have to rebase upon 4.1 at some point.
>
> So, I plan to try the opposite, which is to rebase linux-wpan-next
> upon 4.0.1.  I imagine that perhaps there is a tree that I've missed
> (or isn't tagged) which was before 4.1-rc1 came out... perhaps not.
>
> The question is therefore: have there been any changes in linux-wpan-next
> that got accepted into 4.1, and therefore would be missing if I do a
> naive cherry-pick?
>
> Will I have to do some dtbs hacking?
>
You can directly use linux-wpan-next tree directly, which has the basic
support for RPI. No need to rebase it on rpi kernel.

Please see the blog: https://honk.sigxcpu.org/piki/hw/rpi6lowpan/

Thanks.
-- 
Varka Bhadram

Re: testing and building for RPI

[Christoffer Holmstedt]

2015-05-12 5:52 GMT+02:00 Varka Bhadram <varkabhadram@gmail.com>:
> On 05/12/2015 01:11 AM, Michael Richardson wrote:
>
>> I ordered the 802.15.4 module for PI's GPIO pins from:
>>   http://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio
>>
>> I haven't yet gotten to caring if I got the right dtbs file,
>> as discussed here:
>>    http://forum.openlabs.co/general-oshw-discussion/6lowpan-kernel-on-rpi/

hmm, old post I should probably answer it with my final solution which
is "just do a clean build and it works as intended".

>> Will I have to do some dtbs hacking?

At [1] I have the device tree patch I apply for RPi model B (i.e. not
B+). So if you have B+ just copy the information there to the correct
dts file.

>>
> You can directly use linux-wpan-next tree directly, which has the basic
> support for RPI. No need to rebase it on rpi kernel.

I use the bluetooth-next tree and more specifically a 4.1.0-rc1 commit
from late april on my two RPi model B. I haven't made any "release" of
my scripts [2] but they should all work at the moment from master
branch. If you are running Ubuntu 14.04 and have RPi model B just
follow the README and you should get a working kernel image and dtb
file built.

[1] https://github.com/christofferholmstedt/linux-wpan-dev/blob/master/scripts/linux_kernel_patches/0001-arm-dts-Update-RPi-B-dts-for-Openlabs-802.15.4-trans.patch
[2] https://github.com/christofferholmstedt/linux-wpan-dev

Don't hesitate to send me an email if the scripts don't work.
-- 
Christoffer Holmstedt

Re: testing and building for RPI

[Michael Richardson]

Varka Bhadram <varkabhadram@gmail.com> wrote:
    > You can directly use linux-wpan-next tree directly, which has the basic
    > support for RPI. No need to rebase it on rpi kernel.

    > Please see the blog: https://honk.sigxcpu.org/piki/hw/rpi6lowpan/

I finally got back to working on this.
Some minor edits:

you copy the kernel to the name rpi.img:
    scp bluetooth-next/arch/arm/boot/zImage ${TFTP_IP}:/tftpboot/rpi.img
but you tell the system to load zImage:
    dhcp ${kernel_addr_r} zImage

According to the manual, I can take my image from a different machine than
the dhcp server:

U-Boot> dhcp ${kernel_addr_r} 172.30.2.231:zImage
U-Boot> tftp ${fdt_addr_r} 172.30.2.231:${fdtfile}
U-Boot> bootz ${kernel_addr_r} - ${fdt_addr_r}
Bad Linux ARM zImage magic!

I'm still debugging what's going on...
I think the dhcp did not work correctly, as a md of the ${kernel_addr_r}
does not match a hexdump of the zImage that I built.

%file arch/arm/boot/zImage
arch/arm/boot/zImage: Linux kernel ARM boot executable zImage (little-endian)

{BTW: I will be bringing this code base to the ETSI 6lo plugfest in Yokohama
in November}

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Re: testing and building for RPI

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]


Varka Bhadram <varkabhadram@gmail.com> wrote:
    > You can directly use linux-wpan-next tree directly, which has the basic
    > support for RPI. No need to rebase it on rpi kernel.

    > Please see the blog: https://honk.sigxcpu.org/piki/hw/rpi6lowpan/

I have some edits for this; mostly unfortunate typos or copy/pastes.
I did get it working; my major stumbling block had to do with u-boot
apparently not really sending out multiple DHCPs messages.

The first goes out, and if the network is truly ready, it works.
Why wouldn't it be ready?  Cisco switches with STP enabled... plugging in a
trusty 8-port 100Mb/s stupid switch solved the problem, but cross-over cable to my
laptop showed me that it was really only sending out a single DHCP request,
not 8.  Once I put the "boot.scr" in place, it seems to boot very reliably,
but I haven't removed the 100Mb/s switch yet.

The suggested "agx" tree's defconfig didn't seem to enable the correct set of
kernel CONFIG options for the AT86*, etc. I'll post my whole recipe when I'm
back from the cottage.  You need to enable the IEEE802154, to then see
MAC802154 (and enable it) options before you'll see the AT86 drivers
available if you are using menuconfig.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
	

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: testing and building for RPI

[Michael Richardson]

Michael Richardson <mcr@sandelman.ca> wrote:
    >> Please see the blog: https://honk.sigxcpu.org/piki/hw/rpi6lowpan/

    > I have some edits for this; mostly unfortunate typos or copy/pastes.
    > I did get it working; my major stumbling block had to do with u-boot
    > apparently not really sending out multiple DHCPs messages.

    > The first goes out, and if the network is truly ready, it works.
    > Why wouldn't it be ready?  Cisco switches with STP enabled... plugging in a
    > trusty 8-port 100Mb/s stupid switch solved the problem, but cross-over cable to my
    > laptop showed me that it was really only sending out a single DHCP request,
    > not 8.  Once I put the "boot.scr" in place, it seems to boot very reliably,
    > but I haven't removed the 100Mb/s switch yet.

    > The suggested "agx" tree's defconfig didn't seem to enable the correct set of
    > kernel CONFIG options for the AT86*, etc. I'll post my whole recipe when I'm
    > back from the cottage.  You need to enable the IEEE802154, to then see
    > MAC802154 (and enable it) options before you'll see the AT86 drivers
    > available if you are using menuconfig.

After doing:
      make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- bcm2835_defconfig

I had to enable:
CONFIG_6LOWPAN=y
CONFIG_6LOWPAN_NHC=y
CONFIG_6LOWPAN_NHC_DEST=y
CONFIG_6LOWPAN_NHC_FRAGMENT=y
CONFIG_6LOWPAN_NHC_HOP=y
CONFIG_6LOWPAN_NHC_IPV6=y
CONFIG_6LOWPAN_NHC_MOBILITY=y
CONFIG_6LOWPAN_NHC_ROUTING=y
CONFIG_6LOWPAN_NHC_UDP=y
CONFIG_IEEE802154=y
CONFIG_IEEE802154_SOCKET=y
CONFIG_IEEE802154_6LOWPAN=y
CONFIG_MAC802154=y

CONFIG_IEEE802154_FAKELB=y
CONFIG_IEEE802154_AT86RF230=y
CONFIG_IEEE802154_MRF24J40=y
CONFIG_IEEE802154_CC2520=y

and then I had a kernel that saw my at86 device.  (I'm sure that the CC2520
and MRF24J40 enable was gratuitous).

I haven't yet interoperated with contiki; just ran out of time.

Re: testing and building for RPI

[Alexander Aring]

Hi Michael,

On Sun, Jul 26, 2015 at 10:14:49PM -0400, Michael Richardson wrote:
> 
> Michael Richardson <mcr@sandelman.ca> wrote:
>     >> Please see the blog: https://honk.sigxcpu.org/piki/hw/rpi6lowpan/
> 
>     > I have some edits for this; mostly unfortunate typos or copy/pastes.
>     > I did get it working; my major stumbling block had to do with u-boot
>     > apparently not really sending out multiple DHCPs messages.
> 
>     > The first goes out, and if the network is truly ready, it works.
>     > Why wouldn't it be ready?  Cisco switches with STP enabled... plugging in a
>     > trusty 8-port 100Mb/s stupid switch solved the problem, but cross-over cable to my
>     > laptop showed me that it was really only sending out a single DHCP request,
>     > not 8.  Once I put the "boot.scr" in place, it seems to boot very reliably,
>     > but I haven't removed the 100Mb/s switch yet.
> 
>     > The suggested "agx" tree's defconfig didn't seem to enable the correct set of
>     > kernel CONFIG options for the AT86*, etc. I'll post my whole recipe when I'm
>     > back from the cottage.  You need to enable the IEEE802154, to then see
>     > MAC802154 (and enable it) options before you'll see the AT86 drivers
>     > available if you are using menuconfig.
> 
> After doing:
>       make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- bcm2835_defconfig
> 
> I had to enable:
> CONFIG_6LOWPAN=y
> CONFIG_6LOWPAN_NHC=y
> CONFIG_6LOWPAN_NHC_DEST=y
> CONFIG_6LOWPAN_NHC_FRAGMENT=y
> CONFIG_6LOWPAN_NHC_HOP=y
> CONFIG_6LOWPAN_NHC_IPV6=y
> CONFIG_6LOWPAN_NHC_MOBILITY=y
> CONFIG_6LOWPAN_NHC_ROUTING=y
> CONFIG_6LOWPAN_NHC_UDP=y
> CONFIG_IEEE802154=y
> CONFIG_IEEE802154_SOCKET=y
> CONFIG_IEEE802154_6LOWPAN=y
> CONFIG_MAC802154=y
> 
> CONFIG_IEEE802154_FAKELB=y
> CONFIG_IEEE802154_AT86RF230=y
> CONFIG_IEEE802154_MRF24J40=y
> CONFIG_IEEE802154_CC2520=y
> 
> and then I had a kernel that saw my at86 device.  (I'm sure that the CC2520
> and MRF24J40 enable was gratuitous).
> 

congratulation. :-)

> I haven't yet interoperated with contiki; just ran out of time.
> 

Okay, I see also you use a builtin CONFIG_IEEE802154_FAKELB, this module
generates two virtual phys which can "transmit <-> receive" some data
between them - if the page/channel setting are the same. This module
will register two phys by default.

It's just a note, that you might have 3 phys registered.

- Alex

Re: testing and building for RPI

[Stefan Schmidt]

Hello.

On 21/07/15 18:37, Michael Richardson wrote:
> {BTW: I will be bringing this code base to the ETSI 6lo plugfest in Yokohama
> in November}

Really nice to hear that. Is there already a test spec or at least 
planned what will be covered?
I guess that would be at IETF 94? https://www.ietf.org/meeting/94/index.html

I would be interested in the results when running running linux-wpan 
against other implementations.

regards
Stefan Schmidt

Re: testing and building for RPI

[Guido Günther]

On Sat, Jul 25, 2015 at 02:27:21PM -0400, Michael Richardson wrote:
> 
> Varka Bhadram <varkabhadram@gmail.com> wrote:
>     > You can directly use linux-wpan-next tree directly, which has the basic
>     > support for RPI. No need to rebase it on rpi kernel.
> 
>     > Please see the blog: https://honk.sigxcpu.org/piki/hw/rpi6lowpan/
> 
> I have some edits for this; mostly unfortunate typos or copy/pastes.

I'd be happy to apply a patch. Source is at:

    https://git.sigxcpu.org/cgit/
    git://git.sigxcpu.org/git/piki.git

Cheers,
 -- Guido

Re: testing and building for RPI

[Michael Richardson]

Guido Günther <agx@sigxcpu.org> wrote:
    >> Varka Bhadram <varkabhadram@gmail.com> wrote: > You can directly use
    >> linux-wpan-next tree directly, which has the basic > support for
    >> RPI. No need to rebase it on rpi kernel.
    >>
    >> > Please see the blog: https://honk.sigxcpu.org/piki/hw/rpi6lowpan/
    >>
    >> I have some edits for this; mostly unfortunate typos or copy/pastes.

    > I'd be happy to apply a patch. Source is at:

    >     https://git.sigxcpu.org/cgit/ git://git.sigxcpu.org/git/piki.git

Thank you, I've checked it out, and I'll edit stuff and point you at a git
tree.

Re: testing and building for RPI

[Guido Günther]

On Fri, Jul 31, 2015 at 09:33:40AM -0400, Michael Richardson wrote:
> 
> Guido Günther <agx@sigxcpu.org> wrote:
>     >> Varka Bhadram <varkabhadram@gmail.com> wrote: > You can directly use
>     >> linux-wpan-next tree directly, which has the basic > support for
>     >> RPI. No need to rebase it on rpi kernel.
>     >>
>     >> > Please see the blog: https://honk.sigxcpu.org/piki/hw/rpi6lowpan/
>     >>
>     >> I have some edits for this; mostly unfortunate typos or copy/pastes.
> 
>     > I'd be happy to apply a patch. Source is at:
> 
>     >     https://git.sigxcpu.org/cgit/ git://git.sigxcpu.org/git/piki.git
> 
> Thank you, I've checked it out, and I'll edit stuff and point you at a git
> tree.

While going through stuff for the RPI2 I noticed several typos and
updated them at:

    https://honk.sigxcpu.org/piki/hw/rpi6lowpan/

It should be a bit less confusing now.
Cheers,
 -- Guido