read android device serial number from sysfs node

[vishwasudupa]

read android serial number value from sysfs node
instead of kernel command line. Upstream boot managers
e.g., systemd-boot does not populate kernel command line
with parameter androidboot.serialno.

Reading serial number from sysfs node
/sys/devices/soc0/serial_number generalizes the approach
and makes it independent of bootloader that loads kernel.

[lumag]

Fix commit messages, please.

[lumag]

Still not fully correct. Please take a note on the difference between your text and previous commit messages.

[lumag]

The serial number in sysfs doesn't match the serial number used by the bootloader and by Android. This makes using board farms extremely hard. You can no longer use a single serial number for the board.

E.g. on the db410c I checked sysfs reads 2644893864 = 0x9da5e0a8, while the bootloader sets androidboot.serialno=c2213c38 We should either find a way to convert sysfs data into the same serial number. Another option might be to make reading sysfs a fallback option for the case the /proc/cmdline doesn't contain serial number, but this still doesn't solve the problem of the board farms.

[lumag]

I checked both ABL and LK sources. The serial number is generated basing on the storage data rather than the SoC serial number. Could you please implement the same approach?

[vishwasudupa]

Checked on device and found the serial number used by the bootloader and value read from /sys/class/mmc_host/mmc0/mmc0:0001/serial are matching. Updated the patchset to use this instead of soc serial number.

[lumag]

Also, what is Linux Build Service Account <lnxbuild@localhost>, that has committed this patch?

[vishwasudupa]

Also, what is Linux Build Service Account <lnxbuild@localhost>, that has committed this patch?

Corrected committer-id.

[lumag]

This will break for UFS-based devices.

[sbanerjee-quic]

Hi @lumag

For the RB5, RB3 UFS devices you are using in which sysfs node you see the adb serial numbers matching?

[lumag]

According to what I see in ABL sources, the serial number of the UFS-based boards is a CRC-32 of the UFS serial no.
For the reference, the RB5 that I have at hand:

# udevadm info /dev/sda | grep SERIAL
E: ID_SERIAL=2SAMSUNG
E: ID_SERIAL_SHORT=SAMSUNG
E: ID_SCSI_SERIAL=414b8c053f19
root@qcom-armv8a:~# xargs -n 1 < /proc/cmdline  | grep serial
androidboot.serialno=9105fd32

[lumag]

Relevant piece from ABL:

  Status =
      gBS->HandleProtocol (HandleInfoList[0].Handle,
                           &gEfiMemCardInfoProtocolGuid, (VOID **)&CardInfo);
  if (Status != EFI_SUCCESS) {
    DEBUG ((EFI_D_ERROR, "Error locating MemCardInfoProtocol:%x\n", Status));
    return Status;
  }

  if (CardInfo->GetCardInfo (CardInfo, &CardInfoData) == EFI_SUCCESS) {
    if (Type == UFS) {
      Status = gBS->CalculateCrc32 (CardInfoData.product_serial_num,
                                    CardInfoData.serial_num_len, &SerialNo);
      if (Status != EFI_SUCCESS) {
        DEBUG ((EFI_D_ERROR,
                "Error calculating Crc of the unicode serial number: %x\n",
                Status));
        return Status;
      }
      AsciiSPrint (StrSerialNum, Len, "%x", SerialNo);
    } else {
      AsciiSPrint (StrSerialNum, Len, "%x",
                   *(UINT32 *)CardInfoData.product_serial_num);
    }

[lumag]

1. Please keep UFS devices working.
2. Please make this more robust by checking that the the MMC device exists and that it is actually an eMMC device.

[vishwasudupa]

Below pr solves the issue
#553