[U-Boot] [PATCH] dm: ls1021a: Bring in ls1021a dts files from linux kernel
From: haikun haikun.w...@freescale.com
Bring in device tree files for ls1021a from linux V3.19.
In order to use it in u-boot, make some changes:
1. remove 'gic' node and interrupt related properties in every node.
2. remove 'clockgen' node and clock related properties in every node.
3. change address-cells and size-cells of root node and 'soc' node
from 2 to 1.
4. Add quadspi node.
Signed-off-by: Haikun Wang haikun.w...@freescale.com
---
arch/arm/dts/Makefile| 3 +
arch/arm/dts/ls1021a-qds.dts | 47
arch/arm/dts/ls1021a-twr.dts | 31 +
arch/arm/dts/ls1021a.dtsi| 265 +++
4 files changed, 346 insertions(+)
create mode 100644 arch/arm/dts/ls1021a-qds.dts
create mode 100644 arch/arm/dts/ls1021a-twr.dts
create mode 100644 arch/arm/dts/ls1021a.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cbe5b86..67b821a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -54,6 +54,9 @@ dtb-$(CONFIG_SOCFPGA) += \
socfpga_cyclone5_socdk.dtb \
socfpga_cyclone5_socrates.dtb
+dtb-$(CONFIG_TARGET_LS1021AQDS) += ls1021a-qds.dtb
+dtb-$(CONFIG_TARGET_LS1021ATWR) += ls1021a-twr.dtb
+
targets += $(dtb-y)
DTC_FLAGS += -R 4 -p 0x1000
diff --git a/arch/arm/dts/ls1021a-qds.dts b/arch/arm/dts/ls1021a-qds.dts
new file mode 100644
index 000..9a06695
--- /dev/null
+++ b/arch/arm/dts/ls1021a-qds.dts
@@ -0,0 +1,47 @@
+/*
+ * Freescale ls1021a QDS board device tree source
+ *
+ * Copyright 2013-2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+#include ls1021a.dtsi
+
+/ {
+ model = LS1021A QDS Board;
+
+ aliases {
+ spi0 = qspi;
+ spi1 = dspi0;
+ };
+};
+
+dspi0 {
+ bus-num = 0;
+ status = okay;
+
+ dspiflash: at45db021d@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = spi-flash;
+ spi-max-frequency = 1600;
+ spi-cpol;
+ spi-cpha;
+ reg = 0;
+ };
+};
+
+qspi {
+ bus-num = 0;
+ status = okay;
+
+ qflash0: s25fl128s@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = spi-flash;
+ spi-max-frequency = 2000;
+ reg = 0;
+ };
+};
diff --git a/arch/arm/dts/ls1021a-twr.dts b/arch/arm/dts/ls1021a-twr.dts
new file mode 100644
index 000..db528f9
--- /dev/null
+++ b/arch/arm/dts/ls1021a-twr.dts
@@ -0,0 +1,31 @@
+/*
+ * Freescale ls1021a TWR board device tree source
+ *
+ * Copyright 2013-2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+#include ls1021a.dtsi
+
+/ {
+ model = LS1021A TWR Board;
+
+ aliases {
+ spi0 = qspi;
+ };
+};
+
+qspi {
+ bus-num = 0;
+ status = okay;
+
+ qflash0: n25q128a13@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = spi-flash;
+ spi-max-frequency = 2000;
+ reg = 0;
+ };
+};
diff --git a/arch/arm/dts/ls1021a.dtsi b/arch/arm/dts/ls1021a.dtsi
new file mode 100644
index 000..e160a5d
--- /dev/null
+++ b/arch/arm/dts/ls1021a.dtsi
@@ -0,0 +1,265 @@
+/*
+ * Freescale ls1021a SOC common device tree source
+ *
+ * Copyright 2013-2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include skeleton.dtsi
+
+/ {
+ compatible = fsl,ls1021a;
+
+ aliases {
+ serial0 = lpuart0;
+ serial1 = lpuart1;
+ serial2 = lpuart2;
+ serial3 = lpuart3;
+ serial4 = lpuart4;
+ serial5 = lpuart5;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@f00 {
+ compatible = arm,cortex-a7;
+ device_type = cpu;
+ reg = 0xf00;
+ };
+
+ cpu@f01 {
+ compatible = arm,cortex-a7;
+ device_type = cpu;
+ reg = 0xf01;
+ };
+ };
+
+ timer {
+ compatible = arm,armv7-timer;
+ };
+
+ pmu {
+ compatible = arm,cortex-a7-pmu;
+ };
+
+ soc {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges;
+
+
+ ifc: ifc@153 {
+ compatible = fsl,ifc, simple-bus;
+ reg = 0x153 0x1;
+ };
+
+ dcfg: dcfg@1ee {
+ compatible = fsl,ls1021a-dcfg, syscon;
+ reg = 0x1ee 0x1;
+
Re: [U-Boot] [PATCH v2 3/3] board/seco: Add mx6q-uq7 basic board support
On 04/03/2015 13:13, Boris Brezillon wrote: Add basic SECO MX6Q/uQ7 board support (Ethernet, UART, SD are supported). It also adds a Kconfig skeleton to later add more SECO board (supporting SoC and board variants). Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] imx:mx6slevk support reading temperature
On 10/03/2015 08:33, Peng Fan wrote: This patch is to support reading temperature for mx6slevk board. Signed-off-by: Peng Fan peng@freescale.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx:mx6dlsabresd fix error detecting thermal
On 10/03/2015 08:33, Peng Fan wrote: Before add CONFIG_SYS_MALLOC_F and CONFIG_SYS_MALLOC_F_LEN, uboot will complains CPU: Temperature: Can't find sensor device. This is because DM and DM_THERMAL are enabled, but SYS_MALLOC_F is not configured. After applying this patch, uboot can correctly detect the temperature. U-Boot 2015.04-rc2-00146-g48b6e30-dirty (Mar 09 2015 - 13:04:36) CPU: Freescale i.MX6DL rev1.1 at 792 MHz CPU: Temperature 44 C Signed-off-by: Peng Fan peng@freescale.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] ARM: mx6: move to a standard arch/board approach
On 04/03/2015 13:13, Boris Brezillon wrote: Freescale boards are currently all defined in arch/arm/Kconfig, which makes them hard to detect. Moreover the MX6 SoC variant (Q, D, DL, S, SL) selection is currently done via the SYS_EXTRA_OPTIONS option which marked as deprecated. Move to a more standard way to select sub-architecture and board by creating a Kconfig under arch/arm/cpu/armv7/mx6 and a new ARCH_MX6 option. Existing MX6 board definitions should be moved in this new Kconfig in choice menu, and new boards should be directly declared in this menu. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] ARM: iMX: define an IMX_CONFIG Kconfig option
On 04/03/2015 13:13, Boris Brezillon wrote: IMX_CONFIG is currently passed via the SYS_EXTRA_OPTIONS which is marked as deprecated. Add a new Kconfig file under arch/arm/imx-common and define the IMX_CONFIG Kconfig in there. Each board is supposed to provide a default value pointing to the appropriate imximage.cfg file. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: UniPhier: remove unnecessary CONFIG_SYS_SOC
2015-03-16 13:46 GMT+09:00 Masahiro Yamada yamada.masah...@socionext.com: Since commit a86ac9540e20 (ARM: UniPhier: include mach/*.h instead of asm/arch/*.h), UniPhier platform does not need the symbolic link arch/arm/include/asm. This option is not necessary either. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- Applied to u-boot-uniphier/master. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/13] ARM: UniPhier: enable CONFIG_SPL_DM with some clean-ups
2015-03-23 0:07 GMT+09:00 Masahiro Yamada yamada.masah...@socionext.com: Masahiro Yamada (13): ARM: UniPhier: include PH1-LD4 Makefile from PH1-sLD8 ARM: UniPhier: move platform devices to SPL ARM: UniPhier: move UART pin settings to SPL ARM: UniPhier: enable CONFIG_PANIC_HANG ARM: UniPhier: enable Driver Model and UART on SPL ARM: UniPhier: use CONFIG_SPL_STACK to define SPL stack pointer ARM: UniPhier: add CONFIG_SPL_MAX_FOOTPRINT ARM: UniPhier: move init stack area just below TEXT_BASE ARM: UniPhier: add empty lowlevel_init to U-boot proper ARM: UniPhier: fix typos in comments ARM: UniPhier: optimize kicking secondary CPUs code ARM: UniPhier: disable L2 cache by lowlevel_init of U-Boot proper ARM: UniPhier: remove unnecessary ifdef conditional Applied to u-boot-uniphier/master. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-uniphier
Hi Tom, The following changes since commit 21866c34a1b4098a8868c9250daf01baf84c2397: at91sam9rlek_mmc_defconfig: Add CONFIG_ARCH_AT91=y (2015-03-20 10:47:38 -0400) are available in the git repository at: git://git.denx.de/u-boot-uniphier.git master for you to fetch changes up to 90e357efed06767d87c49280bc25272fdf378612: ARM: UniPhier: remove unnecessary ifdef conditional (2015-03-24 00:16:02 +0900) Masahiro Yamada (14): ARM: UniPhier: remove unnecessary CONFIG_SYS_SOC ARM: UniPhier: include PH1-LD4 Makefile from PH1-sLD8 ARM: UniPhier: move platform devices to SPL ARM: UniPhier: move UART pin settings to SPL ARM: UniPhier: enable CONFIG_PANIC_HANG ARM: UniPhier: enable Driver Model and UART on SPL ARM: UniPhier: use CONFIG_SPL_STACK to define SPL stack pointer ARM: UniPhier: add CONFIG_SPL_MAX_FOOTPRINT ARM: UniPhier: move init stack area just below TEXT_BASE ARM: UniPhier: add empty lowlevel_init to U-boot proper ARM: UniPhier: fix typos in comments ARM: UniPhier: optimize kicking secondary CPUs code ARM: UniPhier: disable L2 cache by lowlevel_init of U-Boot proper ARM: UniPhier: remove unnecessary ifdef conditional arch/arm/mach-uniphier/Kconfig | 3 --- arch/arm/mach-uniphier/Makefile | 2 +- arch/arm/mach-uniphier/cache_uniphier.c | 32 ++-- arch/arm/mach-uniphier/init_page_table.S| 10 +- arch/arm/mach-uniphier/late_lowlevel_init.S | 17 + arch/arm/mach-uniphier/lowlevel_init.S | 63 +++ arch/arm/mach-uniphier/ph1-ld4/Makefile | 4 ++-- arch/arm/mach-uniphier/ph1-ld4/early_pinctrl.c | 27 +++ arch/arm/mach-uniphier/ph1-ld4/pinctrl.c| 18 ++ arch/arm/mach-uniphier/ph1-pro4/Makefile| 4 ++-- arch/arm/mach-uniphier/ph1-pro4/early_pinctrl.c | 27 +++ arch/arm/mach-uniphier/ph1-pro4/pinctrl.c | 15 ++- arch/arm/mach-uniphier/ph1-sld8/Makefile| 17 + arch/arm/mach-uniphier/ph1-sld8/early_pinctrl.c | 27 +++ arch/arm/mach-uniphier/ph1-sld8/pinctrl.c | 18 ++ arch/arm/mach-uniphier/smp.S| 54 -- arch/arm/mach-uniphier/spl.c| 18 +++--- arch/arm/mach-uniphier/support_card.c | 11 ++- configs/ph1_ld4_defconfig | 1 + configs/ph1_pro4_defconfig | 1 + configs/ph1_sld8_defconfig | 1 + include/configs/uniphier.h | 20 22 files changed, 200 insertions(+), 190 deletions(-) create mode 100644 arch/arm/mach-uniphier/late_lowlevel_init.S create mode 100644 arch/arm/mach-uniphier/ph1-ld4/early_pinctrl.c create mode 100644 arch/arm/mach-uniphier/ph1-pro4/early_pinctrl.c create mode 100644 arch/arm/mach-uniphier/ph1-sld8/early_pinctrl.c delete mode 100644 arch/arm/mach-uniphier/smp.S -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] question about software i2c multi instance
Hi Bo, Hi Heiko, After check the software i2c code, I found it can not support multi instances, although it has I2C_SOFT_DECLARATIONS2, I2C_SOFT_DECLARATIONS3, I2C_SOFT_DECLARATIONS4. Because, when do GPIO operation, there is only one pair of CONFIG_SOFT_I2C_GPIO_SCL and CONFIG_SOFT_I2C_GPIO_SDA. So, if want to support multi instances, it needs to extend the GPIO configuration for SCL/SDA, am I right? Some time ago we had a similar problem with SW I2C code. Please look into Samsung's trats board implementation. However, such approach might be outdated, since Przemek is working on porting this functionality to device model: https://patchwork.ozlabs.org/patch/448460/ Thanks. Best Regards, Bo Shen -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] sunxi: Ainol AW1 support
Hi, On 23-03-15 08:09, Chen-Yu Tsai wrote: Hi, On Mon, Mar 23, 2015 at 1:07 AM, Paul Kocialkowski cont...@paulk.fr wrote: Maybe a slight description of the board/device? Never mind I've just merged this in my local tree, adding a short description myself based on (and pointing to): http://linux-sunxi.org/Ainol_AW1 I'll push this to next once tested. Regards, Hans ChenYu Signed-off-by: Paul Kocialkowski cont...@paulk.fr --- board/sunxi/MAINTAINERS | 5 + configs/Ainol_AW1_defconfig | 16 2 files changed, 21 insertions(+) create mode 100644 configs/Ainol_AW1_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index ef3c937..e486458 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -50,6 +50,11 @@ S: Maintained F: board/sunxi/dram_a20_olinuxino_l2.c F: configs/A20-OLinuXino-Lime2_defconfig +AINOL AW1 BOARD +M: Paul Kocialkowski cont...@paulk.fr +S: Maintained +F: configs/Ainol_AW1_defconfig + AMPE A76 BOARD M: Paul Kocialkowski cont...@paulk.fr S: Maintained diff --git a/configs/Ainol_AW1_defconfig b/configs/Ainol_AW1_defconfig new file mode 100644 index 000..1c3b942 --- /dev/null +++ b/configs/Ainol_AW1_defconfig @@ -0,0 +1,16 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER +CONFIG_FDTFILE=sun7i-a20-ainol-aw1.dtb +CONFIG_USB_MUSB_SUNXI=y +CONFIG_USB0_VBUS_PIN=PB9 +CONFIG_USB0_VBUS_DET=AXP0-VBUS-DETECT +CONFIG_VIDEO_LCD_MODE=x:800,y:480,depth:18,pclk_khz:4,le:87,ri:112,up:38,lo:141,hs:1,vs:1,sync:3,vmode:0 +CONFIG_VIDEO_LCD_POWER=PH8 +CONFIG_VIDEO_LCD_BL_EN=PH7 +CONFIG_VIDEO_LCD_BL_PWM=PB2 +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_MACH_SUN7I=y +CONFIG_DRAM_CLK=432 +CONFIG_DRAM_ZQ=123 +CONFIG_DRAM_EMR1=4 -- 1.9.1 ___ 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 01/27] test: dm: Reorder the objects to build
On 22 March 2015 at 16:08, Joe Hershberger joe.hershber...@ni.com wrote: Signed-off-by: Joe Hershberger joe.hershber...@ni.com Acked-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] sunxi: Ainol AW1 support
Hi, On 23-03-15 08:09, Chen-Yu Tsai wrote: Hi, On Mon, Mar 23, 2015 at 1:07 AM, Paul Kocialkowski cont...@paulk.fr wrote: Maybe a slight description of the board/device? Yes please, note no need to send a new version if you reply with a short description I can add that while merging these. This version of the patch-set looks good, so I plan to merge it as is (assuming tests on the a23 tablet I've turn out ok). Not sure yet when exactly I will get around to merging this, that should happen sometime during this week. Regards, Hans ChenYu Signed-off-by: Paul Kocialkowski cont...@paulk.fr --- board/sunxi/MAINTAINERS | 5 + configs/Ainol_AW1_defconfig | 16 2 files changed, 21 insertions(+) create mode 100644 configs/Ainol_AW1_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index ef3c937..e486458 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -50,6 +50,11 @@ S: Maintained F: board/sunxi/dram_a20_olinuxino_l2.c F: configs/A20-OLinuXino-Lime2_defconfig +AINOL AW1 BOARD +M: Paul Kocialkowski cont...@paulk.fr +S: Maintained +F: configs/Ainol_AW1_defconfig + AMPE A76 BOARD M: Paul Kocialkowski cont...@paulk.fr S: Maintained diff --git a/configs/Ainol_AW1_defconfig b/configs/Ainol_AW1_defconfig new file mode 100644 index 000..1c3b942 --- /dev/null +++ b/configs/Ainol_AW1_defconfig @@ -0,0 +1,16 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER +CONFIG_FDTFILE=sun7i-a20-ainol-aw1.dtb +CONFIG_USB_MUSB_SUNXI=y +CONFIG_USB0_VBUS_PIN=PB9 +CONFIG_USB0_VBUS_DET=AXP0-VBUS-DETECT +CONFIG_VIDEO_LCD_MODE=x:800,y:480,depth:18,pclk_khz:4,le:87,ri:112,up:38,lo:141,hs:1,vs:1,sync:3,vmode:0 +CONFIG_VIDEO_LCD_POWER=PH8 +CONFIG_VIDEO_LCD_BL_EN=PH7 +CONFIG_VIDEO_LCD_BL_PWM=PB2 +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_MACH_SUN7I=y +CONFIG_DRAM_CLK=432 +CONFIG_DRAM_ZQ=123 +CONFIG_DRAM_EMR1=4 -- 1.9.1 ___ 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] serial atag tag in devicetree ?
Hi, On 22-03-15 22:01, Rob Herring wrote: On Sun, Mar 22, 2015 at 6:26 AM, Hans de Goede hdego...@redhat.com wrote: Hi All, I'm sending this mail because Paul Kocialkowski (in the Cc) has submitted a patch for upstream u-boot to set the serial atag tag from u-boot for Allwinner SoCs, using the SoCs SID, which is a 128 bit register containing a unique number for each SoC. We shouldn't really be adding ATAGs to newer platforms... In some cases a manufacturer may want to override this with its own serial from say an eeprom, as such it is desirable to communicate the serial from u-boot to the kernel rather then reproducing the sid reading code in the kernel. For old atag using kernels there is an atag for this, and the contents of this tag will show up in /proc/cpuinfo, currently there is no equivalent for this in devicetree. I'm a bit reluctant to merge Paul's patch into u-boot because of this as it will enable a feature on older kernels while leaving the upstream kernel without it. So I was wondering how to deal with this in devicetree, at least one board in u-boot already sets a devicetree property for this: board/gateworks/gw_ventana/gw_ventana.c 1202: * serial# env var 1207: char *serial = getenv(serial#); 1432: setenv(serial#, str); 1512: fdt_setprop(blob, 0, system-serial, getenv(serial#), 1513: strlen(getenv(serial#)) + 1); Which sets a system-serial property in the root node, so at the same level where we also have the model string this seems to make sense to me. system-serial is new to me... So do we want to add a devicetree binding for system serials, and if we do should we make it a string like above, or should we make it an 64 bit integer like the atag? If we make it a string we can store longer serials, but how should we deal with those wrt /proc/cpuinfo? Only show the first 64 bits ? There is already serial-number (a string) which exists for OpenFirmware. Also, copyright corresponds to vendor/manufacturer string. Both of these are supported by lshw already. Ok, so if I understand you correctly then you're saying that we should set a serial-number string property at the dt root level and that this may contain pretty much anything, e.g. in the sunxi case the full 128 bit SID in hex. Is the use of the serial-number string property already documented somewhere? If not I'll submit a kernel patch to document it. And for older kernels we should not set any serial atag (u-boot always sets it, so this leaves it at 0) and old kernel users are out of luck wrt getting to the serial ? Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] question about software i2c multi instance
Hi Heiko,
On 03/20/2015 06:10 PM, Heiko Schocher wrote:
Hello Bo,
Am 20.03.2015 10:44, schrieb Bo Shen:
Hi Heiko,
After check the software i2c code, I found it can not support multi
instances, although it has I2C_SOFT_DECLARATIONS2,
I2C_SOFT_DECLARATIONS3, I2C_SOFT_DECLARATIONS4.
Because, when do GPIO operation, there is only one pair of
CONFIG_SOFT_I2C_GPIO_SCL and CONFIG_SOFT_I2C_GPIO_SDA.
So, if want to support multi instances, it needs to extend the GPIO
configuration for SCL/SDA, am I right?
Prefered way should be to use DM, Przemyslaw posted patches
for the soft-i2c driver, see
http://lists.denx.de/pipermail/u-boot/2015-March/207641.html
maybe you can try this?
Thanks for your information.
As I try to use the old version of U-Boot, it doesn't support DM well.
If not, you are right, you must define your own
I2C_SCL/I2C_SDA/I2C_READ/I2C_INIT
defines, for example:
# define I2C_SCL(bit) \
do { \
switch(I2C_ADAP_HWNR) {
case 0:
gpio_direction_output(CONFIG_SOFT_I2C_GPIO_SCL_0, bit); \
break;
case 1:
gpio_direction_output(CONFIG_SOFT_I2C_GPIO_SCL_1, bit); \
break;
[...]
I2C_GPIO_SYNC; \
} while (0)
For this, the I2C_SCL and I2C_SDA working, however for I2C_READ, it
maybe need to modify the definition from micro to function, as the
I2C_READ can not use do {} while.
Thanks again.
bye,
Heiko
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: dwc2: fix bulk transfers
When I created wait_for_chhltd(), I noticed that some instances of the
code it replaced expected the ACK bit to be set and others didn't. I
assumed this was an accidental inconsistency in the code, so wrote
wait_for_chhltd() to always expect ACK to be set. This code appeared to
work correctly for both enumeration of USB keyboards and operation of
USB Ethernet devices. However, this change broke USB Mass Storage (at
least my USB SD card reader). This change reverts to exactly the
original behaviour. I'm not sure why the ACK bit isn't always set
(perhaps a quirk in the USB HW or DWC2 controller), but the code works
this way!
Fixes: 5be4ca7d6ac8 (usb: dwc2: unify waiting for transfer completion)
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
drivers/usb/host/dwc2.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index e370d29ffc8e..5f4ca7abf7bf 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -703,10 +703,9 @@ static int dwc_otg_submit_rh_msg(struct usb_device *dev,
unsigned long pipe,
return stat;
}
-int wait_for_chhltd(uint32_t *sub, int *toggle)
+int wait_for_chhltd(uint32_t *sub, int *toggle, bool ignore_ack)
{
- const uint32_t hcint_comp_hlt_ack = DWC2_HCINT_XFERCOMP |
- DWC2_HCINT_CHHLTD | DWC2_HCINT_ACK;
+ uint32_t hcint_comp_hlt_ack = DWC2_HCINT_XFERCOMP | DWC2_HCINT_CHHLTD;
struct dwc2_hc_regs *hc_regs = regs-hc_regs[DWC2_HC_CHANNEL];
int ret;
uint32_t hcint, hctsiz;
@@ -716,6 +715,10 @@ int wait_for_chhltd(uint32_t *sub, int *toggle)
return ret;
hcint = readl(hc_regs-hcint);
+ if (ignore_ack)
+ hcint = ~DWC2_HCINT_ACK;
+ else
+ hcint_comp_hlt_ack |= DWC2_HCINT_ACK;
if (hcint != hcint_comp_hlt_ack) {
debug(%s: Error (HCINT=%08x)\n, __func__, hcint);
return -EINVAL;
@@ -739,7 +742,7 @@ static int dwc2_eptype[] = {
};
int chunk_msg(struct usb_device *dev, unsigned long pipe, int *pid, int in,
- void *buffer, int len)
+ void *buffer, int len, bool ignore_ack)
{
struct dwc2_hc_regs *hc_regs = regs-hc_regs[DWC2_HC_CHANNEL];
int devnum = usb_pipedevice(pipe);
@@ -800,7 +803,7 @@ int chunk_msg(struct usb_device *dev, unsigned long pipe,
int *pid, int in,
(1 DWC2_HCCHAR_MULTICNT_OFFSET) |
DWC2_HCCHAR_CHEN);
- ret = wait_for_chhltd(sub, pid);
+ ret = wait_for_chhltd(sub, pid, ignore_ack);
if (ret) {
stop_transfer = 1;
break;
@@ -839,7 +842,7 @@ int submit_bulk_msg(struct usb_device *dev, unsigned long
pipe, void *buffer,
}
return chunk_msg(dev, pipe, bulk_data_toggle[devnum][ep],
-usb_pipein(pipe), buffer, len);
+usb_pipein(pipe), buffer, len, true);
}
int submit_control_msg(struct usb_device *dev, unsigned long pipe, void
*buffer,
@@ -857,14 +860,14 @@ int submit_control_msg(struct usb_device *dev, unsigned
long pipe, void *buffer,
}
pid = DWC2_HC_PID_SETUP;
- ret = chunk_msg(dev, pipe, pid, 0, setup, 8);
+ ret = chunk_msg(dev, pipe, pid, 0, setup, 8, true);
if (ret)
return ret;
if (buffer) {
pid = DWC2_HC_PID_DATA1;
ret = chunk_msg(dev, pipe, pid, usb_pipein(pipe), buffer,
- len);
+ len, false);
if (ret)
return ret;
act_len = dev-act_len;
@@ -879,7 +882,8 @@ int submit_control_msg(struct usb_device *dev, unsigned
long pipe, void *buffer,
status_direction = 0;
pid = DWC2_HC_PID_DATA1;
- ret = chunk_msg(dev, pipe, pid, status_direction, status_buffer, 0);
+ ret = chunk_msg(dev, pipe, pid, status_direction, status_buffer, 0,
+ false);
if (ret)
return ret;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: rpi: fix RPi1 board rev detection for warranty bit
Apparently the firmware's board rev response includes both the board
revision and some other data even on the RPi1. In particular, the
warranty bit is bit 24. We need to mask that out when looking up the
board ID.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
board/raspberrypi/rpi/rpi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 50a699bb9e0c..a105953541be 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -278,10 +278,17 @@ static void get_board_rev(void)
* https://github.com/pimoroni/RPi.version/blob/master/RPi/version.py
* http://www.raspberrypi.org/forums/viewtopic.php?f=63t=99293p=690282
* (a few posts down)
+*
+* For the RPi 1, bit 24 is the warranty bit, so we mask off just the
+* lower byte to use as the board rev:
+*
http://www.raspberrypi.org/forums/viewtopic.php?f=63t=98367start=250
+* http://www.raspberrypi.org/forums/viewtopic.php?f=31t=20594
*/
rpi_board_rev = msg-get_board_rev.body.resp.rev;
if (rpi_board_rev 0x80)
rpi_board_rev = (rpi_board_rev 4) 0xff;
+ else
+ rpi_board_rev = 0xff;
if (rpi_board_rev = ARRAY_SIZE(models)) {
printf(RPI: Board rev %u outside known range\n,
rpi_board_rev);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] net: Add Intel Topcliff GMAC driver
Hi Simon, On Tue, Mar 24, 2015 at 12:18 PM, Simon Glass s...@chromium.org wrote: Hi Bin, On Mar 23, 2015 7:24 PM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Tue, Mar 24, 2015 at 5:57 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 20 March 2015 at 13:18, Joe Hershberger joe.hershber...@gmail.com wrote: On Fri, Mar 20, 2015 at 4:12 AM, Bin Meng bmeng...@gmail.com wrote: Add a new driver for the Gigabit Ethernet MAC found on Intel Topcliff Platform Controller Hub. Tested under 10/100 half/full duplex and 1000 full duplex modes using ping and tftpboot commands. Signed-off-by: Bin Meng bmeng...@gmail.com --- Acked-by: Joe Hershberger joe.hershber...@ni.com Do you think this could be converted to driver model? E.g., see this: http://patchwork.ozlabs.org/patch/444846/ Yes, I plan to do the conversion in the future as a separate patch. If possible to catch up the train for the v2015.04 release, are you going to apply this series now? I was planning to do this later. Do you want it in this release? I suppose that would be ok because it is a new board. Yep, given the series look OK and no rework will be needed, I would like to add it to this release if time permits. And maybe along with my other patches before (quark)? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/board_f: make board_init_f_mem() independent on !CONFIG_X86
Hi Simon,
On Mon, 2015-03-23 at 11:26 -0600, Simon Glass wrote:
On 23 March 2015 at 10:40, Alexey Brodkin alexey.brod...@synopsys.com wrote:
Hi Tom, Simon,
On Mon, 2015-03-16 at 11:03 +0300, Alexey Brodkin wrote:
Even though board_init_f_mem() is not used on x86 today there's no
reason to not use it in the future.
Moreover board_init_f_mem() has nothing to do with any particular
architecture so move it away from #else /* CONFIG_X86 */
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Simon Glass s...@chromium.org
Cc: Tom Rini tr...@ti.com
Any comments on this one?
This is a prerequisite for ARC updates so would be good to have it
merged sometime soon.
I must have missed something as it did not seem to change anything for ARC.
I meant this series -
http://lists.denx.de/pipermail/u-boot/2015-March/208179.html
In particular here I wanted to use board_init_f_mem():
http://lists.denx.de/pipermail/u-boot/2015-March/208183.html
Note that in the previous patch
http://lists.denx.de/pipermail/u-boot/2015-March/208182.html I re-used
former X86-only code sections in common/board_f.c - that's why I did
need board_init_f_mem() to be separated from #ifdef CONFIG_X86 #else - I
wanted to use both branches :)
This breaks building on x86 though, so we can't take this patch as is. E.g.:
x86: + crownbay
+common/board_f.c: In function ‘board_init_f_mem’:
+common/board_f.c:1092:5: error: lvalue required as left operand of assignment
+ gd = (struct global_data *)top;
+ ^
That's why I wanted your opinion :)
Sandbox didn't show any problems and I didn't do makeall.
Because in case of X86 gd is an alias to get_fs_gd_ptr() we cannot do
such assignments.
So then we'll need to keep board_init_f_mem() disabled for X86 like
that:
---8---
#ifndef CONFIG_X86
ulong board_init_f_mem(ulong top)
{
/* Leave space for the stack we are running with now */
top -= 0x40;
top -= sizeof(struct global_data);
top = ALIGN(top, 16);
gd = (struct global_data *)top;
memset((void *)gd, '\0', sizeof(*gd));
#ifdef CONFIG_SYS_MALLOC_F_LEN
top -= CONFIG_SYS_MALLOC_F_LEN;
gd-malloc_base = top;
#endif
return top;
}
#endif
---8---
Do you think that's OK? If so I'll send v2 shortly.
-Alexey
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 20/28] armv8/ls2085ardb: Add support of LS2085ARDB platform
On Fri, 2015-03-20 at 18:46 -0700, York Sun wrote: On 03/20/2015 05:33 PM, Scott Wood wrote: On Fri, 2015-03-20 at 17:29 -0700, York Sun wrote: diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f4a7851..7478eb4 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -658,6 +658,16 @@ config TARGET_LS2085AQDS development platform that supports the QorIQ LS2085A Layerscape Architecture processor. +config TARGET_LS2085ARDB + bool Support ls2085ardb + select ARM64 + select ARMV8_MULTIENTRY + help +Support for Freescale LS2085ARDB platform. +The LS2080A Reference design board (RDB) is a high-performance +development platform that supports the QorIQ LS2085A +LayerScape Architecture processor. + s/LayerScape/Layerscape/ diff --git a/board/freescale/ls2085aqds/README b/board/freescale/ls2085ardb/README similarity index 73% copy from board/freescale/ls2085aqds/README copy to board/freescale/ls2085ardb/README index a4d7b53..cfd5185 100644 --- a/board/freescale/ls2085aqds/README +++ b/board/freescale/ls2085ardb/README @@ -1,10 +1,8 @@ Overview -The LS2080A Development System (QDS) is a high-performance computing, -evaluation, and development platform that supports the QorIQ LS2080A -LayerScape Architecture processor. The LS2080AQDS provides validation and -SW development platform for the Freescale LS2080A processor series, with -a complete debugging environment. +The LS2085A Reference Design (RDB) is a high-performance computing, +evaluation, and development platform that supports the QorIQ LS2085A +Layerscape Architecture processor. LayerScape and 2080 should be fixed in the QDS patch as well. @@ -113,25 +105,25 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_SYS_NAND_CSOR(CSOR_NAND_ECC_ENC_EN /* ECC on encode */ \ | CSOR_NAND_ECC_DEC_EN /* ECC on decode */ \ | CSOR_NAND_ECC_MODE_4 /* 4-bit ECC */ \ - | CSOR_NAND_RAL_3 /* RAL = 2Byes */ \ - | CSOR_NAND_PGS_2K /* Page Size = 2K */ \ - | CSOR_NAND_SPRZ_64/* Spare size = 64 */ \ - | CSOR_NAND_PB(64)) /*Pages Per Block = 64*/ + | CSOR_NAND_RAL_3 /* RAL = 3Byes */ \ + | CSOR_NAND_PGS_4K /* Page Size = 4K */ \ + | CSOR_NAND_SPRZ_224/* Spare size = 224 */ \ + | CSOR_NAND_PB(128))/*Pages Per Block = 128*/ From this it looks like the QDS patch still has a comment/code inconsistency with RAL. Let me re-generate the patch using patman, without -C --find-copies-harder flag so they don't show as copy-n-modify. Why? I found it rather useful. In any case, the error in the QDS file will still be there. -SCott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] sunxi: Yones Toptech BD1078 support
Hi, p.s. On 22-03-15 18:12, Paul Kocialkowski wrote: This series goes on top of my previous series that concludes with Ainol AW1 support. Also, if you're interested by the idea of using sunxi_name_to_gpio_bank, this could be extended for UART as well, where *many* different pin mux setups are possible. We are just lucky that hardware designers usually use the ports that U-Boot selects, but there is no fundamental reason for that. I'm not really interested in making the #ifdeffery for the uart setup even more complicated, eventually we should get all this info, including all the pinmux stuff from a dtb (shared with the kernel) appended to the u-boot binary, and then this will use standard devicetree pinmux stuff, until we get there I would like to keep this as simple as possible. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: axp221: Use vbus-available rather then vbus-usable for vbus-detect
Le lundi 23 mars 2015 à 17:28 +0100, Hans de Goede a écrit : vbus-usable does not get set if power is provided through the power barrel connector, even if external 5v is also present on the otg connector. vbus-available correctly always reflects if there is 5v present on the otg connector. You (or I) could submit the very same change for the AXP209. It's the same bit for available (1 5). Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/power/axp221.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/power/axp221.c b/drivers/power/axp221.c index f758a75..dc3a7f1 100644 --- a/drivers/power/axp221.c +++ b/drivers/power/axp221.c @@ -424,7 +424,7 @@ int axp_gpio_get_value(unsigned int pin) if (ret) return ret; - return !!(val AXP221_POWER_STATUS_VBUS_USABLE); + return !!(val AXP221_POWER_STATUS_VBUS_AVAIL); default: return -EINVAL; } signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: axp221: Use vbus-available rather then vbus-usable for vbus-detect
Hi, On 23-03-15 17:33, Paul Kocialkowski wrote: Le lundi 23 mars 2015 à 17:28 +0100, Hans de Goede a écrit : vbus-usable does not get set if power is provided through the power barrel connector, even if external 5v is also present on the otg connector. vbus-available correctly always reflects if there is 5v present on the otg connector. You (or I) could submit the very same change for the AXP209. It's the same bit for available (1 5). Yes I was about to mail you about that when I noticed that this seems to break actual host mode support on the otg connector, it seems that plugging in a micro-b to usb-a receptacle (aka host) convertor + a device plugged into the usb-a receptacle also causes bit 5 to get set :| So my patch is no good, but powering the otg port while external 5v is present also is not good (one side effect is that the tablet will power up immediately after sending a power-off command to the axp221). If you've some time to tinker with this I would appreciate any ideas you may have (assuming the same problem exists on the axp209) simply plug in 5v power into the power barrel, as well as 5v power (e.g. simply from your pc) and boot up the tablet, at least in my case then it does not properly give the charger plugged in error. Regards, Hans Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/power/axp221.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/power/axp221.c b/drivers/power/axp221.c index f758a75..dc3a7f1 100644 --- a/drivers/power/axp221.c +++ b/drivers/power/axp221.c @@ -424,7 +424,7 @@ int axp_gpio_get_value(unsigned int pin) if (ret) return ret; - return !!(val AXP221_POWER_STATUS_VBUS_USABLE); + return !!(val AXP221_POWER_STATUS_VBUS_AVAIL); default: return -EINVAL; } ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 07/27] net: Change return codes from net/eth.c to use errorno constants
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: Many functions returned -1 previously. Change them to return appropriate error codes. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reported-by: Simon Glass s...@chromium.org Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 03/27] net: Provide a function to get the current MAC address
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: The current implementation exposes the eth_device struct to code that needs to access the MAC address. Add a wrapper function for this to abstract away the pointer for this operation. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 05/27] net: Remove unneeded extern in net.h
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: Many of the functions in net.h were preceded extern needlessly. Removing them to limit the number of checkpatch.pl complaints. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 02/27] common: Make sure arch-specific map_sysmem() is defined
On 22 March 2015 at 16:08, Joe Hershberger joe.hershber...@ni.com wrote: In the case where the arch defines a custom map_sysmem(), make sure that including just mapmem.h is sufficient to have these functions as they are when the arch does not override it. Also split the non-arch specific functions out of common.h Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 04/27] net: Rename helper function to be more clear
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: Make it clear that the helper is checking the addr, not setting it. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 06/27] net: Refactor in preparation for driver model
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: Move some things around and organize things so that the driver model implementation will fit in more easily. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 11/27] net: Access mapped physmem in net functions
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: Previously the net functions would access memory assuming physmem did not need to be mapped. In sandbox, that's not the case. Now we map the physmem specified by the user in loadaddr to the buffer that represents that space. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 12/27] cmd: net: Clean up return codes
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: The return codes in common/cmd_net.c had a number of inconsistencies. Update them to all use the enum from command.h Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 15/27] dm: eth: Pass the packet pointer as a parameter to recv
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: Stop forcing drivers to call net_process_received_packet() - formerly called NetReceive(). Now the uclass will handle calling the driver for each packet until the driver errors or has nothing to return. The uclass will then pass the good packets off to the network stack by calling net_process_received_packet(). Signed-off-by: Joe Hershberger joe.hershber...@ni.com --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 14/27] net: Clean up network stack names used in DM drivers
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: Take the opportunity to enforce better names on newly written or retrofitted Ethernet drivers. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 08/27] net: Use int instead of u8 for boolean flag
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: On some archs masking the parameter is inefficient, so don't use u8. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reported-by: Simon Glass s...@chromium.org Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 09/27] net: Remove the bd* parameter from net stack functions
Hi Joe, On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: This value is not used by the network stack and is available in the global data, so stop passing it around. For the one legacy function that still expects it (init op on old Ethernet drivers) pass in the global pointer version directly to avoid changing that interface. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reported-by: Simon Glass s...@chromium.org Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: -Fixed compile error in 4xx_enet.c This fixes the compile error but introduced a warning. However the fix was trivial (just removing a variable declaration). So I applied that fix to your patch. Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 10/27] net: Make netretry actually do something
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: netretry previously would only retry in one specific case (your MAC address is not set) and no other. This is basically useless. In the DM implementation for eth it turns this into a completely useless case since an un-configured MAC address results in not even entering the NetLoop. The behavior is now changed to retry any failed command (rotating through the eth adapters if ethrotate != no). It also defaulted to retry forever. It is now changed to default to not retry Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 13/27] dm: eth: Add basic driver model support to Ethernet stack
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: First just add support for MAC drivers. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 18/27] test: dm: eth: Add tests for the eth dm implementation
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: Add a test for the eth uclass using the sandbox eth driver. Verify basic functionality of the network stack / eth uclass by exercising the ping function. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 19/27] dm: eth: Add support for aliases
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: Allow network devices to be referred to as eth0 instead of eth@12345678 when specified in ethact. Add tests to verify this behavior. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 17/27] sandbox: eth: Add ARP and PING response to sandbox driver
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: The sandbox driver will now generate response traffic to exercise the ping command even when no network exists. This allows the basic data pathways of the DM to be tested. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 21/27] test: dm: eth: Add testing for ethrotate env var
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: Make sure that the ethrotate behavior occurs as expected. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 20/27] dm: eth: Add support for ethprime env var
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: The ethprime env var is used to indicate the starting device if none is specified in ethact. Also support aliases specified in the ethprime var. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 22/27] sandbox: eth: Add ability to disable ping reply in sandbox eth driver
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: This is needed to test the netretry functionality (make the command fail on a sandbox eth device). Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 16/27] sandbox: eth: Add network support to sandbox
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: Add basic network support to sandbox which includes a network driver. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 23/27] test: dm: net: Add a test of the netretry behavior
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: The effect of the netretry env var was recently changed. This test checks that behavior. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 24/27] sandbox: eth: Add a bridge to a real network for sandbox
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: Implement a bridge between U-Boot's network stack and Linux's raw packet API allowing the sandbox to send and receive packets using the host machine's network interface. This raw Ethernet API requires elevated privileges. You can either run as root, or you can add the capability needed like so: sudo /sbin/setcap CAP_NET_RAW+ep /path/to/u-boot Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 25/27] sandbox: Enable DHCP and IP defrag
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: This is now testable via the eth-raw interface Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 27/27] net: Improve error handling
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: Take a pass at plumbing errors through to the users of the network stack Currently only the start() function errors will be returned from NetLoop(). recv() tends not to have errors, so that is likely not worth adding. send() certainly can return errors, but this patch does not attempt to plumb them yet. halt() is not expected to error. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 26/27] sandbox: eth: Add support for using the 'lo' interface
On 22 March 2015 at 16:09, Joe Hershberger joe.hershber...@ni.com wrote: The 'lo' interface on Linux doesn't support thinks like ARP or link-layer access like we use to talk to a normal network interface. A higher-level network API must be used to access localhost. As written, this interface is limited to not supporting ICMP since the API doesn't allow the socket to be opened for all IP traffic and be able to receive at the same time. UDP is far more useful to test with, so it was selected over ICMP. Ping won't work, but things like TFTP should work. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v7: None Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Rework the network stack
Hi Jörg,
On 22 March 2015 at 14:37, Jörg Krause joerg.krause@embedded.rocks wrote:
Hi Joe,
On Sa, 2015-03-21 at 22:59 -0500, Joe Hershberger wrote:
Hi Jörg,
On Sat, Mar 21, 2015 at 3:33 AM, Jörg Krause joerg.krause@embedded.rocks
wrote:
Hi all,
there is an issue with the current network stack using netconsole. It's
impossible to use network commands as TFTP inside netconsole, because
they try to run as atomic network commands.
The issue was already reported by Stefano Babic in 2010:
[U-Boot] NetConsole and network API
http://lists.denx.de/pipermail/u-boot/2010-August/075535.html
I worked around this problem here:
http://lists.denx.de/pipermail/u-boot/2012-August/129913.html
I know about this patch, and I understand the problem it tries to
workaround. But it does not work for using netconsole with another
protocol like ping. When for example ping enters the NetLoop() it will
halt the network device.
The problem for this is here:
if (eth_is_on_demand_init() || protocol != NETCONS) {
eth_halt();
...
}
eth_is_on_demand_init() returns correctly with false, because PING !=
NETCONS. But the second expression results in true, because PING !=
NETCONS.
I run into the same problem:
[U-Boot] netconsole: USB Ethernet connection dropping with ping or
tftpboot
http://lists.denx.de/pipermail/u-boot/2015-February/203838.html
I didn't understand what about your case was not able to work given the
workaround I implemented previously. What was different about it?
I have looked at the current network stack. The stack is based on the
concept of atomic network commands. The implementation for netconsole
looks very confusing.
There is no doubt that netconsole is quite confusing as it exists today.
I tried to fix the issue, but it did not work properly.
Sascha Hauer has reimplemented the network stack for Barebox:
http://www.spinics.net/lists/u-boot-v2/msg00914.html
Looking at the current implementation of net.c looks very clean and
well-designed.
Thanks for pointing this out. I hadn't gone to look at the network stack in
barebox.
What do you think about porting this to U-Boot?
I can look into this. Naturally there are many other changes to u-boot
network stack since the time barebox forked, so I expect such a port to be
very intensive... most likely a near complete rewrite of Sascha's series,
but I will investigate further.
I had a look at the patches and the code base is not entirely the same.
But maybe we should just stick to the crucial points of the new network
stack:
1) A network device gets initialized when it becomes the current one and
gets brought down when it's not used anymore or prior booting to Linux
so the connection remains active all the time.
My thoughts about this one:
Bringing the device down can be done in eth_unregister(). Initializing
for the current device can be done in eth_current_changed(). What I like
even better is to make eth_current_changed() the sole place for calling
init() and halt(). It would have to be extend to take at least two
parameters, eth_current and new_current. If eth_current is null just
bring up the new device, if new_current is null just bring down the
current device.
2) Replace the NetLoop by a connection list where each protocol uses a
connection to send and receive packets.
This induce to port all protocols to use the new network, of cause.
In my opinion it would be also good to do some clean ups and
restructuring of code. Put more functions into net-utils, is there a
need for eth_init and so on.
Joe has done a lot of work to move U-Boot's network stack over to
driver model. This is now at u-boot-dm/next waiting for the merge
window to open.
The connection list idea does not sound like a hugely complex change.
Are you thinking of trying it out?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: axp221: Use vbus-available rather then vbus-usable for vbus-detect
Hi, On Mon, Mar 23, 2015 at 9:34 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 23-03-15 17:28, Hans de Goede wrote: vbus-usable does not get set if power is provided through the power barrel connector, even if external 5v is also present on the otg connector. vbus-available correctly always reflects if there is 5v present on the otg connector. Except that it also gets set when there is a usb-host cable with a device attached plugged in, so this is going to need some more thinking, I'll send a new patch when I've something which does not break using the port in host mode. My understanding is VBUS_Usable = VBUS_Available (!(N_VBUSEN || reg 30h[7])) reg 30h[7] says whether to check N_VBUSEN before using VBUS. ChenYu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: fix colibri_t20 machine type
On 03/23/2015 11:43 AM, Marcel Ziswiler wrote: A while ago I got Russell to change the machine type of our Colibri T20 from COLIBRI_TEGRA2 to COLIBRI_T20 which is also reflected in his machine registry: http://www.arm.linux.org.uk/developer/machines/list.php?id=3323 Only half of the references there seem to be updated; there are still some mentions of e.g. CONFIG_MACH_COLIBRI_TEGRA2, MACH_TYPE_COLIBRI_TEGRA2. Perhaps it's still in flux? Even so, this change seems fine since it does better represent the name of the board. Acked-by: Stephen Warren swar...@nvidia.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] Document config_distro_bootcmd environment variables for interactive booting.
On 03/21/2015 07:15 AM, Karsten Merker wrote: config_distro_bootcmd.h defines a common boot environment for multiple platforms, including several environment variables that are intended for interactive use by an end-user. Document which variables are considered public interfaces that must remain compatible in future u-boot versions. Acked-by: Stephen Warren swar...@nvidia.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config: Use booti instead of bootz on 64-bit ARM
On 03/20/2015 11:07 AM, Tom Rini wrote: On Fri, Mar 20, 2015 at 10:17:00AM -0600, Stephen Warren wrote: On 03/20/2015 05:56 AM, Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com The bootz command doesn't work with Linux kernel images on 64-bit ARM. The replacement command with the same interface and functionality is booti. Uggh. Why can't bootz work everywhere, or why can't bootz be an alias to booti on ARM64? Are the command-line parameters different? It'd be really nice to be able to create one boot.scr.uimg file that just works everywhere, and having different command names will scupper that. So, a long while back I asked about maybe adding a bootSOMETHING-THAT-GUESSES-YOUR-FORMAT command to help here. The issue is that bootz means boot an ARM Linux Kernel with the kernel's decompressor that's at the front. It's not even (sadly, arg) what boot an x86 Linux Kernel with the kernel's decompressor that's at the front is, that's zboot. In the kernel (today), there's no desire to add the decompressor arm has to aarch64 and instead leave decompression to the loader (And compression to the user). So we have to handle the Image format that aarch64 uses. Frankly I've always looked at the distro work here as the boot-do-what-I-mean stuff where we hide that the common multi-platform image types aren't popular and just let people boot the normal kernel for their architecture. Ah yes, I guess that's true. A hypothetical universal boot this image function would be nice to enable everywhere. IIRC, bootm does some image format detection (uimage vs. FIT) so perhaps it could just grow the ability to boot anything? I suppose it isn't too hard for a distro to detect ARM vs. ARM64 vs. x86 and select bootz/booti/zboot for those cases, so long as all boards of an architecture are consistent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready
On 3/23/2015 12:38 AM, Andrew Gabbasov wrote: Hi Troy, From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] Sent: Friday, March 20, 2015 9:39 PM To: peng@freescale.com; Gabbasov, Andrew; u-boot@lists.denx.de Cc: Eric Nelson Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready [skipped] Here's another patch that solves the problem a little earlier. It has this disadvantage of being slightly bigger, though it makes the code look better. https://github.com/boundarydevices/u-boot-imx6/commit/c0260ca I have a couple of doubts regarding that patch. First, my personal taste objects to such duplicating of the code (I mean setting of version, ocr, rca, etc fields of mmc structure). If we'll have to change or add anything to these settings, we'll have to make the same change in 2 different place, which is error-prone and extremely inconvenient from maintenance point of view. Second, what about SPI mode? Doesn't this patch skip retrieving of OCR register with a special command for SPI host case (thus setting ocr field incorrectly), if the card comes to ready state with the first attempt? That's a good argument for a subroutine to be doing that work instead of in two places. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] ARM: tegra: rename colibri_t20 board folder
On 03/23/2015 11:28 AM, Marcel Ziswiler wrote: In accordance with our other modules supported by U-Boot and as agreed for Apalis/Colibri T30 get rid of the carrier board in the board folder naming. Please note that this temporarily breaks the build as Kconfig within this folder will require changing as well. Conceptually this series seems fine to me, but I'd recommend squashing some/all of the patches together in order to avoid any intermediate breakage and git bisect issues. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] ARM: tegra: get rid of colibri_t20-common
On 03/23/2015 11:28 AM, Marcel Ziswiler wrote: As a preparatory step to renaming the board folder as well first get rid of the colibri_t20-common after having integrated it into colibri_t20_iris for now. While at it also migrate to using NVIDIA's common.mk magic. Is it possible to separate the removal of colibri_t20-common into a separate commit from the renames, so that the two are lumped together. I'd rather expect this series to have two commits: 1) Remove colibri_t20-common and move the C code into the board file. 2) Everything related to the rename. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Rework the network stack
Hi,
On 23 March 2015 at 13:55, Jörg Krause joerg.krause@embedded.rocks wrote:
Joe, Simon,
On Mo, 2015-03-23 at 10:46 -0600, Simon Glass wrote:
Hi Jörg,
On 22 March 2015 at 14:37, Jörg Krause joerg.krause@embedded.rocks wrote:
Hi Joe,
On Sa, 2015-03-21 at 22:59 -0500, Joe Hershberger wrote:
Hi Jörg,
On Sat, Mar 21, 2015 at 3:33 AM, Jörg Krause
joerg.krause@embedded.rocks
wrote:
Hi all,
there is an issue with the current network stack using netconsole. It's
impossible to use network commands as TFTP inside netconsole, because
they try to run as atomic network commands.
The issue was already reported by Stefano Babic in 2010:
[U-Boot] NetConsole and network API
http://lists.denx.de/pipermail/u-boot/2010-August/075535.html
I worked around this problem here:
http://lists.denx.de/pipermail/u-boot/2012-August/129913.html
I know about this patch, and I understand the problem it tries to
workaround. But it does not work for using netconsole with another
protocol like ping. When for example ping enters the NetLoop() it will
halt the network device.
The problem for this is here:
if (eth_is_on_demand_init() || protocol != NETCONS) {
eth_halt();
...
}
eth_is_on_demand_init() returns correctly with false, because PING !=
NETCONS. But the second expression results in true, because PING !=
NETCONS.
I run into the same problem:
[U-Boot] netconsole: USB Ethernet connection dropping with ping or
tftpboot
http://lists.denx.de/pipermail/u-boot/2015-February/203838.html
I didn't understand what about your case was not able to work given the
workaround I implemented previously. What was different about it?
I have looked at the current network stack. The stack is based on the
concept of atomic network commands. The implementation for netconsole
looks very confusing.
There is no doubt that netconsole is quite confusing as it exists today.
I tried to fix the issue, but it did not work properly.
Sascha Hauer has reimplemented the network stack for Barebox:
http://www.spinics.net/lists/u-boot-v2/msg00914.html
Looking at the current implementation of net.c looks very clean and
well-designed.
Thanks for pointing this out. I hadn't gone to look at the network stack
in
barebox.
What do you think about porting this to U-Boot?
I can look into this. Naturally there are many other changes to u-boot
network stack since the time barebox forked, so I expect such a port to
be
very intensive... most likely a near complete rewrite of Sascha's series,
but I will investigate further.
I had a look at the patches and the code base is not entirely the same.
But maybe we should just stick to the crucial points of the new network
stack:
1) A network device gets initialized when it becomes the current one and
gets brought down when it's not used anymore or prior booting to Linux
so the connection remains active all the time.
My thoughts about this one:
Bringing the device down can be done in eth_unregister(). Initializing
for the current device can be done in eth_current_changed(). What I like
even better is to make eth_current_changed() the sole place for calling
init() and halt(). It would have to be extend to take at least two
parameters, eth_current and new_current. If eth_current is null just
bring up the new device, if new_current is null just bring down the
current device.
2) Replace the NetLoop by a connection list where each protocol uses a
connection to send and receive packets.
This induce to port all protocols to use the new network, of cause.
In my opinion it would be also good to do some clean ups and
restructuring of code. Put more functions into net-utils, is there a
need for eth_init and so on.
Joe has done a lot of work to move U-Boot's network stack over to
driver model. This is now at u-boot-dm/next waiting for the merge
window to open.
The connection list idea does not sound like a hugely complex change.
Are you thinking of trying it out?
I have just noticed today the big series of u-boot-dm patches of Joe. I
will try it out. But before I will start I want to discuss the concept.
What do you think about my thoughts about bringing up and down a network
device?
Joe is the expert here.
With driver model the actual bring-up should be automatic (i.e. it is
probed as soon as it is used).
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config: Define BOOTP client architecture and VCI for ARMv8
On 03/20/2015 11:08 AM, Tom Rini wrote: On Fri, Mar 20, 2015 at 10:22:59AM -0600, Stephen Warren wrote: On 03/20/2015 06:11 AM, Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com Reuse the 32-bit ARM client architecture and identify ARMv8 specifically by setting the BOOTP VCI string. Is there a newer version of https://www.rfc-editor.org/rfc/rfc4578.txt that says what this value should be? Even 32-bit ARM isn't in that document, so I'm not sure where 0x100 came from. I wonder if 0x100 is treated by the PXE implementations as set but invalid, don't use. Digging into some PXE servers would shed some light here. I can't actually find any use of this in ISC DHCPd. At most, it might be a value that user config files can match against if they want. I guess it's not worth worrying about? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Setting up MAC address for eth drivers
Hi, On 17 March 2015 at 11:47, Michal Simek michal.si...@xilinx.com wrote: Hi Joe, On 03/17/2015 06:21 PM, Joe Hershberger wrote: Hi Michal, On Tue, Mar 17, 2015 at 11:57 AM, Michal Simek michal.si...@xilinx.com wrote: Hi Joe, On 03/17/2015 04:56 PM, Joe Hershberger wrote: Hi Michal, On Fri, Mar 13, 2015 at 7:25 AM, Michal Simek michal.si...@xilinx.com wrote: Hi, I have a question regarding setting mac address for drivers. Drivers setting up write_hwaddr via eth_write_hwaddr via eth_initialize which is called from common/board_r.c. This is because on at least ARM kernels, the MAC is passed via the MAC's filter registers. Because of this, we need to write hwaddr even before the MAC is started. But then there are some drivers(macb, designware, altera_tse) which also calls mac setup from dev-init which has side effect for example when you setup CONFIG_ENV_OVERWRITE and change mac address you can directly use it. This is probably a work-around for a shortcoming of the net/eth.c not calling write_hwaddr() when the env MAC changes. It already updates the registers used by the network stack, so presumably if those MACs are filtering incoming traffic based on the register as expected, changing the MAC after boot without rewriting that register would cause all traffic to not be returned. It also means if there is intention to call hwaddr from dev-init that for the first packet mac address is setup twice - in eth core init and then before every driver use. The design of the network stack assumes the MAC is started each time a network operation is requested and stopped when done. As for the setting of the hwaddr, we should check if it changed. I am asking this question because I would like to know the right flow for eth mac setup. If it is set ethaddr xx saveenv reset eth with new mac or if set ethaddr eth with new mac should work The second approach looks reasonable when ethaddr is not set at all but then at least our driver needs to be fixed to support this feature. I think the second should work ideally, but we need to add a call to eth_init() if the ethaddr in the env changes and set it again if so. We should also remove the calls from the drivers you identified since the framework will now do it. Does it mean that you are going to write that code for it? Yes... I'll write it, but it needs to be on top of the DM_ETH patches, so I'll probably wait until that's pulled. That's fine. This is in u-boot-dm/next now. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] kbuild: remove *_felconfig target
On 13 March 2015 at 03:08, Masahiro Yamada yamada.masah...@socionext.com wrote: This target was added by commit cbdd9a9737cc (sunxi: kconfig: Add %_felconfig rule to enable FEL build of sunxi platforms.). At that time, U-Boot used separate .config files for U-Boot proper and SPL. I understood the pain to modify both .config and spl/.config. Now, we have switched to single .config configuration. It seems acceptable to run make menuconfig or friends to enable CONFIG_SPL_FEL, as we do for other CONFIGs. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com Cc: Ian Campbell i...@hellion.org.uk Cc: Hans de Goede hdego...@redhat.com --- scripts/multiconfig.sh | 12 1 file changed, 12 deletions(-) Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] power: pfuze100 correct macro definition
Hello Peng,
On 03/23/2015 08:34 AM, Peng Fan wrote:
Correct the macro PFUZE100_SW1ABC_SETP definition. We should
add parenthese for 'x'.
Signed-off-by: Peng Fan peng@freescale.com
---
include/power/pfuze100_pmic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/power/pfuze100_pmic.h b/include/power/pfuze100_pmic.h
index 07199b4..9c749ed 100644
--- a/include/power/pfuze100_pmic.h
+++ b/include/power/pfuze100_pmic.h
@@ -61,7 +61,7 @@ enum {
* Buck Regulators
*/
-#define PFUZE100_SW1ABC_SETP(x)((x - 3000) / 250)
+#define PFUZE100_SW1ABC_SETP(x)(((x) - 3000) / 250)
/* SW1A/B/C Output Voltage Configuration */
#define SW1x_0_300V 0
Acked-by: Przemyslaw Marczak p.marc...@samsung.com
best regards,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Kconfig: i2c: add entry for driver-model software i2c
Hi Przemyslaw,
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Mike Frysinger vap...@gentoo.org
Cc: Simon Glass s...@chromium.org
Cc: Heiko Schocher h...@denx.de
---
drivers/i2c/Kconfig | 43 +++
1 file changed, 43 insertions(+)
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 0a52ed9..dd7eb3c 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -13,6 +13,49 @@ config DM_I2C_COMPAT
to convert all code for a board in a single commit. It
should not be enabled for any board in an official release.
+config DM_I2C_SOFT
+ bool Enable Driver Model for Software I2C Driver
+ depends on DM_I2C
+ help
+ Enable the i2c bus driver emulation by using GPIO.
+ The bus configuration is given by the device-tree, like
below. +
+ /* First, define the alias number to have continuous bus
numbering */
+ aliases {
+ [...]
+ i2c5 = /i2c@1350;
+ i2c6 = /soft-i2c@1;
+ [...]
+ }
+
+ /* And next define the basic bus attributes */
+ soft-i2c@1 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = soft-i2c;
+ clock-frequency = 5;
+ /* Define the proper GPIO pins */
+ clock-pin = gpa0 0 GPIO_ACTIVE_HIGH;
+ data-pin = gpa0 1 GPIO_ACTIVE_HIGH;
+
+ /* Optionally, define some driver node (bus child) */
+ somedev@0x44 {
+ compatible = somedev;
+ reg = 0x44;
+ [...]
+ };
+ }
+
+ The device can be accessed by the i2c command:
+ # i2c dev 8 (bus number set by alias)
+ # i2c probe 0x44(address is optionally)
+ # i2c md 0x44 0x0 (dump dev registers at
address 0x0)
+ # Valid chip addresses: 0x44 (success!)
+ ...
+
+ Driving the bus lines is done by dm gpio calls in the
preprocessor
+ macros. Each, can be redefined by the user.
+
config SYS_I2C_UNIPHIER
bool UniPhier I2C driver
depends on ARCH_UNIPHIER DM_I2C
Reviewed-by: Lukasz Majewski l.majew...@samsung.com
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] question about software i2c multi instance
Hello Bo,
On 03/23/2015 09:36 AM, Bo Shen wrote:
Hi Lukasz,
On 03/23/2015 04:28 PM, Lukasz Majewski wrote:
Hi Bo,
Hi Heiko,
After check the software i2c code, I found it can not support
multi instances, although it has I2C_SOFT_DECLARATIONS2,
I2C_SOFT_DECLARATIONS3, I2C_SOFT_DECLARATIONS4.
Because, when do GPIO operation, there is only one pair of
CONFIG_SOFT_I2C_GPIO_SCL and CONFIG_SOFT_I2C_GPIO_SDA.
So, if want to support multi instances, it needs to extend the
GPIO configuration for SCL/SDA, am I right?
Some time ago we had a similar problem with SW I2C code. Please look
into Samsung's trats board implementation.
However, such approach might be outdated, since Przemek is working on
porting this functionality to device model:
https://patchwork.ozlabs.org/patch/448460/
Thanks for your information.
Now, I just do it as following to make it work. For next step, I will
try to switch to use DM.
---8---
diff --git a/drivers/i2c/soft_i2c.c b/drivers/i2c/soft_i2c.c
index db9b402..b9cfbb8 100644
--- a/drivers/i2c/soft_i2c.c
+++ b/drivers/i2c/soft_i2c.c
@@ -126,6 +126,13 @@ DECLARE_GLOBAL_DATA_PTR;
#define PRINTD(fmt,args...)
#endif
+#ifdef I2C_READ_ADAP
+static int soft_i2c_read_sda(void)
+{
+ I2C_READ_ADAP;
+}
+#endif
+
/*---
* Local functions
*/
@@ -256,7 +263,11 @@ static int write_byte(uchar data)
I2C_SCL(1);
I2C_DELAY;
I2C_DELAY;
+#ifdef I2C_READ_ADAP
+ nack = soft_i2c_read_sda();
+#else
nack = I2C_READ;
+#endif
I2C_SCL(0);
I2C_DELAY;
I2C_ACTIVE;
@@ -286,7 +297,11 @@ static uchar read_byte(int ack)
I2C_SCL(1);
I2C_DELAY;
data = 1;
+#ifdef I2C_READ_ADAP
+ data |= soft_i2c_read_sda();
+#else
data |= I2C_READ;
+#endif
I2C_DELAY;
}
send_ack(ack);
---8---
Thanks again.
Best Regards,
Bo Shen
Please look into the Trats2 board code in:
board/samsung/trats2/trats2.c lines 130-145
include/configs/trats2.h lines 180-185
It doesn't require i2c driver modifications. But anyway I recommend to
use the code of my patches, which Lukasz mentioned.
Best regards,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] ARM: DRA7XX: Add config file for Android with fastboot support
Hi Dileep,
- Added new configuration for Android fastboot
- This is based on following patch modified accordingly
http://git.omapzoom.org/?p=repo/u-boot.git;a=commit;h=b2e04f92b5d91c708b6fd6b79d2266966ac51f4b
Signed-off-by: Angela Stegmaier angelaba...@ti.com
Signed-off-by: Dileep Katta dileep.ka...@linaro.org
---
Changes in v2:
- Merged the header file content to existing dra7xx_evm.h to
avoid duplication
- Removed unnecessary definitions as per comments
board/ti/dra7xx/MAINTAINERS | 1 +
configs/dra7xx_evm_android_defconfig | 5 +
include/configs/dra7xx_evm.h | 30
++ 3 files changed, 36 insertions(+)
create mode 100644 configs/dra7xx_evm_android_defconfig
diff --git a/board/ti/dra7xx/MAINTAINERS b/board/ti/dra7xx/MAINTAINERS
index 5ec6769..1b5ae71 100644
--- a/board/ti/dra7xx/MAINTAINERS
+++ b/board/ti/dra7xx/MAINTAINERS
@@ -6,3 +6,4 @@ F:include/configs/dra7xx_evm.h
F: configs/dra7xx_evm_defconfig
F: configs/dra7xx_evm_qspiboot_defconfig
F: configs/dra7xx_evm_uart3_defconfig
+F: configs/dra7xx_evm_android_defconfig
diff --git a/configs/dra7xx_evm_android_defconfig
b/configs/dra7xx_evm_android_defconfig new file mode 100644
index 000..5fdce85
--- /dev/null
+++ b/configs/dra7xx_evm_android_defconfig
@@ -0,0 +1,5 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS=CONS_INDEX=1,DRA7XX_ANDROID
++S:CONFIG_ARM=y
++S:CONFIG_OMAP54XX=y
++S:CONFIG_TARGET_DRA7XX_EVM=y
diff --git a/include/configs/dra7xx_evm.h
b/include/configs/dra7xx_evm.h index dee2b11..dd20e08 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -43,6 +43,16 @@
uuid_disk=${uuid_gpt_disk}; \
name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}
+#ifdef CONFIG_DRA7XX_ANDROID
+/* Fastboot */
+#define CONFIG_CMD_FASTBOOT
+#define CONFIG_ANDROID_BOOT_IMAGE
+#define CONFIG_USB_FASTBOOT_BUF_ADDRCONFIG_SYS_LOAD_ADDR
+#define CONFIG_USB_FASTBOOT_BUF_SIZE0x2F00
+#define CONFIG_FASTBOOT_FLASH
+#define CONFIG_FASTBOOT_FLASH_MMC_DEV 1
+#endif
+
#include configs/ti_omap5_common.h
/* Enhance our eMMC support / experience. */
@@ -115,7 +125,11 @@
#define CONFIG_SPL_SPI_SUPPORT
#define CONFIG_SPL_SPI_LOAD
#define CONFIG_SPL_SPI_FLASH_SUPPORT
+#ifdef CONFIG_DRA7XX_ANDROID
+#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x8
+#else
#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x4
+#endif
#define CONFIG_SUPPORT_EMMC_BOOT
@@ -130,6 +144,22 @@
#define CONFIG_OMAP_USB_PHY
#define CONFIG_OMAP_USB2PHY2_HOST
+/* USB GADGET */
+#define CONFIG_USB_GADGET
+#define CONFIG_MUSB_GADGET
+#define CONFIG_MUSB_PIO_ONLY
+#define CONFIG_USBDOWNLOAD_GADGET
+#define CONFIG_USB_GADGET_VBUS_DRAW 2
+#define CONFIG_G_DNL_MANUFACTURER Texas Instruments
+#ifdef CONFIG_CMD_FASTBOOT
+#define CONFIG_G_DNL_VENDOR_NUM 0x0451
+#define CONFIG_G_DNL_PRODUCT_NUM 0xd022
+#else
+#define CONFIG_G_DNL_VENDOR_NUM 0x0403
+#define CONFIG_G_DNL_PRODUCT_NUM 0xBD00
+#endif
+#define CONFIG_USB_GADGET_DUALSPEED
+
/* SATA */
#define CONFIG_BOARD_LATE_INIT
#define CONFIG_CMD_SCSI
Reviewed-by: Lukasz Majewski l.majew...@samsung.com
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] question about software i2c multi instance
Hi Przemyslaw Marczak, On 03/23/2015 04:47 PM, Przemyslaw Marczak wrote: Please look into the Trats2 board code in: board/samsung/trats2/trats2.c lines 130-145 include/configs/trats2.h lines 180-185 It doesn't require i2c driver modifications. But anyway I recommend to use the code of my patches, which Lukasz mentioned. Thanks for your information. I will try this method. Thanks again. Best regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com Best Regards, Bo shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] multi-image uImage with fitImage
Hi all,
I am currently attempting to port my combined uImage and ramdisk image +
dtb over to the fitImage format. I am creating a linux kernel + ramdisk
with buildroot and dt blob with buildroot. The .its I am using to create a
fitImage is below:
/dts-v1/;
/ {
description = Linux kernel;
#address-cells = 1;
images {
kernel@1 {
description = Linux kernel;
data = /incbin/(/tftpboot/uImage);
arch = arm;
os = linux;
type = multi;
compression = none;
load = 0x89008000;
entry = 0x89008000;
};
fdt@1 {
description = Flattened Device Tree blob;
data = /incbin/(/tftpboot/arm.dtb);
type = flat_dt;
arch = arm;
compression = none;
};
};
configurations {
default = conf@1;
conf@1 {
description = Boot Linux kernel;
kernel = kernel@1;
fdt = fdt@1;
};
};
};
After tftp'ing the .itb over to address 0x8900 and running bootm, I get:
# bootm
## Loading kernel from FIT Image at 8900 ...
Using 'conf@1' configuration
Trying 'kernel@1' kernel subimage
Description: Linux kernel
Type: Multi-File Image
Compression: uncompressed
Data Start: 0x89d0
Data Size:28604352 Bytes = 27.3 MiB
Verifying Hash Integrity ... OK
No Linux ARM Kernel Image Image
ERROR: can't get kernel image!
The images work perfectly before I try to combine them into a fitImage.
Is there a special configuration option for multi-file (combined
ramdisk-kernel) images in fitImage?
Regards,
George.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fix OCR Polling
Hi Peng, From: Peng Fan [mailto:peng@freescale.com] Sent: Saturday, March 21, 2015 1:34 PM To: Gabbasov, Andrew; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] mmc: fix OCR Polling [skipped] After this patch, if the busy flag is indeed already set (so that the loop body is not executed), and it is not an SPI case (mmc_host_is_spi(mmc) is false), the cmd structure (which is local to mmc_complete_op_cond() function) is left uninitialized, and using cmd.response[0] later in the function becomes incorrect. And the OCR register value and the high capacity flag may be set incorrectly. Yeah. you are right. Maybe the following piece of code should be added to replace mmc-ocr = cmd.response[0]: if (mmc_host_is_spi(mmc)) mmc-ocr = cmd.response[0]; else mmc-ocr = mmc-op_cond_response; Thanks for correcting me. Well, there can be several ways to correct that. The easiest would be something similar to what you propose, but, just to avoid extra if, we could add mmc-op_cond_response = cmd.response[0]; to the end of existing if(mmc_host_is_spi(mmc)) and change mmc-ocr = cmd.response[0]; to mmc-ocr = mmc-op_cond_response; at the end of function. Since op_cond_response should be already set from the function beginning, this can be used immediately. And, going further, since op_cond_response is actually the same contents as mmc-ocr, we could combine them and use mmc-ocr at once, from the beginning of polling loops. This is a little more complex, but makes the code cleaner. This is what is done in one of other patches in my series ;-) Thanks. Best regards, Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fastboot: check for alias when looking up partition by name
Hi Steve, Hi Lukasz, On 15-03-20 12:50 AM, Lukasz Majewski wrote: Hi Steve, On 15-03-12 10:17 AM, Michael Scott wrote: On 03/12/2015 09:23 AM, Steve Rae wrote: [... snip ...] An interesting feature (which seems unnecessary to me...) However, A bit of background: We are using fastboot support on Nvidia Jetson-TK1 platform where a GPT limitation sets partition names to 3 letters. IE: LNX = boot, APP = system and UDA = userdata. OK -- then this patch makes much more sense! - so when the user performs mmc part, (I'm assuming it will list the 3 letter names), then they perform fastboot flash LNX boot.bin (which makes sense to me) - or they can setup these aliases and perform fastboot flash boot boot.bin (I would probably stick with the former myself...) Thanks, Steve To present a normal fastboot experience to users, we use this patch. Acked-by: Steve Rae s...@broadcom.com Thank you for the Ack! Are there more comments for this patch? No - the feature is OK (personally - I would use the names that match what mmc part displays; so I don't think that I would create any aliases) Acked-by: Steve Rae s...@broadcom.com Applied to u-boot-dfu tree. Thanks! -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ci_udc: fix warnings on 64-bit builds
Hi Rob,
Change addresses to unsigned long to be compatible with 64-bit builds.
Regardless of fixing warnings, the device is still only 32-bit
capable.
Signed-off-by: Rob Herring r...@kernel.org
Cc: Łukasz Majewski l.majew...@samsung.com
Cc: Marek Vasut ma...@denx.de
---
drivers/usb/gadget/ci_udc.c | 42
+- 1 file changed, 21
insertions(+), 21 deletions(-)
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index b0ef35e..a231abf 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -160,8 +160,8 @@ static struct ept_queue_item *ci_get_qtd(int
ep_num, int dir_in) static void ci_flush_qh(int ep_num)
{
struct ept_queue_head *head = ci_get_qh(ep_num, 0);
- const uint32_t start = (uint32_t)head;
- const uint32_t end = start + 2 * sizeof(*head);
+ const unsigned long start = (unsigned long)head;
+ const unsigned long end = start + 2 * sizeof(*head);
flush_dcache_range(start, end);
}
@@ -175,8 +175,8 @@ static void ci_flush_qh(int ep_num)
static void ci_invalidate_qh(int ep_num)
{
struct ept_queue_head *head = ci_get_qh(ep_num, 0);
- uint32_t start = (uint32_t)head;
- uint32_t end = start + 2 * sizeof(*head);
+ unsigned long start = (unsigned long)head;
+ unsigned long end = start + 2 * sizeof(*head);
invalidate_dcache_range(start, end);
}
@@ -190,8 +190,8 @@ static void ci_invalidate_qh(int ep_num)
static void ci_flush_qtd(int ep_num)
{
struct ept_queue_item *item = ci_get_qtd(ep_num, 0);
- const uint32_t start = (uint32_t)item;
- const uint32_t end = start + 2 * ILIST_ENT_SZ;
+ const unsigned long start = (unsigned long)item;
+ const unsigned long end = start + 2 * ILIST_ENT_SZ;
flush_dcache_range(start, end);
}
@@ -205,8 +205,8 @@ static void ci_flush_qtd(int ep_num)
static void ci_invalidate_qtd(int ep_num)
{
struct ept_queue_item *item = ci_get_qtd(ep_num, 0);
- const uint32_t start = (uint32_t)item;
- const uint32_t end = start + 2 * ILIST_ENT_SZ;
+ const unsigned long start = (unsigned long)item;
+ const unsigned long end = start + 2 * ILIST_ENT_SZ;
invalidate_dcache_range(start, end);
}
@@ -308,8 +308,8 @@ static int ci_ep_disable(struct usb_ep *ep)
static int ci_bounce(struct ci_req *ci_req, int in)
{
struct usb_request *req = ci_req-req;
- uint32_t addr = (uint32_t)req-buf;
- uint32_t hwaddr;
+ unsigned long addr = (unsigned long)req-buf;
+ unsigned long hwaddr;
uint32_t aligned_used_len;
/* Input buffer address is not aligned. */
@@ -343,7 +343,7 @@ align:
memcpy(ci_req-hw_buf, req-buf, req-length);
flush:
- hwaddr = (uint32_t)ci_req-hw_buf;
+ hwaddr = (unsigned long)ci_req-hw_buf;
aligned_used_len = roundup(req-length, ARCH_DMA_MINALIGN);
flush_dcache_range(hwaddr, hwaddr + aligned_used_len);
@@ -353,8 +353,8 @@ flush:
static void ci_debounce(struct ci_req *ci_req, int in)
{
struct usb_request *req = ci_req-req;
- uint32_t addr = (uint32_t)req-buf;
- uint32_t hwaddr = (uint32_t)ci_req-hw_buf;
+ unsigned long addr = (unsigned long)req-buf;
+ unsigned long hwaddr = (unsigned long)ci_req-hw_buf;
uint32_t aligned_used_len;
if (in)
@@ -388,13 +388,13 @@ static void ci_ep_submit_next_request(struct
ci_ep *ci_ep) len = ci_req-req.length;
item-info = INFO_BYTES(len) | INFO_ACTIVE;
- item-page0 = (uint32_t)ci_req-hw_buf;
- item-page1 = ((uint32_t)ci_req-hw_buf 0xf000) +
0x1000;
- item-page2 = ((uint32_t)ci_req-hw_buf 0xf000) +
0x2000;
- item-page3 = ((uint32_t)ci_req-hw_buf 0xf000) +
0x3000;
- item-page4 = ((uint32_t)ci_req-hw_buf 0xf000) +
0x4000;
+ item-page0 = (unsigned long)ci_req-hw_buf;
+ item-page1 = ((unsigned long)ci_req-hw_buf 0xf000) +
0x1000;
+ item-page2 = ((unsigned long)ci_req-hw_buf 0xf000) +
0x2000;
+ item-page3 = ((unsigned long)ci_req-hw_buf 0xf000) +
0x3000;
+ item-page4 = ((unsigned long)ci_req-hw_buf 0xf000) +
0x4000;
- head-next = (unsigned) item;
+ head-next = (unsigned long)item;
head-info = 0;
/*
@@ -422,7 +422,7 @@ static void ci_ep_submit_next_request(struct
ci_ep *ci_ep)
* can use the other to transmit the extra
zero-length packet. */
struct ept_queue_item *other_item = ci_get_qtd(num,
0);
- item-next = (unsigned)other_item;
+ item-next = (unsigned long)other_item;
item = other_item;
item-info = INFO_ACTIVE;
}
@@ -772,7 +772,7 @@ static int ci_pullup(struct usb_gadget *gadget,
int is_on) writel(USBCMD_ITC(MICRO_8FRAME) | USBCMD_RST,
udc-usbcmd); udelay(200);
- writel((unsigned)controller.epts, udc-epinitaddr);
+
Re: [U-Boot] [PATCH 1/3] dm: i2c soft: enable driver model for software i2c driver
Hi Przemyslaw,
This change adds driver model support to software emulated
i2c bus driver. To bind the driver, proper device-tree node
must be defined, with the following attributes:
- alias: to keep proper bus order
- compatible: 'soft-i2c'
- clock-frequency [Hz]
- clock-pin, data-pin: gpio phandles
/* Define the alias number to keep bus numbering order */
aliases {
[...]
i2c5 = /i2c@1350;
i2c6 = /soft-i2c@1;
[...]
};
/* Define the basic bus attributes */
soft-i2c@1 {
#address-cells = 1;
#size-cells = 0;
compatible = soft-i2c;
clock-frequency = 5;
/* Define the proper GPIO pins */
clock-pin = gpa0 0 GPIO_ACTIVE_HIGH;
data-pin = gpa0 1 GPIO_ACTIVE_HIGH;
/* Optionally, define some driver node (bus child) */
somedev@0x44 {
compatible = somedev;
reg = 0x44;
[...]
};
};
The device can be accessed by the i2c command:
i2c dev 8 (bus number set by alias)
i2c probe 0x44(address is optionally)
i2c md 0x44 0x0 (dump dev registers at address 0x0)
Valid chip addresses: 0x44 (success!)
...
The previous driver functionality stays unchanged. Driving the bus
lines is done by dm gpio calls in the preprocessor macros. Each, can
be redefined by the user as previous.
Tested on Trats2 and Odroid U3.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Mike Frysinger vap...@gentoo.org
Cc: Simon Glass s...@chromium.org
Cc: Heiko Schocher h...@denx.de
---
drivers/i2c/Makefile | 1 +
drivers/i2c/soft_i2c.c | 410
+++-- 2 files changed,
400 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 774bc94..7039b6d 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -6,6 +6,7 @@
#
obj-$(CONFIG_DM_I2C) += i2c-uclass.o
obj-$(CONFIG_DM_I2C_COMPAT) += i2c-uclass-compat.o
+obj-$(CONFIG_DM_I2C_SOFT) += soft_i2c.o
obj-$(CONFIG_SYS_I2C_ADI) += adi_i2c.o
obj-$(CONFIG_I2C_MV) += mv_i2c.o
diff --git a/drivers/i2c/soft_i2c.c b/drivers/i2c/soft_i2c.c
index db9b402..7afae0b 100644
--- a/drivers/i2c/soft_i2c.c
+++ b/drivers/i2c/soft_i2c.c
@@ -1,4 +1,7 @@
/*
+ * (C) Copyright 2015, Samsung Electronics
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
* (C) Copyright 2009
* Heiko Schocher, DENX Software Engineering, h...@denx.de.
* Changes for multibus/multiadapter I2C support.
@@ -14,6 +17,11 @@
*/
#include common.h
+#include errno.h
+#include dm.h
+#include i2c.h
+#include div64.h
+#include asm/gpio.h
#ifdef CONFIG_MPC8260 /* only valid
for MPC8260 */ #include ioports.h
#include asm/io.h
@@ -32,11 +40,9 @@
#if defined(CONFIG_MPC852T) || defined(CONFIG_MPC866)
#include asm/io.h
#endif
-#include i2c.h
+#if defined(CONFIG_SYS_I2C)
#if defined(CONFIG_SOFT_I2C_GPIO_SCL)
-# include asm/gpio.h
-
# ifndef I2C_GPIO_SYNC
# define I2C_GPIO_SYNC
# endif
@@ -85,6 +91,7 @@
# endif
#endif
+#endif
/* #define DEBUG_I2C */
@@ -109,6 +116,65 @@ DECLARE_GLOBAL_DATA_PTR;
#define CONFIG_SYS_I2C_SOFT_SLAVE CONFIG_SYS_I2C_SLAVE
#endif
+/* DM SOFT I2C */
+#ifdef CONFIG_DM_I2C_SOFT
+# ifndef I2C_GPIO_SYNC
+# define I2C_GPIO_SYNC(gpio)
+# endif
+
+# ifndef I2C_INIT
+# define I2C_INIT(scl, sda) \
+ do { } while (0)
+# endif
+
+# ifndef I2C_ACTIVE
+# define I2C_ACTIVE(sda) \
+ do { } while (0)
+# endif
+
+# ifndef I2C_TRISTATE
+# define I2C_TRISTATE(sda) \
+ do { } while (0)
+# endif
+
+# ifndef I2C_READ
+# define I2C_READ(sda) dm_gpio_get_value(sda);
+# endif
+
+# ifndef I2C_SDA
+# define I2C_SDA(sda, bit) \
+ do { \
+ if (bit) { \
+ sda-flags = ~GPIOD_IS_OUT; \
+ sda-flags |= GPIOD_IS_IN; \
+ dm_gpio_set_dir(sda); \
+ } else { \
+ sda-flags = ~GPIOD_IS_IN; \
+ sda-flags |= GPIOD_IS_OUT; \
+ dm_gpio_set_dir(sda); \
+ dm_gpio_set_value(sda, 0); \
+ } \
+ I2C_GPIO_SYNC(sda); \
+ } while (0)
+# endif
+
+# ifndef I2C_SCL
+# define I2C_SCL(scl, bit) \
+ do { \
+ scl-flags = ~GPIOD_IS_IN; \
+ scl-flags |= GPIOD_IS_OUT; \
+ dm_gpio_set_dir(scl); \
+ dm_gpio_set_value(scl, bit); \
+ I2C_GPIO_SYNC(scl); \
+ } while (0)
+# endif
+
+# ifndef I2C_DELAY
+# define I2C_DELAY(us) udelay(us) /* 1/4 I2C clock duration
*/ +# endif
+
+#endif /* CONFIG_DM_I2C_SOFT */
+
/*---
* Definitions
*/
@@ -117,7 +183,6 @@ DECLARE_GLOBAL_DATA_PTR;
#define I2C_ACK
[U-Boot] [PATCH 3/5] vexpress64: remove board late init, use smhload
This removes the kludgy late board init from the FVP simulator
version of Versatile Express 64bit (ARMv8), and replace it with
a default boot command using the new smhload command to load
the files using semihosting. Tested on the Foundation Model.
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
board/armltd/vexpress64/vexpress64.c | 96
include/configs/vexpress_aemv8a.h| 18 ---
2 files changed, 10 insertions(+), 104 deletions(-)
diff --git a/board/armltd/vexpress64/vexpress64.c
b/board/armltd/vexpress64/vexpress64.c
index de6286435d97..876cb678eb03 100644
--- a/board/armltd/vexpress64/vexpress64.c
+++ b/board/armltd/vexpress64/vexpress64.c
@@ -11,7 +11,6 @@
#include netdev.h
#include asm/io.h
#include linux/compiler.h
-#include asm/semihosting.h
DECLARE_GLOBAL_DATA_PTR;
@@ -33,101 +32,6 @@ void reset_cpu(ulong addr)
{
}
-#ifdef CONFIG_BOARD_LATE_INIT
-int board_late_init(void)
-{
-#ifdef CONFIG_SEMIHOSTING
- /*
-* Please refer to doc/README.semihosting for a more complete
-* description.
-*
-* We require that the board include file defines these env variables:
-* - kernel_name
-* - kernel_addr_r
-* - initrd_name
-* - initrd_addr_r
-* - fdt_name
-* - fdt_addr_r
-*
-* For the fdt chosen startup macro, this code will then define:
-* - initrd_end (based on initrd_addr_r plus actual initrd_size)
-*
-* We will then load the kernel, initrd, and fdt into the specified
-* locations in memory in a similar way that the ATF fastmodel code
-* uses semihosting calls to load other boot stages and u-boot itself.
-*/
-
- /* Env variable strings */
- char *kernel_name = getenv(kernel_name);
- char *kernel_addr_str = getenv(kernel_addr_r);
- char *initrd_name = getenv(initrd_name);
- char *initrd_addr_str = getenv(initrd_addr_r);
- char *fdt_name = getenv(fdt_name);
- char *fdt_addr_str = getenv(fdt_addr_r);
- char initrd_end_str[64];
-
- /* Actual addresses converted from env variables */
- void *kernel_addr_r;
- void *initrd_addr_r;
- void *fdt_addr_r;
-
- /* Actual initrd base and size */
- unsigned long initrd_base;
- unsigned long initrd_size;
-
- /* Space available */
- int avail;
-
- /* Make sure the environment variables needed are set */
- if (!(kernel_addr_str initrd_addr_str fdt_addr_str)) {
- printf(%s: Define {kernel/initrd/fdt}_addr_r\n, __func__);
- return -1;
- }
- if (!(kernel_name initrd_name fdt_name)) {
- printf(%s: Define {kernel/initrd/fdt}_name\n, __func__);
- return -1;
- }
-
- /* Get exact initrd_size */
- initrd_size = smh_len(initrd_name);
- if (initrd_size == -1) {
- printf(%s: Can't get file size for \'%s\'\n, __func__,
- initrd_name);
- return -1;
- }
-
- /* Set initrd_end */
- initrd_base = simple_strtoul(initrd_addr_str, NULL, 16);
- initrd_addr_r = (void *)initrd_base;
- sprintf(initrd_end_str, 0x%lx, initrd_base + initrd_size - 1);
- setenv(initrd_end, initrd_end_str);
-
- /* Load kernel to memory */
- fdt_addr_r = (void *)simple_strtoul(fdt_addr_str, NULL, 16);
- kernel_addr_r = (void *)simple_strtoul(kernel_addr_str, NULL, 16);
-
- /*
-* The kernel must be lower in memory than fdt and loading the
-* kernel must not trample the fdt or vice versa.
-*/
- avail = fdt_addr_r - kernel_addr_r;
- if (avail 0) {
- printf(%s: fdt must be after kernel\n, __func__);
- return -1;
- }
- smh_load(kernel_name, kernel_addr_r, avail, 1);
-
- /* Load fdt to memory */
- smh_load(fdt_name, fdt_addr_r, 0x2, 1);
-
- /* Load initrd to memory */
- smh_load(initrd_name, initrd_addr_r, initrd_size, 1);
-
-#endif /* CONFIG_SEMIHOSTING */
- return 0;
-}
-#endif /* CONFIG_BOARD_LATE_INIT */
-
/*
* Board specific ethernet initialization routine.
*/
diff --git a/include/configs/vexpress_aemv8a.h
b/include/configs/vexpress_aemv8a.h
index e6fc2aeea2b8..cda89d8ca814 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -15,7 +15,6 @@
#ifndef CONFIG_SEMIHOSTING
#error CONFIG_TARGET_VEXPRESS64_BASE_FVP requires CONFIG_SEMIHOSTING
#endif
-#define CONFIG_BOARD_LATE_INIT
#define CONFIG_ARMV8_SWITCH_TO_EL1
#endif
@@ -228,11 +227,11 @@
#elif CONFIG_TARGET_VEXPRESS64_BASE_FVP
#define CONFIG_EXTRA_ENV_SETTINGS \
kernel_name=uImage\0 \
- kernel_addr_r=0x8000\0\
+ kernel_addr=0x8000\0
[U-Boot] [PATCH 5/5] vexpress64: cut config and defaults for unclear variant
This variant that is neither FVP / Base Model or Juno Versatile Express 64bit is confusing. Get rid of it unless someone can point out what machine that really is. Seems to be an evolutional artifact in the config base. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- board/armltd/vexpress64/Kconfig | 13 - configs/vexpress_aemv8a_defconfig | 3 --- include/configs/vexpress_aemv8a.h | 28 3 files changed, 4 insertions(+), 40 deletions(-) delete mode 100644 configs/vexpress_aemv8a_defconfig diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig index 7d5e7bee8b9a..f5693aebacc5 100644 --- a/board/armltd/vexpress64/Kconfig +++ b/board/armltd/vexpress64/Kconfig @@ -1,16 +1,3 @@ -if TARGET_VEXPRESS64_AEMV8A - -config SYS_BOARD - default vexpress64 - -config SYS_VENDOR - default armltd - -config SYS_CONFIG_NAME - default vexpress_aemv8a - -endif - if TARGET_VEXPRESS64_BASE_FVP config SYS_BOARD diff --git a/configs/vexpress_aemv8a_defconfig b/configs/vexpress_aemv8a_defconfig deleted file mode 100644 index 9f4b87655613.. --- a/configs/vexpress_aemv8a_defconfig +++ /dev/null @@ -1,3 +0,0 @@ -CONFIG_ARM=y -CONFIG_TARGET_VEXPRESS64_AEMV8A=y -CONFIG_DEFAULT_DEVICE_TREE=vexpress64 diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index cda89d8ca814..027c7d1555ba 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -20,14 +20,6 @@ #define CONFIG_REMAKE_ELF -#if !defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP) \ -!defined(CONFIG_TARGET_VEXPRESS64_JUNO) -/* Base FVP and Juno not using GICv3 yet */ -#define CONFIG_GICV3 -#endif - -/*#define CONFIG_ARMV8_SWITCH_TO_EL1*/ - #define CONFIG_SUPPORT_RAW_INITRD /* Cache Definitions */ @@ -46,8 +38,7 @@ #define CONFIG_SYS_TEXT_BASE 0xe000 #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x7fff0) #else -#define CONFIG_SYS_TEXT_BASE 0x8000 -#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x7fff0) +#error Unknown board variant #endif /* Flat Device Tree Definitions */ @@ -117,10 +108,9 @@ #define GICD_BASE (0x2C01) #define GICC_BASE (0x2C02f000) #else -#define GICD_BASE (0x2C001000) -#define GICC_BASE (0x2C002000) -#endif +#error Unknown board variant #endif +#endif /* !CONFIG_GICV3 */ #define CONFIG_SYS_MEMTEST_START V2M_BASE #define CONFIG_SYS_MEMTEST_END (V2M_BASE + 0x8000) @@ -249,17 +239,7 @@ #define CONFIG_BOOTDELAY 1 #else - -#define CONFIG_EXTRA_ENV_SETTINGS \ - kernel_addr_r=0x8000\0\ - initrd_addr_r=0x8800\0\ - fdt_addr_r=0x8300\0 \ - fdt_high=0xa000\0 - -#define CONFIG_BOOTARGSconsole=ttyAMA0,115200n8 root=/dev/ram0 -#define CONFIG_BOOTCOMMAND bootm $kernel_addr_r \ - $initrd_addr_r:$initrd_size $fdt_addr_r -#define CONFIG_BOOTDELAY -1 +#error Unknown board variant #endif /* Do not preserve environment */ -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] armv8: semihosting: do not inline trap call
The semihosting trap call does not like being inlined, probably
because that will mean register reordering screwing up the return
value in r0, so tag this function noinline.
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
arch/arm/lib/semihosting.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/lib/semihosting.c b/arch/arm/lib/semihosting.c
index fd6d8573f560..d3f724b726e1 100644
--- a/arch/arm/lib/semihosting.c
+++ b/arch/arm/lib/semihosting.c
@@ -26,7 +26,7 @@
/*
* Call the handler
*/
-static long smh_trap(unsigned int sysnum, void *addr)
+static noinline long smh_trap(unsigned int sysnum, void *addr)
{
register long result asm(r0);
#if defined(CONFIG_ARM64)
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] armv8: semihosting: add a command to load semihosted images
Instead of sprinkling custom code and calls over the Vexpress64
boardfile, create a command that loads images using semihosting
just like we would load from flash memory of over the network,
using a special command:
smhload image address
This will make it possible to remove some custom calls and
code and make the boot easier.
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
arch/arm/lib/semihosting.c | 70 ++
doc/README.semihosting | 25 -
2 files changed, 75 insertions(+), 20 deletions(-)
diff --git a/arch/arm/lib/semihosting.c b/arch/arm/lib/semihosting.c
index d3f724b726e1..edacb1187731 100644
--- a/arch/arm/lib/semihosting.c
+++ b/arch/arm/lib/semihosting.c
@@ -13,6 +13,7 @@
* for them.
*/
#include common.h
+#include command.h
#include asm/semihosting.h
#define SYSOPEN0x01
@@ -234,3 +235,72 @@ long smh_len(const char *fname)
/* Return the file length (or -1 error indication) */
return len;
}
+
+static int smh_load_file(const char * const name, ulong load_addr,
+ulong *end_addr)
+{
+ long fd;
+ long len;
+ long ret;
+
+ fd = smh_open(name, rb);
+ if (fd == -1)
+ return -1;
+
+ len = smh_len_fd(fd);
+ if (len 0) {
+ smh_close(fd);
+ return -1;
+ }
+
+ ret = smh_read(fd, (void *)load_addr, len);
+ smh_close(fd);
+
+ if (ret == 0) {
+ *end_addr = load_addr + len - 1;
+ printf(loaded file %s from %08lX to %08lX, %08lX bytes\n,
+ name,
+ load_addr,
+ *end_addr,
+ len);
+ } else {
+ printf(read failed\n);
+ return 0;
+ }
+
+ return 0;
+}
+
+static int do_smhload(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
+{
+ if (argc == 3 || argc == 4) {
+ ulong load_addr;
+ ulong end_addr = 0;
+ ulong ret;
+ char end_str[64];
+
+ load_addr = simple_strtoul(argv[2], NULL, 16);
+ if (!load_addr)
+ return -1;
+
+ ret = smh_load_file(argv[1], load_addr, end_addr);
+ if (ret 0)
+ return 1;
+
+ /* Optionally save returned end to the environment */
+ if (argc == 4) {
+ sprintf(end_str, 0x%08lx, end_addr);
+ setenv(argv[3], end_str);
+ }
+ } else {
+ return CMD_RET_USAGE;
+ }
+ return 0;
+}
+
+U_BOOT_CMD(smhload, 4, 0, do_smhload, load a file using semihosting,
+ file 0xaddress [end var]\n
+ - load a semihosted file to the address specified\n
+if the optional [end var] is specified, the end\n
+address of the file will be stored in this environment\n
+variable.\n);
diff --git a/doc/README.semihosting b/doc/README.semihosting
index 724856078069..c016a4f8406d 100644
--- a/doc/README.semihosting
+++ b/doc/README.semihosting
@@ -30,25 +30,10 @@ vexpress_aemv8a.h but differentiate the two models by the
presence or
absence of CONFIG_BASE_FVP. This change is tested and works on both the
Foundation and Base fastmodel simulators.
-The level of semihosting support is minimal, restricted to just what it
-takes to load images to memory. If more semihosting functionality is
-required, such as file seek, outputting strings, reading characters, etc,
-then it can be easily added later.
+The semihosting code adds a command:
-We require that the board include file define these env variables:
-- kernel_name e.g. uImage
-- kernel_addr_re.g. 0x8000
-- initrd_name e.g. ramdisk.img
-- initrd_addr_re.g. 0x8800
-- fdt_name e.g. devtree.dtb
-- fdt_addr_r e.g. 0x8300
+ smhload image address [env var]
-Optionally, fdt_high and initrd_high can be specified as per
-their rules for allowing or preventing copying of these images.
-
-For the fdt chosen startup macro, this code will then define:
-- initrd_end (based on retrieving initrd_addr_r plus actual initrd_size)
-
-We will then load the kernel, initrd, and fdt into the specified
-locations in memory in a similar way that the ATF fastmodel code
-uses semihosting calls to load other boot stages and u-boot itself.
+That will load an image from the host filesystem into RAM at the specified
+address and optionally store the load end address in the specified
+environment variable.
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/13] dfu: Build warning fixes for 64-bit
Hi Thierry,
From: Thierry Reding tred...@nvidia.com
Explicitly cast the result of a pointer arithmetic to unsigned int so
that it matches the corresponding printf format string. While at it,
use %p to print a buffer address rather than %x and an explicit cast
(which causes a warning in this case because it's cast to unsigned
int instead of unsigned long).
Cc: Łukasz Majewski l.majew...@samsung.com
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/dfu/dfu.c | 2 +-
drivers/dfu/dfu_mmc.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 0560afa9ffa5..5c137acfaa04 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -200,7 +200,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num)
debug(%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x offset:
0x%llx bufoffset: 0x%x\n, __func__, dfu-name, buf, size,
blk_seq_num, dfu-offset,
- dfu-i_buf - dfu-i_buf_start);
+ (unsigned int)(dfu-i_buf - dfu-i_buf_start));
if (!dfu-inited) {
/* initial state */
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index fd865e11212e..2a780f7b5d31 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -156,7 +156,7 @@ static int mmc_file_op(enum dfu_op op, struct
dfu_entity *dfu, dfu-data.mmc.dev, dfu-data.mmc.part);
if (op != DFU_OP_SIZE)
- sprintf(cmd_buf + strlen(cmd_buf), 0x%x,
(unsigned int)buf);
+ sprintf(cmd_buf + strlen(cmd_buf), %p, buf);
sprintf(cmd_buf + strlen(cmd_buf), %s, dfu-name);
Acked-by: Lukasz Majewski l.majew...@samsung.com
Tested-by: Lukasz Majewski l.majew...@samsung.com
[test HW: trats - Exynos4210 board]
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] armv8: semihosting: delete external interface
Now that loading files using semihosting can be done using
a command in standard scripts, and we have rewritten the boardfile
and added it to the Vexpress64, let's delete the external
interface to the semihosting file retrieveal and rely solely
on these commands, and staticize them inside that file so the
whole business is self-contained.
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
arch/arm/include/asm/semihosting.h | 17 ---
arch/arm/lib/semihosting.c | 92 --
2 files changed, 109 deletions(-)
delete mode 100644 arch/arm/include/asm/semihosting.h
diff --git a/arch/arm/include/asm/semihosting.h
b/arch/arm/include/asm/semihosting.h
deleted file mode 100644
index 835ca7e4b683..
--- a/arch/arm/include/asm/semihosting.h
+++ /dev/null
@@ -1,17 +0,0 @@
-/*
- * Copyright 2014 Broadcom Corporation
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef __SEMIHOSTING_H__
-#define __SEMIHOSTING_H__
-
-/*
- * ARM semihosting functions for loading images to memory. See the source
- * code for more information.
- */
-int smh_load(const char *fname, void *memp, int avail, int verbose);
-long smh_len(const char *fname);
-
-#endif /* __SEMIHOSTING_H__ */
diff --git a/arch/arm/lib/semihosting.c b/arch/arm/lib/semihosting.c
index edacb1187731..c3e964eabc13 100644
--- a/arch/arm/lib/semihosting.c
+++ b/arch/arm/lib/semihosting.c
@@ -14,7 +14,6 @@
*/
#include common.h
#include command.h
-#include asm/semihosting.h
#define SYSOPEN0x01
#define SYSCLOSE 0x02
@@ -145,97 +144,6 @@ static long smh_len_fd(long fd)
return ret;
}
-/*
- * Open, load a file into memory, and close it. Check that the available space
- * is sufficient to store the entire file. Return the bytes actually read from
- * the file as seen by the read function. The verbose flag enables some extra
- * printing of successful read status.
- */
-int smh_load(const char *fname, void *memp, int avail, int verbose)
-{
- long ret;
- long fd;
- size_t len;
-
- ret = -1;
-
- debug(%s: fname \'%s\', avail %u, memp %p\n, __func__, fname,
- avail, memp);
-
- /* Open the file */
- fd = smh_open(fname, rb);
- if (fd == -1)
- return -1;
-
- /* Get the file length */
- ret = smh_len_fd(fd);
- if (ret == -1) {
- smh_close(fd);
- return -1;
- }
-
- /* Check that the file will fit in the supplied buffer */
- if (ret avail) {
- printf(%s: ERROR ret %ld, avail %u\n, __func__, ret,
- avail);
- smh_close(fd);
- return -1;
- }
-
- len = ret;
-
- /* Read the file into the buffer */
- ret = smh_read(fd, memp, len);
- if (ret == 0) {
- /* Print successful load information if requested */
- if (verbose) {
- printf(\n%s\n, fname);
- printf(0x%8p dest\n, memp);
- printf(0x%08lx size\n, len);
- printf(0x%08x avail\n, avail);
- }
- }
-
- /* Close the file */
- smh_close(fd);
-
- return ret;
-}
-
-/*
- * Get the file length from the filename
- */
-long smh_len(const char *fname)
-{
- long ret;
- long fd;
- long len;
-
- debug(%s: file \'%s\'\n, __func__, fname);
-
- /* Open the file */
- fd = smh_open(fname, rb);
- if (fd 0)
- return fd;
-
- /* Get the file length */
- len = smh_len_fd(fd);
- if (len 0) {
- smh_close(fd);
- return len;
- }
-
- /* Close the file */
- ret = smh_close(fd);
- if (ret 0)
- return ret;
-
- debug(%s: returning len %ld\n, __func__, len);
-
- /* Return the file length (or -1 error indication) */
- return len;
-}
-
static int smh_load_file(const char * const name, ulong load_addr,
ulong *end_addr)
{
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] sunxi: Ainol AW1 support
Hi, On Mon, Mar 23, 2015 at 1:07 AM, Paul Kocialkowski cont...@paulk.fr wrote: Maybe a slight description of the board/device? ChenYu Signed-off-by: Paul Kocialkowski cont...@paulk.fr --- board/sunxi/MAINTAINERS | 5 + configs/Ainol_AW1_defconfig | 16 2 files changed, 21 insertions(+) create mode 100644 configs/Ainol_AW1_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index ef3c937..e486458 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -50,6 +50,11 @@ S: Maintained F: board/sunxi/dram_a20_olinuxino_l2.c F: configs/A20-OLinuXino-Lime2_defconfig +AINOL AW1 BOARD +M: Paul Kocialkowski cont...@paulk.fr +S: Maintained +F: configs/Ainol_AW1_defconfig + AMPE A76 BOARD M: Paul Kocialkowski cont...@paulk.fr S: Maintained diff --git a/configs/Ainol_AW1_defconfig b/configs/Ainol_AW1_defconfig new file mode 100644 index 000..1c3b942 --- /dev/null +++ b/configs/Ainol_AW1_defconfig @@ -0,0 +1,16 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER +CONFIG_FDTFILE=sun7i-a20-ainol-aw1.dtb +CONFIG_USB_MUSB_SUNXI=y +CONFIG_USB0_VBUS_PIN=PB9 +CONFIG_USB0_VBUS_DET=AXP0-VBUS-DETECT +CONFIG_VIDEO_LCD_MODE=x:800,y:480,depth:18,pclk_khz:4,le:87,ri:112,up:38,lo:141,hs:1,vs:1,sync:3,vmode:0 +CONFIG_VIDEO_LCD_POWER=PH8 +CONFIG_VIDEO_LCD_BL_EN=PH7 +CONFIG_VIDEO_LCD_BL_PWM=PB2 +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_MACH_SUN7I=y +CONFIG_DRAM_CLK=432 +CONFIG_DRAM_ZQ=123 +CONFIG_DRAM_EMR1=4 -- 1.9.1 ___ 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] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready
Hi Troy, From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] Sent: Friday, March 20, 2015 9:39 PM To: peng@freescale.com; Gabbasov, Andrew; u-boot@lists.denx.de Cc: Eric Nelson Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready [skipped] Here's another patch that solves the problem a little earlier. It has this disadvantage of being slightly bigger, though it makes the code look better. https://github.com/boundarydevices/u-boot-imx6/commit/c0260ca I have a couple of doubts regarding that patch. First, my personal taste objects to such duplicating of the code (I mean setting of version, ocr, rca, etc fields of mmc structure). If we'll have to change or add anything to these settings, we'll have to make the same change in 2 different place, which is error-prone and extremely inconvenient from maintenance point of view. Second, what about SPI mode? Doesn't this patch skip retrieving of OCR register with a special command for SPI host case (thus setting ocr field incorrectly), if the card comes to ready state with the first attempt? Thanks. Best regards, Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] question about software i2c multi instance
Hi Lukasz,
On 03/23/2015 04:28 PM, Lukasz Majewski wrote:
Hi Bo,
Hi Heiko,
After check the software i2c code, I found it can not support
multi instances, although it has I2C_SOFT_DECLARATIONS2,
I2C_SOFT_DECLARATIONS3, I2C_SOFT_DECLARATIONS4.
Because, when do GPIO operation, there is only one pair of
CONFIG_SOFT_I2C_GPIO_SCL and CONFIG_SOFT_I2C_GPIO_SDA.
So, if want to support multi instances, it needs to extend the
GPIO configuration for SCL/SDA, am I right?
Some time ago we had a similar problem with SW I2C code. Please look
into Samsung's trats board implementation.
However, such approach might be outdated, since Przemek is working on
porting this functionality to device model:
https://patchwork.ozlabs.org/patch/448460/
Thanks for your information.
Now, I just do it as following to make it work. For next step, I will
try to switch to use DM.
---8---
diff --git a/drivers/i2c/soft_i2c.c b/drivers/i2c/soft_i2c.c
index db9b402..b9cfbb8 100644
--- a/drivers/i2c/soft_i2c.c
+++ b/drivers/i2c/soft_i2c.c
@@ -126,6 +126,13 @@ DECLARE_GLOBAL_DATA_PTR;
#define PRINTD(fmt,args...)
#endif
+#ifdef I2C_READ_ADAP
+static int soft_i2c_read_sda(void)
+{
+ I2C_READ_ADAP;
+}
+#endif
+
/*---
* Local functions
*/
@@ -256,7 +263,11 @@ static int write_byte(uchar data)
I2C_SCL(1);
I2C_DELAY;
I2C_DELAY;
+#ifdef I2C_READ_ADAP
+ nack = soft_i2c_read_sda();
+#else
nack = I2C_READ;
+#endif
I2C_SCL(0);
I2C_DELAY;
I2C_ACTIVE;
@@ -286,7 +297,11 @@ static uchar read_byte(int ack)
I2C_SCL(1);
I2C_DELAY;
data = 1;
+#ifdef I2C_READ_ADAP
+ data |= soft_i2c_read_sda();
+#else
data |= I2C_READ;
+#endif
I2C_DELAY;
}
send_ack(ack);
---8---
Thanks again.
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] fastboot: add support for reboot-bootloader command
Hi Steve,
On 15-02-25 06:10 AM, Alexey Firago wrote:
The fastboot reboot-bootloader command is defined to
re-enter into fastboot mode after rebooting into
bootloader. This command is usually used after updating
bootloader via fastboot.
This commit implements only a generic side of the
command - setting of the reset flag and then resetting.
Setting of the reset flag is implemented using __weak
fb_set_reboot_flag() function. The actual setting and
checking of the reset flag should be implemented by
a boot script and/or board/SoC specific code.
Signed-off-by: Alexey Firago alexey_fir...@mentor.com
---
Changes in v3:
- return -ENOSYS from default fb_set_reboot_flag()
Changes in v2:
- return error in default fb_set_reboot_flag()
drivers/usb/gadget/f_fastboot.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/gadget/f_fastboot.c
b/drivers/usb/gadget/f_fastboot.c index 310175a..a000c25 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -122,6 +122,7 @@ static struct usb_gadget_strings
*fastboot_strings[] = { };
static void rx_handler_command(struct usb_ep *ep, struct
usb_request *req); +static int strcmp_l1(const char *s1, const char
*s2);
static void fastboot_complete(struct usb_ep *ep, struct
usb_request *req) {
@@ -317,8 +318,20 @@ static void compl_do_reset(struct usb_ep *ep,
struct usb_request *req) do_reset(NULL, 0, 0, NULL);
}
+int __weak fb_set_reboot_flag(void)
+{
+ return -ENOSYS;
+}
+
static void cb_reboot(struct usb_ep *ep, struct usb_request *req)
{
+ char *cmd = req-buf;
+ if (!strcmp_l1(reboot-bootloader, cmd)) {
+ if (fb_set_reboot_flag()) {
+ fastboot_tx_write_str(FAILCannot set
reboot flag);
+ return;
+ }
+ }
fastboot_func-in_req-complete = compl_do_reset;
fastboot_tx_write_str(OKAY);
}
Tested-by: Steve Rae s...@broadcom.com
(on bcm28155_ap board)
Thanks!
Applied to u-boot-dfu tree. Thanks!
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/13] usb: mass-storage: Build warning fixes for 64-bit
Hi Thierry,
From: Thierry Reding tred...@nvidia.com
Fix a printf format mismatch warning seen on 64-bit builds.
Cc: Łukasz Majewski l.majew...@samsung.com
Cc: Marek Vasut ma...@denx.de
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/usb/gadget/f_mass_storage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c index
e045957d0723..71fd49db7f24 100644 ---
a/drivers/usb/gadget/f_mass_storage.c +++
b/drivers/usb/gadget/f_mass_storage.c @@ -973,7 +973,7 @@ static int
do_write(struct fsg_common *common)
/* If an error occurred, report it and its
position */ if (nwritten amount) {
- printf(nwritten:%d amount:%d\n,
nwritten,
+ printf(nwritten:%zd amount:%u\n,
nwritten, amount);
curlun-sense_data = SS_WRITE_ERROR;
curlun-info_valid = 1;
Acked-by: Lukasz Majewski l.majew...@samsung.com
Tested-by: Lukasz Majewski l.majew...@samsung.com
[test HW - Exynos4210 Trats board]
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] power: pfuze100 correct macro definition
Correct the macro PFUZE100_SW1ABC_SETP definition. We should
add parenthese for 'x'.
Signed-off-by: Peng Fan peng@freescale.com
---
include/power/pfuze100_pmic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/power/pfuze100_pmic.h b/include/power/pfuze100_pmic.h
index 07199b4..9c749ed 100644
--- a/include/power/pfuze100_pmic.h
+++ b/include/power/pfuze100_pmic.h
@@ -61,7 +61,7 @@ enum {
* Buck Regulators
*/
-#define PFUZE100_SW1ABC_SETP(x)((x - 3000) / 250)
+#define PFUZE100_SW1ABC_SETP(x)(((x) - 3000) / 250)
/* SW1A/B/C Output Voltage Configuration */
#define SW1x_0_300V 0
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/8] lpc32xx: mtd: nand: add MLC NAND controller
Bonjour Scott,
Le Fri, 20 Mar 2015 17:41:11 -0500, Scott Wood
scottw...@freescale.com a écrit :
On Fri, 2015-03-20 at 10:35 +0100, Albert ARIBAUD wrote:
Hi Scott,
Le Thu, 19 Mar 2015 16:39:42 -0500, Scott Wood
scottw...@freescale.com a écrit :
On Wed, 2015-03-18 at 10:04 +0100, Albert ARIBAUD (3ADEV) wrote:
+int nand_spl_load_image(uint32_t offs, unsigned int size, void *dst)
+{
+ int block_good;
bool?
+ struct lpc32xx_oob oob;
+ unsigned int page, left;
+
+ /* if starting mid-block consider block good */
+ block_good = 1;
+
+ for (page = offs / BYTES_PER_PAGE,
+left = DIV_ROUND_UP(size, BYTES_PER_PAGE);
+left (page PAGES_PER_CHIP_MAX); page++) {
+ /* read inband and oob page data anyway */
+ int res = read_single_page(dst, page, oob);
+ /* return error if a good block's page was not readable
*/
+ if ((res 0) block_good)
+ return -1;
Why even try to read it if it's been marked bad?
Actually, at this point, we may not know yet if the block is good or
bad, since we might be reading a page of it for the first time. Will
fix, see below.
+ /* if first page in a block, update 'block good' status
*/
The non-SPL driver appears to be checking the last two pages in the
block, not the first page.
Thanks for pointing out this discrepancy.
I took the first page option here after checking the NAND's datasheet,
which says that for factory bad block marking at least, while all pages
in a bad block /should/ bear the bad block marker, only the first one is
/guaranteed/ to have it. The driver might have inherited the 'last page'
option from the previous NAND chip used, or from a mistake of my own.
Are there any plans for this controller to be used with different chips?
Not that I know; but in the same vein, the current LPC32XX maintainer
did not consider there were any plans for a few devices in it, and then
came my patch series :) so I cannot rule out that someday a new LPC32XX
board pops up in U-Boot with another NAND device.
BTW, is there a standard way to ask a NAND chip which page(s) in a bad
block should be checked?
Yes and no:
http://lists.infradead.org/pipermail/linux-mtd/2011-November/038419.html
... right.
How about this: the driver expects a driver-specific configuration
option which tells it which page(s) in a block, and which byte in a
page's OOB area, should be scanned for bad block markers, and my
board provides a value for said option.
This way, when the driver is used with a new NAND chip in another
board, it can be configured for this board's specific case.
+ if ((page % PAGES_PER_BLOCK) == 0) {
+ /* assume block is good */
+ block_good = 1;
+ /* if page could not be read, assume block is
bad */
+ if (res 0)
+ block_good = 0;
No. A block is to be skipped if and only if it has a bad block marker.
ECC errors should not be silently ignored just because they happen on
the first page of a block. If the writer of this data didn't skip the
block, then skipping it when reading will result in unusable data
regardless of the underlying ECC problem.
You're correct of course.
However, I do want the SPL chainloading to be as resilient as
possible, and we have established that it will have to read some part
of a bad block -- possibly resulting in a read failure -- before
knowing that the block is bad, which means it may have to finally
ignore the read failure.
FWIW, the eLBC/IFC SPL functions have the same problem regarding halting
on an ECC error before checking the bad block status. Instead it should
return an error code, and let the caller halt after it's sure it's not
marked bad.
Maybe we could generalize an SPL chainloading common/spl/spl.c routine
and have boards /SoCs only provide the hardware-specific page/OOB read
function(s) ? Honestly, that would be way beyond my scope for this
patch series.
I guess I could wait to declare the block good or bad until I could
read at least one if its pages (actually, one of its pages' OOB data)
properly, only bail out if the OOB says the block is supposed to be
good.
Now, if none of the block's pages could be read, this still prevents us
from knowing whether these read failures are catastrophic.
If the block was actually bad and skipped, then the resulting image
might be intact, will pass the checksum test, and will run; if the
block was actually good, SPL will detect it and not boot the corrupt
image -- except if the completely unreadable good block was the first
one, which holds the signature and checksum, in which
Re: [U-Boot] [PATCH 2/3] Kconfig: i2c: remove wrong help message related to dm i2c
Hi Przemyslaw, Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Masahiro Yamada yamad...@jp.panasonic.com Cc: Mike Frysinger vap...@gentoo.org Cc: Simon Glass s...@chromium.org Cc: Heiko Schocher h...@denx.de --- drivers/i2c/Kconfig | 11 +-- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 692810d..0a52ed9 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -2,16 +2,7 @@ config DM_I2C bool Enable Driver Model for I2C drivers depends on DM help - Enable driver model for I2C. This SPI flash interface - (spi_flash_probe(), spi_flash_write(), etc.) is then - implemented by the SPI flash uclass. There is one standard - SPI flash driver which knows how to probe most chips - supported by U-Boot. The uclass interface is defined in - include/spi_flash.h, but is currently fully compatible - with the old interface to avoid confusion and duplication - during the transition parent. SPI and SPI flash must be - enabled together (it is not possible to use driver model - for one and not the other). + Enable driver model for I2C. config DM_I2C_COMPAT bool Enable I2C compatibility layer Reviewed-by: Lukasz Majewski l.majew...@samsung.com -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/13] usb: mass-storage: Build warning fixes for 64-bit
Hi Thierry,
From: Thierry Reding tred...@nvidia.com
Fix a printf format mismatch warning seen on 64-bit builds.
Cc: Łukasz Majewski l.majew...@samsung.com
Cc: Marek Vasut ma...@denx.de
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/usb/gadget/f_mass_storage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c index
e045957d0723..71fd49db7f24 100644 ---
a/drivers/usb/gadget/f_mass_storage.c +++
b/drivers/usb/gadget/f_mass_storage.c @@ -973,7 +973,7 @@ static int
do_write(struct fsg_common *common)
/* If an error occurred, report it and its
position */ if (nwritten amount) {
- printf(nwritten:%d amount:%d\n,
nwritten,
+ printf(nwritten:%zd amount:%u\n,
nwritten, amount);
curlun-sense_data = SS_WRITE_ERROR;
curlun-info_valid = 1;
Reviewed-by: Lukasz Majewski l.majew...@samsung.com
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] m68k: remove arch/m68k/lib/board.c
On 19 March 2015 at 04:42, Masahiro Yamada yamada.masah...@socionext.com wrote: All the M68000 boards have switched to Generic Board. This file is no longer necessary. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com Cc: Huan Wang alison.w...@freescale.com Cc: Angelo Dureghello ang...@sysam.it --- Changes in v2: None arch/m68k/lib/Makefile | 3 - arch/m68k/lib/board.c | 642 - 2 files changed, 645 deletions(-) delete mode 100644 arch/m68k/lib/board.c Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] net: Add Intel Topcliff GMAC driver
Hi Bin, On 20 March 2015 at 13:18, Joe Hershberger joe.hershber...@gmail.com wrote: On Fri, Mar 20, 2015 at 4:12 AM, Bin Meng bmeng...@gmail.com wrote: Add a new driver for the Gigabit Ethernet MAC found on Intel Topcliff Platform Controller Hub. Tested under 10/100 half/full duplex and 1000 full duplex modes using ping and tftpboot commands. Signed-off-by: Bin Meng bmeng...@gmail.com --- Acked-by: Joe Hershberger joe.hershber...@ni.com Do you think this could be converted to driver model? E.g., see this: http://patchwork.ozlabs.org/patch/444846/ Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/28] drivers/fsl-mc: Changed MC firmware loading for new boot architecture
On Mon, 23 Mar 2015 15:06:11 -0500
Rivera Jose-B46482 german.riv...@freescale.com wrote:
From: Kim Phillips [mailto:kim.phill...@freescale.com]
Sent: Thursday, March 19, 2015 12:53 PM
On Thu, 19 Mar 2015 09:45:45 -0700
York Sun york...@freescale.com wrote:
From: J. German Rivera german.riv...@freescale.com
Changed MC firmware loading to comply with the new MC boot
architecture.
Flush D-cache hierarchy after loading MC images. Add environment
variables mcboottimeout for MC boot timeout in milliseconds,
mcmemsize for MC DRAM block size. Check MC boot status before
calling flib functions.
Can we just assign actual and/or optimal values for 'mcboottimeout'
and 'mcmemsize' instead of making them environment variables?
Having environment variables gives us the flexibility if these
values need to be changed for a given customer configuration. The actual
what defines a 'customer configuration,' and how does that manifest
itself at u-boot boot time? Is it the amount of time it takes to
load (and execute?) firmare? Why isn't customer-specific firmware
being loaded via linux? All u-boot needs is basic networking,
pretty static setup: fixed numbers for both memsize timeout.
boot time of the MC and the amount of memory needed by the MC is dependent
on how big/complex is the DPL used. Also, the memory needed by the MC
needs to account for how much memory is needed for AIOP programs,
which may depend on how big/complex they are.
ok, that helps (modulo not knowing what 'DPL' is), but still, the
massive customer configurations should be being loaded via linux'
firmware loading infrastructure: u-boot should be using a static
image for u-boot's needs.
+static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr) {
+ u32 reg_gsr;
+ u32 mc_fw_boot_status;
+ unsigned long timeout_ms = get_mc_boot_timeout_ms();
+ struct mc_ccsr_registers __iomem *mc_ccsr_regs = MC_CCSR_BASE_ADDR;
+
+ dmb();
+ debug(Polling mc_ccsr_regs-reg_gsr ...\n);
+ assert(timeout_ms 0);
+ for (;;) {
+ udelay(1000); /* throttle polling */
does this really need to be a whole 1ms?
It is unlikely that the MC fw will boot in less than 1 ms.
is wait_for_mc() only called for the boot command, or all
commands?
So, checking more frequently than 1 ms is not necessary.
yes it is, because e.g., if it takes 1.1ms we will have wasted 0.9ms
on this.
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config: peach: Correct memory layout environment settings
Hi Sjoerd, On 12 March 2015 at 15:33, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: The peach boards have their SDRAM start address at 0x2000 instead of 0x4000 which seems common for all other exynos5 based boards. This means the layout set in exynos5-common.h causes the kernel be loaded more then 128MB (at 0x4200) away from memory start which breaks booting kernels with CONFIG_AUTO_ZRELADDR Define a custom MEM_LAYOUT_ENV_SETTINGS for both peach boards which uses the same offsets from start of memory as the common exynos5 settings. This fixes booting via bootz and PXE Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- include/configs/peach-pi.h | 8 include/configs/peach-pit.h | 8 2 files changed, 16 insertions(+) diff --git a/include/configs/peach-pi.h b/include/configs/peach-pi.h index f04f061..e3cb09e 100644 --- a/include/configs/peach-pi.h +++ b/include/configs/peach-pi.h @@ -16,6 +16,14 @@ #define CONFIG_ENV_OFFSET (FLASH_SIZE - CONFIG_BL2_SIZE) #define CONFIG_SPI_BOOTING +#define MEM_LAYOUT_ENV_SETTINGS \ + bootm_size=0x1000\0 \ + kernel_addr_r=0x2200\0 \ + fdt_addr_r=0x2300\0 \ + ramdisk_addr_r=0x2330\0 \ + scriptaddr=0x3000\0 \ + pxefile_addr_r=0x3100\0 + #include configs/exynos5420-common.h #include configs/exynos5-dt-common.h diff --git a/include/configs/peach-pit.h b/include/configs/peach-pit.h index b5efbdc..3ee42ef 100644 --- a/include/configs/peach-pit.h +++ b/include/configs/peach-pit.h @@ -16,6 +16,14 @@ #define CONFIG_ENV_OFFSET (FLASH_SIZE - CONFIG_BL2_SIZE) #define CONFIG_SPI_BOOTING +#define MEM_LAYOUT_ENV_SETTINGS \ + bootm_size=0x1000\0 \ + kernel_addr_r=0x2200\0 \ + fdt_addr_r=0x2300\0 \ + ramdisk_addr_r=0x2330\0 \ + scriptaddr=0x3000\0 \ + pxefile_addr_r=0x3100\0 + #include configs/exynos5420-common.h #include configs/exynos5-dt-common.h It would be great if we could have this in the device tree. I haven't merged this patch yet, but it goes some of the way: http://patchwork.ozlabs.org/patch/402714/ Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Rework the network stack
Joe, Simon,
On Mo, 2015-03-23 at 10:46 -0600, Simon Glass wrote:
Hi Jörg,
On 22 March 2015 at 14:37, Jörg Krause joerg.krause@embedded.rocks wrote:
Hi Joe,
On Sa, 2015-03-21 at 22:59 -0500, Joe Hershberger wrote:
Hi Jörg,
On Sat, Mar 21, 2015 at 3:33 AM, Jörg Krause joerg.krause@embedded.rocks
wrote:
Hi all,
there is an issue with the current network stack using netconsole. It's
impossible to use network commands as TFTP inside netconsole, because
they try to run as atomic network commands.
The issue was already reported by Stefano Babic in 2010:
[U-Boot] NetConsole and network API
http://lists.denx.de/pipermail/u-boot/2010-August/075535.html
I worked around this problem here:
http://lists.denx.de/pipermail/u-boot/2012-August/129913.html
I know about this patch, and I understand the problem it tries to
workaround. But it does not work for using netconsole with another
protocol like ping. When for example ping enters the NetLoop() it will
halt the network device.
The problem for this is here:
if (eth_is_on_demand_init() || protocol != NETCONS) {
eth_halt();
...
}
eth_is_on_demand_init() returns correctly with false, because PING !=
NETCONS. But the second expression results in true, because PING !=
NETCONS.
I run into the same problem:
[U-Boot] netconsole: USB Ethernet connection dropping with ping or
tftpboot
http://lists.denx.de/pipermail/u-boot/2015-February/203838.html
I didn't understand what about your case was not able to work given the
workaround I implemented previously. What was different about it?
I have looked at the current network stack. The stack is based on the
concept of atomic network commands. The implementation for netconsole
looks very confusing.
There is no doubt that netconsole is quite confusing as it exists today.
I tried to fix the issue, but it did not work properly.
Sascha Hauer has reimplemented the network stack for Barebox:
http://www.spinics.net/lists/u-boot-v2/msg00914.html
Looking at the current implementation of net.c looks very clean and
well-designed.
Thanks for pointing this out. I hadn't gone to look at the network stack in
barebox.
What do you think about porting this to U-Boot?
I can look into this. Naturally there are many other changes to u-boot
network stack since the time barebox forked, so I expect such a port to be
very intensive... most likely a near complete rewrite of Sascha's series,
but I will investigate further.
I had a look at the patches and the code base is not entirely the same.
But maybe we should just stick to the crucial points of the new network
stack:
1) A network device gets initialized when it becomes the current one and
gets brought down when it's not used anymore or prior booting to Linux
so the connection remains active all the time.
My thoughts about this one:
Bringing the device down can be done in eth_unregister(). Initializing
for the current device can be done in eth_current_changed(). What I like
even better is to make eth_current_changed() the sole place for calling
init() and halt(). It would have to be extend to take at least two
parameters, eth_current and new_current. If eth_current is null just
bring up the new device, if new_current is null just bring down the
current device.
2) Replace the NetLoop by a connection list where each protocol uses a
connection to send and receive packets.
This induce to port all protocols to use the new network, of cause.
In my opinion it would be also good to do some clean ups and
restructuring of code. Put more functions into net-utils, is there a
need for eth_init and so on.
Joe has done a lot of work to move U-Boot's network stack over to
driver model. This is now at u-boot-dm/next waiting for the merge
window to open.
The connection list idea does not sound like a hugely complex change.
Are you thinking of trying it out?
I have just noticed today the big series of u-boot-dm patches of Joe. I
will try it out. But before I will start I want to discuss the concept.
What do you think about my thoughts about bringing up and down a network
device?
Best regards,
Jörg
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 20/28] armv8/ls2085ardb: Add support of LS2085ARDB platform
On Mon, 2015-03-23 at 15:04 -0700, York Sun wrote: On 03/23/2015 03:02 PM, Scott Wood wrote: On Fri, 2015-03-20 at 18:46 -0700, York Sun wrote: On 03/20/2015 05:33 PM, Scott Wood wrote: On Fri, 2015-03-20 at 17:29 -0700, York Sun wrote: diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f4a7851..7478eb4 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -658,6 +658,16 @@ config TARGET_LS2085AQDS development platform that supports the QorIQ LS2085A Layerscape Architecture processor. +config TARGET_LS2085ARDB +bool Support ls2085ardb +select ARM64 +select ARMV8_MULTIENTRY +help + Support for Freescale LS2085ARDB platform. + The LS2080A Reference design board (RDB) is a high-performance + development platform that supports the QorIQ LS2085A + LayerScape Architecture processor. + s/LayerScape/Layerscape/ diff --git a/board/freescale/ls2085aqds/README b/board/freescale/ls2085ardb/README similarity index 73% copy from board/freescale/ls2085aqds/README copy to board/freescale/ls2085ardb/README index a4d7b53..cfd5185 100644 --- a/board/freescale/ls2085aqds/README +++ b/board/freescale/ls2085ardb/README @@ -1,10 +1,8 @@ Overview -The LS2080A Development System (QDS) is a high-performance computing, -evaluation, and development platform that supports the QorIQ LS2080A -LayerScape Architecture processor. The LS2080AQDS provides validation and -SW development platform for the Freescale LS2080A processor series, with -a complete debugging environment. +The LS2085A Reference Design (RDB) is a high-performance computing, +evaluation, and development platform that supports the QorIQ LS2085A +Layerscape Architecture processor. LayerScape and 2080 should be fixed in the QDS patch as well. @@ -113,25 +105,25 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_SYS_NAND_CSOR(CSOR_NAND_ECC_ENC_EN /* ECC on encode */ \ | CSOR_NAND_ECC_DEC_EN /* ECC on decode */ \ | CSOR_NAND_ECC_MODE_4 /* 4-bit ECC */ \ -| CSOR_NAND_RAL_3 /* RAL = 2Byes */ \ -| CSOR_NAND_PGS_2K /* Page Size = 2K */ \ -| CSOR_NAND_SPRZ_64/* Spare size = 64 */ \ -| CSOR_NAND_PB(64)) /*Pages Per Block = 64*/ +| CSOR_NAND_RAL_3 /* RAL = 3Byes */ \ +| CSOR_NAND_PGS_4K /* Page Size = 4K */ \ +| CSOR_NAND_SPRZ_224/* Spare size = 224 */ \ +| CSOR_NAND_PB(128))/*Pages Per Block = 128*/ From this it looks like the QDS patch still has a comment/code inconsistency with RAL. Let me re-generate the patch using patman, without -C --find-copies-harder flag so they don't show as copy-n-modify. Why? I found it rather useful. In any case, the error in the QDS file will still be there. I have to modify patman to have these flags. Personally I prefer to use them. I don't understand what this has to do with my original comment. But I guess if everyone uses the patman, so should I. I don't think it's mandatory. :-) Assuming you're getting some benefit from patman, you could add support for those flags. They're useful. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] autoboot.c: Add feature to stop autobooting via SHA256 encrypted password
Hi Stefan,
On 13 March 2015 at 01:15, Stefan Roese s...@denx.de wrote:
Hi Simon,
On 13.03.2015 03:48, Simon Glass wrote:
This patch adds the feature to only stop the autobooting, and therefor
boot into the U-Boot prompt, when the input string / password matches
a values that is encypted via a SHA256 hash and saved in the
environment.
This feature is enabled by defined these config options:
CONFIG_AUTOBOOT_KEYED
CONFIG_AUTOBOOT_STOP_STR_SHA256
Signed-off-by: Stefan Roese s...@denx.de
This is certainly interesting but I think brings us back to a point
Simon made a long while back about needing to factor out this code
better. Especially since this adds big long #if-#else-#endif blocks.
Can we re-do this so at least have some functions be called out instead?
Thanks!
Also if these CONFIG options are in Kconfig (as they should be) then we
can use
if (IS_ENABLED(CONFIG_AUTOBOOT_STOP_STR_SHA256))
instead of #ifdef which may improve the code.
Right. I also thought about this. But the resulting code has all the
functionality extracted into 2 functions:
#if defined(CONFIG_AUTOBOOT_STOP_STR_SHA256)
static int passwd_abort(uint64_t etime)
{
const char *sha_env_str = getenv(bootstopkeysha256);
...
}
#else
static int passwd_abort(uint64_t etime)
{
int abort = 0;
...
}
#endif
And this function is now called unconditionally:
...
abort = passwd_abort(etime);
So there is nothing here that could be simplified by using IS_ENABLED().
I could of course just add this new config option to Kconfig. But with all
the other related options not in Kconfig (CONFIG_AUTOBOOT_KEYED,
CONFIG_AUTOBOOT_DELAY_STR...), this doesn't make much sense. So at some
point all those config options should be moved to Kconfig. Unfortunately I
don't have the time for this right now. But I'll add it to my list to do
this at a later time.
Well rather than adding more options, perhaps we should wait until we
get this moved to Kconfig? It's not going to get any easier :-)
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 20/28] armv8/ls2085ardb: Add support of LS2085ARDB platform
On 03/23/2015 03:02 PM, Scott Wood wrote: On Fri, 2015-03-20 at 18:46 -0700, York Sun wrote: On 03/20/2015 05:33 PM, Scott Wood wrote: On Fri, 2015-03-20 at 17:29 -0700, York Sun wrote: diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f4a7851..7478eb4 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -658,6 +658,16 @@ config TARGET_LS2085AQDS development platform that supports the QorIQ LS2085A Layerscape Architecture processor. +config TARGET_LS2085ARDB + bool Support ls2085ardb + select ARM64 + select ARMV8_MULTIENTRY + help +Support for Freescale LS2085ARDB platform. +The LS2080A Reference design board (RDB) is a high-performance +development platform that supports the QorIQ LS2085A +LayerScape Architecture processor. + s/LayerScape/Layerscape/ diff --git a/board/freescale/ls2085aqds/README b/board/freescale/ls2085ardb/README similarity index 73% copy from board/freescale/ls2085aqds/README copy to board/freescale/ls2085ardb/README index a4d7b53..cfd5185 100644 --- a/board/freescale/ls2085aqds/README +++ b/board/freescale/ls2085ardb/README @@ -1,10 +1,8 @@ Overview -The LS2080A Development System (QDS) is a high-performance computing, -evaluation, and development platform that supports the QorIQ LS2080A -LayerScape Architecture processor. The LS2080AQDS provides validation and -SW development platform for the Freescale LS2080A processor series, with -a complete debugging environment. +The LS2085A Reference Design (RDB) is a high-performance computing, +evaluation, and development platform that supports the QorIQ LS2085A +Layerscape Architecture processor. LayerScape and 2080 should be fixed in the QDS patch as well. @@ -113,25 +105,25 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_SYS_NAND_CSOR(CSOR_NAND_ECC_ENC_EN /* ECC on encode */ \ | CSOR_NAND_ECC_DEC_EN /* ECC on decode */ \ | CSOR_NAND_ECC_MODE_4 /* 4-bit ECC */ \ - | CSOR_NAND_RAL_3 /* RAL = 2Byes */ \ - | CSOR_NAND_PGS_2K /* Page Size = 2K */ \ - | CSOR_NAND_SPRZ_64/* Spare size = 64 */ \ - | CSOR_NAND_PB(64)) /*Pages Per Block = 64*/ + | CSOR_NAND_RAL_3 /* RAL = 3Byes */ \ + | CSOR_NAND_PGS_4K /* Page Size = 4K */ \ + | CSOR_NAND_SPRZ_224/* Spare size = 224 */ \ + | CSOR_NAND_PB(128))/*Pages Per Block = 128*/ From this it looks like the QDS patch still has a comment/code inconsistency with RAL. Let me re-generate the patch using patman, without -C --find-copies-harder flag so they don't show as copy-n-modify. Why? I found it rather useful. In any case, the error in the QDS file will still be there. I have to modify patman to have these flags. Personally I prefer to use them. But I guess if everyone uses the patman, so should I. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/28] drivers/fsl-mc: Changed MC firmware loading for new boot architecture
On Mon, 23 Mar 2015 16:15:56 -0500
Rivera Jose-B46482 german.riv...@freescale.com wrote:
-Original Message-
From: Kim Phillips [mailto:kim.phill...@freescale.com]
Sent: Monday, March 23, 2015 3:34 PM
To: Rivera Jose-B46482
Cc: Sun York-R58495; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH 14/28] drivers/fsl-mc: Changed MC firmware
loading for new boot architecture
On Mon, 23 Mar 2015 15:06:11 -0500
Rivera Jose-B46482 german.riv...@freescale.com wrote:
From: Kim Phillips [mailto:kim.phill...@freescale.com]
Sent: Thursday, March 19, 2015 12:53 PM
On Thu, 19 Mar 2015 09:45:45 -0700
York Sun york...@freescale.com wrote:
From: J. German Rivera german.riv...@freescale.com
Changed MC firmware loading to comply with the new MC boot
architecture.
Flush D-cache hierarchy after loading MC images. Add environment
variables mcboottimeout for MC boot timeout in milliseconds,
mcmemsize for MC DRAM block size. Check MC boot status before
calling flib functions.
Can we just assign actual and/or optimal values for 'mcboottimeout'
and 'mcmemsize' instead of making them environment variables?
Having environment variables gives us the flexibility if these values
need to be changed for a given customer configuration. The actual
what defines a 'customer configuration,' and how does that manifest
itself at u-boot boot time?
A DPL (data path layout - a device-tree-like structure describing
The DPAA2 objects created at boot time and their connections)
Is it the amount of time it takes to load
(and execute?) firmare?
Yes, bigger DPLs take longer to process by the MC.
Why isn't customer-specific firmware being
loaded via linux? All u-boot needs is basic networking, pretty static
setup: fixed numbers for both memsize timeout.
This is not customer-specific firmware. What is customer-specific is just the
DPL.
In order to have networking in u-boot, we need to load the MC firmware in
u-boot,
For cases in which the target system has only DPAA2-based network interfaces.
ok, for that case, when time comes for u-boot to do some DPAA2
networking arrives (i.e., we shouldn't have to be loading firmware
at board boot-time), then we should load a minimal DPL for the
number of singular, non-virtual/switch, etc., interfaces for that
board just to tftp: this shouldn't be a big DPL at all, and its
time complexity is fixed.
boot time of the MC and the amount of memory needed by the MC is
dependent on how big/complex is the DPL used. Also, the memory needed
by the MC needs to account for how much memory is needed for AIOP
programs, which may depend on how big/complex they are.
ok, that helps (modulo not knowing what 'DPL' is), but still, the massive
customer configurations should be being loaded via linux'
firmware loading infrastructure: u-boot should be using a static image
for u-boot's needs.
+static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr) {
+ u32 reg_gsr;
+ u32 mc_fw_boot_status;
+ unsigned long timeout_ms = get_mc_boot_timeout_ms();
+ struct mc_ccsr_registers __iomem *mc_ccsr_regs =
+MC_CCSR_BASE_ADDR;
+
+ dmb();
+ debug(Polling mc_ccsr_regs-reg_gsr ...\n);
+ assert(timeout_ms 0);
+ for (;;) {
+ udelay(1000); /* throttle polling */
does this really need to be a whole 1ms?
It is unlikely that the MC fw will boot in less than 1 ms.
is wait_for_mc() only called for the boot command, or all commands?
I see: there's a udelay(500) in mc_send_command(), which is too high,
too, IMO, but I'm not that familiar with the h/w: How long does the
shortest command take?
So, checking more frequently than 1 ms is not necessary.
yes it is, because e.g., if it takes 1.1ms we will have wasted 0.9ms on
this.
How significant is to save 0.9ms of the whole boot time?
Why waste 0.9ms of boot time when there's no need? It already takes
the boards *way* too long to boot, and now I'm understanding
mc_send_command's delay should probably be adjusted, too.
As the comment in the code says, the intent was to throttle down the polling,
to reduce traffic on the system bus due to polling. This traffic competes with
the MC itself accessing the system bus, as it boots. Having the polling
traffic get
in the way of the MC traffic may increase the MC boot time. Too small delay
between polls may cause the MC boot time to increase more than the .9ms you
are concerned of wasting in the delay.
What value would you suggest to use for the delay instead 1000ms?
I don't know MC h/w: what's the shortest boot time given a standard
simple DPL?: A small fraction of that.
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] kbuild: remove scripts/multiconfig.sh
On 13 March 2015 at 03:08, Masahiro Yamada yamada.masah...@socionext.com wrote: We have switched to the single .config configuration system, the same one as used in Linux Kernel. The necessary glue code is small enough now, so move it to the top-level Makefile and scripts/kconfig/Makefile, and then delete scripts/multiconfig.sh. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- This patch requires http://patchwork.ozlabs.org/patch/449347/ as a prerequisite. Makefile | 13 +-- scripts/kconfig/Makefile | 10 ++ scripts/multiconfig.sh | 90 3 files changed, 21 insertions(+), 92 deletions(-) delete mode 100755 scripts/multiconfig.sh Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/board_f: make board_init_f_mem() independent on !CONFIG_X86
Hi Alexey,
On 23 March 2015 at 15:17, Alexey Brodkin alexey.brod...@synopsys.com wrote:
Hi Simon,
On Mon, 2015-03-23 at 11:26 -0600, Simon Glass wrote:
On 23 March 2015 at 10:40, Alexey Brodkin alexey.brod...@synopsys.com
wrote:
Hi Tom, Simon,
On Mon, 2015-03-16 at 11:03 +0300, Alexey Brodkin wrote:
Even though board_init_f_mem() is not used on x86 today there's no
reason to not use it in the future.
Moreover board_init_f_mem() has nothing to do with any particular
architecture so move it away from #else /* CONFIG_X86 */
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Simon Glass s...@chromium.org
Cc: Tom Rini tr...@ti.com
Any comments on this one?
This is a prerequisite for ARC updates so would be good to have it
merged sometime soon.
I must have missed something as it did not seem to change anything for ARC.
I meant this series -
http://lists.denx.de/pipermail/u-boot/2015-March/208179.html
In particular here I wanted to use board_init_f_mem():
http://lists.denx.de/pipermail/u-boot/2015-March/208183.html
Note that in the previous patch
http://lists.denx.de/pipermail/u-boot/2015-March/208182.html I re-used
former X86-only code sections in common/board_f.c - that's why I did
need board_init_f_mem() to be separated from #ifdef CONFIG_X86 #else - I
wanted to use both branches :)
This breaks building on x86 though, so we can't take this patch as is. E.g.:
x86: + crownbay
+common/board_f.c: In function ‘board_init_f_mem’:
+common/board_f.c:1092:5: error: lvalue required as left operand of
assignment
+ gd = (struct global_data *)top;
+ ^
That's why I wanted your opinion :)
Sandbox didn't show any problems and I didn't do makeall.
Because in case of X86 gd is an alias to get_fs_gd_ptr() we cannot do
such assignments.
So then we'll need to keep board_init_f_mem() disabled for X86 like
that:
---8---
#ifndef CONFIG_X86
ulong board_init_f_mem(ulong top)
{
/* Leave space for the stack we are running with now */
top -= 0x40;
top -= sizeof(struct global_data);
top = ALIGN(top, 16);
gd = (struct global_data *)top;
memset((void *)gd, '\0', sizeof(*gd));
#ifdef CONFIG_SYS_MALLOC_F_LEN
top -= CONFIG_SYS_MALLOC_F_LEN;
gd-malloc_base = top;
#endif
return top;
}
#endif
---8---
Do you think that's OK? If so I'll send v2 shortly.
Yes that should be fine.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/28] drivers/fsl-mc: Changed MC firmware loading for new boot architecture
-Original Message-
From: Kim Phillips [mailto:kim.phill...@freescale.com]
Sent: Monday, March 23, 2015 3:34 PM
To: Rivera Jose-B46482
Cc: Sun York-R58495; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH 14/28] drivers/fsl-mc: Changed MC firmware
loading for new boot architecture
On Mon, 23 Mar 2015 15:06:11 -0500
Rivera Jose-B46482 german.riv...@freescale.com wrote:
From: Kim Phillips [mailto:kim.phill...@freescale.com]
Sent: Thursday, March 19, 2015 12:53 PM
On Thu, 19 Mar 2015 09:45:45 -0700
York Sun york...@freescale.com wrote:
From: J. German Rivera german.riv...@freescale.com
Changed MC firmware loading to comply with the new MC boot
architecture.
Flush D-cache hierarchy after loading MC images. Add environment
variables mcboottimeout for MC boot timeout in milliseconds,
mcmemsize for MC DRAM block size. Check MC boot status before
calling flib functions.
Can we just assign actual and/or optimal values for 'mcboottimeout'
and 'mcmemsize' instead of making them environment variables?
Having environment variables gives us the flexibility if these values
need to be changed for a given customer configuration. The actual
what defines a 'customer configuration,' and how does that manifest
itself at u-boot boot time?
A DPL (data path layout - a device-tree-like structure describing
The DPAA2 objects created at boot time and their connections)
Is it the amount of time it takes to load
(and execute?) firmare?
Yes, bigger DPLs take longer to process by the MC.
Why isn't customer-specific firmware being
loaded via linux? All u-boot needs is basic networking, pretty static
setup: fixed numbers for both memsize timeout.
This is not customer-specific firmware. What is customer-specific is just the
DPL.
In order to have networking in u-boot, we need to load the MC firmware in
u-boot,
For cases in which the target system has only DPAA2-based network interfaces.
boot time of the MC and the amount of memory needed by the MC is
dependent on how big/complex is the DPL used. Also, the memory needed
by the MC needs to account for how much memory is needed for AIOP
programs, which may depend on how big/complex they are.
ok, that helps (modulo not knowing what 'DPL' is), but still, the massive
customer configurations should be being loaded via linux'
firmware loading infrastructure: u-boot should be using a static image
for u-boot's needs.
+static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr) {
+ u32 reg_gsr;
+ u32 mc_fw_boot_status;
+ unsigned long timeout_ms = get_mc_boot_timeout_ms();
+ struct mc_ccsr_registers __iomem *mc_ccsr_regs =
+MC_CCSR_BASE_ADDR;
+
+ dmb();
+ debug(Polling mc_ccsr_regs-reg_gsr ...\n);
+ assert(timeout_ms 0);
+ for (;;) {
+ udelay(1000); /* throttle polling */
does this really need to be a whole 1ms?
It is unlikely that the MC fw will boot in less than 1 ms.
is wait_for_mc() only called for the boot command, or all commands?
So, checking more frequently than 1 ms is not necessary.
yes it is, because e.g., if it takes 1.1ms we will have wasted 0.9ms on
this.
How significant is to save 0.9ms of the whole boot time?
As the comment in the code says, the intent was to throttle down the polling,
to reduce traffic on the system bus due to polling. This traffic competes with
the MC itself accessing the system bus, as it boots. Having the polling traffic
get
in the way of the MC traffic may increase the MC boot time. Too small delay
between polls may cause the MC boot time to increase more than the .9ms you
are concerned of wasting in the delay.
What value would you suggest to use for the delay instead 1000ms?
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/7] sunxi: gpio: Indentation fix
Le lundi 23 mars 2015 à 17:21 +0100, Hans de Goede a écrit :
Hi,
Thanks for the patches, I had to make this fixup (squashed) to fix
vbus detect to work on axp221:
-- drivers/gpio/sunxi_gpio.c
--
index 6296092..670af0c 100644
@@ -21,6 +21,9 @@
#ifdef CONFIG_AXP209_POWER
#include axp209.h
#endif
+#ifdef CONFIG_AXP221_POWER
+#include axp221.h
+#endif
DECLARE_GLOBAL_DATA_PTR;
Other then that + adding a small
blurb with some info on the Ainol AW1 board this set has been
merged as is.
Oh you're right, I forgot that one!
The entire set has been queued up in u-boot-sunxi/next for upstream merging.
Thanks a lot!
Regards,
Hans
On 22-03-15 18:07, Paul Kocialkowski wrote:
Signed-off-by: Paul Kocialkowski cont...@paulk.fr
---
arch/arm/include/asm/arch-sunxi/gpio.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index f2c247d..a66e45c 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -84,7 +84,7 @@ struct sunxi_gpio_reg {
#define GPIO_CFG_INDEX(pin) (((pin) 0x1f) 3)
#define GPIO_CFG_OFFSET(pin) pin) 0x1f) 0x7) 2)
-#define GPIO_DRV_INDEX(pin) (((pin) 0x1f) 4)
+#define GPIO_DRV_INDEX(pin)(((pin) 0x1f) 4)
#define GPIO_DRV_OFFSET(pin) pin) 0x1f) 0xf) 1)
#define GPIO_PULL_INDEX(pin) (((pin) 0x1f) 4)
@@ -194,7 +194,7 @@ enum sunxi_gpio_number {
#define SUN8I_GPL3_R_UART_RX 2
#define SUN9I_GPN0_R_RSB_SCK 3
-#define SUN9I_GPN1_R_RSB_SDA3
+#define SUN9I_GPN1_R_RSB_SDA 3
/* GPIO pin pull-up/down config */
#define SUNXI_GPIO_PULL_DISABLE 0
signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: axp221: Use vbus-available rather then vbus-usable for vbus-detect
Hi, On 23-03-15 17:28, Hans de Goede wrote: vbus-usable does not get set if power is provided through the power barrel connector, even if external 5v is also present on the otg connector. vbus-available correctly always reflects if there is 5v present on the otg connector. Except that it also gets set when there is a usb-host cable with a device attached plugged in, so this is going to need some more thinking, I'll send a new patch when I've something which does not break using the port in host mode. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
