[U-Boot] Marvell DDR training custom ODT configuration
Hi Chris,
Currently the value of g_odt_config is hard coded in Marvell SoC platform headers. Some SolidRun A388 SOMs need a custom value. These SOMs use both DDR chip-selects, but ODT0 alone is connected to both chips. For that to work we need to set g_odt_config to 0x30000, that is, ODT0 is configured for both CS0 and CS1.
How can we do that in a clean way so as to not interfere too much with your periodic code syncs from Marvell's DDR training source tree?
Thanks, baruch
-- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
On Thu, 28 Feb 2019 22:45 Baruch Siach, baruch@tkos.co.il wrote:
Hi Chris,
Currently the value of g_odt_config is hard coded in Marvell SoC platform headers. Some SolidRun A388 SOMs need a custom value. These SOMs use both DDR chip-selects, but ODT0 alone is connected to both chips. For that to work we need to set g_odt_config to 0x30000, that is, ODT0 is configured for both CS0 and CS1.
How can we do that in a clean way so as to not interfere too much with your periodic code syncs from Marvell's DDR training source tree?
I've actually got a patch from marvell that might help. I'll send it to the list when I'm at a proper keyboard.
On Thu, Feb 28, 2019 at 10:45 PM Baruch Siach baruch@tkos.co.il wrote:
Hi Chris,
Currently the value of g_odt_config is hard coded in Marvell SoC platform headers. Some SolidRun A388 SOMs need a custom value. These SOMs use both DDR chip-selects, but ODT0 alone is connected to both chips. For that to work we need to set g_odt_config to 0x30000, that is, ODT0 is configured for both CS0 and CS1.
How can we do that in a clean way so as to not interfere too much with your periodic code syncs from Marvell's DDR training source tree?
In terms of syncing the best approach is upstream first (https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell) then it's a non-issue. I've had some success on that front but that may only be because $dayjob has a commercial relationship with the SoC vendor and I can access their support channels. Even with that I've got two outstanding PRs on github that don't seem to be going anywhere (I have had some feedback through the support channel that the tRAS changes will be incorporated, no information as to when).
Ideally instead of you or I having to maintain this code it would be great if someone from Marvell was involved (I see a similar comment on the recent ThunderX series).
That all said, the only delta we have right now is the configurable 2T timing (Marvell's code forces 2T timing on for all boards). I've been tempted to mark that with #ifdef __U_BOOT__ to make it more obvious. We probably should do the same for any other changes we do end up making.
Hi Chris,
On Thu, Feb 28 2019, Chris Packham wrote:
On Thu, Feb 28, 2019 at 10:45 PM Baruch Siach baruch@tkos.co.il wrote:
Currently the value of g_odt_config is hard coded in Marvell SoC platform headers. Some SolidRun A388 SOMs need a custom value. These SOMs use both DDR chip-selects, but ODT0 alone is connected to both chips. For that to work we need to set g_odt_config to 0x30000, that is, ODT0 is configured for both CS0 and CS1.
How can we do that in a clean way so as to not interfere too much with your periodic code syncs from Marvell's DDR training source tree?
In terms of syncing the best approach is upstream first (https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell) then it's a non-issue. I've had some success on that front but that may only be because $dayjob has a commercial relationship with the SoC vendor and I can access their support channels. Even with that I've got two outstanding PRs on github that don't seem to be going anywhere (I have had some feedback through the support channel that the tRAS changes will be incorporated, no information as to when).
Ideally instead of you or I having to maintain this code it would be great if someone from Marvell was involved (I see a similar comment on the recent ThunderX series).
That all said, the only delta we have right now is the configurable 2T timing (Marvell's code forces 2T timing on for all boards). I've been tempted to mark that with #ifdef __U_BOOT__ to make it more obvious. We probably should do the same for any other changes we do end up making.
OK. I'll try to contact SolidRun's contacts at Marvell. Let's see how far that goes.
Thanks, baruch
participants (2)
-
Baruch Siach -
Chris Packham