Hi Matt,
On Thu, Apr 10, 2008 at 04:25:20PM +0100, Matt Sealey wrote:
> I have a copy of the driver I hacked to work with the new PSC
> framework but it doesn't "work" anymore - I have no idea why.
>
> Mail me privately if you want it, I have no time to make patches or
> look for a good reason for
On Fri, Apr 11, 2008 at 02:18:22AM +0200, Arnd Bergmann wrote:
> On Thursday 10 April 2008, Jerone Young wrote:
> > Well it could be this simple. But the current code leaves a lot more
> > room to add different type waits or spins if need be (if they are ever
> > needed ... though none off the top
In message: Re: [PATCH 0/5] dynamic detection of gianfar TPIPA
on 10/04/2008 Andy Fleming wrote:
>
> I may be missing something, but I don't think this quite right.
>
> If you have a PHY at 0x1f, this patchset will cause no PHY device to be
> allocated for that address, and you'll actually end up
Kumar Gala wrote:
but there is no reason not to make it work properly. For example I
believe libata uses devm_* and the fsl SATA driver (non-PCI) will
need to work in cases similar to the 44x.
Well, as for sata_fsl, it calls of_iomap() which does The Right Thing.
Fair, but I don't see w
On Thu, 10 Apr 2008 18:36:35 -0700 (PDT) Roland McGrath <[EMAIL PROTECTED]>
wrote:
> > This crashes my powerpc mac g5.
>
> It worked fine on mine.
>
> > It happens after the boot, during the first login-over-ssh.
>
> Mine did lots of stuff fine.
>
> > This is with most of the rest of the -mm
On Thu, Apr 10, 2008 at 07:22:17PM -0400, Paul Gortmaker wrote:
> This adds support for the Wind River SBC8641D board, based
> largely on the mpc86xx_hpcn support. The biggest difference is
> the lack of the Uli and the i8259 cascade, which simplifies things.
Hi Paul,
A couple issues. (These sh
> This crashes my powerpc mac g5.
It worked fine on mine.
> It happens after the boot, during the first login-over-ssh.
Mine did lots of stuff fine.
> This is with most of the rest of the -mm poopile applied. i386 and x86_64
> seem OK.
I had only tested with Linus's tree plus the small handfu
Hi Kumar,
On Thu, 10 Apr 2008 10:01:27 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> anyone looking into this?
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/23299/
>
> Its really a Kconfig issue.
Just posted a patch.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
htt
The allyesconfig (among others) build was giving this:
In file included from include/linux/gfp.h:4,
from include/linux/slab.h:14,
from include/linux/percpu.h:5,
from include2/asm/time.h:18,
from include2/asm/cputime.h:26,
On Fri, 2008-04-11 at 02:18 +0200, Arnd Bergmann wrote:
> > > static int __init idle_param(char *p)
> > > {
> > > if (!strcmp(modes[i].name, "spin"))
> > > ppc_md.power_save = NULL;
> > > }
> > > early_param("idle", idle_param);
> > >
> > > if you statically initialize the ppc_
On Fri, 2008-04-11 at 10:05 +1000, Stephen Rothwell wrote:
> Hi Paul,
>
> Just a couple of comments.
>
> On Thu, 10 Apr 2008 19:22:17 -0400 Paul Gortmaker <[EMAIL PROTECTED]> wrote:
> >
> > +++ b/arch/powerpc/platforms/86xx/sbc8641d.c
> > +#undef DEBUG
> > +
> > +#ifdef DEBUG
> > +#define DBG(fmt
On Thursday 10 April 2008, Jerone Young wrote:
> Well it could be this simple. But the current code leaves a lot more
> room to add different type waits or spins if need be (if they are ever
> needed ... though none off the top of my head at the moment)...but it
> does allow you to create another w
Hi Paul,
Just a couple of comments.
On Thu, 10 Apr 2008 19:22:17 -0400 Paul Gortmaker <[EMAIL PROTECTED]> wrote:
>
> +++ b/arch/powerpc/platforms/86xx/sbc8641d.c
> +#undef DEBUG
> +
> +#ifdef DEBUG
> +#define DBG(fmt...) do { printk(KERN_ERR fmt); } while(0)
^^^
On Apr 10, 2008, at 3:45 PM, Scott Wood wrote:
The kconfig entry can go away once arch/ppc and references to the
config in
drivers are removed.
just to be clear. arch/powerpc will always just use the new binding
and arch/ppc uses the old (or has the option)?
- k
This patch series consists of some minor cleanups that eventually
allow us to implement a dynamic assignment of the gianfar TBIPA.
This was the implementation that Andy and Scott indicated was
the most desireable solution at the bottom of this discussion:
http://patchwork.ozlabs.org/linuxppc-embe
The powerpc kernel stacks need to be naturally aligned, as they
contain the thread info at the bottom, which is obtained by
clearing the low bits of the stack pointer.
However, when using 64K pages (the stack is smaller than a page),
we use kmalloc to allocate it, which doesn't provide that guaran
Some architecture need to maintain a kmem cache for thread info
structures. (next patch adds that to powerpc to fix an alignment
problem).
There is no good arch callback to use to initialize that cache
that I can find, so this adds a new one and adds an empty macro
for when it's not implemented.
TBIPA needs to be set to a value (on connected MDIO buses) that doesn't
conflict with PHYs on the bus. By hardcoding it to 0x1f, we were preventing
boards with PHYs at 0x1f from working properly. Instead, scan the bus when
it comes up, and find an address that doesn't have a PHY on it. The TBI P
On Apr 10, 2008, at 12:51, Paul Gortmaker wrote:
This patch series consists of some minor cleanups that eventually
allow us to implement a dynamic assignment of the gianfar TBIPA.
This was the implementation that Andy and Scott indicated was
the most desireable solution at the bottom of this d
Currently the MDIO address for the gianfar Ten Bit
Interface is hard coded to be 0x1f, which can conflit
with some boards if they happen to put a PHY there.
Previous discussions indicated that the proper approach
here would be to dynamically allocate it, based on
picking the highest MDIO address t
The gfar_local_mdio_read/write functions were brought in via
extern since they go right at the regs vs. going via the normal
gfar_mdio_read/write functions. With the priv->mii_bus properly
set, we can get rid of the externs, the casts etc. and use the
normal gfar_mdio_read/write. We just need to m
The gfar was previously using the mii_bus->priv to directly
store the gfar_mii regs, which leaves no room/flexibility to
store anything else there. I believe it makes more sense to
have mii_bus->priv point at a struct gianfar_mdio_data and
then have the regs stored as a field within that. It make
I've tested on 8360, 8540 and 8641D and in all cases, the PHY
ID returned for bus addr 0x1f is all zeros, and not all 0xf.
This means we've been allocating a phydev for this "ghost".
In addition to marking 0x0 as an invalid PHY ID, I've also
changed the existing somewhat useless printk to actually
The gianfar priv struct has an entry for the mii_bus, but it
isn't being populated. Assign a value for it at the same time
as we assign the phydev, so that it can be used in calls like
gianfar_mdio_read/write.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
drivers/net/gianfar.c |1 +
This adds a sample defconfig for the Wind River SBC8641D
board, with SMP, PCI and NFS root enabled.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/configs/sbc8641d_defconfig | 1342 +++
1 files changed, 1342 insertions(+), 0 deletions(-)
create mod
This adds in the device tree source for the SBC8641D, based
largely on the mpc8641_hpcn.dts. The biggest differences are
the lack of a complex IRQ mapping (since no Uli/i8259 cascade)
and the different layout of devices on the localbus node.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
This adds support for the Wind River SBC8641D board, based
largely on the mpc86xx_hpcn support. The biggest difference is
the lack of the Uli and the i8259 cascade, which simplifies things.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/86xx/Kconfig|8 ++-
a
The following patches add support for the Wind River SBC8641D board.
I've done it by starting with the current mpc8641_hpcn support and
then making the changes from there, so it should be 1:1 comparable
with the HPCN platform, which aids in tracking/applying future changes.
The SBC8641D support e
On Thu, 2008-04-10 at 15:16 -0700, David Miller wrote:
> From: Laurent Pinchart <[EMAIL PROTECTED]>
> Date: Thu, 10 Apr 2008 17:20:36 +0200
>
> > On Thursday 10 April 2008 16:21, Kumar Gala wrote:
> > > Guy's
> > >
> > > if you have work you want in 2.6.26 related to Freescale PPC's let me
> >
Please use [EMAIL PROTECTED] for patch and development
discussion, linux-net is for user discussions only.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
From: Laurent Pinchart <[EMAIL PROTECTED]>
Date: Thu, 10 Apr 2008 17:20:36 +0200
> On Thursday 10 April 2008 16:21, Kumar Gala wrote:
> > Guy's
> >
> > if you have work you want in 2.6.26 related to Freescale PPC's let me
> > know. Ideally you can provide links to the patches in
> > http://pat
On Thu, 2008-04-10 at 15:37 +0200, Stefan Roese wrote:
>
> Now I have to re-check to see what you really have in mind. Do you think
> about
> creating two different PCIe nodes, one for root-complex and one for endpoint
> functionality? Or is your idea to add a property to the existing PCIe
>
> +#ifndef thread_info_cache_init
> +#define thread_info_cache_init do { } while(0)
> +#endif
> +
Blah ! Missing a pair of () here. Ooops. I'll send a fixed patch.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/ma
The kconfig entry can go away once arch/ppc and references to the config in
drivers are removed.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/82xx/Kconfig |3 -
arch/powerpc/platforms/85xx/Kconfig |8 -
arch/powerpc/platforms/8xx/Kconfig |4 -
arch/powerpc
On Thu, 2008-04-10 at 15:44 +0200, Arnd Bergmann wrote:
> On Tuesday 08 April 2008, Jerone Young wrote:
> > +static struct sleep_mode modes[] = {
> > + { .name = "wait", .entry = &ppc44x_idle },
> > + { .name = "spin", .entry = NULL },
> > +};
> > +
> > +int __init ppc44x_idle_init(void
On Apr 10, 2008, at 1:24 PM, Sergei Shtylyov wrote:
Kumar Gala wrote:
Those functions are going to break on 32-bit platforms with
extended physical address (well, that's starting with Pentiums
which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g.
PowerPC 44x). You should have
Kumar Gala wrote:
Those functions are going to break on 32-bit platforms with
extended physical address (well, that's starting with Pentiums
which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g.
PowerPC 44x). You should have used resource_size_t for the
'offset' parameter. As t
On Wed, 9 Apr 2008 13:50:43 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 9, 2008 at 12:00 PM, John Bonesio <[EMAIL PROTECTED]> wrote:
> > I understand that many people are using a bootloader that already sets up
> > the
> > cache for the kernel, but I'm wondering if Xilinx board
On Apr 10, 2008, at 11:56 AM, Sergei Shtylyov wrote:
Hello, I wrote:
Those functions are going to break on 32-bit platforms with
extended physical address (well, that's starting with Pentiums
which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g.
PowerPC 44x). You should have us
On Apr 10, 2008, at 10:50 AM, Laurent Pinchart wrote:
Hi everybody,
I need to pass a limited amount of information from the boot loader
to the
Linux kernel, such as the boot mode chosen by the user or the last
boot
reason (power up, reset, watchdog, ...).
What is the best way to pass that
Hello, I wrote:
Those functions are going to break on 32-bit platforms with
extended physical address (well, that's starting with Pentiums which
had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g. PowerPC
44x). You should have used resource_size_t for the 'offset'
parameter. As this m
On Tue, 8 Apr 2008 13:54:41 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 07, 2008 at 10:25:32PM -0500, Hollis Blanchard wrote:
> > On Monday 07 April 2008 20:11:28 David Gibson wrote:
> > > On Mon, Apr 07, 2008 at 03:53:33PM -0500, Hollis Blanchard wrote:
> > > > 1 file changed, 7 i
Sascha Hauer wrote:
See bottom of this mail. The board really is a 8260 based board. Our
bootloader does not fill in the clock values, so they are hardcoded. I'm
not very sure about the muram entries because the dpram is organized
slightly different on the 8260. It has some dedicated FCC space an
On Thu, Apr 10, 2008 at 9:50 AM, Laurent Pinchart
<[EMAIL PROTECTED]> wrote:
> Hi everybody,
>
> I need to pass a limited amount of information from the boot loader to the
> Linux kernel, such as the boot mode chosen by the user or the last boot
> reason (power up, reset, watchdog, ...).
>
> Wh
Hi everybody,
I need to pass a limited amount of information from the boot loader to the
Linux kernel, such as the boot mode chosen by the user or the last boot
reason (power up, reset, watchdog, ...).
What is the best way to pass that kind of information from the boot loader to
the kernel ? S
On Apr 10, 2008, at 10:20 AM, Laurent Pinchart wrote:
On Thursday 10 April 2008 16:21, Kumar Gala wrote:
Guy's
if you have work you want in 2.6.26 related to Freescale PPC's let me
know. Ideally you can provide links to the patches in
http://patchwork.ozlabs.org/linuxppc/
Could you please a
On Apr 3, 2008, at 11:46 AM, Randy Vinson wrote:
When steal_context is used on SMP systems, it can steal a context in
use by one of the other processors. This patch adds context tracking
to
prevent this as suggested by BenH.
Can we be more descriptive in the problem/bug symptom in the
des
I have a copy of the driver I hacked to work with the new PSC framework
but it doesn't "work" anymore - I have no idea why.
Mail me privately if you want it, I have no time to make patches or
look for a good reason for the breakages, but it compiles at least.
The Efika hack should be gone now (ir
On Thursday 10 April 2008 16:21, Kumar Gala wrote:
> Guy's
>
> if you have work you want in 2.6.26 related to Freescale PPC's let me
> know. Ideally you can provide links to the patches in
> http://patchwork.ozlabs.org/linuxppc/
Could you please add this one ?
fs_enet: Don't call NAPI functi
On Apr 1, 2008, at 7:33 AM, 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
t
anyone looking into this?
http://kisskb.ellerman.id.au/kisskb/buildresult/23299/
Its really a Kconfig issue.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Apr 10, 2008, at 6:46 AM, Laurent Pinchart wrote:
Hi Paul,
could you please add the following patches ?
[PATCHv4 1/5] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-
based
platforms.
http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053858.html
[PATCHv4 2/5] powerpc: Add bootwra
On Apr 10, 2008, at 9:28 AM, Laurent Pinchart wrote:
On Thursday 10 April 2008 16:11, Kumar Gala wrote:
On Apr 10, 2008, at 7:32 AM, Paul Mackerras wrote:
Laurent Pinchart writes:
could you please add the following patches ?
Sure, if Kumar acks them, since they are all 8xxx-related as far
On Mon, 07 Apr 2008 15:53:32 -0500
Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> 1 file changed, 2 insertions(+)
> include/asm-powerpc/mmu-44x.h |2 ++
>
>
> PowerPC 440 KVM needs to know how many TLB entries are used for the host
> kernel
> linear mapping (it does not modify these mappings
On Thursday 10 April 2008 16:11, Kumar Gala wrote:
>
> On Apr 10, 2008, at 7:32 AM, Paul Mackerras wrote:
> > Laurent Pinchart writes:
> >
> >> could you please add the following patches ?
> >
> > Sure, if Kumar acks them, since they are all 8xxx-related as far as I
> > can see (with the exception
On Thursday 10 April 2008 06:55:18 Josh Boyer wrote:
> On Mon, 07 Apr 2008 15:53:31 -0500
>
> Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> > Implement initial support for KVM for PowerPC 440. There are just two
> > small prerequisite patches, and then the bulk of the code can't be split
> > easily
Guy's
if you have work you want in 2.6.26 related to Freescale PPC's let me
know. Ideally you can provide links to the patches in http://patchwork.ozlabs.org/linuxppc/
thanks
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs
Hi Kumar,
On Thursday 10 April 2008 16:10, Kumar Gala wrote:
> Laurent,
>
> The cpm/82xx ones should go via me.
Sorry, I didn't know that. I'll e-mail you directly next time.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2
On Apr 10, 2008, at 7:32 AM, Paul Mackerras wrote:
Laurent Pinchart writes:
could you please add the following patches ?
Sure, if Kumar acks them, since they are all 8xxx-related as far as I
can see (with the exception of the part of 2/5 that adds the new
dt_get_virtual_reg function). Or Ku
Laurent,
The cpm/82xx ones should go via me.
- k
On Apr 10, 2008, at 6:46 AM, Laurent Pinchart wrote:
Hi Paul,
could you please add the following patches ?
[PATCHv4 1/5] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-
based
platforms.
http://ozlabs.org/pipermail/linuxppc-dev/2008-Ap
On Tuesday 08 April 2008, Jerone Young wrote:
> +static struct sleep_mode modes[] = {
> + { .name = "wait", .entry = &ppc44x_idle },
> + { .name = "spin", .entry = NULL },
> +};
> +
> +int __init ppc44x_idle_init(void)
> +{
> + void *func = modes[current_mode].entry;
> + ppc
On Thu, Apr 10, 2008 at 12:44:43PM +0200, Marian Balakowicz wrote:
> Last year you have posted a MPC5200 PSC AC97 driver patch
> "[PATCH 9/9] sound: Add support for Freescale MPC5200 AC97 interface."
> with the following comment:
>
> > Not quite a clean driver, but it get things done (well, mostly)
On Thursday 10 April 2008, Benjamin Herrenschmidt wrote:
> > Understood. But for this "dynamic" root-complex/endpoint configuration as
> > implemented with the current version of the patch, I can't change the
> > PCIe node in the dts from root-complex mode to endpoint mode, since I
> > would loose
On Thu, Apr 10, 2008 at 1:52 PM, Josh Boyer <[EMAIL PROTECTED]> wrote:
> You have to call of_platform_bus_probe with the various bus types for
> your board. See the top few functions of:
>
> arch/powerpc/platforms/40x/walnut.c
Well I did this, but I made a typo (plb4 instead of plb3).
So than
Laurent Pinchart writes:
> could you please add the following patches ?
Sure, if Kumar acks them, since they are all 8xxx-related as far as I
can see (with the exception of the part of 2/5 that adds the new
dt_get_virtual_reg function). Or Kumar can put them in his tree.
Paul.
_
On Thu, 2008-04-10 at 13:59 +0200, Stefan Roese wrote:
> Understood. But for this "dynamic" root-complex/endpoint configuration as
> implemented with the current version of the patch, I can't change the PCIe
> node in the dts from root-complex mode to endpoint mode, since I would loose
> root-c
On Thu, 2008-04-10 at 12:56 +0200, Christoph Hellwig wrote:
> On Thu, Apr 10, 2008 at 07:03:22AM +1000, Benjamin Herrenschmidt wrote:
> > I don't think there's any difference between the _ONSTACK variant
> > and the normal one without lockdep, is there ?
>
> No there's not. Thus it's a guarantee
On Thursday 10 April 2008, Benjamin Herrenschmidt wrote:
> On Thu, 2008-04-10 at 12:21 +0200, Stefan Roese wrote:
> > Sure, this would be optimal. But frankly, I currently have no need for
> > this
> > non U-Boot mode, and therefore I didn't implement it. This can be
> > added later
> > when really
On Mon, 07 Apr 2008 15:53:31 -0500
Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> Implement initial support for KVM for PowerPC 440. There are just two small
> prerequisite patches, and then the bulk of the code can't be split easily.
>
> Please review; I would like to submit these for 2.6.26. The
On Tue, 08 Apr 2008 11:49:14 -0500
Jerone Young <[EMAIL PROTECTED]> wrote:
> 2 files changed, 77 insertions(+), 1 deletion(-)
> arch/powerpc/platforms/44x/Makefile |2
> arch/powerpc/platforms/44x/idle.c | 76 +++
>
>
> Updates: Now setting MSR_WE is now de
On Thu, 10 Apr 2008 12:37:45 +0200
"M B" <[EMAIL PROTECTED]> wrote:
> Hi,
> I'm porting vanilla 2.6.25-rc8 (arch=powerpc) to a new board. UART is
> already working in the kernel and Uboot with UART and ethernet is also
> working.
> But I can't get the emac driver (ibm_newemac) working under Linux.
Hi Paul,
could you please add the following patches ?
[PATCHv4 1/5] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based
platforms.
http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053858.html
[PATCHv4 2/5] powerpc: Add bootwrapper function to get virtual reg from the
device tree.
ht
On Thu, 2008-04-10 at 12:21 +0200, Stefan Roese wrote:
>
> Sure, this would be optimal. But frankly, I currently have no need for
> this
> non U-Boot mode, and therefore I didn't implement it. This can be
> added later
> when really needed don't you think?
It can... but on the other hand, it's
On Thursday 10 April 2008, M B wrote:
> I'm porting vanilla 2.6.25-rc8 (arch=powerpc) to a new board. UART is
> already working in the kernel and Uboot with UART and ethernet is also
> working.
> But I can't get the emac driver (ibm_newemac) working under Linux.
> On boot emac_init get's called and
Hi Kumar,
On Thu, 10 Apr 2008 03:51:42 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> We should probably add mpc83xx_defconfig to kisskb. However,
> mpc885_ads_defconfig is an 8xx (extreme low end) and mpc85xx_defconfig
> (higher end) cover two different processor families so we shouldn't
Paul Mackerras <[EMAIL PROTECTED]> wrote:
> The following patches have been added to the master and powerpc-next
> branches of the powerpc.git repository. There is a bunch that I
Paul-san,
Could you apply my "take 2" patchset?
[PATCH 0/11] celleb: patchset for 2.6.26 (take 2)
http://ozlabs.org/
Hi Sylvain,
Last year you have posted a MPC5200 PSC AC97 driver patch
"[PATCH 9/9] sound: Add support for Freescale MPC5200 AC97 interface."
with the following comment:
> Not quite a clean driver, but it get things done (well, mostly).
> Only included to be able to test functionalityi/usage of
>
On Thu, Apr 10, 2008 at 07:03:22AM +1000, Benjamin Herrenschmidt wrote:
> I don't think there's any difference between the _ONSTACK variant
> and the normal one without lockdep, is there ?
No there's not. Thus it's a guaranteed no-op and can easily go in.
On Apr 9, 2008, at 9:25 PM, Paul Mackerras wrote:
Kumar Gala writes:
So now we can look at the vmlinux and determine the physical offset.
The question is how best to do that. Here are the options I see:
* readelf, grep and parse output
* objdump grep and parse output
* simple C program that r
Added support to allow an 85xx kernel to be run from a non-zero physical
address (useful for cooperative asymmetric multiprocessing situations) and
kdump. The support can either be at compile time or runtime
(CONFIG_RELOCATABLE).
Currently we are limited to running at a physical address that is m
We can set LOAD_OFFSET and use the AT attribute on sections and the
linker will properly set the physical address of the LOAD program
header for us.
This allows us to know how the PHYSICAL_START the user configured a
kernel with by just looking at the resulting vmlinux ELF.
This is pretty much st
Now that we properly set the physical address in the program header of the
vmlinux ELF we can extract it to properly set the load and entry point for
u-boot uImages. Before we always hard coded the laod & entry point to 0.
However there are situations that the kernel may be built with a non-zero
p
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 included which
includes . Wh recursive include.
CONFIG_PHYS_64BIT is a bit
* PAGE_OFFSET is not always the start of code, use _stext instead.
* grab PAGE_SIZE and KERNELBASE from asm/page.h like ppc64 does. Makes the
code a bit more common and provide a single place to manipulate the
defines for things like kdump.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
a
We always use __initial_memory_limit as an address so rename it
to be clear.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/mm/fsl_booke_mmu.c |2 +-
arch/powerpc/mm/init_32.c | 10 +-
arch/powerpc/mm/mmu_decl.h |2 +-
arch/powerpc/mm/ppc_mmu_32.c|
Now that we have a proper variable that is the address of the top
of low memory we can use it to limit the lmb allocations.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
include/asm-powerpc/lmb.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/l
* Determine the RPN we are running the kernel at runtime rather
than using compile time constant for initial TLB
* Cleanup adjust_total_lowmem() to respect memstart_addr and
be a bit more clear on variables that are sizes vs addresses.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/p
total_lowmem represents the amount of low memory not the physical address
that low memory ends at. If the start of memory is at 0 it happends that
total_lowmem can be used as both the size and the address that lowmem
ends at. (technical its one byte beyond the end)
To make the code a bit more cle
A number of users of PPC_MEMSTART (40x, ppc_mmu_32) can just always use
0 as we don't support booting these kernels at non-zero physical addresses
since their exception vectors must be at 0 (or 0xfffx_).
For the sub-arches that support relocatable interrupt vectors (book-e) its
reasonable to h
There does not appear to be any reason that we shouldn't just have
-Iarch/$(ARCH) on both ppc32 and ppc64 builds.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/Makefile | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/
Nothing appears to use BOOT_LOAD so remove it as a configurable option.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 625342e..c12111
* Updated the phys_addr_t patch to be a bit cleaner
* reworked order of patches a bit (bootwrapper now second to last)
* added patch to properly set physical address of PHDR
* reverted change in prom.c to use PHYSICAL_START & klimit for lmb_reserve
These patches exist in the following git tree:
On Wed, Apr 09, 2008 at 12:39:48PM -0500, Scott Wood wrote:
> Sascha Hauer wrote:
>> Right, so it's probably not worth the effort. I stumbled on this while
>> porting my board to the new binding code. I was quite confused when
>> seeing this so I made this fix to understand what's going on here.
>>
Hi,
I'm porting vanilla 2.6.25-rc8 (arch=powerpc) to a new board. UART is
already working in the kernel and Uboot with UART and ethernet is also
working.
But I can't get the emac driver (ibm_newemac) working under Linux.
On boot emac_init get's called and exits normally, but no probe or
open will g
On Thursday 10 April 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-04-02 at 17:12 +0200, Stefan Roese wrote:
>
>../..
>
> Overall looks good, just a few things:
Ben, thanks for the review.
> In general, while I have nothing against the idea of reading the HW
> setup left by uboot, I wond
[POWERPC] Clean up some linker and symbol usage
No comments. Straight forward patch.
Well, it is changing behaviour. In particular, klimit is not
necessarily the same as _end. It starts out initialized to &_end but
then gets advanced by some allocations very early in the boot IIRC.
It might
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
include/asm-powerpc/cpm.h | 14 ++
include/asm-powerpc/cpm1.h | 13 -
include/asm-powerpc/cpm2.h | 11 +--
3 files changed, 15 insertions(+), 23 deletions(-)
diff --git a/include/asm-powerpc/cpm.h b/in
On Wed, 2008-04-02 at 17:12 +0200, Stefan Roese wrote:
../..
Overall looks good, just a few things:
In general, while I have nothing against the idea of reading the HW
setup left by uboot, I wonder if it wouldn't be best to have this file
capable of fully configuring it in either mode based
Hi Jon,
On Saturday 12 January 2008 03:47, Jon Smirl wrote:
> Convert pfc8563 i2c driver from old style to new style. The
> driver is also modified to support device tree names via the
> i2c mod alias mechanism.
The patch breaks the pfc8563 driver.
The old style driver allocated memory for a pcf
Scott Wood schrieb:
Andre Schwarz wrote:
Scott Wood schrieb:
Andre Schwarz wrote:
-> find_legacy_serial_port()
stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED]
It looks like you have some memory corruption between here...
clocksource: timebase mult[3c1] shift[22] registered
!!!
1 - 100 of 102 matches
Mail list logo
