* machine check in kernel for a mpc870 board @ 2010-06-29 7:59 Shawn Jin 2010-06-29 8:06 ` Joakim Tjernlund 2010-06-29 18:56 ` Scott Wood 0 siblings, 2 replies; 15+ messages in thread From: Shawn Jin @ 2010-06-29 7:59 UTC (permalink / raw) To: ppcdev I'm porting a mpc870 board to the powerpc arch. The base is the adder-875 board. My first try to boot the cuImage.my870 is experiencing a machine check. And I have no clue where to look. Any help? => bootm 1000000 ## Booting image at 01000000 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 747319 Bytes = 729.8 kB Load Address: 00400000 Entry Point: 004004d4 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Bus Fault @ 0x00404c40, fixup 0x00000000 Machine check in kernel mode. Caused by (from msr): regs 07d1cb80 Unknown values in msr NIP: 00404C40 XER: 00000000 LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: 00000001 MSR: 00001002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 GPR00: 00404D50 07D1CC70 00000000 00000004 007FFF0C 00000001 0040AAB8 726F6F74 GPR08: 3D2F6465 0059D958 FF0009C0 0059DDDC FF003C00 1014BAC4 07FFF000 00000001 GPR16: 007FFF0D 004004D4 00000001 007FFF00 07FF9D78 FFFFFFFF 00000000 07D5D2A0 GPR24: 007FFEC0 00800000 00000000 00000000 00000000 0059D958 004129BC 00000000 Call backtrace: machine check Thanks alot, -Shawn. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: machine check in kernel for a mpc870 board 2010-06-29 7:59 machine check in kernel for a mpc870 board Shawn Jin @ 2010-06-29 8:06 ` Joakim Tjernlund 2010-06-29 8:37 ` Shawn Jin 2010-06-29 18:56 ` Scott Wood 1 sibling, 1 reply; 15+ messages in thread From: Joakim Tjernlund @ 2010-06-29 8:06 UTC (permalink / raw) To: Shawn Jin; +Cc: ppcdev > From: Shawn Jin <shawnxjin@gmail.com> > > I'm porting a mpc870 board to the powerpc arch. The base is the > adder-875 board. My first try to boot the cuImage.my870 is > experiencing a machine check. And I have no clue where to look. Any > help? > > => bootm 1000000 > ## Booting image at 01000000 ... > Image Name: Linux-2.6.33.5 > Image Type: PowerPC Linux Kernel Image (gzip compressed) > Data Size: 747319 Bytes = 729.8 kB > Load Address: 00400000 > Entry Point: 004004d4 Load and Entry Point should probably be 0 Jocke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: machine check in kernel for a mpc870 board 2010-06-29 8:06 ` Joakim Tjernlund @ 2010-06-29 8:37 ` Shawn Jin 0 siblings, 0 replies; 15+ messages in thread From: Shawn Jin @ 2010-06-29 8:37 UTC (permalink / raw) To: Joakim Tjernlund; +Cc: ppcdev >> =3D> bootm 1000000 >> ## Booting image at 01000000 ... >> =A0 =A0Image Name: =A0 Linux-2.6.33.5 >> =A0 =A0Image Type: =A0 PowerPC Linux Kernel Image (gzip compressed) >> =A0 =A0Data Size: =A0 =A0747319 Bytes =3D 729.8 kB >> =A0 =A0Load Address: 00400000 >> =A0 =A0Entry Point: =A0004004d4 > > Load and Entry Point should probably be 0 But the cuImage.adder875-uboot image also has the same load address as mine and the entry point is 0x4004d8. Also cuImage.mpc885ads has the same load address and entry point as cuImage.adder875-uboot. So I don't suspect them. All right. I built a uImage for mpc885ads and the uImage's load address and entry point are both 0. So this is because I'm using cuImage instead of uImage. Thanks Joake, anyway. -Shawn. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: machine check in kernel for a mpc870 board 2010-06-29 7:59 machine check in kernel for a mpc870 board Shawn Jin 2010-06-29 8:06 ` Joakim Tjernlund @ 2010-06-29 18:56 ` Scott Wood 2010-06-30 6:14 ` Shawn Jin 1 sibling, 1 reply; 15+ messages in thread From: Scott Wood @ 2010-06-29 18:56 UTC (permalink / raw) To: Shawn Jin; +Cc: ppcdev On Tue, Jun 29, 2010 at 12:59:56AM -0700, Shawn Jin wrote: > I'm porting a mpc870 board to the powerpc arch. The base is the > adder-875 board. My first try to boot the cuImage.my870 is > experiencing a machine check. And I have no clue where to look. Any > help? > > => bootm 1000000 > ## Booting image at 01000000 ... > Image Name: Linux-2.6.33.5 > Image Type: PowerPC Linux Kernel Image (gzip compressed) > Data Size: 747319 Bytes = 729.8 kB > Load Address: 00400000 > Entry Point: 004004d4 > Verifying Checksum ... OK > Uncompressing Kernel Image ... OK > Bus Fault @ 0x00404c40, fixup 0x00000000 > Machine check in kernel mode. > Caused by (from msr): regs 07d1cb80 Unknown values in msr > NIP: 00404C40 XER: 00000000 LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: 00000001 > MSR: 00001002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 Can you look up the source line/instruction corresponding to 0x404c40, in the wrapper ELF file? -Scott ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: machine check in kernel for a mpc870 board 2010-06-29 18:56 ` Scott Wood @ 2010-06-30 6:14 ` Shawn Jin 2010-06-30 16:16 ` Scott Wood 0 siblings, 1 reply; 15+ messages in thread From: Shawn Jin @ 2010-06-30 6:14 UTC (permalink / raw) To: Scott Wood; +Cc: ppcdev Hi Scott, >> Bus Fault @ 0x00404c40, fixup 0x00000000 >> Machine check in kernel mode. >> Caused by (from msr): regs 07d1cb80 Unknown values in msr >> NIP: 00404C40 XER: 00000000 LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: 00000001 >> MSR: 00001002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 > > Can you look up the source line/instruction corresponding to 0x404c40, in > the wrapper ELF file? I'm not sure how to look up it. But I used the BDI to dump the instructions in which you may find some clue? These should be kernel code, right? Maybe the gdb can help to de-assemble them? BDI>md 0x404c00 0x20 00404c00 : 0x4800317d 1207972221 H.1} 00404c04 : 0x80010014 -2147418092 .... 00404c08 : 0xbbc10008 -1144979448 .... 00404c0c : 0x7c0803a6 2080900006 |... 00404c10 : 0x38210010 941686800 8!.. 00404c14 : 0x4e800020 1317011488 N.. 00404c18 : 0x9421fff0 -1809711120 .!.. 00404c1c : 0x7c0802a6 2080899750 |... 00404c20 : 0x429f0005 1117716485 B... 00404c24 : 0xbfc10008 -1077870584 .... 00404c28 : 0x7fc802a6 2143814310 .... 00404c2c : 0x90010014 -1878982636 .... 00404c30 : 0x3fde0001 1071513601 ?... 00404c34 : 0x3bdedd98 1004461464 ;... 00404c38 : 0x813e8000 -2126610432 .>.. 00404c3c : 0x81490000 -2125922304 .I.. 00404c40 : 0xa00a0000 -1609957376 .... 00404c44 : 0x0c000000 201326592 .... 00404c48 : 0x4c00012c 1275068716 L.., 00404c4c : 0x70090001 1879638017 p... 00404c50 : 0x4082fff0 1082327024 @... 00404c54 : 0x817e8000 -2122416128 .~.. 00404c58 : 0x5469402e 1416183854 Ti@. Thanks a lot, -Shawn. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: machine check in kernel for a mpc870 board 2010-06-30 6:14 ` Shawn Jin @ 2010-06-30 16:16 ` Scott Wood 2010-06-30 22:25 ` Shawn Jin 0 siblings, 1 reply; 15+ messages in thread From: Scott Wood @ 2010-06-30 16:16 UTC (permalink / raw) To: Shawn Jin; +Cc: ppcdev On 06/30/2010 01:14 AM, Shawn Jin wrote: > Hi Scott, > >>> Bus Fault @ 0x00404c40, fixup 0x00000000 >>> Machine check in kernel mode. >>> Caused by (from msr): regs 07d1cb80 Unknown values in msr >>> NIP: 00404C40 XER: 00000000 LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: 00000001 >>> MSR: 00001002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 >> >> Can you look up the source line/instruction corresponding to 0x404c40, in >> the wrapper ELF file? > > I'm not sure how to look up it. Use a powerpc gdb on the wrapper ELF file, and do "li *0x404c40" and/or "i li *0x404c40". Or use a powerpc addr2line. > But I used the BDI to dump the > instructions in which you may find some clue? These should be kernel > code, right? Maybe the gdb can help to de-assemble them? Not easily (Format letter "i" is meaningless in "print" command, it says...) and there'd be no context about what part of the source code it corresponds to... > 00404c40 : 0xa00a0000 -1609957376 .... But this is a 16-bit load from r10, which is from your previous register dump is FF0009C0. Does u-boot on your board put IMMR somewhere other than 0xff000000? If so, you'll need to update the device tree to reflect this. -Scott ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: machine check in kernel for a mpc870 board 2010-06-30 16:16 ` Scott Wood @ 2010-06-30 22:25 ` Shawn Jin 2010-07-01 7:50 ` Shawn Jin 0 siblings, 1 reply; 15+ messages in thread From: Shawn Jin @ 2010-06-30 22:25 UTC (permalink / raw) To: Scott Wood; +Cc: ppcdev Hi Scott, > Does u-boot on your board put IMMR somewhere other than 0xff000000? =A0If= so, > you'll need to update the device tree to reflect this. Thanks a lot. I think you got something here. Please bear with me. This is the first dts file I'm creating. I have some question regarding to dts first. BTW, My IMMR is at 0xfa200000. How do I find the address, reg, and range for nodes like localbus, soc, eth0, cpm, serial etc.? Do the addresses of localbus and soc relate to IMMR? So my localbus and soc should be as follows? localbus@fa200100 { compatible =3D "fsl,mpc885-localbus", "fsl,pq1-localbus", "simple-bus"; #address-cells =3D <2>; #size-cells =3D <1>; reg =3D <0xfa200100 0x40>; ranges =3D < 0 0 0xfe000000 0x01000000 // I'm not sure about = this? >; }; soc@fa200000 { compatible =3D "fsl,mpc875-immr", "fsl,pq1-soc", "simple-bu= s"; #address-cells =3D <1>; #size-cells =3D <1>; ranges =3D <0 0xfa200000 0x00004000>; // Temporary until code stops depending on it. device_type =3D "soc"; // Temporary until get_immrbase() is fixed. reg =3D <0xfa200000 0x4000>; }; Thanks again, -Shawn. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: machine check in kernel for a mpc870 board 2010-06-30 22:25 ` Shawn Jin @ 2010-07-01 7:50 ` Shawn Jin 2010-07-01 17:42 ` Scott Wood 0 siblings, 1 reply; 15+ messages in thread From: Shawn Jin @ 2010-07-01 7:50 UTC (permalink / raw) To: Scott Wood; +Cc: ppcdev Hi Scott, > How do I find the address, reg, and range for nodes like localbus, > soc, eth0, cpm, serial etc.? Do the addresses of localbus and soc > relate to IMMR? So my localbus and soc should be as follows? > > =A0 =A0 =A0 =A0localbus@fa200100 { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc885-localbus", "fsl= ,pq1-localbus", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "simple-bus"; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D <2>; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D <1>; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0xfa200100 0x40>; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ranges =3D < > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00 0 0xfe000000 0x01000000 = =A0 =A0// I'm not sure about this? > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>; > =A0 =A0 =A0 =A0}; I managed to proceed a little bit further. Memory <- <0x0 0x8000000> (128MB) ENET0: local-mac-address <- 00:09:9b:01:58:64 CPU clock-frequency <- 0x7270e00 (120MHz) CPU timebase-frequency <- 0x393870 (4MHz) CPU bus-frequency <- 0x3938700 (60MHz) zImage starting: loaded at 0x00400000 (sp: 0x07d1ccd0) Allocating 0x186bdd bytes for kernel ... gunzipping (0x00000000 <- 0x0040c000:0x00591c30)...done 0x173b18 bytes Linux/PowerPC load: root=3D/dev/ram Finalizing device tree... flat tree at 0x59e300 The gdb showed deadbeef. (gdb) target remote ppcbdi:2001 Remote debugging using ppcbdi:2001 0xdeadbeef in ?? () (gdb) The kernel doesn't seem to start. What could go wrong here? Thanks a lot, -Shawn. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: machine check in kernel for a mpc870 board 2010-07-01 7:50 ` Shawn Jin @ 2010-07-01 17:42 ` Scott Wood 2010-07-01 20:17 ` Shawn Jin 0 siblings, 1 reply; 15+ messages in thread From: Scott Wood @ 2010-07-01 17:42 UTC (permalink / raw) To: Shawn Jin; +Cc: ppcdev On 07/01/2010 02:50 AM, Shawn Jin wrote: > Hi Scott, > >> How do I find the address, reg, and range for nodes like localbus, >> soc, eth0, cpm, serial etc.? If your CCSRBAR is 0xfa200000, then pretty much anywhere you see 0xff0xxxxx change it to 0xfa2xxxxx. > I managed to proceed a little bit further. > Memory<-<0x0 0x8000000> (128MB) > ENET0: local-mac-address<- 00:09:9b:01:58:64 > CPU clock-frequency<- 0x7270e00 (120MHz) > CPU timebase-frequency<- 0x393870 (4MHz) > CPU bus-frequency<- 0x3938700 (60MHz) > > zImage starting: loaded at 0x00400000 (sp: 0x07d1ccd0) > Allocating 0x186bdd bytes for kernel ... > gunzipping (0x00000000<- 0x0040c000:0x00591c30)...done 0x173b18 bytes > > Linux/PowerPC load: root=/dev/ram > Finalizing device tree... flat tree at 0x59e300 > > The gdb showed deadbeef. > (gdb) target remote ppcbdi:2001 > Remote debugging using ppcbdi:2001 > 0xdeadbeef in ?? () > (gdb) > > The kernel doesn't seem to start. What could go wrong here? Pretty much anything. :-) Make sure that you've got Linux platform code enabled that matches the top-level compatible of your device tree. Try enabling PPC_EARLY_DEBUG_CPM, making sure to update PPC_EARLY_DEBUG_CPM_ADDR to 0xfa202008. -Scott ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: machine check in kernel for a mpc870 board 2010-07-01 17:42 ` Scott Wood @ 2010-07-01 20:17 ` Shawn Jin 2010-07-01 20:25 ` Scott Wood 0 siblings, 1 reply; 15+ messages in thread From: Shawn Jin @ 2010-07-01 20:17 UTC (permalink / raw) To: Scott Wood; +Cc: ppcdev >>> How do I find the address, reg, and range for nodes like localbus, >>> soc, eth0, cpm, serial etc.? > > If your CCSRBAR is 0xfa200000, then pretty much anywhere you see 0xff0xxx= xx > change it to 0xfa2xxxxx. I'm not sure about the range settings of 0xfe000000. How do you get this? localbus@fa200100 { compatible =3D "fsl,mpc885-localbus", "fsl,pq1-localbus", "simple-bus"; #address-cells =3D <2>; #size-cells =3D <1>; reg =3D <0xfa200100 0x40>; ranges =3D < 0 0 0xfe000000 0x01000000 // I'm not sure about t= his? >; }; >> =A0 =A0 Linux/PowerPC load: root=3D/dev/ram >> =A0 =A0 Finalizing device tree... flat tree at 0x59e300 >> >> The gdb showed deadbeef. >> =A0 =A0 (gdb) target remote ppcbdi:2001 >> =A0 =A0 Remote debugging using ppcbdi:2001 >> =A0 =A0 0xdeadbeef in ?? () >> =A0 =A0 (gdb) >> >> The kernel doesn't seem to start. What could go wrong here? > > Pretty much anything. :-) I realized that. :-P The kernel booting was able to stop at start_kernel(). I'm going to trace further. > Make sure that you've got Linux platform code enabled that matches the > top-level compatible of your device tree. =A0Try enabling PPC_EARLY_DEBUG= _CPM, > making sure to update PPC_EARLY_DEBUG_CPM_ADDR to 0xfa202008. I enabled this early debug feature but don't know this address change. I'll try it later. Thanks a lot, Scott. -Shawn. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: machine check in kernel for a mpc870 board 2010-07-01 20:17 ` Shawn Jin @ 2010-07-01 20:25 ` Scott Wood 2010-07-02 17:06 ` Shawn Jin 0 siblings, 1 reply; 15+ messages in thread From: Scott Wood @ 2010-07-01 20:25 UTC (permalink / raw) To: Shawn Jin; +Cc: ppcdev On 07/01/2010 03:17 PM, Shawn Jin wrote: >>>> How do I find the address, reg, and range for nodes like localbus, >>>> soc, eth0, cpm, serial etc.? >> >> If your CCSRBAR is 0xfa200000, then pretty much anywhere you see 0xff0xxxxx >> change it to 0xfa2xxxxx. > > I'm not sure about the range settings of 0xfe000000. How do you get this? > > localbus@fa200100 { > compatible = "fsl,mpc885-localbus", "fsl,pq1-localbus", > "simple-bus"; > #address-cells =<2>; > #size-cells =<1>; > reg =<0xfa200100 0x40>; > > ranges =< > 0 0 0xfe000000 0x01000000 // I'm not sure about this? > >; > }; Change 0xfe000000 to wherever u-boot maps your flash, and 0x01000000 to whatever the size of the flash localbus mapping is. Or more generally update this section to hold whatever is connected to the localbus on your board. The first cell is the chipselect. >> Make sure that you've got Linux platform code enabled that matches the >> top-level compatible of your device tree. Try enabling PPC_EARLY_DEBUG_CPM, >> making sure to update PPC_EARLY_DEBUG_CPM_ADDR to 0xfa202008. > > I enabled this early debug feature but don't know this address change. The address change is for the different IMMR base, only this use is too early/hacky to get it from the device tree. -Scott ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: machine check in kernel for a mpc870 board 2010-07-01 20:25 ` Scott Wood @ 2010-07-02 17:06 ` Shawn Jin 2010-07-02 17:47 ` Scott Wood 0 siblings, 1 reply; 15+ messages in thread From: Shawn Jin @ 2010-07-02 17:06 UTC (permalink / raw) To: Scott Wood; +Cc: ppcdev >> =A0 =A0 =A0 =A0localbus@fa200100 { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc885-localbus", "fs= l,pq1-localbus", >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "simple-bus"; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D<2>; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D<1>; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D<0xfa200100 0x40>; >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ranges =3D< >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00 0 0xfe000000 0x01000000= =A0 =A0// I'm not sure about >> this? >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>; >> =A0 =A0 =A0 =A0}; > > Change 0xfe000000 to wherever u-boot maps your flash, and 0x01000000 to > whatever the size of the flash localbus mapping is. > > Or more generally update this section to hold whatever is connected to th= e > localbus on your board. =A0The first cell is the chipselect. The chipselect? Isn't it just the child-bus-addr? BTW, do we have to define the #address-cells to 2? 1 is not enough? SDRAM uses CS0/6, each 64MB. BDI2000 configuration is as follows. ; init memory controller WM32 0xFA200104 0xfe000ff6 ;;OR0: Flash 32MB WM32 0xFA200100 0xfc000001 ;;BR0: Flash at 0xFC000000, 32bit, R/W, no parity, use GPCM WM32 0xFA20010C 0xfc000e00 ;;OR1: SDRAM 64MB, all accesses WM32 0xFA200108 0x00000081 ;;BR1: SDRAM at 0x00000000, 32bit, R/W, no parity, use UPMA WM32 0xFA200134 0xfc000e00 ;;OR6: SDRAM 64MB, all accesses WM32 0xFA200130 0x04000081 ;;BR6: SDRAM at 0x04000000, 32bit, = R/W, no parity, use UPMA When defining memory's reg property, can a single pair <0 0x08000000> be enough? Or must it be <0 0x04000000 0x04000000 0x04000000>? Thanks, -Shawn. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: machine check in kernel for a mpc870 board 2010-07-02 17:06 ` Shawn Jin @ 2010-07-02 17:47 ` Scott Wood 2010-07-02 19:16 ` Shawn Jin 0 siblings, 1 reply; 15+ messages in thread From: Scott Wood @ 2010-07-02 17:47 UTC (permalink / raw) To: Shawn Jin; +Cc: ppcdev On Fri, 2 Jul 2010 10:06:47 -0700 Shawn Jin <shawnxjin@gmail.com> wrote: > > Or more generally update this section to hold whatever is connected > > to the localbus on your board. =A0The first cell is the chipselect. >=20 > The chipselect? Isn't it just the child-bus-addr? BTW, do we have to > define the #address-cells to 2? 1 is not enough? The first cell of the child bus address is the chip select, the second cell is the offset into the chip select. > SDRAM uses CS0/6, each 64MB. BDI2000 configuration is as follows. > ; init memory controller > WM32 0xFA200104 0xfe000ff6 ;;OR0: Flash 32MB > WM32 0xFA200100 0xfc000001 ;;BR0: Flash at 0xFC000000, > 32bit, R/W, no parity, use GPCM > WM32 0xFA20010C 0xfc000e00 ;;OR1: SDRAM 64MB, all > accesses WM32 0xFA200108 0x00000081 ;;BR1: SDRAM at > 0x00000000, 32bit, R/W, no parity, use UPMA > WM32 0xFA200134 0xfc000e00 ;;OR6: SDRAM 64MB, all > accesses WM32 0xFA200130 0x04000081 ;;BR6: SDRAM at > 0x04000000, 32bit, R/W, no parity, use UPMA That looks like SDRAM is on CS1/6, not CS0/6. We haven't been putting ordinary RAM under the localbus node, even though it's connected through the localbus on these chips. > When defining memory's reg property, can a single pair <0 0x08000000> > be enough? Or must it be <0 0x04000000 0x04000000 0x04000000>? A single pair is fine. -Scott ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: machine check in kernel for a mpc870 board 2010-07-02 17:47 ` Scott Wood @ 2010-07-02 19:16 ` Shawn Jin 2010-07-02 19:41 ` Scott Wood 0 siblings, 1 reply; 15+ messages in thread From: Shawn Jin @ 2010-07-02 19:16 UTC (permalink / raw) To: Scott Wood; +Cc: ppcdev >> The chipselect? Isn't it just the child-bus-addr? BTW, do we have to >> define the #address-cells to 2? 1 is not enough? > > The first cell of the child bus address is the chip select, the second > cell is the offset into the chip select. I see. So the #address-sells of 2 doesn't necessarily indicate the address is 64 bits? Different processors can interpret it differently? Where can I find such info? Is there any doc on this? I have a question on the serial settings. Why does it locate at 0xa80? According to MPC885RM.pdf, the SMC1's registers start from 0xa82. What does the reg property specify here for SMC1, the first set of <0xa80 0x10> and the 2nd <0x3e80 0x40>? console: serial@a80 { device_type = "serial"; compatible = "fsl,mpc875-smc-uart", "fsl,cpm1-smc-uart"; reg = <0xa80 0x10 0x3e80 0x40>; interrupts = <4>; interrupt-parent = <&CPM_PIC>; fsl,cpm-brg = <1>; fsl,cpm-command = <0x0090>; current-speed = <115200>; Thanks a lot, -Shawn. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: machine check in kernel for a mpc870 board 2010-07-02 19:16 ` Shawn Jin @ 2010-07-02 19:41 ` Scott Wood 0 siblings, 0 replies; 15+ messages in thread From: Scott Wood @ 2010-07-02 19:41 UTC (permalink / raw) To: Shawn Jin; +Cc: ppcdev On Fri, 2 Jul 2010 12:16:11 -0700 Shawn Jin <shawnxjin@gmail.com> wrote: > >> The chipselect? Isn't it just the child-bus-addr? BTW, do we have > >> to define the #address-cells to 2? 1 is not enough? > > > > The first cell of the child bus address is the chip select, the > > second cell is the offset into the chip select. >=20 > I see. So the #address-sells of 2 doesn't necessarily indicate the > address is 64 bits? Well, there's 64 bits of data, but it doesn't mean that it's one 64-bit integer. > Different processors can interpret it differently? Different device tree bus types can -- though in this case it translates to an ordinary CPU address using the standand ranges property. > Where can I find such info? Is there any doc on this? Documentation/powerpc/dts-bindings/fsl/lbc.txt > I have a question on the serial settings. Why does it locate at 0xa80? > According to MPC885RM.pdf, the SMC1's registers start from 0xa82.=20 I suppose the interpretation was that the register block starts at 0xa80, and the first register within that block is at 0xa82 -- though the manual seems to actually lump those two reserved bytes in with the previous section. > What does the reg property specify here for SMC1, the first set of <0xa80 > 0x10> and the 2nd <0x3e80 0x40>? =46rom Documentation/powerpc/dts-bindings/fsl/cpm.txt: > - reg : Unless otherwise specified, the first resource represents the =20 > scc/fcc/ucc registers, and the second represents the device's > parameter RAM region (if it has one). -Scott ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2010-07-02 19:41 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-06-29 7:59 machine check in kernel for a mpc870 board Shawn Jin 2010-06-29 8:06 ` Joakim Tjernlund 2010-06-29 8:37 ` Shawn Jin 2010-06-29 18:56 ` Scott Wood 2010-06-30 6:14 ` Shawn Jin 2010-06-30 16:16 ` Scott Wood 2010-06-30 22:25 ` Shawn Jin 2010-07-01 7:50 ` Shawn Jin 2010-07-01 17:42 ` Scott Wood 2010-07-01 20:17 ` Shawn Jin 2010-07-01 20:25 ` Scott Wood 2010-07-02 17:06 ` Shawn Jin 2010-07-02 17:47 ` Scott Wood 2010-07-02 19:16 ` Shawn Jin 2010-07-02 19:41 ` Scott Wood
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).