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

Wip/hughsie/nvme #666

Closed
wants to merge 4 commits into
base: master
from

Conversation

2 participants
@hughsie
Owner

hughsie commented Aug 16, 2018

No description provided.

@hughsie

This comment has been minimized.

Show comment
Hide comment
@hughsie

hughsie Aug 16, 2018

Owner

UNTESTED!

Owner

hughsie commented Aug 16, 2018

UNTESTED!

@superm1

Well that was quick. I guess since you have a json dump in the directory it would be good to read that in and with a self test script (and maybe call /bin/true with it to test "flash process" rather than nvme)

Show outdated Hide outdated plugins/nvme/fu-plugin-nvme.c
Show outdated Hide outdated plugins/nvme/fu-plugin-nvme.c
Show outdated Hide outdated plugins/nvme/fu-plugin-nvme.c
Show outdated Hide outdated plugins/nvme/fu-plugin-nvme.c
@superm1

This comment has been minimized.

Show comment
Hide comment
@superm1

superm1 Aug 16, 2018

Collaborator

Assuming this works I guess we'll want to enact getting it installed by more packages automatically too.
I think that can be followed up later though.

Collaborator

superm1 commented Aug 16, 2018

Assuming this works I guess we'll want to enact getting it installed by more packages automatically too.
I think that can be followed up later though.

@superm1

This comment has been minimized.

Show comment
Hide comment
@superm1

superm1 Aug 16, 2018

Collaborator

Have you examined any firmware binaries to check how they're constructed? I inquire because I notice this:

The firmware image may be constructed of multiple pieces that
are individually downloaded with separate Firmware Image Download
commands. Each Firmware Image Download command includes a Dword
Offset and Number of Dwords that specify a Dword range. The host
software shall ensure that firmware pieces do not have Dword ranges
that overlap. Firmware portions may be submitted out of order to the
controller.

If that's a common situation then this might be difficult to represent in the plugin.

Collaborator

superm1 commented Aug 16, 2018

Have you examined any firmware binaries to check how they're constructed? I inquire because I notice this:

The firmware image may be constructed of multiple pieces that
are individually downloaded with separate Firmware Image Download
commands. Each Firmware Image Download command includes a Dword
Offset and Number of Dwords that specify a Dword range. The host
software shall ensure that firmware pieces do not have Dword ranges
that overlap. Firmware portions may be submitted out of order to the
controller.

If that's a common situation then this might be difficult to represent in the plugin.

@hughsie

This comment has been minimized.

Show comment
Hide comment
@hughsie

hughsie Aug 16, 2018

Owner

If that's a common situation then this might be difficult to represent in the plugin.

I've never seen an image with more than one chunk, and I've never seen an image that had an offset that wasn't 0. If we did have to support such a thing I'd urge the vendor to ship a DfuSe binary, that can have multiple images, each with a 32bit offset, and additional metadata. This could then be parsed in the plugin and each image applied.

If you think that's a sensible thing to support out of the box (or if you know of a NVMe binary with more than one chunk) just say and I'll add it to the plugin.

Owner

hughsie commented Aug 16, 2018

If that's a common situation then this might be difficult to represent in the plugin.

I've never seen an image with more than one chunk, and I've never seen an image that had an offset that wasn't 0. If we did have to support such a thing I'd urge the vendor to ship a DfuSe binary, that can have multiple images, each with a 32bit offset, and additional metadata. This could then be parsed in the plugin and each image applied.

If you think that's a sensible thing to support out of the box (or if you know of a NVMe binary with more than one chunk) just say and I'll add it to the plugin.

@superm1

This comment has been minimized.

Show comment
Hide comment
@superm1

superm1 Aug 16, 2018

Collaborator

If you think that's a sensible thing to support out of the box (or if you know of a NVMe binary with more than one chunk) just say and I'll add it to the plugin.

If it's not common I don't think it's sensible to support. I haven't analyzed any of the binaries we use yet, so I don't know if that's something we have to worry about.

Collaborator

superm1 commented Aug 16, 2018

If you think that's a sensible thing to support out of the box (or if you know of a NVMe binary with more than one chunk) just say and I'll add it to the plugin.

If it's not common I don't think it's sensible to support. I haven't analyzed any of the binaries we use yet, so I don't know if that's something we have to worry about.

@hughsie

This comment has been minimized.

Show comment
Hide comment
@hughsie

hughsie Aug 20, 2018

Owner

It wasn't hard to use the ioctl to read the CNS without using nvme-cli. I think this version is much better. Could you re-review please? Thanks.

Owner

hughsie commented Aug 20, 2018

It wasn't hard to use the ioctl to read the CNS without using nvme-cli. I think this version is much better. Could you re-review please? Thanks.

fu_nvme_device_init (FuNvmeDevice *self)
{
fu_device_add_flag (FU_DEVICE (self), FWUPD_DEVICE_FLAG_REQUIRE_AC);
fu_device_add_flag (FU_DEVICE (self), FWUPD_DEVICE_FLAG_UPDATABLE);

This comment has been minimized.

@superm1

superm1 Aug 21, 2018

Collaborator

Weren't we talking about making this updatable flag a whitelist (eg quirked) until OEM vs aftermarket is sorted out?

@superm1

superm1 Aug 21, 2018

Collaborator

Weren't we talking about making this updatable flag a whitelist (eg quirked) until OEM vs aftermarket is sorted out?

This comment has been minimized.

@hughsie

hughsie Aug 21, 2018

Owner

Yes, I still think that's best. Having it as a quirk still makes it hard to test tho. Maybe we can use --force if something isn't in the whitelist?

@hughsie

hughsie Aug 21, 2018

Owner

Yes, I still think that's best. Having it as a quirk still makes it hard to test tho. Maybe we can use --force if something isn't in the whitelist?

This comment has been minimized.

@superm1

superm1 Aug 21, 2018

Collaborator

Yeah I think that's good for now.

@superm1

superm1 Aug 21, 2018

Collaborator

Yeah I think that's good for now.

This comment has been minimized.

@hughsie

hughsie Aug 21, 2018

Owner

I've done the force thing. Do you think it makes sense to whitelist based on model, vendor or guid? Or leave the whitelist to later?

@hughsie

hughsie Aug 21, 2018

Owner

I've done the force thing. Do you think it makes sense to whitelist based on model, vendor or guid? Or leave the whitelist to later?

@superm1

This comment has been minimized.

Show comment
Hide comment
@superm1

superm1 Aug 21, 2018

Collaborator

Looks like the remaining CI failures are all real things (small though).

Collaborator

superm1 commented Aug 21, 2018

Looks like the remaining CI failures are all real things (small though).

g_autofree gchar *guid_id = NULL;
/* add extra component ID if set */
component_id = fu_nvme_device_get_string_safe (buf, 0xc36, 0xc3d);

This comment has been minimized.

@superm1

superm1 Aug 23, 2018

Collaborator

The start offset is right, but this should be 8 long not 7 long.

@superm1

superm1 Aug 23, 2018

Collaborator

The start offset is right, but this should be 8 long not 7 long.

This comment has been minimized.

@hughsie

hughsie Aug 23, 2018

Owner

Yup, it is. It's "inclusive" --hence the + 1 in the fu_nvme_device_get_string_safe() length calculation. I did it that way to match the constants in the NVMe spec. If it's confusing I can add a comment.

@hughsie

hughsie Aug 23, 2018

Owner

Yup, it is. It's "inclusive" --hence the + 1 in the fu_nvme_device_get_string_safe() length calculation. I did it that way to match the constants in the NVMe spec. If it's confusing I can add a comment.

This comment has been minimized.

@superm1

superm1 Aug 23, 2018

Collaborator

Ah yes, a comment would be good.

@superm1

superm1 Aug 23, 2018

Collaborator

Ah yes, a comment would be good.

This comment has been minimized.

@hughsie

hughsie Aug 23, 2018

Owner

Done.

@hughsie
@superm1

This comment has been minimized.

Show comment
Hide comment
@superm1

superm1 Aug 23, 2018

Collaborator

Tested it on a Dell disk that does export both an EFI GUID and Component ID, it did build the GUIDs properly. Haven't tried flashing yet though, waiting for a new binary to do that.

Collaborator

superm1 commented Aug 23, 2018

Tested it on a Dell disk that does export both an EFI GUID and Component ID, it did build the GUIDs properly. Haven't tried flashing yet though, waiting for a new binary to do that.

fu_nvme_device_parse_cns_maybe_dell (self, buf);
/* fall back to the device description */
if (fu_device_get_guids (FU_DEVICE (self))->len == 0) {

This comment has been minimized.

@superm1

superm1 Aug 23, 2018

Collaborator

In your data set were you able to check if any other vendors 'vs' blobs set off the Dell creation of a Dell GUID? With this approach I would just wonder if another vendor vs section has a set of bytes that could represent an EFI guid at that offset) (but doesn't actually) what happens.

@superm1

superm1 Aug 23, 2018

Collaborator

In your data set were you able to check if any other vendors 'vs' blobs set off the Dell creation of a Dell GUID? With this approach I would just wonder if another vendor vs section has a set of bytes that could represent an EFI guid at that offset) (but doesn't actually) what happens.

This comment has been minimized.

@hughsie

hughsie Aug 23, 2018

Owner

It takes more than the plausible GUID, it also takes a plausible component ID string too.

@hughsie

hughsie Aug 23, 2018

Owner

It takes more than the plausible GUID, it also takes a plausible component ID string too.

This comment has been minimized.

@superm1

superm1 Aug 23, 2018

Collaborator

OK, I guess that makes sense then for this. It would only apply to "newer" disks (that only have more than one field), but it's safer.

@superm1

superm1 Aug 23, 2018

Collaborator

OK, I guess that makes sense then for this. It would only apply to "newer" disks (that only have more than one field), but it's safer.

hughsie and others added some commits Aug 23, 2018

f
f
@hughsie

This comment has been minimized.

Show comment
Hide comment
@hughsie

hughsie Aug 26, 2018

Owner

Fixed to actually make updates work, and merged, rebasing against wip/hughsie/gudev. Thanks for all the reviews.

Owner

hughsie commented Aug 26, 2018

Fixed to actually make updates work, and merged, rebasing against wip/hughsie/gudev. Thanks for all the reviews.

@hughsie hughsie closed this Aug 26, 2018

@hughsie hughsie deleted the wip/hughsie/nvme branch Aug 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment