public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: u-boot@lists.denx.de
Subject: [PATCH v2] arm: mvebu: Espressobin: Set environment variable fdtfile
Date: Tue, 6 Oct 2020 13:02:12 +0200	[thread overview]
Message-ID: <20201006110212.ezulkroopckio4up@pali> (raw)
In-Reply-To: <267f1dff-f64f-d42f-9cef-24dfe8c32371@gmail.com>

On Monday 05 October 2020 18:20:17 Andre Heider wrote:
> On 03/10/2020 10:50, Pali Roh?r wrote:
> > On Saturday 03 October 2020 09:17:35 Andre Heider wrote:
> > > On 02/10/2020 12:49, Pali Roh?r wrote:
> > > > On Saturday 26 September 2020 11:09:59 Andre Heider wrote:
> > > > > On 25/09/2020 09:46, Pali Roh?r wrote:
> > > > > > On Friday 11 September 2020 06:35:10 Andre Heider wrote:
> > > > > ...
> > > > > > > +#ifdef CONFIG_BOARD_LATE_INIT
> > > > > > > +int board_late_init(void)
> > > > > > > +{
> > > > > > > +	bool ddr4, emmc;
> > > > > > > +
> > > > > > > +	if (env_get("fdtfile"))
> > > > > > > +		return 0;
> > > > > > > +
> > > > > > > +	if (!of_machine_is_compatible("globalscale,espressobin"))
> > > > > > > +		return 0;
> > > > > > > +
> > > > > > > +	/* If the memory controller has been configured for DDR4, we're running on v7 */
> > > > > > > +	ddr4 = ((readl(A3700_CH0_MC_CTRL2_REG) >> A3700_MC_CTRL2_SDRAM_TYPE_OFFS)
> > > > > > > +		& A3700_MC_CTRL2_SDRAM_TYPE_MASK) == A3700_MC_CTRL2_SDRAM_TYPE_DDR4;
> > > > > > > +
> > > > > > > +	emmc = of_machine_is_compatible("globalscale,espressobin-emmc");
> > > > > > 
> > > > > > Maybe stupid question, but are not we able to detect if eMMC is
> > > > > > connected or not at runtime? That could simplify setup and avoid usage
> > > > > > of additional special DTS file for eMMC in U-Boot.
> > > > > 
> > > > > At some point I wondered about the same.
> > > > > 
> > > > > IIRC armbian just enables it and uses one u-boot binary everywhere. A
> > > > > non-existing chip won't get detected, so that shouldn't be a problem.
> > > > > 
> > > > > But I think it has more to do with enabling/powering up hardware blocks,
> > > > > which is not wanted or may even problematic.
> > > > 
> > > > In U-Boot such functionality may be implemented in board_fix_fdt()
> > > > function which allows U-Boot to modify its Device tree prior using it.
> > > > 
> > > > You have already wrote code which is doing V5 vs V7 detection, so
> > > > detecting eMMC is the last thing which is missing to have just one
> > > > U-Boot DTS file and therefore only one U-Boot binary for Espressobin.
> > > 
> > > That implies setting status=okay for the emmc node, which then powers up
> > > that block. I don't know if that might be problematic. Can we just do that?
> > 
> > No. I mean to detect presence of eMMC in board_fix_fdt() and then set
> > tatus=okay only if check passed.
> 
> Yes, but how do you detect the emmc then? Enabling it in u-boot's dts and
> calling mmc_init() on it would be the easy way, but open coding all the
> required parts to do that with status=disabled could get rather big and/or
> unmaintanable (I didn't check what exactly would be required)?

Hm... seems that it would be really easier to enable eMMC in U-Boot DTS,
let U-Boot to try initialize eMMC and in case it fails, then disable
eMMC drivers &?devices and disable it also in FTB blob.

For powering up eMMC there is function comphy_emmc_power_up(), so it
would be needed to write power_down equivalent. And for xenon_sdhci.c
would be needed to write .remove callback (for disabling eMMC).

> > 
> > > The emmc detection would also add some delay to the boot process.
> > > 
> > > At least it should be powered down if no emmc chip has been detected, but I
> > > didn't check if that happens right now.
> > > 
> > > Regards,
> > > Andre
> 

      reply	other threads:[~2020-10-06 11:02 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-05 12:07 [PATCH] arm: mvebu: Espressobin: Set environment variable fdtfile Andre Heider
2020-09-06  9:32 ` Pali Rohár
2020-09-06 16:12   ` Marek Behun
2020-09-06 18:48     ` Andre Heider
2020-09-06 18:56       ` Marek Behun
2020-09-07  5:20         ` Andre Heider
2020-09-06 18:44   ` Andre Heider
2020-09-07  7:58     ` Pali Rohár
2020-09-07  8:46       ` Andre Heider
2020-09-07  8:52         ` Pali Rohár
2020-09-07 16:51           ` Andre Heider
2020-09-11  4:35 ` [PATCH v2] " Andre Heider
2020-09-11 13:02   ` Gérald Kerma
2020-09-24 10:38   ` Stefan Roese
2020-09-25  7:46   ` Pali Rohár
2020-09-26  9:09     ` Andre Heider
2020-10-02 10:49       ` Pali Rohár
2020-10-03  7:17         ` Andre Heider
2020-10-03  8:50           ` Pali Rohár
2020-10-05 16:20             ` Andre Heider
2020-10-06 11:02               ` Pali Rohár [this message]

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=20201006110212.ezulkroopckio4up@pali \
    --to=pali@kernel.org \
    --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