Re: [U-Boot] [PATCH v3 10/26] x86: ivybridge: Enable PCI in early init
Hello Simon, Is there a specific case to use PCI before relocation? Or it only applies for x86? If so, we could figure out how to use this new feature. Thanks for the info. Regards, James > Date: Fri, 21 Nov 2014 07:51:08 +0100 > From: s...@chromium.org > To: u-boot@lists.denx.de > CC: graeme.r...@gmail.com > Subject: Re: [U-Boot] [PATCH v3 10/26] x86: ivybridge: Enable PCI in early > init > > On 13 November 2014 06:42, Simon Glass wrote: > > Enable PCI so we can access devices that need to be set up before > > relocation. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: > > - Adjust PCI setup code to fit with new generic cpu PCI code > > > > Changes in v2: None > > > > arch/x86/cpu/ivybridge/Makefile | 1 + > > arch/x86/cpu/ivybridge/cpu.c | 6 > > arch/x86/cpu/ivybridge/pci.c | 60 > > +++ > > include/configs/chromebook_link.h | 14 +++-- > > 4 files changed, 79 insertions(+), 2 deletions(-) > > create mode 100644 arch/x86/cpu/ivybridge/pci.c > > Applied to u-boot-x86. > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WARNING Could not get liodn of node /pcie@ffe240000: FDT_ERR_NOTFOUND
York Sun wrote on 2014/10/24 18:02:03:
>
> On 10/24/2014 08:39 AM, Joakim Tjernlund wrote:
> > Booting my t1042 I get:
> > Loading Ramdisk to 2e639000, end 2cc4 ... OK
> > Loading Device Tree to 03fe4000, end 03fffd45 ... OK
> > WARNING Could not get liodn of node /pcie@ffe24: FDT_ERR_NOTFOUND
> > WARNING Could not get liodn of node /pcie@ffe25: FDT_ERR_NOTFOUND
> > WARNING Could not get liodn of node /pcie@ffe24: FDT_ERR_NOTFOUND
> > WARNING Could not get liodn of node /pcie@ffe25: FDT_ERR_NOTFOUND
> >
> >
> > This apperas to come from
> > base_liodn = fdt_getprop(fdt, off, "fsl,liodn", &rc);
> > if (!base_liodn) {
> > char path[64];
> >
> > if (fdt_get_path(fdt, off, path, sizeof(path))
<
> > 0)
> > strcpy(path, "(unknown)");
> > printf("WARNING Could not get liodn of node
%s:
> > %s\n",
> >path, fdt_strerror(rc));
> > continue;
> > }
> >
> > but I cannot find out what what this property should be. Anyone?
> >
>
> Laurentiu,
>
> Can you take a look?
>
> York
I might have missed it, but did this go anywhere?
Jocke
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] odroid: Turn blue LED on
On 24/11/14 15:15, Suriyan Ramasami wrote: > To indicate that U-Boot is active, turn on the blue LED. > > Signed-off-by: Suriyan Ramasami > Acked-by: Przemyslaw Marczak > --- > > Changes in v3: > - Minkyu Kang, Rebase > > Changes in v2: > - Przemyslaw Marczak, Add gpio_request call. > > Changes in v1: > - First try > > board/samsung/odroid/odroid.c | 5 + > 1 file changed, 5 insertions(+) > applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mtd/nand/vf610_nfc: Disable subpage writes
This patch disables subpage writes for vf610_nfc nand driver. This is required, as without this fix, writing unaligned u-boot images with DFU results in a hang. Trying to write unalgined binary images also results in a hang, without disabling subpage writes. Patch has been tested on a Colibri VF61 module. Signed-off-by: Sanchayan Maity --- drivers/mtd/nand/vf610_nfc.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c index 7feb3a7..928d58b 100644 --- a/drivers/mtd/nand/vf610_nfc.c +++ b/drivers/mtd/nand/vf610_nfc.c @@ -611,6 +611,9 @@ static int vf610_nfc_nand_init(int devnum, void __iomem *addr) vf610_nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_16BIT); } + /* Disable subpage writes as we do not provide ecc->hwctl */ + chip->options |= NAND_NO_SUBPAGE_WRITE; + chip->dev_ready = vf610_nfc_dev_ready; chip->cmdfunc = vf610_nfc_command; chip->read_byte = vf610_nfc_read_byte; -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] qemu-system-arm segfaults on zynq_zed
On 24 November 2014 at 06:03, Douglas Rupp wrote: > I'm brand new to Uboot, so hopefully this is just some missing switch. I > did search the archive, and I was able to build and u-boot a versaatilepb > version, but xilinx-zynq-a9 is the one I really need. > > u-boot-2014.10$ make zynq_zed_defconfig > u-boot-2014.10$ make all CROSS_COMPILE=arm-none-eabi- ARCH=arm > u-boot-2014.10$ qemu-system-arm -M xilinx-zynq-a9 -m 1024M -nographic > -kernel u-boot-dtb.bin > Segmentation fault (core dumped) I guess it may be qemu usage issue, is qemu from https://github.com/Xilinx/qemu ? + Peter Hope, he will give some inputs > > What am I doing wrong? thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] odroid: Turn blue LED on
To indicate that U-Boot is active, turn on the blue LED. Signed-off-by: Suriyan Ramasami Acked-by: Przemyslaw Marczak --- Changes in v3: - Minkyu Kang, Rebase Changes in v2: - Przemyslaw Marczak, Add gpio_request call. Changes in v1: - First try board/samsung/odroid/odroid.c | 5 + 1 file changed, 5 insertions(+) diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c index a2c008e..b7d2381 100644 --- a/board/samsung/odroid/odroid.c +++ b/board/samsung/odroid/odroid.c @@ -383,6 +383,11 @@ static void board_gpio_init(void) gpio_set_drv(EXYNOS4X12_GPIO_X31, S5P_GPIO_DRV_4X); gpio_direction_input(EXYNOS4X12_GPIO_X31); + /* Blue LED (Odroid X2/U2/U3) */ + gpio_request(EXYNOS4X12_GPIO_C10, "Blue LED"); + + gpio_direction_output(EXYNOS4X12_GPIO_C10, 0); + #ifdef CONFIG_CMD_USB /* USB3503A Reference frequency */ gpio_request(EXYNOS4X12_GPIO_X30, "USB3503A RefFreq"); -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] qemu-system-arm segfaults on zynq_zed
I'm brand new to Uboot, so hopefully this is just some missing switch. I did search the archive, and I was able to build and u-boot a versaatilepb version, but xilinx-zynq-a9 is the one I really need. u-boot-2014.10$ make zynq_zed_defconfig u-boot-2014.10$ make all CROSS_COMPILE=arm-none-eabi- ARCH=arm u-boot-2014.10$ qemu-system-arm -M xilinx-zynq-a9 -m 1024M -nographic -kernel u-boot-dtb.bin Segmentation fault (core dumped) What am I doing wrong? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 2/3] Odroid-XU3: Add support for Odroid-XU3
Dear Jaehoon Chung,
On Thu, 20 Nov 2014 21:08:30 +0900
Jaehoon Chung wrote:
> Hi,
>
> CPU:Exynos5800@1200MHz
> Board: Odroid XU3 based on EXYNOS5422
>
> Exynos5800? is it right?
>
Exynos5800 is a variant of Exynos5422 for chromebook, so they are
almost same. The support for this SOC is merged earlier than
Exynos5422. At that time, they used 5800 as its name instead of 5422.
It does not make any difference in behavior, at least until now.
> On 11/14/2014 03:25 PM, Hyungwon Hwang wrote:
> > This patch adds support for Odroid-XU3.
> >
> > Signed-off-by: Hyungwon Hwang
> > Tested-by: Lukasz Majewski
> > Acked-by: Lukasz Majewski
> > Cc: Minkyu Kang
> > Cc: Lukasz Majewski
> > ---
> > Changes for v3:
> > - Remove unnecessary node from DT file
> > - Remove unnecessary features from config file
> > - Remove unnecessary macros from board-specific header file
> > - Fix some trivial typos in comments
> >
> > Changes for v4:
> > - Add MMC FIFO buffer's configuration to DT file
> > - Make CONFIG_OF_CONTROL be set by the target information
> > - Add basic document to doc/README.odroid-xu3
> > - Add CONFIG_CMD_EXT4 to config file
> > - Add environment size and offset to config file
> > - Add extra default environment to make bootable without
> > modification
> > - Remove unnecessary features from config file
> >
> > Changes for v5:
> > - Convert /include/ to #include in DT file
> >
> > Changes for v6:
> > - Separate out the documentation to new commit
> > - Remove unnecessary header file inclusions from the board-specific
> > setup file
> > - Make the function board_clock_init be declared, only when
> > CONFIG_BOARD_EARLY_INIT_F is defined
> >
> > Changes for v7:
> > - Remove OF_CONTROL dependency from !SPL_BUILD
> >
> > Changes for v8:
> > - Remove unnecessary properties in DT mmc node
> >
> > arch/arm/cpu/armv7/exynos/Kconfig | 5 ++
> > arch/arm/dts/Makefile | 3 +-
> > arch/arm/dts/exynos5422-odroidxu3.dts | 57 ++
> > board/samsung/odroid-xu3/Kconfig | 12 +++
> > board/samsung/odroid-xu3/MAINTAINERS | 6 ++
> > board/samsung/odroid-xu3/Makefile | 7 ++
> > board/samsung/odroid-xu3/odroid-xu3.c | 122
> > board/samsung/odroid-xu3/setup.h
> > | 95 ++ configs/odroid-xu3_defconfig
> > | 4 + include/configs/odroid_xu3.h | 144
> > ++ 10 files changed, 454
> > insertions(+), 1 deletion(-) create mode 100644
> > arch/arm/dts/exynos5422-odroidxu3.dts create mode 100644
> > board/samsung/odroid-xu3/Kconfig create mode 100644
> > board/samsung/odroid-xu3/MAINTAINERS create mode 100644
> > board/samsung/odroid-xu3/Makefile create mode 100644
> > board/samsung/odroid-xu3/odroid-xu3.c create mode 100644
> > board/samsung/odroid-xu3/setup.h create mode 100644
> > configs/odroid-xu3_defconfig create mode 100644
> > include/configs/odroid_xu3.h
> >
> > diff --git a/arch/arm/cpu/armv7/exynos/Kconfig
> > b/arch/arm/cpu/armv7/exynos/Kconfig index 13dbd95..16c9a0e 100644
> > --- a/arch/arm/cpu/armv7/exynos/Kconfig
> > +++ b/arch/arm/cpu/armv7/exynos/Kconfig
> > @@ -24,6 +24,10 @@ config TARGET_TRATS2
> > config TARGET_ODROID
> > bool "Exynos4412 Odroid board"
> >
> > +config TARGET_ODROID_XU3
> > + bool "Exynos5422 Odroid board"
> > + select OF_CONTROL
> > +
> > config TARGET_ARNDALE
> > bool "Exynos5250 Arndale board"
> > select SUPPORT_SPL
> > @@ -65,6 +69,7 @@ source "board/samsung/universal_c210/Kconfig"
> > source "board/samsung/origen/Kconfig"
> > source "board/samsung/trats2/Kconfig"
> > source "board/samsung/odroid/Kconfig"
> > +source "board/samsung/odroid-xu3/Kconfig"
> > source "board/samsung/arndale/Kconfig"
> > source "board/samsung/smdk5250/Kconfig"
> > source "board/samsung/smdk5420/Kconfig"
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 2b9bd93..d984f34 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -12,7 +12,8 @@ dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
> > exynos5250-smdk5250.dtb \
> > exynos5420-smdk5420.dtb \
> > exynos5420-peach-pit.dtb \
> > - exynos5800-peach-pi.dtb
> > + exynos5800-peach-pi.dtb \
> > + exynos5422-odroidxu3.dtb
> > dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
> > tegra20-medcom-wide.dtb \
> > tegra20-paz00.dtb \
> > diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts
> > b/arch/arm/dts/exynos5422-odroidxu3.dts new file mode 100644
> > index 000..533d88e
> > --- /dev/null
> > +++ b/arch/arm/dts/exynos5422-odroidxu3.dts
> > @@ -0,0 +1,57 @@
> > +/*
> > + * Odroid XU3 device tree source
> > + *
> > + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> > + * http://www.samsung.com
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +/dts-v1/;
> > +#include "exynos54xx.dtsi"
> > +
> > +/ {
> > + model = "Odroid XU3 based on EXYNOS5422";
> > + compatible = "samsung,odroidxu3"
[U-Boot] [PATCHv4 respin 2/6] ARM: HYP/non-sec: Fix the ARCH Timer frequency setting.
For some SoCs, the system clock frequency may not equal to the ARCH Timer's frequency. This patch uses the CONFIG_TIMER_CLK_FREQ instead of CONFIG_SYS_CLK_FREQ, then the system clock macro and arch timer macor could be set separately and without interfering each other. Signed-off-by: Xiubo Li --- Hi Albert, I there is one mistake about the CONFIG_TIMER_CLK_FREQ defination for sun7i platform. So i respin this patch separately. Thanks, BRs Xiubo arch/arm/cpu/armv7/nonsec_virt.S | 4 ++-- include/configs/sun7i.h | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S index 1ab5d54..30d81db 100644 --- a/arch/arm/cpu/armv7/nonsec_virt.S +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -169,11 +169,11 @@ ENTRY(_nonsec_init) * we do this here instead. * But first check if we have the generic timer. */ -#ifdef CONFIG_SYS_CLK_FREQ +#ifdef CONFIG_TIMER_CLK_FREQ mrc p15, 0, r0, c0, c1, 1 @ read ID_PFR1 and r0, r0, #CPUID_ARM_GENTIMER_MASK@ mask arch timer bits cmp r0, #(1 << CPUID_ARM_GENTIMER_SHIFT) - ldreq r1, =CONFIG_SYS_CLK_FREQ + ldreq r1, =CONFIG_TIMER_CLK_FREQ mcreq p15, 0, r1, c14, c0, 0 @ write CNTFRQ #endif diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h index ea40790..368d527 100644 --- a/include/configs/sun7i.h +++ b/include/configs/sun7i.h @@ -28,6 +28,7 @@ #define CONFIG_ARMV7_PSCI_NR_CPUS 2 #define CONFIG_ARMV7_SECURE_BASE SUNXI_SRAM_B_BASE #define CONFIG_SYS_CLK_FREQ2400 +#define CONFIG_TIMER_CLK_FREQ CONFIG_SYS_CLK_FREQ /* * Include common sunxi configuration where most the settings are -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] odroid: Turn blue LED on
Dear Suriyan Ramasami, On 18/11/14 08:50, Suriyan Ramasami wrote: > To indicate that U-Boot is active, turn on the blue LED. > > Signed-off-by: Suriyan Ramasami > > --- > > Changes in v2: > - Przemyslaw Marczak, Add gpio_request call. > > Changes in v1: > - First try > > board/samsung/odroid/odroid.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c > index 33003ee..e1a86f9 100644 > --- a/board/samsung/odroid/odroid.c > +++ b/board/samsung/odroid/odroid.c > @@ -382,6 +382,11 @@ static void board_gpio_init(void) > gpio_set_pull(EXYNOS4X12_GPIO_X31, S5P_GPIO_PULL_UP); > gpio_set_drv(EXYNOS4X12_GPIO_X31, S5P_GPIO_DRV_4X); > gpio_direction_input(EXYNOS4X12_GPIO_X31); > + > + /* Blue LED (Odroid X2/U2/U3) */ > + gpio_request(EXYNOS4X12_GPIO_C10, "Blue LED"); > + > + gpio_direction_output(EXYNOS4X12_GPIO_C10, 0); > } > > static int pmic_init_max77686(void) > Because board_gpio_init was changed by you, please rebase this patch. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] odroid: usbhost - Add missing gpio_request call
On 21/11/14 10:26, Suriyan Ramasami wrote: > The USB host code was missing gpio_request() calls before using the gpio > functions, causing errors to be printed out. > > As a side note calls to max77686_set_buck_mode(OPMODE_OFF/OPMODE_ON) have > been removed, as they did not have any effect. This is as per Przemyslaw: > I looked into the documentation and there is a "ENB8" pin in PMIC package. > This pin allows steering BUCK8 ON/OFF by the vhardware. If ENB8 is set to low > then you can do on/off. If high, then you cannot change its state by I2C > write, which seems to be the case with the Odroids. > > Signed-off-by: Suriyan Ramasami > Acked-by: Przemyslaw Marczak > --- > > Changes in v2: > - Add comment why max77686_set_buck_mode() has been removed > Series-changes: 1 > - Added gpio_request() call in board_gpio_init() > > board/samsung/odroid/odroid.c | 13 +++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] odroid: Update README with USB host usage
On 21/11/14 10:26, Suriyan Ramasami wrote: > Add information wrt using the USB host interface for loading kernel over > ethernet and/or usb mass storage. > > Signed-off-by: Suriyan Ramasami > --- > > Changes in v2: > - Make updates to be of use from a user's perspective > Series-changes: 1 > - Add USB host notes for the Odroid > > doc/README.odroid | 169 > ++ > 1 file changed, 169 insertions(+) > applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx:mx6 fix return value of mxc_get_clock
On Sun, Nov 23, 2014 at 1:52 AM, Peng Fan wrote: > mxc_get_clock's return type is unsigned int. 'return -1' is same with > 'return 0x', so 0 should be used as the return value when > unsupported mxc_clock type is passed to mxc_get_clock. > > Also include an err message when unsupported mxc_clock type is passed > to mxc_get_clock. > > Signed-off-by: Peng Fan Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: remove fdtdec_get_alias_node() function
On 21 November 2014 at 03:47, Masahiro Yamada wrote: > The fdt_path_offset() checks an alias too. > > fdtdec_get_alias_node(blob, "foo") is equivalent to > fdt_path_offset(blob, "foo"). > > Signed-off-by: Masahiro Yamada > --- > > drivers/serial/serial-uclass.c | 2 +- > include/fdtdec.h | 11 --- > lib/fdtdec.c | 15 --- > 3 files changed, 1 insertion(+), 27 deletions(-) Thanks! Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] buildman reports error of script/binutils-version.sh
Hi, On 21 November 2014 at 16:36, York Sun wrote: > Simon, > > Shall we consider host error to be an error reported by buildman? I happen to > try a newer version of toolchain from Linaro. Buildman reports this error > > > +../scripts/binutils-version.sh: line 20: printf: 09: invalid octal number > > The root cause is this version of AS reports version string differently > > GNU assembler (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC > 4.9-2014.09) > 2.24.0.20140829 Linaro 2014.09 > > It has "Linaro 2014.09" at the back, so script/binutils-version.sh cannot > parse > it correctly (the error is not handling zero-leading numbers, but not in the > scope of this discussion). > > Another angle of this question is, why do we need this script? It doesn't > sound > stable to me to parse the version string this way. That's another one in Masahiro's domain I think. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix: tools: kwbimage.c: Initialize headersz to suppress warning
Hi Albert, Sorry for a late reply. > Hello Lukasz, > > On Sat, 22 Nov 2014 07:56:35 +0100, Lukasz Majewski > wrote: > > > > Agreed in general, but not for this one, since "fixing" is the > > > carpet, > > > > I assume that you are presenting below an answer to a "general" > > case. > > > > However, as Thomas pointed out earlier, this "fix" is perfectly safe > > regarding the underlying kwbimage code. > > Jeroen and I (full disclaimer: we have discussed the topic on IRC) > do not contend that the proposed fix would be unsafe; it *is* safe, > i.e. it does not adversely affect the code behavior in any measurable > way. > > What we contend is that the fix be the /right/ fix (although Jeroen > and I have slightly differing criteria for defining what "the right > fix" would be). > > > > > and > > > > the only justification I see as acceptable for doing so is when > > > > leaving the warning enabled would cause an obnoxiously high > > > > number of false positives. > > > > > > Well let me add, if "fixing the warning" causes real error > > > to be hidden, we shouldn't "fix" the warnings by modifying > > > valid code. > > > > Each subsequent "fix" for this kind of warning should be considered > > case by case IMHO, therefore I agree with Albert. > > Jeroen also agreed on IRC that disabling the compiler warning is not > the right fix either; and I agreed that there had to be a better fix > than pseudo-initializing headersz. I therefore suggested refactoring > kwbimage_set_header in order to ensure gcc does not emit the warning, > but without resorting to non-functional code such as a functionally > meaningless initialization. > > Problem is, to refactor the code, one needs a gcc which emits the > warnig. I tried various versions of gcc (4.7.4, 4.8.3, 4.9.1) and all > remained silent when compiling tools/kwbimage.c. > > Hence my request: Lukasz, which toolchain are you using exactly? Where > can we download it from? The warning appear on my personal laptop too: lukma@jawa:~/work/embedded/u-boot-denx (master)$ cc -v Using built-in specs. COLLECT_GCC=cc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) HOSTCC tools/kwbimage.o tools/kwbimage.c: In function ‘kwbimage_set_header’: tools/kwbimage.c:803:8: warning: ‘headersz’ may be used uninitialized in this function [-Wmaybe-uninitialized] Debian distro: version 7.6 (Wheezy) I will check the exact gcc on my office PC tomorrow. Heiko also complained about this Warning. Heiko could you also share information about your setup? > > > > Regards, > > > Jeroen > > > > Best regards, > > Lukasz Majewski > > Amicalement, Best regards, Lukasz Majewski signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] set and test a local variable in a script
Dear Andreas, In message <547211ba.7080...@gmx.at> you wrote: > > many, many, many thx for your quick response ... now it works, and i > know why it hasn't :) I'm glad I was able to help. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If the car industry behaved like the computer industry over the last 30 years, a Rolls-Royce would cost $5, get 300 miles per gallon, and blow up once a year killing all passengers inside. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] set and test a local variable in a script
hi,
many, many, many thx for your quick response ... now it works, and i
know why it hasn't :)
br,
Andy
On 22.11.2014 23:56, Wolfgang Denk wrote:
Dear Andreas,
In message <5470d48c.1080...@gmx.at> you wrote:
i'm trying to set a local variable and test the variable in an
if-then-else script ...
but it's somehow a bit weird!?
Not really weird; you just have to be a bit careful about quoting
rules...
- set variable "nea" to 0
- create a script "x" and run OK
- modify variable "nea" to 1
- run script "x" again ... NOK?!
... what i'm doing wrong - the behavior is the same with 2013.10 and
2014.01
...and it would be the same if you were testing with a regular shell on
the Linux command line.
Actually this is something I always recommend: if you see some strange
behaviour, first try to do the same in a standard shell environment,
and debug it there.
>U-Boot# nea=0
>U-Boot# setenv x "if itest 1 -eq $nea; then echo var1; else echo var0;
fi;"
It would have been a good idea here todo a "printenv x" to check what
was actually stored in the variable - this would have shown your
problem. The thing is, you want to keep the '$nea' notation in the
variable, so you can evaluate the variable when you run that macro.
However, inside double quotes (") variable substitution takes place,
so above command is equivalent to
setenv x "if itest 1 -eq 0; then echo var1; else echo var0; fi;"
>U-Boot# run x
>var0
>U-Boot# nea=1
>U-Boot# run x
>var0<- so now i should get the "var1" as a result
>U-Boot# echo $nea
>1
Use printenv to verify what is stored in the variable x, and you will
understand this.
Best regards,
Wolfgang Denk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] ARM: tegra: Add support for nyan board
Hi, On 23 November 2014 at 09:12, Simon Glass wrote: > > From: Allen Martin > > Nyan is a Tegra124 clamshell board that is very similar to venice2, but it > has a different panel, the sdcard cd and wp sense are flipped, and it has > a different revision of the AS3722 PMIC. > > This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA > Tegra K1, 2GB). The display is not currently supported, so it should > boot on other nyan-based Chromebooks also, but only the device tree for > nyan-big is provided here. > > The device tree file is from Linux but with features removed which are > unlikely to be supported in U-Boot soon (regulators, pinmux). Also the > addresses are updated to 32-bit. > > Signed-off-by: Allen Martin > Signed-off-by: Simon Glass > (rebase, change to 'nyan', fix pinmux that resets nyan) > > --- > > Changes in v3: > - Rename to nyan from norrin > - Bring in device tree file from Linux v3.18-rc5 > - Generate pinmux file from tegra-pinmux-scripts I should say that I'm not thrilled with this approach, particularly as the files it generate have no mentioned that they are auto-generated. Here we have a case where Nyan and Norrin apparently different by one pixmux setting but there is no way to exploit this commonality. I think this was discussed a while ago (the idea of static pinmux being set up at start of day). If I recall I expressed my objections at the time. If U-Boot headed this way in general it would be unfortunate. You get a whole load of pinmux settings with no idea what they are for, and no idea how to change them for your board. It almost feels similar to a 'binary blob'. I recently saw a patch to (from what I can tell) remove all the pinmux information from the device tree in Linux, presumably on the assumption it can never be changed except very early in the boot. If this is a limitation of Tegra then it seems unfortunate to me. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/4] ARM: tegra: Add support for nyan board
From: Allen Martin
Nyan is a Tegra124 clamshell board that is very similar to venice2, but it
has a different panel, the sdcard cd and wp sense are flipped, and it has
a different revision of the AS3722 PMIC.
This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA
Tegra K1, 2GB). The display is not currently supported, so it should
boot on other nyan-based Chromebooks also, but only the device tree for
nyan-big is provided here.
The device tree file is from Linux but with features removed which are
unlikely to be supported in U-Boot soon (regulators, pinmux). Also the
addresses are updated to 32-bit.
Signed-off-by: Allen Martin
Signed-off-by: Simon Glass
(rebase, change to 'nyan', fix pinmux that resets nyan)
---
Changes in v3:
- Rename to nyan from norrin
- Bring in device tree file from Linux v3.18-rc5
- Generate pinmux file from tegra-pinmux-scripts
Changes in v2:
- Rebase and adjust for Kconfig
- Fix up pinmux that reset norrin
- Add note as to the Chromebook's retail name, since it is now released
arch/arm/cpu/armv7/tegra124/Kconfig| 11 +
arch/arm/dts/Makefile | 1 +
arch/arm/dts/tegra124-nyan-big.dts | 365 +
board/nvidia/nyan/Kconfig | 24 +++
board/nvidia/nyan/MAINTAINERS | 6 +
board/nvidia/nyan/Makefile | 9 +
board/nvidia/nyan/nyan.c | 29 +++
board/nvidia/nyan/pinmux-config-nyan.h | 287 ++
board/nvidia/venice2/as3722_init.h | 2 +-
configs/nyan_defconfig | 5 +
include/configs/nyan.h | 76 +++
11 files changed, 814 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/tegra124-nyan-big.dts
create mode 100644 board/nvidia/nyan/Kconfig
create mode 100644 board/nvidia/nyan/MAINTAINERS
create mode 100644 board/nvidia/nyan/Makefile
create mode 100644 board/nvidia/nyan/nyan.c
create mode 100644 board/nvidia/nyan/pinmux-config-nyan.h
create mode 100644 configs/nyan_defconfig
create mode 100644 include/configs/nyan.h
diff --git a/arch/arm/cpu/armv7/tegra124/Kconfig
b/arch/arm/cpu/armv7/tegra124/Kconfig
index 6a1c83a..4238107 100644
--- a/arch/arm/cpu/armv7/tegra124/Kconfig
+++ b/arch/arm/cpu/armv7/tegra124/Kconfig
@@ -6,6 +6,16 @@ choice
config TARGET_JETSON_TK1
bool "NVIDIA Tegra124 Jetson TK1 board"
+config TARGET_NYAN
+ bool "Google/NVIDIA Nyan Chrombook"
+ help
+ Norrin (PM370) is a Tegra124 clamshell board that is very similar
+ to venice2, but it has a different panel, the sdcard CD and WP
+ sense are flipped, and it has a different revision of the AS3722
+ PMIC. This board is also refered to as "nyan" in the Chrome OS
+ trees. The retail name is the Acer Chromebook 13 CB5-311-T7NN
+ (13.3-inch HD, NVIDIA Tegra K1, 2GB).
+
config TARGET_VENICE2
bool "NVIDIA Tegra124 Venice2"
@@ -15,6 +25,7 @@ config SYS_SOC
default "tegra124"
source "board/nvidia/jetson-tk1/Kconfig"
+source "board/nvidia/nyan/Kconfig"
source "board/nvidia/venice2/Kconfig"
endif
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ba6dec9..2d2dd31 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -30,6 +30,7 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra30-tec-ng.dtb \
tegra114-dalmore.dtb \
tegra124-jetson-tk1.dtb \
+ tegra124-nyan-big.dtb \
tegra124-venice2.dtb
dtb-$(CONFIG_ZYNQ) += zynq-zc702.dtb \
zynq-zc706.dtb \
diff --git a/arch/arm/dts/tegra124-nyan-big.dts
b/arch/arm/dts/tegra124-nyan-big.dts
new file mode 100644
index 000..c1f35a0
--- /dev/null
+++ b/arch/arm/dts/tegra124-nyan-big.dts
@@ -0,0 +1,365 @@
+/dts-v1/;
+
+#include
+#include "tegra124.dtsi"
+
+/ {
+ model = "Acer Chromebook 13 CB5-311";
+ compatible = "google,nyan-big", "nvidia,tegra124";
+
+ aliases {
+ console = &uarta;
+ i2c0 = "/i2c@7000d000";
+ i2c1 = "/i2c@7000c000";
+ i2c2 = "/i2c@7000c400";
+ i2c3 = "/i2c@7000c500";
+ i2c4 = "/i2c@7000c700";
+ i2c5 = "/i2c@7000d100";
+ rtc0 = "/i2c@0,7000d000/pmic@40";
+ rtc1 = "/rtc@0,7000e000";
+ sdhci0 = "/sdhci@700b0600";
+ sdhci1 = "/sdhci@700b0400";
+ spi0 = "/spi@7000d400";
+ spi1 = "/spi@7000da00";
+ usb0 = "/usb@7d00";
+ usb1 = "/usb@7d008000";
+ };
+
+ memory {
+ reg = <0x8000 0x8000>;
+ };
+
+ serial@70006000 {
+ /* Debug connector on the bottom of the board near SD card. */
+ status = "okay";
+ };
+
+ pwm@7000a000 {
+ status = "okay";
+ };
+
+ i2c@7000c000 {
+ status = "okay";
+ clock-frequency = <10>;
+
+ acodec: audio-code
[U-Boot] [PATCH v3 2/4] tegra: dts: Sync tegra124.dtsi with linux kernel
Sync this up with Linux v3.18-rc5. Exclude features that are unlikely to
supported in U-Boot soon (regulators, pinmux). Also the addresses are
updated to 32-bit. Otherwise it is the same. Also bring in the dt-bindings
for pinctrl.
Signed-off-by: Simon Glass
---
Changes in v3:
- Add patch to update tegra124.dtsi from Linux v3.18-rc5
Changes in v2: None
arch/arm/dts/tegra124.dtsi | 114
include/dt-bindings/pinctrl/pinctrl-tegra.h | 45 +++
2 files changed, 159 insertions(+)
create mode 100644 include/dt-bindings/pinctrl/pinctrl-tegra.h
diff --git a/arch/arm/dts/tegra124.dtsi b/arch/arm/dts/tegra124.dtsi
index 3288f28..6b5c2be 100644
--- a/arch/arm/dts/tegra124.dtsi
+++ b/arch/arm/dts/tegra124.dtsi
@@ -1,5 +1,6 @@
#include
#include
+#include
#include
#include "skeleton.dtsi"
@@ -192,6 +193,16 @@
status = "disabled";
};
+ pwm: pwm@7000a000 {
+ compatible = "nvidia,tegra124-pwm", "nvidia,tegra20-pwm";
+ reg = <0x7000a000 0x100>;
+ #pwm-cells = <2>;
+ clocks = <&tegra_car TEGRA124_CLK_PWM>;
+ resets = <&tegra_car 17>;
+ reset-names = "pwm";
+ status = "disabled";
+ };
+
spi@7000d400 {
compatible = "nvidia,tegra124-spi", "nvidia,tegra114-spi";
reg = <0x7000d400 0x200>;
@@ -290,6 +301,109 @@
status = "disabled";
};
+ ahub@7030 {
+ compatible = "nvidia,tegra124-ahub";
+ reg = <0x7030 0x200>,
+ <0x70300800 0x800>,
+ <0x70300200 0x600>;
+ interrupts = ;
+ clocks = <&tegra_car TEGRA124_CLK_D_AUDIO>,
+<&tegra_car TEGRA124_CLK_APBIF>;
+ clock-names = "d_audio", "apbif";
+ resets = <&tegra_car 106>, /* d_audio */
+<&tegra_car 107>, /* apbif */
+<&tegra_car 30>, /* i2s0 */
+<&tegra_car 11>, /* i2s1 */
+<&tegra_car 18>, /* i2s2 */
+<&tegra_car 101>, /* i2s3 */
+<&tegra_car 102>, /* i2s4 */
+<&tegra_car 108>, /* dam0 */
+<&tegra_car 109>, /* dam1 */
+<&tegra_car 110>, /* dam2 */
+<&tegra_car 10>, /* spdif */
+<&tegra_car 153>, /* amx */
+<&tegra_car 185>, /* amx1 */
+<&tegra_car 154>, /* adx */
+<&tegra_car 180>, /* adx1 */
+<&tegra_car 186>, /* afc0 */
+<&tegra_car 187>, /* afc1 */
+<&tegra_car 188>, /* afc2 */
+<&tegra_car 189>, /* afc3 */
+<&tegra_car 190>, /* afc4 */
+<&tegra_car 191>; /* afc5 */
+ reset-names = "d_audio", "apbif", "i2s0", "i2s1", "i2s2",
+ "i2s3", "i2s4", "dam0", "dam1", "dam2",
+ "spdif", "amx", "amx1", "adx", "adx1",
+ "afc0", "afc1", "afc2", "afc3", "afc4", "afc5";
+ dmas = <&apbdma 1>, <&apbdma 1>,
+ <&apbdma 2>, <&apbdma 2>,
+ <&apbdma 3>, <&apbdma 3>,
+ <&apbdma 4>, <&apbdma 4>,
+ <&apbdma 6>, <&apbdma 6>,
+ <&apbdma 7>, <&apbdma 7>,
+ <&apbdma 12>, <&apbdma 12>,
+ <&apbdma 13>, <&apbdma 13>,
+ <&apbdma 14>, <&apbdma 14>,
+ <&apbdma 29>, <&apbdma 29>;
+ dma-names = "rx0", "tx0", "rx1", "tx1", "rx2", "tx2",
+ "rx3", "tx3", "rx4", "tx4", "rx5", "tx5",
+ "rx6", "tx6", "rx7", "tx7", "rx8", "tx8",
+ "rx9", "tx9";
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ tegra_i2s0: i2s@70301000 {
+ compatible = "nvidia,tegra124-i2s";
+ reg = <0x70301000 0x100>;
+ nvidia,ahub-cif-ids = <4 4>;
+ clocks = <&tegra_car TEGRA124_CLK_I2S0>;
+ resets = <&tegra_car 30>;
+ reset-names = "i2s";
+ status = "disabled";
+ };
+
+ tegra_i2s1: i2s@70301100 {
+ compatible = "nvidia,tegra124-i2s";
+ reg = <0x70301100 0x100>;
+ nvidia,ahub-cif-ids = <5 5>;
+ clocks = <&tegra_car TEGRA124_CLK_I2S1>;
+ resets = <&tegra_car 11>;
+ reset-names = "i2s";
+
[U-Boot] [PATCH v3 3/4] tegra: config: Enable FIT and device tree for all boards
Modern kernels require a device tree to boot. Enable FIT support to permit booting these images, rather than just legacy images. This allows booting of Chrome OS kernels, among other things. Signed-off-by: Simon Glass --- Changes in v3: - Add new patch to enable FIT support for Tegra boards Changes in v2: None include/configs/tegra-common.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h index 5d2b12a..c8c2366 100644 --- a/include/configs/tegra-common.h +++ b/include/configs/tegra-common.h @@ -162,6 +162,9 @@ #define CONFIG_BOUNCE_BUFFER #define CONFIG_CRC32_VERIFY +#define CONFIG_FIT +#define CONFIG_OF_LIBFDT + #ifndef CONFIG_SPL_BUILD #include #endif -- 2.1.0.rc2.206.gedb03e5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] dts: Bring in Chrome OS keyboard device tree definition
This will be used by nyan, but bring it in in a separate patch since it
will be common to other boards.
Signed-off-by: Simon Glass
---
Changes in v3:
- Add patch to bring in cros-ec-keyboard.dtsi
Changes in v2: None
arch/arm/dts/cros-ec-keyboard.dtsi | 105 +
1 file changed, 105 insertions(+)
create mode 100644 arch/arm/dts/cros-ec-keyboard.dtsi
diff --git a/arch/arm/dts/cros-ec-keyboard.dtsi
b/arch/arm/dts/cros-ec-keyboard.dtsi
new file mode 100644
index 000..9c7fb0a
--- /dev/null
+++ b/arch/arm/dts/cros-ec-keyboard.dtsi
@@ -0,0 +1,105 @@
+/*
+ * Keyboard dts fragment for devices that use cros-ec-keyboard
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include
+
+&cros_ec {
+ keyboard-controller {
+ compatible = "google,cros-ec-keyb";
+ keypad,num-rows = <8>;
+ keypad,num-columns = <13>;
+ google,needs-ghost-filter;
+
+ linux,keymap = <
+ MATRIX_KEY(0x00, 0x01, KEY_LEFTMETA)
+ MATRIX_KEY(0x00, 0x02, KEY_F1)
+ MATRIX_KEY(0x00, 0x03, KEY_B)
+ MATRIX_KEY(0x00, 0x04, KEY_F10)
+ MATRIX_KEY(0x00, 0x06, KEY_N)
+ MATRIX_KEY(0x00, 0x08, KEY_EQUAL)
+ MATRIX_KEY(0x00, 0x0a, KEY_RIGHTALT)
+
+ MATRIX_KEY(0x01, 0x01, KEY_ESC)
+ MATRIX_KEY(0x01, 0x02, KEY_F4)
+ MATRIX_KEY(0x01, 0x03, KEY_G)
+ MATRIX_KEY(0x01, 0x04, KEY_F7)
+ MATRIX_KEY(0x01, 0x06, KEY_H)
+ MATRIX_KEY(0x01, 0x08, KEY_APOSTROPHE)
+ MATRIX_KEY(0x01, 0x09, KEY_F9)
+ MATRIX_KEY(0x01, 0x0b, KEY_BACKSPACE)
+
+ MATRIX_KEY(0x02, 0x00, KEY_LEFTCTRL)
+ MATRIX_KEY(0x02, 0x01, KEY_TAB)
+ MATRIX_KEY(0x02, 0x02, KEY_F3)
+ MATRIX_KEY(0x02, 0x03, KEY_T)
+ MATRIX_KEY(0x02, 0x04, KEY_F6)
+ MATRIX_KEY(0x02, 0x05, KEY_RIGHTBRACE)
+ MATRIX_KEY(0x02, 0x06, KEY_Y)
+ MATRIX_KEY(0x02, 0x07, KEY_102ND)
+ MATRIX_KEY(0x02, 0x08, KEY_LEFTBRACE)
+ MATRIX_KEY(0x02, 0x09, KEY_F8)
+
+ MATRIX_KEY(0x03, 0x01, KEY_GRAVE)
+ MATRIX_KEY(0x03, 0x02, KEY_F2)
+ MATRIX_KEY(0x03, 0x03, KEY_5)
+ MATRIX_KEY(0x03, 0x04, KEY_F5)
+ MATRIX_KEY(0x03, 0x06, KEY_6)
+ MATRIX_KEY(0x03, 0x08, KEY_MINUS)
+ MATRIX_KEY(0x03, 0x0b, KEY_BACKSLASH)
+
+ MATRIX_KEY(0x04, 0x00, KEY_RIGHTCTRL)
+ MATRIX_KEY(0x04, 0x01, KEY_A)
+ MATRIX_KEY(0x04, 0x02, KEY_D)
+ MATRIX_KEY(0x04, 0x03, KEY_F)
+ MATRIX_KEY(0x04, 0x04, KEY_S)
+ MATRIX_KEY(0x04, 0x05, KEY_K)
+ MATRIX_KEY(0x04, 0x06, KEY_J)
+ MATRIX_KEY(0x04, 0x08, KEY_SEMICOLON)
+ MATRIX_KEY(0x04, 0x09, KEY_L)
+ MATRIX_KEY(0x04, 0x0a, KEY_BACKSLASH)
+ MATRIX_KEY(0x04, 0x0b, KEY_ENTER)
+
+ MATRIX_KEY(0x05, 0x01, KEY_Z)
+ MATRIX_KEY(0x05, 0x02, KEY_C)
+ MATRIX_KEY(0x05, 0x03, KEY_V)
+ MATRIX_KEY(0x05, 0x04, KEY_X)
+ MATRIX_KEY(0x05, 0x05, KEY_COMMA)
+ MATRIX_KEY(0x05, 0x06, KEY_M)
+ MATRIX_KEY(0x05, 0x07, KEY_LEFTSHIFT)
+ MATRIX_KEY(0x05, 0x08, KEY_SLASH)
+ MATRIX_KEY(0x05, 0x09, KEY_DOT)
+ MATRIX_KEY(0x05, 0x0b, KEY_SPACE)
+
+ MATRIX_KEY(0x06, 0x01, KEY_1)
+ MATRIX_KEY(0x06, 0x02, KEY_3)
+ MATRIX_KEY(0x06, 0x03, KEY_4)
+ MATRIX_KEY(0x06, 0x04, KEY_2)
+ MATRIX_KEY(0x06, 0x05, KEY_8)
+ MATRIX_KEY(0x06, 0x06, KEY_7)
+ MATRIX_KEY(0x06, 0x08, KEY_0)
+ MATRIX_KEY(0x06, 0x09, KEY_9)
+ MATRIX_KEY(0x06, 0x0a, KEY_LEFTALT)
+ MATRIX_KEY(0x06, 0x0b, KEY_DOWN)
+ MATRIX_KEY(0x06, 0x0c, KEY_RIGHT)
+
+ MATRIX_KEY(0x07, 0x01, KEY_Q)
+ MATRIX_KEY(0x07, 0x02, KEY_E)
+ MATRIX_KEY(0x07, 0x03, KEY_R)
+ MATRIX_KEY(0x07,
[U-Boot] [PATCH] sunxi: video: Add extra modes and allow selecting the mode via hdmi_mode env
Add the following extra modes:
1280x720@50
1920x1080@60
1920x1200@60
And allow selecting them by setting (and then saving and rebooting) a
hdmi_mode env variable to the name of the mode.
Also make the reserved fb mem slightly larger to allow 1920x1200 to work.
Signed-off-by: Hans de Goede
---
drivers/video/sunxi_display.c | 91 +-
include/configs/sunxi-common.h | 2 +-
2 files changed, 81 insertions(+), 12 deletions(-)
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index 3060bee..349e36c 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -355,15 +355,14 @@ retry:
}
}
-void *video_hw_init(void)
+static void video_get_mode(char *modestr, struct fb_videomode *mode)
{
- static GraphicDevice *graphic_device = &sunxi_display.graphic_device;
- /*
-* Vesa standard 1024x768@60
-* 65.0 1024 1032 1176 1344 768 771 777 806 -hsync -vsync
-*/
- struct fb_videomode mode = {
- .name = "1024x768",
+ const struct fb_videomode modes[] = { {
+ /*
+* Vesa standard 1024x768@60
+* 65.0 1024 1032 1176 1344 768 771 777 806 -hsync -vsync
+*/
+ .name = "1024x768@60",
.refresh = 60,
.xres = 1024,
.yres = 768,
@@ -377,7 +376,76 @@ void *video_hw_init(void)
.sync = 0,
.vmode = 0,
.flag = 0,
- };
+ } , {
+ .name = "1280x720@50",
+ .refresh = 50,
+ .xres = 1280,
+ .yres = 720,
+ .pixclock = 74250,
+ .left_margin = 440,
+ .right_margin = 220,
+ .upper_margin = 20,
+ .lower_margin = 5,
+ .hsync_len = 40,
+ .vsync_len = 5,
+ .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ .vmode = FB_VMODE_NONINTERLACED,
+ .flag = 0,
+ } , {
+ .name = "1920x1080@60",
+ .refresh = 60,
+ .xres = 1920,
+ .yres = 1080,
+ .pixclock = 148500,
+ .left_margin = 88,
+ .right_margin = 148,
+ .upper_margin = 36,
+ .lower_margin = 4,
+ .hsync_len = 44,
+ .vsync_len = 5,
+ .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ .vmode = FB_VMODE_NONINTERLACED,
+ .flag = 0,
+ } , {
+ .name = "1920x1200@60",
+ .refresh = 60,
+ .xres = 1920,
+ .yres = 1200,
+ .pixclock = 154000,
+ .left_margin = 48,
+ .right_margin = 80,
+ .upper_margin = 26,
+ .lower_margin = 3,
+ .hsync_len = 32,
+ .vsync_len = 6,
+ .sync = FB_SYNC_HOR_HIGH_ACT,
+ .vmode = FB_VMODE_NONINTERLACED,
+ .flag = 0,
+ } };
+ int i;
+
+ if (!modestr) {
+ *mode = modes[0];
+ return;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(modes); i++) {
+ if (strcmp(modes[i].name, modestr) == 0)
+ break;
+ }
+ if (i >= ARRAY_SIZE(modes)) {
+ eprintf("Mode %s not available, falling back to %s\n",
+ modestr, modes[0].name);
+ i = 0;
+ }
+
+ *mode = modes[i];
+}
+
+void *video_hw_init(void)
+{
+ static GraphicDevice *graphic_device = &sunxi_display.graphic_device;
+ struct fb_videomode mode;
int ret;
memset(&sunxi_display, 0, sizeof(struct sunxi_display));
@@ -390,10 +458,11 @@ void *video_hw_init(void)
if (!ret)
return NULL;
- printf("HDMI connected.\n");
sunxi_display.enabled = true;
+ video_get_mode(getenv("hdmi_mode"), &mode);
+
+ printf("HDMI connected, setting up a %s console.\n", mode.name);
- printf("Setting up a %s console.\n", mode.name);
sunxi_engines_init();
sunxi_mode_set(&mode, gd->fb_base - CONFIG_SYS_SDRAM_BASE);
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 7b958f8..a6cdffb 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -202,7 +202,7 @@
* The amount of RAM that is reserved for the FB. This will not show up as
* RAM to the kernel, but will be reclaimed by a KMS driver in future.
*/
-#define CONFIG_SUNXI_FB_SIZE (8 << 20)
+#define CONFIG_SUNXI_FB_SIZE (9 << 20)
/* Do we want to initialize a simple FB? */
#define CONFIG_VIDEO_DT_SIMPLEFB
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usbkbd input double echoed
Hi, On 11/23/2014 04:07 PM, Nikita Kiryanov wrote: > Hi all, > > I've enabled USB keyboard for cm_fx6 using these three defines: > > #define CONFIG_USB_KEYBOARD > #define CONFIG_SYS_USB_EVENT_POLL > #define CONFIG_SYS_STDIO_DEREGISTER > > I am able to probe it with `usb start`, and set it as input using > `setenv stdin usbkbd`. > > It works, save for one problem: all key presses are echoed twice. > The double echo happens both on serial and vga stdout. > It is not dependant on the keyboard (tried different ones). > Output from commands looks normal. > Switching to CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP did not help. > Shell still understands each key press as one key press, so > even though "pprriinntteennvv" is displayed, the shell still sees > "printenv". > > Any idea what the cause may be? In my experience both polling methods are sub-optimal, if your board has an ehci controller, try using CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE Also I use CONFIG_CONSOLE_MUX, then you can do: setenv stdin serial,usbkbd And get both, using this usb-kbd support works fine for me, without the double echo, both on the serial console and on the sunxi-cfb console over hdmi. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-dm
Hi Tom, There several driver model series outstanding. This request tries to bring in what I think is ready for merging. - at91 series - most of the SPL series, but as mentioned I need a revert of 1ee30aee before enabling this on Tegra (I know you are working on that) - the common parts of the I2C series. You may have seen Masahiro's suggestion to change the uclass <-> driver interface to something more like Linux. I would like to investigate this before merging the I2C series. - a few other fairly small clean-ups This leaves about 12 patches to come from the above series, which is a more manageable level. If we can sort out the I2C uclass and revert then I should be able to do this in the next week or so. One I2C is sorted out I can merge Thierry's Tegra PCI-e series which depends on it. Then there are a few remaining patches from Masahiro to integrate, and hopefully fixing up driver model to use Kconfig everywhere. That will complete the driver model work for 2015.01. -- The following changes since commit 4d70b34d7f721d8b1d4d628e68c3a44ab7a10dff: Merge branch 'master' of git://git.denx.de/u-boot-ubi (2014-11-19 23:18:29 -0500) are available in the git repository at: git://git.denx.de/u-boot-dm.git for you to fetch changes up to 17b28edb37a33d0c89089faf36e4edd7084f65fa: dm: core: remove unnecessary return condition in uclass lookup (2014-11-22 10:16:49 +0100) Masahiro Yamada (4): dm: core: a trivial clean up dm: core: remove meaningless if conditional dm: core: remove unnecessary return condition in driver lookup dm: core: remove unnecessary return condition in uclass lookup Simon Glass (29): dm: at91: Correct text base for snapper9260 dm: at91: Move snapper9260 to generic baord dm: at91: Add driver model support for atmel GPIO driver dm: at91: Add platform data for GPIO on at91sam9260-based boards dm: at91: Refactor serial driver slightly for driver model dm: at91: Add driver model support for the serial driver dm: at91: Convert snapper9260 to use driver model dm: at91: Add myself as maintainer for snapper9260 dm: serial: Support changing the baud rate dm: tegra: Avoid using arch-specific memcpy() in SPL dm: Split the simple malloc() implementation into its own file dm: arm: spl: Allow simple malloc() in SPL dm: spl: Make simple malloc() available when enabled dm: spl: Allow driver model to be used dm: Allow device removal features to be dropped dm: Allow stdio registration to be dropped dm: Disable dm_warn() in SPL dm: tegra: Add platform data for the SPL uart dm: tegra: Add platform data for the GPIO driver dm: arm: spl: Make driver model linker lists available dm: Update documentation to include CONFIG_DM... options dm: i2c: Move error reporting into a common function dm: core: Allow access to the device's driver_id data dm: core: Add functions to find parent and OF data dm: fdt: Correct handling of aliases with embedded digits dm: Add a function to bind a device by driver name dm: spi: Correct handling of SPI chip selects in sandbox dm: spi: Use device_bind_driver() instead of our own function cros_ec: Fix uninitialised variable in cros_ec.c README| 119 +++ arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c | 14 arch/arm/cpu/u-boot-spl.lds | 7 ++ arch/arm/include/asm/arch-at91/at91sam9260.h | 4 +- arch/arm/include/asm/arch-at91/atmel_serial.h | 15 arch/arm/include/asm/arch-at91/gpio.h | 6 ++ arch/arm/lib/crt0.S | 2 +- board/bluewater/snapper9260/MAINTAINERS | 2 +- board/bluewater/snapper9260/snapper9260.c | 18 - board/nvidia/common/board.c | 8 ++ common/Makefile | 3 + common/board_r.c | 3 +- common/cmd_i2c.c | 32 +--- common/dlmalloc.c | 19 ++--- common/malloc_simple.c| 39 + common/spl/spl.c | 16 +++- doc/driver-model/README.txt | 44 +++--- drivers/core/Makefile | 3 +- drivers/core/device-remove.c | 187 ++ drivers/core/device.c | 178 +++- drivers/core/lists.c | 50 drivers/core/root.c | 4 +- drivers/gpio/at91_gpio.c | 241 ++- drivers/misc/cros_ec.c
[U-Boot] usbkbd input double echoed
Hi all, I've enabled USB keyboard for cm_fx6 using these three defines: #define CONFIG_USB_KEYBOARD #define CONFIG_SYS_USB_EVENT_POLL #define CONFIG_SYS_STDIO_DEREGISTER I am able to probe it with `usb start`, and set it as input using `setenv stdin usbkbd`. It works, save for one problem: all key presses are echoed twice. The double echo happens both on serial and vga stdout. It is not dependant on the keyboard (tried different ones). Output from commands looks normal. Switching to CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP did not help. Shell still understands each key press as one key press, so even though "pprriinntteennvv" is displayed, the shell still sees "printenv". Any idea what the cause may be? -- Regards, Nikita Kiryanov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/12] spi: sf: ICH SPI driver fix and flash params update
Hi Jagan, On Wed, Nov 12, 2014 at 3:04 PM, Jagan Teki wrote: > On 12 November 2014 07:57, Bin Meng wrote: >> Hi Jagan, >> >> On Wed, Nov 5, 2014 at 10:56 AM, Bin Meng wrote: >>> Hi Jagan, >>> >>> On Wed, Nov 5, 2014 at 5:21 AM, Jagan Teki wrote: On 1 November 2014 14:23, Bin Meng wrote: > This series fix several bugs in current ICH SPI driver as well as > adding byte program support for the SST25* flash. > > Flash params are updated to explicitly list supported read commands > and change flash sector size to 4KiB as long as flash supports > sector erase (20h) command. > > Changes for v2: > - Rebased to u-boot-spi/mater. > - Reviewed and updated the params of all currently supported flash > parts per their datasheets. > - Corrected AT25DF321 JEDEC ID. > - Corrected Atmel bulk erase command to 50h instead of D8h. > - Added AT25DF321A, W25X10, W25X20, W25X80 params. > > > Bin Meng (12): > spi/ich.c: Fix a bug of reading from a non-64 bytes aligned address > spi/ich.c: Set the rx operation mode for ich 7 > spi: sf: Support byte program for sst spi flash > sf: Update SST flash params > sf: Update Atmel flash params > sf: Update EON flash params > sf: Update GigaDevice flash params > sf: Update Macronix flash params > sf: Update Spansion flash params > sf: Update Micron flash params > sf: Update Winbond flash params > sf: Give proper spacing between flash table params I think you combined two or more changes(unrelated) in a common patches and Added Bulk erase support in e_cmd_rd of sf_params ie quite not correct. >>> >>> Do you mean I should let PATCH 1/2/3 go as a separate patch set? Since >>> these 3 are tested on my x86 board, could it be Simon to pick up these >>> patches instead of through the u-boot-spi? Also I don't understand you >>> comments about "adding bulk erase support in e_cmd_rd is not correct". >>> The e_cmd_rd in sf_params is updated to specify all supported read >>> commands the flash can support. There is no bulk erase here. >>> Please fix those and send me one more. Mean while I will look at your scenario like you're controller only supports AS, As I said before as AS of AF both are similar way of transferring except the dummy bits passing from the driver, try to see the fix on driver point of of instead of digging common sf stuff. >>> >>> Fixing on the driver part might be possible, might be not. Even though >>> it is possible, I don't want to do that as the ICH manual explicitly >>> says fast read command (0Bh) is not supported by the controller. As >>> far as I can test, actually all of the commands which require an >>> additional dummy byte after the address cycle fail to work. The >>> matches what the manual says. >>> >>> Regards, >>> Bin >> >> A gentle ping. > > Will back soon, please give some time. Any update on this patch series? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/5] sun6i: Drop some "unknown magic" from dram init
Allwinner tells us that this bit of code is the rtc ram being used to detect coming out of "super-standby" mode, and if that is the case, going out of self-refresh mode. Since we do not support "super-standby" mode, this can be dropped. Signed-off-by: Hans de Goede Acked-by: Ian Campbell --- arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c index 2ac0b58..5e163cb 100644 --- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c +++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c @@ -140,9 +140,6 @@ static void mctl_channel_init(int ch_index, struct dram_sun6i_para *para) writel((MCTL_TITMSRST << 18) | (MCTL_TDLLLOCK << 6) | MCTL_TDLLSRST, &mctl_phy->ptr0); - /* Unknown magic performed by boot0 */ - if ((readl(SUNXI_RTC_BASE + 0x20c) & 3) == 2) - setbits_le32(&mctl_phy->ptr0, 1 << 18); writel((MCTL_TDINIT1 << 19) | MCTL_TDINIT0, &mctl_phy->ptr1); writel((MCTL_TDINIT3 << 17) | MCTL_TDINIT2, &mctl_phy->ptr2); -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/5] sun6i: Add new CSQ_CS908 board
The CSQ CS908 is an A31s based top-set box, with 1G RAM, 8G NAND, rtl8188etv usb wifi, 2 USB A receptacles (1 connected through the OTG controller), ethernet, 3.5 mm jack with a/v out and hdmi out: http://www.geekbuying.com/item/CS908-Allwinner-A31S-Quad-Core-1-2GHz-Android-4-4-Mini-TV-Box-HDMI-HDD-Player-1G-8G-WIFI-Miracast---Black-95.html Note it has no sdcard slot and therefore can only be fel booted. Signed-off-by: Hans de Goede Acked-by: Ian Campbell --- configs/CSQ_CS908_defconfig | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 configs/CSQ_CS908_defconfig diff --git a/configs/CSQ_CS908_defconfig b/configs/CSQ_CS908_defconfig new file mode 100644 index 000..18fe1f3 --- /dev/null +++ b/configs/CSQ_CS908_defconfig @@ -0,0 +1,19 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS="USB_EHCI" +CONFIG_FDTFILE="sun6i-a31s-cs908.dtb" ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN6I=y ++S:CONFIG_TARGET_CSQ_CS908=y ++S:CONFIG_DRAM_CLK=432 ++S:CONFIG_DRAM_ZQ=123 +# Ethernet phy power ++S:CONFIG_AXP221_DLDO1_VOLT=3300 +# Wifi power ++S:CONFIG_AXP221_ALDO1_VOLT=3300 +# HDMI power ? ++S:CONFIG_AXP221_ALDO2_VOLT=1800 ++S:CONFIG_AXP221_ALDO3_VOLT=3000 +# No Vbus gpio for either usb ++S:CONFIG_USB1_VBUS_PIN="" ++S:CONFIG_USB2_VBUS_PIN="" -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/5] sun6i: Add sunxi_get_ss_bonding_id() function
Add a sunxi_get_ss_bonding_id() function, and use it to differentiate between
the A31s and the A31.
Signed-off-by: Hans de Goede
Acked-by: Ian Campbell
---
arch/arm/cpu/armv7/sunxi/cpu_info.c | 38 ++-
arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 4 ++-
arch/arm/include/asm/arch-sunxi/cpu.h | 5
3 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/cpu_info.c
b/arch/arm/cpu/armv7/sunxi/cpu_info.c
index 41b9add..5146dc4 100644
--- a/arch/arm/cpu/armv7/sunxi/cpu_info.c
+++ b/arch/arm/cpu/armv7/sunxi/cpu_info.c
@@ -9,6 +9,32 @@
#include
#include
#include
+#include
+
+#ifdef CONFIG_MACH_SUN6I
+int sunxi_get_ss_bonding_id(void)
+{
+ struct sunxi_ccm_reg * const ccm =
+ (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+ static int bonding_id = -1;
+
+ if (bonding_id != -1)
+ return bonding_id;
+
+ /* Enable Security System */
+ setbits_le32(&ccm->ahb_reset0_cfg, 1 << AHB_RESET_OFFSET_SS);
+ setbits_le32(&ccm->ahb_gate0, 1 << AHB_GATE_OFFSET_SS);
+
+ bonding_id = readl(SUNXI_SS_BASE);
+ bonding_id = (bonding_id >> 16) & 0x7;
+
+ /* Disable Security System again */
+ clrbits_le32(&ccm->ahb_gate0, 1 << AHB_GATE_OFFSET_SS);
+ clrbits_le32(&ccm->ahb_reset0_cfg, 1 << AHB_RESET_OFFSET_SS);
+
+ return bonding_id;
+}
+#endif
#ifdef CONFIG_DISPLAY_CPUINFO
int print_cpuinfo(void)
@@ -24,7 +50,17 @@ int print_cpuinfo(void)
default: puts("CPU: Allwinner A1X (SUN5I)\n");
}
#elif defined CONFIG_MACH_SUN6I
- puts("CPU: Allwinner A31 (SUN6I)\n");
+ switch (sunxi_get_ss_bonding_id()) {
+ case SUNXI_SS_BOND_ID_A31:
+ puts("CPU: Allwinner A31 (SUN6I)\n");
+ break;
+ case SUNXI_SS_BOND_ID_A31S:
+ puts("CPU: Allwinner A31s (SUN6I)\n");
+ break;
+ default:
+ printf("CPU: Allwinner A31? (SUN6I, id: %d)\n",
+ sunxi_get_ss_bonding_id());
+ }
#elif defined CONFIG_MACH_SUN7I
puts("CPU: Allwinner A20 (SUN7I)\n");
#elif defined CONFIG_MACH_SUN8I
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index 50a4b69..7e810bb 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -209,6 +209,7 @@ struct sunxi_ccm_reg {
#define AHB_GATE_OFFSET_MMC1 9
#define AHB_GATE_OFFSET_MMC0 8
#define AHB_GATE_OFFSET_MMC(n) (AHB_GATE_OFFSET_MMC0 + (n))
+#define AHB_GATE_OFFSET_SS 5
/* ahb_gate1 offsets */
#define AHB_GATE_OFFSET_DRC0 25
@@ -270,8 +271,9 @@ struct sunxi_ccm_reg {
#define AHB_RESET_OFFSET_MMC1 9
#define AHB_RESET_OFFSET_MMC0 8
#define AHB_RESET_OFFSET_MMC(n)(AHB_RESET_OFFSET_MMC0 + (n))
+#define AHB_RESET_OFFSET_SS5
-/* ahb_reset0 offsets */
+/* ahb_reset1 offsets */
#define AHB_RESET_OFFSET_DRC0 25
#define AHB_RESET_OFFSET_DE_BE012
#define AHB_RESET_OFFSET_HDMI 11
diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h
b/arch/arm/include/asm/arch-sunxi/cpu.h
index bdee89e..90e06c0 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu.h
@@ -135,9 +135,14 @@
#define SUNXI_CPU_CFG (SUNXI_TIMER_BASE + 0x13c)
+/* SS bonding ids used for cpu identification */
+#define SUNXI_SS_BOND_ID_A31 4
+#define SUNXI_SS_BOND_ID_A31S 5
+
#ifndef __ASSEMBLY__
void sunxi_board_init(void);
void sunxi_reset(void);
+int sunxi_get_ss_bonding_id(void);
#endif /* __ASSEMBLY__ */
#endif /* _CPU_H */
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/5] sun6i: dram: Do not try to initialize a second dram chan on A31s
The A31s only has one dram channel, so do not bother with trying to initialize a second channel. Signed-off-by: Hans de Goede --- arch/arm/cpu/armv7/sunxi/Makefile | 2 +- arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 11 +-- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv7/sunxi/Makefile b/arch/arm/cpu/armv7/sunxi/Makefile index 3b6ae47..1337b60 100644 --- a/arch/arm/cpu/armv7/sunxi/Makefile +++ b/arch/arm/cpu/armv7/sunxi/Makefile @@ -10,6 +10,7 @@ obj-y += timer.o obj-y += board.o obj-y += clock.o +obj-y += cpu_info.o obj-y += pinmux.o obj-$(CONFIG_MACH_SUN6I) += prcm.o obj-$(CONFIG_MACH_SUN8I) += prcm.o @@ -21,7 +22,6 @@ obj-$(CONFIG_MACH_SUN7I) += clock_sun4i.o obj-$(CONFIG_MACH_SUN8I) += clock_sun6i.o ifndef CONFIG_SPL_BUILD -obj-y += cpu_info.o ifdef CONFIG_ARMV7_PSCI obj-y += psci.o endif diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c index 30439dc..2ac0b58 100644 --- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c +++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c @@ -372,10 +372,15 @@ unsigned long sunxi_dram_init(void) .rows = 16, }; + /* A31s only has one channel */ + if (sunxi_get_ss_bonding_id() == SUNXI_SS_BOND_ID_A31S) + para.chan = 1; + mctl_sys_init(); mctl_dll_init(0, ¶); - mctl_dll_init(1, ¶); + if (para.chan == 2) + mctl_dll_init(1, ¶); setbits_le32(&mctl_com->ccr, MCTL_CCR_MASTER_CLK_EN | @@ -383,7 +388,9 @@ unsigned long sunxi_dram_init(void) MCTL_CCR_CH1_CLK_EN); mctl_channel_init(0, ¶); - mctl_channel_init(1, ¶); + if (para.chan == 2) + mctl_channel_init(1, ¶); + mctl_com_init(¶); mctl_port_cfg(); -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/5] sun6i: A31s / CSQ_CS908 board support
Hi, Here is v2 of my sun6i: A31s / CSQ_CS908 board support series. Changes since v1: -"sun6i: Make dram clk and zq value Kconfig options" -Mention changing of default zq value in commit message -Drop "if EXPERT" usage, as that breaks setting things through defconfig files -"sun6i: Drop some "unknown magic" from dram init" -Mention that the info on what the dropped unknown magic did comes from Allwinner -"sun6i: Add new CSQ_CS908 board" -Add setting of LDO for phy, so that network works -Correct usb vbus settings Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/5] sun6i: Make dram clk and zq value Kconfig options
It turns out that there is a too large spread between boards to handle this
with a default value, turn this into Kconfig options, and set the values
the factory images are using for the Colombus and Mele_M9 boards.
Note this changes the ZQ default when not overriden through defconfig from
120 to 123, as that is what most boards seem to actually use.
Signed-off-by: Hans de Goede
---
arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 12 +---
board/sunxi/Kconfig | 17 +
configs/Colombus_defconfig| 2 ++
configs/Mele_M9_defconfig | 2 ++
4 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
index 10a6241..30439dc 100644
--- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
+++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
@@ -17,9 +17,7 @@
#include
#include
-/* DRAM clk & zq defaults, maybe turn these into Kconfig options ? */
-#define DRAM_CLK_DEFAULT 31200
-#define DRAM_ZQ_DEFAULT 0x78
+#define DRAM_CLK (CONFIG_DRAM_CLK * 100)
struct dram_sun6i_para {
u8 bus_width;
@@ -48,7 +46,7 @@ static void mctl_sys_init(void)
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
const int dram_clk_div = 2;
- clock_set_pll5(DRAM_CLK_DEFAULT * dram_clk_div);
+ clock_set_pll5(DRAM_CLK * dram_clk_div);
clrsetbits_le32(&ccm->dram_clk_cfg, CCM_DRAMCLK_CFG_DIV0_MASK,
CCM_DRAMCLK_CFG_DIV0(dram_clk_div) | CCM_DRAMCLK_CFG_RST |
@@ -173,7 +171,7 @@ static void mctl_channel_init(int ch_index, struct
dram_sun6i_para *para)
await_completion(&mctl_phy->pgsr, 0x03, 0x03);
- writel(DRAM_ZQ_DEFAULT, &mctl_phy->zq0cr1);
+ writel(CONFIG_DRAM_ZQ, &mctl_phy->zq0cr1);
setbits_le32(&mctl_phy->pir, MCTL_PIR_CLEAR_STATUS);
writel(MCTL_PIR_STEP1, &mctl_phy->pir);
@@ -219,9 +217,9 @@ static void mctl_channel_init(int ch_index, struct
dram_sun6i_para *para)
await_completion(&mctl_ctl->sstat, 0x07, 0x01);
/* Set number of clks per micro-second */
- writel(DRAM_CLK_DEFAULT / 100, &mctl_ctl->togcnt1u);
+ writel(DRAM_CLK / 100, &mctl_ctl->togcnt1u);
/* Set number of clks per 100 nano-seconds */
- writel(DRAM_CLK_DEFAULT / 1000, &mctl_ctl->togcnt100n);
+ writel(DRAM_CLK / 1000, &mctl_ctl->togcnt100n);
/* Set memory timing registers */
writel(MCTL_TREFI, &mctl_ctl->trefi);
writel(MCTL_TMRD, &mctl_ctl->tmrd);
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 246cd9a..6162227 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -32,6 +32,23 @@ config MACH_SUN8I
endchoice
+if MACH_SUN6I
+
+config DRAM_CLK
+ int "sun6i dram clock speed"
+ default 312
+ ---help---
+ Set the dram clock speed, valid range 240 - 480, must be a multiple
+ of 24.
+
+config DRAM_ZQ
+ int "sun6i dram zq value"
+ default 123
+ ---help---
+ Set the dram zq value.
+
+endif
+
config SYS_CONFIG_NAME
string
default "sun4i" if MACH_SUN4I
diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig
index de78a01..9b4968f 100644
--- a/configs/Colombus_defconfig
+++ b/configs/Colombus_defconfig
@@ -5,3 +5,5 @@ CONFIG_USB_KEYBOARD=n
+S:CONFIG_ARCH_SUNXI=y
+S:CONFIG_MACH_SUN6I=y
+S:CONFIG_TARGET_COLOMBUS=y
++S:CONFIG_DRAM_CLK=288
++S:CONFIG_DRAM_ZQ=379
diff --git a/configs/Mele_M9_defconfig b/configs/Mele_M9_defconfig
index 40eabce..740b931 100644
--- a/configs/Mele_M9_defconfig
+++ b/configs/Mele_M9_defconfig
@@ -5,6 +5,8 @@ CONFIG_FDTFILE="sun6i-a31-m9.dtb"
+S:CONFIG_ARCH_SUNXI=y
+S:CONFIG_MACH_SUN6I=y
+S:CONFIG_TARGET_MELE_M9=y
++S:CONFIG_DRAM_CLK=312
++S:CONFIG_DRAM_ZQ=120
# Ethernet phy power
+S:CONFIG_AXP221_DLDO1_VOLT=3300
# USB hub power
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/5] sun6i: Make dram clk and zq value Kconfig options
It turns out that there is a too large spread between boards to handle this
with a default value, turn this into Kconfig options, and set the values
the factory images are using for the Colombus and Mele_M9 boards.
Note this changes the ZQ default when not overriden through defconfig from
120 to 123, as that is what most boards seem to actually use.
Signed-off-by: Hans de Goede
---
arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 12 +---
board/sunxi/Kconfig | 17 +
configs/Colombus_defconfig| 2 ++
configs/Mele_M9_defconfig | 2 ++
4 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
index 10a6241..30439dc 100644
--- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
+++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
@@ -17,9 +17,7 @@
#include
#include
-/* DRAM clk & zq defaults, maybe turn these into Kconfig options ? */
-#define DRAM_CLK_DEFAULT 31200
-#define DRAM_ZQ_DEFAULT 0x78
+#define DRAM_CLK (CONFIG_DRAM_CLK * 100)
struct dram_sun6i_para {
u8 bus_width;
@@ -48,7 +46,7 @@ static void mctl_sys_init(void)
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
const int dram_clk_div = 2;
- clock_set_pll5(DRAM_CLK_DEFAULT * dram_clk_div);
+ clock_set_pll5(DRAM_CLK * dram_clk_div);
clrsetbits_le32(&ccm->dram_clk_cfg, CCM_DRAMCLK_CFG_DIV0_MASK,
CCM_DRAMCLK_CFG_DIV0(dram_clk_div) | CCM_DRAMCLK_CFG_RST |
@@ -173,7 +171,7 @@ static void mctl_channel_init(int ch_index, struct
dram_sun6i_para *para)
await_completion(&mctl_phy->pgsr, 0x03, 0x03);
- writel(DRAM_ZQ_DEFAULT, &mctl_phy->zq0cr1);
+ writel(CONFIG_DRAM_ZQ, &mctl_phy->zq0cr1);
setbits_le32(&mctl_phy->pir, MCTL_PIR_CLEAR_STATUS);
writel(MCTL_PIR_STEP1, &mctl_phy->pir);
@@ -219,9 +217,9 @@ static void mctl_channel_init(int ch_index, struct
dram_sun6i_para *para)
await_completion(&mctl_ctl->sstat, 0x07, 0x01);
/* Set number of clks per micro-second */
- writel(DRAM_CLK_DEFAULT / 100, &mctl_ctl->togcnt1u);
+ writel(DRAM_CLK / 100, &mctl_ctl->togcnt1u);
/* Set number of clks per 100 nano-seconds */
- writel(DRAM_CLK_DEFAULT / 1000, &mctl_ctl->togcnt100n);
+ writel(DRAM_CLK / 1000, &mctl_ctl->togcnt100n);
/* Set memory timing registers */
writel(MCTL_TREFI, &mctl_ctl->trefi);
writel(MCTL_TMRD, &mctl_ctl->tmrd);
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 246cd9a..6162227 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -32,6 +32,23 @@ config MACH_SUN8I
endchoice
+if MACH_SUN6I
+
+config DRAM_CLK
+ int "sun6i dram clock speed"
+ default 312
+ ---help---
+ Set the dram clock speed, valid range 240 - 480, must be a multiple
+ of 24.
+
+config DRAM_ZQ
+ int "sun6i dram zq value"
+ default 123
+ ---help---
+ Set the dram zq value.
+
+endif
+
config SYS_CONFIG_NAME
string
default "sun4i" if MACH_SUN4I
diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig
index de78a01..9b4968f 100644
--- a/configs/Colombus_defconfig
+++ b/configs/Colombus_defconfig
@@ -5,3 +5,5 @@ CONFIG_USB_KEYBOARD=n
+S:CONFIG_ARCH_SUNXI=y
+S:CONFIG_MACH_SUN6I=y
+S:CONFIG_TARGET_COLOMBUS=y
++S:CONFIG_DRAM_CLK=288
++S:CONFIG_DRAM_ZQ=379
diff --git a/configs/Mele_M9_defconfig b/configs/Mele_M9_defconfig
index 40eabce..740b931 100644
--- a/configs/Mele_M9_defconfig
+++ b/configs/Mele_M9_defconfig
@@ -5,6 +5,8 @@ CONFIG_FDTFILE="sun6i-a31-m9.dtb"
+S:CONFIG_ARCH_SUNXI=y
+S:CONFIG_MACH_SUN6I=y
+S:CONFIG_TARGET_MELE_M9=y
++S:CONFIG_DRAM_CLK=312
++S:CONFIG_DRAM_ZQ=120
# Ethernet phy power
+S:CONFIG_AXP221_DLDO1_VOLT=3300
# USB hub power
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] dm: core: remove unnecessary return condition in driver lookup
On 17 November 2014 at 02:14, Simon Glass wrote: > On 17 November 2014 08:19, Masahiro Yamada wrote: >> The variable "drv" never becomes NULL because ll_entry_start() >> always returns a valid pointer even if there are no entries. >> >> The case "n_ents == 0" is covered by the following "for" loop. >> >> Signed-off-by: Masahiro Yamada > > Acked-by: Simon Glass Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cros_ec: Fix uninitialised variable in cros_ec.c
On 12 November 2014 at 02:06, Simon Glass wrote: > This fixes this cppcheck report: > > [drivers/misc/cros_ec.c:704]: (error) Uninitialized variable: req > > Signed-off-by: Simon Glass > Reported-by: Wolfgang Denk Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] dm: core: remove unnecessary return condition in uclass lookup
On 17 November 2014 at 10:16, Simon Glass wrote: > On 17 November 2014 08:19, Masahiro Yamada wrote: >> These conditions never happen. >> - There is no real uclass with UCLASS_INVALID id. >> - uclass never becomes NULL because ll_entry_start() always returns >>a valid pointer. >> >> Signed-off-by: Masahiro Yamada > > Yes we now use proper error codes to detect an invalid uclass, so it > is good to clean this up. > > Acked-by: Simon Glass Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] dm: core: remove meaningless if conditional
On 17 November 2014 at 19:23, Simon Glass wrote:
> Hi Masahiro,
>
> On 17 November 2014 11:19, Masahiro Yamada wrote:
>> Hi Simon,
>>
>>
>>
>> On Mon, 17 Nov 2014 09:14:15 +
>> Simon Glass wrote:
>>
>>> Hi Masahiro,
>>>
>>> On 17 November 2014 08:19, Masahiro Yamada
>>> wrote:
>>> > If the variable "ret" is equal to "-ENOENT", it is trapped at [1] and
>>> > never reaches [2]. At [3], the condition "ret != -ENOENT" is always
>>> > true.
>>> >
>>> > if (ret == -ENOENT) { <-- [1]
>>> > continue;
>>> > } else if (ret == -ENODEV) {
>>> > dm_dbg("Device '%s' has no compatible string\n", name);
>>> > break;
>>> > } else if (ret) { <-- [2]
>>> > dm_warn("Device tree error at offset %d\n", offset);
>>> > if (!result || ret != -ENOENT) <-- [3]
>>> > result = ret;
>>> > break;
>>> > }
>>> >
>>> > Signed-off-by: Masahiro Yamada
>>> > ---
>>> >
>>> > drivers/core/lists.c | 3 +--
>>> > 1 file changed, 1 insertion(+), 2 deletions(-)
>>> >
>>> > diff --git a/drivers/core/lists.c b/drivers/core/lists.c
>>> > index 3a1ea85..0aad56d 100644
>>> > --- a/drivers/core/lists.c
>>> > +++ b/drivers/core/lists.c
>>> > @@ -136,8 +136,7 @@ int lists_bind_fdt(struct udevice *parent, const void
>>> > *blob, int offset,
>>> > break;
>>> > } else if (ret) {
>>> > dm_warn("Device tree error at offset %d\n",
>>> > offset);
>>> > - if (!result || ret != -ENOENT)
>>> > - result = ret;
>>> > + result = ret;
>>>
>>> Thanks for the clear explanation.
>>> It looks good, except my intent was to return the first error, hence
>>> the 'if (!result ...'.
>>>
>>> Your code will return the last error. Can we preserve the current bahaviour?
>>
>>
>> Do you mean, like this?
>>
>>dm_warn("Device tree error at offset %d\n", offset);
>>if (!result)
>>result = ret;
>>break;
>>
>>
>> I think there is no difference in the behaviour, because
>> this "for" loop is escaped out at the first encounter with an error
>> except -ENOENT.
>>
>> Here is the only line to set "result" and it is followed by "break"
>> statement,
>> so the last error is also the first error, I think.
>
> Ah yes, OK. The intent here is to provide a useful error message
> without adding a lot of noise. It's a bit of a pain but we should keep
> it I think. Your patch looks good.
>
> Acked-by: Simon Glass
Applied to u-boot-dm.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] dm: core: a trivial clean up
On 17 November 2014 at 10:08, Simon Glass wrote: > On 17 November 2014 08:19, Masahiro Yamada wrote: >> Signed-off-by: Masahiro Yamada > > Acked-by: Simon Glass Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/17] dm: spi: Use device_bind_driver() instead of our own function
On 17 November 2014 at 07:29, Heiko Schocher wrote: > Hello Simon, > > Am 11.11.2014 18:46, schrieb Simon Glass: >> >> The SPI function does the same thing, so we may as well just use the new >> generic function. The 'cs' parameter was not actually used, so can be >> dropped. >> >> Signed-off-by: Simon Glass >> --- >> >> Changes in v2: >> - Add new patches to adjust SPI to use device_bind_driver() >> >> drivers/mtd/spi/sandbox.c | 2 +- >> drivers/spi/spi-uclass.c | 23 +-- >> include/spi.h | 14 -- >> 3 files changed, 2 insertions(+), 37 deletions(-) > > > Acked-by: Heiko Schocher Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/17] dm: spi: Correct handling of SPI chip selects in sandbox
On 17 November 2014 at 07:29, Heiko Schocher wrote: > Hello Simon, > > Am 11.11.2014 18:46, schrieb Simon Glass: >> >> This code was not updated when the chip select handling was adjusted. Fix >> it to call the correct function. >> >> Signed-off-by: Simon Glass >> --- >> >> Changes in v2: None >> >> drivers/mtd/spi/sandbox.c | 2 +- >> drivers/spi/spi-uclass.c | 11 +-- >> include/spi.h | 10 ++ >> 3 files changed, 12 insertions(+), 11 deletions(-) > > > Acked-by: Heiko Schocher Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/17] dm: Add a function to bind a device by driver name
On 17 November 2014 at 07:29, Heiko Schocher wrote: > Hello Simon, > > Am 11.11.2014 18:46, schrieb Simon Glass: >> >> In some cases we need to manually bind a device to a particular driver. >> Add a function to do this. >> >> Signed-off-by: Simon Glass >> --- >> >> Changes in v2: >> - Add new patch to add a function to bind a device by driver name >> >> drivers/core/lists.c | 21 + >> include/dm/lists.h | 13 + >> 2 files changed, 34 insertions(+) > > > Acked-by: Heiko Schocher Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/17] dm: fdt: Correct handling of aliases with embedded digits
On 17 November 2014 at 19:32, Tom Rini wrote: > On Mon, Nov 17, 2014 at 05:57:43AM +, Simon Glass wrote: >> Hi Tom, >> >> On 17 November 2014 00:46, Tom Rini wrote: >> > >> > On Tue, Nov 11, 2014 at 10:46:20AM -0700, Simon Glass wrote: >> > >> > > Since we scan from left to right looking for the first digit, "i2c0" >> > > returns >> > > 2 instead of 0 for the alias number. Adjust the code to scan from right >> > > to >> > > left instead. >> > > >> > > Signed-off-by: Simon Glass >> > >> > How about i2c10 ? I assume you see where I'm worried about here.. >> >> It goes back to the first non-digit, so will produce 10 in this case >> as expected. > > Oh good. > > Reviewed-by: Tom Rini Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/17] dm: core: Add functions to find parent and OF data
On 19 November 2014 at 02:37, Simon Glass wrote:
> Hi Masahiro,
>
> On 19 November 2014 08:27, Masahiro Yamada wrote:
>>
>> On Tue, 11 Nov 2014 10:46:19 -0700
>> Simon Glass wrote:
>>
>>> Add dev_get_parent() as a convenience to obtain the parent of a device.
>>>
>>> Signed-off-by: Simon Glass
>>> ---
>>>
>>> Changes in v2: None
>>>
>>> drivers/core/device.c | 5 +
>>> include/dm/device.h | 8
>>> 2 files changed, 13 insertions(+)
>>>
>>> diff --git a/drivers/core/device.c b/drivers/core/device.c
>>> index 0d84776..76b29fd 100644
>>> --- a/drivers/core/device.c
>>> +++ b/drivers/core/device.c
>>> @@ -549,6 +549,11 @@ int device_find_next_child(struct udevice **devp)
>>> return 0;
>>> }
>>>
>>> +struct udevice *dev_get_parent(struct udevice *child)
>>> +{
>>> + return child->parent;
>>> +}
>>> +
>>
>> Why do you want this? "dev_get_parent(dev)" is longer than "dev->parent".
>>
>> I am not sure if this helper function is useful,
>> but if really necessary, static inline or macro ??
>
> See my comment on the other patch.
>
>>
>>
>> Perhaps, "struct udevice *dev" rather than "struct udevice *child"
>> for consistency?
>
> Maybe, but I feel this is clearer even if it is inconsistent. I try to
> use 'bus' instead of dev when there is a bus too, to help with
> understanding.
>
> Regards,
> Simon
Applied to u-boot-dm.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/17] dm: core: Allow access to the device's driver_id data
On 20 November 2014 at 19:39, Simon Glass wrote:
> Hi Masahiro,
>
> On 20 November 2014 06:06, Masahiro Yamada wrote:
>> Hi Simon,
>>
>>
>>
>>
>> On Wed, 19 Nov 2014 09:35:54 +
>> Simon Glass wrote:
>>
>>> Hi Masahiro,
>>>
>>> On 19 November 2014 08:25, Masahiro Yamada
>>> wrote:
>>> > Hi Simon,
>>> >
>>> >
>>> >
>>> > On Tue, 11 Nov 2014 10:46:18 -0700
>>> > Simon Glass wrote:
>>> >
>>> >> diff --git a/drivers/core/device.c b/drivers/core/device.c
>>> >> index 49faa29..0d84776 100644
>>> >> --- a/drivers/core/device.c
>>> >> +++ b/drivers/core/device.c
>>> >> @@ -548,3 +548,8 @@ int device_find_next_child(struct udevice **devp)
>>> >>
>>> >> return 0;
>>> >> }
>>> >> +
>>> >> +ulong dev_get_of_data(struct udevice *dev)
>>> >> +{
>>> >> + return dev->of_id->data;
>>> >> +}
>>> >
>>> >
>>> > Since this function is short enough, perhaps you might want to
>>> > define it as "static inline" in the header file include/dm/device.h
>>> >
>>> >
>>>
>>> Thanks for looking at this series.
>>>
>>> The background here is that I'm quite worried about all the pointers
>>> in driver model. It might be quite easy to use the wrong one and get
>>> confused.
>>
>> Me too.
>>
>>> So my plan is to add code to check that the pointers are
>>> what we think they are, like:
>>>
>>>DM_CHECK_PTR(dev, "udevice");
>>>
>>> or similar. Then that code would compile to nothing unless it is
>>> enabled with a CONFIG_DM_CHECK_PTRS or whatever. That's the reason for
>>> accessors.
>>>
>>
>> Sounds good!
>>
>>
>>> >
>>> >> @@ -116,6 +120,7 @@ int lists_bind_fdt(struct udevice *parent, const
>>> >> void *blob, int offset,
>>> >> {
>>> >> struct driver *driver = ll_entry_start(struct driver, driver);
>>> >> const int n_ents = ll_entry_count(struct driver, driver);
>>> >> + const struct udevice_id *id;
>>> >> struct driver *entry;
>>> >> struct udevice *dev;
>>> >> bool found = false;
>>> >> @@ -127,7 +132,8 @@ int lists_bind_fdt(struct udevice *parent, const
>>> >> void *blob, int offset,
>>> >> if (devp)
>>> >> *devp = NULL;
>>> >> for (entry = driver; entry != driver + n_ents; entry++) {
>>> >> - ret = driver_check_compatible(blob, offset,
>>> >> entry->of_match);
>>> >> + ret = driver_check_compatible(blob, offset,
>>> >> entry->of_match,
>>> >> + &id);
>>> >> name = fdt_get_name(blob, offset, NULL);
>>> >> if (ret == -ENOENT) {
>>> >> continue;
>>> >> @@ -147,6 +153,7 @@ int lists_bind_fdt(struct udevice *parent, const
>>> >> void *blob, int offset,
>>> >> dm_warn("Error binding driver '%s'\n",
>>> >> entry->name);
>>> >> return ret;
>>> >> } else {
>>> >> + dev->of_id = id;
>>> >
>>> >
>>> > Instead of all the chages above, only one line change,
>>> >
>>> > dev->of_id = entry->of_match
>>> >
>>> >
>>> >
>>> > Does this work for you?
>>> >
>>> >
>>>
>>> entry->of_match is the first element in an array of records. I want to
>>> know exactly which one matches, so I can't just use the first one.
>>>
>>
>>
>> Sorry, it was my misunderstanding.
>> Thanks for explaining this.
>>
>>
>>
>> Could you update the comment block of driver_check_compatible?
>
> OK
>
>>
>>
>>
>> /**
>> * driver_check_compatible() - Check if a driver is compatible with this node
>> *
>> * @param blob: Device tree pointer
>> * @param offset: Offset of node in device tree
>> * @param of_matchL List of compatible strings to match
>> * @return 0 if there is a match, -ENOENT if no match, -ENODEV if the node
>> * does not have a compatible string, other error <0 if there is a device
>> * tree error
>> */
>>
>>
>> - Add description of "@param of_idp"
>> - Fix "of_matchL" -> "of_match"
>
> Will fix.
Fixed these and:
Applied to u-boot-dm.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/17] dm: i2c: Move error reporting into a common function
On 17 November 2014 at 07:27, Heiko Schocher wrote: > Hello Simon, > > Am 11.11.2014 18:46, schrieb Simon Glass: >> >> Factor out the common code to make it easier to adjust it. >> >> Signed-off-by: Simon Glass >> --- >> >> Changes in v2: >> - Add a suitable commit message >> >> common/cmd_i2c.c | 32 ++-- >> 1 file changed, 22 insertions(+), 10 deletions(-) > > > Acked-by: Heiko Schocher Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 14/14] dm: Update documentation to include CONFIG_DM... options
On 11 November 2014 at 01:16, Simon Glass wrote: > Add documentation for the various driver model options that are now > available. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Rebase to master > > Changes in v2: > - Rebase to master > > README | 119 > > doc/driver-model/README.txt | 44 > 2 files changed, 153 insertions(+), 10 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/14] dm: arm: spl: Make driver model linker lists available
On 11 November 2014 at 01:16, Simon Glass wrote: > The linker lists feature is useful in SPL as it holds the driver model > platform data. So don't throw away the lists. > > Signed-off-by: Simon Glass > Reviewed-by: Tom Rini > --- > > Changes in v3: None > Changes in v2: None > > arch/arm/cpu/u-boot-spl.lds | 7 +++ > 1 file changed, 7 insertions(+) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/14] dm: tegra: Add platform data for the SPL uart
On 11 November 2014 at 01:16, Simon Glass wrote: > Since we currently don't have device tree available in SPL, add platform > data so the uart works. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > drivers/serial/serial_tegra.c | 16 > 1 file changed, 16 insertions(+) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/14] dm: tegra: Add platform data for the GPIO driver
On 11 November 2014 at 01:16, Simon Glass wrote: > Add platform data for the GPIO driver. It doesn't need to contain anything > since the GPIO driver will actually use information from the CONFIGs for > now. This merely serves to ensure that the GPIO driver is bound. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/14] dm: Disable dm_warn() in SPL
On 11 November 2014 at 01:16, Simon Glass wrote: > Since this function can use up quite a bit of space for its strings, disable > it by default in SPL. Use CONFIG_DM_WARN to re-enable it. > > Signed-off-by: Simon Glass > Reviewed-by: Tom Rini > --- > > Changes in v3: None > Changes in v2: None > > include/config_defaults.h | 1 + > include/dm/util.h | 6 ++ > 2 files changed, 7 insertions(+) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/14] dm: Allow stdio registration to be dropped
On 11 November 2014 at 01:16, Simon Glass wrote: > Provide a CONFIG_DM_STDIO option to enable registering a serial device > with the stdio library. This is seldom useful in SPL, so disable it by > default when building for SPL. > > Signed-off-by: Simon Glass > Reviewed-by: Tom Rini > --- > > Changes in v3: > - Add #ifdef around serial_stub_puts() to fix error when building SPL > > Changes in v2: None > > drivers/serial/serial-uclass.c | 10 +++--- > include/config_defaults.h | 1 + > 2 files changed, 8 insertions(+), 3 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/14] dm: spl: Allow driver model to be used
On 11 November 2014 at 01:16, Simon Glass wrote: > When enabled, set up driver model for SPL. This allows SPL to use the same > drivers as the main U-Boot. > > Signed-off-by: Simon Glass > Acked-by: Tom Rini > --- > > Changes in v3: None > Changes in v2: None > > common/spl/spl.c | 5 + > scripts/Makefile.spl | 1 + > 2 files changed, 6 insertions(+) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/14] dm: spl: Make simple malloc() available when enabled
On 10 November 2014 at 17:16, Simon Glass wrote: > Set up the simple malloc() implementation when requested, in preference to > the full malloc(). > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > common/spl/spl.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/14] dm: arm: spl: Allow simple malloc() in SPL
On 11 November 2014 at 01:16, Simon Glass wrote: > For SPL it is sometimes useful to have a simple malloc() just to permit > driver model to work, in the cases where the full malloc() is not made > available by the board config. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > arch/arm/lib/crt0.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/14] dm: Split the simple malloc() implementation into its own file
On 11 November 2014 at 01:16, Simon Glass wrote: > The simple malloc() implementation is used when memory is tight. It provides > a simple buffer with an incrementing pointer. > > At present the implementation is inside dlmalloc. Move it into its own file > so that it is easier to find. > > Rather than using relocation as a signal that the full malloc() is > available, add a special GD_FLG_FULL_MALLOC_INIT flag. This signals that the > simple malloc() should no longer be used. > > In some cases, such as SPL, even the code space used by the full malloc() is > wasteful. Add a CONFIG_SYS_MALLOC_SIMPLE option to provide only the simple > malloc. In this case the full malloc is not available at all. It saves about > 1KB of code space and about 0.5KB of data on Thumb 2. > > Acked-by: Tom Rini > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: > - Correct the Makefile condition for simple_malloc > > common/Makefile | 3 ++ > common/board_r.c | 3 +- > common/dlmalloc.c | 19 - > common/malloc_simple.c| 39 + > include/asm-generic/global_data.h | 1 + > include/malloc.h | 60 > --- > 6 files changed, 87 insertions(+), 38 deletions(-) > create mode 100644 common/malloc_simple.c Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/9] dm: at91: Add myself as maintainer for snapper9260
On 29 October 2014 at 20:09, Simon Glass wrote: > The old maintainer has left, so take this over. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add new patch to add myself as maintainer for snapper9260 > > board/bluewater/snapper9260/MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/14] dm: tegra: Avoid using arch-specific memcpy() in SPL
On 11 November 2014 at 01:16, Simon Glass wrote: > The faster functions are not actually available in SPL and the code size > likely isn't worth it. Use the normal memcpy() in SPL. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Add new patch to avoid using arch-specific memcpy() in SPL > > Changes in v2: None > > include/configs/tegra-common.h | 2 ++ > 1 file changed, 2 insertions(+) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 9/9] dm: serial: Support changing the baud rate
On 29 October 2014 at 20:09, Simon Glass wrote: > Implement this feature in the uclass so that the baudrate can be changed > with 'setenv baudrate '. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add a patch to implement baud rate changes > > drivers/serial/serial-uclass.c | 67 > ++ > 1 file changed, 67 insertions(+) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/9] dm: at91: Refactor serial driver slightly for driver model
On 29 October 2014 at 20:08, Simon Glass wrote: > Before adding driver model support, split out a few of the functions so > that they can be used by the driver model code. > > Signed-off-by: Simon Glass > Acked-by: Andreas Bießmann > --- > > Changes in v2: None > > drivers/serial/atmel_usart.c | 32 +++- > 1 file changed, 23 insertions(+), 9 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/9] dm: at91: Convert snapper9260 to use driver model
On 5 November 2014 at 03:54, Simon Glass wrote: > Hi Masahiro, > > On 1 November 2014 10:27, Masahiro YAMADA wrote: >> Hi Simon, >> >> 2014-10-30 4:09 GMT+09:00 Simon Glass : >>> diff --git a/include/configs/snapper9260.h b/include/configs/snapper9260.h >>> index e2e623e..942af2e 100644 >>> --- a/include/configs/snapper9260.h >>> +++ b/include/configs/snapper9260.h >>> @@ -21,6 +21,11 @@ >>> #define CONFIG_SYS_AT91_MAIN_CLOCK 18432000 /* External Crystal, in Hz >>> */ >>> #define CONFIG_SYS_AT91_SLOW_CLOCK 32768 >>> #define CONFIG_SYS_GENERIC_BOARD >>> +#define CONFIG_DM >>> +#define CONFIG_CMD_DM >>> +#define CONFIG_DM_GPIO >>> +#define CONFIG_DM_SERIAL >>> +#define CONFIG_SYS_MALLOC_F_LEN(1 << 10) >>> >> >> >> >> CONFIG_DM, CONFIG_DM_GPIO, CONFIG_DM_SERIAL are available in Kconfig. >> Could you add them into the defconfig, please? > > Yes I need to do a full pass through all the boards I've added. > Hopefully next week. Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/9] dm: at91: Add driver model support for atmel GPIO driver
On 29 October 2014 at 20:08, Simon Glass wrote: > Modify this driver to support driver model, with platform data required to > determine the GPIOs that it controls. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Remove unnecessary port number check > - Use GPIO_PER_BANK instead of 32 in more places > > arch/arm/include/asm/arch-at91/gpio.h | 6 + > drivers/gpio/at91_gpio.c | 241 > ++ > 2 files changed, 193 insertions(+), 54 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/9] dm: at91: Add driver model support for the serial driver
On 29 October 2014 at 20:09, Simon Glass wrote: > Add driver model support while retaining the existing legacy code. This > allows the driver to support boards that have converted to driver model > as well as those that have not. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Rename header to atmel_serial.h and use atmel instead of at91 throughout > > arch/arm/include/asm/arch-at91/atmel_serial.h | 15 + > drivers/serial/atmel_usart.c | 84 > +++ > 2 files changed, 99 insertions(+) > create mode 100644 arch/arm/include/asm/arch-at91/atmel_serial.h Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/9] dm: at91: Add platform data for GPIO on at91sam9260-based boards
On 29 October 2014 at 20:08, Simon Glass wrote: > These boards all have the same GPIO arrangement, so add some common platform > data that can be used by all boards. Remove the configs which are no longer > required. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Use PA/PB/PC instead of A/B/C for GPIO port names > > arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c | 14 ++ > arch/arm/include/asm/arch-at91/at91sam9260.h | 4 +++- > 2 files changed, 17 insertions(+), 1 deletion(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] dm: at91: Correct text base for snapper9260
On 29 October 2014 at 20:08, Simon Glass wrote: > > The value should be 0x21f0. Fix it. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Use a text base of 0x21f0 > > include/configs/snapper9260.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/9] dm: at91: Move snapper9260 to generic baord
On 29 October 2014 at 20:08, Simon Glass wrote: > This works correctly, so switch it over before the deadline. > > Signed-off-by: Simon Glass > --- > > Changes in v2: None > > include/configs/snapper9260.h | 1 + > 1 file changed, 1 insertion(+) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
On Fri, Nov 21, 2014 at 11:28:25PM +0100, Simon Glass wrote: > Hi Masahiro, > > On 21 November 2014 09:29, Masahiro Yamada wrote: > > Hi Simon, Tom, > > > > > > > > On Fri, 21 Nov 2014 08:24:54 +0100 > > Simon Glass wrote: > > > >> Hi Masahiro, > >> > >> On 21 November 2014 08:11, Masahiro Yamada > >> wrote: > >> > Simon, > >> > > >> > On Fri, 21 Nov 2014 08:00:27 +0100 > >> > Simon Glass wrote: > >> > > >> >> Hi Tom, > >> >> > >> >> Here's the introduction of bare x86 support. > >> >> > >> >> > >> >> The following changes since commit > >> >> 4d70b34d7f721d8b1d4d628e68c3a44ab7a10dff: > >> >> > >> >> Merge branch 'master' of git://git.denx.de/u-boot-ubi (2014-11-19 > >> >> 23:18:29 -0500) > >> >> > >> >> are available in the git repository at: > >> >> > >> >> git://git.denx.de/u-boot-x86.git > >> >> > >> >> for you to fetch changes up to fe5b9b447c6eea3873833b1f3ba15c9854aa2ef8: > >> >> > >> >> x86: Rename chromebook-x86 to coreboot (2014-11-21 07:34:16 +0100) > >> >> > >> >> > >> >> Bin Meng (4): > >> >> x86: Do CPU identification in the early phase > >> >> x86: Do TSC MSR calibration only for known/supported CPUs > >> >> x86: Add quick TSC calibration via PIT > >> >> x86: Save TSC frequency in the global data > >> >> > >> >> Masahiro Yamada (1): > >> >> x86: use CONFIG_SYS_COREBOOT to descend into coreboot/ directory > >> > > >> > > >> > Wait, this patch was posted as a series. > >> > > >> > It should not be applied without the others in my series. > >> > What is going on? > >> > >> I applied this to x86 a while back - it actually was the same as a > >> patch I had locally so I picked up yours instead. It works fine on x86 > >> and I think it is independent of the series. > >> > >> So I know this is a bit unusual but I think it is OK. > > > > > > Understood, but I am a bit unhappy because > > - The subject "x86: use CONFIG_SYS_COREBOOT to descend into coreboot/ > > directory" > > is totally unrelated to the actual code > > - The first hunk was lost of my original patch, so I have to resend my > > series > > to get it back. > > > > > > Tom, if possible, after you pull this, can you rephrase the commit subject > > locally? > > For ex. > > > >"x86: use CONFIG_SYS_COREBOOT to descend into coreboot/ directory" > > > >-> > > > > "x86: remove redundant CONFIG_SYS_COREBOOT references" > > > > > > > > I will resend my series lator... > > Ah sorry, I'm not sure what went wrong but it looks like I dropped a piece. > > Tom, if you haven't already applied it, I'll drop this patch and > resend the pull request next week. So this PR is OK because I've already locally applied the whole series from Masahiro and have been doing some build/fix cycles on it all (that series wasn't problematic but the min/max update needed a few cycles to get all the edges right). -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: correct Mele M9 Vbus gpio settings
On Sun, 2014-11-23 at 12:42 +0100, Hans de Goede wrote: > I noticed that the kernel and u-boot settings were different, double checking > has confirmed that the kernel settings are correct. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell > --- > configs/Mele_M9_defconfig | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/configs/Mele_M9_defconfig b/configs/Mele_M9_defconfig > index 6f466ca..a598254 100644 > --- a/configs/Mele_M9_defconfig > +++ b/configs/Mele_M9_defconfig > @@ -16,5 +16,7 @@ CONFIG_FDTFILE="sun6i-a31-m9.dtb" > # HDMI power ? > +S:CONFIG_AXP221_ALDO2_VOLT=1800 > +S:CONFIG_AXP221_ALDO3_VOLT=3000 > -# No Vbus gpio for usb1 > -+S:CONFIG_USB1_VBUS_PIN="" > +# Vbus gpio for usb1 > ++S:CONFIG_USB1_VBUS_PIN="PC27" > +# No Vbus gpio for usb2 > ++S:CONFIG_USB2_VBUS_PIN="" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/17] dm: i2c: Add a uclass for I2C
Hello Simon, On Fri, 21 Nov 2014 23:29:53 +0100, Simon Glass wrote: > > Do you mean you implemented the same (similar) behavior as the legacy I2C > > framework? > > Yes, we need the ability to scan the bus and find which devices are present. Side note: not sure this was touched on, and not sure what the implications are, but let me just mention that some SPLs need this ability too (this causes SPL to grow, which is probably the reason that some ARM boards failed to build once the i2c linker lists were added to the SPL lds file and until some other feature was removed). Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB Host not enumerating properly on AM335x-based board
Hello Anatolij, On Sat, 22 Nov 2014 00:40:58 +0100, Anatolij Gustschin wrote: > Hi Maxime, > > On Thu, 20 Nov 2014 17:49:17 +0100 > Maxime Ripard wrote: > > > Hi, > > > > I'm currently working on 2014.07, on a custom TI AM335x based board. > > > > Everything works great so far, except when we're trying to have USB > > host working. > > > > The board has the MUSB1 controller wired as USB Host only, with the > > following configuration: > > > > #define CONFIG_USB_MUSB_DSPS > > #define CONFIG_ARCH_MISC_INIT > > #define CONFIG_MUSB_PIO_ONLY > > #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT > > #define CONFIG_MUSB_HOST > > #define CONFIG_MUSB_DSPS > > #define CONFIG_AM335X_USB1 > > #define CONFIG_AM335X_USB1_MODE MUSB_HOST > > > > #ifdef CONFIG_MUSB_HOST > > #define CONFIG_CMD_USB > > #define CONFIG_USB_STORAGE > > #define CONFIG_USB_HOST_ETHER > > #define CONFIG_USB_ETHER_ASIX > > #endif > > I'm not familiar with AM335x, so I can't say if this configuration > is okay. > > > Whenever we try to scan the USB controller and that a device is > > attached, we get the following output: > > > > U-Boot# usb start > > (Re)start USB... > > USB0: scanning bus 0 for devices... 1 USB Device(s) found > >scanning usb for storage devices... 0 Storage Device(s) found > >scanning usb for ethernet devices... 0 Ethernet Device(s) found > > > > The device itself being a USB key, it's somewhat odd that it > > enumerates the device, but doesn't find the storage device... > > The device found is the controller's root hub device, not the > USB storage device. "usb info" should show more about it. > > > The same USB port with the same device works fine under Linux. > > > > The VBUS pin is still up after running the command, so it's not really > > a matter of power being shut down on the bus. > > > > I'm kind of running out of idea on what to test next. The differences > > between u-boot's musb-new and Linux' own musb driver seems thin and to > > make sense, so I don't think the driver itself is to blame. > > > > Anyone experienced such a thing? > > We experienced similar thing this week, but on an imx6dl based board. > Quite a lot of debugging and comparison with USB host operation under > Linux didn't really help much. Finally we found the issue with the > timer implementation, udelay(1) took too much time, about 35 usec. > Whereas one would expect it to take about 1 usec, ideally. > EHCI-HCD, USB-Hub and Storage drivers in U-Boot use udelay()/mdelay() > quite extensively. Reworking the timer implementation for our > platform resulted in udelay(1) times taking about 2.5 usec. This was > enough for USB driver code to work again. I think the USB code might be mis-using udelay(), then. Here's why I do: - the semantics of udelay(n) are AFAIUI "delay at least n microseconds", but nothing says it won't delay more, especially for small wait times where the setup/cleanup part of udelay() will obviously get a bigger share of the execution time than the actual delaying. - OTOH, the problems you witness seem to imply that the USB code is expecting udelay(n) to "wait for at least n microseconds but no more than some unspecified limit", since if udelay /does/ take too long, the code fails because its expectation is not met. Did you find out why a longer delay() causes the USB code to fail? For instance, is udelay() used for synchronizing to an external event, and delaying too much makes the code miss the event? > HTH, > > Anatolij Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] sunxi: Avoid usb getting scanned twice when using usb kbd + usb boot
Use the new BOOTENV_PREBOOT_INITS_USB define to avoid usb being scanned twice when using usb kbd + usb boot. Signed-off-by: Hans de Goede --- include/configs/sunxi-common.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 3f890b2..7b958f8 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -302,12 +302,11 @@ func(PXE, pxe, na) \ func(DHCP, dhcp, na) -#include - #ifdef CONFIG_USB_KEYBOARD #define CONSOLE_STDIN_SETTINGS \ "preboot=usb start\0" \ "stdin=serial,usbkbd\0" +#define BOOTENV_PREBOOT_INITS_USB #else #define CONSOLE_STDIN_SETTINGS \ "stdin=serial\0" @@ -327,6 +326,8 @@ CONSOLE_STDIN_SETTINGS \ CONSOLE_STDOUT_SETTINGS +#include + #define CONFIG_EXTRA_ENV_SETTINGS \ CONSOLE_ENV_SETTINGS \ MEM_LAYOUT_ENV_SETTINGS \ -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sunxi: correct Mele M9 Vbus gpio settings
I noticed that the kernel and u-boot settings were different, double checking has confirmed that the kernel settings are correct. Signed-off-by: Hans de Goede --- configs/Mele_M9_defconfig | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/configs/Mele_M9_defconfig b/configs/Mele_M9_defconfig index 6f466ca..a598254 100644 --- a/configs/Mele_M9_defconfig +++ b/configs/Mele_M9_defconfig @@ -16,5 +16,7 @@ CONFIG_FDTFILE="sun6i-a31-m9.dtb" # HDMI power ? +S:CONFIG_AXP221_ALDO2_VOLT=1800 +S:CONFIG_AXP221_ALDO3_VOLT=3000 -# No Vbus gpio for usb1 -+S:CONFIG_USB1_VBUS_PIN="" +# Vbus gpio for usb1 ++S:CONFIG_USB1_VBUS_PIN="PC27" +# No Vbus gpio for usb2 ++S:CONFIG_USB2_VBUS_PIN="" -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] config_distro_bootcmd.h: Allow user to indicate that usb is inited in preboot
When using usb-keyboard support, typically usb will already get started from
preboot. In this case doing it again in the bootcmd is undesirable.
Allow the user of config_distro_bootcmd to indicate that usb is inited in
preboot through the user setting BOOTENV_PREBOOT_INITS_USB.
Signed-off-by: Hans de Goede
---
include/config_distro_bootcmd.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index be616e8..fd01a34 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -91,7 +91,11 @@
#ifdef CONFIG_CMD_USB
#define BOOTENV_RUN_USB_INIT "run usb_init; "
+#ifndef BOOTENV_PREBOOT_INITS_USB
#define BOOTENV_SET_USB_NEED_INIT "setenv usb_need_init; "
+#else
+#define BOOTENV_SET_USB_NEED_INIT "setenv usb_need_init false; "
+#endif
#define BOOTENV_SHARED_USB \
"usb_init=" \
"if ${usb_need_init}; then " \
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Use "usb start" rather then "run usb_init" for preboot with usb-kbd
On Sun, 2014-11-23 at 12:14 +0100, Hans de Goede wrote: > In an effort to avoid usb getting scanned twice when using an usb keyboard, > and booting from usb, I've set preboot to "run usb_init" in the > CONFIG_USB_KEYBOARD patch. > > This is wrong however, as it causes usb to not be scanned (and the keyboard to > not be found) if an "env save" is done, since then the env > contains usb_need_init=false. > > This commit fixes this by changing the preboot value to "usb start", so that > usb gets scanned for a keyboard unconditionally when usb-keyboard support is > enabled. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell > --- > include/configs/sunxi-common.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h > index fcaa249..3f890b2 100644 > --- a/include/configs/sunxi-common.h > +++ b/include/configs/sunxi-common.h > @@ -306,7 +306,7 @@ > > #ifdef CONFIG_USB_KEYBOARD > #define CONSOLE_STDIN_SETTINGS \ > - "preboot=run usb_init\0" \ > + "preboot=usb start\0" \ > "stdin=serial,usbkbd\0" > #else > #define CONSOLE_STDIN_SETTINGS \ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sunxi: Use "usb start" rather then "run usb_init" for preboot with usb-kbd
In an effort to avoid usb getting scanned twice when using an usb keyboard, and booting from usb, I've set preboot to "run usb_init" in the CONFIG_USB_KEYBOARD patch. This is wrong however, as it causes usb to not be scanned (and the keyboard to not be found) if an "env save" is done, since then the env contains usb_need_init=false. This commit fixes this by changing the preboot value to "usb start", so that usb gets scanned for a keyboard unconditionally when usb-keyboard support is enabled. Signed-off-by: Hans de Goede --- include/configs/sunxi-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index fcaa249..3f890b2 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -306,7 +306,7 @@ #ifdef CONFIG_USB_KEYBOARD #define CONSOLE_STDIN_SETTINGS \ - "preboot=run usb_init\0" \ + "preboot=usb start\0" \ "stdin=serial,usbkbd\0" #else #define CONSOLE_STDIN_SETTINGS \ -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] config_distro_bootcmd: Avoid scanning usb twice (under some circumstances)
Hi,
On 11/20/2014 07:59 PM, Hans de Goede wrote:
> When using usb-keyboard support, the preboot env variable must be set to a
> command to scan usb, so that the keyboard is available to interrupt autoboot.
>
> The logical command to add when using config_distro_bootcmd.h is
> "run usb_init", as that does a "setenv usb_need_init false" which should avoid
> a second scan when booting from usb.
>
> However this does not work because config_distro_bootcmd sets
> bootcmd to "setenv usb_need_init; ...".
>
> This is not necessary "if ${usb_need_init}" will evaluate to true just as well
> if usb_need_init is not set at all. So drop the BOOTENV_SET_USB_NEED_INIT
> macro and calling of it, thereby fixing the double usb-scan.
>
> While at it do the same for scsi_need_init which was modelled after the usb
> code.
Self-NAK, this breaks things after an "env save" command, as then the env
saved will contain usb_need_init=false, and usb will no longer get scanned.
I'll look into a different fix.
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
