Skip to contentSkip to conversation

at86rf233 on BeagleBone Black

DISCUSSION Alexander Aring 4 participants 14 messages Apr 3, 2015 – Apr 23, 2015 1 message not in the archive IEEE 802.15.4

lore
Share & tools
lore

Alexander Aring

author maintainer
#1 lore raw
In reply to a message not in the archive
Quoted 10 lines · Michael C. Cambria

Hi Alex,

Do you happen to have the pin mapping & device tree overlay needed for the Openlabs at86rf233 [0] to run on BeagleBone Black (BBB)?

I only have a few Pi's but do have a few spare BBB I could use. I'd rather not experiment an ruin either the BBB or at86rf233 if this information is known.

What I can give you are my dts entries for the BeagleBone (white), pinout should be the same:

&am33xx_pinmux {
	spi1_pins: pinmux_spi1_pins {
		pinctrl-single,pins = <
			0x190 0x33      /* mcasp0_aclkx.spi1_sclk, INPUT_PULLUP | MODE3 (special mode input for clock) */
			0x194 0x33      /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */
			0x198 0x13      /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
			0x19c 0x13      /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
			0x1a4 0x2f      /* mcasp0_fsr.gpio3_19, INPUT, PULL DISABLED | MODE7 */
		>;
	};
};
&spi1 {
	status = "okay";
	pinctrl-names = "default";
	pinctrl-0 = <&spi1_pins>;
	at86rf231@0 {
		compatible = "atmel,at86rf231";
		spi-max-frequency = <7500000>;
		reg = <0>;
		interrupts = <19 4>;
		interrupt-parent = <&gpio3>;
		reset-gpio = $YOUR_GPIO
		xtal-trim = /bits/ 8 <0xF>;
	};
};

I also changed the "xtal-trim" value. Now it's fit with the openlabs transceivers.

So you can see how my transceiver (I use the atben which have no reset pin) is connected to my BeagleBone. Check [0] to get pins for interrupt and reset pin.

I did the reset pin optional, please don't do that... normally then we need to run a reset of phy settings if the at86rf233 have no reset pin which is much unlikely (Okay, the atben have no reset pins...). I did not implement such a PHY reset handling yet. So please use some free gpio. This means you need to replace _maybe_ the interrupts and interrupt-parent property. What you really need to change is the $YOUR_GPIO property to something like [0] (fast googling which use the dt naming stuff).

I mean something like:

reset-gpio = <&gpio3 21 1>;

depends on you adaptation from openlabs at86rf233 to a BBB.

- Alex

[0] http://blog.savoirfairelinux.com/wp-content/uploads/2013/11/beaglebone_pins-table.png
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/gpio/gpio.txt

author maintainer
#2 lore raw

Hi,

I forgot something.

Quoted 15 lines · Alexander Aring
Quoted 10 lines · Michael C. Cambria

Hi Alex,

Do you happen to have the pin mapping & device tree overlay needed for the Openlabs at86rf233 [0] to run on BeagleBone Black (BBB)?

I only have a few Pi's but do have a few spare BBB I could use. I'd rather not experiment an ruin either the BBB or at86rf233 if this information is known.

What I can give you are my dts entries for the BeagleBone (white), pinout should be the same:

Quoted 8 lines
&am33xx_pinmux {
	spi1_pins: pinmux_spi1_pins {
		pinctrl-single,pins = <
			0x190 0x33      /* mcasp0_aclkx.spi1_sclk, INPUT_PULLUP | MODE3 (special mode input for clock) */
			0x194 0x33      /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */
			0x198 0x13      /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
			0x19c 0x13      /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
			0x1a4 0x2f      /* mcasp0_fsr.gpio3_19, INPUT, PULL DISABLED | MODE7 */

You should also declare your pinmux for your reset output pin here. The first magic values you will get from the am33xx datasheet, If I remember correctly that are some offset addresses.

But I am sure there exists also a lot of example outside in the www.

Quoted 4 lines
		>;
	};
};

- Alex

author maintainer
#3 lore raw
In reply to Alexander Aring

Hi,

Quoted 15 lines · Alexander Aring
Quoted 10 lines · Michael C. Cambria

Hi Alex,

Do you happen to have the pin mapping & device tree overlay needed for the Openlabs at86rf233 [0] to run on BeagleBone Black (BBB)?

I only have a few Pi's but do have a few spare BBB I could use. I'd rather not experiment an ruin either the BBB or at86rf233 if this information is known.

What I can give you are my dts entries for the BeagleBone (white), pinout should be the same:

Quoted 12 lines
&am33xx_pinmux {
	spi1_pins: pinmux_spi1_pins {
		pinctrl-single,pins = <
			0x190 0x33      /* mcasp0_aclkx.spi1_sclk, INPUT_PULLUP | MODE3 (special mode input for clock) */
			0x194 0x33      /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */
			0x198 0x13      /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
			0x19c 0x13      /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
			0x1a4 0x2f      /* mcasp0_fsr.gpio3_19, INPUT, PULL DISABLED | MODE7 */
		>;
	};
};

since somebody noticed me about several pinmux issues on this setup. I will update them now with:

&am33xx_pinmux {
        spi1_pins: pinmux_spi1_pins {
                pinctrl-single,pins = <
                        0x190 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcasp0_aclkx.spi1_sclk */
                        0x194 (PIN_INPUT | MUX_MODE3) /* mcasp0_fsx.spi1_d0 */
                        0x198 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* mcasp0_axr0.spi1_d1 */
                        0x19c (PIN_OUTPUT_PULLUP | MUX_MODE3) /* mcasp0_ahclkr.spi1_cs0 */
                        0x1a4 (PIN_INPUT | MUX_MODE7)  /* IRQ: mcasp0_fsr.gpio3_19 */
                        0x1ac (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* SLP_TR: mcasp0_ahclkx.gpio3_21 */
                        0x044 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* RESET: gpmc_a1.gpio1_17 */
                >;            
        };                    
};

This is what [0] describes at page 11, I hope. Can somebody report if it was successful to get openlabs with bb/bbw working?

- Alex

[0] http://www.atmel.com/images/atmel-8351-mcu_wireless-at86rf233_datasheet.pdf (1.3.2 Pull-up and Pull-down Configuration)

#4 lore raw
Quoted 1 line · Alexander Aring

Hi,

[deleted]

Quoted 17 lines

since somebody noticed me about several pinmux issues on this setup. I will update them now with:

&am33xx_pinmux {
         spi1_pins: pinmux_spi1_pins {
                 pinctrl-single,pins = <
                         0x190 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcasp0_aclkx.spi1_sclk */
                         0x194 (PIN_INPUT | MUX_MODE3) /* mcasp0_fsx.spi1_d0 */
                         0x198 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* mcasp0_axr0.spi1_d1 */
                         0x19c (PIN_OUTPUT_PULLUP | MUX_MODE3) /* mcasp0_ahclkr.spi1_cs0 */
                         0x1a4 (PIN_INPUT | MUX_MODE7)  /* IRQ: mcasp0_fsr.gpio3_19 */
                         0x1ac (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* SLP_TR: mcasp0_ahclkx.gpio3_21 */
                         0x044 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* RESET: gpmc_a1.gpio1_17 */
                 >;
         };
};
Quoted 6 lines

This is what [0] describes at page 11, I hope. Can somebody report if it was successful to get openlabs with bb/bbw working?

- Alex

[0] http://www.atmel.com/images/atmel-8351-mcu_wireless-at86rf233_datasheet.pdf (1.3.2 Pull-up and Pull-down Configuration)

On BBB, I'm using:

&am33xx_pinmux {
        spi1_pins: pinmux_spi1_pins {
                pinctrl-single,pins = <
                        0x190 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* 
mcasp0_aclkx.spi1_sclk */
                        0x194 (PIN_INPUT | MUX_MODE3) /* 
mcasp0_fsx.spi1_d0 */
                        0x198 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* 
mcasp0_axr0.spi1_d1 */
                        0x19c (PIN_OUTPUT_PULLUP | MUX_MODE3) /* 
mcasp0_ahclkr.spi1_cs0 */
                        0x1a4 (PIN_INPUT | MUX_MODE7)  /* IRQ: 
mcasp0_fsr.gpio3_19 */
                        0x1ac (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* 
SLP_TR: mcasp0_ahclkx.gpio3_21 */
                        0x044 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* RESET: 
gpmc_a1.gpio1_17 */
                >;
        };
};
&spi1 {
        status = "okay";
        pinctrl-names = "default";
        pinctrl-0 = <&spi1_pins>;
        at86rf231@0 {
                compatible = "atmel,at86rf231";
                spi-max-frequency = <7500000>;
                reg = <0>;
                interrupts = <19 4>;
                interrupt-parent = <&gpio3>;
                reset-gpio = <&gpio1 17>;
                sleep-gpio = <&gpio3 31>;
                xtal-trim = /bits/ 8 <0xF>;
        };
};

At probe time, I get

[    8.203574] /ocp/spi@481a0000/at86rf231@0: arguments longer than property
[    8.210963] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/spi@481a0000/at86rf231@0[0]'
[    8.210992] /ocp/spi@481a0000/at86rf231@0: arguments longer than property
[    8.218231] of_get_named_gpiod_flags: can't parse 'sleep-gpio' property of node '/ocp/spi@481a0000/at86rf231@0[0]'
[    9.830628] using random self ethernet address

Using e.g. "gpio1_17" doesn't compile, nor do other guesses. What syntax is expected for reset-gpio and sleep-gpio?

My kernel id bluetooth-next pulled Monday,

Linux beaglebone 4.0.0-rc7-244798-gf86c0e3 #1 SMP Wed Apr 15 10:34:12 EDT 2015 armv7l GNU/Linux

#5 lore raw
Quoted 64 lines · Michael C. Cambria
Quoted 1 line · Alexander Aring

Hi,

[deleted]

Quoted 24 lines

since somebody noticed me about several pinmux issues on this setup. I will update them now with:

&am33xx_pinmux {
         spi1_pins: pinmux_spi1_pins {
                 pinctrl-single,pins = <
                         0x190 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcasp0_aclkx.spi1_sclk */
                         0x194 (PIN_INPUT | MUX_MODE3) /*
mcasp0_fsx.spi1_d0 */
                         0x198 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /*
mcasp0_axr0.spi1_d1 */
                         0x19c (PIN_OUTPUT_PULLUP | MUX_MODE3) /*
mcasp0_ahclkr.spi1_cs0 */
                         0x1a4 (PIN_INPUT | MUX_MODE7)  /* IRQ:
mcasp0_fsr.gpio3_19 */
                         0x1ac (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
SLP_TR: mcasp0_ahclkx.gpio3_21 */
                         0x044 (PIN_OUTPUT_PULLUP | MUX_MODE7) /*
RESET: gpmc_a1.gpio1_17 */
                 >;
         };
};
Quoted 8 lines

This is what [0] describes at page 11, I hope. Can somebody report if it was successful to get openlabs with bb/bbw working?

- Alex

[0]
http://www.atmel.com/images/atmel-8351-mcu_wireless-at86rf233_datasheet.pdf
(1.3.2 Pull-up and Pull-down Configuration)

On BBB, I'm using:

&am33xx_pinmux {
        spi1_pins: pinmux_spi1_pins {
                pinctrl-single,pins = <
                        0x190 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcasp0_aclkx.spi1_sclk */
                        0x194 (PIN_INPUT | MUX_MODE3) /*
mcasp0_fsx.spi1_d0 */
                        0x198 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /*
mcasp0_axr0.spi1_d1 */
                        0x19c (PIN_OUTPUT_PULLUP | MUX_MODE3) /*
mcasp0_ahclkr.spi1_cs0 */
                        0x1a4 (PIN_INPUT | MUX_MODE7)  /* IRQ:
mcasp0_fsr.gpio3_19 */
                        0x1ac (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
SLP_TR: mcasp0_ahclkx.gpio3_21 */
                        0x044 (PIN_OUTPUT_PULLUP | MUX_MODE7) /*
RESET: gpmc_a1.gpio1_17 */
                >;
        };
};
Quoted 11 lines
&spi1 {
        status = "okay";
        pinctrl-names = "default";
        pinctrl-0 = <&spi1_pins>;
        at86rf231@0 {
                compatible = "atmel,at86rf231";
                spi-max-frequency = <7500000>;
                reg = <0>;
                interrupts = <19 4>;
                interrupt-parent = <&gpio3>;
                reset-gpio = <&gpio1 17>;

Here you are missing the initial state of the reset gpio pin status.

It has to be something like this:

		reset-gpio = <&gpio1 17 1>;
Quoted 1 line
                sleep-gpio = <&gpio3 31>;

Same here also...

		sleep-gpio = <&gpio3 31 1>;
Quoted 36 lines
                xtal-trim = /bits/ 8 <0xF>;
        };
};

At probe time, I get

[    8.203574] /ocp/spi@481a0000/at86rf231@0: arguments longer than
property
[    8.210963] of_get_named_gpiod_flags: can't parse 'reset-gpio'
property of node '/ocp/spi@481a0000/at86rf231@0[0]'
[    8.210992] /ocp/spi@481a0000/at86rf231@0: arguments longer than
property
[    8.218231] of_get_named_gpiod_flags: can't parse 'sleep-gpio'
property of node '/ocp/spi@481a0000/at86rf231@0[0]'
[    9.830628] using random self ethernet address

Using e.g. "gpio1_17" doesn't compile, nor do other guesses. What syntax is expected for reset-gpio and sleep-gpio?

My kernel id bluetooth-next pulled Monday,

Linux beaglebone 4.0.0-rc7-244798-gf86c0e3 #1 SMP Wed Apr 15 10:34:12 EDT 2015 armv7l GNU/Linux

Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Signature · 1 line
Varka Bhadram
#6 lore raw
Quoted 75 lines · Varka Bhadram
Quoted 61 lines · Michael C. Cambria
Quoted 1 line · Alexander Aring

Hi,

[deleted]

Quoted 24 lines

since somebody noticed me about several pinmux issues on this setup. I will update them now with:

&am33xx_pinmux {
          spi1_pins: pinmux_spi1_pins {
                  pinctrl-single,pins = <
                          0x190 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcasp0_aclkx.spi1_sclk */
                          0x194 (PIN_INPUT | MUX_MODE3) /*
mcasp0_fsx.spi1_d0 */
                          0x198 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /*
mcasp0_axr0.spi1_d1 */
                          0x19c (PIN_OUTPUT_PULLUP | MUX_MODE3) /*
mcasp0_ahclkr.spi1_cs0 */
                          0x1a4 (PIN_INPUT | MUX_MODE7)  /* IRQ:
mcasp0_fsr.gpio3_19 */
                          0x1ac (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
SLP_TR: mcasp0_ahclkx.gpio3_21 */
                          0x044 (PIN_OUTPUT_PULLUP | MUX_MODE7) /*
RESET: gpmc_a1.gpio1_17 */
                  >;
          };
};
Quoted 8 lines

This is what [0] describes at page 11, I hope. Can somebody report if it was successful to get openlabs with bb/bbw working?

- Alex

[0]
http://www.atmel.com/images/atmel-8351-mcu_wireless-at86rf233_datasheet.pdf
(1.3.2 Pull-up and Pull-down Configuration)

On BBB, I'm using:

&am33xx_pinmux {
         spi1_pins: pinmux_spi1_pins {
                 pinctrl-single,pins = <
                         0x190 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcasp0_aclkx.spi1_sclk */
                         0x194 (PIN_INPUT | MUX_MODE3) /*
mcasp0_fsx.spi1_d0 */
                         0x198 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /*
mcasp0_axr0.spi1_d1 */
                         0x19c (PIN_OUTPUT_PULLUP | MUX_MODE3) /*
mcasp0_ahclkr.spi1_cs0 */
                         0x1a4 (PIN_INPUT | MUX_MODE7)  /* IRQ:
mcasp0_fsr.gpio3_19 */
                         0x1ac (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
SLP_TR: mcasp0_ahclkx.gpio3_21 */
                         0x044 (PIN_OUTPUT_PULLUP | MUX_MODE7) /*
RESET: gpmc_a1.gpio1_17 */
                 >;
         };
};
Quoted 11 lines
&spi1 {
         status = "okay";
         pinctrl-names = "default";
         pinctrl-0 = <&spi1_pins>;
         at86rf231@0 {
                 compatible = "atmel,at86rf231";
                 spi-max-frequency = <7500000>;
                 reg = <0>;
                 interrupts = <19 4>;
                 interrupt-parent = <&gpio3>;
                 reset-gpio = <&gpio1 17>;

Here you are missing the initial state of the reset gpio pin status.

Quoted 35 lines

It has to be something like this:

		reset-gpio = <&gpio1 17 1>;
Quoted 1 line
                 sleep-gpio = <&gpio3 31>;

Same here also...

		sleep-gpio = <&gpio3 31 1>;
Quoted 26 lines
                 xtal-trim = /bits/ 8 <0xF>;
         };
};

At probe time, I get

[    8.203574] /ocp/spi@481a0000/at86rf231@0: arguments longer than
property
[    8.210963] of_get_named_gpiod_flags: can't parse 'reset-gpio'
property of node '/ocp/spi@481a0000/at86rf231@0[0]'
[    8.210992] /ocp/spi@481a0000/at86rf231@0: arguments longer than
property
[    8.218231] of_get_named_gpiod_flags: can't parse 'sleep-gpio'
property of node '/ocp/spi@481a0000/at86rf231@0[0]'
[    9.830628] using random self ethernet address

Using e.g. "gpio1_17" doesn't compile, nor do other guesses. What syntax is expected for reset-gpio and sleep-gpio?

My kernel id bluetooth-next pulled Monday,

Linux beaglebone 4.0.0-rc7-244798-gf86c0e3 #1 SMP Wed Apr 15 10:34:12 EDT 2015 armv7l GNU/Linux

With those changes the "arguments longer than property" message does go away. I now get this probe error:

[    9.815400] of_get_named_gpiod_flags: parsed 'reset-gpio' property of node '/ocp/spi@481a0000/at86rf231@0[0]' - stat)
[    9.815437] of_get_named_gpiod_flags: parsed 'sleep-gpio' property of node '/ocp/spi@481a0000/at86rf231@0[0]' - stat)
[   10.287193] at86rf230 spi1.0: Non-Atmel dev found (MAN_ID 00 00)
[   10.971416] at86rf230: probe of spi1.0 failed with error -22
author maintainer
#7 lore raw

On Fri, Apr 17, 2015 at 09:28:37AM -0400, Michael C. Cambria wrote:
...

Quoted 6 lines
Quoted 1 line
Quoted 1 line

With those changes the "arguments longer than property" message does go away. I now get this probe error:

Quoted 7 lines
[    9.815400] of_get_named_gpiod_flags: parsed 'reset-gpio' property of
node '/ocp/spi@481a0000/at86rf231@0[0]' - stat)
[    9.815437] of_get_named_gpiod_flags: parsed 'sleep-gpio' property of
node '/ocp/spi@481a0000/at86rf231@0[0]' - stat)
[   10.287193] at86rf230 spi1.0: Non-Atmel dev found (MAN_ID 00 00)
[   10.971416] at86rf230: probe of spi1.0 failed with error -22

Meanwhile I got private repsonse that somebody have a working openlabs module on a beaglebone, so it's _really_ possible! :-)

Your issue now seems that you reading zero's only on the spi bus. Please remember that we can't know your GPIO setup to the beaglebone pinout headers. Maybe your reset pin is always low and then the at86rf233 will not work. You need to know on which GPIO is reset pin/irq pin/sleep etc.

- Alex

#8 lore raw
Quoted 13 lines · Alexander Aring

On Fri, Apr 17, 2015 at 09:28:37AM -0400, Michael C. Cambria wrote:
....

Quoted 11 lines

With those changes the "arguments longer than property" message does go away. I now get this probe error:

[    9.815400] of_get_named_gpiod_flags: parsed 'reset-gpio' property of
node '/ocp/spi@481a0000/at86rf231@0[0]' - stat)
[    9.815437] of_get_named_gpiod_flags: parsed 'sleep-gpio' property of
node '/ocp/spi@481a0000/at86rf231@0[0]' - stat)
[   10.287193] at86rf230 spi1.0: Non-Atmel dev found (MAN_ID 00 00)
[   10.971416] at86rf230: probe of spi1.0 failed with error -22
Quoted 2 lines

Meanwhile I got private repsonse that somebody have a working openlabs module on a beaglebone, so it's _really_ possible! :-)

Thanks for all the help. My BBB now works with the openlabs radio. I had P9_28 & P9_30 in the the wrong holes (blush).

I still have those two messages at modprobe time, but the radio is probed.

[   11.346020] of_get_named_gpiod_flags: parsed 'reset-gpio' property of node '/ocp/spi@481a0000/at86rf233@0[0]' - status (0)
[   11.346056] of_get_named_gpiod_flags: parsed 'sleep-gpio' property of node '/ocp/spi@481a0000/at86rf233@0[0]' - status (0)
[   11.349282] at86rf230 spi1.0: Detected at86rf233 chip version 1

I'll test e..g ping6 to another BBB and Pi ASAP.

Here is what I appended to the existing am335x-boneblack.dts file:

&am33xx_pinmux {
        spi1_pins: pinmux_spi1_pins {
                pinctrl-single,pins = <
                        0x190 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* 
mcasp0_aclkx.spi1_sclk */
                        0x194 (PIN_INPUT | MUX_MODE3) /* 
mcasp0_fsx.spi1_d0 */
                        0x198 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* 
mcasp0_axr0.spi1_d1 */
                        0x19c (PIN_OUTPUT_PULLUP | MUX_MODE3) /* 
mcasp0_ahclkr.spi1_cs0 */
                        0x1a4 (PIN_INPUT | MUX_MODE7)  /* IRQ: 
mcasp0_fsr.gpio3_19 */
                        0x1ac (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* 
SLP_TR: mcasp0_ahclkx.gpio3_21 */
                        0x044 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* RESET: 
gpmc_a1.gpio1_17 */
                >;
        };
};
&spi1 {
        status = "okay";
        pinctrl-names = "default";
        pinctrl-0 = <&spi1_pins>;
        at86rf233@0 {
                compatible = "atmel,at86rf233";
                spi-max-frequency = <500000>;
                reg = <0>;
                interrupts = <19 4>;
                interrupt-parent = <&gpio3>;
                reset-gpio = <&gpio1 17 1>;
                sleep-gpio = <&gpio3 21 1>;
                xtal-trim = /bits/ 8 <0xF>;
        };
};

I'll post the J1 to BBB P9 pin mapping ASAP as well.

author maintainer
#9 lore raw

Hi,

Quoted 22 lines · Michael C. Cambria
Quoted 13 lines · Alexander Aring

On Fri, Apr 17, 2015 at 09:28:37AM -0400, Michael C. Cambria wrote:
....

Quoted 11 lines

With those changes the "arguments longer than property" message does go away. I now get this probe error:

[    9.815400] of_get_named_gpiod_flags: parsed 'reset-gpio' property of
node '/ocp/spi@481a0000/at86rf231@0[0]' - stat)
[    9.815437] of_get_named_gpiod_flags: parsed 'sleep-gpio' property of
node '/ocp/spi@481a0000/at86rf231@0[0]' - stat)
[   10.287193] at86rf230 spi1.0: Non-Atmel dev found (MAN_ID 00 00)
[   10.971416] at86rf230: probe of spi1.0 failed with error -22
Quoted 2 lines

Meanwhile I got private repsonse that somebody have a working openlabs module on a beaglebone, so it's _really_ possible! :-)

Thanks for all the help. My BBB now works with the openlabs radio. I had P9_28 & P9_30 in the the wrong holes (blush).

Quoted 8 lines

I still have those two messages at modprobe time, but the radio is probed.

[   11.346020] of_get_named_gpiod_flags: parsed 'reset-gpio' property of
node '/ocp/spi@481a0000/at86rf233@0[0]' - status (0)
[   11.346056] of_get_named_gpiod_flags: parsed 'sleep-gpio' property of
node '/ocp/spi@481a0000/at86rf233@0[0]' - status (0)
[   11.349282] at86rf230 spi1.0: Detected at86rf233 chip version 1

yes, I think that means "everything okay!" status 0 means success and the last message is a successful probing message of the at86rf230 driver.

So that's normal, if you don't want to printout these messages you need to change your loglevel.

- Alex

#10 lore raw
In reply to Michael C. Cambria
Quoted 17 lines · Michael C. Cambria
Quoted 15 lines · Alexander Aring

On Fri, Apr 17, 2015 at 09:28:37AM -0400, Michael C. Cambria wrote:
....

Quoted 13 lines

With those changes the "arguments longer than property" message does go away. I now get this probe error:

[    9.815400] of_get_named_gpiod_flags: parsed 'reset-gpio'
property of
node '/ocp/spi@481a0000/at86rf231@0[0]' - stat)
[    9.815437] of_get_named_gpiod_flags: parsed 'sleep-gpio'
property of
node '/ocp/spi@481a0000/at86rf231@0[0]' - stat)
[   10.287193] at86rf230 spi1.0: Non-Atmel dev found (MAN_ID 00 00)
[   10.971416] at86rf230: probe of spi1.0 failed with error -22
Quoted 5 lines
Quoted 2 lines

Meanwhile I got private repsonse that somebody have a working openlabs module on a beaglebone, so it's _really_ possible! :-)

Thanks for all the help. My BBB now works with the openlabs radio. I had P9_28 & P9_30 in the the wrong holes (blush).

Funny, that's pretty much the same type mistake that I made, before I got things working. I was the person Alexander referred to earlier.

I have it working on a pretty much vanilla 4.0 (a rebuild of RCN's deb package) on the BBB.

Quoted 1 line

I'll test e..g ping6 to another BBB and Pi ASAP.

Yeah, still have to test mine too. Started working on wiring another openlabs module into a Minnowboard Max, but that needs writing a board file...
I think I'll first just flash one of my CC2530 nodes for some simple tests.

Cheers

Thomas

#11 lore raw
Quoted 6 lines · Thomas B. Rücker
Quoted 1 line · Michael C. Cambria

I'll test e..g ping6 to another BBB and Pi ASAP.

Yeah, still have to test mine too. Started working on wiring another openlabs module into a Minnowboard Max, but that needs writing a board file...
I think I'll first just flash one of my CC2530 nodes for some simple tests.

I've tried two things:
- Receiving packets from cc2530 nodes running contiki in monitor mode. For some reason Wireshark complains about the FCS on some packets.
- Beaglebone White and a BB Black (same image, both DTBs patched) works just fine, #exactsteps below

Boards run a Debian Jessie image with a 4.0 Linux kernel built using RCN's tools. From what I can tell it's pretty low on patches, so ~vanilla. DT for both am335x-bone and am335x-boneblack modified to include a DTSI, similar to what Alex posted e.g. in <20150414150656.GB2179@omega>. DT for BBB disabled HDMI. wpan-tools from git.

Board1:

# iwpan dev wpan0 set pan_id 0xcafe
# ip link add link wpan0 name lowpan0 type lowpan
# ip -6 addr add 2001:db8::1/64 dev lowpan0
# ip link set wpan0 up
# ip link set lowpan0 up

Board2:

# iwpan dev wpan0 set pan_id 0xcafe
# ip link add link wpan0 name lowpan0 type lowpan
# ip -6 addr add 2001:db8::2/64 dev lowpan0
# ip link set wpan0 up
# ip link set lowpan0 up
# ping6 2001:db8::1 -c3
PING 2001:db8::1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=10.8 ms
64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=10.5 ms
64 bytes from 2001:db8::1: icmp_seq=3 ttl=64 time=10.5 ms

--- 2001:db8::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 10.526/10.633/10.814/0.175 ms

Tried SSH, works fine too.

If you are concerned with TCP performance you can modify parameters according to Alex:
#reduce tcp receive buf, will improve tcp connections
echo "127 512 1024" > /proc/sys/net/ipv4/tcp_rmem
echo "127 512 1024" > /proc/sys/net/ipv4/tcp_wmem

Note that this will affect the whole TCP stack. There might be a way to do it per interface.

Next: try to talk to the Contiki nodes properly

Cheers

Thomas

author maintainer
#12 lore raw
In reply to Michael C. Cambria

On Mon, Apr 20, 2015 at 02:04:48PM -0400, Michael C. Cambria wrote:
...

Quoted 8 lines
&spi1 {
        status = "okay";
        pinctrl-names = "default";
        pinctrl-0 = <&spi1_pins>;
        at86rf233@0 {
                compatible = "atmel,at86rf233";
                spi-max-frequency = <500000>;

now I detect this here. Why such low clock? You should use a 7.5 Mhz clock here not 500 Khz. I had some troubles with such a low clock and fragmentation handling.

Means:

change it to "spi-max-frequency = <7500000>;"

- Alex

#13 lore raw
Quoted 13 lines · Alexander Aring

On Mon, Apr 20, 2015 at 02:04:48PM -0400, Michael C. Cambria wrote:
....

Quoted 7 lines
&spi1 {
         status = "okay";
         pinctrl-names = "default";
         pinctrl-0 = <&spi1_pins>;
         at86rf233@0 {
                 compatible = "atmel,at86rf233";
                 spi-max-frequency = <500000>;

now I detect this here. Why such low clock? You should use a 7.5 Mhz clock here not 500 Khz. I had some troubles with such a low clock and fragmentation handling.

Quoted 5 lines

Means:

change it to "spi-max-frequency = <7500000>;"

- Alex

The openlabs blog post [0] used 500 Khz:

&spi {
    status = "okay";
    at86rf233@0 {
        compatible = "atmel,at86rf233";
        reg = <0>;
        interrupts = <23 1>;
        interrupt-parent = <&gpio>;
        reset-gpio = <&gpio 24 1>;
        sleep-tpio = <&gpio 25 1>;
        spi-max-frequency = <500000>;
    };
};

I've fixed both the Pi and BBB dts to use 7.5 Mhz as suggested.
I will also change "interrupts = <23 1>': to <23 4> on the Pi to get rid of the dmesg warning at next reboot.

"[ 7.810095] at86rf230 spi32766.0: Using edge triggered irq's are not recommended!"

Right now, I'm using the Pi to route over at86rf233 to the BBB to a local LAN off the BBB.

[0] http://openlabs.co/blog/archives/1-6LoWPAN-kernel-on-a-Raspberry-Pi

author maintainer
#14 lore raw
Quoted 16 lines · Michael C. Cambria
Quoted 13 lines · Alexander Aring

On Mon, Apr 20, 2015 at 02:04:48PM -0400, Michael C. Cambria wrote:
....

Quoted 7 lines
&spi1 {
        status = "okay";
        pinctrl-names = "default";
        pinctrl-0 = <&spi1_pins>;
        at86rf233@0 {
                compatible = "atmel,at86rf233";
                spi-max-frequency = <500000>;

now I detect this here. Why such low clock? You should use a 7.5 Mhz clock here not 500 Khz. I had some troubles with such a low clock and fragmentation handling.

Quoted 7 lines
Quoted 5 lines

Means:

change it to "spi-max-frequency = <7500000>;"

- Alex

The openlabs blog post [0] used 500 Khz:

I know and that's terrible...

This was tested when the driver was in a "bad" state.

- Alex