| Message ID | 200904291553.49378.jpihet@mvista.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
Hello Jean, sorry about the delay, On Wed, 29 Apr 2009, Jean Pihet wrote: > The suspend/resume on Beagleboard has some problem due to bad memory timings. > Suspending for more than 5 to 10 seconds shows memory corruption. > > The new chips on rev Cx boards are using 2 DDR chip selects and it looks like > the 2nd memory part is not correctly put into self refresh. As an > experimentation I tried the same kernel with 'mem=128M' and it resumes > correctly after 1 min in suspend. Nice work, this seems likely to be the cause. > I could not find the latest DDR detailed specs from Micron. The part number is > MT29C2G48MAKLCJI-6 IT. Are those available? Is this part identical to 2 1Gb > parts? The combined part's web page is: http://www.micron.com/products/partdetail?part=MT29C2G48MAKLCJI-6%20IT The SDRAM datasheet is the same that is used for all the other Micron parts that we've run across so far: http://download.micron.com/pdf/datasheets/dram/mobile/1gb_ddr_mobile_sdram_t48m.pdf > Now for the code in the kernel, there are some changes needed to support 2 > CS'es: > - the SDRC parameters need to be updated for the new memory part > - the SDRC parameters need to include the ACTIM_CTRL_A_0, ACTIM_CTRL_A_1, > ACTIM_CTRL_B_0, ACTIM_CTRL_B_1, RFR_CTRL_0 and RFR_CTRL_1 registers. Since > the parameters for the 2nd CS are the same, this can be avoided by writing > the same values to the 2 sets of registers > - is there a need to differentiate between 1Gb and 2Gb chips, or can we just > write the same params for both CS'es even if only one is being used? > - the 'configure_sdrc' function in arch/arm/mach-omap2/sram34xx.S needs to > program the 2 sets of registers. Here is a patch excerpt below. This patch > only does not help the suspend/resume though. > > Any idea or suggestion? Looks like a good start. Since the two SDRC chip-selects can technically address parts with different timings, we should not assume that the two chip selects will be the same. Admittedly this seems like an unlikely situation, but it's not impossible for non-POP OMAPs. Re: suspend/resume, if you're talking about the code in sleep34xx.S, it looks like this is already in good shape. Re: board & SDRC changes: would suggest modifying omap2_sdrc_init() to take either two struct omap_sdrc_params pointers, or one struct with two pointers. omap2_init_common_hw() will also need to be updated for that, and all of the board-*.c files also. Sound reasonable? > ldr r11, omap3_sdrc_mr_0 > str r6, [r11] > ldr r6, [r11] @ posted-write barrier for SDRC > + ldr r11, omap3_sdrc_mr_1 > + str r6, [r11] > + ldr r6, [r11] @ posted-write barrier for SDRC > bx lr By the way, there's no need to duplicate the posted-write barrier. There should only be one, appearing right before the 'bx lr'. regards, - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Paul, On Thursday 07 May 2009 01:39:02 Paul Walmsley wrote: > Hello Jean, > > sorry about the delay, Thanks for replying! > On Wed, 29 Apr 2009, Jean Pihet wrote: > > The suspend/resume on Beagleboard has some problem due to bad memory > > timings. Suspending for more than 5 to 10 seconds shows memory > > corruption. > > > > The new chips on rev Cx boards are using 2 DDR chip selects and it looks > > like the 2nd memory part is not correctly put into self refresh. As an > > experimentation I tried the same kernel with 'mem=128M' and it resumes > > correctly after 1 min in suspend. > > Nice work, this seems likely to be the cause. > > > I could not find the latest DDR detailed specs from Micron. The part > > number is MT29C2G48MAKLCJI-6 IT. Are those available? Is this part > > identical to 2 1Gb parts? > > The combined part's web page is: > > http://www.micron.com/products/partdetail?part=MT29C2G48MAKLCJI-6%20IT > > The SDRAM datasheet is the same that is used for all the other Micron > parts that we've run across so far: > > http://download.micron.com/pdf/datasheets/dram/mobile/1gb_ddr_mobile_sdram_ >t48m.pdf Ok so we have 2 DDRs combined. That does not explain why the self-refresh is ok with only 1 part while it fails with the 2 parts. Could it be that the timings are too tight? Is there something special for the SDRC to support the 2 CSes correctly? We already have used the self refresh with 2 parts hooked on a 3430, not Micron parts though, so the code looks correct. I think we need help from the HW vendors here to identify the root cause: SDRC, DDR parts, connections? > > Now for the code in the kernel, there are some changes needed to support > > 2 CS'es: > > - the SDRC parameters need to be updated for the new memory part > > - the SDRC parameters need to include the ACTIM_CTRL_A_0, ACTIM_CTRL_A_1, > > ACTIM_CTRL_B_0, ACTIM_CTRL_B_1, RFR_CTRL_0 and RFR_CTRL_1 registers. > > Since the parameters for the 2nd CS are the same, this can be avoided by > > writing the same values to the 2 sets of registers > > - is there a need to differentiate between 1Gb and 2Gb chips, or can we > > just write the same params for both CS'es even if only one is being used? > > - the 'configure_sdrc' function in arch/arm/mach-omap2/sram34xx.S needs > > to program the 2 sets of registers. Here is a patch excerpt below. This > > patch only does not help the suspend/resume though. > > > > Any idea or suggestion? > > Looks like a good start. Since the two SDRC chip-selects can technically > address parts with different timings, we should not assume that the two > chip selects will be the same. Admittedly this seems like an unlikely > situation, but it's not impossible for non-POP OMAPs. Makes sense. It is better to have correct and generic code. > Re: suspend/resume, if you're talking about the code in sleep34xx.S, it > looks like this is already in good shape. > > Re: board & SDRC changes: would suggest modifying omap2_sdrc_init() to > take either two struct omap_sdrc_params pointers, or one struct with two > pointers. omap2_init_common_hw() will also need to be updated for that, > and all of the board-*.c files also. > > Sound reasonable? Sure. I can write the new code, but I prefer to have the self refresh working first. > > ldr r11, omap3_sdrc_mr_0 > > str r6, [r11] > > ldr r6, [r11] @ posted-write barrier for SDRC > > + ldr r11, omap3_sdrc_mr_1 > > + str r6, [r11] > > + ldr r6, [r11] @ posted-write barrier for SDRC > > bx lr > > By the way, there's no need to duplicate the posted-write barrier. There > should only be one, appearing right before the 'bx lr'. Ok I will take it into account. > > regards, > > - Paul Regards, Jean -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, FYI I tried to relax the DDR timings (mainly tRC, tWTR, tXP, tXSR, ARCV) but that did not help. From the OMAP datasheet it looks like the ARCV setting is off: shouldn't it be (tREFI/tCK)+50=(7800/6)+50=0x546? Is there a way to know if the self refresh works on both parts? Regards, Jean On Thursday 07 May 2009 13:18:30 Jean Pihet wrote: > Hi Paul, > > On Thursday 07 May 2009 01:39:02 Paul Walmsley wrote: > > Hello Jean, > > > > sorry about the delay, > > Thanks for replying! > > > On Wed, 29 Apr 2009, Jean Pihet wrote: > > > The suspend/resume on Beagleboard has some problem due to bad memory > > > timings. Suspending for more than 5 to 10 seconds shows memory > > > corruption. > > > > > > The new chips on rev Cx boards are using 2 DDR chip selects and it > > > looks like the 2nd memory part is not correctly put into self refresh. > > > As an experimentation I tried the same kernel with 'mem=128M' and it > > > resumes correctly after 1 min in suspend. > > > > Nice work, this seems likely to be the cause. > > > > > I could not find the latest DDR detailed specs from Micron. The part > > > number is MT29C2G48MAKLCJI-6 IT. Are those available? Is this part > > > identical to 2 1Gb parts? > > > > The combined part's web page is: > > > > http://www.micron.com/products/partdetail?part=MT29C2G48MAKLCJI-6%20IT > > > > The SDRAM datasheet is the same that is used for all the other Micron > > parts that we've run across so far: > > > > http://download.micron.com/pdf/datasheets/dram/mobile/1gb_ddr_mobile_sdra > >m_ t48m.pdf > > Ok so we have 2 DDRs combined. > That does not explain why the self-refresh is ok with only 1 part while it > fails with the 2 parts. > Could it be that the timings are too tight? Is there something special for > the SDRC to support the 2 CSes correctly? > > We already have used the self refresh with 2 parts hooked on a 3430, not > Micron parts though, so the code looks correct. > > I think we need help from the HW vendors here to identify the root cause: > SDRC, DDR parts, connections? > > > > Now for the code in the kernel, there are some changes needed to > > > support 2 CS'es: > > > - the SDRC parameters need to be updated for the new memory part > > > - the SDRC parameters need to include the ACTIM_CTRL_A_0, > > > ACTIM_CTRL_A_1, ACTIM_CTRL_B_0, ACTIM_CTRL_B_1, RFR_CTRL_0 and > > > RFR_CTRL_1 registers. Since the parameters for the 2nd CS are the same, > > > this can be avoided by writing the same values to the 2 sets of > > > registers > > > - is there a need to differentiate between 1Gb and 2Gb chips, or can we > > > just write the same params for both CS'es even if only one is being > > > used? - the 'configure_sdrc' function in arch/arm/mach-omap2/sram34xx.S > > > needs to program the 2 sets of registers. Here is a patch excerpt > > > below. This patch only does not help the suspend/resume though. > > > > > > Any idea or suggestion? > > > > Looks like a good start. Since the two SDRC chip-selects can technically > > address parts with different timings, we should not assume that the two > > chip selects will be the same. Admittedly this seems like an unlikely > > situation, but it's not impossible for non-POP OMAPs. > > Makes sense. It is better to have correct and generic code. > > > Re: suspend/resume, if you're talking about the code in sleep34xx.S, it > > looks like this is already in good shape. > > > > Re: board & SDRC changes: would suggest modifying omap2_sdrc_init() to > > take either two struct omap_sdrc_params pointers, or one struct with two > > pointers. omap2_init_common_hw() will also need to be updated for that, > > and all of the board-*.c files also. > > > > Sound reasonable? > > Sure. I can write the new code, but I prefer to have the self refresh > working first. > > > > ldr r11, omap3_sdrc_mr_0 > > > str r6, [r11] > > > ldr r6, [r11] @ posted-write barrier for SDRC > > > + ldr r11, omap3_sdrc_mr_1 > > > + str r6, [r11] > > > + ldr r6, [r11] @ posted-write barrier for SDRC > > > bx lr > > > > By the way, there's no need to duplicate the posted-write barrier. There > > should only be one, appearing right before the 'bx lr'. > > Ok I will take it into account. > > > regards, > > > > - Paul > > Regards, > Jean > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Jean On Thu, 7 May 2009, Jean Pihet wrote: > From the OMAP datasheet it looks like the ARCV setting is off: shouldn't it be > (tREFI/tCK)+50=(7800/6)+50=0x546? Could you elaborate further what you're seeing? It would help to see the register value that you're using to come to this conclusion. - Paul > > Is there a way to know if the self refresh works on both parts? > > Regards, > Jean > > On Thursday 07 May 2009 13:18:30 Jean Pihet wrote: > > Hi Paul, > > > > On Thursday 07 May 2009 01:39:02 Paul Walmsley wrote: > > > Hello Jean, > > > > > > sorry about the delay, > > > > Thanks for replying! > > > > > On Wed, 29 Apr 2009, Jean Pihet wrote: > > > > The suspend/resume on Beagleboard has some problem due to bad memory > > > > timings. Suspending for more than 5 to 10 seconds shows memory > > > > corruption. > > > > > > > > The new chips on rev Cx boards are using 2 DDR chip selects and it > > > > looks like the 2nd memory part is not correctly put into self refresh. > > > > As an experimentation I tried the same kernel with 'mem=128M' and it > > > > resumes correctly after 1 min in suspend. > > > > > > Nice work, this seems likely to be the cause. > > > > > > > I could not find the latest DDR detailed specs from Micron. The part > > > > number is MT29C2G48MAKLCJI-6 IT. Are those available? Is this part > > > > identical to 2 1Gb parts? > > > > > > The combined part's web page is: > > > > > > http://www.micron.com/products/partdetail?part=MT29C2G48MAKLCJI-6%20IT > > > > > > The SDRAM datasheet is the same that is used for all the other Micron > > > parts that we've run across so far: > > > > > > http://download.micron.com/pdf/datasheets/dram/mobile/1gb_ddr_mobile_sdra > > >m_ t48m.pdf > > > > Ok so we have 2 DDRs combined. > > That does not explain why the self-refresh is ok with only 1 part while it > > fails with the 2 parts. > > Could it be that the timings are too tight? Is there something special for > > the SDRC to support the 2 CSes correctly? > > > > We already have used the self refresh with 2 parts hooked on a 3430, not > > Micron parts though, so the code looks correct. > > > > I think we need help from the HW vendors here to identify the root cause: > > SDRC, DDR parts, connections? > > > > > > Now for the code in the kernel, there are some changes needed to > > > > support 2 CS'es: > > > > - the SDRC parameters need to be updated for the new memory part > > > > - the SDRC parameters need to include the ACTIM_CTRL_A_0, > > > > ACTIM_CTRL_A_1, ACTIM_CTRL_B_0, ACTIM_CTRL_B_1, RFR_CTRL_0 and > > > > RFR_CTRL_1 registers. Since the parameters for the 2nd CS are the same, > > > > this can be avoided by writing the same values to the 2 sets of > > > > registers > > > > - is there a need to differentiate between 1Gb and 2Gb chips, or can we > > > > just write the same params for both CS'es even if only one is being > > > > used? - the 'configure_sdrc' function in arch/arm/mach-omap2/sram34xx.S > > > > needs to program the 2 sets of registers. Here is a patch excerpt > > > > below. This patch only does not help the suspend/resume though. > > > > > > > > Any idea or suggestion? > > > > > > Looks like a good start. Since the two SDRC chip-selects can technically > > > address parts with different timings, we should not assume that the two > > > chip selects will be the same. Admittedly this seems like an unlikely > > > situation, but it's not impossible for non-POP OMAPs. > > > > Makes sense. It is better to have correct and generic code. > > > > > Re: suspend/resume, if you're talking about the code in sleep34xx.S, it > > > looks like this is already in good shape. > > > > > > Re: board & SDRC changes: would suggest modifying omap2_sdrc_init() to > > > take either two struct omap_sdrc_params pointers, or one struct with two > > > pointers. omap2_init_common_hw() will also need to be updated for that, > > > and all of the board-*.c files also. > > > > > > Sound reasonable? > > > > Sure. I can write the new code, but I prefer to have the self refresh > > working first. > > > > > > ldr r11, omap3_sdrc_mr_0 > > > > str r6, [r11] > > > > ldr r6, [r11] @ posted-write barrier for SDRC > > > > + ldr r11, omap3_sdrc_mr_1 > > > > + str r6, [r11] > > > > + ldr r6, [r11] @ posted-write barrier for SDRC > > > > bx lr > > > > > > By the way, there's no need to duplicate the posted-write barrier. There > > > should only be one, appearing right before the 'bx lr'. > > > > Ok I will take it into account. > > > > > regards, > > > > > > - Paul > > > > Regards, > > Jean > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Jean, one other suggestion. You mentioned that you had self-refresh working on another OMAP3430 board with two SDRAM chip-selects. You might consider dumping the SDRC registers from that board, and dumping the SDRC registers on Beagle rev C, and comparing. It could be that the bootloader on your other board is setting some important bit. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Paul, On Thursday 07 May 2009 20:59:43 Paul Walmsley wrote: > Hello Jean > > On Thu, 7 May 2009, Jean Pihet wrote: > > From the OMAP datasheet it looks like the ARCV setting is off: shouldn't > > it be (tREFI/tCK)+50=(7800/6)+50=0x546? > > Could you elaborate further what you're seeing? It would help to > see the register value that you're using to come to this conclusion. The SDRC_RFR_CTRL_p registers are now programmed with 0x4dc01, which means the fiel ARCV has the value 0x4dc=1244. From the DDR datasheet we need an average refresh period of 7.8us and a clock period of 6ns (166MHz). From the definition of the ARCV field in the OMAP TRM I need to program ARCV with: (tREFI/tCK)+50 = (7800/6)+50=1350=0x546. The SDRC_RFR_CTRL_p registers would then have the value of 0x54601. Does that make sense? Am I wrong with the calculation? > > - Paul Regards, Jean > > > Is there a way to know if the self refresh works on both parts? > > > > Regards, > > Jean > > > > On Thursday 07 May 2009 13:18:30 Jean Pihet wrote: > > > Hi Paul, > > > > > > On Thursday 07 May 2009 01:39:02 Paul Walmsley wrote: > > > > Hello Jean, > > > > > > > > sorry about the delay, > > > > > > Thanks for replying! > > > > > > > On Wed, 29 Apr 2009, Jean Pihet wrote: > > > > > The suspend/resume on Beagleboard has some problem due to bad > > > > > memory timings. Suspending for more than 5 to 10 seconds shows > > > > > memory corruption. > > > > > > > > > > The new chips on rev Cx boards are using 2 DDR chip selects and it > > > > > looks like the 2nd memory part is not correctly put into self > > > > > refresh. As an experimentation I tried the same kernel with > > > > > 'mem=128M' and it resumes correctly after 1 min in suspend. > > > > > > > > Nice work, this seems likely to be the cause. > > > > > > > > > I could not find the latest DDR detailed specs from Micron. The > > > > > part number is MT29C2G48MAKLCJI-6 IT. Are those available? Is this > > > > > part identical to 2 1Gb parts? > > > > > > > > The combined part's web page is: > > > > > > > > http://www.micron.com/products/partdetail?part=MT29C2G48MAKLCJI-6%20I > > > >T > > > > > > > > The SDRAM datasheet is the same that is used for all the other Micron > > > > parts that we've run across so far: > > > > > > > > http://download.micron.com/pdf/datasheets/dram/mobile/1gb_ddr_mobile_ > > > >sdra m_ t48m.pdf > > > > > > Ok so we have 2 DDRs combined. > > > That does not explain why the self-refresh is ok with only 1 part while > > > it fails with the 2 parts. > > > Could it be that the timings are too tight? Is there something special > > > for the SDRC to support the 2 CSes correctly? > > > > > > We already have used the self refresh with 2 parts hooked on a 3430, > > > not Micron parts though, so the code looks correct. > > > > > > I think we need help from the HW vendors here to identify the root > > > cause: SDRC, DDR parts, connections? > > > > > > > > Now for the code in the kernel, there are some changes needed to > > > > > support 2 CS'es: > > > > > - the SDRC parameters need to be updated for the new memory part > > > > > - the SDRC parameters need to include the ACTIM_CTRL_A_0, > > > > > ACTIM_CTRL_A_1, ACTIM_CTRL_B_0, ACTIM_CTRL_B_1, RFR_CTRL_0 and > > > > > RFR_CTRL_1 registers. Since the parameters for the 2nd CS are the > > > > > same, this can be avoided by writing the same values to the 2 sets > > > > > of registers > > > > > - is there a need to differentiate between 1Gb and 2Gb chips, or > > > > > can we just write the same params for both CS'es even if only one > > > > > is being used? - the 'configure_sdrc' function in > > > > > arch/arm/mach-omap2/sram34xx.S needs to program the 2 sets of > > > > > registers. Here is a patch excerpt below. This patch only does not > > > > > help the suspend/resume though. > > > > > > > > > > Any idea or suggestion? > > > > > > > > Looks like a good start. Since the two SDRC chip-selects can > > > > technically address parts with different timings, we should not > > > > assume that the two chip selects will be the same. Admittedly this > > > > seems like an unlikely situation, but it's not impossible for non-POP > > > > OMAPs. > > > > > > Makes sense. It is better to have correct and generic code. > > > > > > > Re: suspend/resume, if you're talking about the code in sleep34xx.S, > > > > it looks like this is already in good shape. > > > > > > > > Re: board & SDRC changes: would suggest modifying omap2_sdrc_init() > > > > to take either two struct omap_sdrc_params pointers, or one struct > > > > with two pointers. omap2_init_common_hw() will also need to be > > > > updated for that, and all of the board-*.c files also. > > > > > > > > Sound reasonable? > > > > > > Sure. I can write the new code, but I prefer to have the self refresh > > > working first. > > > > > > > > ldr r11, omap3_sdrc_mr_0 > > > > > str r6, [r11] > > > > > ldr r6, [r11] @ posted-write barrier for > > > > > SDRC + ldr r11, omap3_sdrc_mr_1 > > > > > + str r6, [r11] > > > > > + ldr r6, [r11] @ posted-write barrier for > > > > > SDRC bx lr > > > > > > > > By the way, there's no need to duplicate the posted-write barrier. > > > > There should only be one, appearing right before the 'bx lr'. > > > > > > Ok I will take it into account. > > > > > > > regards, > > > > > > > > - Paul > > > > > > Regards, > > > Jean > > > > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-omap" > > > in the body of a message to majordomo@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 07 May 2009 21:18:41 Paul Walmsley wrote: > Hello Jean, > > one other suggestion. You mentioned that you had self-refresh working on > another OMAP3430 board with two SDRAM chip-selects. You might consider > dumping the SDRC registers from that board, and dumping the SDRC registers > on Beagle rev C, and comparing. It could be that the bootloader on your > other board is setting some important bit. The comparison gives the following: - the timings are slightly different but given that the parts are not the same I do not think it is a problem - the fields FIXEDDELAY and MODEFIXEDDELAYINITLAT are set in SDRC_DLLA_CTRL, the register value is 0x2600000A. Does that affect the 166MHz operation? - the field DEEPPD of SDRC_MCFG_p is set to 0. That setting could affect the suspend/resume - the MUX scheme is different: ADDRMUXLEGACY is set to 0 - the field BANKALLOCATION of SDRC_MCFG_p is set to 0 instead of 2 I tried to change those fields on the Beagleboard but still suspending for more than 10sec corrupts the memory. > - Paul Regards, Jean -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Jean, On Fri, 8 May 2009, Jean Pihet wrote: > On Thursday 07 May 2009 20:59:43 Paul Walmsley wrote: > > On Thu, 7 May 2009, Jean Pihet wrote: > > > From the OMAP datasheet it looks like the ARCV setting is off: shouldn't > > > it be (tREFI/tCK)+50=(7800/6)+50=0x546? > > > > Could you elaborate further what you're seeing? It would help to > > see the register value that you're using to come to this conclusion. > The SDRC_RFR_CTRL_p registers are now programmed with 0x4dc01, which means the > fiel ARCV has the value 0x4dc=1244. > From the DDR datasheet we need an average refresh period of 7.8us and a clock > period of 6ns (166MHz). From the definition of the ARCV field in the OMAP TRM > I need to program ARCV with: (tREFI/tCK)+50 = (7800/6)+50=1350=0x546. > The SDRC_RFR_CTRL_p registers would then have the value of 0x54601. > > Does that make sense? Am I wrong with the calculation? According to the TRM, the 50 cycles should be subtracted rather than added (section 11.2.6.3.3.4). One other thing is that the bootloaders I've seen program DPLL3 such that the SDRC clock is 166000000 Hz, rather than 166666666 Hz, so tCK winds up being something like 6.024... ns. Auto-refresh is only used while the SDRC is active, though. So unless memory corruption is evident outside of suspend, the ARCV value is unlikely to be the problem. It sounds like the problem is related to self-refresh, that the SDRAM bank on one of the chipselects either can't enter or exit self-refresh. You have self-refresh working on a different board with both SDRC CS0 and CS1 in use, correct? Is that with an ES2 or ES3 chip? One possibility: perhaps the problem is with Beagle's pin mux settings. You might want to boot with mem=128M and make sure CONTROL_PADCONF_SAD2D_SBUSFLAG and CONTROL_PADCONF_SDRC_CKE1 are in mode 0 before suspend and after resume. Another thought: it could be that the ROM code on Beagle is not programming the correct SDRC register values after resume. You might try booting with mem=128M and dumping the SDRC register values before suspend and after resume. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 8 May 2009, Jean Pihet wrote: > On Thursday 07 May 2009 21:18:41 Paul Walmsley wrote: > > Hello Jean, > > > > one other suggestion. You mentioned that you had self-refresh working on > > another OMAP3430 board with two SDRAM chip-selects. You might consider > > dumping the SDRC registers from that board, and dumping the SDRC registers > > on Beagle rev C, and comparing. It could be that the bootloader on your > > other board is setting some important bit. > The comparison gives the following: > - the timings are slightly different but given that the parts are not the same > I do not think it is a problem > - the fields FIXEDDELAY and MODEFIXEDDELAYINITLAT are set in SDRC_DLLA_CTRL, > the register value is 0x2600000A. Does that affect the 166MHz operation? It shouldn't. > - the field DEEPPD of SDRC_MCFG_p is set to 0. That setting could affect the > suspend/resume I don't think this should matter, since we never power off the SDRAM. > - the MUX scheme is different: ADDRMUXLEGACY is set to 0 > - the field BANKALLOCATION of SDRC_MCFG_p is set to 0 instead of 2 - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Paul, On Saturday 09 May 2009 00:43:43 Paul Walmsley wrote: > Hello Jean, > > On Fri, 8 May 2009, Jean Pihet wrote: > > On Thursday 07 May 2009 20:59:43 Paul Walmsley wrote: > > > On Thu, 7 May 2009, Jean Pihet wrote: > > > > From the OMAP datasheet it looks like the ARCV setting is off: > > > > shouldn't it be (tREFI/tCK)+50=(7800/6)+50=0x546? > > > > > > Could you elaborate further what you're seeing? It would help to > > > see the register value that you're using to come to this conclusion. > > > > The SDRC_RFR_CTRL_p registers are now programmed with 0x4dc01, which > > means the fiel ARCV has the value 0x4dc=1244. > > From the DDR datasheet we need an average refresh period of 7.8us and a > > clock period of 6ns (166MHz). From the definition of the ARCV field in > > the OMAP TRM I need to program ARCV with: (tREFI/tCK)+50 = > > (7800/6)+50=1350=0x546. The SDRC_RFR_CTRL_p registers would then have the > > value of 0x54601. > > > > Does that make sense? Am I wrong with the calculation? > > According to the TRM, the 50 cycles should be subtracted rather than added > (section 11.2.6.3.3.4). One other thing is that the bootloaders I've seen > program DPLL3 such that the SDRC clock is 166000000 Hz, rather than > 166666666 Hz, so tCK winds up being something like 6.024... ns. The settings should be ok with tCK=6.024ns > Auto-refresh is only used while the SDRC is active, though. So unless > memory corruption is evident outside of suspend, the ARCV value is > unlikely to be the problem. Ok > It sounds like the problem is related to self-refresh, that the SDRAM bank > on one of the chipselects either can't enter or exit self-refresh. You > have self-refresh working on a different board with both SDRC CS0 and CS1 > in use, correct? Is that with an ES2 or ES3 chip? > > One possibility: perhaps the problem is with Beagle's pin mux settings. > You might want to boot with mem=128M and make sure > CONTROL_PADCONF_SAD2D_SBUSFLAG and CONTROL_PADCONF_SDRC_CKE1 are in mode 0 > before suspend and after resume. Yes that definitely is the root cause. I should have checked this first ;-( The U-Boot change is committed, cf. http://gitorious.org/u-boot-omap3/mainline/commit/c6f01ad390308800693c62dbdb096ab59e03630b and http://gitorious.org/u-boot-omap3/mainline/commit/4025cfbde3611b14c0d4831a5524e5e061128e30 > Another thought: it could be that the ROM code on Beagle is not > programming the correct SDRC register values after resume. You might try > booting with mem=128M and dumping the SDRC register values before suspend > and after resume. Those are OK. I am looking at a fix for the SDRC setup with 2 CSes. I will propose the changes asap. > > - Paul Thx & regards, Jean -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Jean, On Mon, 11 May 2009, Jean Pihet wrote: > On Saturday 09 May 2009 00:43:43 Paul Walmsley wrote: > > One possibility: perhaps the problem is with Beagle's pin mux settings. > > You might want to boot with mem=128M and make sure > > CONTROL_PADCONF_SAD2D_SBUSFLAG and CONTROL_PADCONF_SDRC_CKE1 are in mode 0 > > before suspend and after resume. > Yes that definitely is the root cause. I should have checked this first ;-( > The U-Boot change is committed, cf. > http://gitorious.org/u-boot-omap3/mainline/commit/c6f01ad390308800693c62dbdb096ab59e03630b > and > http://gitorious.org/u-boot-omap3/mainline/commit/4025cfbde3611b14c0d4831a5524e5e061128e30 Nice work! Sounds like we should also patch mach-omap2/sdrc.c:omap2_sdrc_init() to warn if the sdrc_cke1 pin mux is wrong if a second struct omap_sdrc_params * is passed. Probably board-omap3beagle.c should also remux the pad if it's wrong. Otherwise there will be a lot of unhappy Rev C BeagleBoard users. > I am looking at a fix for the SDRC setup with 2 CSes. I will propose the > changes asap. Excellent, thanks Jean. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index 487fa86..6d5843a 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -175,15 +175,24 @@ wait_dll_unlock: bne wait_dll_unlock bx lr configure_sdrc: - ldr r11, omap3_sdrc_rfr_ctrl + ldr r11, omap3_sdrc_rfr_ctrl_0 str r0, [r11] - ldr r11, omap3_sdrc_actim_ctrla + ldr r11, omap3_sdrc_rfr_ctrl_1 + str r0, [r11] + ldr r11, omap3_sdrc_actim_ctrla_0 + str r1, [r11] + ldr r11, omap3_sdrc_actim_ctrla_1 str r1, [r11] - ldr r11, omap3_sdrc_actim_ctrlb + ldr r11, omap3_sdrc_actim_ctrlb_0 + str r2, [r11] + ldr r11, omap3_sdrc_actim_ctrlb_1 str r2, [r11] ldr r11, omap3_sdrc_mr_0 str r6, [r11] ldr r6, [r11] @ posted-write barrier for SDRC + ldr r11, omap3_sdrc_mr_1 + str r6, [r11] + ldr r6, [r11] @ posted-write barrier for SDRC bx lr omap3_sdrc_power: @@ -194,14 +203,22 @@ omap3_cm_idlest1_core: .word OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST) omap3_cm_iclken1_core: .word OMAP34XX_CM_REGADDR(CORE_MOD, CM_ICLKEN1) -omap3_sdrc_rfr_ctrl: +omap3_sdrc_rfr_ctrl_0: .word OMAP34XX_SDRC_REGADDR(SDRC_RFR_CTRL_0) -omap3_sdrc_actim_ctrla: +omap3_sdrc_rfr_ctrl_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_RFR_CTRL_1) +omap3_sdrc_actim_ctrla_0: .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_A_0) -omap3_sdrc_actim_ctrlb: +omap3_sdrc_actim_ctrla_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_A_1) +omap3_sdrc_actim_ctrlb_0: .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_B_0) +omap3_sdrc_actim_ctrlb_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_B_1) omap3_sdrc_mr_0: .word OMAP34XX_SDRC_REGADDR(SDRC_MR_0) +omap3_sdrc_mr_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_MR_1) omap3_sdrc_dlla_status: .word OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS) omap3_sdrc_dlla_ctrl: