* [PATCH 05/11] pa_pxp_ops: use named structure member initializers
From: Nathan Lynch @ 2007-08-09 19:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, Paul Mackerras
In-Reply-To: <11866871262306-git-send-email-ntl@pobox.com>
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/platforms/pasemi/pci.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
index ab1f5f6..882b571 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -122,8 +122,8 @@ static int pa_pxp_write_config(struct pci_bus *bus, unsigned int devfn,
}
static struct pci_ops pa_pxp_ops = {
- pa_pxp_read_config,
- pa_pxp_write_config,
+ .read = pa_pxp_read_config,
+ .write = pa_pxp_write_config,
};
static void __init setup_pa_pxp(struct pci_controller *hose)
--
1.5.2.4
^ permalink raw reply related
* [PATCH 04/11] maple pci_ops: use named structure member initializers
From: Nathan Lynch @ 2007-08-09 19:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <11866871262306-git-send-email-ntl@pobox.com>
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/platforms/maple/pci.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/maple/pci.c b/arch/powerpc/platforms/maple/pci.c
index 2542403..6247f94 100644
--- a/arch/powerpc/platforms/maple/pci.c
+++ b/arch/powerpc/platforms/maple/pci.c
@@ -185,8 +185,8 @@ static int u3_agp_write_config(struct pci_bus *bus, unsigned int devfn,
static struct pci_ops u3_agp_pci_ops =
{
- u3_agp_read_config,
- u3_agp_write_config
+ .read = u3_agp_read_config,
+ .write = u3_agp_write_config,
};
static unsigned long u3_ht_cfa0(u8 devfn, u8 off)
@@ -284,8 +284,8 @@ static int u3_ht_write_config(struct pci_bus *bus, unsigned int devfn,
static struct pci_ops u3_ht_pci_ops =
{
- u3_ht_read_config,
- u3_ht_write_config
+ .read = u3_ht_read_config,
+ .write = u3_ht_write_config,
};
static unsigned int u4_pcie_cfa0(unsigned int devfn, unsigned int off)
@@ -392,8 +392,8 @@ static int u4_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
static struct pci_ops u4_pcie_pci_ops =
{
- u4_pcie_read_config,
- u4_pcie_write_config
+ .read = u4_pcie_read_config,
+ .write = u4_pcie_write_config,
};
static void __init setup_u3_agp(struct pci_controller* hose)
--
1.5.2.4
^ permalink raw reply related
* [PATCH 03/11] celleb_epci_ops: use named structure member initializers
From: Nathan Lynch @ 2007-08-09 19:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <11866871262306-git-send-email-ntl@pobox.com>
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/platforms/celleb/scc_epci.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/scc_epci.c b/arch/powerpc/platforms/celleb/scc_epci.c
index c4b0110..7506acc 100644
--- a/arch/powerpc/platforms/celleb/scc_epci.c
+++ b/arch/powerpc/platforms/celleb/scc_epci.c
@@ -278,8 +278,8 @@ static int celleb_epci_write_config(struct pci_bus *bus,
}
struct pci_ops celleb_epci_ops = {
- celleb_epci_read_config,
- celleb_epci_write_config,
+ .read = celleb_epci_read_config,
+ .write = celleb_epci_write_config,
};
/* to be moved in FW */
--
1.5.2.4
^ permalink raw reply related
* [PATCH 02/11] celleb_fake_pci_ops: use named structure member initializers
From: Nathan Lynch @ 2007-08-09 19:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <11866871262306-git-send-email-ntl@pobox.com>
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/platforms/celleb/pci.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/pci.c b/arch/powerpc/platforms/celleb/pci.c
index e9ac19c..de8038b 100644
--- a/arch/powerpc/platforms/celleb/pci.c
+++ b/arch/powerpc/platforms/celleb/pci.c
@@ -242,8 +242,8 @@ static int celleb_fake_pci_write_config(struct pci_bus *bus,
}
static struct pci_ops celleb_fake_pci_ops = {
- celleb_fake_pci_read_config,
- celleb_fake_pci_write_config
+ .read = celleb_fake_pci_read_config,
+ .write = celleb_fake_pci_write_config,
};
static inline void celleb_setup_pci_base_addrs(struct pci_controller *hose,
--
1.5.2.4
^ permalink raw reply related
* [PATCH 01/11] rtas_pci_ops: use named structure member initializers
From: Nathan Lynch @ 2007-08-09 19:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <11866871262306-git-send-email-ntl@pobox.com>
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/kernel/rtas_pci.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/rtas_pci.c b/arch/powerpc/kernel/rtas_pci.c
index a5de621..21f14e5 100644
--- a/arch/powerpc/kernel/rtas_pci.c
+++ b/arch/powerpc/kernel/rtas_pci.c
@@ -171,8 +171,8 @@ static int rtas_pci_write_config(struct pci_bus *bus,
}
struct pci_ops rtas_pci_ops = {
- rtas_pci_read_config,
- rtas_pci_write_config
+ .read = rtas_pci_read_config,
+ .write = rtas_pci_write_config,
};
int is_python(struct device_node *dev)
--
1.5.2.4
^ permalink raw reply related
* [trivial] use named structure member initializers for pci_ops structures
From: Nathan Lynch @ 2007-08-09 19:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
This series converts all pci_ops structures in arch/powerpc to named
member initializers, in accordance with prevailing practice in the
kernel. No behavioral or otherwise stylistic changes.
arch/powerpc/kernel/pci_32.c | 4 ++--
arch/powerpc/kernel/rtas_pci.c | 4 ++--
arch/powerpc/platforms/52xx/efika.c | 4 ++--
arch/powerpc/platforms/celleb/pci.c | 4 ++--
arch/powerpc/platforms/celleb/scc_epci.c | 4 ++--
arch/powerpc/platforms/chrp/pci.c | 8 ++++----
arch/powerpc/platforms/maple/pci.c | 12 ++++++------
arch/powerpc/platforms/pasemi/pci.c | 4 ++--
arch/powerpc/platforms/powermac/pci.c | 16 ++++++++--------
arch/powerpc/sysdev/indirect_pci.c | 4 ++--
arch/powerpc/sysdev/tsi108_pci.c | 4 ++--
11 files changed, 34 insertions(+), 34 deletions(-)
^ permalink raw reply
* Re: [PATCH] Generic configuration selector for Xilinx devices
From: Grant Likely @ 2007-08-09 19:05 UTC (permalink / raw)
To: Wolfgang Reissnegger; +Cc: linuxppc-embedded
In-Reply-To: <20070806225403.B430E550060@mail33-cpk.bigfish.com>
On 8/6/07, Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> wrote:
> This is intended to make visible all device driver options for
> both powerpc and microblaze systems.
>
> Thanks,
> Wolfgang
>
>
> Signed-off-by: Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
This patch adds a new directory "drivers/misc/xilinx" with exactly *1*
file in it; A Kconfig file. Just put the new XILINX_DRIVERS Kconfig
option into drivers/misc/Kconfig. If there is ever enough Xilinx
stuff to warrant a separate drivers/misc/xilinx directory, then the
Kconfig entry can be moved.
<snip>
> +++ b/drivers/misc/xilinx/Kconfig
> @@ -0,0 +1,9 @@
> +#
> +# Xilinx devices and common device driver infrastructure
> +#
> +
> +config XILINX_DRIVERS
> + bool
> + help
> + Enable visibility of all Xilinx device drivers
Drop the help text; XILINX_DRIVERS won't show up in the menu, so it is
pointless.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] Consolidate XILINX_VIRTEX board support
From: Grant Likely @ 2007-08-09 18:57 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded
In-Reply-To: <87vebryfrv.fsf@sleipner.barco.com>
On 8/7/07, Peter Korsgaard <peter.korsgaard@barco.com> wrote:
> >>>>> "WR" == Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> writes:
>
> Hi,
>
> WR> diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
> WR> index 5b87779..05631fe 100644
> WR> --- a/arch/ppc/boot/simple/Makefile
> WR> +++ b/arch/ppc/boot/simple/Makefile
> WR> @@ -187,8 +187,7 @@ boot-$(CONFIG_REDWOOD_6) += embed_config.o
> WR> boot-$(CONFIG_8xx) += embed_config.o
> WR> boot-$(CONFIG_8260) += embed_config.o
> WR> boot-$(CONFIG_EP405) += embed_config.o
> WR> -boot-$(CONFIG_XILINX_ML300) += embed_config.o
> WR> -boot-$(CONFIG_XILINX_ML403) += embed_config.o
> WR> +boot-$(CONFIG_XILINX_VIRTEX) += embed_config.o
>
> Don't do that. Other boards with Xilinx FPGAs don't necessarily need
> embed_config.c
Then post patches for those boards so we can properly support the
different configuration.
>
> WR> boot-$(CONFIG_BSEIP) += iic.o
> WR> boot-$(CONFIG_MBX) += iic.o pci.o qspan_pci.o
> WR> boot-$(CONFIG_MV64X60) += misc-mv64x60.o
> WR> diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
> WR> index 840bff2..e0b8954 100644
> WR> --- a/arch/ppc/boot/simple/embed_config.c
> WR> +++ b/arch/ppc/boot/simple/embed_config.c
> WR> @@ -744,7 +744,7 @@ embed_config(bd_t **bdp)
> WR> }
> WR> #endif /* WILLOW */
>
> WR> -#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
> WR> +#if defined(CONFIG_XILINX_VIRTEX)
> WR> void
> WR> embed_config(bd_t ** bdp)
>
> .. And if they do, they might have another embed_config (E.G. if the
> bootloader provides a valid struct bd_t).
>
> --
> Bye, Peter Korsgaard
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] Consolidate XILINX_VIRTEX board support
From: Grant Likely @ 2007-08-09 18:54 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-embedded
In-Reply-To: <200708070124.04748.arnd@arndb.de>
On 8/6/07, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 07 August 2007, Wolfgang Reissnegger wrote:
> >
> > Make support for Xilinx boards more generic, making it easier
> > to add new boards. Add initial support for xupv2p and ml410 boards.
>
> I really think we shouldn't add stuff to arch/ppc at this point,
> it has been deprecated for over two years now.
Naahh, this is pretty benign stuff. I say let it go in. :-)
These changes are low risk and they don't hurt anything. If Virtex
support worked in arch/powerpc then I'd agree, but for now it allows
us to keep the virtex device driver support somewhat current.
>
> > --- a/arch/ppc/platforms/4xx/virtex.h
> > +++ b/arch/ppc/platforms/4xx/virtex.h
> > @@ -31,5 +31,14 @@ extern const char* virtex_machine_name;
> > #define PPC4xx_ONB_IO_VADDR0u
> > #define PPC4xx_ONB_IO_SIZE0u
> >
> > +
> > +#if defined(CONFIG_XILINX_VIRTEX_II_PRO)
> > +#define XILINX_ARCH "Virtex-II Pro"
> > +#elif defined(CONFIG_XILINX_VIRTEX_4_FX)
> > +#define XILINX_ARCH "Virtex-4 FX"
> > +#else
> > +#error "No Xilinx Architecture recognized."
> > +#endif
> > +
> > #endif/* __ASM_VIRTEX_H__ */
> > #endif/* __KERNEL__ */
>
> When you move over to arch/powerpc, you can't do it this way, because
> that prevents you from building a multiplatform kernel.
>
> Every macro and global function that gets defined must be able to coexist
> with others that are enabled by nonexclusive configuration options.
>
> > +#if defined(CONFIG_XILINX_ML300)
> > +const char *virtex_machine_name = "Xilinx ML300";
> > +#elif defined(CONFIG_XILINX_XUPV2P)
> > +const char *virtex_machine_name = "Xilinx XUPV2P";
> > +#elif defined(CONFIG_XILINX_ML40x)
> > +const char *virtex_machine_name = "Xilinx ML40x";
> > +#elif defined(CONFIG_XILINX_ML41x)
> > +const char *virtex_machine_name = "Xilinx ML41x";
> > +#else
> > +const char *virtex_machine_name = "Unknown Xilinx with PowerPC";
> > +#endif
>
> same here.
>
> > +
> > +
> > +#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
> > +static volatile unsigned *powerdown_base =
> > + (volatile unsigned *) XPAR_POWER_0_POWERDOWN_BASEADDR;
>
> volatile is a bug. This needs to be __iomem, and the address probably
> needs to come from of_iomap() or a similar function.
Ugh; this is an old bug that they just copied. I'll submit a fix for
the original code.
>
> > +static void
> > +xilinx_power_off(void)
> > +{
> > +local_irq_disable();
> > +out_be32(powerdown_base, XPAR_POWER_0_POWERDOWN_VALUE);
> > +while (1) ;
> > +}
> > +#endif
>
> You should run 'sparse' on your code before submitting patches. That
> would have caught this bug in the out_be32() instruction that expects
> an __iomem pointer.
>
> > +
> > +void __init
> > +xilinx_generic_ppc_map_io(void)
> > +{
> > +ppc4xx_map_io();
> > +
> > +#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
> > +powerdown_base = ioremap((unsigned long) powerdown_base,
> > + XPAR_POWER_0_POWERDOWN_HIGHADDR -
> > + XPAR_POWER_0_POWERDOWN_BASEADDR + 1);
> > +#endif
> > +}
>
> It's a rather unconventional way of working with the addresses.
> You should never use a single variable for pointers going to
> two different address spaces (physical and kernel virtual in this
> case).
Double ewh; this is also a cloned bug.
>
> > +void __init
> > +xilinx_generic_ppc_setup_arch(void)
> > +{
> > +virtex_early_serial_map();
>
> Use legacy_serial/of_serial to do this, with proper device tree entries.
>
> > +
> > +int virtex_device_fixup(struct platform_device *dev)
> > +{
> > + int i;
> > +#ifdef XPAR_ONEWIRE_0_BASEADDR
> > + /* Use the Silicon Serial ID attached on the onewire bus to */
> > + /* generate sensible MAC addresses. */
> > + unsigned char *pOnewire = ioremap(XPAR_ONEWIRE_0_BASEADDR, 6);
> > + struct xemac_platform_data *pdata = dev->dev.platform_data;
> > + if (strcmp(dev->name, "xilinx_emac") == 0) {
>
> This is heavily whitespace damaged, use tabs for indentation instead
> of spaces.
>
> > diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > index 01aa043..34d9844 100644
> > --- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > +++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > @@ -15,8 +15,12 @@
> >
> > #if defined(CONFIG_XILINX_ML300)
> > #include "xparameters_ml300.h"
> > +#elif defined(CONFIG_XILINX_XUPV2P)
> > + #include "xparameters_xupv2p.h"
> > #elif defined(CONFIG_XILINX_ML403)
> > #include "xparameters_ml403.h"
> > +#elif defined(CONFIG_XILINX_ML41x)
> > + #include "xparameters_ml41x.h"
> > #else
> > /* Add other board xparameter includes here before the #else */
> > #error No xparameters_*.h file included
>
> see comment above.
This whole xparams stuff is a special case; but it is going away for
arch/powerpc. xparameters.h is generated by the xilinx EDK tool and
it is painful to work with in the Linux context. For arch/powerpc,
I've got a tool that generates a device tree from the FPGA hardware
design.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: BusyBox Mount
From: Wolfgang Reissnegger @ 2007-08-09 18:46 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <12077740.post@talk.nabble.com>
Hi Khollan,
try to use:
mount -t vfat -ouid=uuu,gid=ggg /dev/xsa1 /home/Dak
where uuu is the User ID of your user and ggg is its Group ID.
Cheers,
Wolfgang
khollan wrote:
> Hi
>
> I want to mount the first partion of my compact flash in a users home folder
> during bootup. This partion should be owned by the user and be read write
> and executable. I am using the command:
> mount -t vfat /dev/xsa1 /home/Dak
> in the rcS startup script. This works fine but it is owned by the root, if
> I try to change the ownership with chown as root it says that Operation not
> permitted, if I Chmod to 777 it appears to take but when you ls -l it out it
> says that it is onlt rw by the owner root.
> Any suggestions
> khollan
^ permalink raw reply
* Re: [PATCH] Consolidate XILINX_VIRTEX board support
From: Grant Likely @ 2007-08-09 18:42 UTC (permalink / raw)
To: Wolfgang Reissnegger; +Cc: linuxppc-embedded
In-Reply-To: <20070806225642.7D72A7B005B@mail34-fra.bigfish.com>
On 8/6/07, Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> wrote:
> Make support for Xilinx boards more generic, making it easier
> to add new boards. Add initial support for xupv2p and ml410 boards.
>
> Thanks,
> Wolfgang
>
>
> Signed-off-by: Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Comments below...
> ---
> arch/ppc/boot/simple/Makefile | 3 +-
> arch/ppc/boot/simple/embed_config.c | 4 +-
> arch/ppc/platforms/4xx/Kconfig | 15 +
> arch/ppc/platforms/4xx/Makefile | 2 +
> arch/ppc/platforms/4xx/virtex.h | 9 +
> arch/ppc/platforms/4xx/xilinx_generic_ppc.c | 129 ++++++++
> arch/ppc/platforms/4xx/xilinx_xupv2p.c | 43 +++
> arch/ppc/platforms/4xx/xparameters/xparameters.h | 4 +
> .../platforms/4xx/xparameters/xparameters_ml41x.h | 277 +++++++++++++++++
> .../platforms/4xx/xparameters/xparameters_xupv2p.h | 327 ++++++++++++++++++++
> 10 files changed, 809 insertions(+), 4 deletions(-)
> create mode 100644 arch/ppc/platforms/4xx/xilinx_generic_ppc.c
> create mode 100644 arch/ppc/platforms/4xx/xilinx_xupv2p.c
> create mode 100644 arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h
> create mode 100644 arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h
>
> diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
> index 5b87779..05631fe 100644
> --- a/arch/ppc/boot/simple/Makefile
> +++ b/arch/ppc/boot/simple/Makefile
> @@ -187,8 +187,7 @@ boot-$(CONFIG_REDWOOD_6) += embed_config.o
> boot-$(CONFIG_8xx) += embed_config.o
> boot-$(CONFIG_8260) += embed_config.o
> boot-$(CONFIG_EP405) += embed_config.o
> -boot-$(CONFIG_XILINX_ML300) += embed_config.o
> -boot-$(CONFIG_XILINX_ML403) += embed_config.o
> +boot-$(CONFIG_XILINX_VIRTEX) += embed_config.o
> boot-$(CONFIG_BSEIP) += iic.o
> boot-$(CONFIG_MBX) += iic.o pci.o qspan_pci.o
> boot-$(CONFIG_MV64X60) += misc-mv64x60.o
> diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
> index 840bff2..e0b8954 100644
> --- a/arch/ppc/boot/simple/embed_config.c
> +++ b/arch/ppc/boot/simple/embed_config.c
> @@ -744,7 +744,7 @@ embed_config(bd_t **bdp)
> }
> #endif /* WILLOW */
>
> -#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
> +#if defined(CONFIG_XILINX_VIRTEX)
You need to rebase your patch to mainline. This change has already been applied
> void
> embed_config(bd_t ** bdp)
> {
> @@ -781,7 +781,7 @@ embed_config(bd_t ** bdp)
> timebase_period_ns = 1000000000 / bd->bi_tbfreq;
> /* see bi_tbfreq definition in arch/ppc/platforms/4xx/xilinx_ml300.h */
> }
> -#endif /* CONFIG_XILINX_ML300 || CONFIG_XILINX_ML403 */
> +#endif /* CONFIG_XILINX_VIRTEX */
ditto
>
> #ifdef CONFIG_IBM_OPENBIOS
> /* This could possibly work for all treeboot roms.
> diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
> index d7db7e4..56965cb 100644
> --- a/arch/ppc/platforms/4xx/Kconfig
> +++ b/arch/ppc/platforms/4xx/Kconfig
> @@ -60,12 +60,27 @@ config XILINX_ML300
> help
> This option enables support for the Xilinx ML300 evaluation board.
>
> +config XILINX_XUPV2P
> + bool "Xilinx-XUPV2P"
> + select XILINX_VIRTEX_II_PRO
> + select EMBEDDEDBOOT
> + help
> + This option enables support for the Xilinx University Program (XUP) Virtex 2 Pro board.
> +
> config XILINX_ML403
> bool "Xilinx-ML403"
> select XILINX_VIRTEX_4_FX
> select EMBEDDEDBOOT
> help
> This option enables support for the Xilinx ML403 evaluation board.
> +
> +config XILINX_ML41x
> + bool "Xilinx-ML41x"
> + select XILINX_VIRTEX_4_FX
> + select EMBEDDEDBOOT
> + help
> + This option enables support for the Xilinx ML410/411 evaluation boards.
> +
> endchoice
>
> choice
> diff --git a/arch/ppc/platforms/4xx/Makefile b/arch/ppc/platforms/4xx/Makefile
> index 723ad79..bcf1a63 100644
> --- a/arch/ppc/platforms/4xx/Makefile
> +++ b/arch/ppc/platforms/4xx/Makefile
> @@ -15,7 +15,9 @@ obj-$(CONFIG_SYCAMORE) += sycamore.o
> obj-$(CONFIG_TAISHAN) += taishan.o
> obj-$(CONFIG_WALNUT) += walnut.o
> obj-$(CONFIG_XILINX_ML300) += xilinx_ml300.o
> +obj-$(CONFIG_XILINX_XUPV2P) += xilinx_generic_ppc.o xilinx_xupv2p.o
> obj-$(CONFIG_XILINX_ML403) += xilinx_ml403.o
> +obj-$(CONFIG_XILINX_ML41x) += xilinx_generic_ppc.o
>
> obj-$(CONFIG_405GP) += ibm405gp.o
> obj-$(CONFIG_REDWOOD_5) += ibmstb4.o
> diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virtex.h
> index 7382804..47f67b3 100644
> --- a/arch/ppc/platforms/4xx/virtex.h
> +++ b/arch/ppc/platforms/4xx/virtex.h
> @@ -31,5 +31,14 @@ extern const char* virtex_machine_name;
> #define PPC4xx_ONB_IO_VADDR 0u
> #define PPC4xx_ONB_IO_SIZE 0u
>
> +
> +#if defined(CONFIG_XILINX_VIRTEX_II_PRO)
> +#define XILINX_ARCH "Virtex-II Pro"
> +#elif defined(CONFIG_XILINX_VIRTEX_4_FX)
> +#define XILINX_ARCH "Virtex-4 FX"
> +#else
> +#error "No Xilinx Architecture recognized."
> +#endif
> +
XILINX_ARCH is used in exactly *one* place; I wouldn't add it to the
header file.
> #endif /* __ASM_VIRTEX_H__ */
> #endif /* __KERNEL__ */
> diff --git a/arch/ppc/platforms/4xx/xilinx_generic_ppc.c b/arch/ppc/platforms/4xx/xilinx_generic_ppc.c
This is a clone of arch/ppc/platforms/4xx/xilinx_ml300.c and
xilinx_ml403.c; yet you don't remove the old files or consolidate
ml300 and ml403 to use them. You should separate this change into a
separate patch that just consolidates the xilinx_ml300 & xilinx_ml403,
and then add the other boards in a second patch.
BTW, if you do so, you should add '__attribute ((weak))' to the
definition of platform_init so it can be overridden when needed.
> new file mode 100644
> index 0000000..103e762
> --- /dev/null
> +++ b/arch/ppc/platforms/4xx/xilinx_generic_ppc.c
> @@ -0,0 +1,129 @@
> +/*
> + * Xilinx Generic PPC evaluation board initialization
> + *
> + * Author: MontaVista Software, Inc.
> + * source@mvista.com
> + *
> + * 2002-2004 (c) MontaVista Software, Inc. 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.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/irq.h>
> +#include <linux/tty.h>
> +#include <linux/serial.h>
> +#include <linux/serial_core.h>
> +#include <linux/serial_8250.h>
> +#include <linux/serialP.h>
> +#include <linux/io.h>
> +#include <asm/machdep.h>
> +
> +#include <syslib/gen550.h>
> +#include <syslib/virtex_devices.h>
> +#include <platforms/4xx/xparameters/xparameters.h>
> +
> +/*
> + * As an overview of how the following functions (platform_init,
> + * xilinx_generic_ppc_map_io, xilinx_generic_ppc_setup_arch and xilinx_generic_ppc_init_IRQ) fit into the
> + * kernel startup procedure, here's a call tree:
> + *
> + * start_here arch/ppc/kernel/head_4xx.S
> + * early_init arch/ppc/kernel/setup.c
> + * machine_init arch/ppc/kernel/setup.c
> + * platform_init this file
> + * ppc4xx_init arch/ppc/syslib/ppc4xx_setup.c
> + * parse_bootinfo
> + * find_bootinfo
> + * "setup some default ppc_md pointers"
> + * MMU_init arch/ppc/mm/init.c
> + * *ppc_md.setup_io_mappings == xilinx_generic_ppc_map_io this file
> + * ppc4xx_map_io arch/ppc/syslib/ppc4xx_setup.c
> + * start_kernel init/main.c
> + * setup_arch arch/ppc/kernel/setup.c
> + * #if defined(CONFIG_KGDB)
> + * *ppc_md.kgdb_map_scc() == gen550_kgdb_map_scc
> + * #endif
> + * *ppc_md.setup_arch == xilinx_generic_ppc_setup_arch this file
> + * ppc4xx_setup_arch arch/ppc/syslib/ppc4xx_setup.c
> + * ppc4xx_find_bridges arch/ppc/syslib/ppc405_pci.c
> + * init_IRQ arch/ppc/kernel/irq.c
> + * *ppc_md.init_IRQ == xilinx_generic_ppc_init_IRQ this file
> + * ppc4xx_init_IRQ arch/ppc/syslib/ppc4xx_setup.c
> + * ppc4xx_pic_init arch/ppc/syslib/xilinx_pic.c
> + */
> +
> +#if defined(CONFIG_XILINX_ML300)
> +const char *virtex_machine_name = "Xilinx ML300";
> +#elif defined(CONFIG_XILINX_XUPV2P)
> +const char *virtex_machine_name = "Xilinx XUPV2P";
> +#elif defined(CONFIG_XILINX_ML40x)
> +const char *virtex_machine_name = "Xilinx ML40x";
> +#elif defined(CONFIG_XILINX_ML41x)
> +const char *virtex_machine_name = "Xilinx ML41x";
> +#else
> +const char *virtex_machine_name = "Unknown Xilinx with PowerPC";
> +#endif
> +
> +
> +#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
> +static volatile unsigned *powerdown_base =
> + (volatile unsigned *) XPAR_POWER_0_POWERDOWN_BASEADDR;
> +
> +static void
> +xilinx_power_off(void)
> +{
> + local_irq_disable();
> + out_be32(powerdown_base, XPAR_POWER_0_POWERDOWN_VALUE);
> + while (1) ;
> +}
> +#endif
> +
> +void __init
> +xilinx_generic_ppc_map_io(void)
> +{
> + ppc4xx_map_io();
> +
> +#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
> + powerdown_base = ioremap((unsigned long) powerdown_base,
> + XPAR_POWER_0_POWERDOWN_HIGHADDR -
> + XPAR_POWER_0_POWERDOWN_BASEADDR + 1);
> +#endif
> +}
> +
> +void __init
> +xilinx_generic_ppc_setup_arch(void)
> +{
> + virtex_early_serial_map();
> + ppc4xx_setup_arch(); /* calls ppc4xx_find_bridges() */
> +
> + /* Identify the system */
> + printk(KERN_INFO "Xilinx Generic PowerPC board support package (%s) (%s)\n", PPC4xx_MACHINE_NAME, XILINX_ARCH);
> +}
> +
> +/* Called after board_setup_irq from ppc4xx_init_IRQ(). */
> +void __init
> +xilinx_generic_ppc_init_irq(void)
> +{
> + ppc4xx_init_IRQ();
> +}
> +
> +void __init
> +platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> + unsigned long r6, unsigned long r7)
> +{
> + ppc4xx_init(r3, r4, r5, r6, r7);
> +
> + ppc_md.setup_arch = xilinx_generic_ppc_setup_arch;
> + ppc_md.setup_io_mappings = xilinx_generic_ppc_map_io;
> + ppc_md.init_IRQ = xilinx_generic_ppc_init_irq;
> +
> +#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
> + ppc_md.power_off = xilinx_power_off;
> +#endif
> +
> +#ifdef CONFIG_KGDB
> + ppc_md.early_serial_map = virtex_early_serial_map;
> +#endif
> +}
> +
> diff --git a/arch/ppc/platforms/4xx/xilinx_xupv2p.c b/arch/ppc/platforms/4xx/xilinx_xupv2p.c
> new file mode 100644
> index 0000000..aa2d890
> --- /dev/null
> +++ b/arch/ppc/platforms/4xx/xilinx_xupv2p.c
> @@ -0,0 +1,43 @@
> +/*
> + * Xilinx XUPV2P board initialization
> + *
> + * Author: Stephen.Neuendorffer@xilinx.com
> + *
> + * 2007 (c) Xilinx, Inc. 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.
> + */
> +
> +#include <linux/xilinx_devices.h>
> +#include <platforms/4xx/xparameters/xparameters.h>
> +
> +int virtex_device_fixup(struct platform_device *dev)
> +{
> + int i;
If XPAR_ONEWIRE_0_BASEADDR is not set, then the unused 'int i' will
generate a warning.
> +#ifdef XPAR_ONEWIRE_0_BASEADDR
> + /* Use the Silicon Serial ID attached on the onewire bus to */
> + /* generate sensible MAC addresses. */
> + unsigned char *pOnewire = ioremap(XPAR_ONEWIRE_0_BASEADDR, 6);
Don't use CamelCase variable names.
ioremap() with no matching iounmap()
> + struct xemac_platform_data *pdata = dev->dev.platform_data;
> + if (strcmp(dev->name, "xilinx_emac") == 0) {
> + printk(KERN_INFO "Fixup MAC address for %s:%d\n",
> + dev->name, dev->id);
> + /* FIXME.. this doesn't seem to return data that is consistent */
> + /* with the self test... why not? */
Is this ready to be committed?
> + pdata->mac_addr[0] = 0x00;
> + pdata->mac_addr[1] = 0x0A;
> + pdata->mac_addr[2] = 0x35;
> + pdata->mac_addr[3] = dev->id;
> + pdata->mac_addr[4] = pOnewire[4];
> + pdata->mac_addr[5] = pOnewire[5];
> + printk(KERN_INFO "MAC address is now %2x:%2x:%2x:%2x:%2x:%2x\n",
> + pdata->mac_addr[0],
> + pdata->mac_addr[1],
> + pdata->mac_addr[2],
> + pdata->mac_addr[3],
> + pdata->mac_addr[4],
> + pdata->mac_addr[5]);
The printk is ambiguous because it doesn't specify which device the
MAC addr is assigned to. I'd drop the printk (or change it to a
pr_debug) and print the MAC addr in the Eth device driver itself.
Once you're in the driver, you know which 'eth#' will be assigned.
> + }
> +#endif
> + return 0;
> +}
whitespace problems here
> diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> index 01aa043..34d9844 100644
> --- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
> +++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> @@ -15,8 +15,12 @@
>
> #if defined(CONFIG_XILINX_ML300)
> #include "xparameters_ml300.h"
> +#elif defined(CONFIG_XILINX_XUPV2P)
> + #include "xparameters_xupv2p.h"
> #elif defined(CONFIG_XILINX_ML403)
> #include "xparameters_ml403.h"
> +#elif defined(CONFIG_XILINX_ML41x)
> + #include "xparameters_ml41x.h"
> #else
> /* Add other board xparameter includes here before the #else */
> #error No xparameters_*.h file included
> diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h b/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h
> diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h b/arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h
Split the addition of new xparams files into a separate patch.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* BusyBox Mount
From: khollan @ 2007-08-09 18:17 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I want to mount the first partion of my compact flash in a users home folder
during bootup. This partion should be owned by the user and be read write
and executable. I am using the command:
mount -t vfat /dev/xsa1 /home/Dak
in the rcS startup script. This works fine but it is owned by the root, if
I try to change the ownership with chown as root it says that Operation not
permitted, if I Chmod to 777 it appears to take but when you ls -l it out it
says that it is onlt rw by the owner root.
Any suggestions
khollan
--
View this message in context: http://www.nabble.com/BusyBox-Mount-tf4244254.html#a12077740
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* RE: [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
From: Stephen Neuendorffer @ 2007-08-09 18:17 UTC (permalink / raw)
To: Joachim Förster, linuxppc-embedded; +Cc: alsa-devel, Lorenz Kolb
In-Reply-To: <1186655810.7420.26.camel@localhost>
=20
I second grant here... this should eventually work on microblaze, too,
so putting it drivers/ and using XILINX_DRIVERS instead of XILINX_VIRTEX
(based on the patch Wolfgang recently posted) would probably be =
preferable.
> +
> +config SND_ML403_AC97CR
> + tristate "Xilinx ML403 AC97 Controller Reference"
> + depends on SND && XILINX_VIRTEX
Steve
^ permalink raw reply
* Re: [PATCH 2/2] [VIRTEX] Register AC97 Controller Reference with the platform bus
From: Grant Likely @ 2007-08-09 18:04 UTC (permalink / raw)
To: Joachim Förster
Cc: alsa-devel, Lorenz Kolb, linuxppc-embedded@ozlabs.org
In-Reply-To: <1186655824.7420.27.camel@localhost>
On 8/9/07, Joachim F=F6rster <mls.JOFT@gmx.de> wrote:
> From: Joachim Foerster <JOFT@gmx.de>
>
> (Patch for Linus' master branch, date 2007/08/08)
>
> Signed-off-by: Joachim Foerster <JOFT@gmx.de>
> ---
> arch/ppc/syslib/virtex_devices.c | 28 ++++++++++++++++++++++++++++
> 1 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/arch/ppc/syslib/virtex_devices.c b/arch/ppc/syslib/virtex_de=
vices.c
> index 62a9495..0d6f0ac 100644
> --- a/arch/ppc/syslib/virtex_devices.c
> +++ b/arch/ppc/syslib/virtex_devices.c
> @@ -121,6 +121,29 @@
> }, \
> }
>
> +#define XPAR_AC97_CONTROLLER_REFERENCE(num) { \
> + .name =3D "ml403_ac97cr", \
> + .id =3D num, \
> + .num_resources =3D 3, \
> + .resource =3D (struct resource[]) { \
> + { \
> + .start =3D XPAR_OPB_AC97_CONTROLLER_REF_0_BASEADD=
R, \
> + .end =3D XPAR_OPB_AC97_CONTROLLER_REF_0_HIGHADDR,=
\
This will make each instance try to use the same device! Replace
'_0_' with '_##num##_'
> + .flags =3D IORESOURCE_MEM, \
> + }, \
> + { \
> + .start =3D XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_RE=
F_0_PLAYBACK_INTERRUPT_INTR, \
> + .end =3D XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_REF_=
0_PLAYBACK_INTERRUPT_INTR, \
ditto; in this case you need to change the second _0_. _INTC_0_ is
already the correct form.
> + .flags =3D IORESOURCE_IRQ, \
> + }, \
> + { \
> + .start =3D XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_RE=
F_0_RECORD_INTERRUPT_INTR, \
> + .end =3D XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_REF_=
0_RECORD_INTERRUPT_INTR, \
ditto
> + .flags =3D IORESOURCE_IRQ, \
> + }, \
> + }, \
> +}
> +
> /* UART 8250 driver platform data table */
> struct plat_serial8250_port virtex_serial_platform_data[] =3D {
> #if defined(XPAR_UARTNS550_0_BASEADDR)
> @@ -221,6 +244,11 @@ struct platform_device virtex_platform_devices[] =3D=
{
> #if defined(XPAR_TFT_3_BASEADDR)
> XPAR_TFT(3),
> #endif
> +
> + /* AC97 Controller Reference instances */
> +#if defined(XPAR_OPB_AC97_CONTROLLER_REF_0_BASEADDR)
> + XPAR_AC97_CONTROLLER_REFERENCE(0),
> +#endif
> };
>
> /* Early serial support functions */
> --
> 1.5.2.4
>
>
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
From: Grant Likely @ 2007-08-09 17:49 UTC (permalink / raw)
To: Joachim Förster
Cc: alsa-devel, Lorenz Kolb, linuxppc-embedded@ozlabs.org
In-Reply-To: <1186655810.7420.26.camel@localhost>
On 8/9/07, Joachim F=F6rster <mls.JOFT@gmx.de> wrote:
> From: Joachim Foerster <JOFT@gmx.de>
>
> Add ALSA support for the opb_ac97_controller_ref_v1_00_a ip core found
> in Xilinx' ML403 reference design.
>
> Known issue: Currently this driver hits a WARN_ON_ONCE(1) statement in
> kernel/irq/resend.c (line 70). According to Linus
> (http://lkml.org/lkml/2007/8/5/5) this may be ignored, right? I haven't
> had a look into this "problem" yet.
>
> (Patch for Linus' master branch, date 2007/08/08)
>
> This patchset _will_ be published on
> http://www.esic-solutions.com/support.html soon (like the first version
> of the driver (tar file), but this may take some days ...).
Comments below
> diff --git a/sound/ppc/Makefile b/sound/ppc/Makefile
> index eacee2d..827f2f5 100644
> --- a/sound/ppc/Makefile
> +++ b/sound/ppc/Makefile
Couldn't this end up on MicroBlaze too? If so, sound/ppc is the wrong plac=
e.
> @@ -4,7 +4,9 @@
> #
>
> snd-powermac-objs :=3D powermac.o pmac.o awacs.o burgundy.o daca.o tumbl=
er.o keywest.o beep.o
> +snd-ml403_ac97cr-objs :=3D ml403_ac97cr.o
This line is only needed if you're compiling multiple .c files into one .ko
>
> # Toplevel Module Dependency
> obj-$(CONFIG_SND_POWERMAC) +=3D snd-powermac.o
> obj-$(CONFIG_SND_PS3) +=3D snd_ps3.o
> +obj-$(CONFIG_SND_ML403_AC97CR) +=3D snd-ml403_ac97cr.o
> diff --git a/sound/ppc/ml403_ac97cr.c b/sound/ppc/ml403_ac97cr.c
> new file mode 100644
> index 0000000..99791d7
> --- /dev/null
> +++ b/sound/ppc/ml403_ac97cr.c
> @@ -0,0 +1,1274 @@
> +
> +/* ALSA driver for Xilinx ML403 AC97 Controller Reference
> + * IP: opb_ac97_controller_ref_v1_00_a (EDK 8.1i)
> + * IP: opb_ac97_controller_ref_v1_00_a (EDK 9.1i)
> + *
> + * Copyright (c) by 2007 Joachim Foerster <JOFT@gmx.de>
> + *
> + * This program is free software; you can redistribute it and/or modif=
y
> + * it under the terms of the GNU General Public License as published b=
y
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-130=
7 USA
> + *
> + */
> +
> +#include <sound/driver.h>
> +#include <linux/init.h>
> +#include <linux/moduleparam.h>
> +
> +#include <linux/platform_device.h>
> +
> +#include <linux/ioport.h>
> +#include <asm/io.h>
> +#include <linux/interrupt.h>
> +
> +/* HZ */
> +#include <linux/param.h>
> +/* jiffies, time_*() */
> +#include <linux/jiffies.h>
> +/* schedule_timeout*() */
> +#include <linux/sched.h>
> +/* spin_lock*() */
> +#include <linux/spinlock.h>
> +
> +/* snd_printk(), snd_printd() */
> +#include <sound/core.h>
> +#include <sound/pcm.h>
> +#include <sound/pcm_params.h>
> +#include <sound/initval.h>
> +#include <sound/ac97_codec.h>
> +
> +
> +#define SND_ML403_AC97CR_DRIVER "ml403_ac97cr"
> +
> +MODULE_AUTHOR("Joachim Foerster <JOFT@gmx.de>");
> +MODULE_DESCRIPTION("Xilinx ML403 AC97 Controller Reference");
> +MODULE_LICENSE("GPL");
> +MODULE_SUPPORTED_DEVICE("{{Xilinx,ML403 AC97 Controller Reference}}");
> +MODULE_VERSION("0.0.1-pre2");
This patch is targeted for mainline inclusion (which gives you the
kernel version number). Do you really want to maintain a separate
version number that needs to be update manually? I'd drop the
MODULE_VERSION line.
<snip>
I'm not an ALSA expert, so I didn't review the rest of the code in
detail (but I didn't see anything to comment on with a quick review).
I'll try adding your patches to my tree this afternoon.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [alsa-devel] [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
From: Takashi Iwai @ 2007-08-09 17:13 UTC (permalink / raw)
To: Joachim Förster
Cc: alsa-devel, Lorenz Kolb, linuxppc-embedded@ozlabs.org
In-Reply-To: <1186655810.7420.26.camel@localhost>
Hi,
thanks for the patch. Here the quick review at a first glance...
At Thu, 09 Aug 2007 12:36:50 +0200,
Joachim Förster wrote:
>
> --- a/sound/ppc/Makefile
> +++ b/sound/ppc/Makefile
> @@ -4,7 +4,9 @@
> #
>
> snd-powermac-objs := powermac.o pmac.o awacs.o burgundy.o daca.o tumbler.o keywest.o beep.o
> +snd-ml403_ac97cr-objs := ml403_ac97cr.o
>
> # Toplevel Module Dependency
> obj-$(CONFIG_SND_POWERMAC) += snd-powermac.o
> obj-$(CONFIG_SND_PS3) += snd_ps3.o
> +obj-$(CONFIG_SND_ML403_AC97CR) += snd-ml403_ac97cr.o
Using both _ and - look weird. Let's choose '-' as well as others.
> --- /dev/null
> +++ b/sound/ppc/ml403_ac97cr.c
(snip)
> +static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
> +static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;
> +static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE;
Can the driver really support multiple instances?
If not, better to avoid these arrays.
> +#define PDEBUG(fac, fmt, args...) if (fac & PDEBUG_FACILITIES) \
> + snd_printd(KERN_DEBUG SND_ML403_AC97CR_DRIVER ": " fmt, ##args)
This should be wrapped with do { } while (0)
> +struct lm4550_reg lm4550_regfile[64] = {
> + {.reg = 0x00,
> + .flag = LM4550_REG_NOSAVE | LM4550_REG_FAKEREAD,
> + .def = 0x0D50},
Better to use C99 style initialization here, e.g.
[0x00] = { .... },
[0x02] = { .... },
[0x7e] = { .... },
so you can avoid writing empty items.
The index value could be also AC97_XXX, such as [AC97_MASTER] =
{...}.
What is the purpose of reg field at all, BTW? I guess it's
superfluous.
> +#define LM4550_RF_OK(reg) ((lm4550_regfile[reg / 2].reg != 0) \
> + || (lm4550_regfile[reg / 2].flag != 0))
> +#define LM4550_RF_FLAG(reg) lm4550_regfile[reg / 2].flag
> +#define LM4550_RF_VAL(reg) lm4550_regfile[reg / 2].value
> +#define LM4550_RF_DEF(reg) lm4550_regfile[reg / 2].def
> +#define LM4550_RF_WMASK(reg) lm4550_regfile[reg / 2].wmask
> +
> +static void lm4550_regfile_init(void)
> +{
> + int i;
> + for (i = 0; i < 128; i = i + 2)
> + if (LM4550_RF_FLAG(i) & LM4550_REG_FAKEPROBE)
> + LM4550_RF_VAL(i) = LM4550_RF_DEF(i);
"MACRO(x) = XXX" looks a bit strange to me.
> +static struct snd_pcm_hardware snd_ml403_ac97cr_playback = {
> + .info = (SNDRV_PCM_INFO_MMAP |
> + SNDRV_PCM_INFO_INTERLEAVED |
> + SNDRV_PCM_INFO_MMAP_VALID),
> + .formats = SNDRV_PCM_FMTBIT_S16_BE,
> + .rates = (SNDRV_PCM_RATE_CONTINUOUS |
> + SNDRV_PCM_RATE_8000_48000 |
> + SNDRV_PCM_RATE_KNOT),
RATE_CONTINUOUS and RATE_KNOW are usually exclusive.
> +static int
> +snd_ml403_ac97cr_pcm_trigger(struct snd_pcm_substream *substream, int cmd)
> +{
> + struct snd_ml403_ac97cr *ml403_ac97cr;
> + int err = 0;
> +
> + ml403_ac97cr = snd_pcm_substream_chip(substream);
> +
> + switch (cmd) {
> + case SNDRV_PCM_TRIGGER_START:
> + if (substream == ml403_ac97cr->playback_substream) {
> + PDEBUG(WORK_INFO, "trigger(playback): START\n");
> + ml403_ac97cr->ind_rec.hw_ready = 1;
> +
> + /* clear play FIFO */
> + out_be32(CR_REG(ml403_ac97cr, RESETFIFO), CR_PLAYRESET);
> +
> + /* enable play irq */
> + ml403_ac97cr->enable_irq = 1;
> + enable_irq(ml403_ac97cr->irq);
> + }
Maybe better to create two functions, one for playback and one for
capture, instead of many if's in a function?
> +static int snd_ml403_ac97cr_pcm_prepare(struct snd_pcm_substream *substream)
> +{
> + struct snd_ml403_ac97cr *ml403_ac97cr;
> + struct snd_pcm_runtime *runtime;
> +
> + ml403_ac97cr = snd_pcm_substream_chip(substream);
> + runtime = substream->runtime;
> +
> + if (substream == ml403_ac97cr->playback_substream) {
Ditto.
> +static int
> +snd_ml403_ac97cr_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *hw_params)
> +{
> + PDEBUG(WORK_INFO, "hw_params(): desired buffer bytes=%d, desired "
> + "period bytes=%d\n",
> + params_buffer_bytes(hw_params), params_period_bytes(hw_params));
> + /* check period bytes, has to be multiple of CR_FIFO_SIZE / 2, don't
> + * know if ALSA takes multiples of period_bytes_min _only_ ...?!
> + */
This should be done via an additional hw_constraint at open,
snd_pcm_hw_constraint_step(runtime, 0,
SNDRV_PCM_HW_PARAM_PERIOD_BYTES, CR_FIFO_SIZE / 2);
> +struct snd_pcm_ops snd_ml403_ac97cr_playback_ops = {
Missing static.
> +irqreturn_t snd_ml403_ac97cr_irq(int irq, void *dev_id, struct pt_regs *regs)
Hm, this looks like an old style irq handler.
Did you test the driver with the recent kernel?
Also, missing static there.
> +static unsigned short
> +snd_ml403_ac97cr_codec_read(struct snd_ac97 *ac97, unsigned short reg)
....
> + /* if we are here, we _have_ to access the codec really, no faking */
> + spin_lock(&ml403_ac97cr->reg_lock);
....
> + do {
....
> + schedule_timeout_uninterruptible(1);
> + } while (time_after(end_time, jiffies));
Sleep in spinlock is bad.
> +static int __init
> +snd_ml403_ac97cr_create(struct snd_card *card, struct platform_device *pfdev,
> + struct snd_ml403_ac97cr **rml403_ac97cr)
It's no longer __init as long as you use platform_device.
It should be __devinit instead.
> --- /dev/null
> +++ b/sound/ppc/pcm-indirect2.h
(snip)
> +#ifdef SND_PCM_INDIRECT2_STAT
> +static inline void snd_pcm_indirect2_stat(struct snd_pcm_substream *substream,
> + struct snd_pcm_indirect2 *rec)
Remove inline from the functions in this file. They are too lengthy.
sound/pcm-indirect.h contain inline functions becuase they are
relatively small, and I didn't want to add them in the core module
unconditionally.
Last but not least, the whole patch appears not following strictly the
standard kernel coding style. For example, the style
if ((err = foo()) < 0)
....
should be
err = foo();
if (err < 0)
...
Also, many lines are over 80 chars. Fold them appropriately.
At least the new patches should be like that.
In doubt, you can try $KERNEL/scripts/checkpatch.pl script, which was
added recently to linux kernel tree.
Takashi
^ permalink raw reply
* Re: BUG-REPORT Re: ml403 ac97 driver
From: Joachim Förster @ 2007-08-09 17:01 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11922613.post@talk.nabble.com>
Hi Qin Lin,
sorry for my late answer.
On Tue, 2007-07-31 at 04:49 -0700, Qin Lin wrote:
> When i used the aplay to test the drive first time,it played well. But
> after restart the board
> it is not well again.
Well, I don't think the problem occurs due to the restart of your
board ...
> # aplay yonggan.wav
> Playing WAVE 'yonggan.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,
> Stereo
> [ 258.518119] Kernel stack overflow in process c039ec00, r1=c3e0bf50
... but unfortunately I can't tell how such an error results from the
driver. Are you able to reproduce it?
Since the driver "works", I never got such an error nor another kernel
panic/error.
[The only thing that comes to my mind is the very high interrupt volume,
because of the very small size (32 byte) of the playback FIFO (of the
AC97 controller) => hardware issue. But, since interrupts are _disabled_
during execution of interrupt handlers, I am sure that this cannot be
the source of the problem.]
Joachim
^ permalink raw reply
* Re: [PATCH] powerpc: Pegasos keyboard detection
From: Matt Sealey @ 2007-08-09 16:46 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Alan Curry, linux-kernel
In-Reply-To: <909c5e405e5cd26bca3aff13fe55adbc@kernel.crashing.org>
Segher Boessenkool wrote:
>> Would you guys rather we shipped a boot script that ran the OS, fixed
>> all these issues in-place in-firmware, so Linux did not have to have
>> these
>> workarounds,
>
> Sure, if you can do that, that would be great.
Right, so don't accept that keyboard fix, and we will work on the script
instead.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Sequoia 440EPx patches not working
From: Valentine Barshak @ 2007-08-09 16:33 UTC (permalink / raw)
To: jyoung5; +Cc: linuxppc-dev
In-Reply-To: <1186670238.5547.25.camel@laptop>
Jerone Young wrote:
> So did a rebase on kernel.org 2.6.23-rc2 patch (as opposed the latest
> git). I am using Uboot version 1.2.0-gc0c292b2. This is the version
> that came with the board. It still appears to hang during early boot on
> my Sequoia.
>
> Trying the cuImage.sequoia.bin.gz just result in Uboot giving "Bad Magic
> Number" when trying to boot it. This is also the same for using
> cuImage.sequoia.elf.
>
> So when I use the uImage file it will load but just hang after it's
> loaded. I'm building it using "make uImage CROSS_COMPILE=<cross prefix>
> ARCH=powerpc" on an x86 box.
>
> I'll see what else I could possibly be doing wrong (maybe something
> happened to the patch when I grabbed it off of gmane and the web filters
> did something to it, I did have to fix a problem where in the
> sequoia.dts file the web filter replace "@" with " at ". This was simple
> enough to fix. Maybe something else when wrong. I'll see what else I can
> look at.
>
> On Thu, 2007-08-09 at 16:56 +0400, Vitaly Bordug wrote:
>> On Wed, 08 Aug 2007 13:45:10 -0500
>> Jerone Young wrote:
>>
>>> Using the Sequoia (AMCC 440EPx) patches recently submitted to the
>>> list I am unable to boot to fully boot a uImage built with these
>>> patches under Uboot. It appears to hang in very early boot.
>>>
>>>
>>> Here is the output:
>>> => tftp 400000
>>> sequoia/uImage ENET Speed is 100 Mbps - FULL duplex connection
>>> (EMAC0) Using ppc_4xx_eth0
>>> device TFTP from server 9.53.41.24; our IP address is
>>> 9.53.41.38 Filename
>>> 'sequoia/uImage'. Load address:
>>> 0x400000 Loading:
>>> #################################################################
>>> #################################################################
>>> #################################################################
>>> #######################
>>> done Bytes transferred = 1112434 (10f972
>>> hex) => bootm
>>> 400000 ## Booting image at
>>> 00400000 ... Image Name:
>>> Linux-2.6.23-rc2 Image Type: PowerPC Linux Kernel Image (gzip
>>> compressed) Data Size: 1112370 Bytes = 1.1
>>> MB Load Address:
>>> 00000000 Entry Point:
>>> 00000000 Verifying Checksum ...
>>> OK Uncompressing Kernel Image ... OK
>>>
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>> This seems to be a wrong image..
>>
>> Are you using "make zImage" ?
>>
>> The proper uImage after that command would be smth like cuImage* then...
>>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please, apply clean patches (not filtered by web filters) and
try make ARCH=powerpc CROSS_COMPILE=<cross_prefix> zImage
The image should be at arch/powerpc/boot/cuImage.sequoia
^ permalink raw reply
* Re: [PATCH] powerpc: Pegasos keyboard detection
From: Segher Boessenkool @ 2007-08-09 16:30 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Alan Curry, linux-kernel
In-Reply-To: <46B89C10.7090507@genesi-usa.com>
>> That's hardly the only reason. But yeah, that's one way to
>> implement the workaround, but _we_ (the Linux community) cannot
>> do it like that (easily) for all users.
>
> But you're the guy who told us our firmware sucks and we should fix our
> firmware
Yes, and? You _should_ fix your firmware, it is buggy after all.
Esp. back then as it wasn't shipping yet.
> rather than clutter Linux with too many fixups.
Also, putting fixups in the wrapper is a wholly different thing from
putting fixups deep inside the kernel code proper.
> Linux is already a bad enough moving target, and none of these fixes
> help
> other operating systems or developers, if we only patch Linux,
But that's not Linux' concern. You might care, we don't. Is
this so hard to understand?
> 1) the reports as we had when Efika was released and continually levied
> against Pegasos firmware, that the firmware is broken and must be fixed
> to comply, and no fixes will be considered because "bplan sucks and
> must
> fix it"
>
> 2) As long as the patches are 2 lines big, you will allow them in,
> because
> it is too much for a user to update firmware or run a script to boot?
Our only two concerns are what is best on technical grounds, and what
is best for our users.
> Would you guys rather we shipped a boot script that ran the OS, fixed
> all these issues in-place in-firmware, so Linux did not have to have
> these
> workarounds,
Sure, if you can do that, that would be great.
Segher
^ permalink raw reply
* Re: Sequoia 440EPx patches not working
From: Valentine Barshak @ 2007-08-09 16:21 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070809083443.2b2f5407@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Thu, 09 Aug 2007 14:58:55 +0400
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
>> David Gibson wrote:
>>> On Wed, Aug 08, 2007 at 01:45:10PM -0500, Jerone Young wrote:
>>>> Using the Sequoia (AMCC 440EPx) patches recently submitted to the
>>>> list I am unable to boot to fully boot a uImage built with these
>>>> patches under Uboot. It appears to hang in very early boot.
>>> I'm guessing this is an old version of u-boot, that's not device
>>> tree aware. That would need a cuImage, not a uImage, and IIRC the
>>> posted patches didn't yet have cuboot support for Sequoia.
>>>
>> The patches do have cuImage support.
>> I have a Sequoia board with uBoot 1.1.6 and it boots cuImage fine.
>
> Speaking of those patches, are you planning on rebasing them against
> the latest 4xx series I sent out soon? That should have some cleanups
> that make adding sequoia support a bit easier.
>
> josh
Yes, I do :)
^ permalink raw reply
* Re: pci in arch/powerpc vs arch/ppc
From: Segher Boessenkool @ 2007-08-09 15:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Alexandros Kostopoulos
In-Reply-To: <46BB2CE2.2060207@freescale.com>
> It means the bus on which legacy I/O ports can be found. It's a fairly
> broken concept; each host bridge should really be treated as a
> completely separate entity, and if something like a VGA card has legacy
> I/O ports that need to be used, they should be looked for on the same
> PCI bus as the card itself. Legacy ISA ports should be discovered
> through the device tree (or platform devices, or whatever) that
> explicitly state which PCI-to-ISA bridge they're under.
Currently, Linux does not allow multiple PCI domains to use
overlapping legacy I/O ranges. Yeah it's a pain.
> Yes, apparently -- according to a recent thread here, recent versions
> of
> the PCI spec removed the wording that prohibited a zero BAR (is there
> then no way to disable a BAR?).
I couldn't find that prohibition even in ancient versions of
the PCI specification, for what it's worth. Maybe I'm just
blind.
> Still, it'd be better to avoid it.
Yeah, many drivers go bonkers otherwise. Some devices might
misbehave, too.
Segher
^ permalink raw reply
* Re: Re: my cpu is MPC860, kernel version is 2.6.20.14, the kernel startinfo in the mail. why does the kernel panic?
From: poorbeyond @ 2007-08-09 15:27 UTC (permalink / raw)
To: Scott Wood, Dan Malek; +Cc: Linux-ppc mail list
In-Reply-To: <46B79176.6080308@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 4340 bytes --]
it's now print below. it's too late here, sleep....
thanks
^_^=>bootm 300000
## Booting image at 00300000 ...
Image Name: Linux-2.6.20.14
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 839246 Bytes = 819.6 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x01D5DB10 => set upper limit to 0x00800000
No initrd
## Transferring control to Linux (at address 00000000) ...
bootm1
Linux version 2.6.20.14 (root@localhost.localdomain) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #2 Thu Aug 9 23:26:51 CST 2007
I2C/SPI/SMC1 microcode patch installed.
Zone PFN ranges:
DMA 0 -> 2048
Normal 2048 -> 2048
early_node_map[1] active PFN ranges
0: 0 -> 2048
Built 1 zonelists. Total pages: 2032
Kernel command line:
PID hash table entries: 32 (order: 5, 128 bytes)
Decrementer Frequency = 187500000/60
Warning: real time clock seems stuck!
cpm_uart: console: compat mode
Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 6164k available (1252k kernel code, 604k data, 84k init, 0k highmem)
Mount-cache hash table entries: 512
Zq001: start_kernel
------------[ cut here ]------------
Badness at arch/ppc/kernel/dma-mapping.c:345
Call Trace:
[00213E60] [00008BA0] (unreliable)
[00213E90] [000A1370]
[00213EA0] [0000388C]
[00213ED0] [0000304C]
[00213F90] [001A29B4]
[00213FA0] [000022B0]
[00213FF0] [00004A80]
NET: Registered protocol family 16
Generic PHY: Registered new driver
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 256 (order: 0, 4096 bytes)
TCP bind hash table entries: 128 (order: -1, 2560 bytes)
TCP: Hash tables configured (established 256 bind 128)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(4294836223.218:1): initialized
audit: cannot initialize inotify handle
io scheduler noop registered (default)
Serial: CPM driver $Revision: 0.02 $
cpm_uart: WARNING: no UART devices found on platform bus!
cpm_uart: the driver will guess configuration, but this mode is no longer supported.
ttyCPM0 at MMIO 0xff000a80 (irq = 20) is a CPM UART
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
LXT970: Registered new driver
LXT971: Registered new driver
fs_enet.c:v1.0 (Aug 8, 2005)
------------[ cut here ]------------
kernel BUG at arch/ppc/kernel/dma-mapping.c:233!
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: 00005584 LR: 00005538 CTR: 00000000
REGS: 00213e90 TRAP: 0700 Not tainted (2.6.20.14)
MSR: 00029032 <EE,ME,IR,DR> CR: 55222253 XER: A000247F
TASK = 00210ba0[1] 'swapper' THREAD: 00212000
GPR00: 00400165 00213F40 00210BA0 001EDD64 00000000 00000BDA 00269FFC 00000000
GPR08: 00160648 00000001 00401000 00400164 00000000 41082001 02000000 00000001
GPR16: 00000000 01FFFA54 FFFFFFFF 00000000 00800000 007FFF00 01FFAA14 00213F78
GPR24: 005FF000 00160000 00000000 001EDD40 00001000 001E6000 00231220 001EDD20
Call Trace:
[00213F40] [00005508] (unreliable)
[00213F70] [001A3578]
[00213FA0] [000022B0]
[00213FF0] [00004A80]
Instruction dump:
38630658 4813226d 7fc3f378 48050eb5 7fe3fb78 7f44d378 48041b35 48000078
801d0000 5400066e 3160ffff 7d2b0110 <0f090000> 38000400 7d20f828 7d290378
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 180 seconds..
poorbeyond
2007-08-09
发件人： Scott Wood
发送时间： 2007-08-07 05:24:12
收件人： Dan Malek
抄送： poorbeyond; Linux-ppc mail list
主题： Re: my cpu is MPC860, kernel version is 2.6.20.14, the kernel startinfo in the mail. why does the kernel panic?
Dan Malek wrote:
> On Aug 6, 2007, at 8:52 AM, Scott Wood wrote:
>
> > It wouldn't surprise me if the 8xx code has issues with PREEMPT; try
> > turning it off for now.
>
>
> What is your reason that 8xx would be any different?
It's just a suspicion based on my dealings with the CPM code, and the
fact that the crash appeared to happen in the CPM ethernet driver. It
could be wrong, but it doesn't hurt to try without PREEMPT and see if
the problem remains.
-Scott
[-- Attachment #2: Type: text/html, Size: 8038 bytes --]
^ permalink raw reply
* Re: pci in arch/powerpc vs arch/ppc
From: Scott Wood @ 2007-08-09 15:04 UTC (permalink / raw)
To: Alexandros Kostopoulos; +Cc: linuxppc-dev
In-Reply-To: <twig.1186611635.44657@inaccessnetworks.com>
Alexandros Kostopoulos wrote:
> Hi Scott,
>
> please allow me to insist a little bit more on this.
No problem. :-)
> 1. As far as the device tree is concerned, it is defined that the first 3
> numbers in every line of the ranges property (for our case, with #address-
> cells=3) is the PCI address of the device (in this case, host bridge), the
> next one is the local bus base address and the last two the local region
> size. In the case of memory space, res->start for the host bridge takes as a
> value ranges[3], which is actually the local bus base address. Why does the
> code for IO space uses ranges[2]. Shouldn't these two use the same field of
> the corresponding ranges property line?
Yes, I see what you mean -- non-primary buses appear to be completely
broken for IO-space. One part of the code insists that ranges[2] be
zero, but later it assumes that it matches the CPU-side offset from the
start of the primary IO-space (which cannot be zero, because it would
conflict with the primary bus).
> 2. As far as isa_io_base is concerned: When primary (what does this actually
> mean? primary PCI bus ?) is 1,
It means the bus on which legacy I/O ports can be found. It's a fairly
broken concept; each host bridge should really be treated as a
completely separate entity, and if something like a VGA card has legacy
I/O ports that need to be used, they should be looked for on the same
PCI bus as the card itself. Legacy ISA ports should be discovered
through the device tree (or platform devices, or whatever) that
explicitly state which PCI-to-ISA bridge they're under.
> then indeed
> isa_io_base=ranges[na+2]=ranges[3] (in this case) as it should (while res-
>
>>start=ranges[2] for some reason I don't understand, as I said earlier). And
>
> this is indeed added in the i/o address of the device during in/out
> operations. However, the driver I use, drivers/net/tulip/dmfe.c, actually
> checks whether res->start for the PCI device is zero, and if it is so, it
> fails. So, assuming that the pci_process_OF_bridges code is correct as is,
It's not, but even if the above bug were fixed it'd still start at zero
for the primary bus.
> then there is some problem with the driver?
Yes, apparently -- according to a recent thread here, recent versions of
the PCI spec removed the wording that prohibited a zero BAR (is there
then no way to disable a BAR?). Still, it'd be better to avoid it.
> Because the same driver worked in
> arch/ppc, which makes me think that there, res->start was NOT 0, but was
> already offset to the actual I/O space of the local bus.
The m82xx_pci code in arch/ppc seems to set isa_io_base to the start of
the I/O region, so I'm not sure why you'd get different behavior.
-Scott
^ permalink raw reply
* Re: Sequoia 440EPx patches not working
From: Jerone Young @ 2007-08-09 14:37 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, vbarshark
In-Reply-To: <20070809165612.12100334@localhost.localdomain>
So did a rebase on kernel.org 2.6.23-rc2 patch (as opposed the latest
git). I am using Uboot version 1.2.0-gc0c292b2. This is the version
that came with the board. It still appears to hang during early boot on
my Sequoia.
Trying the cuImage.sequoia.bin.gz just result in Uboot giving "Bad Magic
Number" when trying to boot it. This is also the same for using
cuImage.sequoia.elf.
So when I use the uImage file it will load but just hang after it's
loaded. I'm building it using "make uImage CROSS_COMPILE=<cross prefix>
ARCH=powerpc" on an x86 box.
I'll see what else I could possibly be doing wrong (maybe something
happened to the patch when I grabbed it off of gmane and the web filters
did something to it, I did have to fix a problem where in the
sequoia.dts file the web filter replace "@" with " at ". This was simple
enough to fix. Maybe something else when wrong. I'll see what else I can
look at.
On Thu, 2007-08-09 at 16:56 +0400, Vitaly Bordug wrote:
> On Wed, 08 Aug 2007 13:45:10 -0500
> Jerone Young wrote:
>
> > Using the Sequoia (AMCC 440EPx) patches recently submitted to the
> > list I am unable to boot to fully boot a uImage built with these
> > patches under Uboot. It appears to hang in very early boot.
> >
> >
> > Here is the output:
> > => tftp 400000
> > sequoia/uImage ENET Speed is 100 Mbps - FULL duplex connection
> > (EMAC0) Using ppc_4xx_eth0
> > device TFTP from server 9.53.41.24; our IP address is
> > 9.53.41.38 Filename
> > 'sequoia/uImage'. Load address:
> > 0x400000 Loading:
> > #################################################################
> > #################################################################
> > #################################################################
> > #######################
> > done Bytes transferred = 1112434 (10f972
> > hex) => bootm
> > 400000 ## Booting image at
> > 00400000 ... Image Name:
> > Linux-2.6.23-rc2 Image Type: PowerPC Linux Kernel Image (gzip
> > compressed) Data Size: 1112370 Bytes = 1.1
> > MB Load Address:
> > 00000000 Entry Point:
> > 00000000 Verifying Checksum ...
> > OK Uncompressing Kernel Image ... OK
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
> This seems to be a wrong image..
>
> Are you using "make zImage" ?
>
> The proper uImage after that command would be smth like cuImage* then...
>
^ 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