ODROID-N2/C2/C4: Force 40MHz instead of 24MHz as eMMC clock #3319
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It seems that forcing 24MHz clocks is problematic for newer 32GB Kingston based eMMC modules on ODROID-N2(+). Use what downstream U-Boot is using as f_max, which is 40MHz. Fixes: #3227
agners
force-pushed
the
odroid-use-40mhz-emmc-clock
branch
2 times, most recently
from
eab292f
to
865d640
Compare
agners
changed the title
alvaroroyo
approved these changes
Apr 23, 2024
sairon
approved these changes
Apr 24, 2024
sairon
added a commit
that referenced
this pull request
Jun 11, 2024
As we don't have proper solution for #3319 and #3351 yet, revert to previous U-Boot which was proven working. This is intended as a workaround but as there's nothing in the latest U-Boot that will be really missed on N2, we can stay on the older version for the time being. This also means reverting the "40 MHz hack" back to the 24 MHz one. Since this patch only applies to N2 (meson gx), it can stay along the common hardkernel uboot patches.
sairon
added a commit
that referenced
this pull request
Jun 11, 2024
As we don't have proper solution for #3319 and #3351 yet, revert to previous U-Boot which was proven working. This is intended as a workaround but as there's nothing in the latest U-Boot that will be really missed on N2, we can stay on the older version for the time being. This also means reverting the "40 MHz hack" back to the 24 MHz one. Since this patch only applies to N2 (meson gx), it can stay along the common hardkernel uboot patches.
sairon
added a commit
that referenced
this pull request
Oct 10, 2024
Testing shows that the 24MHz cap is problematic for Kingston. Bumping this cap to 40 MHz in #3319 fixed Kingston but reintroduced issues with some other eMMCs that the frequency cap was supposed to fix. This commit adds another patch that selects a different clock for eMMC. While it's still unclear why Kingston fails with the frequencies of slightly below 24 MHz (see patch message why it's below), using 24 MHz from xtal seems to be fine and hopefully shouldn't introduce regressions for old eMMCs. Alternative approach would be using the same clock source but setting the frequency cap to 25 MHz. This results in exact 25 MHz from PLL which is even the defined frequency for some eMMC modes, Kingston eMMC works fine with it and the difference from the previously used value wouldn't be too high, but with 24 MHz we're even closer. refs #3250, refs #3227
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It seems that forcing 24MHz clocks is problematic for newer 32GB Kingston based eMMC modules on ODROID-N2(+). Use what downstream U-Boot is using as f_max, which is 40MHz.
Fixes: #3227