August 2016 - U-Boot

[U-Boot] [PULL] u-boot-usb/master
by Marek Vasut 12 Aug '16

12 Aug '16

The following changes since commit 2863a9bfc29092be37f8beee230883367b057065: Merge git://git.denx.de/u-boot-rockchip (2016-08-06 11:38:14 -0400) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 606120f99ec2baf3635b1c2545803348b6f550ab: dm: atmel: Add driver model support for the ehci driver (2016-08-07 21:56:56 +0200) ---------------------------------------------------------------- Alban Bedel (4): eth: asix88179: Add VID:DID for Cypress GX3 USB Ethernet Adapter eth: asix88179: Fix receiving on big endian system eth: asix88179: Prepare supporting the driver model eth: asix88179: Add support for the driver model Masahiro Yamada (3): usb: add CONFIG_USB_OHCI_HCD in Kconfig usb: add CONFIG_USB_UHCI_HCD in Kconfig usb: add (move) CONFIG_USB_HOST to Kconfig Peng Fan (1): dm: ehci-mx6: support driver model Rajesh Bhagat (5): drivers: usb: fsl: Make function for initialization to use in CONFIG_DM_USB usb: ehci: fsl: Add code to use CONFIG_DM_USB usb: xhci: fsl: Add code to use CONFIG_DM_USB dm: ls1021a: dts: Update USB 3.0 node to support DM USB arm: ls1021a: Enable CONFIG_DM_USB in defconfigs Stefan Roese (1): net: usb: r8152: Add DM support Wenyou Yang (1): dm: atmel: Add driver model support for the ehci driver arch/arm/dts/ls1021a.dtsi | 2 +- configs/axs103_defconfig | 1 + configs/ls1021aqds_ddr4_nor_defconfig | 1 + configs/ls1021aqds_ddr4_nor_lpuart_defconfig | 1 + configs/ls1021aqds_nor_defconfig | 1 + configs/ls1021aqds_nor_lpuart_defconfig | 1 + drivers/usb/eth/asix88179.c | 259 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------- drivers/usb/eth/r8152.c | 237 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------- drivers/usb/eth/r8152.h | 4 ++ drivers/usb/eth/r8152_fw.c | 2 + drivers/usb/host/Kconfig | 66 ++++++++++++++++++++---- drivers/usb/host/ehci-atmel.c | 116 +++++++++++++++++++++++++++++++++++++++++ drivers/usb/host/ehci-fsl.c | 194 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------- drivers/usb/host/ehci-mx6.c | 144 ++++++++++++++++++++++++++++++++++++++++++++++----- drivers/usb/host/xhci-fsl.c | 83 +++++++++++++++++++++++++++++- include/configs/am43xx_evm.h | 1 - include/configs/am57xx_evm.h | 1 - include/configs/cm_t43.h | 1 - include/configs/cm_t54.h | 1 - include/configs/dra7xx_evm.h | 1 - include/configs/duovero.h | 1 - include/configs/omap4_panda.h | 1 - include/configs/omap5_uevm.h | 1 - 23 files changed, 1005 insertions(+), 115 deletions(-)

3 5

[U-Boot] [PATCH 1/2] ARM: tegra: reduce CSITE clock from 204M to 136M
by Stephen Warren 12 Aug '16

12 Aug '16

From: Bryan Wu <pengw(a)nvidia.com> The L4T kernel complains about a CSITE clock rate above 144MHz, presumably because the HW is only characterized for a clock less than that. Adjust the rate to 136MHz to avoid the warning and stay in spec. Signed-off-by: Bryan Wu <pengw(a)nvidia.com> (swarren, re-wrote commit description) Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- arch/arm/mach-tegra/cpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-tegra/cpu.h b/arch/arm/mach-tegra/cpu.h index 3f38969a44f1..1154f8b37ef8 100644 --- a/arch/arm/mach-tegra/cpu.h +++ b/arch/arm/mach-tegra/cpu.h @@ -16,7 +16,7 @@ #elif defined(CONFIG_TEGRA30) || defined(CONFIG_TEGRA114) || \ defined(CONFIG_TEGRA124) || defined(CONFIG_TEGRA210) #define NVBL_PLLP_KHZ 408000 -#define CSITE_KHZ 204000 +#define CSITE_KHZ 136000 #else #error "Unknown Tegra chip!" #endif -- 2.9.2

1 1

[U-Boot] [PATCH 3/3 v2] test/fs: strip carriage-return from sandbox output
by Stefan Brüns 11 Aug '16

11 Aug '16

DM added carriage-returns to every newline. Strip everything after the 32 character long mdsum. Signed-off-by: Stefan Brüns <stefan.bruens(a)rwth-aachen.de> --- test/fs/fs-test.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/fs/fs-test.sh b/test/fs/fs-test.sh index 043e5d0..171b1de 100755 --- a/test/fs/fs-test.sh +++ b/test/fs/fs-test.sh @@ -402,7 +402,7 @@ check_md5() { # the 7th field is the actual md5 md5_src=`grep -A3 "$1" "$2" | grep "md5 for"` md5_src=($md5_src) - md5_src=${md5_src[6]} + md5_src=${md5_src[6]:0:32} # The md5 list, each line is of the form: # - <md5> -- 2.9.2

1 0

[U-Boot] [PATCH 0/3 v2] Some additions for sandbox and fs tests
by Stefan Brüns 11 Aug '16

11 Aug '16

Add some documentation for the sandbox block device emulation and fix some issues for the fs test script. v2: added Acked-by: Simon Glass <sjg(a)chromium.org> on patch 1 and 2 added missing commit messages dropped test/fs: replace deprecated "sb" command with "host" - will be replaced by pytest based implementation later Stefan Brüns (4): Sandbox: document support of block device emulation sandbox: Add "host size" hostfs command for fs test test/fs: strip carriage-return from sandbox output board/sandbox/README.sandbox | 19 +++++++++++++++++++ cmd/host.c | 8 ++++++++ test/fs/fs-test.sh | 2 +- 3 files changed, 28 insertions(+), 1 deletion(-) -- 2.9.2

1 0

[U-Boot] [PATCH] tools/env: ensure environment starts at erase block boundary
by Andreas Fenkart 11 Aug '16

11 Aug '16

56086921 added support for unaligned environments access. U-boot itself does not support this: - env_nand.c fails when using an unaligned offset. It produces an error in nand_erase_opts{drivers/mtd/nand/nand_util.c} - in env_sf/env_flash the unused space at the end is preserved, but not in the beginning. block alignment is assumed - env_sata/env_mmc aligns offset/length to the block size of the underlying device. data is silently redirected to the beginning of a block There is seems no use case for unaligned environment. If there is some useful data at the beginning of the the block (e.g. end of u-boot) that would be very unsafe. If the redundant environments are hosted by the same erase block then that invalidates the idea of double buffering. It might be that unaligned access was allowed in the past, and that people with legacy u-boot are trapped. But at the time of 56086921 it wasn't supported and due to reasons above I guess it was never introduced. I prefer to remove that (unused) feature in favor of simplicity Signed-off-by: Andreas Fenkart <andreas.fenkart(a)digitalstrom.com> --- tools/env/fw_env.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index 6b0dcaa..2ccc617 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -1294,6 +1294,18 @@ static int check_device_config(int dev) struct stat st; int fd, rc = 0; + if (DEVOFFSET(dev) % DEVESIZE(dev) != 0) { + fprintf(stderr, "Environment does not start on erase block boundary\n"); + errno = EINVAL; + return -1; + } + + if (ENVSIZE(i) > ENVSECTORS(i) * DEVESIZE(i)) { + fprintf(stderr, "Environment does not fit into available sectors\n"); + errno = EINVAL; + return -1; + } + fd = open(DEVNAME(dev), O_RDONLY); if (fd < 0) { fprintf(stderr, -- 2.8.1

1 0

[U-Boot] A command to discard saved environments?
by Masahiro Yamada 11 Aug '16

11 Aug '16

Hi. I am looking for a command that discards the saved environments, and takes me back to the "*** Warning - bad CRC, using default environment" state. In my case, the environment data is saved at sector 0x400 of the MMC device on my board. So, I can just do > mmc erase 400 10 But, beforehand, I need to know CONFIG_ENV_IS_IN_MMC CONFIG_ENV_OFFSET 0x80000 in order to confirm if the above command is doing the right thing. (If I make a mistake in calculating the offset value, other data would be damaged.) Is there a nice command to do that? -- Best Regards Masahiro Yamada

5 9

[U-Boot] [PATCH] net: asix: Fix ASIX 88772B with driver model
by Alban Bedel 11 Aug '16

11 Aug '16

Commit 147271209a9d ("net: asix: fix operation without eeprom") added a special handling for ASIX 88772B that enable another type of header. This break the driver in DM mode as the extra handling needed in the receive path is missing. However this new header mode is not required and only seems to increase the code complexity, so this patch revert this part of commit 147271209a9d. Change-Id: I7edc89f5714ead60e5204340ba05caf21b155593 Fixes: 147271209a9d ("net: asix: fix operation without eeprom") Signed-off-by: Alban Bedel <alban.bedel(a)avionic-design.de> --- drivers/usb/eth/asix.c | 22 +++------------------- 1 file changed, 3 insertions(+), 19 deletions(-) diff --git a/drivers/usb/eth/asix.c b/drivers/usb/eth/asix.c index ad083cf8ae4a..1c6e967db1a0 100644 --- a/drivers/usb/eth/asix.c +++ b/drivers/usb/eth/asix.c @@ -67,11 +67,8 @@ AX_MEDIUM_AC | AX_MEDIUM_RE) /* AX88772 & AX88178 RX_CTL values */ -#define AX_RX_CTL_RH2M 0x0200 /* 32-bit aligned RX IP header */ -#define AX_RX_CTL_RH1M 0x0100 /* Enable RX header format type 1 */ -#define AX_RX_CTL_SO 0x0080 -#define AX_RX_CTL_AB 0x0008 -#define AX_RX_HEADER_DEFAULT (AX_RX_CTL_RH1M | AX_RX_CTL_RH2M) +#define AX_RX_CTL_SO 0x0080 +#define AX_RX_CTL_AB 0x0008 #define AX_DEFAULT_RX_CTL \ (AX_RX_CTL_SO | AX_RX_CTL_AB) @@ -98,8 +95,6 @@ #define FLAG_TYPE_AX88772B (1U << 2) #define FLAG_EEPROM_MAC (1U << 3) /* initial mac address in eeprom */ -#define ASIX_USB_VENDOR_ID 0x0b95 -#define AX88772B_USB_PRODUCT_ID 0x772b /* driver private */ struct asix_private { @@ -431,15 +426,10 @@ static int asix_init_common(struct ueth_data *dev, uint8_t *enetaddr) int timeout = 0; #define TIMEOUT_RESOLUTION 50 /* ms */ int link_detected; - u32 ctl = AX_DEFAULT_RX_CTL; debug("** %s()\n", __func__); - if ((dev->pusb_dev->descriptor.idVendor == ASIX_USB_VENDOR_ID) && - (dev->pusb_dev->descriptor.idProduct == AX88772B_USB_PRODUCT_ID)) - ctl |= AX_RX_HEADER_DEFAULT; - - if (asix_write_rx_ctl(dev, ctl) < 0) + if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) < 0) goto out_err; if (asix_write_hwaddr_common(dev, enetaddr) < 0) @@ -572,12 +562,6 @@ static int asix_recv(struct eth_device *eth) return -1; } - if ((dev->pusb_dev->descriptor.idVendor == - ASIX_USB_VENDOR_ID) && - (dev->pusb_dev->descriptor.idProduct == - AX88772B_USB_PRODUCT_ID)) - buf_ptr += 2; - /* Notify net stack */ net_process_received_packet(buf_ptr + sizeof(packet_len), packet_len); -- 2.9.2

3 12

[U-Boot] [PATCH v2 0/5] Enable caches for the RPi2
by Alexander Graf 11 Aug '16

11 Aug '16

This patch set converts the Raspberry Pi 2 system to properly make use of the caches available in it. Because we're running in HYP mode, we first need to teach U-Boot how to make use of HYP registers and the LPAE page layout which is mandated by hardware when running in HYP mode. Then while we're at it, also mark the frame buffer cached to speed up screen updates. With this patch set, my Raspberry Pi 3 running in AArch32 mode is a *lot* faster than without. Please verify that the code works on a RPi2 as well and doesn't break the original Pi. In theory it should work, but I only have a 3 to test on available here. v1 -> v2: - Move to KConfig - Adapt to new config name "CONFIG_ARMV7_LPAE" Alexander Graf (5): arm64: Add 32bit arm compatible dcache definitions arm: Add support for HYP mode and LPAE page tables lcd: Fix compile warning in 64bit mode RPi: Enable caches for rpi2 bcm2835 video: Map fb as cached arch/arm/cpu/armv7/Kconfig | 8 ++++ arch/arm/include/asm/system.h | 105 +++++++++++++++++++++++++++++++++++++++--- arch/arm/lib/cache-cp15.c | 66 +++++++++++++++++++++++--- arch/arm/mach-bcm283x/Kconfig | 1 + arch/arm/mach-bcm283x/init.c | 7 +++ common/lcd.c | 4 +- drivers/video/bcm2835.c | 6 +++ include/configs/rpi_2.h | 1 - 8 files changed, 182 insertions(+), 16 deletions(-) -- 1.8.5.6

3 22

[U-Boot] [PATCH 00/14] ARM: uniphier: updates for v2016.09-rc2
by Masahiro Yamada 11 Aug '16

11 Aug '16

Cleanups, Fixes, and PSCI support. Masahiro Yamada (14): ARM: uniphier: refactor outer cache code ARM: uniphier: support prefetch and touch operations for outer cache ARM: uniphier: do not compile v7_outer_cache_disable if L2 is disabled ARM: uniphier: refactor L2 zero-touching code in lowlevel_init ARM: uniphier: fix ROM boot mode for PH1-sLD3 ARM: uniphier: move lowlevel debug init code after page table switch ARM: uniphier: export uniphier_cache_enable/disable functions ARM: uniphier: reuse uniphier_cache_disable() for lowlevel_init ARM: uniphier: move outer cache register macros to .c file ARM: uniphier: move (and rename) CONFIG_UNIPHIER_L2CACHE_ON to Kconfig ARM: uniphier: fix CONFIG_SYS_CACHELINE_SIZE when outer cache is on ARM: uniphier: add uniphier_cache_inv_way() to support way invalidation ARM: uniphier: add uniphier_cache_set_active_ways() ARM: uniphier: add PSCI support for UniPhier ARMv7 SoCs arch/arm/mach-uniphier/Kconfig | 9 + arch/arm/mach-uniphier/arm32/Makefile | 1 + arch/arm/mach-uniphier/arm32/arm-mpcore.h | 3 + arch/arm/mach-uniphier/arm32/cache-uniphier.c | 261 ++++++++++++++++------ arch/arm/mach-uniphier/arm32/cache-uniphier.h | 21 ++ arch/arm/mach-uniphier/arm32/late_lowlevel_init.S | 10 +- arch/arm/mach-uniphier/arm32/lowlevel_init.S | 61 ++--- arch/arm/mach-uniphier/arm32/psci.c | 153 +++++++++++++ arch/arm/mach-uniphier/arm32/psci_smp.S | 40 ++++ arch/arm/mach-uniphier/arm32/ssc-regs.h | 68 ------ arch/arm/mach-uniphier/debug.h | 68 ++++++ arch/arm/mach-uniphier/sbc/sbc-regs.h | 1 - include/configs/uniphier.h | 10 +- 13 files changed, 532 insertions(+), 174 deletions(-) create mode 100644 arch/arm/mach-uniphier/arm32/cache-uniphier.h create mode 100644 arch/arm/mach-uniphier/arm32/psci.c create mode 100644 arch/arm/mach-uniphier/arm32/psci_smp.S delete mode 100644 arch/arm/mach-uniphier/arm32/ssc-regs.h create mode 100644 arch/arm/mach-uniphier/debug.h -- 1.9.1

1 15

Re: [U-Boot] [LEDE-DEV] Older u-boot mangles UBI from ubinize 1.5.2
by Richard Weinberger 11 Aug '16

11 Aug '16

Am 11.08.2016 um 13:49 schrieb Daniel Golle: > Hi! > > On Thu, Aug 11, 2016 at 04:28:47AM -0700, J Mo wrote: >> >> I got that good old feeling... like I just jumped onto a bag of flaming poo. >> Ha ha >> >> >> >> On 08/11/2016 03:40 AM, Daniel Golle wrote: >>> >>> Understandable. However, we also need to experiment and figure out the >>> mess left behind by $vendor which often doesn't leave a lot of >>> reasonable options for 3rd-party firmware to be installed. >>> With regard to that specific hack, I never truly understood why it was >>> needed in first place -- I'm not using it on any UBI-enabled device and >>> believe it's some kind of work-around to allow ubinized images to be >>> written via nandwrite, initially in order to support the vendor/stock >>> sysupgrade-format of a specific device (NETGEAR WNDR4300). Please >>> correct me or add the missing bits needed to understand the use-case. >>> It was added to OpenWrt long ago in r38681...r38683 and by now needed >>> to be fixed several times in r42940, r43287, r44658, r44801 and r44881. >>> Later on it was re-used by a bunch of other devices, e.g. >>> bcm4708-netgear-r6250, bcm4708-netgear-r6300-v2, >>> bcm4708-buffalo-wzr-1750dhp, bcm47081-buffalo-wzr-600dhp2 and probably >>> some more. >>> >>> Gabor and Rafal should know more about it and why exactly this is >>> needed and supposedly cannot be solved without this hack. >>> >> >> I'm also confused about WTF that patch does. If it was device-specific to >> comply with OEM-hackery, why apply it generally? > > I reckon because it's generic in the sense that it's used by more than > one target (ar71xx, bcm47xx) and we don't do any device/board specific > patching at all. > >> >> Hm, I just found another example. I don't know why this didn't turn up in my >> searches yesterday since it's a perfect match with the EXACT error. This too >> was on a QSDK AP148: >> >> https://patchwork.ozlabs.org/patch/509468/ >> >> I think I'll go rip that patch out here in a bit, recompile my image, and >> see what happens. > > In the end, this will at least give you some consistency in terms > of U-Boot's and the Kernel's UBI implementation. Ie. either both work > or both fail (e.g. to attach a not entirely erased/formatted UBI device > with left-overs from previous uses of the stock fw). > In case you are flashing the firmware using ubiformat, this shouldn't > be a problem anyway. > >> >> >> >>> [...] >> Thanks for the insight. >> >> The idea was to have a UBI with three volumes: kernel, rootfs(squashfs), and >> the rootfs_data overlay(ubifs). >> >> One of my problems is that someone thought it was a great idea to name the >> SMEM NAND UBI partition "rootfs". There's a patch out there which is >> supposed to fix that, (rename to "ubi") but it's apparently not working for >> me. The auto rootfs selection method might be trying to use the smem/mtd >> parition named "rootfs" instead of the UBI volume named "rootfs"? > > No, these are two different things and it shouldn't matter. However, in > order to have your UBI device auto-attached without any cmdline > parameters it needs to be named 'ubi', so simply changing the name of > the MTD partition in the device-tree should do the trick. > >> >> And yes, my DTS has: >> bootargs = "console=ttyMSM0,115200n8 ubi.mtd=11 root=ubi0:rootfs >> rootfstype=squashfs"; >> >> Is that not valid? Looks right to me. > > squashfs doesn't work on UBI character devices but rather likes block > devices only, just like most filesystems. > Thus, rootfs detection works automagically in OpenWrt/LEDE, just having > a ubi volume named 'rootfs' should do the trick and automatically > decide whether the volume is UBIFS and thus would be mounted similar to > what you tried to do now -- or to create a ubiblock-device and select > that to be mounted as rootfs. In any case, you shouldn't need any > kernel command-line parameters for that, so simply drop everything past > 'console=ttyMSM0,115200n8' (and btw, this can also be done nicer by > setting stdout-path rather than hacking the cmdline). > > >> >> >> >> >>> Right. Depending on whether U-Boot's UBI support or the kernel itself >>> first touches the freshly-written UBI device things go wrong, becase >>> only the hacked-up OpenWrt/LEDE kernel does the right magic on >>> firstboot... >>> >> >> >> The kernel is in the UBI, so u-boot is going to attach it. I can't get >> around that without doing major reconstructive surgery to how this thing was >> designed to boot. >> >> The number of OpenWRT/LEDE devices that have KERNEL_IN_UBI set are tiny. I >> think I only saw one or two others, and they were obscure or dev boards. >> This is likely why the issue hasn't come up before, and it could have been a >> problem for awhile and nobody noticed. > > I do the excact same for all boards on the oxnas target and it works > great. I even store U-Boot's environment inside UBI volumes. > I reckon it really depends on how you flash the device in first place, > ie. using raw nand-write (which may need the before mentioned hack to > erase the remaining free-space) or using ubiformat (which shouldn't > need that). > >> >> >> >> I don't know who's to blame. That's why I started this three-way cross >> posting clusterfark. =) > > Not too bad, at least we get to discuss some forgotten uglyness now > before it starts to affect more people... > >> >> I'm most tempted to blame the kernel rather than u-boot. After all, I can >> change the kernel, and the old kernel worked fine. >> > > I reckon it's somewhere between the way the image was generated and > written to the flash and then didn't get the right treatment on > first-boot because U-Boot tried to access it before it got fixed-up. > Again, if you just use ubiformat to write the image, you won't need > any EOF-markers or other hacks (ie. thus you also shouldn't include > them in the ubinized image!) Did you intentional drop linux-mtd from the CC's after I offered you to discuss your patches on linux-mtd? ;-) Thanks //richard

2 1