* Please pull powerpc.git 'master' branch
From: Paul Mackerras @ 2006-10-04 23:36 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
again, to get a Cell update. I apologize on Arnd's behalf for the
lateness of this update.
Thanks,
Paul.
arch/powerpc/configs/cell_defconfig | 60 +++
arch/powerpc/platforms/cell/Kconfig | 5
arch/powerpc/platforms/cell/interrupt.c | 10 -
arch/powerpc/platforms/cell/iommu.c | 8
arch/powerpc/platforms/cell/spider-pic.c | 6
arch/powerpc/platforms/cell/spu_base.c | 168 ++++++++--
arch/powerpc/platforms/cell/spufs/Makefile | 2
arch/powerpc/platforms/cell/spufs/context.c | 6
arch/powerpc/platforms/cell/spufs/file.c | 354 +++++++++++++++-----
arch/powerpc/platforms/cell/spufs/gang.c | 81 +++++
arch/powerpc/platforms/cell/spufs/inode.c | 232 +++++++++++--
arch/powerpc/platforms/cell/spufs/run.c | 48 ++-
arch/powerpc/platforms/cell/spufs/sched.c | 450 ++++++++++----------------
arch/powerpc/platforms/cell/spufs/spufs.h | 29 ++
arch/powerpc/platforms/cell/spufs/switch.c | 9 +
arch/powerpc/platforms/cell/spufs/syscalls.c | 9 -
include/asm-powerpc/spu.h | 36 ++
17 files changed, 1017 insertions(+), 496 deletions(-)
create mode 100644 arch/powerpc/platforms/cell/spufs/gang.c
Arnd Bergmann:
[POWERPC] spufs: implement error event delivery to user space
[POWERPC] spufs: Add infrastructure needed for gang scheduling
[POWERPC] spufs: use correct pg_prot for mapping SPU local store
[POWERPC] spufs: make mailbox functions handle multiple elements
[POWERPC] spufs: remove support for ancient firmware
[POWERPC] spufs: add support for read/write on cntl
[POWERPC] spufs: support new OF device tree format
[POWERPC] spufs: add infrastructure for finding elf objects
[POWERPC] Update cell_defconfig
[POWERPC] spiderpic: enable new style devtree support
[POWERPC] cell: fix bugs found by sparse
Benjamin Herrenschmidt:
[POWERPC] spufs: cell spu problem state mapping updates
HyeonSeung Jang:
[POWERPC] spufs: fix context switch during page fault
Mark Nutter:
[POWERPC] spufs: scheduler support for NUMA.
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Benjamin Herrenschmidt @ 2006-10-04 23:36 UTC (permalink / raw)
To: Dan Malek; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <7BD0D5CE-7BA3-43DC-B972-B75672F6A31E@embeddedalley.com>
On Wed, 2006-10-04 at 10:48 -0400, Dan Malek wrote:
> On Oct 4, 2006, at 2:08 AM, Benjamin Herrenschmidt wrote:
>
> > It's not that complex and the single binary is not necessarily the
> > main
> > objective (it's a good practice as it enforce avoiding ugly #ifdef
> > hacks
>
> Would you guys please get off of this #ifdefs discussion! :-)
> That's not what this is about.
But it _IS_ in large part ! #ifdefs are ugly and evil. So it's about
that and having a central repository for board specific informations
instead of hacks cluttered around 20 drivers....
> > There is fundamentally little difference between the OCP tables we had
> > before and the device-tree.
>
> Exactly! So why has it become such a desire to represent
> stuff in the device tree that was never necessary to represent
> in other table formats before?
For several reasons. One of them is the fact that the previous tables
were too limited, another is that we are converging using the same
mecanism for all platforms.
> > The new device-tree model provides a more flexible and richer semantic
> > for adding all sort of driver or BSP private infos, and for dealing
> > with
> > address mapping and interrupt mapping.
>
> Not really, we had all of this before..... and in a way
> that I didn't have to learn a new syntax to represent.
Ugh ? Look at the #ifdef mess in ibm_emac...
> > When done right, it does simplify the matter. An example that I've
> > seen
> > internally is embedded boards with all sorts of variety of dodgy
> > interrupt controllers cascaded on each other.
>
> Good example. Cascaded interrupt controllers are always
> a challenge. :-) It doesn't matter how you present the
> information about their configuration if you don't have
> the code written properly to manage them. It's the
> _code_ you write the solves the problem, not the
> device tree.
The device-tree allows the code to be much simpler. The -code- becomes
what it should be in the first place: purely a driver for each actual
chip with no need for much knowledge if the general layout. Layout
related (and in general board related) informations are in the
device-tree and the board setup file(s). It's cleaner and simpler.
> It doesn't really make it any simpler for the driver, because
> they have always retrieved that information in some way that
> has been consistent, usually from the old board descriptor
> or platform data.
No, it's never been consistent.
> The method of converting that information,
> usually a concern of the boot rom or the boot wrapper or
> compiled in, is what we are changing now.
We are changing the method to make it consistent. Providing the
information is still a concern of the boot rom or the wrapper.
> > There is a great flexibility of putting whatever you want in
> > there... or
> > not.
>
> It's the 'or not' part that I am worried about. Things like
> you mention above make sense. I'm starting to worry about
> some of this other stuff, and the bscr example is what
> woke me up :-) I think that's an example of things that
> should be considered not necessary.
I haven't looked at this specific example. I'll try to have a look
later. I jumped into the discussion pointed by somebody else :)
> > It's up to the embedded developper to use that tool, it can be used
> > in a bloated way, or in a smart way, we aren't enforcing any direction
> > here.
>
> Not really. To use a particular driver you are going to have
> to provide the proper amount of information. It's not up to
> me as a consumer of something already written. I can
> only control that if I'm the developer of the code.
Oh sure, existing drivers will require some amount of information, and
that's good. Better have it in that central place than having board
specific junk in every driver. However, you can use it to add your own
stuffs as well if you feel the need. And when I say used in a simple vs.
a bloated way, it's also up to the driver writer to not require too
much...
> > I think you are a bit too dismissive here. The approach has always
> > been
> > to provide the choice,
>
> There isn't a choice. If I want to use a particular driver
> I have to provide the proper and necessary information
> using a device tree, period. If I want to change my
> board design for some reason that is advantageous
> to me, and the driver doesn't support it, no possible
> convolution of device tree information is going to make
> that happen.
Then you fix the driver. We are not solving world hunger but we are at
least trying to improve our own food quality here.
> > ... is hopefully an easier way to create the BSP in the first place,
>
> Sorry, but I don't see that. You are either skilled at
> creating a BSP or you are not. The device tree just adds
> another dimension of information in a syntax and structure
> that you have to learn.
To re-use your own answer to one of my points, I'd say that's
bullshit :) It's easier to have a central place with well defined
bindings to express things like your interrupt routing, device layout
and addresses etc...
> > .... The -ability- to build multi-board
> > kernels is made mandatory for code to be merged upstream,
>
> Why? When are people going to realize that the
> ratio of Linux on custom embedded systems to a standard
> workstation is about a million to one?
And ?
> So what if I
> can boot the same kernel on a couple of obsolete
> PowerPC workstations using drivers that aren't used
> anywhere else? Or, on a couple of embedded eval
> boards that don't represent how people build products?
> Hell, I tried to build an x86 kernel the other day
> for a PC and still don't have one that boots. I can't
> seem to figure out what processor configuration
> options or compiler options to use. Linux doesn't
> even support this on a "standard" PC. :-)
That's what defconfigs are for.
> > ... as it enforces
> > a certain level of quality,
>
> That's BS and you know it :-)
No, it's not. Look at the inextricable mess arch/ppc is in. We are
trying hard to avoid that for arch/powerpc. If you let people just do
hacks with #ifdef's all over the place for every single board, you end
up with something mostly unmaintainable. Your point would be valid if
the linux kernel was a frozen thing that didn't evolve. However, it
evolves and needs to be actively devleopped/maintained. Having a sane
infrastructure to hook board support in makes it easier and cleaner.
Also, most of the code for embedded that actually gets merged upstream
is code for evaluation boards provided by chip vendors, not end-user
embedded code, you know very well that the actual embedded developpers
never submit anything upstream, they don't care. That means that what
gets merged upstream is what will be used as example code and base for
new board supports. Thus it's important that is has as much flexibility
as possible, including the ability to build kernels with multiple board
supports in a single image. Embedded customers are the end of the chain
might chose to not use that capability, but it shall be provided by the
base/example code in the upstream repository.
> > .... In fact, you client may be happy, once it's done rev 3 of the
> > board with a 3rd type of wifi chip or a 2nd type of ethernet HUB to
> > have
> > the ability to easily build, maintain, distribute and test a single
> > kernel image,
>
> That's not very important. For high volume products that
> are already in the field, the way the binary image is created
> or if they need different ones on different versions, isn't
> important. The whole process of tracking, testing, distributing,
> installing, upgrading, reverting makes our development
> tools insignificant to them. All that is desired is an image
> that when upgraded doesn't turn a million boxes into
> bricks. If it does, our cleverness to use a device tree to
> support multiple boards better not be the problem, because
> if it is it will never be used again.
That argument too is BS and you know it :)
Ben.
^ permalink raw reply
* [PATCH] Fix dtb inclusion in zImage and split OF stuff
From: Paul Mackerras @ 2006-10-04 23:57 UTC (permalink / raw)
To: mgreer, linuxppc-dev
This fixes the inclusion of device-tree blobs by the wrapper script,
and splits of.c into of.c and ofcall.c, where ofcall.c contains the
low-level interface to OF and of.c contains the platform definition
for OF-based machines. This patch forms part of the changes I have
been working on to get an IBM PReP machine booting with ARCH=powerpc.
Paul.
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index c383d56..6568e32 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -40,8 +40,8 @@ zliblinuxheader := zlib.h zconf.h zutil.
$(addprefix $(obj)/,$(zlib) main.o): $(addprefix $(obj)/,$(zliblinuxheader)) \
$(addprefix $(obj)/,$(zlibheader))
-src-wlib := string.S stdio.c main.c div64.S $(zlib)
-src-plat := of.c
+src-wlib := string.S stdio.c main.c ofcons.c ofcall.c div64.S $(zlib)
+src-plat := of.c prep.c
src-boot := crt0.S $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
diff --git a/arch/powerpc/boot/main.c b/arch/powerpc/boot/main.c
index d719bb9..3084fb0 100644
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@ -27,6 +27,8 @@ extern char _vmlinux_start[];
extern char _vmlinux_end[];
extern char _initrd_start[];
extern char _initrd_end[];
+extern char _dtb_start[];
+extern char _dtb_end[];
struct addr_range {
unsigned long addr;
@@ -285,12 +287,6 @@ static void set_cmdline(char *buf)
setprop(devp, "bootargs", buf, strlen(buf) + 1);
}
-/* Section where ft can be tacked on after zImage is built */
-union blobspace {
- struct boot_param_header hdr;
- char space[8*1024];
-} dt_blob __attribute__((__section__("__builtin_ft")));
-
struct platform_ops platform_ops;
struct dt_ops dt_ops;
struct console_ops console_ops;
@@ -309,9 +305,9 @@ void start(unsigned long a1, unsigned lo
/* Override the dt_ops and device tree if there was an flat dev
* tree attached to the zImage.
*/
- if (dt_blob.hdr.magic == OF_DT_HEADER) {
+ if (_dtb_end > _dtb_start) {
have_dt = 1;
- ft_init(&dt_blob);
+ ft_init(_dtb_start);
}
if (platform_init(promptr))
diff --git a/arch/powerpc/boot/of.c b/arch/powerpc/boot/of.c
index fd99f78..2541339 100644
--- a/arch/powerpc/boot/of.c
+++ b/arch/powerpc/boot/of.c
@@ -14,165 +14,17 @@ #include "string.h"
#include "stdio.h"
#include "page.h"
#include "ops.h"
-
-typedef void *ihandle;
-typedef void *phandle;
+#include "of.h"
extern char _end[];
+static unsigned long claim_base;
+
/* Value picked to match that used by yaboot */
#define PROG_START 0x01400000 /* only used on 64-bit systems */
#define RAM_END (512<<20) /* Fixme: use OF */
#define ONE_MB 0x100000
-int (*prom) (void *);
-
-
-static unsigned long claim_base;
-
-static int call_prom(const char *service, int nargs, int nret, ...)
-{
- int i;
- struct prom_args {
- const char *service;
- int nargs;
- int nret;
- unsigned int args[12];
- } args;
- va_list list;
-
- args.service = service;
- args.nargs = nargs;
- args.nret = nret;
-
- va_start(list, nret);
- for (i = 0; i < nargs; i++)
- args.args[i] = va_arg(list, unsigned int);
- va_end(list);
-
- for (i = 0; i < nret; i++)
- args.args[nargs+i] = 0;
-
- if (prom(&args) < 0)
- return -1;
-
- return (nret > 0)? args.args[nargs]: 0;
-}
-
-static int call_prom_ret(const char *service, int nargs, int nret,
- unsigned int *rets, ...)
-{
- int i;
- struct prom_args {
- const char *service;
- int nargs;
- int nret;
- unsigned int args[12];
- } args;
- va_list list;
-
- args.service = service;
- args.nargs = nargs;
- args.nret = nret;
-
- va_start(list, rets);
- for (i = 0; i < nargs; i++)
- args.args[i] = va_arg(list, unsigned int);
- va_end(list);
-
- for (i = 0; i < nret; i++)
- args.args[nargs+i] = 0;
-
- if (prom(&args) < 0)
- return -1;
-
- if (rets != (void *) 0)
- for (i = 1; i < nret; ++i)
- rets[i-1] = args.args[nargs+i];
-
- return (nret > 0)? args.args[nargs]: 0;
-}
-
-/*
- * Older OF's require that when claiming a specific range of addresses,
- * we claim the physical space in the /memory node and the virtual
- * space in the chosen mmu node, and then do a map operation to
- * map virtual to physical.
- */
-static int need_map = -1;
-static ihandle chosen_mmu;
-static phandle memory;
-
-/* returns true if s2 is a prefix of s1 */
-static int string_match(const char *s1, const char *s2)
-{
- for (; *s2; ++s2)
- if (*s1++ != *s2)
- return 0;
- return 1;
-}
-
-static int check_of_version(void)
-{
- phandle oprom, chosen;
- char version[64];
-
- oprom = finddevice("/openprom");
- if (oprom == (phandle) -1)
- return 0;
- if (getprop(oprom, "model", version, sizeof(version)) <= 0)
- return 0;
- version[sizeof(version)-1] = 0;
- printf("OF version = '%s'\r\n", version);
- if (!string_match(version, "Open Firmware, 1.")
- && !string_match(version, "FirmWorks,3."))
- return 0;
- chosen = finddevice("/chosen");
- if (chosen == (phandle) -1) {
- chosen = finddevice("/chosen@0");
- if (chosen == (phandle) -1) {
- printf("no chosen\n");
- return 0;
- }
- }
- if (getprop(chosen, "mmu", &chosen_mmu, sizeof(chosen_mmu)) <= 0) {
- printf("no mmu\n");
- return 0;
- }
- memory = (ihandle) call_prom("open", 1, 1, "/memory");
- if (memory == (ihandle) -1) {
- memory = (ihandle) call_prom("open", 1, 1, "/memory@0");
- if (memory == (ihandle) -1) {
- printf("no memory node\n");
- return 0;
- }
- }
- printf("old OF detected\r\n");
- return 1;
-}
-
-static void *claim(unsigned long virt, unsigned long size, unsigned long align)
-{
- int ret;
- unsigned int result;
-
- if (need_map < 0)
- need_map = check_of_version();
- if (align || !need_map)
- return (void *) call_prom("claim", 3, 1, virt, size, align);
-
- ret = call_prom_ret("call-method", 5, 2, &result, "claim", memory,
- align, size, virt);
- if (ret != 0 || result == -1)
- return (void *) -1;
- ret = call_prom_ret("call-method", 5, 2, &result, "claim", chosen_mmu,
- align, size, virt);
- /* 0x12 == coherent + read/write */
- ret = call_prom("call-method", 6, 1, "map", chosen_mmu,
- 0x12, size, virt, virt);
- return (void *) virt;
-}
-
static void *of_try_claim(u32 size)
{
unsigned long addr = 0;
@@ -187,7 +39,7 @@ static void *of_try_claim(u32 size)
#ifdef DEBUG
printf(" trying: 0x%08lx\n\r", claim_base);
#endif
- addr = (unsigned long)claim(claim_base, size, 0);
+ addr = (unsigned long)of_claim(claim_base, size, 0);
if ((void *)addr != (void *)-1)
break;
}
@@ -211,73 +63,18 @@ static void of_image_hdr(const void *hdr
}
}
-static void of_exit(void)
-{
- call_prom("exit", 0, 0);
-}
-
-/*
- * OF device tree routines
- */
-static void *of_finddevice(const char *name)
-{
- return (phandle) call_prom("finddevice", 1, 1, name);
-}
-
-static int of_getprop(const void *phandle, const char *name, void *buf,
- const int buflen)
-{
- return call_prom("getprop", 4, 1, phandle, name, buf, buflen);
-}
-
-static int of_setprop(const void *phandle, const char *name, const void *buf,
- const int buflen)
-{
- return call_prom("setprop", 4, 1, phandle, name, buf, buflen);
-}
-
-/*
- * OF console routines
- */
-static void *of_stdout_handle;
-
-static int of_console_open(void)
-{
- void *devp;
-
- if (((devp = finddevice("/chosen")) != NULL)
- && (getprop(devp, "stdout", &of_stdout_handle,
- sizeof(of_stdout_handle))
- == sizeof(of_stdout_handle)))
- return 0;
-
- return -1;
-}
-
-static void of_console_write(char *buf, int len)
-{
- call_prom("write", 3, 1, of_stdout_handle, buf, len);
-}
-
int platform_init(void *promptr)
{
+ of_init(promptr);
+
platform_ops.fixups = NULL;
platform_ops.image_hdr = of_image_hdr;
platform_ops.malloc = of_try_claim;
platform_ops.free = NULL;
platform_ops.exit = of_exit;
- dt_ops.finddevice = of_finddevice;
- dt_ops.getprop = of_getprop;
- dt_ops.setprop = of_setprop;
- dt_ops.translate_addr = NULL;
-
- console_ops.open = of_console_open;
- console_ops.write = of_console_write;
- console_ops.edit_cmdline = NULL;
- console_ops.close = NULL;
- console_ops.data = NULL;
+ of_tree_init();
+ of_console_init();
- prom = (int (*)(void *))promptr;
return 0;
}
diff --git a/arch/powerpc/boot/of.h b/arch/powerpc/boot/of.h
new file mode 100644
index 0000000..0828643
--- /dev/null
+++ b/arch/powerpc/boot/of.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) Paul Mackerras 1997.
+ *
+ * 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.
+ */
+
+typedef void *ihandle;
+typedef void *phandle;
+
+/* In ofcall.c */
+void of_init(void *promptr);
+int call_prom(const char *service, int nargs, int nret, ...);
+int call_prom_ret(const char *service, int nargs, int nret,
+ unsigned int *rets, ...);
+void *of_claim(unsigned long virt, unsigned long size, unsigned long align);
+void of_exit(void);
+
+void *of_finddevice(const char *name);
+int of_getprop(const void *phandle, const char *name, void *buf,
+ const int buflen);
+int of_setprop(const void *phandle, const char *name, const void *buf,
+ const int buflen);
+void of_tree_init(void);
+
+/* In ofcons.c */
+void of_console_init(void);
diff --git a/arch/powerpc/boot/ofcall.c b/arch/powerpc/boot/ofcall.c
new file mode 100644
index 0000000..8086b60
--- /dev/null
+++ b/arch/powerpc/boot/ofcall.c
@@ -0,0 +1,200 @@
+/*
+ * Copyright (C) Paul Mackerras 1997.
+ *
+ * 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 <stdarg.h>
+#include <stddef.h>
+#include "types.h"
+#include "string.h"
+#include "stdio.h"
+#include "page.h"
+#include "ops.h"
+#include "of.h"
+
+int (*prom) (void *);
+
+
+void of_init(void *promptr)
+{
+ prom = (int (*)(void *))promptr;
+}
+
+int call_prom(const char *service, int nargs, int nret, ...)
+{
+ int i;
+ struct prom_args {
+ const char *service;
+ int nargs;
+ int nret;
+ unsigned int args[12];
+ } args;
+ va_list list;
+
+ args.service = service;
+ args.nargs = nargs;
+ args.nret = nret;
+
+ va_start(list, nret);
+ for (i = 0; i < nargs; i++)
+ args.args[i] = va_arg(list, unsigned int);
+ va_end(list);
+
+ for (i = 0; i < nret; i++)
+ args.args[nargs+i] = 0;
+
+ if (prom(&args) < 0)
+ return -1;
+
+ return (nret > 0)? args.args[nargs]: 0;
+}
+
+int call_prom_ret(const char *service, int nargs, int nret,
+ unsigned int *rets, ...)
+{
+ int i;
+ struct prom_args {
+ const char *service;
+ int nargs;
+ int nret;
+ unsigned int args[12];
+ } args;
+ va_list list;
+
+ args.service = service;
+ args.nargs = nargs;
+ args.nret = nret;
+
+ va_start(list, rets);
+ for (i = 0; i < nargs; i++)
+ args.args[i] = va_arg(list, unsigned int);
+ va_end(list);
+
+ for (i = 0; i < nret; i++)
+ args.args[nargs+i] = 0;
+
+ if (prom(&args) < 0)
+ return -1;
+
+ if (rets != (void *) 0)
+ for (i = 1; i < nret; ++i)
+ rets[i-1] = args.args[nargs+i];
+
+ return (nret > 0)? args.args[nargs]: 0;
+}
+
+/*
+ * Older OF's require that when claiming a specific range of addresses,
+ * we claim the physical space in the /memory node and the virtual
+ * space in the chosen mmu node, and then do a map operation to
+ * map virtual to physical.
+ */
+static int need_map = -1;
+static ihandle chosen_mmu;
+static phandle memory;
+
+/* returns true if s2 is a prefix of s1 */
+static int string_match(const char *s1, const char *s2)
+{
+ for (; *s2; ++s2)
+ if (*s1++ != *s2)
+ return 0;
+ return 1;
+}
+
+static int check_of_version(void)
+{
+ phandle oprom, chosen;
+ char version[64];
+
+ oprom = finddevice("/openprom");
+ if (oprom == (phandle) -1)
+ return 0;
+ if (getprop(oprom, "model", version, sizeof(version)) <= 0)
+ return 0;
+ version[sizeof(version)-1] = 0;
+ printf("OF version = '%s'\r\n", version);
+ if (!string_match(version, "Open Firmware, 1.")
+ && !string_match(version, "FirmWorks,3."))
+ return 0;
+ chosen = finddevice("/chosen");
+ if (chosen == (phandle) -1) {
+ chosen = finddevice("/chosen@0");
+ if (chosen == (phandle) -1) {
+ printf("no chosen\n");
+ return 0;
+ }
+ }
+ if (getprop(chosen, "mmu", &chosen_mmu, sizeof(chosen_mmu)) <= 0) {
+ printf("no mmu\n");
+ return 0;
+ }
+ memory = (ihandle) call_prom("open", 1, 1, "/memory");
+ if (memory == (ihandle) -1) {
+ memory = (ihandle) call_prom("open", 1, 1, "/memory@0");
+ if (memory == (ihandle) -1) {
+ printf("no memory node\n");
+ return 0;
+ }
+ }
+ printf("old OF detected\r\n");
+ return 1;
+}
+
+void *of_claim(unsigned long virt, unsigned long size, unsigned long align)
+{
+ int ret;
+ unsigned int result;
+
+ if (need_map < 0)
+ need_map = check_of_version();
+ if (align || !need_map)
+ return (void *) call_prom("claim", 3, 1, virt, size, align);
+
+ ret = call_prom_ret("call-method", 5, 2, &result, "claim", memory,
+ align, size, virt);
+ if (ret != 0 || result == -1)
+ return (void *) -1;
+ ret = call_prom_ret("call-method", 5, 2, &result, "claim", chosen_mmu,
+ align, size, virt);
+ /* 0x12 == coherent + read/write */
+ ret = call_prom("call-method", 6, 1, "map", chosen_mmu,
+ 0x12, size, virt, virt);
+ return (void *) virt;
+}
+
+void of_exit(void)
+{
+ call_prom("exit", 0, 0);
+}
+
+/*
+ * OF device tree routines
+ */
+void *of_finddevice(const char *name)
+{
+ return (phandle) call_prom("finddevice", 1, 1, name);
+}
+
+int of_getprop(const void *phandle, const char *name, void *buf,
+ const int buflen)
+{
+ return call_prom("getprop", 4, 1, phandle, name, buf, buflen);
+}
+
+int of_setprop(const void *phandle, const char *name, const void *buf,
+ const int buflen)
+{
+ return call_prom("setprop", 4, 1, phandle, name, buf, buflen);
+}
+
+void of_tree_init(void)
+{
+ dt_ops.finddevice = of_finddevice;
+ dt_ops.getprop = of_getprop;
+ dt_ops.setprop = of_setprop;
+ dt_ops.translate_addr = NULL;
+}
diff --git a/arch/powerpc/boot/ofcons.c b/arch/powerpc/boot/ofcons.c
new file mode 100644
index 0000000..5c76734
--- /dev/null
+++ b/arch/powerpc/boot/ofcons.c
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) Paul Mackerras 1997.
+ *
+ * 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 <stdarg.h>
+#include <stddef.h>
+#include "types.h"
+#include "elf.h"
+#include "string.h"
+#include "stdio.h"
+#include "page.h"
+#include "ops.h"
+#include "of.h"
+
+/*
+ * OF console routines
+ */
+static void *of_stdout_handle;
+
+static int of_console_open(void)
+{
+ void *devp;
+
+ if (((devp = of_finddevice("/chosen")) != NULL)
+ && (of_getprop(devp, "stdout", &of_stdout_handle,
+ sizeof(of_stdout_handle))
+ == sizeof(of_stdout_handle)))
+ return 0;
+
+ return -1;
+}
+
+static void of_console_write(char *buf, int len)
+{
+ call_prom("write", 3, 1, of_stdout_handle, buf, len);
+}
+
+void of_console_init(void)
+{
+ console_ops.open = of_console_open;
+ console_ops.write = of_console_write;
+ console_ops.edit_cmdline = NULL;
+ console_ops.close = NULL;
+ console_ops.data = NULL;
+
+}
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index eab7318..debb02b 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -179,11 +179,11 @@ if [ -z "$cacheit" ]; then
fi
if [ -n "$initrd" ]; then
- addsec $tmp "$initrd" initrd
+ addsec $tmp "$initrd" $isection
fi
if [ -n "$dtb" ]; then
- addsec $tmp "$dtb" dtb
+ addsec $tmp "$dtb" .kernel:dtb
fi
if [ "$platform" != "miboot" ]; then
diff --git a/arch/powerpc/boot/zImage.lds.S b/arch/powerpc/boot/zImage.lds.S
index 4b6bb3f..4be3c64 100644
--- a/arch/powerpc/boot/zImage.lds.S
+++ b/arch/powerpc/boot/zImage.lds.S
@@ -21,6 +21,11 @@ SECTIONS
__got2_end = .;
}
+ . = ALIGN(8);
+ _dtb_start = .;
+ .kernel:dtb : { *(.kernel:dtb) }
+ _dtb_end = .;
+
. = ALIGN(4096);
_vmlinux_start = .;
.kernel:vmlinux.strip : { *(.kernel:vmlinux.strip) }
^ permalink raw reply related
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Paul Mackerras @ 2006-10-05 0:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <1160005019.5887.30.camel@localhost.localdomain>
Benjamin Herrenschmidt writes:
> > It's the 'or not' part that I am worried about. Things like
> > you mention above make sense. I'm starting to worry about
> > some of this other stuff, and the bscr example is what
> > woke me up :-) I think that's an example of things that
> > should be considered not necessary.
>
> I haven't looked at this specific example. I'll try to have a look
> later. I jumped into the discussion pointed by somebody else :)
That one was interesting - the bcsr was being referenced from an
ethernet driver that looked to me like it would be useful on any board
based on an 836x chip (I think). Yet it was claimed that the bcsr was
so specific and unique to each board that there was no point putting
it in the device tree - which implies that we would have to have a
separate lump of code in the tree to drive it for every single
board. :P I asked why the ethernet driver was accessing it directly
if that was the case, but didn't get an answer (well, only an indirect
answer in that the bcsr access code got removed from the ethernet
driver).
Paul.
^ permalink raw reply
* Re: [PATCH 1/4]: Spidernet stop queue when queue is full
From: Linas Vepstas @ 2006-10-05 0:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: akpm, jeff, netdev, James K Lewis, linux-kernel, linuxppc-dev
In-Reply-To: <200610040019.43028.arnd@arndb.de>
On Wed, Oct 04, 2006 at 12:19:42AM +0200, Arnd Bergmann wrote:
> On Tuesday 03 October 2006 22:57, Linas Vepstas wrote:
> > result = NETDEV_TX_LOCKED;
>
> Hmm, this looks a little strange to me.
Right. This was left-over cruft from back when.
I'll fix this and resend the whole series tommorrow or friday,
I've got a few more minor performnace tweaks, an implementation
of NETIF_F_SG, and another fix or two, etc.
--linas
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Benjamin Herrenschmidt @ 2006-10-05 0:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <17700.19414.724178.711359@cargo.ozlabs.ibm.com>
On Thu, 2006-10-05 at 10:03 +1000, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > > It's the 'or not' part that I am worried about. Things like
> > > you mention above make sense. I'm starting to worry about
> > > some of this other stuff, and the bscr example is what
> > > woke me up :-) I think that's an example of things that
> > > should be considered not necessary.
> >
> > I haven't looked at this specific example. I'll try to have a look
> > later. I jumped into the discussion pointed by somebody else :)
>
> That one was interesting - the bcsr was being referenced from an
> ethernet driver that looked to me like it would be useful on any board
> based on an 836x chip (I think). Yet it was claimed that the bcsr was
> so specific and unique to each board that there was no point putting
> it in the device tree - which implies that we would have to have a
> separate lump of code in the tree to drive it for every single
> board. :P I asked why the ethernet driver was accessing it directly
> if that was the case, but didn't get an answer (well, only an indirect
> answer in that the bcsr access code got removed from the ethernet
> driver).
Well, feature calls might be the answer there... at least to move the
problem out of the driver to the platform code. They are after all just
a way to do random calls into the BSP from drivers, though they have
some issues too (you gotta hope you are running the right platform code
that understands your calls, in which case, why not just call an
exported function ...)
Ben.
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Vitaly Bordug @ 2006-10-05 0:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <17700.19414.724178.711359@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]
On Thu, 5 Oct 2006 10:03:34 +1000
Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > > It's the 'or not' part that I am worried about. Things like
> > > you mention above make sense. I'm starting to worry about
> > > some of this other stuff, and the bscr example is what
> > > woke me up :-) I think that's an example of things that
> > > should be considered not necessary.
> >
> > I haven't looked at this specific example. I'll try to have a look
> > later. I jumped into the discussion pointed by somebody else :)
>
> That one was interesting - the bcsr was being referenced from an
> ethernet driver that looked to me like it would be useful on any board
> based on an 836x chip (I think). Yet it was claimed that the bcsr was
> so specific and unique to each board that there was no point putting
> it in the device tree - which implies that we would have to have a
> separate lump of code in the tree to drive it for every single
> board. :P I asked why the ethernet driver was accessing it directly
> if that was the case, but didn't get an answer (well, only an indirect
> answer in that the bcsr access code got removed from the ethernet
> driver).
>
Well that's because accessing bcsr in generic code is just odd. Yes, there are some places with
such a stuff still. bcsr is something like a sw jumper to enable/disable stuff, configure things, etc.
which may vary up to the hw design even if it's following the reference closely.
It's unique across the boards, and should be touched in BSP code only to keep the base sane.
Such a thing in the eth driver directly was sort of "nice" because takes care of enabling network "physically"
on board. For the same aim, I used to have board-specific callback to set up some bits if needed(speaking about
fs_enet/ppc). IOW, upon network driver init, it triggers callback function (passed in there via platform data) that's intended to do the bsp setup (or may be unset if nothing needed). In powerpc, only sane solution seems to be Dan's proposed
feature_call thing. I wish I'd have some time for that ...
Thanks,
-Vitaly
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Paul Mackerras @ 2006-10-05 0:27 UTC (permalink / raw)
To: Dan Malek; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <2867EA41-5135-43F7-9873-044C617EAC1B@embeddedalley.com>
Dan Malek writes:
> I'm not against using the device tree (or platform data
> or #defines) when it's appropriate to do so. I think our
> obsession to represent everything there is what is
> creating the complexity. If a #define in a board
> specific port file makes sense, then just do that,
> even if it is a BSCR address.
So, where this discussion started was that I saw an ioremap in an
ethernet driver using a physical address defined with #define, and I
said "that should go in the device tree". And I would still say that
if the ioremap was still there, since the driver is one that is useful
across a range of boards and chips.
My other point would be that what you say is valid *until* the
hardware engineers come to you and say "we're doing rev 2 of the
board, and we had to move the BCSR a bit. That's OK with you, isn't
it?".
If you have the BCSR address in the device tree, you don't even need
to recompile your kernel. You can just copy your board.dts to
board-rev2.dts, change the address in there, and rerun the wrapper
script to create the flash image to put on the new board. Or if you
are using a bootloader that knows how to supply a device-tree blob,
you just put board-rev2.dtb into flash along with your existing kernel
image.
Paul.
^ permalink raw reply
* Re: [PATCH] uninorth: Add module param 'aperture' for aperture size
From: Benjamin Herrenschmidt @ 2006-10-05 1:09 UTC (permalink / raw)
To: Michel Dänzer; +Cc: Dave Jones, linuxppc-dev
In-Reply-To: <1159966604.23084.236.camel@thor.lorrainebruecke.local>
On Wed, 2006-10-04 at 14:56 +0200, Michel Dänzer wrote:
> In contrast to most if not all PC BIOSes, OpenFirmware (OF) on PowerMacs with
> UniNorth bridges does not allow changing the aperture size. The size set up by
> OF is usually 16 MB, which is too low for graphics intensive environments.
> Hence, add a module parameter that allows changing the aperture size at driver
> initialization time. When the parameter is not specified, the default is 32 MB.
>
> Signed-off-by: Michel Dänzer <michel@tungstengraphics.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(it should probably go in 2.6.19, patch has been around for some time)
> ---
>
> Reversed a 'value == variable' test, as suggested by Andreas Schwab (thanks!).
>
> drivers/char/agp/uninorth-agp.c | 54 +++++++++++++++++++++++++--------------
> 1 files changed, 35 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
> index 78c8cb2..c2b6f7d 100644
> --- a/drivers/char/agp/uninorth-agp.c
> +++ b/drivers/char/agp/uninorth-agp.c
> @@ -27,32 +27,42 @@ #include "agp.h"
> static int uninorth_rev;
> static int is_u3;
>
> +static char __devinitdata *aperture = NULL;
>
> static int uninorth_fetch_size(void)
> {
> - int i;
> - u32 temp;
> - struct aper_size_info_32 *values;
> -
> - pci_read_config_dword(agp_bridge->dev, UNI_N_CFG_GART_BASE, &temp);
> - temp &= ~(0xfffff000);
> - values = A_SIZE_32(agp_bridge->driver->aperture_sizes);
> -
> - for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++) {
> - if (temp == values[i].size_value) {
> - agp_bridge->previous_size =
> - agp_bridge->current_size = (void *) (values + i);
> - agp_bridge->aperture_size_idx = i;
> - return values[i].size;
> + int i, size = 0;
> + struct aper_size_info_32 *values =
> + A_SIZE_32(agp_bridge->driver->aperture_sizes);
> +
> + if (aperture) {
> + char *save = aperture;
> +
> + size = memparse(aperture, &aperture) >> 20;
> + aperture = save;
> +
> + for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++)
> + if (size == values[i].size)
> + break;
> +
> + if (i == agp_bridge->driver->num_aperture_sizes) {
> + printk(KERN_ERR PFX "Invalid aperture size, using"
> + " default\n");
> + size = 0;
> + aperture = NULL;
> }
> }
>
> - agp_bridge->previous_size =
> - agp_bridge->current_size = (void *) (values + 1);
> - agp_bridge->aperture_size_idx = 1;
> - return values[1].size;
> + if (!size) {
> + for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++)
> + if (values[i].size == 32)
> + break;
> + }
>
> - return 0;
> + agp_bridge->previous_size =
> + agp_bridge->current_size = (void *)(values + i);
> + agp_bridge->aperture_size_idx = i;
> + return values[i].size;
> }
>
> static void uninorth_tlbflush(struct agp_memory *mem)
> @@ -668,5 +678,11 @@ static void __exit agp_uninorth_cleanup(
> module_init(agp_uninorth_init);
> module_exit(agp_uninorth_cleanup);
>
> +module_param(aperture, charp, 0);
> +MODULE_PARM_DESC(aperture,
> + "Aperture size, must be power of two between 4MB and an\n"
> + "\t\tupper limit specific to the UniNorth revision.\n"
> + "\t\tDefault: 32M");
> +
> MODULE_AUTHOR("Ben Herrenschmidt & Paul Mackerras");
> MODULE_LICENSE("GPL");
> --
> 1.4.2.1
>
>
> --
> Earthling Michel Dänzer | http://tungstengraphics.com
> Libre software enthusiast | Debian, X and DRI developer
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] linux,tce-size property is 32 bits
From: Nathan Lynch @ 2006-10-05 3:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, matthltc
The "linux,tce-size" property is only 32 bits (see
prom_initialize_tce_table() in arch/powerpc/kernel/prom_init.c).
Treating it as an unsigned long in iommu_table_setparms() leads to
access beyond the end of the property's buffer, so we pass garbage to
the memset() in that function.
[boot]0020 XICS Init
i8259 legacy interrupt controller initialized
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
cpu 0x0: Vector: 300 (Data Access) at [c0000000fe783850]
pc: c000000000035e90: .memset+0x60/0xfc
lr: c000000000044fa4: .iommu_table_setparms+0xb0/0x158
sp: c0000000fe783ad0
msr: 9000000000009032
dar: c000000100000000
dsisr: 42010000
current = 0xc00000000450e810
paca = 0xc000000000411580
pid = 1, comm = swapper
enter ? for help
[link register ] c000000000044fa4 .iommu_table_setparms+0xb0/0x158
[c0000000fe783ad0] c000000000044f4c .iommu_table_setparms+0x58/0x158
(unreliable)
[c0000000fe783b70] c00000000004529c
.iommu_bus_setup_pSeries+0x1c4/0x254
[c0000000fe783c00] c00000000002b8ac .do_bus_setup+0x3c/0xe4
[c0000000fe783c80] c00000000002c924 .pcibios_fixup_bus+0x64/0xd8
[c0000000fe783d00] c0000000001a2d5c .pci_scan_child_bus+0x6c/0x10c
[c0000000fe783da0] c00000000002be28 .scan_phb+0x17c/0x1b4
[c0000000fe783e40] c0000000003cfa00 .pcibios_init+0x58/0x19c
[c0000000fe783ec0] c0000000000094b4 .init+0x1e8/0x3d8
[c0000000fe783f90] c000000000026e54 .kernel_thread+0x4c/0x68
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
I believe this is a regression since 2.6.18, so please push for
inclusion in 2.6.19.
--- linux-2.6.git.orig/arch/powerpc/platforms/pseries/iommu.c
+++ linux-2.6.git/arch/powerpc/platforms/pseries/iommu.c
@@ -267,7 +267,8 @@ static void iommu_table_setparms(struct
struct iommu_table *tbl)
{
struct device_node *node;
- const unsigned long *basep, *sizep;
+ const unsigned long *basep;
+ const u32 *sizep;
node = (struct device_node *)phb->arch_data;
^ permalink raw reply
* [PATCH] powerpc: Fix zImage decompress location
From: Benjamin Herrenschmidt @ 2006-10-05 4:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
The zImage wrapper has a "hack" that force the decompression to happen
above 20Mb for 64 bits kernels, to work around issues with some
firmwares on the field. However, the new wrapper has a bug which makes
that hack not work properly. This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/boot/of.c
===================================================================
--- linux-work.orig/arch/powerpc/boot/of.c 2006-10-03 12:41:02.000000000 +1000
+++ linux-work/arch/powerpc/boot/of.c 2006-10-05 13:52:29.000000000 +1000
@@ -176,12 +176,9 @@ static void *claim(unsigned long virt, u
static void *of_try_claim(u32 size)
{
unsigned long addr = 0;
- static u8 first_time = 1;
- if (first_time) {
+ if (claim_base == 0)
claim_base = _ALIGN_UP((unsigned long)_end, ONE_MB);
- first_time = 0;
- }
for(; claim_base < RAM_END; claim_base += ONE_MB) {
#ifdef DEBUG
^ permalink raw reply
* [PATCH] powerpc: Enable DEEPNAP power savings mode on 970MP
From: Olof Johansson @ 2006-10-05 4:41 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel
Hi,
Without this patch, on an idle system I get:
cpu-power-0:21.638
cpu-power-1:27.102
cpu-power-2:29.343
cpu-power-3:25.784
Total: 103.8W
With this patch:
cpu-power-0:11.730
cpu-power-1:17.185
cpu-power-2:18.547
cpu-power-3:17.528
Total: 65.0W
If I lower HZ to 100, I can get it as low as:
cpu-power-0:10.938
cpu-power-1:16.021
cpu-power-2:17.245
cpu-power-3:16.145
Total: 60.2W
Another (older) Quad G5 went from 54W to 39W at HZ=250.
Coming back out of Deep Nap takes 40-70 cycles longer than coming back
from just Nap (which already takes quite a while). I don't think it'll
be a performance issue (interrupt latency on an idle system), but in
case someone does measurements feel free to report them.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: linux-2.6/arch/powerpc/kernel/cpu_setup_ppc970.S
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/cpu_setup_ppc970.S
+++ linux-2.6/arch/powerpc/kernel/cpu_setup_ppc970.S
@@ -83,6 +83,22 @@ _GLOBAL(__setup_cpu_ppc970)
rldimi r0,r11,52,8 /* set NAP and DPM */
li r11,0
rldimi r0,r11,32,31 /* clear EN_ATTN */
+ b load_hids /* Jump to shared code */
+
+
+_GLOBAL(__setup_cpu_ppc970MP)
+ /* Do nothing if not running in HV mode */
+ mfmsr r0
+ rldicl. r0,r0,4,63
+ beqlr
+
+ mfspr r0,SPRN_HID0
+ li r11,0x15 /* clear DOZE and SLEEP */
+ rldimi r0,r11,52,6 /* set DEEPNAP, NAP and DPM */
+ li r11,0
+ rldimi r0,r11,32,31 /* clear EN_ATTN */
+
+load_hids:
mtspr SPRN_HID0,r0
mfspr r0,SPRN_HID0
mfspr r0,SPRN_HID0
Index: linux-2.6/arch/powerpc/kernel/cputable.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/cputable.c
+++ linux-2.6/arch/powerpc/kernel/cputable.c
@@ -41,6 +41,7 @@ extern void __setup_cpu_745x(unsigned lo
#endif /* CONFIG_PPC32 */
#ifdef CONFIG_PPC64
extern void __setup_cpu_ppc970(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_ppc970MP(unsigned long offset, struct cpu_spec* spec);
extern void __restore_cpu_ppc970(void);
#endif /* CONFIG_PPC64 */
@@ -221,7 +222,7 @@ struct cpu_spec cpu_specs[] = {
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_ppc970,
+ .cpu_setup = __setup_cpu_ppc970MP,
.cpu_restore = __restore_cpu_ppc970,
.oprofile_cpu_type = "ppc64/970",
.oprofile_type = PPC_OPROFILE_POWER4,
^ permalink raw reply
* [PATCH] powerpc: make U4 PCIe work
From: Benjamin Herrenschmidt @ 2006-10-05 4:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
The Maple support code was missing code for U4/CPC945 PCIe. This adds
it, enabling it to work on tigerwood boards, and possibly also js21
using SLOF.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Patch just missed the merge window but should go in anyway. It's been
hanging around for a while, I just forgot about it, and it's fairly
harmless.
Index: linux-work/arch/powerpc/platforms/maple/pci.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/maple/pci.c 2006-10-05 14:14:28.000000000 +1000
+++ linux-work/arch/powerpc/platforms/maple/pci.c 2006-10-05 14:29:30.000000000 +1000
@@ -8,7 +8,7 @@
* 2 of the License, or (at your option) any later version.
*/
-#define DEBUG
+#undef DEBUG
#include <linux/kernel.h>
#include <linux/pci.h>
@@ -16,6 +16,7 @@
#include <linux/string.h>
#include <linux/init.h>
#include <linux/bootmem.h>
+#include <linux/irq.h>
#include <asm/sections.h>
#include <asm/io.h>
@@ -33,7 +34,7 @@
#define DBG(x...)
#endif
-static struct pci_controller *u3_agp, *u3_ht;
+static struct pci_controller *u3_agp, *u3_ht, *u4_pcie;
static int __init fixup_one_level_bus_range(struct device_node *node, int higher)
{
@@ -287,6 +288,110 @@ static struct pci_ops u3_ht_pci_ops =
u3_ht_write_config
};
+#define U4_PCIE_CFA0(devfn, off) \
+ ((1 << ((unsigned int)PCI_SLOT(dev_fn))) \
+ | (((unsigned int)PCI_FUNC(dev_fn)) << 8) \
+ | ((((unsigned int)(off)) >> 8) << 28) \
+ | (((unsigned int)(off)) & 0xfcU))
+
+#define U4_PCIE_CFA1(bus, devfn, off) \
+ ((((unsigned int)(bus)) << 16) \
+ |(((unsigned int)(devfn)) << 8) \
+ | ((((unsigned int)(off)) >> 8) << 28) \
+ |(((unsigned int)(off)) & 0xfcU) \
+ |1UL)
+
+static volatile void __iomem *u4_pcie_cfg_access(struct pci_controller* hose,
+ u8 bus, u8 dev_fn, int offset)
+{
+ unsigned int caddr;
+
+ if (bus == hose->first_busno) {
+ caddr = U4_PCIE_CFA0(dev_fn, offset);
+ } else
+ caddr = U4_PCIE_CFA1(bus, dev_fn, offset);
+
+ /* Uninorth will return garbage if we don't read back the value ! */
+ do {
+ out_le32(hose->cfg_addr, caddr);
+ } while (in_le32(hose->cfg_addr) != caddr);
+
+ offset &= 0x03;
+ return hose->cfg_data + offset;
+}
+
+static int u4_pcie_read_config(struct pci_bus *bus, unsigned int devfn,
+ int offset, int len, u32 *val)
+{
+ struct pci_controller *hose;
+ volatile void __iomem *addr;
+
+ hose = pci_bus_to_host(bus);
+ if (hose == NULL)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ if (offset >= 0x1000)
+ return PCIBIOS_BAD_REGISTER_NUMBER;
+ addr = u4_pcie_cfg_access(hose, bus->number, devfn, offset);
+ if (!addr)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ /*
+ * Note: the caller has already checked that offset is
+ * suitably aligned and that len is 1, 2 or 4.
+ */
+ switch (len) {
+ case 1:
+ *val = in_8(addr);
+ break;
+ case 2:
+ *val = in_le16(addr);
+ break;
+ default:
+ *val = in_le32(addr);
+ break;
+ }
+ return PCIBIOS_SUCCESSFUL;
+}
+static int u4_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
+ int offset, int len, u32 val)
+{
+ struct pci_controller *hose;
+ volatile void __iomem *addr;
+
+ hose = pci_bus_to_host(bus);
+ if (hose == NULL)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ if (offset >= 0x1000)
+ return PCIBIOS_BAD_REGISTER_NUMBER;
+ addr = u4_pcie_cfg_access(hose, bus->number, devfn, offset);
+ if (!addr)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ /*
+ * Note: the caller has already checked that offset is
+ * suitably aligned and that len is 1, 2 or 4.
+ */
+ switch (len) {
+ case 1:
+ out_8(addr, val);
+ (void) in_8(addr);
+ break;
+ case 2:
+ out_le16(addr, val);
+ (void) in_le16(addr);
+ break;
+ default:
+ out_le32(addr, val);
+ (void) in_le32(addr);
+ break;
+ }
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static struct pci_ops u4_pcie_pci_ops =
+{
+ u4_pcie_read_config,
+ u4_pcie_write_config
+};
+
static void __init setup_u3_agp(struct pci_controller* hose)
{
/* On G5, we move AGP up to high bus number so we don't need
@@ -307,6 +412,26 @@ static void __init setup_u3_agp(struct p
u3_agp = hose;
}
+static void __init setup_u4_pcie(struct pci_controller* hose)
+{
+ /* We currently only implement the "non-atomic" config space, to
+ * be optimised later.
+ */
+ hose->ops = &u4_pcie_pci_ops;
+ hose->cfg_addr = ioremap(0xf0000000 + 0x800000, 0x1000);
+ hose->cfg_data = ioremap(0xf0000000 + 0xc00000, 0x1000);
+
+ /* The bus contains a bridge from root -> device, we need to
+ * make it visible on bus 0 so that we pick the right type
+ * of config cycles. If we didn't, we would have to force all
+ * config cycles to be type 1. So we override the "bus-range"
+ * property here
+ */
+ hose->first_busno = 0x00;
+ hose->last_busno = 0xff;
+ u4_pcie = hose;
+}
+
static void __init setup_u3_ht(struct pci_controller* hose)
{
hose->ops = &u3_ht_pci_ops;
@@ -354,6 +479,10 @@ static int __init add_bridge(struct devi
setup_u3_ht(hose);
disp_name = "U3-HT";
primary = 1;
+ } else if (device_is_compatible(dev, "u4-pcie")) {
+ setup_u4_pcie(hose);
+ disp_name = "U4-PCIE";
+ primary = 0;
}
printk(KERN_INFO "Found %s PCI host bridge. Firmware bus number: %d->%d\n",
disp_name, hose->first_busno, hose->last_busno);
@@ -361,7 +490,6 @@ static int __init add_bridge(struct devi
/* Interpret the "ranges" property */
/* This also maps the I/O region and sets isa_io/mem_base */
pci_process_bridge_OF_ranges(hose, dev, primary);
- pci_setup_phb_io(hose, primary);
/* Fixup "bus-range" OF property */
fixup_bus_range(dev);
@@ -376,8 +504,17 @@ void __init maple_pcibios_fixup(void)
DBG(" -> maple_pcibios_fixup\n");
- for_each_pci_dev(dev)
- pci_read_irq_line(dev);
+ for_each_pci_dev(dev) {
+ /* Fixup IRQ for PCIe host */
+ if (u4_pcie != NULL && dev->bus->number == 0 &&
+ pci_bus_to_host(dev->bus) == u4_pcie) {
+ printk(KERN_DEBUG "Fixup U4 PCIe IRQ\n");
+ dev->irq = irq_create_mapping(NULL, 1);
+ if (dev->irq != NO_IRQ)
+ set_irq_type(dev->irq, IRQ_TYPE_LEVEL_LOW);
+ } else
+ pci_read_irq_line(dev);
+ }
DBG(" <- maple_pcibios_fixup\n");
}
@@ -388,8 +525,10 @@ static void __init maple_fixup_phb_resou
list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
unsigned long offset = (unsigned long)hose->io_base_virt - pci_io_base;
+
hose->io_resource.start += offset;
hose->io_resource.end += offset;
+
printk(KERN_INFO "PCI Host %d, io start: %llx; io end: %llx\n",
hose->global_number,
(unsigned long long)hose->io_resource.start,
@@ -431,6 +570,19 @@ void __init maple_pci_init(void)
if (ht && add_bridge(ht) != 0)
of_node_put(ht);
+ /*
+ * We need to call pci_setup_phb_io for the HT bridge first
+ * so it gets the I/O port numbers starting at 0, and we
+ * need to call it for the AGP bridge after that so it gets
+ * small positive I/O port numbers.
+ */
+ if (u3_ht)
+ pci_setup_phb_io(u3_ht, 1);
+ if (u3_agp)
+ pci_setup_phb_io(u3_agp, 0);
+ if (u4_pcie)
+ pci_setup_phb_io(u4_pcie, 0);
+
/* Fixup the IO resources on our host bridges as the common code
* does it only for childs of the host bridges
*/
@@ -479,6 +631,9 @@ int maple_pci_get_legacy_ide_irq(struct
/* XXX: To remove once all firmwares are ok */
static void fixup_maple_ide(struct pci_dev* dev)
{
+ if (!machine_is(maple))
+ return;
+
#if 0 /* Enable this to enable IDE port 0 */
{
u8 v;
@@ -495,7 +650,7 @@ static void fixup_maple_ide(struct pci_d
dev->resource[4].start = 0xcc00;
dev->resource[4].end = 0xcc10;
#endif
-#if 1 /* Enable this to fixup IDE sense/polarity of irqs in IO-APICs */
+#if 0 /* Enable this to fixup IDE sense/polarity of irqs in IO-APICs */
{
struct pci_dev *apicdev;
u32 v;
^ permalink raw reply
* Re: [PATCH] powerpc: Enable DEEPNAP power savings mode on 970MP
From: Benjamin Herrenschmidt @ 2006-10-05 5:34 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20061004234141.749b13fb@localhost.localdomain>
On Wed, 2006-10-04 at 23:41 -0500, Olof Johansson wrote:
> Hi,
>
> Without this patch, on an idle system I get:
>
> cpu-power-0:21.638
> cpu-power-1:27.102
> cpu-power-2:29.343
> cpu-power-3:25.784
> Total: 103.8W
>
> With this patch:
>
> cpu-power-0:11.730
> cpu-power-1:17.185
> cpu-power-2:18.547
> cpu-power-3:17.528
> Total: 65.0W
>
> If I lower HZ to 100, I can get it as low as:
>
> cpu-power-0:10.938
> cpu-power-1:16.021
> cpu-power-2:17.245
> cpu-power-3:16.145
> Total: 60.2W
>
> Another (older) Quad G5 went from 54W to 39W at HZ=250.
>
> Coming back out of Deep Nap takes 40-70 cycles longer than coming back
> from just Nap (which already takes quite a while). I don't think it'll
> be a performance issue (interrupt latency on an idle system), but in
> case someone does measurements feel free to report them.
Isn't deep nap supposed to only get entered from F/4 which we never
use ?
Ben confused...
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
>
>
> Index: linux-2.6/arch/powerpc/kernel/cpu_setup_ppc970.S
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/cpu_setup_ppc970.S
> +++ linux-2.6/arch/powerpc/kernel/cpu_setup_ppc970.S
> @@ -83,6 +83,22 @@ _GLOBAL(__setup_cpu_ppc970)
> rldimi r0,r11,52,8 /* set NAP and DPM */
> li r11,0
> rldimi r0,r11,32,31 /* clear EN_ATTN */
> + b load_hids /* Jump to shared code */
> +
> +
> +_GLOBAL(__setup_cpu_ppc970MP)
> + /* Do nothing if not running in HV mode */
> + mfmsr r0
> + rldicl. r0,r0,4,63
> + beqlr
> +
> + mfspr r0,SPRN_HID0
> + li r11,0x15 /* clear DOZE and SLEEP */
> + rldimi r0,r11,52,6 /* set DEEPNAP, NAP and DPM */
> + li r11,0
> + rldimi r0,r11,32,31 /* clear EN_ATTN */
> +
> +load_hids:
> mtspr SPRN_HID0,r0
> mfspr r0,SPRN_HID0
> mfspr r0,SPRN_HID0
> Index: linux-2.6/arch/powerpc/kernel/cputable.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/cputable.c
> +++ linux-2.6/arch/powerpc/kernel/cputable.c
> @@ -41,6 +41,7 @@ extern void __setup_cpu_745x(unsigned lo
> #endif /* CONFIG_PPC32 */
> #ifdef CONFIG_PPC64
> extern void __setup_cpu_ppc970(unsigned long offset, struct cpu_spec* spec);
> +extern void __setup_cpu_ppc970MP(unsigned long offset, struct cpu_spec* spec);
> extern void __restore_cpu_ppc970(void);
> #endif /* CONFIG_PPC64 */
>
> @@ -221,7 +222,7 @@ struct cpu_spec cpu_specs[] = {
> .icache_bsize = 128,
> .dcache_bsize = 128,
> .num_pmcs = 8,
> - .cpu_setup = __setup_cpu_ppc970,
> + .cpu_setup = __setup_cpu_ppc970MP,
> .cpu_restore = __restore_cpu_ppc970,
> .oprofile_cpu_type = "ppc64/970",
> .oprofile_type = PPC_OPROFILE_POWER4,
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Eugene Surovegin @ 2006-10-05 6:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <1160005019.5887.30.camel@localhost.localdomain>
On Thu, Oct 05, 2006 at 09:36:59AM +1000, Benjamin Herrenschmidt wrote:
> Ugh ? Look at the #ifdef mess in ibm_emac...
Ugh?
I think you have to thank IBM/AMCC designers which keep changing bit
layout of some registers, sometimes just changing polarity for no
reason.
And with all due respect, Ben. Current ibm_emac despite of all "mess"
is actually usable in production environment, which cannot be said
about initial Armin version and second version you started but never
got time to actually finish.
--
Eugene
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Benjamin Herrenschmidt @ 2006-10-05 6:26 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <20061005062105.GA1985@gate.ebshome.net>
On Wed, 2006-10-04 at 23:21 -0700, Eugene Surovegin wrote:
> On Thu, Oct 05, 2006 at 09:36:59AM +1000, Benjamin Herrenschmidt wrote:
> > Ugh ? Look at the #ifdef mess in ibm_emac...
>
> Ugh?
>
> I think you have to thank IBM/AMCC designers which keep changing bit
> layout of some registers, sometimes just changing polarity for no
> reason.
>
> And with all due respect, Ben. Current ibm_emac despite of all "mess"
> is actually usable in production environment, which cannot be said
> about initial Armin version and second version you started but never
> got time to actually finish.
That second version was working fine... on the limited available
variations of EMAC back then.
Regarding the "mess", it's the whole #ifdef junk in there that is
driving me nuts and that I'll rip appart probably next week. A lot of
this could be soft-tests or the ifdefs could be resolved at Kconfig
instead of having a list of processors in 3 different headers if you
really want to compile the changes in rather than do soft-tests.
Ben.
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Eugene Surovegin @ 2006-10-05 6:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <17700.20834.792693.853677@cargo.ozlabs.ibm.com>
On Thu, Oct 05, 2006 at 10:27:14AM +1000, Paul Mackerras wrote:
> Dan Malek writes:
>
> > I'm not against using the device tree (or platform data
> > or #defines) when it's appropriate to do so. I think our
> > obsession to represent everything there is what is
> > creating the complexity. If a #define in a board
> > specific port file makes sense, then just do that,
> > even if it is a BSCR address.
>
> So, where this discussion started was that I saw an ioremap in an
> ethernet driver using a physical address defined with #define, and I
> said "that should go in the device tree". And I would still say that
> if the ioremap was still there, since the driver is one that is useful
> across a range of boards and chips.
>
> My other point would be that what you say is valid *until* the
> hardware engineers come to you and say "we're doing rev 2 of the
> board, and we had to move the BCSR a bit. That's OK with you, isn't
> it?".
>
> If you have the BCSR address in the device tree, you don't even need
> to recompile your kernel. You can just copy your board.dts to
> board-rev2.dts, change the address in there, and rerun the wrapper
> script to create the flash image to put on the new board. Or if you
> are using a bootloader that knows how to supply a device-tree blob,
> you just put board-rev2.dtb into flash along with your existing kernel
> image.
Paul,
it doesn't really matter if you have to rebuild a kernel or some
other blob and have it re-flashed in the actual board.
Having something in device tree doesn't change a simple fact that you
have to update some firmware component, be it boot code, kernel or
some dts blob. You still have to prepare new flash image, period.
--
Eugene
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Eugene Surovegin @ 2006-10-05 6:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <1160029594.22232.22.camel@localhost.localdomain>
On Thu, Oct 05, 2006 at 04:26:34PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2006-10-04 at 23:21 -0700, Eugene Surovegin wrote:
> > On Thu, Oct 05, 2006 at 09:36:59AM +1000, Benjamin Herrenschmidt wrote:
> > > Ugh ? Look at the #ifdef mess in ibm_emac...
> >
> > Ugh?
> >
> > I think you have to thank IBM/AMCC designers which keep changing bit
> > layout of some registers, sometimes just changing polarity for no
> > reason.
> >
> > And with all due respect, Ben. Current ibm_emac despite of all "mess"
> > is actually usable in production environment, which cannot be said
> > about initial Armin version and second version you started but never
> > got time to actually finish.
>
> That second version was working fine... on the limited available
> variations of EMAC back then.
No it wasn't. If it were I would have never wasted my time re-writing
this driver.
--
Eugene
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Eugene Surovegin @ 2006-10-05 6:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <1160029594.22232.22.camel@localhost.localdomain>
On Thu, Oct 05, 2006 at 04:26:34PM +1000, Benjamin Herrenschmidt wrote:
>
> Regarding the "mess", it's the whole #ifdef junk in there that is
> driving me nuts and that I'll rip appart probably next week. A lot of
> this could be soft-tests or the ifdefs could be resolved at Kconfig
> instead of having a list of processors in 3 different headers if you
> really want to compile the changes in rather than do soft-tests.
Well, sent me changes for review, or become a maintainer, but this
time _real_ maintainer, not like last time when you touched this code.
--
Eugene
^ permalink raw reply
* [PATCH] powerpc: Don't get PCI IRQ from OF for devices with no IRQ
From: Benjamin Herrenschmidt @ 2006-10-05 6:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
This patch adds checking of the PCI_INTERRUPT_PIN register before
using standard OF parsing to retreive PCI interrupts. The reason is
that some PCI devices may have no PCI interrupt, though they may have
interrupts attached via other means. In this case, we shall not use
irq->pdev, but device-specific code can later retreive those interrupts
instead.
Without that patch, Maple and derivatives don't get the right interrupt
for the second IDE channel as the linux IDE code fallsback to the PCI
irq instead of trying to use the legacy ones for the on-board controller
(which has no PCI_INTERRUPT_PIN). Having no PCI IRQ assign to it (as it
doesn't request any) fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/kernel/prom_parse.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/prom_parse.c 2006-10-03 12:41:03.000000000 +1000
+++ linux-work/arch/powerpc/kernel/prom_parse.c 2006-10-05 16:33:25.000000000 +1000
@@ -914,6 +914,17 @@ int of_irq_map_pci(struct pci_dev *pdev,
u8 pin;
int rc;
+ /* We need to first check if the PCI device has a PCI interrupt at all
+ * since we have cases where the device-node might expose non-PCI
+ * interrupts, but the device has no PCI interrupt to it
+ */
+ rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
+ if (rc != 0)
+ return rc;
+ /* No pin, exit */
+ if (pin == 0)
+ return -ENODEV;
+
/* Check if we have a device node, if yes, fallback to standard OF
* parsing
*/
@@ -925,12 +936,6 @@ int of_irq_map_pci(struct pci_dev *pdev,
* interrupt spec. we assume #interrupt-cells is 1, which is standard
* for PCI. If you do different, then don't use that routine.
*/
- rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
- if (rc != 0)
- return rc;
- /* No pin, exit */
- if (pin == 0)
- return -ENODEV;
/* Now we walk up the PCI tree */
lspec = pin;
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Benjamin Herrenschmidt @ 2006-10-05 6:51 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <20061005063304.GD1985@gate.ebshome.net>
On Wed, 2006-10-04 at 23:33 -0700, Eugene Surovegin wrote:
> On Thu, Oct 05, 2006 at 04:26:34PM +1000, Benjamin Herrenschmidt wrote:
> >
> > Regarding the "mess", it's the whole #ifdef junk in there that is
> > driving me nuts and that I'll rip appart probably next week. A lot of
> > this could be soft-tests or the ifdefs could be resolved at Kconfig
> > instead of having a list of processors in 3 different headers if you
> > really want to compile the changes in rather than do soft-tests.
>
> Well, sent me changes for review, or become a maintainer, but this
> time _real_ maintainer, not like last time when you touched this code.
Well, last time I touched this code, I took something that was not
working at all and made it work for me and a couple of other people that
were working on it at the same time. If it had issues, they were never
reported to me back then. However, I never intended to do long term
maintainership of this driver and that was clear from the very
beginning. If you ran into other issues and fixed them afterward, that's
fine, but don't blame me for not fixing issues I didn't encounter nor
was told about for the short time while I was taking care of it.
Anyway, my point is, the per-processor ifdef lists are just fugly and
need to be turned into "soft" changes. The driver also needs to get some
OF probing and use the new DCR accessors to move over to powerpc and to
work with the EMAC cell within the new Cell southbridge.
I have some preliminary patches doing just the OF probing and DCR
changes. I still want to do some serious change of the #ifdef mess into
something more flexible to allow for runtime choice of the type of EMAC
and MAL.
I'll post patches (and possibly incremental "cleanup") to the list,
CC'ing you, as expected for a driver you maintain.
Ben.
^ permalink raw reply
* Re: booting 2.6 kernel on ML403
From: Ameet Patil @ 2006-10-05 8:27 UTC (permalink / raw)
To: Pradeep Sampath; +Cc: linuxppc-embedded
In-Reply-To: <20061004163517.17874.qmail@web83207.mail.mud.yahoo.com>
Hi Pradeep,
Pradeep Sampath wrote:
> Hello Ameet/Ming,
>
> First of all really appreciate your inputs on this...
> Problem 1 :
> I was using the factory shipped compact flash as is which comes with a
> DOS FAT16 partition and a linux 83 partition with ext3 filesystem.
> I tried it on 2 factory shipped CFs and its the same behavior - . When
> i plug-in the CF card reader to the linux box it always reads it as
> "sda" and in the linux2.6.17.1/Documentation/devices.txt - sda is the
> device file for SCSI disk devices. Wonerding how you guys configured
> the root option as "/dev/xsa".
xsa and sda are nothing but the device name registered by the driver. It
is not related to whether the device is a SCSI or not. Since I wrote the
SysAce driver, I decided to name it as xsa (as opposed to the original
Monta Vista xsysace). Thus, all the partitions on this device will be
named xsa1 for the first partition, xsa2 for the second and so on.
When you access your CF card in your Linux PC, the driver names the
device as sda. Thats all... theres no much difference. Hope you got the
point.
cheers,
-Ameet
>
> Now i re-formatted my CF, created a ext2 filesystem using
> busybox-1.1.0 like the BYU instructions. Created 2 partitions on CF
> card 1. FAT16 partition & 2. linux partition and then created 1. dos
> file system using mkdosfs and 2. linux ext2 filesystem using mke2fs.
>
> But the problem still persists and i get "Please append a correct
> "root=" boot option :"
> :(
>
> Problem 2: After i included the TEMAC driver and sysace drivers,
> the kernel just hangs. I thought i'll fix problem 1 before i get to
> problem 2...
>
> With your help i am getting the confidence that i can make this all work!
> thanks once again.
> -Pradeep
>
>
>
> */Ming Liu <eemingliu@hotmail.com>/* wrote:
>
> Hello Ameet,
> I am using that driver very well now. There is only one problem.
> It seems
> that the driver for TEMAC only support Gigabit Enet, not 10/100/1000M
> adapted. But because I want to use the Gigabit enet, I don't care
> that. So
> it's OK, at lease for 1Gbit/s.
>
> So I don't think Pradeep's problem is caused by Temac. I still
> suspect that
> he didn't pass a right parameter to "root=", just like what I posted
> before.
>
> Regards
> Ming
>
>
> >From: Ameet Patil
> >To: Ming Liu
> >CC: pradeepsampath@yahoo.com, linuxppc-embedded@ozlabs.org
> >Subject: Re: booting 2.6 kernel on ML403
> >Date: Wed, 04 Oct 2006 09:35:07 +0100
> >
> >Ming Liu wrote:
> > > Hi,
> > >
> > >> [ 3.093694] TCP bic registered
> > >> [ 3.129458] NET: Registered protocol family 8
> > >> [ 3.181412] NET: Registered protocol family 20
> > >> [ 3.236744] VFS: Cannot open root device "xsa2" or
> unknown-block(0,0)
> > >> [ 3.313092] Please append a correct "root=" boot option
> > >
> > > It looks that some errors still exist in the parameters you
> passed to
> > > "root=". Please double check it, or post it in the maillist
> for deep
> > > analysis.
> > > Regards
> > > Ming
> > >
> > > _________________________________________________________________
> > > ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£
> http://www.hotmail.com
> > >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >Hi Ming,
> >IIRC, you are or were using the TEMAC driver along with my System Ace
> >driver, isn't it? Does my driver patch ***-after-TEMAC.patch work for
> >you? I ask this because Pradeep is having some problems using it (see
> >Problem 2 in his email). Could you please update on this?
> >
> >Thanks,
> >-Ameet
>
> _________________________________________________________________
> ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger:
> http://messenger.msn.com/cn
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: booting 2.6 kernel on ML403
From: Ameet Patil @ 2006-10-05 8:30 UTC (permalink / raw)
To: Pradeep Sampath; +Cc: linuxppc-embedded
In-Reply-To: <20061004164721.22885.qmail@web83207.mail.mud.yahoo.com>
Pradeep,
What you have pasted is only part of the messages displayed. I can't
tell anything from this apart from you 'root=' option. It would be nice
if you could paste the entire log of the boot messages right from
'loaded at: xxxxxxx xxxxxxxx' to 'Kernel Rebooting in 150 seconds'.
-Ameet
Pradeep Sampath wrote:
> Ameet,
>
> loaded at: 00400000 0051513C
> board data at: 00513124 0051313C
> relocated to: 004050E8 00405100
> zimage at: 004057FD 0051230A
> avail ram: 00516000 04000000
> Linux/PPC load: console=ttyS0,9600 root=/dev/xsa2
> Uncompressing Linux...done.
> Now booting the kernel
>
>
> Please could send me all the boot messages until the point where it
> stops. This will help me better identify the problem.
>
> Thanks,
> -Ameet
>
>
^ permalink raw reply
* Re: [PATCH] linux,tce-size property is 32 bits
From: Benjamin Herrenschmidt @ 2006-10-05 9:18 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras, matthltc
In-Reply-To: <20061005032800.GH24705@localdomain>
On Wed, 2006-10-04 at 22:28 -0500, Nathan Lynch wrote:
> The "linux,tce-size" property is only 32 bits (see
> prom_initialize_tce_table() in arch/powerpc/kernel/prom_init.c).
> Treating it as an unsigned long in iommu_table_setparms() leads to
> access beyond the end of the property's buffer, so we pass garbage to
> the memset() in that function.
Probably needs to go into stable as well. Do you know if RHEL5 is
affected too ?
Cheers
Ben.
> [boot]0020 XICS Init
> i8259 legacy interrupt controller initialized
> [boot]0021 XICS Done
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> cpu 0x0: Vector: 300 (Data Access) at [c0000000fe783850]
> pc: c000000000035e90: .memset+0x60/0xfc
> lr: c000000000044fa4: .iommu_table_setparms+0xb0/0x158
> sp: c0000000fe783ad0
> msr: 9000000000009032
> dar: c000000100000000
> dsisr: 42010000
> current = 0xc00000000450e810
> paca = 0xc000000000411580
> pid = 1, comm = swapper
> enter ? for help
> [link register ] c000000000044fa4 .iommu_table_setparms+0xb0/0x158
> [c0000000fe783ad0] c000000000044f4c .iommu_table_setparms+0x58/0x158
> (unreliable)
> [c0000000fe783b70] c00000000004529c
> .iommu_bus_setup_pSeries+0x1c4/0x254
> [c0000000fe783c00] c00000000002b8ac .do_bus_setup+0x3c/0xe4
> [c0000000fe783c80] c00000000002c924 .pcibios_fixup_bus+0x64/0xd8
> [c0000000fe783d00] c0000000001a2d5c .pci_scan_child_bus+0x6c/0x10c
> [c0000000fe783da0] c00000000002be28 .scan_phb+0x17c/0x1b4
> [c0000000fe783e40] c0000000003cfa00 .pcibios_init+0x58/0x19c
> [c0000000fe783ec0] c0000000000094b4 .init+0x1e8/0x3d8
> [c0000000fe783f90] c000000000026e54 .kernel_thread+0x4c/0x68
>
> Signed-off-by: Nathan Lynch <ntl@pobox.com>
>
> ---
>
> I believe this is a regression since 2.6.18, so please push for
> inclusion in 2.6.19.
>
>
> --- linux-2.6.git.orig/arch/powerpc/platforms/pseries/iommu.c
> +++ linux-2.6.git/arch/powerpc/platforms/pseries/iommu.c
> @@ -267,7 +267,8 @@ static void iommu_table_setparms(struct
> struct iommu_table *tbl)
> {
> struct device_node *node;
> - const unsigned long *basep, *sizep;
> + const unsigned long *basep;
> + const u32 *sizep;
>
> node = (struct device_node *)phb->arch_data;
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 2.6.19-rc1] ehea bug fix (port state notification, default queue sizes)
From: Jeff Garzik @ 2006-10-05 11:30 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
In-Reply-To: <200609281244.40887.ossthema@de.ibm.com>
which patch is to be applied first?
You failed to include an order, as described by
http://linux.yyz.us/patch-format.html and Documentation/SubmittingPatches.
Also, stuff like "hi Jeff" and "Thanks, Jan-Bernd" must be hand-edited
out before patch application. All comments not intended to be DIRECTLY
copied into the kernel changeset description should follow the "---"
separator.
Jeff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox