Hi Balena Team,
now i looked into the beta device provided and found some issues with the hardware capabilities for reading CID of the sd-card device inserted.
The Devices are mounted as /dev/sd[a-p] this is no issue for flashing it but for reading out CDIs over SPI.
Because the Device is using the USB Storage Capabilities and not the SPI.
I collected two good ressources for the situation and will have a look by myself, if reading CIDs will be possible without breaking the OS.
Stack Overflow Why /dev/sda cant be used to read CID from a SD-Card Reader in USB-Mass Storage mode
Stack Overflow on the possibilities to use a SD-Card Reader with SPI instead of USB mass-storage mode
Hey @Markus.Kohn.GWA I pinged Zane who is working on this in case he can help you somehow.
1 Like
I Markus, we are able to get the serial number from the card already. I have gotten it working on Windows and Linux at least, but I am now working on integrating the solution into our codebase.
There was some technical debt built up that I am taking care of, but as soon as that is fixed, we should be able to add the field to Etcher-SDK.
For your reference, in Etcher, we actually don’t use lsblk and parse the output from that, so that work is done for us.
For Windows we will use IOCTL_STORAGE_GET_MEDIA_SERIAL_NUMBER.
I haven’t actually tried on Mac yet, because I started working on the technical debt I mentioned earlier, but I am hoping to get this resolved this week. It might be a little longer before we can actually deploy the fix though.
So, the technical challenges of actually getting the serial number are mostly done, it’s other stuff happening in the background that I am working on, that is specific to Balena.
Thank you for the info though. I do plan on implementing a native solution on Linux so we don’t have to rely on lsblk on the user’s system, although, since pretty much every linux machine is probably going to have lsblk, is hasn’t been a priority.
I will keep you posted on future updates.
Thanks,
Zane
1 Like
Thank you @konmouz and @zwhitchcox this sounds pretty much like a good way to go. 
Looking forward to hear from you guys.
Best Regards, I get back to integrating the etcherPro into our internal workflows now. 
Just to make sure @zwhitchcox
Is it possible to read the CID from the connected flash targets as well?
You said:
we are able to get the serial number from the card already. I have gotten it working on Windows and Linux at least, but I am now working on integrating the solution into our codebase
Do you mean the host SD-Card and the flash targets or only the host SD-Card?
Regards,
Markus
Yes, the solution will read the serial number from the flash targets. I’m not sure what you mean by “host” SD card though? As in if the host OS is running on an SD card? But the answer is yes, because the system drives also show up in etcher.
I’ve created an issue so that the public can follow. When the PR is merged, it will automatically open this ticket, and I will respond here that it is done.
Or, if you prefer, you can just watch the issue.
Hi @zwhitchcox
First, thank you for the issue and the link to this thread, i had a look into the drivelist project now.
Yes, the solution will read the serial number from the flash targets
Okay, so on the EtcherPro hardware+OS tweaks are needed to read the CIDs because the Card-Readers are running in USB-Mass Storage Mode and not SPI mode. That means, changes to drivelist will not be enough, i guess.
I’m not sure what you mean by “host” SD card though?
“The Balena EtcherPro already read CIDs” that is the current explanation of the hardware capabilities. I just wanted to make sure that you know that this could be misleading because someone most likely was able to read the CID of mmcblk0. Which is the block device the OS is running on.
The Flash targets are only recognized as sda, sdb, sdc and so on.
With this thread i want to assure that the targets need to be registered/ recognized as mmcblk devices in order to read the SD-Card registers mentioned in the Simplified Specifications sdcard.org. Worth a read is always this page where the information is a bit more condensed down to tables and figures: cameramemoryspeed.com
“The Balena EtcherPro already read CIDs” that is the current explanation of the hardware capabilities. I just wanted to make sure that you know that this could be misleading because someone most likely was able to read the CID of mmcblk0. Which is the block device the OS is running on.
Ah, I see, no, I tested on the /dev/sda device. For linux, this code is already written for us, because it uses lsblk under the hood though (although I intend to change that at some point to remove the lsblk dependency).
Just to keep you updated, I believe I have the CI issues worked out, and now I’m back to the main event, although there is one other (unrelated) issue I’m working on as well.
Okay, so on the EtcherPro hardware+OS tweaks are needed to read the CIDs because the Card-Readers are running in USB-Mass Storage Mode and not SPI mode. That means, changes to drivelist will not be enough, i guess.
I haven’t actually tested this on the EtcherPro yet, so I’m I’ll have to get back to you when I get to that point, but I think it should still work, as I’ve tried on USB adapters before, and it has been working. To my understanding the adapter just forwards SCSI commands to the SD card. SCSI just has a standard command list (see SCSI command - Wikipedia), and everything else is just built on top of the SCSI generic driver in linux. This article gives a great explanation of how SCSI works underneath the hood, but basically, Linux pretty much just handles all the tedious request forwarding, so we can just send IOCTL commands directly to the device (/dev/sd*).
But again, this is all theoretical until I test it, but I haven’t gotten to that point yet.
1 Like
okey thanks for the update, i think we both now know what we wanted to say.
Then I look forward to your updates
Regards,
Markus
Hi, Markus, so I have some sad news. It turns out you were right. The SCSI signals are intercepted and translated to USB mass storage device packets, and most of the ioctl commands are not forwarded properly by the card readers. It looks like there is no real way that I can find to add serial numbers with the current etcher pro hardware. I thought I was getting a serial number, but it turns out it was just a revision level of the card reader itself that it was reporting as its serial number. I’ve been able to get serial numbers of USB mass storage devices and like you said, mmcblk and nvme devices, but not SD cards through the SCSI generic driver. Sorry, I had a misunderstanding of how the sg driver worked.
1 Like
@zwhitchcox sorry to hear that.
Not that I prepared for this scenario, but I already figured out a production process change for our use case.
The problem comes with the compatibility and implementation given by SD-card reader vendors. They don´t label their product features when it comes to consumer hardware, and enterprise venders often fail the feature of SPI mode, but at least can tell afterwards.
I really would like to ask for a V2 of the etcherPro with SD-Association conformity when it comes to the MMC features.
Anyways we already love our etcherPro, gave it its own desk and will integrate it even more in the future.
Regards Markus