[Solved ]Odroid C2 - eMMC 5.1 Module can't boot ?

[pigiron]

@lcard - That's good to hear. Also your previous post provided some valuable information. So much thanks for the info/update.

For full disclosure, I found that my eMMC chip is probably the same as Sagittarius'. When I peeled off the red sticker, I found that it was actually a 5.1 HS400 and was not the chip advertised on Ameridroid (i.e. I'm guessing they simply stuck a red sticker on their "black" chip). So when you couple that with your info that some eMMC chips work and others don't, my total guess is that it's these newer/faster chips that have the problem.

Now... perhaps the bigger issue is that the BayLibre folks that are doing most of the Amlogic heavy lifting for the mainline kernel seem to have very few eMMC chips, and I'm guessing none of these faster ones.

After I reported this issue upstream, they had me try their latest (unshipped) kernel, but it still failed. After reporting this result to them, there's been nothing but radio silence.

Their lack of eMMC chips is a shame because they've created a wonderful test environment that would probably catch this type of problem early:

https://baylibre.com/intro-kernelci/
https://www.youtube.com/watch?v=kSe5GMJvqOI

Reviewing these ODroid C2 test results at https://kernelci.org/stats/, I've not found any tests that are using an eMMC chip, but I didn't check them all.

But I've been intermittently following BayLibre's kernel changes and there are a ton of them (these few folks are very busy):

https://git.kernel.org/pub/scm/linux/ke ... mlogic.git

There are many code changes near our problem area (pin bias) scheduled for the 5.3 release. But I (and probably they,) don't know if it's going to fix this issue for those of us with these chips.

Here's their mailing list if you want to follow along:

http://lists.infradead.org/mailman/list ... ux-amlogic

Possibly the best, in the near and long term, would be for some kind soul to donate eMMC chip(s) to these BayLibre folks. I currently don't have the funds or I would.

Also, I think it's highly admirable to tackle a kernel compile, but I've been bypassing that by simply using the "dtc" utility to disassemble the /boot/dtbs/amlogic/meson-gxbb-odroidc2.dtb file, then editing the result, and recompiling. But it's a personal choice, and there are multiple options.

[pigiron]

OK, lcard's update caused me to play around some more and I may have found some good news for a change.

As an experiment, I decided to try a meson-gxbb-odroidc2.dtb file from version 5.3 on my existing version 5.1 mainline kernel... just to see what would happen. Besides, I didn't have much to lose after now knowing that an upgrade to 5.2 was going to be painful (again).

A quick and easy/dirty/ugly way to do that was to grab one from that wonderful "kernelci" project.

I started by looking at the reports from their ODroid C2 boards here:

https://kernelci.org/boot/meson-gxbb-odroidc2/

The first task was to find C2 boards that were "online"... they have a green check mark in the "Status" column. So I sorted on that column.

Then looked down the "Tree" column for the "next" entries, hoping that will be the stuff coming in version 5.3.

Then looked at the entries named "master" from the "Branch" column.

Narrowed it down some more by looking at those named "next-20190712" in the "Kernel" column, because that seemed promising.

Finally, I now decided that the one using the "defconfig" in the "Defconfig" column sounded pretty good, so I clicked on it's magnifying glass symbol in the rightmost column.

That brought up a web page that had a link to download the dtbs/amlogic/meson-gxbb-odroidc2.dtb file.

Disassembled that file, and yep, there were a bunch of the future device tree changes I'd previously seen in BayLibre's git tree. Including the pin bias stuff for the eMMC.

Renamed my old meson-gxbb-odroidc2.dtb file as a backup, put this new file in it's place, rebooted, and held my breath.

It booted just fine. Logged in at the prompt and ran "dmesg". I don't see anything bad in there, but little time has passed. And I haven't yet tried it on the 5.2 kernel. So we'll see.

Obviously, this method is fraught with danger, and won't be good in the future... maybe not even tomorrow. But it seems promising that this problem may finally be fixed near the 5.3 time frame.

[lcard]

@pigiron

I had though we could patch arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts to update the EMMC pin-bias settings to whatever their mode was before they got clobbered to 'bias-disabled'. It would appear there are quite an array of pin modes to choose from...

I admit I'm a bit out of my element.

Are you suggesting the thing to do here is hurry up and wait for 5.3?

Edited to add: Thanks for looking at this.

[pigiron]

@lcard

Yep, I agree that the device tree and pin control stuff is complex. And I still haven't wrapped my brain around the MMC code either; and it doesn't help when the MMC spec costs almost $300... jeeze.

One thing I hadn't really made clear was the dtb file was going to have a bunch of changes for 5.3. So any patch created in PKGBUILD for 5.2 would need to change. And my total guess was the Arch ARM developers probably wouldn't want to carry a custom patch for this anyway.

That's one of the reasons I decided to get a jump on things and see if the 5.3 dtb file would fix this bloody bugger... and it appears that it does. If you look at that 5.3 dtb file, things are really different when it comes to pin bias (and DT structure) for the eMMC and SD card/chip. Some of the pins are biased down, some are biased up, etc. Bottom line is the devs seem to have finally created a combination that works (at least on my system).

Here's an example of what I mean:

https://git.kernel.org/pub/scm/linux/ke ... 489e727d5d

One (obscure) item to note though. Most of the changes (including the example above) in that 5.3 dtb file I used are currently sitting in remote branches of BayLibre's git tree. My assumption is that stuff will be pushed into Linus's git tree in 5.3. Let's hope so anyway.

The latest news from my end is, using that 5.3 dtb file on the 5.2.1-1-ARCH mainline kernel booted successfully to the login prompt, BUT the ethernet subsystem was unstable. It (eth0) struggled to come up and didn't stay up very long. Using the old trick of removing the "bias-disable" in the 5.2 dtb file (like you did) made for a stable working system.

So yea, my suggestion is that we just keep modifying the dtb until 5.3 is released and then see what happens... because it looks hopeful. Something I wouldn't have said before yesterday.

[lcard]

@pigiron

Oh wow. That commit from your link sure looks like they are working on it. I'm just going to fix up /etc/pacman.conf with a IgnorePkg entry and chill out waiting for 5.3. Cool beans.

Thanks again.

[Sagittarius]

@pigiron
@Icard

Thank you very much guys for the good news and for having reported the issue to Baylibre pigiron !

[WorMzy]

My eMMC works again now that linux-aarch64 is at 5.3.1. \o/

[lcard]

@WorMzy

You beat me to it. Mine is working again too. I am a happy camper.

$this->bbcode_second_pass_code('', '
[lcard@null ~]$ uname -a
Linux null 5.3.1-1-ARCH #1 SMP Sat Sep 21 15:09:05 UTC 2019 aarch64 GNU/Linux
')

[Sagittarius]

For info, works great with Linux Odroid-C2 5.3.5-1-ARCH #1 SMP Tue Oct 8 03:39:11 UTC 2019 aarch64 GNU/Linux.
Topic solved