* Re: [PATCH 4/8] powerpc: add the ability for a classic ppc kernel to be loaded at 32M
From: Anton Vorontsov @ 2008-08-01 20:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080801184952.GA25225@ld0162-tx32.am.freescale.net>
On Fri, Aug 01, 2008 at 01:49:52PM -0500, Scott Wood wrote:
> On Fri, Aug 01, 2008 at 06:14:20PM +0400, Anton Vorontsov wrote:
> > From: Dale Farnsworth <dale@farnsworth.org>
> >
> > Add the ability for a classic ppc kernel to be loaded at an address
> > of 32MB. This done by fixing a few places that assume we are loaded
> > at address 0, and by changing several uses of KERNELBASE to use
> > PAGE_OFFSET, instead.
>
> What do you do about the exception vectors?
Making a trampoline code in place of exception vectors. See this patch:
[PATCH 8/8] powerpc: last bits to support kdump on ppc32
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Trent Piepho @ 2008-08-01 21:14 UTC (permalink / raw)
To: Jon Smirl; +Cc: Linuxppc-dev, Timur Tabi, Scott Wood, Linux I2C
In-Reply-To: <9e4733910808010732u48ed06a4vc2121c133d91bbbd@mail.gmail.com>
On Fri, 1 Aug 2008, Jon Smirl wrote:
> I don't like the third choice. Keep a simple Linux driver for i2c and
> the platform, and then move all of the messy code into uboot. BTW,
> the messy code is about 10 lines. It's going to take more than 10
> lines to hide those 10 lines.
It's not being _moved_ to u-boot, it's already there. U-boot needs it
because u-boot uses i2c.
It would need to be duplicated in linux, and then both u-boot and linux
would need to be updated each time a new platform is added.
It's pretty much a given that a u-boot binary will only work on one
platform. The same is not true with a compiled kernel. That makes it
harder to all the platform specific stuff in linux. It's a little more
than 10 lines too. Keep in mind that accessing all these devices registers
isn't as easy in linux as u-boot. In linux you have to look up the
register location in device tree and map the registers. All this code uses
a system clock as a starting point, which u-boot already passes to linux.
#if defined(CONFIG_MPC83XX)
volatile immap_t *im = (immap_t *) CFG_IMMR;
sccr = im->clk.sccr;
#if defined(CONFIG_MPC834X) || defined(CONFIG_MPC831X) || defined(CONFIG_MPC837X)
switch ((sccr & SCCR_TSEC1CM) >> SCCR_TSEC1CM_SHIFT) {
case 0:
tsec1_clk = 0;
break;
case 1:
tsec1_clk = csb_clk;
break;
case 2:
tsec1_clk = csb_clk / 2;
break;
case 3:
tsec1_clk = csb_clk / 3;
break;
default:
/* unkown SCCR_TSEC1CM value */
return -2;
}
#endif
#if defined(CONFIG_MPC834X) || defined(CONFIG_MPC837X) || defined(CONFIG_MPC8315)
switch ((sccr & SCCR_TSEC2CM) >> SCCR_TSEC2CM_SHIFT) {
case 0:
tsec2_clk = 0;
break;
case 1:
tsec2_clk = csb_clk;
break;
case 2:
tsec2_clk = csb_clk / 2;
break;
case 3:
tsec2_clk = csb_clk / 3;
break;
default:
/* unkown SCCR_TSEC2CM value */
return -4;
}
#elif defined(CONFIG_MPC8313)
tsec2_clk = tsec1_clk;
if (!(sccr & SCCR_TSEC1ON))
tsec1_clk = 0;
if (!(sccr & SCCR_TSEC2ON))
tsec2_clk = 0;
#endif
switch ((sccr & SCCR_ENCCM) >> SCCR_ENCCM_SHIFT) {
case 0:
enc_clk = 0;
break;
case 1:
enc_clk = csb_clk;
break;
case 2:
enc_clk = csb_clk / 2;
break;
case 3:
enc_clk = csb_clk / 3;
break;
default:
/* unkown SCCR_ENCCM value */
return -7;
}
#if defined(CONFIG_MPC837X)
switch ((sccr & SCCR_SDHCCM) >> SCCR_SDHCCM_SHIFT) {
case 0:
sdhc_clk = 0;
break;
case 1:
sdhc_clk = csb_clk;
break;
case 2:
sdhc_clk = csb_clk / 2;
break;
case 3:
sdhc_clk = csb_clk / 3;
break;
default:
/* unkown SCCR_SDHCCM value */
return -8;
}
#endif
#if defined(CONFIG_MPC834X)
i2c1_clk = tsec2_clk;
#elif defined(CONFIG_MPC8360)
i2c1_clk = csb_clk;
#elif defined(CONFIG_MPC832X)
i2c1_clk = enc_clk;
#elif defined(CONFIG_MPC831X)
i2c1_clk = enc_clk;
#elif defined(CONFIG_MPC837X)
i2c1_clk = sdhc_clk;
#endif
#if !defined(CONFIG_MPC832X)
i2c2_clk = csb_clk; /* i2c-2 clk is equal to csb clk */
#endif
#elif defined (CONFIG_MPC85XX)
#if defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \
defined(CONFIG_MPC8560) || defined(CONFIG_MPC8555)
gd->i2c1_clk = sys_info.freqSystemBus;
#elif defined(CONFIG_MPC8544)
volatile ccsr_gur_t *gur = (void *) CFG_MPC85xx_GUTS_ADDR;
/*
* On the 8544, the I2C clock is the same as the SEC clock. This can be
* either CCB/2 or CCB/3, depending on the value of cfg_sec_freq. See
* 4.4.3.3 of the 8544 RM. Note that this might actually work for all
* 85xx, but only the 8544 has cfg_sec_freq, so it's unknown if the
* PORDEVSR2_SEC_CFG bit is 0 on all 85xx boards that are not an 8544.
*/
if (gur->pordevsr2 & MPC85xx_PORDEVSR2_SEC_CFG)
gd->i2c1_clk = sys_info.freqSystemBus / 3;
else
gd->i2c1_clk = sys_info.freqSystemBus / 2;
#else
/* Most 85xx SOCs use CCB/2, so this is the default behavior. */
gd->i2c1_clk = sys_info.freqSystemBus / 2;
#endif
gd->i2c2_clk = gd->i2c1_clk;
#elif defined(CONFIG_MPC86XX)
#ifdef CONFIG_MPC8610
gd->i2c1_clk = sys_info.freqSystemBus;
#else
gd->i2c1_clk = sys_info.freqSystemBus / 2;
#endif
gd->i2c2_clk = gd->i2c1_clk;
#endif
^ permalink raw reply
* Re: ide pmac breakage
From: Benjamin Herrenschmidt @ 2008-08-01 22:26 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: FUJITA Tomonori, linux-ide, petkovbb, linuxppc-dev
In-Reply-To: <200808011254.02989.bzolnier@gmail.com>
On Fri, 2008-08-01 at 12:54 +0200, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 31 July 2008, Bartlomiej Zolnierkiewicz wrote:
>
> [...]
>
> Sorry if my mails were a bit harsh but nobody likes to be pushed around.
>
> [ It is not like I don't want to add proper hot-plugging support or do test
> on more hardware but my time schedule is already tight enough and there are
> still more fundamental things to address (which take priority). ]
>
> > - host->dev[0] = hws[0]->dev;
> > + host->dev[0] = hws[0]->parent ? hws[0]->parent : hws[0]->dev;
> >
> > Could you please try it together with my previous patch for
> > ide_device_{get,put}()?
>
> Please test it when you have some time.
The problem in that case is access to the HW :-) I have plenty ide-pmac
based machines but only one or two old laptop (ie. Paul has one too)
with a media-bay and those are in the office. So I'll test on Monday
when I get there, unless I get a chance to pop by on Sunday but that's
unlikely.
Ben.
^ permalink raw reply
* Re: Board level compatibility matching
From: Benjamin Herrenschmidt @ 2008-08-01 22:48 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <20080801080632.35edcb04@zod.rchland.ibm.com>
> This is sort of the part that sucks. Look at 44x. There are 10
> board.c files there. There really only needs to be 3 or 4 (sam440ep,
> warp, virtex, and "generic") because the board files are identical in
> everything except name. By doing the library code approach, one still
> has to create a board.c file for a new board and plug in the library
> functions to ppc_md.
And ? How is that a big deal ? Real products (ie not eval boards, and
even those ...) will probably end up needing that due to subtle
differences anyway.
> Alternatively, you could do the:
>
> compatible = "specific-board", "similar-board"
>
> approach that has been done for e.g. Bamboo and Yosemite. Again, the
> issue is that is that OK? Is it OK for a board to claim compatibility
> with another board when it might not have all the devices of that
> board, or might have additional devices, etc. I was of the opinion
> it is, and the device tree handles this just fine, as does the platform
> code. But it can be confusing, hence the discussion here.
Well, as I said. If it stops being ok, just create your own board
and it will take over provided you put it before the other one in
the link order.
If we generalize that approach, we might want to change the board
probing code a bit to first do a full pass based on the first
entry in compatible, then another full pass based on the second, etc...
Ben.
^ permalink raw reply
* Re: Board level compatibility matching
From: Benjamin Herrenschmidt @ 2008-08-01 22:54 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <fa686aa40808010727v53fe3580q2813a12cb66f8f68@mail.gmail.com>
On Fri, 2008-08-01 at 08:27 -0600, Grant Likely wrote:
>
> I agree with most of your argument, except I really have problems with
> boards claiming compatibility with an older board. My reason is
> exactly the reason you state; One day you'll figure out that there is
> indeed a difference. The problem is; when the original board (the one
> others are claiming compatibility with) gains additional code to fixup
> quirks or something, then that code will get changed with no
> visibility that it is borking up other boards that are currently
> depending on it.
Then just use your own .c file. It's not like it was a big deal.
I don't know why it's -so- appealing to not have to do one at all.
> I far prefer the solution I'm currently using in 5200-land where there
> is a simple (boring?) board port which *explicitly* states which
> boards it supports (see arch/powerpc/platforms/52xx/mpc5200_simple.c).
> When someone goes to modify that file, it is explicit that it
> currently supports multiple boards. If a board becomes 'non-boring',
> then it is removed from the simple platform; the simple platform is
> *not* extended to accommodate it.
As long as you stick to -never- extend the simple platform to accomodate
for a variant, then I suppose that's ok I suppose, though that does
raise the point of what to put in the compatible property.
> I *fully* agree that it is insane for the code to grow detection logic
> and I've been explicit about not doing anything of the sort in 5200
> land. What I am suggesting is that if nothing else claims the board,
> then allow the simple platform to bind against it based on the fact
> that it uses the same SoC.
See my comment in my reply to Josh about changing the board probe into a
multi-pass probe so that first, we only match on the first entry of the
compatible property, then we match on the second, etc... to go from more
specific to less specific.
> However, if I can't get concensus on this approach, then I do /not/
> want to go to a boards compatible with other boards scheme. It will
> cause breakage and pain that is non-obvious to debug for many users.
As far as I'm concerned, this approach is mostly useful for revisions of
a board. Oh and I'm not going to whack you with a stick if in the end,
you do have a little bit of variation in a single board .c file to deal
with a glitch in rev. C of the board that wired something backward for
example ... it's a matter of perspective. But I would prefer a different
board (from a different vendor for example) to use a different .c file
even if it only differs by the same little glitch.
> BTW, I am also not suggesting that the .dts files themselves try to
> claim some kind of 'generic' compatibility. I'm proposing handling
> any catch-all cases in the Linux code itself, where it is easy to
> change because it is just an implementation detail. Trying to make
> the dt 'generic' doesn't make any sense because doing so is almost
> always wrong (or will become wrong in the future).
The problem is that I don't see a sane way to do the catch all in the
linux code, other than explicitely doing what you already do which is to
list all supported boards in the simple platform. It's either that or
adding some compatible "socname,linux-simple" or so property in
your .dts. I don't believe matching on SoC is of any use. It will
incorrectly try to match things that don't work and that's bad.
Ben.
^ permalink raw reply
* Re: [PATCH 00/10] powerpc: Remove use of CONFIG_PPC_MERGE
From: Paul Mackerras @ 2008-08-01 23:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1217609060-6381-1-git-send-email-galak@kernel.crashing.org>
Kumar Gala writes:
> This set of patches remove Kconfig and code related to CONFIG_PPC_MERGE
> and !CONFIG_PPC_MERGE. There is some discussion about that one last
> use of !PPC_MERGE with respect to the 4xx MTD_NAND_NDFC driver.
>
> Paul, is this something you'd be willing to entertain for 2.6.27?
Yes, since it's just dead code removal.
Paul.
^ permalink raw reply
* Re: Board level compatibility matching
From: Josh Boyer @ 2008-08-02 0:07 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1217630903.11188.537.camel@pasglop>
On Sat, 02 Aug 2008 08:48:23 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > This is sort of the part that sucks. Look at 44x. There are 10
> > board.c files there. There really only needs to be 3 or 4 (sam440ep,
> > warp, virtex, and "generic") because the board files are identical in
> > everything except name. By doing the library code approach, one still
> > has to create a board.c file for a new board and plug in the library
> > functions to ppc_md.
>
> And ? How is that a big deal ? Real products (ie not eval boards, and
> even those ...) will probably end up needing that due to subtle
> differences anyway.
I didn't say it was a big deal. But I also think it's pretty pointless
to carry around a bunch of C files that have to get the same set of
fixes across the board when updated because they really only differ by
the function names. Particularly when you could just have one C file
with a list of supported boards.
As I said, to me this is about cleanup and maintenance. I totally
agree that truly custom boards (e.g. actual products) will likely
require different board.c files and that's just fine with me. I'm just
looking for the best approach to cleanup the ones that don't need to
be, and the explicit list seems to be that way.
> > Alternatively, you could do the:
> >
> > compatible = "specific-board", "similar-board"
> >
> > approach that has been done for e.g. Bamboo and Yosemite. Again, the
> > issue is that is that OK? Is it OK for a board to claim compatibility
> > with another board when it might not have all the devices of that
> > board, or might have additional devices, etc. I was of the opinion
> > it is, and the device tree handles this just fine, as does the platform
> > code. But it can be confusing, hence the discussion here.
>
> Well, as I said. If it stops being ok, just create your own board
> and it will take over provided you put it before the other one in
> the link order.
>
> If we generalize that approach, we might want to change the board
> probing code a bit to first do a full pass based on the first
> entry in compatible, then another full pass based on the second, etc...
I don't care much either way. I guess I'd rather avoid relying on
strict link order to do the probing right, if only because a simple
mistake can break things.
There might not be a "one true way", but Grant and I thought it
pertinent to bring up a discussion in case there was a "very wrong
way", that's all.
josh
^ permalink raw reply
* Re: [PATCH 01/10] powerpc: Remove use of CONFIG_PPC_MERGE
From: Michael Ellerman @ 2008-08-02 2:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1217609060-6381-2-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
On Fri, 2008-08-01 at 11:44 -0500, Kumar Gala wrote:
> Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore remove
> the dead code associated with !CONFIG_PPC_MERGE out of arch/powerpc
> and include/asm-powerpc.
...
> diff --git a/include/asm-powerpc/irq.h b/include/asm-powerpc/irq.h
> index 1ef8e30..a372f76 100644
> --- a/include/asm-powerpc/irq.h
> +++ b/include/asm-powerpc/irq.h
...
> -#define SIU_INT_PC4 ((uint)0x3b + CPM_IRQ_OFFSET)
> -#define SIU_INT_PC3 ((uint)0x3c + CPM_IRQ_OFFSET)
> -#define SIU_INT_PC2 ((uint)0x3d + CPM_IRQ_OFFSET)
> -#define SIU_INT_PC1 ((uint)0x3e + CPM_IRQ_OFFSET)
> -#define SIU_INT_PC0 ((uint)0x3f + CPM_IRQ_OFFSET)
> -
> -#endif /* CONFIG_8260 */
> -
> -#endif /* Whatever way too big #ifdef */
I'll miss that one, it made me laugh once.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Creating a wrapped zImage.initrd -- can't start the trampoline?
From: Paul Smith @ 2008-08-02 2:40 UTC (permalink / raw)
To: Linuxppc-embedded
Hi all;
I'm working with a PPC 460EX-based board. I have a 2.6.25.10-based
kernel I obtained from the DENX git tree which contains a port to this
board, under arch/powerpc.
I can build a kernel and have it downloaded and booting using u-boot,
providing the blob and appropriate kernel parameters, after having done
a standard "make zImage" with the appropriate configs etc. All good so
far.
However, my ultimate target board uses a custom bootloader, not uboot,
which is very, very simple (please don't suggest we just switch to
uboot--that argument has been already had, and lost :-/) I had a
previous version of Linux, 2.6.14, booting on a predecessor of this
board based on the 440GX with the same bootloader, but the creation of
that image was done under arch/ppc and it was pretty different (I'm
discovering). And, I didn't do that port anyway.
Anyway, I need to generate an all-in-one image containing the kernel and
the initrd, and the trampoline code tacked onto it to turn it into an
ELF image. I'm worried I'll need to write a custom platform_init() but
for now I'm just using of.c.
>From what I can tell, the wrapper script seems to be intended to have
the ability to generate an image like this. I've tried just running
"make zImage.initrd" after putting the ramdisk.initrd.gz in the right
place, and it seems to create an image OK: using file shows it to be
"ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV),
statically linked, not stripped", which seems correct.
But we can't get it to boot.
The bootloader downloads the image (tftp) and jumps to the start address
in the ELF image, and immediately takes an illegal instruction. We have
set the bootloader to load the image at 0x00000000 and then we look
through the ELF image for the start address, which (using objdump) I can
see is the correct address for the _zimage_start symbol from crt0.S; in
our case it's 0x00400204.
When we use a debugger to look at what's loaded at that location, it's
just a whole slew of 0xa bytes... obviously not right. Is the start
address not the offset from the start of the ELF image? Should we be
loading the image somewhere else (the previous incarnation loaded it at
0x0, so we just did that too)?
I'm afraid I'm at the very outer limits of my knowledge on these
matters. I realize there is not enough detail in the above to really
provide an answer but any suggestions anyone has would be very much
appreciated.
Cheers!
^ permalink raw reply
* [PATCH] port ndfc driver to arch/powerpc
From: Sean MacLennan @ 2008-08-02 3:30 UTC (permalink / raw)
To: linuxppc-dev
This is a port of the ndfc driver from arch/ppc to arch/powerpc. Since
arch/ppc has been removed, references to CONFIG_PPC_MERGE where removed.
For an example of how to use the driver see
arch/powerpc/platforms/44x/warp-nand.c .
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 02f9cc3..b0d408e 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -165,7 +165,7 @@ config MTD_NAND_S3C2410_HWECC
config MTD_NAND_NDFC
tristate "NDFC NanD Flash Controller"
- depends on 4xx && !PPC_MERGE
+ depends on 4xx
select MTD_NAND_ECC_SMC
help
NDFC Nand Flash Controllers are integrated in IBM/AMCC's 4xx SoCs
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 955959e..efb1ab6 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -21,14 +21,11 @@
#include <linux/mtd/partitions.h>
#include <linux/mtd/ndfc.h>
#include <linux/mtd/mtd.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
#include <linux/platform_device.h>
#include <asm/io.h>
-#ifdef CONFIG_40x
-#include <asm/ibm405.h>
-#else
-#include <asm/ibm44x.h>
-#endif
struct ndfc_nand_mtd {
struct mtd_info mtd;
@@ -103,8 +100,9 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
wmb();
ecc = __raw_readl(ndfc->ndfcbase + NDFC_ECC);
- ecc_code[0] = p[1];
- ecc_code[1] = p[2];
+ /* The NDFC uses Smart Media (SMC) bytes order */
+ ecc_code[0] = p[2];
+ ecc_code[1] = p[1];
ecc_code[2] = p[3];
return 0;
@@ -234,11 +232,7 @@ static int ndfc_nand_probe(struct platform_device *pdev)
struct ndfc_controller *ndfc = &ndfc_ctrl;
unsigned long long phys = settings->ndfc_erpn | res->start;
-#ifndef CONFIG_PHYS_64BIT
ndfc->ndfcbase = ioremap((phys_addr_t)phys, res->end - res->start + 1);
-#else
- ndfc->ndfcbase = ioremap64(phys, res->end - res->start + 1);
-#endif
if (!ndfc->ndfcbase) {
printk(KERN_ERR "NDFC: ioremap failed\n");
return -EIO;
@@ -300,9 +294,16 @@ static int __init ndfc_nand_init(void)
init_waitqueue_head(&ndfc_ctrl.ndfc_control.wq);
ret = platform_driver_register(&ndfc_nand_driver);
- if (!ret)
- ret = platform_driver_register(&ndfc_chip_driver);
- return ret;
+ if (ret)
+ return ret;
+
+ ret = platform_driver_register(&ndfc_chip_driver);
+ if (ret) {
+ platform_driver_unregister(&ndfc_nand_driver);
+ return ret;
+ }
+
+ return 0;
}
static void __exit ndfc_nand_exit(void)
^ permalink raw reply related
* Re: platforms/44x/warp-nand.c bogosity
From: Sean MacLennan @ 2008-08-02 3:42 UTC (permalink / raw)
To: Valentine Barshak; +Cc: Adrian Bunk, linuxppc-dev, paulus, Stefan Roese
In-Reply-To: <48932C78.9010303@ru.mvista.com>
For those who are interested, I have posted a patch for the ndfc
driver. This is the driver we use un-bogusitize the warp-nand ;)
I removed the CONFIG_PPC_MERGE defines, but other than that this is the
driver we use in production.
Stefan: This has the byte order reversing that I believe you where
going to look into wrt u-boot. This may need to be a config option.
Cheers,
Sean
^ permalink raw reply
* nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: Paul Collins @ 2008-08-02 12:03 UTC (permalink / raw)
To: linux-kernel, nfsv4, linuxppc-dev
I just got the oops below on a ppc32 NFS4 server. I was cross-compiling
Linux with an amd64 client at the time. The server is running Linus's
tree as of 94ad374a0751f40d25e22e036c37f7263569d24c, the client is
running 2.6.26.
The server's kernel was cross-compiled with gcc 4.2.4-3 and binutils
2.18.50.20080610-1, both built from the Debian sources following their
toolchain-building procedures.
Annoyingly, I can't kill two of the client processes:
1 11634 11634 977 ? -1 D 1000 0:00 make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- oldconfig vmlinux modules
1 23887 11634 977 ? -1 D 1000 0:00 [powerpc-linux-g]
Here's the oops. The instruction dump really was all Xes.
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
PowerMac
Modules linked in: snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_aoa_soundbus radeon drm b43 mac80211 cfg80211 pcmcia snd_pcm_oss snd_pcm snd_page_alloc yenta_socket rsrc_nonstatic pcmcia_core ssb uninorth_agp agpgart ehci_hcd ohci_hcd [last unloaded: snd_aoa_soundbus]
NIP: 00000000 LR: c0159a44 CTR: 00000000
REGS: c1d81c70 TRAP: 0400 Not tainted (2.6.27-rc1-00158-g643fbd8)
MSR: 40009032 <EE,ME,IR,DR> CR: 82002024 XER: 20000000
TASK = c1c7b210[2306] 'nfsd' THREAD: c1d80000
GPR00: c0159bcc c1d81d20 c1c7b210 82002044 c2e538d4 82002044 002e499d f92d835f
GPR08: 00000000 c2e55ac4 c2e55adc c1d81d50 82002024 00000000 018985fc 01898404
GPR16: 01898710 018c7894 c04b03f4 c04b03e0 c0173da0 c05f4e84 fffff000 00000001
GPR24: c00c05dc 00000000 82002044 00000000 c2e538d4 c2e538d4 c0437120 c1d81d20
NIP [00000000] 0x0
LR [c0159a44] find_acceptable_alias+0x44/0x108
Call Trace:
[c1d81d20] [c00cbab8] exportfs_d_alloc+0x40/0x70 (unreliable)
[c1d81d50] [c0159bcc] exportfs_decode_fh+0xc4/0x200
[c1d81e80] [c015d568] fh_verify+0x2e8/0x578
[c1d81ed0] [c016b1ec] nfsd4_putfh+0x60/0x78
[c1d81ef0] [c016afd0] nfsd4_proc_compound+0x1e4/0x34c
[c1d81f30] [c015a060] nfsd_dispatch+0xfc/0x220
[c1d81f50] [c0400c70] svc_process+0x3e4/0x6e8
[c1d81f90] [c015a8bc] nfsd+0x1c4/0x294
[c1d81fd0] [c0049e48] kthread+0x5c/0x9c
[c1d81ff0] [c00125c0] kernel_thread+0x44/0x60
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace 88de9451d0d3e759 ]---
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: Creating a wrapped zImage.initrd -- can't start the trampoline?
From: Josh Boyer @ 2008-08-02 12:35 UTC (permalink / raw)
To: paul; +Cc: Linuxppc-embedded
In-Reply-To: <1217644827.6390.12.camel@homebase.localnet>
On Fri, 2008-08-01 at 22:40 -0400, Paul Smith wrote:
> Hi all;
>
> I'm working with a PPC 460EX-based board. I have a 2.6.25.10-based
> kernel I obtained from the DENX git tree which contains a port to this
> board, under arch/powerpc.
>
> I can build a kernel and have it downloaded and booting using u-boot,
> providing the blob and appropriate kernel parameters, after having done
> a standard "make zImage" with the appropriate configs etc. All good so
> far.
>
> However, my ultimate target board uses a custom bootloader, not uboot,
> which is very, very simple (please don't suggest we just switch to
> uboot--that argument has been already had, and lost :-/) I had a
> previous version of Linux, 2.6.14, booting on a predecessor of this
> board based on the 440GX with the same bootloader, but the creation of
> that image was done under arch/ppc and it was pretty different (I'm
> discovering). And, I didn't do that port anyway.
>
> Anyway, I need to generate an all-in-one image containing the kernel and
> the initrd, and the trampoline code tacked onto it to turn it into an
> ELF image. I'm worried I'll need to write a custom platform_init() but
> for now I'm just using of.c.
It needs the vmlinux, dtb, and initrd in a single image. The dtb is
required for arch/powerpc ports.
> >From what I can tell, the wrapper script seems to be intended to have
> the ability to generate an image like this. I've tried just running
> "make zImage.initrd" after putting the ramdisk.initrd.gz in the right
> place, and it seems to create an image OK: using file shows it to be
> "ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV),
> statically linked, not stripped", which seems correct.
>
> But we can't get it to boot.
>
> The bootloader downloads the image (tftp) and jumps to the start address
> in the ELF image, and immediately takes an illegal instruction. We have
> set the bootloader to load the image at 0x00000000 and then we look
> through the ELF image for the start address, which (using objdump) I can
> see is the correct address for the _zimage_start symbol from crt0.S; in
> our case it's 0x00400204.
>
> When we use a debugger to look at what's loaded at that location, it's
> just a whole slew of 0xa bytes... obviously not right. Is the start
> address not the offset from the start of the ELF image? Should we be
> loading the image somewhere else (the previous incarnation loaded it at
> 0x0, so we just did that too)?
Load it at the link address. Which is 4MiB. A normal bootloader would
have done that. Then the wrapper code will uncompress your kernel to
0x0 for you.
josh
^ permalink raw reply
* Re: Creating a wrapped zImage.initrd -- can't start the trampoline?
From: Paul Smith @ 2008-08-02 12:55 UTC (permalink / raw)
To: jwboyer; +Cc: Linuxppc-embedded
In-Reply-To: <1217680550.2328.15.camel@localhost.localdomain>
On Sat, 2008-08-02 at 08:35 -0400, Josh Boyer wrote:
> It needs the vmlinux, dtb, and initrd in a single image. The dtb is
> required for arch/powerpc ports.
We have a dtb that we were using with uboot. We were hoping we could
continue to do that even with the trampoline: that is, get the dtb from
the bootloader, while leaving the kernel and initrd in the downloaded
image. We have coded up the bootloader to provide this information on
the command line and I was kind of hoping the trampoline would just pass
it through when it booted the uncompressed kernel.
It just seems to make more sense to have the dtb tied to the
hardware/firmware.
Is this possible? If not we can do it the other way around (I found the
right targets in the Linux build system for this, I think).
> > The bootloader downloads the image (tftp) and jumps to the start address
> > in the ELF image, and immediately takes an illegal instruction. We have
> > set the bootloader to load the image at 0x00000000 and then we look
> > through the ELF image for the start address, which (using objdump) I can
> > see is the correct address for the _zimage_start symbol from crt0.S; in
> > our case it's 0x00400204.
> >
> > When we use a debugger to look at what's loaded at that location, it's
> > just a whole slew of 0xa bytes... obviously not right. Is the start
> > address not the offset from the start of the ELF image? Should we be
> > loading the image somewhere else (the previous incarnation loaded it at
> > 0x0, so we just did that too)?
>
> Load it at the link address. Which is 4MiB. A normal bootloader would
> have done that. Then the wrapper code will uncompress your kernel to
> 0x0 for you.
Ah. OK, that's good info. We'll give that a go.
Thanks!
^ permalink raw reply
* Re: Compact flash on mpc8349eITX
From: Arnd Bergmann @ 2008-08-02 17:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sparks, Sam
In-Reply-To: <6011A7C9CD0EE74792C3ED2A835560863421AB@mail.twacs.com>
On Friday 01 August 2008, Sparks, Sam wrote:
> Has anyone successfully communicated with a compact flash device in true
> IDE mode on the MPC8349eITX? If so, do you happen to know the kernel
> configuration and/or revision?
>
There are some CF cards and some IDE-CF adapters that are missing the lines
for DMA mode, even if the controller on the card supports DMA.
If a specific card doesn't work, try using a different one, or use PIO mode
only.
Arnd <><
^ permalink raw reply
* Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: J. Bruce Fields @ 2008-08-02 18:45 UTC (permalink / raw)
To: linux-kernel, nfsv4, linuxppc-dev, Neil Brown
In-Reply-To: <87tze38vzt.fsf@burly.wgtn.ondioline.org>
On Sun, Aug 03, 2008 at 12:03:18AM +1200, Paul Collins wrote:
> I just got the oops below on a ppc32 NFS4 server. I was cross-compiling
> Linux with an amd64 client at the time. The server is running Linus's
> tree as of 94ad374a0751f40d25e22e036c37f7263569d24c, the client is
> running 2.6.26.
>
> The server's kernel was cross-compiled with gcc 4.2.4-3 and binutils
> 2.18.50.20080610-1, both built from the Debian sources following their
> toolchain-building procedures.
Without having really thought about this,
496d6c32d4d057cb44272d9bd587ff97d023ee92 "nfsd: fix spurious
EACCESS in reconnect_path()"
is one suspect; it might be worth checking whether the problem's
reproduceable with that reverted. But I assume we're not so lucky as to
have a 100% reproduceable problem here?
What do your export options look like?
--b.
>
> Annoyingly, I can't kill two of the client processes:
>
> 1 11634 11634 977 ? -1 D 1000 0:00 make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- oldconfig vmlinux modules
> 1 23887 11634 977 ? -1 D 1000 0:00 [powerpc-linux-g]
>
> Here's the oops. The instruction dump really was all Xes.
>
> Unable to handle kernel paging request for instruction fetch
> Faulting instruction address: 0x00000000
> Oops: Kernel access of bad area, sig: 11 [#1]
> PowerMac
> Modules linked in: snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_aoa_soundbus radeon drm b43 mac80211 cfg80211 pcmcia snd_pcm_oss snd_pcm snd_page_alloc yenta_socket rsrc_nonstatic pcmcia_core ssb uninorth_agp agpgart ehci_hcd ohci_hcd [last unloaded: snd_aoa_soundbus]
> NIP: 00000000 LR: c0159a44 CTR: 00000000
> REGS: c1d81c70 TRAP: 0400 Not tainted (2.6.27-rc1-00158-g643fbd8)
> MSR: 40009032 <EE,ME,IR,DR> CR: 82002024 XER: 20000000
> TASK = c1c7b210[2306] 'nfsd' THREAD: c1d80000
> GPR00: c0159bcc c1d81d20 c1c7b210 82002044 c2e538d4 82002044 002e499d f92d835f
> GPR08: 00000000 c2e55ac4 c2e55adc c1d81d50 82002024 00000000 018985fc 01898404
> GPR16: 01898710 018c7894 c04b03f4 c04b03e0 c0173da0 c05f4e84 fffff000 00000001
> GPR24: c00c05dc 00000000 82002044 00000000 c2e538d4 c2e538d4 c0437120 c1d81d20
> NIP [00000000] 0x0
> LR [c0159a44] find_acceptable_alias+0x44/0x108
> Call Trace:
> [c1d81d20] [c00cbab8] exportfs_d_alloc+0x40/0x70 (unreliable)
> [c1d81d50] [c0159bcc] exportfs_decode_fh+0xc4/0x200
> [c1d81e80] [c015d568] fh_verify+0x2e8/0x578
> [c1d81ed0] [c016b1ec] nfsd4_putfh+0x60/0x78
> [c1d81ef0] [c016afd0] nfsd4_proc_compound+0x1e4/0x34c
> [c1d81f30] [c015a060] nfsd_dispatch+0xfc/0x220
> [c1d81f50] [c0400c70] svc_process+0x3e4/0x6e8
> [c1d81f90] [c015a8bc] nfsd+0x1c4/0x294
> [c1d81fd0] [c0049e48] kthread+0x5c/0x9c
> [c1d81ff0] [c00125c0] kernel_thread+0x44/0x60
> Instruction dump:
> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
> ---[ end trace 88de9451d0d3e759 ]---
>
> --
> Paul Collins
> Wellington, New Zealand
>
> Dag vijandelijk luchtschip de huismeester is dood
> _______________________________________________
> NFSv4 mailing list
> NFSv4@linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: harihanv @ 2008-08-02 19:13 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <18647614.post@talk.nabble.com>
Hi,
I also want to allocate 4MB space for DMA from external device. if possible,
please let me know how did you overcome the problem of using mmap option
from the userspace
Regards
Harish
Misbah khan wrote:
>
>> printk(KERN_INFO"Allocated Memory for Circular Buffer at physical
>> 0x0%x\n",phy_addr);
>>
>> #else
>>
>> buf_area = ioremap(0xB2000000,0x4000); //(0xB2000000,0x4000);
>> //(7700000,900000);
>> if(!buf_area)
>> {
>> printk(KERN_ALERT"ioremap failed \n");
>> return -1;
>> } ...[show rest of quote]
> Don't hardcode the numbers here, you should get the values from the
> device tree, and use of_iomap().
>
> I am really unaware of how can we get this physical address from the
> device tree which you have mentioned can you please explain this to me ???
>
> Suppose there is one situation in which i have to map ram of the address
> 0x800000 to 9MB will it be good if i do this to map to user space
>
> static int McBSP_DriverMmap(struct file *file,struct vm_area_struct *vma)
> {
>
> unsigned long start = vma->vm_start ;
> unsigned long size = 0x900000 ;
> unsigned long phy_add = 0x800000;
> int ret = 0;
>
> /* Make the mmaped area noncacheable */
> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>
> /* Set the Flags to give permissions to Mmaped area */
> vma->vm_flags |=VM_RESERVED;
> vma->vm_flags |=VM_READ;
> vma->vm_flags |=VM_WRITE;
>
> printk(KERN_DEBUG"In mmap function\n");
>
> /* Mmap the kernel buffer to user space */
> if(remap_pfn_range(vma,start,(phy_add >>
> PAGE_SHIFT),size,vma->vm_page_prot))
> {
> printk(KERN_ALERT"remap_pfn_range failed\n");
> goto mmap_exit;
>
> }
>
> printk(KERN_ALERT"phy addr 0x%08X mmapped to virt addr 0x%08X, size =
> 0x%08X\n",
> (unsigned int)phy_add, (unsigned int)start, (unsigned int)size);
>
> /* Initialize the file operation structure of Mmaped area */
> vma->vm_ops=&mmap_op;
>
> /* Open the Mmaped area */
> MmapOpen(vma);
>
> mmap_exit:
> return ret;
> }
>
> suppose the same mapping i have to do using nopage method then shall i
> specify the RAM physical address and sixe in the same manner ???
>
>
> There is one more concern that i have now is that i am writing a pattern
> (say 0xa5a5a5a5) to cpld by building the page using remap_pfn_range but
> when i try to read it its showing the pattern as
> a5a5a5a50000000a5a5a5a50000000 like with zeros in between is it a non
> aligned page problem.
>
> ----- Misbah <><
>
> Arnd Bergmann wrote:
>>
>> On Thursday 24 July 2008, Misbah khan wrote:
>>>
>>> Hi all ...
>>>
>>> I am uploading the source code which is doing the following :-
>>>
>>> 1. mapping cpld register using ioremap coping the data to circular
>>> buffer
>>> and remapping it to user space .
>>>
>>> 2. It can also map kernel virtual dma memory to user space if compiled
>>> conditionally .
>>>
>>> following is the problem which i am facing ...
>>>
>>> 1. It is somitimes giving following kernel panic ....
>>>
>>> nable to handle kernel NULL pointer dereference at virtual address
>>> 00000000
>>> pgd = c0004000
>>> [00000000] *pgd=00000000
>>> Internal error: Oops: 17 [#1]
>>> Modules linked in: fluke_driver tstamp sig_router mvci_spi mvci_sf_pcd
>>> mvci_sci_unidir_s1 mvci_sci_diff mvci_sci_bidir_s
>>> 1 mvci_rtmd_s1 mvci_kwiso_s1 mvci_kw1281_s1 mvci_kh_s1 mvci_j1850
>>> mvci_gm_sbc mvci_diagh_s1 g_ether mvci_dcl mvci_can1 f
>>> pga_conf arcotg_udc adc_dac keypad(F) splc501_lcd(F) cpld
>>> CPU: 0
>>> PC is at cascade+0x64/0x8c
>>> LR is at __init_begin+0x3fff8000/0x30
>>> pc : [<c00484ac>] lr : [<00000000>] Tainted: GF
>>> sp : c0293ea8 ip : 0040b000 fp : c0293ecc
>>> r10: 8001d9f0 r9 : c0292000 r8 : 00000001
>>> r7 : c0292000 r6 : 0000000c r5 : c02fa048 r4 : 00000000
>>> r3 : c02fa2f8 r2 : 0000261a r1 : bf01ab70 r0 : c02fa2f8
>>> Flags: Nzcv IRQs off FIQs on Mode SVC_32 Segment kernel
>>> Control: C5387F
>>> Table: 8698C000 DAC: 00000017
>>> Process swapper (pid: 0, stack limit = 0xc0292250)
>>> Stack: (0xc0293ea8 to 0xc0294000)
>>> 3ea0: bf01ab70 c02fb440 0000000a 00000000 c02fa048
>>> 0000000a
>>> 3ec0: c0293efc c0293ed0 c0048810 c0048454 c0293eec c0293ee0 c002a30c
>>> 00000001
>>> 3ee0: c02f9e44 0000000a 00000002 00000001 c0293f1c c0293f00 c00442a0
>>> c0048794
>>> 3f00: c0293f2c 0000001d c0294740 00000000 c0293f2c c0293f20 c00446d4
>>> c0044254
>>> 3f20: c0293f4c c0293f30 c00217b0 c0044698 c0293f5c ffffffff 0000ffff
>>> 00000001
>>> 3f40: c0293fa4 c0293f50 c00209e4 c0021770 00000001 00000001 c0292000
>>> 00000000
>>> 3f60: c0022068 c0292000 c0298c44 c03121c0 8001da24 4107b364 8001d9f0
>>> c0293fa4
>>> 3f80: c0293fa8 c0293f98 c0021d48 c002209c 60000013 ffffffff c0293fbc
>>> c0293fa8
>>> 3fa0: c0021d48 c0022074 c02faae0 c02f292c c0293fcc c0293fc0 c00202e0
>>> c0021d24
>>> 3fc0: c0293ff4 c0293fd0 c0008848 c00202b4 c00083c4 00000000 00000000
>>> c02f29a8
>>> 3fe0: 00000000 00c5387d 00000000 c0293ff8 80008030 c00086e0 00000000
>>> 00000000
>>> Backtrace:
>>> [<c0048448>] (cascade+0x0/0x8c) from [<c0048810>]
>>> (run_timer_softirq+0x88/0x1e8)
>>> r6 = 0000000A r5 = C02FA048 r4 = 00000000
>>> [<c0048788>] (run_timer_softirq+0x0/0x1e8) from [<c00442a0>]
>>> (__do_softirq+0x58/0xc8)
>>> r8 = 00000001 r7 = 00000002 r6 = 0000000A r5 = C02F9E44
>>> r4 = 00000001
>>> [<c0044248>] (__do_softirq+0x0/0xc8) from [<c00446d4>]
>>> (irq_exit+0x48/0x5c)
>>> r6 = 00000000 r5 = C0294740 r4 = 0000001D
>>> [<c004468c>] (irq_exit+0x0/0x5c) from [<c00217b0>]
>>> (asm_do_IRQ+0x4c/0x64)
>>> [<c0021764>] (asm_do_IRQ+0x0/0x64) from [<c00209e4>]
>>> (__irq_svc+0x44/0x80)
>>> r6 = 00000001 r5 = 0000FFFF r4 = FFFFFFFF
>>> [<c0022068>] (default_idle+0x0/0x3c) from [<c0021d48>]
>>> (cpu_idle+0x30/0x5c)
>>> [<c0021d18>] (cpu_idle+0x0/0x5c) from [<c00202e0>] (rest_init+0x38/0x40)
>>> r5 = C02F292C r4 = C02FAAE0
>>> [<c00202a8>] (rest_init+0x0/0x40) from [<c0008848>]
>>> (start_kernel+0x174/0x1c0)
>>> [<c00086d4>] (start_kernel+0x0/0x1c0) from [<80008030>] (0x80008030)
>>> Code: e1530005 15822000 ebffffb6 e1a0e004 (e5944000)
>>> <0>Kernel panic - not syncing: Aiee, killing interrupt handler!
>>>
>>>
>>> also when i run it on X86 PC i am able to get the data and no panic
>>> where in
>>> on the board it is giving the above error ....
>>>
>>> 2. I can raed the data using the user application when i run it on X86
>>> PC
>>> where in i cant able to read the data when i run it on the board the
>>> data i
>>> was getting was always '/0' filled buffer .
>>>
>>>
>>> Here is the compilete code .............
>>>
>>>
>>> static int McBSP_DriverOpen(struct inode *inode,struct file *file)
>>> {
>>> /* Reintialize file operation structure */
>>> file->f_op=&fluke_fops;
>>>
>>
>> this is already set.
>>
>>> printk(KERN_DEBUG" fluke driver open success \n");
>>>
>>> if (device_open_count == 0)
>>> {
>>> device_open_count = 1;
>>>
>>> /* Reset the read and write index*/
>>> buf_index_area.write_index=0;
>>> buf_index_area.read_index=-1;
>>> buf_index_area.count_index=0;
>>>
>>> #ifdef SIMULATION
>>> /* Initialize the Timer */
>>> init_timer(&fluke_timer);
>>> fluke_timer.expires = jiffies + (HZ*10);//Timer will Expire after 60
>>> sec
>>> fluke_timer.data = 0;
>>> fluke_timer.function = (void *)timer_func;
>>> add_timer(&fluke_timer);
>>> #endif
>>> }
>>>
>>> return 0;
>>> }
>>
>> Using the count in this way is racy, best write the code so
>> that it can allow multiple opens.
>>
>>> irqreturn_t DataAcqIntHandler(int irq,void *dev_id, struct pt_regs
>>> *regs)
>>> {
>>> printk(KERN_ALERT" In Interrupt Handler\n");
>>> /* Data present status is set to wake up the read call */
>>> data_present_status=1;
>>>
>>> /* Wake up the blocked Select call */
>>> wake_up_interruptible(&wait_queue);
>>>
>>> #ifndef SIMULATION
>>> /* Clear the interrupt in the interrupt pending registor */
>>> cpi->ic_scprrh |=DATA_ACQ_INT_CLEAR;
>>> #endif
>>>
>>> return IRQ_HANDLED;
>>>
>>> }/* End of PpsIntrHandler() */
>>
>> The interrupt handler should be able to deal with shared interrupts,
>> and needs to check if the interrupt came from this device, returning
>> IRQ_NONE otherwise.
>>
>>> static int __init McBSP_DriverInit(void)
>>> {
>>> unsigned int virt_addr = 0;
>>> int mem = 0;
>>>
>>> //buf_area = vmalloc(sizeof(circularbuffer_S));
>>> //if(!buf_area)
>>> //{
>>> // printk(KERN_ALERT"vmalloc failed \n");
>>> // return -1;
>>> //}
>>>
>>> #if 0
>>> /*
>>> * Allocate memory for the circular buffer in the DMA coherent area
>>> * and algin it in the Cache
>>> */
>>> mem = L1_CACHE_ALIGN(sizeof(circularbuffer_S));
>>>
>>> buf_ptr = (char *)dma_alloc_coherent(NULL, mem, &dma_addr,GFP_KERNEL);
>>
>> no need for the cast.
>>
>>> printk(KERN_INFO" buf_ptr = 0x%x \n",(int )buf_ptr);
>>> if(NULL == buf_ptr )
>>> {
>>> printk(KERN_ALERT" Allocation of Memory failure ");
>>> return -1;
>>> }
>>>
>>> buf_area = (circularbuffer_S *)(((unsigned int )buf_ptr + PAGE_SIZE -
>>> 1) \
>>> & PAGE_MASK);
>>>
>>> printk(KERN_INFO" buf_area = 0x%x \n",(int )buf_area);
>>>
>>> if(NULL == buf_area)
>>> {
>>> printk(KERN_ALERT" Circular buffer memory not allocated \n");
>>> return -1;
>>> }
>>>
>>> /* Marking the Pages as reserved */
>>> for (virt_addr = (unsigned int)buf_area; \
>>> virt_addr < (unsigned int )buf_area + sizeof(circularbuffer_S);\
>>> virt_addr += PAGE_SIZE)
>>> {
>>> /* Set the pages as reserved */
>>> SetPageReserved(virt_to_page(virt_addr));
>>> //mem_map_reserve(virt_to_page(virt_addr));
>>> }
>>
>> no need for SetPageReserved, it already is marked as in use through
>> the allocation.
>>
>>> phy_addr = virt_to_phys(buf_ptr);
>>
>> You can't use virt_to_phys to get the dma address. You also don't need
>> that
>> because you already have it in dma_addr.
>>
>>
>>> printk(KERN_INFO"Allocated Memory for Circular Buffer at physical
>>> 0x0%x\n",phy_addr);
>>>
>>> #else
>>>
>>> buf_area = ioremap(0xB2000000,0x4000); //(0xB2000000,0x4000);
>>> //(7700000,900000);
>>> if(!buf_area)
>>> {
>>> printk(KERN_ALERT"ioremap failed \n");
>>> return -1;
>>> }
>>
>> Don't hardcode the numbers here, you should get the values from the
>> device tree, and use of_iomap().
>>
>>> printk(" Ioremap mapped to virtual 0x0%x \n",buf_area);
>>> *((unsigned int *)buf_area) = 0xa5a5a5a5;
>>> printk(" Ioremap data 0x0%x \n",*((unsigned int *)buf_area + 0));
>>>
>>> #endif
>>>
>>> /* Device major number is registered to set the driver entry point */
>>> if(register_chrdev(MAJOR_NO,MODULE_NAME, &fluke_fops)==0)
>>> {
>>> printk(KERN_DEBUG" Fluke driver registeration success \n");
>>>
>>> }
>>> else
>>> {
>>> printk(KERN_ALERT" Fluke driver registeration failed \n");
>>> return -1;
>>> }
>>
>> Since it's just one device, it's easier to use a misc_device.
>>
>>> /*
>>> * Register Data Acq interrupt request with specified irq and install
>>> the
>>> * handler
>>> */
>>> if(request_irq(DATA_ACQ_INT,(void *)DataAcqIntHandler, SA_INTERRUPT,
>>> MODULE_NAME, NULL)==0)
>>> {
>>> printk(KERN_DEBUG" Data Acq interrupt request returns success \n");
>>> }
>>> else
>>> {
>>> printk(KERN_DEBUG" Data Acq interrupt request failed \n");
>>> unregister_chrdev(MAJOR_NO,MODULE_NAME);
>>> return -1;
>>>
>>> }
>>
>> hardcoding interrupt numbers is broken, interrupt numbers are relative to
>> one interrupt controller. Use irq_of_parse_and_map.
>>
>>> static int McBSP_DriverIoctl(struct inode *inode, struct file *file,\
>>> unsigned int cmd, unsigned long param)
>>> {
>>> int i;
>>> daq_t daq_param;
>>>
>>> printk(KERN_DEBUG"In ioctl command \n");
>>>
>>> switch(cmd)
>>> {
>>> case START_ACQ_DATA:
>>>
>>> if(copy_from_user(&daq_param,(void *)param,sizeof(daq_param)))
>>> {
>>>
>>> return -1;
>>> }
>>>
>>> /* For Simulation we are writing the data */
>>> if(WriteBuf() < 0)
>>> {
>>> printk(" Writing to the memory failure \n");
>>> return -1;
>>> }
>>>
>>> /* Wait for the Interrupt to occur */
>>> wait_event_interruptible( wait_queue, data_present_status !=0);
>>>
>>> printk("Read Index before read %d\n",buf_index_area.read_index);
>>> data_present_status=0;
>>
>> Racy, you could have multiple threads doing this ioctl.
>> Moreover, you should not block in an ioctl but rather
>> implement a poll() function for waiting.
>>
>>> buf_index_area.read_index++;
>>> buf_index_area.read_index%=NO_FRAMES;
>>>
>>> if(buf_index_area.read_index ==((buf_index_area.write_index +1) %
>>> NO_FRAMES))
>>> //if(buf_index_area.read_index == buf_index_area.write_index )
>>> {
>>> printk("Read failure because read and write index are same\n");
>>> return -1;
>>> }
>>>
>>> /* Decrement the count index to indicate the data availibility */
>>> down(&mutex);
>>> buf_index_area.count_index--;
>>> up(&mutex);
>>
>> New drivers should not use semaphores (up/down) in places where they can
>> use real
>> mutexes (mutex_lock/mutex_unlock).
>>
>>> static int McBSP_DriverMmap(struct file *file,struct vm_area_struct
>>> *vma)
>>> {
>>>
>>> unsigned long start = vma->vm_start;
>>> unsigned long size = vma->vm_end - vma->vm_start; //0x900000;
>>> unsigned long phy_add = virt_to_phys(buf_ptr); //0x7700000;
>>
>> virt_to_phys doesn't work on vmalloc memory.
>>
>>
>>> int ret = 0;
>>>
>>> /* Make the mmaped area noncacheable */
>>> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>>>
>>> /* Set the Flags to give permissions to Mmaped area */
>>> vma->vm_flags |=VM_RESERVED;
>>> vma->vm_flags |=VM_READ;
>>> vma->vm_flags |=VM_WRITE;
>>> vma->vm_flags |=VM_IO;
>>> //vma->vm_flags |=VM_SHARED;
>>> //vma->vm_flags |=VM_LOCKED;
>>
>> For memory, you typically want to set vm_page_prot to use non-guarded
>> mapping,
>> so that user space accesses are faster.
>>
>> Not sure if VM_IO is right for vmalloc.
>>
>> Arnd <><
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
>
--
View this message in context: http://www.nabble.com/how-to-allocate-9MB-of-memory-in-kernel---tp18503022p18792322.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: Paul Collins @ 2008-08-02 22:36 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Neil Brown, linuxppc-dev, nfsv4, linux-kernel
In-Reply-To: <20080802184554.GB715@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Sun, Aug 03, 2008 at 12:03:18AM +1200, Paul Collins wrote:
>> I just got the oops below on a ppc32 NFS4 server. I was cross-compiling
>> Linux with an amd64 client at the time. The server is running Linus's
>> tree as of 94ad374a0751f40d25e22e036c37f7263569d24c, the client is
>> running 2.6.26.
>>
>> The server's kernel was cross-compiled with gcc 4.2.4-3 and binutils
>> 2.18.50.20080610-1, both built from the Debian sources following their
>> toolchain-building procedures.
>
> Without having really thought about this,
>
> 496d6c32d4d057cb44272d9bd587ff97d023ee92 "nfsd: fix spurious
> EACCESS in reconnect_path()"
>
> is one suspect; it might be worth checking whether the problem's
> reproduceable with that reverted. But I assume we're not so lucky as to
> have a 100% reproduceable problem here?
Unknown. I've kicked off a fresh build. Here's hoping!
> What do your export options look like?
$ cat /etc/exports
/srv/nfsv4 *(sec=krb5:krb5i:krb5p,rw,fsid=0,crossmnt,insecure,no_subtree_check)
/srv/nfsv4/home/paul *(sec=krb5:krb5i:krb5p,rw,insecure,no_subtree_check)
$ mount | grep bind
/home/paul on /srv/nfsv4/home/paul type none (rw,bind)
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: [PATCH v3 0/4 REPOST] OF infrastructure for SPI devices
From: Jon Smirl @ 2008-08-02 22:46 UTC (permalink / raw)
To: Grant Likely, Anton Vorontsov
Cc: spi-devel-general, linux-kernel, linuxppc-dev
In-Reply-To: <9e4733910807250746g436307d7sbbf799b73a9f2c67@mail.gmail.com>
On 7/25/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 7/25/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> > I don't know what to do with these patches. I'd really like to see them
> > in .27, and now that akpm has cleared his queue, the prerequisite patch
> > has been merged so they are ready to go in. However, even though there
> > has been favourable reception on the SPI and linuxppc lists for these
> > changes I don't have any acks from anybody yet.
>
>
> I have compatible hardware but it has an MMC card socket hooked up. I
> haven't figured out yet how to get this driver hooked to the MMC
> subsystem and make the file system on the card work. (I've been
> working on ALSA).
>
> I believe I need this:
> http://lkml.org/lkml/2008/6/5/209
>
> Then I need to get everything hooked together. Point me in the right
> direction and I can help with testing.
Grant, your SPI driver works with MMC cards. I needed to add the patch
noted above.
http://lkml.org/lkml/2008/6/5/209
What's the status of merging Anton's patch?
And then tweak names until everything matches.
spi@f00 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
reg = <0xf00 0x20>;
interrupts = <0x2 0xd 0x0 0x2 0xe 0x0>;
interrupt-parent = <&mpc5200_pic>;
mmc-slot@0 {
compatible = "linux,mmc-spi";
reg = <0>;
spi-max-frequency = <20000000>;
/* Unregulated slot. */
voltage-range = <3300 3300>;
/*gpios = <&sdcsr_pio 1 0 /* WP */
/* &sdcsr_pio 0 1>; /* nCD */
};
};
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index 7503b81..eb056b9 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -1400,7 +1400,7 @@ static int __devexit mmc_spi_remove(struct
spi_device *spi)
static struct spi_driver mmc_spi_driver = {
.driver = {
- .name = "mmc_spi",
+ .name = "mmc-spi",
.bus = &spi_bus_type,
.owner = THIS_MODULE,
},
diff --git a/drivers/of/of_mmc_spi.c b/drivers/of/of_mmc_spi.c
index aa4e017..f189cdb 100644
--- a/drivers/of/of_mmc_spi.c
+++ b/drivers/of/of_mmc_spi.c
@@ -95,7 +95,7 @@ static int of_mmc_spi_add(struct device *dev)
const u32 *voltage_range;
int size;
- if (!np || !of_device_is_compatible(np, "mmc-spi"))
+ if (!np || !of_device_is_compatible(np, "linux,mmc-spi"))
return NOTIFY_DONE;
oms = kzalloc(sizeof(*oms), GFP_KERNEL);
@@ -152,7 +152,7 @@ static int of_mmc_spi_del(struct device *dev)
struct device_node *np = dev->archdata.of_node;
struct of_mmc_spi *oms;
- if (!np || !of_device_is_compatible(np, "mmc-spi") ||
+ if (!np || !of_device_is_compatible(np, "linux,mmc-spi") ||
!dev->platform_data)
return NOTIFY_DONE;
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: Paul Collins @ 2008-08-03 6:47 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: neilb, linuxppc-dev, nfsv4, linux-kernel
In-Reply-To: <87abfvm4cc.fsf@burly.wgtn.ondioline.org>
Paul Collins <paul@burly.ondioline.org> writes:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
>> On Sun, Aug 03, 2008 at 12:03:18AM +1200, Paul Collins wrote:
>>> I just got the oops below on a ppc32 NFS4 server. I was cross-compiling
>>> Linux with an amd64 client at the time. The server is running Linus's
>>> tree as of 94ad374a0751f40d25e22e036c37f7263569d24c, the client is
>>> running 2.6.26.
>>>
>>> The server's kernel was cross-compiled with gcc 4.2.4-3 and binutils
>>> 2.18.50.20080610-1, both built from the Debian sources following their
>>> toolchain-building procedures.
>>
>> Without having really thought about this,
>>
>> 496d6c32d4d057cb44272d9bd587ff97d023ee92 "nfsd: fix spurious
>> EACCESS in reconnect_path()"
>>
>> is one suspect; it might be worth checking whether the problem's
>> reproduceable with that reverted. But I assume we're not so lucky as to
>> have a 100% reproduceable problem here?
>
> Unknown. I've kicked off a fresh build. Here's hoping!
I can trigger it reliably with a 2.6.26 client. I've also triggered it
with 496d6c32d4d057cb44272d9bd587ff97d023ee92 reverted on the server.
It's harder to trigger with 2.6.27-rc1+ but I managed to get an Oops
on the fourth build after three successful builds on the NFS4 mount.
One of the Oopses I got with 2.6.26 had a slightly different call trace:
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
PowerMac
Modules linked in: radeon drm snd_aoa_codec_tas snd_aoa_fabric_layout b43 mac80211 snd_aoa cfg80211 pcmcia snd_aoa_i2sbus snd_pcm_oss snd_pcm snd_page_alloc snd_aoa_soundbus yenta_socket rsrc_nonstatic pcmcia_core ssb uninorth_agp agpgart ehci_hcd ohci_hcd
NIP: 00000000 LR: c0159bb0 CTR: 00000000
REGS: c1f79ca0 TRAP: 0400 Not tainted (2.6.27-rc1-00158-g643fbd8)
MSR: 40009032 <EE,ME,IR,DR> CR: 22002022 XER: 20000000
TASK = c1ca5440[2321] 'nfsd' THREAD: c1f78000
GPR00: 00000008 c1f79d50 c1ca5440 82002044 edda2c54 002d6642 002d6642 e05f26bc
GPR08: ee126e60 00000000 eed7a600 c1f79d50 00000007 00000000 018985fc 01898404
GPR16: 01898710 018c7894 c04b03f4 c04b03e0 c0173da0 c05f4e84 fffff000 00000001
GPR24: c00c05dc 00000000 82002044 ef80cca0 edda2c54 ee10d020 c0437120 c1f79d50
NIP [00000000] 0x0
LR [c0159bb0] exportfs_decode_fh+0xa8/0x200
Call Trace:
[c1f79d50] [c0159b54] exportfs_decode_fh+0x4c/0x200 (unreliable)
[c1f79e80] [c015d568] fh_verify+0x2e8/0x578
[c1f79ed0] [c016b1ec] nfsd4_putfh+0x60/0x78
[c1f79ef0] [c016afd0] nfsd4_proc_compound+0x1e4/0x34c
[c1f79f30] [c015a060] nfsd_dispatch+0xfc/0x220
[c1f79f50] [c0400c70] svc_process+0x3e4/0x6e8
[c1f79f90] [c015a8bc] nfsd+0x1c4/0x294
[c1f79fd0] [c0049e48] kthread+0x5c/0x9c
[c1f79ff0] [c00125c0] kernel_thread+0x44/0x60
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace 3dfa6e448b5c7077 ]---
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: Neil Brown @ 2008-08-03 12:09 UTC (permalink / raw)
To: Paul Collins; +Cc: J. Bruce Fields, linuxppc-dev, nfsv4, linux-kernel
In-Reply-To: <877iayy4qc.fsf@burly.wgtn.ondioline.org>
On Sunday August 3, paul@burly.ondioline.org wrote:
>
> I can trigger it reliably with a 2.6.26 client. I've also triggered it
> with 496d6c32d4d057cb44272d9bd587ff97d023ee92 reverted on the server.
>
> It's harder to trigger with 2.6.27-rc1+ but I managed to get an Oops
> on the fourth build after three successful builds on the NFS4 mount.
>
> One of the Oopses I got with 2.6.26 had a slightly different call trace:
>
> Unable to handle kernel paging request for instruction fetch
> Faulting instruction address: 0x00000000
So we have called a function pointer which was NULL.
There a lots of function pointers in use in this code.
There is the 'acceptable' function. There is ->fh_to_dentry
and ->fh_to_parent. And various inode operations line ->lookup, but
that is a bit further away.
> NIP [00000000] 0x0
> LR [c0159bb0] exportfs_decode_fh+0xa8/0x200
I guess this is where the call came from.
exportfs_decode_fh is never passed NULL for 'acceptable'. Only
ever 'nfsd_acceptable'.
->fh_to_parent is tested for NULL before being called, and
->fh_to_dentry is called very early in exportfs_decode_fh, where as
the bad call is 0xa8 in to the function.
Is it possible that ->fh_to_parent is being changed immediately after
being tested for NULL and before being dereferenced. That seems
unlikely.
What filesystem is being exported here?
Can you get an assembly version of exportfs_decode_fh, so we can check
what is happening at 0xa8 (and 0x4c).
Either "disassemble exportfs_decode_fh" in gdb, or
make fs/exportfs/expfs.i
(I think).
NeilBrown
> Call Trace:
> [c1f79d50] [c0159b54] exportfs_decode_fh+0x4c/0x200 (unreliable)
> [c1f79e80] [c015d568] fh_verify+0x2e8/0x578
> [c1f79ed0] [c016b1ec] nfsd4_putfh+0x60/0x78
> [c1f79ef0] [c016afd0] nfsd4_proc_compound+0x1e4/0x34c
> [c1f79f30] [c015a060] nfsd_dispatch+0xfc/0x220
> [c1f79f50] [c0400c70] svc_process+0x3e4/0x6e8
> [c1f79f90] [c015a8bc] nfsd+0x1c4/0x294
> [c1f79fd0] [c0049e48] kthread+0x5c/0x9c
> [c1f79ff0] [c00125c0] kernel_thread+0x44/0x60
^ permalink raw reply
* Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: Paul Collins @ 2008-08-03 12:25 UTC (permalink / raw)
To: Neil Brown; +Cc: J. Bruce Fields, linuxppc-dev, nfsv4, linux-kernel
In-Reply-To: <18581.40960.737792.454035@notabene.brown>
Neil Brown <neilb@suse.de> writes:
> On Sunday August 3, paul@burly.ondioline.org wrote:
>>
>> I can trigger it reliably with a 2.6.26 client. I've also triggered it
>> with 496d6c32d4d057cb44272d9bd587ff97d023ee92 reverted on the server.
>>
>> It's harder to trigger with 2.6.27-rc1+ but I managed to get an Oops
>> on the fourth build after three successful builds on the NFS4 mount.
>>
>> One of the Oopses I got with 2.6.26 had a slightly different call trace:
>>
>> Unable to handle kernel paging request for instruction fetch
>> Faulting instruction address: 0x00000000
>
> So we have called a function pointer which was NULL.
>
> There a lots of function pointers in use in this code.
> There is the 'acceptable' function. There is ->fh_to_dentry
> and ->fh_to_parent. And various inode operations line ->lookup, but
> that is a bit further away.
>
>> NIP [00000000] 0x0
>> LR [c0159bb0] exportfs_decode_fh+0xa8/0x200
>
> I guess this is where the call came from.
> exportfs_decode_fh is never passed NULL for 'acceptable'. Only
> ever 'nfsd_acceptable'.
> ->fh_to_parent is tested for NULL before being called, and
> ->fh_to_dentry is called very early in exportfs_decode_fh, where as
> the bad call is 0xa8 in to the function.
>
> Is it possible that ->fh_to_parent is being changed immediately after
> being tested for NULL and before being dereferenced. That seems
> unlikely.
>
> What filesystem is being exported here?
Boring old ext3 (on LVM, on dm-crypt).
> Can you get an assembly version of exportfs_decode_fh, so we can check
> what is happening at 0xa8 (and 0x4c).
Dump of assembler code for function exportfs_decode_fh:
0xc015b7cc <exportfs_decode_fh+0>: mflr r0
0xc015b7d0 <exportfs_decode_fh+4>: stw r0,4(r1)
0xc015b7d4 <exportfs_decode_fh+8>: bl 0xc0013154 <_mcount>
0xc015b7d8 <exportfs_decode_fh+12>: stwu r1,-304(r1)
0xc015b7dc <exportfs_decode_fh+16>: mflr r0
0xc015b7e0 <exportfs_decode_fh+20>: stmw r22,264(r1)
0xc015b7e4 <exportfs_decode_fh+24>: mr r27,r3
0xc015b7e8 <exportfs_decode_fh+28>: mr r31,r1
0xc015b7ec <exportfs_decode_fh+32>: stw r0,308(r1)
0xc015b7f0 <exportfs_decode_fh+36>: mr r25,r7
0xc015b7f4 <exportfs_decode_fh+40>: mr r26,r8
0xc015b7f8 <exportfs_decode_fh+44>: mr r29,r4
0xc015b7fc <exportfs_decode_fh+48>: mr r24,r5
0xc015b800 <exportfs_decode_fh+52>: mr r23,r6
0xc015b804 <exportfs_decode_fh+56>: lwz r3,20(r3)
0xc015b808 <exportfs_decode_fh+60>: lwz r30,48(r3)
0xc015b80c <exportfs_decode_fh+64>: lwz r0,4(r30)
0xc015b810 <exportfs_decode_fh+68>: mtctr r0
0xc015b814 <exportfs_decode_fh+72>: bctrl
0xc015b818 <exportfs_decode_fh+76>: mr. r28,r3
0xc015b81c <exportfs_decode_fh+80>: bne+ 0xc015b824 <exportfs_decode_fh+88>
0xc015b820 <exportfs_decode_fh+84>: li r28,-116
0xc015b824 <exportfs_decode_fh+88>: li r22,-4096
0xc015b828 <exportfs_decode_fh+92>: cmplw cr7,r28,r22
0xc015b82c <exportfs_decode_fh+96>: bgt- cr7,0xc015b9b0 <exportfs_decode_fh+484>
0xc015b830 <exportfs_decode_fh+100>: lwz r9,8(r28)
0xc015b834 <exportfs_decode_fh+104>: lhz r0,114(r9)
0xc015b838 <exportfs_decode_fh+108>: rlwinm r0,r0,0,16,19
0xc015b83c <exportfs_decode_fh+112>: cmpwi cr7,r0,16384
0xc015b840 <exportfs_decode_fh+116>: bne- cr7,0xc015b880 <exportfs_decode_fh+180>
0xc015b844 <exportfs_decode_fh+120>: lwz r0,4(r28)
0xc015b848 <exportfs_decode_fh+124>: andi. r9,r0,4
0xc015b84c <exportfs_decode_fh+128>: beq- 0xc015b864 <exportfs_decode_fh+152>
0xc015b850 <exportfs_decode_fh+132>: mr r3,r27
0xc015b854 <exportfs_decode_fh+136>: mr r4,r28
0xc015b858 <exportfs_decode_fh+140>: bl 0xc015b45c <reconnect_path>
0xc015b85c <exportfs_decode_fh+144>: mr. r30,r3
0xc015b860 <exportfs_decode_fh+148>: bne- 0xc015b9a4 <exportfs_decode_fh+472>
0xc015b864 <exportfs_decode_fh+152>: mr r3,r26
0xc015b868 <exportfs_decode_fh+156>: mr r4,r28
0xc015b86c <exportfs_decode_fh+160>: mtctr r25
0xc015b870 <exportfs_decode_fh+164>: bctrl
0xc015b874 <exportfs_decode_fh+168>: cmpwi cr7,r3,0
0xc015b878 <exportfs_decode_fh+172>: beq+ cr7,0xc015b998 <exportfs_decode_fh+460>
0xc015b87c <exportfs_decode_fh+176>: b 0xc015b9b0 <exportfs_decode_fh+484>
0xc015b880 <exportfs_decode_fh+180>: mr r3,r28
0xc015b884 <exportfs_decode_fh+184>: mr r4,r25
0xc015b888 <exportfs_decode_fh+188>: mr r5,r26
0xc015b88c <exportfs_decode_fh+192>: bl 0xc015b6c4 <find_acceptable_alias>
0xc015b890 <exportfs_decode_fh+196>: cmpwi r3,0
0xc015b894 <exportfs_decode_fh+200>: bne+ 0xc015b990 <exportfs_decode_fh+452>
0xc015b898 <exportfs_decode_fh+204>: lwz r0,8(r30)
0xc015b89c <exportfs_decode_fh+208>: cmpwi cr7,r0,0
0xc015b8a0 <exportfs_decode_fh+212>: beq- cr7,0xc015b9a0 <exportfs_decode_fh+468>
0xc015b8a4 <exportfs_decode_fh+216>: mr r4,r29
0xc015b8a8 <exportfs_decode_fh+220>: mr r5,r24
0xc015b8ac <exportfs_decode_fh+224>: lwz r3,20(r27)
0xc015b8b0 <exportfs_decode_fh+228>: mtctr r0
0xc015b8b4 <exportfs_decode_fh+232>: mr r6,r23
0xc015b8b8 <exportfs_decode_fh+236>: bctrl
0xc015b8bc <exportfs_decode_fh+240>: mr. r29,r3
0xc015b8c0 <exportfs_decode_fh+244>: beq- 0xc015b9a0 <exportfs_decode_fh+468>
0xc015b8c4 <exportfs_decode_fh+248>: cmplw cr7,r29,r22
0xc015b8c8 <exportfs_decode_fh+252>: mr r30,r29
0xc015b8cc <exportfs_decode_fh+256>: bgt- cr7,0xc015b9a4 <exportfs_decode_fh+472>
0xc015b8d0 <exportfs_decode_fh+260>: mr r3,r27
0xc015b8d4 <exportfs_decode_fh+264>: mr r4,r29
0xc015b8d8 <exportfs_decode_fh+268>: bl 0xc015b45c <reconnect_path>
0xc015b8dc <exportfs_decode_fh+272>: mr. r30,r3
0xc015b8e0 <exportfs_decode_fh+276>: beq- 0xc015b8f0 <exportfs_decode_fh+292>
0xc015b8e4 <exportfs_decode_fh+280>: mr r3,r29
0xc015b8e8 <exportfs_decode_fh+284>: bl 0xc00befb0 <dput>
0xc015b8ec <exportfs_decode_fh+288>: b 0xc015b9a4 <exportfs_decode_fh+472>
0xc015b8f0 <exportfs_decode_fh+292>: addi r30,r31,8
0xc015b8f4 <exportfs_decode_fh+296>: mr r3,r27
0xc015b8f8 <exportfs_decode_fh+300>: mr r4,r29
0xc015b8fc <exportfs_decode_fh+304>: mr r5,r30
0xc015b900 <exportfs_decode_fh+308>: mr r6,r28
0xc015b904 <exportfs_decode_fh+312>: bl 0xc015b2cc <exportfs_get_name>
0xc015b908 <exportfs_decode_fh+316>: cmpwi cr7,r3,0
0xc015b90c <exportfs_decode_fh+320>: bne+ cr7,0xc015b970 <exportfs_decode_fh+420>
0xc015b910 <exportfs_decode_fh+324>: lwz r3,8(r29)
0xc015b914 <exportfs_decode_fh+328>: addi r3,r3,116
0xc015b918 <exportfs_decode_fh+332>: bl 0xc0421bb0 <mutex_lock>
0xc015b91c <exportfs_decode_fh+336>: mr r3,r30
0xc015b920 <exportfs_decode_fh+340>: bl 0xc00188fc <strlen>
0xc015b924 <exportfs_decode_fh+344>: mr r4,r29
0xc015b928 <exportfs_decode_fh+348>: mr r5,r3
0xc015b92c <exportfs_decode_fh+352>: mr r3,r30
0xc015b930 <exportfs_decode_fh+356>: bl 0xc00b4e44 <lookup_one_len>
0xc015b934 <exportfs_decode_fh+360>: mr r30,r3
0xc015b938 <exportfs_decode_fh+364>: lwz r3,8(r29)
0xc015b93c <exportfs_decode_fh+368>: addi r3,r3,116
0xc015b940 <exportfs_decode_fh+372>: bl 0xc04219a8 <mutex_unlock>
0xc015b944 <exportfs_decode_fh+376>: cmplw cr7,r30,r22
0xc015b948 <exportfs_decode_fh+380>: bgt- cr7,0xc015b970 <exportfs_decode_fh+420>
0xc015b94c <exportfs_decode_fh+384>: lwz r0,8(r30)
0xc015b950 <exportfs_decode_fh+388>: cmpwi cr7,r0,0
0xc015b954 <exportfs_decode_fh+392>: beq- cr7,0xc015b968 <exportfs_decode_fh+412>
0xc015b958 <exportfs_decode_fh+396>: mr r3,r28
0xc015b95c <exportfs_decode_fh+400>: mr r28,r30
0xc015b960 <exportfs_decode_fh+404>: bl 0xc00befb0 <dput>
0xc015b964 <exportfs_decode_fh+408>: b 0xc015b970 <exportfs_decode_fh+420>
0xc015b968 <exportfs_decode_fh+412>: mr r3,r30
0xc015b96c <exportfs_decode_fh+416>: bl 0xc00befb0 <dput>
0xc015b970 <exportfs_decode_fh+420>: mr r3,r29
0xc015b974 <exportfs_decode_fh+424>: bl 0xc00befb0 <dput>
0xc015b978 <exportfs_decode_fh+428>: mr r3,r28
0xc015b97c <exportfs_decode_fh+432>: mr r4,r25
0xc015b980 <exportfs_decode_fh+436>: mr r5,r26
0xc015b984 <exportfs_decode_fh+440>: bl 0xc015b6c4 <find_acceptable_alias>
0xc015b988 <exportfs_decode_fh+444>: cmpwi r3,0
0xc015b98c <exportfs_decode_fh+448>: beq- 0xc015b998 <exportfs_decode_fh+460>
0xc015b990 <exportfs_decode_fh+452>: mr r28,r3
0xc015b994 <exportfs_decode_fh+456>: b 0xc015b9b0 <exportfs_decode_fh+484>
0xc015b998 <exportfs_decode_fh+460>: li r30,-13
0xc015b99c <exportfs_decode_fh+464>: b 0xc015b9a4 <exportfs_decode_fh+472>
0xc015b9a0 <exportfs_decode_fh+468>: li r30,-116
0xc015b9a4 <exportfs_decode_fh+472>: mr r3,r28
0xc015b9a8 <exportfs_decode_fh+476>: mr r28,r30
0xc015b9ac <exportfs_decode_fh+480>: bl 0xc00befb0 <dput>
0xc015b9b0 <exportfs_decode_fh+484>: lwz r11,0(r1)
0xc015b9b4 <exportfs_decode_fh+488>: mr r3,r28
0xc015b9b8 <exportfs_decode_fh+492>: lwz r0,4(r11)
0xc015b9bc <exportfs_decode_fh+496>: lmw r22,-40(r11)
0xc015b9c0 <exportfs_decode_fh+500>: mr r1,r11
0xc015b9c4 <exportfs_decode_fh+504>: mtlr r0
0xc015b9c8 <exportfs_decode_fh+508>: blr
End of assembler dump.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: [PATCH 8/8] powerpc: last bits to support kdump on ppc32
From: Michael Ellerman @ 2008-08-03 14:40 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080801141435.GH1161@polina.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]
On Fri, 2008-08-01 at 18:14 +0400, Anton Vorontsov wrote:
> From: Dale Farnsworth <dale@farnsworth.org>
>
> Wire up the trampoline code for ppc32 to relay exceptions from the
> vectors at address 0 to vectors at address 32MB, and modify Kconfig
> to enable Kdump support for all powerpcs (except BookE, for now).
>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
> index e0debcc..96cd521 100644
> --- a/arch/powerpc/kernel/crash_dump.c
> +++ b/arch/powerpc/kernel/crash_dump.c
> @@ -34,7 +34,11 @@ void __init reserve_kdump_trampoline(void)
>
> static void __init create_trampoline(unsigned long addr)
> {
> - unsigned int *p = (unsigned int *)addr;
> + unsigned int *p;
> +
> + /* XXX: why this code is working without += PAGE_OFFSET on PPC64? */
> + addr += PAGE_OFFSET;
> + p = (unsigned int *)addr;
Because we're still in real mode when we call it.
It's kind of funny that it works on 32-bit as well. You're creating a
branch from 0xc0000000 to 0xc2000000, and then expecting it to work when
you're in real mode and you actually want to jump from 0x0 to 0x2000000
- luckily it's a relative branch :)
To clean this up you should just be able to change the definitions for
KDUMP_TRAMPOLINE_START/END to include PAGE_OFFSET and that should work
for 32 & 64-bit.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2] powerpc: move include files to arch/powerpc/include/asm
From: Kumar Gala @ 2008-08-03 14:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Stephen Rothwell, Roland Dreier, LKML, general, ppc-dev
In-Reply-To: <20080801152030.ff10b6b2.sfr@canb.auug.org.au>
On Aug 1, 2008, at 12:20 AM, Stephen Rothwell wrote:
> from include/asm-powerpc. This is the result of a
>
> mkdir arch/powerpc/include/asm
> git mv include/asm-powerpc/* arch/powerpc/include/asm
>
> Followed by a few documentation/comment fixups and a couple of places
> where <asm-powepc/...> was being used explicitly. Of the latter only
> one was outside the arch code and it is a driver only built for
> powerpc.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>
> v2 don't change other arch files - the fixups are only in comments
> anyway.
>
> This patch can be applied with "git am" - the full patch is way to bug
> for our mailing lists.
>
> This has been built for all the powerpc defconfigs including
> all{no,mod,yes}config. There was only one failure, but that is
> expected anyway (I had to apply patches for the iommu and hfcmulti
> breakages).
Paul, what's the plan for this change? If this is something that will
go in so can we get a tree with it so we can base other patches on it
(like the PPC_MERGE cleanup)?
- k
^ permalink raw reply
* Re: [PATCH v2] powerpc: move include files to arch/powerpc/include/asm
From: Stephen Rothwell @ 2008-08-03 15:00 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, Roland Dreier, LKML, general
In-Reply-To: <20080801152030.ff10b6b2.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 361 bytes --]
On Fri, 1 Aug 2008 15:20:30 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> This patch can be applied with "git am" - the full patch is way to bug
^^^
Freudian slip :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
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