| Message ID | 20170709182728.kam75j2kpt36ulju@omega (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
hi, I figured out that you can disable the shadow registers (in the regmap dir) by writing "y" to "cache_bypass" by the command "echo y > cache_bypass", ore by setting the third char to y (in the corresponding line ) in the file access but this you cannot do in user space. I've checked it out that if you write a "y" to "cache_bypass" that the drive reads all defined registers (seen in "range") from the device. The value of ref 0x0C stays unchanged. I would be very grateful if you could use you connections to Atmel. Of cause you can refer to my proved logic-dump and pcap file in my dropbox regards Sebastian Balz Am 09.07.2017 um 20:27 schrieb Alexander Aring: > Hi, > > On Sun, Jul 09, 2017 at 06:22:29PM +0200, Balz wrote: >> Hi, >> I do not use the SPIDEV fragment, so I've deleted it out of the Overlay. >> The data sheet of the ATREB233 says that the SPI cut get up to 7.5 MHZ but >> decreasing it does have no positive effects. >> My SPI Configuration is specified for the BBB. >> > mh, ok. 7Mhz could be too high, I expierenced bad behaviours on RPI with > openlabs board which has no jumpwire etc. setup. > >> I do think that released the RX_Save_MODE means, that the frame buffer is >> not any more protected, so that the hardware can override the FrameBuffer. >> I've checked the value of register 0x0c periodically but it does not change >> its value while operating. But i have no idea how to make the regmap >> volatile. >> > You need to have it volatile otherwise the read will not trigger a register > read on the bus. Maybe there exists a runtime solution to add it via debugfs > to volatile registers. I know this way only, you can run the cat on > registers afterwards and it should trigger a register read. Acutally you > could check it on you logic analyzer (but there should be a lot of > register read, search for 0x0c). > > Here is the diff, very easy (recompile kernel and boot it, sure... or > just at86rf230.ko replacement): > > diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c > index 548d9d026a85..858b07a4febc 100644 > --- a/drivers/net/ieee802154/at86rf230.c > +++ b/drivers/net/ieee802154/at86rf230.c > @@ -311,6 +311,7 @@ at86rf230_reg_volatile(struct device *dev, unsigned int reg) > case RG_VREG_CTRL: > case RG_PLL_CF: > case RG_PLL_DCU: > + case RG_TRX_CTRL_2: > return true; > default: > return false; > > ---------- > > I reread the datasheet and I think this will not happen, that we lost > RX_SAFE_MODE... because the datasheet [0] shows how to setup enable > "receive mode" inclusive address filtering etc. there is the > RX_SAFE_MODE setting mentioned. That says to me: we need it for hardware > init once OR when going into some RX state of at86rf233... but what an > ugly behaviour that it will drop RX_SAFE_MODE when changing state - > another question: would we always set the address filtering again then? > I don't know... > > I maybe can ask "again" Atmel support for help me, but this support > interface of them are very ugly and I only got reponse the last time, > because somebody on the list had some support contract with them (I > think). > > Also [0] for running in promiscuous mode (page 59) doesn't mention > anything about RX_SAFE_MODE! So question would be if RX_SAFE_MODE > working in promiscuous mode? Or does the hardware doesn't support it... > in this configuration. > > The datasheet doesn't contain the information which I need to know... I > need the firmware of this chip >:-( > > - Alex > > [0] http://www.atmel.com/images/Atmel-8351-MCU_Wireless-AT86RF233_Datasheet.pdf (PDF PAGE 56) -- 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
Hi, On Mon, Jul 10, 2017 at 10:39:34AM +0200, Balz wrote: > hi, > > I figured out that you can disable the shadow registers (in the regmap dir) > by writing "y" to "cache_bypass" by the command "echo y > cache_bypass", ore > by setting the third char to y (in the corresponding line ) in the file > access but this you cannot do in user space. > > I've checked it out that if you write a "y" to "cache_bypass" that the drive > reads all defined registers (seen in "range") from the device. > The value of ref 0x0C stays unchanged. > > I would be very grateful if you could use you connections to Atmel. > Of cause you can refer to my proved logic-dump and pcap file in my dropbox > tried it, gave up... seems to be everything has changed because microchip & atmel stuff. You could try it... You didn't answered my other question: Do you transmit over monitor interface? Also I don't have such issues with RPi, do you have some RPi around and use _mainline_ Linux kernel. Very important _mainline_. - Alex -- 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
Hi,
thank you as far.
i do have next Thursday the possibility to get a rpi.
I'am sorry.
yes i'am using it as monitor.
the configuration is :
sudo iwpan "$wpan" del
sudo iwpan "$phy" interface add "$wpan" type monitor
sudo iwpan "$phy" set channel 0 "$channel"
sudo ifconfig "$wpan" up
with $wpan == wpan0, $phy == phy0 and $channel = 26
So i try to get in touch with Atmel/Micochip and report the result.
Best Regards
Sebastian Balz
Am 10.07.2017 um 11:40 schrieb Alexander Aring:
> Hi,
>
> On Mon, Jul 10, 2017 at 10:39:34AM +0200, Balz wrote:
>> hi,
>>
>> I figured out that you can disable the shadow registers (in the
regmap dir)
>> by writing "y" to "cache_bypass" by the command "echo y >
cache_bypass", ore
>> by setting the third char to y (in the corresponding line ) in the file
>> access but this you cannot do in user space.
>>
>> I've checked it out that if you write a "y" to "cache_bypass" that
the drive
>> reads all defined registers (seen in "range") from the device.
>> The value of ref 0x0C stays unchanged.
>>
>> I would be very grateful if you could use you connections to Atmel.
>> Of cause you can refer to my proved logic-dump and pcap file in my
dropbox
>>
> tried it, gave up... seems to be everything has changed because
> microchip & atmel stuff. You could try it...
>
> You didn't answered my other question:
>
> Do you transmit over monitor interface?
>
> Also I don't have such issues with RPi, do you have some RPi around and
> use _mainline_ Linux kernel. Very important _mainline_.
>
> - Alex
--
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
Hi, On Mon, Jul 10, 2017 at 01:50:30PM +0200, Balz wrote: > Hi, > > thank you as far. > > i do have next Thursday the possibility to get a rpi. > > I'am sorry. > yes i'am using it as monitor. > the configuration is : > sudo iwpan "$wpan" del > sudo iwpan "$phy" interface add "$wpan" type monitor > sudo iwpan "$phy" set channel 0 "$channel" > sudo ifconfig "$wpan" up > > with $wpan == wpan0, $phy == phy0 and $channel = 26 > ok. But do you transmit over monitor interface or not? It could be that the transceiver overwrites framebuffer with tx frames. (only after some xxx times when going to TX_ON isn't possible, it will do some force change). > So i try to get in touch with Atmel/Micochip and report the result. > ok. - Alex -- 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
Hi Alex, The Atmel/Microchip Team ask me to do not a Frame-Buffer Reader but a SRAM read(addr 0x00-0x7F) I locked through the Code but could not find the Frame-Buffer reading part. I would like to recompile the corresponding part and check if that changes something Best Regards Sebastian Balz Am 10.07.2017 um 14:03 schrieb Alexander Aring: > Hi, > > On Mon, Jul 10, 2017 at 01:50:30PM +0200, Balz wrote: > >> So i try to get in touch with Atmel/Micochip and report the result. >> > ok. > > - Alex > -- 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
Hi, On Sat, Jul 29, 2017 at 8:05 AM, Balz <Sebastian.balz@freenet.de> wrote: > > Hi Alex, > > The Atmel/Microchip Team ask me to do not a Frame-Buffer Reader but a SRAM read(addr 0x00-0x7F) > I locked through the Code but could not find the Frame-Buffer reading part. > We start the read frame buffer command at [0]. > I would like to recompile the corresponding part and check if that changes something > For me it sounds weird. You definitely lost the frame buffer protection with that. Is there some errata released where it stands you should use SRAM access? If I would be atmel, then maybe try to use manual locks, see register bits "RX_PDT_DIS". If they don't trust that automatic way doesn't work. You can change the code as well to use the manual way. - Alex [0] http://elixir.free-electrons.com/linux/latest/source/drivers/net/ieee802154/at86rf230.c#L758 -- 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
Hi Alex, I've changed the Kernel module so that i read the Framebuffer as SRAM and not as FrameBuffer. I've write a 0x00n followed by 0x00 to determine a SRAM read from the addr 0. But the Kernel Module can not identity the frame length any more. The Sniffed packages (all Packages have 143 byte length) do not show the behaviour any more. Maybe the SRAM read access is protected and the Frame-buffer Read not...? Best Regards Sebastian Balz Am 31.07.2017 um 15:48 schrieb Alexander Aring: > Hi, > > On Sat, Jul 29, 2017 at 8:05 AM, Balz <Sebastian.balz@freenet.de> wrote: >> Hi Alex, >> >> The Atmel/Microchip Team ask me to do not a Frame-Buffer Reader but a SRAM read(addr 0x00-0x7F) >> I locked through the Code but could not find the Frame-Buffer reading part. >> > We start the read frame buffer command at [0]. > >> I would like to recompile the corresponding part and check if that changes something >> > For me it sounds weird. You definitely lost the frame buffer > protection with that. > Is there some errata released where it stands you should use SRAM access? > > If I would be atmel, then maybe try to use manual locks, see register > bits "RX_PDT_DIS". If they don't trust that automatic way doesn't > work. > You can change the code as well to use the manual way. > > - Alex > > [0] http://elixir.free-electrons.com/linux/latest/source/drivers/net/ieee802154/at86rf230.c#L758 -- 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
Hi, On Wed, Aug 2, 2017 at 1:03 PM, Balz <s.balz@hm.edu> wrote: > Hi Alex, > > I've changed the Kernel module so that i read the Framebuffer as SRAM and > not as FrameBuffer. > I've write a 0x00n followed by 0x00 to determine a SRAM read from the addr > 0. > > But the Kernel Module can not identity the frame length any more. > > The Sniffed packages (all Packages have 143 byte length) do not show the > behaviour any more. > > Maybe the SRAM read access is protected and the Frame-buffer Read not...? > I think frame buffer read access only. "Dynamic Frame Buffer Protection is released on the rising edge of pin 23 (/SEL) during a Frame Buffer read access, or on the radio transceiver’s state change from RX_ON or RX_AACK_ON to another state.", see [0]. unless there is no errata which said is broken for frame buffer I am not willing to change it to e.g. SRAM which would work. As the datasheet says "Frame Buffer read access" only and not SRAM, foo. - Alex [0] http://www.atmel.com/images/Atmel-8351-MCU_Wireless-AT86RF233_Datasheet.pdf -- 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
Hi, as mention the packages seems to be valid expected the package size of 143. I tried to manipulate the kernel module so that is read the SRAM but I've trouble with reading the correct frame length. For me that is to deep into kernel programming (I have no knowledge with the Linux kernel). Temporally we switch to a RIOT based SLIP sniffer. Thank you very much fro your help. Best Regards Sebastian Balz Am 31.07.2017 um 15:48 schrieb Alexander Aring: > Hi, > > On Sat, Jul 29, 2017 at 8:05 AM, Balz <Sebastian.balz@freenet.de> wrote: >> Hi Alex, >> >> The Atmel/Microchip Team ask me to do not a Frame-Buffer Reader but a SRAM read(addr 0x00-0x7F) >> I locked through the Code but could not find the Frame-Buffer reading part. >> > We start the read frame buffer command at [0]. > >> I would like to recompile the corresponding part and check if that changes something >> > For me it sounds weird. You definitely lost the frame buffer > protection with that. > Is there some errata released where it stands you should use SRAM access? > > If I would be atmel, then maybe try to use manual locks, see register > bits "RX_PDT_DIS". If they don't trust that automatic way doesn't > work. > You can change the code as well to use the manual way. > > - Alex > > [0] http://elixir.free-electrons.com/linux/latest/source/drivers/net/ieee802154/at86rf230.c#L758 -- 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
Hi, On Thu, Aug 10, 2017 at 7:59 AM, Balz <Sebastian.balz@freenet.de> wrote: > Hi, > > as mention the packages seems to be valid expected the package size of 143. > I tried to manipulate the kernel module so that is read the SRAM but I've > trouble with reading the correct frame length. For me that is to deep into > kernel programming (I have no knowledge with the Linux kernel). > so you mention that you got a frame length which is not valid. It can't be large than 127. This is an on the air field (PHR), so it could be that somebody while transmitting is wrong. _IMPORTANT_ this (PHR) field is not part of CRC (FCS). Also we filter on such frame length and read the whole framebuffer then and trim it to 127 bytes (for monitoring could be interesting)... I would check with an e.g. ATUSB if you receive the same frames... I would only trust other sniffer devices if you know how they filter or simple drop such frames or do whatever their policy is. btw: I bet many other drivers doesn't check on valid PHR field and so far they run into bufferoverflows... - Alex -- 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
diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c index 548d9d026a85..858b07a4febc 100644 --- a/drivers/net/ieee802154/at86rf230.c +++ b/drivers/net/ieee802154/at86rf230.c @@ -311,6 +311,7 @@ at86rf230_reg_volatile(struct device *dev, unsigned int reg) case RG_VREG_CTRL: case RG_PLL_CF: case RG_PLL_DCU: + case RG_TRX_CTRL_2: return true; default: return false;