* Wolfgang's updates
From: Tony @ 2006-03-02 13:20 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 178 bytes --]
Dear Mr.WolfGang,
Can u do me a favor,I need U_boot 1.1.4, I am trying to download it from internet,but I am failed! I am very appreciate your help!thx!
your Tony
[-- Attachment #2: Type: text/html, Size: 718 bytes --]
^ permalink raw reply
* 802.3ah OAM
From: feng @ 2006-03-02 7:08 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
DQpISTsNCiAgDQogICAgICAgd2hvIGhhcyA4MDIuM2FoIE9BTSAgY29kZSAoQyBsYW5ndWFnZSAg
aW4gdGhlIGxpbnV4KSAgPz8/Pw0KDQogICAgICAgVGhhbmtzISEhIQ0KDQoNCg0KoaGhoaGhoaGh
oaGhoaGhoWZlbmcNCqGhoaGhoaGhoaGhoaGhoaFjaGluYWZlbmcyMDA4QDE2My5jb20NCqGhoaGh
oaGhoaGhoaGhoaGhoaGhMjAwNi0wMy0wMg0K
^ permalink raw reply
* Re: boot failure on lite5200b board
From: John Rigby @ 2006-03-02 0:52 UTC (permalink / raw)
To: #LI JIANGGAN#; +Cc: linuxppc-embedded
In-Reply-To: <84A109BF918D934CB46ACF33BCE187C002D54D94@mail02.student.main.ntu.edu.sg>
SGVyZSBpcyBhIHVib290IHNldHVwIHRoYXQgd29ya3Mgd2l0aCBhIGZyZWVzY2FsZSBrZXJuZWw6
CmJvb3RkZWxheT01CmJhdWRyYXRlPTExNTIwMApwcmVib290PWVjaG87ZWNobyBUeXBlICJydW4g
Zmxhc2hfbmZzIiB0byBtb3VudCByb290IGZpbGVzeXN0ZW0gb3ZlciBORlM7ZWNobwphdXRvbG9h
ZD1ubwpldGhhY3Q9RkVDIEVUSEVSTkVUCnJhbWFyZ3M9c2V0ZW52IGJvb3RhcmdzIHJvb3Q9L2Rl
di9yYW0gcncKamZmczJhcmdzPXNldGVudiBib290YXJncyByb290PS9kZXYvbXRkYmxvY2swIHJ3
IHJvb3Rmc3R5cGU9amZmczIKYWRkaXA9c2V0ZW52IGJvb3RhcmdzICQoYm9vdGFyZ3MpCmlwPSQo
aXBhZGRyKTokKHNlcnZlcmlwKTokKGdhdGV3YXlpcCk6JChuZXRtYXNrKTokKGhvc3RuYW1lKTok
KG5ldGRldik6b2ZmCnBhbmljPTEKZmxhc2hfbmZzPXJ1biBuZnNhcmdzIGFkZGlwO2Jvb3RtICQo
a2VybmVsX2FkZHIpCmZsYXNoX3NlbGY9cnVuIHJhbWFyZ3MgYWRkaXA7Ym9vdG0gJChrZXJuZWxf
YWRkcikgJChyYW1kaXNrX2FkZHIpCmZsYXNoX2pmZnMyPXJ1biBqZmZzMmFyZ3M7Ym9vdG0gJChr
ZXJuZWxfYWRkcikKbmV0X25mcz10ZnRwIDIwMDAwMCAkKGJvb3RmaWxlKTtydW4gbmZzYXJncyBh
ZGRpcDtib290bQpuZXRkZXY9ZXRoMApldGhhZGRyPTAwOjA0OjlmOjIyOjMzOjQ0CmJvb3RmaWxl
PS90ZnRwYm9vdC91SW1hZ2UKa2VybmVsX2FkZHI9ZmZkMDAwMDAKcm9vdHBhdGg9L3RmdHBib290
L2x0aWIKZmlsZXNpemU9YzlkNzAwCmZpbGVhZGRyPTEwMDAwMDAKZ2F0ZXdheWlwPTE3Mi4yNy4y
NTUuMjU0Cm5ldG1hc2s9MjU1LjI1NS4wLjAKaXBhZGRyPTE3Mi4yNy4xNTIuOTkKc2VydmVyaXA9
MTcyLjI3LjE1Mi41CmJvb3RjbWQ9cnVuIG5ldF9uZnMKbmZzYXJncz1zZXRlbnYgYm9vdGFyZ3Mg
Y29uc29sZT10dHlTMCwxMTUyMDAgcm9vdD0vZGV2L25mcyBydwpuZnNyb290PSQoc2VydmVyaXAp
OiQocm9vdHBhdGgpCnN0ZGluPXNlcmlhbApzdGRvdXQ9c2VyaWFsCnN0ZGVycj1zZXJpYWwKCkNo
YW5nZSBpcCBpbmZvLCBib290ZmlsZSwgcm9vdHBhdGggZXRjIHRvIGZpdCB5b3UgY29uZmlnLgpJ
ZiB5b3Ugd2FudCBpdCB0byB3b3JrIHdpdGggU3lsdmFpbidzIGtlcm5lbCB0aGVuIHlvdSBuZWVk
IHRvIGNoYW5nZQp0dHlTMCB0byB0dHlQU0MwLgoKQWxzbyBhZGQgYSBwcmludGVudiBqdXN0IGJl
Zm9yZSB0aGUgYm9vdG0gc28geW91IGNhbiB2ZXJpZnkgdGhhdCB5b3VyCmJvb3RhcmdzIHJlYWxs
eSBhcmUgZ2V0dGluZyBzZXQgY29ycmVjdGx5LgoKT24gMy8xLzA2LCAjTEkgSklBTkdHQU4jIDxs
aWppYW5nZ2FuQHBtYWlsLm50dS5lZHUuc2c+IHdyb3RlOgo+Cj4KPiBob3cgYWJvdXQgdGhlIGZv
bGxvd2luZyBVLWJvb3Qgc2V0dGluZ3M6Cj4KPiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4KPgo+Cj4gSGl0IGFueSBrZXkgdG8gc3RvcCBhdXRvYm9vdDogIDAKPiA9PiBwcmludGVudgo+
IGJhdWRyYXRlPTExNTIwMAo+IGF1dG9sb2FkPW5vCj4gZXRoYWN0PUZFQyBFVEhFUk5FVAo+IGV0
aGFkZHI9MDA6MDE6OUY6MDA6Mjc6MkYKPiBwcmVib290PWVjaG87IGVjaG8gQXV0b3N0YXJ0aW5n
LiBQcmVzcyBhbnkga2V5IHRvIGFib3J0Li47IGVjaG8KPiBib290ZGVsYXk9NQo+IGhvc3RuYW1l
PWljZWN1YmUKPiBib290ZmlsZT1NUEM1MjAwL3VJbWFnZQo+IG52PW5mc3Jvb3Qgcm9vdD0vZGV2
L25mcyBydyBuZnNyb290PTEwLjE5MC4zLjExMzovb3B0L2VsZGsvcm9vdGZzCj4gbmV0bWFzaz0y
NTUuMjU1LjI0MC4wCj4gaXBhZGRyPTEwLjE5MC4zLjE0NAo+IHNlcnZlcmlwPTEwLjE5MC4zLjEw
Mwo+IGJvb3RjbWQ9cnVuIG5ldF9uZnMKPgo+IHJvb3Rmcz1yb290PS9kZXYvbmZzIHJ3Cj4gbmV0
ZGV2PWV0aDAKPiByb290cGF0aD0vb3B0L2VsZGstNC0wL3Jvb3Rmcwo+IG5mc2FyZ3M9c2V0ZW52
IGJvb3RhcmdzIHJvb3Q9L2Rldi9uZnMgcncKPiBuZnNyb290PTEwLjE5MC4zLjEwMzovb3B0L2Vs
ZGstNC0wL3Jvb3Rmcwo+Cj4gcmFtYXJncz1zZXRlbnYgYm9vdGFyZ3Mgcm9vdD0vZGV2L3JhbSBy
dwo+IGFkZGlwPXNldGVudiBib290YXJncwo+IGlwPTEwLjE5MC4zLjE0NDoxMC4xOTAuMy4xMDM6
MTAuMTkwLjMuMTAzOjI1NS4yNTUuMjQwLjA6aWNlY3ViZTpldGgwOm9mZgo+IHBhbmljPTEKPiBu
ZXRfbmZzPXRmdHAgMjAwMDAwIE1QQzUyMDAvdUltYWdlO3J1biBuZnNhcmdzIGFkZGlwO2Jvb3Rt
Cj4KPiBzdGRpbj1zZXJpYWwKPiBzdGRvdXQ9c2VyaWFsCj4gc3RkZXJyPXNlcmlhbAo+Cj4gRW52
aXJvbm1lbnQgc2l6ZTogNzM4LzY1NTMyIGJ5dGVzCj4gPT4gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIC4KPiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLgo+Cj4KPgo+IFRo
ZSBvdXRwdXQgaXMgc3RpbGwgdGhlIHNhbWUsIGl0IGhhbmdzIGFmdGVyIGRpc3BsYXlpbmcgYXJj
aDpleGl0Cj4KPiBJIGhhdmUgYWxzbyB0cmllZCB0aGUgYWJvdmUgc2V0dGluZ3Mgd2l0aCBjb25z
b2xlIHNldCwgaXQgZ2l2ZXMgdGhlIHNhbWUKPiBvdXRwdXQKPgo+IEkgYW0gcmVhbGx5IHdvbmRl
cmluZyB3aGV0aGVyIHRoZSBwcm9ibGVtIGlzIHdpdGggdGhlIGtlcm5lbC4gU3lsdmFpbidzCj4g
a2VybmVsIHVJbWFnZSBpcyBvbmx5IGFyb3VuZCA2MDBrIHdoaWxlIHRoZSBvbmUgZnJvbSBmcmVl
c2NhbGUgaXMgMS40TSwKPiBhbnlib2R5IGtub3dzIHdoZXJlIHRoZSBkaWZmZXJlbmNlIGlzPwo+
Cj4gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLgo+Cj4gQXV0b3N0YXJ0aW5n
LiBQcmVzcyBhbnkga2V5IHRvIGFib3J0Li4KPgo+IEhpdCBhbnkga2V5IHRvIHN0b3AgYXV0b2Jv
b3Q6ICAwCj4gVXNpbmcgRkVDIEVUSEVSTkVUIGRldmljZQo+IFRGVFAgZnJvbSBzZXJ2ZXIgMTAu
MTkwLjMuMTAzOyBvdXIgSVAgYWRkcmVzcyBpcyAxMC4xOTAuMy4xNDQKPiBGaWxlbmFtZSAnTVBD
NTIwMC91SW1hZ2UnLgo+IExvYWQgYWRkcmVzczogMHgyMDAwMDAKPgo+IExvYWRpbmc6Cj4gIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMKPgo+ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjCj4KPiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwo+Cj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKPiAgICAgICAgICAj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwo+IGRvbmUKPiBCeXRlcyB0cmFuc2Zl
cnJlZCA9IDE1MTAxNDMgKDE3MGFmZiBoZXgpCj4gIyMgQm9vdGluZyBpbWFnZSBhdCAwMDIwMDAw
MCAuLi4KPgo+ICAgIEltYWdlIE5hbWU6ICAgTGludXgtMi42LjExLjcKPiAgICBJbWFnZSBUeXBl
OiAgIFBvd2VyUEMgTGludXggS2VybmVsIEltYWdlIChnemlwIGNvbXByZXNzZWQpCj4gICAgRGF0
YSBTaXplOiAgICAxNTEwMDc5IEJ5dGVzID0gIDEuNCBNQgo+ICAgIExvYWQgQWRkcmVzczogMDAw
MDAwMDAKPiAgICBFbnRyeSBQb2ludDogIDAwMDAwMDAwCj4gICAgVmVyaWZ5aW5nIENoZWNrc3Vt
IC4uLiBPSwo+ICAgIFVuY29tcHJlc3NpbmcgS2VybmVsIEltYWdlIC4uLiBPSwo+IGlkIG1hY2go
KTogZG9uZQo+IE1NVTplbnRlcgo+IE1NVTpodyBpbml0Cj4gTU1VOm1hcGluCj4gTU1VOnNldGlv
Cj4gTU1VOmV4aXQKPiBzZXR1cF9hcmNoOiBlbnRlcgo+IHNldHVwX2FyY2g6IGJvb3RtZW0KPiBv
Y3A6IGV4aXQKPiBhcmNoOiBleGl0Cj4KPgo+Cj4KPgo+IC4uLi4uLi4uLi4uLi4uLi4uLi4uLgo+
Cj4gUmVnYXJkcywKPgo+IEppYW5nZ2FuIExJCj4KPiAgX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KPgo+IEZyb206IEpvaG4gUmlnYnkgW21haWx0bzpqY3JpZ2J5QGdtYWlsLmNvbV0K
PiBTZW50OiBTYXQgMi8yNS8yMDA2IDE6MTcKPiBUbzogI0xJIEpJQU5HR0FOIwo+IENjOiB0bnRA
MjQ2dG50LmNvbTsgbGludXhwcGMtZW1iZWRkZWRAb3psYWJzLm9yZwo+Cj4gU3ViamVjdDogUmU6
IGJvb3QgZmFpbHVyZSBvbiBsaXRlNTIwMGIgYm9hcmQKPgo+Cj4KPgo+IEkgZG9uJ3QgdGhpbmsg
eW91ciBzeW50YXggZm9yIGFwcGVuZGluZyB0byBhbiBlbnYgdmFyaWFibGUgaXMgY29ycmVjdDoK
Pgo+IHRyeToKPiBzZXQgYm9vdGFyZ3MgJChib290YXJncykgLi4uYXBwZW5kZWQgc3R1ZmYuLi4K
PiBpbnN0ZWFkIG9mOgo+IHNldCBib290YXJncyBlbnYgYm9vdGFyZ3MgLi4uYXBwZW5kZWQgc3R1
ZmYuLi4uCj4KPiBBbHNvIHRvIHNlZSB3aGF0IGJvb3RhcmdzIGlzIGFjdHVhbGx5IHNldCB0byBh
ZnRlciBhbGwgdGhlIG5lc3RlZAo+IGNvbW1hbmRzLCBhZGQgYSBwcmludGVudiBqdXN0IGJlZm9y
ZSB0aGUgYm9vdG0KPgo+IE9uIDIvMjMvMDYsICNMSSBKSUFOR0dBTiMgPGxpamlhbmdnYW5AcG1h
aWwubnR1LmVkdS5zZz4gd3JvdGU6Cj4gPgo+ID4KPiA+IEkgaGF2ZSBhY3R1YWxseSB0cmllZCBi
b3RoIGtlcm5lbCB3aXRoIGJvdGggY29uc29sZSBjb25maWd1cmF0aW9ucy4gSXQKPiBnYXZlCj4g
PiB0aGUgc2FtZSBvdXRwdXQsIHRodXMgSSBwcmVzdW1lIHRoYXQgdGhlIHByb2JsZW0gbGllcyBz
b21ld2hlcmUgZWxzZS4gSQo+ID4gYXR0YWNoZWQgdGhlIGxvZyB0byB0aGlzIGVtYWlsLgo+ID4K
PiA+ICB0aGUgYm9hcmQgaXMgTGl0ZTUyMDBCIFZlcnNpb24gMS4wLiBXaGljaCAuY29uZmlnIGZp
bGUgZG8geW91IHdhbnQ/Cj4gPgo+ID4gIFN5bHZhaW4sIHdlIGhhdmUgb3JkZXJlZCBhIGRlYnVn
Z2luZyBzZXQgYnV0IHdlIGFyZSBzdGlsbCB3YWl0aW5nIGZvcgo+ID4gZGVsaXZlcnksIHRoZSBs
ZWFraW5nIHRpbWUgaXMgc2FpZCB0byBiZSBvbmUgbW9udGgsIHRhbnQgcGlzLiBBbmQgdGhlIGxv
Zwo+IEkKPiA+IGF0dGFjaGVkIGhlcmUgYXJlIGJvb3RpbmcgZnJvbSBhIGhpZ2hlciBhZGRyZXNz
ICgweDUwMDAwMCkuCj4gPgo+ID4gIE15IGN1cnJlbnQgdS1ib290IGFyZ3M6Cj4gPiAgQXV0b3N0
YXJ0aW5nLiBQcmVzcyBhbnkga2V5IHRvIGFib3J0Li4KPiA+Cj4gPiAgSGl0IGFueSBrZXkgdG8g
c3RvcCBhdXRvYm9vdDogIDAKPiA+ICA9PiBwcmludGVudgo+ID4gIGJhdWRyYXRlPTExNTIwMAo+
ID4gIGF1dG9sb2FkPW5vCj4gPiAgZXRoYWN0PUZFQyBFVEhFUk5FVAo+ID4gIGZsc2hyb290PXJv
b3Q9L2Rldi9tdGRibG9jazIgcncKPiA+ICBldGhhZGRyPTAwOjAxOjlGOjAwOjI3OjJGCj4gPiAg
cHJlYm9vdD1lY2hvOyBlY2hvIEF1dG9zdGFydGluZy4gUHJlc3MgYW55IGtleSB0byBhYm9ydC4u
OyBlY2hvCj4gPiAgYm9vdGRlbGF5PTUKPiA+ICBob3N0bmFtZT1pY2VjdWJlCj4gPiAgYm9vdGZp
bGU9TVBDNTIwMC91SW1hZ2UKPiA+ICBudj1uZnNyb290IHJvb3Q9L2Rldi9uZnMgcncgbmZzcm9v
dD0xMC4xOTAuMy4xMTM6L29wdC9lbGRrL3Jvb3Rmcwo+ID4gIGlwPWlwPTEwLjE5MC4zLjE0NDox
MC4xOTAuMy4xMDM6MTAuMTkwLjMuMTAzOjI1NS4yNTUuMjQwLjA6aWNlY3ViZTo6b2ZmCj4gPiAg
bmZzcm9vdD1yb290PS9kZXYvbmZzIHJ3Cj4gbmZzcm9vdD0xMC4xOTAuMy4xMDM6L29wdC9lbGRr
LTQtMC9yb290ZnMKPiA+ICBib290Y21kPXJ1biBuZXRfbmZzCj4gPiAgZmlsZXNpemU9NTQ2Cj4g
PiAgZmlsZWFkZHI9NTAwMDAwCj4gPiAgbmV0bWFzaz0yNTUuMjU1LjI0MC4wCj4gPiAgaXBhZGRy
PTEwLjE5MC4zLjE0NAo+ID4gIHNlcnZlcmlwPTEwLjE5MC4zLjEwMwo+ID4gIHNldGNvbnNvbGU9
c2V0ZW52IGJvb3RhcmdzIGNvbnNvbGU9dHR5UFNDMCwgMTE1MjAwbjggY29uc29sZT10dHkxCj4g
PiAgcm9vdGZzPXJvb3Q9L2Rldi9uZnMgcncKPiBuZnNyb290PTEwLjE5MC4zLjEwMzovb3B0L2Vs
ZGstNC0wL3Jvb3Rmcwo+ID4gIGJvb3RhcmdzPWVudiBib290YXJncyByb290PS9kZXYvbmZzIHJ3
Cj4gPiBuZnNyb290PTEwLjE5MC4zLjEwMzovb3B0L2VsZGstNC0wL3Jvb3Rmcwo+ID4gaXA9MTAu
MTkwLjMuMTQ0OjEwLjE5MC4zLjEwMzoxMC4xOTAuMy4xMDM6MjU1LjI1NS4yNDAuMDppY2VjdWJl
OjpvZmYKPiA+ICBmbGFzaF9uZnM9cnVuIHNldGNvbnNvbGUgbmZzYXJncyBhZGRpcDtib290bQo+
ID4gIG5ldF9uZnM9dGZ0cCA1MDAwMDAgTVBDNTIwMC91SW1hZ2U7cnVuIHNldGNvbnNvbGUgbmZz
YXJncyBhZGRpcDtib290bQo+ID4gIG5mc2FyZ3M9c2V0ZW52IGJvb3RhcmdzIGVudiBib290YXJn
cyByb290PS9kZXYvbmZzIHJ3Cj4gPiBuZnNyb290PTEwLjE5MC4zLjEwMzovb3B0L2VsZGstNC0w
L3Jvb3Rmcwo+ID4KPiBpcD0xMC4xOTAuMy4xNDQ6MTAuMTkwLjMuMTAzOjEwLjE5MC4zLjEwMzoy
NTUuMjU1LjI0MC4wOmljZWN1YmU6Om9mZnJvb3Q9L2Rldi9uZnMKPiA+IHJ3Cj4gPiAgYWRkaXA9
c2V0ZW52IGJvb3RhcmdzIGVudiBib290YXJncyByb290PS9kZXYvbmZzIHJ3Cj4gPiBuZnNyb290
PTEwLjE5MC4zLjEwMzovb3B0L2VsZGstNC0wL3Jvb3Rmcwo+ID4gaXA9MTAuMTkwLjMuMTQ0OjEw
LjE5MC4zLjEwMzoxMC4xOTAuMy4xMDM6MjU1LjI1NS4yNDAuMDppY2VjdWJlOjpvZmYKPiA+ICBy
YW1hcmdzPXNldGVudiBib290YXJncyByb290PS9kZXYvcmFtIHJ3Cj4gPiAgY29uc29sZT1jb25z
b2xlPXR0eVMwLDExNTIwMG44IGNvbnNvbGU9dHR5MQo+ID4gIHN0ZGluPXNlcmlhbAo+ID4gIHN0
ZG91dD1zZXJpYWwKPiA+ICBzdGRlcnI9c2VyaWFsCj4gPgo+ID4gIEVudmlyb25tZW50IHNpemU6
IDE0NzIvNjU1MzIgYnl0ZXMKPiA+ICA9Pgo+ID4KPiA+Cj4gPgo+ID4KPiA+ICBVU0lORyBTeWx2
YWluJ3MgS0VSTkVMOgo+ID4KPiA+ICBVLUJvb3QgMS4xLjMgKEZlYiAgNiAyMDA2IC0gMDk6NTY6
NDYpCj4gPgo+ID4gIENQVTogICBNUEM1MjAwIHYyLjIgYXQgNDYyIE1Iego+ID4gICAgICAgICBC
dXMgMTMyIE1IeiwgSVBCIDEzMiBNSHosIFBDSSAzMyBNSHoKPiA+ICBCb2FyZDogRnJlZXNjYWxl
IE1QQzUyMDAgKExpdGU1MjAwQikKPiA+ICBJMkM6ICAgODUga0h6LCByZWFkeQo+ID4gIERSQU06
ICAyNTYgTUIKPiA+ICBGTEFTSDogMzIgTUIKPiA+ICBQQ0k6ICAgQnVzIERldiBWZW5JZCBEZXZJ
ZCBDbGFzcyBJbnQKPiA+ICAgICAgICAgIDAwICAxYSAgMTA1NyAgNTgwOSAgMDY4MCAgMDAKPiA+
ICBJbjogICAgc2VyaWFsCj4gPiAgT3V0OiAgIHNlcmlhbAo+ID4gIEVycjogICBzZXJpYWwKPiA+
ICBOZXQ6ICAgRkVDIEVUSEVSTkVUCj4gPiAgSURFOiAgIEJ1cyAwOiBPSwo+ID4gICAgRGV2aWNl
IDA6IG5vdCBhdmFpbGFibGUKPiA+ICAgIERldmljZSAxOiBub3QgYXZhaWxhYmxlCj4gPgo+ID4g
IEF1dG9zdGFydGluZy4gUHJlc3MgYW55IGtleSB0byBhYm9ydC4uCj4gPgo+ID4gIEhpdCBhbnkg
a2V5IHRvIHN0b3AgYXV0b2Jvb3Q6ICAwCj4gPiAgVXNpbmcgRkVDIEVUSEVSTkVUIGRldmljZQo+
ID4gIFRGVFAgZnJvbSBzZXJ2ZXIgMTAuMTkwLjMuMTAzOyBvdXIgSVAgYWRkcmVzcyBpcyAxMC4x
OTAuMy4xNDQKPiA+ICBGaWxlbmFtZSAnTVBDNTIwMC91SW1hZ2UnLgo+ID4gIExvYWQgYWRkcmVz
czogMHg1MDAwMDAKPiA+ICBMb2FkaW5nOgo+ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCj4gPgo+ICMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKPiA+ICBk
b25lCj4gPiAgQnl0ZXMgdHJhbnNmZXJyZWQgPSA2NTgxMTQgKGEwYWMyIGhleCkKPiA+ICAjIyBC
b290aW5nIGltYWdlIGF0IDAwNTAwMDAwIC4uLgo+ID4gICAgIEltYWdlIE5hbWU6ICAgTGludXgt
Mi42LjE2LXJjMQo+ID4gICAgIEltYWdlIFR5cGU6ICAgUG93ZXJQQyBMaW51eCBLZXJuZWwgSW1h
Z2UgKGd6aXAgY29tcHJlc3NlZCkKPiA+ICAgICBEYXRhIFNpemU6ICAgIDY1ODA1MCBCeXRlcyA9
IDY0Mi42IGtCCj4gPiAgICAgTG9hZCBBZGRyZXNzOiAwMDAwMDAwMAo+ID4gICAgIEVudHJ5IFBv
aW50OiAgMDAwMDAwMDAKPiA+ICAgICBWZXJpZnlpbmcgQ2hlY2tzdW0gLi4uIE9LCj4gPiAgICAg
VW5jb21wcmVzc2luZyBLZXJuZWwgSW1hZ2UgLi4uIE9LCj4gPiAgaWQgbWFjaCgpOiBkb25lCj4g
PiAgTU1VOmVudGVyCj4gPiAgTU1VOmh3IGluaXQKPiA+ICBNTVU6bWFwaW4KPiA+ICBNTVU6c2V0
aW8KPiA+ICBNTVU6ZXhpdAo+ID4gIHNldHVwX2FyY2g6IGVudGVyCj4gPiAgc2V0dXBfYXJjaDog
Ym9vdG1lbQo+ID4gIGFyY2g6IGV4aXQKPiA+Cj4gPgo+ID4KPiA+ICBVU0lORyBLRVJORUwgRlJP
TSBGcmVlc2NhbGU6Cj4gPgo+ID4gIFUtQm9vdCAxLjEuMyAoRmViICA2IDIwMDYgLSAwOTo1Njo0
NikKPiA+Cj4gPiAgQ1BVOiAgIE1QQzUyMDAgdjIuMiBhdCA0NjIgTUh6Cj4gPiAgICAgICAgIEJ1
cyAxMzIgTUh6LCBJUEIgMTMyIE1IeiwgUENJIDMzIE1Iego+ID4gIEJvYXJkOiBGcmVlc2NhbGUg
TVBDNTIwMCAoTGl0ZTUyMDBCKQo+ID4gIEkyQzogICA4NSBrSHosIHJlYWR5Cj4gPiAgRFJBTTog
IDI1NiBNQgo+ID4gIEZMQVNIOiAzMiBNQgo+ID4gIFBDSTogICBCdXMgRGV2IFZlbklkIERldklk
IENsYXNzIEludAo+ID4gICAgICAgICAgMDAgIDFhICAxMDU3ICA1ODA5ICAwNjgwICAwMAo+ID4g
IEluOiAgICBzZXJpYWwKPiA+ICBPdXQ6ICAgc2VyaWFsCj4gPiAgRXJyOiAgIHNlcmlhbAo+ID4g
IE5ldDogICBGRUMgRVRIRVJORVQKPiA+ICBJREU6ICAgQnVzIDA6IE9LCj4gPiAgICBEZXZpY2Ug
MDogbm90IGF2YWlsYWJsZQo+ID4gICAgRGV2aWNlIDE6IG5vdCBhdmFpbGFibGUKPiA+Cj4gPiAg
QXV0b3N0YXJ0aW5nLiBQcmVzcyBhbnkga2V5IHRvIGFib3J0Li4KPiA+Cj4gPiAgSGl0IGFueSBr
ZXkgdG8gc3RvcCBhdXRvYm9vdDogIDAKPiA+ICBVc2luZyBGRUMgRVRIRVJORVQgZGV2aWNlCj4g
PiAgVEZUUCBmcm9tIHNlcnZlciAxMC4xOTAuMy4xMDM7IG91ciBJUCBhZGRyZXNzIGlzIDEwLjE5
MC4zLjE0NAo+ID4gIEZpbGVuYW1lICdNUEM1MjAwL3VJbWFnZScuCj4gPiAgTG9hZCBhZGRyZXNz
OiAweDUwMDAwMAo+ID4gIExvYWRpbmc6Cj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKPiA+Cj4gIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKPiA+Cj4g
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMKPiA+Cj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKPiA+ICAgICAgICAgICAjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIwo+ID4gIGRvbmUKPiA+ICBCeXRlcyB0cmFuc2ZlcnJlZCA9IDE1MTAx
NDMgKDE3MGFmZiBoZXgpCj4gPiAgIyMgQm9vdGluZyBpbWFnZSBhdCAwMDUwMDAwMCAuLi4KPiA+
ICAgICBJbWFnZSBOYW1lOiAgIExpbnV4LTIuNi4xMS43Cj4gPiAgICAgSW1hZ2UgVHlwZTogICBQ
b3dlclBDIExpbnV4IEtlcm5lbCBJbWFnZSAoZ3ppcCBjb21wcmVzc2VkKQo+ID4gICAgIERhdGEg
U2l6ZTogICAgMTUxMDA3OSBCeXRlcyA9ICAxLjQgTUIKPiA+ICAgICBMb2FkIEFkZHJlc3M6IDAw
MDAwMDAwCj4gPiAgICAgRW50cnkgUG9pbnQ6ICAwMDAwMDAwMAo+ID4gICAgIFZlcmlmeWluZyBD
aGVja3N1bSAuLi4gT0sKPiA+ICAgICBVbmNvbXByZXNzaW5nIEtlcm5lbCBJbWFnZSAuLi4gT0sK
PiA+ICBpZCBtYWNoKCk6IGRvbmUKPiA+ICBNTVU6ZW50ZXIKPiA+ICBNTVU6aHcgaW5pdAo+ID4g
IE1NVTptYXBpbgo+ID4gIE1NVTpzZXRpbwo+ID4gIE1NVTpleGl0Cj4gPiAgc2V0dXBfYXJjaDog
ZW50ZXIKPiA+ICBzZXR1cF9hcmNoOiBib290bWVtCj4gPiAgb2NwOiBleGl0Cj4gPiAgYXJjaDog
ZXhpdAo+ID4KPiA+Cj4gPgo+ID4KPiA+ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4g
IEZyb206IEpvaG4gUmlnYnkgW21haWx0bzpqY3JpZ2J5QGdtYWlsLmNvbV0KPiA+ICBTZW50OiBG
cmkgMi8yNC8yMDA2IDA6MTgKPiA+ICBUbzogI0xJIEpJQU5HR0FOIwo+ID4gIFN1YmplY3Q6IFJl
OiBib290IGZhaWx1cmUgb24gbGl0ZTUyMDBiIGJvYXJkCj4gPgo+ID4gIElmIHlvdSBhcmUgdXNp
bmcgU3lsdmFpbidzIGtlcm5lbCB5b3UgbmVlZCB0byBzZXQgY29uc29sZT10dHlQU0MwLiAgSWYK
PiB5b3UKPiA+IGFyZQo+ID4gIHVzaW5nIGEga2VybmVsIGZyb20gRnJlZXNjYWxlIHRoZW4geW91
IG5lZWQgdG8gc2V0IGNvbnNvbGU9dHR5UzAuCj4gPgo+ID4gIEFsc28gd2hhdCByZXYgb2YgdGhl
IGJvYXJkIGRvIHlvdSBoYXZlPwo+ID4KPiA+Cj4gPgo+ID4gIE9uIDIvMjMvMDYsICNMSSBKSUFO
R0dBTiMgPGxpamlhbmdnYW5AcG1haWwubnR1LmVkdS5zZz4gd3JvdGU6Cj4gPiAgPgo+ID4gID4K
PiA+ICA+IFRoYW5rIHlvdSBKb3Pvv70gTWFy77+9YSBhbmQgQW5kcmV5IGZvciB5b3VyIGFkdmlj
ZXMsIGhvd2V2ZXIgdGhlIHByb2JsZW0KPgo+ID4gID4gcmVtYWlucy4gSSd2ZSB0cmllZCBzZXR0
aW5nIHRoZSBjb25zb2xlICh0aG91Z2ggSSByZW1lbWJlciB0aGF0IG91cgo+ID4gcHJldmlvdXMK
PiA+ICA+IGxpdGU1MjAwIGJvYXJkIHdhcyB3b3JraW5nIGZpbmUgb24ga2VybmVsIDIuNCB3aXRo
b3V0IHNldHRpbmcgdGhlCj4gPiBjb25zb2xlKTsKPiA+ICA+IG1lYW50aW1lLCBJJ3ZlIHNldCB0
aGUgYm9vdGluZyBpbWFnZSB0byAweDUwMDAwMDsgSSBoYXZlIGFsc28gdHJpZWQKPiB1c2luZwo+
ID4gID4gdGhlIGtlcm5lbCBpbWFnZSBjb21lIHRvZ2V0aGVyIHdpdGggdGhlIEJTUCwgaXQncyBh
bHdheXMgdGhlIHNhbWUKPiBlcnJvci4KPiA+ICA+Cj4gPiAgPiAgU3lsdmFpbiwgSSd2ZSBhY3R1
YWxseSB1c2luZyB5b3VyIGtlcm5lbCBzb3VyY2UsIHRoZSBjb21waWxlZCBpbWFnZSBpcwo+ID4g
ID4gYXJvdW5kIDcwMGsgKGNvbXBhcmVkIHRvIHRoZSAxLjRNIGltYWdlIGZyb20gdGhlIEJTUCks
IGJ1dCBpdCBkb2Vzbid0Cj4gPiBzb2x2ZQo+ID4gID4gdGhlIHByb2JsZW0uIFNvIEkgcHJlc3Vt
ZSB0aGF0IHRoZSBwcm9ibGVtIGlzIGx5aW5nIHNvbWV3aGVyZSBlbHNlLgo+ID4gID4KPiA+ICA+
ICBBIFNOQVBTSE9UIE9GIFRIRSBCT09USU5HIE1FU1NBR0VTOgo+ID4gID4KPiA+ICA+Cj4gPiAg
PiAgVS1Cb290IDEuMS4zIChGZWIgIDYgMjAwNiAtIDA5OjU2OjQ2KQo+ID4gID4KPiA+ICA+ICBD
UFU6ICAgTVBDNTIwMCB2Mi4yIGF0IDQ2MiBNSHoKPiA+ICA+ICAgICAgICAgQnVzIDEzMiBNSHos
IElQQiAxMzIgTUh6LCBQQ0kgMzMgTUh6Cj4gPiAgPiAgQm9hcmQ6IEZyZWVzY2FsZSBNUEM1MjAw
IChMaXRlNTIwMEIpCj4gPiAgPiAgSTJDOiAgIDg1IGtIeiwgcmVhZHkKPiA+ICA+ICBEUkFNOiAg
MjU2IE1CCj4gPiAgPiAgRkxBU0g6IDMyIE1CCj4gPiAgPiAgUENJOiAgIEJ1cyBEZXYgVmVuSWQg
RGV2SWQgQ2xhc3MgSW50Cj4gPiAgPiAgICAgICAgICAwMCAgMWEgIDEwNTcgIDU4MDkgIDA2ODAg
IDAwCj4gPiAgPiAgSW46ICAgIHNlcmlhbAo+ID4gID4gIE91dDogICBzZXJpYWwKPiA+ICA+ICBF
cnI6ICAgc2VyaWFsCj4gPiAgPiAgTmV0OiAgIEZFQyBFVEhFUk5FVAo+ID4gID4gIElERTogICBC
dXMgMDogT0sKPiA+ICA+ICAgIERldmljZSAwOiBub3QgYXZhaWxhYmxlCj4gPiAgPiAgICBEZXZp
Y2UgMTogbm90IGF2YWlsYWJsZQo+ID4gID4KPiA+ICA+ICBBdXRvc3RhcnRpbmcuIFByZXNzIGFu
eSBrZXkgdG8gYWJvcnQuLgo+ID4gID4KPiA+ICA+ICBIaXQgYW55IGtleSB0byBzdG9wIGF1dG9i
b290OiAgMAo+ID4gID4gIFVzaW5nIEZFQyBFVEhFUk5FVCBkZXZpY2UKPiA+ICA+ICBURlRQIGZy
b20gc2VydmVyIDEwLjE5MC4zLjEwMzsgb3VyIElQIGFkZHJlc3MgaXMgMTAuMTkwLjMuMTQ0Cj4g
PiAgPiAgRmlsZW5hbWUgJ01QQzUyMDAvdUltYWdlJy4KPiA+ICA+ICBMb2FkIGFkZHJlc3M6IDB4
MTAwMDAwCj4gPiAgPiAgTG9hZGluZzoKPiA+ICA+Cj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKPiA+ICA+Cj4gPiAgPgo+
ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMKPiA+ICA+ICBkb25lCj4gPiAgPiAgQnl0ZXMgdHJhbnNmZXJyZWQgPSA2NTgxMTQg
KGEwYWMyIGhleCkKPiA+ICA+ICAjIyBCb290aW5nIGltYWdlIGF0IDAwMTAwMDAwIC4uLgo+ID4g
ID4gICAgIEltYWdlIE5hbWU6ICAgTGludXgtMi42LjE2LXJjMQo+ID4gID4gICAgIEltYWdlIFR5
cGU6ICAgUG93ZXJQQyBMaW51eCBLZXJuZWwgSW1hZ2UgKGd6aXAgY29tcHJlc3NlZCkKPiA+ICA+
ICAgICBEYXRhIFNpemU6ICAgIDY1ODA1MCBCeXRlcyA9IDY0Mi42IGtCCj4gPiAgPiAgICAgTG9h
ZCBBZGRyZXNzOiAwMDAwMDAwMAo+ID4gID4gICAgIEVudHJ5IFBvaW50OiAgMDAwMDAwMDAKPiA+
ICA+ICAgICBWZXJpZnlpbmcgQ2hlY2tzdW0gLi4uIE9LCj4gPiAgPiAgICAgVW5jb21wcmVzc2lu
ZyBLZXJuZWwgSW1hZ2UgLi4uIE9LCj4gPiAgPiAgaWQgbWFjaCgpOiBkb25lCj4gPiAgPiAgTU1V
OmVudGVyCj4gPiAgPiAgTU1VOmh3IGluaXQKPiA+ICA+ICBNTVU6bWFwaW4KPiA+ICA+ICBNTVU6
c2V0aW8KPiA+ICA+ICBNTVU6ZXhpdAo+ID4gID4gIHNldHVwX2FyY2g6IGVudGVyCj4gPiAgPiAg
c2V0dXBfYXJjaDogYm9vdG1lbQo+ID4gID4gIGFyY2g6IGV4aXQKPiA+ICA+Cj4gPiAgPgo+ID4g
ID4gIEkgYW0gd29uZGVyaW5nIHdoZXRoZXIgaXQncyBhIGtlcm5lbCBwcm9ibGVtIG9yIG1vcmUg
bGlrZWx5IHRvIGJlIGEKPiA+IHByb2JsZW0KPiA+ICA+IGx5aW5nIHdpdGggdGhlIFUtYm9vdC4g
SXQgc2VlbXMgdG8gaGFuZyB3aGVuIGV4ZWN1dGluZyBzZXR1cF9hcmNoKCkKPiA+ICA+IGZ1bmN0
aW9uLCBvciBtYXliZSB0aGVyZSBpcyBzdGggZWxzZSBiZWhpbmQgdGhlIHdhbGw/Cj4gPiAgPgo+
ID4gID4gIFJlZ2FyZHMsCj4gPiAgPiAgSmlhbmdnYW4gTEkKPiA+ICA+Cj4gPiAgPgo+ID4gID4K
PiA+ICA+Cj4gPiAgPiAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiA+ICA+ICBGcm9tOiBT
eWx2YWluIE11bmF1dCBbbWFpbHRvOnRudEAyNDZ0TnQuY29tXQo+ID4gID4gIFNlbnQ6IFRodSAy
LzIzLzIwMDYgMTU6MzgKPiA+ICA+ICBUbzogI0xJIEpJQU5HR0FOIwo+ID4gID4gIENjOiBsaW51
eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnCj4gPiAgPiAgU3ViamVjdDogUmU6IGJvb3QgZmFpbHVy
ZSBvbiBsaXRlNTIwMGIgYm9hcmQKPiA+ICA+Cj4gPiAgPiAgI0xJIEpJQU5HR0FOIyB3cm90ZToK
PiA+ICA+ICA+IEhlbGxvIGFsbCwKPiA+ICA+ICA+Cj4gPiAgPiAgPiBGb3IgbXkgZW5kLW9mLXN0
dWR5IHByb2plY3QsIEkgYW0gd29ya2luZyBvbiBhbiBlbWJlZGRlZCBzeXN0ZW0gd2l0aAo+ID4g
ID4gID4gcmVmZXJlbmNlIG9mIGZyZWVzY2FsZSdzIGxpdGU1MjAwYiByZWZlcmVuY2UgYm9hcmQu
IEkgd2FzIHRyeWluZyB0bwo+ID4gYm9vdAo+ID4gID4gID4gTGludXggMi42LjE1IG9uIHRoZSBi
b2FyZCAod2l0aCB0aGUgZmVjIGFuZCBiZXN0Y29tbSBjb3JyZWN0ZWQpLgo+ID4gaG93ZXZlcgo+
ID4gID4gID4gdGhlIGJvb3Rpbmcgd2FzIHN0dWNrIGF0IHRoZSBmb2xsb3dpbmcgc3RhZ2U6Cj4g
PiAgPgo+ID4gID4gIEluIGFkZGl0aW9uIHRvIHdoYXQgaGFzIGFscmVhZHkgYmVlbiBzYWlkICh1
c2UgYSBoaWdoZXIgYWRkcmVzcyBmb3IKPiB0aGUKPiA+ICA+ICBpbWFnZSBhbmQgZG9uJ3QgZm9y
Z2V0IGNvbnNvbGU9dHR5UFNDMCBpbiBrZXJuZWwgY29tbWFuZCBsaW5lKSwgbWFrZQo+ID4gID4g
IHN1cmUgeW91IHVzZSB0aGUga2VybmVsIGZyb20gbXkgZ2l0IHRyZWUsIGl0IGNvbnRhaW5zIGEg
ZmV3IHBhdGNoZXMKPiBmcm9tCj4gPiAgPiAgSm9obiBSaWdieSB0byBhZGQgc3VwcG9ydCBmb3Ig
dGhlIGxpdGU1MjAwYi4KPiA+ICA+Cj4gPiAgPiAgUGxlYXNlIHJlcG9ydCBpZiBpdCB3b3Jrcywg
SSd2ZSBub3QgYmVlbiBhYmxlIHRvIHRlc3QgdGhvc2UgbXlzZWxmCj4gc2luY2UKPiA+ICA+ICBp
J20gc3RpbGwgb24gbGl0ZTUyMDAuCj4gPiAgPgo+ID4gID4KPiA+ICA+ICAgICAgICAgIFN5bHZh
aW4KPiA+ICA+Cj4gPiAgPgo+ID4gID4KPiA+ICA+Cj4gPiAgPgo+ID4gID4KPiA+ICA+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiAgPiBMaW51eHBw
Yy1lbWJlZGRlZCBtYWlsaW5nIGxpc3QKPiA+ICA+IExpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5v
cmcKPiA+ICA+IGh0dHBzOi8vb3psYWJzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4cHBjLWVt
YmVkZGVkCj4gPiAgPgo+ID4gID4KPiA+Cj4gPgo+ID4KPiA+Cj4gPgo+Cj4KPgo=
^ permalink raw reply
* Re: [PPC,SOUND] Fix audio gpio state detection
From: Benjamin Herrenschmidt @ 2006-03-02 0:04 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, alsa-devel, Ben Collins
In-Reply-To: <20060302000019.GB6792@suse.de>
On Thu, 2006-03-02 at 01:00 +0100, Olaf Hering wrote:
> On Wed, Mar 01, Ben Collins wrote:
>
> > I'm rediffing now. However, I may not include my tumbler changes
> > immediately. For some reason, those are the ones causing problems. I
> > need to review the diff and see if I can find the problem (which I
> > cannot reproduce).
>
> Can you make individual patches, each one fixing one thing, going from A
> to B. You know that hch song...
In that case, it's difficult as it's more like a rewrite of the GPIO
handling from scratch (well... almost)
Ben.
^ permalink raw reply
* Re: [PPC,SOUND] Fix audio gpio state detection
From: Benjamin Herrenschmidt @ 2006-03-02 0:04 UTC (permalink / raw)
To: Ben Collins; +Cc: linuxppc-dev, alsa-devel, Ben Collins, Olaf Hering
In-Reply-To: <1141256965.4378.145.camel@grayson>
On Wed, 2006-03-01 at 18:49 -0500, Ben Collins wrote:
> On Thu, 2006-03-02 at 10:09 +1100, Benjamin Herrenschmidt wrote:
> > > > This (sort of) breaks PowerMac3,4 (69 (PowerMac G4 Silver)). I have to
> > > > force it on up to now, but with this patch the internal speaker will not
> > > > work with or without my patch to force it on.
> > >
> > > But the patch fixes also my PowerBook4,1, I dont have to toggle the headphone
> > > once to get the built-in speakers enabled.
> > > Looks like 2.6.16 stuff, but its been broken for so long now...
> >
> > What is the status of Ben's latest stuff ?
>
> I'm rediffing now. However, I may not include my tumbler changes
> immediately. For some reason, those are the ones causing problems. I
> need to review the diff and see if I can find the problem (which I
> cannot reproduce).
>
> The toonie stuff is great. Been working really well for all the folks
> I've heard from, and for me on my PowerBook5,9.
There is an issue with some models where asserting both mutes will reset
the codec, so you have to be careful with that. Then, there is the
old-style GPIOs where you can read the polarity from the device-tree and
the new style ones...
I _think_ apple uses the GPIO platform functions only on machines that
have "include-k2-support" property in macio too, so maybe you are trying
to use them on earlier machines and they are bogus...
Send me the complete patch and I'll see if I spot something. Olaf, can
you give me quick summary of the machines that have problems with Ben's
code ?
Ben.
^ permalink raw reply
* Re: [PPC,SOUND] Fix audio gpio state detection
From: Olaf Hering @ 2006-03-02 0:00 UTC (permalink / raw)
To: Ben Collins; +Cc: linuxppc-dev, alsa-devel, Ben Collins
In-Reply-To: <1141256965.4378.145.camel@grayson>
On Wed, Mar 01, Ben Collins wrote:
> I'm rediffing now. However, I may not include my tumbler changes
> immediately. For some reason, those are the ones causing problems. I
> need to review the diff and see if I can find the problem (which I
> cannot reproduce).
Can you make individual patches, each one fixing one thing, going from A
to B. You know that hch song...
^ permalink raw reply
* [PATCH 0/6] AMCC 440SP/Luan board enhancements & fixes
From: Wade Farnsworth @ 2006-03-01 23:35 UTC (permalink / raw)
To: linuxppc-embedded
Greetings,
The following patches are enhancements and/or fixes for the AMCC 440SP
SoC and the Luan board. Most notably there is support for UART2 and the
L2 Cache, as well as increased flexibility for the PCIX bridges.
--Wade Farnsworth
^ permalink raw reply
* Re: [Fastboot] Re: Kexec for booke PPC processors
From: Kumar Gala @ 2006-03-01 23:46 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, dagriego, fastboot
In-Reply-To: <200603021012.57955.michael@ellerman.id.au>
> On Thu, 2 Mar 2006 09:43, dagriego wrote:
> > I'm finishing my first pass on getting kexec to work on PPC booke
> > processor, and needed some insight into how to pass information from the
> > first kernel to the kexec'ed kernel. This information is the board
> > information that the first kernel is given in r3 from the board firmware.
> > Is there a standard convention for passing this information?
>
> Yep, it's called the flat device tree.
Which PPC booke are you trying to get this to work on?
- kumar
^ permalink raw reply
* Re: [PATCH 6/6] MTD defines for Luan
From: Wade Farnsworth @ 2006-03-01 23:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1141257179.25758.31.camel@rhino.az.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 131 bytes --]
This fixes the defines for MTD support in the Luan platform file.
--Wade
Signed off by: Wade Farnsworth <wfarnsworth@mvista.com>
[-- Attachment #2: luan-mtd-defs.patch --]
[-- Type: text/x-patch, Size: 1412 bytes --]
diff --git a/arch/ppc/platforms/4xx/luan.h b/arch/ppc/platforms/4xx/luan.h
--- a/arch/ppc/platforms/4xx/luan.h
+++ b/arch/ppc/platforms/4xx/luan.h
@@ -32,14 +32,28 @@
#define LUAN_TMR_CLK 25000000
/* Flash */
-#define LUAN_FPGA_REG_0 0x0000000148300000ULL
+#define LUAN_FPGA_REG_0 0x00000001f8000000ULL
+#define LUAN_CONFIG_MASK 0x43
+#define LUAN_CONFIG_1 0x41
+#define LUAN_CONFIG_2 0x40
+#define LUAN_CONFIG_3 0x01
+#define LUAN_CONFIG_4 0x00
#define LUAN_BOOT_LARGE_FLASH(x) (x & 0x40)
-#define LUAN_SMALL_FLASH_LOW 0x00000001ff900000ULL
-#define LUAN_SMALL_FLASH_HIGH 0x00000001ffe00000ULL
+#define LUAN_SMALL_FLASH_LOW 0x00000001f9900000ULL
+#define LUAN_SMALL_FLASH_LOW4 0x00000001f9800000ULL
+#define LUAN_SMALL_FLASH_HIGH 0x00000001fff00000ULL
+#define LUAN_SMALL_FLASH_HIGH2 0x00000001ffe00000ULL
#define LUAN_SMALL_FLASH_SIZE 0x100000
-#define LUAN_LARGE_FLASH_LOW 0x00000001ff800000ULL
+#define LUAN_LARGE_FLASH_LOW 0x00000001f9800000ULL
#define LUAN_LARGE_FLASH_HIGH 0x00000001ffc00000ULL
#define LUAN_LARGE_FLASH_SIZE 0x400000
+#define LUAN_SRAM_HIGH 0x00000001ffe00000ULL
+#define LUAN_SRAM_HIGH2 0x00000001fff00000ULL
+#define LUAN_SRAM_LOW 0x00000001f9800000ULL
+#define LUAN_SRAM_LOW4 0x00000001f9900000ULL
+#define LUAN_SRAM_SIZE 0x100000
+#define LUAN_FRAM_ADDR 0x00000001f8060000ULL
+#define LUAN_FRAM_SIZE 0x8000
/*
* Serial port defines
^ permalink raw reply
* Re: [PATCH 5/6] Clock and power management define fixes for 440SP
From: Wade Farnsworth @ 2006-03-01 23:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1141257084.25758.28.camel@rhino.az.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 129 bytes --]
This fixes the clock and power management defines on the 440SP.
--Wade
Signed off by: Wade Farnsworth <wfarnsworth@mvista.com>
[-- Attachment #2: luan-cpm.patch --]
[-- Type: text/x-patch, Size: 2672 bytes --]
diff --git a/arch/ppc/platforms/4xx/ibm440sp.h b/arch/ppc/platforms/4xx/ibm440sp.h
--- a/arch/ppc/platforms/4xx/ibm440sp.h
+++ b/arch/ppc/platforms/4xx/ibm440sp.h
@@ -32,33 +32,28 @@
/* Clock and Power Management */
#define IBM_CPM_IIC0 0x80000000 /* IIC interface */
#define IBM_CPM_IIC1 0x40000000 /* IIC interface */
-#define IBM_CPM_PCI 0x20000000 /* PCI bridge */
-#define IBM_CPM_CPU 0x02000000 /* processor core */
-#define IBM_CPM_DMA 0x01000000 /* DMA controller */
-#define IBM_CPM_BGO 0x00800000 /* PLB to OPB bus arbiter */
-#define IBM_CPM_BGI 0x00400000 /* OPB to PLB bridge */
-#define IBM_CPM_EBC 0x00200000 /* External Bux Controller */
-#define IBM_CPM_EBM 0x00100000 /* Ext Bus Master Interface */
-#define IBM_CPM_DMC 0x00080000 /* SDRAM peripheral controller */
-#define IBM_CPM_PLB 0x00040000 /* PLB bus arbiter */
+#define IBM_CPM_PCIX0 0x20000000 /* PCIX bridge 0 */
+#define IBM_CPM_PCIX1 0x10000000 /* PCIX bridge 1 */
+#define IBM_CPM_PCIX2 0x08000000 /* PCIX bridge 2 */
+#define IBM_CPM_CPU 0x02000000 /* processor core */
+#define IBM_CPM_BGO 0x00800000 /* PLB to OPB bus arbiter */
+#define IBM_CPM_EBC 0x00200000 /* External Bux Controller */
+#define IBM_CPM_PLB 0x00040000 /* PLB bus arbiter */
#define IBM_CPM_SRAM 0x00020000 /* SRAM memory controller */
-#define IBM_CPM_PPM 0x00002000 /* PLB Performance Monitor */
#define IBM_CPM_UIC1 0x00001000 /* Universal Interrupt Controller */
#define IBM_CPM_GPIO0 0x00000800 /* General Purpose IO (??) */
-#define IBM_CPM_GPT 0x00000400 /* General Purpose Timers */
+#define IBM_CPM_GPT 0x00000400 /* General Purpose Timers */
#define IBM_CPM_UART0 0x00000200 /* serial port 0 */
#define IBM_CPM_UART1 0x00000100 /* serial port 1 */
-#define IBM_CPM_UART2 0x00000100 /* serial port 1 */
#define IBM_CPM_UIC0 0x00000080 /* Universal Interrupt Controller */
#define IBM_CPM_TMRCLK 0x00000040 /* CPU timers */
#define IBM_CPM_EMAC0 0x00000020 /* EMAC 0 */
+#define IBM_CPM_UART2 0x00000010 /* serial port 2 */
-#define DFLT_IBM4xx_PM ~(IBM_CPM_UIC | IBM_CPM_UIC1 | IBM_CPM_CPU \
+#define DFLT_IBM4xx_PM ~(IBM_CPM_UIC0 | IBM_CPM_UIC1 | IBM_CPM_CPU \
| IBM_CPM_EBC | IBM_CPM_SRAM | IBM_CPM_BGO \
- | IBM_CPM_EBM | IBM_CPM_PLB | IBM_CPM_OPB \
- | IBM_CPM_TMRCLK | IBM_CPM_DMA | IBM_CPM_PCI \
- | IBM_CPM_TAHOE0 | IBM_CPM_TAHOE1 \
- | IBM_CPM_EMAC0 | IBM_CPM_EMAC1 \
- | IBM_CPM_EMAC2 | IBM_CPM_EMAC3 )
+ | IBM_CPM_PLB | IBM_CPM_TMRCLK | IBM_CPM_PCIX0 \
+ | IBM_CPM_PCIX1 | IBM_CPM_PCIX2\
+ | IBM_CPM_EMAC0 )
#endif /* __PPC_PLATFORMS_IBM440SP_H */
#endif /* __KERNEL__ */
^ permalink raw reply
* Re: [PATCH 4/6] L2 Cache support for 440SP
From: Wade Farnsworth @ 2006-03-01 23:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1141257021.25761.26.camel@rhino.az.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 107 bytes --]
This adds L2 Cache support for the 440SP.
--Wade
Signed off by: Wade Farnsworth <wfarnsworth@mvista.com>
[-- Attachment #2: luan-l2c.patch --]
[-- Type: text/x-patch, Size: 636 bytes --]
diff --git a/arch/ppc/platforms/4xx/luan.c b/arch/ppc/platforms/4xx/luan.c
--- a/arch/ppc/platforms/4xx/luan.c
+++ b/arch/ppc/platforms/4xx/luan.c
@@ -408,6 +408,11 @@ luan_setup_arch(void)
printk("Luan port (MontaVista Software, Inc. <source@mvista.com>)\n");
}
+static void __init luan_init(void)
+{
+ ibm440gx_l2c_setup(&clocks);
+}
+
void __init platform_init(unsigned long r3, unsigned long r4,
unsigned long r5, unsigned long r6, unsigned long r7)
{
@@ -422,4 +427,5 @@ void __init platform_init(unsigned long
#ifdef CONFIG_KGDB
ppc_md.early_serial_map = luan_early_serial_map;
#endif
+ ppc_md.init = luan_init;
}
^ permalink raw reply
* Re: [PPC,SOUND] Fix audio gpio state detection
From: Ben Collins @ 2006-03-01 23:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, alsa-devel, Ben Collins, Olaf Hering
In-Reply-To: <1141254596.3889.26.camel@localhost.localdomain>
On Thu, 2006-03-02 at 10:09 +1100, Benjamin Herrenschmidt wrote:
> > > This (sort of) breaks PowerMac3,4 (69 (PowerMac G4 Silver)). I have to
> > > force it on up to now, but with this patch the internal speaker will not
> > > work with or without my patch to force it on.
> >
> > But the patch fixes also my PowerBook4,1, I dont have to toggle the headphone
> > once to get the built-in speakers enabled.
> > Looks like 2.6.16 stuff, but its been broken for so long now...
>
> What is the status of Ben's latest stuff ?
I'm rediffing now. However, I may not include my tumbler changes
immediately. For some reason, those are the ones causing problems. I
need to review the diff and see if I can find the problem (which I
cannot reproduce).
The toonie stuff is great. Been working really well for all the folks
I've heard from, and for me on my PowerBook5,9.
--
Ubuntu - http://www.ubuntu.com/
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
SwissDisk - http://www.swissdisk.com/
^ permalink raw reply
* Re: [PATCH 3/6] PCIX fixes and enhancements for 440SP & Luan
From: Wade Farnsworth @ 2006-03-01 23:50 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1141256859.25758.22.camel@rhino.az.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 249 bytes --]
This patch allows each bridge on the 440SP to be configured for both
host and adapter mode. Previously, PCIX0 was configured for adapter
mode only.
Also fixes PCIXn_IO_BASE for PCIX1 and 2.
Signed off by: Wade Farnsworth <wfarnsworth@mvista.com>
[-- Attachment #2: luan-pcix.patch --]
[-- Type: text/x-patch, Size: 4304 bytes --]
diff --git a/arch/ppc/platforms/4xx/luan.c b/arch/ppc/platforms/4xx/luan.c
--- a/arch/ppc/platforms/4xx/luan.c
+++ b/arch/ppc/platforms/4xx/luan.c
@@ -95,9 +95,7 @@ luan_map_irq(struct pci_dev *dev, unsign
{
struct pci_controller *hose = pci_bus_to_hose(dev->bus->number);
- /* PCIX0 in adapter mode, no host interrupt routing */
-
- /* PCIX1 */
+ /* PCIX0 */
if (hose->index == 0) {
static char pci_irq_table[][4] =
/*
@@ -105,6 +103,21 @@ luan_map_irq(struct pci_dev *dev, unsign
* A B C D
*/
{
+ { 32, 32, 32, 32 }, /* IDSEL 1 - PCIX0 Slot 0 */
+ { 32, 32, 32, 32 }, /* IDSEL 2 - PCIX0 Slot 1 */
+ { 32, 32, 32, 32 }, /* IDSEL 3 - PCIX0 Slot 2 */
+ { 32, 32, 32, 32 }, /* IDSEL 4 - PCIX0 Slot 3 */
+ };
+ const long min_idsel = 1, max_idsel = 4, irqs_per_slot = 4;
+ return PCI_IRQ_TABLE_LOOKUP;
+ /* PCIX1 */
+ } else if (hose->index == 1) {
+ static char pci_irq_table[][4] =
+ /*
+ * PCI IDSEL/INTPIN->INTLINE
+ * A B C D
+ */
+ {
{ 49, 49, 49, 49 }, /* IDSEL 1 - PCIX1 Slot 0 */
{ 49, 49, 49, 49 }, /* IDSEL 2 - PCIX1 Slot 1 */
{ 49, 49, 49, 49 }, /* IDSEL 3 - PCIX1 Slot 2 */
@@ -113,7 +126,7 @@ luan_map_irq(struct pci_dev *dev, unsign
const long min_idsel = 1, max_idsel = 4, irqs_per_slot = 4;
return PCI_IRQ_TABLE_LOOKUP;
/* PCIX2 */
- } else if (hose->index == 1) {
+ } else if (hose->index == 2) {
static char pci_irq_table[][4] =
/*
* PCI IDSEL/INTPIN->INTLINE
@@ -237,42 +250,70 @@ luan_setup_hose(struct pci_controller *h
static void __init
luan_setup_hoses(void)
{
- struct pci_controller *hose1, *hose2;
+ struct pci_controller *hose0, *hose1, *hose2;
+ int last_busno = -1;
/* Configure windows on the PCI-X host bridge */
luan_setup_pcix();
+
+ /* Setup PCIX0 */
+ if (SDR_READ(0x01c0) & 0x20000000) {
+ hose0 = pcibios_alloc_controller();
+ if (!hose0)
+ return;
+ hose0->first_busno = 0;
+ hose0->last_busno = 0xff;
+ hose0->index = 0;
+
+ luan_setup_hose(hose0,
+ LUAN_PCIX0_LOWER_MEM,
+ LUAN_PCIX0_UPPER_MEM,
+ PCIX0_CFGA,
+ PCIX0_CFGD,
+ PCIX0_IO_BASE);
- /* Allocate hoses for PCIX1 and PCIX2 */
- hose1 = pcibios_alloc_controller();
- hose2 = pcibios_alloc_controller();
- if (!hose1 || !hose2)
- return;
+ last_busno = hose0->last_busno =
+ pciauto_bus_scan(hose0, hose0->first_busno);
+ }
/* Setup PCIX1 */
- hose1->first_busno = 0;
- hose1->last_busno = 0xff;
-
- luan_setup_hose(hose1,
- LUAN_PCIX1_LOWER_MEM,
- LUAN_PCIX1_UPPER_MEM,
- PCIX1_CFGA,
- PCIX1_CFGD,
- PCIX1_IO_BASE);
+ if (SDR_READ(0x01c3) & 0x20000000) {
+ hose1 = pcibios_alloc_controller();
+ if (!hose1)
+ return;
+ hose1->first_busno = last_busno + 1;
+ hose1->last_busno = 0xff;
+ hose1->index = 1;
+
+ luan_setup_hose(hose1,
+ LUAN_PCIX1_LOWER_MEM,
+ LUAN_PCIX1_UPPER_MEM,
+ PCIX1_CFGA,
+ PCIX1_CFGD,
+ PCIX1_IO_BASE);
- hose1->last_busno = pciauto_bus_scan(hose1, hose1->first_busno);
+ last_busno = hose1->last_busno =
+ pciauto_bus_scan(hose1, hose1->first_busno);
+ }
/* Setup PCIX2 */
- hose2->first_busno = hose1->last_busno + 1;
- hose2->last_busno = 0xff;
+ if (SDR_READ(0x01c6) & 0x20000000) {
+ hose2 = pcibios_alloc_controller();
+ if (!hose2)
+ return;
+ hose2->first_busno = last_busno + 1;
+ hose2->last_busno = 0xff;
+ hose2->index = 2;
+
+ luan_setup_hose(hose2,
+ LUAN_PCIX2_LOWER_MEM,
+ LUAN_PCIX2_UPPER_MEM,
+ PCIX2_CFGA,
+ PCIX2_CFGD,
+ PCIX2_IO_BASE);
- luan_setup_hose(hose2,
- LUAN_PCIX2_LOWER_MEM,
- LUAN_PCIX2_UPPER_MEM,
- PCIX2_CFGA,
- PCIX2_CFGD,
- PCIX2_IO_BASE);
-
- hose2->last_busno = pciauto_bus_scan(hose2, hose2->first_busno);
+ hose2->last_busno = pciauto_bus_scan(hose2, hose2->first_busno);
+ }
ppc_md.pci_swizzle = common_swizzle;
ppc_md.pci_map_irq = luan_map_irq;
diff --git a/include/asm-ppc/ibm44x.h b/include/asm-ppc/ibm44x.h
--- a/include/asm-ppc/ibm44x.h
+++ b/include/asm-ppc/ibm44x.h
@@ -560,8 +560,8 @@
#define PCIX2_CFGD 0x2ec00004UL
#define PCIX0_IO_BASE 0x0000000908000000ULL
-#define PCIX1_IO_BASE 0x0000000908000000ULL
-#define PCIX2_IO_BASE 0x0000000908000000ULL
+#define PCIX1_IO_BASE 0x0000000918000000ULL
+#define PCIX2_IO_BASE 0x0000000928000000ULL
#define PCIX_IO_SIZE 0x00010000
#ifdef CONFIG_440SP
^ permalink raw reply
* Re: [PATCH 2/6] Add UIC settings for 440SP & Luan
From: Wade Farnsworth @ 2006-03-01 23:47 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1141256751.25761.19.camel@rhino.az.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 156 bytes --]
This adds the necessary structures for the UIC polarity and triggering
on the 440SP & Luan.
-Wade
Signed off by: Wade Farnsworth <wfarnsworth@mvista.com>
[-- Attachment #2: luan-uic.patch --]
[-- Type: text/x-patch, Size: 1590 bytes --]
diff --git a/arch/ppc/platforms/4xx/ibm440sp.c b/arch/ppc/platforms/4xx/ibm440sp.c
--- a/arch/ppc/platforms/4xx/ibm440sp.c
+++ b/arch/ppc/platforms/4xx/ibm440sp.c
@@ -19,6 +19,7 @@
#include <linux/module.h>
#include <platforms/4xx/ibm440sp.h>
#include <asm/ocp.h>
+#include <asm/ppc4xx_pic.h>
static struct ocp_func_emac_data ibm440sp_emac0_def = {
.rgmii_idx = -1, /* No RGMII */
@@ -129,3 +130,15 @@ struct ocp_def core_ocp[] = {
{ .vendor = OCP_VENDOR_INVALID
}
};
+
+/* Polarity and triggering settings for internal interrupt sources */
+struct ppc4xx_uic_settings ppc4xx_core_uic_cfg[] __initdata = {
+ { .polarity = 0xffffffff,
+ .triggering = 0x01084004,
+ .ext_irq_mask = 0x00000000,
+ },
+ { .polarity = 0x7fff83ff,
+ .triggering = 0x00000000,
+ .ext_irq_mask = 0x80007c00, /* IRQ7 - IRQ9 */
+ },
+};
diff --git a/arch/ppc/platforms/4xx/luan.c b/arch/ppc/platforms/4xx/luan.c
--- a/arch/ppc/platforms/4xx/luan.c
+++ b/arch/ppc/platforms/4xx/luan.c
@@ -56,6 +56,18 @@ extern bd_t __res;
static struct ibm44x_clocks clocks __initdata;
+/*
+ * Luan external IRQ triggering/polarity settings
+ */
+unsigned char ppc4xx_uic_ext_irq_cfg[] __initdata = {
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ0 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ1 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ2 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* IRQ3 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* IRQ4 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ5 */
+};
+
static void __init
luan_calibrate_decr(void)
{
^ permalink raw reply
* Re: [PATCH 1/6] Support for UART 2 on 440SP and Luan
From: Wade Farnsworth @ 2006-03-01 23:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1141256113.25761.14.camel@rhino.az.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 204 bytes --]
This fixes the IRQ number for UART 2 on the 440SP and adds support to
ibm440gx_get_clocks() for it. It also enables the UART on the Luan.
--Wade
Signed off by: Wade Farnsworth <wfarnsworth@mvista.com>
[-- Attachment #2: luan-uart2.patch --]
[-- Type: text/x-patch, Size: 2731 bytes --]
diff --git a/arch/ppc/platforms/4xx/ibm440sp.h b/arch/ppc/platforms/4xx/ibm440sp.h
--- a/arch/ppc/platforms/4xx/ibm440sp.h
+++ b/arch/ppc/platforms/4xx/ibm440sp.h
@@ -27,7 +27,7 @@
#define PPC440SP_UART2_ADDR 0x00000001f0000600ULL
#define UART0_INT 0
#define UART1_INT 1
-#define UART2_INT 2
+#define UART2_INT 37
/* Clock and Power Management */
#define IBM_CPM_IIC0 0x80000000 /* IIC interface */
diff --git a/arch/ppc/platforms/4xx/luan.c b/arch/ppc/platforms/4xx/luan.c
--- a/arch/ppc/platforms/4xx/luan.c
+++ b/arch/ppc/platforms/4xx/luan.c
@@ -296,9 +296,12 @@ luan_early_serial_map(void)
printk("Early serial init of port 1 failed\n");
}
+ /* Enable UART2 */
+ SDR_WRITE(DCRN_SDR_PFC1, SDR_READ(DCRN_SDR_PFC1) | 0x01000000);
+
port.membase = ioremap64(PPC440SP_UART2_ADDR, 8);
port.irq = UART2_INT;
- port.uartclk = BASE_BAUD;
+ port.uartclk = clocks.uart2;
port.line = 2;
if (early_serial_setup(&port) != 0) {
diff --git a/arch/ppc/syslib/ibm440gx_common.c b/arch/ppc/syslib/ibm440gx_common.c
--- a/arch/ppc/syslib/ibm440gx_common.c
+++ b/arch/ppc/syslib/ibm440gx_common.c
@@ -34,8 +34,10 @@ void __init ibm440gx_get_clocks(struct i
u32 plld = CPR_READ(DCRN_CPR_PLLD);
u32 uart0 = SDR_READ(DCRN_SDR_UART0);
u32 uart1 = SDR_READ(DCRN_SDR_UART1);
-#ifdef CONFIG_440EP
+#if defined(CONFIG_440EP) || defined(CONFIG_440SP)
u32 uart2 = SDR_READ(DCRN_SDR_UART2);
+#endif
+#if defined(CONFIG_440EP)
u32 uart3 = SDR_READ(DCRN_SDR_UART3);
#endif
@@ -100,12 +102,15 @@ bypass:
p->uart1 = ser_clk;
else
p->uart1 = p->plb / __fix_zero(uart1 & 0xff, 256);
-#ifdef CONFIG_440EP
+
+#if defined(CONFIG_440EP) || (CONFIG_440SP)
if (uart2 & 0x00800000)
p->uart2 = ser_clk;
else
p->uart2 = p->plb / __fix_zero(uart2 & 0xff, 256);
+#endif
+#ifdef CONFIG_440EP
if (uart3 & 0x00800000)
p->uart3 = ser_clk;
else
diff --git a/arch/ppc/syslib/ibm44x_common.h b/arch/ppc/syslib/ibm44x_common.h
--- a/arch/ppc/syslib/ibm44x_common.h
+++ b/arch/ppc/syslib/ibm44x_common.h
@@ -29,8 +29,10 @@ struct ibm44x_clocks {
unsigned int ebc; /* PerClk */
unsigned int uart0;
unsigned int uart1;
-#ifdef CONFIG_440EP
+#if defined(CONFIG_440EP) || defined(CONFIG_440SP)
unsigned int uart2;
+#endif
+#if defined(CONFIG_440EP)
unsigned int uart3;
#endif
};
diff --git a/include/asm-ppc/ibm44x.h b/include/asm-ppc/ibm44x.h
--- a/include/asm-ppc/ibm44x.h
+++ b/include/asm-ppc/ibm44x.h
@@ -179,8 +179,10 @@
#define DCRN_SDR_UART0 0x0120
#define DCRN_SDR_UART1 0x0121
-#ifdef CONFIG_440EP
+#if defined(CONFIG_440EP) || defined(CONFIG_440SP)
#define DCRN_SDR_UART2 0x0122
+#endif
+#if defined(CONFIG_440EP)
#define DCRN_SDR_UART3 0x0123
#define DCRN_SDR_CUST0 0x4000
#endif
^ permalink raw reply
* Re: [Fastboot] Re: Kexec for booke PPC processors
From: Michael Ellerman @ 2006-03-01 23:12 UTC (permalink / raw)
To: fastboot; +Cc: linuxppc-dev, dagriego
In-Reply-To: <3d42041d0603011443v4840d65en4f0676ff86c44e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]
On Thu, 2 Mar 2006 09:43, dagriego wrote:
> I'm finishing my first pass on getting kexec to work on PPC booke
> processor, and needed some insight into how to pass information from the
> first kernel to the kexec'ed kernel. This information is the board
> information that the first kernel is given in r3 from the board firmware.
> Is there a standard convention for passing this information?
Yep, it's called the flat device tree.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PPC,SOUND] Fix audio gpio state detection
From: Benjamin Herrenschmidt @ 2006-03-01 23:09 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, alsa-devel, Ben Collins
In-Reply-To: <20060301223034.GA5965@suse.de>
> > This (sort of) breaks PowerMac3,4 (69 (PowerMac G4 Silver)). I have to
> > force it on up to now, but with this patch the internal speaker will not
> > work with or without my patch to force it on.
>
> But the patch fixes also my PowerBook4,1, I dont have to toggle the headphone
> once to get the built-in speakers enabled.
> Looks like 2.6.16 stuff, but its been broken for so long now...
What is the status of Ben's latest stuff ?
Ben.
^ permalink raw reply
* Re: [PPC,SOUND] Fix audio gpio state detection
From: Olaf Hering @ 2006-03-01 22:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, alsa-devel, Ben Collins
In-Reply-To: <20060226173908.GA4871@suse.de>
On Sun, Feb 26, Olaf Hering wrote:
> On Mon, Feb 13, Benjamin Herrenschmidt wrote:
>
> > On Sat, 2006-02-11 at 17:10 +0100, Andreas Schwab wrote:
> > > When booting with line out or headphone plugged, you won't hear anything.
> > > The problem is that after reset all channels are muted, but the actual
> > > value of the gpio port doesn't exactly match the active_val settings as
> > > expected by check_audio_gpio. For example, the line_mute port is set to
> > > 7, but check_audio_gpio would expect 0xd or 0xf, thus its return value
> > > indicates that it is not active, even though it is. AFAICS only looking
> > > at the low bit is enough to determine whether the port is active.
> > >
> > > Signed-off-by: Andreas Schwab <schwab@suse.de>
> > >
> > > Index: linux-2.6.16-rc2/sound/ppc/tumbler.c
> > > ===================================================================
> > > --- linux-2.6.16-rc2.orig/sound/ppc/tumbler.c 2006-02-03 19:43:50.000000000 +0100
> > > +++ linux-2.6.16-rc2/sound/ppc/tumbler.c 2006-02-11 03:46:30.000000000 +0100
> > > @@ -207,7 +207,7 @@ static int check_audio_gpio(struct pmac_
> > >
> > > ret = do_gpio_read(gp);
> > >
> > > - return (ret & 0xd) == (gp->active_val & 0xd);
> > > + return (ret & 0x1) == (gp->active_val & 0x1);
> > > }
> > >
> > > static int read_audio_gpio(struct pmac_gpio *gp)
>
> This (sort of) breaks PowerMac3,4 (69 (PowerMac G4 Silver)). I have to
> force it on up to now, but with this patch the internal speaker will not
> work with or without my patch to force it on.
But the patch fixes also my PowerBook4,1, I dont have to toggle the headphone
once to get the built-in speakers enabled.
Looks like 2.6.16 stuff, but its been broken for so long now...
^ permalink raw reply
* [PATCH] move eeh_add_device_tree_late()
From: John Rose @ 2006-03-01 18:57 UTC (permalink / raw)
To: Mark Fasheh; +Cc: linuxppc-dev, lkml
In-Reply-To: <20060301175922.GX20175@ca-server1.us.oracle.com>
> Hmm, you still left the EXPORT_SYMBOL(eeh_add_device_late) and you didn't
> make eeh_add_device_late() static. Shouldn't you do that if you don't want
> to make it accessible outside of eeh.c?
> --Mark
Again, good points. Ever have one of those days? Take 2.
Commit 827c1a6c1a5dcb2902fecfb648f9af6a532934eb introduced a new
function that calls eeh_add_device_late() implicitly. This patch
reorders the two functions in question to fix the compile error. This
might be preferable to exposing eeh_add_device_late() in eeh.h.
Thanks-
John
Signed-off-by: John Rose <johnrose@austin.ibm.com>
diff -puN arch/powerpc/platforms/pseries/eeh.c~fix_eeh_bb arch/powerpc/platforms/pseries/eeh.c
--- 2_6_linus_3/arch/powerpc/platforms/pseries/eeh.c~fix_eeh_bb 2006-03-01 10:30:52.000000000 -0600
+++ 2_6_linus_3-johnrose/arch/powerpc/platforms/pseries/eeh.c 2006-03-01 12:54:03.000000000 -0600
@@ -893,20 +893,6 @@ void eeh_add_device_tree_early(struct de
}
EXPORT_SYMBOL_GPL(eeh_add_device_tree_early);
-void eeh_add_device_tree_late(struct pci_bus *bus)
-{
- struct pci_dev *dev;
-
- list_for_each_entry(dev, &bus->devices, bus_list) {
- eeh_add_device_late(dev);
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
- struct pci_bus *subbus = dev->subordinate;
- if (subbus)
- eeh_add_device_tree_late(subbus);
- }
- }
-}
-
/**
* eeh_add_device_late - perform EEH initialization for the indicated pci device
* @dev: pci device for which to set up EEH
@@ -914,7 +900,7 @@ void eeh_add_device_tree_late(struct pci
* This routine must be used to complete EEH initialization for PCI
* devices that were added after system boot (e.g. hotplug, dlpar).
*/
-void eeh_add_device_late(struct pci_dev *dev)
+static void eeh_add_device_late(struct pci_dev *dev)
{
struct device_node *dn;
struct pci_dn *pdn;
@@ -933,7 +919,20 @@ void eeh_add_device_late(struct pci_dev
pci_addr_cache_insert_device (dev);
}
-EXPORT_SYMBOL_GPL(eeh_add_device_late);
+
+void eeh_add_device_tree_late(struct pci_bus *bus)
+{
+ struct pci_dev *dev;
+
+ list_for_each_entry(dev, &bus->devices, bus_list) {
+ eeh_add_device_late(dev);
+ if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+ struct pci_bus *subbus = dev->subordinate;
+ if (subbus)
+ eeh_add_device_tree_late(subbus);
+ }
+ }
+}
/**
* eeh_remove_device - undo EEH setup for the indicated pci device
_
^ permalink raw reply
* Re: [PATCH] move eeh_add_device_tree_late()
From: Mark Fasheh @ 2006-03-01 17:59 UTC (permalink / raw)
To: John Rose; +Cc: linuxppc-dev, lkml
In-Reply-To: <1141230954.19095.19.camel@sinatra.austin.ibm.com>
On Wed, Mar 01, 2006 at 10:35:55AM -0600, John Rose wrote:
> Good catch, Mark.
Heh, thanks.
> Commit 827c1a6c1a5dcb2902fecfb648f9af6a532934eb introduced a new
> function that calls eeh_add_device_late() implicitly. This patch
> reorders the two functions in question to fix the compile error. This
> might be preferable to exposing eeh_add_device_late() in eeh.h.
Hmm, you still left the EXPORT_SYMBOL(eeh_add_device_late) and you didn't
make eeh_add_device_late() static. Shouldn't you do that if you don't want
to make it accessible outside of eeh.c?
--Mark
--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@oracle.com
^ permalink raw reply
* RE: boot failure on lite5200b board
From: #LI JIANGGAN# @ 2006-03-01 17:16 UTC (permalink / raw)
To: John Rigby; +Cc: haidong_feng, linuxppc-embedded
In-Reply-To: <4b73d43f0602240917h1d80bcf8ycc87086305434304@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 12708 bytes --]
how about the following U-boot settings:
..............................
Hit any key to stop autoboot: 0
=> printenv
baudrate=115200
autoload=no
ethact=FEC ETHERNET
ethaddr=00:01:9F:00:27:2F
preboot=echo; echo Autostarting. Press any key to abort..; echo
bootdelay=5
hostname=icecube
bootfile=MPC5200/uImage
nv=nfsroot root=/dev/nfs rw nfsroot=10.190.3.113:/opt/eldk/rootfs
netmask=255.255.240.0
ipaddr=10.190.3.144
serverip=10.190.3.103
bootcmd=run net_nfs
rootfs=root=/dev/nfs rw
netdev=eth0
rootpath=/opt/eldk-4-0/rootfs
nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
ramargs=setenv bootargs root=/dev/ram rw
addip=setenv bootargs ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube:eth0:off panic=1
net_nfs=tftp 200000 MPC5200/uImage;run nfsargs addip;bootm
stdin=serial
stdout=serial
stderr=serial
Environment size: 738/65532 bytes
=> .
................................
The output is still the same, it hangs after displaying arch:exit
I have also tried the above settings with console set, it gives the same output
I am really wondering whether the problem is with the kernel. Sylvain's kernel uImage is only around 600k while the one from freescale is 1.4M, anybody knows where the difference is?
.....................................
Autostarting. Press any key to abort..
Hit any key to stop autoboot: 0
Using FEC ETHERNET device
TFTP from server 10.190.3.103; our IP address is 10.190.3.144
Filename 'MPC5200/uImage'.
Load address: 0x200000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
###################################
done
Bytes transferred = 1510143 (170aff hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.11.7
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1510079 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
ocp: exit
arch: exit
.....................
Regards,
Jianggan LI
________________________________
From: John Rigby [mailto:jcrigby@gmail.com]
Sent: Sat 2/25/2006 1:17
To: #LI JIANGGAN#
Cc: tnt@246tnt.com; linuxppc-embedded@ozlabs.org
Subject: Re: boot failure on lite5200b board
I don't think your syntax for appending to an env variable is correct:
try:
set bootargs $(bootargs) ...appended stuff...
instead of:
set bootargs env bootargs ...appended stuff....
Also to see what bootargs is actually set to after all the nested
commands, add a printenv just before the bootm
On 2/23/06, #LI JIANGGAN# <lijianggan@pmail.ntu.edu.sg> wrote:
>
>
> I have actually tried both kernel with both console configurations. It gave
> the same output, thus I presume that the problem lies somewhere else. I
> attached the log to this email.
>
> the board is Lite5200B Version 1.0. Which .config file do you want?
>
> Sylvain, we have ordered a debugging set but we are still waiting for
> delivery, the leaking time is said to be one month, tant pis. And the log I
> attached here are booting from a higher address (0x500000).
>
> My current u-boot args:
> Autostarting. Press any key to abort..
>
> Hit any key to stop autoboot: 0
> => printenv
> baudrate=115200
> autoload=no
> ethact=FEC ETHERNET
> flshroot=root=/dev/mtdblock2 rw
> ethaddr=00:01:9F:00:27:2F
> preboot=echo; echo Autostarting. Press any key to abort..; echo
> bootdelay=5
> hostname=icecube
> bootfile=MPC5200/uImage
> nv=nfsroot root=/dev/nfs rw nfsroot=10.190.3.113:/opt/eldk/rootfs
> ip=ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
> nfsroot=root=/dev/nfs rw nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> bootcmd=run net_nfs
> filesize=546
> fileaddr=500000
> netmask=255.255.240.0
> ipaddr=10.190.3.144
> serverip=10.190.3.103
> setconsole=setenv bootargs console=ttyPSC0, 115200n8 console=tty1
> rootfs=root=/dev/nfs rw nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> bootargs=env bootargs root=/dev/nfs rw
> nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
> flash_nfs=run setconsole nfsargs addip;bootm
> net_nfs=tftp 500000 MPC5200/uImage;run setconsole nfsargs addip;bootm
> nfsargs=setenv bootargs env bootargs root=/dev/nfs rw
> nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::offroot=/dev/nfs
> rw
> addip=setenv bootargs env bootargs root=/dev/nfs rw
> nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
> ramargs=setenv bootargs root=/dev/ram rw
> console=console=ttyS0,115200n8 console=tty1
> stdin=serial
> stdout=serial
> stderr=serial
>
> Environment size: 1472/65532 bytes
> =>
>
>
>
>
> USING Sylvain's KERNEL:
>
> U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
>
> CPU: MPC5200 v2.2 at 462 MHz
> Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
> Board: Freescale MPC5200 (Lite5200B)
> I2C: 85 kHz, ready
> DRAM: 256 MB
> FLASH: 32 MB
> PCI: Bus Dev VenId DevId Class Int
> 00 1a 1057 5809 0680 00
> In: serial
> Out: serial
> Err: serial
> Net: FEC ETHERNET
> IDE: Bus 0: OK
> Device 0: not available
> Device 1: not available
>
> Autostarting. Press any key to abort..
>
> Hit any key to stop autoboot: 0
> Using FEC ETHERNET device
> TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> Filename 'MPC5200/uImage'.
> Load address: 0x500000
> Loading: #################################################################
> ################################################################
> done
> Bytes transferred = 658114 (a0ac2 hex)
> ## Booting image at 00500000 ...
> Image Name: Linux-2.6.16-rc1
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 658050 Bytes = 642.6 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> setup_arch: enter
> setup_arch: bootmem
> arch: exit
>
>
>
> USING KERNEL FROM Freescale:
>
> U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
>
> CPU: MPC5200 v2.2 at 462 MHz
> Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
> Board: Freescale MPC5200 (Lite5200B)
> I2C: 85 kHz, ready
> DRAM: 256 MB
> FLASH: 32 MB
> PCI: Bus Dev VenId DevId Class Int
> 00 1a 1057 5809 0680 00
> In: serial
> Out: serial
> Err: serial
> Net: FEC ETHERNET
> IDE: Bus 0: OK
> Device 0: not available
> Device 1: not available
>
> Autostarting. Press any key to abort..
>
> Hit any key to stop autoboot: 0
> Using FEC ETHERNET device
> TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> Filename 'MPC5200/uImage'.
> Load address: 0x500000
> Loading: #################################################################
> #################################################################
> #################################################################
> #################################################################
> ###################################
> done
> Bytes transferred = 1510143 (170aff hex)
> ## Booting image at 00500000 ...
> Image Name: Linux-2.6.11.7
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1510079 Bytes = 1.4 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> setup_arch: enter
> setup_arch: bootmem
> ocp: exit
> arch: exit
>
>
>
>
> -----Original Message-----
> From: John Rigby [mailto:jcrigby@gmail.com]
> Sent: Fri 2/24/2006 0:18
> To: #LI JIANGGAN#
> Subject: Re: boot failure on lite5200b board
>
> If you are using Sylvain's kernel you need to set console=ttyPSC0. If you
> are
> using a kernel from Freescale then you need to set console=ttyS0.
>
> Also what rev of the board do you have?
>
>
>
> On 2/23/06, #LI JIANGGAN# <lijianggan@pmail.ntu.edu.sg> wrote:
> >
> >
> > Thank you José María and Andrey for your advices, however the problem
> > remains. I've tried setting the console (though I remember that our
> previous
> > lite5200 board was working fine on kernel 2.4 without setting the
> console);
> > meantime, I've set the booting image to 0x500000; I have also tried using
> > the kernel image come together with the BSP, it's always the same error.
> >
> > Sylvain, I've actually using your kernel source, the compiled image is
> > around 700k (compared to the 1.4M image from the BSP), but it doesn't
> solve
> > the problem. So I presume that the problem is lying somewhere else.
> >
> > A SNAPSHOT OF THE BOOTING MESSAGES:
> >
> >
> > U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
> >
> > CPU: MPC5200 v2.2 at 462 MHz
> > Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
> > Board: Freescale MPC5200 (Lite5200B)
> > I2C: 85 kHz, ready
> > DRAM: 256 MB
> > FLASH: 32 MB
> > PCI: Bus Dev VenId DevId Class Int
> > 00 1a 1057 5809 0680 00
> > In: serial
> > Out: serial
> > Err: serial
> > Net: FEC ETHERNET
> > IDE: Bus 0: OK
> > Device 0: not available
> > Device 1: not available
> >
> > Autostarting. Press any key to abort..
> >
> > Hit any key to stop autoboot: 0
> > Using FEC ETHERNET device
> > TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> > Filename 'MPC5200/uImage'.
> > Load address: 0x100000
> > Loading:
> > #################################################################
> >
> > ################################################################
> > done
> > Bytes transferred = 658114 (a0ac2 hex)
> > ## Booting image at 00100000 ...
> > Image Name: Linux-2.6.16-rc1
> > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > Data Size: 658050 Bytes = 642.6 kB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ... OK
> > id mach(): done
> > MMU:enter
> > MMU:hw init
> > MMU:mapin
> > MMU:setio
> > MMU:exit
> > setup_arch: enter
> > setup_arch: bootmem
> > arch: exit
> >
> >
> > I am wondering whether it's a kernel problem or more likely to be a
> problem
> > lying with the U-boot. It seems to hang when executing setup_arch()
> > function, or maybe there is sth else behind the wall?
> >
> > Regards,
> > Jianggan LI
> >
> >
> >
> >
> > -----Original Message-----
> > From: Sylvain Munaut [mailto:tnt@246tNt.com]
> > Sent: Thu 2/23/2006 15:38
> > To: #LI JIANGGAN#
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: boot failure on lite5200b board
> >
> > #LI JIANGGAN# wrote:
> > > Hello all,
> > >
> > > For my end-of-study project, I am working on an embedded system with
> > > reference of freescale's lite5200b reference board. I was trying to
> boot
> > > Linux 2.6.15 on the board (with the fec and bestcomm corrected).
> however
> > > the booting was stuck at the following stage:
> >
> > In addition to what has already been said (use a higher address for the
> > image and don't forget console=ttyPSC0 in kernel command line), make
> > sure you use the kernel from my git tree, it contains a few patches from
> > John Rigby to add support for the lite5200b.
> >
> > Please report if it works, I've not been able to test those myself since
> > i'm still on lite5200.
> >
> >
> > Sylvain
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
>
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 19591 bytes --]
^ permalink raw reply
* [PATCH] move eeh_add_device_tree_late()
From: John Rose @ 2006-03-01 16:35 UTC (permalink / raw)
To: Mark Fasheh; +Cc: linuxppc-dev, lkml
In-Reply-To: <20060301010249.GV20175@ca-server1.us.oracle.com>
Good catch, Mark.
Commit 827c1a6c1a5dcb2902fecfb648f9af6a532934eb introduced a new
function that calls eeh_add_device_late() implicitly. This patch
reorders the two functions in question to fix the compile error. This
might be preferable to exposing eeh_add_device_late() in eeh.h.
Apologies Paul/everyone, please don't kill me.
Thanks-
John
Signed-off-by: John Rose <johnrose@austin.ibm.com>
diff -puN arch/powerpc/platforms/pseries/eeh.c~fix_eeh_bb arch/powerpc/platforms/pseries/eeh.c
--- 2_6_linus_3/arch/powerpc/platforms/pseries/eeh.c~fix_eeh_bb 2006-03-01 10:30:52.000000000 -0600
+++ 2_6_linus_3-johnrose/arch/powerpc/platforms/pseries/eeh.c 2006-03-01 10:31:28.000000000 -0600
@@ -893,20 +893,6 @@ void eeh_add_device_tree_early(struct de
}
EXPORT_SYMBOL_GPL(eeh_add_device_tree_early);
-void eeh_add_device_tree_late(struct pci_bus *bus)
-{
- struct pci_dev *dev;
-
- list_for_each_entry(dev, &bus->devices, bus_list) {
- eeh_add_device_late(dev);
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
- struct pci_bus *subbus = dev->subordinate;
- if (subbus)
- eeh_add_device_tree_late(subbus);
- }
- }
-}
-
/**
* eeh_add_device_late - perform EEH initialization for the indicated pci device
* @dev: pci device for which to set up EEH
@@ -935,6 +921,20 @@ void eeh_add_device_late(struct pci_dev
}
EXPORT_SYMBOL_GPL(eeh_add_device_late);
+void eeh_add_device_tree_late(struct pci_bus *bus)
+{
+ struct pci_dev *dev;
+
+ list_for_each_entry(dev, &bus->devices, bus_list) {
+ eeh_add_device_late(dev);
+ if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+ struct pci_bus *subbus = dev->subordinate;
+ if (subbus)
+ eeh_add_device_tree_late(subbus);
+ }
+ }
+}
+
/**
* eeh_remove_device - undo EEH setup for the indicated pci device
* @dev: pci device to be removed
_
^ permalink raw reply
* Re: MPC85xx TSEC performance limits
From: Pantelis Antoniou @ 2006-03-01 15:25 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Joyeau Sylvain
In-Reply-To: <9C1918067C3BC14C9C351C206D8A84370398A987@rennsmail03.eu.thmulti.com>
On Wednesday 01 March 2006 14:23, Joyeau Sylvain wrote:
> Hi,
>
> Does anybody already succeeded in getting full TX bandwidth on a TSEC
> interface, transmitting 1500 bytes frames at netdev level (ie calling
> directly dev_queue_xmit(skb)) for instance ?
>
> With default Gianfar driver parameters, I can transmit only around
> 870Mb/s (while reception side is idle). The other TSEC interface is used
> only to control a telnet terminal (~1Kb/s), the CPU is idle 60%,
> 6000irq/s.
>
> I must decrease TX threshold value from 1024 to 128 to get 960Mb/s.
>
> The problem is that decreasing the TX threshold under 512 bytes has a
> dramatic side effect: the Gianfar driver generates "TX underrun" events
> as soon as I start, in parallel, a DMA transfer from memory to memory.
> Rather disappointing behavior from a PQ3@825MHz :-(
>
> Any idea how to get full TX bandwidth _without_ modifying this
> parameter?
>
> Thanks.
>
> --
> sylvain
>
I don't know 85xx in any great detail, but most QUICCs have a register
that controls the DMA bus arbitration priorities. Find it and give
the highest priority to the ethernet.
Pantelis
^ permalink raw reply
* MVME5100 Exception: Program (Illegal Instruction)
From: Bora KARTAL @ 2006-03-01 12:54 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am trying to run linuxppc 2.4.20 with a nfs mounted root file system on=
=20a Motorolla MVME5100 board with a PowerPC 7410 processor. When I used =
the default kernel =FDmage sh=FDpped with MontaVista Linux development ki=
t, it boots up and works fine. But when I build up a custom kernel I am g=
etting the following exception during bootup.
=20
Residual-Data Located at: $1FE9077C
Exception: Program (Illegal Instruction)
SRR0 =3D00005000 SRR1 =3D00083040 Vector-Offset =3D00700
IP =3D00005000 MSR =3D00003040 CR =3D00000000 FPSCR =3D00000000
R0 =3D00000000 R1 =3D1FE00000 R2 =3D00000000 R3 =3D1FE9077C
R4 =3D00005000 R5 =3D00000000 R6 =3D00000000 R7 =3D00000000
R8 =3D00000000 R9 =3D00000000 R10 =3D00000000 R11 =3D00000000
R12 =3D00000000 R13 =3D00000000 R14 =3D00000000 R15 =3D00000000
R16 =3D00000000 R17 =3D00000000 R18 =3D00000000 R19 =3D00000000
R20 =3D00000000 R21 =3D00000000 R22 =3D00000000 R23 =3D00000000
R24 =3D00000000 R25 =3D00000000 R26 =3D00000000 R27 =3D00000000
R28 =3D00000000 R29 =3D00000000 R30 =3D00000000 R31 =3D00000000
SPR0 =3D00000000 SPR1 =3D00000000 SPR8 =3D00000000 SPR9 =3D00000000
00005000 7F454C46 WORD $7F454C46
Anybody can help?
Thanks,
Bora
######################################################################
Dikkat:
Bu elektronik posta mesaji kisisel ve ozeldir. Eger size=20
gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz.=20
Firmamiza gelen ve giden mesajlar virus taramasindan gecirilmekte,=20
guvenlik nedeni ile kontrol edilerek saklanmaktadir. Mesajdaki=20
gorusler ve bakis acisi gondericiye ait olup Aselsan A.S. resmi=20
gorusu olmak zorunda degildir.
######################################################################
Attention:=20
This e-mail message is privileged and confidential. If you are=20
not the intended recipient please delete the message and notify=20
the sender. E-mails to and from the company are monitored for=20
operational reasons and in accordance with lawful business practices.=20
Any views or opinions presented are solely those of the author and=20
do not necessarily represent the views of the company.
######################################################################
^ permalink raw reply
* MPC85xx TSEC performance limits
From: Joyeau Sylvain @ 2006-03-01 12:23 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Does anybody already succeeded in getting full TX bandwidth on a TSEC
interface, transmitting 1500 bytes frames at netdev level (ie calling
directly dev_queue_xmit(skb)) for instance ?
With default Gianfar driver parameters, I can transmit only around
870Mb/s (while reception side is idle). The other TSEC interface is used
only to control a telnet terminal (~1Kb/s), the CPU is idle 60%,
6000irq/s.
I must decrease TX threshold value from 1024 to 128 to get 960Mb/s.
The problem is that decreasing the TX threshold under 512 bytes has a
dramatic side effect: the Gianfar driver generates "TX underrun" events
as soon as I start, in parallel, a DMA transfer from memory to memory.
Rather disappointing behavior from a PQ3@825MHz :-(
Any idea how to get full TX bandwidth _without_ modifying this
parameter?
Thanks.
--
sylvain
^ 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