* 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
* 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: 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
* 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: 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
* 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: 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: 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: 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: Information for setting up SMT related parameters on linux 2.6.16 on POWER5
From: Will Schmidt @ 2006-05-10 16:27 UTC (permalink / raw)
To: Meswani, Mitesh; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <C26C730943E01145B4F89E37FE0A022002BBC74D@itdsrvmail02.utep.edu>
On Tue, 2006-05-09 at 17:17 -0600, Meswani, Mitesh wrote:
> Thanks guys
>
> That answered so many of my questions.
>
> If I were to use these macros from user space, would they remain set
> until next reboot or change ? POWER5 allows priorities 2 through 4 for
> user apps, so considering this, and the fact that the normal prioirity
> is level 4, if a user app resets it to say 2 and then finishes without
> changing it back to 4 , would all the subsequent user apps run at the
> new level 2. I wonder what I am saying even makes sense, because the
> kernel internally throttles the priority for various sections of the
> kernel code and it may even overwrite it.
I dont believe there is any mechanism that ever saves the current
priority between user and kernel, or between threads, etc. So if you
were to set it, it would remain set until the next HMT_ macro was
touched. A brief source search shows that the HMT_ macros are
referenced in idle loops, spin locks, exceptions, and hcalls, so not
likely that it would remain set for long.
>
> On a slightly unrelated note, I appended some boot parameters like
> smt-enabled=on/off to /etc/lilo.conf and unfortunately I am not able
> to see any effect and it boots the same way. I am switching from the
Perhaps bad notation in my first note. "smt-enabled=on" is a default,
and will give you threads. "smt-enabled=off" will cause those threads
to be off by default.
> AIX world so I maybe doing something dumb, please point out if I am !
> This kind of seems to effect the bind processor calls using
> sys_setaffinity when there are 4 logical processors 0-3 on two
> physical processors, bind only allows me to set affinity to either cpu
> 0 or 2, this seems weird to me because my system is booting with two
> logical cpus and then I set online bit to 1 to turn the remaining on,
> thereafter I try binding and havent been very successful.
Dont know about the affinity stuff..
>
>
> Thanks for all your replies.
>
>
>
>
> Mitesh R. Meswani
> Ph.D. Candidate
> Research Associate, PLS2 Group
> Room 106 F, Department of Computer Science
> The University of Texas at El Paso,
> El Paso, Texas 79968
> Tel: 915 747 8012 (O)
> Email: mmeswani@utep.edu
>
>
> ______________________________________________________________________
> From: Segher Boessenkool [mailto:segher@kernel.crashing.org]
> Sent: Mon 5/8/2006 5:04 PM
> To: will_schmidt@vnet.ibm.com
> Cc: Meswani, Mitesh; linuxppc-dev@ozlabs.org; Arnd Bergmann;
> linux-kernel@vger.kernel.org; cbe-oss-dev@ozlabs.org
> Subject: Re: Information for setting up SMT related parameters on
> linux 2.6.16 on POWER5
>
>
> > the HMT_* macros are telling firmware that "this processor thread
> > should
> > run at this priority". Typically used when we're waiting on a
> > spinlock.
> > I.e. When we are waiting on a spinlock, we hit the HMT_low macro to
> > drop
> > our threads priority, allowing the other thread to use those extra
> > cycles finish it's stuff quicker, and maybe even release the lock
> > we're
> > waiting for. HMT_* is all within the kernel though, no
> > exposure
> > to userspace apps.
>
> Actually, those macros translate straight into a single machine insn.
> No firmware is involved. See include/asm-powerpc/processor.h. For
> example:
>
> #define HMT_very_low() asm volatile("or 31,31,31 # very low
> priority")
>
> You can use those same macros from user space, although it is CPU
> implementation dependent which priorities you can actually set (you
> probably can do low and medium priority).
>
>
> Segher
>
>
>
>
^ permalink raw reply
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: Richard Henderson @ 2006-05-10 15:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-arch, linuxppc-dev, linux-kernel
In-Reply-To: <17505.26159.807484.477212@cargo.ozlabs.ibm.com>
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.
r~
^ permalink raw reply
* Re: Alubook 5,8: No sound with 2.6.17-rc3-g5528e568-dirty
From: Johannes Berg @ 2006-05-10 16:04 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev list
In-Reply-To: <20060510154930.GD3878@localhost>
> 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.
johannes
^ permalink raw reply
* Alubook 5,8: No sound with 2.6.17-rc3-g5528e568-dirty
From: Wolfgang Pfeiffer @ 2006-05-10 15:49 UTC (permalink / raw)
To: linuxppc-dev list
Hi All
First a *Thanks* to all those, here or elsewhere, who spend their time
on the development of usable software for PPC Linux: I don't think I
ever would have bought the latest alu Powerbook with the option that
this machine will be an MacOSX-only one ... :)
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 I put some sound relevant config files in a
tarball (~ 12 KB) to my homepage:
wolfgangpfeiffer.com/alsa.configs.tar.gz
In the tarball above you'll find
these local /etc/ dirs with all files below them:
alsa modprobe.d modutils
and these single files, also from /etc/ here:
modules modules.conf pbbuttonsd.conf
The kernel config
http://wolfgangpfeiffer.com/config-2.6.17-rc3-g5528e568-dirty.txt
(Geocities, which my site actually is hosted by, does not allow
uploading the file without the file type suffix, IIRC ...)
The kernel, made with non-edited (except the kernel .config), as I hope,
git sources, and with the 'make-kpkg' Debian package:
$ 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
OS is Debian/unstable.
Machine:
$ cat /proc/cpuinfo
processor : 0
cpu : 7447A, altivec supported
clock : 833.333000MHz
revision : 0.5 (pvr 8003 0105)
bogomips : 16.57
timebase : 8320000
platform : PowerMac
machine : PowerBook5,8
motherboard : PowerBook5,8 MacRISC3 Power Macintosh
detected as : 287 (PowerBook G4 15")
pmac flags : 00000019
L2 cache : 512K unified
pmac-generation : NewWorld
lspci -v:
---------------------
0000:00:0b.0 Host bridge: Apple Computer Inc.: Unknown device 0066
Flags: bus master, 66MHz, medium devsel, latency 16
Capabilities: [80] AGP version 1.0
0000:00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
Flags: bus master, 66MHz, medium devsel, latency 255, IRQ 48
Memory at b8000000 (32-bit, prefetchable) [size=128M]
I/O ports at f0000400 [size=256]
Memory at b0000000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at f1000000 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
0001:10:0b.0 Host bridge: Apple Computer Inc.: Unknown device 0067
Flags: bus master, 66MHz, medium devsel, latency 16
0001:10:11.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
Subsystem: Apple Computer Inc.: Unknown device 4318
Flags: bus master, fast devsel, latency 16, IRQ 52
Memory at a0004000 (32-bit, non-prefetchable) [size=8K]
0001:10:14.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller
Flags: bus master, medium devsel, latency 168, IRQ 53
Memory at a0003000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=10, secondary=11, subordinate=14, sec-latency=176
Memory window 0: 90000000-9ffff000 (prefetchable)
Memory window 1: f3000000-f33ff000
I/O window 0: 00001000-000011ff
I/O window 1: 00001400-000015ff
16-bit legacy interface ports at 0001
0001:10:15.0 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI])
Subsystem: NEC Corporation USB
Flags: bus master, medium devsel, latency 16, IRQ 54
Memory at a0002000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
0001:10:15.1 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI])
Subsystem: NEC Corporation USB
Flags: bus master, medium devsel, latency 16, IRQ 54
Memory at a0001000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
0001:10:15.2 USB Controller: NEC Corporation USB 2.0 (rev 04) (prog-if 20 [EHCI])
Subsystem: NEC Corporation USB 2.0
Flags: bus master, medium devsel, latency 16, IRQ 54
Memory at a0000000 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2
0001:10:17.0 ff00: Apple Computer Inc. KeyLargo/Intrepid Mac I/O
Flags: bus master, medium devsel, latency 16
Memory at 80000000 (32-bit, non-prefetchable) [size=512K]
0002:24:0b.0 Host bridge: Apple Computer Inc.: Unknown device 0068
Flags: bus master, 66MHz, medium devsel, latency 16
0002:24:0d.0 ff00: Apple Computer Inc.: Unknown device 0069
Flags: bus master, medium devsel, latency 32, IRQ 39
Memory at f5004000 (32-bit, non-prefetchable) [size=16K]
0002:24:0e.0 FireWire (IEEE 1394): Apple Computer Inc.: Unknown device 006a (prog-if 10 [OHCI])
Subsystem: Apple Computer Inc.: Unknown device 5811
Flags: bus master, medium devsel, latency 64, IRQ 40
Memory at f5000000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
0002:24:0f.0 Ethernet controller: Apple Computer Inc.: Unknown device 006b
Flags: bus master, 66MHz, slow devsel, latency 16, IRQ 41
Memory at f5200000 (32-bit, non-prefetchable) [size=2M]
Expansion ROM at f5100000 [disabled] [size=1M]
---------------------
So with the settings from the files above I run 'alsaconf', and it
can't find any sound card:
x x
x x
x No supported PnP or PCI card found. x
x x
x Would you like to probe legacy ISA sound cards/chips? x
x x
x x
x <Yes> <No> x
x x
Either answering No or Yes does not help to get sound.
KDE also is complaining. Something like:
---------------------
Sound server informational message:
Error while initializing the sound driver:
device: default can't be opened for playback (No such device)
The sound server will continue, using the null output device.
-----------------------
The alsapackages seem to be the latest ones I can get:
# apt-get install alsa-base alsa-utils alsaplayer-alsa alsaplayer-common alsaplayer-gtk
Reading package lists... Done
Building dependency tree... Done
alsa-base is already the newest version.
alsa-utils is already the newest version.
alsaplayer-alsa is already the newest version.
alsaplayer-common is already the newest version.
alsaplayer-gtk is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 322 not upgraded.
Please let me know in case you need more information ..
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: Walter L. Wimer III @ 2006-05-10 15:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <3A4FA660-AD13-4E2B-846B-B9ACD901444F@embeddedalley.com>
Thanks, Dan! This is exactly the kind of feedback I was seeking.
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.
2. For now, there is no pressing need to fix the existing drivers;
they may continue dereferencing IMAP_ADDR directly as they
currently do.
3. In the future, the drivers will ultimately migrate toward
individually calling ioremap() and maintaining their own private
pointers.
Thanks again,
Walt
On Tue, 2006-05-09 at 17:51 -0400, Dan Malek wrote:
> On May 9, 2006, at 3:52 PM, Walter L. Wimer III wrote:
>
> > Exactly. I think this kind of "automatic adaption" to the particular
> > platform is what should be in the vanilla kernel.
>
> This does not mean you can choose some arbitrary value.
> There is a small range of high memory addresses that will
> work successfully for IMMR. You may not see any problems
> right away, but depending upon drivers selected and the
> software features used, some problems will crop up.
> There are also MMU performance enhancements that may
> be used with certain values, and guaranteed kernel crashes
> at some point in the future when abused.
>
> With Linux, the IMMR should always have a value of
> 0xf0000000 or 0xff000000 for best results.
>
> > This was the second major part of our 2.6.11.7-based patch. It
> > performed a single ioremap(), stored the result in a global
> > pointer, and
> > then used that pointer in all the drivers instead of using IMAP_ADDR
> > directly.
>
> This is not an acceptable practice. We are removing all
> global pointers like this, and any driver that needs access to
> some or all of the IMMR space should be individually mapping
> those regions it needs. Under the covers of ioremap() we are
> performing various alignment and reuse of address spaces
> in order to support things like performance enhancements
> and cache coherent regions.
>
> Thanks.
>
> -- Dan
>
^ permalink raw reply
* Re: Kernel bug reports welcome here?
From: Olof Johansson @ 2006-05-10 15:24 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev
In-Reply-To: <20060510135139.GB3878@localhost>
On Wed, May 10, 2006 at 03:51:39PM +0200, Wolfgang Pfeiffer wrote:
> Hi All
>
> I'm running a git kernel with sources from about last Sunday, on a
> alubook5.8, and I would like to know whether bug reports, if things
> don't work with this kernel (there are a few ... :), will be welcome
> here.
>
> If not: Where's the better place for reports like that: Linux kernel
> mailing list?
They are welcome here, but keep in mind that some of them could be
better suited for LKML. It depends on what the problem is. If it seems
to be machine/PPC-specific, post here. If it's generic kernel (MM, other
things), post on LKML. If unsure, you could also crosspost on both lists,
but try to keep that to a minimum.
There's also the debian-ppc mailing list, for things not directly related
to the kernel but to the rest of the distro you run (some kernel problems
are also discussed there, but I'm not sure if they're interested in
mainline kernel bugs there or not).
-Olof
^ permalink raw reply
* RE: Help Needed: input overrun(s)
From: Rune Torgersen @ 2006-05-10 15:15 UTC (permalink / raw)
To: Stevan Ignjatovic, s.maiti; +Cc: linuxppc-embedded
> -----Original Message-----
> From: Stevan Ignjatovic
> Hello,
>=20
> > console we are receiving a print "ttyS: 1 input overrun(s)"=20
> along with=20
> > other prints of the driver and resulting in scrambled output.=20
> > Can anyone suggest why this is happening? Is the driver=20
> affecting the uart=20
> > driver?
>=20
> As far as UART driver is concerned, it could be affected if=20
> you did not
> carefully allocate some resources. Are you using MCC1 or MCC2? Channel
> specific parameters of MCC1 (channels 0-127) are at the=20
> 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=20
> starts at
> the beginning of the DPRAM, so you might have overwritten=20
> 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. =20
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....
^ permalink raw reply
* Re: Kernel bug reports welcome here?
From: Hollis Blanchard @ 2006-05-10 13:57 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev
In-Reply-To: <20060510135139.GB3878@localhost>
On Wed, 2006-05-10 at 15:51 +0200, Wolfgang Pfeiffer wrote:
> I'm running a git kernel with sources from about last Sunday, on a
> alubook5.8, and I would like to know whether bug reports, if things
> don't work with this kernel (there are a few ... :), will be welcome
> here.
They are welcome here.
-Hollis
^ permalink raw reply
* Re: Kernel panic - not syncing: No init found.
From: Steve Iribarne (GMail) @ 2006-05-10 13:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <-1484187685935794069@unknownmsgid>
On 5/10/06, hangtoo <hangtoo@163.com> wrote:
>
> I try to make a new uRamdisk for my bubinga board(linux-2.6.14,PPC405EP).
> actully I just copy the most of the files in the board,and compiled busyb=
ox with ppc tools.
> but when I use the new uRamdisk for a try,it just showed up this errors(a=
s follow),then reboot,back and forth...
> **************************************************
> RAMDISK: incomplete write (-28 !=3D 32768) 4194304
>
I'm pretty sure this tells me that your ramdisk is not big enough.
Take a look at
http://www.vanemery.com/Linux/Ramdisk/ramdisk.html
If you are using LILO like in the example listed at the link above,
you need to make sure your ramdisk_size parameter is big enough.
That's what my gues is.
-stv
^ permalink raw reply
* Kernel bug reports welcome here?
From: Wolfgang Pfeiffer @ 2006-05-10 13:51 UTC (permalink / raw)
To: linuxppc-dev
Hi All
I'm running a git kernel with sources from about last Sunday, on a
alubook5.8, and I would like to know whether bug reports, if things
don't work with this kernel (there are a few ... :), will be welcome
here.
If not: Where's the better place for reports like that: Linux kernel
mailing list?
Just in case if this might help:
$ cat /proc/cpuinfo
processor : 0
cpu : 7447A, altivec supported
clock : 833.333000MHz
revision : 0.5 (pvr 8003 0105)
bogomips : 16.57
timebase : 8320000
platform : PowerMac
machine : PowerBook5,8
motherboard : PowerBook5,8 MacRISC3 Power Macintosh
detected as : 287 (PowerBook G4 15")
pmac flags : 00000019
L2 cache : 512K unified
pmac-generation : NewWorld
$ 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
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: Help Needed: input overrun(s)
From: Stevan Ignjatovic @ 2006-05-10 13:32 UTC (permalink / raw)
To: s.maiti; +Cc: linuxppc-embedded
In-Reply-To: <OF00585CA1.4BAD2F12-ON6525716A.0018127A-6525716A.00191467@tcs.com>
Hello,
On Wed, 2006-05-10 at 06:33, s.maiti@tcs.com wrote:
> Hi all,
>
> I am currently involve in development of Multi-Channel Controller (MCC)
> driver for MPC8260 processor. Whenever we are loading the driver, on the
> 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 seen the memory map thoroughly, there is no issue of
> memory conflict. Any help in this regards, I will be grateful.
>
> Thnaks and regards,
> Souvik Maiti
> Tata Consultancy Services Limited
> Mailto: s.maiti@tcs.com
> Website: http://www.tcs.com
> =====-----=====-----=====
> 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
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Regards,
Stevan
^ permalink raw reply
* Re: Failed to do bolted mapping IO memory with minimal .config
From: Olaf Hering @ 2006-05-10 11:25 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060510095943.GA15460@suse.de>
On Wed, May 10, Olaf Hering wrote:
> CONFIG_NR_CPUS=4
It boots if I change this to 8.
^ permalink raw reply
* Re: Viable PPC platform?
From: Alex Zeffertt @ 2006-05-10 11:11 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded, gd.smth
In-Reply-To: <20060509171520.GA10886@gate.ebshome.net>
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.
Alex
^ permalink raw reply
* Re: Calculating virtual address from physical address
From: David H. Lynch Jr. @ 2006-05-10 11:04 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <200605061843.k46Ih5Vd032048@www-webmail1.magma.ca>
Chris Dumoulin wrote:
> Thanks for your reply; I found it very useful and interesting. Now, I have a whole bunch
> of questions.
>
> You said that the temporary TLB entries setup in head_4xx.S will eventually be replaced.
> Where is the code that creates these new TLB entries later on? Are the 'real' TLB entries
> only created once, and persist for as long as the system is running, or do TLB entries
> change often while the system is running?
>
It has been a few months since I was deep in this, so I am weaker on
details at the moment.
But the gist is that the MMU in PowerPC's is primarily software
driven. It functions as a cache - there are alot of details, but unless
you arfe getting really deep into memory management you can think of the
MMU as a 64 entry cache. Software - in this instance the Linux VM system
is responsible for deciding exactly what happens when the cache is full
and a new entry needs added.
Manually stuffing an entry into the MMU is safe up until that event
occurs.
The VM system entries ("real" entries if you wish) are in Linux
Memory management data structures - page tables etc. When a page fault
occurs Linux looks up the correct entry in its tables and replaces one
in the MMU with the required one. Unlike X86's where much of this is
implimented in hardware, in a PowerPC the replacement algorithm can be
anything you want - it is written in software. Therefore handling page
faults is likely to be slower, but the OS is in total control of all
aspects of Memory management. It has very few constraints imposed on it
by the MMU.
"Real" entries are created and destroyed inside the kernel by
anything that wants memory. Drivers demand mapping of IO based memory
typically when they initiallize and should release it when they unload.
Programs request memory when they need it and release it when they
are done. There are subtle differences between IO memory mapping - the
virtual address for an IO mapped memory device MUST corresponf to a
specific set of addresses, while ordinary requests for a memory mapping
can be satisfied by most any block of memory.
> Do you know what state the MSR will be in at this point in the code? I know what the
> power-on reset state is, but I'm wondering if it'll be in a different state by the time we
> get to this point in head_4xx.S.
>
I am not sure that Linux sets the MSR at any point prior to
head_4xx.S. Regardless, greping the ppc directories within kernel source
for MSR_KERNEL will expose the bits their definitions and the normal state,
In my instance to avoid machine checks I had to conditionally
redefine MSR_KERNEL in one header file to avoid machine checks.
> When you suggest disabling instruction or data address translation, is that just so I
> could access my hardware directly, or is there some other reason?
>
Atleast for me getting through the rfi to start_here: which should
be where you end up immediately after the rfi proved very difficult.
by enabling bits one at a time I was able to test what was happening
and establish what was working. I.E if you only enable instruction
translation, you can still write to your physical IO port, but the 'rfi'
will take you to the virtual address 'start_here:'
This was solely a debugging and problem isolation approach. It also
enabled me to test things bit by bit and assure my self that everything
worked, while loading the MSR with the default KERNEL MSR value and
executing the rfi presumes that a number of things are all setup
properly - a failure in any of them would create a problem. It is not
often in programming that a single instructions makes so many changes
all at once, and therefore in one instant requires so many of them to be
right.
I actually wrote some code the stuffed a value at specific physical
addresses, turned on data address mapping, read the value from the
correct virtual address turned of mapping and then wrote the value to my
debug port.
I also was able to test the TLB entry I inserted the same way.
The bit by bit approach is just a way to figure out why you can not
get from "real" mode to "virtual" mode by dividing the problem into
small testable peices.
> You were enabling the MSR bits, one at a time, and found that the machine check was
> causing the hang (I'm assuming that's what you meant by 'sent me to space'). Was the idea
> there to just isolate what type of exception was causing the hang, or were you looking to
> make some permanent changes to the MSR? Is a machine check interrupt caused by trying to
> access an address that doesn't have a TLB entry?
>
Unless I am completely mistaken, machine checks are not cause by
softwded are or programming errors, they are cause by hardware problems,
or atleast by hardware reporting problems In my instance I forwarded I
c the problem to the FPGA programmers, and disabled the machine check so
that I could move on.
I was able to get some clues prior to my bit by bit tests. I had
established fairly quickly that instead of going to start_here that I
was getting into the exception handlers. But that mislead me into the
belief I had something worng with my memory configuration. I was not
trying to isolate the exception. Maybe I should have. I made the
asumption that the exception was programming related and therfore had
something to do with my choices regarding memory.
I was messing with the MSR to try to cut the problem into peices and
deal with each individually.
As I understand it a machine check is generated by hardware. It is a
general purpose something bad that should nto have happened happened
with the hardware. I think it can happen if you address physical memory
that does nto exists. My theory for whatever it is worth is that I asked
the FPGA programmers to reorganize the memory map to zero org all RAM.
as I was advised that getting Linux up otherwise was going to be very
hard. I beleive that when they did that the screwed up the memory check
logic and now it is generating checks on valid accesses. But that is
just a theory. The FPGA people tell me I am wrong and that Machine check
is actually hardwired permanently to the correct level and does nothing.
Regardless I was getting Machine Checks, and disabling them got
Linux booted. If and when the FPGA people ever figure out what is wrong
I can re-enable them in about 10 minutes.
> Can you point me to some information about Grant's platform bus changes that you were
> talking about? I am using a custom V2Pro board, and I'd be interested to see if this code
> is something I should be looking at.
>
Look at the changes to xilinx devices in arch/ppc/platform/4xx/
between maybe 2.6.13 and 2.6.16. There are changes elsewhere, but that
is where I tripped over them.
> Thanks alot,
> Chris
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too
numerous to list.
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction."
Albert Einstein
^ permalink raw reply
* Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
From: David Howells @ 2006-05-10 10:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-arch, linux-kernel, linuxppc-dev, paulus, olof,
David S. Miller
In-Reply-To: <1147245709.32448.74.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > That first cache line of current_thread_info() should be so hot that
> > it's probably just fine to use current_thread_info()->task since
> > you're just doing a mask on a fixed register (r1) to implement that.
>
> Iirc, he tried that, though it did bloat the kernel size a bit due the
> the amount of occurences of current-> in there. We are now thinking
> about either dedicating a register to current (that would avoid the
> problem of printk() using it in start_kernel before we get the per-cpu
> areas setup) in addition to __thread (heh, we have lots of registers on
> ppc :) or maybe putting current back in the paca...
I dedicated registers to current and current threadinfo in the FRV arch. As I
recall doing that improved both performance and code size quite a bit. It also
means that I get sensible bug panic reports when the stack pointer overruns the
stack space.
David
^ permalink raw reply
* Kernel panic - not syncing: No init found.
From: hangtoo @ 2006-05-10 9:40 UTC (permalink / raw)
To: linuxppc-embedded
I try to make a new uRamdisk for my bubinga board(linux-2.6.14,PPC405EP).
actully I just copy the most of the files in the board,and compiled busybox with ppc tools.
but when I use the new uRamdisk for a try,it just showed up this errors(as follow),then reboot,back and forth...
**************************************************
RAMDISK: incomplete write (-28 != 32768) 4194304
EXT2-fs warning: checktime reached, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 116k init
attempt to access beyond end of device //this is where the error begins.
ram0: rw=0, want=10330, limit=8192
Buffer I/O error on device ram0, logical block 5164
attempt to access beyond end of device
ram0: rw=0, want=10330, limit=8192
Buffer I/O error on device ram0, logical block 5164
attempt to access beyond end of device
ram0: rw=0, want=10330, limit=8192
Buffer I/O error on device ram0, logical block 5164
attempt to access beyond end of device
ram0: rw=0, want=10330, limit=8192
Buffer I/O error on device ram0, logical block 5164
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
//according to this note,is there something I have to do with my kernel??
<0>Rebooting in 1 seconds..
*************************************************
Any help is appreciated.
regards
tony
^ 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