* Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
From: Peter Tyser @ 2009-12-31 23:10 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, linux-kbuild
In-Reply-To: <20091231224439.AF5353F6D1@gemini.denx.de>
Hi Wolfgang,
> > IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
> > Makefile so that make behaves more consistently. Speaking of which,
> > the number of '.' in the name is getting rather large. Would you
> > consider using 'fitImage' instead of 'uImage.fit'?
>
> Why chose a different name at all? We could still call it "uImage",
> meaning "U-Boot image" - U-Boot is clever enought o detect
> automatically if we pass it an old style or a fit image.
I agree with your point to an extent, but having 2 types of uImages is
somewhat confusing to a user, even if U-Boot can differentiate between
them. And if the legacy image and FIT image had the same Make target,
how does a user specify which type they want to build? The fact that
both "legacy" and FIT images would reside at arch/powerpc/boot/uImage
doesn't make things any less confusing to Joe User.
Currently U-Boot supports booting:
1 "legacy" uImages
2 "new" Flattened Image Tree (FIT) uImages
What do you think about changing the U-Boot documentation to rename
those 2 image types to:
1 uImages
2 FIT Images
The FIT image is a relatively generic image type - its just a blob that
dtc created from a device tree and some input binaries. In my mind its
not intimately tied to U-Boot, at least not conceptually. The "legacy"
uImages have to agree with U-Boot's header format defined in the U-Boot
source code, so the uImage name does make sense with respect to the
"legacy" uImages.
My vote would be to make the Linux FIT target rule "fitImage" and then
update the U-Boot documentation to make obvious the differences between
uImages and FIT images.
What do you think of that?
Thanks,
Peter
^ permalink raw reply
* Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
From: Wolfgang Denk @ 2009-12-31 22:44 UTC (permalink / raw)
To: Grant Likely; +Cc: Peter Tyser, linux-kbuild, linuxppc-dev
In-Reply-To: <fa686aa40912301502x48785614ya4dd5c71815a7633@mail.gmail.com>
Dear Grant Likely,
In message <fa686aa40912301502x48785614ya4dd5c71815a7633@mail.gmail.com> you wrote:
>
> IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
> Makefile so that make behaves more consistently. Speaking of which,
> the number of '.' in the name is getting rather large. Would you
> consider using 'fitImage' instead of 'uImage.fit'?
Why chose a different name at all? We could still call it "uImage",
meaning "U-Boot image" - U-Boot is clever enought o detect
automatically if we pass it an old style or a fit image.
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
If the odds are a million to one against something occuring, chances
are 50-50 it will.
^ permalink raw reply
* [PATCH] POWERPC: Simplify param.h by including <asm-generic/param.h>
From: Robert P. J. Day @ 2009-12-31 20:45 UTC (permalink / raw)
To: Linux PPC Mailing List
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
---
diff --git a/arch/powerpc/include/asm/param.h b/arch/powerpc/include/asm/param.h
index 094f63d..965d454 100644
--- a/arch/powerpc/include/asm/param.h
+++ b/arch/powerpc/include/asm/param.h
@@ -1,22 +1 @@
-#ifndef _ASM_POWERPC_PARAM_H
-#define _ASM_POWERPC_PARAM_H
-
-#ifdef __KERNEL__
-#define HZ CONFIG_HZ /* internal kernel timer frequency */
-#define USER_HZ 100 /* for user interfaces in "ticks" */
-#define CLOCKS_PER_SEC (USER_HZ) /* frequency at which times() counts */
-#endif /* __KERNEL__ */
-
-#ifndef HZ
-#define HZ 100
-#endif
-
-#define EXEC_PAGESIZE 4096
-
-#ifndef NOGROUP
-#define NOGROUP (-1)
-#endif
-
-#define MAXHOSTNAMELEN 64 /* max length of hostname */
-
-#endif /* _ASM_POWERPC_PARAM_H */
+#include <asm-generic/param.h>
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
^ permalink raw reply related
* Re: Trouble specifying dts gpio-leds with GPIO expander chip
From: Bill Gatliff @ 2009-12-31 17:00 UTC (permalink / raw)
To: avorontsov; +Cc: Linux/PPC Development
In-Reply-To: <20091221215544.GA30974@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> Though, soon there will be an easier way to register I2C/SPI chips
> with the OF GPIO infrastructure.
>
Should this make me hesitate to update the pca953x driver, or clone it?
b.g.
--
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com
^ permalink raw reply
* Re: Question on MPC52xx IRQ[123] pins
From: Bill Gatliff @ 2009-12-31 14:34 UTC (permalink / raw)
To: Grant Likely; +Cc: Linux/PPC Development
In-Reply-To: <fa686aa40912211516u4a079693h74e39fd887cb421d@mail.gmail.com>
Grant Likely wrote:
> Correct. IRQ2 can only be used as IRQ2. It cannot be used a GPIO.
> (Well, I suppose you *could* try to hack into the interrupt controller
> driver and fetch the pin state that way; but I don't know if you can
> read the state of masked out IRQ pins, and it sure would be ugly.)
>
Actually, I did think of a way you could do this. You could register an
interrupt handler on the line, and set the irq type to level-low or
level-high. Depending on whether the handler fires right away, you know
what the state of the pin must be. And when the interrupt handler does
fire, you switch the irq type to the opposite setting.
I think that approach rates pretty high on the "ugly scale" too, but
perhaps tolerably so. In fact, were I to actually need to interface one
of the IRQ lines to gpiolib, I might attempt this...
b.g.
--
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com
^ permalink raw reply
* RE: [PATCH] arch/powerpc/boot/devtree.c: use %pM to show MAC address
From: H Hartley Sweeten @ 2009-12-31 14:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20091231044926.GC18358@brick.ozlabs.ibm.com>
On Wednesday, December 30, 2009 9:49 PM, Paul Mackerras wrote:
> On Wed, Dec 30, 2009 at 02:30:39PM -0500, H Hartley Sweeten wrote:
>
>> Use the %pM kernel extension to display the MAC address.
>>=20
>> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
>>=20
>> ---
>
> Nak - this isn't the kernel, this is a separate program, namely the
> bootwrapper that decompresses the kernel image, and it has its own
> printf (not printk) implementation in arch/powerpc/boot/stdio.c, which
> doesn't understand the %pX extensions (and I don't see any good reason
> to make it do so).
OK. Sorry for the noise.
Regards,
Hartley
^ permalink raw reply
* How to access PPC460EX SDRAM space from PCI/PCIe.
From: Lonsn @ 2009-12-31 8:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sr
Hi:
I'm now using canyonlands board with latest u-boot and linux kernel
from DENX git.
A PCIe card is plugged in the PCIeX4 slot. The PCIe card is a PCIe-pci
bridge(PI7C9X130) plus an Altera fpga.
The PCIe card act as a PCI master and send data to SDRAM of 460EX
space (total sdram 512MB, reserve 8M for PCI write data(0x1F800000)).
Now linux can identify this card, but CPU cann't receive any data from
PCIe and no PCIe interrupt.
I know about the PCI card works in 32bit mode and doesn't support
64bit address(No pci dual address cycle support).
Does the PCI card can access PPC460EX sdram space using just 32bit
physical address(0x1F800000)?
Best regards,
Lonsn
^ permalink raw reply
* Re: [HELP] BAD interrupts
From: Régis Odeyé @ 2009-12-31 8:12 UTC (permalink / raw)
To: Kumar Gopalpet-B05799; +Cc: gshan, avorontsov, linuxppc-dev, netdev
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81BA0905B@zin33exm22.fsl.freescale.net>
Hi,
We experimented something similar with a 8641D board.
This seems to come from the gianfar and:
- when we are binding the three interruptions enet_tx, enet_rx and
enet_err of each interfaces on the same processor, the BAD interruptions
do not increase any more.
- when we are compiling the driver without the NAPI mode, there is no
more BAD interruptions at all.
Hope it will help even if we did not find a real fix.
Regards.
Régis.
Kumar Gopalpet-B05799 wrote:
>
>
>
>> -----Original Message-----
>> From: gshan [mailto:gshan@alcatel-lucent.com]
>> Sent: Thursday, December 24, 2009 5:16 PM
>> To: michael@ellerman.id.au
>> Cc: Kumar Gopalpet-B05799; netdev@vger.kernel.org;
>> linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [HELP] BAD interrupts
>>
>> Michael Ellerman wrote:
>>
>>> On Wed, 2009-12-23 at 19:41 +0530, Kumar Gopalpet-B05799 wrote:
>>>
>>>
>>>> Hi all,
>>>>
>>>> I am trying linux 2.6.32-rc3 in SMP mode. I am seeing a lot of BAD
>>>> interrupts when I do a "cat /proc/interrupts".
>>>>
>>>> I am running a forwarding application b/w two ethernet ports
>>>> (ethernet uses gianfar driver).
>>>>
>>>> Has any one observed these BAD interrupts ? If so, can someone help
>>>> me in understanding why these interrupts come and how to
>>>>
>> resolve it ?
>>
>>>>
>>>>
>>> You'll need to tell us what platform you're running on.
>>>
>>> The BAD interrupts come from ppc_spurious_interrupts. It's a
>>>
>> count of
>>
>>> the number of times we entered do_IRQ() (ie. took an external
>>> interrupt), but when we asked the interrupt controller which irq it
>>> was, the interrupt controller said there was no irq.
>>>
>>> Depending on your interrupt controller that might happen
>>>
>> sometimes for
>>
>>> valid reasons. Or it might indicate something is setup wrong.
>>>
>>> cheers
>>>
>>>
>> I think it will help to show us your /proc/interrupts so that
>> how you suffered from bad interrupts.
>>
>>
>
> I am running linux-2.6.29 in SMP mode on P2020RDB ( ruuning at
> 1200/600/667). The test scenario forwarding
> application and is a bidirectioanl flow between eth0 & eth2.
>
> Attached is the complete log of the test scenario.
>
> I also noted another observation that when all the interrupts are mapped
> to a single core, the BAD interrupts stop coming.
>
> --
>
> Thanks
> Sandeep
>
>
> ------------------------------------------------------------------------
>
> tftp 1000000 etsec2/uImage_alpha
> Speed: 1000, full duplex
> Using eTSEC1 device
> TFTP from server 10.232.134.194; our IP address is 10.232.133.188
> Filename 'etsec2/uImage_alpha'.
> Load address: 0x1000000
> Loading: *\b#################################################################
> #################################################################
> ###################################################
> done
> Bytes transferred = 2654090 (287f8a hex)
> => tftp 2000000 etsec2/rf\b \bootfs_alpha
> Speed: 1000, full duplex
> Using eTSEC1 device
> TFTP from server 10.232.134.194; our IP address is 10.232.133.188
> Filename 'etsec2/rootfs_alpha'.
> Load address: 0x2000000
> Loading: *\b#################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #####
> done
> Bytes transferred = 26776875 (198952b hex)
> => tftp c00000 etsec2/p2020alpha.dtb
> Speed: 1000, full duplex
> Using eTSEC1 device
> TFTP from server 10.232.134.194; our IP address is 10.232.133.188
> Filename 'etsec2/p2020alpha.dtb'.
> Load address: 0xc00000
> Loading: *\b#
> done
> Bytes transferred = 10579 (2953 hex)
> => bootm 1000000 2000000 c00000
> WARNING: adjusting available memory to 30000000
> ## Booting kernel from Legacy Image at 01000000 ...
> Image Name: Linux-2.6.29
> Created: 2009-07-03 9:42:06 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 2654026 Bytes = 2.5 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> ## Loading init Ramdisk from Legacy Image at 02000000 ...
> Image Name: uboot ext2 ramdisk rootfs
> Created: 2009-07-04 8:24:27 UTC
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 26776811 Bytes = 25.5 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 00c00000
> Booting using the fdt blob at 0xc00000
> Uncompressing Kernel Image ... OK
> Loading Ramdisk to 2e676000, end 2ffff4eb ... OK
> Using P2020 RDB machine description
> Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=256Mb residual: 256Mb
> Linux version 2.6.29 (dipen@uTeam3.ap.freescale.net) (gcc version 4.3.2 (GCC) ) #1 SMP Fri Jul 3 15:11:50 IST 2009
> Found initrd at 0xee676000:0xeffff4eb
> CPU maps initialized for 1 thread per core
> console [udbg0] enabled
> setup_arch: bootmem
> mpc85xx_rdb_setup_arch()
> Found FSL PCI host bridge at 0x00000000ffe09000. Firmware bus number: 0->255
> PCI host bridge /pcie@ffe09000 ranges:
> MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000a0000000
> IO 0x00000000ffc30000..0x00000000ffc3ffff -> 0x0000000000000000
> Found FSL PCI host bridge at 0x00000000ffe0a000. Firmware bus number: 0->255
> PCI host bridge /pcie@ffe0a000 ranges:
> MEM 0x00000000c0000000..0x00000000dfffffff -> 0x00000000c0000000
> IO 0x00000000ffc20000..0x00000000ffc2ffff -> 0x0000000000000000
> MPC85xx RDB board from Freescale Semiconductor
> arch: exit
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00030000
> Normal 0x00030000 -> 0x00030000
> HighMem 0x00030000 -> 0x00040000
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0x00000000 -> 0x00040000
> MMU: Allocated 1088 bytes of context maps for 255 contexts
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096
> Kernel command line: root=/dev/ram rw console=ttyS0,115200 ramdisk_size=275000 cache-sram-size=0x10000
> mpic: Setting up MPIC " OpenPIC " version 1.2 at ffe40000, max 2 CPUs
> mpic: ISU size: 256, shift: 8, mask: ff
> mpic: Initializing for 256 sources
> PID hash table entries: 4096 (order: 12, 16384 bytes)
> clocksource: timebase mult[3555555] shift[22] registered
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 1007184k/1048576k available (5180k kernel code, 40848k reserved, 164k data, 134k bss, 216k init)
> SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> Calibrating delay loop... 149.50 BogoMIPS (lpj=299008)
> Mount-cache hash table entries: 512
> mpic: requesting IPIs ...
> Processor 1 found.
> Brought up 2 CPUs
> net_namespace: 732 bytes
> NET: Registered protocol family 16
>
> PCI: Probing PCI hardware
> pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
> pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> pci 0000:00:00.0: PME# disabled
> pci 0001:02:00.0: ignoring class b20 (doesn't match header type 01)
> pci 0001:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> pci 0001:02:00.0: PME# disabled
> pci 0000:00:00.0: not setting up bridge for bus 0000:01
> pci 0000:00:00.0: enabling device (0106 -> 0107)
> pci 0001:02:00.0: not setting up bridge for bus 0001:03
> pci 0001:02:00.0: enabling device (0106 -> 0107)
> bio: create slab <bio-0> at 0
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Freescale Elo / Elo Plus DMA driver
> NET: Registered protocol family 2
> IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
> TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> NET: Registered protocol family 1
> checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
> Freeing initrd memory: 26149k freed
> fsl-elo-dma ffe0c300.dma: Probe the Freescale DMA driver for fsl,eloplus-dma controller at ffe0c300...
> fsl-elo-dma ffe0c300.dma: #0 (fsl,eloplus-dma-channel), irq 76
> fsl-elo-dma ffe0c300.dma: #1 (fsl,eloplus-dma-channel), irq 77
> fsl-elo-dma ffe0c300.dma: #2 (fsl,eloplus-dma-channel), irq 78
> fsl-elo-dma ffe0c300.dma: #3 (fsl,eloplus-dma-channel), irq 79
> fsl-elo-dma ffe21300.dma: Probe the Freescale DMA driver for fsl,eloplus-dma controller at ffe21300...
> fsl-elo-dma ffe21300.dma: #0 (fsl,eloplus-dma-channel), irq 20
> fsl-elo-dma ffe21300.dma: #1 (fsl,eloplus-dma-channel), irq 21
> fsl-elo-dma ffe21300.dma: #2 (fsl,eloplus-dma-channel), irq 22
> fsl-elo-dma ffe21300.dma: #3 (fsl,eloplus-dma-channel), irq 23
> audit: initializing netlink socket (disabled)
> type=2000 audit(2.388:1): initialized
> highmem bounce pool size: 64 pages
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> NTFS driver 2.1.29 [Flags: R/O].
> JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
> JFFS2: default compression mode: priority
> msgmni has been set to 1507
> alg: No test for stdrng (krng)
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> Generic non-volatile memory driver v1.1
> Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled
> serial8250.0: ttyS0 at MMIO 0xffe04500 (irq = 42) is a 16550A
> console handover: boot [udbg0] -> real [ttyS0]
> serial8250.0: ttyS1 at MMIO 0xffe04600 (irq = 42) is a 16550A
> brd: module loaded
> loop: module loaded
> nbd: registered device at major 43
> e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6
> e1000e: Copyright (c) 1999-2008 Intel Corporation.
> Gianfar MII Bus: probed
> Gianfar MII Bus: probed
> eth0 (fsl-gianfar): not using net_device_ops yet
> eth0: Gianfar Ethernet Controller Version 1.4-skbr1.1.4, 00:04:9f:0c:05:00
> eth0: MTU = 1500 (frame size=1524, truesize=1800)
> eth0: Running with NAPI enabled
> eth0: 128/128 RX/TX BD ring size
> eth1 (fsl-gianfar): not using net_device_ops yet
> eth1: Gianfar Ethernet Controller Version 1.4-skbr1.1.4, 00:04:9f:0c:05:01
> eth1: MTU = 1500 (frame size=1524, truesize=1800)
> eth1: Running with NAPI enabled
> eth1: 128/128 RX/TX BD ring size
> eth2 (fsl-gianfar): not using net_device_ops yet
> eth2: Gianfar Ethernet Controller Version 1.4-skbr1.1.4, 00:04:9f:0c:05:02
> eth2: MTU = 1500 (frame size=1524, truesize=1800)
> eth2: Running with NAPI enabled
> eth2: 128/128 RX/TX BD ring size
> Fixed MDIO Bus: probed
> st: Version 20081215, fixed bufsize 32768, s/g segs 256
> Driver 'st' needs updating - please use bus_type methods
> Driver 'sd' needs updating - please use bus_type methods
> Driver 'sr' needs updating - please use bus_type methods
> ef000000.nor: Found 1 x16 devices at 0x0 in 16-bit bank
> Amd/Fujitsu Extended Query Table at 0x0040
> ef000000.nor: CFI does not contain boot bank location. Assuming top.
> number of CFI chips: 1
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
> RedBoot partition parsing not available
> Creating 5 MTD partitions on "ef000000.nor":
> 0x000000000000-0x000000040000 : "NOR (RO) Vitesse-7385 Firmware"
> ftl_cs: FTL header not found.
> 0x000000040000-0x000000080000 : "NOR (RO) DTB Image"
> ftl_cs: FTL header not found.
> 0x000000080000-0x000000400000 : "NOR (RO) Linux Kernel Image"
> ftl_cs: FTL header not found.
> 0x000000400000-0x000000f00000 : "NOR (RW) JFFS2 Root File System"
> ftl_cs: FTL header not found.
> 0x000000f00000-0x000001000000 : "NOR (RO) U-Boot Image"
> ftl_cs: FTL header not found.
> NAND device: Manufacturer ID: 0xec, Chip ID: 0x75 (Samsung NAND 32MiB 3,3V 8-bit)
> RedBoot partition parsing not available
> Creating 6 MTD partitions on "ffa00000.flash":
> 0x000000000000-0x000000080000 : "NAND (RO) U-Boot Image"
> ftl_cs: FTL header not found.
> 0x000000080000-0x000000100000 : "NAND (RO) DTB Image"
> ftl_cs: FTL header not found.
> 0x000000100000-0x000000500000 : "NAND (RO) Linux Kernel Image"
> ftl_cs: FTL header not found.
> 0x000000500000-0x000000900000 : "NAND (RO) Compressed RFS Image"
> ftl_cs: FTL header not found.
> 0x000000900000-0x000001000000 : "NAND (RW) JFFS2 Root File System"
> ftl_cs: FTL header not found.
> 0x000001000000-0x000002000000 : "NAND (RW) Writable User area"
> ftl_cs: FTL header not found.
> eLBC NAND device at 0xffa00000, bank 1
> fsl_m25p80 spi28672.0: s25sl128b (0 Kbytes)
> Creating 5 MTD partitions on "SPIFLASH0":
> 0x000000000000-0x000000080000 : "SPI (RO) U-Boot Image"
> ftl_cs: FTL header not found.
> 0x000000080000-0x000000100000 : "SPI (RO) DTB Image"
> ftl_cs: FTL header not found.
> 0x000000100000-0x000000500000 : "SPI (RO) Linux Kernel Image"
> ftl_cs: FTL header not found.
> 0x000000500000-0x000000900000 : "SPI (RO) Compressed RFS Image"
> ftl_cs: FTL header not found.
> 0x000000900000-0x000001000000 : "SPI (RW) JFFS2 RFS"
> ftl_cs: FTL header not found.
> ffe07000.spi: Freescale eSPI Controller driver at 0xf210a000 (irq = 59)
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
> fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
> fsl-ehci fsl-ehci.0: irq 28, io base 0xffe22000
> fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
> usb usb1: configuration #1 chosen from 1 choice
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> Initializing USB Mass Storage driver...
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> i2c /dev entries driver
> rtc-ds1307 0-0068: rtc core: registered ds1339 as rtc0
> sdhci: Secure Digital Host Controller Interface driver
> sdhci: Copyright(c) Pierre Ossman
> esdhc: Freescale Enhanced Secure Digital Host Controller driver
> mmc0: ESDHC at 0xffe2e000 irq 72 PIO
> talitos ffe30000.crypto: hwrng
> alg: No test for authenc(hmac(sha1),cbc(aes)) (authenc-hmac-sha1-cbc-aes-talitos)
> talitos ffe30000.crypto: authenc-hmac-sha1-cbc-aes-talitos
> alg: No test for authenc(hmac(sha1),cbc(des3_ede)) (authenc-hmac-sha1-cbc-3des-talitos)
> talitos ffe30000.crypto: authenc-hmac-sha1-cbc-3des-talitos
> alg: No test for authenc(hmac(sha256),cbc(aes)) (authenc-hmac-sha256-cbc-aes-talitos)
> talitos ffe30000.crypto: authenc-hmac-sha256-cbc-aes-talitos
> alg: No test for authenc(hmac(sha256),cbc(des3_ede)) (authenc-hmac-sha256-cbc-3des-talitos)
> talitos ffe30000.crypto: authenc-hmac-sha256-cbc-3des-talitos
> alg: No test for authenc(hmac(md5),cbc(aes)) (authenc-hmac-md5-cbc-aes-talitos)
> talitos ffe30000.crypto: authenc-hmac-md5-cbc-aes-talitos
> alg: No test for authenc(hmac(md5),cbc(des3_ede)) (authenc-hmac-md5-cbc-3des-talitos)
> talitos ffe30000.crypto: authenc-hmac-md5-cbc-3des-talitos
> IPv4 over IPv4 tunneling driver
> GRE over IPv4 tunneling driver
> TCP cubic registered
> Initializing XFRM netlink socket
> NET: Registered protocol family 10
> IPv6 over IPv4 tunneling driver
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
> All bugs added by David S. Miller <davem@redhat.com>
> rtc-ds1307 0-0068: setting system clock to 2009-07-01 10:24:20 UTC (1246443860)
> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem) on device 1:0.
> Freeing unused kernel memory: 216k init
> Mounting /proc and /sys
> Setting the hostname to P2020RDB
> Mounting filesystems
> mount: sysfs already mounted or /sys busy
> mount: according to mtab, /sys is already mounted on /sys
> Starting syslogd and klogd
> Running sysctl
> Setting up networking on loopback device:
> Setting up networking on eth0: ADDRCONF(NETDEV_UP): eth0: link is not ready
>
> Adding static route for default gateway to 192.168.0.1:
> Setting nameserver to 192.168.0.1 in /etc/resolv.conf:
> SettingADDRCONF(NETDEV_UP): eth1: link is not ready
> up networking on eth1:
> Adding static route for default gateway to 192.168.1.1:
> Setting nameserver to 192.168.1.1 in /etc/resolv.conf:
> SettingADDRCONF(NETDEV_UP): eth2: link is not ready
> up networking on eth2:
> Adding static route for default gateway to 192.168.2.1:
> Starting inetd:
> Starting the port mapper:
> Generating keys for the dropbear ssh server:
> Will output 1024 bit rsa secret key to '/etc/dropbear/dropbear_rsa_host_key'
> Generating key, this may take a while...
> Public key portion is:
> ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgwC8sk4V/7x6e0hJOjBdcGmUx26QQfpVdxT1z9itBPZf/bdfogKI5OHEfCPU2Tc+ZYNtrPXIgYvrML5I5z/WQL7QNgOx0/Vv
> woNbxHLXj5UmirIJ6kNKlyUisPyZNU54XQjKCTpK7GjcGvUFgQMqv2HqWMfFV9XmytvXJgkhyg0jxox7 root@P2020RDB
> Fingerprint: md5 2d:50:46:59:d1:92:72:1f:07:cf:e4:b6:14:6c:86:f3
> Starting the dropbear ssh server:
> Starting the boa webserver:
> Please set the system time using
> date <mmddhhmnyyyy>
> /sbin/hwclock -w
> PHY: 0:01 - Link is Up - 1000/Full
> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
>
> Welcome to Freescale Semiconductor Embedded Linux Environment
>
> !!!!! WARNING !!!!!!!
>
> The default password for the root account is: root
> please change this password using the 'passwd' command
> and then edit this message (/etc/issue) to remove this message
>
> P2020RDB login: PHY: mdio0@520:01 - Link is Up - 1000/Full
> ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
> root
> Password:
> [root@P2020RDB /root]# ifco\b\b\b\b[root@P2020RDB /root]# ifconfig eth0 down
> [root@P2020RDB /root]# [root@P2020RDB /root]# ifconfig eth0 down\b\b\b\b\b\b down 1 down down
> [root@P2020RDB /root]# [root@P2020RDB /root]# ifconfig eth1 down\b\b\b\b\b\b down 2 down down
> [root@P2020RDB /root]#
> [root@P2020RDB /root]#
> [root@P2020RDB /root]# ifco\b\b\b\b[root@P2020RDB /root]# ifconfig eth0 192.168.1.2 netmask 255.255.255.0
> [root@P2020RDB /root]# PHY: 0:01 - Link is Up - 1000/Full
>
> [root@P2020RDB /root]# ifcoe\b \b\b\b\b\b[root@P2020RDB /root]# ifconfig t\b \beyh\b \b\b \bth2 192.168.2.2 netmask 255.255.255.0
> [root@P2020RDB /root]# PHY: mdio0@520:01 - Link is Up - 1000/Full
>
> [root@P2020RDB /root]# ifco\b\b\b\b[root@P2020RDB /root]# ifconfig eth\b \b\b \b\b \b\b \b\b \b\b \b\b \b\b \b\b \b\b \b\b \b\b \beccho 1 > /p\b\b[root@P2020RDB /root]# eccho 1 > /proc/sy[root@P2020RDB /root]# eccho 1 > /proc/sys/n[root@P2020RDB /root]# eccho 1 > /proc/sys/net/ip[root@P2020RDB /root]# eccho 1 > /proc/sys/net/ipv4[root@P2020RDB /root]# eccho 1 > /proc/sys/net/ipv4/ip_f[root@P2020RDB /root]# eccho 1 > /proc/sys/net/ipv4/ip_forward
> -sh: eccho: not found
> [root@P2020RDB /root]# echo 1 > /p\b\b[root@P2020RDB /root]# echo 1 > /proc/sy[root@P2020RDB /root]# echo 1 > /proc/sys/n[root@P2020RDB /root]# echo 1 > /proc/sys/net/ip[root@P2020RDB /root]# echo 1 > /proc/sys/net/ipv4[root@P2020RDB /root]# echo 1 > /proc/sys/net/ipv4/ip_f[root@P2020RDB /root]# echo 1 > /proc/sys/net/ipv4/ip_forward
> [root@P2020RDB /root]#
> [root@P2020RDB /root]#
> [root@P2020RDB /root]# pn\b \bing 192.168.1.1
> PING 192.168.1.1 (192.168.1.1): 56 data bytes
> 64 bytes from 192.168.1.1: seq=0 ttl=255 time=2.590 ms
> 64 bytes from 192.168.1.1: seq=1 ttl=255 time=0.090 ms
>
> --- 192.168.1.1 ping statistics ---
> 2 packets transmitted, 2 packets received, 0% packet loss
> round-trip min/avg/max = 0.090/1.340/2.590 ms
> [root@P2020RDB /root]#
> [root@P2020RDB /root]#
> [root@P2020RDB /root]# ping 192.168.2.1
> PING 192.168.2.1 (192.168.2.1): 56 data bytes
> 64 bytes from 192.168.2.1: seq=0 ttl=255 time=3.502 ms
>
> --- 192.168.2.1 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max = 3.502/3.502/3.502 ms
> [root@P2020RDB /root]# arp
> gateway2 (192.168.2.1) at 00:00:08:00:00:01 [ether] on eth2
> gateway1 (192.168.1.1) at 00:00:07:00:00:01 [ether] on eth0
> [root@P2020RDB /root]# arp -s 192.168.2.1 00:00:08:00:00:01
> [root@P2020RDB /root]# arp -s 192.1681.\b \b\b \b.1.1 00:00:07:00:00:01
> [root@P2020RDB /root]#
> [root@P2020RDB /root]#
> [root@P2020RDB /root]#
> [root@P2020RDB /root]# arp
> gateway2 (192.168.2.1) at 00:00:08:00:00:01 [ether] PERM on eth2
> gateway1 (192.168.1.1) at 00:00:07:00:00:01 [ether] PERM on eth0
> [root@P2020RDB /root]# ifco\b\b\b\b[root@P2020RDB /root]# ifconfig
> eth0 Link encap:Ethernet HWaddr 00:04:9F:0C:05:00
> inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:5 errors:0 dropped:0 overruns:0 frame:0
> TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:426 (426.0 B) TX bytes:1146 (1.1 KiB)
> Base address:0x2000
>
> eth2 Link encap:Ethernet HWaddr 00:04:9F:0C:05:02
> inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:4 errors:0 dropped:0 overruns:0 frame:0
> TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:318 (318.0 B) TX bytes:1048 (1.0 KiB)
> Base address:0xa000
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>
> [root@P2020RDB /root]# cat /p\b\b[root@P2020RDB /root]# cat /proc/in[root@P2020RDB /root]# cat /proc/interrupts
> CPU0 CPU1
> 19: 648 0 OpenPIC Level fsl-elbc
> 20: 0 0 OpenPIC Level fsldma-channel
> 21: 0 0 OpenPIC Level fsldma-channel
> 22: 0 0 OpenPIC Level fsldma-channel
> 23: 0 0 OpenPIC Level fsldma-channel
> 28: 0 0 OpenPIC Level ehci_hcd:usb1
> 29: 13 0 OpenPIC Level eth0_tx
> 30: 0 4 OpenPIC Level eth0_rx
> 31: 0 12 OpenPIC Level eth2_tx
> 32: 4 0 OpenPIC Level eth2_rx
> 33: 0 0 OpenPIC Level eth2_er
> 34: 0 0 OpenPIC Level eth0_er
> 42: 1049 0 OpenPIC Level serial
> 43: 0 29 OpenPIC Level i2c-mpc, i2c-mpc
> 45: 0 0 OpenPIC Level talitos
> 59: 0 2494 OpenPIC Level fsl_espi
> 72: 12 0 OpenPIC Level esdhc:slot0
> 76: 0 0 OpenPIC Level fsldma-channel
> 77: 0 0 OpenPIC Level fsldma-channel
> 78: 0 0 OpenPIC Level fsldma-channel
> 79: 0 0 OpenPIC Level fsldma-channel
> 251: 0 0 OpenPIC Edge ipi call function
> 252: 1253 1387 OpenPIC Edge ipi reschedule
> 253: 427 390 OpenPIC Edge ipi call function single
> BAD: 1
> [root@P2020RDB /root]# PHY: mdio0@520:01 - Link is Down
> PHY: mdio0@520:01 - Link is Up - 1000/Full
>
> [root@P2020RDB /root]# cat /p\b\b[root@P2020RDB /root]# cat /proc/in[root@P2020RDB /root]# cat /proc/interrupts
> CPU0 CPU1
> 19: 648 0 OpenPIC Level fsl-elbc
> 20: 0 0 OpenPIC Level fsldma-channel
> 21: 0 0 OpenPIC Level fsldma-channel
> 22: 0 0 OpenPIC Level fsldma-channel
> 23: 0 0 OpenPIC Level fsldma-channel
> 28: 0 0 OpenPIC Level ehci_hcd:usb1
> 29: 56328 0 OpenPIC Level eth0_tx
> 30: 0 5553282 OpenPIC Level eth0_rx
> 31: 0 43413 OpenPIC Level eth2_tx
> 32: 5709572 0 OpenPIC Level eth2_rx
> 33: 0 0 OpenPIC Level eth2_er
> 34: 0 0 OpenPIC Level eth0_er
> 42: 1179 0 OpenPIC Level serial
> 43: 0 29 OpenPIC Level i2c-mpc, i2c-mpc
> 45: 0 0 OpenPIC Level talitos
> 59: 0 2494 OpenPIC Level fsl_espi
> 72: 12 0 OpenPIC Level esdhc:slot0
> 76: 0 0 OpenPIC Level fsldma-channel
> 77: 0 0 OpenPIC Level fsldma-channel
> 78: 0 0 OpenPIC Level fsldma-channel
> 79: 0 0 OpenPIC Level fsldma-channel
> 251: 0 0 OpenPIC Edge ipi call function
> 252: 1254 1389 OpenPIC Edge ipi reschedule
> 253: 427 406 OpenPIC Edge ipi call function single
> BAD: 36172
> [root@P2020RDB /root]# uname -a
> Linux P2020RDB 2.6.29 #1 SMP Fri Jul 3 15:11:50 IST 2009 ppc unknown
> [root@P2020RDB /root]# cat /p\b\b[root@P2020RDB /root]# cat /proc/in[root@P2020RDB /root]# cat /proc/interrupts
> CPU0 CPU1
> 19: 648 0 OpenPIC Level fsl-elbc
> 20: 0 0 OpenPIC Level fsldma-channel
> 21: 0 0 OpenPIC Level fsldma-channel
> 22: 0 0 OpenPIC Level fsldma-channel
> 23: 0 0 OpenPIC Level fsldma-channel
> 28: 0 0 OpenPIC Level ehci_hcd:usb1
> 29: 56328 0 OpenPIC Level eth0_tx
> 30: 0 5553282 OpenPIC Level eth0_rx
> 31: 0 43413 OpenPIC Level eth2_tx
> 32: 5709572 0 OpenPIC Level eth2_rx
> 33: 0 0 OpenPIC Level eth2_er
> 34: 0 0 OpenPIC Level eth0_er
> 42: 1329 0 OpenPIC Level serial
> 43: 0 29 OpenPIC Level i2c-mpc, i2c-mpc
> 45: 0 0 OpenPIC Level talitos
> 59: 0 2494 OpenPIC Level fsl_espi
> 72: 12 0 OpenPIC Level esdhc:slot0
> 76: 0 0 OpenPIC Level fsldma-channel
> 77: 0 0 OpenPIC Level fsldma-channel
> 78: 0 0 OpenPIC Level fsldma-channel
> 79: 0 0 OpenPIC Level fsldma-channel
> 251: 0 0 OpenPIC Edge ipi call function
> 252: 1256 1391 OpenPIC Edge ipi reschedule
> 253: 427 439 OpenPIC Edge ipi call function single
> BAD: 36172
> [root@P2020RDB /root]# ifco\b\b\b\b[root@P2020RDB /root]# ifconfig
> eth0 Link encap:Ethernet HWaddr 00:04:9F:0C:05:00
> inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:8928576 errors:0 dropped:0 overruns:0 frame:0
> TX packets:8928586 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:625000396 (596.0 MiB) TX bytes:535715406 (510.8 MiB)
> Base address:0x2000
>
> eth2 Link encap:Ethernet HWaddr 00:04:9F:0C:05:02
> inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:8928575 errors:0 dropped:0 overruns:0 frame:0
> TX packets:8928585 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:625000288 (596.0 MiB) TX bytes:535715308 (510.8 MiB)
> Base address:0xa000
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>
> [root@P2020RDB /root]#
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Régis ODEYE
Kontron Modular Computers SA
150, rue M. Berthelot / ZI Toulon Est / BP 244 / Fr 83078 TOULON Cedex 9
Phone: (33) 4 98 16 34 86 Fax: (33) 4 98 16 34 01
E-mail: regis.odeye@kontron.com Web : www.kontron.com
^ permalink raw reply
* Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
From: Peter Korsgaard @ 2009-12-31 8:01 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Peter Tyser, linux-kbuild, u-boot
In-Reply-To: <fa686aa40912301601s6cd0ec4y85b88976159a36af@mail.gmail.com>
>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
Grant> Personally, I don't get any benefit out of the new image format,
Grant> so I haven't spent any time looking at it. However, I'm
Grant> concerned about the drift back towards a different image per
Grant> target when the move over the last 4 years has been towards
Grant> multiplatform kernel images. I certainly don't want to
Grant> encourage embedding the device tree blob into the kernel image,
Grant> and I'm not very interested in merging code to do that into the
Grant> kernel tree. If someone really needs to do that for their
Grant> particular target, it is certainly easy enough for them to weld
Grant> in the .dtb after the fact before transferring the image to the
Grant> target, but I want that mode to be the exception, not the rule.
I understand the advantages of being able to compile multiplatform
kernels - But for the typical embedded device, having the device tree
together with the kernel makes stuff a lot simpler when upgrading
because of the version depencies of the dts.
That's also why I submitted the (nacked) multifile uimage support some
time ago:
http://thread.gmane.org/gmane.linux.ports.ppc64.devel/46825/
The fitimage stuff is the logical continuation of that.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: net: Assorted fixes
From: David Miller @ 2009-12-31 6:04 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, afleming, linuxppc-dev
In-Reply-To: <20091230182146.GA4515@oksana.dev.rtsoft.ru>
RnJvbTogQW50b24gVm9yb250c292IDxhdm9yb250c292QHJ1Lm12aXN0YS5jb20+DQpEYXRlOiBX
ZWQsIDMwIERlYyAyMDA5IDIxOjIxOjQ2ICswMzAwDQoNCj4gT24gU3VuLCBEZWMgMjcsIDIwMDkg
YXQgMDk6NTc6MzZQTSAtMDgwMCwgRGF2aWQgTWlsbGVyIHdyb3RlOg0KPj4gQWN0dWFsbHkgSSdt
IHJldmVydGluZyBib3RoIHBhdGNoZXM6DQo+PiANCj4+IGRyaXZlcnMvbmV0L3BoeS9tZGlvX2J1
cy5jOjI2ODogd2FybmluZzogoW1kaW9fYnVzX3BoeV9tYXlfc3VzcGVuZKIgZGVmaW5lZCBidXQg
bm90IHVzZWQNCj4+IA0KPj4gUGxlYXNlIHJlc3VibWl0IHRoZXNlIHR3byBwYXRjaGVzIHdpdGgg
dGhpcyB3YXJuaW5nIGZpeGVkLg0KPj4gDQo+PiBDT05GSUdfUE0gaXMgbm90IGFsd2F5cyBlbmFi
bGVkIDotKQ0KPiANCj4gVWdoLCBzb3JyeSBhYm91dCB0aGF0LCBhbmQgdGhhbmtzIGZvciBjYXRj
aGluZyENCj4gDQo+IEhlcmUgYXJlIHRoZSBhbWVuZGVkIHBhdGNoZXMgKyBvbmUgbW9yZSBmaXgu
DQoNCkFsbCBhcHBsaWVkLCB0aGFua3MuDQo=
^ permalink raw reply
* Re: [PATCH] arch/powerpc/boot/devtree.c: use %pM to show MAC address
From: Paul Mackerras @ 2009-12-31 4:49 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <BD79186B4FD85F4B8E60E381CAEE19090200F65E@mi8nycmail19.Mi8.com>
On Wed, Dec 30, 2009 at 02:30:39PM -0500, H Hartley Sweeten wrote:
> Use the %pM kernel extension to display the MAC address.
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
>
> ---
>
> diff --git a/arch/powerpc/boot/devtree.c b/arch/powerpc/boot/devtree.c
> index a7e21a3..a2f07a5 100644
> --- a/arch/powerpc/boot/devtree.c
> +++ b/arch/powerpc/boot/devtree.c
> @@ -93,10 +93,7 @@ void dt_fixup_mac_address_by_alias(const char *alias, const u8 *addr)
> void *devp = find_node_by_alias(alias);
>
> if (devp) {
> - printf("%s: local-mac-address <-"
> - " %02x:%02x:%02x:%02x:%02x:%02x\n\r", alias,
> - addr[0], addr[1], addr[2],
> - addr[3], addr[4], addr[5]);
> + printf("%s: local-mac-address <- %pM\n\r", alias, addr);
Nak - this isn't the kernel, this is a separate program, namely the
bootwrapper that decompresses the kernel image, and it has its own
printf (not printk) implementation in arch/powerpc/boot/stdio.c, which
doesn't understand the %pX extensions (and I don't see any good reason
to make it do so).
Paul.
^ permalink raw reply
* Re: [PATCH 1/1] Adds gpio_to_irq() and related support to the mpc52xx_gpio WKUP peripheral driver
From: Bill Gatliff @ 2009-12-31 4:19 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1262232985-30822-1-git-send-email-bgat@billgatliff.com>
Bill Gatliff wrote:
> Second, the previously-unimplemented gpio_to_irq() function was added,
> using __gpio_to_irq(). The author does not know why this code was previously
> left out of arch/powerpc/include/asm/gpio.h. It seems to work. The generic
> irq_to_gpio() function was not tested.
>
Actually, I just noticed that this patch was already committed but I
hadn't pulled it in to my repo so I ended up re-discovering and
duplicating it.
The rest of the comments for this patch are accurate.
b.g.
--
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com
^ permalink raw reply
* [PATCH 1/1] Adds gpio_to_irq() and related support to the mpc52xx_gpio WKUP peripheral driver
From: Bill Gatliff @ 2009-12-31 4:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Bill Gatliff
This patch cascades the GPIO_WKUP peripheral's eight pins into separate,
virtual interrupt descriptors. This demultiplexing relieves driver authors
of having to demultiplex and manage the pins on their own.
Several important changes were necessary to implement this support, beyond
just the addition of the cascading and irq_host functions. First, the
gpiochip devices are now registered during arch_initcall. Without this
modification, the virtual interrupt mapping changes during startup in ways
that cause drivers to "lose" their interrupt-to-handler mappings. The
mpc52xx FEC driver, for example, will fail to receive interrupts if the
gpiochip and irq_host registrations happen at subsys_initcall as was done
in the previous version of the driver.
Second, the previously-unimplemented gpio_to_irq() function was added,
using __gpio_to_irq(). The author does not know why this code was previously
left out of arch/powerpc/include/asm/gpio.h. It seems to work. The generic
irq_to_gpio() function was not tested.
Finally, the interrupt-controller property was added to the mpc52xx_gpio device
tree entry for the WKUP peripheral. The interrupt demultiplexing code is
installed only when this property is present. The author's device tree node
for the GPIO_WKUP peripheral looks like this:
gpio_wkup: gpio@c00 {
compatible = "fsl,mpc5200b-gpio-wkup","fsl,mpc5200-gpio-wkup";
#gpio-cells = <2>;
#address-cells = <0>;
reg = <0xc00 0x40>;
interrupt-parent = <&mpc5200_pic>;
interrupts = <1 8 0 0 3 0>;
gpio-controller;
interrupt-controller;
#interrupt-cells = <3>;
};
The author generally refrains from modifying working code. However, there were a large
number of redundant statements in the existing gpiolib implementation code to compute
bit masks for pins, and these masks needed to be consistent throughout the gpio and interrupt
cascading implementation. The redundant statements were replaced with a new
mpc52xx_wkup_gpio_to_mask() helper function.
The gpio-to-irq mapping follows the convention established by the gpiolib driver.
Specifically, gpio pin 0 is GPIO_WKUP_7, pin 1 is GPIO_WKUP_6, and so on. An example of
a device tree node that attaches to GPIO_WKUP_7 looks like this (the associated driver is
a modified version of the existing drivers/misc/input/rotary_encoder.c):
rotary-encoder {
compatible = "linux,rotary-encoder","rotary-encoder";
interrupts = <&mpc5200_pic 1 2 3>;
gpios = <&gpio_wkup 0 0>;
type = <1>;
val-ccw = <0x4a>;
val-cw = <78>;
};
The three values in the "gpios =" statement are the phandle for the gpio controller,
the peripheral pin number, and a flag that is currently ignored. The rotary-encoder
driver uses of_get_gpio_flags() to get the gpiolib value for the pin:
cfg->gpio[wchan] = of_get_gpio_flags(ofdev->node, ngpio++, NULL);
The value returned by of_get_gpio_flags() can be passed to gpio_to_irq(), and then
on to request_irq().
The GPIO_WKUP peripheral supports limited options for interrupt types, including:
IRQ_TYPE_EDGE_FALLING, IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_BOTH
The driver emulates IRQ_TYPE_LEVEL_LOW and IRQ_TYPE_LEVEL_HIGH types using falling
and rising edges, respectively, but this code has not been extensively tested. The
GPIO_WKUP peripheral's "pulse" interrupt type is not supported.
This driver does not currently support Deep Sleep wakeups, only non-Deep Sleep ones.
The Deep Sleep wakeups appear to be most suited for support under power management
functionality, and not gpio-related operations.
Signed-off-by: Bill Gatliff <bgat@billgatliff.com>
---
arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 328 ++++++++++++++++++++++-----
1 files changed, 267 insertions(+), 61 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
index 2b8d8ef..67d91d2 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
@@ -1,6 +1,7 @@
/*
* MPC52xx gpio driver
*
+ * Copyright (c) 2010 Bill Gatliff <bgat@billgatliff.com>
* Copyright (c) 2008 Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix
*
* This program is free software; you can redistribute it and/or modify
@@ -22,6 +23,7 @@
#include <linux/of_gpio.h>
#include <linux/io.h>
#include <linux/of_platform.h>
+#include <linux/irq.h>
#include <asm/gpio.h>
#include <asm/mpc52xx.h>
@@ -34,8 +36,18 @@ struct mpc52xx_gpiochip {
unsigned int shadow_dvo;
unsigned int shadow_gpioe;
unsigned int shadow_ddr;
+ unsigned int shadow_iinten;
+ unsigned int shadow_itype;
+ struct irq_host *irqhost;
+ unsigned int irq;
};
+static inline struct mpc52xx_gpiochip *
+to_mpc52xx_gpiochip(struct of_mm_gpio_chip *mm)
+{
+ return container_of(mm, struct mpc52xx_gpiochip, mmchip);
+}
+
/*
* GPIO LIB API implementation for wakeup GPIOs.
*
@@ -52,6 +64,14 @@ struct mpc52xx_gpiochip {
* 7 -> PSC1_4
*
*/
+
+#define MPC52XX_WKUP_GPIO_PINS 8
+
+static inline u32 mpc52xx_wkup_gpio_to_mask(unsigned int gpio)
+{
+ return 1u << ((MPC52XX_WKUP_GPIO_PINS - 1) - gpio);
+}
+
static int mpc52xx_wkup_gpio_get(struct gpio_chip *gc, unsigned int gpio)
{
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
@@ -74,9 +94,9 @@ __mpc52xx_wkup_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
struct mpc52xx_gpio_wkup __iomem *regs = mm_gc->regs;
if (val)
- chip->shadow_dvo |= 1 << (7 - gpio);
+ chip->shadow_dvo |= mpc52xx_wkup_gpio_to_mask(gpio);
else
- chip->shadow_dvo &= ~(1 << (7 - gpio));
+ chip->shadow_dvo &= ~mpc52xx_wkup_gpio_to_mask(gpio);
out_8(®s->wkup_dvo, chip->shadow_dvo);
}
@@ -103,14 +123,16 @@ static int mpc52xx_wkup_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
struct mpc52xx_gpio_wkup __iomem *regs = mm_gc->regs;
unsigned long flags;
+ pr_debug("%s: gpio %d\n", __func__, gpio);
+
spin_lock_irqsave(&gpio_lock, flags);
/* set the direction */
- chip->shadow_ddr &= ~(1 << (7 - gpio));
+ chip->shadow_ddr &= ~mpc52xx_wkup_gpio_to_mask(gpio);
out_8(®s->wkup_ddr, chip->shadow_ddr);
/* and enable the pin */
- chip->shadow_gpioe |= 1 << (7 - gpio);
+ chip->shadow_gpioe |= mpc52xx_wkup_gpio_to_mask(gpio);
out_8(®s->wkup_gpioe, chip->shadow_gpioe);
spin_unlock_irqrestore(&gpio_lock, flags);
@@ -132,11 +154,11 @@ mpc52xx_wkup_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
__mpc52xx_wkup_gpio_set(gc, gpio, val);
/* Then set direction */
- chip->shadow_ddr |= 1 << (7 - gpio);
+ chip->shadow_ddr |= mpc52xx_wkup_gpio_to_mask(gpio);
out_8(®s->wkup_ddr, chip->shadow_ddr);
/* Finally enable the pin */
- chip->shadow_gpioe |= 1 << (7 - gpio);
+ chip->shadow_gpioe |= mpc52xx_wkup_gpio_to_mask(gpio);
out_8(®s->wkup_gpioe, chip->shadow_gpioe);
spin_unlock_irqrestore(&gpio_lock, flags);
@@ -146,17 +168,198 @@ mpc52xx_wkup_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
return 0;
}
-static int __devinit mpc52xx_wkup_gpiochip_probe(struct of_device *ofdev,
- const struct of_device_id *match)
+static int mpc52xx_wkup_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
+{
+ struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpiochip *c = to_mpc52xx_gpiochip(mm);
+
+ if (c->irqhost && offset < MPC52XX_WKUP_GPIO_PINS)
+ return irq_create_mapping(c->irqhost, offset);
+ return -ENXIO;
+}
+
+static void mpc52xx_wkup_gpio_irq_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ struct mpc52xx_gpiochip *chip = get_irq_data(irq);
+ struct of_mm_gpio_chip *mm_gc = &chip->mmchip;
+ struct mpc52xx_gpio_wkup __iomem *regs = mm_gc->regs;
+ u32 istat;
+ int gpio, sub_virq;
+
+ while((istat = in_8(®s->wkup_istat) != 0)) {
+ gpio = ffs(istat) - 1;
+ sub_virq = irq_linear_revmap(chip->irqhost, gpio);
+ generic_handle_irq(sub_virq);
+
+ pr_debug("%s: istat %x gpio %d irq %u sub_virq %d\n",
+ __func__, istat, gpio, irq, sub_virq);
+ }
+}
+
+static void mpc52xx_wkup_gpio_irq_unmask(unsigned int virq)
+{
+ struct mpc52xx_gpiochip *c = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &c->mmchip;
+ struct mpc52xx_gpio_wkup __iomem *regs = mm->regs;
+ unsigned long flags;
+
+ pr_debug("%s virq %d hwirq %ld\n",
+ __func__, virq, virq_to_hw(virq));
+
+ spin_lock_irqsave(&gpio_lock, flags);
+ c->shadow_iinten |= mpc52xx_wkup_gpio_to_mask(virq_to_hw(virq));
+ out_8(®s->wkup_iinten, c->shadow_iinten);
+ spin_unlock_irqrestore(&gpio_lock, flags);
+
+ pr_debug( "%s: iinten %x\n", __func__, c->shadow_iinten);
+}
+
+static void mpc52xx_wkup_gpio_irq_mask(unsigned int virq)
+{
+ struct mpc52xx_gpiochip *c = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &c->mmchip;
+ struct mpc52xx_gpio_wkup __iomem *regs = mm->regs;
+ unsigned long flags;
+
+ pr_debug("%s virq %d hwirq %ld\n",
+ __func__, virq, virq_to_hw(virq));
+
+ spin_lock_irqsave(&gpio_lock, flags);
+ c->shadow_iinten &= ~mpc52xx_wkup_gpio_to_mask(virq_to_hw(virq));
+ out_8(®s->wkup_iinten, c->shadow_iinten);
+ spin_unlock_irqrestore(&gpio_lock, flags);
+
+ pr_debug( "%s: iinten %x\n",
+ __func__, c->shadow_iinten);
+}
+
+static void mpc52xx_wkup_gpio_irq_ack(unsigned int virq)
+{
+ struct mpc52xx_gpiochip *c = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &c->mmchip;
+ struct mpc52xx_gpio_wkup __iomem *regs = mm->regs;
+ unsigned long flags;
+
+ pr_debug("%s\n", __func__);
+
+ spin_lock_irqsave(&gpio_lock, flags);
+ out_8(®s->wkup_istat, mpc52xx_wkup_gpio_to_mask(virq_to_hw(virq)));
+ spin_unlock_irqrestore(&gpio_lock, flags);
+}
+
+
+static inline u32 mpc52xx_wkup_gpio_to_itype(unsigned int gpio,
+ unsigned int type)
+{
+ return type << (((MPC52XX_WKUP_GPIO_PINS - 1) - gpio) * 2);
+}
+
+enum wkup_gpio_itype {
+ ITYPE_BOTH = 0,
+ ITYPE_FALLING = 1,
+ ITYPE_RISING = 2,
+ ITYPE_PULSE = 3,
+ ITYPE_MASK = (ITYPE_BOTH | ITYPE_RISING
+ | ITYPE_FALLING | ITYPE_PULSE),
+};
+
+static int mpc52xx_wkup_gpio_irq_set_type(unsigned int virq,
+ unsigned int flow_type)
+{
+ struct mpc52xx_gpiochip *c = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &c->mmchip;
+ struct mpc52xx_gpio_wkup __iomem *regs = mm->regs;
+ unsigned int hw = virq_to_hw(virq);
+ unsigned long flags;
+ unsigned int type;
+
+ pr_debug("%s virq %d hw %d type %d\n",
+ __func__, virq, hw, flow_type);
+
+ switch (flow_type) {
+ case IRQ_TYPE_LEVEL_LOW:
+ /* emulate with IRQ_TYPE_EDGE_FALLING */
+ case IRQ_TYPE_EDGE_FALLING:
+ type = mpc52xx_wkup_gpio_to_itype(hw, ITYPE_FALLING);
+ break;
+ case IRQ_TYPE_LEVEL_HIGH:
+ /* emulate with IRQ_TYPE_EDGE_RISING */
+ case IRQ_TYPE_EDGE_RISING:
+ type = mpc52xx_wkup_gpio_to_itype(hw, ITYPE_RISING);
+ break;
+ case IRQ_TYPE_EDGE_BOTH:
+ type = mpc52xx_wkup_gpio_to_itype(hw, ITYPE_BOTH);
+ break;
+ case IRQ_TYPE_NONE: /* TODO: what do we do with this? */
+ return -EINVAL;
+ default:
+ /* TODO: how do we map the "pulse" type? */
+ return -EINVAL;
+ }
+
+ spin_lock_irqsave(&gpio_lock, flags);
+ c->shadow_itype &= ~mpc52xx_wkup_gpio_to_itype(hw, ITYPE_MASK);
+ c->shadow_itype |= type;
+ out_be16(®s->wkup_itype, c->shadow_itype);
+ spin_unlock_irqrestore(&gpio_lock, flags);
+
+ pr_debug("%s: itype %x\n", __func__, c->shadow_itype);
+ return 0;
+}
+
+
+static struct irq_chip mpc52xx_wkup_gpio_irq_chip = {
+ .name = "mpc5200-gpio-wkup-irq",
+ .unmask = mpc52xx_wkup_gpio_irq_unmask,
+ .mask = mpc52xx_wkup_gpio_irq_mask,
+ .ack = mpc52xx_wkup_gpio_irq_ack,
+ .set_type = mpc52xx_wkup_gpio_irq_set_type,
+};
+
+static int mpc52xx_wkup_gpio_irqhost_map(struct irq_host *h,
+ unsigned int virq,
+ irq_hw_number_t hw)
+{
+ pr_debug("%s virq %d hw %ld host_data %p\n",
+ __func__, virq, hw, h->host_data);
+ set_irq_chip_data(virq, h->host_data);
+ set_irq_chip_and_handler(virq,
+ &mpc52xx_wkup_gpio_irq_chip,
+ handle_level_irq);
+ return 0;
+}
+
+static int mpc52xx_wkup_gpio_irqhost_xlate(struct irq_host *h,
+ struct device_node *ctrler,
+ const u32 *intspec,
+ unsigned int intsize,
+ irq_hw_number_t *out_hwirq,
+ unsigned int *out_flags)
+{
+ *out_hwirq = intspec[0];
+ *out_flags = intspec[1];
+
+ pr_debug("*** %s intspec %d %d %d out_hwirq %d out_flags %d\n",
+ __func__, intspec[0], intspec[1], intspec[2],
+ (int)*out_hwirq, *out_flags);
+ return 0;
+}
+
+static struct irq_host_ops mpc52xx_wkup_gpio_irq_ops = {
+ .map = mpc52xx_wkup_gpio_irqhost_map,
+ .xlate = mpc52xx_wkup_gpio_irqhost_xlate,
+};
+
+static void __init mpc52xx_add_wkup_gpiochip(struct device_node *np)
{
struct mpc52xx_gpiochip *chip;
struct mpc52xx_gpio_wkup __iomem *regs;
struct of_gpio_chip *ofchip;
- int ret;
+ unsigned int irq;
chip = kzalloc(sizeof(*chip), GFP_KERNEL);
if (!chip)
- return -ENOMEM;
+ goto done;
ofchip = &chip->mmchip.of_gc;
@@ -167,36 +370,56 @@ static int __devinit mpc52xx_wkup_gpiochip_probe(struct of_device *ofdev,
ofchip->gc.get = mpc52xx_wkup_gpio_get;
ofchip->gc.set = mpc52xx_wkup_gpio_set;
- ret = of_mm_gpiochip_add(ofdev->node, &chip->mmchip);
- if (ret)
- return ret;
+ if (of_mm_gpiochip_add(np, &chip->mmchip))
+ goto err_free_chip;
regs = chip->mmchip.regs;
chip->shadow_gpioe = in_8(®s->wkup_gpioe);
chip->shadow_ddr = in_8(®s->wkup_ddr);
chip->shadow_dvo = in_8(®s->wkup_dvo);
- return 0;
-}
+ if (!of_find_property(np, "interrupt-controller", NULL))
+ goto done;
-static int mpc52xx_gpiochip_remove(struct of_device *ofdev)
-{
- return -EBUSY;
-}
+ irq = irq_of_parse_and_map(np, 0);
+ if (irq == NO_IRQ)
+ goto done;
-static const struct of_device_id mpc52xx_wkup_gpiochip_match[] = {
- {
- .compatible = "fsl,mpc5200-gpio-wkup",
- },
- {}
-};
+ pr_debug("%s: irq %d\n", __func__, irq);
-static struct of_platform_driver mpc52xx_wkup_gpiochip_driver = {
- .name = "gpio_wkup",
- .match_table = mpc52xx_wkup_gpiochip_match,
- .probe = mpc52xx_wkup_gpiochip_probe,
- .remove = mpc52xx_gpiochip_remove,
-};
+ chip->irq = irq;
+ chip->irqhost = irq_alloc_host(np, IRQ_HOST_MAP_LINEAR,
+ MPC52XX_WKUP_GPIO_PINS,
+ &mpc52xx_wkup_gpio_irq_ops,
+ MPC52XX_WKUP_GPIO_PINS);
+ if (!chip->irqhost) {
+ pr_err( "%s: irq_alloc_host() failed\n", __func__);
+ goto done;
+ }
+
+ chip->irqhost->host_data = chip;
+ pr_debug("%s: chip %p\n", __func__, chip);
+
+ out_8(®s->wkup_iinten, 0);
+ out_be16(®s->wkup_itype, 0);
+ out_8(®s->wkup_istat, 0xff);
+
+ ofchip->gc.to_irq = mpc52xx_wkup_gpio_to_irq;
+
+ set_irq_data(irq, chip);
+ set_irq_chained_handler(irq, mpc52xx_wkup_gpio_irq_cascade);
+
+ out_8(®s->wkup_maste, 1);
+
+ chip->shadow_iinten = in_8(®s->wkup_iinten);
+ chip->shadow_itype = in_be16(®s->wkup_itype);
+
+done:
+ return;
+
+err_free_chip:
+ kfree(chip);
+}
/*
* GPIO LIB API implementation for simple GPIOs
@@ -307,17 +530,16 @@ mpc52xx_simple_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
return 0;
}
-static int __devinit mpc52xx_simple_gpiochip_probe(struct of_device *ofdev,
- const struct of_device_id *match)
+
+static void __init mpc52xx_add_simple_gpiochip(struct device_node *np)
{
struct mpc52xx_gpiochip *chip;
struct of_gpio_chip *ofchip;
struct mpc52xx_gpio __iomem *regs;
- int ret;
chip = kzalloc(sizeof(*chip), GFP_KERNEL);
if (!chip)
- return -ENOMEM;
+ return;
ofchip = &chip->mmchip.of_gc;
@@ -328,50 +550,34 @@ static int __devinit mpc52xx_simple_gpiochip_probe(struct of_device *ofdev,
ofchip->gc.get = mpc52xx_simple_gpio_get;
ofchip->gc.set = mpc52xx_simple_gpio_set;
- ret = of_mm_gpiochip_add(ofdev->node, &chip->mmchip);
- if (ret)
- return ret;
+ of_mm_gpiochip_add(np, &chip->mmchip);
regs = chip->mmchip.regs;
chip->shadow_gpioe = in_be32(®s->simple_gpioe);
chip->shadow_ddr = in_be32(®s->simple_ddr);
chip->shadow_dvo = in_be32(®s->simple_dvo);
-
- return 0;
}
-static const struct of_device_id mpc52xx_simple_gpiochip_match[] = {
- {
- .compatible = "fsl,mpc5200-gpio",
- },
- {}
-};
-
-static struct of_platform_driver mpc52xx_simple_gpiochip_driver = {
- .name = "gpio",
- .match_table = mpc52xx_simple_gpiochip_match,
- .probe = mpc52xx_simple_gpiochip_probe,
- .remove = mpc52xx_gpiochip_remove,
-};
-
static int __init mpc52xx_gpio_init(void)
{
- if (of_register_platform_driver(&mpc52xx_wkup_gpiochip_driver))
- printk(KERN_ERR "Unable to register wakeup GPIO driver\n");
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "fsl,mpc5200-gpio")
+ mpc52xx_add_simple_gpiochip(np);
- if (of_register_platform_driver(&mpc52xx_simple_gpiochip_driver))
- printk(KERN_ERR "Unable to register simple GPIO driver\n");
+ for_each_compatible_node(np, NULL, "fsl,mpc5200-gpio-wkup")
+ mpc52xx_add_wkup_gpiochip(np);
return 0;
}
-
/* Make sure we get initialised before anyone else tries to use us */
-subsys_initcall(mpc52xx_gpio_init);
+arch_initcall(mpc52xx_gpio_init);
/* No exit call at the moment as we cannot unregister of gpio chips */
MODULE_DESCRIPTION("Freescale MPC52xx gpio driver");
-MODULE_AUTHOR("Sascha Hauer <s.hauer@pengutronix.de");
+MODULE_AUTHOR("Sascha Hauer <s.hauer@pengutronix.de, "
+ "Bill Gatliff <bgat@billgatliff.com>");
MODULE_LICENSE("GPL v2");
--
1.6.5
^ permalink raw reply related
* Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
From: Peter Tyser @ 2009-12-31 1:10 UTC (permalink / raw)
To: Grant Likely; +Cc: u-boot, linuxppc-dev, linux-kbuild
In-Reply-To: <fa686aa40912301601s6cd0ec4y85b88976159a36af@mail.gmail.com>
On Wed, 2009-12-30 at 17:01 -0700, Grant Likely wrote:
> On Wed, Dec 30, 2009 at 4:39 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> > Hi Grant,
> > I put U-Boot ML on CC.
>
> Thinking further, I do actually have another concern, at least with
> regard to the way the current patch set implements things. Is it
> expected or even "recommended" that fit images will *always* contain a
> .dtb image? The current patch only handles the case of a .dtb
> embedded inside the fit image.
I'm not aware of any recommendations as far as what FIT images should
contain and there isn't a requirement that it should contain a .dtb
image - its just a flexible image format.
I believe in the most common FIT usage scenario the image would contain
both a kernel image and .dtb file though. For example, most people I
deal with just have boardX and boardY that they want to boot Linux on.
Currently they have to make a "legacy" uImage, manually run the device
tree compiler with the proper flags to generate a board-specific .dtb
file, transfer the uImage to to boardX, transfer the .dtb file to
boardX, set some U-Boot variables, then boot to Linux. For boardY they
would have to redo the steps with the exception of recreating the legacy
uImage. (To add to the confusion, the format of device trees is a
somewhat moving target, so .dtb files aren't always compatible with
different kernel versions.)
The FIT+.dtb patches I sent make it so the same process is shortened to:
make a FIT image for boardX which contains a .dtb, download it to
boardX, and boot it. Then repeat the same steps for boardY.
> Personally, I don't get any benefit out of the new image format, so I
> haven't spent any time looking at it. However, I'm concerned about
> the drift back towards a different image per target when the move over
> the last 4 years has been towards multiplatform kernel images. I
> certainly don't want to encourage embedding the device tree blob into
> the kernel image, and I'm not very interested in merging code to do
> that into the kernel tree. If someone really needs to do that for
> their particular target, it is certainly easy enough for them to weld
> in the .dtb after the fact before transferring the image to the
> target, but I want that mode to be the exception, not the rule.
I see your point. The main goal of the patch was to introduce FIT image
support as its the new, more flexible, "better", standard image format
for U-Boot going forward. Also, lots people aren't aware of FIT images
and the cool stuff they can do with them, so what better way to get the
word out than getting support for FIT images included in the kernel
proper:)
I think it would be nice to generate a FIT image that contained the
kernel + .dtb as it significantly simplifies the process of booting
Linux for the common case for lots of U-Boot users and showcases one of
the benefits of the FIT format. If you'd prefer not to have this
portion of the patch included, I can respin so that the FIT image
created only contains a kernel image, not a .dtb or initramfs. Or I
could make targets of fitImage (no dtb included), fitImage.<board> (dtb
included), and fitImage.initrd.<board> (dtb and initramfs included).
Either way is fine with me, it'd just be nice to see FIT support get in
in some form.
Thanks,
Peter
^ permalink raw reply
* Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
From: Grant Likely @ 2009-12-31 0:01 UTC (permalink / raw)
To: Peter Tyser; +Cc: u-boot, linuxppc-dev, linux-kbuild
In-Reply-To: <1262216393.29396.41.camel@localhost.localdomain>
On Wed, Dec 30, 2009 at 4:39 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> Hi Grant,
> I put U-Boot ML on CC.
Thinking further, I do actually have another concern, at least with
regard to the way the current patch set implements things. Is it
expected or even "recommended" that fit images will *always* contain a
.dtb image? The current patch only handles the case of a .dtb
embedded inside the fit image.
Personally, I don't get any benefit out of the new image format, so I
haven't spent any time looking at it. However, I'm concerned about
the drift back towards a different image per target when the move over
the last 4 years has been towards multiplatform kernel images. I
certainly don't want to encourage embedding the device tree blob into
the kernel image, and I'm not very interested in merging code to do
that into the kernel tree. If someone really needs to do that for
their particular target, it is certainly easy enough for them to weld
in the .dtb after the fact before transferring the image to the
target, but I want that mode to be the exception, not the rule.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
From: Peter Tyser @ 2009-12-30 23:39 UTC (permalink / raw)
To: Grant Likely; +Cc: u-boot, linuxppc-dev, linux-kbuild
In-Reply-To: <fa686aa40912301502x48785614ya4dd5c71815a7633@mail.gmail.com>
Hi Grant,
I put U-Boot ML on CC.
On Wed, 2009-12-30 at 16:02 -0700, Grant Likely wrote:
> On Mon, Dec 21, 2009 at 6:50 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> > The PowerPC architecture has the ability to embed the ramdisk located
> > at arch/powerpc/boot/ramdisk.image.gz into a bootable kernel image. If
> > the bootable kernel is in the Flattened Image Tree (FIT) format, the
> > ramdisk should be a node in the tree instead of being embedded directly
> > in the kernel executable.
> >
> > A FIT uImage with a ram filesystem can be generated using the command:
> > "make uImage.fit.initrd.<boardname>" where <boardname> is one of
> > arch/powerpc/boot/dts/<boardname>.dts. The command will generate a FIT
> > uImage at arch/powerpc/boot/uImage.fit.initrd.<boardname> that contains
> > a kernel image, device tree blob, and a ram filesystem.
> >
> > The ramdisk at arch/powerpc/boot/ramdisk.image.gz can either be an older
> > style "ramdisk" or a newer "ramfs" gzipped cpio archive.
> >
> > Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > ---
> > Changes since v1:
> > - Don't strip leading 0x from dts ramdisk address
> >
> > arch/powerpc/boot/Makefile | 3 +++
> > arch/powerpc/boot/wrapper | 20 ++++++++++++++++----
> > scripts/mkits.sh | 34 ++++++++++++++++++++++++++++++++--
> > 3 files changed, 51 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> > index e56ec21..c2a6591 100644
> > --- a/arch/powerpc/boot/Makefile
> > +++ b/arch/powerpc/boot/Makefile
> > @@ -313,6 +313,9 @@ $(obj)/uImage: vmlinux $(wrapperbits)
> > $(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> > $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
> >
> > +$(obj)/uImage.fit.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> > + $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
> > +
>
> IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
> Makefile so that make behaves more consistently.
Makes sense.
> Speaking of which,
> the number of '.' in the name is getting rather large. Would you
> consider using 'fitImage' instead of 'uImage.fit'?
Sure, I don't have a strong opinion about the name. I settled on
uImage.fit because all the U-Boot documentation describes the FIT images
as type of uImage. Eg the readme is located in doc/uImage.fit, its
referred to as the "new uImage" format, etc. So using the
"uimage.fit.*" name goes along with the concept that a FIT image is a
type of uImage. A target like fitImage loses the uImage<->FIT
connection.
But I do agree that "."s are a bit overwhelming. I could rework these
patches with your suggested fitImage target name and follow-up with
U-Boot patches to clear up its documentation. In my opinion, there's
not much reason to keep the uImage<->FIT connection that currently
exists in U-Boot. Right now U-Boot documents the "Legacy uImage" and
"FIT uImage" format when logically it would make sense to rename the
formats to "uImage" and "FIT" as there isn't much in common between the
2 formats. The FIT image is just a blob generated by the device tree
compiler, its not tied to U-Boot in any way.
Does anyone in the U-Boot community have an opinion about this? I'm
fine with keeping the uImage.fit naming or using fitImage for this
patch, but I think U-Boot's documentation should be on the same page
either way.
Thanks for the review,
Peter
^ permalink raw reply
* Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
From: Grant Likely @ 2009-12-30 23:02 UTC (permalink / raw)
To: Peter Tyser; +Cc: linuxppc-dev, linux-kbuild
In-Reply-To: <1261446643-21714-4-git-send-email-ptyser@xes-inc.com>
On Mon, Dec 21, 2009 at 6:50 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> The PowerPC architecture has the ability to embed the ramdisk located
> at arch/powerpc/boot/ramdisk.image.gz into a bootable kernel image. =A0If
> the bootable kernel is in the Flattened Image Tree (FIT) format, the
> ramdisk should be a node in the tree instead of being embedded directly
> in the kernel executable.
>
> A FIT uImage with a ram filesystem can be generated using the command:
> "make uImage.fit.initrd.<boardname>" where <boardname> is one of
> arch/powerpc/boot/dts/<boardname>.dts. =A0The command will generate a FIT
> uImage at arch/powerpc/boot/uImage.fit.initrd.<boardname> that contains
> a kernel image, device tree blob, and a ram filesystem.
>
> The ramdisk at arch/powerpc/boot/ramdisk.image.gz can either be an older
> style "ramdisk" or a newer "ramfs" gzipped cpio archive.
>
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
> Changes since v1:
> - Don't strip leading 0x from dts ramdisk address
>
> =A0arch/powerpc/boot/Makefile | =A0 =A03 +++
> =A0arch/powerpc/boot/wrapper =A0| =A0 20 ++++++++++++++++----
> =A0scripts/mkits.sh =A0 =A0 =A0 =A0 =A0 | =A0 34 ++++++++++++++++++++++++=
++++++++--
> =A03 files changed, 51 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index e56ec21..c2a6591 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -313,6 +313,9 @@ $(obj)/uImage: vmlinux $(wrapperbits)
> =A0$(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> =A0 =A0 =A0 =A0$(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
>
> +$(obj)/uImage.fit.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> + =A0 =A0 =A0 $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb,$(obj)/ramd=
isk.image.gz)
> +
IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
Makefile so that make behaves more consistently. Speaking of which,
the number of '.' in the name is getting rather large. Would you
consider using 'fitImage' instead of 'uImage.fit'?
g.
^ permalink raw reply
* Re: [PATCH v2 2/3] powerpc: Add support for creating FIT uImages
From: Grant Likely @ 2009-12-30 22:57 UTC (permalink / raw)
To: Peter Tyser; +Cc: linuxppc-dev, linux-kbuild
In-Reply-To: <1261446643-21714-3-git-send-email-ptyser@xes-inc.com>
On Mon, Dec 21, 2009 at 6:50 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> Recent U-Boot versions support booting a Flattened Image Tree (FIT)
> image format. =A0The FIT uImage format uses a tree structure to describe =
a
> kernel image as well as supporting device tree blobs, ramdisks, etc.
> The 'mkimage' and 'dtc' utilities convert this tree description into a
> binary blob that bootloaders such as U-Boot can execute.
>
> This patch adds support for automatically creating a U-Boot FIT image
> using the "make uImage.fit.<boardname>" command where <boardname> is
> one of arch/powerpc/boot/dts/<boardname>.dts. =A0The resulting
> arch/powerpc/boot/uImage.fit.<boardname> file will contain a kernel
> image as well as a device tree blob. =A0U-Boot versions compiled with FIT
> support can directly boot this image using the "bootm" command.
>
> Additional information about the FIT format and its uses can be found in
> doc/uImage.FIT/howto.txt of U-Boot's source tree.
>
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
> Changes since v1:
> - Add 'dts-v1' header to scripts/mkits.sh output
> - Don't strip leading 0x from dts addresses
> - Default to using kernel dtc if the user doesn't have it in their path
I think I need to NAK this one. As it is, the wrapper script is a
moderately complex thing, but it has to do a non-trivial job: create a
custom linked executable that sets up the environment that the kernel
expects. zImage.* wrappers uncompress the kernel, dtbImage.* wrappers
also contain a .dtb image. cuImage.* wrappers adapt to the old u-boot
interface, etc.
Unfortunately, the wrapper script is also being used to do things that
are completely unrelated to creating wrapper binaries. FIT images
(and uImages) don't use any of the wrapper bits at all. In fact, as
seen in this patch, generating them involves bailing out of the
wrapper script early to avoid linking the wrapper bits. I think for
all types of uImages, the wrapper script is being misused and I don't
like the extra complexity that it adds.
Rather than adding new paths to arch/powerpc/boot/wrapper, I would
rather see a new script used for generating FIT image that isn't
complicated by all the current wrapper cruft. Also, the Makefile rule
doesn't need to depend on $(wrapperbits) which means faster build
times when only building uImages.
Bonus points if you also convert the uImage target to use the new
script; but I'm not demanding that you do that yet.
Finally, you need to add documentation about the new target to
Documentation/powerpc/bootwrapper.txt.
g.
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index bb2465b..e56ec21 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -310,6 +310,9 @@ $(obj)/zImage.iseries: vmlinux
> =A0$(obj)/uImage: vmlinux $(wrapperbits)
> =A0 =A0 =A0 =A0$(call if_changed,wrap,uboot)
>
> +$(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> + =A0 =A0 =A0 $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
> +
> =A0$(obj)/cuImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> =A0 =A0 =A0 =A0$(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb,$(obj)/ram=
disk.image.gz)
>
> @@ -349,7 +352,7 @@ install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y)=
)
>
> =A0# anything not in $(targets)
> =A0clean-files +=3D $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.*=
\
> - =A0 =A0 =A0 zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
> + =A0 =A0 =A0 uImage.* zImage zImage.initrd zImage.chrp zImage.coff zImag=
e.holly \
> =A0 =A0 =A0 =A0zImage.iseries zImage.miboot zImage.pmac zImage.pseries \
> =A0 =A0 =A0 =A0simpleImage.* otheros.bld *.dtb
>
> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> index f4594ed..1f35b66 100755
> --- a/arch/powerpc/boot/wrapper
> +++ b/arch/powerpc/boot/wrapper
> @@ -46,6 +46,9 @@ CROSS=3D
> =A0# mkimage wrapper script
> =A0MKIMAGE=3D$srctree/scripts/mkuboot.sh
>
> +# script to generate an .its file for uImage.fit.* images
> +MKITS=3D$srctree/scripts/mkits.sh
> +
> =A0# directory for object and other files used by this script
> =A0object=3Darch/powerpc/boot
> =A0objbin=3D$object
> @@ -157,7 +160,7 @@ coff)
> =A0 =A0 lds=3D$object/zImage.coff.lds
> =A0 =A0 link_address=3D'0x500000'
> =A0 =A0 ;;
> -miboot|uboot)
> +miboot|uboot|uboot.fit)
> =A0 =A0 # miboot and U-boot want just the bare bits, not an ELF binary
> =A0 =A0 ext=3Dbin
> =A0 =A0 objflags=3D"-O binary"
> @@ -277,6 +280,21 @@ uboot)
> =A0 =A0 fi
> =A0 =A0 exit 0
> =A0 =A0 ;;
> +uboot.fit)
> + =A0 =A0rm -f "$ofile"
> + =A0 =A0${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
> + =A0 =A0 =A0 -d "$srctree/$dtb" -k "$srctree/$vmz" -o "$object/uImage.it=
s"
> +
> + =A0 =A0# mkimage calls dtc for FIT images so use kernel dtc if necessar=
y
> + =A0 =A0export PATH=3D$PATH:$srctree/scripts/dtc
> +
> + =A0 =A0${MKIMAGE} -f "$object/uImage.its" "$ofile"
> + =A0 =A0rm "$object/uImage.its"
> + =A0 =A0if [ -z "$cacheit" ]; then
> + =A0 =A0 =A0 rm -f "$vmz"
> + =A0 =A0fi
> + =A0 =A0exit 0
> + =A0 =A0;;
> =A0esac
>
> =A0addsec() {
> diff --git a/scripts/mkits.sh b/scripts/mkits.sh
> new file mode 100755
> index 0000000..fae43dd
> --- /dev/null
> +++ b/scripts/mkits.sh
> @@ -0,0 +1,111 @@
> +#!/bin/bash
> +#
> +# Licensed under the terms of the GNU GPL License version 2 or later.
> +#
> +# Author: Peter Tyser <ptyser@xes-inc.com>
> +#
> +# U-Boot firmware supports the booting of images in the Flattened Image
> +# Tree (FIT) format. =A0The FIT format uses a device tree structure to
> +# describe a kernel image, device tree blob, ramdisk, etc. =A0This scrip=
t
> +# creates an Image Tree Source (.its file) which can be passed to the
> +# 'mkimage' utility to generate an Image Tree Blob (.itb file). =A0The .=
itb
> +# file can then be booted by U-Boot (or other bootloaders which support
> +# FIT images). =A0See doc/uImage.FIT/howto.txt in U-Boot source code for
> +# additional information on FIT images.
> +#
> +
> +usage() {
> + =A0 =A0 =A0 echo "Usage: `basename $0` -A arch -C comp -a addr -e entry=
" \
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 "-v version -k kernel [-d dtb] -o its_file"
> + =A0 =A0 =A0 echo -e "\t-A =3D=3D> set architecture to 'arch'"
> + =A0 =A0 =A0 echo -e "\t-C =3D=3D> set compression type 'comp'"
> + =A0 =A0 =A0 echo -e "\t-a =3D=3D> set load address to 'addr' (hex)"
> + =A0 =A0 =A0 echo -e "\t-e =3D=3D> set entry point to 'entry' (hex)"
> + =A0 =A0 =A0 echo -e "\t-v =3D=3D> set kernel version to 'version'"
> + =A0 =A0 =A0 echo -e "\t-k =3D=3D> include kernel image 'kernel'"
> + =A0 =A0 =A0 echo -e "\t-d =3D=3D> include Device Tree Blob 'dtb'"
> + =A0 =A0 =A0 echo -e "\t-o =3D=3D> create output file 'its_file'"
> + =A0 =A0 =A0 exit 1
> +}
> +
> +while getopts ":A:C:a:d:e:k:o:v:" OPTION
> +do
> + =A0 =A0 =A0 case $OPTION in
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 A ) ARCH=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 C ) COMPRESS=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 a ) LOAD_ADDR=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 d ) DTB=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 e ) ENTRY_ADDR=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 k ) KERNEL=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 o ) OUTPUT=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 v ) VERSION=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 * ) echo "Invalid option passed to '$0' (op=
tions:$@)"
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 usage;;
> + =A0 =A0 =A0 esac
> +done
> +
> +# Make sure user entered all required parameters
> +if [ -z "${ARCH}" ] || [ -z "${COMPRESS}" ] || [ -z "${LOAD_ADDR}" ] || =
\
> + =A0 =A0 =A0 [ -z "${ENTRY_ADDR}" ] || [ -z "${VERSION}" ] || [ -z "${KE=
RNEL}" ] || \
> + =A0 =A0 =A0 [ -z "${OUTPUT}" ]; then
> + =A0 =A0 =A0 usage
> +fi
> +
> +# Create a default, fully populated DTS file
> +DATA=3D"/dts-v1/;
> +
> +/ {
> + =A0 =A0 =A0 description =3D \"Linux kernel ${VERSION}\";
> + =A0 =A0 =A0 #address-cells =3D <1>;
> +
> + =A0 =A0 =A0 images {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 kernel@1 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 description =3D \"Linux Ker=
nel ${VERSION}\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 data =3D /incbin/(\"${KERNE=
L}\");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type =3D \"kernel\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 arch =3D \"${ARCH}\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 os =3D \"linux\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compression =3D \"${COMPRES=
S}\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 load =3D <${LOAD_ADDR}>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 entry =3D <${ENTRY_ADDR}>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hash@1 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algo =3D \"=
crc32\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hash@2 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algo =3D \"=
sha1\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 fdt@1 { /* start fdt */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 description =3D \"Flattened=
Device Tree blob\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 data =3D /incbin/(\"${DTB}\=
");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type =3D \"flat_dt\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 arch =3D \"${ARCH}\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compression =3D \"none\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hash@1 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algo =3D \"=
crc32\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hash@2 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algo =3D \"=
sha1\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }; /* end fdt */
> +
> + =A0 =A0 =A0 configurations {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 default =3D \"config@1\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 config@1 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 description =3D \"Default L=
inux kernel\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 kernel =3D \"kernel@1\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fdt =3D \"fdt@1\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ramdisk =3D \"ramdisk@1\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 };
> +};"
> +
> +# Conditionally strip fdt information out of tree
> +if [ -z "${DTB}" ]; then
> + =A0 =A0 =A0 DATA=3D`echo "$DATA" | sed '/start fdt/,/end fdt/d'`
> + =A0 =A0 =A0 DATA=3D`echo "$DATA" | sed '/fdt/d'`
> +fi
> +
> +# Write .its file to disk
> +echo "$DATA" > ${OUTPUT}
> --
> 1.6.2.1
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2 1/3] powerpc: Use scripts/mkuboot.sh instead of 'mkimage'
From: Grant Likely @ 2009-12-30 22:25 UTC (permalink / raw)
To: Peter Tyser; +Cc: linuxppc-dev, linux-kbuild
In-Reply-To: <1261446643-21714-2-git-send-email-ptyser@xes-inc.com>
On Mon, Dec 21, 2009 at 6:50 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> mkuboot.sh provides a basic wrapper for the 'mkimage' utility. =A0Using
> mkuboot.sh provides clearer error reporting and allows a toolchain to
> use its own 'mkimage' executable specified by ${CROSS_COMPILE}mkimage.
> Additionally, this brings PowerPC in line with other architectures
> which already call mkimage via mkuboot.sh.
>
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Okay by me. I've picked this one up.
g.
> ---
> =A0arch/powerpc/boot/wrapper | =A0 =A07 +++++--
> =A01 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> index 390512a..f4594ed 100755
> --- a/arch/powerpc/boot/wrapper
> +++ b/arch/powerpc/boot/wrapper
> @@ -43,6 +43,9 @@ gzip=3D.gz
> =A0# cross-compilation prefix
> =A0CROSS=3D
>
> +# mkimage wrapper script
> +MKIMAGE=3D$srctree/scripts/mkuboot.sh
> +
> =A0# directory for object and other files used by this script
> =A0object=3Darch/powerpc/boot
> =A0objbin=3D$object
> @@ -267,7 +270,7 @@ membase=3D`${CROSS}objdump -p "$kernel" | grep -m 1 L=
OAD | awk '{print $7}'`
> =A0case "$platform" in
> =A0uboot)
> =A0 =A0 rm -f "$ofile"
> - =A0 =A0mkimage -A ppc -O linux -T kernel -C gzip -a $membase -e $membas=
e \
> + =A0 =A0${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a $membase -e $mem=
base \
> =A0 =A0 =A0 =A0$uboot_version -d "$vmz" "$ofile"
> =A0 =A0 if [ -z "$cacheit" ]; then
> =A0 =A0 =A0 =A0rm -f "$vmz"
> @@ -327,7 +330,7 @@ coff)
> =A0 =A0 ;;
> =A0cuboot*)
> =A0 =A0 gzip -f -9 "$ofile"
> - =A0 =A0mkimage -A ppc -O linux -T kernel -C gzip -a "$base" -e "$entry"=
\
> + =A0 =A0${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a "$base" -e "$ent=
ry" \
> =A0 =A0 =A0 =A0 =A0 =A0 $uboot_version -d "$ofile".gz "$ofile"
> =A0 =A0 ;;
> =A0treeboot*)
> --
> 1.6.2.1
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] arch/powerpc/boot/devtree.c: use %pM to show MAC address
From: H Hartley Sweeten @ 2009-12-30 19:30 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Use the %pM kernel extension to display the MAC address.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
---
diff --git a/arch/powerpc/boot/devtree.c b/arch/powerpc/boot/devtree.c
index a7e21a3..a2f07a5 100644
--- a/arch/powerpc/boot/devtree.c
+++ b/arch/powerpc/boot/devtree.c
@@ -93,10 +93,7 @@ void dt_fixup_mac_address_by_alias(const char *alias, =
const u8 *addr)
void *devp =3D find_node_by_alias(alias);
=20
if (devp) {
- printf("%s: local-mac-address <-"
- " %02x:%02x:%02x:%02x:%02x:%02x\n\r", alias,
- addr[0], addr[1], addr[2],
- addr[3], addr[4], addr[5]);
+ printf("%s: local-mac-address <- %pM\n\r", alias, addr);
=20
setprop(devp, "local-mac-address", addr, 6);
}
@@ -108,10 +105,7 @@ void dt_fixup_mac_address(u32 index, const u8 =
*addr)
(void*)&index, sizeof(index));
=20
if (devp) {
- printf("ENET%d: local-mac-address <-"
- " %02x:%02x:%02x:%02x:%02x:%02x\n\r", index,
- addr[0], addr[1], addr[2],
- addr[3], addr[4], addr[5]);
+ printf("ENET%d: local-mac-address <- %pM\n\r", index, addr);
=20
setprop(devp, "local-mac-address", addr, 6);
}=20
^ permalink raw reply related
* Re: FSL UPM NAND driver for linux 2.6.24
From: Anton Vorontsov @ 2009-12-30 18:35 UTC (permalink / raw)
To: nanda; +Cc: linuxppc-dev
In-Reply-To: <20091230083656.51308.qmail@f5mail-237-241.rediffmail.com>
On Wed, Dec 30, 2009 at 08:36:56AM -0000, nanda wrote:
> Hi,
> I am looking for freescale NAND driver in the kernel 2.6.24
> (which implement UPM based technique). Can anyone point us the
> patch which is available for the same?
There is drivers/mtd/nand/fsl_upm.c in the mainline kernel
(it's there since 2.6.26, IIRC).
Or are you looking for the ready to use back-port of that
driver? I don't have one, but it should be relatively easiy
to back-port.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH 4/4] fsl_pq_mdio: Fix iomem unmapping for non-eTSEC2.0 controllers
From: Anton Vorontsov @ 2009-12-30 18:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andy Fleming, linuxppc-dev
In-Reply-To: <20091230182146.GA4515@oksana.dev.rtsoft.ru>
We use a rather complicated logic to support eTSEC and eTSEC2.0
registers maps in a single driver. Currently, the code tries to
unmap 'regs', but for non-eTSEC2.0 controllers 'regs' doesn't
point to a mapping start, and this might cause badness on probe
failure or module removal:
Freescale PowerQUICC MII Bus: probed
Trying to vfree() nonexistent vm area (e107f000)
------------[ cut here ]------------
Badness at c00a7754 [verbose debug info unavailable]
NIP: c00a7754 LR: c00a7754 CTR: c02231ec
[...]
NIP [c00a7754] __vunmap+0xec/0xf4
LR [c00a7754] __vunmap+0xec/0xf4
Call Trace:
[df827e50] [c00a7754] __vunmap+0xec/0xf4 (unreliable)
[df827e70] [c001519c] iounmap+0x44/0x54
[df827e80] [c028b924] fsl_pq_mdio_probe+0x1cc/0x2fc
[df827eb0] [c02fb9b4] of_platform_device_probe+0x5c/0x84
[df827ed0] [c0229928] really_probe+0x78/0x1a8
[df827ef0] [c0229b20] __driver_attach+0xa4/0xa8
Fix this by introducing a proper priv structure (finally!), which
now holds 'regs' and 'map' fields separately.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/fsl_pq_mdio.c | 30 +++++++++++++++++++++++-------
1 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/net/fsl_pq_mdio.c b/drivers/net/fsl_pq_mdio.c
index 25fabb3..d5160ed 100644
--- a/drivers/net/fsl_pq_mdio.c
+++ b/drivers/net/fsl_pq_mdio.c
@@ -46,6 +46,11 @@
#include "gianfar.h"
#include "fsl_pq_mdio.h"
+struct fsl_pq_mdio_priv {
+ void __iomem *map;
+ struct fsl_pq_mdio __iomem *regs;
+};
+
/*
* Write value to the PHY at mii_id at register regnum,
* on the bus attached to the local interface, which may be different from the
@@ -105,7 +110,9 @@ int fsl_pq_local_mdio_read(struct fsl_pq_mdio __iomem *regs,
static struct fsl_pq_mdio __iomem *fsl_pq_mdio_get_regs(struct mii_bus *bus)
{
- return (void __iomem __force *)bus->priv;
+ struct fsl_pq_mdio_priv *priv = bus->priv;
+
+ return priv->regs;
}
/*
@@ -266,6 +273,7 @@ static int fsl_pq_mdio_probe(struct of_device *ofdev,
{
struct device_node *np = ofdev->node;
struct device_node *tbi;
+ struct fsl_pq_mdio_priv *priv;
struct fsl_pq_mdio __iomem *regs = NULL;
void __iomem *map;
u32 __iomem *tbipa;
@@ -274,14 +282,19 @@ static int fsl_pq_mdio_probe(struct of_device *ofdev,
u64 addr = 0, size = 0;
int err = 0;
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
new_bus = mdiobus_alloc();
if (NULL == new_bus)
- return -ENOMEM;
+ goto err_free_priv;
new_bus->name = "Freescale PowerQUICC MII Bus",
new_bus->read = &fsl_pq_mdio_read,
new_bus->write = &fsl_pq_mdio_write,
new_bus->reset = &fsl_pq_mdio_reset,
+ new_bus->priv = priv;
fsl_pq_mdio_bus_name(new_bus->id, np);
/* Set the PHY base address */
@@ -291,6 +304,7 @@ static int fsl_pq_mdio_probe(struct of_device *ofdev,
err = -ENOMEM;
goto err_free_bus;
}
+ priv->map = map;
if (of_device_is_compatible(np, "fsl,gianfar-mdio") ||
of_device_is_compatible(np, "fsl,gianfar-tbi") ||
@@ -298,8 +312,7 @@ static int fsl_pq_mdio_probe(struct of_device *ofdev,
of_device_is_compatible(np, "ucc_geth_phy"))
map -= offsetof(struct fsl_pq_mdio, miimcfg);
regs = map;
-
- new_bus->priv = (void __force *)regs;
+ priv->regs = regs;
new_bus->irq = kcalloc(PHY_MAX_ADDR, sizeof(int), GFP_KERNEL);
@@ -392,10 +405,11 @@ static int fsl_pq_mdio_probe(struct of_device *ofdev,
err_free_irqs:
kfree(new_bus->irq);
err_unmap_regs:
- iounmap(regs);
+ iounmap(priv->map);
err_free_bus:
kfree(new_bus);
-
+err_free_priv:
+ kfree(priv);
return err;
}
@@ -404,14 +418,16 @@ static int fsl_pq_mdio_remove(struct of_device *ofdev)
{
struct device *device = &ofdev->dev;
struct mii_bus *bus = dev_get_drvdata(device);
+ struct fsl_pq_mdio_priv *priv = bus->priv;
mdiobus_unregister(bus);
dev_set_drvdata(device, NULL);
- iounmap(fsl_pq_mdio_get_regs(bus));
+ iounmap(priv->map);
bus->priv = NULL;
mdiobus_free(bus);
+ kfree(priv);
return 0;
}
--
1.6.5.7
^ permalink raw reply related
* [PATCH 3/4] ucc_geth: Fix netdev watchdog triggering on suspend
From: Anton Vorontsov @ 2009-12-30 18:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andy Fleming, linuxppc-dev
In-Reply-To: <20091230182146.GA4515@oksana.dev.rtsoft.ru>
Sometimes ucc_geth fails to suspend with the following trace:
ucc_geth e0103000.ucc: suspend
ucc_geth e0102000.ucc: suspend
NETDEV WATCHDOG: eth0 (ucc_geth): transmit queue 0 timed out
------------[ cut here ]------------
Badness at net/sched/sch_generic.c:255
NIP: c021cb5c LR: c021cb5c CTR: c01ab4b4
[...]
NIP [c021cb5c] dev_watchdog+0x298/0x2a8
LR [c021cb5c] dev_watchdog+0x298/0x2a8
Call Trace:
[c0389da0] [c021cb5c] dev_watchdog+0x298/0x2a8 (unreliable)
[c0389e00] [c0031ed8] run_timer_softirq+0x16c/0x1dc
[c0389e50] [c002c638] __do_softirq+0xa4/0x11c
[...]
This patch fixes the issue by properly detaching the device on
suspend, and attaching it back on resume.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 41ad2f3..96bdc0b 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3607,6 +3607,7 @@ static int ucc_geth_suspend(struct of_device *ofdev, pm_message_t state)
if (!netif_running(ndev))
return 0;
+ netif_device_detach(ndev);
napi_disable(&ugeth->napi);
/*
@@ -3665,7 +3666,7 @@ static int ucc_geth_resume(struct of_device *ofdev)
phy_start(ugeth->phydev);
napi_enable(&ugeth->napi);
- netif_start_queue(ndev);
+ netif_device_attach(ndev);
return 0;
}
--
1.6.5.7
^ permalink raw reply related
* [PATCH 2/4] phylib: Properly reinitialize PHYs after hibernation
From: Anton Vorontsov @ 2009-12-30 18:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andy Fleming, linuxppc-dev
In-Reply-To: <20091230182146.GA4515@oksana.dev.rtsoft.ru>
Since hibernation assumes power loss, we should fully reinitialize
PHYs (including platform fixups), as if PHYs were just attached.
This patch factors phy_init_hw() out of phy_attach_direct(), then
converts mdio_bus to dev_pm_ops and adds an appropriate restore()
callback.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/phy/mdio_bus.c | 50 ++++++++++++++++++++++++++++++++++++------
drivers/net/phy/phy_device.c | 30 ++++++++++++------------
include/linux/phy.h | 1 +
3 files changed, 59 insertions(+), 22 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 49252d3..e17b702 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -264,6 +264,8 @@ static int mdio_bus_match(struct device *dev, struct device_driver *drv)
(phydev->phy_id & phydrv->phy_id_mask));
}
+#ifdef CONFIG_PM
+
static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
{
struct device_driver *drv = phydev->dev.driver;
@@ -295,10 +297,7 @@ static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
return true;
}
-/* Suspend and resume. Copied from platform_suspend and
- * platform_resume
- */
-static int mdio_bus_suspend(struct device * dev, pm_message_t state)
+static int mdio_bus_suspend(struct device *dev)
{
struct phy_driver *phydrv = to_phy_driver(dev->driver);
struct phy_device *phydev = to_phy_device(dev);
@@ -318,7 +317,7 @@ static int mdio_bus_suspend(struct device * dev, pm_message_t state)
return phydrv->suspend(phydev);
}
-static int mdio_bus_resume(struct device * dev)
+static int mdio_bus_resume(struct device *dev)
{
struct phy_driver *phydrv = to_phy_driver(dev->driver);
struct phy_device *phydev = to_phy_device(dev);
@@ -338,11 +337,48 @@ no_resume:
return 0;
}
+static int mdio_bus_restore(struct device *dev)
+{
+ struct phy_device *phydev = to_phy_device(dev);
+ struct net_device *netdev = phydev->attached_dev;
+ int ret;
+
+ if (!netdev)
+ return 0;
+
+ ret = phy_init_hw(phydev);
+ if (ret < 0)
+ return ret;
+
+ /* The PHY needs to renegotiate. */
+ phydev->link = 0;
+ phydev->state = PHY_UP;
+
+ phy_start_machine(phydev, NULL);
+
+ return 0;
+}
+
+static struct dev_pm_ops mdio_bus_pm_ops = {
+ .suspend = mdio_bus_suspend,
+ .resume = mdio_bus_resume,
+ .freeze = mdio_bus_suspend,
+ .thaw = mdio_bus_resume,
+ .restore = mdio_bus_restore,
+};
+
+#define MDIO_BUS_PM_OPS (&mdio_bus_pm_ops)
+
+#else
+
+#define MDIO_BUS_PM_OPS NULL
+
+#endif /* CONFIG_PM */
+
struct bus_type mdio_bus_type = {
.name = "mdio_bus",
.match = mdio_bus_match,
- .suspend = mdio_bus_suspend,
- .resume = mdio_bus_resume,
+ .pm = MDIO_BUS_PM_OPS,
};
EXPORT_SYMBOL(mdio_bus_type);
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index b10fedd..8212b2b 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -378,6 +378,20 @@ void phy_disconnect(struct phy_device *phydev)
}
EXPORT_SYMBOL(phy_disconnect);
+int phy_init_hw(struct phy_device *phydev)
+{
+ int ret;
+
+ if (!phydev->drv || !phydev->drv->config_init)
+ return 0;
+
+ ret = phy_scan_fixups(phydev);
+ if (ret < 0)
+ return ret;
+
+ return phydev->drv->config_init(phydev);
+}
+
/**
* phy_attach_direct - attach a network device to a given PHY device pointer
* @dev: network device to attach
@@ -425,21 +439,7 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
/* Do initial configuration here, now that
* we have certain key parameters
* (dev_flags and interface) */
- if (phydev->drv->config_init) {
- int err;
-
- err = phy_scan_fixups(phydev);
-
- if (err < 0)
- return err;
-
- err = phydev->drv->config_init(phydev);
-
- if (err < 0)
- return err;
- }
-
- return 0;
+ return phy_init_hw(phydev);
}
EXPORT_SYMBOL(phy_attach_direct);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index b1368b8..7968def 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -447,6 +447,7 @@ struct phy_device* get_phy_device(struct mii_bus *bus, int addr);
int phy_device_register(struct phy_device *phy);
int phy_clear_interrupt(struct phy_device *phydev);
int phy_config_interrupt(struct phy_device *phydev, u32 interrupts);
+int phy_init_hw(struct phy_device *phydev);
int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
u32 flags, phy_interface_t interface);
struct phy_device * phy_attach(struct net_device *dev,
--
1.6.5.7
^ permalink raw reply related
* [PATCH 1/4] phylib: Fix deadlock on resume
From: Anton Vorontsov @ 2009-12-30 18:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andy Fleming, linuxppc-dev
In-Reply-To: <20091230182146.GA4515@oksana.dev.rtsoft.ru>
Sometimes kernel hangs on resume with the following trace:
ucc_geth e0102000.ucc: resume
INFO: task bash:1764 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
bash D 0fecf43c 0 1764 1763 0x00000000
Call Trace:
[cf9a7c10] [c0012868] ret_from_except+0x0/0x14 (unreliable)
--- Exception: cf9a7ce0 at __switch_to+0x4c/0x6c
LR = 0xcf9a7cc0
[cf9a7cd0] [c0008c14] __switch_to+0x4c/0x6c (unreliable)
[cf9a7ce0] [c028bcfc] schedule+0x158/0x260
[cf9a7d10] [c028c720] __mutex_lock_slowpath+0x80/0xd8
[cf9a7d40] [c01cf388] phy_stop+0x20/0x70
[cf9a7d50] [c01d514c] ugeth_resume+0x6c/0x13c
[...]
Here is why.
On suspend:
- PM core starts suspending devices, ucc_geth_suspend gets called;
- ucc_geth calls phy_stop() on suspend. Note that phy_stop() is
mostly asynchronous so it doesn't block ucc_geth's suspend routine,
it just sets PHY_HALTED state and disables PHY's interrupts;
- Suddenly the state machine gets scheduled, it grabs the phydev->lock
mutex and tries to process the PHY_HALTED state, so it calls
phydev->adjust_link(phydev->attached_dev). In ucc_geth case
adjust_link() calls msleep(), which reschedules the code flow back to
PM core, which now finishes suspend and so we end up sleeping with
phydev->lock mutex held.
On resume:
- PM core starts resuming devices (notice that nobody rescheduled
the state machine yet, so the mutex is still held), the core calls
ucc_geth's resume routine;
- ucc_geth_resume restarts the PHY with phy_stop()/phy_start()
sequence, and the phy_*() calls are trying to grab the phydev->lock
mutex. Here comes the deadlock.
This patch fixes the issue by stopping the state machine on suspend
and starting it again on resume.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/phy/mdio_bus.c | 24 ++++++++++++++++++++++--
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index bd4e8d7..49252d3 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -303,8 +303,18 @@ static int mdio_bus_suspend(struct device * dev, pm_message_t state)
struct phy_driver *phydrv = to_phy_driver(dev->driver);
struct phy_device *phydev = to_phy_device(dev);
+ /*
+ * We must stop the state machine manually, otherwise it stops out of
+ * control, possibly with the phydev->lock held. Upon resume, netdev
+ * may call phy routines that try to grab the same lock, and that may
+ * lead to a deadlock.
+ */
+ if (phydev->attached_dev)
+ phy_stop_machine(phydev);
+
if (!mdio_bus_phy_may_suspend(phydev))
return 0;
+
return phydrv->suspend(phydev);
}
@@ -312,10 +322,20 @@ static int mdio_bus_resume(struct device * dev)
{
struct phy_driver *phydrv = to_phy_driver(dev->driver);
struct phy_device *phydev = to_phy_device(dev);
+ int ret;
if (!mdio_bus_phy_may_suspend(phydev))
- return 0;
- return phydrv->resume(phydev);
+ goto no_resume;
+
+ ret = phydrv->resume(phydev);
+ if (ret < 0)
+ return ret;
+
+no_resume:
+ if (phydev->attached_dev)
+ phy_start_machine(phydev, NULL);
+
+ return 0;
}
struct bus_type mdio_bus_type = {
--
1.6.5.7
^ permalink raw reply related
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