* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Benjamin Herrenschmidt @ 2009-07-16 1:56 UTC (permalink / raw)
To: michael
Cc: Linux-Arch, Nick Piggin, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management
In-Reply-To: <1247708177.9851.4.camel@concordia>
On Thu, 2009-07-16 at 11:36 +1000, Michael Ellerman wrote:
>
> Builds for the important architectures, powerpc, ia64, arm, sparc,
> sparc64, oh and x86:
>
> http://kisskb.ellerman.id.au/kisskb/head/1976/
>
> (based on your test branch 34f25476)
Note for all lurkers: the fails in there are unrelated to the patch
(mostly warnings triggering our new Werror and probably mostly fixed
upstream already).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 04/15] swiotlb: remove unnecessary swiotlb_bus_to_virt
From: Benjamin Herrenschmidt @ 2009-07-16 3:40 UTC (permalink / raw)
To: Becky Bruce
Cc: tony.luck, linux-ia64, x86, linux-kernel, FUJITA Tomonori,
linuxppc-dev
In-Reply-To: <5E909C02-3FA2-4BEB-8C73-F4E4A5A404BF@kernel.crashing.org>
On Mon, 2009-07-13 at 21:17 -0500, Becky Bruce wrote:
>
> phys_to_virt (also, virt_to_phys) is invalid for highmem addresses on
> ppc.
I would be surprised if x86 was any different here. Most of our highmem
implementation comes straight from x86 :-)
Cheers,
Ben.
^ permalink raw reply
* Re: ethernet driver - problem capturing own packet in promiscous mode
From: sudheer a @ 2009-07-16 4:07 UTC (permalink / raw)
To: Cote, Sylvain; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <579B119545DAEF4689C8FBEEFEC5793F01D4FF0A202C@ATLMBX.verint.corp.verintsystems.com>
[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]
On Wed, Jul 15, 2009 at 5:52 PM, Cote, Sylvain <Sylvain.Cote@verint.com>wrote:
> > Hi all
>
>
>
> > In ethernet driver i need to enable promiscous mode and have to capture
> the packet that is sent by the same ethernet.
>
>
>
> > The board is connected to a packet generator and could send/receive
> packets whenever i need .
>
>
>
> > In the board ethernet driver , I made sure that am sending only
> broadcast packets and promisc mode is enabled but the packets are not
> captured. If i am sending a packet to the board from packetgenerator it is
> receiving.
>
>
>
> > Could any one please suggest me any clues.
>
>
>
> > Having the promisc enabled:
>
> > Packet sent by packetgenerator is received by board.
>
> > Packet sent by board is received by packetgenerator, The same packet
> should be captured by board as promiscuous is enabled. but not happening.
>
>
>
>
>
> The Ethernet interface that sent the packet will never receive the packet
> it sent even if you are in promiscuous mode. To be able to do that you
> should put your interface in loopback mode.
>
> In promiscuous mode, you will be able to receive any packets sent by other
> interfaces (broadcast, multicast and also unicast that is not directed to
> you interface MAC address). But not
>
> from your interface.
>
Thanks for your inputs Sylvain.
I tried with loopback, it is working.
But during the time the hardware is in lopback mode, it may miss some rx
packets coming from outside or packet generator unfortunately and i dont
want it to happen.
Please let me know your views and suggestions.
Thanks
Sudheer
[-- Attachment #2: Type: text/html, Size: 4319 bytes --]
^ permalink raw reply
* Re: booting MPC8313 based board with yaffs2 RFS
From: Rupesh Kumar @ 2009-07-16 5:22 UTC (permalink / raw)
To: tonyliu; +Cc: linuxppc-dev
In-Reply-To: <4A5FDCDF.9010005@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]
Hi
Thanks for reply.
After erasing one of the flash partition, i mounted it as yaffs2 and
manually created rootfs there.
Though it (careting RFS in NAND partiton) marked blocks bad, I am able to
boot with this yaffs2 filesystem.
When image is created with mkyffs2image binary, board does not boot with
that and says kernel panic.
1. What nand flash is on-board? what's the size of the nand flash page
size, 512/2048?
Nand Flash used on board is K9F2G08U0M-P from Samsung and page size is
2048.
2. what's the version of mkyaffs2image you are using?
mkyaffs2image: image building tool for YAFFS2 built Jan 31 2009
3. Can you mount an empty nand flash partition using yaffs2 type,
mount /dev/mtdblock##x xxx
Yes, i wrote RFS contents to the nand flash partition and booted with
that.
4. It's better to attatch bootup message.
Bootup message is attached for both conditions
1) booting with manually created RFS on flash drive mounted as
yaffs2(boot-up_manual_RFS.txt).
2) booting with yaffs2 image created by mkyaffs2image tool.
Note :- below are steps used for writing RFS iamge
~ # flash_eraseall /dev/mtd11
~ # nandwrite -a -o /dev/mtd11 rootrfs_1.yaffs2
Thanks
Rupesh
tonyliu <Bo.Liu@windriver.com>
07/17/2009 07:37 AM
To
Rupesh Kumar <Rupesh.Kumar@Lntemsys.com>
cc
linuxppc-dev@lists.ozlabs.org
Subject
Re: booting MPC8313 based board with yaffs2 RFS
Rupesh Kumar wrote:
> Hi
> I am using MPC8313 board which is currently booting with JFFS2 root file
> system.
> I am using linux kernel version 2.6.23 from FreeScale's LTIB for
MPC8313.
>
> As, I want it to boot with YAFFS2 root file system, I did compile kernel
> with yaffs2 support, craeted yaffs2 rootfile system and passed yaffs2
> partiton of nand in bootargs. However it didnot work.
>
>
> If any one has done it successfully, can please share the steps to be
> followed ?
>
More detailed info maybe helpful for debugging this issue.
1. What nand flash is on-board? what's the size of the nand flash page
size, 512/2048?
2. what's the version of mkyaffs2image you are using?
3. Can you mount an empty nand flash partition using yaffs2 type,
mount /dev/mtdblock##x xxx
4. It's better to attatch bootup message.
Tony
> Thanks
> Rupesh
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
[-- Attachment #2: boot-up_manual_RFS.txt --]
[-- Type: text/plain, Size: 22487 bytes --]
U-Boot 1.3.0-S600-Ver1.0 (Jul 16 2009 - 00:03:56) MPC83XX
Reset Status: Software Hard, External/Internal Soft, External/Internal Hard
CPU: e300c3, Rev: Unknown revision number:80b10021
Warning: Unsupported cpu revision!
Board: S600 CPU BOARD
I2C: ready
DRAM: 128 MB
FLASH: 16 MB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
Net: TSEC0, TSEC1 [PRIME]
Hit any key to stop autoboot: 6 \b\b\b 5 \b\b\b 4 \b\b\b 3 \b\b\b 2 \b\b\b 1 \b\b\b 0
Speed: 100, full duplex
Using TSEC1 device
TFTP from server 192.168.6.251; our IP address is 192.168.34.10; sending through gateway 192.168.32.47
Filename 'uImage_yaffs2'.
Load address: 0x200000
Loading: *\b#################################################################
#################################################
done
Bytes transferred = 1669252 (197884 hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.23-S600-Ver1.0
Created: 2009-07-16 2:03:41 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1669188 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0xfe900000
Loading Device Tree to 007fd000, end 007fef4f ... OK
Using MPC8313 RDB machine description
Linux version 2.6.23-S600-Ver1.0 (root@leapfrogserver) (gcc version 4.1.2) #71 Thu Jul 16 07:33:39 IST 2009
console [udbg0] enabled
setup_arch: bootmem
mpc8313_rdb_setup_arch()
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0
arch: exit
Zone PFN ranges:
DMA 0 -> 32768
Normal 32768 -> 32768
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 32768
Built 1 zonelists in Zone order. Total pages: 32512
Kernel command line: root=/dev/mtdblock12 rootfstype=yaffs2 rw console=ttyS0,115200
IPIC (128 IRQ sources) at fdef9700
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 126220k/131072k available (3288k kernel code, 4712k reserved, 148k data, 96k bss, 152k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
yaffs Jul 16 2009 04:53:10 Installing.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
device node obtained!
sram_irq = 48
Sram driver inserted
Serial: 8250/16550 driver $Revision: 1.90 $ 14 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 18) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 21) is a 16550A
serial8250.0: ttyS2 at MMIO 0xfa000000 (irq = 22) is a ST16654
serial8250.0: ttyS3 at MMIO 0xfa000008 (irq = 22) is a ST16654
serial8250.0: ttyS4 at MMIO 0xfa000010 (irq = 22) is a ST16654
serial8250.0: ttyS5 at MMIO 0xfa000018 (irq = 22) is a ST16654
serial8250.0: ttyS6 at MMIO 0xfa000020 (irq = 22) is a ST16654
serial8250.0: ttyS7 at MMIO 0xfa000028 (irq = 22) is a ST16654
serial8250.0: ttyS8 at MMIO 0xfa000030 (irq = 22) is a ST16654
serial8250.0: ttyS9 at MMIO 0xfa000038 (irq = 22) is a ST16654
serial8250.0: ttyS10 at MMIO 0xfa000040 (irq = 23) is a ST16654
serial8250.0: ttyS11 at MMIO 0xfa000048 (irq = 23) is a ST16654
serial8250.0: ttyS12 at MMIO 0xfa000050 (irq = 23) is a ST16654
serial8250.0: ttyS13 at MMIO 0xfa000058 (irq = 23) is a ST16654
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: module loaded
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.3-skbr, 00:e0:0c:00:95:01
GFAR: SKB Handler initialized at CPU#0(max=32)
eth0: MTU = 1500 (frame size=1526, truesize=1800)
eth0: Running with NAPI enabled
eth0: 64/64 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.3-skbr, 00:e0:0c:00:95:02
GFAR: SKB Handler initialized at CPU#0(max=32)
eth1: MTU = 1500 (frame size=1526, truesize=1800)
eth1: Running with NAPI enabled
eth1: 64/64 RX/TX BD ring size
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
Marvell 88E1101: Registered new driver
Marvell 88E1112: Registered new driver
Marvell 88E1111: Registered new driver
Marvell 88E1145: Registered new driver
Fixed MDIO Bus: probed
NFTL driver: nftlcore.c $Revision: 1.98 $, nftlmount.c $Revision: 1.41 $
nor: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
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
physmap-flash nor: Using OF partition information
Creating 6 MTD partitions on "nor":
0x00000000-0x00100000 : "U-Boot"
0x00100000-0x00500000 : "Kernel1"
0x00500000-0x00900000 : "Kernel2"
0x00900000-0x00980000 : "DTB1"
0x00980000-0x00a00000 : "DTB2"
0x00a00000-0x01000000 : "Unused"
Freescale eLBC NAND Driver (C) 2006-2007 Freescale
NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 1062 at 0x084c0000
Bad eraseblock 1063 at 0x084e0000
Bad eraseblock 1064 at 0x08500000
Bad eraseblock 1065 at 0x08520000
Bad eraseblock 1066 at 0x08540000
Bad eraseblock 1067 at 0x08560000
Bad eraseblock 1068 at 0x08580000
Bad eraseblock 1069 at 0x085a0000
Bad eraseblock 1070 at 0x085c0000
Bad eraseblock 1071 at 0x085e0000
Bad eraseblock 1072 at 0x08600000
Bad eraseblock 1073 at 0x08620000
Bad eraseblock 1074 at 0x08640000
Bad eraseblock 1075 at 0x08660000
Bad eraseblock 1076 at 0x08680000
Bad eraseblock 1077 at 0x086a0000
Bad eraseblock 1078 at 0x086c0000
Bad eraseblock 1079 at 0x086e0000
Bad eraseblock 1080 at 0x08700000
Bad eraseblock 1081 at 0x08720000
Bad eraseblock 1082 at 0x08740000
Bad eraseblock 1083 at 0x08760000
Bad eraseblock 1084 at 0x08780000
Bad eraseblock 1085 at 0x087a0000
Bad eraseblock 1086 at 0x087c0000
Bad eraseblock 1087 at 0x087e0000
Bad eraseblock 1088 at 0x08800000
Bad eraseblock 1089 at 0x08820000
Bad eraseblock 1090 at 0x08840000
Bad eraseblock 1091 at 0x08860000
Bad eraseblock 1092 at 0x08880000
Bad eraseblock 1093 at 0x088a0000
Bad eraseblock 1094 at 0x088c0000
Bad eraseblock 1095 at 0x088e0000
Bad eraseblock 1096 at 0x08900000
Bad eraseblock 1097 at 0x08920000
Bad eraseblock 1098 at 0x08940000
Bad eraseblock 1099 at 0x08960000
Bad eraseblock 1100 at 0x08980000
Bad eraseblock 1101 at 0x089a0000
Bad eraseblock 1102 at 0x089c0000
Bad eraseblock 1103 at 0x089e0000
Bad eraseblock 1104 at 0x08a00000
Bad eraseblock 1105 at 0x08a20000
Bad eraseblock 1106 at 0x08a40000
Bad eraseblock 1107 at 0x08a60000
Bad eraseblock 1108 at 0x08a80000
Bad eraseblock 1109 at 0x08aa0000
Bad eraseblock 1110 at 0x08ac0000
Bad eraseblock 1111 at 0x08ae0000
Bad eraseblock 1112 at 0x08b00000
Bad eraseblock 1113 at 0x08b20000
Bad eraseblock 1114 at 0x08b40000
Bad eraseblock 1115 at 0x08b60000
Bad eraseblock 1116 at 0x08b80000
Bad eraseblock 1117 at 0x08ba0000
Bad eraseblock 1118 at 0x08bc0000
Bad eraseblock 1119 at 0x08be0000
Bad eraseblock 1120 at 0x08c00000
Bad eraseblock 1121 at 0x08c20000
Bad eraseblock 1122 at 0x08c40000
Bad eraseblock 1123 at 0x08c60000
Bad eraseblock 1124 at 0x08c80000
Bad eraseblock 1125 at 0x08ca0000
Bad eraseblock 1126 at 0x08cc0000
Bad eraseblock 1127 at 0x08ce0000
Bad eraseblock 1128 at 0x08d00000
Bad eraseblock 1129 at 0x08d20000
Bad eraseblock 1130 at 0x08d40000
Bad eraseblock 1131 at 0x08d60000
Bad eraseblock 1132 at 0x08d80000
Bad eraseblock 1133 at 0x08da0000
Bad eraseblock 1134 at 0x08dc0000
Bad eraseblock 1135 at 0x08de0000
Bad eraseblock 1136 at 0x08e00000
Bad eraseblock 1137 at 0x08e20000
Bad eraseblock 1138 at 0x08e40000
Bad eraseblock 1139 at 0x08e60000
Bad eraseblock 1140 at 0x08e80000
Bad eraseblock 1141 at 0x08ea0000
Bad eraseblock 1142 at 0x08ec0000
Bad eraseblock 1143 at 0x08ee0000
Bad eraseblock 1144 at 0x08f00000
Bad eraseblock 1145 at 0x08f20000
Bad eraseblock 1146 at 0x08f40000
Bad eraseblock 1147 at 0x08f60000
Bad eraseblock 1148 at 0x08f80000
Bad eraseblock 1149 at 0x08fa0000
Bad eraseblock 1150 at 0x08fc0000
Bad eraseblock 1151 at 0x08fe0000
Bad eraseblock 1152 at 0x09000000
Bad eraseblock 1153 at 0x09020000
Bad eraseblock 1154 at 0x09040000
Bad eraseblock 1155 at 0x09060000
Bad eraseblock 1156 at 0x09080000
Bad eraseblock 1157 at 0x090a0000
Bad eraseblock 1158 at 0x090c0000
Bad eraseblock 1159 at 0x090e0000
Bad eraseblock 1160 at 0x09100000
Bad eraseblock 1161 at 0x09120000
Bad eraseblock 1162 at 0x09140000
Bad eraseblock 1163 at 0x09160000
Bad eraseblock 1164 at 0x09180000
Bad eraseblock 1165 at 0x091a0000
Bad eraseblock 1166 at 0x091c0000
Bad eraseblock 1167 at 0x091e0000
Bad eraseblock 1168 at 0x09200000
Bad eraseblock 1169 at 0x09220000
Bad eraseblock 1170 at 0x09240000
Bad eraseblock 1171 at 0x09260000
Bad eraseblock 1172 at 0x09280000
Bad eraseblock 1173 at 0x092a0000
Bad eraseblock 1174 at 0x092c0000
Bad eraseblock 1175 at 0x092e0000
Bad eraseblock 1176 at 0x09300000
Bad eraseblock 1177 at 0x09320000
Bad eraseblock 1178 at 0x09340000
Bad eraseblock 1179 at 0x09360000
Bad eraseblock 1180 at 0x09380000
Bad eraseblock 1181 at 0x093a0000
Bad eraseblock 1182 at 0x093c0000
Bad eraseblock 1183 at 0x093e0000
Bad eraseblock 1184 at 0x09400000
Bad eraseblock 1185 at 0x09420000
Bad eraseblock 1186 at 0x09440000
Bad eraseblock 1187 at 0x09460000
Bad eraseblock 1188 at 0x09480000
Bad eraseblock 1189 at 0x094a0000
Bad eraseblock 1190 at 0x094c0000
Bad eraseblock 1191 at 0x094e0000
Bad eraseblock 1192 at 0x09500000
Bad eraseblock 1193 at 0x09520000
Bad eraseblock 1194 at 0x09540000
Bad eraseblock 1195 at 0x09560000
Bad eraseblock 1196 at 0x09580000
Bad eraseblock 1197 at 0x095a0000
Bad eraseblock 1198 at 0x095c0000
Bad eraseblock 1199 at 0x095e0000
Bad eraseblock 1200 at 0x09600000
Bad eraseblock 1201 at 0x09620000
Bad eraseblock 1202 at 0x09640000
Bad eraseblock 1203 at 0x09660000
Bad eraseblock 1204 at 0x09680000
Bad eraseblock 1205 at 0x096a0000
Bad eraseblock 1206 at 0x096c0000
Bad eraseblock 1207 at 0x096e0000
Bad eraseblock 1208 at 0x09700000
Bad eraseblock 1209 at 0x09720000
Bad eraseblock 1210 at 0x09740000
Bad eraseblock 1211 at 0x09760000
Bad eraseblock 1212 at 0x09780000
Bad eraseblock 1213 at 0x097a0000
Bad eraseblock 1214 at 0x097c0000
Bad eraseblock 1215 at 0x097e0000
Bad eraseblock 1216 at 0x09800000
Bad eraseblock 1217 at 0x09820000
Bad eraseblock 1218 at 0x09840000
Bad eraseblock 1219 at 0x09860000
Bad eraseblock 1220 at 0x09880000
Bad eraseblock 1221 at 0x098a0000
Bad eraseblock 1222 at 0x098c0000
Bad eraseblock 1223 at 0x098e0000
Bad eraseblock 1224 at 0x09900000
Bad eraseblock 1225 at 0x09920000
Bad eraseblock 1226 at 0x09940000
Bad eraseblock 1227 at 0x09960000
Bad eraseblock 1228 at 0x09980000
Bad eraseblock 1229 at 0x099a0000
Bad eraseblock 1230 at 0x099c0000
Bad eraseblock 1231 at 0x099e0000
Bad eraseblock 1232 at 0x09a00000
Bad eraseblock 1233 at 0x09a20000
Bad eraseblock 1234 at 0x09a40000
fsl-elbc fsl-elbc.0: Using OF partition information
Creating 7 MTD partitions on "nand":
0x00000000-0x00100000 : "U-Boot-NAND"
0x00100000-0x00500000 : "Kernel1"
0x00500000-0x00900000 : "Kernel2"
0x00900000-0x00980000 : "DTB1"
0x00980000-0x00a00000 : "DTB2"
0x00a00000-0x08500000 : "RFS1"
0x084c0000-0x0ffc0000 : "RFS2"
mpc83xx_spi.0: MPC83xx SPI Controller driver at 0xc907e000 (irq = 24)
usbmon: debugfs is not available
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 38, io base 0xe0023000
CMD REG : 10009
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
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
WDT driver for MPC83xx initialized. mode:reset timeout=65535 (25 seconds)
mmc_spi spi28672.0: SD/MMC host mmc0, no DMA, no WP, no poweroff
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
rtc-ds1307 0-0068: setting the system clock to 2009-07-15 13:15:24 (1247663724)
yaffs: dev is 32505868 name is "mtdblock12"
yaffs: passed flags ""
yaffs: Attempting MTD mount on 31.12, "mtdblock12"
yaffs: restored from checkpoint
yaffs_read_super: isCheckpointed 1
VFS: Mounted root (yaffs2 filesystem).
Freeing unused kernel memory: 152k init
Setting the hostname to S600CPUBoardRev2.1
Mounting filesystems
Running sysctl
Setting up networking on loopback device:
nand_erase: attempt to erase a bad block at page 0x00013180
------retval -5--------1
nand_erase: attempt to erase a bad block at page 0x000131c0
------retval -5--------1
Warning: no IPADDR is set, please set this from the ltib
config screen, or directly in /etc/rc.d/rc.conf.
IP address setup bypassed
Setting up networking on eth1:
Adding static route for default gateway to 192.168.174.47:
**>> yaffs chunk 10432 was not erased
**>> yaffs chunk 10433 was not erased
**>> yaffs chunk 10434 was not erased
**>> yaffs chunk 10435 was not erased
**>> yaffs chunk 10436 was not erased
**>> yaffs chunk 10437 was not erased
**>> yaffs chunk 10438 was not erased
**>> yaffs chunk 10439 was not erased
**>> yaffs chunk 10440 was not erased
**>> yaffs chunk 10441 was not erased
**>> yaffs chunk 10442 was not erased
**>> yaffs chunk 10443 was not erased
**>> yaffs chunk 10444 was not erased
**>> yaffs chunk 10445 was not erased
**>> yaffs chunk 10446 was not erased
**>> yaffs chunk 10447 was not erased
**>> yaffs chunk 10448 was not erased
**>> yaffs chunk 10449 was not erased
**>> yaffs chunk 10450 was not erased
**>> yaffs chunk 10451 was not erased
**>> yaffs chunk 10452 was not erased
**>> yaffs chunk 10453 was not erased
**>> yaffs chunk 10454 was not erased
**>> yaffs chunk 10455 was not erased
**>> yaffs chunk 10456 was not erased
**>> yaffs chunk 10457 was not erased
**>> yaffs chunk 10458 was not erased
**>> yaffs chunk 10459 was not erased
**>> yaffs chunk 10460 was not erased
**>> yaffs chunk 10461 was not erased
**>> yaffs chunk 10462 was not erased
**>> yaffs chunk 10463 was not erased
**>> yaffs chunk 10464 was not erased
**>> yaffs chunk 10465 was not erased
**>> yaffs chunk 10466 was not erased
**>> yaffs chunk 10467 was not erased
**>> yaffs chunk 10468 was not erased
**>> yaffs chunk 10469 was not erased
**>> yaffs chunk 10470 was not erased
**>> yaffs chunk 10471 was not erased
**>> yaffs chunk 10472 was not erased
**>> yaffs chunk 10473 was not erased
**>> yaffs chunk 10474 was not erased
**>> yaffs chunk 10475 was not erased
**>> yaffs chunk 10476 was not erased
**>> yaffs chunk 10477 was not erased
**>> yaffs chunk 10478 was not erased
**>> yaffs chunk 10479 was not erased
**>> yaffs chunk 10480 was not erased
**>> yaffs chunk 10481 was not erased
**>> yaffs chunk 10482 was not erased
**>> yaffs chunk 10483 was not erased
**>> yaffs chunk 10484 was not erased
**>> yaffs chunk 10485 was not erased
**>> yaffs chunk 10486 was not erased
**>> yaffs chunk 10487 was not erased
**>> yaffs chunk 10488 was not erased
**>> yaffs chunk 10489 was not erased
**>> yaffs chunk 10490 was not erased
**>> yaffs chunk 10491 was not erased
**>> yaffs chunk 10492 was not erased
**>> yaffs chunk 10493 was not erased
**>> yaffs chunk 10494 was not erased
**>> yaffs chunk 10495 was not erased
**>> yaffs chunk 10496 was not erased
**>> yaffs chunk 10560 was not erased
**>> yaffs chunk 10624 was not erased
**>> yaffs chunk 10625 was not erased
**>> yaffs chunk 10626 was not erased
**>> yaffs chunk 10627 was not erased
**>> yaffs chunk 10628 was not erased
**>> yaffs chunk 10629 was not erased
**>> yaffs chunk 10630 was not erased
**>> yaffs chunk 10631 was not erased
**>> yaffs chunk 10632 was not erased
**>> yaffs chunk 10633 was not erased
**>> yaffs chunk 10634 was not erased
**>> yaffs chunk 10635 was not erased
**>> yaffs chunk 10636 was not erased
**>> yaffs chunk 10637 was not erased
**>> yaffs chunk 10638 was not erased
**>> yaffs chunk 10639 was not erased
**>> yaffs chunk 10640 was not erased
**>> yaffs chunk 10641 was not erased
**>> yaffs chunk 10642 was not erased
**>> yaffs chunk 10643 was not erased
**>> yaffs chunk 10644 was not erased
**>> yaffs chunk 10645 was not erased
**>> yaffs chunk 10646 was not erased
**>> yaffs chunk 10647 was not erased
**>> yaffs chunk 10648 was not erased
**>> yaffs chunk 10649 was not erased
**>> yaffs chunk 10650 was not erased
**>> yaffs chunk 10651 was not erased
**>> yaffs chunk 10652 was not erased
**>> yaffs chunk 10653 was not erased
**>> yaffs chunk 10654 was not erased
**>> yaffs chunk 10655 was not erased
**>> yaffs chunk 10656 was not erased
**>> yaffs chunk 10657 was not erased
**>> yaffs chunk 10658 was not erased
**>> yaffs chunk 10659 was not erased
**>> yaffs chunk 10660 was not erased
**>> yaffs chunk 10661 was not erased
**>> yaffs chunk 10662 was not erased
**>> yaffs chunk 10663 was not erased
**>> yaffs chunk 10664 was not erased
**>> yaffs chunk 10665 was not erased
**>> yaffs chunk 10666 was not erased
**>> yaffs chunk 10667 was not erased
**>> yaffs chunk 10668 was not erased
**>> yaffs chunk 10669 was not erased
**>> yaffs chunk 10670 was not erased
**>> yaffs chunk 10671 was not erased
**>> yaffs chunk 10672 was not erased
**>> yaffs chunk 10673 was not erased
**>> yaffs chunk 10674 was not erased
**>> yaffs chunk 10675 was not erased
**>> yaffs chunk 10676 was not erased
**>> yaffs chunk 10677 was not erased
**>> yaffs chunk 10678 was not erased
**>> yaffs chunk 10679 was not erased
**>> yaffs chunk 10680 was not erased
**>> yaffs chunk 10681 was not erased
**>> yaffs chunk 10682 was not erased
**>> yaffs chunk 10683 was not erased
**>> yaffs chunk 10684 was not erased
**>> yaffs chunk 10685 was not erased
**>> yaffs chunk 10686 was not erased
**>> yaffs chunk 10687 was not erased
**>> yaffs chunk 10688 was not erased
**>> yaffs chunk 10752 was not erased
**>> yaffs chunk 10816 was not erased
**>> yaffs chunk 10880 was not erased
**>> yaffs chunk 10944 was not erased
**>> yaffs chunk 10945 was not erased
**>> yaffs chunk 10946 was not erased
**>> yaffs chunk 10947 was not erased
**>> yaffs chunk 10948 was not erased
**>> yaffs chunk 10949 was not erased
**>> yaffs chunk 10950 was not erased
**>> yaffs chunk 10951 was not erased
**>> yaffs chunk 10952 was not erased
**>> yaffs chunk 10953 was not erased
**>> yaffs chunk 10954 was not erased
**>> yaffs chunk 10955 was not erased
**>> yaffs chunk 10956 was not erased
**>> yaffs chunk 10957 was not erased
**>> yaffs chunk 10958 was not erased
**>> yaffs chunk 10959 was not erased
**>> yaffs chunk 10960 was not erased
**>> yaffs chunk 10961 was not erased
**>> yaffs chunk 10962 was not erased
**>> yaffs chunk 10963 was not erased
**>> yaffs chunk 10964 was not erased
**>> yaffs chunk 10965 was not erased
**>> yaffs chunk 10966 was not erased
**>> yaffs chunk 10967 was not erased
**>> yaffs chunk 10968 was not erased
**>> yaffs chunk 10969 was not erased
**>> yaffs chunk 10970 was not erased
**>> yaffs chunk 10971 was not erased
**>> yaffs chunk 10972 was not erased
**>> yaffs write required 164 attempts
page 10496 in gc has no object: 165 1 2048
nand_erase: attempt to erase a bad block at page 0x00013240
------retval -5<4>**>> Erasure failed 164
**>> Block 164 retired
Block 164 is in state 9 after gc, should be erased
page 10560 in gc has no object: 166 65 2048
nand_erase: attempt to erase a bad block at page 0x00013280
------retval -5<4>**>> Erasure failed 165
**>> Block 165 retired
Block 165 is in state 9 after gc, should be erased
page 10688 in gc has no object: 168 1 2048
nand_erase: attempt to erase a bad block at page 0x00013300
------retval -5<4>**>> Erasure failed 167
**>> Block 167 retired
Block 167 is in state 9 after gc, should be erased
page 10752 in gc has no object: 169 65 2048
nand_erase: attempt to erase a bad block at page 0x00013340
------retval -5<4>**>> Erasure failed 168
**>> Block 168 retired
Block 168 is in state 9 after gc, should be erased
page 10816 in gc has no object: 136 1 2048
nand_erase: attempt to erase a bad block at page 0x00013380
------retval -5<4>**>> Erasure failed 169
**>> Block 169 retired
Block 169 is in state 9 after gc, should be erased
Setting nameservpage 10880 in gc has no object: 171 65 2048
er to 192.168.1.nand_erase: attempt to erase a bad block at page 0x000133c0
1 in /etc/resolv------retval -5.conf:
<4>**>> Erasure failed 170
**>> Block 170 retired
Block 170 is in state 9 after gc, should be erased
Starting inetd:
Starting the dropbear ssh server:
Setting RS485 Mode
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
S600CPUBoardRev2.1 login: PHY: e0024520:19 - Link is Up - 100/Full
root
Password:
login[889]: root login on `console'
~ #
~ #
~ #
~ #
~ #
~ #
[-- Attachment #3: boot-up_with_RFS_createdby_mkyffs2image_tool.txt --]
[-- Type: text/plain, Size: 19833 bytes --]
Resetting the board.
U-Boot 1.3.0-S600-Ver1.0 (Jul 16 2009 - 00:03:56) MPC83XX
Reset Status: Software Hard, External/Internal Soft, External/Internal Hard
CPU: e300c3, Rev: Unknown revision number:80b10021
Warning: Unsupported cpu revision!
Board: S600 CPU BOARD
I2C: ready
DRAM: 128 MB
FLASH: 16 MB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
Net: TSEC0, TSEC1 [PRIME]
Hit any key to stop autoboot: 6 \b\b\b 5 \b\b\b 4 \b\b\b 3 \b\b\b 2 \b\b\b 1 \b\b\b 0
Speed: 100, full duplex
Using TSEC1 device
TFTP from server 192.168.6.251; our IP address is 192.168.34.10; sending through gateway 192.168.32.47
Filename 'uImage_yaffs2'.
Load address: 0x200000
Loading: *\b#################################################################
#################################################
done
Bytes transferred = 1669252 (197884 hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.23-S600-Ver1.0
Created: 2009-07-16 2:03:41 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1669188 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0xfe900000
Loading Device Tree to 007fd000, end 007fef4f ... OK
Using MPC8313 RDB machine description
Linux version 2.6.23-S600-Ver1.0 (root@leapfrogserver) (gcc version 4.1.2) #71 Thu Jul 16 07:33:39 IST 2009
console [udbg0] enabled
setup_arch: bootmem
mpc8313_rdb_setup_arch()
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0
arch: exit
Zone PFN ranges:
DMA 0 -> 32768
Normal 32768 -> 32768
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 32768
Built 1 zonelists in Zone order. Total pages: 32512
Kernel command line: root=/dev/mtdblock11 rootfstype=yaffs2 rw console=ttyS0,115200
IPIC (128 IRQ sources) at fdef9700
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 126220k/131072k available (3288k kernel code, 4712k reserved, 148k data, 96k bss, 152k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
yaffs Jul 16 2009 04:53:10 Installing.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
device node obtained!
sram_irq = 48
Sram driver inserted
Serial: 8250/16550 driver $Revision: 1.90 $ 14 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 18) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 21) is a 16550A
serial8250.0: ttyS2 at MMIO 0xfa000000 (irq = 22) is a ST16654
serial8250.0: ttyS3 at MMIO 0xfa000008 (irq = 22) is a ST16654
serial8250.0: ttyS4 at MMIO 0xfa000010 (irq = 22) is a ST16654
serial8250.0: ttyS5 at MMIO 0xfa000018 (irq = 22) is a ST16654
serial8250.0: ttyS6 at MMIO 0xfa000020 (irq = 22) is a ST16654
serial8250.0: ttyS7 at MMIO 0xfa000028 (irq = 22) is a ST16654
serial8250.0: ttyS8 at MMIO 0xfa000030 (irq = 22) is a ST16654
serial8250.0: ttyS9 at MMIO 0xfa000038 (irq = 22) is a ST16654
serial8250.0: ttyS10 at MMIO 0xfa000040 (irq = 23) is a ST16654
serial8250.0: ttyS11 at MMIO 0xfa000048 (irq = 23) is a ST16654
serial8250.0: ttyS12 at MMIO 0xfa000050 (irq = 23) is a ST16654
serial8250.0: ttyS13 at MMIO 0xfa000058 (irq = 23) is a ST16654
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: module loaded
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.3-skbr, 00:e0:0c:00:95:01
GFAR: SKB Handler initialized at CPU#0(max=32)
eth0: MTU = 1500 (frame size=1526, truesize=1800)
eth0: Running with NAPI enabled
eth0: 64/64 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.3-skbr, 00:e0:0c:00:95:02
GFAR: SKB Handler initialized at CPU#0(max=32)
eth1: MTU = 1500 (frame size=1526, truesize=1800)
eth1: Running with NAPI enabled
eth1: 64/64 RX/TX BD ring size
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
Marvell 88E1101: Registered new driver
Marvell 88E1112: Registered new driver
Marvell 88E1111: Registered new driver
Marvell 88E1145: Registered new driver
Fixed MDIO Bus: probed
NFTL driver: nftlcore.c $Revision: 1.98 $, nftlmount.c $Revision: 1.41 $
nor: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
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
physmap-flash nor: Using OF partition information
Creating 6 MTD partitions on "nor":
0x00000000-0x00100000 : "U-Boot"
0x00100000-0x00500000 : "Kernel1"
0x00500000-0x00900000 : "Kernel2"
0x00900000-0x00980000 : "DTB1"
0x00980000-0x00a00000 : "DTB2"
0x00a00000-0x01000000 : "Unused"
Freescale eLBC NAND Driver (C) 2006-2007 Freescale
NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 80 at 0x00a00000
Bad eraseblock 81 at 0x00a20000
Bad eraseblock 1062 at 0x084c0000
Bad eraseblock 1063 at 0x084e0000
Bad eraseblock 1064 at 0x08500000
Bad eraseblock 1065 at 0x08520000
Bad eraseblock 1066 at 0x08540000
Bad eraseblock 1067 at 0x08560000
Bad eraseblock 1068 at 0x08580000
Bad eraseblock 1069 at 0x085a0000
Bad eraseblock 1070 at 0x085c0000
Bad eraseblock 1071 at 0x085e0000
Bad eraseblock 1072 at 0x08600000
Bad eraseblock 1073 at 0x08620000
Bad eraseblock 1074 at 0x08640000
Bad eraseblock 1075 at 0x08660000
Bad eraseblock 1076 at 0x08680000
Bad eraseblock 1077 at 0x086a0000
Bad eraseblock 1078 at 0x086c0000
Bad eraseblock 1079 at 0x086e0000
Bad eraseblock 1080 at 0x08700000
Bad eraseblock 1081 at 0x08720000
Bad eraseblock 1082 at 0x08740000
Bad eraseblock 1083 at 0x08760000
Bad eraseblock 1084 at 0x08780000
Bad eraseblock 1085 at 0x087a0000
Bad eraseblock 1086 at 0x087c0000
Bad eraseblock 1087 at 0x087e0000
Bad eraseblock 1088 at 0x08800000
Bad eraseblock 1089 at 0x08820000
Bad eraseblock 1090 at 0x08840000
Bad eraseblock 1091 at 0x08860000
Bad eraseblock 1092 at 0x08880000
Bad eraseblock 1093 at 0x088a0000
Bad eraseblock 1094 at 0x088c0000
Bad eraseblock 1095 at 0x088e0000
Bad eraseblock 1096 at 0x08900000
Bad eraseblock 1097 at 0x08920000
Bad eraseblock 1098 at 0x08940000
Bad eraseblock 1099 at 0x08960000
Bad eraseblock 1100 at 0x08980000
Bad eraseblock 1101 at 0x089a0000
Bad eraseblock 1102 at 0x089c0000
Bad eraseblock 1103 at 0x089e0000
Bad eraseblock 1104 at 0x08a00000
Bad eraseblock 1105 at 0x08a20000
Bad eraseblock 1106 at 0x08a40000
Bad eraseblock 1107 at 0x08a60000
Bad eraseblock 1108 at 0x08a80000
Bad eraseblock 1109 at 0x08aa0000
Bad eraseblock 1110 at 0x08ac0000
Bad eraseblock 1111 at 0x08ae0000
Bad eraseblock 1112 at 0x08b00000
Bad eraseblock 1113 at 0x08b20000
Bad eraseblock 1114 at 0x08b40000
Bad eraseblock 1115 at 0x08b60000
Bad eraseblock 1116 at 0x08b80000
Bad eraseblock 1117 at 0x08ba0000
Bad eraseblock 1118 at 0x08bc0000
Bad eraseblock 1119 at 0x08be0000
Bad eraseblock 1120 at 0x08c00000
Bad eraseblock 1121 at 0x08c20000
Bad eraseblock 1122 at 0x08c40000
Bad eraseblock 1123 at 0x08c60000
Bad eraseblock 1124 at 0x08c80000
Bad eraseblock 1125 at 0x08ca0000
Bad eraseblock 1126 at 0x08cc0000
Bad eraseblock 1127 at 0x08ce0000
Bad eraseblock 1128 at 0x08d00000
Bad eraseblock 1129 at 0x08d20000
Bad eraseblock 1130 at 0x08d40000
Bad eraseblock 1131 at 0x08d60000
Bad eraseblock 1132 at 0x08d80000
Bad eraseblock 1133 at 0x08da0000
Bad eraseblock 1134 at 0x08dc0000
Bad eraseblock 1135 at 0x08de0000
Bad eraseblock 1136 at 0x08e00000
Bad eraseblock 1137 at 0x08e20000
Bad eraseblock 1138 at 0x08e40000
Bad eraseblock 1139 at 0x08e60000
Bad eraseblock 1140 at 0x08e80000
Bad eraseblock 1141 at 0x08ea0000
Bad eraseblock 1142 at 0x08ec0000
Bad eraseblock 1143 at 0x08ee0000
Bad eraseblock 1144 at 0x08f00000
Bad eraseblock 1145 at 0x08f20000
Bad eraseblock 1146 at 0x08f40000
Bad eraseblock 1147 at 0x08f60000
Bad eraseblock 1148 at 0x08f80000
Bad eraseblock 1149 at 0x08fa0000
Bad eraseblock 1150 at 0x08fc0000
Bad eraseblock 1151 at 0x08fe0000
Bad eraseblock 1152 at 0x09000000
Bad eraseblock 1153 at 0x09020000
Bad eraseblock 1154 at 0x09040000
Bad eraseblock 1155 at 0x09060000
Bad eraseblock 1156 at 0x09080000
Bad eraseblock 1157 at 0x090a0000
Bad eraseblock 1158 at 0x090c0000
Bad eraseblock 1159 at 0x090e0000
Bad eraseblock 1160 at 0x09100000
Bad eraseblock 1161 at 0x09120000
Bad eraseblock 1162 at 0x09140000
Bad eraseblock 1163 at 0x09160000
Bad eraseblock 1164 at 0x09180000
Bad eraseblock 1165 at 0x091a0000
Bad eraseblock 1166 at 0x091c0000
Bad eraseblock 1167 at 0x091e0000
Bad eraseblock 1168 at 0x09200000
Bad eraseblock 1169 at 0x09220000
Bad eraseblock 1170 at 0x09240000
Bad eraseblock 1171 at 0x09260000
Bad eraseblock 1172 at 0x09280000
Bad eraseblock 1173 at 0x092a0000
Bad eraseblock 1174 at 0x092c0000
Bad eraseblock 1175 at 0x092e0000
Bad eraseblock 1176 at 0x09300000
Bad eraseblock 1177 at 0x09320000
Bad eraseblock 1178 at 0x09340000
Bad eraseblock 1179 at 0x09360000
Bad eraseblock 1180 at 0x09380000
Bad eraseblock 1181 at 0x093a0000
Bad eraseblock 1182 at 0x093c0000
Bad eraseblock 1183 at 0x093e0000
Bad eraseblock 1184 at 0x09400000
Bad eraseblock 1185 at 0x09420000
Bad eraseblock 1186 at 0x09440000
Bad eraseblock 1187 at 0x09460000
Bad eraseblock 1188 at 0x09480000
Bad eraseblock 1189 at 0x094a0000
Bad eraseblock 1190 at 0x094c0000
Bad eraseblock 1191 at 0x094e0000
Bad eraseblock 1192 at 0x09500000
Bad eraseblock 1193 at 0x09520000
Bad eraseblock 1194 at 0x09540000
Bad eraseblock 1195 at 0x09560000
Bad eraseblock 1196 at 0x09580000
Bad eraseblock 1197 at 0x095a0000
Bad eraseblock 1198 at 0x095c0000
Bad eraseblock 1199 at 0x095e0000
Bad eraseblock 1200 at 0x09600000
Bad eraseblock 1201 at 0x09620000
Bad eraseblock 1202 at 0x09640000
Bad eraseblock 1203 at 0x09660000
Bad eraseblock 1204 at 0x09680000
Bad eraseblock 1205 at 0x096a0000
Bad eraseblock 1206 at 0x096c0000
Bad eraseblock 1207 at 0x096e0000
Bad eraseblock 1208 at 0x09700000
Bad eraseblock 1209 at 0x09720000
Bad eraseblock 1210 at 0x09740000
Bad eraseblock 1211 at 0x09760000
Bad eraseblock 1212 at 0x09780000
Bad eraseblock 1213 at 0x097a0000
Bad eraseblock 1214 at 0x097c0000
Bad eraseblock 1215 at 0x097e0000
Bad eraseblock 1216 at 0x09800000
Bad eraseblock 1217 at 0x09820000
Bad eraseblock 1218 at 0x09840000
Bad eraseblock 1219 at 0x09860000
Bad eraseblock 1220 at 0x09880000
Bad eraseblock 1221 at 0x098a0000
Bad eraseblock 1222 at 0x098c0000
Bad eraseblock 1223 at 0x098e0000
Bad eraseblock 1224 at 0x09900000
Bad eraseblock 1225 at 0x09920000
Bad eraseblock 1226 at 0x09940000
Bad eraseblock 1227 at 0x09960000
Bad eraseblock 1228 at 0x09980000
Bad eraseblock 1229 at 0x099a0000
Bad eraseblock 1230 at 0x099c0000
Bad eraseblock 1231 at 0x099e0000
Bad eraseblock 1232 at 0x09a00000
Bad eraseblock 1233 at 0x09a20000
Bad eraseblock 1234 at 0x09a40000
Bad eraseblock 1235 at 0x09a60000
Bad eraseblock 1236 at 0x09a80000
Bad eraseblock 1237 at 0x09aa0000
Bad eraseblock 1238 at 0x09ac0000
Bad eraseblock 1239 at 0x09ae0000
Bad eraseblock 1240 at 0x09b00000
Bad eraseblock 1241 at 0x09b20000
Bad eraseblock 1242 at 0x09b40000
Bad eraseblock 1243 at 0x09b60000
Bad eraseblock 1244 at 0x09b80000
Bad eraseblock 1245 at 0x09ba0000
Bad eraseblock 1246 at 0x09bc0000
Bad eraseblock 1247 at 0x09be0000
Bad eraseblock 1248 at 0x09c00000
Bad eraseblock 1249 at 0x09c20000
Bad eraseblock 1250 at 0x09c40000
Bad eraseblock 1251 at 0x09c60000
Bad eraseblock 1252 at 0x09c80000
Bad eraseblock 1253 at 0x09ca0000
Bad eraseblock 1254 at 0x09cc0000
Bad eraseblock 1255 at 0x09ce0000
Bad eraseblock 1256 at 0x09d00000
Bad eraseblock 1257 at 0x09d20000
Bad eraseblock 1258 at 0x09d40000
Bad eraseblock 1259 at 0x09d60000
Bad eraseblock 1260 at 0x09d80000
Bad eraseblock 1261 at 0x09da0000
Bad eraseblock 1262 at 0x09dc0000
Bad eraseblock 1263 at 0x09de0000
Bad eraseblock 1264 at 0x09e00000
Bad eraseblock 1265 at 0x09e20000
Bad eraseblock 1266 at 0x09e40000
Bad eraseblock 1267 at 0x09e60000
Bad eraseblock 1268 at 0x09e80000
Bad eraseblock 1269 at 0x09ea0000
Bad eraseblock 1270 at 0x09ec0000
Bad eraseblock 1271 at 0x09ee0000
Bad eraseblock 1272 at 0x09f00000
Bad eraseblock 1273 at 0x09f20000
Bad eraseblock 1274 at 0x09f40000
Bad eraseblock 1275 at 0x09f60000
Bad eraseblock 1276 at 0x09f80000
Bad eraseblock 1277 at 0x09fa0000
Bad eraseblock 1278 at 0x09fc0000
Bad eraseblock 1279 at 0x09fe0000
Bad eraseblock 1280 at 0x0a000000
Bad eraseblock 1281 at 0x0a020000
Bad eraseblock 1282 at 0x0a040000
Bad eraseblock 1283 at 0x0a060000
Bad eraseblock 1284 at 0x0a080000
Bad eraseblock 1285 at 0x0a0a0000
Bad eraseblock 1286 at 0x0a0c0000
Bad eraseblock 1287 at 0x0a0e0000
Bad eraseblock 1288 at 0x0a100000
Bad eraseblock 1289 at 0x0a120000
Bad eraseblock 1290 at 0x0a140000
Bad eraseblock 1291 at 0x0a160000
Bad eraseblock 1292 at 0x0a180000
Bad eraseblock 1293 at 0x0a1a0000
Bad eraseblock 1294 at 0x0a1c0000
Bad eraseblock 1295 at 0x0a1e0000
Bad eraseblock 1296 at 0x0a200000
Bad eraseblock 1297 at 0x0a220000
Bad eraseblock 1298 at 0x0a240000
Bad eraseblock 1299 at 0x0a260000
Bad eraseblock 1300 at 0x0a280000
Bad eraseblock 1301 at 0x0a2a0000
Bad eraseblock 1302 at 0x0a2c0000
Bad eraseblock 1303 at 0x0a2e0000
Bad eraseblock 1304 at 0x0a300000
Bad eraseblock 1305 at 0x0a320000
Bad eraseblock 1306 at 0x0a340000
Bad eraseblock 1307 at 0x0a360000
Bad eraseblock 1308 at 0x0a380000
Bad eraseblock 1309 at 0x0a3a0000
Bad eraseblock 1310 at 0x0a3c0000
Bad eraseblock 1311 at 0x0a3e0000
Bad eraseblock 1312 at 0x0a400000
Bad eraseblock 1313 at 0x0a420000
Bad eraseblock 1314 at 0x0a440000
Bad eraseblock 1315 at 0x0a460000
Bad eraseblock 1316 at 0x0a480000
Bad eraseblock 1317 at 0x0a4a0000
Bad eraseblock 1318 at 0x0a4c0000
Bad eraseblock 1319 at 0x0a4e0000
Bad eraseblock 1320 at 0x0a500000
Bad eraseblock 1321 at 0x0a520000
Bad eraseblock 1322 at 0x0a540000
Bad eraseblock 1323 at 0x0a560000
Bad eraseblock 1324 at 0x0a580000
Bad eraseblock 1325 at 0x0a5a0000
Bad eraseblock 1326 at 0x0a5c0000
Bad eraseblock 1327 at 0x0a5e0000
Bad eraseblock 1328 at 0x0a600000
Bad eraseblock 1329 at 0x0a620000
Bad eraseblock 1330 at 0x0a640000
Bad eraseblock 1331 at 0x0a660000
Bad eraseblock 1332 at 0x0a680000
Bad eraseblock 1333 at 0x0a6a0000
Bad eraseblock 1334 at 0x0a6c0000
Bad eraseblock 1335 at 0x0a6e0000
Bad eraseblock 1336 at 0x0a700000
Bad eraseblock 1337 at 0x0a720000
Bad eraseblock 1338 at 0x0a740000
Bad eraseblock 1339 at 0x0a760000
Bad eraseblock 1340 at 0x0a780000
Bad eraseblock 1341 at 0x0a7a0000
Bad eraseblock 1342 at 0x0a7c0000
Bad eraseblock 1343 at 0x0a7e0000
Bad eraseblock 1344 at 0x0a800000
Bad eraseblock 1345 at 0x0a820000
Bad eraseblock 1346 at 0x0a840000
Bad eraseblock 1347 at 0x0a860000
Bad eraseblock 1348 at 0x0a880000
Bad eraseblock 1349 at 0x0a8a0000
Bad eraseblock 1350 at 0x0a8c0000
Bad eraseblock 1351 at 0x0a8e0000
Bad eraseblock 1352 at 0x0a900000
Bad eraseblock 1353 at 0x0a920000
Bad eraseblock 1354 at 0x0a940000
Bad eraseblock 1355 at 0x0a960000
Bad eraseblock 1356 at 0x0a980000
Bad eraseblock 1357 at 0x0a9a0000
Bad eraseblock 1358 at 0x0a9c0000
Bad eraseblock 1359 at 0x0a9e0000
Bad eraseblock 1360 at 0x0aa00000
Bad eraseblock 1361 at 0x0aa20000
Bad eraseblock 1362 at 0x0aa40000
Bad eraseblock 1363 at 0x0aa60000
Bad eraseblock 1364 at 0x0aa80000
Bad eraseblock 1365 at 0x0aaa0000
Bad eraseblock 1366 at 0x0aac0000
Bad eraseblock 1367 at 0x0aae0000
Bad eraseblock 1368 at 0x0ab00000
Bad eraseblock 1369 at 0x0ab20000
Bad eraseblock 1370 at 0x0ab40000
Bad eraseblock 1371 at 0x0ab60000
Bad eraseblock 1372 at 0x0ab80000
Bad eraseblock 1373 at 0x0aba0000
Bad eraseblock 1374 at 0x0abc0000
Bad eraseblock 1375 at 0x0abe0000
Bad eraseblock 1376 at 0x0ac00000
Bad eraseblock 1377 at 0x0ac20000
Bad eraseblock 1378 at 0x0ac40000
Bad eraseblock 1379 at 0x0ac60000
Bad eraseblock 1380 at 0x0ac80000
Bad eraseblock 1381 at 0x0aca0000
Bad eraseblock 1382 at 0x0acc0000
Bad eraseblock 1383 at 0x0ace0000
Bad eraseblock 1384 at 0x0ad00000
Bad eraseblock 1385 at 0x0ad20000
Bad eraseblock 1386 at 0x0ad40000
Bad eraseblock 1387 at 0x0ad60000
Bad eraseblock 1388 at 0x0ad80000
Bad eraseblock 1389 at 0x0ada0000
Bad eraseblock 1390 at 0x0adc0000
Bad eraseblock 1391 at 0x0ade0000
Bad eraseblock 1392 at 0x0ae00000
Bad eraseblock 1393 at 0x0ae20000
Bad eraseblock 1394 at 0x0ae40000
Bad eraseblock 1395 at 0x0ae60000
Bad eraseblock 1396 at 0x0ae80000
Bad eraseblock 1397 at 0x0aea0000
Bad eraseblock 1398 at 0x0aec0000
Bad eraseblock 1399 at 0x0aee0000
Bad eraseblock 1400 at 0x0af00000
Bad eraseblock 1401 at 0x0af20000
Bad eraseblock 1402 at 0x0af40000
Bad eraseblock 1403 at 0x0af60000
fsl-elbc fsl-elbc.0: Using OF partition information
Creating 7 MTD partitions on "nand":
0x00000000-0x00100000 : "U-Boot-NAND"
0x00100000-0x00500000 : "Kernel1"
0x00500000-0x00900000 : "Kernel2"
0x00900000-0x00980000 : "DTB1"
0x00980000-0x00a00000 : "DTB2"
0x00a00000-0x08500000 : "RFS1"
0x084c0000-0x0ffc0000 : "RFS2"
mpc83xx_spi.0: MPC83xx SPI Controller driver at 0xc907e000 (irq = 24)
usbmon: debugfs is not available
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 38, io base 0xe0023000
CMD REG : 10009
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
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
WDT driver for MPC83xx initialized. mode:reset timeout=65535 (25 seconds)
mmc_spi spi28672.0: SD/MMC host mmc0, no DMA, no WP, no poweroff
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
rtc-ds1307 0-0068: setting the system clock to 2009-07-16 04:53:18 (1247719998)
yaffs: dev is 32505867 name is "mtdblock11"
yaffs: passed flags ""
yaffs: Attempting MTD mount on 31.11, "mtdblock11"
block 1 is bad
block 2 is bad
block 983 is bad
block 984 is bad
yaffs_read_super: isCheckpointed 0
VFS: Mounted root (yaffs2 filesystem).
Freeing unused kernel memory: 152k init
Warning: unable to open an initial console.
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
Rebooting in 180 seconds..
^ permalink raw reply
* Re: [PATCH] kmemleak: Allow kmemleak to be built on powerpc
From: Michael Ellerman @ 2009-07-16 7:43 UTC (permalink / raw)
To: catalin.marinas; +Cc: linuxppc-dev
In-Reply-To: <f18967360113efe4354a9ad0d71ead9a0f7579ea.1247707485.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]
On Thu, 2009-07-16 at 11:25 +1000, Michael Ellerman wrote:
> Very lightly tested, doesn't crash the kernel.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
>
> It doesn't look like we actually need to add any support in the
> arch code - or is there something I'm missing?
Hmm, I think we want to add annotations in lib/lmb.c don't we? That's
our low-level pre-bootmem allocator.
And we have the same problem with _edata as x86.
And I'm seeing lots (~250) of these:
unreferenced object 0xc0000000fcd2e2f0 (size 16):
comm "swapper", pid 1, jiffies 4294892393
backtrace:
[<c00000000014d9c0>] .create_object+0x164/0x2a8
[<c00000000014dc94>] .kmemleak_alloc+0x74/0x120
[<c0000000001474d0>] .__kmalloc+0x20c/0x2ac
[<c00000000036998c>] .kvasprintf+0x64/0xb0
[<c000000000360558>] .kobject_set_name_vargs+0x44/0xb4
[<c0000000003f06d0>] .dev_set_name+0x50/0x6c
[<c00000000042a794>] .scsi_sysfs_device_initialize+0xd0/0x16c
[<c000000000426600>] .scsi_alloc_sdev+0x1c4/0x284
[<c000000000426b50>] .scsi_probe_and_add_lun+0x144/0xbd4
[<c0000000004279bc>] .__scsi_scan_target+0xfc/0x658
[<c000000000427f90>] .scsi_scan_channel+0x78/0xe8
[<c0000000004280cc>] .scsi_scan_host_selected+0xcc/0x154
[<c00000000042823c>] .do_scsi_scan_host+0xe8/0x10c
[<c0000000004286ec>] .scsi_scan_host+0x250/0x294
[<c000000000456ef8>] .ibmvscsi_probe+0x4f8/0x630
[<c000000000027418>] .vio_bus_probe+0x360/0x3cc
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-07-16 8:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here are a couple of fixes for powerpc for 2.6.31.
The following changes since commit e9e961c9a818a2f24711af493b907a8e40a69efc:
Linus Torvalds (1):
Merge branch 'i2c-for-2631-rc3' of git://aeryn.fluff.org.uk/bjdooks/linux
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Andreas Schwab (1):
powerpc: Fix another bug in move of altivec code to vector.S
Dave Kleikamp (1):
powerpc: Fix booke user_disable_single_step()
arch/powerpc/kernel/ptrace.c | 17 +++++++++--------
arch/powerpc/kernel/vector.S | 6 +++---
2 files changed, 12 insertions(+), 11 deletions(-)
^ permalink raw reply
* Re: [PATCH] kmemleak: Allow kmemleak to be built on powerpc
From: Josh Boyer @ 2009-07-16 11:31 UTC (permalink / raw)
To: Michael Ellerman; +Cc: catalin.marinas, linuxppc-dev
In-Reply-To: <1247730230.18228.5.camel@concordia>
On Thu, Jul 16, 2009 at 05:43:50PM +1000, Michael Ellerman wrote:
>On Thu, 2009-07-16 at 11:25 +1000, Michael Ellerman wrote:
>> Very lightly tested, doesn't crash the kernel.
>>
>> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
>> ---
>>
>> It doesn't look like we actually need to add any support in the
>> arch code - or is there something I'm missing?
>
>Hmm, I think we want to add annotations in lib/lmb.c don't we? That's
>our low-level pre-bootmem allocator.
>
>And we have the same problem with _edata as x86.
I'll point out that the Fedora developers enabled this in the rawhide kernels
for 3 days, and then turned it back off because most of the things found were
false positives.
Might still be worth poking at, but until it gets a bit less buggy itself it
could be a timesink.
josh
^ permalink raw reply
* Linux with RAM mapped other than zero.
From: Sumesh Kaana @ 2009-07-16 12:08 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]
Hi all, I've a system design (32 bit) with SDRAM mapped at 0xf8000000 rather than at 0. what are the changes i should make to successfully boot a kernel..? my design with SDRAM at 0 (64MB) is working fine with xilinx git line kernel(2.6.27). i was using 'make simpleImage.xilinx (where xilinx.dts is my device tree file) i tried to change the link_address in arch/powerpc/boot/wrapper from 0x400000 to 0xf4000000. when i analysed the dump with step mode in xmd, it fails in platform_init()function in arch/powerpc/boot/simpleboot.c may be at /* Only interested in memory based at 0 */
for (i = 0; i < *na; i++)
if (*reg++ != 0)
fatal("Memory range is not based at address 0\n"); can anyone tell what are the changes i shoud do if my memory ranges from 0xf8000000 to 0xfbffffff..? (64MB)
is it possible to change the physical address of kernel from 0 to any other location..? is the option provided in menuconfig..? or in any linker script..?
Thanks in advance,Sumesh.
_________________________________________________________________
Looking for a new car this winter? Let us help with car news, reviews and more
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT
[-- Attachment #2: Type: text/html, Size: 5713 bytes --]
^ permalink raw reply
* riscwatch shows up core status UNKNOWN for 970mp ppc processor
From: anil kumar @ 2009-07-16 12:32 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3608 bytes --]
Hello
I am newbie to RISCWatch and debugging using JTAG interface .I want to debug
Linux Kernel on target board
using jtag interface provided on board.
To debug 970MP dual core ppc processor on traget board, I installed
RISCWatch software on my window host.
My Setup:
----------
Host <--(over ethernet)--> RISCWatch 13H6423 <--(jtag interface)--> 970MP
Processor
I am able to detect two core on target 970MP processor but it shows both
cores as `UNKNOWN` . I have no idea,
why riscwatch shows up status of both cores as UNKNOWN?
I would like to mention:
-------------------------
1) After attaching JTAG cable & switching on riscwatch box, powered cycle
was done on the target board
and restart RISCWatch. But still core status is shown `UNKNOWN`
2) For PVR value 0x00440101, I used `REV = 1' in rwppc.env file. Correct us
if I am wrong.
3) I am able to ping RISCWatch 13H6423 from host system.
4) When I reset target board, target status changes from "UNKNOWN to HALTED"
and "HALTED to UNKNOWN"
I noticed that PVR register value is 0x00440101. I am not sure if this
confirms that revision of the processor(970mp) is 1.
Please find the rwppc.env file (C:\Program Files\RISCWatch\rwppc.env) that I
configured:
------------------------------
----------------------------------------------------------
PROC = 970MP
REV = 1
TARGET_TYPE = jtag_eth
TARGET_NAME = 192.168.10.5
RWPPC_DIR = .
SEARCH_PATH = .
LOG_FILE_DIR = .
SAVE_LAYOUT = no
PRD_FILE = rwppc.prd
Please find board information:
------------------------------
KAT2000 970MP (1.0)=> boardinfo
board config data version: 1.0
processor name : 970MP
processor PVR value : 0x00440101
timer clock frequency : 112500000
total SDRAM memory : 4096MB
SDRAM frequency : 533333333
system clk frequency (Hz): 225000000
CPU frequency : 1800000000
CPU frequency ind. est. : 1800001200
CPU to EI speed ratio : 2:1
frequency scaling divider: 1
serial clk frequency : 1843200
HID0 value : 0011008180000000
HID1 value : fd3c200000000000
HID4 value : 0000001000000000
HID5 value : 0000000000000080
SDR1 value : 0000000000d00002
PIR value : 00000000
Ethernet hardware addr 0 : FFFFFFFFFFFF
RISCWatch log:
--------------
12:37:18 - RISCWatch program start
12:37:18 - RISCWatch v7.1 for Windows XP
12:37:18 - Current directory: C:\Program Files\RISCWatch
12:37:18 - Environment file: RWPPC.ENV
12:37:18 - RWPPC_DIR = .
12:37:18 - TARGET_TYPE = JTAG_Ethernet
12:37:18 - TARGET_NAME = 192.168.10.5
12:37:18 - Requested Processor 970MPRev1:CORE1
12:37:18 - Requested Processor 970MPRev1:CORE2
12:37:18 - Unable to get port number for jtag_eth service, using 6470
default 12:37:30 - Configuring probe 12:37:30 - cf default; jtagch a32,a32
12:37:31 - HPE8130A Series Emulation System
12:37:31 - Version: A.01.20 04Apr02 Unreleased
12:37:31 - Location: Generics
12:37:31 - HPEGPUL PowerPC 970 JTAG Emulator
12:37:31 - Version: A.00.I0 22Jul08 13:48 Proto
12:37:31 - WARNING : Could not read processor status, slowing JTAG clock
and retrying
12:37:31 - ERROR : bad status received, see README for possible causes
12:37:36 - Starting MPS mode
12:43:18 - STATUS : CORE1 status changed from UNKNOWN to HALTED
12:43:18 - STATUS : CORE2 status changed from UNKNOWN to HALTED
Note---> Status become HALTED because I reset target board
12:43:19 - ERROR : CORE1 status changed from HALTED to UNKNOWN
12:43:19 - ERROR : CORE2 status changed from HALTED to UNKNOWN
Thanks in advance.
Regards,
Anil
[-- Attachment #2: Type: text/html, Size: 4143 bytes --]
^ permalink raw reply
* Re: [PATCH] kmemleak: Allow kmemleak to be built on powerpc
From: Catalin Marinas @ 2009-07-16 13:16 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20090716113100.GB7102@zod.rchland.ibm.com>
On Thu, 2009-07-16 at 07:31 -0400, Josh Boyer wrote:
> On Thu, Jul 16, 2009 at 05:43:50PM +1000, Michael Ellerman wrote:
> >On Thu, 2009-07-16 at 11:25 +1000, Michael Ellerman wrote:
> >> Very lightly tested, doesn't crash the kernel.
> >>
> >> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> >> ---
> >>
> >> It doesn't look like we actually need to add any support in the
> >> arch code - or is there something I'm missing?
> >
> >Hmm, I think we want to add annotations in lib/lmb.c don't we? That's
> >our low-level pre-bootmem allocator.
> >
> >And we have the same problem with _edata as x86.
>
> I'll point out that the Fedora developers enabled this in the rawhide kernels
> for 3 days, and then turned it back off because most of the things found were
> false positives.
Yes, but with 2.6.31-rc3 the number of false positives dropped
considerably. I don't plan to push any new kmemleak patches for 2.6.31
(probably only a bug-fix).
Anyway, even when it reports real leaks, it is very time consuming to
investigate.
I don't have any PPC hardware but as long as someone sorts out things
like _edata or other PPC-specific allocators which aren't currently
tracked by kmemleak, I'm OK with the original patch:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
--
Catalin
^ permalink raw reply
* rtas instantiation when commandline contains mem
From: Benjamin Krill @ 2009-07-16 13:12 UTC (permalink / raw)
To: enjamin Herrenschmidt, Michael Ellerman; +Cc: linuxppc-dev
Hi,
the rtas instantiation (prom_init.c) doesn't work correctly if the
kernel parameter "mem=" is used. The current code doesn't evaluate
the kernel parameter which causes the issue that alloc_down
allocates somewhere in the "real" memory space. So it can
happen that the allocation space is above "mem=".
Commit 2babf5c2ec2f2d5de3e38d20f7df7fd815fd10c9 removes the
evaluation of "mem=".
cheers
ben
^ permalink raw reply
* ECC & Magic bitmask errors with JFFS2 file system on 6.23 kernel for powerpc
From: Rupesh Kumar @ 2009-07-16 15:03 UTC (permalink / raw)
To: linuxppc-dev
Hi
We are using Linux kernel 2.6.23 from freescale LTIB
(MPC8313E_RDB_K26_20081226-LTIB.iso) on our custom board.
JFFS2 is used as RFS and nand write.jffs2 utility in the u-boot is used
to burn the image on to the nand flash.
When we boot for the first time everything seems to be OK. On subsequent
reboots we are seeing following error messages reported by kernel on
bootup.
In addition we also see Magic bitmask errors being reported.
///////////////////////////
mtd->read(0x400 bytes from 0x1b00000) returned ECC error
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01b001d0:
0xfffe instead
mtd->read(0x400 bytes from 0x2500000) returned ECC error
mtd->read(0x400 bytes from 0x27c0000) returned ECC error
mtd->read(0x400 bytes from 0x2c20000) returned ECC error
mtd->read(0x400 bytes from 0x2cc0000) returned ECC error
mtd->read(0x400 bytes from 0x2d00000) returned ECC error
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x02d00074:
0xfffe instead
Empty flash at 0x02d00078 ends at 0x02d003e4
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x02d003e4:
0xffef instead
Empty flash at 0x02d003e8 ends at 0x02d00780
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x02d00780:
0xfffb instead
mtd->read(0x400 bytes from 0x3320000) returned ECC error
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03320190:
0xffff instead
Empty flash at 0x03320194 ends at 0x0332047c
////////////////////////////
We verified erase size passed as an argument for creating jffs2 file
system (initial googling on the issue).
After contacting freescale we came to know that, it is a known issue and
they dont have planned to work on this in near future. :(
Please give your valuable suggestions so that we can fix this problem and
make our board running properly.
Thanks
Rupesh
^ permalink raw reply
* Re: [PATCH] Hold reference to device_node during EEH event handling
From: Mike Mason @ 2009-07-16 16:33 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, linasvepstas, Paul Mackerras
In-Reply-To: <1247708506.9851.8.camel@concordia>
Michael Ellerman wrote:
> On Wed, 2009-07-15 at 14:43 -0700, Mike Mason wrote:
>> This patch increments the device_node reference counter when an EEH
>> error occurs and decrements the counter when the event has been
>> handled. This is to prevent the device_node from being released until
>> eeh_event_handler() has had a chance to deal with the event. We've
>> seen cases where the device_node is released too soon when an EEH
>> event occurs during a dlpar remove, causing the event handler to
>> attempt to access bad memory locations.
>>
>> Please review and let me know of any concerns.
>
> Taking a reference sounds sane, but ...
>
>> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
>>
>> --- a/arch/powerpc/platforms/pseries/eeh_event.c 2008-10-09 15:13:53.000000000 -0700
>> +++ b/arch/powerpc/platforms/pseries/eeh_event.c 2009-07-14 14:14:00.000000000 -0700
>> @@ -75,6 +75,14 @@ static int eeh_event_handler(void * dumm
>> if (event == NULL)
>> return 0;
>>
>> + /* EEH holds a reference to the device_node, so if it
>> + * equals 1 it's no longer valid and the event should
>> + * be ignored */
>> + if (atomic_read(&event->dn->kref.refcount) == 1) {
>> + of_node_put(event->dn);
>> + return 0;
>> + }
>
> That's really gross :)
Agreed. I'll look for another way to determine if device is gone and the event should be ignored. Suggestions are welcome :-)
>
> And what happens if the refcount goes to 1 just after the check? ie.
> here.
>
>> /* Serialize processing of EEH events */
>> mutex_lock(&eeh_event_mutex);
>> eeh_mark_slot(event->dn, EEH_MODE_RECOVERING);
>
>
> cheers
>
^ permalink raw reply
* Re: riscwatch shows up core status UNKNOWN for 970mp ppc processor
From: Hollis Blanchard @ 2009-07-16 17:25 UTC (permalink / raw)
To: anil kumar; +Cc: linuxppc-dev
In-Reply-To: <73afa9bf0907160532l5525124cg72bee2631e3dab66@mail.gmail.com>
On Thu, Jul 16, 2009 at 5:32 AM, anil kumar<anildahiya80@gmail.com> wrote:
> Hello
> I am newbie to RISCWatch and debugging using JTAG interface .I want to de=
bug
> Linux Kernel on target board
> using jtag interface provided on board.
>
> To=A0 debug 970MP dual core ppc processor on traget board, I installed
> RISCWatch software on my window host.
>
> My Setup:
> ----------
> =A0=A0 Host <--(over ethernet)--> RISCWatch 13H6423 <--(jtag interface)--=
> 970MP
> Processor
>
> I am able to detect two core on target 970MP processor but it shows both
> cores as `UNKNOWN` . I have no idea,
> why riscwatch shows up status of both cores as UNKNOWN?
You should probably contact ppcsupp@us.ibm.com instead of this mailing list=
.
-Hollis
^ permalink raw reply
* Re: [PATCH] kmemleak: Allow kmemleak to be built on powerpc
From: Catalin Marinas @ 2009-07-16 17:52 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1247730230.18228.5.camel@concordia>
On Thu, 2009-07-16 at 17:43 +1000, Michael Ellerman wrote:
> On Thu, 2009-07-16 at 11:25 +1000, Michael Ellerman wrote:
> > Very lightly tested, doesn't crash the kernel.
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> > ---
> >
> > It doesn't look like we actually need to add any support in the
> > arch code - or is there something I'm missing?
>
> Hmm, I think we want to add annotations in lib/lmb.c don't we? That's
> our low-level pre-bootmem allocator.
Yes, I think so (I'm not using this on ARM or x86 so I can't really test
it). Without these hooks, there kmemleak reports aren't that useful
(probably too many).
--
Catalin
^ permalink raw reply
* Re: [PATCH] mpc83xx/usb.c: fix usb mux setup for mpc834x
From: Peter Korsgaard @ 2009-07-16 20:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <E3FB2692-D60E-4C06-BEDD-45441E67458E@kernel.crashing.org>
>>>>> "Kumar" == Kumar Gala <galak@kernel.crashing.org> writes:
Hi,
Kumar> On Jun 9, 2009, at 6:43 AM, Peter Korsgaard wrote:
>> usb0 and usb1 mux settings in the sicrl register were swapped (twice!)
>> in mpc834x_usb_cfg(), leading to various strange issues with fsl-ehci
>> and full speed devices.
>>
>> The USB port config on mpc834x is done using 2 muxes: Port 0 is
>> always used for MPH port 0, and port 1 can either be used for MPH
>> port 1 or DR (unless DR uses TMDI phy or OTG, then it uses both
>> ports) - See 8349 RM figure 1-4..
>>
>> mpc8349_usb_cfg() had this inverted for the DR, and it also had
>> the bit positions of the usb0 / usb1 mux settings swapped. It
>> would basically work if you specified port1 instead of port0 for
>> the MPH controller (and happened to use ULPI phys), which is what
>> all the 834x dts have done, even though that configuration is
>> physically invalid.
>>
>> Instead fix mpc8349_usb_cfg() and adjust the dts files to match
>> reality.
>>
>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Kumar> applied.. Please remind me to send this linux-stable for .30 and .29
*Remind*
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 1/2 v3] fs_enet/mii-fec.c: fix MII speed calculation
From: Wolfgang Denk @ 2009-07-16 21:21 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, netdev
In-Reply-To: <fa686aa40907151017n76524708tdb028689adad4b5f@mail.gmail.com>
Dear Grant Likely,
In message <fa686aa40907151017n76524708tdb028689adad4b5f@mail.gmail.com> you wrote:
> On Wed, Jul 15, 2009 at 9:18 AM, Wolfgang Denk<wd@denx.de> wrote:
> > The MII speed calculation was based on the CPU clock (ppc_proc_freq),
> > but for MPC512x we must use the bus clock instead.
> >
> > This patch makes it use the correct clock and makes sure we don't
> > clobber reserved bits in the MII_SPEED register.
...
> Drop the common code bit. The 5200 and 5121 are different devices and
> it is a tiny bit of code. I don't think there is any benefit to
> having it as a common function. Just roll the get_mii_speed function
> in the mii-fec driver itself.
I don't like to see the code repeated - it makes maintenance harder
and increases the memory footprint. But if you like it that way I'll
do that.
> Also, this patch can be quite a bit simpler if you use the .data
> pointer in the drivers match table to specify the function used to
> return the bus clock speed. Something like this:
OK, will do that, too.
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
Weekends were made for programming. - Karl Lehenbauer
^ permalink raw reply
* Re: [PATCH 2/2] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Wolfgang Denk @ 2009-07-16 21:21 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, netdev
In-Reply-To: <fa686aa40907151018n194a154cmb8549c98c673d2bb@mail.gmail.com>
Dear Grant Likely,
In message <fa686aa40907151018n194a154cmb8549c98c673d2bb@mail.gmail.com> you wrote:
> On Wed, Jul 15, 2009 at 9:18 AM, Wolfgang Denk<wd@denx.de> wrote:
> > This patch adds error checking and prevents clobbering unrelated bits
> > (reserved bits or the DIS_PREAMBLE bit) when writing the MII_SPEED
> > register on MPC52xx systems.
...
> As I mentioned in the other patch, I don't want the 5121 and 5200 FEC
> devices using common code for this. It is a tiny block of code and
> they are different devices. Just open code the needed calculation
> into this driver.
OK, will do.
^ permalink raw reply
* [PATCH 1/2 v4] fs_enet/mii-fec.c: fix MII speed calculation
From: Wolfgang Denk @ 2009-07-16 21:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev, Wolfgang Denk
In-Reply-To: <1247671133-12148-1-git-send-email-wd@denx.de>
The MII speed calculation was based on the CPU clock (ppc_proc_freq),
but for MPC512x we must use the bus clock instead.
This patch makes it use the correct clock and makes sure we don't
clobber reserved bits in the MII_SPEED register.
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: <netdev@vger.kernel.org>
Signed-off-by: Wolfgang Denk <wd@denx.de>
---
drivers/net/fs_enet/mii-fec.c | 35 +++++++++++++++++++++++++++++++----
1 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c
index 75a0999..62b2d7a 100644
--- a/drivers/net/fs_enet/mii-fec.c
+++ b/drivers/net/fs_enet/mii-fec.c
@@ -103,11 +103,11 @@ static int fs_enet_fec_mii_reset(struct mii_bus *bus)
static int __devinit fs_enet_mdio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct resource res;
struct mii_bus *new_bus;
struct fec_info *fec;
- int ret = -ENOMEM, i;
+ int (*get_bus_freq)(struct device_node *) = match->data;
+ int ret = -ENOMEM, clock, speed;
new_bus = mdiobus_alloc();
if (!new_bus)
@@ -133,13 +133,34 @@ static int __devinit fs_enet_mdio_probe(struct of_device *ofdev,
if (!fec->fecp)
goto out_fec;
- fec->mii_speed = ((ppc_proc_freq + 4999999) / 5000000) << 1;
+ if (get_bus_freq) {
+ clock = get_bus_freq(ofdev->node);
+
+ if (!clock) {
+ dev_err(&ofdev->dev, "could not determine IPS/IPB clock\n");
+ goto out_unmap_regs;
+ }
+ } else
+ clock = ppc_proc_freq;
+
+ /* scale for a MII clock <= 2.5 MHz */
+ speed = (clock + 2499999) / 2500000;
+
+ /* only 6 bits (25:30) available for MII speed */
+ if (speed > 0x3F) {
+ speed = 0x3F;
+ dev_err(&ofdev->dev,
+ "MII clock (%d Hz) exceeds max (2.5 MHz)\n",
+ clock / speed);
+ }
+
+ fec->mii_speed = speed << 1;
setbits32(&fec->fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
setbits32(&fec->fecp->fec_ecntrl, FEC_ECNTRL_PINMUX |
FEC_ECNTRL_ETHER_EN);
out_be32(&fec->fecp->fec_ievent, FEC_ENET_MII);
- out_be32(&fec->fecp->fec_mii_speed, fec->mii_speed);
+ clrsetbits_be32(&fec->fecp->fec_mii_speed, 0x7E, fec->mii_speed);
new_bus->phy_mask = ~0;
new_bus->irq = kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
@@ -188,6 +209,12 @@ static struct of_device_id fs_enet_mdio_fec_match[] = {
{
.compatible = "fsl,pq1-fec-mdio",
},
+#if defined(CONFIG_PPC_MPC512x)
+ {
+ .compatible = "fsl,mpc5121-fec-mdio",
+ .data = mpc5xxx_get_bus_frequency,
+ },
+#endif
{},
};
--
1.6.0.6
^ permalink raw reply related
* [PATCH 2/2 v2] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Wolfgang Denk @ 2009-07-16 21:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev, Wolfgang Denk
In-Reply-To: <1247671133-12148-1-git-send-email-wd@denx.de>
This patch adds error checking and prevents clobbering unrelated bits
(reserved bits or the DIS_PREAMBLE bit) when writing the MII_SPEED
register on MPC52xx systems.
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: <netdev@vger.kernel.org>
---
drivers/net/fec_mpc52xx.c | 2 +-
drivers/net/fec_mpc52xx_phy.c | 21 ++++++++++++++++++---
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index cc78633..b69d440 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -639,7 +639,7 @@ static void mpc52xx_fec_hw_init(struct net_device *dev)
/* set phy speed.
* this can't be done in phy driver, since it needs to be called
* before fec stuff (even on resume) */
- out_be32(&fec->mii_speed, priv->mdio_speed);
+ clrsetbits_be32(&fec->mii_speed, 0x7E, priv->mdio_speed);
}
/**
diff --git a/drivers/net/fec_mpc52xx_phy.c b/drivers/net/fec_mpc52xx_phy.c
index 31e6d62..4c33dc5 100644
--- a/drivers/net/fec_mpc52xx_phy.c
+++ b/drivers/net/fec_mpc52xx_phy.c
@@ -70,7 +70,7 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of,
struct mpc52xx_fec_mdio_priv *priv;
struct resource res = {};
int err;
- int i;
+ int i, clock, speed;
bus = mdiobus_alloc();
if (bus == NULL)
@@ -105,8 +105,23 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of,
dev_set_drvdata(dev, bus);
/* set MII speed */
- out_be32(&priv->regs->mii_speed,
- ((mpc5xxx_get_bus_frequency(of->node) >> 20) / 5) << 1);
+ clock = mpc5xxx_get_bus_frequency(of->node);
+ if (!clock) {
+ dev_err(&of->dev, "could not determine IPS/IPB clock\n");
+ goto out_unmap;
+ }
+
+ /* scale for a MII clock <= 2.5 MHz */
+ speed = (clock + 2499999) / 2500000;
+
+ /* only 6 bits (25:30) available for MII speed */
+ if (speed > 0x3F) {
+ speed = 0x3F;
+ dev_err(&of->dev, "MII clock (%d Hz) exceeds max (2.5 MHz)\n",
+ clock / speed);
+ }
+
+ clrsetbits_be32(&priv->regs->mii_speed, 0x7E, speed << 1);
err = of_mdiobus_register(bus, np);
if (err)
--
1.6.0.6
^ permalink raw reply related
* Re: booting MPC8313 based board with yaffs2 RFS
From: tonyliu @ 2009-07-17 2:07 UTC (permalink / raw)
To: Rupesh Kumar; +Cc: linuxppc-dev
In-Reply-To: <OFB2EFC395.7BD1B8AD-ON652575F4.00512780-652575F4.00513235@lntemsys.com>
Rupesh Kumar wrote:
> Hi
> I am using MPC8313 board which is currently booting with JFFS2 root file
> system.
> I am using linux kernel version 2.6.23 from FreeScale's LTIB for MPC8313.
>
> As, I want it to boot with YAFFS2 root file system, I did compile kernel
> with yaffs2 support, craeted yaffs2 rootfile system and passed yaffs2
> partiton of nand in bootargs. However it didnot work.
>
>
> If any one has done it successfully, can please share the steps to be
> followed ?
>
More detailed info maybe helpful for debugging this issue.
1. What nand flash is on-board? what's the size of the nand flash page
size, 512/2048?
2. what's the version of mkyaffs2image you are using?
3. Can you mount an empty nand flash partition using yaffs2 type,
mount /dev/mtdblock##x xxx
4. It's better to attatch bootup message.
Tony
> Thanks
> Rupesh
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: rtas instantiation when commandline contains mem
From: Benjamin Herrenschmidt @ 2009-07-16 22:36 UTC (permalink / raw)
To: Benjamin Krill; +Cc: linuxppc-dev
In-Reply-To: <20090716131246.GB22901@codiert.org>
On Thu, 2009-07-16 at 15:12 +0200, Benjamin Krill wrote:
> Hi,
>
> the rtas instantiation (prom_init.c) doesn't work correctly if the
> kernel parameter "mem=" is used. The current code doesn't evaluate
> the kernel parameter which causes the issue that alloc_down
> allocates somewhere in the "real" memory space. So it can
> happen that the allocation space is above "mem=".
>
> Commit 2babf5c2ec2f2d5de3e38d20f7df7fd815fd10c9 removes the
> evaluation of "mem=".
Ah yes, we don't constraint prom_init.c to mem=, only the kernel
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2 v3] fs_enet/mii-fec.c: fix MII speed calculation
From: Grant Likely @ 2009-07-16 22:37 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, netdev
In-Reply-To: <20090716212129.70710832E416@gemini.denx.de>
On Thu, Jul 16, 2009 at 3:21 PM, Wolfgang Denk<wd@denx.de> wrote:
> Dear Grant Likely,
>
> In message <fa686aa40907151017n76524708tdb028689adad4b5f@mail.gmail.com> =
you wrote:
>> On Wed, Jul 15, 2009 at 9:18 AM, Wolfgang Denk<wd@denx.de> wrote:
>> > The MII speed calculation was based on the CPU clock (ppc_proc_freq),
>> > but for MPC512x we must use the bus clock instead.
>> >
>> > This patch makes it use the correct clock and makes sure we don't
>> > clobber reserved bits in the MII_SPEED register.
> ...
>> Drop the common code bit. =A0The 5200 and 5121 are different devices and
>> it is a tiny bit of code. =A0I don't think there is any benefit to
>> having it as a common function. =A0Just roll the get_mii_speed function
>> in the mii-fec driver itself.
>
> I don't like to see the code repeated - it makes maintenance harder
> and increases the memory footprint. But if you like it that way I'll
> do that.
Neither do I, but in this case has some mitigating factors. diff stat
is interesting:
Old:
arch/powerpc/include/asm/mpc5xxx.h | 10 +++++++++
arch/powerpc/sysdev/mpc5xxx_clocks.c | 37 ++++++++++++++++++++++++++++++=
++++
drivers/net/fs_enet/mii-fec.c | 13 +++++++++--
drivers/net/fec_mpc52xx.c | 2 +-
drivers/net/fec_mpc52xx_phy.c | 6 ++++--
5 files changed, 62 insertions(+), 6 deletions(-)
New:
drivers/net/fs_enet/mii-fec.c | 35 +++++++++++++++++++++++++++++++----
drivers/net/fec_mpc52xx.c | 2 +-
drivers/net/fec_mpc52xx_phy.c | 21 ++++++++++++++++++---
3 files changed, 50 insertions(+), 8 deletions(-)
If the two devices were somewhat related then my opinion might be
different. However the combination of the tiny amount of calculation
code, the drivers being kept completely separate (or at least as
separate as they were before), the smaller code impact, and the lower
driver complexity (because the calculation code is inline instead of
in a different file) makes me like the second approach is better.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2 v4] fs_enet/mii-fec.c: fix MII speed calculation
From: Grant Likely @ 2009-07-16 22:44 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, netdev
In-Reply-To: <1247780546-4426-1-git-send-email-wd@denx.de>
On Thu, Jul 16, 2009 at 3:42 PM, Wolfgang Denk<wd@denx.de> wrote:
> The MII speed calculation was based on the CPU clock (ppc_proc_freq),
> but for MPC512x we must use the bus clock instead.
>
> This patch makes it use the correct clock and makes sure we don't
> clobber reserved bits in the MII_SPEED register.
>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: <netdev@vger.kernel.org>
Looks good to me. Thanks for the work!
I assume this is tested. I have not tested this on my board, and I've
got one question below, but otherwise I think I can say....
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> - =A0 =A0 =A0 fec->mii_speed =3D ((ppc_proc_freq + 4999999) / 5000000) <<=
1;
> + =A0 =A0 =A0 if (get_bus_freq) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock =3D get_bus_freq(ofdev->node);
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!clock) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&ofdev->dev, "could=
not determine IPS/IPB clock\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_unmap_regs;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> + =A0 =A0 =A0 } else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock =3D ppc_proc_freq;
> +
> + =A0 =A0 =A0 /* scale for a MII clock <=3D 2.5 MHz */
> + =A0 =A0 =A0 speed =3D (clock + 2499999) / 2500000;
The calculation has changed here for non mpc5121 users. Shouldn't the
"clock =3D ppc_proc_freq;" line above be "clock =3D ppc_proc_freq / 2;"?
Or was this also a bug in the original driver?
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2 v2] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Grant Likely @ 2009-07-16 22:48 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, netdev
In-Reply-To: <1247780546-4426-2-git-send-email-wd@denx.de>
On Thu, Jul 16, 2009 at 3:42 PM, Wolfgang Denk<wd@denx.de> wrote:
> This patch adds error checking and prevents clobbering unrelated bits
> (reserved bits or the DIS_PREAMBLE bit) when writing the MII_SPEED
> register on MPC52xx systems.
>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: <netdev@vger.kernel.org>
Mostly good. One comment below. When it's resolved, feel free to add
my acked-by line. Thanks for getting this done.
> @@ -105,8 +105,23 @@ static int mpc52xx_fec_mdio_probe(struct of_device *=
of,
> =A0 =A0 =A0 =A0dev_set_drvdata(dev, bus);
>
> =A0 =A0 =A0 =A0/* set MII speed */
> - =A0 =A0 =A0 out_be32(&priv->regs->mii_speed,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((mpc5xxx_get_bus_frequency(of->node) >> 20=
) / 5) << 1);
> + =A0 =A0 =A0 clock =3D mpc5xxx_get_bus_frequency(of->node);
> + =A0 =A0 =A0 if (!clock) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&of->dev, "could not determine IPS/=
IPB clock\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_unmap;
> + =A0 =A0 =A0 }
Just thought of something. If it cannot find the clock, then wouldn't
it be better to just use the maximum divider and print a warning
instead of bailing completely? This goes for the other patch as well.
> +
> + =A0 =A0 =A0 /* scale for a MII clock <=3D 2.5 MHz */
> + =A0 =A0 =A0 speed =3D (clock + 2499999) / 2500000;
> +
> + =A0 =A0 =A0 /* only 6 bits (25:30) available for MII speed */
> + =A0 =A0 =A0 if (speed > 0x3F) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 speed =3D 0x3F;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&of->dev, "MII clock (%d Hz) exceed=
s max (2.5 MHz)\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock / speed);
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 clrsetbits_be32(&priv->regs->mii_speed, 0x7E, speed << 1);
>
> =A0 =A0 =A0 =A0err =3D of_mdiobus_register(bus, np);
> =A0 =A0 =A0 =A0if (err)
> --
> 1.6.0.6
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox