* Re: Virtex-4 TEMAC device driver available?
From: Yoshio Kashiwagi @ 2006-02-19 11:39 UTC (permalink / raw)
To: S. Egbert, linuxppc-embedded
In-Reply-To: <43F7CB11.5000202@sbcglobal.net>
Hello Steve San,
Strictly, GSRD differs from TEMAC.
Although both are embedded TEMAC is used in Virtex4, GSRD accesses
direct memory through MPMC. MPMC is a multi-port memory controller
for GSRD to access direct memory.
http://www.xilinx.com/esp/wired/optical/xlnx_net/gsrd_download.htm
Download of GSRD is linked out of the above-mentioned URL, and
becomes a place to be logged in (Registration for downloading the
reference design short cut).
http://www.xilinx.com/xlnx/xil_entry2.jsp?sMode=login&group=gsrd
Linux2.4 driver is contained in this GSRD. However, this Linux2.4
driver (adapter.c) has the fault which does not operate correctly,
when a 100BASE hub is connected. In order to correct this problem,
it is necessary to add the interrupt handling routine of PHY.
Although this GSRD is a reference design more nearly high-speed
than TEMAC, many FPGA resources are used for it.
I am going to create a TEMAC driver (Linux2.6) by a scratch, I
cannot make time for it now. Since it is due to make by the end of
this month, if it is completed, I'll announce it to this mailing
list.
I'll write the Linux2.6 TEMAC driver corresponding to the following
reference designs.
http://direct.xilinx.com/bvdocs/appnotes/xapp902.pdf
http://www.xilinx.com/bvdocs/appnotes/xapp902.zip
(The Linux driver is not contained in this reference design)
Best Regards,
Yoshio Kashiwagi - Nissin Systems
> Dear Kashiwagi-San,
>
> I noticed in your posting over at linuxppc-embedded in Jan 2006 about
a
> Xilinx demo code for the TEMAC driver.
>
> So, I pulled the
> http://www.xilinx.co.jp/ise/embedded/EDK/71i/mpmc_7_1_2.zip file and
> browsed it.
>
> Do you know where one can get a patch for Linux 2.4?
>
> Thank you,
>
> Steve Egbert
>
> --
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GAT d- s++: !a C+++ UL++++ P+++ L+++ E W+++ N+ o++ K+++ w--
> O- M+ V- PS PE++ Y+ PGP++ t++ 5++ X++ R tv- b++ DI+ D+
> G++ e* h++ r+++ z
> ------END GEEK CODE BLOCK------
> GPG Public Key: http://www.egbert.net/pgp
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* [PATCH] powermac: Fix loss of ethernet PHY on sleep
From: Benjamin Herrenschmidt @ 2006-02-20 0:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list, Linus Torvalds, Linux Kernel list
Some recent PowerBook models tend to lose the ethernet PHY on
suspend/resume. It -seems- that they use a combo ethernet-firewire PHY
chip and the firewire PHY seems to die the same way when that happens.
Not trying to toggle the firewire cable power appears to fix it. So this
patch disables changes to the firewire cable power control GPIO on those
models. Please apply for 2.6.16.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/feature.c 2006-02-20 11:10:07.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/feature.c 2006-02-20 11:13:25.000000000 +1100
@@ -1648,10 +1648,10 @@
KL0_SCC_CELL_ENABLE);
MACIO_BIC(KEYLARGO_FCR1,
- /*KL1_USB2_CELL_ENABLE |*/
KL1_I2S0_CELL_ENABLE | KL1_I2S0_CLK_ENABLE_BIT |
KL1_I2S0_ENABLE | KL1_I2S1_CELL_ENABLE |
- KL1_I2S1_CLK_ENABLE_BIT | KL1_I2S1_ENABLE);
+ KL1_I2S1_CLK_ENABLE_BIT | KL1_I2S1_ENABLE |
+ KL1_EIDE0_ENABLE);
if (pmac_mb.board_flags & PMAC_MB_MOBILE)
MACIO_BIC(KEYLARGO_FCR1, KL1_UIDE_RESET_N);
@@ -2185,7 +2185,7 @@
},
{ "PowerMac10,1", "Mac mini",
PMAC_TYPE_UNKNOWN_INTREPID, intrepid_features,
- PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER,
+ PMAC_MB_MAY_SLEEP,
},
{ "iMac,1", "iMac (first generation)",
PMAC_TYPE_ORIG_IMAC, paddington_features,
@@ -2297,11 +2297,11 @@
},
{ "PowerBook5,8", "PowerBook G4 15\"",
PMAC_TYPE_UNKNOWN_INTREPID, intrepid_features,
- PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,
+ PMAC_MB_MAY_SLEEP | PMAC_MB_MOBILE,
},
{ "PowerBook5,9", "PowerBook G4 17\"",
PMAC_TYPE_UNKNOWN_INTREPID, intrepid_features,
- PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,
+ PMAC_MB_MAY_SLEEP | PMAC_MB_MOBILE,
},
{ "PowerBook6,1", "PowerBook G4 12\"",
PMAC_TYPE_UNKNOWN_INTREPID, intrepid_features,
^ permalink raw reply
* please pull powerpc-merge.git
From: Paul Mackerras @ 2006-02-20 6:08 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
There are 6 commits there with some bug fixes that should go in
2.6.16, including a fix for the xtime vs gettimeofday drift that uses
the current_tick_length() function that was recently added.
Thanks,
Paul.
Michael Ellerman:
powerpc: Don't start secondary CPUs in a UP && KEXEC kernel
powerpc: Make UP -> SMP kexec work again
powerpc: Fix bug in spinup of renumbered secondary threads
Olaf Hering:
powerpc: remove duplicate exports
Olof Johansson:
powerpc: Fix OOPS in lparcfg on G5
Paul Mackerras:
powerpc: Keep xtime and gettimeofday in sync
arch/powerpc/kernel/head_64.S | 4
arch/powerpc/kernel/lparcfg.c | 6 -
arch/powerpc/kernel/ppc_ksyms.c | 16 --
arch/powerpc/kernel/setup_64.c | 4
arch/powerpc/kernel/sys_ppc32.c | 4
arch/powerpc/kernel/time.c | 282 ++++++++++++----------------------
arch/powerpc/platforms/pseries/smp.c | 2
arch/ppc/kernel/ppc_ksyms.c | 8 -
arch/ppc/xmon/start.c | 15 --
include/asm-ppc/machdep.h | 13 --
10 files changed, 108 insertions(+), 246 deletions(-)
^ permalink raw reply
* Re: arch/ppc/82xx_io/uart.c bug found
From: Wojciech Kromer @ 2006-02-20 7:57 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <0744a8b48857d469b3d4ceff6f7fd40f@embeddedalley.com>
>Three things....
>
>One, this code is obsolete and isn't used any more.
>
>
It's in latest linuxppc_2_4_devel from denx.de CVS.
>Two, it's not a bug, just a feature enhancement.
>
>
OK.
>Three, if you want us to actually do something about
>this I need a real patch against an up to date
>public source tree and indication it was actually
>tested on some platform.
>
>
I'm currently using CVS version from denx.de,
there are lot of features I'm using.
Just use this info as an information, not offcial bug note.
I spend few days finding it.
^ permalink raw reply
* Broken pcmcia on m8xx.
From: Hans Schillstrom @ 2006-02-20 11:24 UTC (permalink / raw)
To: linuxppc-dev list
Hello
I'm trying to get a flash disk working with 2.6.15 kernel
on a TQM860L board.( With 2.4.25 it works perfect.)
I added a printk in ide-probe.c to see the result from IDE_SELECT_REG
and it was 0xff ...
Does any one has an idea where to start searching or knows what is
wrong ?
Added some printouts from u-boot, linux 2.4.25 and 2.6.15
/Hans
U-BOOT Startup message:
=======================
PCMCIA: 3.3V card found: SanDisk SDP 5/3 0.6
Fixed Disk Card
IDE interface
[silicon] [unique] [single] [sleep] [standby] [idle] [low
power]
Bus 0: OK
Device 0: Model: SanDisk SDCFB-1024 Firm: Rev 0.00 Ser#: X0406
20050813225551
Type: Removable Hard Disk
Capacity: 977.4 MB = 0.9 GB (2001888 x 512)
Kernel 2.4.25 Startup:
======================
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 50MHz system bus speed for PIO modes; override with
idebus=xx
PCMCIA slot B: phys mem e0000000...ec000000 (size 0c000000)
Card ID: SanDisk SDP 5/3 0.6
Fixed Disk Card
IDE interface
[silicon] [unique] [single] [sleep] [standby] [idle] [low power]
Probing IDE interface ide0...
hda: probing with STATUS(0x50) instead of ALTSTATUS(0xf6)
hda: SanDisk SDCFB-1024, CFA DISK drive
hdb: probing with STATUS(0x50) instead of ALTSTATUS(0xf6)
hdb: probing with STATUS(0x50) instead of ALTSTATUS(0xf6)
hdb: probing with STATUS(0x50) instead of ALTSTATUS(0xf6)
hdb: probing with STATUS(0x50) instead of ALTSTATUS(0xf6)
ide0 at 0x460df320-0x460df327,0x420df106 on irq 13
hda: attached ide-disk driver.
hda: 2001888 sectors (1025 MB) w/1KiB Cache, CHS=1986/16/63
Partition check:
hda: [PTBL] [993/32/63] hda1
TQM8xxL Bank 0: Found 2 x16 devices at 0x400000 in 32-bit mode
Kernel 2.6.15 startup:
========================
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with
idebus=xx
init_hwif_default()
PCMCIA slot B: phys mem e0000000...ec000000 (size 0c000000)
Card ID: SanDisk SDP 5/3 0.6
Fixed Disk Card
IDE interface
[silicon] [unique] [single] [sleep] [standby] [idle] [low power]
probing for hda: present=0, media=32, probetype=ATA
do_probe(ret:255)
Here is the my small modification of do_probe.
static int do_probe (ide_drive_t *drive, u8 cmd)
{
...
/* needed for some systems
* (e.g. crw9624 as drive0 with disk as slave)
*/
ide_delay_50ms();
SELECT_DRIVE(drive);
ide_delay_50ms();
printk("do_probe(inb:%d)\n",hwif->INB(IDE_SELECT_REG));
if (hwif->INB(IDE_SELECT_REG) != drive->select.all && !drive->present)
{
if (drive->select.b.unit != 0) {
/* exit with drive0 selected */
SELECT_DRIVE(&hwif->drives[0]);
/* allow BUSY_STAT to assert & clear */
ide_delay_50ms();
}
/* no i/f present: mmm.. this should be a 4 -ml */
return 3;
}
...
^ permalink raw reply
* RE: 82xx_io UART BRG's vs BUS CLK
From: Russell McGuire @ 2006-02-20 12:22 UTC (permalink / raw)
To: 'Jenkins, Clive', linuxppc-embedded
In-Reply-To: <35786B99AB3FDC45A8215724617919736D9236@gbrwgceumf01.eu.xerox.net>
Everyone,
Found a bug in the Linux 2.4.25 -> 2.4.26 and perhaps newer PPC kernels.
However, thanks for the U-boot tree, as it already had the fix. Thanks to
those who had hinted at something like this already. I have tested this out
and it works good for me on a MPC8280, with U-boot 1.1.2 and DENX Linux
2.4.25.
I don't have a patch file but the change is real simple if someone would
like to provide one.
/linux/arch/ppc/8260_io/commproc.c there is this bit of code.
--------------------------------------
/* This function is used by UARTS, or anything else that uses a 16x
* oversampled clock. */
void cpm2_setbrg(uint brg, uint rate)
{
volatile uint *bp;
/* This is good enough to get SMCs running.....
*/
if (brg < 4) {
bp = (uint *)&cpm2_immr->im_brgc1;
}
else {
bp = (uint *)&cpm2_immr->im_brgc5;
brg -= 4;
}
bp += brg;
*bp = ((BRG_UART_CLK / rate) << 1) | CPM_BRG_EN;
}
----------------------------------------
I recently put the correct frequency in U-boot to pass to linux, i.e.
66,666,666Mhz instead of 66,000,000Mhz. And this broke the BRG setups and I
could no longer run 115200 Baudrate.
So after looking around, I found that the Uboot 1.1.2 and newer code already
has a modified version of this code, and that it works correctly. Thanks
DENX!
See correct code below: note the cd--
-------------------------------------------------
void m8260_cpm_setbrg(uint brg, uint rate)
{
volatile uint *bp;
uint cd = BRG_UART_CLK / rate;
if ((BRG_UART_CLK % rate) < (rate / 2))
cd--;
if (brg < 4) {
bp = (uint *)&immr->im_brgc1;
}
else {
bp = (uint *)&immr->im_brgc5;
brg -= 4;
}
bp += brg;
*bp = (cd << 1) | CPM_BRG_EN;
}
----------------------------------------------------
-----Original Message-----
From: Jenkins, Clive [mailto:Clive.Jenkins@xerox.com]
Sent: Tuesday, February 14, 2006 3:24 AM
To: Russell McGuire; linuxppc-embedded@ozlabs.org
Subject: RE: 82xx_io UART BRG's vs BUS CLK
> I did some math on the BRG calculations and with 66Mhz the BRG divisor
is
> 17.8 I am assuming 17 gets written, and with 66.666Mhz then its 18.02
so
> thus 18 probably gets written. Should perhaps a constant minus 1 be
added to
> the code?
> Using:
> U-boot 1.1.2
> DENX Linux 2.4.25
> Is anyone aware of similar issues, or are there bug fixes past the
2.4.25
> Kernel for this?
> -Russ
Hi Russ
I am not familiar with your hardware, nor have I checked the code that
calculated the Baud rate divisor.
I would advise against "adding a constant -1", in favour of rounding
to the nearest integer. From your figures:
divisor = clock / (baudrate * 32)
To get a rounded result using real numbers:
divisor = integer_part_of((clock / (baudrate * 32)) + 1/2)
Using integer arithmetic, you can code this in C as:
divisor = ((clock / baudrate /16) + 1) >> 1;
I would check whether or not the code is doing this, or the equivalent,
and if not, change it. If the code is doing this, the divisor should be
18 in both cases.
Clive
^ permalink raw reply
* RE: 82xx_io UART BRG's vs BUS CLK
From: Jenkins, Clive @ 2006-02-20 13:32 UTC (permalink / raw)
To: Russell McGuire, linuxppc-embedded
Russ
In fact the CD field of the hardware register needs to be
programmed with (divisor - 1), so in a sense you were right
about "adding a constant -1"! But it still needs the rounding
I suggested.
The Denx code combines the rounding and decrementing.
Clive
-----Original Message-----
From: Russell McGuire [mailto:rmcguire@uwbt.com]=20
Sent: 20 February 2006 12:22
To: Jenkins, Clive; linuxppc-embedded@ozlabs.org
Subject: RE: 82xx_io UART BRG's vs BUS CLK
Everyone,
Found a bug in the Linux 2.4.25 -> 2.4.26 and perhaps newer PPC kernels.
However, thanks for the U-boot tree, as it already had the fix. Thanks
to
those who had hinted at something like this already. I have tested this
out
and it works good for me on a MPC8280, with U-boot 1.1.2 and DENX Linux
2.4.25.
I don't have a patch file but the change is real simple if someone would
like to provide one.
/linux/arch/ppc/8260_io/commproc.c there is this bit of code.
--------------------------------------
/* This function is used by UARTS, or anything else that uses a 16x
* oversampled clock. */
void cpm2_setbrg(uint brg, uint rate)
{
volatile uint *bp;
=20
/* This is good enough to get SMCs running.....
*/
if (brg < 4) {
bp =3D (uint *)&cpm2_immr->im_brgc1;
}
else {
bp =3D (uint *)&cpm2_immr->im_brgc5;
brg -=3D 4;
}
bp +=3D brg;
*bp =3D ((BRG_UART_CLK / rate) << 1) | CPM_BRG_EN;
}
----------------------------------------
I recently put the correct frequency in U-boot to pass to linux, i.e.
66,666,666Mhz instead of 66,000,000Mhz. And this broke the BRG setups
and I
could no longer run 115200 Baudrate.
So after looking around, I found that the Uboot 1.1.2 and newer code
already
has a modified version of this code, and that it works correctly. Thanks
DENX!
See correct code below: note the cd--
-------------------------------------------------
void m8260_cpm_setbrg(uint brg, uint rate)
{
volatile uint *bp;
uint cd =3D BRG_UART_CLK / rate;
if ((BRG_UART_CLK % rate) < (rate / 2))
cd--;
if (brg < 4) {
bp =3D (uint *)&immr->im_brgc1;
}
else {
bp =3D (uint *)&immr->im_brgc5;
brg -=3D 4;
}
bp +=3D brg;
*bp =3D (cd << 1) | CPM_BRG_EN; =20
}
----------------------------------------------------
-----Original Message-----
From: Jenkins, Clive [mailto:Clive.Jenkins@xerox.com]=20
Sent: Tuesday, February 14, 2006 3:24 AM
To: Russell McGuire; linuxppc-embedded@ozlabs.org
Subject: RE: 82xx_io UART BRG's vs BUS CLK
> I did some math on the BRG calculations and with 66Mhz the BRG divisor
is
> 17.8 I am assuming 17 gets written, and with 66.666Mhz then its 18.02
so
> thus 18 probably gets written. Should perhaps a constant minus 1 be
added to
> the code?
> Using:
> U-boot 1.1.2
> DENX Linux 2.4.25
> Is anyone aware of similar issues, or are there bug fixes past the
2.4.25
> Kernel for this?
> -Russ
Hi Russ
I am not familiar with your hardware, nor have I checked the code that
calculated the Baud rate divisor.
I would advise against "adding a constant -1", in favour of rounding
to the nearest integer. From your figures:
divisor =3D clock / (baudrate * 32)
To get a rounded result using real numbers:
divisor =3D integer_part_of((clock / (baudrate * 32)) + 1/2)
Using integer arithmetic, you can code this in C as:
divisor =3D ((clock / baudrate /16) + 1) >> 1;
I would check whether or not the code is doing this, or the equivalent,
and if not, change it. If the code is doing this, the divisor should be
18 in both cases.
Clive
^ permalink raw reply
* (no subject)
From: Bora KARTAL @ 2006-02-20 13:39 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am trying to run linuxppc 2.4.20 with a nfs mounted root file system on=
=20a Motorolla MVME5100 board with a PowerPC 7410 processor. When I used =
the default kernel =FDmage sh=FDpped with MontaVista Linux development ki=
t, it boots up and works fine. But when I build up a custom kernel I am g=
etting the following exception during bootup.
=20
Residual-Data Located at: $1FE9077C
Exception: Program (Illegal Instruction)
SRR0 =3D00005000 SRR1 =3D00083040 Vector-Offset =3D00700
IP =3D00005000 MSR =3D00003040 CR =3D00000000 FPSCR =3D00000000
R0 =3D00000000 R1 =3D1FE00000 R2 =3D00000000 R3 =3D1FE9077C
R4 =3D00005000 R5 =3D00000000 R6 =3D00000000 R7 =3D00000000
R8 =3D00000000 R9 =3D00000000 R10 =3D00000000 R11 =3D00000000
R12 =3D00000000 R13 =3D00000000 R14 =3D00000000 R15 =3D00000000
R16 =3D00000000 R17 =3D00000000 R18 =3D00000000 R19 =3D00000000
R20 =3D00000000 R21 =3D00000000 R22 =3D00000000 R23 =3D00000000
R24 =3D00000000 R25 =3D00000000 R26 =3D00000000 R27 =3D00000000
R28 =3D00000000 R29 =3D00000000 R30 =3D00000000 R31 =3D00000000
SPR0 =3D00000000 SPR1 =3D00000000 SPR8 =3D00000000 SPR9 =3D00000000
00005000 7F454C46 WORD $7F454C46
Anybody can help?
Thanks,
Bora
######################################################################
Dikkat:
Bu elektronik posta mesaji kisisel ve ozeldir. Eger size=20
gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz.=20
Firmamiza gelen ve giden mesajlar virus taramasindan gecirilmekte,=20
guvenlik nedeni ile kontrol edilerek saklanmaktadir. Mesajdaki=20
gorusler ve bakis acisi gondericiye ait olup Aselsan A.S. resmi=20
gorusu olmak zorunda degildir.
######################################################################
Attention:=20
This e-mail message is privileged and confidential. If you are=20
not the intended recipient please delete the message and notify=20
the sender. E-mails to and from the company are monitored for=20
operational reasons and in accordance with lawful business practices.=20
Any views or opinions presented are solely those of the author and=20
do not necessarily represent the views of the company.
######################################################################
^ permalink raw reply
* MVME5100 Exception: Program (Illegal Instruction)
From: Bora KARTAL @ 2006-02-20 13:39 UTC (permalink / raw)
To: linuxppc-embedded
=20
Hi,
I am trying to run linuxppc 2.4.20 with a nfs mounted root file system on=
=20a Motorolla MVME5100 board with a PowerPC 7410 processor. When I used =
the default kernel =FDmage sh=FDpped with MontaVista Linux development ki=
t, it boots up and works fine. But when I build up a custom kernel I am g=
etting the following exception during bootup.
=20
Residual-Data Located at: $1FE9077C
Exception: Program (Illegal Instruction)
SRR0 =3D00005000 SRR1 =3D00083040 Vector-Offset =3D00700
IP =3D00005000 MSR =3D00003040 CR =3D00000000 FPSCR =3D00000000
R0 =3D00000000 R1 =3D1FE00000 R2 =3D00000000 R3 =3D1FE9077C
R4 =3D00005000 R5 =3D00000000 R6 =3D00000000 R7 =3D00000000
R8 =3D00000000 R9 =3D00000000 R10 =3D00000000 R11 =3D00000000
R12 =3D00000000 R13 =3D00000000 R14 =3D00000000 R15 =3D00000000
R16 =3D00000000 R17 =3D00000000 R18 =3D00000000 R19 =3D00000000
R20 =3D00000000 R21 =3D00000000 R22 =3D00000000 R23 =3D00000000
R24 =3D00000000 R25 =3D00000000 R26 =3D00000000 R27 =3D00000000
R28 =3D00000000 R29 =3D00000000 R30 =3D00000000 R31 =3D00000000
SPR0 =3D00000000 SPR1 =3D00000000 SPR8 =3D00000000 SPR9 =3D00000000
00005000 7F454C46 WORD $7F454C46
Anybody can help?
Thanks,
Bora
######################################################################
Dikkat:
Bu elektronik posta mesaji kisisel ve ozeldir. Eger size=20
gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz.=20
Firmamiza gelen ve giden mesajlar virus taramasindan gecirilmekte,=20
guvenlik nedeni ile kontrol edilerek saklanmaktadir. Mesajdaki=20
gorusler ve bakis acisi gondericiye ait olup Aselsan A.S. resmi=20
gorusu olmak zorunda degildir.
######################################################################
Attention:=20
This e-mail message is privileged and confidential. If you are=20
not the intended recipient please delete the message and notify=20
the sender. E-mails to and from the company are monitored for=20
operational reasons and in accordance with lawful business practices.=20
Any views or opinions presented are solely those of the author and=20
do not necessarily represent the views of the company.
######################################################################
^ permalink raw reply
* SCCx UART status on 8xx
From: Björn Östby @ 2006-02-20 13:37 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I'm messing with a mpc823e based board trying to enable the SCC3 UART. =
I'm using the 2.4.25 denx linux_ppc kernel and I've got SMC1 for console =
and SMC2 up and running but I'm in desperate need of another rs232 port =
(which is on SCC3 on my board).=20
Reading quite a lot of old posts on this mailing list got me confused =
whether the SCCx UART support in the kernel is ready to be used on 8xx =
or if there will take a large amount of hacking to get things going =
(reading the header of 8xx_io/uart.c got me wondering even more).
Current situation is that I have enabled the SCC3 UART in the kernel, =
set the correct CTS, RTS and CD signal options and finally disabled the =
SPI which (on my board at least) can override the UART on the third SCC =
port. During boot up I get the standard output:
>ttyS0 at 0x0280 is on SMC1 using BRG1
>ttyS1 at 0x0380 is on SMC2 using BRG2
>ttyS2 at 0x0200 is on SCC3 using BRG3
Writing to ttyS0 and ttyS1 works fine (the result pop up in the =
receiving terminal) but when trying ttyS2 nothing happens. I've checked =
the Tx signal and it appears as if data is sent (the signal gets noisy =
when starting the write procedure). I may also add that restaring the =
write application causes the kernel to hang (for ttyS2 only of course).
I've read some posts saying that Linux don't init other uart ports than =
the console port and that is the potential problem here, but it is =
unclear if this statement is true or not. I can also add to the problem =
description that my SMC2 port works fine for writing, but reading just =
hangs in the read() call. So, can anyone confirm any status on the SMCx =
and SCCx UART drivers for 2.4?
Best regards,
Bjorn ostby
^ permalink raw reply
* Re: SCCx UART status on 8xx
From: Aristeu Sergio Rozanski Filho @ 2006-02-20 14:18 UTC (permalink / raw)
To: Björn Östby; +Cc: fbl, linuxppc-embedded
In-Reply-To: <004B1D7A5257174C9044A1B7BD0E60ED0178CC4F@ratatosk.combitechsystems.com>
[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]
On Mon, Feb 20, 2006 at 02:37:23PM +0100, Björn Östby wrote:
> Hello,
> I'm messing with a mpc823e based board trying to enable the SCC3 UART. I'm using the 2.4.25 denx linux_ppc kernel and I've got SMC1 for console and SMC2 up and running but I'm in desperate need of another rs232 port (which is on SCC3 on my board).
> Reading quite a lot of old posts on this mailing list got me confused whether the SCCx UART support in the kernel is ready to be used on 8xx or if there will take a large amount of hacking to get things going (reading the header of 8xx_io/uart.c got me wondering even more).
> Current situation is that I have enabled the SCC3 UART in the kernel, set the correct CTS, RTS and CD signal options and finally disabled the SPI which (on my board at least) can override the UART on the third SCC port. During boot up I get the standard output:
>
> >ttyS0 at 0x0280 is on SMC1 using BRG1
> >ttyS1 at 0x0380 is on SMC2 using BRG2
> >ttyS2 at 0x0200 is on SCC3 using BRG3
>
> Writing to ttyS0 and ttyS1 works fine (the result pop up in the receiving terminal) but when trying ttyS2 nothing happens. I've checked the Tx signal and it appears as if data is sent (the signal gets noisy when starting the write procedure). I may also add that restaring the write application causes the kernel to hang (for ttyS2 only of course).
>
> I've read some posts saying that Linux don't init other uart ports than the console port and that is the potential problem here, but it is unclear if this statement is true or not. I can also add to the problem description that my SMC2 port works fine for writing, but reading just hangs in the read() call. So, can anyone confirm any status on the SMCx and SCCx UART drivers for 2.4?
please try the two attached patches. the first one configures each SCC to
one BRG. the second one, makes use always of dpram memory. we're working on a
decent fix.
Marcelo: if you find the first one ok, you may apply it, but don't apply the
second
--
Aristeu
[-- Attachment #2: cpm_uart-configure_brgs_properly.patch --]
[-- Type: text/plain, Size: 1028 bytes --]
Index: stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c
===================================================================
--- stable.orig/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17 17:11:37.000000000 -0200
+++ stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17 17:15:57.000000000 -0200
@@ -139,24 +139,31 @@
void scc1_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC1: insert port configuration here */
+ cpmp->cp_sicr &= 0xFFFFFFC0;
pinfo->brg = 1;
}
void scc2_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC2: insert port configuration here */
+ cpmp->cp_sicr &= 0xFFFFC0FF;
+ cpmp->cp_sicr |= 0x00000900;
pinfo->brg = 2;
}
void scc3_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC3: insert port configuration here */
+ cpmp->cp_sicr &= 0xFFC0FFFF;
+ cpmp->cp_sicr |= 0x00140000;
pinfo->brg = 3;
}
void scc4_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC4: insert port configuration here */
+ cpmp->cp_sicr &= 0xC0FFFFFF;
+ cpmp->cp_sicr |= 0x1BFFFFFF;
pinfo->brg = 4;
}
[-- Attachment #3: serial_alloc_bootmem.patch --]
[-- Type: text/plain, Size: 1131 bytes --]
Index: stable/drivers/serial/cpm_uart/cpm_uart_core.c
===================================================================
--- stable.orig/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-07 15:30:42.000000000 -0200
+++ stable/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-08 12:39:11.000000000 -0200
@@ -467,6 +467,7 @@
/* free interrupt handler */
free_irq(port->irq, port);
+#if 0
/* If the port is not the console, disable Rx and Tx. */
if (!(pinfo->flags & FLAG_CONSOLE)) {
/* Wait for all the BDs marked sent */
@@ -492,6 +493,7 @@
/* Shut them really down */
cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
}
+#endif
}
static void cpm_uart_set_termios(struct uart_port *port,
@@ -896,7 +898,7 @@
pinfo->sccp->scc_gsmrl &= ~(SCC_GSMRL_ENR | SCC_GSMRL_ENT);
}
- ret = cpm_uart_allocbuf(pinfo, 0);
+ ret = cpm_uart_allocbuf(pinfo, 1);
if (ret)
return ret;
@@ -912,10 +914,12 @@
static void cpm_uart_release_port(struct uart_port *port)
{
+#if 0
struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
if (!(pinfo->flags & FLAG_CONSOLE))
cpm_uart_freebuf(pinfo);
+#endif
}
/*
^ permalink raw reply
* Re: 440gx GPIO
From: Ed Goforth @ 2006-02-20 17:13 UTC (permalink / raw)
To: Howard, Marc, linuxppc-embedded
In-Reply-To: <91B22F93A880FA48879475E134D6F0BE023887B6@CA1EXCLV02.adcorp.kla-tencor.com>
On 2/14/06, Howard, Marc <Marc.Howard@kla-tencor.com> wrote:
>
> > -----Original Message-----
> > From:
> > linuxppc-embedded-bounces+marc.howard=3Dkla-tencor.com@ozlabs.or
> > g
> > [mailto:linuxppc-embedded-bounces+marc.howard=3Dkla-tencor.com@o
> > zlabs.org] On Behalf Of Ed Goforth
> > Sent: Tuesday, February 14, 2006 1:47 PM
> > To: linuxppc-embedded@ozlabs.org
> > Subject: Re: 440gx GPIO
> > .....
> > Well, I was able to manipulate GPIO9, GPIO10 and GPIO12. It's time to
> > turn it over to the hardware people.
> >
>
> It's AMCC's fault. They aren't listing the latest errata on their
> website. I downloaded their rev 3.1 ver 1.03 errata last August.
> However if you look today you get the rev 3.1 ver 1.02 release.
>
Do you recall if this errata is only against rev 3.1 chips? We are
currently using rev 2.1 (PVR ending in 892), but will be doing some
hardware refreshes sometime.
>
> Marc
Thanks,
Ed
^ permalink raw reply
* Re: 440gx GPIO
From: Ed Goforth @ 2006-02-20 17:20 UTC (permalink / raw)
To: Ed Goforth, linuxppc-embedded
In-Reply-To: <20060214170140.GB12465@gate.ebshome.net>
On 2/14/06, Eugene Surovegin <ebs@ebshome.net> wrote:
>
> Try writing the same GPIO output register value as you read from it
> (without clearing bit 11). Also, try changing some other GPIO bit
> (e.g. one which is not connected in your design). Maybe board hangs
> exactly because you set GPIO bit 11 low :).
Bingo! The board wasn't actually hanging. When we set GPIO11 low, it
is supposed to reset our on-board FPGAs. One of the FPGAs controls a
TX disable signal. And the (current) default on a reset is to leave
the TX disable low, hence no network after a FPGA reset. Doesn't work
well with a NFS root :)
>
> Also, connect scope to that GPIO pin and see what is really going on.
>
> --
> Eugene
^ permalink raw reply
* [PATCH] change compat shmget size arg to signed
From: Olaf Hering @ 2006-02-20 18:39 UTC (permalink / raw)
To: linuxppc-dev
change second arg (the 'size') to signed to handle a size of -1.
ltp test shmget02 fails. This patch fixes it.
Oddly, we see the failure only on a POWER4 LPAR with 4.6G ram.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/sys_ppc32.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.16-rc4-olh/arch/powerpc/kernel/sys_ppc32.c
===================================================================
--- linux-2.6.16-rc4-olh.orig/arch/powerpc/kernel/sys_ppc32.c
+++ linux-2.6.16-rc4-olh/arch/powerpc/kernel/sys_ppc32.c
@@ -429,7 +429,7 @@ long compat_sys_ipc(u32 call, u32 first,
return sys_shmdt(compat_ptr(ptr));
case SHMGET:
/* sign extend key_t */
- return sys_shmget((int)first, second, third);
+ return sys_shmget((int)first, (int)second, third);
case SHMCTL:
/* sign extend shmid */
return compat_sys_shmctl((int)first, second, compat_ptr(ptr));
^ permalink raw reply
* Re: SCCx UART status on 8xx
From: Wolfgang Denk @ 2006-02-20 20:15 UTC (permalink / raw)
To: Björn Östby; +Cc: linuxppc-embedded
In-Reply-To: <004B1D7A5257174C9044A1B7BD0E60ED0178CC4F@ratatosk.combitechsystems.com>
In message <004B1D7A5257174C9044A1B7BD0E60ED0178CC4F@ratatosk.combitechsystems.com> you wrote:
>
> I'm messing with a mpc823e based board trying to enable the SCC3 UART. I'm using the 2.4.25 denx linux_ppc kernel and I've got SMC1 for console and SMC2 up and running but I'm in desperate need of another rs232 port (which is on SCC3 on my board).
> Reading quite a lot of old posts on this mailing list got me confused whether the SCCx UART support in the kernel is ready to be used on 8xx or if there will take a large amount of hacking to get things going (reading the header of 8xx_io/uart.c got me
> wondering even more).
All UARTS (up to 2 x SMC + 4 x SCC, depending on CPU model) can be
used with our tree, including hardware handshake.
> I've read some posts saying that Linux don't init other uart ports than the console port and that is the potential problem here, but it is unclear if this statement is true or not. I can also add to the problem description that my SMC2 port works fine f
> or writing, but reading just hangs in the read() call. So, can anyone confirm any status on the SMCx and SCCx UART drivers for 2.4?
Works fine on all board supported by us.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The C-shell doesn't parse. It adhoculates.
- Casper.Dik@Holland.Sun.COM in <3ol96k$b2j@engnews2.Eng.Sun.COM>
^ permalink raw reply
* Re: SCCx UART status on 8xx
From: Dan Malek @ 2006-02-20 20:43 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Björn Östby, linuxppc-embedded
In-Reply-To: <20060220201504.C5289353C11@atlas.denx.de>
On Feb 20, 2006, at 3:15 PM, Wolfgang Denk wrote:
> All UARTS (up to 2 x SMC + 4 x SCC, depending on CPU model) can be
> used with our tree, including hardware handshake.
Except that you have to be careful about BRG allocation. At most,
the 8xx will have 4 BRGs, some only have 2. There have been various
implementations to work with this, some forced the BRGs to be
multiply mapped (where more than one UART had to run at the same rate)
while others silently returned errors and the UARTs were non-functional
although appeared for use.
Thanks.
-- Dan
^ permalink raw reply
* hello error during kernel compilation of ml300 powerpc405 plzz help
From: shivani kirubanandan @ 2006-02-21 3:12 UTC (permalink / raw)
To: linuxppc-embedded
hello ,
i encountered this error while tryin to compile a
ml300 xilinx specific powerpc405 kernel...plz help me
out!
make[1]: Leaving directory
`/home/shivani/downloads/linux-2.4.26/arch/ppc/4xx_io'
/opt/crosstool/gcc-3.3.2-glibc-2.3.2/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-ld
-T arch/ppc/vmlinux.lds -Ttext 0xc0000000 -Bstatic
arch/ppc/kernel/head_4xx.o init/main.o init/version.o
init/do_mounts.o \
--start-group \
arch/ppc/kernel/kernel.o
arch/ppc/platforms/platform.o arch/ppc/mm/mm.o
arch/ppc/lib/lib.o kernel/kernel.o mm/mm.o fs/fs.o
ipc/ipc.o \
drivers/char/char.o drivers/block/block.o
drivers/misc/misc.o drivers/net/net.o
drivers/ide/idedriver.o drivers/scsi/scsidrv.o
drivers/cdrom/driver.o drivers/pci/driver.o
drivers/net/wireless/wireless_net.o
drivers/macintosh/macintosh.o drivers/video/video.o
drivers/usb/usbdrv.o drivers/media/media.o
drivers/input/inputdrv.o arch/ppc/4xx_io/4xx_io.o \
net/network.o \
/home/shivani/downloads/linux-2.4.26/lib/lib.a
\
--end-group \
-o vmlinux
drivers/char/char.o(.text+0x1d824): In function
`handle_kbd_event':
: undefined reference to `x8042_read_status'
drivers/char/char.o(.text+0x1d844): In function
`handle_kbd_event':
: undefined reference to `x8042_read_input'
drivers/char/char.o(.text+0x1d860): In function
`handle_kbd_event':
: undefined reference to `x8042_read_status'
drivers/char/char.o(.text+0x1dc64): In function
`kbd_write_command_w':
: undefined reference to `x8042_write_command'
drivers/char/char.o(.text+0x1dcb0): In function
`kbd_write_output_w':
: undefined reference to `x8042_write_output'
drivers/char/char.o(.text+0x1dd68): In function
`panic_blink':
: undefined reference to `x8042_read_status'
drivers/char/char.o(.text+0x1dd8c): In function
`panic_blink':
: undefined reference to `x8042_write_output'
drivers/char/char.o(.text+0x1ddb0): In function
`panic_blink':
: undefined reference to `x8042_read_status'
drivers/char/char.o(.text+0x1ddec): In function
`panic_blink':
: undefined reference to `x8042_write_output'
drivers/char/char.o(.text.init+0x1604): In function
`kbd_read_data':
: undefined reference to `x8042_read_status'
drivers/char/char.o(.text.init+0x162c): In function
`kbd_read_data':
: undefined reference to `x8042_read_input'
make: *** [vmlinux] Error 1
cheers
shivani
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Uart on cpm2_io (was: Using modem signal in cpm2 uart for MPC8270)
From: Mathieu Deschamps @ 2006-02-21 8:58 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
Sorry to come with this UART issue again but I had no answer and no
better idea but asking people who knows 82xx uart well, people who
designed it.
My issue about this uart could be approched elseway : why is there a
modem_control conditionnal compilation option when PQ2 SCCs
(in normal operation mode which is default) take care of CTS,CD signals
(Chap 20-8 GSMR_L register DIAG MPC8280 PQ2 Ref. Manual ) ?
I fell like that is clearly a design-time choice matter that I need to
clarify.
And simply :
Is this version is known to be broken when activating this option ?
Please let me know your thoughts on this, it is very valuable to me,
thanks.
Best Regards,
Mathieu
---------- Forwarded Message ----------
Subject: Using modem signal in cpm2 uart for MPC8270
Date: Friday 17 February 2006 11:12
From: Mathieu Deschamps <mathieu.deschamps@com2gether.net>
To: linuxppc-embedded@ozlabs.org
Hello ppc-embedded folks,
I'am looking for a hint in arch/ppc/cpm2_io/uart.c on enable modem signal
handling on MontaVista Linux 2.4.20. I know it's a bit ancient but some of
you may have a good memory :) I mentionned enabling modem signal because this
file seems to support modem, yet I come to the conclusion it is incomplete.
In void rs_8xx_interrupt function I've noticed it needs 'modem_control'
defined to get the call done and modem lines changed on interrup(1). Also it
needs defined 'notdef' to implement this code(2).
===(1)
#ifdef modem_control
check_modem_status(info);
#endif
===(2)
#ifdef notdef
/* I need to do this for the SCCs, so it is left as a reminder.
*/
static _INLINE_ void check_modem_status(struct async_struct *info)
{
[...]
}
#endif
===
Having this done is not sufficient, a lot of registers defined in
linux/serial_reg.h are reported missing. I have included this file, yet
other functions are missing, struct members also.
Here is compilation output :
===========================
uart.c: In function `check_modem_status':
uart.c:603: warning: implicit declaration of function `serial_in'
uart.c:638: error: structure has no member named `tqueue_hangup'
uart.c:650: warning: implicit declaration of function `serial_out'
uart.c:651: warning: passing arg 1 of `rs_sched_event' from incompatible
pointer type
uart.c: In function `rs_8xx_interrupt':
uart.c:709: warning: passing arg 1 of `check_modem_status' from incompatible
pointer type
uart.c: In function `startup':
uart.c:813: error: structure has no member named `MCR'
uart.c:815: error: structure has no member named `MCR'
uart.c: In function `change_speed':
uart.c:993: error: structure has no member named `IER'
uart.c:995: error: structure has no member named `IER'
uart.c:998: error: structure has no member named `IER'
uart.c:1005: error: structure has no member named `IER'
uart.c:1007: error: structure has no member named `IER'
uart.c: In function `rs_8xx_throttle':
uart.c:1255: error: structure has no member named `MCR'
uart.c:1258: error: structure has no member named `MCR'
uart.c: In function `rs_8xx_unthrottle':
uart.c:1284: error: structure has no member named `MCR'
uart.c:1286: error: structure has no member named `MCR'
uart.c: In function `get_modem_info':
uart.c:1327: error: structure has no member named `MCR'
uart.c: In function `set_modem_info':
uart.c:1358: error: structure has no member named `MCR'
uart.c:1360: error: structure has no member named `MCR'
uart.c:1363: error: structure has no member named `MCR'
uart.c:1365: error: structure has no member named `MCR'
uart.c:1370: error: structure has no member named `MCR'
uart.c:1372: error: structure has no member named `MCR'
uart.c:1375: error: structure has no member named `MCR'
uart.c:1377: error: structure has no member named `MCR'
uart.c:1381: error: structure has no member named `MCR'
uart.c:1381: error: structure has no member named `MCR'
uart.c:1398: error: structure has no member named `MCR'
uart.c: In function `begin_break':
uart.c:1417: warning: comparison is always false due to limited range of data
type
uart.c: In function `end_break':
uart.c:1461: warning: comparison is always false due to limited range of data
type
uart.c: In function `rs_8xx_ioctl':
uart.c:1600: error: `cprev' undeclared (first use in this function)
uart.c:1600: error: (Each undeclared identifier is reported only once
uart.c:1600: error: for each function it appears in.)
uart.c:1603: error: structure has no member named `delta_msr_wait'
uart.c: In function `rs_8xx_set_termios':
uart.c:1670: error: structure has no member named `MCR'
uart.c:1672: error: structure has no member named `MCR'
uart.c:1679: error: structure has no member named `MCR'
uart.c:1682: error: structure has no member named `MCR'
uart.c:1685: error: structure has no member named `MCR'
uart.c: In function `rs_8xx_wait_until_sent':
uart.c:1839: warning: unused variable `lsr'
=======
I wonder if modem support is incomplete or even if it was dropped in here but
was conceived for another arch .
Looking forward to read your inputs.
Best regards,
Mathieu Deschamps
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
-------------------------------------------------------
^ permalink raw reply
* Re: Uart on cpm2_io (was: Using modem signal in cpm2 uart for MPC8270)
From: Wojciech Kromer @ 2006-02-21 9:20 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200602210954.51248.mathieu.deschamps@com2gether.net>
Dnia 2006-02-21 09:58, Użytkownik Mathieu Deschamps napisał:
> Hello,
>
> Sorry to come with this UART issue again but I had no answer and no
> better idea but asking people who knows 82xx uart well, people who
> designed it.
>
> My issue about this uart could be approched elseway : why is there a
> modem_control conditionnal compilation option when PQ2 SCCs
> (in normal operation mode which is default) take care of CTS,CD signals
> (Chap 20-8 GSMR_L register DIAG MPC8280 PQ2 Ref. Manual ) ?
>
> I fell like that is clearly a design-time choice matter that I need to
> clarify.
>
> And simply :
> Is this version is known to be broken when activating this option ?
>
Do not know what this option is, probably for disabling code from
another driver.
With latest CVS version from denx.de you have only to enable CTS/RTS..
signals in menuconfig.
(And read my prior post if you're using SCC4 with SCC_CONSOLE)
^ permalink raw reply
* RE: SCCx UART status on 8xx
From: Björn Östby @ 2006-02-21 11:01 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: fbl, linuxppc-embedded
Hi all again,
-----Original Message-----
From: Aristeu Sergio Rozanski Filho [mailto:aris@mandriva.com]=20
Sent: den 20 februari 2006 15:19
To: Bj=F6rn =D6stby
Cc: linuxppc-embedded@ozlabs.org; marcelo.tosatti@cyclades.com; =
fbl@conectiva.com.br
Subject: Re: SCCx UART status on 8xx
On Mon, Feb 20, 2006 at 02:37:23PM +0100, Bj=F6rn =D6stby wrote:
> Hello,
> I'm messing with a mpc823e based board trying to enable the SCC3 UART. =
> I'm using the 2.4.25 denx linux_ppc kernel and I've got SMC1 for =
console and SMC2 up and running but I'm in desperate need of another =
rs232 port (which is on SCC3 on my board).
> Reading quite a lot of old posts on this mailing list got me confused =
whether the SCCx UART support in the kernel is ready to be used on 8xx =
or if there will take a large amount of hacking to get things going =
(reading the header of 8xx_io/uart.c got me wondering even more).
> Current situation is that I have enabled the SCC3 UART in the kernel, =
set the correct CTS, RTS and CD signal options and finally disabled the =
SPI which (on my board at least) can override the UART on the third SCC =
port. During boot up I get the standard output:
>=20
> >ttyS0 at 0x0280 is on SMC1 using BRG1
> >ttyS1 at 0x0380 is on SMC2 using BRG2
> >ttyS2 at 0x0200 is on SCC3 using BRG3
>=20
> Writing to ttyS0 and ttyS1 works fine (the result pop up in the=20
> receiving terminal) but when trying ttyS2 nothing happens. I've=20
> checked the Tx signal and it appears as if data is sent (the signal=20
> gets noisy when starting the write procedure). I may also add that=20
> restaring the write application causes the kernel to hang (for ttyS2=20
> only of course).
>=20
> I've read some posts saying that Linux don't init other uart ports=20
> than the console port and that is the potential problem here, but it =
is unclear if this >>
>statement is true or not. I can also add to the problem description =
that my SMC2 port works >fine for writing, but reading just hangs in the =
read() call. So, can anyone confirm any >
>status on the SMCx and SCCx UART drivers for 2.4?
>please try the two attached patches. the first one configures each SCC =
to one BRG. the second one, makes use always of dpram memory. we're =
working on a decent fix.
>Marcelo: if you find the first one ok, you may apply it, but don't =
apply the second
>
>--=20
>Aristeu
>
I would like to thank everyone who has given input to the discussion. =
Unfortunately the problems remain. I have not been able to try the =
patches since I reckon they are for Linux 2.6 specific while I'm using =
the 2.4 kernel (could be good to have in for future projects though). I =
did however triy remove the CTS, RTS and CD signal from the config as =
suggested which stopped the kernel from hanging. Might be a step in the =
right direction.
Best regards,
Bjorn Ostby
^ permalink raw reply
* Re: Uart on cpm2_io (was: Using modem signal in cpm2 uart for MPC8270)
From: Mathieu Deschamps @ 2006-02-21 16:44 UTC (permalink / raw)
To: Wojciech Kromer; +Cc: linuxppc-embedded
In-Reply-To: <43FADB46.6030109@dgt.com.pl>
On Tuesday 21 February 2006 10:20, Wojciech Kromer wrote:
> Dnia 2006-02-21 09:58, U=C5=BCytkownik Mathieu Deschamps napisa=C5=82:
> > Hello,
> >
> > Sorry to come with this UART issue again but I had no answer and no
> > better idea but asking people who knows 82xx uart well, people who
> > designed it.
> >
> > My issue about this uart could be approched elseway : why is there a
> > modem_control conditionnal compilation option when PQ2 SCCs
> > (in normal operation mode which is default) take care of CTS,CD signals
> > (Chap 20-8 GSMR_L register DIAG MPC8280 PQ2 Ref. Manual ) ?
> >
> > I fell like that is clearly a design-time choice matter that I need to
> > clarify.
> >
> > And simply :
> > Is this version is known to be broken when activating this option ?
>
> Do not know what this option is, probably for disabling code from
> another driver.
> With latest CVS version from denx.de you have only to enable CTS/RTS..
> signals in menuconfig.
> (And read my prior post if you're using SCC4 with SCC_CONSOLE)
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Thanks for your reply,
<> Do not know what this option is, probably for disabling code from
<> another driver.
=2E..or rather to enable it...(default is disabled). Allthesame :=20
Now it's clear it has historical reason and that I should not meddle with i=
t=20
in getting it enable. I guess it may be used for non-PQ2 or rather for non=
=20
dedicated pins assignement capable cpu in order to implement thoses signals
handling.
About SCC4 my version includes that code you spoke about in your prior=20
posts, but I'll use SCC4 as usb and not as console. Thus maybe this
turned nouse and has vanished in your version and that's why it's call a=20
"feature enhancement" yet. =20
Best Regards,
=20
Mathieu Deschamps
Com2gether Design Center
Electronic and Embedded Engineering Services
www.com2gether.net=20
^ permalink raw reply
* AmigaOne PPC Linux: Problems with Interrupts
From: Gerhard Pircher @ 2006-02-21 19:07 UTC (permalink / raw)
To: linuxppc-dev, debian-powerpc
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 2892 bytes --]
Hi,
I encountered some problems with Linux PPC on the AmigaOne. As you can see
in the /proc/interrupts output below, the AmigaOne has a i8259 PIC (no
OpenPIC). The first problem is, that the interrupts 7 and 10 are shown as
"Edge" triggered, but they're set to "Level" in the u-boot (firmware)
preferences. I'm not sure, if u-boot setups the interrupts, therefore I
added this code to the platform PCI initialisation code (copied from
prep_pci.c):
void __init
amigaone_pcibios_fixup(void)
{
/* IRQ 7 is level triggered. */
unsigned char irq_edge_mask_lo = 0x80;
/* IRQ, 9, 10, 11 is level triggered. */
unsigned char irq_edge_mask_hi = 0x07;
outb(inb(0x04d0)|irq_edge_mask_lo, 0x4d0); /* primary 8259 */
outb(inb(0x04d1)|irq_edge_mask_hi, 0x4d1); /* cascaded 8259 */
}
Unortunately this didn't help and the interrupts seem to be still "edge"
triggered.
/proc/interrupts:
CPU0
1: 189 i8259 Edge i8042
2: 0 i8259 Edge 82c59 secondary cascade
5: 0 i8259 Edge uhci_hcd, uhci_hcd
7: 546 i8259 Edge eth0
10: 0 i8259 Edge EMU10K1
12: 8217 i8259 Edge i8042
14: 19597 i8259 Edge ide0
15: 18951 i8259 Edge ide1
BAD: 2
The other issue are the 2 BAD interrupts shown above. Does this have to do
something with the "edge" or "level" triggered mode or is it a interrupt
routing problem?
Thanks!
Gerhard
Other infos:
/proc/ioports
00000000-00bfffff : PCI host bridge
00000000-0000001f : dma1
00000020-00000021 : 8259 (master)
00000040-0000005f : timer
00000060-0000006f : i8042
00000080-0000008f : dma page reg
000000a0-000000a1 : 8259 (slave)
000000c0-000000df : dma2
00000170-00000177 : ide1
000001f0-000001f7 : ide0
00000278-0000027a : parport2
000002f8-000002ff : serial
00000376-00000376 : ide1
00000378-0000037a : parport0
000003bc-000003be : parport1
000003c0-000003df : vga+
000003e8-000003ef : serial
000003f6-000003f6 : ide0
000003f8-000003ff : serial
000004d0-000004d1 : 8259 edge control
00002000-00002fff : PCI Bus #01
00002000-000020ff : 0000:01:00.0
0000cc00-0000cc0f : 0000:00:07.1
0000cc00-0000cc07 : ide0
0000cc08-0000cc0f : ide1
00802000-0080207f : 0000:00:06.0
00802000-0080207f : 0000:00:06.0
00802080-0080209f : 0000:00:07.2
00802080-0080209f : uhci_hcd
008020a0-008020bf : 0000:00:07.3
008020a0-008020bf : uhci_hcd
00802100-008021ff : 0000:00:07.5
00802200-00802203 : 0000:00:07.5
00802204-00802207 : 0000:00:07.5
00802300-008023ff : 0000:00:07.6
00802400-0080241f : 0000:00:09.0
00802400-0080241f : EMU10K1
00802420-00802427 : 0000:00:09.1
00802420-00802427 : emu10k1-gp
--
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++
^ permalink raw reply
* [PATCH] fix adb breakage in xmon
From: Olaf Hering @ 2006-02-21 20:06 UTC (permalink / raw)
To: Al Viro, Paul Mackeras, linuxppc-dev
In-Reply-To: <20060221183324.GA3444@suse.de>
Fix up xmon compilation after the last change.
Remove lots of dead code, all the pmac and chrp support is in arch/powerpc
Signed-off-by: Olaf Hering <olh@suse.de>
arch/ppc/xmon/adb.c | 212 --------------------------------------------------
arch/ppc/xmon/start.c | 169 ---------------------------------------
arch/ppc/xmon/xmon.c | 108 -------------------------
3 files changed, 3 insertions(+), 486 deletions(-)
Index: linux-2.6.16-rc4-olh/arch/ppc/xmon/start.c
===================================================================
--- linux-2.6.16-rc4-olh.orig/arch/ppc/xmon/start.c
+++ linux-2.6.16-rc4-olh/arch/ppc/xmon/start.c
@@ -6,16 +6,11 @@
#include <asm/machdep.h>
#include <asm/io.h>
#include <asm/page.h>
-#include <linux/adb.h>
-#include <linux/pmu.h>
-#include <linux/cuda.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/sysrq.h>
#include <linux/bitops.h>
#include <asm/xmon.h>
-#include <asm/prom.h>
-#include <asm/bootx.h>
#include <asm/machdep.h>
#include <asm/errno.h>
#include <asm/processor.h>
@@ -26,9 +21,7 @@ static volatile unsigned char *sccc, *sc
unsigned int TXRDY, RXRDY, DLAB;
static int xmon_expect(const char *str, unsigned int timeout);
-static int use_screen;
static int via_modem;
-static int xmon_use_sccb;
#define TB_SPEED 25000000
@@ -46,47 +39,6 @@ void buf_access(void)
sccd[3] &= ~DLAB; /* reset DLAB */
}
-extern int adb_init(void);
-
-#ifdef CONFIG_PPC_CHRP
-/*
- * This looks in the "ranges" property for the primary PCI host bridge
- * to find the physical address of the start of PCI/ISA I/O space.
- * It is basically a cut-down version of pci_process_bridge_OF_ranges.
- */
-static unsigned long chrp_find_phys_io_base(void)
-{
- struct device_node *node;
- unsigned int *ranges;
- unsigned long base = CHRP_ISA_IO_BASE;
- int rlen = 0;
- int np;
-
- node = find_devices("isa");
- if (node != NULL) {
- node = node->parent;
- if (node == NULL || node->type == NULL
- || strcmp(node->type, "pci") != 0)
- node = NULL;
- }
- if (node == NULL)
- node = find_devices("pci");
- if (node == NULL)
- return base;
-
- ranges = (unsigned int *) get_property(node, "ranges", &rlen);
- np = prom_n_addr_cells(node) + 5;
- while ((rlen -= np * sizeof(unsigned int)) >= 0) {
- if ((ranges[0] >> 24) == 1 && ranges[2] == 0) {
- /* I/O space starting at 0, grab the phys base */
- base = ranges[np - 3];
- break;
- }
- ranges += np;
- }
- return base;
-}
-#endif /* CONFIG_PPC_CHRP */
#ifdef CONFIG_MAGIC_SYSRQ
static void sysrq_handle_xmon(int key, struct pt_regs *regs,
@@ -109,22 +61,6 @@ xmon_map_scc(void)
#ifdef CONFIG_PPC_MULTIPLATFORM
volatile unsigned char *base;
-#ifdef CONFIG_PPC_CHRP
- base = (volatile unsigned char *) isa_io_base;
- if (_machine == _MACH_chrp)
- base = (volatile unsigned char *)
- ioremap(chrp_find_phys_io_base(), 0x1000);
-
- sccc = base + 0x3fd;
- sccd = base + 0x3f8;
- if (xmon_use_sccb) {
- sccc -= 0x100;
- sccd -= 0x100;
- }
- TXRDY = 0x20;
- RXRDY = 1;
- DLAB = 0x80;
-#endif /* CONFIG_PPC_CHRP */
#elif defined(CONFIG_GEMINI)
/* should already be mapped by the kernel boot */
sccc = (volatile unsigned char *) 0xffeffb0d;
@@ -143,7 +79,7 @@ xmon_map_scc(void)
register_sysrq_key('x', &sysrq_xmon_op);
}
-static int scc_initialized = 0;
+static int scc_initialized;
void xmon_init_scc(void);
@@ -163,14 +99,6 @@ xmon_write(void *handle, void *ptr, int
break;
#endif
-#ifdef CONFIG_BOOTX_TEXT
- if (use_screen) {
- /* write it on the screen */
- for (i = 0; i < nb; ++i)
- btext_drawchar(*p++);
- goto out;
- }
-#endif
if (!scc_initialized)
xmon_init_scc();
ct = 0;
@@ -190,7 +118,6 @@ xmon_write(void *handle, void *ptr, int
eieio();
}
- out:
#ifdef CONFIG_SMP
if (!locked)
clear_bit(0, &xmon_write_lock);
@@ -199,65 +126,7 @@ xmon_write(void *handle, void *ptr, int
}
int xmon_wants_key;
-int xmon_adb_keycode;
-
-#ifdef CONFIG_BOOTX_TEXT
-static int xmon_adb_shiftstate;
-static unsigned char xmon_keytab[128] =
- "asdfhgzxcv\000bqwer" /* 0x00 - 0x0f */
- "yt123465=97-80]o" /* 0x10 - 0x1f */
- "u[ip\rlj'k;\\,/nm." /* 0x20 - 0x2f */
- "\t `\177\0\033\0\0\0\0\0\0\0\0\0\0" /* 0x30 - 0x3f */
- "\0.\0*\0+\0\0\0\0\0/\r\0-\0" /* 0x40 - 0x4f */
- "\0\0000123456789\0\0\0"; /* 0x50 - 0x5f */
-
-static unsigned char xmon_shift_keytab[128] =
- "ASDFHGZXCV\000BQWER" /* 0x00 - 0x0f */
- "YT!@#$^%+(&_*)}O" /* 0x10 - 0x1f */
- "U{IP\rLJ\"K:|<?NM>" /* 0x20 - 0x2f */
- "\t ~\177\0\033\0\0\0\0\0\0\0\0\0\0" /* 0x30 - 0x3f */
- "\0.\0*\0+\0\0\0\0\0/\r\0-\0" /* 0x40 - 0x4f */
- "\0\0000123456789\0\0\0"; /* 0x50 - 0x5f */
-
-static int
-xmon_get_adb_key(void)
-{
- int k, t, on;
-
- xmon_wants_key = 1;
- for (;;) {
- xmon_adb_keycode = -1;
- t = 0;
- on = 0;
- do {
- if (--t < 0) {
- on = 1 - on;
- btext_drawchar(on? 0xdb: 0x20);
- btext_drawchar('\b');
- t = 200000;
- }
- do_poll_adb();
- } while (xmon_adb_keycode == -1);
- k = xmon_adb_keycode;
- if (on)
- btext_drawstring(" \b");
-
- /* test for shift keys */
- if ((k & 0x7f) == 0x38 || (k & 0x7f) == 0x7b) {
- xmon_adb_shiftstate = (k & 0x80) == 0;
- continue;
- }
- if (k >= 0x80)
- continue; /* ignore up transitions */
- k = (xmon_adb_shiftstate? xmon_shift_keytab: xmon_keytab)[k];
- if (k != 0)
- break;
- }
- xmon_wants_key = 0;
- return k;
-}
-#endif /* CONFIG_BOOTX_TEXT */
int
xmon_read(void *handle, void *ptr, int nb)
@@ -265,18 +134,11 @@ xmon_read(void *handle, void *ptr, int n
char *p = ptr;
int i;
-#ifdef CONFIG_BOOTX_TEXT
- if (use_screen) {
- for (i = 0; i < nb; ++i)
- *p++ = xmon_get_adb_key();
- return i;
- }
-#endif
if (!scc_initialized)
xmon_init_scc();
for (i = 0; i < nb; ++i) {
while ((*sccc & RXRDY) == 0)
- do_poll_adb();
+ ;
buf_access();
*p++ = *sccd;
}
@@ -287,7 +149,7 @@ int
xmon_read_poll(void)
{
if ((*sccc & RXRDY) == 0) {
- do_poll_adb();
+ ;
return -1;
}
buf_access();
@@ -297,15 +159,6 @@ xmon_read_poll(void)
void
xmon_init_scc(void)
{
- if ( _machine == _MACH_chrp )
- {
- sccd[3] = 0x83; eieio(); /* LCR = 8N1 + DLAB */
- sccd[0] = 12; eieio(); /* DLL = 9600 baud */
- sccd[1] = 0; eieio();
- sccd[2] = 0; eieio(); /* FCR = 0 */
- sccd[3] = 3; eieio(); /* LCR = 8N1 */
- sccd[1] = 0; eieio(); /* IER = 0 */
- }
scc_initialized = 1;
if (via_modem) {
for (;;) {
@@ -321,22 +174,6 @@ xmon_init_scc(void)
}
}
-#if 0
-extern int (*prom_entry)(void *);
-
-int
-xmon_exit(void)
-{
- struct prom_args {
- char *service;
- } args;
-
- for (;;) {
- args.service = "exit";
- (*prom_entry)(&args);
- }
-}
-#endif
void *xmon_stdin;
void *xmon_stdout;
Index: linux-2.6.16-rc4-olh/arch/ppc/xmon/adb.c
===================================================================
--- linux-2.6.16-rc4-olh.orig/arch/ppc/xmon/adb.c
+++ /dev/null
@@ -1,212 +0,0 @@
-/*
- * Copyright (C) 1996 Paul Mackerras.
- */
-#include "nonstdio.h"
-#include "privinst.h"
-
-#define scanhex xmon_scanhex
-#define skipbl xmon_skipbl
-
-#define ADB_B (*(volatile unsigned char *)0xf3016000)
-#define ADB_SR (*(volatile unsigned char *)0xf3017400)
-#define ADB_ACR (*(volatile unsigned char *)0xf3017600)
-#define ADB_IFR (*(volatile unsigned char *)0xf3017a00)
-
-static inline void eieio(void) { asm volatile ("eieio" : :); }
-
-#define N_ADB_LOG 1000
-struct adb_log {
- unsigned char b;
- unsigned char ifr;
- unsigned char acr;
- unsigned int time;
-} adb_log[N_ADB_LOG];
-int n_adb_log;
-
-void
-init_adb_log(void)
-{
- adb_log[0].b = ADB_B;
- adb_log[0].ifr = ADB_IFR;
- adb_log[0].acr = ADB_ACR;
- adb_log[0].time = get_dec();
- n_adb_log = 0;
-}
-
-void
-dump_adb_log(void)
-{
- unsigned t, t0;
- struct adb_log *ap;
- int i;
-
- ap = adb_log;
- t0 = ap->time;
- for (i = 0; i <= n_adb_log; ++i, ++ap) {
- t = t0 - ap->time;
- printf("b=%x ifr=%x acr=%x at %d.%.7d\n", ap->b, ap->ifr, ap->acr,
- t / 1000000000, (t % 1000000000) / 100);
- }
-}
-
-void
-adb_chklog(void)
-{
- struct adb_log *ap = &adb_log[n_adb_log + 1];
-
- ap->b = ADB_B;
- ap->ifr = ADB_IFR;
- ap->acr = ADB_ACR;
- if (ap->b != ap[-1].b || (ap->ifr & 4) != (ap[-1].ifr & 4)
- || ap->acr != ap[-1].acr) {
- ap->time = get_dec();
- ++n_adb_log;
- }
-}
-
-int
-adb_bitwait(int bmask, int bval, int fmask, int fval)
-{
- int i;
- struct adb_log *ap;
-
- for (i = 10000; i > 0; --i) {
- adb_chklog();
- ap = &adb_log[n_adb_log];
- if ((ap->b & bmask) == bval && (ap->ifr & fmask) == fval)
- return 0;
- }
- return -1;
-}
-
-int
-adb_wait(void)
-{
- if (adb_bitwait(0, 0, 4, 4) < 0) {
- printf("adb: ready wait timeout\n");
- return -1;
- }
- return 0;
-}
-
-void
-adb_readin(void)
-{
- int i, j;
- unsigned char d[64];
-
- if (ADB_B & 8) {
- printf("ADB_B: %x\n", ADB_B);
- return;
- }
- i = 0;
- adb_wait();
- j = ADB_SR;
- eieio();
- ADB_B &= ~0x20;
- eieio();
- for (;;) {
- if (adb_wait() < 0)
- break;
- d[i++] = ADB_SR;
- eieio();
- if (ADB_B & 8)
- break;
- ADB_B ^= 0x10;
- eieio();
- }
- ADB_B |= 0x30;
- if (adb_wait() == 0)
- j = ADB_SR;
- for (j = 0; j < i; ++j)
- printf("%.2x ", d[j]);
- printf("\n");
-}
-
-int
-adb_write(unsigned char *d, int i)
-{
- int j;
- unsigned x;
-
- if ((ADB_B & 8) == 0) {
- printf("r: ");
- adb_readin();
- }
- for (;;) {
- ADB_ACR = 0x1c;
- eieio();
- ADB_SR = d[0];
- eieio();
- ADB_B &= ~0x20;
- eieio();
- if (ADB_B & 8)
- break;
- ADB_ACR = 0xc;
- eieio();
- ADB_B |= 0x20;
- eieio();
- adb_readin();
- }
- adb_wait();
- for (j = 1; j < i; ++j) {
- ADB_SR = d[j];
- eieio();
- ADB_B ^= 0x10;
- eieio();
- if (adb_wait() < 0)
- break;
- }
- ADB_ACR = 0xc;
- eieio();
- x = ADB_SR;
- eieio();
- ADB_B |= 0x30;
- return j;
-}
-
-void
-adbcmds(void)
-{
- char cmd;
- unsigned rtcu, rtcl, dec, pdec, x;
- int i, j;
- unsigned char d[64];
-
- cmd = skipbl();
- switch (cmd) {
- case 't':
- for (;;) {
- rtcl = get_rtcl();
- rtcu = get_rtcu();
- dec = get_dec();
- printf("rtc u=%u l=%u dec=%x (%d = %d.%.7d)\n",
- rtcu, rtcl, dec, pdec - dec, (pdec - dec) / 1000000000,
- ((pdec - dec) % 1000000000) / 100);
- pdec = dec;
- if (cmd == 'x')
- break;
- while (xmon_read(stdin, &cmd, 1) != 1)
- ;
- }
- break;
- case 'r':
- init_adb_log();
- while (adb_bitwait(8, 0, 0, 0) == 0)
- adb_readin();
- break;
- case 'w':
- i = 0;
- while (scanhex(&x))
- d[i++] = x;
- init_adb_log();
- j = adb_write(d, i);
- printf("sent %d bytes\n", j);
- while (adb_bitwait(8, 0, 0, 0) == 0)
- adb_readin();
- break;
- case 'l':
- dump_adb_log();
- break;
- }
-}
Index: linux-2.6.16-rc4-olh/arch/ppc/xmon/xmon.c
===================================================================
--- linux-2.6.16-rc4-olh.orig/arch/ppc/xmon/xmon.c
+++ linux-2.6.16-rc4-olh/arch/ppc/xmon/xmon.c
@@ -12,8 +12,6 @@
#include <linux/kallsyms.h>
#include <asm/ptrace.h>
#include <asm/string.h>
-#include <asm/prom.h>
-#include <asm/bootx.h>
#include <asm/machdep.h>
#include <asm/xmon.h>
#include "nonstdio.h"
@@ -101,9 +99,6 @@ void cacheflush(void);
static void cpu_cmd(void);
#endif /* CONFIG_SMP */
static void csum(void);
-#ifdef CONFIG_BOOTX_TEXT
-static void vidcmds(void);
-#endif
static void bootcmds(void);
static void proccall(void);
static void printtime(void);
@@ -522,11 +517,6 @@ cmds(struct pt_regs *excp)
cpu_cmd();
break;
#endif /* CONFIG_SMP */
-#ifdef CONFIG_BOOTX_TEXT
- case 'v':
- vidcmds();
- break;
-#endif
case 'z':
bootcmds();
break;
@@ -618,43 +608,6 @@ static void cpu_cmd(void)
}
#endif /* CONFIG_SMP */
-#ifdef CONFIG_BOOTX_TEXT
-extern boot_infos_t disp_bi;
-
-static void vidcmds(void)
-{
- int c = inchar();
- unsigned int val, w;
- extern int boot_text_mapped;
-
- if (!boot_text_mapped)
- return;
- if (c != '\n' && scanhex(&val)) {
- switch (c) {
- case 'd':
- w = disp_bi.dispDeviceRowBytes
- / (disp_bi.dispDeviceDepth >> 3);
- disp_bi.dispDeviceDepth = val;
- disp_bi.dispDeviceRowBytes = w * (val >> 3);
- return;
- case 'p':
- disp_bi.dispDeviceRowBytes = val;
- return;
- case 'w':
- disp_bi.dispDeviceRect[2] = val;
- return;
- case 'h':
- disp_bi.dispDeviceRect[3] = val;
- return;
- }
- }
- printf("W = %d (0x%x) H = %d (0x%x) D = %d (0x%x) P = %d (0x%x)\n",
- disp_bi.dispDeviceRect[2], disp_bi.dispDeviceRect[2],
- disp_bi.dispDeviceRect[3], disp_bi.dispDeviceRect[3],
- disp_bi.dispDeviceDepth, disp_bi.dispDeviceDepth,
- disp_bi.dispDeviceRowBytes, disp_bi.dispDeviceRowBytes);
-}
-#endif /* CONFIG_BOOTX_TEXT */
static unsigned short fcstab[256] = {
0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf,
@@ -1020,7 +973,6 @@ dump_hash_table(void)
}
#else
-#ifndef CONFIG_PPC64BRIDGE
static void
dump_hash_table_seg(unsigned seg, unsigned start, unsigned end)
{
@@ -1079,66 +1031,6 @@ dump_hash_table_seg(unsigned seg, unsign
printf(" ... %x\n", last_va);
}
-#else /* CONFIG_PPC64BRIDGE */
-static void
-dump_hash_table_seg(unsigned seg, unsigned start, unsigned end)
-{
- extern void *Hash;
- extern unsigned long Hash_size;
- unsigned *htab = Hash;
- unsigned hsize = Hash_size;
- unsigned v, hmask, va, last_va;
- int found, last_found, i;
- unsigned *hg, w1, last_w2, last_va0;
-
- last_found = 0;
- hmask = hsize / 128 - 1;
- va = start;
- start = (start >> 12) & 0xffff;
- end = (end >> 12) & 0xffff;
- for (v = start; v < end; ++v) {
- found = 0;
- hg = htab + (((v ^ seg) & hmask) * 32);
- w1 = 1 | (seg << 12) | ((v & 0xf800) >> 4);
- for (i = 0; i < 8; ++i, hg += 4) {
- if (hg[1] == w1) {
- found = 1;
- break;
- }
- }
- if (!found) {
- w1 ^= 2;
- hg = htab + ((~(v ^ seg) & hmask) * 32);
- for (i = 0; i < 8; ++i, hg += 4) {
- if (hg[1] == w1) {
- found = 1;
- break;
- }
- }
- }
- if (!(last_found && found && (hg[3] & ~0x180) == last_w2 + 4096)) {
- if (last_found) {
- if (last_va != last_va0)
- printf(" ... %x", last_va);
- printf("\n");
- }
- if (found) {
- printf("%x to %x", va, hg[3]);
- last_va0 = va;
- }
- last_found = found;
- }
- if (found) {
- last_w2 = hg[3] & ~0x180;
- last_va = va;
- }
- va += 4096;
- }
- if (last_found)
- printf(" ... %x\n", last_va);
-}
-#endif /* CONFIG_PPC64BRIDGE */
-
static unsigned hash_ctx;
static unsigned hash_start;
static unsigned hash_end;
^ permalink raw reply
* [PATCH] powerpc: fix altivec_unavailable_exception Oopses
From: Alan Curry @ 2006-02-21 23:39 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel
altivec_unavailable_exception is called without setting r3... it looks like
the r3 that actually gets passed in as struct pt_regs *regs is the
undisturbed value of r3 at the time the altivec instruction was encountered.
The user actually gets to choose the pt_regs printed in the Oops!
After applying the following patch to 2.6.16-rc4, I can no longer cause an
Oops by executing an altivec instruction with CONFIG_ALTIVEC=n. The same
change would probably also be good for arch/ppc/kernel/head.S to fix the same
Oops in 2.6.15.4, though I haven't tested that.
--- arch/powerpc/kernel/head_32.S.orig 2006-02-21 15:58:18.000000000 -0500
+++ arch/powerpc/kernel/head_32.S 2006-02-21 15:59:23.000000000 -0500
@@ -714,6 +714,7 @@
#ifdef CONFIG_ALTIVEC
bne load_up_altivec /* if from user, just load it up */
#endif /* CONFIG_ALTIVEC */
+ addi r3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_EE_LITE(0xf20, altivec_unavailable_exception)
PerformanceMonitor:
^ permalink raw reply
* Re: [PATCH] powerpc: fix altivec_unavailable_exception Oopses
From: Kumar Gala @ 2006-02-22 0:52 UTC (permalink / raw)
To: Alan Curry; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200602212339.SAA1138491@shell.TheWorld.com>
On Feb 21, 2006, at 5:39 PM, Alan Curry wrote:
> altivec_unavailable_exception is called without setting r3... it
> looks like
> the r3 that actually gets passed in as struct pt_regs *regs is the
> undisturbed value of r3 at the time the altivec instruction was
> encountered.
> The user actually gets to choose the pt_regs printed in the Oops!
>
> After applying the following patch to 2.6.16-rc4, I can no longer
> cause an
> Oops by executing an altivec instruction with CONFIG_ALTIVEC=n. The
> same
> change would probably also be good for arch/ppc/kernel/head.S to
> fix the same
> Oops in 2.6.15.4, though I haven't tested that.
>
> --- arch/powerpc/kernel/head_32.S.orig 2006-02-21
> 15:58:18.000000000 -0500
> +++ arch/powerpc/kernel/head_32.S 2006-02-21 15:59:23.000000000 -0500
> @@ -714,6 +714,7 @@
> #ifdef CONFIG_ALTIVEC
> bne load_up_altivec /* if from user, just load it up */
> #endif /* CONFIG_ALTIVEC */
> + addi r3,r1,STACK_FRAME_OVERHEAD
> EXC_XFER_EE_LITE(0xf20, altivec_unavailable_exception)
>
> PerformanceMonitor:
Would you mine providing a patch for arch/ppc/kernel/head.S and
adding a signed-off-by line.
- k
^ 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