January 2018 - U-Boot

[U-Boot] [PATCH 1/1] efi_loader: do not install NULL as device path
by Heinrich Schuchardt 26 Jan '18

26 Jan '18

In an image is loaded from memory we do not have a device path. Do not install NULL as device path in this case. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- lib/efi_loader/efi_boottime.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 4a36b62828..da93498b36 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -1367,16 +1367,18 @@ efi_status_t efi_setup_loaded_image( obj->handle = info; info->file_path = file_path; - if (device_path) - info->device_handle = efi_dp_find_obj(device_path, NULL); - /* - * When asking for the device path interface, return - * bootefi_device_path - */ - ret = efi_add_protocol(obj->handle, &efi_guid_device_path, device_path); - if (ret != EFI_SUCCESS) - goto failure; + if (device_path) { + info->device_handle = efi_dp_find_obj(device_path, NULL); + /* + * When asking for the device path interface, return + * bootefi_device_path + */ + ret = efi_add_protocol(obj->handle, &efi_guid_device_path, + device_path); + if (ret != EFI_SUCCESS) + goto failure; + } /* * When asking for the loaded_image interface, just -- 2.15.1

1 0

[U-Boot] [PATCH 0/9] LS1012A PFE driver patch series
by Calvin Johnson 26 Jan '18

26 Jan '18

Hi, This patch series introduces U-Boot support for NXP's LS1012A Packet Forwarding Engine (pfe_eth). LS1012A uses hardware packet forwarding engine to provide high performance Ethernet interfaces. The device includes two Ethernet ports. Depends on https://patchwork.ozlabs.org/patch/704305 Regards Calvin Calvin Johnson (9): drivers: net: pfe_eth: LS1012A PFE driver introduction drivers: net: pfe_eth: provide pfe commands drivers: net: pfe_eth: LS1012A PFE headers board: freescale: ls1012a: enable network support on ls1012a platforms armv8: fsl-lsch2: initialize pfe gemac armv8: fsl-lsch2: add pfe macros and update ccsr_scfg structure armv8: fsl-lsch2: configure pfe's scfg & dcfg registers fsl: csu: enable ns access for PFE configs: ls1012a: add pfe configuration for LS1012A arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 8 + arch/arm/cpu/armv8/fsl-layerscape/soc.c | 18 + .../include/asm/arch-fsl-layerscape/immap_lsch2.h | 38 +- .../include/asm/arch-fsl-layerscape/ns_access.h | 2 + arch/arm/include/asm/arch-fsl-layerscape/soc.h | 3 + board/freescale/ls1012afrdm/Makefile | 1 + board/freescale/ls1012afrdm/eth.c | 86 ++ board/freescale/ls1012afrdm/ls1012afrdm.c | 5 - board/freescale/ls1012aqds/Makefile | 1 + board/freescale/ls1012aqds/eth.c | 263 +++++ board/freescale/ls1012aqds/ls1012aqds.c | 97 +- board/freescale/ls1012aqds/ls1012aqds_pfe.h | 48 + board/freescale/ls1012aqds/ls1012aqds_qixis.h | 2 +- board/freescale/ls1012ardb/Makefile | 1 + board/freescale/ls1012ardb/eth.c | 70 ++ board/freescale/ls1012ardb/ls1012ardb.c | 4 - configs/ls1012afrdm_qspi_defconfig | 1 + configs/ls1012aqds_qspi_defconfig | 1 + configs/ls1012ardb_qspi_defconfig | 1 + drivers/net/Kconfig | 1 + drivers/net/Makefile | 1 + drivers/net/pfe_eth/Kconfig | 29 + drivers/net/pfe_eth/Makefile | 11 + drivers/net/pfe_eth/pfe.c | 1161 ++++++++++++++++++++ drivers/net/pfe_eth/pfe_cmd.c | 537 +++++++++ drivers/net/pfe_eth/pfe_driver.c | 626 +++++++++++ drivers/net/pfe_eth/pfe_eth.c | 545 +++++++++ drivers/net/pfe_eth/pfe_firmware.c | 230 ++++ include/configs/ls1012a_common.h | 6 +- include/configs/ls1012afrdm.h | 7 + include/configs/ls1012aqds.h | 14 + include/configs/ls1012ardb.h | 13 + include/pfe_eth/pfe/cbus.h | 75 ++ include/pfe_eth/pfe/cbus/bmu.h | 40 + include/pfe_eth/pfe/cbus/class_csr.h | 181 +++ include/pfe_eth/pfe/cbus/emac.h | 150 +++ include/pfe_eth/pfe/cbus/gpi.h | 62 ++ include/pfe_eth/pfe/cbus/hif.h | 68 ++ include/pfe_eth/pfe/cbus/hif_nocpy.h | 40 + include/pfe_eth/pfe/cbus/tmu_csr.h | 148 +++ include/pfe_eth/pfe/cbus/util_csr.h | 47 + include/pfe_eth/pfe/pfe.h | 178 +++ include/pfe_eth/pfe_driver.h | 55 + include/pfe_eth/pfe_eth.h | 111 ++ include/pfe_eth/pfe_firmware.h | 17 + 45 files changed, 4983 insertions(+), 20 deletions(-) create mode 100644 board/freescale/ls1012afrdm/eth.c create mode 100644 board/freescale/ls1012aqds/eth.c create mode 100644 board/freescale/ls1012aqds/ls1012aqds_pfe.h create mode 100644 board/freescale/ls1012ardb/eth.c create mode 100644 drivers/net/pfe_eth/Kconfig create mode 100644 drivers/net/pfe_eth/Makefile create mode 100644 drivers/net/pfe_eth/pfe.c create mode 100644 drivers/net/pfe_eth/pfe_cmd.c create mode 100644 drivers/net/pfe_eth/pfe_driver.c create mode 100644 drivers/net/pfe_eth/pfe_eth.c create mode 100644 drivers/net/pfe_eth/pfe_firmware.c create mode 100644 include/pfe_eth/pfe/cbus.h create mode 100644 include/pfe_eth/pfe/cbus/bmu.h create mode 100644 include/pfe_eth/pfe/cbus/class_csr.h create mode 100644 include/pfe_eth/pfe/cbus/emac.h create mode 100644 include/pfe_eth/pfe/cbus/gpi.h create mode 100644 include/pfe_eth/pfe/cbus/hif.h create mode 100644 include/pfe_eth/pfe/cbus/hif_nocpy.h create mode 100644 include/pfe_eth/pfe/cbus/tmu_csr.h create mode 100644 include/pfe_eth/pfe/cbus/util_csr.h create mode 100644 include/pfe_eth/pfe/pfe.h create mode 100644 include/pfe_eth/pfe_driver.h create mode 100644 include/pfe_eth/pfe_eth.h create mode 100644 include/pfe_eth/pfe_firmware.h -- 2.7.4

5 20

[U-Boot] [PATCH 1/1] vsprintf.c: correct printing of a NULL device path
by Heinrich Schuchardt 26 Jan '18

26 Jan '18

When printing '%pD' with a value of NULL we want to output '<NULL>'. But this requires copying to buf. Leave this to string16. A unit test is supplied which relies on EFI support in the sandbox. The development for EFI support in the sandbox is currently in branch u-boot-dm/efi-working. The branch lacks commit 6ea8b580f06b ("efi_loader: correct DeviceNodeToText for media types"). Ater rebasing the aforementioned branch on U-Boot v2018.01 and adding 256060e4257a2 and this patch the test is executed successfully. Fixes: 256060e4257a2 (vsprintf.c: add EFI device path printing) Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- Alex, could you pick this up for the efi-next tree, please. --- lib/vsprintf.c | 3 ++- test/print_ut.c | 4 ++++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 226f4eb3e5..5f7a5f17dc 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -300,8 +300,9 @@ static char *device_path_string(char *buf, char *end, void *dp, int field_width, { u16 *str; + /* If dp == NULL output the string '<NULL>' */ if (!dp) - return "<NULL>"; + return string16(buf, end, dp, field_width, precision, flags); str = efi_dp_str((struct efi_device_path *)dp); if (!str) diff --git a/test/print_ut.c b/test/print_ut.c index 1aa68be7a9..d8e9da8fa8 100644 --- a/test/print_ut.c +++ b/test/print_ut.c @@ -44,6 +44,10 @@ static void efi_ut_print(void) snprintf(str, sizeof(str), "_%pD_", buf); assert(!strcmp("_/SD(3)_", str)); + + /* NULL device path */ + snprintf(str, sizeof(str), "_%pD_", NULL); + assert(!strcmp("_<NULL>_", str)); #endif } -- 2.15.1

1 0

[U-Boot] [PATCH] efi_laoder: Call Exit() on return from payload in StartImage()
by Alexander Graf 26 Jan '18

26 Jan '18

When a UEFI payload just returns instead of calling the Exit() callback, we handle that in efi_do_enter() and call Exit on its behalf, so that the loaded_image->exit_status value is correct. We were missing that logic in StartImage(). Call it there too. Reported-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> Signed-off-by: Alexander Graf <agraf(a)suse.de> --- lib/efi_loader/efi_boottime.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index f5dae40f06..4a36b62828 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -1578,8 +1578,13 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t image_handle, ret = EFI_CALL(entry(image_handle, &systab)); - /* Should usually never get here */ - return EFI_EXIT(ret); + /* + * Usually UEFI applications call Exit() instead of returning. + * But because the world doesn not consist of ponies and unicorns, + * we're happy to emulate that behavior on behalf of a payload + * that forgot. + */ + return EFI_CALL(systab.boottime->exit(image_handle, ret, 0, NULL)); } /* -- 2.12.3

2 1

Re: [U-Boot] SquashFS and FIT images
by Chris Packham 26 Jan '18

26 Jan '18

Hi Mark, On 26/01/2018 10:12, "Mathew McBride" <matt(a)bionicmessage.net> wrote: On 26/01/2018 8:01 AM, Bishop, Mark (STRT) wrote: > Is it possible to specify squashFS images in an .its file? If so, anyone > have an example or a pointer to the docs I've been searching for? > Hi Mark, > It is possible, here is an example I have used on an NXP LS1043 board: /dts-v1/; As Matthew's example shows it's totally doable. Furthermore it's not just squashfs it could be any valid initrd. As long as your kernel is configured to expect it u-boot will pass it along. On that note last time i looked most if the general kernel defconfigs didn't have squashfs enabled. / { description = "ARM64 OpenWrt FIT (Flattened Image Tree)"; #address-cells = <1>; images { kernel@1 { description = "ARM64 OpenWrt Linux-4.4"; data = /incbin/("arch/arm64/boot/Image.gz"); type = "kernel"; arch = "arm64"; os = "linux"; compression = "gzip"; load = <0x80080000>; entry = <0x80080000>; }; ramdisk@1 { description = "ARM64 OpenWrt ramdisk"; data = /incbin/("root.squashfs"); type = "ramdisk"; arch = "arm64"; os = "linux"; compression = "gzip"; }; fdt@1 { description = "ARM64 OpenWrt device tree blob"; data = /incbin/("arch/arm64/boot/dts/ freescale/fsl-ls1043a-rdb.dtb"); type = "flat_dt"; arch = "arm64"; compression = "none"; load = <0x90000000>; }; }; configurations { default = "config@1"; config@1 { description = "OpenWrt"; kernel = "kernel@1"; fdt = "fdt@1"; ramdisk = "ramdisk@1"; }; }; }; Cheers, Matt Mark Bishop > Sr. Firmware/Software Engineer - Microwave Subsystems > > [cid:image001.png@01D281ED.A45F0A90] > > 4726 Eisenhower Blvd. > Tampa, FL 33634 > USA > > > T +1 813 901 7293 > > mbishop(a)smithsinterconnectinc.com<mailto:mbishop@smithsinterconnectinc.com > > > > smithsinterconnect.com<http://www.smithsinterconnect.com/> > > TRAK MICROWAVE IS NOW SMITHS INTERCONNECT! > > > > > > > > > _______________________________________________ > U-Boot mailing list > U-Boot(a)lists.denx.de > https://lists.denx.de/listinfo/u-boot > > _______________________________________________ U-Boot mailing list U-Boot(a)lists.denx.de https://lists.denx.de/listinfo/u-boot

1 0

[U-Boot] [PATCH 0/8] Bring NAND support to Nintendo NES Classic
by Miquel Raynal 26 Jan '18

26 Jan '18

Hello, This series adds fixes to sunxi NAND drivers (SPL and U-Boot), in order to later migrate the SPL driver to use PIO instead of DMA to have more generic code (working also on a A33). Finally, NAND support is added to Nintendo NES Classic through Kconfig and DT additions. Thanks, Miquèl Miquel Raynal (8): mtd: nand: sunxi: Fix strength minimum value spl: nand: sunxi: Fix second case of modulo by zero error sunxi: Allow SPL to be compiled for sun8i platforms spl: nand: sunxi: Enhancements and cleaning spl: nand: sunxi: use PIO instead of DMA configs: Add NAND support for NES Classic sunxi: dts: Add NAND node to sun8i DTSI sunxi: dts: Enable NAND on NES classic arch/arm/dts/sun8i-a23-a33.dtsi | 31 +++ arch/arm/dts/sun8i-a33.dtsi | 8 + .../dts/sun8i-r16-nintendo-nes-classic-edition.dts | 14 ++ arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 6 + board/sunxi/board.c | 4 +- configs/Nintendo_NES_Classic_Edition_defconfig | 4 + drivers/mtd/nand/Kconfig | 2 +- drivers/mtd/nand/sunxi_nand.c | 1 + drivers/mtd/nand/sunxi_nand_spl.c | 236 +++++++++++---------- 9 files changed, 188 insertions(+), 118 deletions(-) -- 2.11.0

3 29

[U-Boot] SquashFS and FIT images
by Bishop, Mark (STRT) 26 Jan '18

26 Jan '18

Is it possible to specify squashFS images in an .its file? If so, anyone have an example or a pointer to the docs I've been searching for? Mark Bishop Sr. Firmware/Software Engineer - Microwave Subsystems [cid:image001.png@01D281ED.A45F0A90] 4726 Eisenhower Blvd. Tampa, FL 33634 USA T +1 813 901 7293 mbishop(a)smithsinterconnectinc.com<mailto:mbishop@smithsinterconnectinc.com> smithsinterconnect.com<http://www.smithsinterconnect.com/> TRAK MICROWAVE IS NOW SMITHS INTERCONNECT!

2 1

[U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI
by Heinrich Schuchardt 25 Jan '18

25 Jan '18

The appended README explains how U-Boot and iPXE can be used to boot a diskless system from an iSCSI SAN. The maintainer for README.efi and README.iscsi is set. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- MAINTAINERS | 2 + doc/README.iscsi | 178 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 180 insertions(+) create mode 100644 doc/README.iscsi diff --git a/MAINTAINERS b/MAINTAINERS index d459153503..6e94cee5d3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -286,6 +286,8 @@ EFI PAYLOAD M: Alexander Graf <agraf(a)suse.de> S: Maintained T: git git://github.com/agraf/u-boot.git +F: doc/README.efi +F: doc/README.iscsi F: include/efi* F: lib/efi*/ F: test/py/tests/test_efi* diff --git a/doc/README.iscsi b/doc/README.iscsi new file mode 100644 index 0000000000..f095ad1ddf --- /dev/null +++ b/doc/README.iscsi @@ -0,0 +1,178 @@ +# iSCSI booting with U-Boot and iPXE + +## Motivation + +U-Boot has only a reduced set of supported network protocols. A major gap is +the lack of a TCP stack. + +For booting a diskless computer this leaves us with BOOTP or DHCP to get the +address of a boot script. TFTP can be used to load the boot script and the +operating system kernel and initial file system (initrd). + +These protocols are insecure. The client cannot validate the authenticity +of the contacted servers. And the server cannot verify the identity of the +client. + +Furthermore the services providing the operating system loader or kernel are +not the ones that the operating system will use. Especially in a SAN environment +this makes updating the operating system a hassle. After installing a new +kernel version the boot files have to be copied to the TFTP server directory. + +The HTTPS protocol provides certificate based validation of servers. Sensitive +data like passwords can be securely transmitted. + +The iSCSI protocol is used for connecting storage attached networks. It +provides mutual authentication using the CHAP protocol. It typically runs on +a TCP transport. + +Thus a better solution than DHCP/TFTP boot would be to load a boot script via +HTTPS and to download any other files needed for booting via iSCSI. + +An alternative to implementing these protocols in U-Boot is to use an existing +software that can run on top of U-Boot. iPXE is the "swiss army knife" of +network booting. It supports both HTTPS and iSCSI. It has a script engine for +fine grained control of the boot process and can provide a command shell. + +iPXE can be built as an EFI application (named snp.efi) which can be loaded and +run by U-Boot. + +## Boot sequence + +U-Boot loads the EFI application iPXE snp.efi using the bootefi command. This +application has network access via the simple network protocol offered by +U-Boot. + +iPXE executes its internal script. This script may optionally chain load a +secondary boot script via HTTPS or open a shell. + +For the further boot process iPXE connects to the iSCSI server. This includes +the mutual authentication using the CHAP protocol. After the authentication iPXE +has access to the iSCSI targets. + +For a selected iSCSI target iPXE sets up a handle with the block IO protocol. It +uses the ConnectController boot service of U-Boot to request U-Boot to connect a +file system driver. U-Boot reads from the iSCSI drive via the block IO protocol +offered by iPXE. It creates the partition handles and install the simple file +protocol. Now iPXE can call the simple file protocol to load Grub. U-Boot uses +the block IO protocol offered by iPXE to fulfill the request. + +Once Grub is started it uses the same simple file protocol to load Linux. Via +the EFI stub Linux is called as an EFI application. + +``` + +--------+ +--------+ + | | Runs | | + | U-Boot |=========>| iPXE | + | EFI | | snp.efi| ++--------+ | | DHCP | | +| |<====|********|<=========| | +| DHCP | | | Request | | +| Server | | | | | +| |====>|********|=========>| | ++--------+ | | Response | | + | | | | + | | | | ++--------+ | | HTTPS | | +| |<====|********|<=========| | +| HTTPS | | | Request | | +| Server | | | | | +| |====>|********|=========>| | ++--------+ | | Response | | + | | | | + | | | | ++--------+ | | iSCSI | | +| |<====|********|<=========| | +| iSCSI | | | Auth | | +| Server |====>|********|=========>| | +| | | | | | +| | | | Loads | | +| |<====|********|<=========| | +--------+ +| | | | Grub | | Runs | | +| |====>|********|=========>| |=======>| Grub | +| | | | | | | | +| | | | | | | | +| | | | | | Loads | | +| |<====|********|<=========|********|<=======| | +--------+ +| | | | | | Linux | | Runs | | +| |====>|********|=========>|********|=======>| |=====>| Linux | +| | | | | | | | | | ++--------+ +--------+ +--------+ +--------+ | | + | | + | | + | ~ ~ ~ ~| +``` + +## Security + +The iSCSI protocol is not encrypted. The traffic could be secured using IPsec +but iPXE does not support this. So we should at least separate the iSCSI traffic +from all other network traffic. This can be achieved using a virtual local area +network (VLAN). + +``` + +-----------+ + | | + | | + | iSCSI | + | Server | + | | + | | + +-----------+ + | + |iSCSI + | ++-----------+ +-----------+ +-----------+ +| | VLAN 2 | * | | | +| |----------|****** | | | +| Diskless | | Managed | | Firewall | +| Computer | VLAN 1 | Switch | HTTP | | +| |==========|***********|==========|***********|=====$ +| | | | | | ++-----------+ +-----------+ +-----------+ +``` + +## Configuration + +### iPXE + +For running iPXE on arm64 the bin-arm64-efi/snp.efi build target is needed. + + git clone http://git.ipxe.org/ipxe.git + cd ipxe/src + make bin-arm64-efi/snp.efi -j6 EMBED=myscript.ipxe + +The available commands for the boot script are documented at: + +http://ipxe.org/cmd + +Credentials are managed as environment variables. These are described here: + +http://ipxe.org/cfg + +iPXE by default will put the CPU to rest when waiting for input. U-Boot does +not wake it up due to missing interrupt support. To avoid this behavior create +file src/config/local/nap.h. + + /* nap.h */ + #undef NAP_EFIX86 + #undef NAP_EFIARM + #define NAP_NULL + +The supported commands in iPXE are controlled by an include, too. Putting the +following into src/config/local/general.h is sufficient for most use cases. + + /* general.h */ + #define NSLOOKUP_CMD /* Name resolution command */ + #define PING_CMD /* Ping command */ + #define NTP_CMD /* NTP commands */ + #define VLAN_CMD /* VLAN commands */ + #define IMAGE_EFI /* EFI image support */ + #define DOWNLOAD_PROTO_HTTPS /* Secure Hypertext Transfer Protocol */ + #define DOWNLOAD_PROTO_FTP /* File Transfer Protocol */ + #define DOWNLOAD_PROTO_NFS /* Network File System Protocol */ + #define DOWNLOAD_PROTO_FILE /* Local file system access */ + +## Links + +* https://ipxe.org - iPXE open source boot firmware +* https://www.gnu.org/software/grub/ - GNU Grub (Grand Unified Bootloader) -- 2.11.0

2 2

[U-Boot] [PATCH] usb: ehci: mxs: fix swapped argument in ehci_writel()
by Daniel Schwierzeck 25 Jan '18

25 Jan '18

ehci_writel() swaps the arguments for address and value. One call in ehci-mxs ignores that. This fixes the warning: drivers/usb/host/ehci-mxs.c: In function ?ehci_hcd_stop?: drivers/usb/host/ehci-mxs.c:159:19: error: initialization makes integer from pointer without a cast [-Werror=int-conversion] ehci_writel(tmp, &hcor->or_usbcmd); ^ arch/arm/include/asm/io.h:117:34: note: in definition of macro ?writel? #define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; }) ^ drivers/usb/host/ehci-mxs.c:159:2: note: in expansion of macro ?ehci_writel? ^~~~~~~~~~~ Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck(a)gmail.com> --- drivers/usb/host/ehci-mxs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c index 6b8d969bb0..9872415562 100644 --- a/drivers/usb/host/ehci-mxs.c +++ b/drivers/usb/host/ehci-mxs.c @@ -156,7 +156,7 @@ int ehci_hcd_stop(int index) tmp = ehci_readl(&hcor->or_usbcmd); tmp &= ~CMD_RUN; - ehci_writel(tmp, &hcor->or_usbcmd); + ehci_writel(&hcor->or_usbcmd, tmp); /* Disable the PHY */ tmp = USBPHY_PWD_RXPWDRX | USBPHY_PWD_RXPWDDIFF | -- 2.16.1

1 0

[U-Boot] [PATCH] arc: Eliminate unused code and data with GCC's garbage collector
by Alexey Brodkin 25 Jan '18

25 Jan '18

Finally GCC's garbage collector works on ARC so let's use it. That's what I may see for HSDK: Before: text data bss dec hex filename 290153 10068 222616 522837 7fa55 u-boot After: text data bss dec hex filename 261999 9460 222360 493819 788fb u-boot Overall ~5% of memory footprint saved. Signed-off-by: Alexey Brodkin <abrodkin(a)synopsys.com> --- arch/arc/config.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arc/config.mk b/arch/arc/config.mk index 13676bd0c8e1..a19c188dbcfa 100644 --- a/arch/arc/config.mk +++ b/arch/arc/config.mk @@ -51,9 +51,10 @@ PLATFORM_CPPFLAGS += -mcpu=archs endif PLATFORM_CPPFLAGS += -ffixed-r25 -D__ARC__ -gdwarf-2 +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections # Needed for relocation -LDFLAGS_FINAL += -pie +LDFLAGS_FINAL += -pie --gc-sections # Load address for standalone apps CONFIG_STANDALONE_LOAD_ADDR ?= 0x82000000 -- 2.14.3

1 0