From: Dave Kleikamp <hidden> Date: 2011-02-01 18:49:15
Allow the early debug uart address to be overridden from the kernel
command line.
I would have preferred use the uart's virtual-reg property, but the device
tree hasn't been unflatted yet, and I don't know a reliable way to find it.
Signed-off-by: Dave Kleikamp <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Josh Boyer <redacted>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/udbg_16550.c | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
From: Dave Kleikamp <hidden> Date: 2011-02-01 18:49:17
so that it can use information from the device tree.
Signed-off-by: Dave Kleikamp <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Josh Boyer <redacted>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/setup_32.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
@@ -120,12 +120,12 @@ notrace void __init machine_init(unsigned long dt_ptr){lockdep_init();-/* Enable early debugging if any specified (see udbg.h) */-udbg_early_init();-/* Do some early initialization based on the flat device tree */early_init_devtree(__va(dt_ptr));+/* Enable early debugging if any specified (see udbg.h) */+udbg_early_init();+probe_machine();setup_kdump_trampoline();
@@ -3,8 +3,8 @@ CONFIG_SMP=y CONFIG_EXPERIMENTAL=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y+CONFIG_SPARSE_IRQ=y CONFIG_LOG_BUF_SHIFT=14-CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_BLK_DEV_INITRD=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_EXPERT=y
@@ -21,10 +21,11 @@ CONFIG_ISS4xx=y CONFIG_HZ_100=y CONFIG_MATH_EMULATION=y CONFIG_IRQ_ALL_CPUS=y-CONFIG_SPARSE_IRQ=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="root=/dev/issblk0" # CONFIG_PCI is not set+CONFIG_ADVANCED_OPTIONS=y+CONFIG_RELOCATABLE=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y
@@ -67,7 +68,6 @@ CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y-CONFIG_INOTIFY=y CONFIG_PROC_KCORE=y CONFIG_TMPFS=y CONFIG_CRAMFS=y
@@ -186,10 +186,11 @@ void __init MMU_init_hw(void)unsignedlong__initmmu_mapin_ram(unsignedlongtop){unsignedlongaddr;+unsignedlongmemstart=memstart_addr&~(PPC_PIN_SIZE-1);/* Pin in enough TLBs to cover any lowmem not covered by the*initial256Mmappingestablishedinhead_44x.S*/-for(addr=PPC_PIN_SIZE;addr<lowmem_end_addr;+for(addr=memstart+PPC_PIN_SIZE;addr<lowmem_end_addr;addr+=PPC_PIN_SIZE){if(mmu_has_feature(MMU_FTR_TYPE_47x))ppc47x_pin_tlb(addr+PAGE_OFFSET,addr);
@@ -218,19 +219,25 @@ unsigned long __init mmu_mapin_ram(unsigned long top)voidsetup_initial_memory_limit(phys_addr_tfirst_memblock_base,phys_addr_tfirst_memblock_size){+u64size;++#ifndef CONFIG_RELOCATABLE/* We don't currently support the first MEMBLOCK not mapping 0*physicalonthoseprocessors*/BUG_ON(first_memblock_base!=0);+#endif/* 44x has a 256M TLB entry pinned at boot */-memblock_set_current_limit(min_t(u64,first_memblock_size,PPC_PIN_SIZE));+size=(min_t(u64,first_memblock_size,PPC_PIN_SIZE));+memblock_set_current_limit(first_memblock_base+size);}#ifdef CONFIG_SMPvoid__cpuinitmmu_init_secondary(intcpu){unsignedlongaddr;+unsignedlongmemstart=memstart_addr&~(PPC_PIN_SIZE-1);/* Pin in enough TLBs to cover any lowmem not covered by the*initial256Mmappingestablishedinhead_44x.S
@@ -0,0 +1,119 @@+/*+*DeviceTreeSourceforIBMEmbeddedPPC476Platform+*+*Copyright2010TorezSmith,IBMCorporation.+*+*Basedonearliercode:+*Copyright(c)2006,2007IBMCorp.+*JoshBoyer<jwboyer@linux.vnet.ibm.com>,DavidGibson<dwg@au1.ibm.com>+*+*ThisfileislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2.Thisprogramislicensed"as is"without+*anywarrantyofanykind,whetherexpressorimplied.+*/++/dts-v1/;++/memreserve/0x01f00000 0x00100000;++/{+#address-cells=<2>;+#size-cells=<1>;+model="ibm,iss-4xx";+compatible="ibm,iss-4xx","ibm,47x-AMP";+dcr-parent=<&{/cpus/cpu@0}>;++aliases{+serial0=&UART0;+};++cpus{+#address-cells=<1>;+#size-cells=<0>;++cpu@0{+device_type="cpu";+model="PowerPC,4xx";// real CPU changed in sim+reg=<0>;+clock-frequency=<100000000>;// 100Mhz :-)+timebase-frequency=<100000000>;+i-cache-line-size=<32>;+d-cache-line-size=<32>;+i-cache-size=<32768>;+d-cache-size=<32768>;+dcr-controller;+dcr-access-method="native";+status="ok";+};+cpu@1{+device_type="cpu";+model="PowerPC,4xx";// real CPU changed in sim+reg=<1>;+clock-frequency=<100000000>;// 100Mhz :-)+timebase-frequency=<100000000>;+i-cache-line-size=<32>;+d-cache-line-size=<32>;+i-cache-size=<32768>;+d-cache-size=<32768>;+dcr-controller;+dcr-access-method="native";+status="disabled";+enable-method="spin-table";+cpu-release-addr=<00x01f00100>;+};+};++memory{+device_type="memory";+reg=<0x000000000x000000000x02000000>;++};++MPIC:interrupt-controller{+compatible="chrp,open-pic";+interrupt-controller;+dcr-reg=<0xffc000000x00030000>;+#address-cells=<0>;+#size-cells=<0>;+#interrupt-cells=<2>;++};++plb{+compatible="ibm,plb-4xx","ibm,plb4";/* Could be PLB6, doesn't matter */+#address-cells=<2>;+#size-cells=<1>;+ranges;+clock-frequency=<0>;// Filled in by zImage++POB0:opb{+compatible="ibm,opb-4xx","ibm,opb";+#address-cells=<1>;+#size-cells=<1>;+/* Wish there was a nicer way of specifying a full 32-bit+range*/+ranges=<0x000000000x000000010x000000000x80000000+0x800000000x000000010x800000000x80000000>;+clock-frequency=<0>;// Filled in by zImage+UART0:serial@40000200{+device_type="serial";+compatible="ns16550a";+reg=<0x400002000x00000008>;+virtual-reg=<0xe0000200>;+clock-frequency=<11059200>;+current-speed=<115200>;+interrupt-parent=<&MPIC>;+interrupts=<0x00x2>;+};+};+};++nvrtc{+compatible="ds1743-nvram","ds1743","rtc-ds1743";+reg=<00xEF7030000x2000>;+};++chosen{+linux,stdout-path="/plb/opb/serial@40000200";+};+};
@@ -0,0 +1,120 @@+/*+*DeviceTreeSourceforIBMEmbeddedPPC476Platform+*+*Copyright2010TorezSmith,IBMCorporation.+*+*Basedonearliercode:+*Copyright(c)2006,2007IBMCorp.+*JoshBoyer<jwboyer@linux.vnet.ibm.com>,DavidGibson<dwg@au1.ibm.com>+*+*ThisfileislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2.Thisprogramislicensed"as is"without+*anywarrantyofanykind,whetherexpressorimplied.+*/++/dts-v1/;++/memreserve/0x11f00000 0x00100000;++/{+#address-cells=<2>;+#size-cells=<1>;+model="ibm,iss-4xx";+compatible="ibm,iss-4xx","ibm,47x-AMP";+dcr-parent=<&{/cpus/cpu@2}>;++aliases{+serial0=&UART0;+};++cpus{+#address-cells=<1>;+#size-cells=<0>;++cpu@2{+device_type="cpu";+model="PowerPC,4xx";// real CPU changed in sim+reg=<2>;+clock-frequency=<100000000>;// 100Mhz :-)+timebase-frequency=<100000000>;+i-cache-line-size=<32>;+d-cache-line-size=<32>;+i-cache-size=<32768>;+d-cache-size=<32768>;+dcr-controller;+dcr-access-method="native";+status="ok";+};+cpu@3{+device_type="cpu";+model="PowerPC,4xx";// real CPU changed in sim+reg=<3>;+clock-frequency=<100000000>;// 100Mhz :-)+timebase-frequency=<100000000>;+i-cache-line-size=<32>;+d-cache-line-size=<32>;+i-cache-size=<32768>;+d-cache-size=<32768>;+dcr-controller;+dcr-access-method="native";+status="disabled";+enable-method="spin-table";+cpu-release-addr=<00x11f00300>;+};+};++memory{+device_type="memory";+reg=<0x00x100000000x02000000>;++};++MPIC:interrupt-controller{+compatible="chrp,open-pic";+interrupt-controller;+dcr-reg=<0xffc000000x00030000>;+#address-cells=<0>;+#size-cells=<0>;+#interrupt-cells=<2>;++};++plb{+compatible="ibm,plb-4xx","ibm,plb4";/* Could be PLB6, doesn't matter */+#address-cells=<2>;+#size-cells=<1>;+ranges;+clock-frequency=<0>;// Filled in by zImage++POB0:opb{+compatible="ibm,opb-4xx","ibm,opb";+#address-cells=<1>;+#size-cells=<1>;+/* Wish there was a nicer way of specifying a full 32-bit+range*/+ranges=<0x000000000x000000010x000000000x80000000+0x800000000x000000010x800000000x80000000>;+clock-frequency=<0>;// Filled in by zImage+UART0:serial@40001200{+device_type="serial";+compatible="ns16550a";+reg=<0x400012000x00000008>;+virtual-reg=<0xe0001200>;+clock-frequency=<11059200>;+current-speed=<115200>;+interrupt-parent=<&MPIC>;+interrupts=<0x10x2>;+};+};+};++nvrtc{+compatible="ds1743-nvram","ds1743","rtc-ds1743";+reg=<00xEF7030000x2000>;+};++chosen{+bootargs="uart_addr=0xf0001200";+linux,stdout-path="/plb/opb/serial@40001200";+};+};
From: Dave Kleikamp <hidden> Date: 2011-02-01 18:49:22
For AMP, different kernel instances load into separate memory regions.
Read the start of memory from the device tree and limit the memory to what's
specified in the device tree.
Signed-off-by: Dave Kleikamp <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Josh Boyer <redacted>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/boot/treeboot-iss4xx.c | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
@@ -34,9 +34,28 @@BSS_STACK(4096);+staticibm4xx_memstart;+staticvoidiss_4xx_fixups(void){-ibm4xx_sdram_fixup_memsize();+void*memory;+u32reg[3];++memory=finddevice("/memory");+if(!memory)+fatal("Can't find memory node\n");+getprop(memory,"reg",reg,sizeof(reg));+if(reg[1]||reg[2])+/* If the device tree specifies the memory range, use it */+ibm4xx_memstart=reg[1];+else+/* othersize, read it from the SDRAM controller */+ibm4xx_sdram_fixup_memsize();+}++staticvoid*iss_4xx_vmlinux_alloc(unsignedlongsize)+{+returnibm4xx_memstart;}#define SPRN_PIR 0x11E /* Processor Indentification Register */
From: Dave Kleikamp <hidden> Date: 2011-02-01 18:49:34
Since other OS's may be running on the other cores don't use tlbivax
Signed-off-by: Dave Kleikamp <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Josh Boyer <redacted>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/mmu.h | 2 +-
arch/powerpc/kernel/setup_32.c | 2 ++
arch/powerpc/mm/tlb_nohash.c | 21 ++++++++++++++++++++-
3 files changed, 23 insertions(+), 2 deletions(-)
@@ -126,6 +126,8 @@ notrace void __init machine_init(unsigned long dt_ptr)/* Enable early debugging if any specified (see udbg.h) */udbg_early_init();+early_init_mmu();+probe_machine();setup_kdump_trampoline();
@@ -232,7 +244,7 @@ void __flush_tlb_page(struct mm_struct *mm, unsigned long vmaddr,cpu_mask=mm_cpumask(mm);if(!mm_is_core_local(mm)){/* If broadcast tlbivax is supported, use it */-if(mmu_has_feature(MMU_FTR_USE_TLBIVAX_BCAST)){+if(!amp&&mmu_has_feature(MMU_FTR_USE_TLBIVAX_BCAST)){intlock=mmu_has_feature(MMU_FTR_LOCK_BCAST_INVAL);if(lock)raw_spin_lock(&tlbivax_lock);
From: Scott Wood <hidden> Date: 2011-02-01 19:14:20
On Tue, 1 Feb 2011 12:48:45 -0600
Dave Kleikamp [off-list ref] wrote:
quoted hunk
For AMP, different kernel instances load into separate memory regions.
Read the start of memory from the device tree and limit the memory to what's
specified in the device tree.
Signed-off-by: Dave Kleikamp <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Josh Boyer <redacted>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/boot/treeboot-iss4xx.c | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
From: Dave Kleikamp <hidden> Date: 2011-02-01 19:41:18
On Tue, 2011-02-01 at 13:13 -0600, Scott Wood wrote:
On Tue, 1 Feb 2011 12:48:45 -0600
Dave Kleikamp [off-list ref] wrote:
quoted
For AMP, different kernel instances load into separate memory regions.
Read the start of memory from the device tree and limit the memory to what's
specified in the device tree.
Signed-off-by: Dave Kleikamp <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Josh Boyer <redacted>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/boot/treeboot-iss4xx.c | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
You can use a string reference here:
linux,stdout-path = &UART0;
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: David Gibson <hidden> Date: 2011-02-02 23:06:43
On Tue, Feb 01, 2011 at 12:48:41PM -0600, Dave Kleikamp wrote:
so that it can use information from the device tree.
Hrm. On the other hand this means that the early_init_devtree() code
can't benefit from hardcoded early debugging. Since you don't
actually appear to use devtree information in udbg_early_init() in the
latest series, I'd suggest dropping this patch.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: David Gibson <hidden> Date: 2011-02-02 23:08:44
On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
Since other OS's may be running on the other cores don't use tlbivax
[snip]
quoted hunk
+#ifdef CONFIG_44x+void __init early_init_mmu_44x(void)+{+ unsigned long root = of_get_flat_dt_root();+ if (of_flat_dt_is_compatible(root, "ibm,47x-AMP"))+ amp = 1;+}+#endif /* CONFIG_44x */
A test against a hardcoded compatible string seems a nasty way to do
this. Maybe we should define a new boolean property for the root
node.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Dave Kleikamp <hidden> Date: 2011-02-02 23:54:05
On Thu, 2011-02-03 at 10:08 +1100, David Gibson wrote:
On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
quoted
Since other OS's may be running on the other cores don't use tlbivax
[snip]
quoted
+#ifdef CONFIG_44x+void __init early_init_mmu_44x(void)+{+ unsigned long root = of_get_flat_dt_root();+ if (of_flat_dt_is_compatible(root, "ibm,47x-AMP"))+ amp = 1;+}+#endif /* CONFIG_44x */
A test against a hardcoded compatible string seems a nasty way to do
this. Maybe we should define a new boolean property for the root
node.
I'm not crazy about this string, but I needed something in the device
tree to key off of. Freescale has something similar (i.e.
MPC8572DS-CAMP), so I chose to follow their example. I'd be happy to
replace it with a boolean property. Any objection to just using "amp"?
Thanks,
Shaggy
--
Dave Kleikamp
IBM Linux Technology Center
From: Dave Kleikamp <hidden> Date: 2011-02-03 00:00:31
On Thu, 2011-02-03 at 10:06 +1100, David Gibson wrote:
On Tue, Feb 01, 2011 at 12:48:41PM -0600, Dave Kleikamp wrote:
quoted
so that it can use information from the device tree.
Hrm. On the other hand this means that the early_init_devtree() code
can't benefit from hardcoded early debugging. Since you don't
actually appear to use devtree information in udbg_early_init() in the
latest series, I'd suggest dropping this patch.
Patch 2 depends on early_init_devtree() being run. Until then, I don't
know of a way to get at the bootargs.
--
Dave Kleikamp
IBM Linux Technology Center
From: David Gibson <hidden> Date: 2011-02-03 05:03:51
On Wed, Feb 02, 2011 at 05:53:59PM -0600, Dave Kleikamp wrote:
On Thu, 2011-02-03 at 10:08 +1100, David Gibson wrote:
quoted
On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
quoted
Since other OS's may be running on the other cores don't use tlbivax
[snip]
quoted
+#ifdef CONFIG_44x+void __init early_init_mmu_44x(void)+{+ unsigned long root = of_get_flat_dt_root();+ if (of_flat_dt_is_compatible(root, "ibm,47x-AMP"))+ amp = 1;+}+#endif /* CONFIG_44x */
A test against a hardcoded compatible string seems a nasty way to do
this. Maybe we should define a new boolean property for the root
node.
I'm not crazy about this string, but I needed something in the device
tree to key off of. Freescale has something similar (i.e.
MPC8572DS-CAMP), so I chose to follow their example. I'd be happy to
replace it with a boolean property. Any objection to just using
"amp"?
Bit too short, I think. I'd suggest either spelling out
'asymmetric-multiprocessor' or 'cooperative-partition' (a more
accurate term, IMO).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Dave Kleikamp <hidden> Date: 2011-02-03 23:16:04
On Thu, 2011-02-03 at 16:03 +1100, David Gibson wrote:
On Wed, Feb 02, 2011 at 05:53:59PM -0600, Dave Kleikamp wrote:
quoted
On Thu, 2011-02-03 at 10:08 +1100, David Gibson wrote:
quoted
On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
quoted
Since other OS's may be running on the other cores don't use tlbivax
[snip]
quoted
+#ifdef CONFIG_44x+void __init early_init_mmu_44x(void)+{+ unsigned long root = of_get_flat_dt_root();+ if (of_flat_dt_is_compatible(root, "ibm,47x-AMP"))+ amp = 1;+}+#endif /* CONFIG_44x */
A test against a hardcoded compatible string seems a nasty way to do
this. Maybe we should define a new boolean property for the root
node.
I'm not crazy about this string, but I needed something in the device
tree to key off of. Freescale has something similar (i.e.
MPC8572DS-CAMP), so I chose to follow their example. I'd be happy to
replace it with a boolean property. Any objection to just using
"amp"?
Bit too short, I think. I'd suggest either spelling out
'asymmetric-multiprocessor' or 'cooperative-partition' (a more
accurate term, IMO).
I could be wrong, but I thought the A stands for Asynchronous, not
Asymmetric. I thought Asymmetric means that different types of tasks
run on the secondary processors, as on the Cell. Anyway, going with
'cooperative-partition' would avoid that confusion.
Shaggy
--
Dave Kleikamp
IBM Linux Technology Center
From: Timur Tabi <hidden> Date: 2011-02-04 02:23:02
On Thu, Feb 3, 2011 at 5:15 PM, Dave Kleikamp [off-list ref] w=
rote:
quoted
Bit too short, I think. =A0I'd suggest either spelling out
'asymmetric-multiprocessor' or 'cooperative-partition' (a more
accurate term, IMO).
I could be wrong, but I thought the A stands for Asynchronous, not
Asymmetric. =A0I thought Asymmetric means that different types of tasks
run on the secondary processors, as on the Cell. =A0Anyway, going with
'cooperative-partition' would avoid that confusion.
Well, if we pretend that everyone already knows what the "A" stands
for, that's not going to avoid confusion. Some people still are going
to be wrong. It would be great if we could settle the matter once and
for all.
I've always thought the A stood for asymmetric, since you're running
multiple cores, but each OS is not aware of the others. It doesn't
necessarily have to be two copies of Linux. In fact, it usually
isn't.
As for "MPC8572DS-CAMP", I've always hated that. A specific property
that defines an AMP environment is a much better idea.
--=20
Timur Tabi
Linux kernel developer at Freescale
Something aside from the property thing sits weirdly with me on this as
well.
We have this guarded by CONFIG_44x but also CONFIG_SMP, and we're doing
476 specific checks (for now). There is at least one 44x board that has
dual-CPUs (AMCC Arches, iirc) that can theoretically be run in AMP mode.
However, it won't be using an SMP kernel because it's a single core per CPU.
Admittedly I don't think it supports the tlbivax instruction either so
the patch as it stands doesn't impact that theoretical scenario much.
I do wonder if we really need to guard the call to this behind
CONFIG_SMP though. Maybe a slight performance increase I suppose, but
if we wind up using the AMP check elsewhere then it might be needed
anyway. Something to think about.
Oh, and I agree 'cooperative-partition' or something would be a better
check.
josh
Something aside from the property thing sits weirdly with me on this as
well.
We have this guarded by CONFIG_44x but also CONFIG_SMP, and we're doing
476 specific checks (for now). There is at least one 44x board that has
dual-CPUs (AMCC Arches, iirc) that can theoretically be run in AMP mode.
However, it won't be using an SMP kernel because it's a single core per CPU.
Admittedly I don't think it supports the tlbivax instruction either so
the patch as it stands doesn't impact that theoretical scenario much.
I should have used CONFIG_PPC_47x here.
I do wonder if we really need to guard the call to this behind
CONFIG_SMP though. Maybe a slight performance increase I suppose, but
if we wind up using the AMP check elsewhere then it might be needed
anyway. Something to think about.
I agree that it's awkward. The code affected by this is all behind
CONFIG_SMP. There's no reason to use tlbivax, or the alternate ipi, in
a uni kernel. An alternative would be to define early_init_mmu_44x (or
47x) outside of CONFIG_SMP, but the contents of the function would still
be inside CONFIG_SMP, and it would be an empty function otherwise.
Oh, and I agree 'cooperative-partition' or something would be a better
check.
From: David Gibson <hidden> Date: 2011-02-07 08:29:34
On Wed, Feb 02, 2011 at 06:00:25PM -0600, Dave Kleikamp wrote:
On Thu, 2011-02-03 at 10:06 +1100, David Gibson wrote:
quoted
On Tue, Feb 01, 2011 at 12:48:41PM -0600, Dave Kleikamp wrote:
quoted
so that it can use information from the device tree.
Hrm. On the other hand this means that the early_init_devtree() code
can't benefit from hardcoded early debugging. Since you don't
actually appear to use devtree information in udbg_early_init() in the
latest series, I'd suggest dropping this patch.
Patch 2 depends on early_init_devtree() being run. Until then, I don't
know of a way to get at the bootargs.
Ah, yes. Drat.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: David Gibson <hidden> Date: 2011-02-07 08:30:53
On Thu, Feb 03, 2011 at 05:15:57PM -0600, Dave Kleikamp wrote:
On Thu, 2011-02-03 at 16:03 +1100, David Gibson wrote:
quoted
On Wed, Feb 02, 2011 at 05:53:59PM -0600, Dave Kleikamp wrote:
quoted
On Thu, 2011-02-03 at 10:08 +1100, David Gibson wrote:
quoted
On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
quoted
Since other OS's may be running on the other cores don't use tlbivax
[snip]
quoted
+#ifdef CONFIG_44x+void __init early_init_mmu_44x(void)+{+ unsigned long root = of_get_flat_dt_root();+ if (of_flat_dt_is_compatible(root, "ibm,47x-AMP"))+ amp = 1;+}+#endif /* CONFIG_44x */
A test against a hardcoded compatible string seems a nasty way to do
this. Maybe we should define a new boolean property for the root
node.
I'm not crazy about this string, but I needed something in the device
tree to key off of. Freescale has something similar (i.e.
MPC8572DS-CAMP), so I chose to follow their example. I'd be happy to
replace it with a boolean property. Any objection to just using
"amp"?
Bit too short, I think. I'd suggest either spelling out
'asymmetric-multiprocessor' or 'cooperative-partition' (a more
accurate term, IMO).
I could be wrong, but I thought the A stands for Asynchronous, not
Asymmetric. I thought Asymmetric means that different types of tasks
run on the secondary processors, as on the Cell.
Yeah, I thought so too, but Freescale at least seem to use it this
way. 'Asynchronous' would make even less sense.
Anyway, going with
'cooperative-partition' would avoid that confusion.
Shaggy
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Dave Kleikamp <hidden> Date: 2011-02-09 23:05:13
On Wed, 2011-02-02 at 13:43 +1100, David Gibson wrote:
On Tue, Feb 01, 2011 at 12:48:46PM -0600, Dave Kleikamp wrote:
quoted
These are completely independent OS instances, each running on 2
cores.
[snip]
quoted
+/memreserve/ 0x01f00000 0x00100000;
A comment describing what this reserved section is for would be good.
I with I knew what it was for. I've blindly carried it along for a
while. Removing it doesn't appear to do any harm. Ben, any idea why
this was ever in here?
quoted
+/ {+ #address-cells = <2>;+ #size-cells = <1>;+ model = "ibm,iss-4xx";+ compatible = "ibm,iss-4xx", "ibm,47x-AMP";+ dcr-parent = <&{/cpus/cpu@0}>;++ aliases {+ serial0 = &UART0;+ };++ cpus {+ #address-cells = <1>;+ #size-cells = <0>;++ cpu@0 {+ device_type = "cpu";+ model = "PowerPC,4xx"; // real CPU changed in sim
If the comment is true, then it's probably simpler to just omit the
model property. I'm pretty sure nothing will look at it.
It doesn't appear to be true. Another bit I've been carrying along
without checking it. Removing the comment.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2011-03-02 03:37:36
On Mon, 2011-02-07 at 19:29 +1100, David Gibson wrote:
On Wed, Feb 02, 2011 at 06:00:25PM -0600, Dave Kleikamp wrote:
quoted
On Thu, 2011-02-03 at 10:06 +1100, David Gibson wrote:
quoted
On Tue, Feb 01, 2011 at 12:48:41PM -0600, Dave Kleikamp wrote:
quoted
so that it can use information from the device tree.
Hrm. On the other hand this means that the early_init_devtree() code
can't benefit from hardcoded early debugging. Since you don't
actually appear to use devtree information in udbg_early_init() in the
latest series, I'd suggest dropping this patch.
Patch 2 depends on early_init_devtree() being run. Until then, I don't
know of a way to get at the bootargs.
Ah, yes. Drat.
Doesn't matter. _Early_ debug has (or should have) the address in
the .config file anyways, so it really shouldn't have to care about the
arguments.
So I'll drop this patch.
There are plenty of reasons why we want to be able to use the early
debug stuff to debug what's happening inside early_init_devtree() :-)
Cheers,
Ben.
From: Dave Kleikamp <shaggy@kernel.org> Date: 2011-03-02 13:03:11
On Wed, 2011-03-02 at 14:37 +1100, Benjamin Herrenschmidt wrote:
On Mon, 2011-02-07 at 19:29 +1100, David Gibson wrote:
quoted
On Wed, Feb 02, 2011 at 06:00:25PM -0600, Dave Kleikamp wrote:
quoted
On Thu, 2011-02-03 at 10:06 +1100, David Gibson wrote:
quoted
On Tue, Feb 01, 2011 at 12:48:41PM -0600, Dave Kleikamp wrote:
quoted
so that it can use information from the device tree.
Hrm. On the other hand this means that the early_init_devtree() code
can't benefit from hardcoded early debugging. Since you don't
actually appear to use devtree information in udbg_early_init() in the
latest series, I'd suggest dropping this patch.
Patch 2 depends on early_init_devtree() being run. Until then, I don't
know of a way to get at the bootargs.
Ah, yes. Drat.
Doesn't matter. _Early_ debug has (or should have) the address in
the .config file anyways, so it really shouldn't have to care about the
arguments.
So I'll drop this patch.
There are plenty of reasons why we want to be able to use the early
debug stuff to debug what's happening inside early_init_devtree() :-)
Fair enough. I wasn't sure this was the right thing to do. It's either
turn off early debug for AMP, or build separate kernels with a different
address in .config.
Shaggy