* Re: Alubook 5,8: No sound with 2.6.17-rc3-g5528e568-dirty
From: Wolfgang Pfeiffer @ 2006-05-10 21:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <2829.131.234.104.112.1147277053.squirrel@secure.sipsolutions.net>
On Wed, May 10, 2006 at 06:04:13PM +0200, Johannes Berg wrote:
> Also, try snd-aoa.
Impossible here, it does not compile here. Neither with gcc 4.0 or 4.1
I took your instructions from
http://lists.debian.org/debian-powerpc/2006/03/msg00470.html
And if I understand them correctly it's not necessary to descend to
some directory level of the kernel source for my current kernel. I
slightly modified your instructions (being addicted to git, Sorry
about that ... :) .. :
Something like:
mkdir snd-aoa
cd snd-aoa/
git clone http://johannes.sipsolutions.net/snd-aoa.git/
cd snd-aoa/
make
The above did not work: compile problems:
-----------------
include/sound/pcm.h:742: error: dereferencing pointer to incomplete type
include/sound/pcm.h: In function 'snd_pcm_capture_empty':
include/sound/pcm.h:755: error: dereferencing pointer to incomplete type
include/sound/pcm.h: In function 'snd_pcm_trigger_done':
include/sound/pcm.h:762: error: dereferencing pointer to incomplete type
include/sound/pcm.h: At top level:
include/sound/pcm.h:844: error: syntax error before 'u_int32_t'
include/sound/pcm.h:844: warning: function declaration isn't a prototype
include/sound/pcm.h:846: error: syntax error before 'u_int64_t'
include/sound/pcm.h:846: warning: function declaration isn't a prototype
include/sound/pcm.h:901: error: syntax error before 'snd_pcm_format_size'
include/sound/pcm.h:901: error: syntax error before 'size_t'
include/sound/pcm.h:901: warning: type defaults to 'int' in declaration of 'snd_pcm_format_size'
include/sound/pcm.h:901: warning: function declaration isn't a prototype
include/sound/pcm.h:901: warning: data definition has no type or storage class
include/sound/pcm.h: In function 'snd_pcm_set_runtime_buffer':
include/sound/pcm.h:936: error: dereferencing pointer to incomplete type
include/sound/pcm.h:938: error: dereferencing pointer to incomplete type
include/sound/pcm.h:939: error: dereferencing pointer to incomplete type
include/sound/pcm.h:939: error: dereferencing pointer to incomplete type
include/sound/pcm.h:940: error: dereferencing pointer to incomplete type
include/sound/pcm.h:940: error: dereferencing pointer to incomplete type
include/sound/pcm.h:941: error: dereferencing pointer to incomplete type
include/sound/pcm.h:941: error: dereferencing pointer to incomplete type
include/sound/pcm.h:943: error: dereferencing pointer to incomplete type
include/sound/pcm.h:944: error: dereferencing pointer to incomplete type
include/sound/pcm.h:945: error: dereferencing pointer to incomplete type
include/sound/pcm.h:946: error: dereferencing pointer to incomplete type
include/sound/pcm.h: At top level:
include/sound/pcm.h:966: error: syntax error before 'size_t'
include/sound/pcm.h:966: warning: function declaration isn't a prototype
include/sound/pcm.h:969: error: syntax error before 'size_t'
include/sound/pcm.h:969: warning: function declaration isn't a prototype
include/sound/pcm.h:970: error: syntax error before 'size_t'
include/sound/pcm.h:970: warning: function declaration isn't a prototype
include/sound/pcm.h: In function 'snd_pcm_mmap_data_open':
include/sound/pcm.h:981: error: dereferencing pointer to incomplete type
include/sound/pcm.h:982: error: dereferencing pointer to incomplete type
include/sound/pcm.h: In function 'snd_pcm_mmap_data_close':
include/sound/pcm.h:987: error: dereferencing pointer to incomplete type
include/sound/pcm.h:988: error: dereferencing pointer to incomplete type
include/sound/pcm.h: At top level:
include/sound/pcm.h:1000: error: syntax error before 'size_t'
include/sound/pcm.h:1001: warning: function declaration isn't a prototype
include/sound/pcm.h: In function 'snd_pcm_limit_isa_dma_size':
include/sound/pcm.h:1002: error: 'max' undeclared (first use in this function)
include/sound/pcm.h:1002: error: 'dma' undeclared (first use in this function)
In file included from /home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/aoa.h:21,
from /home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.c:14:
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/../soundbus/soundbus.h: At top level:
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/../soundbus/soundbus.h:37: error: syntax error before 'u64'
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/../soundbus/soundbus.h:37: warning: no semicolon at end of struct or union
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/../soundbus/soundbus.h:40: error: syntax error before 'transfer_in'
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/../soundbus/soundbus.h:44: error: syntax error before '}' token
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/../soundbus/soundbus.h:142: error: field 'ofdev' has incomplete type
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/../soundbus/soundbus.h:169: error: syntax error before 'u32'
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/../soundbus/soundbus.h:169: warning: no semicolon at end of struct or union
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/../soundbus/soundbus.h:193: error: field 'driver' has incomplete type
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.c: In function 'attach_codec_to_fabric':
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.c:33: error: 'ENOENT' undeclared (first use in this function)
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.c: In function 'aoa_fabric_register':
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.c:85: error: 'EALREADY' undeclared (first use in this function)
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.c:89: error: 'EEXIST' undeclared (first use in this function)
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.c:91: error: 'EINVAL' undeclared (first use in this function)
make[3]: *** [/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.o] Error 1
make[2]: *** [/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa] Error 2
make[1]: *** [_module_/home/shorty/kernel-factory/git/snd-aoa/snd-aoa] Error 2
make[1]: Leaving directory `/home/shorty/kernel-factory/git/linux-2.6'
make: *** [modules] Error 2
----------------
FYI:
------------------------
$ gcc --version
gcc (GCC) 4.0.4 20060422 (prerelease) (Debian 4.0.3-2)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-------------------------------------------
Same being true for this:
$ pwd
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa
$ make clean
$ MAKEFLAGS="CC=gcc-4.1" make
The end from the latter command:
--------------
include/sound/pcm.h:669: error: 'struct snd_pcm_runtime' has no member named 'status'
include/sound/pcm.h:669: error: 'struct snd_pcm_runtime' has no member named 'control'
include/sound/pcm.h:671: error: 'struct snd_pcm_runtime' has no member named 'boundary'
include/sound/pcm.h: In function 'snd_pcm_playback_ready':
include/sound/pcm.h:695: error: 'struct snd_pcm_substream' has no member named 'runtime'
include/sound/pcm.h:696: error: 'struct snd_pcm_runtime' has no member named 'control'
include/sound/pcm.h: In function 'snd_pcm_capture_ready':
include/sound/pcm.h:709: error: 'struct snd_pcm_substream' has no member named 'runtime'
include/sound/pcm.h:710: error: 'struct snd_pcm_runtime' has no member named 'control'
include/sound/pcm.h: In function 'snd_pcm_playback_data':
include/sound/pcm.h:724: error: 'struct snd_pcm_substream' has no member named 'runtime'
include/sound/pcm.h:726: error: 'struct snd_pcm_runtime' has no member named 'stop_threshold'
include/sound/pcm.h:726: error: 'struct snd_pcm_runtime' has no member named 'boundary'
include/sound/pcm.h: In function 'snd_pcm_playback_empty':
include/sound/pcm.h:741: error: 'struct snd_pcm_substream' has no member named 'runtime'
include/sound/pcm.h: In function 'snd_pcm_capture_empty':
include/sound/pcm.h:755: error: 'struct snd_pcm_substream' has no member named 'runtime'
include/sound/pcm.h: In function 'snd_pcm_trigger_done':
include/sound/pcm.h:762: error: 'struct snd_pcm_substream' has no member named 'runtime'
include/sound/pcm.h: At top level:
include/sound/pcm.h:844: error: expected declaration specifiers or '...' before 'u_int32_t'
include/sound/pcm.h:846: error: expected declaration specifiers or '...' before 'u_int64_t'
include/sound/pcm.h:901: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'snd_pcm_format_size'
include/sound/pcm.h: In function 'snd_pcm_set_runtime_buffer':
include/sound/pcm.h:936: error: 'struct snd_pcm_substream' has no member named 'runtime'
include/sound/pcm.h:938: error: 'struct snd_pcm_runtime' has no member named 'dma_buffer_p'
include/sound/pcm.h:939: error: 'struct snd_pcm_runtime' has no member named 'dma_area'
include/sound/pcm.h:940: error: 'struct snd_pcm_runtime' has no member named 'dma_addr'
include/sound/pcm.h:940: error: 'struct snd_dma_buffer' has no member named 'addr'
include/sound/pcm.h:941: error: 'struct snd_pcm_runtime' has no member named 'dma_bytes'
include/sound/pcm.h:941: error: 'struct snd_dma_buffer' has no member named 'bytes'
include/sound/pcm.h:943: error: 'struct snd_pcm_runtime' has no member named 'dma_buffer_p'
include/sound/pcm.h:944: error: 'struct snd_pcm_runtime' has no member named 'dma_area'
include/sound/pcm.h:945: error: 'struct snd_pcm_runtime' has no member named 'dma_addr'
include/sound/pcm.h:946: error: 'struct snd_pcm_runtime' has no member named 'dma_bytes'
include/sound/pcm.h: At top level:
include/sound/pcm.h:966: error: expected declaration specifiers or '...' before 'size_t'
include/sound/pcm.h:966: error: expected declaration specifiers or '...' before 'size_t'
include/sound/pcm.h:969: error: expected declaration specifiers or '...' before 'size_t'
include/sound/pcm.h:969: error: expected declaration specifiers or '...' before 'size_t'
include/sound/pcm.h:970: error: expected declaration specifiers or '...' before 'size_t'
include/sound/pcm.h: In function 'snd_pcm_mmap_data_open':
include/sound/pcm.h:981: error: 'struct vm_area_struct' has no member named 'vm_private_data'
include/sound/pcm.h:982: error: 'struct snd_pcm_substream' has no member named 'runtime'
include/sound/pcm.h: In function 'snd_pcm_mmap_data_close':
include/sound/pcm.h:987: error: 'struct vm_area_struct' has no member named 'vm_private_data'
include/sound/pcm.h:988: error: 'struct snd_pcm_substream' has no member named 'runtime'
include/sound/pcm.h: At top level:
include/sound/pcm.h:1000: error: expected declaration specifiers or '...' before 'size_t'
include/sound/pcm.h: In function 'snd_pcm_limit_isa_dma_size':
include/sound/pcm.h:1002: error: 'max' undeclared (first use in this function)
In file included from /home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/aoa.h:21,
from /home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.c:14:
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/../soundbus/soundbus.h: At top level:
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/../soundbus/soundbus.h:37: error: expected specifier-qualifier-list before 'u64'
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/../soundbus/soundbus.h:142: error: field 'ofdev' has incomplete type
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/../soundbus/soundbus.h:169: error: expected specifier-qualifier-list before 'u32'
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/../soundbus/soundbus.h:193: error: field 'driver' has incomplete type
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.c: In function 'attach_codec_to_fabric':
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.c:33: error: 'ENOENT' undeclared (first use in this function)
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.c: In function 'aoa_fabric_register':
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.c:85: error: 'EALREADY' undeclared (first use in this function)
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.c:89: error: 'EEXIST' undeclared (first use in this function)
/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.c:91: error: 'EINVAL' undeclared (first use in this function)
make[3]: *** [/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa/snd-aoa-core.o] Error 1
make[2]: *** [/home/shorty/kernel-factory/git/snd-aoa/snd-aoa/aoa] Error 2
make[1]: *** [_module_/home/shorty/kernel-factory/git/snd-aoa/snd-aoa] Error 2
make[1]: Leaving directory `/home/shorty/kernel-factory/git/linux-2.6'
make: *** [modules] Error 2
-------------
I should compile with gcc 4.1, IINM:
$ cat /proc/version
Linux version 2.6.17-rc3-g5528e568-dirty (root@debby1-6) (gcc version
4.1.1 20060428 (prerelease) (Debian 4.1.0-2)) #1 Sun May 7 23:51:15
CEST 2006
Does it help?
Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: David S. Miller @ 2006-05-10 22:25 UTC (permalink / raw)
To: paulus; +Cc: linux-arch, linuxppc-dev, linux-kernel, rth
In-Reply-To: <17506.21908.857189.645889@cargo.ozlabs.ibm.com>
From: Paul Mackerras <paulus@samba.org>
Date: Thu, 11 May 2006 07:05:24 +1000
> No, Richard has a point, it's not the value that is the concern, it's
> the address, which gcc could assume is still valid after a barrier.
> Drat.
Oh right, and that's currently part of why we obfuscate the
address computation with the RELOC_HIDE() buisness.
Once we expose what's really going on with something like
__thread, gcc can now be "smart" about it.
^ permalink raw reply
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: Paul Mackerras @ 2006-05-10 23:05 UTC (permalink / raw)
To: Richard Henderson; +Cc: linux-arch, linuxppc-dev, linux-kernel, t
In-Reply-To: <20060510154702.GA28938@twiddle.net>
Richard Henderson writes:
> How do you plan to address the compiler optimizing
>
> __thread int foo;
> {
> use(foo);
> schedule();
> use(foo);
> }
>
> into
>
> {
> int *tmp = &foo; // tls arithmetic here
> use(*tmp);
> schedule();
> use(*tmp);
> }
Hmmm... Would it be sufficient to use a RELOC_HIDE in __get_cpu_var,
like this?
#define __get_cpu_var(x) (*(RELOC_HIDE(&per_cpu__##x, 0)))
Paul.
^ permalink raw reply
* Re: Alubook 5,8: No sound with 2.6.17-rc3-g5528e568-dirty
From: Wolfgang Pfeiffer @ 2006-05-10 23:08 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <20060510213028.GG3878@localhost>
On Wed, May 10, 2006 at 11:30:28PM +0200, Wolfgang Pfeiffer wrote:
> On Wed, May 10, 2006 at 06:04:13PM +0200, Johannes Berg wrote:
>
> > Also, try snd-aoa.
>
> Impossible here, it does not compile here. Neither with gcc 4.0 or 4.1
>
Not being sure tho' whether the fact my source dir for the running
kernel is cleaned up, IINM, (like "fakeroot make-kpkg clean") is the
culprit for the failed compile ... I'll have a look into that at
next daylight ... :)
Until then
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: Segher Boessenkool @ 2006-05-10 23:17 UTC (permalink / raw)
To: Paul Mackerras
Cc: linux-arch, linuxppc-dev, rth, David S. Miller, linux-kernel
In-Reply-To: <17506.21908.857189.645889@cargo.ozlabs.ibm.com>
>>> How do you plan to address the compiler optimizing
>> ...
>>> Across the schedule, we may have changed cpus, making the cached
>>> address invalid.
>>
>> Per-cpu variables need to be accessed only with preemption
>> disabled. And the preemption enable/disable operations
>> provide a compiler memory barrier.
>
> No, Richard has a point, it's not the value that is the concern, it's
> the address, which gcc could assume is still valid after a barrier.
> Drat.
Would an asm clobber of GPR13 in the schedule routines (or a wrapper
for them, or whatever) work?
Segher
^ permalink raw reply
* [RFC-PATCH] Prevent tasks from sleeping in die()
From: David Wilder @ 2006-05-11 0:19 UTC (permalink / raw)
To: linuxppc-dev
I am seeing an issue in die() when voluntary preemption is enabled.
die()
->>show_regs()->>show_instructions()->>__get_user_nocheck()->>might_sleep()
If multiple CPUs call die() and one should sleep other CPUs may block on
the die_lock held by the sleeping CPU. This problem is seen when a
soft-reset is issued as all CPUs call die() at roughly the same time.
Is this the correct way to fix this problem?
Signed-of-by: <wilder@us.ibm.com>
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 064a525..dc45bcd 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -101,6 +101,15 @@ int die(const char *str, struct pt_regs
if (debugger(regs))
return 1;
+ /* If voluntary preemption is on we can sleep
+ * in show_regs(). This is bad as we hold the
+ * die_lock. Ether the task is exiting or the system
+ * is crashing so there is no need to restore the
+ * NEED_RESCHED flag.
+ */
+ clear_need_resched();
+
+
console_verbose();
spin_lock_irq(&die_lock);
bust_spinlocks(1);
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
^ permalink raw reply related
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: Paul Mackerras @ 2006-05-10 23:44 UTC (permalink / raw)
To: Richard Henderson, t, linux-kernel, linux-arch, linuxppc-dev,
amodra
In-Reply-To: <17506.29128.591758.502430@cargo.ozlabs.ibm.com>
I wrote:
> Hmmm... Would it be sufficient to use a RELOC_HIDE in __get_cpu_var,
> like this?
>
> #define __get_cpu_var(x) (*(RELOC_HIDE(&per_cpu__##x, 0)))
But that won't work because the compiler can still cache &per_cpu__x.
I guess I have to do this:
#define __get_cpu_var(var, cpu) \
(*(__typeof__(&per_cpu__##var))({ \
void *__ptr; \
asm("addi %0,13,per_cpu__"#var"@tprel" \
: "=r" (__ptr)); \
__ptr; \
}))
That means we lose the possible optimization of combining the addi
into a following load or store. Bah. However, I guess it's still
better than what we do at the moment.
Paul.
^ permalink raw reply
* Re: [RFC-PATCH] Prevent tasks from sleeping in die()
From: Paul Mackerras @ 2006-05-10 23:45 UTC (permalink / raw)
To: David Wilder; +Cc: linuxppc-dev
In-Reply-To: <44628316.80600@us.ibm.com>
David Wilder writes:
> I am seeing an issue in die() when voluntary preemption is enabled.
> die()
> ->>show_regs()->>show_instructions()->>__get_user_nocheck()->>might_sleep()
Are you using Linus' current git tree? It has a patch that fixes this
problem by making __get_user_nocheck do the might_sleep only if the
address you give it is a user address.
Paul.
^ permalink raw reply
* Re: Alubook 5,8: No sound with 2.6.17-rc3-g5528e568-dirty
From: Benjamin Herrenschmidt @ 2006-05-10 23:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <2829.131.234.104.112.1147277053.squirrel@secure.sipsolutions.net>
On Wed, 2006-05-10 at 18:04 +0200, Johannes Berg wrote:
> > As to the reason why I came here:
> > As I can't be sure whether the issue announced in the subject line is
> > really a kernel issue
>
> Did it ever work? I don't quite know what machine a 5,8 is since I have a
> 5,6 only. Also, try snd-aoa.
Same as mine, it works fine with snd-aoa
Ben.
^ permalink raw reply
* Re: Alubook 5,8: No sound with 2.6.17-rc3-g5528e568-dirty
From: Benjamin Herrenschmidt @ 2006-05-10 23:48 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev list, Johannes Berg
In-Reply-To: <20060510172443.GF3878@localhost>
On Wed, 2006-05-10 at 19:24 +0200, Wolfgang Pfeiffer wrote:
> On Wed, May 10, 2006 at 06:04:13PM +0200, Johannes Berg wrote:
> > > As to the reason why I came here:
> > > As I can't be sure whether the issue announced in the subject line is
> > > really a kernel issue
> >
> > Did it ever work?
>
> Not with Debian, but with this Ubuntu live CD I have sound:
> Ubuntu 6.06 "Dapper Drake" Beta 2 powerpc (20060427)
>
> The kernel on their CD is a 2.6.15-21-powerpc
Dapper kernel has the hack to consider it as a toonie. No volume control
nor anything.
> > I don't quite know what machine a 5,8 is since I have a
> > 5,6 only.
>
>
> 5.8 is, IINM, the last PPC 15" Powerbook that Apple made
>
> > Also, try snd-aoa.
>
> With the git kernel mentioned in my previous mail there's no snd-aoa
> available, IINM. I'll try figure out how to get the source and compile
> another kernel with this driver ...
It's not merged upstream yet.
Ben.
^ permalink raw reply
* Re: Alubook 5,8: No sound with 2.6.17-rc3-g5528e568-dirty
From: Benjamin Herrenschmidt @ 2006-05-10 23:49 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev list, Johannes Berg
In-Reply-To: <20060510230811.GH3878@localhost>
On Thu, 2006-05-11 at 01:08 +0200, Wolfgang Pfeiffer wrote:
> On Wed, May 10, 2006 at 11:30:28PM +0200, Wolfgang Pfeiffer wrote:
> > On Wed, May 10, 2006 at 06:04:13PM +0200, Johannes Berg wrote:
> >
> > > Also, try snd-aoa.
> >
> > Impossible here, it does not compile here. Neither with gcc 4.0 or 4.1
> >
>
> Not being sure tho' whether the fact my source dir for the running
> kernel is cleaned up, IINM, (like "fakeroot make-kpkg clean") is the
> culprit for the failed compile ... I'll have a look into that at
> next daylight ... :)
You can't build modules with "cleaned" kernel headers.
Ben.
^ permalink raw reply
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: David S. Miller @ 2006-05-11 0:11 UTC (permalink / raw)
To: paulus; +Cc: linux-arch, linux-kernel, linuxppc-dev, amodra, rth, t
In-Reply-To: <17506.31456.68099.57515@cargo.ozlabs.ibm.com>
From: Paul Mackerras <paulus@samba.org>
Date: Thu, 11 May 2006 09:44:32 +1000
> That means we lose the possible optimization of combining the addi
> into a following load or store. Bah. However, I guess it's still
> better than what we do at the moment.
If you have to hide the operation so deeply like this, maybe you can
do something similar to sparc64, by explicitly doing the per-cpu fixed
register and offsets, and still get the single instruction relocs that
powerpc can do for up to 64K by doing something like:
&per_cpu_blah - &per_cpu_base
to calculate the offset.
^ permalink raw reply
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: Richard Henderson @ 2006-05-11 0:22 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linux-arch, linuxppc-dev, Paul Mackerras, David S. Miller,
linux-kernel
In-Reply-To: <49BB818F-DF88-43A3-8B6A-7F9F5C7A2C3C@kernel.crashing.org>
On Thu, May 11, 2006 at 01:17:50AM +0200, Segher Boessenkool wrote:
> Would an asm clobber of GPR13 in the schedule routines (or a wrapper
> for them, or whatever) work?
No. The address is cse'd symbolically long before the r13
reference is exposed.
r~
^ permalink raw reply
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: Alan Modra @ 2006-05-11 1:04 UTC (permalink / raw)
To: Paul Mackerras
Cc: linux-arch, linuxppc-dev, rth, David S. Miller, linux-kernel
In-Reply-To: <17506.21908.857189.645889@cargo.ozlabs.ibm.com>
On Thu, May 11, 2006 at 07:05:24AM +1000, Paul Mackerras wrote:
> No, Richard has a point, it's not the value that is the concern, it's
> the address, which gcc could assume is still valid after a barrier.
> Drat.
That may never happen, at least with a compiler that knows how to
optimise away the addi. You're using -mtls-size=16 so all your accesses
should look like
lwz rn,per_cpu_var@tprel(13)
gcc shouldn't think there is any reason to cache the address.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: Paul Mackerras @ 2006-05-11 1:21 UTC (permalink / raw)
To: Alan Modra; +Cc: linux-arch, linuxppc-dev, rth, David S. Miller, linux-kernel
In-Reply-To: <20060511010438.GE24458@bubble.grove.modra.org>
Alan Modra writes:
> gcc shouldn't think there is any reason to cache the address.
Can I rely on that being true in the future?
Paul.
^ permalink raw reply
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: Alan Modra @ 2006-05-11 2:01 UTC (permalink / raw)
To: Paul Mackerras
Cc: linux-arch, linuxppc-dev, rth, David S. Miller, linux-kernel
In-Reply-To: <17506.37259.755099.974824@cargo.ozlabs.ibm.com>
On Thu, May 11, 2006 at 11:21:15AM +1000, Paul Mackerras wrote:
> Alan Modra writes:
>
> > gcc shouldn't think there is any reason to cache the address.
>
> Can I rely on that being true in the future?
It isn't true in the *present*, except with a compiler on my home
machine. :-)
__thread int i1;
void
f3 (void)
{
int x = i1;
__asm__ __volatile__ ("#dragons be here. %0" : "+r" (x));
i1 = x;
}
current mainline with -O2 -S -mtls-size=16
f3:
addi 9,2,i1@tprel
lwz 0,0(9)
#APP
#dragons be here. 0
#NO_APP
stw 0,0(9)
blr
Same thing with my modified compiler.
f3:
lwz 0,i1@tprel(2)
#APP
#dragons be here. 0
#NO_APP
stw 0,i1@tprel(2)
blr
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply
* mpc8270 : i2c support
From: Heiko Schocher @ 2006-05-11 5:12 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
on Thu May 4 06:11:17 2006 i wrote:
> Hmmm.... I think there are differences in the memory map between
> MPC826x and MPC827x ... can you try following Hack in
> include/asm-ppc/cpm_8260.h?
>
> -#define PROFF_I2C ((16 * 1024) - 64)
> +#define PROFF_I2C ((8 * 1024) - 64)
>
> [If it solves the problem, we must do this on a better way ;-)]
I don t know, if this was necessary to solve the problem, but i think
the follwing patch is useful, but I have no Hardware to try it out.
Any comments?
Best regards
Heiko
diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
index 6197986..738259c 100644
--- a/include/asm-ppc/cpm2.h
+++ b/include/asm-ppc/cpm2.h
@@ -181,7 +181,11 @@ #define PROFF_IDMA4_BASE ((uint)0x8afe)
*/
#define PROFF_SMC1 (0)
#define PROFF_SMC2 (64)
+#if defined(CONFIG_8272) || defined(CONFIG_MPC8555)
+#define PROFF_I2C ((8 * 1024) - 64)
+#else
#define PROFF_I2C ((16 * 1024) - 64)
+#endif
/* Define enough so I can at least use the serial port as a UART.
*/
^ permalink raw reply related
* Re: Alubook 5,8: No sound with 2.6.17-rc3-g5528e568-dirty
From: Johannes Berg @ 2006-05-11 11:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1147304824.32448.82.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 633 bytes --]
On Thu, 2006-05-11 at 09:47 +1000, Benjamin Herrenschmidt wrote:
> Same as mine, it works fine with snd-aoa
I should build a database with a machine string -> user* mapping... This
means that even my brother has this one and it works great with snd-aoa
as far as I know :)
Though, since the alsa userspace libs absolutely *SUCK* no program I
know of can properly represent the mixer controls except maybe amixer...
I'd hate to work around this in the kernel, but the alsa libs are such
complex beasts that I have a feeling they won't be fixed.
Anyone up to inventing a new mixer API that uses sysfs? ;)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: Alubook 5,8: No sound with 2.6.17-rc3-g5528e568-dirty
From: Benjamin Herrenschmidt @ 2006-05-11 12:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1147348702.9630.7.camel@johannes>
On Thu, 2006-05-11 at 13:58 +0200, Johannes Berg wrote:
> On Thu, 2006-05-11 at 09:47 +1000, Benjamin Herrenschmidt wrote:
>
> > Same as mine, it works fine with snd-aoa
>
> I should build a database with a machine string -> user* mapping... This
> means that even my brother has this one and it works great with snd-aoa
> as far as I know :)
>
> Though, since the alsa userspace libs absolutely *SUCK* no program I
> know of can properly represent the mixer controls except maybe amixer...
> I'd hate to work around this in the kernel, but the alsa libs are such
> complex beasts that I have a feeling they won't be fixed.
kmix looks approx. ok
> Anyone up to inventing a new mixer API that uses sysfs? ;)
>
> johannes
^ permalink raw reply
* Help: Linux porting to custom target hw
From: Thiago Galesi @ 2006-05-11 12:02 UTC (permalink / raw)
To: Jayanta Das; +Cc: linuxppc-embedded
In-Reply-To: <8584FDC94AFF7640B17B8A89B23B19B331C626@sbsserver.AlphionCorp.local>
Ok
What is the specific problem you are having?? Based on what you said
all went well, didn't it?
Basically, I think the main thing you have to configure there is flash
location (in the kernel), to be able to use it via MTD.
Booting from NFS or Flash is pretty much effortless, configurable via cmdli=
ne.
Be more specific, so we can help you more...
Thiago
On 5/10/06, Jayanta Das <JDas@alphion.com> wrote:
>
>
> Hello:
>
> Can someone point me in the right direction for some good documentation o=
n
> the above topic. Following is what I so far have done and what I need to =
do.
>
> 1. Set up host environment based on Fedora Core 4
> 2. Downloaded 'ppc4xx' tool chain, ELDK and kernel
> 3. Built U-Boot and uImage
> 4. Flashed U-Boot on the 2nd flash on the Ocotea board (AMCC440GX PowerPC=
)
> 5. Changed the environment variable for NFS mounted root fs and other MAC
> and IP addresses as needed
> 6. TFTP uImage at 400000
> 7. bootm and kernel boots all right with root fs mounted on the host
>
> I am expecting my hardware based on 440GX end of the month. I told the HW
> engineer to follow the peripheral i/f as much possible close to the ref.
> design. We are putting 32MB of Flash and 256MB of RAM.
>
> I need some guidance so that I can port U-Boot and the kernel (minimal
> changes) so that I can bring up the board initially with root fs NFS mint=
ed
> and later on the RAMDISK.
>
> Appreciate the help.
>
> Regards.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* RE: Help Needed: input overrun(s)
From: s.maiti @ 2006-05-11 12:56 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0189DD9F@ismail.innsys.innovsys.com>
[-- Attachment #1: Type: text/plain, Size: 2550 bytes --]
Thanks very much for your reply. It's seems you have already developed the
MCC driver. Are you using channels 32 to 96? Have you made any changes in
the dp ram allocation for uart or ethernet driver?
Please help me...
Thanks and regards,
Souvik Maiti
Tata Consultancy Services Limited
Mailto: s.maiti@tcs.com
Website: http://www.tcs.com
"Rune Torgersen" <runet@innovsys.com>
05/10/2006 08:45 PM
To
"Stevan Ignjatovic" <stevan@iritel.com>, <s.maiti@tcs.com>
cc
<linuxppc-embedded@ozlabs.org>
Subject
RE: Help Needed: input overrun(s)
> -----Original Message-----
> From: Stevan Ignjatovic
> Hello,
>
> > console we are receiving a print "ttyS: 1 input overrun(s)"
> along with
> > other prints of the driver and resulting in scrambled output.
> > Can anyone suggest why this is happening? Is the driver
> affecting the uart
> > driver?
>
> As far as UART driver is concerned, it could be affected if
> you did not
> carefully allocate some resources. Are you using MCC1 or MCC2? Channel
> specific parameters of MCC1 (channels 0-127) are at the
> beginning of the
> DPRAM (channel CH_NUM at address 64*CH_NUM). UART driver (as well as
> ethernet driver) allocates its buffer descriptors with
> m8260_cpm_dpalloc. I think that allocating with this function
> starts at
> the beginning of the DPRAM, so you might have overwritten
> UART's buffer
> descriptors. So, use MCC2 if you can. If you use some BRGs in your MCC
> driver you should check that as well.
We have a MCC driver that we see the same happening on. It only occurs
under heavy load (top sows us usig 20-40 % cpu in interrupt).
I am pretty confident that we are not overwriting uart DPRAM. (MCC1 only
uses the middle 64 channels, skipping over the first 32 where the
conflict witht he UARTS are)
I have not seen it corrupt anything, so we have more or less ignored it.
Our theory is that it happens when the CPM gets overloaded.
It would be nice to actually fix it though....
ForwardSourceID:NT00006D1A
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
[-- Attachment #2: Type: text/html, Size: 3722 bytes --]
^ permalink raw reply
* MPC8641(D) software status
From: Sam Song @ 2006-05-11 13:53 UTC (permalink / raw)
To: linuxppc-embedded
Dear all,
Could anyone kindly disclose any info on
its boot code and kernel support?
Mass production is under way if I am not
wrong but less info on software. Just out of
interest to know that... Maybe I could have
the luck to touch it.
Thanks in advance,
Sam
___________________________________________________________
雅虎免费邮箱-3.5G容量，20M附件
http://cn.mail.yahoo.com/
^ permalink raw reply
* Re: MPC8641(D) software status
From: Xianghua Xiao @ 2006-05-11 14:08 UTC (permalink / raw)
To: Sam Song; +Cc: linuxppc-embedded
In-Reply-To: <20060511135328.25523.qmail@web15706.mail.cnb.yahoo.com>
Sam,
We have patches for 8641D against 2.6.15/2.6.16 and it works well in lab
in the last three months along with u-boot code. I think a patch against
2.6.17 or later will be released in the future. However if you need the
2.6.15/2.6.16 patch now, you can contact Freescale directly. In fact,
for all 8641D boards we will ship, we will include the kernel/u-boot
source code on the SATA hard drive directly as well, or you can also
download them from freescale's website.
Hope this helps,
Xianghua
Sam Song wrote:
>Dear all,
>
>Could anyone kindly disclose any info on
>its boot code and kernel support?
>
>Mass production is under way if I am not
>wrong but less info on software. Just out of
>interest to know that... Maybe I could have
>the luck to touch it.
>
>Thanks in advance,
>
>Sam
>
>
>
>
>
>
>___________________________________________________________
>雅虎免费邮箱-3.5G容量，20M附件
>http://cn.mail.yahoo.com/
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* RE: Help Needed: input overrun(s)
From: Rune Torgersen @ 2006-05-11 14:14 UTC (permalink / raw)
To: s.maiti; +Cc: linuxppc-embedded
> From: s.maiti@tcs.com [mailto:s.maiti@tcs.com]=20
> Thanks very much for your reply. It's seems you have already=20
> developed the MCC driver. Are you using channels 32 to 96?=20
> Have you made any changes in the dp ram allocation for uart=20
> or ethernet driver?=20
> Please help me...=20
We are using every other channel from 32 to 96 on both MCC's as SS7
receivers.
We did not have to do any relocations for UART or ethernet.=20
Ethernet uses upper DPRAM (above 0x8000) and uarts use the first 128
bytes.
We statically allocate DPRAM with cpm_alloc_fixed. MCC1 use 0x0800 to
0x17ff
MCC2 use 0x2800 to 0x37ff. Extra param RAM is allocated with cpm_alloc
and is allocated as 256*8 bytes, and shared between MCC1 and 2.
All BD and interrupt tables are in main memory.
^ permalink raw reply
* Tests to enable Dcache on MPC8270ZUQLDA PPC board restart the system
From: Om Vadlapatla @ 2006-05-11 16:32 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org, U-Boot-Users@lists.sourceforge.net
[-- Attachment #1: Type: text/plain, Size: 6402 bytes --]
Hello,
Processor: MPC8270
Debugger: Abatron BDI 2000
Board & processor Initialization by: Uboot 1.1.2
Aim:
I try to enable d-cache at the Register level with out
having any exceptions. I want to write my own code to
compile into the kernel that is no longer supported by
Montavista (3.0).
Proceedure:
~in window 1 (DIP window) I reset the processor then
the flash mem loads the U-boot version 1.1.2. I do not
load the OS so the system is running at the U-boot
prompt.
=>
~In window 2 (BDI debugger window) I use the Abarton
BDI to force the PPC to enter debug mode by issuing -
"halt" instruction.
MPC8270>halt
Target CPU : MPC8280/MGT5200 (Zeppo)
Target state : debug mode
Debug entry cause : COP halt
Current PC : 0x0ffe935c
Current CR : 0x44004044
Current MSR : 0x0000b002
Current LR : 0x0ffe13a8
~now by issueing commands from the BDI I try to set
the BATs and the MMU as follows:
I tried two BAT schemes on the abatron that are
attached in BAT register setting table.do &
8280_InitMMU.cmm :
Test 1:-
For seting DBAT regs by BDI commands ccording to
(BAT_register_setting_table.doc):
// initialize bats
MPC8270>rm dbat0u 0xffe0003f
MPC8270>rm dbat0l 0xffe00022
MPC8270>rm dbat1u 0x00001fff
MPC8270>rm dbat1l 0x00000002
MPC8270>rm dbat2u 0x300007ff
MPC8270>rm dbat2l 0x30000002
MPC8270>rm dbat3u 0x400003FF
MPC8270>rm dbat3l 0x40000022
MPC8270>rm dbat4u 0xFB0001FF
MPC8270>rm dbat4l 0xFB000022
MPC8270>rm dbat5u 0xFE400003
MPC8270>rm dbat5l 0xFE400022
MPC8270>rm dbat6u 0xF0000003
MPC8270>rm dbat6l 0xF0000022
MPC8270>rm dbat7u 0xFF000003
MPC8270>rm dbat7l 0xFF000022
MPC8270>rm hid0 0x8000c088 // set HID0 to enable
// I & D Cache
MPC8270>go // to let the processor run
I check the PC and it is at 0x200 the Machine check
exception.
Test 2:-
commands I issued throught Abatron BDI window:
// initialization of BATs reffre to (8280_InitMMU.cmm)
// please keep in mind that even though these BAT
// initialization are for a Stand alone systems I only
// plan to test if I am able to initialize the data
// cache without the 0x200 (Machine check exception)
// exception.
MPC8270>rm ibat0u 0x000003fe
MPC8270>rm ibat0l 0x00000002
MPC8270>rm ibat1u 0x04700002
MPC8270>rm ibat1l 0x04700022
MPC8270>rm ibat3u 0xff0000fe
MPC8270>rm ibat3l 0xff000001
MPC8270>rm dbat0u 0x000007fe
MPC8270>rm dbat0l 0x00000002
MPC8270>rm dbat1u 0x0400007e
MPC8270>rm dbat1l 0x0400002a
MPC8270>rm dbat2u 0x0450007e
MPC8270>rm dbat2l 0x0450002a
MPC8270>rm dbat3u 0xff0000fe
MPC8270>rm dbat3l 0xff000022
// the Bats initialize fine no problem till here
MPC8270>rm msr 0x9030 // enable MMU (EE + ME + DR +
IR)
// I feel I may be messing it up here (can some one
// correct me?)
MPC8270>go // this is to let the processor run
// however ends up restarting the system
// I dont issue the foll command coz of reset
MPC8270>rm hid0 0x8000c088 // this is to set and
// enable the I & D Caches
This is how the DIP window where the boot prompt is
looks after this test 2:-
-------------------------------------------------------
U-Boot 1.1.2 (Jan 27 2006 - 14:27:57) ### Release
1.1.5 ###
MPC8260 Reset Status: Bus Monitor, External Soft,
External Hard
MPC8260 Clock Configuration
- Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75
, Core Freq 100-300
- dfbrg 1, corecnf 0x1a, busdf 5, cpmdf 1, plldf 0,
pllmf 5
- vco_out 400000002, scc_clk 100000000, brg_clk
25000000
- cpu_clk 266666668, cpm_clk 200000001, bus_clk
66666667
CPU: MPC8260 (HiP7 Rev 14, Mask 1.0 1K49M) at
266.666 MHz
Board: Fujitsu FW4060
I2C: ready
DRAM: 256 MB
FLASH: 2 MB
In: serial
Out: serial
Err: serial
Net: FCC2 ETHERNET
IDE: Bus 0: OK
Device 0: Model: Hitachi XXM2.3.0 Firm: Rev 3.00
Ser#: X0405 20050304185152
Type: Removable Hard Disk
Capacity: 61.1 MB = 0.0 GB (125184 x 512)
Hit any key to stop autoboot: 0
=>Bad trap at PC: fffffffc, SR: 1000, vector=800
NIP: FFFFFFFC XER: 20000000 LR: 00001088 REGS:
0ffa7dc0 TRAP: 0800 DAR: 0FFE55FC
MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 0000A000 0FFA7EB0 00000004 00000000 0FFF0E80
0000000A FFFFFFFD FFFFFFFF
GPR08: 0FFA7C18 F0000080 00008000 F0000090 00000000
0403FF80 0FFF6000 101C8000
GPR16: 00000000 00000000 00000000 0100FFE0 00000000
00000001 00000000 00000000
GPR24: 00000000 FFFFFFFF 00000001 00000003 0FFFEFC8
0FFA7F64 0FFF74AC 0FFF0E80
Call backtrace:
Exception in kernel pc fffffffc signal 0
U-Boÿ
U-Boot 1.1.2 (Jan 27 2006 - 14:27:57) ### Release
1.1.5 ###
MPC8260 Reset Status: External Soft, External Hard
MPC8260 Clock Configuration
- Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75
, Core Freq 100-300
- dfbrg 1, corecnf 0x1a, busdf 5, cpmdf 1, plldf 0,
pllmf 5
- vco_out 400000002, scc_clk 100000000, brg_clk
25000000
- cpu_clk 266666668, cpm_clk 200000001, bus_clk
66666667
CPU: MPC8260 (HiP7 Rev 14, Mask 1.0 1K49M) at
266.666 MHz
Board: Fujitsu FW4060
I2C: ready
DRAM: 256 MB
FLASH: 2 MB
In: serial
Out: serial
Err: serial
Net: FCC2 ETHERNET
IDE: Bus 0: OK
Device 0: Model: Hitachi XXM2.3.0 Firm: Rev 3.00
Ser#: X0405 20050304185152
Type: Removable Hard Disk
Capacity: 61.1 MB = 0.0 GB (125184 x 512)
Hit any key to stop autoboot: 0
=> Bad trap at PC: fffffffc, SR: 1000, vector=800
NIP: FFFFFFFC XER: 00000000 LR: 00001088 REGS:
0ffa7dc0 TRAP: 0800 DAR: 0FFE55FC
MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 0000A000 0FFA7EB0 00000004 00000000 0FFF0E80
0000000A FFFFFFFD 00000000
GPR08: 00000002 F0000080 00008000 F0000090 00000000
0403FF80 0FFF6000 101C8000
GPR16: 00000000 00000000 00000000 0100FFE0 00003002
00000001 00000000 0FFCB098
GPR24: 0FFCE410 00000001 00000001 00000003 0FFFEFC8
0FFA7F64 0FFF74AC 0FFF0E80
Call backtrace:
Exception in kernel pc fffffffc signal 0
-------------------------------------------------------
Have I wrongly inilialized the MSR?
Please post comments and suggestions of how I can
initialized MMU for d-cache performance. I am very new
to this.
Thanky you,
Best regards,
Om Vadlapatla
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[-- Attachment #2: 790078158-8280_InitMMU.cmm --]
[-- Type: application/octet-stream, Size: 1775 bytes --]
; ********************************
; Initialize BATs
; ********************************
INIT_MMU:
; *** Invalidate TLBs
d.a 0x10000 addi r2,0,32
d.a 0x10004 mtctr r2 ; Load CTR with 32.
d.a 0x10008 addi r3,0,0 ; Use r3 as the tlb index
d.a 0x1000C tlbie r3 ; invalidate the tlb entry
d.a 0x10010 sync
d.a 0x10014 addi r3,r3,0x1000 ; increment the index
d.a 0x10018 bdnz 0x1000C
d.a 0x1001C b 0x1001C
r.s IP 0x10000
go
wait 1ms
break
; *** Clear all Upper BATs
d.s SPR:0x218 %l 0 ; DBAT0U
d.s SPR:0x21A %l 0 ; DBAT1U
d.s SPR:0x21C %l 0 ; DBAT2U
d.s SPR:0x21E %l 0 ; DBAT3U
d.s SPR:0x238 %l 0 ; DBAT4U
d.s SPR:0x23A %l 0 ; DBAT5U
d.s SPR:0x23C %l 0 ; DBAT6U
d.s SPR:0x23E %l 0 ; DBAT7U
d.s SPR:0x210 %l 0 ; IBAT0U
d.s SPR:0x212 %l 0 ; IBAT1U
d.s SPR:0x214 %l 0 ; IBAT2U
d.s SPR:0x216 %l 0 ; IBAT3U
d.s SPR:0x230 %l 0 ; IBAT4U
d.s SPR:0x232 %l 0 ; IBAT5U
d.s SPR:0x234 %l 0 ; IBAT6U
d.s SPR:0x236 %l 0 ; IBAT7U
; 60-x SDRAM IBAT
d.s SPR:0x210 %l 0x000003FE ; IBAT0U 32MB
d.s SPR:0x211 %l 0x00000002 ; IBAT0L R/W
; IMMR IBAT
d.s SPR:0x212 %l 0x04700002 ; IBAT1U 128KB
d.s SPR:0x213 %l 0x04700022 ; IBAT0L I R/W
; Flash IBAT
d.s SPR:0x216 %l 0xFF0000FE ; IBAT3U 8MB
d.s SPR:0x217 %l 0xFF000001 ; IBAT3L R/O
; 60-x SDRAM DBAT
d.s SPR:0x218 %l 0x000007FE ; DBAT0U 16MB
d.s SPR:0x219 %l 0x00000002 ; DBAT0L R/W
; Local SDRAM DBAT
d.s SPR:0x21A %l 0x0400007E ; DBAT1U
d.s SPR:0x21B %l 0x0400002A ; DBAT1L I,G R/W
; BCSR DBAT
d.s SPR:0x21C %l 0x0450007E ; DBAT2U BCSR + IMMR space
d.s SPR:0x21D %l 0x0450002A ; DBAT2L I,G R/W
; Flash DBAT
d.s SPR:0x21E %l 0xFF0000FE ; DBAT3U 8MB
d.s SPR:0x21F %l 0xFF000022 ; DBAT3L I R/W
; Enable MMU
;r.s MSR 0x9030 ; EE + ME + DR + IR
[-- Attachment #3: 1927371312-BAT register setting table.doc --]
[-- Type: application/msword, Size: 28672 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox