All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Kumar Gala <galak@kernel.crashing.org>, linuxppc-dev@lists.ozlabs.org
Cc: Bryan Hundven <Bryan.Hundven@watchguard.com>
Subject: Re: powerpc/85xx: p2020rdb - move the NAND address.
Date: Thu, 29 Mar 2012 09:26:16 +0200	[thread overview]
Message-ID: <4F740E98.50104@linutronix.de> (raw)
In-Reply-To: <E9CCADB024EDCD44A9C1083605680C42B9053302@ES05CO.wgti.net>

On 03/28/2012 10:30 PM, Bryan Hundven wrote:
>  > It is not at 0xffa00000. According to current u-boot source the NAND
>  > controller is always at 0xff800000 and it is either at CS0 or CS1
>  > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to
>  > 0xfff800000 but it has always an eight there and never an A.
>  >
>  > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>  > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> I am having a hard time verifying this change. I don't think you are
> wrong, I'm just having a hard time following.
>
> I do not see where this has always been 0xff800000 in u-boot.

<cut>

> But while I was checking changes in arch/powerpc/, I found this change
> and wanted to understand why 0xffa00000 has worked for us for so long?

Kumar, I wasn't wrong entirely I just missed one detail. U-Boot
provides two different configs, not just one define like its for
SPL/SPI/...:

- include/configs/P1_P2_RDB.h

  #ifndef CONFIG_NAND_SPL
  #define CONFIG_SYS_NAND_BASE            0xffa00000
  #ifdef CONFIG_PHYS_64BIT
  #define CONFIG_SYS_NAND_BASE_PHYS       0xfffa00000ull
  #else
  #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
  #endif
  #else
  #define CONFIG_SYS_NAND_BASE            0xfff00000
  #ifdef CONFIG_PHYS_64BIT
  #define CONFIG_SYS_NAND_BASE_PHYS       0xffff00000ull
  #else
  #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
  #endif
  #endif

- include/configs/p1_p2_rdb_pc.h

  #ifdef CONFIG_NAND_FSL_ELBC
  #define CONFIG_SYS_NAND_BASE            0xff800000
  #ifdef CONFIG_PHYS_64BIT
  #define CONFIG_SYS_NAND_BASE_PHYS       0xfff800000ull
  #else
  #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
  #endif

and for kernel they use both the same device tree. So with the change,
the _pc variant finds its flash. Before that it worked for the non-pc
variant only if NAND_SPL wasn't used.
Any suggestion on fixing that? Providing a new dt for _pc would "fix"
it but the non pc variant won't find it in the case of NAND_SPL.

Since both system have the same SoC and the NAND_SPL is always linked
against 0xfff00000 I don't see anything wrong to relocate the NAND CS
later to 0xff800000 (or to 0xffa00000) and having it consistent among
both configs.

> -Bryan

Sebastian

       reply	other threads:[~2012-03-29  7:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E9CCADB024EDCD44A9C1083605680C42B9053302@ES05CO.wgti.net>
2012-03-29  7:26 ` Sebastian Andrzej Siewior [this message]
2012-03-29 13:10   ` powerpc/85xx: p2020rdb - move the NAND address Kumar Gala
2012-03-29 18:28     ` Bryan Hundven
2012-03-29 23:17       ` Bryan Hundven
2012-03-30 14:04     ` Sebastian Andrzej Siewior
2012-03-31 14:48       ` Kumar Gala
2012-05-09 19:53         ` Sebastian Andrzej Siewior
2012-06-29 20:01           ` Kumar Gala

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=4F740E98.50104@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=Bryan.Hundven@watchguard.com \
    --cc=galak@kernel.crashing.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.