* ARM: amlogic: RFC: meson_sm_get_serial secure call update
@ 2021-10-05 9:35 Vyacheslav Bocharov
2021-10-07 8:13 ` Neil Armstrong
0 siblings, 1 reply; 6+ messages in thread
From: Vyacheslav Bocharov @ 2021-10-05 9:35 UTC (permalink / raw)
To: Neil Armstrong; +Cc: u-boot-amlogic
Hi.
I am investigating the source code of uboot from amlogic and found
differences in the function to get the cpu serial. In amlogic-uboot it
looks like this:
int version = *((unsigned int *)sharemem_output_base);
if (version == 2) {
memcpy(buff, (void *)sharemem_output_base + 4, 16);
}
else {
/**
* Legacy 12-byte chip ID read out, transform data
* to expected order format.
*/
uint32_t chip_info = readl(P_AO_SEC_SD_CFG8);
uint8_t *ch;
int i;
((uint32_t *)buff)[0] =
((chip_info & 0xff000000) | // Family ID
((chip_info << 8) & 0xff0000) | // Chip Revision
((chip_info >> 8) & 0xff00)); // Package ID
((uint32_t *)buff)[0] = htonl(((uint32_t *)buff)[0]);
/* Transform into expected order for display */
ch = (uint8_t *)(sharemem_output_base + 4);
for (i = 0; i < 12; i++)
buff[i + 4] = ch[11 - i];
}
Where P_AO_SEC_SD_CFG8 is offset (0x88<<2) of the AOBUS_BASE register.
The current uboot source code uses only the read 12 bytes as cpu serial
ignoring the chipID and the existence of a 16-byte version of the serial
number.
Does it make sense to transfer the code to the uboot project?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ARM: amlogic: RFC: meson_sm_get_serial secure call update
2021-10-05 9:35 ARM: amlogic: RFC: meson_sm_get_serial secure call update Vyacheslav Bocharov
@ 2021-10-07 8:13 ` Neil Armstrong
2021-10-07 12:11 ` Vyacheslav Bocharov
0 siblings, 1 reply; 6+ messages in thread
From: Neil Armstrong @ 2021-10-07 8:13 UTC (permalink / raw)
To: Vyacheslav; +Cc: u-boot-amlogic
Hi,
On 05/10/2021 11:35, Vyacheslav wrote:
> Hi.
>
> I am investigating the source code of uboot from amlogic and found differences in the function to get the cpu serial. In amlogic-uboot it looks like this:
>
> int version = *((unsigned int *)sharemem_output_base);
>
> if (version == 2) {
> memcpy(buff, (void *)sharemem_output_base + 4, 16);
> }
> else {
> /**
> * Legacy 12-byte chip ID read out, transform data
> * to expected order format.
> */
> uint32_t chip_info = readl(P_AO_SEC_SD_CFG8);
> uint8_t *ch;
> int i;
>
> ((uint32_t *)buff)[0] =
> ((chip_info & 0xff000000) | // Family ID
> ((chip_info << 8) & 0xff0000) | // Chip Revision
> ((chip_info >> 8) & 0xff00)); // Package ID
>
> ((uint32_t *)buff)[0] = htonl(((uint32_t *)buff)[0]);
>
> /* Transform into expected order for display */
> ch = (uint8_t *)(sharemem_output_base + 4);
> for (i = 0; i < 12; i++)
> buff[i + 4] = ch[11 - i];
> }
>
>
> Where P_AO_SEC_SD_CFG8 is offset (0x88<<2) of the AOBUS_BASE register.
We already handle this in arch/arm/mach-meson/board-info.c
>
> The current uboot source code uses only the read 12 bytes as cpu serial ignoring the chipID and the existence of a 16-byte version of the serial number.
>
> Does it make sense to transfer the code to the uboot project?
>
How does it detect when 16 bytes serial is available ?
I'm not against this but I'm not sure when 16 bytes are available.
Neil
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ARM: amlogic: RFC: meson_sm_get_serial secure call update
2021-10-07 8:13 ` Neil Armstrong
@ 2021-10-07 12:11 ` Vyacheslav Bocharov
2021-10-07 12:48 ` Neil Armstrong
0 siblings, 1 reply; 6+ messages in thread
From: Vyacheslav Bocharov @ 2021-10-07 12:11 UTC (permalink / raw)
To: u-boot-amlogic, narmstrong
07.10.2021 11:13, Neil Armstrong пишет:
> Hi,
>
> On 05/10/2021 11:35, Vyacheslav wrote:
>> Hi.
>>
>> I am investigating the source code of uboot from amlogic and found differences in the function to get the cpu serial. In amlogic-uboot it looks like this:
>>
>> int version = *((unsigned int *)sharemem_output_base);
>>
>> if (version == 2) {
>> memcpy(buff, (void *)sharemem_output_base + 4, 16);
>> }
>> else {
>> /**
>> * Legacy 12-byte chip ID read out, transform data
>> * to expected order format.
>> */
>> uint32_t chip_info = readl(P_AO_SEC_SD_CFG8);
>> uint8_t *ch;
>> int i;
>>
>> ((uint32_t *)buff)[0] =
>> ((chip_info & 0xff000000) | // Family ID
>> ((chip_info << 8) & 0xff0000) | // Chip Revision
>> ((chip_info >> 8) & 0xff00)); // Package ID
>>
>> ((uint32_t *)buff)[0] = htonl(((uint32_t *)buff)[0]);
>>
>> /* Transform into expected order for display */
>> ch = (uint8_t *)(sharemem_output_base + 4);
>> for (i = 0; i < 12; i++)
>> buff[i + 4] = ch[11 - i];
>> }
>>
>>
>> Where P_AO_SEC_SD_CFG8 is offset (0x88<<2) of the AOBUS_BASE register.
> We already handle this in arch/arm/mach-meson/board-info.c
Really, I didn't look there.
>> The current uboot source code uses only the read 12 bytes as cpu serial ignoring the chipID and the existence of a 16-byte version of the serial number.
>>
>> Does it make sense to transfer the code to the uboot project?
>>
> How does it detect when 16 bytes serial is available ?
Call to sm function FN_CHIP_ID returns version number in uint32 at
beginning of result (shmem_output var in sm.c):
> int version = *((unsigned int *)sharemem_output_base);
if version == 2 then serial is next 16 bytes
for version == 1 then serial is next 12 bytes and amlogic suggests using chipid as an additional 4 bytes.
I have gxl and axg platform, there version is 1. Unfortunately I don't have more recent chipsets at hand to check if they have introduced version 2 on them.
> I'm not against this but I'm not sure when 16 bytes are available.
I'm not sure if the 16 bytes even exist at all or if this is just in case for future SoC.
--
Vyacheslav
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ARM: amlogic: RFC: meson_sm_get_serial secure call update
2021-10-07 12:11 ` Vyacheslav Bocharov
@ 2021-10-07 12:48 ` Neil Armstrong
2021-10-07 14:28 ` Vyacheslav Bocharov
0 siblings, 1 reply; 6+ messages in thread
From: Neil Armstrong @ 2021-10-07 12:48 UTC (permalink / raw)
To: Vyacheslav, u-boot-amlogic
On 07/10/2021 14:11, Vyacheslav wrote:
> 07.10.2021 11:13, Neil Armstrong пишет:
>> Hi,
>>
>> On 05/10/2021 11:35, Vyacheslav wrote:
>>> Hi.
>>>
>>> I am investigating the source code of uboot from amlogic and found differences in the function to get the cpu serial. In amlogic-uboot it looks like this:
>>>
>>> int version = *((unsigned int *)sharemem_output_base);
>>>
>>> if (version == 2) {
>>> memcpy(buff, (void *)sharemem_output_base + 4, 16);
>>> }
>>> else {
>>> /**
>>> * Legacy 12-byte chip ID read out, transform data
>>> * to expected order format.
>>> */
>>> uint32_t chip_info = readl(P_AO_SEC_SD_CFG8);
>>> uint8_t *ch;
>>> int i;
>>>
>>> ((uint32_t *)buff)[0] =
>>> ((chip_info & 0xff000000) | // Family ID
>>> ((chip_info << 8) & 0xff0000) | // Chip Revision
>>> ((chip_info >> 8) & 0xff00)); // Package ID
>>>
>>> ((uint32_t *)buff)[0] = htonl(((uint32_t *)buff)[0]);
>>>
>>> /* Transform into expected order for display */
>>> ch = (uint8_t *)(sharemem_output_base + 4);
>>> for (i = 0; i < 12; i++)
>>> buff[i + 4] = ch[11 - i];
>>> }
>>>
>>>
>>> Where P_AO_SEC_SD_CFG8 is offset (0x88<<2) of the AOBUS_BASE register.
>> We already handle this in arch/arm/mach-meson/board-info.c
> Really, I didn't look there.
>>> The current uboot source code uses only the read 12 bytes as cpu serial ignoring the chipID and the existence of a 16-byte version of the serial number.
>>>
>>> Does it make sense to transfer the code to the uboot project?
>>>
>> How does it detect when 16 bytes serial is available ?
>
> Call to sm function FN_CHIP_ID returns version number in uint32 at beginning of result (shmem_output var in sm.c):
>
>> int version = *((unsigned int *)sharemem_output_base);
>
> if version == 2 then serial is next 16 bytes
> for version == 1 then serial is next 12 bytes and amlogic suggests using chipid as an additional 4 bytes.
>
> I have gxl and axg platform, there version is 1. Unfortunately I don't have more recent chipsets at hand to check if they have introduced version 2 on them.
Seems to be a very recent addition, I get version 1 on S905Y2 (G12A), A311d (G12B) & S905D3 (SM1).
Neil
>
>> I'm not against this but I'm not sure when 16 bytes are available.
> I'm not sure if the 16 bytes even exist at all or if this is just in case for future SoC.
>
> --
> Vyacheslav
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ARM: amlogic: RFC: meson_sm_get_serial secure call update
2021-10-07 12:48 ` Neil Armstrong
@ 2021-10-07 14:28 ` Vyacheslav Bocharov
2021-10-08 13:28 ` Neil Armstrong
0 siblings, 1 reply; 6+ messages in thread
From: Vyacheslav Bocharov @ 2021-10-07 14:28 UTC (permalink / raw)
To: narmstrong, u-boot-amlogic
07.10.2021 15:48, Neil Armstrong пишет:
> On 07/10/2021 14:11, Vyacheslav wrote:
>> 07.10.2021 11:13, Neil Armstrong пишет:
>>> Hi,
>>>
>>> On 05/10/2021 11:35, Vyacheslav wrote:
>>>> Hi.
>>>>
>>>> I am investigating the source code of uboot from amlogic and found differences in the function to get the cpu serial. In amlogic-uboot it looks like this:
>>>>
>>>> int version = *((unsigned int *)sharemem_output_base);
>>>>
>>>> if (version == 2) {
>>>> memcpy(buff, (void *)sharemem_output_base + 4, 16);
>>>> The current uboot source code uses only the read 12 bytes as cpu serial ignoring the chipID and the existence of a 16-byte version of the serial number.
>>>>
>>>> Does it make sense to transfer the code to the uboot project?
>>>>
>>> How does it detect when 16 bytes serial is available ?
>> Call to sm function FN_CHIP_ID returns version number in uint32 at beginning of result (shmem_output var in sm.c):
>>
>>> int version = *((unsigned int *)sharemem_output_base);
>> if version == 2 then serial is next 16 bytes
>> for version == 1 then serial is next 12 bytes and amlogic suggests using chipid as an additional 4 bytes.
>>
>> I have gxl and axg platform, there version is 1. Unfortunately I don't have more recent chipsets at hand to check if they have introduced version 2 on them.
> Seems to be a very recent addition, I get version 1 on S905Y2 (G12A), A311d (G12B) & S905D3 (SM1).
>
I forgot that the argument of amlogic's getchip call was changed to 2. With
regs.regs[0] = FN_CHIP_ID;
regs.regs[1] = 2;
regs.regs[2] = 0;
I receive version == 2 on axg and gxl.
For example on gxl (only 96bits checked):
regs[1]=0
02000000: a7795fe3 d8f855af 14c30b56 00000000 ._y..U..V.......
regs[1]=2
02000000: 00a40d21 560bc314 af55f8d8 e35f79a7 .......V..U..y_.
We have same serial with reversed byte order.
Change introduced in 2017 with comment:
GX-family chips (e.g. GXB, GXL) supports a 128-bit chip ID.
128-bit chip ID consists 32-bit SoC version and 96-bit OTP data.
BL30 provides a SoC command to obtain the chip ID value.
Legacy implementation only returns 96-bit OTP data and requires
the construction of the 128-bit by the caller.
This change updates the implementation to return the constructed
128-bit chip ID while maintain backward compatibility with existing
software.
--
Vyacheslav
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ARM: amlogic: RFC: meson_sm_get_serial secure call update
2021-10-07 14:28 ` Vyacheslav Bocharov
@ 2021-10-08 13:28 ` Neil Armstrong
0 siblings, 0 replies; 6+ messages in thread
From: Neil Armstrong @ 2021-10-08 13:28 UTC (permalink / raw)
To: Vyacheslav, u-boot-amlogic
Hi,
On 07/10/2021 16:28, Vyacheslav wrote:
> 07.10.2021 15:48, Neil Armstrong пишет:
>> On 07/10/2021 14:11, Vyacheslav wrote:
>>> 07.10.2021 11:13, Neil Armstrong пишет:
>>>> Hi,
>>>>
>>>> On 05/10/2021 11:35, Vyacheslav wrote:
>>>>> Hi.
>>>>>
>>>>> I am investigating the source code of uboot from amlogic and found differences in the function to get the cpu serial. In amlogic-uboot it looks like this:
>>>>>
>>>>> int version = *((unsigned int *)sharemem_output_base);
>>>>>
>>>>> if (version == 2) {
>>>>> memcpy(buff, (void *)sharemem_output_base + 4, 16);
>>>>> The current uboot source code uses only the read 12 bytes as cpu serial ignoring the chipID and the existence of a 16-byte version of the serial number.
>>>>>
>>>>> Does it make sense to transfer the code to the uboot project?
>>>>>
>>>> How does it detect when 16 bytes serial is available ?
>>> Call to sm function FN_CHIP_ID returns version number in uint32 at beginning of result (shmem_output var in sm.c):
>>>
>>>> int version = *((unsigned int *)sharemem_output_base);
>>> if version == 2 then serial is next 16 bytes
>>> for version == 1 then serial is next 12 bytes and amlogic suggests using chipid as an additional 4 bytes.
>>>
>>> I have gxl and axg platform, there version is 1. Unfortunately I don't have more recent chipsets at hand to check if they have introduced version 2 on them.
>> Seems to be a very recent addition, I get version 1 on S905Y2 (G12A), A311d (G12B) & S905D3 (SM1).
>>
> I forgot that the argument of amlogic's getchip call was changed to 2. With
>
> regs.regs[0] = FN_CHIP_ID;
> regs.regs[1] = 2;
> regs.regs[2] = 0;
>
> I receive version == 2 on axg and gxl.
>
> For example on gxl (only 96bits checked):
>
> regs[1]=0
> 02000000: a7795fe3 d8f855af 14c30b56 00000000 ._y..U..V.......
>
> regs[1]=2
> 02000000: 00a40d21 560bc314 af55f8d8 e35f79a7 .......V..U..y_.
>
> We have same serial with reversed byte order.
Interesting, but since the current serial based mac generation is based
on the 96bits current serial, adding support for the new 16bytes serial
will change the mac on the boards.
Not sure how to handle that.
Anyway, a patch is welcome to add support for that !
Neil
>
> Change introduced in 2017 with comment:
>
> GX-family chips (e.g. GXB, GXL) supports a 128-bit chip ID.
> 128-bit chip ID consists 32-bit SoC version and 96-bit OTP data.
>
> BL30 provides a SoC command to obtain the chip ID value.
>
> Legacy implementation only returns 96-bit OTP data and requires
> the construction of the 128-bit by the caller.
>
> This change updates the implementation to return the constructed
> 128-bit chip ID while maintain backward compatibility with existing
>
> software.
>
> --
>
> Vyacheslav
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-10-08 13:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-05 9:35 ARM: amlogic: RFC: meson_sm_get_serial secure call update Vyacheslav Bocharov
2021-10-07 8:13 ` Neil Armstrong
2021-10-07 12:11 ` Vyacheslav Bocharov
2021-10-07 12:48 ` Neil Armstrong
2021-10-07 14:28 ` Vyacheslav Bocharov
2021-10-08 13:28 ` Neil Armstrong
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.