Linux 2.6 8xx kernel booting vs watchdog
On Wed, Jan 12, 2005 at 02:41:18PM -0500, Povolotsky, Alexander wrote: > Hi, > > I wonder if someone could help me with answering couple of my questions: > > How watchdog resetting is handled for PPC > in Linux 2.6 on the kernel level ? > Does one need to add code for it or is it supported "off the shelf" ? It is not supported off the shelf. We (Cyclades) have a timer to periodically touch the watchdog on boot, and afterwards a watchdog driver which gets periodically written by a userspace daemon. I can send a patch if you wish. > Is "early printk" supported for PPC on 2.6 ? > If yes - how and where it could be enabled? Not sure.
8xx-2.6 | Prolog
On Wed, May 26, 2004 at 03:05:31PM +0300, Pantelis Antoniou wrote: > > Hi > > The patches that follow are against the linuxppc-2.5 tree and > are tested to work on my NETTA board. > > Awaiting comments. Excellent, I'll try this out on MPC855T. Should it work? ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Crash on MPC855T with 2.2.14
Hi PPC fellows,
We are facing a crash on high load on our TS console servers (2.2.14 based).
The test used to reproduce the crash involves running SSH connection
attemps in a loop from a fast host. After one or two hours of testing,
the crash happens. Its still possible to ping the box and it answers to
typed keys, but thats all. The kernel is looping in page fault handling
code as following, which has been observed from a BDI2000 and gdb:
(gdb) cont
Continuing.
(locked here, so I type "ctrl+c" on the gdb session).
Program received signal SIGSTOP, Stopped (signal).
local_flush_tlb_page (vma=0xce678200, vmaddr=2147481140) at init.c:549
549 asm volatile ("tlbia" : : );
(gdb) bt
#0 local_flush_tlb_page (vma=0xce678200, vmaddr=2147481140) at init.c:549
#1 0xc0019368 in handle_mm_fault (tsk=0xce95e000, vma=0xce678200,
address=2147481140, write_access=33554432) at memory.c:918
Cannot access memory at address 0xce95fca0
(gdb) cont
Continuing.
And it keeps receiving faults from this address (7634 in this example,
sometimes also 7630), which are part of the process last VMA. Forever.
# cat /proc/1/maps
30023000-30026000 rwxp 00013000 01:00 249/lib/ld-2.1.3.so
30026000-30027000 rwxp 00:00 0
7fffe000-8000 rwxp f000 00:00 0
The "error_code" passed to "do_page_fault" under such endless loop
is either 0xE (14) or 0x8200 (2181038080).
handle_mm_fault trace for such "unsuccessful pte bringup":
#0 handle_mm_fault (tsk=0xce70c000, vma=0xce6188c0, address=2147481140,
write_access=33554432) at memory.c:901
903 if (!pte_present(entry)) {
909 entry = pte_mkyoung(entry);
910 set_pte(pte, entry);
911 flush_tlb_page(vma, address);
912 if (write_access) {
913 if (!pte_write(entry))
303 pte_val(pte) |= _PAGE_DIRTY;
304 if (pte_val(pte) & _PAGE_RW)
305 pte_val(pte) |= _PAGE_HWWRITE;
918 flush_tlb_page(vma, address);
916 entry = pte_mkdirty(entry);
917 set_pte(pte, entry);
918 flush_tlb_page(vma, address);
921 return 1;
I should try to figure out why is it faulting. Maybe the pte
is not being correctly setup.
Any hints are welcome.
/proc/cpuinfo
processor : 0
cpu : 8xx
clock : 48MHz
clock : 48MHz
bus clock : 48MHz
revision: 0.0
bogomips: 47.82
zero pages : total 0 (0Kb) current: 0 (0Kb) hits: 0/124087 (0%)
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Help with crash on MPC855T with 2.2.14
Forgot to mention that same processor (on a similar but not exactly the
same hardware) running v2.4 is not-crashable with the same test.
On Wed, May 26, 2004 at 07:09:54PM -0300, Marcelo Tosatti wrote:
>
> Hi PPC fellows,
>
> We are facing a crash on high load on our TS console servers (2.2.14 based).
>
> The test used to reproduce the crash involves running SSH connection attemps
> in a loop
> from a fast host. After one or two hours of testing, the crash happens. Its
> still
> possible to ping the box and it answers to typed keys, but thats all. The
> kernel is looping
> in page fault handling code as following, which has been observed from a
> BDI2000 and gdb:
>
> (gdb) cont
> Continuing.
>
> (locked here, so I type "ctrl+c" on the gdb session).
>
> Program received signal SIGSTOP, Stopped (signal).
> local_flush_tlb_page (vma=0xce678200, vmaddr=2147481140) at init.c:549
> 549 asm volatile ("tlbia" : : );
> (gdb) bt
> #0 local_flush_tlb_page (vma=0xce678200, vmaddr=2147481140) at init.c:549
> #1 0xc0019368 in handle_mm_fault (tsk=0xce95e000, vma=0xce678200,
> address=2147481140, write_access=33554432) at memory.c:918
> Cannot access memory at address 0xce95fca0
> (gdb) cont
> Continuing.
>
> And it keeps receiving faults from this address (7634 in this example,
> sometimes also 7630), which are part of the process last VMA. Forever.
>
> # cat /proc/1/maps
>
> 30023000-30026000 rwxp 00013000 01:00 249/lib/ld-2.1.3.so
> 30026000-30027000 rwxp 00:00 0
> 7fffe000-8000 rwxp f000 00:00 0
>
> The "error_code" passed to "do_page_fault" under such endless loop
> is either 0xE (14) or 0x8200 (2181038080).
>
> handle_mm_fault trace for such "unsuccessful pte bringup":
>
> #0 handle_mm_fault (tsk=0xce70c000, vma=0xce6188c0, address=2147481140,
> write_access=33554432) at memory.c:901
>
> 903 if (!pte_present(entry)) {
> 909 entry = pte_mkyoung(entry);
> 910 set_pte(pte, entry);
> 911 flush_tlb_page(vma, address);
> 912 if (write_access) {
> 913 if (!pte_write(entry))
> 303 pte_val(pte) |= _PAGE_DIRTY;
> 304 if (pte_val(pte) & _PAGE_RW)
> 305 pte_val(pte) |= _PAGE_HWWRITE;
> 918 flush_tlb_page(vma, address);
> 916 entry = pte_mkdirty(entry);
> 917 set_pte(pte, entry);
> 918 flush_tlb_page(vma, address);
> 921 return 1;
>
> I should try to figure out why is it faulting. Maybe the pte
> is not being correctly setup.
>
> Any hints are welcome.
>
> /proc/cpuinfo
> processor : 0
> cpu : 8xx
> clock : 48MHz
> clock : 48MHz
> bus clock : 48MHz
> revision: 0.0
> bogomips: 47.82
> zero pages : total 0 (0Kb) current: 0 (0Kb) hits: 0/124087 (0%)
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
How to remove JFFS2 'Making dirty' display on RPXlite DW?
On Sat, Aug 07, 2004 at 10:14:11PM +0800, Song Sam wrote: > > David Woodhouse wrote?? > > > > The JFFS2 code in the 2.6 kernel can give about an order of magnitude > > improvement in mount time. It's a lot less na??ve than the 2.4 code. > > Good hints.But 2.6 cannot boot on 8xx via NFS by > now.How can I make a JFFS2?Beats me.Anyway,I will try > it to see how far I would go ... Unfortunately v2.6 does not seem to be working properly on m8xx yet. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
2.4 versus 2.6 patches
On Mon, Jul 26, 2004 at 09:48:47PM +0800, Song Sam wrote: > > --- Eugene Surovegin wrote?? > > > On Mon, Jul 26, 2004 at 12:13:17AM -0400, David > > Woodhouse wrote: > > > > > > On Mon, 26 Jul 2004, [gb2312] Song Sam wrote: > > > > But 2.4 kernel is still a pet for 8xx,at least. I guess many > > > > embedded Linux development lean to 2.4 kernel for the moment.For > > > > Linux kernel hackers,2.4 kernel was dead but it is alive for most > > > > embedded developers.Right? :-) > > > > > > I cannot speak for 'most embedded developers.'; only those with > > > clue. > > Sorry,I got you wrong.I was a little too sensitive to > see 2.4 with "dead".Just gave my opinion on 2.4 kernel > on embedded development. > > > > I would not consider deploying anything new on 2.4 today; it's just > > > not a viable, maintainable platform in my opinion. > > It was really a puzzle for me why 2.4 is NOT a viable, > maintainable platform but it is used more than 2.6.x > in many embedded development.Also why to see 2.4 dying > without leaving the official maintaining work to some > volunteers? Any special reason? I think what David means is that v2.6 is the new platform where all development effort is being done. Most of its core code, in general, is much cleaner than v2.4. I disagree with him when he says "v2.4 is dead" (I coudlnt otherwise :)), because its still maintained and will be for years. And its still in use by a lot of folks. But his point is that new development efforts should be based on the new, shiny, improved v2.6 kernel, since that is where all development is focused at. And as time passes, v2.4 will get more and more obsolete. Unfortunately for 8xx users, as noted by other people on this thread, v2.6 is not yet 100% (wish it was, I'm myself trying to get our boards to boot v2.6). There are some TLB related issue which needs fixing, Panto got a workaround which works for him (while not being fully optimal). Dan Malek and Panto, at least, know exactly what still needs work (unlike me). ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
2.4 versus 2.6 patches
Hi Wolfgang! On Mon, Jul 26, 2004 at 07:16:03PM +0200, Wolfgang Denk wrote: > > In message you > wrote: > > > > Deployment if you're already almost ready to ship is sane enough, I > > suppose -- but to actually put more effort into 2.4 wouldn't make much > > sense. > > It depends on your requirements. > > If you need a kernel that is > (1) stable and working [2.6 is still pretty much useless for example > on 8xx systems], > (2) small [2.6 is usually >= 20% bigger than 2.4], > and/or Even with CONFIG_EMBEDDED or Matt Mackall's -tiny tree? > (3) fast [2.6 is usually >= 10% slower than 2.4], > then 2.4 may be the better choice. Where are you you seeing this slowdown? v2.6 is faster in almost all workloads (it often consumes less memory, VM/FS/core API's are faster, etc). rkload, and we are talking about embedded setups/workloads here. So, I'm sure we should go hunt the slowdowns... At least make the kernel development community known about them. For sure we should make efforts to fix any performance regressions in v2.6. > > Because nobody's really that interested in it. For what it's worth, I've > > abandoned all pretence of continuing to support 2.4 in the MTD/JFFS2 CVS > > David, you can do what you want. But it is not up to you to decide > what other people are doing. I declare that there ARE people who are > interested in 2.4 kernel - both for maintenance and development work. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
2.4 versus 2.6 patches
On Tue, Aug 10, 2004 at 01:58:26PM +0800, Song Sam wrote: > Marcelo Tosatti wrote?? > > I think what David means is that v2.6 is the new > > platform where all development effort is being done. > > Most of its core code, in general, is much cleaner > > than v2.4. > > Thanks for your insight on 2.6 nice characters. > > > I disagree with him when he says "v2.4 is dead" (I > > coudlnt otherwise :)), > > because its still maintained and will be for years. > > And its still in use by a lot of folks. > > Yeah,I am so happy to see v2.4 is still supported > officially.2.4.27 was released a couple of days ago.So > mother tree is alive but ppc child tree was dead. > I wonder if I have a patch vs 2.4 branch on ppc,could > I send to Marcelo Tosatti directly? > > > But his point is that new development efforts should > > be based on the new, shiny, improved v2.6 kernel, > > since that is where all development > > is focused at. And as time passes, v2.4 will get > > more and more obsolete. > > I am looking forward to seeing the day coming. :-) Me too :) > > Unfortunately for 8xx users, as noted by other > > people on this thread, > > v2.6 is not yet 100% (wish it was, I'm myself trying > > to get our boards > > to boot v2.6). > > Could you make it? I once booted v2.6 on RPXlite DW > via ramdisk root file system but failed via NFS. There was an oops at startup, but it reached "VFS: Mounting root" point. It took me almost two weeks to get there. Note our board has quite some specific needs which are not supported in mainline. I plan to send a CONFIG_PRxK (new sub-sub-architecture) to PPC maintainers as soon as I have it clean (its years work of Cyclades programmers work on top of MontaVista work) to support it. Other people seem to get it to boot fully (reported here on the list), but there's still needs work to be done on TLB flushing code (Paul & others discussed this in-depth on the list a month ago or so). ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux 2.6.x on 8xx status
On Mon, Mar 21, 2005 at 04:45:21PM -0500, Guillaume Autran wrote: > Hi, > > Was there any progress made about this issue or is it still pending ? That one is still pending. There are other issues in 8xx which are probably related to it, as follows. > I'm running 2.6.11 and still see the problem... I'm currently trying to understand 8xx cache structure and VM semantics to find out why I'm seeing the following numbers. Test application is: copy 16M from /dev/zero to file-on-RAMDISK, using: # dd if=/dev/zero of=file bs=4k count=3840 v2.6: I-TLB userspace misses: 141264 I-TLB kernel misses: 117455 D-TLB userspace misses: 217590 D-TLB kernel misses: 202677 tlbie: 260 I-TLB userspace misses: 143455 I-TLB kernel misses: 119189 D-TLB userspace misses: 212828 D-TLB kernel misses: 197883 tlbie: 260 I-TLB userspace misses: 142248 I-TLB kernel misses: 118195 D-TLB userspace misses: 217576 D-TLB kernel misses: 202663 tlbie: 260 v2.4: I-TLB userspace misses: 266 I-TLB kernel misses: 5170 D-TLB userspace misses: 3661 D-TLB kernel misses: 177004 tlbie: 162599 I-TLB userspace misses: 266 I-TLB kernel misses: 3183 D-TLB userspace misses: 2024 D-TLB kernel misses: 180178 tlbie: 165675 I'm quite puzzled. Why v2.6 calls the "tlbie" instruction 100-or-so less times than v2.4 ? Paul, Ben? > > Regards, > Guillaume. > > > > Marcelo Tosatti wrote: > > >On Thu, Feb 10, 2005 at 03:06:58PM -0200, Marcelo Tosatti wrote: > > > > > >>On Thu, Feb 10, 2005 at 02:26:52PM -0500, Dan Malek wrote: > >> > >> > >>>On Feb 10, 2005, at 10:04 AM, Marcelo Tosatti wrote: > >>> > >>> > >>> > >>>>Does anyone have a clue of what is/can be wrong with the TLB entry for > >>>>the > >>>>address being flushed at __flush_dcache_icache()? > >>>> > >>>> > >>>Not sure. The problem is that the __flush_dcache_icache is passed a > >>>user space virtual address that doesn't look like it is mapped for > >>>writing > >>>or something. I don't know, as an ooops isn't sufficient to debug the > >>>problem. > >>>You have to catch it here and track down the current state of the TLB > >>>and > >>>the page tables. Of course, when I do this everything looks OK, > >>> > >>> > >>How do you do track down the current TLB state? With a BDI? > >> > >> > >> > >>>so what I've been trying to do is catch the TLBmiss reload that actually > >>>causes this > >>>to happen to see what it really tried to load into the tlb. > >>> > >>> > >>Shouldnt it be loading the TLB entry which "seem to be OK" accordingly to > >>your > >>analysis ?? > >> > >> > > > >So this assumption which you have made sometime ago is wrong, given that > >now you know TLB entry is not stale ? > > > >"The symptom is we appear to have a stale TLB entry, > >so at least one of the callouts from the generic VM > >code isn't doing the right thing for us. I'm still > >puzzled as to why it doesn't affect other PPC processor." > > > >___ > >Linuxppc-embedded mailing list > >Linuxppc-embedded at ozlabs.org > >https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > > > > > > > -- > === > Guillaume Autran > Senior Software Engineer > MRV Communications, Inc. > Tel: (978) 952-4932 office > E-mail: gautran at mrv.com > === >
Linux 2.6.x on 8xx status
On Tue, Mar 22, 2005 at 03:57:08PM -0500, Dan Malek wrote:
>
> On Mar 22, 2005, at 8:04 AM, Marcelo Tosatti wrote:
>
> >I'm quite puzzled. Why v2.6 calls the "tlbie" instruction 100-or-so
> >less times than v2.4 ?
That was rather a _factor_ of "100-or-so" less.
> Oh my ... I'm more worried about the high number of TLB misses
> in 2.6 compared to 2.4. That's really bad.
Newbie question: What prevents the initial kernel map (tuple of 8Mbyte I/D-TLB
entries)
and the IMMR 8Mbyte D-TLB entry from getting unmapped by translation pressure,
in case CONFIG_PIN_TLB is disabled ?
> How did you instrument the tlbie measurement?
By a counter at the end of _tlbie function, similar to other counters which
you suggested.
> It could be that 2.4 used lots more 'tlbia' which were replaced by tlbie in
> 2.6.
Dont think thats the case given that v2.4 calls tlbia through flush_tlb_mm() at
exit_mmap()
only. And at vmalloc_free which shouldnt be called at all.
I just noticed this conditional at switch_mm() (v2.6), which _can_ partly
explain the reduced tlbie's (its just a guess for now, though):
static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
struct task_struct *tsk)
{
#ifdef CONFIG_ALTIVEC
asm volatile (
BEGIN_FTR_SECTION
"dssall;\n"
#ifndef CONFIG_POWER4
"sync;\n" /* G4 needs a sync here, G5 apparently not */
#endif
END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
: : );
#endif /* CONFIG_ALTIVEC */
tsk->thread.pgdir = next->pgd;
/* No need to flush userspace segments if the mm doesnt change */
if (prev == next) <--
return; <--
/* Setup new userspace context */
get_mmu_context(next);
set_context(next->context, next->pgd);
}
I'm about to disable it and retry.
Spent part of the day reading the MMU section of 860 manual, I think I have
kind
of a clue how things are supposed to work at the lowlevel now.
I'll continue tracking it down - any help is appreciated.
PS: I can't reproduce the invalid TLB crash anymore. i.e. even by removing
the _tlbie() at update_mmu_cache() everything is working as expected.
How can I reproduce it again? Guillaume, what kernel version are you using?
Linux 2.6.x on 8xx status
On Tue, Mar 22, 2005 at 05:53:40PM -0500, Dan Malek wrote: > > On Mar 22, 2005, at 12:58 PM, Marcelo Tosatti wrote: > > >Newbie question: What prevents the initial kernel map (tuple of 8Mbyte > >I/D-TLB entries) > >and the IMMR 8Mbyte D-TLB entry from getting unmapped by translation > >pressure, > >in case CONFIG_PIN_TLB is disabled ? > > Nothing. In fact, they are likely invalidated shortly after the kernel > page tables are set up. This was only done to ensure we could get the > kernel initialized without taking page faults. OK. > >By a counter at the end of _tlbie function, similar to other counters > >which > >you suggested. > > OK. > > >Dont think thats the case given that v2.4 calls tlbia through > >flush_tlb_mm() at exit_mmap() > >only. And at vmalloc_free which shouldnt be called at all. > > Hmmm ... Then, the 2.6 looks to be much less efficient with the MMU > resources than 2.4 was. This is going to affect everyone, it's just > easier > to measure on this processor. Many codepaths are longer (eg. but the difference > > >I just noticed this conditional at switch_mm() (v2.6), which _can_ > >partly > >explain the reduced tlbie's (its just a guess for now, though): > > What is your guess? I don't know how this would reduce the number > of tlbie instructions, since stealing a context (as part of > get_context()) > will simply whack the whole TLB with a tlbia. On 8xx, both instructions > could be simply implemented as macros. You misunderstood: get_mmu_context() _wont_ be called if the mm structures are the same. v2.4 didnt had this optimization. > >Spent part of the day reading the MMU section of 860 manual, I think I > >have kind > >of a clue how things are supposed to work at the lowlevel now. > > :-) > > >PS: I can't reproduce the invalid TLB crash anymore. i.e. even by > >removing > >the _tlbie() at update_mmu_cache() everything is working as expected. > > Well, that's interesting. It's likely to only happen on an 860 variant > that > has the large TLB. For what reasoning? > >How can I reproduce it again? Guillaume, what kernel version are you > >using? > > It used to happen on early 2.6 versions as soon as you entered user > space programs. Will let you know of any findings...
Linux 2.6.x on 8xx status
On Wed, Mar 23, 2005 at 11:12:11AM -0500, Dan Malek wrote: > > On Mar 23, 2005, at 5:25 AM, Marcelo Tosatti wrote: > > >You misunderstood: get_mmu_context() _wont_ be called if the mm > >structures > >are the same. > > I understood. At most, get_mmu_context() will only do a 'tlbia' > instruction, I didn't see your reason for thinking this would have > an effect on the tlbie usage. OK. That is not a good reason, indeed. > >>Well, that's interesting. It's likely to only happen on an 860 > >>variant > >>that > >>has the large TLB. > > > >For what reasoning? > > My initial debugging seemed to indicate a stale TLB entry. With > the larger TLB this is more likely to happen. The bug was never > seen on the 823/850 with smaller TLBs. > > I have a new 8xx board now, so I'll have to start working on these > issues as well. OK!
MPC885 CryptoApi support.
On Mon, Mar 21, 2005 at 03:54:39PM -0500, Bruce Donadt wrote: > Guillaume: > > Arabella Software provides asynchronous 2.6 kernel CryptoApi support for the > MPC885 as well as the PowerQUICC II devices as part of our commercially > supported Linux distribution. If you would be interested in a commercial > open source offering, please feel free to contact me and I can provide > further detail. These drivers are not GPL, then?
[PATCH] ppc32: 8xx board-specific platform stuff for fs_enet
On Wed, Nov 30, 2005 at 01:08:31AM -0600, Kumar Gala wrote: > >Hi Kumar, > > > >I dont really know the policy for driver placement, but it seems that > >it works on a case by case basis. > > > >The files in arch/ppc/8xx_io/ (which is what I think you refer to as > >candidates for drivers/), are: > > We have been slowly working on moving drivers out of arch/ppc and > into drivers/ so that subsystem maintainers could get proper review > of them. > > >1) commproc.c > >Basic API for dpram access. Core code. > > > >2) micropatch.c > >microcode update code/data. Core code. > > Well #1 & #2 aren't what I would call drivers at all. I would > consider them syslib/ candidates. Hopefully, someone will Move them there? Yeah... We can add that to the 8xx TODO list if its interesting. > >3) cs4218.h > >4) cs4218_tdm.c > > > >cs4218 does not compile at the moment due to syntatical problems, > >I've fixed them up and the driver compiles, but I don't know > >if it works (patch attached). > > > >I would not be surprised if the driver has been broken since > >long time ago. > > > >Does anyone have hardware to test it? Dan? > > > >Otherwise we should remove it from the tree, since its unmaintained > >and unused. > > If its still good, I would guessing /drivers/audio or snd, but > neither seem to exist. I wondering where sound card drivers live > these days. snd/ I think... Someone needs to test the driver. I think we should just fixup the syntactical problems and mark it as BROKEN until someone (Dan?) confirms it works. > >5) enet.c > >6) fec.c > > > >The ENET/FEC network drivers are obseleted by fs_enet. > > > >However there are some PHY descriptions in fec.c which are missing > >from > >fs_enet - we'd better make sure to have them all in the new driver > >before removing the old one. > > Agreed. > > >Aris, would you mind looking into this? > > > >Once we have that we can set a deadline at Documentation/feature- > >removal.txt > >if desired. > > > >Other than those there are no 8xx drivers in arch/ppc/ AFAIK. > > > > > > Good deal. Are we really removing anything (except maybe cs4218)? FEC certainly and cs4218 seems like a candidate. Thanks for your comments!
INTERACTIVE_CONSOLE for misc-embedded.c and watchdog issue
Hi Tom, On Mon, Nov 28, 2005 at 04:27:38PM -0700, Tom Rini wrote: > On Thu, Nov 17, 2005 at 01:17:30PM -0200, Marcelo Tosatti wrote: > > > The following patch against misc-embedded.c adds an INTERACTIVE_CONSOLE > > #define to guard reading from console (causes unecessary delay in some > > situations). > > > > Its an adaptation of misc.c's define, a difference being that platform > > headers define "NO_INTERACTIVE_CONSOLE" if required. > > > > What do you think? > > Please put a comment above the #ifndef stating where the define should > be. But I have a feeling that's going to be somewhere under > arch/ppc/platforms/ or include/asm-ppc/ and I don't know if that's a > good idea... arch/ppc/platforms/ surely. You have a problem with that? > I've got a vauge idea on how we can handle this a little bit more > cleanly, in the merge tree. How's that? Should I cancel the patch, then?
Failure to boot v2.6.14+ on PPC8xx
Hi, More details on the problem reported earlier. Some change introduced after v2.6.14 makes the "relocate_code" relocate section of arch/ppc/boot/common/util.o disappear. This results in a kernel image with functions at util.o not being part of the relocate section, rendering the system unbootable. Follows relevant output, Debian unstable toolchain (/opt/montavista is a link to the default Debian tools). marcelo at pegasos:~$ gcc -v Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --disable-werror --enable-checking=release powerpc-linux-gnu Thread model: posix gcc version 4.0.2 (Debian 4.0.2-2) marcelo at pegasos:~$ ld -v GNU ld version 2.16.1 Debian GNU/Linux marcelo at pegasos:~/8xx/linux-2.6.14$ /opt/montavista/pro/devkit/ppc/8xx/bin/ppc_8xx-gcc -m32 -Wp,-MD,arch/ppc/boot/common/.util.o.d -nostdinc -isystem /usr/lib/gcc/powerpc-linux-gnu/4.0.2/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Iarch/ppc -Iarch/ppc/include -D__ASSEMBLY__ -Iarch/ppc -c -o arch/ppc/boot/common/util.o arch/ppc/boot/common/util.S marcelo at pegasos:~/8xx/linux-2.6.14$ readelf -a arch/ppc/boot/common/util.o Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 34 000150 00 AX 0 0 1 [ 2] .rela.textRELA 00061c 18 0c 11 1 4 [ 3] .data PROGBITS 000184 04 00 WA 0 0 1 [ 4] .bss NOBITS 000188 00 00 WA 0 0 1 [ 5] .relocate_codePROGBITS 000188 48 00 AX 0 0 1 [ 6] .rela.relocate_co RELA 000634 0c 0c 11 5 4 [ 7] .stab PROGBITS 0001d0 24 0c 9 0 4 [ 8] .rela.stabRELA 000640 18 0c 11 7 4 [ 9] .stabstr STRTAB 0001f4 4e 00 0 0 1 [10] .shstrtab STRTAB 000242 59 00 0 0 1 [11] .symtab SYMTAB 0004a4 f0 10 12 9 4 [12] .strtab STRTAB 000594 88 00 0 0 1 Relocation section '.rela.text' at offset 0x61c contains 2 entries: Offset InfoTypeSym.Value Sym. Name + Addend 0102 0b06 R_PPC_ADDR16_HA timebase_period_ns + 0 0106 0b04 R_PPC_ADDR16_LO timebase_period_ns + 0 Relocation section '.rela.relocate_code' at offset 0x634 contains 1 entries: Offset InfoTypeSym.Value Sym. Name + Addend 0004 0e0a R_PPC_REL24 0028 flush_data_cache + 0 Relocation section '.rela.stab' at offset 0x640 contains 2 entries: Offset InfoTypeSym.Value Sym. Name + Addend 0014 0d01 R_PPC_ADDR32 flush_instruction_cach + 0 0020 0e01 R_PPC_ADDR32 0028 flush_data_cache + 0 There are no unwind sections in this file. Symbol table '.symtab' contains 15 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 FILELOCAL DEFAULT ABS arch/ppc/boot/common/util 2: 0 SECTION LOCAL DEFAULT1 3: 0 SECTION LOCAL DEFAULT3 4: 0 SECTION LOCAL DEFAULT4 5: 00fc 0 NOTYPE LOCAL DEFAULT1 .udelay_not_601 6: 0 SECTION LOCAL DEFAULT5 7: 0 SECTION LOCAL DEFAULT7 8: 0 SECTION LOCAL DEFAULT9 9: 0 NOTYPE GLOBAL DEFAULT1 _setup_L2CR 10: 0080 0 NOTYPE GLOBAL DEFAULT1 _setup_L3CR 11: 0 NOTYPE GLOBAL DEFAULT3 timebase_period_ns 12: 00d0 0 NOTYPE GLOBAL DEFAULT1 udelay 13: 0 NOTYPE GLOBAL DEFAULT5 flush_instruction_cache 14: 0028 0 NOTYPE GLOBAL DEFAULT5 flush_data_cache No version information found in this file. marcelo at pegasos:~/8xx/linux-2.6-git-dec01$ /opt/montavista/pro/devkit/ppc/8xx/bin/ppc_8xx-gcc -m32 -Wp,-MD,arch/ppc/boot/common/.util.o.d -nostdinc -isystem /usr/lib/gcc/powerpc-linux-gnu/4.0.2/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Iarch/ppc -
[PATCH] Support 8xx based Silicon Turnkey XTc
Hi Panto! On Mon, Dec 05, 2005 at 09:15:43PM +0200, Pantelis Antoniou wrote: > Support of Silicon Turnkey's XTc. > > --- > commit fac9bbd80d8f8ab3c6af5a417f804dbf8537c700 > tree 7863f94249651a26ca3eb29aed4c65c214968dda > parent e4f5c82a92c2a546a16af1614114eec19120e40a > author Pantelis Antoniou Mon, 05 Dec 2005 > 21:13:56 +0200 > committer Pantelis Antoniou Mon, 05 Dec 2005 > 21:13:56 +0200 > > arch/ppc/Kconfig |5 > arch/ppc/configs/stxxtc_defconfig | 804 > + > arch/ppc/platforms/Makefile |1 > arch/ppc/platforms/stxxtc.h | 285 + > arch/ppc/platforms/stxxtc_setup.c | 193 + > arch/ppc/syslib/m8xx_setup.c | 14 + > drivers/mtd/maps/Kconfig |6 > drivers/mtd/maps/Makefile |1 > drivers/mtd/maps/stxxtc_nor.c | 326 +++ > drivers/mtd/nand/Kconfig |8 > drivers/mtd/nand/Makefile |1 > drivers/mtd/nand/stxxtc_nand.c| 277 + > include/asm-ppc/mpc8xx.h |4 > 13 files changed, 1922 insertions(+), 3 deletions(-) > > +# CONFIG_PIN_TLB is not set Might want to enable by default? > diff --git a/arch/ppc/platforms/stxxtc.h b/arch/ppc/platforms/stxxtc.h > new file mode 100644 > --- /dev/null > +++ b/arch/ppc/platforms/stxxtc.h > @@ -0,0 +1,285 @@ > +/* > + * A collection of structures, addresses, and values associated with > + * the STXXTC systems. > + * > + * Copyright (c) 2005 Pantelis Antoniou > + *Dan Malek > + * > + */ > +#ifndef __MACH_STXXTC_DEFS > +#define __MACH_STXXTC_DEFS > + > +#include > + > +#ifndef __ASSEMBLY__ > + > +#include > + > +#include > +#include > +#include > +#include > + > +#endif > + > +#define IMAP_ADDR 0xFF00 /* physical base > address of IMMR area */ Extra TAB (or missing tab below, whatever you prefer ;) > +#define IMAP_SIZE(64 * 1024) /* mapped size of IMMR area > */ > + > +/* We don't use the 8259. > +*/ > +#define NR_8259_INTS 0 > + > +#define NAND_SIZE0x0001 > +#define NAND_BASE0xF100 > + > +/*--- > + * PCMCIA stuff > + *--- > + * > + */ > +#define PCMCIA_MEM_SIZE ( 64 << 20 ) > + > +#define MAX_HWIFS 1 /* overwrite default in > include/asm-ppc/ide.h */ > + > +/* > + * Definitions for IDE0 Interface > + */ > +#define IDE0_BASE_OFFSET 0 > +#define IDE0_DATA_REG_OFFSET (PCMCIA_MEM_SIZE + 0x320) > +#define IDE0_ERROR_REG_OFFSET(2 * PCMCIA_MEM_SIZE + 0x320 + > 1) > +#define IDE0_NSECTOR_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + > 2) > +#define IDE0_SECTOR_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + > 3) > +#define IDE0_LCYL_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 4) > +#define IDE0_HCYL_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 5) > +#define IDE0_SELECT_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + > 6) > +#define IDE0_STATUS_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + > 7) > +#define IDE0_CONTROL_REG_OFFSET 0x0106 > +#define IDE0_IRQ_REG_OFFSET 0x000A /* not used > */ > + > +#define IDE0_INTERRUPT 13 > + > +/* XXX FUCK!, for IDE disk set to 0, for normal PCMCIA set to 1 */ > +/* XXX don't ask me why.. */ Can you make the comment a bit nicer? :) > +#if 1 > +/* define IO_BASE for PCMCIA */ > +#define _IO_BASE 0x8000 > +#define _IO_BASE_SIZE (64<<10) > +#endif > + > +/***/ > + > +/* shorthand for the ports data registers */ > +#define PORTA(((volatile immap_t > *)IMAP_ADDR)->im_ioport.iop_padat) > +#define PORTB(((volatile immap_t > *)IMAP_ADDR)->im_cpm.cp_pbdat) > +#define PORTC(((volatile immap_t > *)IMAP_ADDR)->im_ioport.iop_pcdat) > +#define PORTD(((volatile immap_t > *)IMAP_ADDR)->im_ioport.iop_pddat) > +#define PORTE(((volatile immap_t > *)IMAP_ADDR)->im_cpm.cp_pedat) > + > +// > + > +#define PIN_PORT_EQ(p, x)((void *) & x ## _PORT == (void *) & p) > +#define PIN_PORT_NE(p, x)((void *) & x ## _PORT != (void *) & p) > + > +#define PIN_PORT_RW(x) (PIN_PORT_NE(PORTXWO, x) && > PIN_PORT_NE(PORTXRO, x)) > +#define PIN_PORT_RO(x) PIN_PORT_EQ(PORTXRO, x) > +#define PIN_PORT_WO(x) PIN_PORT_EQ(PORTXWO, x) > + > +// > + > +#define PIN_SFT(x) ((sizeof(x ## _PORT) * 8 - 1) - x ## _BIT) > +#define PIN_MSK(x) (1U << PIN_SFT(x)) > + > +/*
[PATCH] ppc32: Adds MPC885ADS, MPC866ADS and MPC8272ADS-specific platform stuff for fs_enet
On Mon, Nov 28, 2005 at 08:00:11PM +0300, Vitaly Bordug wrote:
> Added proper ppc_sys identification and fs_platform_info's for MPC 885ADS,
> 866ADS and 8272ADS. Assuming setbitsXX/clrbitsXX patch is applied.
>
>
> Signed-off-by: Vitaly Bordug
diff --git a/arch/ppc/platforms/mpc8272ads_setup.c
b/arch/ppc/platforms/mpc8272ads_setup.c
new file mode 100644
index 000..4f76b1b
--- /dev/null
+++ b/arch/ppc/platforms/mpc8272ads_setup.c
@@ -0,0 +1,253 @@
+/*
+ * arch/ppc/platforms/82xx/pq2ads_pd.c
+ *
+ * MPC82xx Board-specific PlatformDevice descriptions
+ *
+ * 2005 (c) MontaVista Software, Inc.
+ * Vitaly Bordug
+ *
+ * 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.
+ */
+static int __init mpc8272ads_platform_notify(struct device *dev)
+{
+ static struct {
+ const char *bus_id;
+ void (*rtn) (struct platform_device * pdev, int idx);
+ } dev_map[] = {
+ {"fsl-cpm-fcc", mpc8272ads_fixup_enet_pdata},
+ };
+ struct platform_device *pdev;
+ int i, j, idx;
+ const char *s;
+ if (dev && dev->bus_id)
+ for (i = 0; i < ARRAY_SIZE(dev_map); i++) {
+ idx = -1;
+
+ if ((s = strrchr(dev->bus_id, '.')) != NULL)
+ idx = (int)simple_strtol(s + 1, NULL, 10);
+ else
+ s = dev->bus_id;
+ j = s - dev->bus_id;
+ if (!strncmp(dev->bus_id, dev_map[i].bus_id, j)) {
+ pdev =
+ container_of(dev, struct platform_device,
+dev);
+ dev_map[i].rtn(pdev, idx);
+ }
+ }
+ return 0;
+}
Seems this loop is common to all boards and should be moved to a helper
function?
Denx vs kernel.org
On Tue, Dec 06, 2005 at 10:14:59PM +0100, Wolfgang Denk wrote: > In message <20051206164212.82779.qmail at web33505.mail.mud.yahoo.com> you > wrote: > > I'm looking at embedding linux into a PowerPC-based > > system. I found the DENX website to be very helpful, > > but I'm struggling to understand a few items: > > It would be helpful if you precisely stated which of the misc trees > you are talking about. > > > 1) The source from kernel.org appears to have support > > for the powerpc (arch/powerpc/8xx_io). But when using > > 'make xconfig' I cannot select PowerPC from the list > > of processors. Is this just a limitation on the the > > configuration utility? > > Seems like you are trying to use the linux-2.6-denx tree and forgot > to pass a "ARCH=ppc" argument to "make" (and did not set "ARCH=ppc" > in your shell environment either). > > > 2) What is the difference between the sources on DENX > > and kernel.org? Are there other places where PPC > > We have some stuff added which was submitted as patches to the list > but not all of this has been accepted for or merged into the > kernel.org tree yet. Hi Wolfgang, Is there a list of your fixes anywhere? Is the linux-2.6-denx tree public?
[PATCH] MPC85xx: CPM2 interrupt handler failure after 100, 000 interrupts
Hi Kumar,
Please apply.
From: Edson Seabra <[EMAIL PROTECTED]>
The CPM2 interrupt handler does not return success to the IRQ subsystem, which
causes it to kill the IRQ line after 100,000 interrupts.
[root at KVM ~]# create_cf --doformat --factory_default
...
Copying Linux kernel to /dev/hda1
Initialization of /dev/hda1 done.
Copying RO file system to /dev/hda5
Packing dev done.
Creating directories...
Creating etc... done.
Creating home... done.
Creating root... done.
Creating mnt... done.
Creating var... done.
Creating dev... done.
Creating tmp... done.
Creating proc... done.
Copying directories/files...
Copying bin... done.
Copying sbin... done.
Copying lib... done.
Copying libexec... done.
Copying new_web... done.
Copying opt... done.
Copying usr... done.
Copying COPYRIGHTS...
Error in command: 'cp -a /COPYRIGHTS /mnt/hdPart'
[ 1133.542580] Disabling IRQ #94
May 23 16:59:53 s_kernel at KVM [ 1133.54] irq 94: nobody cared (try
booting with the "irqpoll" option)
May 23 16:59:53 s_kernel at KVM [ 1133.542546] handlers:
May 23 16:59:53 s_kernel at KVM [ 1133.542554] []
(cpm2_cascade+0x0/0x48)
The following patch fixes the problem.
Signed-off-by: Edson Seabra
Signed-off-by: Marcelo Tosatti
RCS file: /usr/cvsroot/oobi_projects/sources/lsp/linux-2.6.14
/arch/ppc/platforms/85xx/mpc85xx_cds_common.c,v
retrieving revision 1.1
retrieving revision 1.4
diff -u -r1.1 -r1.4
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c6 Dec 2005 02:56:21
- 1.1
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c14 Dec 2005 19:32:57
- 1.4
@@ -145,10 +154,11 @@
}
#ifdef CONFIG_CPM2
-static void cpm2_cascade(int irq, void *dev_id, struct pt_regs *regs)
+static int cpm2_cascade(int irq, void *dev_id, struct pt_regs *regs)
{
while((irq = cpm2_get_irq(regs)) >= 0)
__do_IRQ(irq, regs);
+ return(IRQ_HANDLED);
}
static struct irqaction cpm2_irqaction = {
TLB preloading on 8xx
Hi, Been playing with TLB preloading on 8xx for the past weeks, and I must say that results are frustrating. Most of the TLB setup work involves writing to special purpose registers, using "mtspr", which is a serializing instruction (it blocks all execution units). Sum up the costs of disabling interrupts and disabling translation, and you end up with a slow dog. Damn, the TLB exceptions are indeed efficient. The test used to measure pagefault latency is LMbench's "lat_pagefault". vanilla: [root at CAS /]# ./lat_pagefault -N10 out.prof Pagefaults on out.prof: 36.3728 microseconds d-tlb-preload: [root at CAS /]# ./lat_pagefault -N10 out.prof Pagefaults on out.prof: 43.7793 microseconds diff -Nur --exclude-from=linux-2.6-git-dec01/Documentation/dontdiff linux-2.6-git-dec01.orig/arch/ppc/kernel/head_8xx.S linux-2.6-git-dec01/arch/ppc/kernel/head_8xx.S --- linux-2.6-git-dec01.orig/arch/ppc/kernel/head_8xx.S 2005-12-05 09:47:27.0 -0600 +++ linux-2.6-git-dec01/arch/ppc/kernel/head_8xx.S 2005-12-15 12:37:07.449818656 -0600 @@ -804,7 +828,156 @@ SYNC blr + +_GLOBAL(__tlb_data_load) + rlwinm r8, r4, 0, 0, 19/* extract page address */ + ori r8, r8, MD_EVALID /* set valid bit */ + slw r3, r3, 28 + rlwimi r8, r3, 0, 28, 31 /* load ASID from r3 */ +#ifdef CONFIG_8xx_CPU6 + li r9, 0x3780; + stw r9, 4(r7); + lwz r9, 4(r7); +#endif + mtspr SPRN_MD_EPN, r8 + + mfspr r10, SPRN_M_TWB /* Get level 1 table entry address */ + lwz r11, 0(r10) /* Get the level 1 entry */ + ori r11,r11,1 /* Set valid bit */ + + /* Insert the Guarded flag into the TWC from the Linux PTE. + * It is bit 27 of both the Linux PTE and the TWC (at least + * I got that right :-). It will be better when we can put + * this into the Linux pgd/pmd and load it in the operation + * above. + */ + mr r12, r5 + rlwimi r11, r12, 0, 27, 27 + + /* +* Some fields of MD_TWC are cleared by the CPU on a DTLB miss. +* Must do it manually for TLB preload. +* clear 23-26 (access protection group) +* clear 28-29 (page size) and 30 (write-through) +*/ + li r12, 0 + rlwimi r11, r12, 0, 23, 26 + rlwimi r11, r12, 0, 28, 30 +#ifdef CONFIG_8xx_CPU6 + li r9, 0x3b80; + stw r9, 4(r7); + lwz r9, 4(r7); +#endif + mtspr SPRN_MD_TWC, r11/* Set segment attributes */ + + mr r8, r5 + mr r11, r8 + rlwinm r8, r8, 0, 0, 20 + ori r8, r8, 1 /* set valid bit */ + /* Update 'changed', among others. + */ + andi. r11, r11, _PAGE_RW + li r11, 0x00f0 + beq 1f + ori r8, r8, _PAGE_DIRTY|_PAGE_ACCESSED|_PAGE_HWWRITE +// stw r8, 0(r5) /* and update pte in table */ + ori r11, r11, _PAGE_HWWRITE + /* The Linux PTE won't go exactly into the MMU TLB. +* Software indicator bits 21, 22 and 28 must be clear. +* Software indicator bits 24, 25, 26, and 27 must be +* set. All other Linux PTE bits control the behavior +* of the MMU. +*/ +1: + rlwimi r8, r11, 0, 23, 28 /* Set 24-27, clear 28 */ + /* 23 is set if page is _PAGE_RW */ +#ifdef CONFIG_8xx_CPU6 + li r9, 0x3d80; + stw r9, 4(r7); + lwz r9, 4(r7); +#endif + mtspr SPRN_MD_RPN, r8 /* Update TLB entry */ + + mfmsr r11 + lwz r6, 0(r7) /* restore Link Register */ + mtlrr6 + li r6, 0x7fff + rlwimi r11, r6, 0, 27, 27 /* set DR */ + mtmsr r11 + tovirt(r7, r7) + blr + +/* + * Load a D-TLB entry. + * r3: context number + * r4: effective address + * r5: PTE pointer + * r6: PMD (level-1 entry) + * r7: temp location + */ +_GLOBAL(tlb_data_load) + lwz r5, 0(r5) + mflrr6 + stw r6, 0(r7) /* save Link Register */ + mfmsr r11 + li r6, 0 + rlwimi r11, r6, 0, 27, 27 /* clear DR (data translat.)*/ + mtmsr r11 + lis r6, __tlb_data_load at h + ori r6, r6, __tlb_data_load at l + tophys(r7, r7) + mtlrr6 + blr + +/* + * Load a I-TLB entry. + * r3: context number + * r4: effective address + * r5: PTE pointer + * r6: PMD (level-1 entry) + * r7: temp location + */ +_GLOBAL(tlb_instr_load) + rlwinm r8, r4, 0, 0, 19/* extract page address */ + ori r8, r8, MI_EVALID /* set valid bit */ + slw r3, r3, 28 + rlwimi r8, r3, 0, 28, 31 /* load ASID from r3 */ #ifdef CONFIG_8xx_CPU6 +
[PATCH] ppc32 8xx: last two 8MB D-TLB entries are incorrectly set
Hi, The last two 8MB TLB entries are being incorrectly set by initial_mmu on 8xx. The first entry is written with the same virtual/physical address, which renders it invalid: BDI>rms 792 0x1e00 BDI>rms 824 1 BDI>rds 824 SPR 824 : 0xc08000c0 -1065353024 BDI>rds 825 SPR 825 : 0xc0800de0 -1065349664 BDI>rds 826 SPR 826 : 0x0 And the second entry, in addition, does not have its TLB index set correctly. Dan, I'm afraid that, with this problem fixed, the issue you mentioned before with relation to conflicts with the vmalloc space becomes real. * only pin available RAM at initial_mmu, the pinned mappings pointing beyond the end of physical RAM cause conflicts with vmalloc() space. Is there any way to know the RAM size at this point in boot? The bd_t structure is board-specific, so no chance at offseting bd_t to reach the "mem_size" field. I see no improvements with the following patch on 128MB boxen, probably because most referenced kernel data is above 24MB (SLAB caches, etc). But lower mem machines should benefit significantly - anyone willing to do some testing? diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S index de09787..c67cb5c 100644 --- a/arch/ppc/kernel/head_8xx.S +++ b/arch/ppc/kernel/head_8xx.S @@ -733,13 +733,16 @@ initial_mmu: mtspr SPRN_MD_TWC, r9 li r11, MI_BOOTINIT/* Create RPN for address 0 */ addis r11, r11, 0x0080/* Add 8M */ - mtspr SPRN_MD_RPN, r8 + mtspr SPRN_MD_RPN, r11 + + addir10, r10, 0x0100 + mtspr SPRN_MD_CTR, r10 addis r8, r8, 0x0080 /* Add 8M */ mtspr SPRN_MD_EPN, r8 mtspr SPRN_MD_TWC, r9 addis r11, r11, 0x0080/* Add 8M */ - mtspr SPRN_MD_RPN, r8 + mtspr SPRN_MD_RPN, r11 #endif /* Since the cache is enabled according to the information we
[PATCH 1/2] ppc32: Make platform devices being able to assign functions (resend)
Hi Vitaly,
On Wed, Dec 28, 2005 at 11:04:32PM +0300, Vitaly Bordug wrote:
>
> Implemented by modification of the .name field of the platform device,
> when PDs with the
> same names are to be used within different drivers, as
> -> :
> Corresponding drivers should change the .name in struct device_driver to
> reflect upper of course.
I'm not certain that the : structure for sysfs
representation is "allowed" - have you asked GregKH about it?
> Also helper platform_notify_map function added, making assignment of
> board-specific platform_info more consistent and generic.
>
> Signed-off-by: Vitaly Bordug
> ---
>
> arch/ppc/syslib/ppc_sys.c | 165
> -
> include/asm-ppc/mpc10x.h |1
> include/asm-ppc/mpc52xx.h |1
> include/asm-ppc/mpc8260.h |1
> include/asm-ppc/mpc83xx.h |1
> include/asm-ppc/mpc85xx.h |1
> include/asm-ppc/mpc8xx.h |1
> include/asm-ppc/ppc_sys.h | 26 +++
> 8 files changed, 194 insertions(+), 3 deletions(-)
>
> diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
> index c0b93c4..e3856e7 100644
> --- a/arch/ppc/syslib/ppc_sys.c
> +++ b/arch/ppc/syslib/ppc_sys.c
> @@ -15,11 +15,22 @@
> */
>
> #include
> +#include
> #include
>
> int (*ppc_sys_device_fixup) (struct platform_device * pdev);
>
> static int ppc_sys_inited;
> +static int ppc_sys_func_inited;
> +
> +static const char *ppc_sys_func_names[] = {
> + [PPC_SYS_FUNC_DUMMY] = "dummy",
> + [PPC_SYS_FUNC_ETH] = "eth",
> + [PPC_SYS_FUNC_UART] = "uart",
> + [PPC_SYS_FUNC_HLDC] = "hldc",
> + [PPC_SYS_FUNC_USB] = "usb",
> + [PPC_SYS_FUNC_IRDA] = "irda",
> +};
>
> void __init identify_ppc_sys_by_id(u32 id)
> {
> @@ -38,13 +49,13 @@ void __init identify_ppc_sys_by_id(u32 i
> void __init identify_ppc_sys_by_name(char *name)
> {
> unsigned int i = 0;
> - while (ppc_sys_specs[i].ppc_sys_name[0])
> - {
> + while (ppc_sys_specs[i].ppc_sys_name[0]) {
> if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
> break;
> i++;
> }
> cur_ppc_sys_spec = &ppc_sys_specs[i];
> +
> return;
> }
>
> @@ -128,6 +139,153 @@ void ppc_sys_device_remove(enum ppc_sys_
> }
> }
>
> +/* Platform-notify mapping
> + * Helper function for BSP code to assign board-specific platfom-divice
^^^
typo
> bits + */
> +
> +void platform_notify_map(const struct platform_notify_dev_map *map,
> + struct device *dev)
> +{
> + struct platform_device *pdev;
> + int len, idx;
> + const char *s;
> +
> + /* do nothing if no device or no bus_id */
> + if (!dev || !dev->bus_id)
> + return;
> +
> + /* call per device map */
> + while (map->bus_id != NULL) {
> + idx = -1;
> + s = strrchr(dev->bus_id, '.');
> + if (s != NULL)
> + idx = (int)simple_strtol(s + 1, NULL, 10);
> + else
> + s = dev->bus_id;
> +
> + len = s - dev->bus_id;
> +
> + if (!strncmp(dev->bus_id, map->bus_id, len)) {
> + pdev = container_of(dev, struct platform_device,
> dev);
> + map->rtn(pdev, idx);
> + }
> + map++;
> + }
> +}
> +
> +/*
> + Function assignment stuff.
> + Intended to work as follows:
> + the device name defined in foo_devices.c will be concatenated with
> :"func", + where func is string map of respective function from
> platfom_device_func enum
This line looks odd, even though my mailer supposedly breaks it. Can you
format it nicely please?
> +
> + The PPC_SYS_FUNC_DUMMY function is intended to remove all assignments,
> making the device to appear
> + in platform bus with unmodified name.
> + */
> +
> +/*
> + Here we'll replace .name pointers with fixed-lenght strings
> + Hereby, this should be called *before* any func stuff triggeded.
> + */
> +void ppc_sys_device_initfunc(void)
> +{
> + int i;
> + const char *name;
> + static char new_names[NUM_PPC_SYS_DEVS][BUS_ID_SIZE];
> + enum ppc_sys_devices cur_dev;
> +
> + /* If inited yet, do nothing */
> + if (ppc_sys_func_inited)
> + return;
> +
> + for (i = 0; i < cur_ppc_sys_spec->num_devices; i++) {
> + if ((cur_dev = cur_ppc_sys_spec->device_list[i]) < 0)
> + continue;
> +
> + if (ppc_sys_platform_devices[cur_dev].name) {
> + /*backup name */
> + name = ppc_sys_platform_devices[cur_dev].name;
> + strlcpy(new_names[i], name, BUS_ID_SIZE);
> + ppc_sys_platform_devices[cur_dev].name =
> new_names[i];
Did my mailer break this line or the original patch is borked?
> + }
> + }
> +
> + ppc_sys_func_inited = 1;
> +}
> +
> +/*The "engine" of the fun
[PATCH 2/2] ppc32: MPC885ADS, MPC866ADS and MPC8272ADS-specific platform stuff for fs_enet
On Wed, Dec 28, 2005 at 10:23:23PM +0300, Vitaly Bordug wrote: > > Added proper ppc_sys identification and fs_platform_info's for MPC 885ADS, > 866ADS and 8272ADS, utilizing function assignment to remove/do not use > platform devices which conflict with PD-incompatible drivers. > > Signed-off-by: Vitaly Bordug > --- > > arch/ppc/Kconfig | 47 > arch/ppc/platforms/Makefile |4 > arch/ppc/platforms/fads.h |2 > arch/ppc/platforms/mpc8272ads_setup.c | 236 > arch/ppc/platforms/mpc866ads_setup.c | 270 +++ > arch/ppc/platforms/mpc885ads_setup.c | 387 > + > arch/ppc/platforms/pq2ads.h |4 > arch/ppc/platforms/pq2ads_pd.h| 114 ++ > arch/ppc/syslib/ppc_sys.c |4 > drivers/base/platform.c |2 > 10 files changed, 1066 insertions(+), 4 deletions(-) > > diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig > index cc3f64c..ac32793 100644 > --- a/arch/ppc/Kconfig > +++ b/arch/ppc/Kconfig > @@ -506,6 +506,53 @@ config WINCEPT > > endchoice > > +menu "Freescale Ethernet driver platform-specific options" > + depends on FS_ENET > + > + config MPC8xx_SECOND_ETH > + bool "Second Ethernet channel" > + depends on (MPC885ADS || MPC86XADS) > + default y > + help > + This enables support for second Ethernet on MPC885ADS and > MPC86xADS boards. > + The latter will use SCC1, for 885ADS you can select it below. > + > + choice > + prompt "Second Ethernet channel" > + depends on MPC8xx_SECOND_ETH > + default MPC8xx_SECOND_ETH_FEC2 > + > + config MPC8xx_SECOND_ETH_FEC2 > + bool "FEC2" > + depends on MPC885ADS > + help > + Enable FEC2 to serve as 2-nd Ethernet channel. Note that > SMC2 > + (often 2-nd UART) will not work if this is enabled. > + > + config MPC8xx_SECOND_ETH_SCC1 > + bool "SCC1" > + depends on MPC86XADS > + select MPC8xx_SCC_ENET_FIXED > + help > + Enable SCC1 to serve as 2-nd Ethernet channel. Note that > SMC1 > + (often 1-nd UART) will not work if this is enabled. > + > + config MPC8xx_SECOND_ETH_SCC3 > + bool "SCC3" > + depends on MPC885ADS > + help > + Enable SCC3 to serve as 2-nd Ethernet channel. Note that > SMC1 > + (often 1-nd UART) will not work if this is enabled. > + > + endchoice > + > + config MPC8xx_SCC_ENET_FIXED > + depends on MPC8xx_SECOND_ETH_SCC > + default n > + bool "Use fixed MII-less mode for SCC Ethernet" > + > +endmenu > + > choice > prompt "Machine Type" > depends on 6xx || POWER3 || POWER4 > diff --git a/arch/ppc/platforms/Makefile b/arch/ppc/platforms/Makefile > index 7c5cdab..ee50b0d 100644 > --- a/arch/ppc/platforms/Makefile > +++ b/arch/ppc/platforms/Makefile > @@ -22,6 +22,8 @@ ifeq ($(CONFIG_PPC_PMAC),y) > obj-$(CONFIG_NVRAM) += pmac_nvram.o > obj-$(CONFIG_CPU_FREQ_PMAC) += pmac_cpufreq.o > endif > + > +obj-$(CONFIG_ADS8272)+= mpc8272ads_setup.o > obj-$(CONFIG_PMAC_BACKLIGHT) += pmac_backlight.o > obj-$(CONFIG_PREP_RESIDUAL) += residual.o > obj-$(CONFIG_PQ2ADS) += pq2ads.o > @@ -45,6 +47,8 @@ obj-$(CONFIG_SBC82xx) += sbc82xx.o > obj-$(CONFIG_SPRUCE) += spruce.o > obj-$(CONFIG_LITE5200) += lite5200.o > obj-$(CONFIG_EV64360)+= ev64360.o > +obj-$(CONFIG_MPC86XADS) += mpc866ads_setup.o > +obj-$(CONFIG_MPC885ADS) += mpc885ads_setup.o > > ifeq ($(CONFIG_SMP),y) > obj-$(CONFIG_PPC_PMAC) += pmac_smp.o > diff --git a/arch/ppc/platforms/fads.h b/arch/ppc/platforms/fads.h > index a48fb8d..e1c0b1b 100644 > --- a/arch/ppc/platforms/fads.h > +++ b/arch/ppc/platforms/fads.h > @@ -112,7 +112,7 @@ > > /* CPM Ethernet through SCC1 or SCC2 */ > > -#ifdef CONFIG_SCC1_ENET /* Probably 860 variant */ > +#if defined(CONFIG_SCC1_ENET) || defined(CONFIG_MPC8xx_SECOND_ETH_SCC1) /* > Probably 860 variant */ > /* Bits in parallel I/O port registers that have to be set/cleared > * to configure the pins for SCC1 use. > * TCLK - CLK1, RCLK - CLK2. > diff --git a/arch/ppc/platforms/mpc8272ads_setup.c > b/arch/ppc/platforms/mpc8272ads_setup.c > new file mode 100644 > index 000..e45b91a > --- /dev/null > +++ b/arch/ppc/platforms/mpc8272ads_setup.c > @@ -0,0 +1,236 @@ > +/* > + * arch/ppc/platforms/82xx/pq2ads_pd.c > + * > + * MPC82xx Board-specific PlatformDevice descriptions > + * > + * 2005 (c) MontaVista Software, Inc. > + * Vitaly Bordug > + * > + * 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 > + *
[PATCH 2/2] ppc32: MPC885ADS, MPC866ADS and MPC8272ADS-specific platform stuff for fs_enet(resend)
> diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
> index e3856e7..9182a36 100644
> --- a/arch/ppc/syslib/ppc_sys.c
> +++ b/arch/ppc/syslib/ppc_sys.c
> @@ -238,7 +238,7 @@ void ppc_sys_device_setfunc(enum ppc_sys
> else
> *s = 0;
> } else if (func != PPC_SYS_FUNC_DUMMY) {
> - /* do assignment if it is not just "enable" request */
> + /* do assignment if it is not just "clear" request */
> sprintf(tmp, "%s:%s", name, ppc_sys_func_names[func]);
> strlcpy(name, tmp, BUS_ID_SIZE);
> }
> @@ -294,7 +294,7 @@ static int __init ppc_sys_init(void)
>
> for (i = 0; i < cur_ppc_sys_spec->num_devices; i++) {
> dev_id = cur_ppc_sys_spec->device_list[i];
> - if ((dev_id != -1) ||
> + if ((dev_id != -1) &&
> (cur_ppc_sys_spec->config[dev_id] & PPC_SYS_CONFIG_ENABED)) {
> if (ppc_sys_device_fixup != NULL)
> ppc_sys_device_fixup(&ppc_sys_platform_devices
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 8827daf..ce551b5 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -266,7 +266,7 @@ int platform_device_add(struct platform_
> }
> }
>
> - pr_debug("Registering platform device '%s'. Parent at %s\n",
> + pr_info("Registering platform device '%s'. Parent at %s\n",
>pdev->dev.bus_id, pdev->dev.parent->bus_id);
>
> ret = device_register(&pdev->dev);
Suppose that all this hunks belong to a different patch?
[PATCH 1/2] ppc32: Make platform devices being able to assign functions (resend)
On Thu, Dec 29, 2005 at 12:54:12PM -0700, Grant Likely wrote: > Marcelo Tosatti wrote: > > Hi Vitaly, > > > > On Wed, Dec 28, 2005 at 11:04:32PM +0300, Vitaly Bordug wrote: > > > >>Implemented by modification of the .name field of the platform device, > >>when PDs with the > >>same names are to be used within different drivers, as > >> -> : > >>Corresponding drivers should change the .name in struct device_driver to > >>reflect upper of course. > > > > > > I'm not certain that the : structure for sysfs > > representation is "allowed" - have you asked GregKH about it? > > > > > He didn't seem to have any problem with it when we talked about it at > OLS. Also, ':' is already used by the PCI bus driver. Look in > /sys/class/pci_bus. Fine then, thanks Grant.
[PATCH] powerpc: generalize PPC44x_PIN_SIZE
Hi,
The following patch generalizes PPC44x_PIN_SIZE by changing it to
PPC_PIN_SIZE, which can be defined by any board to automatically adjust
VMALLOC_START, avoiding conflicts with pinned virtual space.
Also define it for 8xx.
Matt, please review.
diff --git a/arch/ppc/mm/44x_mmu.c b/arch/ppc/mm/44x_mmu.c
index 3d79ce2..e0152a9 100644
--- a/arch/ppc/mm/44x_mmu.c
+++ b/arch/ppc/mm/44x_mmu.c
@@ -104,7 +104,7 @@ unsigned long __init mmu_mapin_ram(void)
/* Determine number of entries necessary to cover lowmem */
pinned_tlbs = (unsigned int)
- (_ALIGN(total_lowmem, PPC44x_PIN_SIZE) >> PPC44x_PIN_SHIFT);
+ (_ALIGN(total_lowmem, PPC_PIN_SIZE) >> PPC44x_PIN_SHIFT);
/* Write upper watermark to save location */
tlb_44x_hwater = PPC44x_LOW_SLOT - pinned_tlbs;
@@ -112,7 +112,7 @@ unsigned long __init mmu_mapin_ram(void)
/* If necessary, set additional pinned TLBs */
if (pinned_tlbs > 1)
for (i = (PPC44x_LOW_SLOT-(pinned_tlbs-1)); i <
PPC44x_LOW_SLOT; i++) {
- unsigned int phys_addr = (PPC44x_LOW_SLOT-i) *
PPC44x_PIN_SIZE;
+ unsigned int phys_addr = (PPC44x_LOW_SLOT-i) *
PPC_PIN_SIZE;
ppc44x_pin_tlb(i, phys_addr+PAGE_OFFSET, phys_addr);
}
diff --git a/include/asm-ppc/ibm44x.h b/include/asm-ppc/ibm44x.h
index f835066..3acc382 100644
--- a/include/asm-ppc/ibm44x.h
+++ b/include/asm-ppc/ibm44x.h
@@ -29,7 +29,7 @@
/* TLB entry offset/size used for pinning kernel lowmem */
#define PPC44x_PIN_SHIFT 28
-#define PPC44x_PIN_SIZE(1 << PPC44x_PIN_SHIFT)
+#define PPC_PIN_SIZE (1 << PPC44x_PIN_SHIFT)
/* Lowest TLB slot consumed by the default pinned TLBs */
#define PPC44x_LOW_SLOT63
diff --git a/include/asm-ppc/mpc8xx.h b/include/asm-ppc/mpc8xx.h
index 46f159c..73ec9a6 100644
--- a/include/asm-ppc/mpc8xx.h
+++ b/include/asm-ppc/mpc8xx.h
@@ -113,6 +113,8 @@ enum ppc_sys_devices {
MPC8xx_CPM_USB,
};
+#define PPC_PIN_SIZE (24 * 1024 * 1024) /* 24Mbytes of data pinned */
+
#ifndef BOARD_CHIP_NAME
#define BOARD_CHIP_NAME ""
#endif
diff --git a/include/asm-ppc/pgtable.h b/include/asm-ppc/pgtable.h
index 6d1c39e..3f8c38e 100644
--- a/include/asm-ppc/pgtable.h
+++ b/include/asm-ppc/pgtable.h
@@ -12,6 +12,7 @@
#include /* For TASK_SIZE */
#include
#include
+#include/* For sub-arch specific PPC_PIN_SIZE */
struct mm_struct;
extern unsigned long va_to_phys(unsigned long address);
@@ -127,9 +128,8 @@ extern unsigned long ioremap_bot, iorema
* of RAM. -- Cort
*/
#define VMALLOC_OFFSET (0x100) /* 16M */
-#ifdef CONFIG_44x
-#include
-#define VMALLOC_START (((_ALIGN((long)high_memory, PPC44x_PIN_SIZE) +
VMALLOC_OFFSET) & ~(VMALLOC_OFFSET-1)))
+#ifdef PPC_PIN_SIZE
+#define VMALLOC_START (((_ALIGN((long)high_memory, PPC_PIN_SIZE) +
VMALLOC_OFFSET) & ~(VMALLOC_OFFSET-1)))
#else
#define VMALLOC_START long)high_memory + VMALLOC_OFFSET) &
~(VMALLOC_OFFSET-1)))
#endif
[PATCH] ppc32 8xx: last two 8MB D-TLB entries are incorrectly set
On Thu, Dec 22, 2005 at 05:52:21PM -0200, Marcelo Tosatti wrote: > Hi, > > The last two 8MB TLB entries are being incorrectly set by initial_mmu on 8xx. > > The first entry is written with the same virtual/physical address, which > renders it invalid: > > BDI>rms 792 0x1e00 > BDI>rms 824 1 > BDI>rds 824 > SPR 824 : 0xc08000c0 -1065353024 > BDI>rds 825 > SPR 825 : 0xc0800de0 -1065349664 > BDI>rds 826 > SPR 826 : 0x0 > > And the second entry, in addition, does not have its TLB index set > correctly. > > Dan, I'm afraid that, with this problem fixed, the issue you mentioned > before with relation to conflicts with the vmalloc space becomes real. > > * only pin available RAM at initial_mmu, the pinned mappings pointing > beyond the end of physical RAM cause conflicts with vmalloc() space. > > Is there any way to know the RAM size at this point in boot? The bd_t > structure is board-specific, so no chance at offseting bd_t to reach the > "mem_size" field. None of this is necessary, we only need to define VMALLOC_START such that it won't conflict with pinned space, as the Book-E 44x port already does.
[PATCH] Use 8MB D-TLB entries for kernel static mapping
Hi, The following patch implements support for instantiation of 8MB D-TLB entries for the kernel direct virtual mapping on 8xx, thus reducing TLB space consumed for the kernel. Test used: writing 40MB from /dev/zero to file in ext2fs over RAMDISK. $ time dd if=/dev/zero of=file bs=4k count=1 VANILLA 8MB kernel data pages real0m11.485s real0m11.267s user0m0.218suser0m0.250s sys 0m8.939ssys 0m9.108s real0m11.518s real0m10.978s user0m0.203suser0m0.222s sys 0m9.585ssys 0m9.138s real0m11.554s real0m10.967s user0m0.228suser0m0.222s sys 0m9.497ssys 0m9.127s real0m11.633s real0m11.286s user0m0.214suser0m0.196s sys 0m9.529ssys 0m9.134s and averages for both: real11.54750real 11.12450 Which is a 3.6% improvement in execution time. More improvement is expected for loads with larger kernel data footprint (real workloads). Dan, could you please review the code. diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S index de09787..fe25f3f 100644 --- a/arch/ppc/kernel/head_8xx.S +++ b/arch/ppc/kernel/head_8xx.S @@ -375,6 +375,14 @@ DataStoreTLBMiss: lis r11, swapper_pg_dir at h ori r11, r11, swapper_pg_dir at l rlwimi r10, r11, 0, 2, 19 + stw r12, 16(r0) + mflrr12 + stw r12, 20(r0) /* save LR */ + lis r3, LoadLargeDTLB at h + ori r3, r3, LoadLargeDTLB at l + tophys (r3, r3) + mtlrr3 + blr 3: lwz r11, 0(r10) /* Get the level 1 entry */ rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address */ @@ -430,6 +438,83 @@ DataStoreTLBMiss: InstructionTLBError: b InstructionAccess +LoadLargeDTLB: + li r12, 0 + lwz r11, 0(r10) /* Get the level 1 entry */ + rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address */ + beq 3f /* If zero, don't try to find a pte */ + + /* We have a pte table, so load fetch the pte from the table. +*/ + ori r11, r11, 1 /* Set valid bit in physical L2 page */ + DO_8xx_CPU6(0x3b80, r3) + mtspr SPRN_MD_TWC, r11/* Load pte table base address */ + mfspr r10, SPRN_MD_TWC/* and get the pte address */ + lwz r10, 0(r10) /* Get the pte */ + + /* Insert the Guarded flag into the TWC from the Linux PTE. +* It is bit 27 of both the Linux PTE and the TWC (at least +* I got that right :-). It will be better when we can put +* this into the Linux pgd/pmd and load it in the operation +* above. +*/ + rlwimi r11, r10, 0, 27, 27 + + rlwimi r12, r10, 0, 0, 9 /* extract phys. addr */ + mfspr r3, SPRN_MD_EPN + rlwinm r3, r3, 0, 0, 9 /* extract virtual address */ + tophys(r3, r3) + cmpwr3, r12 /* only use 8M page if it is a direct + kernel mapping */ + bne 1f + ori r11, r11, MD_PS8MEG + li r12, 1 + b 2f +1: + li r12, 0 /* can't use 8MB TLB, so zero r12. */ +2: + DO_8xx_CPU6(0x3b80, r3) + mtspr SPRN_MD_TWC, r11 + + /* The Linux PTE won't go exactly into the MMU TLB. +* Software indicator bits 21, 22 and 28 must be clear. +* Software indicator bits 24, 25, 26, and 27 must be +* set. All other Linux PTE bits control the behavior +* of the MMU. +*/ +3: li r11, 0x00f0 + rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */ + cmpwi r12, 1 + bne 4f + ori r10, r10, 0x8 + + mfspr r12, SPRN_MD_EPN + lis r3, 0xff80 /* 10-19 must be clear for 8MB TLB */ + ori r3, r3, 0x0fff + and r12, r3, r12 + DO_8xx_CPU6(0x3780, r3) + mtspr SPRN_MD_EPN, r12 + + lis r3, 0xff80 /* 10-19 must be clear for 8MB TLB */ + ori r3, r3, 0x0fff + and r10, r3, r10 +4: + DO_8xx_CPU6(0x3d80, r3) + mtspr SPRN_MD_RPN, r10/* Update TLB entry */ + + mfspr r10, SPRN_M_TW /* Restore registers */ + lwz r11, 0(r0) + mtcrr11 + lwz r11, 4(r0) + + lwz r12, 20(r0) + mtlrr12 /* Restore LR */ + lwz r12, 16(r0) +#ifdef CONFIG_8xx_CPU6 + lwz r3, 8(r0) +#endif + rfi + /* This is the data TLB error on the MPC8xx. This could be due to * many reasons, including a dirty update to a pte. We can catch that * one here, but anything else is an error. First, we track down the
Linux 2.6 sources for MPC852T processor
On Wed, Apr 26, 2006 at 07:32:13PM -0400, Dan Malek wrote: > > On Apr 26, 2006, at 7:50 AM, David Jander wrote: > > > Yes, MPC852T is supported, although I might add that I have been > > using 2.6.14 > > and 2.6.15 sucessfully with our own MPC852T-based board, but 2.6.16 > > did not > > boot and as of today I don't know why, or whether this is an issue > > at all > > with boards other than ours. > > There is a horrible bug in the 8xx TLB miss handler that is in the > 2.6.16 > sources. I don't know when it appeared. Enable the CPU6 Errata > workaround to see if that solves the problem and please report back > to me. I'm working on a solution. Hi Dan, Shame on me! I screwed up. David, can you please try the following patch on top of vanilla v2.6.16? The large TLB change introduced in v2.6.16 (which is broken as is for configurations without CPU6 errata enabled as Dan noted) should boost performance significantly, so you might want to rerun the lmbench tests... diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S index ec53c7d..7a2f205 100644 --- a/arch/ppc/kernel/head_8xx.S +++ b/arch/ppc/kernel/head_8xx.S @@ -355,9 +355,7 @@ #endif . = 0x1200 DataStoreTLBMiss: -#ifdef CONFIG_8xx_CPU6 stw r3, 8(r0) -#endif DO_8xx_CPU6(0x3f80, r3) mtspr SPRN_M_TW, r10 /* Save a couple of working registers */ mfcrr10 @@ -417,9 +415,7 @@ #endif lwz r11, 0(r0) mtcrr11 lwz r11, 4(r0) -#ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) -#endif rfi /* This is an instruction TLB error on the MPC8xx. This could be due
[PATCH] ppc32 8xx: Fix r3 thrashing due to 8MB TLB page instantiation (!CONFIG_8xx_CPU6)
(please ignore last patch, its incomplete) Instantiation of 8MB pages on the TLB cache for the kernel static mapping thrashes r3 register on !CONFIG_8xx_CPU6 configurations. Signed-off-by: Marcelo Tosatti diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S index ec53c7d..09b3adc 100644 --- a/arch/ppc/kernel/head_8xx.S +++ b/arch/ppc/kernel/head_8xx.S @@ -355,9 +355,7 @@ #endif . = 0x1200 DataStoreTLBMiss: -#ifdef CONFIG_8xx_CPU6 stw r3, 8(r0) -#endif DO_8xx_CPU6(0x3f80, r3) mtspr SPRN_M_TW, r10 /* Save a couple of working registers */ mfcrr10 @@ -417,9 +415,7 @@ #endif lwz r11, 0(r0) mtcrr11 lwz r11, 4(r0) -#ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) -#endif rfi /* This is an instruction TLB error on the MPC8xx. This could be due @@ -500,9 +496,7 @@ LoadLargeDTLB: lwz r11, 4(r0) lwz r12, 16(r0) -#ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) -#endif rfi /* This is the data TLB error on the MPC8xx. This could be due to
[PATCH] ppc32 8xx: Fix r3 thrashing due to 8MB TLB page instantiation (!CONFIG_8xx_CPU6)
Instantiation of 8MB pages on the TLB cache for the kernel static mapping thrashes r3 register on !CONFIG_8xx_CPU6 configurations. Signed-off-by: Marcelo Tosatti diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S index ec53c7d..7a2f205 100644 --- a/arch/ppc/kernel/head_8xx.S +++ b/arch/ppc/kernel/head_8xx.S @@ -355,9 +355,7 @@ #endif . = 0x1200 DataStoreTLBMiss: -#ifdef CONFIG_8xx_CPU6 stw r3, 8(r0) -#endif DO_8xx_CPU6(0x3f80, r3) mtspr SPRN_M_TW, r10 /* Save a couple of working registers */ mfcrr10 @@ -417,9 +415,7 @@ #endif lwz r11, 0(r0) mtcrr11 lwz r11, 4(r0) -#ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) -#endif rfi /* This is an instruction TLB error on the MPC8xx. This could be due
PPC 405GPr support in linux 2.4.32
On Thu, Apr 27, 2006 at 11:32:45AM -0700, Stephen Williams wrote: > Eugene Surovegin wrote: > > There are bigger problems with 4xx support in 2.4 mainline than just > > missing some chips support. > > > > Some parts which are already in 2.4 (e.g. ethernet driver) are of > > non-production quality. > > > > I can imagine Marcelo agreeing to commit 405GPr/405EP support as this > > change shouldn't break anything, but this will not make 2.4 support > > really useful for real world deployments. I think we are stuck with > > maintaining our own 2.4 trees with backports from 2.6. This is what I > > do myself of all our products (and yeah, diff between stock 2.4.32 and > > my internal version has already grown quite big to be acceptable for > > 2.4 inclusion). > > > > Of course we are going to have to keep our own per-board trees. > but the blatantly common stuff, like the core 405gpr support and > certain drivers, might as well go in if the gatekeeper can be > convinced. You and I both probably have huge drivers for custom > devices hanging off our PPCs, with various hacks to squeeze extra > performance out. These make our transition to 2.6 difficult, and > surely we are not alone. > > So 2.4 is going to be around for a while longer for us, so we might > as well make an effort to keep the house in some sort of order. It > serves no one to keep these fixes a secret:-) > > In any case, if the patches I sent are rejected, then that's that. > We'll see. Folks, The v2.4 patch acceptance policy has been shifting gradually from "accept new features" to "critical fixes only", and at this point in time the goal is to have a minimal amount of modifications as possible. There should be no need for major patch reworking with reference to new v2.4 releases. Willy Tarreau created a repository of useful v2.4 patches for this sort of situations. Stephen, Eugene, I think the 405GPr patches are good candidates. http://w.ods.org/linux/kernel/2.4/lkup/hardware.html Of course that it would be incredibly better for everyone to be happy with v2.6. I see a lot of embedded users complaining about v2.6. Cyclades (my former employer) has been using v2.6 in production environments with 48MHz MPC855T PPC's with no problems at all (actually, it is faster in certain key situations). This boxes have 128MB, which is can be considered large, but still, no major problems have been seen in _several_ different v2.6 versions.
SCCx UART status on 8xx
Aris,
Can you please prepare a detailed description of what the
patch is doing and why?
Thanks
On Mon, Feb 20, 2006 at 11:18:35AM -0300, Aristeu Sergio Rozanski Filho wrote:
> Index: stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> ===
> --- stable.orig/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17
> 17:11:37.0 -0200
> +++ stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c2006-02-17
> 17:15:57.0 -0200
> @@ -139,24 +139,31 @@
> void scc1_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC1: insert port configuration here */
> + cpmp->cp_sicr &= 0xFFC0;
> pinfo->brg = 1;
> }
>
> void scc2_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC2: insert port configuration here */
> + cpmp->cp_sicr &= 0xC0FF;
> + cpmp->cp_sicr |= 0x0900;
> pinfo->brg = 2;
> }
>
> void scc3_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC3: insert port configuration here */
> + cpmp->cp_sicr &= 0xFFC0;
> + cpmp->cp_sicr |= 0x0014;
> pinfo->brg = 3;
> }
>
> void scc4_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC4: insert port configuration here */
> + cpmp->cp_sicr &= 0xC0FF;
> + cpmp->cp_sicr |= 0x1BFF;
> pinfo->brg = 4;
> }
>
> Index: stable/drivers/serial/cpm_uart/cpm_uart_core.c
> ===
> --- stable.orig/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-07
> 15:30:42.0 -0200
> +++ stable/drivers/serial/cpm_uart/cpm_uart_core.c2005-12-08
> 12:39:11.0 -0200
> @@ -467,6 +467,7 @@
> /* free interrupt handler */
> free_irq(port->irq, port);
>
> +#if 0
> /* If the port is not the console, disable Rx and Tx. */
> if (!(pinfo->flags & FLAG_CONSOLE)) {
> /* Wait for all the BDs marked sent */
> @@ -492,6 +493,7 @@
> /* Shut them really down */
> cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
> }
> +#endif
> }
>
> static void cpm_uart_set_termios(struct uart_port *port,
> @@ -896,7 +898,7 @@
> pinfo->sccp->scc_gsmrl &= ~(SCC_GSMRL_ENR | SCC_GSMRL_ENT);
> }
>
> - ret = cpm_uart_allocbuf(pinfo, 0);
> + ret = cpm_uart_allocbuf(pinfo, 1);
>
> if (ret)
> return ret;
> @@ -912,10 +914,12 @@
>
> static void cpm_uart_release_port(struct uart_port *port)
> {
> +#if 0
> struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
>
> if (!(pinfo->flags & FLAG_CONSOLE))
> cpm_uart_freebuf(pinfo);
> +#endif
> }
>
> /*
CONFIG_PIN_TLB experiments
Hi 8xx folks, I've been testing the CONFIG_PIN_TLB option under v2.6, results are not good. The 8Mbyte TLB entries do not seem to work as expected, they do not cover the regions which they claim to. Accesses inside the region covered by pinned 8Mb TLB result in pagefaults and 4kb entries getting created. Actually, CONFIG_PIN_TLB slowdowns the system, as expected (there are only 28 usable TLB's instead of 32). v2.6 CONFIG_PIN_TLB: I-TLB userspace misses: 162113 I-TLB kernel misses: 135911 D-TLB userspace misses: 289452 D-TLB kernel misses: 257039 v2.6 without CONFIG_PIN_TLB: I-TLB userspace misses: 160828 I-TLB kernel misses: 134746 D-TLB userspace misses: 253557 D-TLB kernel misses: 227383 The following BDI output shows the pinned, 8MByte data page mapping present, at 0xc000. BDI>rds 826 SPR 826 : 0x7f0032512 BDI>rms 792 0x0c001C00 BDI>rms 824 1 BDI>rds 824 SPR 824 : 0xc0f0 -1073741584 BDI>rds 825 SPR 825 : 0x0fe0 4064 BDI>rds 826 SPR 826 : 0x7fff32767 <- "0x7fff" was 0x7f00" initially. I tried enabling usermode access without success. There are several 4Kb mappings inside the range covered by this 8Mb TLB entry, for example: BDI>rms 792 0x0c000200 BDI>rms 824 1 BDI>rds 824 SPR 824 : 0xc0224f17 -1071493353 BDI>rds 825 SPR 825 : 0x002241e0 2245088 BDI>rds 826 SPR 826 : 0x7f0032512 And more, without so much detail: SPR 824 : 0xc0224f17 -1071493353 SPR 824 : 0xc01fbf17 -1071661289 SPR 824 : 0xc0246f17 -1071354089 SPR 824 : 0xc023ff17 -1071382761 SPR 824 : 0xc7e35f17 - 941400297 SPR 824 : 0xc0244f17 -1071362281 SPR 824 : 0xc023ef17 -1071386857 Note that protection (SPR 826) is exactly the same as the 8Mbyte page protection. Why is the translation mechanism rejection the pinned mappings? Dan, have you ever seen this work? Am I misunderstanding how the pinned entries are supposed to work?
CONFIG_PIN_TLB experiments
Hi, On Tue, May 03, 2005 at 11:14:39AM -0700, Conn Clark wrote: > Marcelo Tosatti wrote: > >Hi 8xx folks, > > > > > > >Actually, CONFIG_PIN_TLB slowdowns the system, as expected (there are only > >28 usable TLB's instead of 32). > > > > > >v2.6 CONFIG_PIN_TLB: > >I-TLB userspace misses: 162113 > >I-TLB kernel misses: 135911 > >D-TLB userspace misses: 289452 > >D-TLB kernel misses: 257039 > > > >v2.6 without CONFIG_PIN_TLB: > >I-TLB userspace misses: 160828 > >I-TLB kernel misses: 134746 > >D-TLB userspace misses: 253557 > >D-TLB kernel misses: 227383 > > > > > > Considering that the TLB kernel misses are higher with tlb pinning it > appears as though the pinned TLBs are not marked as valid. Yep > > >The following BDI output shows the pinned, 8MByte data page mapping > >present, > >at 0xc000. > > > >BDI>rds 826 > >SPR 826 : 0x7f0032512 > >BDI>rms 792 0x0c001C00 > >BDI>rms 824 1 > >BDI>rds 824 > >SPR 824 : 0xc0f0 -1073741584 > >BDI>rds 825 > >SPR 825 : 0x0fe0 4064 > >BDI>rds 826 > >SPR 826 : 0x7fff32767 <- "0x7fff" was 0x7f00" > >initially. I tried enabling > > usermode access without > > success. > > > >There are several 4Kb mappings inside the range covered by this 8Mb TLB > >entry, for example: > > > >BDI>rms 792 0x0c000200 > >BDI>rms 824 1 > >BDI>rds 824 > >SPR 824 : 0xc0224f17 -1071493353 > >BDI>rds 825 > >SPR 825 : 0x002241e0 2245088 > >BDI>rds 826 > >SPR 826 : 0x7f0032512 > > > >And more, without so much detail: > >SPR 824 : 0xc0224f17 -1071493353 > >SPR 824 : 0xc01fbf17 -1071661289 > >SPR 824 : 0xc0246f17 -1071354089 > >SPR 824 : 0xc023ff17 -1071382761 > >SPR 824 : 0xc7e35f17 - 941400297 > >SPR 824 : 0xc0244f17 -1071362281 > >SPR 824 : 0xc023ef17 -1071386857 > > > >Note that protection (SPR 826) is exactly the same as the 8Mbyte page > >protection. > >Why is the translation mechanism rejection the pinned mappings? > > > >Dan, have you ever seen this work? Am I misunderstanding how the pinned > >entries are supposed to work? > > When you load the Mx_EPN of the pinned area is the EV bit being set? Yep. "MD_RAM1" (SPR 826) is set: SPR 826 : 0x7fff32767 <- "0x7fff" was 0x7f00" Bits 17 and 18 are set. Their meaning is: "Change bit for DTLB entry" and "Entry valid flag" respectively. Bits 19...23 are also set, they represent supervisor access. Note that bit 23 "supervisor access type" is set: 0 is read-only, 1 is read-write. so everything looks OK here. "MD_RAM0": SPR 825 : 0x0fe0 4064 Bits 20...26 are set. 20-22: 8Mbyte page set. 23-26: APGI (access protection group in 1's complement) set. It is zero ( in 1's complement). 27: guarded memory not set. "MD_CAM": SPR 824 : 0xc0f0 -1073741584 Bits 24-27 are set. 24-26 is "page size" (111 = 8Mb) and 27 indicates "shared page" (ASID comparisong disabled). The 8Mbyte page is used at boot, from "start_here" until "MMU_init()" gets called... The manual says, section "9.3 Address Translation" "When TLB logic detects that a new effective page number (EPN) overlaps one in the TLB (when taking into account page sizes, subpage validity flags, user/supervisor state, etc. the new EPN is written and the old one is invalidated." I'm trying to boot a kernel which does not create kernel pte's from 0xc00 till 0xc08.
CONFIG_PIN_TLB experiments
> >>When you load the Mx_EPN of the pinned area is the EV bit being set? > > > > > >Yep. > > > > > >"MD_RAM1" (SPR 826) is set: > > > >SPR 826 : 0x7fff32767 <- "0x7fff" was 0x7f00" > > > >Bits 17 and 18 are set. Their meaning is: "Change bit for DTLB entry" and > >"Entry valid flag" respectively. > >Bits 19...23 are also set, they represent supervisor access. Note that > >bit 23 "supervisor access type" is set: 0 is read-only, 1 is read-write. > > > >so everything looks OK here. > > > >"MD_RAM0": > > > >SPR 825 : 0x0fe0 4064 > > > >Bits 20...26 are set. > > > >20-22: 8Mbyte page set. > >23-26: APGI (access protection group in 1's complement) set. It is > >zero ( in 1's complement). > >27: guarded memory not set. > > > >"MD_CAM": > > > >SPR 824 : 0xc0f0 -1073741584 > > > >Bits 24-27 are set. > > > >24-26 is "page size" (111 = 8Mb) and 27 indicates "shared page" > >(ASID comparisong disabled). > > > >The 8Mbyte page is used at boot, from "start_here" until "MMU_init()" > >gets called... > > > >The manual says, section "9.3 Address Translation" > > > >"When TLB logic detects that a new effective page number (EPN) overlaps > >one in the TLB (when taking into account page sizes, subpage validity > >flags, > >user/supervisor state, etc. the new EPN is written and the old one is > >invalidated." > > > >I'm trying to boot a kernel which does not create kernel pte's > >from 0xc00 till 0xc08. > > > > Well, looking at the sources I currently have, 2.6.8 and 2.4.27, I > noticed that InstructionTLBMiss in 2.6 is missing some ifdefs that the > 2.4 has that pertain to TLB pinning. Otherwise the code appears > basically the same. Hi Conn, Those changes shouldnt be pertinent... I believeCONFIG_PIN_TLB never worked on 2.4 either.
[PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
Hi,
As can be seen by BDI output from previous messages, the 8Mbyte TLB
pinned entry is not being actually used.
The manual says, in section "9.3.2 Translation Enabled" (MMU section):
"A TLB hit in multiple entries is avoided when a TLB is being reloaded.
When TLB logic detects that a new effective page number (EPN) overlaps
one in the TLB (when taking into account pages sizes, subpage validity,
user/supervisor state, address space ID,and the SH values of the TLB
entries), the new EPN is written and the old one is invalidated."
The following patch changes "mmu_mapin_ram" (hook used by mapin_ram), to
begin creation of pagetables after the first 8Megs, preserving the
8Mbyte TLB entry.
This changes the assumption that DMA allocations can start at the first
kernel address, given that those need to be marked uncached due to DMA
cache coherency issues.
The bootmem allocator, used to allocate DMA regions at bootup,uses
MAX_DMA_ADDRESS as its goal parameter. The algorithm searches for
pages above 'goal' first, for then to search lower pages.
So change MAX_DMA_ADDRESS to avoid bootmem collisions with lower 8Megs.
Drivers which allocate directly from __get_free_pages() and tweak the
pte's directly also need to be fixed. For example
Panto: FEC currently does
mem_addr = __get_free_page(GFP_KERNEL);
cbd_base = (cbd_t *)mem_addr;
/* XXX: missing check for allocation failure */
fec_uncache(mem_addr);
That needs to be changed to avoid the lower 8Megs.
We are still using v2.4 FEC driver, so this fixed it:
// mem_addr = __get_free_page(GFP_KERNEL);
mem_addr = dma_alloc_coherent(NULL, PAGE_SIZE, &physaddr,
GFP_KERNEL);
cbd_base = (cbd_t *)mem_addr;
Allocateing from the coherent memory DMA region. Which sits at, I suppose,
after initial 8Megs in all configurations (should be always).
TLB miss stat output now looks like this on 2.6.11:
[root at CAS root]# time dd if=/dev/zero of=file bs=4k count=3840
3840+0 records in
3840+0 records out
real0m3.723s
user0m0.150s
sys 0m3.560s
I-TLB userspace misses: 1904
I-TLB kernel misses: 0
D-TLB userspace misses: 160272
D-TLB kernel misses: 135098
instead of
[root at CAS root]# time dd if=/dev/zero of=file bs=4k count=3840
3840+0 records in
3840+0 records out
real0m4.328s
user0m0.128s
sys 0m4.170s
I-TLB userspace misses: 162651
I-TLB kernel misses:138100
D-TLB userspace misses: 255294
D-TLB kernel misses:238129
Dan: Maybe the pinning should be mandatory, getting rid of CONFIG_PIN_TLB?
diff -Nur --show-c-function linux-2.6.12-rc3.orig/arch/ppc/mm/mmu_decl.h
linux-2.6.12-rc3/arch/ppc/mm/mmu_decl.h
--- linux-2.6.12-rc3.orig/arch/ppc/mm/mmu_decl.h2005-05-05
17:21:55.0 -0300
+++ linux-2.6.12-rc3/arch/ppc/mm/mmu_decl.h 2005-05-05 17:31:20.0
-0300
@@ -49,7 +49,8 @@ extern unsigned long Hash_size, Hash_mas
#if defined(CONFIG_8xx)
#define flush_HPTE(X, va, pg) _tlbie(va)
#define MMU_init_hw() do { } while(0)
-#define mmu_mapin_ram()(0UL)
+/* There is a 8Mbyte pinned TLB entry covering the first 8Megs, so skip it */
+#define mmu_mapin_ram()(0x0080)
#elif defined(CONFIG_4xx)
#define flush_HPTE(X, va, pg) _tlbie(va)
diff -Nur --show-c-function linux-2.6.12-rc3.orig/include/asm-ppc/dma.h
linux-2.6.12-rc3/include/asm-ppc/dma.h
--- linux-2.6.12-rc3.orig/include/asm-ppc/dma.h 2005-05-05 17:21:59.0
-0300
+++ linux-2.6.12-rc3/include/asm-ppc/dma.h 2005-05-05 17:53:07.0
-0300
@@ -32,9 +32,16 @@
#define MAX_DMA_CHANNELS 8
#endif
+#ifdef CONFIG_8xx
+/* DMA pages are uncached on 8xx due to cache coherency issues.
+* Avoid bootmem from trying to allocate pages from first 8Megs.
+*/
+#define MAX_DMA_ADDRESS(KERNELBASE + 0x0100)
+#else
/* The maximum address that we can perform a DMA transfer to on this platform
*/
/* Doesn't really apply... */
#define MAX_DMA_ADDRESS0x
+#endif
/* in arch/ppc/kernel/setup.c -- Cort */
extern unsigned long DMA_MODE_WRITE, DMA_MODE_READ;
[PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
On Fri, May 06, 2005 at 09:04:24AM -0400, Jason McMullan wrote: > On Thu, 2005-05-05 at 14:20 -0300, Marcelo Tosatti wrote: > > [snip snip] > > > > Allocateing from the coherent memory DMA region. Which sits at, I suppose, > > after initial 8Megs in all configurations (should be always). > > > > > What if your board (ie the MPC885ADS) only has 8Mb? Soldered on. Jason, Oops, in that case you can't pin the 8Mbyte entry.
[PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
> >The following patch changes "mmu_mapin_ram" (hook used by mapin_ram), > >to > >begin creation of pagetables after the first 8Megs, preserving the > >8Mbyte TLB entry. > > Please don't do this. It isn't necessary. Why it is not necessary? Have you read the section of the manual which I pasted here? > >This changes the assumption that DMA allocations can start at the first > >kernel address, given that those need to be marked uncached due to DMA > >cache coherency issues. > > VM space for uncached DMA has always been allocated using vmalloc(), > the location of the physical pages backing this space is irrelevant. > > The only thing you have to ensure is the virtual address is outside > of the pinned entry. What you replied to is: "This changes the assumption that DMA allocations can start at the first kernel address, given that those need to be marked uncached due to DMA cache coherency issues." I think we mean the same, yes? > If something about the way the VM space is structured in 2.6 is > different, we need to fix that in general. > > >Panto: FEC currently does > > > >mem_addr = __get_free_page(GFP_KERNEL); > >cbd_base = (cbd_t *)mem_addr; > > This is just plain broken and it shouldn't do this. > > >We are still using v2.4 FEC driver, so this fixed it: > > > >// mem_addr = __get_free_page(GFP_KERNEL); > >mem_addr = dma_alloc_coherent(NULL, PAGE_SIZE, &physaddr, > >GFP_KERNEL); > > This is the proper way, and should be moved to the equivalent in 2.6. > > >Allocateing from the coherent memory DMA region. Which sits at, I > >suppose, > >after initial 8Megs in all configurations (should be always). > > You are making this too complicated :-) All we have to do is use the > proper dma allocators and make sure the TLBs are pinned properly. > That is all. Sorry, but, what is too complicated? The patch I sent does two things (pretty much the same thing you suggest after stating that its "too complicated", AFAICS): 1) avoids the creation of pte tables in the 8Mbyte range, thus preserving the pinned TLB entry. 2) restricts bootmem to above 8Mbyte region And last thing is: 3) Memory for DMA pages must not be in the pinned region. ie. drivers should not allocate memory directly for DMA purposes. Dan, I would really enjoy having access to some of your precious 8xx knowledge: share it, along with the correct way to fix this and the other pending issues.
How to fix 8xx dcbst bug?
Hi Dan, So, restarting this conversation... On Tue, Apr 05, 2005 at 11:58:17AM -0400, Dan Malek wrote: > > On Apr 4, 2005, at 3:17 PM, Marcelo Tosatti wrote: > > >Problem is that the "dcbst" instruction will, _sometimes_ (the > >failure/success rate is about 1/4 > >with my test application) fault as a _write_ operation on the data. > > Oh, geeze It's all coming back to me now > > The 8xx cache operations don't always operate as defined in the PEM. > There are likely to be some archive discussions within the Freescale > knowledge data base that describe the different behaviors I've seen > with the chip variants and revisions. I can't find any of those e-mail > discussions, so I'll try to recall from memory. > > The PEM cache instructions are all implemented in a microcode that > uses the 8xx unique cache control SPRs. Depending upon the state > of the cache and MMU, it seems in some cases the EA translation is > subject to a "normal" protection match instead of a load operation > match. > > The behavior of these operations isn't consistent across all of the 8xx > processor revisions, especially with early silicon if people are still > using those. During conversations with Freescale engineers, it seems > the only guaranteed operation was to use the 8xx unique SPRs, but > I think I only did that in 8xx specific functions. > > We have way too much code in the TLB exception handlers already, > so let's just try a tlbia of the EA in the update_mmu_cache, with an > #ifdef > for the 8xx. > We may want to make the dcbxxx instructions > some > kind of macro, so on 8xx we can include such operations in otherwise > "standard" software. Now that I think of it, userspace dcbst users should not be an issue because the intermediate invalid TLB entry is not visible to applications. Userspace sees only: not present pte, or valid present pte. Well, at least the entry which has been causing problems, created by DataStoreTLBMiss. Is it safe to assume that dcbst usage on userspace is restricted to valid TLBs? Since MMU SPRs are restricted to supervisor protection, I think so. So, if that is true, can you please merge the update_mmu_cache() fix for the dcbst misbehaviour previously discussed ? Thanks!!
[PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
Hi Dan,
On Fri, May 06, 2005 at 06:49:11PM -0400, Dan Malek wrote:
>
> On May 6, 2005, at 9:38 AM, Marcelo Tosatti wrote:
>
> >1) avoids the creation of pte tables in the 8Mbyte range, thus
> >preserving
> >the pinned TLB entry.
>
> This has nothing to do with "preserving" the pinned TLB entry.
> The pinned entries are placed into the reserved portion of the TLB,
> and are never evicted.
OK.
> We never get a fault on these pages, so wenever look up an
> entry in the page table.
The data I have tells me otherwise. I have seen the I-TLB entries
getting created for kernel space.
I did the following:
- insert a break at the beginning of start_kernel, another break at
the end of start_kernel.
- boot, BDI stops at start_kernel.
- dump I-TLB contents, no entries for "start_kernel" pages on I-TLB.
- "go".
- BDI stops at the end of start_kernel.
- dump I-TLB contents, see the 4kb entries for "start_kernel" I-cache
there (ie we _do_ get faults on these pages).
Check it out.
If your setup is not working yet I can get the data for you tomorrow.
> We need to create the
> page tables for informational purposes, so software or debugger
> lookups will do the right thing.
Can't the BDI work on the 8Mbyte page? Same for other software
or debuggers...
Any in-kernel algorithm which relies on direct pte manipulation
looks fragile...
i386 and some (?) other architectures do use big pages for the first
kernel addresses, right?
> >2) restricts bootmem to above 8Mbyte region
>
> Why is this necessary?
void __init
m8xx_setup_arch(void)
{
int cpm_page;
cpm_page = (int) alloc_bootmem_pages(PAGE_SIZE);
/* Reset the Communication Processor Module.
*/
m8xx_cpm_reset(cpm_page);
...
void
m8xx_cpm_reset(uint bootpage)
{
...
/* get the PTE for the bootpage */
if (!get_pteptr(&init_mm, bootpage, &pte))
panic("get_pteptr failed\n");
/* and make it uncachable */
pte_val(*pte) |= _PAGE_NO_CACHE;
_tlbie(bootpage);
host_buffer = bootpage;
host_end = host_buffer + PAGE_SIZE;
> >3) Memory for DMA pages must not be in the pinned region. ie. drivers
> >should not allocate memory directly for DMA purposes.
>
> Why not?
Because DMA pages need to have their PTE's marked as uncached, which in turn
means their TLB's need to be marked as uncached.
> It doesn't matter if we cover a VM space with a bunch of 4K
> entries or a single 8M entry. The physical pages are always going to
> be multiple mapped, either through the mapin_ram() space or a single 8M
> entry, and also through the vmalloc() space. You just have to ensure,
> in any case, that you don't access the pages through both VM spaces.
I dont think you can have multiple overlapping TLB entries.
How is the MMU supposed to decide between multiple mappings
for the same address ?
> >Dan, I would really enjoy having access to some of your precious 8xx
> >knowledge: share it, along with the correct way to fix this and the
> >other pending issues.
>
> The correct fix is rather simple, just make sure you configure the TLB
> to reserve entries, and get the pinned entries into those reserved
> entries.
That is how it is now. See previous posts with detailed TLB debugging.
> I know I had it right once, I don't know what happened :-)
Maybe you thought you got it right because the initial 8Mbyte
mapping works?
Unfortunately that mapping is trashed after overlapping
pte's are created.
> Just hang on and I'll get you some code to test
Sure...
[PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
On Fri, May 06, 2005 at 11:09:15PM -0400, Dan Malek wrote:
>
> On May 6, 2005, at 4:03 PM, Marcelo Tosatti wrote:
>
> >The data I have tells me otherwise. I have seen the I-TLB entries
> >getting created for kernel space.
>
> Of course. That's because the pinned entries aren't working :-)
>
> >Can't the BDI work on the 8Mbyte page? Same for other software
> >or debuggers...
>
> The BDI can, but other software functions will walk the page
> tables looking for PTE information.
Do you have any practical example which you are certain is going
to break?
I dont remember any, and I dont think any software should be walking
kernel pte's directly...
It is not possible to have the 8Mbyte pinned TLB and 4kb pagetables
mapping the same kernel virtual addresses.
> >/* get the PTE for the bootpage */
> >if (!get_pteptr(&init_mm, bootpage, &pte))
> > panic("get_pteptr failed\n");
> >
> >/* and make it uncachable */
> >pte_val(*pte) |= _PAGE_NO_CACHE;
> >_tlbie(bootpage);
>
> This is a bad hack (that I wrote) that needs to get fixed.
>
> >Because DMA pages need to have their PTE's marked as uncached, which
> >in turn
> >means their TLB's need to be marked as uncached.
>
> Right, but these are allocated from the vmalloc() space, far away
> from the pinned entries.
>
> >I dont think you can have multiple overlapping TLB entries.
>
> Sure you can, we do it all of the time. The kernel maps all of
> memory, and then user applications do it again. The only time
> it causes a problem is when you have different cache attributes
> for the same physical page. In this case, you need to ensure
> you only use one mapping. You can't have the same virtual
> address twice in the TLB (iirc, the 8xx automatically invalidates
> an existing one if you do this), but you can have the same
> physical page mapped multiple times.
You can't have both a 4kb page and a 8Mbyte page mapping the virtual
address KERNELBASE + 0.
Do you agree?
> >How is the MMU supposed to decide between multiple mappings
> >for the same address ?
>
> You are thinking backward. The MMU maps the virtual address
> accessed, there is only one valid at a time. You can have multiple
> VM addresses accessing the same physical page.
Right - I'm talking about kernel virtual addresses: in this specific case,
we can't have more than one mapping for the first page at KERNELBASE.
> >That is how it is now. See previous posts with detailed TLB debugging.
>
> Something isn't correct if it isn't working.
>
> >Maybe you thought you got it right because the initial 8Mbyte
> >mapping works?
>
> No, this is required to work for some execute in place from rom
> systems I have done. It was adapted from that. The initial 8M
> mapping must be evicted when the mapin_ram() is done. It's
> supposed to happen that way.
>
> >Unfortunately that mapping is trashed after overlapping
> >pte's are created.
>
> Right, that is supposed to happen unless TLB pinning
> is configured.
OK, we seem to be on the same page now.
So you do agree that pte's should not be created for the first
8MBytes if CONFIG_PIN_TLB is set? :)
Should I send an updated patch or you plan to do that?
[PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
> >So you do agree that pte's should not be created for the first > >8MBytes if CONFIG_PIN_TLB is set? :) > > NO. Just leave that code alone. I don't understand why you think > doing this will have any effect on the system operation. > > If you are able to run a system without creating these tables, then > the pinned TLBs must be working. If pinned TLBs weren't working, > the kernel would crash. Not creating 4kb mappings for the first 8Mbytes of kernel virtual addresses fixed the problem for me. Break at first start_kernel instruction (0xc02284a4). Dump TLB contents to "itlb-before". [marcelo at dmt ~]$ grep SPR itlb-before | grep 816 SPR 816 : 0x10002080268443776 SPR 816 : 0x10001080268439680 SPR 816 : 0x0ff79080267882624 SPR 816 : 0x0ff261c0267542976 SPR 816 : 0x0ff521c0267723200 SPR 816 : 0x100121c0268509632 SPR 816 : 0x100011c026844 SPR 816 : 0x0ffdd1c0268292544 SPR 816 : 0x0ffdb1c0268284352 SPR 816 : 0x0fef51c0267342272 SPR 816 : 0x0fef91c0267358656 SPR 816 : 0x0fe0b1c0266383808 SPR 816 : 0x0fef71c0267350464 SPR 816 : 0x0fef61c0267346368 SPR 816 : 0x0ffee1c0268362176 SPR 816 : 0x0ffdc1c0268288448 SPR 816 : 0x0fef21c0267329984 SPR 816 : 0x0fef11c0267325888 SPR 816 : 0x0fe071c0266367424 SPR 816 : 0x0ffc61c0268198336 SPR 816 : 0x0fe0c1c0266387904 SPR 816 : 0x0ffc51c0268194240 SPR 816 : 0x0fe091c0266375616 SPR 816 : 0x0ffea080268345472 SPR 816 : 0x0ff20080267518080 SPR 816 : 0x0ff81080267915392 SPR 816 : 0x1001c080268550272 SPR 816 : 0x10008080268468352 SPR 816 : 0x100021e0268444128 SPR 816 : 0x100241e0268583392 SPR 816 : 0x100301e0268632544 SPR 816 : 0xce1f -1073738209 <- VALID 8MB TLB ENTRY "go" BDI breaks at BDI>i Target state : debug mode Debug entry cause : instruction breakpoint Current PC: 0xc0228544 BDI> 0xc0228538 : bl 0xc023107c 0xc022853c : bl 0xc0230f1c 0xc0228540 : bl 0xc0230cf4 0xc0228544 : bl 0xc022ead0 0xc0228548 : bl 0xc02354b0 0xc022854c : lis r9,-16348 [marcelo at dmt ~]$ grep SPR itlb-2 | grep 816 SPR 816 : 0x10001100268439808 SPR 816 : 0x0ffdd100268292352 SPR 816 : 0x0ffdb100268284160 SPR 816 : 0x0fef5100267342080 SPR 816 : 0x0fef9100267358464 SPR 816 : 0x0fe0b100266383616 SPR 816 : 0x0fef7100267350272 SPR 816 : 0x0fef6100267346176 SPR 816 : 0x0ffee100268361984 SPR 816 : 0x0ffdc100268288256 SPR 816 : 0xc0038110 -1073512176 <- SPR 816 : 0xc0063110 -1073336048 SPR 816 : 0xc0024110 -1073594096 SPR 816 : 0xc0017110 -1073647344 SPR 816 : 0xc000e110 -1073684208 SPR 816 : 0xc0003110 -1073729264 SPR 816 : 0xc0002110 -1073733360 SPR 816 : 0xc000d110 -1073688304 SPR 816 : 0xc0004110 -1073725168 SPR 816 : 0xc0012110 -1073667824 SPR 816 : 0xc01a1110 -1072033520 SPR 816 : 0xc01a2110 -1072029424 SPR 816 : 0xc000a110 -1073700592 SPR 816 : 0xc001c110 -1073626864 SPR 816 : 0xc001b110 -1073630960 <- SPR 816 : 0x0ff26100267542784 SPR 816 : 0x0ff52100 SPR 816 : 0x10012100268509440 SPR 816 : 0x100021e0268444128 SPR 816 : 0x100241e0268583392 SPR 816 : 0x100301e0268632544 SPR 816 : 0xce1f -1073738209 (gdb) disassemble start_kernel Dump of assembler code for function start_kernel: 0xc02284a4 :lis r3,-16358 0xc02284a8 :stwur1,-32(r1) 0xc02284ac :mflrr0 0xc02284b0 : addir3,r3,21832 0xc02284b4 : stw r0,36(r1) 0xc02284b8 : stmwr29,20(r1) 0xc02284bc : bl 0xc0012130 0xc02284c0 : addir3,r1,8 0xc02284c4 : bl 0xc022ee28 0xc02284c8 : bl 0xc0230548 0xc02284cc : bl 0xc02321e8 0xc02284d0 : bl 0xc02326f4 0xc02284d4 : lis r4,-16348 0xc02284d8 : lis r3,-16355 0xc02284dc : addir4,r4,-5804 0xc02284e0 : addir3,r3,-6768 0xc02284e4 : bl 0xc0012130 0xc02284e8 : bl 0xc022842c 0xc02284ec : lis r5,-16353 0xc02284f0 : lis r6,-16353 0xc02284f4 : addir5,r5,4580 0xc02284f8 : addir6,r6,5060 ---Type to continue, or q to quit--- 0xc02284fc : subfr6,r5,r6 0xc0228500 : lis r0,-13108 0xc0228504 : ori r0,r0,52429 0xc0228508 : srawi r6,r6,2 0xc022850c : mullw r6,r6,r0 0xc0228510 : lwz r4,8(r1) 0xc0228514 : lis r7,-16349 0xc0228518 : lis r3,-16355 0xc022851c : addir7,r7,-32404 0xc0228520 : addir3,r3,-6740 0xc0228524 : bl 0xc0024dac 0xc0228528 : bl 0xc0231220 0xc022852c : bl 0xc022eaa0 0xc0228530 : bl 0xc02311f0 0xc0228534 : bl 0xc022eaa4 0xc0228538 : bl 0xc023107c 0xc022853c : bl 0xc0230f1c 0xc0228540 : bl 0xc0230cf4 0xc0228544 : bl 0xc022ead0 0xc0228548 : bl 0xc02354b0 0xc022854c : lis r9,-16348 0xc0228550 : lwz r3,-8180(r9) 0xc0228554 : cmpwi r3
[PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
> NO. Just leave that code alone. I don't understand why you think > doing this will have any effect on the system operation. If you are > able to run a system without creating these tables, then the pinned > TLBs must be working. If pinned TLBs weren't working, the kernel > would crash. I just booted a kernel with 4kb PTE mappings at KERNELBASE and the pinned TLB was not trashed. So, I was talking nonsense. :) The only problem are DMA users who dont use dma_alloc_coherent API.
How to fix 8xx dcbst bug?
On Sat, May 07, 2005 at 08:24:01PM +0200, Joakim Tjernlund wrote: > > > > > > Hi Dan, > > > > So, restarting this conversation... > > > > On Tue, Apr 05, 2005 at 11:58:17AM -0400, Dan Malek wrote: > > > > > > On Apr 4, 2005, at 3:17 PM, Marcelo Tosatti wrote: > > > > > > >Problem is that the "dcbst" instruction will, _sometimes_ (the > > > >failure/success rate is about 1/4 > > > >with my test application) fault as a _write_ operation on the data. > > > > > > Oh, geeze It's all coming back to me now > > > > > > The 8xx cache operations don't always operate as defined in the PEM. > > > There are likely to be some archive discussions within the Freescale > > > knowledge data base that describe the different behaviors I've seen > > > with the chip variants and revisions. I can't find any of those e-mail > > > discussions, so I'll try to recall from memory. > > > > > > The PEM cache instructions are all implemented in a microcode that > > > uses the 8xx unique cache control SPRs. Depending upon the state > > > of the cache and MMU, it seems in some cases the EA translation is > > > subject to a "normal" protection match instead of a load operation > > > match. > > > > > > The behavior of these operations isn't consistent across all of the 8xx > > > processor revisions, especially with early silicon if people are still > > > using those. During conversations with Freescale engineers, it seems > > > the only guaranteed operation was to use the 8xx unique SPRs, but > > > I think I only did that in 8xx specific functions. > > > > > > We have way too much code in the TLB exception handlers already, > > > so let's just try a tlbia of the EA in the update_mmu_cache, with an > > > #ifdef > > > for the 8xx. > > > > > We may want to make the dcbxxx instructions > > > some > > > kind of macro, so on 8xx we can include such operations in otherwise > > > "standard" software. > > > > Now that I think of it, userspace dcbst users should not be an issue > > because the intermediate invalid TLB entry is not visible to applications. > > > > Userspace sees only: not present pte, or valid present pte. > > > > Well, at least the entry which has been causing problems, > > created by DataStoreTLBMiss. > > > > Is it safe to assume that dcbst usage on userspace is restricted > > to valid TLBs? Since MMU SPRs are restricted to supervisor > > protection, I think so. > > Not sure what you mean here. Currently all dcbX instr. in user space > have to be on valid\populated pte's since otherwise it will SEGV. OK. The BUG in update_mmu_cache() is triggered because dcbX happens on populated but invalid page mapping. > If you write your app so that any dcbX will only cause a plain DTLB you are > safe, just look at ld.so. This should not be a requirement but for 8xx it is > currently and I think 8xx gets > away with it because nobody is using swap on 8xx.
[26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
On Sat, May 07, 2005 at 08:10:38PM +0200, Joakim Tjernlund wrote:
> > Hi Dan, Joakim,
> >
> > On Sat, Apr 23, 2005 at 08:00:39PM -0400, Dan Malek wrote:
> > >
> > > On Apr 23, 2005, at 7:51 PM, Joakim Tjernlund wrote:
> > >
> > > >hmm, I have more than 24MB of memory and I can run CONFIG_PIN_TLB just
> > > >fine with modules off in kernel 2.4. Havn't tried 2.6 yet.
> > >
> > > Doh. Oh, I see. We only do the optimization for the instruction
> > > misses.
> > > I'll have to take a closer look at Marcelo's 2.6 tests.
> >
> > The PIN TLB entry option does not make much difference in my tests,
> > never did.
> >
> > Who wrote the code? Are there results which indicate a performance gain
> > from TLB pinning on 8xx? If so, where are such results?
> >
> > One problem that I've noted is that initial_mmu sets {I,D}TLB index
> > to be 27 (11100).
> >
> > MI_RSV4I protects TLB's 27...31.
> >
> > Given that both {I,D}TLB INDEX's are _decreased_ on each update, it seems
> > to me that initial_mmu should set {I,D}TLB INDEX to 31, which will then
> > decrease down to 27 after 4 TLB's are created.
> >
> > Another question that comes to mind is why initial_mmu does create
> > additional 8Meg TLB entries for D-cache but not for I-cache:
> >
> > #ifdef CONFIG_PIN_TLB
> > /* Map two more 8M kernel data pages.
> > */
> > ...
> > #endif
>
> Not completly sure that this is correct. There are a few:
> addir10, r10, 0x0100
> mtspr SPRN_MD_CTR, r10
> later on which will "overflow" 0x1f00 into 0x2000 etc.
Yep. This is not correct at all: the TLB index is increased
at each miss, not decreased as the manual says.
I have confirmed it with the BDI...
> Jocke
> >
> > I'll do some more CONFIG_PIN_TLB tests this week...
> >
> > --- head_8xx.S.orig22005-04-24 17:55:59.0 -0300
> > +++ head_8xx.S 2005-04-24 17:57:44.0 -0300
> > @@ -697,7 +697,7 @@
> > tlbia /* Invalidate all TLB entries */
> > #ifdef CONFIG_PIN_TLB
> > lis r8, MI_RSV4I at h
> > - ori r8, r8, 0x1c00
> > + ori r8, r8, 0x1f00
> > #else
> > li r8, 0
> > #endif
> > @@ -705,7 +705,7 @@
> >
> > #ifdef CONFIG_PIN_TLB
> > lis r10, (MD_RSV4I | MD_RESETVAL)@h
> > - ori r10, r10, 0x1c00
> > + ori r10, r10, 0x1f00
> > mr r8, r10
> > #else
> > lis r10, MD_RESETVAL at h
[PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
On Sat, May 07, 2005 at 04:02:34PM -0400, Dan Malek wrote: > > On May 7, 2005, at 9:16 AM, Marcelo Tosatti wrote: > > >Not creating 4kb mappings for the first 8Mbytes of kernel > >virtual addresses fixed the problem for me. > > Fixed what problem? page faults for initial 8Mbytes of kernel virtual map. > In the TLB dump, you replaced the initial 8M entry with > a bunch of 4K page entries, just as I would have expected > to happen. Since it was able to run and load these, the > complete PTE tables must have been created. Right, that was a dump of a "problematic" (ie 4kb pagefaults on 8Mbyte pinned region) kernel. > How did you "not create" the 4K mappings? I told mapin_ram() to start at KERNELBASE + 8Mb. But, as you said, thats not necessary.
How to fix 8xx dcbst bug?
On Sat, May 07, 2005 at 09:10:17PM -0400, Dan Malek wrote: > > On May 6, 2005, at 11:45 AM, Marcelo Tosatti wrote: > > > > >Hi Dan, > > > >So, restarting this conversation... > > One of the things I don't want to lose sight of during > all of this is the real performance problem in 2.6. > Your test results show there is something that needs > attention, regardless of using pinned entries. We > need to continue some of this investigation, it > affects all processors. True. Follows some useful data: "itlb-content-before" and "itlb-content-after" are dumps of TLB cache content before and after "sys_read()", for both v2.4 and v2.6. The "diff" output shows which TLB's have been faulted in: [marcelo at logos itlb]$ diff -u 24-itlb-content-before.txt 24-itlb-content-after.txt | grep SPR | grep 816 | grep "+" +SPR 816 : 0x0ffe800f268337167 +SPR 816 : 0x0ffeb00f268349455 +SPR 816 : 0xc009e01f -1073094625 +SPR 816 : 0xc009d01f -1073098721 +SPR 816 : 0xc000301f -1073729505 +SPR 816 : 0xc009c01f -1073102817 [marcelo at logos itlb]$ diff -u 24-itlb-content-before.txt 24-itlb-content-after.txt | grep SPR | grep 818 | grep "+" | wc -l 6 Now v2.6: [marcelo at logos itlb]$ diff -u 26-itlb-before.txt 26-itlb-after.txt | grep 816 | grep SPR | grep "+" +SPR 816 : 0x0feda16f267231599 +SPR 816 : 0xc004b17f -1073434241 +SPR 816 : 0xc004a17f -1073438337 +SPR 816 : 0x0ff7e16f267903343 +SPR 816 : 0x1001016f268501359 +SPR 816 : 0xc000217f -1073733249 +SPR 816 : 0xc001617f -1073651329 +SPR 816 : 0xc002e17f -1073553025 +SPR 816 : 0xc010e17f -1072635521 +SPR 816 : 0xc002d17f -1073557121 +SPR 816 : 0xc010d17f -1072639617 +SPR 816 : 0xc000c17f -1073692289 +SPR 816 : 0xc000317f -1073729153 [marcelo at logos itlb]$ diff -u 26-itlb-before.txt 26-itlb-after.txt | grep 816 | grep SPR | grep "+" | wc -l 13 So, for sys_read() v2.6 i-cache translation footprint is about 100% more than v2.4. I suspect that actual cache footprint is higher, too.
m8xx_pcmcia driver ported to v2.6
Per Jason's request, here goes the m8xx PCMCIA driver ported to v2.6.
It needs some cleaning up (some #ifdef'd out code pieces need to
be removed), but should be fine other than that.
There is one pending problem: the M8xx does not accept
access to non present ioports (an exception is triggered),
which is quite common while inserting/removing cards.
We've hacked around this in our tree, Panto once mentioned
that another PPC's do handle those exceptions fine (?).
Makefile:
obj-$(CONFIG_M8XX) += m8xx_pcmcia.o
Kconfig:
config M8XX
tristate "MPC8xx PCMCIA support"
depends on PCMCIA && PPC
select PCCARD_NONSTATIC
help
This provides support for Motorola 8xx embedded PowerPC
series PCMCIA controller.
-- next part --
/* -*- linux-c -*- */
/*
* m8xx_pcmcia.c - Linux PCMCIA socket driver for the mpc8xx series.
*
* (C) 1999-2000 Magnus Damm
* (C) 2001-2002 Montavista Software, Inc.
*
* Support for two slots by Cyclades Corporation
*
*
* v2.6 kernel port, further fixes by Marcelo Tosatti
*
*
* "The ExCA standard specifies that socket controllers should provide
* two IO and five memory windows per socket, which can be independently
* configured and positioned in the host address space and mapped to
* arbitrary segments of card address space. " - David A Hinds. 1999
*
* This controller does _not_ meet the ExCA standard.
*
* m8xx pcmcia controller brief info:
* + 8 windows (attrib, mem, i/o)
* + up to two slots (SLOT_A and SLOT_B)
* + inputpins, outputpins, event and mask registers.
* - no offset register. sigh.
*
* Because of the lacking offset register we must map the whole card.
* We assign each memory window PCMCIA_MEM_WIN_SIZE address space.
* Make sure there is (PCMCIA_MEM_WIN_SIZE * PCMCIA_MEM_WIN_NO
* * PCMCIA_SOCKETS_NO) bytes at PCMCIA_MEM_WIN_BASE.
* The i/o windows are dynamically allocated at PCMCIA_IO_WIN_BASE.
* They are maximum 64KByte each...
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#ifdef CONFIG_TSxK
#include
#endif
//#define PCMCIA_DEBUG 5
#ifdef PCMCIA_DEBUG
static int pc_debug = PCMCIA_DEBUG;
MODULE_PARM(pc_debug, "i");
#define DEBUG(n, args...) printk(KERN_DEBUG "m8xx_pcmcia: " args);
#else
#define DEBUG(n, args...)
#endif
#define PCMCIA_INFO(args...) printk(KERN_INFO "m8xx_pcmcia: "args)
#define PCMCIA_ERROR(args...) printk(KERN_ERR "m8xx_pcmcia: "args)
static const char *version = "Version 0.05-cyclades1, May 2003";
MODULE_LICENSE("Dual MPL/GPL");
#if !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B)
/* The RPX series use SLOT_B */
#if defined(CONFIG_RPXCLASSIC) || defined(CONFIG_RPXLITE)
#define CONFIG_PCMCIA_SLOT_B
#define CONFIG_BD_IS_MHZ
#endif
/* The ADS board use SLOT_A */
#ifdef CONFIG_ADS
#define CONFIG_PCMCIA_SLOT_A
#define CONFIG_BD_IS_MHZ
#endif
/* The FADS series are a mess */
#ifdef CONFIG_FADS
#if defined(CONFIG_MPC860T) || defined(CONFIG_MPC860) || defined(CONFIG_MPC821)
#define CONFIG_PCMCIA_SLOT_A
#else
#define CONFIG_PCMCIA_SLOT_B
#endif
#endif
/* Cyclades ACS uses both slots */
#ifdef CONFIG_PRxK
#define CONFIG_PCMCIA_SLOT_A
#define CONFIG_PCMCIA_SLOT_B
#endif
#endif /* !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B) */
#if defined(CONFIG_PCMCIA_SLOT_A) && defined(CONFIG_PCMCIA_SLOT_B)
#define PCMCIA_SOCKETS_NO 2
/* We have only 8 windows, dualsocket support will be limited. */
#define PCMCIA_MEM_WIN_NO 2
#define PCMCIA_IO_WIN_NO 2
#define PCMCIA_SLOT_MSG "SLOT_A and SLOT_B"
#elif defined(CONFIG_PCMCIA_SLOT_A) || defined(CONFIG_PCMCIA_SLOT_B)
#define PCMCIA_SOCKETS_NO 1
/* full support for one slot */
#define PCMCIA_MEM_WIN_NO 5
#define PCMCIA_IO_WIN_NO 2
/* define _slot_ to be able to optimize macros */
#ifdef CONFIG_PCMCIA_SLOT_A
#define _slot_ 0
#define PCMCIA_SLOT_MSG "SLOT_A"
#else
#define _slot_ 1
#define PCMCIA_SLOT_MSG "SLOT_B"
#endif
#else
#error m8xx_pcmcia: Bad configuration!
#endif
/* - */
#define PCMCIA_MEM_WIN_BASE 0xe000 /* base address for memory window 0 */
#define PCMCIA_MEM_WIN_SIZE 0x0400 /* each memory window is 64 MByte */
#define PCMCIA_IO_WIN_BASE _IO_BASE /* base address for io window 0 */
#define PCMCIA_SCHLVL PCMCIA_INTERRUPT /* Status Change Interrupt Level */
/* - */
/* 2.4.x and newer has this always in HZ */
#define M8XX_BUSFREQ bd_t *)&(__res))->bi_busfreq))
static i
[PATCH] allow coherent DMA API to work before main page allocator is set up
Hi Dan, Matt,
The following patch changes dma_alloc_coherent() to, in case the
main page allocator is not yet up and running, use the bootmem
allocator instead.
It also adds a new parameter to m8xx_cpm_hostalloc() to send back
the physical address to its caller.
With such modification in place it will be possible for early drivers
to rely on the coherent DMA allocator. Special casing such as
drivers/serial/cpm_uart/cpm_uart_cpm1.c's cpm_uart_allocbuf() can be
removed:
if (is_con) {
mem_addr = (u8 *) m8xx_cpm_hostalloc(memsz);
dma_addr = 0;
} else
mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
GFP_KERNEL);
What is your opinion on this approach?
If virt_to_phys() usage is discouraged any different method to walk
the pagetables and retrieve the physical address can be used.
TIA
diff -Nur linux-2.6.11.orig/arch/ppc/8xx_io/commproc.c
linux-2.6.11/arch/ppc/8xx_io/commproc.c
--- linux-2.6.11.orig/arch/ppc/8xx_io/commproc.c2005-05-20
13:53:17.0 -0300
+++ linux-2.6.11/arch/ppc/8xx_io/commproc.c 2005-05-20 16:02:13.0
-0300
@@ -39,7 +39,8 @@
#include
#include
-extern int get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep);
+
+phys_addr_tphysaddr;
static void m8xx_cpm_dpinit(void);
static uinthost_buffer;/* One page of host buffer */
@@ -111,11 +112,10 @@
extern void flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr);
void
-m8xx_cpm_reset(uint bootpage)
+m8xx_cpm_reset(void)
{
volatile immap_t *imp;
volatile cpm8xx_t *commproc;
- pte_t *pte;
imp = (immap_t *)IMAP_ADDR;
commproc = (cpm8xx_t *)&imp->im_cpm;
@@ -143,17 +143,6 @@
/* Reclaim the DP memory for our use. */
m8xx_cpm_dpinit();
- /* get the PTE for the bootpage */
- if (!get_pteptr(&init_mm, bootpage, &pte))
- panic("get_pteptr failed\n");
-
- /* and make it uncachable */
- pte_val(*pte) |= _PAGE_NO_CACHE;
- _tlbie(bootpage);
-
- host_buffer = bootpage;
- host_end = host_buffer + PAGE_SIZE;
-
/* Tell everyone where the comm processor resides.
*/
cpmp = (cpm8xx_t *)commproc;
@@ -165,7 +154,6 @@
static void
alloc_host_memory(void)
{
- dma_addr_t physaddr;
/* Set the host page for allocation.
*/
@@ -325,7 +313,7 @@
* UART "fifos" and the like.
*/
uint
-m8xx_cpm_hostalloc(uint size)
+m8xx_cpm_hostalloc(uint size, phys_addr_t *handle)
{
uintretloc;
@@ -336,7 +324,9 @@
return(0);
retloc = host_buffer;
+ *handle = physaddr;
host_buffer += size;
+ physaddr += size;
return(retloc);
}
diff -Nur linux-2.6.11.orig/arch/ppc/kernel/dma-mapping.c
linux-2.6.11/arch/ppc/kernel/dma-mapping.c
--- linux-2.6.11.orig/arch/ppc/kernel/dma-mapping.c 2005-05-20
13:53:17.0 -0300
+++ linux-2.6.11/arch/ppc/kernel/dma-mapping.c 2005-05-20 14:03:56.0
-0300
@@ -55,6 +55,8 @@
int map_page(unsigned long va, phys_addr_t pa, int flags);
+extern int mem_init_done;
+
#include
/*
@@ -121,7 +123,10 @@
unsigned long flags;
struct vm_region *c, *new;
- new = kmalloc(sizeof(struct vm_region), gfp);
+ if (mem_init_done)
+ new = kmalloc(sizeof(struct vm_region), gfp);
+ else
+ new = alloc_bootmem(sizeof(struct vm_region));
if (!new)
goto out;
@@ -175,10 +180,11 @@
void *
__dma_alloc_coherent(size_t size, dma_addr_t *handle, int gfp)
{
- struct page *page;
+ struct page *page = NULL;
struct vm_region *c;
unsigned long order;
u64 mask = 0x00ff, limit; /* ISA default */
+ void *bootmem_address = NULL;
if (!consistent_pte) {
printk(KERN_ERR "%s: not initialised\n", __func__);
@@ -199,14 +205,21 @@
if (mask != 0x)
gfp |= GFP_DMA;
- page = alloc_pages(gfp, order);
- if (!page)
- goto no_page;
+ if (mem_init_done) {
+ page = alloc_pages(gfp, order);
+ if (!page)
+ goto no_page;
+ } else {
+ bootmem_address = alloc_bootmem_pages(PAGE_SIZE << order);
+ if (!bootmem_address)
+ goto no_page;
+ }
/*
* Invalidate any data that might be lurking in the
* kernel direct-mapped region for device DMA.
*/
+ if (mem_init_done)
{
unsigned long kaddr = (unsigned long)page_address(page);
memset(page_address(page), 0, size);
@@
[PATCH] allow coherent DMA API to work before main page allocator is set up
On Fri, May 20, 2005 at 05:03:59PM -0400, Dan Malek wrote:
>
> On May 20, 2005, at 10:12 AM, Marcelo Tosatti wrote:
>
> >The following patch changes dma_alloc_coherent() to, in case the
> >main page allocator is not yet up and running, use the bootmem
> >allocator instead.
>
> I'm concerned about this ... Why did the drivers change in 2.6
> such that they now call dma_alloc_coherent() prior to the VM set up?
Well, as far as I can see, it is expected that console_init() gets called
before the main page allocator.
The startup sequence, on both v2.4 and v2.6, is:
setup_arch()
...
console_init()
console_8xx_init()
register_console()
release_console_sem()
...
mem_init()
register_console calls the driver ->setup method, and release_console_sem()
is going to ->write pending data from the log buffer to the device.
As you well know, ->setup calls m8xx_cpm_hostalloc().
I must be missing something very obvious here, can you explain how
did you arrange things in v2.4 such that the console's ->setup
method is called _after_ mem_init() ?
> >It also adds a new parameter to m8xx_cpm_hostalloc() to send back
> >the physical address to its caller.
>
> Anyone calling m8xx_cpm_hostalloc() is likely to be immediately
> calling dma_alloc_coherent(). There is some design problem here
> if we can't properly use these interfaces and get the mapping we
> need. The TLB pinning option won't work if we can't do this.
>
>
> > . Special casing such as
> >drivers/serial/cpm_uart/cpm_uart_cpm1.c's cpm_uart_allocbuf() can be
> >removed:
> >
> >if (is_con) {
> >mem_addr = (u8 *) m8xx_cpm_hostalloc(memsz);
> >dma_addr = 0;
> >} else
> >mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
> > GFP_KERNEL);
>
> This is bogus and should not be necessary. The original serial
> driver was able to work without doing this, I spent lots of time so
> stuff like this wasn't necessary, and it's sad to see us take such
> a step backward.
Well, if you got this right in v2.4 then it must be possible to get
it right in v2.6 too...
Thanks!
[RFT] 8xx cpm_hostalloc patch was: allow coherent DMA API to work before main page allocator is set up
Can someone with 8xx using the cpm_uart driver please test
the attached patch? It should avoid corruption of the pinned
8Mbyte CONFIG_PIN_TLB entry, as noted by Dan.
On Sat, May 21, 2005 at 05:21:47PM -0400, Dan Malek wrote:
>
> On May 20, 2005, at 1:51 PM, Marcelo Tosatti wrote:
>
> >I must be missing something very obvious here, can you explain how
> >did you arrange things in v2.4 such that the console's ->setup
> >method is called _after_ mem_init() ?
>
> The driver used to use the serial port configuration as left by the
> boot rom until very late into the initialization. As I have said many
> times in the past, the serial driver went through three different
> levels of configuration. There was an early configuration that was
> used for kgdb, a later one used by the serial kernel printk, and
> finally a full configuration by the serial driver.
I have missed your statements about that in the past.
OK, the v2.4 driver is using the dual port RAM:
/* Allocate space for two FIFOs. We can't allocate from host
* memory yet because vm allocator isn't initialized
* during this early console init.
*/
dp_addr = m8xx_cpm_dpalloc(2*EARLY_BUF_SIZE);
mem_addr = (uint)(&cpmp->cp_dpmem[dp_addr]);
> It's sad that "moving forward" is done at a cost of throwing away
> features that were important.
Now that I think of it, no v2.6 driver should be calling
dma_alloc_coherent() before mem_init(). I was seeing the problem
because we're still using the old uart driver, which does that, and
our timer setup routine also.
> is a quick fix, but this further ensures features like pinned TLB
> entries won't work.
Actually, the quick fix to use bootmem allocator ensures that the
pinned TLB is _preserved_ (by using a pagetableentry from the consistent
DMA address space to mark as uncached and invalidate, instead of a pte
from the kernel direct mapped virtual space which blows away the 8Mbyte
entry - current v2.6 state).
Why do you say that "further ensures that features like pinned TLB
entries won't work" ?
If there is really a problem with using the bootmem allocator for
noncacheable purposes (which I can't see), it should be pretty easy
to modify cpm_uart to use dpram instead of host bootmem RAM, right?
-- next part --
--- linux-2.6.11.orig/arch/ppc/syslib/m8xx_setup.c 2005-05-20
13:53:17.0 -0300
+++ linux-2.6.11/arch/ppc/syslib/m8xx_setup.c 2005-05-20 15:59:24.0
-0300
@@ -57,7 +57,7 @@
extern void m8xx_ide_init(void);
extern unsigned long find_available_memory(void);
-extern void m8xx_cpm_reset(uint cpm_page);
+extern void m8xx_cpm_reset();
extern void m8xx_wdt_handler_install(bd_t *bp);
extern void rpxfb_alloc_pages(void);
extern void cpm_interrupt_init(void);
@@ -70,13 +70,9 @@
void __init
m8xx_setup_arch(void)
{
- int cpm_page;
-
- cpm_page = (int) alloc_bootmem_pages(PAGE_SIZE);
-
/* Reset the Communication Processor Module.
*/
- m8xx_cpm_reset(cpm_page);
+ m8xx_cpm_reset();
#ifdef CONFIG_FB_RPX
rpxfb_alloc_pages();
--- linux-2.6.11.orig/arch/ppc/8xx_io/commproc.c2005-05-20
13:53:17.0 -0300
+++ linux-2.6.11/arch/ppc/8xx_io/commproc.c 2005-05-22 00:29:42.0
-0300
@@ -39,8 +39,6 @@
#include
#include
-extern int get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep);
-
static void m8xx_cpm_dpinit(void);
static uinthost_buffer;/* One page of host buffer */
static uinthost_end; /* end + 1 */
@@ -111,11 +109,10 @@
extern void flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr);
void
-m8xx_cpm_reset(uint bootpage)
+m8xx_cpm_reset(void)
{
volatile immap_t *imp;
volatile cpm8xx_t *commproc;
- pte_t *pte;
imp = (immap_t *)IMAP_ADDR;
commproc = (cpm8xx_t *)&imp->im_cpm;
@@ -143,17 +140,6 @@
/* Reclaim the DP memory for our use. */
m8xx_cpm_dpinit();
- /* get the PTE for the bootpage */
- if (!get_pteptr(&init_mm, bootpage, &pte))
- panic("get_pteptr failed\n");
-
- /* and make it uncachable */
- pte_val(*pte) |= _PAGE_NO_CACHE;
- _tlbie(bootpage);
-
- host_buffer = bootpage;
- host_end = host_buffer + PAGE_SIZE;
-
/* Tell everyone where the comm processor resides.
*/
cpmp = (cpm8xx_t *)commproc;
[PATCH] PRxK sub-architecture
On Fri, Oct 15, 2004 at 11:15:39AM -0700, Tom Rini wrote: > [ Switched over to linuxppc-embedded ] > > On Fri, Oct 15, 2004 at 01:09:41PM -0300, Marcelo Tosatti wrote: > > Just some rough comments: > > [snip] > > diff -Nur --exclude-from=/tmp/exclude > > linux-2.6-bkppc.orig/arch/ppc/8xx_io/fec.c > > linux-2.6-bkppc/arch/ppc/8xx_io/fec.c > > --- linux-2.6-bkppc.orig/arch/ppc/8xx_io/fec.c 2004-09-02 > > 08:52:19.0 -0300 > > +++ linux-2.6-bkppc/arch/ppc/8xx_io/fec.c 2004-09-02 14:33:23.0 > > -0300 > > @@ -173,7 +173,7 @@ > > uintphy_status; > > uintphy_speed; > > phy_info_t *phy; > > - struct tq_struct phy_task; > > + struct work_struct phy_task; > > > > uintsequence_done; > > > > This looks like a dupe of what's already in linuxppc-2.5. > > [snip] > > diff -Nur --exclude-from=/tmp/exclude > > linux-2.6-bkppc.orig/arch/ppc/boot/simple/embed_config.c > > linux-2.6-bkppc/arch/ppc/boot/simple/embed_config.c > > --- linux-2.6-bkppc.orig/arch/ppc/boot/simple/embed_config.c > > 2004-09-02 08:52:19.0 -0300 > > +++ linux-2.6-bkppc/arch/ppc/boot/simple/embed_config.c 2004-09-02 > > 10:17:19.0 -0300 > > This looks like it should be done in prxk.c, with the various hooks that > we provide in misc.c, which might have to be ported to misc-embedded.c. OK, I'll look into this. > [snip] > > diff -Nur --exclude-from=/tmp/exclude > > linux-2.6-bkppc.orig/arch/ppc/boot/simple/head.S > > linux-2.6-bkppc/arch/ppc/boot/simple/head.S > > --- linux-2.6-bkppc.orig/arch/ppc/boot/simple/head.S2004-09-02 > > 08:52:19.0 -0300 > > +++ linux-2.6-bkppc/arch/ppc/boot/simple/head.S 2004-09-02 > > 17:30:39.0 -0300 > > Do we really need to do this? If so, why? Yes because the bootloader jumps to 0x2120. We can't afford to change that, I think. I'll take a closer look at this too. > [snip] > > diff -Nur --exclude-from=/tmp/exclude > > linux-2.6-bkppc.orig/include/asm-ppc/prxk.h > > linux-2.6-bkppc/include/asm-ppc/prxk.h > > --- linux-2.6-bkppc.orig/include/asm-ppc/prxk.h 1969-12-31 > > 21:00:00.0 -0300 > > +++ linux-2.6-bkppc/include/asm-ppc/prxk.h 2004-09-02 08:54:51.0 > > -0300 > [snip] > > +/* Machine type > > +*/ > > +#define _MACH_8xx (_MACH_PRxK) > > Eh? Is there more to come that moves 8xx towards what we have on > pmac/prep/chrp ? Or a left-over from older kernels? I think its just a leftover from older kernels. > Thanks. Thank you for commenting! I'll move embed_config() to prxk.c as suggested, fix the _bcopy_str(), and come up with another patch next week.
m8xx PCMCIA driver for 2.6 kernel
Hi, It seems you "mlocke at mvista.com" (I dont know your name, sorry) done some work and submitted the m8xx pcmcia driver for the v2.4 kernel tree. Have you done any work in respect to porting the driver to v2.6 kernel? TIA
m8xx_pcmcia.c for v2.6 kernels
Hi fellows,
I'm attaching a port of our internal m8xx_pcmcia.c (based
on MontaVista 2.1's 2.4.17 kernel with many fixes) to v2.6.
It works fine on our MPC8xx boxes, detects cards on the two slots,
removal/insert event works.
Would be nice if other people could give it a try.
Also very interesting thing would be to merge other fixes
done by MontaVista or others to this one driver and
merge it upstream at some point.
I volunteer to maintain it.
-- next part --
/* -*- linux-c -*- */
/*
* m8xx_pcmcia.c - Linux PCMCIA socket driver for the mpc8xx series.
*
* (C) 1999-2000 Magnus Damm
* (C) 2001-2002 Montavista Software, Inc.
*
* Support for two slots by Cyclades Corporation
*
*
* v2.6 kernel port, further fixes by Cyclades Corporation
*
*
* "The ExCA standard specifies that socket controllers should provide
* two IO and five memory windows per socket, which can be independently
* configured and positioned in the host address space and mapped to
* arbitrary segments of card address space. " - David A Hinds. 1999
*
* This controller does _not_ meet the ExCA standard.
*
* m8xx pcmcia controller brief info:
* + 8 windows (attrib, mem, i/o)
* + up to two slots (SLOT_A and SLOT_B)
* + inputpins, outputpins, event and mask registers.
* - no offset register. sigh.
*
* Because of the lacking offset register we must map the whole card.
* We assign each memory window PCMCIA_MEM_WIN_SIZE address space.
* Make sure there is (PCMCIA_MEM_WIN_SIZE * PCMCIA_MEM_WIN_NO
* * PCMCIA_SOCKETS_NO) bytes at PCMCIA_MEM_WIN_BASE.
* The i/o windows are dynamically allocated at PCMCIA_IO_WIN_BASE.
* They are maximum 64KByte each...
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#ifdef CONFIG_TSxK
#include
#endif
#define PCMCIA_DEBUG 5
#ifdef PCMCIA_DEBUG
static int pc_debug = PCMCIA_DEBUG;
MODULE_PARM(pc_debug, "i");
#define DEBUG(n, args...) printk(KERN_DEBUG "m8xx_pcmcia: " args);
#else
#define DEBUG(n, args...)
#endif
#define PCMCIA_INFO(args...) printk(KERN_INFO "m8xx_pcmcia: "args)
#define PCMCIA_ERROR(args...) printk(KERN_ERR "m8xx_pcmcia: "args)
static const char *version = "Version 0.05-cyclades1, May 2003";
MODULE_LICENSE("Dual MPL/GPL");
#if !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B)
/* The RPX series use SLOT_B */
#if defined(CONFIG_RPXCLASSIC) || defined(CONFIG_RPXLITE)
#define CONFIG_PCMCIA_SLOT_B
#define CONFIG_BD_IS_MHZ
#endif
/* The ADS board use SLOT_A */
#ifdef CONFIG_ADS
#define CONFIG_PCMCIA_SLOT_A
#define CONFIG_BD_IS_MHZ
#endif
/* The FADS series are a mess */
#ifdef CONFIG_FADS
#if defined(CONFIG_MPC860T) || defined(CONFIG_MPC860) || defined(CONFIG_MPC821)
#define CONFIG_PCMCIA_SLOT_A
#else
#define CONFIG_PCMCIA_SLOT_B
#endif
#endif
/* Cyclades ACS uses both slots */
#ifdef CONFIG_PRxK
#define CONFIG_PCMCIA_SLOT_A
#define CONFIG_PCMCIA_SLOT_B
#endif
#endif /* !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B) */
#if defined(CONFIG_PCMCIA_SLOT_A) && defined(CONFIG_PCMCIA_SLOT_B)
#define PCMCIA_SOCKETS_NO 2
/* We have only 8 windows, dualsocket support will be limited. */
#define PCMCIA_MEM_WIN_NO 2
#define PCMCIA_IO_WIN_NO 2
#define PCMCIA_SLOT_MSG "SLOT_A and SLOT_B"
#elif defined(CONFIG_PCMCIA_SLOT_A) || defined(CONFIG_PCMCIA_SLOT_B)
#define PCMCIA_SOCKETS_NO 1
/* full support for one slot */
#define PCMCIA_MEM_WIN_NO 5
#define PCMCIA_IO_WIN_NO 2
/* define _slot_ to be able to optimize macros */
#ifdef CONFIG_PCMCIA_SLOT_A
#define _slot_ 0
#define PCMCIA_SLOT_MSG "SLOT_A"
#else
#define _slot_ 1
#define PCMCIA_SLOT_MSG "SLOT_B"
#endif
#else
#error m8xx_pcmcia: Bad configuration!
#endif
/* - */
#define PCMCIA_MEM_WIN_BASE 0xe000 /* base address for memory window 0 */
#define PCMCIA_MEM_WIN_SIZE 0x0400 /* each memory window is 64 MByte */
#define PCMCIA_IO_WIN_BASE _IO_BASE /* base address for io window 0 */
#define PCMCIA_SCHLVL PCMCIA_INTERRUPT /* Status Change Interrupt Level */
/* - */
//#if (LINUX_VERSION_CODE >= VERSION(2,4,0))
#if 1
/* 2.4.x has this always in HZ */
#define M8XX_BUSFREQ bd_t *)&(__res))->bi_busfreq))
#else /* 2.2.x */
#ifdef CONFIG_BD_IS_MHZ
#define M8XX_BUSFREQ ((mpc8xx_bdinfo->bi_busfreq) * 100)
#else
#define M8XX_BUSFREQ (mpc8xx_bdinfo->bi_busfreq)
#endif
#endif
static int pcmcia_schlvl = PCMCIA_SCHLVL;
spinlock_t events_lock = SPIN_LOCK_UNLOCKED;
/* - */
#define PCMCIA_SOCKET_KEY_5V 1
#define PCMCIA_SOCKET_KEY_LV 2
/* look up table for pgcrx registers */
static u_int *m8xx_pgcrx[2] = {
&((im
[RFC: 2.6 patch] powerpc: remove the unused HTDMSOUND driver
Dan, Shall this driver be removed? On Sun, Mar 25, 2007 at 04:58:38PM +0200, Adrian Bunk wrote: > Recently, someone fixed a syntax error in the HTDMSOUND driver > introduced 4 years ago. > > Unfortunately not by trying to compile this driver for his hardware but > by code inspection - which seems to be a strong indication that there > are no users left for this OSS sound driver. > > This patch therefore removes it. > > Signed-off-by: Adrian Bunk > > --- > > This patch was already sent on: > - 7 Mar 2007 > > arch/ppc/8xx_io/Kconfig |4 > arch/ppc/8xx_io/Makefile|1 > arch/ppc/8xx_io/cs4218.h| 166 - > arch/ppc/8xx_io/cs4218_tdm.c| 2833 > arch/ppc/platforms/rpxclassic.h |4 > arch/ppc/platforms/rpxhiox.h| 41 > arch/ppc/platforms/rpxlite.h|4 > arch/ppc/syslib/m8xx_setup.c|2 > 8 files changed, 1 insertion(+), 3054 deletions(-) > > --- linux-2.6.21-rc2-mm1/arch/ppc/8xx_io/Kconfig.old 2007-03-06 > 06:47:04.0 +0100 > +++ linux-2.6.21-rc2-mm1/arch/ppc/8xx_io/Kconfig 2007-03-06 > 06:47:16.0 +0100 > @@ -74,10 +74,6 @@ > Allocate large buffers for MPC8xx Ethernet. Increases throughput > and decreases the likelihood of dropped packets, but costs memory. > > -config HTDMSOUND > - bool "Embedded Planet HIOX Audio" > - depends on SOUND=y > - > # This doesn't really belong here, but it is convenient to ask > # 8xx specific questions. > comment "Generic MPC8xx Options" > --- linux-2.6.21-rc2-mm1/arch/ppc/8xx_io/Makefile.old 2007-03-06 > 06:47:23.0 +0100 > +++ linux-2.6.21-rc2-mm1/arch/ppc/8xx_io/Makefile 2007-03-06 > 06:47:30.0 +0100 > @@ -7,4 +7,3 @@ > obj-$(CONFIG_FEC_ENET) += fec.o > obj-$(CONFIG_SCC_ENET) += enet.o > obj-$(CONFIG_UCODE_PATCH) += micropatch.o > -obj-$(CONFIG_HTDMSOUND) += cs4218_tdm.o > --- linux-2.6.21-rc2-mm1/arch/ppc/platforms/rpxlite.h.old 2007-03-06 > 06:49:05.0 +0100 > +++ linux-2.6.21-rc2-mm1/arch/ppc/platforms/rpxlite.h 2007-03-06 > 06:49:41.0 +0100 > @@ -57,10 +57,6 @@ > #define BCSR1_PCVCTL6 ((uint)0x0002) > #define BCSR1_PCVCTL7 ((uint)0x0001) > > -#if defined(CONFIG_HTDMSOUND) > -#include > -#endif > - > /* define IO_BASE for pcmcia */ > #define _IO_BASE 0x8000 > #define _IO_BASE_SIZE 0x1000 > --- linux-2.6.21-rc2-mm1/arch/ppc/platforms/rpxclassic.h.old 2007-03-06 > 06:49:51.0 +0100 > +++ linux-2.6.21-rc2-mm1/arch/ppc/platforms/rpxclassic.h 2007-03-06 > 06:49:56.0 +0100 > @@ -69,10 +69,6 @@ > #define BCSR2_QSPACESEL ((uint)0x4000) > #define BCSR2_FETHLEDMODE((uint)0x0800) /* CLLF */ > > -#if defined(CONFIG_HTDMSOUND) > -#include > -#endif > - > /* define IO_BASE for pcmcia, CLLF only */ > #if !defined(CONFIG_PCI) > #define _IO_BASE 0x8000 > --- linux-2.6.21-rc2-mm1/arch/ppc/syslib/m8xx_setup.c.old 2007-03-06 > 06:50:43.0 +0100 > +++ linux-2.6.21-rc2-mm1/arch/ppc/syslib/m8xx_setup.c 2007-03-06 > 06:50:59.0 +0100 > @@ -413,7 +413,7 @@ > io_block_mapping(_IO_BASE,_IO_BASE,_IO_BASE_SIZE, _PAGE_IO); > #endif > #endif > -#if defined(CONFIG_HTDMSOUND) || defined(CONFIG_RPXTOUCH) || > defined(CONFIG_FB_RPX) > +#if defined(CONFIG_RPXTOUCH) || defined(CONFIG_FB_RPX) > io_block_mapping(HIOX_CSR_ADDR, HIOX_CSR_ADDR, HIOX_CSR_SIZE, _PAGE_IO); > #endif > #ifdef CONFIG_FADS > --- linux-2.6.21-rc2-mm1/arch/ppc/platforms/rpxhiox.h 2007-02-04 > 19:44:54.0 +0100 > +++ /dev/null 2006-09-19 00:45:31.0 +0200 > @@ -1,41 +0,0 @@ > -/* > - * The Embedded Planet HIOX expansion card definitions. > - * There were a few different versions of these cards, but only > - * the one that escaped real production is defined here. > - * > - * Copyright (c) 2000 Dan Malek (dmalek at jlc.net) > - */ > -#ifndef __MACH_RPX_HIOX_DEFS > -#define __MACH_RPX_HIOX_DEFS > - > -#define HIOX_CSR_ADDR((uint)0xfac0) > -#define HIOX_CSR_SIZE((uint)(4 * 1024)) > -#define HIOX_CSR0_ADDR HIOX_CSR_ADDR > -#define HIOX_CSR4_ADDR ((uint)0xfac4) > - > -#define HIOX_CSR0_DEFAULT((uint)0x380f3c00) > -#define HIOX_CSR0_ENSCC2 ((uint)0x8000) > -#define HIOX_CSR0_ENSMC2 ((uint)0x0400) > -#define HIOX_CSR0_ENVDOCLK ((uint)0x0200) > -#define HIOX_CSR0_VDORST_HL ((uint)0x0100) > -#define HIOX_CSR0_RS232SEL ((uint)0xc000) > -#define HIOX_CSR0_SCC3SEL((uint)0xc000) > -#define HIOX_CSR0_SMC1SEL((uint)0x8000) > -#define HIOX_CSR0_SCC1SEL((uint)0x4000) > -#define HIOX_CSR0_ENTOUCH((uint)0x0080) > -#define HIOX_CSR0_PDOWN100 ((uint)0x0060) > -#define HIOX_CSR0_PDOWN10((uint)0x0040) > -#define HIOX_CSR0_PDOWN1 ((uint)0x0020) > -#define HIOX_CSR0_TSELSPI((uint)0x0010) > -#define HIOX_CSR0_TIRQSTAT ((uint)0x0008)
ptrace on linux 2.6.12 causes oops
On Thu, Jul 14, 2005 at 05:27:15PM -0300, aris at conectiva.com.br wrote:
> > when i try to run strace or gdbserver on a program, the following comes:
> >
> > NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
> > LR [c000b060] flush_dcache_icache_page+0x20/0x30
> > Call trace:
> > [c000b154] update_mmu_cache+0x7c/0xa4
> > [c005ae98] do_wp_page+0x460/0x5ec
> > [c005c8a0] handle_mm_fault+0x7cc/0x91c
> > [c005ccec] get_user_pages+0x2fc/0x65c
> > [c0027104] access_process_vm+0x9c/0x1d4
> > [c00076e0] sys_ptrace+0x240/0x4a4
> > [c0002bd0] ret_from_syscall+0x0/0x44
> > mm/memory.c:2054: spin_lock(kernel/fork.c:c0ea1618) already locked by
> > mm/memory.c/1306
> please try to reproduce with 2.6.13-rc2. seems much like the problem Marcelo
> fixed recently (dcbst misbehaviour with unpopulated TLB entries)
Yep, just that now its the ptraceing process which is faulting in the page,
instead of the (ptraced) process itself.
So Anton, can you move the _tlbie() call up to
&& !test_bit(PG_arch_1, &page->flags)) {
<-- HERE
if (vma->vm_mm == current->active_mm)
__flush_dcache_icache((void *) address);
else
flush_dcache_icache_page(page);
set_bit(PG_arch_1, &page->flags);
So that it covers both cases instead of just (vma->vm_mm == current->active_mm)
?
Its safe to do it because the address space ID is ignored by tlbie accordingly
to the manual page:
The ASID value in the entry is ignored for the purpose of
matching an invalidate address, thus multiple entries can be invalidated
if they have the same effective address and different ASID values.
ptrace on linux 2.6.12 causes oops
On Thu, Jul 14, 2005 at 08:31:50AM -0500, Kumar Gala wrote: > What system is this on? Thats 8xx (Anton told me on IRC earlier)...
ptrace on linux 2.6.12 causes oops
Hi Anton,
On Fri, Jul 15, 2005 at 11:42:27AM +0200, Anton W?llert wrote:
> >
> > Yep, just that now its the ptraceing process which is faulting in the
> > page,
> > instead of the (ptraced) process itself.
> >
> > So Anton, can you move the _tlbie() call up to
> >
> > && !test_bit(PG_arch_1, &page->flags)) {
> > <-- HERE
> > if (vma->vm_mm == current->active_mm)
> > __flush_dcache_icache((void *) address);
> > else
> > flush_dcache_icache_page(page);
> > set_bit(PG_arch_1, &page->flags);
> >
> > So that it covers both cases instead of just (vma->vm_mm ==
> > current->active_mm) ?
> >
> > Its safe to do it because the address space ID is ignored by tlbie
> > accordingly
> > to the manual page:
> >
> > The ASID value in the entry is ignored for the purpose of
> > matching an invalidate address, thus multiple entries can be invalidated
> > if they have the same effective address and different ASID values.
>
>
>
> Well, unfortunately, that doesn't work :(.
Oh doh, on the case where the process faulting in the page is not the owner of
the
vma (which is the case with ptrace here), the flushing is done via the physical
address.
So its expected that the _tlbie() on the process virtual address will not
change
a thing, since flush_dcache_icache_page() is working on the physical address.
> If i'm right, the
> __flush_dcache_icache((void *) address) should avoid that the cache says
> faulting address again.
> The flush_dcache_icache_page(page) should flush the cache, where stands,
> page not mapped. but the flush_dcache_icache_page(page) oopses on my system.
> but instead of this call, the call __flush_dcache_icache(page_address(page))
> works. for me, that also makes more sence.
Well, you end up flushing the page through its kernel virtual address mapping
(returned
by page_address()).
It will be necessary for the kernel virtual map to be faulted in the TLB, which
is
certainly slower than doing the direct physical address flush (requires
updating
the MSR twice (+isync) to turn the MMU on/off).
But other than that I see no problem with your suggestion really, as to
workaround the
oops.
Still, we should try to understand what is going on...
> and also, the flush_dcache_icache_page(page) calls the
> flush_dcache_icache_phys, which
> turns off the data virtual address mapping. i found that a bit strange. any
> comments?
It seems that the instruction at "__flush_dcache_icache_phys+0x38" is icbi -
can you send
the disassembly of __flush_dcache_icache_phys?
We should figure out what is causing the oops.
What is causing DAR to be set to "0010"? ie why the hell is it trying to
access
the 0010 address.
Oops: kernel access of bad area, sig: 11 [#2]
NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: 0300 Not tainted
MSR: 9022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
DAR: 0010, DSISR: C200
TASK = c0ea8430[761] 'gdbserver' THREAD: c0f34000
Last syscall: 26
GPR00: 9022 C0F35DF0 C0EA8430 00F59000 0100 00F58000
0001
GPR08: C021DAEF C027 9032 C027 22044024 10025428 01000800
0001
GPR16: 007FFF3F 0001 7FBC6AC0 00F61022 0001 C0839300
C01E
GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 C02ACB00
C02ACB00
NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
LR [c000b060] flush_dcache_icache_page+0x20/0x30
[PATCH] 8xx: avoid icbi misbehaviour in __flush_dcache_icache_phys
Anton, Can you please test the following which is equivalent to your suggest changes, the only difference being the location, contained inside flush_dcache_icache_page(). After confirmation that it works we can send up to the kernel maintainers. We should still try to understand why this is happening, possibly matching it to a published CPU errata bug, or inform Freescale otherwise. I've written that entry down in the 8xx TODO list. Thanks! - On 8xx, in the case where a pagefault happens for a process who's not the owner of the vma in question (ptrace for instance), the flush operation is performed via the physical address. Unfortunately, that results in a strange, unexplainable "icbi" instruction fault, most likely due to a CPU bug (see oops below). Avoid that by flushing the page via its kernel virtual address. Oops: kernel access of bad area, sig: 11 [#2] NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: 0300 Not tainted MSR: 9022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10 DAR: 0010, DSISR: C200 TASK = c0ea8430[761] 'gdbserver' THREAD: c0f34000 Last syscall: 26 GPR00: 9022 C0F35DF0 C0EA8430 00F59000 0100 00F58000 0001 GPR08: C021DAEF C027 9032 C027 22044024 10025428 01000800 0001 GPR16: 007FFF3F 0001 7FBC6AC0 00F61022 0001 C0839300 C01E GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 C02ACB00 C02ACB00 NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54 LR [c000b060] flush_dcache_icache_page+0x20/0x30 Call trace: [c000b154] update_mmu_cache+0x7c/0xa4 [c005ae98] do_wp_page+0x460/0x5ec [c005c8a0] handle_mm_fault+0x7cc/0x91c [c005ccec] get_user_pages+0x2fc/0x65c [c0027104] access_process_vm+0x9c/0x1d4 [c00076e0] sys_ptrace+0x240/0x4a4 [c0002bd0] ret_from_syscall+0x0/0x44 From: Anton W?llert <[EMAIL PROTECTED]> Signed-off-by: Marcelo Tosatti --- a/arch/ppc/mm/init.c.orig 2005-07-20 03:05:44.0 -0300 +++ b/arch/ppc/mm/init.c2005-07-20 03:05:46.0 -0300 @@ -577,6 +577,9 @@ #ifdef CONFIG_BOOKE __flush_dcache_icache(kmap(page)); kunmap(page); +#elif CONFIG_8xx + /* On 8xx there is no need to kmap since highmem is not supported */ + __flush_dcache_icache(page_address(page)); #else __flush_dcache_icache_phys(page_to_pfn(page) << PAGE_SHIFT); #endif
swap_dup: Bad swap file entry 00480020
On Fri, Jul 22, 2005 at 10:46:38AM -0500, bogdan antonovici wrote: > Hi Dan, > > I checked the driver code. I found a pointer that was in my opinion > initialized too late and i corrected that but other than that i haven't > found anything. > I ran the driver alone, enabling the interrupts and the interrupt > routine doesn't cause any trouble. > I started my application and i haven't seen any sign of trouble. > But once i started also the snmpd after few interrupts i got the > message: > > __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) > VM: killing process sectionmond Thats a different problem: you ran out of memory and the VM can't swap out any data. So its likely that the pagetable corruption is gone (it was indeed a bug in the driver as Dan suspected). > sectionmond being my application. > My read and write driver operation are requesting a page for a buffer > but they also release it. Should i declare the buffer pointer with > volatile attribute? > Do you know what may cause that message? Out of memory condition.
[PATCH] 8xx: avoid icbi misbehaviour in __flush_dcache_icache_phys
Hi Anton, On Thu, Jul 21, 2005 at 01:34:53AM +0200, Anton W?llert wrote: > Marcelo Tosatti wrote: > >Can you please test the following which is equivalent to your > >suggest changes, the only difference being the location, contained > >inside flush_dcache_icache_page(). After confirmation that it works > >we can send up to the kernel maintainers. > > of course, i can do that :). > > >We should still try to understand why this is happening, possibly > >matching it to a published CPU errata bug, or inform Freescale > >otherwise. > > i think so too. as far as i understand it, the thing with the previous > __flush_dcache_icache&tlbie patch was that __flush_dcache_icache should > try to call dcbst on every address on a cache-line-boundary that could > reference the page to give the cpu a hint, so that the next write-access > to this page will be more effective, right? but while trying to do the > dcbst, the TLB is looked up for the addresses for a faster translation. > but here the old TLB-Entry exists, that says invalid Page or something > like that, right? So it should be invalidated before, right? Actually the dcbst instruction flushes data from cache to main memory. Quoting MPC860UM.pdf: Data Cache Block Store (dcbst) The effective address is computed, translated, and checked for protection violations as defined in the PowerPC architecture. This instruction is treated as a load with respect to address translation and memory protection. If the address hits in the cache and the cache block is in the unmodified-valid state, no action is taken. If the address hits in the cache and the cache block is in the modified-valid state, the modified block is written back to memory and the cache block is placed in the unmodified-valid state. > Question, normally the dcbst should cause a TLB-Error-Exception, > that than should do reload the TLB-Entry automatically, doesn't this > work > because of the dcb*-errata (btw. where can i found that?). I dont think that this one bug which the TLB invalidate worksaround, namely dcbst misbehaviour with invalid (zeroed) TLB, is covered by Freescale errata (I'm looking at Errata revision A.2). > And the __flush_dcache_icache should do a dcbst 4096/16=256 times, but there > are > just 64 cache-lines ? 16Byte (1Kb DCache), so shouldn't be 3/4 of that > routine redundant? and also, as it seems to me, the whole dcache will be > *flushed* or better dcbst'd trough this routine. is that right? > please correct me! See the dcbst description above, the cache line entry is only flushed if the address hits in cache _and_ is the modified state. > so, now the __flush_dcache_icache_phys(). this is just called, when the > memory-mapping of the vma is not same as the one of that from the > current process. this should be the case with ptrace. couldn't now be > done the same as above? maybe no because the address is the virtual > address as seen from the ptraced process? and so that will *flush* the > pages from the ptraced process (that doesn't exists yet?, because they > were just created for the tracing process?). Since the 8xx cache is physically indexed and tagged, you can flush memory by either its virtual address or its physical address - virtual accesses need to perform v->p translation with help from the MMU. On the ptrace case the kernel must do a physical flush because the ptraceing process does not have an equivalent virtual->physical mapping in its own address space. ie. equivalent virtual addresses from the ptracing and ptrace'd processes are obviously not physically equivalent. The change you proposed flushes the page via its kernel virtual map: page_address(page), which is similar to doing a physical flush. Only difference being that on 8xx "icbi" goes nuts when using the physical flush, as you reported. > so the pte, that was created for the tracing process is used. from that, > the physical address is calculated (how is this done, whats the magic > about the pfn-stuff etc, i didn't really understand that :( ). Actually the page being faulted in by the ptrace'ing process is a page of the _ptraced_ process, that is, one process is faulting in pages of another process. > now __flush_dcache_icache_phys is used, because the [d|i]cache uses physical > address tags and so the data-mmu could be turned off to flush these entries. > so to understand the things further, i have to understand which > addresses are used with dcbst and icbi. there is > page=pfn_to_page(pte_pfn(pte)) and (page_to_pfn(page) << PAGE_SHIFT). > but what are these values or where do they point. any hints to the > pfn&pte stuff? unfortunately i didn't have much time the last days to > understand this
platform/board removal update
On Tue, Jul 26, 2005 at 09:43:43AM -0500, Kumar Gala wrote: > > On Jul 26, 2005, at 9:35 AM, Dan Malek wrote: > > > > >On Jul 26, 2005, at 9:01 AM, Kumar Gala wrote: > > > > > >>All the other systems (apus, gemini, rpxcllf) were more effort than I > >>was wanting to deal with. > >> > > > >Why? The rpxcllf worked not long ago. What happened to the > >courtesy of > >the past when such updates were applied to all platforms such they > >would at least build? After such changes, if there is still a > >problem, > >the > >person should at least contact the maintainer to get it resolved. I > >don't > >appreciate being demanded to fix something within a short period of > >time that someone else broke or else everything I've done in the past > >will be discarded. > > Well, I think its reasonable amount of time. We are talking about > 4-6 months between now and when a 2.6.15 is likely to get released. > I'm not 100% sure who broken rpxcllf, but the issue seems to be with > the 8xx_io/fec.c driver so it should be resolved with panto's updated > driver. 8xx_io/fec.c is still using v2.4's workqueue infrastructure but other than that its working fine. The fix will be pushed upstream ASAP. BTW, we should schedule 8xx_io/fec.c for removal, but before that we ought to test all supported PHY's on the new driver. Aris was talking to me about this on OLS. Aris, what are the PHY's not supported by Panto's driver again? We should build a list of those and ask around for testers. > I'm just trying to get us back into a sane state and hopefully we > will regress building of all our defconfigs more often to catch > things sooner.
platform/board removal update
On Tue, Jul 26, 2005 at 06:14:00PM -0400, Dan Malek wrote: > > On Jul 26, 2005, at 6:05 AM, Marcelo Tosatti wrote: > > >8xx_io/fec.c is still using v2.4's workqueue infrastructure but other > >than > >that its working fine. > > I talked to panto about this earlier today. > > >The fix will be pushed upstream ASAP. > > That's OK, I'm just glad I know what it is :-) > > >BTW, we should schedule 8xx_io/fec.c for removal, but before that we > >ought to > >test all supported PHY's on the new driver. > > It will be around in old kernels if we need it for reference. Indeed. > Thanks, and good luck with the new job :-) Thanks! Be prepared to handle my questions :-)
[PATCH] 8xx: fec: fix interrupt handler prototypes
From: Aristeu Sergio Rozanski Filho <[EMAIL PROTECTED]>
8xx: fec: fix interrupt handler prototypes
Signed-off-by: Aristeu Sergio Rozanski Filho
Signed-off-by: Marcelo Tosatti
Index: 2.6-8xx/arch/ppc/8xx_io/fec.c
===
--- 2.6-8xx.orig/arch/ppc/8xx_io/fec.c 2005-07-04 11:45:57.0 -0300
+++ 2.6-8xx/arch/ppc/8xx_io/fec.c 2005-07-04 11:45:57.0 -0300
@@ -199,7 +199,8 @@
#ifdef CONFIG_USE_MDIO
static void fec_enet_mii(struct net_device *dev);
#endif /* CONFIG_USE_MDIO */
-static void fec_enet_interrupt(int irq, void * dev_id, struct pt_regs * regs);
+static irqreturn_t fec_enet_interrupt(int irq, void * dev_id,
+ struct pt_regs * regs);
#ifdef CONFIG_FEC_PACKETHOOK
static void fec_enet_tx(struct net_device *dev, __u32 regval);
static void fec_enet_rx(struct net_device *dev, __u32 regval);
@@ -471,7 +472,7 @@
/* The interrupt handler.
* This is called from the MPC core interrupt.
*/
-static void
+static irqreturn_t
fec_enet_interrupt(int irq, void * dev_id, struct pt_regs * regs)
{
struct net_device *dev = dev_id;
@@ -525,6 +526,7 @@
}
}
+ return IRQ_RETVAL(IRQ_HANDLED);
}
@@ -1403,11 +1405,11 @@
/* This interrupt occurs when the PHY detects a link change.
*/
-static void
+static
#ifdef CONFIG_RPXCLASSIC
-mii_link_interrupt(void *dev_id)
+void mii_link_interrupt(void *dev_id)
#else
-mii_link_interrupt(int irq, void * dev_id, struct pt_regs * regs)
+irqreturn_t mii_link_interrupt(int irq, void * dev_id, struct pt_regs * regs)
#endif
{
#ifdef CONFIG_USE_MDIO
@@ -1440,6 +1442,9 @@
printk("%s[%d] %s: unexpected Link interrupt\n",
__FILE__,__LINE__,__FUNCTION__);
#endif /* CONFIG_USE_MDIO */
+#ifndef CONFIG_RPXCLASSIC
+ return IRQ_RETVAL(IRQ_HANDLED);
+#endif /* CONFIG_RPXCLASSIC */
}
static int
[PATCH] 8xx: convert fec driver to use work_struct
From: Aristeu Sergio Rozanski Filho <[EMAIL PROTECTED]>
8xx: convert fec driver to use work_struct
Signed-off-by: Aristeu Sergio Rozanski Filho
Signed-off-by: Marcelo Tosatti
Index: 2.6-8xx/arch/ppc/8xx_io/fec.c
===
--- 2.6-8xx.orig/arch/ppc/8xx_io/fec.c 2005-07-04 11:40:54.0 -0300
+++ 2.6-8xx/arch/ppc/8xx_io/fec.c 2005-07-04 11:45:57.0 -0300
@@ -173,7 +173,7 @@
uintphy_status;
uintphy_speed;
phy_info_t *phy;
- struct tq_struct phy_task;
+ struct work_struct phy_task;
uintsequence_done;
@@ -1263,8 +1263,9 @@
printk(".\n");
}
-static void mii_display_config(struct net_device *dev)
+static void mii_display_config(void *priv)
{
+ struct net_device *dev = (struct net_device *)priv;
struct fec_enet_private *fep = dev->priv;
volatile uint *s = &(fep->phy_status);
@@ -1294,8 +1295,9 @@
fep->sequence_done = 1;
}
-static void mii_relink(struct net_device *dev)
+static void mii_relink(void *priv)
{
+ struct net_device *dev = (struct net_device *)priv;
struct fec_enet_private *fep = dev->priv;
int duplex;
@@ -1323,18 +1325,16 @@
{
struct fec_enet_private *fep = dev->priv;
- fep->phy_task.routine = (void *)mii_relink;
- fep->phy_task.data = dev;
- schedule_task(&fep->phy_task);
+ INIT_WORK(&fep->phy_task, mii_relink, (void *)dev);
+ schedule_work(&fep->phy_task);
}
static void mii_queue_config(uint mii_reg, struct net_device *dev)
{
struct fec_enet_private *fep = dev->priv;
- fep->phy_task.routine = (void *)mii_display_config;
- fep->phy_task.data = dev;
- schedule_task(&fep->phy_task);
+ INIT_WORK(&fep->phy_task, mii_display_config, (void *)dev);
+ schedule_work(&fep->phy_task);
}
[PATCH] 8xx: using dma_alloc_coherent() instead consistent_alloc()
From: Aristeu Sergio Rozanski Filho <[EMAIL PROTECTED]>
8xx: using dma_alloc_coherent() instead consistent_alloc()
Signed-off-by: Aristeu Sergio Rozanski Filho
Signed-off-by: Marcelo Tosatti
Index: 2.6-8xx/arch/ppc/8xx_io/fec.c
===
--- 2.6-8xx.orig/arch/ppc/8xx_io/fec.c 2005-07-04 11:45:57.0 -0300
+++ 2.6-8xx/arch/ppc/8xx_io/fec.c 2005-07-04 11:45:58.0 -0300
@@ -1580,7 +1580,7 @@
struct fec_enet_private *fep;
int i, j, k, err;
unsigned char *eap, *iap, *ba;
- unsigned long mem_addr;
+ dma_addr_t mem_addr;
volatilecbd_t *bdp;
cbd_t *cbd_base;
volatileimmap_t *immap;
@@ -1645,7 +1645,8 @@
printk("FEC initialization failed.\n");
return 1;
}
- cbd_base = (cbd_t *)consistent_alloc(GFP_KERNEL, PAGE_SIZE, &mem_addr);
+ cbd_base = (cbd_t *)dma_alloc_coherent(dev->class_dev.dev, PAGE_SIZE,
+ &mem_addr, GFP_KERNEL);
/* Set receive and transmit descriptor base.
*/
@@ -1662,7 +1663,10 @@
/* Allocate a page.
*/
- ba = (unsigned char *)consistent_alloc(GFP_KERNEL, PAGE_SIZE,
&mem_addr);
+ ba = (unsigned char *)dma_alloc_coherent(dev->class_dev.dev,
+PAGE_SIZE,
+&mem_addr,
+GFP_KERNEL);
/* BUG: no check for failure */
/* Initialize the BD for every fragment in the page.
[PATCH] MPC8xx PCMCIA driver
Thu, Sep 01, 2005 at 10:53:19AM +0200, Dominik Brodowski wrote:
> Hi,
>
> On Mon, Aug 29, 2005 at 11:48:40PM -0300, Marcelo Tosatti wrote:
> > Russell: The driver is using pccard_nonstatic_ops for card window
> > management, even though the driver its marked SS_STATIC_MAP (using
> > mem->static_map).
>
> This is obviously broken. Where does it fail if pccard_static_ops is used?
IIRC pcmcia_request_io() fails to dynamically allocate IO windows for PCMCIA
cards because find_io_region returns NULL.
OTOH, as Magnus noted, the memory windows are static:
* Because of the lacking offset register we must map the whole card.
* We assign each memory window PCMCIA_MEM_WIN_SIZE address space.
* Make sure there is (PCMCIA_MEM_WIN_SIZE * PCMCIA_MEM_WIN_NO
* * PCMCIA_SOCKETS_NO) bytes at PCMCIA_MEM_WIN_BASE.
* The i/o windows are dynamically allocated at PCMCIA_IO_WIN_BASE.
* They are maximum 64KByte each...
socket[i].socket.features = SS_CAP_PCCARD | SS_CAP_MEM_ALIGN |
SS_CAP_STATIC_MAP;
socket[i].socket.io_offset = 0;
> > +typedef struct {
> > + u_int regbit;
> > + u_int eventbit;
> > +} event_table_t;
>
> No typedefs, please.
OK, will fix.
[PATCH] add big endian version of ld_/st_ IO access macros and convert main 8xx code to use it
Hi,
The following patch adds big endian version of ld_/st_ macros
and converts core 8xx code to use them.
Other than making IO accesses explicit (which is a plus for
readability), a common set of macros provides a unified place for the
volatile flag to constraint compiler code reordering.
There are several unlucky places at the moment which lack the
volatile flag.
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -73,7 +73,7 @@ cpm_mask_irq(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr &= ~(1 << cpm_vec);
+ st_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, ld_be32(&((immap_t
*)IMAP_ADDR)->im_cpic.cpic_cimr) & ~(1 << cpm_vec));
}
static void
@@ -81,7 +81,7 @@ cpm_unmask_irq(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr |= (1 << cpm_vec);
+ st_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, ld_be32(&((immap_t
*)IMAP_ADDR)->im_cpic.cpic_cimr) | (1 << cpm_vec));
}
static void
@@ -95,7 +95,7 @@ cpm_eoi(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cisr = (1 << cpm_vec);
+ st_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cisr, (1 << cpm_vec));
}
struct hw_interrupt_type cpm_pic = {
@@ -133,7 +133,7 @@ m8xx_cpm_reset(void)
* manual recommends it.
* Bit 25, FAM can also be set to use FEC aggressive mode (860T).
*/
- imp->im_siu_conf.sc_sdcr = 1;
+ st_be32(&imp->im_siu_conf.sc_sdcr, 1);
/* Reclaim the DP memory for our use. */
m8xx_cpm_dpinit();
@@ -178,10 +178,10 @@ cpm_interrupt_init(void)
/* Initialize the CPM interrupt controller.
*/
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr =
+ st_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr,
(CICR_SCD_SCC4 | CICR_SCC_SCC3 | CICR_SCB_SCC2 | CICR_SCA_SCC1) |
- ((CPM_INTERRUPT/2) << 13) | CICR_HP_MASK;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr = 0;
+ ((CPM_INTERRUPT/2) << 13) | CICR_HP_MASK);
+ st_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, 0);
/* install the CPM interrupt controller routines for the CPM
* interrupt vectors
@@ -198,7 +198,7 @@ cpm_interrupt_init(void)
if (setup_irq(CPM_IRQ_OFFSET + CPMVEC_ERROR, &cpm_error_irqaction))
panic("Could not allocate CPM error IRQ!");
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr |= CICR_IEN;
+ st_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr, ld_be32(&((immap_t
*)IMAP_ADDR)->im_cpic.cpic_cicr) | CICR_IEN);
}
/*
@@ -212,8 +212,8 @@ cpm_get_irq(struct pt_regs *regs)
/* Get the vector by setting the ACK bit and then reading
* the register.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr = 1;
- cpm_vec = ((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr;
+ st_be16(&((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr, 1);
+ cpm_vec = ld_be16(&((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr);
cpm_vec >>= 11;
return cpm_vec;
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -144,12 +144,12 @@ void __init m8xx_calibrate_decr(void)
int freq, fp, divisor;
/* Unlock the SCCR. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = KAPWR_KEY;
+ st_be32(&((immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk, ~KAPWR_KEY);
+ st_be32(&((immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk, KAPWR_KEY);
/* Force all 8xx processors to use divide by 16 processor clock. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrst.car_sccr |= 0x0200;
-
+ st_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_sccr,
+ ld_be32(&((immap_t
*)IMAP_ADDR)->im_clkrst.car_sccr)|0x0200);
/* Processor frequency is MHz.
* The value 'fp' is the number of decrementer ticks per second.
*/
@@ -175,28 +175,24 @@ void __init m8xx_calibrate_decr(void)
* we guarantee the registers are locked, then we unlock them
* for our use.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk= ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk= KAPWR_KEY;
+ st_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk, ~KAPWR_KEY);
+ st_be32(&((immap_t *)IMAP_ADDR)->im_s
[PATCH] add big endian version of ld_/st_ IO access macros and convert main 8xx code to use it
On Thu, Sep 08, 2005 at 10:28:52AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2005-09-07 at 20:03 -0300, Marcelo Tosatti wrote:
> > Hi,
> >
> > The following patch adds big endian version of ld_/st_ macros
> > and converts core 8xx code to use them.
> >
> > Other than making IO accesses explicit (which is a plus for
> > readability), a common set of macros provides a unified place for the
> > volatile flag to constraint compiler code reordering.
> >
> > There are several unlucky places at the moment which lack the
> > volatile flag.
>
> I'm not fan of the approach. You should use in_/out_ macros for IOs. If
> you don't need eieio on 8xx , then just #ifdef it out of the
> implementation of these.
The reason for that is that in_/out_ are supposed to be the standard
IO macros (conformance)? In practice most drivers using the std macros
can benefit from the change.
A common routine is shared by all architectures. Doing something like
/*
* 8, 16 and 32 bit, big and little endian I/O operations, with barrier.
*/
extern inline int in_8(volatile unsigned char __iomem *addr)
{
int ret;
__asm__ __volatile__(
"lbz%U1%X1 %0,%1;\n"
#ifndef CONFIG_8xx
"twi 0,%0,0;\n"
"isync" : "=r" (ret) : "m" (*addr));
#else
: "=r" (ret) : "m" (*addr));
#endif
return ret;
}
Seems somewhat ugly?
[PATCH] add big endian version of ld_/st_ IO access macros and convert main 8xx code to use it
On Wed, Sep 07, 2005 at 08:42:42PM -0400, Dan Malek wrote: > > On Sep 7, 2005, at 8:28 PM, Benjamin Herrenschmidt wrote: > > >I'm not fan of the approach. You should use in_/out_ macros for IOs. If > >you don't need eieio on 8xx , then just #ifdef it out of the > >implementation of these. > > Yeah, #ifdef :-) That patch wouldn't go anywhere (well, > to /dev/null perhaps). Well, its easy to s/st/out/ - s/ld/in/, so its still a useful patch. ;) > We can just use the in_/out_ macros that are there. The eieio > doesn't hurt anything on the 8xx. eieio/isync are not required. There's no need to execute redudant instructions and occupy kernel space.
[PATCH] add big endian version of ld_/st_ IO access macros and convert main 8xx code to use it
On Thu, Sep 08, 2005 at 02:27:11PM +1000, Paul Mackerras wrote:
> Marcelo Tosatti writes:
>
> > eieio/isync are not required. There's no need to execute redudant
> > instructions and occupy kernel space.
>
> Given how long it takes to access I/O devices, I don't believe an
> extra instruction or two is going to make a measurable difference.
> Feel free to show me measurements proving me wrong, of course... :)
I will try to measure it later on and change out_/in_ macros as
suggested.
For now are there any objections against this? Otherwise I'll merge it.
There are a few more places which need conversion, plan to change them
later on also.
Thanks everyone.
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -73,7 +73,7 @@ cpm_mask_irq(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr &= ~(1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, in_be32(&((immap_t
*)IMAP_ADDR)->im_cpic.cpic_cimr) & ~(1 << cpm_vec));
}
static void
@@ -81,7 +81,7 @@ cpm_unmask_irq(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr |= (1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, in_be32(&((immap_t
*)IMAP_ADDR)->im_cpic.cpic_cimr) | (1 << cpm_vec));
}
static void
@@ -95,7 +95,7 @@ cpm_eoi(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cisr = (1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cisr, (1 << cpm_vec));
}
struct hw_interrupt_type cpm_pic = {
@@ -133,7 +133,7 @@ m8xx_cpm_reset(void)
* manual recommends it.
* Bit 25, FAM can also be set to use FEC aggressive mode (860T).
*/
- imp->im_siu_conf.sc_sdcr = 1;
+ out_be32(&imp->im_siu_conf.sc_sdcr, 1),
/* Reclaim the DP memory for our use. */
m8xx_cpm_dpinit();
@@ -178,10 +178,10 @@ cpm_interrupt_init(void)
/* Initialize the CPM interrupt controller.
*/
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr =
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr,
(CICR_SCD_SCC4 | CICR_SCC_SCC3 | CICR_SCB_SCC2 | CICR_SCA_SCC1) |
- ((CPM_INTERRUPT/2) << 13) | CICR_HP_MASK;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr = 0;
+ ((CPM_INTERRUPT/2) << 13) | CICR_HP_MASK);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, 0);
/* install the CPM interrupt controller routines for the CPM
* interrupt vectors
@@ -198,7 +198,7 @@ cpm_interrupt_init(void)
if (setup_irq(CPM_IRQ_OFFSET + CPMVEC_ERROR, &cpm_error_irqaction))
panic("Could not allocate CPM error IRQ!");
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr |= CICR_IEN;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr, in_be32(&((immap_t
*)IMAP_ADDR)->im_cpic.cpic_cicr) | CICR_IEN);
}
/*
@@ -212,8 +212,8 @@ cpm_get_irq(struct pt_regs *regs)
/* Get the vector by setting the ACK bit and then reading
* the register.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr = 1;
- cpm_vec = ((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr;
+ out_be16(&((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr, 1);
+ cpm_vec = in_be16(&((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr);
cpm_vec >>= 11;
return cpm_vec;
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -144,12 +144,12 @@ void __init m8xx_calibrate_decr(void)
int freq, fp, divisor;
/* Unlock the SCCR. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = KAPWR_KEY;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk, KAPWR_KEY);
/* Force all 8xx processors to use divide by 16 processor clock. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrst.car_sccr |= 0x0200;
-
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_sccr,
+ in_be32(&((immap_t
*)IMAP_ADDR)->im_clkrst.car_sccr)|0x0200);
/* Processor frequency is MHz.
* The value 'fp' is the number of decrementer ticks per second.
*/
@@ -175,28 +175,24 @@ void __init m8xx_calibrate_decr(void)
* we g
gdb hangs on Linux 2.6.11 on 8xx
Folks, Can you please upgrade to a recent kernel? A problem with ptrace has been fixed sometime ago, it might be what you're hitting. The fix is part of v2.6.13: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bf85fa6c878aa3968df47d7f70a2b506c3e53b99 If that does not work, complain. On Tue, Sep 13, 2005 at 09:25:41AM -0300, Aristeu Sergio Rozanski Filho wrote: > > I am running Linux 2.6.11 on a TQM823L development board. I find that > > gdb (version 6.3) hangs when I try to run an application - any > > application, even a simple helloworld. It's not just gdb hanging, the > > whole system is stone dead. > "me too" > actually the system is not completely dead, you still can use sysrq keys. > Tried to use gdbserver too, but it also doesn't work (hangs after the first > breakpoint and timeouts). > > gdb S 30106778 0 691687 692 (NOTLB) > Call trace: > [c0005330] __switch_to+0x44/0x78 > [c015beb0] schedule+0x30c/0x730 > [c015c888] schedule_timeout+0xdc/0xe0 > [c0068918] sys_poll+0x27c/0x404 > [c0002810] syscall_dotrace_cont+0x24/0x38 > flash_testt 19E4 0 692691 (NOTLB) > Call trace: > [c0005330] __switch_to+0x44/0x78 > [c015beb0] schedule+0x30c/0x730 > [c0026248] ptrace_stop+0x68/0x88 > [c0026604] get_signal_to_deliver+0x130/0x2b4 > [c00063dc] do_signal+0x38/0x464 > [c0003034] do_user_signal+0x74/0xc4 > > -- > Aristeu > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
gdb hangs on Linux 2.6.11 on 8xx
On Tue, Sep 13, 2005 at 09:25:41AM -0300, Aristeu Sergio Rozanski Filho wrote: > > I am running Linux 2.6.11 on a TQM823L development board. I find that > > gdb (version 6.3) hangs when I try to run an application - any > > application, even a simple helloworld. It's not just gdb hanging, the > > whole system is stone dead. > "me too" > actually the system is not completely dead, you still can use sysrq keys. > Tried to use gdbserver too, but it also doesn't work (hangs after the first > breakpoint and timeouts). > > gdb S 30106778 0 691687 692 (NOTLB) > Call trace: > [c0005330] __switch_to+0x44/0x78 > [c015beb0] schedule+0x30c/0x730 > [c015c888] schedule_timeout+0xdc/0xe0 > [c0068918] sys_poll+0x27c/0x404 > [c0002810] syscall_dotrace_cont+0x24/0x38 > flash_testt 19E4 0 692691 (NOTLB) > Call trace: > [c0005330] __switch_to+0x44/0x78 > [c015beb0] schedule+0x30c/0x730 > [c0026248] ptrace_stop+0x68/0x88 > [c0026604] get_signal_to_deliver+0x130/0x2b4 > [c00063dc] do_signal+0x38/0x464 > [c0003034] do_user_signal+0x74/0xc4 Aris, How does the disassemble of __switch_to looks like? Chris oopsen is exactly what the 'icbi' patch fixes. Maybe this is an additional problem then. SysRq : Show Regs NIP: C00047BC LR: C000A0C0 SP: C09FBDD0 REGS: c09fbd20 TRAP: 0501Not tainted MSR: 9022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10 TASK = c031f3e0[187] 'gdb' THREAD: c09fa000 Last syscall: 26 GPR00: 9022 C09FBDD0 C031F3E0 00589000 0100 C01F3000 00588000 808B GPR08: 3860 C01D 9032 B100 33003035 NIP [c00047bc] __flush_dcache_icache_phys+0x38/0x54 LR [c000a0c0] flush_dcache_icache_page+0x20/0x30 Call trace: [c000a17c] update_mmu_cache+0x68/0x98 [c003dbe8] do_wp_page+0x184/0x3a4 [c003ebc8] handle_mm_fault+0x29c/0x42c [c003ee7c] get_user_pages+0x124/0x428 [c001a030] access_process_vm+0xfc/0x1bc [c0006680] sys_ptrace+0x22c/0x4b4 [c0002590] ret_from_syscall+0x0/0x44
__switch_to test-and-branch ALTIVEC specific?
Hi, This test&branch looks AltiVec specific, any reason for not #ifdef'ing it out? --- arch/ppc/kernel/process.c.orig 2005-09-13 14:43:13.0 -0300 +++ arch/ppc/kernel/process.c 2005-09-13 14:43:51.0 -0300 @@ -287,11 +287,13 @@ struct task_struct *__switch_to(struct t #endif /* CONFIG_SPE */ #endif /* CONFIG_SMP */ +#ifdef CONFIG_ALTIVEC /* Avoid the trap. On smp this this never happens since * we don't set last_task_used_altivec -- Cort */ if (new->thread.regs && last_task_used_altivec == new) new->thread.regs->msr |= MSR_VEC; +#endif #ifdef CONFIG_SPE /* Avoid the trap. On smp this this never happens since * we don't set last_task_used_spe
gdb hangs on Linux 2.6.11 on 8xx
On Tue, Sep 13, 2005 at 02:22:13PM -0300, Aristeu Sergio Rozanski Filho wrote:
> Hi Marcelo,
> after the last Chris post, I decided to double check if I wasn't doing
> something wrong. vanilla 2.6.13 hangs in the same way my patched 2.6.10 does.
>
> > How does the disassemble of __switch_to looks like?
> from 2.6.13 kernel
> Dump of assembler code for function __switch_to:
> 0xc00055a4 <__switch_to+0>: mflrr0
> 0xc00055a8 <__switch_to+4>: stwur1,-16(r1)
> 0xc00055ac <__switch_to+8>: stw r31,12(r1)
> 0xc00055b0 <__switch_to+12>:mr r11,r4
> 0xc00055b4 <__switch_to+16>:stw r0,20(r1)
> 0xc00055b8 <__switch_to+20>:mfmsr r31
> 0xc00055bc <__switch_to+24>:rlwinm r0,r31,0,17,15
> 0xc00055c0 <__switch_to+28>:mtmsr r0
> 0xc00055c4 <__switch_to+32>:lwz r10,460(r4)
> 0xc00055c8 <__switch_to+36>:addir3,r2,456
> 0xc00055cc <__switch_to+40>:addir4,r4,456
> 0xc00055d0 <__switch_to+44>:cmpwi cr7,r10,0
> 0xc00055d4 <__switch_to+48>:beq-cr7,0xc00055e8 <__switch_to+68>
> 0xc00055d8 <__switch_to+52>:lis r9,-16354
> 0xc00055dc <__switch_to+56>:lwz r0,28880(r9)
> 0xc00055e0 <__switch_to+60>:cmpwcr7,r0,r11
> 0xc00055e4 <__switch_to+64>:beq-cr7,0xc0005604 <__switch_to+96>
> 0xc00055e8 <__switch_to+68>:bl 0xc0003024 <_switch>
> 0xc00055ec <__switch_to+72>:mtmsr r31
> 0xc00055f0 <__switch_to+76>:lwz r0,20(r1)
> 0xc00055f4 <__switch_to+80>:lwz r31,12(r1)
> 0xc00055f8 <__switch_to+84>:addir1,r1,16
> 0xc00055fc <__switch_to+88>:mtlrr0
> 0xc0005600 <__switch_to+92>:blr
> 0xc0005604 <__switch_to+96>:lwz r0,132(r10)
> 0xc0005608 <__switch_to+100>: orisr0,r0,512
> 0xc000560c <__switch_to+104>: stw r0,132(r10)
> 0xc0005610 <__switch_to+108>: b 0xc00055e8 <__switch_to+68>
> End of assembler dump.
>
> > Chris oopsen is exactly what the 'icbi' patch fixes.
> notice that what I'm having here is not an oops
>
> but if for Chris works, I must be doing something wrong, sorry for the noise
Hi Aris,
gdb S 30106778 0 691687 692 (NOTLB)
Call trace:
[c0005330] __switch_to+0x44/0x78
[c015beb0] schedule+0x30c/0x730
[c015c888] schedule_timeout+0xdc/0xe0
[c0068918] sys_poll+0x27c/0x404
[c0002810] syscall_dotrace_cont+0x24/0x38
flash_testt 19E4 0 692691 (NOTLB)
Call trace:
[c0005330] __switch_to+0x44/0x78
[c015beb0] schedule+0x30c/0x730
[c0026248] ptrace_stop+0x68/0x88
[c0026604] get_signal_to_deliver+0x130/0x2b4
[c00063dc] do_signal+0x38/0x464
[c0003034] do_user_signal+0x74/0xc4
flash_test is trying to handle a signal, can you print some information
about it in get_signal_to_deliver (before ptrace_stop), such as si_signo:
typedef struct siginfo {
int si_signo;
int si_errno;
int si_code;
ptrace_stop() calls do_notify_parent_cldstop() to wakeup gdb, maybe
there's something wrong during wakeup?
The box locks up completly or its just gdb that freezes?
[PATCH] ppc32 8xx: use io accessor macros instead of direct memory reference
Convert core 8xx drivers to use in_xxxbe/in_xxx macros instead
of direct memory references.
Other than making IO accesses explicit (which is a plus for
readability), a common set of macros provides a unified place for the
volatile flag to constraint compiler code reordering.
There are several unlucky places at the moment which lack the
volatile flag.
Signed-off-by: Marcelo Tosatti
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -73,7 +73,7 @@ cpm_mask_irq(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr &= ~(1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, in_be32(&((immap_t
*)IMAP_ADDR)->im_cpic.cpic_cimr) & ~(1 << cpm_vec));
}
static void
@@ -81,7 +81,7 @@ cpm_unmask_irq(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr |= (1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, in_be32(&((immap_t
*)IMAP_ADDR)->im_cpic.cpic_cimr) | (1 << cpm_vec));
}
static void
@@ -95,7 +95,7 @@ cpm_eoi(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cisr = (1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cisr, (1 << cpm_vec));
}
struct hw_interrupt_type cpm_pic = {
@@ -133,7 +133,7 @@ m8xx_cpm_reset(void)
* manual recommends it.
* Bit 25, FAM can also be set to use FEC aggressive mode (860T).
*/
- imp->im_siu_conf.sc_sdcr = 1;
+ out_be32(&imp->im_siu_conf.sc_sdcr, 1),
/* Reclaim the DP memory for our use. */
m8xx_cpm_dpinit();
@@ -178,10 +178,10 @@ cpm_interrupt_init(void)
/* Initialize the CPM interrupt controller.
*/
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr =
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr,
(CICR_SCD_SCC4 | CICR_SCC_SCC3 | CICR_SCB_SCC2 | CICR_SCA_SCC1) |
- ((CPM_INTERRUPT/2) << 13) | CICR_HP_MASK;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr = 0;
+ ((CPM_INTERRUPT/2) << 13) | CICR_HP_MASK);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, 0);
/* install the CPM interrupt controller routines for the CPM
* interrupt vectors
@@ -198,7 +198,7 @@ cpm_interrupt_init(void)
if (setup_irq(CPM_IRQ_OFFSET + CPMVEC_ERROR, &cpm_error_irqaction))
panic("Could not allocate CPM error IRQ!");
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr |= CICR_IEN;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr, in_be32(&((immap_t
*)IMAP_ADDR)->im_cpic.cpic_cicr) | CICR_IEN);
}
/*
@@ -212,8 +212,8 @@ cpm_get_irq(struct pt_regs *regs)
/* Get the vector by setting the ACK bit and then reading
* the register.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr = 1;
- cpm_vec = ((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr;
+ out_be16(&((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr, 1);
+ cpm_vec = in_be16(&((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr);
cpm_vec >>= 11;
return cpm_vec;
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -144,12 +144,12 @@ void __init m8xx_calibrate_decr(void)
int freq, fp, divisor;
/* Unlock the SCCR. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = KAPWR_KEY;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk, KAPWR_KEY);
/* Force all 8xx processors to use divide by 16 processor clock. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrst.car_sccr |= 0x0200;
-
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_sccr,
+ in_be32(&((immap_t
*)IMAP_ADDR)->im_clkrst.car_sccr)|0x0200);
/* Processor frequency is MHz.
* The value 'fp' is the number of decrementer ticks per second.
*/
@@ -175,28 +175,24 @@ void __init m8xx_calibrate_decr(void)
* we guarantee the registers are locked, then we unlock them
* for our use.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk= ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk = KAPWR_K
__switch_to test-and-branch ALTIVEC specific?
On Tue, Sep 13, 2005 at 02:05:57PM -0500, Kumar Gala wrote: > This probably has to due with what happens on a G4 system with a > kernel not build with Altivec.. However, I dont remember exactly what > behavior is desired. What would be the appropriate set of definitions to use, then ? #if defined (CONFIG_ALTIVEC || CONFIG_6xx) ?
[PATCH] MPC8xx PCMCIA driver
On Thu, Sep 01, 2005 at 10:53:19AM +0200, Dominik Brodowski wrote:
> > +typedef struct {
> > + u_int regbit;
> > + u_int eventbit;
> > +} event_table_t;
>
> No typedefs, please.
OK, I've converted it to a plain "struct".
I think this code is just following PCMCIA style:
typedef struct pccard_mem_map {
u_char map;
u_char flags;
u_short speed;
u_long static_start;
u_int card_start;
struct resource *res;
} pccard_mem_map;
Any reason why this typedef and similar ones in ss.h
are wanted?
PCMCIA is also using u_xxx "weird data types" extensively.
[PATCH] MPC8xx PCMCIA driver
Here is an uptodated version of the MPC8xx PCMCIA driver for v2.6,
addressing comments by Jeff and Dominik:
- use IO accessors instead of direct device memory referencing
- avoid usage of non-standard "uint/uchar" data types
- kill struct typedef's
Will submit it for inclusion once v2.6.14 is out.
Testing on 8xx platforms is more than welcome! Works like a charm
on our custom hardware (CONFIG_PRxK).
diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -154,6 +154,16 @@ config TCIC
"Bridge" is the name used for the hardware inside your computer that
PCMCIA cards are plugged into. If unsure, say N.
+config PCMCIA_M8XX
+tristate "MPC8xx PCMCIA support"
+depends on PCMCIA && PPC
+select PCCARD_NONSTATIC
+help
+Say Y here to include support for PowerPC 8xx series PCMCIA
+controller.
+
+This driver is also available as a module called m8xx_pcmcia.
+
config HD64465_PCMCIA
tristate "HD64465 host bridge support"
depends on HD64465 && PCMCIA
diff --git a/drivers/pcmcia/Makefile b/drivers/pcmcia/Makefile
--- a/drivers/pcmcia/Makefile
+++ b/drivers/pcmcia/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_PD6729) += pd6729.o
obj-$(CONFIG_I82365) += i82365.o
obj-$(CONFIG_I82092) += i82092.o
obj-$(CONFIG_TCIC) += tcic.o
+obj-$(CONFIG_PCMCIA_M8XX) += m8xx_pcmcia.o
obj-$(CONFIG_HD64465_PCMCIA) += hd64465_ss.o
obj-$(CONFIG_PCMCIA_SA1100)+= sa11xx_core.o sa1100_cs.o
obj-$(CONFIG_PCMCIA_SA)+= sa11xx_core.o sa_cs.o
diff --git a/drivers/pcmcia/m8xx_pcmcia.c b/drivers/pcmcia/m8xx_pcmcia.c
new file mode 100644
--- /dev/null
+++ b/drivers/pcmcia/m8xx_pcmcia.c
@@ -0,0 +1,1290 @@
+/*
+ * m8xx_pcmcia.c - Linux PCMCIA socket driver for the mpc8xx series.
+ *
+ * (C) 1999-2000 Magnus Damm
+ * (C) 2001-2002 Montavista Software, Inc.
+ *
+ *
+ * Support for two slots by Cyclades Corporation
+ *
+ * Further fixes, v2.6 kernel port
+ *
+ *
+ * "The ExCA standard specifies that socket controllers should provide
+ * two IO and five memory windows per socket, which can be independently
+ * configured and positioned in the host address space and mapped to
+ * arbitrary segments of card address space. " - David A Hinds. 1999
+ *
+ * This controller does _not_ meet the ExCA standard.
+ *
+ * m8xx pcmcia controller brief info:
+ * + 8 windows (attrib, mem, i/o)
+ * + up to two slots (SLOT_A and SLOT_B)
+ * + inputpins, outputpins, event and mask registers.
+ * - no offset register. sigh.
+ *
+ * Because of the lacking offset register we must map the whole card.
+ * We assign each memory window PCMCIA_MEM_WIN_SIZE address space.
+ * Make sure there is (PCMCIA_MEM_WIN_SIZE * PCMCIA_MEM_WIN_NO
+ * * PCMCIA_SOCKETS_NO) bytes at PCMCIA_MEM_WIN_BASE.
+ * The i/o windows are dynamically allocated at PCMCIA_IO_WIN_BASE.
+ * They are maximum 64KByte each...
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#ifdef PCMCIA_DEBUG
+static int pc_debug = PCMCIA_DEBUG;
+module_param(pc_debug, int, 0);
+#define dprintk(args...) printk(KERN_DEBUG "m8xx_pcmcia: " args);
+#else
+#define dprintk(args...)
+#endif
+
+#define pcmcia_info(args...) printk(KERN_INFO "m8xx_pcmcia: "args)
+#define pcmcia_error(args...) printk(KERN_ERR "m8xx_pcmcia: "args)
+
+static const char *version = "Version 0.06, Aug 2005";
+MODULE_LICENSE("Dual MPL/GPL");
+
+#if !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B)
+
+/* The RPX series use SLOT_B */
+#if defined(CONFIG_RPXCLASSIC) || defined(CONFIG_RPXLITE)
+#define CONFIG_PCMCIA_SLOT_B
+#define CONFIG_BD_IS_MHZ
+#endif
+
+/* The ADS board use SLOT_A */
+#ifdef CONFIG_ADS
+#define CONFIG_PCMCIA_SLOT_A
+#define CONFIG_BD_IS_MHZ
+#endif
+
+/* The FADS series are a mess */
+#ifdef CONFIG_FADS
+#if defined(CONFIG_MPC860T) || defined(CONFIG_MPC860) || defined(CONFIG_MPC821)
+#define CONFIG_PCMCIA_SLOT_A
+#else
+#define CONFIG_PCMCIA_SLOT_B
+#endif
+#endif
+
+/* Cyclades ACS uses both slots */
+#ifdef CONFIG_PRxK
+#define CONFIG_PCMCIA_SLOT_A
+#define CONFIG_PCMCIA_SLOT_B
+#endif
+
+#endif /* !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B) */
+
+#if defined(CONFIG_PCMCIA_SLOT_A) && defined(CONFIG_PCMCIA_SLOT_B)
+
+#define PCMCIA_SOCKETS_NO 2
+/* We have only 8 windows, dualsocket support will be limited. */
+#define PCMCIA_MEM_WIN_NO 2
+#define PCMCIA_IO_WIN_NO 2
+#define PCMCIA_SLOT_MSG "SLOT_A and SLOT_B"
+
+#elif defined(CONFIG_PCMCIA_SLOT_A) || defined(CONFIG_PCMCIA_SLOT_B)
+
+#define PCMCIA_SOCKE
gdb hangs on Linux 2.6.11 on 8xx
On Wed, Sep 14, 2005 at 12:42:18PM -0300, Aristeu Sergio Rozanski Filho wrote:
> Hi Marcelo,
>
> > flash_test is trying to handle a signal, can you print some information
> > about it in get_signal_to_deliver (before ptrace_stop), such as si_signo:
> >
> > typedef struct siginfo {
> > int si_signo;
> > int si_errno;
> > int si_code;
> >
> > ptrace_stop() calls do_notify_parent_cldstop() to wakeup gdb, maybe
> > there's something wrong during wakeup?
> >
> > The box locks up completly or its just gdb that freezes?
> seems it's more simple than I thought: seems to be a problem with serial
> console as I'm able to use gdb using ssh
> Is serial console (using ttyCPM) supposed to work with gdb?
Using a different device than the one used by the serial console? Yes,
think so..
[PATCH] cpm_uart: make dpram allocation actually work
On Tue, Aug 02, 2005 at 07:09:45PM +0300, Pantelis Antoniou wrote: > Hi Marcelo > > While the idea of allocating console buffers from dpram is sound, > the initial implementation didn't actually work :) > > The following patch fixes it (tested and booted on 2.6.13-rc4). OK thanks Panto. Despite my limited knowledge here, Vitaly's merged patch looks fine. I suppose someone (Kumar?) is going to send it upstream now?
[PATCH] 8xx: port i2c-algo-8xx to 2.6
On Sat, Aug 06, 2005 at 03:01:31PM -0300, Aristeu Sergio Rozanski Filho wrote:
> 8xx: port i2c-algo_8xx to 2.6
>
> Based on Tom Rini's work
>
> compile tested
Would be good to test before submitting? :)
> Signed-off-by: Aristeu Sergio Rozanski Filho
>
> Index: 2.6-8xx/drivers/i2c/algos/i2c-algo-8xx.c
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ 2.6-8xx/drivers/i2c/algos/i2c-algo-8xx.c 2005-08-05 17:16:08.0
> -0300
> @@ -0,0 +1,625 @@
> +/*
> + * i2c-algo-8xx.c i2x driver algorithms for MPC8XX CPM
> + * Copyright (c) 1999 Dan Malek (dmalek at jlc.net).
> + *
> +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.
> +
> +This program is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with this program; if not, write to the Free Software
> +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + *
> + * moved into proper i2c interface; separated out platform specific
> + * parts into i2c-rpx.c
> + * Brad Parker (brad at heeltoe.com)
> + */
> +
> +// XXX todo
> +// timeout sleep?
> +
> +/* $Id: i2c-algo-8xx.c,v 1.7 2002/08/03 22:48:18 ac9410 Exp $ */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define CPM_MAX_READ 513
> +/* Try uncomment this if you have an older CPU(earlier than rev D4) */
> +/* #define I2C_CHIP_ERRATA */
> +
> +static char *module_name = "i2c_algo_8xx";
> +#define DEBUGP(level, x, y...) do { \
> + if (cpm_debug >= level) \
> + printk(KERN_DEBUG "%s: " x, \
> +module_name, ## y); \
> + } while(0)
> +
> +static wait_queue_head_t iic_wait;
> +static ushort r_tbase, r_rbase;
> +
> +int cpm_scan = 0;
> +int cpm_debug = 0;
> +
> +static void
> +cpm_iic_interrupt(void *dev_id, struct pt_regs *regs)
> + {
> + volatile i2c8xx_t *i2c = (i2c8xx_t *)dev_id;
You got an extra space everywhere other than the initial TAB?
[PATCH] 8xx: add cpm_get_cpmp()
Aris,
It already is exported, declared as
commproc.h:extern cpm8xx_t*cpmp; /* Pointer to comm
processor */
and many drivers use the pointer directly.
arch/ppc/8260_io/ drivers also use the same convention.
Not sure I see much advantage in changing it?
On Sat, Aug 06, 2005 at 03:03:53PM -0300, Aristeu Sergio Rozanski Filho wrote:
> 8xx: add cpm_get_cpmp() to make cpmp visible to modules
>
> Signed-off-by: Aristeu Sergio Rozanski Filho
>
> Index: 2.6-8xx/arch/ppc/8xx_io/commproc.c
> ===
> --- 2.6-8xx.orig/arch/ppc/8xx_io/commproc.c 2005-08-03 17:26:05.0
> -0300
> +++ 2.6-8xx/arch/ppc/8xx_io/commproc.c2005-08-05 17:13:21.0
> -0300
> @@ -462,3 +462,10 @@
> return ((immap_t *)IMAP_ADDR)->im_cpm.cp_dpmem + offset;
> }
> EXPORT_SYMBOL(cpm_dpram_addr);
> +
> +cpm8xx_t *cpm_get_cpmp(void)
> +{
> + return cpmp;
> +}
> +EXPORT_SYMBOL(cpm_get_cpmp);
> +
> Index: 2.6-8xx/include/asm/commproc.h
> ===
> --- 2.6-8xx.orig/include/asm/commproc.h 2005-07-28 12:06:51.0
> -0300
> +++ 2.6-8xx/include/asm/commproc.h2005-08-05 17:14:28.0 -0300
> @@ -78,6 +78,7 @@
> extern void cpm_dpdump(void);
> extern void *cpm_dpram_addr(uint offset);
> extern void cpm_setbrg(uint brg, uint rate);
> +extern cpm8xx_t *cpm_get_cpmp(void);
>
> extern uint m8xx_cpm_hostalloc(uint size);
> extern int m8xx_cpm_hostfree(uint start);
[PATCH] 8xx: add cpm_get_cpmp()
On Sat, Aug 06, 2005 at 08:42:44PM -0300, Aristeu Sergio Rozanski Filho wrote: > > It already is exported, declared as > > > > commproc.h:extern cpm8xx_t*cpmp; /* Pointer to comm > > processor */ > > > > > > and many drivers use the pointer directly. > > > > arch/ppc/8260_io/ drivers also use the same convention. > > > > Not sure I see much advantage in changing it? > but not with EXPORT_SYMBOL(). I noticed this while compiling i2c stuff > as module. Then other modules suffer from the same problem - what if you EXPORT_SYMBOL(cpmp)? > also, I think it's better add a function to do this instead > doing EXPORT_SYMBOL() in a variable. > what you think? Well it is better in theory because it hides details, but in practice I'm not sure its worth it - the CPM pointer (along with the whole immap) never changes during runtime.
Volunteers to test i2c-algo-8xx on v2.6?
On Sat, Aug 06, 2005 at 09:08:15PM -0300, Aristeu Sergio Rozanski Filho wrote:
> > Would be good to test before submitting? :)
> I would like but I don't have the hardware and Alex (who reported this
> on bugzilla) told me he doesn't have it anymore. feel free to discard it
> until someone tests it
Does anyone volunteer to test this 8xx i2c driver?
>
> > > +static void
> > > +cpm_iic_interrupt(void *dev_id, struct pt_regs *regs)
> > > + {
> > > + volatile i2c8xx_t *i2c = (i2c8xx_t *)dev_id;
> >
> > You got an extra space everywhere other than the initial TAB?
> fixed this and others I found in the file, patch attached
>
> --
> Aristeu
>
> 8xx: port i2c-algo_8xx to 2.6
>
> Based on Tom Rini's work
>
> Signed-off-by: Aristeu Sergio Rozanski Filho
>
> Index: 8xx/drivers/i2c/algos/i2c-algo-8xx.c
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ 8xx/drivers/i2c/algos/i2c-algo-8xx.c 2005-08-06 21:04:37.0
> -0300
> @@ -0,0 +1,625 @@
> +/*
> + * i2c-algo-8xx.c i2x driver algorithms for MPC8XX CPM
> + * Copyright (c) 1999 Dan Malek (dmalek at jlc.net).
> + *
> +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.
> +
> +This program is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with this program; if not, write to the Free Software
> +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + *
> + * moved into proper i2c interface; separated out platform specific
> + * parts into i2c-rpx.c
> + * Brad Parker (brad at heeltoe.com)
> + */
> +
> +// XXX todo
> +// timeout sleep?
> +
> +/* $Id: i2c-algo-8xx.c,v 1.7 2002/08/03 22:48:18 ac9410 Exp $ */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define CPM_MAX_READ 513
> +/* Try uncomment this if you have an older CPU(earlier than rev D4) */
> +/* #define I2C_CHIP_ERRATA */
> +
> +static char *module_name = "i2c_algo_8xx";
> +#define DEBUGP(level, x, y...) do { \
> + if (cpm_debug >= level) \
> + printk(KERN_DEBUG "%s: " x, \
> +module_name, ## y); \
> + } while(0)
> +
> +static wait_queue_head_t iic_wait;
> +static ushort r_tbase, r_rbase;
> +
> +int cpm_scan = 0;
> +int cpm_debug = 0;
> +
> +static void
> +cpm_iic_interrupt(void *dev_id, struct pt_regs *regs)
> +{
> + volatile i2c8xx_t *i2c = (i2c8xx_t *)dev_id;
> +
> + DEBUGP(2, "cpm_iic_interrupt(dev_id=%p)\n", dev_id);
> +
> +#ifdef I2C_CHIP_ERRATA
> + /* Chip errata, clear enable.
> + * This seems to not be needed on rev D4 or newer CPUs.
> + * Someone with an older CPU needs to verify this.
> + */
> + i2c->i2c_i2mod &= ~1;
> +#endif
> +
> + /* Clear interrupt.
> + */
> + i2c->i2c_i2cer = 0xff;
> +
> + /* Get 'me going again.
> + */
> + wake_up_interruptible(&iic_wait);
> +}
> +
> +static void
> +cpm_iic_init(struct i2c_algo_8xx_data *cpm_adap)
> +{
> + volatile iic_t *iip = cpm_adap->iip;
> + volatile i2c8xx_t *i2c = cpm_adap->i2c;
> + unsigned char brg;
> + bd_t *bd = (bd_t *)__res;
> +
> + DEBUGP(1, "cpm_iic_init() - iip=%p\n", iip);
> +
> + /* Initialize the parameter ram.
> + * We need to make sure many things are initialized to zero,
> + * especially in the case of a microcode patch.
> + */
> + iip->iic_rstate = 0;
> + iip->iic_rdp = 0;
> + iip->iic_rbptr = 0;
> + iip->iic_rbc = 0;
> + iip->iic_rxtmp = 0;
> + iip->iic_tstate = 0;
> + iip->iic_tdp = 0;
> + iip->iic_tbptr = 0;
> + iip->iic_tbc = 0;
> + iip->iic_txtmp = 0;
> +
> + /* Set up the IIC parameters in the parameter ram.
> + */
> + iip->iic_tbase = r_tbase = cpm_adap->dp_addr;
> + iip->iic_rbase = r_rbase = cpm_adap->dp_addr + sizeof(cbd_t) * 2;
> +
> + iip->iic_tfcr = SMC_EB;
> + iip->iic_rfcr = SMC_EB;
> +
> + /* Set maximum receive size.
> + */
> + iip->iic_mrblr = CPM_MAX_READ;
> +
> + /* Initialize Tx/Rx parameters.
> + */
> + if (cpm_adap->reloc == 0) {
> + volatile cpm8xx_t *cp = cpm_adap->cp;
> +
> + cp->cp_cpcr =
> + mk_cr_cmd(CPM_CR_CH_I2C, CPM_CR_INIT_TRX) | CPM_CR_FLG;
> + while (cp->cp_cpcr & CPM_CR_F
[PATCH] 8xx: add cpm_get_cpmp()
On Sat, Aug 06, 2005 at 10:40:37PM -0400, Dan Malek wrote: > > On Aug 6, 2005, at 7:27 PM, Marcelo Tosatti wrote: > > >It already is exported, declared as > > > >commproc.h:extern cpm8xx_t*cpmp; /* Pointer to > >comm processor */ > > > > > >and many drivers use the pointer directly. > > We shouldn't be doing this. All drivers should ioremap() any > peripheral spaces they use and not make any assumptions > someone else has done that already. We've been making > such changes in the 82xx/83xx/85xx CPM2 drivers. If it > isn't convenient to find the #defines for the ioremap(), we > should change that. When I originally wrote all of this > code, it was long ago when we didn't have some of the > abstractions and it seemed any shortcuts for performance > were desired :-) OK makes sense (yep it was even discussed already). Aris, sounds like you should proceed with cpm_get_cpmp() and change all other drivers using it also. > > > >arch/ppc/8260_io/ drivers also use the same convention. > > If there are any drivers in here, they either aren't used or > on their way out. The only things that should remain are > common support functions. OK!
[PATCH] 8xx: add cpm_get_cpmp()
On Sun, Aug 07, 2005 at 12:44:32PM -0300, Aristeu Sergio Rozanski Filho wrote: > > It depends how you define the semantics of this function call. > > Can you call it any (and all of the) time you need it, or does it > > actually perform an ioremap() and you only want to call it > > once? > what about don't cache it and call ioremap() from driver? (I guess > ioremap() already check if an area is already mapped, no?) Yep, ioremap() should be doing virtual address caching already, no?
8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
On Wed, Aug 10, 2005 at 09:27:57AM +0200, cajus.hahn at de.abb.com wrote:
>
>
>
>
> Hi all,
>
> I had some problems on my MPC855M based board when I tried to access the
> i2c bus.
> The cause were some disturbances on the i2c bus. If a slave device or
> another master device hold the SDA or SCL line low, the CPM will get into a
> state, where no more transmissions are made. The only way I found, to get
> the CPM back to work, was a complete re-initialisation. -> force_reinit()
> In this case the busy-wait for transmissions with count < 16 will lock the
> complete system (CPU load 99.9%)
> I added the define I2C_BUSY_WAIT to switch between faster access or safer
> system.
> I found out that the i2c-algo-8xx.c has a bug in cpm_iic_read() and
> cpm_iic_write(): the timeout detection will not work in the case of count <
> 16.
> I also added the define I2C_INTERRUPTIBLE_SLEEP: the old driver reported
> IO-error (-EIO) if a timeout occured (which was not working, see above) or
> if a signal was pending. This caused some problems if the process receives
> user-signals. The driver will report IO-error, which is not correct. With
> the busy-wait this effect might not be seen, because there will be no
> process scheduling -> no signals might be send.
> My modified file is appended. The defines for I2C_BUSY_WAIT and
> I2C_INTERRUPTIBLE_SLEEP are active, which let the driver act like the old
> one.
> Maybe this is helpful for others too and some of the modifications find
> it?s way into the official kernel tree.
Cajus,
Can you please prepare a diff with "diff -u" against the old version and your
modified version of the driver? That way it becomes easier for everyone to
stop the changes you have made.
Thanks in advance.
>
> Cajus Hahn
>
> /*
> * i2c-algo-8xx.c i2x driver algorithms for MPC8XX CPM
> * Copyright (c) 1999 Dan Malek (dmalek at jlc.net).
> *
> 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.
>
> This program is distributed in the hope that it will be useful,
> but WITHOUT ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> GNU General Public License for more details.
>
> You should have received a copy of the GNU General Public License
> along with this program; if not, write to the Free Software
> Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> *
> * moved into proper i2c interface; separated out platform specific
> * parts into i2c-rpx.c
> * Brad Parker (brad at heeltoe.com)
> *
> * added define for BUSY_WAIT and INTERRUPTIBLE_SLEEP, added
> I2C_ALGO_8XX_DATE + ..VERSION
> * fixed bug in cpm_iic_read and cpm_iic_write (timeout never detected if
> count < 16)
> * added force_reinit(): in certain cases (disturbances on the I2C bus) a
> timeout will
> * occur. After this a complete re-initialisation will be necessary,
> otherwise all
> * following transmissions will have a timeout.
> * Cajus Hahn, 09.08.2005
> */
>
> // XXX todo
> // timeout sleep?
>
> /* $Id: i2c-algo-8xx.c,v 1.1.1.1 2004/12/10 08:44:35 cajus Exp $ */
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #include
> #include
>
> #include
> #include
>
> #define I2C_ALGO_8XX_DATE "20050809"
> #define I2C_ALGO_8XX_VERSION "2.6.2"
>
> #define CPM_MAX_READ513
> /* #define I2C_CHIP_ERRATA */ /* Try uncomment this if you have an older
> CPU(earlier than rev D4) */
> #define I2C_BUSY_WAIT /* Uncomment this if you want to do a busy wait in
> cpm_iic_read and cpm_iic_write */
> #define I2C_INTERRUPTIBLE_SLEEP /* Uncomment this if you want the waiting
> in cpm_iic_read and
> cpm_iic_write beeing interruptable
> by signals */
>
> static wait_queue_head_t iic_wait;
> static ushort r_tbase, r_rbase;
>
> int cpm_scan = 0;
> int cpm_debug = 0;
>
> static void
> cpm_iic_interrupt(void *dev_id, struct pt_regs *regs)
> {
> volatile i2c8xx_t *i2c = (i2c8xx_t *)dev_id;
>
> if (cpm_debug > 1)
> printk(KERN_DEBUG "cpm_iic_interrupt(dev_id=%p)\n", dev_id);
>
> #ifdef I2C_CHIP_ERRATA
> /* Chip errata, clear enable.
>* This seems to not be needed on rev D4 or newer CPUs.
>* Someone with an older CPU needs to verify this.
>*/
> i2c->i2c_i2mod &= ~1;
> #endif
>
> /* Clear interrupt.
> */
> i2c->i2c_i2cer = 0xff;
>
> /* Get 'me going again.
> */
> #ifdef I2C_INTERRUPTIBLE_SLEEP
> wake_up_interruptible(&iic_wait);
> #else
> wake_up(&iic_wait);
> #endif
> }
>
> static void
> cpm_iic_init(struct i2c_algo_8xx_data *cpm_adap)
> {
> volatile iic_t *iip = cpm_adap->iip;
> volat
[PATCH] identify_ppc_sys_by_name_and_id function implementation final
On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:
> +static int __init find_chip_by_name_and_id(char *name, u32 id)
> +{
> +int ret = -1;
> +unsigned int i = 0;
> +unsigned int j = 0;
> +unsigned int dups = 0;
> +
> +unsigned int matched[count_sys_specs()];
>
> Is is legit in the kernel to use dynamically sized array?
kmalloc() is certainly safer - why not use it?
> +
> +while (strcmp(ppc_sys_specs[i].ppc_sys_name, "")) {
> +if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
> +matched[j++] = i;
> +i++;
> +}
> +if (j != 0) {
> +for (i = 0; i < j; i++) {
> +if ((ppc_sys_specs[matched[i]].mask & id) ==
> +ppc_sys_specs[matched[i]].value) {
> +ret = matched[i];
> +dups++;
> +}
> +}
> +ret = (dups == 1) ? ret : (-1 * dups);
> +}
> +return ret;
> +}
>
> On Aug 10, 2005, at 1:01 PM, Vitaly Bordug wrote:
>
> >Finally correct indentation style.
> >
> >Signed-off-by: Vitaly Bordug
> >> >--
> >Sincerely,
> >Vitaly
> >
> >
> >
> >
>
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] identify_ppc_sys_by_name_and_id function implementation final
On Thu, Aug 11, 2005 at 07:25:20PM +0400, Vitaly Bordug wrote:
> Marcelo Tosatti wrote:
> >On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:
> >
> >>+static int __init find_chip_by_name_and_id(char *name, u32 id)
> >>+{
> >>+int ret = -1;
> >>+unsigned int i = 0;
> >>+unsigned int j = 0;
> >>+unsigned int dups = 0;
> >>+
> >>+unsigned int matched[count_sys_specs()];
> >>
> >>Is is legit in the kernel to use dynamically sized array?
> >
> >
> >kmalloc() is certainly safer - why not use it?
> Practically , version with kmalloc works, but setup_arch and thus this
> function is called before mem_init, so I just wonder if kmalloc can
> handle this case. On the other hand, I don't like to deal with
> alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp
> does) just for the temporary buffer.
>
> But it's the only _right_ way (or I 've missed something) - sure I'll
> follow it.
I dont see any problem with dynamic array usage on the kernel (maybe someone
else has good argumentation against it).
Just that you have a 4kb stack. Does count_sys_specs() have an appropriate
maximum?
[PATCH] PPC: Don't sleep in flush_dcache_icache_page()
Hi Roland,
On Tue, Aug 16, 2005 at 01:56:49PM -0700, Roland Dreier wrote:
> flush_dcache_icache_page() will be called on an instruction page
> fault. We can't sleep in the fault handler, so use kmap_atomic()
> instead of just kmap() for the Book-E case.
>
> Signed-off-by: Roland Dreier
Why do you need to disable interrupts during the kmap_atomic/flush_dcache_icache
operation ?
I fail to see how an interrupt could have any reference to the data
being dealt with here (the user page).
> diff --git a/arch/ppc/mm/init.c b/arch/ppc/mm/init.c
> --- a/arch/ppc/mm/init.c
> +++ b/arch/ppc/mm/init.c
> @@ -560,8 +560,16 @@ void flush_dcache_page(struct page *page
> void flush_dcache_icache_page(struct page *page)
> {
> #ifdef CONFIG_BOOKE
> - __flush_dcache_icache(kmap(page));
> - kunmap(page);
> + unsigned long flags;
> + void *start;
> +
> + local_irq_save(flags);
> +
> + start = kmap_atomic(page, KM_PPC_SYNC_PAGE);
> + __flush_dcache_icache(start);
> + kunmap_atomic(start, KM_PPC_SYNC_PAGE);
> +
> + local_irq_restore(flags);
> #elif CONFIG_8xx
> /* On 8xx there is no need to kmap since highmem is not supported */
> __flush_dcache_icache(page_address(page));
segmentaion fault with array[4096]
Hi! On Thu, Aug 18, 2005 at 11:45:04AM +0200, Studencki Pawel wrote: > hello, > > because I want to do some tests with fusion/RTAI on my mpc852, > I had to downgrade my system to kernel 2.6.10 Downgrade from what? > And I get a strange problem: if I start application with char array size > 4096 (or even smaller 2600) I get "segmentation fault". > > Could someone gives me a hint? Is this kernel configuration problem? > Where can I start looking for a reason? Have you tried to debug the application with gdb to spot more precisely what is it doing that makes it receive a segfault? Most likely its doing an invalid memory access.
segmentaion fault with array[4096]'
On Fri, Aug 19, 2005 at 09:17:07AM +0200, Studencki Pawel wrote:
> hello,
>
> it is very strange, I found that SIGSEGV is generated in function
> do_page_fault() in arch/ppc/mm/fault.c
>
> --
> int do_page_fault(struct pt_regs *regs, unsigned long address,
> unsigned long error_code)
> {
> struct vm_area_struct * vma;
> struct mm_struct *mm = current->mm;
> siginfo_t info;
> int code = SEGV_MAPERR;
> #if defined(CONFIG_4xx) || defined (CONFIG_BOOKE)
> int is_write = error_code & ESR_DST;
> #else
> int is_write = 0;
>
> /*
> * Fortunately the bit assignments in SRR1 for an instruction
> * fault and DSISR for a data fault are mostly the same for the
> * bits we are interested in. But there are some bits which
> * indicate errors in DSISR but can validly be set in SRR1.
> */
> // printk("fault bad_area is_write is NULL %x\n", regs->dsisr);
> if (TRAP(regs) == 0x400)
> error_code &= 0x4820;
> else
> {
> // printk("fault bad_area is_write err = %x %x\n", error_code,
> TRAP(regs));
> is_write = error_code & 0x0200;
> }
> #endif /* CONFIG_4xx || CONFIG_BOOKE */
> ---
>
>
> It is in DSI Exception, so it goes to "else" and sets is_write to value
> error_code & 0x0200, where error_code is DSISR.
> it is better, when is_write != 0, because if it's NULL, a few lines below
> there
> is an "goto" to bad_area:
>
> if (!is_write)
> {
>goto bad_area;
> }
>
>
> and I get exception.
Sometimes is_write is set and sometimes it is not? Can you please be more
precise?
> At exception error_code is 0x4821, but in User Manual MPC866 in chapter
> 6.1.2.3
> in table 6-7, they write that bits 0-14 in DSISR are NULL. I'm confused and
> I don't know how should I interpret this.
You're looking at the wrong table, thats alignment exception. You should look
at data tlb error exception.
> Where does value 0x4821 come
> from??? most of the time it is 0x8200...
It probably comes from
if (TRAP(regs) == 0x400)
error_code &= 0x4820;
No?
I think you're just doing something wrong in your app.
Check what instruction resides where the invalid access is done (in your
application), which vma its trying to access, and you will figure out
what is going on.
[PATCH] cpm_uart: Fix dpram allocation and non-console uarts
Hi,
On Wed, Aug 17, 2005 at 10:42:36PM -0700, Nish Aravamudan wrote:
> On 8/8/05, Kumar Gala wrote:
> > (A believe Marcelo would like to see this in 2.6.13, but I'll let him
> > fight over that ;)
> >
> > * Makes dpram allocations work
> > * Makes non-console UART work on both 8xx and 82xx
> > * Fixed whitespace in files that were touched
> >
> > Signed-off-by: Vitaly Bordug
> > Signed-off-by: Pantelis Antoniou
> > Signed-off-by: Kumar Gala
> >
> > ---
> > commit 1de80554bcae877dce3b6d878053eb092ef65c72
> > tree aba124824607fea1070e86501ddccc9decce362d
> > parent ad8fd554c9d3c14c0a50885e076af2f9ac9b
> > author Kumar K. Gala Mon, 08 Aug 2005
> > 22:35:39 -0500
> > committer Kumar K. Gala Mon, 08 Aug 2005
> > 22:35:39 -0500
>
>
>
> > diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
> > b/drivers/serial/cpm_uart/cpm_uart_core.c
> > --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> > +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
>
>
>
> > @@ -376,9 +396,19 @@ static int cpm_uart_startup(struct uart_
> > pinfo->sccp->scc_sccm |= UART_SCCM_RX;
> > }
> >
> > + if (!(pinfo->flags & FLAG_CONSOLE))
> > + cpm_line_cr_cmd(line,CPM_CR_INIT_TRX);
> > return 0;
> > }
> >
> > +inline void cpm_uart_wait_until_send(struct uart_cpm_port *pinfo)
> > +{
> > + unsigned long target_jiffies = jiffies + pinfo->wait_closing;
> > +
> > + while (!time_after(jiffies, target_jiffies))
> > + schedule();
> > +}
>
> Not sure about that call here. Does the state need to be set so that
> you won't be run again immediately? In any case, I think direct
> schedule() callers are discouraged? Do you want to call a yield() or
> schedule_timeout({0,1}) instead maybe?
Yep, schedule_timeout(pinfo->wait_closing) looks much better.
> > /*
> > * Shutdown the uart
> > */
> > @@ -394,6 +424,12 @@ static void cpm_uart_shutdown(struct uar
> >
> > /* If the port is not the console, disable Rx and Tx. */
> > if (!(pinfo->flags & FLAG_CONSOLE)) {
> > + /* Wait for all the BDs marked sent */
> > + while(!cpm_uart_tx_empty(port))
> > + schedule_timeout(2);
>
>
>
> I think you are using 2 jiffies to guarantee that at least one jiffy
> elapses, which is fine. But, if you do not set the state beforehand,
> schedule_timeout() returns immediately, so you have a busy-wait here.
Right, what about the following untested patch.
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -403,10 +403,9 @@ static int cpm_uart_startup(struct uart_
inline void cpm_uart_wait_until_send(struct uart_cpm_port *pinfo)
{
- unsigned long target_jiffies = jiffies + pinfo->wait_closing;
-
- while (!time_after(jiffies, target_jiffies))
- schedule();
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(pinfo->wait_closing);
+ set_current_state(TASK_RUNNING);
}
/*
@@ -425,9 +424,13 @@ static void cpm_uart_shutdown(struct uar
/* If the port is not the console, disable Rx and Tx. */
if (!(pinfo->flags & FLAG_CONSOLE)) {
/* Wait for all the BDs marked sent */
- while(!cpm_uart_tx_empty(port))
+ while(!cpm_uart_tx_empty(port)) {
+ set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(2);
- if(pinfo->wait_closing)
+ }
+ set_current_state(TASK_RUNNING);
+
+ if (pinfo->wait_closing)
cpm_uart_wait_until_send(pinfo);
/* Stop uarts */
[PATCH] ppc32: 8xx pq platform system descriptions
On Fri, Aug 19, 2005 at 11:01:49PM +0400, Vitaly Bordug wrote: > Added ppc_sys device and system definitions for PowerQUICC I devices. > > Signed-off-by: Vitaly Bordug > -- > Sincerely, > Vitaly Vitaly, Kumar, Have a few questions: - Do you have any plans on actually using device model information by drivers (as was done in the mpc8xxx/gianfar) on m8xx? Its not very clear to me what are the the practical advantages of that? - I don't know whether its possible to retrieve 8xx CPUID information (if there is any). Can't find anything in the manual.
Enabling 8xx debug mode
Hi Dan, I know now that the BDI automatically enables debug mode by asserting the DSCK signal (available through the JTAG port). Is there any way to enable debugging mode purely via software? 44.3.1.2 Entering Debug Mode By appropriately programming the development port during reset, debug mode can be entered immediately out of reset, thus allowing the user to debug a ROM-less system. If DSCK is asserted throughout SRESET assertion and then past SRESET negation, the processor takes a breakpoint exception and goes directly to debug mode instead of fetching the reset vector. To avoid entering debug mode after reset, DSCK must be negated no later than seven clock cycles after SRESET negates, allowing the processor to jump to the reset vector and begin normal execution. If debug mode is entered immediately after reset, as shown in Figure 44-7, ICR[DPI] is set. The user can enable events that can initiate debug mode and determine which events require regular interrupt handling.
Enabling 8xx debug mode
On Tue, Aug 23, 2005 at 12:58:21AM -0400, Dan Malek wrote: > > On Aug 22, 2005, at 10:20 PM, Marcelo Tosatti wrote: > > >I know now that the BDI automatically enables debug mode by asserting > >the DSCK signal (available through the JTAG port). Is there any way > >to enable debugging mode purely via software? > > I'm not sure I really understand the question, but I'll give some > answers anyway :-) The 8xx has the development/debug support, > which is a bunch of registers that allow setting instruction/data > breakpoints and so on. These are accessible from software, along > with other standard PowerPC debug (like single step). > > The DSCK is a BDM/JTAG clock signal, and along with the other > signals allow the clocking of instructions and data through the BDM > pins. One of the things you can do is strobe in instructions that will > set these same breakpoint or other debug registers as are accessible > from software running on the part. > > So, if you have software running on the processor, you can do the > same things. Obviously, if you are stuck someplace you need to > get the attention of the processor. You can do this with some interrupt > like kgdb does, then use the debug interface to help. > > Does this make sense? Yep.. my misunderstanding was the debug mode can only be turned ON by asserting the DSCK signal during SRESET as the manual says. That's fine. I'm trying to use the debugging registers - seem to work (the example is a data breakpoint). Just need a real interrupt handler, the current one breaks at trap but since the console is not yet initialized I et no output (that sucks). It panic()'s, as expected. Index: arch/ppc/boot/simple/head.S === RCS file: /mnt/test1/tslinux_mv21/linux-2.6/arch/ppc/boot/simple/head.S,v retrieving revision 1.3 diff -u -r1.3 head.S --- arch/ppc/boot/simple/head.S 16 Mar 2005 22:04:09 - 1.3 +++ arch/ppc/boot/simple/head.S 23 Aug 2005 01:41:07 - @@ -130,7 +130,18 @@ * processor correctly. Don't do this if you want to debug * using a BDM device. */ +#define CONFIG_8xx_DEBUG +#ifdef CONFIG_8xx_DEBUG + /* bit 2: Checkstop enable +* bit 3: Machine check interrupt enable +* bits [28,30]: load/store, instruction and external breakpoint resp. +* bit 31: Development port nonmaskable request enable +*/ + li r4,0x000F + lis r4,0x3000 +#else li r4,0/* Zero DER to prevent FRZ */ +#endif mtspr SPRN_DER,r4 #endif Index: arch/ppc/kernel/head_8xx.S === RCS file: /mnt/test1/tslinux_mv21/linux-2.6/arch/ppc/kernel/head_8xx.S,v retrieving revision 1.4 diff -u -r1.4 head_8xx.S --- arch/ppc/kernel/head_8xx.S 16 Mar 2005 22:04:09 - 1.4 +++ arch/ppc/kernel/head_8xx.S 23 Aug 2005 03:05:35 - @@ -554,7 +554,17 @@ * support of breakpoints and such. Someday I will get around to * using them. */ - EXCEPTION(0x1c00, Trap_1c, UnknownException, EXC_XFER_EE) +. = 0x1c00 +DataBreakpoint: + + EXCEPTION_PROLOG + mfspr r4,DAR + stw r4,_DAR(r11) + mfspr r5,DSISR + stw r5,_DSISR(r11) + trap + +/* EXCEPTION(0x1c00, Trap_1c, UnknownException, EXC_XFER_EE) */ EXCEPTION(0x1d00, Trap_1d, UnknownException, EXC_XFER_EE) EXCEPTION(0x1e00, Trap_1e, UnknownException, EXC_XFER_EE) EXCEPTION(0x1f00, Trap_1f, UnknownException, EXC_XFER_EE) Index: arch/ppc/kernel/misc.S === RCS file: /mnt/test1/tslinux_mv21/linux-2.6/arch/ppc/kernel/misc.S,v retrieving revision 1.4 diff -u -r1.4 misc.S --- arch/ppc/kernel/misc.S 21 Jun 2005 16:43:24 - 1.4 +++ arch/ppc/kernel/misc.S 22 Aug 2005 23:23:06 - @@ -1276,6 +1276,31 @@ addir1,r1,16 blr +#define LCTRL1 156 +#define LCTRL2 157 +#define CMPE 152 +#define CMPF 153 + +/* initrd_watchpoint(unsigned long start, unsigned long end) */ +_GLOBAL(initrd_watchpoint) + stw r5, 4(r0) + + mtspr CMPE, r3 + mtspr CMPF, r4 + + li r5, 0x + lis r5, 0xD4F0 + + mtspr LCTRL1, r5 + + li r5, 0x0002 + lis r5, 0x8A00 + + mtspr LCTRL2, r5 + + lwz r5, 4(r0) + blr + /* * This routine is just here to keep GCC happy - sigh... */ Index: arch/ppc/syslib/m8xx_setup.c === RCS file: /mnt/test1/tslinux_mv21/linux-2.6/arch/ppc/syslib/m8xx_setup.c,v retrieving revision 1.12 diff -u -r1.12 m8xx_setup.c --- arch/ppc/syslib/m8xx_setup.c30 Jun 2005 23:02:49 - 1.12 +++ arch/ppc/syslib/m8xx_setup.c23 Aug 2005 03:08:27 - @@ -70,6
[PATCH] ppc32 8xx: fix m8xx_ide_init() #ifdef
Be more precise on deciding whether to call m8xx_ide_init() at m8xx_setup.c:platform_init(). Compilation fails if CONFIG_BLK_DEV_IDE is defined but CONFIG_BLK_DEV_MPC8xx_IDE isnt. Please apply. Signed-off-by: Marcelo Tosatti diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c --- a/arch/ppc/syslib/m8xx_setup.c +++ b/arch/ppc/syslib/m8xx_setup.c @@ -423,7 +423,7 @@ platform_init(unsigned long r3, unsigned ppc_md.find_end_of_memory = m8xx_find_end_of_memory; ppc_md.setup_io_mappings= m8xx_map_io; -#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE) +#if defined(CONFIG_BLK_DEV_MPC8xx_IDE) m8xx_ide_init(); #endif }
