On 22. 10. 19 14:40, Jean-Jacques Hiblot wrote:
On 14/10/2019 15:29, Michal Simek wrote:
From: Siva Durga Prasad Paladugu siva.durga.paladugu@xilinx.com
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 siva.durga.paladugu@xilinx.com Signed-off-by: Michal Simek michal.simek@xilinx.com
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 michal.simek@xilinx.com 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: (?<!uni)versal 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 <common.h> +#include <fdtdec.h> +#include <malloc.h> +#include <fru.h>
+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 <addr> - 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 <common.h> +#include <fdtdec.h> +#include <fru.h> +#include <malloc.h> +#include <asm/io.h> +#include <asm/arch/hardware.h>
+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