* Re: 8xx v2.6 TLB problems and suggested workaround
From: Marcelo Tosatti @ 2005-04-04 20:09 UTC (permalink / raw)
To: linux-ppc-embedded, Dan Malek, Pantelis Antoniou; +Cc: Paul Mackerras
In-Reply-To: <20050404191718.GA30281@logos.cnet>
Hum,
The machine seems to be acting strange, but it boots normally
and applications run (more importantly there is no TLB entry
which could cause dcbst fault strangeness).
Some "dd" hangs till I press "ctrl+c", others just work. Really strange.
G'night, I'll look at it tomorrow.
[root@(none) /]# time dd if=/dev/zero of=file bs=16k count=400
400+0 records in
400+0 records out
real 0m4.261s
user 0m0.040s
sys 0m1.240s
[root@(none) /]# time dd if=/dev/zero of=file bs=32k count=400
real 0m50.369s
user 0m0.040s
sys 0m1.680s (ctrl+c)
[root@(none) /]#
> --- a/arch/ppc/kernel/head_8xx.S.orig 2005-04-04 19:43:23.000000000 -0300
> +++ b/arch/ppc/kernel/head_8xx.S 2005-04-04 19:47:40.000000000 -0300
> @@ -359,9 +359,7 @@
>
> . = 0x1200
> DataStoreTLBMiss:
> -#ifdef CONFIG_8xx_CPU6
> stw r3, 8(r0)
> -#endif
> DO_8xx_CPU6(0x3f80, r3)
> mtspr M_TW, r10 /* Save a couple of working registers */
> mfcr r10
> @@ -390,6 +388,16 @@
> mfspr r10, MD_TWC /* ....and get the pte address */
> lwz r10, 0(r10) /* Get the pte */
>
> + li r3, 0
> + cmpw r10, r3 /* does the pte contain a valid address? */
> + bne 4f
> + mfspr r10, M_TW /* Restore registers */
> + lwz r11, 0(r0)
> + mtcr r11
> + lwz r11, 4(r0)
> + lwz r3, 8(r0)
> + b DataAccess
> +4:
> /* Insert the Guarded flag into the TWC from the Linux PTE.
> * It is bit 27 of both the Linux PTE and the TWC (at least
> * I got that right :-). It will be better when we can put
> @@ -419,9 +427,7 @@
> lwz r11, 0(r0)
> mtcr r11
> lwz r11, 4(r0)
> -#ifdef CONFIG_8xx_CPU6
> lwz r3, 8(r0)
> -#endif
> rfi
>
> /* This is an instruction TLB error on the MPC8xx. This could be due
^ permalink raw reply
* Re: 8xx v2.6 TLB problems and suggested workaround
From: Kumar Gala @ 2005-04-05 1:11 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Paul Mackerras, linux-ppc-embedded
In-Reply-To: <20050404191718.GA30281@logos.cnet>
Marcelo,
One thing would be useful to comment why we are doing this so if it=20
ends up being a CPU errata we at least know why we are doing this.
- kumar
On Apr 4, 2005, at 2:17 PM, Marcelo Tosatti wrote:
> (need volunteers to test the patch below on 8xx)
>
> Hi,
>
> I've been investigating the 8xx update_mmu_cache() oops for the last=20=
> weeks, and
> here is what I have gathered.
>
> Oops: kernel access of bad area, sig: 11 [#1]
> NIP: C00049E8 LR: C000A5D0 SP: C4F53E10 REGS: c4f53d60 TRAP: 0300=A0=A0=
=A0=20
> Not taintedMSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
>
> DAR: 100113A0, DSISR: C2000000
> TASK =3D c53f17e0[1224] 'a' THREAD: c4f52000
> Last syscall: 47
> GPR00: C783D2A0 C4F53E10 C53F17E0 10050000 00000100 0009F0A0 10050000=20=
> 00000000
> GPR08: 00075925 C783D2A0 C53F17E0 00000000 00076924 10077178 00000000=20=
> 100B4338
> GPR16: 100BBDE8 0ED792CE 7FFFF670 00000000 00000000 00000000 00000000=20=
> C4F41100
> GPR24: 00000000 C4F3CAD4 C783D2A0 1005078C C4EB9140 C53861D0 04F85889=20=
> C034A0A0
> NIP [c00049e8] __flush_dcache_icache+0x14/0x40
> LR [c000a5d0] update_mmu_cache+0x64/0x98
> Call trace:
> =A0[c003fa7c] do_no_page+0x2f8/0x370
> =A0[c003fc44] handle_mm_fault+0x88/0x160
> =A0[c0009b58] do_page_fault+0x168/0x394
> =A0[c0002c28] handle_page_fault+0xc/0x80
>
> What is happening here is that update_mmu_cache() calls=20
> __flush_dcache_icache()
> to sync the d-cache with memory and invalidate any stale i-cache=20
> entries for
> the address being faulted in.
>
> Problem is that the "dcbst" instruction will, _sometimes_ (the=20
> failure/success rate is about 1/4
> with my test application) fault as a _write_ operation on the data.
>
> The address in question is always at the very beginning of the=20
> read-only data section,
> thus the write fault (as can be verified in DSISR: 0x02000000) is=20
> rejected
> because the vma structure is marked as read-only (vma->flags =3D=20
> ~VM_WRITE).
>
> 8xx machines running v2.6 are operating at the moment with a "tlbie()"=20=
> call at
> update_mmu_cache() just before __flush_dcache_icache(), which=20
> worksaround the problem.
>
> I've been able to watch the "problematic" TLB entry just before=20
> update_mmu_cache().
> Here it is:
>
> SPR=A0 824 : 0x10011f0b=A0=A0=A0 268508939
> BDI>rds 825
> SPR=A0 825 : 0x000001e0=A0=A0=A0=A0=A0=A0=A0=A0=A0 480
> BDI>rds 826
> SPR=A0 826 : 0x00001f00=A0=A0=A0=A0=A0=A0=A0=A0 7936
>
> As you can see by bit 18 of the D-TLB debugging register MD_RAM1 (SPR=20=
> 826), this entry
> is marked as invalid, which will invocate DataTLBError in case of an=20=
> access at this point
> and handle the fault properly in most cases.
>
> This is expected, and is how the sequence "DataTLBMiss" (no effective=20=
> address in TLB entry) ->
> "DataTLBError" (existant EA but valid bit not set) works on 8xx.
>
> Kumar Gala suggested inspection of memory which holds=20
> __flush_dcache_icache().
> With the BDI I could verify that the instruction sequence is there,=20
> intact.
>
> I'm unable to determine why a "dcbst" fault is incorrectly being=20
> treated as a WRITE operation.
>
> That seems to be the real problem. Likely to be Yet Another CPU bug?
>
> I've came up with a workaround which looks acceptable (unlike the=20
> tlbie one).
>
> Solution is to jump directly from the data tlb miss exception to=20
> DataAccess, which
> in turn calls do_page_fault() and friends.
>
> This avoids the dcbst's from being called to sync an address with an=20=
> "invalid" TLB entry.
>
> Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>
> --- a/arch/ppc/kernel/head_8xx.S.orig=A0=A0 2005-04-04 =
19:43:23.000000000=20
> -0300
> +++ b/arch/ppc/kernel/head_8xx.S=A0=A0=A0=A0=A0=A0=A0 2005-04-04 =
19:47:40.000000000=20
> -0300
> @@ -359,9 +359,7 @@
> =A0
> =A0=A0=A0=A0=A0=A0=A0 . =3D 0x1200
> =A0DataStoreTLBMiss:
> -#ifdef CONFIG_8xx_CPU6
> =A0=A0=A0=A0=A0=A0=A0 stw=A0=A0=A0=A0 r3, 8(r0)
> -#endif
> =A0=A0=A0=A0=A0=A0=A0 DO_8xx_CPU6(0x3f80, r3)
> =A0=A0=A0=A0=A0=A0=A0 mtspr=A0=A0 M_TW, r10=A0=A0=A0=A0=A0=A0 /* Save =
a couple of working registers=20
> */
> =A0=A0=A0=A0=A0=A0=A0 mfcr=A0=A0=A0 r10
> @@ -390,6 +388,16 @@
> =A0=A0=A0=A0=A0=A0=A0 mfspr=A0=A0 r10, MD_TWC=A0=A0=A0=A0 /* ....and =
get the pte address */
> =A0=A0=A0=A0=A0=A0=A0 lwz=A0=A0=A0=A0 r10, 0(r10)=A0=A0=A0=A0 /* Get =
the pte */
> =A0
> +=A0=A0=A0=A0=A0=A0 li=A0=A0=A0=A0=A0 r3, 0
> +=A0=A0=A0=A0=A0=A0 cmpw=A0=A0=A0 r10, r3=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
/* does the pte contain a valid=20
> address? */
> +=A0=A0=A0=A0=A0=A0 bne=A0=A0=A0=A0 4f
> +=A0=A0=A0=A0=A0=A0 mfspr=A0=A0 r10, M_TW=A0=A0=A0=A0=A0=A0 /* Restore =
registers */
> +=A0=A0=A0=A0=A0=A0 lwz=A0=A0=A0=A0 r11, 0(r0)
> +=A0=A0=A0=A0=A0=A0 mtcr=A0=A0=A0 r11
> +=A0=A0=A0=A0=A0=A0 lwz=A0=A0=A0=A0 r11, 4(r0)
> +=A0=A0=A0=A0=A0=A0 lwz=A0=A0=A0=A0 r3, 8(r0)
> +=A0=A0=A0=A0=A0=A0 b DataAccess
> +4:
> =A0=A0=A0=A0=A0=A0=A0 /* Insert the Guarded flag into the TWC from =
the Linux PTE.
> =A0=A0=A0=A0=A0=A0=A0=A0 * It is bit 27 of both the Linux PTE and the =
TWC (at least
> =A0=A0=A0=A0=A0=A0=A0=A0 * I got that right :-).=A0 It will be better =
when we can put
> @@ -419,9 +427,7 @@
> =A0=A0=A0=A0=A0=A0=A0 lwz=A0=A0=A0=A0 r11, 0(r0)
> =A0=A0=A0=A0=A0=A0=A0 mtcr=A0=A0=A0 r11
> =A0=A0=A0=A0=A0=A0=A0 lwz=A0=A0=A0=A0 r11, 4(r0)
> -#ifdef CONFIG_8xx_CPU6
> =A0=A0=A0=A0=A0=A0=A0 lwz=A0=A0=A0=A0 r3, 8(r0)
> -#endif
> =A0=A0=A0=A0=A0=A0=A0 rfi
> =A0
> =A0/* This is an instruction TLB error on the MPC8xx.=A0 This could =
be due
>
>
>
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: somewhat OT -- trying to build code on the fly then run it
From: Benjamin Herrenschmidt @ 2005-04-05 1:03 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev list
In-Reply-To: <4251CEA4.6070604@nortel.com>
On Mon, 2005-04-04 at 17:32 -0600, Chris Friesen wrote:
> I'm writing a testcase to test some code we wrote to allow userspace to
> flush the whole dcache and invalidate the whole icache. This requires
> me to write self-modifying code. For the first stage I'm just trying to
> build a routine (that just increments r3 and returns) on the heap and
> then call it.
>
> Everything seems to be fine right up until I jump to the code that I've
> written, then I get a segfault. The debugger shows my registers and
> data values are as expected, and the page of memory has xwr permissions.
>
> Can anyone tell me what I'm missing? I'm sure its something simple.
>
> Thanks,
>
> Chris.
>
>
> PS. Here's my current test code.
>
> #include <errno.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <sys/ioctl.h>
> #include <unistd.h>
> #include <stdio.h>
> #include <stdio.h>
> #include <sys/mman.h>
>
> /* these next two lines are the hex equivalents of the instructions:
> * addi r3,r3,1
> * blr
> */
> unsigned int incr_code[] = {
> 0x38630001,
> 0x4e800020
> };
>
> int dotest(unsigned long *addr)
> {
> int i=0;
> asm volatile (" \n\
> mr 3,%1 \n\
> bla %2 \n\
> mr %0,3 \n"
> : "=r" (i)
> : "r" (i), "r" (addr));
> return i;
> }
bla can only be used for small addresses (or very high addresses), and
it doesn't take a register argument but an absolute address. You want
something different, more like
mtctr %2
bctrl
Though you also need to add proper "clobber" constraints to indicate to
the compiler what will be clobbered by the routine you are calling (look
at the syscall macros of the kernel for an example of rather standard
clobber lists).
> void alter_opcode(unsigned long *addr, unsigned long opcode)
> {
> unsigned long offset = 0;
>
> asm volatile(
> "stw %1,0(%0) \n\t"
> "dcbf %0,%2 \n\t"
> "sync \n\t"
> "icbi %0,%2 \n\t"
> "sync \n\t"
> "isync \n\t"
> :: "r" (addr), "r" (opcode), "r" (offset));
> }
>
> int main()
> {
> unsigned long *addr;
> void *p = mmap(0, 4096, PROT_EXEC|PROT_WRITE|PROT_READ,
> MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
> if (p == MAP_FAILED) {
> perror("mmap");
> goto error;
> }
>
> addr = (unsigned long *)p;
>
> alter_opcode(addr, incr_code[0]);
> alter_opcode(addr+1, incr_code[1]);
>
> printf("%d\n", dotest(addr));
> return 0;
>
> error:
> return -1;
> }
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* [PATCH] ppc32: Fix cpufreq problems
From: Benjamin Herrenschmidt @ 2005-04-05 0:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list
Hi Andrew !
This patch updates the PowerMac cpufreq driver. It depends on the
addition of the suspend() method (my previous patch) and on the new flag
I defined to silence some warnings that are normal for us.
It fixes various issues related to cpufreq on pmac, including some
crashes on some models when sleeping the machine while in low speed,
proper voltage control on some newer machines, and adds voltage control
on 750FX based G3 laptops.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/ppc/platforms/pmac_feature.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_feature.c 2005-04-05 09:21:40.000000000 +1000
+++ linux-work/arch/ppc/platforms/pmac_feature.c 2005-04-05 10:53:44.000000000 +1000
@@ -1779,32 +1779,6 @@
if ((pmac_mb.board_flags & PMAC_MB_CAN_SLEEP) == 0)
return -EPERM;
-#ifdef CONFIG_CPU_FREQ_PMAC
- /* XXX should be elsewhere */
- if (machine_is_compatible("PowerBook6,5") ||
- machine_is_compatible("PowerBook6,4") ||
- machine_is_compatible("PowerBook5,5") ||
- machine_is_compatible("PowerBook5,4")) {
- struct device_node *volt_gpio_np;
- u32 *reg = NULL;
-
- volt_gpio_np = of_find_node_by_name(NULL, "cpu-vcore-select");
- if (volt_gpio_np != NULL)
- reg = (u32 *)get_property(volt_gpio_np, "reg", NULL);
- if (reg != NULL) {
- /* Set the CPU voltage high if sleeping */
- if (value == 1) {
- pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL,
- *reg, 0x05);
- } else if (value == 0 && (mfspr(SPRN_HID1) & HID1_DFS)) {
- pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL,
- *reg, 0x04);
- }
- mdelay(2);
- }
- }
-#endif /* CONFIG_CPU_FREQ_PMAC */
-
if (value == 1)
return core99_sleep();
else if (value == 0)
Index: linux-work/arch/ppc/platforms/pmac_cpufreq.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_cpufreq.c 2005-04-05 09:21:40.000000000 +1000
+++ linux-work/arch/ppc/platforms/pmac_cpufreq.c 2005-04-05 10:53:56.000000000 +1000
@@ -1,13 +1,18 @@
/*
* arch/ppc/platforms/pmac_cpufreq.c
*
- * Copyright (C) 2002 - 2004 Benjamin Herrenschmidt <benh@kernel.crashing.org>
+ * Copyright (C) 2002 - 2005 Benjamin Herrenschmidt <benh@kernel.crashing.org>
* Copyright (C) 2004 John Steele Scott <toojays@toojays.net>
*
* 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.
*
+ * TODO: Need a big cleanup here. Basically, we need to have different
+ * cpufreq_driver structures for the different type of HW instead of the
+ * current mess. We also need to better deal with the detection of the
+ * type of machine.
+ *
*/
#include <linux/config.h>
@@ -35,6 +40,7 @@
#include <asm/time.h>
#include <asm/system.h>
#include <asm/open_pic.h>
+#include <asm/keylargo.h>
/* WARNING !!! This will cause calibrate_delay() to be called,
* but this is an __init function ! So you MUST go edit
@@ -61,11 +67,13 @@
static unsigned int low_freq;
static unsigned int hi_freq;
static unsigned int cur_freq;
+static unsigned int sleep_freq;
/*
* Different models uses different mecanisms to switch the frequency
*/
static int (*set_speed_proc)(int low_speed);
+static unsigned int (*get_speed_proc)(void);
/*
* Some definitions used by the various speedprocs
@@ -73,6 +81,8 @@
static u32 voltage_gpio;
static u32 frequency_gpio;
static u32 slew_done_gpio;
+static int no_schedule;
+static int has_cpu_l2lve;
#define PMAC_CPU_LOW_SPEED 1
@@ -90,6 +100,14 @@
{0, CPUFREQ_TABLE_END},
};
+static inline void local_delay(unsigned long ms)
+{
+ if (no_schedule)
+ mdelay(ms);
+ else
+ msleep(ms);
+}
+
static inline void wakeup_decrementer(void)
{
set_dec(tb_ticks_per_jiffy);
@@ -118,20 +136,48 @@
*/
static int __pmac cpu_750fx_cpu_speed(int low_speed)
{
-#ifdef DEBUG_FREQ
- printk(KERN_DEBUG "HID1, before: %x\n", mfspr(SPRN_HID1));
-#endif
+ u32 hid2;
+
+ if (low_speed == 0) {
+ /* ramping up, set voltage first */
+ pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL, voltage_gpio, 0x05);
+ /* Make sure we sleep for at least 1ms */
+ local_delay(10);
+
+ /* tweak L2 for high voltage */
+ if (has_cpu_l2lve) {
+ hid2 = mfspr(SPRN_HID2);
+ hid2 &= ~0x2000;
+ mtspr(SPRN_HID2, hid2);
+ }
+ }
#ifdef CONFIG_6xx
low_choose_750fx_pll(low_speed);
#endif
-#ifdef DEBUG_FREQ
- printk(KERN_DEBUG "HID1, after: %x\n", mfspr(SPRN_HID1));
- debug_calc_bogomips();
-#endif
+ if (low_speed == 1) {
+ /* tweak L2 for low voltage */
+ if (has_cpu_l2lve) {
+ hid2 = mfspr(SPRN_HID2);
+ hid2 |= 0x2000;
+ mtspr(SPRN_HID2, hid2);
+ }
+
+ /* ramping down, set voltage last */
+ pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL, voltage_gpio, 0x04);
+ local_delay(10);
+ }
return 0;
}
+static unsigned int __pmac cpu_750fx_get_cpu_speed(void)
+{
+ if (mfspr(SPRN_HID1) & HID1_PS)
+ return low_freq;
+ else
+ return hi_freq;
+}
+
/* Switch CPU speed using DFS */
static int __pmac dfs_set_cpu_speed(int low_speed)
{
@@ -139,22 +185,25 @@
/* ramping up, set voltage first */
pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL, voltage_gpio, 0x05);
/* Make sure we sleep for at least 1ms */
- msleep(1);
+ local_delay(1);
}
/* set frequency */
+#ifdef CONFIG_6xx
low_choose_7447a_dfs(low_speed);
+#endif
+ udelay(100);
if (low_speed == 1) {
/* ramping down, set voltage last */
pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL, voltage_gpio, 0x04);
- msleep(1);
+ local_delay(1);
}
return 0;
}
-static unsigned int __pmac dfs_get_cpu_speed(unsigned int cpu)
+static unsigned int __pmac dfs_get_cpu_speed(void)
{
if (mfspr(SPRN_HID1) & HID1_DFS)
return low_freq;
@@ -167,30 +216,35 @@
*/
static int __pmac gpios_set_cpu_speed(int low_speed)
{
- int gpio;
+ int gpio, timeout = 0;
/* If ramping up, set voltage first */
if (low_speed == 0) {
pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL, voltage_gpio, 0x05);
/* Delay is way too big but it's ok, we schedule */
- msleep(10);
+ local_delay(10);
}
/* Set frequency */
+ gpio = pmac_call_feature(PMAC_FTR_READ_GPIO, NULL, frequency_gpio, 0);
+ if (low_speed == ((gpio & 0x01) == 0))
+ goto skip;
+
pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL, frequency_gpio,
low_speed ? 0x04 : 0x05);
udelay(200);
do {
- set_current_state(TASK_UNINTERRUPTIBLE);
- schedule_timeout(1);
+ if (++timeout > 100)
+ break;
+ local_delay(1);
gpio = pmac_call_feature(PMAC_FTR_READ_GPIO, NULL, slew_done_gpio, 0);
} while((gpio & 0x02) == 0);
-
+ skip:
/* If ramping down, set voltage last */
if (low_speed == 1) {
pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL, voltage_gpio, 0x04);
/* Delay is way too big but it's ok, we schedule */
- msleep(10);
+ local_delay(10);
}
#ifdef DEBUG_FREQ
@@ -207,6 +261,8 @@
struct adb_request req;
unsigned long save_l2cr;
unsigned long save_l3cr;
+ unsigned int pic_prio;
+ unsigned long flags;
preempt_disable();
@@ -214,7 +270,8 @@
printk(KERN_DEBUG "HID1, before: %x\n", mfspr(SPRN_HID1));
#endif
/* Disable all interrupt sources on openpic */
- openpic_set_priority(0xf);
+ pic_prio = openpic_get_priority();
+ openpic_set_priority(0xf);
/* Make sure the decrementer won't interrupt us */
asm volatile("mtdec %0" : : "r" (0x7fffffff));
@@ -224,7 +281,7 @@
asm volatile("mtdec %0" : : "r" (0x7fffffff));
/* We can now disable MSR_EE */
- local_irq_disable();
+ local_irq_save(flags);
/* Giveup the FPU & vec */
enable_kernel_fp();
@@ -277,10 +334,10 @@
wakeup_decrementer();
/* Restore interrupts */
- openpic_set_priority(0);
+ openpic_set_priority(pic_prio);
/* Let interrupts flow again ... */
- local_irq_enable();
+ local_irq_restore(flags);
#ifdef DEBUG_FREQ
debug_calc_bogomips();
@@ -291,9 +348,11 @@
return 0;
}
-static int __pmac do_set_cpu_speed(int speed_mode)
+static int __pmac do_set_cpu_speed(int speed_mode, int notify)
{
struct cpufreq_freqs freqs;
+ unsigned long l3cr;
+ static unsigned long prev_l3cr;
freqs.old = cur_freq;
freqs.new = (speed_mode == PMAC_CPU_HIGH_SPEED) ? hi_freq : low_freq;
@@ -302,14 +361,35 @@
if (freqs.old == freqs.new)
return 0;
- cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+ if (notify)
+ cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+ if (speed_mode == PMAC_CPU_LOW_SPEED &&
+ cpu_has_feature(CPU_FTR_L3CR)) {
+ l3cr = _get_L3CR();
+ if (l3cr & L3CR_L3E) {
+ prev_l3cr = l3cr;
+ _set_L3CR(0);
+ }
+ }
set_speed_proc(speed_mode == PMAC_CPU_LOW_SPEED);
- cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+ if (speed_mode == PMAC_CPU_HIGH_SPEED &&
+ cpu_has_feature(CPU_FTR_L3CR)) {
+ l3cr = _get_L3CR();
+ if ((prev_l3cr & L3CR_L3E) && l3cr != prev_l3cr)
+ _set_L3CR(prev_l3cr);
+ }
+ if (notify)
+ cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
cur_freq = (speed_mode == PMAC_CPU_HIGH_SPEED) ? hi_freq : low_freq;
return 0;
}
+static unsigned int __pmac pmac_cpufreq_get_speed(unsigned int cpu)
+{
+ return cur_freq;
+}
+
static int __pmac pmac_cpufreq_verify(struct cpufreq_policy *policy)
{
return cpufreq_frequency_table_verify(policy, pmac_cpu_freqs);
@@ -325,7 +405,7 @@
target_freq, relation, &newstate))
return -EINVAL;
- return do_set_cpu_speed(newstate);
+ return do_set_cpu_speed(newstate, 1);
}
unsigned int __pmac pmac_get_one_cpufreq(int i)
@@ -349,19 +429,65 @@
static u32 __pmac read_gpio(struct device_node *np)
{
u32 *reg = (u32 *)get_property(np, "reg", NULL);
+ u32 offset;
if (reg == NULL)
return 0;
/* That works for all keylargos but shall be fixed properly
- * some day...
+ * some day... The problem is that it seems we can't rely
+ * on the "reg" property of the GPIO nodes, they are either
+ * relative to the base of KeyLargo or to the base of the
+ * GPIO space, and the device-tree doesn't help.
+ */
+ offset = *reg;
+ if (offset < KEYLARGO_GPIO_LEVELS0)
+ offset += KEYLARGO_GPIO_LEVELS0;
+ return offset;
+}
+
+static int __pmac pmac_cpufreq_suspend(struct cpufreq_policy *policy, u32 state)
+{
+ /* Ok, this could be made a bit smarter, but let's be robust for now. We
+ * always force a speed change to high speed before sleep, to make sure
+ * we have appropriate voltage and/or bus speed for the wakeup process,
+ * and to make sure our loops_per_jiffies are "good enough", that is will
+ * not cause too short delays if we sleep in low speed and wake in high
+ * speed..
+ */
+ no_schedule = 1;
+ sleep_freq = cur_freq;
+ if (cur_freq == low_freq)
+ do_set_cpu_speed(PMAC_CPU_HIGH_SPEED, 0);
+ return 0;
+}
+
+static int __pmac pmac_cpufreq_resume(struct cpufreq_policy *policy)
+{
+ /* If we resume, first check if we have a get() function */
+ if (get_speed_proc)
+ cur_freq = get_speed_proc();
+ else
+ cur_freq = 0;
+
+ /* We don't, hrm... we don't really know our speed here, best
+ * is that we force a switch to whatever it was, which is
+ * probably high speed due to our suspend() routine
*/
- return 0x50 + (*reg);
+ do_set_cpu_speed(sleep_freq == low_freq ? PMAC_CPU_LOW_SPEED
+ : PMAC_CPU_HIGH_SPEED, 0);
+
+ no_schedule = 0;
+ return 0;
}
static struct cpufreq_driver pmac_cpufreq_driver = {
.verify = pmac_cpufreq_verify,
.target = pmac_cpufreq_target,
+ .get = pmac_cpufreq_get_speed,
.init = pmac_cpufreq_cpu_init,
+ .suspend = pmac_cpufreq_suspend,
+ .resume = pmac_cpufreq_resume,
+ .flags = CPUFREQ_PM_NO_WARN,
.name = "powermac",
.owner = THIS_MODULE,
};
@@ -461,14 +587,14 @@
static int __pmac pmac_cpufreq_init_7447A(struct device_node *cpunode)
{
struct device_node *volt_gpio_np;
- u32 *reg;
- struct cpufreq_driver *driver = &pmac_cpufreq_driver;
- /* Look for voltage GPIO */
+ if (get_property(cpunode, "dynamic-power-step", NULL) == NULL)
+ return 1;
+
volt_gpio_np = of_find_node_by_name(NULL, "cpu-vcore-select");
- reg = (u32 *)get_property(volt_gpio_np, "reg", NULL);
- voltage_gpio = *reg;
- if (!volt_gpio_np){
+ if (volt_gpio_np)
+ voltage_gpio = read_gpio(volt_gpio_np);
+ if (!voltage_gpio){
printk(KERN_ERR "cpufreq: missing cpu-vcore-select gpio\n");
return 1;
}
@@ -478,9 +604,37 @@
low_freq = cur_freq/2;
/* Read actual frequency from CPU */
- driver->get = dfs_get_cpu_speed;
- cur_freq = driver->get(0);
+ cur_freq = dfs_get_cpu_speed();
set_speed_proc = dfs_set_cpu_speed;
+ get_speed_proc = dfs_get_cpu_speed;
+
+ return 0;
+}
+
+static int __pmac pmac_cpufreq_init_750FX(struct device_node *cpunode)
+{
+ struct device_node *volt_gpio_np;
+ u32 pvr, *value;
+
+ if (get_property(cpunode, "dynamic-power-step", NULL) == NULL)
+ return 1;
+
+ hi_freq = cur_freq;
+ value = (u32 *)get_property(cpunode, "reduced-clock-frequency", NULL);
+ if (!value)
+ return 1;
+ low_freq = (*value) / 1000;
+
+ volt_gpio_np = of_find_node_by_name(NULL, "cpu-vcore-select");
+ if (volt_gpio_np)
+ voltage_gpio = read_gpio(volt_gpio_np);
+
+ pvr = mfspr(SPRN_PVR);
+ has_cpu_l2lve = !((pvr & 0xf00) == 0x100);
+
+ set_speed_proc = cpu_750fx_cpu_speed;
+ get_speed_proc = cpu_750fx_get_cpu_speed;
+ cur_freq = cpu_750fx_get_cpu_speed();
return 0;
}
@@ -543,16 +697,8 @@
set_speed_proc = pmu_set_cpu_speed;
}
/* Else check for 750FX */
- else if (PVR_VER(mfspr(SPRN_PVR)) == 0x7000) {
- if (get_property(cpunode, "dynamic-power-step", NULL) == NULL)
- goto out;
- hi_freq = cur_freq;
- value = (u32 *)get_property(cpunode, "reduced-clock-frequency", NULL);
- if (!value)
- goto out;
- low_freq = (*value) / 1000;
- set_speed_proc = cpu_750fx_cpu_speed;
- }
+ else if (PVR_VER(mfspr(SPRN_PVR)) == 0x7000)
+ pmac_cpufreq_init_750FX(cpunode);
out:
if (set_speed_proc == NULL)
return -ENODEV;
Index: linux-work/include/asm-ppc/reg.h
===================================================================
--- linux-work.orig/include/asm-ppc/reg.h 2005-04-05 09:21:40.000000000 +1000
+++ linux-work/include/asm-ppc/reg.h 2005-04-05 10:53:44.000000000 +1000
@@ -181,6 +181,7 @@
#define HID1_PC3 (1<<13) /* 7450 PLL_CFG[3] */
#define HID1_SYNCBE (1<<11) /* 7450 ABE for sync, eieio */
#define HID1_ABE (1<<10) /* 7450 Address Broadcast Enable */
+#define HID1_PS (1<<16) /* 750FX PLL selection */
#define SPRN_HID2 0x3F8 /* Hardware Implementation Register 2 */
#define SPRN_IABR 0x3F2 /* Instruction Address Breakpoint Register */
#define SPRN_HID4 0x3F4 /* 970 HID4 */
Index: linux-work/arch/ppc/syslib/open_pic.c
===================================================================
--- linux-work.orig/arch/ppc/syslib/open_pic.c 2005-04-05 09:21:40.000000000 +1000
+++ linux-work/arch/ppc/syslib/open_pic.c 2005-04-05 10:53:44.000000000 +1000
@@ -78,7 +78,6 @@
*/
#ifdef notused
static void openpic_enable_8259_pass_through(void);
-static u_int openpic_get_priority(void);
static u_int openpic_get_spurious(void);
static void openpic_set_sense(u_int irq, int sense);
#endif /* notused */
@@ -465,8 +464,7 @@
(void)openpic_read(&OpenPIC->THIS_CPU.EOI);
}
-#ifdef notused
-static u_int openpic_get_priority(void)
+u_int openpic_get_priority(void)
{
DECL_THIS_CPU;
@@ -474,7 +472,6 @@
return openpic_readfield(&OpenPIC->THIS_CPU.Current_Task_Priority,
OPENPIC_CURRENT_TASK_PRIORITY_MASK);
}
-#endif /* notused */
void openpic_set_priority(u_int pri)
{
Index: linux-work/include/asm-ppc/open_pic.h
===================================================================
--- linux-work.orig/include/asm-ppc/open_pic.h 2005-04-05 09:21:40.000000000 +1000
+++ linux-work/include/asm-ppc/open_pic.h 2005-04-05 10:53:44.000000000 +1000
@@ -56,6 +56,7 @@
int wait);
extern void openpic_set_k2_cascade(int irq);
extern void openpic_set_priority(u_int pri);
+extern u_int openpic_get_priority(void);
extern inline int openpic_to_irq(int irq)
{
^ permalink raw reply
* [PATCH] ppc32: Fix errata for some G3 CPUs
From: Benjamin Herrenschmidt @ 2005-04-05 0:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list
Hi !
Some G3 CPUs can crash in funny way if a store from an FPU register
instruction is executed on a register that has never been initialized
since power on. This patch fixes it by making sure all FP registers have
been properly initialized at kernel boot and when waking from sleep.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/ppc/kernel/cpu_setup_6xx.S
===================================================================
--- linux-work.orig/arch/ppc/kernel/cpu_setup_6xx.S 2005-03-15 11:56:39.000000000 +1100
+++ linux-work/arch/ppc/kernel/cpu_setup_6xx.S 2005-04-04 16:33:52.000000000 +1000
@@ -30,12 +30,14 @@
blr
_GLOBAL(__setup_cpu_750)
mflr r4
+ bl __init_fpu_registers
bl setup_common_caches
bl setup_750_7400_hid0
mtlr r4
blr
_GLOBAL(__setup_cpu_750cx)
mflr r4
+ bl __init_fpu_registers
bl setup_common_caches
bl setup_750_7400_hid0
bl setup_750cx
@@ -43,6 +45,7 @@
blr
_GLOBAL(__setup_cpu_750fx)
mflr r4
+ bl __init_fpu_registers
bl setup_common_caches
bl setup_750_7400_hid0
bl setup_750fx
@@ -51,6 +54,7 @@
_GLOBAL(__setup_cpu_7400)
mflr r4
bl setup_7400_workarounds
+ bl __init_fpu_registers
bl setup_common_caches
bl setup_750_7400_hid0
mtlr r4
@@ -58,6 +62,7 @@
_GLOBAL(__setup_cpu_7410)
mflr r4
bl setup_7410_workarounds
+ bl __init_fpu_registers
bl setup_common_caches
bl setup_750_7400_hid0
li r3,0
@@ -248,6 +253,25 @@
isync
blr
+/*
+ * Initialize the FPU registers. This is needed to work around an errata
+ * in some 750 cpus where using a not yet initialized FPU register after
+ * power on reset may hang the CPU
+ */
+_GLOBAL(__init_fpu_registers)
+ mfmsr r10
+ ori r11,r10,MSR_FP
+ mtmsr r11
+ isync
+ addis r9,r3,empty_zero_page@ha
+ addi r9,r9,empty_zero_page@l
+ REST_32FPRS(0,r9)
+ sync
+ mtmsr r10
+ isync
+ blr
+
+
/* Definitions for the table use to save CPU states */
#define CS_HID0 0
#define CS_HID1 4
Index: linux-work/arch/ppc/platforms/pmac_sleep.S
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_sleep.S 2005-03-15 11:56:42.000000000 +1100
+++ linux-work/arch/ppc/platforms/pmac_sleep.S 2005-04-05 10:35:06.000000000 +1000
@@ -267,6 +267,10 @@
/* Restore various CPU config stuffs */
bl __restore_cpu_setup
+ /* Make sure all FPRs have been initialized */
+ bl reloc_offset
+ bl __init_fpu_registers
+
/* Invalidate & enable L1 cache, we don't care about
* whatever the ROM may have tried to write to memory
*/
^ permalink raw reply
* 8xx v2.6 TLB problems and suggested workaround
From: Marcelo Tosatti @ 2005-04-04 19:17 UTC (permalink / raw)
To: linux-ppc-embedded, Dan Malek, Pantelis Antoniou; +Cc: Paul Mackerras
(need volunteers to test the patch below on 8xx)
Hi,
I've been investigating the 8xx update_mmu_cache() oops for the last weeks, and
here is what I have gathered.
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C00049E8 LR: C000A5D0 SP: C4F53E10 REGS: c4f53d60 TRAP: 0300 Not taintedMSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 100113A0, DSISR: C2000000
TASK = c53f17e0[1224] 'a' THREAD: c4f52000
Last syscall: 47
GPR00: C783D2A0 C4F53E10 C53F17E0 10050000 00000100 0009F0A0 10050000 00000000
GPR08: 00075925 C783D2A0 C53F17E0 00000000 00076924 10077178 00000000 100B4338
GPR16: 100BBDE8 0ED792CE 7FFFF670 00000000 00000000 00000000 00000000 C4F41100
GPR24: 00000000 C4F3CAD4 C783D2A0 1005078C C4EB9140 C53861D0 04F85889 C034A0A0
NIP [c00049e8] __flush_dcache_icache+0x14/0x40
LR [c000a5d0] update_mmu_cache+0x64/0x98
Call trace:
[c003fa7c] do_no_page+0x2f8/0x370
[c003fc44] handle_mm_fault+0x88/0x160
[c0009b58] do_page_fault+0x168/0x394
[c0002c28] handle_page_fault+0xc/0x80
What is happening here is that update_mmu_cache() calls __flush_dcache_icache()
to sync the d-cache with memory and invalidate any stale i-cache entries for
the address being faulted in.
Problem is that the "dcbst" instruction will, _sometimes_ (the failure/success rate is about 1/4
with my test application) fault as a _write_ operation on the data.
The address in question is always at the very beginning of the read-only data section,
thus the write fault (as can be verified in DSISR: 0x02000000) is rejected
because the vma structure is marked as read-only (vma->flags = ~VM_WRITE).
8xx machines running v2.6 are operating at the moment with a "tlbie()" call at
update_mmu_cache() just before __flush_dcache_icache(), which worksaround the problem.
I've been able to watch the "problematic" TLB entry just before update_mmu_cache().
Here it is:
SPR 824 : 0x10011f0b 268508939
BDI>rds 825
SPR 825 : 0x000001e0 480
BDI>rds 826
SPR 826 : 0x00001f00 7936
As you can see by bit 18 of the D-TLB debugging register MD_RAM1 (SPR 826), this entry
is marked as invalid, which will invocate DataTLBError in case of an access at this point
and handle the fault properly in most cases.
This is expected, and is how the sequence "DataTLBMiss" (no effective address in TLB entry) ->
"DataTLBError" (existant EA but valid bit not set) works on 8xx.
Kumar Gala suggested inspection of memory which holds __flush_dcache_icache().
With the BDI I could verify that the instruction sequence is there, intact.
I'm unable to determine why a "dcbst" fault is incorrectly being treated as a WRITE operation.
That seems to be the real problem. Likely to be Yet Another CPU bug?
I've came up with a workaround which looks acceptable (unlike the tlbie one).
Solution is to jump directly from the data tlb miss exception to DataAccess, which
in turn calls do_page_fault() and friends.
This avoids the dcbst's from being called to sync an address with an "invalid" TLB entry.
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
--- a/arch/ppc/kernel/head_8xx.S.orig 2005-04-04 19:43:23.000000000 -0300
+++ b/arch/ppc/kernel/head_8xx.S 2005-04-04 19:47:40.000000000 -0300
@@ -359,9 +359,7 @@
. = 0x1200
DataStoreTLBMiss:
-#ifdef CONFIG_8xx_CPU6
stw r3, 8(r0)
-#endif
DO_8xx_CPU6(0x3f80, r3)
mtspr M_TW, r10 /* Save a couple of working registers */
mfcr r10
@@ -390,6 +388,16 @@
mfspr r10, MD_TWC /* ....and get the pte address */
lwz r10, 0(r10) /* Get the pte */
+ li r3, 0
+ cmpw r10, r3 /* does the pte contain a valid address? */
+ bne 4f
+ mfspr r10, M_TW /* Restore registers */
+ lwz r11, 0(r0)
+ mtcr r11
+ lwz r11, 4(r0)
+ lwz r3, 8(r0)
+ b DataAccess
+4:
/* Insert the Guarded flag into the TWC from the Linux PTE.
* It is bit 27 of both the Linux PTE and the TWC (at least
* I got that right :-). It will be better when we can put
@@ -419,9 +427,7 @@
lwz r11, 0(r0)
mtcr r11
lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
-#endif
rfi
/* This is an instruction TLB error on the MPC8xx. This could be due
^ permalink raw reply
* Re: PREP sym53c8xx sym53c8xx brokeness due to 2.6.9-rc1-bk1 introduced residual data patch ...
From: Christian @ 2005-04-05 0:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Tom Rini
In-Reply-To: <20050331184549.GA28069@pegasos>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sven Luther wrote:
>>># This is a BitKeeper generated diff -Nru style patch.
>>>#
>>># ChangeSet
>>># 2004/08/16 10:35:18-07:00 trini@kernel.crashing.org
>>># ppc32: On PReP, use residual data for PCI dev -> IRQ, and use it.
>
> I got through all the changesets one by one, and it is most definitively this
> one. i unapply it and it works, i apply it and it breaks.
i can confirm this one.
the changesets are listed here:
http://linux.bkbits.net:8080/linux-2.6/patch@1.1803.125.6
...and because i had some troubles getting a GNU diff-style patch with
/usr/bin/bk, i made one against 2.6.11.6:
http://nerdbynature.de/bits/hal/2.6.11.6/1.1803.125.6.diff
more info and dmesg under:
http://nerdbynature.de/bits/hal/2.6.11.6/
to summarize: i don't know exactly which changes, but *some* changes had
to be made to arch/ppc/platforms/prep_pci.c to get the network card
working [1] again (network code kept locking up the machine). after this
issue was resolved, i too noticed the scsi errors [2] others were
complaing about.
thanks to all involved,
Christian.
[1] http://ozlabs.org/pipermail/linuxppc-dev/2004-December/017954.html
[2] http://nerdbynature.de/bits/hal/2.6.11-rc5/dmesg
- --
BOFH excuse #307:
emissions from GSM-phones
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCUdW5C/PVm5+NVoYRAnBFAKDWoLrgNglNCIuVNLMZcJXccp7K6QCfSyIp
i4H8VpqUw3e7WiyqpsqYs54=
=WD3X
-----END PGP SIGNATURE-----
^ permalink raw reply
* somewhat OT -- trying to build code on the fly then run it
From: Chris Friesen @ 2005-04-04 23:32 UTC (permalink / raw)
To: linuxppc-dev
I'm writing a testcase to test some code we wrote to allow userspace to
flush the whole dcache and invalidate the whole icache. This requires
me to write self-modifying code. For the first stage I'm just trying to
build a routine (that just increments r3 and returns) on the heap and
then call it.
Everything seems to be fine right up until I jump to the code that I've
written, then I get a segfault. The debugger shows my registers and
data values are as expected, and the page of memory has xwr permissions.
Can anyone tell me what I'm missing? I'm sure its something simple.
Thanks,
Chris.
PS. Here's my current test code.
#include <errno.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <stdio.h>
#include <stdio.h>
#include <sys/mman.h>
/* these next two lines are the hex equivalents of the instructions:
* addi r3,r3,1
* blr
*/
unsigned int incr_code[] = {
0x38630001,
0x4e800020
};
int dotest(unsigned long *addr)
{
int i=0;
asm volatile (" \n\
mr 3,%1 \n\
bla %2 \n\
mr %0,3 \n"
: "=r" (i)
: "r" (i), "r" (addr));
return i;
}
void alter_opcode(unsigned long *addr, unsigned long opcode)
{
unsigned long offset = 0;
asm volatile(
"stw %1,0(%0) \n\t"
"dcbf %0,%2 \n\t"
"sync \n\t"
"icbi %0,%2 \n\t"
"sync \n\t"
"isync \n\t"
:: "r" (addr), "r" (opcode), "r" (offset));
}
int main()
{
unsigned long *addr;
void *p = mmap(0, 4096, PROT_EXEC|PROT_WRITE|PROT_READ,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
if (p == MAP_FAILED) {
perror("mmap");
goto error;
}
addr = (unsigned long *)p;
alter_opcode(addr, incr_code[0]);
alter_opcode(addr+1, incr_code[1]);
printf("%d\n", dotest(addr));
return 0;
error:
return -1;
}
^ permalink raw reply
* Re: linux 2.6.12-rc1-bk5 compilation error
From: Benjamin Herrenschmidt @ 2005-04-04 23:12 UTC (permalink / raw)
To: Jerome Glisse; +Cc: linuxppc-dev list
In-Reply-To: <4240b91605040412117b29d4ca@mail.gmail.com>
On Mon, 2005-04-04 at 20:11 +0100, Jerome Glisse wrote:
> > You should really be using a 64 bits kernel :)
>
> Yes, i should, honte à moi :) btw which distribution
> do you use or recommand for 64bits ? gentoo ? I am
> long time debian user (x86) and i think that this is not the
> best choice for ppc64...
I'm using debian 32 bits and do my own 64 bits toolchain for building
kernels ;)
For toolchain, I recommend Janis scripts at penguinppc64.org (toolchain
section, there is a link to mkbiarch etc... I don't use crosstools).
Ben.
^ permalink raw reply
* 440GP system freezes with jiffies not incrementing?
From: David Adair @ 2005-04-04 20:40 UTC (permalink / raw)
To: linuxppc-embedded
I have a configuration where it appears that I have missed a decrementer
interrupt and the system gets frozen in the idle loop:
Dec: 0 (interrupts on 1->0 transition)
MSR[EE]: 1 (interrupt enabled)
TSR[DIS]: 0 (no interrupt pending)
Since the decrementer interrupt occurs ONLY on the 1->0 transition
I'm not too sure how the system can get out of this state -- in my
particular case the answer is it gets a Watchdog timeout and reboots.
This occurs very rarely running a modified version of 2.4.28_pre3
on a custom board very similar to the Ebony.
I am very curious about the behavior of the code in arch/ppc/time.c
in the case where I manage to miss exactly 1 jiffy - IRQ service time:
int timer_interrupt(struct pt_regs * regs)
{
int next_dec;
unsigned long cpu =3D smp_processor_id();
unsigned jiffy_stamp =3D last_jiffy_stamp(cpu);
extern void do_IRQ(struct pt_regs *);
if (atomic_read(&ppc_n_lost_interrupts) !=3D 0)
do_IRQ(regs);
hardirq_enter(cpu);
while ((next_dec =3D tb_ticks_per_jiffy - tb_delta(&jiffy_stamp))
< 0) {
jiffy_stamp +=3D tb_ticks_per_jiffy;=20
<snip>
}
if ( !disarm_decr[smp_processor_id()] )
set_dec(next_dec);
last_jiffy_stamp(cpu) =3D jiffy_stamp;
}
Seems like the result is to go through the loop once and then program
the decrementer to 0, effectively disabling timer interrupts.
Also curious about exactly where disarm_decr() gets initialized.
I will be adjusting this and testing but it seems really strange
that I have the only setup that manages to hit just the right
timing -- is there someplace else where we would normally recover
from this situation?
Thanks
David
^ permalink raw reply
* Re: linux 2.6.12-rc1-bk5 compilation error
From: Jerome Glisse @ 2005-04-04 19:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1112618509.26086.68.camel@gaston>
> You should really be using a 64 bits kernel :)
Yes, i should, honte =E0 moi :) btw which distribution
do you use or recommand for 64bits ? gentoo ? I am
long time debian user (x86) and i think that this is not the
best choice for ppc64...
Jerome Glisse
^ permalink raw reply
* Re: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
From: Jon Masters @ 2005-04-04 16:56 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: Sylvain Munaut, Linux PPC Embedded list, Jakob Viketoft
In-Reply-To: <42517236.70707@ru.mvista.com>
Andrei Konovalov wrote:
> Wolfgang Denk wrote:
>> Who said this, and where? I am not aware of such a discussion.
> These are just plans:
>
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-April/017561.html
>
> -------- Original Message --------
> Subject: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
> Date: Thu, 31 Mar 2005 09:55:42 -0600
> From: Jon Loeliger <jdl@freescale.com>
>
> <snip>
> Oh, yeah. Um, also on my plate will be to construct the
> original flat-tree blob in U-Boot to be handed to the kernel.
> (I'll start with 85xx and 83xx, naturlich.)
> -------- End Original Message --------
The magic bit will be when we have automatic SYSTEM.MHS -> FlatOF BLOB
on stuff like Virtex. That'll assist in doing away with the HAL :-)
Jon.
^ permalink raw reply
* Re: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
From: Andrei Konovalov @ 2005-04-04 16:58 UTC (permalink / raw)
To: Wolfgang Denk
Cc: Jon Masters, Sylvain Munaut, Linux PPC Embedded list,
Jakob Viketoft
In-Reply-To: <20050404164545.E603CC108D@atlas.denx.de>
Wolfgang Denk wrote:
> In message <42511D55.4040507@ru.mvista.com> you wrote:
>
>>Should we rely on U-Boot to give that device tree structure to
>>the kernel? If I got it correct this is how the Freescale team
>>plans to proceed. Jon (Masters), are you going the same way?
>
>
> Who said this, and where? I am not aware of such a discussion.
These are just plans:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-April/017561.html
-------- Original Message --------
Subject: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
Date: Thu, 31 Mar 2005 09:55:42 -0600
From: Jon Loeliger <jdl@freescale.com>
<snip>
Oh, yeah. Um, also on my plate will be to construct the
original flat-tree blob in U-Boot to be handed to the kernel.
(I'll start with 85xx and 83xx, naturlich.)
-------- End Original Message --------
Thanks,
Andrei
> Best regards,
>
> Wolfgang Denk
>
^ permalink raw reply
* Re: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
From: Wolfgang Denk @ 2005-04-04 16:45 UTC (permalink / raw)
To: Andrei Konovalov
Cc: Jon Masters, Sylvain Munaut, Linux PPC Embedded list,
Jakob Viketoft
In-Reply-To: <42511D55.4040507@ru.mvista.com>
In message <42511D55.4040507@ru.mvista.com> you wrote:
>
> Should we rely on U-Boot to give that device tree structure to
> the kernel? If I got it correct this is how the Freescale team
> plans to proceed. Jon (Masters), are you going the same way?
Who said this, and where? I am not aware of such a discussion.
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
"The best index to a person's character is a) how he treats people
who can't do him any good and b) how he treats people who can't fight
back." - Abigail Van Buren
^ permalink raw reply
* Re: gcc4 compile fixes
From: Dan Kegel @ 2005-04-04 14:10 UTC (permalink / raw)
To: Christian; +Cc: linuxppc-dev
In-Reply-To: <425147C4.10906@gmx.net>
Christian wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> replying to myself:
>
> Christian wrote:
>
>>now it [1] fails with:
>>
>>In file included from arch/ppc/kernel/time.c:68:
>>include/asm/time.h:61: warning: type qualifiers ignored on function return
>>type
>
> [...]
>
> ..and there were other error messages too. not knowing a *bit* of C, i was
> able to do minor alterations which i deduced from gcc's error messages.
> now compiling for ppc604 (PReP) with gcc4 succeeds.
Thanks for the report and the patch.
Parts of that patch look like ones I've already collected at:
http://www.kegel.com/crosstool/crosstool-0.30/patches/linux-2.6.11.3/
Here are the patches I have so far:
kaz-types.patch
linux-2.6.11-allow-gcc-4.0-asm-i386.patch
linux-2.6.11-allow-gcc-4.0-asm-m68k.patch
linux-2.6.11-allow-gcc-4.0-asm-ppc64.patch
linux-2.6.11-allow-gcc-4.0-asm-x86_64.patch
linux-2.6.11-allow-gcc-4.0-i2c.patch
linux-2.6.11-allow-gcc-4.0-ppc-mikpe.patch
In particular,
http://www.kegel.com/crosstool/crosstool-0.30/patches/linux-2.6.11.3/linux-2.6.11-allow-gcc-4.0-ppc-mikpe.patch
covers some of what you found.
Maybe if I apply your first patch, I'll make it all the way through.
Thanks,
Dan
--
Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
^ permalink raw reply
* RE: RE : How to read/write in flash memories (MTD)?
From: Fillod Stephane @ 2005-04-04 14:05 UTC (permalink / raw)
To: Garcia Jérémie; +Cc: linuxppc-dev
Bonjour J=E9r=E9mie,
Your mail is a bit off-topic on the linuxppc-dev list. A better list =
would
be linux-mtd. Check out: http://www.linux-mtd.infradead.org
>Your reply confirmed my feeling. So I've decided to use the MTD but =
with my >own driver as I found in a tutorial. So I made the file =
(module) >/drivers/mtd/maps/myBoardFlash.c in order to support my 2 =
flash memories. >You can see the code below, but once again (sorry...) I =
have some questions >and doubts on it.=20
>1- Is that driver correct for my case?=20
>2- Are those R/W routines are usable?
>3- In our application we want to download source code and achievable =
code >using Ethernet (so R/W operations). Do I need a filesystem for =
that as JFFS2 ?=20
yes, or any other kind of filesystem on top of "MTD block", but this can =
be=20
unreliable. One solution can be also to use raw partitions to store =
data.
>4- Giving this driver, what is the process to use my R/W routines (if =
they >are correct...) from the user space?
To use your R/W routines, you can use "MTD char" support.=20
See fcp.c (from MTD CVS or ftp site) for an example.
Regards
--=20
Stephane
^ permalink raw reply
* Re: gcc4 compile fixes
From: Christian @ 2005-04-04 13:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Dan Kegel
In-Reply-To: <42509DB9.4090609@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
replying to myself:
Christian wrote:
> now it [1] fails with:
>
> In file included from arch/ppc/kernel/time.c:68:
> include/asm/time.h:61: warning: type qualifiers ignored on function return
> type
[...]
..and there were other error messages too. not knowing a *bit* of C, i was
able to do minor alterations which i deduced from gcc's error messages.
now compiling for ppc604 (PReP) with gcc4 succeeds.
thank you for your concern,
Christian.
- --
BOFH excuse #403:
Sysadmin didn't hear pager go off due to loud music from bar-room speakers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCUUfEC/PVm5+NVoYRAiMYAKCVru912jky9ctrnAhBe+ukymReQgCg9z6Y
YSNKwksGyXiDKgxpvGhO1wM=
=WSll
-----END PGP SIGNATURE-----
[-- Attachment #2: 2.6.11.6.gcc4_compile_fixes-take2.diff --]
[-- Type: text/plain, Size: 1770 bytes --]
--- linux-2.6/arch/ppc/syslib/open_pic_defs.h.orig 2005-04-04 15:01:39.581824538 +0200
+++ linux-2.6/arch/ppc/syslib/open_pic_defs.h 2005-04-04 15:01:52.679696972 +0200
@@ -172,7 +172,7 @@
OpenPIC_Processor Processor[OPENPIC_MAX_PROCESSORS];
};
-extern volatile struct OpenPIC __iomem *OpenPIC;
+static volatile struct OpenPIC __iomem *OpenPIC;
/*
--- linux-2.6/arch/ppc/kernel/time.c.orig 2005-04-04 15:12:41.963801575 +0200
+++ linux-2.6/arch/ppc/kernel/time.c 2005-04-04 15:12:56.390559608 +0200
@@ -89,7 +89,7 @@
extern unsigned long wall_jiffies;
-static long time_offset;
+extern long time_offset;
DEFINE_SPINLOCK(rtc_lock);
--- linux-2.6/include/asm-ppc/time.h.orig 2005-04-04 14:47:55.526765569 +0200
+++ linux-2.6/include/asm-ppc/time.h 2005-04-04 14:49:59.075129571 +0200
@@ -58,7 +58,7 @@
/* Accessor functions for the timebase (RTC on 601) registers. */
/* If one day CONFIG_POWER is added just define __USE_RTC as 1 */
#ifdef CONFIG_6xx
-extern __inline__ int const __USE_RTC(void) {
+static __inline__ int const __USE_RTC(void) {
return (mfspr(SPRN_PVR)>>16) == 1;
}
#else
@@ -92,7 +92,7 @@
mtspr(SPRN_TBWL, lower);
}
-extern __inline__ unsigned long get_rtcl(void) {
+static __inline__ unsigned long get_rtcl(void) {
unsigned long rtcl;
asm volatile("mfrtcl %0" : "=r" (rtcl));
return rtcl;
--- linux-2.6/include/asm-ppc/prom.h.orig 2005-04-04 14:56:50.014752710 +0200
+++ linux-2.6/include/asm-ppc/prom.h 2005-04-04 14:59:59.805414063 +0200
@@ -13,8 +13,8 @@
typedef void *phandle;
typedef void *ihandle;
-extern char *prom_display_paths[];
-extern unsigned int prom_num_displays;
+static char *prom_display_paths[];
+static unsigned int prom_num_displays;
struct address_range {
unsigned int space;
^ permalink raw reply
* Re: linux 2.6.12-rc1-bk5 compilation error
From: Benjamin Herrenschmidt @ 2005-04-04 12:41 UTC (permalink / raw)
To: Jerome Glisse; +Cc: linuxppc-dev list
In-Reply-To: <4240b916050404033230db0551@mail.gmail.com>
On Mon, 2005-04-04 at 11:32 +0100, Jerome Glisse wrote:
> Hi,
>
> Once again i face an error that i got with a previous
> 2.6 kernel (i already posted about this in january
> i think).
>
> My config G5 bi 2Ghz and you can grab my kernel
> config here : http://dj.planet-d.net/config
>
> When compiling 2.6.12-rc1-bk5 i first get unknown
> symbol _flush_disable_L1. This is in arch/ppc/kernel/l2cr.S
> I changed the makefile in arch/ppc/kernel to have this :
> obj-$(CONFIG_POWER4) += cpu_setup_power4.o
> into :
> obj-$(CONFIG_POWER4) += l2cr.o cpu_setup_power4.o
>
> .../...
You should really be using a 64 bits kernel :)
Ben.
^ permalink raw reply
* Re: iBook G3 owners
From: Benjamin Herrenschmidt @ 2005-04-04 12:06 UTC (permalink / raw)
To: debian-powerpc@lists.debian.org; +Cc: linuxppc-dev list
In-Reply-To: <1112594783.26086.22.camel@gaston>
> http://gate.crahsing.org/~benh/ppc32-750-errata-fix.diff
> http://gate.crahsing.org/~benh/ppc32-pmac-sleep-fix.diff
> http://gate.crahsing.org/~benh/cpufreq-add-suspend.diff
> http://gate.crahsing.org/~benh/ppc32-cpufreq-gpio-off.diff
Of course, without the typo, it gives:
http://gate.crashing.org/~benh/ppc32-750-errata-fix.diff
http://gate.crashing.org/~benh/ppc32-pmac-sleep-fix.diff
http://gate.crashing.org/~benh/cpufreq-add-suspend.diff
http://gate.crashing.org/~benh/ppc32-cpufreq-gpio-off.diff
^ permalink raw reply
* Re: linux 2.6.12-rc1-bk5 compilation error
From: Jerome Glisse @ 2005-04-04 11:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4240b9160504040351333e0b23@mail.gmail.com>
One more things i can boot with this kernel.
I got a Invalid memory access right after
kernel start...
Jerome Glisse
^ permalink raw reply
* Re: [Fwd: Re: Platform bus/ppc sys model - [Fwd: bi_recs and u-boot ppcboot.h]]
From: Jon Masters @ 2005-04-04 11:14 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20050404081932.B8CD7C108D@atlas.denx.de>
Wolfgang Denk wrote:
> In message <4250ED79.6010304@jonmasters.org> you wrote:
>
>>| The CPCI405 supports switching the boot-cs between its 2 flash chips with the
>>| DIP-switch 4. You could copy the current ppcboot version into the 2nd flash
>>| chip as a fallback (please test it once).
>>
>>Oooh. I didn't know that (don't have the schematics here :P) - cheers.
> BTW: I will attach the BDI2000 to the CPCI405 tomorrow or so, so you
> can continue debugging in our virtual lab, too.
Good. I'll work with the Freescale guys to get somewhere with the OF
stuff - I know you're not so keen on this as the final solution, and I
agree with you, but it looks like there might be sufficient critical
mass here to finally do something about ppc boot records.
>>FWIW Stefan, I am just setting up a similar power cycler setup to what
>>you guys have there - found a cheap supplier of wireless 13A mains
>>socket automation kits (<15EUR) in the local electronics store,
>>butchered remote control unit, sufficient for a cheapo cycler.
> Can you please send me some more details?
I bought one of these yesterday:
http://www.maplin.co.uk/Module.aspx?ModuleNo=-10523&TabID=1&source=15&WorldID=&doy=4m4
The remote control is trivially butchered and the buttons replaced with
NPN transistors running off a PIC16F628 (well it will be by tonight).
I've got a MAX233 doing RS232 to a PC for another project so am just
reusing the comms to allow remote on/off control of 4-16 devices.
Jon.
^ permalink raw reply
* Re: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
From: Jakob Viketoft @ 2005-04-04 11:08 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: Jon Masters, Sylvain Munaut, Linux PPC Embedded list
In-Reply-To: <42511D55.4040507@ru.mvista.com>
Hello Andrei!
Andrei Konovalov wrote:
> Hi Jakob!
>
> Yes, Jon Loeliger's implementation plan looks OK for me
> (as far as I understood Jon's posting; having look at
> the current patch would be great). And I could participate
> in the implementation for Xilinx if needed too, but don't
> object if you do it by yourself (at the moment, I know
> little about the OF device tree, so just testing the patch
> on ML300 would be fine for me as well).
Great! I could start and ask for assistance when needed... :)
> Should we rely on U-Boot to give that device tree structure to
> the kernel? If I got it correct this is how the Freescale team
> plans to proceed. Jon (Masters), are you going the same way?
> Anyone using arch/ppc/boot/simple bootwrapper with his Virtex 2 Pro
> board? If we drop Virtex 2 Pro support in arch/ppc/boot and move to
> U-Boot would it hurt anyone?
>
> Thanks,
> Andrei
My end intention is to write something that both builds the OF device
tree from a listed number of (ip-)devices and a small FPGA-suitable
bootloader (as a small prog separated from the kernel). It'll probably
end up being an entire "Linux on Xilinx" howto... I say we can drop the
simple bootwrapper once all the stages of the OF adaptation is in place
(which might not happen overnight :).
Cheers!
/Jakob
>
> Jakob Viketoft wrote:
>
>> Hi!
>>
>> You don't happen to have a patch of your current work against one of
>> the trees (83xx and 85xx)? It would be much easier to do work in
>> parallell, and I'd be happy to do it on the "Xilinx" tree (and help
>> out where I can, of course).
>>
>> Jon Masters and Andrei: Does Jon Loeliger's implementation plan sound
>> alright to you? Since you seem quite full-handed on your end anyway,
>> Jon, I'll be happy to do the work needed unless anyone has any
>> objections...
>>
>> Cheers!
>>
>> /Jakob
>>
>> Jon Loeliger wrote:
>>
>>> On Thu, 2005-03-31 at 06:33, Jon Masters wrote:
>>>
>>>> Kumar Gala wrote:
>>>>
>>>> |> My intention was to give a device tree structure to the kernel at
>>>> boot
>>>> |> time via a (pseudo?) pointer in bd_info or similar.
>>>
>>>
>>>
>>>
>>>> This got resurrected recently.
>>>
>>>
>>>
>>>
>>> Hi!
>>>
>>>
>>>> | I think this is reasonable. The best device tree would be a
>>>> flattened
>>>> | OF tree since we are trying to move the world in that direction. Jon
>>>> | Masters around?
>>>>
>>>> Yes, but I've been tied up with worky and magazine stuff again. If
>>>> someone wants to work with me then this might actually happen.
>>>
>>>
>>>
>>>
>>> Hi Jon,
>>>
>>> I'm here and actively(!) working on it now. Here is the very
>>> rough plan as Kumar and I have discussed it. Please feel free
>>> to comment on it or offer suggestions. Ben has suggested that
>>> I start with the "second step" below. I'd like to do a round
>>> of cleanup first.
>>>
>>> So far, I have taken the first step of isolating the references
>>> to the global __res[] variable into one file and replacing all
>>> references to the data in the bd_t structure with a thin, shim
>>> layer of function calls that are nominally into an OF-like
>>> interface. I have done this for all the 85xx and 83xx boards
>>> in my development tree, and am working on the others now.
>>> This step effectively isolates the __res[] references to one
>>> file where a well defined interface can be created to pose as
>>> an OF Device Tree layer (briefly).
>>>
>>> As a follow-up second step, I plan on introducing essentially
>>> the same code currently in ppc64 to handle the flat device tree
>>> and provide an interface to that data in exactly the same manner
>>> as the ppc64 currently has. I understand the desire to have the
>>> flat-tree handling be "outside the kernel".
>>>
>>> As a third step, the shim layer will be rewritten/augmented to
>>> use the actual OF device tree data where it currently fronts
>>> for the bd_t data.
>>>
>>> Finally, as time permits and maintainers allow (read: prod),
>>> the other (not 85xx, not 83xx) boards can have their setup code
>>> converted to use the "real" OF device tree function calls.
>>>
>>> When all of that is done, the shim layer can be removed, as needed.
>>>
>>>
>>> Oh, yeah. Um, also on my plate will be to construct the
>>> original flat-tree blob in U-Boot to be handed to the kernel.
>>> (I'll start with 85xx and 83xx, naturlich.)
>>>
>>> We have not yet decided on the layout of that tree to determine
>>> where all the attributes and devices really belong. I will
>>> also discuss with Wolfgang and crew how to generate that tree
>>> over in U-Boot land.
>>>
>>> Right?
>>>
>>> Thanks,
>>> jdl
>>>
>>
>>
>
^ permalink raw reply
* Re: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
From: Jon Masters @ 2005-04-04 11:01 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: Linux PPC Embedded list, Sylvain Munaut, Jakob Viketoft
In-Reply-To: <42511D55.4040507@ru.mvista.com>
Andrei Konovalov wrote:
> Should we rely on U-Boot to give that device tree structure to
> the kernel?
I think this is the best way to do it - there's already a ppc_md struct
kicking around which is semi-meant for this kind of thing.
> If I got it correct this is how the Freescale team plans to proceed.
Good. It might actually happen if enough of us want it to :-)
> Jon (Masters), are you going the same way?
Yes, but I'm more than willing to pitch in with the Freescale guys if
that'll get things done faster - they've obviously got more manpower. I
wanted to get this thing done already! :-)
> Anyone using arch/ppc/boot/simple bootwrapper with his Virtex 2 Pro
> board? If we drop Virtex 2 Pro support in arch/ppc/boot and move to
> U-Boot would it hurt anyone?
I don't use it. I have a very simple bootloader which I use on our Memec
based design - comes in straight off sysace and jumps at the kernel
after doing simple diagnostics, avoided the need for porting an existing
boot loader and it's reasonably able to cope with braindead Xilinx HALs.
Jon.
^ permalink raw reply
* Re: linux 2.6.12-rc1-bk5 compilation error
From: Jerome Glisse @ 2005-04-04 10:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4240b916050404033230db0551@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 134 bytes --]
I send the wrong patch (old one) and with paste & cute error.
Here is a good one.
Signed-off-by: Jerome Glisse <j.glisse@gmail.com>
[-- Attachment #2: patch-6xx --]
[-- Type: application/octet-stream, Size: 570 bytes --]
diff -Nru a/arch/ppc/boot/simple/misc-prep.c b/arch/ppc/boot/simple/misc-prep.c
--- a/arch/ppc/boot/simple/misc-prep.c 2005-04-04 10:41:25.766786800 +0200
+++ b/arch/ppc/boot/simple/misc-prep.c 2005-04-04 10:47:23.185450904 +0200
@@ -34,7 +34,11 @@
extern void serial_fixups(void);
extern struct bi_record *decompress_kernel(unsigned long load_addr,
int num_words, unsigned long cksum);
+#ifdef CONFIG_6XX
extern void disable_6xx_mmu(void);
+#else
+static inline void disable_6xx_mmu(void){}
+#endif
extern unsigned long mpc10x_get_mem_size(void);
static void
^ permalink raw reply
* Re: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
From: Andrei Konovalov @ 2005-04-04 10:56 UTC (permalink / raw)
To: Jakob Viketoft; +Cc: Jon Masters, Sylvain Munaut, Linux PPC Embedded list
In-Reply-To: <4250EACF.1040403@bitsim.se>
Hi Jakob!
Yes, Jon Loeliger's implementation plan looks OK for me
(as far as I understood Jon's posting; having look at
the current patch would be great). And I could participate
in the implementation for Xilinx if needed too, but don't
object if you do it by yourself (at the moment, I know
little about the OF device tree, so just testing the patch
on ML300 would be fine for me as well).
Should we rely on U-Boot to give that device tree structure to
the kernel? If I got it correct this is how the Freescale team
plans to proceed. Jon (Masters), are you going the same way?
Anyone using arch/ppc/boot/simple bootwrapper with his Virtex 2 Pro
board? If we drop Virtex 2 Pro support in arch/ppc/boot and move to
U-Boot would it hurt anyone?
Thanks,
Andrei
Jakob Viketoft wrote:
> Hi!
>
> You don't happen to have a patch of your current work against one of the
> trees (83xx and 85xx)? It would be much easier to do work in parallell,
> and I'd be happy to do it on the "Xilinx" tree (and help out where I
> can, of course).
>
> Jon Masters and Andrei: Does Jon Loeliger's implementation plan sound
> alright to you? Since you seem quite full-handed on your end anyway,
> Jon, I'll be happy to do the work needed unless anyone has any
> objections...
>
> Cheers!
>
> /Jakob
>
> Jon Loeliger wrote:
>
>> On Thu, 2005-03-31 at 06:33, Jon Masters wrote:
>>
>>> Kumar Gala wrote:
>>>
>>> |> My intention was to give a device tree structure to the kernel at
>>> boot
>>> |> time via a (pseudo?) pointer in bd_info or similar.
>>
>>
>>
>>> This got resurrected recently.
>>
>>
>>
>> Hi!
>>
>>
>>> | I think this is reasonable. The best device tree would be a flattened
>>> | OF tree since we are trying to move the world in that direction. Jon
>>> | Masters around?
>>>
>>> Yes, but I've been tied up with worky and magazine stuff again. If
>>> someone wants to work with me then this might actually happen.
>>
>>
>>
>> Hi Jon,
>>
>> I'm here and actively(!) working on it now. Here is the very
>> rough plan as Kumar and I have discussed it. Please feel free
>> to comment on it or offer suggestions. Ben has suggested that
>> I start with the "second step" below. I'd like to do a round
>> of cleanup first.
>>
>> So far, I have taken the first step of isolating the references
>> to the global __res[] variable into one file and replacing all
>> references to the data in the bd_t structure with a thin, shim
>> layer of function calls that are nominally into an OF-like
>> interface. I have done this for all the 85xx and 83xx boards
>> in my development tree, and am working on the others now.
>> This step effectively isolates the __res[] references to one
>> file where a well defined interface can be created to pose as
>> an OF Device Tree layer (briefly).
>>
>> As a follow-up second step, I plan on introducing essentially
>> the same code currently in ppc64 to handle the flat device tree
>> and provide an interface to that data in exactly the same manner
>> as the ppc64 currently has. I understand the desire to have the
>> flat-tree handling be "outside the kernel".
>>
>> As a third step, the shim layer will be rewritten/augmented to
>> use the actual OF device tree data where it currently fronts
>> for the bd_t data.
>>
>> Finally, as time permits and maintainers allow (read: prod),
>> the other (not 85xx, not 83xx) boards can have their setup code
>> converted to use the "real" OF device tree function calls.
>>
>> When all of that is done, the shim layer can be removed, as needed.
>>
>>
>> Oh, yeah. Um, also on my plate will be to construct the
>> original flat-tree blob in U-Boot to be handed to the kernel.
>> (I'll start with 85xx and 83xx, naturlich.)
>>
>> We have not yet decided on the layout of that tree to determine
>> where all the attributes and devices really belong. I will
>> also discuss with Wolfgang and crew how to generate that tree
>> over in U-Boot land.
>>
>> Right?
>>
>> Thanks,
>> jdl
>>
>
>
^ 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