• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1]
1  General Category / General Discussion / Re: ZWave on Stratus Plug Computer on: December 25, 2012, 09:49:39 AM
I have a Sratus with ZWave and have the same question. I can't figure out how to use it.

In fact, I can't even figure out how to verify that the plug *has* Zwave in that I don't see any devices or files with the word Zwave in it.  Nor is it mentioned in the /sys/devices tree.

Have you been able to get *anything* out of your Zwave plug -- even if just to verify that it has a Zwave module?
2  Hardware and U-Boot firmware / Hardware / Re: Firmware CRC load error when loading upa or wlan firmware on: January 16, 2011, 09:23:51 PM
Any reason you don't *read* the thread that you are posting in?
I directly explain and address the specific problem you are having.
The kernel tainting is a red herring btw I believe.
3  Hardware and U-Boot firmware / Hardware / Re: Firmware CRC load error when loading upa or wlan firmware on: January 10, 2011, 02:20:06 AM
Your aproach is necessary but not sufficient in that it won't let you go back from wifi mode to ap mode without rebooting unless you use my method from the other thread (that you helpfully site) to reset the wifi portion -- Note: I think I probably forgot about this thread when I posted my solution.

In any case, I came up with what I think is a pretty elegant solution that allows you to switch back-and-forth repeatedly between wifi and uap mode plus/minus a wired eth0 port.

I do it using a /etc/network/interfaces script plus 2 helper scripts for wifi and uap mode. These helper scripts are separate both so that you can hide the respective access point and wifi passwords (and ssids) and also since they have several user-defined parameters that you might want to play with.

Basically you have the following options:
1. Wired ethernet only  (eth0)
            ifup eth0; ifdown uap0
2. Wired ethernet plus access point (eth0 + uap0)
            ifup eth0; ifup uap0
3. Access point only (not very useful since you can't connect to the
   rest of the world)
            ifup uap0; ifdown eth0
4. Wireless ethernet only (mlan0)
            ifup mlan0

It requires the following 3 files (that should be untarred within /etc/network/)
/etc/network/interfaces
/etc/network/wpa_supplicant.conf.jjk_
/etc/network/uap-post.jjk_

The 'interfaces' file should be edited to choose between dhcp and static ip and if using static ip to set your ip address. Also, you need to set the AP IP address. The last two files need to be edited to add the appropriate SSID's and WPA passphrases. Finally, the last two files should be mode 600 and 700, respectively.

To set everything up properly, you probably should also add the following lines to the end of your etc/rc.local file (also feel free to add the appropriate ifup/ifdown combinations to start up in the mode that you prefer)

rmmod libertas_sdio libertas btmrvl_sdio btmrvl bluetooth 2>/dev/null
#IP masquerading to forward internal packets to external network
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
#iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -A INPUT -i uap0 -p tcp -m tcp --dport 80 -j ACCEPT

echo 1 > /proc/sys/net/ipv4/ip_forward

exit 0





4  Hardware and U-Boot firmware / Hardware / Switching between uap8xxx and sd8xxx requires soft wireless hardware reset on: December 31, 2010, 07:31:54 AM
I have not seen this explicitly documented anywhere, but if you want to switch between access point mode (uap8xxx module) and wlan mode (sd8xxx module) then you need to soft reset the wireless hardware *before* unloading the module. Otherwise, the new module will load, but the hardware will not be recognized by the system (e.g., /sys/class/net/uap0 and /sys/class/net/mlan0, respectively, won't even show up meaning that there is no hardware recognition).

The way to reset the module is not obvious (and is buried in the source code) but is as follows:
For uap8xxx, before unloading, issue the command:
    cat 2 >| /proc/uap/uap0/hwstatus
This triggers the case HWReset in uap_proc.c and calls the function uap_soft_reset(). The message 'reset hw' is sent to the syslog.

For sd8xxx, there is no corresponding /proc/mlan/mlan0/hwstatus created in /proc and there is no HWReset in the corresponding wlan_proc.c
Instead, you issue the command:
   iwpriv mlan0 softreset
This has the effect of ultimately calling the analogous wlan_soft_reset() function (though it's name seems to differ depending on driver version). No syslog message is generated.

This still leaves me with a couple of questions:
1. Why is this not better documented given that the modules cannot be switched properly without it? i.e., it's pretty basic functionality
2. Why doesn't the module code itself *automatically* trigger a software reset upon being unloaded? This would make it all seemless
3. Why are soft resets of uap8xxx and sd8xxx treated asymmetrically? i.e. why does uap8xxx use 'echo 2>| /proc/uap/uap0/hwstatus' while sd8xxx uses 'iwpriv mlan0 softreset'
5  Hardware and U-Boot firmware / Hardware / Firmware CRC load error when loading upa or wlan firmware on: December 29, 2010, 02:32:35 PM
I have been encountering some frequent, but intermittent wireless *firmware* loading bugs on the Ionics Stratus Zigby plug when I load/unload or switch between the access point (uap0) and wlan (mlan0) modules which are the Marvel firmware modules uap8xxx and sd8xxx, respectively.

For example, when loading the wlan module by doing:
    rmmod uap8xxx sd8xxx
    rm /lib/firmware/mrvl/*
    cp -a /fw/wlan/* /lib/firmware/mrvl
    insmod /root/modules/wlan/sd8688.ko

The module loads, but doesnt' work (e.g., ifconfig fails) and dmesg shows the following errors about the wlan firmware not loading correctly:
      wlan_sdio mmc0:0001:1: firmware: requesting mrvl/helper_sd.bin
      wlan_sdio mmc0:0001:1: firmware: requesting mrvl/sd8688.bin
      FW CRC error indicated by the helper: len = 0x0011, txlen = 17
      FW CRC error indicated by the helper: len = 0x0011, txlen = 17
      FW download failure @ 0, over max retry count
      Firmware Init Failed
      wlan_probe: wlan_add_callback failed
      wlan_sdio: probe of mmc0:0001:1 failed with error -1



Similarly, when loading the access point module by doing:
    rmmod uap8xxx sd8xxx
    rm /lib/firmware/mrvl/*
    cp -a /fw/uap/* /lib/firmware/mrvl
    insmod /root/modules/uap/sd8688.ko

The module loads, but doesnt' work (e.g., ifconfig fails) and dmesg shows the following errors about the uap firmware not loading correctly:
      uap_probe: vendor=0x02DF device=0x9104 class=0 function=1
      uap_sdio mmc0:0001:1: firmware: requesting mrvl/helper_sd.bin
      uap_sdio mmc0:0001:1: firmware: requesting mrvl/sd8688_ap.bin
      FW CRC error indicated by the helper: len = 0x0011, txlen = 17
      FW CRC error indicated by the helper: len = 0x0011, txlen = 17
      FW download failure @ 0, over max retry count
      UAP FW download failed!
      Firmware Init Failed
      uap_probe: uap_add_callback failed
      uap_sdio: probe of mmc0:0001:1 failed with error -1

Sometimes it happens on the first load or switch, sometimes on later ones. Sometimes rebooting helps, sometimes it doesn't. Unplugging often but doesn't seem to always help. This *appears* to be a firmware issue but could of course be cause by the hardware not loading the firmware properly.

Note, the error seems to be generated in the following kernel module code (relative to kernel source root):
        ./drivers/net/wireless/libertas_uap/uap_sdio_mmc.c

Note I don't think the problem is due to corruption of the code being loaded (as copied from /fw/uap and /fw/wlan or from /root/modules) since the code has not been changed and indeed it does load properly sometimes.

Any thoughts on what might be causing this issue and how to fix it?

Thanks,
Jeff


6  Hardware and U-Boot firmware / Hardware / Re: Guruplug I/O and JDB errors on writing to micro SD card on: November 17, 2010, 09:33:55 PM
I just mentioned the model for full disclosure, BUT I assumed that the problem may be more generic to Gurplugs or even to linux+flash in general.

I ended up reformatting the internal 8GB card (which is originally all vfat) into a boot and root partition so that I could boot from the internal flash drive (I also of course had to change the Uboot bootargs and bootcmd to get it to boot from it).

And I ended up getting SIMILAR write errors with the internal flash.
So, since it is probably unlikely to have both the external micro SD and the internal flah broken, my hypothesis now is that it is more likely to be a driver problem.

I must say the errors are "scary" when they show up randomly during a long 'apt-get upgrade' since you never know whether anything got corrupted that might one day come back to bite you... (I wish dpkg had a 'verify' mode like rpm).

(And please don't be jealous of me since I don't have an HDMI monitor to really make it work and the DVI-HDMI converter plug I have seems to work OK for standard display but the screen goes berzerk when I try to play any video (and of course sound doesn't work)
7  Hardware and U-Boot firmware / Hardware / Guruplug I/O and JDB errors on writing to micro SD card on: November 17, 2010, 05:55:00 PM
I have a GPlug-Display which is configured with boot and root partitions on a micro-SD card (/dev/sda1, /dev/sda2, respectively) while there is an internal flash drive partitioned as FAT16 for storing videos (this is how it came configured).

When running applications that seem to write intensively to the flash (such as apt-upgrade but occassionally even simpler things), I randomly get errors on the console of form:
xa-sdh pxa-sdh.0: DATA Line Error(status: 0x0010)!
mmcblk0: error -5 transferring data, sector 1319016, nr 120, card status 0x900
end_request: I/O error, dev mmcblk0, sector 1319096
Buffer I/O error on device mmcblk0p2, logical block 139387
lost page write due to I/O error on mmcblk0p2
end_request: I/O error, dev mmcblk0, sector 1319104
Buffer I/O error on device mmcblk0p2, logical block 139388
lost page write due to I/O error on mmcblk0p2
end_request: I/O error, dev mmcblk0, sector 1319112
Buffer I/O error on device mmcblk0p2, logical block 139389
lost page write due to I/O error on mmcblk0p2
end_request: I/O error, dev mmcblk0, sector 1319120
Buffer I/O error on device mmcblk0p2, logical block 139390
lost page write due to I/O error on mmcblk0p2
end_request: I/O error, dev mmcblk0, sector 1319128
Buffer I/O error on device mmcblk0p2, logical block 139391
lost page write due to I/O error on mmcblk0p2
JBD: Detected IO errors while flushing file data on mmcblk0p2
JBD: Detected IO errors while flushing file data on mmcblk0p2

I'm not sure if this is due to bad flash or due to a driver issue. I am concerned though of course about data corruption.

NOTE the  output of fdisk -l is:
Disk /dev/mmcblk0: 4035 MB, 4035969024 bytes
68 heads, 3 sectors/track, 38640 cylinders
Units = cylinders of 204 * 512 = 104448 bytes
Disk identifier: 0x00000000

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1               1        1000      101998+   6  FAT16
/dev/mmcblk0p2            1001       38640     3839280   83  Linux

Disk /dev/mmcblk1: 8018 MB, 8018460672 bytes
219 heads, 12 sectors/track, 5959 cylinders
Units = cylinders of 2628 * 512 = 1345536 bytes
Disk identifier: 0x00000000

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk1p1               4        5960     7826432    b  W95 FAT32

and the outut of df is:
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mmcblk0p2         3778976   1072780   2514232  30% /
tmpfs                   257748         0    257748   0% /lib/init/rw
udev                     10240       520      9720   6% /dev
tmpfs                   257748         4    257744   1% /dev/shm

In any case, the problem seems to occur when writing to the root filesystem
8  Hardware and U-Boot firmware / Hardware / Re: Probing gpio pins from userspace using /dev/mem on: October 27, 2010, 10:10:02 AM
About connecting pins to themselves..what if I oops and connect two set output pins to each other? That doesn't sound too good.
Guess I should check the ribbon cable between the boards first as a warm up. Just a resistance check for each pin or something.

That is unlikely to cause permanent damage. After all, the GPIO pins are *bidirectional* by nature. As long as you stay away from too high a voltage, the pins are pretty robust.

Remember the pin voltages are 3.3V not 5V highs.
9  Linux Stuff / Kernel / Re: wds support in uap8xxx on: October 26, 2010, 11:30:26 AM
Did you ever figure this out or get an answer?
I am interested in usin the plug as a wireless repeater
10  Hardware and U-Boot firmware / Hardware / Re: Probing gpio pins from userspace using /dev/mem on: October 26, 2010, 08:02:15 AM
But I'd need some kind of hardware device to sample the output of the pins, right?
There is no way to just try to write to a pin and see if it can be set from software? Maybe some error message if something goes wrong?
I'm not too hot with designing my own hardware  Lips sealed

Something like
Set pin 1 to 1
Read pin 1: 1. OK
Set pin 2 to 1
Read pin 2: 0. ERROR
woops, line 2 is broken.


Well the only way to tell if the read/write actually happens in hardware is by sending & sampling signals.
You can use a cheap (<$10 digital voltmeter) to measure the voltage on the pins in response to you setting them to 0/1 ( you can use my write program to send out a very slow pulse by changing the speed to say 1 sec intervals)
You can check the input by putting in alternatively 0 or 3.3 volts (2 1.5 volt batteries in series between ground and the pin will work or use the internal 3.3 (not 5v) signal if it is broken out for you on the sdio connector (or open the plug and go inside to access the 3.3v test pin somewhere).

Or you can just let the pin float if it is not attached to a pull-up/pull-down resistor and you will see the inputs change fast from 0 to 1
11  Hardware and U-Boot firmware / Hardware / Re: Probing gpio pins from userspace using /dev/mem on: October 26, 2010, 12:02:55 AM
Does anyone know if there is a way to try to read/write to the individual SDIO pins?

I think my SDIO port is broken and it would be nice to know if any pins aren't connected properly.

Ummmm... isn't this *exactly* what I just took the trouble of posting about and even attached the actual code to do exactly what you want without any additional programming or modifications? (please tell me you read the last couple of posts...)

Just figure out which is the pin number corresponding to the sdio ports on your device and run my programs to read/write to the pins...
BE CAREFUL to get the port numbers right...
12  Hardware and U-Boot firmware / Hardware / Re: Probing gpio pins from userspace using /dev/mem on: October 24, 2010, 12:54:01 PM
First, I am looking for the fastest possible way to sequentially sample and/or output to the GPIO pins so I am looking for the method that has the least overhead (without resorting to assembly code or anything too hard).
The input pins sampling method with the least overhead is to not sample them. Smiley Implementation involves setting the input pins up to cause an interrupt when they are changed by exterior signals.  This, however, requires kernel code (a device driver, usually) to handle the interrupt condition and user code to handle a propagated "IO change" event.

Determining a purely user space alternative requires an understanding of the maximum "IO change" event propagation delay that can be tolerated.  In short, the less delay that can be tolerated, the higher the priority of and the smaller the sleep time in the polling loop (both of which increase the overhead associated with the method).
[


Thanks, I came to a similar conclusion upon reading the Marvel datasheets and seeing that there is the option to trigger inputs. I have no idea though how to write a kernel driver. Any pointers to sample code or a similar driver for another device or application that I could potentionally adapt to the plucomputer?

Thanks!
13  Hardware and U-Boot firmware / Hardware / Re: Probing gpio pins from userspace using /dev/mem on: October 24, 2010, 12:49:54 PM
OK I figured it out and got it working using /dev/mem!
I am able to sample (read or write) at 1MHz (1us/sample) with good accuracy (though occasionally some other thread burps and I miss a sample).

As TMK, mentioned be CAREFUL about accidentally changing the status of key dedicated GPIOs. When I was testing my code to make sure it properly did all the shifting/masking for different GPIOs,  I accidentally changed the status of one of the GPIOs controlling the NAND flash and it corrupted my flash (of course just before I was about to backup my system but I thought let me just try one more test) -- I had to reflash to fix that... Sad

Anyway, I wrote some sample code for reading and writing GPIOs that:
1. Sets the appropriate status/direction of the desired GPIO port via the appropriate control registers
2. Samples or outputs to the corresponding GPIO pin.

I tested the code on the Ionics Stratus plug and put in some guard rail code to make sure you only toggle the free GPIOs (I know that GPIOs 20-27 are safe)
The attached routines are jdevmem-gpi.c (input) and jdevmem-gpo.c (output). Obviously, they can be generalized/adapted to sample/write to multiple gpios at once etc.

Enjoy!
14  Hardware and U-Boot firmware / Hardware / Re: Probing gpio pins from userspace using /dev/mem on: October 20, 2010, 11:01:06 AM
TMK,
Since you seem to be one of the few who have mastered reading/writing GPIOs, I was hoping you could help me with a few questions.

First, I am looking for the fastest possible way to sequentially sample and/or output to the GPIO pins so I am looking for the method that has the least overhead (without resorting to assembly code or anything too hard).

I used the modified devmem2 code that you cited. It seems to read the mpp control registers just fine but I have a couple of problems/questions:
1. I get the same hang under kernel 2.6.31.8 when I try to write to those registers (and I also have the same issue with 'undocumented' states). Has any workaround been found or is it not possible to write these registers via /dev/mem
2. I see how to read/write the MPP control registers but how do you access the actual bits themselves in the corresponding GPIO lines?
3. Is /dev/mem the fastest way to read/write the GPIO lines or are there equally fast (or faster) alternatives? I have always assumed that /sys is slow but maybe I'm wrong.
4. Just out of curiosity, do you have to call mmap each time you want to re-read/write a GPIO line or does it only need to be done once at initialization and then it is just sufficient to reread the pointer to the mmapped region.

Thanks
Pages: [1]