Alex Bennée via Stratos-dev stratos-dev@op-lists.linaro.org writes:
Hi Ulf,
Ilias told me you were the eMMC guru so your might be best placed to advise on this problem.
Ping?
<snip>
However I'm wary of adding an open ended pass-through definition, especially anything that might tempt an implementer to start trying to read and write data using eMMC commands instead of the proper virtio commands.
- What eMMC commands are needed for a probe?
- What are the bounds of frame sizes for those commands?
- I'm currently overloading the wasted stuff[196] bytes to the encapsulation and it would get complicated if we extended into the used fields.
- Should we mandate certain responses?
- e.g. 0 "normal" size, eMMC version 4.1 etc
Thanks,
-- Alex Bennée
On Thu, 15 Oct 2020 at 12:44, Alex Bennée alex.bennee@linaro.org wrote:
Alex Bennée via Stratos-dev stratos-dev@op-lists.linaro.org writes:
Hi Ulf,
Ilias told me you were the eMMC guru so your might be best placed to advise on this problem.
Ping?
This slipped through in my email filtering, my apologies.
Anyway, let me try to help.
<snip>
However I'm wary of adding an open ended pass-through definition, especially anything that might tempt an implementer to start trying to read and write data using eMMC commands instead of the proper virtio commands.
- What eMMC commands are needed for a probe?
I suggest you have a look at the mmc core in the kernel. More precisely:
drivers/mmc/core/core.c, drivers/mmc/core/mmc.c and drivers/mmc/core/mmc_ops.c. These files implement the eMMC specification, in principle.
Start following the path from the mmc_rescan() function, where you would end up in mmc_attach_mmc() after a while, which is the piece of code dealing with the eMMC card initializations.
Note that, depending on the greater speed mode you want to support, the more complicated becomes the initialization.
- What are the bounds of frame sizes for those commands?
Not sure what you mean by frame size here. Most of the initialization commands don't transmit any data from an I/O point of view, but are sent on a single command line.
In some cases, there are 512 bytes being transmitted on the 8 data lines, along with control commands on a separate line.
- I'm currently overloading the wasted stuff[196] bytes to the encapsulation and it would get complicated if we extended into the used fields.
No clue what you are talking about, sorry.
- Should we mandate certain responses?
The eMMC spec mandates the responses, so not sure what you propose.
- e.g. 0 "normal" size, eMMC version 4.1 etc
I clearly don't have the full context here, but I understand that you are looking at an abstraction layer above eMMC, but perhaps even block devices in general?
Seems I need to get a better picture, if I should be able to guide you in some direction.
We can run a HO or if you can point me to some other documentations!?
Kind regards Uffe
Ulf Hansson ulf.hansson@linaro.org writes:
On Thu, 15 Oct 2020 at 12:44, Alex Bennée alex.bennee@linaro.org wrote:
Alex Bennée via Stratos-dev stratos-dev@op-lists.linaro.org writes:
Hi Ulf,
Ilias told me you were the eMMC guru so your might be best placed to advise on this problem.
Ping?
This slipped through in my email filtering, my apologies.
Anyway, let me try to help.
<snip>
However I'm wary of adding an open ended pass-through definition, especially anything that might tempt an implementer to start trying to read and write data using eMMC commands instead of the proper virtio commands.
- What eMMC commands are needed for a probe?
I suggest you have a look at the mmc core in the kernel. More precisely:
drivers/mmc/core/core.c, drivers/mmc/core/mmc.c and drivers/mmc/core/mmc_ops.c. These files implement the eMMC specification, in principle.
Start following the path from the mmc_rescan() function, where you would end up in mmc_attach_mmc() after a while, which is the piece of code dealing with the eMMC card initializations.
Note that, depending on the greater speed mode you want to support, the more complicated becomes the initialization.
I'm not looking to emulate an eMMC device but to provide enough support that an eMMC stack which understands RPMB partitions can operate with a virtio-rpmb backend. It may well be that the driver model is just not suited to being plumbed into existing eMMC software stacks.
- What are the bounds of frame sizes for those commands?
Not sure what you mean by frame size here. Most of the initialization commands don't transmit any data from an I/O point of view, but are sent on a single command line.
In some cases, there are 512 bytes being transmitted on the 8 data lines, along with control commands on a separate line.
- I'm currently overloading the wasted stuff[196] bytes to the encapsulation and it would get complicated if we extended into the used fields.No clue what you are talking about, sorry.
The virtio-rpmb frame is 512 bytes of which 196 bytes is currently unused by the specification. If I can fit everything into currently unused bytes that makes things simpler - but it depends on the maximum frame size needed to do a negotiation that satisfies the software stack. I'm not expecting to transfer any data aside from 256 byte RPMB data frames.
- Should we mandate certain responses?
The eMMC spec mandates the responses, so not sure what you propose.
- e.g. 0 "normal" size, eMMC version 4.1 etcI clearly don't have the full context here, but I understand that you are looking at an abstraction layer above eMMC, but perhaps even block devices in general?
Seems I need to get a better picture, if I should be able to guide you in some direction.
We can run a HO or if you can point me to some other documentations!?
Sure - maybe a HO with Ilias and myself so he can lay out the problem he's trying to solve and I can explain what the virtio-rpmb device provides.
Kind regards Uffe
On Thu, 15 Oct 2020 at 16:51, Alex Bennée alex.bennee@linaro.org wrote:
Ulf Hansson ulf.hansson@linaro.org writes:
On Thu, 15 Oct 2020 at 12:44, Alex Bennée alex.bennee@linaro.org wrote:
Alex Bennée via Stratos-dev stratos-dev@op-lists.linaro.org writes:
Hi Ulf,
Ilias told me you were the eMMC guru so your might be best placed to advise on this problem.
Ping?
This slipped through in my email filtering, my apologies.
Anyway, let me try to help.
<snip>
However I'm wary of adding an open ended pass-through definition, especially anything that might tempt an implementer to start trying to read and write data using eMMC commands instead of the proper virtio commands.
- What eMMC commands are needed for a probe?
I suggest you have a look at the mmc core in the kernel. More precisely:
drivers/mmc/core/core.c, drivers/mmc/core/mmc.c and drivers/mmc/core/mmc_ops.c. These files implement the eMMC specification, in principle.
Start following the path from the mmc_rescan() function, where you would end up in mmc_attach_mmc() after a while, which is the piece of code dealing with the eMMC card initializations.
Note that, depending on the greater speed mode you want to support, the more complicated becomes the initialization.
I'm not looking to emulate an eMMC device but to provide enough support that an eMMC stack which understands RPMB partitions can operate with a virtio-rpmb backend. It may well be that the driver model is just not suited to being plumbed into existing eMMC software stacks.
I see! That helped me to understand better, thanks!
As you likely know, there is no common rpmb "block" device - but all storage device-types that support an rpmb partition, have their own rpmb interface in the kernel. There have been attempts to implement this, quite recently, but those have failed and are likely not able to make it go forward. Just so you know.
So, for eMMC rpmb, the MMC subsystem exports a character device to userspace, which allows userspace to operate upon it as a "partition".
Userspace must encapsulate the authentication data within the rpmb frames, together with the rpmb-data that it wants to write/read. If you need some examples of how this is being done, there is an open source user space client, implementing a proof of concept for this. Perhaps that can help, while you are trying to define the virto protocol for the backend driver!? Just, tell if you want a pointer to this userspace code.
In regards to frame sizes, for eMMC rpmb the supported frame sizes are always aligned with 512 bytes - and a single 512 bytes is always supported. For the 512 bytes case, 256 bytes are the actual rpmb-data (you already know this of course), while the remaining 256 bytes are authentication data and other metadata that is needed per rpmb frame.
eMMC cards may also support 1024 bytes frames and some even 16k bytes frames, but if you want to keep things simple - maybe it's enough to support only the 512 byte case?
- What are the bounds of frame sizes for those commands?
Not sure what you mean by frame size here. Most of the initialization commands don't transmit any data from an I/O point of view, but are sent on a single command line.
In some cases, there are 512 bytes being transmitted on the 8 data lines, along with control commands on a separate line.
- I'm currently overloading the wasted stuff[196] bytes to the encapsulation and it would get complicated if we extended into the used fields.No clue what you are talking about, sorry.
The virtio-rpmb frame is 512 bytes of which 196 bytes is currently unused by the specification. If I can fit everything into currently unused bytes that makes things simpler - but it depends on the maximum frame size needed to do a negotiation that satisfies the software stack. I'm not expecting to transfer any data aside from 256 byte RPMB data frames.
As stated above, 512bytes should be sufficient for an eMMC rpmb-frame.
256 byte is the rpmb data and the other 256 bytes are for authentication-/meta-data.
- Should we mandate certain responses?
The eMMC spec mandates the responses, so not sure what you propose.
- e.g. 0 "normal" size, eMMC version 4.1 etcI clearly don't have the full context here, but I understand that you are looking at an abstraction layer above eMMC, but perhaps even block devices in general?
Seems I need to get a better picture, if I should be able to guide you in some direction.
We can run a HO or if you can point me to some other documentations!?
Sure - maybe a HO with Ilias and myself so he can lay out the problem he's trying to solve and I can explain what the virtio-rpmb device provides.
Yeah, let's do a HO. In any case, I am interested to learn a bit more about what you guys are working on in this field.
I have just sent you guys an invite. Please suggest another slot, if it doesn't suit you.
Kind regards Uffe
stratos-dev@op-lists.linaro.org
-
Alex Bennée -
Ulf Hansson