non-PCI OHCI (STBxxxx)
Hi, i'm using a IBM STB04xxx-based system (PPC405 core with Set-Top-Box MPEG functions as well as some other stuff), which has an integrated OHCI controller i'd like to use. Obviously there is no PCI bus on that system, so it's not as simple as possible. I hacked a 2.4.19-preX ohci-driver to use some consistent_alloc, _sync instead of the pci functions and hardcoded baseaddress and IRQ. This worked (a bit), but was very unstable and stopped working totally with -rc3. Don't know what exactly changed, since i'm very new into USB at all, and i'm really unable to debug what's going wrong for example on device not accepting new address etc., since this already requires working USB transfers etc. A bit disappointed by commtens in ohci.h which state that it's not so easy to use non-PCI OHCI controllers i looked into the SA-case, but - well, it didn't helped me too much and seems to require huge hacks (for example they emulate the pci-functions.. or is that the way to go?) I then tried to use a 2.5 kernel. The ohci-stuff is well structured there, and i made some ohci-ocp.c and hacked the use of the pci-functions again. Result was a working USB support, but somewhere there's still an error, as there is some data inconsistency. for example, i burned an audio cd, and it contained noise about every second. When i read a FAT disk, there're randomly some invalid cluster chain error messages etc. Maybe some cache problems. Don't know, and as said, i'm unable to debug this further without help :( So i'm asking: Is there any standard approach to this? Maybe there's already a patch flying around? If someone from Monta Vista is reading this: Is this going to be supported? If not: How is this going to be? What exactly are the issues regarding consistent_alloc, _sync versus their pci-variants? Is it maybe possible to USE the pci-functions with some dummy pci device? If i understand correctly, consistent_alloc allocates contigouus, non-pagable memory which is directly mapped to bus-addresses, consistent_sync flushes all writeback caches (if TODEVICE) or invalidates them (if FROMDEVICE) is this correct? Do pci_pool_alloc alloc compatible memory? does pci_map_single nothing more (in functional meaning, if we don't look at other, more complex hardware/bridges) that a consistent_sync and bus2virt? And finally: I usually ioremap() to use hardware memory. What's the difference of using ioremap() vresus bus2virt and virt2bus? are they deprecated ? are they only possible after an ioremap? or is kernel-memory all the time mapped to bus addresses which can be retrieved using virt2bus? thanks in advance, Felix Domke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Incoming to hostme.bitkeeper.com:/ua/repos/p/ppc/linuxppc-2.5
On Mon, Jan 06, 2003 at 04:03:28AM -0800, ppc at bkbits.net wrote: ChangeSet at 1.778, 2003-01-06 21:55:54+11:00, paulus at samba.org Small walnut update: don't reference todc_* unless CONFIG_GEN_RTC is set, plus minor syntax fix. arch/ppc/platforms/4xx/walnut.c at 1.9, 03-01-06 21:55:49+11:00, paulus at samba.org take out parentheses in #ifdef, add #ifdef CONFIG_GEN_RTC around todc_* references Ack! I really think this is the wrong approach, as now CONFIG_GEN_RTC=m will still not work on Walnut (/ 40x in general). I think what we really need is on 40x to either mimic how the 'classic' boards do it, and have CONFIG_WALNUT, CONFIG_ASH, etc reference todc_time.o, and always get it, or start defining attributes like had been suggested many times in the past (ie a walnut, ash, spruce and so on would set CONFIG_PPC32_USE_TODC_SUPPORT or something). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
request_irq, MPX8xx, IDE, PCMCIA, ...
Hi there,
last year ide-cs was working on MPC8xx platforms.
It was necessary to define
define ide_request_irq(irq,hand,flg,dev,id)
request_8xxirq((irq),(hand),(flg),(dev),(id))
in the board specific header file.
I just relalised that on December 16 code in ide-probe was changed!!!
- if (ide_request_irq(hwif-irq, ide_intr, sa, hwif-name,
hwgroup)) {
+ if (request_irq(hwif-irq,ide_intr,sa,hwif-name,hwgroup)) {
Now it crashes with a Kernel panic: request_irq.
What is the status of the request_8xxirq() vs request_irq() stuff?
BTW: Is the patch changing IN_BYTE() to hwif-INB() etc. working on MPC8xx
platforms?
Thanks a million,
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
request_irq, MPX8xx, IDE, PCMCIA, ...
On Mon, Jan 06, 2003 at 06:11:05PM +0100, Steven Scholz wrote: Hi there, last year ide-cs was working on MPC8xx platforms. It was necessary to define define ide_request_irq(irq,hand,flg,dev,id) request_8xxirq((irq),(hand),(flg),(dev),(id)) in the board specific header file. I just relalised that on December 16 code in ide-probe was changed!!! As part of the IDE cleanup, yes. What is the status of the request_8xxirq() vs request_irq() stuff? At the certain annoyance of Dan Malek (sorry Dan), really really soon now. I've got a local (Marcelo-based) 2.4 with the changes in, and lightly tested. Once it passes some more heavy 'stress', I'll ask Paul to send it onto Marcelo. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
wireless lan PCMCIA card advice
Hello, I have a RPXLite 823e based board from EmbeddedPlanet that has an open PCMCIA slot in it. Currently I am booting a 2.4.4 kernel from ELDK which works just fine. I would like to buy a wireless 802.11b PCMCIA card for this board and am wondering about any past experiences. I have researched the general linux+WiFi webistes a bit, but I wanted the embedded society's opinion also. Any success stories out there? If so could you include the following info? embedded board: PCMCIA hardware: PCMCIA vendor: driver used: kernel version: I appreciate your help. Please CC: me on the replies. Cheers, Curt ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
wireless lan PCMCIA card advice
I've heard of success with the Cisco Aironet 340. -Original Message- From: curt brune [mailto:[EMAIL PROTECTED] Sent: Monday, January 06, 2003 3:51 PM To: linuxppc-embedded at lists.linuxppc.org Subject: wireless lan PCMCIA card advice Hello, I have a RPXLite 823e based board from EmbeddedPlanet that has an open PCMCIA slot in it. Currently I am booting a 2.4.4 kernel from ELDK which works just fine. I would like to buy a wireless 802.11b PCMCIA card for this board and am wondering about any past experiences. I have researched the general linux+WiFi webistes a bit, but I wanted the embedded society's opinion also. Any success stories out there? If so could you include the following info? embedded board: PCMCIA hardware: PCMCIA vendor: driver used: kernel version: I appreciate your help. Please CC: me on the replies. Cheers, Curt ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
wireless lan PCMCIA card advice
Dear Curt, in message 20030106125125.D24490 at curtisb.com you wrote: I have a RPXLite 823e based board from EmbeddedPlanet that has an open PCMCIA slot in it. Currently I am booting a 2.4.4 kernel from ELDK which works just fine. The current version of our ELDK provides pretty complete support for PCMCIA cards, and has been tested with WLAN, CompactFlash and other IDE, network and modem cards. I would like to buy a wireless 802.11b PCMCIA card for this board and am wondering about any past experiences. I have researched the general linux+WiFi webistes a bit, but I wanted the embedded society's opinion also. Any success stories out there? If so could you include the following info? Here is a step-by-step description of what we did - both on custom hardware and on standard TQM8xxL systems: 1. Building and installing the CardServices package. QUICKSTART: - Unpack pcmcia-cs-3.2.0.tar.gz tarball, apply patch. - The CIS replacement data file ARGOSY.dat have to be copied to pcmcia-cs-3.2.0/etc/cis directory of the source tree. - set up cross-development environment (ppc_8xx-gcc should be in PATH) - configure, build and boot the kernel, making sure that the latest patch is applied. The CONFIG_PCMCIA kernel option must be off. For particular card types see notes below. To avoid warnings during depmod at the system start-up, enable the standard 16550 serial driver. While in the pcmcia-cs-3.2.0 directory, execute the following commands: - make config It is safe to leave the default answers to all the configuration questions, except for the Cardbus support, which must be disabled, and for the Linux kernel source directory, which must match the directory you used in the previous step - make all - touch etc/cis/ARGOSY.dat - make install The resulting tree will be in pcmcia-cs-3.2.0/../pcmcia directory. - Copy the resulting tree to the root (/) of the target file system being logged as 'root': # cp -r ../pcmcia/* /opt/eldk/ppc_8xx/ 2. Starting CardServices: on the target: /etc/rc.d/rc.pcmcia start 3. To be able to use wireless PCMCIA cards the 'wireless-tools' package must be installed on the target filesystem. To bring up the WLAN card for network operations, the following actions should be performed (the example output shows card configuration for the WLAN network controlled by the Access Point (managed mode)): 1. Assign the ip address of the WLAN network segment to the WLAN interface: bash# ifconfig eth1 192.168.2.3 2. Assign the Network (or Domain) Name to the WLAN interface: bash# iwconfig eth1 essid DENX At this point the Acess Point station MAC address should appear on the iwconfig output: bash# iwconfig eth1 eth1 IEEE 802.11-DS ESSID:DENX Nickname:Prism I Mode:Managed Frequency:2.462GHz Access Point: 00:02:2D:03:A5:15 Bit Rate:2Mb/s Tx-Power=15 dBm Sensitivity:1/3 Retry min limit:8 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality:28/92 Signal level:151/153 Noise level:107/153 Rx invalid nwid:0 invalid crypt:0 invalid misc:0 The card now is ready for normal network operations. Special considerations about kernel configuration on certain card types: - PCMCIA IDE cards (CF and true-IDE) To support the ide CardService Client, the kernel have to be configured with general ATA IDE support. The MPC8XX IDE support (CONFIG_BLK_DEV_MPC8XX_IDE flag) have to be turned off. - PCMCIA modem cards The kernel have to be configured with standard serial port support (CONFIG_SERIAL flag). After the kernel bootup the following preparation is needed: mknod /dev/ttySp0 c 240 64 (/dev/ttyS0-4 and TTY_MAJOR 4 are already used by the standard 8xx uart driver). After the CardServices detects and initializes the PCMCIA card, the /dev/ttySp0 becomes available for use. - PCMCIA Wireless LAN cards Enable Network device support -- Wireless LAN (non-hamradio) -- Wireless LAN (non-hamradio) option in the kernel configuration (CONFIG_NET_RADIO flag). Note that the current version of the ELDK includes all required packages in the pcmcia-cs-ppc_8xx-3.2.1-1.ppc.rpm and wireless-tools-ppc_8xx-21-3.ppc.rpm RPMs Hope this helps. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de The most difficult thing in the world is to know how to do a thing and to watch someone else doing it wrong, without commenting. -- T.H. White ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
wireless lan PCMCIA card advice
Wolfgang, Excellent response once again thanks. I am running ELDK 2.0.2 which does have RPMs for pcmcia-cs and wireless-tools. I also see my target installation has the iwconfig program installed in /sbin. The target also has /etc/pcmcia/* and /etc/rc.d/init.d/pcmcia. From your email I gather all I need to do is recompile my kernel to include support for the wireless LAN (CONFIG_NET_RADIO) . Is that correct ? Cheers, Curt On Mon, Jan 06, 2003 at 10:58:16PM +0100, Wolfgang Denk wrote: Note that the current version of the ELDK includes all required packages in the pcmcia-cs-ppc_8xx-3.2.1-1.ppc.rpm and wireless-tools-ppc_8xx-21-3.ppc.rpm RPMs Hope this helps. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de The most difficult thing in the world is to know how to do a thing and to watch someone else doing it wrong, without commenting. -- T.H. White ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
