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

Add support for UFS devices #36

Open
runningnak3d opened this issue Dec 12, 2017 · 6 comments
Open

Add support for UFS devices #36

runningnak3d opened this issue Dec 12, 2017 · 6 comments

Comments

@runningnak3d
Copy link

LG devices with UFS NAND use a sector size of 4096 not 512. Also, they have 7 block devices (/dev/block/sda to /dev/block/sdg) instead of the single block device (mmcblk0) that an eMMC device has.

I propose adding two switches:

--ufs to set the blocksize to 4096
--block to pass the block device that you want to work with

Alternatively could parse the GPT of all 7 block devices, and then issue the OPEN based on the partition that gets passed.

I am happy to open a PR, but some feedback on the best method of dealing with UFS would be good first :)

-- Brian

@tuxuser
Copy link
Contributor

tuxuser commented Dec 12, 2017

Hey @runningnak3d! Does an UFS device advertise somehow that it's using UFS? Maybe in the LAF Properties.. or in another way?

@runningnak3d
Copy link
Author

Hmmm, well memory_id:'H28U74303AMR \n' but then we would have to have a list of all the NAND chips.

Another possibility is to parse dmesg:

[LAF] lun_sizes[0] = 124370944

[LAF] lun_sizes[1] = 32768

[LAF] lun_sizes[2] = 16384

[LAF] lun_sizes[3] = 16384

[LAF] lun_sizes[4] = 475136

[LAF] lun_sizes[5] = 16384

[LAF] lun_sizes[6] = 16384

Lastly, could try to open /dev/block/sda if it fails, it is an eMMC device, if it opens, it is UFS.

Those are the only auto detection methods that I can think of.

@Lekensteyn
Copy link
Owner

Parsing dmesg is probably fragile, maybe there is some /sys/block//queue/ file that could list the actual size (/sys/block/sda/queue/physical_block_size or logical_block_size)? Maybe it is even safe to use 4K in both UFS/eMMC cases if the offsets are aligned at that number (I am just thinking aloud).

eMMC has a single block device with a partition table, how does UFS work?
What are the different block devices sda..sdg for?
Do they have partitions like sda1, sda2, etc.?)

@runningnak3d
Copy link
Author

Yes the /sys file system has the size of the devices, but we can't read those with protocol version 1.0.0.4. No way -- no cat command :)

The partitions that are on the single mmcblk0 block device are spread across the 7 block devices. For example laf on the v20 is /dev/block/sda1 recovery is /dev/block/sde2.

Yea, I agree that parsing dmesg is messy. IMHO trying to open sda is the cleanest. It will fail on eMMC devices and succeed on UFS devices. Can't check for mmcblk0 because if someone has a UFS device and has an SD card in, it will exist.

@runningnak3d
Copy link
Author

I don't really like this solution because it relies on ls and that could be pulled in the future....

With that said, we could ls /dev/block/sda -- if it exists, it is a UFS device, if not eMMC. If it is a UFS, then we need to find out how many block devices there are as some devices use less than the 7 that are available on UFS. Iterate through sda to sdg till nothing is returned, then read each one to get the partition info into an array. At that point based on the partition name that is passed, the appropriate block device can be opened.

Thoughts?

@shadabmozaffar
Copy link

To know if memory device is UFS or eMMC, you can rely on block size, which is 4K for UFS. To detect, you can just read physical_part0 GPT, and if EFI PART sign in at 4K address, you have UFS device. EFI PART signature is always at Sector 1.

Btw, I am still thinking how to open physical part 1 and others with OPEN command?

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

No branches or pull requests

4 participants