* linux-2.5-marvell tree deletion
From: Mark A. Greer @ 2005-02-18 23:27 UTC (permalink / raw)
To: David Woodhouse, Steven J. Hill, Brian Waite; +Cc: Embedded PPC Linux list
Dale Farnsworth has moved the mv64[34]60 enet driver to
bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet and all of the code
that I've worked on is either in linux-2.5 or on a queue to go in so
this tree should evaporate.
If you have an issue with this please let me know before the morning of
Wednesday, Feb 23, 2005; otherwise, I will delete it on Wednesday.
Thanks,
Mark
^ permalink raw reply
* Re: linux-2.5-marvell tree deletion
From: David Woodhouse @ 2005-02-18 23:30 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Brian Waite, Steven J. Hill, Embedded PPC Linux list
In-Reply-To: <421679DA.60005@mvista.com>
On Fri, 2005-02-18 at 16:27 -0700, Mark A. Greer wrote:
>Dale Farnsworth has moved the mv64[34]60 enet driver to
>bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet and all of the code
>that I've worked on is either in linux-2.5 or on a queue to go in so
>this tree should evaporate.
>
>If you have an issue with this please let me know before the morning of
>Wednesday, Feb 23, 2005; otherwise, I will delete it on Wednesday.
I've still got a copy with the local hacks I had for the Dy-4
DMV/SVME182 board; when I get time I'll try to get those finished and
sent upstream too. In the meantime I'm happy for you to delete yours --
thanks.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] emac: filter illegal frame sizes
From: Jeff Garzik @ 2005-02-19 8:48 UTC (permalink / raw)
To: Matt Porter; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20050218101245.D11439@cox.net>
Matt Porter wrote:
> Fix to drop frames that are too large for the current MTU.
What is this fixing?
You should be passing all frames up to the software stack.
Jeff
^ permalink raw reply
* Re: [PATCH][PPC32] PPC4xx ocp ide rewrite/cleanup
From: Andre' Draszik @ 2005-02-19 9:28 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050217103527.A5230@cox.net>
Hi,
Matt Porter wrote:
> Ok, this one looks good save a few minor things that need done:
i will address these as soon as i have time again, i.e. on wednesday.
> 1) Rename from ibm_ocp_ide.[c|h] to ibm_stb_ide.[c|h] We want
> rid of "ocp" in the file names since eventually 4xx will
> convert to platform devices.
is diff -N appropriate for that and convenient for you? as said, i'm using
the rsync mirror only, no bitkeeper.
> 2) Remove the #if 0'ed code...if it's not used it doesn't belong
> in there.
ok.
> 3) Run Lindent on the driver.
ok.
Shall I send the new patch against the one I already sent or against the
unpatched tree?
> What systems have you tested on?
On two different custom built boards both based on the redwood5 reference
design.
a.
^ permalink raw reply
* Re: [PATCH] Heartbeat LED for iBook
From: Brad Boyer @ 2005-02-19 19:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Nico Schottelius, linuxppc-dev list
In-Reply-To: <06fb81c4f23d0b47f8205b433fa6eb21@kernel.crashing.org>
On Fri, Feb 18, 2005 at 07:10:42PM +0100, Segher Boessenkool wrote:
> ADB has nothing to do with the PMU (well, the PMU emulates an ADB
> device, sort of).
>
> The Linux kernel multiplexes the /dev/adb device to also serve as
> a channel to the PMU, though. This ugliness should be fixed, some
> day...
The original PMU chip (in the Macintosh Portable) was used for
several purposes, including being the ADB transceiver. Most of
the revisions of the PMU that have shipped have still driven a
real ADB chain, although that has changed in more recent models.
The /dev/adb mess is a reflection of the mess that is the current
ADB subsystem in the kernel. You can write code in the kernel
that uses adb_request() to send non-adb PMU commands, and it
works due to the way it all works underneath. I was going to work
on it, but I got sidetracked with other issues that made it hard
to debug the various ADB drivers. If noone else gets to it, I
will eventually. I'm just not sure when I will have time.
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Cross-compile kernel modules
From: Markus Westergren @ 2005-02-20 9:49 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm trying to get loadable kernel modules support on a Adder development board.
The kernel is cross-compiled on an regular PC and boots fine but I can't insert
any modules into the running kernel, all I get is undefined reference for all
functions called by the module. I use the kernel module utilities (insmod,
lsmod, modprobe) supplied by BusyBox to manage the modules on the Adder board.
What am I doning wrong? Do I need to perform any aditional steps when
cross-compiling kernel modules? My cross-compile toolchain have no depmod so I
have no modules.dep file. But I only need it if a module depend on other
modules, right?
/Markus
-----------------
Markus Westergren
Biologigrand 17
907 32 Umea
SWEDEN
^ permalink raw reply
* Re: Cross-compile kernel modules
From: Chris Hallinan @ 2005-02-20 14:18 UTC (permalink / raw)
To: Markus Westergren; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.50.0502201034520.25626-100000@220a.licentiaten.umea.hsb.se>
On Sun, Feb 20, 2005 at 10:49:50AM +0100, Markus Westergren wrote:
> Hi,
>
> I'm trying to get loadable kernel modules support on a Adder development board.
> The kernel is cross-compiled on an regular PC and boots fine but I can't insert
> any modules into the running kernel, all I get is undefined reference for all
> functions called by the module. I use the kernel module utilities (insmod,
> lsmod, modprobe) supplied by BusyBox to manage the modules on the Adder board.
You don't give many details, but in general the above should
work, assuming you have properly built and configured your
kernel, modules and root file system.
> What am I doning wrong? Do I need to perform any aditional steps when
Yes. You need to make sure your modules are built from the same
kernel source tree, with the same configuration as the kernel you
are booting. Then you need to install those modules on your
target's root file system.
In general, you must do a 'make modules' followed by a 'make
modules_install' with INSTALL_MOD_PATH pointing to your target's
root file system. The details depend on how you've built your
rootfs and your cross-development setup. I usually mount my
rootfs image on a loop device somewhere, and point
INSTALL_MOD_PATH to it.
> cross-compiling kernel modules? My cross-compile toolchain have no depmod so I
Fix your development environment.
> have no modules.dep file. But I only need it if a module depend on other
> modules, right?
modprobe depends on modules.dep. You can run depmod on your
target assuming you have the depmod binary for your architecture
on your target file system.
Regards,
Chris
>
> /Markus
>
> -----------------
> Markus Westergren
> Biologigrand 17
> 907 32 Umea
> SWEDEN
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Chris Hallinan
clh at net1plus d0t com - via mutt/Linux
----------------------------------
^ permalink raw reply
* Freeing unused kernel memory: 56k init
From: srinivas.surabhi @ 2005-02-20 15:25 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 4996 bytes --]
When I tried to debug for the reason of "Freeing unused kernel memory:
56k init " hang problem the following is the printk outputs...
Entering kernel_read
Entering elf_map
map_addr was 0x30026000
Failed due to bad address
Entering padzero
...
>From the above can anything be concluded ?
One more doubt was, is it mandatory that the Virtual memory has to
enabled while building the Mounta Vista linux kernel ? Why because there
was an option to enable the kernel base address and if it is enabled it
asks for what is the address for the Kernel Virtual base address? If I
give 0x0 it works otherwise the Kernel itself is not at all booting.
Till the statement "Freeing unused kernel memory: 56k init" is coming
only if and if the 0x0 was given for the kernel virtual base address.
Thanks & Regards
-SS
________________________________
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org]
Sent: Friday, February 18, 2005 2:42 PM
To: linuxppc-embedded@ozlabs.org
Subject: Freeing unused kernel memory: 56k init
The latest update is that the init was also found in one of the
packages. So now I am not facing init not found problem . But there was
a hung problem, once the init is invoked .. Please find the output
below...
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1235k freed
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 56k init
< there is no output after the above statement.....>
Thanks & Regards
Surabhi Srinivas
________________________________
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Thu 2/17/2005 5:12 PM
Subject: Re: Mounta Vista Linux prompt on serial console
In message
<EF9B29C78F41FA488927FCBC7750AF0E08DA14@hyd-mdp-msg.wipro.com> you
wrote:
>
> But the problem is that it was stopping at
>
> "No init found. Try passing init= option to kernel". Before that
there
> were no errors. Everthing looks fine Mounted VFS root file system was
also
Fine. So you can mount the root filesystem, but it obviously does not
contain all the required files.
> seen. >From the net I understood is that the fstab file was the
cause. So
> edited the filesytem parameter for / as /dev/ram earlier it used to
be
> /dev/root.
No. /etc/fstab has absolutley nothing to do with your problem. The
kernel cannot start the init porocess - make sure init is in the
filesystem, plus all required libraries.
> So please tell me whether the given fstab file will suffice? The
filesystem
This is completley unrelated.
> 2. I have one more doubt /sbin/init utility comes with what package?
> Because in /sbin directory although the init binary is present, not
shown
> in the file system heirarchy view. For eg. if I select DHCPD package
then
> able to see dhcpd related binary in the /sbin similarly my question
was
> which package has to be selected to have init included.
Please contact MV support. I have no idea how they package their
distribution, or how their config tools might work. You paid for
their stuff, so ask _them_.
Best regards,
Wolfgang Denk
--
See us @ Embedded World, Nuremberg, Feb 22 - 24, Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
-- Isaac Asimov
Confidentiality Notice
The information contained in this electronic message and any attachments
to this message are intended
for the exclusive use of the addressee(s) and may contain confidential
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
Confidentiality Notice
The information contained in this electronic message and any attachments
to this message are intended
for the exclusive use of the addressee(s) and may contain confidential
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
Confidentiality Notice
The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
[-- Attachment #2: Type: text/html, Size: 14567 bytes --]
^ permalink raw reply
* [PATCH] ppc32: fix ptep_test_and_clear_young
From: Benjamin Herrenschmidt @ 2005-02-21 5:09 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: linuxppc-dev list
Hi !
ppc32's implementation of ptep_test_and_clear_young() has a logic error
which makes it fail to flush the hash table. Thus PAGE_ACCESSED is
almost never set again after beeing cleared (unless something else cause
that hash entry to be flushed).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/include/asm-ppc/pgtable.h
===================================================================
--- linux-work.orig/include/asm-ppc/pgtable.h 2005-01-24 17:09:50.000000000 +1100
+++ linux-work/include/asm-ppc/pgtable.h 2005-02-21 16:00:26.000000000 +1100
@@ -560,12 +560,12 @@
static inline int ptep_test_and_clear_young(pte_t *ptep)
{
unsigned long old;
- old = (pte_update(ptep, _PAGE_ACCESSED, 0) & _PAGE_ACCESSED);
+ old = pte_update(ptep, _PAGE_ACCESSED, 0);
#if _PAGE_HASHPTE != 0
if (old & _PAGE_HASHPTE)
flush_hash_one_pte(ptep);
#endif
- return old != 0;
+ return (old & _PAGE_ACCESSED) != 0;
}
static inline int ptep_test_and_clear_dirty(pte_t *ptep)
^ permalink raw reply
* Re: Freeing unused kernel memory: 56k init
From: David Jander @ 2005-02-21 7:37 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <EF9B29C78F41FA488927FCBC7750AF0E011DA65E@hyd-mdp-msg.wipro.com>
On Sunday 20 February 2005 16:25, srinivas.surabhi@wipro.com wrote:
> When I tried to debug for the reason of "Freeing unused kernel memory:
> 56k init " hang problem the following is the printk outputs...
>
> Entering kernel_read
>
> Entering elf_map
>
> map_addr was 0x30026000
Heh? Weired address. I'd expect something above 0xc0000000
> Failed due to bad address
No wonder....
> >From the above can anything be concluded ?
>
> One more doubt was, is it mandatory that the Virtual memory has to
> enabled while building the Mounta Vista linux kernel ? Why because there
> was an option to enable the kernel base address and if it is enabled it
> asks for what is the address for the Kernel Virtual base address? If I
> give 0x0 it works otherwise the Kernel itself is not at all booting.
Ok, don't say no more! Do not ever change that address unless you know exactly
what you are doing. It should be 0xc0000000 usually.
If the kernel doesn't boot, something else is wrong.
The linux kernel uses virtual memory, that's why it needs an MMU for instance.
That way, the memory the kernel uses and runs in is always mapped at address
0xc0000000.
> Till the statement "Freeing unused kernel memory: 56k init" is coming
> only if and if the 0x0 was given for the kernel virtual base address.
That's actually pretty funny. I'd never thought about doing such an experiment
and expecting it to do something :-)
Greetings,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Porting Linux into Flash and Execute in IBM PowerPC 405 stbx25xx.
From: Vijesh VH @ 2005-02-21 8:15 UTC (permalink / raw)
To: linuxppc-embedded, Paul Mackerras
I am Vijesh . I am now currently working on Linux for IBM power PC
Processor. I want to know, can anyone help me out in Porting the
Linux on to the PowerPC 405 stbx25xx Processor (via Flash).
--
Regards,
Vijesh
^ permalink raw reply
* kernel with marvell 64360 support
From: Suresh Chandra Mannava @ 2005-02-21 9:17 UTC (permalink / raw)
To: Embedded PPC Linux list
Hi,
We designed a power-pc 7410 board with galileo mv64360 bridge.
We are interested in porting linux on to that board.
Where can I download the linux kernel with 64360 (serial, ethernet, PCI
etc)
drivers.
please provide the pointers for the same.
Regards,
Suresh Chandra Mannava
^ permalink raw reply
* mkImage -e option for 4MB virtual entry point address of vmlinux
From: srinivas.surabhi @ 2005-02-21 9:48 UTC (permalink / raw)
To: david.jander, linuxppc-embedded
In the last lines of the build which contains the below
ppc_82xx-ld -T ../ld.script -Ttext 0x00400000 -Bstatic -o zvmlinux
head.o
means that the entry address is 0x400000 ( 4MB) . Does it mean that the
while making mkImage for the kernel the -e option should be given
0x400000? And the load address option should also be the same for linux
kernel image or Is it ok if the load address is 0x0 address?
Thanks & Regards
Surabhi Srinivas
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of David Jander
Sent: Monday, February 21, 2005 1:08 PM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Freeing unused kernel memory: 56k init
On Sunday 20 February 2005 16:25, srinivas.surabhi@wipro.com wrote:
> When I tried to debug for the reason of "Freeing unused kernel
memory:
> 56k init " hang problem the following is the printk outputs...
>
> Entering kernel_read
>
> Entering elf_map
>
> map_addr was 0x30026000
Heh? Weired address. I'd expect something above 0xc0000000
> Failed due to bad address
No wonder....
> >From the above can anything be concluded ?
>
> One more doubt was, is it mandatory that the Virtual memory has to
> enabled while building the Mounta Vista linux kernel ? Why because
there
> was an option to enable the kernel base address and if it is enabled
it
> asks for what is the address for the Kernel Virtual base address? If I
> give 0x0 it works otherwise the Kernel itself is not at all booting.
Ok, don't say no more! Do not ever change that address unless you know
exactly=0D
what you are doing. It should be 0xc0000000 usually.
If the kernel doesn't boot, something else is wrong.
The linux kernel uses virtual memory, that's why it needs an MMU for
instance.=0D
That way, the memory the kernel uses and runs in is always mapped at
address=0D
0xc0000000.
> Till the statement "Freeing unused kernel memory: 56k init" is coming
> only if and if the 0x0 was given for the kernel virtual base address.
That's actually pretty funny. I'd never thought about doing such an
experiment=0D
and expecting it to do something :-)
Greetings,
--=0D
David Jander
Protonic Holland.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Confidentiality Notice=0D
The information contained in this electronic message and any attachments to=
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or=
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or=
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
^ permalink raw reply
* Re: Cross-compile kernel modules
From: Markus Westergren @ 2005-02-21 10:37 UTC (permalink / raw)
To: Chris Hallinan; +Cc: Markus Westergren, linuxppc-embedded
In-Reply-To: <20050220141840.GC4565@net1plus.com>
On Sun, 20 Feb 2005, Chris Hallinan wrote:
> On Sun, Feb 20, 2005 at 10:49:50AM +0100, Markus Westergren wrote:
> > Hi,
> >
> > I'm trying to get loadable kernel modules support on a Adder development board.
> > The kernel is cross-compiled on an regular PC and boots fine but I can't insert
> > any modules into the running kernel, all I get is undefined reference for all
> > functions called by the module. I use the kernel module utilities (insmod,
> > lsmod, modprobe) supplied by BusyBox to manage the modules on the Adder board.
>
> You don't give many details, but in general the above should
> work, assuming you have properly built and configured your
> kernel, modules and root file system.
>
> > What am I doning wrong? Do I need to perform any aditional steps when
>
> Yes. You need to make sure your modules are built from the same
> kernel source tree, with the same configuration as the kernel you
> are booting. Then you need to install those modules on your
> target's root file system.
>
> In general, you must do a 'make modules' followed by a 'make
> modules_install' with INSTALL_MOD_PATH pointing to your target's
> root file system. The details depend on how you've built your
> rootfs and your cross-development setup. I usually mount my
> rootfs image on a loop device somewhere, and point
> INSTALL_MOD_PATH to it.
>
> > cross-compiling kernel modules? My cross-compile toolchain have no depmod so I
>
> Fix your development environment.
>
> > have no modules.dep file. But I only need it if a module depend on other
> > modules, right?
>
> modprobe depends on modules.dep. You can run depmod on your
> target assuming you have the depmod binary for your architecture
> on your target file system.
>
> Regards,
>
> Chris
>
> >
> > /Markus
> >
> > -----------------
> > Markus Westergren
> > Biologigrand 17
> > 907 32 Umea
> > SWEDEN
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
Thanks for your reply. I got it to work by upgrading my version of BusyBox to
1.00. Had 1.00-pre3 before which is really old.
^ permalink raw reply
* Re: AW: bdi2000 debugging
From: Andrey Volkov @ 2005-02-21 10:42 UTC (permalink / raw)
To: Martin Krause; +Cc: Sylvain Munaut, linuxppc-embedded
In-Reply-To: <DE2CC66C40EAB74EA6D66AC71BF98E1E03055B96@TQ-MAILSRV-1>
Martin Krause wrote:
> Hi,
>
> matej.kupljen@ultra.si wrote:
>
>>>L25R marking on the top means rev 1.2 IIRC. That's the one I have.
>>>Also, if you have a rev 2, you're lucky, I'd like one ;)
>>
>>Nope, mine has: 2L25R
>
>
> Mine also has a 2L25R marking, and it is rev 1.2
>
> U-Boot reads the System-On-Chip Version Register (SVR) and prints
> the version information while booting:
>
> U-Boot 1.1.3 (Feb 16 2005 - 10:38:30)
>
> CPU: MPC5200 v1.2 at 396 MHz
> Bus 132 MHz, IPB 132 MHz, PCI 66 MHz
> ...
>
> I don't think rev 2 is released officially, yet.
>
AFAIK they released this rev.(SPC5200CBV400R2) at November,
but it available only for big OEM's,
for others - it will be in second quarter of '05.
--
Regards
Andrey Volkov
^ permalink raw reply
* [PATCH] Non-DMA mode for floppy on PowerPC
From: Pavel Fedin @ 2005-02-21 21:49 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, Alain.Knaff
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
Nobody answered, repost again.
This patch allows to use floppy drive in non-DMA mode on PegasosPPC machines. To use it:
1. Do not build floppy driver as a module, link it statically. Transferring parameters to it from insmod is still problematic, at least it doesn't work properly on my system. May be i'll clean it up in future.
2. Specify floppy=nodma in kernel's arguments. Also you'll need to specify your drive type here using floppy=<Drive number>,<Drive type>,cmos. For example, floppy=0,4,cmos specifies type 4 (1.44 mb 3.5") for drive 0 on my system.
This patch does not affect operation of the driver in DMA mode so it's safe to use on any platform.
The patch is written for kernel version 2.6.8. Please merge it with -p0 argument, i already know it's wrong and will be more correct in the future.
--
Best regards,
Pavel Fedin, mailto:sonic_amiga@rambler.ru
[-- Attachment #2: ppc_floppy-vdma.diff --]
[-- Type: text/plain, Size: 5476 bytes --]
--- include/asm-ppc/floppy.h.orig 2004-08-14 09:36:45.000000000 +0400
+++ include/asm-ppc/floppy.h 2005-02-12 02:26:54.000000000 +0300
@@ -11,30 +11,188 @@
#ifndef __ASM_PPC_FLOPPY_H
#define __ASM_PPC_FLOPPY_H
+#include <linux/vmalloc.h>
+
+#define CSW fd_routine[can_use_virtual_dma & 1]
+
#define fd_inb(port) inb_p(port)
#define fd_outb(value,port) outb_p(value,port)
-#define fd_enable_dma() enable_dma(FLOPPY_DMA)
-#define fd_disable_dma() disable_dma(FLOPPY_DMA)
-#define fd_request_dma() request_dma(FLOPPY_DMA,"floppy")
-#define fd_free_dma() free_dma(FLOPPY_DMA)
-#define fd_clear_dma_ff() clear_dma_ff(FLOPPY_DMA)
-#define fd_set_dma_mode(mode) set_dma_mode(FLOPPY_DMA,mode)
-#define fd_set_dma_addr(addr) set_dma_addr(FLOPPY_DMA,(unsigned int)virt_to_bus(addr))
-#define fd_set_dma_count(count) set_dma_count(FLOPPY_DMA,count)
+#define fd_disable_dma() CSW._disable_dma(FLOPPY_DMA)
+#define fd_request_dma() CSW._request_dma(FLOPPY_DMA,"floppy")
+#define fd_free_dma() CSW._free_dma(FLOPPY_DMA)
+#define fd_get_dma_residue() CSW._get_dma_residue(FLOPPY_DMA)
+#define fd_dma_mem_alloc(size) CSW._dma_mem_alloc(size)
+#define fd_dma_setup(addr, size, mode, io) CSW._dma_setup(addr, size, mode, io)
#define fd_enable_irq() enable_irq(FLOPPY_IRQ)
#define fd_disable_irq() disable_irq(FLOPPY_IRQ)
-#define fd_cacheflush(addr,size) /* nothing */
-#define fd_request_irq() request_irq(FLOPPY_IRQ, floppy_interrupt, \
- SA_INTERRUPT|SA_SAMPLE_RANDOM, \
- "floppy", NULL)
#define fd_free_irq() free_irq(FLOPPY_IRQ, NULL);
-__inline__ void virtual_dma_init(void)
+static int virtual_dma_count;
+static int virtual_dma_residue;
+static char *virtual_dma_addr;
+static int virtual_dma_mode;
+static int doing_pdma;
+
+static irqreturn_t floppy_hardint(int irq, void *dev_id, struct pt_regs * regs)
+{
+ register unsigned char st;
+
+#undef TRACE_FLPY_INT
+
+#ifdef TRACE_FLPY_INT
+ static int calls=0;
+ static int bytes=0;
+ static int dma_wait=0;
+#endif
+ if (!doing_pdma)
+ return floppy_interrupt(irq, dev_id, regs);
+
+#ifdef TRACE_FLPY_INT
+ if(!calls)
+ bytes = virtual_dma_count;
+#endif
+ {
+ register int lcount;
+ register char *lptr;
+
+ st = 1;
+ for(lcount=virtual_dma_count, lptr=virtual_dma_addr;
+ lcount; lcount--, lptr++) {
+ st=inb(virtual_dma_port+4) & 0xa0 ;
+ if(st != 0xa0)
+ break;
+ if(virtual_dma_mode)
+ outb_p(*lptr, virtual_dma_port+5);
+ else
+ *lptr = inb_p(virtual_dma_port+5);
+ }
+ virtual_dma_count = lcount;
+ virtual_dma_addr = lptr;
+ st = inb(virtual_dma_port+4);
+ }
+
+#ifdef TRACE_FLPY_INT
+ calls++;
+#endif
+ if(st == 0x20)
+ return IRQ_HANDLED;
+ if(!(st & 0x20)) {
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
+#ifdef TRACE_FLPY_INT
+ printk("count=%x, residue=%x calls=%d bytes=%d dma_wait=%d\n",
+ virtual_dma_count, virtual_dma_residue, calls, bytes,
+ dma_wait);
+ calls = 0;
+ dma_wait=0;
+#endif
+ doing_pdma = 0;
+ floppy_interrupt(irq, dev_id, regs);
+ return IRQ_HANDLED;
+ }
+#ifdef TRACE_FLPY_INT
+ if(!virtual_dma_count)
+ dma_wait++;
+#endif
+ return IRQ_HANDLED;
+}
+
+static void vdma_disable_dma(unsigned int dummy)
{
- /* Nothing to do on PowerPC */
+ doing_pdma = 0;
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
}
+static int vdma_request_dma(unsigned int dmanr, const char * device_id)
+{
+ return 0;
+}
+
+static void vdma_nop(unsigned int dummy)
+{
+}
+
+
+static int vdma_get_dma_residue(unsigned int dummy)
+{
+ return virtual_dma_count + virtual_dma_residue;
+}
+
+
+static int fd_request_irq(void)
+{
+ if(can_use_virtual_dma)
+ return request_irq(FLOPPY_IRQ, floppy_hardint,SA_INTERRUPT,
+ "floppy", NULL);
+ else
+ return request_irq(FLOPPY_IRQ, floppy_interrupt,
+ SA_INTERRUPT|SA_SAMPLE_RANDOM,
+ "floppy", NULL);
+
+}
+
+static inline unsigned long dma_mem_alloc(unsigned long size)
+{
+ return __get_dma_pages(GFP_KERNEL,get_order(size));
+}
+
+
+static inline unsigned long vdma_mem_alloc(unsigned long size)
+{
+ return __get_free_pages(GFP_KERNEL,get_order(size));
+}
+
+static int vdma_dma_setup(char *addr, unsigned long size, int mode, int io)
+{
+ doing_pdma = 1;
+ virtual_dma_port = io;
+ virtual_dma_mode = (mode == DMA_MODE_WRITE);
+ virtual_dma_addr = addr;
+ virtual_dma_count = size;
+ virtual_dma_residue = 0;
+ return 0;
+}
+
+static int hard_dma_setup(char *addr, unsigned long size, int mode, int io)
+{
+ /* actual, physical DMA */
+ doing_pdma = 0;
+ clear_dma_ff(FLOPPY_DMA);
+ set_dma_mode(FLOPPY_DMA,mode);
+ set_dma_addr(FLOPPY_DMA,(unsigned int)virt_to_bus(addr));
+ set_dma_count(FLOPPY_DMA,size);
+ enable_dma(FLOPPY_DMA);
+ return 0;
+}
+
+struct fd_routine_l {
+ void (*_disable_dma)(unsigned int dmanr);
+ int (*_request_dma)(unsigned int dmanr, const char * device_id);
+ void (*_free_dma)(unsigned int dmanr);
+ int (*_get_dma_residue)(unsigned int dummy);
+ unsigned long (*_dma_mem_alloc) (unsigned long size);
+ int (*_dma_setup)(char *addr, unsigned long size, int mode, int io);
+} fd_routine[] = {
+ {
+ disable_dma,
+ request_dma,
+ free_dma,
+ get_dma_residue,
+ dma_mem_alloc,
+ hard_dma_setup
+ },
+ {
+ vdma_disable_dma,
+ vdma_request_dma,
+ vdma_nop,
+ vdma_get_dma_residue,
+ vdma_mem_alloc,
+ vdma_dma_setup
+ }
+};
+
static int FDC1 = 0x3f0;
static int FDC2 = -1;
^ permalink raw reply
* any hints using gcc 3.4.3 for 2.4.25 kernel?
From: Wojciech Kromer @ 2005-02-21 14:12 UTC (permalink / raw)
To: linuxppc-embedded
a)first i have:
- 2.4.25 kernel (from denx cvs)
- eldk with 2.95.4 compiler
this one set works fine :)
b)then, i've tried to same sources with:
gcc-3.4.3 , self build from uClibc buildroot
new hernel hangs just after decompressing :(
any tricks?
^ permalink raw reply
* Re: any hints using gcc 3.4.3 for 2.4.25 kernel?
From: Ralph Siemsen @ 2005-02-21 14:28 UTC (permalink / raw)
To: Wojciech Kromer; +Cc: linuxppc-embedded
In-Reply-To: <4219EC67.1070602@dgt-lab.com.pl>
Wojciech Kromer wrote:
> a)first i have:
> - 2.4.25 kernel (from denx cvs)
> - eldk with 2.95.4 compiler
> this one set works fine :)
>
> b)then, i've tried to same sources with:
> gcc-3.4.3 , self build from uClibc buildroot
> new hernel hangs just after decompressing :(
I haven't tried this on PPC, but under similar circumstances on ARM what
I learned was: there are several places in the kernel where lists are
generated by some linker tricks. For example all of the device
initialization functions are assembled into a list, so they can be
conveniently called in sequence.
The semantics for getting the linker to fill this list have changed. In
2.4 days they used ELF sections marked as "unnused", which were simply
ignored but passed through.
Newer toolchains now drop unnused sections, so the initialization tables
are not present in your kernel, which leads to the crash. I was able
kludge around this by changing in <asm/setup.h> and <linux/init.h>,
search for __attribute__((unused, ...) and change to "used" instead.
There are about half dozen occurrences, in the __init* and __exit*
macros. You then need some ugly casts in <linux/module.h> to match.
Of course the same thing could happen in other places/drivers, so really
the above is not a good solution. New 2.6 kernels handle this sort of
thing in a different way. Best solution is to keep an older gcc for
older kernels, and a newer one for 2.6...
-Ralph
^ permalink raw reply
* Re: Linux 2.6.x on 8xx status
From: Armin Schindler @ 2005-02-21 21:12 UTC (permalink / raw)
To: Dan Malek; +Cc: linux-ppc-embedded
In-Reply-To: <c5f8c158f9254cbb0a8e085cf0fda8de@embeddededge.com>
Hi Dan,
On Thu, 10 Feb 2005, Dan Malek wrote:
>
> On Feb 10, 2005, at 10:04 AM, Marcelo Tosatti wrote:
>
>> Does anyone have a clue of what is/can be wrong with the TLB entry for the
>> address being flushed at __flush_dcache_icache()?
>
> Not sure. The problem is that the __flush_dcache_icache is passed a
> user space virtual address that doesn't look like it is mapped for writing
> or something. I don't know, as an ooops isn't sufficient to debug the
> problem.
> You have to catch it here and track down the current state of the TLB and
> the page tables. Of course, when I do this everything looks OK, so what
> I've been trying to do is catch the TLBmiss reload that actually causes this
> to happen to see what it really tried to load into the tlb. A much more
> challenging project :-) I'll get it one of these days .....
any news on that issue?
I just started with an MPC855/859 and run into the same problem with
2.6.9.
Is there anything I can do or test?
Right now I'm not sure where to begin.
Even BDI-debugging would be possible...
Thanks,
Armin
---
Armin Schindler
SYSGO AG
Am Pfaffenstein 14
D-55270 Klein-Winternheim / Germany
Phone: +49 6136 9948-0
Fax : +49 6136 9948-10
armin.schindler@sysgo.com
www.sysgo.com
www.elinos.com
^ permalink raw reply
* Re: Linux 2.6.x on 8xx status
From: Guillaume Autran @ 2005-02-21 23:45 UTC (permalink / raw)
To: linux-ppc-embedded; +Cc: Armin Schindler
In-Reply-To: <Pine.LNX.4.61.0502212206420.14199@acs.sysgo.com>
Armin Schindler wrote:
> Hi Dan,
>
> On Thu, 10 Feb 2005, Dan Malek wrote:
>
>>
>> On Feb 10, 2005, at 10:04 AM, Marcelo Tosatti wrote:
>>
>>> Does anyone have a clue of what is/can be wrong with the TLB entry
>>> for the
>>> address being flushed at __flush_dcache_icache()?
>>
>>
>> Not sure. The problem is that the __flush_dcache_icache is passed a
>> user space virtual address that doesn't look like it is mapped for
>> writing
>> or something. I don't know, as an ooops isn't sufficient to debug the
>> problem.
>> You have to catch it here and track down the current state of the TLB
>> and
>> the page tables. Of course, when I do this everything looks OK, so what
>> I've been trying to do is catch the TLBmiss reload that actually
>> causes this
>> to happen to see what it really tried to load into the tlb. A much more
>> challenging project :-) I'll get it one of these days .....
>
>
> any news on that issue?
>
> I just started with an MPC855/859 and run into the same problem with
> 2.6.9.
>
> Is there anything I can do or test?
> Right now I'm not sure where to begin.
>
> Even BDI-debugging would be possible...
>
> Thanks,
> Armin
>
> ---
> Armin Schindler SYSGO AG
> Am Pfaffenstein 14
> D-55270 Klein-Winternheim / Germany
> Phone: +49 6136 9948-0
> Fax : +49 6136 9948-10
> armin.schindler@sysgo.com
> www.sysgo.com
> www.elinos.com
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
Hi all,
I am experiencing the same issue with 2.6.11-rc2 (see oops below).
And I also notice something else that may or may not be related. I see
that doing a DCBZ instruction on an invalid address "hangs" the process
doing it. My expectation was to get a crash/core instead of hanging
forever...
The code used is extremely simple (may be too simple ?):
int main( int argc, char **argv ) {
int *where = NULL;
int index = 0;
asm volatile ("dcbz %0,%1" : : "r"(index), "r"(where) );
return 1;
}
Also, the instruction left in the NIP by the Oops is:
0xc0004758 <__flush_dcache_icache+20>: dcbst r0,r3
Yet another dcbX instruction...
Does anyone know where do we go from here ??
Guillaume.
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C0004758 LR: C0009804 SP: C7C4BE10 REGS: c7c4bd60 TRAP: 0300 Not
tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 3000A038, DSISR: C2000000
TASK = c7c76ae0[24] 'ldconfig' THREAD: c7c4a000
Last syscall: 90
GPR00: C01C38C0 C7C4BE10 C7C76AE0 3000A000 00000100 00007FCB 3000A000
C03FC028
GPR08: C03FE300 C01C38C0 00000000 000FF960 00000000 10099C8C 000000D8
00000000
GPR16: 0000A038 3000A7F4 1009386B 00000007 7FFFFAD8 00000000 C03FE300
00000000
GPR24: 00000000 C67732B0 C01C38C0 3000A038 C03FC028 C01C08B0 07FCB889
C02FE960
NIP [c0004758] __flush_dcache_icache+0x14/0x40
LR [c0009804] update_mmu_cache+0x64/0x98
Call trace:
[c003aba0] do_no_page+0x4b8/0x54c
[c003ad28] handle_mm_fault+0xf4/0x2b4
[c0008de4] do_page_fault+0x208/0x424
[c0002ae8] handle_page_fault+0xc/0x80
.........
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
^ permalink raw reply
* Re: [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map
From: Meelis Roos @ 2005-02-22 8:36 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, Sven Hartge, Kernel Mailing List, Christian Kujau
In-Reply-To: <20041206185416.GE7153@smtp.west.cox.net>
> The PCI IRQ map for the old Motorola PowerStackII (Utah) boards was
> incorrect, but this breakage wasn't exposed until 2.5, and finally fixed
> until recently by Sebastian Heutling <sheutlin@gmx.de>.
Yesterday I finally got around to testing it. It seems the patch has
been applied in Linus's tree so I downloaded the latest BK and tried it.
Still does not work for me but this time it's different. Before the
patch SCSI worked fine but PCI NICs caused hangs. Now I can't test PCI
NICs because even the onboard 53c825 SCSI hangs - seems it gets no
interrupts.
It detects the HBA, tries device discovery, gets a timeout, ABORT,
timeout, TARGET RESET, timeout, BUS RESET, timeout, HOST RESET and there
it hangs.
Does it work for anyone else on Powerstack II Pro4000 (Utah)?
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* [PATCH] Non-DMA mode for floppy on PowerPC
From: Pavel Fedin @ 2005-02-22 17:18 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
Nobody answered, repost again.
This patch allows to use floppy drive in non-DMA mode on PegasosPPC machines. To use it:
1. Do not build floppy driver as a module, link it statically. Transferring parameters to it from insmod is still problematic, at least it doesn't work properly on my system. May be i'll clean it up in future.
2. Specify floppy=nodma in kernel's arguments. Also you'll need to specify your drive type here using floppy=<Drive number>,<Drive type>,cmos. For example, floppy=0,4,cmos specifies type 4 (1.44 mb 3.5") for drive 0 on my system.
This patch does not affect operation of the driver in DMA mode so it's safe to use on any platform.
The patch is written for kernel version 2.6.8. Please merge it with -p0 argument, i already know it's wrong and will be more correct in the future.
--
Best regards,
Pavel Fedin, mailto:sonic_amiga@rambler.ru
[-- Attachment #2: ppc_floppy-vdma.diff --]
[-- Type: text/plain, Size: 5477 bytes --]
--- include/asm-ppc/floppy.h.orig 2004-08-14 09:36:45.000000000 +0400
+++ include/asm-ppc/floppy.h 2005-02-12 02:26:54.000000000 +0300
@@ -11,30 +11,188 @@
#ifndef __ASM_PPC_FLOPPY_H
#define __ASM_PPC_FLOPPY_H
+#include <linux/vmalloc.h>
+
+#define CSW fd_routine[can_use_virtual_dma & 1]
+
#define fd_inb(port) inb_p(port)
#define fd_outb(value,port) outb_p(value,port)
-#define fd_enable_dma() enable_dma(FLOPPY_DMA)
-#define fd_disable_dma() disable_dma(FLOPPY_DMA)
-#define fd_request_dma() request_dma(FLOPPY_DMA,"floppy")
-#define fd_free_dma() free_dma(FLOPPY_DMA)
-#define fd_clear_dma_ff() clear_dma_ff(FLOPPY_DMA)
-#define fd_set_dma_mode(mode) set_dma_mode(FLOPPY_DMA,mode)
-#define fd_set_dma_addr(addr) set_dma_addr(FLOPPY_DMA,(unsigned int)virt_to_bus(addr))
-#define fd_set_dma_count(count) set_dma_count(FLOPPY_DMA,count)
+#define fd_disable_dma() CSW._disable_dma(FLOPPY_DMA)
+#define fd_request_dma() CSW._request_dma(FLOPPY_DMA,"floppy")
+#define fd_free_dma() CSW._free_dma(FLOPPY_DMA)
+#define fd_get_dma_residue() CSW._get_dma_residue(FLOPPY_DMA)
+#define fd_dma_mem_alloc(size) CSW._dma_mem_alloc(size)
+#define fd_dma_setup(addr, size, mode, io) CSW._dma_setup(addr, size, mode, io)
#define fd_enable_irq() enable_irq(FLOPPY_IRQ)
#define fd_disable_irq() disable_irq(FLOPPY_IRQ)
-#define fd_cacheflush(addr,size) /* nothing */
-#define fd_request_irq() request_irq(FLOPPY_IRQ, floppy_interrupt, \
- SA_INTERRUPT|SA_SAMPLE_RANDOM, \
- "floppy", NULL)
#define fd_free_irq() free_irq(FLOPPY_IRQ, NULL);
-__inline__ void virtual_dma_init(void)
+static int virtual_dma_count;
+static int virtual_dma_residue;
+static char *virtual_dma_addr;
+static int virtual_dma_mode;
+static int doing_pdma;
+
+static irqreturn_t floppy_hardint(int irq, void *dev_id, struct pt_regs * regs)
+{
+ register unsigned char st;
+
+#undef TRACE_FLPY_INT
+
+#ifdef TRACE_FLPY_INT
+ static int calls=0;
+ static int bytes=0;
+ static int dma_wait=0;
+#endif
+ if (!doing_pdma)
+ return floppy_interrupt(irq, dev_id, regs);
+
+#ifdef TRACE_FLPY_INT
+ if(!calls)
+ bytes = virtual_dma_count;
+#endif
+ {
+ register int lcount;
+ register char *lptr;
+
+ st = 1;
+ for(lcount=virtual_dma_count, lptr=virtual_dma_addr;
+ lcount; lcount--, lptr++) {
+ st=inb(virtual_dma_port+4) & 0xa0 ;
+ if(st != 0xa0)
+ break;
+ if(virtual_dma_mode)
+ outb_p(*lptr, virtual_dma_port+5);
+ else
+ *lptr = inb_p(virtual_dma_port+5);
+ }
+ virtual_dma_count = lcount;
+ virtual_dma_addr = lptr;
+ st = inb(virtual_dma_port+4);
+ }
+
+#ifdef TRACE_FLPY_INT
+ calls++;
+#endif
+ if(st == 0x20)
+ return IRQ_HANDLED;
+ if(!(st & 0x20)) {
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
+#ifdef TRACE_FLPY_INT
+ printk("count=%x, residue=%x calls=%d bytes=%d dma_wait=%d\n",
+ virtual_dma_count, virtual_dma_residue, calls, bytes,
+ dma_wait);
+ calls = 0;
+ dma_wait=0;
+#endif
+ doing_pdma = 0;
+ floppy_interrupt(irq, dev_id, regs);
+ return IRQ_HANDLED;
+ }
+#ifdef TRACE_FLPY_INT
+ if(!virtual_dma_count)
+ dma_wait++;
+#endif
+ return IRQ_HANDLED;
+}
+
+static void vdma_disable_dma(unsigned int dummy)
{
- /* Nothing to do on PowerPC */
+ doing_pdma = 0;
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
}
+static int vdma_request_dma(unsigned int dmanr, const char * device_id)
+{
+ return 0;
+}
+
+static void vdma_nop(unsigned int dummy)
+{
+}
+
+
+static int vdma_get_dma_residue(unsigned int dummy)
+{
+ return virtual_dma_count + virtual_dma_residue;
+}
+
+
+static int fd_request_irq(void)
+{
+ if(can_use_virtual_dma)
+ return request_irq(FLOPPY_IRQ, floppy_hardint,SA_INTERRUPT,
+ "floppy", NULL);
+ else
+ return request_irq(FLOPPY_IRQ, floppy_interrupt,
+ SA_INTERRUPT|SA_SAMPLE_RANDOM,
+ "floppy", NULL);
+
+}
+
+static inline unsigned long dma_mem_alloc(unsigned long size)
+{
+ return __get_dma_pages(GFP_KERNEL,get_order(size));
+}
+
+
+static inline unsigned long vdma_mem_alloc(unsigned long size)
+{
+ return __get_free_pages(GFP_KERNEL,get_order(size));
+}
+
+static int vdma_dma_setup(char *addr, unsigned long size, int mode, int io)
+{
+ doing_pdma = 1;
+ virtual_dma_port = io;
+ virtual_dma_mode = (mode == DMA_MODE_WRITE);
+ virtual_dma_addr = addr;
+ virtual_dma_count = size;
+ virtual_dma_residue = 0;
+ return 0;
+}
+
+static int hard_dma_setup(char *addr, unsigned long size, int mode, int io)
+{
+ /* actual, physical DMA */
+ doing_pdma = 0;
+ clear_dma_ff(FLOPPY_DMA);
+ set_dma_mode(FLOPPY_DMA,mode);
+ set_dma_addr(FLOPPY_DMA,(unsigned int)virt_to_bus(addr));
+ set_dma_count(FLOPPY_DMA,size);
+ enable_dma(FLOPPY_DMA);
+ return 0;
+}
+
+struct fd_routine_l {
+ void (*_disable_dma)(unsigned int dmanr);
+ int (*_request_dma)(unsigned int dmanr, const char * device_id);
+ void (*_free_dma)(unsigned int dmanr);
+ int (*_get_dma_residue)(unsigned int dummy);
+ unsigned long (*_dma_mem_alloc) (unsigned long size);
+ int (*_dma_setup)(char *addr, unsigned long size, int mode, int io);
+} fd_routine[] = {
+ {
+ disable_dma,
+ request_dma,
+ free_dma,
+ get_dma_residue,
+ dma_mem_alloc,
+ hard_dma_setup
+ },
+ {
+ vdma_disable_dma,
+ vdma_request_dma,
+ vdma_nop,
+ vdma_get_dma_residue,
+ vdma_mem_alloc,
+ vdma_dma_setup
+ }
+};
+
static int FDC1 = 0x3f0;
static int FDC2 = -1;
^ permalink raw reply
* Re: [PATCH] Non-DMA mode for floppy on PowerPC
From: Eugene Surovegin @ 2005-02-22 9:32 UTC (permalink / raw)
To: Pavel Fedin; +Cc: linuxppc-dev
In-Reply-To: <20050222121809.351088dc.sonic_amiga@rambler.ru>
On Tue, Feb 22, 2005 at 12:18:09PM -0500, Pavel Fedin wrote:
> Nobody answered, repost again.
Please, be patient and don't repost the same stuff every day.
--
Eugene.
^ permalink raw reply
* Re: [PATCH] Non-DMA mode for floppy on PowerPC
From: Pavel Fedin @ 2005-02-22 18:06 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev
In-Reply-To: <20050222093208.GE27891@gate.ebshome.net>
On Tue, 22 Feb 2005 01:32:09 -0800
Eugene Surovegin <ebs@ebshome.net> wrote:
> Please, be patient and don't repost the same stuff every day.
Ok. How long does it take for a patch to get included into the kernel? I posted if two weeks ago for the first time and nothing happened. In LKML also nobody answers.
--
Best regards,
Pavel Fedin, mailto:sonic_amiga@rambler.ru
^ permalink raw reply
* FCC on 8560 ADS
From: Jose Almeida @ 2005-02-22 10:41 UTC (permalink / raw)
To: linuxppc-embedded
All,
I'm trying to get a linux 2.6 kernel up and running on an freescale 8560
ADS board. I have every peace of this up and running apart from the FCC
ethernet.
I've switched to the legacy mode, which now allow me to talk to the PHY
and negocite properly @ 100BT FD.
But I don't seem to get any ethernet packet going out. The FCC
controller does not seem to read the BDs, and all the packet's I'm
placing in the BD just stay there for ever !
I'm wondering if you have a driver which works properlly ? I'm thinking
on some wrong setup in the ioports, but is all seems to be correct !
I'm using a 2.6.9 kernel, but I also tryed other versions (2.6.11r4),
with the same problems ...
Thanks
Jose
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox