Re: Wireless Linux(802.11) for Embedded PowerPC
On Tue, Sep 05, 2006 at 04:03:55PM -0400, [EMAIL PROTECTED] wrote: Where is the best access point for this topic? Did anyone work on this with MPC8xx? Thanks. Probably [EMAIL PROTECTED] Is there anything about your wireless needs that is specific to embedded work? John -- John W. Linville [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC8245 reset register
LoL, my bad not understanding the humor.
This becomes an interesting topic. I looked at different CPUs, it seems
everyone uses different method to reset itself, and there is no uniformed or
easy for 603e. I searched on google but didn't see anyone have similiar
concern. Actually lots of boxes/systems using MPC8245, why nobody cares
about it? :)
To use watchdog timeout, or gpio port to assert reset line on CPU are not
flexible enough. If using watchdog, I have to enable watchdog and reduce the
timeout length (if it's too long). If using some GPIO device, I'll have to
rely on i2c bus or whatever io interface to write data. Acutally our system
has RESET by a GPIO(PCA9556) port.
Interesting enough, I resolved the problem by writing a data to an invalid
address with hoping for a machine check exception (in fact this is what
u-boot does). Would it be good to make it as a stardard restart function
in mpc10x_common.c? If it's acceptable I could send out my patch.
- Reeve
On 9/6/06, Jon Scully jonscully at gmail.com wrote:
On 9/5/06, Reeve Yang yang.reeve at gmail.com wrote:
I'm kind of curious what's the proper way to reset the
8245 CPU? For anyone who doesn't know MPC8245, which is 603e core.
You could starve the watchdog (assuming SWE=1 in SYPCR). If you own
the hardware design, you could add an addressable WO latch (FPGA) that
asserts reset for the right number of clock cycles (what I would
normally provide or ask for in a design -- but *only* during
development). Otherwise... If this is for development purposes,
consider using JTAG (Boundary Scan) to control /SRESET.
(My reference to RST was supposed to be humorous -- as in, remember
the good old days when you could do that in S/W?! ('RST 7' in Z80
8085) Sorry for my bad humor.)
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
-- next part --
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060906/3a42d9f1/attachment.htm
MPC5200 SPI interface.
Hi all, We are developping a Lite5200B based custom board and we are planning to connect some SPI peripherals. But we are not sure about what MPC5200 SPI interface choose. Does anyone know what are the advantages/disadvantages of use the MPC5200 SPI dedicated interface or an PSC (PSC3) as the SPI interface?. The linux kernel includes both interfaces but we can not see in the documentation anything about this aspect. Any kind of information will be welcomed. Best Regards, Jos? Mar?a L?pez. -- next part -- A non-text attachment was scrubbed... Name: tlopez.vcf Type: text/x-vcard Size: 324 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060906/2093dd55/attachment.vcf
MAC driver issue
FWIW, in my experience the hardware independent parts of the networking stack are very stable and the problem is almost always with the drivers, or with the IP configuration (e.g. two interfaces on the same subnet). I have no doubt it is with the driver. I am somewhat fortunate in this instance that I have a nearly identical setup - this is an FPGA based system I can swap the FPGA firmware, get an almost identical kernel with a slightly different NIC, and everything works - same cables, same IP's, Same switch, The only things different are the NIC and its driver. Even the Linux kernels are identical - except the NIC driver. BUT so is the data received and passed on to the kernel (outside random differences in the padding of the ARP packet) One works the other doesn't. Well ethernet device drivers contain multiple arp supporting methods, e.g. header_cache, header_cache_update, hard_header_parse, etc etc. Generally driver writers don't need to concern themselves about these as they are assigned to generic handlers by ether_setup(). However, your problematic driver may do something different. Given this problem appears to be driver specific rather than PPC specific your best bet is to try and contact the author. BTW, I don't think you've said which driver you are using, a key piece of info Alex
Wireless Linux(802.11) for Embedded PowerPC
On Tue, Sep 05, 2006 at 04:03:55PM -0400, wei.li4 at elf.mcgill.ca wrote: Where is the best access point for this topic? Did anyone work on this with MPC8xx? Thanks. Probably netdev at vger.kernel.org. Is there anything about your wireless needs that is specific to embedded work? John -- John W. Linville linville at tuxdriver.com
Wireless Linux(802.11) for Embedded PowerPC
On Wed, Sep 06, 2006 at 09:30:00AM +0800, Chun Chung Lo wrote: 1. WLAN card driver: linux-wlan -- http://www.linux-wlan.org/ Is this project even still active? The last update to the page was 2.5 years ago (2/2004), and many of the links are broken... Do the prism drivers in the upstream kernel not work for you? John -- John W. Linville linville at tuxdriver.com
MAC driver issue
I have no doubt it is with the driver. I am somewhat fortunate in this instance that I have a nearly identical setup - this is an FPGA based system I can swap the FPGA firmware, get an almost identical kernel with a slightly different NIC, and everything works - same cables, same IP's, Same switch, The only things different are the NIC and its driver. Even the Linux kernels are identical - except the NIC driver. BUT so is the data received and passed on to the kernel (outside random differences in the padding of the ARP packet) Why is the ARP packet padding random? I would think it would be fixed, since the ARP packet itself is a fixed length (for IPv4-Ethernet ARPs) and the minimum Ethernet frame is 64 bytes... One works the other doesn't. Well ethernet device drivers contain multiple arp supporting methods, e.g. header_cache, header_cache_update, hard_header_parse, etc etc. Generally driver writers don't need to concern themselves about these as they are assigned to generic handlers by ether_setup(). However, your problematic driver may do something different. Given this problem appears to be driver specific rather than PPC specific your best bet is to try and contact the author. BTW, I don't think you've said which driver you are using, a key piece of info Might I suggest putting static ARP entries in the kernel (use the arp command from a prompt) and some other packet traffic - UDP perhaps. See if the problem is specifically with the way your network driver handles ARP packets, or if it's a more fundamental problem of how the driver hands any type of Ethernet packet off to the upper kernel stack layers.
Continuous Login Loop
On 9/6/06, Clint Thomas cthomas at soneticom.com wrote: Hey, I'm running the latest kernel pull from the mvista powerpc 2.4 dev source. I built a root file system using Busybox 1.2.0 and the mkrootfs script by Wolfgang Klingauf (removed all DOS carriage returns). When the system boots up, i'm getting this output. Mounted devfs on /dev Freeing unused kernel memory: 44k init init started: BusyBox v1.2.0 (2006.09.06-19:44+) multi-call binary Starting pid 10, console /dev/console: '/etc/init.d/rcS' Bummer, could not run '/etc/ PowerPC Linux 2.4.26 (none) login: root Process '/sbin/getty 38400 tts/0' (pid 11) exited. Scheduling i PowerPC Linux 2.4.26 (none) login: it keeps looping through the login every time I try to enter root. I have the root user in the passwd file, and I believe I have the RFS setup properly. What would cause this kind of an issue? Is this a problem related to getty? or just a missing file or device of some kind? Thanks Hi Clint, You know in the back of my head (very dusty place) I seem to recall that this is a Busybox issue with getty. Something about security. Not sure... but I'd check with their forums. -stv Clinton Thomas ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
