August 2015 - U-Boot

[U-Boot] [PATCH 1/1] tools: mxsboot: calculate ECC block level dynamically
by Jörg Krause 12 Aug '15

12 Aug '15

For pages of 2048 bytes the current setting of the ECC Error Correction Level is only true for an oob size of 64 bytes and wrong for all others. Instead of hard-coding every possible combination of page size and oob size use the dynamic calculation of the ECC strength introduced in commit 6121560d7714d6d8e41ce1687a1388a1a8fea4cb. Cc: Marek Vasut <marex(a)denx.de> Signed-off-by: Jörg Krause <joerg.krause(a)embedded.rocks> --- tools/mxsboot.c | 21 ++++----------------- 1 file changed, 4 insertions(+), 17 deletions(-) diff --git a/tools/mxsboot.c b/tools/mxsboot.c index 185b327..15eec91 100644 --- a/tools/mxsboot.c +++ b/tools/mxsboot.c @@ -271,23 +271,10 @@ static struct mx28_nand_fcb *mx28_nand_get_fcb(uint32_t size) fcb->ecc_block_0_size = 512; fcb->ecc_block_n_size = 512; fcb->metadata_bytes = 10; - - if (nand_writesize == 2048) { - fcb->ecc_block_n_ecc_type = 4; - fcb->ecc_block_0_ecc_type = 4; - } else if (nand_writesize == 4096) { - if (nand_oobsize == 128) { - fcb->ecc_block_n_ecc_type = 4; - fcb->ecc_block_0_ecc_type = 4; - } else if (nand_oobsize == 218) { - fcb->ecc_block_n_ecc_type = 8; - fcb->ecc_block_0_ecc_type = 8; - } else if (nand_oobsize == 224) { - fcb->ecc_block_n_ecc_type = 8; - fcb->ecc_block_0_ecc_type = 8; - } - } - + fcb->ecc_block_n_ecc_type = mx28_nand_get_ecc_strength( + nand_writesize, nand_oobsize) >> 1; + fcb->ecc_block_0_ecc_type = mx28_nand_get_ecc_strength( + nand_writesize, nand_oobsize) >> 1; if (fcb->ecc_block_n_ecc_type == 0) { printf("MX28 NAND: Unsupported NAND geometry\n"); goto err; -- 2.5.0

3 3

[U-Boot] regarding u-boot ethernet support for TFTP boot in Banana pi R1 (Lamobo R1)
by ramki982 12 Aug '15

12 Aug '15

Dear all, I've successfully compiled and running u-boot on the Bananapi R1 board using the instructions in http://linux-sunxi.org/Mainline_U-boot#Compile_U-Boot This board uses a BCM 53125 ethernet chip 4+1 ports 10/100/1000 Ethernet RJ45 (BCM 53125), WLAN @802.11b/g/n (RTL8192CU) with 2x external antennas connectors But when I any try to run any NETWORK related command - i'm getting a "No Link". I do have the ip add, gateway addr, net mask etc set as environment variables. sunxi# ping 192.168.10.1 ethernet@01c50000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@01c50000: No link. ping failed; host 192.168.10.1 is not alive Could someone help me to understand if the above issue can be fixed by any config changes ? thanks Ram -- View this message in context: http://u-boot.10912.n7.nabble.com/regarding-u-boot-ethernet-support-for-TFT… Sent from the U-Boot mailing list archive at Nabble.com.

3 2

[U-Boot] [PATCH v2] x86: Drop FSP error defines and use EFI instead
by Simon Glass 12 Aug '15

12 Aug '15

Now that we have an efi.h header we can use that for FSP error defines. Drop the FSP ones. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- Changes in v2: - Drop checking against EFI_STATUS since this reduces code readability arch/x86/include/asm/fsp/fsp_types.h | 11 ----------- arch/x86/lib/fsp/fsp_common.c | 3 ++- 2 files changed, 2 insertions(+), 12 deletions(-) diff --git a/arch/x86/include/asm/fsp/fsp_types.h b/arch/x86/include/asm/fsp/fsp_types.h index f32d827..4fe69f2 100644 --- a/arch/x86/include/asm/fsp/fsp_types.h +++ b/arch/x86/include/asm/fsp/fsp_types.h @@ -68,15 +68,4 @@ struct efi_guid { #define SIGNATURE_64(A, B, C, D, E, F, G, H) \ (SIGNATURE_32(A, B, C, D) | ((u64)(SIGNATURE_32(E, F, G, H)) << 32)) -/* - * Define FSP API return status code. - * Compatiable with EFI_STATUS defined in PI Spec. - */ -#define FSP_SUCCESS 0 -#define FSP_INVALID_PARAM 0x80000002 -#define FSP_UNSUPPORTED 0x80000003 -#define FSP_DEVICE_ERROR 0x80000007 -#define FSP_NOT_FOUND 0x8000000E -#define FSP_ALREADY_STARTED 0x80000014 - #endif diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c index 6f72c6d..6a0a026 100644 --- a/arch/x86/lib/fsp/fsp_common.c +++ b/arch/x86/lib/fsp/fsp_common.c @@ -5,6 +5,7 @@ */ #include <common.h> +#include <efi.h> #include <errno.h> #include <asm/io.h> #include <asm/post.h> @@ -46,7 +47,7 @@ void board_final_cleanup(void) /* call into FspNotify */ debug("Calling into FSP (notify phase INIT_PHASE_BOOT): "); status = fsp_notify(NULL, INIT_PHASE_BOOT); - if (status != FSP_SUCCESS) + if (status) debug("fail, error code %x\n", status); else debug("OK\n"); -- 2.5.0.rc2.392.g76e840b

2 1

[U-Boot] [PATCH 1/3] ARM: tegra: move kernel_addr_r on T210
by Stephen Warren 12 Aug '15

12 Aug '15

From: Stephen Warren <swarren(a)nvidia.com> The new value is the most likely value where the kernel wants to end up at run-time. Selecting this value as the load address likely avoids the need to copy the kernel image from the actual load address to the desired load address. Note that this isn't guaranteed since the kernel may wish to run at an arbitrary location. In that case, U-Boot will still relocate the image according to its wishes; this change is a performance optimization, not a hard-coding of the final image location. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- include/configs/tegra210-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/tegra210-common.h b/include/configs/tegra210-common.h index d95056c00261..e6c815212d7b 100644 --- a/include/configs/tegra210-common.h +++ b/include/configs/tegra210-common.h @@ -55,7 +55,7 @@ * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 33M allows * for the FDT/DTB to be up to 1M, which is hopefully plenty. */ -#define CONFIG_LOADADDR 0x81000000 +#define CONFIG_LOADADDR 0x80080000 #define MEM_LAYOUT_ENV_SETTINGS \ "scriptaddr=0x90000000\0" \ "pxefile_addr_r=0x90100000\0" \ -- 1.9.1

2 7

[U-Boot] [PATCH] Add clarifications to the x86 README
by Stoppa, Igor 12 Aug '15

12 Aug '15

Explicitly list the targets supported in each section of the instructions from the x86 README. --- doc/README.x86 | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/doc/README.x86 b/doc/README.x86 index af2459c..1105afe 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -19,14 +19,15 @@ work with minimal adjustments on other x86 boards since coreboot deals with most of the low-level details. U-Boot also supports booting directly from x86 reset vector without coreboot, -aka raw support or bare support. Currently Link, QEMU x86 targets and all -Intel boards support running U-Boot 'bare metal'. +aka raw support or bare support. U-Boot becomes a replacement for the BIOS. +Currently Link, QEMU x86 targets and all Intel boards support running U-Boot +'bare metal'. As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit Linux kernel as part of a FIT image. It also supports a compressed zImage. -Build Instructions ------------------- +Build Instructions for U-Boot as coreboot payload +------------------------------------------------- Building U-Boot as a coreboot payload is just like building U-Boot for targets on other architectures, like below: @@ -48,6 +49,8 @@ Change the 'Board configuration file' and 'Board Device Tree Source (dts) file' to point to a new board. You can also change the Cache-As-RAM (CAR) related settings here if the default values do not fit your new board. +Build Instructions for U-Boot as BIOS replacement (raw/bare mode) +----------------------------------------------------------------- Building a ROM version of U-Boot (hereafter referred to as u-boot.rom) is a little bit tricky, as generally it requires several binary blobs which are not shipped in the U-Boot source tree. Due to this reason, the u-boot.rom build is @@ -87,7 +90,7 @@ Now you can build U-Boot and obtain u-boot.rom: $ make chromebook_link_defconfig $ make all -Intel Crown Bay specific instructions: +Intel Crown Bay specific instructions (raw mode): U-Boot support of Intel Crown Bay board [4] relies on a binary blob called Firmware Support Package [5] to perform all the necessary initialization steps @@ -122,7 +125,7 @@ Now you can build U-Boot and obtain u-boot.rom $ make crownbay_defconfig $ make all -Intel Minnowboard Max instructions: +Intel Minnowboard Max instructions (raw mode): This uses as FSP as with Crown Bay, except it is for the Atom E3800 series. Download this and get the .fd file (BAYTRAIL_FSP_GOLD_003_16-SEP-2014.fd at @@ -189,7 +192,7 @@ Offset Description Controlling config Overall ROM image size is controlled by CONFIG_ROM_SIZE. -Intel Galileo instructions: +Intel Galileo instructions (raw mode): Only one binary blob is needed for Remote Management Unit (RMU) within Intel Quark SoC. Not like FSP, U-Boot does not call into the binary. The binary is -- 2.1.4

2 2

[U-Boot] [RESEND PATCH] usb: gadget: f_thor: Allocate request up to THOR_PACKET_SIZE
by Michal Simek 12 Aug '15

12 Aug '15

From: Siva Durga Prasad Paladugu <siva.durga.paladugu(a)xilinx.com> Allocate request up to THOR_PACKET_SIZE not the ep0->maxpacket as the descriptors data depend on the number of descriptors and this 64 bytes were not enough and the buffer might overflow which results in memalign failures later. Signed-off-by: Siva Durga Prasad Paladugu <sivadur(a)xilinx.com> Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- drivers/usb/gadget/f_thor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c index 31eec36be876..5c8f6768519c 100644 --- a/drivers/usb/gadget/f_thor.c +++ b/drivers/usb/gadget/f_thor.c @@ -775,7 +775,7 @@ static int thor_func_bind(struct usb_configuration *c, struct usb_function *f) goto fail; } dev->req->buf = memalign(CONFIG_SYS_CACHELINE_SIZE, - gadget->ep0->maxpacket); + THOR_PACKET_SIZE); if (!dev->req->buf) { status = -ENOMEM; goto fail; -- 2.3.5

3 4

[U-Boot] [PATCH] zynqmp: enable CONFIG_NET_RANDOM_ETHADDR
by Michal Simek 12 Aug '15

12 Aug '15

We have to set a MAC address to use network. Otherwise, the tftpboot command fails with the following message: Gem.e000b000 Waiting for PHY auto negotiation to complete........ done *** ERROR: `ethaddr' not set Since commit 92ac52082140 ("net: Remove all references to CONFIG_ETHADDR and friends"), we can not use CONFIG_ETHADDR. The easiest way to set a MAC address is to enable CONFIG_NET_RANDOM_ETHADDR. Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- configs/xilinx_zynqmp_ep_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/xilinx_zynqmp_ep_defconfig b/configs/xilinx_zynqmp_ep_defconfig index 107236b18fb8..dbf06b538645 100644 --- a/configs/xilinx_zynqmp_ep_defconfig +++ b/configs/xilinx_zynqmp_ep_defconfig @@ -20,3 +20,4 @@ CONFIG_CMD_PING=y CONFIG_CMD_TIME=y CONFIG_CMD_TIMER=y # CONFIG_REGEX is not set +CONFIG_NET_RANDOM_ETHADDR=y -- 2.3.5

1 0

[U-Boot] Installing u-boot for x86 (non EFI) on a disk
by Stoppa, Igor 12 Aug '15

12 Aug '15

Hello, I have read the documentation coming with u-boot and several other links that I got from Google, but I am still confused on certain items. I'll gladly provide patches for enhancing the documentation, if anyone can help me to understand better. My impression is that the typical way of running u-boot in non-EFI mode is to create its raw version. Because the alternative is to build u-boot as coreboot payload, but not many target HW use coreboot. Is this correct? Googling, I found this link [1] from the qemu ml archives, which shows how to build and start a u-boot rom file in qemu. Which works also for me. However I would like to create a loop file, install u-boot in it and pass that file to qemu as hda, rather than using the rom file. How do I install u-boot? From what I understood I should put something in the (disk? / partition?) MBR and copy something else elsewhere. But I could not figure out what goes where, exactly. Could anybody please enlighten me? [1] https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg04835.html -- tia, Igor Stoppa

2 3

[U-Boot] [PATCH v2] f_thor: Dont perform reset at the end of thor
by Michal Simek 12 Aug '15

12 Aug '15

From: Siva Durga Prasad Paladugu <siva.durga.paladugu(a)xilinx.com> Dont perform reset at the end of thor download if configured to do reset off. Reset may not be required in all cases and hence provided an option to do so. The case would be to download the images to DDR instead of flash device. Signed-off-by: Siva Durga Prasad Paladugu <sivadur(a)xilinx.com> Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- Changes in v2: - Update commit message with additional description drivers/usb/gadget/f_thor.c | 7 +++++++ drivers/usb/gadget/f_thor.h | 3 +++ 2 files changed, 10 insertions(+) diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c index e9a690eff5f1..5c8f6768519c 100644 --- a/drivers/usb/gadget/f_thor.c +++ b/drivers/usb/gadget/f_thor.c @@ -123,6 +123,9 @@ static int process_rqt_cmd(const struct rqt_box *rqt) send_rsp(rsp); g_dnl_unregister(); dfu_free_entities(); +#ifdef CONFIG_THOR_RESET_OFF + return RESET_DONE; +#endif run_command("reset", 0); break; case RQT_CMD_POWEROFF: @@ -728,6 +731,10 @@ int thor_handle(void) if (ret > 0) { ret = process_data(); +#ifdef CONFIG_THOR_RESET_OFF + if (ret == RESET_DONE) + break; +#endif if (ret < 0) return ret; } else { diff --git a/drivers/usb/gadget/f_thor.h b/drivers/usb/gadget/f_thor.h index 833a9d24ae7e..83412851dd17 100644 --- a/drivers/usb/gadget/f_thor.h +++ b/drivers/usb/gadget/f_thor.h @@ -121,4 +121,7 @@ struct f_thor { #define F_NAME_BUF_SIZE 32 #define THOR_PACKET_SIZE SZ_1M /* 1 MiB */ #define THOR_STORE_UNIT_SIZE SZ_32M /* 32 MiB */ +#ifdef CONFIG_THOR_RESET_OFF +#define RESET_DONE 0xFFFFFFFF +#endif #endif /* _USB_THOR_H_ */ -- 2.3.5

4 7

[U-Boot] [PATCH] ARM: dts: Rename memory@0 to memory
by Michal Simek 12 Aug '15

12 Aug '15

zynq-7000.dtsi include skeleton.dtsi which contains memory node with base address and size zero. If you add memory@0 node to the platform DTS in final DTB there are two memory nodes and U-Boot works with the first one (with zeros) which end up in failing in dram_init because size is zero. Platform memory node should rewrite default memory node setup from skeleton.dtsi that's why platfroms needs to also use memory as node name instead of memory@0. Reported-by: Siva Durga Prasad Paladugu <sivadur(a)xilinx.com> Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- arch/arm/dts/zynq-zc770-xm010.dts | 2 +- arch/arm/dts/zynq-zc770-xm011.dts | 2 +- arch/arm/dts/zynq-zc770-xm012.dts | 2 +- arch/arm/dts/zynq-zc770-xm013.dts | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/dts/zynq-zc770-xm010.dts b/arch/arm/dts/zynq-zc770-xm010.dts index da3a182ea1e1..680f24c9c44d 100644 --- a/arch/arm/dts/zynq-zc770-xm010.dts +++ b/arch/arm/dts/zynq-zc770-xm010.dts @@ -25,7 +25,7 @@ stdout-path = &uart1; }; - memory@0 { + memory { device_type = "memory"; reg = <0x0 0x40000000>; }; diff --git a/arch/arm/dts/zynq-zc770-xm011.dts b/arch/arm/dts/zynq-zc770-xm011.dts index d38c8201353c..f73c0ddcb8d4 100644 --- a/arch/arm/dts/zynq-zc770-xm011.dts +++ b/arch/arm/dts/zynq-zc770-xm011.dts @@ -23,7 +23,7 @@ stdout-path = &uart1; }; - memory@0 { + memory { device_type = "memory"; reg = <0x0 0x40000000>; }; diff --git a/arch/arm/dts/zynq-zc770-xm012.dts b/arch/arm/dts/zynq-zc770-xm012.dts index f8cc5039d6b7..4289e31f4615 100644 --- a/arch/arm/dts/zynq-zc770-xm012.dts +++ b/arch/arm/dts/zynq-zc770-xm012.dts @@ -25,7 +25,7 @@ stdout-path = &uart1; }; - memory@0 { + memory { device_type = "memory"; reg = <0x0 0x40000000>; }; diff --git a/arch/arm/dts/zynq-zc770-xm013.dts b/arch/arm/dts/zynq-zc770-xm013.dts index 436a8cd1b9a9..5124cdc5cdf0 100644 --- a/arch/arm/dts/zynq-zc770-xm013.dts +++ b/arch/arm/dts/zynq-zc770-xm013.dts @@ -25,7 +25,7 @@ stdout-path = &uart0; }; - memory@0 { + memory { device_type = "memory"; reg = <0x0 0x40000000>; }; -- 2.3.5

1 0