public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Baruch Siach <baruch@tkos.co.il>
To: u-boot@lists.denx.de
Subject: [PATCH 06/10] arm: mvebu: clearfog: Add config for 2GB SOM
Date: Sun, 12 Jan 2020 18:44:59 +0200	[thread overview]
Message-ID: <87a76szks4.fsf@tarshish> (raw)
In-Reply-To: <1b8510605dbe9f1d65298a0f8e6be168@lixil.net>

Hi Joel,

On Sun, Jan 12 2020, Joel Johnson wrote:
> On 2020-01-12 03:33, Baruch Siach wrote:
>> On Sat, Jan 11 2020, Joel Johnson wrote:
>>> While 1GB SOM parts are much more common, provide a build config
>>> option for supporting parts with 2GB.
>>>
>>> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
>>> ---
>>>
>>>  board/solidrun/clearfog/Kconfig    | 6 ++++++
>>>  board/solidrun/clearfog/clearfog.c | 8 ++++++++
>>>  2 files changed, 14 insertions(+)
>>>
>>> diff --git a/board/solidrun/clearfog/Kconfig
>>> b/board/solidrun/clearfog/Kconfig
>>> index 53f01daf7a..fd880ee591 100644
>>> --- a/board/solidrun/clearfog/Kconfig
>>> +++ b/board/solidrun/clearfog/Kconfig
>>> @@ -31,4 +31,10 @@ config CLEARFOG_SFP_25GB
>>>  	 SGMII connection (requires a supporting SFP). By default, transfer
>>> speed
>>>  	 of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP module.
>>>
>>> +config CLEARFOG_2GB_SOM
>>> +	bool "Configure for a SOM with 2GB RAM"
>>> +	help
>>> +	 Enable support for the 2GB RAM SOM variant. If this option is not
>>> +	 enabled then the more common 1GB version will be used.
>>> +
>>>  endmenu
>>> diff --git a/board/solidrun/clearfog/clearfog.c
>>> b/board/solidrun/clearfog/clearfog.c
>>> index 247785ac56..38f411b942 100644
>>> --- a/board/solidrun/clearfog/clearfog.c
>>> +++ b/board/solidrun/clearfog/clearfog.c
>>> @@ -67,11 +67,19 @@ static struct mv_ddr_topology_map board_topology_map =
>>> {
>>>  	DEBUG_LEVEL_ERROR,
>>>  	0x1, /* active interfaces */
>>>  	/* cs_mask, mirror, dqs_swap, ck_swap X PUPs */
>>> +#if defined (CONFIG_CLEARFOG_2GB_SOM)
>>> +	{ { { {0x3, 0, 0, 0},
>>> +	      {0x3, 0, 0, 0},
>>> +	      {0x3, 0, 0, 0},
>>> +	      {0x3, 0, 0, 0},
>>> +	      {0x3, 0, 0, 0} },
>>
>> That can only work for 2GB SOMs with twin-die RAM configuration. SOMs
>> with single-die RAM need MV_DDR_DIE_CAP_8GBIT in the mem_size field
>> instead. See board/kobol/helios4/helios4.c. See also
>>
>>   https://patchwork.ozlabs.org/patch/1200332/
>
> That seems to only target the newer EEPROM TLV units which I don't believe I
> have (still pending final checking). As with the other patch, an option for
> manual predefinition at build time will still be needed as an alternate path.

In linking to this patch I only meant to demonstrate
MV_DDR_DIE_CAP_8GBIT.

A388 SOMs of rev 2.0 have no EEPROM.

>> You should also adjust the ODT configuration to assert M_ODT[0] of both
>> chip-selects, since only M_ODT[0] is connected on the A388 SOM. See the
>> comment I added to the cherry-picked commit log in
>>
>>
>> https://github.com/SolidRun/u-boot/commit/ab15b2d5b6ee50c106628dc0aa5943747a5dd772
>>
>> Wrong ODT configuration might cause memory corruption in high RAM
>> traffic load.
>>
>> I have a patch adding support for per-board ODT configuration. I have
>> not posted it yet to the list.
>
> Sounds promising, any planned timeframe for readiness and posting of that
> patch?

I plan to post patches adding support for twin-die SOMs once the
previous series is merged.

> I may just remove this patch from this series pending the per-board ODT
> config ability.

You need this patch (or equivalent) for twin-die SOMs regardless of
per-board ODT.

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 -

  reply	other threads:[~2020-01-12 16:44 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-11 19:36 [PATCH 01/10] arm: mvebu: fix SerDes table alignment Joel Johnson
2020-01-11 19:36 ` [PATCH 02/10] arm: mvebu: solidrun: remove hardcoded DTS MAC address Joel Johnson
2020-01-13  8:21   ` Stefan Roese
2020-01-11 19:36 ` [PATCH 03/10] arm: mvebu: clearfog: initial ClearFog Base variant Joel Johnson
2020-01-12 10:14   ` Baruch Siach
2020-01-12 15:16     ` Joel Johnson
2020-01-13  8:19       ` Stefan Roese
2020-01-11 19:36 ` [PATCH 04/10] arm: mvebu: clearfog: Add SATA mode flags Joel Johnson
2020-01-11 19:36 ` [PATCH 05/10] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP Joel Johnson
2020-01-12 10:21   ` Baruch Siach
2020-01-12 15:07     ` Joel Johnson
2020-01-11 19:36 ` [PATCH 06/10] arm: mvebu: clearfog: Add config for 2GB SOM Joel Johnson
2020-01-12 10:33   ` Baruch Siach
2020-01-12 15:48     ` Joel Johnson
2020-01-12 16:44       ` Baruch Siach [this message]
2020-01-11 19:36 ` [PATCH 07/10] arm: mvebu: clearfog: add SPI offsets Joel Johnson
2020-01-12 10:42   ` Baruch Siach
2020-01-12 15:30     ` Joel Johnson
2020-01-12 16:28       ` Baruch Siach
2020-01-11 19:36 ` [PATCH 08/10] arm: mvebu: enable working default boot support Joel Johnson
2020-01-11 21:07   ` Joel Johnson
2020-01-13  8:26     ` Stefan Roese
2020-01-11 19:36 ` [PATCH 09/10] arm: mvebu: clearfog: move ENV params to Kconfig Joel Johnson
2020-01-13  8:29   ` Stefan Roese
2020-01-11 19:36 ` [PATCH 10/10] arm: mvebu: clearfog: don't assume MMC booting Joel Johnson
2020-01-12 10:49   ` Baruch Siach
2020-01-12 15:40     ` Joel Johnson
2020-01-12 16:34       ` Baruch Siach
2020-01-13  6:48         ` Stefan Roese
2020-01-13 11:40           ` Baruch Siach
2020-01-13 11:42             ` Stefan Roese
2020-01-14 12:55           ` Baruch Siach
2020-01-14 13:01             ` Stefan Roese
2020-01-14 14:53               ` Baruch Siach
2020-01-14 15:06                 ` Stefan Roese
2020-01-15  7:04                   ` Baruch Siach
2020-01-13  8:18 ` [PATCH 01/10] arm: mvebu: fix SerDes table alignment Stefan Roese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a76szks4.fsf@tarshish \
    --to=baruch@tkos.co.il \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox