> -Original Message-
> From: Anton Vorontsov [mailto:cbouatmai...@gmail.com]
> Sent: Thursday, September 09, 2010 19:54 PM
> To: Zang Roy-R61911
> Cc: linux-...@lists.infradead.org; dw...@infradead.org; dedeki...@gmail.com;
> a...@linux-foundation.org; Lan Chunhe-B25806; Wood Scott-B07421
I didn't understand the address mask.
it's said that: BR[BA] is the base address,the OR[AM] is the address mask,
"Provides masking for corresponding BRx bits. By masking address
bits independently, SDRAM devices of different size address ranges can be used.
Clearing
bits masks the correspondin
Ravi Gupta wrote:
> Hi Tiejun,
>
> Thanks for the reply.
>
> Omm.
>> Often we always disable this pref windows so please disable this window.
>> Try use
>> the following ways to clear PCI_PREF_MEMORY_BASE and PCI_PREF_MEMORY_LIMIT.
>> --
>>pci_write_config_word(dev, PCI_PREF_MEMORY_BA
The logic to distinguish marked instruction events from ordinary events
on PPC970 and derivatives was flawed. The result is that instruction
sampling didn't get enabled in the PMU for some marked instruction
events, so they would never trigger. This fixes it by adding the
appropriate break statem
[ Repost with correct kexec ML address ]
[ CCed linuxppc-dev ]
On Thu, Sep 09, 2010 at 04:27:11PM -0400, Neil Horman wrote:
> hey-
> Got a segfault recently on ppc64 kexec with a system with 256Gb of ram.
> Tracked it back to running over the end of the device tree buffer that we have
> alloc
[ CCed linuxppc-dev ]
On Thu, Sep 09, 2010 at 04:27:11PM -0400, Neil Horman wrote:
> hey-
> Got a segfault recently on ppc64 kexec with a system with 256Gb of ram.
> Tracked it back to running over the end of the device tree buffer that we have
> allocated. I can't find any docs on how big t
On Thu, 2010-09-09 at 17:37 -0500, Scott Wood wrote:
>
> Wolfgang was just defending it on the U-Boot list the past couple
> days... seems like the main thing in its favor is the CRC, especially
> as a final check before reflashing an image.
Right, then fwd my 2 cents:
Makes sense to have a wra
Hi,
On Thu, 9 Sep 2010 15:17:10 -0700 Tirumala Marri wrote:
>
> [Marri]That is kind of true. Can we create new defconfigs then ?
> I am trying to check-in new defconfig.
Just make sure that it is minimal by using "make savedefconfig". This
will create a file "defconfig" in the current directory
On Fri, 10 Sep 2010 08:13:53 +1000
Benjamin Herrenschmidt wrote:
> On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote:
> > > I would have expected uboot to warn (the kernel ELF header contains
> > the
> > > BSS size) but apparently that isn't the case.
> >
> > U-Boot doesn't use ELF files with
On Fri, 10 Sep 2010 07:58:54 +1000
Benjamin Herrenschmidt wrote:
> I would have expected uboot to warn (the kernel ELF header contains the
> BSS size) but apparently that isn't the case.
U-Boot doesn't use ELF files with Linux, so it has no idea where the
BSS is. uImage is just a wrapper around
> On Thu, 9 Sep 2010 09:49:14 -0700
> Tirumala Marri wrote:
>
> > [Marri] Great we already have it. We should remove the defconfigs
> > under 44x then ?
>
> I'd rather we didn't. I thought Linus' beef was over the churn in the
> defconfigs, not the fact that they exist. The 44x defconfigs change
>
On Fri, 2010-09-10 at 08:13 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote:
> > > I would have expected uboot to warn (the kernel ELF header contains
> > the
> > > BSS size) but apparently that isn't the case.
> >
> > U-Boot doesn't use ELF files with Li
On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote:
> > I would have expected uboot to warn (the kernel ELF header contains
> the
> > BSS size) but apparently that isn't the case.
>
> U-Boot doesn't use ELF files with Linux, so it has no idea where the
> BSS is. uImage is just a wrapper around a
On Thu, 2010-09-09 at 12:36 -0700, Ira W. Snyder wrote:
> On Thu, Sep 09, 2010 at 02:10:59PM -0500, Timur Tabi wrote:
> > On Thu, Sep 9, 2010 at 1:44 PM, Ira W. Snyder wrote:
> >
> > > Single stepping through the initial assembly portion of kernel startup
> > > shows that the FDT gets clobbered d
> I have succeeded in getting the debugger to break early on during boot.
> I have it set to break at start_here, in arch/powerpc/kernel/head_32.S.
>
> My U-Boot bootloader indicates that the fdt is being loaded to address
> 0x7f8000, which translates to VA 0xc07f8000. See this output:
>
>Bo
Ira W. Snyder wrote:
> I have no idea how to determine this.
>
> The code that caused the problem runs so early in boot that the MMU is
> not running yet. Looking through the tiny bit of code, it appears that
> it just uses whatever the bootloader set up for it. It hasn't gotten to
> the initial_b
On Thu, Sep 09, 2010 at 03:36:31PM -0500, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > That did it!
>
> Yea!
>
> > I'm using include/configs/MPC8349EMDS.h. On that board,
> > CONFIG_SYS_BOOTMAPSZ is 8MB. Boosting it to 16MB fixed the problem and
> > the kernel now boots.
>
> Ah, yes. I believe the
Ira W. Snyder wrote:
> That did it!
Yea!
> I'm using include/configs/MPC8349EMDS.h. On that board,
> CONFIG_SYS_BOOTMAPSZ is 8MB. Boosting it to 16MB fixed the problem and
> the kernel now boots.
Ah, yes. I believe the reason that is the case is because some of those
boards were shipped with on
On Thu, Sep 09, 2010 at 03:13:17PM -0500, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > That easily overruns the location where U-Boot puts the FDT. Is this a
> > U-Boot bug, meaning I should post this information on the U-Boot
> > mailing list?
>
> Possibly.
>
> I am under the impression that the
Ira W. Snyder wrote:
> That easily overruns the location where U-Boot puts the FDT. Is this a
> U-Boot bug, meaning I should post this information on the U-Boot
> mailing list?
Possibly.
I am under the impression that the memory in the boot block that contains
the FDT is marked as "reserved" in t
On Thu, Sep 09, 2010 at 02:40:50PM -0500, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > As noted in another email, it appears that U-Boot puts the FDT in such a
> > place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y
> > option expands the BSS by a large amount, which causes the
Ira W. Snyder wrote:
> As noted in another email, it appears that U-Boot puts the FDT in such a
> place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y
> option expands the BSS by a large amount, which causes the error. It
> isn't directly lockdep related.
>
> I don't know if thi
On Thu, Sep 09, 2010 at 02:10:59PM -0500, Timur Tabi wrote:
> On Thu, Sep 9, 2010 at 1:44 PM, Ira W. Snyder wrote:
>
> > Single stepping through the initial assembly portion of kernel startup
> > shows that the FDT gets clobbered during the function early_init(). This
> > trace is reproduced belo
On Thu, Sep 09, 2010 at 11:44:46AM -0700, Ira W. Snyder wrote:
[ snip a bunch of info: summary below ]
>
> I've also found that setting a breakpoint at 0x0 stops right when the
> Linux kernel starts, at symbol _start. AFAIK, the MMU is not yet
> enabled, so I have to subtract 0xc000 from all
On Thu, Sep 9, 2010 at 1:44 PM, Ira W. Snyder wrote:
> Single stepping through the initial assembly portion of kernel startup
> shows that the FDT gets clobbered during the function early_init(). This
> trace is reproduced below.
Have you tried also enabling CONFIG_DEBUG_LOCK_ALLOC? These two
c
On Thu, Sep 09, 2010 at 09:23:07AM -0700, Ira W. Snyder wrote:
> On Thu, Sep 09, 2010 at 12:58:16PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2010-09-08 at 19:52 -0700, Ira W. Snyder wrote:
> > >
> > > I will attempt to get the debugger to stop at start_kernel. I'm having
> > > trouble driv
The Freescale P1022DS has an on-chip video controller called the DIU, and a
driver for this device already exists. Update the platform file for the
P1022DS reference board to enable the driver, and update the defconfig for
Freescale MPC85xx boards to add the driver.
Signed-off-by: Timur Tabi
---
The device tree for Freescale's P1022DS reference board is missing the node
for the ngPIXIS FPGA.
Signed-off-by: Timur Tabi
---
arch/powerpc/boot/dts/p1022ds.dts |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1022ds.dts
b/arch/powerpc/boo
"Andre Schwarz" wrote:
> Anton,
>
>> we're about to get new MPC8377 based hardware with various peripherals.
>>> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
>>> how to define a proper dts...
>>>
>>> Of course it's an easy thing creating 2 child nodes on the CPU's I
On Thu, 9 Sep 2010 09:49:14 -0700
Tirumala Marri wrote:
> [Marri] Great we already have it. We should remove the defconfigs
> under 44x then ?
I'd rather we didn't. I thought Linus' beef was over the churn in the
defconfigs, not the fact that they exist. The 44x defconfigs change
very rarely.
C
On Fri, Sep 03, 2010 at 10:36:19AM +0200, André Schwarz wrote:
> Hi,
>
> we're about to get new MPC8377 based hardware with various peripherals.
> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
> how to define a proper dts...
>
> Of course it's an easy thing creating 2 c
>
> We already have arch/powerpc/configs/ppc40x_defconfig and
> arch/powerpc/configs/ppc44x_defconfig in mainline.
>
> What's wrong with using these?
[Marri] Great we already have it. We should remove the defconfigs under
44x then ?
Regards,
Marri
___
Lin
On Thu, Sep 09, 2010 at 12:58:16PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2010-09-08 at 19:52 -0700, Ira W. Snyder wrote:
> >
> > I will attempt to get the debugger to stop at start_kernel. I'm having
> > trouble driving the JTAG debugger (a BDI2000). I have used Denx's
> > guide
> > [1] i
Hi Tiejun,
Thanks for the reply.
Omm.
>
> Often we always disable this pref windows so please disable this window.
> Try use
> the following ways to clear PCI_PREF_MEMORY_BASE and PCI_PREF_MEMORY_LIMIT.
> --
>pci_write_config_word(dev, PCI_PREF_MEMORY_BASE, 0);
>pci_write_conf
Just a few cosmetic nits for this patch...
On Thu, Sep 09, 2010 at 06:20:30PM +0800, Roy Zang wrote:
[...]
> @@ -94,22 +73,26 @@ int fsl_upm_find(phys_addr_t addr_base, struct fsl_upm
> *upm)
> {
> int bank;
> __be32 br;
> + struct fsl_lbc_regs __iomem *lbc;
>
> bank = fs
On Thu, Sep 09, 2010 at 06:20:32PM +0800, Roy Zang wrote:
[...]
> /**
> + * fsl_lbc_addr - convert the base address
> + * @addr_base: base address of the memory bank
> + *
> + * This function converts a base address of lbc into the right format for
> the BR
> + * registers. If the SOC has e
On Thu, Sep 09, 2010 at 06:20:31PM +0800, Roy Zang wrote:
[...]
> #include
> #include
> #include
> -#include
> -#include
> -#include
> -#include
> -#include
>
> -#include
> #include
> -#include
> #include
> -
> -#include
> #include
> +#include
Why move slab.h?
[...]
>
On Thu, Sep 9, 2010 at 12:20, Roy Zang wrote:
> From: Lan Chunhe-B25806
>
> When system uses 36bit physical address, res.start is 36bit
> physical address. But the function of in_be32 returns 32bit
> physical address. Then both of them compared each other is
> wrong. So by converting the address
From: Lan Chunhe-B25806
When system uses 36bit physical address, res.start is 36bit
physical address. But the function of in_be32 returns 32bit
physical address. Then both of them compared each other is
wrong. So by converting the address of res.start into
the right format fixes this issue.
Sign
From: Jack Lan
The former driver had the two functions:
1. detecting nand flash partitions;
2. registering elbc interrupt.
Now, second function is removed to fsl_lbc.c.
Signed-off-by: Lan Chunhe-B25806
Signed-off-by: Roy Zang
---
Comparing with v1, according to the feedback, remove global va
From: Lan Chunhe-B25806
Move Freescale elbc interrupt from nand dirver to elbc driver.
Then all elbc devices can use the interrupt instead of ONLY nand.
Signed-off-by: Lan Chunhe-B25806
Signed-off-by: Roy Zang
---
Comparing with v1, according to the feedback, add some decorations.
arch/power
Ravi Gupta wrote:
> Hi Tiejun,
>
> Thanks for the reply.
>
>
> Your PCI device should be one virtual device so I think the above should be
>> as
>> we understood. You know 0x ~ 0x3 should not be allowed to
>> reserved.
>>
>
> Can you explain a little more that what do you mean b
Signed-off-by: Roy Zang
---
arch/powerpc/boot/dts/p4080ds.dts |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p4080ds.dts
b/arch/powerpc/boot/dts/p4080ds.dts
index 2f0de24..0a18138 100644
--- a/arch/powerpc/boot/dts/p4080ds.dts
+++ b/arch/powerpc/bo
On Thu, Sep 09, 2010 at 03:28:34AM +0100, Chris Ball wrote:
[...]
> [7.372843] [] __might_sleep+0xd9/0xe0
> [7.387864] [] mutex_lock+0x1c/0x2a
> [7.402576] [] sdhci_led_control+0x1a/0x41
> [7.417727] [] led_trigger_event+0x42/0x5c
led_trigger_even grabs a readlock. :-(
> [
44 matches
Mail list logo
