IDMA PCI on 8250
Do I need any hardware changes to use IDMA version of PCI driver?
[RFT] 8xx cpm_hostalloc patch was: allow coherent DMA API to work before main page allocator is set up
Marcelo Tosatti wrote: Can someone with 8xx using the cpm_uart driver please test the attached patch? It should avoid corruption of the pinned 8Mbyte CONFIG_PIN_TLB entry, as noted by Dan. You shouldn't have these discussions on the weekend :) I'm the culprit of the code in question. This is the second take of the code. The hack with the 'if' was not actually in the first edition, since I had the hostalloc function working properly before initialization by using the remainder of the bootpage, as a backup memory area, for when the mm is not yet ready. Somewhere along the way, it fell through the cracks. IMHO that's the proper way to fix it. There were some objection on that however. Regards Pantelis
Microcode patches for mpc8xx
Dear Wolfgang, Wolfgang Denk wrote: since we are on this topic here: look like SMC relocation is explicitly not supported and I can't see the SPI driver as well (unless it reuses 8260 driver). In our CVS tree? See the old linux-2.4 tree. We don't see many uses of 8xx systems recently with ucode requirements. I am completely puzzled now. It looks like your stable, but old linux-2.4 tree has a much better selection of 8xx drivers compared to the linuxppc_2_4_devel. Why is that? What do you recommend for a new MPC852T-based development? Can the drivers be dropped into the newer tree or more serious backporting effort is needed? Thanks, Vladimir
Memory mapping the PHY on CR826
Hi all, Does anyone here have *any* code for memory mapping the PM5350 ATM phy on the Microsys CR826 board? I've just purchased this board from Microsys and I'm trying to get the atm8260 ATM device driver to work on it - unfortunately I cannot seem to memory map the phy. My current settings are: memctl-memc_or8 = 0xe0400ef4; // base 0xe040; default timings memctl-memc_br8 = 0x8821; // min banksize; 8bit port; GPCM local; // bank valid Has anybody done this already? TIA, Alex
[RFT] 8xx cpm_hostalloc patch was: allow coherent DMA API to work before main page allocator is set up
On May 23, 2005, at 2:27 AM, Pantelis Antoniou wrote: You shouldn't have these discussions on the weekend :) Sorry. I try not to, but then people think I'm not interested :-) I was working on my race car data acquisition telemetry project, anyway. I'm the culprit of the code in question. I'm not trying to blame anyone. The new driver is better in many ways, we just have to fix up this one little thing so it works in all possible VM configurations. I also have to look at the new consistent mapping functions, as those also seem to have changed. Maybe this will work fine, or can be made to work with minor changes. Thanks. -- Dan
[PATCH] ppc32: Fix an off-by-one error in ipic_init
(This fixes a bug and should go into 2.6.12 if possible.)
There is an off-by-one error in the IPIC code that configures the
external interrupts (Edge or Level Sensitive).
Signed-off-by: Randy Vinson rvinson at mvista.com
Signed-off-by: Kumar Gala kumar.gala at freescale.com
---
commit e8366420067384e3443e5ed95c151198e5ca6d22
tree 6aeff44236e7890cce085e65661884e4622785a7
parent 57bf2ca5c599f50428bf3f8ff9707411b2dfbae8
author Kumar K. Gala kumar.gala at freescale.com Mon, 23 May 2005 12:27:15
-0500
committer Kumar K. Gala kumar.gala at freescale.com Mon, 23 May 2005 12:27:15
-0500
ppc/syslib/ipic.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: arch/ppc/syslib/ipic.c
===
--- 55631465fc89fa1f96bdadaa7026113780db1c8a/arch/ppc/syslib/ipic.c
(mode:100644)
+++ 6aeff44236e7890cce085e65661884e4622785a7/arch/ppc/syslib/ipic.c
(mode:100644)
@@ -479,7 +479,7 @@
temp = 0;
for (i = 0 ; i senses_count ; i++) {
if ((senses[i] IRQ_SENSE_MASK) == IRQ_SENSE_EDGE) {
- temp |= 1 (16 - i);
+ temp |= 1 (15 - i);
if (i != 0)
irq_desc[i + irq_offset + MPC83xx_IRQ_EXT1 -
1].status = 0;
else
tah reset?
FYI, I did find the source of the reset tah issue. The physical address of TAH 0 and TAH 1 was ending in B00h and D00h respectively. But in the UM, it ends in B50 and D50. the file affected is ibm440gx.c in arch/ppc/platforms. Thanks, Sanjay -Original Message- From: Eugene Surovegin [mailto:[EMAIL PROTECTED] Sent: Thursday, May 19, 2005 2:23 PM To: Sanjay Bajaj Cc: linuxppc-embedded at ozlabs.org Subject: Re: tah reset? On Thu, May 19, 2005 at 02:14:20PM -0400, Sanjay Bajaj wrote: While trying to reset the TAH on emac2 of PPC440GX, the Soft Reset (SR) bit never resets itself to 0. Does anybody know the reason for it? Did you enable TAH0 in SDR0_MFR register? Also, I don't remember for sure, but TAH may have the same problem as EMAC, namely, it won't go out of reset if there is no RX clock from PHY. -- Eugene
Microcode patches for mpc8xx
Dear Vladimir, in message 4291DEAF.1080705 at paulidav.org you wrote: In our CVS tree? See the old linux-2.4 tree. We don't see many uses of 8xx systems recently with ucode requirements. I am completely puzzled now. It looks like your stable, but old linux-2.4 tree has a much better selection of 8xx drivers compared to the linuxppc_2_4_devel. Why is that? What do you recommend for a new This is because we have limited resources, and do those things (first) where a customer is waiting (and paying) for. Not all of the work that went into the old 2.4.4 tree was adapted for more recent versions of 2.4 yet; and most of the 2.4 stuff got lost in 2.6 anyway. MPC852T-based development? Can the drivers be dropped into the newer tree or more serious backporting effort is needed? It depends. Most should work fine with minimal changes, but obviously some effort for a code review and especially testing will be needed. 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 core error - bus dumped
[Linux-ATM-General] Memory mapping the PHY on CR826
Hi Alex, I have got the Microsys board but I believe you sort of mixed up the 2 registers : try : memctl-memc_br8 = 0xe0400821; // base 0xe040; default timings; // bank valid; 8bit port; GPCM local; memctl-memc_or8 = 0x8820; // min banksize; addressline config Please verify the or8 setting with the actual board configuration. Alex Zeffertt wrote: Hi all, Does anyone here have *any* code for memory mapping the PM5350 ATM phy on the Microsys CR826 board? I've just purchased this board from Microsys and I'm trying to get the atm8260 ATM device driver to work on it - unfortunately I cannot seem to memory map the phy. My current settings are: memctl-memc_or8 = 0xe0400ef4; // base 0xe040; default timings memctl-memc_br8 = 0x8821; // min banksize; 8bit port; GPCM local; // bank valid Has anybody done this already? TIA, Alex --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ Linux-atm-general mailing list Linux-atm-general at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-atm-general -- - Koen Peeters Cellink bvba Catherinalaan 37, 3110 Rotselaar, Belgium web : http://www.cellink.net/
tah reset?
My intention is not to waste anybody's time and I think, I did not. As I mentioned to you earlier that I am working on the vendor provided version of Linux Kernel 2.4.27-pre3, which looks clearly from kernel.org. The value of PPC440GX_TAH0_ADDR and PPC440GX_TAH1_ADDR in arch/ppc/platforms/ibm440gx.h is 0x00014b00 0x00014d00 respectively. I verified this value in lk 2.4.30 also, these values are the same. Though in lk 2.6.x, the values have been hardcoded in the arch/ppc/platforms/ibm440gx.c to 0x00014b50 and 0x00014d50. Therefore, the confusion. I hope this clears your misunderstanding. I did not see your suggestion for using your version of 2.4.x backported driver of ibm_emac. I could use it, if you send it again. Thanks, Sanjay -Original Message- From: Eugene Surovegin [mailto:[EMAIL PROTECTED] Sent: Monday, May 23, 2005 4:04 PM To: Sanjay Bajaj Cc: linuxppc-embedded at ozlabs.org Subject: Re: tah reset? On Mon, May 23, 2005 at 03:17:26PM -0400, Sanjay Bajaj wrote: I did find the source of the reset tah issue. The physical address of TAH 0 and TAH 1 was ending in B00h and D00h respectively. But in the UM, it ends in B50 and D50. the file affected is ibm440gx.c in arch/ppc/platforms. Linux 2.6 has correct values for TAH base address, 2.4 doesn't have any support for TAH at all. Where did you get this incorrect code? You see, you should have used supported sources (2.6) or the one I recommended to you (my 2.4 backport) but you have ignored this suggestion and wasted your time and time of people on this mail list. Please, next time if you use some stuff which isn't in kernel.org's tree, direct you questions to the person who made those patches, because we cannot help you as we don't have the source code you are using. -- Eugene
MMUCR on ppc440 GP/GX
Hi, I have problem on running system with linuxppc 2.4.19(ppc440GP/GX) regarding MMU Control Register(MMUCR). I checked the code in arch/ppc/ there is no code setting or unsetting bit 12(DULXE) or bit 13(IULXE), but somehow these two bits got changed during boot process. Question 1: Does CPU or other hardware change these two bits? If linux code doesnt set these two bits initiallt, what's the default value? Or I miss something in the code that may change these two bits? Question 2: For current 2.4.19 PPC440 implementation, there is no special handling for this kind of DataStorage exception, is it possible for the user code to stuck in this exception forever if these two bits got set in MMUCR and the user code calls icbi instruction? I did a simple test on head_440.S so whenever the DataStorage exception happens, in DataStorage assmbly code, I clear these two bits in MMUCR, but somehow these two bits got set mysteriourly in next exception with error_code 0x20(got from ESR DLK bits). What's happening here? Thanks for any points and suggestions, Ming __ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
MMUCR on ppc440 GP/GX
On Mon, May 23, 2005 at 01:55:58PM -0700, ming lei wrote: Hi, I have problem on running system with linuxppc 2.4.19(ppc440GP/GX) regarding MMU Control Register(MMUCR). I checked the code in arch/ppc/ there is no code setting or unsetting bit 12(DULXE) or bit 13(IULXE), but somehow these two bits got changed during boot process. Question 1: Does CPU or other hardware change these two bits? If linux code doesnt set these two bits initiallt, what's the default value? Or I miss something in the code that may change these two bits? Question 2: For current 2.4.19 PPC440 implementation, there is no special handling for this kind of DataStorage exception, is it possible for the user code to stuck in this exception forever if these two bits got set in MMUCR and the user code calls icbi instruction? I did a simple test on head_440.S so whenever the DataStorage exception happens, in DataStorage assmbly code, I clear these two bits in MMUCR, but somehow these two bits got set mysteriourly in next exception with error_code 0x20(got from ESR DLK bits). What's happening here? Your kernel revision is very ancient. The problem here is that you are trying to use _very_ early PPC440 core code I released. It's filled with critical bugs that were fixed over time. The MMUCR issue was fixed almost 3 years ago, in fact. Your best solution is to run a more recent kernel. If that's not possible, then I suggest you backport all the PPC440 related code from a more recent kernel into your old kernel base. -Matt
