May 2015 - U-Boot

[U-Boot] [PATCH 0/8] ARM: sunxi: Support PSCI for sun6i and sun8i
by Chen-Yu Tsai 30 May '15

30 May '15

Hi everyone, I finally got around to rebasing and fixing up my PSCI stuff. This series adds PSCI support for sun6i and sun8i. This is based on sun7i PSCI support by Marc, and the SMP support routines found in both mainline Linux and Allwinner's Android kernel. I've tested this on my Hummingbird A31 board and Ippo q8h v5 tablet. Given the A23 SMP routines work on the A33 as well, I see no reason it would not work, so A33 support is included as well, but more testing is always welcome. Patch 1 and 2 address a build failur on sunxi/next I ran into, which is related to the new NAND SPL support. Patch 3 adds some comments to the sunxi PSCI code, for easier reading. Patch 4 moves sun7i PSCI code aside. Patch 5 adds sun6i PSCI code. Differences from sun7i are the separate PRCM block for power gating/clamps, and support for more than 1 secondary CPU core. Patch 6 enables PSCI for sun6i. Patch 7 lets sun8i share PSCI code with sun6i. The routines are the same, except sun8i does not have power clamps. Patch 8 enables PSCI for sun8i (A23/A33). Wonder if we still need the SMP support in the kernel? Regards ChenYu Chen-Yu Tsai (8): sunxi: Only compile board_nand_init() if CONFIG_NAND is set sunxi: Add extra NAND pins for sun6i ARM: sunxi: Document registers in PSCI code ARM: sunxi: Make PSCI code sun7i specific ARM: sunxi: Add sun6i specific PSCI implementation ARM: sunxi: Enable PSCI for sun6i ARM: sunxi: Share sun6i PSCI backend with sun8i ARM: sunxi: Enable PSCI for sun8i arch/arm/cpu/armv7/sunxi/Makefile | 4 +- arch/arm/cpu/armv7/sunxi/{psci.S => psci_sun6i.S} | 81 +++++++++++++++-------- arch/arm/cpu/armv7/sunxi/{psci.S => psci_sun7i.S} | 14 ++-- board/sunxi/Kconfig | 9 +++ board/sunxi/board.c | 2 + include/configs/sun6i.h | 7 ++ include/configs/sun8i.h | 6 ++ 7 files changed, 87 insertions(+), 36 deletions(-) copy arch/arm/cpu/armv7/sunxi/{psci.S => psci_sun6i.S} (74%) rename arch/arm/cpu/armv7/sunxi/{psci.S => psci_sun7i.S} (94%) -- 2.1.4

3 18

[U-Boot] [RFC] tam3517: add GPMC nand timing (brutally)
by Jeroen Hofstee 30 May '15

30 May '15

cc: Stefano Babic <sbabic(a)denx.de> Cc: Scott Wood <scottwood(a)freescale.com> Cc: Tom Rini <trini(a)konsulko.com> Cc: Tapani Utriainen <tapani(a)technexion.com> cc: Simon Glass <sjg(a)chromium.org> --- Hi, This patch intends to set the proper timing for the MT29F4G16ABBDAHC as used on the tam3517 SOM by brutally changing the defaults values. Some ascii art is included to describe why I believe these timing values to be correct. Of course we should find a better way for a board to set proper timings, some options: - do the CONFIG_* foo - implement a weak function to get the timing - find a spot to let the board overwrite the timing (spl and/or u-boot?) I think the last option is the best one in general, since it allows to read for example a dtb from the nand with the timing, and allows ONFI detection / timing modes to be set before changing the gpmc timing. Since this is a SOM we need to find a decent place to put that logic, since all derived boards would like to have the timing. Comments / ideas are welcome, With kind regards, Jeroen orig 195.247 0.005: NAND read: device 0 offset 0x400000, size 0x600000 196.362 1.116: 6291456 bytes read: OK prefetch 0.025 0.004: NAND read: device 0 offset 0x400000, size 0x600000 0.843 0.818: 6291456 bytes read: OK timing 120.332 0.005: NAND read: device 0 offset 0x400000, size 0x600000 121.329 0.997: 6291456 bytes read: OK timing + prefetech 2515.535 0.004: NAND read: device 0 offset 0x400000, size 0x600000 2516.117 0.582: 6291456 bytes read: OK orig -> prefetch = 298ms orig -> timing = 119ms pretech -> prefetch + timing = 236ms timing -> timing + prefetch = 415ms orig -> timing + prefetch = 534ms arch/arm/cpu/armv7/omap-common/mem-common.c | 148 ++++++++++++++++++++++++++-- 1 file changed, 142 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/armv7/omap-common/mem-common.c b/arch/arm/cpu/armv7/omap-common/mem-common.c index fc4290c..42346e6 100644 --- a/arch/arm/cpu/armv7/omap-common/mem-common.c +++ b/arch/arm/cpu/armv7/omap-common/mem-common.c @@ -68,6 +68,141 @@ void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, sdelay(2000); } +#include <asm/arch/omap3-regs.h> + +/* + * ========================== WRITE CYCLE =============================== + * + * Sending a command: + * + * |- WRCYCLETIME -| + * + * CSONTIME=0 CSWROFFTIME=WRCYCLETIME + * CE# xxxxxxxxxxxxx|_____________________________|xxxxxxxxxxxxxxxxxx + * + * + * WEONTIME=0 WEOFFTIME (trigger) + * *_____________ + * WE# xxxxxxxxxxxxx|________________| |xxxxxxxxxxxxxxxxxx + * + * ______________________________ + * DATA xxxxxxxxxxxxx| |xxxxxxxxxxxxxxxxxx + * + * + * + * ========================== LATCH CYCLE =============================== + * + * Sending a address (note uses WRCYCLETIME!) + * + * |- WRCYCLETIME -| + * + * CSONTIME=0 CSWROFFTIME=WRCYCLETIME + * CE# xxxxxxxxxxxxx|_____________________________|xxxxxxxxxxxxxxxxxx + * + * + * WEONTIME=0 WEOFFTIME (trigger) + * *_____________ + * WE# xxxxxxxxxxxxx|________________| |xxxxxxxxxxxxxxxxxx + * + * ADVONTIME=0 ADVWROFFTIME=WRCYCLETIME + * ______________________________ + * ALE xxxxxxxxxxxxx| |xxxxxxxxxxxxxxxxxx + * + * ______________________________ + * DATA xxxxxxxxxxxxx| |xxxxxxxxxxxxxxxxxx + * + * + * + * ========================== READ CYCLE =============================== + * + * + * NAND triggers the READY signal, which is a flags in status register and + * causes the code to perform the (next) read. CE is enabled again, RE# pulled + * down and data is read at READACCESSTIME. After the read the CE is off again. + * + * |- RDCYCLETIME -| + * + * ____________________________________________________ + * READY __________| + * + * CSONTIME=0 CSRDOFFTIME=RDCYCLETIME + * CE# xxxxxxxxxxxxx|_____________________________|xxxxxxxxxxxxxxxxxx + * + * + * OEONTIME=0 OEOFFTIME + * * _____________ + * RE# xxxxxxxxxxxxxx|________________| |xxxxxxxxxxxxxxxxxx + * + * READACCESTIME + * ________|_______ + * DATA xxxxxxxxxxxxxxxxxxxxxxxxxxxx| | |xxxxxxxxxxxxxxxxxx + */ + + +/* The gpmc is timed from the L3 (165 MHz, so T ~= 6.06 ns */ + +/* read acces time is 25ms from CS. -> 4.5 cycle */ +#define OEONTIME_NAND 0x0 /* RE# on time */ +#define OEOFFTIME_NAND 0x3 /* RE# off time */ +#define RDACCESSTIME_NAND 0x6 /* sampling point for read */ +#define RDCYCLETIME_NAND 0x6 /* complete read time */ + +/* + * The WEOFFTIME triggers the NAND to sample the data line (command or address). + * There must be enough time before that to satisy the setup times, so it must + * be after at least tCLS, tCS, tALS, tDS. Futhermore there is a minimum time + * the WE# must be held low, tWP for the NAND to detect the edge. For the + * MT29F4G16ABBDAHC these are tCLS=10ns, tCS=20ns, tALS=10ns, tDS=10ns and tW=12ns. + * So at least 4 clock ticks are needed before the WE# can be pulled up. Thereafter + * the lines must be held for some hold times, for the NAND to sample them. Hold + * times for the chip are tCLH=5ns, tCH=5ns, tALH=5ns, tDH=5ns. The WE must be held + * high for the tWH=10ns. + * + * From above timing 2,4,6 should work from the NAND chips point of view. It doesn't + * and since the TRM mentions "For the AccessCompletion: 1 cycle is required for data + * hold time (nCS deassertion)" make it 3,5,7.... + */ +#define WEONTIME_NAND 0x3 /* WE# on time */ +#define WEOFFTIME_NAND 0x5 /* WE# off time */ +#define WRCYCLETIME_NAND 0x7 /* complete write, latch time */ + +/* For a latch ALE should be high at WEOFFTIME, just make it high during the whole cycle */ +#define ADVONTIME_NAND 0 /* ALE on time */ +#define ADVWROFFTIME_NAND WRCYCLETIME_NAND /* ALE off time for latch */ + +#define CSONTIME_NAND 0 /* CE# on time for read, latch, write */ +#define CSRDOFFTIME_NAND RDCYCLETIME_NAND /* CE# off for read */ +#define CSWROFFTIME_NAND WRCYCLETIME_NAND /* CE# off for latch, write */ + +/* tRLOH=5ns, wait for data lines to be released when switching to other CS */ +#define BUSTURNAROUND_NAND 1 +#define CYCLE2CYCLEDELAY_NAND 0x0 + +/* CONFIG1: Type of Device, Type of Access */ +#define NAND_GPMC_CONFIG1 ( GPMCFCLKDIVIDER(0) /* not used for NAND */ | 0 /* TIMEPARAGRANULARITY */ | \ + 0 /* MUXADDDATA */ | DEVICETYPE_NAND | DEVICESIZE_16BIT | WAITPINSELECT(0) | WAITMONITORINGTIME(0) | \ + 0 /* WAITWRITEMONITORING */ | 0 /* WAITREADMONITORING */ | ATTACHEDDEVICEPAGELENGTH(0) | \ + CLKACTIVATIONTIME(0) | 0 /* WRITETYPE */ | 0 /* WRITEMULTIPLE */ | 0 /* READTYPE */ | \ + 0 /* READMULTIPLE */ | 0 /* WRAPBURST */ ) +/* CONFIG2: Chip Select */ +#define NAND_GPMC_CONFIG2 (CSWROFFTIME(CSWROFFTIME_NAND) | CSRDOFFTIME(CSRDOFFTIME_NAND) | \ + CSONTIME(CSONTIME_NAND) | 0 /* CSEXTRADELAY */ ) +/* CONFIG3: ADV/ALE */ +#define NAND_GPMC_CONFIG3 ( ADVWROFFTIME(ADVWROFFTIME_NAND) | ADVRDOFFTIME(0) | \ + 0 /* ADVEXTRADELAY */ | ADVONTIME(ADVONTIME_NAND) ) +/* CONFIG4: WE/OE */ +#define NAND_GPMC_CONFIG4 ( WEOFFTIME(WEOFFTIME_NAND) | 0 /* WEEXTRADELAY */ | WEONTIME(WEONTIME_NAND) | \ + OEOFFTIME(WEOFFTIME_NAND) | OEEXTRADELAY | OEONTIME(OEONTIME_NAND) ) +/* CONFIG5: Cycle Timing */ +#define NAND_GPMC_CONFIG5 ( PAGEBURSTACCESSTIME(1) | RDACCESSTIME(RDACCESSTIME_NAND) | \ + WRCYCLETIME(WRCYCLETIME_NAND) | RDCYCLETIME(RDCYCLETIME_NAND) ) +/* CONFIG6: Rest of the Pack */ +#define NAND_GPMC_CONFIG6 ( WRACCESSTIME(0) /* not NAND */ | WRDATAONADMUXBUS(0) | \ + CYCLE2CYCLEDELAY(CYCLE2CYCLEDELAY_NAND) | \ + CYCLE2CYCLESAMECSEN | 0 /* CYCLE2CYCLEDIFFCSEN */ | BUSTURNAROUND(BUSTURNAROUND_NAND) ) +/* CONFIG7: Address Mapping */ +#define NAND_GPMC_CONFIG7 ( MASKADDRESS(0xC) /* 64MB */ | CSVALID | BASEADDRESS(0x4) ) + /***************************************************** * gpmc_init(): init gpmc bus * Init GPMC for x16, MuxMode (SDRAM in x32). @@ -95,12 +230,13 @@ void gpmc_init(void) /* min 16MB */ GPMC_SIZE_16M))); #elif defined(CONFIG_NAND) || defined(CONFIG_CMD_NAND) /* configure GPMC for NAND */ - const u32 gpmc_regs[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG1, - M_NAND_GPMC_CONFIG2, - M_NAND_GPMC_CONFIG3, - M_NAND_GPMC_CONFIG4, - M_NAND_GPMC_CONFIG5, - M_NAND_GPMC_CONFIG6, + const u32 gpmc_regs[GPMC_MAX_REG] = { + NAND_GPMC_CONFIG1, + NAND_GPMC_CONFIG2, + NAND_GPMC_CONFIG3, + NAND_GPMC_CONFIG4, + NAND_GPMC_CONFIG5, + NAND_GPMC_CONFIG6, 0 }; u32 base = CONFIG_SYS_NAND_BASE; -- 1.9.1

1 0

[U-Boot] Broken support for hummingboard i2
by Andrei Gherzan 30 May '15

30 May '15

Hello, Using HEAD of default U-boot-fslc branch 2015.14, my Hummingboard i2 stuck at "U-Boot SPL 2015.04-00129-g10aced3 (May 29 2015 - 01:43:12)" Reproduced in yocto (U-Boot SPL 2015.04+fslc+gb16ec2d) and using fedora arm toolchain. Reproduce steps: $ make mrproper $ make mx6cuboxi_defconfig $ make $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 $ sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=42 It seems like SPL can't load the uboot image. The cuboxi uboot fork works just fine: git:// github.com/SolidRun/u-boot-imx6.git;branch=imx6. Is this a known issue? Regards, Andrei

3 4

[U-Boot] [PATCH] mx6: repair sl and slx load addresses
by Vincent Stehlé 29 May '15

29 May '15

Commit 8183058188cd ("imx6: centralise common boot options in mx6_common.h") changed the LOADADDR and SYS_TEXT_BASE for all mx6 boards, setting them to 0x12000000 and 0x17800000 respectively. This does not work for i.MX6SL and i.MX6 SoloX based boards, which have their DDR starting at 0x80000000. We allow to override LOADADDR from mx6_common.h and restore previous LOADADDR and SYS_TEXT_BASE for SL and SoloX based boards. This repairs the boot for i.MX6 SoloX Sabre SD, and should also repair SL EVK and Warp board. Signed-off-by: Vincent Stehlé <vincent.stehle(a)laposte.net> Cc: Peter Robinson <pbrobinson(a)gmail.com> Cc: Fabio Estevam <fabio.estevam(a)freescale.com> Cc: Otavio Salvador <otavio(a)ossystems.com.br> --- Hi, This patch repairs for sure mx6sxsabresd with latest u-boot. I am pretty sure that mx6slevk and warp are broken in current u-boot and are repaired by this patch, but I cannot test, only compile. Also, I noticed that the following boards have different LOADADDR and/or SYS_TEST_BASE after the aforementioned commit: - cm_fx6 - novena - tbs2910 The current patch does not touch those and assumes they still work with latest u-boot. Maybe a test or two to confirm would not harm... Testers welcome! Best regards, V. include/configs/mx6_common.h | 2 ++ include/configs/mx6slevk.h | 3 +++ include/configs/mx6sxsabresd.h | 3 +++ include/configs/warp.h | 3 +++ 4 files changed, 11 insertions(+) diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index 233c6d2..2367374 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -53,7 +53,9 @@ #define CONFIG_REVISION_TAG /* Boot options */ +#ifndef CONFIG_LOADADDR #define CONFIG_LOADADDR 0x12000000 +#endif #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR #ifndef CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_TEXT_BASE 0x17800000 diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h index 2b8bb2a..52f2442 100644 --- a/include/configs/mx6slevk.h +++ b/include/configs/mx6slevk.h @@ -9,6 +9,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_LOADADDR 0x82000000 +#define CONFIG_SYS_TEXT_BASE 0x87800000 + #include "mx6_common.h" #define MACH_TYPE_MX6SLEVK 4307 diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h index 46e1262..d62b3bf 100644 --- a/include/configs/mx6sxsabresd.h +++ b/include/configs/mx6sxsabresd.h @@ -10,6 +10,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_LOADADDR 0x80800000 +#define CONFIG_SYS_TEXT_BASE 0x87800000 + #include "mx6_common.h" #ifdef CONFIG_SPL diff --git a/include/configs/warp.h b/include/configs/warp.h index 2673948..25f24c1 100644 --- a/include/configs/warp.h +++ b/include/configs/warp.h @@ -13,6 +13,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_LOADADDR 0x82000000 +#define CONFIG_SYS_TEXT_BASE 0x87800000 + #include "mx6_common.h" /* Size of malloc() pool */ -- 2.1.4

2 1

[U-Boot] [PATCH 0/10 v3] i.MX6: move duplicated options to mx6_common to standardise mx6 config
by Peter Robinson 29 May '15

29 May '15

There's a lot of common options in the i.MX6 boards that are repeated across a lot of the devices. There's a mx6_common.h which is little used but makes sense to be the central location for all the options we want across all mx6 boards to ensure a consistent set of features. This is a first pass at moving those options and unifying the common options to a standard default. Changes since v2: * Rebase on imx-uboot master * Check that CONFIG_MX6 hasn't already been defined * Check that CONFIG_SYS_TEXT_BASE/CONFIG_BOOTDELAY haven't already been defined * Don't accidentily drop CONFIG_EFI_PARTITION from tbs2910.h Changes since v1: * Move CONFIG_SYS_NO_FLASH changes from patch 7 to patch 2 and reorder includes so we don't need to undef CONFIG_CMD_FLASH / CONFIG_CMD_IMLS * Add CONFIG_CMD_GPIO to mx6_common.f (patch 5) * Use the default for all CONFIG_SYS_PROMPT_HUSH_PS2 (patch 7) * Drop LZO change (patch 8) Peter Robinson (10): novena: standardise mx6_common.h include imx6: move all standard includes to mx6_common.h imx6: move generic imx6 options to mx6_common.h imx6: move standard ATAG configs to mx6_common.h imx6: move MXC_GPIO define to mx6_common.h imx6: centralise common boot options in mx6_common.h imx6: move generic miscellaneous and overwrite options imx6: standardise filesystem and boot options imx6: generic MMC config options to mx6_common mx6: standardise CONFIG_CMD_CACHE Reviewed-by: Eric Nelson <eric.nelson(a)boundarydevices.com>

4 23

[U-Boot] [PATCH v3 resend 0/3] typo in PATCH v3 2/3
by Daniel Kochmański 29 May '15

29 May '15

Sorry, some typo left after rebasing (affects only patch 2/3). Daniel Kochmański (3): sunxi: Create helper function veryfing valid boot signature on MMC sunxi/spl: Detect at runtime where from SPL was read mmc: Protect `mmc_initialize` from initilizing mmc multiple times arch/arm/cpu/armv7/sunxi/board.c | 62 ++++++++++++++++++++++------------- arch/arm/include/asm/arch-sunxi/mmc.h | 1 + board/sunxi/board.c | 8 ++--- drivers/mmc/mmc.c | 5 +++ drivers/mmc/sunxi_mmc.c | 17 ++++++++++ 5 files changed, 65 insertions(+), 28 deletions(-) -- 2.4.1

1 1

[U-Boot] [PATCH 1/2] sunxi: Create helper function veryfing valid boot signature on MMC
by Daniel Kochmański 29 May '15

29 May '15

This patch extracts checking for valid SD card "eGON.BT0" signature from `board_mmc_init` into function `sunxi_mmc_has_egon_boot_signature`. Buffer for mmc sector is allocated and freed at runtime. `panic` is triggered on malloc failure. Signed-off-by: Daniel Kochmański <dkochmanski(a)turtle-solutions.eu> CC: Roy Spliet <r.spliet(a)ultimaker.com> Cc: Ian Campbell <ijc(a)hellion.org.uk> Cc: Hans De Goede <hdegoede(a)redhat.com> helper --- arch/arm/include/asm/arch-sunxi/mmc.h | 1 + board/sunxi/board.c | 8 ++------ drivers/mmc/sunxi_mmc.c | 17 +++++++++++++++++ 3 files changed, 20 insertions(+), 6 deletions(-) diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h b/arch/arm/include/asm/arch-sunxi/mmc.h index cb52e64..3da360b 100644 --- a/arch/arm/include/asm/arch-sunxi/mmc.h +++ b/arch/arm/include/asm/arch-sunxi/mmc.h @@ -127,4 +127,5 @@ struct sunxi_mmc { #define SUNXI_MMC_COMMON_RESET (1 << 18) struct mmc *sunxi_mmc_init(int sdc_no); +int sunxi_mmc_has_egon_boot_signature(struct mmc *mmc); #endif /* _SUNXI_MMC_H */ diff --git a/board/sunxi/board.c b/board/sunxi/board.c index d5bed30..aa18a10 100644 --- a/board/sunxi/board.c +++ b/board/sunxi/board.c @@ -302,12 +302,8 @@ int board_mmc_init(bd_t *bis) * Both mmc0 and mmc2 are bootable, figure out where we're booting * from. Try mmc0 first, just like the brom does. */ - if (mmc_getcd(mmc0) && mmc_init(mmc0) == 0 && - mmc0->block_dev.block_read(0, 16, 1, buf) == 1) { - buf[12] = 0; - if (strcmp(&buf[4], "eGON.BT0") == 0) - return 0; - } + if (sunxi_mmc_has_egon_boot_signature(mmc0)) + return 0; /* no bootable card in mmc0, so we must be booting from mmc2, swap */ mmc0->block_dev.dev = 1; diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index c4300f2..c01d142 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -431,6 +431,23 @@ static int sunxi_mmc_getcd(struct mmc *mmc) return !gpio_get_value(cd_pin); } +int sunxi_mmc_has_egon_boot_signature(struct mmc *mmc) +{ + char *buf = malloc(512); + int valid_signature = 0; + + if (buf == NULL) + panic("Failed to allocate memory\n"); + + if (mmc_getcd(mmc) && mmc_init(mmc) == 0 && + mmc->block_dev.block_read(0, 16, 1, buf) == 1 && + strncmp(&buf[4], "eGON.BT0", 8) == 0) + valid_signature = 1; + + free(buf); + return valid_signature; +} + static const struct mmc_ops sunxi_mmc_ops = { .send_cmd = sunxi_mmc_send_cmd, .set_ios = sunxi_mmc_set_ios, -- 2.4.1

2 4

[U-Boot] [PATCH] tools/kwboot: Add parameters to set delay and timeout via cmdline
by Stefan Roese 29 May '15

29 May '15

To support the Armada 38x, new values for the request-delay and the response-timeout are needed. As the values already implemented in this tool (for Kirkwood and Armada XP) don't seem to work here. To make this more flexible, lets add make those 2 parameters configurable via the cmdline. Here the new parameters: -q <req-delay>: use specific request-delay -s <resp-timeo>: use specific response-timeout For the Marvell DB-88F6820 these values are known to work: One board: -q 2 -s 1 2nd board: -q 5 -s 5 So this seems to be even board specific. But with this patch now those values can be specified and tested via the cmdline. Signed-off-by: Stefan Roese <sr(a)denx.de> Cc: Kevin Smith <kevin.smith(a)elecsyscorp.com> Cc: Dirk Eibach <dirk.eibach(a)gdsys.cc> Cc: Luka Perkov <luka.perkov(a)sartura.hr> --- tools/kwboot.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/tools/kwboot.c b/tools/kwboot.c index 1368b4c..af7a6ee 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -657,7 +657,7 @@ static void kwboot_usage(FILE *stream, char *progname) { fprintf(stream, - "Usage: %s [-d | -a | -b <image> | -D <image> ] [ -t ] [-B <baud> ] <TTY>\n", + "Usage: %s [-d | -a | -q <req-delay> | -s <resp-timeo> | -b <image> | -D <image> ] [ -t ] [-B <baud> ] <TTY>\n", progname); fprintf(stream, "\n"); fprintf(stream, @@ -667,6 +667,8 @@ kwboot_usage(FILE *stream, char *progname) " -D <image>: boot <image> without preamble (Dove)\n"); fprintf(stream, " -d: enter debug mode\n"); fprintf(stream, " -a: use timings for Armada XP\n"); + fprintf(stream, " -q <req-delay>: use specific request-delay\n"); + fprintf(stream, " -s <resp-timeo>: use specific response-timeout\n"); fprintf(stream, "\n"); fprintf(stream, " -t: mini terminal\n"); fprintf(stream, "\n"); @@ -699,7 +701,7 @@ main(int argc, char **argv) kwboot_verbose = isatty(STDOUT_FILENO); do { - int c = getopt(argc, argv, "hb:ptaB:dD:"); + int c = getopt(argc, argv, "hb:ptaB:dD:q:s:"); if (c < 0) break; @@ -731,6 +733,14 @@ main(int argc, char **argv) msg_rsp_timeo = KWBOOT_MSG_RSP_TIMEO_AXP; break; + case 'q': + msg_req_delay = atoi(optarg); + break; + + case 's': + msg_rsp_timeo = atoi(optarg); + break; + case 'B': speed = kwboot_tty_speed(atoi(optarg)); if (speed == -1) -- 2.4.2

2 1

[U-Boot] [PATCH] x86: Fix regression build issue of coreboot-x86_defconfig
by Bin Meng 29 May '15

29 May '15

Commit bd328eb "Clean all defconfigs with savedefconfig" accidentally removed 'CONFIG_VENDOR_COREBOOT=y' from configs/coreboot-x86_defconfig. This commit reverts the change. Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- configs/coreboot-x86_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/coreboot-x86_defconfig b/configs/coreboot-x86_defconfig index 66f94d0..799853f 100644 --- a/configs/coreboot-x86_defconfig +++ b/configs/coreboot-x86_defconfig @@ -1,4 +1,5 @@ CONFIG_X86=y +CONFIG_VENDOR_COREBOOT=y CONFIG_TARGET_COREBOOT=y CONFIG_OF_CONTROL=y CONFIG_DM_PCI=y -- 1.8.2.1

4 14

Re: [U-Boot] [PATCH] x86: Fix regression build issue of coreboot-x86_defconfig
by Bin Meng 29 May '15

29 May '15

Hi Andy, On Thu, May 28, 2015 at 11:22 PM, Andy Pont <andy.pont(a)sdcsystems.com> wrote: > Hi Bin, > >> I just found u-boot.rom created from u-boot-x86/testing branch does >> not have working network any more on QEMU. It is working on the >> u-boot-x86/master branch. >> >> => set serverip 10.10.0.100;set ipaddr 10.10.0.108;set netmask >> 255.255.255.0;set gatewayip 10.10.0.100 >> => run ramboot >> *** ERROR: `serverip' not set >> *** ERROR: `serverip' not set >> >> But 'print' says the env indeed has the 'serverip'. I think there >> should be something in the upstream that caused this after the >> u-boot-x86/testing branch rebase. Do you know where might be the >> problem? > > This looks very similar to an issue that got patched on the i.MX6 yesterday > by Stefano which said: > > commit fd3056337e6fcc140f400e11edd33f6f1cb37de1 > "Use env callbacks for net variables" has a side effect on i.MX6 boards > because they do not set CONFIG_NET: the ip address results not set, but it > is stored in the environment." > > Might be something to check... > Thanks for the hint! Indeed there are something wrong in the upstream which broke the networking on several x86 boards. Regards, Bin

1 0