* Re: powerpc problem with .data.page_aligned -> __page_aligned_data conversion
From: Tim Abbott @ 2009-10-15 16:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Andrew Morton, Linus Torvalds, sam,
linux-kernel@vger.kernel.org
In-Reply-To: <1255584772.2347.86.camel@pasglop>
On Thu, 15 Oct 2009, Benjamin Herrenschmidt wrote:
> For some weird reason, our gcc until 4.3 (fixed in 4.3) had the weird
> idea that the alignment attribute should not be allowed to force an
> alignment greater than 32k. If attempted, it would warn -and- crop the
> alignment to 32k.
[...]
> This has a few issues for us:
>
> - The patch that converted bits of powerpc to the new macro break since
> it now hits that bug
Hi Ben,
Just to make sure I understand the nature of the problem, is the current
breakage that gcc < 4.3 will _warn_ on any compilation units on ppc64 that
use __page_aligned data, or something worse?
The cropping is clearly a potential problem, but I read the rest of your
email as saying that the cropping of the alignment isn't actually a
problem with the current kernel because the kernel is currently only using
the macro with things whose size is divisible by PAGE_SIZE. However, I am
not sure how to reconcile that with using the word "break" above...
-Tim Abbott
^ permalink raw reply
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Scott Wood @ 2009-10-15 16:27 UTC (permalink / raw)
To: Richard Cochran; +Cc: 'linuxppc-dev@lists.ozlabs.org'
In-Reply-To: <95DC1AA8EC908B48939B72CF375AA5E30E2AE72C@alice.at.omicron.at>
On Thu, Oct 15, 2009 at 02:19:30PM +0200, Richard Cochran wrote:
> >-----Original Message----- From: Scott Wood [mailto:scottwood@freescale.com]
> >Because that would be three times the device trees to maintain, and a
> >source of user confusion.
>
> I wonder which is more confusing for the user:
>
> 1. Choosing one of three dts files.
Possibly incorrectly.
> 2. Having only one dts for his board, but Ethernet doesn't work.
The point is to fix u-boot so that it *does* work with only one dts. If
people not upgrading u-boot is your concern, we could put the fixup in the
Linux platform code instead.
And feel free to ask through official Freescale support channels why the
U-Boot that shipped on these boards does not have such a fixup (or why they
decided it was better to make late-rev 8313's interrupt assignments match
other 83xx than for all revs of the same part number to have the same
interrupt assignments).
-Scott
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Scott Wood @ 2009-10-15 16:09 UTC (permalink / raw)
To: Christian Borntraeger
Cc: linuxppc-dev, brueckner, Timur Tabi, Alan Cox,
Linux Kernel Mailing List
In-Reply-To: <200910151305.47100.borntraeger@de.ibm.com>
On Thu, Oct 15, 2009 at 01:05:47PM +0200, Christian Borntraeger wrote:
> The fact that struct console->write returns void indicates that the console
> layer is not interested in errors. We have two policies we can implement:
>
> 1. drop console messages if case of congestion but keep the system going
> 2. dont drop messages and wait, even if the system might come to a complete stop
>
> Looking at drivers/char/vt.c
> /* console busy or not yet initialized */
> if (!printable)
> return;
> if (!spin_trylock(&printing_lock))
> return;
> could mean that Linux consoles should not block.
That's a bit different -- the code above is testing for potential deadlocks
within Linux (or a not-yet-initialized console), not a device that has yet
to process the last batch of characters we threw at it. Plus, given the
"console must be locked when we get here" comment, I'm not sure that you'll
ever see contention on printing_lock?
Serial consoles currently block when waiting for the buffer to drain:
static void serial8250_console_putchar(struct uart_port *port, int ch)
{
struct uart_8250_port *up = (struct uart_8250_port *)port;
wait_for_xmitr(up, UART_LSR_THRE);
serial_out(up, UART_TX, ch);
}
-Scott
^ permalink raw reply
* Re: [PATCH 5/5 v2] kernel handling of CPU DLPAR
From: Nathan Fontenot @ 2009-10-15 15:40 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1255473054.21871.39.camel@concordia>
Michael Ellerman wrote:
> On Tue, 2009-10-13 at 13:14 -0500, Nathan Fontenot wrote:
>> This adds the capability to DLPAR add and remove CPUs from the kernel. The
>> creates two new files /sys/devices/system/cpu/probe and
>> /sys/devices/system/cpu/release to handle the DLPAR addition and removal of
>> CPUs respectively.
>
> How does this relate to the existing cpu hotplug mechanism? Or is this
> making the cpu exist (possible), vs marking it as online?
This update makes the cpu exist, it does not mark the cpu online.
>
> Is some other platform going to want to do the same? ie. should the
> probe/release part be in generic code?
I thought about making this generic code, perhaps a follow-on patch to move
the creation of the probe/release files to generic code to see what the
community thinks. I would assume there would still need to be a arch and/or
platforms specific callout to do the real work.
>
>> Index: powerpc/arch/powerpc/platforms/pseries/dlpar.c
>> ===================================================================
>> --- powerpc.orig/arch/powerpc/platforms/pseries/dlpar.c 2009-10-13 13:08:22.000000000 -0500
>> +++ powerpc/arch/powerpc/platforms/pseries/dlpar.c 2009-10-13 13:09:00.000000000 -0500
>> @@ -1,11 +1,11 @@
>> /*
>> - * dlpar.c - support for dynamic reconfiguration (including PCI
>> - * Hotplug and Dynamic Logical Partitioning on RPA platforms).
>> + * dlpar.c - support for dynamic reconfiguration (including PCI,
>
> We know it's dlpar.c :)
heh! good point. Consider it gone.
>
>> + * Memory, and CPU Hotplug and Dynamic Logical Partitioning on
>> + * PAPR platforms).
>> *
>> * Copyright (C) 2009 Nathan Fontenot
>> * Copyright (C) 2009 IBM Corporation
>> *
>> - *
>> * This program is free software; you can redistribute it and/or
>> * modify it under the terms of the GNU General Public License version
>> * 2 as published by the Free Software Foundation.
>> @@ -19,6 +19,7 @@
>> #include <linux/memory_hotplug.h>
>> #include <linux/sysdev.h>
>> #include <linux/sysfs.h>
>> +#include <linux/cpu.h>
>>
>>
>> #include <asm/prom.h>
>> @@ -408,6 +409,82 @@
>> return 0;
>> }
>>
>> +#ifdef CONFIG_HOTPLUG_CPU
>> +static ssize_t cpu_probe_store(struct class *class, const char *buf,
>> + size_t count)
>> +{
>> + struct device_node *dn;
>> + unsigned long drc_index;
>> + char *cpu_name;
>> + int rc;
>> +
>> + rc = strict_strtoul(buf, 0, &drc_index);
>> + if (rc)
>> + return -EINVAL;
>> +
>> + rc = acquire_drc(drc_index);
>> + if (rc)
>> + return rc;
>> +
>> + dn = configure_connector(drc_index);
>> + if (!dn) {
>> + release_drc(drc_index);
>> + return rc;
>> + }
>> +
>> + /* fixup dn name */
>> + cpu_name = kzalloc(strlen(dn->full_name) + strlen("/cpus/") + 1,
>> + GFP_KERNEL);
>> + if (!cpu_name) {
>> + free_cc_nodes(dn);
>> + release_drc(drc_index);
>> + return -ENOMEM;
>> + }
>> +
>> + sprintf(cpu_name, "/cpus/%s", dn->full_name);
>> + kfree(dn->full_name);
>> + dn->full_name = cpu_name;
>
> What was all that? Firmware gives us a bogus full name? But the parent
> is right?
Yeah, this has always been an oddity to me. The name that is given to us
from firmware puts the cpu node in the root of the device tree as opposed
to /cpus. Since cpu nodes are in /cpus, the name is fixed up to reflect this.
This name fixup has always been done by the drmgr userspace command, which is
where this functionality is being imported from.
>
>> + rc = add_device_tree_nodes(dn);
>> + if (rc)
>> + release_drc(drc_index);
>> +
>> + return rc ? rc : count;
>
> You're sure rc is < 0.
>
Oh, good catch.
>> +}
>> +
>> +static ssize_t cpu_release_store(struct class *class, const char *buf,
>> + size_t count)
>> +{
>> + struct device_node *dn;
>> + u32 *drc_index;
>> + int rc;
>> +
>> + dn = of_find_node_by_path(buf);
>> + if (!dn)
>> + return -EINVAL;
>> +
>> + drc_index = (u32 *)of_get_property(dn, "ibm,my-drc-index", NULL);
>
> No cast required.
ok.
thanks for the review.
-Nathan
>
>> + if (!drc_index) {
>> + of_node_put(dn);
>> + return -EINVAL;
>> + }
>> +
>> + rc = release_drc(*drc_index);
>> + if (rc) {
>> + of_node_put(dn);
>> + return rc;
>> + }
>> +
>> + rc = remove_device_tree_nodes(dn);
>> + if (rc)
>> + acquire_drc(*drc_index);
>> +
>> + of_node_put(dn);
>> + return rc ? rc : count;
>> +}
>
>
> cheers
^ permalink raw reply
* Re: [PATCH 4/5 v3] kernel handling of memory DLPAR
From: Nathan Fontenot @ 2009-10-15 15:23 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1255473061.21871.40.camel@concordia>
Michael Ellerman wrote:
> On Tue, 2009-10-13 at 13:13 -0500, Nathan Fontenot wrote:
>> This adds the capability to DLPAR add and remove memory from the kernel. The
>
> Hi Nathan,
>
> Sorry to only get around to reviewing version 3, time is a commodity in
> short supply :)
>
>> Index: powerpc/arch/powerpc/platforms/pseries/dlpar.c
>> ===================================================================
>> --- powerpc.orig/arch/powerpc/platforms/pseries/dlpar.c 2009-10-08 11:08:42.000000000 -0500
>> +++ powerpc/arch/powerpc/platforms/pseries/dlpar.c 2009-10-13 13:08:22.000000000 -0500
>> @@ -16,6 +16,10 @@
>> #include <linux/notifier.h>
>> #include <linux/proc_fs.h>
>> #include <linux/spinlock.h>
>> +#include <linux/memory_hotplug.h>
>> +#include <linux/sysdev.h>
>> +#include <linux/sysfs.h>
>> +
>>
>> #include <asm/prom.h>
>> #include <asm/machdep.h>
>> @@ -404,11 +408,165 @@
>> return 0;
>> }
>>
>> +#ifdef CONFIG_MEMORY_HOTPLUG
>> +
>> +static struct property *clone_property(struct property *old_prop)
>> +{
>> + struct property *new_prop;
>> +
>> + new_prop = kzalloc((sizeof *new_prop), GFP_KERNEL);
>> + if (!new_prop)
>> + return NULL;
>> +
>> + new_prop->name = kzalloc(strlen(old_prop->name) + 1, GFP_KERNEL);
>
> kstrdup()?
Ahhh.. I did not know of kstrdup(). I will update to use this instead.
>
>> + new_prop->value = kzalloc(old_prop->length + 1, GFP_KERNEL);
>> + if (!new_prop->name || !new_prop->value) {
>> + free_property(new_prop);
>> + return NULL;
>> + }
>> +
>> + strcpy(new_prop->name, old_prop->name);
>> + memcpy(new_prop->value, old_prop->value, old_prop->length);
>> + new_prop->length = old_prop->length;
>> +
>> + return new_prop;
>> +}
>> +
>> +int platform_probe_memory(u64 phys_addr)
>> +{
>> + struct device_node *dn;
>> + struct property *new_prop, *old_prop;
>> + struct property *lmb_sz_prop;
>> + struct of_drconf_cell *drmem;
>> + u64 lmb_size;
>> + int num_entries, i, rc;
>> +
>> + if (!phys_addr)
>> + return -EINVAL;
>> +
>> + dn = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
>> + if (!dn)
>> + return -EINVAL;
>> +
>> + lmb_sz_prop = of_find_property(dn, "ibm,lmb-size", NULL);
>> + lmb_size = *(u64 *)lmb_sz_prop->value;
>
> of_get_property() ?
ok, will switch to of_find_property()
>> +
>> + old_prop = of_find_property(dn, "ibm,dynamic-memory", NULL);
>
> I know we should never fail to find these properties, but it would be
> nice to check just in case.
>
yes, will update.
>> +
>> + num_entries = *(u32 *)old_prop->value;
>> + drmem = (struct of_drconf_cell *)
>> + ((char *)old_prop->value + sizeof(u32));
>
> You do this dance twice (see below), a struct might make it cleaner.
Agreed. I think I will make this update in a separate patch. Updating
this to use a of_drconf struct would benefit this code as well as the code
in powerpc/numa.c that also deals with manipulating this property.
>
>> + for (i = 0; i < num_entries; i++) {
>> + u64 lmb_end_addr = drmem[i].base_addr + lmb_size;
>> + if (phys_addr >= drmem[i].base_addr
>> + && phys_addr < lmb_end_addr)
>> + break;
>> + }
>> +
>> + if (i >= num_entries) {
>> + of_node_put(dn);
>> + return -EINVAL;
>> + }
>> +
>> + if (drmem[i].flags & DRCONF_MEM_ASSIGNED) {
>> + of_node_put(dn);
>> + return 0;
>
> This is the already added case?
Yes. In this case the lmb is already assigned to the system.
>
>> + }
>> +
>> + rc = acquire_drc(drmem[i].drc_index);
>> + if (rc) {
>> + of_node_put(dn);
>> + return -1;
>
> -1 ?
Yeah, bad choice.
>
>> + }
>> +
>> + new_prop = clone_property(old_prop);
>> + drmem = (struct of_drconf_cell *)
>> + ((char *)new_prop->value + sizeof(u32));
>> +
>> + drmem[i].flags |= DRCONF_MEM_ASSIGNED;
>> + prom_update_property(dn, new_prop, old_prop);
>> +
>> + rc = blocking_notifier_call_chain(&pSeries_reconfig_chain,
>> + PSERIES_DRCONF_MEM_ADD,
>> + &drmem[i].base_addr);
>> + if (rc == NOTIFY_BAD) {
>> + prom_update_property(dn, old_prop, new_prop);
>> + release_drc(drmem[i].drc_index);
>> + }
>> +
>> + of_node_put(dn);
>> + return rc == NOTIFY_BAD ? -1 : 0;
>
> -1 ?
Another bad return code choice.
>
>> +}
>> +
>> +static ssize_t memory_release_store(struct class *class, const char *buf,
>> + size_t count)
>> +{
>> + unsigned long drc_index;
>> + struct device_node *dn;
>> + struct property *new_prop, *old_prop;
>> + struct of_drconf_cell *drmem;
>> + int num_entries;
>> + int i, rc;
>> +
>> + rc = strict_strtoul(buf, 0, &drc_index);
>> + if (rc)
>> + return -EINVAL;
>> +
>> + dn = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
>> + if (!dn)
>> + return 0;
>
> 0 really?
... and again...
>
>> +
>> + old_prop = of_find_property(dn, "ibm,dynamic-memory", NULL);
>> + new_prop = clone_property(old_prop);
>> +
>> + num_entries = *(u32 *)new_prop->value;
>> + drmem = (struct of_drconf_cell *)
>> + ((char *)new_prop->value + sizeof(u32));
>> +
>> + for (i = 0; i < num_entries; i++) {
>> + if (drmem[i].drc_index == drc_index)
>> + break;
>> + }
>> +
>> + if (i >= num_entries) {
>> + free_property(new_prop);
>> + of_node_put(dn);
>> + return -EINVAL;
>> + }
>
> Couldn't use old_prop up until here? They're identical aren't they, so
> you can do the clone here and you can avoid the free in the above error
> case.
>
Yes, this is possible. I will clean this up.
>> + drmem[i].flags &= ~DRCONF_MEM_ASSIGNED;
>> + prom_update_property(dn, new_prop, old_prop);
>> +
>> + rc = blocking_notifier_call_chain(&pSeries_reconfig_chain,
>> + PSERIES_DRCONF_MEM_REMOVE,
>> + &drmem[i].base_addr);
>> + if (rc != NOTIFY_BAD)
>> + rc = release_drc(drc_index);
>> +
>> + if (rc)
>> + prom_update_property(dn, old_prop, new_prop);
>> +
>> + of_node_put(dn);
>> + return rc ? -1 : count;
>
> -1, EPERM?
EPERM.
>
>> +}
>> +
>> +static struct class_attribute class_attr_mem_release =
>> + __ATTR(release, S_IWUSR, NULL, memory_release_store);
>> +#endif
>> +
>> static int pseries_dlpar_init(void)
>> {
>> if (!machine_is(pseries))
>> return 0;
>>
>> +#ifdef CONFIG_MEMORY_HOTPLUG
>> + if (sysfs_create_file(&memory_sysdev_class.kset.kobj,
>> + &class_attr_mem_release.attr))
>> + printk(KERN_INFO "DLPAR: Could not create sysfs memory "
>> + "release file\n");
>> +#endif
>> +
>> return 0;
>> }
>> device_initcall(pseries_dlpar_init);
>> Index: powerpc/arch/powerpc/mm/mem.c
>> ===================================================================
>> --- powerpc.orig/arch/powerpc/mm/mem.c 2009-10-08 11:07:45.000000000 -0500
>> +++ powerpc/arch/powerpc/mm/mem.c 2009-10-08 11:08:54.000000000 -0500
>> @@ -111,8 +111,19 @@
>> #ifdef CONFIG_MEMORY_HOTPLUG
>>
>> #ifdef CONFIG_NUMA
>> +int __attribute ((weak)) platform_probe_memory(u64 start)
>
> __weak
>
> Though be careful, I think this is vulnerable to a bug in some
> toolchains where the compiler will inline this version. See the comment
> around early_irq_init() in kernel/softirq.c for example.
>
> This will need to be a ppc_md hook as soon as another platform supports
> memory hotplug, though that may be never :)
>
I didn't know any other way to implement this. If using a weak symbol is ok
I will leave it. I am open to suggestions if there is a better way to do this.
thanks for reviewing the patch.
-Nathan
>> +{
>> + return 0;
>> +}
>> +
>> int memory_add_physaddr_to_nid(u64 start)
>> {
>> + int rc;
>> +
>> + rc = platform_probe_memory(start);
>> + if (rc)
>> + return rc;
>> +
>> return hot_add_scn_to_nid(start);
>> }
>> #endif
>
> cheers
>
^ permalink raw reply
* Re: i2c-powermac fails
From: Jean Delvare @ 2009-10-15 14:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, Tim Shepard, linuxppc-dev
In-Reply-To: <1255605559.2347.102.camel@pasglop>
On Thu, 15 Oct 2009 22:19:19 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2009-10-15 at 12:49 +0200, Jean Delvare wrote:
> > Oh. Well, if that was the case, we would see errors all the time, not
> > just during initialization, right? Or does the I2C clock frequency
> > change over time somehow?
>
> No but maybe we are a bit on the "limit" of the device and some
> registers take long to respond than others ?
Unlikely. The ADT7460 can run at I2C clock rates up to 400 kHz while
the Keywest I2C runs at 25, 50 or 100 kHz if I read the code properly.
I don't know what exact speed is used on Tim's system, apparently it is
read from the hardware in the device tree directly?
We could have low_i2c.c log the I2C clock frequency and/or try to force
the lowest speed (25 kHz) and see if it helps, but I very much doubt
it. And I'd rather wait for Tim to report the result with my last patch
first.
--
Jean Delvare
^ permalink raw reply
* kernel oops issue in localbus driver
From: Fathi Boudra @ 2009-10-15 13:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-embedded
Hi,
I have a FPGA connected to a MPC8347 through localbus.
The following kernel oops occurs sometimes:
Unable to handle kernel paging request for data at address 0x7ddfecb0
Faulting instruction address: 0xc00145f4
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT
Modules linked in: ath_pci ath_rate_minstrel ath_hal wlan_acl
wlan_ccmp wlan_scan_ap wlan_scan_sta wlan_tkip wlan_wep wlan_xauth
wlan gpio localbus
NIP: C00145F4 LR: D1083C74 CTR: 000001C3
REGS: c700ddb0 TRAP: 0300 Tainted: P (2.6.18)
MSR: 00009032 <EE,ME,IR,DR> CR: 20024042 XER: 20000000
DAR: 7DDFECB0, DSISR: 22000000
TASK = c7786810[345] 'femain' THREAD: c700c000
GPR00: 00000000 C700DE60 C7786810 7DDFEBC8 C90620EC 00000F00 7DDFECAC
7196E7E0
GPR08: 0EECA261 D1090000 0021ED00 C00145D0 00001000 704C6206 00000000
1005924D
GPR16: C0034D7C 7DDFEBC8 C700DE9C 00000F00 00000000 C787A3C0 D1090000
00000000
GPR24: 00000000 D1090000 7DDFEBC8 D1090000 000003C0 C9062000 7DDFEBC8
D108E954
NIP [C00145F4] memcpy+0x24/0x9c
LR [D1083C74] lbp_memcpy32_fromio+0x54/0x98 [localbus]
Call Trace:
[C700DE60] [C019B780] preempt_schedule_irq+0x64/0xa4 (unreliable)
[C700DE80] [D10813C0] fpgadecenc_read+0x3ac/0x4b0 [localbus]
--- Exception: 7ddfebc8 at 0xc700df40
LR = _start+0x40000000/0xc
[C700DEF0] [C005F4DC] vfs_read+0x9c/0x140 (unreliable)
[C700DF10] [C005F840] sys_read+0x4c/0x90
[C700DF40] [C000F89C] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0x300bb7dc
LR = 0x3001ed40
Instruction dump:
4e800020 7c032040 418100a0 54a7e8ff 38c3fffc 3884fffc 41820028
70c00003
7ce903a6 40820054 80e40004 85040008 <90e60004> 95060008 4200fff0 70a50007
It seems there's an issue in the localbus driver (lbp_memcpy32_fromio
is a wrapper function for the localbus memory access):
ssize_t lbp_memcpy_fromio(void *dest, void *source, __u32 count32)
{
/* attempt to acquire the semaphore */
down(&sem_lb);
/* critical region */
mb();
memcpy_fromio(dest, source, count32 * 4);
mb();
/* release the given semaphore */
up(&sem_lb);
}
Aren't we supposed to use down_interruptible() instead ?
I didn't write the driver and would like to fix it.
Any hints will be appreciated.
cheers,
Fathi
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Felix Radensky @ 2009-10-15 12:49 UTC (permalink / raw)
To: Norbert van Bolhuis; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <4AD6F172.6030407@aimvalley.nl>
Hi, Norbert
Norbert van Bolhuis wrote:
> Hi Felix,
>
> do you have CONFIG_NO_HZ defined ?
>
> I've seen similar problems with powerpc + CONFIG_NO_HZ. In my case the
> low-level
> do_write_buffer (cfi_cmdset_0002.c) timed out too early. See
> http://lkml.org/lkml/2009/9/3/84
>
> Maybe in your case it's the do_erase_chip timing out too early.
>
> ---
> NvBolhuis.
>
Thanks for suggestion.
I have CONFIG_NO_HZ defined, but disabling it doesn't help.
I my case timeouts occur in NAND driver, fsl_elbc_nand.c
Felix.
^ permalink raw reply
* RE: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Richard Cochran @ 2009-10-15 12:19 UTC (permalink / raw)
To: 'Scott Wood'; +Cc: 'linuxppc-dev@lists.ozlabs.org'
In-Reply-To: <20091014152722.GA17867@b07421-ec1.am.freescale.net>
>-----Original Message----- From: Scott Wood [mailto:scottwood@freescale.co=
m]
>Because that would be three times the device trees to maintain, and a
>source of user confusion.
I wonder which is more confusing for the user:
1. Choosing one of three dts files.
2. Having only one dts for his board, but Ethernet doesn't work.
Richard
^ permalink raw reply
* Re: MPC5121 CAN and USB
From: Kári Davíðsson @ 2009-10-15 11:36 UTC (permalink / raw)
To: paul.gibson2074@gmail.com; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <4AD70585.40302@gmail.com>
Thank you Paul,
The kernel from the BSP on Freescale site is crashing on the CAN in my case=
(might be a hardware bug).
I could not find the source for the kernel in the BSP or on the freescale s=
ite.
I had not looked at http://git.denx.de/?p=3Dlinux-2.6-denx.git;a=3Dshortlog=
;h=3Drefs/heads/ltib-mpc5121ads-20090602
I am now in the progress of cloning the linux-mpc512x git from denx and bui=
lding from it.
Hopefully that will help me.
rg
kd
Paul Gibson wrote:
> In my opinion the best place is the BSP available on the MPC5121e page=20
> on the Freescale site.
>=20
> I actually use the kernel in the git repository here which is similar to=
=20
> the BSP:
> http://git.denx.de/?p=3Dlinux-2.6-denx.git;a=3Dshortlog;h=3Drefs/heads/lt=
ib-mpc5121ads-20090602=20
> or here:
> http://git.denx.de/?p=3Dlinux-mpc512x.git;a=3Dsummary
>=20
> I have found both to be very stable, also with the CAN and USB.
>=20
> Paul
>=20
> K=E1ri Dav=ED=F0sson wrote:
>> Hello,
>>
>> Where is the most current linux work for the Freescale MPC5121 cpu=20
>> stored.
>> What I am specifically interested in at this time is the CAN and USB=20
>> subsystems.
>>
>> rg
>> kd
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: MPC5121 CAN and USB
From: Paul Gibson @ 2009-10-15 11:20 UTC (permalink / raw)
Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <4AD6FD4E.9060507@marel.com>
In my opinion the best place is the BSP available on the MPC5121e page
on the Freescale site.
I actually use the kernel in the git repository here which is similar to
the BSP:
http://git.denx.de/?p=linux-2.6-denx.git;a=shortlog;h=refs/heads/ltib-mpc5121ads-20090602
or here:
http://git.denx.de/?p=linux-mpc512x.git;a=summary
I have found both to be very stable, also with the CAN and USB.
Paul
Kári Davíðsson wrote:
> Hello,
>
> Where is the most current linux work for the Freescale MPC5121 cpu
> stored.
> What I am specifically interested in at this time is the CAN and USB
> subsystems.
>
> rg
> kd
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: i2c-powermac fails
From: Benjamin Herrenschmidt @ 2009-10-15 11:19 UTC (permalink / raw)
To: Jean Delvare; +Cc: Paul Mackerras, Tim Shepard, linuxppc-dev
In-Reply-To: <20091015124923.23863a94@hyperion.delvare>
On Thu, 2009-10-15 at 12:49 +0200, Jean Delvare wrote:
> Oh. Well, if that was the case, we would see errors all the time, not
> just during initialization, right? Or does the I2C clock frequency
> change over time somehow?
No but maybe we are a bit on the "limit" of the device and some
registers take long to respond than others ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Christian Borntraeger @ 2009-10-15 11:05 UTC (permalink / raw)
To: Timur Tabi
Cc: scottwood, linuxppc-dev, brueckner, Linux Kernel Mailing List,
Alan Cox
In-Reply-To: <1255557226-4403-1-git-send-email-timur@freescale.com>
Am Mittwoch 14 Oktober 2009 23:53:46 schrieben Sie:
> hvc_console_print() calls the HVC client driver's put_chars() callback
> to write some characters to the console. If the callback returns 0, that
> indicates that no characters were written (perhaps the output buffer is
> full), but hvc_console_print() treats that as an error and discards the
> rest of the buffer.
>
> So change hvc_console_print() to just loop and call put_chars() again if it
> returns a 0 return code.
>
> This change makes hvc_console_print() behave more like hvc_push(), which
> does check for a 0 return code and re-schedules itself.
There is a difference between console and tty, if the console call does not
return, it might bring the full system to a stop. (if its the preferred console,
init will stop)
> This patch might fix drivers that return 0 to indicate that they're busy, such
> as arch/powerpc/platforms/pseries/hvconsole.c. It will break drivers that
> return 0 if their output buffer is full, but where those buffers cannot be
> emptied while the kernel is in a loop.
Yep. I think it really depends on the backend if looping will result in any
progress or not. My experience wth hvc_console is, that its quite hard to get
changes tested on all backends. (e.g. XEN, pseries, iseries, virtio_console,
s390_iucv...), so even if this change turns out to be correct, it should
probably sit in linux-next for a while. In additon I really dont oversee, what
backends wil break due to this patch.
The fact that struct console->write returns void indicates that the console
layer is not interested in errors. We have two policies we can implement:
1. drop console messages if case of congestion but keep the system going
2. dont drop messages and wait, even if the system might come to a complete stop
Looking at drivers/char/vt.c
/* console busy or not yet initialized */
if (!printable)
return;
if (!spin_trylock(&printing_lock))
return;
could mean that Linux consoles should not block.
Maybe its time to ask some of the elder magicians (CCing Alan Cox and linux-
kernel) about blocking and error handling in console code.
> --- a/drivers/char/hvc_console.c
> +++ b/drivers/char/hvc_console.c
> @@ -161,7 +161,7 @@ static void hvc_console_print(struct console *co, const
> char *b, }
> } else {
> r = cons_ops[index]->put_chars(vtermnos[index], c, i);
> - if (r <= 0) {
> + if (r < 0) {
> /* throw away chars on error */
> i = 0;
> } else if (r > 0) {
>
^ permalink raw reply
* MPC5121 CAN and USB
From: Kári Davíðsson @ 2009-10-15 10:45 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <4AD6F172.6030407@aimvalley.nl>
Hello,
Where is the most current linux work for the Freescale MPC5121 cpu stored.
What I am specifically interested in at this time is the CAN and USB subsystems.
rg
kd
^ permalink raw reply
* Re: i2c-powermac fails
From: Jean Delvare @ 2009-10-15 10:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, Tim Shepard, linuxppc-dev
In-Reply-To: <1255555575.2347.56.camel@pasglop>
On Thu, 15 Oct 2009 08:26:15 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2009-10-14 at 23:02 +0200, Jean Delvare wrote:
> > Hi all,
> >
> > On Tue, 13 Oct 2009 11:49:48 +0200, Jean Delvare wrote:
> > > I2C bus being setup too fast sounds more likely. It might be worth
> > > adding an arbitrary delay after initialization, just to see if it
> > > helps. Not sure where though, as I'm not familiar with the Powermac
> > > initialization steps. Maybe right before i2c_add_adapter() in
> > > i2c_powermac_probe?
> >
> > Tim, can you please give a try to this patch? Obviously your machine
> > will take 5 additional seconds to boot, and this isn't meant as a real
> > fix, but if it helps, this will be an interesting hint for further
> > debugging attempts.
>
> Oh, I was actually thinking about the frequency of the I2C clock :-)
Oh. Well, if that was the case, we would see errors all the time, not
just during initialization, right? Or does the I2C clock frequency
change over time somehow?
--
Jean Delvare
^ permalink raw reply
* Instable kernel (2.6.29 or 2.6.31) on MPC8548 with 2 GByte RAM
From: willy jacobs @ 2009-10-15 10:13 UTC (permalink / raw)
To: Linuxppc-dev
On our MPC8548 (latest die revision) based boards with 2 GByte DDR2 RAM we see an stable kernel when
CONFIG_HIGHMEM is not set
In this case only the first 768 MB will be used (as reported by /proc/cpuinfo).
Tested with/without the RT-patches for 2.6.29.6(-rt23) and 2.6.31.2(-rt13) kernels.
With CONFIG_HIGHMEM=y (2048 MB reported) we see (under "heavy" load conditions) regulary page
errors like this (with/without RT patches):
BUG: Bad page state in process loadgen pfn:7e31d
page:c17c23a0 flags:80000000 count:0 mapcount:-128 mapping:(null) index:48105
Call Trace:
[ef867d20] [c00072ac] show_stack+0x34/0x160 (unreliable)
[ef867d50] [c006fcd0] bad_page+0x90/0x13c
[ef867d70] [c0070d94] get_page_from_freelist+0x424/0x45c
[ef867de0] [c0070ea4] __alloc_pages_nodemask+0xd8/0x48c
[ef867e40] [c0082bf0] handle_mm_fault+0x404/0x740
[ef867e90] [c00131bc] do_page_fault+0x150/0x460
[ef867f40] [c001017c] handle_page_fault+0xc/0x80
With the RT-patches we see already during Linux startup at lot of these errors (from several processes):
BUG: scheduling while atomic: pam_console_app/0x00000001/802, CPU#0
Modules linked in:
Call Trace:
[ef28dce0] [c00072ac] show_stack+0x34/0x160 (unreliable)
[ef28dd10] [c002fa90] __schedule_bug+0x6c/0x80
[ef28dd30] [c02660fc] __schedule+0x264/0x338
[ef28dd60] [c0266400] schedule+0x1c/0x40
[ef28dd70] [c0267898] rt_spin_lock_slowlock+0x124/0x264
[ef28dde0] [c0079154] __lru_cache_add+0x24/0xa8
[ef28de00] [c008ee04] page_add_new_anon_rmap+0x58/0x88
[ef28de20] [c0086ff8] handle_mm_fault+0x5a4/0x804
[ef28de80] [c0013590] do_page_fault+0x14c/0x49c
[ef28df40] [c00101c4] handle_page_fault+0xc/0x80
BUG: scheduling while atomic: pam_console_app/0x00000001/807, CPU#0
Modules linked in:
Call Trace:
[ef323a30] [c00072ac] show_stack+0x34/0x160 (unreliable)
[ef323a60] [c002fa90] __schedule_bug+0x6c/0x80
[ef323a80] [c02660fc] __schedule+0x264/0x338
[ef323ab0] [c0266400] schedule+0x1c/0x40
[ef323ac0] [c0267898] rt_spin_lock_slowlock+0x124/0x264
[ef323b30] [c0079154] __lru_cache_add+0x24/0xa8
[ef323b50] [c008ee04] page_add_new_anon_rmap+0x58/0x88
[ef323b70] [c0086ff8] handle_mm_fault+0x5a4/0x804
[ef323bd0] [c0013590] do_page_fault+0x14c/0x49c
[ef323c90] [c00101c4] handle_page_fault+0xc/0x80
[ef323d50] [00000007] 0x7
[ef323d80] [c0071320] generic_file_aio_read+0x2d4/0x6bc
[ef323e00] [c00ffe98] nfs_file_read+0x124/0x178
[ef323e30] [c009d56c] do_sync_read+0xc4/0x138
[ef323ef0] [c009e0a4] vfs_read+0xc4/0x188
[ef323f10] [c009e514] sys_read+0x4c/0x90
[ef323f40] [c000fd84] ret_from_syscall+0x0/0x3c
Anyone experience with MPC8548 with 2 GByte RAM (HIGHMEM)?
Regards,
--
willy
Unclassified
------------------------------------------------------------------------------------------------------------
Disclaimer:
If you are not the intended recipient of this email, please notify the sender and delete it.
Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden.
Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s).
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
------------------------------------------------------------------------------------------------------------
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Norbert van Bolhuis @ 2009-10-15 9:54 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <4AD5ADC9.30503@embedded-sol.com>
Hi Felix,
do you have CONFIG_NO_HZ defined ?
I've seen similar problems with powerpc + CONFIG_NO_HZ. In my case the low-level
do_write_buffer (cfi_cmdset_0002.c) timed out too early. See
http://lkml.org/lkml/2009/9/3/84
Maybe in your case it's the do_erase_chip timing out too early.
---
NvBolhuis.
Felix Radensky wrote:
> Hi,
>
> I have a strange problem in linux-2.6.31 running on MPC8536DS board.
> It is 100% reproducible, by opening a 350MB tar file into ubifs volume
> on NAND flash, and starting erase of NOR flash partition right after that.
>
> If I don't start NOR erase, everything works fine. Also, If I run sync
> after
> tar, no problem occurs. The NOR flash is 32MB Spansion, NAND is
> 4GB Samsung.
>
> The error messages are as follows:
>
> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
> 5812:12288, written 0 bytes
> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5812
> UBI: recover PEB 5812, move data to PEB 19400
> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
> 5812:512, read 512 bytes
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
> 19400:512, written 0 bytes
> UBI warning: recover_peb: failed to write to PEB 19400
> UBI: try again
> UBI: recover PEB 5812, move data to PEB 19401
> UBI: run torture test for PEB 19400
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
> 19401:512, written 0 bytes
> UBI warning: recover_peb: failed to write to PEB 19401
> UBI: try again
> UBI: recover PEB 5812, move data to PEB 19402
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
> 19402:512, written 0 bytes
> UBI warning: recover_peb: failed to write to PEB 19402
> UBI: try again
> UBI: recover PEB 5812, move data to PEB 19403
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
> 19403:512, written 0 bytes
> UBI warning: recover_peb: failed to write to PEB 19403
> UBI warning: ubi_ro_mode: switch to read-only mode
> UBIFS error (pid 1149): ubifs_wbuf_write_nolock: cannot write 2522 bytes
> to LEB 389:10240, error -5
> UBIFS warning (pid 1149): ubifs_ro_mode: switched to read-only mode,
> error -5
> UBIFS error (pid 1149): do_writepage: cannot write page 0 of inode
> 30708, error -5
> UBIFS error (pid 1149): make_reservation: cannot reserve 858 bytes in
> jhead 2, error -30
> UBIFS error (pid 1149): do_writepage: cannot write page 2 of inode
> 29486, error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 721 bytes in
> jhead 2, error -30
> UBIFS error (pid 1149): do_writepage: cannot write page 1 of inode
> 30070, error -30
> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
> 5022:88064, written 0 bytes
> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5022
> UBI: recover PEB 5022, move data to PEB 19404
> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
> 5022:512, read 512 bytes
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19404
> UBI: try again
> UBI: recover PEB 5022, move data to PEB 19405
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19405
> UBI: try again
> UBI: recover PEB 5022, move data to PEB 19406
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19406
> UBI: try again
> UBI: recover PEB 5022, move data to PEB 19407
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19407
> UBIFS error (pid 1044): ubifs_wbuf_sync_nolock: cannot write 2048 bytes
> to LEB 788:86016
> UBIFS error (pid 1044): ubifs_bg_wbufs_sync: cannot sync write-buffer,
> error -30
> UBIFS warning (pid 1044): ubifs_ro_mode: switched to read-only mode,
> error -30
> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
> 5817:26624, written 0 bytes
> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5817
> UBI: recover PEB 5817, move data to PEB 19408
> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
> 5817:512, read 512 bytes
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19408
> UBI: try again
> UBI: recover PEB 5817, move data to PEB 19409
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19409
> UBI: try again
> UBI: recover PEB 5817, move data to PEB 19410
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19410
> UBI: try again
> UBI: recover PEB 5817, move data to PEB 19411
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19411
> UBIFS error (pid 1047): ubifs_wbuf_sync_nolock: cannot write 2048 bytes
> to LEB 385:24576
> UBIFS error (pid 1047): ubifs_bg_wbufs_sync: cannot sync write-buffer,
> error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
> jhead 1, error -30
> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30709,
> error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
> jhead 1, error -30
> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30710,
> error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
> jhead 1, error -30
> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30698,
> error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
> jhead 1, error -30
> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30711,
> error -30
>
> I'd appreciate any hints on what can cause this. Is it a hardware
> problem, mtd layer problem
> or UBI problem ?
>
> Thanks a lot in advance.
>
> Felix.
>
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* [PATCH 6/8] 8xx: Restore _PAGE_WRITETHRU
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-6-git-send-email-Joakim.Tjernlund@transmode.se>
8xx has not had WRITETHRU due to lack of bits in the pte.
After the recent rewrite of the 8xx TLB code, there are
two bits left. Use one of them to WRITETHRU.
Perhaps use the last SW bit to PAGE_SPECIAL or PAGE_FILE?
---
arch/powerpc/include/asm/pte-8xx.h | 5 +++--
arch/powerpc/kernel/head_8xx.S | 8 ++++++++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
index f23cd15..9349d83 100644
--- a/arch/powerpc/include/asm/pte-8xx.h
+++ b/arch/powerpc/include/asm/pte-8xx.h
@@ -34,12 +34,13 @@
#define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
#define _PAGE_DIRTY 0x0100 /* C: page changed */
-/* These 3 software bits must be masked out when the entry is loaded
- * into the TLB, 2 SW bits left.
+/* These 4 software bits must be masked out when the entry is loaded
+ * into the TLB, 1 SW bit left(0x0080).
*/
#define _PAGE_EXEC 0x0008 /* software: i-cache coherency required */
#define _PAGE_GUARDED 0x0010 /* software: guarded access */
#define _PAGE_ACCESSED 0x0020 /* software: page referenced */
+#define _PAGE_WRITETHRU 0x0040 /* software: caching is write through */
/* Setting any bits in the nibble with the follow two controls will
* require a TLB exception handler change. It is assumed unused bits
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index a1512e9..6fadc44 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -422,6 +422,10 @@ DataStoreTLBMiss:
* above.
*/
rlwimi r11, r10, 0, 27, 27
+ /* Insert the WriteThru flag into the TWC from the Linux PTE.
+ * It is bit 25 in the Linux PTE and bit 30 in the TWC
+ */
+ rlwimi r11, r10, 32-5, 30, 30
DO_8xx_CPU6(0x3b80, r3)
mtspr SPRN_MD_TWC, r11
@@ -559,6 +563,10 @@ DARFixed:/* Return from dcbx instruction bug workaround, r10 holds value of DAR
* It is bit 27 of both the Linux PTE and the TWC
*/
rlwimi r11, r10, 0, 27, 27
+ /* Insert the WriteThru flag into the TWC from the Linux PTE.
+ * It is bit 25 in the Linux PTE and bit 30 in the TWC
+ */
+ rlwimi r11, r10, 32-5, 30, 30
DO_8xx_CPU6(0x3b80, r3)
mtspr SPRN_MD_TWC, r11
mfspr r11, SPRN_MD_TWC /* get the pte address again */
--
1.6.4.4
^ permalink raw reply related
* [PATCH 5/8] 8xx: Add missing Guarded setting in DTLB Error.
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-5-git-send-email-Joakim.Tjernlund@transmode.se>
only DTLB Miss did set this bit, DTLB Error needs too otherwise
the setting is lost when the page becomes dirty.
---
arch/powerpc/kernel/head_8xx.S | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 320f333..a1512e9 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -552,9 +552,16 @@ DARFixed:/* Return from dcbx instruction bug workaround, r10 holds value of DAR
*/
ori r11, r11, 1 /* Set valid bit in physical L2 page */
DO_8xx_CPU6(0x3b80, r3)
- mtspr SPRN_MD_TWC, r11 /* Load pte table base address */
- mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
- lwz r10, 0(r11) /* Get the pte */
+ mtspr SPRN_MD_TWC, r11 /* Load pte table base address */
+ mfspr r10, SPRN_MD_TWC /* ....and get the pte address */
+ lwz r10, 0(r10) /* Get the pte */
+ /* Insert the Guarded flag into the TWC from the Linux PTE.
+ * It is bit 27 of both the Linux PTE and the TWC
+ */
+ rlwimi r11, r10, 0, 27, 27
+ DO_8xx_CPU6(0x3b80, r3)
+ mtspr SPRN_MD_TWC, r11
+ mfspr r11, SPRN_MD_TWC /* get the pte address again */
ori r10, r10, _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_HWWRITE
stw r10, 0(r11) /* and update pte in table */
--
1.6.4.4
^ permalink raw reply related
* [PATCH 8/8] 8xx: Remove DIRTY pte handling in DTLB Error.
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-8-git-send-email-Joakim.Tjernlund@transmode.se>
There is no need to do set the DIRTY bit directly in DTLB Error.
Trap to do_page_fault() and let the generic MM code do the work.
---
arch/powerpc/kernel/head_8xx.S | 96 ----------------------------------------
1 files changed, 0 insertions(+), 96 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 6fadc44..c60636e 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -500,102 +500,6 @@ DataTLBError:
cmpwi cr0, r10, 0x00f0
beq- FixupDAR /* must be a buggy dcbX, icbi insn. */
DARFixed:/* Return from dcbx instruction bug workaround, r10 holds value of DAR */
- mfspr r11, SPRN_DSISR
- /* As the DAR fixup may clear store we may have all 3 states zero.
- * Make sure only 0x0200(store) falls down into DIRTY handling
- */
- andis. r11, r11, 0x4a00 /* !translation, protection or store */
- srwi r11, r11, 16
- cmpwi cr0, r11, 0x0200 /* just store ? */
- bne 2f
- /* Only Change bit left now, do it here as it is faster
- * than trapping to the C fault handler.
- */
-
- /* The EA of a data TLB miss is automatically stored in the MD_EPN
- * register. The EA of a data TLB error is automatically stored in
- * the DAR, but not the MD_EPN register. We must copy the 20 most
- * significant bits of the EA from the DAR to MD_EPN before we
- * start walking the page tables. We also need to copy the CASID
- * value from the M_CASID register.
- * Addendum: The EA of a data TLB error is _supposed_ to be stored
- * in DAR, but it seems that this doesn't happen in some cases, such
- * as when the error is due to a dcbi instruction to a page with a
- * TLB that doesn't have the changed bit set. In such cases, there
- * does not appear to be any way to recover the EA of the error
- * since it is neither in DAR nor MD_EPN. As a workaround, the
- * _PAGE_HWWRITE bit is set for all kernel data pages when the PTEs
- * are initialized in mapin_ram(). This will avoid the problem,
- * assuming we only use the dcbi instruction on kernel addresses.
- */
-
- /* DAR is in r10 already */
- rlwinm r11, r10, 0, 0, 19
- ori r11, r11, MD_EVALID
- mfspr r10, SPRN_M_CASID
- rlwimi r11, r10, 0, 28, 31
- DO_8xx_CPU6(0x3780, r3)
- mtspr SPRN_MD_EPN, r11
-
- mfspr r10, SPRN_M_TWB /* Get level 1 table entry address */
-
- /* If we are faulting a kernel address, we have to use the
- * kernel page tables.
- */
- andi. r11, r10, 0x0800
- beq 3f
- lis r11, swapper_pg_dir@h
- ori r11, r11, swapper_pg_dir@l
- rlwimi r10, r11, 0, 2, 19
-3:
- lwz r11, 0(r10) /* Get the level 1 entry */
- rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address */
- beq 2f /* If zero, bail */
-
- /* We have a pte table, so fetch the pte from the table.
- */
- ori r11, r11, 1 /* Set valid bit in physical L2 page */
- DO_8xx_CPU6(0x3b80, r3)
- mtspr SPRN_MD_TWC, r11 /* Load pte table base address */
- mfspr r10, SPRN_MD_TWC /* ....and get the pte address */
- lwz r10, 0(r10) /* Get the pte */
- /* Insert the Guarded flag into the TWC from the Linux PTE.
- * It is bit 27 of both the Linux PTE and the TWC
- */
- rlwimi r11, r10, 0, 27, 27
- /* Insert the WriteThru flag into the TWC from the Linux PTE.
- * It is bit 25 in the Linux PTE and bit 30 in the TWC
- */
- rlwimi r11, r10, 32-5, 30, 30
- DO_8xx_CPU6(0x3b80, r3)
- mtspr SPRN_MD_TWC, r11
- mfspr r11, SPRN_MD_TWC /* get the pte address again */
-
- ori r10, r10, _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_HWWRITE
- stw r10, 0(r11) /* and update pte in table */
- xori r10, r10, _PAGE_RW /* RW bit is inverted */
-
- /* The Linux PTE won't go exactly into the MMU TLB.
- * Software indicator bits 22 and 28 must be clear.
- * Software indicator bits 24, 25, 26, and 27 must be
- * set. All other Linux PTE bits control the behavior
- * of the MMU.
- */
- li r11, 0x00f0
- mtspr SPRN_DAR,r11 /* Tag DAR */
- rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
- DO_8xx_CPU6(0x3d80, r3)
- mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
-
- mfspr r10, SPRN_M_TW /* Restore registers */
- lwz r11, 0(r0)
- mtcr r11
- lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
- lwz r3, 8(r0)
-#endif
- rfi
-2:
mfspr r10, SPRN_M_TW /* Restore registers */
lwz r11, 0(r0)
mtcr r11
--
1.6.4.4
^ permalink raw reply related
* [PATCH 7/8] 8xx: start using dcbX instructions in various copy routines
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-7-git-send-email-Joakim.Tjernlund@transmode.se>
Now that 8xx can fixup dcbX instructions, start using them
where possible like every other PowerPc arch do.
---
arch/powerpc/kernel/misc_32.S | 18 ------------------
arch/powerpc/lib/copy_32.S | 24 ------------------------
2 files changed, 0 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 15f28e0..b92095e 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -495,15 +495,7 @@ _GLOBAL(clear_pages)
li r0,PAGE_SIZE/L1_CACHE_BYTES
slw r0,r0,r4
mtctr r0
-#ifdef CONFIG_8xx
- li r4, 0
-1: stw r4, 0(r3)
- stw r4, 4(r3)
- stw r4, 8(r3)
- stw r4, 12(r3)
-#else
1: dcbz 0,r3
-#endif
addi r3,r3,L1_CACHE_BYTES
bdnz 1b
blr
@@ -528,15 +520,6 @@ _GLOBAL(copy_page)
addi r3,r3,-4
addi r4,r4,-4
-#ifdef CONFIG_8xx
- /* don't use prefetch on 8xx */
- li r0,4096/L1_CACHE_BYTES
- mtctr r0
-1: COPY_16_BYTES
- bdnz 1b
- blr
-
-#else /* not 8xx, we can prefetch */
li r5,4
#if MAX_COPY_PREFETCH > 1
@@ -577,7 +560,6 @@ _GLOBAL(copy_page)
li r0,MAX_COPY_PREFETCH
li r11,4
b 2b
-#endif /* CONFIG_8xx */
/*
* void atomic_clear_mask(atomic_t mask, atomic_t *addr)
diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
index c657de5..74a7f41 100644
--- a/arch/powerpc/lib/copy_32.S
+++ b/arch/powerpc/lib/copy_32.S
@@ -98,20 +98,7 @@ _GLOBAL(cacheable_memzero)
bdnz 4b
3: mtctr r9
li r7,4
-#if !defined(CONFIG_8xx)
10: dcbz r7,r6
-#else
-10: stw r4, 4(r6)
- stw r4, 8(r6)
- stw r4, 12(r6)
- stw r4, 16(r6)
-#if CACHE_LINE_SIZE >= 32
- stw r4, 20(r6)
- stw r4, 24(r6)
- stw r4, 28(r6)
- stw r4, 32(r6)
-#endif /* CACHE_LINE_SIZE */
-#endif
addi r6,r6,CACHELINE_BYTES
bdnz 10b
clrlwi r5,r8,32-LG_CACHELINE_BYTES
@@ -200,9 +187,7 @@ _GLOBAL(cacheable_memcpy)
mtctr r0
beq 63f
53:
-#if !defined(CONFIG_8xx)
dcbz r11,r6
-#endif
COPY_16_BYTES
#if L1_CACHE_BYTES >= 32
COPY_16_BYTES
@@ -356,14 +341,6 @@ _GLOBAL(__copy_tofrom_user)
li r11,4
beq 63f
-#ifdef CONFIG_8xx
- /* Don't use prefetch on 8xx */
- mtctr r0
- li r0,0
-53: COPY_16_BYTES_WITHEX(0)
- bdnz 53b
-
-#else /* not CONFIG_8xx */
/* Here we decide how far ahead to prefetch the source */
li r3,4
cmpwi r0,1
@@ -416,7 +393,6 @@ _GLOBAL(__copy_tofrom_user)
li r3,4
li r7,0
bne 114b
-#endif /* CONFIG_8xx */
63: srwi. r0,r5,2
mtctr r0
--
1.6.4.4
^ permalink raw reply related
* [PATCH 2/8] 8xx: Update TLB asm so it behaves as linux mm expects.
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-2-git-send-email-Joakim.Tjernlund@transmode.se>
Update the TLB asm to make proper use of _PAGE_DIRY and _PAGE_ACCESSED.
Get rid of _PAGE_HWWRITE too.
Pros:
- I/D TLB Miss never needs to write to the linux pte.
- _PAGE_ACCESSED is only set on TLB Error fixing accounting
- _PAGE_DIRTY is mapped to 0x100, the changed bit, and is set directly
when a page has been made dirty.
- Proper RO/RW mapping of user space.
- Free up 2 SW TLB bits in the linux pte(add back _PAGE_WRITETHRU ?)
- kernel RO/user NA support.
Cons:
- A few more instructions in the TLB Miss routines.
---
arch/powerpc/include/asm/pte-8xx.h | 13 ++---
arch/powerpc/kernel/head_8xx.S | 99 ++++++++++++++++++-----------------
2 files changed, 57 insertions(+), 55 deletions(-)
diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
index 8c6e312..f23cd15 100644
--- a/arch/powerpc/include/asm/pte-8xx.h
+++ b/arch/powerpc/include/asm/pte-8xx.h
@@ -32,22 +32,21 @@
#define _PAGE_FILE 0x0002 /* when !present: nonlinear file mapping */
#define _PAGE_NO_CACHE 0x0002 /* I: cache inhibit */
#define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
+#define _PAGE_DIRTY 0x0100 /* C: page changed */
-/* These five software bits must be masked out when the entry is loaded
- * into the TLB.
+/* These 3 software bits must be masked out when the entry is loaded
+ * into the TLB, 2 SW bits left.
*/
#define _PAGE_EXEC 0x0008 /* software: i-cache coherency required */
#define _PAGE_GUARDED 0x0010 /* software: guarded access */
-#define _PAGE_DIRTY 0x0020 /* software: page changed */
-#define _PAGE_RW 0x0040 /* software: user write access allowed */
-#define _PAGE_ACCESSED 0x0080 /* software: page referenced */
+#define _PAGE_ACCESSED 0x0020 /* software: page referenced */
/* Setting any bits in the nibble with the follow two controls will
* require a TLB exception handler change. It is assumed unused bits
* are always zero.
*/
-#define _PAGE_HWWRITE 0x0100 /* h/w write enable: never set in Linux PTE */
-#define _PAGE_USER 0x0800 /* One of the PP bits, the other is USER&~RW */
+#define _PAGE_RW 0x0400 /* lsb PP bits, inverted in HW */
+#define _PAGE_USER 0x0800 /* msb PP bits */
#define _PMD_PRESENT 0x0001
#define _PMD_BAD 0x0ff0
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 52ff8c5..2011230 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -333,26 +333,20 @@ InstructionTLBMiss:
mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
lwz r10, 0(r11) /* Get the pte */
-#ifdef CONFIG_SWAP
- /* do not set the _PAGE_ACCESSED bit of a non-present page */
- andi. r11, r10, _PAGE_PRESENT
- beq 4f
- ori r10, r10, _PAGE_ACCESSED
- mfspr r11, SPRN_MD_TWC /* get the pte address again */
- stw r10, 0(r11)
-4:
-#else
- ori r10, r10, _PAGE_ACCESSED
- stw r10, 0(r11)
-#endif
+ andi. r11, r10, _PAGE_ACCESSED | _PAGE_PRESENT
+ cmpwi cr0, r11, _PAGE_ACCESSED | _PAGE_PRESENT
+ bne- cr0, 2f
+
+ /* Clear PP lsb, 0x400 */
+ rlwinm r10, r10, 0, 22, 20
/* The Linux PTE won't go exactly into the MMU TLB.
- * Software indicator bits 21, 22 and 28 must be clear.
+ * Software indicator bits 22 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
* set. All other Linux PTE bits control the behavior
* of the MMU.
*/
-2: li r11, 0x00f0
+ li r11, 0x00f0
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x2d80, r3)
mtspr SPRN_MI_RPN, r10 /* Update TLB entry */
@@ -365,6 +359,22 @@ InstructionTLBMiss:
lwz r3, 8(r0)
#endif
rfi
+2:
+ mfspr r11, SPRN_SRR1
+ /* clear all error bits as TLB Miss
+ * sets a few unconditionally
+ */
+ rlwinm r11, r11, 0, 0xffff
+ mtspr SPRN_SRR1, r11
+
+ mfspr r10, SPRN_M_TW /* Restore registers */
+ lwz r11, 0(r0)
+ mtcr r11
+ lwz r11, 4(r0)
+#ifdef CONFIG_8xx_CPU6
+ lwz r3, 8(r0)
+#endif
+ b InstructionAccess
. = 0x1200
DataStoreTLBMiss:
@@ -409,21 +419,27 @@ DataStoreTLBMiss:
DO_8xx_CPU6(0x3b80, r3)
mtspr SPRN_MD_TWC, r11
-#ifdef CONFIG_SWAP
- /* do not set the _PAGE_ACCESSED bit of a non-present page */
- andi. r11, r10, _PAGE_PRESENT
- beq 4f
- ori r10, r10, _PAGE_ACCESSED
-4:
- /* and update pte in table */
-#else
- ori r10, r10, _PAGE_ACCESSED
-#endif
- mfspr r11, SPRN_MD_TWC /* get the pte address again */
- stw r10, 0(r11)
+ /* Both _PAGE_ACCESSED and _PAGE_PRESENT has to be set.
+ * We also need to know if the insn is a load/store, so:
+ * Clear _PAGE_PRESENT and load that which will
+ * trap into DTLB Error with store bit set accordinly.
+ */
+ /* PRESENT=0x1, ACCESSED=0x20
+ * r11 = ((r10 & PRESENT) & ((r10 & ACCESSED) >> 5));
+ * r10 = (r10 & ~PRESENT) | r11;
+ */
+ rlwinm r11, r10, 32-5, 31, 31
+ and r11, r11, r10
+ rlwimi r10, r11, 0, 31, 31
+
+ /* Honour kernel RO, User NA */
+ andi. r11, r10, _PAGE_USER | _PAGE_RW
+ bne- cr0, 5f
+ ori r10,r10, 0x200 /* Extended encoding, bit 22 */
+5: xori r10, r10, _PAGE_RW /* invert RW bit */
/* The Linux PTE won't go exactly into the MMU TLB.
- * Software indicator bits 21, 22 and 28 must be clear.
+ * Software indicator bits 22 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
* set. All other Linux PTE bits control the behavior
* of the MMU.
@@ -469,11 +485,12 @@ DataTLBError:
stw r10, 0(r0)
stw r11, 4(r0)
- /* First, make sure this was a store operation.
+ mfspr r11, SPRN_DSISR
+ andis. r11, r11, 0x4800 /* !translation or protection */
+ bne 2f /* branch if either is set */
+ /* Only Change bit left now, do it here as it is faster
+ * than trapping to the C fault handler.
*/
- mfspr r10, SPRN_DSISR
- andis. r11, r10, 0x0200 /* If set, indicates store op */
- beq 2f
/* The EA of a data TLB miss is automatically stored in the MD_EPN
* register. The EA of a data TLB error is automatically stored in
@@ -522,26 +539,12 @@ DataTLBError:
mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
lwz r10, 0(r11) /* Get the pte */
- andi. r11, r10, _PAGE_RW /* Is it writeable? */
- beq 2f /* Bail out if not */
-
- /* Update 'changed', among others.
- */
-#ifdef CONFIG_SWAP
- ori r10, r10, _PAGE_DIRTY|_PAGE_HWWRITE
- /* do not set the _PAGE_ACCESSED bit of a non-present page */
- andi. r11, r10, _PAGE_PRESENT
- beq 4f
- ori r10, r10, _PAGE_ACCESSED
-4:
-#else
- ori r10, r10, _PAGE_DIRTY|_PAGE_ACCESSED|_PAGE_HWWRITE
-#endif
- mfspr r11, SPRN_MD_TWC /* Get pte address again */
+ ori r10, r10, _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_HWWRITE
stw r10, 0(r11) /* and update pte in table */
+ xori r10, r10, _PAGE_RW /* RW bit is inverted */
/* The Linux PTE won't go exactly into the MMU TLB.
- * Software indicator bits 21, 22 and 28 must be clear.
+ * Software indicator bits 22 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
* set. All other Linux PTE bits control the behavior
* of the MMU.
--
1.6.4.4
^ permalink raw reply related
* [PATCH 3/8] 8xx: Tag DAR with 0x00f0 to catch buggy instructions.
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-3-git-send-email-Joakim.Tjernlund@transmode.se>
dcbz, dcbf, dcbi, dcbst and icbi do not set DAR when they
cause a DTLB Error. Dectect this by tagging DAR with 0x00f0
at every exception exit that modifies DAR.
Test for DAR=0x00f0 in DataTLBError and bail
to handle_page_fault().
---
arch/powerpc/kernel/head_8xx.S | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 2011230..bca22fa 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -206,6 +206,8 @@ MachineCheck:
EXCEPTION_PROLOG
mfspr r4,SPRN_DAR
stw r4,_DAR(r11)
+ li r5,0x00f0
+ mtspr SPRN_DAR,r5 /* Tag DAR, to be used in DTLB Error */
mfspr r5,SPRN_DSISR
stw r5,_DSISR(r11)
addi r3,r1,STACK_FRAME_OVERHEAD
@@ -222,6 +224,8 @@ DataAccess:
stw r10,_DSISR(r11)
mr r5,r10
mfspr r4,SPRN_DAR
+ li r10,0x00f0
+ mtspr SPRN_DAR,r10 /* Tag DAR, to be used in DTLB Error */
EXC_XFER_EE_LITE(0x300, handle_page_fault)
/* Instruction access exception.
@@ -244,6 +248,8 @@ Alignment:
EXCEPTION_PROLOG
mfspr r4,SPRN_DAR
stw r4,_DAR(r11)
+ li r5,0x00f0
+ mtspr SPRN_DAR,r5 /* Tag DAR, to be used in DTLB Error */
mfspr r5,SPRN_DSISR
stw r5,_DSISR(r11)
addi r3,r1,STACK_FRAME_OVERHEAD
@@ -445,6 +451,7 @@ DataStoreTLBMiss:
* of the MMU.
*/
2: li r11, 0x00f0
+ mtspr SPRN_DAR,r11 /* Tag DAR */
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x3d80, r3)
mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
@@ -485,6 +492,10 @@ DataTLBError:
stw r10, 0(r0)
stw r11, 4(r0)
+ mfspr r10, SPRN_DAR
+ cmpwi cr0, r10, 0x00f0
+ beq- 2f /* must be a buggy dcbX, icbi insn. */
+
mfspr r11, SPRN_DSISR
andis. r11, r11, 0x4800 /* !translation or protection */
bne 2f /* branch if either is set */
@@ -508,7 +519,8 @@ DataTLBError:
* are initialized in mapin_ram(). This will avoid the problem,
* assuming we only use the dcbi instruction on kernel addresses.
*/
- mfspr r10, SPRN_DAR
+
+ /* DAR is in r10 already */
rlwinm r11, r10, 0, 0, 19
ori r11, r11, MD_EVALID
mfspr r10, SPRN_M_CASID
@@ -550,6 +562,7 @@ DataTLBError:
* of the MMU.
*/
li r11, 0x00f0
+ mtspr SPRN_DAR,r11 /* Tag DAR */
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x3d80, r3)
mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
--
1.6.4.4
^ permalink raw reply related
* [PATCH 4/8] 8xx: Fixup DAR from buggy dcbX instructions.
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-4-git-send-email-Joakim.Tjernlund@transmode.se>
This is an assembler version to fixup DAR not being set
by dcbX, icbi instructions. There are two versions, one
uses selfmodifing code, the other uses a
jump table but is much bigger(default).
---
arch/powerpc/kernel/head_8xx.S | 180 +++++++++++++++++++++++++++++++++++++++-
1 files changed, 176 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index bca22fa..320f333 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -494,11 +494,16 @@ DataTLBError:
mfspr r10, SPRN_DAR
cmpwi cr0, r10, 0x00f0
- beq- 2f /* must be a buggy dcbX, icbi insn. */
-
+ beq- FixupDAR /* must be a buggy dcbX, icbi insn. */
+DARFixed:/* Return from dcbx instruction bug workaround, r10 holds value of DAR */
mfspr r11, SPRN_DSISR
- andis. r11, r11, 0x4800 /* !translation or protection */
- bne 2f /* branch if either is set */
+ /* As the DAR fixup may clear store we may have all 3 states zero.
+ * Make sure only 0x0200(store) falls down into DIRTY handling
+ */
+ andis. r11, r11, 0x4a00 /* !translation, protection or store */
+ srwi r11, r11, 16
+ cmpwi cr0, r11, 0x0200 /* just store ? */
+ bne 2f
/* Only Change bit left now, do it here as it is faster
* than trapping to the C fault handler.
*/
@@ -604,6 +609,173 @@ DataTLBError:
. = 0x2000
+/* This is the procedure to calculate the data EA for buggy dcbx,dcbi instructions
+ * by decoding the registers used by the dcbx instruction and adding them.
+ * DAR is set to the calculated address and r10 also holds the EA on exit.
+ */
+#define NO_SELF_MODIFYING_CODE /* define if you don't want to use self modifying code */
+ nop /* A few nops to make the modified_instr: space below cache line aligned */
+ nop
+139: /* fetch instruction from userspace memory */
+ DO_8xx_CPU6(0x3780, r3)
+ mtspr SPRN_MD_EPN, r10
+ mfspr r11, SPRN_M_TWB /* Get level 1 table entry address */
+ lwz r11, 0(r11) /* Get the level 1 entry */
+ tophys (r11, r11)
+ DO_8xx_CPU6(0x3b80, r3)
+ mtspr SPRN_MD_TWC, r11 /* Load pte table base address */
+ mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
+ lwz r11, 0(r11) /* Get the pte */
+ /* concat physical page address(r11) and page offset(r10) */
+ rlwimi r11, r10, 0, 20, 31
+ b 140f
+FixupDAR: /* Entry point for dcbx workaround. */
+ /* fetch instruction from memory. */
+ mfspr r10, SPRN_SRR0
+ andis. r11, r10, 0x8000
+ tophys (r11, r10)
+ beq- 139b /* Branch if user space address */
+140: lwz r11,0(r11)
+/* Check if it really is a dcbx instruction. */
+/* dcbt and dcbtst does not generate DTLB Misses/Errors,
+ * no need to include them here */
+ srwi r10, r11, 26 /* check if major OP code is 31 */
+ cmpwi cr0, r10, 31
+ bne- 141f
+ rlwinm r10, r11, 0, 21, 30
+ cmpwi cr0, r10, 2028 /* Is dcbz? */
+ beq+ 142f
+ cmpwi cr0, r10, 940 /* Is dcbi? */
+ beq+ 142f
+ cmpwi cr0, r10, 108 /* Is dcbst? */
+ beq+ 144f /* Fix up store bit! */
+ cmpwi cr0, r10, 172 /* Is dcbf? */
+ beq+ 142f
+ cmpwi cr0, r10, 1964 /* Is icbi? */
+ beq+ 142f
+141: mfspr r10, SPRN_DAR /* r10 must hold DAR at exit */
+ b DARfix /* Nope, go back to normal TLB processing */
+
+144: mfspr r10, SPRN_DSISR
+ rlwinm r10, r10,0,7,5 /* Clear store bit for buggy dcbst insn */
+ mtspr SPRN_DSISR, r10
+142: /* continue, it was a dcbx, dcbi instruction. */
+#ifdef CONFIG_8xx_CPU6
+ lwz r3, 8(r0) /* restore r3 from memory */
+#endif
+#ifndef NO_SELF_MODIFYING_CODE
+ andis. r10,r11,0x1f /* test if reg RA is r0 */
+ li r10,modified_instr@l
+ dcbtst r0,r10 /* touch for store */
+ rlwinm r11,r11,0,0,20 /* Zero lower 10 bits */
+ oris r11,r11,640 /* Transform instr. to a "add r10,RA,RB" */
+ ori r11,r11,532
+ stw r11,0(r10) /* store add/and instruction */
+ dcbf 0,r10 /* flush new instr. to memory. */
+ icbi 0,r10 /* invalidate instr. cache line */
+ lwz r11, 4(r0) /* restore r11 from memory */
+ mfspr r10, SPRN_M_TW /* restore r10 from M_TW */
+ isync /* Wait until new instr is loaded from memory */
+modified_instr:
+ .space 4 /* this is where the add/and instr. is stored */
+ bne+ 143f
+ subf r10,r0,r10 /* r10=r10-r0, only if reg RA is r0 */
+143: mtdar r10 /* store faulting EA in DAR */
+ b DARFixed /* Go back to normal TLB handling */
+#else
+ mfctr r10
+ mtdar r10 /* save ctr reg in DAR */
+ rlwinm r10, r11, 24, 24, 28 /* offset into jump table for reg RB */
+ addi r10, r10, 150f@l /* add start of table */
+ mtctr r10 /* load ctr with jump address */
+ xor r10, r10, r10 /* sum starts at zero */
+ bctr /* jump into table */
+150:
+ add r10, r10, r0
+ b 151f
+ add r10, r10, r1
+ b 151f
+ add r10, r10, r2
+ b 151f
+ add r10, r10, r3
+ b 151f
+ add r10, r10, r4
+ b 151f
+ add r10, r10, r5
+ b 151f
+ add r10, r10, r6
+ b 151f
+ add r10, r10, r7
+ b 151f
+ add r10, r10, r8
+ b 151f
+ add r10, r10, r9
+ b 151f
+ add r10, r10, r10
+ b 151f
+ add r10, r10, r11
+ b 151f
+ add r10, r10, r12
+ b 151f
+ add r10, r10, r13
+ b 151f
+ add r10, r10, r14
+ b 151f
+ add r10, r10, r15
+ b 151f
+ add r10, r10, r16
+ b 151f
+ add r10, r10, r17
+ b 151f
+ add r10, r10, r18
+ b 151f
+ add r10, r10, r19
+ b 151f
+ mtctr r11 /* r10 needs special handling */
+ b 154f
+ mtctr r11 /* r11 needs special handling */
+ b 153f
+ add r10, r10, r22
+ b 151f
+ add r10, r10, r23
+ b 151f
+ add r10, r10, r24
+ b 151f
+ add r10, r10, r25
+ b 151f
+ add r10, r10, r25
+ b 151f
+ add r10, r10, r27
+ b 151f
+ add r10, r10, r28
+ b 151f
+ add r10, r10, r29
+ b 151f
+ add r10, r10, r30
+ b 151f
+ add r10, r10, r31
+151:
+ rlwinm. r11,r11,19,24,28 /* offset into jump table for reg RA */
+ beq 152f /* if reg RA is zero, don't add it */
+ addi r11, r11, 150b@l /* add start of table */
+ mtctr r11 /* load ctr with jump address */
+ rlwinm r11,r11,0,16,10 /* make sure we don't execute this more than once */
+ bctr /* jump into table */
+152:
+ mfdar r11
+ mtctr r11 /* restore ctr reg from DAR */
+ mtdar r10 /* save fault EA to DAR */
+ b DARFixed /* Go back to normal TLB handling */
+
+ /* special handling for r10,r11 since these are modified already */
+153: lwz r11, 4(r0) /* load r11 from memory */
+ b 155f
+154: mfspr r11, SPRN_M_TW /* load r10 from M_TW */
+155: add r10, r10, r11 /* add it */
+ mfctr r11 /* restore r11 */
+ b 151b
+#endif
+
.globl giveup_fpu
giveup_fpu:
blr
--
1.6.4.4
^ permalink raw reply related
* [PATCH 0/8] Fix 8xx MMU/TLB
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
Now updated with Scott's remarks.
There is still(probably) a trivial conflict in pte-8xx.h
Joakim Tjernlund (8):
8xx: invalidate non present TLBs
8xx: Update TLB asm so it behaves as linux mm expects.
8xx: Tag DAR with 0x00f0 to catch buggy instructions.
8xx: Fixup DAR from buggy dcbX instructions.
8xx: Add missing Guarded setting in DTLB Error.
8xx: Restore _PAGE_WRITETHRU
8xx: start using dcbX instructions in various copy routines
8xx: Remove DIRTY pte handling in DTLB Error.
arch/powerpc/include/asm/pte-8xx.h | 14 +-
arch/powerpc/kernel/head_8xx.S | 341 +++++++++++++++++++++++------------
arch/powerpc/kernel/misc_32.S | 18 --
arch/powerpc/lib/copy_32.S | 24 ---
arch/powerpc/mm/fault.c | 8 +-
5 files changed, 238 insertions(+), 167 deletions(-)
^ 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