Yes. But when I re-added it, no one reported any success / differences, so it stayed out.
Sam
If you re-added it in August / September, then I’ve probably tested it.
My recent reinstall was the first time I’ve been able to run a kernel newer than 3.14 on my Vero.
It was added in a specific testing kernel made available in this post.
I’m actually not sure if I tested that one. Was quite busy at the time, and didn’t have much time for testing.
I don’t want to crash my Vero again by testing it now (if it’s not solving the problem), but maybe @arubislander want to give it a try? Since he got the same problem.
I am actually quite sure I tried that one without success…
Just dusted down the Vero after it refused to update from 2015. Disappointed to find that despite loading up the latest release the same Dependency failed for local file system error occurred. Oh well, a Rasp Pi 3 is cheap enough, and certainly cheaper than the Vero was!
First try to pull the power a couple of times, and see if it passes that critical point.
If not, try doing a clean install of the june 2015 image and update from inside OSMC. This works for me when my Vero starts to hang on dependency failed after a restart every couple of months.
I’m still running OSMC on a “broken” Vero 1, and most of the time it’s running without any problems.
We haven’t heard of this problem for a few months, so assumed all was resolved.
If you are still having problems, I would recommend reseating the card and checking your power supply. I can start producing some newer builds again to test things. I did receive a problematic unit back, and we managed to replicate the problem on 4.x, but we did resolve it.
Sam
If you resolved it, what caused the problems?
I can probably do some testing if you make some builds.
Hi
This SDHC tuning issue resolved the matter for the customer that returned their device:
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index 5478fc1..7b024087 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -136,6 +136,7 @@
#define ESDHC_FLAG_HS200 BIT(8)
/* The IP supports HS400 mode */
#define ESDHC_FLAG_HS400 BIT(9)
+#define ESDHC_FLAG_TUNING_WORK_AROUND BIT(10)
/* A higher clock ferquency than this rate requires strobell dll control */
#define ESDHC_STROBE_DLL_CLK_FREQ 100000000
@@ -161,7 +162,8 @@ static struct esdhc_soc_data esdhc_imx53_data = {
};
static struct esdhc_soc_data usdhc_imx6q_data = {
- .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING,
+ .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING
+ | ESDHC_FLAG_TUNING_WORK_AROUND,
};
static struct esdhc_soc_data usdhc_imx6sl_data = {
@@ -1017,6 +1019,9 @@ sdhci_esdhc_imx_probe_dt(struct platform_device *pdev,
if (!IS_ERR_VALUE(mmc_gpio_get_cd(host->mmc)))
host->quirks &= ~SDHCI_QUIRK_BROKEN_CARD_DETECTION;
+ if (imx_data->socdata->flags & ESDHC_FLAG_TUNING_WORK_AROUND)
+ host->quirks2 |= SDHCI_QUIRK2_TUNING_WORK_AROUND;
+
return 0;
}
#else
We had positive reports from users affected by this.
This was an omission around a quirk when we moved from 3.14 to 4.4. Quirks are ways of addressing errata, or slightly out of spec behaviour and they are common in the kernel.
This commit is included in the latest Vero 1 kernel, so I am quite intrigued, and confused, that you are still experiencing problems.
When you and @arubislander had positive reports (i.e. it works now), I thought that the issue could be, on the whole, considered resolved.
Sam
I haven’t tried a fresh install of the latest image.
I’ll do some testing this weekend.
I finally got some time to test the latest image.
Did a clean install of latest image, and it started on first try. Did some reboots, looking for dependency failed, but it started properly every time.
I then tried a new clean install, to see if I just got really lucky on the previous installation. Did some reboots again, but couldn’t get the dependency failed error.
This is the first time in a year that I can do a clean install of the newest build, without any errors.
To me it looks like the problem is finally solved.
Thanks Sam!
Thanks, that’s great to hear.
We resolved the problem very quickly when we finally got an affected unit back. I entirely understand the frustration of users here. Unfortunately until a few weeks ago, we never received an affected unit back, so we could never diagnose the problem. As soon as we got one, we got things sorted.
Cheers,
Sam
After a couple of tries, my revision 1 Vero also booted to the newest build (2016.06-2 at the time of this writing)
But the fact that it took a couple of tries gives me reason for pause… I will keep a close eye on things and report back with my findings.