linux-kernel - Re: beaglebone black boot failure Linux v5.15.rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 21 Sep 2021 11:07:10 -0500
From:   Suman Anna <s-anna@...com>
To:     Tony Lindgren <tony@...mide.com>,
        Matti Vaittinen <mazziesaccount@...il.com>
CC:     Grygorii Strashko <grygorii.strashko@...com>,
        "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>,
        "linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
        Paul Barker <paul.barker@...cloud.com>,
        Peter Ujfalusi <peter.ujfalusi@...il.com>,
        Benoît Cousson <bcousson@...libre.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: beaglebone black boot failure Linux v5.15.rc1

Hi Matti, Tony,

On 9/21/21 2:47 AM, Tony Lindgren wrote:
> * Matti Vaittinen <mazziesaccount@...il.com> [210920 08:23]:
>> Finally, adding the udelay(100); (as Tony suggested) at the end of the
>> omap_reset_deassert() did make the oops go away even when pruss_tm was
>> enabled. I don't know what would be a proper fix though.

I have been able to boot v5.15-rc1 just fine on my BBB without any additional
changes [1].

May I ask what is your BBB board version? My board is rev.A5C.

I vaguely remember from all those years ago when I first enabled PRUSS on AM335x
that some earlier BBB versions had some issues around PRUSS.

regards
Suman

[1] https://marc.info/?l=linux-omap&m=163223991005545&w=2

> 
> The following patch works for me on bbb with the following test script:
> 
> #!/bin/sh
> 
> module="4a326000.target-module"
> driver="/sys/bus/platform/drivers/ti-sysc"
> 
> while true; do
> 	echo ${module} > ${driver}/bind
> 	echo ${module} > ${driver}/unbind
> done
> 
> It also allows leaving out the udelay for dra7 iva reset. Care to try
> this and see if it helps?
> 
> Regards,
> 
> Tony
> 
> 8< -----------------
> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
> --- a/drivers/soc/ti/omap_prm.c
> +++ b/drivers/soc/ti/omap_prm.c
> @@ -825,26 +825,29 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
>  	writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
>  	spin_unlock_irqrestore(&reset->lock, flags);
>  
> -	if (!has_rstst)
> -		goto exit;
> -
> -	/* wait for the status to be set */
> -	ret = readl_relaxed_poll_timeout_atomic(reset->prm->base +
> +	if (has_rstst) {
> +		/* wait for the status to be set */
> +		ret = readl_relaxed_poll_timeout_atomic(reset->prm->base +
>  						 reset->prm->data->rstst,
>  						 v, v & BIT(st_bit), 1,
>  						 OMAP_RESET_MAX_WAIT);
> -	if (ret)
> -		pr_err("%s: timedout waiting for %s:%lu\n", __func__,
> -		       reset->prm->data->name, id);
> -
> -exit:
> -	if (reset->clkdm) {
> -		/* At least dra7 iva needs a delay before clkdm idle */
> -		if (has_rstst)
> -			udelay(1);
> -		pdata->clkdm_allow_idle(reset->clkdm);
> +		if (ret)
> +			pr_err("%s: timedout waiting for %s:%lu\n", __func__,
> +			       reset->prm->data->name, id);
> +	} else {
> +		/* wait for the reset bit to cleaar */
> +		ret = readl_relaxed_poll_timeout_atomic(reset->prm->base +
> +						reset->prm->data->rstctrl,
> +						v, !(v & BIT(id)), 1,
> +						OMAP_RESET_MAX_WAIT);
> +		if (ret)
> +			pr_err("%s: timedout waiting for %s:%lu\n", __func__,
> +			       reset->prm->data->name, id);
>  	}
>  
> +	if (reset->clkdm)
> +		pdata->clkdm_allow_idle(reset->clkdm);
> +
>  	return ret;
>  }
>  
>