Re: at86rf233 on BeagleBone Black

Re: at86rf233 on BeagleBone Black

[Alexander Aring]

On Fri, Apr 03, 2015 at 02:45:30PM -0400, Michael C. Cambria wrote:
> 
> 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

Re: at86rf233 on BeagleBone Black

[Alexander Aring]

Hi,

I forgot something.

On Fri, Apr 03, 2015 at 09:13:20PM +0200, Alexander Aring wrote:
> On Fri, Apr 03, 2015 at 02:45:30PM -0400, Michael C. Cambria wrote:
> > 
> > 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 */

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.

> 		>;
> 	};
> };
> 

- Alex

Re: at86rf233 on BeagleBone Black

[Alexander Aring]

Hi,

On Fri, Apr 03, 2015 at 09:13:20PM +0200, Alexander Aring wrote:
> On Fri, Apr 03, 2015 at 02:45:30PM -0400, Michael C. Cambria wrote:
> > 
> > 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 */
> 		>;
> 	};
> };
> 

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)

Re: at86rf233 on BeagleBone Black

[Michael C. Cambria]

On 04/14/2015 11:06 AM, Alexander Aring wrote:
> Hi,

[deleted]

> 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)

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

Re: at86rf233 on BeagleBone Black

[Varka Bhadram]

On 04/17/2015 02:38 AM, Michael C. Cambria wrote:
>
>
> On 04/14/2015 11:06 AM, Alexander Aring wrote:
>> Hi,
>
> [deleted]
>
>> 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)
>
> 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>;

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>;

>                 sleep-gpio = <&gpio3 31>;

Same here also...

		sleep-gpio = <&gpio3 31 1>;

>                 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
>
>
>
>
>
>
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Varka Bhadram

Re: at86rf233 on BeagleBone Black

[Michael C. Cambria]

On 04/16/2015 11:26 PM, Varka Bhadram wrote:
> On 04/17/2015 02:38 AM, Michael C. Cambria wrote:
>>
>> On 04/14/2015 11:06 AM, Alexander Aring wrote:
>>> Hi,
>> [deleted]
>>
>>> 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)
>> 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>;
> 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>;
>
>>                  sleep-gpio = <&gpio3 31>;
> Same here also...
>
> 		sleep-gpio = <&gpio3 31 1>;
>
>>                  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

Re: at86rf233 on BeagleBone Black

[Alexander Aring]

On Fri, Apr 17, 2015 at 09:28:37AM -0400, Michael C. Cambria wrote:
...
> >>
> 
> 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
> 

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

Re: at86rf233 on BeagleBone Black

[Michael C. Cambria]

On 04/17/2015 06:19 PM, Alexander Aring wrote:
> On Fri, Apr 17, 2015 at 09:28:37AM -0400, Michael C. Cambria wrote:
> ....
>> 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
>>
> 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.

Re: at86rf233 on BeagleBone Black

[Alexander Aring]

Hi,

On Mon, Apr 20, 2015 at 02:04:48PM -0400, Michael C. Cambria wrote:
> 
> 
> On 04/17/2015 06:19 PM, Alexander Aring wrote:
> >On Fri, Apr 17, 2015 at 09:28:37AM -0400, Michael C. Cambria wrote:
> >....
> >>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
> >>
> >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
> 

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

Re: at86rf233 on BeagleBone Black

["Thomas B. Rücker"]

On 04/20/2015 06:04 PM, Michael C. Cambria wrote:
>
> On 04/17/2015 06:19 PM, Alexander Aring wrote:
>> On Fri, Apr 17, 2015 at 09:28:37AM -0400, Michael C. Cambria wrote:
>> ....
>>> 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
>>>
>> 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.


> 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

Re: at86rf233 on BeagleBone Black

["Thomas B. Rücker"]

On 21/04/15 10:23, "Thomas B. Rücker" wrote:
> On 04/20/2015 06:04 PM, Michael C. Cambria wrote:
>> 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

Re: at86rf233 on BeagleBone Black

[Alexander Aring]

On Mon, Apr 20, 2015 at 02:04:48PM -0400, Michael C. Cambria wrote:
...
> 
> &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

Re: at86rf233 on BeagleBone Black

[Michael C. Cambria]

On 04/23/2015 05:37 AM, Alexander Aring wrote:
> On Mon, Apr 20, 2015 at 02:04:48PM -0400, Michael C. Cambria wrote:
> ....
>> &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

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

Re: at86rf233 on BeagleBone Black

[Alexander Aring]

On Thu, Apr 23, 2015 at 09:47:19AM -0400, Michael C. Cambria wrote:
> 
> 
> On 04/23/2015 05:37 AM, Alexander Aring wrote:
> >On Mon, Apr 20, 2015 at 02:04:48PM -0400, Michael C. Cambria wrote:
> >....
> >>&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
> 
> 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