* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: David Woodhouse @ 2004-11-22 8:25 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20041121173711.GA5692@austin.ibm.com>
On Sun, 2004-11-21 at 11:37 -0600, Olof Johansson wrote:
> On Sun, Nov 21, 2004 at 11:01:08AM +1100, Benjamin Herrenschmidt wrote:
> > > Ok, I already found a bug, occasional lockups on boot and when setting
> > > the backlight. I uploaded a new version at:
> >
> > Here's a 3rd version. It may or may not help, as I didn't have a chance
> > to test this one on either albook or ibook g4 yet. I added saving and
> > restoring of a few more registers that may fix the Xv problem (or not...
> > depends what X does at this point) and eventually some corruption
> > problem (the bandwidth related registers weren't restored).
>
> This one caused problems for me. Looks like the backlight got turned off
> at boot, I had to sleep it and wake it up to get it back.
I've seen that since the first version. I also have to restart
pbbuttonsd to make it work again after sleep. I keep logging in on tty1
to run 'fblevel 15'.
Actually the backlight tends to turn off some time later, too. It's not
just that it's off after sleep.
--
dwmw2
^ permalink raw reply
* Re: TEST: Sleep patch #4
From: Sean Neakums @ 2004-11-22 13:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, gentoo-ppc-user,
debian-powerpc@lists.debian.org
In-Reply-To: <1101083578.13597.5.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> Ok, here's the 4th iteration of the patch. It includes John Steele
> Scott fixes for cpufreq and the sound driver and fixes a problem
> where memory refresh wouldn't properly be re-enabled on the video
> chip upon wakeup. I also cleaned a bit more the MDLL reset code for
> r300, plus a couple of other things.
>
> http://gate.crashing.org/~benh/albook-ibookg4-sleep-4.diff
Works great now (15" 1.5GHz PB).
Many thanks!
^ permalink raw reply
* RE: Large PCI region mapping 8272
From: Milligan, Keath @ 2004-11-22 16:15 UTC (permalink / raw)
To: linuxppc-dev
Well, I've confirmed that I have the right platform files and I've =
enabled
debugging in most of the related files.
At this point, I am specifically concerned about code in
arch/ppc/kernel/mpc10x_common.c and m8260_setup.c.
In mpc10x_common.c there is a setup switch statement that has the =
following
case for the 8272ADS:
#if defined CONFIG_MPC8272ADS || defined CONFIG_ADS8266
case MPC10X_MEM_MAP_826x:
pci_init_resource(&hose->io_resource,
#if 0 /* zhx */
0xe0000000,
0xeeffffff,
#else
0xa0000000,
0xafffffff,
#endif
IORESOURCE_IO,
"PCI host bridge");
pci_init_resource (&hose->mem_resources[0],
0x80000000,
0x9fffffff,
IORESOURCE_MEM,
"PCI host bridge");
break;
This seems to be limiting resources to a0000000-afffffff and
80000000-9fffffff. Does anyone know where these hard-coded values come =
from?
Also in m8260_setup.c, more hard-coded ranges appear in m8260_map_io().
These would seem to suggest the 8272ADS is pretty limited on the amount =
of
PCI-mapped memory that it can handle.
-----Original Message-----
From: Marc Leeman [mailto:marc.leeman@gmail.com]=20
Sent: Friday, November 19, 2004 4:34 AM
To: Milligan, Keath
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Large PCI region mapping 8272
> Could someone point me in the right direction to getting everything
> initialized and mapped correctly?
I had the same impression (that the PCI initialisation) was not quite
right. After some investigation, it was me that used a wrong platform
file (overzealous deleting and copying to minimise custom code).
>From what I understand (after a brief look in the files), most of the
changes can be localised in that file.
You can enable debugging in (IIRC) -#define DEBUG-
arch/ppc/kernel/pci.c
to have a more verbose look at what is happening.
The same goes for quircks.c and pci.c (in drivers/ somewhere).
In any case, the pci mapping calls your platform dependent fixes.=20
--=20
ash nazg durbatul=FBk, ash nazg gimbatul,
ash nazg thrakatul=FBk agh burzum-ishi krimpatul
^ permalink raw reply
* Re: TEST: Sleep patch #4
From: Keith Conger @ 2004-11-22 16:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt, debian-powerpc@lists.debian.org,
linuxppc-dev list, gentoo-ppc-user
In-Reply-To: <6ullcuggfr.fsf@zork.zork.net>
Hi,
Works great here also (15" 1GHz PB). One issue which may be unrelated
I have some sound issues. For instance one a sound is played it sounds
fine but if a sound is played right after its volume is extremely low.
But with headphones this doesn't occur.
Thanks again for your hard work.
Keith
On Mon, 22 Nov 2004 13:29:44 +0000, Sean Neakums <sneakums@zork.net> wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > Ok, here's the 4th iteration of the patch. It includes John Steele
> > Scott fixes for cpufreq and the sound driver and fixes a problem
> > where memory refresh wouldn't properly be re-enabled on the video
> > chip upon wakeup. I also cleaned a bit more the MDLL reset code for
> > r300, plus a couple of other things.
> >
> > http://gate.crashing.org/~benh/albook-ibookg4-sleep-4.diff
>
> Works great now (15" 1.5GHz PB).
>
> Many thanks!
>
>
>
>
> --
> To UNSUBSCRIBE, email to debian-powerpc-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
--
Keith Conger
keith DOT conger AT gmail DOT com
http://pimpstation.org
^ permalink raw reply
* Re: TEST: Sleep patch #4
From: Keith Conger @ 2004-11-22 16:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt, debian-powerpc@lists.debian.org,
linuxppc-dev list
In-Reply-To: <4517b8e04112208383cc9b24c@mail.gmail.com>
Hi,
Two things I forgot to include, the sound problem happens with or
without going to sleep. Also here is something that apears in my
dmesg:
Oops: kernel access of bad area, sig: 11 [#3]
PREEMPT
NIP: D22FB074 LR: D22FB8C0 SP: C548FDB0 REGS: c548fd00 TRAP: 0300
Not taintedMSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: D23032A4, DSISR: 40000000
TASK = cfe60c90[10505] 'gst-launch-0.8' THREAD: c548e000Last syscall: 4
GPR00: 000007FC C548FDB0 CFE60C90 CDE724A0 C0BA6AA0 C0BA6580 00000200 00000B03
GPR08: C0BA6AE8 D2302AA8 000007FC D2302AE8 CDE72244 1001C6C4 00000014 10021340
GPR16: 00000003 100213F8 00000000 10021340 3007502C 00001000 1002D028 00000000
GPR24: 00000000 00000000 C07579A0 00000000 C0BA6AA0 CDE72510 CDE724A0 00000200
NIP [d22fb074] resample_expand+0x44/0x35c [snd_pcm_oss]
LR [d22fb8c0] rate_transfer+0x80/0x88 [snd_pcm_oss]
Call trace:
[d22fb8c0] rate_transfer+0x80/0x88 [snd_pcm_oss]
[d22f8798] snd_pcm_plug_write_transfer+0xd4/0x14c [snd_pcm_oss]
[d22f3520] snd_pcm_oss_write2+0xb0/0x128 [snd_pcm_oss]
[d22f3774] snd_pcm_oss_write1+0x1dc/0x20c [snd_pcm_oss]
[d22f6180] snd_pcm_oss_write+0x64/0xb4 [snd_pcm_oss]
[c0069c44] vfs_write+0xdc/0x158
[c0069da4] sys_write+0x50/0x94
[c0007e30] ret_from_syscall+0x0/0x4c
adt746x: Setting speed to: 128 for CPU fan.
adt746x: Stopping CPU fan.
adt746x: Setting speed to: 0 for CPU fan.
adt746x: Setting speed to: 128 for CPU fan.
Oops: kernel access of bad area, sig: 11 [#4]
PREEMPT
NIP: D22FB074 LR: D22FB8C0 SP: C5C33DB0 REGS: c5c33d00 TRAP: 0300
Not taintedMSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: D23032A4, DSISR: 40000000
TASK = c78cac90[10759] 'gst-launch-0.8' THREAD: c5c32000Last syscall: 4
GPR00: 000007FC C5C33DB0 C78CAC90 CDE724A0 CF2D97C0 CFFD7BA0 00000200 00000B03
GPR08: C0BA6A88 D2302AA8 000007FC D2302AE8 CDE72844 1001C6C4 00000014 10021340
GPR16: 00000003 100213F8 00000000 10021340 3007502C 00001000 1002D028 00000000
GPR24: 00000000 00000000 C07579A0 00000000 CF2D97C0 CDE72510 CDE724A0 00000200
NIP [d22fb074] resample_expand+0x44/0x35c [snd_pcm_oss]
LR [d22fb8c0] rate_transfer+0x80/0x88 [snd_pcm_oss]
Call trace:
[d22fb8c0] rate_transfer+0x80/0x88 [snd_pcm_oss]
[d22f8798] snd_pcm_plug_write_transfer+0xd4/0x14c [snd_pcm_oss]
[d22f3520] snd_pcm_oss_write2+0xb0/0x128 [snd_pcm_oss]
[d22f3774] snd_pcm_oss_write1+0x1dc/0x20c [snd_pcm_oss]
[d22f6180] snd_pcm_oss_write+0x64/0xb4 [snd_pcm_oss]
[c0069c44] vfs_write+0xdc/0x158
[c0069da4] sys_write+0x50/0x94
[c0007e30] ret_from_syscall+0x0/0x4c
On Mon, 22 Nov 2004 11:38:09 -0500, Keith Conger <keith.conger@gmail.com> wrote:
> Hi,
>
> Works great here also (15" 1GHz PB). One issue which may be unrelated
> I have some sound issues. For instance one a sound is played it sounds
> fine but if a sound is played right after its volume is extremely low.
> But with headphones this doesn't occur.
>
> Thanks again for your hard work.
>
> Keith
>
>
>
>
> On Mon, 22 Nov 2004 13:29:44 +0000, Sean Neakums <sneakums@zork.net> wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> >
> > > Ok, here's the 4th iteration of the patch. It includes John Steele
> > > Scott fixes for cpufreq and the sound driver and fixes a problem
> > > where memory refresh wouldn't properly be re-enabled on the video
> > > chip upon wakeup. I also cleaned a bit more the MDLL reset code for
> > > r300, plus a couple of other things.
> > >
> > > http://gate.crashing.org/~benh/albook-ibookg4-sleep-4.diff
> >
> > Works great now (15" 1.5GHz PB).
> >
> > Many thanks!
> >
> >
> >
> >
> > --
> > To UNSUBSCRIBE, email to debian-powerpc-REQUEST@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> >
> >
>
>
> --
> Keith Conger
> keith DOT conger AT gmail DOT com
> http://pimpstation.org
>
--
Keith Conger
keith DOT conger AT gmail DOT com
http://pimpstation.org
^ permalink raw reply
* Re: TEST: Sleep patch #4
From: Michael Schmitz @ 2004-11-22 17:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, gentoo-ppc-user,
debian-powerpc@lists.debian.org
In-Reply-To: <1101083578.13597.5.camel@gaston>
> Ok, here's the 4th iteration of the patch. It includes John Steele Scott fixes for
> cpufreq and the sound driver and fixes a problem where memory refresh wouldn't properly
> be re-enabled on the video chip upon wakeup. I also cleaned a bit more the MDLL reset
> code for r300, plus a couple of other things.
>
> http://gate.crashing.org/~benh/albook-ibookg4-sleep-4.diff
Sorry for coming late to the party ... the current code works nicely on
the 17" PB. On the first boot with that code, I had the PLL freak out (or
so it looked like) but I couldn't reproduce that. Needless to say, the
new PLL fixup code produces the same dividers as the hardcoded fixup
before, so it should work :-)
Michael
^ permalink raw reply
* Re: TEST: Sleep patch #4
From: Sean Neakums @ 2004-11-22 18:36 UTC (permalink / raw)
To: Keith Conger
Cc: gentoo-ppc-user, debian-powerpc@lists.debian.org,
linuxppc-dev list
In-Reply-To: <4517b8e04112208383cc9b24c@mail.gmail.com>
Keith Conger <keith.conger@gmail.com> writes:
> Works great here also (15" 1GHz PB). One issue which may be unrelated
> I have some sound issues. For instance one a sound is played it sounds
> fine but if a sound is played right after its volume is extremely low.
> But with headphones this doesn't occur.
I have a similar problem post-resume -- sound from the speakers is
very quiet (although it seems to be louder at the very beginning) and
I had to plug and re-plug the headphones to get sound from them. I
tried unloading and reloading snd_powermac, to no avail.
^ permalink raw reply
* Re: [PATCH][PPC32] Marvell host bridge support (mv64x60)
From: Mark A. Greer @ 2004-11-22 18:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <20041119155854.02af2174.akpm@osdl.org>
Andrew Morton wrote:
>"Mark A. Greer" <mgreer@mvista.com> wrote:
>
>
>>This patch adds core support for a line of host bridges from Marvell
>>(formerly Galileo). This code has been tested with a GT64260a,
>>GT64260b, MV64360, and MV64460. Patches for platforms that use these
>>bridges will be sent separately.
>>
>>
>>
>
>Shouldn't these guys:
>
>
>+ u32 cpu2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = {
>+ { MV64x60_CPU2MEM_0_BASE, MV64x60_CPU2MEM_0_SIZE },
>+ { MV64x60_CPU2MEM_1_BASE, MV64x60_CPU2MEM_1_SIZE },
>+ { MV64x60_CPU2MEM_2_BASE, MV64x60_CPU2MEM_2_SIZE },
>+ { MV64x60_CPU2MEM_3_BASE, MV64x60_CPU2MEM_3_SIZE }
>+ };
>+ u32 com2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = {
>+ { MV64360_MPSC2MEM_0_BASE, MV64360_MPSC2MEM_0_SIZE },
>+ { MV64360_MPSC2MEM_1_BASE, MV64360_MPSC2MEM_1_SIZE },
>+ { MV64360_MPSC2MEM_2_BASE, MV64360_MPSC2MEM_2_SIZE },
>+ { MV64360_MPSC2MEM_3_BASE, MV64360_MPSC2MEM_3_SIZE }
>+ };
>+ u32 dram_selects[MV64x60_CPU2MEM_WINDOWS] = { 0xe, 0xd, 0xb, 0x7 };
>
>be static, and maybe __devinitdata? Right now, the CPU has to populate
>them by hand at runtime.
>
Yes. I'll fix that.
>
>+wait_for_ownership(int chan)
>+{
>+ int i;
>+
>+ for (i=0; i<MAX_TX_WAIT; i++) {
>+ if ((MV64x60_REG_READ(sdma_regs[chan].sdcm) &
>+ SDMA_SDCM_TXD) == 0)
>+ break;
>+
>+ udelay(1000);
>
>ow, big busywait. Can't use a sleep in here? I guess not :(
>
This code is in the ppc bootwrapper which is glue code to get the
hardware (and bd_info, etc.) from whatever state the f/w left it in into
something the kernel can work with. IOW, its not in the kernel and
there is no sleep mechanism...or even a thread/process entity to put to
sleep.
>+ * arch/ppc/boot/simple/mv64x60_tty.c
>
>hm. Normally we put arch-specific drivers like this into drivers/serial
>and do the appropriate Kconfig work. Is there a reason why this serial
>driver is buried under arch/ppc?
>
It isn't a part of the kernel so I don't think it belongs in
drivers/serial. This particular serial driver is required for cmd_line
editing when booting a zImage.
>+#include "../../../../drivers/serial/mpsc_defs.h"
>
>erk.
>
Ah, yeah, I'll fix that too :)
>
>+struct mv64x60_rx_desc {
>+ volatile u16 bufsize;
>+ volatile u16 bytecnt;
>+ volatile u32 cmd_stat;
>+ volatile u32 next_desc_ptr;
>+ volatile u32 buffer;
>+};
>+
>+struct mv64x60_tx_desc {
>+ volatile u16 bytecnt;
>+ volatile u16 shadow;
>+ volatile u32 cmd_stat;
>+ volatile u32 next_desc_ptr;
>+ volatile u32 buffer;
>+};
>
>Do these need to be volatile? If so, it indicates that the driver is doing
>something wrong.
>
I didn't spend much time looking at this code. I'll clean it up.
>
>+gt64260_register_hdlrs(void)
>+{
>+ /* Register CPU interface error interrupt handler */
>+ request_irq(MV64x60_IRQ_CPU_ERR, gt64260_cpu_error_int_handler,
>+ SA_INTERRUPT, CPU_INTR_STR, 0);
>
>request_irq() can fail.
>
OK.
>+int
>+mv64360_get_irq(struct pt_regs *regs)
>+{
>+ int irq;
>+ int irq_gpp;
>+
>+#ifdef CONFIG_SMP
>+ /*
>+ * Second CPU gets only doorbell (message) interrupts.
>+ * The doorbell interrupt is BIT28 in the main interrupt low cause reg.
>+ */
>+ int cpu_nr = smp_processor_id();
>
>This function has no callers, so I am unable to determine whether it is
>called from non-preemptible code. If it is called from preemptible code
>then that smp_processor_id() is buggy, because you can switch CPUs at any
>time.
>
Its called via ppc_md.get_irq() (see arch/ppc/kernel/irq.c:do_IRQ()).
ppc_md.get_irq is set up in the platform files.
>+static struct platform_device mpsc_shared_device = { /* Shared device */
>+ .name = MPSC_SHARED_NAME,
>+ .id = 0,
>+ .num_resources = ARRAY_SIZE(mv64x60_mpsc_shared_resources),
>+ .resource = mv64x60_mpsc_shared_resources,
>+ .dev = {
>+ .driver_data = (void *)&mv64x60_mpsc_shared_pd_dd,
>+ },
>+};
>
>The cast to void* is unnecessary.
>
OK.
>+ (void)mv64x60_setup_for_chip(&bh);
>
>how come you always stick that (void) in there?
>
I did that b/c the routine returns an 'int' but I'm ignoring it. I
probably shouldn't be ignoring it...
>
>+mv64x60_config_cpu2mem_windows(struct mv64x60_handle *bh,
>+ struct mv64x60_setup_info *si,
>+ u32 mem_windows[MV64x60_CPU2MEM_WINDOWS][2])
>+{
>+ u32 i, win;
>+ u32 prot_tab[] = {
>+ MV64x60_CPU_PROT_0_WIN, MV64x60_CPU_PROT_1_WIN,
>+ MV64x60_CPU_PROT_2_WIN, MV64x60_CPU_PROT_3_WIN
>+ };
>+ u32 cpu_snoop_tab[] = {
>+ MV64x60_CPU_SNOOP_0_WIN, MV64x60_CPU_SNOOP_1_WIN,
>+ MV64x60_CPU_SNOOP_2_WIN, MV64x60_CPU_SNOOP_3_WIN
>+ };
>
>static initialisation?
>
Yep.
>
>+mv64x60_config_cpu2pci_windows(struct mv64x60_handle *bh,
>+ struct mv64x60_pci_info *pi, u32 bus)
>+{
>+ int i;
>+ u32 win_tab[2][4] = {
>+ { MV64x60_CPU2PCI0_IO_WIN, MV64x60_CPU2PCI0_MEM_0_WIN,
>+ MV64x60_CPU2PCI0_MEM_1_WIN,
>+ MV64x60_CPU2PCI0_MEM_2_WIN },
>+ { MV64x60_CPU2PCI1_IO_WIN, MV64x60_CPU2PCI1_MEM_0_WIN,
>+ MV64x60_CPU2PCI1_MEM_1_WIN,
>+ MV64x60_CPU2PCI1_MEM_2_WIN },
>+ };
>+ u32 remap_tab[2][4] = {
>+ { MV64x60_CPU2PCI0_IO_REMAP_WIN,
>+ MV64x60_CPU2PCI0_MEM_0_REMAP_WIN,
>+ MV64x60_CPU2PCI0_MEM_1_REMAP_WIN,
>+ MV64x60_CPU2PCI0_MEM_2_REMAP_WIN },
>+ { MV64x60_CPU2PCI1_IO_REMAP_WIN,
>+ MV64x60_CPU2PCI1_MEM_0_REMAP_WIN,
>+ MV64x60_CPU2PCI1_MEM_1_REMAP_WIN,
>+ MV64x60_CPU2PCI1_MEM_2_REMAP_WIN }
>+ };
>+
>
>ditto
>
>
>+mv64x60_config_pci2mem_windows(struct mv64x60_handle *bh,
>
>and here
>
>+mv64360_set_pci2mem_window(struct pci_controller *hose, u32 bus, u32 window,
>
>and here
>
>+mv64360_config_io2mem_windows(struct mv64x60_handle *bh,
>
>and here
Yes, several times. I'll fix it.
>
>Anyway, I'll stick this as-is in -mm. Feel free to send an incremental
>patch, or a replacement.
>
Thanks for the feedback. I'll clean it up & resend.
Mark
^ permalink raw reply
* Re: [PATCH][PPC32] Marvell host bridge support (mv64x60)
From: Mark A. Greer @ 2004-11-22 18:49 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: akpm, lkml, linuxppc-embedded
In-Reply-To: <20041120162622.GA19099@infradead.org>
Christoph Hellwig wrote:
>Just looking through this and you should share some more code with mips,
>e.g. the mavell register layout should move from asm-mips/marvell.h and
>your file to linux/marvell.h or something, especially as another ppc
>plattform (pegasosII) needs it aswell.
>
Yes, and there is already include/linux/mv643xx.h that has a bunch of
64340 definitions which share offset with the 64360 (and some with the
64260). However, to be correct, there needs to be a lot of munging.
mv643xx.h should be renamed to mv64xxx.h and all of the MV64340 macros
need to be renamed as well. This ripples into the mips code which I
didn't want to battle with right now. I would prefer that this patch go
in and then submit a separate patch that fixes and combines the hdr
files & macros they contain. Doing it that way, there is one patch for
the ppc bridge support and one patch for the hdr file clean up. That's
cleaner than mixing the two (IMHO). It is on the todo list.
Mark
^ permalink raw reply
* MPC5200 target name
From: Ratin Kumar @ 2004-11-22 19:27 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 22 bytes --]
Is this -mppc=82xx??
[-- Attachment #2: Type: text/html, Size: 390 bytes --]
^ permalink raw reply
* (no subject)
From: Ratin Kumar @ 2004-11-22 19:23 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
Hi,
I am trying to build a toolchain for MPC5200 using gcc 3.4.1.
The bootstrap compiler build fails with a complain that it could not
locate "signal.h". This happens even though I have the kernel headers
(with signal.h) installed. A quick search on google shows that some
other people have also run into this issue, although no patches/sloution
appears. Any ideas??
Also, has anyone tried using 3.4.1 compiler for kernel 2.4.23 ????
What are the matching glibc and binutils to use with 3.4.1?? Any
patches??
Thanks,
Rk.
[-- Attachment #2: Type: text/html, Size: 1144 bytes --]
^ permalink raw reply
* compiling ELDK3 microwindows source paket
From: Dieter Wirtz @ 2004-11-22 19:38 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I want to rebuild the ELDK3 (www.denx.de) microwindows source paket
(host system: i386 pc running SUSE 9.0; target system: embedded ppc405;
CROSS_COMPILE=ppc_4xx-).
For it I installed the source in the ELDK3 directory and tried to
rebuild the paket with ${CROSS_COMPILE}rpmbuild -ba microwindows.spec.
This gave some errors because the host and not the cross compiler was used.
After I changed the file microwindows-0.90-config.ppc.patch from
...
-POWERPCTOOLSPREFIX = powerpc-linux-
+POWERPCTOOLSPREFIX =
SHTOOLSPREFIX = sh-linux-gnu
...
to
...
-POWERPCTOOLSPREFIX = powerpc-linux-
+POWERPCTOOLSPREFIX = ppc_4xx-
SHTOOLSPREFIX = sh-linux-gnu
...
the command make use of the cross tools.
Now it rebuild the rpm paket but the strip command gives the warning:
strip: Warning: Output file cannot represent architecture UNKNOWN!
and the programms are not executable (on the ppc405 board) after
installing the rpm paket.
What can it be?
Regards,
Dieter
Here an extract from the build process:
wi@wi2:~/PPC/ELDK3/usr/src/denx/SPECS> ${CROSS_COMPILE}rpmbuild -ba
microwindows.spec
Executing(%prep): /bin/sh -e /home/wi/PPC/ELDK3/var/tmp/rpm-tmp.50044
+ umask 022
+ cd /home/wi/PPC/ELDK3/usr/src/denx/BUILD
+ cd /home/wi/PPC/ELDK3/usr/src/denx/BUILD
+ rm -rf microwindows-0.90
+ /bin/gzip -dc
/home/wi/PPC/ELDK3/usr/src/denx/SOURCES/microwindows-0.90.tar.gz
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd microwindows-0.90
+ echo 'Patch #0 (microwindows-0.90-noroot.patch):'
Patch #0 (microwindows-0.90-noroot.patch):
+ patch -p1 -s
+ echo 'Patch #1 (microwindows-0.90-bugfix.ppc.patch):'
Patch #1 (microwindows-0.90-bugfix.ppc.patch):
+ patch -p1 -s
+ echo 'Patch #2 (microwindows-0.90-config.ppc.patch):'
Patch #2 (microwindows-0.90-config.ppc.patch):
+ patch -p1 -s
+ echo 'Patch #3 (microwindows-0.90_thick_lines.patch):'
Patch #3 (microwindows-0.90_thick_lines.patch):
+ patch -p1 -s
+ echo 'Patch #4 (microwindows-0.90-stretch.patch):'
Patch #4 (microwindows-0.90-stretch.patch):
+ patch -p1 -s
+ echo 'Patch #5 (microwindows-0.90-tsc2000.patch):'
Patch #5 (microwindows-0.90-tsc2000.patch):
+ patch -p1 -s
+ echo 'Patch #6 (microwindows-0.90-config-fonts.patch):'
Patch #6 (microwindows-0.90-config-fonts.patch):
+ patch -p1 -s
+ echo 'Patch #7 (microwindows-0.90-mtest-fix.patch):'
Patch #7 (microwindows-0.90-mtest-fix.patch):
+ patch -p1 -s
+ exit 0
Executing(%build): /bin/sh -e /home/wi/PPC/ELDK3/var/tmp/rpm-tmp.89079
+ umask 022
+ cd /home/wi/PPC/ELDK3/usr/src/denx/BUILD
+ cd microwindows-0.90
+ cd src
+ HOSTCC=/usr/bin/gcc -B/usr/bin/
+ make -e
make -C drivers
make[1]: Entering directory
`/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/drivers'
Updating dependencies in
/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/drivers ...
/bin/sh -ec '/usr/bin/gcc -B/usr/bin/ -MM
-DMWPIXEL_FORMAT=MWPF_TRUECOLOR565 -DVTSWITCH=1 -DHAVE_FILEIO
-DHAVE_FNT_SUPPORT=1 -DFNT_FONT_DIR="\""/usr/microwindows-fonts/bdf""\"
-DHAVE_PCF_SUPPORT=1 -DPCF_FONT_DIR="\""/usr/microwindows-fonts/pcf""\"
-DHAVE_HZK_SUPPORT=1
-DHZK_FONT_DIR="\""/usr/microwindows-fonts/chinese""\"
-DHAVE_EUCJP_SUPPORT=1
-DEUCJP_FONT_DIR=\""/usr/microwindows-fonts/japanese"\"
-DHAVE_BMP_SUPPORT=1 -DHAVE_GIF_SUPPORT=1 -DHAVE_PNM_SUPPORT=1
-DHAVE_XPM_SUPPORT=1 -DHAVETEXTMODE=1 -DTHREADSAFE=1 -DERASEMOVE=1
-DUPDATEREGIONS=1 -DDEBUG=1 -DLINUX=1 -DUNIX=1 -DARCH_LINUX_POWERPPC=1
-DMW_CPU_BIG_ENDIAN=1 -I.
-I/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/include
fblin8.c fblin16.c fblin24.c fblin32.c fblin32alpha.c genmem.c fb.c
fblin1.c fblin2.c genfont.c scr_fb.c fbportrait_left.c
fbportrait_right.c fbportrait_down.c fblin4.c vtswitch.c mou_ser.c
kbd_tty.c \
| sed '\''s/\(\)\.o[ :]*/\1.o \.depend : $(TOP)\/config /g'\'' > .depend; \
[ -s .depend ] || rm -f .depend'
make[1]: Leaving directory
`/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/drivers'
make[1]: Entering directory
`/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/drivers'
Compiling fblin8.c ...
ppc_4xx-gcc -c -DMWPIXEL_FORMAT=MWPF_TRUECOLOR565 -DVTSWITCH=1
-DHAVE_FILEIO -DHAVE_FNT_SUPPORT=1
-DFNT_FONT_DIR="\""/usr/microwindows-fonts/bdf""\" -DHAVE_PCF_SUPPORT=1
-DPCF_FONT_DIR="\""/usr/microwindows-fonts/pcf""\" -DHAVE_HZK_SUPPORT=1
-DHZK_FONT_DIR="\""/usr/microwindows-fonts/chinese""\"
-DHAVE_EUCJP_SUPPORT=1
-DEUCJP_FONT_DIR=\""/usr/microwindows-fonts/japanese"\"
-DHAVE_BMP_SUPPORT=1 -DHAVE_GIF_SUPPORT=1 -DHAVE_PNM_SUPPORT=1
-DHAVE_XPM_SUPPORT=1 -DHAVETEXTMODE=1 -DTHREADSAFE=1 -DERASEMOVE=1
-DUPDATEREGIONS=1 -DDEBUG=1 -DLINUX=1 -DUNIX=1 -DARCH_LINUX_POWERPPC=1
-DMW_CPU_BIG_ENDIAN=1 -fpic -I.
-I/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/include
-msoft-float -Wall -Wpointer-arith -O3 -ggdb -o fblin8.o fblin8.c
Compiling fblin16.c ...
...
Compiling nanox.c ...
ppc_4xx-gcc -c -DNANOX=1 -DMWPIXEL_FORMAT=MWPF_TRUECOLOR565
-DVTSWITCH=1 -DHAVE_FILEIO -DHAVE_FNT_SUPPORT=1
-DFNT_FONT_DIR="\""/usr/microwindows-fonts/bdf""\" -DHAVE_PCF_SUPPORT=1
-DPCF_FONT_DIR="\""/usr/microwindows-fonts/pcf""\" -DHAVE_HZK_SUPPORT=1
-DHZK_FONT_DIR="\""/usr/microwindows-fonts/chinese""\"
-DHAVE_EUCJP_SUPPORT=1
-DEUCJP_FONT_DIR=\""/usr/microwindows-fonts/japanese"\"
-DHAVE_BMP_SUPPORT=1 -DHAVE_GIF_SUPPORT=1 -DHAVE_PNM_SUPPORT=1
-DHAVE_XPM_SUPPORT=1 -DHAVETEXTMODE=1 -DTHREADSAFE=1 -DERASEMOVE=1
-DUPDATEREGIONS=1 -DDEBUG=1 -DLINUX=1 -DUNIX=1
-DARCH_LINUX_POWERPPC=1-DMW_CPU_BIG_ENDIAN=1 -fpic -I../include -I.
-I/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/include
-msoft-float -Wall -Wpointer-arith -O3 -ggdb -o nanox.o nanox.c
ppc_4xx-gcc -fpic -I../include -I.
-I/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/include
-msoft-float -Wall -Wpointer-arith -O3 -ggdb
-L/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/lib
args.o rfbproto.o sockets.o vncviewer.o nanox.o -o
/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/bin/vnc
/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/lib/libnano-X.a
/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/lib/libvncauth.a
make[3]: Leaving directory
`/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/demos/vnc/vncviewer'
make[2]: Zirkuläre Datei
/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/lib/ <-
/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/lib/
Abhängigkeit wird nicht verwendet.
make[2]: Leaving directory
`/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/demos/vnc'
make[1]: Zirkuläre Datei
/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/lib/ <-
/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/lib/
Abhängigkeit wird nicht verwendet.
make[1]: Leaving directory
`/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/demos'
+ exit 0
Executing(%install): /bin/sh -e /home/wi/PPC/ELDK3/var/tmp/rpm-tmp.69817
+ umask 022
+ cd /home/wi/PPC/ELDK3/usr/src/denx/BUILD
+ cd microwindows-0.90
+ cd src
+ rm -rf -- /home/wi/PPC/ELDK3/var/tmp/microwindows-0.90-root
+ mkdir -p -- /home/wi/PPC/ELDK3/var/tmp/microwindows-0.90-root/usr/bin
+ make
INSTALL_PREFIX=/home/wi/PPC/ELDK3/var/tmp/microwindows-0.90-root/usr install
make -C drivers
make[1]: Entering directory
`/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/drivers'
make[1]: Leaving directory
`/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/drivers'
make -C mwin
...
make -C nanox
make[1]: Entering directory
`/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/nanox'
make[1]: Leaving directory
`/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/nanox'
make: Zirkuläre Datei
/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/lib/ <-
/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/lib/
Abhängigkeit wird nicht verwendet.
install -c -m 755 -d
/home/wi/PPC/ELDK3/var/tmp/microwindows-0.90-root/usr/include/microwin
echo "Copying hdrs to
/home/wi/PPC/ELDK3/var/tmp/microwindows-0.90-root/usr/include/microwin"
Copying hdrs to
/home/wi/PPC/ELDK3/var/tmp/microwindows-0.90-root/usr/include/microwin
install -c -m 644 include/*.h
/home/wi/PPC/ELDK3/var/tmp/microwindows-0.90-root/usr/include/microwin
echo "Copying libs to
/home/wi/PPC/ELDK3/var/tmp/microwindows-0.90-root/usr/lib"
Copying libs to /home/wi/PPC/ELDK3/var/tmp/microwindows-0.90-root/usr/lib
install -c -m 755 -d
/home/wi/PPC/ELDK3/var/tmp/microwindows-0.90-root/usr/lib
install -c -m 644 -s lib/*.a
/home/wi/PPC/ELDK3/var/tmp/microwindows-0.90-root/usr/lib
strip: Warning: Output file cannot represent architecture UNKNOWN!
strip: Warning: Output file cannot represent architecture UNKNOWN!
strip: Warning: Output file cannot represent architecture UNKNOWN!
...
ppc-linux-strip: Warning: Output file cannot represent architecture UNKNOWN!
ppc-linux-strip: Warning: Output file cannot represent architecture UNKNOWN!
Processing files: microwindows-0.90-2
Finding Provides: /home/wi/PPC/ELDK3/usr/lib/rpm/find-provides
Finding Requires: /home/wi/PPC/ELDK3/usr/lib/rpm/find-requires
Provides: libmwimages.so libmwinlib.so libmwin.so libnano-X.so
Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
Requires: libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.3) libm.so.6 libmwimages.so libmwinlib.so libmwin.so
libnano-X.so
Checking for unpackaged file(s):
/home/wi/PPC/ELDK3/usr/lib/rpm/check-files
/home/wi/PPC/ELDK3/var/tmp/microwindows-0.90-root
Wrote: /home/wi/PPC/ELDK3/usr/src/denx/SRPMS/microwindows-0.90-2.src.rpm
Wrote:
/home/wi/PPC/ELDK3/usr/src/denx/RPMS/ppc/microwindows-ppc_4xx-0.90-2.ppc.rpm
Executing(%clean): /bin/sh -e /home/wi/PPC/ELDK3/var/tmp/rpm-tmp.10309
+ umask 022
+ cd /home/wi/PPC/ELDK3/usr/src/denx/BUILD
+ cd microwindows-0.90
+ rm -rf /home/wi/PPC/ELDK3/var/tmp/microwindows-0.90-root
+ exit 0
^ permalink raw reply
* Re: MPC82xx -- DPRAM1
From: Dan Malek @ 2004-11-22 19:54 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B06DBC9@ismail.innsys.innovsys.com>
On Nov 19, 2004, at 9:25 AM, Rune Torgersen wrote:
> Send a patch to fix this in the driver. I think most people on this
> list
> would like the seriaql drivers to be totally independent of the
> bootloader (no matter what it is).
The serial driver is totally independent of the bootloader.
It configures the SMC from scratch and assumes nothing of
the bootloader. However, if the bootloader configures itself
as Linux does, then other functions like early kgdb over
serial port work properly.
-- Dan
^ permalink raw reply
* Re: TEST: Sleep patch #4
From: Michel Dänzer @ 2004-11-22 21:13 UTC (permalink / raw)
To: Keith Conger
Cc: gentoo-ppc-user, debian-powerpc@lists.debian.org,
linuxppc-dev list
In-Reply-To: <4517b8e04112208383cc9b24c@mail.gmail.com>
On Mon, 2004-11-22 at 11:38 -0500, Keith Conger wrote:
>=20
> Works great here also (15" 1GHz PB). One issue which may be unrelated
> I have some sound issues. For instance one a sound is played it sounds
> fine but if a sound is played right after its volume is extremely low.
> But with headphones this doesn't occur.
Make sure that DRC is disabled or that it's set up to operate on a
reasonable (i.e. non-empty :) range.
--=20
Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop=
er
Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer
^ permalink raw reply
* Re: TEST: Sleep patch #4
From: Benjamin Herrenschmidt @ 2004-11-22 21:48 UTC (permalink / raw)
To: Keith Conger
Cc: linuxppc-dev list, gentoo-ppc-user,
debian-powerpc@lists.debian.org
In-Reply-To: <4517b8e04112208383cc9b24c@mail.gmail.com>
On Mon, 2004-11-22 at 11:38 -0500, Keith Conger wrote:
> Hi,
>
> Works great here also (15" 1GHz PB). One issue which may be unrelated
> I have some sound issues. For instance one a sound is played it sounds
> fine but if a sound is played right after its volume is extremely low.
> But with headphones this doesn't occur.
That's problems with the sound drivers...
Ben.
^ permalink raw reply
* Re: TEST: Sleep patch #4
From: Benjamin Herrenschmidt @ 2004-11-22 21:48 UTC (permalink / raw)
To: Keith Conger; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <4517b8e0411220858256619b4@mail.gmail.com>
On Mon, 2004-11-22 at 11:58 -0500, Keith Conger wrote:
> Hi,
>
> Two things I forgot to include, the sound problem happens with or
> without going to sleep. Also here is something that apears in my
> dmesg:
> Oops: kernel access of bad area, sig: 11 [#3]
> PREEMPT
>
> .../...
Alsa bugs (as well). You should probably report this to the proper
driver author/maintainer.
Ben.
^ permalink raw reply
* Re: TEST: Sleep patch #4
From: Benjamin Herrenschmidt @ 2004-11-22 21:50 UTC (permalink / raw)
To: Michael Schmitz
Cc: linuxppc-dev list, gentoo-ppc-user,
debian-powerpc@lists.debian.org
In-Reply-To: <Pine.LNX.4.44.0411221758220.2076-100000@zirkon.biophys.uni-duesseldorf.de>
On Mon, 2004-11-22 at 18:04 +0100, Michael Schmitz wrote:
> > Ok, here's the 4th iteration of the patch. It includes John Steele Scott fixes for
> > cpufreq and the sound driver and fixes a problem where memory refresh wouldn't properly
> > be re-enabled on the video chip upon wakeup. I also cleaned a bit more the MDLL reset
> > code for r300, plus a couple of other things.
> >
> > http://gate.crashing.org/~benh/albook-ibookg4-sleep-4.diff
>
> Sorry for coming late to the party ... the current code works nicely on
> the 17" PB. On the first boot with that code, I had the PLL freak out (or
> so it looked like) but I couldn't reproduce that. Needless to say, the
> new PLL fixup code produces the same dividers as the hardcoded fixup
> before, so it should work :-)
It reads them from OF at boot. What do you mean by "freak out" ? the
usual problem with those models where the display gets all fuzzy ? I'm
not completely sure what's up, I tend to blame the panel power sequence
nowadays ...
Ben.
^ permalink raw reply
* Re: TEST: Sleep patch #4
From: Benjamin Herrenschmidt @ 2004-11-22 21:52 UTC (permalink / raw)
To: Sean Neakums
Cc: linuxppc-dev list, Keith Conger, debian-powerpc@lists.debian.org,
gentoo-ppc-user
In-Reply-To: <6uzn19g299.fsf@zork.zork.net>
On Mon, 2004-11-22 at 18:36 +0000, Sean Neakums wrote:
> Keith Conger <keith.conger@gmail.com> writes:
>
> > Works great here also (15" 1GHz PB). One issue which may be unrelated
> > I have some sound issues. For instance one a sound is played it sounds
> > fine but if a sound is played right after its volume is extremely low.
> > But with headphones this doesn't occur.
>
> I have a similar problem post-resume -- sound from the speakers is
> very quiet (although it seems to be louder at the very beginning) and
> I had to plug and re-plug the headphones to get sound from them. I
> tried unloading and reloading snd_powermac, to no avail.
Tried playing with the DRC setting in Alsa mixer ?
Ben.
^ permalink raw reply
* Re: Test patch for sleep on Aluminium PowerBooks
From: Benjamin Herrenschmidt @ 2004-11-22 22:20 UTC (permalink / raw)
To: Armando Di Cianno; +Cc: linuxppc-dev list
In-Reply-To: <fc01eab7ddb069d0da7030a94b467f8f@nephilim.localdomain>
> Does this patch do, or should have to do, anything special to
> "normalize" the mounted filesystems before sleep? When I patched the
> kernel first, I was running XFS, and of course that is notorious for
> file corruptions with power abnormalities on a system. I started to
> get really odd file corruptions, where 'ls file' would should the
> file, but 'ls -l file' would not.
I though xfs was supposed to be journaled ? Yes, the sleep code will
sync all disks before sleep. You should update to patch #4 though, there
have been number of problems fixes since then.
> I switched to ReiserFS (v3) now, and have seen symptoms like this
> problem caused appear once more (but not to the extent that XFS showed
> [where I thought my system was disintegrating before my eyes]).
Hrm... reiserfs is evil, ask any sane kernel hacker :) Why not ext3 ?
> Is there something that was overlooked in the patch, or something that
> I'm overlooking that needs to be done?
>
> If filesystems do not need to be "normalized" at sleep, what
> filesystems are known to work? (Hesistant about ext3, as it's quite
> slow, imho, but I'll go that route if needed, I suppose).
It's not that slow ...
Ben.
^ permalink raw reply
* Re: Test patch for sleep on Aluminium PowerBooks
From: Colin Leroy @ 2004-11-22 22:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1101162053.13597.136.camel@gaston>
On 23 Nov 2004 at 09h11, Benjamin Herrenschmidt wrote:
Hi,
> > If filesystems do not need to be "normalized" at sleep, what
> > filesystems are known to work? (Hesistant about ext3, as it's quite
> > slow, imho, but I'll go that route if needed, I suppose).
>
> It's not that slow ...
It also has the advantages of being natively big-endian, giving us ppc
users a bit more speed :)
--
\|/ ____ \|/ Colin
"@'/ ,. \`@" http://www.geekounet.org/
/_| \__/ |_\
\__U_/
^ permalink raw reply
* Re: (no subject)
From: Kumar Gala @ 2004-11-22 22:53 UTC (permalink / raw)
To: Ratin Kumar; +Cc: linuxppc-embedded
In-Reply-To: <8E5ACAE05E6B9E44A2903C693A5D4E8A023EC8C0@hqemmail02.nvidia.com>
Ratin,
I would suggest looking at Dan Kegel's crosstool @
http://www.kegel.com/crosstool/. Very helpful in pairing various parts
of the GNU toolchain together to get a working version. For MPC5200
you want the ppc750 build.
- kumar
On Nov 22, 2004, at 1:23 PM, Ratin Kumar wrote:
> Hi,
>
> I am trying to build a toolchain for MPC5200 using gcc 3.4.1.
>
> The bootstrap compiler build fails with a complain that it could not
> locate "signal.h". This happens even though I have the kernel headers
> (with signal.h) installed. A quick search on google shows that some
> other people have also run into this issue, although no
> patches/sloution appears. Any ideas??
>
> Also, has anyone tried using 3.4.1 compiler for kernel 2.4.23 ????
>
> What are the matching glibc and binutils to use with 3.4.1?? Any
> patches??
>
> Thanks,
> Rk.
> <ATT949193.txt>
^ permalink raw reply
* Re: compiling ELDK3 microwindows source paket
From: Wolfgang Denk @ 2004-11-22 22:26 UTC (permalink / raw)
To: Dieter Wirtz; +Cc: linuxppc-embedded
In-Reply-To: <41A24026.5070908@gmx.net>
In message <41A24026.5070908@gmx.net> you wrote:
>
> I want to rebuild the ELDK3 (www.denx.de) microwindows source paket
> (host system: i386 pc running SUSE 9.0; target system: embedded ppc405;
> CROSS_COMPILE=ppc_4xx-).
>
> For it I installed the source in the ELDK3 directory and tried to
> rebuild the paket with ${CROSS_COMPILE}rpmbuild -ba microwindows.spec.
> This gave some errors because the host and not the cross compiler was used.
There is a detailed description how to do this inthe ELDK manual;
please see
http://www.denx.de/twiki/bin/view/DULG/ELDKRebuildingComponents#Section_3.7.2.
Please pay special attention to the two requirements shown at the end
of this paragraph.
> After I changed the file microwindows-0.90-config.ppc.patch from
Don't do this, it will break the build.
> What can it be?
User error. Please RTFM.
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
"There's only one kind of woman ..." "Or man, for that matter. You
either believe in yourself or you don't."
-- Kirk and Harry Mudd, "Mudd's Women", stardate 1330.1
^ permalink raw reply
* Re: [PATCH][PPC32] Marvell host bridge support (mv64x60)
From: Mark A. Greer @ 2004-11-23 0:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <20041119155854.02af2174.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
Andrew Morton wrote:
>Anyway, I'll stick this as-is in -mm. Feel free to send an incremental
>patch, or a replacement.
>
Here is an incremental patch [hopefully] with your concerns addressed.
Note that the arch/ppc/boot code is not kernel code and only exists for
a short period of time before execution jumps to the kernel. Please let
me know if you have any more concerns.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
--
[-- Attachment #2: mv64x60_2.patch --]
[-- Type: text/plain, Size: 23135 bytes --]
diff -Nru a/arch/ppc/boot/include/mpsc_defs.h b/arch/ppc/boot/include/mpsc_defs.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/boot/include/mpsc_defs.h 2004-11-22 17:03:43 -07:00
@@ -0,0 +1,146 @@
+/*
+ * drivers/serial/mpsc/mpsc_defs.h
+ *
+ * Register definitions for the Marvell Multi-Protocol Serial Controller (MPSC),
+ * Serial DMA Controller (SDMA), and Baud Rate Generator (BRG).
+ *
+ * Author: Mark A. Greer <mgreer@mvista.com>
+ *
+ * 2004 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#ifndef _PPC_BOOT_MPSC_DEFS_H__
+#define _PPC_BOOT_MPSC_DEFS_H__
+
+#define MPSC_NUM_CTLRS 2
+
+/*
+ *****************************************************************************
+ *
+ * Multi-Protocol Serial Controller Interface Registers
+ *
+ *****************************************************************************
+ */
+
+/* Main Configuratino Register Offsets */
+#define MPSC_MMCRL 0x0000
+#define MPSC_MMCRH 0x0004
+#define MPSC_MPCR 0x0008
+#define MPSC_CHR_1 0x000c
+#define MPSC_CHR_2 0x0010
+#define MPSC_CHR_3 0x0014
+#define MPSC_CHR_4 0x0018
+#define MPSC_CHR_5 0x001c
+#define MPSC_CHR_6 0x0020
+#define MPSC_CHR_7 0x0024
+#define MPSC_CHR_8 0x0028
+#define MPSC_CHR_9 0x002c
+#define MPSC_CHR_10 0x0030
+#define MPSC_CHR_11 0x0034
+
+#define MPSC_MPCR_CL_5 0
+#define MPSC_MPCR_CL_6 1
+#define MPSC_MPCR_CL_7 2
+#define MPSC_MPCR_CL_8 3
+#define MPSC_MPCR_SBL_1 0
+#define MPSC_MPCR_SBL_2 3
+
+#define MPSC_CHR_2_TEV (1<<1)
+#define MPSC_CHR_2_TA (1<<7)
+#define MPSC_CHR_2_TTCS (1<<9)
+#define MPSC_CHR_2_REV (1<<17)
+#define MPSC_CHR_2_RA (1<<23)
+#define MPSC_CHR_2_CRD (1<<25)
+#define MPSC_CHR_2_EH (1<<31)
+#define MPSC_CHR_2_PAR_ODD 0
+#define MPSC_CHR_2_PAR_SPACE 1
+#define MPSC_CHR_2_PAR_EVEN 2
+#define MPSC_CHR_2_PAR_MARK 3
+
+/* MPSC Signal Routing */
+#define MPSC_MRR 0x0000
+#define MPSC_RCRR 0x0004
+#define MPSC_TCRR 0x0008
+
+/*
+ *****************************************************************************
+ *
+ * Serial DMA Controller Interface Registers
+ *
+ *****************************************************************************
+ */
+
+#define SDMA_SDC 0x0000
+#define SDMA_SDCM 0x0008
+#define SDMA_RX_DESC 0x0800
+#define SDMA_RX_BUF_PTR 0x0808
+#define SDMA_SCRDP 0x0810
+#define SDMA_TX_DESC 0x0c00
+#define SDMA_SCTDP 0x0c10
+#define SDMA_SFTDP 0x0c14
+
+#define SDMA_DESC_CMDSTAT_PE (1<<0)
+#define SDMA_DESC_CMDSTAT_CDL (1<<1)
+#define SDMA_DESC_CMDSTAT_FR (1<<3)
+#define SDMA_DESC_CMDSTAT_OR (1<<6)
+#define SDMA_DESC_CMDSTAT_BR (1<<9)
+#define SDMA_DESC_CMDSTAT_MI (1<<10)
+#define SDMA_DESC_CMDSTAT_A (1<<11)
+#define SDMA_DESC_CMDSTAT_AM (1<<12)
+#define SDMA_DESC_CMDSTAT_CT (1<<13)
+#define SDMA_DESC_CMDSTAT_C (1<<14)
+#define SDMA_DESC_CMDSTAT_ES (1<<15)
+#define SDMA_DESC_CMDSTAT_L (1<<16)
+#define SDMA_DESC_CMDSTAT_F (1<<17)
+#define SDMA_DESC_CMDSTAT_P (1<<18)
+#define SDMA_DESC_CMDSTAT_EI (1<<23)
+#define SDMA_DESC_CMDSTAT_O (1<<31)
+
+#define SDMA_DESC_DFLT (SDMA_DESC_CMDSTAT_O | \
+ SDMA_DESC_CMDSTAT_EI)
+
+#define SDMA_SDC_RFT (1<<0)
+#define SDMA_SDC_SFM (1<<1)
+#define SDMA_SDC_BLMR (1<<6)
+#define SDMA_SDC_BLMT (1<<7)
+#define SDMA_SDC_POVR (1<<8)
+#define SDMA_SDC_RIFB (1<<9)
+
+#define SDMA_SDCM_ERD (1<<7)
+#define SDMA_SDCM_AR (1<<15)
+#define SDMA_SDCM_STD (1<<16)
+#define SDMA_SDCM_TXD (1<<23)
+#define SDMA_SDCM_AT (1<<31)
+
+#define SDMA_0_CAUSE_RXBUF (1<<0)
+#define SDMA_0_CAUSE_RXERR (1<<1)
+#define SDMA_0_CAUSE_TXBUF (1<<2)
+#define SDMA_0_CAUSE_TXEND (1<<3)
+#define SDMA_1_CAUSE_RXBUF (1<<8)
+#define SDMA_1_CAUSE_RXERR (1<<9)
+#define SDMA_1_CAUSE_TXBUF (1<<10)
+#define SDMA_1_CAUSE_TXEND (1<<11)
+
+#define SDMA_CAUSE_RX_MASK (SDMA_0_CAUSE_RXBUF | SDMA_0_CAUSE_RXERR | \
+ SDMA_1_CAUSE_RXBUF | SDMA_1_CAUSE_RXERR)
+#define SDMA_CAUSE_TX_MASK (SDMA_0_CAUSE_TXBUF | SDMA_0_CAUSE_TXEND | \
+ SDMA_1_CAUSE_TXBUF | SDMA_1_CAUSE_TXEND)
+
+/* SDMA Interrupt registers */
+#define SDMA_INTR_CAUSE 0x0000
+#define SDMA_INTR_MASK 0x0080
+
+/*
+ *****************************************************************************
+ *
+ * Baud Rate Generator Interface Registers
+ *
+ *****************************************************************************
+ */
+
+#define BRG_BCR 0x0000
+#define BRG_BTR 0x0004
+
+#endif /*_PPC_BOOT_MPSC_DEFS_H__ */
diff -Nru a/arch/ppc/boot/simple/mv64x60_tty.c b/arch/ppc/boot/simple/mv64x60_tty.c
--- a/arch/ppc/boot/simple/mv64x60_tty.c 2004-11-22 17:03:43 -07:00
+++ b/arch/ppc/boot/simple/mv64x60_tty.c 2004-11-22 17:03:43 -07:00
@@ -21,7 +21,7 @@
#include <linux/serial_reg.h>
#include <asm/serial.h>
#include <asm/mv64x60_defs.h>
-#include "../../../../drivers/serial/mpsc_defs.h"
+#include <mpsc_defs.h>
extern void udelay(long);
static void stop_dma(int chan);
@@ -78,19 +78,19 @@
static u32 mpsc_base[2] = { MV64x60_MPSC_0_OFFSET, MV64x60_MPSC_1_OFFSET };
struct mv64x60_rx_desc {
- volatile u16 bufsize;
- volatile u16 bytecnt;
- volatile u32 cmd_stat;
- volatile u32 next_desc_ptr;
- volatile u32 buffer;
+ u16 bufsize;
+ u16 bytecnt;
+ u32 cmd_stat;
+ u32 next_desc_ptr;
+ u32 buffer;
};
struct mv64x60_tx_desc {
- volatile u16 bytecnt;
- volatile u16 shadow;
- volatile u32 cmd_stat;
- volatile u32 next_desc_ptr;
- volatile u32 buffer;
+ u16 bytecnt;
+ u16 shadow;
+ u32 cmd_stat;
+ u32 next_desc_ptr;
+ u32 buffer;
};
#define MAX_RESET_WAIT 10000
@@ -121,6 +121,24 @@
SDMA_DESC_CMDSTAT_O; \
}
+#ifdef CONFIG_MV64360
+static u32 cpu2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = {
+ { MV64x60_CPU2MEM_0_BASE, MV64x60_CPU2MEM_0_SIZE },
+ { MV64x60_CPU2MEM_1_BASE, MV64x60_CPU2MEM_1_SIZE },
+ { MV64x60_CPU2MEM_2_BASE, MV64x60_CPU2MEM_2_SIZE },
+ { MV64x60_CPU2MEM_3_BASE, MV64x60_CPU2MEM_3_SIZE }
+};
+
+static u32 com2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = {
+ { MV64360_MPSC2MEM_0_BASE, MV64360_MPSC2MEM_0_SIZE },
+ { MV64360_MPSC2MEM_1_BASE, MV64360_MPSC2MEM_1_SIZE },
+ { MV64360_MPSC2MEM_2_BASE, MV64360_MPSC2MEM_2_SIZE },
+ { MV64360_MPSC2MEM_3_BASE, MV64360_MPSC2MEM_3_SIZE }
+};
+
+static u32 dram_selects[MV64x60_CPU2MEM_WINDOWS] = { 0xe, 0xd, 0xb, 0x7 };
+#endif
+
unsigned long
serial_init(int chan, void *ignored)
{
@@ -180,19 +198,6 @@
/* Set up comm unit to memory mapping windows */
/* Note: Assumes MV64x60_CPU2MEM_WINDOWS == 4 */
- u32 cpu2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = {
- { MV64x60_CPU2MEM_0_BASE, MV64x60_CPU2MEM_0_SIZE },
- { MV64x60_CPU2MEM_1_BASE, MV64x60_CPU2MEM_1_SIZE },
- { MV64x60_CPU2MEM_2_BASE, MV64x60_CPU2MEM_2_SIZE },
- { MV64x60_CPU2MEM_3_BASE, MV64x60_CPU2MEM_3_SIZE }
- };
- u32 com2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = {
- { MV64360_MPSC2MEM_0_BASE, MV64360_MPSC2MEM_0_SIZE },
- { MV64360_MPSC2MEM_1_BASE, MV64360_MPSC2MEM_1_SIZE },
- { MV64360_MPSC2MEM_2_BASE, MV64360_MPSC2MEM_2_SIZE },
- { MV64360_MPSC2MEM_3_BASE, MV64360_MPSC2MEM_3_SIZE }
- };
- u32 dram_selects[MV64x60_CPU2MEM_WINDOWS] = { 0xe, 0xd, 0xb, 0x7 };
enables = MV64x60_REG_READ(MV64360_CPU_BAR_ENABLE) & 0xf;
prot_bits = 0;
diff -Nru a/arch/ppc/syslib/gt64260_pic.c b/arch/ppc/syslib/gt64260_pic.c
--- a/arch/ppc/syslib/gt64260_pic.c 2004-11-22 17:03:43 -07:00
+++ b/arch/ppc/syslib/gt64260_pic.c 2004-11-22 17:03:43 -07:00
@@ -294,21 +294,31 @@
static int __init
gt64260_register_hdlrs(void)
{
+ int rc;
+
/* Register CPU interface error interrupt handler */
- request_irq(MV64x60_IRQ_CPU_ERR, gt64260_cpu_error_int_handler,
- SA_INTERRUPT, CPU_INTR_STR, 0);
+ if ((rc = request_irq(MV64x60_IRQ_CPU_ERR,
+ gt64260_cpu_error_int_handler, SA_INTERRUPT, CPU_INTR_STR, 0)))
+ printk(KERN_WARNING "Can't register cpu error handler: %d", rc);
+
mv64x60_write(&bh, MV64x60_CPU_ERR_MASK, 0);
mv64x60_write(&bh, MV64x60_CPU_ERR_MASK, 0x000000fe);
/* Register PCI 0 error interrupt handler */
- request_irq(MV64360_IRQ_PCI0, gt64260_pci_error_int_handler,
- SA_INTERRUPT, PCI0_INTR_STR, (void *)0);
+ if ((rc = request_irq(MV64360_IRQ_PCI0, gt64260_pci_error_int_handler,
+ SA_INTERRUPT, PCI0_INTR_STR, (void *)0)))
+ printk(KERN_WARNING "Can't register pci 0 error handler: %d",
+ rc);
+
mv64x60_write(&bh, MV64x60_PCI0_ERR_MASK, 0);
mv64x60_write(&bh, MV64x60_PCI0_ERR_MASK, 0x003c0c24);
/* Register PCI 1 error interrupt handler */
- request_irq(MV64360_IRQ_PCI1, gt64260_pci_error_int_handler,
- SA_INTERRUPT, PCI1_INTR_STR, (void *)1);
+ if ((rc = request_irq(MV64360_IRQ_PCI1, gt64260_pci_error_int_handler,
+ SA_INTERRUPT, PCI1_INTR_STR, (void *)1)))
+ printk(KERN_WARNING "Can't register pci 1 error handler: %d",
+ rc);
+
mv64x60_write(&bh, MV64x60_PCI1_ERR_MASK, 0);
mv64x60_write(&bh, MV64x60_PCI1_ERR_MASK, 0x003c0c24);
diff -Nru a/arch/ppc/syslib/mv64360_pic.c b/arch/ppc/syslib/mv64360_pic.c
--- a/arch/ppc/syslib/mv64360_pic.c 2004-11-22 17:03:43 -07:00
+++ b/arch/ppc/syslib/mv64360_pic.c 2004-11-22 17:03:43 -07:00
@@ -367,16 +367,20 @@
mv64360_register_hdlrs(void)
{
u32 mask;
+ int rc;
/* Register CPU interface error interrupt handler */
- request_irq(MV64x60_IRQ_CPU_ERR, mv64360_cpu_error_int_handler,
- SA_INTERRUPT, CPU_INTR_STR, 0);
+ if ((rc = request_irq(MV64x60_IRQ_CPU_ERR,
+ mv64360_cpu_error_int_handler, SA_INTERRUPT, CPU_INTR_STR, 0)))
+ printk(KERN_WARNING "Can't register cpu error handler: %d", rc);
+
mv64x60_write(&bh, MV64x60_CPU_ERR_MASK, 0);
mv64x60_write(&bh, MV64x60_CPU_ERR_MASK, 0x000000ff);
/* Register internal SRAM error interrupt handler */
- request_irq(MV64360_IRQ_SRAM_PAR_ERR, mv64360_sram_error_int_handler,
- SA_INTERRUPT, SRAM_INTR_STR, 0);
+ if ((rc = request_irq(MV64360_IRQ_SRAM_PAR_ERR,
+ mv64360_sram_error_int_handler,SA_INTERRUPT,SRAM_INTR_STR, 0)))
+ printk(KERN_WARNING "Can't register SRAM error handler: %d",rc);
/*
* Bit 0 reserved on 64360 and erratum FEr PCI-#11 (PCI internal
@@ -390,14 +394,20 @@
mask |= 0x1; /* enable DPErr on 64460 */
/* Register PCI 0 error interrupt handler */
- request_irq(MV64360_IRQ_PCI0, mv64360_pci_error_int_handler,
- SA_INTERRUPT, PCI0_INTR_STR, (void *)0);
+ if ((rc = request_irq(MV64360_IRQ_PCI0, mv64360_pci_error_int_handler,
+ SA_INTERRUPT, PCI0_INTR_STR, (void *)0)))
+ printk(KERN_WARNING "Can't register pci 0 error handler: %d",
+ rc);
+
mv64x60_write(&bh, MV64x60_PCI0_ERR_MASK, 0);
mv64x60_write(&bh, MV64x60_PCI0_ERR_MASK, mask);
/* Register PCI 1 error interrupt handler */
- request_irq(MV64360_IRQ_PCI1, mv64360_pci_error_int_handler,
- SA_INTERRUPT, PCI1_INTR_STR, (void *)1);
+ if ((rc = request_irq(MV64360_IRQ_PCI1, mv64360_pci_error_int_handler,
+ SA_INTERRUPT, PCI1_INTR_STR, (void *)1)))
+ printk(KERN_WARNING "Can't register pci 1 error handler: %d",
+ rc);
+
mv64x60_write(&bh, MV64x60_PCI1_ERR_MASK, 0);
mv64x60_write(&bh, MV64x60_PCI1_ERR_MASK, mask);
diff -Nru a/arch/ppc/syslib/mv64x60.c b/arch/ppc/syslib/mv64x60.c
--- a/arch/ppc/syslib/mv64x60.c 2004-11-22 17:03:43 -07:00
+++ b/arch/ppc/syslib/mv64x60.c 2004-11-22 17:03:43 -07:00
@@ -192,7 +192,7 @@
.num_resources = ARRAY_SIZE(mv64x60_mpsc_shared_resources),
.resource = mv64x60_mpsc_shared_resources,
.dev = {
- .driver_data = (void *)&mv64x60_mpsc_shared_pd_dd,
+ .driver_data = &mv64x60_mpsc_shared_pd_dd,
},
};
@@ -248,7 +248,7 @@
.num_resources = ARRAY_SIZE(mv64x60_mpsc0_resources),
.resource = mv64x60_mpsc0_resources,
.dev = {
- .driver_data = (void *)&mv64x60_mpsc0_pd_dd,
+ .driver_data = &mv64x60_mpsc0_pd_dd,
},
};
@@ -305,7 +305,7 @@
.num_resources = ARRAY_SIZE(mv64x60_mpsc1_resources),
.resource = mv64x60_mpsc1_resources,
.dev = {
- .driver_data = (void *)&mv64x60_mpsc1_pd_dd,
+ .driver_data = &mv64x60_mpsc1_pd_dd,
},
};
#endif
@@ -537,6 +537,7 @@
val = map_to_field(val, size_bits);
mv64x60_write(bh, size_reg, val);
}
+
(void)mv64x60_read(bh, base_reg); /* Flush FIFO */
}
@@ -836,15 +837,19 @@
{
struct mv64x60_handle bh;
u32 mem_windows[MV64x60_CPU2MEM_WINDOWS][2];
+ u32 rc = 0;
memset(&bh, 0, sizeof(bh));
bh.type = chip_type;
bh.v_base = bridge_base;
- (void)mv64x60_setup_for_chip(&bh);
- mv64x60_get_mem_windows(&bh, mem_windows);
- return mv64x60_calc_mem_size(&bh, mem_windows);
+ if (!mv64x60_setup_for_chip(&bh)) {
+ mv64x60_get_mem_windows(&bh, mem_windows);
+ rc = mv64x60_calc_mem_size(&bh, mem_windows);
+ }
+
+ return rc;
}
/*
@@ -900,20 +905,22 @@
*
* Configure CPU->Memory windows on the bridge.
*/
+static u32 prot_tab[] __initdata = {
+ MV64x60_CPU_PROT_0_WIN, MV64x60_CPU_PROT_1_WIN,
+ MV64x60_CPU_PROT_2_WIN, MV64x60_CPU_PROT_3_WIN
+};
+
+static u32 cpu_snoop_tab[] __initdata = {
+ MV64x60_CPU_SNOOP_0_WIN, MV64x60_CPU_SNOOP_1_WIN,
+ MV64x60_CPU_SNOOP_2_WIN, MV64x60_CPU_SNOOP_3_WIN
+};
+
void __init
mv64x60_config_cpu2mem_windows(struct mv64x60_handle *bh,
struct mv64x60_setup_info *si,
u32 mem_windows[MV64x60_CPU2MEM_WINDOWS][2])
{
u32 i, win;
- u32 prot_tab[] = {
- MV64x60_CPU_PROT_0_WIN, MV64x60_CPU_PROT_1_WIN,
- MV64x60_CPU_PROT_2_WIN, MV64x60_CPU_PROT_3_WIN
- };
- u32 cpu_snoop_tab[] = {
- MV64x60_CPU_SNOOP_0_WIN, MV64x60_CPU_SNOOP_1_WIN,
- MV64x60_CPU_SNOOP_2_WIN, MV64x60_CPU_SNOOP_3_WIN
- };
/* Set CPU protection & snoop windows */
for (win=MV64x60_CPU2MEM_0_WIN,i=0;win<=MV64x60_CPU2MEM_3_WIN;win++,i++)
@@ -942,29 +949,25 @@
*
* Configure the CPU->PCI windows for one of the PCI buses.
*/
+static u32 win_tab[2][4] __initdata = {
+ { MV64x60_CPU2PCI0_IO_WIN, MV64x60_CPU2PCI0_MEM_0_WIN,
+ MV64x60_CPU2PCI0_MEM_1_WIN, MV64x60_CPU2PCI0_MEM_2_WIN },
+ { MV64x60_CPU2PCI1_IO_WIN, MV64x60_CPU2PCI1_MEM_0_WIN,
+ MV64x60_CPU2PCI1_MEM_1_WIN, MV64x60_CPU2PCI1_MEM_2_WIN },
+};
+
+static u32 remap_tab[2][4] __initdata = {
+ { MV64x60_CPU2PCI0_IO_REMAP_WIN, MV64x60_CPU2PCI0_MEM_0_REMAP_WIN,
+ MV64x60_CPU2PCI0_MEM_1_REMAP_WIN, MV64x60_CPU2PCI0_MEM_2_REMAP_WIN },
+ { MV64x60_CPU2PCI1_IO_REMAP_WIN, MV64x60_CPU2PCI1_MEM_0_REMAP_WIN,
+ MV64x60_CPU2PCI1_MEM_1_REMAP_WIN, MV64x60_CPU2PCI1_MEM_2_REMAP_WIN }
+};
+
void __init
mv64x60_config_cpu2pci_windows(struct mv64x60_handle *bh,
struct mv64x60_pci_info *pi, u32 bus)
{
int i;
- u32 win_tab[2][4] = {
- { MV64x60_CPU2PCI0_IO_WIN, MV64x60_CPU2PCI0_MEM_0_WIN,
- MV64x60_CPU2PCI0_MEM_1_WIN,
- MV64x60_CPU2PCI0_MEM_2_WIN },
- { MV64x60_CPU2PCI1_IO_WIN, MV64x60_CPU2PCI1_MEM_0_WIN,
- MV64x60_CPU2PCI1_MEM_1_WIN,
- MV64x60_CPU2PCI1_MEM_2_WIN },
- };
- u32 remap_tab[2][4] = {
- { MV64x60_CPU2PCI0_IO_REMAP_WIN,
- MV64x60_CPU2PCI0_MEM_0_REMAP_WIN,
- MV64x60_CPU2PCI0_MEM_1_REMAP_WIN,
- MV64x60_CPU2PCI0_MEM_2_REMAP_WIN },
- { MV64x60_CPU2PCI1_IO_REMAP_WIN,
- MV64x60_CPU2PCI1_MEM_0_REMAP_WIN,
- MV64x60_CPU2PCI1_MEM_1_REMAP_WIN,
- MV64x60_CPU2PCI1_MEM_2_REMAP_WIN }
- };
if (pi->pci_io.size > 0) {
mv64x60_set_32bit_window(bh, win_tab[bus][0],
@@ -1004,38 +1007,33 @@
*
* Configure the PCI->Memory windows on the bridge.
*/
+static u32 pci_acc_tab[2][4] __initdata = {
+ { MV64x60_PCI02MEM_ACC_CNTL_0_WIN, MV64x60_PCI02MEM_ACC_CNTL_1_WIN,
+ MV64x60_PCI02MEM_ACC_CNTL_2_WIN, MV64x60_PCI02MEM_ACC_CNTL_3_WIN },
+ { MV64x60_PCI12MEM_ACC_CNTL_0_WIN, MV64x60_PCI12MEM_ACC_CNTL_1_WIN,
+ MV64x60_PCI12MEM_ACC_CNTL_2_WIN, MV64x60_PCI12MEM_ACC_CNTL_3_WIN }
+};
+
+static u32 pci_snoop_tab[2][4] __initdata = {
+ { MV64x60_PCI02MEM_SNOOP_0_WIN, MV64x60_PCI02MEM_SNOOP_1_WIN,
+ MV64x60_PCI02MEM_SNOOP_2_WIN, MV64x60_PCI02MEM_SNOOP_3_WIN },
+ { MV64x60_PCI12MEM_SNOOP_0_WIN, MV64x60_PCI12MEM_SNOOP_1_WIN,
+ MV64x60_PCI12MEM_SNOOP_2_WIN, MV64x60_PCI12MEM_SNOOP_3_WIN }
+};
+
+static u32 pci_size_tab[2][4] __initdata = {
+ { MV64x60_PCI0_MEM_0_SIZE, MV64x60_PCI0_MEM_1_SIZE,
+ MV64x60_PCI0_MEM_2_SIZE, MV64x60_PCI0_MEM_3_SIZE },
+ { MV64x60_PCI1_MEM_0_SIZE, MV64x60_PCI1_MEM_1_SIZE,
+ MV64x60_PCI1_MEM_2_SIZE, MV64x60_PCI1_MEM_3_SIZE }
+};
+
void __init
mv64x60_config_pci2mem_windows(struct mv64x60_handle *bh,
struct pci_controller *hose, struct mv64x60_pci_info *pi,
u32 bus, u32 mem_windows[MV64x60_CPU2MEM_WINDOWS][2])
{
u32 i, win;
- u32 pci_acc_tab[2][4] = {
- { MV64x60_PCI02MEM_ACC_CNTL_0_WIN,
- MV64x60_PCI02MEM_ACC_CNTL_1_WIN,
- MV64x60_PCI02MEM_ACC_CNTL_2_WIN,
- MV64x60_PCI02MEM_ACC_CNTL_3_WIN },
- { MV64x60_PCI12MEM_ACC_CNTL_0_WIN,
- MV64x60_PCI12MEM_ACC_CNTL_1_WIN,
- MV64x60_PCI12MEM_ACC_CNTL_2_WIN,
- MV64x60_PCI12MEM_ACC_CNTL_3_WIN }
- };
- u32 pci_snoop_tab[2][4] = {
- { MV64x60_PCI02MEM_SNOOP_0_WIN,
- MV64x60_PCI02MEM_SNOOP_1_WIN,
- MV64x60_PCI02MEM_SNOOP_2_WIN,
- MV64x60_PCI02MEM_SNOOP_3_WIN },
- { MV64x60_PCI12MEM_SNOOP_0_WIN,
- MV64x60_PCI12MEM_SNOOP_1_WIN,
- MV64x60_PCI12MEM_SNOOP_2_WIN,
- MV64x60_PCI12MEM_SNOOP_3_WIN }
- };
- u32 pci_size_tab[2][4] = {
- { MV64x60_PCI0_MEM_0_SIZE, MV64x60_PCI0_MEM_1_SIZE,
- MV64x60_PCI0_MEM_2_SIZE, MV64x60_PCI0_MEM_3_SIZE },
- { MV64x60_PCI1_MEM_0_SIZE, MV64x60_PCI1_MEM_1_SIZE,
- MV64x60_PCI1_MEM_2_SIZE, MV64x60_PCI1_MEM_3_SIZE }
- };
/*
* Set the access control, snoop, BAR size, and window base addresses.
@@ -1345,13 +1343,14 @@
* The PCI->MEM window registers are actually in PCI config space so need
* to set them by setting the correct config space BARs.
*/
+static u32 gt64260_reg_addrs[2][4] __initdata = {
+ { 0x10, 0x14, 0x18, 0x1c }, { 0x90, 0x94, 0x98, 0x9c }
+};
+
static void __init
gt64260_set_pci2mem_window(struct pci_controller *hose, u32 bus, u32 window,
u32 base)
{
- u32 reg_addrs[2][4] = {
- { 0x10, 0x14, 0x18, 0x1c }, { 0x90, 0x94, 0x98, 0x9c }
- };
u8 save_exclude;
pr_debug("set pci->mem window: %d, hose: %d, base: 0x%x\n", window,
@@ -1360,7 +1359,7 @@
save_exclude = mv64x60_pci_exclude_bridge;
mv64x60_pci_exclude_bridge = 0;
early_write_config_dword(hose, 0, PCI_DEVFN(0, 0),
- reg_addrs[bus][window], mv64x60_mask(base, 20) | 0x8);
+ gt64260_reg_addrs[bus][window], mv64x60_mask(base, 20) | 0x8);
mv64x60_pci_exclude_bridge = save_exclude;
return;
@@ -1371,11 +1370,12 @@
*
* Set where the bridge's registers appear in PCI MEM space.
*/
+static u32 gt64260_offset[2] __initdata = {0x20, 0xa0};
+
static void __init
gt64260_set_pci2regs_window(struct mv64x60_handle *bh,
struct pci_controller *hose, u32 bus, u32 base)
{
- u32 offset[2] = {0x20, 0xa0};
u8 save_exclude;
pr_debug("set pci->internal regs hose: %d, base: 0x%x\n", hose->index,
@@ -1383,7 +1383,7 @@
save_exclude = mv64x60_pci_exclude_bridge;
mv64x60_pci_exclude_bridge = 0;
- early_write_config_dword(hose, 0, PCI_DEVFN(0,0), offset[bus],
+ early_write_config_dword(hose, 0, PCI_DEVFN(0,0), gt64260_offset[bus],
(base << 16));
mv64x60_pci_exclude_bridge = save_exclude;
@@ -1778,20 +1778,21 @@
* The PCI->MEM window registers are actually in PCI config space so need
* to set them by setting the correct config space BARs.
*/
+struct {
+ u32 fcn;
+ u32 base_hi_bar;
+ u32 base_lo_bar;
+} static mv64360_reg_addrs[2][4] __initdata = {
+ {{ 0, 0x14, 0x10 }, { 0, 0x1c, 0x18 },
+ { 1, 0x14, 0x10 }, { 1, 0x1c, 0x18 }},
+ {{ 0, 0x94, 0x90 }, { 0, 0x9c, 0x98 },
+ { 1, 0x94, 0x90 }, { 1, 0x9c, 0x98 }}
+};
+
static void __init
mv64360_set_pci2mem_window(struct pci_controller *hose, u32 bus, u32 window,
u32 base)
{
- struct {
- u32 fcn;
- u32 base_hi_bar;
- u32 base_lo_bar;
- } reg_addrs[2][4] = {
- {{ 0, 0x14, 0x10 }, { 0, 0x1c, 0x18 },
- { 1, 0x14, 0x10 }, { 1, 0x1c, 0x18 }},
- {{ 0, 0x94, 0x90 }, { 0, 0x9c, 0x98 },
- { 1, 0x94, 0x90 }, { 1, 0x9c, 0x98 }}
- };
u8 save_exclude;
pr_debug("set pci->mem window: %d, hose: %d, base: 0x%x\n", window,
@@ -1800,11 +1801,12 @@
save_exclude = mv64x60_pci_exclude_bridge;
mv64x60_pci_exclude_bridge = 0;
early_write_config_dword(hose, 0,
- PCI_DEVFN(0, reg_addrs[bus][window].fcn),
- reg_addrs[bus][window].base_hi_bar, 0);
+ PCI_DEVFN(0, mv64360_reg_addrs[bus][window].fcn),
+ mv64360_reg_addrs[bus][window].base_hi_bar, 0);
early_write_config_dword(hose, 0,
- PCI_DEVFN(0, reg_addrs[bus][window].fcn),
- reg_addrs[bus][window].base_lo_bar,mv64x60_mask(base,20) | 0xc);
+ PCI_DEVFN(0, mv64360_reg_addrs[bus][window].fcn),
+ mv64360_reg_addrs[bus][window].base_lo_bar,
+ mv64x60_mask(base,20) | 0xc);
mv64x60_pci_exclude_bridge = save_exclude;
return;
@@ -1815,11 +1817,12 @@
*
* Set where the bridge's registers appear in PCI MEM space.
*/
+static u32 mv64360_offset[2][2] __initdata = {{0x20, 0x24}, {0xa0, 0xa4}};
+
static void __init
mv64360_set_pci2regs_window(struct mv64x60_handle *bh,
struct pci_controller *hose, u32 bus, u32 base)
{
- u32 offset[2][2] = {{0x20, 0x24}, {0xa0, 0xa4}};
u8 save_exclude;
pr_debug("set pci->internal regs hose: %d, base: 0x%x\n", hose->index,
@@ -1827,9 +1830,10 @@
save_exclude = mv64x60_pci_exclude_bridge;
mv64x60_pci_exclude_bridge = 0;
- early_write_config_dword(hose, 0, PCI_DEVFN(0,0), offset[bus][0],
- (base << 16));
- early_write_config_dword(hose, 0, PCI_DEVFN(0,0), offset[bus][1], 0);
+ early_write_config_dword(hose, 0, PCI_DEVFN(0,0),
+ mv64360_offset[bus][0], (base << 16));
+ early_write_config_dword(hose, 0, PCI_DEVFN(0,0),
+ mv64360_offset[bus][1], 0);
mv64x60_pci_exclude_bridge = save_exclude;
return;
@@ -2110,28 +2114,32 @@
* ENET, MPSC, and IDMA ctlrs on the MV64[34]60 have separate windows that
* must be set up so that the respective ctlr can access system memory.
*/
+static u32 enet_tab[MV64x60_CPU2MEM_WINDOWS] __initdata = {
+ MV64x60_ENET2MEM_0_WIN, MV64x60_ENET2MEM_1_WIN,
+ MV64x60_ENET2MEM_2_WIN, MV64x60_ENET2MEM_3_WIN,
+};
+
+static u32 mpsc_tab[MV64x60_CPU2MEM_WINDOWS] __initdata = {
+ MV64x60_MPSC2MEM_0_WIN, MV64x60_MPSC2MEM_1_WIN,
+ MV64x60_MPSC2MEM_2_WIN, MV64x60_MPSC2MEM_3_WIN,
+};
+
+static u32 idma_tab[MV64x60_CPU2MEM_WINDOWS] __initdata = {
+ MV64x60_IDMA2MEM_0_WIN, MV64x60_IDMA2MEM_1_WIN,
+ MV64x60_IDMA2MEM_2_WIN, MV64x60_IDMA2MEM_3_WIN,
+};
+
+static u32 dram_selects[MV64x60_CPU2MEM_WINDOWS] __initdata =
+ { 0xe, 0xd, 0xb, 0x7 };
+
static void __init
mv64360_config_io2mem_windows(struct mv64x60_handle *bh,
struct mv64x60_setup_info *si,
u32 mem_windows[MV64x60_CPU2MEM_WINDOWS][2])
{
u32 i, win;
- u32 enet_tab[MV64x60_CPU2MEM_WINDOWS] = {
- MV64x60_ENET2MEM_0_WIN, MV64x60_ENET2MEM_1_WIN,
- MV64x60_ENET2MEM_2_WIN, MV64x60_ENET2MEM_3_WIN,
- };
- u32 mpsc_tab[MV64x60_CPU2MEM_WINDOWS] = {
- MV64x60_MPSC2MEM_0_WIN, MV64x60_MPSC2MEM_1_WIN,
- MV64x60_MPSC2MEM_2_WIN, MV64x60_MPSC2MEM_3_WIN,
- };
- u32 idma_tab[MV64x60_CPU2MEM_WINDOWS] = {
- MV64x60_IDMA2MEM_0_WIN, MV64x60_IDMA2MEM_1_WIN,
- MV64x60_IDMA2MEM_2_WIN, MV64x60_IDMA2MEM_3_WIN,
- };
- u32 dram_selects[MV64x60_CPU2MEM_WINDOWS] = { 0xe, 0xd, 0xb, 0x7 };
pr_debug("config_io2regs_windows: enet, mpsc, idma -> bridge regs\n");
-
mv64x60_write(bh, MV64360_ENET2MEM_ACC_PROT_0, 0);
mv64x60_write(bh, MV64360_ENET2MEM_ACC_PROT_1, 0);
^ permalink raw reply
* Re: TEST: Sleep patch #4
From: Chris Anderson @ 2004-11-23 1:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, gentoo-ppc-user,
debian-powerpc@lists.debian.org
In-Reply-To: <1101083578.13597.5.camel@gaston>
On Mon, Nov 22, 2004 at 11:32:58AM +1100, Benjamin Herrenschmidt wrote:
> Ok, here's the 4th iteration of the patch. It includes John Steele Scott fixes for
> cpufreq and the sound driver and fixes a problem where memory refresh wouldn't properly
> be re-enabled on the video chip upon wakeup. I also cleaned a bit more the MDLL reset
> code for r300, plus a couple of other things.
>
> http://gate.crashing.org/~benh/albook-ibookg4-sleep-4.diff
>
> Ben.
Works like a charm here.
>
>
>
> --
> To UNSUBSCRIBE, email to debian-powerpc-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
Chris Anderson <chris@nullcode.org>
ICQ: 72021847 Jabber: chrisja@jabber.org
20B2 CB34 8AA5 05BC A90C 2CDD 2768 D4B4 2B93 424B
^ permalink raw reply
* Re: [PATCH][PPC32] Marvell host bridge support (mv64x60)
From: Andrew Morton @ 2004-11-23 4:24 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, linux-kernel, linuxppc-embedded
In-Reply-To: <41A27F77.9080401@mvista.com>
"Mark A. Greer" <mgreer@mvista.com> wrote:
>
> Andrew Morton wrote:
>
> >Anyway, I'll stick this as-is in -mm. Feel free to send an incremental
> >patch, or a replacement.
> >
>
> Here is an incremental patch [hopefully] with your concerns addressed.
OK, thanks. I added this to the queue for post-2.6.10. I'll assume that
silence means assent from the rest of the ppc team ;)
(Patches are at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/broken-out/ppc32-marvell-host-bridge-support-mv64x60.patch
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/broken-out/ppc32-support-for-marvell-ev-64260-bp-eval-platform.patch
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/broken-out/ppc32-support-for-artesyn-katana-cpci-boards.patch
^ 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