* [PATCH] Never panic when taking altivec exceptions from userspace
From: Anton Blanchard @ 2006-10-13 1:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
At the moment we rely on a cpu feature bit or a firmware property to
detect altivec. If we dont have either of these and the cpu does in fact
support altivec we can cause a panic from userspace.
It seems safer to always send a signal if we manage to get an 0xf20
exception from userspace.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index d9f10f2..5ed4c2c 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -900,14 +900,13 @@ void kernel_fp_unavailable_exception(str
void altivec_unavailable_exception(struct pt_regs *regs)
{
-#if !defined(CONFIG_ALTIVEC)
if (user_mode(regs)) {
/* A user program has executed an altivec instruction,
but this kernel doesn't support altivec. */
_exception(SIGILL, regs, ILL_ILLOPC, regs->nip);
return;
}
-#endif
+
printk(KERN_EMERG "Unrecoverable VMX/Altivec Unavailable Exception "
"%lx at %lx\n", regs->trap, regs->nip);
die("Unrecoverable VMX/Altivec Unavailable Exception", regs, SIGABRT);
^ permalink raw reply related
* RE: plb_temac, ML403, linux 2.4.26, EDK 7.1
From: Pradeep Sampath @ 2006-10-13 0:18 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F29333102EBA79FA70A2873B2140@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]
Guys,
I need your help on this, i am stuck for over a week now. I am currently using
ML403 Virtex-4 FX12 board, linux kernel 2.6.17.1, EDK 8.1.2i, and Ameet's sysace and TEMAC driver patch. With your help I was able to get the Kernel to boot on the ML403 board. But kernel crashes at xsysace_init function call.
[ 3.995416] Call Trace:
[ 4.024581] [C04A1D20] [FFFFFFFF] 0xffffffff (unreliable)
[ 4.089156] [C04A1D40] [C021D358] xsysace_init+0x50/0x330
[ 4.153726] [C04A1F90] [C0002448] init+0xa4/0x27c
[ 4.209968] [C04A1FF0] [C000509C] kernel_thread+0x44/0x60
Since I am using 8.1.2i to generate the BSP, i suspect that the xparamater_ml300.h file the EDK generates for the ML403 board is not compatible with the sysace driver patch. I suspect that if i include a xparameters_ml300.h file that was generated using EDK 7.1 it would run.
Ming, would it be possible for you to send me a xparameters.h file using EDK 7.1 (or the version you are using) with very basic IP cores that will work with the sysace and TEMAC drivers. Thanks in advance.
I need to get the sysace driver and TEMAC driver's up and running for the project. Any suggestions will be very helpful...
-Pradeep
[-- Attachment #2: Type: text/html, Size: 1480 bytes --]
^ permalink raw reply
* RE: plb_temac, ML403, linux 2.4.26, EDK 7.1
From: Pradeep Sampath @ 2006-10-13 0:18 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F29333102EBA79FA70A2873B2140@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]
Guys,
I need your help on this, i am stuck for over a week now. I am currently using
ML403 Virtex-4 FX12 board, linux kernel 2.6.17.1, EDK 8.1.2i, and Ameet's sysace and TEMAC driver patch. With your help I was able to get the Kernel to boot on the ML403 board. But kernel crashes at xsysace_init function call.
[ 3.995416] Call Trace:
[ 4.024581] [C04A1D20] [FFFFFFFF] 0xffffffff (unreliable)
[ 4.089156] [C04A1D40] [C021D358] xsysace_init+0x50/0x330
[ 4.153726] [C04A1F90] [C0002448] init+0xa4/0x27c
[ 4.209968] [C04A1FF0] [C000509C] kernel_thread+0x44/0x60
Since I am using 8.1.2i to generate the BSP, i suspect that the xparamater_ml300.h file the EDK generates for the ML403 board is not compatible with the sysace driver patch. I suspect that if i include a xparameters_ml300.h file that was generated using EDK 7.1 it would run.
Ming, would it be possible for you to send me a xparameters.h file using EDK 7.1 (or the version you are using) with very basic IP cores that will work with the sysace and TEMAC drivers. Thanks in advance.
I need to get the sysace driver and TEMAC driver's up and running for the project. Any suggestions will be very helpful...
-Pradeep
[-- Attachment #2: Type: text/html, Size: 1480 bytes --]
^ permalink raw reply
* Re: Recently removed io accessors
From: Benjamin Herrenschmidt @ 2006-10-13 0:04 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: sfr, linuxppc-dev
In-Reply-To: <873b9twnbb.fsf@sleipner.barco.com>
On Thu, 2006-10-12 at 17:44 +0200, Peter Korsgaard wrote:
> Hi,
>
> Commit 661f1cdb8b3e3c2c44e97df122c1d5643c054ce8 ([POWERPC] remove
> unused asm routines) removed the _insl / _outsl routines for 32bit
> copies with byteswap.
>
> I've been working on adding ppc support to drivers/net/smc911x.c, and
> I was unfortunately using those routines (The ethernet controller can
> be configured for big endian mode, but the contents of the internal
> packet buffers is still little endian, so you need to byteswap in the
> tx/rx routines).
>
> Any chance of getting them back or should I implement a (slower) loop
> myself before submitting the patch?
Well, a "packet buffer" should have no endian. When streaming in our out
a fifo, you basically stream bytes that happen to come out 2 at a time.
So unless somebody wired the hardware backward, you should do no
swapping when using the fifo.
Ben.
^ permalink raw reply
* [PATCH] Fix IO Window Updates on P2P bridges.
From: Randy Vinson @ 2006-10-12 20:36 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 238 bytes --]
Greetings,
When update_bridge_base() updates the IO window on a PCI-to-PCI bridge, it fails to zero the upper 16 bits of the base and limit registers if the window size is less than 64K. The attached patch corrects this.
Randy Vinson
[-- Attachment #2: pci_update_IO.patch --]
[-- Type: text/plain, Size: 1594 bytes --]
Fix IO Window Updates on P2P bridges.
When updating the I/O window of a PCI-to-PCI bridge, update_bridge_base()
fails to zero the upper 16 bits of the IO base and limit registers if the
new I/O window is under 64k in size.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
---
commit 46be7a52bb42e3323644f4d15bd1e93f14632a60
tree 3e5b1c12c04255d59647f6660cd6b0e3f39d1cc5
parent 10270613fb4d5a44c335cfa13e9626bf5743c01d
author Randy Vinson <rvinson@linuxbox.(none)> Thu, 12 Oct 2006 13:25:46 -0700
committer Randy Vinson <rvinson@linuxbox.(none)> Thu, 12 Oct 2006 13:25:46 -0700
arch/powerpc/kernel/pci_32.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 9b49f86..0d9ff72 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -441,14 +441,14 @@ update_bridge_base(struct pci_bus *bus,
end = res->end - off;
io_base_lo = (start >> 8) & PCI_IO_RANGE_MASK;
io_limit_lo = (end >> 8) & PCI_IO_RANGE_MASK;
- if (end > 0xffff) {
- pci_write_config_word(dev, PCI_IO_BASE_UPPER16,
- start >> 16);
- pci_write_config_word(dev, PCI_IO_LIMIT_UPPER16,
- end >> 16);
+ if (end > 0xffff)
io_base_lo |= PCI_IO_RANGE_TYPE_32;
- } else
+ else
io_base_lo |= PCI_IO_RANGE_TYPE_16;
+ pci_write_config_word(dev, PCI_IO_BASE_UPPER16,
+ start >> 16);
+ pci_write_config_word(dev, PCI_IO_LIMIT_UPPER16,
+ end >> 16);
pci_write_config_byte(dev, PCI_IO_BASE, io_base_lo);
pci_write_config_byte(dev, PCI_IO_LIMIT, io_limit_lo);
^ permalink raw reply related
* Re: [PATCH] Xilinx UART Lite 2.6.18 driver
From: David Bolcsfoldi @ 2006-10-12 21:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <87ac41esap.fsf@sleipner.barco.com>
No I did not know that unfortunately, it could have saved me some work.
You are of course right and I'd much prefer to make changes to your driver
instead of writing another one.
I've noticed that in the probe function it tries to get some resources
from the platform_device structure but it looks like that this
operation will always fail unless I add a 'uartlite' platform device
or have I completely misunderstood how platform devices work?
But yes, I will try to add support for the things I need to this
driver instead, most importantly early console support and move the
#defines for register offsets and such into a separate header file per
Grants comment.
Cheers,
David
On 10/12/06, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> >>>>> "David" == David Bolcsfoldi <dbolcsfoldi@gmail.com> writes:
>
> Hi David,
>
> David> here's a set of patches that adds support for Xilinx UART lite
> David> devices. It has been tested on an ML403-FX using xapp902
> David> (ml403_ppc_plb_temac) using a 2.6.18 kernel and a BusyBox
> David> userspace.
>
> I guess you didn't know, but there already exists a uartlite driver!
> It unfortunately didn't made it into 2.6.19-rc1 because Russell
> stopped maintaining serial stuff, but it's in -mm.
>
> It also has an official lanana.org assigned set of device nodes.
>
> I didn't look at your patch yet, but I think it would be more useful
> to add any features missing to my driver than writing yet another
> driver (I think we're up to 3 now).
>
> --
> Bye, Peter Korsgaard
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Handling machine check exception
From: Segher Boessenkool @ 2006-10-12 20:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ganesh subramonian, linuxppc-dev
In-Reply-To: <1160664666.4792.151.camel@localhost.localdomain>
>> The G2 core definitely has a DAR register (SPR 19).
>>
>> Look on the Freescale site for G2CORERM.pdf - this is
>> your reference manual, not the one specifically for the
>> 8247.
>
> Is DAR set for a machine check ?
Not on these old cores.
Segher
^ permalink raw reply
* Re: lite5200B boot up error with PCI card
From: Wolfgang Denk @ 2006-10-12 18:33 UTC (permalink / raw)
To: prashanth epuru; +Cc: linuxppc-embedded
In-Reply-To: <20061012135311.HM.0000000000000BP@epuru.bos-mail-wwl4.lycos.com>
In message <20061012135311.HM.0000000000000BP@epuru.bos-mail-wwl4.lycos.com> you wrote:
>
> >I am trying to boot up lite5200B version 1.0 freescale board with u boot and it boots up properly without any PCI card.
> The lite5200B crashes while bootup if a PCI card (PCI to mini PCI converter card of Catalyst Enterprises) is inserted.
...
> U-Boot 1.1.3 (Aug 10 2005 - 11:07:57)
No big surprise. Support for the Lite500B was added much later. You
should update U-Boot to the latest version (= top of tree in git
repository).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Life sucks, but it's better than the alternative."
- Peter da Silva
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 2/2] Add support for dumping spu info from xmon
From: Geoff Levand @ 2006-10-12 17:42 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <20061012120312.10FDD67BE5@ozlabs.org>
Michael Ellerman wrote:
> This patch adds a command to xmon for dumping information about
> spu structs. The command is 'sf' for "spu fields" perhaps, and
> takes the spu number as an argument. This is the same value as the
> spu->number field, or the "phys-id" value of a context when it is
> bound to a physical spu.
> +static void dump_spu_fields(struct spu *spu)
> +{
...
> + DUMP_FIELD(spu, "0x%x", problem->spu_npc_RW);
> + DUMP_FIELD(spu, "0x%p", priv1);
> +
> + if (spu->priv1)
> + DUMP_FIELD(spu, "0x%lx", priv1->mfc_sr1_RW);
> +
> + DUMP_FIELD(spu, "0x%p", priv2);
Just to let you know, I've been doing some work to abstract the platform
specific parts out of the spu support to better support running on a
hypervisor. It shouldn't make much difference, but maybe I'll try to set
something up like this for you:
DUMP_FIELD(spu, "0x%x", problem->spu_npc_RW);
DUMP_FIELD(spu, "0x%p", priv2);
spu_dump_platform_fields(spu);
-Geoff
^ permalink raw reply
* lite5200B boot up error with PCI card
From: prashanth epuru @ 2006-10-12 17:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 2335 bytes --]
^ permalink raw reply
* Re: Problems with DMA from user space on MPC834x (Cache coherency?)
From: Manish Joshi @ 2006-10-12 17:32 UTC (permalink / raw)
To: Lauri Ehrenpreis, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3216 bytes --]
Yeah it looks like a cache coherency problem from the first look.
You may try enabling snooping on the DMA channel if MPC824X supports it. Check in Mode register setting.
Else you may want to use flush_dcache_range(start, last) functions and see if it helps.
----- Original Message ----
From: Lauri Ehrenpreis <lauri.ehrenpreis@liewenthal.ee>
To: linuxppc-embedded@ozlabs.org
Sent: Wednesday, October 11, 2006 7:20:03 AM
Subject: Problems with DMA from user space on MPC834x (Cache coherency?)
Hi!
I have a problem with DMA from user space on a platform powered by MPC834x
processor (which has powerpc e300 core inside). Our linux kernel version is
2.6.17.
My user space program does something like this:
file_fd = open("/disk/file", O_RDONLY);
result = read(file_fd, page_aligned_buf, len);
call_driver_ioctl_which_performs_dma();
while /disk is mounted to a partition residing on USB memory stick or SD
card.
page_aligned_buf starts from page boundary and contains enough full pages
for
the data (so I can allways map full page with dma_map_page in kernel).
The buffer address and data length will then be passed to a driver, which
calls
get_user_pages, then maps each page with dma_map_page and tells a PCI
device
to start reading from that page:
...
down_read(¤t->mm->mmap_sem);
result = get_user_pages(current, current->mm, page_aligned_buf, nr_pages,
0, 0, pages, NULL);
up_read(¤t->mm->mmap_sem);
for (i = 0; i < nr_pages; i++) {
find_data_checksum(pages[i]);
dma_addr = dma_map_page(&fpga.pci_dev->dev, pages[i], 0, PAGE_SIZE,
DMA_TO_DEVICE);
start_dma();
wait_until_dma_ready();
dma_unmap_page(&fpga.pci_dev->dev, dma_addr, dma_len, DMA_TO_DEVICE);
if(!checksum_ok_in_fpga())
print_page_data();
}
for (i = 0; i < nr_pages; i++)
page_cache_release(pages[i]);
The problem is that sometimes the PCI device receives wrong bytes at random
locations. I find the data checksum inside the driver and inside the FPGA.
Inside the driver I use kmap(page) and kunmap(page) to access data on the
user page. Sometimes the checksums do not match and I can see with the FPGA
debugging tool, that the FPGA receives different data than the driver is
printing out.
I have noticed 3 things regarding this error:
1) When I copy the data I read from the block device to another buffer in
userspace and pass this new buffer to the driver, then this error will
never occur:
file_fd = open("/disk/file", O_RDONLY);
result = read(file_fd, page_aligned_buf, len);
memcpy(new_page_aligned_buf, page_aligned_buf, len);
call_driver_ioctl_which_performs_dma(new_page_aligned_buf, len);
2) this error does not occur when I use copy_from_user instead of
get_user_pages
and dma_map_page inside driver.
3) this error does not occur on our previuos device, which has x86
platform.
I am currently out of ideas what to do next.. It seems to me like a cache
coherency problem. Can anyone suggest what might be wrong?
--
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 4713 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Add support for stopping spus from xmon
From: Linas Vepstas @ 2006-10-12 16:18 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <20061012120310.6B5A967BD5@ozlabs.org>
On Thu, Oct 12, 2006 at 10:03:08PM +1000, Michael Ellerman wrote:
>
> arch/powerpc/platforms/cell/spu_base.c | 4
> arch/powerpc/xmon/xmon.c | 142 ++++++++++++++++++++++++++++++++-
> include/asm-powerpc/xmon.h | 2
> 3 files changed, 146 insertions(+), 2 deletions(-)
The next patch adds another 60 lines to xmon.c, which
is already a bit too big. Perhaps you could instead
put this code in "xmon/cell.c" or something like that?
--linas
^ permalink raw reply
* RE: plb_temac, ML403, linux 2.4.26, EDK 7.1
From: Rick Moleres @ 2006-10-12 15:55 UTC (permalink / raw)
To: Robert Corley; +Cc: linuxppc-embedded
Robert,
(I copied the list)
Linux 2.4 support for plb_temac was not added until EDK 8.1.1. This
driver is not available in the MV Linux 2.4 tree. So if you want
something (the driver) to show up in libsrc/linux_mvl31_v1_01_b/linux
then you would need to upgrade.
Note also that checksum offload was added to the plb_temac core in EDK
8.1.2 (v3.00a of the core), so using that EDK or later will provide much
better GigE throughput (I think we measured somewhere around 650Mbps TCP
traffic using netperf on Linux 2.4 with checksum offload).
In Linux 2.4 we place the plb_temac driver in drivers/net/xilinx_gige
during the BSP generation process of EDK 8.1.1 or later in order to take
advantage of the jumbo frame config option. I looked at
source.mvista.com and this directory does appear in the Linux 2.4
repository (rsync://source.mvista.com/linuxppc-2.4).
Hope that helps,
Rick
-----Original Message-----
From: Robert Corley [mailto:rcorley@aegis-inc.net]=20
Sent: Wednesday, October 11, 2006 10:16 AM
To: Rick Moleres
Subject: Fw: plb_temac, ML403, linux 2.4.26, EDK 7.1
Rick,
Apologies for some potentially confusing parts of my last email to you.
Here is what I just posted if you care to reply.
----- Forwarded Message ----
From: robert corley <rdcorle@yahoo.com>
To: linuxppc-embedded@ozlabs.org
Sent: Wednesday, October 11, 2006 12:14:51 PM
Subject: plb_temac, ML403, linux 2.4.26, EDK 7.1
Some background:
ML403 devel board
EDK 7.1
compilation of reference design xapp902, modified to use linux and
without loopback
use of linux_2_4_devel obtained from montavista via rsync
I am trying to use the plb_temac rather than the ll_temac. In the long
run, I'd prefer to stick with linux 2.4. In addition, I will need to
get both embedded EMAC's up and running, but first I just wanna get the
xapp902 working. Also, I will need gigE support.
So, right now I am trying to get the plb_temac to compile and get errors
about the defines XPAR_XTEMAC_* within the linux directories
../drivers/net/xilinx_enet. I see that the edk gets the defines within
the xparameters.h file of the xapp902 project. I also see that my
C:\EDK\sw\ThirdParty\bsp\linux_mvl31_v1_01_a\drivers don't have anything
for a plb_temac.
Q: Is my error related to an incorrect setup of the linux or with the
EDK?
Q: t is stated that the plb_temac drivers are in EDK 8.1. Can I
stick
with 7.1 or must I ugprade?
Q: Where in the linux tree should I look for the xtemac
stuff? Is this what the EDK pushes on to the tree or is it released
within the MVL distro?
Q Based on posts by David and Ming, it
appears that I must use xilinx_gige to get up to gigE speeds. Will the
plb_temac support this data rate and, if so, is this a transparent
support or do I need to go the route suggested to Ming and
overwrite files in xilinx_enet?
R. Corley
^ permalink raw reply
* plb_temac, EDK 8.1 et al
From: robert corley @ 2006-10-12 16:15 UTC (permalink / raw)
To: Rick Moleres; +Cc: linuxppc-embedded
Rick;=0A=0AThanks so much for the reply.=0A=0AAs I understand your email=0A=
=0AEDK 7.1 vs. EDK 8.1=0A gets the *best* plb_temac I need to upgrade th=
e EDK,=0A I can stick with 7.1 if I am satisfied with the lower performa=
nce,=0A MVL drivers in source tree of EDK (sw/Thirdparty...)=0A=0Alinux =
2.4 vs. linux 2.6=0A plb_temac drivers already done=0A plb_temac avai=
lable in 2.4 via use of xilinx_gige directory=0A=0A-cy=0A
^ permalink raw reply
* Re: Xilinx I2C driver for linux 2.6?
From: Peter Korsgaard @ 2006-10-12 15:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <452E612D.1070301@ovro.caltech.edu>
>>>>> "DH" == David Hawkins <dwh@ovro.caltech.edu> writes:
Hi,
DH> Peter, whats the name of the driver in mainline? (Denx git or
DH> kernel.org?)
Kernel.org - drivers/i2c/busses/i2c-ocores.c
Also take a look at Documentation/i2c/busses/i2c-ocores.
DH> I want to use the opencore IP in a memory mapped FPGA (Altera
DH> though), so would like to take a look at your driver.
You're welcome. It should be pretty easy to get going (just provide a
platform device with addr/irq).
--
Bye, Peter Korsgaard
^ permalink raw reply
* Recently removed io accessors
From: Peter Korsgaard @ 2006-10-12 15:44 UTC (permalink / raw)
To: sfr; +Cc: linuxppc-dev
Hi,
Commit 661f1cdb8b3e3c2c44e97df122c1d5643c054ce8 ([POWERPC] remove
unused asm routines) removed the _insl / _outsl routines for 32bit
copies with byteswap.
I've been working on adding ppc support to drivers/net/smc911x.c, and
I was unfortunately using those routines (The ethernet controller can
be configured for big endian mode, but the contents of the internal
packet buffers is still little endian, so you need to byteswap in the
tx/rx routines).
Any chance of getting them back or should I implement a (slower) loop
myself before submitting the patch?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: Xilinx I2C driver for linux 2.6?
From: David Hawkins @ 2006-10-12 15:37 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded
In-Reply-To: <877iz5wo8q.fsf@sleipner.barco.com>
> Not afaik. We're using the OpenCores I2C controller instead which I in
> the mean time have written a driver for (in mainline). The IP core is
> afaik even smaller than the Xilinx controller.
>
Peter, whats the name of the driver in mainline?
(Denx git or kernel.org?)
I want to use the opencore IP in a memory mapped
FPGA (Altera though), so would like to take a look
at your driver.
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: consolidate feature fixup code
From: Benjamin Herrenschmidt @ 2006-10-12 15:24 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list
In-Reply-To: <20061012095649.23bb6b35@localhost.localdomain>
> It will also be easier to graft in a branch forward instead of a large
> amount of nops for large feature sections. I guess it will take some
> benchmarking to see what the breakeven point is.
Yeah, I've been thinking about that one for some time (in fact since I
did the first implementation of feature fixup). Thing is, back when it
was all asm, it was hard, and we never really had big feature sections.
Now that we have all that stuff with with PURR etc... in the exception
entry/return path, it might be worth having another look. I suspect that
the breakeven point will be very CPU dependant tho.
Ben.
^ permalink raw reply
* Re: Xilinx I2C driver for linux 2.6?
From: Peter Korsgaard @ 2006-10-12 15:24 UTC (permalink / raw)
To: linuxppc-embedded
>>>>> "JBM" == Jean-Baptiste Maneyrol <MANE@teamlog.com> writes:
Hi,
JBM> Does anyone know if there is somewhere an i2c driver for the
JBM> Xilinx IIC IP working on linux 2.6?
Not afaik. We're using the OpenCores I2C controller instead which I in
the mean time have written a driver for (in mainline). The IP core is
afaik even smaller than the Xilinx controller.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: consolidate feature fixup code
From: Olof Johansson @ 2006-10-12 14:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1160664449.4792.147.camel@localhost.localdomain>
On Fri, 13 Oct 2006 00:47:29 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > > +void do_feature_fixups(unsigned long offset, unsigned long value,
> > > + void *fixup_start, void *fixup_end)
> > > +{
> > > + struct fixup_entry {
> > > + unsigned long mask;
> > > + unsigned long value;
> > > + unsigned int *start;
> > > + unsigned int *end;
> > > + } *fcur, *fend;
> >
> > Shouldn't there be a better place to keep this struct definition than
> > in the function it's used? Some header file?
>
> It's not used anywhere else.... which header would you put it in ?
Near where the asm-corresponding ones are located (cputable.h).
-Olof
> > Ok, now it's in C, no reason to do a dcbst/icbi for every word. We did
> > it in asm for simplicity's sake. Split it in two loops, one to nop,
> > second to step per line and do the flushes. :-)
>
> Do we care ? :) But yah, I suppose I can do that.
Close call. :-) It's just easier to do now, might as well do it. But
yeah, no big deal.
It will also be easier to graft in a branch forward instead of a large
amount of nops for large feature sections. I guess it will take some
benchmarking to see what the breakeven point is.
-Olof
^ permalink raw reply
* Modules_install (depmod) prob
From: srideep.devireddy @ 2006-10-12 14:33 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2966 bytes --]
Hi ,
I am trying to compile mvista linux , I am able to run make dep ,
make zImage successfully after I do make modules and make
modules_install .
I am struck with below errors , I found that depmod which is x86 cant
execute it on the modules created for Arm . can any one give me any
suggestion to bypass this and make depmod as crosscompile or over come
this problem . I got few out by googling that we have to change few
CFLAGS or depmod.pl , if any one has used it please let me know .Thanks
in advance ..
Log
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{}
pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map
2.4.19-rmk7-ds3-mw1; fi
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr.o not for this
architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_atmdAcc.o not
for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_atmm.o not for
this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_atmsch.o not for
this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_atmDemo
.o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_cryptoA
cc.o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_demoUti
ls.o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_dmaAcc.
o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_ethAal5
App.o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_ethAcc.
o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_fpathAc
c.o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_hssAcc.
o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_oam.o
not for this architecture
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
[-- Attachment #2: Type: text/html, Size: 7399 bytes --]
^ permalink raw reply
* Re: Handling machine check exception
From: Benjamin Herrenschmidt @ 2006-10-12 14:51 UTC (permalink / raw)
To: Matt Sealey; +Cc: ganesh subramonian, linuxppc-dev
In-Reply-To: <452E1A1D.1050601@genesi-usa.com>
On Thu, 2006-10-12 at 12:34 +0200, Matt Sealey wrote:
> The G2 core definitely has a DAR register (SPR 19).
>
> Look on the Freescale site for G2CORERM.pdf - this is
> your reference manual, not the one specifically for the
> 8247.
Is DAR set for a machine check ?
Ben.
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: Cell timebase workaround
From: Benjamin Herrenschmidt @ 2006-10-12 14:48 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list
In-Reply-To: <20061012091455.6409046e@localhost.localdomain>
> The above is a bit obfuscated. Please make the MFTB() macro use the
> nested version of the feature definitions, and let the surrounding code
> use the base one. Otherwise it will be really easy to mix them up by
> mistake, there's no exposure at the time of MFTB() usage that it uses
> feature labels.
Yup, I was thinking about doing that at one point and it slipped out of
my mind. Thanks for reminding me :)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: consolidate feature fixup code
From: Benjamin Herrenschmidt @ 2006-10-12 14:47 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list
In-Reply-To: <20061012085617.3a5d6a31@localhost.localdomain>
> > +void do_feature_fixups(unsigned long offset, unsigned long value,
> > + void *fixup_start, void *fixup_end)
> > +{
> > + struct fixup_entry {
> > + unsigned long mask;
> > + unsigned long value;
> > + unsigned int *start;
> > + unsigned int *end;
> > + } *fcur, *fend;
>
> Shouldn't there be a better place to keep this struct definition than
> in the function it's used? Some header file?
It's not used anywhere else.... which header would you put it in ?
> > +
> > + fcur = fixup_start;
> > + fend = fixup_end;
> > +
> > + for (; fcur < fend; fcur++) {
>
> for (fcur = fixup_start; fcur < fend; fcur++) {
>
> > + unsigned int *pcur, *pend;
> > +
> > + if ((value & fcur->mask) == fcur->value)
> > + continue;
> > +
> > + pcur = fcur->start - offset;
> > + pend = fcur->end - offset;
> > + for (; pcur < pend; pcur++) {
> > + *pcur = 0x60000000u;
> > + asm ("dcbst 0, %0; sync; icbi 0,%0; sync; isync"
> > + : : "r" (pcur));
> > + }
>
> Ok, now it's in C, no reason to do a dcbst/icbi for every word. We did
> it in asm for simplicity's sake. Split it in two loops, one to nop,
> second to step per line and do the flushes. :-)
Do we care ? :) But yah, I suppose I can do that.
Thanks,
Ben.
^ permalink raw reply
* Xilinx I2C driver for linux 2.6?
From: Jean-Baptiste Maneyrol @ 2006-10-12 14:35 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody!
Does anyone know if there is somewhere an i2c driver for the Xilinx IIC IP
working on linux 2.6?
I'm using the ML405 board with EDK 8.2i, and their driver is for linux 2.4.
Thanks!
Jean-Baptiste Maneyrol
Teamlog - France
________________________________________________
Message sent using UebiMiau 2.7.9
^ 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