* Re: AltiVec in the kernel
From: Linas Vepstas @ 2006-07-21 16:51 UTC (permalink / raw)
To: Matt Sealey
Cc: 'Olof Johansson', 'linuxppc-dev list',
'Paul Mackerras'
In-Reply-To: <000001c6acd3$ea93f5c0$99dfdfdf@bakuhatsu.net>
On Fri, Jul 21, 2006 at 09:42:32AM -0500, Matt Sealey wrote:
>
> > > http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
> >
> > 128-bit AltiVec operations are still being solicited.
>
> "Still"?
>
> http://www.freevec.org/
>
> Been there for months, before the glibc thing. Most of the functions
> are ready. Anyone can bugfix this. The beauty of GPL. The ugly part
> is.. we've had this there for months. Nobody has contributed a single
> update or bugfix or even a performance test as far as I know.
Sounds like a problem of advertising and communications. This is
kind of "under the radar" for most users and developers. It needs to
work out-of-the-box, most people, even those with interest in
performance, will not even be aware of the possibility to tne this.
It should be folded into glibc. It is up to the altivec product vendor
to nag the glibc folks into folding it in. This task could be as hard
as writing the code in the first place.
> Indeed it's a cute feature but we were scared away by the glibc guys
Many maintainers of core libraries have similar behaviour patterns.
Besides glibc, gcc and gsl come to mind. This is becase they get tired out
by naive eager-beavers who walk in with the greatest idea in the world,
make a big fuss about it, and the proceed to demonstrate that they have
absolutely no clue of what they're talking about. For every ten of
those, there's maybe one legit idea. Worse, many of these "clueless
newbies" come in the surprising shape of PhD's working outside thier
specialty, and can convingingly sling jargon and authority for a while
before its realized they're just... clueless.
If you've got good code, you'll just need to be persistent.
--linas
^ permalink raw reply
* Re: mpic discovery on JS20
From: Benjamin Herrenschmidt @ 2006-07-21 17:37 UTC (permalink / raw)
To: Amos Waterland; +Cc: linuxppc-dev
In-Reply-To: <20060720231601.GA24736@kvasir.watson.ibm.com>
On Thu, 2006-07-20 at 19:16 -0400, Amos Waterland wrote:
> Current Linus and Paulus trees do this on JS20 blades with SLOF:
I need a tarball of /proc/device-tree on these.
> Failed to locate the MPIC interrupt controller
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> Maple: Found RTC at IO 0x1070
> cpu 0x0: Vector: 700 (Program Check) at [c00000007ef83ab0]
> pc: c00000000002e0c8: .mpic_request_ipis+0x34/0xc8
> lr: c00000000036b484: .smp_mpic_probe+0x3c/0x58
> sp: c00000007ef83d30
> msr: 9000000000029032
> current = 0xc00000000194d610
> paca = 0xc00000000038f180
> pid = 1, comm = swapper
> kernel BUG in mpic_request_ipis at arch/powerpc/sysdev/mpic.c:1132!
>
> Doing a git-bisect produces this:
>
> 0ebfff1491ef85d41ddf9c633834838be144f69f is first bad commit
> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Mon Jul 3 21:36:01 2006 +1000
>
> [POWERPC] Add new interrupt mapping core and change platforms to use it
>
> This adds the new irq remapper core and removes the old one. Because
> there are some fundamental conflicts with the old code, like the value
> of NO_IRQ which I'm now setting to 0 (as per discussions with Linus),
> etc..., this commit also changes the relevant platform and driver code
> over to use the new remapper (so as not to cause difficulties later
> in bisecting).
>
> This patch removes the old pre-parsing of the open firmware interrupt
> tree along with all the bogus assumptions it made to try to renumber
> interrupts according to the platform. This is all to be handled by the
> new code now.
>
> For the pSeries XICS interrupt controller, a single remapper host is
> created for the whole machine regardless of how many interrupt
> presentation and source controllers are found, and it's set to match
> any device node that isn't a 8259. That works fine on pSeries and
> avoids having to deal with some of the complexities of split source
> controllers vs. presentation controllers in the pSeries device trees.
>
> The powerpc i8259 PIC driver now always requests the legacy interrupt
> range. It also has the feature of being able to match any device node
> (including NULL) if passed no device node as an input. That will help
> porting over platforms with broken device-trees like Pegasos who don't
> have a proper interrupt tree.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: AltiVec in the kernel
From: Matt Sealey @ 2006-07-21 18:08 UTC (permalink / raw)
To: 'Linas Vepstas'
Cc: 'Olof Johansson', 'linuxppc-dev list',
'Paul Mackerras'
In-Reply-To: <20060721165130.GS5905@austin.ibm.com>
> Sounds like a problem of advertising and communications.
> This is kind of "under the radar" for most users and
> developers. It needs to work out-of-the-box, most people,
> even those with interest in performance, will not even be
> aware of the possibility to tne this.
It's listed on every site we have, and on PenguinPPC.org too if I
recall (hi Hollis) it even got a sticky news item like a lot of the
stuff we do (thanks Hollis :).
Everyone who cares knows about it, I would think. Probably not
enough people care, is the problem.
> It should be folded into glibc. It is up to the altivec
> product vendor to nag the glibc folks into folding it in.
You mean Freescale? Or Genesi?
Freevec was being developed as a "perfect opportunity". glibc-ports
came to life and was something that code could be contributed to.
Since it was such a hassle dealing with the glibc guys, it ended up
being a seperate library for now.
> This task could be as hard as writing the code in the first place.
I think we could handle it if there were less stubborn mules maintaining
the most important software. I can think of one guy in particular.. but
I won't name him.
> Many maintainers of core libraries have similar behaviour patterns.
> Besides glibc, gcc and gsl come to mind. This is becase they
> get tired out by naive eager-beavers who walk in with the
> greatest idea in the world
I think this kind of behaviour stalls Open Source software,
because it unfairly treats those *with* clues.
<-us-> do you want the AltiVec code or not?
<them> Oh no because I am bored of dealing with people who only had ideas!!
It doesn't make much sense politically or technically.
So like I said we could have had this code in glibc when glibc-ports
first was conceptualised and then released, but there was just too
many mules in the way.
Check the freevec.org whitepapers section), Konstantinos is not just
"ideas", he proved out optimizations and then implemented them.
Is it his fault that they're not in glibc, because he's "stupid" or
"clueless"? :D
> If you've got good code, you'll just need to be persistent.
Personally I am pretty tired (in return) with angry-faced Open
Source developers deciding that "Open Source" is equivalent to
"My Source, Back Off, Your Patch Sucks". It is always the choice
of the lead developer (and/or copyright holder) to refuse
patches, but.. seriously.. a lot of Open Source development is
the wrong kind of dictatorship.
Cynicism aside.. :D
</rant>
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
^ permalink raw reply
* Re: problems with mounting JFFS2 using CFI for AM29LV160MT on ppc8245 k2.4.x
From: Ben Warren @ 2006-07-21 16:20 UTC (permalink / raw)
To: Arun Kumar; +Cc: linuxppc-embedded
In-Reply-To: <edd12c050607210756h71bab7f8ve323edf3bf6077c6@mail.gmail.com>
Hi Arun,
On Fri, 2006-07-21 at 20:26 +0530, Arun Kumar wrote:
> Hi ,
> Can anyone help me in this naive problem ?
>
Then a naive answer is most fitting... Turns out that's my specialty.
> #
> # Memory Technology Devices (MTD)
> #
> CONFIG_MTD=y
> CONFIG_MTD_DEBUG=y
> CONFIG_MTD_DEBUG_VERBOSE=2
> CONFIG_MTD_PARTITIONS=y
> CONFIG_MTD_CONCAT=y
> CONFIG_MTD_REDBOOT_PARTS=y
> CONFIG_MTD_CMDLINE_PARTS=y
Probably get rid of REDBOOT if you're not using that bootloader
>
> #
> # User Modules And Translation Layers
> #
> # CONFIG_MTD_CHAR is not set
> # CONFIG_MTD_BLOCK is not set
> # CONFIG_MTD_BLOCK_RO is not set
> # CONFIG_FTL is not set
> # CONFIG_NFTL is not set
> # CONFIG_INFTL is not set
>
You need to enable MTD_CHAR to read/write and MTD_BLOCK to mount
> Can any happy soul let me know :--
>
> 1)How to mount jffs2 on this flash and also to test mtd->read/write
> routines ?
Start with the char drivers (/dev/mtd0 etc.). You'll need one for each
partition you want to experiment with.
How about creating the nodes manually?
mknod /dev/mtd0 c 90 0
mknod /dev/mtd1 c 90 2 etc. (minor # increments in 2s)
Add a block device for each partition:
mknod /dev/mtdblock0 b 31 0
mknod /dev/mtdblock1 b 31 1 etc.
Once you clean up #3 below, you should be able to read/write the char
devices using commands like 'cat', or write a simple user-space app
using "open, read, write", etc if you'd rather look at the actual binary
data.
You can then experiment with mounting the JFFS2. I recommend booting to
an NFS file system then mounting the JFFS2 with something like:
mount -t jffs2 /dev/mtdblock5 /mnt/temp (Use the correct partition)
>
> 2) Is it ok not to see mtd0.. partions in /dev directory .
Pretty sure you'll need these
>
> 3 ) Where do I register the mtd partitions to get them noticed
> here ??
Looks like your partitions are already being found, but are probably not
set up right. I don't know if this is a static definition in your board
init code or passed by command line from the bootloader, but it looks
like the values don't line up with your device:
*********
Using physmap partition definition
Creating 3 MTD partitions on "phys_mapped_flash":
0x00000000-0x00040000 : "foo-ets0"
mtd: Giving out device 0 to foo-ets0
0x00040000-0x001e0000 : "foo-ets1"
mtd: partition "agere-ets1" doesn't end on an erase block -- force
read-only
mtd: Giving out device 1 to foo-ets1
0x001e0000-0x00200000 : "foo-ets2"
mtd: partition "foo-ets2" doesn't start on an erase block boundary --
force read-only
*********
--------------------------------------------------------------------------
Hopefully this helps you proceed a little bit.
regards,
Ben
^ permalink raw reply
* Re: AltiVec in the kernel
From: Brian D. Carlstrom @ 2006-07-21 18:46 UTC (permalink / raw)
To: Linas Vepstas
Cc: 'Olof Johansson', 'Paul Mackerras',
'linuxppc-dev list'
In-Reply-To: <20060721165130.GS5905@austin.ibm.com>
At Fri, 21 Jul 2006 11:51:30 -0500,
Linas Vepstas wrote:
> If you've got good code, you'll just need to be persistent.
While I agree with most of Matt's rant, I think Linas is right as well.
Hearing that code is already in a distribution like Gentoo makes it
easier to make the case that the code doesn't suck or is vaporware.
-bri
disclaimer: a PhD student working outside my specialty :)
^ permalink raw reply
* Boot problem on Sandpoint
From: Benoit Lajoie-Dorval @ 2006-07-21 18:49 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
Hi all,
I have to port Linux on a Sandpoint Board wtih a MPC8241 processor on. I
built a kernel using linux 2.6.15 and create an zImage.initrd.elf with a
ramdisk. All of this (linux and ramdisk) was packaged with ELDK 4.0. I also
minimized everything in the .config file to only have what is really
necessary (serial port, 6xx processor, etc). The communication is made with
the board by its internal serial port and Dink32 is used to do everything
else.
The problem is that when I execute the loaded zImage.initrd.elf, the boot
sequence just hangs there and I just don't see anything happening. There is
nothing that is displayed. I know that the elf file as an offset header of
0X10000, so the problem is not there. I also put some breakpoints and trace
using Dink32 to see where it stops and it may have something to do with the
disable_6xx_mmu in the utils.S file.
I just really don't know what's wrong in my config and I hope someone could
help me on this.
Thank you
Benoit Lajoie-Dorval
^ permalink raw reply
* Re: Boot problem on Sandpoint
From: Mark A. Greer @ 2006-07-21 19:58 UTC (permalink / raw)
To: Benoit Lajoie-Dorval; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <D3A60B685BD79544ACA481B73FA81EA02F4F27@COBALT>
On Fri, Jul 21, 2006 at 11:49:14AM -0700, Benoit Lajoie-Dorval wrote:
> Hi all,
> I have to port Linux on a Sandpoint Board wtih a MPC8241 processor on.
Tell your boss that it'll take 3 months including lots of overtime,
then crack open a beer! The sandpoint/8241 has been working for years.
> built a kernel using linux 2.6.15 and create an zImage.initrd.elf with a
> ramdisk. All of this (linux and ramdisk) was packaged with ELDK 4.0. I also
> minimized everything in the .config file to only have what is really
> necessary (serial port, 6xx processor, etc). The communication is made with
> the board by its internal serial port and Dink32 is used to do everything
> else.
>
> The problem is that when I execute the loaded zImage.initrd.elf, the boot
> sequence just hangs there and I just don't see anything happening. There is
> nothing that is displayed. I know that the elf file as an offset header of
> 0X10000, so the problem is not there. I also put some breakpoints and trace
> using Dink32 to see where it stops and it may have something to do with the
> disable_6xx_mmu in the utils.S file.
>
> I just really don't know what's wrong in my config and I hope someone could
> help me on this.
Well, you did lots of things that could have broken it. Go back to
square one: default .config with nfs mounted rootfs. Get that to work
then tune the .config and add a ramdisk.
Also, if you have a bdi2000 or some other jtag/cops debugger, you can
dump __log_buf and see if there is anything there.
Mark
^ permalink raw reply
* stupid linker question....
From: Steve Iribarne (GMail) @ 2006-07-21 20:06 UTC (permalink / raw)
To: linuxppc-embedded
I forgot the flag that generates a list file that has both assembly
and c mixed in.
Anyone?
Thanks...
-stv
^ permalink raw reply
* Re: stupid linker question....
From: Wade Maxfield @ 2006-07-21 21:10 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: linuxppc-embedded
In-Reply-To: <b4b98b690607211306rea34437gb05e84d24e8c66a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
gcc -Wa,-alhs -g main.c >main.cs
will put interleaved code/assembly into main.cs file.
wade
On 7/21/06, Steve Iribarne (GMail) <netstv@gmail.com> wrote:
>
> I forgot the flag that generates a list file that has both assembly
> and c mixed in.
>
> Anyone?
>
> Thanks...
>
> -stv
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 898 bytes --]
^ permalink raw reply
* Re: AltiVec in the kernel
From: Hollis Blanchard @ 2006-07-21 21:30 UTC (permalink / raw)
To: Linas Vepstas, Matt Sealey
Cc: 'Olof Johansson', 'linuxppc-dev list',
'Paul Mackerras', Konstantinos Margaritis
In-Reply-To: <20060721165130.GS5905@austin.ibm.com>
On Fri, 21 Jul 2006 11:51:30 -0500, "Linas Vepstas"
<linas@austin.ibm.com> said:
> On Fri, Jul 21, 2006 at 09:42:32AM -0500, Matt Sealey wrote:
> > http://www.freevec.org/
> >
> > Been there for months, before the glibc thing. Most of the functions
> > are ready. Anyone can bugfix this. The beauty of GPL. The ugly part
> > is.. we've had this there for months. Nobody has contributed a single
> > update or bugfix or even a performance test as far as I know.
>
> Sounds like a problem of advertising and communications. This is
> kind of "under the radar" for most users and developers. It needs to
> work out-of-the-box, most people, even those with interest in
> performance, will not even be aware of the possibility to tne this.
It is difficult to make sure every OSS developer is notified of all work
they may be interested in...
However, I have noticed a trend where Genesi people seem to think
everybody pays attention to their websites (and the same could be said
for Debian and other subcultures). In this case there actually have been
other people aware of this project, but not very many. Considering all
the traffic about it on ppczone.org, people looking for exposure for
their project may want to look beyond PPCZone.
> It should be folded into glibc. It is up to the altivec product vendor
> to nag the glibc folks into folding it in. This task could be as hard
> as writing the code in the first place.
Konstantinos is aware of Steve's glibc project and has indicated he'll
try to contribute to it.
To be fair, probably not many people have heard of Steve's project
either. I doubt Konstantinos would have heard of it if I hadn't
mentioned it.
-Hollis
^ permalink raw reply
* Re: AltiVec in the kernel
From: Peter Bergner @ 2006-07-21 22:21 UTC (permalink / raw)
To: Brian D. Carlstrom
Cc: Olof Johansson, 'linuxppc-dev list',
'Paul Mackerras', Steve Munroe
In-Reply-To: <lezmf4j5ym.wl%bdc@carlstrom.com>
On Thu, 2006-07-20 at 14:56 -0700, Brian D. Carlstrom wrote:
> At Thu, 20 Jul 2006 14:05:23 -0500, Olof Johansson wrote:
> > http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
>
> Very interesting. According to that page, the memcpy optimizations seem
> to be using 64-bit operations and that 128-bit AltiVec operations are
> still being solicited.
>
> I was encouraged to see the following:
>
> If you need to build generic distributions (supporting several
> <cpu_types>) you can leverage the dl_procinfo support built into
> glibc. This mechanism allows for multiple versions of the core
> libraries (libc, libm, librt, libpthread, libpthread_db) to be
> stored in hardware/platform specific subdirectories under /lib[64].
Actually, this support is not limited to the core glibc routines or
the system lib directors /lib/ and /usr/lib/. This works just as well
for third party shipped libraries in their own library trees as the
following example (on a power5 box) shows:
bergner@vervainp1:~/cpu-tuned-libs> pwd
/home/bergner/cpu-tuned-libs
bergner@vervainp1:~/cpu-tuned-libs> ls lib/ lib/power5/
lib/:
libfoo.so power5/
lib/power5/:
libfoo.so
bergner@vervainp1:~/cpu-tuned-libs> gcc
-L/home/bergner/cpu-tuned-libs/lib -R/home/bergner/cpu-tuned-libs/lib
main.c -lfoo
bergner@vervainp1:~/cpu-tuned-libs> ldd a.out
linux-vdso32.so.1 => (0x00100000)
libfoo.so => /home/bergner/cpu-tuned-libs/lib/power5/libfoo.so
(0x0ffde000)
libc.so.6 => /lib/power5/libc.so.6 (0x0fe69000)
/lib/ld.so.1 (0xf7fe1000)
bergner@vervainp1:~/cpu-tuned-libs> ./a.out
Loaded the optimzed lib
bergner@vervainp1:~/cpu-tuned-libs> rm lib/power5/libfoo.so
bergner@vervainp1:~/cpu-tuned-libs> ldd a.out
linux-vdso32.so.1 => (0x00100000)
libfoo.so => /home/bergner/cpu-tuned-libs/lib/libfoo.so
(0x0ffde000)
libc.so.6 => /lib/power5/libc.so.6 (0x0fe69000)
/lib/ld.so.1 (0xf7fe1000)
bergner@vervainp1:~/cpu-tuned-libs> ./a.out
Loaded the unoptimzed lib
The runtime loader magic uses the AT_PLATFORM string value as
the subdirectory to search in under the .../lib/ or .../lib64/
library directory. To find out what your AT_PLATFORM value is
on your current box, you can do:
bergner@vervainp1:~/cpu-tuned-libs> LD_SHOW_AUXV=1 /bin/true
AT_DCACHEBSIZE: 0x80
AT_ICACHEBSIZE: 0x80
AT_UCACHEBSIZE: 0x0
AT_SYSINFO_EHDR: 0x100000
AT_HWCAP: power5 mmu fpu ppc64 ppc32
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x10000034
AT_PHENT: 32
AT_PHNUM: 9
AT_BASE: 0xf7fe1000
AT_FLAGS: 0x0
AT_ENTRY: 0x10000980
AT_UID: 1001
AT_EUID: 1001
AT_GID: 100
AT_EGID: 100
AT_SECURE: 0
AT_PLATFORM: power5
> However, I'm guessing this addon is not something found in common
> distributions for PowerPC like Debian, Fedora, Gentoo, Ubuntu, ...
At last years GCC Developers Summit, one of the Ubuntu guys mentioned
he was interested in adding it to Ubuntu. I haven't heard whether that
has shown up yet though. It will be available in upcoming SUSE and
Red Hat enterprise distros. I don't know about the others. As Olof
mentioned, it can take some lead time for this to get picked up.
There's also the question of how many and which processors a distro
will ship cpu optimized libraries for. Given all of the PowerPC
variants, they obviously can ship optimized libs for everything.
Peter
^ permalink raw reply
* Re: AltiVec in the kernel
From: Segher Boessenkool @ 2006-07-22 3:09 UTC (permalink / raw)
To: matt
Cc: 'Olof Johansson', 'linuxppc-dev list',
'Paul Mackerras'
In-Reply-To: <002b01c6acf0$a7417050$99dfdfdf@bakuhatsu.net>
> Freevec was being developed as a "perfect opportunity". glibc-ports
> came to life and was something that code could be contributed to.
> Since it was such a hassle dealing with the glibc guys, it ended up
> being a seperate library for now.
Do you have a pointer to an archive of that email thread? I can't
remember it.
You could give Freevec a whole lot more exposure, to people who
might be more interested in it than the average glibc user, by
putting it into uClibc first. Additional advantage is that you
don't have to care about forward/backward compatibility issues,
or even whether the platform a binary ends up running on actually
has AltiVec or not (uClibc gets tailored to the exact system it
runs on at compile time). So you can focus on the routines you
want to speed up instead of on all the infrastructure stuff
required for glibc.
You'll have to update uClibc's PowerPC port first though (mostly
just copying stuff from recent glibc) -- it seems the libc AltiVec
support (for handling setjmp() etc.) isn't in there yet.
>> This task could be as hard as writing the code in the first place.
Not as hard. Way, way harder instead. Part of that is that the
code probably really isn't good enough yet, sorry. And then there's
all the compatibility stuff, and symbol versioning, etc. And the
communication issue, of course.
Segher
^ permalink raw reply
* Reg. virtual address space in embedded linux
From: jagannathanjay @ 2006-07-22 5:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 958 bytes --]
Hi all
We are porting third party driver code from vxworks to Embedded linux in MPC 8260 under a evaluation platform from Embedded Planet in linux kernel space.
The first step we carried out was reading the chip id and we were able to read the chip id correctly. For reading the chip id we used the routine ChipReadMemory in the attached text and we were able to retrive the chip id successfully. Subsequently when we write and read from Chip Specific Control Status registers ,it didn't work. I checked the manual and the Chip Specific Control Status registers have RW access. Any inputs on how to check if the write we made to virtual address succeeds? Is there a way to dump the linux virtual address and examine the write we made ?
Regards
Jay
________________________________________________________________________
Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection.
[-- Attachment #1.2: Type: text/html, Size: 2129 bytes --]
[-- Attachment #2: RWroutines.txt --]
[-- Type: text/plain, Size: 831 bytes --]
int ChipReadMemory(unsigned int arg_phys_addr,unsigned int *memValue)
{
void *virt_addr = NULL;
unsigned int phys_addr = 0;
phys_addr = DEVICE_BASE_ADDRESS + arg_phys_addr;
virt_addr = ioremap(phys_addr, 4);
if(virt_addr == NULL)
{
printk("ChipReadMemory: unable to perform ioremap \n");
return -1;
}
*memValue = readl(virt_addr);
iounmap(virt_addr);
return 0;
}
int ChipWriteMemory(unsigned int arg_phys_addr, unsigned int arg_val)
{
void *virt_addr = NULL;
unsigned int phys_addr = 0;
phys_addr = DEVICE_BASE_ADDRESS + arg_phys_addr;
virt_addr = ioremap(phys_addr, 4);
if(virt_addr == NULL)
{
printk("ChipWriteMemory : unable to perform ioremap \n");
return -1;
}
writel(arg_val,virt_addr);
iounmap(virt_addr);
return 0;
}
^ permalink raw reply
* linux kernel hang in execve("/sbin/init")
From: Eric Nuckols @ 2006-07-22 6:10 UTC (permalink / raw)
To: linuxppc-embedded
I googled...and googled...etc. etc.. when trying to solve the problem of my
linux kernel seemingly locking or hanging when it gets to the last part of
the linux init in main.c
I saw lots of information and suggestions related to try /bin/sh or make
sure your initrd is ok or make sure you have more than one session..etc.
etc... .. and all of these topics were mostly from 2001-2003...well..
2006...it's here and apparently some of us haven't gotten smarter..
I had this problem recently where my kernel would boot and freeze or hang in
execve of /sbin/init and also of /bin/sh or /bin/bash...
I debugged and debugged.. and finally thougt... why not try the default
Kernel config for my target, the PrPmc800 from Motorola... and see what that
does.. Originally, I started with the MontaVista 3.1 Pro setup for the
board and it works...so I used it's Kernel .config file to configure my
latest and greatest (at the time) 2.6.16.18 kernel thinking... well.. this
has to work..
so.. I ended up with a kernel that semingly hang/froze/locked on the execve
call in the linux init routines...
guess what folks... the google searches left me just on the verge of giving
up.
I am here to post this info as somewhat of another answer/alternative to
people in the same predicament...
if you are having problems with your cross-compiled / embedded ppc kernel
freezing or hanging on execve, try using the default configuration for your
target when you build the kernel...
in my case, I did this sort of thing and all of a sudden, my kernel was
working:
cd to kernel dir
make distclean
make CROSS_COMPILE=powerpc-7400-linux-gnu- prpmc800_defconfig
make zImage.initrd
etc..etc..
it turns out that since I was basing my initial config off of the 2.4.x
.config from MontaVista, my kernel didn't boot as desired...
so I figured.. after all the googling and working on it that the default
PrPmc800 config had to boot... why else call it the default config..
so that's my story.. since then, I have copied the kernel
dir/arch/ppc/configs/prpmc800_defconfig to a temporary file, and modified it
as necessary...
moral of the story... if you are cross-compiling and having problems where
you hang on execve("/sbin/init") or execve("/bin/sh") or
execve("/bin/bash")..etc... try what I did before you go crazy analyzing
the initrd or the various /etc/ file configurations or any of the other
typical bs...
^ permalink raw reply
* Re:Re: AltiVec in the kernel
From: Konstantinos Margaritis @ 2006-07-22 9:38 UTC (permalink / raw)
To: Hollis Blanchard, Linas Vepstas, Matt Sealey
Cc: 'Olof Johansson', 'linuxppc-dev list',
'Paul Mackerras', Konstantinos Margaritis
(Writing this on a wap mobile phone)
actually, i knew about steve's effort as i am subscribed to glibc-ports. the problem is i am doing my military service this whole period (right now i am a sentry guard at an oupost somewhere in rhodes :-). the good news is that in about a month or less i'll return close to my home and i intend to get back to work asap. but till then i'm stuck here.
konstantinos
_____________________________
I sent this message from my cell phone using flurry.
Click here to get your email and news on your cell phone for free:
http://www.flurry.com
--- Original Message ---
Date: Fri Jul 21 14:30:56 PDT 2006
From: Hollis Blanchard <hollis@penguinppc.org>
To: Linas Vepstas <linas@austin.ibm.com>, Matt Sealey <matt@genesi-usa.com>
Subject: Re: AltiVec in the kernel
---
On Fri, 21 Jul 2006 11:51:30 -0500, "Linas Vepstas"
<linas@austin.ibm.com> said:
> On Fri, Jul 21, 2006 at 09:42:32AM -0500, Matt Sealey wrote:
> > http://www.freevec.org/
> >
> > Been there for months, before the glibc thing. Most of the functions
> > are ready. Anyone can bugfix this. The beauty of GPL. The ugly part
> > is.. we've had this there for months. Nobody has contributed a single
> > update or bugfix or even a performance test as far as I know.
>
> Sounds like a problem of advertising and communications. This is
> kind of "under the radar" for most users and developers. It needs to
> work out-of-the-box, most people, even those with interest in
> performance, will not even be aware of the possibility to tne this.
It is difficult to make sure every OSS developer is notified of all work
they may be interested in...
However, I have noticed a trend where Genesi people seem to think
everybody pays attention to their websites (and the same could be said
for Debian and other subcultures). In this case there actually have been
other people aware of this project, but not very many. Considering all
the traffic about it on ppczone.org, people looking for exposure for
their project may want to look beyond PPCZone.
> It should be folded into glibc. It is up to the altivec product vendor
> to nag the glibc folks into folding it in. This task could be as hard
> as writing the code in the first place.
Konstantinos is aware of Steve's glibc project and has indicated he'll
try to contribute to it.
To be fair, probably not many people have heard of Steve's project
either. I doubt Konstantinos would have heard of it if I hadn't
mentioned it.
-Hollis
^ permalink raw reply
* Re: [PATCH 0/6] bootwrapper: arch/powerpc/boot code reorg patches
From: Tom Rini @ 2006-07-22 15:04 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060719225356.GA3887@mag.az.mvista.com>
On Wed, Jul 19, 2006 at 03:53:56PM -0700, Mark A. Greer wrote:
> The following emails from me in this thread are the latest set of
> patches that reorg the bootwrapper code so that OF and non-OF
> platforms can live together.
>
> I punted somewhat on "The Tool" that's been talked about that takes a
> kernel and attaches a flattened device tree (fdt) to it. I thought
> about it for a while but I think we need to clarify the requirements
> better before it makes sense to spend a lot of cycles on it.
Great! As the last person to know what all this code was doing in
arch/ppc/boot, I'll try and give it all a review..
--
Tom Rini
^ permalink raw reply
* RE: AltiVec in the kernel
From: Matt Sealey @ 2006-07-23 13:28 UTC (permalink / raw)
To: 'Segher Boessenkool'
Cc: 'Olof Johansson', 'linuxppc-dev list',
'Paul Mackerras'
In-Reply-To: <bb0f53dbee5c7240daf6855454eca028@kernel.crashing.org>
> You could give Freevec a whole lot more exposure, to people
> who might be more interested in it than the average glibc
> user, by putting it into uClibc first.
[snip]
> You'll have to update uClibc's PowerPC port first though
> (mostly just copying stuff from recent glibc) -- it seems the
> libc AltiVec support (for handling setjmp() etc.) isn't in there yet.
I remember a discussion from one of the Gentoo guys wanting to do this
with libfreevec.
Getting into Gentoo, though, is not difficult. The problem with this
is Gentoo is one Linux distribution. I would be more impressed if code
was in Debian or Ubuntu considering their exhausting lead times on
producing new package trees and accepting new code :D
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
^ permalink raw reply
* RE: AltiVec in the kernel
From: Benjamin Herrenschmidt @ 2006-07-23 21:37 UTC (permalink / raw)
To: matt
Cc: 'Olof Johansson', 'linuxppc-dev list',
'Paul Mackerras'
In-Reply-To: <006701c6ae5b$d5e83620$7302a8c0@bakuhatsu.net>
> I remember a discussion from one of the Gentoo guys wanting to do this
> with libfreevec.
>
> Getting into Gentoo, though, is not difficult. The problem with this
> is Gentoo is one Linux distribution. I would be more impressed if code
> was in Debian or Ubuntu considering their exhausting lead times on
> producing new package trees and accepting new code :D
It seems to me that the "problem" just doesn't exist at the moment...
libfreevec is nice, but it's unfinished, and the author is away for now
and thus not able to complete nor work on a port to glibc or others.
Once he's back, of course, it would be nice to have him complete the
work (and maybe get some outside help).
I'd like to also verify his methodology for measuring the performance
improvements, I'm not saying it's wrong, I want to make sure some of the
overhead of enabling altivec has been properly measured for various
usage patterns and thus possibly restrict the optimisations to patterns
where that matter, as an example, only use altivec for large memcpy's.
Once that's done, I don't see any good reason why it would be so hard to
include that work into glibc, or rather into the powerpc add-ons in a
first step and maybe then the whole into glibc. Maintainers rarely
rejects things just for the sake of doing so. If they do so, they
usually provide reasons, often boiling to implementation details, than
can then be fixed. Note also that in the case of submitting code to
glibc, there is a copyright assignment issue to be sorted out I think (I
don't know the details here).
I have the feeling that there is very little point to this thread. Let's
wait for Konstantinos to be back and submit his work, possibly to this
list at first for review, tests, etc... and then to the appropriate
maintainers. If there is a problem at that point, then we'll see how we
can address it.
Regards,
Ben.
^ permalink raw reply
* RE: [PATCH] powerpc: Add tsi108/9 and new hardware interface to mpic
From: Zang Roy-r61911 @ 2006-07-24 3:16 UTC (permalink / raw)
To: Zang Roy-r61911, Paul Mackerras, Benjamin Herrenschmidt
Cc: linuxppc-dev list, Alexandre.Bounine, Yang Xin-Xin-r48390
In-Reply-To: <7EA18FDD2DC2154AA3BD6D2F22A62A0E0456D0@zch01exm23.fsl.freescale.net>
>=20
> The patch add new hardware information table for mpic. This=20
> enables mpic
> code=20
> to deal with OpenPIC controller with hardware behavior difference.
> Add TSI108/109 PIC hardware information table. The=20
> Tsi108/109 PIC looks
> like=20
> standard OpenPIC but, in fact, is different in registers mapping and
> behavior.
> =20
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>=20
>=20
> ---
Ben,
How do you think the new hardware information entry for mpic?
Thanks.
Roy
^ permalink raw reply
* Why the "opd" section?
From: Jonathan Bartlett @ 2006-07-24 4:01 UTC (permalink / raw)
To: linuxppc-dev
I'm learning PPC64 assembly language, and I found the existence of the
"opd" sections containing function descriptors quite odd. What is the use
of these? Are they used by the linker? Why are they needed in the 64-bit
ELF platforms and not the 32-bit ones?
Thanks,
Jon
^ permalink raw reply
* [PATCH] use gcc -O1 in fs/reiserfs only for ancient gcc versions
From: Olaf Hering @ 2006-07-24 6:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, reiserfs-dev
In-Reply-To: <20051011190133.GA31348@suse.de>
only compile with -O1 if the (very old) compiler is broken.
We use reiserfs alot since SLES9 on ppc64, and it was never seen
with gcc33.
Assume the broken gcc is gcc-3.4 or older.
Signed-off-by: Olaf Hering <olh@suse.de>
---
fs/reiserfs/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.18-rc2/fs/reiserfs/Makefile
===================================================================
--- linux-2.6.18-rc2.orig/fs/reiserfs/Makefile
+++ linux-2.6.18-rc2/fs/reiserfs/Makefile
@@ -28,7 +28,7 @@ endif
# will work around it. If any other architecture displays this behavior,
# add it here.
ifeq ($(CONFIG_PPC32),y)
-EXTRA_CFLAGS := -O1
+EXTRA_CFLAGS := $(call cc-ifversion, -lt, 0400, -O1)
endif
TAGS:
^ permalink raw reply
* [PATCH] enable mac partition label per default on pmac
From: Olaf Hering @ 2006-07-24 7:00 UTC (permalink / raw)
To: Andrew Morton, linuxppc-dev
Enable mac partition table support per default also for a powermac config.
Signed-off-by: Olaf Hering <olh@suse.de>
---
fs/partitions/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.18-rc2/fs/partitions/Kconfig
===================================================================
--- linux-2.6.18-rc2.orig/fs/partitions/Kconfig
+++ linux-2.6.18-rc2/fs/partitions/Kconfig
@@ -99,7 +99,7 @@ config IBM_PARTITION
config MAC_PARTITION
bool "Macintosh partition map support" if PARTITION_ADVANCED
- default y if MAC
+ default y if (MAC || PPC_PMAC)
help
Say Y here if you would like to use hard disks under Linux which
were partitioned on a Macintosh.
^ permalink raw reply
* Re: linux kernel hang in execve("/sbin/init")
From: Stephen Telfer @ 2006-07-24 6:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAY117-F38602DE22BC1EB7A1E1660C8670@phx.gbl>
Hi Eric -
Sometimes a hang at this point can be down to a mismatch between
toolchain, C library and kernel about whether floating point is
implemented, emulated or absent. Early in one of the shared libraries
there are a string of saves of FP registers, and if your CPU has no FPU
and your kernel has no FPU emulation this will be terminal (and
silently so). A printk statement in the illegal instruction trap
handler would confirm this hypothesis.
Hope this helps,
Stig
On 22 Jul 2006, at 07:10, Eric Nuckols wrote:
> I googled...and googled...etc. etc.. when trying to solve the problem
> of my
> linux kernel seemingly locking or hanging when it gets to the last
> part of
> the linux init in main.c
>
> I saw lots of information and suggestions related to try /bin/sh or
> make
> sure your initrd is ok or make sure you have more than one
> session..etc.
> etc... .. and all of these topics were mostly from 2001-2003...well..
> 2006...it's here and apparently some of us haven't gotten smarter..
>
> I had this problem recently where my kernel would boot and freeze or
> hang in
> execve of /sbin/init and also of /bin/sh or /bin/bash...
>
> I debugged and debugged.. and finally thougt... why not try the default
> Kernel config for my target, the PrPmc800 from Motorola... and see
> what that
> does.. Originally, I started with the MontaVista 3.1 Pro setup for
> the
> board and it works...so I used it's Kernel .config file to configure my
> latest and greatest (at the time) 2.6.16.18 kernel thinking... well..
> this
> has to work..
>
> so.. I ended up with a kernel that semingly hang/froze/locked on the
> execve
> call in the linux init routines...
>
> guess what folks... the google searches left me just on the verge of
> giving
> up.
>
> I am here to post this info as somewhat of another answer/alternative
> to
> people in the same predicament...
>
> if you are having problems with your cross-compiled / embedded ppc
> kernel
> freezing or hanging on execve, try using the default configuration for
> your
> target when you build the kernel...
>
> in my case, I did this sort of thing and all of a sudden, my kernel was
> working:
>
> cd to kernel dir
> make distclean
> make CROSS_COMPILE=powerpc-7400-linux-gnu- prpmc800_defconfig
> make zImage.initrd
>
> etc..etc..
>
> it turns out that since I was basing my initial config off of the 2.4.x
> .config from MontaVista, my kernel didn't boot as desired...
>
> so I figured.. after all the googling and working on it that the
> default
> PrPmc800 config had to boot... why else call it the default config..
>
> so that's my story.. since then, I have copied the kernel
> dir/arch/ppc/configs/prpmc800_defconfig to a temporary file, and
> modified it
> as necessary...
>
> moral of the story... if you are cross-compiling and having problems
> where
> you hang on execve("/sbin/init") or execve("/bin/sh") or
> execve("/bin/bash")..etc... try what I did before you go crazy
> analyzing
> the initrd or the various /etc/ file configurations or any of the other
> typical bs...
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] hide onboard graphics drivers on G5
From: Olaf Hering @ 2006-07-24 7:22 UTC (permalink / raw)
To: Andrew Morton, linuxppc-dev
Hide the video drivers for onboard graphics found in early PCI PowerMacs
in Apple G5 config files.
drivers/built-in.o: In function `.platinumfb_probe':
platinumfb.c:(.text+0x377a0): undefined reference to `.nvram_read_byte'
platinumfb.c:(.text+0x37830): undefined reference to `.nvram_read_byte'
drivers/built-in.o: In function `.control_init':
controlfb.c:(.init.text+0x1938): undefined reference to `.nvram_read_byte'
controlfb.c:(.init.text+0x1968): undefined reference to `.nvram_read_byte'
drivers/built-in.o: In function `.valkyriefb_init':
(.init.text+0x2300): undefined reference to `.nvram_read_byte'
drivers/built-in.o:(.init.text+0x239c): more undefined references to `.nvram_read_byte' follow
Signed-off-by: Olaf Hering <olh@suse.de>
---
drivers/video/Kconfig | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6.18-rc2/drivers/video/Kconfig
===================================================================
--- linux-2.6.18-rc2.orig/drivers/video/Kconfig
+++ linux-2.6.18-rc2/drivers/video/Kconfig
@@ -420,7 +420,7 @@ config FB_OF
config FB_CONTROL
bool "Apple \"control\" display support"
- depends on (FB = y) && PPC_PMAC
+ depends on (FB = y) && PPC_PMAC && PPC32
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -431,7 +431,7 @@ config FB_CONTROL
config FB_PLATINUM
bool "Apple \"platinum\" display support"
- depends on (FB = y) && PPC_PMAC
+ depends on (FB = y) && PPC_PMAC && PPC32
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -442,7 +442,7 @@ config FB_PLATINUM
config FB_VALKYRIE
bool "Apple \"valkyrie\" display support"
- depends on (FB = y) && (MAC || PPC_PMAC)
+ depends on (FB = y) && (MAC || (PPC_PMAC && PPC32))
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -453,7 +453,7 @@ config FB_VALKYRIE
config FB_CT65550
bool "Chips 65550 display support"
- depends on (FB = y) && PPC
+ depends on (FB = y) && PPC32
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
^ permalink raw reply
* Re: mpic discovery on JS20
From: Michael Ellerman @ 2006-07-24 7:41 UTC (permalink / raw)
To: Amos Waterland; +Cc: linuxppc-dev
In-Reply-To: <20060720231601.GA24736@kvasir.watson.ibm.com>
[-- Attachment #1.1: Type: text/plain, Size: 716 bytes --]
On Thu, 2006-07-20 at 19:16 -0400, Amos Waterland wrote:
> Current Linus and Paulus trees do this on JS20 blades with SLOF:
>
> Failed to locate the MPIC interrupt controller
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> Maple: Found RTC at IO 0x1070
> cpu 0x0: Vector: 700 (Program Check) at [c00000007ef83ab0]
> pc: c00000000002e0c8: .mpic_request_ipis+0x34/0xc8
> lr: c00000000036b484: .smp_mpic_probe+0x3c/0x58
> sp: c00000007ef83d30
> msr: 9000000000029032
> current = 0xc00000000194d610
> paca = 0xc00000000038f180
> pid = 1, comm = swapper
> kernel BUG in mpic_request_ipis at arch/powerpc/sysdev/mpic.c:1132!
Does this help?
cheers
[-- Attachment #1.2: mpic-fixup.patch --]
[-- Type: text/x-patch, Size: 1132 bytes --]
Index: to-merge/arch/powerpc/platforms/maple/setup.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/maple/setup.c
+++ to-merge/arch/powerpc/platforms/maple/setup.c
@@ -216,6 +216,7 @@ static void __init maple_init_IRQ(void)
int naddr, n, i, opplen, has_isus = 0;
struct mpic *mpic;
unsigned int flags = MPIC_PRIMARY;
+ char *typep;
/* Locate MPIC in the device-tree. Note that there is a bug
* in Maple device-tree where the type of the controller is
@@ -226,9 +227,19 @@ static void __init maple_init_IRQ(void)
break;
}
if (mpic_node == NULL) {
- printk(KERN_ERR
- "Failed to locate the MPIC interrupt controller\n");
- return;
+ for_each_node_by_type(np, "interrupt-controller") {
+ typep = (char *)get_property(np, "compatible", NULL);
+ if (strstr(typep, "open-pic")) {
+ mpic_node = np;
+ break;
+ }
+ }
+
+ if (mpic_node == NULL) {
+ printk(KERN_ERR "Failed to locate the MPIC interrupt "
+ "controller\n");
+ return;
+ }
}
/* Find address list in /platform-open-pic */
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 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