* MPC8xx Debugging: function call vs. no function call
From: Josef Angermeier @ 2006-05-23 15:40 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am not yet pretty familiar with 8xx system programming, so maybe you
could give me some debugging hint. My C code which programs the the CPM
(USB) has to execute the following commands:
eieio();
usbregs->usb_uscom = 0x80 | 0;
mb();
If i put those instructions in an new function, the CPM behaves as
wished, elsewise it depends on the remaining code. E.g. the number of
NOP machine code instructions before make a difference:
1.)
...< remaining C function code>
__asm__("nop\n\t");
eieio();
usbregs->usb_uscom = 0x80 | 0;
mb();
... <other code>
2.)
...< remaining C function code>
__asm__("nop\n\t");
__asm__("nop\n\t");
eieio();
usbregs->usb_uscom = 0x80 | 0;
mb();
... <other code>
Every hint howto find my mistake is appreciated! Thanks
Josef
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Hollis Blanchard @ 2006-05-23 15:25 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148395617.3434.0.camel@diesel>
On Tue, 2006-05-23 at 09:46 -0500, Hollis Blanchard wrote:
>
> Could you also add a sample modules.conf? For example, users should be
> told to remove snd-powermac. Here's what I have ATM, on an FC5 system:
> alias snd-card-0 i2sbus
> remove snd-card-0 { /usr/sbin/alsactl store 0 >/dev/null 2>&1
> || : ; }; /sbin/modprobe -r --ignore-remove snd-powermac
Oops, obviously that last "snd-powermac" shouldn't be there; I just
edited what FC5 had put there and I missed a spot. Maybe this will be
better:
alias snd-card-0 i2sbus
remove i2sbus { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove i2sbus
Also, the file is called modprobe.conf... :)
-Hollis
^ permalink raw reply
* Re: Maple: killing a process that causes a machine check exception
From: Anton Blanchard @ 2006-05-23 15:15 UTC (permalink / raw)
To: jfaslist; +Cc: linuxppc64-dev
In-Reply-To: <44732357.4000506@yahoo.fr>
> By applying the following mods (plse see below), i was able to have a
> user process that caused a machine check exception to be terminated (on
> a Maple platform), as expected. I was wondering why the PPC64 had a
> different ME handling than PPC which does send the SIGBUS to the process?
Not all machine checks are synchronous so we cant always do this. From
memory the ppc64 version will panic if the machine check wasnt
synchronous.
Anton
^ permalink raw reply
* Re: UART DRIVER on 2.6.15
From: Vitaly Bordug @ 2006-05-23 15:11 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <3348e5d9925e49e2badcd00d615156b4@pobox.sk>
On Tue, 23 May 2006 14:02:49 +0200
"Ladislav Klenovič" <lk99336@pobox.sk> wrote:
> Hi,
> just a simple question, is uart driver for kernel 2.6.15 complete.
> There are some parts like:
> void scc1_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC1: insert port configuration here */
> pinfo->brg = 1;
> }
> ....
> that seems to incomplete. Am I able to do something with SCC1 with the current cpm_uart code?
>
> Maybe stupid question, is there any way (is it possible) to import old uart driver from kernel 2.4.x to kernel 2.6.x
>
It is clear, that per-board tune-up is too specific to be kept within drivers/ and now it is accomplished in the board setup code.
Just have a look at arch/ppc/platforms/mps866ads_setup.c The thing you'll have to do is implement the pin tune-up for your board in a function, and set the callback pointer to it - it will be executed at the time UART initializes its resources.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] powerpc: Auto reserve of device tree blob
From: Jon Loeliger @ 2006-05-23 15:04 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <1148315146.17549.8.camel@cashmere.sps.mot.com>
On Mon, 2006-05-22 at 11:25, Jon Loeliger wrote:
> While I've not seen
> it applied yet, I am assuming that Jimi's patch from 14 April
> is what is needed here and will be applied.
And that patch appears to be in Paul's tree now!
jdl
^ permalink raw reply
* Maple: killing a process that causes a machine check exception
From: jfaslist @ 2006-05-23 14:59 UTC (permalink / raw)
To: linuxppc64-dev
Hi,
By applying the following mods (plse see below), i was able to have a
user process that caused a machine check exception to be terminated (on
a Maple platform), as expected. I was wondering why the PPC64 had a
different ME handling than PPC which does send the SIGBUS to the process?
Thanks
Regards,
-jean-francois simon
diff -urN -X linux-2.6.16.14/Documentation/dontdiff
linux-2.6.16.14/arch/powerpc/kernel/traps.c
linux-2.6.16.14.vmeberr_fix/arch/powerpc/kernel/traps.c
--- linux-2.6.16.14/arch/powerpc/kernel/traps.c 2006-05-04
17:03:45.000000000 -0700
+++ linux-2.6.16.14.vmeberr_fix/arch/powerpc/kernel/traps.c 2006-05-09
02:46:59.000000000 -0700
@@ -340,12 +340,19 @@
#ifdef CONFIG_PPC64
int recover = 0;
+
/* See if any machine dependent calls */
if (ppc_md.machine_check_exception)
recover = ppc_md.machine_check_exception(regs);
if (recover)
return;
+
+ if (user_mode(regs)) {
+ regs->msr |= MSR_RI;
+ _exception(SIGBUS, regs, BUS_ADRERR, regs->nip);
+ return;
+ }
#else
unsigned long reason = get_mc_reason(regs);
___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com
^ permalink raw reply
* pmppc7448/mv64x60 DMA from PCI to memory
From: Phil Nitschke @ 2006-05-23 14:50 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm working on a project using this processor:
http://www.artesyncp.com/products/PmPPC7448.html
on a custom VME carrier, as shown below. We're wanting to suck
large amounts of data from a PCI device which _cannot_ perform
bus-mastered DMA (it is a PCI Target only).
The Marvell Chip used by the PmPPC7448 is this one:
http://www.marvell.com/products/communication/Discovery%20MV64460%
20FINAL.pdf
I've written a collection of simple routines to program the Marvell IDMA
controller, for example:
mv64x6x_init_dma_channel();
mv64x6x_set_dma_mode();
mv64x6x_set_src_addr();
mv64x6x_set_dst_addr();
mv64x6x_set_dma_count();
mv64x6x_enable_dma();
or rather more simply:
mv64x6x_memcpy_dma(dst_handle, src_handle, size);
This works OK for copying from a memory to memory, where the buffers are
allocated using:
src = dma_alloc_noncoherent(NULL, BUF_SZ, &src_handle, GFP_KERNEL);
The src_handle is passed directly to mv64x6x_set_src_addr();
But when the src address is the FIFO on the PCI bus, I don't know how to
get the IDMA controller to play nicely. The FIFO sits in the middle of
the PCI device's I/O mem range 0x9fe00000 - 0x9fffffff. I've programmed
and enabled a 5th address window in the IDMA controller which
encompasses the 0x200000 bytes of the PCI memory range, and I'm not
seeing any address violation or address miss errors. The PCI->memory
DMA "completes" without any traffic every touching the PCI bus, so
obviously I need to do something else/differently.
For this scenario, can anyone tell me:
* Should I be using the same src address as that reported via
the 'lspci' command - this _is_ the PCI bus address, isn't it?
* Do I have to do anything special to tell the IDMA controller
to source data from the PCI bus and shift it into memory?
* Looking through mv64x60.c in the 2.6.16 kernel, I note that 4
of the 8 possible IDMA address windows are configured (for each
of the 512 MB DRAM on our processor card). Do I need to add
tests to my source and destination regions, to determine if they
cross one of the 512 MB regions, and hence will require a
different CSx line (and thus the DMA will need to be broken into
two transactions), or does kernel already take care to ensure
allocated regions will not cross these boundaries?
TIA for any help that anyone can offer.
--
Phil
+--------------------------------------------------+
| Custom VME64x Carrier Card |
| +-------------------+ +-------------------+ |
| | Artesyn PmPPC7448 | | Altera FPGA | |
| | | | | |
| |+-----------------+| |+-----------------+| |
| ||Marvell MV64460 || || Altera PCI I/F || |
| ||(NOT coherent || ||(non-prefetchable)| |
| || cache) (+IDMA) || || FIFO || |
| |+--------#--------+| |+---------#-------+| |
| +---------#---------+ +----------#--------+ |
| # PCI Bus # |
| ########################################### |
+--------------------------------------------------+
p.s. Since my driver was developed using documentation obtained from
Marvell under a very restrictive NDA, I cannot release it as open source
just yet. Marvell's Vice President and General Counsel is currently
reviewing the matter, and I expect to hear from them in the next couple
weeks.
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Hollis Blanchard @ 2006-05-23 14:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148387282.25971.8.camel@johannes>
On Tue, 23 May 2006 14:27:52 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
> --44731b52_16deb9ec_c30
>
> gpg: Signature made Tue 23 May 2006 07:27:49 AM CDT using RSA key ID
> 227A1158 gpg: Can't check signature: public key not found
>
> --44731b52_16deb9ec_c30
>
> On Mon, 2006-05-22 at 22:11 -0500, Hollis Blanchard wrote:
>
> > The "auto-loading" stuff doesn't seem to be working for me on my
> > PowerMac11,2, with a fresh git clone as of right now. What is the
> > base module that should load all the others? After a "make
> > install", I still had to modprobe almost everything by hand
> > (`find ./snd-aoa -name \*.ko` in the source directory to get a
> > list).
>
> Odd. i2sbus should pull in all other required modules, and should
> itself load automatically at boot due to having a modalias that
> matches the of:... modalias the mac-io bus device for the i2s stuff
> has.
Yeah, I'm not sure how I was supposed to know that i2sbus was the magic
module. That seems to be working now. Again, from PowerMac11,2:
i2sbus: mapped i2s control registers
i2sbus: control register contents:
i2sbus: fcr0 = 0x8000056
i2sbus: cell_control = 0x5b43b71a
i2sbus: fcr2 = 0xe7008000
i2sbus: fcr3 = 0x7200d607
i2sbus: clock_control = 0x0
i2sbus: found i2s controller
serial format: 0x41190000
dws: 0x2000200
i2sbus: found i2s controller
serial format: 0x41100000
dws: 0x0
...
snd-aoa-fabric-layout: found bus with layout 68 (using)
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
snd-aoa: fabric didn't like codec onyx
snd-aoa-codec-onyx: created and attached onyx instance
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: can use this codec
snd-aoa-codec-onyx: attached to onyx codec via i2c
snd-aoa-codec-onyx: created and attached onyx instance
snd-aoa-fabric-layout: found bus with layout 69 (using)
snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
snd-aoa: fabric didn't like codec onyx
> > snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is
> > on it snd-aoa-codec-tas: created and attached tas instance
> > snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is
> > on it snd-aoa-codec-tas: created and attached tas instance
>
> Uh. That one I need to check, there is no tas codec on your machine.
This is probably just because I loaded all the modules I could find.
> > snd: Unknown layout ID 0x44
>
> That looks like you have snd-powermac loaded too. Or not? I don't
> think I have anything that prints "snd:" as the prefix but I might be
> wrong.
Yes, it looks like snd-powermac was loading as well, thanks to
modules.conf. I've removed that now.
> > For the record, there are two "layout-id" properties in my device
> > tree, as discussed in this patch:
> > http://patchwork.ozlabs.org/linuxppc/patch?id=3D4867
>
> Note that the patch is mine :)
I noted that. Since most of the archived mails aren't overly helpful, I
was trying to be complete.
> > Ultimately, snd_aoa_codec_onyx seems to be the happy module. Only
> > the headphone jack was enabled; I had to use GNOME's "Volume
> > Control" panel applet to enable speakers or line out (both of which
> > work).
> >=20
> > However, volume control doesn't work at all, for both line-out and
> > headphone jacks. Should it?
>
> Yes, it should. I think the bug is that the tas module thinks it can
> attach a codec here. Can you try *not* loading that module and see if
> it works better then? I'll try to see if I can make the tas module not
> attach on those machines, but as long as you don't load it manually
> all should be fine.
Volume control does indeed work when the tas module isn't loaded.
> > Also, it would be helpful if the git tree were better publicized
> > somewhere (e.g. http://johannes.sipsolutions.net/). I had to dig
> > through =
> a LOT of mails to find the source.
>
> Sorry. I linked it up on http://johannes.sipsolutions.net/Projects/
> and will add a few more details later.
Could you also add a sample modules.conf? For example, users should be
told to remove snd-powermac. Here's what I have ATM, on an FC5 system:
alias snd-card-0 i2sbus
remove snd-card-0 { /usr/sbin/alsactl store 0 >/dev/null 2>&1
|| : ; }; /sbin/modprobe -r --ignore-remove snd-powermac
Thanks again!
-Hollis
^ permalink raw reply
* Re: Problem mapping GPIO regs on ppc440gx
From: Travis B. Sawyer @ 2006-05-23 13:50 UTC (permalink / raw)
To: Travis B. Sawyer; +Cc: linuxppc-embedded
In-Reply-To: <44730484.4090208@broadcom.com>
Answering my own question here...
Travis B. Sawyer wrote:
>Greetings:
>
>We've been using a 2.4.30 kernel (with numerous patches) on a AMCC 440gx
>custom built board for quite some time now.
>
>We're building some new hardware that forces us to go to a 2.6 kernel.
>So, I've downloaded 2.6.16.16 from kernel.org and am porting everything
>forward from our 2.4.30 kernel.
>
>The problem lies in mapping the GPIO regs of the 440 to user space using
>/dev/mem:
>
> gpio_fd = open("/dev/mem", O_RDWR | O_SYNC);
>
> if (0 > gpio_fd) {
> perror("mbGpioGet(): Unable to open gpio");
> return(-1);
> }
>
> addr = (ppc440_gpio_regs_t *)mmap(0, getpagesize() * 2,
> PROT_READ | PROT_WRITE,
> MAP_SHARED, gpio_fd,
> (off_t)(0x40000000));
>
>
>
The above mmap call worked for 2.4.30, but for 2.6.16 I needed to change
the offset
to be a multiple of page size, so:
(off_t)(0x40000000/getpagesize());
-travis
^ permalink raw reply
* [PATCH, 2.6.17-rc4-git10] ieee80211softmac_io.c: fix warning "defined but not used"
From: Toralf Förster @ 2006-05-23 13:49 UTC (permalink / raw)
To: linville; +Cc: netdev, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]
Got this compiler warning today and Johannes Berg <johannes@sipsolutions.net> wrote:
Yeah, known 'bug', we have that code there but never use it. Feel free
to submit a patch (to John Linville, CC netdev and softmac-dev) to
remove it.
Signed-off-by: Toralf Foerster <toralf.foerster@gmx.de>
--- linux-2.6.17-rc4-git10-pcie-rme9652/net/ieee80211/softmac/ieee80211softmac_io.c.old 2006-05-12 09:44:47.000000000 +0200
+++ linux-2.6.17-rc4-git10-pcie-rme9652/net/ieee80211/softmac/ieee80211softmac_io.c 2006-05-23 15:16:38.000000000 +0200
@@ -456,31 +456,3 @@
return IEEE80211_2ADDR_LEN;
}
-
-/* Sends a control packet */
-static int
-ieee80211softmac_send_ctl_frame(struct ieee80211softmac_device *mac,
- struct ieee80211softmac_network *net, u32 type, u32 arg)
-{
- void *pkt = NULL;
- u32 pkt_size = 0;
-
- switch(type) {
- case IEEE80211_STYPE_RTS:
- case IEEE80211_STYPE_CTS:
- pkt_size = ieee80211softmac_rts_cts((struct ieee80211_hdr_2addr **)(&pkt), mac, net, type);
- break;
- default:
- printkl(KERN_DEBUG PFX "Unsupported Control Frame type: %i\n", type);
- return -EINVAL;
- }
-
- if(pkt_size == 0)
- return -ENOMEM;
-
- /* Send the packet to the ieee80211 layer for tx */
- ieee80211_tx_frame(mac->ieee, (struct ieee80211_hdr *) pkt, pkt_size);
-
- kfree(pkt);
- return 0;
-}
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Tri-mode or gigebit ethernet support problem in ML403
From: Grant Likely @ 2006-05-23 13:32 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F36C1C973DE890A4541FF9EB29B0@phx.gbl>
On 5/23/06, Ming Liu <eemingliu@hotmail.com> wrote:
> Dear Grant,
Hey Ming, I just saw your repy to Rick from Xilinx. His advice is
better than mine. Listen to him. :)
> First, thanks for your help on my problem.
>
> So you mean, because there is no specific driver for TEMAC included in al=
l
> versions of linux, I must port the driver from the BSP generated by EDK
> into the linux kernel by myself, right? I am sorry that I am a novice in
> linux field and I cannot understand you very well. Could you please give =
me
> more guidance on what shall I do to port the driver, in detail? Do you ha=
ve
> some reference documents for me to do this?
You need some background on writing Linux device drivers:
http://lwn.net/Kernel/LDD3/
Cheers,
g.
--=20
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Tri-mode or gigebit ethernet support problem in ML403
From: Ming Liu @ 2006-05-23 13:25 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0605230553o72bd9d85r6d95580fdaaf9a72@mail.gmail.com>
Dear Grant,
First, thanks for your help on my problem.
So you mean, because there is no specific driver for TEMAC included in all
versions of linux, I must port the driver from the BSP generated by EDK
into the linux kernel by myself, right? I am sorry that I am a novice in
linux field and I cannot understand you very well. Could you please give me
more guidance on what shall I do to port the driver, in detail? Do you have
some reference documents for me to do this?
I really appreciate a lot for your kindly help on my work. Thank you so
much.
Regards
Ming
>From: "Grant Likely" <grant.likely@secretlab.ca>
>To: "Ming Liu" <eemingliu@hotmail.com>
>CC: linuxppc-embedded@ozlabs.org
>Subject: Re: Tri-mode or gigebit ethernet support problem in ML403
>Date: Tue, 23 May 2006 06:53:34 -0600
>
>On 5/23/06, Ming Liu <eemingliu@hotmail.com> wrote:
>>Hi Grant,
>>I want to ask you a problem about the 1000M ethernet support. Now I
>>am
>>trying to integrate a linux (2.4 or 2.6) in my ML403 platform, with
>>tri-mode ethernet support. And I have downloaded many versions of
>>linux,
>>including linuxppc_2_4_devel, MontaVista linux 3.1 Preview
>>Kit(v2.4.20_mvl31-ml300), and linux-xilinx-26. Unfortunately, I
>>didn't find
>>any option in the menuconfig item Network Device Support->ethernet
>>(1000Mbit) for me to enable the 1000M ethernet in all three
>>versions.
>
>I hate to be the bearer of bad news, but AFAIK non of the public
>trees
>have a driver for the TEMAC. Xilinx EDK 8.1 does include drivers
>for
>the TEMAC and it *should* generate a working BSP for MontaVista
>Linux
>3.1 (patched 2.4 kernel). It should also work with the linuxppc-2.4
>tree.
>
>If you want it on a 2.6, you'll need to port the driver.
>Regardless,
>the Xilinx driver code is NOT GPL'd, so beware.
>
>>So I have the following questions to ask.
>>
>>1. With Xilinx Virtex 4 tri-mode ethernet MAC support, which
>>version of
>>Linux shall I use? I think I should choose a version with Xilinx
>>On-chip
>>Ethernet supported in the 1000M ethernet item in menuconfig.
>
>Both Linux 2.4 and 2.6 are usable. You've got some work to do to
>port
>the driver in either case.
>
>>2. Assume that you can provide me a proper version. Shall I use
>>Xilinx EDK
>>to generate the BSP for my platform and copy the source code to
>>overwrite
>>the drivers in the original version. Then configure the kernel and
>>enable
>>1000M ethernet (choose Xilinx on-chip ethernet). Then compile the
>>kernel...... Are these steps correct?
>
>The TEMAC and EMAC are totally different devices, and I haven't
>looked
>to see if TEMAC driver uses the same API, but it is probably a good
>starting point.
>
>Cheers,
>g.
>
>--
>Grant Likely, B.Sc. P.Eng.
>Secret Lab Technologies Ltd.
>grant.likely@secretlab.ca
>(403) 399-0195
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* [PATCH] force 64bit mode in system_reset_fwnmi for broken POWER4 firmware
From: Olaf Hering @ 2006-05-23 13:07 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060522164111.GA14462@suse.de>
On Mon, May 22, Olaf Hering wrote:
> NIP [0000000000003200] 0x3200
> LR [0000000010000338] 0x10000338
The reason is that system_reset_fwnmi is called in 32bit mode. Forcing
64bit mode fixes the corrupt NIP for me. JS20 and p690 are affected,
seems to work on p550 and JS21.
According to this change for EXCEPTION_PROLOG_COMMON, I get still into
decremeter_common, but its not fatal anymore because the cpu is now in
64bit mode and the stack is forced to PACAKSAVE(r13).
subi r1,r1,INT_FRAME_SIZE; /* alloc frame on kernel stack */ \
beq- 1f; \
ld r1,PACAKSAVE(r13); /* kernel stack to use */ \
-1: cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
+1: \
+ cmpdi cr1,r29,0x42; \
+ bne cr1,2f; \
+ li r29,2f@l; \
+2: \
+ cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
bge- cr1,bad_stack; /* abort if it is */ \
std r9,_CCR(r1); /* save CR in stackframe */ \
std r11,_NIP(r1); /* save SRR0 in stackframe */ \
Index: linux-2.6/arch/powerpc/kernel/head_64.S
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/head_64.S
+++ linux-2.6/arch/powerpc/kernel/head_64.S
@@ -211,6 +211,29 @@ exception_marker:
ori reg,reg,(label)@l; /* virt addr of handler ... */
#endif
+#define EXCEPTION_PROLOG_PSERIES_BROKEN_POWER4_FIRMWARE(area, label) \
+ mfspr r13,SPRN_SPRG3; /* get paca address into r13 */ \
+ std r9,area+EX_R9(r13); /* save r9 - r12 */ \
+ std r10,area+EX_R10(r13); \
+ std r11,area+EX_R11(r13); \
+ std r12,area+EX_R12(r13); \
+ mfspr r9,SPRN_SPRG1; \
+ std r9,area+EX_R13(r13); \
+ mfcr r9; \
+ clrrdi r12,r13,32; /* get high part of &label */ \
+ mfmsr r10; \
+ li r11,5; /* MSR_SF_LG|MSR_ISF_LG */ \
+ rldicr r11,r11,61,2; /* (5 << 61) */ \
+ or r10,r10,r11; \
+ mfspr r11,SPRN_SRR0; /* save SRR0 */ \
+ LOAD_HANDLER(r12,label) \
+ ori r10,r10,MSR_IR|MSR_DR|MSR_RI; \
+ mtspr SPRN_SRR0,r12; \
+ mfspr r12,SPRN_SRR1; /* and SRR1 */ \
+ mtspr SPRN_SRR1,r10; \
+ rfid; \
+ b . /* prevent speculative execution */
+
#define EXCEPTION_PROLOG_PSERIES(area, label) \
mfspr r13,SPRN_SPRG3; /* get paca address into r13 */ \
std r9,area+EX_R9(r13); /* save r9 - r12 */ \
@@ -600,14 +623,14 @@ slb_miss_user_pseries:
system_reset_fwnmi:
HMT_MEDIUM
mtspr SPRN_SPRG1,r13 /* save r13 */
- EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, system_reset_common)
+ EXCEPTION_PROLOG_PSERIES_BROKEN_POWER4_FIRMWARE(PACA_EXGEN, system_reset_common)
.globl machine_check_fwnmi
.align 7
machine_check_fwnmi:
HMT_MEDIUM
mtspr SPRN_SPRG1,r13 /* save r13 */
- EXCEPTION_PROLOG_PSERIES(PACA_EXMC, machine_check_common)
+ EXCEPTION_PROLOG_PSERIES_BROKEN_POWER4_FIRMWARE(PACA_EXMC, machine_check_common)
#ifdef CONFIG_PPC_ISERIES
/*** ISeries-LPAR interrupt handlers ***/
^ permalink raw reply
* Re: Tri-mode or gigebit ethernet support problem in ML403
From: Grant Likely @ 2006-05-23 12:53 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F197CC0259C9877D5B47F3B29B0@phx.gbl>
On 5/23/06, Ming Liu <eemingliu@hotmail.com> wrote:
> Hi Grant,
> I want to ask you a problem about the 1000M ethernet support. Now I am
> trying to integrate a linux (2.4 or 2.6) in my ML403 platform, with
> tri-mode ethernet support. And I have downloaded many versions of linux,
> including linuxppc_2_4_devel, MontaVista linux 3.1 Preview
> Kit(v2.4.20_mvl31-ml300), and linux-xilinx-26. Unfortunately, I didn't fi=
nd
> any option in the menuconfig item Network Device Support->ethernet
> (1000Mbit) for me to enable the 1000M ethernet in all three versions.
I hate to be the bearer of bad news, but AFAIK non of the public trees
have a driver for the TEMAC. Xilinx EDK 8.1 does include drivers for
the TEMAC and it *should* generate a working BSP for MontaVista Linux
3.1 (patched 2.4 kernel). It should also work with the linuxppc-2.4
tree.
If you want it on a 2.6, you'll need to port the driver. Regardless,
the Xilinx driver code is NOT GPL'd, so beware.
> So I have the following questions to ask.
>
> 1. With Xilinx Virtex 4 tri-mode ethernet MAC support, which version of
> Linux shall I use? I think I should choose a version with Xilinx On-chip
> Ethernet supported in the 1000M ethernet item in menuconfig.
Both Linux 2.4 and 2.6 are usable. You've got some work to do to port
the driver in either case.
> 2. Assume that you can provide me a proper version. Shall I use Xilinx ED=
K
> to generate the BSP for my platform and copy the source code to overwrite
> the drivers in the original version. Then configure the kernel and enable
> 1000M ethernet (choose Xilinx on-chip ethernet). Then compile the
> kernel...... Are these steps correct?
The TEMAC and EMAC are totally different devices, and I haven't looked
to see if TEMAC driver uses the same API, but it is probably a good
starting point.
Cheers,
g.
--=20
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Fwd: Re: net/ieee80211/softmac/ieee80211softmac_io.c:464: warning: 'ieee80211softmac_send_ctl_frame' defined but not used
From: Johannes Berg @ 2006-05-23 12:55 UTC (permalink / raw)
To: Toralf Förster; +Cc: netdev, linuxppc-dev
In-Reply-To: <200605231445.43205.toralf.foerster@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]
On Tue, 2006-05-23 at 14:45 +0200, Toralf Förster wrote:
> Here is a patch applicable fotr the current git kernel:
Not really. Please read http://linux.yyz.us/patch-format.html
> --- net/ieee80211/softmac/ieee80211softmac_io.c 2006-05-23 14:41:19.000000000
> +0200
> +++ net/ieee80211/softmac/ieee80211softmac_io.c_orig 2006-05-23
It's also the wrong way around.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Problem mapping GPIO regs on ppc440gx
From: Travis B. Sawyer @ 2006-05-23 12:48 UTC (permalink / raw)
To: linuxppc-embedded
Greetings:
We've been using a 2.4.30 kernel (with numerous patches) on a AMCC 440gx
custom built board for quite some time now.
We're building some new hardware that forces us to go to a 2.6 kernel.
So, I've downloaded 2.6.16.16 from kernel.org and am porting everything
forward from our 2.4.30 kernel.
The problem lies in mapping the GPIO regs of the 440 to user space using
/dev/mem:
gpio_fd = open("/dev/mem", O_RDWR | O_SYNC);
if (0 > gpio_fd) {
perror("mbGpioGet(): Unable to open gpio");
return(-1);
}
addr = (ppc440_gpio_regs_t *)mmap(0, getpagesize() * 2,
PROT_READ | PROT_WRITE,
MAP_SHARED, gpio_fd,
(off_t)(0x40000000));
if (MAP_FAILED == addr) {
perror("mbGpioGet(): map error");
close(gpio_fd);
return(-1);
}
pGpioRegs = (ppc440_gpio_regs_t *)((uint32_t)addr + 0x700);
data = pGpioRegs->in & (MB_GPIO_PRI_N_K | MB_GPIO_SEC_PRES_K);
munmap(0, sizeof(ppc440_gpio_regs_t));
close(gpio_fd);
The data I get back is 0. Always. /SEC_PRES_K should be 1 in this case.
(gdb) print /x addr
$7 = 0x30015000
(gdb) print /x pGpioRegs
$8 = 0x30015700
Checking /proc/<PID>/map shows the mapping:
30015000-30019000 rw-p 30015000 00:00 0
On a board running the 2.4.30 kernel, I show the SAME entry in
/proc/<PID>/map
but I do get data back.
Any idea what I'm doing wrong here?
TIA,
Travis Sawyer
^ permalink raw reply
* Fwd: Re: net/ieee80211/softmac/ieee80211softmac_io.c:464: warning: 'ieee80211softmac_send_ctl_frame' defined but not used
From: Toralf Förster @ 2006-05-23 12:45 UTC (permalink / raw)
To: linville; +Cc: netdev, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]
---------- Weitergeleitete Nachricht ----------
Subject: Re: net/ieee80211/softmac/ieee80211softmac_io.c:464:
warning: 'ieee80211softmac_send_ctl_frame' defined but not used
Date: Tuesday 23 May 2006 14:33
From: Johannes Berg <johannes@sipsolutions.net>
To: Toralf Förster <toralf.foerster@gmx.de>
Cc: linuxppc-dev@ozlabs.org
On Mon, 2006-05-22 at 19:48 +0200, Toralf Förster wrote:
> While playing with various kernel config I observed the warning above
> compiling 2.6.17-rc4-git10.
Yeah, known 'bug', we have that code there but never use it. Feel free
to submit a patch (to John Linville, CC netdev and softmac-dev) to
remove it.
johannes
-------------------------------------------------------
Here is a patch applicable fotr the current git kernel:
n22 ~ # cat patch_softmac
--- net/ieee80211/softmac/ieee80211softmac_io.c 2006-05-23 14:41:19.000000000
+0200
+++ net/ieee80211/softmac/ieee80211softmac_io.c_orig 2006-05-23
14:40:44.000000000 +0200
@@ -456,3 +456,31 @@
return IEEE80211_2ADDR_LEN;
}
+
+/* Sends a control packet */
+static int
+ieee80211softmac_send_ctl_frame(struct ieee80211softmac_device *mac,
+ struct ieee80211softmac_network *net, u32 type, u32 arg)
+{
+ void *pkt = NULL;
+ u32 pkt_size = 0;
+
+ switch(type) {
+ case IEEE80211_STYPE_RTS:
+ case IEEE80211_STYPE_CTS:
+ pkt_size = ieee80211softmac_rts_cts((struct
ieee80211_hdr_2addr **)(&pkt), mac, net, type);
+ break;
+ default:
+ printkl(KERN_DEBUG PFX "Unsupported Control Frame type: %i\n",
type);
+ return -EINVAL;
+ }
+
+ if(pkt_size == 0)
+ return -ENOMEM;
+
+ /* Send the packet to the ieee80211 layer for tx */
+ ieee80211_tx_frame(mac->ieee, (struct ieee80211_hdr *) pkt, pkt_size);
+
+ kfree(pkt);
+ return 0;
+}
--
MfG/Sincerely
Toralf Förster
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: net/ieee80211/softmac/ieee80211softmac_io.c:464: warning: 'ieee80211softmac_send_ctl_frame' defined but not used
From: Johannes Berg @ 2006-05-23 12:33 UTC (permalink / raw)
To: Toralf Förster; +Cc: linuxppc-dev
In-Reply-To: <200605221948.09538.toralf.foerster@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 330 bytes --]
On Mon, 2006-05-22 at 19:48 +0200, Toralf Förster wrote:
> While playing with various kernel config I observed the warning above
> compiling 2.6.17-rc4-git10.
Yeah, known 'bug', we have that code there but never use it. Feel free
to submit a patch (to John Linville, CC netdev and softmac-dev) to
remove it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-23 12:27 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <20060522221138.683790c2@diesel>
[-- Attachment #1: Type: text/plain, Size: 3046 bytes --]
On Mon, 2006-05-22 at 22:11 -0500, Hollis Blanchard wrote:
> The "auto-loading" stuff doesn't seem to be working for me on my
> PowerMac11,2, with a fresh git clone as of right now. What is the base
> module that should load all the others? After a "make install", I still
> had to modprobe almost everything by hand (`find ./snd-aoa -name \*.ko`
> in the source directory to get a list).
Odd. i2sbus should pull in all other required modules, and should itself
load automatically at boot due to having a modalias that matches the
of:... modalias the mac-io bus device for the i2s stuff has.
> snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is on it
> snd-aoa-codec-tas: created and attached tas instance
> snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is on it
> snd-aoa-codec-tas: created and attached tas instance
Uh. That one I need to check, there is no tas codec on your machine.
> snd: Unknown layout ID 0x44
That looks like you have snd-powermac loaded too. Or not? I don't think
I have anything that prints "snd:" as the prefix but I might be wrong.
> snd-aoa-fabric-layout: found bus with layout 68 (using)
> snd-aoa: fabric didn't like codec tas
> snd-aoa: fabric didn't like codec tas
> snd-aoa-codec-onyx: found pcm3052
> snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
> snd-aoa: fabric didn't like codec onyx
> snd-aoa-codec-onyx: created and attached onyx instance
> snd-aoa-codec-onyx: found pcm3052
> snd-aoa-fabric-layout: can use this codec
> snd-aoa-codec-onyx: attached to onyx codec via i2c
> snd-aoa-codec-onyx: created and attached onyx instance
Most of this is due to that device-tree bug on those machines.
> For the record, there are two "layout-id" properties in my device tree,
> as discussed in this patch:
> http://patchwork.ozlabs.org/linuxppc/patch?id=4867
Note that the patch is mine :)
But also note that this isn't the reason that there are two layout-id
properties, there really *are* two sound nodes with layout-id property
because there are two i2s busses for the two codecs.
> Ultimately, snd_aoa_codec_onyx seems to be the happy module. Only the
> headphone jack was enabled; I had to use GNOME's "Volume Control" panel
> applet to enable speakers or line out (both of which work).
>
> However, volume control doesn't work at all, for both line-out and
> headphone jacks. Should it?
Yes, it should. I think the bug is that the tas module thinks it can
attach a codec here. Can you try *not* loading that module and see if it
works better then? I'll try to see if I can make the tas module not
attach on those machines, but as long as you don't load it manually all
should be fine.
> Also, it would be helpful if the git tree were better publicized
> somewhere (e.g. http://johannes.sipsolutions.net/). I had to dig through a LOT of mails to find the source.
Sorry. I linked it up on http://johannes.sipsolutions.net/Projects/ and
will add a few more details later.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* [PATCH] make ams work with latest kernels
From: Johannes Berg @ 2006-05-23 11:32 UTC (permalink / raw)
To: Stelian Pop; +Cc: linuxppc-dev list, Linux Kernel list
For those who don't know: ams, written by Stelian Pop, is a driver for
the motion sensor present in some PowerBooks (the series the
PowerBook5,6 falls into, later ones have a slightly different one the
driver doesn't handle).
Even though we still don't seem to have a client that can actually use
this data (something to actually tell the hd to protect itself) I
updated the ams code to compile against the latest linux kernel
versions. I also fixed a buglet (the interrupt handler should return
IRQ_HANDLED even if the init flag isn't set yet since we own the
interrupts, they can't be shared).
Stelian and all, how about adding this driver to linux? hdaps seems to
be there even if it too doesn't serve a useful purpose at this time.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
--- ams-0.02.orig/ams.c 2006-05-22 15:24:51.545837212 +0200
+++ ams-0.02/ams.c 2006-05-22 15:36:10.175837212 +0200
@@ -97,7 +97,7 @@ struct ams {
int irq1; /* first irq line */
int irq2; /* second irq line */
struct work_struct worker; /* worker thread */
- struct input_dev idev; /* input device */
+ struct input_dev *idev; /* input device */
char iactive; /* is the input device active ? */
int xcalib; /* calibrated null value for x */
int ycalib; /* calibrated null value for y */
@@ -110,9 +110,10 @@ static int ams_attach(struct i2c_adapter
static int ams_detach(struct i2c_adapter *adapter);
static struct i2c_driver ams_driver = {
- .owner = THIS_MODULE,
- .name = "ams",
- .flags = I2C_DF_NOTIFY,
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = "ams",
+ },
.attach_adapter = ams_attach,
.detach_adapter = ams_detach,
};
@@ -210,10 +211,10 @@ static int ams_mouse_kthread(void *data)
while (!kthread_should_stop()) {
ams_sensors(&x, &y, &z);
- input_report_abs(&ams.idev, ABS_X, x - ams.xcalib);
- input_report_abs(&ams.idev, ABS_Y, y - ams.ycalib);
+ input_report_abs(ams.idev, ABS_X, x - ams.xcalib);
+ input_report_abs(ams.idev, ABS_Y, y - ams.ycalib);
- input_sync(&ams.idev);
+ input_sync(ams.idev);
msleep(25);
}
@@ -231,22 +232,24 @@ static void ams_mouse_enable(void)
ams.xcalib = x;
ams.ycalib = y;
- init_input_dev(&ams.idev);
- ams.idev.name = "ams";
- ams.idev.dev = &ams.client.dev;
-
- input_set_abs_params(&ams.idev, ABS_X, -50, 50, 3, 0);
- input_set_abs_params(&ams.idev, ABS_Y, -50, 50, 3, 0);
-
- set_bit(EV_ABS, ams.idev.evbit);
- set_bit(EV_KEY, ams.idev.evbit);
- set_bit(BTN_TOUCH, ams.idev.keybit);
+ ams.idev = input_allocate_device();
+ if (!ams.idev)
+ return;
+ ams.idev->name = "Apple Motion Sensor";
+ ams.idev->dev = &ams.client.dev;
+
+ input_set_abs_params(ams.idev, ABS_X, -50, 50, 3, 0);
+ input_set_abs_params(ams.idev, ABS_Y, -50, 50, 3, 0);
+
+ set_bit(EV_ABS, ams.idev->evbit);
+ set_bit(EV_KEY, ams.idev->evbit);
+ set_bit(BTN_TOUCH, ams.idev->keybit);
ams.kthread = kthread_run(ams_mouse_kthread, NULL, "kams");
if (IS_ERR(ams.kthread))
return;
- input_register_device(&ams.idev);
+ input_register_device(ams.idev);
ams.iactive = 1;
}
@@ -257,7 +260,8 @@ static void ams_mouse_disable(void)
kthread_stop(ams.kthread);
- input_unregister_device(&ams.idev);
+ if (ams.idev)
+ input_unregister_device(ams.idev);
ams.iactive = 0;
}
@@ -300,7 +304,7 @@ static void ams_worker(void *data)
static irqreturn_t ams_interrupt(int irq, void *devid, struct pt_regs *regs)
{
if (!ams.init)
- return IRQ_NONE;
+ return IRQ_HANDLED;
schedule_work(&ams.worker);
return IRQ_HANDLED;
}
@@ -471,7 +475,7 @@ static int __init ams_init(void)
INIT_WORK(&ams.worker, ams_worker, NULL);
- if ((ams.of_dev = of_platform_device_create(np, "ams")) == NULL) {
+ if ((ams.of_dev = of_platform_device_create(np, "ams", NULL)) == NULL) {
free_irq(ams.irq1, NULL);
free_irq(ams.irq2, NULL);
return -ENODEV;
^ permalink raw reply
* UART DRIVER on 2.6.15
From: Ladislav Klenovič @ 2006-05-23 12:02 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
just a simple question, is uart driver for kernel 2=2E6=2E15 complete=2E=
=20
There are some parts like:
void scc1_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC1: insert port configuration here */
pinfo->brg =3D 1;
}
=2E=2E=2E=2E
that seems to incomplete=2E Am I able to do something with SCC1 with th=
e current cpm_uart code?
Maybe stupid question, is there any way (is it possible) to import old =
uart driver from kernel 2=2E4=2Ex to kernel 2=2E6=2Ex
Regards,
Ladislav Klenovic
^ permalink raw reply
* Re: CRAMFS: Error -3 while decompressing!
From: Wolfgang Denk @ 2006-05-23 11:04 UTC (permalink / raw)
To: IGOR LURI; +Cc: linuxppc-embedded
In-Reply-To: <918EB199DDDFFA42BEA2EB3A1C6021F3D49640@correo.fagorautomation.net>
In message <918EB199DDDFFA42BEA2EB3A1C6021F3D49640@correo.fagorautomation.net> you wrote:
>
> We would want to use a Compact Flash card with VFAT file system to boot
> our system, so we need to store a linux kernel image and an initrd image
> on it.
Did you read http://www.denx.de/wiki/view/DULG/RootFileSystemInAReadOnlyFile ???
> U-Boot can load linux kernel image and initrd from Compact Flash to RAM.
No need to waste memory on a (big) ramdisk.
> We haven't choose already the initrd file system type, but CRAMFS is an
> option. However, as I mentioned in the previos message, a CRAMFS initrd
> doesn´t boot in our board.
cramfs makes no sense on a ramdisk image. Use ext2.
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
In theory, there is no difference between theory and practice. In
practice, however, there is.
^ permalink raw reply
* RE: CRAMFS: Error -3 while decompressing!
From: IGOR LURI @ 2006-05-23 10:15 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
>What's /dev/rw ???
Is a mistake, the correct argument is root=3D/dev/ram.
We would want to use a Compact Flash card with VFAT file system to boot =
our system, so we need to store a linux kernel image and an initrd image =
on it.
/boot/initrd.img
/boot/vmlinux.img
/custom/ (custom applications)
The contents of this initrd is basically busybox,libraris and device =
files:
/bin/busybox (and simbolik links to busybox) =09
/etc/*
/lib/lib*.so=20
/dev/*
/proc
/mnt/(here goes mounted Compact Flash card )
U-Boot can load linux kernel image and initrd from Compact Flash to RAM. =
Then, when linux boots, we can mount the Compact flash card and execute =
our custom applications.
We haven't choose already the initrd file system type, but CRAMFS is an =
option. However, as I mentioned in the previos message, a CRAMFS initrd =
doesn=B4t boot in our board.
Thanks in advance.
-----Mensaje original-----
De: wd@denx.de [mailto:wd@denx.de]
Enviado el: lunes, 22 de mayo de 2006 22:59
Para: IGOR LURI
CC: linuxppc-embedded@ozlabs.org
Asunto: Re: CRAMFS: Error -3 while decompressing!=20
In message <44718702.1070809@fagorautomation.es> you wrote:
>=20
> We have a mpc5200liteB evaluation board with u-boot 1.1.4 and linux=20
> 2.4.25 from Denx. We have grabed a cramfs root fs on a mtd partition =
> and we are able to boot linux without problems:
...
> However, we are not able to boot linux with the same rootfs image =
(with=20
> the u-boot header) loaded from RAM.
>=20
> setenv bootargs root=3D/dev/rw rw console=3DttyS0 =
console=3DttyS0
> init=3D/sbin/init ip=3Don
What's /dev/rw ???
> and CRAMFS image is built with correct endianess:
Ummm.. Why would you want to use a cramfs file system in a ramdisk
image? This iseems to be a truely pessimal combination of features to
me. Please see
http://www.denx.de/wiki/view/DULG/RootFileSystemDesignAndBuilding for
some hints...
Best regards,
Wolfgang Denk
--=20
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Life sucks, but it's better than the alternative."
- Peter da Silva
^ permalink raw reply
* RE: Setting I&D cache enable in the same mtspr instruction
From: Assaf Hoffman @ 2006-05-23 9:55 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Ronen Shitrit, Rita Shtern, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]
Attached.
Thanks.
-----Original Message-----
From: Mark A. Greer [mailto:mgreer@mvista.com]
Sent: Monday, May 15, 2006 10:00 PM
To: Assaf Hoffman
Cc: linuxppc-embedded@ozlabs.org; Rita Shtern; Ronen Shitrit
Subject: Re: Setting I&D cache enable in the same mtspr instruction
On Mon, May 08, 2006 at 01:39:13PM +0300, Assaf Hoffman wrote:
> Hi,
> I think the implementation of setup_common_caches() in file
> cpu_setup_6xx.S; not according to the spec as far as MPC74xx concerns.
> Looking in the spec (MPC7450 RISC Microprocessor Family Reference
> Manual, MPC7450UM Rev. 5 1/2005) section 3.4.1.5 L1 Instruction and
Data
> Cache Flash Invalidation it says:
> "Note that HID0[ICFI] and HID0[DCFI] must not both be set with the
same
> mtspr instruction, due to the synchronization requirements described
in
> Section 2.4.2.4.1, "Context Synchronization."
> But in the code those two do set together.
> Also, the same section says:
> "An isync must precede the setting of the HID0[ICFI] in order for the
> setting to take effect."
> But in the code, only 'sync' can be found.
>
> /* Enable caches for 603's, 604, 750 & 7400 */
> setup_common_caches:
> mfspr r11,SPRN_HID0
> andi. r0,r11,HID0_DCE
> ori r11,r11,HID0_ICE|HID0_DCE
> ori r8,r11,HID0_ICFI
> bne 1f /* don't invalidate the D-cache
> */
> ori r8,r8,HID0_DCI /* unless it wasn't enabled */
> 1: sync
> mtspr SPRN_HID0,r8 /* enable and invalidate caches
> */
> ^^^^^^^^^^^^^^^^^^^ Here we set both ICFI and DCFI in the same
> mtspr instruction. Also, no isync before setting ICFI.
> sync
> mtspr SPRN_HID0,r11 /* enable caches */
> sync
> isync
> blr
>
> Please advice.
> Thanks.
Yep, looks like a bug. How about a patch? :)
Mark
[-- Attachment #2: cpu_setup_6xx.S --]
[-- Type: application/octet-stream, Size: 10964 bytes --]
/*
* This file contains low level CPU setup functions.
* Copyright (C) 2003 Benjamin Herrenschmidt (benh@kernel.crashing.org)
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
*/
#include <linux/config.h>
#include <asm/processor.h>
#include <asm/page.h>
#include <asm/ppc_asm.h>
#include <asm/cputable.h>
#include <asm/ppc_asm.h>
#include <asm/offsets.h>
#include <asm/cache.h>
_GLOBAL(__setup_cpu_601)
blr
_GLOBAL(__setup_cpu_603)
b setup_common_caches
_GLOBAL(__setup_cpu_604)
mflr r4
bl setup_common_caches
bl setup_604_hid0
mtlr r4
blr
_GLOBAL(__setup_cpu_750)
mflr r4
bl __init_fpu_registers
bl setup_common_caches
bl setup_750_7400_hid0
mtlr r4
blr
_GLOBAL(__setup_cpu_750cx)
mflr r4
bl __init_fpu_registers
bl setup_common_caches
bl setup_750_7400_hid0
bl setup_750cx
mtlr r4
blr
_GLOBAL(__setup_cpu_750fx)
mflr r4
bl __init_fpu_registers
bl setup_common_caches
bl setup_750_7400_hid0
bl setup_750fx
mtlr r4
blr
_GLOBAL(__setup_cpu_7400)
mflr r4
bl __init_fpu_registers
bl setup_7400_workarounds
bl setup_common_caches
bl setup_750_7400_hid0
mtlr r4
blr
_GLOBAL(__setup_cpu_7410)
mflr r4
bl __init_fpu_registers
bl setup_7410_workarounds
bl setup_common_caches
bl setup_750_7400_hid0
li r3,0
mtspr SPRN_L2CR2,r3
mtlr r4
blr
_GLOBAL(__setup_cpu_745x)
mflr r4
#if defined(CONFIG_SMP) && defined(CONFIG_MARVELL)
/* this bits must be set for MP system - see 745x spec */
mfspr r6, HID1
oris r6, r6, 0x3000 // set : EBA and EBD
ori r6, r6, 0x0c00 // set : SyncBE and ABE
mtspr HID1, r6
sync
#endif
bl setup_common_caches
bl setup_745x_specifics
mtlr r4
blr
/* Enable caches for 603's, 604, 750 & 7400 */
setup_common_caches:
mfspr r11,SPRN_HID0
ori r8,r11,HID0_DCE
andi. r0,r11,HID0_DCE
bne 1f /* don't invalidate the D-cache */
ori r8,r8,HID0_DCI /* unless it wasn't enabled */
1: sync
mtspr SPRN_HID0,r8 /* enable and invalidate caches */
sync
ori r8,r11,HID0_ICE|HID0_DCE|HID0_ICFI
isync
sync
mtspr SPRN_HID0,r8 /* enable and invalidate Instruction cache */
sync
blr
/* 604, 604e, 604ev, ...
* Enable superscalar execution & branch history table
*/
setup_604_hid0:
mfspr r11,SPRN_HID0
ori r11,r11,HID0_SIED|HID0_BHTE
ori r8,r11,HID0_BTCD
sync
mtspr SPRN_HID0,r8 /* flush branch target address cache */
sync /* on 604e/604r */
mtspr SPRN_HID0,r11
sync
isync
blr
/* 7400 <= rev 2.7 and 7410 rev = 1.0 suffer from some
* erratas we work around here.
* Moto MPC710CE.pdf describes them, those are errata
* #3, #4 and #5
* Note that we assume the firmware didn't choose to
* apply other workarounds (there are other ones documented
* in the .pdf). It appear that Apple firmware only works
* around #3 and with the same fix we use. We may want to
* check if the CPU is using 60x bus mode in which case
* the workaround for errata #4 is useless. Also, we may
* want to explicitely clear HID0_NOPDST as this is not
* needed once we have applied workaround #5 (though it's
* not set by Apple's firmware at least).
*/
setup_7400_workarounds:
mfpvr r3
rlwinm r3,r3,0,20,31
cmpwi 0,r3,0x0207
ble 1f
blr
setup_7410_workarounds:
mfpvr r3
rlwinm r3,r3,0,20,31
cmpwi 0,r3,0x0100
bnelr
1:
mfspr r11,SPRN_MSSSR0
/* Errata #3: Set L1OPQ_SIZE to 0x10 */
rlwinm r11,r11,0,9,6
oris r11,r11,0x0100
/* Errata #4: Set L2MQ_SIZE to 1 (check for MPX mode first ?) */
oris r11,r11,0x0002
/* Errata #5: Set DRLT_SIZE to 0x01 */
rlwinm r11,r11,0,5,2
oris r11,r11,0x0800
sync
mtspr SPRN_MSSSR0,r11
sync
isync
blr
/* 740/750/7400/7410
* Enable Store Gathering (SGE), Address Brodcast (ABE),
* Branch History Table (BHTE), Branch Target ICache (BTIC)
* Dynamic Power Management (DPM), Speculative (SPD)
* Clear Instruction cache throttling (ICTC)
*/
setup_750_7400_hid0:
mfspr r11,SPRN_HID0
ori r11,r11,HID0_SGE | HID0_ABE | HID0_BHTE | HID0_BTIC
oris r11,r11,HID0_DPM@h
BEGIN_FTR_SECTION
xori r11,r11,HID0_BTIC
END_FTR_SECTION_IFSET(CPU_FTR_NO_BTIC)
BEGIN_FTR_SECTION
xoris r11,r11,HID0_DPM@h /* disable dynamic power mgmt */
END_FTR_SECTION_IFSET(CPU_FTR_NO_DPM)
li r3,HID0_SPD
andc r11,r11,r3 /* clear SPD: enable speculative */
li r3,0
mtspr SPRN_ICTC,r3 /* Instruction Cache Throttling off */
isync
mtspr SPRN_HID0,r11
sync
isync
blr
/* 750cx specific
* Looks like we have to disable NAP feature for some PLL settings...
* (waiting for confirmation)
*/
setup_750cx:
mfspr r10, SPRN_HID1
rlwinm r10,r10,4,28,31
cmpwi cr0,r10,7
cmpwi cr1,r10,9
cmpwi cr2,r10,11
cror 4*cr0+eq,4*cr0+eq,4*cr1+eq
cror 4*cr0+eq,4*cr0+eq,4*cr2+eq
bnelr
lwz r6,CPU_SPEC_FEATURES(r5)
li r7,CPU_FTR_CAN_NAP
andc r6,r6,r7
stw r6,CPU_SPEC_FEATURES(r5)
blr
/* 750fx specific
*/
setup_750fx:
blr
/* MPC 745x
* Enable Store Gathering (SGE), Branch Folding (FOLD)
* Branch History Table (BHTE), Branch Target ICache (BTIC)
* Dynamic Power Management (DPM), Speculative (SPD)
* Ensure our data cache instructions really operate.
* Timebase has to be running or we wouldn't have made it here,
* just ensure we don't disable it.
* Clear Instruction cache throttling (ICTC)
* Enable L2 HW prefetch
*/
setup_745x_specifics:
/* We check for the presence of an L3 cache setup by
* the firmware. If any, we disable NAP capability as
* it's known to be bogus on rev 2.1 and earlier
*/
mfspr r11,SPRN_L3CR
andis. r11,r11,L3CR_L3E@h
beq 1f
lwz r6,CPU_SPEC_FEATURES(r5)
andi. r0,r6,CPU_FTR_L3_DISABLE_NAP
beq 1f
li r7,CPU_FTR_CAN_NAP
andc r6,r6,r7
stw r6,CPU_SPEC_FEATURES(r5)
1:
mfspr r11,SPRN_HID0
/* All of the bits we have to set.....
*/
ori r11,r11,HID0_SGE | HID0_FOLD | HID0_BHTE
ori r11,r11,HID0_LRSTK | HID0_BTIC
oris r11,r11,HID0_DPM@h
BEGIN_FTR_SECTION
xori r11,r11,HID0_BTIC
END_FTR_SECTION_IFSET(CPU_FTR_NO_BTIC)
BEGIN_FTR_SECTION
xoris r11,r11,HID0_DPM@h /* disable dynamic power mgmt */
END_FTR_SECTION_IFSET(CPU_FTR_NO_DPM)
/* All of the bits we have to clear....
*/
li r3,HID0_SPD | HID0_NOPDST | HID0_NOPTI
andc r11,r11,r3 /* clear SPD: enable speculative */
li r3,0
mtspr SPRN_ICTC,r3 /* Instruction Cache Throttling off */
isync
mtspr SPRN_HID0,r11
sync
isync
/* Enable L2 HW prefetch
*/
mfspr r3,SPRN_MSSCR0
ori r3,r3,3
sync
mtspr SPRN_MSSCR0,r3
sync
isync
blr
/*
* Initialize the FPU registers. This is needed to work around an errata
* in some 750 cpus where using a not yet initialized FPU register after
* power on reset may hang the CPU
*/
_GLOBAL(__init_fpu_registers)
mfmsr r10
ori r11,r10,MSR_FP
mtmsr r11
isync
addis r9,r3,empty_zero_page@ha
addi r9,r9,empty_zero_page@l
REST_32FPRS(0,r9)
sync
mtmsr r10
isync
blr
/* Definitions for the table use to save CPU states */
#define CS_HID0 0
#define CS_HID1 4
#define CS_HID2 8
#define CS_MSSCR0 12
#define CS_MSSSR0 16
#define CS_ICTRL 20
#define CS_LDSTCR 24
#define CS_LDSTDB 28
#define CS_SIZE 32
.data
.balign L1_CACHE_LINE_SIZE
cpu_state_storage:
.space CS_SIZE
.balign L1_CACHE_LINE_SIZE,0
.text
/* Called in normal context to backup CPU 0 state. This
* does not include cache settings. This function is also
* called for machine sleep. This does not include the MMU
* setup, BATs, etc... but rather the "special" registers
* like HID0, HID1, MSSCR0, etc...
*/
_GLOBAL(__save_cpu_setup)
/* Some CR fields are volatile, we back it up all */
mfcr r7
/* Get storage ptr */
lis r5,cpu_state_storage@h
ori r5,r5,cpu_state_storage@l
/* Save HID0 (common to all CONFIG_6xx cpus) */
mfspr r3,SPRN_HID0
stw r3,CS_HID0(r5)
/* Now deal with CPU type dependent registers */
mfspr r3,SPRN_PVR
srwi r3,r3,16
cmplwi cr0,r3,0x8000 /* 7450 */
cmplwi cr1,r3,0x000c /* 7400 */
cmplwi cr2,r3,0x800c /* 7410 */
cmplwi cr3,r3,0x8001 /* 7455 */
cmplwi cr4,r3,0x8002 /* 7457 */
cmplwi cr5,r3,0x8003 /* 7447A */
cmplwi cr6,r3,0x7000 /* 750FX */
/* cr1 is 7400 || 7410 */
cror 4*cr1+eq,4*cr1+eq,4*cr2+eq
/* cr0 is 74xx */
cror 4*cr0+eq,4*cr0+eq,4*cr3+eq
cror 4*cr0+eq,4*cr0+eq,4*cr4+eq
cror 4*cr0+eq,4*cr0+eq,4*cr1+eq
cror 4*cr0+eq,4*cr0+eq,4*cr5+eq
bne 1f
/* Backup 74xx specific regs */
mfspr r4,SPRN_MSSCR0
stw r4,CS_MSSCR0(r5)
mfspr r4,SPRN_MSSSR0
stw r4,CS_MSSSR0(r5)
beq cr1,1f
/* Backup 745x specific registers */
mfspr r4,SPRN_HID1
stw r4,CS_HID1(r5)
mfspr r4,SPRN_ICTRL
stw r4,CS_ICTRL(r5)
mfspr r4,SPRN_LDSTCR
stw r4,CS_LDSTCR(r5)
mfspr r4,SPRN_LDSTDB
stw r4,CS_LDSTDB(r5)
1:
bne cr6,1f
/* Backup 750FX specific registers */
mfspr r4,SPRN_HID1
stw r4,CS_HID1(r5)
/* If rev 2.x, backup HID2 */
mfspr r3,SPRN_PVR
andi. r3,r3,0xff00
cmpwi cr0,r3,0x0200
bne 1f
mfspr r4,SPRN_HID2
stw r4,CS_HID2(r5)
1:
mtcr r7
blr
/* Called with no MMU context (typically MSR:IR/DR off) to
* restore CPU state as backed up by the previous
* function. This does not include cache setting
*/
_GLOBAL(__restore_cpu_setup)
/* Some CR fields are volatile, we back it up all */
mfcr r7
/* Get storage ptr */
lis r5,(cpu_state_storage-KERNELBASE)@h
ori r5,r5,cpu_state_storage@l
/* Restore HID0 */
lwz r3,CS_HID0(r5)
sync
isync
mtspr SPRN_HID0,r3
sync
isync
/* Now deal with CPU type dependent registers */
mfspr r3,SPRN_PVR
srwi r3,r3,16
cmplwi cr0,r3,0x8000 /* 7450 */
cmplwi cr1,r3,0x000c /* 7400 */
cmplwi cr2,r3,0x800c /* 7410 */
cmplwi cr3,r3,0x8001 /* 7455 */
cmplwi cr4,r3,0x8002 /* 7457 */
cmplwi cr5,r3,0x8003 /* 7447A */
cmplwi cr6,r3,0x7000 /* 750FX */
/* cr1 is 7400 || 7410 */
cror 4*cr1+eq,4*cr1+eq,4*cr2+eq
/* cr0 is 74xx */
cror 4*cr0+eq,4*cr0+eq,4*cr3+eq
cror 4*cr0+eq,4*cr0+eq,4*cr4+eq
cror 4*cr0+eq,4*cr0+eq,4*cr1+eq
cror 4*cr0+eq,4*cr0+eq,4*cr5+eq
bne 2f
/* Restore 74xx specific regs */
lwz r4,CS_MSSCR0(r5)
sync
mtspr SPRN_MSSCR0,r4
sync
isync
lwz r4,CS_MSSSR0(r5)
sync
mtspr SPRN_MSSSR0,r4
sync
isync
bne cr2,1f
/* Clear 7410 L2CR2 */
li r4,0
mtspr SPRN_L2CR2,r4
1: beq cr1,2f
/* Restore 745x specific registers */
lwz r4,CS_HID1(r5)
sync
mtspr SPRN_HID1,r4
isync
sync
lwz r4,CS_ICTRL(r5)
sync
mtspr SPRN_ICTRL,r4
isync
sync
lwz r4,CS_LDSTCR(r5)
sync
mtspr SPRN_LDSTCR,r4
isync
sync
lwz r4,CS_LDSTDB(r5)
sync
mtspr SPRN_LDSTDB,r4
isync
sync
2: bne cr6,1f
/* Restore 750FX specific registers
* that is restore HID2 on rev 2.x and PLL config & switch
* to PLL 0 on all
*/
/* If rev 2.x, restore HID2 with low voltage bit cleared */
mfspr r3,SPRN_PVR
andi. r3,r3,0xff00
cmpwi cr0,r3,0x0200
bne 4f
lwz r4,CS_HID2(r5)
rlwinm r4,r4,0,19,17
mtspr SPRN_HID2,r4
sync
4:
lwz r4,CS_HID1(r5)
rlwinm r5,r4,0,16,14
mtspr SPRN_HID1,r5
/* Wait for PLL to stabilize */
mftbl r5
3: mftbl r6
sub r6,r6,r5
cmplwi cr0,r6,10000
ble 3b
/* Setup final PLL */
mtspr SPRN_HID1,r4
1:
mtcr r7
blr
^ permalink raw reply
* question about linux with Xilinx ML-403
From: Ming Liu @ 2006-05-23 9:41 UTC (permalink / raw)
To: rick.moleres; +Cc: linuxppc-embedded
Hi Rick,
> Yes, we have a driver for the PLB TEMAC (different than the GSRD LL
> TEMAC) for Linux 2.4 (MontaVista Linux 2.4.20) that's shipped in EDK
> 8.1.1, and MontaVista is on the verge of publishing a driver for PLB
> TEMAC for Linux 2.6. (I believe it came across this mailing list a few
> weeks ago)
I have generated the BSP by EDK 8.1.1 for my project in ML403(hardcore
Temac and PLB Temac included). I noticed that there is a directory called
Xilinx_gige in the directory of /drivers/net. Is this the driver for
MontaVista Linux2.4.20? I copied the BSP and overwrote the original one in
the linux kernel directory (in the kernel directory, there is only a
directory called Xilinx_enet, no Xilinx_gige. So I just copied
Xilinx_gige.). However, my problem is in the menuconfig item of Network
Device Support->1000Mbit ethernet, there is not any option to choose and
enable the Xilinx on-chip ethernet. Is this a problem of MontaVista Linux
3.1 Preview Kit, or my problem? And What shall I do to enable the tri-mode
Temac in my platform? Thanks for your answer.
BR
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ 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