* Re: patches for 2.6.25
From: Jochen Friedrich @ 2008-01-21 17:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801211041100.14676@blarg.am.freescale.net>
Hi Kumar,
> I'm sure I missed some patches for 2.6.25, so please point any out that
> people would like to see get in.
What about this one, now that the fixed phy parts are in:
http://patchwork.ozlabs.org/linuxppc/patch?person=1023&id=15654
Thanks,
Jochen
^ permalink raw reply
* Re: Generated xilinx linux 2.6 image sections
From: Grant Likely @ 2008-01-21 17:16 UTC (permalink / raw)
To: greenlean; +Cc: linuxppc-embedded
In-Reply-To: <14997109.post@talk.nabble.com>
On 1/21/08, greenlean <jmgomez@atc.ugr.es> wrote:
>
> Hi all,
>
> I'm trying to boot the 2.6 xilinx kernel downloaded from their git server in
> the XUPV2P board I'm really having troubles (I can't see anything in the
> minicom console terminal). I'm not seeing anything, neither the ucompressing
> kernel string nor the prompt with the memory addresses that kernel prompt at
> first time, so I have started to distrust of anything.
>
> When I download the kernel using xmd, I see:
>
> XMD% dow imagen_UART16550_ml300.elf
> section, .text: 0x00400000-0x0040387b
> section, .data: 0x00404000-0x004e6fff
> section, .bss: 0x004e7000-0x004e919f
> Downloaded Program imagen_UART16550_ml300.elf
> Setting PC with Program Start Address 0x00400000
>
<snip>
> I suppossed this is because the image kernel is compressed, but despite
> beeing compressed it should have a boot section or something similar ???
> It's right that the kernel start address is set to the 0x00400000??
>
> Or does the section .text contains all the kernel code to uncompresse the
> code of the kernel??
Yes; what you're seeing is the sections for the boot wrapper; not for
the kernel itself. The bootwrapper carries a compressed kernel image
as it's payload (notice how large the .data section is?). To see the
sections on the kernel proper, use readelf on the vmlinux file in the
kernel tree.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
From: Grant Likely @ 2008-01-21 17:11 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, dbrownell, linux-usb
In-Reply-To: <20080121103434.397382000@sunsite.dk>
On 1/21/08, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
> USB controllers. This patch series implements a HCD driver and shows the
> work-in-progress status of a gadget driver.
>
> I believe patch 1..3 are ready, and I would like to see queued up for 2.6.25.
>
> Changes since v3:
> - Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, ..
> - The dummy platform_device's created per serial engine are gone.
> - Gadget driver (WIP)
Can you please post/publish the diff between v3 and this series?
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [MPC5200] problem running FEC and ATA
From: Juergen Beisert @ 2008-01-21 16:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mehlan, Markus (Ritter Elektronik)
In-Reply-To: <FACFFB02D783C64FB2CEF2D6825F6FC206EEF1C0@SRVEXC01.sts.saurer.vpn>
On Monday 21 January 2008 14:01, Mehlan, Markus (Ritter Elektronik) wrote:
> > -----Urspr=FCngliche Nachricht-----
> > Von: Juergen Beisert [mailto:jbe@pengutronix.de]
> > Gesendet: Montag, 21. Januar 2008 09:58
> > An: linuxppc-dev@ozlabs.org
> > Cc: Mehlan, Markus (Ritter Elektronik)
> > Betreff: Re: [MPC5200] problem running FEC and ATA
> >
> > Markus,
> >
> > On Monday 21 January 2008 08:10, Mehlan, Markus (Ritter
> >
> > Elektronik) wrote:
> > > i have the same problem with the fec driver. See my posting at
> >
> > http://ozlabs.org/pipermail/linuxppc-embedded/2008-January/029466.html
> >
> > > Arnon, have you already fixed the FEC problem?
> >
> > Can you check this?
> >
> > http://ozlabs.org/pipermail/linuxppc-embedded/2007-May/027046.html
>
> I have checked the article. To set the BSDIS bit in the XLB config regist=
er
> during initialization fixes my problem:
>
> xlb =3D (struct mpc52xx_xlb *)MPC5xxx_XLB;
> out_be32(&xlb->config, in_be32(&xlb->config) |
> MPC52xx_XLB_CFG_BSDIS);
Is anybody out there with more MPC5200B experience? Can someone tell me why=
=20
some MPC5200B are need this patch and others not? We have two different=20
systems here (cards from different vendors) with the same processor, one=20
needs this BSDIS-patch and the other not. ???????????????
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
* Re: Endian problem when accessing internel regs on 8347
From: Scott Wood @ 2008-01-21 16:40 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-embedded
In-Reply-To: <OFE90E4633.93F2906B-ON882573D7.002448B6-882573D7.00287256@selinc.com>
On Sun, Jan 20, 2008 at 11:21:48PM -0800, Bruce_Leonard@selinc.com wrote:
> Okay, after much digging and experimenting, I'll agree that the memory
> operand makes sense. When I first said that I was thinking of direct
> manipulation of memory, which the PPC doesn't support. (Don't ask, my
> brain sometimes goes off into la-la land without me :-> ) Also, update
> mode is applicable and makes sense. But I do still have a problem with
> the index mode, though it could be compiler magic. Here's why: the index
> mode of the 'lwz' instruction requires three operands, i.e., 'lwzx
> rD,rA,rB', and there's only place holders for two operands. Is the
> compiler smart enough to add the third operand for the index mode? If so,
> what does it put for the third operand?
When the compiler decides to use index mode, the second "operand" is a
string containing "rX, rY", just as when it decides not to, the second
operand is a string containing "offset(rX)".
> Another question is how does the compiler know which mode to pick?
The same way it decides which mode to use for internally generated loads
and stores. Compiler optimization implementation is beyond the scope of
this list. :-)
> And what is the significance of the trailing number? Some places in
> the code have %U1%X1 and others have %U2%X2? I've found documentation
> for the # and ## tokens, but I can't find anything for the %U or %X
> tokens.
The number is an index into the operand list at the end of the asm
statement.
> Now this has all been very interesting to learn but doesn't solve my
> underlying problem which I've finally drilled down to. At first I thought
> in_be32() might be broken because I wasn't getting back the value I knew
> to be in the internal register. I knew I had the address and the mapping
> to kernel space correct because I could use in_le32 and get the right
> value though it was byte swapped.
Are you absolutely sure that in_le32 to in_be32 is the only thing that
changed? If you change it back now, does it resume returning a byte-swap
of the correct value?
If that is indeed what is making the difference, then perhaps it's some
subtle timing (or memory corruption) difference caused by different code
generation because the compiler is forced to use index mode for in_le32
(though it appears that the same operand list is given to GCC in either
case -- is GCC smart enough to optimize away preperation of inputs that
aren't actually referenced in the asm statement?). Is there any
difference in the generated assembly besides the specific load
instruction used?
Alternatively, maybe your chip is just fried. :-)
> I don't want to just arbitrarily point to that %U1%X1 parameter list,
So please don't.
> but I get compiler errors if I try to remove them
That's why it's there. :-)
> Can't anyone suggest anything I can try?
Beer.
-Scott
^ permalink raw reply
* Re: [PATCH 2/3] i2c: Convert all new-style drivers to use module aliasing
From: Jon Smirl @ 2008-01-21 16:50 UTC (permalink / raw)
To: Jean Delvare; +Cc: David Brownell, linuxppc-dev, Linux I2C
In-Reply-To: <20080121114139.3aaa111a@hyperion.delvare>
In my version of these patches new style drivers could be loaded with
both the driver_name/name scheme and the modalias. In these patches
new style drivers can only be loaded via modalias. Is that what you
intended? I'm all for making new style driver only use the modalias
scheme.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* patches for 2.6.25
From: Kumar Gala @ 2008-01-21 16:43 UTC (permalink / raw)
To: linuxppc-dev
I'm sure I missed some patches for 2.6.25, so please point any out that
people would like to see get in.
- k
^ permalink raw reply
* Please pull from 'for-2.6.25' branch
From: Kumar Gala @ 2008-01-21 16:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25
to receive the following updates:
Documentation/powerpc/00-INDEX | 3
Documentation/powerpc/booting-without-of.txt | 91 +
Documentation/powerpc/qe_firmware.txt | 295 ++++
arch/powerpc/Kconfig | 3
arch/powerpc/boot/.gitignore | 1
arch/powerpc/boot/Makefile | 7
arch/powerpc/boot/cuboot-83xx.c | 3
arch/powerpc/boot/cuboot-85xx.c | 5
arch/powerpc/boot/devtree.c | 14
arch/powerpc/boot/dts/adder875-redboot.dts | 184 ++
arch/powerpc/boot/dts/adder875-uboot.dts | 183 ++
arch/powerpc/boot/dts/ep8248e.dts | 207 +++
arch/powerpc/boot/dts/mpc8313erdb.dts | 49
arch/powerpc/boot/dts/mpc832x_mds.dts | 51
arch/powerpc/boot/dts/mpc8349emitx.dts | 30
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 1
arch/powerpc/boot/dts/mpc834x_mds.dts | 2
arch/powerpc/boot/dts/mpc836x_mds.dts | 1
arch/powerpc/boot/dts/mpc8377_mds.dts | 279 ++++
arch/powerpc/boot/dts/mpc8378_mds.dts | 265 ++++
arch/powerpc/boot/dts/mpc8379_mds.dts | 293 ++++
arch/powerpc/boot/dts/mpc8544ds.dts | 6
arch/powerpc/boot/dts/mpc8572ds.dts | 7
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 113 +
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 6
arch/powerpc/boot/ep8248e.c | 55
arch/powerpc/boot/ops.h | 14
arch/powerpc/boot/redboot-8xx.c | 58
arch/powerpc/boot/redboot.h | 56
arch/powerpc/boot/wrapper | 2
arch/powerpc/configs/adder875-redboot_defconfig | 798 ++++++++++++
arch/powerpc/configs/adder875-uboot_defconfig | 798 ++++++++++++
arch/powerpc/configs/ep8248e_defconfig | 821 +++++++++++++
arch/powerpc/configs/mpc8313_rdb_defconfig | 46
arch/powerpc/configs/mpc834x_itx_defconfig | 3
arch/powerpc/configs/mpc8610_hpcd_defconfig | 171 ++
arch/powerpc/kernel/head_fsl_booke.S | 20
arch/powerpc/kernel/pci-common.c | 8
arch/powerpc/kernel/pci_32.c | 58
arch/powerpc/math-emu/op-4.h | 40
arch/powerpc/mm/fsl_booke_mmu.c | 6
arch/powerpc/mm/lmb.c | 13
arch/powerpc/mm/mem.c | 20
arch/powerpc/platforms/82xx/Kconfig | 13
arch/powerpc/platforms/82xx/Makefile | 1
arch/powerpc/platforms/82xx/ep8248e.c | 324 +++++
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 13
arch/powerpc/platforms/83xx/mpc832x_mds.c | 5
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 10
arch/powerpc/platforms/83xx/mpc834x_itx.c | 12
arch/powerpc/platforms/83xx/mpc834x_mds.c | 5
arch/powerpc/platforms/83xx/mpc836x_mds.c | 5
arch/powerpc/platforms/83xx/mpc837x_mds.c | 56
arch/powerpc/platforms/83xx/mpc83xx.h | 3
arch/powerpc/platforms/83xx/usb.c | 46
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 18
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 7
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 15
arch/powerpc/platforms/8xx/Kconfig | 9
arch/powerpc/platforms/8xx/Makefile | 1
arch/powerpc/platforms/8xx/adder875.c | 118 +
arch/powerpc/platforms/Kconfig | 6
arch/powerpc/sysdev/Makefile | 2
arch/powerpc/sysdev/fsl_pci.c | 139 --
arch/powerpc/sysdev/fsl_soc.c | 103 +
arch/powerpc/sysdev/ipic.c | 62
arch/powerpc/sysdev/mpic.c | 4
arch/powerpc/sysdev/qe_lib/Kconfig | 2
arch/powerpc/sysdev/qe_lib/qe.c | 247 +++
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 10
drivers/net/phy/Kconfig | 32
drivers/net/phy/fixed.c | 445 ++-----
drivers/serial/Kconfig | 10
drivers/serial/Makefile | 1
drivers/serial/ucc_uart.c | 1514 ++++++++++++++++++++++++
include/asm-powerpc/immap_qe.h | 34
include/asm-powerpc/lmb.h | 1
include/asm-powerpc/mpc8260.h | 1
include/asm-powerpc/pci-bridge.h | 3
include/asm-powerpc/qe.h | 61
include/linux/phy_fixed.h | 51
82 files changed, 7840 insertions(+), 641 deletions(-)
Anton Vorontsov (1):
[POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
Becky Bruce (1):
[POWERPC] Fixup use of phys_addr_t in mpic code
Dale Farnsworth (1):
[POWERPC] 85xx: Respect KERNELBASE, PAGE_OFFSET, and PHYSICAL_START on e500
John Rigby (2):
[POWERPC] Add support for mpc512x interrupts to ipic
[POWERPC] Add IPIC Kconfig option
Kumar Gala (10):
[POWERPC] Fix handling of memreserve if the range lands in highmem
[POWERPC] Ensure we only handle PowerMac PCI bus fixup for memory resources
[POWERPC] Fixup transparent P2P resources
[POWERPC] FSL: Rework PCI/PCIe support for 85xx/86xx
[POWERPC] Remove update_bridge_resource
[POWERPC] 85xx: convert boards to use machine_device_initcall
[POWERPC] 83xx: convert boards to use machine_device_initcall
[POWERPC] bootwrapper: Add find_node_by_alias and dt_fixup_mac_address_by_alias
[POWERPC] bootwrapper: convert cuboot-8{3,5}xx to dt_fixup_mac_address_by_alias
[POWERPC] Fix incorrect interrupt map on FSL reference boards
Li Yang (3):
[POWERPC] 83xx: add device trees for MPC837x MDS board
[POWERPC] 83xx: Add MPC837x USB platform support
[POWERPC] 83xx: USB device tree cleanups
Liu Yu (1):
[POWERPC] Fix carry bug in 128-bit unsigned integer adding
Paul Gortmaker (1):
[POWERPC] 85xx: mpc85xx_ads: add in missing of_node_put()
Scott Wood (6):
[POWERPC] fsl_soc: Fix get_immrbase() to use ranges, rather than reg.
[POWERPC] 8xx: Analogue & Micro Adder875 board support.
[POWERPC] 82xx: Embedded Planet EP8248E support
[POWERPC] 83xx: MPC8313e RBD add NAND to device tree
[POWERPC] 83xx: MPC8313e RDB - Add NOR flash to the device tree.
[POWERPC] 83xx: Update MPC8313e RDB defconfig for MTD, NAND, JFFS2.
Timur Tabi (4):
[POWERPC] QE: Add ability to upload QE firmware
[POWERPC] QE: Add support for Freescale QUICCEngine UART
[POWERPC] qe-uart: add support for Freescale QUICCEngine UART
[POWERPC] Update MPC8610 HPCD to support audio drivers
Vitaly Bordug (3):
phy/fixed.c: rework to not duplicate PHY layer functionality
[POWERPC] MPC8349E-mITX: Vitesse 7385 PHY is not connected to the MDIO bus
[POWERPC] fsl_soc: add support to gianfar for fixed-link property
^ permalink raw reply
* Re: [PATCH 2/3] mpc8313erdb: Add NOR flash to the device tree.
From: Kumar Gala @ 2008-01-21 16:22 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080117223755.GB20697@loki.buserror.net>
On Thu, 17 Jan 2008, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8313erdb.dts | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
applied.
- k
^ permalink raw reply
* Re: [PATCH 3/3] Update mpc8313erdb defconfig for MTD, NAND, JFFS2.
From: Kumar Gala @ 2008-01-21 16:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080117223811.GC20697@loki.buserror.net>
On Thu, 17 Jan 2008, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/configs/mpc8313_rdb_defconfig | 46 ++++++++++++++++++++--------
> 1 files changed, 33 insertions(+), 13 deletions(-)
>
applied.
- k
^ permalink raw reply
* Re: [PATCH 2/2] mpc82xx: Embedded Planet EP8248E support
From: Kumar Gala @ 2008-01-21 16:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080117223205.GB17300@loki.buserror.net>
On Thu, 17 Jan 2008, Scott Wood wrote:
> This board is also resold by Freescale under the names
> "QUICCStart MPC8248 Evaluation System" and "CWH-PPC-8248N-VE".
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Removed const/initdata combo, and used simple-bus for probing.
>
> Please apply for 2.6.25.
>
> arch/powerpc/boot/Makefile | 3 +-
> arch/powerpc/boot/dts/ep8248e.dts | 207 ++++++++
> arch/powerpc/boot/ep8248e.c | 55 +++
> arch/powerpc/boot/wrapper | 2 +-
> arch/powerpc/configs/ep8248e_defconfig | 821 ++++++++++++++++++++++++++++++++
> arch/powerpc/platforms/82xx/Kconfig | 13 +
> arch/powerpc/platforms/82xx/Makefile | 1 +
> arch/powerpc/platforms/82xx/ep8248e.c | 324 +++++++++++++
> include/asm-powerpc/mpc8260.h | 1 +
> 9 files changed, 1425 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/ep8248e.dts
> create mode 100644 arch/powerpc/boot/ep8248e.c
> create mode 100644 arch/powerpc/configs/ep8248e_defconfig
> create mode 100644 arch/powerpc/platforms/82xx/ep8248e.c
>
applied.
- k
^ permalink raw reply
* Re: [PATCH 1/3] mpc8313erdb: Add NAND to device tree, and call of_platform_bus_probe().
From: Kumar Gala @ 2008-01-21 16:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080117223750.GA20697@loki.buserror.net>
On Thu, 17 Jan 2008, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Please apply this series for 2.6.25.
>
> arch/powerpc/boot/dts/mpc8313erdb.dts | 39 +++++++++++++++++++++++++++++
> arch/powerpc/platforms/83xx/mpc8313_rdb.c | 13 +++++++++
> 2 files changed, 52 insertions(+), 0 deletions(-)
>
applied.
- k
^ permalink raw reply
* Re: [PATCH 1/2] 8xx: Analogue & Micro Adder875 board support.
From: Kumar Gala @ 2008-01-21 16:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080117223140.GA17300@loki.buserror.net>
On Thu, 17 Jan 2008, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Removed const/initdata combo, added simple-bus to cpm node,
> and used simple-bus for probing.
>
> Please apply for 2.6.25.
>
> arch/powerpc/Kconfig | 3 +
> arch/powerpc/boot/.gitignore | 1 +
> arch/powerpc/boot/Makefile | 6 +-
> arch/powerpc/boot/dts/adder875-redboot.dts | 184 ++++++
> arch/powerpc/boot/dts/adder875-uboot.dts | 183 ++++++
> arch/powerpc/boot/redboot-8xx.c | 58 ++
> arch/powerpc/boot/redboot.h | 56 ++
> arch/powerpc/boot/wrapper | 2 +-
> arch/powerpc/configs/adder875-redboot_defconfig | 798 +++++++++++++++++++++++
> arch/powerpc/configs/adder875-uboot_defconfig | 798 +++++++++++++++++++++++
> arch/powerpc/platforms/8xx/Kconfig | 9 +
> arch/powerpc/platforms/8xx/Makefile | 1 +
> arch/powerpc/platforms/8xx/adder875.c | 118 ++++
> 13 files changed, 2215 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/adder875-redboot.dts
> create mode 100644 arch/powerpc/boot/dts/adder875-uboot.dts
> create mode 100644 arch/powerpc/boot/redboot-8xx.c
> create mode 100644 arch/powerpc/boot/redboot.h
> create mode 100644 arch/powerpc/configs/adder875-redboot_defconfig
> create mode 100644 arch/powerpc/configs/adder875-uboot_defconfig
> create mode 100644 arch/powerpc/platforms/8xx/adder875.c
>
applied.
- k
^ permalink raw reply
* Re: [PATCH 05/10] powerpc: Add crash kernel support for 85xx
From: Kumar Gala @ 2008-01-21 16:19 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20071122154619.GA26471@xyzzy.farnsworth.org>
On Thu, 22 Nov 2007, Dale Farnsworth wrote:
> Add the ability to build a ppc_85xx kernel to run at a physical
> address of 32MB.
>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> ---
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/kernel/head_fsl_booke.S | 23 ++++++++++++++++++-----
> arch/powerpc/mm/fsl_booke_mmu.c | 6 +++---
> 3 files changed, 22 insertions(+), 9 deletions(-)
>
applied. (w/o Kconfig since this is useful for other purposes).
-k
^ permalink raw reply
* Re: [i2c] [PATCH 19 3/5] Clean up error returns
From: Jean Delvare @ 2008-01-21 16:10 UTC (permalink / raw)
To: Jon Smirl; +Cc: i2c, linux-kernel, linuxppc-dev
In-Reply-To: <9e4733910801200739x502d5407x85f0d950ace80bee@mail.gmail.com>
Hi Jon,
On Sun, 20 Jan 2008 10:39:43 -0500, Jon Smirl wrote:
> Here' s a version with the compares to zero switched to NO_IRQ. If I
> understand how NO_IRQ works it is the correct change. My understanding
> is that under ppc IRQ zero was legal and NO_IRQ was -1. But then the
> whole kernel switched to NO_IRQ = zero. Powerpc updated to NO_IRQ=0
> and used virtual IRQs to move a physical IRQ 0 to another IRQ number.
> ppc was not changed. This driver does not appear to have been updated
> to track this global change since it didn't initially use the NO_IRQ
> define everywhere.
As I have already applied the part of this patch that preserves error
values in error paths, can you please send an incremental patch that
only fixes the IRQ issues? These are separate issues so it's better to
have separate patches anyway.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] autodetect serial console on efika
From: Andreas Schwab @ 2008-01-21 16:09 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Paul Mackeras
In-Reply-To: <20080121152900.GA8664@aepfle.de>
Olaf Hering <olaf@aepfle.de> writes:
> +/*
> + * Per default, input/output-device points to keyboard/screen
> + * If no card is installed, the built-in serial port is used as a fallback.
> + * But unfortunately, the firmware does not connect /chosen/{stdin,stdout}
> + * the the built-in serial node. Instead, a /failsafe node is created.
s/the the/to the/
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] autodetect serial console on efika
From: Geert Uytterhoeven @ 2008-01-21 15:56 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Paul Mackeras
In-Reply-To: <20080121152900.GA8664@aepfle.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 843 bytes --]
On Mon, 21 Jan 2008, Olaf Hering wrote:
> + * But unfortunately, the firmware does not connect /chosen/{stdin,stdout}
> + * the the built-in serial node. Instead, a /failsafe node is created.
^^^
to
The same typo is in the pegasos2 patch.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [PATCH] autodetect serial console on pegasos2
From: Olaf Hering @ 2008-01-21 15:37 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
In-Reply-To: <20080121152900.GA8664@aepfle.de>
Autodetect the serial console on Pegasos2.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
arch/powerpc/platforms/chrp/setup.c | 52 ++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
--- a/arch/powerpc/platforms/chrp/setup.c
+++ b/arch/powerpc/platforms/chrp/setup.c
@@ -251,6 +251,57 @@ static void briq_restart(char *cmd)
for(;;);
}
+/*
+ * Per default, input/output-device points to the keyboard/screen
+ * If no card is installed, the built-in serial port is used as a fallback.
+ * But unfortunately, the firmware does not connect /chosen/{stdin,stdout}
+ * the the built-in serial node. Instead, a /failsafe node is created.
+ */
+static void chrp_init_early(void)
+{
+ struct device_node *node;
+ const char *property;
+
+ if (strstr(cmd_line, "console="))
+ return;
+ /* find the boot console from /chosen/stdout */
+ if (!of_chosen)
+ return;
+ node = of_find_node_by_path("/");
+ if (!node)
+ return;
+ property = of_get_property(node, "model", NULL);
+ if (!property)
+ goto out_put;
+ if (strcmp(property, "Pegasos2"))
+ goto out_put;
+ /* this is a Pegasos2 */
+ property = of_get_property(of_chosen, "linux,stdout-path", NULL);
+ if (!property)
+ goto out_put;
+ of_node_put(node);
+ node = of_find_node_by_path(property);
+ if (!node)
+ return;
+ property = of_get_property(node, "device_type", NULL);
+ if (!property)
+ goto out_put;
+ if (strcmp(property, "serial"))
+ goto out_put;
+ /*
+ * The 9pin connector is either /failsafe
+ * or /pci@80000000/isa@C/serial@i2F8
+ * The optional graphics card has also type 'serial' in VGA mode.
+ */
+ property = of_get_property(node, "name", NULL);
+ if (!property)
+ goto out_put;
+ if (!strcmp(property, "failsafe") || !strcmp(property, "serial"))
+ add_preferred_console("ttyS", 0, NULL);
+out_put:
+ of_node_put(node);
+}
+
void __init chrp_setup_arch(void)
{
struct device_node *root = of_find_node_by_path("/");
@@ -594,6 +645,7 @@ define_machine(chrp) {
.probe = chrp_probe,
.setup_arch = chrp_setup_arch,
.init = chrp_init2,
+ .init_early = chrp_init_early,
.show_cpuinfo = chrp_show_cpuinfo,
.init_IRQ = chrp_init_IRQ,
.restart = rtas_restart,
^ permalink raw reply
* [PATCH] autodetect serial console on efika
From: Olaf Hering @ 2008-01-21 15:29 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
In-Reply-To: <20070331150823.GA25421@aepfle.de>
Efika boards have to be booted with console=ttyPSC0 unless there is a
graphics card plugged in. Detect if the firmware stdout is the serial
connector.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
arch/powerpc/platforms/52xx/efika.c | 50 ++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
--- a/arch/powerpc/platforms/52xx/efika.c
+++ b/arch/powerpc/platforms/52xx/efika.c
@@ -13,6 +13,7 @@
#include <linux/utsrelease.h>
#include <linux/pci.h>
#include <linux/of.h>
+#include <linux/console.h>
#include <asm/prom.h>
#include <asm/time.h>
#include <asm/machdep.h>
@@ -208,12 +209,61 @@ static int __init efika_probe(void)
return 1;
}
+/*
+ * Per default, input/output-device points to keyboard/screen
+ * If no card is installed, the built-in serial port is used as a fallback.
+ * But unfortunately, the firmware does not connect /chosen/{stdin,stdout}
+ * the the built-in serial node. Instead, a /failsafe node is created.
+ * More advanced hardware configurations cant be detected,
+ * boot with console=xyz123 to point the kernel to the correct device
+ */
+static void __init efika_init_early(void)
+{
+#ifdef CONFIG_SERIAL_MPC52xx
+ struct device_node *stdout_node;
+ const char *property;
+
+ if (strstr(cmd_line, "console="))
+ return;
+ /* find the boot console from /chosen/stdout */
+ if (!of_chosen)
+ return;
+ property = of_get_property(of_chosen, "linux,stdout-path", NULL);
+ if (!property)
+ return;
+ stdout_node = of_find_node_by_path(property);
+ if (!stdout_node)
+ return;
+ property = of_get_property(stdout_node, "device_type", NULL);
+ if (property && strcmp(property, "serial") == 0) {
+ /*
+ * The 9pin connector is either /failsafe or /builtin/serial.
+ * The optional graphics card has also type 'serial' in VGA mode.
+ */
+ property = of_get_property(stdout_node, "name", NULL);
+ if (property) {
+ if (strcmp(property, "failsafe") == 0)
+ add_preferred_console("ttyPSC", 0, NULL);
+ else {
+ if (strcmp(property, "serial") == 0) {
+ property = of_get_property(stdout_node, "model", NULL);
+ if (property && strcmp(property, "mpc5200-serial") == 0)
+ add_preferred_console("ttyPSC", 0, NULL);
+ }
+ }
+ }
+ }
+ of_node_put(stdout_node);
+#endif
+}
+
define_machine(efika)
{
.name = EFIKA_PLATFORM_NAME,
.probe = efika_probe,
.setup_arch = efika_setup_arch,
.init = mpc52xx_declare_of_platform_devices,
+ .init_early = efika_init_early,
.show_cpuinfo = efika_show_cpuinfo,
.init_IRQ = mpc52xx_init_irq,
.get_irq = mpc52xx_get_irq,
^ permalink raw reply
* Re: [PATCH 2/2] mpc82xx: Embedded Planet EP8248E support
From: Sergej Stepanov @ 2008-01-21 15:28 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080118160303.GC15620@ld0162-tx32.am.freescale.net>
Am Freitag, den 18.01.2008, 10:03 -0600 schrieb Scott Wood:
> On Fri, Jan 18, 2008 at 12:07:07PM +0100, Sergej Stepanov wrote:
> >
> > > + /* "Serial" port/SCC1 */
> > > + scc1: serial@11a00 {
> > > + device_type = "serial";
> > > + compatible = "fsl,mpc8248-scc-uart",
> > > + "fsl,cpm2-scc-uart";
> > > + reg = <0x11a00 0x20 0x8000 0x100>;
> > > + interrupts = <40 8>;
> > are you sure with 40 as interrupt? has not it be "28"(hex) here?
>
> This is a version 1 dts file -- the default base is decimal.
>
> -Scott
yes, you are right, sorry.
^ permalink raw reply
* Re: Endian problem when accessing internel regs on 8347
From: Ben Warren @ 2008-01-21 15:16 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: Scott Wood, linuxppc-embedded
In-Reply-To: <OFE90E4633.93F2906B-ON882573D7.002448B6-882573D7.00287256@selinc.com>
Hey Bruce,
Bruce_Leonard@selinc.com wrote:
>>>>> __asm__ __volatile__("lwz%U1%X1 %0,%1; twi 0,%0,0; isync" : "=r"
>>>>>
> (ret)
>
>>> :
>>>
>>>>> "m" (*addr));
>>>>>
>>>> They allow the compiler to use update and/or index mode for the
>>>>
> memory
>
>>>> operand.
>>>>
>>> Well that makes sense, U for update and X for index, but I'm not sure
>>> they're applicable to this particular instruction and I'm not sure
>>>
> that
>
>>> the memory operand makes sense for PowerPC.
>>>
>> Why not?
>>
>
> Okay, after much digging and experimenting, I'll agree that the memory
> operand makes sense. When I first said that I was thinking of direct
> manipulation of memory, which the PPC doesn't support. (Don't ask, my
> brain sometimes goes off into la-la land without me :-> ) Also, update
> mode is applicable and makes sense. But I do still have a problem with
> the index mode, though it could be compiler magic. Here's why: the index
> mode of the 'lwz' instruction requires three operands, i.e., 'lwzx
> rD,rA,rB', and there's only place holders for two operands. Is the
> compiler smart enough to add the third operand for the index mode? If so,
> what does it put for the third operand?
>
> Another question is how does the compiler know which mode to pick? And
> what is the significance of the trailing number? Some places in the code
> have %U1%X1 and others have %U2%X2? I've found documentation for the #
> and ## tokens, but I can't find anything for the %U or %X tokens.
>
> Now this has all been very interesting to learn but doesn't solve my
> underlying problem which I've finally drilled down to. At first I thought
> in_be32() might be broken because I wasn't getting back the value I knew
> to be in the internal register. I knew I had the address and the mapping
> to kernel space correct because I could use in_le32 and get the right
> value though it was byte swapped. The value in the register was
> 0xFFFFFFE7 but what I was getting from in_be32 was 0xFFFFFFFF. Then I
> started playing and here's what I found:
>
> Register value in_be32 value
> 0x12345678 0x1234567
> 0xff345678 0xff345678
> 0xffff5678 0xffff5678
> 0xfffff678 0xfffff678
> 0xfffffe78 0xffffffff
> 0xffffff78 0xffffffff
>
> This isn't an exhastive list but I tried about twenty values and pretty
> much what I found was that if bits 0 through 22 are set to 1 then in_be32
> reads 0xffffffff. I've also tried it at a variety of addresses and the
> behaviour is the same. in_le32 works fine as does in_be16. I've got no
> ideas as to what may be wrong. I don't want to just arbitrarily point to
> that %U1%X1 parameter list, but I get compiler errors if I try to remove
> them so I can't prove or disprove it and I can't find any documentation on
> it I can't even form a theroy. Has anyone ever seen anything like this?
> Can't anyone suggest anything I can try?
>
Are you sure that all the bits are configured as GPIO? Almost every
peripheral pin on these chips is muxed at least two ways. Maybe some of
the bits that you think are GPIO are configured as some other bus,
possibly explaining goofy behavior and perceived volatility of data.
This is pretty well-vetted code on a reasonably mature product, and in
my experience it's very rarely the tools ...
Just a thought.
regards,
Ben
^ permalink raw reply
* Re: Warp Watchdog
From: Josh Boyer @ 2008-01-21 14:01 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <478FB93A.7040505@pikatech.com>
On Thu, 17 Jan 2008 15:23:22 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> The taco, er warp, has a watchdog timer built into the fpga. The
> watchdog is very trivial and very tied to the warp. I have put it has
> part of the platform code rather than a standalone module.
>
> Two reasons for this: one, once started it can't be stopped. A module
> unload would be fatal ;) Two, it is so closely tied to the taco that it
> really has no use otherwise.
The first isn't much of a reason. The watchdog on the 44x and FSL
Book-E cores have the same behavior.
> The platform always starts the watchdog, assuming you asked for the
> watchdog, but does not enable it until hit from user mode.
>
> What is the general feeling about this implementation? I am not
> submitting this for inclusion in the kernel right now, just feeling out
> what others think.
I'm not thrilled with it being in the platform file itself. It should
really go into drivers/watchdog. It's OK that the watchdog is tied to
Warp, that really isn't an issue. Just make it depend on Warp in the
Kconfig file. And you can select it in your board config so that it's
built in-kernel and not as a module.
The code itself looks pretty clean.
josh
^ permalink raw reply
* Generated xilinx linux 2.6 image sections
From: greenlean @ 2008-01-21 13:05 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm trying to boot the 2.6 xilinx kernel downloaded from their git server in
the XUPV2P board I'm really having troubles (I can't see anything in the
minicom console terminal). I'm not seeing anything, neither the ucompressing
kernel string nor the prompt with the memory addresses that kernel prompt at
first time, so I have started to distrust of anything.
When I download the kernel using xmd, I see:
XMD% dow imagen_UART16550_ml300.elf
section, .text: 0x00400000-0x0040387b
section, .data: 0x00404000-0x004e6fff
section, .bss: 0x004e7000-0x004e919f
Downloaded Program imagen_UART16550_ml300.elf
Setting PC with Program Start Address 0x00400000
and when I download some of the TestApp generated by EDK I see:
XMD% dow perif.elf
section, .vectors: 0xfffe0000-0xfffe20c3
section, .text: 0x10000000-0x10003b7b
section, .init: 0x10003b7c-0x10003b9f
section, .fini: 0x10003ba0-0x10003bbf
section, .boot0: 0xfffe20c4-0xfffe20d3
section, .boot: 0xfffffffc-0xffffffff
section, .rodata: 0x10003bc0-0x10004111
section, .sdata2: 0x10004114-0x10004113
section, .sbss2: 0x10004114-0x10004113
section, .data: 0x10004114-0x10004243
section, .got: 0x10004244-0x10004243
section, .got1: 0x10004244-0x10004243
section, .got2: 0x10004244-0x1000425f
section, .ctors: 0x10004260-0x10004267
section, .dtors: 0x10004268-0x1000426f
section, .fixup: 0x10004270-0x1000426f
section, .eh_frame: 0x10004270-0x10004277
section, .jcr: 0x10004278-0x1000427b
section, .gcc_except_table: 0x1000427c-0x100042
section, .sdata: 0x1000427c-0x10004293
section, .sbss: 0x10004294-0x100042a3
section, .bss: 0x100042a4-0x10004473
section, .stack: 0x10004474-0x1000647f
section, .heap: 0x10006480-0x1000847f
Downloaded Program perif.elf
Setting PC with Program Start Address 0xfffffffc
Does anybody know why the kernel elf don't have a boot section like the
TestApp generated by EDK?
I suppossed this is because the image kernel is compressed, but despite
beeing compressed it should have a boot section or something similar ???
It's right that the kernel start address is set to the 0x00400000??
Or does the section .text contains all the kernel code to uncompresse the
code of the kernel??
--
View this message in context: http://www.nabble.com/Generated-xilinx-linux-2.6--image-sections-tp14997109p14997109.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [MPC5200] problem running FEC and ATA
From: Mehlan, Markus (Ritter Elektronik) @ 2008-01-21 13:01 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200801210957.57761.jbe@pengutronix.de>
Hello Juergen,
> -----Urspr=FCngliche Nachricht-----
> Von: Juergen Beisert [mailto:jbe@pengutronix.de]=20
> Gesendet: Montag, 21. Januar 2008 09:58
> An: linuxppc-dev@ozlabs.org
> Cc: Mehlan, Markus (Ritter Elektronik)
> Betreff: Re: [MPC5200] problem running FEC and ATA
>=20
> Markus,
>=20
> On Monday 21 January 2008 08:10, Mehlan, Markus (Ritter=20
> Elektronik) wrote:
> > i have the same problem with the fec driver. See my posting at=20
> >=20
> http://ozlabs.org/pipermail/linuxppc-embedded/2008-January/029466.html
> >
> > Arnon, have you already fixed the FEC problem?
>=20
> Can you check this?
>=20
> http://ozlabs.org/pipermail/linuxppc-embedded/2007-May/027046.html
I have checked the article. To set the BSDIS bit in the XLB config =
register
during initialization fixes my problem:
xlb =3D (struct mpc52xx_xlb *)MPC5xxx_XLB;
out_be32(&xlb->config, in_be32(&xlb->config) |
MPC52xx_XLB_CFG_BSDIS);
Thank you!
Best regards,
Markus
^ permalink raw reply
* Re: [i2c] [PATCH 0/3] i2c: Use the standard, alias-based device/driver matching scheme
From: Jean Delvare @ 2008-01-21 12:34 UTC (permalink / raw)
To: Rudolf Marek; +Cc: David Brownell, linuxppc-dev, Linux I2C
In-Reply-To: <479478C7.5060807@assembler.cz>
On Mon, 21 Jan 2008 11:49:43 +0100, Rudolf Marek wrote:
> > Note: all the arm and powerpc stuff is untested.
>
> We at http://sysgo.com have some demo server, where you can access embedded
> systems remotely (via VNC to a server with cross tools (ELinOS) + serial console),
> there is 2.6.22 kernel, but I think the i2c core can be replaced. I think some
> PPC and ARMs are connected there. I will ask if you can get access to it if you
> are interested.
Thanks for the proposal, but in general I think it makes more sense
that people who are familiar with these architectures test the patches
themselves. That's less work for me, and they'll do a better job anyway.
--
Jean Delvare
^ 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