mpc8xx and ld.so problem
> > The PPC32 dbcz semantics don't seem to work properly on 8xx > > in all cases. Removing the '.S' file makes glibc fall back on > > the .c implementation. > > Hi Jason, > > That was a quick response - thanks. > > Two questions: > > - Do you happen to know about details of dcbz's (mis)behaviour on 8xx? This is the famus dcbX bug on 8xx CPUs. 8xx dcbX instructions don't update the DAR register when they cause a TLB Miss/Error. This bug is undocumented but Motorola/Freescale has verified that it is there. Jocke (going on vacation now, won't read email for a week)
PPC bn_div_words routine rewrite
> The reason I had to redo this routine, in case anyone is wondering, is > because ssh-keygen segfaults when this assembly routine returns junk > to the BN_div_word function. On a ppc, if you issue the command > > ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N "" > > The program craps out when it tries to write the public key in ascii decimal. If would help if you provide evidence such as debugger stack trace and program output. Provided description makes no sense. "seg-faults when routine returns junk to BN_div_word"? Seg-fault [segmentation violation] can occur when you write something to memory and nothing gets written to memory upon result return. BN_div_word does write to memory, but I fail to see how a bogus value could possibly trigger seg-fault. The only possibility is that assembler doesn't follow ABI convention and corrupts registers, which caller is using/expects to be preserved by callee. There're several PPC ABI flavors in use, but OpenSSL routines were designed ABI-neutral, Well, "neutrality" really means "common denominator for ABI specs examined at the moment of coding," so there is a window of opportunity that it won't be "neutral" to future ABI, but is it really case? That your system uses some newly designed PPC ABI? You never mentioned what's your system... But you're apparently right about a bug being present in PPC assembler. I too have got insane [with very few significant digits] decimal printout of public key generated by ssh-keygen... >>This is a rewrite of the bn_div_words routine for the PowerPC arch, >>tested on a MPC8xx processor. Well, suggested routine apparently sends ssh-keygen on the PPC-based 32-bit system I have access to to an end-less loop... And (cd test; make test_bn) fails early in BN_sqr... And test/exptest fails miserably with "bad reciprocal"... >>I initially thought there is maybe a small mistake in the code that >>requires a one-liner change But apparently this appears to be the case! Please verify following: --- crypto/bn/asm/ppc.pl.orig2004-04-28 00:05:50.0 +0200 +++ crypto/bn/asm/ppc.pl 2005-07-01 18:58:21.105656512 +0200 @@ -1717,7 +1717,7 @@ li r9,1# r9=1 $SHLr10,r9,r8 # r9<<=r8 $UCMP 0,r3,r10# - bc BO_IF,CR0_GT,Lppcasm_div2 #or if (h > (1< (1<
MPC85xx DMA support for Kernel 2.6?
On Fri, 01 Jul 2005 09:54:44 +0200, Clemens Koller writes: >Is there any interest to publish this and the other patches >and get it into 2.6 if not already planned? Well, I'd certainly be interested. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen at csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.
MPC85xx DMA support for Kernel 2.6?
On Jul 1, 2005, at 10:15 AM, Mark Chambers wrote: > Is the SRAM being cached? I don't think the CPU will generate bursts > unless it's cached, right? I don't really remember :-) I know the 8xx will not burst if the line isn't cached, and I know the 7xxx will. I thought the 82xx and 85xx would also burst if you had sufficient sequential operations queued. On 83/85xx you have to further qualify the discussion based upon the DDR2 or the local bus interface :-) The CPM and DMA will burst on all buses for 8xx/82xx/83xx/85xx if the memory controller is configured to do so. I always end up writing code to test it, then those brain cells get replaced by more meaningful experiences before I have to use them again :-) Thanks. -- Dan
mpc8xx and ld.so problem
On Fri, 2005-07-01 at 07:17 -0300, Marcelo Tosatti wrote: > That was a quick response - thanks. > > Two questions: > > - Do you happen to know about details of dcbz's (mis)behaviour on 8xx? > > I ask that mainly because I worry about in-kernel dcbz users. IIRC, it isn't used in any 8xx code paths. > - Shouldnt upstream glibc have that fixed for 8xx by now? Ha. Funny. The glibc powerpc maintainer doesn't want any embedded fixes in the mainline. Last I checked, that was for 'the tools vendors' to fix. "We won't work around processor bugs" is their philosophy. I went through a similar (unsuccessful) battle with the amcc 440ep's "blrl" errata and gcc/glibc. It would be nice if the politics there have changed (maybe they just didn't like me personally), but I don't have much hope. -- Jason McMullan "Sure, send me the latest Knoppix DVD as an attachment..." -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050701/3582fda4/attachment.pgp
mpc8xx and ld.so problem
On Fri, Jul 01, 2005 at 02:56:30PM -0400, Jason McMullan wrote: > On Fri, 2005-07-01 at 07:17 -0300, Marcelo Tosatti wrote: > > That was a quick response - thanks. > > > > Two questions: > > > > - Do you happen to know about details of dcbz's (mis)behaviour on 8xx? > > > > I ask that mainly because I worry about in-kernel dcbz users. > > IIRC, it isn't used in any 8xx code paths. OK! > > - Shouldnt upstream glibc have that fixed for 8xx by now? > > Ha. Funny. The glibc powerpc maintainer doesn't want any embedded > fixes in the mainline. Who is that? > Last I checked, that was for 'the tools vendors' to fix. Silly - so embedded developers are supposed rely on "embedded vendors" and not on the mainstream software distributions? > "We won't work around processor bugs" is their philosophy. > > I went through a similar (unsuccessful) battle with the > amcc 440ep's "blrl" errata and gcc/glibc. > > It would be nice if the politics there have changed > (maybe they just didn't like me personally), but I don't have > much hope. If enough people complain they will, hopefully, listen.
mpc8xx and ld.so problem
On Fri, 2005-07-01 at 06:44 -0300, Marcelo Tosatti wrote: > Hi Anton, > > > (moving to ppc-embedded since it might be of interesting for other > 8xx users) > Apply this patch to glibc, and recompile: rm -f glibc/sysdeps/powerpc/powerpc32/memset.S The PPC32 dbcz semantics don't seem to work properly on 8xx in all cases. Removing the '.S' file makes glibc fall back on the .c implementation. -- Jason McMullan "Sure, send me the latest Knoppix DVD as an attachment..." -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050701/d36f7b32/attachment.pgp
MPC85xx DMA support for Kernel 2.6?
> > On Jul 1, 2005, at 3:47 AM, Clemens Koller wrote: > > > And currently, when I access (memcopy) the SRAM on my > > Local Bus via UPM I cannot get it to generate bursts yet, so I hope the > > DMA will speed up those things, too. > > If the CPU won't do it, the DMA won't either. You better get that > UPM working first :-) > > > -- Dan > Is the SRAM being cached? I don't think the CPU will generate bursts unless it's cached, right? Mark Chambers
MPC85xx DMA support for Kernel 2.6?
On Jul 1, 2005, at 3:47 AM, Clemens Koller wrote: > And currently, when I access (memcopy) the SRAM on my > Local Bus via UPM I cannot get it to generate bursts yet, so I hope the > DMA will speed up those things, too. If the CPU won't do it, the DMA won't either. You better get that UPM working first :-) -- Dan
[PATCH] ppc32: explicitly disable 440GP IRQ compatibility mode in 440GX setup
Andrew,
the following patch adds explicit disabling of 440GP IRQ compatibility
mode when configuring 440GX interrupt controller. This helps when
board firmware for some reason uses this compatibility mode and
leaves it enabled. It breaks 440GX interrupt code because it assumes
native 440GX IRQ mode. People seems to be continuously bitten by this.
Signed-off-by: Eugene Surovegin
diff --git a/arch/ppc/syslib/ppc4xx_pic.c b/arch/ppc/syslib/ppc4xx_pic.c
--- a/arch/ppc/syslib/ppc4xx_pic.c
+++ b/arch/ppc/syslib/ppc4xx_pic.c
@@ -110,6 +110,10 @@ static int ppc4xx_pic_get_irq(struct pt_
static void __init ppc4xx_pic_impl_init(void)
{
+#if defined(CONFIG_440GX)
+ /* Disable 440GP compatibility mode if it was enabled in firmware */
+ SDR_WRITE(DCRN_SDR_MFR, SDR_READ(DCRN_SDR_MFR) & ~DCRN_SDR_MFR_PCM);
+#endif
/* Configure Base UIC */
mtdcr(DCRN_UIC_CR(UICB), 0);
mtdcr(DCRN_UIC_TR(UICB), 0);
[PATCH] 8xx: map_page() skip pinned region and tlbie debugging aid
Benjamin Herrenschmidt wrote: > On Thu, 2005-06-30 at 14:05 -0400, Dan Malek wrote: > >>On Jun 29, 2005, at 7:31 PM, Benjamin Herrenschmidt wrote: >> >> >>> - The debate between Dan and me here is about the semantics of >>>io_block_mapping(). >> >>My point of discussion is this function needs to be much smarter than >>simply allocating a virtual address space. We need to track the calls >>so that we can "grow" previous spaces. A single io_block_mapping() >>should not always allocate a new BAT, CAM or otherwise wired entry. >>It has to know the alignment, size and amount of resource available. >>For example, if an io_block_mapping() requests a 4M space, and it >>isn't possible to wire such a size, we still need to keep track of that >>such that a subsequent 4M request is combined into a space that >>can be wired with an 8M entry. We need to make it smart enough >>to coalesce the spaces to maximize the use of the available and >>minimal mapping resources. If io_block_mapping() is just a simple >>functions that decrements a pointer and sets a value in a register, >>then you have already required the caller to know everything about >>the mapping details, so why bother performing "hidden" arithmetic >>that is likely to be known by the caller? If we are going to change >>this > > > Everyting ... but the virtual address, which is quite a bit :) My > problem is really with virtual addresses beeing hard coded, which makes > things complicated every time we try to do something with the kenrel > virtual space. But > > >>let's make it tru >>y useful, so it understands the capabilities of the >>processor, optimizes the resources, and keeps generic mapping >>information so ioremap() doesn't care if it is mapped by BATs, CAMs, >>or large pages. > > > ... I do agree that making it even smarter so it can coalesce block > mappings with the same attributes would be "interesting". > > Ben. > > Let me pop in here. My remote heap allocator has these properties, i.e. it can coalesce adjucent areas if they are of the same "key". Back to the depths which I now reside... Regards Pantelis
MPC85xx DMA support for Kernel 2.6?
Hi, Murray! Hello, Jason! Thank you very much! It seems like you saved my holiday! :-))) I will have a look and see what I can find there. Is there any interest to publish this and the other patches and get it into 2.6 if not already planned? Best regards, Clemens Koller ___ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 Murray.Jensen at csiro.au wrote: > On Thu, 30 Jun 2005 17:56:30 +0200, Clemens Koller writes: > >>But is there any code available for recycling? > > > Jason McMullan has some code for mpc85xx dma here: > > http://www.evillabs.net/~gus/patches/mpc85xx_dma.patch > > Looks like it wouldn't take much to get it working. Cheers! > Murray... > -- > Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 > Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 > Internet: Murray.Jensen at csiro.au > > To the extent permitted by law, CSIRO does not represent, warrant and/or > guarantee that the integrity of this communication has been maintained or > that the communication is free of errors, virus, interception or interference. > > The information contained in this e-mail may be confidential or privileged. > Any unauthorised use or disclosure is prohibited. If you have received this > e-mail in error, please delete it immediately and notify Murray Jensen on > +61 3 9662 7763. Thank you. >
MPC85xx DMA support for Kernel 2.6?
Hi, Dan! Dan Malek wrote: > Before you start, just make sure such a thing is really a performance > enhancement. Yes, the DMA does run in parallel with the core, but often > the overhead of the set up and clean up interrupt is more code and time > that if you just copied the data in a loop. If possible, integrate the DMA > processing into other driver work, clean up a previous DMA the next time > the driver needs to use it, not with a separate completion handler. Well... thanks. But the CPU is intended to do image processing while data comes in. And currently, when I access (memcopy) the SRAM on my Local Bus via UPM I cannot get it to generate bursts yet, so I hope the DMA will speed up those things, too. Greets, Clemens Koller ___ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
[PATCH] 8xx: map_page() skip pinned region and tlbie debugging aid
On Thu, 2005-06-30 at 14:05 -0400, Dan Malek wrote: > On Jun 29, 2005, at 7:31 PM, Benjamin Herrenschmidt wrote: > > > - The debate between Dan and me here is about the semantics of > > io_block_mapping(). > > My point of discussion is this function needs to be much smarter than > simply allocating a virtual address space. We need to track the calls > so that we can "grow" previous spaces. A single io_block_mapping() > should not always allocate a new BAT, CAM or otherwise wired entry. > It has to know the alignment, size and amount of resource available. > For example, if an io_block_mapping() requests a 4M space, and it > isn't possible to wire such a size, we still need to keep track of that > such that a subsequent 4M request is combined into a space that > can be wired with an 8M entry. We need to make it smart enough > to coalesce the spaces to maximize the use of the available and > minimal mapping resources. If io_block_mapping() is just a simple > functions that decrements a pointer and sets a value in a register, > then you have already required the caller to know everything about > the mapping details, so why bother performing "hidden" arithmetic > that is likely to be known by the caller? If we are going to change > this Everyting ... but the virtual address, which is quite a bit :) My problem is really with virtual addresses beeing hard coded, which makes things complicated every time we try to do something with the kenrel virtual space. But > let's make it tru > y useful, so it understands the capabilities of the > processor, optimizes the resources, and keeps generic mapping > information so ioremap() doesn't care if it is mapped by BATs, CAMs, > or large pages. ... I do agree that making it even smarter so it can coalesce block mappings with the same attributes would be "interesting". Ben.
MPC85xx DMA support for Kernel 2.6?
Well, this goes back to my comment on there not being a set of generic kernel APIs for general purpose DMA engines. Otherwise, I'd rather leave this out of the kernel proper. - kumar On Jul 1, 2005, at 3:36 AM, wrote: > On Fri, 01 Jul 2005 09:54:44 +0200, Clemens Koller writes: > >> Is there any interest to publish this and the other patches >> and get it into 2.6 if not already planned? >> > > Well, I'd certainly be interested. Cheers! > > Murray... > -- > Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 > 9662 > 7763 > Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 > 9662 > 7853 > Internet: Murray.Jensen at csiro.au > > To the extent permitted by law, CSIRO does not represent, warrant > and/or > guarantee that the integrity of this communication has been maintained > or > that the communication is free of errors, virus, interception or > interference. > > The information contained in this e-mail may be confidential or > privileged. > Any unauthorised use or disclosure is prohibited. If you have received > this > e-mail in error, please delete it immediately and notify Murray Jensen > on > +61 3 9662 7763. Thank you. > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded >
mpc8xx and ld.so problem
On Fri, Jul 01, 2005 at 10:55:16AM -0400, Jason McMullan wrote: > On Fri, 2005-07-01 at 06:44 -0300, Marcelo Tosatti wrote: > > Hi Anton, > > > > > > (moving to ppc-embedded since it might be of interesting for other > > 8xx users) > > > > Apply this patch to glibc, and recompile: > > rm -f glibc/sysdeps/powerpc/powerpc32/memset.S > > > The PPC32 dbcz semantics don't seem to work properly on 8xx > in all cases. Removing the '.S' file makes glibc fall back on > the .c implementation. Hi Jason, That was a quick response - thanks. Two questions: - Do you happen to know about details of dcbz's (mis)behaviour on 8xx? I ask that mainly because I worry about in-kernel dcbz users. - Shouldnt upstream glibc have that fixed for 8xx by now?
mpc8xx and ld.so problem
Hi Anton, (moving to ppc-embedded since it might be of interesting for other 8xx users) On Thu, Jun 30, 2005 at 04:13:30PM +0200, Anton W?llert wrote: > Hello Marcelo > > I suggest you should find out why binaries hang and where. > > > > You can see where processes are sleeping with: > > > > ps -axeo "command nwchan" > > > > thank you for that tip. but i found out (what i should have had to do > before), that the application doesn't hang in kernel-mode. so wchan doesn't > say anything. but with gdb i saw the problem, the application hangs in the > function memset at the instruction dcbz, this should be a instruction, that > loops until it something is zero or so ( sorry, that i didn't looked up it > yet, i will do that ). and because of the bug of these dcbx instructions on > 8xx i think, that this is the cause. here my gdb-session, i hope you may > find it helpful or give me an advise how to fix that : > > awoeller at zwiebel > :~/ToolChains/new.usr.chain/powerpc-linux-toolchain/src/busybox-1.00$powerpc-linux-gdb > GNU gdb 6.3 > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "--host=i686-linux --target=powerpc-linux". > (gdb) set solib-absolute-prefix /tmp/fakelibc > (gdb) file busybox > Reading symbols from > /home/awoeller/ToolChains/new.usr.chain/powerpc-linux-toolchain/src/busybox- > 1.00/busybox...done. > (gdb) b main > Breakpoint 1 at 0x1000398c: file > /home/awoeller/ToolChains/new.usr.chain/powerpc-linux-toolchain/src/busybox- > 1.00/applets/busybox.c, line 75. > (gdb) target remote tqm850l:123 > Remote debugging using tqm850l:123 > 0x300103f4 in ?? () > (gdb) cont > Continuing. > # here i interrupt, because it hangs > Program received signal SIGINT, Interrupt. > 0x30013e58 in ?? () > (gdb) return > Make selected stack frame return now? (y or n) y > #0 0x3000e374 in ?? () > (gdb) cont > Continuing. > > Breakpoint 1, main (argc=1, argv=0x7eb4) at > /home/awoeller/ToolChains/new.usr.chain/powerpc-linux-toolchain/src/busybox- > 1.00/applets/busybox.c:75 > 75 bb_applet_name = argv[0]; > > (gdb) disas 0x30013e58 > Dump of assembler code for function memset: > 0x30013ba4 : cmplwi cr1,r5,4 > 0x30013ba8 : andi. r7,r3,3 > 0x30013bac : mr r6,r3 > 0x30013bb0 : ble- cr1,0x30013d40 > 0x30013bb4 : cmplwi cr5,r5,31 > 0x30013bb8 : rlwimi r4,r4,8,16,23 > 0x30013bbc : beq+ 0x30013be0 > 0x30013bc0 : mtcrf 1,r3 > 0x30013bc4 : subfic r7,r7,4 > 0x30013bc8 : add r6,r6,r7 > 0x30013bcc : subf r5,r7,r5 > 0x30013bd0 : bns+ cr7,0x30013bdc > 0x30013bd4 : stb r4,0(r3) > 0x30013bd8 : beq- cr7,0x30013be0 > 0x30013bdc : sth r4,-2(r6) > 0x30013be0 : mtcrf 1,r5 > 0x30013be4 : rlwimi r4,r4,16,0,15 > 0x30013be8 : ble- cr5,0x30013d80 > 0x30013bec : andi. r7,r6,28 > 0x30013bf0 : subfic r7,r7,32 > 0x30013bf4 : beq- 0x30013c34 > 0x30013bf8 : mtcrf 1,r7 > 0x30013bfc : add r6,r6,r7 > 0x30013c00 : subf r5,r7,r5 > 0x30013c04 : cmplwi cr1,r7,16 > 0x30013c08 : mr r8,r6 > 0x30013c0c : bge- cr7,0x30013c18 > 0x30013c10 : stw r4,-4(r8) > 0x30013c14 : stwu r4,-8(r8) > 0x30013c18 : blt- cr1,0x30013c2c > 0x30013c1c : stw r4,-4(r8) > 0x30013c20 : stw r4,-8(r8) > 0x30013c24 : stw r4,-12(r8) > 0x30013c28 : stwu r4,-16(r8) > 0x30013c2c : ble- cr7,0x30013c34 > 0x30013c30 : stw r4,-4(r8) > 0x30013c34 : cmplwi cr1,r4,0 > 0x30013c38 : rlwinm. r7,r5,0,0,26 > 0x30013c3c : mtcrf 1,r5 > 0x30013c40 : beq- cr1,0x30013de0 > 0x30013c44 : rlwinm r0,r7,27,5,31 > 0x30013c48 : mtctr r0 > 0x30013c4c : beq- 0x30013d80 > 0x30013c50 : clrlwi. r5,r5,27 > 0x30013c54 : add r6,r6,r7 > 0x30013c58 : li r8,-64 > 0x30013c5c : bdz- 0x30013c90 > 0x30013c60 : dcbtst r8,r6 > 0x30013c64 : stw r4,-4(r6) > 0x30013c68 : stw r4,-8(r6) > 0x30013c6c : stw r4,-12(r6) > 0x30013c70 : stw r4,-16(r6) > 0x30013c74 : nop > 0x30013c78 : stw r4,-20(r6) > 0x30013c7c : stw r4,-24(r6) > 0x30013c80 : nop > 0x30013c84 : stw r4,-28(r6) > 0x30013c88 : stwu r4,-32(r6) > 0x30013c8c : bdnz+ 0x30013c60 > 0x30013c90 : stw r4,-4(r6) > 0x30013c94 : stw r4,-8(r6) > 0x30013c98 : stw r4,-12(r6) > 0x30013c9c : stw r4,-16(r6) > 0x30013ca0 : stw r4,-20(r6) > 0x30013ca4 : cmplwi cr1,r5,16 > 0x30013ca8 : stw r4,-24(r6) > 0x30013cac : stw r4,-28(r6) > 0x30013cb0 : stwu r4,-32(r6) > 0x30013cb4 : beqlr > 0x30013cb8 : add r6,r6,r7 > 0x30013cbc : b 0x30013d84 > 0x30013cc0 : nop > 0x30013cc4 : clrlwi r5,r5,27 > 0x30013cc8 : mtcrf 2,r7 > 0x30013ccc : rlwinm. r0,r7,25,7,31 > ---Type to continue, or q to quit--- > 0x30013cd0 : mtctr r0 > 0x30013cd4 : li r7,32 > 0x30013cd8 : li r8,-64 > 0x30013cdc : cmplwi cr1,r5,16 > 0x30013ce0 : bne- cr6,0x30013cec > 0x30013ce4 : dcbz r0,r6 > 0x30013ce8 : addi r6,r6,32 > 0x30013cec : li r9,-32 > 0x30013cf0 : ble- cr6,0x30013d00 > 0x30013cf4 : d
MPC85xx DMA support for Kernel 2.6?
On Thu, 30 Jun 2005 17:56:30 +0200, Clemens Koller writes: >But is there any code available for recycling? Jason McMullan has some code for mpc85xx dma here: http://www.evillabs.net/~gus/patches/mpc85xx_dma.patch Looks like it wouldn't take much to get it working. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen at csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.
eth0 autonegotation 8260
Dear Samuel, in message you wrote: > ... > clocks and MDIO pins. I took changes somebody made with DENX's 2.4.18 and > ported them to 2.4.25, probably forgeting something in the waymay be > something related to interrupts interfaces has changed since then??? Ummm did you by chance try the currnt code in CVS, which is 2.4.25 based? I am not aware of any problems in that area, at least not on the boards we use for regular testing. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Anyone who isn't confused here doesn't really know what's going on.
