testing and building for RPI

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  [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [

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

2015-05-12 5:52 GMT+02:00 Varka Bhadram <[email protected]>:

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

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.

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

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  [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [

Hello.

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

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  [ 
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [ 

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.

Hi Michael,

congratulation. :-)

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

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

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