Hello there,
I’ve been working on IMX8MP-hummingboard-pulse SOM since couple of years with Hardknott Yocto Image and everything was fine. But recently our SW requirements got changed and for that we have to move to Kirkstone Yocto Image. But the image dosen’t work on all the SOMs I’m working on.
Just to give you a context, here’s what I found while doing some experiments with multiple boards.
Recently I built a fresh Kirkstone Image and it is working as expected but only on one single HW setup. On other Hardwares, the same SD card is not working.
I found following debug prints which states as follows -
board_id_from_tlv_info: did not recognise SKU !
board_late_init: could not identify board, defaulting to CuBox-M!
Because of which when we dump out the device-tree from these HWs, it shows model = “SolidRun i.MX8MP CuBox-M”;
But on the working HW it shows model = “SolidRun i.MX8MP HummingBoard Pulse”;
This clearly tells me that while booting, because of the board-id, the image is rolling back to imx8mp-cubox-m settings instead of going through as hummingboard-pulse.
Looking forward to your help and solution.
Thanks and Warm Regards,
Lokesh Jadhav
Thanks for reaching out. The initial HardKnott distro only had support for the HummingBoard Pulse carrier as that was the only one produced at the time. When we added additional boards including the CuBox-M we also moved to Kirkstone as the default distro since this is a LTS Yocto release.
In order to support the various boards we started programming the SKU and other information in TLV format of the EEPROM of the SOM and Carrier. If there is no SKU data on the SOM then we fall through to the CuBox-M device-tree since it does not have a carrier EEPROM to read to distinguish itself.
The system that does work obviously has this data programmed already. You can either program the TLV data on your SOMs that aren’t working, all the SOMs have an eeprom on board they were just not programmed during early production runs, or you can just override the device-tree file by setting the fdtfile environment variable in u-boot. You can find information on programming the TLV data on developer.solid-run.com
Hi @jnettlet
I followed the below link for EEPROM Programming
https://solidrun.atlassian.net/wiki/spaces/developer/pages/344883516/iMX8MP+EEPROM+Programming+-+TLV
Details of imx8mp-Humming-pulse -board inside EEPROM
TLV Name Code Len Value
Product Name 0x21 28 i.MX8M Plus System on Module
Part Number 0x22 23 SRMP8QDWB1D03GE008V12C0
Serial Number 0x23 16 IP00039223100042
Manufacture Date 0x25 19 03/08/2022 09:57:26
Device Version 0x26 1 12
Label Revision 0x27 1 1
Platform Name 0x28 11 i.MX8M Plus
MAC Addresses 0x2A 2 1
Manufacturer 0x2B 3 IMI
Country Code 0x2C 2 PH
Vendor Name 0x2D 8 SolidRun
Vendor Extension 0xFD 28 0xFF 0xFF 0xFF 0xFF 0x10 0x53 0x52 0x4D 0x50 0x38 0x51 0x44 0x57 0x42 0x31 0x44 0x30 0x33 0x47 0x45 0x30 0x30 0x38 0x56 0x31 0x32 0x43 0x30
CRC-32 0xFE 4 0x724D1D2A
Checksum is valid.
Following is the Error Message I’m getting when I restarted the board
board_id_from_tlv_info: did not recognise kit variant ‘V’ in sku “SRMP8QDWB1D03GE008V12C0”!
board_id_from_tlv_info: did not recognise SKU !
board_late_init: could not identify board, defaulting to CuBox-M!
But when I checked in my yocto project /build/tmp/work/imx8mpsolidrun-poky-linux/u-boot-imx/2022.04-r0/git/noard/solidrun/imx8mpsolidrun/imx8mp_solidrun.c
there were 4 cases based on which it selects the board else it goes to default cuBox
case ‘M’ : mate
case ‘U’ : humming-pulse
case ‘R’ : humming ripple
case ‘X’ : cuBox
These cases are selected based on part number 19th character SRMP8QDWB1D03GE008V12C0
of Vendor Extension code ,which is V in ASCII is 0x56
You can see that Vendor Extension - 0xFD 28 0xFF 0xFF 0xFF 0xFF 0x10 (S)0x53 (R)0x52 (M)0x4D (P)0x50 (8)0x38 (Q)0x51 (D)0x44 (W)0x57 (B)0x42 (1)0x31 (D)0x44 (0)0x30 (3)0x33 (G)0x47 (E)0x45 (0)0x30 (0)0x30 (8)0x38 (V)0x56 (1)0x31 (2)0x32 (C)0x43 (0)0x30
But in the imx8mp_solidrun.c file U is for Humming-pulse
I even tried replacing V(0x56) with U(0x55) in Vendor Extension code to check whether it select Humming-pulse, but still u-boot is not able to read the SKU from EEPROM
Following info is present on the SOM.
Could you please help in resolving this.??
Thanks
Lokesh
There are 2 eeprom’s that need to be programmed. The one on SOM and the one on the carrier. The error you are getting is most likely because the carrier eeprom is not programmed.
You can also reference our SKU decoding guide here, SolidRun SKU Guide - SolidRun
Hi @jnettlet,
We have our own carrier card and it dose not have EEPROM. Is it necessary to have EEPROM on Carrier Card to solve this issue.??
Is there any alternate way to handle this.??
Thanks
Lokesh
If you have your own carrier, then I would recommend just patching u-boot so the fall through default board name matches the same name that you are using for your custom device-tree for your carrier.
I will take a bit of time later to see if we can patch u-boot to make this process a bit simpler.
Dear @jnettlet
Thanks for your quick response. Will do the needful then.
Warm Regards,
Lokesh J.