[RFC PATCH 1/2] cmd/fru: cmd/fru: move FRU handling support to common region

Jae Hyun Yoo quic_jaehyoo at quicinc.com
Fri Jul 29 17:00:19 CEST 2022


Hello Michal,

On 7/29/2022 7:38 AM, Jae Hyun Yoo wrote:
> On 7/29/2022 4:13 AM, Michal Simek wrote:
>> The main reason why I didn't added to generic location was that in 
>> board field there are xilinx specific custom fields.
>> With other vendor this won't work.
>> I think this should be solved before this code can be moved to generic 
>> location.
>>
>> Also maybe make sense to move and spec that variable creation.
> 
> Yes, I realized that the Xilinx specific customization was added into
> the standard board info area so actually it breaks the spec.
> 
> struct fru_board_data {
>          [....]
> 
>      /* Xilinx custom fields */
>      u8 rev_type_len;
>      u8 rev[FRU_BOARD_MAX_LEN];
>      u8 pcie_type_len;
>      u8 pcie[FRU_BOARD_MAX_LEN];
>      u8 uuid_type_len;
>      u8 uuid[FRU_BOARD_MAX_LEN];
> };
> 
> I think, this type of customization should be added using multirecords
> instead of expanding the common board info structure, and it's the
> reason why the FRU spec provides OEM multirecord types (0xc0 - 0xff).
> Do you have any plan to replace them with OEM multirecords?

I reviewed the spec again and checked that adding additional info fields
is also acceptable by the spec. Let me try to refine the current code to
make it parse the additional custom info fields in a generic way.

Thanks,
Jae

> Thanks,
> Jae


More information about the U-Boot mailing list