* FCC on 8560 ADS
From: Jose Almeida @ 2005-02-22 10:41 UTC (permalink / raw)
To: linuxppc-embedded
All,
I'm trying to get a linux 2.6 kernel up and running on an freescale 8560
ADS board. I have every peace of this up and running apart from the FCC
ethernet.
I've switched to the legacy mode, which now allow me to talk to the PHY
and negocite properly @ 100BT FD.
But I don't seem to get any ethernet packet going out. The FCC
controller does not seem to read the BDs, and all the packet's I'm
placing in the BD just stay there for ever !
I'm wondering if you have a driver which works properlly ? I'm thinking
on some wrong setup in the ioports, but is all seems to be correct !
I'm using a 2.6.9 kernel, but I also tryed other versions (2.6.11r4),
with the same problems ...
Thanks
Jose
^ permalink raw reply
* Linux 2.6.x on 8xx status
From: Joakim Tjernlund @ 2005-02-22 11:20 UTC (permalink / raw)
To: Linuxppc-Embedded@Ozlabs. Org, gautran
dcbz(and a few other cache instr.) is buggy on 8xx CPU:s.
See http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/000867.html
for a litte more input or google.
This bug will cuase random craches or "hangs" if not used with care.
There is an old patch floating around for 2.4 that will workaround the bug by
doing instr. decoding in the TLB Error handler.
Jocke
^ permalink raw reply
* Re: [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map
From: Sebastian Heutling @ 2005-02-22 12:01 UTC (permalink / raw)
To: Meelis Roos
Cc: Tom Rini, Sven Hartge, Kernel Mailing List, Christian Kujau,
linuxppc-dev
In-Reply-To: <Pine.SOC.4.61.0502221031230.6097@math.ut.ee>
Meelis Roos wrote:
>> The PCI IRQ map for the old Motorola PowerStackII (Utah) boards was
>> incorrect, but this breakage wasn't exposed until 2.5, and finally fixed
>> until recently by Sebastian Heutling <sheutlin@gmx.de>.
>
>
> Yesterday I finally got around to testing it. It seems the patch has
> been applied in Linus's tree so I downloaded the latest BK and tried it.
>
> Still does not work for me but this time it's different. Before the
> patch SCSI worked fine but PCI NICs caused hangs. Now I can't test PCI
> NICs because even the onboard 53c825 SCSI hangs - seems it gets no
> interrupts.
>
> It detects the HBA, tries device discovery, gets a timeout, ABORT,
> timeout, TARGET RESET, timeout, BUS RESET, timeout, HOST RESET and
> there it hangs.
>
> Does it work for anyone else on Powerstack II Pro4000 (Utah)?
>
It does work in 2.6.8 using backported patches (e.g. the debian 2.6.8
kernel). But it doesn't work above that version because of other patches
in arch/ppc/platforms/prep_pci.c and arch/ppc/platforms/prep_setup.c
(made by Tom Rini?). I couldn't find out what exactly is causing this
problem yet (because lack of time and the fact that my Powerstack is
used as a router).
Basti
^ permalink raw reply
* Re: [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map
From: Leigh Brown @ 2005-02-22 12:23 UTC (permalink / raw)
To: Sebastian Heutling
Cc: Tom Rini, Christian Kujau, Meelis Roos, Kernel Mailing List,
linuxppc-dev, Sven Hartge
In-Reply-To: <421B1F12.7050601@gmx.de>
Sebastian Heutling said:
> Meelis Roos wrote:
>
>>> The PCI IRQ map for the old Motorola PowerStackII (Utah) boards was
>>> incorrect, but this breakage wasn't exposed until 2.5, and finally
>>> fixed
>>> until recently by Sebastian Heutling <sheutlin@gmx.de>.
>>
>>
>> Yesterday I finally got around to testing it. It seems the patch has
>> been applied in Linus's tree so I downloaded the latest BK and tried it.
>>
>> Still does not work for me but this time it's different. Before the
>> patch SCSI worked fine but PCI NICs caused hangs. Now I can't test PCI
>> NICs because even the onboard 53c825 SCSI hangs - seems it gets no
>> interrupts.
>>
>> It detects the HBA, tries device discovery, gets a timeout, ABORT,
>> timeout, TARGET RESET, timeout, BUS RESET, timeout, HOST RESET and
>> there it hangs.
>>
>> Does it work for anyone else on Powerstack II Pro4000 (Utah)?
>>
> It does work in 2.6.8 using backported patches (e.g. the debian 2.6.8
> kernel). But it doesn't work above that version because of other patches
> in arch/ppc/platforms/prep_pci.c and arch/ppc/platforms/prep_setup.c
> (made by Tom Rini?). I couldn't find out what exactly is causing this
> problem yet (because lack of time and the fact that my Powerstack is
> used as a router).
Ah, this could well be my fault. Those patches were to improve support
of IBM RS/6000 PReP boxes. Do those machines have residual data? If
so, could anyone who has one send me the contents of /proc/residual?
Also, a full boot log when working and failing would be cool.
^ permalink raw reply
* GLIBC_2.0 not defined in libc.so.6 ---- problem
From: srinivas.surabhi @ 2005-02-22 13:27 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am facing the following problem with kernel 2.4.20. Can any body throw
light on it?
...
Freeing unused kernel memory: 56k init
init: relocation error: init: symbol optarg, version GLIBC_2.0 not
defined in file libc.so.6 with link time reference
Kernel panic: Attempted to kill init!
My one more doubt is the file libc.so.6 is it mandatory to be linked?
Thanks in advance=0D
-SS
Confidentiality Notice=0D
The information contained in this electronic message and any attachments to=
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or=
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or=
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
^ permalink raw reply
* Re: [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map
From: Christian Kujau @ 2005-02-22 16:27 UTC (permalink / raw)
To: Kernel Mailing List; +Cc: Tom Rini, Meelis Roos, linuxppc-dev, Sven Hartge
In-Reply-To: <5982.195.212.29.67.1109074991.squirrel@195.212.29.67>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leigh Brown wrote:
>>>It detects the HBA, tries device discovery, gets a timeout, ABORT,
>>>timeout, TARGET RESET, timeout, BUS RESET, timeout, HOST RESET and
>>>there it hangs.
it does not really hang, it just tries to initialize every target of the
HBA (here: from sym0:0:0: to sym0:15:0, see [1] for more info) and it is
so busy with it that the bootprocess seems to hang. after failing with the
last target, booting continues just fine. (i have no disks attached,
booting via nfsroot)
> Ah, this could well be my fault. Those patches were to improve support
> of IBM RS/6000 PReP boxes. Do those machines have residual data? If
> so, could anyone who has one send me the contents of /proc/residual?
>
> Also, a full boot log when working and failing would be cool.
[1] it's all here: http://nerdbynature.de/bits/hal/2.6.11-rc3/
(yes, they are from different dates, but the setup is the same. the
kernelversion from messages is 2.6.11-rc2, the rest is all 2.6.11-rc3,
from vanilla (-BK) sources)
thanks,
Christian.
- --
BOFH excuse #67:
descramble code needed from software company
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCG11y+A7rjkF8z0wRAvMoAKCWliE97XWNmFv+xf7d3yU5vN3tDQCffMCj
Y8hf0xXrOsCA6WkZUPKkUa0=
=ECSk
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: kernel with marvell 64360 support
From: Mark A. Greer @ 2005-02-22 17:05 UTC (permalink / raw)
To: Suresh Chandra Mannava; +Cc: Embedded PPC Linux list
In-Reply-To: <4219A711.80204@gamebox.net>
Suresh Chandra Mannava wrote:
> Hi,
>
> We designed a power-pc 7410 board with galileo mv64360 bridge.
> We are interested in porting linux on to that board.
>
> Where can I download the linux kernel with 64360 (serial, ethernet,
> PCI etc)
> drivers.
> please provide the pointers for the same.
You can get the latest code minus 3 patches and the enet driver from the
latest linux-2.5 tree on bkbits.net/kernel.org. The 3 patches are in the
linuxppc-embedded mail archive. AFAIK, the enet driver is queued to go
into the mainline tree but I don't know when that'll happen. If you
need it now, you can contact Dale Farnsworth <dfarnsworth@mvista.com>.
Mark
^ permalink raw reply
* Re: [PATCH] Non-DMA mode for floppy on PowerPC
From: Eugene Surovegin @ 2005-02-22 17:54 UTC (permalink / raw)
To: Pavel Fedin; +Cc: linuxppc-dev
In-Reply-To: <20050222130646.25bc9520.sonic_amiga@rambler.ru>
On Tue, Feb 22, 2005 at 01:06:46PM -0500, Pavel Fedin wrote:
> On Tue, 22 Feb 2005 01:32:09 -0800
> Eugene Surovegin <ebs@ebshome.net> wrote:
>
> > Please, be patient and don't repost the same stuff every day.
>
> Ok. How long does it take for a patch to get included into the
> kernel? I posted if two weeks ago for the first time and nothing
> happened. In LKML also nobody answers.
Don't know. Sometimes it takes days, sometimes months and sometimes
it never happens.
But, posting your patch every day is not gonna make it faster. It will
only annoy people and you can end up in kill file and be ignored after
that completely.
--
Eugene
^ permalink raw reply
* Looking for LKCD ppc (not ppc64)
From: Andrew Williams @ 2005-02-22 18:08 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 279 bytes --]
Has anyone done this yet? I've got an embedded board
with a periodic oops (all over the map), and we want
to generate a crashdump (or similar) when it occurs.
There appear to have been a couple of attempts to do
this, but no results had been announced/released.
Thanks,
Andrew
[-- Attachment #2: Type: text/html, Size: 746 bytes --]
^ permalink raw reply
* Re: [PATCH] Non-DMA mode for floppy on PowerPC
From: Hollis Blanchard @ 2005-02-22 15:56 UTC (permalink / raw)
To: Pavel Fedin; +Cc: Linux PPC Dev
In-Reply-To: <20050222130646.25bc9520.sonic_amiga@rambler.ru>
On Feb 22, 2005, at 12:06 PM, Pavel Fedin wrote:
> On Tue, 22 Feb 2005 01:32:09 -0800
> Eugene Surovegin <ebs@ebshome.net> wrote:
>
>> Please, be patient and don't repost the same stuff every day.
>
> Ok. How long does it take for a patch to get included into the
> kernel? I posted if two weeks ago for the first time and nothing
> happened. In LKML also nobody answers.
That generally means nobody cares (don't worry, we've all been there).
In your case, I would start by very clearly describing exactly why you
can't use DMA on Pegasos, and why the current code is unusable. Can a
PC floppy run in non-DMA mode? If so, your patch should probably be for
floppy.c rather than asm-ppc/floppy.h . I notice there is already code
for "virtual DMA mode" in floppy.c, apparently for when there is no
memory available in the DMA zone. Why doesn't that code work for you?
As for code style, it seems that "TRACE_FLPY_INT" is something you
invented. It hurts readability; I'd remove it. Drop that "register"
stuff. Make your whitespace consistent (for example, add spaces after
"if" and "for").
-Hollis
^ permalink raw reply
* Re: [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map
From: Sebastian Heutling @ 2005-02-22 18:27 UTC (permalink / raw)
To: Leigh Brown
Cc: Tom Rini, Christian Kujau, Meelis Roos, Kernel Mailing List,
linuxppc-dev, Sven Hartge
In-Reply-To: <5982.195.212.29.67.1109074991.squirrel@195.212.29.67>
Leigh Brown wrote:
>Sebastian Heutling said:
>
>
>>Meelis Roos wrote:
>>
>>
>>
>>>>The PCI IRQ map for the old Motorola PowerStackII (Utah) boards was
>>>>incorrect, but this breakage wasn't exposed until 2.5, and finally
>>>>fixed
>>>>until recently by Sebastian Heutling <sheutlin@gmx.de>.
>>>>
>>>>
>>>Yesterday I finally got around to testing it. It seems the patch has
>>>been applied in Linus's tree so I downloaded the latest BK and tried it.
>>>
>>>Still does not work for me but this time it's different. Before the
>>>patch SCSI worked fine but PCI NICs caused hangs. Now I can't test PCI
>>>NICs because even the onboard 53c825 SCSI hangs - seems it gets no
>>>interrupts.
>>>
>>>It detects the HBA, tries device discovery, gets a timeout, ABORT,
>>>timeout, TARGET RESET, timeout, BUS RESET, timeout, HOST RESET and
>>>there it hangs.
>>>
>>>Does it work for anyone else on Powerstack II Pro4000 (Utah)?
>>>
>>>
>>>
>>It does work in 2.6.8 using backported patches (e.g. the debian 2.6.8
>>kernel). But it doesn't work above that version because of other patches
>>in arch/ppc/platforms/prep_pci.c and arch/ppc/platforms/prep_setup.c
>>(made by Tom Rini?). I couldn't find out what exactly is causing this
>>problem yet (because lack of time and the fact that my Powerstack is
>>used as a router).
>>
>>
>
>Ah, this could well be my fault. Those patches were to improve support
>of IBM RS/6000 PReP boxes. Do those machines have residual data? If
>so, could anyone who has one send me the contents of /proc/residual?
>
>Also, a full boot log when working and failing would be cool.
>
>
No, the PowerstackII Pro4000 (Utah) has no residual. I couldn't see
anything unusal in the bootlogs except that
neither IDE nor SCSI interrupts occour (timeouts for SCSI and lost
interrupts for IDE). I assume other PCI-devices have a similar problem.
I will try to extract some bootlogs in the next days but I think they
won't help.
Basti
^ permalink raw reply
* PPC32 8xx MPC880 Linux 2.6 Interrupt storm
From: Povolotsky, Alexander @ 2005-02-22 18:36 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
I have MPC880 based board with 24C02 I2C serial EEPROM
and I try to run Linux 2.6 on this board.
Originally I had problem:
<3>request_irq() returned -22 for CPM vector 32.
I traced the problem to the following line,
shown below as commented out (by me)
in cpm_iic_init() (drivers/i2c/algos/i2c-algo-8xx.c)
/* (*cpm_adap->setisr)(CPM_IRQ_OFFSET + CPMVEC_I2C, cpm_iic_interrupt,
cpm_int_name[CPMVEC_I2C], (void *)i2c); */
^ ^
| |
16 16
It makes the first argument to be 32 (16 + 16) and that was originally
causing error.
This error gets generated actually in request_irq() in kernel/irq/manage.c.
Specifically (I tracked it down with debug print there ) it comes from
if (irq >= NR_IRQS)
return -EINVAL;
Note that NR_IRQS is set to 32 and irq was also 32 as described above
(before my "fix" - see below) .
I have made the "fix" (it's just a kludge, I am not sure where the correct
fix should be
and what is the actual origin of this problem):
(*cpm_adap->setisr)(CPM_IRQ_OFFSET + CPMVEC_I2C - CPM_IRQ_OFFSET,
cpm_iic_interrupt, cpm_int_name[CPMVEC_I2C], (void *)i2c);
^^^^^^^^^^^^^^^
I am leaving above line "as is" just for demonstrational purpose: to show
that in the first argument the
CPM_IRQ_OFFSET is originally added and I am subtracting it back.
This gives:
cpm_iic_init[134] Install ISR for IRQ 16 CPM_IRQ_OFFSET 16
rpx_install_isr: irq: 0x10 <<<============= This is correct IRQ for I2C
on 8xx
However after this "fix" I see continuos flood of interrupts for IRQ 0x10
(dedicated to I2C on 8xx) in response to polling of 0x50 I2C address
- should be just one interrupt ...
but actually, the ISR function gets triggered in continuous non-stop flood -
I could see it with the print statement (of course I disabled this print for
the next build ...) so it chokes the processor completely.
Thanks,
Best Regards,
Alex
^ permalink raw reply
* RE: PPC32 8xx MPC880 Linux 2.6 Interrupt storm
From: Povolotsky, Alexander @ 2005-02-22 19:03 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
- I forgot to mention in my post that i2c-algo-8xx.c and i2c-algo-8xx.h,
which I am using, were "taken" from Linux 2.4.26 ...
until some time ago, even bulding of 8xx with I2C configured was broken.
I copied i2c-algo-8xx.h from Linux 2.4.26
into 2.6.10-rc3 code source and made couple small changes
to allow building of the 8xx code with I2C configured, please see:
http://archives.andrew.net.au/lm-sensors/msg28725.html
Could there be some incompatibility between the way how i2c-algo-8xx.c
("taken" from Linux 2.4.26 )
handles interrupt vs how it is "expected to be " by Linux 2.6 ?
^ permalink raw reply
* Re: kernel with marvell 64360 support
From: Mark A. Greer @ 2005-02-22 21:04 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Embedded PPC Linux list
In-Reply-To: <421B666B.205@mvista.com>
Mark A. Greer wrote:
> Suresh Chandra Mannava wrote:
>
>> Hi,
>>
>> We designed a power-pc 7410 board with galileo mv64360 bridge.
>> We are interested in porting linux on to that board.
>>
>> Where can I download the linux kernel with 64360 (serial, ethernet,
>> PCI etc)
>> drivers.
>> please provide the pointers for the same.
>
>
>
> You can get the latest code minus 3 patches and the enet driver from
> the latest linux-2.5 tree on bkbits.net/kernel.org. The 3 patches are
> in the linuxppc-embedded mail archive. AFAIK, the enet driver is
> queued to go into the mainline tree but I don't know when that'll
> happen. If you need it now, you can contact Dale Farnsworth
> <dfarnsworth@mvista.com>.
I failed to mention that there is an i2c driver queued to go in at:
http://archives.andrew.net.au/lm-sensors/msg29471.html
Mark
^ permalink raw reply
* kgdb on 2.4.21 on Ebony
From: Prosun Niyogi @ 2005-02-22 18:43 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
Has anyone used kgdb on a 2.4.21 kernel on 44x hardware? I am attempting
to do this, but am running into problems with kgdb serial port setup. The
gdb stub is not being transmitted correctly to the development machine. I
would greatly appreciate it if someone who has done this before could
point me to some documentation or explain their setup to me. Any pointers
would be appreciated.
Thanks,
Prosun Niyogi
pniyogi@us.ibm.com
[-- Attachment #2: Type: text/html, Size: 568 bytes --]
^ permalink raw reply
* Re: mv64x60 patches for Radstone PPC7D - for review
From: Mark A. Greer @ 2005-02-22 22:27 UTC (permalink / raw)
To: James Chapman; +Cc: linuxppc-embedded
In-Reply-To: <421B4126.1070808@katalix.com>
Hi James.
James Chapman wrote:
> Attached is a series of patches adding support for Radstone PPC7D
> boards and Marvell Discovery watchdog. PPC7D are rugged Marvell
> Discovery boards with PPC7447A CPUs, dual GigE, dual PMC and optional
> SCSI, VGA.
>
> Signed-off-by: James Chapman <jchapman@katalix.com>
>
> The patches are split into separate pieces to aid review. Most patches
> are generic for mv64x60 boards and could be applied separately. Patch
> p9, however, requires all other patches.
From now on, please make a separate email per patch. That way the
email threads/patch discussions are easier to track.
>
>
> Patch p2 just makes fields in /proc/interrupts line up so it is
> optional.
>
> p1 - fix mv64360_pic_irq_offset bugs when non-zero
While you're in there, would you make a #define for the IRQ 28 in
include/asm-ppc/mv64x60_defs.h. Otherwise, it looks good.
>
>
> p2 - cleanup formatting of mv64360 entries in /proc/interrupts
> [optional]
Looks fine but you may as well combine w/ patch p1.
>
>
> p3 - add pciauto_ignore_device() hook to allow platforms to ignore
> specific devices in pciauto_bus_scan(). Should this hook be
> in ppc_md instead?
Is there a reason ppc_md.pci_exclude_device doesn't work?
>
>
> p4 - add GPP IO pin/IRQ register definitions
Looks fine.
>
>
> p5 - add extern i8259_pic_irq_offset
XXXX
>
>
> p6 - add 7447A and 7457 CPU definitions
Looks okay to me but these should probably be posted to linuxppc-dev.
>
>
> p7 - add mv64x60 watchdog support
I think it would be better to use platform_data to pass in the
duration/timeout value and not a config option. Other than that, it
looks okay to me but I didn't go over it in detail.
When you separate this patch into its own email, you should send it to
whoever looks after the watchdog drivers, cc the appropriate mailing
list, and lmkl and/or linuxppc-embedded.
>
>
> p8 - add mv64x60_setclr_bits() which can be used to set and clear bits
> of a mv64x60 register with a single chip register write.
Is this really necessary? I have learned that many in the community
really hate little routines like this. I have a todo item to get rid of
the _set/clr_bits routines and replace them explicit code.
>
>
> p9 - add Radstone PPC7D board support
I didn't go through this in great detail but I do have a few comments:
> +++ linux-2.6/arch/ppc/boot/simple/misc-radstone_ppc7d.c
> +void __attribute__ ((weak)) mv64x60_board_init(void)
Don't make this "weak", there is one alread defined as weak that you're
replacing.
> + /* Map 0xe0000000-0xffffffff early because we need access to SRAM
> + * and the ISA memory space (for serial port) here.
You mean for accessing the serial port while in the bootwrapper, right?
The firmware doesn't put anything out the serial port? If so, there is
likely a mapping alread setup for you to use, no?
> +++ linux-2.6/arch/ppc/Kconfig
Why bother with RADSTONE_DEBUG? Plus I'm told that pr_debug() is the
preferred method for this.
Why a separate CONFIG_RADSTONE and CONFIG_RADSTONE_PPC7C? You never use
CONFIG_RADSTONE.
> +++ linux-2.6/arch/ppc/platforms/radstone_ppc7d.c
It looks like you only really use the 8250 uart. Is that correct? If
so, get rid of the MPSC stuff since its only clutter.
> static void __init ppc7d_early_serial_map(void)
I don't think you need this as long as you have your
STD_SERIAL_PORT_DFNS setup correctly.
> TODC_ALLOC();
It doesn't look like you need this since you don't actually use a
time-of-day/realtime clock.
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1533, ppc7d_fixup_ali1535);
You have a lot of pci fixups. Are they all necessary? I noticed a
quirk already implemented for the 1533...
General note: you have a lot of lines that wrap in an 80 column window.
I guess its a personal preference but I find it hard to read. Would you
mind breaking them into separate lines?
Mark
^ permalink raw reply
* Re: mv64x60 patches for Radstone PPC7D - for review
From: Mark A. Greer @ 2005-02-22 23:04 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <421BB1CB.1070803@mvista.com>
Mark A. Greer wrote:
> Hi James.
>
> James Chapman wrote:
>
>>
>> p5 - add extern i8259_pic_irq_offset
>
>
>
> XXXX
Oops, hit send to soon.
This looks okay but in your platform file, you never set it anyway so
you don't need to access it in there.
Mark
^ permalink raw reply
* [PATCH} include/asm-ppc/cpu2.h typo
From: Mark A. Greer @ 2005-02-22 23:32 UTC (permalink / raw)
To: Embedded PPC Linux list
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
Hi,
This bug/typo was pointed out to me. I looked at the 8260 & 8272
manuals and it should be 0x0002 in both cases. I don't work with the
82[67]x processors but it looks like this would have quickly bit anyone
trying even parity on their serial line. Nobody uses even parity on
those platforms? Is there something I don't know (and the manual isn't
telling me)?
Mark
[-- Attachment #2: cpm2_1.patch --]
[-- Type: text/plain, Size: 432 bytes --]
diff -Nru a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
--- a/include/asm-ppc/cpm2.h 2005-02-22 16:26:07 -07:00
+++ b/include/asm-ppc/cpm2.h 2005-02-22 16:26:07 -07:00
@@ -531,7 +531,7 @@
#define SCU_PSMR_RPM ((ushort)0x000c)
#define SCU_PSMR_REVP ((ushort)0x0008)
#define SCU_PSMR_TPM ((ushort)0x0003)
-#define SCU_PSMR_TEVP ((ushort)0x0003)
+#define SCU_PSMR_TEVP ((ushort)0x0002)
/* CPM Transparent mode SCC.
*/
^ permalink raw reply
* [PPC32] Report chip version in /proc/cpuinfo for 85xx boards
From: Kumar Gala @ 2005-02-22 19:41 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Andrew,
Here is a patch for post 2.6.11.
Report the chip version in /proc/cpuinfo on 85xx ADS and CDS platforms.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c 2005-02-22 13:22:09 -06:00
+++ b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c 2005-02-22 13:22:09 -06:00
@@ -128,6 +128,7 @@
pvid = mfspr(PVR);
svid = mfspr(SVR);
+ seq_printf(m, "chip\t\t: %s\n", cur_ppc_sys_spec->ppc_sys_name);
seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
switch (svid & 0xffff0000) {
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-02-22 13:22:09 -06:00
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-02-22 13:22:09 -06:00
@@ -145,6 +145,7 @@
pvid = mfspr(PVR);
svid = mfspr(SVR);
+ seq_printf(m, "chip\t\t: %s\n", cur_ppc_sys_spec->ppc_sys_name);
seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
seq_printf(m, "Machine\t\t: CDS (%x)\n", cadmus[CM_VER]);
seq_printf(m, "clock\t\t: %dMHz\n", freq / 1000000);
^ permalink raw reply
* [PPC32] fix formatting of CDS common platform file
From: Kumar Gala @ 2005-02-22 19:42 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Andrew,
Here is a patch for post 2.6.11.
Fixes formatting of mpc85xx_cds_common.c
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-02-22 13:35:18 -06:00
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-02-22 13:35:18 -06:00
@@ -73,60 +73,60 @@
/* Internal interrupts are all Level Sensitive, and Positive Polarity */
static u_char mpc85xx_cds_openpic_initsenses[] __initdata = {
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 0: L2 Cache */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 1: ECM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 2: DDR DRAM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 3: LBIU */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 4: DMA 0 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 5: DMA 1 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 6: DMA 2 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 7: DMA 3 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 8: PCI/PCI-X */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 9: RIO Inbound Port Write Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 10: RIO Doorbell Inbound */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 11: RIO Outbound Message */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 12: RIO Inbound Message */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 13: TSEC 0 Transmit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 14: TSEC 0 Receive */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 15: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 16: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 17: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 18: TSEC 0 Receive/Transmit Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 19: TSEC 1 Transmit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 20: TSEC 1 Receive */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 21: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 22: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 23: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 24: TSEC 1 Receive/Transmit Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 25: Fast Ethernet */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 26: DUART */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 27: I2C */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 28: Performance Monitor */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 29: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 30: CPM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 31: Unused */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 0: L2 Cache */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 1: ECM */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 2: DDR DRAM */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 3: LBIU */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 4: DMA 0 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 5: DMA 1 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 6: DMA 2 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 7: DMA 3 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 8: PCI/PCI-X */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 9: RIO Inbound Port Write Error */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 10: RIO Doorbell Inbound */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 11: RIO Outbound Message */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 12: RIO Inbound Message */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 13: TSEC 0 Transmit */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 14: TSEC 0 Receive */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 15: Unused */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 16: Unused */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 17: Unused */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 18: TSEC 0 Receive/Transmit Error */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 19: TSEC 1 Transmit */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 20: TSEC 1 Receive */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 21: Unused */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 22: Unused */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 23: Unused */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 24: TSEC 1 Receive/Transmit Error */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 25: Fast Ethernet */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 26: DUART */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 27: I2C */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 28: Performance Monitor */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 29: Unused */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 30: CPM */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 31: Unused */
#if defined(CONFIG_PCI)
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 0: PCI1 slot */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 1: PCI1 slot */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 2: PCI1 slot */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 3: PCI1 slot */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 0: PCI1 slot */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 1: PCI1 slot */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 2: PCI1 slot */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 3: PCI1 slot */
#else
- 0x0, /* External 0: */
- 0x0, /* External 1: */
- 0x0, /* External 2: */
- 0x0, /* External 3: */
-#endif
- 0x0, /* External 4: */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 5: PHY */
- 0x0, /* External 6: */
- 0x0, /* External 7: */
- 0x0, /* External 8: */
- 0x0, /* External 9: */
- 0x0, /* External 10: */
+ 0x0, /* External 0: */
+ 0x0, /* External 1: */
+ 0x0, /* External 2: */
+ 0x0, /* External 3: */
+#endif
+ 0x0, /* External 4: */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 5: PHY */
+ 0x0, /* External 6: */
+ 0x0, /* External 7: */
+ 0x0, /* External 8: */
+ 0x0, /* External 9: */
+ 0x0, /* External 10: */
#if defined(CONFIG_85xx_PCI2) && defined(CONFIG_PCI)
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 11: PCI2 slot 0 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 11: PCI2 slot 0 */
#else
- 0x0, /* External 11: */
+ 0x0, /* External 11: */
#endif
};
@@ -134,32 +134,32 @@
int
mpc85xx_cds_show_cpuinfo(struct seq_file *m)
{
- uint pvid, svid, phid1;
- uint memsize = total_memory;
- bd_t *binfo = (bd_t *) __res;
- unsigned int freq;
+ uint pvid, svid, phid1;
+ uint memsize = total_memory;
+ bd_t *binfo = (bd_t *) __res;
+ unsigned int freq;
- /* get the core frequency */
- freq = binfo->bi_intfreq;
+ /* get the core frequency */
+ freq = binfo->bi_intfreq;
- pvid = mfspr(PVR);
- svid = mfspr(SVR);
+ pvid = mfspr(PVR);
+ svid = mfspr(SVR);
seq_printf(m, "chip\t\t: %s\n", cur_ppc_sys_spec->ppc_sys_name);
- seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
+ seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
seq_printf(m, "Machine\t\t: CDS (%x)\n", cadmus[CM_VER]);
seq_printf(m, "clock\t\t: %dMHz\n", freq / 1000000);
- seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
- seq_printf(m, "SVR\t\t: 0x%x\n", svid);
+ seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
+ seq_printf(m, "SVR\t\t: 0x%x\n", svid);
- /* Display cpu Pll setting */
- phid1 = mfspr(HID1);
- seq_printf(m, "PLL setting\t: 0x%x\n", ((phid1 >> 24) & 0x3f));
+ /* Display cpu Pll setting */
+ phid1 = mfspr(HID1);
+ seq_printf(m, "PLL setting\t: 0x%x\n", ((phid1 >> 24) & 0x3f));
- /* Display the amount of memory */
- seq_printf(m, "Memory\t\t: %d MB\n", memsize / (1024 * 1024));
+ /* Display the amount of memory */
+ seq_printf(m, "Memory\t\t: %d MB\n", memsize / (1024 * 1024));
- return 0;
+ return 0;
}
#ifdef CONFIG_CPM2
@@ -186,21 +186,21 @@
int i;
#endif
- /* Determine the Physical Address of the OpenPIC regs */
- phys_addr_t OpenPIC_PAddr = binfo->bi_immr_base + MPC85xx_OPENPIC_OFFSET;
- OpenPIC_Addr = ioremap(OpenPIC_PAddr, MPC85xx_OPENPIC_SIZE);
- OpenPIC_InitSenses = mpc85xx_cds_openpic_initsenses;
- OpenPIC_NumInitSenses = sizeof (mpc85xx_cds_openpic_initsenses);
-
- /* Skip reserved space and internal sources */
- openpic_set_sources(0, 32, OpenPIC_Addr + 0x10200);
- /* Map PIC IRQs 0-11 */
- openpic_set_sources(32, 12, OpenPIC_Addr + 0x10000);
-
- /* we let openpic interrupts starting from an offset, to
- * leave space for cascading interrupts underneath.
- */
- openpic_init(MPC85xx_OPENPIC_IRQ_OFFSET);
+ /* Determine the Physical Address of the OpenPIC regs */
+ phys_addr_t OpenPIC_PAddr = binfo->bi_immr_base + MPC85xx_OPENPIC_OFFSET;
+ OpenPIC_Addr = ioremap(OpenPIC_PAddr, MPC85xx_OPENPIC_SIZE);
+ OpenPIC_InitSenses = mpc85xx_cds_openpic_initsenses;
+ OpenPIC_NumInitSenses = sizeof (mpc85xx_cds_openpic_initsenses);
+
+ /* Skip reserved space and internal sources */
+ openpic_set_sources(0, 32, OpenPIC_Addr + 0x10200);
+ /* Map PIC IRQs 0-11 */
+ openpic_set_sources(32, 12, OpenPIC_Addr + 0x10000);
+
+ /* we let openpic interrupts starting from an offset, to
+ * leave space for cascading interrupts underneath.
+ */
+ openpic_init(MPC85xx_OPENPIC_IRQ_OFFSET);
#ifdef CONFIG_CPM2
/* disable all CPM interupts */
@@ -220,7 +220,7 @@
setup_irq(MPC85xx_IRQ_CPM, &cpm2_irqaction);
#endif
- return;
+ return;
}
#ifdef CONFIG_PCI
@@ -279,8 +279,8 @@
}
}
-#define ARCADIA_HOST_BRIDGE_IDSEL 17
-#define ARCADIA_2ND_BRIDGE_IDSEL 3
+#define ARCADIA_HOST_BRIDGE_IDSEL 17
+#define ARCADIA_2ND_BRIDGE_IDSEL 3
extern int mpc85xx_pci1_last_busno;
@@ -290,7 +290,7 @@
if (bus == 0 && PCI_SLOT(devfn) == 0)
return PCIBIOS_DEVICE_NOT_FOUND;
#ifdef CONFIG_85xx_PCI2
- if (mpc85xx_pci1_last_busno)
+ if (mpc85xx_pci1_last_busno)
if (bus == (mpc85xx_pci1_last_busno + 1) && PCI_SLOT(devfn) == 0)
return PCIBIOS_DEVICE_NOT_FOUND;
#endif
@@ -312,14 +312,14 @@
static void __init
mpc85xx_cds_setup_arch(void)
{
- bd_t *binfo = (bd_t *) __res;
- unsigned int freq;
+ bd_t *binfo = (bd_t *) __res;
+ unsigned int freq;
struct gianfar_platform_data *pdata;
- /* get the core frequency */
- freq = binfo->bi_intfreq;
+ /* get the core frequency */
+ freq = binfo->bi_intfreq;
- printk("mpc85xx_cds_setup_arch\n");
+ printk("mpc85xx_cds_setup_arch\n");
#ifdef CONFIG_CPM2
cpm2_reset();
@@ -329,17 +329,17 @@
cds_pci_slot = ((cadmus[CM_CSR] >> 6) & 0x3) + 1;
printk("CDS Version = %x in PCI slot %d\n", cadmus[CM_VER], cds_pci_slot);
- /* Set loops_per_jiffy to a half-way reasonable value,
- for use until calibrate_delay gets called. */
- loops_per_jiffy = freq / HZ;
+ /* Set loops_per_jiffy to a half-way reasonable value,
+ for use until calibrate_delay gets called. */
+ loops_per_jiffy = freq / HZ;
#ifdef CONFIG_PCI
- /* setup PCI host bridges */
- mpc85xx_setup_hose();
+ /* setup PCI host bridges */
+ mpc85xx_setup_hose();
#endif
#ifdef CONFIG_SERIAL_8250
- mpc85xx_early_serial_map();
+ mpc85xx_early_serial_map();
#endif
#ifdef CONFIG_SERIAL_TEXT_DEBUG
@@ -367,14 +367,14 @@
#ifdef CONFIG_BLK_DEV_INITRD
- if (initrd_start)
- ROOT_DEV = Root_RAM0;
- else
+ if (initrd_start)
+ ROOT_DEV = Root_RAM0;
+ else
#endif
#ifdef CONFIG_ROOT_NFS
- ROOT_DEV = Root_NFS;
+ ROOT_DEV = Root_NFS;
#else
- ROOT_DEV = Root_HDA1;
+ ROOT_DEV = Root_HDA1;
#endif
}
@@ -383,18 +383,18 @@
platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
unsigned long r6, unsigned long r7)
{
- /* parse_bootinfo must always be called first */
- parse_bootinfo(find_bootinfo());
+ /* parse_bootinfo must always be called first */
+ parse_bootinfo(find_bootinfo());
- /*
- * If we were passed in a board information, copy it into the
- * residual data area.
- */
- if (r3) {
- memcpy((void *) __res, (void *) (r3 + KERNELBASE),
- sizeof (bd_t));
+ /*
+ * If we were passed in a board information, copy it into the
+ * residual data area.
+ */
+ if (r3) {
+ memcpy((void *) __res, (void *) (r3 + KERNELBASE),
+ sizeof (bd_t));
- }
+ }
#ifdef CONFIG_SERIAL_TEXT_DEBUG
{
bd_t *binfo = (bd_t *) __res;
@@ -402,7 +402,7 @@
/* Use the last TLB entry to map CCSRBAR to allow access to DUART regs */
settlbcam(NUM_TLBCAMS - 1, binfo->bi_immr_base,
- binfo->bi_immr_base, MPC85xx_CCSRBAR_SIZE, _PAGE_IO, 0);
+ binfo->bi_immr_base, MPC85xx_CCSRBAR_SIZE, _PAGE_IO, 0);
memset(&p, 0, sizeof (p));
p.iotype = SERIAL_IO_MEM;
@@ -421,49 +421,49 @@
#endif
#if defined(CONFIG_BLK_DEV_INITRD)
- /*
- * If the init RAM disk has been configured in, and there's a valid
- * starting address for it, set it up.
- */
- if (r4) {
- initrd_start = r4 + KERNELBASE;
- initrd_end = r5 + KERNELBASE;
- }
-#endif /* CONFIG_BLK_DEV_INITRD */
-
- /* Copy the kernel command line arguments to a safe place. */
-
- if (r6) {
- *(char *) (r7 + KERNELBASE) = 0;
- strcpy(cmd_line, (char *) (r6 + KERNELBASE));
- }
+ /*
+ * If the init RAM disk has been configured in, and there's a valid
+ * starting address for it, set it up.
+ */
+ if (r4) {
+ initrd_start = r4 + KERNELBASE;
+ initrd_end = r5 + KERNELBASE;
+ }
+#endif /* CONFIG_BLK_DEV_INITRD */
+
+ /* Copy the kernel command line arguments to a safe place. */
+
+ if (r6) {
+ *(char *) (r7 + KERNELBASE) = 0;
+ strcpy(cmd_line, (char *) (r6 + KERNELBASE));
+ }
identify_ppc_sys_by_id(mfspr(SVR));
- /* setup the PowerPC module struct */
- ppc_md.setup_arch = mpc85xx_cds_setup_arch;
- ppc_md.show_cpuinfo = mpc85xx_cds_show_cpuinfo;
-
- ppc_md.init_IRQ = mpc85xx_cds_init_IRQ;
- ppc_md.get_irq = openpic_get_irq;
-
- ppc_md.restart = mpc85xx_restart;
- ppc_md.power_off = mpc85xx_power_off;
- ppc_md.halt = mpc85xx_halt;
-
- ppc_md.find_end_of_memory = mpc85xx_find_end_of_memory;
-
- ppc_md.time_init = NULL;
- ppc_md.set_rtc_time = NULL;
- ppc_md.get_rtc_time = NULL;
- ppc_md.calibrate_decr = mpc85xx_calibrate_decr;
+ /* setup the PowerPC module struct */
+ ppc_md.setup_arch = mpc85xx_cds_setup_arch;
+ ppc_md.show_cpuinfo = mpc85xx_cds_show_cpuinfo;
+
+ ppc_md.init_IRQ = mpc85xx_cds_init_IRQ;
+ ppc_md.get_irq = openpic_get_irq;
+
+ ppc_md.restart = mpc85xx_restart;
+ ppc_md.power_off = mpc85xx_power_off;
+ ppc_md.halt = mpc85xx_halt;
+
+ ppc_md.find_end_of_memory = mpc85xx_find_end_of_memory;
+
+ ppc_md.time_init = NULL;
+ ppc_md.set_rtc_time = NULL;
+ ppc_md.get_rtc_time = NULL;
+ ppc_md.calibrate_decr = mpc85xx_calibrate_decr;
#if defined(CONFIG_SERIAL_8250) && defined(CONFIG_SERIAL_TEXT_DEBUG)
- ppc_md.progress = gen550_progress;
+ ppc_md.progress = gen550_progress;
#endif /* CONFIG_SERIAL_8250 && CONFIG_SERIAL_TEXT_DEBUG */
- if (ppc_md.progress)
- ppc_md.progress("mpc85xx_cds_init(): exit", 0);
+ if (ppc_md.progress)
+ ppc_md.progress("mpc85xx_cds_init(): exit", 0);
- return;
+ return;
}
^ permalink raw reply
* Re: [PATCH] Non-DMA mode for floppy on PowerPC
From: Benjamin Herrenschmidt @ 2005-02-23 1:59 UTC (permalink / raw)
To: Pavel Fedin; +Cc: linuxppc-dev list
In-Reply-To: <20050222130646.25bc9520.sonic_amiga@rambler.ru>
On Tue, 2005-02-22 at 13:06 -0500, Pavel Fedin wrote:
> On Tue, 22 Feb 2005 01:32:09 -0800
> Eugene Surovegin <ebs@ebshome.net> wrote:
>
> > Please, be patient and don't repost the same stuff every day.
>
> Ok. How long does it take for a patch to get included into the kernel? I
> posted if two weeks ago for the first time and nothing happened. In LKML also nobody answers.
Maybe you haven't noticed but 2.6.11 is actually in late -rc phase and
not open to such patches.
Just be patient. Patches posted to linuxppc-dev or linuxppc64-dev are
generally not lost as we have an automatic patch tracking system there.
It will be picked up at one point.
Also, it's a good habit, _especially_ if you re-post your patch, to
actually repost it properly re-based against the latest linux bk tree,
or at least the latest -rc, and with the proper format (which is -p1),
maintainers just don't have time to play at fixing patches.
Ben.
^ permalink raw reply
* Ethernet doesn't work in linux for PPC440GP?
From: Shawn Jin @ 2005-02-23 3:07 UTC (permalink / raw)
To: uboot, ppcembed
Hi,
First please forgive me for the cross-list post. I do believe this
topic is related to both lists.
I'm playing with UBoot and Linux 2.6.10 on IBM PPC440GP evaluation
board (Ebony) and have some issue with ethernet. With Rom Monitor
linux 2.6.10 was running successfully using default configuration for
Ebony. Here the scree dump for ethernet dection.
emac: IBM EMAC Ethernet driver, version 2.0
Maintained by Benjamin Herrenschmidt <benh@kernel.crashing.org>
zmii0: input 0 in RMII mode
eth0: IBM emac, MAC 00:04:ac:e3:1b:bb
eth0: Found Generic MII PHY (0x08)
zmii0: input 1 in RMII mode
eth1: IBM emac, MAC 00:04:ac:e3:1b:bc
eth1: Found Generic MII PHY (0x09)
However with Uboot, the emac driver cannot read MAC addresses from VPD
correctly. The original 2.6.10 code didn't recognize uboot's bd_info.
After some hack eth0 gets its MAC address from uboot's bd_info and
seems initialized correctly. But somehow booting an NFS root fs
failed. So I suspect it's due to the ethernet driver. BTW, the same
image is used in the two
emac: IBM EMAC Ethernet driver, version 2.0
Maintained by Benjamin Herrenschmidt <benh@kernel.crashing.org>
zmii0: input 0 in SMII mode
eth0: IBM emac, MAC 00:04:ac:e3:1b:bb
eth0: Found Generic MII PHY (0x08)
zmii0: input 1 in RMII mode
eth1: IBM emac, MAC FF:FF:FF:FF:FF:FF
eth1: Found Generic MII PHY (0x09)
I know there was discussion about what a linux ethernet driver should
expect from boot loader. In fact the driver shouldn't expect anything
from a boot loader. Wolfgang has the same opinion in his DULG. What I
don't know is if this EMAC driver expects something configured by boot
loader? It seems to me that Rom Monitor did configure something for
ethernet that the EMAC driver expected.
Anyone has the similar problem before?
Thanks,
-Shawn.
^ permalink raw reply
* [PATCH] ppc32: kernel mapping breakage
From: Benjamin Herrenschmidt @ 2005-02-23 3:35 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: linuxppc-dev list, Linux Kernel list
Hi !
Christoph Lameter's patch that change page allocators to use GFP_ZERO
broke ppc32 in a subtle way. Our allocator is designed to work before
mem_init_done, in which cases it uses a ppc specific early_get_page()
which doesn't return zeroed pages. However, he removed the call to
clear_page() unconditionally, thus causing the kernel initial page
tables to have random data in them.
They are initialized with set_pte, which means it's _mostly_ harmless,
except that set_pte on ppc32 preserves the _PAGE_HASHPTE bit, thus we
end up with random bits there, which can cause issues with further
manipulation of the kernel page tables and will slow down all hash
faults to them causing unnecessary searches.
Please apply in 2.6.11 if still possible ...
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/ppc/mm/pgtable.c
===================================================================
--- linux-work.orig/arch/ppc/mm/pgtable.c 2005-01-24 17:09:23.000000000 +1100
+++ linux-work/arch/ppc/mm/pgtable.c 2005-02-23 14:31:41.000000000 +1100
@@ -107,8 +107,11 @@
ptepage->mapping = (void *) mm;
ptepage->index = address & PMD_MASK;
}
- } else
+ } else {
pte = (pte_t *)early_get_page();
+ if (pte)
+ clear_page(pte);
+ }
return pte;
}
^ permalink raw reply
* Re: Ethernet doesn't work in linux for PPC440GP?
From: Eugene Surovegin @ 2005-02-23 4:22 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b050222190712ee7dff@mail.gmail.com>
On Tue, Feb 22, 2005 at 07:07:44PM -0800, Shawn Jin wrote:
> zmii0: input 0 in SMII mode
> eth0: IBM emac, MAC 00:04:ac:e3:1b:bb
> eth0: Found Generic MII PHY (0x08)
> zmii0: input 1 in RMII mode
> eth1: IBM emac, MAC FF:FF:FF:FF:FF:FF
> eth1: Found Generic MII PHY (0x09)
I already told you that this is wrong, why are you asking again?
Please, if you asking questions, spend some time reading answers
given to you, before asking again.
ZMII bridge cannot have inputs in different modes (SMII and RMII).
Ebony uses RMII, so SMII is obviously wrong. Most probably your
firmware doesn't set correct mode and autodetection in the EMAC driver
fails.
--
Eugene.
^ permalink raw reply
* Re: Ethernet doesn't work in linux for PPC440GP?
From: Eugene Surovegin @ 2005-02-23 4:29 UTC (permalink / raw)
To: Shawn Jin; +Cc: uboot, ppcembed
In-Reply-To: <c3d0340b050222190712ee7dff@mail.gmail.com>
On Tue, Feb 22, 2005 at 07:07:44PM -0800, Shawn Jin wrote:
> However with Uboot, the emac driver cannot read MAC addresses from VPD
> correctly. The original 2.6.10 code didn't recognize uboot's bd_info.
You are welcome to submit patch with U-Boot support for Ebony.
Currently only OpenBIOS is supported.
Look at the way it was done for Ocotea, 2.6 now supports both U-Boot
and PIBS.
--
Eugene
^ 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