* RE: My kernel hangs after transferring control to linux
From: Pedro Luis D. L. @ 2007-08-06 10:40 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <380-220078167042554@M2W021.mail2web.com>
Ramesh wrote on Mon, 6 Aug 2007 03:00:42 -0400
>
>Hi ,
> My kernel hangs after transferring control to linux ,can any one
>help
>me out how to trace my problem .
>
>I have attached my u-boot.bin and memory layout of our board.
>
>I guess problem will be on the u-boot configuration i am missing something
>.Can any one tell me what todo next because i am getting struck with it for
>more than 2 weeks.I have attached the snap-shot of my problem.If anyone
>has faced similar issue can help me out. I have attached my bin file also
>for your refference.
>
>Regards
>Ramesh
>
Is the console parameter given to the kernel at boot time?
I had the same problem long time ago and it was solved giving the
console=ttyPSC0,115200 parameter in bootargs. You will need to give the
appropriate parameter depending on your hardware, of course.
Regards,
Pedro.
>--------------------------------------------------------------------
>mail2web.com – What can On Demand Business Solutions do for you?
>http://link.mail2web.com/Business/SharePoint
>
><< Memory >>
><< U-2.png >>
><< U-1.png >>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
Horóscopo, tarot, numerología... Escucha lo que te dicen los astros.
http://astrocentro.msn.es/
^ permalink raw reply
* Re: [PATCH 1/1] lro: Generic Large Receive Offload for TCP traffic
From: Jan-Bernd Themann @ 2007-08-06 7:51 UTC (permalink / raw)
To: Jörn Engel
Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Christoph Raisch, Marcus Eder,
Andrew Gallatin, Stefan Roscher, David Miller
In-Reply-To: <20070803134150.GH19344@lazybastard.org>
Hi J=C3=B6rn
On Friday 03 August 2007 15:41, J=C3=B6rn Engel wrote:
> On Fri, 3 August 2007 14:41:19 +0200, Jan-Bernd Themann wrote:
> >=20
> > This patch provides generic Large Receive Offload (LRO) functionality
> > for IPv4/TCP traffic.
> >=20
> > LRO combines received tcp packets to a single larger tcp packet and=20
> > passes them then to the network stack in order to increase performance
> > (throughput). The interface supports two modes: Drivers can either pass
> > SKBs or fragment lists to the LRO engine.=20
>=20
> Maybe this is a stupid question, but why is LRO done at the device
> driver level?
>=20
> If it is a unversal performance benefit, I would have expected it to be
> done generically, i.e. have all packets moved into network layer pass
> through LRO instead.
The driver seems to be the right place:
=2D There is the "page mode" interface that accepts fragment lists instead=
of
SKBs and does generate SKBs only in the end (see Andrew Gallatins=20
mails where he described the advantages of this approach)
=2D Some drivers (in particular for 10G NICs which actually could benefit
from LRO) have multiple HW receive queues that do some sort of sorting,
thus using one lro_mgr per queue increases the likelyhood of beeing able
to do efficient LRO.
=20
> > +void lro_flush_pkt(struct net_lro_mgr *lro_mgr,
> > + struct iphdr *iph, struct tcphdr *tcph);
> In particular this bit looks like it should be driven by a timeout,
> which would be settable via /proc/sys/net/core/lro_timeout or similar.
No, this function is needed for "page mode" as some HW provides
extra handling for small packets where packets are not stored in preallocat=
ed=20
pages but in extra queues. Thus the driver needs a way to flush old sessions
for this connection and handle these packets in a different way (for exampl=
e=20
create a SKB and copy the data there).
Timeouts are not used at all. Experiments showed that flushing at the end=20
of a NAPI poll round seems to be sufficient (see Andrew's test results)
and does not affect the latency too badly.
Regards,
Jan-Bernd
^ permalink raw reply
* Re: [PATCH] lro: eHEA example how to use LRO
From: Jan-Bernd Themann @ 2007-08-06 7:01 UTC (permalink / raw)
To: Kok, Auke
Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Christoph Raisch, Marcus Eder,
Andrew Gallatin, Stefan Roscher, David Miller
In-Reply-To: <46B39030.7030009@intel.com>
Hi Auke,
On Friday 03 August 2007 22:29, Kok, Auke wrote:
> Jan-Bernd Themann wrote:
> > This patch shows how the generic LRO interface is used for SKB mode
> >
> > Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
> >
> > ---
> > drivers/net/Kconfig | 1 +
> > drivers/net/ehea/ehea.h | 9 ++++-
> > drivers/net/ehea/ehea_ethtool.c | 15 +++++++
> > drivers/net/ehea/ehea_main.c | 84 +++++++++++++++++++++++++++++++++++---
> > 4 files changed, 101 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > index f8a602c..fec4004 100644
> > --- a/drivers/net/Kconfig
> > +++ b/drivers/net/Kconfig
>
> <snip>
>
> > +module_param(use_lro, int, 0);
>
> Have you looked at my generic lro get/set patch that I posted this week? this
> adds a useless module parameter while ethtool has all the structure already to
> accomodate setting lro on/off.
>
Yes, I saw your patch. Looks very good to me. I will modify our driver soon
to use ethtool instead of this module parameter.
Thanks for adding this support to the ethtool interface.
^ permalink raw reply
* My kernel hangs after transferring control to linux
From: ramesh @ 2007-08-06 7:00 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 713 bytes --]
Hi ,
My kernel hangs after transferring control to linux ,can any one help
me out how to trace my problem .
I have attached my u-boot.bin and memory layout of our board.
I guess problem will be on the u-boot configuration i am missing something
.Can any one tell me what todo next because i am getting struck with it for
more than 2 weeks.I have attached the snap-shot of my problem.If anyone
has faced similar issue can help me out. I have attached my bin file also
for your refference.
Regards
Ramesh
--------------------------------------------------------------------
mail2web.com – What can On Demand Business Solutions do for you?
http://link.mail2web.com/Business/SharePoint
[-- Attachment #2: Memory --]
[-- Type: application/octet-stream, Size: 16384 bytes --]
[-- Attachment #3: U-2.png --]
[-- Type: image/png, Size: 151497 bytes --]
[-- Attachment #4: U-1.png --]
[-- Type: image/png, Size: 137241 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] powerpc clk.h interface for platforms
From: Domen Puncer @ 2007-08-06 6:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: David Brownell, linuxppc-dev, Sylvain Munaut
In-Reply-To: <20070711093220.GF4375@moe.telargo.com>
Hi!
Paul, what do you say about this?
Sylvain suggested it could also be integrated with define_machine
interface.
If it's OK, it would be cool if it got merged in next release cycle.
Domen
On 11/07/07 11:32 +0200, Domen Puncer wrote:
> clk interface for arch/powerpc, platforms should fill
> clk_functions.
>
> Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
>
> ---
> arch/powerpc/kernel/Makefile | 3 -
> arch/powerpc/kernel/clock.c | 82 ++++++++++++++++++++++++++++++++++++
> include/asm-powerpc/clk_interface.h | 20 ++++++++
> 3 files changed, 104 insertions(+), 1 deletion(-)
>
> Index: work-powerpc.git/arch/powerpc/kernel/clock.c
> ===================================================================
> --- /dev/null
> +++ work-powerpc.git/arch/powerpc/kernel/clock.c
> @@ -0,0 +1,82 @@
> +/*
> + * Dummy clk implementations for powerpc.
> + * These need to be overridden in platform code.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> +#include <linux/module.h>
> +#include <asm/clk_interface.h>
> +
> +struct clk_interface clk_functions;
> +
> +struct clk *clk_get(struct device *dev, const char *id)
> +{
> + if (clk_functions.clk_get)
> + return clk_functions.clk_get(dev, id);
> + return ERR_PTR(-ENOSYS);
> +}
> +EXPORT_SYMBOL(clk_get);
> +
> +void clk_put(struct clk *clk)
> +{
> + if (clk_functions.clk_put)
> + clk_functions.clk_put(clk);
> +}
> +EXPORT_SYMBOL(clk_put);
> +
> +int clk_enable(struct clk *clk)
> +{
> + if (clk_functions.clk_enable)
> + return clk_functions.clk_enable(clk);
> + return -ENOSYS;
> +}
> +EXPORT_SYMBOL(clk_enable);
> +
> +void clk_disable(struct clk *clk)
> +{
> + if (clk_functions.clk_disable)
> + clk_functions.clk_disable(clk);
> +}
> +EXPORT_SYMBOL(clk_disable);
> +
> +unsigned long clk_get_rate(struct clk *clk)
> +{
> + if (clk_functions.clk_get_rate)
> + return clk_functions.clk_get_rate(clk);
> + return 0;
> +}
> +EXPORT_SYMBOL(clk_get_rate);
> +
> +long clk_round_rate(struct clk *clk, unsigned long rate)
> +{
> + if (clk_functions.clk_round_rate)
> + return clk_functions.clk_round_rate(clk, rate);
> + return -ENOSYS;
> +}
> +EXPORT_SYMBOL(clk_round_rate);
> +
> +int clk_set_rate(struct clk *clk, unsigned long rate)
> +{
> + if (clk_functions.clk_set_rate)
> + return clk_functions.clk_set_rate(clk, rate);
> + return -ENOSYS;
> +}
> +EXPORT_SYMBOL(clk_set_rate);
> +
> +struct clk *clk_get_parent(struct clk *clk)
> +{
> + if (clk_functions.clk_get_parent)
> + return clk_functions.clk_get_parent(clk);
> + return ERR_PTR(-ENOSYS);
> +}
> +EXPORT_SYMBOL(clk_get_parent);
> +
> +int clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> + if (clk_functions.clk_set_parent)
> + return clk_functions.clk_set_parent(clk, parent);
> + return -ENOSYS;
> +}
> +EXPORT_SYMBOL(clk_set_parent);
> Index: work-powerpc.git/include/asm-powerpc/clk_interface.h
> ===================================================================
> --- /dev/null
> +++ work-powerpc.git/include/asm-powerpc/clk_interface.h
> @@ -0,0 +1,20 @@
> +#ifndef __ASM_POWERPC_CLK_INTERFACE_H
> +#define __ASM_POWERPC_CLK_INTERFACE_H
> +
> +#include <linux/clk.h>
> +
> +struct clk_interface {
> + struct clk* (*clk_get) (struct device *dev, const char *id);
> + int (*clk_enable) (struct clk *clk);
> + void (*clk_disable) (struct clk *clk);
> + unsigned long (*clk_get_rate) (struct clk *clk);
> + void (*clk_put) (struct clk *clk);
> + long (*clk_round_rate) (struct clk *clk, unsigned long rate);
> + int (*clk_set_rate) (struct clk *clk, unsigned long rate);
> + int (*clk_set_parent) (struct clk *clk, struct clk *parent);
> + struct clk* (*clk_get_parent) (struct clk *clk);
> +};
> +
> +extern struct clk_interface clk_functions;
> +
> +#endif /* __ASM_POWERPC_CLK_INTERFACE_H */
> Index: work-powerpc.git/arch/powerpc/kernel/Makefile
> ===================================================================
> --- work-powerpc.git.orig/arch/powerpc/kernel/Makefile
> +++ work-powerpc.git/arch/powerpc/kernel/Makefile
> @@ -12,7 +12,8 @@ endif
>
> obj-y := semaphore.o cputable.o ptrace.o syscalls.o \
> irq.o align.o signal_32.o pmc.o vdso.o \
> - init_task.o process.o systbl.o idle.o
> + init_task.o process.o systbl.o idle.o \
> + clock.o
> obj-y += vdso32/
> obj-$(CONFIG_PPC64) += setup_64.o binfmt_elf32.o sys_ppc32.o \
> signal_64.o ptrace32.o \
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: Please pull powerpc.git merge branch
From: Zhang Wei-r63237 @ 2007-08-06 5:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18099.1109.83340.915328@cargo.ozlabs.ibm.com>
Hi, Paul,
How about following patches?
[PATCH 1/2] Add sysdev/pci_quirks.c file into PowerPC architecture with
ULI chip quirk functions.
URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040363.html
[PATCH 2/2] Remove ULI chip quirks functions from MPC8641HPCN and
MPC8544DS boards.
URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040364.html
[PATCH 1/3] Add a new member name to structure irq_host =20
URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039896.html
[PATCH 2/3] Add irq host name for all powerpc interrupt controllors.=20
URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039897.html
[PATCH 3/3] Add irq debugfs and virq_mapping for getting the virq=20
URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039895.html
Thanks!
Best Regards,
Zhang Wei
> -----Original Message-----
> From: linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.or
> g] On Behalf Of Paul Mackerras
> Sent: Friday, August 03, 2007 6:33 PM
> To: torvalds@linux-foundation.org
> Cc: linuxppc-dev@ozlabs.org
> Subject: Please pull powerpc.git merge branch
>=20
> Linus,
>=20
> Please do
>=20
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
>=20
> to get another batch of bug-fixes for powerpc.
>=20
> Thanks,
> Paul.
>=20
> arch/powerpc/kernel/entry_64.S | 3 +++
> arch/powerpc/kernel/pci_32.c | 5 ++++-
> arch/powerpc/kernel/smp.c | 9 +++------
> arch/powerpc/mm/hash_low_64.S | 6 ++++--
> arch/powerpc/mm/hash_utils_64.c | 2 +-
> arch/powerpc/mm/numa.c | 4 ++--
> arch/powerpc/mm/slb.c | 28=20
> ++++++++++++++++++----------
> arch/powerpc/platforms/cell/spufs/sched.c | 3 ++-
> arch/powerpc/platforms/powermac/feature.c | 6 ++++--
> arch/powerpc/platforms/ps3/setup.c | 2 +-
> include/asm-powerpc/mmu-hash64.h | 1 +
> include/asm-powerpc/pgtable-64k.h | 8 +++-----
> 12 files changed, 46 insertions(+), 31 deletions(-)
>=20
> Andre Detsch (1):
> [POWERPC] spufs: Fix affinity after introduction of=20
> node_allowed() calls
>=20
> Kevin Corry (1):
> [POWERPC] Fix num_cpus calculation in smp_call_function_map()
>=20
> Michael Ellerman (1):
> [POWERPC] Fix parse_drconf_memory() for 64-bit start addresses
>=20
> Michael Neuling (1):
> [POWERPC] Fixes for the SLB shadow buffer code
>=20
> Paul Mackerras (2):
> [POWERPC] Expand RPN field to 34 bits when using 64k pages
> [POWERPC] Fix special PTE code for secondary hash bucket
>=20
> Segher Boessenkool (2):
> [POWERPC] Fix a compile warning in pci_32.c
> [POWERPC] Fix a compile warning in powermac/feature.c
>=20
> Stephen Rothwell (1):
> [POWERPC] ps3: Fix section mismatch in ps3/setup.c
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: [patch 08/10] Bamboo DTS
From: David Gibson @ 2007-08-06 4:53 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070803161711.202342000@linux.vnet.ibm.com>
On Fri, Aug 03, 2007 at 11:09:08AM -0500, Josh Boyer wrote:
> AMCC Bamboo board DTS
All the compatible properties should have "XXXX-440ep" as the most
precise version, in addition to the more general strings.
> --- /dev/null
> +++ linux-2.6/arch/powerpc/boot/dts/bamboo.dts
> @@ -0,0 +1,248 @@
> +/*
> + * Device Tree Source for AMCC Bamboo
> + *
> + * Copyright (c) 2006, 2007 IBM Corp.
> + * Josh Boyer <jwboyer@linux.vnet.ibm.com>
> + *
> + * FIXME: Draft only!
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without
> + * any warranty of any kind, whether express or implied.
> + *
> + * To build:
> + * dtc -I dts -O asm -o bamboo.S -b 0 bamboo.dts
> + * dtc -I dts -O dtb -o bamboo.dtb -b 0 bamboo.dts
Can we ditch this "to build" boilerplate. It's just another thing
people frequently forget to update as they copy it from dts to dts.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 09/10] Bamboo board support
From: David Gibson @ 2007-08-06 4:55 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070803161711.324021000@linux.vnet.ibm.com>
On Fri, Aug 03, 2007 at 11:09:09AM -0500, Josh Boyer wrote:
> Add support for the AMCC Bamboo board
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 10/10] Bamboo zImage wrapper
From: David Gibson @ 2007-08-06 5:00 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070803161711.457497000@linux.vnet.ibm.com>
On Fri, Aug 03, 2007 at 11:09:10AM -0500, Josh Boyer wrote:
> Add a bootwrapper for the AMCC 440EP Bamboo Eval board. This also adds a
> common fixup_clock function for all 440EP(x) chips.
Ok, you have a separate bamboo.c and treeboot-bamboo.c, like with
ebony. However here, therer's only one outermost wrapper -
treeboot-bamboo.c which means there's not really any point to this
separation.
Do you know if there are Bamboo boards with old u-boot versions, or
some other bootloader which would make the separation worthwhile
later?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 05/10] 40x MMU
From: David Gibson @ 2007-08-06 4:34 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070803161710.809842000@linux.vnet.ibm.com>
On Fri, Aug 03, 2007 at 11:09:05AM -0500, Josh Boyer wrote:
> Add MMU definitions for 40x platforms. Also fixes two warnings in 40x_mmu.c.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 07/10] Fix 40x build
From: David Gibson @ 2007-08-06 4:39 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070803161711.059388000@linux.vnet.ibm.com>
On Fri, Aug 03, 2007 at 11:09:07AM -0500, Josh Boyer wrote:
> Remove inclusion of __res on 40x. We don't need it in arch/powerpc
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 03/10] Rename 44x bootwrapper
From: David Gibson @ 2007-08-06 4:36 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070803161710.524454000@linux.vnet.ibm.com>
On Fri, Aug 03, 2007 at 11:09:03AM -0500, Josh Boyer wrote:
> Rename the 44x.c wrapper file to 4xx.c. This will allow us to add common
> functions in a single file that can be shared across all of 4xx.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 04/10] 4xx bootwrapper reworks
From: David Gibson @ 2007-08-06 4:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070803161710.676644000@linux.vnet.ibm.com>
On Fri, Aug 03, 2007 at 11:09:04AM -0500, Josh Boyer wrote:
> Make the fixup_memsize function common for all of 4xx as several chips share
> the same SDRAM controller. Also add functions to reset 40x chips and quiesce
> the ethernet.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> ---
> arch/powerpc/boot/44x.h | 4 ----
> arch/powerpc/boot/4xx.c | 36 +++++++++++++++++++++++++++++++-----
> arch/powerpc/boot/4xx.h | 20 ++++++++++++++++++++
> arch/powerpc/boot/dcr.h | 2 ++
> arch/powerpc/boot/ebony.c | 3 ++-
> 5 files changed, 55 insertions(+), 10 deletions(-)
>
> --- linux-2.6.orig/arch/powerpc/boot/44x.h
> +++ linux-2.6/arch/powerpc/boot/44x.h
> @@ -10,10 +10,6 @@
> #ifndef _PPC_BOOT_44X_H_
> #define _PPC_BOOT_44X_H_
>
> -void ibm44x_fixup_memsize(void);
> -void ibm4xx_fixup_ebc_ranges(const char *ebc);
> -
> -void ibm44x_dbcr_reset(void);
> void ebony_init(void *mac0, void *mac1);
>
> #endif /* _PPC_BOOT_44X_H_ */
> --- linux-2.6.orig/arch/powerpc/boot/4xx.c
> +++ linux-2.6/arch/powerpc/boot/4xx.c
> @@ -21,8 +21,8 @@
> #include "reg.h"
> #include "dcr.h"
>
> -/* Read the 44x memory controller to get size of system memory. */
> -void ibm44x_fixup_memsize(void)
> +/* Read the 4xx SDRAM controller to get size of system memory. */
> +void ibm4xx_fixup_memsize(void)
> {
> int i;
> unsigned long memsize, bank_config;
> @@ -39,22 +39,48 @@ void ibm44x_fixup_memsize(void)
> dt_fixup_memory(0, memsize);
> }
>
> -#define SPRN_DBCR0 0x134
> -#define DBCR0_RST_SYSTEM 0x30000000
> +#define DBCR0_RST_SYSTEM 0x30000000
Rather than just removing these defines and using hardcoded values,
I'd prefer to see separate SPRN_DBCR0_40X and SPRN_DBCR0_44X defines.
[snip]
> +#define EMAC_RESET 0x20000000
> +#define MAL_RESET 0x80000000
I think the MAL_RESET definition should go in the same place as the
DCR number definition.
> +void ibm4xx_quiesce_eth(u32 *emac0, u32 *emac1)
> +{
As I think I said before, I'm not really happy with this being
hardcoded assuming exactly 2 ethernets.
> + /* Quiesce the MAL and EMAC(s) since PIBS/OpenBIOS don't do this for us */
> + if (emac0)
> + *emac0 = EMAC_RESET;
> + if (emac1)
> + *emac1 = EMAC_RESET;
> +
> + mtdcr(DCRN_MAL0_CFG, MAL_RESET);
> +}
[snip]
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-06 4:31 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <46B357D3.1040608@ru.mvista.com>
On Fri, Aug 03, 2007 at 08:29:07PM +0400, Sergei Shtylyov wrote:
> David Gibson wrote:
>
> > Duh, forgot to attach the actual patch. Here it is:
>
> > Index: working-2.6/Documentation/powerpc/booting-without-of.txt
> > ===================================================================
> > --- working-2.6.orig/Documentation/powerpc/booting-without-of.txt 2007-07-30 17:07:14.000000000 +1000
> > +++ working-2.6/Documentation/powerpc/booting-without-of.txt 2007-07-30 17:07:14.000000000 +1000
> > @@ -1757,45 +1757,23 @@ platforms are moved over to use the flat
> > };
> > };
> >
> > - j) Flash chip nodes
> > + j) CFI or JEDEC memory-mapped NOR flash
> >
> > Flash chips (Memory Technology Devices) are often used for solid state
> > file systems on embedded devices.
> >
> > - Required properties:
> > + - compatible : should contain the specific model of flash chip(s) used
> > + followed by either "cfi-flash" or "jedec-flash"
>
> Duh, have nearly forgotten to complain about "-flash" suffix. Isn't it
> superfluous?
For CFI, I guess so. But don't JEDEC standardise other things as well
as flash? I think "-flash" makes the description a bit more obvious,
but I'll be swayed if a few other people chime in with opinions on this.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-06 4:21 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <46B34E1F.5060009@ru.mvista.com>
On Fri, Aug 03, 2007 at 07:47:43PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> David Gibson wrote:
>
> >>>Index: working-2.6/Documentation/powerpc/booting-without-of.txt
> >>>===================================================================
> >>>--- working-2.6.orig/Documentation/powerpc/booting-without-of.txt 2007-07-30 17:07:14.000000000 +1000
> >>>+++ working-2.6/Documentation/powerpc/booting-without-of.txt 2007-07-30 17:07:14.000000000 +1000
> >>>@@ -1757,45 +1757,23 @@ platforms are moved over to use the flat
> >>> };
> >>> };
> >>>
> >>>- j) Flash chip nodes
> >>>+ j) CFI or JEDEC memory-mapped NOR flash
> >>>
> >>> Flash chips (Memory Technology Devices) are often used for solid state
> >>> file systems on embedded devices.
>
> >>>- Required properties:
> >>>+ - compatible : should contain the specific model of flash chip(s) used
> >>>+ followed by either "cfi-flash" or "jedec-flash"
>
> >> This "compatible" prop (and the node in whole) doesn't say a
> >>thing about how the flash is mapped into the CPU address space. I
> >>strongly disagree that this node provides enough info to select a
> >>driver. :-/
>
> > To be honest, I'm not sure that describing the mapping is really the
> > job of the compatible property. That the flash is mapped into the
> > address space is kind of implicit in the way the reg interacts with
> > the parents' ranges property.
>
> Ah, I keep forgetting about implied 1:1 parent/child address
> correspondence... :-<
> But does it really imply how the (low) address bits of the *child* bus
> ("ebc" in this case) are connected to the chip? I don't think so...
>
> > Can you describe some of the options for *not* direct mapped flash
> > chips - I can't reasonably come up with a way of describing the
> > distinction when I've never seen NOR flash other than direct mapped.
>
> You're lucky to live in the single-endian world. Once you're in bi-endian
> one, all kinds of strange mappings become possible. I've seen the MIPS
> mapping driver which required swapping flash bytes in s/w in BE mode, i.e.
> couldn't be served by physmap, yet that's not all... here's the code of its
> map read*() methods:
Aha! Ok, now I understand the sorts of situations you're talking
about. By "not direct mapped", I thought you were talking about some
kind of access via address/data registers on some indirect bus
controller, rather than weird variations on endianness and
bit-swizzling.
Hrm.. this is a property of how the flash is wired onto the bus,
rather than of the flash chips themselves, so I'm not entirely sure
where description of it belongs.
Simplest option seems to me to add a property "endianness" or
"bit-swizzling" or something which can be defined to describe some odd
connections. If absent we'd default to direct mapping. Segher, is
that idea going to cause you to scream?
> >>>+ - reg : Address range of the flash chip
> >>>+ - bank-width : Width (in bytes) of the flash bank. Equal to the device width
> >>>+ times the number of interleaved chips.
> >>>+ - device-width : (optional) Width of a single flash chip. If omitted,
> >>>+ assumed to be equal to 'bank-width'.
>
> >> Why then not just introduce the "interleave" prop and obsolete the
> >>"bank-width"?
>
> > Because they're equivalent information, and bank-width is what the
> > code ends up actually caring about. I don't see any reason to prefer
> > giving the interleave.
>
> Well, "device-width" is not the thing that we care about either. ;-)
Well, yes but we need to encode it somehow. Segher preferred
device-width to interleave, because it's closer to a description of
the actual hardware, rather than an abstration decribing its wiring.
In other words I *still* don't see any reason to prefer giving the
interleave.
> >>>Index: working-2.6/drivers/mtd/maps/physmap_of.c
> >>>===================================================================
> >>>--- working-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-07-30 17:07:11.000000000 +1000
> >>>+++ working-2.6/drivers/mtd/maps/physmap_of.c 2007-07-30 17:07:14.000000000 +1000
> [...]
> >>>+ for (pp = dp->child, i = 0 ; pp; pp = pp->sibling, i++) {
> >>>+ const u32 *reg;
> >>>+ const char *name;
> >>>+ const void *ro;
> >>
> >> We hardly need the above 2 variables.
>
> > They're all used...
>
> I meant that there's no necessity in them.
By which you mean....?
> >> Oh, I see that the new partition representation have really simplified
> >>parsing -- this function is hardly shorter than the old one... :-P
>
> > They new format isn't supposed to be simpler to parse: it's supposed
> > to be more flexible if we ever need to add more per-partition
> > information than just the offset / size / read-only.
>
> Well, if we ever need that indeed... :-)
>
> [...]
>
> >>>@@ -221,6 +297,14 @@ err_out:
> >>>
> >>> static struct of_device_id of_physmap_match[] = {
> >>> {
> >>>+ .compatible = "cfi-flash",
> >>>+ .data = (void *)"cfi_probe",
> >>>+ },
> >>>+ {
> >>>+ .compatible = "jedec-flash",
> >>>+ .data = (void *)"jedec_probe",
> >>>+ },
> >>>+ {
>
> >> This would also trigger on non-linearly mapped CFI or JEDEC
> >>flashes which is not a good idea -- however, as we're using the MTD
> >>probing code anyway, it will just fail, so it's not luckily is not a
> >>fatal design flaw.
>
> > Well, if there's nothing else to distinguish them. Which there isn't
> > yet, but will need to be: see above about incomplete - helpful
> > suggestions about how to describe the mapping would be more useful
> > than merely pointing out the lack.
>
> I was thinking about adding "direct-mapped" prop... but maybe adding
> "ranges" to the parent node (that's "ebc") would indeed ensure that the flash
> is mapped 1:1 to the EBC's parent bus also.
The ebc already has a ranges property. But that can't describe the
sorts of bit-swizzling you're talking about.
> >>>Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
> >>>===================================================================
> >>>--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-07-30 17:07:14.000000000 +1000
> >>>+++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-07-30 17:07:14.000000000 +1000
>
> >>[...]
>
> >>>@@ -158,14 +161,20 @@
> >>> };
>
> >>> large-flash@2,0 {
>
> >> Hmm... what does @2,0 mean? :-O
>
> > EBC chip select 2, offset 0.
>
> Well, so this node is under some kind of local bus node -- that's good.
> Didn't know that the spec allows commas after @...
Well, now you do. I believe USB usually uses that format, too.
> >>>- device_type = "rom";
> >>>- compatible = "direct-mapped";
> >>>- probe-type = "JEDEC";
> >>>+ compatible = "jedec-flash";
> >>> bank-width = <1>;
> >>>- partitions = <0 380000
> >>>- 380000 80000>;
> >>>- partition-names = "fs", "firmware";
> >>>+// partitions = <0 380000
> >>>+// 380000 80000>;
> >>>+// partition-names = "fs", "firmware";
> >>> reg = <2 0 400000>;
> >>>+ #address-cells = <1>;
> >>>+ #size-cells = <1>;
>
> >> Heh...
>
> > Yeah, that bit's a bit ugly, I'll grant you.
>
> Don't we need "ranges" here, at least from the formal PoV -- as the parent
> and child address spaces differ? I know the physmap_of parser doesn't care but
> still...
That's one I've wondered about. To describe the partitions address
space as lying (ultimately) in the physical address space, which in a
sense it does, yes we'd need a ranges property here. But we also have
a 'reg' at the top level which would overlap with that hypothetical
ranges which would be weird. Or we could exclude the top-level reg,
but then that's a pain if we do want to map the flash as a whole.
So I left out ranges, on the grounds that there isn't actually
anything at present which will attempt to access flash partitions
"generically" as a device tree device.
I'm not sold on this approach, but I haven't heard you give a better
argument yet.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Uncompressing Kernel Image ... Error: inflate() returned -3 GUNZIP ERROR - must RESET board to recover
From: Nethra @ 2007-08-06 4:16 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <137d01c6e288$844fcdd0$8119fea9@deltatau.local>
change ur bootm address it will work fine....
see the fallowing example..
Linux crashes when uncompressing the kernel
Question:
When I try to boot Linux, it crashes during uncompressing the kernel image:
=3D> bootm 100000
## Booting image at 00100000 ...
Image Name: Linux=E2=88=922.4.25
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1003065 Bytes =3D 979.6 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... Error: inflate() returned =E2=88=923
GUNZIP ERROR =E2=88=92 must RESET board to recover
Answer:
Your kernel image is quite big =E2=88=92 nearly 1 MB compressed; when it ge=
ts
uncompressed it will need 2.5
... 3 MB, starting at address 0x0000. But your compressed image was stored
at 1 MB (0x100000), so
the uncompressed code will overwrite the (remaining) compressed image. The
solution is thus simple:
just use a higher address to download the compressed image into RAM. For
example, try:
=3D> bootm 400000
Henry Bausley wrote:
>=20
> I am getting the error
>=20
> Uncompressing Kernel Image ... Error: inflate() returned -3
> GUNZIP ERROR - must RESET board to recover
> OK
>=20
> when u-boot tries to uncompress the kernel. I am using a board based upo=
n
> a=20
> Yosemite AMCC 440EP.
> I do have some boards that work. Does anyone know what could cause this=
=20
> problem. Bad Flash , Bad DDR ?
>=20
>=20
>=20
>=20
>=20
>=20
> U-Boot 1.1.4 (Jun 30 2006 - 14:55:59)
>=20
> CPU: AMCC PowerPC 440EP Rev. B at 533.333 MHz (PLB=3D133, OPB=3D66, EBC=
=3D66=20
> MHz)
> I2C boot EEPROM enabled
> Internal PCI arbiter disabled, PCI async ext clock used
> 32 kB I-Cache 32 kB D-Cache
> Board: Yosemite - AMCC PPC440EP Evaluation Board
> I2C: ready
> DRAM: 256 MB
> FLASH: 64 MB
> PCI: Bus Dev VenId DevId Class Int
> In: serial
> Out: serial
> Err: serial
> Net: ppc_4xx_eth0, ppc_4xx_eth1
> Hit any key to stop autoboot: 0
> ## Booting image at fc000000 ...
> Image Name: Linux-2.6.14-rtl
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1250069 Bytes =3D 1.2 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... Error: inflate() returned -3
> GUNZIP ERROR - must RESET board to recover
> OK
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
--=20
View this message in context: http://www.nabble.com/Asterisk-on-Embedded-Li=
nux-tf2336671.html#a12010845
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: David Gibson @ 2007-08-06 4:02 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA303156076@az33exm25.fsl.freescale.net>
On Fri, Aug 03, 2007 at 02:55:16PM -0700, Yoder Stuart-B08248 wrote:
>
> > > > > + MPIC: interrupt-controller@d {
> > > > > + device_type = "open-pic";
> > > > >
> > > > > device_type = "interrupt-controller".
> > >
> > > Not according to the binding in booting-without-of.txt
> >
> > My understanding here, though possibly flawed, is that the current
> > implementation has "open-pic" but _should_ have "interrupt-controller"
> > as that is the officially correct name.
> >
> > I _think_ this means we need a transitional period where we update
> > the code to look for "interrupt-controller", and obsoletedly, looks
> > for the "open-pic", while we transition to the new, correct name.
>
> "open-pic" is the correct value for the device_type property.
> See the binding at:
> http://playground.sun.com/1275/bindings/chrp/chrp1_8a.ps
> That is the definition for open pic interrupt controllers (AFAIK).
>
> I am not aware of any official binding with "interrupt-controller"
> as the device_type.
That's what I thought.
> However, the interrupt mapping spec says that all interrupt
> controller (regardless of device_type) must have a
> property named "interrupt-controller" to identify
> the device node as an interrupt controller and root of
> a interrupt tree.
> See: http://playground.sun.com/1275/practice/imap/imap0_9d.html
Ah, yes. Added to both the mpic and 8259.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 02/10] 4xx Kconfig cleanup
From: David Gibson @ 2007-08-04 7:45 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070803161710.335369000@linux.vnet.ibm.com>
On Fri, Aug 03, 2007 at 11:09:02AM -0500, Josh Boyer wrote:
> Remove some leftover cruft in the 40x Kconfig file. Also make sure we
> select WANT_DEVICE_TREE for 40x.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> ---
> arch/powerpc/platforms/40x/Kconfig | 77 ---------------------------------
> arch/powerpc/platforms/Kconfig.cputype | 1
> 2 files changed, 1 insertion(+), 77 deletions(-)
>
> --- linux-2.6.orig/arch/powerpc/platforms/40x/Kconfig
> +++ linux-2.6/arch/powerpc/platforms/40x/Kconfig
> @@ -1,16 +1,3 @@
> -config 4xx
> - bool
> - depends on 40x || 44x
> - default y
You've removed this one, but I don't see you re-add it anywhere. We
still need to define the CONFIG_4xx symbol or things will break..
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Benjamin Herrenschmidt @ 2007-08-05 22:04 UTC (permalink / raw)
To: Stefan Richter
Cc: Robert Hancock, linuxppc-dev, stable, linux-kernel, Olaf Hering
In-Reply-To: <46B5824B.1000103@s5r6.in-berlin.de>
On Sun, 2007-08-05 at 09:54 +0200, Stefan Richter wrote:
> Benjamin Herrenschmidt wrote:
> >>> If setting 32-bit DMA mask fails on ppc64, that sounds like a problem
> >>> with the DMA implementation on that architecture. There are enough cards
> >>> out there that only support 32-bit DMA that this really needs to work..
> >> Yes, could the PPC folks please have a look at it? Thanks.
> >
> > Smells like we may have a bug there. No worries though, all current PPC
> > machines have an iommu that will not give out addresses above 32 bits
> > anyway, but I'll double check what's up.
> >
> > Do you see something in dmesg when that happens ?
>
> There was nothing in Olaf's report, except for trouble in sbp2 _after_
> the failure. http://lkml.org/lkml/2007/8/1/344 (I don't have a PMac.)
Hrm, allright, that's a bit weird. Olaf machine has only 256M of RAM
according to that dmesg, and thus, the kernel isn't enabling the iommu,
we use the "trivial" version of the dma mapping ops.
I suspect we have a bug in our imlementation of set_dma_mask though, in
that it does the "dma_supported" check using the previous mask and not
the one passed in :-)
The implementation of dma_supported that we hit in the no-iommu case
looks like that:
static int dma_direct_dma_supported(struct device *dev, u64 mask)
{
/* Could be improved to check for memory though it better be
* done via some global so platforms can set the limit in case
* they have limited DMA windows
*/
return mask >= DMA_32BIT_MASK;
}
So that should have worked. (The comment is a bit obscure, just ignore
it for now).
However, as I said above, our dma_set_mask() wrapper uses the wrong
value (the old, not the new mask). But that still should have worked
since the default dma mask for a PCI device is 0xffffffff....
Thus at this stable, I'm a bit at a loss of why it didn't work, I'll
have to test on one of those machines with some printk's in when I
manage to get to work (dunno when, kid's sick so I may have to stay home
today).
BTW. Any reason why you don't set the DMA mask in the ohci driver rather
than the sbp2 one ?
Cheers,
Ben.
^ permalink raw reply
* Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
From: Arnd Bergmann @ 2007-08-05 21:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jon Loeliger, Guennadi Liakhovetski, linux-serial
In-Reply-To: <Pine.LNX.4.60.0708052336360.4120@poirot.grange>
On Sunday 05 August 2007, Guennadi Liakhovetski wrote:
>
> > I supect it will have the same issue in the end, right?
>
> ...if you choose to use of_serial.c, yes, if you don't use it and just use
> legacy_serial.c, then you're fine.
But of_serial can be a loadable module, which means you still get into
trouble if you load it, even if the port was originally initialized
by legacy_serial.
Maybe the best solution would be for 824[15] to not claim compatibility
with 8250 at all then. If the device tree contains an entry that matches
what the generic driver looks for, it better be something that can
be handled by that driver.
Arnd <><
^ permalink raw reply
* Re: "Badness at kernel/irq/resend.c:70" on boot - via-pmu?
From: Benjamin Herrenschmidt @ 2007-08-05 21:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: linuxppc-dev, Ingo Molnar, paulus, Linux Kernel Mailing List
In-Reply-To: <alpine.LFD.0.999.0708042139300.5037@woody.linux-foundation.org>
On Sat, 2007-08-04 at 21:41 -0700, Linus Torvalds wrote:
>
> On Sun, 5 Aug 2007, Paul Collins wrote:
> >
> > I got the message below on boot with 2.6.23-rc2 on my PowerBook.
>
> It's a debug message, I think we need to remove it. It's trying to figure
> out what goes wrong with one particular machine, and I probably shouldn't
> have merged it for mainline.
>
> Ignore it, it will be gone soon enough, and it should happen just once per
> boot.
Actually, it's interesting as that irq shouldn't hit that path :-) Not
critical (won't break anything), but still something I'll look into just
in case it hides something bad.
Cheers,
Ben.
^ permalink raw reply
* Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
From: Jon Loeliger @ 2007-08-05 21:50 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-serial, Arnd Bergmann
In-Reply-To: <Pine.LNX.4.60.0708052336360.4120@poirot.grange>
So, like, the other day Guennadi Liakhovetski mumbled:
> On Sun, 5 Aug 2007, Jon Loeliger wrote:
>
> ...if you choose to use of_serial.c, yes, if you don't use it and just use
> legacy_serial.c, then you're fine.
Ah, I see. OK.
> BTW, my offer still holds to see if we can build a single kernel for both
> with just specific device-trees, but that's a separate matter:-)
Indeed. I'm fully on-board with that goal, but it may take a couple
rounds to refine it into that state.
One question I have is the stupid ethernet driver. Is the driver
that is in mainline now usable on the StorCenter? I haven't
waded through the supplied vendor patch to verify how it compares
to the r8169 in mainline yet.
Also, what do you want to do about the Kconfig set up for these then?
Specifically, do you want to have "TurboStation" and "StorCenter"?
Or would it make more sense to have something like a generic
"NAS8241" with sub-choices of "storcenter" and "turbostation"?
Thanks,
jdl
^ permalink raw reply
* Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
From: Guennadi Liakhovetski @ 2007-08-05 21:39 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, linux-serial, Arnd Bergmann
In-Reply-To: <E1IHnhY-0008PO-IZ@jdl.com>
On Sun, 5 Aug 2007, Jon Loeliger wrote:
> So, like, the other day Arnd Bergmann mumbled:
> > On Sunday 05 August 2007, Guennadi Liakhovetski wrote:
> > > That would be a possibility, but that would mean all 8241/8245 have to
> > > adjust their .dts. Ok, there are not so many of them in the mainline now
> > > (in fact, hardly any apart from linkstation:-)), still. Cannot we use
>
> Heck, I'm slowly working on the StorCenter too.. :-)
>
> I supect it will have the same issue in the end, right?
...if you choose to use of_serial.c, yes, if you don't use it and just use
legacy_serial.c, then you're fine.
BTW, my offer still holds to see if we can build a single kernel for both
with just specific device-trees, but that's a separate matter:-)
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
From: Jon Loeliger @ 2007-08-05 21:31 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Guennadi Liakhovetski, linux-serial
In-Reply-To: <200708051841.17471.arnd@arndb.de>
So, like, the other day Arnd Bergmann mumbled:
> On Sunday 05 August 2007, Guennadi Liakhovetski wrote:
> > That would be a possibility, but that would mean all 8241/8245 have to
> > adjust their .dts. Ok, there are not so many of them in the mainline now
> > (in fact, hardly any apart from linkstation:-)), still. Cannot we use
Heck, I'm slowly working on the StorCenter too.. :-)
I supect it will have the same issue in the end, right?
jdl
^ permalink raw reply
* Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
From: Arnd Bergmann @ 2007-08-05 16:41 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <Pine.LNX.4.60.0708051600550.4120@poirot.grange>
On Sunday 05 August 2007, Guennadi Liakhovetski wrote:
> That would be a possibility, but that would mean all 8241/8245 have to
> adjust their .dts. Ok, there are not so many of them in the mainline now
> (in fact, hardly any apart from linkstation:-)), still. Cannot we use
> something already available to just check if we're running on such a CPU?
> Worst case - find and parse cpu node, or maybe using some cpu_feature?
It's fundamentally a property of the serial controller implementation,
not of the processor, so the cpu_features are the wrong place to put
this. There should at least be a generic way to define thsi in the device
tree so that _future_ trees can just mark the port as compatible with
one that has this bug.
If you want to work around existing systems that don't mention this
in the device_tree, you could perhaps use machine_is(foo) to test
for it.
Another option altogether would be to allow the device node to
specify the linux specific serial port flags in a separate property,
like "linux,uart-port-flags" that contains the same flags that
setserial can set from user space. That would also be useful
if you want to specify UPF_MAGIC_MULTIPLIER on certain high-speed
ports, because it cannot be autoprobed.
Arnd <><
^ 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