From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Date: Tue, 22 Oct 2019 14:54:07 +0200 Subject: [U-Boot] [PATCH 1/3] cmd: fru: Add support for FRU commands In-Reply-To: References: <299fbc3c72c46ceb1b03fb2843876ff3e2f255ca.1571059750.git.michal.simek@xilinx.com> Message-ID: <2ef49072-fa47-efba-b7c2-cf9e45828d66@xilinx.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de On 22. 10. 19 14:40, Jean-Jacques Hiblot wrote: > > On 14/10/2019 15:29, Michal Simek wrote: >> From: Siva Durga Prasad Paladugu >> >> This patch adds support for fru commands "fru capture" and "fru display". >> The fru capture parses the FRU table present at an address and stores >> in a >> structure for later use. The fru display prints the content of captured >> structured in a readable format. >> >> As of now, it supports only common header and board area of FRU. Also, it >> supports only English language code and ASCII8 format. >> >> fru_data variable is placed to data section because fru parser can be >> called very early before bss is initialized. And also information >> needs to >> be shared that's why it is exported via header. >> >> Signed-off-by: Siva Durga Prasad Paladugu >> >> Signed-off-by: Michal Simek >> --- >> >>   MAINTAINERS      |   3 + >>   cmd/Kconfig      |   8 ++ >>   cmd/Makefile     |   1 + >>   cmd/fru.c        |  68 +++++++++++++ >>   common/Makefile  |   1 + >>   common/fru_ops.c | 247 +++++++++++++++++++++++++++++++++++++++++++++++ >>   include/fru.h    |  64 ++++++++++++ >>   7 files changed, 392 insertions(+) >>   create mode 100644 cmd/fru.c >>   create mode 100644 common/fru_ops.c >>   create mode 100644 include/fru.h >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 2ef29768555c..420ce26cd0aa 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -404,6 +404,9 @@ M:    Michal Simek >>   S:    Maintained >>   T:    git >> https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze.git >>   F:    arch/arm/mach-versal/ >> +F:    cmd/fru.c >> +F:    common/fru_ops.c >> +F:    include/fru.h >>   N:    (?>     ARM VERSATILE EXPRESS DRIVERS >> diff --git a/cmd/Kconfig b/cmd/Kconfig >> index 07060c63a7e6..68815e42641e 100644 >> --- a/cmd/Kconfig >> +++ b/cmd/Kconfig >> @@ -1688,6 +1688,14 @@ config CMD_UUID >>         The two commands are very similar except for the endianness of >> the >>         output. >>   +config CMD_FRU >> +    bool "FRU information for product" >> +    help >> +      This option enables FRU commands to capture and display FRU >> +      information present in the device. The FRU Information is used >> +      to primarily to provide "inventory" information about the boards >> +      that the FRU Information Device is located on. >> + >>   endmenu >>     source "cmd/ti/Kconfig" >> diff --git a/cmd/Makefile b/cmd/Makefile >> index ac843b4b16ad..f790217dd628 100644 >> --- a/cmd/Makefile >> +++ b/cmd/Makefile >> @@ -43,6 +43,7 @@ obj-$(CONFIG_DATAFLASH_MMC_SELECT) += >> dataflash_mmc_mux.o >>   obj-$(CONFIG_CMD_DATE) += date.o >>   obj-$(CONFIG_CMD_DEMO) += demo.o >>   obj-$(CONFIG_CMD_DM) += dm.o >> +obj-$(CONFIG_CMD_FRU) += fru.o >>   obj-$(CONFIG_CMD_SOUND) += sound.o >>   ifdef CONFIG_POST >>   obj-$(CONFIG_CMD_DIAG) += diag.o >> diff --git a/cmd/fru.c b/cmd/fru.c >> new file mode 100644 >> index 000000000000..d5e96cfe8984 >> --- /dev/null >> +++ b/cmd/fru.c >> @@ -0,0 +1,68 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * (C) Copyright 2019 Xilinx, Inc. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> + >> +static int do_fru_capture(cmd_tbl_t *cmdtp, int flag, int argc, >> +              char *const argv[]) >> +{ >> +    unsigned long addr; >> +    char *endp; >> + >> +    if (argc < cmdtp->maxargs) >> +        return CMD_RET_USAGE; >> + >> +    addr = simple_strtoul(argv[2], &endp, 16); >> +    if (*argv[1] == 0 || *endp != 0) >> +        return -1; >> + >> +    return fru_capture(addr); >> +} >> + >> +static int do_fru_display(cmd_tbl_t *cmdtp, int flag, int argc, >> +              char *const argv[]) >> +{ >> +    fru_display(); >> +    return CMD_RET_SUCCESS; >> +} >> + >> +static cmd_tbl_t cmd_fru_sub[] = { >> +    U_BOOT_CMD_MKENT(capture, 3, 0, do_fru_capture, "", ""), >> +    U_BOOT_CMD_MKENT(display, 2, 0, do_fru_display, "", ""), >> +}; > > Why not do the capture in "fru display" itself ? And maybe provide the > ability to display a FRU read from an EEPROM? Sure we can do it but I think there are two separate things. Especially if you don't need to show content. >> + >> +static int do_fru(cmd_tbl_t *cmdtp, int flag, int argc, >> +          char *const argv[]) >> +{ >> +    cmd_tbl_t *c; >> + >> +    if (argc < 2) >> +        return CMD_RET_USAGE; >> + >> +    c = find_cmd_tbl(argv[1], &cmd_fru_sub[0], >> +             ARRAY_SIZE(cmd_fru_sub)); >> +    if (c) >> +        return c->cmd(c, flag, argc, argv); >> + >> +    return CMD_RET_USAGE; >> +} >> + >> +/***************************************************/ >> +#ifdef CONFIG_SYS_LONGHELP >> +static char fru_help_text[] = >> +    "capture - Parse and capture FRU table present at address.\n" >> +    "fru display - Displays content of FRU table that was captured >> using\n" >> +    "              fru capture command\n" >> +    ; >> +#endif >> + >> +U_BOOT_CMD( >> +    fru, 3, 1, do_fru, >> +    "FRU table info", >> +    fru_help_text >> +) >> diff --git a/common/Makefile b/common/Makefile >> index 302d8beaf356..10cbe9a15ea1 100644 >> --- a/common/Makefile >> +++ b/common/Makefile >> @@ -57,6 +57,7 @@ obj-$(CONFIG_UPDATE_TFTP) += update.o >>   obj-$(CONFIG_DFU_TFTP) += update.o >>   obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o >>   obj-$(CONFIG_CMDLINE) += cli_readline.o cli_simple.o >> +obj-$(CONFIG_CMD_FRU) += fru_ops.o >>     endif # !CONFIG_SPL_BUILD >>   diff --git a/common/fru_ops.c b/common/fru_ops.c >> new file mode 100644 >> index 000000000000..dd54bd9c0214 >> --- /dev/null >> +++ b/common/fru_ops.c >> @@ -0,0 +1,247 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * (C) Copyright 2019 Xilinx, Inc. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +struct fru_table fru_data  __attribute__((section(".data"))); > > Isn't it restrictive to have only a single instance of struct fru_table > ? Could there be multiple ? You can have multiple FRUs but only one which is valid at that time and which also fru_addr is pointing to. Thanks, Michal