From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pali =?utf-8?B?Um9ow6Fy?= Date: Fri, 14 Aug 2020 22:16:00 +0200 Subject: [PATCH] Revert "mmc: disable UHS modes if Vcc cannot be switched on and off" In-Reply-To: <20200811162723.ixnydta32h4edkh2@pali> References: <20200809160303.8773-1-pali@kernel.org> <20200811074913.qyzcaumgbypcus44@pali> <20200811162723.ixnydta32h4edkh2@pali> Message-ID: <20200814201600.gofpby3gmtuivjue@pali> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tuesday 11 August 2020 18:27:23 Pali Roh?r wrote: > On Tuesday 11 August 2020 21:33:19 Faiz Abbas wrote: > > Pali, > > > > On 11/08/20 1:19 pm, Pali Roh?r wrote: > > > On Tuesday 11 August 2020 08:39:24 Faiz Abbas wrote: > > >> Pali, Peng, > > >> > > >> On 10/08/20 6:25 am, Peng Fan wrote: > > >>> Faiz, Jean > > >>> > > >>>> Subject: [PATCH] Revert "mmc: disable UHS modes if Vcc cannot be switched > > >>>> on and off" > > >>> > > >>> Got time to take a look? > > >>> > > >> > > >> When this issue was reported in the last thread, Pali said that he was unable to get > > >> prints because of the constant reboot loops? Shouldn't it be easy to put while(1) > > >> at different points in this execution and see which step causes the reboot loop? > > > > > > In May in that last thread I wrote details which I was able to gather: > > > > > > Month ago I was able to detect that problem is somewhere in function > > > mmc_set_ios() from mmc.c file. I put long debug line prior and also > > > after mmc_set_ios() call. And it was printed only prior. Not after. > > > So I think NULL pointer dereference is in mmc_set_ios() function. > > > > > > I could try with that while(1) loop to print detailed log message and > > > read/capture it. But what information for debugging you need? Or what do > > > you want to print which could help you? > > > > > > > You can continue to bisect into omap_hsmmc_set_ios() to see at what point the NULL pointer > > gets triggered and what the NULL pointer is. > > I could try it, but I do not think I would be able to gather more data. > I will try to find free time for this debugging on device either at the > end of this week or end of next week. Here are more details. Crash is in omap_hsmmc_stop_clock() function when trying to dereference mmc_base->sysctl. Call trace is: mmc_set_ios --> mmc->cfg->ops->set_ios --> omap_hsmmc_set_ios --> omap_hsmmc_stop_clock I applied following diff diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c index 715eee0e3e..d4bbfd7b97 100644 --- a/drivers/mmc/omap_hsmmc.c +++ b/drivers/mmc/omap_hsmmc.c @@ -22,6 +22,8 @@ * MA 02111-1307 USA */ +#define DEBUG + #include #include #include @@ -1335,7 +1337,16 @@ static int mmc_write_data(struct hsmmc *mmc_base, const char *buf, #endif static void omap_hsmmc_stop_clock(struct hsmmc *mmc_base) { + debug("omap_hsmmc_stop_clock: before writel\n"); + debug("mmc_base=%p\n", mmc_base); + debug("barrier\n"); + asm volatile (""); + debug("mmc_base->sysctl=%x\n", mmc_base->sysctl); + debug("barrier\n"); + asm volatile (""); + debug("readl(&mmc_base->sysctl)=%x\n", readl(&mmc_base->sysctl)); writel(readl(&mmc_base->sysctl) & ~CEN_ENABLE, &mmc_base->sysctl); + debug("omap_hsmmc_stop_clock: after writel\n"); } static void omap_hsmmc_start_clock(struct hsmmc *mmc_base) and I see that first word "barrier" is written. There is no "mmc_base->sysctl=" string on output display. If you are interested, mmc_base has value 480b4000. That is probably all what I can do. > As I wrote in previous thread, main issue which makes it hard to debug > is that this error is not triggered in emulator. > > > Also can you point to your config file? > > I'm using standard config file without any modifications. It is: > configs/nokia_rx51_defconfig > > In case you are interested, I'm compiling u-boot by commands: > > export ARCH=arm > export CROSS_COMPILE=arm-linux-gnueabi- > make nokia_rx51_config > make -j12 u-boot.bin