LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 3/3] ppc64-specific memory notifier support
From: Badari Pulavarty @ 2008-02-29 17:47 UTC (permalink / raw)
  To: michael; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <1204247002.7729.11.camel@concordia.ozlabs.ibm.com>

On Fri, 2008-02-29 at 12:03 +1100, Michael Ellerman wrote:
> On Thu, 2008-02-28 at 18:39 -0600, Nathan Lynch wrote:
> > Michael Ellerman wrote:
> > > On Thu, 2008-02-28 at 08:46 -0800, Badari Pulavarty wrote:
> > > > Hotplug memory notifier for ppc64. This gets invoked by writing
> > > > the device-node that needs to be removed to /proc/ppc64/ofdt.
> > > > We need to adjust the sections and remove sysfs entries by
> > > > calling __remove_pages(). Then call arch specific code to
> > > > get rid of htab mappings for the section of memory.
> > > > 
> > > > Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
> > > > ---
> > > >  arch/powerpc/platforms/pseries/Makefile         |    1 
> > > >  arch/powerpc/platforms/pseries/hotplug-memory.c |   98 ++++++++++++++++++++++++
> > > >  2 files changed, 99 insertions(+)
> > > > 
> > > > Index: linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c
> > > > ===================================================================
> > > > --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> > > > +++ linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c	2008-02-28 08:20:14.000000000 -0800
> > > 
> > > > +
> > > > +static struct notifier_block pseries_smp_nb = {
> > > > +	.notifier_call = pseries_memory_notifier,
> > > > +};
> > > > +
> > > > +static int __init pseries_memory_hotplug_init(void)
> > > > +{
> > > > +	if (firmware_has_feature(FW_FEATURE_LPAR))
> > > > +		pSeries_reconfig_notifier_register(&pseries_smp_nb);
> > > > +
> > > > +	return 0;
> > > > +}
> > > > +arch_initcall(pseries_memory_hotplug_init);
> > > 
> > > This is going to fire on non-pseries LPAR platforms, like iSeries and
> > > PS3. Which is not what you want I think.
> > 
> > Well, the notifier will be registered, yes, but it will never be
> > called because that path is reachable only from a write to
> > /proc/ppc64/ofdt, which is not created on non-pseries.
> 
> Sure. Still seems better not to register it in the first place.
> 
> > Maybe it should be
> > 
> > machine_device_initcall(pseries, pseries_memory_hotplug_init);
> 
> I think so.
> 

Here is the latest for review. (just to make sure I didn't miss
anything).

Thanks,
Badari

Hotplug memory notifier for ppc64. This gets invoked by writing
the device-node that needs to be removed to /proc/ppc64/ofdt.
We need to adjust the sections and remove sysfs entries by
calling __remove_pages(). Then call arch specific code to
get rid of htab mappings for the section of memory.

Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
---
 arch/powerpc/platforms/pseries/Makefile         |    1 
 arch/powerpc/platforms/pseries/hotplug-memory.c |   98 ++++++++++++++++++++++++
 2 files changed, 99 insertions(+)

Index: linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c	2008-02-29 09:25:14.000000000 -0800
@@ -0,0 +1,98 @@
+/*
+ * pseries Memory Hotplug infrastructure.
+ *
+ * Copyright (C) 2008 Badari Pulavarty, IBM Corporation
+ *
+ *      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/prom.h>
+#include <asm/firmware.h>
+#include <asm/machdep.h>
+#include <asm/pSeries_reconfig.h>
+
+static int pseries_remove_memory(struct device_node *np)
+{
+	const char *type;
+	const unsigned int *my_index;
+	const unsigned int *regs;
+	u64 start_pfn, start;
+	struct zone *zone;
+	int ret = -EINVAL;
+
+	/*
+	 * Check to see if we are actually removing memory
+	 */
+	type = of_get_property(np, "device_type", NULL);
+	if (type == NULL || strcmp(type, "memory") != 0)
+		return 0;
+
+	/*
+	 * Find the memory index and size of the removing section
+	 */
+	my_index = of_get_property(np, "ibm,my-drc-index", NULL);
+	if (!my_index)
+		return ret;
+
+	regs = of_get_property(np, "reg", NULL);
+	if (!regs)
+		return ret;
+
+	start_pfn = section_nr_to_pfn(*my_index & 0xffff);
+	zone = page_zone(pfn_to_page(start_pfn));
+
+	/*
+	 * Remove section mappings and sysfs entries for the
+	 * section of the memory we are removing.
+	 *
+	 * NOTE: Ideally, this should be done in generic code like
+	 * remove_memory(). But remove_memory() gets called by writing
+	 * to sysfs "state" file and we can't remove sysfs entries
+	 * while writing to it. So we have to defer it to here.
+	 */
+	ret = __remove_pages(zone, start_pfn, regs[3] >> PAGE_SHIFT);
+	if (ret)
+		return ret;
+
+	/*
+	 * Remove htab bolted mappings for this section of memory
+	 */
+ 	start = (unsigned long)__va(start_pfn << PAGE_SHIFT);
+ 	ret = remove_section_mapping(start, start + regs[3]);
+	return ret;
+}
+
+static int pseries_memory_notifier(struct notifier_block *nb,
+				unsigned long action, void *node)
+{
+	int err = NOTIFY_OK;
+
+	switch (action) {
+	case PSERIES_RECONFIG_ADD:
+		break;
+	case PSERIES_RECONFIG_REMOVE:
+		if (pseries_remove_memory(node))
+			err = NOTIFY_BAD;
+		break;
+	default:
+		err = NOTIFY_DONE;
+		break;
+	}
+	return err;
+}
+
+static struct notifier_block pseries_mem_nb = {
+	.notifier_call = pseries_memory_notifier,
+};
+
+static int __init pseries_memory_hotplug_init(void)
+{
+	if (firmware_has_feature(FW_FEATURE_LPAR))
+		pSeries_reconfig_notifier_register(&pseries_mem_nb);
+
+	return 0;
+}
+machine_device_initcall(pseries, pseries_memory_hotplug_init);
Index: linux-2.6.25-rc2/arch/powerpc/platforms/pseries/Makefile
===================================================================
--- linux-2.6.25-rc2.orig/arch/powerpc/platforms/pseries/Makefile	2008-02-28 08:15:53.000000000 -0800
+++ linux-2.6.25-rc2/arch/powerpc/platforms/pseries/Makefile	2008-02-28 08:17:57.000000000 -0800
@@ -14,6 +14,7 @@ obj-$(CONFIG_PCI)	+= pci.o pci_dlpar.o
 obj-$(CONFIG_PCI_MSI)	+= msi.o
 
 obj-$(CONFIG_HOTPLUG_CPU)	+= hotplug-cpu.o
+obj-$(CONFIG_MEMORY_HOTPLUG)	+= hotplug-memory.o
 
 obj-$(CONFIG_HVC_CONSOLE)	+= hvconsole.o
 obj-$(CONFIG_HVCS)		+= hvcserver.o

^ permalink raw reply

* [RFC] updating lmb.memory information for hot mem add/remove
From: Badari Pulavarty @ 2008-02-29 17:56 UTC (permalink / raw)
  To: michael, paulus; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <1204247002.7729.11.camel@concordia.ozlabs.ibm.com>

Hi,

I am wondering if you could give me your opinion on how to proceed
(before I code too much).

eHEA driver writers wants to know what the memory layout is - where the
holes are and where the reserved memory is. They can get this from
parsing through the device-tree every time, but it would be too
expensive. And also, they would like to get information for contiguous
ranges (instead of 16MB chunks).

Since we already have this information at boot time in lmb.memory, 
lmb.reserve - would it be okay to update those for hotplug mem
add/remove ? Of course, all the routines which handles updates 
(lmb_add() etc..) are available only at boot (__init). I could
change that. Is it acceptable ?

Other way to handle the issue is to come up with arch-neutral
way of representing the memory layout. x86-64 and ia64 shows
this information in /proc/iomem (even there is in chunks not 
combined).

Ideas ? Would it be acceptable if I update lmb.memory for add/remove
memory ? Am I missing something ?

Thanks,
Badari

^ permalink raw reply

* Re: [PATCH] [POWERPC] Fix zImage-dtb.initrd build error
From: Geoff Levand @ 2008-02-29 18:18 UTC (permalink / raw)
  To: Grant Likely
  Cc: Geert.Uytterhoeven, linuxppc-dev, paulus, miltonm, Hiroaki_Fuse
In-Reply-To: <fa686aa40802290633i2918cfbdtecb614065895f82a@mail.gmail.com>

On 02/29/2008 06:33 AM, Grant Likely wrote:
> Any comments on this patch?  It needs to go in for .25, but I haven't
> gotten any Acks on it.

I have it in ps3-linux.git, and seems to work OK.

Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>

^ permalink raw reply

* RE: ML403 Linux port questions
From: Darcy Watkins @ 2008-02-29 18:13 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <ADA5878BA63680469C75C14CEEE2FE28012F482B@mail.serveron.com>

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

Hello,

 

I am using an AMCC PPC405EP based system and find that the following
works...

 

Development / build machine --> Fedora core 6 or 7 on x86 PC

Cross compile and target rootfs generation --> Buildroot

Linux kernel (at least to start with) --> 2.6.19.2 from DENX ELDK 4.1

 

Of course, you can use the cross compile environment from ELDK if you
like.  I used it at first (had a very good out-of-box experience on AMCC
Taihu with it) and then switched to Buildroot later.

 

http://www.denx.de <http://www.denx.de/>  for ELDK / kernel

http://buildroot.uclibc.org <http://buildroot.uclibc.org/>  for
Buildroot

 

I am presently using the Linux 2.6.19.2 kernel with I-Pipe real time
extension (2.3.0) from the Xenomai project - as bundled in ELDK 4.1 by
DENX.  I have also experimented with some newer stuff, but this involves
diving into the board support migration from arch/ppc to arch/powerpc
which is still pretty bleeding edge. 2.6.19.2 is pretty safe and not too
old - and is probably the newest available with RT option while still
being in the arch/ppc tree.

 

Don't attempt to have buildroot automatically build the kernel for you
as part of its config - that may cause you grief as their integration
for PowerPC kernels appears hit-and-miss for 40x series due to all the
arch/ppc versus arch/powerpc stuff.  Also, the buildroot automatic
kernel generation doesn't include RT support (in case you need it).

 

 

Regards,

 

Darcy

 

 

________________________________

From: linuxppc-embedded-bounces+dwatkins=tranzeo.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+dwatkins=tranzeo.com@ozlabs.org] On
Behalf Of Phil Hochstetler
Sent: Friday, February 29, 2008 9:25 AM
To: linuxppc-embedded@ozlabs.org
Subject: ML403 Linux port questions

 

I'm setting up a new development environment to get a working port of
Linux on the Xilinx Virtex-4 chip  (I have a Xilinx ML403 board).  I'm
looking for the quickest way to get a working development environment
for the 2.6 kernel without paying thousands of $$ 

--snip!--

I guess what I am looking for is advise on the lowest risk, easiest to
set up environment to setup that will just work.  Also advise on which
kernel to use. 

--snip!-

 


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

^ permalink raw reply

* No serial port interrupts in /proc/interrupts
From: Gerhard Pircher @ 2008-02-29 19:08 UTC (permalink / raw)
  To: linuxppc-dev

Hi,

I'm wondering why the serial port interrupts don't show up in
/proc/interrupts or in debugfs/powerpc/virq_mapping. I added some debugging
code to the relevant code in arch/powerpc/kernel/irq.c and of_serial.c and
it looks like irq_of_parse_and_map() returns valid virqs (irq3, irq4 on a
i8259) for the two ns16550 compatible UARTs. Is there anything else to do,
to correctly implement UART support for a platform?

regards,

Gerhard

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

^ permalink raw reply

* Re: [PATCH 0/3] hotplug memory remove updates
From: Nathan Lynch @ 2008-02-29 19:15 UTC (permalink / raw)
  To: Geoff Levand; +Cc: linuxppc-dev, Badari Pulavarty
In-Reply-To: <47C76BBA.5000503@am.sony.com>

Geoff Levand wrote:
> 
> I'm wondering how the memory hot un-plug is initiated on the pseries.
> Could you tell me about this HMC?  Is it an application running in
> the lpar, or is it an external entity?

The HMC (Hardware Management Console) is a system separate from the
pseries box.  It's used to provision and, um, manage, one or more
systems and their partitions.  It communicates with both the POWER
hypervisor and some optional userspace daemons and utilities running
on the lpars.

> Is there a 'standard' interface from userspace that can be used to
> trigger the hot-unplug sequence?  I'm asking because PS3's lv1
> hypervisor supports hot un-plug of memory, but it would need to be
> triggered from some kind of management application running in in
> userspace.

I think sysfs is the conventional interface for "offlining" a
resource, that is, getting Linux to stop using it.  That's what is
used for cpu online/offline (and memory as well, I think).  Releasing
a resource to the hypervisor's control is necessarily a
platform-specific operation; on pseries a userspace utility calls a
set of RTAS methods to accomplish this.

^ permalink raw reply

* Re: ML403 Linux port questions
From: Grant Likely @ 2008-02-29 20:46 UTC (permalink / raw)
  To: Phil Hochstetler; +Cc: linuxppc-embedded
In-Reply-To: <ADA5878BA63680469C75C14CEEE2FE28012F482B@mail.serveron.com>

On Fri, Feb 29, 2008 at 10:24 AM, Phil Hochstetler
<Phil.Hochstetler@serveron.com> wrote:
> I guess what I am looking for is advise on the lowest risk, easiest to set
> up environment to setup that will just work.  Also advise on which kernel to
> use.   I don't need a detailed tutorial but a high level direct that is
> known to work.  I am thinking of using either the secret lab tree or the
> Xilinx tree as recommended in Grants wiki page.  Should I just forget using
> XP and install a Linux (x86 processor so I must use cross tools)?   If so,
> what is the recommend distro and what version?

Yes, absolutely.  Going down the cygwin path is doable, but it is a
path of pain.  I strongly recommend using a Linux host.  (I personally
use Ubuntu, but you should have good success with any disto.  Use what
you're most comfortable with).

The simplest approach to get running with a Linux box is to install
either VirtualBox or VMware and create yourself a Linux virtual
machine.  That will get you up and running without having to obtain
new hardware or risk breaking your XP setup.

Cheers,
g.

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

^ permalink raw reply

* Re: [PATCH 04/11] [RFC][GPIOLIB] add gpio_set_dedicated() routine
From: Anton Vorontsov @ 2008-02-29 20:55 UTC (permalink / raw)
  To: David Brownell; +Cc: linuxppc-dev
In-Reply-To: <20080215114029.GA16810@localhost.localdomain>

On Fri, Feb 15, 2008 at 02:40:29PM +0300, Anton Vorontsov wrote:
[...]
> > > {
> > > 	qe_chip = container_of(gpio_to_chip(...), struct qe_chip, chip);
> > > 	...
> > 
> > You know, you can write all this yourself, without needing any
> > support from the GPIO framework whatsoever.  The QE stuff that
> > registered a gpio_chip interface to its hardware probably keeps
> > some records itself, sufficient for such (infrequent) mappings.
> 
> Yes, surely. And as I've said already, I do know how to workaround
> that, without GPIOLIB support. The thing is that I don't like the
> way I'm going to do it.

...please, don't force me to do these dirty hacks inside the arch code,
nobody will like them, I know it beforehand. ;-)

...if you so reluctant supporting dedicated functions inside the gpiolib,
then nothing could be easier than exporting gpio_to_chip(), so arch code
can write extensions without dirty hacks. Please?


p.s. By "dirty hacks" I mean:

a) drivers will need to fetch and store device_node in their private
   driver data, in _addition_ to gpio numbers;

b) which means that I'll have to introduce of_get_gpio_controller()
   to solely workaround gpio_to_chip() absence;

c) and all that will result in 9 * N additional lines of code to
   handle by the drivers, where N is the number of GPIOs we want to use:

   struct drvdata {
   (1) struct device_node *gpioX_controller;

   drv_probe()
   (2) drvdata->gpioX_controller = of_get_gpio_controller(...);
   (3) if (!drvdata->gpioX_controller) {
   (4)        ret = -EINVAL;
   (5)        goto gpioX_contr_failed;
   (6) }
   (7) gpioX_contr_failed:
   (8) of_put_gpio_controller(drvdata->gpioX_controller)

   drv_remove()
   {
   (9) of_put_gpio_controller(drvdata->gpioX_controller)

-- 
Anton Vorontsov
email: cboumailru@gmail.com
irc://irc.freenode.net/bd2

^ permalink raw reply

* Kernel 2.6 configuration
From: rodolfo @ 2008-02-29 21:28 UTC (permalink / raw)
  To: Linuxppc embedded, rodolfo
In-Reply-To: <fa686aa40802251205t5c9e76a3yf314b325bfcdd342@mail.gmail.com>

As Grant Likely said I downloaded the last release of linux kernel
(2.6.24). How can I configure the kernel for XUP v II P ? Which are the
minimal required configuration for a simple test? I just want to check if
the ppc405 is booting the kernel image.

Thanks !

On Mon, 25 Feb 2008 13:05:19 -0700, "Grant Likely"
<grant.likely@secretlab.ca> wrote:
> On Mon, Feb 25, 2008 at 12:05 PM, rodolfo <rodolfo@lesc.ufc.br> wrote:
>> Hey everybody,
>>
>>  I'm in trouble;
>>
>>  1) The EDK flow: I set the OS in the Software Plataform Settings to
>>  linux_2_6 version 1.00.a. after that, in OS and Library section I have
> to
>>  fill out the fields "memory size" , "connected_periphs" , "ramdisk
> size"
>>  ... ?  How would I do it ?
>>
>>  2) Do I place xparametera_ml300.h in
> /opt/ELDK/ppc_4xx/usr/src/linux-2.6.15
>>  ? if not where?
> 
> You should download a current release of the linux kernel.  Don't use
> the one that comes with ELDK.
> 
> in arch/ppc/platforms/4xx/xparameters/xparameters_ml403.h.  If you're
> using the ml403 reference design, it is already there.  If you're
> using a custom design then you'll need to replace it.
> 
> See here for hints:
> 
> http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
> 
>>  3) I downloaded "ppc-2006-01-11.iso" from denx (ELDK) website and I'm
>>  trying to follow their instructions for ppc 4xx plataform.
>>  [ website: http://www.denx.de/wiki/view/DULG/ELDK ]
> 
> This is an old release of ELDK.  You should probably move up to a more
> recent release.
> 
>>
>>  In /opt/ELDK/ppc_4xx/usr/src/u-boot-1.1.4/ I do:
>>
>>  "make distclen" and  "make ml300_config" are ok! After "make all" in 
> I've
>>  got an error:
>>
>>  a - ppc_longjmp.o
>>  a - ppc_setjmp.o
>>  a - stubs.o
>>  make[1]: *** No rules for processing the target `hello_world.srec',
> needed
>>  by `all'. Stop.       --> note: "TRANSLATION FROM PORTUGESE"
>>  make[1]: Exiting `/opt/ELDK/ppc_4xx/usr/src/u-boot-1.1.4/examples'
>>  make: ** [examples] Error 2
> 
> You're using an ancient copy of u-boot that breaks with certain
> versions of the 'make' program.  You should try using a recent release
> of u-boot.  Alternately, you can hack the u-boot makefile to not build
> the examples directory.
> 
> Cheers,
> g.
> 
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* Sequoia build with KDBG
From: Steve Heflin @ 2008-02-29 21:34 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20080222145224.7349cf36@weaponx>

I attempted to enable the kernel debugger on my Sequoia board, and I 
get build errors:
  /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:254: undefined 
reference to `set_debug_traps'
  /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:259: undefined 
reference to `breakpoint'

Josh: I assume you have used the kernel debugger with your 44x 
boards, how did you build it?

thanks so much,
Steve

^ permalink raw reply

* Re: Sequoia build with KDBG
From: Josh Boyer @ 2008-02-29 21:35 UTC (permalink / raw)
  To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <200802292133.m1TLXqv3012273@e36.co.us.ibm.com>

On Fri, 29 Feb 2008 16:34:09 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:

> I attempted to enable the kernel debugger on my Sequoia board, and I 
> get build errors:
>   /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:254: undefined 
> reference to `set_debug_traps'
>   /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:259: undefined 
> reference to `breakpoint'
> 
> Josh: I assume you have used the kernel debugger with your 44x 
> boards, how did you build it?

Why would you assume that?  I've never used kgdb on arch/powerpc
kernels, nor have I ever tried to build it.

I don't think kgdb is ported to powerpc at the moment.

josh

^ permalink raw reply

* Re: [PATCH 1/2] firewire: endianess fix
From: Benjamin Herrenschmidt @ 2008-02-29 21:49 UTC (permalink / raw)
  To: Stefan Richter
  Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, Paul Mackerras,
	sparclinux, Jarod Wilson, linux1394-devel, Sam Ravnborg,
	Harvey Harrison
In-Reply-To: <47C7F209.9030907@s5r6.in-berlin.de>


> The second line looks like this is indeed one of those which needs the 
> header byte-swap workaround which ohci1394 has but firewire-ohci hasn't yet.
> 
> On the weekend I'm going to attempt to put Linux on this PowerBook, at last.

Those machines can netboot, or boot from USB. Might be easier for you.

For that sort of test, usually, I just netboot a zImage with built-in
initrd, using an initrd with all the tools I need on it.

(A way to build that sort of initrd or initramfs is OpenWRT though I use
a home made one).

You can netboot any newworld mac with that OF command:

boot enet:tftp_server_ip,filename

(you need to make sure you have a DHCP around to give it an address).

However, make _SURE_ you use the file arch/powerpc/boot/zImage.pmac (and
not any other zImage).

To build one with an initrd included, put the initrd in
arch/powerpc/boot as "ramdisk.image.gz" and do make zImage.initrd.

That should result in a file name zImage.initrd.pmac that you can
netboot.

Cheers,
Ben.

^ permalink raw reply

* Re: ML403 Linux port questions
From: Brian Silverman @ 2008-02-29 22:11 UTC (permalink / raw)
  To: Phil Hochstetler; +Cc: linuxppc-embedded
In-Reply-To: <ADA5878BA63680469C75C14CEEE2FE28012F482B@mail.serveron.com>

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

I am currently building under cygwin for the Virtex-4.  Yes, it's likely 
more of a pain, but its doable.  But any way you slice it, its not 
instantaneous to get a build environment up and running.

Anyway, here's what I'm using right now:

crosstool 0.42 (gcc3.4.1, glibc2.3.3) (possibly patched)
Linux 2.6.24-rc8-xlnx (git.xilinx.com)
    - with patch for building under cygwin: 
http://lkml.org/lkml/2007/2/22/421
    - A missing elf.h file, not in my cygwin distribution.

Also a pain with cygwin is the NFS server - I had difficulty getting it 
to work with more recent cygwin install, and have been unable to 
downgrade it.  Finally, with no loopback device in cygwin, if you want 
to create initrd's, you have to do this on a Linux box.  But this is now 
less of an issue in 2.6 with initramfs.

-bri


Phil Hochstetler wrote:
>
> I'm setting up a new development environment to get a working port of 
> Linux on the Xilinx Virtex-4 chip  (I have a Xilinx ML403 board).  I'm 
> looking for the quickest way to get a working development environment 
> for the 2.6 kernel without paying thousands of $$ (what happened to 
> MontaVista?).  My first attempt was to use google and found lots of 
> resources.  The problem is that much of the info is dated or makes 
> assumptions about your environment.  I read Grants write-up at 
> http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex.  Because I 
> want to use Windows XP SP2 as the host if possible, I went down the 
> path of installing the current Cygwin and was able to create cross 
> tools (gcc 4.1) successfully.  The problem I am having is that the 
> Linux build process requires a newer gcc than 3.4.4-3 which is what 
> Cygwin provides.  I have used the EDK to build a bsp package 
> successfully so that is not a problem.  I tried to compile the 
> 2.6.24.2 mainline kernel but it fails to compile using the Cygwin 
> tools (it never gets as far as using them).
>
>  
>
> I guess what I am looking for is advise on the lowest risk, easiest to 
> set up environment to setup that will just work.  Also advise on which 
> kernel to use.   I don't need a detailed tutorial but a high level 
> direct that is known to work.  I am thinking of using either the 
> secret lab tree or the Xilinx tree as recommended in Grants wiki 
> page.  Should I just forget using XP and install a Linux (x86 
> processor so I must use cross tools)?   If so, what is the recommend 
> distro and what version?
>
>  
>
> Thanks for all your sharing of experience.  I hope to contribute back 
> as soon as I can.
>
>  
>
> --phil
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded


-- 
Brian Silverman
Concept X, LLC


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

^ permalink raw reply

* Re: Sequoia build with KDBG
From: Steve Heflin @ 2008-02-29 22:31 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20080229153534.684aebf9@zod.rchland.ibm.com>

At 04:35 PM 2/29/2008, Josh Boyer wrote:
>On Fri, 29 Feb 2008 16:34:09 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > I attempted to enable the kernel debugger on my Sequoia board, and I
> > get build errors:
> >   /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:254: undefined
> > reference to `set_debug_traps'
> >   /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:259: undefined
> > reference to `breakpoint'
> >
> > Josh: I assume you have used the kernel debugger with your 44x
> > boards, how did you build it?
>
>Why would you assume that?  I've never used kgdb on arch/powerpc
>kernels, nor have I ever tried to build it.
>
>I don't think kgdb is ported to powerpc at the moment.
>
>josh

I assumed that because I've always needed a debugger when 
implementing kernel level components. Since you've implemented kernel 
level support for several 44x processors, I just assumed that you 
needed kdbg at some point. So you're saying that your additions 
worked right out of the gate and you never needed a debugger?  You're my hero!

^ permalink raw reply

* Re: Sequoia build with KDBG
From: Josh Boyer @ 2008-02-29 22:51 UTC (permalink / raw)
  To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <200802292230.m1TMUk4I005462@e31.co.us.ibm.com>

On Fri, 29 Feb 2008 17:31:10 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:

> At 04:35 PM 2/29/2008, Josh Boyer wrote:
> >On Fri, 29 Feb 2008 16:34:09 -0500
> >Steve Heflin <sheflin@newagemicro.com> wrote:
> >
> > > I attempted to enable the kernel debugger on my Sequoia board, and I
> > > get build errors:
> > >   /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:254: undefined
> > > reference to `set_debug_traps'
> > >   /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:259: undefined
> > > reference to `breakpoint'
> > >
> > > Josh: I assume you have used the kernel debugger with your 44x
> > > boards, how did you build it?
> >
> >Why would you assume that?  I've never used kgdb on arch/powerpc
> >kernels, nor have I ever tried to build it.
>
> I assumed that because I've always needed a debugger when 
> implementing kernel level components. Since you've implemented kernel 
> level support for several 44x processors, I just assumed that you 
> needed kdbg at some point. So you're saying that your additions 

Nope.  I did the poor man's method of manually poking characters out of
the serial port.

> worked right out of the gate and you never needed a debugger?  You're my hero!

I largely stood on the shoulders of those that came before me.  Porting
has become trivial lately, mostly due to the collective work lots of
people have put in.

That all being said, I'm not opposed to having kgdb work on 4xx.  I
just have never personally looked at it yet.  Patches welcome :).

josh

^ permalink raw reply

* Re: Sequoia build with KDBG
From: Scott Wood @ 2008-02-29 22:58 UTC (permalink / raw)
  To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080229223046.1B332DDE0A@ozlabs.org>

Steve Heflin wrote:
> I assumed that because I've always needed a debugger when 
> implementing kernel level components. Since you've implemented kernel 
> level support for several 44x processors, I just assumed that you 
> needed kdbg at some point. So you're saying that your additions 
> worked right out of the gate and you never needed a debugger?  You're my hero!

There are ways of debugging that don't involve a debugger.

-Scott

^ permalink raw reply

* Re: Sequoia build with KDBG
From: Jon Loeliger @ 2008-02-29 23:28 UTC (permalink / raw)
  To: Scott Wood; +Cc: Steve Heflin, linuxppc-embedded
In-Reply-To: <47C88E25.2050306@freescale.com>

Scott Wood wrote:

> There are ways of debugging that don't involve a debugger.

I suppose we could get all tautological and start claiming
that anything that helped one debug something might be, by
definition, a debugger. :-)

(de-)buggering off,
jdl

^ permalink raw reply

* Re: Sequoia build with KDBG
From: Steve Heflin @ 2008-03-01  0:36 UTC (permalink / raw)
  To: linuxppc-embedded

At 05:51 PM 2/29/2008, you wrote:
>On Fri, 29 Feb 2008 17:31:10 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > At 04:35 PM 2/29/2008, Josh Boyer wrote:
> > >On Fri, 29 Feb 2008 16:34:09 -0500
> > >Steve Heflin <sheflin@newagemicro.com> wrote:
> > >
> > > > I attempted to enable the kernel debugger on my Sequoia board, and I
> > > > get build errors:
> > > >   /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:254: undefined
> > > > reference to `set_debug_traps'
> > > >   /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:259: undefined
> > > > reference to `breakpoint'
> > > >
> > > > Josh: I assume you have used the kernel debugger with your 44x
> > > > boards, how did you build it?
> > >
> > >Why would you assume that?  I've never used kgdb on arch/powerpc
> > >kernels, nor have I ever tried to build it.
> >
> > I assumed that because I've always needed a debugger when
> > implementing kernel level components. Since you've implemented kernel
> > level support for several 44x processors, I just assumed that you
> > needed kdbg at some point. So you're saying that your additions
>
>Nope.  I did the poor man's method of manually poking characters out of
>the serial port.
>
> > worked right out of the gate and you never needed a 
> debugger?  You're my hero!
>
>I largely stood on the shoulders of those that came before me.  Porting
>has become trivial lately, mostly due to the collective work lots of
>people have put in.
>
>That all being said, I'm not opposed to having kgdb work on 4xx.  I
>just have never personally looked at it yet.  Patches welcome :).
>
>josh

poor man's debugging works fine if a serial port is available, but my 
Sequoia platform doesn't get that far!  I use u-boot to download and 
boot my image, and I don't get any serial output after the boot completes:

=> bootm 0x500000
## Booting image at 00500000 ...
    Image Name:   Kernel and Ramdisk
    Created:      2008-03-01   0:09:57 UTC
    Image Type:   PowerPC Linux Multi-File Image (gzip compressed)
    Data Size:    2430248 Bytes =  2.3 MB
    Load Address: 00000000
    Entry Point:  00000000
    Contents:
    Image 0:  1471523 Bytes =  1.4 MB
    Image 1:   958712 Bytes = 936.2 kB
    Verifying Checksum ... OK
    Uncompressing Multi-File Image ... OK
    Loading Ramdisk to 07e42000, end 07f2c0f8 ... OK
------
console port is now dead.
------

^ permalink raw reply

* Re: Sequoia build with KDBG
From: Wolfgang Denk @ 2008-03-01  0:16 UTC (permalink / raw)
  To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080229223046.1B332DDE0A@ozlabs.org>

In message <20080229223046.1B332DDE0A@ozlabs.org> you wrote:
>
> I assumed that because I've always needed a debugger when 
> implementing kernel level components. Since you've implemented kernel 
> level support for several 44x processors, I just assumed that you 
> needed kdbg at some point. So you're saying that your additions 
> worked right out of the gate and you never needed a debugger?  You're my hero!

Many people working on this stuff use a BDI2000 / BDI3000. Makes life
much easier...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I have the simplest tastes.  I am always satisfied with the best.
                                                       -- Oscar Wilde

^ permalink raw reply

* Re: [RFC] updating lmb.memory information for hot mem add/remove
From: Badari Pulavarty @ 2008-03-01  1:12 UTC (permalink / raw)
  To: michael; +Cc: Nathan Lynch, anton, paulus, linuxppc-dev
In-Reply-To: <1204307816.10146.11.camel@dyn9047017100.beaverton.ibm.com>

On Fri, 2008-02-29 at 09:56 -0800, Badari Pulavarty wrote:
> Hi,
> 
> I am wondering if you could give me your opinion on how to proceed
> (before I code too much).
> 
> eHEA driver writers wants to know what the memory layout is - where the
> holes are and where the reserved memory is. They can get this from
> parsing through the device-tree every time, but it would be too
> expensive. And also, they would like to get information for contiguous
> ranges (instead of 16MB chunks).
> 
> Since we already have this information at boot time in lmb.memory, 
> lmb.reserve - would it be okay to update those for hotplug mem
> add/remove ? Of course, all the routines which handles updates 
> (lmb_add() etc..) are available only at boot (__init). I could
> change that. Is it acceptable ?
> 
> Other way to handle the issue is to come up with arch-neutral
> way of representing the memory layout. x86-64 and ia64 shows
> this information in /proc/iomem (even there is in chunks not 
> combined).
> 
> Ideas ? Would it be acceptable if I update lmb.memory for add/remove
> memory ? Am I missing something ?

Here is what I cooked up and it seems to work fine.
It may be easier to review the code (against my earlier patches).

Thanks,
Badari

ppc kernel maintains information about logical memory blocks in
lmb.memory structure at the boot time. Its not updated for
hotplug memory add/remove. hotplug memory notifier for memory
add/remove now updates lmb.memory.

This information is useful for eHEA driver to find out the memory 
layout and holes.

TODO: locking ?

---
 arch/powerpc/mm/lmb.c                           |   61 +++++++++++++++++++++---
 arch/powerpc/platforms/pseries/hotplug-memory.c |   42 ++++++++++++++++
 include/asm-powerpc/lmb.h                       |    3 -
 3 files changed, 98 insertions(+), 8 deletions(-)

Index: linux-2.6.25-rc2/arch/powerpc/mm/lmb.c
===================================================================
--- linux-2.6.25-rc2.orig/arch/powerpc/mm/lmb.c	2008-02-15 12:57:20.000000000 -0800
+++ linux-2.6.25-rc2/arch/powerpc/mm/lmb.c	2008-02-29 16:55:49.000000000 -0800
@@ -60,13 +60,13 @@ void lmb_dump_all(void)
 #endif /* DEBUG */
 }
 
-static unsigned long __init lmb_addrs_overlap(unsigned long base1,
+static unsigned long lmb_addrs_overlap(unsigned long base1,
 		unsigned long size1, unsigned long base2, unsigned long size2)
 {
 	return ((base1 < (base2+size2)) && (base2 < (base1+size1)));
 }
 
-static long __init lmb_addrs_adjacent(unsigned long base1, unsigned long size1,
+static long lmb_addrs_adjacent(unsigned long base1, unsigned long size1,
 		unsigned long base2, unsigned long size2)
 {
 	if (base2 == base1 + size1)
@@ -77,7 +77,7 @@ static long __init lmb_addrs_adjacent(un
 	return 0;
 }
 
-static long __init lmb_regions_adjacent(struct lmb_region *rgn,
+static long lmb_regions_adjacent(struct lmb_region *rgn,
 		unsigned long r1, unsigned long r2)
 {
 	unsigned long base1 = rgn->region[r1].base;
@@ -88,7 +88,7 @@ static long __init lmb_regions_adjacent(
 	return lmb_addrs_adjacent(base1, size1, base2, size2);
 }
 
-static void __init lmb_remove_region(struct lmb_region *rgn, unsigned long r)
+static void lmb_remove_region(struct lmb_region *rgn, unsigned long r)
 {
 	unsigned long i;
 
@@ -100,7 +100,7 @@ static void __init lmb_remove_region(str
 }
 
 /* Assumption: base addr of region 1 < base addr of region 2 */
-static void __init lmb_coalesce_regions(struct lmb_region *rgn,
+static void lmb_coalesce_regions(struct lmb_region *rgn,
 		unsigned long r1, unsigned long r2)
 {
 	rgn->region[r1].size += rgn->region[r2].size;
@@ -135,7 +135,7 @@ void __init lmb_analyze(void)
 }
 
 /* This routine called with relocation disabled. */
-static long __init lmb_add_region(struct lmb_region *rgn, unsigned long base,
+static long lmb_add_region(struct lmb_region *rgn, unsigned long base,
 				  unsigned long size)
 {
 	unsigned long coalesced = 0;
@@ -191,7 +191,7 @@ static long __init lmb_add_region(struct
 }
 
 /* This routine may be called with relocation disabled. */
-long __init lmb_add(unsigned long base, unsigned long size)
+long lmb_add(unsigned long base, unsigned long size)
 {
 	struct lmb_region *_rgn = &(lmb.memory);
 
@@ -203,6 +203,53 @@ long __init lmb_add(unsigned long base, 
 
 }
 
+long lmb_remove(unsigned long base, unsigned long size)
+{
+	struct lmb_region *rgn = &(lmb.memory);
+	unsigned long end = base + size;
+	unsigned long rgnbegin, rgnend;
+	int i;
+
+	/* Find the region where (base, size) belongs to */
+	for (i=0; i < rgn->cnt; i++) {
+		rgnbegin = rgn->region[i].base;
+		rgnend = rgnbegin + rgn->region[i].size;
+
+		if ((rgnbegin <= base) && (end <= rgnend))
+			break;
+	}
+
+	/* Didn't find the region */
+	if (i == rgn->cnt)
+		return -1;
+
+	/* Check to see if we are removing entire region */
+	if ((rgnbegin == base) && (rgnend == end)) {
+		lmb_remove_region(rgn, i);
+		return 0;
+	}
+
+	/* Check to see if region is matching at the front */
+	if (rgnbegin == base) {
+		rgn->region[i].base = end;
+		rgn->region[i].size -= size;
+		return 0;
+	}
+
+	/* Check to see if the region is matching at the end */
+	if (rgnend == end) {
+		rgn->region[i].size -= size;
+		return 0;
+	}
+
+	/*
+	 * We need to split the entry -  adjust the current one to the
+	 * beginging of the hole and add the region after hole.
+	 */
+	rgn->region[i].size = base - rgn->region[i].base;
+	return lmb_add_region(rgn, end, rgnend - end);
+}
+
 long __init lmb_reserve(unsigned long base, unsigned long size)
 {
 	struct lmb_region *_rgn = &(lmb.reserved);
Index: linux-2.6.25-rc2/include/asm-powerpc/lmb.h
===================================================================
--- linux-2.6.25-rc2.orig/include/asm-powerpc/lmb.h	2008-02-15 12:57:20.000000000 -0800
+++ linux-2.6.25-rc2/include/asm-powerpc/lmb.h	2008-02-29 13:42:03.000000000 -0800
@@ -41,7 +41,8 @@ extern struct lmb lmb;
 
 extern void __init lmb_init(void);
 extern void __init lmb_analyze(void);
-extern long __init lmb_add(unsigned long base, unsigned long size);
+extern long lmb_add(unsigned long base, unsigned long size);
+extern long lmb_remove(unsigned long base, unsigned long size);
 extern long __init lmb_reserve(unsigned long base, unsigned long size);
 extern unsigned long __init lmb_alloc(unsigned long size, unsigned long align);
 extern unsigned long __init lmb_alloc_base(unsigned long size,
Index: linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c
===================================================================
--- linux-2.6.25-rc2.orig/arch/powerpc/platforms/pseries/hotplug-memory.c	2008-02-29 09:25:14.000000000 -0800
+++ linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c	2008-02-29 16:58:33.000000000 -0800
@@ -12,6 +12,7 @@
 #include <asm/prom.h>
 #include <asm/firmware.h>
 #include <asm/machdep.h>
+#include <asm/lmb.h>
 #include <asm/pSeries_reconfig.h>
 
 static int pseries_remove_memory(struct device_node *np)
@@ -58,6 +59,11 @@ static int pseries_remove_memory(struct 
 		return ret;
 
 	/*
+	 * Update memory regions for memory remove
+	 */
+	lmb_remove(start_pfn << PAGE_SHIFT, regs[3]);
+
+	/*
 	 * Remove htab bloted mappings for this section of memory
 	 */
  	start = (unsigned long)__va(start_pfn << PAGE_SHIFT);
@@ -65,6 +71,40 @@ static int pseries_remove_memory(struct 
 	return ret;
 }
 
+static int pseries_add_memory(struct device_node *np)
+{
+	const char *type;
+	const unsigned int *my_index;
+	const unsigned int *regs;
+	u64 start_pfn;
+	int ret = -EINVAL;
+
+	/*
+	 * Check to see if we are actually adding memory
+	 */
+	type = of_get_property(np, "device_type", NULL);
+	if (type == NULL || strcmp(type, "memory") != 0)
+		return 0;
+
+	/*
+	 * Find the memory index and size of the removing section
+	 */
+	my_index = of_get_property(np, "ibm,my-drc-index", NULL);
+	if (!my_index)
+		return ret;
+
+	regs = of_get_property(np, "reg", NULL);
+	if (!regs)
+		return ret;
+
+	start_pfn = section_nr_to_pfn(*my_index & 0xffff);
+
+	/*
+	 * Update memory region to represent the memory add
+	 */
+	return lmb_add(start_pfn << PAGE_SHIFT, regs[3]);
+}
+
 static int pseries_memory_notifier(struct notifier_block *nb,
 				unsigned long action, void *node)
 {
@@ -72,6 +112,8 @@ static int pseries_memory_notifier(struc
 
 	switch (action) {
 	case PSERIES_RECONFIG_ADD:
+		if (pseries_add_memory(node))
+			err = NOTIFY_BAD;
 		break;
 	case PSERIES_RECONFIG_REMOVE:
 		if (pseries_remove_memory(node))

^ permalink raw reply

* [PATCH 0/3] firewire: PPC PMac updates
From: Stefan Richter @ 2008-03-01  1:42 UTC (permalink / raw)
  To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel

Next up:
1/3 firewire: fw-ohci: PPC PMac platform code
2/3 firewire: fw-ohci: Apple UniNorth 1st generation support
3/3 firewire: fw-ohci: shut up false compiler warning on PPC32
-- 
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/

^ permalink raw reply

* [PATCH 1/3] firewire: fw-ohci: PPC PMac platform code
From: Stefan Richter @ 2008-03-01  1:42 UTC (permalink / raw)
  To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <tkrat.ac97915a5b51e35b@s5r6.in-berlin.de>

Copied from ohci1394.c.  This code is necessary to prevent machine check
exceptions when reloading or resuming the driver.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 drivers/firewire/fw-ohci.c |   50 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

Index: linux-2.6.25-rc3/drivers/firewire/fw-ohci.c
===================================================================
--- linux-2.6.25-rc3.orig/drivers/firewire/fw-ohci.c
+++ linux-2.6.25-rc3/drivers/firewire/fw-ohci.c
@@ -33,6 +33,10 @@
 #include <asm/page.h>
 #include <asm/system.h>
 
+#ifdef CONFIG_PPC_PMAC
+#include <asm/pmac_feature.h>
+#endif
+
 #include "fw-ohci.h"
 #include "fw-transaction.h"
 
@@ -2057,6 +2061,18 @@ pci_probe(struct pci_dev *dev, const str
 	int err;
 	size_t size;
 
+#ifdef CONFIG_PPC_PMAC
+	/* Necessary on some machines if fw-ohci was loaded/ unloaded before */
+	if (machine_is(powermac)) {
+		struct device_node *ofn = pci_device_to_OF_node(dev);
+
+		if (ofn) {
+			pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 1);
+			pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
+		}
+	}
+#endif /* CONFIG_PPC_PMAC */
+
 	ohci = kzalloc(sizeof(*ohci), GFP_KERNEL);
 	if (ohci == NULL) {
 		fw_error("Could not malloc fw_ohci data.\n");
@@ -2189,6 +2205,20 @@ static void pci_remove(struct pci_dev *d
 	pci_iounmap(dev, ohci->registers);
 	pci_release_region(dev, 0);
 	pci_disable_device(dev);
+
+#ifdef CONFIG_PPC_PMAC
+	/* On UniNorth, power down the cable and turn off the chip clock
+	 * to save power on laptops */
+	if (machine_is(powermac)) {
+		struct device_node* ofn = pci_device_to_OF_node(dev);
+
+		if (ofn) {
+			pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
+			pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 0);
+		}
+	}
+#endif /* CONFIG_PPC_PMAC */
+
 	kfree(&ohci->card);
 
 	fw_notify("Removed fw-ohci device.\n");
@@ -2211,6 +2241,16 @@ static int pci_suspend(struct pci_dev *p
 	if (err)
 		fw_error("pci_set_power_state failed with %d\n", err);
 
+/* PowerMac suspend code comes last */
+#ifdef CONFIG_PPC_PMAC
+	if (machine_is(powermac)) {
+		struct device_node *ofn = pci_device_to_OF_node(pdev);
+
+		if (ofn)
+			pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
+	}
+#endif /* CONFIG_PPC_PMAC */
+
 	return 0;
 }
 
@@ -2219,6 +2259,16 @@ static int pci_resume(struct pci_dev *pd
 	struct fw_ohci *ohci = pci_get_drvdata(pdev);
 	int err;
 
+/* PowerMac resume code comes first */
+#ifdef CONFIG_PPC_PMAC
+	if (machine_is(powermac)) {
+		struct device_node *ofn = pci_device_to_OF_node(pdev);
+
+		if (ofn)
+			pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
+	}
+#endif /* CONFIG_PPC_PMAC */
+
 	pci_set_power_state(pdev, PCI_D0);
 	pci_restore_state(pdev);
 	err = pci_enable_device(pdev);

-- 
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/

^ permalink raw reply

* Re: [RFC] updating lmb.memory information for hot mem add/remove
From: David Miller @ 2008-03-01  1:44 UTC (permalink / raw)
  To: pbadari; +Cc: paulus, anton, ntl, linuxppc-dev
In-Reply-To: <1204333964.10146.18.camel@dyn9047017100.beaverton.ibm.com>

From: Badari Pulavarty <pbadari@us.ibm.com>
Date: Fri, 29 Feb 2008 17:12:44 -0800

> Here is what I cooked up and it seems to work fine.
> It may be easier to review the code (against my earlier patches).

BTW, the lmb code now lives under lib/ (sparc64 will be using it too)
and has several bug fixes applied to it in Paulus's current upstream
tree.

^ permalink raw reply

* [PATCH 2/3] firewire: fw-ohci: Apple UniNorth 1st generation support
From: Stefan Richter @ 2008-03-01  1:47 UTC (permalink / raw)
  To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <tkrat.ac97915a5b51e35b@s5r6.in-berlin.de>

Mostly copied from ohci1394.c.  Necessary for some older Macs, e.g.
PowerBook G3 Pismo and early PowerBook G4 Titanium.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---

Since my TiBook has a broken FireWire PHY I was only able to test
the byte order of self ID packets but not of the headers of any
other packets.  The code in handle_ar_packet() is only guesswork
from ohci1394.c's respective code.  Also, I wonder what's up with
isochronous packets...

 drivers/firewire/fw-ohci.c |   29 +++++++++++++++++++++--------
 1 file changed, 21 insertions(+), 8 deletions(-)

Index: linux-2.6.25-rc3/drivers/firewire/fw-ohci.c
===================================================================
--- linux-2.6.25-rc3.orig/drivers/firewire/fw-ohci.c
+++ linux-2.6.25-rc3/drivers/firewire/fw-ohci.c
@@ -179,6 +179,7 @@ struct fw_ohci {
 	int generation;
 	int request_generation;
 	u32 bus_seconds;
+	bool old_uninorth;
 
 	/*
 	 * Spinlock for accessing fw_ohci data.  Never call out of
@@ -315,15 +316,22 @@ static int ar_context_add_page(struct ar
 	return 0;
 }
 
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_PPC32)
+#define cond_le32_to_cpu(v) \
+	(ohci->old_uninorth ? (__force __u32)(v) : le32_to_cpu(v))
+#else
+#define cond_le32_to_cpu(v) le32_to_cpu(v)
+#endif
+
 static __le32 *handle_ar_packet(struct ar_context *ctx, __le32 *buffer)
 {
 	struct fw_ohci *ohci = ctx->ohci;
 	struct fw_packet p;
 	u32 status, length, tcode;
 
-	p.header[0] = le32_to_cpu(buffer[0]);
-	p.header[1] = le32_to_cpu(buffer[1]);
-	p.header[2] = le32_to_cpu(buffer[2]);
+	p.header[0] = cond_le32_to_cpu(buffer[0]);
+	p.header[1] = cond_le32_to_cpu(buffer[1]);
+	p.header[2] = cond_le32_to_cpu(buffer[2]);
 
 	tcode = (p.header[0] >> 4) & 0x0f;
 	switch (tcode) {
@@ -335,7 +343,7 @@ static __le32 *handle_ar_packet(struct a
 		break;
 
 	case TCODE_READ_BLOCK_REQUEST :
-		p.header[3] = le32_to_cpu(buffer[3]);
+		p.header[3] = cond_le32_to_cpu(buffer[3]);
 		p.header_length = 16;
 		p.payload_length = 0;
 		break;
@@ -344,7 +352,7 @@ static __le32 *handle_ar_packet(struct a
 	case TCODE_READ_BLOCK_RESPONSE:
 	case TCODE_LOCK_REQUEST:
 	case TCODE_LOCK_RESPONSE:
-		p.header[3] = le32_to_cpu(buffer[3]);
+		p.header[3] = cond_le32_to_cpu(buffer[3]);
 		p.header_length = 16;
 		p.payload_length = p.header[3] >> 16;
 		break;
@@ -361,7 +369,7 @@ static __le32 *handle_ar_packet(struct a
 
 	/* FIXME: What to do about evt_* errors? */
 	length = (p.header_length + p.payload_length + 3) / 4;
-	status = le32_to_cpu(buffer[length]);
+	status = cond_le32_to_cpu(buffer[length]);
 
 	p.ack        = ((status >> 16) & 0x1f) - 16;
 	p.speed      = (status >> 21) & 0x7;
@@ -1026,13 +1034,14 @@ static void bus_reset_tasklet(unsigned l
 	 */
 
 	self_id_count = (reg_read(ohci, OHCI1394_SelfIDCount) >> 3) & 0x3ff;
-	generation = (le32_to_cpu(ohci->self_id_cpu[0]) >> 16) & 0xff;
+	generation = (cond_le32_to_cpu(ohci->self_id_cpu[0]) >> 16) & 0xff;
 	rmb();
 
 	for (i = 1, j = 0; j < self_id_count; i += 2, j++) {
 		if (ohci->self_id_cpu[i] != ~ohci->self_id_cpu[i + 1])
 			fw_error("inconsistent self IDs\n");
-		ohci->self_id_buffer[j] = le32_to_cpu(ohci->self_id_cpu[i]);
+		ohci->self_id_buffer[j] =
+				cond_le32_to_cpu(ohci->self_id_cpu[i]);
 	}
 	rmb();
 
@@ -2091,6 +2100,10 @@ pci_probe(struct pci_dev *dev, const str
 	pci_write_config_dword(dev, OHCI1394_PCI_HCI_Control, 0);
 	pci_set_drvdata(dev, ohci);
 
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_PPC32)
+	ohci->old_uninorth = dev->vendor == PCI_VENDOR_ID_APPLE &&
+			     dev->device == PCI_DEVICE_ID_APPLE_UNI_N_FW;
+#endif
 	spin_lock_init(&ohci->lock);
 
 	tasklet_init(&ohci->bus_reset_tasklet,

-- 
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/

^ permalink raw reply

* Re: Sequoia build with KDBG
From: Steve Heflin @ 2008-03-01  1:48 UTC (permalink / raw)
  To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20080301001632.BA47B2476B@gemini.denx.de>

At 07:16 PM 2/29/2008, Wolfgang Denk wrote:
>In message <20080229223046.1B332DDE0A@ozlabs.org> you wrote:
> >
> > I assumed that because I've always needed a debugger when
> > implementing kernel level components. Since you've implemented kernel
> > level support for several 44x processors, I just assumed that you
> > needed kdbg at some point. So you're saying that your additions
> > worked right out of the gate and you never needed a 
> debugger?  You're my hero!
>
>Many people working on this stuff use a BDI2000 / BDI3000. Makes life
>much easier...

Wolfgang, you hit the nail on the head. Trying to debug a target 
without a JTAG debugger is a pain.

^ 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