* Re: [PATCH] phy: export phy_mii_ioctl
From: Jon Smirl @ 2007-09-19 13:56 UTC (permalink / raw)
To: Pedro Luis D. L.; +Cc: netdev, Domen Puncer, linuxppc-embedded
In-Reply-To: <BLU106-W49D16A32DDFE2611E15371CAB90@phx.gbl>
On 9/19/07, Pedro Luis D. L. <carcadiz@hotmail.com> wrote:
>
> Hello Jon,
> I=B4m also working with a Phytec pcm030, but I can=B4t get it booted...
> Which kernel are you using?
> I tried to apply the 7 bestcomm patches from Sylvain and patch over these=
with this new ones that Domen released.
> The base kernel I=B4m using is 2.6.22.6 from kernel.org.
> Although I used the patch that creates pcm030.c in arch/platforms/52xx/ a=
nd compiled using this file, it gets halted at booting time.
>
> Bytes transferred =3D 5091 (13e3 hex)
> ## Booting image at 00500000 ...
> Image Name: Linux-2.6.22.6
> Created: 2007-09-19 8:53:02 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1196911 Bytes =3D 1.1 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using flat device tree at 0x400000
>
> (No more output and boot is halted)
The root name of your device tree needs to match the name in pcm030.c
pcm030_probe(void). If they don't match this happens.
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Eth1 init and link status
From: - Reyneke @ 2007-09-19 13:54 UTC (permalink / raw)
To: linuxppc-embedded
HI,
We've run into a bit of an odd problem and we are not sure where to go and
look for the cause.
We have some 440EPx based hardware with two GIG-Ethernet ports using RGMII
and 2x ET1011C PHY's. Problem is that eth1 will only initialise correctly
(i.e. receive and transmit) if eth0 has a link. Eth0 always work OK,
regardless of eth1 status. Eth1 will work OK if eth0 has a link (i.e.
initialised) at time of setup. Once initialised, eth0 status is irrelevant.
All this is during Linux boot process.
Any ideas?
We can access PHY registers via u-boot (mii commands). Same 1Gig link speed
is used on both ports. Linux kernel is 2.6.19.
Regards
Jan Reyneke
_________________________________________________________________
Can you see your house from the sky? Try Live Search Maps
http://maps.live.com
^ permalink raw reply
* Re: [PATCH 2/3] usb: ehci-ppc-of dts bindings.
From: Valentine Barshak @ 2007-09-19 13:52 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <19e5f15308dfb8e60e2e49379666d00a@kernel.crashing.org>
Segher Boessenkool wrote:
>> + l) USB EHCI controllers
>> +
>> + Required properties:
>> + - device_type : should be "usb".
>
> No device_type please. The published USB binding doesn't define
> one on purpose.
>
Could you please, explain why?
Sorry, I don't think I get the concept of device description here.
>> + - compatible : should be "ehci".
>
> Just "ehci" isn't enough -- compare to OHCI, which is the name for
> a kind of USB host controller as well as for a kind of Firewire
> host controller.
Actually, I though device type="usb" + compatible="ehci" would be enough.
>
> Maybe "usb-ehci" is best -- can anyone think of a better name?
Again, why not type="usb", compatible="ehci"?
>
>> + - reg : Offset and length of the register set for the device
>
> Address and length. You also should declare here how the optional
> EHCI register blocks should be encoded (the USB debug port, etc.)
>
>> + - interrupts : <a b> where a is the interrupt number and b is a
>> + field that represents an encoding of the sense and level
>> + information for the interrupt.
>
> This is incorrect; not all interrupt domains use two cells, and
> not all that do have this meaning for those cells.
Well, this was just copied from other descriptions in
Documentation/powerpc/booting-without-of.txt
Do we need to fix them all?
>
> Instead, you should just say how many interrupts should be here,
> and which is which in the EHCI standard.
>
>> + - interrupt-parent : the phandle for the interrupt controller that
>> + services interrupts for this device.
>
> Not every EHCI node needs this; just don't mention this at all,
> interrupt mapping is fully defined for all devices elsewhere
> already (in the "interrupt mapping" recommended practice).
>
>> + If device registers are implemented in big endian mode, the device
>> + node should have "big-endian" property.
>> + If controller implementation operates with big endian descriptors,
>> + compatible should also have "ehci-be-desc"
>
> Ah, I understand what this is about, finally.
>
> Don't put this in "compatible"; instead, do a "big-endian-descriptors"
> property similar to the "big-endian" property. That last one should
> maybe be "big-endian-registers" here then, to avoid confusion.
>
> Or make "big-endian" mean both big-endian registers *and* big-endian
> descriptors.
But doesn't "big-endian" property actually mean "big-endian-registers"?
Do we have to overload property meaning in this case?
>
> I have no opinion which is best; it depends on what configurations
> actually exist, and how popular those are.
>
>> + ehci@e0000300 {
>> + device_type = "usb";
>> + compatible = "ibm,ehci-440epx", "ehci-be-desc", "ehci";
>> + interrupts = <1a 4>;
>> + interrupt-parent = <&UIC0>;
>> + reg = <0 e0000300 ff>;
>
> Length should be 100 here.
>
>> + big-endian;
>> + };
>
>
> Segher
>
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH] powerpc: Avoid pointless WARN_ON(irqs_disabled()) from panic codepath
From: Satyam Sharma @ 2007-09-19 13:45 UTC (permalink / raw)
To: Josh Boyer
Cc: Randy Dunlap, Mailing List, Kamalesh Babulal, linuxppc-dev,
Paul Mackerras, Linux
In-Reply-To: <20070917204625.64b97392@vader.jdub.homelinux.org>
> On Mon, 17 Sep 2007 18:37:49 -0700
> Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
> > On Tue, 18 Sep 2007 05:13:40 +0530 (IST) Satyam Sharma wrote:
> >
> > > Untested (not even compile-tested) patch.
> > > Could someone point me to ppc32/64 cross-compilers for i386?
> >
> > OSDL had some, but those are gone now.
> > I downloaded all of them and still use them, although it would
> > be good to have some more recent versions of them.
> >
> > I put the power* compiler tarballs here:
> >
> > http://userweb.kernel.org/~rdunlap/cross-compilers/
Thanks -- BTW I made some simple changes to the tree structure in there
and added a few distcc [*] related scriptlets. The resulting tar ball:
http://www.cse.iitk.ac.in/users/ssatyam/powerpc64-unknown-linux-gnu.tar.bz2
can be made to work with Andrew's nice "xb" script with the following
trivial patch:
--- cross-compilers/read-me.txt~powerpc64 2007-09-19 14:39:01.000000000 +0530
+++ cross-compilers/read-me.txt 2007-09-19 14:44:29.000000000 +0530
@@ -3,7 +3,7 @@ i386 cross-compilation binaries for seve
on RH FC5 and RH FC6 i386 and x86_64.
- untar the tarball in /
-- setenv ARCH sparc64 (or alpha, arm, i386, ia64, m68k, mips, s390, sparc)
+- setenv ARCH sparc64 (or alpha, arm, i386, ia64, m68k, mips, powerpc64, s390, sh4, sparc, x86_64)
- xb mrproper
- xb allmodconfig
- xb
--- cross-compilers/xb~powerpc64 2007-09-19 14:40:09.000000000 +0530
+++ cross-compilers/xb 2007-09-19 14:52:46.000000000 +0530
@@ -31,6 +31,7 @@ I=vmlinux
[ $ARCH = m68k ] && CT=gcc-4.1.0-glibc-2.3.6
[ $ARCH = mips ] && CT=gcc-3.4.5-glibc-2.3.6
[ $ARCH = powerpc ] && CT=gcc-4.1.0-glibc-2.3.6 && XARCH=powerpc-405-linux-gnu
+[ $ARCH = powerpc64 ] && CT=gcc-3.4.0-glibc-2.3.2 && export ARCH=powerpc
[ $ARCH = s390 ] && CT=gcc-4.1.0-glibc-2.3.6
[ $ARCH = sh ] && CT=gcc-3.4.5-glibc-2.3.6 && XARCH=sh4-unknown-linux-gnu
[ $ARCH = sparc ] && CT=gcc-4.1.0-glibc-2.3.6
On Mon, 17 Sep 2007, Josh Boyer wrote:
>
> Crosstool is widely used. It'll build several combinations of
> gcc/binutils/glibc for you.
>
> http://www.kegel.com/crosstool/
In fact, it turns out OSDL's cross-compiler toolchains were built with
crosstool itself. Should also add that those OSDL compilers are too old
(gcc version 3.4.x-3.5.x mostly -- my build was totally spammed with those
"+m" in asm constraints related warnings), so I'll try and build a few
more recent ones (at least for the more popular platforms) over the
weekend too.
Satyam
[*] But I'm a bit skeptical if the distcc stuff in "xb" works as intended.
Has anybody used that successfully? Will test it over the weekend ...
^ permalink raw reply
* Re: CONFIG_BLK_DEV_BSG=n
From: Jens Axboe @ 2007-09-19 12:53 UTC (permalink / raw)
To: David Howells
Cc: James Bottomley, akpm, linux-scsi, Gala Kumar-B11780,
fujita.tomonori, linuxppc-dev, paulus
In-Reply-To: <19650.1190040390@redhat.com>
On Mon, Sep 17 2007, David Howells wrote:
>
> James Bottomley <James.Bottomley@SteelEye.com> wrote:
>
> > > Which solution would you be more comfortable with?
> >
> > The one which is currently in -mm is this one:
> >
> > http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commit;h=49892223f7d3a2333ef9e6cbdd526676e1fc517a
>
> In my opinion, this is the wrong fix. There shouldn't be anything in
> the kernel using stuff from bsg.h if CONFIG_BLOCK=n, so there should
> be an error if anything tries to. The correct fix is to exclude the
> non-userspace-visible contents of bsg.h with #ifdef CONFIG_BLOCK, not
> to declare things that we've tried to make sure specifically aren't
> declared.
I agree, I'll pass your fix on.
--
Jens Axboe
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-09-19 12:38 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get three more bug-fixes for powerpc, as listed below.
Thanks,
Paul.
arch/powerpc/kernel/time.c | 8 +++++---
arch/powerpc/kernel/vdso.c | 12 ++++++++++++
arch/powerpc/platforms/cell/spufs/sched.c | 4 ++--
include/asm-powerpc/time.h | 5 +++++
4 files changed, 24 insertions(+), 5 deletions(-)
commit c27da339698145a9383e052c1070a950d30da478
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed Sep 19 14:21:56 2007 +1000
[POWERPC] Fix timekeeping on PowerPC 601
Recent changes to the timekeeping code broke support for the PowerPC 601
processor which doesn't have the usual timebase facility but a slightly
different thing called (yuck) the RTC.
This fixes it, boot tested on an old 601 based PowerMac 7200.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 7b5acbaac3f94ab810a977c0ec4e5fcabbf51bed
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed Sep 19 14:21:56 2007 +1000
[POWERPC] Don't expose clock vDSO functions when CPU has no timebase
We forgot to remove the clock_gettime, clock_getres and get_tbfreq vDSO
calls on CPUs that have no timebase such as 601 or 403 (old CPUs that have
different mechanisms and for which the vDSO code will not work properly).
This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit c0e7b4aa1c09ea992808ea8c079141bc8dd0f5bc
Author: Christoph Hellwig <hch@lst.de>
Date: Wed Sep 19 14:38:12 2007 +1000
[POWERPC] spusched: Fix null pointer dereference in find_victim
find_victim can dereference a NULL pointer when iterating over the list
of victim spus because list_mutex only guarantees spu->ct to be stable,
but of course not to be non-NULL.
Also fix find_victim to not call spu_unbind_context without list_mutex
because that violates the above guarantee.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: Cleanups for physmap_of.c
From: Josh Boyer @ 2007-09-19 12:14 UTC (permalink / raw)
To: David Gibson; +Cc: Paul Mackerras, Vitaly Wool, linuxppc-dev
In-Reply-To: <20070919041646.GA30212@localhost.localdomain>
On Wed, 19 Sep 2007 14:16:46 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> This patch includes a whole batch of smallish cleanups for
> drivers/mtd/physmap_of.c.
>
> - A bunch of uneeded #includes are removed
> - We switch to the modern linux/of.h etc. in place of
> asm/prom.h
> - Use some helper macros to avoid some ugly inline #ifdefs
> - A few lines of unreachable code are removed
> - A number of indentation / line-wrapping fixes
> - More consistent use of kernel idioms such as if (!p) instead
> of if (p == NULL)
> - Clarify some printk()s and other informative strings.
Most of that looks good. Just a couple issues below. Mostly it
doesn't apply cleanly to my tree because you didn't base if off of the
patch I sent out last week to fix optional partitions.
> - (the big one) Despite the name, this driver really has
> nothing to do with drivers/mtd/physmap.c. The fact that the flash
> chips must be physically direct mapped is a constrant, but doesn't
> really say anything about the actual purpose of this driver, which is
> to instantiate MTD devices based on information from the device tree.
> Therefore the physmap name is replaced everywhere within the file with
> "of_flash". The file itself and the Kconfig option is not renamed for
> now (so that the diff is actually a diff). That can come later.
Later when? If we're all in agreement, then why don't we just apply
your patch after you fix it up and I can move the file in my git tree.
That way we don't forget about it.
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Index: working-2.6/drivers/mtd/maps/physmap_of.c
> ===================================================================
> --- working-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-09-14 14:24:06.000000000 +1000
> +++ working-2.6/drivers/mtd/maps/physmap_of.c 2007-09-19 13:59:23.000000000 +1000
> @@ -1,5 +1,5 @@
> /*
> - * Normal mappings of chips in physical memory for OF devices
> + * Flash mappings described by the OF (or flattened) device tree
> *
> * Copyright (C) 2006 MontaVista Software Inc.
> * Author: Vitaly Wool <vwool@ru.mvista.com>
> @@ -15,20 +15,15 @@
>
> #include <linux/module.h>
> #include <linux/types.h>
> -#include <linux/kernel.h>
> #include <linux/init.h>
> -#include <linux/slab.h>
> #include <linux/device.h>
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/map.h>
> #include <linux/mtd/partitions.h>
> -#include <linux/mtd/physmap.h>
> -#include <asm/io.h>
> -#include <asm/prom.h>
> -#include <asm/of_device.h>
> -#include <asm/of_platform.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
>
> -struct physmap_flash_info {
> +struct of_flash {
> struct mtd_info *mtd;
> struct map_info map;
> struct resource *res;
> @@ -38,8 +33,10 @@ struct physmap_flash_info {
> };
>
> #ifdef CONFIG_MTD_PARTITIONS
> +#define OF_FLASH_PARTS(info) ((info)->parts)
> +
> static int parse_obsolete_partitions(struct of_device *dev,
> - struct physmap_flash_info *info,
> + struct of_flash *info,
> struct device_node *dp)
> {
> int i, plen, nr_parts;
> @@ -56,11 +53,9 @@ static int parse_obsolete_partitions(str
>
> nr_parts = plen / sizeof(part[0]);
>
> - info->parts = kzalloc(nr_parts * sizeof(struct mtd_partition), GFP_KERNEL);
> - if (!info->parts) {
> - printk(KERN_ERR "Can't allocate the flash partition data!\n");
> + info->parts = kzalloc(nr_parts * sizeof(*info->parts), GFP_KERNEL);
> + if (!info->parts)
> return -ENOMEM;
You dropped the printk here. Any particular reason why?
> - }
>
> names = of_get_property(dp, "partition-names", &plen);
>
> @@ -86,8 +81,8 @@ static int parse_obsolete_partitions(str
> return nr_parts;
> }
>
> -static int __devinit process_partitions(struct physmap_flash_info *info,
> - struct of_device *dev)
> +static int __devinit parse_partitions(struct of_flash *info,
> + struct of_device *dev)
> {
> const char *partname;
> static const char *part_probe_types[]
> @@ -109,87 +104,68 @@ static int __devinit process_partitions(
> for (pp = dp->child; pp; pp = pp->sibling)
> nr_parts++;
>
> - if (nr_parts) {
> - info->parts = kzalloc(nr_parts * sizeof(struct mtd_partition),
> - GFP_KERNEL);
> - if (!info->parts) {
> - printk(KERN_ERR "Can't allocate the flash partition data!\n");
> - return -ENOMEM;
> - }
> + if (nr_parts == 0)
> + return parse_obsolete_partitions(dev, info, dp);
You reintroduced the optional partitions bug I fixed with:
http://git.infradead.org/?p=users/jwboyer/powerpc.git;a=commit;h=7cafc8f8c89d1f49039b7c345ca832fbd2d1e639
josh
^ permalink raw reply
* Configuration-Problem ext-interrupt on mpc52xx
From: S. Fricke @ 2007-09-19 11:59 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 655 bytes --]
Hi,
how can i configure an "ext interrupt" to high-level? I want a interruption on
IRQ2, but I checked with an oscilloscope that the pin has a low state and I
needs a high state.
I have tried, after I got the irq (with irq_of_parse_and_map), set it with
set_irq_type(irq, IRQ_TYPE_LEVEL_HIGH);
But I think it is a system-configuration (irq_desc) and no
device-configuration.
Mit freundlichen Gruessen
Silvio Fricke
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] phy: export phy_mii_ioctl
From: Domen Puncer @ 2007-09-19 11:56 UTC (permalink / raw)
To: Jon Smirl; +Cc: netdev, linuxppc-embedded
In-Reply-To: <9e4733910709181217v417438s85bb9e6b4ad4b475@mail.gmail.com>
On 18/09/07 15:17 -0400, Jon Smirl wrote:
> On 9/18/07, Domen Puncer <domen@coderock.org> wrote:
> > More testing and getting it to work properly on Phytec pcm030 would
> > be great.
>
> I compiled it as a module:
> CC [M] drivers/net/fec_mpc52xx/fec.o
> drivers/net/fec_mpc52xx/fec.c:613: warning: 'mpc52xx_fec_mac_setup'
> defined but not used
>
> This code needs to be enclosed in "#ifndef MODULE". But why aren't you
> using module_param() to make a string parameter and then copy it into
> mpc52xx_fec_mac_addr[] if the parameter is not null?
Right,
Patch at the end.
When compiled as module use "modprobe fec_mpc52xx mac=foo",
when built-in add to boot line: "fec_mpc52xx.mac=foo"
As for link-up-printk in the middle of DHCP requests...
is it really that big of a problem?
This sort of things happen when printk doesn't have the whole
line... getting rid of link-up message would just hide it (it can show
ie. when an usb device is bound to scsi layer).
Domen
---
drivers/net/fec_mpc52xx/fec.c | 18 ++----------------
1 files changed, 2 insertions(+), 16 deletions(-)
Index: linux.git/drivers/net/fec_mpc52xx/fec.c
===================================================================
--- linux.git.orig/drivers/net/fec_mpc52xx/fec.c
+++ linux.git/drivers/net/fec_mpc52xx/fec.c
@@ -53,6 +53,8 @@ static void fec_start(struct net_device
static void fec_reset(struct net_device *dev);
static u8 mpc52xx_fec_mac_addr[6];
+module_param_array_named(mac, mpc52xx_fec_mac_addr, byte, NULL, 0);
+MODULE_PARM_DESC(mac, "six hex digits, ie. 0x1,0x2,0xc0,0x01,0xba,0xbe");
static void fec_tx_timeout(struct net_device *dev)
{
@@ -609,22 +611,6 @@ static void fec_set_multicast_list(struc
}
}
-static int __init mpc52xx_fec_mac_setup(char *mac_address)
-{
- int i;
- u64 val64;
-
- val64 = simple_strtoull(mac_address, NULL, 16);
-
- for (i = 0; i < 6; i++)
- mpc52xx_fec_mac_addr[5-i] = val64 >> (i*8);
-
- return 0;
-}
-
-__setup("mpc52xx-mac=",mpc52xx_fec_mac_setup);
-
-
/**
* fec_hw_init
* @dev: network device
^ permalink raw reply
* RE: [PATCH] phy: export phy_mii_ioctl
From: Pedro Luis D. L. @ 2007-09-19 11:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200709191238.00183.jbe@pengutronix.de>
Juergen wrote:
>
>Pedro,
>
>On Wednesday 19 September 2007 10:54, Pedro Luis D. L. wrote:
>> I=B4m also working with a Phytec pcm030, but I can=B4t get it booted...
>> Which kernel are you using?
>> I tried to apply the 7 bestcomm patches from Sylvain and patch over thes=
e
>> with this new ones that Domen released. The base kernel I=B4m using is
>> 2.6.22.6 from kernel.org.
>> Although I used the patch that creates pcm030.c in arch/platforms/52xx/ =
and
>> compiled using this file, it gets halted at booting time.
>>
>> Bytes transferred =3D 5091 (13e3 hex)
>> ## Booting image at 00500000 ...
>> Image Name: Linux-2.6.22.6
>> Created: 2007-09-19 8:53:02 UTC
>> Image Type: PowerPC Linux Kernel Image (gzip compressed)
>> Data Size: 1196911 Bytes =3D 1.1 MB
>> Load Address: 00000000
>> Entry Point: 00000000
>> Verifying Checksum ... OK
>> Uncompressing Kernel Image ... OK
>> Booting using flat device tree at 0x400000
>>
>> (No more output and boot is halted)
>=20
>Check your oftree! Most of the time this behaviour means its a wrong oftre=
e in=20
>use.
I=B4m using an specific pcm030.dts oftree that works for the 2.6.20 kernel.=
I=B4m not quite familiar with the oftree stuff, but I thought it should wo=
rk also for the 2.6.22.6.
Is there any other dts file? Where can I find it?
Pedro.
PD: Sorry. I sent the previous message to Jon, Domen and someone else too b=
esides the list. I had some problems with the browser... Even sent twice th=
e message :-(
>Juergen
>=20
>--=20
>Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
>Pengutronix - Linux Solutions for Science and Industry
> Handelsregister: Amtsgericht Hildesheim, HRA 2686
> Vertretung Sued/Muenchen, Germany
> Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
>
_________________________________________________________________
Llama a tus amigos de PC a PC: =A1Es GRATIS!
http://get.live.com/messenger/overview=
^ permalink raw reply
* [PATCH] [POWERPC] Fix various build errors seen on MPC885ADS with CONFIG_MODULES=y
From: Anton Vorontsov @ 2007-09-19 11:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <4F1F43EE-214F-4EB0-82CF-9EC04830ECC6@kernel.crashing.org>
On Tue, Sep 18, 2007 at 09:26:18AM -0500, Kumar Gala wrote:
>
> On Sep 18, 2007, at 7:29 AM, Anton Vorontsov wrote:
>
>> cpm_install_handler and cpm_free_handler neither used nor defined
>> for arch/powerpc.
>>
>> This causes MPC8xx build failure, patch used to fix that.
>
> can you add the __res fix, and EXPORT() and do these three as one patch and
> improve the commit message. I'm guessing this all shows up when we try to
> build with CONFIG_MODULES=y. Put the actual compile failures in the commit
> message.
>
> - k
>
Done, thanks.
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [POWERPC] Fix various build errors seen on MPC885ADS with CONFIG_MODULES=y
CC arch/powerpc/kernel/ppc_ksyms.o
arch/powerpc/kernel/ppc_ksyms.c:184: error: `__res' undeclared here (not in a function)
arch/powerpc/kernel/ppc_ksyms.c:184: warning: type defaults to `int' in declaration of `__res'
make[1]: *** [arch/powerpc/kernel/ppc_ksyms.o] Error 1
make: *** [arch/powerpc/kernel] Error 2
There is no __res in the arch/powerpc tree.
LD .tmp_vmlinux1
arch/powerpc/kernel/built-in.o(__ksymtab+0x1b0): undefined reference to `cpm_free_handler'
arch/powerpc/kernel/built-in.o(__ksymtab+0x1b8): undefined reference to `cpm_install_handler'
make: *** [.tmp_vmlinux1] Error 1
cpm_install_handler and cpm_free_handler neither used nor defined
for arch/powerpc.
CC arch/powerpc/sysdev/commproc.o
arch/powerpc/sysdev/commproc.c:390: error: redefinition of '__kstrtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:384: error: previous definition of '__kstrtab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:390: error: redefinition of '__ksymtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:384: error: previous definition of '__ksymtab_cpm_dpram_addr' was here
make[1]: *** [arch/powerpc/sysdev/commproc.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2
Second export should be for cpm_dpram_phys not cpm_dpram_addr, this
is copy-n-paste problem.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/kernel/ppc_ksyms.c | 8 --------
arch/powerpc/sysdev/commproc.c | 2 +-
include/asm-powerpc/commproc.h | 3 ---
3 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index 430c502..4d28774 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -176,14 +176,6 @@ EXPORT_SYMBOL(console_drivers);
EXPORT_SYMBOL(cacheable_memcpy);
#endif
-#ifdef CONFIG_8xx
-EXPORT_SYMBOL(cpm_install_handler);
-EXPORT_SYMBOL(cpm_free_handler);
-#endif /* CONFIG_8xx */
-#if defined(CONFIG_8xx)
-EXPORT_SYMBOL(__res);
-#endif
-
#ifdef CONFIG_PPC32
EXPORT_SYMBOL(next_mmu_context);
EXPORT_SYMBOL(set_context);
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index b562afc..160a8b4 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -387,4 +387,4 @@ uint cpm_dpram_phys(u8* addr)
{
return (dpram_pbase + (uint)(addr - dpram_vbase));
}
-EXPORT_SYMBOL(cpm_dpram_addr);
+EXPORT_SYMBOL(cpm_dpram_phys);
diff --git a/include/asm-powerpc/commproc.h b/include/asm-powerpc/commproc.h
index 3972487..0d92012 100644
--- a/include/asm-powerpc/commproc.h
+++ b/include/asm-powerpc/commproc.h
@@ -686,7 +686,4 @@ typedef struct risc_timer_pram {
#define CICR_IEN ((uint)0x00000080) /* Int. enable */
#define CICR_SPS ((uint)0x00000001) /* SCC Spread */
-extern void cpm_install_handler(int vec, void (*handler)(void *), void *dev_id);
-extern void cpm_free_handler(int vec);
-
#endif /* __CPM_8XX__ */
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH 2/2] PowerPC: Fix Sequoia MAL0 and EMAC dts entries.
From: Valentine Barshak @ 2007-09-19 11:14 UTC (permalink / raw)
To: Valentine Barshak, linuxppc-dev
In-Reply-To: <20070919010526.GA23646@localhost.localdomain>
David Gibson wrote:
> On Tue, Sep 18, 2007 at 09:29:13PM +0400, Valentine Barshak wrote:
>> According to PowerPC 440EPx documentation,
>> MAL0 is comprised of four channels (two transmit and two receive).
>> Each channel is dedicated to one of two EMAC cores.
>> This patch fixes Sequoia DTS MAL0 entry and EMAC entries,
>> assigning correct channel numbers to EMACs.
>
> Hrm.. did they change the EMAC in 440EPx to only use one MAL
> tx-channel? All the older ones could use two (for no readily apparent
> reason, IMO).
>
Yes, they did.
Just 1 tx and 1 rx-channel per EMAC. Just 2 bits to select channels,
while all other bits in MAL registers are reserved.
I'm not sure why they did it (possible bus bandwidth problems), but it's
impossible to set more than 1 rx/tx channel for each EMAC in 440EPx.
^ permalink raw reply
* Re: [PATCH] phy: export phy_mii_ioctl
From: Juergen Beisert @ 2007-09-19 10:37 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: netdev, Domen Puncer
In-Reply-To: <BLU106-W49D16A32DDFE2611E15371CAB90@phx.gbl>
Pedro,
On Wednesday 19 September 2007 10:54, Pedro Luis D. L. wrote:
> I=B4m also working with a Phytec pcm030, but I can=B4t get it booted...
> Which kernel are you using?
> I tried to apply the 7 bestcomm patches from Sylvain and patch over these
> with this new ones that Domen released. The base kernel I=B4m using is
> 2.6.22.6 from kernel.org.
> Although I used the patch that creates pcm030.c in arch/platforms/52xx/ a=
nd
> compiled using this file, it gets halted at booting time.
>
> Bytes transferred =3D 5091 (13e3 hex)
> ## Booting image at 00500000 ...
> Image Name: Linux-2.6.22.6
> Created: 2007-09-19 8:53:02 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1196911 Bytes =3D 1.1 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using flat device tree at 0x400000
>
> (No more output and boot is halted)
Check your oftree! Most of the time this behaviour means its a wrong oftree=
in=20
use.
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* 2.6.23-rc6-mm1 -- powerpc pSeries_log_error panic in rtas_call/early_enable_eeh
From: Andy Whitcroft @ 2007-09-19 9:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20070918011841.2381bd93.akpm@linux-foundation.org>
Seeing the following panic booting an old powerpc LPAR:
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc000000000047b48
cpu 0x0: Vector: 300 (Data Access) at [c0000000006a3750]
pc: c000000000047b48: .pSeries_log_error+0x364/0x420
lr: c000000000047acc: .pSeries_log_error+0x2e8/0x420
sp: c0000000006a39d0
msr: 8000000000001032
dar: 0
dsisr: 42000000
current = 0xc0000000005acab0
paca = 0xc0000000005ad700
pid = 0, comm = swapper
enter ? for help
[c0000000006a3af0] c000000000021164 .rtas_call+0x200/0x250
[c0000000006a3ba0] c000000000049d50 .early_enable_eeh+0x168/0x360
[c0000000006a3c70] c00000000002f674 .traverse_pci_devices+0x8c/0x138
[c0000000006a3d10] c000000000560ce8 .eeh_init+0x1a8/0x200
[c0000000006a3db0] c00000000055fb70 .pSeries_setup_arch+0x128/0x234
[c0000000006a3e40] c00000000054f830 .setup_arch+0x214/0x24c
[c0000000006a3ee0] c000000000546a38 .start_kernel+0xd4/0x3e4
[c0000000006a3f90] c00000000045adc4 .start_here_common+0x54/0x58
0:mon>
This machine is:
# cat /proc/cpuinfo
processor : 0
cpu : POWER4+ (gq)
clock : 1703.965296MHz
revision : 19.0
[...]
machine : CHRP IBM,7040-681
-apw
^ permalink raw reply
* 2.6.23-rc6-mm1 -- powerpc link failure
From: Andy Whitcroft @ 2007-09-19 9:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20070918011841.2381bd93.akpm@linux-foundation.org>
I am seeing this strange link error from a PowerMac G5 (powerpc):
[...]
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1
Compiler version below.
root@elm3b19:~# gcc -v
Using built-in specs.
Target: powerpc-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-softfloat
--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32
--disable-werror --enable-checking=release powerpc-linux-gnu
Thread model: posix
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
-apw
^ permalink raw reply
* RE: [PATCH] phy: export phy_mii_ioctl
From: Pedro Luis D. L. @ 2007-09-19 8:54 UTC (permalink / raw)
To: Jon Smirl, Domen Puncer; +Cc: netdev, linuxppc-embedded
In-Reply-To: <9e4733910709181229m4afe7ecr56e2411f52a84232@mail.gmail.com>
Hello Jon,
I=B4m also working with a Phytec pcm030, but I can=B4t get it booted...
Which kernel are you using?
I tried to apply the 7 bestcomm patches from Sylvain and patch over these w=
ith this new ones that Domen released.
The base kernel I=B4m using is 2.6.22.6 from kernel.org.
Although I used the patch that creates pcm030.c in arch/platforms/52xx/ and=
compiled using this file, it gets halted at booting time.
Bytes transferred =3D 5091 (13e3 hex)
## Booting image at 00500000 ...
Image Name: Linux-2.6.22.6
Created: 2007-09-19 8:53:02 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1196911 Bytes =3D 1.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x400000
(No more output and boot is halted)
Are you using any other patch for the platform or any other kernel, because=
I tried to apply these patches to a 2.6.20 kernel and are not successful.
Bests,
Pedro.
> Date: Tue, 18 Sep 2007 15:29:09 -0400> From: jonsmirl@gmail.com=20
> To: domen@coderock.org> Subject: Re: [PATCH] phy: export phy_mii_ioctl=20
> CC: netdev@vger.kernel.org; linuxppc-embedded@ozlabs.org=20
>> On 9/18/07, Domen Puncer wrote:=20
>> More testing and getting it to work properly on Phytec pcm030 would=20
>> be great.>> Do we want to do anything about this?=20
>> [ 1.569657] net eth0: attached phy 0 to driver Generic PHY=20
> [ 2.576013] Sending DHCP requests .PHY: f0003000:00 - Link is Up=20
> - 100/Full> [ 4.612000] ., OK=20
> [ 6.764005] IP-Config: Got DHCP answer from 192.168.1.200, my=20
> address is 192.168.1.5
>> What is happening is the printk for "PHY: f0003000:00 - Link is Up=20
> - 100/Full" is done in an interrupt and it comes in the middle of the> ke=
rnel doing DHCP and printing ... without a CR.=20
>> Two possible solutions, get rid of the link-up message or wait in in=20
> the initial driver load until the link is up. Or we could leave it the=20
> way it is, but some people may report this as a bug.
>>> --> Jon Smirl> jonsmirl@gmail.com=20
> _______________________________________________=20
> Linuxppc-embedded mailing list> Linuxppc-embedded@ozlabs.org> https://ozl=
abs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
Busca desde cualquier p=E1gina Web con una protecci=F3n excepcional. Consig=
ue la Barra de herramientas de Windows Live hoy mismo y GRATUITAMENTE.
http://www.toolbar.live.com=
^ permalink raw reply
* RE: [PATCH] phy: export phy_mii_ioctl
From: Pedro Luis D. L. @ 2007-09-19 8:54 UTC (permalink / raw)
To: Jon Smirl, Domen Puncer; +Cc: netdev, linuxppc-embedded
In-Reply-To: <9e4733910709181229m4afe7ecr56e2411f52a84232@mail.gmail.com>
Hello Jon,
I=B4m also working with a Phytec pcm030, but I can=B4t get it booted...
Which kernel are you using?
I tried to apply the 7 bestcomm patches from Sylvain and patch over these w=
ith this new ones that Domen released.
The base kernel I=B4m using is 2.6.22.6 from kernel.org.
Although I used the patch that creates pcm030.c in arch/platforms/52xx/ and=
compiled using this file, it gets halted at booting time.
Bytes transferred =3D 5091 (13e3 hex)
## Booting image at 00500000 ...
Image Name: Linux-2.6.22.6
Created: 2007-09-19 8:53:02 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1196911 Bytes =3D 1.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x400000
(No more output and boot is halted)
Are you using any other patch for the platform or any other kernel, because=
I tried to apply these patches to a 2.6.20 kernel and are not successful.
Bests,
Pedro.
> Date: Tue, 18 Sep 2007 15:29:09 -0400> From: jonsmirl@gmail.com=20
> To: domen@coderock.org> Subject: Re: [PATCH] phy: export phy_mii_ioctl=20
> CC: netdev@vger.kernel.org; linuxppc-embedded@ozlabs.org=20
>> On 9/18/07, Domen Puncer wrote:=20
>> More testing and getting it to work properly on Phytec pcm030 would=20
>> be great.>> Do we want to do anything about this?=20
>> [ 1.569657] net eth0: attached phy 0 to driver Generic PHY=20
> [ 2.576013] Sending DHCP requests .PHY: f0003000:00 - Link is Up=20
> - 100/Full> [ 4.612000] ., OK=20
> [ 6.764005] IP-Config: Got DHCP answer from 192.168.1.200, my=20
> address is 192.168.1.5
>> What is happening is the printk for "PHY: f0003000:00 - Link is Up=20
> - 100/Full" is done in an interrupt and it comes in the middle of the> ke=
rnel doing DHCP and printing ... without a CR.=20
>> Two possible solutions, get rid of the link-up message or wait in in=20
> the initial driver load until the link is up. Or we could leave it the=20
> way it is, but some people may report this as a bug.
>>> --> Jon Smirl> jonsmirl@gmail.com=20
> _______________________________________________=20
> Linuxppc-embedded mailing list> Linuxppc-embedded@ozlabs.org> https://ozl=
abs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
Busca desde cualquier p=E1gina Web con una protecci=F3n excepcional. Consig=
ue la Barra de herramientas de Windows Live hoy mismo y GRATUITAMENTE.
http://www.toolbar.live.com=
^ permalink raw reply
* Re: cross compiling a library with ELDK
From: Murat Artun @ 2007-09-19 8:28 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20070918224126.48196247FE@gemini.denx.de>
Wolfgang,
Thanks for your response...
I confess I did not read the whole documentation from scratch, but I
have browsed many sections especially related with my issue. I should
say it is always said in documentation that setting $CROSS_COMPILE
environment variable is necessary, but that did not work for me.
Specifically, I am trying to cross compile osip library with EDLK (not
an ELDK component). When I execute the configure script I want the
config.h to be generated to reflect the target system. As from your
last response I understand that I always need to make sure by checking
config.h file myself.
After I have posted this problem I found the below thread:
http://ozlabs.org/pipermail/linuxppc-embedded/2003-July/011785.html
Following the same, I have achieved generation of config.h by checking
ELDK components and GNU cross tools to be prefixed with ppc_8xx.
Although I was not able to build shared libraries with the generated
makefile, building static libraries was OK. But it seems as if it is
somehow difficult to cross build a SW component that is not a part of
ELDK, and this is harder than "Rebuilding ELDK Components" which is
specified to be so straightforward in the documentation.
Thanks and regards...
On 9/19/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <4e5a3720709180602g20ccc060hbf7f091839a18c99@mail.gmail.com> you wrote:
> >
> > I want to cross compile a free software library with ELDK 3.1.1 for
> > powerpc. I have ELDK installed under directory /opt and my system and
> > PATH is set properly. I have a few points to be clarified:
>
> May I recommend that, as a first step, you read the documentation?
>
> > - For a cross compilation with ELDK how can we be sure that config.h
> > file for a software packet is generated properly? I mean, how can we
>
> You cannot be sure. You will always have to check.
>
> > be sure that ELDK components is checked instead of our host linux
> > system for generating a config.h file by the configure script?
>
> RTFM. See especially the two bullets at
> http://www.denx.de/wiki/view/DULG/ELDKRebuildingComponents#Section_3.7.2.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> Wisdom is one of the few things that looks bigger the further away it
> is. - Terry Pratchett, _Witches Abroad_
>
--
M u r at A r t u n, MSc.
Design Engineer
"be conservative in what you do, be liberal in what you accept from others"
^ permalink raw reply
* Re: Where did the fs_enet patches go?
From: Esben Haabendal @ 2007-09-19 8:25 UTC (permalink / raw)
To: Vitaly Bordug, Scott Wood; +Cc: LinuxPPC-dev
In-Reply-To: <20070919114035.075acafb@localhost.localdomain>
On Wed, 19 Sep 2007 11:40:35 +0400, Vitaly Bordug <vitb@kernel.crashing.org> wrote:
> On Wed, 19 Sep 2007 09:05:16 +0200
>> Where did the patches containing the reworked fs_enet drivers and the
>> generic bitbanged MDIO library go?
>> I am talking about these 8 patches:
>> http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg03184.html
>>
>> They seem to have been removed from
>> http://patchwork.ozlabs.org/linuxppc/ ...
>>
>> AFAICS, they have not been merged in neither galak or paulus git.
>>
>> It works nicely here at my mpc8270 target btw. :-)
>>
> iirc they are slowly spinning with netdev/Jeff Garzik... Scott would know
> for sure :)
Ah, I see. Thanks.
Most of it is at least ack'ed by Jeff. But he did not seem to like
the generic bitbanged MDIO library.
Scott, what is the plan with that part? I need it :-)
/Esben
--
Esben Haabendal
Embedded Software Consultant
Doré Development ApS
^ permalink raw reply
* Re: Where did the fs_enet patches go?
From: Vitaly Bordug @ 2007-09-19 7:40 UTC (permalink / raw)
To: Esben Haabendal; +Cc: LinuxPPC-dev
In-Reply-To: <fe1de3834843c215554ca03da0bc7eb3@127.0.0.1>
Hello Esben,
On Wed, 19 Sep 2007 09:05:16 +0200
Esben Haabendal wrote:
>
> Hi
>
> Where did the patches containing the reworked fs_enet drivers and the generic bitbanged MDIO library go?
> I am talking about these 8 patches: http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg03184.html
>
> They seem to have been removed from http://patchwork.ozlabs.org/linuxppc/ ...
>
> AFAICS, they have not been merged in neither galak or paulus git.
>
> It works nicely here at my mpc8270 target btw. :-)
>
iirc they are slowly spinning with netdev/Jeff Garzik... Scott would know for sure :)
--
Sincerely, Vitaly
^ permalink raw reply
* Re: PSC in UART mode on TQM5200S
From: Leopold Stotch @ 2007-09-19 7:40 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20070918223857.11329247FE@gemini.denx.de>
Thank you for the answer, Wolfgang !
Yes, we made a custom board which implements UART's
instead of USB, keyboard, mouse and others...
I checked the baudrate and i think it's ok.
Can you tell me, please, is there any HOWTO about MPC5200's
PSC's reconfiguration or something for newbies ?
On 9/19/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <53b5d6e90709180313n7ef053ddqfb771f44d9bd44ef@mail.gmail.com> you wrote:
> >
> > So changed $HOME/linuxppc_2_4_devel/arch/ppc/platforms/tqm5200.h
> > the following way:
>
> Well, you have to unserstand *exactly* what the CPU and the board are
> doing - the MPC5200 has multiplexed pins, and if you select one
> function you lose a few others, so you must carefully check for
> conflicts. Probably you will have to disable some other functions.
> Also you have to usnerstand what the board is designed like - some
> ports have specific and reserved functions.
>
> Finally, there are such things like wrong baud rate on a serial port
> which may make you think it's not working while you are just using bad
> user mode settings.
>
> > Is it possible to reconfigure all PSC's as UART's ?
>
> Yes, it is. But you have to know what you are doing.
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> All a hacker needs is a tight PUSHJ, a loose pair of UUOs, and a warm
> place to shift.
>
--
Best regards,
Leopold Stotch
^ permalink raw reply
* cuImage generation
From: Gerhard Pircher @ 2007-09-19 7:28 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I tried to compile a 2.6.23-rc6 kernel yesterday, but wasn't able to get a
cuImage.<platform) out of it (only the uImage file was generated). My
platform config defines DEFAULT_UIMAGE and WANT_DEVICE_TREE. Do I need to
generate it manually or is there a makefile where I have to specify it?
Naturally I added my cuboot wrapper code to the arch/powerpc/boot/Makefile.
Thanks!
regards,
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: [NEWBIE] Interrupt-problem mpc5200
From: S. Fricke @ 2007-09-19 7:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fa686aa40709121229h6bb2902etffcd197e2e5af722@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]
Hello,
> > Can u give me an example with a single IRQ of a configuration-node for a
> > dts?
>
> myreallycooldevice@0 {
> interrupts = <1 2 3>;
> interrupt-parent = <&mpc5200_pic>;
> };
Ahh - oh weh - so simple! Thank you!
> The interrupts property matches the size of the #interrupt-cells
> property in the interrupt controller node. For the 5200-intc, each
> interrupt is described by 3 cells; l1, l2 and sense which is a
> reflection of the interrupt controller architecture. For IRQ0, l1=0,
> l2=0; IRQ1, l1=1, l2=1; IRQ2, l1=1 and l2=2; IRQ3, l1=1, l2=3 Sense is
> described in mpc52xx-device-tree-bindings.txt
OK, my dts is now:
/ {
/* ... */
soc5200@f0000000 {
/* ... */
intpin@0 {
interrupt-parent = <500>;
interrupts = <1 2 2>;
};
/* ... */
};
/* ... */
};
And the corresponding code is:
struct intmod_priv {
/** Interrupt-Number */
int own_irq;
/** The of-device-node */
struct device_node *intmod_dev_node;
};
static int __init mod_init( void )
{
// ...
priv.intmod_dev_node = NULL;
priv.intmod_dev_node = of_find_node_by_name(NULL, "intpin");
priv.own_irq = irq_of_parse_and_map(priv.intmod_dev_node, 0);
request_irq(priv.own_irq, intmod_isr, IRQF_DISABLED , "intmod", INTMOD_IRQ_BOARD);
// ...
Thank you and bye, my next question is following :-)
Silvio Fricke
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Where did the fs_enet patches go?
From: Esben Haabendal @ 2007-09-19 7:05 UTC (permalink / raw)
To: LinuxPPC-dev
Hi
Where did the patches containing the reworked fs_enet drivers and the generic bitbanged MDIO library go?
I am talking about these 8 patches: http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg03184.html
They seem to have been removed from http://patchwork.ozlabs.org/linuxppc/ ...
AFAICS, they have not been merged in neither galak or paulus git.
It works nicely here at my mpc8270 target btw. :-)
--
Esben Haabendal
Embedded Software Consultant
Doré Development ApS
^ permalink raw reply
* Re: PSC in UART mode on TQM5200S
From: Leopold Stotch @ 2007-09-19 7:04 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40709180701w17273a11wda8c9ece79aad483@mail.gmail.com>
Thank you for the answer, Grant !
I knew nothing about port_config register before your answer :-(
I haven't changed any processor registers yet
because i'm still searching where i can do this.
Can you tell me, is it UBoot specific or kernel specific or both ?
And i already know about MPC5200's device tree in 2.6.x kernel but not
in 2.4.x...
On 9/18/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 9/18/07, Leopold Stotch <l.butterz@gmail.com> wrote:
> > Hello, everyone !
> >
> > I have TQM5200S module and development board.
> > It runs factory UBoot and latest DENX's linuxppc_2_4_devel kernel.
> > I want to configure all TQM5200S's onboard PSC's as UART's.
> > TQM5200S's onboard PSC's are connected to custom board
> > that makes all electrical things as my hardware engineer says...
> > So changed
> > $HOME/linuxppc_2_4_devel/arch/ppc/platforms/tqm5200.h
> > the following way:
> >
> > #ifdef CONFIG_PS2MULT
> > #define RS_TABLE_SIZE 4
> > #else
> > #if defined(CONFIG_SPI_EVAL) || defined(CONFIG_TB5200)
> > #define RS_TABLE_SIZE 2
> > #elif defined(CONFIG_CAM5200)
> > #define RS_TABLE_SIZE 6
> > #else
> > #define RS_TABLE_SIZE 3
> > #endif
> > #endif
> >
> > changed to
> >
> > #ifdef CONFIG_PS2MULT
> > #define RS_TABLE_SIZE 4
> > #else
> > #if defined(CONFIG_SPI_EVAL) || defined(CONFIG_TB5200)
> > #define RS_TABLE_SIZE 2
> > #elif defined(CONFIG_CAM5200)
> > #define RS_TABLE_SIZE 6
> > #else
> > #define RS_TABLE_SIZE 6
> > #endif
> > #endif
> >
> > and
> >
> > #else /* default */
> > #define SERIAL_PORT_DFNS \
> > STD_PSC_OP(1) \
> > STD_PSC_OP(2) \
> > STD_PSC_OP(3)
> > #endif
> >
> > changed to
> >
> > #else /* default */
> > #define SERIAL_PORT_DFNS \
> > STD_PSC_OP(1) \
> > STD_PSC_OP(2) \
> > STD_PSC_OP(3) \
> > STD_PSC_OP(4) \
> > STD_PSC_OP(5) \
> > STD_PSC_OP(6)
> > #endif
> >
> > After rebuilding the kernel, dmesg says:
> >
> > ...
> > ttyS0 on PSC1
> > ttyS1 on PSC2
> > ttyS2 on PSC3
> > ttyS3 on PSC4
> > ttyS4 on PSC5
> > ttyS5 on PSC6
> > ...
> >
> > But when i do "echo 1 > /dev/ttyS4" i receive nothing at the other end.
>
> Have you made the appropriate changes to the port_config register?
>
> Cheers,
> g.
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
--
Best regards,
Leopold Stotch
^ 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