Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

disk: fixing the sending of commands with r1 response #17700

Merged
merged 1 commit into from
Aug 1, 2019

Conversation

pabigot
Copy link
Collaborator

@pabigot pabigot commented Jul 22, 2019

NOTE Rebased version of #15790

The sdhc_cmd_r1_raw() function doesn't take into account the existence
of commands with data response. Because of this, some datas were being
lost.

The commands that return a r1 response and a data are: SDHC_SEND_CSD,
SDHC_SEND_CID, SDHC_READ_SINGLE_BLOCK, SDHC_READ_MULTIPLE_BLOCK,
SDHC_WRITE_BLOCK, SDHC_WRITE_MULTIPLE_BLOCK.

In order to solve this, was juts necessary skip the byte discard when
the command is one of these.

This problem was affecting, for example, the sdhc initialization. The
token returned from SDHC_SEND_CSD was being lost and the initialization
was broken.

Fixes #15444.

Signed-off-by: Lucas Peixoto lucaspeixotoac@gmail.com
Signed-off-by: Peter A. Bigot pab@pabigot.com

The sdhc_cmd_r1_raw() function doesn't take into account the existence
of commands with data response. Because of this, some datas were being
lost.

The commands that return a r1 response and a data are: SDHC_SEND_CSD,
SDHC_SEND_CID, SDHC_READ_SINGLE_BLOCK, SDHC_READ_MULTIPLE_BLOCK,
SDHC_WRITE_BLOCK, SDHC_WRITE_MULTIPLE_BLOCK.

In order to solve this, was juts necessary skip the byte discard when
the command is one of these.

This problem was affecting, for example, the sdhc initialization. The
token returned from SDHC_SEND_CSD was being lost and the initialization
was broken.

Fixes zephyrproject-rtos#15444.

Signed-off-by: Lucas Peixoto <lucaspeixotoac@gmail.com>
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
@pabigot
Copy link
Collaborator Author

pabigot commented Jul 22, 2019

I have a backport branch ready to go whenever it can be done (it won't backport automatically due to changes since 1.14).

@pabigot pabigot modified the milestones: v2.0.0, v1.14.1 Jul 23, 2019
@pabigot pabigot added the dev-review To be discussed in dev-review meeting label Jul 31, 2019
@pabigot
Copy link
Collaborator Author

pabigot commented Jul 31, 2019

Added to dev review so we can make progress on this.

@galak galak removed the dev-review To be discussed in dev-review meeting label Aug 1, 2019
@galak galak merged commit e3f2add into zephyrproject-rtos:master Aug 1, 2019
@backporting
Copy link

backporting bot commented Aug 1, 2019

The backport to v1.14-branch failed:

Commits ["e637ebcc74a21b3c67efff1bfd002e840393b8d6"] could not be cherry-picked on top of v1.14-branch

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub.
git fetch
# Create new working tree.
git worktree add .worktrees/backport v1.14-branch
# Navigate to the new directory.
cd .worktrees/backport
# Cherry-pick all the commits of this pull request and resolve the likely conflicts.
git cherry-pick e637ebcc74a21b3c67efff1bfd002e840393b8d6
# Create a new branch with these backported commits.
git checkout -b backport-17700-to-v1.14-branch
# Push it to GitHub.
git push --set-upstream origin backport-17700-to-v1.14-branch
# Go back to the original working tree.
cd ../..
# Delete the working tree.
git worktree remove .worktrees/backport

Then, create a pull request where the base branch is v1.14-branch and the compare/head branch is backport-17700-to-v1.14-branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Error initiating sdhc disk
3 participants