* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Linas Vepstas @ 2007-09-27 21:35 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927211700.201970@gmx.net>
On Thu, Sep 27, 2007 at 11:17:00PM +0200, Gerhard Pircher wrote:
> > Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
>
> Do you have an idea how to debug it?
Not particularly. What caught my eye was the failure right near the
PCI quirk stuff, as I was having problems there as well (but apearntly,
for very different reasons). Based on your boot messages, it looks
like you are failing somewhere in pci probe. My olde-fashioned, slow,
but-usually-works method is to sprinkle enough printk's into the code
to catch it in the act.
--linas
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Kumar Gala @ 2007-09-27 21:40 UTC (permalink / raw)
To: ljd015; +Cc: linuxppc-embedded
In-Reply-To: <11909173512321-git-send-email-ljd015@freescale.com>
On Sep 27, 2007, at 1:22 PM, ljd015@freescale.com wrote:
> From: Joe D'Abbraccio <ljd015@freescale.com>
>
> The MPC837x RDB is a new member of the Freescale MPC83xx reference
> design
> boards.
>
> Signed-off-by: Joe D'Abbraccio <ljd015@freescale.com>
Please base your patch against an external tree (like my for-2.6.24
branch).
See comments inline.
- k
> ---
> arch/powerpc/boot/dts/mpc8377_rdb.dts | 306 ++++++++++
> arch/powerpc/boot/dts/mpc8378_rdb.dts | 286 +++++++++
> arch/powerpc/boot/dts/mpc8379_rdb.dts | 281 +++++++++
> arch/powerpc/configs/mpc837x_rdb_defconfig | 886 +++++++++++++++++
> +++++++++++
> arch/powerpc/platforms/83xx/Kconfig | 8 +-
> arch/powerpc/platforms/83xx/Makefile | 1 +
> arch/powerpc/platforms/83xx/mpc837x_rdb.c | 102 ++++
> 7 files changed, 1869 insertions(+), 1 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/mpc8377_rdb.dts
> create mode 100644 arch/powerpc/boot/dts/mpc8378_rdb.dts
> create mode 100644 arch/powerpc/boot/dts/mpc8379_rdb.dts
> create mode 100644 arch/powerpc/configs/mpc837x_rdb_defconfig
> create mode 100644 arch/powerpc/platforms/83xx/mpc837x_rdb.c
>
> diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/
> boot/dts/mpc8377_rdb.dts
> new file mode 100644
> index 0000000..1ee2a06
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
> @@ -0,0 +1,306 @@
> +/*
> + * MPC8377E RDB Device Tree Source
> + *
> + * Copyright 2005, 2006, 2007 Freescale Semiconductor Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + */
> +
> +/ {
> + model = "fsl,mpc8377erdb";
> + compatible = "fsl,mpc8377erdb","fsl,mpc837xrdb";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,837x@0 {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <20>;
> + i-cache-line-size = <20>;
> + d-cache-size = <8000>; // L1, 32K
> + i-cache-size = <8000>; // L1, 32K
> + timebase-frequency = <0>;
> + bus-frequency = <0>;
> + clock-frequency = <0>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <00000000 10000000>; // 256MB at 0
> + };
> +
> + soc837x@e0000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + ranges = <0 e0000000 00100000>;
> + reg = <e0000000 00000200>;
> + bus-frequency = <0>;
> +
> + wdt@200 {
> + device_type = "watchdog";
> + compatible = "mpc83xx_wdt";
> + reg = <200 100>;
> + };
> +
> + i2c@3000 {
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <3000 100>;
> + interrupts = <e 8>;
> + interrupt-parent = < &ipic >;
> + dfsrr;
> + };
> +
> + i2c@3100 {
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <3100 100>;
> + interrupts = <f 8>;
> + interrupt-parent = < &ipic >;
> + dfsrr;
> + };
> +
> + spi@7000 {
> + device_type = "spi";
> + compatible = "mpc83xx_spi";
> + reg = <7000 1000>;
> + interrupts = <10 8>;
> + interrupt-parent = < &ipic >;
> + mode = <0>;
> + };
> +
> + /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
> + usb@23000 {
> + device_type = "usb";
> + compatible = "fsl-usb2-dr";
> + reg = <23000 1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupt-parent = < &ipic >;
> + interrupts = <26 8>;
> + phy_type = "utmi_wide";
> + };
> +
> + mdio@24520 {
> + device_type = "mdio";
> + compatible = "gianfar";
> + reg = <24520 20>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy2: ethernet-phy@2 {
> + interrupt-parent = < &ipic >;
> + interrupts = <11 8>;
> + reg = <2>;
> + device_type = "ethernet-phy";
> + };
> + phy3: ethernet-phy@3 {
> + interrupt-parent = < &ipic >;
> + interrupts = <12 8>;
> + reg = <3>;
> + device_type = "ethernet-phy";
> + };
> + };
> +
> + ethernet@24000 {
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <24000 1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <20 8 21 8 22 8>;
> + phy-connection-type = "mii";
> + interrupt-parent = < &ipic >;
> + phy-handle = < &phy2 >;
> + };
> +
> + ethernet@25000 {
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <25000 1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <23 8 24 8 25 8>;
> + phy-connection-type = "mii";
> + interrupt-parent = < &ipic >;
> + phy-handle = < &phy3 >;
> + };
> +
> + serial@4500 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <4500 100>;
> + clock-frequency = <0>;
> + interrupts = <9 8>;
> + interrupt-parent = < &ipic >;
> + };
> +
> + serial@4600 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <4600 100>;
> + clock-frequency = <0>;
> + interrupts = <a 8>;
> + interrupt-parent = < &ipic >;
> + };
> +
> + pci@9000 {
> + device_type = "pci";
> + compatible = "fsl,mpc83xx-pex";
> + reg = <9000 1000>;
> + interrupt-parent = < &ipic >;
> + interrupts = <1 8>;
> + phy-handle = < &serdes2 >;
> + };
> +
> + pci@a000 {
> + device_type = "pci";
> + compatible = "fsl,mpc83xx-pex";
> + reg = <a000 1000>;
> + interrupt-parent = < &ipic >;
> + interrupts = <2 8>;
> + phy-handle = < &serdes2 >;
> + };
> +
remove these pci nodes since we don't have kernel support for pex on
83xx.
> + crypto@30000 {
> + device_type = "crypto";
> + model = "SEC2";
> + compatible = "talitos";
> + reg = <30000 7000>;
> + interrupts = <b 8>;
> + interrupt-parent = < &ipic >;
> + /* Rev. 2.2 */
> + num-channels = <1>;
> + channel-fifo-len = <18>;
> + exec-units-mask = <0000004c>;
> + descriptor-types-mask = <0122003f>;
> + };
> +
> + sdhc@2e000 {
> + model = "eSDHC";
> + compatible = "fsl,esdhc";
> + reg = <2e000 1000>;
> + interrupts = <2a 8>;
> + interrupt-parent = < &ipic >;
> + };
> +
> + sata@18000 {
> + device_type = "sata";
> + model = "SATA-300";
> + compatible = "fsl,sata300";
> + reg = <18000 1000>;
> + interrupts = <2c 8>;
> + interrupt-parent = < &ipic >;
> + phy-handle = < &serdes1 >;
> + };
> +
> + sata@19000 {
> + device_type = "sata";
> + model = "SATA-300";
> + compatible = "fsl,sata300";
> + reg = <19000 1000>;
> + interrupts = <2d 8>;
> + interrupt-parent = < &ipic >;
> + phy-handle = < &serdes1 >;
> + };
> +
> + serdes1:serdes@e3000 {
> + compatible = "fsl,serdes";
> + reg = <e3000 100>;
> + vdd-1v;
> + protocol = "sata";
> + clock = <d#100>;
> + };
> +
> + serdes2:serdes@e3100 {
> + model = "SerDes";
> + compatible = "fsl,serdes";
> + reg = <e3100 100>;
> + vdd-1v;
> + protocol = "pex";
> + clock = <d#100>;
> + };
remove sata, sdhc, and serdes until the device binding patches that
describe these are posted.
> +
> + /* IPIC
> + * interrupts cell = <intr #, sense>
> + * sense values match linux IORESOURCE_IRQ_* defines:
> + * sense == 8: Level, low assertion
> + * sense == 2: Edge, high-to-low change
> + */
> + ipic: pic@700 {
> + compatible = "fsl,ipic";
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = <700 100>;
> + };
> + };
> +
> + pci@e0008500 {
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <
> +
> + /* IDSEL 0x11 */
> + 8800 0 0 1 &ipic 14 8
> + 8800 0 0 2 &ipic 15 8
> + 8800 0 0 3 &ipic 16 8
> + 8800 0 0 4 &ipic 17 8
> +
> + /* IDSEL 0x12 */
> + 9000 0 0 1 &ipic 16 8
> + 9000 0 0 2 &ipic 17 8
> + 9000 0 0 3 &ipic 14 8
> + 9000 0 0 4 &ipic 15 8
> +
> + /* IDSEL 0x13 */
> + 9800 0 0 1 &ipic 17 8
> + 9800 0 0 2 &ipic 14 8
> + 9800 0 0 3 &ipic 15 8
> + 9800 0 0 4 &ipic 16 8
> +
> + /* IDSEL 0x15 */
> + a800 0 0 1 &ipic 14 8
> + a800 0 0 2 &ipic 15 8
> + a800 0 0 3 &ipic 16 8
> + a800 0 0 4 &ipic 17 8
> +
> + /* IDSEL 0x16 */
> + b000 0 0 1 &ipic 17 8
> + b000 0 0 2 &ipic 14 8
> + b000 0 0 3 &ipic 15 8
> + b000 0 0 4 &ipic 16 8
> +
> + /* IDSEL 0x17 */
> + b800 0 0 1 &ipic 16 8
> + b800 0 0 2 &ipic 17 8
> + b800 0 0 3 &ipic 14 8
> + b800 0 0 4 &ipic 15 8
> +
> + /* IDSEL 0x18 */
> + c000 0 0 1 &ipic 15 8
> + c000 0 0 2 &ipic 16 8
> + c000 0 0 3 &ipic 17 8
> + c000 0 0 4 &ipic 14 8>;
> + interrupt-parent = < &ipic >;
> + interrupts = <42 8>;
> + bus-range = <0 0>;
> + ranges = <02000000 0 90000000 90000000 0 10000000
> + 42000000 0 80000000 80000000 0 10000000
> + 01000000 0 00000000 e2000000 0 00100000>;
> + clock-frequency = <0>;
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + reg = <e0008500 100>;
> + compatible = "fsl,mpc83xx-pci", "83xx";
> + device_type = "pci";
> + };
> +};
(above comments apply to other .dts)
[snip]
> diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/
> platforms/83xx/Kconfig
> index 0c61e7a..76a623b 100644
> --- a/arch/powerpc/platforms/83xx/Kconfig
> +++ b/arch/powerpc/platforms/83xx/Kconfig
> @@ -55,6 +55,12 @@ config MPC837x_MDS
> select DEFAULT_UIMAGE
> help
> This option enables support for the MPC837x MDS Processor Board.
> +
> +config MPC837x_RDB
> + bool "Freescale MPC837x RDB"
> + select DEFAULT_UIMAGE
> + help
> + This option enables support for the MPC837x RDB Board.
> endchoice
>
> config PPC_MPC831x
> @@ -86,4 +92,4 @@ config PPC_MPC837x
> select PPC_UDBG_16550
> select PPC_INDIRECT_PCI
> select FSL_SERDES
FSL_SERDES doesn't exist in any tree at this point.
> - default y if MPC837x_MDS
> + default y if MPC837x_MDS || MPC837x_RDB
> diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/
> platforms/83xx/Makefile
> index df46629..d64c0ad 100644
> --- a/arch/powerpc/platforms/83xx/Makefile
> +++ b/arch/powerpc/platforms/83xx/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_MPC834x_ITX) += mpc834x_itx.o
> obj-$(CONFIG_MPC836x_MDS) += mpc836x_mds.o
> obj-$(CONFIG_MPC832x_MDS) += mpc832x_mds.o
> obj-$(CONFIG_MPC837x_MDS) += mpc837x_mds.o
> +obj-$(CONFIG_MPC837x_RDB) += mpc837x_rdb.o
This patch will not apply since 837x_MDS doesn't exist.
> diff --git a/arch/powerpc/platforms/83xx/mpc837x_rdb.c b/arch/
> powerpc/platforms/83xx/mpc837x_rdb.c
> new file mode 100644
> index 0000000..132438f
> --- /dev/null
> +++ b/arch/powerpc/platforms/83xx/mpc837x_rdb.c
> @@ -0,0 +1,102 @@
> +/*
> + * arch/powerpc/platforms/83xx/mpc837x_rdb.c
> + *
> + * Copyright (C) 2007 Freescale Semicondutor, Inc. All rights
> reserved.
> + *
> + * MPC837x RDB board specific routines
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + */
> +
> +#include <linux/of_platform.h>
> +
> +#include <asm/time.h>
> +#include <asm/ipic.h>
> +#include <asm/udbg.h>
> +
> +#include "mpc83xx.h"
> +
> +#ifndef CONFIG_PCI
> +unsigned long isa_io_base;
> +unsigned long isa_mem_base;
> +#endif
> +
> +/*
> **********************************************************************
> **
> + *
> + * Setup the architecture
> + *
> + */
> +static void __init mpc837x_rdb_setup_arch(void)
> +{
> +#ifdef CONFIG_PCI
> + struct device_node *np;
> +#endif
> +
> + if (ppc_md.progress)
> + ppc_md.progress("mpc837x_rdb_setup_arch()", 0);
> +
> +#ifdef CONFIG_PCI
> + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> + add_bridge(np);
This should be somethine like:
for_each_node_by_type(np, "pci")
if (of_device_is_compatible(np, "fsl,mpc83xx-pci"))
add_bridge(np);
> +#endif
> +}
> +
> +static struct of_device_id mpc837x_ids[] = {
> + { .type = "soc", },
> + { .compatible = "soc", },
> + {},
> +};
> +
> +static int __init mpc837x_declare_of_platform_devices(void)
> +{
> + if (!machine_is(mpc837x_rdb))
> + return 0;
> +
> + /* Publish of_device */
> + of_platform_bus_probe(NULL, mpc837x_ids, NULL);
> +
> + return 0;
> +}
> +device_initcall(mpc837x_declare_of_platform_devices);
> +
> +static void __init mpc837x_rdb_init_IRQ(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,ipic");
> + if (!np)
> + return;
> +
> + ipic_init(np, 0);
> +
> + /* Initialize the default interrupt mapping priorities,
> + * in case the boot rom changed something on us.
> + */
> + ipic_set_default_priority();
> +}
> +
> +
> +/*
> + * Called very early, MMU is off, device-tree isn't unflattened
> + */
> +static int __init mpc837x_rdb_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + return of_flat_dt_is_compatible(root, "fsl,mpc837xrdb");
> +}
> +
> +define_machine(mpc837x_rdb) {
> + .name = "MPC837x RDB",
> + .probe = mpc837x_rdb_probe,
> + .setup_arch = mpc837x_rdb_setup_arch,
> + .init_IRQ = mpc837x_rdb_init_IRQ,
> + .get_irq = ipic_get_irq,
> + .restart = mpc83xx_restart,
> + .time_init = mpc83xx_time_init,
> + .calibrate_decr = generic_calibrate_decr,
> + .progress = udbg_progress,
> +};
> --
> 1.5.2.2
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Gerhard Pircher @ 2007-09-27 21:57 UTC (permalink / raw)
To: linas; +Cc: linuxppc-dev
In-Reply-To: <20070927213503.GA18686@austin.ibm.com>
-------- Original-Nachricht --------
> Datum: Thu, 27 Sep 2007 16:35:03 -0500
> Von: linas@austin.ibm.com
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> On Thu, Sep 27, 2007 at 11:17:00PM +0200, Gerhard Pircher wrote:
> > > Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> >
> > Do you have an idea how to debug it?
>
> Not particularly. What caught my eye was the failure right near the
> PCI quirk stuff, as I was having problems there as well (but apearntly,
> for very different reasons).
Yes, I also suspect the PCI code. The AmigaOne has a VIA southbridge.
AFAIK there were some changes in the PCI quirks for VIA chipsets, but so
far I couldn't see any significant changes in the code.
> Based on your boot messages, it looks like you are failing somewhere in
> pci probe. My olde-fashioned, slow, but-usually-works method is to
> sprinkle enough printk's into the code to catch it in the act.
I guess the code in arch/powerpc/pci*.c is the right place to sprinkle
some printk's into the code?
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas @ 2007-09-27 22:00 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070926150216.GH3899@parisc-linux.org>
On Wed, Sep 26, 2007 at 09:02:16AM -0600, Matthew Wilcox wrote:
> On Fri, Apr 20, 2007 at 03:47:20PM -0500, Linas Vepstas wrote:
> > Implement the so-called "first failure data capture" (FFDC) for the
> > symbios PCI error recovery. After a PCI error event is reported,
> > the driver requests that MMIO be enabled. Once enabled, it
> > then reads and dumps assorted status registers, and concludes
> > by requesting the usual reset sequence.
>
> > + /* Request that MMIO be enabled, so register dump can be taken. */
> > + return PCI_ERS_RESULT_CAN_RECOVER;
> > +}
>
> I'm a little concerned by the mention of MMIO. It's entirely possible
> for the sym2 driver to be using ioports to access the card rather than
> MMIO. Is it simply that it can't on the platform you test on?
The comment is misleading. I've been in the bad habit of calling
it "mmio" whenever its not DMA.
The habit is because there are two distinct enable bits in the
pci-host bridge during error recovery: one to enable mmio/ioports,
and the other to enable DMA. If the adapter has gone crazy, I don't
want to enable DMA, so that it doesn't scribble to bad places. But,
by enabling mmio/ioports, perhaps it can be finessed back into a
semi-sane state, e.g. sane enough to perform a dump of its internal
state.
--linas
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Benjamin Herrenschmidt @ 2007-09-27 22:08 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <20070927.202207.-1300525707.kouish@swc.toshiba.co.jp>
On Thu, 2007-09-27 at 20:22 +0900, Ishizaki Kou wrote:
> Ben-san,
>
> > On Thu, 2007-09-27 at 17:01 +0900, kou.ishizaki@toshiba.co.jp wrote:
> >
> > > Celleb does not set get_paca()->kstack properly (I don't know which
> > > function should set it up), so we need to workaround.
> >
> > paca->kstack is set in asm (via the PACAKSAVE macro), from either
> > __secondary_start for non-boot CPUs or from start_here_common for the
> > boot CPU.
> >
> > slb_flush_and_rebolt() should not be called before that happens.
> >
> > How do you end up with kstack set to 0 ?
>
> I found r13 is not set before entering start_here_common for boot cpu.
> For non-boot threads, __secondary_start will set r13 properly.
>
> So the problem is to set r13 correct PACA address before entering
> start_here_common. Should it set before entering kernel or will some
> patch make sense?
That is scary... we seem to have lost an mfsprg r13,SPRN_SPRG3 somewhere
along the way, I'm surprised things boot at all, or maybe I'm missing
something here... Paul ?
Ben.
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Matthew Wilcox @ 2007-09-27 22:10 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070927220022.GC18686@austin.ibm.com>
On Thu, Sep 27, 2007 at 05:00:22PM -0500, Linas Vepstas wrote:
> On Wed, Sep 26, 2007 at 09:02:16AM -0600, Matthew Wilcox wrote:
> > I'm a little concerned by the mention of MMIO. It's entirely possible
> > for the sym2 driver to be using ioports to access the card rather than
> > MMIO. Is it simply that it can't on the platform you test on?
>
> The comment is misleading. I've been in the bad habit of calling
> it "mmio" whenever its not DMA.
OK, cool, thanks. I'll update the comment for you.
One last thing (sorry, I only just noticed):
In the error handler, we wait_for_completion(io_reset_wait).
In sym2_io_error_detected, we init_completion(io_reset_wait).
Isn't it possible that we hit the error handler before we hit the
io_error_detected path, and thus the completion wait is lost?
Since the completion is already initialised in sym_attach(), I don't
think we need to initialise it in sym2_io_error_detected().
Makes sense to just delete it?
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Linas Vepstas @ 2007-09-27 22:20 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927215735.201960@gmx.net>
On Thu, Sep 27, 2007 at 11:57:35PM +0200, Gerhard Pircher wrote:
>
> > Based on your boot messages, it looks like you are failing somewhere in
> > pci probe. My olde-fashioned, slow, but-usually-works method is to
> > sprinkle enough printk's into the code to catch it in the act.
> I guess the code in arch/powerpc/pci*.c is the right place to sprinkle
> some printk's into the code?
The last identifiable message I was
<7>PCI: Calling quirk...
which is from drivers/pci/quirks.c
...CI: Found 0000:00:07.2 [1106/303...
and this is from pci_setup_device() in drivers/pci/probe.c So I'd look
to see if pci_setup_device() ever returned, and then I'd look to see
what happened next.
--linas
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Benjamin Herrenschmidt @ 2007-09-27 22:20 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <20070927.202207.-1300525707.kouish@swc.toshiba.co.jp>
On Thu, 2007-09-27 at 20:22 +0900, Ishizaki Kou wrote:
> Ben-san,
>
> > On Thu, 2007-09-27 at 17:01 +0900, kou.ishizaki@toshiba.co.jp wrote:
> >
> > > Celleb does not set get_paca()->kstack properly (I don't know which
> > > function should set it up), so we need to workaround.
> >
> > paca->kstack is set in asm (via the PACAKSAVE macro), from either
> > __secondary_start for non-boot CPUs or from start_here_common for the
> > boot CPU.
> >
> > slb_flush_and_rebolt() should not be called before that happens.
> >
> > How do you end up with kstack set to 0 ?
>
> I found r13 is not set before entering start_here_common for boot cpu.
> For non-boot threads, __secondary_start will set r13 properly.
>
> So the problem is to set r13 correct PACA address before entering
> start_here_common. Should it set before entering kernel or will some
> patch make sense?
It should have been set in setup_64.c, in setup_paca() (which is called
twice) in that statement:
local_paca = &paca[cpu];
As local_paca is defined as being a variable held in register r13. Maybe
something bad's happening with the compiler ?
Ben.
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Gerhard Pircher @ 2007-09-27 22:27 UTC (permalink / raw)
To: linas; +Cc: linuxppc-dev
In-Reply-To: <20070927222007.GE18686@austin.ibm.com>
-------- Original-Nachricht --------
> Datum: Thu, 27 Sep 2007 17:20:07 -0500
> Von: linas@austin.ibm.com
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> On Thu, Sep 27, 2007 at 11:57:35PM +0200, Gerhard Pircher wrote:
>
> The last identifiable message I was
>
> <7>PCI: Calling quirk...
>
> which is from drivers/pci/quirks.c
>
> ...CI: Found 0000:00:07.2 [1106/303...
>
> and this is from pci_setup_device() in drivers/pci/probe.c So I'd look
> to see if pci_setup_device() ever returned, and then I'd look to see
> what happened next.
Ah, I thought probing is done in the architecture's PCI code. I'll take
a look at pci_setup_device() function.
Thanks!
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Benjamin Herrenschmidt @ 2007-09-27 22:37 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <1190931617.6158.29.camel@pasglop>
> It should have been set in setup_64.c, in setup_paca() (which is called
> twice) in that statement:
>
> local_paca = &paca[cpu];
>
> As local_paca is defined as being a variable held in register r13. Maybe
> something bad's happening with the compiler ?
Can you check early_setup disassembly, see if r13 is assigned (it should
be in two spots) and if it's clobbered by the compiler somewhere ?
Also, you may want to try adding --ffixed-r13 to the CFLAGS in the
makefile and let us know if it makes a difference... r13 is marked
reserved by the ABI but segher seems to imply that gcc may decide to ues
it anyway (ouch !)
Ben.
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Benjamin Herrenschmidt @ 2007-09-27 22:39 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927222733.201970@gmx.net>
On Fri, 2007-09-28 at 00:27 +0200, Gerhard Pircher wrote:
> -------- Original-Nachricht --------
> > Datum: Thu, 27 Sep 2007 17:20:07 -0500
> > Von: linas@austin.ibm.com
> > An: Gerhard Pircher <gerhard_pircher@gmx.net>
> > CC: linuxppc-dev@ozlabs.org
> > Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
>
> > On Thu, Sep 27, 2007 at 11:57:35PM +0200, Gerhard Pircher wrote:
> >
> > The last identifiable message I was
> >
> > <7>PCI: Calling quirk...
> >
> > which is from drivers/pci/quirks.c
> >
> > ...CI: Found 0000:00:07.2 [1106/303...
> >
> > and this is from pci_setup_device() in drivers/pci/probe.c So I'd look
> > to see if pci_setup_device() ever returned, and then I'd look to see
> > what happened next.
> Ah, I thought probing is done in the architecture's PCI code. I'll take
> a look at pci_setup_device() function.
It's one of the quirks I suppose. Those are often full of x86 only
bogoziness that hurts everybody else if you happen to hit them.
The "late" quirks are called at pci_enable_device() time.
Ben
^ permalink raw reply
* Re: jffs2 file system on MPC8272ADS board
From: Detlev Zundel @ 2007-09-27 15:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <12900017.post@talk.nabble.com>
Hi Nethra,
> The other options I am wondering about,
> -c, --cleanmarker=SIZE Size of cleanmarker (default 12)
> -n, --no-cleanmarkers Don't add a cleanmarker to every eraseblock
> cleanmaker size will it help the cause?
Skimming through the thread I cannot tell whether you use NAND or NOR,
but on NAND flash, the cleanmarkers are actually in the out-of-band
area and thus *should not* be in the image, so for NAND we need the -n
option.
I don't think you should have to adjust the size, at least I never
needed this.
Best wishes
Detlev
--
I've been examining the existing [linux] kernel configuration system, and I
have about concluded that the best favor we could do everybody involved with
it is to take it out behind the barn and shoot it through the head.
-- Eric S. Raymond on linux-kbuild Mar 2000
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: [PATCH v4] Make instruction dumping work in real mode.
From: Michael Ellerman @ 2007-09-27 22:57 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070927183855.GA18226@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 639 bytes --]
On Thu, 2007-09-27 at 13:38 -0500, Scott Wood wrote:
> On non-book-E-or-4xx, exceptions execute in real mode. If a fault happens
> that leads to a register dump, the kernel currently prints XXXXXXXX because
> it doesn't realize that PC is a physical address.
>
> This patch checks the state of the IMMU, and if necessary converts PC into a
> virtual address.
IMMU ?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v4] Make instruction dumping work in real mode.
From: Scott Wood @ 2007-09-27 23:01 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, paulus
In-Reply-To: <1190933846.6601.1.camel@concordia>
Michael Ellerman wrote:
> On Thu, 2007-09-27 at 13:38 -0500, Scott Wood wrote:
>> On non-book-E-or-4xx, exceptions execute in real mode. If a fault happens
>> that leads to a register dump, the kernel currently prints XXXXXXXX because
>> it doesn't realize that PC is a physical address.
>>
>> This patch checks the state of the IMMU, and if necessary converts PC into a
>> virtual address.
>
> IMMU ?
Instruction Memory Management Unit.
-Scott
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Paul Mackerras @ 2007-09-27 23:31 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927191233.201980@gmx.net>
Gerhard Pircher writes:
> I'm working on a 2.6.23 kernel for the AmigaOne. I implemented the device
> tree and the platform setup code, which all compiles fine. I built a
> cuImage target, loaded it on my target machine with TFTP and booted it.
> The kernel passes the platform setup code and then dies somewhere in the
> driver init code (AFAICT), but before the keyboard driver is initialized
> (thus magic sysrq key doesn't work). Can somebody help me to track down
> this problem?
You appear to have a working 16550-style serial port which the udbg
infrastructure sees. Thus you should be able to use xmon, talking to
it via the serial port. Put "xmon" on the kernel command line and the
kernel will drop into xmon early in the boot process (in setup_arch).
Then, either the kernel will oops at some point and drop into xmon,
and you can then inspect memory and registers and get a stack trace,
or it will hang at some point. If it hangs, you can work out where it
hangs by putting in breakpoints at various points and seeing which
breakpoints you get to (this might take several boots).
Paul.
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas @ 2007-09-27 23:34 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070927221031.GY3899@parisc-linux.org>
On Thu, Sep 27, 2007 at 04:10:31PM -0600, Matthew Wilcox wrote:
> In the error handler, we wait_for_completion(io_reset_wait).
> In sym2_io_error_detected, we init_completion(io_reset_wait).
> Isn't it possible that we hit the error handler before we hit the
> io_error_detected path, and thus the completion wait is lost?
> Since the completion is already initialised in sym_attach(), I don't
> think we need to initialise it in sym2_io_error_detected().
> Makes sense to just delete it?
Good catch. But no ... and I had to study this a bit. Bear with me:
It is enough to call init_completion() once, and not once per use:
it initializes spinlocks, which shouldn't be intialized twice.
But, that completion might be used multiple times when there are
multiple errors, and so, before using it a second time, one must
set completion->done = 0. The INIT_COMPLETION() macro does this.
One must have completion->done = 0 before every use, as otherwise,
wait_for_completion() won't actually wait. And since complete_all()
sets x->done += UINT_MAX/2, I'm pretty sure x->done won't be zero
the next time we use it, unless we make it so.
So I need to find a place to safely call INIT_COMPLETION() again,
after the completion has been used. At the moment, I'm stumped
as to where to do this.
---- [think ... think ... think] ----
I think the race you describe above is harmless. The first time
that sym_eh_handler() will run, it will be with SYM_EH_ABORT,
in it doesn't matter if we lose that, since the device is hosed
anyway. At some later time, it will run with SYM_EH_DEVICE_RESET
and then SYM_EH_BUS_RESET and then SYM_EH_HOST_RESET, and we won't
miss those, since, by now, sym2_io_error_detected() will have run.
So, by my reading, I'd say that init_completion() in
sym2_io_error_detected() has to stay (although perhaps
it should be replaced by the INIT_COMPLETION() macro.)
Removing it will prevent correct operation on the second
and subsequent errors.
--Linas
^ permalink raw reply
* Re: [PATCH] add Altivec/VMX state to coredumps
From: Michael Ellerman @ 2007-09-27 23:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Carlos Eduardo Seo
In-Reply-To: <1D8E59FD-E8B1-446C-ABEE-D41F5496B518@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]
On Thu, 2007-09-27 at 05:10 -0500, Kumar Gala wrote:
> >>> You're probably right :)
> >>>
> >>> What cores have SPE at the moment? Also, perhaps more importantly,
> >>> are there any plans to have Altivec and SPE in the same core?
> >>
> >> The e500 cores's from Freescale.
> >>
> >> No, they are pretty much mutually exclusive.
> >>
> >>> I've been working with Carlos Eduardo Seo (Cc'ed on this mail) on
> >>> the GDB side of this.
> >>
> >> From comments it looks like the expectation is that the combination
> >> of note type and name which is expected to be unique.
> >>
> >> I'm wondering if we should handle this via
> >> elf_coredump_extra_notes_size() & elf_coredump_extra_notes_write().
> >> Does GDB care about the order it sees the various sections in?
> >
> > I don't think those callbacks will work in this case, they're only
> > called for the primary thread that's doing the coredump, not for each
> > thread. Perhaps there's a way to adapt it though.
> >
> > I think the easiest solution for now is just to make the note type a
> > #define and create a new value for Altivec.
>
> Oh, well. It shouldn't be too difficult to abstract vector handler
> similar to how we do GPRs today to the core dump code.
I'm not sure I follow, you mean elf_core_copy_regs() ?
If so, that's basically what we've done, the problem is that as with
elf_core_copy_regs(), although the content is abstracted and overridden
by arch code, the note type is not. But making the vector note type
configurable seems easy enough.
eg:
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 4482a06..7c8a145 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1624,7 +1624,7 @@ static int elf_core_dump(long signr, struct pt_regs *regs,
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(current, xfpu))
fill_note(notes + numnote++,
- "LINUX", NT_PRXFPREG, sizeof(*xfpu), xfpu);
+ "LINUX", ELF_CORE_XFPREGS_TYPE, sizeof(*xfpu), xfpu);
#endif
fs = get_fs();
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16
From: David Gibson @ 2007-09-28 2:40 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <41180fced14196db80f261d2ac1909e0@bga.com>
On Thu, Sep 27, 2007 at 10:44:27AM -0500, Milton Miller wrote:
>
> On Sep 26, 2007, at 9:45 PM, David Gibson wrote:
[snip]
> >> What's your souce for saying the were supposed to be backwards
> >> compatable? That dtc fills out the struct header so?
> >
> > Sitting next to BenH and knowing he always intended them to be so.
> >
> >> My source is my involvment when v2 was defined (they were discovered
> >> while writing my device tree generation code):
> >>
> >> The actual binary structure is compatable, just not the contents of
> >> the
> >> properties nor how any slave cpus wait (for some trees it doesn't
> >> matter).
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools-
> >> testing.git;a=blob;f=kexec/arch/ppc64/fs2dt.c;
> >> hb=b84b87747a16f0afbef6f6802bb794a94f4961d9
> >
> > An old version of fs2dt is hardly definitive. It could just be Plain
> > Wrong, nothing to do with the dt version.
>
> Sorry, copy and paste error. I was tring to point out this changelog
> in 2.6.10:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;
> a=commitdiff;h=e1b47549d1588ccea1fa5726eb430aae4e80f8ed
Hrm, I see, yes that seems conclusive enough. Yuck.
In which case, I think we should try to forget that v1 ever existed.
I don't think anyone ever generated v1 trees other than kernels which
also consumed them, and I doubt current kernels will correctly deal
with v1 trees in this form.
In any case, this is all rather beside the point. My basic point is
that this bootwrapper stuff should not attempt to be a general
backwards compatibility layer for every broken early dt format that
ever existed. In general we should try to make sure nothing ever uses
<v16 trees. We want, here, to do the minimum we can get away with to
support the specific v2 trees produced by kexec-tools, as an interim
measure while kexec-tools itself is fixed to produce v17 trees (say,
by replacing fs2dt with dtc plus a libfdt based post-processing
program).
--
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 3/3] mpc8349emitx.dts: Add ds1339 RTC
From: David Gibson @ 2007-09-28 2:45 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <9c20d018e890250443516b886317ceb9@kernel.crashing.org>
On Tue, Sep 25, 2007 at 10:33:58PM +0200, Segher Boessenkool wrote:
> >>> Hrm... we probably want an "i2c" device_type class, but I don't think
> >>> we've actually defined one, which is a problem
> >>
> >> By defining new device_type's, or new semantics for device_type,
> >> you open the door to (accidentally) becoming incompatible with
> >> "real" OF.
> >
> > Hrm... perhaps. But is it a realistic danger - I'll have to think
> > more about that.
>
> It is trivial to avoid these dangers completely by not overloading
> the meaning of "device_type".
Hrm. Perhaps.
> >>> I think we want to think a bit more carefully about how to do
> >>> bindings
> >>> for RTC devices. No "rtc" device_type is defined, but again we might
> >>> want to.
> >>
> >> Actually, "device_type" = "rtc" _is_ defined (in the "device support
> >> extensions" recommended practice), and there is no useful way a flat
> >> device tree can implement it (it merely defines get-time and set-time
> >> methods).
> >
> > Ah.. right. That changes things a bit, in that we might want to
> > include device_type purely for similarity with real OF tree.
>
> You should include the device_type only if you implement its binding,
> and a flat device tree does not, and cannot. (In almost all cases,
> a flat device tree cannot implement device_type's semantics -- this
> means that pretty much the only case where a flat tree should use
> device_type is to have it as a workaround for bad kernel requirements).
I really don't think there's an ambiguity here. A flat-tree can
clearly never implement runtime binding features. This is also true
for a flat tree derived from a real OF, and so full of device_type all
over the place.
> > Real OF has a device_type == "nvram" too, doesn't it?
>
> Yes, same "device support extensions" document.
Erm.. I've lost track amongst our various threads. Which same
document?
> > AFAICT the real
> > OF systems I have (which I think all have ISA-like CMOS RTC/NVRAM
> > chips) the RTC is labelled as "nvram" rather than "rtc".
>
> Sounds buggy.
Why?
[snip]
> > I did find one real OF binding for a different Dallas RTC (and NVRAM),
> > see:
> >
> > http://playground.sun.com/1275/proposals/Closed/Remanded/Accepted/346-
> > it.txt
> >
> > It's a little different from the example above.
>
> That is a binding for the nvram part only, not for the RTC.
Hrm. So how do you suggest we do bindings for combined devices?
--
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: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
From: Misbah khan @ 2007-09-28 4:28 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46FBD483.6090403@freescale.com>
Scott Wood-2 wrote:
>
> Misbah khan wrote:
>> Hi all I am using "test_bit(),set_bit(),clear_bit() etc" API functions
>> provided by the Linux kernel. I want to know that if anybody is used it
>> and have full faith in its operation then please let me know. Driver in
>> the while loop is calling these API's hence i want to make sure that its
>> operation will remain stable.
>
> They're used all over the place. Is there anything about them that you
> find suspect?
>
> -Scott
>
> I have devloped a character driver for FPGA which is memory mapped and
> using these API's to test a bit , set a bit or to clear a bit in the
> memory for eg :-
>
> /* poll till data is transfered from sdram to dpram */
> while((test_bit(DFR_BUSY,(UINT32 *)(\
> (void *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
> && (delay < MAX_DELAY_BUSY))
> {
> KDEBUG3(" In the Dfr delay loop \n");
> mdelay(DELAY);
> delay+=DELAY;
> }/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
>
> if(delay==MAX_DELAY_BUSY)
> {
> KDEBUG1("Out of the the Dfr busy loop \n");
> return -1;
> }
>
> People working for FPGA are sure that they are not making the bit high
> where in my driver is returning -1 from the kernel space aborting it after
> running for few minutes or so . Please let me know that This function is
> stable and i should tell them that the driver is stable in its operation
> and they should check it from there side.
>
> Misbah
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Is-it-safe-to-use-these-Linux-function-%28test_bit%28%29%2Cset_bit%28%29%2Cclear_bit%28%29%29-in-character-device-driver-for-2.6.10-ppc-kernel.-tf4527008.html#a12934517
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* libfdt: libfdt_env.h must be included first
From: David Gibson @ 2007-09-28 4:52 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
libfdt.h currently includes fdt.h, then libfdt_env.h. This is
incorrect, because depending on the environment into which libfdt is
embedded, libfdt_env.h may be needed to define datatypes used in
fdt.h. This patch corrects the problem.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-09-27 15:23:10.000000000 +1000
+++ dtc/libfdt/libfdt.h 2007-09-27 15:23:50.000000000 +1000
@@ -51,8 +51,8 @@
* EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-#include <fdt.h>
#include <libfdt_env.h>
+#include <fdt.h>
#define FDT_FIRST_SUPPORTED_VERSION 0x10
#define FDT_LAST_SUPPORTED_VERSION 0x11
--
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
* libfdt: Test rw functions on more trees
From: David Gibson @ 2007-09-28 4:57 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
At present, the testcases for read/write functions (setprop,
del_property and del_node) are only invoked on the single
asm-generated tree, not on any of the other tree images which should
be equivalent. The functions in question will (correctly) not work on
the "unfinished" tree output from sw_tree1, but should work on most of
the others.
This patch extends the run_tests script to invoke the r/w testcases on
more example trees. The testsuite still passes clean with this
addition.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2007-09-27 17:49:29.000000000 +1000
+++ dtc/tests/run_tests.sh 2007-09-27 17:57:00.000000000 +1000
@@ -49,6 +49,15 @@ tree1_tests () {
run_test nop_node $TREE
}
+tree1_tests_rw () {
+ TREE=$1
+
+ # Read-write tests
+ run_test setprop $TREE
+ run_test del_property $TREE
+ run_test del_node $TREE
+}
+
libfdt_tests () {
# Make sure we don't have stale blobs lying around
rm -f *.test.dtb
@@ -76,11 +85,16 @@ libfdt_tests () {
tree1_tests opened.$tree
tree1_tests repacked.$tree
done
- run_test setprop test_tree1.dtb
- run_test del_property test_tree1.dtb
- run_test del_node test_tree1.dtb
+
+ for tree in test_tree1.dtb sw_tree1.test.dtb; do
+ tree1_tests_rw $tree
+ tree1_tests_rw moved.$tree
+ tree1_tests_rw shunted.$tree
+ tree1_tests_rw deshunted.$tree
+ done
run_test rw_tree1
tree1_tests rw_tree1.test.dtb
+ tree1_tests_rw rw_tree1.test.dtb
# Tests for behaviour on various sorts of corrupted trees
run_test truncated_property
@@ -92,6 +106,7 @@ dtc_tests () {
run_test dtc.sh -f -I dts -O dtb -o dtc_tree1.test.dtb test_tree1.dts
tree1_tests dtc_tree1.test.dtb
+ tree1_tests_rw dtc_tree1.test.dtb
}
while getopts "vdt:" ARG ; do
--
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: libfdt: libfdt_env.h must be included first
From: Stephen Rothwell @ 2007-09-28 5:13 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070928045206.GA25743@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
On Fri, 28 Sep 2007 14:52:06 +1000 David Gibson <david@gibson.dropbear.id.au> wrote:
>
> libfdt.h currently includes fdt.h, then libfdt_env.h. This is
> incorrect, because depending on the environment into which libfdt is
> embedded, libfdt_env.h may be needed to define datatypes used in
> fdt.h. This patch corrects the problem.
So why doesn't fdt.h include libfdt_env.h, then?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
From: Jeff Mock @ 2007-09-28 5:19 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <12934517.post@talk.nabble.com>
Misbah khan wrote:
>
>
> Scott Wood-2 wrote:
>> Misbah khan wrote:
>>> Hi all I am using "test_bit(),set_bit(),clear_bit() etc" API functions
>>> provided by the Linux kernel. I want to know that if anybody is used it
>>> and have full faith in its operation then please let me know. Driver in
>>> the while loop is calling these API's hence i want to make sure that its
>>> operation will remain stable.
>> They're used all over the place. Is there anything about them that you
>> find suspect?
>>
>> -Scott
>>
>> I have devloped a character driver for FPGA which is memory mapped and
>> using these API's to test a bit , set a bit or to clear a bit in the
>> memory for eg :-
>>
>> /* poll till data is transfered from sdram to dpram */
>> while((test_bit(DFR_BUSY,(UINT32 *)(\
>> (void *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
>> && (delay < MAX_DELAY_BUSY))
>> {
>> KDEBUG3(" In the Dfr delay loop \n");
>> mdelay(DELAY);
>> delay+=DELAY;
>> }/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
>>
>> if(delay==MAX_DELAY_BUSY)
>> {
>> KDEBUG1("Out of the the Dfr busy loop \n");
>> return -1;
>> }
>>
>> People working for FPGA are sure that they are not making the bit high
>> where in my driver is returning -1 from the kernel space aborting it after
>> running for few minutes or so . Please let me know that This function is
>> stable and i should tell them that the driver is stable in its operation
>> and they should check it from there side.
>>
I think a more more likely source of the problem is that the FPGA
pointer is not cast volatile, or perhaps the FPGA is mapped cached and
the hardware doesn't always get touched when you think it does. The bit
manipulation macros are probably fine.
jeff
^ permalink raw reply
* Re: libfdt: libfdt_env.h must be included first
From: David Gibson @ 2007-09-28 5:22 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20070928151322.a9dee5d9.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
On Fri, Sep 28, 2007 at 03:13:22PM +1000, Stephen Rothwell wrote:
> On Fri, 28 Sep 2007 14:52:06 +1000 David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > libfdt.h currently includes fdt.h, then libfdt_env.h. This is
> > incorrect, because depending on the environment into which libfdt is
> > embedded, libfdt_env.h may be needed to define datatypes used in
> > fdt.h. This patch corrects the problem.
>
> So why doesn't fdt.h include libfdt_env.h, then?
Because libfdt_env.h is specifically for libfdt, whereas fdt.h
contains passive structures only, related to the flat tree structure
but without reference to any particular code for handling it.
Basically, fdt.h includes no other headers as a compromise to make it
more easily usable in various contexts. In fact the only thing it
needs is the C99 fixed-width integer types, but I want it to be also
usable in contexts which don't have a <stdint.h> (e.g. the kernel
bootwrapper).
--
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox