Re: [U-Boot] [PATCH v3 1/2] usb: net: Add support for Microchip LAN75xx and LAN78xx
On 08/09/2017 07:47 PM, Joe Hershberger wrote: > On Wed, Aug 9, 2017 at 12:12 PM, Marek Vasut wrote: >> On 08/09/2017 06:25 PM, yuiko.osh...@microchip.com wrote: >>> From: Yuiko Oshino >>> >>> Series-Changes: 3 >> >> FYI, this will end in the commit message when applied, remove it or move >> it below the --- . Also commit message is missing. > > This is what I was talking about when I said I would fix the commit > log as I apply it. I have a few more comments though, but feel free to fix them up too. >>>- All #ifdef CONFIG_DM_ETH and #endif are removed. >>>- The lan7x_eth_recv() is modifed to correctly support the Driver Model >>> and returns packet_en. >>>- Add mii_resolve_flowctrl_fdx() patch in the series. >>> >>> Series-Changes: 2 >>>- The wait_for_bit functions copy the real one. >>>- Uses phylib >>>- Unnecessary variables are removed >>>- All return values are checked >>>- Uses mii_resolve_flowctrl_fdx() from linux/mii.h >>> >>> Signed-off-by: Yuiko Oshino >>> --- >>> Add support for Microchip LAN7500, LAN7800 and LAN7850, >>> USB to 10/100/1000 Ethernet Controllers. >>> -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/10] This patch set represent Marvell mvpp2 driver fixes
Hi Joe, On 09.08.2017 17:24, Joe Hershberger wrote: On Wed, Aug 9, 2017 at 12:56 AM, Stefan Roese wrote: Hi Joe, On 08.08.2017 17:57, Joe Hershberger wrote: Hi Stefan (and Stefan), On Tue, Aug 8, 2017 at 7:05 AM, Stefan Roese wrote: Hi Joe, On 11.07.2017 10:04, Stefan Roese wrote: On 21.06.2017 10:31, stef...@malvell.com wrote: Huh? Sent from a typo email address? Where is the problem with the Stefan Chulski's email address? Sorry, I can't spot it. Just above and in the reply-to of the messages: stefanc@ma>l Ah, thanks. That's pretty tedious. I recommend fixing your git config. And if that's fine, I recommend using patman so this won't happen again. From: Stefan Chulski Issues were found during internal QA phase. Stefan Chulski (10): net: mvpp2x: Add GPIO configuration support net: mvpp2x: fix phy connected to wrong mdio issue net: mvpp2x: Enable GoP packet padding in TX net: mvpp2x: fix BM configuration overrun issue net: mvpp2x: decrease size of AGGR_TXQ and CPU_DESC_CHUNK net: mvpp2x: remove MBUS configurations from MvPP22 driver net: mvpp2x: Remove IRQ configuration from u-boot net: mvpp2x: Set BM pool high address net: mvpp2x: remove TX drain from transmit routine net: mvpp2x: Set BM poll size once during priv probe drivers/net/mvpp2.c | 189 ++-- 1 file changed, 94 insertions(+), 95 deletions(-) Joe, do you have any comments on these mvpp2 patches? Gently ping on these patches again. Joe, do you have any comments on these? Do you want to take these patches via your tree? Or should I push them if you don't have any objections? Reviewing now. I generally use patchwork to remember what I have to do. I guess if I didn't rely on that I would set up better work queue email filters. Sorry for the delay. I figured since the series is assigned to you in PW, that you wanted it through your tree. I'm fine either way. I assume that Tom assigned them to me (I didn't do it at least). But I can definitely pull these patches via the Marvell tree, once all open issues are resolved and all patches have your Acked-by tag. Sounds good! Great. I'm build testing right now and will send the pull request, once this has finished without any issues. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] mmc: uniphier-sd: Factor out register IO
Hi. 2017-08-07 17:30 GMT+09:00 Marek Vasut : > On 08/07/2017 04:30 AM, Masahiro Yamada wrote: >> Hi Marek, > > Hi Masahiro, > > This is gonna be a great discussion, let's wrestle about consts and ints :-) > >> 2017-08-06 4:23 GMT+09:00 Marek Vasut : >>> On 08/03/2017 02:36 PM, Masahiro Yamada wrote: Hi Marek, >>> >>> Hi, >>> >>> [...] >>> > +static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, const u32 > reg) "const" is unneeded here. >>> >>> Why? The function should not modify reg , so it is const. >> >> >> Because "const" is useless here. >> >> The "reg" is not a pointer, so it is obvious >> that there is no impact to the callers. >> >> >> >> Moreover, whether "reg" is constant or not >> depends on how you implement the function. >> >> >> If you force "const" to the argument, the only choice for the implementation >> will be as follows: >> >> >> >> static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, const u32 reg) >> { >> if (priv->caps & UNIPHIER_SD_CAP_64BIT) >> return readl(priv->regbase + (reg << 1)); >> else >> return readl(priv->regbase + reg); >> } >> >> >> >> If you want to implement the function as follows, you need to drop "const". >> >> static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, u32 reg) >> { >> if (priv->caps & UNIPHIER_SD_CAP_64BIT) >> reg <<= 1; >> >> return readl(priv->regbase + reg); >> } > > My argument would be that the const prevents you from accidentally > modifying the $reg inside the function. No. The arguments of a functions are local variables. No impact on the outside of the scope of the function. If you accidentally modify a variable where it should not, it is a bug. Just fix it. If you want to wrestle more, please do it in LKML by adding around "const". For example, drivers/base/regmap/regmap.c: int regmap_write(struct regmap *map, unsigned int reg, unsigned int val) arch/arm/include/asm/io.h: static inline void __raw_writel(u32 val, volatile void __iomem *addr) -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 5/7] spl: add serial download protocol (SDP) support
Hi Stefan, On 09/08/2017 02:59, Stefan Agner wrote: > Stefano, > > One question below: > > On 2017-08-04 16:38, Stefan Agner wrote: >> From: Stefan Agner >> >> Add USB serial download protocol support to SPL. If the SoC started >> in recovery mode the SPL will immediately switch to SDP and wait for >> further downloads/commands from the host side. >> >> Signed-off-by: Stefan Agner >> --- >> >> common/spl/Kconfig | 6 ++ >> common/spl/Makefile | 1 + >> common/spl/spl_sdp.c| 38 ++ >> drivers/usb/gadget/Makefile | 1 + >> 4 files changed, 46 insertions(+) >> create mode 100644 common/spl/spl_sdp.c >> >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig >> index 4de81392b0..95378b98a0 100644 >> --- a/common/spl/Kconfig >> +++ b/common/spl/Kconfig >> @@ -646,6 +646,12 @@ config SPL_DFU_RAM >> >> endchoice >> >> +config SPL_USB_SDP_SUPPORT >> +bool "Support SDP (Serial Download Protocol)" >> +help >> + Enable Serial Download Protocol (SDP) device support in SPL. This >> + allows to download images into memory and execute (jump to) them >> + using the same protocol as implemented by the i.MX family's boot ROM. >> endif >> >> config SPL_WATCHDOG_SUPPORT >> diff --git a/common/spl/Makefile b/common/spl/Makefile >> index 47a64dd7d0..a979560acf 100644 >> --- a/common/spl/Makefile >> +++ b/common/spl/Makefile >> @@ -29,4 +29,5 @@ obj-$(CONFIG_SPL_SATA_SUPPORT) += spl_sata.o >> obj-$(CONFIG_SPL_DFU_SUPPORT) += spl_dfu.o >> obj-$(CONFIG_SPL_SPI_LOAD) += spl_spi.o >> obj-$(CONFIG_SPL_RAM_SUPPORT) += spl_ram.o >> +obj-$(CONFIG_SPL_USB_SDP_SUPPORT) += spl_sdp.o >> endif >> diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c >> new file mode 100644 >> index 00..faa74b8bec >> --- /dev/null >> +++ b/common/spl/spl_sdp.c >> @@ -0,0 +1,38 @@ >> +/* >> + * (C) Copyright 2016 Toradex >> + * Author: Stefan Agner >> + * >> + * SPDX-License-Identifier: GPL-2.0+ >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +DECLARE_GLOBAL_DATA_PTR; >> + >> +static int spl_sdp_load_image(struct spl_image_info *spl_image, >> + struct spl_boot_device *bootdev) >> +{ >> +int ret; >> + >> +g_dnl_clear_detach(); >> +g_dnl_register("usb_dnl_sdp"); >> + >> +ret = sdp_init(); >> +if (ret) { >> +error("SDP init failed: %d", ret); >> +return -ENODEV; >> +} >> + >> +ret = sdp_handle(); >> +if (ret) { >> +error("SDP failed: %d", ret); >> +return -ENODEV; >> +} >> + >> +return 0; >> +} >> +SPL_LOAD_IMAGE_METHOD("USB SDP", 0, BOOT_DEVICE_UART, spl_sdp_load_image); > > > We currently use BOOT_DEVICE_UART when serial downloader boot mode is > detected. This can be either USB or UART... > Right > In fact, USB is probably much more often used since only 6UL/ULL have > UART serial downloader support afact... The misunderstanding is originated from NXP's documentation. The official name is "Serial Downloader" and this can be easy confused as "UART" downloader. Even if documentation is correct, it can be bad interpreted. To be correct, we have a "serial protocol" over a device that can be either USB or UART. > > There is BOOT_DEVICE_BOARD which is used by e.g. Sunxi in case the boot > ROM mechanism is used, what do you think, should be change that? Good point. To be consistent (thanks for hint, I was not aware of this in sunxi) we should change it, yes. > > Ideally we should be able to discriminate between USB and UART. But I > don't think its possible... (the USBPH0_PWD method likely does not work > since even in the UART case the boot ROM will initialize the USB PHY > first, at least according to the flow diagram in ULL's Chapter 9...) I agree with you - we should get rid of undocumented feature inside ROM, whose behaviour could be changed with SOC revision number. The use case is fixed - if a board loads from USB, it will always load from USB. A runtime detection is difficult and even overkilling for this application. > > The i.MX 7 which has the new Boot Information block actually only > support USB serial downloader... > > Thoughts? As far as I can see and apart of names, we should reach to have this mainlined as USB downloader. It covers quite all cases. Best regards, Stefano > > -- > Stefan > > >> diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile >> index 6a007d1bcb..7258099c1c 100644 >> --- a/drivers/usb/gadget/Makefile >> +++ b/drivers/usb/gadget/Makefile >> @@ -11,6 +11,7 @@ obj-$(CONFIG_USB_ETHER) += epautoconf.o config.o >> usbstring.o >> ifdef CONFIG_SPL_BUILD >> obj-$(CONFIG_SPL_USB_GADGET_SUPPORT) += g_dnl.o >> obj-$(CONFIG_SPL_DFU_SUPPORT) += f_dfu.o >> +obj-$(CONFIG_SPL_USB_SDP_SUPPORT) += f_sdp.o >> endif >> >> # new USB gadget layer dependencies -- ===
Re: [U-Boot] [PATCH v1 2/7] usb: gadget: add SDP driver
Hi Stefan, On 05/08/2017 01:38, Stefan Agner wrote: > From: Stefan Agner > > Add SDP (Serial Downloader Protocol) implementation for U-Boot. The > protocol is used in NXP SoC's boot ROM and allows to download program > images. Beside that, it can also be used to read/write registers and > download complete Device Configuration Data (DCD) sets. This basic > implementation supports downloading images with the imx header format > and reading registers. > > Signed-off-by: Stefan Agner > --- > > drivers/usb/gadget/Kconfig | 7 + > drivers/usb/gadget/Makefile | 1 + > drivers/usb/gadget/f_sdp.c | 723 > > include/sdp.h | 16 + > 4 files changed, 747 insertions(+) > create mode 100644 drivers/usb/gadget/f_sdp.c > create mode 100644 include/sdp.h > > diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig > index 261ed128ac..225b66bc95 100644 > --- a/drivers/usb/gadget/Kconfig > +++ b/drivers/usb/gadget/Kconfig > @@ -103,6 +103,13 @@ config USB_GADGET_DOWNLOAD > > if USB_GADGET_DOWNLOAD > > +config USB_FUNCTION_SDP > + bool "Enable USB SDP (Serial Download Protocol)" > + help > + Enable Serial Download Protocol (SDP) device support in U-Boot. This > + allows to download images into memory and execute (jump to) them > + using the same protocol as implemented by the i.MX family's boot ROM. > + > config G_DNL_MANUFACTURER > string "Vendor name of USB device" > > diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile > index 5e316a7cff..6a007d1bcb 100644 > --- a/drivers/usb/gadget/Makefile > +++ b/drivers/usb/gadget/Makefile > @@ -28,6 +28,7 @@ obj-$(CONFIG_USB_FUNCTION_THOR) += f_thor.o > obj-$(CONFIG_USB_FUNCTION_DFU) += f_dfu.o > obj-$(CONFIG_USB_FUNCTION_MASS_STORAGE) += f_mass_storage.o > obj-$(CONFIG_USB_FUNCTION_FASTBOOT) += f_fastboot.o > +obj-$(CONFIG_USB_FUNCTION_SDP) += f_sdp.o > endif > endif > ifdef CONFIG_USB_ETHER > diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c > new file mode 100644 > index 00..eb89695aaf > --- /dev/null > +++ b/drivers/usb/gadget/f_sdp.c > @@ -0,0 +1,723 @@ > +/* > + * f_sdp.c -- USB HID Serial Download Protocol > + * > + * Copyright (C) 2016 Toradex > + * Author: Stefan Agner > + * > + * This file implements the Serial Download Protocol (SDP) as specified in > + * the i.MX 6 Reference Manual. The SDP is a USB HID based protocol and > + * allows to download images directly to memory. The implementation > + * works with the imx_loader (imx_usb) USB client software on host side. > + * > + * Not all commands are implemented, e.g. WRITE_REGISTER, DCD_WRITE and > + * SKIP_DCD_HEADER are only stubs. > + * > + * Parts of the implementation are based on f_dfu and f_thor. > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > + > +#define HID_REPORT_ID_MASK 0x00ff > + > +/* > + * HID class requests > + */ > +#define HID_REQ_GET_REPORT 0x01 > +#define HID_REQ_GET_IDLE 0x02 > +#define HID_REQ_GET_PROTOCOL 0x03 > +#define HID_REQ_SET_REPORT 0x09 > +#define HID_REQ_SET_IDLE 0x0A > +#define HID_REQ_SET_PROTOCOL 0x0B > + > +#define HID_USAGE_PAGE_LEN 76 > + > +struct hid_report { > + u8 usage_page[HID_USAGE_PAGE_LEN]; > +} __packed; > + > +#define SDP_READ_REGISTER0x0101 > +#define SDP_WRITE_REGISTER 0x0202 > +#define SDP_WRITE_FILE 0x0404 > +#define SDP_ERROR_STATUS 0x0505 > +#define SDP_DCD_WRITE0x0a0a > +#define SDP_JUMP_ADDRESS 0x0b0b > +#define SDP_SKIP_DCD_HEADER 0x0c0c It looks like that I am again out of sync with documentation. Where is defined SDP_SKIP_DCD_HEADER ? It is undefined for MX6Q/D, Solo and DL. > + > +#define SDP_WRITE_FILE_COMPLETE 0x > +#define SDP_WRITE_REGISTER_COMPLETE 0x128A8A12 > +#define SDP_SKIP_DCD_HEADER_COMPLETE 0x900DD009 > +#define SDP_ERROR_IMXHEADER 0x000a0533 > + > +#define SDP_COMMAND_LEN 16 > + > +struct sdp_command { > + u16 cmd; > + u32 addr; > + u8 format; > + u32 cnt; > + u32 data; > + u8 rsvd; > +} __packed; > + > +enum sdp_state { > + SDP_STATE_IDLE, > + SDP_STATE_RX_DCD_DATA, > + SDP_STATE_RX_FILE_DATA, > + SDP_STATE_TX_SEC_CONF, > + SDP_STATE_TX_SEC_CONF_BUSY, > + SDP_STATE_TX_REGISTER, > + SDP_STATE_TX_REGISTER_BUSY, > + SDP_STATE_TX_STATUS, > + SDP_STATE_TX_STATUS_BUSY, > + SDP_STATE_JUMP, > +}; > + > +struct f_sdp { > + struct usb_function usb_function; > + > + struct usb_descriptor_header**function; > + > + u8 altsetting; > + enum sdp_state state; > + enum sdp_state next_state; > + u
Re: [U-Boot] [PATCH v1 3/7] usb: gadget: sdp: extend images compatible for jumps
On 05/08/2017 01:38, Stefan Agner wrote: > From: Stefan Agner > > Support U-Boot images in SPL so that u-boot.img files can be > directly downloaded and executed. Furthermore support U-Boot > scripts download and execution in full U-Boot so that custom > recovery actions can be downloaded from the host in a third > step. > > Signed-off-by: Stefan Agner > --- > > drivers/usb/gadget/f_sdp.c | 20 ++-- > 1 file changed, 18 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c > index eb89695aaf..9a752843f0 100644 > --- a/drivers/usb/gadget/f_sdp.c > +++ b/drivers/usb/gadget/f_sdp.c > @@ -29,6 +29,8 @@ > #include > #include > #include > +#include > +#include > #include > > #define HID_REPORT_ID_MASK 0x00ff > @@ -672,8 +674,22 @@ static void sdp_handle_in_ep(void) > sdp_func->state = SDP_STATE_TX_REGISTER_BUSY; > break; > case SDP_STATE_JUMP: > - printf("Checking imxheader at 0x%08x\n", f_sdp->jmp_address); > - status = sdp_jump_imxheader((void *)f_sdp->jmp_address); > + printf("Jumping to header at 0x%08x\n", sdp_func->jmp_address); > + status = sdp_jump_imxheader((void *)sdp_func->jmp_address); > + > + /* If imx header fails, try some U-Boot specific headers */ > + if (status) { > +#ifdef CONFIG_SPL_BUILD > + /* In SPL, allow jumps to U-Boot images */ > + struct spl_image_info spl_image = {}; > + spl_parse_image_header(&spl_image, > + (struct image_header *)sdp_func->jmp_address); > + jump_to_image_no_args(&spl_image); > +#else > + /* In U-Boot, allow jumps to scripts */ > + source(sdp_func->jmp_address, "script@1"); > +#endif > + } > > sdp_func->next_state = SDP_STATE_IDLE; > sdp_func->error_status = status; > Reviewed-by: Stefano Babic Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 4/7] cmd: add sdp command
Hi Stefan, On 05/08/2017 01:38, Stefan Agner wrote: > From: Stefan Agner > > Add a new command to start USB Serial Download Protocol (SDP) > state machine. > > Signed-off-by: Stefan Agner > --- > > cmd/Kconfig | 7 +++ > cmd/Makefile | 1 + > cmd/usb_gadget_sdp.c | 53 > > 3 files changed, 61 insertions(+) > create mode 100644 cmd/usb_gadget_sdp.c > > diff --git a/cmd/Kconfig b/cmd/Kconfig > index f18efc1e88..87333b3a97 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -665,6 +665,13 @@ config CMD_DFU > Enables the command "dfu" which is used to have U-Boot create a DFU > class device via USB. > > +config CMD_USB_SDP > + bool "sdp" > + select USB_FUNCTION_SDP > + help > + Enables the command "sdp" which is used to have U-Boot emulating the > + Serial Download Protocol (SDP) via USB. > + > config CMD_USB_MASS_STORAGE > bool "UMS usb mass storage" > help > diff --git a/cmd/Makefile b/cmd/Makefile > index bd231f24d8..e0b5940ba6 100644 > --- a/cmd/Makefile > +++ b/cmd/Makefile > @@ -131,6 +131,7 @@ obj-$(CONFIG_CMD_FASTBOOT) += fastboot.o > obj-$(CONFIG_CMD_FS_UUID) += fs_uuid.o > > obj-$(CONFIG_CMD_USB_MASS_STORAGE) += usb_mass_storage.o > +obj-$(CONFIG_CMD_USB_SDP) += usb_gadget_sdp.o > obj-$(CONFIG_CMD_THOR_DOWNLOAD) += thordown.o > obj-$(CONFIG_CMD_XIMG) += ximg.o > obj-$(CONFIG_YAFFS2) += yaffs2.o > diff --git a/cmd/usb_gadget_sdp.c b/cmd/usb_gadget_sdp.c > new file mode 100644 > index 00..09ddb4f3aa > --- /dev/null > +++ b/cmd/usb_gadget_sdp.c > @@ -0,0 +1,53 @@ > +/* > + * cmd_sdp.c -- sdp command > + * > + * Copyright (C) 2016 Toradex > + * Author: Stefan Agner > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > + > +static int do_sdp(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) > +{ > + int ret = CMD_RET_SUCCESS; > + > + if (argc < 2) > + return CMD_RET_USAGE; > + > + char *usb_controller = argv[1]; > + int controller_index = simple_strtoul(usb_controller, NULL, 0); > + board_usb_init(controller_index, USB_INIT_DEVICE); > + > + g_dnl_clear_detach(); > + g_dnl_register("usb_dnl_sdp"); > + > + ret = sdp_init(); > + if (ret) { > + error("SDP init failed: %d", ret); > + ret = CMD_RET_FAILURE; > + goto exit; > + } > + > + ret = sdp_handle(); > + if (ret) { > + error("SDP failed: %d", ret); > + ret = CMD_RET_FAILURE; > + goto exit; > + } > + > +exit: > + g_dnl_unregister(); > + > + return ret; > +} > + > +U_BOOT_CMD(sdp, 2, 1, do_sdp, > + "Serial Downloader Protocol", > + "\n" > + " - serial downloader protocol via \n" > +); > Reviewed-by: Stefano Babic Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 5/7] spl: add serial download protocol (SDP) support
Hi Stefan, On 05/08/2017 01:38, Stefan Agner wrote: > From: Stefan Agner > > Add USB serial download protocol support to SPL. If the SoC started > in recovery mode the SPL will immediately switch to SDP and wait for > further downloads/commands from the host side. > > Signed-off-by: Stefan Agner > --- > > common/spl/Kconfig | 6 ++ > common/spl/Makefile | 1 + > common/spl/spl_sdp.c| 38 ++ > drivers/usb/gadget/Makefile | 1 + > 4 files changed, 46 insertions(+) > create mode 100644 common/spl/spl_sdp.c > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > index 4de81392b0..95378b98a0 100644 > --- a/common/spl/Kconfig > +++ b/common/spl/Kconfig > @@ -646,6 +646,12 @@ config SPL_DFU_RAM > > endchoice > > +config SPL_USB_SDP_SUPPORT > + bool "Support SDP (Serial Download Protocol)" > + help > + Enable Serial Download Protocol (SDP) device support in SPL. This > + allows to download images into memory and execute (jump to) them > + using the same protocol as implemented by the i.MX family's boot ROM. > endif > > config SPL_WATCHDOG_SUPPORT > diff --git a/common/spl/Makefile b/common/spl/Makefile > index 47a64dd7d0..a979560acf 100644 > --- a/common/spl/Makefile > +++ b/common/spl/Makefile > @@ -29,4 +29,5 @@ obj-$(CONFIG_SPL_SATA_SUPPORT) += spl_sata.o > obj-$(CONFIG_SPL_DFU_SUPPORT) += spl_dfu.o > obj-$(CONFIG_SPL_SPI_LOAD) += spl_spi.o > obj-$(CONFIG_SPL_RAM_SUPPORT) += spl_ram.o > +obj-$(CONFIG_SPL_USB_SDP_SUPPORT) += spl_sdp.o > endif > diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c > new file mode 100644 > index 00..faa74b8bec > --- /dev/null > +++ b/common/spl/spl_sdp.c > @@ -0,0 +1,38 @@ > +/* > + * (C) Copyright 2016 Toradex > + * Author: Stefan Agner > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +DECLARE_GLOBAL_DATA_PTR; > + > +static int spl_sdp_load_image(struct spl_image_info *spl_image, > + struct spl_boot_device *bootdev) > +{ > + int ret; > + > + g_dnl_clear_detach(); > + g_dnl_register("usb_dnl_sdp"); > + > + ret = sdp_init(); > + if (ret) { > + error("SDP init failed: %d", ret); > + return -ENODEV; > + } > + > + ret = sdp_handle(); > + if (ret) { > + error("SDP failed: %d", ret); > + return -ENODEV; > + } > + > + return 0; > +} > +SPL_LOAD_IMAGE_METHOD("USB SDP", 0, BOOT_DEVICE_UART, spl_sdp_load_image); > diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile > index 6a007d1bcb..7258099c1c 100644 > --- a/drivers/usb/gadget/Makefile > +++ b/drivers/usb/gadget/Makefile > @@ -11,6 +11,7 @@ obj-$(CONFIG_USB_ETHER) += epautoconf.o config.o usbstring.o > ifdef CONFIG_SPL_BUILD > obj-$(CONFIG_SPL_USB_GADGET_SUPPORT) += g_dnl.o > obj-$(CONFIG_SPL_DFU_SUPPORT) += f_dfu.o > +obj-$(CONFIG_SPL_USB_SDP_SUPPORT) += f_sdp.o > endif > > # new USB gadget layer dependencies > Reviewed-by: Stefano Babic Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv2 00/10] This patch set represent Marvell mvpp2 driver fixes
Hi Stefan, On 09.08.2017 09:37, stef...@marvell.com wrote: From: Stefan Chulski Issues were found during internal QA phase. Stefan Chulski (10): net: mvpp2x: Add GPIO configuration support net: mvpp2x: fix phy connected to wrong mdio issue net: mvpp2x: Enable GoP packet padding in TX net: mvpp2x: fix BM configuration overrun issue net: mvpp2x: decrease size of AGGR_TXQ and CPU_DESC_CHUNK net: mvpp2x: remove MBUS configurations from MvPP22 driver net: mvpp2x: Remove IRQ configuration from U-Boot net: mvpp2x: Set BM pool high address net: mvpp2x: remove TX drain from transmit routine net: mvpp2x: Set BM poll size once during priv probe drivers/net/mvpp2.c | 187 +--- 1 file changed, 89 insertions(+), 98 deletions(-) All patches applied to u-boot-marvell/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-marvell/master
Hi Tom, please pull the mvpp2x net patches from Stefan Chulski, which have been missed for quite some time. All have been acked by Joe. Thanks, Stefan The following changes since commit d529124fdcf941c34074fd1ce600f4b1b4a7dd07: Merge git://git.denx.de/u-boot-x86 (2017-08-08 17:06:19 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-marvell.git for you to fetch changes up to ceec6c48a472514e6110d07064006258376d4537: net: mvpp2x: Set BM poll size once during priv probe (2017-08-10 08:33:02 +0200) Stefan Chulski (10): net: mvpp2x: Add GPIO configuration support net: mvpp2x: fix phy connected to wrong mdio issue net: mvpp2x: Enable GoP packet padding in TX net: mvpp2x: fix BM configuration overrun issue net: mvpp2x: decrease size of AGGR_TXQ and CPU_DESC_CHUNK net: mvpp2x: remove MBUS configurations from MvPP22 driver net: mvpp2x: Remove IRQ configuration from U-Boot net: mvpp2x: Set BM pool high address net: mvpp2x: remove TX drain from transmit routine net: mvpp2x: Set BM poll size once during priv probe drivers/net/mvpp2.c | 187 +--- 1 file changed, 89 insertions(+), 98 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: spi: Remove atmel_dataflash_spi driver
On Wed, Aug 9, 2017 at 10:53 AM, Wenyou Yang wrote: > This driver is replaced by the SPI-flash-based AT45xxx DataFlash > driver, which supports the driver model and device tree, the > atmel_dataflash_spi driver will not be used any more. > > Signed-off-by: Wenyou Yang > --- > > drivers/spi/Makefile | 1 - > drivers/spi/atmel_dataflash_spi.c | 184 > -- > 2 files changed, 185 deletions(-) > delete mode 100644 drivers/spi/atmel_dataflash_spi.c Similar patch [1] sent before, please ACK if you're OK. [1] https://patchwork.ozlabs.org/patch/765828/ thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] rk3288: 32KB SPL size restriction
Hi Simon/Philipp or any, I believe rk3288 has 20KB BootRom and 100KB internal SRAM and current u-boot can archive the maximum size of u-boot-spl-dtb.bin which the boot ROM will read is 32KB, do we have any possibility to increase the SPL size here. # ./tools/mkimage -n rk3288 -T rksd -d ./spl/u-boot-spl-dtb.bin out.img Warning: SPL image is too large (size 0x9000) and will not boot Error: image verification failed I tried to increase the spl_size from spl_infos (on tools/rkcommon.c) but not able to boot. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 01/10] drivers: spi: allow limiting reads
On Sun, Jul 30, 2017 at 5:43 PM, Álvaro Fernández Rojas wrote: > For some SPI controllers it's not possible to keep the CS active between > transfers and they are limited to a known number of bytes. > This splits spi_flash reads into different iterations in order to respect > the SPI controller limits. > > Signed-off-by: Álvaro Fernández Rojas > Reviewed-by: Simon Glass > Reviewed-by: Daniel Schwierzeck Reviewed-by: Jagan Teki thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 02/10] drivers: spi: consider command bytes when sending transfers
On Sun, Jul 30, 2017 at 5:43 PM, Álvaro Fernández Rojas wrote: > Command bytes are part of the written bytes and they should be taken into > account when sending a spi transfer. > > Signed-off-by: Álvaro Fernández Rojas > Reviewed-by: Simon Glass > Reviewed-by: Daniel Schwierzeck Reviewed-by: Jagan Teki thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 03/10] dm: spi: add BCM63xx SPI driver
On Sun, Jul 30, 2017 at 5:43 PM, Álvaro Fernández Rojas wrote: > This driver is a simplified version of linux/drivers/spi/spi-bcm63xx.c > > Signed-off-by: Álvaro Fernández Rojas > Reviewed-by: Simon Glass > Reviewed-by: Daniel Schwierzeck > --- > v5: Introduce changes suggested by Jagan Teki: > - Use long structure instead of a custom bmips_spi_hw structure. > - Define constants for each SPI core. > v4: Introduce changes suggested by Jagan Teki: > - Add data for each HW controller instead of having two separate configs. > - Also check clock and reset returns as suggested by Simon Glass for HSSPI. > v3: rename BCM6338 SPI driver to BCM6348 > switch to devfdt_get_addr_size_index() > v2: no changes > > drivers/spi/Kconfig | 8 + > drivers/spi/Makefile | 1 + > drivers/spi/bcm63xx_spi.c | 434 > ++ > 3 files changed, 443 insertions(+) > create mode 100644 drivers/spi/bcm63xx_spi.c > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index 8a8e8e480f..511643607b 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -40,6 +40,14 @@ config ATMEL_SPI > many AT91 (ARM) chips. This driver can be used to access > the SPI Flash, such as AT25DF321. > > +config BCM63XX_SPI > + bool "BCM6348 SPI driver" > + depends on ARCH_BMIPS > + help > + Enable the BCM6348/BCM6358 SPI driver. This driver can be used to > + access the SPI NOR flash on platforms embedding these Broadcom > + SPI cores. > + > config CADENCE_QSPI > bool "Cadence QSPI driver" > help > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index 9f8b86de76..d9802dd8c3 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -19,6 +19,7 @@ obj-$(CONFIG_ALTERA_SPI) += altera_spi.o > obj-$(CONFIG_ATH79_SPI) += ath79_spi.o > obj-$(CONFIG_ATMEL_DATAFLASH_SPI) += atmel_dataflash_spi.o > obj-$(CONFIG_ATMEL_SPI) += atmel_spi.o > +obj-$(CONFIG_BCM63XX_SPI) += bcm63xx_spi.o > obj-$(CONFIG_CADENCE_QSPI) += cadence_qspi.o cadence_qspi_apb.o > obj-$(CONFIG_CF_SPI) += cf_spi.o > obj-$(CONFIG_DAVINCI_SPI) += davinci_spi.o > diff --git a/drivers/spi/bcm63xx_spi.c b/drivers/spi/bcm63xx_spi.c > new file mode 100644 > index 00..904db2b7c7 > --- /dev/null > +++ b/drivers/spi/bcm63xx_spi.c > @@ -0,0 +1,434 @@ > +/* > + * Copyright (C) 2017 Álvaro Fernández Rojas > + * > + * Derived from linux/drivers/spi/spi-bcm63xx.c: > + * Copyright (C) 2009-2012 Florian Fainelli > + * Copyright (C) 2010 Tanguy Bouzeloc > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +DECLARE_GLOBAL_DATA_PTR; > + > +/* BCM6348 SPI core */ > +#define SPI_6348_CLK 0x06 > +#define SPI_6348_CMD 0x00 > +#define SPI_6348_CTL 0x40 > +#define SPI_6348_CTL_SHIFT 6 > +#define SPI_6348_FILL 0x07 > +#define SPI_6348_IR_MASK 0x04 > +#define SPI_6348_IR_STAT 0x02 > +#define SPI_6348_RX0x80 > +#define SPI_6348_RX_SIZE 0x3f > +#define SPI_6348_TX0x41 > +#define SPI_6348_TX_SIZE 0x3f > + > +/* BCM6358 SPI core */ > +#define SPI_6358_CLK 0x706 > +#define SPI_6358_CMD 0x700 > +#define SPI_6358_CTL 0x000 > +#define SPI_6358_CTL_SHIFT 14 > +#define SPI_6358_FILL 0x707 > +#define SPI_6358_IR_MASK 0x702 > +#define SPI_6358_IR_STAT 0x704 > +#define SPI_6358_RX0x400 > +#define SPI_6358_RX_SIZE 0x220 > +#define SPI_6358_TX0x002 > +#define SPI_6358_TX_SIZE 0x21e > + > +/* SPI Clock register */ > +#define SPI_CLK_SHIFT 0 > +#define SPI_CLK_20MHZ (0 << SPI_CLK_SHIFT) > +#define SPI_CLK_0_391MHZ (1 << SPI_CLK_SHIFT) > +#define SPI_CLK_0_781MHZ (2 << SPI_CLK_SHIFT) > +#define SPI_CLK_1_563MHZ (3 << SPI_CLK_SHIFT) > +#define SPI_CLK_3_125MHZ (4 << SPI_CLK_SHIFT) > +#define SPI_CLK_6_250MHZ (5 << SPI_CLK_SHIFT) > +#define SPI_CLK_12_50MHZ (6 << SPI_CLK_SHIFT) > +#define SPI_CLK_25MHZ (7 << SPI_CLK_SHIFT) > +#define SPI_CLK_MASK (7 << SPI_CLK_SHIFT) > +#define SPI_CLK_SSOFF_SHIFT3 > +#define SPI_CLK_SSOFF_2(2 << SPI_CLK_SSOFF_SHIFT) > +#define SPI_CLK_SSOFF_MASK (7 << SPI_CLK_SSOFF_SHIFT) > +#define SPI_CLK_BSWAP_SHIFT7 > +#define SPI_CLK_BSWAP_MASK (1 << SPI_CLK_BSWAP_SHIFT) > + > +/* SPI Command register */ > +#define SPI_CMD_OP_SHIFT 0 > +#define SPI_CMD_OP_START (0x3 << SPI_CMD_OP_SHIFT) > +#define SPI_CMD_SLAVE_SHIFT4 > +#define SPI_CMD_SLAVE_MASK (0xf << SPI_CMD_SLAVE_SHIFT) > +#define SPI_CMD_PREPEND_SHIFT 8 > +#define SPI_CMD_PREPEND_BYTES 0xf > +#d
Re: [U-Boot] [PATCH v2] serial: ns16550: Add RX interrupt buffer support
Hi Bin, On 17.07.2017 16:49, Bin Meng wrote: > +Simon, > > Hi Stefan, > > On Mon, Jul 17, 2017 at 7:18 PM, Stefan Roese wrote: >> Hi Bin, >> >> >> On 17.07.2017 11:43, Stefan Roese wrote: >>> >>> On 17.07.2017 11:26, Bin Meng wrote: >>> >>> >>> >>> + } >>> +#endif >>> + >>>return 0; >>> } >>> >>> @@ -459,6 +559,15 @@ int ns16550_serial_ofdata_to_platdata(struct >>> udevice >>> *dev) >>>if (port_type == PORT_JZ4780) >>>plat->fcr |= UART_FCR_UME; >>> >>> +#if CONFIG_IS_ENABLED(SERIAL_IRQ_BUFFER) >>> + plat->irq = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev), >>> + "interrupts", 0); >> >> >> >> Should we handle NS16550 on the PCI bus? If not, better put a comment >> here. > > > > Actually I'm also using this RX IRQ buffer for the HS-UART on BayTrail > connected via PCI (pciuart0: uart@1e,3). I've added the interrupt > property to the DT for this to work for now. I'll check, if I can read > the interrupt from the PCI config space instead. > Yes, the interrupt line register is programmed with the value of its interrupt vector in irq_router_probe(). But you should wait for the IRQ device to be probed before NS16550. >>> >>> >>> I'm currently working on this and this dependency with the PCI interrupt >>> assignment is problematic. The serial driver is (intentionally) probed >>> earlier and the PCI interrupts are still unassigned at that stage. >>> >>> I currently have no real good idea on how to solve this. We could >>> add a new "probe_late() / probe_irqs_enabled()" DM function for such >>> cases, but this seems overly complex and adds new bloat to the DM >>> infrastructure. >>> >>> Do you have some other (simpler) ideas on how to solve this? >> >> >> Another idea would be, to write the PCI interrupt vectors earlier >> in the boot stage, before the serial driver is probed. The interrupts >> don't need to be enabled for this. >> >> What do you think of this idea? >> > > Yep, I believe we can move the following codes from > arch/x86/cpu/i386/interrupts.c > > /* Try to set up the interrupt router, but don't require one */ > ret = uclass_first_device_err(UCLASS_IRQ, &dev); > if (ret && ret != -ENODEV) > return ret; > > to arch_cpu_init_dm() in board_f.c. This does not seem to work. This IRQ routing code is still only called pretty late in the init process: U-Boot 2017.09-rc1-00210-gab169101b0-dirty (Aug 10 2017 - 11:29:37 +0200) CPU: x86_64, vendor Intel, device 30679h DRAM: 4 GiB MMC: pci_mmc: 0, pci_mmc: 1, pci_mmc: 2 SF: Detected w25q64cv with page size 256 Bytes, erase size 4 KiB, total 8 MiB Model: theadorable-x86-DFI-BT700 SF: Detected w25q64cv with page size 256 Bytes, erase size 4 KiB, total 8 MiB Net: No ethernet found. irq_router_common_init (245) Assigning IRQ 5 to PCI device 0.2.0 (INTA) Assigning IRQ 5 to PCI device 0.11.0 (INTA) Assigning IRQ 5 to PCI device 0.12.0 (INTA) Assigning IRQ 5 to PCI device 0.13.0 (INTA) Assigning IRQ 5 to PCI device 0.14.0 (INTA) Assigning IRQ 5 to PCI device 0.15.0 (INTA) Assigning IRQ 5 to PCI device 0.16.0 (INTA) Assigning IRQ 5 to PCI device 0.17.0 (INTA) Assigning IRQ 5 to PCI device 0.18.0 (INTA) Assigning IRQ 7 to PCI device 0.18.1 (INTC) Assigning IRQ 10 to PCI device 0.18.2 (INTD) Assigning IRQ 6 to PCI device 0.18.3 (INTB) Assigning IRQ 5 to PCI device 0.18.4 (INTA) Assigning IRQ 7 to PCI device 0.18.5 (INTC) Assigning IRQ 10 to PCI device 0.18.6 (INTD) Assigning IRQ 6 to PCI device 0.18.7 (INTB) Assigning IRQ 5 to PCI device 0.1c.0 (INTA) Assigning IRQ 5 to PCI device 0.1e.0 (INTA) Assigning IRQ 10 to PCI device 0.1e.1 (INTD) Assigning IRQ 6 to PCI device 0.1e.2 (INTB) Assigning IRQ 7 to PCI device 0.1e.3 (INTC) Assigning IRQ 10 to PCI device 0.1e.4 (INTD) Assigning IRQ 6 to PCI device 0.1e.5 (INTB) Assigning IRQ 6 to PCI device 0.1f.3 (INTB) scanning bus for devices... I see that this PCI interrupt routing is taken from the dts file. An easy solution would be, to just add an interrupt entry to the PCI UART device tree node: - arch/x86/dts/dfi-bt700.dtsi - index b62e00ff1f..1ccdf5d24b 100644 @@ -115,6 +115,7 @@ reg-shift = <2>; clock-frequency = <58982400>; current-speed = <115200>; + interrupts = <7>; }; No need to change any of the interrupt related code and its init sequence this way. What do you think? Would this be acceptable? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Configs: Migrate CONFIG_SYS_I2C_OMAP34XX to CONFIG_SYS_I2C_OMAP24XX
Hello Adam, Am 07.08.2017 um 20:11 schrieb Adam Ford: The driver is for all boards 24XX and up, so let's eliminate the extra option called CONFIG_SYS_I2C_OMAP34XX since the driver checks for CONFIG_OMAP34XX we don't need CONFIG_SYS_I2C_OMAP34XX. Signed-off-by: Adam Ford --- arch/arm/mach-omap2/omap3/clock.c | 2 +- board/compulab/cm_t35/cm_t35.c | 2 +- board/logicpd/am3517evm/am3517evm.c | 2 +- board/ti/am3517crane/am3517crane.c | 2 +- board/ti/evm/evm.c | 2 +- drivers/i2c/Makefile| 1 - include/configs/am3517_crane.h | 2 +- include/configs/am3517_evm.h| 2 +- include/configs/cm_t35.h| 2 +- include/configs/cm_t3517.h | 2 +- include/configs/cm_t54.h| 2 +- include/configs/devkit8000.h| 2 +- include/configs/mcx.h | 2 +- include/configs/nokia_rx51.h| 2 +- include/configs/omap3_evm.h | 2 +- include/configs/omap3_logic.h | 2 +- include/configs/omap3_overo.h | 2 +- include/configs/omap3_pandora.h | 2 +- include/configs/omap3_zoom1.h | 2 +- include/configs/sniper.h| 2 +- include/configs/tam3517-common.h| 2 +- include/configs/tao3530.h | 2 +- include/configs/tricorder.h | 2 +- scripts/config_whitelist.txt| 1 - 24 files changed, 22 insertions(+), 24 deletions(-) applied to u-boot-i2c.git bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c: designware: Allow sending restart conditions
Hello Marek, Am 07.08.2017 um 20:45 schrieb Marek Vasut: Allow sending restart conditions upon direction change as this is required by some chips. Signed-off-by: Marek Vasut Cc: Stefan Roese Cc: Alexey Brodkin Cc: Heiko Schocher --- drivers/i2c/designware_i2c.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) applied to u-boot-i2c.git bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c: at91: Add missing probe function to device driver
Hello Wenyou, Am 31.07.2017 um 03:56 schrieb Wenyou Yang: Add missing probe function to the device driver to active a device. Signed-off-by: Wenyou Yang --- drivers/i2c/at91_i2c.c | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) applied to u-boot-i2c.git bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull from u-boot-i2c
Hello Tom, The following changes since commit 1989374b21089c63019fc9648408c8d609023ffe: configs: Finish migration of PHY_GIGE (2017-08-08 17:02:31 -0400) are available in the git repository at: git://git.denx.de/u-boot-i2c.git master for you to fetch changes up to 014e47f028526689aaa8ecb2e9164572937afe44: i2c: designware: Allow sending restart conditions (2017-08-10 12:02:50 +0200) Adam Ford (2): Configs: Migrate CONFIG_SYS_I2C_OMAP34XX to CONFIG_SYS_I2C_OMAP24XX Convert CONFIG_SYS_I2C_OMAP24XX to Kconfig Marek Vasut (1): i2c: designware: Allow sending restart conditions wenyou.y...@microchip.com (1): i2c: at91: Add missing probe function to device driver arch/arm/mach-omap2/Kconfig| 5 + arch/arm/mach-omap2/omap3/clock.c | 2 +- board/compulab/cm_t35/cm_t35.c | 2 +- board/logicpd/am3517evm/am3517evm.c| 2 +- board/ti/am3517crane/am3517crane.c | 2 +- board/ti/evm/evm.c | 2 +- configs/ti816x_evm_defconfig | 1 + drivers/i2c/Kconfig| 6 ++ drivers/i2c/Makefile | 1 - drivers/i2c/at91_i2c.c | 26 -- drivers/i2c/designware_i2c.c | 3 ++- include/configs/am3517_crane.h | 1 - include/configs/am3517_evm.h | 1 - include/configs/bur_am335x_common.h| 1 - include/configs/cm_t35.h | 1 - include/configs/cm_t3517.h | 1 - include/configs/cm_t54.h | 1 - include/configs/devkit8000.h | 2 -- include/configs/kc1.h | 1 - include/configs/mcx.h | 1 - include/configs/nokia_rx51.h | 1 - include/configs/omap3_evm.h| 1 - include/configs/omap3_logic.h | 1 - include/configs/omap3_overo.h | 1 - include/configs/omap3_pandora.h| 3 --- include/configs/omap3_zoom1.h | 3 --- include/configs/siemens-am33x-common.h | 1 - include/configs/sniper.h | 1 - include/configs/tam3517-common.h | 1 - include/configs/tao3530.h | 1 - include/configs/ti_armv7_omap.h| 1 - include/configs/ti_omap4_common.h | 1 - include/configs/tricorder.h| 1 - scripts/config_whitelist.txt | 2 -- 34 files changed, 43 insertions(+), 38 deletions(-) travis build without errors: https://travis-ci.org/hsdenx/u-boot-i2c/builds/262518498 Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RESEND PATCH] arm: dts: am33xx: Remove redundant interrupt-parent property
From: Suniel Mahesh Upstream Linux has the Interrupt-parent property being removed from mmc, mac, lcdc and tscadc sub nodes in the dtsi file. Interrupt-parent property is already defined in the root node. Therefore, update the dtsi to mimic this change and remove duplicates. Signed-off-by: Suniel Mahesh --- Note: - Compile tested on latest u-boot mainline tree no build issues. - commit information upstream Linux: arm: dts: am33xx: Remove redundant interrupt-parent property sha1: de09eb52a1cceb6f80464a008c67c7bebb242314 --- arch/arm/dts/am33xx.dtsi | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/dts/am33xx.dtsi b/arch/arm/dts/am33xx.dtsi index b26e21b..14caee7 100644 --- a/arch/arm/dts/am33xx.dtsi +++ b/arch/arm/dts/am33xx.dtsi @@ -315,7 +315,6 @@ &edma 25>; dma-names = "tx", "rx"; interrupts = <64>; - interrupt-parent = <&intc>; reg = <0x4806 0x1000>; status = "disabled"; }; @@ -328,7 +327,6 @@ &edma 3>; dma-names = "tx", "rx"; interrupts = <28>; - interrupt-parent = <&intc>; reg = <0x481d8000 0x1000>; status = "disabled"; }; @@ -338,7 +336,6 @@ ti,hwmods = "mmc3"; ti,needs-special-reset; interrupts = <29>; - interrupt-parent = <&intc>; reg = <0x4781 0x1000>; status = "disabled"; }; @@ -724,7 +721,6 @@ 0x4a101200 0x100>; #address-cells = <1>; #size-cells = <1>; - interrupt-parent = <&intc>; /* * c0_rx_thresh_pend * c0_rx_pend @@ -787,7 +783,6 @@ lcdc: lcdc@4830e000 { compatible = "ti,am33xx-tilcdc"; reg = <0x4830e000 0x1000>; - interrupt-parent = <&intc>; interrupts = <36>; ti,hwmods = "lcdc"; status = "disabled"; @@ -796,7 +791,6 @@ tscadc: tscadc@44e0d000 { compatible = "ti,am3359-tscadc"; reg = <0x44e0d000 0x1000>; - interrupt-parent = <&intc>; interrupts = <16>; ti,hwmods = "adc_tsc"; status = "disabled"; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] scripts: setlocalversion: safely extract variables from auto.conf using awk
> Moving SPL_LDSCRIPT to Kconfig triggered an unfortunate attempt of > command substitution, as the sourced auto.conf may include $(ARCH) > which tries to execute a command 'ARCH'. > This showed up as a warning similar to the following: > include/config/auto.conf: line 209: ARCH: command not found > > This change does no longer attempt to source auto.conf, but rather > passes it through awk to retrieve the values for CONFIG_LOCALVERSION > and CONFIG_LOCALVERSION_AUTO. This will also mitigate the risk of > unintended command substitution. > > Signed-off-by: Philipp Tomsich > Reported-by: Andy Yan > Reviewed-by: Tom Rini > --- > > scripts/setlocalversion | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rockchip: rk3288: fix EMMC_DIV_MASK definition in header
> It shoulb be '<<' instead of '<' for _MASK definition, fix it. > > Signed-off-by: Ziyuan Xu > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > Acked-by: Philipp Tomsich > Reviewed-by: Simon Glass > --- > > arch/arm/include/asm/arch-rockchip/cru_rk3288.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v0 00/20] enough UEFI for standard distro boot
On Wed, Aug 9, 2017 at 9:32 PM, Tom Rini wrote: > On Fri, Aug 04, 2017 at 03:31:42PM -0400, Rob Clark wrote: > >> This patchset fleshes out EFI_LOADER enough to support booting an >> upstream \EFI\BOOT\bootaa64.efi (which then loads fallback.efi and >> then eventually the per-distro shim.efi which loads the per-distro >> grubaa64.efi) without resorting to hacks to hard-code u-boot to load >> a particular distro's grub, or other hacks like setting up the >> distro installation as live-media. >> >> The first seven patches add dependencies that will be needed later >> in the series. Patches 8-15 make u-boot work with upstream grub, >> without relying on distro patches. Patches 16-19 add missing bits >> of the UEFI implementation needed to support shim/fallback. And >> finally patch 20 adds bootmanager support to avoid shim/fallback >> after first boot. > > In concept, I am in agreement with the goals of this patch series. In > specifics, I'm going to skim around v0 and see if there's anything in > particular that I feel I need to jump in and comment on at this point. > Thanks for working on this! > There is one remaining regression in travis (well, actually two identical ones) on vexpress which I am pretty stumped by: https://travis-ci.org/robclark/u-boot/jobs/262841862 I cannot reproduce that outside of travis (although I am using distro qemu). I "bisected" it a few days back by cutting down the travis config to just those two vexpress platforms and pushing different stages of this patchset to a test branch. It seemed to be 'efi_loader: refactor boot device and loaded_image handling' that was triggering it. Although that patch (or really any of them) don't touch anything near printenv. Possibly it could be a build size issue with EFI_LOADER getting slightly bigger? I tried updating travis to use qemu 2.9.0 (which modulo any possible distro patches should match what I have when I run locally on fedora 26), but that didn't help. I'm at a bit of a loss about what to do.. I guess I can have a closer look and see if we have any distro patches on qemu that look somehow related. I don't see how this can possibly be a problem w/ the efi_loader patchset. Any suggestions welcome. BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] efi_loader: Add test to boot OpenBSD's efi bootloader
On Wed, Aug 9, 2017 at 11:43 PM, Jonathan Gray wrote: > On Sun, Aug 06, 2017 at 03:06:17PM -0400, Rob Clark wrote: >> On Sun, Aug 6, 2017 at 2:54 PM, Mark Kettenis >> wrote: >> >> From: Rob Clark >> >> Date: Sun, 6 Aug 2017 12:10:28 -0400 >> >> >> >> Signed-off-by: Rob Clark >> >> --- >> >> Kinda works, but since we don't have an 'exit' command like grub, we >> >> have to reboot, which leaves the "board" in a bad state (I guess, >> >> since the next test fails). I haven't tackled the travis bits to get >> >> travis to download OpenBSD's bootloader, or other little details like >> >> that. >> > >> > What does the grub "exit" command do? Simply call EFI_BOOT_SERVICE.Exit()? >> > Wouldn't be too difficult for me to add a command that does this. >> >> Yeah, I think just calls BS->Exit().. that would be quite useful. > > Mark committed the change for this and snapshots now have "machine exit" > and "machine poweroff". > > https://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/BOOTARM.EFI > https://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/BOOTAA64.EFI Excellent.. I'll update my patch and give this a spin today. BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board: ks2: README: Update NAND wording
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 10/08/17 05:29, Franklin S Cooper Jr wrote: > Traditional KS2 devices supported NAND via the AEMIF peripheral. However, > 66AK2G doesn't use the AEMIF but rather the GPMC for NAND. Therefore, > clarify some statements to indicate only certain devices have AEMIF and > in other places just say NAND instead of AEMIF NAND > > Signed-off-by: Franklin S Cooper Jr Acked-by: Roger Quadros > --- > board/ti/ks2_evm/README | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/board/ti/ks2_evm/README b/board/ti/ks2_evm/README > index 5430c7d..a26b7f8 100644 > --- a/board/ti/ks2_evm/README > +++ b/board/ti/ks2_evm/README > @@ -61,7 +61,7 @@ configs/k2g_evm_defconfig > > Supported boot modes: > - SPI NOR boot > - - AEMIF NAND boot > + - AEMIF NAND boot (K2E, K2L and K2HK) > - UART boot > - MMC boot (Only on K2G) > > @@ -69,7 +69,7 @@ Supported image formats: > - u-boot.bin: for loading and running u-boot.bin through > Texas Instruments code composure studio (CCS) and for UART boot. > - u-boot-spi.gph: gpimage for programming SPI NOR flash for SPI NOR boot > - - MLO: gpimage for programming AEMIF NAND flash for NAND boot, MMC boot. > + - MLO: gpimage for programming NAND flash for NAND boot, MMC boot. > > Build instructions: > === > -- cheers, -roger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Convert CONFIG_SYS_I2C_OMAP24XX to Kconfig
Hello Adam, Am 07.08.2017 um 20:11 schrieb Adam Ford: This converts the following to Kconfig: CONFIG_SYS_I2C_OMAP24XX Signed-off-by: Adam Ford --- arch/arm/mach-omap2/Kconfig| 5 + configs/ti816x_evm_defconfig | 1 + drivers/i2c/Kconfig| 6 ++ include/configs/am3517_crane.h | 1 - include/configs/am3517_evm.h | 1 - include/configs/bur_am335x_common.h| 1 - include/configs/cm_t35.h | 1 - include/configs/cm_t3517.h | 1 - include/configs/cm_t54.h | 1 - include/configs/devkit8000.h | 2 -- include/configs/kc1.h | 1 - include/configs/mcx.h | 1 - include/configs/nokia_rx51.h | 1 - include/configs/omap3_evm.h| 1 - include/configs/omap3_logic.h | 1 - include/configs/omap3_overo.h | 1 - include/configs/omap3_pandora.h| 3 --- include/configs/omap3_zoom1.h | 3 --- include/configs/siemens-am33x-common.h | 1 - include/configs/sniper.h | 1 - include/configs/tam3517-common.h | 1 - include/configs/tao3530.h | 1 - include/configs/ti_armv7_omap.h| 1 - include/configs/ti_omap4_common.h | 1 - include/configs/tricorder.h| 1 - scripts/config_whitelist.txt | 1 - 26 files changed, 12 insertions(+), 28 deletions(-) applied to u-boot-i2c.git bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: omap: Fix 'get_device_type()' for OMAP34XX
On Mon, Aug 7, 2017 at 5:19 PM, Derald Woods wrote: > On Mon, Aug 7, 2017 at 7:41 AM, Tom Rini wrote: > >> On Mon, Aug 07, 2017 at 07:35:30AM -0500, Derald Woods wrote: >> > On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods < >> woods.techni...@gmail.com> >> > wrote: >> > >> > > Fixes: 00bbe96ebabb ("arm: omap: Unify get_device_type() function") >> > > >> > > The control status register value is embedded in a structure somewhere >> > > in SRAM, with the last refactoring effort. This patch allows OMAP3 EVM >> > > (TMDSEVM3530) to boot again using the known control register base and >> > > offset for 'readl', for the OMAP34XX case. >> > > >> > > Signed-off-by: Derald D. Woods >> > > >> > > --- >> > > Changes in v2: >> > > - Added 'signed-off-by' >> > > - Updated description >> > > >> > > --- >> > > arch/arm/mach-omap2/sysinfo-common.c | 4 >> > > 1 file changed, 4 insertions(+) >> > > >> > > diff --git a/arch/arm/mach-omap2/sysinfo-common.c >> > > b/arch/arm/mach-omap2/sysinfo-common.c >> > > index 1dc7051ab3..3955e803ad 100644 >> > > --- a/arch/arm/mach-omap2/sysinfo-common.c >> > > +++ b/arch/arm/mach-omap2/sysinfo-common.c >> > > @@ -16,6 +16,10 @@ >> > > */ >> > > u32 get_device_type(void) >> > > { >> > > +#if defined(CONFIG_OMAP34XX) >> > > + return (readl(OMAP34XX_CTRL_BASE + 0x2f0) & DEVICE_TYPE_MASK) >> >> >> > > + DEVICE_TYPE_SHIFT; >> > > +#endif >> > > return (readl((*ctrl)->control_status) & DEVICE_TYPE_MASK) >> >> > > DEVICE_TYPE_SHIFT; >> > > } >> > >> > Is there any comment or concern with this patch? It was the simplest >> > means to get OMAP35XX booting again and still keep the original patch. >> > Basically it avoids the pointer to the OMAP_SRAM_SCRATCH_SYS_CTRL >> located >> > structure as now defined in "arch/arm/mach-omap2/omap3/hw_data.c". >> OMAP3 >> > has a larger active SOC base than just OMAP36XX and greater. Was there >> > anything really broken with 'get_device_type()' previously? >> >> Is the pointer value wrong for 35xx? The problem, such as it was, was >> having the same function duplicated in a number of places, and needing >> to make it more easily / readily available (rather than duplicated >> again) for some additional patches. I'd really rather not introduce >> an #if here unless we really have no other choice. Thanks! >> >> -- >> Tom >> > > I will examine/debug the new 'get_device_type()' source code again > tonight. Without the patch, I have two OMAP3530 boards that do not boot at > all. > Derald In "arch/arm/mach-omap2/omap3/board.c", the following routines call 'get_device_type': - v7_arch_cp15_set_l2aux_ctrl (called from "arch/arm/cpu/armv7/start.S") - v7_arch_cp15_set_acr (called from "arch/arm/cpu/armv7/start.S") - omap3_invalidate_l2_cache_secure (called from "board.c" 's_init') - try_unlock_memory(called from "board.c" 's_init') Each one of these calls to 'get_device_type' seems to have a purpose (i.e. ERRATA or setup). What it highlights is the difference in usage from OMAP36XX, AM33XX, and newer. The SRAM usage, L2 cache and call ordering are likely factors here. Figuring out the implications for OMAP34XX will take time. But you need to have boards that boot to address those issues. So 'get_device_type' usage, for OMAP34XX, is not strictly a "Apples to Apples" type comparison. For now I can proceed with an "out-of-tree" patch, since it is small. Let me know if there is something that I am missing here. Derald ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESENT, v2, 1/4] rockchip: rk322x: set the DDR region as non-secure in SPL
> Disable the ddr secure region setting in SPL and the ddr memory > becomes non-secure, every one can access it. the trust firmware > like OPTEE should have the correct setting for it after SPL if > there is one. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > Acked-by: Philipp Tomsich > --- > > Changes in v2: > - add comment for the change and update the commit message > > arch/arm/mach-rockchip/rk322x-board-spl.c | 4 > 1 file changed, 4 insertions(+) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESENT, v2, 2/4] rockchip: rk322x: update max-frequency for mmc node
> mmc using 15000 as max-frequency like what rk3288 sets. > This can speed up the mmc read/write, the actual mmc clock is: > Before this patch: 37.125M > After this patch: 49.5M > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > Acked-by: Philipp Tomsich > --- > > Changes in v2: > - remove fifo-mode in patch > - update commit message to explain why this patch needed. > > arch/arm/dts/rk3229-evb.dts | 1 - > arch/arm/dts/rk322x.dtsi| 4 ++-- > 2 files changed, 2 insertions(+), 3 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESENT, v2, 3/4] rockchip: clk: update dwmmc clock div
> dwmmc controller has default internal divider by 2, > and we always provide double of the clock rate request by > dwmmc controller. Sync code for all Rockchip SoC with: > 4055b46 rockchip: clk: rk3288: fix mmc clock setting > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > Acked-by: Philipp Tomsich > --- > > Changes in v2: > - add comment for mmc clock div 2 internal > - update the commit message > > drivers/clk/rockchip/clk_rk3036.c | 6 +++--- > drivers/clk/rockchip/clk_rk3188.c | 5 +++-- > drivers/clk/rockchip/clk_rk322x.c | 8 > drivers/clk/rockchip/clk_rk3288.c | 1 + > drivers/clk/rockchip/clk_rk3328.c | 9 + > drivers/clk/rockchip/clk_rk3399.c | 12 > 6 files changed, 24 insertions(+), 17 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/5] rockchip: dts: rk322x: add sdmmc device node
> add node for sdmmc in dts and rk3229-evb. > > Signed-off-by: Kever Yang > Acked-by: Philipp Tomsich > Reviewed-by: Philipp Tomsich > --- > > arch/arm/dts/rk3229-evb.dts | 12 + > arch/arm/dts/rk322x.dtsi| 62 > + > 2 files changed, 74 insertions(+) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESENT, v2, 4/4] rockchip: clk: remove RATE_TO_DIV
> Use DIV_ROUND_UP instead RATE_TO_DIV for all Rockchip SoC > clock driver. > Add or fix the div-field overflow check at the same time. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > Acked-by: Philipp Tomsich > --- > > Changes in v2: > - add overflow check for div-field > > drivers/clk/rockchip/clk_rk3036.c | 3 ++- > drivers/clk/rockchip/clk_rk3188.c | 12 +--- > drivers/clk/rockchip/clk_rk322x.c | 6 ++ > drivers/clk/rockchip/clk_rk3288.c | 7 +++ > drivers/clk/rockchip/clk_rk3368.c | 8 +++- > drivers/clk/rockchip/clk_rk3399.c | 11 ++- > drivers/clk/rockchip/clk_rv1108.c | 3 --- > 7 files changed, 21 insertions(+), 29 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: omap: Fix 'get_device_type()' for OMAP34XX
On Thu, Aug 10, 2017 at 7:25 AM, Derald Woods wrote: > On Mon, Aug 7, 2017 at 5:19 PM, Derald Woods > wrote: > >> On Mon, Aug 7, 2017 at 7:41 AM, Tom Rini wrote: >> >>> On Mon, Aug 07, 2017 at 07:35:30AM -0500, Derald Woods wrote: >>> > On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods < >>> woods.techni...@gmail.com> >>> > wrote: >>> > >>> > > Fixes: 00bbe96ebabb ("arm: omap: Unify get_device_type() function") >>> > > >>> > > The control status register value is embedded in a structure >>> somewhere >>> > > in SRAM, with the last refactoring effort. This patch allows OMAP3 >>> EVM >>> > > (TMDSEVM3530) to boot again using the known control register base and >>> > > offset for 'readl', for the OMAP34XX case. >>> > > >>> > > Signed-off-by: Derald D. Woods >>> > > >>> > > --- >>> > > Changes in v2: >>> > > - Added 'signed-off-by' >>> > > - Updated description >>> > > >>> > > --- >>> > > arch/arm/mach-omap2/sysinfo-common.c | 4 >>> > > 1 file changed, 4 insertions(+) >>> > > >>> > > diff --git a/arch/arm/mach-omap2/sysinfo-common.c >>> > > b/arch/arm/mach-omap2/sysinfo-common.c >>> > > index 1dc7051ab3..3955e803ad 100644 >>> > > --- a/arch/arm/mach-omap2/sysinfo-common.c >>> > > +++ b/arch/arm/mach-omap2/sysinfo-common.c >>> > > @@ -16,6 +16,10 @@ >>> > > */ >>> > > u32 get_device_type(void) >>> > > { >>> > > +#if defined(CONFIG_OMAP34XX) >>> > > + return (readl(OMAP34XX_CTRL_BASE + 0x2f0) & >>> DEVICE_TYPE_MASK) >> >>> > > + DEVICE_TYPE_SHIFT; >>> > > +#endif >>> > > return (readl((*ctrl)->control_status) & DEVICE_TYPE_MASK) >>> >> >>> > > DEVICE_TYPE_SHIFT; >>> > > } >>> > >>> > Is there any comment or concern with this patch? It was the simplest >>> > means to get OMAP35XX booting again and still keep the original patch. >>> > Basically it avoids the pointer to the OMAP_SRAM_SCRATCH_SYS_CTRL >>> located >>> > structure as now defined in "arch/arm/mach-omap2/omap3/hw_data.c". >>> OMAP3 >>> > has a larger active SOC base than just OMAP36XX and greater. Was there >>> > anything really broken with 'get_device_type()' previously? >>> >>> Is the pointer value wrong for 35xx? The problem, such as it was, was >>> having the same function duplicated in a number of places, and needing >>> to make it more easily / readily available (rather than duplicated >>> again) for some additional patches. I'd really rather not introduce >>> an #if here unless we really have no other choice. Thanks! >>> >>> -- >>> Tom >>> >> >> I will examine/debug the new 'get_device_type()' source code again >> tonight. Without the patch, I have two OMAP3530 boards that do not boot at >> all. >> > > > Derald > > > In "arch/arm/mach-omap2/omap3/board.c", the following routines call > 'get_device_type': > - v7_arch_cp15_set_l2aux_ctrl (called from > "arch/arm/cpu/armv7/start.S") > - v7_arch_cp15_set_acr (called from > "arch/arm/cpu/armv7/start.S") > - omap3_invalidate_l2_cache_secure (called from "board.c" 's_init') > - try_unlock_memory(called from "board.c" 's_init') > > Each one of these calls to 'get_device_type' seems to have a purpose (i.e. > ERRATA or setup). What it highlights is the difference in usage from > OMAP36XX, AM33XX, and newer. The SRAM usage, L2 cache and call ordering are > likely factors here. Figuring out the implications for OMAP34XX will take > time. But you need to have boards that boot to address those issues. So > 'get_device_type' usage, for OMAP34XX, is not strictly a "Apples to Apples" > type comparison. For now I can proceed with an "out-of-tree" patch, since > it is small. Let me know if there is something that I am missing here. > > Derald > Based on all of the above, I think the "#if" is still the simplest path to booting. Derald ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] spl: fit: Add booting OS first
On 08/07/2017 04:16 PM, York Sun wrote: > If CONFIG_SPL_OS_BOOT is enabled, boot OS if kernel image is found > in FIT structure. > > Signed-off-by: York Sun > > --- > This presums the kernel image doesn't exist in a FIT image intended for > U-Boot. If kernel image normally co-exists with U-Boot and other images > and user intends to boot U-Boot, this patch needs to rewrite to favor > "loadables" over either "firmware" or "kernel" so user can select which > image to boot. Andre, Need your comment on this. Since you created spl_load_simple_fit() and it is used for both loading kernel and U-Boot (and other images), it favors "firmware" over "loadables" when booting U-Boot. I added CONFIG_SPL_OS_BOOT to favor "kernel". However, if your image contains both kernel and U-Boot and you intend to boot U-Boot, this will break when CONFIG_SPL_OS_BOOT is defined. In this case, I can drop detecting "kernel" and use "loadables" to find kernel image. Please respond. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-fsl-qoriq master
Tom, The following changes since commit eaa90e5df2a4a1cb12fb73571978a9379242d0b5: common/env_embedded.c: rename PPCENV/PPCTEXT macros (2017-08-04 20:38:39 -0400) are available in the git repository at: git://git.denx.de/u-boot-fsl-qoriq.git for you to fetch changes up to 1c83df6f3f95055ed1c8fb40d1d0604863eab78b: armv8: ls2080a: Increase env sector size for qspi boot (2017-08-09 09:57:33 -0700) Alison Wang (1): dm: arm: ls1021a: Move to driver model for USB Hou Zhiqiang (4): armv8/fsl-lsch2: correct the config description of DSPI clock divider fsl-lsch2: csu: remove multiple calling function PCI: layerscape: Fix assigning wrong address to LS2088A pcie cfg1 space fsl-lsch2: csu: correct the workaround A-010315 Qianyu Gong (1): armv8: ls1046ardb: update core frequency to 1800MHZ Rajesh Bhagat (1): config: ls1012aqds: Enable USB EHCI support for ls1012aqds Santan Kumar (5): board/ls2080ardb: Disable SD-related GPIO programming board:ls2080ardb: Update execution of config_board_mux board: ls2080ardb: Add fsl_fdt_fixup_flash driver: net: fsl-mc: fsl_mc_ldpaa_exit exit earlier if dpl applied armv8: ls2080a: Increase env sector size for qspi boot Yang Li (1): mmc: fsl_esdhc: not always setting esdhc fdt status to okay York Sun (1): driver: mmc: fsl_esdhc: Fix compiling warning arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 2 +- .../include/asm/arch-fsl-layerscape/immap_lsch2.h | 1 + board/freescale/common/ns_access.c | 20 +++--- board/freescale/ls1021aiot/ls1021aiot.c| 4 -- board/freescale/ls1021atwr/ls1021atwr.c| 1 - board/freescale/ls1046aqds/ls1046aqds.c| 4 -- board/freescale/ls1046ardb/ls1046ardb.c| 4 -- board/freescale/ls1046ardb/ls1046ardb_rcw_emmc.cfg | 2 +- board/freescale/ls1046ardb/ls1046ardb_rcw_sd.cfg | 2 +- board/freescale/ls2080ardb/ls2080ardb.c| 71 +- configs/ls1021aqds_nand_defconfig | 1 + configs/ls1021aqds_nor_SECURE_BOOT_defconfig | 1 + configs/ls1021aqds_qspi_defconfig | 1 + configs/ls1021aqds_sdcard_ifc_defconfig| 1 + configs/ls1021aqds_sdcard_qspi_defconfig | 1 + configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 1 + configs/ls1021atwr_nor_defconfig | 1 + configs/ls1021atwr_nor_lpuart_defconfig| 1 + configs/ls1021atwr_qspi_defconfig | 1 + .../ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig| 1 + configs/ls1021atwr_sdcard_ifc_defconfig| 1 + configs/ls1021atwr_sdcard_qspi_defconfig | 1 + drivers/mmc/fsl_esdhc.c| 4 +- drivers/net/fsl-mc/mc.c| 11 +++- drivers/pci/pcie_layerscape.c | 3 + include/configs/ls1012aqds.h | 2 + include/configs/ls2080a_common.h | 2 +- include/fsl_csu.h | 2 +- include/usb/ehci-ci.h | 2 +- 29 files changed, 88 insertions(+), 61 deletions(-) Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] driver: mmc: fsl_esdhc: Fix compiling warning
On 08/08/2017 05:07 PM, York Sun wrote: > Commit 4483b7eb added variable vqmmc_dev but only uses it under > CONFIG_DM_REGULATOR. Add the same macro to variable declaration to > get rid of compiling warning. > > Signed-off-by: York Sun > --- Applied to fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: ls1046ardb: update core frequency to 1800MHZ
On 06/15/2017 01:28 AM, Q.y. Gong wrote: > Hi York, > >> -Original Message- >> From: York Sun >> Sent: Wednesday, June 14, 2017 4:55 AM >> To: Q.y. Gong ; u-boot@lists.denx.de >> Cc: Mingkai Hu >> Subject: Re: [PATCH] armv8: ls1046ardb: update core frequency to 1800MHZ >> >> On 06/12/2017 02:30 AM, Gong Qianyu wrote: >>> Update the default core frequency to 1800MHZ for best performance >>> under SD boot and eMMC boot. >> >> Why do you want to change the core frequency? What's the default setting for >> shipment? >> >> York > > It supports 1800MHZ and now new boards all use 1800MHZ by default. > Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8/fsl-lsch2: correct the config description of DSPI clock divider
On 07/03/2017 03:53 AM, Zhiqiang Hou wrote: > From: Hou Zhiqiang > > It is derived from Platform clock instead of Platform PLL frequency. > > Signed-off-by: Hou Zhiqiang > --- Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] board/ls2080ardb: Disable SD-related GPIO programming
On 08/07/2017 10:18 PM, Priyanka Jain wrote: > Both LS2080ARDB rev F and LS2081ARDB were initially designed to have smart > voltage translator to support SD-boot and UHS mode > At a later stage, due to some issues on LS2088ARDB RevF board to support > SD-boot, translator was removed from RevF boards. > > I confirmed with board team that all LS2088ARDB RevF board will not have the > smart voltage translator and all LS2081ARDB boards will have smart voltage > translator. > Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] board:ls2080ardb: Update execution of config_board_mux
On 06/15/2017 04:34 AM, Santan Kumar wrote: > config_board_mux() is dependent on 'hwconfig' env read value. > > For some bootloaders like QSPI, env is ready only after > relocation. So delay execution of config_board_mux() > to misc_init_r(). > > Signed-off-by: Santan Kumar > --- Revised commit message. Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl-lsch2: csu: remove multiple calling function
On 07/03/2017 08:52 PM, Zhiqiang Hou wrote: > From: Hou Zhiqiang > > Signed-off-by: Hou Zhiqiang > --- Added commit message. Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: arm: ls1021a: Move to driver model for USB
On 07/07/2017 01:55 AM, Bin Meng wrote: > On Fri, Jul 7, 2017 at 3:10 PM, Alison Wang wrote: >> This patch enables driver model for USB in defconfigs for LS1021A platforms. >> >> Signed-off-by: Alison Wang >> --- Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fsl_esdhc: not always setting esdhc fdt status to okay
On 07/21/2017 12:10 PM, Li Yang wrote: > We shouldn't always change the status to okay. There could be > situations that the esdhc is intentionally disabled in the device > tree. > > Signed-off-by: Li Yang > --- Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] PCI: layerscape: Fix the bug assigning wrong address to LS2088A pcie cfg1 space
On 07/17/2017 08:45 PM, Zhiqiang Hou wrote: > From: Hou Zhiqiang > > This bug is brought by the commit 3d8553f0a3 (pci: layerscape: add > LS2088A series SoC pcie support), which only updated cfg_res.start > and did not update the .end field, this will make fdt_resource_size() > getting wrong value when calculate the cfg1 space address. This > patch is to fix the bug. > > Signed-off-by: Hou Zhiqiang > --- Revised subject and commit message slightly. Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] config: ls1012aqds: Add USB EHCI support for ls1012aqds
On 07/27/2017 03:05 AM, yinbo@nxp.com wrote: > From: Rajesh Bhagat > > Add USB EHCI support for ls1012aqds platform > > Signed-off-by: Rajat Srivastava > Signed-off-by: Rajesh Bhagat > Signed-off-by: yinbo.zhu > --- Removed commit message (a copy of subject). Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] board: ls2080ardb: Add fsl_fdt_fixup_flash
On 08/07/2017 09:48 PM, Priyanka Jain wrote: > > But in this case at board level, complete IFC is mux-ed with QSPI. > So, we have put this code in board file. > Priyanka > Revised commit message. Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] driver: net: fsl-mc: fsl_mc_ldpaa_exit exit earlier if dpl applied
>> On 06/28/2017 10:47 PM, Santan Kumar wrote: >>> In fsl_mc_ldpaa_exit(), in case of mc is booted and dpl is applied, it >>> should return earlier without executing >>> dpbp_exit() >>> >>> Signed-off-by: Santan Kumar >>> --- Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl-lsch2: csu: correct the workaround A-010315
On 07/03/2017 03:07 AM, Zhiqiang Hou wrote: > From: Hou Zhiqiang > > The implementation of workaround A-010315 is wrong, it updated > other IP's CSU registers. > > Signed-off-by: Hou Zhiqiang > --- Revised commit message. Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1][v2] armv8: ls2080a: Increase env sector size for qspi boot
On 08/08/2017 10:03 PM, Santan Kumar wrote: > Increase env sector size from 64kb to 256kb for qspi boot > > Signed-off-by: Santan Kumar > Signed-off-by: Priyanka Jain > --- > Changes for v2: > -Change the commit message Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/1] mmc: Add MMC support for stm32h7 Socs
Hi Simon On 08/06/2017 07:15 AM, Simon Glass wrote: > Hi Patrice, > > On 20 July 2017 at 02:34, wrote: >> From: Patrice Chotard >> >> This patch adds SD/MMC support for STM32H7 SoCs. >> >> Here is an extraction of SDMMC main features, embedded in >> STM32H7 SoCs. >> The SD/MMC block include the following: >> _ Full compliance with MultiMediaCard System Specification >> Version 4.51. Card support for three different databus modes: >> 1-bit (default), 4-bit and 8-bit. >> _ Full compatibility with previous versions of MultiMediaCards >> (backward compatibility). >> _ Full compliance with SD memory card specifications version 4.1. >> (SDR104 SDMMC_CK speed limited to maximum allowed IO speed, >> SPI mode and UHS-II mode not supported). >> _ Full compliance with SDIO card specification version 4.0. >> Card support for two different databus modes: 1-bit (default) >> and 4-bit. (SDR104 SDMMC_CK speed limited to maximum allowed IO >> speed, SPI mode and UHS-II mode not supported). >> _ Data transfer up to 208 Mbyte/s for the 8 bit mode. >> (depending maximum allowed IO speed). >> _ Data and command output enable signals to control external >> bidirectional drivers. >> >> The current version of the SDMMC supports only one SD/SDIO/MMC card >> at any one time and a stack of MMC Version 4.51 or previous. >> >> Signed-off-by: Christophe Kerello >> Signed-off-by: Patrice Chotard >> --- >> v3: _ use registers offset instead of registers struct description >> _ rename clk_reg_add and pwr_reg_add to respectively clk_reg_msk and >> pwr_reg_msk >> _ don't exit in error if DT bus-width value is not correct, force it to >> 1 >>and continue >> v2: _ add .get_cd() callback support >> >> drivers/mmc/Kconfig| 8 + >> drivers/mmc/Makefile | 1 + >> drivers/mmc/stm32_sdmmc2.c | 598 >> + >> 3 files changed, 607 insertions(+) >> create mode 100644 drivers/mmc/stm32_sdmmc2.c >> >> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig >> index 82b8d75..f2e4c26 100644 >> --- a/drivers/mmc/Kconfig >> +++ b/drivers/mmc/Kconfig >> @@ -377,6 +377,14 @@ config GENERIC_ATMEL_MCI >>the SD Memory Card Specification V2.0, the SDIO V2.0 specification >>and CE-ATA V1.1. >> >> +config STM32_SDMMC2 >> + bool "STMicroelectronics STM32H7 SD/MMC Host Controller support" >> + depends on DM_MMC && OF_CONTROL && DM_MMC_OPS > > I don't see a call to mmc_bind() anywhere. I'm not sure how this > driver actually works without that? We use the mmc_create() API. Patrice > >> + help >> + This selects support for the SD/MMC controller on STM32H7 SoCs. >> + If you have a board based on such a SoC and with a SD/MMC slot, >> + say Y or M here. >> + >> endif > > Regards, > Simon > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] usb: net: Add support for Microchip LAN75xx and LAN78xx
On Thu, Aug 10, 2017 at 2:15 AM, Marek Vasut wrote: > On 08/09/2017 07:47 PM, Joe Hershberger wrote: >> On Wed, Aug 9, 2017 at 12:12 PM, Marek Vasut wrote: >>> On 08/09/2017 06:25 PM, yuiko.osh...@microchip.com wrote: From: Yuiko Oshino Series-Changes: 3 >>> >>> FYI, this will end in the commit message when applied, remove it or move >>> it below the --- . Also commit message is missing. >> >> This is what I was talking about when I said I would fix the commit >> log as I apply it. > > I have a few more comments though, but feel free to fix them up too. I'll let you guys work through the rest of your comments and apply them when you're done. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] stm32: stm32f7: add spl build support
Hi Vikas, On Sun, May 28, 2017 at 2:55 PM, Vikas Manocha wrote: > This commit supports booting from stm32 internal nor flash. spl U-Boot > initializes the sdram memory, copies next image (e.g. standard U-Boot) > to sdram & then jumps to entry point. > > Here are the flash memory addresses for U-Boot-spl & standard U-Boot: > - spl U-Boot: 0x0800_ > - standard U-Boot : 0x0800_8000 Is there another patchset missing on mainline for booting via spl? on mainline with the stm32f746-disco board: U-Boot SPL 2017.09-rc1-00177-gd529124fdc (Aug 10 2017 - 12:33:35) Trying to boot from XIP Hard fault pc : 08008008lr : 08000adbxPSR : 2100 r12 : 2004f338 r3 : 0005r2 : 081c r1 : ff9ar0 : Resetting CPU ... resetting ... I'm using openocd to program openocd -f board/stm32f7discovery.cfg \ -c "init" \ -c "reset init" \ -c "flash probe 0" \ -c "flash write_image erase ./spl/u-boot-spl.bin 0x0800" \ -c "flash write_image erase ./u-boot.img 0x08008000" \ -c "reset run" \ -c "shutdown" Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fs: add fs_readdir()
On Sun, Aug 6, 2017 at 1:16 AM, Simon Glass wrote: > Hi Rob, > > On 3 August 2017 at 13:36, Rob Clark wrote: >> On Thu, Aug 3, 2017 at 3:10 PM, Brüns, Stefan >> wrote: >>> On Donnerstag, 3. August 2017 18:54:30 CEST Rob Clark wrote: Needed to support efi file protocol. The fallback.efi loader wants to be able to read the contents of the /EFI directory to find an OS to boot. Currently only implemented for FAT, but that is all that UEFI is required to support. Signed-off-by: Rob Clark --- fs/fat/fat.c | 59 ++- fs/fs.c | 25 + include/fat.h | 4 +++- include/fs.h | 21 + 4 files changed, 95 insertions(+), 14 deletions(-) >>> >>> NAK >>> >>> 1. The current code is already much to convoluted. Your changes add to this >>> significantly >> >> I agree with the first part of that statement, but not the second. >> The code is pretty awful, but apparently works for people, and I don't >> know (or have the time to learn) enough about FAT to do a massive >> re-write. >> >> I'll split this patch so we can add the interface without FAT >> implementation, and I'll just carry around the second part downstream. >> >>> 2. Your patch description neither references the exact part of the EFI >>> specification you want to support (which took me some time, for reference it >>> is "13.: Protocols - Media Access, 13.5: File Protocol"), nor are you >>> specifying the required semantics (which is "open", "read", "close", where >>> each read returns a single directory entry, similar to the POSIX opendir(), >>> readdir() calls. >> >> I can add a note in the commit message.. although I didn't really >> think it would be too relevant to this patch. (More relevant to the >> patch which adds the efi_loader part, which depends on this patch.) >> >>> 3. Usage of an index too lookup the next entry is also quite convoluted. >>> >>> 4. As far as I can see, your code will fail to find files in the root >>> directory (look for LS_ROOT). >> >> You could be right.. nothing ever traverses the root directory. >> >>> I think it would be much better to first restructure the current code to use >>> an readdir like interface internally, and then do everything EFI needs on >>> top. >> >> tbh, it would be nice even to implement fs_ls() generically on top of >> readdir().. although I didn't do that since it would be slower >> (without a re-write of FAT implementation, since we currently have to >> re-traverse things for each readdir()). >> >> BR, >> -R >> >>> This would get rid of the 4 almost identical copies to print the current >>> directory entry (dols == LS_ROOT || dols == LS_YES), 2 copies of the >>> remaining >>> directory traversal and and also avoid the bug in (4.). >>> >>> Kind regards, >>> >>> Stefan > > How can we get some tests for this code? We have fs-tests.sh - perhaps > we should build on that? If it helps I could bring that into the > pytest framework and you could take it from there? > > With tests we at least have the possibility of refactoring later. > So I haven't had a whole lot of luck getting fs-tests.sh working properly (on master).. With the ext4 tests, at some point mounting the loopback image fails, I end up with this in dmesg: EXT4-fs (loop0): ext4_check_descriptors: Checksum for group 0 failed (50995!=31053) EXT4-fs (loop0): group descriptors corrupted! I guess technically I don't need to run ext4 tests, so if I skip those and just run the fat tests, I still end up with some fails with things like: => fatload host 0:0 0x0108 ./1MB.file.w2 ** Unable to read file ./1MB.file.w2 ** I'm not sure if this is down to some differences in my environment, or if these tests just don't get run often? What I have done is add a ls2 cmd, which implements ls on top of fs_readdir(), which would at least make testing possible. (And fixed a few bugs that turns up with some manual testing.) BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] usb: net: Add support for Microchip LAN75xx and LAN78xx
Hi Marek, >-Original Message- >From: Marek Vasut [mailto:ma...@denx.de] >Sent: Wednesday, August 9, 2017 1:12 PM >To: Yuiko Oshino - C18177; u-boot@lists.denx.de >Cc: Joe Hershberger >Subject: Re: [PATCH v3 1/2] usb: net: Add support for Microchip LAN75xx and >LAN78xx > >On 08/09/2017 06:25 PM, yuiko.osh...@microchip.com wrote: >> From: Yuiko Oshino >> >> Series-Changes: 3 > >FYI, this will end in the commit message when applied, remove it or move it >below the --- . Also commit message is missing. I did my best to follow the patman instructions and I added "commit-notes:" tag, but I guess it wasn't good enough. Should I always manually edit the patch before sending email in the patman? Also, when I am ready to update this patch again, should I do a series or just this patch? How can I update the [PATCH v] number? If just his patch, then will it be [PATCH v4]? > >>- All #ifdef CONFIG_DM_ETH and #endif are removed. >>- The lan7x_eth_recv() is modifed to correctly support the Driver Model >> and returns packet_en. >>- Add mii_resolve_flowctrl_fdx() patch in the series. >> >> Series-Changes: 2 >>- The wait_for_bit functions copy the real one. >>- Uses phylib >>- Unnecessary variables are removed >>- All return values are checked >>- Uses mii_resolve_flowctrl_fdx() from linux/mii.h >> >> Signed-off-by: Yuiko Oshino >> --- >> Add support for Microchip LAN7500, LAN7800 and LAN7850, USB to >> 10/100/1000 Ethernet Controllers. >> >> >> drivers/usb/Kconfig | 2 + >> drivers/usb/eth/Kconfig | 17 ++ >> drivers/usb/eth/Makefile | 2 + >> drivers/usb/eth/lan75xx.c | 318 + >> drivers/usb/eth/lan78xx.c | 477 > >> drivers/usb/eth/lan7x.c | 495 >++ >> drivers/usb/eth/lan7x.h | 230 + >> 7 files changed, 1541 insertions(+) >> create mode 100644 drivers/usb/eth/Kconfig create mode 100644 >> drivers/usb/eth/lan75xx.c create mode 100644 >> drivers/usb/eth/lan78xx.c create mode 100644 drivers/usb/eth/lan7x.c >> create mode 100644 drivers/usb/eth/lan7x.h >> >> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index >> da3ec2f..62126aa 100644 >> --- a/drivers/usb/Kconfig >> +++ b/drivers/usb/Kconfig >> @@ -94,4 +94,6 @@ endif >> >> source "drivers/usb/gadget/Kconfig" >> >> +source "drivers/usb/eth/Kconfig" >> + >> endif >> diff --git a/drivers/usb/eth/Kconfig b/drivers/usb/eth/Kconfig new >> file mode 100644 index 000..14cfa26 >> --- /dev/null >> +++ b/drivers/usb/eth/Kconfig >> @@ -0,0 +1,17 @@ >> +comment "USB to Ethernet Controller Drivers" >> + >> +config USB_ETHER_LAN75XX >> +bool "Microchip LAN75XX support" >> +---help--- >> + Say Y here if you would like to support Microchip LAN75XX Hi-Speed >> + USB 2.0 to 10/100/1000 Gigabit Ethernet controller. >> + Supports 10Base-T/ 100Base-TX/1000Base-T. >> + This driver supports the internal PHY. >> + >> +config USB_ETHER_LAN78XX >> +bool "Microchip LAN78XX support" >> +---help--- >> + Say Y here if you would like to support Microchip LAN78XX USB 3.1 >> + Gen 1 to 10/100/1000 Gigabit Ethernet controller. >> + Supports 10Base-T/ 100Base-TX/1000Base-T. >> + This driver supports the internal PHY. >> diff --git a/drivers/usb/eth/Makefile b/drivers/usb/eth/Makefile index >> 4c44efc..4b935a3 100644 >> --- a/drivers/usb/eth/Makefile >> +++ b/drivers/usb/eth/Makefile >> @@ -9,4 +9,6 @@ obj-$(CONFIG_USB_ETHER_ASIX) += asix.o >> obj-$(CONFIG_USB_ETHER_ASIX88179) += asix88179.o >> obj-$(CONFIG_USB_ETHER_MCS7830) += mcs7830.o >> obj-$(CONFIG_USB_ETHER_SMSC95XX) += smsc95xx.o >> +obj-$(CONFIG_USB_ETHER_LAN75XX) += lan7x.o lan75xx.o >> +obj-$(CONFIG_USB_ETHER_LAN78XX) += lan7x.o lan78xx.o >> obj-$(CONFIG_USB_ETHER_RTL8152) += r8152.o r8152_fw.o diff --git >> a/drivers/usb/eth/lan75xx.c b/drivers/usb/eth/lan75xx.c new file mode >> 100644 index 000..a3c1411 >> --- /dev/null >> +++ b/drivers/usb/eth/lan75xx.c >> @@ -0,0 +1,318 @@ >> +/* >> + * Copyright (c) 2017 Microchip Technology Inc. All rights reserved. >> + * >> + * SPDX-License-Identifier: GPL-2.0+ >> + */ >> + >> +#include >> +#include >> +#include >> +#include "usb_ether.h" >> +#include "lan7x.h" >> + >> +/* LAN75xx specific register/bit defines */ >> +#define LAN75XX_HW_CFG_BIR BIT(7) >> + >> +#define LAN75XX_BURST_CAP 0x034 >> + >> +#define LAN75XX_BULK_IN_DLY 0x03C >> + >> +#define LAN75XX_RFE_CTL 0x060 >> + >> +#define LAN75XX_FCT_RX_CTL 0x090 >> + >> +#define LAN75XX_FCT_TX_CTL 0x094 >> + >> +#define LAN75XX_FCT_RX_FIFO_END 0x098 >> + >> +#define LAN75XX_FCT_TX_FIFO_END 0x09C >> + >> +#define LAN75XX_FCT_FLOW0x0A0 >> + >> +/* MAC ADDRESS PERFECT FILTER For LAN75xx */ >> +#define LAN75XX_ADDR_FILTX 0x300 >> +#define LAN75XX_ADDR_FILTX_FB_VAL
Re: [U-Boot] [PATCH v3 1/2] usb: net: Add support for Microchip LAN75xx and LAN78xx
On 08/10/2017 08:13 PM, yuiko.osh...@microchip.com wrote: > Hi Marek, Hi, >> -Original Message- >> From: Marek Vasut [mailto:ma...@denx.de] >> Sent: Wednesday, August 9, 2017 1:12 PM >> To: Yuiko Oshino - C18177; u-boot@lists.denx.de >> Cc: Joe Hershberger >> Subject: Re: [PATCH v3 1/2] usb: net: Add support for Microchip LAN75xx and >> LAN78xx >> >> On 08/09/2017 06:25 PM, yuiko.osh...@microchip.com wrote: >>> From: Yuiko Oshino >>> >>> Series-Changes: 3 >> >> FYI, this will end in the commit message when applied, remove it or move it >> below the --- . Also commit message is missing. > > I did my best to follow the patman instructions and I added "commit-notes:" > tag, but I guess it wasn't good enough. > Should I always manually edit the patch before sending email in the patman? > Also, when I am ready to update this patch again, should I do a series or > just this patch? > How can I update the [PATCH v] number? If just his patch, then will it be > [PATCH v4]? TBH, I dunno, I don't use patman :) >> >>>- All #ifdef CONFIG_DM_ETH and #endif are removed. >>>- The lan7x_eth_recv() is modifed to correctly support the Driver Model >>> and returns packet_en. >>>- Add mii_resolve_flowctrl_fdx() patch in the series. >>> >>> Series-Changes: 2 >>>- The wait_for_bit functions copy the real one. >>>- Uses phylib >>>- Unnecessary variables are removed >>>- All return values are checked >>>- Uses mii_resolve_flowctrl_fdx() from linux/mii.h >>> >>> Signed-off-by: Yuiko Oshino >>> --- >>> Add support for Microchip LAN7500, LAN7800 and LAN7850, USB to >>> 10/100/1000 Ethernet Controllers. >>> >>> >>> drivers/usb/Kconfig | 2 + >>> drivers/usb/eth/Kconfig | 17 ++ >>> drivers/usb/eth/Makefile | 2 + >>> drivers/usb/eth/lan75xx.c | 318 + >>> drivers/usb/eth/lan78xx.c | 477 >> >>> drivers/usb/eth/lan7x.c | 495 >> ++ >>> drivers/usb/eth/lan7x.h | 230 + >>> 7 files changed, 1541 insertions(+) >>> create mode 100644 drivers/usb/eth/Kconfig create mode 100644 >>> drivers/usb/eth/lan75xx.c create mode 100644 >>> drivers/usb/eth/lan78xx.c create mode 100644 drivers/usb/eth/lan7x.c >>> create mode 100644 drivers/usb/eth/lan7x.h >>> >>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index >>> da3ec2f..62126aa 100644 >>> --- a/drivers/usb/Kconfig >>> +++ b/drivers/usb/Kconfig >>> @@ -94,4 +94,6 @@ endif >>> >>> source "drivers/usb/gadget/Kconfig" >>> >>> +source "drivers/usb/eth/Kconfig" >>> + >>> endif >>> diff --git a/drivers/usb/eth/Kconfig b/drivers/usb/eth/Kconfig new >>> file mode 100644 index 000..14cfa26 >>> --- /dev/null >>> +++ b/drivers/usb/eth/Kconfig >>> @@ -0,0 +1,17 @@ >>> +comment "USB to Ethernet Controller Drivers" >>> + >>> +config USB_ETHER_LAN75XX >>> + bool "Microchip LAN75XX support" >>> + ---help--- >>> + Say Y here if you would like to support Microchip LAN75XX Hi-Speed >>> + USB 2.0 to 10/100/1000 Gigabit Ethernet controller. >>> + Supports 10Base-T/ 100Base-TX/1000Base-T. >>> + This driver supports the internal PHY. >>> + >>> +config USB_ETHER_LAN78XX >>> + bool "Microchip LAN78XX support" >>> + ---help--- >>> + Say Y here if you would like to support Microchip LAN78XX USB 3.1 >>> + Gen 1 to 10/100/1000 Gigabit Ethernet controller. >>> + Supports 10Base-T/ 100Base-TX/1000Base-T. >>> + This driver supports the internal PHY. >>> diff --git a/drivers/usb/eth/Makefile b/drivers/usb/eth/Makefile index >>> 4c44efc..4b935a3 100644 >>> --- a/drivers/usb/eth/Makefile >>> +++ b/drivers/usb/eth/Makefile >>> @@ -9,4 +9,6 @@ obj-$(CONFIG_USB_ETHER_ASIX) += asix.o >>> obj-$(CONFIG_USB_ETHER_ASIX88179) += asix88179.o >>> obj-$(CONFIG_USB_ETHER_MCS7830) += mcs7830.o >>> obj-$(CONFIG_USB_ETHER_SMSC95XX) += smsc95xx.o >>> +obj-$(CONFIG_USB_ETHER_LAN75XX) += lan7x.o lan75xx.o >>> +obj-$(CONFIG_USB_ETHER_LAN78XX) += lan7x.o lan78xx.o >>> obj-$(CONFIG_USB_ETHER_RTL8152) += r8152.o r8152_fw.o diff --git >>> a/drivers/usb/eth/lan75xx.c b/drivers/usb/eth/lan75xx.c new file mode >>> 100644 index 000..a3c1411 >>> --- /dev/null >>> +++ b/drivers/usb/eth/lan75xx.c >>> @@ -0,0 +1,318 @@ >>> +/* >>> + * Copyright (c) 2017 Microchip Technology Inc. All rights reserved. >>> + * >>> + * SPDX-License-Identifier:GPL-2.0+ >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include "usb_ether.h" >>> +#include "lan7x.h" >>> + >>> +/* LAN75xx specific register/bit defines */ >>> +#define LAN75XX_HW_CFG_BIR BIT(7) >>> + >>> +#define LAN75XX_BURST_CAP 0x034 >>> + >>> +#define LAN75XX_BULK_IN_DLY0x03C >>> + >>> +#define LAN75XX_RFE_CTL0x060 >>> + >>> +#define LAN75XX_FCT_RX_CTL 0x090 >>> + >>> +#define LAN75XX_FCT_TX_CTL 0x094 >>> + >>> +#define LAN75XX_FCT_RX_FIFO_END0x0
[U-Boot] [PATCH v1 00/15] enough UEFI for standard distro boot
This patchset fleshes out EFI_LOADER enough to support booting an upstream \EFI\BOOT\bootaa64.efi (which then loads fallback.efi and then eventually the per-distro shim.efi which loads the per-distro grubaa64.efi) without resorting to hacks to hard-code u-boot to load a particular distro's grub, or other hacks like setting up the distro installation as live-media. This patchset applies on top of the "vsprintf and short-wchar for EFI_LOADER" patchset, and the first two patches are additional dependencies. Background: with a normal UEFI implementation, the boot process is: a) firmware (u-boot) looks at BootOrder and the Boot variables to try to determine what to boot. b) the firmware will look at the Boot variables (which contain an EFI_LOAD_OPTION "struct" in order specified by BootOrder, and will boot the first bootable option. c) The EFI_LOAD_OPTION specifies a device-path which identifies the device and file path of the .efi payload to exectute. If there are no bootable options the firmware falls back to loading \EFI\BOOT\bootaa64.efi (exact name varies depending on arch), which then loads fallback.efi which uses the EFI_SIMPLE_FILE_SYSTEM_PROTCOL and EFI_FILE_PROTOCOL to search for \EFI\*\boot.csv, and will then set BootOrder and Boot EFI variables accordingly so that on next boot fallback.efi is not necessary. (I'm ignoring secure boot, it is out of scope here.) For example, if you had both fedora and opensuse installed on the same disk in different partitions, you would have both: + \EFI\fedora\boot.csv + \EFI\opensuse\boot.csv The former would contain the filename of \EFI\fedora\shim.efi and the latter to \EFI\opensuse\shim.efi (each of which would know to load \EFI\fedora\grubaa64.efi or \EFI\opensuse\grubaa64.efi). Based on this, fallback.efi would setup EFI_LOAD_OPTION's Boot and Boot0001 (and BootOrder would control the order the load-options are considered). With a real UEFI fw there would also be some sort of boot-order menu (ie. hold down f9 at boot, and get a menu to pick which of the Boot* load-options to try first). That is not part of this patchset but would be a useful next step to allow installing multiple operating systems on the same disk. This patchset provides EFI variable support during bootservices, so viewing or modifying EFI variables after linux ExitBootServices()'s is not possible. If the board supports saveenv() this will be called in efi_exit_boot_services() to persist variables that where set during the boot process. Making variables available after EBS is tricky on hardware that does not have dedicated storage, as after EBS u-boot no longer controls the devices. An approach that Alexander Graf suggested, is that since reboot/halt is controlled via UEFI, is that on boards that can ensure memory is persisted across reboot, to store modified EFI variables in a special memory location and turn halt into reboot uboot -> appropriate setenv() calls -> saveenv() -> halt in order to persist modified variables. Which is also not part of this patchset, and will likely require some board-specific help. Thanks to Peter Jones for a couple of the patches, and a bunch of help understanding what the things above the UEFI fw expect (and fixing a few shim and grub bugs that we found along the way). Since v0 of the patchset, notable changes: * drop reintroduction of efi_handler::open(), it wasn't really needed and conflicts with some patches Heinrich is working on * splitout vsprintf patches into their own patchset * various fixes Peter Jones (2): part: extract MBR signature from partitions efi: add some more device path structures Rob Clark (13): fs: add fs_readdir() fs/fat: implement readdir efi_loader: add device-path utils efi_loader: drop redundant efi_device_path_protocol efi_loader: flesh out device-path to text efi_loader: use proper device-paths for partitions efi_loader: use proper device-paths for net efi_loader: refactor boot device and loaded_image handling efi_loader: add file/filesys support efi_loader: support load_image() from a file-path efi_loader: make pool allocations cacheline aligned efi_loader: efi variable support efi_loader: add bootmgr cmd/bootefi.c| 249 +++- cmd/fs.c | 14 + disk/part_dos.c | 12 +- disk/part_efi.c | 20 ++ fs/fat/fat.c | 94 -- fs/fs.c | 101 +++ include/blk.h| 15 + include/config_distro_bootcmd.h | 5 + include/efi.h| 25 ++ include/efi_api.h| 154 +- include/efi_loader.h | 56 +++- include/fat.h| 4 +- include/fs.h | 25 ++ include/part.h | 3 +- include/part_ef
[U-Boot] [PATCH v1 01/15] fs: add fs_readdir()
Needed to support efi file protocol. The fallback.efi loader wants to be able to read the contents of the /EFI directory to find an OS to boot. Also included is an ls2 command which implements ls on top of fs_readdir(), to more easily test the readdir functionality. Signed-off-by: Rob Clark --- cmd/fs.c | 14 +++ fs/fs.c | 80 include/fs.h | 23 + 3 files changed, 117 insertions(+) diff --git a/cmd/fs.c b/cmd/fs.c index abfe5be172..58ddcec1a9 100644 --- a/cmd/fs.c +++ b/cmd/fs.c @@ -75,6 +75,20 @@ U_BOOT_CMD( " device type 'interface' instance 'dev'." ) +static int do_ls2_wrapper(cmd_tbl_t *cmdtp, int flag, int argc, + char * const argv[]) +{ + return do_ls2(cmdtp, flag, argc, argv, FS_TYPE_ANY); +} + +U_BOOT_CMD( + ls2,4, 1, do_ls2_wrapper, + "list files in a directory using fs_readdir (default /)", + " [ [directory]]\n" + "- List files in directory 'directory' of partition 'part' on\n" + " device type 'interface' instance 'dev'." +) + static int do_fstype_wrapper(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { diff --git a/fs/fs.c b/fs/fs.c index 595ff1fe69..5720ceec49 100644 --- a/fs/fs.c +++ b/fs/fs.c @@ -69,6 +69,12 @@ static inline int fs_uuid_unsupported(char *uuid_str) return -1; } +static inline int fs_readdir_unsupported(const char *filename, loff_t offset, +struct fs_dirent *dent) +{ + return -ENXIO; +} + struct fstype_info { int fstype; char *name; @@ -92,6 +98,7 @@ struct fstype_info { loff_t len, loff_t *actwrite); void (*close)(void); int (*uuid)(char *uuid_str); + int (*readdir)(const char *filename, loff_t offset, struct fs_dirent *dent); }; static struct fstype_info fstypes[] = { @@ -112,6 +119,7 @@ static struct fstype_info fstypes[] = { .write = fs_write_unsupported, #endif .uuid = fs_uuid_unsupported, + .readdir = fs_readdir_unsupported, }, #endif #ifdef CONFIG_FS_EXT4 @@ -131,6 +139,7 @@ static struct fstype_info fstypes[] = { .write = fs_write_unsupported, #endif .uuid = ext4fs_uuid, + .readdir = fs_readdir_unsupported, }, #endif #ifdef CONFIG_SANDBOX @@ -146,6 +155,7 @@ static struct fstype_info fstypes[] = { .read = fs_read_sandbox, .write = fs_write_sandbox, .uuid = fs_uuid_unsupported, + .readdir = fs_readdir_unsupported, }, #endif #ifdef CONFIG_CMD_UBIFS @@ -161,6 +171,7 @@ static struct fstype_info fstypes[] = { .read = ubifs_read, .write = fs_write_unsupported, .uuid = fs_uuid_unsupported, + .readdir = fs_readdir_unsupported, }, #endif { @@ -175,6 +186,7 @@ static struct fstype_info fstypes[] = { .read = fs_read_unsupported, .write = fs_write_unsupported, .uuid = fs_uuid_unsupported, + .readdir = fs_readdir_unsupported, }, }; @@ -334,6 +346,19 @@ int fs_write(const char *filename, ulong addr, loff_t offset, loff_t len, return ret; } +int fs_readdir(const char *filename, loff_t offset, struct fs_dirent *dent) +{ + struct fstype_info *info = fs_get_info(fs_type); + int ret; + + memset(dent, 0, sizeof(*dent)); + + ret = info->readdir(filename, offset, dent); + fs_close(); + + return ret; +} + int do_size(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[], int fstype) { @@ -440,6 +465,61 @@ int do_ls(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[], return 0; } +int do_ls2(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[], + int fstype) +{ + const char *filename = argc >= 4 ? argv[3] : "/"; + const char *ifname = argv[1]; + const char *dev_part_str = (argc >= 3) ? argv[2] : NULL; + loff_t offset = 0; + int ret, files = 0, dirs = 0; + + if (argc < 2) + return CMD_RET_USAGE; + if (argc > 4) + return CMD_RET_USAGE; + + while (1) { + struct fs_dirent dent, dent2; + char buf[256]; + + if (fs_set_blk_dev(ifname, dev_part_str, fstype)) + return 1; + + ret = fs_readdir(filename, offset, &dent); + if (ret == -ENOENT) { + /* no more directory entries */ + break; + } else if (ret) { + printf("command failed at offset %lld (%d)\n", + offset, ret); + return 1; + } + +
[U-Boot] [PATCH v1 02/15] fs/fat: implement readdir
Yes, this is super-hacky. The FAT code is quite ugly, and this doesn't improve things. But it doesn't make it significantly worse either. The better option would be a massive FAT re-write to get rid of the hacky way that fat_file_ls() works. Volunteers welcome. Signed-off-by: Rob Clark --- fs/fat/fat.c | 94 --- fs/fs.c | 2 +- include/fat.h | 4 ++- 3 files changed, 81 insertions(+), 19 deletions(-) diff --git a/fs/fat/fat.c b/fs/fat/fat.c index 9ad18f96ff..3d5dde0d9e 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -575,17 +576,25 @@ static __u8 mkcksum(const char name[8], const char ext[3]) /* * Get the directory entry associated with 'filename' from the directory * starting at 'startsect' + * + * Last two args are only used for dols==LS_READDIR */ __u8 get_dentfromdir_block[MAX_CLUSTSIZE] __aligned(ARCH_DMA_MINALIGN); -static dir_entry *get_dentfromdir(fsdata *mydata, int startsect, - char *filename, dir_entry *retdent, - int dols) +static dir_entry *get_dentfromdir(fsdata *mydata, char *filename, + dir_entry *retdent, int dols, + loff_t pos, struct fs_dirent *d) { __u16 prevcksum = 0x; __u32 curclust = START(retdent); int files = 0, dirs = 0; + int readdir = 0; + + if (dols == LS_READDIR) { + readdir = 1; + dols = 0; + } debug("get_dentfromdir: %s\n", filename); @@ -618,7 +627,7 @@ static dir_entry *get_dentfromdir(fsdata *mydata, int startsect, get_vfatname(mydata, curclust, get_dentfromdir_block, dentptr, l_name); - if (dols) { + if (dols || readdir) { int isdir; char dirc; int doit = 0; @@ -637,7 +646,14 @@ static dir_entry *get_dentfromdir(fsdata *mydata, int startsect, } } if (doit) { - if (dirc == ' ') { + if (readdir) { + if ((dirs + files - 1) == pos) { + strcpy(d->name, l_name); + if (!isdir) + d->size = FAT2CPU32(dentptr->size); + return NULL; + } + } else if (dirc == ' ') { printf(" %8u %s%c\n", FAT2CPU32(dentptr->size), l_name, @@ -668,7 +684,7 @@ static dir_entry *get_dentfromdir(fsdata *mydata, int startsect, } if (vfat_enabled) { __u8 csum = mkcksum(dentptr->name, dentptr->ext); - if (dols && csum == prevcksum) { + if ((dols || readdir) && csum == prevcksum) { prevcksum = 0x; dentptr++; continue; @@ -676,7 +692,7 @@ static dir_entry *get_dentfromdir(fsdata *mydata, int startsect, } get_name(dentptr, s_name); - if (dols) { + if (dols || readdir) { int isdir = (dentptr->attr & ATTR_DIR); char dirc; int doit = 0; @@ -694,7 +710,14 @@ static dir_entry *get_dentfromdir(fsdata *mydata, int startsect, } if (doit) { - if (dirc == ' ') { + if (readdir) { + if ((dirs + files - 1) == pos) { + strcpy(d->name, s_name); +
[U-Boot] [PATCH v1 04/15] efi: add some more device path structures
From: Peter Jones Signed-off-by: Peter Jones Signed-off-by: Rob Clark --- include/efi_api.h | 62 +++ 1 file changed, 58 insertions(+), 4 deletions(-) diff --git a/include/efi_api.h b/include/efi_api.h index ec1b321e8e..b761cf4822 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -284,28 +284,82 @@ struct efi_device_path { u8 type; u8 sub_type; u16 length; -}; +} __packed; struct efi_mac_addr { u8 addr[32]; -}; +} __packed; + +#define DEVICE_PATH_TYPE_HARDWARE_DEVICE 0x01 +# define DEVICE_PATH_SUB_TYPE_VENDOR 0x04 + +struct efi_device_path_vendor { + struct efi_device_path dp; + efi_guid_t guid; + u8 vendor_data[]; +} __packed; + +#define DEVICE_PATH_TYPE_ACPI_DEVICE 0x02 +# define DEVICE_PATH_SUB_TYPE_ACPI_DEVICE 0x01 + +#define EFI_PNP_ID(ID) (u32)(((ID) << 16) | 0x41D0) +#define EISA_PNP_ID(ID)EFI_PNP_ID(ID) + +struct efi_device_path_acpi_path { + struct efi_device_path dp; + u32 hid; + u32 uid; +} __packed; #define DEVICE_PATH_TYPE_MESSAGING_DEVICE 0x03 +# define DEVICE_PATH_SUB_TYPE_MSG_USB 0x05 # define DEVICE_PATH_SUB_TYPE_MSG_MAC_ADDR0x0b +# define DEVICE_PATH_SUB_TYPE_MSG_SD 0x1a +# define DEVICE_PATH_SUB_TYPE_MSG_MMC 0x1d + +struct efi_device_path_usb { + struct efi_device_path dp; + u8 parent_port_number; + u8 usb_interface; +} __packed; struct efi_device_path_mac_addr { struct efi_device_path dp; struct efi_mac_addr mac; u8 if_type; -}; +} __packed; + +struct efi_device_path_sd_mmc_path { + struct efi_device_path dp; + u8 slot_number; +} __packed; #define DEVICE_PATH_TYPE_MEDIA_DEVICE 0x04 +# define DEVICE_PATH_SUB_TYPE_HARD_DRIVE_PATH 0x01 +# define DEVICE_PATH_SUB_TYPE_CDROM_PATH 0x02 # define DEVICE_PATH_SUB_TYPE_FILE_PATH 0x04 +struct efi_device_path_hard_drive_path { + struct efi_device_path dp; + u32 partition_number; + u64 partition_start; + u64 partition_end; + u8 partition_signature[16]; + u8 partmap_type; + u8 signature_type; +} __packed; + +struct efi_device_path_cdrom_path { + struct efi_device_path dp; + u32 boot_entry; + u64 partition_start; + u64 partition_end; +} __packed; + struct efi_device_path_file_path { struct efi_device_path dp; u16 str[32]; -}; +} __packed; #define BLOCK_IO_GUID \ EFI_GUID(0x964e5b21, 0x6459, 0x11d2, \ -- 2.13.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 03/15] part: extract MBR signature from partitions
From: Peter Jones EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark --- disk/part_dos.c| 12 +--- disk/part_efi.c| 20 include/blk.h | 15 +++ include/efi.h | 4 include/part.h | 3 ++- include/part_efi.h | 4 6 files changed, 50 insertions(+), 8 deletions(-) diff --git a/disk/part_dos.c b/disk/part_dos.c index 7ede15ec26..850a538e83 100644 --- a/disk/part_dos.c +++ b/disk/part_dos.c @@ -89,14 +89,20 @@ static int test_block_type(unsigned char *buffer) static int part_test_dos(struct blk_desc *dev_desc) { - ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz); + ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz); - if (blk_dread(dev_desc, 0, 1, (ulong *)buffer) != 1) + if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1) return -1; - if (test_block_type(buffer) != DOS_MBR) + if (test_block_type((unsigned char *)mbr) != DOS_MBR) return -1; + if (dev_desc->sig_type == SIG_TYPE_NONE && + mbr->unique_mbr_signature != 0) { + dev_desc->sig_type = SIG_TYPE_MBR; + dev_desc->mbr_sig = mbr->unique_mbr_signature; + } + return 0; } diff --git a/disk/part_efi.c b/disk/part_efi.c index 1b7ba27947..71e4188455 100644 --- a/disk/part_efi.c +++ b/disk/part_efi.c @@ -871,11 +871,19 @@ static int is_pmbr_valid(legacy_mbr * mbr) static int is_gpt_valid(struct blk_desc *dev_desc, u64 lba, gpt_header *pgpt_head, gpt_entry **pgpt_pte) { + ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz); + if (!dev_desc || !pgpt_head) { printf("%s: Invalid Argument(s)\n", __func__); return 0; } + /* Read MBR Header from device */ + if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1) { + printf("*** ERROR: Can't read MBR header ***\n"); + return 0; + } + /* Read GPT Header from device */ if (blk_dread(dev_desc, (lbaint_t)lba, 1, pgpt_head) != 1) { printf("*** ERROR: Can't read GPT header ***\n"); @@ -885,6 +893,18 @@ static int is_gpt_valid(struct blk_desc *dev_desc, u64 lba, if (validate_gpt_header(pgpt_head, (lbaint_t)lba, dev_desc->lba)) return 0; + if (dev_desc->sig_type == SIG_TYPE_NONE) { + efi_guid_t empty = {}; + if (memcmp(&pgpt_head->disk_guid, &empty, sizeof(empty))) { + dev_desc->sig_type = SIG_TYPE_GUID; + memcpy(&dev_desc->guid_sig, &pgpt_head->disk_guid, + sizeof(empty)); + } else if (mbr->unique_mbr_signature != 0) { + dev_desc->sig_type = SIG_TYPE_MBR; + dev_desc->mbr_sig = mbr->unique_mbr_signature; + } + } + /* Read and allocate Partition Table Entries */ *pgpt_pte = alloc_read_gpt_entries(dev_desc, pgpt_head); if (*pgpt_pte == NULL) { diff --git a/include/blk.h b/include/blk.h index ef29a07ee2..3a5e04c00d 100644 --- a/include/blk.h +++ b/include/blk.h @@ -8,6 +8,8 @@ #ifndef BLK_H #define BLK_H +#include + #ifdef CONFIG_SYS_64BIT_LBA typedef uint64_t lbaint_t; #define LBAFlength "ll" @@ -35,6 +37,14 @@ enum if_type { IF_TYPE_COUNT, /* Number of interface types */ }; +enum sig_type { + SIG_TYPE_NONE, + SIG_TYPE_MBR, + SIG_TYPE_GUID, + + SIG_TYPE_COUNT /* Number of signature types */ +}; + /* * With driver model (CONFIG_BLK) this is uclass platform data, accessible * with dev_get_uclass_platdata(dev) @@ -62,6 +72,11 @@ struct blk_desc { charvendor[40+1]; /* IDE model, SCSI Vendor */ charproduct[20+1]; /* IDE Serial no, SCSI product */ charrevision[8+1]; /* firmware revision */ + enum sig_type sig_type; /* Partition table signature type */ + union { + uint32_t mbr_sig; /* MBR integer signature */ + efi_guid_t guid_sig;/* GPT GUID Signature */ + }; #ifdef CONFIG_BLK /* * For now we have a few functions which take struct blk_desc as a diff --git a/include/efi.h b/include/efi.h index 02b78b31b1..87b0b43f20 100644 --- a/include/efi.h +++ b/include/efi.h @@ -28,6 +28,10 @@ struct efi_device_path; +typedef struct { + u8 b[16]; +} efi_guid_t; + #define EFI_BITS_PER_LONG BITS_PER_LONG /* diff --git a/include/part.h b/include/part.h index 83bce05a43..ac5ee895e9 100644 --- a/include/part.h +++ b/include/part.h @@ -259,8 +259,9 @
[U-Boot] [PATCH v1 12/15] efi_loader: support load_image() from a file-path
Previously we only supported the case when the EFI application loaded the image into memory for us. But fallback.efi does not do this. Signed-off-by: Rob Clark --- lib/efi_loader/efi_boottime.c | 83 +++ 1 file changed, 68 insertions(+), 15 deletions(-) diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 9dec79d525..7e44ba56e2 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -749,6 +749,45 @@ void efi_setup_loaded_image(struct efi_loaded_image *info, struct efi_object *ob list_add_tail(&obj->link, &efi_obj_list); } +static efi_status_t load_image_from_path(struct efi_device_path *file_path, +void **buffer) +{ + struct efi_file_info *info = NULL; + struct efi_file_handle *f; + static efi_status_t ret; + uint64_t bs; + + f = efi_file_from_path(file_path); + if (!f) + return EFI_DEVICE_ERROR; + + bs = 0; + EFI_CALL(ret = f->getinfo(f, (efi_guid_t *)&efi_file_info_guid, &bs, info)); + if (ret == EFI_BUFFER_TOO_SMALL) { + info = malloc(bs); + EFI_CALL(ret = f->getinfo(f, (efi_guid_t *)&efi_file_info_guid, &bs, info)); + } + if (ret != EFI_SUCCESS) + goto error; + + ret = efi_allocate_pool(EFI_LOADER_DATA, info->file_size, buffer); + if (ret) + goto error; + + EFI_CALL(ret = f->read(f, &info->file_size, *buffer)); + +error: + free(info); + EFI_CALL(f->close(f)); + + if (ret != EFI_SUCCESS) { + efi_free_pool(*buffer); + *buffer = NULL; + } + + return ret; +} + static efi_status_t EFIAPI efi_load_image(bool boot_policy, efi_handle_t parent_image, struct efi_device_path *file_path, @@ -756,25 +795,40 @@ static efi_status_t EFIAPI efi_load_image(bool boot_policy, unsigned long source_size, efi_handle_t *image_handle) { - static struct efi_object loaded_image_info_obj = { - .protocols = { - { - .guid = &efi_guid_loaded_image, - }, - }, - }; struct efi_loaded_image *info; struct efi_object *obj; EFI_ENTRY("%d, %p, %p, %p, %ld, %p", boot_policy, parent_image, file_path, source_buffer, source_size, image_handle); - info = malloc(sizeof(*info)); - loaded_image_info_obj.protocols[0].protocol_interface = info; - obj = malloc(sizeof(loaded_image_info_obj)); - memset(info, 0, sizeof(*info)); - memcpy(obj, &loaded_image_info_obj, sizeof(loaded_image_info_obj)); - obj->handle = info; - info->file_path = file_path; + + info = calloc(1, sizeof(*info)); + obj = calloc(1, sizeof(*obj)); + + if (!source_buffer) { + struct efi_device_path *dp, *fp; + efi_status_t ret; + + ret = load_image_from_path(file_path, &source_buffer); + if (ret != EFI_SUCCESS) { + free(info); + free(obj); + return EFI_EXIT(ret); + } + + /* +* split file_path which contains both the device and +* file parts: +*/ + efi_dp_split_file_path(file_path, &dp, &fp); + + efi_setup_loaded_image(info, obj, dp, fp); + } else { + /* In this case, file_path is the "device" path, ie. +* something like a HARDWARE_DEVICE:MEMORY_MAPPED +*/ + efi_setup_loaded_image(info, obj, file_path, NULL); + } + info->reserved = efi_load_pe(source_buffer, info); if (!info->reserved) { free(info); @@ -783,7 +837,6 @@ static efi_status_t EFIAPI efi_load_image(bool boot_policy, } *image_handle = info; - list_add_tail(&obj->link, &efi_obj_list); return EFI_EXIT(EFI_SUCCESS); } -- 2.13.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 06/15] efi_loader: drop redundant efi_device_path_protocol
This is really the same thing as the efi_device_path struct. Signed-off-by: Rob Clark --- include/efi_api.h| 12 ++-- lib/efi_loader/efi_device_path_to_text.c | 13 - 2 files changed, 10 insertions(+), 15 deletions(-) diff --git a/include/efi_api.h b/include/efi_api.h index 4e27c82129..ac58fd58de 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -487,22 +487,14 @@ struct efi_console_control_protocol EFI_GUID(0x8b843e20, 0x8132, 0x4852, \ 0x90, 0xcc, 0x55, 0x1a, 0x4e, 0x4a, 0x7f, 0x1c) -struct efi_device_path_protocol -{ - uint8_t type; - uint8_t sub_type; - uint16_t length; - uint8_t data[]; -}; - struct efi_device_path_to_text_protocol { uint16_t *(EFIAPI *convert_device_node_to_text)( - struct efi_device_path_protocol *device_node, + struct efi_device_path *device_node, bool display_only, bool allow_shortcuts); uint16_t *(EFIAPI *convert_device_path_to_text)( - struct efi_device_path_protocol *device_path, + struct efi_device_path *device_path, bool display_only, bool allow_shortcuts); }; diff --git a/lib/efi_loader/efi_device_path_to_text.c b/lib/efi_loader/efi_device_path_to_text.c index 4b2f43f0c8..f9d071ac50 100644 --- a/lib/efi_loader/efi_device_path_to_text.c +++ b/lib/efi_loader/efi_device_path_to_text.c @@ -16,7 +16,7 @@ const efi_guid_t efi_guid_device_path_to_text_protocol = EFI_DEVICE_PATH_TO_TEXT_PROTOCOL_GUID; static uint16_t *efi_convert_device_node_to_text( - struct efi_device_path_protocol *device_node, + struct efi_device_path *device_node, bool display_only, bool allow_shortcuts) { @@ -55,15 +55,18 @@ static uint16_t *efi_convert_device_node_to_text( break; case DEVICE_PATH_TYPE_MEDIA_DEVICE: switch (device_node->sub_type) { - case DEVICE_PATH_SUB_TYPE_FILE_PATH: + case DEVICE_PATH_SUB_TYPE_FILE_PATH: { + struct efi_device_path_file_path *fp = + (struct efi_device_path_file_path *)device_node; buffer_size = device_node->length - 4; r = efi_allocate_pool(EFI_ALLOCATE_ANY_PAGES, buffer_size, (void **) &buffer); if (r != EFI_SUCCESS) return NULL; - memcpy(buffer, device_node->data, buffer_size); + memcpy(buffer, fp->str, buffer_size); break; } + } break; } @@ -89,7 +92,7 @@ static uint16_t *efi_convert_device_node_to_text( } static uint16_t EFIAPI *efi_convert_device_node_to_text_ext( - struct efi_device_path_protocol *device_node, + struct efi_device_path *device_node, bool display_only, bool allow_shortcuts) { @@ -105,7 +108,7 @@ static uint16_t EFIAPI *efi_convert_device_node_to_text_ext( } static uint16_t EFIAPI *efi_convert_device_path_to_text( - struct efi_device_path_protocol *device_path, + struct efi_device_path *device_path, bool display_only, bool allow_shortcuts) { -- 2.13.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 05/15] efi_loader: add device-path utils
Helpers to construct device-paths from devices, partitions, files, and for parsing and manipulating device-paths. For non-legacy devices, this will use u-boot's device-model to construct device-paths which include bus hierarchy to construct device-paths. For legacy devices we still fake it, but slightly more convincingly. Signed-off-by: Rob Clark --- include/efi_api.h| 10 + include/efi_loader.h | 20 ++ lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_device_path.c | 489 +++ 4 files changed, 520 insertions(+), 1 deletion(-) create mode 100644 lib/efi_loader/efi_device_path.c diff --git a/include/efi_api.h b/include/efi_api.h index b761cf4822..4e27c82129 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -314,6 +314,7 @@ struct efi_device_path_acpi_path { #define DEVICE_PATH_TYPE_MESSAGING_DEVICE 0x03 # define DEVICE_PATH_SUB_TYPE_MSG_USB 0x05 # define DEVICE_PATH_SUB_TYPE_MSG_MAC_ADDR0x0b +# define DEVICE_PATH_SUB_TYPE_MSG_USB_CLASS 0x0f # define DEVICE_PATH_SUB_TYPE_MSG_SD 0x1a # define DEVICE_PATH_SUB_TYPE_MSG_MMC 0x1d @@ -329,6 +330,15 @@ struct efi_device_path_mac_addr { u8 if_type; } __packed; +struct efi_device_path_usb_class { + struct efi_device_path dp; + u16 vendor_id; + u16 product_id; + u8 device_class; + u8 device_subclass; + u8 device_protocol; +} __packed; + struct efi_device_path_sd_mmc_path { struct efi_device_path dp; u8 slot_number; diff --git a/include/efi_loader.h b/include/efi_loader.h index 037cc7c543..bcca6e49ea 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -197,6 +197,26 @@ extern void *efi_bounce_buffer; #define EFI_LOADER_BOUNCE_BUFFER_SIZE (64 * 1024 * 1024) #endif + +struct efi_device_path *efi_dp_next(struct efi_device_path *dp); +int efi_dp_match(struct efi_device_path *a, struct efi_device_path *b); +struct efi_object *efi_dp_find_obj(struct efi_device_path *dp); +unsigned efi_dp_size(struct efi_device_path *dp); +struct efi_device_path *efi_dp_dup(struct efi_device_path *dp); + +struct efi_device_path *efi_dp_from_dev(struct udevice *dev); +struct efi_device_path *efi_dp_from_part(struct blk_desc *desc, int part); +struct efi_device_path *efi_dp_from_file(struct blk_desc *desc, int part, +const char *path); +struct efi_device_path *efi_dp_from_eth(void); +void efi_dp_split_file_path(struct efi_device_path *full_path, + struct efi_device_path **device_path, + struct efi_device_path **file_path); + +#define EFI_DP_TYPE(_dp, _type, _subtype) \ + (((_dp)->type == DEVICE_PATH_TYPE_##_type) && \ +((_dp)->sub_type == DEVICE_PATH_SUB_TYPE_##_subtype)) + /* Convert strings from normal C strings to uEFI strings */ static inline void ascii2unicode(u16 *unicode, const char *ascii) { diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile index 30bf343a36..f35e5ce8a8 100644 --- a/lib/efi_loader/Makefile +++ b/lib/efi_loader/Makefile @@ -15,7 +15,7 @@ always := $(efiprogs-y) obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o -obj-y += efi_memory.o efi_device_path_to_text.o +obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o obj-$(CONFIG_LCD) += efi_gop.o obj-$(CONFIG_DM_VIDEO) += efi_gop.o obj-$(CONFIG_PARTITIONS) += efi_disk.o diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c new file mode 100644 index 00..e8a6bbff82 --- /dev/null +++ b/lib/efi_loader/efi_device_path.c @@ -0,0 +1,489 @@ +/* + * EFI device path from u-boot device-model mapping + * + * (C) Copyright 2017 Rob Clark + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* template END node: */ +static const struct efi_device_path END = { + .type = DEVICE_PATH_TYPE_END, + .sub_type = DEVICE_PATH_SUB_TYPE_END, + .length = sizeof(END), +}; + +#define U_BOOT_GUID \ + EFI_GUID(0xe61d73b9, 0xa384, 0x4acc, \ +0xae, 0xab, 0x82, 0xe8, 0x28, 0xf3, 0x62, 0x8b) + +/* template ROOT node, a fictional ACPI PNP device: */ +static const struct efi_device_path_vendor ROOT = { + .dp = { + .type = DEVICE_PATH_TYPE_HARDWARE_DEVICE, + .sub_type = DEVICE_PATH_SUB_TYPE_VENDOR, + .length = sizeof(ROOT), + }, + .guid = U_BOOT_GUID, +}; + + +/* + * Iterate to next block in device-path, terminating (returning NULL) + * at /End* node. + */ +struct efi_device_path *efi_dp_next(struct efi_device_path *dp) +{ + if (dp == NULL) + return NULL; + dp = ((void *)dp) + dp->length; + if (dp->type == DEVICE_PATH_TYPE_END) + return NULL; +
Re: [U-Boot] [PATCH v2 3/7] stm32: stm32f7: add spl build support
Hi Robert, On 08/10/2017 11:03 AM, Robert Nelson wrote: > Hi Vikas, > > On Sun, May 28, 2017 at 2:55 PM, Vikas Manocha wrote: >> This commit supports booting from stm32 internal nor flash. spl U-Boot >> initializes the sdram memory, copies next image (e.g. standard U-Boot) >> to sdram & then jumps to entry point. >> >> Here are the flash memory addresses for U-Boot-spl & standard U-Boot: >> - spl U-Boot: 0x0800_ >> - standard U-Boot : 0x0800_8000 > > Is there another patchset missing on mainline for booting via spl? No, you just need to flash spl & next image at above mentioned addresses. By default spl expects kernel image. To boot u-boot, press keyboard character 'c'. you might need to keep on pressing 'c' it for some time as the keyboard entry acceptance & detection window is very small. Cheers, Vikas > > on mainline with the stm32f746-disco board: > > U-Boot SPL 2017.09-rc1-00177-gd529124fdc (Aug 10 2017 - 12:33:35) > Trying to boot from XIP > Hard fault > pc : 08008008lr : 08000adbxPSR : 2100 > r12 : 2004f338 r3 : 0005r2 : 081c > r1 : ff9ar0 : > Resetting CPU ... > > resetting ... > > I'm using openocd to program > > openocd -f board/stm32f7discovery.cfg \ > -c "init" \ > -c "reset init" \ > -c "flash probe 0" \ > -c "flash write_image erase ./spl/u-boot-spl.bin 0x0800" \ > -c "flash write_image erase ./u-boot.img 0x08008000" \ > -c "reset run" \ > -c "shutdown" > > Regards, > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 15/15] efi_loader: add bootmgr
Similar to a "real" UEFI implementation, the bootmgr looks at the BootOrder and Boot variables to try to find an EFI payload to load and boot. This is added as a sub-command of bootefi. The idea is that the distro bootcmd would first try loading a payload via the bootmgr, and then if that fails (ie. first boot or corrupted EFI variables) it would fallback to loading bootaa64.efi. (Which would then load fallback.efi which would look for \EFI\*\boot.csv and populate BootOrder and Boot based on what it found.) Signed-off-by: Rob Clark --- cmd/bootefi.c | 48 ++- include/config_distro_bootcmd.h | 5 ++ include/efi_api.h | 4 + include/efi_loader.h | 6 ++ lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_bootmgr.c | 169 ++ lib/efi_loader/efi_boottime.c | 6 +- lib/efi_loader/efi_image_loader.c | 1 + 8 files changed, 235 insertions(+), 6 deletions(-) create mode 100644 lib/efi_loader/efi_bootmgr.c diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 80f52e9e35..02a0dd159b 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -219,6 +219,36 @@ exit: return ret; } +static int do_bootefi_bootmgr_exec(unsigned long fdt_addr) +{ + struct efi_device_path *device_path, *file_path; + void *addr; + efi_status_t r; + + /* Initialize and populate EFI object list */ + if (!efi_obj_list_initalized) + efi_init_obj_list(); + + /* +* gd lives in a fixed register which may get clobbered while we execute +* the payload. So save it here and restore it on every callback entry +*/ + efi_save_gd(); + + addr = efi_bootmgr_load(&device_path, &file_path); + if (!addr) + return 1; + + printf("## Starting EFI application at %p ...\n", addr); + r = do_bootefi_exec(addr, (void*)fdt_addr, device_path, file_path); + printf("## Application terminated, r = %lu\n", + r & ~EFI_ERROR_MASK); + + if (r != EFI_SUCCESS) + return 1; + + return 0; +} /* Interpreter command to boot an arbitrary EFI image from memory */ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) @@ -237,7 +267,14 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) memcpy((char *)addr, __efi_hello_world_begin, size); } else #endif - { + if (!strcmp(argv[1], "bootmgr")) { + unsigned long fdt_addr = 0; + + if (argc > 2) + fdt_addr = simple_strtoul(argv[2], NULL, 16); + + return do_bootefi_bootmgr_exec(fdt_addr); + } else { saddr = argv[1]; addr = simple_strtoul(saddr, NULL, 16); @@ -270,7 +307,11 @@ static char bootefi_help_text[] = "hello\n" " - boot a sample Hello World application stored within U-Boot" #endif - ; + "bootmgr [fdt addr]\n" + " - load and boot EFI payload based on BootOrder/Boot variables.\n" + "\n" + "If specified, the device tree located at gets\n" + "exposed as EFI configuration table.\n"; #endif U_BOOT_CMD( @@ -308,6 +349,9 @@ void efi_set_bootdev(const char *dev, const char *devnr, const char *path) #endif } + if (!path) + return; + if (strcmp(dev, "Net")) { /* Add leading / to fs paths, because they're absolute */ snprintf(filename, sizeof(filename), "/%s", path); diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index d8dab8e46a..94ccab02d2 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -112,6 +112,11 @@ #define BOOTENV_SHARED_EFI\ "boot_efi_binary="\ + "if fdt addr ${fdt_addr_r}; then "\ + "bootefi bootmgr ${fdt_addr_r};" \ + "else " \ + "bootefi bootmgr ${fdtcontroladdr};" \ + "fi;" \ "load ${devtype} ${devnum}:${distro_bootpart} " \ "${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; " \ "if fdt addr ${fdt_addr_r}; then "\ diff --git a/include/efi_api.h b/include/efi_api.h index 1aae96355f..d0aefa8221 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -211,6 +211,10 @@ struct efi_runtime_services { EFI_GUID(0x, 0x, 0x, 0x00, 0x00, \ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00) +#define EFI_GLOBAL_VARIABLE_GUID \ + EFI_GUID(0x8be4df61, 0x93ca, 0x11d2, 0xaa, 0x0d, \
[U-Boot] [PATCH v1 07/15] efi_loader: flesh out device-path to text
It needs to handle more device-path node types, and also multiple levels of path hierarchy. To simplify this, initially construct utf8 string to a temporary buffer, and then allocate the real utf16 buffer that is returned. This should be mostly for debugging or at least not critical- path so an extra copy won't hurt, and is saner than the alternative. Signed-off-by: Rob Clark --- include/efi_api.h| 1 + include/efi_loader.h | 2 + lib/efi_loader/efi_device_path_to_text.c | 241 +++ 3 files changed, 181 insertions(+), 63 deletions(-) diff --git a/include/efi_api.h b/include/efi_api.h index ac58fd58de..0c36122107 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -304,6 +304,7 @@ struct efi_device_path_vendor { #define EFI_PNP_ID(ID) (u32)(((ID) << 16) | 0x41D0) #define EISA_PNP_ID(ID)EFI_PNP_ID(ID) +#define EISA_PNP_NUM(ID) ((ID) >> 16) struct efi_device_path_acpi_path { struct efi_device_path dp; diff --git a/include/efi_loader.h b/include/efi_loader.h index bcca6e49ea..f2b98f1d2d 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -59,6 +59,8 @@ extern struct efi_simple_input_interface efi_con_in; extern const struct efi_console_control_protocol efi_console_control; extern const struct efi_device_path_to_text_protocol efi_device_path_to_text; +uint16_t *efi_dp_str(struct efi_device_path *dp); + extern const efi_guid_t efi_guid_console_control; extern const efi_guid_t efi_guid_device_path; extern const efi_guid_t efi_guid_loaded_image; diff --git a/lib/efi_loader/efi_device_path_to_text.c b/lib/efi_loader/efi_device_path_to_text.c index f9d071ac50..1a5ef3919b 100644 --- a/lib/efi_loader/efi_device_path_to_text.c +++ b/lib/efi_loader/efi_device_path_to_text.c @@ -15,82 +15,197 @@ const efi_guid_t efi_guid_device_path_to_text_protocol = EFI_DEVICE_PATH_TO_TEXT_PROTOCOL_GUID; -static uint16_t *efi_convert_device_node_to_text( - struct efi_device_path *device_node, - bool display_only, - bool allow_shortcuts) +static char *dp_unknown(char *s, struct efi_device_path *dp) { - unsigned long buffer_size; - efi_status_t r; - uint16_t *buffer = NULL; - int i; + s += sprintf(s, "/UNKNOWN(%04x,%04x)", dp->type, dp->sub_type); + return s; +} - switch (device_node->type) { - case DEVICE_PATH_TYPE_END: - return NULL; - case DEVICE_PATH_TYPE_MESSAGING_DEVICE: - switch (device_node->sub_type) { - case DEVICE_PATH_SUB_TYPE_MSG_MAC_ADDR: { - struct efi_device_path_mac_addr *dp = - (struct efi_device_path_mac_addr *)device_node; - - if (dp->if_type != 0 && dp->if_type != 1) - break; - r = efi_allocate_pool(EFI_ALLOCATE_ANY_PAGES, - 2 * MAC_OUTPUT_LEN, - (void **)&buffer); - if (r != EFI_SUCCESS) - return NULL; - sprintf((char *)buffer, - "MAC(%02x%02x%02x%02x%02x%02x,0x%1x)", - dp->mac.addr[0], dp->mac.addr[1], - dp->mac.addr[2], dp->mac.addr[3], - dp->mac.addr[4], dp->mac.addr[5], - dp->if_type); - for (i = MAC_OUTPUT_LEN - 1; i >= 0; --i) - buffer[i] = ((uint8_t *)buffer)[i]; +static char *dp_hardware(char *s, struct efi_device_path *dp) +{ + switch (dp->sub_type) { + case DEVICE_PATH_SUB_TYPE_VENDOR: { + struct efi_device_path_vendor *vdp = + (struct efi_device_path_vendor *)dp; + s += sprintf(s, "/VenHw(%pUl)", &vdp->guid); + break; + } + default: + s = dp_unknown(s, dp); + break; + } + return s; +} + +static char *dp_acpi(char *s, struct efi_device_path *dp) +{ + switch (dp->sub_type) { + case DEVICE_PATH_SUB_TYPE_ACPI_DEVICE: { + struct efi_device_path_acpi_path *adp = + (struct efi_device_path_acpi_path *)dp; + s += sprintf(s, "/Acpi(PNP%04x", EISA_PNP_NUM(adp->hid)); + if (adp->uid) + s += sprintf(s, ",%d", adp->uid); + s += sprintf(s, ")"); + break; + } + default: + s = dp_unknown(s, dp); + break; + } + return s; +} + +static char *dp_msging(char *s, struct efi_device_path *dp) +{ + switch (dp->sub_type) { + case DEVICE_PATH_SUB_TYPE_MSG_USB: { + struct ef
[U-Boot] [PATCH v1 09/15] efi_loader: use proper device-paths for net
Signed-off-by: Rob Clark --- lib/efi_loader/efi_net.c | 19 ++- 1 file changed, 2 insertions(+), 17 deletions(-) diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c index 0b949d86e8..aa0618fd3a 100644 --- a/lib/efi_loader/efi_net.c +++ b/lib/efi_loader/efi_net.c @@ -26,9 +26,6 @@ struct efi_net_obj { /* EFI Interface callback struct for network */ struct efi_simple_network net; struct efi_simple_network_mode net_mode; - /* Device path to the network adapter */ - struct efi_device_path_mac_addr dp_mac; - struct efi_device_path_file_path dp_end; /* PXE struct to transmit dhcp data */ struct efi_pxe pxe; struct efi_pxe_mode pxe_mode; @@ -213,16 +210,6 @@ void efi_net_set_dhcp_ack(void *pkt, int len) int efi_net_register(void **handle) { struct efi_net_obj *netobj; - struct efi_device_path_mac_addr dp_net = { - .dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE, - .dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_MAC_ADDR, - .dp.length = sizeof(dp_net), - }; - struct efi_device_path_file_path dp_end = { - .dp.type = DEVICE_PATH_TYPE_END, - .dp.sub_type = DEVICE_PATH_SUB_TYPE_END, - .dp.length = sizeof(dp_end), - }; if (!eth_get_dev()) { /* No eth device active, don't expose any */ @@ -236,7 +223,8 @@ int efi_net_register(void **handle) netobj->parent.protocols[0].guid = &efi_net_guid; netobj->parent.protocols[0].protocol_interface = &netobj->net; netobj->parent.protocols[1].guid = &efi_guid_device_path; - netobj->parent.protocols[1].protocol_interface = &netobj->dp_mac; + netobj->parent.protocols[1].protocol_interface = + efi_dp_from_eth(); netobj->parent.protocols[2].guid = &efi_pxe_guid; netobj->parent.protocols[2].protocol_interface = &netobj->pxe; netobj->parent.handle = &netobj->net; @@ -255,9 +243,6 @@ int efi_net_register(void **handle) netobj->net.receive = efi_net_receive; netobj->net.mode = &netobj->net_mode; netobj->net_mode.state = EFI_NETWORK_STARTED; - netobj->dp_mac = dp_net; - netobj->dp_end = dp_end; - memcpy(netobj->dp_mac.mac.addr, eth_get_ethaddr(), 6); memcpy(netobj->net_mode.current_address.mac_addr, eth_get_ethaddr(), 6); netobj->net_mode.max_packet_size = PKTSIZE; -- 2.13.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 14/15] efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables. Variables are pretty important for setting up boot order, among other things. If the board supports saveenv, then it will be called in ExitBootServices() to persist variables set by the efi payload. (For example, fallback.efi configuring BootOrder and Boot load-option variables.) Variables are *not* currently exposed at runtime, post ExitBootServices. On boards without a dedicated device for storage, which the loaded OS is not trying to also use, this is rather tricky. One idea, at least for boards that can persist RAM across reboot, is to keep a "journal" of modified variables in RAM, and then turn halt into a reboot into u-boot, plus store variables, plus halt. Whatever the solution, it likely involves some per-board support. Mapping between EFI variables and u-boot variables: efi_$guid_$varname = {attributes}(type)value For example: efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported= "{ro,boot,run}(blob)" efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder= "(blob)0001" The attributes are a comma separated list of these possible attributes: + ro - read-only + boot - boot-services access + run - runtime access NOTE: with current implementation, no variables are available after ExitBootServices, and all are persisted (if possible). If not specified, the attributes default to "{boot}". The required type is one of: + utf8 - raw utf8 string + blob - arbitrary length hex string Signed-off-by: Rob Clark --- cmd/bootefi.c | 4 + include/efi.h | 19 +++ include/efi_loader.h | 10 ++ lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_boottime.c | 5 + lib/efi_loader/efi_runtime.c | 17 ++- lib/efi_loader/efi_variable.c | 342 ++ 7 files changed, 394 insertions(+), 5 deletions(-) create mode 100644 lib/efi_loader/efi_variable.c diff --git a/cmd/bootefi.c b/cmd/bootefi.c index b9e1e5e131..80f52e9e35 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -181,6 +181,10 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt, goto exit; } + /* we don't support much: */ + setenv("efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported", + "{ro,boot}(blob)"); + /* Call our payload! */ debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__, (long)entry); diff --git a/include/efi.h b/include/efi.h index ddd2b96417..dbd482a5db 100644 --- a/include/efi.h +++ b/include/efi.h @@ -324,6 +324,25 @@ extern char image_base[]; /* Start and end of U-Boot image (for payload) */ extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[]; +/* + * Variable Attributes + */ +#define EFI_VARIABLE_NON_VOLATILE 0x0001 +#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x0002 +#define EFI_VARIABLE_RUNTIME_ACCESS 0x0004 +#define EFI_VARIABLE_HARDWARE_ERROR_RECORD 0x0008 +#define EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS 0x0010 +#define EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS 0x0020 +#define EFI_VARIABLE_APPEND_WRITE 0x0040 + +#define EFI_VARIABLE_MASK (EFI_VARIABLE_NON_VOLATILE | \ + EFI_VARIABLE_BOOTSERVICE_ACCESS | \ + EFI_VARIABLE_RUNTIME_ACCESS | \ + EFI_VARIABLE_HARDWARE_ERROR_RECORD | \ + EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS | \ + EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS | \ + EFI_VARIABLE_APPEND_WRITE) + /** * efi_get_sys_table() - Get access to the main EFI system table * diff --git a/include/efi_loader.h b/include/efi_loader.h index efb93f31f7..9cb568e615 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -271,6 +271,16 @@ efi_status_t __efi_runtime EFIAPI efi_get_time( struct efi_time_cap *capabilities); void efi_get_time_init(void); +efi_status_t EFIAPI efi_get_variable(s16 *variable_name, + efi_guid_t *vendor, u32 *attributes, + unsigned long *data_size, void *data); +efi_status_t EFIAPI efi_get_next_variable( + unsigned long *variable_name_size, + s16 *variable_name, efi_guid_t *vendor); +efi_status_t EFIAPI efi_set_variable(s16 *variable_name, + efi_guid_t *vendor, u32 attributes, + unsigned long data_size, void *data); + #else /* defined(EFI_LOADER) && !defined(CONFIG_SPL_BUILD) */ /* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */ diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile index cce92cfeb5..f58cb13337 100644 --- a/lib/efi_loader/Makefile +++ b/lib/efi_loader/Makefile @@ -16,7 +16,7 @@ always := $(efiprogs-
[U-Boot] [PATCH v1 08/15] efi_loader: use proper device-paths for partitions
Also, create disk objects for the disk itself, in addition to the partitions. (UEFI terminology is a bit confusing, a "disk" object is really a partition.) This helps grub properly identify the boot device since it is trying to match up partition "disk" object with it's parent device. Now instead of seeing devices like: /File(sd...@07864000.blk)/EndEntire /File(usb_mass_storage.lun0)/EndEntire You see: /ACPI(133741d0,0)/UnknownMessaging(1d)/EndEntire /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(0,800,64000,dd904a8c,1,1)/EndEntire /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(1,64800,20,dd904a8c,1,1)/EndEntire /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(2,264800,19a000,dd904a8c,1,1)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(0,800,6,38ca6802,1,1)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(1,61000,155000,38ca6802,1,1)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(2,20fa800,1bbf8800,38ca6802,1,1)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(3,1b6800,1f44000,38ca6802,1,1)/EndEntire This is on a board with single USB disk and single sd-card. The UnknownMessaging(1d) node in the device-path is the MMC device, but grub_efi_print_device_path() hasn't been updated yet for some of the newer device-path sub-types. This patch is inspired by a patch originally from Peter Jones, but re-worked to use efi_device_path, so it doesn't much resemble the original. Signed-off-by: Rob Clark --- lib/efi_loader/efi_disk.c | 54 +++ 1 file changed, 31 insertions(+), 23 deletions(-) diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c index ed06485e33..eea65a402a 100644 --- a/lib/efi_loader/efi_disk.c +++ b/lib/efi_loader/efi_disk.c @@ -28,11 +28,13 @@ struct efi_disk_obj { /* EFI Interface Media descriptor struct, referenced by ops */ struct efi_block_io_media media; /* EFI device path to this block device */ - struct efi_device_path_file_path *dp; + struct efi_device_path *dp; + /* partition # */ + unsigned part; /* Offset into disk for simple partitions */ lbaint_t offset; /* Internal block device */ - const struct blk_desc *desc; + struct blk_desc *desc; }; static efi_status_t EFIAPI efi_disk_reset(struct efi_block_io *this, @@ -172,26 +174,26 @@ static const struct efi_block_io block_io_disk_template = { static void efi_disk_add_dev(const char *name, const char *if_typename, -const struct blk_desc *desc, +struct blk_desc *desc, int dev_index, -lbaint_t offset) +lbaint_t offset, +unsigned part) { struct efi_disk_obj *diskobj; - struct efi_device_path_file_path *dp; - int objlen = sizeof(*diskobj) + (sizeof(*dp) * 2); /* Don't add empty devices */ if (!desc->lba) return; - diskobj = calloc(1, objlen); + diskobj = calloc(1, sizeof(*diskobj)); /* Fill in object data */ - dp = (void *)&diskobj[1]; + diskobj->dp = efi_dp_from_part(desc, part); + diskobj->part = part; diskobj->parent.protocols[0].guid = &efi_block_io_guid; diskobj->parent.protocols[0].protocol_interface = &diskobj->ops; diskobj->parent.protocols[1].guid = &efi_guid_device_path; - diskobj->parent.protocols[1].protocol_interface = dp; + diskobj->parent.protocols[1].protocol_interface = diskobj->dp; diskobj->parent.handle = diskobj; diskobj->ops = block_io_disk_template; diskobj->ifname = if_typename; @@ -207,17 +209,6 @@ static void efi_disk_add_dev(const char *name, diskobj->media.last_block = desc->lba - offset; diskobj->ops.media = &diskobj->media; - /* Fill in device path */ - diskobj->dp = dp; - dp[0].dp.type = DEVICE_PATH_TYPE_MEDIA_DEVICE; - dp[0].dp.sub_type = DEVICE_PATH_SUB_TYPE_FILE_PATH; - dp[0].dp.length = sizeof(*dp); - ascii2unicode(dp[0].str, name); - - dp[1].dp.type = DEVICE_PATH_TYPE_END; - dp[1].dp.sub_type = DEVICE_PATH_SUB_TYPE_END; - dp[1].dp.length = sizeof(*dp); - /* Hook up to the device list */ list_add_tail(&diskobj->parent.link, &efi_obj_list); } @@ -236,14 +227,18 @@ static int efi_disk_create_eltorito(struct blk_desc *desc, if (desc->part_type != PART_TYPE_ISO) return 0; + /* and devices for each partition: */ while (!part_get_info(desc, part, &info)) { snprintf(devname, sizeof(devname), "%s:%d", pdevname, part); efi_disk_add_dev(devname, if_typename, desc, di
[U-Boot] [PATCH v1 10/15] efi_loader: refactor boot device and loaded_image handling
Get rid of the hacky fake boot-device and duplicate device-path constructing (which needs to match what efi_disk and efi_net do). Instead convert over to use efi_device_path helpers to construct device-paths, and use that to look up the actual boot device. Also, extract out a helper to plug things in properly to the loaded_image. In a following patch we'll want to re-use this in efi_load_image() to handle the case of loading an image from a file_path. Signed-off-by: Rob Clark --- cmd/bootefi.c | 201 +- include/efi_loader.h | 5 +- lib/efi_loader/efi_boottime.c | 35 lib/efi_loader/efi_net.c | 5 +- 4 files changed, 99 insertions(+), 147 deletions(-) diff --git a/cmd/bootefi.c b/cmd/bootefi.c index d20775eccd..b9e1e5e131 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -22,97 +22,14 @@ DECLARE_GLOBAL_DATA_PTR; static uint8_t efi_obj_list_initalized; -/* - * When booting using the "bootefi" command, we don't know which - * physical device the file came from. So we create a pseudo-device - * called "bootefi" with the device path /bootefi. - * - * In addition to the originating device we also declare the file path - * of "bootefi" based loads to be /bootefi. - */ -static struct efi_device_path_file_path bootefi_image_path[] = { - { - .dp.type = DEVICE_PATH_TYPE_MEDIA_DEVICE, - .dp.sub_type = DEVICE_PATH_SUB_TYPE_FILE_PATH, - .dp.length = sizeof(bootefi_image_path[0]), - .str = { 'b','o','o','t','e','f','i' }, - }, { - .dp.type = DEVICE_PATH_TYPE_END, - .dp.sub_type = DEVICE_PATH_SUB_TYPE_END, - .dp.length = sizeof(bootefi_image_path[0]), - } -}; - -static struct efi_device_path_file_path bootefi_device_path[] = { - { - .dp.type = DEVICE_PATH_TYPE_MEDIA_DEVICE, - .dp.sub_type = DEVICE_PATH_SUB_TYPE_FILE_PATH, - .dp.length = sizeof(bootefi_image_path[0]), - .str = { 'b','o','o','t','e','f','i' }, - }, { - .dp.type = DEVICE_PATH_TYPE_END, - .dp.sub_type = DEVICE_PATH_SUB_TYPE_END, - .dp.length = sizeof(bootefi_image_path[0]), - } -}; - -/* The EFI loaded_image interface for the image executed via "bootefi" */ -static struct efi_loaded_image loaded_image_info = { - .device_handle = bootefi_device_path, - .file_path = bootefi_image_path, -}; - -/* The EFI object struct for the image executed via "bootefi" */ -static struct efi_object loaded_image_info_obj = { - .handle = &loaded_image_info, - .protocols = { - { - /* -* When asking for the loaded_image interface, just -* return handle which points to loaded_image_info -*/ - .guid = &efi_guid_loaded_image, - .protocol_interface = &loaded_image_info, - }, - { - /* -* When asking for the device path interface, return -* bootefi_device_path -*/ - .guid = &efi_guid_device_path, - .protocol_interface = bootefi_device_path, - }, - { - .guid = &efi_guid_console_control, - .protocol_interface = (void *) &efi_console_control - }, - { - .guid = &efi_guid_device_path_to_text_protocol, - .protocol_interface = (void *) &efi_device_path_to_text - }, - }, -}; - -/* The EFI object struct for the device the "bootefi" image was loaded from */ -static struct efi_object bootefi_device_obj = { - .handle = bootefi_device_path, - .protocols = { - { - /* When asking for the device path interface, return -* bootefi_device_path */ - .guid = &efi_guid_device_path, - .protocol_interface = bootefi_device_path - } - }, -}; +static struct efi_device_path *bootefi_image_path; +static struct efi_device_path *bootefi_device_path; /* Initialize and populate EFI object list */ static void efi_init_obj_list(void) { efi_obj_list_initalized = 1; - list_add_tail(&loaded_image_info_obj.link, &efi_obj_list); - list_add_tail(&bootefi_device_obj.link, &efi_obj_list); efi_console_register(); #ifdef CONFIG_PARTITIONS efi_disk_register(); @@ -121,13 +38,7 @@ static void efi_init_obj_list(void) efi_gop_register(); #endif #ifdef CONFIG_NET - void *nethandle = loaded_image_info.device_handle; - efi_net_register(&nethandle); - - if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6)) -
[U-Boot] [PATCH v1 13/15] efi_loader: make pool allocations cacheline aligned
This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark --- lib/efi_loader/efi_memory.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c index 9e079f1fa3..2ba8d8b42b 100644 --- a/lib/efi_loader/efi_memory.c +++ b/lib/efi_loader/efi_memory.c @@ -43,7 +43,7 @@ void *efi_bounce_buffer; */ struct efi_pool_allocation { u64 num_pages; - char data[]; + char data[] __attribute__((aligned(ARCH_DMA_MINALIGN))); }; /* @@ -356,7 +356,8 @@ efi_status_t efi_allocate_pool(int pool_type, unsigned long size, { efi_status_t r; efi_physical_addr_t t; - u64 num_pages = (size + sizeof(u64) + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT; + u64 num_pages = DIV_ROUND_UP(size + sizeof(struct efi_pool_allocation), +EFI_PAGE_SIZE); if (size == 0) { *buffer = NULL; -- 2.13.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 11/15] efi_loader: add file/filesys support
fallback.efi (and probably other things) use UEFI's simple-file-system protocol and file support to search for OS's to boot. Signed-off-by: Rob Clark --- fs/fs.c | 21 ++ include/efi.h | 2 + include/efi_api.h | 65 ++ include/efi_loader.h | 13 ++ include/fs.h | 2 + lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_disk.c | 32 +++ lib/efi_loader/efi_file.c | 468 ++ lib/efi_loader/efi_image_loader.c | 3 + 9 files changed, 607 insertions(+) create mode 100644 lib/efi_loader/efi_file.c diff --git a/fs/fs.c b/fs/fs.c index d6a2cdb22f..d4ece2a757 100644 --- a/fs/fs.c +++ b/fs/fs.c @@ -247,6 +247,27 @@ int fs_set_blk_dev(const char *ifname, const char *dev_part_str, int fstype) return -1; } +/* set current blk device w/ blk_desc + partition # */ +int fs_set_blk_dev2(struct blk_desc *desc, int part) +{ + struct fstype_info *info; + int ret, i; + + ret = part_get_info(desc, part, &fs_partition); + if (ret) + return ret; + fs_dev_desc = desc; + + for (i = 0, info = fstypes; i < ARRAY_SIZE(fstypes); i++, info++) { + if (!info->probe(fs_dev_desc, &fs_partition)) { + fs_type = info->fstype; + return 0; + } + } + + return -1; +} + static void fs_close(void) { struct fstype_info *info = fs_get_info(fs_type); diff --git a/include/efi.h b/include/efi.h index 87b0b43f20..ddd2b96417 100644 --- a/include/efi.h +++ b/include/efi.h @@ -81,6 +81,8 @@ typedef struct { #define EFI_IP_ADDRESS_CONFLICT(EFI_ERROR_MASK | 34) #define EFI_HTTP_ERROR (EFI_ERROR_MASK | 35) +#define EFI_WARN_DELETE_FAILURE2 + typedef unsigned long efi_status_t; typedef u64 efi_physical_addr_t; typedef u64 efi_virtual_addr_t; diff --git a/include/efi_api.h b/include/efi_api.h index 0c36122107..1aae96355f 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -666,4 +666,69 @@ struct efi_pxe { struct efi_pxe_mode *mode; }; +#define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID \ + EFI_GUID(0x964e5b22, 0x6459, 0x11d2, \ +0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b) +#define EFI_FILE_PROTOCOL_REVISION 0x0001 + +struct efi_file_handle { + u64 rev; + efi_status_t (EFIAPI *open)(struct efi_file_handle *file, + struct efi_file_handle **new_handle, + s16 *file_name, u64 open_mode, u64 attributes); + efi_status_t (EFIAPI *close)(struct efi_file_handle *file); + efi_status_t (EFIAPI *delete)(struct efi_file_handle *file); + efi_status_t (EFIAPI *read)(struct efi_file_handle *file, + u64 *buffer_size, void *buffer); + efi_status_t (EFIAPI *write)(struct efi_file_handle *file, + u64 *buffer_size, void *buffer); + efi_status_t (EFIAPI *getpos)(struct efi_file_handle *file, + u64 *pos); + efi_status_t (EFIAPI *setpos)(struct efi_file_handle *file, + u64 pos); + efi_status_t (EFIAPI *getinfo)(struct efi_file_handle *file, + efi_guid_t *info_type, u64 *buffer_size, void *buffer); + efi_status_t (EFIAPI *setinfo)(struct efi_file_handle *file, + efi_guid_t *info_type, u64 buffer_size, void *buffer); + efi_status_t (EFIAPI *flush)(struct efi_file_handle *file); +}; + +#define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID \ + EFI_GUID(0x964e5b22, 0x6459, 0x11d2, \ +0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b) +#define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_REVISION 0x0001 + +struct efi_simple_file_system_protocol { + u64 rev; + efi_status_t (EFIAPI *open_volume)(struct efi_simple_file_system_protocol *this, + struct efi_file_handle **root); +}; + +#define EFI_FILE_INFO_GUID \ + EFI_GUID(0x9576e92, 0x6d3f, 0x11d2, \ +0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b) + +#define EFI_FILE_MODE_READ 0x0001 +#define EFI_FILE_MODE_WRITE0x0002 +#define EFI_FILE_MODE_CREATE 0x8000 + +#define EFI_FILE_READ_ONLY 0x0001 +#define EFI_FILE_HIDDEN0x0002 +#define EFI_FILE_SYSTEM0x0004 +#define EFI_FILE_RESERVED 0x0008 +#define EFI_FILE_DIRECTORY 0x0010 +#define EFI_FILE_ARCHIVE 0x0020 +#define EFI_FILE_VALID_ATTR0x0037 + +struct efi_file_info { + u64 size; + u64 file_size; + u64 physical_size; + struct efi_time create_time; + struct efi_time last_access_time; + struct efi_time modification_time; + u64 attribute; + s16 file_name[0]; +}; + #endif dif
Re: [U-Boot] [PATCH v2 3/7] stm32: stm32f7: add spl build support
On Thu, Aug 10, 2017 at 1:10 PM, Vikas Manocha wrote: > One other point, > > On 08/10/2017 11:07 AM, Vikas Manocha wrote: >> Hi Robert, >> >> On 08/10/2017 11:03 AM, Robert Nelson wrote: >>> Hi Vikas, >>> >>> On Sun, May 28, 2017 at 2:55 PM, Vikas Manocha wrote: This commit supports booting from stm32 internal nor flash. spl U-Boot initializes the sdram memory, copies next image (e.g. standard U-Boot) to sdram & then jumps to entry point. Here are the flash memory addresses for U-Boot-spl & standard U-Boot: - spl U-Boot: 0x0800_ - standard U-Boot : 0x0800_8000 >>> >>> Is there another patchset missing on mainline for booting via spl? >> >> No, you just need to flash spl & next image at above mentioned addresses. By >> default spl expects kernel image. >> >> To boot u-boot, press keyboard character 'c'. >> you might need to keep on pressing 'c' it for some time as the keyboard >> entry acceptance & detection window is very small. >> >> Cheers, >> Vikas >> >>> >>> on mainline with the stm32f746-disco board: >>> >>> U-Boot SPL 2017.09-rc1-00177-gd529124fdc (Aug 10 2017 - 12:33:35) >>> Trying to boot from XIP >>> Hard fault >>> pc : 08008008lr : 08000adbxPSR : 2100 >>> r12 : 2004f338 r3 : 0005r2 : 081c >>> r1 : ff9ar0 : >>> Resetting CPU ... >>> >>> resetting ... >>> >>> I'm using openocd to program >>> >>> openocd -f board/stm32f7discovery.cfg \ >>> -c "init" \ >>> -c "reset init" \ >>> -c "flash probe 0" \ >>> -c "flash write_image erase ./spl/u-boot-spl.bin 0x0800" \ >>> -c "flash write_image erase ./u-boot.img 0x08008000" \ > > it should be u-boot-dtb.bin. Bingo! Thanks Vikas!! U-Boot SPL 2017.09-rc1-00177-gd529124fdc (Aug 10 2017 - 12:33:35) Trying to boot from XIP U-Boot 2017.09-rc1-00177-gd529124fdc (Aug 10 2017 - 12:33:35 -0500) Model: STMicroelectronics STM32F746-DISCO board DRAM: 8 MiB Flash: 1 MiB Using default environment In:serial@40011000 Out: serial@40011000 Err: serial@40011000 usr button is at LOW LEVEL Net: Warning: ethernet@40028000 (eth0) using random MAC address - 02:4a:de:c3:c8:80 eth0: ethernet@40028000 Hit SPACE in 3 seconds to stop autoboot. U-Boot > Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] stm32: stm32f7: add spl build support
One other point, On 08/10/2017 11:07 AM, Vikas Manocha wrote: > Hi Robert, > > On 08/10/2017 11:03 AM, Robert Nelson wrote: >> Hi Vikas, >> >> On Sun, May 28, 2017 at 2:55 PM, Vikas Manocha wrote: >>> This commit supports booting from stm32 internal nor flash. spl U-Boot >>> initializes the sdram memory, copies next image (e.g. standard U-Boot) >>> to sdram & then jumps to entry point. >>> >>> Here are the flash memory addresses for U-Boot-spl & standard U-Boot: >>> - spl U-Boot: 0x0800_ >>> - standard U-Boot : 0x0800_8000 >> >> Is there another patchset missing on mainline for booting via spl? > > No, you just need to flash spl & next image at above mentioned addresses. By > default spl expects kernel image. > > To boot u-boot, press keyboard character 'c'. > you might need to keep on pressing 'c' it for some time as the keyboard entry > acceptance & detection window is very small. > > Cheers, > Vikas > >> >> on mainline with the stm32f746-disco board: >> >> U-Boot SPL 2017.09-rc1-00177-gd529124fdc (Aug 10 2017 - 12:33:35) >> Trying to boot from XIP >> Hard fault >> pc : 08008008lr : 08000adbxPSR : 2100 >> r12 : 2004f338 r3 : 0005r2 : 081c >> r1 : ff9ar0 : >> Resetting CPU ... >> >> resetting ... >> >> I'm using openocd to program >> >> openocd -f board/stm32f7discovery.cfg \ >> -c "init" \ >> -c "reset init" \ >> -c "flash probe 0" \ >> -c "flash write_image erase ./spl/u-boot-spl.bin 0x0800" \ >> -c "flash write_image erase ./u-boot.img 0x08008000" \ it should be u-boot-dtb.bin. Cheers, Vikas >> -c "reset run" \ >> -c "shutdown" >> >> Regards, >> ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] usb: net: Add support for Microchip LAN75xx and LAN78xx
On Thu, Aug 10, 2017 at 1:13 PM, wrote: > Hi Marek, > >>-Original Message- >>From: Marek Vasut [mailto:ma...@denx.de] >>Sent: Wednesday, August 9, 2017 1:12 PM >>To: Yuiko Oshino - C18177; u-boot@lists.denx.de >>Cc: Joe Hershberger >>Subject: Re: [PATCH v3 1/2] usb: net: Add support for Microchip LAN75xx and >>LAN78xx >> >>On 08/09/2017 06:25 PM, yuiko.osh...@microchip.com wrote: >>> From: Yuiko Oshino >>> >>> Series-Changes: 3 >> >>FYI, this will end in the commit message when applied, remove it or move it >>below the --- . Also commit message is missing. > > I did my best to follow the patman instructions and I added "commit-notes:" > tag, but I guess it wasn't good enough. You need to not use commit notes here. That's for things that you want to be a note in the email, but not end up in the commit log. > Should I always manually edit the patch before sending email in the patman? No, you shouldn't have to. The reason this failed to be removed is that you capitalized the 'C' in changes, and it didn't see it. Also, these tags are parsed and included as notes. You don't want to put these in a commit notes tag. That's only needed for other random commit notes. > Also, when I am ready to update this patch again, should I do a series or > just this patch? Do the series. Also, you should have the dependency patch first, and the dependent patch second (swap them around). > How can I update the [PATCH v] number? If just his patch, then will it be > [PATCH v4]? Go ahead and use v4. So use: Series-version: 4 >> >>>- All #ifdef CONFIG_DM_ETH and #endif are removed. >>>- The lan7x_eth_recv() is modifed to correctly support the Driver Model >>> and returns packet_en. >>>- Add mii_resolve_flowctrl_fdx() patch in the series. >>> >>> Series-Changes: 2 >>>- The wait_for_bit functions copy the real one. >>>- Uses phylib >>>- Unnecessary variables are removed >>>- All return values are checked >>>- Uses mii_resolve_flowctrl_fdx() from linux/mii.h >>> >>> Signed-off-by: Yuiko Oshino >>> --- >>> Add support for Microchip LAN7500, LAN7800 and LAN7850, USB to >>> 10/100/1000 Ethernet Controllers. The fact that this is in the notes means that you put it under "Commit-notes:" ... "END" >>> >>> >>> drivers/usb/Kconfig | 2 + >>> drivers/usb/eth/Kconfig | 17 ++ >>> drivers/usb/eth/Makefile | 2 + >>> drivers/usb/eth/lan75xx.c | 318 + >>> drivers/usb/eth/lan78xx.c | 477 >> >>> drivers/usb/eth/lan7x.c | 495 >>++ >>> drivers/usb/eth/lan7x.h | 230 + >>> 7 files changed, 1541 insertions(+) -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] usb: net: Add support for Microchip LAN75xx and LAN78xx
>-Original Message- >From: Joe Hershberger [mailto:joe.hershber...@ni.com] >Sent: Thursday, August 10, 2017 2:45 PM >To: Yuiko Oshino - C18177 >Cc: Marek Vasut; u-boot; Joe Hershberger >Subject: Re: [U-Boot] [PATCH v3 1/2] usb: net: Add support for Microchip >LAN75xx and LAN78xx > >On Thu, Aug 10, 2017 at 1:13 PM, wrote: >> Hi Marek, >> >>>-Original Message- >>>From: Marek Vasut [mailto:ma...@denx.de] >>>Sent: Wednesday, August 9, 2017 1:12 PM >>>To: Yuiko Oshino - C18177; u-boot@lists.denx.de >>>Cc: Joe Hershberger >>>Subject: Re: [PATCH v3 1/2] usb: net: Add support for Microchip >>>LAN75xx and LAN78xx >>> >>>On 08/09/2017 06:25 PM, yuiko.osh...@microchip.com wrote: From: Yuiko Oshino Series-Changes: 3 >>> >>>FYI, this will end in the commit message when applied, remove it or >>>move it below the --- . Also commit message is missing. >> >> I did my best to follow the patman instructions and I added "commit-notes:" >> tag, >but I guess it wasn't good enough. > >You need to not use commit notes here. That's for things that you want to be a >note in the email, but not end up in the commit log. Understood. So what is the "commit message" that Marek meant that I missed? > >> Should I always manually edit the patch before sending email in the patman? > >No, you shouldn't have to. The reason this failed to be removed is that you >capitalized the 'C' in changes, and it didn't see it. I see... > >Also, these tags are parsed and included as notes. You don't want to put these >in >a commit notes tag. That's only needed for other random commit notes. > What are "threse"? >> Also, when I am ready to update this patch again, should I do a series or >> just this >patch? > >Do the series. Also, you should have the dependency patch first, and the >dependent patch second (swap them around). > >> How can I update the [PATCH v] number? If just his patch, then will it be >> [PATCH >v4]? > >Go ahead and use v4. So use: > >Series-version: 4 > Got it. >>> - All #ifdef CONFIG_DM_ETH and #endif are removed. - The lan7x_eth_recv() is modifed to correctly support the Driver Model and returns packet_en. - Add mii_resolve_flowctrl_fdx() patch in the series. Series-Changes: 2 - The wait_for_bit functions copy the real one. - Uses phylib - Unnecessary variables are removed - All return values are checked - Uses mii_resolve_flowctrl_fdx() from linux/mii.h Signed-off-by: Yuiko Oshino --- Add support for Microchip LAN7500, LAN7800 and LAN7850, USB to 10/100/1000 Ethernet Controllers. > >The fact that this is in the notes means that you put it under "Commit-notes:" >... >"END" > Yes, I did. Is the Commit-notes: == Commit message? Do I still need this tag? Following tags are all I need? Series-to: u-boot Series-version: 4 Series-changes: 4 Series-changes: 3 Series-changes: 2 Series-changes: 1 Signed-off-by: Yuiko Oshino Should I add Acked-by:? drivers/usb/Kconfig | 2 + drivers/usb/eth/Kconfig | 17 ++ drivers/usb/eth/Makefile | 2 + drivers/usb/eth/lan75xx.c | 318 + drivers/usb/eth/lan78xx.c | 477 >>> drivers/usb/eth/lan7x.c | 495 >>>++ drivers/usb/eth/lan7x.h | 230 + 7 files changed, 1541 insertions(+) > >-Joe Thank you, Joe. Yuiko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull from u-boot-i2c
On Thu, Aug 10, 2017 at 12:09:58PM +0200, Heiko Schocher wrote: > Hello Tom, > > The following changes since commit 1989374b21089c63019fc9648408c8d609023ffe: > > configs: Finish migration of PHY_GIGE (2017-08-08 17:02:31 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-i2c.git master > > for you to fetch changes up to 014e47f028526689aaa8ecb2e9164572937afe44: > > i2c: designware: Allow sending restart conditions (2017-08-10 12:02:50 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-marvell/master
On Thu, Aug 10, 2017 at 10:26:32AM +0200, Stefan Roese wrote: > Hi Tom, > > please pull the mvpp2x net patches from Stefan Chulski, which have > been missed for quite some time. All have been acked by Joe. > > Thanks, > Stefan > > > The following changes since commit d529124fdcf941c34074fd1ce600f4b1b4a7dd07: > > Merge git://git.denx.de/u-boot-x86 (2017-08-08 17:06:19 -0400) > > are available in the git repository at: > > git://www.denx.de/git/u-boot-marvell.git > > for you to fetch changes up to ceec6c48a472514e6110d07064006258376d4537: > > net: mvpp2x: Set BM poll size once during priv probe (2017-08-10 08:33:02 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-rockchip/master
Hello Tom, The following changes since commit d529124fdcf941c34074fd1ce600f4b1b4a7dd07: Merge git://git.denx.de/u-boot-x86 (2017-08-08 17:06:19 -0400) are available in the git repository at: git://git.denx.de/u-boot-rockchip.git master for you to fetch changes up to 6785e701b70a5e12a3dbb2f50972cc97e5bd9dd5: rockchip: clk: remove RATE_TO_DIV (2017-08-10 14:49:19 +0200) Andy Yan (3): rockchip: add u-boot specific dts for rk3368 based boards rockchip: set Pre-reloc malloc pool size to 4kb for rk3368 based boards rockchip: remove the hard coded uart iomux setting for px5 evb Kever Yang (6): rockchip: rk3288: fix EMMC_DIV_MASK definition in header rockchip: rk322x: set the DDR region as non-secure in SPL rockchip: dts: rk322x: add sdmmc device node rockchip: rk322x: update max-frequency for mmc node rockchip: clk: update dwmmc clock div rockchip: clk: remove RATE_TO_DIV Klaus Goger (1): rockchip: board: puma_rk3399: rename ATF firmware Philipp Tomsich (76): spl: add a 'return to bootrom' boot method spl: configure 'return to bootrom' separately for SPL and TPL rockchip: back-to-bootrom: add 'back-to-bootrom' support for AArch64 rockchip: back-to-bootrom: split BACK_TO_BOOTROM for TPL/SPL rockchip: back-to-bootrom: simplify the #ifdef-check for LIBCOMMON in TPL/SPL spl: use TPL_SYS_MALLOC_F_LEN for TPL spl: dm: Kconfig: fix help text for SPL/TPL confusion spl: dm: Kconfig: use more specific prereqs for SPL_REGMAP and SPL_SYSCON spl: dm: Kconfig: split REGMAP/SYSCON support for TPL from SPL spl: dm: Kconfig: SPL_RAM depends on SPL_DM spl: dm: Kconfig: introduce TPL_RAM (in analogy to SPL_RAM) spl: dm: Kconfig: SPL_CLK depends on SPL_DM spl: dm: Kconfig: split CLK support for SPL and TPL spl: dm: Kconfig: split OF_CONTROL and OF_PLATDATA between SPL and TPL spl: dm: use CONFIG_IS_ENABLED to test for the DM option armv8: move low-level assembly functions into function-sections armv8: spl: Support separate stack for TPL spl: allow a separate TEXT_BASE, LDSCRIPT and MAX_SIZE for TPL spl: Kconfig: split SYS_MALLOC_SIMPLE for TPL and SPL lib: spl: differentiate between TPL and SPL for libfdt/of_control/of_platdata spl: consistently use $(SPL_TPL_) to select features for SPL and TPL builds spl: add TPL_DRIVER_MISC_SUPPORT option drivers: spl: consistently use the $(SPL_TPL_) macro rockchip: Makefile: allow selective inclusion of sdram_common.o from TPL/SPL/U-Boot rockchip: rk3368: improve Kconfig text for the RK3368 rockchip: rk3368: mkimage: add support for the RK3368 rockchip: rk3368: pmugrf: add definitions for os_reg[0..3] rockchip: rk3368: spl: define COUNTER_FREQUENCY to 24MHz rockchip: rk3368: spl: add memory layout for TPL and SPL rockchip: rk3368: syscon: MSCH/PMUGRF/GRF support for OF_PLATDATA rockchip: rk3368: syscon: SGRF support for OF_PLATDATA rockchip: rk3368: grf: use shifted-constants rockchip: rk3368: dts: add sgrf node rockchip: pinctrl: rk3368: add GMAC (RGMII only) support rockchip: pinctrl: rk3368: add support for configuring the MMC pins rockchip: pinctrl: rk3368: move IOMUX bit-definitions to pinctrl driver rockchip: pinctrl: rk3368: add SPI support rockchip: clk: rk3368: implement bandwidth adjust for PLLs rockchip: clk: rk3368: support OF_PLATDATA for the RK3368 clk driver rockchip: clk: rk3368: do not change CPLL/GPLL before returning to BROM rockchip: clk: rk3368: implement DPLL (DRAM PLL) support rockchip: clk: rk3368: define DMA1_SRST_REQ and DMA2_SRST_REQ rockchip: clk: rk3368: implement MMC/SD clock reparenting rockchip: clk: rk3368: support configuring the DRAM PLL (from TPL) rockchip: clk: rk3368: add support for GMAC (SLCK_MAC) clock rockchip: clk: rk3368: mark 'priv' __maybe_unused in rk3368_clk_set_rate() rockchip: clk: rk3368: add support for configuring the SPI clocks net: gmac_rockchip: Add support for the RK3368 GMAC rockchip: Makefile: streamline SPL/TPL configuration rockchip: rk3368: add DRAM controller driver with DRAM initialisation rockchip: rk3368: dts: add DMC node in rk3368.dtsi rockchip: rk3368: spl: enable SPL_FRAMEWORK in rk3368_common.h rockchip: rk3368: spl: add TPL support rockchip: spl: make spl-boot-order code reusable (split from rk3399) rockchip: rk3368: spl: add SPL support rockchip: rk3368: spl: mark SPL and TPL as supported for ROCKCHIP_RK3368 rockchip: spi: enable support for the rk_spi driver for the RK3368 rockchip: board: lion-rk3368: add support for the RK3368-uQ7 spl: Kconfig: migrate $(SPL_TPL_)LDSCRIPT to Kconfig rockchip: Kconfig: preset TPL_LDSCRIPT via
Re: [U-Boot] [PATCH v3 1/2] usb: net: Add support for Microchip LAN75xx and LAN78xx
On Thu, Aug 10, 2017 at 2:32 PM, wrote: >>-Original Message- >>From: Joe Hershberger [mailto:joe.hershber...@ni.com] >>Sent: Thursday, August 10, 2017 2:45 PM >>To: Yuiko Oshino - C18177 >>Cc: Marek Vasut; u-boot; Joe Hershberger >>Subject: Re: [U-Boot] [PATCH v3 1/2] usb: net: Add support for Microchip >>LAN75xx and LAN78xx >> >>On Thu, Aug 10, 2017 at 1:13 PM, wrote: >>> Hi Marek, >>> -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Wednesday, August 9, 2017 1:12 PM To: Yuiko Oshino - C18177; u-boot@lists.denx.de Cc: Joe Hershberger Subject: Re: [PATCH v3 1/2] usb: net: Add support for Microchip LAN75xx and LAN78xx On 08/09/2017 06:25 PM, yuiko.osh...@microchip.com wrote: > From: Yuiko Oshino > > Series-Changes: 3 FYI, this will end in the commit message when applied, remove it or move it below the --- . Also commit message is missing. >>> >>> I did my best to follow the patman instructions and I added "commit-notes:" >>> tag, >>but I guess it wasn't good enough. >> >>You need to not use commit notes here. That's for things that you want to be a >>note in the email, but not end up in the commit log. > > Understood. So what is the "commit message" that Marek meant that I missed? This: Add support for Microchip LAN7500, LAN7800 and LAN7850, USB to 10/100/1000 Ethernet Controllers. > >> >>> Should I always manually edit the patch before sending email in the patman? >> >>No, you shouldn't have to. The reason this failed to be removed is that you >>capitalized the 'C' in changes, and it didn't see it. > > I see... > >> >>Also, these tags are parsed and included as notes. You don't want to put >>these in >>a commit notes tag. That's only needed for other random commit notes. >> > What are "threse"? The tags I was referring to the Series-*: tags. It seemed like you were putting those tags into the Commit-notes: since that's there they should ultimately end up, but I'm saying that it happens for you. There should not be any nested tags. >>> Also, when I am ready to update this patch again, should I do a series or >>> just this >>patch? >> >>Do the series. Also, you should have the dependency patch first, and the >>dependent patch second (swap them around). >> >>> How can I update the [PATCH v] number? If just his patch, then will it be >>> [PATCH >>v4]? >> >>Go ahead and use v4. So use: >> >>Series-version: 4 >> > > Got it. > >- All #ifdef CONFIG_DM_ETH and #endif are removed. >- The lan7x_eth_recv() is modifed to correctly support the Driver Model > and returns packet_en. >- Add mii_resolve_flowctrl_fdx() patch in the series. > > Series-Changes: 2 >- The wait_for_bit functions copy the real one. >- Uses phylib >- Unnecessary variables are removed >- All return values are checked >- Uses mii_resolve_flowctrl_fdx() from linux/mii.h > > Signed-off-by: Yuiko Oshino > --- > Add support for Microchip LAN7500, LAN7800 and LAN7850, USB to > 10/100/1000 Ethernet Controllers. >> >>The fact that this is in the notes means that you put it under >>"Commit-notes:" ... >>"END" >> > Yes, I did. Is the Commit-notes: == Commit message? That's not correct. Commit-notes: is for the random other notes that you want not to be in git. Just like not using patman, the standard un-tagged text is the Commit message. > Do I still need this tag? No, unless you have something to say in the notes beyond the change comments. > Following tags are all I need? > Series-to: u-boot > Series-version: 4 > Series-changes: 4 > Series-changes: 3 > Series-changes: 2 > Series-changes: 1 Presumably there is no change for the initial version. > Signed-off-by: Yuiko Oshino > > Should I add Acked-by:? Yes, you should add any Acked-by that you got on a previous version to the commit so it is already included in all following versions. > > > drivers/usb/Kconfig | 2 + > drivers/usb/eth/Kconfig | 17 ++ > drivers/usb/eth/Makefile | 2 + > drivers/usb/eth/lan75xx.c | 318 + > drivers/usb/eth/lan78xx.c | 477 > drivers/usb/eth/lan7x.c | 495 ++ > drivers/usb/eth/lan7x.h | 230 + > 7 files changed, 1541 insertions(+) >> >>-Joe > > Thank you, Joe. > Yuiko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH] arm: dts: am33xx: Remove redundant interrupt-parent property
On Thu, Aug 10, 2017 at 03:40:24PM +0530, suni...@techveda.org wrote: > From: Suniel Mahesh > > Upstream Linux has the Interrupt-parent property being removed > from mmc, mac, lcdc and tscadc sub nodes in the dtsi file. > Interrupt-parent property is already defined in the root node. > Therefore, update the dtsi to mimic this change and remove duplicates. > > Signed-off-by: Suniel Mahesh > --- > Note: > - Compile tested on latest u-boot mainline tree no build issues. > - commit information upstream Linux: > arm: dts: am33xx: Remove redundant interrupt-parent property > sha1: de09eb52a1cceb6f80464a008c67c7bebb242314 Can you please re-sync with that commit ID for all am33xx DTS files and mention it (or perhaps v4.13-rc3 or so) in the commit message? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] sf: improve support of (Q)SPI flash memories
Hi All, Do you have some comment on it? On 2017/7/25 15:00, Wenyou Yang wrote: This series of patches are based and have been tested on the 'master' branch of the u-boot.git tree. Tests were passed with a sama5d2 xplained board which embeds both SPI and QSPI controllers. The following tests have been passed: - QSPI0 + Macronix MX25L25673G: + probe: OK + Fast Read 1-1-4 at offset 0x1 (u-boot env): OK + Page Program 1-1-4 at offset 0x1: OK The Macronix datasheet tells that only Page Program 1-4-4 is supported, not Page Program 1-1-4, however it worked, I don't know why... - QSPI0 + Microchip SST26 + probe: OK + Fast Read 1-1-4 at offset 0x1 (u-boot env): OK + Page Program 1-1-1 at offset 0x1: OK SST26 memories support Page Program 1-4-4 but with the op code of Page Program 1-1-4, which is not standard so I don't use it. - QSPI0 + Adesto AT25DF321A + probe: OK + Fast Read 1-1-1 at offset 0x1 (u-boot env): OK + Page Program 1-1-1 at offset 0x1: OK - SPI0 + Adesto AT25DF321A + probe: OK + Fast Read 1-1-1 at offset 0x6000 (u-boot env): OK + Page Program 1-1-1 at offest 0x6000: OK - SPI1 + Atmel AT45 + probe: OK + Read at offset 0 and other than 0: OK + Write at offset 0 and other than 0: OK During my tests, I used: - setenv/saveenv, reboot, printenv or - sf probe, sf read, sf write, sf erase and sf update. Changes in v3: - Add the include to fix build error for corvus_defconfig. Changes in v2: - Rebase on the latest u-boot/master(2710d54f5). Cyrille Pitchen (8): spi: add support of SPI flash commands sf: describe all SPI flash commands with 'struct spi_flash_command' sf: select the relevant SPI flash protocol for read and write commands sf: differentiate Page Program 1-1-4 and 1-4-4 sf: add 'addr_len' member to 'struct spi_flash' sf: add new option to support SPI flash above 16MiB sf: add support to Microchip SST26 QSPI memories sf: add driver for Atmel QSPI controller drivers/mtd/spi/Kconfig | 16 +- drivers/mtd/spi/sf.c| 78 ++-- drivers/mtd/spi/sf_dataflash.c | 119 ++-- drivers/mtd/spi/sf_internal.h | 48 +++-- drivers/mtd/spi/spi_flash.c | 341 +++-- drivers/mtd/spi/spi_flash_ids.c | 5 + drivers/spi/Kconfig | 7 + drivers/spi/Makefile| 1 + drivers/spi/atmel_qspi.c| 404 drivers/spi/atmel_qspi.h| 169 + drivers/spi/spi-uclass.c| 40 drivers/spi/spi.c | 13 ++ include/spi.h | 168 + include/spi_flash.h | 7 + 14 files changed, 1226 insertions(+), 190 deletions(-) create mode 100644 drivers/spi/atmel_qspi.c create mode 100644 drivers/spi/atmel_qspi.h Best Regards, Wenyou Yang ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: layerscape platform pcie link up state judgment strongly
Hi York, I will add the inline comment in the patch, send it to you later. thanks -Original Message- From: York Sun Sent: Wednesday, August 09, 2017 12:14 AM To: Xiaowei Bao ; u-boot@lists.denx.de; Priyanka Jain ; Z.q. Hou ; M.h. Lian ; s...@chromium.org Subject: Re: [PATCH] armv8: layerscape platform pcie link up state judgment strongly On 08/07/2017 11:56 PM, Xiaowei Bao wrote: > Hi York, > > I will pay attention to the case of the case in commit message. > > This patch is for some special reset times for longer pcie devices, in this > case, the pcie device may on polling compliance state, the RC considers the > pcie device is link up, but the pcie device is not link up, only the L0 state > is link up state. So add the link up status judgement mechanisms. > > About 100ms timeout, the pcie spec does not specify the link up timeout time, > and the link up state is determined by a state machine. The state machine > implementation is relatively complex, refer to uboot of other platform pcie > link up state to determine the realization of the mechanism, we evaluated a > timeout, in detect state consider the pcie device is link down, in L0 state > consider the pcie device is link up, within 100ms in other states can be > restored to the L0 state considers the pcie device is link up . Can you put this information to inline comment? It will help us when we read the code later. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-fsl-qoriq master
On Thu, Aug 10, 2017 at 03:34:49PM +, York Sun wrote: > Tom, > > The following changes since commit eaa90e5df2a4a1cb12fb73571978a9379242d0b5: > >common/env_embedded.c: rename PPCENV/PPCTEXT macros (2017-08-04 > 20:38:39 -0400) > > are available in the git repository at: > >git://git.denx.de/u-boot-fsl-qoriq.git > > for you to fetch changes up to 1c83df6f3f95055ed1c8fb40d1d0604863eab78b: > >armv8: ls2080a: Increase env sector size for qspi boot (2017-08-09 > 09:57:33 -0700) > This seems to lead to a number of PowerPC boards failing, can you please throw this at travis-ci and fix the fallout? See https://travis-ci.org/trini/u-boot/builds/263245350, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-rockchip/master
On Thu, Aug 10, 2017 at 10:17:46PM +0200, Dr. Philipp Tomsich wrote: > Hello Tom, > > The following changes since commit d529124fdcf941c34074fd1ce600f4b1b4a7dd07: > > Merge git://git.denx.de/u-boot-x86 (2017-08-08 17:06:19 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-rockchip.git master > > for you to fetch changes up to 6785e701b70a5e12a3dbb2f50972cc97e5bd9dd5: > > rockchip: clk: remove RATE_TO_DIV (2017-08-10 14:49:19 +0200) > This seems to lead to a number of odds-and-end boards failing (maybe some more races exposed?), can you please throw this at travis-ci and fix the fallout? See https://travis-ci.org/trini/u-boot/builds/263245350, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-fsl-qoriq master
On 08/10/2017 07:18 PM, Tom Rini wrote: > On Thu, Aug 10, 2017 at 03:34:49PM +, York Sun wrote: > >> Tom, >> >> The following changes since commit eaa90e5df2a4a1cb12fb73571978a9379242d0b5: >> >> common/env_embedded.c: rename PPCENV/PPCTEXT macros (2017-08-04 >> 20:38:39 -0400) >> >> are available in the git repository at: >> >> git://git.denx.de/u-boot-fsl-qoriq.git >> >> for you to fetch changes up to 1c83df6f3f95055ed1c8fb40d1d0604863eab78b: >> >> armv8: ls2080a: Increase env sector size for qspi boot (2017-08-09 >> 09:57:33 -0700) >> > > This seems to lead to a number of PowerPC boards failing, can you please > throw this at travis-ci and fix the fallout? See > https://travis-ci.org/trini/u-boot/builds/263245350, thanks! > I made sure the compiling was OK before request a pull. See https://travis-ci.org/yorksun/u-boot/builds/262844095. Your travis build is still on-going. I will check a little bit later. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] sf: improve support of (Q)SPI flash memories
On Fri, Aug 11, 2017 at 6:32 AM, Yang, Wenyou wrote: > Hi All, > > Do you have some comment on it? Yes, Will come back. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 1/3] armv8:fsl-layerscape: Consolidate registers space defination for CCI-400 bus
CoreLink Cache Coherent Interconnect (CCI) is ARM BUS which provides full cache coherency between two clusters of multi-core CPUs and I/O coherency for devices and I/O masters. This patch add new CONFIG defination "SYS_FSL_HAS_CCI400" and moves existing register space definaton of CCI-400 bus from immap_lsch2 to fsl_immap, so that it can be used for both chasis 2 and chasis 3. "CONFIG_SYS_CCI400_ADDR" is depricated and new SYS_CCI400_OFFSET is introduced in Kconfig Signed-off-by: Ashish Kumar Signed-off-by: Prabhakar Kushwaha --- v3: This is v3 for https://patchwork.ozlabs.org/patch/731464/ v4: Header file included in middle of the file in cpu.c v5: Moving ls1021aqds to 2/3-armv7 of this patch-set README | 9 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 13 ++ arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 1 + arch/arm/cpu/armv8/fsl-layerscape/soc.c| 10 +++-- .../include/asm/arch-fsl-layerscape/immap_lsch2.h | 49 - board/freescale/ls1012afrdm/ls1012afrdm.c | 4 +- board/freescale/ls1012aqds/ls1012aqds.c| 4 +- board/freescale/ls1012ardb/ls1012ardb.c| 3 +- include/fsl_immap.h| 51 ++ 9 files changed, 88 insertions(+), 56 deletions(-) diff --git a/README b/README index 3735916..a66a7ae 100644 --- a/README +++ b/README @@ -312,6 +312,15 @@ Many of the options are named exactly as the corresponding Linux kernel configuration options. The intention is to make it easier to build a config tool - later. +- ARM Platform Bus Type(CCI): + CoreLink Cache Coherent Interconnect (CCI) is ARM BUS which + provides full cache coherency between two clusters of multi-core + CPUs and I/O coherency for devices and I/O masters + + CONFIG_SYS_FSL_HAS_CCI400 + + Defined For SoC that has cache coherent interconnect + CCN-400 The following options need to be configured: diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig index 5825f9b..1132969 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig @@ -84,6 +84,7 @@ config ARCH_LS2080A config FSL_LSCH2 bool + select SYS_FSL_HAS_CCI400 select SYS_FSL_HAS_SEC select SYS_FSL_SEC_COMPAT_5 select SYS_FSL_SEC_BE @@ -247,6 +248,15 @@ config QSPI_AHB_INIT But some QSPI flash size up to 64MBytes, so initialize the QSPI AHB bus for those flashes to support the full QSPI flash size. +config SYS_CCI400_OFFSET + hex "Offset for CCI400 base" + depends on SYS_FSL_HAS_CCI400 + default 0x309 if ARCH_LS1088A + default 0x18 if FSL_LSCH2 + help + Offset for CCI400 base + CCI400 base addr = CCSRBAR + CCI400_OFFSET + config SYS_FSL_IFC_BANK_COUNT int "Maximum banks of Integrated flash controller" depends on ARCH_LS1043A || ARCH_LS1046A || ARCH_LS2080A @@ -254,6 +264,9 @@ config SYS_FSL_IFC_BANK_COUNT default 4 if ARCH_LS1046A default 8 if ARCH_LS2080A +config SYS_FSL_HAS_CCI400 + bool + config SYS_FSL_HAS_DP_DDR bool diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c index c6fede3..ec58065 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c b/arch/arm/cpu/armv8/fsl-layerscape/soc.c index aee1ffa..ddb7d82 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c @@ -5,6 +5,7 @@ */ #include +#include #include #include #include @@ -285,7 +286,8 @@ static void erratum_a008850_early(void) { #ifdef CONFIG_SYS_FSL_ERRATUM_A008850 /* part 1 of 2 */ - struct ccsr_cci400 __iomem *cci = (void *)CONFIG_SYS_CCI400_ADDR; + struct ccsr_cci400 __iomem *cci = (void *)(CONFIG_SYS_IMMR + + CONFIG_SYS_CCI400_OFFSET); struct ccsr_ddr __iomem *ddr = (void *)CONFIG_SYS_FSL_DDR_ADDR; /* Skip if running at lower exception level */ @@ -304,7 +306,8 @@ void erratum_a008850_post(void) { #ifdef CONFIG_SYS_FSL_ERRATUM_A008850 /* part 2 of 2 */ - struct ccsr_cci400 __iomem *cci = (void *)CONFIG_SYS_CCI400_ADDR; + struct ccsr_cci400 __iomem *cci = (void *)(CONFIG_SYS_IMMR + + CONFIG_SYS_CCI400_OFFSET); struct ccsr_ddr __iomem *ddr = (void *)CONFIG_SYS_FSL_DDR_ADDR; u32 tmp; @@ -439,7 +442,8 @@ int setup_chip_volt(void) void fsl_lsch2_early_init_f(void) { - struct ccsr_cci400 *cci = (struct ccsr_cci400 *)CONFIG_SYS
[U-Boot] [PATCH v5 3/3] whitelist: Remove "CONFIG_SYS_CCI400_ADDR" from whitelist
This config is depricated and new config SYS_CCI400_OFFSET is introduced in Kconfig Signed-off-by: Ashish Kumar --- v3: This is v3 for https://patchwork.ozlabs.org/patch/731464/ v4: No change v5: NO change scripts/config_whitelist.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 2dacf79..a4c0c6e 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -2490,7 +2490,6 @@ CONFIG_SYS_CACHE_STASHING CONFIG_SYS_CADMUS_BASE_REG CONFIG_SYS_CBSIZE CONFIG_SYS_CCCR -CONFIG_SYS_CCI400_ADDR CONFIG_SYS_CCSRBAR CONFIG_SYS_CCSRBAR_PHYS CONFIG_SYS_CCSRBAR_PHYS_HIGH -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 2/3] armv7: Consolidate registers space defination for CCI-400 bus
CoreLink Cache Coherent Interconnect (CCI) is ARM BUS which provides full cache coherency between two clusters of multi-core CPUs and I/O coherency for devices and I/O masters. This patch add new CONFIG defination "FSL_SYS_HAS_CCI400" and removes register space definaton of CCI-400 bus from immap_ls102xa to fsl_immap, since same is defined there already "CONFIG_SYS_CCI400_ADDR" is depricated and new SYS_CCI400_OFFSET is introduced in Kconfig Signed-off-by: Ashish Kumar --- v3: This is v3 for https://patchwork.ozlabs.org/patch/731464/ v4: No change v5: Moving ls1021aqds here arch/arm/cpu/armv7/ls102xa/Kconfig| 12 ++ arch/arm/cpu/armv7/ls102xa/soc.c | 3 +- arch/arm/include/asm/arch-ls102xa/config.h| 1 - arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 49 +-- board/freescale/ls1021aqds/ls1021aqds.c | 9 +++-- 5 files changed, 22 insertions(+), 52 deletions(-) diff --git a/arch/arm/cpu/armv7/ls102xa/Kconfig b/arch/arm/cpu/armv7/ls102xa/Kconfig index 6a013b2..61dd522 100644 --- a/arch/arm/cpu/armv7/ls102xa/Kconfig +++ b/arch/arm/cpu/armv7/ls102xa/Kconfig @@ -5,6 +5,7 @@ config ARCH_LS1021A select SYS_FSL_ERRATUM_A009663 select SYS_FSL_ERRATUM_A009942 select SYS_FSL_ERRATUM_A010315 + select SYS_FSL_HAS_CCI400 select SYS_FSL_SRDS_1 select SYS_HAS_SERDES select SYS_FSL_DDR_BE if SYS_FSL_DDR @@ -48,9 +49,20 @@ config SECURE_BOOT Enable Freescale Secure Boot feature. Normally selected by defconfig. If unsure, do not change. +config SYS_CCI400_OFFSET + hex "Offset for CCI400 base" + depends on SYS_FSL_HAS_CCI400 + default 0x18 + help + Offset for CCI400 base. + CCI400 base addr = CCSRBAR + CCI400_OFFSET + config SYS_FSL_ERRATUM_A010315 bool "Workaround for PCIe erratum A010315" +config SYS_FSL_HAS_CCI400 + bool + config SYS_FSL_SRDS_1 bool diff --git a/arch/arm/cpu/armv7/ls102xa/soc.c b/arch/arm/cpu/armv7/ls102xa/soc.c index b84a1a6..c043b82 100644 --- a/arch/arm/cpu/armv7/ls102xa/soc.c +++ b/arch/arm/cpu/armv7/ls102xa/soc.c @@ -80,7 +80,8 @@ void erratum_a010315(void) int arch_soc_init(void) { struct ccsr_scfg *scfg = (struct ccsr_scfg *)CONFIG_SYS_FSL_SCFG_ADDR; - struct ccsr_cci400 *cci = (struct ccsr_cci400 *)CONFIG_SYS_CCI400_ADDR; + struct ccsr_cci400 *cci = (struct ccsr_cci400 *)(CONFIG_SYS_IMMR + + CONFIG_SYS_CCI400_OFFSET); unsigned int major; #ifdef CONFIG_LAYERSCAPE_NS_ACCESS diff --git a/arch/arm/include/asm/arch-ls102xa/config.h b/arch/arm/include/asm/arch-ls102xa/config.h index fc954c5..ff0fc47 100644 --- a/arch/arm/include/asm/arch-ls102xa/config.h +++ b/arch/arm/include/asm/arch-ls102xa/config.h @@ -20,7 +20,6 @@ #define SYS_FSL_GIC_ADDR (CONFIG_SYS_IMMR + 0x0040) #define CONFIG_SYS_FSL_DDR_ADDR(CONFIG_SYS_IMMR + 0x0008) -#define CONFIG_SYS_CCI400_ADDR (CONFIG_SYS_IMMR + 0x0018) #define CONFIG_SYS_FSL_CSU_ADDR (CONFIG_SYS_IMMR + 0x0051) #define CONFIG_SYS_IFC_ADDR(CONFIG_SYS_IMMR + 0x0053) #define CONFIG_SYS_FSL_ESDHC_ADDR (CONFIG_SYS_IMMR + 0x0056) diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h index c34fd63..1415b0b 100644 --- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h +++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h @@ -6,6 +6,7 @@ #ifndef __ASM_ARCH_LS102XA_IMMAP_H_ #define __ASM_ARCH_LS102XA_IMMAP_H_ +#include #define SVR_MAJ(svr) (((svr) >> 4) & 0xf) #define SVR_MIN(svr) (((svr) >> 0) & 0xf) @@ -374,53 +375,7 @@ struct ccsr_serdes { u8 res_a00[0x1000-0xa00]; /* from 0xa00 to 0xfff */ }; -#define CCI400_CTRLORD_TERM_BARRIER0x0008 -#define CCI400_CTRLORD_EN_BARRIER 0 -#define CCI400_SHAORD_NON_SHAREABLE0x0002 -#define CCI400_DVM_MESSAGE_REQ_EN 0x0002 -#define CCI400_SNOOP_REQ_EN0x0001 - -/* CCI-400 registers */ -struct ccsr_cci400 { - u32 ctrl_ord; /* Control Override */ - u32 spec_ctrl; /* Speculation Control */ - u32 secure_access; /* Secure Access */ - u32 status; /* Status */ - u32 impr_err; /* Imprecise Error */ - u8 res_14[0x100 - 0x14]; - u32 pmcr; /* Performance Monitor Control */ - u8 res_104[0xfd0 - 0x104]; - u32 pid[8]; /* Peripheral ID */ - u32 cid[4]; /* Component ID */ - struct { - u32 snoop_ctrl; /* Snoop Control */ - u32 sha_ord;/* Shareable Override */ - u8 res_1008[0x110
Re: [U-Boot] [PATCH] drivers:net:fsl-mc: Update MC address calculation
> -Original Message- > From: York Sun > Sent: Wednesday, August 09, 2017 10:19 PM > To: Priyanka Jain ; u-boot@lists.denx.de > Cc: Ashish Kumar > Subject: Re: [PATCH] drivers:net:fsl-mc: Update MC address calculation > > On 06/23/2017 03:30 AM, Priyanka Jain wrote: > > Update MC address caluclation as per MC design requirement of address > > as least significant 512MB address of MC private allocated memory. > > > > Signed-off-by: Priyanka Jain > > Signed-off-by: Ashish Kumar > > --- > > drivers/net/fsl-mc/mc.c |7 ++- > > 1 files changed, 6 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c index > > eeecb2d..623586c 100644 > > --- a/drivers/net/fsl-mc/mc.c > > +++ b/drivers/net/fsl-mc/mc.c > > @@ -704,10 +704,15 @@ int get_dpl_apply_status(void) > > > > /** > >* Return the MC address of private DRAM block. > > + * MC address should be least significant 512MB address > > + * of MC private memory > >*/ > > u64 mc_get_dram_addr(void) > > { > > - return gd->arch.resv_ram; > > + size_t mc_ram_size = mc_get_dram_block_size(); > > + > > + return (gd->arch.resv_ram + mc_ram_size - 1) & > > + MC_RAM_BASE_ADDR_ALIGNMENT_MASK; > > } > > > > /** > > > > Priyanka, > > This looks odd. You already have the address aligned by > CONFIG_SYS_MC_RSV_MEM_ALIGN (512MB by default), tracked by > gd->arch.resv_ram. Did you find the address is wrong sometimes? > > York York, As per MC design requirement, MC memory should be 512MB aligned for which start address is gd->arch.resv_ram. But the MC core's initial boot address should not contain start address. It must be located in the least significant 512MB of its address range. So this change is basically shifting address from start of memory towards end of Memory (which is least significant 512MB address). Priyanka ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [UBOOT] [PATCH] cmd: usb: ignore block devices under mass storage device
usb tree and info commands may cause crash otherwise Signed-off-by: Suneel Garapati --- cmd/usb.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/cmd/usb.c b/cmd/usb.c index 992d414..81e1a7b 100644 --- a/cmd/usb.c +++ b/cmd/usb.c @@ -415,7 +415,8 @@ static void usb_show_tree_graph(struct usb_device *dev, char *pre) udev = dev_get_parent_priv(child); /* Ignore emulators, we only want real devices */ - if (device_get_uclass_id(child) != UCLASS_USB_EMUL) { + if (device_get_uclass_id(child) != + (UCLASS_USB_EMUL | UCLASS_BLK)) { usb_show_tree_graph(udev, pre); pre[index] = 0; } @@ -605,7 +606,8 @@ static void usb_show_info(struct usb_device *udev) for (device_find_first_child(udev->dev, &child); child; device_find_next_child(&child)) { - if (device_active(child)) { + if (device_active(child) && + (device_get_uclass_id(child) != UCLASS_BLK)) { udev = dev_get_parent_priv(child); usb_show_info(udev); } -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sf: Preserve QE bit when clearing BP# bits for Macronix flash
On Mon, Aug 7, 2017 at 3:54 PM, Jagan Teki wrote: > Hi Bing, > > On Mon, Aug 7, 2017 at 1:09 PM, Bin Meng wrote: >> On Fri, Aug 4, 2017 at 12:21 PM, Bin Meng wrote: >>> On Wed, Aug 2, 2017 at 6:26 AM, Bin Meng wrote: Hi Jagan, On Wed, Aug 2, 2017 at 12:01 AM, Jagan Teki wrote: > On Sun, Jul 23, 2017 at 8:14 PM, Bin Meng wrote: >> On some flash (like Macronix), QE (quad enable) bit is in the same >> status register as BP# bits, and we need preserve its original value >> during a reboot cycle as this is required by some platforms (like >> Intel ICH SPI controller working under descriptor mode). >> >> Signed-off-by: Bin Meng >> --- >> >> drivers/mtd/spi/spi_flash.c | 17 +++-- >> 1 file changed, 15 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c >> index 0034a28..7d8c660 100644 >> --- a/drivers/mtd/spi/spi_flash.c >> +++ b/drivers/mtd/spi/spi_flash.c >> @@ -947,11 +947,24 @@ int spi_flash_scan(struct spi_flash *flash) >> if (IS_ERR_OR_NULL(info)) >> return -ENOENT; >> >> - /* Flash powers up read-only, so clear BP# bits */ >> + /* >> +* Flash powers up read-only, so clear BP# bits. >> +* >> +* Note on some flash (like Macronix), QE (quad enable) bit is >> in the >> +* same status register as BP# bits, and we need preserve its >> original >> +* value during a reboot cycle as this is required by some >> platforms >> +* (like Intel ICH SPI controller working under descriptor mode). >> +*/ >> if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_ATMEL || >> - JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_MACRONIX || >> JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_SST) >> write_sr(flash, 0); >> + if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_MACRONIX) { >> + u8 sr = 0; >> + >> + read_sr(flash, &sr); >> + sr &= STATUS_QEB_MXIC; >> + write_sr(flash, sr); >> + } > > It doesn't make sense to have one(specific) controller fix to be > generic to all macronix chips, think about alternative. > This is no way to fix at the controller level. Actually this is nothing related to controller level. It's just the bootstrap settings (QE bit in this case) that cannot be overwritten by someone else (although it's seen on Intel, it might happen on some other architecture). The logic in the codes are having issues. Its comment says: clear BP# bits, but it clears QE bit for Macronix flash as well, which is wrong. The update was just to make sure the codes do as what its comment says. If you have any other alternative, please suggest. >>> >>> Ping again.. > > Wait for sometime, I've queue that I need to review-it and respond > accordingly patches with latest may take some time. And commenting > yes will respond soon. > Ping! Can you please respond with a reasonable time frame (ie: when you will have time to look at this)? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot