 Show Posts
|
|
Pages: [1] 2 3
|
|
2
|
Linux Stuff / Kernel / Re: Dreamplug AP using mwifiex (SD8787)
|
on: April 28, 2013, 09:19:01 AM
|
|
Right now, I'm running an AP on mwifiex using the tip of the wireless-testing git repo (version reads as 3.9.0-rc8-wl), the latest firmware from the link nago gave, and WPA2. Note that if you try to use WPA instead of WPA2, the client handshake seems to fail.
I've had it running for a half hour or so of light use - seems stable so far, but time will tell.
|
|
|
|
|
3
|
Linux Stuff / Kernel / Re: Dreamplug AP using mwifiex (SD8787)
|
on: February 13, 2013, 12:04:40 PM
|
|
Interesting.
I've been running the tip of the wireless-testing tree (currently a release candidate of 3.8 ). I'm primarily interested in AP mode.
With a git version of hostapd (which is basically REQUIRED for this card at the moment), I was able to bring up an AP with WPA, and everything would work for a few seconds. Then the transmit queue on the AP would get stuck and the kernel would start printing errors about a hung kernel task.
I'll try with the new firmware and latest updates from wireless-testing to see if the behavior improves at all. I'll see about trying STA mode while I'm at it.
It seems that most of the problems with this card revolve around the fact that it implements a lot in hardware that most cards do in software. There have been multiple patches to cfg80211 in the kernel and hostapd in userspace to deal with the fact that the card performs certain tasks that the software expects to perform.
|
|
|
|
|
4
|
Linux Stuff / Kernel / Re: Dreamplug AP using mwifiex (SD8787)
|
on: October 17, 2012, 12:04:32 PM
|
|
Most of the instability seems to be when bringing the card up. Since that first time when closing hostapd hung the box, I haven't had another hang.
When the card comes up properly, I can start hostapd and have a working AP with no encryption. The client fails to associate if I enable WPA - not sure if it's implemented yet. I don't even know if this card has hardware crypto or not, so I don't know whether it needs to be implemented.
Thinking about emailing one of the Marvell guys that's submitting code for inclusion in the kernel, but I'm not sure if this is worth bothering them about.
|
|
|
|
|
5
|
Linux Stuff / Kernel / Re: Dreamplug AP using mwifiex (SD8787)
|
on: October 14, 2012, 11:42:08 PM
|
Got a 3.7rc1 kernel running. The mwifiex_sdio kernel module seems to allow the WiFi adapter to simultaneously act as client and AP (and p2p, whatever that is). When the WiFi PHY comes up, it creates three interfaces: mlan0, uap0, and p2p0. I'm not sure how to configure uap0 to make things work. It seems I can't just set the SSID through iwconfig. I ran hostapd, and while it failed to create the monitor interface it normally uses, I did start seeing SSID broadcasts from my AP, and I could associate with it. I couldn't get full network connectivity, but that may have just been due to my IPTables rules being too strict or somesuch. I didn't get the chance to find out because apparently if you kill hostapd, the system locks. No kernel panic messages on the serial port; it just dies. Also, things seem to be alright if I modprobe mwifiex_sdio myself, but the one time I removed it from the blacklist and it was loaded on boot, the system hung. Haven't checked whether it's repeatable, but it's more than a little frightening. Anyway, this is looking pretty interesting. If anyone is interested in fiddling with this, I could post up the config I'm using (although it's really just an updated version of one from http://www.xilka.com/). I could probably get the uImage and modules up somewhere as well, but this probably isn't something stable enough for general usage. Actually, it's probably a terrible idea to use this if you don't have a JTAG box. |
|
|
|
|
6
|
Linux Stuff / Kernel / Re: Dreamplug AP using mwifiex (SD8787)
|
on: October 14, 2012, 07:04:09 PM
|
|
Self-reply since I apparently can't edit the original post:
It looks like uAP support only entered the mainline kernel in 3.6, and a lot of fixes are making it into 3.7.
I'm currently building a 3.7rc1 kernel. I'll see how it goes.
|
|
|
|
|
7
|
Linux Stuff / Kernel / Dreamplug AP using mwifiex (SD8787)
|
on: October 14, 2012, 05:35:44 PM
|
|
I have a recent Dreamplug, and it looks like at some point the wireless chipset switched to SD8787. uap8xxx does not bring up this card, and it looks like the official kernel driver is mwifiex. Looking at various kernel mailing lists, it looks like this driver *does* support both UAP and STA mode, but I haven't figured out how to get it into UAP mode.
Has anyone tried this? I can't find any mailing list discussions about using this driver in UAP mode, just patches from Marvell that supposedly add it.
|
|
|
|
|
8
|
Hardware and U-Boot firmware / Hardware / Replacement Power Supply
|
on: June 01, 2010, 04:19:34 PM
|
My plug started rebooting this morning, and after the third reboot, I unplugged it, thinking it was probably overheating. After plugging it back in, I got the familiar flashing green light and ethernet lights, and upon taking it apart, it looks like my power supply has failed. What's strange is that my plug has been running for months with an externally powered Western Digital Essentials hard drive, so I don't think I fall into the category of people that ran hard drives off the sheevaplug. Still, it's clear which capacitor went bad, and my power supply is definitely the issue. Now, is the issue fixed in Globalscale's replacement power supplies, or should I be going with something like http://cgi.ebay.com/BRAND-NEW-5V-3A-AC-DC-Power-adapter-Power-supply-Well_W0QQitemZ280325831479QQcmdZViewItemQQptZCOMP_EN_Networking_Components?hash=item4144b8bb37? On the one hand, Globalscale's replacement would keep the plug looking decent, but on the other hand, I'd much rather spend a few hours rigging up my own power supply if Globalscale is going to be slow and/or provide a replacement with the same low capacity as the original. |
|
|
|
|
9
|
Hardware and U-Boot firmware / U-Boot stuff / Re: I Seem to Have Built a Bad Kernel
|
on: August 08, 2009, 10:36:39 AM
|
|
I'm guessing the kernel module for our NAND changed, probably because in Marvell's original kernel tree, they patched the nand_mtd driver to work with a slightly different NAND setup. When it was merged into the full kernel, it was probably separated into a different driver.
That's just my guess though.
|
|
|
|
|
11
|
Hardware and U-Boot firmware / U-Boot stuff / Re: can't find ftdi device from ubuntu
|
on: August 07, 2009, 10:44:55 PM
|
The link works for me, but just for good measure: looks like the last batch of sheevaplugs changed vendor and product id. Modified scripts-linux/openocd/config/interface/sheevaplug.cfg to
interface ft2232
ft2232_layout sheevaplug
ft2232_vid_pid 0x0403 0x6010
#ft2232_vid_pid 0x9e88 0x9e8f
#ft2232_device_desc "SheevaPlug JTAGKey FT2232D B"
jtag_khz 2000
|
|
|
|
|
12
|
Hardware and U-Boot firmware / U-Boot stuff / Booting From a USB Hard Drive Enclosure
|
on: August 07, 2009, 10:05:00 PM
|
Okay, so I have a 250GB drive in a Rosewill USB SATA enclosure, and I want to try to get U-Boot to load the uImage from it. "fdisk -l" looks like this: $ sudo fdisk -l
Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x97073300
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 30401 244091610 83 Linux
sda1 is a 100MB ext2 partition that I planned to mount as /boot sda2 is a giant ext4 partition that I planned to mount as / (I was still deciding whether I had a reason to split the filesystem more than that) U-Boot recognizes the drive in the enclosure as a mass storage device, then it claims that my partitions are invalid. Here's a log of one of my attempts: Hit any key to stop autoboot: 0
Marvell>> usb start
(Re)start USB...
USB: scanning bus for devices... 2 USB Device(s) found
scanning bus for storage devices... T 1 Storage Device(s) found
Marvell>> ext2load usb 0:1 0x800000 /uImage
** Bad partition 1 **
Marvell>> usb storage
Device 0: Vendor: Maxtor 6 Prod.: B250S0 Rev:
Type: Hard Disk
Capacity: 238475.1 MB = 232.8 GB (488397168 x 512)
Marvell>> usb tree
Device Tree:
1 Hub (480MBit/s, 0mA)
| Marvell EHCI
|
+-2 Mass Storage (480MBit/s, 2mA)
Sunplus Technology Co.,Ltd. USB to Serial-ATA bridge FAFFFF06B2B60FFFFF
Marvell>> usb dev 0
USB device 0:
Device 0: Vendor: Maxtor 6 Prod.: B250S0 Rev:
Type: Hard Disk
Capacity: 238475.1 MB = 232.8 GB (488397168 x 512)
... is now current device
Marvell>> usb part
print_part of 0
## Unknown partition table
print_part of 1
## Unknown partition table
print_part of 2
## Unknown partition table
print_part of 3
## Unknown partition table
print_part of 4
## Unknown partition table
Marvell>> usb info
1: Hub, USB Revision 2.0
- Marvell EHCI
- Class: Hub
- PacketSize: 64 Configurations: 1
- Vendor: 0x0000 Product 0x0000 Version 1.0
Configuration: 1
- Interfaces: 1 Self Powered 0mA
Interface: 0
- Alternate Settings 0, Endpoints: 1
- Class Hub
- Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
2: Mass Storage, USB Revision 2.0
- Sunplus Technology Co.,Ltd. USB to Serial-ATA bridge FAFFFF06B2B60FFFFF
- Class: (from Interface) Mass Storage
- PacketSize: 64 Configurations: 1
- Vendor: 0x04fc Product 0x0c25 Version 1.18
Configuration: 1
- Interfaces: 1 Self Powered 2mA
- String: ""
Interface: 0
- Alternate Settings 0, Endpoints: 2
- Class Mass Storage, Transp. SCSI, Bulk only
- String: ""
- Endpoint 1 In Bulk MaxPacket 512
- Endpoint 2 Out Bulk MaxPacket 512
The "T" after "scanning bus for storage devices" is printed while U-Boot waits for the drive to spin up. It also takes at least a few seconds for "usb info" to print info on the hard drive, but the drive is already spinning by then. I'm hoping I'm missing something obvious and U-Boot isn't at fault. |
|
|
|
|
15
|
General Category / General Discussion / Re: Sheevaplug installer - alpha-6 release - Testers needed
|
on: August 05, 2009, 03:28:23 PM
|
When I run runme.sh, I get this: # ./runme.sh
**** Preparing environment variables file ...
**** Burning uboot and environment variables ... This will take few minutes ...
Open On-Chip Debugger 0.2.0-in-development (2009-05-17-10:32) svn:1800M
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
2000 kHz
dcc downloads are enabled
Error: unable to open ftdi device: device not found
Runtime error, file "command.c", line 453:
**** openocd FAILED
**** Is the mini USB cable connected?
**** Try powering down, then replugging the Sheevaplug
The Sheevaplug is connected and I can connect to the Linux host on /dev/ttyUSB1. Rebooting the plug made no difference. The kernel logs show this: Aug 5 16:50:45 Reno kernel: usb 4-2: new full speed USB device using ohci_hcd and address 7
Aug 5 16:50:45 Reno kernel: usb 4-2: configuration #1 chosen from 1 choice
Aug 5 16:50:45 Reno kernel: ftdi_sio 4-2:1.0: FTDI USB Serial Device converter detected
Aug 5 16:50:45 Reno kernel: usb 4-2: Detected FT2232C
Aug 5 16:50:45 Reno kernel: usb 4-2: FTDI USB Serial Device converter now attached to ttyUSB0
Aug 5 16:50:45 Reno kernel: ftdi_sio 4-2:1.1: FTDI USB Serial Device converter detected
Aug 5 16:50:45 Reno kernel: usb 4-2: Detected FT2232C
Aug 5 16:50:45 Reno kernel: usb 4-2: FTDI USB Serial Device converter now attached to ttyUSB1
Should I try recompiling OpenOCD on my non-ARM linux box? It looks like I have libftdi and not libftdi2xx, would that cause problems? OpenOCD didn't have any errors about dynamic library loading... Actually, could Bad Things (TM) be happening because I'm running this on 64 bit Linux? I'll try it on a 32 bit system... On the 32 bit system, openocd segfaulted almost instantly. Ergh, I guess I'll try recompiling it. Okay, it looks like it's working from my 64 bit box with fragfutter's modifications to interface.cfg. |
|
|
|
|
