I should add that I've tried several things:
- compile the Xilinx kernel as indicated in my previous message.
- compile it with just the xparameters_ml*.h files added
This should work.
It doesn't... Which makes me wonder if my problem may be with the boot
itself.
Once I have my zImage properly
On Monday 31 March 2008 19:06, Sergei Shtylyov wrote:
> Hello.
>
> Laurent Pinchart wrote:
>
> > Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
> > ---
> > Documentation/powerpc/booting-without-of.txt | 13 -
> > 1 files changed, 12 insertions(+), 1 deletions(-)
> >
> > diff
I have updated the master and powerpc-next branches of the powerpc.git
repository with the following commits, including some pulled from Josh
Boyer and Kumar Gala.
Paul.
Alexandr Smirnov (4):
[POWERPC] 85xx: Emerson KSI8560 base support
[POWERPC] 85xx: Emerson KSI8560 bootwrapper
On Tue, 1 Apr 2008 15:00:38 +1100
Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Josh Boyer writes:
>
> > Actually, you probably don't want this as a property in the device
> > tree. It doesn't describe hardware. A Kconfig option might be
> > warranted though.
>
> In general it is valid to have p
Grant Likely wrote:
> On Mon, Mar 31, 2008 at 3:44 AM, Wolfgang Grandegger <[EMAIL PROTECTED]>
> wrote:
>> Wolfgang Grandegger wrote:
>> > Hello,
>> >
>> > is it possible to use the FEC on a MPC5200 with the default hardware PHY
>> > configuration. I mean running the link with a default speed
Kumar Gala writes:
> For the sub-arches that support relocatable interrupt vectors (book-e) its
> reasonable to have memory start at a non-zero physical address. For those
> cases use the variable memstart_addr instead of the #define PPC_MEMSTART
> since the only uses of PPC_MEMSTART are for init
Kumar Gala writes:
> Normally we assume kernel images will be loaded at offset 0. However
> there are situations, like when the kernel itself is running at a non-zero
> physical address, that we don't want to load it at 0.
>
> Allow the wrapper to take an offset. We use this when building u-boot
On Monday 31 March 2008 21:10, Scott Wood wrote:
> Laurent Pinchart wrote:
> > This patch relocates the buffer descriptors and the SMC parameter RAM at the
> > end of the first CPM muram chunk, as described in the device tree. This
> > allows
> > device trees to stop excluding SMC parameter ram al
On Mar 31, 2008, at 11:15 PM, Josh Boyer wrote:
On Tue, 2008-04-01 at 12:04 +1100, Michael Ellerman wrote:
I'm assuming you pass a dtb to the virtual guest when you start
it up.
Could you define a property in the CPU node there that can be
parsed to
use the power_save function instead of al
On Tue, 2008-04-01 at 08:01 -0400, Jimi Xenidis wrote:
> On Mar 31, 2008, at 11:15 PM, Josh Boyer wrote:
>
> > On Tue, 2008-04-01 at 12:04 +1100, Michael Ellerman wrote:
> > I'm assuming you pass a dtb to the virtual guest when you start
> > it up.
> > Could you define a property in
On Tue, 2008-04-01 at 21:59 +1100, Paul Mackerras wrote:
> I have updated the master and powerpc-next branches of the powerpc.git
> repository with the following commits, including some pulled from Josh
> Boyer and Kumar Gala.
Is there something still wrong with version 3 of this patch?
http://pa
On Monday 31 March 2008, Jerone Young wrote:
> >
> > > +{
> > > + unsigned long msr_save;
> > > +
> > > + /* set wait state MSR */
> > > + local_irq_enable();
> > > + msr_save = mfmsr();
> > > + mtmsr(msr_save|MSR_WE);
> >
> > Why don't you |MSR_WE|MSR_EE at the same time?
>
> You tech
Hi everybody,
these 5 patches reset the CPM in cpm2_reset() and fix the cpm_uart driver to
initialise SMC ports correctly without relying on any initialisation
performed by the boot loader/wrapper. They update the boot wrapper code and
the EP8248E device tree to match the new SMC registers descr
This patch adds a new generic device tree processing function that retrieves
virtual reg addresses from the device tree to the bootwrapper code. It also
updates the bootwrapper code to use the new function.
dt_get_virtual_reg() retrieves the virtual reg addresses from the
"virtual-reg" property. I
This patch modifies the Embedded Planet EP8248E device tree to reference the
SMC paramater RAM base register instead of the parameter RAM allocated by the
boot loader.
The cpm_uart driver will allocate parameter RAM itself, making the serial port
initialisation independent of the boot loader.
The
On Tuesday 01 April 2008 11:18, Trent Piepho wrote:
> On Tue, 1 Apr 2008, Laurent Pinchart wrote:
> > On Monday 31 March 2008 19:06, Sergei Shtylyov wrote:
> >>>p) Freescale Synchronous Serial Interface
> >>> - q) USB EHCI controllers
> >>> + q) USB EHCI controllers
> >>> + r) M
Similarly to what is done for PQ1-based platforms, this patch resets the
PQ2 Communication Processor Module in cpm2_reset() when early debugging is
not enabled. This helps avoiding conflicts when the boot loader configured
the CPM in an unexpected way.
Signed-off-by: Laurent Pinchart <[EMAIL PROTE
Hi Grant,
Grant Likely wrote:
On Tue, Mar 25, 2008 at 11:38 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote:
Grant Likely wrote:
> The one part that I have a really strong opinion on is that there
> should be a full featured mpc5200 defconfig for build testing. Beyond
> that (and if ojn can
This patch relocates the buffer descriptors and the SMC parameter RAM at the
end of the first CPM muram chunk, as described in the device tree. This allows
device trees to stop excluding SMC parameter ram allocated by the boot loader
from the CPM muram node.
Signed-off-by: Laurent Pinchart <[EMAIL
This patch allocates parameter RAM for SMC serial ports without relying on
previous initialisation by a boot loader or a wrapper layer.
SMC parameter RAM on CPM2-based platforms can be allocated anywhere in the
general-purpose areas of the dual-port RAM. The current code relies on the
boot loader
On Mon, Mar 31, 2008 at 10:39 AM, Laurent Pinchart
<[EMAIL PROTECTED]> wrote:
>
> Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
> ---
> Documentation/powerpc/booting-without-of.txt | 13 -
> 1 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/p
On Apr 1, 2008, at 1:54 AM, Stephen Rothwell wrote:
Hi Michael,
On Tue, 1 Apr 2008 17:39:11 +1100 (EST) Michael Ellerman <[EMAIL PROTECTED]
> wrote:
We currently have inconsistent settings between 32 & 64-bit which
means
32-bit code can #include but 64-bit code can't.
Kumar sent a ver
Laurent Pinchart wrote:
On Monday 31 March 2008 19:06, Sergei Shtylyov wrote:
p) Freescale Synchronous Serial Interface
- q) USB EHCI controllers
+ q) USB EHCI controllers
+ r) Memory-mapped RAM & ROM
Memory-mapped RA/RO Memory again? Should better drop this. :-)
Hi,
rtas_flash was broken since 2.6.24-rc5. This patch fixes it.
I think this is a good bugfix candidate for 2.6.25.
Jens
---
From: Maxim Shchetynin <[EMAIL PROTECTED]>
Handling of the proc_dir_entry->count has being changed in 2.6.24-rc5.
After this change the default value for pde->count is
The patch fixes a bug, where the PESDRn_UTLSET1 register was setup
wrongly resulting in a non working PCIe port 1. With this fix both
PCIe ports work fine again.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
Based upon linux-next repo from 2008-03-31
arch/powerpc/sysdev/ppc4xx_pci.c | 10
On Tue, Apr 1, 2008 at 6:05 AM, Josh Boyer <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-04-01 at 21:59 +1100, Paul Mackerras wrote:
> > I have updated the master and powerpc-next branches of the powerpc.git
> > repository with the following commits, including some pulled from Josh
> > Boyer and Kum
On Tue, 1 Apr 2008 08:26:17 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 1, 2008 at 6:05 AM, Josh Boyer <[EMAIL PROTECTED]> wrote:
> > On Tue, 2008-04-01 at 21:59 +1100, Paul Mackerras wrote:
> > > I have updated the master and powerpc-next branches of the powerpc.git
> > > repo
Paul Mackerras wrote:
> I have updated the master and powerpc-next branches of the powerpc.git
> repository with the following commits, including some pulled from Josh
> Boyer and Kumar Gala.
How about this patch?
Enable CONFIG_FORCE_MAX_ZONEORDER for all PowerPC, and make selectable
--
Jens Osterkamp wrote:
>
> Handling of the proc_dir_entry->count has being changed in 2.6.24-rc5.
Do you know which commit caused the change?
> After this change the default value for pde->count is 1 and not 0 as it
> was in earlier kernels. Therefore, if we want to check wether our procfs
> fil
replace `__attribute' by `__attribute__'
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/platforms/iseries/main_store.h
b/arch/powerpc/platforms/iseries/main_store.h
index 1a7a3f5..976b23e 100644
--- a/arch/powerpc/platforms/iseries/main_store.h
+++ b/arch/powerpc/plat
On Tue, Apr 01, 2008 at 07:31:01PM +0200, Roel Kluin wrote:
> replace `__attribute' by `__attribute__'
>
> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
> ---
> diff --git a/arch/powerpc/platforms/iseries/main_store.h
> b/arch/powerpc/platforms/iseries/main_store.h
> index 1a7a3f5..976b23e 100644
Laurent Pinchart wrote:
Hi everybody,
these 5 patches reset the CPM in cpm2_reset() and fix the cpm_uart driver to
initialise SMC ports correctly without relying on any initialisation
performed by the boot loader/wrapper. They update the boot wrapper code and
the EP8248E device tree to match
Nathan Lynch wrote:
>
> One could argue that the real problem is using the proc_dir_entry's
> reference count to enforce exclusive open.
I think this is better... the way these files are used is lame, but
this should preserve the existing behavior. I haven't yet tested
this, can you?
diff --g
I considered function pointers as well, but I think something like
dcr-generic.h is still required in order to get the specialization if
only one is selected.
Also note that I neglected to change the patch description: The
dcr-access-method attribute is applied to the dcr-controller node, not
the
On Mon, 31 Mar 2008 11:23:25 -0500
York Sun <[EMAIL PROTECTED]> wrote:
> Add platform code to support Freescale DIU. The platform code includes
> framebuffer memory allocation, pixel format, monitor port, etc.
>
> Signed-off-by: York Sun <[EMAIL PROTECTED]>
> Signed-off-by: Timur Tabi <[EMAIL PRO
Roel Kluin writes:
> replace `__attribute' by `__attribute__'
Why? Your commit message doesn't give any motivation.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Andrew Morton wrote:
> The defconfig change gets almost 100% rejects and probably isn't
> appropriate here and isn't very important.
It's weird that you get rejects, but otherwise you're correct. defconfigs are
just a convenience, anyway.
--
Timur Tabi
Linux kernel developer at Freescale
_
On Tue, 1 Apr 2008, Laurent Pinchart wrote:
On Monday 31 March 2008 19:06, Sergei Shtylyov wrote:
p) Freescale Synchronous Serial Interface
- q) USB EHCI controllers
+ q) USB EHCI controllers
+ r) Memory-mapped RAM & ROM
Memory-mapped RA/RO Memory again? Should bet
This patch contains the entry for the build system and glue code for the
platform bus. Currently OpenFirmware and PCI is supported.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -95,6 +95,32 @@ config USB_ISP116X_HCD
On Apr 1, 2008, at 5:50 AM, Paul Mackerras wrote:
Kumar Gala writes:
For the sub-arches that support relocatable interrupt vectors (book-
e) its
reasonable to have memory start at a non-zero physical address.
For those
cases use the variable memstart_addr instead of the #define
PPC_MEMSTA
On Apr 1, 2008, at 5:08 AM, Paul Mackerras wrote:
Kumar Gala writes:
Normally we assume kernel images will be loaded at offset 0. However
there are situations, like when the kernel itself is running at a
non-zero
physical address, that we don't want to load it at 0.
Allow the wrapper to ta
On Mar 31, 2008, at 10:42 PM, Paul Mackerras wrote:
Kumar Gala writes:
Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can use
it in
places that before would have caused recursive includes.
For example to use phys_addr_t in we would have included
which would have possibly incl
Bartlomiej Sieka writes:
> What about http://patchwork.ozlabs.org/linuxppc/patch?id=17525 ? I don't
> see it in the merge branch of your repository, and it would be nice to
> get it upstream as it fixes boot problems on some MPC5200-based boards.
It needs a proper stand-alone commit message and a
On Tue, 2008-04-01 at 08:18 -0500, Kumar Gala wrote:
> On Apr 1, 2008, at 1:54 AM, Stephen Rothwell wrote:
> > Hi Michael,
> >
> > On Tue, 1 Apr 2008 17:39:11 +1100 (EST) Michael Ellerman <[EMAIL
> > PROTECTED]
> > > wrote:
> >>
> >> We currently have inconsistent settings between 32 & 64-bit w
On Mar 31, 2008, at 11:57 AM, Kumar Gala wrote:
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
for-2.6.25
I'd like to get these minor fixes into 2.6.25. They aren't critical
but
extremely convenient at this point.
Paul, any comme
Kumar Gala writes:
> Hmm, need to think about that. But my initial reaction is two fold.
> One I don't think this information would be around and two don't we
> already have this problem with a kdump kernel?
I'm just concerned that we have two things that have to match up - the
compiled-in
On Tue, Apr 1, 2008 at 5:12 PM, Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Bartlomiej Sieka writes:
>
> > What about http://patchwork.ozlabs.org/linuxppc/patch?id=17525 ? I don't
> > see it in the merge branch of your repository, and it would be nice to
> > get it upstream as it fixes boot prob
On Tuesday 25 March 2008, Carl Love wrote:
> This patch fixes a bug in the code that records the SPU data and
> context switches. The buffer_mutex lock must be held when the
> kernel is adding data to the buffer between the kernel and the
> OProfile daemon. The lock is not being held in the curre
Hi Andrew,
The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
[0.00] [ cut here ]
[0.00] kernel BUG at arch/powerpc/mm/init_64.c:240!
[0.00] Oops: Exception in kernel mode, sig: 5 [#1]
[0.00] SMP NR_CPUS=32 NUMA PowerMac
On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
>
> [0.00] [ cut here ]
> [0.00] kernel BUG at arch/powerpc/mm/init_64.c:240!
> [0.0
A subtle bug sneaked into iSeries recently. On this platform, we
must not normally clear MSR:EE unless it's for short periods of
time. Taking an interrupt while soft-disabled doesn't cause us to
clear it for example.
The iSeries kernel expects to mostly run with MSR:EE enabled at
all times except
51 matches
Mail list logo
