LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/2] Support internal I2S clock sources on MPC5200
From: Jon Smirl @ 2008-07-22 23:53 UTC (permalink / raw)
  To: linuxppc-dev, alsa-devel

Support internal I2S clock sources on MPC5200

Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---

 sound/soc/fsl/mpc5200_psc_i2s.c |   58 ++++++++++++++++++++++++++++++++++-----
 sound/soc/fsl/mpc5200_psc_i2s.h |   13 +++++++++
 2 files changed, 64 insertions(+), 7 deletions(-)
 create mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h

diff --git a/sound/soc/fsl/mpc5200_psc_i2s.c b/sound/soc/fsl/mpc5200_psc_i2s.c
index 8692329..f028f61 100644
--- a/sound/soc/fsl/mpc5200_psc_i2s.c
+++ b/sound/soc/fsl/mpc5200_psc_i2s.c
@@ -23,8 +23,12 @@
 
 #include <sysdev/bestcomm/bestcomm.h>
 #include <sysdev/bestcomm/gen_bd.h>
+#include <asm/time.h>
+#include <asm/mpc52xx.h>
 #include <asm/mpc52xx_psc.h>
 
+#include "mpc5200_psc_i2s.h"
+
 MODULE_AUTHOR("Grant Likely <grant.likely@secretlab.ca>");
 MODULE_DESCRIPTION("Freescale MPC5200 PSC in I2S mode ASoC Driver");
 MODULE_LICENSE("GPL");
@@ -93,6 +97,7 @@ struct psc_i2s {
 	struct snd_soc_dai dai;
 	spinlock_t lock;
 	u32 sicr;
+	uint sysclk;
 
 	/* per-stream data */
 	struct psc_i2s_stream playback;
@@ -224,6 +229,7 @@ static int psc_i2s_hw_params(struct snd_pcm_substream *substream,
 {
 	struct snd_soc_pcm_runtime *rtd = substream->private_data;
 	struct psc_i2s *psc_i2s = rtd->dai->cpu_dai->private_data;
+	uint bits, framesync, bitclk, value;
 	u32 mode;
 
 	dev_dbg(psc_i2s->dev, "%s(substream=%p) p_size=%i p_bytes=%i"
@@ -235,15 +241,19 @@ static int psc_i2s_hw_params(struct snd_pcm_substream *substream,
 	switch (params_format(params)) {
 	case SNDRV_PCM_FORMAT_S8:
 		mode = MPC52xx_PSC_SICR_SIM_CODEC_8;
+		bits = 8;
 		break;
 	case SNDRV_PCM_FORMAT_S16_BE:
 		mode = MPC52xx_PSC_SICR_SIM_CODEC_16;
+		bits = 16;
 		break;
 	case SNDRV_PCM_FORMAT_S24_BE:
 		mode = MPC52xx_PSC_SICR_SIM_CODEC_24;
+		bits = 24;
 		break;
 	case SNDRV_PCM_FORMAT_S32_BE:
 		mode = MPC52xx_PSC_SICR_SIM_CODEC_32;
+		bits = 32;
 		break;
 	default:
 		dev_dbg(psc_i2s->dev, "invalid format\n");
@@ -251,7 +261,24 @@ static int psc_i2s_hw_params(struct snd_pcm_substream *substream,
 	}
 	out_be32(&psc_i2s->psc_regs->sicr, psc_i2s->sicr | mode);
 
-	snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer);
+	if (psc_i2s->sysclk) {
+		framesync = bits * 2;
+		bitclk = (psc_i2s->sysclk) / (params_rate(params) * framesync);
+		
+		/* bitclk field is byte swapped due to mpc5200/b compatibility */
+		value = ((framesync - 1) << 24) |
+			(((bitclk - 1) & 0xFF) << 16) | ((bitclk - 1) & 0xFF00);
+		
+		dev_dbg(psc_i2s->dev, "%s(substream=%p) rate=%i sysclk=%i"
+			" framesync=%i bitclk=%i reg=%X\n",
+			__FUNCTION__, substream, params_rate(params), psc_i2s->sysclk,
+			framesync, bitclk, value);
+		
+		out_be32(&psc_i2s->psc_regs->ccr, value);
+		out_8(&psc_i2s->psc_regs->ctur, bits - 1);
+	}
+	
+  	snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer);
 
 	return 0;
 }
@@ -429,9 +456,29 @@ static int psc_i2s_set_sysclk(struct snd_soc_dai *cpu_dai,
 			      int clk_id, unsigned int freq, int dir)
 {
 	struct psc_i2s *psc_i2s = cpu_dai->private_data;
-	dev_dbg(psc_i2s->dev, "psc_i2s_set_sysclk(cpu_dai=%p, dir=%i)\n",
-				cpu_dai, dir);
-	return (dir == SND_SOC_CLOCK_IN) ? 0 : -EINVAL;
+	int clkdiv, err; 
+	dev_dbg(psc_i2s->dev, "psc_i2s_set_sysclk(cpu_dai=%p, freq=%u, dir=%i)\n",
+				cpu_dai, freq, dir);
+	if (dir == SND_SOC_CLOCK_OUT) {
+		psc_i2s->sysclk = freq;
+		if (clk_id == MPC52xx_CLK_CELLSLAVE) {
+			psc_i2s->sicr |= MPC52xx_PSC_SICR_CELLSLAVE | MPC52xx_PSC_SICR_GENCLK;
+		} else { /* MPC52xx_CLK_INTERNAL */
+			psc_i2s->sicr &= ~MPC52xx_PSC_SICR_CELLSLAVE;
+			psc_i2s->sicr |= MPC52xx_PSC_SICR_GENCLK;
+
+			clkdiv = ppc_proc_freq / freq;
+			err = ppc_proc_freq % freq;
+			if (err > freq / 2)
+				clkdiv++;
+
+			dev_dbg(psc_i2s->dev, "psc_i2s_set_sysclk(clkdiv %d freq error=%ldHz)\n",
+					clkdiv, (ppc_proc_freq / clkdiv - freq));
+				
+			return mpc52xx_set_psc_clkdiv(psc_i2s->dai.id + 1, clkdiv); 
+		}
+	}
+	return 0;
 }
 
 /**
@@ -784,9 +831,6 @@ static int __devinit psc_i2s_of_probe(struct of_device *op,
 	/* Configure the serial interface mode; defaulting to CODEC8 mode */
 	psc_i2s->sicr = MPC52xx_PSC_SICR_DTS1 | MPC52xx_PSC_SICR_I2S |
 			MPC52xx_PSC_SICR_CLKPOL;
-	if (of_get_property(op->node, "fsl,cellslave", NULL))
-		psc_i2s->sicr |= MPC52xx_PSC_SICR_CELLSLAVE |
-				 MPC52xx_PSC_SICR_GENCLK;
 	out_be32(&psc_i2s->psc_regs->sicr,
 		 psc_i2s->sicr | MPC52xx_PSC_SICR_SIM_CODEC_8);
 
diff --git a/sound/soc/fsl/mpc5200_psc_i2s.h b/sound/soc/fsl/mpc5200_psc_i2s.h
new file mode 100644
index 0000000..0e0a84e
--- /dev/null
+++ b/sound/soc/fsl/mpc5200_psc_i2s.h
@@ -0,0 +1,13 @@
+/*
+ * Freescale MPC5200 PSC in I2S mode
+ * ALSA SoC Digital Audio Interface (DAI) driver
+ *
+ */
+ 
+#ifndef __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__
+#define __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__
+
+#define MPC52xx_CLK_INTERNAL 0
+#define MPC52xx_CLK_CELLSLAVE 1
+
+#endif /* __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__ */

^ permalink raw reply related

* [PATCH 2/2] Allow a custom ASOC machine driver with soc-of-simple
From: Jon Smirl @ 2008-07-22 23:53 UTC (permalink / raw)
  To: linuxppc-dev, alsa-devel
In-Reply-To: <20080722235349.11648.90112.stgit@terra>

Allow a custom ASOC machine driver with soc-of-simple

Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---

 include/sound/soc-of-simple.h |    2 ++
 sound/soc/fsl/soc-of-simple.c |   26 +++++++++++++++++++++-----
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/include/sound/soc-of-simple.h b/include/sound/soc-of-simple.h
index 696fc51..1e83f2f 100644
--- a/include/sound/soc-of-simple.h
+++ b/include/sound/soc-of-simple.h
@@ -18,4 +18,6 @@ int of_snd_soc_register_platform(struct snd_soc_platform *platform,
 				 struct device_node *node,
 				 struct snd_soc_dai *cpu_dai);
 
+void of_snd_soc_register_machine(char *name, struct snd_soc_ops *ops);
+
 #endif /* _INCLUDE_SOC_OF_H_ */
diff --git a/sound/soc/fsl/soc-of-simple.c b/sound/soc/fsl/soc-of-simple.c
index 0382fda..dd2fa23 100644
--- a/sound/soc/fsl/soc-of-simple.c
+++ b/sound/soc/fsl/soc-of-simple.c
@@ -38,8 +38,8 @@ struct of_snd_soc_device {
 	struct device_node *codec_node;
 };
 
-static struct snd_soc_ops of_snd_soc_ops = {
-};
+static struct snd_soc_ops *machine_ops = NULL;
+static char *machine_name = NULL;
 
 static struct of_snd_soc_device *
 of_snd_soc_get_device(struct device_node *codec_node)
@@ -61,7 +61,7 @@ of_snd_soc_get_device(struct device_node *codec_node)
 	of_soc->machine.dai_link = &of_soc->dai_link;
 	of_soc->machine.num_links = 1;
 	of_soc->device.machine = &of_soc->machine;
-	of_soc->dai_link.ops = &of_snd_soc_ops;
+	of_soc->dai_link.ops = machine_ops;
 	list_add(&of_soc->list, &of_snd_soc_device_list);
 
 	return of_soc;
@@ -74,7 +74,7 @@ static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
 
 	/* Only register the device if both the codec and platform have
 	 * been registered */
-	if ((!of_soc->device.codec_data) || (!of_soc->platform_node))
+	if ((!of_soc->device.codec_data) || (!of_soc->platform_node) || !machine_name)
 		return;
 
 	pr_info("platform<-->codec match achieved; registering machine\n");
@@ -159,7 +159,7 @@ int of_snd_soc_register_platform(struct snd_soc_platform *platform,
 	of_soc->platform_node = node;
 	of_soc->dai_link.cpu_dai = cpu_dai;
 	of_soc->device.platform = platform;
-	of_soc->machine.name = of_soc->dai_link.cpu_dai->name;
+	of_soc->machine.name = machine_name;
 
 	/* Now try to register the SoC device */
 	of_snd_soc_register_device(of_soc);
@@ -169,3 +169,19 @@ int of_snd_soc_register_platform(struct snd_soc_platform *platform,
 	return rc;
 }
 EXPORT_SYMBOL_GPL(of_snd_soc_register_platform);
+
+void of_snd_soc_register_machine(char *name, struct snd_soc_ops *ops)
+{
+	struct of_snd_soc_device *of_soc;
+	
+	machine_name = name;
+	machine_ops = ops;
+	
+	list_for_each_entry(of_soc, &of_snd_soc_device_list, list) {
+		of_soc->dai_link.ops = machine_ops;
+		of_soc->machine.name = machine_name;
+		of_snd_soc_register_device(of_soc);
+	}
+
+}
+EXPORT_SYMBOL_GPL(of_snd_soc_register_machine);

^ permalink raw reply related

* Re: Linuxppc-embedded Digest, Vol 47, Issue 39
From: Duy-Ky Nguyen @ 2008-07-22 23:59 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <mailman.401.1216756203.2828.linuxppc-embedded@ozlabs.org>

Hello Scott,

We have One_Second_IRR() using PPS (Pulse Per Second) as external interrupt 
implemented on all our comapny products.
I used GPIO interrupt in 1 product using MPC8272 (arch/ppc) and it works 
fine.

Now I'm trying to use the same way with MPC8313 (arch/powerpc) but failed.

I fixed my mistake by include a device node "gpio" in the DTS file 
arch/powerpc/boot/dts/mpc8313erdb.dts

  gpio@c00 {
   linux,phandle = <c00>;
   device_type = "gpio";
   compatible = "fsl-gpio";
   reg = <c00 100>;
   interrupts = <4a 8>; /* IRQ ID 74, edge trigger */
   interrupt-parent = <700>;
  };

Using DTC to compile DTS for DTB and check DTB in binary format and found 
the new node really there. I set the size 0x3000 so the original and new DTS 
have the same file size of 12 KB

dtc -b 0 -V 17 -p 0x3000 -I dts -O dtb -f ${1}.dts > ${1}.dtb

I then have the code segment below to access the node and request interrupt

## Start of code
 struct device_node *np = NULL;

 np = of_find_node_by_type(np, "gpio");    // is it correct ???
 if (np != NULL) {
  printk("Got device node from device tree\n");
 }

 virq = irq_of_parse_and_map(np, 0);    // unsigned return, so return of 0 
must be error ?

// int return for request_irq() so return negative number must be error
 result = request_irq (virq,  //
      ppc_ISR,  // ISR
      IRQF_SHARED,
      DEVICE_NAME,   // LCS_dev name
      NULL);   // LCS_dev ID

## End of code

I have screen capture for error in the code above at the end of this email

I'm not sure if I have the right way in finding the node and in mapping the 
"virq" ?

Your help is very much appreciated, Scott

Best Regards,

^^Duy-Ky


## Start of screen capture for error in requesting interrupt

Unable to handle kernel paging request for data at address 0x00000014
Faulting instruction address: 0xc000d1e8
Oops: Kernel access of bad area, sig: 11 [#1]

Modules linked in: ppc_drv
NIP: C000D1E8 LR: C000D274 CTR: C0006088
REGS: c783dd20 TRAP: 0300   Not tainted  (2.6.20)
MSR: 00009032 <EE,ME,IR,DR>  CR: 22000442  XER: 00000000
DAR: 00000014, DSISR: 20000000
TASK = c03bdbd0[765] 'rrgg' THREAD: c783c000
GPR00: C000D274 C783DDD0 C03BDBD0 00000000 C0282BA8 C783DE08 C786EA60 
00000000
GPR08: C034F280 00000000 C0282E31 C0006088 22000442 10018D00 07FFD000 
28000422
GPR16: 10090000 100B0000 100B7318 00000000 00000000 00000000 100BDBA8 
100BDBE8
GPR24: 100BDAE8 00000000 00000000 C786EA60 FFFFFFEA C783DE08 C0282BA8 
00000000
Call Trace:
[C783DDD0] [C7FD5468]  (unreliable)
[C783DDF0] [C000D274]
[C783DE00] [C0009FC8]
[C783DE30] [C000609C]
[C783DE60] [C9072054]
[C783DE70] [C0063E5C]
[C783DEA0] [C005FFAC]
[C783DEC0] [C0060244]
[C783DF20] [C00602B8]
[C783DF40] [C000F540]
--- Exception: c01Instruction dump:
409effc8 80030024 900b0020 4e800020 7d800026 9421ffe0 7c0802a6 bfa10014
7c9e2378 7cbd2b78 91810010 90010024 <83e30014> 2f9f0000 419e0028 2e050000
 Segmentation fault

## End of capture

----- Original Message ----- 
From: <linuxppc-embedded-request@ozlabs.org>
To: <linuxppc-embedded@ozlabs.org>
Sent: Tuesday, July 22, 2008 12:50 PM
Subject: Linuxppc-embedded Digest, Vol 47, Issue 39


> Send Linuxppc-embedded mailing list submissions to
> linuxppc-embedded@ozlabs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> or, via email, send a message with subject or body 'help' to
> linuxppc-embedded-request@ozlabs.org
>
> You can reach the person managing the list at
> linuxppc-embedded-owner@ozlabs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linuxppc-embedded digest..."
>
>
> Today's Topics:
>
>   1. Re: how to allocate 9MB of memory in kernel ? (Arnd Bergmann)
>   2. Re: Help: Kernel BUG with U-boot 1.1.4 and kernel 2.6.23
>      scanning PCIe on a MPC8641D board (Jon Loeliger)
>   3. Re: Failure of request_irq()  for MPC8313 using arch=powerpc
>      (Scott Wood)
>   4. Re: Problem with cuImage Linux entry from old U-boot (Scott Wood)
>   5. RE: Problem with cuImage Linux entry from old U-boot
>      (Mike Timmons)
>   6. Re: Problem with cuImage Linux entry from old U-boot (Scott Wood)
>   7. [OT] write flash on MPC5200 board via jtag (Albrecht Dre?)
>   8. RE: Problem with cuImage Linux entry from old U-boot
>      (Stephen Horton)
>   9. Re: [PATCH] Add AMCC Arches 460GT eval board support to
>      platforms/44x (Victor Gallardo)
>  10. Re: How to create custom ramdisk  (Ron Sass)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 22 Jul 2008 17:12:51 +0200
> From: Arnd Bergmann <arnd@arndb.de>
> Subject: Re: how to allocate 9MB of memory in kernel ?
> To: linuxppc-embedded@ozlabs.org
> Cc: Misbah khan <misbah_khan@engineer.com>
> Message-ID: <200807221712.52030.arnd@arndb.de>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> On Tuesday 22 July 2008, Misbah khan wrote:
>> First of all let me thank you for your valuable suggessions ...
>>
>> 1. I wanted to allocate 9MB in kernel and wanted that memory to be mapped 
>> to
>> the physically continews SDRAM memory. but till now i could not found a 
>> way
>> to do so ???
>>
>> 2. So i thought to use ioremap to map SDRAM and make it accessible to 
>> user
>> using mmap technique but there is only one doubt and that is will it be
>> secure and stable and whether it is a right way of doing ???
>
> As I have told you a few times now, you *either* allocate the memory *or*
> ioremap it, NOT BOTH!!!
>
> If you SDRAM is you main memory, you need vmalloc and remap_vmalloc_range.
> If the SDRAM is not your main memory but some I/O attached buffer, you 
> need
> ioremap/of_iomap and remap_pfn_range.
>
> Arnd <><
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 22 Jul 2008 11:57:05 -0500
> From: Jon Loeliger <jdl@freescale.com>
> Subject: Re: Help: Kernel BUG with U-boot 1.1.4 and kernel 2.6.23
> scanning PCIe on a MPC8641D board
> To: joachim.bader@diehl-aerospace.de
> Cc: linuxppc-embedded@ozlabs.org
> Message-ID: <48861161.8050707@freescale.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> joachim.bader@diehl-aerospace.de wrote:
>>
>> Hello folks,
>>
>> we run a proprietary board with Freescale MPC8641D using U-boot 1.1.4
>> and Linux kernel 2.6.23
>>
>
>> I read in the logs some messages that 2.6.23 does contain some bugs
>> related to PCIe
>
> Correct.
>
>> and it would be a good choice to upgrade to 2.6.25. Is
>> this one of that cases?
>
> Almost certainly.  You should pick up top of tree if you can.
>
>> Currently we would like to prevent switching the kernel version.
>
> You could back-port the PCIe bug fixes and rewrite if you wanted.
> My guess is that a _trial_ run of the current top of tree,
> or at least 2.6.26 might Just Work and fix your issues.
>
> It would be less work to try it than do discover-n-back-port...
>
> jdl
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 22 Jul 2008 12:55:08 -0500
> From: Scott Wood <scottwood@freescale.com>
> Subject: Re: Failure of request_irq()  for MPC8313 using arch=powerpc
> To: Duy-Ky Nguyen <duykynguyen@hotmail.com>
> Cc: Liu Dave <DaveLiu@freescale.com>, linuxppc-embedded@ozlabs.org
> Message-ID: <20080722175508.GA13940@loki.buserror.net>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Jul 15, 2008 at 08:43:59PM -0700, Duy-Ky Nguyen wrote:
>> Hi Dave,
>>
>> I've just tried it and it failed.
>
> Could you elaborate on exactly what you tried?  Did you pass the GPIO 
> device
> tree node?
>
>> Before I had tried using the function
>> int virq = of_irq_to_resource(GPIO_IRQ, 0, NULL);
>> and it failed the same way
>
> The first argument of of_irq_to_resource is a device node pointer, not an
> IRQ number.  Surely the compiler warned you about this.
>
> -Scott
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 22 Jul 2008 13:05:06 -0500
> From: Scott Wood <scottwood@freescale.com>
> Subject: Re: Problem with cuImage Linux entry from old U-boot
> To: Stephen Horton <SHorton@kodiaknetworks.com>
> Cc: linuxppc-embedded@ozlabs.org
> Message-ID: <20080722180506.GB13940@loki.buserror.net>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Jul 21, 2008 at 03:39:55PM -0500, Stephen Horton wrote:
>> I have made great strides with help from this mailing list and its
>> archives. I now have a compiled cuImage ready to boot from my older
>> working u-boot 1.1.2. I now seem to be stuck at the kernel entry point.
>> I'm not sure if I'm trying to jump into the kernel at the wrong address,
>> or if I have a serial console issue that prevents me from seeing anymore
>> progress.
>
> Most likely the latter, or some other issue that prevents the kernel from
> booting to the point where the serial console functions.
>
>> Linux/PowerPC load: ip=bootp root=/dev/nfs rw nfsroot=/opt/gentoo
>> console=ttyMM0,9600n8
>> Finalizing device tree... flat tree at 0x7423a0
>>
>>
>>
>> ------
>>
>>
>>
>> If I run 'nm' on my elf image, I expect to find some entry point address
>> that corresponds to 0x7423a0, but this is not the case.
>
> Why would you expect that?  It's a dynamically allocated chunk of memory
> that holds the device tree that is passed to the kernel.  It's not an 
> entry
> point; the entry point to the kernel is zero.
>
> -Scott
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 22 Jul 2008 11:13:09 -0700
> From: "Mike Timmons" <mike_timmons@trimble.com>
> Subject: RE: Problem with cuImage Linux entry from old U-boot
> To: "Scott Wood" <scottwood@freescale.com>, "Stephen Horton"
> <SHorton@kodiaknetworks.com>
> Cc: linuxppc-embedded@ozlabs.org
> Message-ID:
> <161B3BAD77161449A144FF054231C3D60249D825@uss-am-xch-01.am.trimblecorp.net>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Related question: I'm using a newer U-boot and managing the load of the
> kernel and the device tree from separate partitions of my boot media.
>
> Having the two partitions and managing the kernel and the tree
> separately is a bit cumbersome, or maybe I'm just lazy. Regardless, can
> I just use that "static" file name option when I build the kernel, load
> the cuImage, and just invoke
>
> bootm <cuImageLoadAddress> ?
>
> Will it work to just leave off the - <device tree Ram address>
>
> I think I had it set-p right yesterday and I gave it a try, but no joy.
>
> Can it be this simple to statically link the device tree with the kernel
> build? For my application I don't see a benefit in keeping them separate
> (the kernel and the tree).
>
> Thanks,
> Mike
>
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+mike_timmons=trimble.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+mike_timmons=trimble.com@ozlabs.org]
> On Behalf Of Scott Wood
> Sent: Tuesday, July 22, 2008 1:05 PM
> To: Stephen Horton
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Problem with cuImage Linux entry from old U-boot
>
> On Mon, Jul 21, 2008 at 03:39:55PM -0500, Stephen Horton wrote:
>> I have made great strides with help from this mailing list and its
>> archives. I now have a compiled cuImage ready to boot from my older
>> working u-boot 1.1.2. I now seem to be stuck at the kernel entry
> point.
>> I'm not sure if I'm trying to jump into the kernel at the wrong
> address,
>> or if I have a serial console issue that prevents me from seeing
> anymore
>> progress.
>
> Most likely the latter, or some other issue that prevents the kernel
> from
> booting to the point where the serial console functions.
>
>> Linux/PowerPC load: ip=bootp root=/dev/nfs rw nfsroot=/opt/gentoo
>> console=ttyMM0,9600n8
>> Finalizing device tree... flat tree at 0x7423a0
>>
>>
>>
>> ------
>>
>>
>>
>> If I run 'nm' on my elf image, I expect to find some entry point
> address
>> that corresponds to 0x7423a0, but this is not the case.
>
> Why would you expect that?  It's a dynamically allocated chunk of memory
> that holds the device tree that is passed to the kernel.  It's not an
> entry
> point; the entry point to the kernel is zero.
>
> -Scott
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 22 Jul 2008 13:20:30 -0500
> From: Scott Wood <scottwood@freescale.com>
> Subject: Re: Problem with cuImage Linux entry from old U-boot
> To: Mike Timmons <mike_timmons@trimble.com>
> Cc: Stephen Horton <SHorton@kodiaknetworks.com>,
> linuxppc-embedded@ozlabs.org
> Message-ID: <488624EE.9040502@freescale.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Mike Timmons wrote:
>> Related question: I'm using a newer U-boot and managing the load of the
>> kernel and the device tree from separate partitions of my boot media.
>>
>> Having the two partitions and managing the kernel and the tree
>> separately is a bit cumbersome, or maybe I'm just lazy. Regardless, can
>> I just use that "static" file name option when I build the kernel, load
>> the cuImage, and just invoke
>>
>> bootm <cuImageLoadAddress> ?
>>
>> Will it work to just leave off the - <device tree Ram address>
>>
>> I think I had it set-p right yesterday and I gave it a try, but no joy.
>>
>> Can it be this simple to statically link the device tree with the kernel
>> build? For my application I don't see a benefit in keeping them separate
>> (the kernel and the tree).
>
> Yes, you can use cuImage to bundle the device tree with the kernel (note
> that the type of image you use *must* match the type of bootm command
> you use), though it's not recommended if you have a u-boot that can
> properly pass a device tree.  cuImage relies on the bd_t to get
> information from u-boot, and this is a very fragile structure, and
> contains less information than the device tree.
>
> -Scott
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 22 Jul 2008 20:56:43 +0200
> From: Albrecht Dre? <albrecht.dress@arcor.de>
> Subject: [OT] write flash on MPC5200 board via jtag
> To: LinuxPPC Embedded <linuxppc-embedded@ozlabs.org>
> Message-ID: <1216753011l.5683l.0l@antares>
> Content-Type: text/plain; charset="us-ascii"; Format="Flowed";
> DelSp="Yes"
>
> Hi,
>
> sorry for a somewhat off-topic question...
>
> I want to design a mpc5200b board which is roughly derived from
> Freescale's 5200B Lite demo.  Obviously, I have the problem to
> initially write u-boot into the boot nor flash.  I believe this would
> be possible using the jtag/bsm interface (is that true?).
>
> Can you recommend any good hardware and software solution for that, if
> possible running on linux (OSS?)?  I don't need a "real" debugger
> (maybe an interface to gdb), just something to write the flash, so
> u-boot comes up.
>
> Thanks for any help,
> Albrecht.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: not available
> URL: 
> <http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20080722/8a637400/attachment-0001.pgp>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 22 Jul 2008 14:23:39 -0500
> From: "Stephen Horton" <SHorton@kodiaknetworks.com>
> Subject: RE: Problem with cuImage Linux entry from old U-boot
> To: "Scott Wood" <scottwood@freescale.com>
> Cc: linuxppc-embedded@ozlabs.org
> Message-ID:
> <295C5089A56CE143B316E5F67CA99CB001D0637A@cowboy.inovate.inovate.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Thanks Scott for the tip. I'll redouble my efforts to compare the code
> in my older 1.1.2 U-boot source (that the board boots from) with my new
> .dts and cuboot source.
>
> -----Original Message-----
> From: Scott Wood [mailto:scottwood@freescale.com]
> Sent: Tuesday, July 22, 2008 1:05 PM
> To: Stephen Horton
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Problem with cuImage Linux entry from old U-boot
>
> On Mon, Jul 21, 2008 at 03:39:55PM -0500, Stephen Horton wrote:
>> I have made great strides with help from this mailing list and its
>> archives. I now have a compiled cuImage ready to boot from my older
>> working u-boot 1.1.2. I now seem to be stuck at the kernel entry
> point.
>> I'm not sure if I'm trying to jump into the kernel at the wrong
> address,
>> or if I have a serial console issue that prevents me from seeing
> anymore
>> progress.
>
> Most likely the latter, or some other issue that prevents the kernel
> from
> booting to the point where the serial console functions.
>
>> Linux/PowerPC load: ip=bootp root=/dev/nfs rw nfsroot=/opt/gentoo
>> console=ttyMM0,9600n8
>> Finalizing device tree... flat tree at 0x7423a0
>>
>>
>>
>> ------
>>
>>
>>
>> If I run 'nm' on my elf image, I expect to find some entry point
> address
>> that corresponds to 0x7423a0, but this is not the case.
>
> Why would you expect that?  It's a dynamically allocated chunk of memory
> that holds the device tree that is passed to the kernel.  It's not an
> entry
> point; the entry point to the kernel is zero.
>
> -Scott
>
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 22 Jul 2008 12:35:51 -0700 (PDT)
> From: Victor Gallardo <vgallardo@amcc.com>
> Subject: Re: [PATCH] Add AMCC Arches 460GT eval board support to
> platforms/44x
> To: linuxppc-embedded@ozlabs.org
> Message-ID: <18597016.post@talk.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
>
>>As you might have noticed, this has generated quite a bit of discussion
>>on whether this is the right approach or not.  If you can wait for a
>>week, we plan on talking it over at OLS.  Then I can give you a better
>>idea as to whether we're going to stick with this or use a different
>>approach.
>>
>>Overall your patches are fairly clean, so you've done a good job so
>>far.  Have a little patience with us as we figure out the right way to
>>go :).
>>
>>josh
>
> OK. I watch the mailing list for updates.
>
> Thanks,
>
> Victor Gallardo
> -- 
> View this message in context: 
> http://www.nabble.com/-PATCH--Add-AMCC-Arches-460GT-eval-board-support-to-platforms-44x-tp18480745p18597016.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 22 Jul 2008 15:49:47 -0400
> From: Ron Sass <rsass@uncc.edu>
> Subject: Re: How to create custom ramdisk
> To: Neeraj Garg <neerajg@cdac.in>
> Cc: linuxppc-embedded@ozlabs.org
> Message-ID: <200807221949.m6MJnll7016697@rsass-homer.uncc.edu>
>
>
> Under my home page, I have links to the courses I teach.
>
> http://rcs.uncc.edu/~rsass/
>
> Follow the links to "Fundamentals of Reconfigurable
> Computing"  specifically,
>
> http://rcs.uncc.edu/~rsass/courses/2008-Fall/6890/
>
> There are labs and tutorials there.  Under Labs, (Lab 3 in
> particular) we build Linux-based systems.  Lab 3 is has a tutorial
> based on Secret Lab's git repository and some in-house scripts.
> The students use RHEL5 machines but in our research lab we Fedora
> Core and CentOS4 machines.
>
> Also we have a wiki with other tutorials.  Sorry, it's not very
> organized (or up to date...)
>
> http://www.rcs.uncc.edu/wiki/index.php/Main_Page
>
> Ron
>
>
>>
>> Hi,
>>
>> I want to create a custom ramdisk (initrd which can be placed in
>> arch/ppc/boot/images). Can anybody guide me steps to built the same. My
>> host have RHEL-4.
>>
>> -- 
>>
>> -------------------------------------------------------------------
>> Neeraj Garg
>>
>>
>>
>> --------------080207080004080602090709
>> Content-Type: text/html; charset=ISO-8859-1
>> Content-Transfer-Encoding: 7bit
>>
>> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>> <html>
>> <head>
>>   <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
>>   <title></title>
>> </head>
>> <body bgcolor="#ffffff" text="#000000">
>> Hi,<br>
>> <br>
>> I want to create a custom ramdisk (initrd which can be placed in
>> arch/ppc/boot/images). Can anybody guide me steps to built
>> the same. My host have RHEL-4.<br>
>> <br>
>> <div class="moz-signature">-- <br>
>> <pre><!-- img src="file:///E:/htdg.jpg" border="0" 
>> alt="C-DAC"-->------------
>> -------------------------------------------------------
>> Neeraj Garg
>>
>> </pre>
>> </div>
>> </body>
>> </html>
>>
>> --------------080207080004080602090709--
>>
>>
>> --===============0773240910==
>> Content-Type: text/plain; charset="us-ascii"
>> MIME-Version: 1.0
>> Content-Transfer-Encoding: 7bit
>> Content-Disposition: inline
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> --===============0773240910==--
>>
>
>
> ------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> End of Linuxppc-embedded Digest, Vol 47, Issue 39
> *************************************************
> 

^ permalink raw reply

* [PATCH] powerpc: fallout from sysdev API changes
From: Stephen Rothwell @ 2008-07-23  0:44 UTC (permalink / raw)
  To: Paul Mackerras, Benjamin Herrenschmidt; +Cc: linuxppc-dev, Greg KH

A struct sysdev_attribute * parameter was added to the show routine by
commit 4a0b2b4dbe1335b8b9886ba3dc85a145d5d938ed "sysdev: Pass the
attribute to the low level sysdev show/store function".

This eliminates a warning:

arch/powerpc/kernel/sysfs.c:538: warning: initialization from incompatible pointer type

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/kernel/sysfs.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

Greg, probably easiest for this to go via the powerpc tree - an Ack would
be nice, though.

diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index aba0ba9..800e5e9 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -529,7 +529,8 @@ static void register_nodes(void)
 #endif
 
 /* Only valid if CPU is present. */
-static ssize_t show_physical_id(struct sys_device *dev, char *buf)
+static ssize_t show_physical_id(struct sys_device *dev,
+				struct sysdev_attribute *attr, char *buf)
 {
 	struct cpu *cpu = container_of(dev, struct cpu, sysdev);
 
-- 
1.5.6.3

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply related

* Re: [RFC] 4xx hardware watchpoint support
From: Luis Machado @ 2008-07-23  1:47 UTC (permalink / raw)
  To: Josh Boyer; +Cc: ppc-dev, Paul Mackerras
In-Reply-To: <20080721130551.23a06006@zod.rchland.ibm.com>

Hi,

> That, or adding a small function to move the bits to the appropriate
> registers (set_dbcr or set_dac_events).
> 
> > Do you think it's worth to support this facility on 405's processors? If
> > so, i'll gladly work on a solution to it.
> 
> I would think so.  There's really no difference from a userspace
> perspective, so gdb watchpoints could be valuable there too.  I'll
> leave it up to you though.

As the 440 support is ready and the 405 needs additional tweaking due to
the use of DBCR1 instead of DBCR0 and due to a different position scheme
of the DAC1R/DAC1W flags inside DBCR1, i'd say we should include this
code and handle the 405 case later. 

We might have to handle it anyway if we're going to pursue the hardware
breakpoint interface work in the future.

I've fixed some formatting problems. Tested on a 440 Taishan board and
on a PPC970. Both worked as they should. Ok?


Signed-off-by: Luis Machado <luisgpm@br.ibm.com>

Index: linux-2.6.26/arch/powerpc/kernel/process.c
===================================================================
--- linux-2.6.26.orig/arch/powerpc/kernel/process.c	2008-07-20 16:56:57.000000000 -0700
+++ linux-2.6.26/arch/powerpc/kernel/process.c	2008-07-22 16:46:36.000000000 -0700
@@ -47,6 +47,8 @@
 #ifdef CONFIG_PPC64
 #include <asm/firmware.h>
 #endif
+#include <linux/kprobes.h>
+#include <linux/kdebug.h>
 
 extern unsigned long _get_SP(void);
 
@@ -239,6 +241,36 @@
 }
 #endif /* CONFIG_SMP */
 
+void do_dabr(struct pt_regs *regs, unsigned long address,
+		    unsigned long error_code)
+{
+	siginfo_t info;
+
+#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
+	if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
+			11, SIGSEGV) == NOTIFY_STOP)
+		return;
+
+	if (debugger_dabr_match(regs))
+		return;
+
+	/* Clear the DAC and struct entries.  One shot trigger.  */
+#else /* (defined(CONFIG_4xx) || defined(CONFIG_BOOKE)) */
+	mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~(DBSR_DAC1R | DBSR_DAC1W
+							| DBCR0_IDM));
+#endif
+
+	/* Clear the DABR */
+	set_dabr(0);
+
+	/* Deliver the signal to userspace */
+	info.si_signo = SIGTRAP;
+	info.si_errno = 0;
+	info.si_code = TRAP_HWBKPT;
+	info.si_addr = (void __user *)address;
+	force_sig_info(SIGTRAP, &info, current);
+}
+
 static DEFINE_PER_CPU(unsigned long, current_dabr);
 
 int set_dabr(unsigned long dabr)
@@ -254,6 +286,11 @@
 #if defined(CONFIG_PPC64) || defined(CONFIG_6xx)
 	mtspr(SPRN_DABR, dabr);
 #endif
+
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+	mtspr(SPRN_DAC1, dabr);
+#endif
+
 	return 0;
 }
 
@@ -337,6 +374,12 @@
 	if (unlikely(__get_cpu_var(current_dabr) != new->thread.dabr))
 		set_dabr(new->thread.dabr);
 
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+	/* If new thread DAC (HW breakpoint) is the same then leave it.  */
+	if (new->thread.dabr)
+		set_dabr(new->thread.dabr);
+#endif
+
 	new_thread = &new->thread;
 	old_thread = &current->thread;
 
@@ -525,6 +568,10 @@
 	if (current->thread.dabr) {
 		current->thread.dabr = 0;
 		set_dabr(0);
+
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+		current->thread.dbcr0 &= ~(DBSR_DAC1R | DBSR_DAC1W);
+#endif
 	}
 }
 
Index: linux-2.6.26/arch/powerpc/kernel/ptrace.c
===================================================================
--- linux-2.6.26.orig/arch/powerpc/kernel/ptrace.c	2008-07-20 16:56:57.000000000 -0700
+++ linux-2.6.26/arch/powerpc/kernel/ptrace.c	2008-07-22 16:41:24.000000000 -0700
@@ -703,7 +703,7 @@
 
 	if (regs != NULL) {
 #if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
-		task->thread.dbcr0 = DBCR0_IDM | DBCR0_IC;
+		task->thread.dbcr0 |= DBCR0_IDM | DBCR0_IC;
 		regs->msr |= MSR_DE;
 #else
 		regs->msr |= MSR_SE;
@@ -716,9 +716,16 @@
 {
 	struct pt_regs *regs = task->thread.regs;
 
+
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+	/* If DAC then do not single step, skip.  */
+	if (task->thread.dabr)
+		return;
+#endif
+
 	if (regs != NULL) {
 #if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
-		task->thread.dbcr0 = 0;
+		task->thread.dbcr0 &= ~(DBCR0_IC | DBCR0_IDM);
 		regs->msr &= ~MSR_DE;
 #else
 		regs->msr &= ~MSR_SE;
@@ -727,22 +734,71 @@
 	clear_tsk_thread_flag(task, TIF_SINGLESTEP);
 }
 
-static int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
+int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
 			       unsigned long data)
 {
-	/* We only support one DABR and no IABRS at the moment */
+	/* For ppc64 we support one DABR and no IABR's at the moment (ppc64).
+	   For embedded processors we support one DAC and no IAC's
+	   at the moment.  */
 	if (addr > 0)
 		return -EINVAL;
 
-	/* The bottom 3 bits are flags */
 	if ((data & ~0x7UL) >= TASK_SIZE)
 		return -EIO;
 
-	/* Ensure translation is on */
+#ifdef CONFIG_PPC64
+
+	/* For processors using DABR (i.e. 970), the bottom 3 bits are flags.
+	   It was assumed, on previous implementations, that 3 bits were
+	   passed together with the data address, fitting the design of the
+	   DABR register, as follows:
+
+	   bit 0: Read flag
+	   bit 1: Write flag
+	   bit 2: Breakpoint translation
+
+	   Thus, we use them here as so.  */
+
+	/* Ensure breakpoint translation bit is set.  */
 	if (data && !(data & DABR_TRANSLATION))
 		return -EIO;
 
+	/* Move contents to the DABR register.  */
 	task->thread.dabr = data;
+
+#endif
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+
+	/* As described above, it was assumed 3 bits were passed with the data
+	   address, but we will assume only the mode bits will be passed
+	   as to not cause alignment restrictions for DAC-based processors.  */
+	/* DAC's hold the whole address without any mode flags.  */
+	task->thread.dabr = data & ~0x3UL;
+
+	if (task->thread.dabr == 0) {
+		task->thread.dbcr0 &= ~(DBSR_DAC1R | DBSR_DAC1W | DBCR0_IDM);
+		task->thread.regs->msr &= ~MSR_DE;
+		return 0;
+	}
+
+	/* Read or Write bits must be set.  */
+
+	if (!(data & 0x3UL))
+		return -EINVAL;
+
+	/* Set the Internal Debugging flag (IDM bit 1) for the DBCR0
+	   register.  */
+	task->thread.dbcr0 = DBCR0_IDM;
+
+	/* Check for write and read flags and set DBCR0
+	   accordingly.  */
+	if (data & 0x1UL)
+		task->thread.dbcr0 |= DBSR_DAC1R;
+	if (data & 0x2UL)
+		task->thread.dbcr0 |= DBSR_DAC1W;
+
+	task->thread.regs->msr |= MSR_DE;
+#endif
 	return 0;
 }
 
Index: linux-2.6.26/arch/powerpc/kernel/signal.c
===================================================================
--- linux-2.6.26.orig/arch/powerpc/kernel/signal.c	2008-07-20 16:56:57.000000000 -0700
+++ linux-2.6.26/arch/powerpc/kernel/signal.c	2008-07-22 16:47:22.000000000 -0700
@@ -145,8 +145,12 @@
 	 * user space. The DABR will have been cleared if it
 	 * triggered inside the kernel.
 	 */
-	if (current->thread.dabr)
+	if (current->thread.dabr) {
 		set_dabr(current->thread.dabr);
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+		mtspr(SPRN_DBCR0, current->thread.dbcr0);
+#endif
+	}
 
 	if (is32) {
         	if (ka.sa.sa_flags & SA_SIGINFO)
Index: linux-2.6.26/arch/powerpc/kernel/traps.c
===================================================================
--- linux-2.6.26.orig/arch/powerpc/kernel/traps.c	2008-07-20 16:56:57.000000000 -0700
+++ linux-2.6.26/arch/powerpc/kernel/traps.c	2008-07-22 16:49:28.000000000 -0700
@@ -1067,6 +1067,22 @@
 		}
 
 		_exception(SIGTRAP, regs, TRAP_TRACE, regs->nip);
+	} else if (debug_status & (DBSR_DAC1R | DBSR_DAC1W)) {
+		regs->msr &= ~MSR_DE;
+
+		if (user_mode(regs)) {
+			current->thread.dbcr0 &= ~(DBSR_DAC1R | DBSR_DAC1W |
+								DBCR0_IDM);
+		} else {
+			/* Disable DAC interupts.  */
+			mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~(DBSR_DAC1R |
+						DBSR_DAC1W | DBCR0_IDM));
+
+			/* Clear the DAC event.  */
+			mtspr(SPRN_DBSR, (DBSR_DAC1R | DBSR_DAC1W));
+		}
+		/* Setup and send the trap to the handler.  */
+		do_dabr(regs, mfspr(SPRN_DAC1), debug_status);
 	}
 }
 #endif /* CONFIG_4xx || CONFIG_BOOKE */
Index: linux-2.6.26/arch/powerpc/kernel/entry_32.S
===================================================================
--- linux-2.6.26.orig/arch/powerpc/kernel/entry_32.S	2008-07-20 16:56:57.000000000 -0700
+++ linux-2.6.26/arch/powerpc/kernel/entry_32.S	2008-07-20 16:58:54.000000000 -0700
@@ -148,7 +148,7 @@
 	/* Check to see if the dbcr0 register is set up to debug.  Use the
 	   internal debug mode bit to do this. */
 	lwz	r12,THREAD_DBCR0(r12)
-	andis.	r12,r12,DBCR0_IDM@h
+	andis.	r12,r12,(DBCR0_IDM  | DBSR_DAC1R | DBSR_DAC1W)@h
 	beq+	3f
 	/* From user and task is ptraced - load up global dbcr0 */
 	li	r12,-1			/* clear all pending debug events */
@@ -292,7 +292,7 @@
 	/* If the process has its own DBCR0 value, load it up.  The internal
 	   debug mode bit tells us that dbcr0 should be loaded. */
 	lwz	r0,THREAD+THREAD_DBCR0(r2)
-	andis.	r10,r0,DBCR0_IDM@h
+	andis.	r10,r0,(DBCR0_IDM  | DBSR_DAC1R | DBSR_DAC1W)@h
 	bnel-	load_dbcr0
 #endif
 #ifdef CONFIG_44x
@@ -720,7 +720,7 @@
 	/* Check whether this process has its own DBCR0 value.  The internal
 	   debug mode bit tells us that dbcr0 should be loaded. */
 	lwz	r0,THREAD+THREAD_DBCR0(r2)
-	andis.	r10,r0,DBCR0_IDM@h
+	andis.	r10,r0,(DBCR0_IDM  | DBSR_DAC1R | DBSR_DAC1W)@h
 	bnel-	load_dbcr0
 #endif
 
Index: linux-2.6.26/arch/powerpc/mm/fault.c
===================================================================
--- linux-2.6.26.orig/arch/powerpc/mm/fault.c	2008-07-20 16:56:57.000000000 -0700
+++ linux-2.6.26/arch/powerpc/mm/fault.c	2008-07-20 16:58:54.000000000 -0700
@@ -100,31 +100,6 @@
 	return 0;
 }
 
-#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
-static void do_dabr(struct pt_regs *regs, unsigned long address,
-		    unsigned long error_code)
-{
-	siginfo_t info;
-
-	if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
-			11, SIGSEGV) == NOTIFY_STOP)
-		return;
-
-	if (debugger_dabr_match(regs))
-		return;
-
-	/* Clear the DABR */
-	set_dabr(0);
-
-	/* Deliver the signal to userspace */
-	info.si_signo = SIGTRAP;
-	info.si_errno = 0;
-	info.si_code = TRAP_HWBKPT;
-	info.si_addr = (void __user *)address;
-	force_sig_info(SIGTRAP, &info, current);
-}
-#endif /* !(CONFIG_4xx || CONFIG_BOOKE)*/
-
 /*
  * For 600- and 800-family processors, the error_code parameter is DSISR
  * for a data fault, SRR1 for an instruction fault. For 400-family processors
Index: linux-2.6.26/include/asm-powerpc/system.h
===================================================================
--- linux-2.6.26.orig/include/asm-powerpc/system.h	2008-07-20 16:57:09.000000000 -0700
+++ linux-2.6.26/include/asm-powerpc/system.h	2008-07-20 23:00:36.000000000 -0700
@@ -110,6 +110,8 @@
 #endif
 
 extern int set_dabr(unsigned long dabr);
+extern void do_dabr(struct pt_regs *regs, unsigned long address,
+		    unsigned long error_code);
 extern void print_backtrace(unsigned long *);
 extern void show_regs(struct pt_regs * regs);
 extern void flush_instruction_cache(void);

^ permalink raw reply

* Re: Failure of request_irq()  for MPC8313 using arch=powerpc
From: Duy-Ky Nguyen @ 2008-07-23  1:54 UTC (permalink / raw)
  To: Scott Wood; +Cc: Liu Dave, linuxppc-embedded
In-Reply-To: <20080722175508.GA13940@loki.buserror.net>

Hello Scott,

I forgot to mention that I have less error if I use the existing device node 
"spi" in the DTS file

# Start of error capture

Got device node from device tree
Got Virtual IRQ
PPC : interrupt hook failed (-22)

# End of capture

So it's able to access the device node and to map "virq" while I had total 
failure in using "gpio" I put into DTS

I must make mistake in creating the node "gpio" in the DTS file

I'm using FreeScale Eva board MPC8313ERDB

Thanks,

Duy-Ky

----- Original Message ----- 
From: "Scott Wood" <scottwood@freescale.com>
To: "Duy-Ky Nguyen" <duykynguyen@hotmail.com>
Cc: "Liu Dave" <DaveLiu@freescale.com>; <linuxppc-embedded@ozlabs.org>
Sent: Tuesday, July 22, 2008 10:55 AM
Subject: Re: Failure of request_irq() for MPC8313 using arch=powerpc


> On Tue, Jul 15, 2008 at 08:43:59PM -0700, Duy-Ky Nguyen wrote:
>> Hi Dave,
>>
>> I've just tried it and it failed.
>
> Could you elaborate on exactly what you tried?  Did you pass the GPIO 
> device
> tree node?
>
>> Before I had tried using the function
>> int virq = of_irq_to_resource(GPIO_IRQ, 0, NULL);
>> and it failed the same way
>
> The first argument of of_irq_to_resource is a device node pointer, not an
> IRQ number.  Surely the compiler warned you about this.
>
> -Scott
> 

^ permalink raw reply

* Re: netif_schedule and mpc5200_fec
From: Grant Likely @ 2008-07-23  4:57 UTC (permalink / raw)
  To: David Miller; +Cc: davem, Linuxppc-dev, netdev
In-Reply-To: <20080722.163626.109432106.davem@davemloft.net>

On Tue, Jul 22, 2008 at 7:36 PM, David Miller <davem@davemloft.net> wrote:
> From: "Jon Smirl" <jonsmirl@gmail.com>
>> You're right. That patch fixes it. Another thing I brought down made
>> my image file not get generated and I was using an old image.
>
> Thanks for confirming this Jon.

Thanks for fixing it!

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: [PATCH 2/2] Allow a custom ASOC machine driver with soc-of-simple
From: Stephen Rothwell @ 2008-07-23  5:30 UTC (permalink / raw)
  To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20080722235351.11648.56387.stgit@terra>

[-- Attachment #1: Type: text/plain, Size: 328 bytes --]

Hi John,

On Tue, 22 Jul 2008 19:53:51 -0400 Jon Smirl <jonsmirl@gmail.com> wrote:
>
> +static struct snd_soc_ops *machine_ops = NULL;
> +static char *machine_name = NULL;

You don't need these initialisations.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Kernel is Hanging for page size 16KB.
From: Naresh Bhat @ 2008-07-23  6:42 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

Hi Guys,

I have a board MIPS Malta and Linux 2.6.10 is running on that. By default
4KB page size will be allocated in the kernel (I mean to say I saw it when I
do the "make menuconfig".

Problem is:

When I changed the page size to 16KB it will hang after mounting the file
system. I am using the NFS for booting the board.


Can anybody help me on this issue...
-- 

Naresh Bhat

[-- Attachment #2: Type: text/html, Size: 470 bytes --]

^ permalink raw reply

* Re: Kernel is Hanging for page size 16KB.
From: Marco Stornelli @ 2008-07-23  6:58 UTC (permalink / raw)
  To: Naresh Bhat; +Cc: linuxppc-embedded
In-Reply-To: <cf9b3c760807222342h47ff8d0atd74fd5a583a62d9c@mail.gmail.com>

Naresh Bhat ha scritto:
> Hi Guys,
> 
> I have a board MIPS Malta and Linux 2.6.10 is running on that. By default
> 4KB page size will be allocated in the kernel (I mean to say I saw it when I
> do the "make menuconfig".
> 
> Problem is:
> 
> When I changed the page size to 16KB it will hang after mounting the file
> system. I am using the NFS for booting the board.
> 
> 
> Can anybody help me on this issue...
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

This is not a MIPS a mailing list.

-- 
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it

marco.stornelli@coritel.it
+39 06 72582838

^ permalink raw reply

* Re: Kernel is Hanging for page size 16KB.
From: Naresh Bhat @ 2008-07-23  7:03 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <cf9b3c760807222342h47ff8d0atd74fd5a583a62d9c@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

ooops sorry,  Please Ignore....by mistake I put the question here...

On Wed, Jul 23, 2008 at 12:12 PM, Naresh Bhat <nareshgbhat@gmail.com> wrote:

> Hi Guys,
>
> I have a board MIPS Malta and Linux 2.6.10 is running on that. By default
> 4KB page size will be allocated in the kernel (I mean to say I saw it when I
> do the "make menuconfig".
>
> Problem is:
>
> When I changed the page size to 16KB it will hang after mounting the file
> system. I am using the NFS for booting the board.
>
>
> Can anybody help me on this issue...
> --
>
> Naresh Bhat
>
>


-- 

Naresh Bhat
9845365362(M)

[-- Attachment #2: Type: text/html, Size: 942 bytes --]

^ permalink raw reply

* kernel panic while using alloc_bootmem()
From: Misbah khan @ 2008-07-23  7:22 UTC (permalink / raw)
  To: linuxppc-embedded


Hi all ,

I am getting kernel panic while allocating memory at boottime in my driver
which is linked to the kernel following is the code snapshort from driver
init module .

 buf_area = alloc_bootmem_low(0x900000);
 if(buf_area == NULL)
 {
      printk(" ################## Memory allocation failed \n");
       return -1;

  }

following is the error message :-

###################### bootmem driver init call start #################
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1]
Modules linked in:
CPU: 0
PC is at _find_first_zero_bit_le+0xc/0x2c
LR is at __alloc_bootmem_core+0x138/0x334
pc : [<c0152b58>]    lr : [<c00132d0>]    Not tainted
sp : c043df38  ip : 00000000  fp : c043df74
r10: 00000000  r9 : 00000900  r8 : 00900000
r7 : 00000001  r6 : 00000020  r5 : c02fa9e0  r4 : 000fffff
r3 : 00007700  r2 : 00000000  r1 : 00007700  r0 : 00000000
Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  Segment kernel
Control: C5387F
Table: 80004000  DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc043c250)
Stack: (0xc043df38 to 0xc043e000)
df20:                                                       c018195c
ffffffe0
df40: 00007700 00000000 c043df84 c02fa9e0 00900000 00000000 00000020
00000000
df60: 00000000 00000000 c043df9c c043df78 c0013538 c00131a4 ffffffff
c043df94
df80: c001e504 c001dfd8 c043c000 00000001 c043dfac c043dfa0 c001ae98
c0013500
dfa0: c043dff4 c043dfb0 c00200c8 c001ae80 00000000 00000000 c002002c
c0041eb8
dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
dfe0: 00000000 00000000 00000000 c043dff8 c0041eb8 c0020038 c021c9dc
c021cb50
Backtrace:
[<c0013198>] (__alloc_bootmem_core+0x0/0x334) from [<c0013538>]
(__alloc_bootmem_low+0x44/0x94)
[<c00134f4>] (__alloc_bootmem_low+0x0/0x94) from [<c001ae98>]
(FlukeDriverInit+0x24/0x7c)
 r7 = 00000001  r6 = C043C000  r5 = C001DFD8  r4 = C001E504
[<c001ae74>] (FlukeDriverInit+0x0/0x7c) from [<c00200c8>] (init+0x9c/0x27c)
[<c002002c>] (init+0x0/0x27c) from [<c0041eb8>] (do_exit+0x0/0x93c)
 r7 = 00000000  r6 = 00000000  r5 = 00000000  r4 = 00000000
Code: e49df008 e3310000 0a000006 e3a02000 (e7d031a2)
 <0>Kernel panic - not syncing: Attempted to kill init!

---Misbah <><

-- 
View this message in context: http://www.nabble.com/kernel-panic-while-using-alloc_bootmem%28%29-tp18605311p18605311.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* Re: how to allocate 9MB of memory in kernel ?
From: Misbah khan @ 2008-07-23  7:30 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <200807221712.52030.arnd@arndb.de>



If you SDRAM is you main memory, you need vmalloc and remap_vmalloc_range.
If the SDRAM is not your main memory but some I/O attached buffer, you need
ioremap/of_iomap and remap_pfn_range.

My SDRAM is the main memory of which 9MB i have to allocate in the driver. 

If i allocate 9BM using vmalloc and remap to user space how should it
address to the 9MB 
SDRAM contigues address which i need to map for user access ? 


Arnd Bergmann wrote:
> 
> On Tuesday 22 July 2008, Misbah khan wrote:
>> First of all let me thank you for your valuable suggessions ...
>> 
>> 1. I wanted to allocate 9MB in kernel and wanted that memory to be mapped
>> to
>> the physically continews SDRAM memory. but till now i could not found a
>> way
>> to do so ???
>> 
>> 2. So i thought to use ioremap to map SDRAM and make it accessible to
>> user
>> using mmap technique but there is only one doubt and that is will it be
>> secure and stable and whether it is a right way of doing ???
> 
> As I have told you a few times now, you *either* allocate the memory *or*
> ioremap it, NOT BOTH!!!
> 
> If you SDRAM is you main memory, you need vmalloc and remap_vmalloc_range.
> If the SDRAM is not your main memory but some I/O attached buffer, you
> need
> ioremap/of_iomap and remap_pfn_range.
> 
> 	Arnd <><
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/how-to-allocate-9MB-of-memory-in-kernel---tp18503022p18605418.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* [PATCH 1/6] kvmppc: read device tree hypervisor node infrastructure
From: ehrhardt @ 2008-07-23  8:36 UTC (permalink / raw)
  To: kvm-ppc, embedded-hypervisor, linuxppc-dev; +Cc: hollisb
In-Reply-To: <1216802207-32675-1-git-send-email-ehrhardt@linux.vnet.ibm.com>

From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

This patch adds the guest portion of the device tree based host->guest
communication. Using the device tree infrastructure this patch implements
kvm_para_available and kvm_arch_para_features (in this patch just the
infrastructure, no specific feature registered).

Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
---

[diffstat]
 arch/powerpc/kernel/Makefile       |    2 ++
 arch/powerpc/kernel/kvm.c          |   30 ++++++++++++++++++++++++++++++
 arch/powerpc/kernel/setup_32.c     |    3 +++
 arch/powerpc/platforms/44x/Kconfig |    7 +++++++
 include/asm-powerpc/kvm_para.h     |   37 ++++++++++++++++++++++++++++++++++---
 5 files changed, 76 insertions(+), 3 deletions(-)

[diff]

diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -80,6 +80,8 @@
 
 obj-$(CONFIG_8XX_MINIMAL_FPEMU) += softemu8xx.o
 
+obj-$(CONFIG_KVM_GUEST)		+= kvm.o
+
 ifneq ($(CONFIG_PPC_INDIRECT_IO),y)
 obj-y				+= iomap.o
 endif
diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/kernel/kvm.c
@@ -0,0 +1,30 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ * Copyright IBM Corp. 2008
+ *
+ * Authors:
+ * 	Hollis Blanchard <hollisb@us.ibm.com>
+ * 	Christian Ehrhardt <ehrhardt@de.ibm.com>
+ */
+
+#include <linux/percpu.h>
+#include <linux/mm.h>
+#include <linux/kvm_para.h>
+
+void __init kvm_guest_init(void)
+{
+	if (!kvm_para_available())
+		return;
+}
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -17,6 +17,7 @@
 #include <linux/cpu.h>
 #include <linux/console.h>
 #include <linux/lmb.h>
+#include <linux/kvm_para.h>
 
 #include <asm/io.h>
 #include <asm/prom.h>
@@ -319,5 +320,7 @@
 		ppc_md.setup_arch();
 	if ( ppc_md.progress ) ppc_md.progress("arch: exit", 0x3eab);
 
+	kvm_guest_init();
+
 	paging_init();
 }
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -152,3 +152,10 @@
 # 44x errata/workaround config symbols, selected by the CPU models above
 config IBM440EP_ERR42
 	bool
+
+config KVM_GUEST
+	bool "KVM Guest support"
+	depends on EXPERIMENTAL
+	help
+	This option enables various optimizations for running under the KVM
+	hypervisor.
diff --git a/include/asm-powerpc/kvm_para.h b/include/asm-powerpc/kvm_para.h
--- a/include/asm-powerpc/kvm_para.h
+++ b/include/asm-powerpc/kvm_para.h
@@ -14,7 +14,9 @@
  *
  * Copyright IBM Corp. 2008
  *
- * Authors: Hollis Blanchard <hollisb@us.ibm.com>
+ * Authors:
+ * 	Hollis Blanchard <hollisb@us.ibm.com>
+ * 	Christian Ehrhardt <ehrhardt@de.ibm.com>
  */
 
 #ifndef __POWERPC_KVM_PARA_H__
@@ -22,15 +24,44 @@
 
 #ifdef __KERNEL__
 
+#include <linux/of.h>
+
+static struct kvmppc_para_features {
+	char *dtcell;
+	int feature;
+} para_features[] = {
+};
+
 static inline int kvm_para_available(void)
 {
-	return 0;
+	struct device_node *dn;
+
+	dn = of_find_node_by_path("/hypervisor");
+
+	return !!dn;
 }
 
 static inline unsigned int kvm_arch_para_features(void)
 {
-	return 0;
+	struct device_node *dn;
+	const int *dtval;
+	unsigned int features = 0;
+	int i;
+
+	dn = of_find_node_by_path("/hypervisor");
+	if (!dn)
+		return 0;
+
+	for (i = 0; i < ARRAY_SIZE(para_features)-1; i++) {
+		dtval = of_get_property(dn, para_features[i].dtcell, NULL);
+		if (dtval && *dtval == 1)
+			features |= (1 << para_features[i].feature);
+	}
+
+	return features;
 }
+
+void kvm_guest_init(void);
 
 #endif /* __KERNEL__ */
 

^ permalink raw reply

* [PATCH 5/6] kvmppc: magic page paravirtualization - guest part
From: ehrhardt @ 2008-07-23  8:36 UTC (permalink / raw)
  To: kvm-ppc, embedded-hypervisor, linuxppc-dev; +Cc: hollisb
In-Reply-To: <1216802207-32675-1-git-send-email-ehrhardt@linux.vnet.ibm.com>

From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

This patch adds the guest handling for the magic page mechanism. A Hypervisor
can modify the device tree passed to the guest. Using that already existing
interface a guest can simply detect available hypervisor features and agree
on the supported ones using hypercalls.
In this example it is checked for the feature switch "feature,pv-magicpage"
in the hypervisor node and additional data which represents the size the
hypervisor requests in "data,pv-magicpage-size".
When the guest read that data and wants to support it the memory is allocated
and passed to the hypervisor using the KVM_HCALL_RESERVE_MAGICPAGE hypercall.

Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
---

[diffstat]
 arch/powerpc/kernel/kvm.c      |   48 +++++++++++++++++++++++++++++++++++++++++
 include/asm-powerpc/kvm_para.h |   27 ++++++++++++++++++++++-
 2 files changed, 74 insertions(+), 1 deletion(-)

[diff]
diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
--- a/arch/powerpc/kernel/kvm.c
+++ b/arch/powerpc/kernel/kvm.c
@@ -22,9 +22,57 @@
 #include <linux/percpu.h>
 #include <linux/mm.h>
 #include <linux/kvm_para.h>
+#include <linux/bootmem.h>
+
+/*
+ * this is guest memory granted to the hypervisor;
+ * the hypervisor can place data in this area and rewrite
+ * privileged instructions to read from this area without
+ * trapping.
+ * Only the Hypervisor needs to be aware of the structure layout
+ * which makes the guest more felxible - the guest only guarantees
+ * the size which is requested by the hypervisor and read from a
+ * device tree entry.
+ */
+void *kvm_magicpage;
+
+static void __init kvmppc_register_magic_page(void)
+{
+	unsigned long paddr;
+	int size;
+	long err;
+
+	size = kvmppc_pv_read_data(KVM_PVDATA_MAGICPAGE_SIZE);
+	if (size < 0) {
+		printk(KERN_ERR"%s: couldn't read size for kvmppc style "
+			"paravirtualization support (got %d)\n",
+			__func__, size);
+		return;
+	}
+
+	/* FIXME Guest SMP needs that percpu
+	 * On SMP we might also need a free implementation */
+	kvm_magicpage = alloc_bootmem(size);
+	if (!kvm_magicpage) {
+		printk(KERN_ERR"%s - failed to allocate %d bytes\n",
+			 __func__, size);
+		return;
+	}
+
+	paddr = (unsigned long)__pa(kvm_magicpage);
+	err = kvm_hypercall1(KVM_HCALL_RESERVE_MAGICPAGE, paddr);
+	if (err)
+		printk(KERN_ERR"%s: couldn't register magic page\n", __func__);
+	else
+		printk(KERN_NOTICE"%s: registered %d bytes for "
+			"virtualization support\n", __func__, size);
+}
 
 void __init kvm_guest_init(void)
 {
 	if (!kvm_para_available())
 		return;
+
+	if (kvm_para_has_feature(KVM_FEATURE_PPCPV_MAGICPAGE))
+		kvmppc_register_magic_page();
 }
diff --git a/include/asm-powerpc/kvm_para.h b/include/asm-powerpc/kvm_para.h
--- a/include/asm-powerpc/kvm_para.h
+++ b/include/asm-powerpc/kvm_para.h
@@ -28,10 +28,18 @@
 
 #define KVM_HYPERCALL_BIN 0x03ffffff
 
+#define KVM_HCALL_RESERVE_MAGICPAGE	0
+
+#define KVM_PVDATA_MAGICPAGE_SIZE	"data,pv-magicpage-size"
+
+/* List of PV features supported, returned as a bitfield */
+#define KVM_FEATURE_PPCPV_MAGICPAGE	0
+
 static struct kvmppc_para_features {
 	char *dtcell;
 	int feature;
 } para_features[] = {
+	{ "feature,pv-magicpage", KVM_FEATURE_PPCPV_MAGICPAGE }
 };
 
 static inline int kvm_para_available(void)
@@ -54,13 +62,30 @@
 	if (!dn)
 		return 0;
 
-	for (i = 0; i < ARRAY_SIZE(para_features)-1; i++) {
+	for (i = 0; i < ARRAY_SIZE(para_features); i++) {
 		dtval = of_get_property(dn, para_features[i].dtcell, NULL);
 		if (dtval && *dtval == 1)
 			features |= (1 << para_features[i].feature);
 	}
 
 	return features;
+}
+
+/* reads the specified data field out of the hypervisor node */
+static inline int kvmppc_pv_read_data(char *dtcell)
+{
+	struct device_node *dn;
+	const int *dtval;
+
+	dn = of_find_node_by_path("/hypervisor");
+	if (!dn)
+		return -EINVAL;
+
+	dtval = of_get_property(dn, dtcell, NULL);
+	if (dtval)
+		return *dtval;
+	else
+		return -EINVAL;
 }
 
 void kvm_guest_init(void);

^ permalink raw reply

* [PATCH 3/6] kvmppc: add hypercall infrastructure - guest part
From: ehrhardt @ 2008-07-23  8:36 UTC (permalink / raw)
  To: kvm-ppc, embedded-hypervisor, linuxppc-dev; +Cc: hollisb
In-Reply-To: <1216802207-32675-1-git-send-email-ehrhardt@linux.vnet.ibm.com>

From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

This adds the guest portion of the hypercall infrastructure, basically an
illegal instruction with a defined layout.
See http://kvm.qumranet.com/kvmwiki/PowerPC_Hypercall_ABI for more detail
on the hypercall ABI for powerpc.

Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
---

[diffstat]
 kvm_para.h |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

[diff]
diff --git a/include/asm-powerpc/kvm_para.h b/include/asm-powerpc/kvm_para.h
--- a/include/asm-powerpc/kvm_para.h
+++ b/include/asm-powerpc/kvm_para.h
@@ -25,6 +25,8 @@
 #ifdef __KERNEL__
 
 #include <linux/of.h>
+
+#define KVM_HYPERCALL_BIN 0x03ffffff
 
 static struct kvmppc_para_features {
 	char *dtcell;
@@ -63,6 +65,20 @@
 
 void kvm_guest_init(void);
 
+static inline long kvm_hypercall1(unsigned int nr, unsigned long p1)
+{
+	register unsigned long hcall asm ("r0") = nr;
+	register unsigned long arg1 asm ("r3") = p1;
+	register long ret asm ("r11");
+
+	asm volatile(".long %1"
+			: "=r"(ret)
+			: "i"(KVM_HYPERCALL_BIN), "r"(hcall), "r"(arg1)
+			: "r4", "r5", "r6", "r7", "r8",
+			  "r9", "r10", "r12", "cc");
+	return ret;
+}
+
 #endif /* __KERNEL__ */
 
 #endif /* __POWERPC_KVM_PARA_H__ */

^ permalink raw reply

* [PATCH 6/6] kvmppc: kvm-userspace: device tree modification for magicpage
From: ehrhardt @ 2008-07-23  8:36 UTC (permalink / raw)
  To: kvm-ppc, embedded-hypervisor, linuxppc-dev; +Cc: hollisb
In-Reply-To: <1216802207-32675-1-git-send-email-ehrhardt@linux.vnet.ibm.com>

From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

This patch to kvm-userspace connects the other host & guest patches in this
series. On guest initialization it checks the hosts capabilities for the
magicpage mechanism. If available the device tree passed to the guest gets the
"hypervisor" node added and in that node the feature flag and the requested
magic page size (read from the host kernel via an ioctl) is stored.

Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
---

[diffstat]
 libkvm/libkvm-powerpc.c |    6 ++++++
 libkvm/libkvm.h         |    6 ++++++
 qemu/hw/device_tree.c   |   10 ++++++++++
 qemu/hw/device_tree.h   |    1 +
 qemu/hw/ppc440_bamboo.c |   15 +++++++++++++++
 qemu/qemu-kvm-powerpc.c |    5 +++++
 qemu/qemu-kvm.h         |    1 +
 7 files changed, 44 insertions(+)

[diff]
diff --git a/libkvm/libkvm-powerpc.c b/libkvm/libkvm-powerpc.c
--- a/libkvm/libkvm-powerpc.c
+++ b/libkvm/libkvm-powerpc.c
@@ -19,6 +19,7 @@
 
 #include "libkvm.h"
 #include "kvm-powerpc.h"
+#include <sys/ioctl.h>
 #include <errno.h>
 #include <stdio.h>
 #include <inttypes.h>
@@ -105,6 +106,11 @@
 	return 0;
 }
 
+int kvm_get_magicpage_size(kvm_context_t kvm)
+{
+	return ioctl(kvm->fd, KVM_GET_PPCPV_MAGICPAGE_SIZE, 0);
+}
+
 int kvm_arch_run(struct kvm_run *run, kvm_context_t kvm, int vcpu)
 {
 	int ret = 0;
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -639,6 +639,12 @@
 
 #endif
 
+#ifdef KVM_CAP_PPCPV_MAGICPAGE
+
+int kvm_get_magicpage_size(kvm_context_t kvm);
+
+#endif
+
 int kvm_translate(kvm_context_t kvm, int vcpu, struct kvm_translation *tr);
 
 #endif
diff --git a/qemu/hw/device_tree.c b/qemu/hw/device_tree.c
--- a/qemu/hw/device_tree.c
+++ b/qemu/hw/device_tree.c
@@ -190,4 +190,14 @@
 		exit(1);
 	}
 }
+
+void dt_add_subnode(void *fdt, const char *name, char *node_path)
+{
+	int offset;
+	offset = get_offset_of_node(fdt, node_path);
+	if (fdt_add_subnode(fdt, offset, name) < 0) {
+		printf("Unable to create device tree node '%s'\n", name);
+		exit(1);
+	}
+}
 #endif
diff --git a/qemu/hw/device_tree.h b/qemu/hw/device_tree.h
--- a/qemu/hw/device_tree.h
+++ b/qemu/hw/device_tree.h
@@ -23,4 +23,5 @@
 		uint32_t *val_array, int size);
 void dt_string(void *fdt, char *node_path, char *property,
 		char *string);
+void dt_add_subnode(void *fdt, const char *name, char *node_path);
 #endif
diff --git a/qemu/hw/ppc440_bamboo.c b/qemu/hw/ppc440_bamboo.c
--- a/qemu/hw/ppc440_bamboo.c
+++ b/qemu/hw/ppc440_bamboo.c
@@ -51,6 +51,7 @@
 	uint32_t cpu_freq;
 	uint32_t timebase_freq;
 	uint32_t mem_reg_property[]={0, 0, ram_size};
+	int pv_magicpage_size;
 
 	printf("%s: START\n", __func__);
 
@@ -167,6 +168,20 @@
 	dt_cell(fdt, "/chosen", "linux,initrd-end",
 				(initrd_base + initrd_size));
 	dt_string(fdt, "/chosen", "bootargs", (char *)kernel_cmdline);
+
+	if (kvm_enabled()
+	    && kvm_qemu_check_extension(KVM_CAP_PPCPV_MAGICPAGE)) {
+		pv_magicpage_size = kvmppc_pv_get_magicpage_size();
+		if (pv_magicpage_size < 0) {
+			fprintf(stderr, "%s: error reading magic page size\n",
+				 __func__);
+			exit(1);
+		}
+		dt_add_subnode(fdt, "hypervisor", "/");
+		dt_cell(fdt, "/hypervisor", "feature,pv-magicpage", 1);
+		dt_cell(fdt, "/hypervisor", "data,pv-magicpage-size",
+			pv_magicpage_size);
+	}
 #endif
 
 	if (kvm_enabled()) {
diff --git a/qemu/qemu-kvm-powerpc.c b/qemu/qemu-kvm-powerpc.c
--- a/qemu/qemu-kvm-powerpc.c
+++ b/qemu/qemu-kvm-powerpc.c
@@ -214,6 +214,11 @@
     return 0; /* XXX ignore failed DCR ops */
 }
 
+int kvmppc_pv_get_magicpage_size(void)
+{
+	return kvm_get_magicpage_size(kvm_context);
+}
+
 int mmukvm_get_physical_address(CPUState *env, mmu_ctx_t *ctx,
                                 target_ulong eaddr, int rw, int access_type)
 {
diff --git a/qemu/qemu-kvm.h b/qemu/qemu-kvm.h
--- a/qemu/qemu-kvm.h
+++ b/qemu/qemu-kvm.h
@@ -86,6 +86,7 @@
 #ifdef TARGET_PPC
 int handle_powerpc_dcr_read(int vcpu, uint32_t dcrn, uint32_t *data);
 int handle_powerpc_dcr_write(int vcpu,uint32_t dcrn, uint32_t data);
+int kvmppc_pv_get_magicpage_size();
 #endif
 
 #if !defined(SYS_signalfd)

^ permalink raw reply

* [PATCH 0/6][RFC] kvmppc: paravirtualization interface
From: ehrhardt @ 2008-07-23  8:36 UTC (permalink / raw)
  To: kvm-ppc, embedded-hypervisor, linuxppc-dev; +Cc: hollisb

From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

This patch series implements a paravirtualization interface using:
- the device tree mechanism to pass hypervisor informations to the guest
- hypercalls for guest->host calls
- an example exploiter of that interface (magic page)
This is work in progress, but working so far. I just start to really exploit
the fuctionality behind the magic page mechanism therefor I can't provide any
performance improvements so far, but it is evolved enough for RFC and to start
the standardization discussion.

The used hypercall ABI was already discussed on the embedded-hypervisor mailing
list and is available at http://kvm.qumranet.com/kvmwiki/PowerPC_Hypercall_ABI

The device tree format used here (=base for the discussions on
embedded-hypervisor) is the following.
- A node "hypervisor" to show the general availability of some hypervisor data
- flags for features like the example "feature,pv-magicpage"
  setting 1 = available, everything else = unavailable
- Some features might need to pass more data and can use an entry in the
  device tree like the example of "data,pv-magicpage-size"

Parties on cc:
linuxppc-dev@ozlabs.org
  The patches affect code in the generic powerpc boot&setup so I would be
  happy about comments if the hooks are ok that way.
embedded-hypervisor@power.org
  This power.org TSC discusses about standardization of the virtualization
  interfaces. This patch series is perfectly suited due to it's simple changes
  to start the discussion about the device tree there.
kvm-ppc@vger.kernel.org
  The code is made for kvm on powerpc which lives on this list.

[patches in series]
Subject: [PATCH 1/6] kvmppc: read device tree hypervisor node infrastructure
  Providing the guest functionality to read hypervisor features from the
  device tree and adding the basic hook to the powerpc boot6setup code
Subject: [PATCH 2/6] kvmppc: add hypercall infrastructure - host part
Subject: [PATCH 3/6] kvmppc: add hypercall infrastructure - guest part
  patch 2&3 add the hypercall infrastruture as mentioned above
Subject: [PATCH 4/6] kvmppc: magic page hypercall - host part
Subject: [PATCH 5/6] kvmppc: magic page paravirtualization - guest part
  patch 4&5 add the magic page mechanism which will later on be used for
  binary rewriting the guest.
Subject: [PATCH 6/6] kvmppc: kvm-userspace: device tree modification for magicpage
  This connects host and guest reading host capabilities and modifying the
  device tree passed to the guest accordingly 

---
[diffstat]
 arch/powerpc/kernel/kvm.c            |   48 +++++++++++++++++++++++++++++++++++
 arch/powerpc/kvm/emulate.c           |    5 +++
 b/arch/powerpc/kernel/Makefile       |    2 +
 b/arch/powerpc/kernel/kvm.c          |   30 +++++++++++++++++++++
 b/arch/powerpc/kernel/setup_32.c     |    3 ++
 b/arch/powerpc/kvm/emulate.c         |   27 +++++++++++++++++++
 b/arch/powerpc/kvm/powerpc.c         |   18 ++++++++++++-
 b/arch/powerpc/platforms/44x/Kconfig |    7 +++++
 b/include/asm-powerpc/kvm_para.h     |   37 ++++++++++++++++++++++++--
 b/include/linux/kvm.h                |    6 ++++
 b/libkvm/libkvm-powerpc.c            |    6 ++++
 b/libkvm/libkvm.h                    |    6 ++++
 b/qemu/hw/device_tree.c              |   10 +++++++
 b/qemu/hw/device_tree.h              |    1
 b/qemu/hw/ppc440_bamboo.c            |   15 ++++++++++
 b/qemu/qemu-kvm-powerpc.c            |    5 +++
 b/qemu/qemu-kvm.h                    |    1
 include/asm-powerpc/kvm_para.h       |   47 +++++++++++++++++++++++++++++++++-
 18 files changed, 269 insertions(+), 5 deletions(-)

^ permalink raw reply

* [PATCH 4/6] kvmppc: magic page hypercall - host part
From: ehrhardt @ 2008-07-23  8:36 UTC (permalink / raw)
  To: kvm-ppc, embedded-hypervisor, linuxppc-dev; +Cc: hollisb
In-Reply-To: <1216802207-32675-1-git-send-email-ehrhardt@linux.vnet.ibm.com>

From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

This adds the host part of the magic page registration. This is a memory
area of the guest granted to the host.
The patch just introduces the infrastruture to receive the guest paddr.
This is work in progress and it is intended to later on use this memory
as storage area a guest can read unprivileged (using binary rewriting to
change privileges instructions).

Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
---

[diffstat]
 arch/powerpc/kvm/emulate.c     |    5 +++++
 arch/powerpc/kvm/powerpc.c     |   18 +++++++++++++++++-
 include/asm-powerpc/kvm_para.h |    2 ++
 include/linux/kvm.h            |    6 ++++++
 4 files changed, 30 insertions(+), 1 deletion(-)

[diff]
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -208,6 +208,11 @@
 	int ret = 0;
 
 	switch (vcpu->arch.gpr[0]) {
+	case KVM_HCALL_RESERVE_MAGICPAGE:
+		/* FIXME TODO implement the real fuctionality using that */
+		printk(KERN_ERR"%s - receive magicpage address 0x%x\n",
+			__func__, vcpu->arch.gpr[3]);
+		break;
 	default:
 		printk(KERN_ERR"unknown hypercall %d\n", vcpu->arch.gpr[0]);
 		kvmppc_dump_vcpu(vcpu);
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -148,6 +148,9 @@
 	case KVM_CAP_COALESCED_MMIO:
 		r = KVM_COALESCED_MMIO_PAGE_OFFSET;
 		break;
+	case KVM_CAP_PPCPV_MAGICPAGE:
+		r = 1;
+		break;
 	default:
 		r = 0;
 		break;
@@ -159,7 +162,20 @@
 long kvm_arch_dev_ioctl(struct file *filp,
                         unsigned int ioctl, unsigned long arg)
 {
-	return -EINVAL;
+	long r = -EINVAL;
+
+	switch (ioctl) {
+	case KVM_GET_PPCPV_MAGICPAGE_SIZE:
+		r = -EINVAL;
+		if (arg)
+			goto out;
+		r = 1024;
+		break;
+	default:
+		r = -EINVAL;
+	}
+out:
+	return r;
 }
 
 int kvm_arch_set_memory_region(struct kvm *kvm,
diff --git a/include/asm-powerpc/kvm_para.h b/include/asm-powerpc/kvm_para.h
--- a/include/asm-powerpc/kvm_para.h
+++ b/include/asm-powerpc/kvm_para.h
@@ -24,6 +24,8 @@
 
 #define KVM_HYPERCALL_BIN 0x03ffffff
 
+#define KVM_HCALL_RESERVE_MAGICPAGE	0
+
 static inline int kvm_para_available(void)
 {
 	return 0;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -365,6 +365,11 @@
 #define KVM_TRACE_PAUSE           _IO(KVMIO,  0x07)
 #define KVM_TRACE_DISABLE         _IO(KVMIO,  0x08)
 /*
+ * ioctls for powerpc paravirtualization extensions
+ */
+#define KVM_GET_PPCPV_MAGICPAGE_SIZE       _IO(KVMIO,   0x09)
+
+/*
  * Extension capability list.
  */
 #define KVM_CAP_IRQCHIP	  0
@@ -382,6 +387,7 @@
 #define KVM_CAP_PV_MMU 13
 #define KVM_CAP_MP_STATE 14
 #define KVM_CAP_COALESCED_MMIO 15
+#define KVM_CAP_PPCPV_MAGICPAGE 16
 
 /*
  * ioctls for VM fds

^ permalink raw reply

* [PATCH 2/6] kvmppc: add hypercall infrastructure - host part
From: ehrhardt @ 2008-07-23  8:36 UTC (permalink / raw)
  To: kvm-ppc, embedded-hypervisor, linuxppc-dev; +Cc: hollisb
In-Reply-To: <1216802207-32675-1-git-send-email-ehrhardt@linux.vnet.ibm.com>

From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

This adds the host portion of the hypercall infrastructure which receives
the guest calls - no specific hcall function is implemented in this patch.

Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
---

[diffstat]
 arch/powerpc/kvm/emulate.c     |   27 +++++++++++++++++++++++++++
 include/asm-powerpc/kvm_para.h |    2 ++
 2 files changed, 29 insertions(+)

[diff]
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -203,6 +203,24 @@
 	kvmppc_set_msr(vcpu, vcpu->arch.srr1);
 }
 
+static int kvmppc_do_hypercall(struct kvm_vcpu *vcpu)
+{
+	int ret = 0;
+
+	switch (vcpu->arch.gpr[0]) {
+	default:
+		printk(KERN_ERR"unknown hypercall %d\n", vcpu->arch.gpr[0]);
+		kvmppc_dump_vcpu(vcpu);
+		ret = -ENOSYS;
+	}
+
+	vcpu->arch.gpr[11] = ret;
+	vcpu->arch.pc += 4; /* Advance past hypercall instruction. */
+
+	return ret;
+}
+
+
 /* XXX to do:
  * lhax
  * lhaux
@@ -232,6 +250,15 @@
 	int advance = 1;
 
 	switch (get_op(inst)) {
+	case 0:
+		if (inst == KVM_HYPERCALL_BIN) {
+			kvmppc_do_hypercall(vcpu);
+			advance = 0; /* kvmppc_do_hypercall handles the PC. */
+		} else {
+			printk(KERN_ERR"unknown op %d\n", get_op(inst));
+			emulated = EMULATE_FAIL;
+		}
+		break;
 	case 3:                                                 /* trap */
 		printk("trap!\n");
 		kvmppc_queue_exception(vcpu, BOOKE_INTERRUPT_PROGRAM);
diff --git a/include/asm-powerpc/kvm_para.h b/include/asm-powerpc/kvm_para.h
--- a/include/asm-powerpc/kvm_para.h
+++ b/include/asm-powerpc/kvm_para.h
@@ -22,6 +22,8 @@
 
 #ifdef __KERNEL__
 
+#define KVM_HYPERCALL_BIN 0x03ffffff
+
 static inline int kvm_para_available(void)
 {
 	return 0;

^ permalink raw reply

* Kexec on arch powerpc, device trees
From: Simon Kagstrom @ 2008-07-23  9:48 UTC (permalink / raw)
  To: linuxppc-embedded

Hi!

I'm looking a bit at adding kexec support for our mpc8347-based board
running a 2.6.21 kernel. Since the board isn't a "PPC_MULTIPLATFORM"
one, I did a quick patch to the Kconfig file to allow enabling Kexec
for our own board. The patch below then adds the kexec machine
callbacks for our board, and this is enough to build.

I ran into two problems though: First, /proc/iomem did not contain any
"System RAM", so the kexec userspace tool ended up without any usable
memory regions and fails because of that. I thought this would be
handled by the device tree support, where we have a node for the memory:

	memory {
		device_type = "memory";
		reg = <00000000 20000000>;
	};

but apparently it isn't. Anyway, the add_ram_region_iomem() function
adds a "System RAM" region for all "memory" nodes in the device tree.


However, even after this kexec still fails:

   bash-3.1# /kexec -l /vmlinux
   Invalid memory segment 0xc0000000 - 0xc0304fff

this time because the "System RAM" is really 0x00000000-0x20000000. If
I use the --gamecube=1 option, kexec will load the kernel, but when
trying to start it the board will just crash:

   bash-3.1# /kexec -e -d
   [ 1579.005719] Starting new kernel
   <end up in U-boot here>

So some questions: Is the --gamecube=1 option really meant to be used
without a gamecube and should the first version really fail? Is the
"System RAM" usage correct? Are there any similar freescale-based
boards which have kexec support?

// Simon

Index: linux-2.6.21-standard/arch/powerpc/platforms/83xx/cmxb.c
===================================================================
--- linux-2.6.21-standard.orig/arch/powerpc/platforms/83xx/cmxb.c
+++ linux-2.6.21-standard/arch/powerpc/platforms/83xx/cmxb.c
@@ -23,6 +23,7 @@
 #include <linux/delay.h>
 #include <linux/seq_file.h>
 #include <linux/root_dev.h>
+#include <linux/bootmem.h>
 
 #include <asm/system.h>
 #include <asm/atomic.h>
@@ -35,6 +36,7 @@
 #include <asm/prom.h>
 #include <asm/udbg.h>
 #include <sysdev/fsl_soc.h>
+#include <linux/kexec.h>
 
 #include "mpc83xx.h"
 #include "cmxb.h"
@@ -44,6 +46,31 @@ unsigned long isa_io_base = 0;
 unsigned long isa_mem_base = 0;
 #endif
 
+
+static void add_ram_region_iomem(void)
+{
+	struct device_node *np;
+	struct resource *res;
+	struct resource of_resource;
+
+	for (np = NULL; (np = of_find_node_by_type(np, "memory")) != NULL;) {
+                if (of_address_to_resource(np, 0, &of_resource)) {
+                        printk(KERN_ERR "Could not convert memory node to resource\n");
+                        of_node_put(np);
+                        return;
+                }
+		res = alloc_bootmem(sizeof(struct resource));
+
+		res->name = "System RAM";
+		res->start = of_resource.start;
+		res->end = of_resource.end;
+		res->flags = of_resource.flags;
+		request_resource(&iomem_resource, res);
+                of_node_put(np);
+	}
+}
+
+
 /* ************************************************************************
  *
  * Setup the architecture
@@ -62,6 +89,7 @@ static void __init cmxb_setup_arch(void)
 
 	ppc_md.pci_exclude_device = mpc83xx_exclude_device;
 #endif
+        add_ram_region_iomem();
 }
 
 static void __init cmxb_init_IRQ(void)
@@ -100,4 +128,9 @@ define_machine(cmxb) {
 	.time_init		= mpc83xx_time_init,
 	.calibrate_decr		= generic_calibrate_decr,
 	.progress		= udbg_progress,
+#ifdef CONFIG_KEXEC
+	.machine_kexec		= default_machine_kexec,
+	.machine_kexec_prepare	= default_machine_kexec_prepare,
+	.machine_crash_shutdown	= default_machine_crash_shutdown,
+#endif
 };

^ permalink raw reply

* Re: [alsa-devel] [PATCH 1/2] Support internal I2S clock sources on MPC5200
From: Mark Brown @ 2008-07-23 10:36 UTC (permalink / raw)
  To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20080722235349.11648.90112.stgit@terra>

On Tue, Jul 22, 2008 at 07:53:49PM -0400, Jon Smirl wrote:
> Support internal I2S clock sources on MPC5200

Looks good from an ASoC point of view.  There's quite a few checkpatch
warnings that should be fixed (all fairly straightforward, though) but
other than that I'm happy to apply it with Grant's ack.

^ permalink raw reply

* Re: [alsa-devel] [PATCH 2/2] Allow a custom ASOC machine driver with soc-of-simple
From: Mark Brown @ 2008-07-23 10:53 UTC (permalink / raw)
  To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20080722235351.11648.56387.stgit@terra>

On Tue, Jul 22, 2008 at 07:53:51PM -0400, Jon Smirl wrote:

> Allow a custom ASOC machine driver with soc-of-simple

As with the clocking configuration: this looks fine from an ASoC point
of view but please fix the checkpatch warnings.  However...

>  	/* Only register the device if both the codec and platform have
>  	 * been registered */
> -	if ((!of_soc->device.codec_data) || (!of_soc->platform_node))
> +	if ((!of_soc->device.codec_data) || (!of_soc->platform_node) || !machine_name)
>  		return;

...this doesn't just allow a custom machine driver, it requires that
something configures at least the machine name.  That's not a problem
from the ASoC point of view but possibly from the PowerPC side?

^ permalink raw reply

* Re: Kexec on arch powerpc, device trees
From: Marco Stornelli @ 2008-07-23 11:59 UTC (permalink / raw)
  To: Simon Kagstrom; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <20080723114848.0e2d1a73@seasc0532.dyn.rnd.as.sw.ericsson.se>

Simon Kagstrom ha scritto:
> Hi!
> 
> I'm looking a bit at adding kexec support for our mpc8347-based board
> running a 2.6.21 kernel. Since the board isn't a "PPC_MULTIPLATFORM"
> one, I did a quick patch to the Kconfig file to allow enabling Kexec
> for our own board. The patch below then adds the kexec machine
> callbacks for our board, and this is enough to build.
> 
> I ran into two problems though: First, /proc/iomem did not contain any
> "System RAM", so the kexec userspace tool ended up without any usable
> memory regions and fails because of that. I thought this would be
> handled by the device tree support, where we have a node for the memory:
> 
> 	memory {
> 		device_type = "memory";
> 		reg = <00000000 20000000>;
> 	};
> 
> but apparently it isn't. Anyway, the add_ram_region_iomem() function
> adds a "System RAM" region for all "memory" nodes in the device tree.
> 
> 
> However, even after this kexec still fails:
> 
>    bash-3.1# /kexec -l /vmlinux
>    Invalid memory segment 0xc0000000 - 0xc0304fff
> 
> this time because the "System RAM" is really 0x00000000-0x20000000. If
> I use the --gamecube=1 option, kexec will load the kernel, but when
> trying to start it the board will just crash:
> 
>    bash-3.1# /kexec -e -d
>    [ 1579.005719] Starting new kernel
>    <end up in U-boot here>
> 
> So some questions: Is the --gamecube=1 option really meant to be used
> without a gamecube and should the first version really fail? Is the
> "System RAM" usage correct? Are there any similar freescale-based
> boards which have kexec support?
> 
> // Simon
> 
> Index: linux-2.6.21-standard/arch/powerpc/platforms/83xx/cmxb.c
> ===================================================================
> --- linux-2.6.21-standard.orig/arch/powerpc/platforms/83xx/cmxb.c
> +++ linux-2.6.21-standard/arch/powerpc/platforms/83xx/cmxb.c
> @@ -23,6 +23,7 @@
>  #include <linux/delay.h>
>  #include <linux/seq_file.h>
>  #include <linux/root_dev.h>
> +#include <linux/bootmem.h>
>  
>  #include <asm/system.h>
>  #include <asm/atomic.h>
> @@ -35,6 +36,7 @@
>  #include <asm/prom.h>
>  #include <asm/udbg.h>
>  #include <sysdev/fsl_soc.h>
> +#include <linux/kexec.h>
>  
>  #include "mpc83xx.h"
>  #include "cmxb.h"
> @@ -44,6 +46,31 @@ unsigned long isa_io_base = 0;
>  unsigned long isa_mem_base = 0;
>  #endif
>  
> +
> +static void add_ram_region_iomem(void)
> +{
> +	struct device_node *np;
> +	struct resource *res;
> +	struct resource of_resource;
> +
> +	for (np = NULL; (np = of_find_node_by_type(np, "memory")) != NULL;) {
> +                if (of_address_to_resource(np, 0, &of_resource)) {
> +                        printk(KERN_ERR "Could not convert memory node to resource\n");
> +                        of_node_put(np);
> +                        return;
> +                }
> +		res = alloc_bootmem(sizeof(struct resource));
> +
> +		res->name = "System RAM";
> +		res->start = of_resource.start;
> +		res->end = of_resource.end;
> +		res->flags = of_resource.flags;
> +		request_resource(&iomem_resource, res);
> +                of_node_put(np);
> +	}
> +}
> +
> +
>  /* ************************************************************************
>   *
>   * Setup the architecture
> @@ -62,6 +89,7 @@ static void __init cmxb_setup_arch(void)
>  
>  	ppc_md.pci_exclude_device = mpc83xx_exclude_device;
>  #endif
> +        add_ram_region_iomem();
>  }
>  
>  static void __init cmxb_init_IRQ(void)
> @@ -100,4 +128,9 @@ define_machine(cmxb) {
>  	.time_init		= mpc83xx_time_init,
>  	.calibrate_decr		= generic_calibrate_decr,
>  	.progress		= udbg_progress,
> +#ifdef CONFIG_KEXEC
> +	.machine_kexec		= default_machine_kexec,
> +	.machine_kexec_prepare	= default_machine_kexec_prepare,
> +	.machine_crash_shutdown	= default_machine_crash_shutdown,
> +#endif
>  };
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
Hi mate,

I think currently there's support for the kexec on 85xx.

Regards,

-- 
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it

marco.stornelli@coritel.it
+39 06 72582838

^ permalink raw reply

* Re: [OT] write flash on MPC5200 board via jtag
From: WITTROCK @ 2008-07-23 12:21 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <1216753011l.5683l.0l@antares>


I am using  http://urjtag.org/ UrJtag  to do accomplish this.  I have used it
with both a Wiggler clone and an Altera UsbBlaster as the physical JTAG
interface on both a Linux and Windows (cygwin) host.  The only problem is
that this approach is very slow, so I wrote a small (~8kb) "bootstrap"
program which is first put into flash.  This small program then handles
programming u-boot to flash over a serial interface.  Once u-boot is in
place, I use it to program the rest of flash.

Some JTAG tools actually place a small application in the target devices
ram, then this application allows much faster programming of an attached
flash device.  This requires more information about the COP/BDM interface
than is published in the MPC5200B user manual or data sheet.  I haven't used
the Abatron tools, so maybe they do this.  In the case of UrJtag, it is
simply fiddling with bus signals using boundry scan, so it is excruciatingly
slow.

-WITTROCK
-- 
View this message in context: http://www.nabble.com/-OT--write-flash-on-MPC5200-board-via-jtag-tp18596887p18609501.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox