[U-Boot] Marvell DDR training custom ODT configuration

[U-Boot] Marvell DDR training custom ODT configuration

[Baruch Siach]

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 at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[U-Boot] Marvell DDR training custom ODT configuration

[Chris Packham]

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.

>

[U-Boot] Marvell DDR training custom ODT configuration

[Chris Packham]

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.

[U-Boot] Marvell DDR training custom ODT configuration

[Baruch Siach]

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

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -