* Re: Calculating virtual address from physical address
From: Eugene Surovegin @ 2006-05-10 16:43 UTC (permalink / raw)
To: dhlii; +Cc: Chris Dumoulin, linuxppc-embedded
In-Reply-To: <4461C8BE.4050504@dlasys.net>
On Wed, May 10, 2006 at 07:04:30AM -0400, David H. Lynch Jr. wrote:
[skip]
> Unless I am completely mistaken, machine checks are not cause by
> softwded are or programming errors, they are cause by hardware problems,
You can trivially trigger MachineChecks without any hardware problems
- just map some non-existent physical address and try to access it.
--
Eugene
^ permalink raw reply
* Re: Viable PPC platform?
From: Eugene Surovegin @ 2006-05-10 16:48 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded, gd.smth
In-Reply-To: <20060510121141.0a866b8f.ajz@cambridgebroadband.com>
On Wed, May 10, 2006 at 12:11:41PM +0100, Alex Zeffertt wrote:
> On Tue, 9 May 2006 10:15:20 -0700
> Eugene Surovegin <ebs@ebshome.net> wrote:
>
> > On Tue, May 09, 2006 at 05:41:01PM +0100, Alex Zeffertt wrote:
> > > On Tue, 09 May 2006 10:38:19 -0400
> > > geneSmith <gd.smth@gmail.com> wrote:
> > >
> > > > I have a ppc405gpr system with 64M ram and 4Meg flash in a
> > > > AM29LV320. Is this a viable platform for linux? Can a filesystem
> > > > (JFFS2?) be put this flash type?
> > > >
> > >
> > > I would create an initrd and put every file that doesn't need
> > > to be changed persistently into it instead of JFFS2.
> >
> > After many years of doing embedded Linux stuff I still don't
> > understand why people are so fond of initrd.
> >
> > For temporary stuff - tempfs is much better and flexible. For r/o
> > stuff - just make separate MTD partition (cramfs, squashfs) and
> > mount it directly as root. Both options will waste significantly
> > less memory.
> >
>
> Okay, let me qualify my answer. It depends on whether you need to
> make persistent changes to the filesystem in flash. If so, and given
> that your flash is only 4MB, I would recommend moving files to
> somewhere else, e.g. an initrd, because if when a JFFS2 FS is
> approaching full, you often find that writes to flash hang
> while JFFS2 searches for blocks to use as a scratchpad. This has been
> my experience anyway.
>
> If you don't need to make persistent changes to files, then I'm sure
> cramfs in flash as a rootfs would work well, with a tmpfs partition
> mounted on /tmp and /var.
You missed my point. initrd should be stored somewhere - in the same
flash . In this case there is no reason to actually use initrd instead
of just direct mount from flash.
--
Eugene
^ permalink raw reply
* Re: IMAP_ADDR on PPC 8xx
From: Walter L. Wimer III @ 2006-05-10 16:49 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1147274635.23931.17.camel@excalibur.timesys.com>
On Wed, 2006-05-10 at 11:23 -0400, Walter L. Wimer III wrote:
> Based on your comments and Wolfgang's comments, I conclude that:
>
> 1. The U-Boots on my MPC885ADS and MPC8272ADS boards are
> unequivocally broken and should be replaced with ones from the
> official U-Boot source repositories that use IMMR values
> matching the Linux kernel source.
FYI, here's a table from the "MPC885ADS PowerQUICC(tm) Application
Development System User's Guide", available on Freescale's website.
This table seems to confirm how they've configured their U-Boot -- the
IMMR is set to 0x02200000...
This may be fine for non-Linux purposes, but it looks like we need to
spread some gospel to Freescale regarding the correct IMMR address for
U-Boot / Linux....
(Or they need to convince folks on this list why their way is
right.... :-)
(In any case I'm convinced. I'm switching over to the community U-Boot
that uses 0xFF000000.)
FYI-ly,
Walt
Freescale Semiconductor, Inc.
Table 3-2. Memory Map in MP885ADS
Port
ADDESS RANGE Memory Type Size
------------------------ ----------------------------- ----
00000000 - 007FFFFF (8M) SDRAM -- CS4 32
02000000 - 020FFFFF (1M) Communication ports -- CS5
02000000 - 020000FF ATM25
02000100 - 020001FF ATM155
02000200 - 020002FF T1/E1 framer
02000300 - 020003FF BCSR5, control register
02000400 - 020004FF Reserved
02100000 - 02107FFF (32K) BCSR[0-4] (1) -- CS1 32 (2)
02100000 - 02107FE3 BCSR0
02100004 - 02107FE7 BCSR1
02100008 - 02107FEB BCSR2
0210000C - 02107FEF BCSR3
02100010 - 02107FF3 BCSR4
02108000 - 021FFFFF Empty space
02200000 - 02203FFF MPC885 internal MAP (3) 32
02204000 - 0221FFFF Empty space
02220000 - 02227FFF Security engine (SEC) 64
02228000 - 027FFFFF Empty space
02800000 - 029FFFFF (2M) 32
02A00000 - 02BFFFFF (2M) Flash SIMM -- CS0
02C00000 - 02FFFFFF (4M)
03000000 - FFFFFFFF Empty space
-----------------------------------------------------------------
(1) The device appears repeatedly in multiples of its size.
That is, BCSR0 appears at memory locations 2100000, 2100020,
2100040..., while BCSR1 appears at 2100004, 2100024,
2100044, and so on.
(2) Only the upper 16 bits (D0\u2013D15) are used.
(3) Refer to the MPC885 PowerQUICC Family Reference Manual for
a complete description of the MPC885 internal memory map.
^ permalink raw reply
* Re: Alubook 5,8: No sound with 2.6.17-rc3-g5528e568-dirty
From: Wolfgang Pfeiffer @ 2006-05-10 17:24 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:
> > 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
> 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 ...
Best 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: IMAP_ADDR on PPC 8xx
From: Dan Malek @ 2006-05-10 17:45 UTC (permalink / raw)
To: Walter L. Wimer III; +Cc: linuxppc-embedded
In-Reply-To: <1147279763.23931.32.camel@excalibur.timesys.com>
On May 10, 2006, at 12:49 PM, Walter L. Wimer III wrote:
> FYI, here's a table from the "MPC885ADS PowerQUICC(tm) Application
> Development System User's Guide", available on Freescale's website.
> This table seems to confirm how they've configured their U-Boot -- the
> IMMR is set to 0x02200000...
Freescale never ported U-Boot to the MPC855ADS platform, and
I don't believe it came with any software at all. This IMMR value was
chosen to be backward compatible with some old software tools to
get a compact address space without the need of using the MMU,
long before we had Linux running on the platform.
> This may be fine for non-Linux purposes, but it looks like we need to
> spread some gospel to Freescale regarding the correct IMMR address for
> U-Boot / Linux....
I think you better be pointing fingers at the clueless person that
provided the software you have, as it didn't come from Freescale nor
any of the public U-Boot sources.
Thanks.
-- Dan
^ permalink raw reply
* Need help debugging
From: Steve Iribarne (GMail) @ 2006-05-10 18:04 UTC (permalink / raw)
To: linuxppc-embedded
ok, so I've got my BDI2000 working and talking to my 8260.
I read as much info as I could find on this but I still think I'm
missing something.
I have a uBoot image and I wait for the system to download my kernel.=20
Not through the BDI, I just let the uBoot boot image do it the normal
way. I start it by telling the BDI to "go".
Then what I want to do is connect to my linux kernel after the kernel
is up and running so I do:
(gdb) target remote bdi:2001
Remote debugging using bdi:2001
0xc000c9cc in ??()
(gdb)
Then I add my symbol table.
(gdb) add-symbol-file vmlinux 0xc0000000
at that point I get a reset.
I turn off the software watchdog in the BDI config file. Is there
something I am missing?
Thanks in advance.
-stv
^ permalink raw reply
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: Steven Rostedt @ 2006-05-10 18:04 UTC (permalink / raw)
To: Richard Henderson
Cc: linux-arch, linuxppc-dev, Paul Mackerras, linux-kernel, t
In-Reply-To: <20060510154702.GA28938@twiddle.net>
On Wed, 10 May 2006, Richard Henderson wrote:
> On Wed, May 10, 2006 at 02:03:59PM +1000, Paul Mackerras wrote:
> > With this patch, 64-bit powerpc uses __thread for per-cpu variables.
>
> 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);
> }
>
> Across the schedule, we may have changed cpus, making the cached
> address invalid.
>
If you mean use(foo) is the same as per_cpu(foo), I can't see the compile
optimizing this:
+#define per_cpu(var, cpu) \
+ (*(__typeof__(&per_cpu__##var))({ \
+ void *__ptr; \
+ asm("addi %0,%1,per_cpu__"#var"@tprel" \
+ : "=b" (__ptr) \
+ : "b" (paca[(cpu)].thread_ptr)); \
+ __ptr; \
+ }))
Anyway, per_cpu variables are usually used with preemption turned off and
no need to schedule.
-- Steve
^ permalink raw reply
* Help: Linux porting to custom target hw
From: Jayanta Das @ 2006-05-10 18:01 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]
Hello:
Can someone point me in the right direction for some good documentation
on 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
minted and later on the RAMDISK.
Appreciate the help.
Regards.
[-- Attachment #2: Type: text/html, Size: 2863 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: David S. Miller @ 2006-05-10 19:40 UTC (permalink / raw)
To: rth; +Cc: linux-arch, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20060510154702.GA28938@twiddle.net>
From: Richard Henderson <rth@twiddle.net>
Date: Wed, 10 May 2006 08:47:13 -0700
> 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.
#define preempt_disable() \
do { \
inc_preempt_count(); \
barrier(); \
} while (0)
...
#define preempt_enable() \
do { \
preempt_enable_no_resched(); \
barrier(); \
preempt_check_resched(); \
} while (0)
The scheduler itself need to take care to not cause the situation
you mention either.
Therefore this is an issue we had already, not some new thing
introduced by using __thread for per-cpu variables.
^ permalink raw reply
* Re: IMAP_ADDR on PPC 8xx
From: John Rigby @ 2006-05-10 19:58 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <6CE25E1C-0F7A-4644-926E-746C17A7A851@embeddedalley.com>
Thanks Dan for the extra info.
Just to let everyone know even though this turned out to not
be our problem we here at Freescale are looking at how we
can make sure this does not happen in the future. We want
any uboot shipped with future Freescale boards to have the
correct behavior. We also understand the board documentation
needs to be changed to mention the appropriate value for IMMR
for linux.
John
jrigby@freescale.com
On 5/10/06, Dan Malek <dan@embeddedalley.com> wrote:
>
> On May 10, 2006, at 12:49 PM, Walter L. Wimer III wrote:
>
> > FYI, here's a table from the "MPC885ADS PowerQUICC(tm) Application
> > Development System User's Guide", available on Freescale's website.
> > This table seems to confirm how they've configured their U-Boot -- the
> > IMMR is set to 0x02200000...
>
> Freescale never ported U-Boot to the MPC855ADS platform, and
> I don't believe it came with any software at all. This IMMR value was
> chosen to be backward compatible with some old software tools to
> get a compact address space without the need of using the MMU,
> long before we had Linux running on the platform.
>
> > This may be fine for non-Linux purposes, but it looks like we need to
> > spread some gospel to Freescale regarding the correct IMMR address for
> > U-Boot / Linux....
>
> I think you better be pointing fingers at the clueless person that
> provided the software you have, as it didn't come from Freescale nor
> any of the public U-Boot sources.
>
> Thanks.
>
> -- Dan
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: IMAP_ADDR on PPC 8xx
From: Walter L. Wimer III @ 2006-05-10 20:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <6CE25E1C-0F7A-4644-926E-746C17A7A851@embeddedalley.com>
On Wed, 2006-05-10 at 13:45 -0400, Dan Malek wrote:
> > This may be fine for non-Linux purposes, but it looks like we need
> > to spread some gospel to Freescale regarding the correct IMMR
> > address for U-Boot / Linux....
>
> I think you better be pointing fingers at the clueless person that
> provided the software you have, as it didn't come from Freescale nor
> any of the public U-Boot sources.
My sincerest apologies to Freescale. Upon further research, it appears
that it was another TimeSys engineer (who has since moved on to another
job) who built and installed U-Boot on our MPC885ADS board. Strangely,
it appears that he started with the community U-Boot 1.1.3 and then
added a patch to change the IMMR value (plus a few other things). I'm
not sure why. He's a very bright guy, so I'm very puzzled....
Anyway, mystery solved.
Again, my sincerest apologies to Freescale.
I built the community U-Boot 1.1.4 and flashed it onto our board. Linux
2.6.16.11 now boots much farther than before (I'm now getting printk()
output). The kernel is hitting a new problem now, but I suspect it may
be related to the TLB code that Marcello has discussed recently. I'm
going to go look at that patch next. :-)
> Thanks.
>
> -- Dan
Thanks again to everyone!!!
Walt Wimer
TimeSys Corporation
^ permalink raw reply
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: Paul Mackerras @ 2006-05-10 21:05 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-arch, linuxppc-dev, linux-kernel, rth
In-Reply-To: <20060510.124003.04457042.davem@davemloft.net>
David S. Miller writes:
> From: Richard Henderson <rth@twiddle.net>
> Date: Wed, 10 May 2006 08:47:13 -0700
>
> > 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.
Paul.
^ permalink raw reply
* Re: Alubook 5,8: No sound with 2.6.17-rc3-g5528e568-dirty
From: Christoph Cebulla @ 2006-05-10 20:54 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev list, Johannes Berg
In-Reply-To: <20060510172443.GF3878@localhost>
Hi,
> > Did it ever work?
Kind of... with a patch[1] originally by Ben Collins and adapted by
Gaudenz Steinlin it at least lets you play your favorite music. The
kernel I use is a 2.6.17-rc3-git5.
> 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
This patch applied cleanly on every kernel I tried since 2.6.15...
> 5.8 is, IINM, the last PPC 15" Powerbook that Apple made
>
> > Also, try snd-aoa.
Best regards,
Christoph
[1] http://lists.debian.org/debian-powerpc/2006/03/msg00226.html
^ permalink raw reply
* 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
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