* [PATCH] powerpc: 85xx: separate e500 from e500mc
From: Baruch Siach @ 2011-08-01 5:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Baruch Siach, Timur Tabi
In-Reply-To: <20110801045938.GA5716@sapphire.tkos.co.il>
CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus
breaking clear_pages(), probably others too.
This patch adds a new "Processor Type" entry for e500mc, and makes e500 systems
depend on PPC_E500.
Cc: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
Sending again with the correct list address. Sorry for the noise.
arch/powerpc/platforms/85xx/Kconfig | 12 +++++++++---
arch/powerpc/platforms/Kconfig.cputype | 27 +++++++++++++++------------
2 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index b6976e1..9530fca 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -13,6 +13,8 @@ if FSL_SOC_BOOKE
if PPC32
+if PPC_E500
+
config MPC8540_ADS
bool "Freescale MPC8540 ADS"
select DEFAULT_UIMAGE
@@ -155,10 +157,13 @@ config SBC8560
help
This option enables support for the Wind River SBC8560 board
+endif # PPC_E500
+
+if PPC_E500MC
+
config P3041_DS
bool "Freescale P3041 DS"
select DEFAULT_UIMAGE
- select PPC_E500MC
select PHYS_64BIT
select SWIOTLB
select MPC8xxx_GPIO
@@ -169,7 +174,6 @@ config P3041_DS
config P4080_DS
bool "Freescale P4080 DS"
select DEFAULT_UIMAGE
- select PPC_E500MC
select PHYS_64BIT
select SWIOTLB
select MPC8xxx_GPIO
@@ -177,13 +181,15 @@ config P4080_DS
help
This option enables support for the P4080 DS board
+endif # PPC_E500MC
+
endif # PPC32
config P5020_DS
bool "Freescale P5020 DS"
+ depends on PPC_E500MC
select DEFAULT_UIMAGE
select E500
- select PPC_E500MC
select PHYS_64BIT
select SWIOTLB
select MPC8xxx_GPIO
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 2165b65..71e3cfb 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -11,13 +11,13 @@ choice
prompt "Processor Type"
depends on PPC32
help
- There are five families of 32 bit PowerPC chips supported.
+ There are six families of 32 bit PowerPC chips supported.
The most common ones are the desktop and server CPUs (601, 603,
604, 740, 750, 74xx) CPUs from Freescale and IBM, with their
embedded 512x/52xx/82xx/83xx/86xx counterparts.
- The other embeeded parts, namely 4xx, 8xx, e200 (55xx) and e500
- (85xx) each form a family of their own that is not compatible
- with the others.
+ The other embeeded parts, namely 4xx, 8xx, e200 (55xx), e500
+ (85xx), and e500mc each form a family of their own that is not
+ compatible with the others.
If unsure, select 52xx/6xx/7xx/74xx/82xx/83xx/86xx.
@@ -25,10 +25,15 @@ config PPC_BOOK3S_32
bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx"
select PPC_FPU
-config PPC_85xx
- bool "Freescale 85xx"
+config PPC_E500
+ bool "Freescale e500v1/e500v2 (85xx, P10xx, P20xx)"
+ select PPC_85xx
select E500
+config PPC_E500MC
+ bool "Freescale e500mc/e5500 (P30xx, P40xx, P50xx)"
+ select PPC_85xx
+
config PPC_8xx
bool "Freescale 8xx"
select FSL_SOC
@@ -128,15 +133,13 @@ config TUNE_CELL
config 8xx
bool
-config E500
+config PPC_85xx
+ bool
select FSL_EMB_PERFMON
select PPC_FSL_BOOK3E
- bool
-config PPC_E500MC
- bool "e500mc Support"
- select PPC_FPU
- depends on E500
+config E500
+ bool
config PPC_FPU
bool
--
1.7.5.4
^ permalink raw reply related
* [PATCH] powerpc: Move kdump default base address to half RMO size on 64bit
From: Anton Blanchard @ 2011-08-01 5:27 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
We are seeing boot failures on some very large boxes even with
commit b5416ca9f824 (powerpc: Move kdump default base address to
64MB on 64bit).
This patch halves the RMO so both kernels get about the same
amount of RMO memory. On large machines this region will be
at least 256MB, so each kernel will get 128MB.
We cap it at 256MB (small SLB size) since some early allocations need
to be in the bolted SLB region. We could relax this on machines with
1TB SLBs in a future patch.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-powerpc/arch/powerpc/include/asm/kdump.h
===================================================================
--- linux-powerpc.orig/arch/powerpc/include/asm/kdump.h 2011-07-26 11:11:35.583436932 +1000
+++ linux-powerpc/arch/powerpc/include/asm/kdump.h 2011-07-26 11:17:13.159317079 +1000
@@ -3,17 +3,7 @@
#include <asm/page.h>
-/*
- * If CONFIG_RELOCATABLE is enabled we can place the kdump kernel anywhere.
- * To keep enough space in the RMO for the first stage kernel on 64bit, we
- * place it at 64MB. If CONFIG_RELOCATABLE is not enabled we must place
- * the second stage at 32MB.
- */
-#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_PPC64)
-#define KDUMP_KERNELBASE 0x4000000
-#else
#define KDUMP_KERNELBASE 0x2000000
-#endif
/* How many bytes to reserve at zero for kdump. The reserve limit should
* be greater or equal to the trampoline's end address.
Index: linux-powerpc/arch/powerpc/kernel/machine_kexec.c
===================================================================
--- linux-powerpc.orig/arch/powerpc/kernel/machine_kexec.c 2011-07-26 11:10:27.932259619 +1000
+++ linux-powerpc/arch/powerpc/kernel/machine_kexec.c 2011-07-26 11:18:17.830444562 +1000
@@ -136,12 +136,16 @@ void __init reserve_crashkernel(void)
crashk_res.start = KDUMP_KERNELBASE;
#else
if (!crashk_res.start) {
+#ifdef CONFIG_PPC64
/*
- * unspecified address, choose a region of specified size
- * can overlap with initrd (ignoring corruption when retained)
- * ppc64 requires kernel and some stacks to be in first segemnt
+ * On 64bit we split the RMO in half but cap it at half of
+ * a small SLB (128MB) since the crash kernel needs to place
+ * itself and some stacks to be in the first segment.
*/
+ crashk_res.start = min(0x80000000ULL, (ppc64_rma_size / 2));
+#else
crashk_res.start = KDUMP_KERNELBASE;
+#endif
}
crash_base = PAGE_ALIGN(crashk_res.start);
^ permalink raw reply
* [PATCH] powerpc: Lack! of! ibm,io-events! not! that! important!
From: Anton Blanchard @ 2011-08-01 5:30 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
The ibm,io-events code is a bit verbose with its error messages.
Reverse the reporting so we only print when we successfully enable
I/O event interrupts.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-powerpc/arch/powerpc/platforms/pseries/io_event_irq.c
===================================================================
--- linux-powerpc.orig/arch/powerpc/platforms/pseries/io_event_irq.c 2011-07-26 08:50:11.291231586 +1000
+++ linux-powerpc/arch/powerpc/platforms/pseries/io_event_irq.c 2011-07-26 08:51:39.992772071 +1000
@@ -212,17 +212,15 @@ static int __init ioei_init(void)
struct device_node *np;
ioei_check_exception_token = rtas_token("check-exception");
- if (ioei_check_exception_token == RTAS_UNKNOWN_SERVICE) {
- pr_warning("IO Event IRQ not supported on this system !\n");
+ if (ioei_check_exception_token == RTAS_UNKNOWN_SERVICE)
return -ENODEV;
- }
+
np = of_find_node_by_path("/event-sources/ibm,io-events");
if (np) {
request_event_sources_irqs(np, ioei_interrupt, "IO_EVENT");
+ pr_info("IBM I/O event interrupts enabled\n");
of_node_put(np);
} else {
- pr_err("io_event_irq: No ibm,io-events on system! "
- "IO Event interrupt disabled.\n");
return -ENODEV;
}
return 0;
^ permalink raw reply
* Re: [PATCH v2 2/4] powerpc, mpc52xx: add a4m072 board support
From: Heiko Schocher @ 2011-08-01 5:30 UTC (permalink / raw)
To: Grant Likely; +Cc: devicetree-discuss, linuxppc-dev, Wolfgang Denk
In-Reply-To: <20110731040819.GM24334@ponder.secretlab.ca>
Hello Grant,
Grant Likely wrote:
> On Wed, Jun 22, 2011 at 12:39:10PM +0200, Heiko Schocher wrote:
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>> cc: Grant Likely <grant.likely@secretlab.ca>
>> cc: devicetree-discuss@ozlabs.org
>> cc: Wolfgang Denk <wd@denx.de>
>> cc: Wolfram Sang <w.sang@pengutronix.de>
>> ---
>> For this patchseries following patch is needed:
>>
>> http://patchwork.ozlabs.org/patch/91919/
>>
>> Grant? Do you have some comments on that patch?
>>
>> changes for v2:
>> add comment from Wolfram Sang:
>> use mpc5200.dtsi
>>
>> arch/powerpc/boot/dts/a4m072.dts | 172 ++++++++++++++++++++++++++
>> arch/powerpc/platforms/52xx/mpc5200_simple.c | 1 +
>> 2 files changed, 173 insertions(+), 0 deletions(-)
>> create mode 100644 arch/powerpc/boot/dts/a4m072.dts
>>
>> diff --git a/arch/powerpc/boot/dts/a4m072.dts b/arch/powerpc/boot/dts/a4m072.dts
>> new file mode 100644
>> index 0000000..adb6746
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/a4m072.dts
>> @@ -0,0 +1,172 @@
>> +/*
>> + * a4m072 board Device Tree Source
>> + *
>> + * Copyright (C) 2011 DENX Software Engineering GmbH
>> + * Heiko Schocher <hs@denx.de>
>> + *
>> + * Copyright (C) 2007 Semihalf
>> + * Marian Balakowicz <m8@semihalf.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + */
>> +
>> +/include/ "mpc5200b.dtsi"
>
> Ah, I missed this follow up patch. Yes, this is better.
;-)
>> +
>> +/ {
>> + model = "anonymous,a4m072";
>> + compatible = "anonymous,a4m072";
The customer don;t want, that his name appear, so I decided here,
to use "anonymous" ... what name should used here?
>> +
>> + soc5200@f0000000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "fsl,mpc5200b-immr";
>> + ranges = <0 0xf0000000 0x0000c000>;
>> + reg = <0xf0000000 0x00000100>;
>> + bus-frequency = <0>; /* From boot loader */
>> + system-frequency = <0>; /* From boot loader */
>> +
>> + cdm@200 {
>> + fsl,ext_48mhz_en = <0x0>;
>> + fsl,fd_enable = <0x01>;
>> + fsl,fd_counters = <0xbbbb>;
>
> Are these new properties documented? They need to be. Also,
> convention is to use '-' instead of '_' in property names.
Yes, see patch here:
>> For this patchseries following patch is needed:
>>
>> http://patchwork.ozlabs.org/patch/91919/
>> + };
>> +
>> + timer@600 {
>> + compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
>> + reg = <0x600 0x80>;
>> + interrupts = <1 9 0>;
>> + fsl,has-wdt;
>> + };
>
> Isn't this node already in the mpc5200b.dtsi file?
Yes, you are right, remove this.
> Otherwise, this patch looks pretty good.
Thanks for your review! I wait for a comment on patch
http://patchwork.ozlabs.org/patch/91919/ from you and rework this
2 patches.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* For Power Arch, the Exception Vector always locate at 0x0100-0x0FFF physical address?
From: Wizard @ 2011-08-01 7:25 UTC (permalink / raw)
To: linuxppc-dev
Hi
I am not sure whether this is the right place for this question.
>From the PEM, it says the physical area is reserved for the exception
vector, this is always true?
And how many vectors could it hold?
--
Wizard
^ permalink raw reply
* Re: [PATCH] perf: powerpc: Disable pagefaults during callchain stack read
From: Peter Zijlstra @ 2011-08-01 9:59 UTC (permalink / raw)
To: David Ahern; +Cc: linux-kernel, paulus, anton, acme, mingo, linuxppc-dev
In-Reply-To: <1312059200-11563-1-git-send-email-dsahern@gmail.com>
On Sat, 2011-07-30 at 14:53 -0600, David Ahern wrote:
> A page fault occurred walking the callchain while creating a perf
> sample for the context-switch event. To handle the page fault the
> mmap_sem is needed, but it is currently held by setup_arg_pages.
> (setup_arg_pages calls shift_arg_pages with the mmap_sem held.
> shift_arg_pages then calls move_page_tables which has a cond_resched
> at the top of its for loop - hitting that cond_resched is what caused
> the context switch.)
>
> This is an extension of Anton's proposed patch:
> https://lkml.org/lkml/2011/7/24/151
> adding case for 32-bit ppc.
>
> Tested on the system that first generated the panic and then again
> with latest kernel using a PPC VM. I am not able to test the 64-bit
> path - I do not have H/W for it and 64-bit PPC VMs (qemu on Intel)
> is horribly slow.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Anton Blanchard <anton@samba.org>
Hmm, Paul, didn't you fix something like this early on? Anyway, I've no
objections since I'm really not familiar enough with the PPC side of
things.
^ permalink raw reply
* Re: [PATCH] powerpc: Lack! of! ibm,io-events! not! that! important!
From: Michael Neuling @ 2011-08-01 10:29 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, linuxppc-dev
In-Reply-To: <20110801153004.0e8af5df@kryten>
In message <20110801153004.0e8af5df@kryten> you wrote:
>
> The ibm,io-events code is a bit verbose with its error messages.
> Reverse the reporting so we only print when we successfully enable
> I/O event interrupts.
NAK!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Mikey
PS :-)
PPS !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
>
> Index: linux-powerpc/arch/powerpc/platforms/pseries/io_event_irq.c
> ===================================================================
> --- linux-powerpc.orig/arch/powerpc/platforms/pseries/io_event_irq.c 2011-07
-26 08:50:11.291231586 +1000
> +++ linux-powerpc/arch/powerpc/platforms/pseries/io_event_irq.c 2011-07
-26 08:51:39.992772071 +1000
> @@ -212,17 +212,15 @@ static int __init ioei_init(void)
> struct device_node *np;
>
> ioei_check_exception_token = rtas_token("check-exception");
> - if (ioei_check_exception_token == RTAS_UNKNOWN_SERVICE) {
> - pr_warning("IO Event IRQ not supported on this system !\n");
> + if (ioei_check_exception_token == RTAS_UNKNOWN_SERVICE)
> return -ENODEV;
> - }
> +
> np = of_find_node_by_path("/event-sources/ibm,io-events");
> if (np) {
> request_event_sources_irqs(np, ioei_interrupt, "IO_EVENT");
> + pr_info("IBM I/O event interrupts enabled\n");
> of_node_put(np);
> } else {
> - pr_err("io_event_irq: No ibm,io-events on system! "
> - "IO Event interrupt disabled.\n");
> return -ENODEV;
> }
> return 0;
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] perf: powerpc: Disable pagefaults during callchain stack read
From: Benjamin Herrenschmidt @ 2011-08-01 10:39 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, paulus, anton, acme, David Ahern, mingo,
linuxppc-dev
In-Reply-To: <1312192792.2617.381.camel@laptop>
On Mon, 2011-08-01 at 11:59 +0200, Peter Zijlstra wrote:
> > Signed-off-by: David Ahern <dsahern@gmail.com>
> > CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > CC: Anton Blanchard <anton@samba.org>
>
> Hmm, Paul, didn't you fix something like this early on? Anyway, I've
> no
> objections since I'm really not familiar enough with the PPC side of
> things.
I'm travelling so I haven't had a chance to review properly or even test
but it looks like an ad-hoc fix for the immediate problem.
Ultimately, I want to rework that stuff to do a __gup_fast like x86 does
(maybe as a fallback from an attempt at access first) so we work around
access permissions blocked by lack of dirty/accessed bits but in the
meantime, this should fix the immediate issue.
Cheers,
Ben.
^ permalink raw reply
* RE: HELP:PowerPc-Linux kernel
From: naresh.kamboju @ 2011-08-01 11:31 UTC (permalink / raw)
To: gary, scottwood, david, paulus; +Cc: vijay.t.nikam, cort, linuxppc-dev
In-Reply-To: <4E33F8F3.80002@mlbassoc.com>
>Did you try passing 'console=3DttyCPM0' to the bootargs?
>I have tried ttyCPM0 no use.
Do I need to modify something on boot loader or is there any boot loader
can support CPM ?
Scott,
Is cpm_console_init() must be initialized to fix this issue?
>Also, 2.6.21 is truly ancient. Why not try a more recent kernel,
especially if
>you are just getting srarted?
I think this is the time, for me to use latest kernel to work on.
BR Naresh Kamboju
-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Saturday, July 30, 2011 5:59 PM
To: Naresh Kamboju (WT01 - GMT-Telecom Equipment)
Cc: linuxppc-dev@lists.ozlabs.org; scottwood@freescale.com;
vijay.t.nikam@gmail.com; cort@fsmlabs.com
Subject: Re: HELP:PowerPc-Linux kernel
On 2011-07-30 06:21, naresh.kamboju@wipro.com wrote:
> Hi All,
>
> I have started working on powerpc board bring up. I have prepared dtb
file and booted linux kernel with my debug statement.
> Problem:
> I could not see anything on the serial console. By using the emulator
I can read __log_buf and found below info.
>
> How can I initialize the serial console?
> Here "ttyCPM0 at MMIO map 0xc504aa00 mem 0x0 (irq =3D 40) is a CPM UART"
is detected by kernel and where we generally pass boot args as ttyS0.
> May I the relation between ttyCPM0 and ttyS0.
> How can I see kernel boot console on the serial port? It would be
helpful if you share any workarounds.
Did you try passing 'console=3DttyCPM0' to the bootargs?
Also, 2.6.21 is truly ancient. Why not try a more recent kernel,
especially if
you are just getting srarted?
>
> Below print out is from emulator by reading __log_buf and parsed as
readable log.
>
> <6>Using MPC82xx ADS machine description
> .<3>Initializing container subsys cpu.
> <5>Linux version 2.6.21.7-hrt1-cfs-v22-grsec-WR2.0bl_cgl (vanga@linux)
(gcc version 4.1.2 (Wind River Linux Sourcery G++ 4.1-91)) #18 Sat Jul
30 14:39:06 IST 2011
> .<7>Entering add_active_range(0, 0, 16384) 0 entries of 256 used
> .<6>No memory reg property [1] in devicetree
> .<7>Top of RAM: 0x4000000, Total RAM: 0x4000000
> .<7>Memory hole size: 0MB
> .<4>Zone PFN ranges:
> .<4> DMA 0 -> 16384
> .<4> Normal 16384 -> 16384
> .< 4>early_node_map[1] active PFN ranges
> .<4> 0: 0 -> 16384
> .<7>On node 0 totalpages: 16384
> .<7> DMA zone: 128 pages used for memmap
> .<7> DMA zone: 0 pages reserved
> .<7> DMA zone: 16256 pages, LIFO batch:3
> .<7> Normal zone: 0 pages used for memmap.<4>Built 1 zonelists.
Total pages: 16256.
> <5>Kernel command line: mem=3D64M console=3DttyS0,9600n8 root=3D/dev/nfs r=
w
nfsroot=3D172.16.50.152:/home/export,nolock,rsize=3D1024,wsize=3D1024.
> <5>---after parse_early_param------- .
> <5>---after parse_args------- .
> <5>entered sort_main_extable
> <5>exit sort_main_extable
> <5>---after sort_main_extable()------- .
> <5>---after trap_init()------- .
> <5>---after rcu_init()-------
> .<6>No pci node on device tree.
> <5>---after init_IRQ()-------
> .<4>PID hash table entries: 256 (order: 8, 1024 bytes).
> <5>---after pidhash_init------- .
> <5>---after init_timers------- .
> <5>---after hrtimers_init------- .
> <5>---after softirq_init------- .
> <5>---after timekeeping_init-------
> .<7>time_init: decrementer frequency =3D 16.675000 MHz
> .<7>time_init: processor fre quency =3D 166.750000 MHz.
> <5>---after time_init------- .
> <5>---after profile_init------- .
> <5>---after early_boot_irqs_on------- .
> <5>---after local_irq_enable-------
> .<6>---entered in cpm_uart_console_init -- .
> <5>---after console_init------- .
> <5>---after pan ic check------- .
> <5>---after lockdep_info------- .
> <5>---after locking_selftest-------
> .<4>Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> .<4>Inode-cache hash table entries: 4096 (order: 2, 16384 bytes).
> <5>---after vfs_caches_init_early------- .
> <5>---cpuset_init_early-------
> .<6>Memory: 61612k/65536k available (2848k kernel code, 3860k
reserved, 84k data, 276k bss, 152k init).
> <5>---after kmem_cache_init------- .
> <5>---after locking_selftest------- .
> <5>---after radix_tree_init------- .
> <5>---after memleak_init------- .
> <5>---after setup_per_cpu_pageset------- .
> <5>---after numa_policy_init------- .
> <5>---after late_time_init------
> .<7>Calibrating delay loop... 33.28 BogoMIPS (lpj=3D66560).
> <5>---after calibrate_delay------- .
> <5>---after pidmap_init------ - .
> <5>---after pgtable_cache_init------- .
> <5>---after prio_tree_init------- .
> <5>---after anon_vma_init------- .
> <5>---after fork_init------- .
> <5>---after proc_caches_init------- .
> <5>---after buffer_init------- .
> <5>---after unnamed_dev_init------- .
> <5>---aft er key_init------- .
> <5>---after security_init-------
> .<4>Mount-cache hash table entries: 512.
> <5>---after vfs_caches_init------- .
> <5>---after signals_init------- .
> <5>---after page_writeback_init-------
> .<3>Initializing container subsys cpuacct
> .<3>Initializi ng container subsys debug.
> <5>---after container_init------- .
> <5>---after cpuset_init------- .
> <5>---after taskstats_init_early------ .
> <5>---after delayacct_init------- .
> <5>---after check_bugs------- .
> <5>---after acpi_early_init-------
> .<6>-------entry rest_ init--------
> .<6>-------kernel_thread --------
> .<6>----------after numa_default_policy---------
> .<6>-----unlock_kernel--------
> .<6>------------init_idle_bootup_task---------
> .<6>--------preempt_enable_no_resched------
> .<6>NET: Registered protocol family 16
> .<6>PC I: Probing PCI hardware
> .<6>Generic PHY: Registered new driver
> .<6>NET: Registered protocol family 2
> .<6>------------after schedule---------
> .<6>----------preempt_disable-------.
> <5>-----entered cpu_idle -------
> <5>-----entered cpu_idle set_thread_flag -------I P route cache
hash table entries: 1024 (order: 0, 4096 bytes)
> .<4>TCP established hash table entries: 2048 (order: 2, 16384 bytes)
> .<4>TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
> .<6>TCP: Hash tables configured (established 2048 bind 2048)
> .<6>TCP reno registered
> .<6>JFS: nTxBlock =3D 481, nTxLock =3D 3854
> .<6>Time: timebase clocksource has been installed.
> .<6>Switched to high resolution mode on CPU 0
> .<6>Registering unionfs 2.1.6 (for 2.6.21.7)
> .<6>io scheduler noop registered
> .<6>Generic RTC Driver v1.07
> .< 3>i8042.c: No controller found.
> .<6>Serial: CPM driver $Revision: 0.02 $
> .<6>--cpm_uart_init()---dev =3D C07E6C08
> .<6>--uart_register_driver() ---ret =3D 0--
> .<6>cpm_uart_drv_probe: Adding CPM UART 0
> .<6>CPM uart[0]:config_port
> .<6>:CPM uart[0]:request port
> .<6>pinfo->sccp->scc_sccm
> .<6>CPM uart[0]:allocbuf
> .<6>CPM uart[0]:init_scc
> .<6>ttyCPM0 at MMIO map 0xc504aa00 mem 0x0 (irq =3D 40) is a CPM UART
> .<4>RAMDISK driver initialized: 16 RAM disks of 32768K size 1024
blocksize
> .<4>Default I/O scheduler not found, using no- op
> .<4>Default I/O scheduler not found, using no-op
> .<4>Default I/O scheduler not found, using no-op
> .<4>Default I/O scheduler not found, using no-op
> .<4>Default I/O scheduler not found, using no-op
> .<4>Default I/O scheduler not found, using no-op
> .<4>Default I/O scheduler not found, using no-op
> .<4>Default I/O scheduler not found, using no-op
> .<4>Default I/O scheduler not found, using no-op
> .<4>Default I/O scheduler not found, using no-op
> .<4>Default I/O scheduler not found, using no-op
> .<4>Default I/O scheduler not found, using no-op
> .<4>Default I/O scheduler not found, using no-op
> .<4>Default I/O scheduler not found, using no-op
> .<4>Default I/O scheduler not found, using no-op
> .<4>Default I/O scheduler not found, using no-op
> .<6>nbd: registered device at major 43
> .<6>Broa dcom BCM5411: Registered new driver
> .<6>Broadcom BCM5421: Registered new driver
> .<6>Broadcom BCM5461: Registered new driver
> .<6>fs_enet.c:v1.0 (Aug 8, 2005)
> .<3>BB MII Bus: Cannot register as MDIO bus
> .<4>fsl-bb-mdio: probe of fsl-bb-mdio.0 failed with error -1
> .<3>BB MII Bus: Cannot register as MDIO bus
> .<4>fsl-bb-mdio: probe of fsl-bb-mdio.1 failed with error -1
> .<6>No memory reg property [1] in devicetree
> .<6>No memory reg property [1] in devicetree
> .<6>i2c /dev entries driver.
> <5>physmap platform flash device: 020 00000 at fe000000
> .<6>physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank.
> <5>Support for command set 0002 not present
> .<4>gen_probe: No supported Vendor Command Set found
> .<3>physmap-flash physmap-flash.0: map_probe failed
> .<6>TCP cubic registered
> .<6>Initializing XFRM netlink socket
> .<6>NET: Registered protocol family 1
> .<6>NET: Registered protocol family 17
> .<6>NET: Registered protocol family 15
> .<6>802.1Q VLAN Support v1.8 Ben Greear<greearb@candelatech.com>
> .<6>All bugs added by David S. Miller<davem@red hat.com>.
> <5>Looking up port of RPC 100003/2 on 172.16.50.152....
>
>
> Best regards
> Naresh Kamboju
> -----Original Message-----
> From: Vijay Nikam [mailto:vijay.t.nikam@gmail.com]
> Sent: Thursday, July 28, 2011 10:16 AM
> To: Naresh Kamboju (WT01 - GMT-Telecom Equipment)
> Cc: linuxppc-dev@lists.ozlabs.org; cort@fsmlabs.com;
linas@austin.ibm.com; hollis@austin.ibm.com
> Subject: Re: HELP:PowerPc-Linux kernel
>
> Hello,
>
> Start with looking at the configuration of the board done which is
> similar to yours
> or based on the same CPU as yours. It is important to know role of
> device tree so
> read the documentation and understand the syntax and concept of device
> tree. Once
> the complete concept is understood then you should start the
> configuration and achieve
> successful creation of kernel image.
>
> Take a step forward and do some hands on. If any problem occurs then
> post for specific help,
> as porting itself is a big task and dosent have really straight
forward steps.
> Good Luck
>
> Kind Regards,
> Vijay Nikam
>
> On Wed, Jul 27, 2011 at 8:33 PM,<naresh.kamboju@wipro.com> wrote:
>>
>> Hi,
>>
>>
>>
>> I have take up the new assignment Board bring up activity with Linux
kernel on PowerPC MPC8272.
>>
>> I have been searching Linux bring up on PowerPC processor in Google
and IBM wiki and not found good stuff.
>>
>> It would be more helpful for me if you could share related documents.
>>
>>
>>
>> Best regards
>>
>> Naresh Kamboju
>>
>>
>>
>> Please do not print this email unless it is absolutely necessary.
>>
>> The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
addressee(s) and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately and destroy all copies of this message and any attachments.
>>
>> WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.
>>
>> www.wipro.com
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
addressee(s) and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately and destroy all copies of this message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.
>
> www.wipro.com
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
Please do not print this email unless it is absolutely necessary. =0A=
=0A=
The information contained in this electronic message and any attachments to=
this message are intended for the exclusive use of the addressee(s) and may=
contain proprietary, confidential or privileged information. If you are not=
the intended recipient, you should not disseminate, distribute or copy this=
e-mail. Please notify the sender immediately and destroy all copies of this=
message and any attachments. =0A=
=0A=
WARNING: Computer viruses can be transmitted via email. The recipient should=
check this email and any attachments for the presence of viruses. The compa=
ny accepts no liability for any damage caused by any virus transmitted by th=
is email. =0A=
=0A=
www.wipro.com
^ permalink raw reply
* Re: HELP:PowerPc-Linux kernel
From: Gary Thomas @ 2011-08-01 11:36 UTC (permalink / raw)
To: naresh.kamboju
Cc: vijay.t.nikam, paulus, scottwood, cort, linuxppc-dev, david
In-Reply-To: <35CC4C9595855B43903A67B297EFA8E3C54771@HYD-MKD-MBX01.wipro.com>
On 2011-08-01 05:31, naresh.kamboju@wipro.com wrote:
>> Did you try passing 'console=ttyCPM0' to the bootargs?
>> I have tried ttyCPM0 no use.
> Do I need to modify something on boot loader or is there any boot loader
> can support CPM ?
What boot loader does your board use?
>
> Scott,
> Is cpm_console_init() must be initialized to fix this issue?
>
>
>> Also, 2.6.21 is truly ancient. Why not try a more recent kernel,
> especially if
>> you are just getting srarted?
> I think this is the time, for me to use latest kernel to work on.
>
> BR Naresh Kamboju
>
> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Saturday, July 30, 2011 5:59 PM
> To: Naresh Kamboju (WT01 - GMT-Telecom Equipment)
> Cc: linuxppc-dev@lists.ozlabs.org; scottwood@freescale.com;
> vijay.t.nikam@gmail.com; cort@fsmlabs.com
> Subject: Re: HELP:PowerPc-Linux kernel
>
> On 2011-07-30 06:21, naresh.kamboju@wipro.com wrote:
>> Hi All,
>>
>> I have started working on powerpc board bring up. I have prepared dtb
> file and booted linux kernel with my debug statement.
>> Problem:
>> I could not see anything on the serial console. By using the emulator
> I can read __log_buf and found below info.
>>
>> How can I initialize the serial console?
>> Here "ttyCPM0 at MMIO map 0xc504aa00 mem 0x0 (irq = 40) is a CPM UART"
> is detected by kernel and where we generally pass boot args as ttyS0.
>> May I the relation between ttyCPM0 and ttyS0.
>> How can I see kernel boot console on the serial port? It would be
> helpful if you share any workarounds.
>
> Did you try passing 'console=ttyCPM0' to the bootargs?
>
> Also, 2.6.21 is truly ancient. Why not try a more recent kernel,
> especially if
> you are just getting srarted?
>
>>
>> Below print out is from emulator by reading __log_buf and parsed as
> readable log.
>>
>> <6>Using MPC82xx ADS machine description
>> .<3>Initializing container subsys cpu.
>> <5>Linux version 2.6.21.7-hrt1-cfs-v22-grsec-WR2.0bl_cgl (vanga@linux)
> (gcc version 4.1.2 (Wind River Linux Sourcery G++ 4.1-91)) #18 Sat Jul
> 30 14:39:06 IST 2011
>> .<7>Entering add_active_range(0, 0, 16384) 0 entries of 256 used
>> .<6>No memory reg property [1] in devicetree
>> .<7>Top of RAM: 0x4000000, Total RAM: 0x4000000
>> .<7>Memory hole size: 0MB
>> .<4>Zone PFN ranges:
>> .<4> DMA 0 -> 16384
>> .<4> Normal 16384 -> 16384
>> .< 4>early_node_map[1] active PFN ranges
>> .<4> 0: 0 -> 16384
>> .<7>On node 0 totalpages: 16384
>> .<7> DMA zone: 128 pages used for memmap
>> .<7> DMA zone: 0 pages reserved
>> .<7> DMA zone: 16256 pages, LIFO batch:3
>> .<7> Normal zone: 0 pages used for memmap.<4>Built 1 zonelists.
> Total pages: 16256.
>> <5>Kernel command line: mem=64M console=ttyS0,9600n8 root=/dev/nfs rw
> nfsroot=172.16.50.152:/home/export,nolock,rsize=1024,wsize=1024.
>> <5>---after parse_early_param------- .
>> <5>---after parse_args------- .
>> <5>entered sort_main_extable
>> <5>exit sort_main_extable
>> <5>---after sort_main_extable()------- .
>> <5>---after trap_init()------- .
>> <5>---after rcu_init()-------
>> .<6>No pci node on device tree.
>> <5>---after init_IRQ()-------
>> .<4>PID hash table entries: 256 (order: 8, 1024 bytes).
>> <5>---after pidhash_init------- .
>> <5>---after init_timers------- .
>> <5>---after hrtimers_init------- .
>> <5>---after softirq_init------- .
>> <5>---after timekeeping_init-------
>> .<7>time_init: decrementer frequency = 16.675000 MHz
>> .<7>time_init: processor fre quency = 166.750000 MHz.
>> <5>---after time_init------- .
>> <5>---after profile_init------- .
>> <5>---after early_boot_irqs_on------- .
>> <5>---after local_irq_enable-------
>> .<6>---entered in cpm_uart_console_init -- .
>> <5>---after console_init------- .
>> <5>---after pan ic check------- .
>> <5>---after lockdep_info------- .
>> <5>---after locking_selftest-------
>> .<4>Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
>> .<4>Inode-cache hash table entries: 4096 (order: 2, 16384 bytes).
>> <5>---after vfs_caches_init_early------- .
>> <5>---cpuset_init_early-------
>> .<6>Memory: 61612k/65536k available (2848k kernel code, 3860k
> reserved, 84k data, 276k bss, 152k init).
>> <5>---after kmem_cache_init------- .
>> <5>---after locking_selftest------- .
>> <5>---after radix_tree_init------- .
>> <5>---after memleak_init------- .
>> <5>---after setup_per_cpu_pageset------- .
>> <5>---after numa_policy_init------- .
>> <5>---after late_time_init------
>> .<7>Calibrating delay loop... 33.28 BogoMIPS (lpj=66560).
>> <5>---after calibrate_delay------- .
>> <5>---after pidmap_init------ - .
>> <5>---after pgtable_cache_init------- .
>> <5>---after prio_tree_init------- .
>> <5>---after anon_vma_init------- .
>> <5>---after fork_init------- .
>> <5>---after proc_caches_init------- .
>> <5>---after buffer_init------- .
>> <5>---after unnamed_dev_init------- .
>> <5>---aft er key_init------- .
>> <5>---after security_init-------
>> .<4>Mount-cache hash table entries: 512.
>> <5>---after vfs_caches_init------- .
>> <5>---after signals_init------- .
>> <5>---after page_writeback_init-------
>> .<3>Initializing container subsys cpuacct
>> .<3>Initializi ng container subsys debug.
>> <5>---after container_init------- .
>> <5>---after cpuset_init------- .
>> <5>---after taskstats_init_early------ .
>> <5>---after delayacct_init------- .
>> <5>---after check_bugs------- .
>> <5>---after acpi_early_init-------
>> .<6>-------entry rest_ init--------
>> .<6>-------kernel_thread --------
>> .<6>----------after numa_default_policy---------
>> .<6>-----unlock_kernel--------
>> .<6>------------init_idle_bootup_task---------
>> .<6>--------preempt_enable_no_resched------
>> .<6>NET: Registered protocol family 16
>> .<6>PC I: Probing PCI hardware
>> .<6>Generic PHY: Registered new driver
>> .<6>NET: Registered protocol family 2
>> .<6>------------after schedule---------
>> .<6>----------preempt_disable-------.
>> <5>-----entered cpu_idle -------
>> <5>-----entered cpu_idle set_thread_flag -------I P route cache
> hash table entries: 1024 (order: 0, 4096 bytes)
>> .<4>TCP established hash table entries: 2048 (order: 2, 16384 bytes)
>> .<4>TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
>> .<6>TCP: Hash tables configured (established 2048 bind 2048)
>> .<6>TCP reno registered
>> .<6>JFS: nTxBlock = 481, nTxLock = 3854
>> .<6>Time: timebase clocksource has been installed.
>> .<6>Switched to high resolution mode on CPU 0
>> .<6>Registering unionfs 2.1.6 (for 2.6.21.7)
>> .<6>io scheduler noop registered
>> .<6>Generic RTC Driver v1.07
>> .< 3>i8042.c: No controller found.
>> .<6>Serial: CPM driver $Revision: 0.02 $
>> .<6>--cpm_uart_init()---dev = C07E6C08
>> .<6>--uart_register_driver() ---ret = 0--
>> .<6>cpm_uart_drv_probe: Adding CPM UART 0
>> .<6>CPM uart[0]:config_port
>> .<6>:CPM uart[0]:request port
>> .<6>pinfo->sccp->scc_sccm
>> .<6>CPM uart[0]:allocbuf
>> .<6>CPM uart[0]:init_scc
>> .<6>ttyCPM0 at MMIO map 0xc504aa00 mem 0x0 (irq = 40) is a CPM UART
>> .<4>RAMDISK driver initialized: 16 RAM disks of 32768K size 1024
> blocksize
>> .<4>Default I/O scheduler not found, using no- op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<6>nbd: registered device at major 43
>> .<6>Broa dcom BCM5411: Registered new driver
>> .<6>Broadcom BCM5421: Registered new driver
>> .<6>Broadcom BCM5461: Registered new driver
>> .<6>fs_enet.c:v1.0 (Aug 8, 2005)
>> .<3>BB MII Bus: Cannot register as MDIO bus
>> .<4>fsl-bb-mdio: probe of fsl-bb-mdio.0 failed with error -1
>> .<3>BB MII Bus: Cannot register as MDIO bus
>> .<4>fsl-bb-mdio: probe of fsl-bb-mdio.1 failed with error -1
>> .<6>No memory reg property [1] in devicetree
>> .<6>No memory reg property [1] in devicetree
>> .<6>i2c /dev entries driver.
>> <5>physmap platform flash device: 020 00000 at fe000000
>> .<6>physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank.
>> <5>Support for command set 0002 not present
>> .<4>gen_probe: No supported Vendor Command Set found
>> .<3>physmap-flash physmap-flash.0: map_probe failed
>> .<6>TCP cubic registered
>> .<6>Initializing XFRM netlink socket
>> .<6>NET: Registered protocol family 1
>> .<6>NET: Registered protocol family 17
>> .<6>NET: Registered protocol family 15
>> .<6>802.1Q VLAN Support v1.8 Ben Greear<greearb@candelatech.com>
>> .<6>All bugs added by David S. Miller<davem@red hat.com>.
>> <5>Looking up port of RPC 100003/2 on 172.16.50.152....
>>
>>
>> Best regards
>> Naresh Kamboju
>> -----Original Message-----
>> From: Vijay Nikam [mailto:vijay.t.nikam@gmail.com]
>> Sent: Thursday, July 28, 2011 10:16 AM
>> To: Naresh Kamboju (WT01 - GMT-Telecom Equipment)
>> Cc: linuxppc-dev@lists.ozlabs.org; cort@fsmlabs.com;
> linas@austin.ibm.com; hollis@austin.ibm.com
>> Subject: Re: HELP:PowerPc-Linux kernel
>>
>> Hello,
>>
>> Start with looking at the configuration of the board done which is
>> similar to yours
>> or based on the same CPU as yours. It is important to know role of
>> device tree so
>> read the documentation and understand the syntax and concept of device
>> tree. Once
>> the complete concept is understood then you should start the
>> configuration and achieve
>> successful creation of kernel image.
>>
>> Take a step forward and do some hands on. If any problem occurs then
>> post for specific help,
>> as porting itself is a big task and dosent have really straight
> forward steps.
>> Good Luck
>>
>> Kind Regards,
>> Vijay Nikam
>>
>> On Wed, Jul 27, 2011 at 8:33 PM,<naresh.kamboju@wipro.com> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> I have take up the new assignment Board bring up activity with Linux
> kernel on PowerPC MPC8272.
>>>
>>> I have been searching Linux bring up on PowerPC processor in Google
> and IBM wiki and not found good stuff.
>>>
>>> It would be more helpful for me if you could share related documents.
>>>
>>>
>>>
>>> Best regards
>>>
>>> Naresh Kamboju
>>>
>>>
>>>
>>> Please do not print this email unless it is absolutely necessary.
>>>
>>> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> addressee(s) and may contain proprietary, confidential or privileged
> information. If you are not the intended recipient, you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately and destroy all copies of this message and any attachments.
>>>
>>> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email.
>>>
>>> www.wipro.com
>>>
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@lists.ozlabs.org
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>> Please do not print this email unless it is absolutely necessary.
>>
>> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> addressee(s) and may contain proprietary, confidential or privileged
> information. If you are not the intended recipient, you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately and destroy all copies of this message and any attachments.
>>
>> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email.
>>
>> www.wipro.com
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* RE: HELP:PowerPc-Linux kernel
From: naresh.kamboju @ 2011-08-01 12:29 UTC (permalink / raw)
To: gary; +Cc: vijay.t.nikam, paulus, scottwood, cort, linuxppc-dev, david
In-Reply-To: <4E368FB9.4010202@mlbassoc.com>
>What boot loader does your board use?
Boot loader 1.3.0
-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Monday, August 01, 2011 5:06 PM
To: Naresh Kamboju (WT01 - GMT-Telecom Equipment)
Cc: scottwood@freescale.com; david@gibson.dropbear.id.au;
paulus@samba.org; linuxppc-dev@lists.ozlabs.org;
vijay.t.nikam@gmail.com; cort@fsmlabs.com
Subject: Re: HELP:PowerPc-Linux kernel
On 2011-08-01 05:31, naresh.kamboju@wipro.com wrote:
>> Did you try passing 'console=3DttyCPM0' to the bootargs?
>> I have tried ttyCPM0 no use.
> Do I need to modify something on boot loader or is there any boot
loader
> can support CPM ?
What boot loader does your board use?
>
> Scott,
> Is cpm_console_init() must be initialized to fix this issue?
>
>
>> Also, 2.6.21 is truly ancient. Why not try a more recent kernel,
> especially if
>> you are just getting srarted?
> I think this is the time, for me to use latest kernel to work on.
>
> BR Naresh Kamboju
>
> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Saturday, July 30, 2011 5:59 PM
> To: Naresh Kamboju (WT01 - GMT-Telecom Equipment)
> Cc: linuxppc-dev@lists.ozlabs.org; scottwood@freescale.com;
> vijay.t.nikam@gmail.com; cort@fsmlabs.com
> Subject: Re: HELP:PowerPc-Linux kernel
>
> On 2011-07-30 06:21, naresh.kamboju@wipro.com wrote:
>> Hi All,
>>
>> I have started working on powerpc board bring up. I have prepared dtb
> file and booted linux kernel with my debug statement.
>> Problem:
>> I could not see anything on the serial console. By using the emulator
> I can read __log_buf and found below info.
>>
>> How can I initialize the serial console?
>> Here "ttyCPM0 at MMIO map 0xc504aa00 mem 0x0 (irq =3D 40) is a CPM
UART"
> is detected by kernel and where we generally pass boot args as ttyS0.
>> May I the relation between ttyCPM0 and ttyS0.
>> How can I see kernel boot console on the serial port? It would be
> helpful if you share any workarounds.
>
> Did you try passing 'console=3DttyCPM0' to the bootargs?
>
> Also, 2.6.21 is truly ancient. Why not try a more recent kernel,
> especially if
> you are just getting srarted?
>
>>
>> Below print out is from emulator by reading __log_buf and parsed as
> readable log.
>>
>> <6>Using MPC82xx ADS machine description
>> .<3>Initializing container subsys cpu.
>> <5>Linux version 2.6.21.7-hrt1-cfs-v22-grsec-WR2.0bl_cgl
(vanga@linux)
> (gcc version 4.1.2 (Wind River Linux Sourcery G++ 4.1-91)) #18 Sat Jul
> 30 14:39:06 IST 2011
>> .<7>Entering add_active_range(0, 0, 16384) 0 entries of 256 used
>> .<6>No memory reg property [1] in devicetree
>> .<7>Top of RAM: 0x4000000, Total RAM: 0x4000000
>> .<7>Memory hole size: 0MB
>> .<4>Zone PFN ranges:
>> .<4> DMA 0 -> 16384
>> .<4> Normal 16384 -> 16384
>> .< 4>early_node_map[1] active PFN ranges
>> .<4> 0: 0 -> 16384
>> .<7>On node 0 totalpages: 16384
>> .<7> DMA zone: 128 pages used for memmap
>> .<7> DMA zone: 0 pages reserved
>> .<7> DMA zone: 16256 pages, LIFO batch:3
>> .<7> Normal zone: 0 pages used for memmap.<4>Built 1 zonelists.
> Total pages: 16256.
>> <5>Kernel command line: mem=3D64M console=3DttyS0,9600n8 root=3D/dev/nfs=
rw
> nfsroot=3D172.16.50.152:/home/export,nolock,rsize=3D1024,wsize=3D1024.
>> <5>---after parse_early_param------- .
>> <5>---after parse_args------- .
>> <5>entered sort_main_extable
>> <5>exit sort_main_extable
>> <5>---after sort_main_extable()------- .
>> <5>---after trap_init()------- .
>> <5>---after rcu_init()-------
>> .<6>No pci node on device tree.
>> <5>---after init_IRQ()-------
>> .<4>PID hash table entries: 256 (order: 8, 1024 bytes).
>> <5>---after pidhash_init------- .
>> <5>---after init_timers------- .
>> <5>---after hrtimers_init------- .
>> <5>---after softirq_init------- .
>> <5>---after timekeeping_init-------
>> .<7>time_init: decrementer frequency =3D 16.675000 MHz
>> .<7>time_init: processor fre quency =3D 166.750000 MHz.
>> <5>---after time_init------- .
>> <5>---after profile_init------- .
>> <5>---after early_boot_irqs_on------- .
>> <5>---after local_irq_enable-------
>> .<6>---entered in cpm_uart_console_init -- .
>> <5>---after console_init------- .
>> <5>---after pan ic check------- .
>> <5>---after lockdep_info------- .
>> <5>---after locking_selftest-------
>> .<4>Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
>> .<4>Inode-cache hash table entries: 4096 (order: 2, 16384 bytes).
>> <5>---after vfs_caches_init_early------- .
>> <5>---cpuset_init_early-------
>> .<6>Memory: 61612k/65536k available (2848k kernel code, 3860k
> reserved, 84k data, 276k bss, 152k init).
>> <5>---after kmem_cache_init------- .
>> <5>---after locking_selftest------- .
>> <5>---after radix_tree_init------- .
>> <5>---after memleak_init------- .
>> <5>---after setup_per_cpu_pageset------- .
>> <5>---after numa_policy_init------- .
>> <5>---after late_time_init------
>> .<7>Calibrating delay loop... 33.28 BogoMIPS (lpj=3D66560).
>> <5>---after calibrate_delay------- .
>> <5>---after pidmap_init------ - .
>> <5>---after pgtable_cache_init------- .
>> <5>---after prio_tree_init------- .
>> <5>---after anon_vma_init------- .
>> <5>---after fork_init------- .
>> <5>---after proc_caches_init------- .
>> <5>---after buffer_init------- .
>> <5>---after unnamed_dev_init------- .
>> <5>---aft er key_init------- .
>> <5>---after security_init-------
>> .<4>Mount-cache hash table entries: 512.
>> <5>---after vfs_caches_init------- .
>> <5>---after signals_init------- .
>> <5>---after page_writeback_init-------
>> .<3>Initializing container subsys cpuacct
>> .<3>Initializi ng container subsys debug.
>> <5>---after container_init------- .
>> <5>---after cpuset_init------- .
>> <5>---after taskstats_init_early------ .
>> <5>---after delayacct_init------- .
>> <5>---after check_bugs------- .
>> <5>---after acpi_early_init-------
>> .<6>-------entry rest_ init--------
>> .<6>-------kernel_thread --------
>> .<6>----------after numa_default_policy---------
>> .<6>-----unlock_kernel--------
>> .<6>------------init_idle_bootup_task---------
>> .<6>--------preempt_enable_no_resched------
>> .<6>NET: Registered protocol family 16
>> .<6>PC I: Probing PCI hardware
>> .<6>Generic PHY: Registered new driver
>> .<6>NET: Registered protocol family 2
>> .<6>------------after schedule---------
>> .<6>----------preempt_disable-------.
>> <5>-----entered cpu_idle -------
>> <5>-----entered cpu_idle set_thread_flag -------I P route cache
> hash table entries: 1024 (order: 0, 4096 bytes)
>> .<4>TCP established hash table entries: 2048 (order: 2, 16384 bytes)
>> .<4>TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
>> .<6>TCP: Hash tables configured (established 2048 bind 2048)
>> .<6>TCP reno registered
>> .<6>JFS: nTxBlock =3D 481, nTxLock =3D 3854
>> .<6>Time: timebase clocksource has been installed.
>> .<6>Switched to high resolution mode on CPU 0
>> .<6>Registering unionfs 2.1.6 (for 2.6.21.7)
>> .<6>io scheduler noop registered
>> .<6>Generic RTC Driver v1.07
>> .< 3>i8042.c: No controller found.
>> .<6>Serial: CPM driver $Revision: 0.02 $
>> .<6>--cpm_uart_init()---dev =3D C07E6C08
>> .<6>--uart_register_driver() ---ret =3D 0--
>> .<6>cpm_uart_drv_probe: Adding CPM UART 0
>> .<6>CPM uart[0]:config_port
>> .<6>:CPM uart[0]:request port
>> .<6>pinfo->sccp->scc_sccm
>> .<6>CPM uart[0]:allocbuf
>> .<6>CPM uart[0]:init_scc
>> .<6>ttyCPM0 at MMIO map 0xc504aa00 mem 0x0 (irq =3D 40) is a CPM UART
>> .<4>RAMDISK driver initialized: 16 RAM disks of 32768K size 1024
> blocksize
>> .<4>Default I/O scheduler not found, using no- op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<4>Default I/O scheduler not found, using no-op
>> .<6>nbd: registered device at major 43
>> .<6>Broa dcom BCM5411: Registered new driver
>> .<6>Broadcom BCM5421: Registered new driver
>> .<6>Broadcom BCM5461: Registered new driver
>> .<6>fs_enet.c:v1.0 (Aug 8, 2005)
>> .<3>BB MII Bus: Cannot register as MDIO bus
>> .<4>fsl-bb-mdio: probe of fsl-bb-mdio.0 failed with error -1
>> .<3>BB MII Bus: Cannot register as MDIO bus
>> .<4>fsl-bb-mdio: probe of fsl-bb-mdio.1 failed with error -1
>> .<6>No memory reg property [1] in devicetree
>> .<6>No memory reg property [1] in devicetree
>> .<6>i2c /dev entries driver.
>> <5>physmap platform flash device: 020 00000 at fe000000
>> .<6>physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank.
>> <5>Support for command set 0002 not present
>> .<4>gen_probe: No supported Vendor Command Set found
>> .<3>physmap-flash physmap-flash.0: map_probe failed
>> .<6>TCP cubic registered
>> .<6>Initializing XFRM netlink socket
>> .<6>NET: Registered protocol family 1
>> .<6>NET: Registered protocol family 17
>> .<6>NET: Registered protocol family 15
>> .<6>802.1Q VLAN Support v1.8 Ben Greear<greearb@candelatech.com>
>> .<6>All bugs added by David S. Miller<davem@red hat.com>.
>> <5>Looking up port of RPC 100003/2 on 172.16.50.152....
>>
>>
>> Best regards
>> Naresh Kamboju
>> -----Original Message-----
>> From: Vijay Nikam [mailto:vijay.t.nikam@gmail.com]
>> Sent: Thursday, July 28, 2011 10:16 AM
>> To: Naresh Kamboju (WT01 - GMT-Telecom Equipment)
>> Cc: linuxppc-dev@lists.ozlabs.org; cort@fsmlabs.com;
> linas@austin.ibm.com; hollis@austin.ibm.com
>> Subject: Re: HELP:PowerPc-Linux kernel
>>
>> Hello,
>>
>> Start with looking at the configuration of the board done which is
>> similar to yours
>> or based on the same CPU as yours. It is important to know role of
>> device tree so
>> read the documentation and understand the syntax and concept of
device
>> tree. Once
>> the complete concept is understood then you should start the
>> configuration and achieve
>> successful creation of kernel image.
>>
>> Take a step forward and do some hands on. If any problem occurs then
>> post for specific help,
>> as porting itself is a big task and dosent have really straight
> forward steps.
>> Good Luck
>>
>> Kind Regards,
>> Vijay Nikam
>>
>> On Wed, Jul 27, 2011 at 8:33 PM,<naresh.kamboju@wipro.com> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> I have take up the new assignment Board bring up activity with
Linux
> kernel on PowerPC MPC8272.
>>>
>>> I have been searching Linux bring up on PowerPC processor in Google
> and IBM wiki and not found good stuff.
>>>
>>> It would be more helpful for me if you could share related
documents.
>>>
>>>
>>>
>>> Best regards
>>>
>>> Naresh Kamboju
>>>
>>>
>>>
>>> Please do not print this email unless it is absolutely necessary.
>>>
>>> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> addressee(s) and may contain proprietary, confidential or privileged
> information. If you are not the intended recipient, you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately and destroy all copies of this message and any
attachments.
>>>
>>> WARNING: Computer viruses can be transmitted via email. The
recipient
> should check this email and any attachments for the presence of
viruses.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email.
>>>
>>> www.wipro.com
>>>
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@lists.ozlabs.org
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>> Please do not print this email unless it is absolutely necessary.
>>
>> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> addressee(s) and may contain proprietary, confidential or privileged
> information. If you are not the intended recipient, you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately and destroy all copies of this message and any
attachments.
>>
>> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of
viruses.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email.
>>
>> www.wipro.com
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
Please do not print this email unless it is absolutely necessary. =0A=
=0A=
The information contained in this electronic message and any attachments to=
this message are intended for the exclusive use of the addressee(s) and may=
contain proprietary, confidential or privileged information. If you are not=
the intended recipient, you should not disseminate, distribute or copy this=
e-mail. Please notify the sender immediately and destroy all copies of this=
message and any attachments. =0A=
=0A=
WARNING: Computer viruses can be transmitted via email. The recipient should=
check this email and any attachments for the presence of viruses. The compa=
ny accepts no liability for any damage caused by any virus transmitted by th=
is email. =0A=
=0A=
www.wipro.com
^ permalink raw reply
* Re: [PATCH] perf: powerpc: Disable pagefaults during callchain stack read
From: David Ahern @ 2011-08-01 12:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Peter Zijlstra, linux-kernel, paulus, anton, acme, mingo,
linuxppc-dev
In-Reply-To: <1312195147.8793.794.camel@pasglop>
On 08/01/2011 04:39 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2011-08-01 at 11:59 +0200, Peter Zijlstra wrote:
>>> Signed-off-by: David Ahern <dsahern@gmail.com>
>>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> CC: Anton Blanchard <anton@samba.org>
>>
>> Hmm, Paul, didn't you fix something like this early on? Anyway, I've
>> no
>> objections since I'm really not familiar enough with the PPC side of
>> things.
>
> I'm travelling so I haven't had a chance to review properly or even test
> but it looks like an ad-hoc fix for the immediate problem.
>
> Ultimately, I want to rework that stuff to do a __gup_fast like x86 does
> (maybe as a fallback from an attempt at access first) so we work around
> access permissions blocked by lack of dirty/accessed bits but in the
> meantime, this should fix the immediate issue.
The problem goes back to all kernel releases with perf, so this patch
should get applied to the stable trains too.
David
>
> Cheers,
> Ben.
>
>
^ permalink raw reply
* Re: HELP:PowerPc-Linux kernel
From: Scott Wood @ 2011-08-01 16:12 UTC (permalink / raw)
To: naresh.kamboju; +Cc: vijay.t.nikam, gary, paulus, cort, linuxppc-dev, david
In-Reply-To: <35CC4C9595855B43903A67B297EFA8E3C54771@HYD-MKD-MBX01.wipro.com>
On Mon, 1 Aug 2011 17:01:27 +0530
<naresh.kamboju@wipro.com> wrote:
> >Did you try passing 'console=ttyCPM0' to the bootargs?
> >I have tried ttyCPM0 no use.
Have you tried specifying the baud rate?
> Do I need to modify something on boot loader or is there any boot loader
> can support CPM ?
>
> Scott,
> Is cpm_console_init() must be initialized to fix this issue?
Please start with the latest kernel. Upgrade U-Boot as well if you have a
way to recover if the new image doesn't work (e.g. a BDI).
You don't need the bootwrapper for the main serial driver to work. You may
need some board-specific pin/port init, though at least the serial port
that U-Boot uses should already be set up, assuming it worked in U-Boot
of course. :-)
If it still doesn't work after switching to a current kernel, try dumping
CPM registers, instrumenting the driver, etc. to see what's going on.
-Scott
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Alex Williamson @ 2011-08-01 16:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alexey Kardashevskiy, kvm, Paul Mackerras,
linux-pci@vger.kernel.org, David Gibson, Anthony Liguori,
linuxppc-dev
In-Reply-To: <1312064479.8793.739.camel@pasglop>
On Sun, 2011-07-31 at 08:21 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
> > Hi folks !
> >
> > So I promised Anthony I would try to summarize some of the comments &
> > issues we have vs. VFIO after we've tried to use it for PCI pass-through
> > on POWER. It's pretty long, there are various items with more or less
> > impact, some of it is easily fixable, some are API issues, and we'll
> > probably want to discuss them separately, but for now here's a brain
> > dump.
> >
> > David, Alexei, please make sure I haven't missed anything :-)
>
> And I think I have :-)
>
> * Config space
>
> VFIO currently handles that as a byte stream. It's quite gross to be
> honest and it's not right. You shouldn't lose access size information
> between guest and host when performing real accesses.
>
> Some config space registers can have side effects and not respecting
> access sizes can be nasty.
It's a bug, let's fix it.
Alex
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Alex Williamson @ 2011-08-01 18:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: chrisw, Alexey Kardashevskiy, kvm, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, David Gibson, aafabbri,
iommu, Anthony Liguori, linuxppc-dev, benve
In-Reply-To: <1312070097.8793.786.camel@pasglop>
On Sun, 2011-07-31 at 09:54 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2011-07-30 at 12:20 -0600, Alex Williamson wrote:
>
> > On x86, the USB controllers don't typically live behind a PCIe-to-PCI
> > bridge, so don't suffer the source identifier problem, but they do often
> > share an interrupt. But even then, we can count on most modern devices
> > supporting PCI2.3, and thus the DisINTx feature, which allows us to
> > share interrupts. In any case, yes, it's more rare but we need to know
> > how to handle devices behind PCI bridges. However I disagree that we
> > need to assign all the devices behind such a bridge to the guest.
>
> Well, ok so let's dig a bit more here :-) First, yes I agree they don't
> all need to appear to the guest. My point is really that we must prevent
> them to be "used" by somebody else, either host or another guest.
>
> Now once you get there, I personally prefer having a clear "group"
> ownership rather than having devices stay in some "limbo" under vfio
> control but it's an implementation detail.
>
> Regarding DisINTx, well, it's a bit like putting separate PCIe functions
> into separate guests, it looks good ... but you are taking a chance.
> Note that I do intend to do some of that for power ... well I think, I
> haven't completely made my mind.
>
> pHyp for has a stricter requirement, PEs essentially are everything
> behind a bridge. If you have a slot, you have some kind of bridge above
> this slot and everything on it will be a PE.
>
> The problem I see is that with your filtering of config space, BAR
> emulation, DisINTx etc... you essentially assume that you can reasonably
> reliably isolate devices. But in practice, it's chancy. Some devices for
> example have "backdoors" into their own config space via MMIO. If I have
> such a device in a guest, I can completely override your DisINTx and
> thus DOS your host or another guest with a shared interrupt. I can move
> my MMIO around and DOS another function by overlapping the addresses.
>
> You can really only be protect yourself against a device if you have it
> behind a bridge (in addition to having a filtering iommu), which limits
> the MMIO span (and thus letting the guest whack the BARs randomly will
> only allow that guest to shoot itself in the foot).
>
> Some bridges also provide a way to block INTx below them which comes in
> handy but it's bridge specific. Some devices can be coerced to send the
> INTx "assert" message and never de-assert it (for example by doing a
> soft-reset while it's asserted, which can be done with some devices with
> an MMIO).
>
> Anything below a PCIe -> PCI/PCI-X needs to also be "grouped" due to
> simple lack of proper filtering by the iommu (PCI-X in theory has RIDs
> and fowards them up, but this isn't very reliable, for example it fails
> over with split transactions).
>
> Fortunately in PCIe land, we most have bridges above everything. The
> problem somewhat remains with functions of a device, how can you be sure
> that there isn't a way via some MMIO to create side effects on the other
> functions of the device ? (For example by checkstopping the whole
> thing). You can't really :-)
>
> So it boils down of the "level" of safety/isolation you want to provide,
> and I suppose to some extent it's a user decision but the user needs to
> be informed to some extent. A hard problem :-)
>
> > There's a difference between removing the device from the host and
> > exposing the device to the guest. If I have a NIC and HBA behind a
> > bridge, it's perfectly reasonable that I might only assign the NIC to
> > the guest, but as you describe, we then need to prevent the host, or any
> > other guest from making use of the HBA.
>
> Yes. However the other device is in "limbo" and it may be not clear to
> the user why it can't be used anymore :-)
>
> The question is more, the user needs to "know" (or libvirt does, or
> somebody ... ) that in order to pass-through device A, it must also
> "remove" device B from the host. How can you even provide a meaningful
> error message to the user if all VFIO does is give you something like
> -EBUSY ?
>
> So the information about the grouping constraint must trickle down
> somewhat.
>
> Look at it from a GUI perspective for example. Imagine a front-end
> showing you devices in your system and allowing you to "Drag & drop"
> them to your guest. How do you represent that need for grouping ? First
> how do you expose it from kernel/libvirt to the GUI tool and how do you
> represent it to the user ?
>
> By grouping the devices in logical groups which end up being the
> "objects" you can drag around, at least you provide some amount of
> clarity. Now if you follow that path down to how the GUI app, libvirt
> and possibly qemu need to know / resolve the dependency, being given the
> "groups" as the primary information of what can be used for pass-through
> makes everything a lot simpler.
>
> > > - The -minimum- granularity of pass-through is not always a single
> > > device and not always under SW control
> >
> > But IMHO, we need to preserve the granularity of exposing a device to a
> > guest as a single device. That might mean some devices are held hostage
> > by an agent on the host.
>
> Maybe but wouldn't that be even more confusing from a user perspective ?
> And I think it makes it harder from an implementation of admin &
> management tools perspective too.
>
> > > - Having a magic heuristic in libvirt to figure out those constraints is
> > > WRONG. This reeks of XFree 4 PCI layer trying to duplicate the kernel
> > > knowledge of PCI resource management and getting it wrong in many many
> > > cases, something that took years to fix essentially by ripping it all
> > > out. This is kernel knowledge and thus we need the kernel to expose in a
> > > way or another what those constraints are, what those "partitionable
> > > groups" are.
> > >
> > > - That does -not- mean that we cannot specify for each individual device
> > > within such a group where we want to put it in qemu (what devfn etc...).
> > > As long as there is a clear understanding that the "ownership" of the
> > > device goes with the group, this is somewhat orthogonal to how they are
> > > represented in qemu. (Not completely... if the iommu is exposed to the
> > > guest ,via paravirt for example, some of these constraints must be
> > > exposed but I'll talk about that more later).
> >
> > Or we can choose not to expose all of the devices in the group to the
> > guest?
>
> As I said, I don't mind if you don't, I'm just worried about the
> consequences of that from a usability standpoint. Having advanced
> command line option to fine tune is fine. Being able to specify within a
> "group" which devices to show and at what address if fine.
>
> But I believe the basic entity to be manipulated from an interface
> standpoitn remains the group.
>
> To get back to my GUI example, once you've D&D your group of devices
> over, you can have the option to open that group and check/uncheck
> individual devices & assign them addresses if you want. That doesn't
> change the fact that practically speaking, the whole group is now owned
> by the guest.
>
> I will go further than that actually. If you look at how the isolation
> HW works on POWER, the fact that I have the MMIO segmentation means that
> I can simply give the entire group MMIO space to the guest. No problem
> of small BARs, no need to slow-map them ... etc.. that's a pretty handy
> feature don't you think ?
>
> But that means that those other devices -will- be there, mapped along
> with the one you care about. We may not expose it in config space but it
> will be accessible. I suppose we can keep its IO/MEM decoding disabled.
> But my point is that for all intend and purpose, it's actually owned by
> the guest.
>
> > > The interface currently proposed for VFIO (and associated uiommu)
> > > doesn't handle that problem at all. Instead, it is entirely centered
> > > around a specific "feature" of the VTd iommu's for creating arbitrary
> > > domains with arbitrary devices (tho those devices -do- have the same
> > > constraints exposed above, don't try to put 2 legacy PCI devices behind
> > > the same bridge into 2 different domains !), but the API totally ignores
> > > the problem, leaves it to libvirt "magic foo" and focuses on something
> > > that is both quite secondary in the grand scheme of things, and quite
> > > x86 VTd specific in the implementation and API definition.
> >
> > To be fair, libvirt's "magic foo" is built out of the necessity that
> > nobody else is defining the rules.
>
> Sure, which is why I propose that the kernel exposes the rules since
> it's really the one right place to have that sort of HW constraint
> knowledge, especially since it can be partially at least platform
> specific.
>
> .../...
I'll try to consolidate my reply to all the above here because there are
too many places above to interject and make this thread even more
difficult to respond to. Much of what you're discussion above comes
down to policy. Do we trust DisINTx? Do we trust multi-function
devices? I have no doubt there are devices we can use as examples for
each behaving badly. On x86 this is one of the reasons we have SR-IOV.
Besides splitting a single device into multiple, it makes sure each
devices is actually virtualization friendly. POWER seems to add
multiple layers of hardware so that you don't actually have to trust the
device, which is a great value add for enterprise systems, but in doing
so it mostly defeats the purpose and functionality of SR-IOV.
How we present this in a GUI is largely irrelevant because something has
to create a superset of what the hardware dictates (can I uniquely
identify transactions from this device, can I protect other devices from
it, etc.), the system policy (do I trust DisINTx, do I trust function
isolation, do I require ACS) and mold that with what the user actually
wants to assign. For the VFIO kernel interface, we should only be
concerned with the first problem. Userspace is free to make the rest as
simple or complete as it cares to. I argue for x86, we want device
level granularity of assignment, but that also tends to be the typical
case (when only factoring in hardware restrictions) due to our advanced
iommus.
> > > Maybe something like /sys/devgroups ? This probably warrants involving
> > > more kernel people into the discussion.
> >
> > I don't yet buy into passing groups to qemu since I don't buy into the
> > idea of always exposing all of those devices to qemu. Would it be
> > sufficient to expose iommu nodes in sysfs that link to the devices
> > behind them and describe properties and capabilities of the iommu
> > itself? More on this at the end.
>
> Well, iommu aren't the only factor. I mentioned shared interrupts (and
> my unwillingness to always trust DisINTx),
*userspace policy*
> there's also the MMIO
> grouping I mentioned above (in which case it's an x86 -limitation- with
> small BARs that I don't want to inherit, especially since it's based on
> PAGE_SIZE and we commonly have 64K page size on POWER), etc...
But isn't MMIO grouping effectively *at* the iommu?
> So I'm not too fan of making it entirely look like the iommu is the
> primary factor, but we -can-, that would be workable. I still prefer
> calling a cat a cat and exposing the grouping for what it is, as I think
> I've explained already above, tho.
The trouble is the "group" analogy is more fitting to a partitionable
system, whereas on x86 we can really mix-n-match devices across iommus
fairly easily. The iommu seems to be the common point to describe these
differences.
> > > Now some of this can be fixed with tweaks, and we've started doing it
> > > (we have a working pass-through using VFIO, forgot to mention that, it's
> > > just that we don't like what we had to do to get there).
> >
> > This is a result of wanting to support *unmodified* x86 guests. We
> > don't have the luxury of having a predefined pvDMA spec that all x86
> > OSes adhere to.
>
> No but you could emulate a HW iommu no ?
We can, but then we have to worry about supporting legacy, proprietary
OSes that may not have support or may make use of it differently. As
Avi mentions, hardware is coming the eases the "pin the whole guest"
requirement and we may implement emulated iommus for the benefit of some
guests.
> > The 32bit problem is unfortunate, but the priority use
> > case for assigning devices to guests is high performance I/O, which
> > usually entails modern, 64bit hardware. I'd like to see us get to the
> > point of having emulated IOMMU hardware on x86, which could then be
> > backed by VFIO, but for now guest pinning is the most practical and
> > useful.
>
> For your current case maybe. It's just not very future proof imho.
> Anyways, it's fixable, but the APIs as they are make it a bit clumsy.
You expect more 32bit devices in the future?
> > > Also our next generation chipset may drop support for PIO completely.
> > >
> > > On the other hand, because PIO is just a special range of MMIO for us,
> > > we can do normal pass-through on it and don't need any of the emulation
> > > done qemu.
> >
> > Maybe we can add mmap support to PIO regions on non-x86.
>
> We have to yes. I haven't looked into it yet, it should be easy if VFIO
> kernel side starts using the "proper" PCI mmap interfaces in kernel (the
> same interfaces sysfs & proc use).
Patches welcome.
> > > * MMIO constraints
> > >
> > > The QEMU side VFIO code hard wires various constraints that are entirely
> > > based on various requirements you decided you have on x86 but don't
> > > necessarily apply to us :-)
> > >
> > > Due to our paravirt nature, we don't need to masquerade the MSI-X table
> > > for example. At all. If the guest configures crap into it, too bad, it
> > > can only shoot itself in the foot since the host bridge enforce
> > > validation anyways as I explained earlier. Because it's all paravirt, we
> > > don't need to "translate" the interrupt vectors & addresses, the guest
> > > will call hyercalls to configure things anyways.
> >
> > With interrupt remapping, we can allow the guest access to the MSI-X
> > table, but since that takes the host out of the loop, there's
> > effectively no way for the guest to correctly program it directly by
> > itself.
>
> Right, I think what we need here is some kind of capabilities to
> "disable" those "features" of qemu vfio.c that aren't needed on our
> platform :-) Shouldn't be too hard. We need to make this runtime tho
> since different machines can have different "capabilities".
Sure, we'll probably eventually want a switch to push the MSI-X table to
KVM when it's available.
> > > We don't need to prevent MMIO pass-through for small BARs at all. This
> > > should be some kind of capability or flag passed by the arch. Our
> > > segmentation of the MMIO domain means that we can give entire segments
> > > to the guest and let it access anything in there (those segments are a
> > > multiple of the page size always). Worst case it will access outside of
> > > a device BAR within a segment and will cause the PE to go into error
> > > state, shooting itself in the foot, there is no risk of side effect
> > > outside of the guest boundaries.
> >
> > Sure, this could be some kind of capability flag, maybe even implicit in
> > certain configurations.
>
> Yup.
>
> > > In fact, we don't even need to emulate BAR sizing etc... in theory. Our
> > > paravirt guests expect the BARs to have been already allocated for them
> > > by the firmware and will pick up the addresses from the device-tree :-)
> > >
> > > Today we use a "hack", putting all 0's in there and triggering the linux
> > > code path to reassign unassigned resources (which will use BAR
> > > emulation) but that's not what we are -supposed- to do. Not a big deal
> > > and having the emulation there won't -hurt- us, it's just that we don't
> > > really need any of it.
> > >
> > > We have a small issue with ROMs. Our current KVM only works with huge
> > > pages for guest memory but that is being fixed. So the way qemu maps the
> > > ROM copy into the guest address space doesn't work. It might be handy
> > > anyways to have a way for qemu to use MMIO emulation for ROM access as a
> > > fallback. I'll look into it.
> >
> > So that means ROMs don't work for you on emulated devices either? The
> > reason we read it once and map it into the guest is because Michael
> > Tsirkin found a section in the PCI spec that indicates devices can share
> > address decoders between BARs and ROM.
>
> Yes, he is correct.
>
> > This means we can't just leave
> > the enabled bit set in the ROM BAR, because it could actually disable an
> > address decoder for a regular BAR. We could slow-map the actual ROM,
> > enabling it around each read, but shadowing it seemed far more
> > efficient.
>
> Right. We can slow map the ROM, or we can not care :-) At the end of the
> day, what is the difference here between a "guest" under qemu and the
> real thing bare metal on the machine ? IE. They have the same issue vs.
> accessing the ROM. IE. I don't see why qemu should try to make it safe
> to access it at any time while it isn't on a real machine. Since VFIO
> resets the devices before putting them in guest space, they should be
> accessible no ? (Might require a hard reset for some devices tho ... )
My primary motivator for doing the ROM the way it's done today is that I
get to push all the ROM handling off to QEMU core PCI code. The ROM for
an assigned device is handled exactly like the ROM for an emulated
device except it might be generated by reading it from the hardware.
This gives us the benefit of things like rombar=0 if I want to hide the
ROM or romfile=<file> if I want to load an ipxe image for a device that
may not even have a physical ROM. Not to mention I don't have to
special case ROM handling routines in VFIO. So it actually has little
to do w/ making it safe to access the ROM at any time.
> In any case, it's not a big deal and we can sort it out, I'm happy to
> fallback to slow map to start with and eventually we will support small
> pages mappings on POWER anyways, it's a temporary limitation.
Perhaps this could also be fixed in the generic QEMU PCI ROM support so
it works for emulated devices too... code reuse paying off already ;)
> > > * EEH
> > >
> > > This is the name of those fancy error handling & isolation features I
> > > mentioned earlier. To some extent it's a superset of AER, but we don't
> > > generally expose AER to guests (or even the host), it's swallowed by
> > > firmware into something else that provides a superset (well mostly) of
> > > the AER information, and allow us to do those additional things like
> > > isolating/de-isolating, reset control etc...
> > >
> > > Here too, we'll need arch specific APIs through VFIO. Not necessarily a
> > > huge deal, I mention it for completeness.
> >
> > We expect to do AER via the VFIO netlink interface, which even though
> > its bashed below, would be quite extensible to supporting different
> > kinds of errors.
>
> As could platform specific ioctls :-)
Is qemu going to poll for errors?
> > > * Misc
> > >
> > > There's lots of small bits and pieces... in no special order:
> > >
> > > - netlink ? WTF ! Seriously, we don't need a hybrid API with a bit of
> > > netlink and a bit of ioctl's ... it's not like there's something
> > > fundamentally better for netlink vs. ioctl... it really depends what
> > > you are doing, and in this case I fail to see what netlink brings you
> > > other than bloat and more stupid userspace library deps.
> >
> > The netlink interface is primarily for host->guest signaling. I've only
> > implemented the remove command (since we're lacking a pcie-host in qemu
> > to do AER), but it seems to work quite well. If you have suggestions
> > for how else we might do it, please let me know. This seems to be the
> > sort of thing netlink is supposed to be used for.
>
> I don't understand what the advantage of netlink is compared to just
> extending your existing VFIO ioctl interface, possibly using children
> fd's as we do for example with spufs but it's not a huge deal. It just
> that netlink has its own gotchas and I don't like multi-headed
> interfaces.
We could do yet another eventfd that triggers the VFIO user to go call
an ioctl to see what happened, but then we're locked into an ioctl
interface for something that we may want to more easily extend over
time. As I said, it feels like this is what netlink is for and the
arguments against seem to be more gut reaction.
> > > - I don't like too much the fact that VFIO provides yet another
> > > different API to do what we already have at least 2 kernel APIs for, ie,
> > > BAR mapping and config space access. At least it should be better at
> > > using the backend infrastructure of the 2 others (sysfs & procfs). I
> > > understand it wants to filter in some case (config space) and -maybe-
> > > yet another API is the right way to go but allow me to have my doubts.
> >
> > The use of PCI sysfs is actually one of my complaints about current
> > device assignment. To do assignment with an unprivileged guest we need
> > to open the PCI sysfs config file for it, then change ownership on a
> > handful of other PCI sysfs files, then there's this other pci-stub thing
> > to maintain ownership, but the kvm ioctls don't actually require it and
> > can grab onto any free device... We are duplicating some of that in
> > VFIO, but we also put the ownership of the device behind a single device
> > file. We do have the uiommu problem that we can't give an unprivileged
> > user ownership of that, but your usage model may actually make that
> > easier. More below...
> >
> > > One thing I thought about but you don't seem to like it ... was to use
> > > the need to represent the partitionable entity as groups in sysfs that I
> > > talked about earlier. Those could have per-device subdirs with the usual
> > > config & resource files, same semantic as the ones in the real device,
> > > but when accessed via the group they get filtering. I might or might not
> > > be practical in the end, tbd, but it would allow apps using a slightly
> > > modified libpci for example to exploit some of this.
> >
> > I may be tainted by our disagreement that all the devices in a group
> > need to be exposed to the guest and qemu could just take a pointer to a
> > sysfs directory. That seems very unlike qemu and pushes more of the
> > policy into qemu, which seems like the wrong direction.
>
> I don't see how it pushes "policy" into qemu.
>
> The "policy" here is imposed by the HW setup and exposed by the
> kernel :-) Giving qemu a group means qemu takes "owership" of that bunch
> of devices, so far I don't see what's policy about that. From there, it
> would be "handy" for people to just stop there and just see all the
> devices of the group show up in the guest, but by all means feel free to
> suggest a command line interface that allows to more precisely specify
> which of the devices in the group to pass through and at what address.
That's exactly the policy I'm thinking of. Here's a group of devices,
do something with them... Does qemu assign them all? where? does it
allow hotplug? do we have ROMs? should we? from where?
> > > - The qemu vfio code hooks directly into ioapic ... of course that
> > > won't fly with anything !x86
> >
> > I spent a lot of time looking for an architecture neutral solution here,
> > but I don't think it exists. Please prove me wrong.
>
> No it doesn't I agree, that's why it should be some kind of notifier or
> function pointer setup by the platform specific code.
Hmm... it is. I added a pci_get_irq() that returns a
platform/architecture specific translation of a PCI interrupt to it's
resulting system interrupt. Implement this in your PCI root bridge.
There's a notifier for when this changes, so vfio will check
pci_get_irq() again, also to be implemented in the PCI root bridge code.
And a notifier that gets registered with that system interrupt and gets
notice for EOI... implemented in x86 ioapic, somewhere else for power.
> > The problem is
> > that we have to disable INTx on an assigned device after it fires (VFIO
> > does this automatically). If we don't do this, a non-responsive or
> > malicious guest could sit on the interrupt, causing it to fire
> > repeatedly as a DoS on the host. The only indication that we can rely
> > on to re-enable INTx is when the guest CPU writes an EOI to the APIC.
> > We can't just wait for device accesses because a) the device CSRs are
> > (hopefully) direct mapped and we'd have to slow map them or attempt to
> > do some kind of dirty logging to detect when they're accesses b) what
> > constitutes an interrupt service is device specific.
> >
> > That means we need to figure out how PCI interrupt 'A' (or B...)
> > translates to a GSI (Global System Interrupt - ACPI definition, but
> > hopefully a generic concept). That GSI identifies a pin on an IOAPIC,
> > which will also see the APIC EOI. And just to spice things up, the
> > guest can change the PCI to GSI mappings via ACPI. I think the set of
> > callbacks I've added are generic (maybe I left ioapic in the name), but
> > yes they do need to be implemented for other architectures. Patches
> > appreciated from those with knowledge of the systems and/or access to
> > device specs. This is the only reason that I make QEMU VFIO only build
> > for x86.
>
> Right, and we need to cook a similiar sauce for POWER, it's an area that
> has to be arch specific (and in fact specific to the specific HW machine
> being emulated), so we just need to find out what's the cleanest way for
> the plaform to "register" the right callbacks here.
Aside from the ioapic, I hope it's obvious hooks in the PCI root bridge
emulation.
[snip]
> > Rather than your "groups" idea, I've been mulling over whether we can
> > just expose the dependencies, configuration, and capabilities in sysfs
> > and build qemu commandlines to describe it. For instance, if we simply
> > start with creating iommu nodes in sysfs, we could create links under
> > each iommu directory to the devices behind them. Some kind of
> > capability file could define properties like whether it's page table
> > based or fixed iova window or the granularity of mapping the devices
> > behind it. Once we have that, we could probably make uiommu attach to
> > each of those nodes.
>
> Well, s/iommu/groups and you are pretty close to my original idea :-)
>
> I don't mind that much what the details are, but I like the idea of not
> having to construct a 3-pages command line every time I want to
> pass-through a device, most "simple" usage scenario don't care that
> much.
>
> > That means we know /dev/uiommu7 (random example) is our access to a
> > specific iommu with a given set of devices behind it.
>
> Linking those sysfs iommus or groups to a /dev/ entry is fine by me.
>
> > If that iommu is
> > a PE (via those capability files), then a user space entity (trying hard
> > not to call it libvirt) can unbind all those devices from the host,
> > maybe bind the ones it wants to assign to a guest to vfio and bind the
> > others to pci-stub for safe keeping. If you trust a user with
> > everything in a PE, bind all the devices to VFIO, chown all
> > the /dev/vfioX entries for those devices, and the /dev/uiommuX device.
> >
> > We might then come up with qemu command lines to describe interesting
> > configurations, such as:
> >
> > -device iommu,model=PAPR,uiommu=/dev/uiommu7,id=iommu.0 \
> > -device pci-bus,...,iommu=iommu0,id=pci.0 \
> > -device vfio,host=ssss:bb:dd.f,bus=pci.0,addr=dd.f,id=hostdev0
> >
> > The userspace entity would obviously need to put things in the same PE
> > in the right place, but it doesn't seem to take a lot of sysfs info to
> > get that right.
> >
> > Today we do DMA mapping via the VFIO device because the capabilities of
> > the IOMMU domains change depending on which devices are connected (for
> > VT-d, the least common denominator of the IOMMUs in play). Forcing the
> > DMA mappings through VFIO naturally forces the call order. If we moved
> > to something like above, we could switch the DMA mapping to the uiommu
> > device, since the IOMMU would have fixed capabilities.
>
> That makes sense.
>
> > What gaps would something like this leave for your IOMMU granularity
> > problems? I'll need to think through how it works when we don't want to
> > expose the iommu to the guest, maybe a model=none (default) that doesn't
> > need to be connected to a pci bus and maps all guest memory. Thanks,
>
> Well, I would map those "iommus" to PEs, so what remains is the path to
> put all the "other" bits and pieces such as inform qemu of the location
> and size of the MMIO segment(s) (so we can map the whole thing and not
> bother with individual BARs) etc...
My assumption is that PEs are largely defined by the iommus already.
Are MMIO segments a property of the iommu too? Thanks,
Alex
^ permalink raw reply
* [PATCH 00/15] ps3: Support more than the OtherOS lpar
From: Andre Heider @ 2011-08-01 20:02 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
This series addresses various issues and extends support when running
in lpars like GameOS. Included are some patches from Hector Martin, which
I found useful.
The ps3disk driver now creates multiple block devices instead of just one.
On the GameOS lpar we have access to all regions, and - depending on the
customizable layout - the linux partitions are likely not on the first.
The device names look similar the bsd slices, a bit unusual, but the best
I could think of. Better suggestions?
There're 2 new drivers: ps3vflash and ps3nflash. These are just modified
copies of the ps3disk driver:
diff -u drivers/block/ps3disk.c drivers/block/ps3vflash.c
and "worse":
diff -u drivers/block/ps3vflash.c drivers/block/ps3nflash.c
I'm not sure what the desired way to handle these similarities are. Should
that be merged to avoid code duplication? If so, how?
Patches are based on 2.6.39 since master doesn't boot with smp on my
console. I wasn't able to pinpoint the cause so far (not that I tried
too hard). If anything get accepted I'll rebase :)
All patches were tested with the AsbestOS bootloader from Hector
Martin (http://git.marcansoft.com/?p=asbestos.git) on a PS3 slim.
Note: There are various patches floating around from anonymous
developers. None of those are signed-off and had various issues.
While some of those do contain simliar changes, I redid everything
in this series from scratch (except the patches from Hector).
Please let me know If there're any issues!
Thanks,
Andre
Andre Heider (12):
ps3: MEMORY_HOTPLUG is not a requirement anymore
ps3: Detect the current lpar environment
ps3flash: Fix region align checks
ps3flash: Refuse to work in lpars other than OtherOS
ps3: Only prealloc the flash bounce buffer for the OtherOS lpar
ps3: Limit the number of regions per storage device
ps3stor_lib: Add support for multiple regions
ps3disk: Provide a gendisk per accessible region
ps3stor_lib: Add support for storage access flags
ps3disk: Use region flags
ps3: Add a vflash driver for lpars other than OtherOS
ps3: Add a NOR FLASH driver for PS3s without NAND
Hector Martin (3):
[PS3] Add udbg driver using the PS3 gelic Ethernet device
[PS3] Get lv1 high memory region from devtree
[PS3] Add region 1 memory early
arch/powerpc/Kconfig.debug | 8 +
arch/powerpc/include/asm/ps3.h | 9 +
arch/powerpc/include/asm/ps3stor.h | 11 +-
arch/powerpc/include/asm/udbg.h | 1 +
arch/powerpc/kernel/udbg.c | 2 +
arch/powerpc/platforms/ps3/Kconfig | 43 +++-
arch/powerpc/platforms/ps3/Makefile | 1 +
arch/powerpc/platforms/ps3/device-init.c | 16 +
arch/powerpc/platforms/ps3/gelic_udbg.c | 272 ++++++++++++++++
arch/powerpc/platforms/ps3/mm.c | 91 ++++---
arch/powerpc/platforms/ps3/platform.h | 5 +
arch/powerpc/platforms/ps3/repository.c | 19 ++
arch/powerpc/platforms/ps3/setup.c | 27 ++-
arch/powerpc/platforms/ps3/system-bus.c | 2 +
drivers/block/Makefile | 2 +
drivers/block/ps3disk.c | 136 ++++++---
drivers/block/ps3nflash.c | 473 +++++++++++++++++++++++++++
drivers/block/ps3vflash.c | 508 ++++++++++++++++++++++++++++++
drivers/char/ps3flash.c | 56 +++--
drivers/net/ps3_gelic_net.c | 3 +
drivers/net/ps3_gelic_net.h | 6 +
drivers/ps3/ps3stor_lib.c | 30 +-
drivers/scsi/ps3rom.c | 11 +-
23 files changed, 1617 insertions(+), 115 deletions(-)
create mode 100644 arch/powerpc/platforms/ps3/gelic_udbg.c
create mode 100644 drivers/block/ps3nflash.c
create mode 100644 drivers/block/ps3vflash.c
--
1.7.5.4
^ permalink raw reply
* [PATCH 01/15] [PS3] Add udbg driver using the PS3 gelic Ethernet device
From: Andre Heider @ 2011-08-01 20:02 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1312228986-32307-1-git-send-email-a.heider@gmail.com>
From: Hector Martin <hector@marcansoft.com>
Signed-off-by: Hector Martin <hector@marcansoft.com>
[a.heider: Various cleanups to make checkpatch.pl happy]
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/Kconfig.debug | 8 +
arch/powerpc/include/asm/udbg.h | 1 +
arch/powerpc/kernel/udbg.c | 2 +
arch/powerpc/platforms/ps3/Kconfig | 12 ++
arch/powerpc/platforms/ps3/Makefile | 1 +
arch/powerpc/platforms/ps3/gelic_udbg.c | 272 +++++++++++++++++++++++++++++++
drivers/net/ps3_gelic_net.c | 3 +
drivers/net/ps3_gelic_net.h | 6 +
8 files changed, 305 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/ps3/gelic_udbg.c
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 2d38a50..47edab6 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -267,6 +267,14 @@ config PPC_EARLY_DEBUG_USBGECKO
Select this to enable early debugging for Nintendo GameCube/Wii
consoles via an external USB Gecko adapter.
+config PPC_EARLY_DEBUG_PS3GELIC
+ bool "Early debugging through the PS3 Ethernet port"
+ depends on PPC_PS3
+ select PS3GELIC_UDBG
+ help
+ Select this to enable early debugging for the PlayStation3 via
+ UDP broadcasts sent out through the Ethernet port.
+
endchoice
config PPC_EARLY_DEBUG_44x_PHYSLOW
diff --git a/arch/powerpc/include/asm/udbg.h b/arch/powerpc/include/asm/udbg.h
index 11ae699..58f0ab9 100644
--- a/arch/powerpc/include/asm/udbg.h
+++ b/arch/powerpc/include/asm/udbg.h
@@ -52,6 +52,7 @@ extern void __init udbg_init_44x_as1(void);
extern void __init udbg_init_40x_realmode(void);
extern void __init udbg_init_cpm(void);
extern void __init udbg_init_usbgecko(void);
+extern void __init udbg_init_ps3gelic(void);
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_UDBG_H */
diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
index e39cad8..9ea9897 100644
--- a/arch/powerpc/kernel/udbg.c
+++ b/arch/powerpc/kernel/udbg.c
@@ -62,6 +62,8 @@ void __init udbg_early_init(void)
udbg_init_cpm();
#elif defined(CONFIG_PPC_EARLY_DEBUG_USBGECKO)
udbg_init_usbgecko();
+#elif defined(CONFIG_PPC_EARLY_DEBUG_PS3GELIC)
+ udbg_init_ps3gelic();
#endif
#ifdef CONFIG_PPC_EARLY_DEBUG
diff --git a/arch/powerpc/platforms/ps3/Kconfig b/arch/powerpc/platforms/ps3/Kconfig
index dfe316b..476d9d9 100644
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -148,4 +148,16 @@ config PS3_LPM
profiling support of the Cell processor with programs like
oprofile and perfmon2, then say Y or M, otherwise say N.
+config PS3GELIC_UDBG
+ bool "PS3 udbg output via UDP broadcasts on Ethernet"
+ depends on PPC_PS3
+ help
+ Enables udbg early debugging output by sending broadcast UDP
+ via the Ethernet port (UDP port number 18194).
+
+ This driver uses a trivial implementation and is independent
+ from the main network driver.
+
+ If in doubt, say N here.
+
endmenu
diff --git a/arch/powerpc/platforms/ps3/Makefile b/arch/powerpc/platforms/ps3/Makefile
index ac1bdf8..02b9e63 100644
--- a/arch/powerpc/platforms/ps3/Makefile
+++ b/arch/powerpc/platforms/ps3/Makefile
@@ -2,6 +2,7 @@ obj-y += setup.o mm.o time.o hvcall.o htab.o repository.o
obj-y += interrupt.o exports.o os-area.o
obj-y += system-bus.o
+obj-$(CONFIG_PS3GELIC_UDBG) += gelic_udbg.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_SPU_BASE) += spu.o
obj-y += device-init.o
diff --git a/arch/powerpc/platforms/ps3/gelic_udbg.c b/arch/powerpc/platforms/ps3/gelic_udbg.c
new file mode 100644
index 0000000..9b383bd
--- /dev/null
+++ b/arch/powerpc/platforms/ps3/gelic_udbg.c
@@ -0,0 +1,272 @@
+/*
+ * arch/powerpc/platforms/ps3/gelic_udbg.c
+ *
+ * udbg debug output routine via GELIC UDP broadcasts
+ * Copyright (C) 2010 Hector Martin <hector@marcansoft.com>
+ * Copyright (C) 2011 Andre Heider <a.heider@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ */
+
+#include <asm/io.h>
+#include <asm/udbg.h>
+#include <asm/lv1call.h>
+
+#define GELIC_BUS_ID 1
+#define GELIC_DEVICE_ID 0
+#define GELIC_DEBUG_PORT 18194
+#define GELIC_MAX_MESSAGE_SIZE 1000
+
+#define GELIC_LV1_GET_MAC_ADDRESS 1
+#define GELIC_LV1_GET_VLAN_ID 4
+#define GELIC_LV1_VLAN_TX_ETHERNET_0 2
+
+#define GELIC_DESCR_DMA_STAT_MASK 0xf0000000
+#define GELIC_DESCR_DMA_CARDOWNED 0xa0000000
+
+#define GELIC_DESCR_TX_DMA_IKE 0x00080000
+#define GELIC_DESCR_TX_DMA_NO_CHKSUM 0x00000000
+#define GELIC_DESCR_TX_DMA_FRAME_TAIL 0x00040000
+
+#define GELIC_DESCR_DMA_CMD_NO_CHKSUM (GELIC_DESCR_DMA_CARDOWNED | \
+ GELIC_DESCR_TX_DMA_IKE | \
+ GELIC_DESCR_TX_DMA_NO_CHKSUM)
+
+static u64 bus_addr;
+
+struct gelic_descr {
+ /* as defined by the hardware */
+ u32 buf_addr;
+ u32 buf_size;
+ u32 next_descr_addr;
+ u32 dmac_cmd_status;
+ u32 result_size;
+ u32 valid_size; /* all zeroes for tx */
+ u32 data_status;
+ u32 data_error; /* all zeroes for tx */
+} __attribute__((aligned(32)));
+
+struct debug_block {
+ struct gelic_descr descr;
+ u8 pkt[1520];
+} __packed;
+
+struct ethhdr {
+ u8 dest[6];
+ u8 src[6];
+ u16 type;
+} __packed;
+
+struct vlantag {
+ u16 vlan;
+ u16 subtype;
+} __packed;
+
+struct iphdr {
+ u8 ver_len;
+ u8 dscp_ecn;
+ u16 total_length;
+ u16 ident;
+ u16 frag_off_flags;
+ u8 ttl;
+ u8 proto;
+ u16 checksum;
+ u32 src;
+ u32 dest;
+} __packed;
+
+struct udphdr {
+ u16 src;
+ u16 dest;
+ u16 len;
+ u16 checksum;
+} __packed;
+
+static __iomem struct ethhdr *h_eth;
+static __iomem struct vlantag *h_vlan;
+static __iomem struct iphdr *h_ip;
+static __iomem struct udphdr *h_udp;
+
+static __iomem char *pmsg;
+static __iomem char *pmsgc;
+
+static __iomem struct debug_block dbg __attribute__((aligned(32)));
+
+static int header_size;
+
+static void map_dma_mem(int bus_id, int dev_id, void *start, size_t len,
+ u64 *real_bus_addr)
+{
+ s64 result;
+ u64 real_addr = ((u64)start) & 0x0fffffffffffffffUL;
+ u64 real_end = real_addr + len;
+ u64 map_start = real_addr & ~0xfff;
+ u64 map_end = (real_end + 0xfff) & ~0xfff;
+ u64 bus_addr = 0;
+
+ u64 flags = 0xf800000000000000UL;
+
+ result = lv1_allocate_device_dma_region(bus_id, dev_id,
+ map_end - map_start, 12, 0,
+ &bus_addr);
+ if (result)
+ lv1_panic(0);
+
+ result = lv1_map_device_dma_region(bus_id, dev_id, map_start,
+ bus_addr, map_end - map_start,
+ flags);
+ if (result)
+ lv1_panic(0);
+
+ *real_bus_addr = bus_addr + real_addr - map_start;
+}
+
+static int unmap_dma_mem(int bus_id, int dev_id, u64 bus_addr, size_t len)
+{
+ s64 result;
+ u64 real_bus_addr;
+
+ real_bus_addr = bus_addr & ~0xfff;
+ len += bus_addr - real_bus_addr;
+ len = (len + 0xfff) & ~0xfff;
+
+ result = lv1_unmap_device_dma_region(bus_id, dev_id, real_bus_addr,
+ len);
+ if (result)
+ return result;
+
+ return lv1_free_device_dma_region(bus_id, dev_id, real_bus_addr);
+}
+
+static void gelic_debug_init(void)
+{
+ s64 result;
+ u64 v2;
+ u64 mac;
+ u64 vlan_id;
+
+ result = lv1_open_device(GELIC_BUS_ID, GELIC_DEVICE_ID, 0);
+ if (result)
+ lv1_panic(0);
+
+ map_dma_mem(GELIC_BUS_ID, GELIC_DEVICE_ID, &dbg, sizeof(dbg),
+ &bus_addr);
+
+ memset(&dbg, 0, sizeof(dbg));
+
+ dbg.descr.buf_addr = bus_addr + offsetof(struct debug_block, pkt);
+
+ wmb();
+
+ result = lv1_net_control(GELIC_BUS_ID, GELIC_DEVICE_ID,
+ GELIC_LV1_GET_MAC_ADDRESS, 0, 0, 0,
+ &mac, &v2);
+ if (result)
+ lv1_panic(0);
+
+ mac <<= 16;
+
+ h_eth = (struct ethhdr *)dbg.pkt;
+
+ memset(&h_eth->dest, 0xff, 6);
+ memcpy(&h_eth->src, &mac, 6);
+
+ header_size = sizeof(struct ethhdr);
+
+ result = lv1_net_control(GELIC_BUS_ID, GELIC_DEVICE_ID,
+ GELIC_LV1_GET_VLAN_ID,
+ GELIC_LV1_VLAN_TX_ETHERNET_0, 0, 0,
+ &vlan_id, &v2);
+ if (result == 0) {
+ h_eth->type = 0x8100;
+
+ header_size += sizeof(struct vlantag);
+ h_vlan = (struct vlantag *)(h_eth + 1);
+ h_vlan->vlan = vlan_id;
+ h_vlan->subtype = 0x0800;
+ h_ip = (struct iphdr *)(h_vlan + 1);
+ } else {
+ h_eth->type = 0x0800;
+ h_ip = (struct iphdr *)(h_eth + 1);
+ }
+
+ header_size += sizeof(struct iphdr);
+ h_ip->ver_len = 0x45;
+ h_ip->ttl = 10;
+ h_ip->proto = 0x11;
+ h_ip->src = 0x00000000;
+ h_ip->dest = 0xffffffff;
+
+ header_size += sizeof(struct udphdr);
+ h_udp = (struct udphdr *)(h_ip + 1);
+ h_udp->src = GELIC_DEBUG_PORT;
+ h_udp->dest = GELIC_DEBUG_PORT;
+
+ pmsgc = pmsg = (char *)(h_udp + 1);
+}
+
+static void gelic_debug_shutdown(void)
+{
+ if (bus_addr)
+ unmap_dma_mem(GELIC_BUS_ID, GELIC_DEVICE_ID,
+ bus_addr, sizeof(dbg));
+ lv1_close_device(GELIC_BUS_ID, GELIC_DEVICE_ID);
+}
+
+static void gelic_sendbuf(int msgsize)
+{
+ u16 *p;
+ u32 sum;
+ int i;
+
+ dbg.descr.buf_size = header_size + msgsize;
+ h_ip->total_length = msgsize + sizeof(struct udphdr) +
+ sizeof(struct iphdr);
+ h_udp->len = msgsize + sizeof(struct udphdr);
+
+ h_ip->checksum = 0;
+ sum = 0;
+ p = (u16 *)h_ip;
+ for (i = 0; i < 5; i++)
+ sum += *p++;
+ h_ip->checksum = ~(sum + (sum >> 16));
+
+ dbg.descr.dmac_cmd_status = GELIC_DESCR_DMA_CMD_NO_CHKSUM |
+ GELIC_DESCR_TX_DMA_FRAME_TAIL;
+ dbg.descr.result_size = 0;
+ dbg.descr.data_status = 0;
+
+ wmb();
+
+ lv1_net_start_tx_dma(GELIC_BUS_ID, GELIC_DEVICE_ID, bus_addr, 0);
+
+ while ((dbg.descr.dmac_cmd_status & GELIC_DESCR_DMA_STAT_MASK) ==
+ GELIC_DESCR_DMA_CARDOWNED)
+ cpu_relax();
+}
+
+static void ps3gelic_udbg_putc(char ch)
+{
+ *pmsgc++ = ch;
+ if (ch == '\n' || (pmsgc-pmsg) >= GELIC_MAX_MESSAGE_SIZE) {
+ gelic_sendbuf(pmsgc-pmsg);
+ pmsgc = pmsg;
+ }
+}
+
+void __init udbg_init_ps3gelic(void)
+{
+ gelic_debug_init();
+ udbg_putc = ps3gelic_udbg_putc;
+}
+
+void udbg_shutdown_ps3gelic(void)
+{
+ udbg_putc = NULL;
+ gelic_debug_shutdown();
+}
+EXPORT_SYMBOL(udbg_shutdown_ps3gelic);
diff --git a/drivers/net/ps3_gelic_net.c b/drivers/net/ps3_gelic_net.c
index 035a676..4488655 100644
--- a/drivers/net/ps3_gelic_net.c
+++ b/drivers/net/ps3_gelic_net.c
@@ -1688,6 +1688,9 @@ static int __devinit ps3_gelic_driver_probe(struct ps3_system_bus_device *dev)
int result;
pr_debug("%s: called\n", __func__);
+
+ udbg_shutdown_ps3gelic();
+
result = ps3_open_hv_device(dev);
if (result) {
diff --git a/drivers/net/ps3_gelic_net.h b/drivers/net/ps3_gelic_net.h
index 07bdc17..57ef974 100644
--- a/drivers/net/ps3_gelic_net.h
+++ b/drivers/net/ps3_gelic_net.h
@@ -360,6 +360,12 @@ static inline void *port_priv(struct gelic_port *port)
return port->priv;
}
+#ifdef CONFIG_PPC_EARLY_DEBUG_PS3GELIC
+extern void udbg_shutdown_ps3gelic(void);
+#else
+static inline void udbg_shutdown_ps3gelic(void) {}
+#endif
+
extern int gelic_card_set_irq_mask(struct gelic_card *card, u64 mask);
/* shared netdev ops */
extern void gelic_card_up(struct gelic_card *card);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 02/15] [PS3] Get lv1 high memory region from devtree
From: Andre Heider @ 2011-08-01 20:02 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1312228986-32307-1-git-send-email-a.heider@gmail.com>
From: Hector Martin <hector@marcansoft.com>
This lets the bootloader preallocate the high lv1 region and pass its
location to the kernel through the devtree. Thus, it can be used to hold
the initrd. If the property doesn't exist, the kernel retains the old
behavior and attempts to allocate the region itself.
Signed-off-by: Hector Martin <hector@marcansoft.com>
[a.heider: Various cleanups to make checkpatch.pl happy]
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/platforms/ps3/mm.c | 61 +++++++++++++++++++++++++++++++++++++-
1 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/mm.c b/arch/powerpc/platforms/ps3/mm.c
index c204588..30bb096 100644
--- a/arch/powerpc/platforms/ps3/mm.c
+++ b/arch/powerpc/platforms/ps3/mm.c
@@ -110,6 +110,7 @@ struct map {
u64 htab_size;
struct mem_region rm;
struct mem_region r1;
+ int destroy_r1;
};
#define debug_dump_map(x) _debug_dump_map(x, __func__, __LINE__)
@@ -287,6 +288,49 @@ static void ps3_mm_region_destroy(struct mem_region *r)
}
}
+static int ps3_mm_scan_memory(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ struct mem_region *r = data;
+ void *p;
+ u64 prop[2];
+ unsigned long l;
+ char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+
+ if (type == NULL)
+ return 0;
+ if (strcmp(type, "memory") != 0)
+ return 0;
+
+ p = of_get_flat_dt_prop(node, "sony,lv1-highmem", &l);
+ if (p == NULL)
+ return 0;
+
+ BUG_ON(l != sizeof(prop));
+ memcpy(prop, p, sizeof(prop));
+
+ r->base = prop[0];
+ r->size = prop[1];
+ r->offset = r->base - map.rm.size;
+
+ return -1;
+}
+
+static int ps3_mm_get_devtree_highmem(struct mem_region *r)
+{
+ r->size = r->base = r->offset = 0;
+ of_scan_flat_dt(ps3_mm_scan_memory, r);
+
+ if (r->base && r->size) {
+ DBG("%s:%d got high region from devtree: %llxh %llxh\n",
+ __func__, __LINE__, r->base, r->size);
+ return 0;
+ } else {
+ DBG("%s:%d no high region in devtree...\n", __func__, __LINE__);
+ return -1;
+ }
+}
+
/**
* ps3_mm_add_memory - hot add memory
*/
@@ -303,6 +347,12 @@ static int __init ps3_mm_add_memory(void)
BUG_ON(!mem_init_done);
+ if (!map.r1.size) {
+ DBG("%s:%d: no region 1, not adding memory\n",
+ __func__, __LINE__);
+ return 0;
+ }
+
start_addr = map.rm.size;
start_pfn = start_addr >> PAGE_SHIFT;
nr_pages = (map.r1.size + PAGE_SIZE - 1) >> PAGE_SHIFT;
@@ -1219,7 +1269,13 @@ void __init ps3_mm_init(void)
/* arrange to do this in ps3_mm_add_memory */
- ps3_mm_region_create(&map.r1, map.total - map.rm.size);
+
+ if (ps3_mm_get_devtree_highmem(&map.r1) == 0) {
+ map.destroy_r1 = 0;
+ } else {
+ ps3_mm_region_create(&map.r1, map.total - map.rm.size);
+ map.destroy_r1 = 1;
+ }
/* correct map.total for the real total amount of memory we use */
map.total = map.rm.size + map.r1.size;
@@ -1233,5 +1289,6 @@ void __init ps3_mm_init(void)
void ps3_mm_shutdown(void)
{
- ps3_mm_region_destroy(&map.r1);
+ if (map.destroy_r1)
+ ps3_mm_region_destroy(&map.r1);
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 03/15] [PS3] Add region 1 memory early
From: Andre Heider @ 2011-08-01 20:02 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1312228986-32307-1-git-send-email-a.heider@gmail.com>
From: Hector Martin <hector@marcansoft.com>
Signed-off-by: Hector Martin <hector@marcansoft.com>
[a.heider: Various cleanups to make checkpatch.pl happy]
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/platforms/ps3/mm.c | 62 +++++++--------------------------------
1 files changed, 11 insertions(+), 51 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/mm.c b/arch/powerpc/platforms/ps3/mm.c
index 30bb096..15876d6 100644
--- a/arch/powerpc/platforms/ps3/mm.c
+++ b/arch/powerpc/platforms/ps3/mm.c
@@ -331,57 +331,6 @@ static int ps3_mm_get_devtree_highmem(struct mem_region *r)
}
}
-/**
- * ps3_mm_add_memory - hot add memory
- */
-
-static int __init ps3_mm_add_memory(void)
-{
- int result;
- unsigned long start_addr;
- unsigned long start_pfn;
- unsigned long nr_pages;
-
- if (!firmware_has_feature(FW_FEATURE_PS3_LV1))
- return -ENODEV;
-
- BUG_ON(!mem_init_done);
-
- if (!map.r1.size) {
- DBG("%s:%d: no region 1, not adding memory\n",
- __func__, __LINE__);
- return 0;
- }
-
- start_addr = map.rm.size;
- start_pfn = start_addr >> PAGE_SHIFT;
- nr_pages = (map.r1.size + PAGE_SIZE - 1) >> PAGE_SHIFT;
-
- DBG("%s:%d: start_addr %lxh, start_pfn %lxh, nr_pages %lxh\n",
- __func__, __LINE__, start_addr, start_pfn, nr_pages);
-
- result = add_memory(0, start_addr, map.r1.size);
-
- if (result) {
- pr_err("%s:%d: add_memory failed: (%d)\n",
- __func__, __LINE__, result);
- return result;
- }
-
- memblock_add(start_addr, map.r1.size);
- memblock_analyze();
-
- result = online_pages(start_pfn, nr_pages);
-
- if (result)
- pr_err("%s:%d: online_pages failed: (%d)\n",
- __func__, __LINE__, result);
-
- return result;
-}
-
-device_initcall(ps3_mm_add_memory);
-
/*============================================================================*/
/* dma routines */
/*============================================================================*/
@@ -1280,6 +1229,17 @@ void __init ps3_mm_init(void)
/* correct map.total for the real total amount of memory we use */
map.total = map.rm.size + map.r1.size;
+ if (!map.r1.size) {
+ DBG("%s:%d: no region 1, not adding memory\n",
+ __func__, __LINE__);
+ } else {
+ DBG("%s:%d: adding memory: start %llxh, size %llxh\n",
+ __func__, __LINE__, map.rm.size, map.r1.size);
+
+ memblock_add(map.rm.size, map.r1.size);
+ memblock_analyze();
+ }
+
DBG(" <- %s:%d\n", __func__, __LINE__);
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 04/15] ps3: MEMORY_HOTPLUG is not a requirement anymore
From: Andre Heider @ 2011-08-01 20:02 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1312228986-32307-1-git-send-email-a.heider@gmail.com>
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/platforms/ps3/Kconfig | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/Kconfig b/arch/powerpc/platforms/ps3/Kconfig
index 476d9d9..84df5c8 100644
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -7,7 +7,6 @@ config PPC_PS3
select USB_OHCI_BIG_ENDIAN_MMIO
select USB_ARCH_HAS_EHCI
select USB_EHCI_BIG_ENDIAN_MMIO
- select MEMORY_HOTPLUG
select PPC_PCI_CHOICE
help
This option enables support for the Sony PS3 game console
--
1.7.5.4
^ permalink raw reply related
* [PATCH 05/15] ps3: Detect the current lpar environment
From: Andre Heider @ 2011-08-01 20:02 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1312228986-32307-1-git-send-email-a.heider@gmail.com>
There is more than the OtherOS lpar the kernel can be launched in.
Detect it by reading the ss laid repository node, and be verbose about
it.
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/include/asm/ps3.h | 7 +++++++
arch/powerpc/platforms/ps3/platform.h | 4 ++++
arch/powerpc/platforms/ps3/repository.c | 19 +++++++++++++++++++
arch/powerpc/platforms/ps3/setup.c | 22 ++++++++++++++++++++++
4 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/ps3.h b/arch/powerpc/include/asm/ps3.h
index 7f065e1..136354a 100644
--- a/arch/powerpc/include/asm/ps3.h
+++ b/arch/powerpc/include/asm/ps3.h
@@ -39,6 +39,13 @@ union ps3_firmware_version {
void ps3_get_firmware_version(union ps3_firmware_version *v);
int ps3_compare_firmware_version(u16 major, u16 minor, u16 rev);
+enum ps3_ss_laid {
+ PS3_SS_LAID_GAMEOS = 0x1070000002000001UL,
+ PS3_SS_LAID_OTHEROS = 0x1080000004000001UL,
+};
+
+enum ps3_ss_laid ps3_get_ss_laid(void);
+
/* 'Other OS' area */
enum ps3_param_av_multi_out {
diff --git a/arch/powerpc/platforms/ps3/platform.h b/arch/powerpc/platforms/ps3/platform.h
index 9a196a8..1ba15b8 100644
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -232,4 +232,8 @@ int ps3_repository_read_spu_resource_id(unsigned int res_index,
int ps3_repository_read_vuart_av_port(unsigned int *port);
int ps3_repository_read_vuart_sysmgr_port(unsigned int *port);
+/* repository ss info */
+
+int ps3_repository_read_ss_laid(enum ps3_ss_laid *laid);
+
#endif
diff --git a/arch/powerpc/platforms/ps3/repository.c b/arch/powerpc/platforms/ps3/repository.c
index 5e304c2..6fa3e96 100644
--- a/arch/powerpc/platforms/ps3/repository.c
+++ b/arch/powerpc/platforms/ps3/repository.c
@@ -1002,6 +1002,25 @@ int ps3_repository_read_lpm_privileges(unsigned int be_index, u64 *lpar,
lpar, rights);
}
+/**
+ * ps3_repository_read_ss_laid - Read the lpar auth id
+ */
+
+int ps3_repository_read_ss_laid(enum ps3_ss_laid *laid)
+{
+ int result;
+ u64 id, v1;
+
+ lv1_get_logical_partition_id(&id);
+ result = read_node(PS3_LPAR_ID_PME,
+ make_first_field("ss", 0),
+ make_field("laid", 0),
+ id, 0,
+ &v1, NULL);
+ *laid = v1;
+ return result;
+}
+
#if defined(DEBUG)
int ps3_repository_dump_resource_info(const struct ps3_repository_device *repo)
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index 149bea2..f430279 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -47,6 +47,7 @@ DEFINE_MUTEX(ps3_gpu_mutex);
EXPORT_SYMBOL_GPL(ps3_gpu_mutex);
static union ps3_firmware_version ps3_firmware_version;
+static enum ps3_ss_laid ps3_ss_laid;
void ps3_get_firmware_version(union ps3_firmware_version *v)
{
@@ -68,6 +69,12 @@ int ps3_compare_firmware_version(u16 major, u16 minor, u16 rev)
}
EXPORT_SYMBOL_GPL(ps3_compare_firmware_version);
+enum ps3_ss_laid ps3_get_ss_laid(void)
+{
+ return ps3_ss_laid;
+}
+EXPORT_SYMBOL_GPL(ps3_get_ss_laid);
+
static void ps3_power_save(void)
{
/*
@@ -192,6 +199,7 @@ static int ps3_set_dabr(unsigned long dabr)
static void __init ps3_setup_arch(void)
{
+ const char *laid_str;
DBG(" -> %s:%d\n", __func__, __LINE__);
@@ -200,6 +208,20 @@ static void __init ps3_setup_arch(void)
ps3_firmware_version.major, ps3_firmware_version.minor,
ps3_firmware_version.rev);
+ ps3_repository_read_ss_laid(&ps3_ss_laid);
+ switch (ps3_ss_laid) {
+ case PS3_SS_LAID_GAMEOS:
+ laid_str = "GameOS";
+ break;
+ case PS3_SS_LAID_OTHEROS:
+ laid_str = "OtherOS";
+ break;
+ default:
+ laid_str = "unknown";
+ break;
+ }
+ printk(KERN_INFO "Running in %s lpar\n", laid_str);
+
ps3_spu_set_platform();
#ifdef CONFIG_SMP
--
1.7.5.4
^ permalink raw reply related
* [PATCH 06/15] ps3flash: Fix region align checks
From: Andre Heider @ 2011-08-01 20:02 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1312228986-32307-1-git-send-email-a.heider@gmail.com>
The region fields used by the align checks are set in
ps3stor_setup(), so move those after that call.
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
drivers/char/ps3flash.c | 30 +++++++++++++++---------------
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/char/ps3flash.c b/drivers/char/ps3flash.c
index 85c004a..69c734a 100644
--- a/drivers/char/ps3flash.c
+++ b/drivers/char/ps3flash.c
@@ -360,21 +360,6 @@ static int __devinit ps3flash_probe(struct ps3_system_bus_device *_dev)
int error;
unsigned long tmp;
- tmp = dev->regions[dev->region_idx].start*dev->blk_size;
- if (tmp % FLASH_BLOCK_SIZE) {
- dev_err(&dev->sbd.core,
- "%s:%u region start %lu is not aligned\n", __func__,
- __LINE__, tmp);
- return -EINVAL;
- }
- tmp = dev->regions[dev->region_idx].size*dev->blk_size;
- if (tmp % FLASH_BLOCK_SIZE) {
- dev_err(&dev->sbd.core,
- "%s:%u region size %lu is not aligned\n", __func__,
- __LINE__, tmp);
- return -EINVAL;
- }
-
/* use static buffer, kmalloc cannot allocate 256 KiB */
if (!ps3flash_bounce_buffer.address)
return -ENODEV;
@@ -405,6 +390,21 @@ static int __devinit ps3flash_probe(struct ps3_system_bus_device *_dev)
if (error)
goto fail_free_priv;
+ tmp = dev->regions[dev->region_idx].start*dev->blk_size;
+ if (tmp % FLASH_BLOCK_SIZE) {
+ dev_err(&dev->sbd.core,
+ "%s:%u region start %lu is not aligned\n", __func__,
+ __LINE__, tmp);
+ return -EINVAL;
+ }
+ tmp = dev->regions[dev->region_idx].size*dev->blk_size;
+ if (tmp % FLASH_BLOCK_SIZE) {
+ dev_err(&dev->sbd.core,
+ "%s:%u region size %lu is not aligned\n", __func__,
+ __LINE__, tmp);
+ return -EINVAL;
+ }
+
ps3flash_misc.parent = &dev->sbd.core;
error = misc_register(&ps3flash_misc);
if (error) {
--
1.7.5.4
^ permalink raw reply related
* [PATCH 07/15] ps3flash: Refuse to work in lpars other than OtherOS
From: Andre Heider @ 2011-08-01 20:02 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1312228986-32307-1-git-send-email-a.heider@gmail.com>
The driver implements a character and misc device, meant for the
axed OtherOS to exchange various settings with GameOS.
Since Firmware 3.21 there is no GameOS support anymore to write these
settings, so limit the driver to the OtherOS environment.
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/platforms/ps3/Kconfig | 1 +
drivers/char/ps3flash.c | 7 +++++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/Kconfig b/arch/powerpc/platforms/ps3/Kconfig
index 84df5c8..5eb956a 100644
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -121,6 +121,7 @@ config PS3_FLASH
This support is required to access the PS3 FLASH ROM, which
contains the boot loader and some boot options.
+ This driver only supports the deprecated OtherOS LPAR.
In general, all users will say Y or M.
As this driver needs a fixed buffer of 256 KiB of memory, it can
diff --git a/drivers/char/ps3flash.c b/drivers/char/ps3flash.c
index 69c734a..b1e8659 100644
--- a/drivers/char/ps3flash.c
+++ b/drivers/char/ps3flash.c
@@ -25,6 +25,7 @@
#include <asm/lv1call.h>
#include <asm/ps3stor.h>
+#include <asm/firmware.h>
#define DEVICE_NAME "ps3flash"
@@ -455,6 +456,12 @@ static struct ps3_system_bus_driver ps3flash = {
static int __init ps3flash_init(void)
{
+ if (!firmware_has_feature(FW_FEATURE_PS3_LV1))
+ return -ENODEV;
+
+ if (ps3_get_ss_laid() != PS3_SS_LAID_OTHEROS)
+ return -ENODEV;
+
return ps3_system_bus_driver_register(&ps3flash);
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 08/15] ps3: Only prealloc the flash bounce buffer for the OtherOS lpar
From: Andre Heider @ 2011-08-01 20:02 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1312228986-32307-1-git-send-email-a.heider@gmail.com>
It's only used by the ps3flash driver, which only supports the
OtherOS lpar.
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/platforms/ps3/setup.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index f430279..923be8a 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -233,7 +233,10 @@ static void __init ps3_setup_arch(void)
#endif
prealloc_ps3fb_videomemory();
- prealloc_ps3flash_bounce_buffer();
+
+ /* the ps3flash driver only works for OtherOS */
+ if (ps3_get_ss_laid() == PS3_SS_LAID_OTHEROS)
+ prealloc_ps3flash_bounce_buffer();
ppc_md.power_save = ps3_power_save;
ps3_os_area_init();
--
1.7.5.4
^ permalink raw reply related
* [PATCH 09/15] ps3: Limit the number of regions per storage device
From: Andre Heider @ 2011-08-01 20:03 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1312228986-32307-1-git-send-email-a.heider@gmail.com>
There can be only 8 regions, add a sanity check
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/include/asm/ps3stor.h | 1 +
arch/powerpc/platforms/ps3/device-init.c | 8 ++++++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/ps3stor.h b/arch/powerpc/include/asm/ps3stor.h
index 6fcaf71..d51e53c 100644
--- a/arch/powerpc/include/asm/ps3stor.h
+++ b/arch/powerpc/include/asm/ps3stor.h
@@ -25,6 +25,7 @@
#include <asm/ps3.h>
+#define PS3_STORAGE_MAX_REGIONS (8)
struct ps3_storage_region {
unsigned int id;
diff --git a/arch/powerpc/platforms/ps3/device-init.c b/arch/powerpc/platforms/ps3/device-init.c
index 6c4b583..830d741 100644
--- a/arch/powerpc/platforms/ps3/device-init.c
+++ b/arch/powerpc/platforms/ps3/device-init.c
@@ -349,6 +349,14 @@ static int ps3_setup_storage_dev(const struct ps3_repository_device *repo,
return -ENODEV;
}
+ if (num_regions > PS3_STORAGE_MAX_REGIONS) {
+ pr_warning("%s:%u: device %u:%u reported %u regions, "
+ "limiting to %u\n", __func__, __LINE__,
+ num_regions, repo->bus_index, repo->dev_index,
+ PS3_STORAGE_MAX_REGIONS);
+ num_regions = PS3_STORAGE_MAX_REGIONS;
+ }
+
pr_debug("%s:%u: (%u:%u:%u): port %llu blk_size %llu num_blocks %llu "
"num_regions %u\n", __func__, __LINE__, repo->bus_index,
repo->dev_index, repo->dev_type, port, blk_size, num_blocks,
--
1.7.5.4
^ permalink raw reply related
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