Re: [U-Boot] [PATCH 1/4] x86: microcode-tool: Write pure data to the dtsi file
Hi Bin, On 7 August 2015 at 03:28, Bin Meng bmeng...@gmail.com wrote: Currently the microcode-tool writes microcode into a data block as well as the device tree properties which represents the first 48 bytes in the microcode data. Now we change the tool to only write the microcode without device tree stuff so that multiple microcode data blocks can be included in a single property. Signed-off-by: Bin Meng bmeng...@gmail.com --- tools/microcode-tool.py | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) I would rather than we use a tool to pack the microcode together (e.g. ifdtool) rather than changing the source data. I realise that the FSP requires this packing, but I quite dislike the approach of making the source files fit the object files. If you like I can take a look at adding this feature to ifdtool. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] common: Display =4GiB memory bank size
On 6 August 2015 at 02:31, Bin Meng bmeng...@gmail.com wrote: bd-bi_dram[] has both start address and size defined as 32-bit, which is not the case on some platforms where =4GiB memory bank is used. Change them to support such memory banks. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v3: - Use %llx to print the dram start address Changes in v2: - Drop patches which are already applied - Change start to phys_addr_t - Change debug output to either %016llx or %08lx common/board_f.c | 3 ++- include/asm-generic/u-boot.h | 4 ++-- 2 files changed, 4 insertions(+), 3 deletions(-) Acked-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 v3 14/16] drivers/net/vsc9953: Add command for shared/private VLAN learning
Hi Codrin,
On Fri, Jul 24, 2015 at 8:55 AM, Codrin Ciubotariu
codrin.ciubota...@freescale.com wrote:
The command:
ethsw vlan fdb { [help] | show | shared | private }
- make VLAN learning shared or private
configures the FDB to share the FDB entries learned on multiple VLANs
or to keep them separated. By default, the FBD uses private VLAN
learning. This command has also been added to the ethsw generic parser
from common/cmd_ethsw.c
Signed-off-by: Johnson Leung johnson.le...@freescale.com
Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com
---
Changes for v2:
- removed Change-id field;
Changes for v3:
- replaced values returned by functions called by the parser with
CMD_RET_* macros;
- removed CONFIG_ from macros added in vsc9953.h;
- each variabled is declared on a separate line, with one space
instead of tab(s);
common/cmd_ethsw.c| 65 +++
drivers/net/vsc9953.c | 95
+++
include/ethsw.h | 4 +++
include/vsc9953.h | 3 ++
4 files changed, 167 insertions(+)
Acked-by: Joe Hershberger joe.hershber...@ni.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 16/16] drivers/net/vsc9953: Add GPL-2.0+ SPDX-License-Identifier
Hi Codrin, On Fri, Jul 24, 2015 at 8:55 AM, Codrin Ciubotariu codrin.ciubota...@freescale.com wrote: Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com --- Changes for v2: - removed Change-id field; Changes for v3: - this patch also includes the Copyright year updates for the modified values; drivers/net/vsc9953.c | 2 +- include/vsc9953.h | 11 +++ 2 files changed, 4 insertions(+), 9 deletions(-) Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 15/16] drivers/net/vsc9953: Add commands for VLAN ingress filtering
Hi Codrin,
On Fri, Jul 24, 2015 at 8:55 AM, Codrin Ciubotariu
codrin.ciubota...@freescale.com wrote:
The command:
ethsw [port port_no] ingress filtering
{ [help] | show | enable | disable }
- enable/disable VLAN ingress filtering on port
can be used to enable/disable/show VLAN ingress filtering on a port.
This command has also been added to the ethsw generic parser
from common/cmd_ethsw.c
Signed-off-by: Johnson Leung johnson.le...@freescale.com
Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com
---
Changes for v2:
- removed Change-id field;
Changes for v3:
- replaced values returned by functions called by the parser with
CMD_RET_* macros;
- each variabled is declared on a separate line, with one space
instead of tab(s);
- vsc9953_port_ingress_filtering_get() returns enabled value;
common/cmd_ethsw.c| 65 ++
drivers/net/vsc9953.c | 86
+++
include/ethsw.h | 4 +++
3 files changed, 155 insertions(+)
Acked-by: Joe Hershberger joe.hershber...@ni.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: drop optional from target select in favor of ARCH_VERSATILE
Hi Masahiro, On Sat, Aug 1, 2015 at 2:39 AM, Masahiro Yamada yamada.masah...@socionext.com wrote: Since commit a26cd04920dc (arch: Make board selection choices optional), Kconfig could create such an insane .config file that no SoC/board is selected. This is now a real problem for Buildroot, for example. (http://lists.busybox.net/pipermail/buildroot/2015-July/135125.html) Maybe at some time in the future someone should add a new keyword to Kconfig that forces there to be no implicit default when saving_defconfig (so it is not removed from the defconfig), but also not optional (so that if it really is missing, there is a sane default). This commit drops the optional from the ARM target select menu in favor of Versatile family. Rationale: - Historically, Linux chose versatile_defconfig as the default of ARM defconfig. (arch/arm/Makefile of Linux describes: KBUILD_DEFCONFIG := versatile_defconfig) - It was published by ARM Ltd. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 00/11] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Driver model support for these was recently merged. This series does the following: - Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of u-boot.bin) - Remove GPIO platform data (now uses device tree) - Remove serial platform data (now uses device tree) - Enable CONFIG_DM_ETH and CONFIG_DM_USB on Raspberry Pi With Ethernet active the device list looks something like this: U-Boot dm tree Class Probed Name root[ + ]root_driver simple_bus [ + ]|-- soc gpio[ ]| |-- gpio@7e20 serial [ + ]| |-- uart@7e201000 usb [ + ]| `-- usb@7e98 usb_hub [ + ]| `-- usb_hub usb_hub [ + ]| `-- usb_hub eth [ + ]| `-- smsc95xx_eth simple_bus [ ]`-- clocks Changes in v3: - Drop applied patches from series - Drop patch to introduce usbethaddr for driver model - Rename binding file to pl01x.txt Changes in v2: - Add support for Raspberry Pi 2 Simon Glass (11): dm: serial: Update binding for PL01x serial UART arm: rpi: Define CONFIG_TFTP_TSIZE to show tftp size info arm: rpi: Bring in kernel device tree files arm: rpi: Device tree modifications for U-Boot arm: rpi: Add device tree files for Raspberry Pi 2 arm: rpi: Enable device tree control for Rasberry Pi arm: rpi: Enable device tree control for Rasberry Pi 2 arm: rpi: Drop the UART console platform data arm: rpi: Drop the GPIO platform data arm: rpi: Move to driver model for USB arm: rpi: Use driver model for Ethernet arch/arm/dts/Makefile | 3 + arch/arm/dts/bcm2835-rpi-b.dts| 24 arch/arm/dts/bcm2835.dtsi | 35 + arch/arm/dts/bcm2836-rpi-2-b.dts | 30 + arch/arm/dts/bcm2836.dtsi | 42 ++ arch/arm/dts/bcm283x-common.dtsi | 157 ++ arch/arm/dts/bcm283x-rpi.dtsi | 49 +++ arch/arm/dts/stv0991.dts | 2 +- arch/arm/mach-bcm283x/include/mach/gpio.h | 5 - board/raspberrypi/rpi/rpi.c | 24 configs/rpi_2_defconfig | 6 + configs/rpi_defconfig | 6 + doc/device-tree-bindings/arm/bcm/brcm,bcm2835.txt | 8 ++ doc/device-tree-bindings/arm/bcm/brcm,bcm2836.txt | 10 ++ doc/device-tree-bindings/serial/pl01x.txt | 55 +++- drivers/gpio/bcm2835_gpio.c | 20 +++ drivers/serial/serial_pl01x.c | 6 +- include/configs/rpi-common.h | 6 +- include/dt-bindings/pinctrl/bcm2835.h | 27 19 files changed, 474 insertions(+), 41 deletions(-) create mode 100644 arch/arm/dts/bcm2835-rpi-b.dts create mode 100644 arch/arm/dts/bcm2835.dtsi create mode 100644 arch/arm/dts/bcm2836-rpi-2-b.dts create mode 100644 arch/arm/dts/bcm2836.dtsi create mode 100644 arch/arm/dts/bcm283x-common.dtsi create mode 100644 arch/arm/dts/bcm283x-rpi.dtsi create mode 100644 doc/device-tree-bindings/arm/bcm/brcm,bcm2835.txt create mode 100644 doc/device-tree-bindings/arm/bcm/brcm,bcm2836.txt create mode 100644 include/dt-bindings/pinctrl/bcm2835.h -- 2.5.0.rc2.392.g76e840b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx6 move TARGET_xx Kconfig option to mx6 specific Kconfig file
2015-08-07 19:02 GMT+09:00 Marek Vasut ma...@denx.de: On Friday, August 07, 2015 at 09:33:02 AM, Stefano Babic wrote: Hi Peng, Soeren, Hi, On 07/08/2015 09:19, Soeren Moch wrote: Peng, Sorry for being unclear here. In your patch you add several options in arch/arm/cpu/armv7/mx6/Kconfig under MX6 board select. Some of these options are named Support boardname (e.g. Support udoo), while others are simply called boardname (e.g. Bachmann OT1200). I would prefer the simple boardname naming style for all options and remove the word Support from all description strings. But this is only my personal opinion and a minor cosmetic change. Checking in other architecture, I see there is no rule about this. Even in the same Kconfig (AT91), there is a mix with and without Support. Both are ok - decide yourself. The Support is implicit (you won't select it if you didn't want to support that board, would you?), so please use just the board name. The prompts Support lower-case board name were automatically created by tool based on boards.cfg when U-boot switched to Kconfig. Later, some of them were rephrased without Support by hand. In other words, the boards with Support have been untouched since the automatic conversion. Actually, arch/arm/mach-at91/Kconfig has a mix with and without Support. I only rephrased the boards which have device trees in Linux Kernel, because device trees often include official board names. I could not find the better names for the others. Better prompts are always welcome. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 11/11] arm: rpi: Use driver model for Ethernet
Enable CONFIG_DM_ETH so that driver model is used for the USB Ethernet device. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Drop applied patches from series - Drop patch to introduce usbethaddr for driver model Changes in v2: None configs/rpi_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig index 43f5fdd..d523e81 100644 --- a/configs/rpi_defconfig +++ b/configs/rpi_defconfig @@ -11,3 +11,4 @@ CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE=bcm2835-rpi-b CONFIG_USB=y CONFIG_DM_USB=y +CONFIG_DM_ETH=y -- 2.5.0.rc2.392.g76e840b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 09/11] arm: rpi: Drop the GPIO platform data
We can rely on the device tree to provide the GPIO information.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
arch/arm/mach-bcm283x/include/mach/gpio.h | 5 -
board/raspberrypi/rpi/rpi.c | 9 -
drivers/gpio/bcm2835_gpio.c | 20
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-bcm283x/include/mach/gpio.h
b/arch/arm/mach-bcm283x/include/mach/gpio.h
index c8ef8f5..7b4ddc9 100644
--- a/arch/arm/mach-bcm283x/include/mach/gpio.h
+++ b/arch/arm/mach-bcm283x/include/mach/gpio.h
@@ -9,11 +9,6 @@
#ifndef _BCM2835_GPIO_H_
#define _BCM2835_GPIO_H_
-#ifdef CONFIG_BCM2836
-#define BCM2835_GPIO_BASE 0x3f20
-#else
-#define BCM2835_GPIO_BASE 0x2020
-#endif
#define BCM2835_GPIO_COUNT 54
#define BCM2835_GPIO_FSEL_MASK 0x7
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 7de1921..39f451f 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -19,15 +19,6 @@
DECLARE_GLOBAL_DATA_PTR;
-static const struct bcm2835_gpio_platdata gpio_platdata = {
- .base = BCM2835_GPIO_BASE,
-};
-
-U_BOOT_DEVICE(bcm2835_gpios) = {
- .name = gpio_bcm2835,
- .platdata = gpio_platdata,
-};
-
struct msg_get_arm_mem {
struct bcm2835_mbox_hdr hdr;
struct bcm2835_mbox_tag_get_arm_mem get_arm_mem;
diff --git a/drivers/gpio/bcm2835_gpio.c b/drivers/gpio/bcm2835_gpio.c
index fbc641d..f571b0b 100644
--- a/drivers/gpio/bcm2835_gpio.c
+++ b/drivers/gpio/bcm2835_gpio.c
@@ -114,9 +114,29 @@ static int bcm2835_gpio_probe(struct udevice *dev)
return 0;
}
+#ifdef CONFIG_OF_CONTROL
+static int bcm2835_gpio_ofdata_to_platdata(struct udevice *dev)
+{
+ struct bcm2835_gpio_platdata *plat = dev_get_platdata(dev);
+
+ plat-base = dev_get_addr(dev);
+ if (plat-base == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+ return 0;
+}
+
+static const struct udevice_id bcm2835_gpio_id[] = {
+ {.compatible = brcm,bcm2835-gpio},
+ {}
+};
+#endif
+
U_BOOT_DRIVER(gpio_bcm2835) = {
.name = gpio_bcm2835,
.id = UCLASS_GPIO,
+ .of_match = of_match_ptr(bcm2835_gpio_id),
+ .ofdata_to_platdata = of_match_ptr(bcm2835_gpio_ofdata_to_platdata),
.ops= gpio_bcm2835_ops,
.probe = bcm2835_gpio_probe,
.priv_auto_alloc_size = sizeof(struct bcm2835_gpios),
--
2.5.0.rc2.392.g76e840b
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 08/11] arm: rpi: Drop the UART console platform data
We can rely on the device tree to provide the UART information.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
board/raspberrypi/rpi/rpi.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 96fe870..7de1921 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -28,21 +28,6 @@ U_BOOT_DEVICE(bcm2835_gpios) = {
.platdata = gpio_platdata,
};
-static const struct pl01x_serial_platdata serial_platdata = {
-#ifdef CONFIG_BCM2836
- .base = 0x3f201000,
-#else
- .base = 0x20201000,
-#endif
- .type = TYPE_PL011,
- .clock = 300,
-};
-
-U_BOOT_DEVICE(bcm2835_serials) = {
- .name = serial_pl01x,
- .platdata = serial_platdata,
-};
-
struct msg_get_arm_mem {
struct bcm2835_mbox_hdr hdr;
struct bcm2835_mbox_tag_get_arm_mem get_arm_mem;
--
2.5.0.rc2.392.g76e840b
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 07/11] arm: rpi: Enable device tree control for Rasberry Pi 2
Enable device tree control so that we can use driver model fully and avoid using platform data. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: - Add support for Raspberry Pi 2 configs/rpi_2_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig index 139189d..1945a7d 100644 --- a/configs/rpi_2_defconfig +++ b/configs/rpi_2_defconfig @@ -6,3 +6,9 @@ CONFIG_TARGET_RPI_2=y # CONFIG_CMD_FPGA is not set # CONFIG_CMD_SETEXPR is not set CONFIG_PHYS_TO_BUS=y +CONFIG_CMD_NET=y +CONFIG_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE=bcm2836-rpi-2-b +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_DM_ETH=y -- 2.5.0.rc2.392.g76e840b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 04/11] arm: rpi: Device tree modifications for U-Boot
This updates the device tree from the kernel version to something suitable
for U-Boot:
- Add stdout-path alias for console
- Mark the /soc node to be available pre-relocation so that the early serial
console works (we need the 'ranges' property to be available)
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
arch/arm/dts/bcm2835.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/bcm2835.dtsi b/arch/arm/dts/bcm2835.dtsi
index 301c73f..bd6bff6 100644
--- a/arch/arm/dts/bcm2835.dtsi
+++ b/arch/arm/dts/bcm2835.dtsi
@@ -8,6 +8,7 @@
chosen {
bootargs = earlyprintk console=ttyAMA0;
+ stdout-path = uart;
};
soc {
@@ -16,6 +17,7 @@
#size-cells = 1;
ranges = 0x7e00 0x2000 0x0200;
dma-ranges = 0x4000 0x 0x2000;
+ u-boot,dm-pre-reloc;
timer@7e003000 {
compatible = brcm,bcm2835-system-timer;
@@ -92,7 +94,7 @@
#interrupt-cells = 2;
};
- uart@7e201000 {
+ uart: uart@7e201000 {
compatible = brcm,bcm2835-pl011, arm,pl011,
arm,primecell;
reg = 0x7e201000 0x1000;
interrupts = 2 25;
--
2.5.0.rc2.392.g76e840b
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 06/11] arm: rpi: Enable device tree control for Rasberry Pi
Enable device tree control so that we can use driver model fully and avoid using platform data. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: None configs/rpi_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig index db8da68..d22ed78 100644 --- a/configs/rpi_defconfig +++ b/configs/rpi_defconfig @@ -6,3 +6,6 @@ CONFIG_TARGET_RPI=y # CONFIG_CMD_FPGA is not set # CONFIG_CMD_SETEXPR is not set CONFIG_PHYS_TO_BUS=y +CONFIG_CMD_NET=y +CONFIG_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE=bcm2835-rpi-b -- 2.5.0.rc2.392.g76e840b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 10/11] arm: rpi: Move to driver model for USB
Start using driver model for USB on the Raspberry Pi. The dwc2 supports this now so this is just a config change. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: None configs/rpi_defconfig| 2 ++ include/configs/rpi-common.h | 5 - 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig index d22ed78..43f5fdd 100644 --- a/configs/rpi_defconfig +++ b/configs/rpi_defconfig @@ -9,3 +9,5 @@ CONFIG_PHYS_TO_BUS=y CONFIG_CMD_NET=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE=bcm2835-rpi-b +CONFIG_USB=y +CONFIG_DM_USB=y diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h index 733d1ab..8d85e93 100644 --- a/include/configs/rpi-common.h +++ b/include/configs/rpi-common.h @@ -81,11 +81,6 @@ #define CONFIG_CMD_USB #ifdef CONFIG_CMD_USB #define CONFIG_USB_DWC2 -#ifdef CONFIG_BCM2836 -#define CONFIG_USB_DWC2_REG_ADDR 0x3f98 -#else -#define CONFIG_USB_DWC2_REG_ADDR 0x2098 -#endif #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_SMSC95XX -- 2.5.0.rc2.392.g76e840b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] imx: mx6 move TARGET_xx Kconfig option to mx6 specific Kconfig file
On Fri, Aug 7, 2015 at 9:35 AM, Peng Fan peng@freescale.com wrote: Move TARGET_xx Kconfig option based on mx6 to arch/arm/cpu/armv7/mx6/Kconfig. Add enable CONFIG_ARCH_MX6 for boards based on mx6. Then we can choose target boards using make ARCH=arm menuconfig with ARCH_MX6 defined. If using original way, we have no chance to enable ARCH_MX6 when make menuconfig. Even define CONFIG_ARCH_MX6=y in xx_defconfig, kconfig will complains arch/../configs/platinum_titanium_defconfig:3: warning: override: TARGET_PLATINUM_TITANIUM changes choice state Signed-off-by: Peng Fan peng@freescale.com Cc: Stefano Babic sba...@denx.de Cc: Heiko Schocher h...@denx.de Cc: Tim Harvey thar...@gateworks.com Cc: Eric Bénard e...@eukrea.com Cc: Fabio Estevam fabio.este...@freescale.com Cc: Eric Nelson eric.nel...@boundarydevices.com Cc: Marek Vasut ma...@denx.de Cc: Christian Gmeiner christian.gmei...@gmail.com Cc: Stefan Roese s...@denx.de Cc: Soeren Moch sm...@web.de Cc: Otavio Salvador ota...@ossystems.com.br Acked-by: Stefano Babic sba...@denx.de Acked-by: Soeren Moch sm...@web.de Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 05/11] arm: rpi: Add device tree files for Raspberry Pi 2
These are taken from Eric Anholt's April series here:
https://patchwork.kernel.org/patch/6252531/
I doubt they final. We can update then here or bring in the kernel version
when it lands.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2:
- Add support for Raspberry Pi 2
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/bcm2835-rpi-b.dts | 3 +-
arch/arm/dts/bcm2835.dtsi | 161 +
arch/arm/dts/bcm2836-rpi-2-b.dts | 30
arch/arm/dts/bcm2836.dtsi | 42 ++
arch/arm/dts/bcm283x-common.dtsi | 157
.../arm/dts/{bcm2835-rpi.dtsi = bcm283x-rpi.dtsi} | 2 -
doc/device-tree-bindings/arm/bcm/brcm,bcm2835.txt | 8 +
doc/device-tree-bindings/arm/bcm/brcm,bcm2836.txt | 10 ++
9 files changed, 252 insertions(+), 164 deletions(-)
create mode 100644 arch/arm/dts/bcm2836-rpi-2-b.dts
create mode 100644 arch/arm/dts/bcm2836.dtsi
create mode 100644 arch/arm/dts/bcm283x-common.dtsi
rename arch/arm/dts/{bcm2835-rpi.dtsi = bcm283x-rpi.dtsi} (96%)
create mode 100644 doc/device-tree-bindings/arm/bcm/brcm,bcm2835.txt
create mode 100644 doc/device-tree-bindings/arm/bcm/brcm,bcm2836.txt
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 949048c..8d25596 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -52,7 +52,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
zynq-zc770-xm013.dtb
dtb-$(CONFIG_AM33XX) += am335x-boneblack.dtb
-dtb-$(CONFIG_ARCH_BCM283X) += bcm2835-rpi-b.dtb
+dtb-$(CONFIG_ARCH_BCM283X) += bcm2835-rpi-b.dtb \
+ bcm2836-rpi-2-b.dtb
dtb-$(CONFIG_ARCH_SOCFPGA) += \
socfpga_arria5_socdk.dtb\
diff --git a/arch/arm/dts/bcm2835-rpi-b.dts b/arch/arm/dts/bcm2835-rpi-b.dts
index ee89b79..58d3520 100644
--- a/arch/arm/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/dts/bcm2835-rpi-b.dts
@@ -1,5 +1,6 @@
/dts-v1/;
-#include bcm2835-rpi.dtsi
+#include bcm2835.dtsi
+#include bcm283x-rpi.dtsi
/ {
compatible = raspberrypi,model-b, brcm,bcm2835;
diff --git a/arch/arm/dts/bcm2835.dtsi b/arch/arm/dts/bcm2835.dtsi
index bd6bff6..dd2ce18 100644
--- a/arch/arm/dts/bcm2835.dtsi
+++ b/arch/arm/dts/bcm2835.dtsi
@@ -1,5 +1,6 @@
#include dt-bindings/pinctrl/bcm2835.h
#include skeleton.dtsi
+#include bcm283x-common.dtsi
/ {
compatible = brcm,bcm2835;
@@ -26,169 +27,9 @@
clock-frequency = 100;
};
- dma: dma@7e007000 {
- compatible = brcm,bcm2835-dma;
- reg = 0x7e007000 0xf00;
- interrupts = 1 16,
-1 17,
-1 18,
-1 19,
-1 20,
-1 21,
-1 22,
-1 23,
-1 24,
-1 25,
-1 26,
-1 27,
-1 28;
-
- #dma-cells = 1;
- brcm,dma-channel-mask = 0x7f35;
- };
-
- intc: interrupt-controller@7e00b200 {
- compatible = brcm,bcm2835-armctrl-ic;
- reg = 0x7e00b200 0x200;
- interrupt-controller;
- #interrupt-cells = 2;
- };
-
- watchdog@7e10 {
- compatible = brcm,bcm2835-pm-wdt;
- reg = 0x7e10 0x28;
- };
-
- rng@7e104000 {
- compatible = brcm,bcm2835-rng;
- reg = 0x7e104000 0x10;
- };
-
- mailbox: mailbox@7e00b800 {
- compatible = brcm,bcm2835-mbox;
- reg = 0x7e00b880 0x40;
- interrupts = 0 1;
- #mbox-cells = 0;
- };
-
- gpio: gpio@7e20 {
- compatible = brcm,bcm2835-gpio;
- reg = 0x7e20 0xb4;
- /*
-* The GPIO IP block is designed for 3 banks of GPIOs.
-* Each bank has a GPIO interrupt for itself.
-* There is an overall any bank interrupt.
-* In order, these are GIC interrupts 17, 18, 19, 20.
-* Since the BCM2835 only has 2 banks, the 2nd bank
-* interrupt output appears to be mirrored onto the
-* 3rd bank's interrupt signal.
-* So, a bank0 interrupt shows up on 17, 20, and
[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART
This binding differs from that of Linux. Update it and change existing
users.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3:
- Rename binding file to pl01x.txt
Changes in v2: None
arch/arm/dts/stv0991.dts | 2 +-
doc/device-tree-bindings/serial/pl01x.txt | 55 ---
drivers/serial/serial_pl01x.c | 6 ++--
3 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/arch/arm/dts/stv0991.dts b/arch/arm/dts/stv0991.dts
index fa3fd64..d20c87a 100644
--- a/arch/arm/dts/stv0991.dts
+++ b/arch/arm/dts/stv0991.dts
@@ -18,7 +18,7 @@
uart0: serial@0x80406000 {
compatible = arm,pl011, arm,primecell;
reg = 0x80406000 0x1000;
- clock = 270;
+ clock-frequency = 270;
};
aliases {
diff --git a/doc/device-tree-bindings/serial/pl01x.txt
b/doc/device-tree-bindings/serial/pl01x.txt
index 61c27d1..4483553 100644
--- a/doc/device-tree-bindings/serial/pl01x.txt
+++ b/doc/device-tree-bindings/serial/pl01x.txt
@@ -1,7 +1,54 @@
-* ARM AMBA Primecell PL011 PL010 serial UART
+* ARM AMBA Primecell PL011 serial UART
Required properties:
-- compatible: must be arm,primecell, arm,pl011 or arm,pl010
+- compatible: must be arm,primecell, arm,pl011
- reg: exactly one register range with length 0x1000
-- clock: input clock frequency for the UART (used to calculate the baud
- rate divisor)
+- interrupts: exactly one interrupt specifier
+
+Optional properties:
+- pinctrl:
+ When present, must have one state named default,
+ and may contain a second name named sleep. The former
+ state sets up pins for ordinary operation whereas
+ the latter state will put the associated pins to sleep
+ when the UART is unused
+- clocks:
+ When present, the first clock listed must correspond to
+ the clock named UARTCLK on the IP block, i.e. the clock
+ to the external serial line, whereas the second clock
+ must correspond to the PCLK clocking the internal logic
+ of the block. Just listing one clock (the first one) is
+ deprecated.
+- clocks-names:
+ When present, the first clock listed must be named
+ uartclk and the second clock listed must be named
+ apb_pclk
+- dmas:
+ When present, may have one or two dma channels.
+ The first one must be named rx, the second one
+ must be named tx.
+- auto-poll:
+ Enables polling when using RX DMA.
+- poll-rate-ms:
+ Rate at which poll occurs when auto-poll is set,
+ default 100ms.
+- poll-timeout-ms:
+ Poll timeout when auto-poll is set, default
+ 3000ms.
+- clock-frequency:
+ Input clock frequency for UART. This is optional in Linux but
required
+ in U-Boot.
+
+See also bindings/arm/primecell.txt
+
+Example:
+
+uart@8012 {
+ compatible = arm,pl011, arm,primecell;
+ reg = 0x8012 0x1000;
+ interrupts = 0 11 IRQ_TYPE_LEVEL_HIGH;
+ dmas = dma 13 0 0x2, dma 13 0 0x0;
+ dma-names = rx, tx;
+ clocks = foo_clk, bar_clk;
+ clock-names = uartclk, apb_pclk;
+};
diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
index ad503af..ae6fc0e 100644
--- a/drivers/serial/serial_pl01x.c
+++ b/drivers/serial/serial_pl01x.c
@@ -365,13 +365,15 @@ static int pl01x_serial_ofdata_to_platdata(struct udevice
*dev)
struct pl01x_serial_platdata *plat = dev_get_platdata(dev);
fdt_addr_t addr;
- addr = fdtdec_get_addr(gd-fdt_blob, dev-of_offset, reg);
+ addr = dev_get_addr(dev);
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
plat-base = addr;
- plat-clock = fdtdec_get_int(gd-fdt_blob, dev-of_offset, clock, 1);
+ plat-clock = fdtdec_get_int(gd-fdt_blob, dev-of_offset,
+clock-frequency, 1);
plat-type = dev_get_driver_data(dev);
+
return 0;
}
#endif
--
2.5.0.rc2.392.g76e840b
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 03/11] arm: rpi: Bring in kernel device tree files
Bring in the device tree files from Linux v4.1.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
arch/arm/dts/Makefile | 2 +
arch/arm/dts/bcm2835-rpi-b.dts| 23
arch/arm/dts/bcm2835-rpi.dtsi | 51 +
arch/arm/dts/bcm2835.dtsi | 192 ++
include/dt-bindings/pinctrl/bcm2835.h | 27 +
5 files changed, 295 insertions(+)
create mode 100644 arch/arm/dts/bcm2835-rpi-b.dts
create mode 100644 arch/arm/dts/bcm2835-rpi.dtsi
create mode 100644 arch/arm/dts/bcm2835.dtsi
create mode 100644 include/dt-bindings/pinctrl/bcm2835.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2df957c..949048c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -52,6 +52,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
zynq-zc770-xm013.dtb
dtb-$(CONFIG_AM33XX) += am335x-boneblack.dtb
+dtb-$(CONFIG_ARCH_BCM283X) += bcm2835-rpi-b.dtb
+
dtb-$(CONFIG_ARCH_SOCFPGA) += \
socfpga_arria5_socdk.dtb\
socfpga_cyclone5_socdk.dtb \
diff --git a/arch/arm/dts/bcm2835-rpi-b.dts b/arch/arm/dts/bcm2835-rpi-b.dts
new file mode 100644
index 000..ee89b79
--- /dev/null
+++ b/arch/arm/dts/bcm2835-rpi-b.dts
@@ -0,0 +1,23 @@
+/dts-v1/;
+#include bcm2835-rpi.dtsi
+
+/ {
+ compatible = raspberrypi,model-b, brcm,bcm2835;
+ model = Raspberry Pi Model B;
+
+ leds {
+ act {
+ gpios = gpio 16 1;
+ };
+ };
+};
+
+gpio {
+ pinctrl-0 = gpioout alt0 i2s_alt2 alt3;
+
+ /* I2S interface */
+ i2s_alt2: i2s_alt2 {
+ brcm,pins = 28 29 30 31;
+ brcm,function = BCM2835_FSEL_ALT2;
+ };
+};
diff --git a/arch/arm/dts/bcm2835-rpi.dtsi b/arch/arm/dts/bcm2835-rpi.dtsi
new file mode 100644
index 000..46780bb
--- /dev/null
+++ b/arch/arm/dts/bcm2835-rpi.dtsi
@@ -0,0 +1,51 @@
+#include bcm2835.dtsi
+
+/ {
+ memory {
+ reg = 0 0x1000;
+ };
+
+ leds {
+ compatible = gpio-leds;
+
+ act {
+ label = ACT;
+ default-state = keep;
+ linux,default-trigger = heartbeat;
+ };
+ };
+};
+
+gpio {
+ pinctrl-names = default;
+
+ gpioout: gpioout {
+ brcm,pins = 6;
+ brcm,function = BCM2835_FSEL_GPIO_OUT;
+ };
+
+ alt0: alt0 {
+ brcm,pins = 0 1 2 3 4 5 7 8 9 10 11 14 15 40 45;
+ brcm,function = BCM2835_FSEL_ALT0;
+ };
+
+ alt3: alt3 {
+ brcm,pins = 48 49 50 51 52 53;
+ brcm,function = BCM2835_FSEL_ALT3;
+ };
+};
+
+i2c0 {
+ status = okay;
+ clock-frequency = 10;
+};
+
+i2c1 {
+ status = okay;
+ clock-frequency = 10;
+};
+
+sdhci {
+ status = okay;
+ bus-width = 4;
+};
diff --git a/arch/arm/dts/bcm2835.dtsi b/arch/arm/dts/bcm2835.dtsi
new file mode 100644
index 000..301c73f
--- /dev/null
+++ b/arch/arm/dts/bcm2835.dtsi
@@ -0,0 +1,192 @@
+#include dt-bindings/pinctrl/bcm2835.h
+#include skeleton.dtsi
+
+/ {
+ compatible = brcm,bcm2835;
+ model = BCM2835;
+ interrupt-parent = intc;
+
+ chosen {
+ bootargs = earlyprintk console=ttyAMA0;
+ };
+
+ soc {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0x7e00 0x2000 0x0200;
+ dma-ranges = 0x4000 0x 0x2000;
+
+ timer@7e003000 {
+ compatible = brcm,bcm2835-system-timer;
+ reg = 0x7e003000 0x1000;
+ interrupts = 1 0, 1 1, 1 2, 1 3;
+ clock-frequency = 100;
+ };
+
+ dma: dma@7e007000 {
+ compatible = brcm,bcm2835-dma;
+ reg = 0x7e007000 0xf00;
+ interrupts = 1 16,
+1 17,
+1 18,
+1 19,
+1 20,
+1 21,
+1 22,
+1 23,
+1 24,
+1 25,
+1 26,
+1 27,
+1 28;
+
+ #dma-cells = 1;
+ brcm,dma-channel-mask = 0x7f35;
+ };
+
+ intc: interrupt-controller@7e00b200 {
+ compatible = brcm,bcm2835-armctrl-ic;
+ reg = 0x7e00b200 0x200;
+
[U-Boot] [PATCH v3 02/11] arm: rpi: Define CONFIG_TFTP_TSIZE to show tftp size info
This shows a proper progress display and the total amount of data transferred. Enable it for Raspberry Pi. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: None include/configs/rpi-common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h index 1012cdd..733d1ab 100644 --- a/include/configs/rpi-common.h +++ b/include/configs/rpi-common.h @@ -89,6 +89,7 @@ #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_SMSC95XX +#define CONFIG_TFTP_TSIZE #define CONFIG_MISC_INIT_R #endif -- 2.5.0.rc2.392.g76e840b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/16] drivers/net/vsc9953: Add default configuration for VSC9953 L2 Switch
Hi Codrin, On Fri, Jul 24, 2015 at 8:55 AM, Codrin Ciubotariu codrin.ciubota...@freescale.com wrote: At startup, the default configuration should be: - enable HW learning on all ports (HW default); - all ports are VLAN aware; - all ports are members of VLAN 1; - all ports have Port-based VLAN 1; - on all ports, the switch is allowed to remove maximum one VLAN tag, - on egress, the switch should add a VLAN tag if the frame is classified to a different VLAN than the port's Port-based VLAN; Signed-off-by: Johnson Leung johnson.le...@freescale.com Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com --- Changes for v2: - removed Change-id field; Changes for v3: - moved the copyright update in the last patch; - return -EBUSY if the VLAN table is not ready; - each variable is declared on a new line, without tabs; - renamed variable set to set_member; - removed unnecessary brackets; - renamed some VSC9953_TAG_CFG_* macros; - removed field_set() and field_get() macros; - removed CONFIG_ from some macros' name; - removed port_' from members of struct vsc9953_rew_port; - modified a comment describing struct vsc9953_rew_reg; drivers/net/vsc9953.c | 253 ++ include/vsc9953.h | 56 +++ 2 files changed, 309 insertions(+) Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/16] common/cmd_ethsw: Add generic commands for Ethernet Switches
Hi Codrin,
On Fri, Jul 24, 2015 at 8:55 AM, Codrin Ciubotariu
codrin.ciubota...@freescale.com wrote:
This patch creates a flexible parser for Ethernet Switch
configurations that should support complex commands.
The parser searches for predefined keywords in the command
and calls the proper function when a match is found.
Also, the parser allows for optional keywords, such as
port, to apply the command on a port
or on all ports. For now, the defined commands are:
ethsw [port port_no] { enable | disable | show }
Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com
---
Changes for v3:
- parser removed from previous patch:
drivers/net/vsc9953: Refractor the parser for VSC9953 commands;
- removed member err from struct command_def;
- using CMD_RET_* macros instead of magic numbers;
- moved each variable declaration on a separate line, with a single
space;
- the code from functions cmd_keywords*_check() should be more clear
now;
- removed unused function command_def_cleanup();
common/Makefile| 1 +
common/cmd_ethsw.c | 346
+
include/ethsw.h| 48
3 files changed, 395 insertions(+)
create mode 100644 common/cmd_ethsw.c
create mode 100644 include/ethsw.h
diff --git a/common/Makefile b/common/Makefile
index d6c1d48..f0b4eec 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -211,6 +211,7 @@ obj-$(CONFIG_UPDATE_TFTP) += update.o
obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
obj-$(CONFIG_CMD_DFU) += cmd_dfu.o
obj-$(CONFIG_CMD_GPT) += cmd_gpt.o
+obj-$(CONFIG_CMD_ETHSW) += cmd_ethsw.o
# Power
obj-$(CONFIG_CMD_PMIC) += cmd_pmic.o
diff --git a/common/cmd_ethsw.c b/common/cmd_ethsw.c
new file mode 100644
index 000..ebeaae0
--- /dev/null
+++ b/common/cmd_ethsw.c
@@ -0,0 +1,346 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ *
+ * Ethernet Switch commands
+ */
+
+#include common.h
+#include command.h
+#include errno.h
+#include ethsw.h
+
+static const char *ethsw_name;
+
+static struct keywords_to_function {
+ enum ethsw_keyword_id cmd_keyword[ETHSW_MAX_CMD_PARAMS];
+ int cmd_func_offset;
+ int (*keyword_function)(struct ethsw_command_def *parsed_cmd);
+} ethsw_cmd_def[] = {
+ {
+ .cmd_keyword = {
+ ethsw_id_enable,
+ ethsw_id_key_end,
+ },
+ .cmd_func_offset = offsetof(struct ethsw_command_func,
+ port_enable),
+ .keyword_function = NULL,
+ }, {
+ .cmd_keyword = {
+ ethsw_id_disable,
+ ethsw_id_key_end,
+ },
+ .cmd_func_offset = offsetof(struct ethsw_command_func,
+ port_disable),
+ .keyword_function = NULL,
+ }, {
+ .cmd_keyword = {
+ ethsw_id_show,
+ ethsw_id_key_end,
+ },
+ .cmd_func_offset = offsetof(struct ethsw_command_func,
+ port_show),
+ .keyword_function = NULL,
+ },
+};
+
+struct keywords_optional {
+ int cmd_keyword[ETHSW_MAX_CMD_PARAMS];
+} cmd_opt_def[] = {
+ {
+ .cmd_keyword = {
+ ethsw_id_port,
+ ethsw_id_port_no,
+ ethsw_id_key_end,
+ },
+ },
+};
+
+static int keyword_match_gen(enum ethsw_keyword_id key_id, int argc, char
+*const argv[], int *argc_nr,
+struct ethsw_command_def *parsed_cmd);
+static int keyword_match_port(enum ethsw_keyword_id key_id, int argc,
+ char *const argv[], int *argc_nr,
+ struct ethsw_command_def *parsed_cmd);
+
+/*
+ * Define properties for each keyword;
+ * keep the order synced with enum ethsw_keyword_id
+ */
+struct keyword_def {
+ const char *keyword_name;
+ int (*match)(enum ethsw_keyword_id key_id, int argc, char *const
argv[],
+int *argc_nr, struct ethsw_command_def *parsed_cmd);
+} keyword[] = {
+ {
+ .keyword_name = help,
+ .match = keyword_match_gen,
+ }, {
+
Re: [U-Boot] [PATCH v3 10/16] drivers/net/vsc9953: Add commands to enable/disable HW learning
Hi Codrin,
On Fri, Jul 24, 2015 at 8:55 AM, Codrin Ciubotariu
codrin.ciubota...@freescale.com wrote:
The command:
ethsw [port port_no] learning { [help] | show | auto | disable }
can be used to enable/disable HW learning on a port.
This patch also adds this command to the generic ethsw parser from
cmd_ethsw.
Signed-off-by: Johnson Leung johnson.le...@freescale.com
Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com
---
Changes for v2:
- removed Change-id field;
Changes for v3:
- replaced values returned by functions called by the parser with
CMD_RET_* macros;
- removed CONFIG_ from macros added in vsc9953.h;
- each variabled is declared on a separate line, with one space
instead of tab(s);
common/cmd_ethsw.c| 60 +
drivers/net/vsc9953.c | 141
++
include/ethsw.h | 4 ++
include/vsc9953.h | 6 +++
4 files changed, 211 insertions(+)
Acked-by: Joe Hershberger joe.hershber...@ni.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/16] net/eth.c: Add function to validate a MAC address
Hi Codrin, On Fri, Jul 24, 2015 at 8:55 AM, Codrin Ciubotariu codrin.ciubota...@freescale.com wrote: The code from common/env_flags.c that checks if a string has the format of a MAC address has been moved in net/eth.c as a separate function called eth_validate_ethaddr_str(). Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com --- Changes for v3: - none, new patch; common/env_flags.c | 15 ++- include/net.h | 1 + net/eth.c | 30 ++ 3 files changed, 33 insertions(+), 13 deletions(-) Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/16] drivers/net/vsc9953: Add VLAN commands for VSC9953
Hi Codrin,
On Fri, Jul 24, 2015 at 8:55 AM, Codrin Ciubotariu
codrin.ciubota...@freescale.com wrote:
The new added commands can be used to configure VLANs for a port
on both ingress and egress.
The new commands are:
ethsw [port port_no] pvid { [help] | show | pvid }
- set/show PVID (ingress and egress VLAN tagging) for a port;
ethsw [port port_no] vlan { [help] | show | add vid | del vid }
- add a VLAN to a port (VLAN members);
ethsw [port port_no] untagged { [help] | show | all | none | pvid }
- set egress tagging mod for a port
ethsw [port port_no] egress tag { [help] | show | pvid | classified }
- Configure VID source for egress tag. Tag's VID could be the
frame's classified VID or the PVID of the port
These commands have also been added to the ethsw generic parser from
common/cmd_ethsw.c
Signed-off-by: Johnson Leung johnson.le...@freescale.com
Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com
---
Changes for v2:
- removed Change-id field;
Changes for v3:
- replaced values returned by functions called by the parser with
CMD_RET_* macros;
- removed CONFIG_ from macros added in vsc9953.h;
- each variabled is declared on a separate line, with one space
instead of tab(s);
- removed unecessary brackets;
- typo fix in comment: Shiw;
common/cmd_ethsw.c| 270
drivers/net/vsc9953.c | 478
++
include/ethsw.h | 16 ++
include/vsc9953.h | 3 +
4 files changed, 767 insertions(+)
Acked-by: Joe Hershberger joe.hershber...@ni.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/16] drivers/net/vsc9953: Add commands to manipulate the FDB for VSC9953
Hi Codrin,
On Fri, Jul 24, 2015 at 8:55 AM, Codrin Ciubotariu
codrin.ciubota...@freescale.com wrote:
The new command:
ethsw [port port_no] [vlan vid] fdb
{ [help] | show | flush | { add | del } mac }
Can be used to add and delete FDB entries. Also, the command can be used
to show entries from the FDB tables. When used with [port port_no]
and [vlan vid], only the matching the FDB entries can be seen or
flushed. The command has also been added to the generic ethsw parser
from cmd_ethsw.c.
Signed-off-by: Johnson Leung johnson.le...@freescale.com
Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com
---
Changes for v2:
- removed Change-id field;
Changes for v3:
- replaced values returned by functions called by the parser with
CMD_RET_* macros;
- removed CONFIG_ from macros added in vsc9953.h;
- each variabled is declared on a separate line, with one space
instead of tab(s);
- vsc9953_mac_table_poll_idle() returns -EBUSY if the table is not
idle;
- the array used to hold the MAC address (mac_addr) has been renamed
to ethaddr
and is allocated statically instead of dynamically;
- reformulate definition of VSC9953_FDB_HELP macro;
- used the function added by previous patch to check if a string has
the format
of a MAC address;
common/cmd_ethsw.c| 177 +++
drivers/net/vsc9953.c | 473
++
include/ethsw.h | 15 ++
include/vsc9953.h | 28 +++
4 files changed, 693 insertions(+)
Acked-by: Joe Hershberger joe.hershber...@ni.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/16] drivers/net/vsc9953: Add command to show/clear port counters
Hi Codrin,
On Fri, Jul 24, 2015 at 8:55 AM, Codrin Ciubotariu
codrin.ciubota...@freescale.com wrote:
The new added command:
ethsw [port port_no] statistics { [help] | [clear] }
will print counters like the number of Rx/Tx frames,
number of Rx/Tx bytes, number of Rx/Tx unicast frames, etc.
This patch also adds this commnd in the genereric ethsw
parser from cmd_ethsw.c
Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com
---
Changes for v2:
- removed Change-id field;
Changes for v3:
- moved each variable declaration on a separate line, with one space
only;
- replaced magic numbers on functions called by the parser with
CMD_RET_* macros;
common/cmd_ethsw.c| 42 +
drivers/net/vsc9953.c | 256
++
include/ethsw.h | 4 +
include/vsc9953.h | 116 ++-
4 files changed, 415 insertions(+), 3 deletions(-)
Acked-by: Joe Hershberger joe.hershber...@ni.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/16] include/bitfield: Add new bitfield operations
Hi Codrin, On Fri, Jul 24, 2015 at 8:55 AM, Codrin Ciubotariu codrin.ciubota...@freescale.com wrote: These new operations allow manipulation of bitfields within a word by using a mask instead of width and shift values to extract/replace the bitfields. Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com --- Changes for v3: - none; new patch; include/bitfield.h | 32 1 file changed, 32 insertions(+) Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/16] drivers/net/vsc9953: Use the generic Ethernet Switch parser
Hi Codrin, On Fri, Jul 24, 2015 at 8:55 AM, Codrin Ciubotariu codrin.ciubota...@freescale.com wrote: This patch replaces the parser used by VSC9953 L2 Switch driver with the generic one. Also, the config macro that enables the VSC9953 commands has been replaced in all the platforms that use this driver with the config macro that corresponds to the generic parser. Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com --- Changes for v3: - this patch was extracted from previous patch: drivers/net/vsc9953: Refractor the parser for VSC9953 commands; - used CMD_RET_* macros instead of magic numbers; - each variable is declared on a new line, with one space only; drivers/net/vsc9953.c | 349 + include/configs/T104xRDB.h | 2 +- 2 files changed, 166 insertions(+), 185 deletions(-) Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] arm: socfpga: scan: Introduce generic JTAG accessor
On 8/3/15 9:22 AM, Marek Vasut wrote: Introduce generic function for accessing the JTAG scan chains in the SCC manager. Make use of this function throughout the SCC manager to replace the ad-hoc writes to registers and make the code less cryptic. Signed-off-by: Marek Vasut ma...@denx.de --- arch/arm/mach-socfpga/scan_manager.c | 104 +-- 1 file changed, 63 insertions(+), 41 deletions(-) Acked-by: Dinh Nguyen dingu...@opensource.altera.com Thanks, Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] gpio: Add DW APB GPIO driver
Hi Marek,
On 7 August 2015 at 14:35, Marek Vasut ma...@denx.de wrote:
On Friday, August 07, 2015 at 09:13:45 PM, Simon Glass wrote:
Hi Marek,
Hi!
On 5 August 2015 at 19:49, Marek Vasut ma...@denx.de wrote:
On Wednesday, August 05, 2015 at 04:39:33 PM, Simon Glass wrote:
Hi Marek,
Hi Simon,
[...]
It's up to you. Normally each bank has a name and the datasheet
specifies it. In your case if not you could think about a naming
scheme.
Can you please take a look into arch/arm/dts/socfpga.dtsi ?
The system has three GPIO controllers (look for gpio0, gpio1, gpio2)
and each of these controllers has one bank (porta, portb, portc) .
I can name my gpios portxN , where x is either of a,b,c and N is the
GPIO number. The problem is, I cannot determine in dwapb_gpio_bind()
which one is porta, portb and portc because all I have is the
physical addess of the GPIO controller and the index of the bank in
the namespace of that controller.
Sure, I can do some sort of global counting in the driver, but I would
like to avoid that sort of thing. I can also add some kind of ad-hoc DT
prop, but that's also not a good idea I think. Do you have any suggestion
for me please ?
One option is to use the device tree node name but it isn't very
friendly - gpio0@x.
That's what I do now pretty much.
You could perhaps add a new property like 'bank-name'?
Do we want to add ad-hoc DT nodes which are
a) Not describing hardware
b) Not part of the official DT bindings for that platform
?
Is that really a way to go ?
[...]
It needs to be part of the official binding. Naming the hardware is
part of the hardware definition - see for example the regulator-name
property for regulators.
Another option is to use an alias:
aliases {
gpio0 = gpio_0;
gpio1 = gpio_1;
gpio2 = gpio_2;
}
Then you can turn gpio0 into bank A, gpio1 into bank B, etc.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] arm: socfpga: scan: Clean up horrible macros
On 8/3/15 9:22 AM, Marek Vasut wrote: Clean up the horrible macros present in the scan_manager.h . Firstly, the function scan_mgr_io_scan_chain_prg() is static, yet all the macros are used only within it, thus there is no point in having them in the header file. Moreover, the macros are just making the code much less readable, so remove them instead. Signed-off-by: Marek Vasut ma...@denx.de --- arch/arm/mach-socfpga/include/mach/scan_manager.h | 42 arch/arm/mach-socfpga/scan_manager.c | 47 --- 2 files changed, 17 insertions(+), 72 deletions(-) Acked-by: Dinh Nguyen dingu...@opensource.altera.com Thanks, Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] ARM: tegra: represent RAM in 1 or 2 banks
From: Stephen Warren swar...@nvidia.com
Represent all available RAM in either one or two banks. The first bank
describes any RAM below 4GB. The second bank describes any RAM above 4GB.
This split is driven by the following requirements:
- The NVIDIA L4T kernel requires separate entries in the DT /memory/reg
property for memory below and above the 4GB boundary. The layout of that
DT property is directly driven by the entries in the U-Boot bank array.
- On systems with RAM beyond a physical address of 4GB, the potential
existence of a carve-out at the end of RAM below 4GB can only be
represented using multiple banks, since usable RAM is not contiguous.
While making this change, add a lot more comments re: how and why RAM is
represented in banks, and implement a few more semantic functions that
define (and perhaps later detect at run-time) the size of any carve-out.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
arch/arm/mach-tegra/board2.c | 120 -
include/configs/tegra-common.h | 2 +-
2 files changed, 107 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
index 37953cfda8a1..8ecc67459a10 100644
--- a/arch/arm/mach-tegra/board2.c
+++ b/arch/arm/mach-tegra/board2.c
@@ -10,6 +10,7 @@
#include errno.h
#include ns16550.h
#include linux/compiler.h
+#include linux/sizes.h
#include asm/io.h
#include asm/arch/clock.h
#ifdef CONFIG_LCD
@@ -287,27 +288,118 @@ void pad_init_mmc(struct mmc_host *host)
}
#endif /* MMC */
+/*
+ * In some SW environments, a memory carve-out exists to house a secure
+ * monitor, a trusted OS, and/or various statically allocated media buffers.
+ *
+ * This carveout exists at the highest possible address that is within a
+ * 32-bit physical address space.
+ *
+ * This function returns the total size of this carve-out. At present, the
+ * returned value is hard-coded for simplicity. In the future, it may be
+ * possible to determine the carve-out size:
+ * - By querying some run-time information source, such as:
+ * - A structure passed to U-Boot by earlier boot software.
+ * - SoC registers.
+ * - A call into the secure monitor.
+ * - In the per-board U-Boot configuration header, based on knowledge of the
+ * SW environment that U-Boot is being built for.
+ *
+ * For now, we support two configurations in U-Boot:
+ * - 32-bit ports without any form of carve-out.
+ * - 64 bit ports which are assumed to use a carve-out of a conservatively
+ * hard-coded size.
+ */
+static ulong carveout_size(void)
+{
#ifdef CONFIG_ARM64
+ return SZ_512M;
+#else
+ return 0;
+#endif
+}
+
+/*
+ * Determine the amount of usable RAM below 4GiB, taking into account any
+ * carve-out that may be assigned.
+ */
+static ulong usable_ram_size_below_4g(void)
+{
+ ulong total_size_below_4g;
+ ulong usable_size_below_4g;
+
+ /*
+* The total size of RAM below 4GiB is the lesser address of:
+* (a) 2GiB itself (RAM starts at 2GiB, and 4GiB - 2GiB == 2GiB).
+* (b) The size RAM physically present in the system.
+*/
+ if (gd-ram_size SZ_2G)
+ total_size_below_4g = gd-ram_size;
+ else
+ total_size_below_4g = SZ_2G;
+
+ /* Calculate usable RAM by subtracting out any carve-out size */
+ usable_size_below_4g = total_size_below_4g - carveout_size();
+
+ return usable_size_below_4g;
+}
+
+/*
+ * Represent all available RAM in either one or two banks.
+ *
+ * The first bank describes any usable RAM below 4GiB.
+ * The second bank describes any RAM above 4GiB.
+ *
+ * This split is driven by the following requirements:
+ * - The NVIDIA L4T kernel requires separate entries in the DT /memory/reg
+ * property for memory below and above the 4GiB boundary. The layout of that
+ * DT property is directly driven by the entries in the U-Boot bank array.
+ * - The potential existence of a carve-out at the end of RAM below 4GiB can
+ * only be represented using multiple banks.
+ *
+ * Explicitly removing the carve-out RAM from the bank entries makes the RAM
+ * layout a bit more obvious, e.g. when running bdinfo at the U-Boot
+ * command-line.
+ *
+ * This does mean that the DT U-Boot passes to the Linux kernel will not
+ * include this RAM in /memory/reg at all. An alternative would be to include
+ * all RAM in the U-Boot banks (and hence DT), and add a /memreserve/ node
+ * into DT to stop the kernel from using the RAM. IIUC, I don't /think/ the
+ * Linux kernel will ever need to access any RAM in* the carve-out via a CPU
+ * mapping, so either way is acceptable.
+ *
+ * On 32-bit systems, we never define a bank for RAM above 4GiB, since the
+ * start address of that bank cannot be represented in the 32-bit .size
+ * field.
+ */
+void dram_init_banksize(void)
+{
+ gd-bd-bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+ gd-bd-bi_dram[0].size = usable_ram_size_below_4g();
+
+#ifdef
Re: [U-Boot] [PATCH v3 07/16] common/cmd_ethsw: Add generic commands for Ethernet Switches
On 08/07/2015 01:18 PM, Joe Hershberger wrote: snip + } + + /* if all our optional command's keywords perfectly match an +* optional pattern, then we can move to the next defined +* keywords in our command; remember the one that matched the +* greatest number of keywords +*/ Improper comment format. Please make sure you always run your patches through checkpatch.pl. I recommend using patman! Joe, Do you mean the multiple-line comment should start from the second line? I can change it when I merge the patch. Checkpatch/patman doesn't complain about this format. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot FIT image support
Simon, I was doing an experiment to put the load address and entry address of Linux to higher than 32-bit address. I found it is broken to process more than 32-bit addresses. When I attempted to fix it, I was troubled by those code used for both host and target, like common/image-fit.c. For example, to process 64-bit address, the function int fit_image_get_load(const void *fit, int noffset, ulong *load) should be converted to int fit_image_get_load(const void *fit, int noffset, uint64_t *load) ulong is 64-bit for 64-bit target such as ARMv8, but it can be 32-bit on host. If I use uint64_t, all related code in bootm and others need to change. Before I go too far, I'd like to check if anyone has tried to enable this in FIT image. #address-cells = 2; I can try to use uint64_t in place of ulong for all related code if that's right. That will be a lot of change. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-dm
On Thu, Aug 06, 2015 at 04:49:13PM -0600, Simon Glass wrote: Hi Tom, This includes some driver model support for devres (managed device resource framework), I2C multiplexers, some PMIC framework improvements and USB Ethernet additions. It also includes support for spring (Exynos5-based Chromebook) as requested by Minkyu (Samsung maintainer). The following changes since commit a5325cd5e91f77a2214e80198ae31c1d8b7e7c3c: configs: Remove CONFIG_SERIAL_MULTI (2015-08-05 14:12:42 -0400) are available in the git repository at: git://git.denx.de/u-boot-dm.git for you to fetch changes up to fac971b2b5efbdb6ed2d12ebdbf7e029c5ed30e8: exynos: dts: Correct LDO and BUCK naming (2015-08-06 07:44:30 -0600) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] ARM: tegra: move kernel_addr_r on T210
From: Stephen Warren swar...@nvidia.com The new value is the most likely value where the kernel wants to end up at run-time. Selecting this value as the load address likely avoids the need to copy the kernel image from the actual load address to the desired load address. Note that this isn't guaranteed since the kernel may wish to run at an arbitrary location. In that case, U-Boot will still relocate the image according to its wishes; this change is a performance optimization, not a hard-coding of the final image location. Signed-off-by: Stephen Warren swar...@nvidia.com --- include/configs/tegra210-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/tegra210-common.h b/include/configs/tegra210-common.h index d95056c00261..e6c815212d7b 100644 --- a/include/configs/tegra210-common.h +++ b/include/configs/tegra210-common.h @@ -55,7 +55,7 @@ * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 33M allows * for the FDT/DTB to be up to 1M, which is hopefully plenty. */ -#define CONFIG_LOADADDR 0x8100 +#define CONFIG_LOADADDR 0x8008 #define MEM_LAYOUT_ENV_SETTINGS \ scriptaddr=0x9000\0 \ pxefile_addr_r=0x9010\0 \ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] ARM: tegra: query_sdram_size() cleanup
From: Stephen Warren swar...@nvidia.com
The return value of query_sdram_size() is assigned directly to
gd-ram_size in dram_init(). Adjust the return type to match the field
it's assigned to. This has the beneficial effect that on 64-bit systems,
the return value can correctly represent large RAM sizes over 4GB.
For similar reasons, change the type of variable size_bytes in the same
way.
query_sdram_size() would previously clip the detected RAM size to at most
just under 4GB in all cases, since on 32-bit systems, larger values could
not be represented. Disable this feature on 64-bit systems since the
representation restriction does not exist.
On 64-bit systems, never call get_ram_size() to validate the detected/
calculated RAM size. On any system with a secure OS/... carve-out, RAM
may not have a single contiguous usable area, and this can confuse
get_ram_size(). Ideally, we'd make this call conditional upon some other
flag that indicates specifically that a carve-out is actually in use. At
present, building for a 64-bit system is the best indication we have of
this fact. In fact, the call to get_ram_size() is not useful by the time
U-Boot runs on any system, since U-Boot (and potentially much other early
boot software) always runs from RAM on Tegra, so any mistakes in memory
controller register programming will already have manifested themselves
and prevented U-Boot from running to this point. In the future, we may
simply delete the call to get_ram_size() in all cases.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
arch/arm/mach-tegra/board.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index 40de72dc575f..b00e4b5c1e25 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -66,10 +66,11 @@ bool tegra_cpu_is_non_secure(void)
#endif
/* Read the RAM size directly from the memory controller */
-unsigned int query_sdram_size(void)
+static phys_size_t query_sdram_size(void)
{
struct mc_ctlr *const mc = (struct mc_ctlr *)NV_PA_MC_BASE;
- u32 emem_cfg, size_bytes;
+ u32 emem_cfg;
+ phys_size_t size_bytes;
emem_cfg = readl(mc-mc_emem_cfg);
#if defined(CONFIG_TEGRA20)
@@ -77,6 +78,7 @@ unsigned int query_sdram_size(void)
size_bytes = get_ram_size((void *)PHYS_SDRAM_1, emem_cfg * 1024);
#else
debug(mc-mc_emem_cfg (MEM_SIZE_MB) = 0x%08x\n, emem_cfg);
+#ifndef CONFIG_PHYS_64BIT
/*
* If =4GB RAM is present, the byte RAM size won't fit into 32-bits
* and will wrap. Clip the reported size to the maximum that a 32-bit
@@ -84,9 +86,12 @@ unsigned int query_sdram_size(void)
*/
if (emem_cfg = 4096) {
size_bytes = U32_MAX ~(0x1000 - 1);
- } else {
+ } else
+#endif
+ {
/* RAM size EMC is programmed to. */
- size_bytes = emem_cfg * 1024 * 1024;
+ size_bytes = (phys_size_t)emem_cfg * 1024 * 1024;
+#ifndef CONFIG_ARM64
/*
* If all RAM fits within 32-bits, it can be accessed without
* LPAE, so go test the RAM size. Otherwise, we can't access
@@ -97,6 +102,7 @@ unsigned int query_sdram_size(void)
if (emem_cfg = (0 - PHYS_SDRAM_1) / (1024 * 1024))
size_bytes = get_ram_size((void *)PHYS_SDRAM_1,
size_bytes);
+#endif
}
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot FIT image support
Hi York, On 7 August 2015 at 14:48, York Sun york...@freescale.com wrote: Simon, I was doing an experiment to put the load address and entry address of Linux to higher than 32-bit address. I found it is broken to process more than 32-bit addresses. When I attempted to fix it, I was troubled by those code used for both host and target, like common/image-fit.c. For example, to process 64-bit address, the function int fit_image_get_load(const void *fit, int noffset, ulong *load) should be converted to int fit_image_get_load(const void *fit, int noffset, uint64_t *load) ulong is 64-bit for 64-bit target such as ARMv8, but it can be 32-bit on host. If I use uint64_t, all related code in bootm and others need to change. Before I go too far, I'd like to check if anyone has tried to enable this in FIT image. #address-cells = 2; I can try to use uint64_t in place of ulong for all related code if that's right. That will be a lot of change. Perhaps I misunderstand something, but I think ulong should be OK on the host. I just needs to hold a machine address. On a 32-bit host this cannot be 64-bit. Can you explain the problem a bit more? I have not need #address-cells in a FIT. It would be better to use ulong for addresses in U-Boot I think. It is safe and efficient on both 32- and 64-bit machines. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/9] update: tftp: dfu: Extend update_tftp() function to support DFU
Hi Lukasz, On Sat, Jul 25, 2015 at 3:11 AM, Lukasz Majewski l.majew...@majess.pl wrote: This code allows using DFU defined mediums for storing data received via TFTP protocol. It reuses and preserves functionality of legacy code at common/update.c. The update_tftp() function now accepts parameters - namely medium device name and its number (e.g. mmc 1). Without this information passed old behavior is preserved. Signed-off-by: Lukasz Majewski l.majew...@majess.pl --- Changes for v2: - Remove env variables from update_tftp() function - Add parameters to update_tftp() function - without them old behavior is preserved - Stop compilation when legacy flags (CONFIG_UPDATE_TFTP and CONFIG_SYS_NO_FLASH) are wrongly defined - In the u-boot code legacy calls to update_tftp(0UL) have been changed to update_tftp(0UL, NULL, NULL) --- common/Makefile | 1 + common/cmd_fitupd.c | 2 +- common/main.c | 2 +- common/update.c | 40 ++-- include/net.h | 2 +- 5 files changed, 34 insertions(+), 13 deletions(-) Address Simon's nits and then, Acked-by: Joe Hershberger joe.hershber...@ni.com diff --git a/common/Makefile b/common/Makefile index d6c1d48..76626f1 100644 --- a/common/Makefile +++ b/common/Makefile @@ -208,6 +208,7 @@ obj-$(CONFIG_LYNXKDI) += lynxkdi.o obj-$(CONFIG_MENU) += menu.o obj-$(CONFIG_MODEM_SUPPORT) += modem.o obj-$(CONFIG_UPDATE_TFTP) += update.o +obj-$(CONFIG_DFU_TFTP) += update.o Nice. That's much cleaner. obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o obj-$(CONFIG_CMD_DFU) += cmd_dfu.o obj-$(CONFIG_CMD_GPT) += cmd_gpt.o ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 9/9] dfu:tests: Modify dfu_gadget_test.sh to accept USB device major:minor number
Hi Lukasz, On Sat, Jul 25, 2015 at 3:11 AM, Lukasz Majewski l.majew...@majess.pl wrote: In the dfu-util it is possible to set major:minor number by unsing -d flag (-d 0451:d022). Such option is very handy when many DFU devices are connected to a single host PC. This commit allows testing when above situation emerges. Signed-off-by: Lukasz Majewski l.majew...@majess.pl --- Changes for v2: - New patch --- test/dfu/README | 9 - test/dfu/dfu_gadget_test.sh | 18 +++--- 2 files changed, 19 insertions(+), 8 deletions(-) This seems unrelated to the series (aside from generally also being DFU). Probably just send it separately. What about a test for TFTP? Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/9] dfu: tftp: update: Provide tftp support for the DFU subsystem
Hi Lukasz, On Sat, Jul 25, 2015 at 3:11 AM, Lukasz Majewski l.majew...@majess.pl wrote: This commit adds initial support for using tftp for downloading and upgrading firmware on the device. Signed-off-by: Lukasz Majewski l.majew...@majess.pl --- Changes for v2: - Return -ENOSYS instead of plain -1 - Remove interface and devstring env variables reading in the dfu_tftp_write() - Those parameters are now passed to dfu_tftp_write() function as its arguments --- Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/9] dfu: tftp: update: Add dfu_write_from_mem_addr() function
Hi Lukasz, On Sat, Jul 25, 2015 at 3:11 AM, Lukasz Majewski l.majew...@majess.pl wrote: This function allows writing via DFU data stored from fixed buffer address (like e.g. loadaddr env variable). Such predefined buffers are used in the update_tftp() code. In fact this function is a wrapper on the dfu_write() and dfu_flush(). Signed-off-by: Lukasz Majewski l.majew...@majess.pl --- Changes for v2: - Use min() macro instead of comparison - Change definition of left variable to be unsigned long - this allowed safe usage of min() macro --- Address Simon's nits and then, Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/9] config: bbb: Configs necessary for running update via TFTP on Beagle Bone Black
Hi Lukasz, On Sat, Jul 25, 2015 at 3:11 AM, Lukasz Majewski l.majew...@majess.pl wrote: Signed-off-by: Lukasz Majewski l.majew...@majess.pl --- Changes for v2: - Do not enable CONFIG_UPDATE_TFTP since CONFIG_DFU_TFTP enables the common code - Do not enable CONFIG_CMD_DFUTFTP since dfutftp commands has been removed --- I agree with Simon on his 2 points. Please address those. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/9] dfu: command: Extend dfu command to handle receiving data via TFTP
Hi Lukasz,
On Sat, Jul 25, 2015 at 3:11 AM, Lukasz Majewski l.majew...@majess.pl wrote:
The dfu command has been extended to support transfers via TFTP protocol.
Signed-off-by: Lukasz Majewski l.majew...@majess.pl
---
Changes for v2:
- Remove dfutftp command
- Modify dfu command to support optional [tftp] parameter
- Only one flag (CONFIG_DFU_TFTP) needs to be enabled
---
common/cmd_dfu.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c
index 857148f..aea466b 100644
--- a/common/cmd_dfu.c
+++ b/common/cmd_dfu.c
@@ -1,6 +1,9 @@
/*
* cmd_dfu.c -- dfu command
*
+ * Copyright (C) 2015
+ * Lukasz Majewski l.majew...@majess.pl
+ *
* Copyright (C) 2012 Samsung Electronics
* authors: Andrzej Pietrasiewicz andrze...@samsung.com
* Lukasz Majewski l.majew...@samsung.com
@@ -13,6 +16,9 @@
#include dfu.h
#include g_dnl.h
#include usb.h
+#ifdef CONFIG_DFU_TFTP
+#include net.h
+#endif
Generally you shouldn't need to guard an include. Just include net.h
all the time.
static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
@@ -26,7 +32,18 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
char *devstring = argv[3];
int ret, i = 0;
+#ifdef CONFIG_DFU_TFTP
+ unsigned long addr = 0;
Maybe you should reinitialize devstring to NULL here?
+ if (!strcmp(usb_controller, tftp)) {
This would look a lot clearer if you used argv[1] instead of
usb_controller. You are not using it as the usb_controller parameter,
it just happens to be the second word.
+ usb_controller = argv[2];
You shouldn't be keeping the usb_controller parameter around. It makes
no sense for the tftp case. Why not just drop it?
+ interface = argv[3];
+ devstring = argv[4];
Is it safe to read argv[4] on your optional parameter without checking
for argc = 5?
+ if (argc == 6)
+ addr = simple_strtoul(argv[5], NULL, 0);
+ return update_tftp(addr, interface, devstring);
+ }
+#endif
ret = dfu_init_env_entities(interface, devstring);
if (ret)
goto done;
@@ -84,9 +101,17 @@ done:
U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu,
Device Firmware Upgrade,
+#ifdef CONFIG_DFU_TFTP
+ [tftp] USB_controller interface dev [list] [addr]\n
Also drop USB_controller from the help here.
+#else
USB_controller interface dev [list]\n
+#endif
- device firmware upgrade via USB_controller\n
on device dev, attached to interface\n
interface\n
[list] - list available alt settings\n
+#ifdef CONFIG_DFU_TFTP
+ [tftp] - use TFTP protocol to download data\n
+ [addr] - address where FIT image has been stored\n
Probably not helpful to include the '[' and ']' here. They are
supposed to indicate optional parameters. We already know they are
optional from above. Good to fix up the '[list]' as well.
+#endif
);
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/3] mmc: dw_mmc: Support bypass mode with the get_mmc_clk() method
Hi, On 08/07/2015 12:07 PM, Marek Vasut wrote: On Friday, August 07, 2015 at 05:00:24 AM, Simon Glass wrote: Hi Marek, Hi Simon, On 6 August 2015 at 20:58, Marek Vasut ma...@denx.de wrote: On Friday, August 07, 2015 at 04:54:42 AM, Simon Glass wrote: Hi Marek, Hi Simon, On 6 August 2015 at 20:51, Marek Vasut ma...@denx.de wrote: On Friday, August 07, 2015 at 04:16:28 AM, Simon Glass wrote: Some SoCs want to adjust the input clock to the DWMMC block as a way of controlling the MMC bus clock. Update the get_mmc_clk() method to support this. Signed-off-by: Simon Glass s...@chromium.org Hi Simon, --- Changes in v4: - Update commit message to indicate this patch is for the dw_mmc driver drivers/mmc/dw_mmc.c| 2 +- drivers/mmc/exynos_dw_mmc.c | 2 +- include/dwmmc.h | 16 +++- 3 files changed, 17 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c index 8f28d7e..a034c3f 100644 --- a/drivers/mmc/dw_mmc.c +++ b/drivers/mmc/dw_mmc.c @@ -248,7 +248,7 @@ static int dwmci_setup_bus(struct dwmci_host *host, u32 freq) * host-bus_hz should be set by user. */ if (host-get_mmc_clk) - sclk = host-get_mmc_clk(host); + sclk = host-get_mmc_clk(host, freq); Why are you passing the @freq into get_mmc_clk() ? Shouldn't you call some clock framework function to determine the input frequency of the DWMMC block from within the get_mmc_clk() implementation instead ? What do you think please ? Well, yes. If such a clock frame work existed I would call it :-) We do have a uclass now so we are getting there. Excellent, so do you really need this kind of patch ? :) Why don't you make just some kind of function -- get_dwmmc_clock() -- and call it instead ? This is sort-of what is happening. It is calling a function in the host controller - i.e. the SoC's MMC controller. It is one step closer to knowing the input clock to the dwmmc input clock. Note that it is not the clock of the MMC bus itself, but the input clock to the dwmmc logic block. I don't think I quite understand wha,t you mean here. We're talking about obtaining the frequency of the clock which go into the DWMMC IP block, right ? So, if you implement a function, say -- dwmmc_get_upstream_clock() -- and call it from within the implementation of the .get_mmc_clk(), which is specific for that particular chip of yours*, you don't need this patch. Or am I really missing something fundamental ? Hmm. I don't know what purpose @freq is...just bypass? @freq doesn't use wherever..I'm checking with u-boot-dm repository(mmc-working branch) I wonder i'm also missing something like Marek. Best Regards, Jaehoon Chung *the .get_mmc_clk() is specific to a chip, see for example exynos_dw_mmc.c Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_DM_ETH USB_ETHER_ASIX Reception Issue on Tegra
On Thu, 2015-08-06 at 23:29 -0600, Simon Glass wrote: The memalign() function arguments are around the wrong way! I assume you meant that one: diff --git a/drivers/usb/eth/usb_ether.c b/drivers/usb/eth/usb_ether.c index 3c3e082..11d26be 100644 --- a/drivers/usb/eth/usb_ether.c +++ b/drivers/usb/eth/usb_ether.c @@ -73,7 +73,7 @@ int usb_ether_register(struct udevice *dev, struct ueth_data *ueth, int rxsize) } ueth-rxsize = rxsize; - ueth-rxbuf = memalign(rxsize, ARCH_DMA_MINALIGN); + ueth-rxbuf = memalign(ARCH_DMA_MINALIGN, rxsize); if (!ueth-rxbuf) return -ENOMEM; Definitely worth seeing if that fixes it. For some reason rpi and minnowboard seem to work even with this error. Unfortunately still the same: U-Boot SPL 2015.10-rc1-00188-gfac971b-dirty (Aug 07 2015 - 06:34:28) U-Boot 2015.10-rc1-00188-gfac971b-dirty (Aug 07 2015 - 06:34:28 +) TEGRA20 Model: Toradex Colibri T20 Board: Toradex Colibri T20 DRAM: 512 MiB NAND: 1024 MiB MMC: Tegra SD/MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 Colibri T20 # usb start starting USB... USB0: USB EHCI 1.00 USB1: USB EHCI 1.00 USB2: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning bus 2 for devices... Warning: asix_eth using MAC address from ROM 2 USB Device(s) found scanning bus 0 for devices... 1 USB Device(s) found Colibri T20 # dhcp BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 EHCI timed out on TD - token=0x8008d80 Rx: failed to receive: -5 BOOTP broadcast 4 BOOTP broadcast 5 EHCI timed out on TD - token=0x88008d80 Rx: failed to receive: -5 BOOTP broadcast 6 BOOTP broadcast 7 EHCI timed out on TD - token=0x8008d80 Rx: failed to receive: -5 BOOTP broadcast 8 BOOTP broadcast 9 EHCI timed out on TD - token=0x88008d80 Rx: failed to receive: -5 Retry time exceeded; starting again Colibri T20 # ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx6 move TARGET_xx Kconfig option to mx6 specific Kconfig file
Hi Peng, Soeren, On 07/08/2015 09:19, Soeren Moch wrote: Peng, Sorry for being unclear here. In your patch you add several options in arch/arm/cpu/armv7/mx6/Kconfig under MX6 board select. Some of these options are named Support boardname (e.g. Support udoo), while others are simply called boardname (e.g. Bachmann OT1200). I would prefer the simple boardname naming style for all options and remove the word Support from all description strings. But this is only my personal opinion and a minor cosmetic change. Checking in other architecture, I see there is no rule about this. Even in the same Kconfig (AT91), there is a mix with and without Support. Both are ok - decide yourself. 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] [ANN] U-Boot v2015.07 released
On 7 August 2015 at 12:33, Wolfgang Denk w...@denx.de wrote: Dear Tom, In message 20150714175627.GJ23886@bill-the-cat you wrote: I've pushed v2015.07 out to the repository and tarballs should exist soon. Here finally the release statistics - sorry this took so long. For the full list please see [1]. [1] http://www.denx.de/wiki/U-Boot/UbootStat_2015_07 Processed 1563 csets from 156 developers 24 employers found A total of 176355 lines added, 44130 removed (delta 132225) Developers with the most changesets Simon Glass311 (19.9%) Joe Hershberger111 (7.1%) Hans de Goede 106 (6.8%) Tim Harvey 77 (4.9%) Masahiro Yamada 68 (4.4%) Bin Meng56 (3.6%) Jagannadh Teki 44 (2.8%) Przemyslaw Marczak 43 (2.8%) Paul Kocialkowski 42 (2.7%) Kishon Vijay Abraham I 41 (2.6%) ... Developers with the most changed lines Masahiro Yamada 56181 (28.7%) Simon Glass 22872 (11.7%) Hans de Goede 19807 (10.1%) Kishon Vijay Abraham I15720 (8.0%) Joe Hershberger 13351 (6.8%) Prabhakar Kushwaha6857 (3.5%) Przemyslaw Marczak6471 (3.3%) Stefan Roese 3275 (1.7%) Bin Meng 3114 (1.6%) Haikun Wang 3058 (1.6%) ... Developers with the most lines removed Andreas Bießmann 2018 (4.6%) Angelo Dureghello 1628 (3.7%) Stefan Roese 1117 (2.5%) Peter Robinson1105 (2.5%) Jagannadh Teki1001 (2.3%) Ian Campbell 354 (0.8%) Valentin Longchamp 116 (0.3%) Lars Poeschel 52 (0.1%) Jagannadha Sutradharudu Teki 41 (0.1%) Stephen Warren 15 (0.0%) ... Developers with the most signoffs (total 302) Tom Warren 60 (19.9%) Hans de Goede 55 (18.2%) Michal Simek19 (6.3%) York Sun19 (6.3%) Tom Rini10 (3.3%) Nishanth Menon 9 (3.0%) Rabeeh Khoury8 (2.6%) Andre Przywara 6 (2.0%) Rob Herring 5 (1.7%) Radha Mohan Chintakuntla 5 (1.7%) ... Developers with the most reviews (total 486) Simon Glass101 (20.8%) Marek Vasut 88 (18.1%) Tom Rini80 (16.5%) York Sun50 (10.3%) Łukasz Majewski41 (8.4%) Bin Meng38 (7.8%) Hans de Goede 15 (3.1%) Joe Hershberger 14 (2.9%) Jagannadha Sutradharudu Teki 13 (2.7%) Jagannadh Teki 12 (2.5%) ... Developers with the most test credits (total 127) Simon Glass 17 (13.4%) Kevin Smith 14 (11.0%) Dirk Eibach 13 (10.2%) Thierry Reding 11 (8.7%) Ian Campbell11 (8.7%) Vagrant Cascadian9 (7.1%) Jagannadh Teki 8 (6.3%) Haikun Wang 6 (4.7%) Bin Meng 4 (3.1%) Joe Hershberger 3 (2.4%) ... Developers who gave the most tested-by credits (total 127) Stefan Roese27 (21.3%) Jan Kiszka 18 (14.2%) Fabio Estevam 11 (8.7%) Przemyslaw Marczak 11 (8.7%) Simon Glass 8 (6.3%) Haikun Wang 8 (6.3%) Ian Campbell 6 (4.7%) Jagannadh Teki 5 (3.9%) Heiko Schocher 4 (3.1%) Bin Meng 3 (2.4%) ... Developers with the most report credits (total 21) Simon Glass 5 (23.8%) Joe Hershberger 2 (9.5%) Ingrid Viitanen 2 (9.5%) Haikun Wang 1 (4.8%) Bin Meng 1 (4.8%) Tim Harvey 1 (4.8%) Michal Simek 1 (4.8%) Pavel Machek 1 (4.8%) Vagrant Cascadian1 (4.8%) Maxin B. John1 (4.8%) ... Developers who gave the most report credits (total 21) Simon Glass 7 (33.3%) Joe Hershberger 5 (23.8%) Lokesh Vutla 3 (14.3%) Fabio Estevam2 (9.5%) Tom Rini 1 (4.8%) Jagannadha Sutradharudu Teki1 (4.8%) Daniel Schwierzeck 1 (4.8%) Hans de Goede1 (4.8%) Top changeset contributors by employer (Unknown) 571 (36.5%) Google, Inc. 312 (20.0%) Freescale 151 (9.7%) National Instruments 111 (7.1%) Red Hat106 (6.8%) Texas Instruments 81 (5.2%) DENX Software Engineering 73 (4.7%) Samsung 65 (4.2%) Xilinx 25 (1.6%) Siemens 14 (0.9%) ... Top lines changed by employer (Unknown) 86637 (44.3%) Google, Inc. 22901 (11.7%) Red Hat
Re: [U-Boot] [PATCH v1 1/2] cmd_sf: Add command sf info to show current device info
On 20 July 2015 at 11:25, Wang Haikun haikun.w...@freescale.com wrote: On 5/11/2015 10:59 AM, Simon Glass wrote: Hi, On 10 May 2015 at 07:04, Jagan Teki jt...@openedev.com wrote: On 8 May 2015 at 13:51, haikun.w...@freescale.com haikun.w...@freescale.com wrote: On 5/8/2015 1:53 PM, Jagan Teki wrote: On 8 May 2015 at 08:14, haikun.w...@freescale.com haikun.w...@freescale.com wrote: On 5/7/2015 7:44 PM, Jagan Teki wrote: On 6 May 2015 at 02:30, Simon Glass s...@chromium.org wrote: On 5 May 2015 at 05:37, haikun.w...@freescale.com haikun.w...@freescale.com wrote: On 5/1/2015 9:54 AM, Simon Glass wrote: Hi, On 29 April 2015 at 04:40, Haikun Wang haikun.w...@freescale.com wrote: Add command sf info to show the information of the current SPI flash device. Signed-off-by: Haikun Wang haikun.w...@freescale.com --- In current sf driver, we show the debug information during the flash probe period. In case of without DM SPI, we need to run command sf probe to get the debug information of the current SPI flash device. sf probe will re-identify the device every time and it reduce the efficiency. We can get the debug information without any re-identify process using sf info. So for non-dm case, sf probe and sf info does same? For non-dm case, sf info only show the information store in the current struct spi_flash, sf_probe will re-probe the SPI flash and create a new struct spi-flash. How could it be, in non-dm case sf probe will detect the flash and print the info from drivers/mtd/spi/sf_probe.c So sf probe every-time will re-identify the device and print the info. I approve of what you said. We don't have divergence about the difference between sf probe and sf info. I just want to emphasize that sf probe re-identify the device, create a new spi_flash and print the info, sf info only print the current info. BTW: regarding this patch, unlike any command in u-boot (for my understanding) sf probe has a run-time capable detection option based on bus:cs hz mode from user. So it better to skip the re-identify the same fitlash if the flash is identified before in sf probe logic and try to print the info in it instead of going another stale command just by doing print using earlier commands settings (sf probe). I think we get to a common view that it is unnecessary to re-identify the device if it has been identified. Divergence is that you think this should be completed through updating the sf probe logic and I think we should add the new command sf info. sf info resolves the problem in a more simpler way. User will be more clearly about the functions of the sf commands if we add a new command sf info. From the literal meaning of the command sf probe should identify the device and the command sf info show the information of current device. Yes, I agree that 'sf info' simply show the current device info in a simpler way. But, being with my previous statement it simply print the info which is derived from 'sf probe' So why should we go and do the same thing in 'sf probe' with increasing one more command which does part of same as before. Yes, 'sf probe' is doing unnecessary re-identify the device so may be we can fix that, ie going to be a real fix other than adding new command. Please think in that direction, adding new command in u-boot is really a big step to think in whole u-boot development point of view. We have an 'info' command for usb, mmc, scsi, etc. and they don't have side-effects like re-probing the device. I think it makes sense to support something like this for sf, at least for driver model. Also, with driver model it would be good if the sf could automatically probe when used, rather than needing to probe it explicitly. We could also support more than one active flash, and a command to switch between them (like mmc dev and the like). Even better if we could specific the device in the 'sf read/write/erase' commands. [snip] Regards, Simon Update my email address. Pls- send the next version by add some text on commit message. thanks! -- Jagan | openedev. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [V4 1/2] sf: Add clear flag status register operation on Micron chips
On 23 July 2015 at 15:24, Zhiqiang Hou b48...@freescale.com wrote:
From: Hou Zhiqiang b48...@freescale.com
Add clear flag status register operation that was required by Micron SPI
flash chips after reading the flag status register to check if the erase
and program operations complete or an error occur.
Flag status requires N25Q512 + parts, so clear flag status we need add only
in this scenario is that true?
Signed-off-by: Hou Zhiqiang b48...@freescale.com
Signed-off-by: Mingkai.Hu mingkai...@freescale.com
---
drivers/mtd/spi/sf_internal.h | 9 +
drivers/mtd/spi/sf_ops.c | 40
2 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 9fb5557..703d4a7 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -73,6 +73,7 @@ enum {
#define CMD_WRITE_ENABLE 0x06
#define CMD_READ_CONFIG0x35
#define CMD_FLAG_STATUS0x70
+#define CMD_CLEAR_FLAG_STATUS 0x50
/* Read commands */
#define CMD_READ_ARRAY_SLOW0x03
@@ -96,6 +97,8 @@ enum {
#define STATUS_QEB_WINSPAN (1 1)
#define STATUS_QEB_MXIC(1 6)
#define STATUS_PEC (1 7)
+#define STATUS_PROT(1 1)
+#define STATUS_ERASE (1 5)
/* Flash timeout values */
#define SPI_FLASH_PROG_TIMEOUT (2 * CONFIG_SYS_HZ)
@@ -182,6 +185,12 @@ static inline int spi_flash_cmd_write_disable(struct
spi_flash *flash)
return spi_flash_cmd(flash-spi, CMD_WRITE_DISABLE, NULL, 0);
}
+/* Clear flag status register */
+static inline int spi_flash_cmd_clear_flag_status(struct spi_slave *spi)
+{
+ return spi_flash_cmd(spi, CMD_CLEAR_FLAG_STATUS, NULL, 0);
+}
+
/*
* Send the read status command to the device and wait for the wip
* (write-in-progress) bit to clear itself.
diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
index 38592f5..cbb9f00 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -160,6 +160,7 @@ static int spi_flash_poll_status(struct spi_slave *spi,
unsigned long timeout,
unsigned long timebase;
unsigned long flags = SPI_XFER_BEGIN;
int ret;
+ int out_of_time = 1;
u8 status;
u8 check_status = 0x0;
@@ -182,22 +183,45 @@ static int spi_flash_poll_status(struct spi_slave *spi,
unsigned long timeout,
WATCHDOG_RESET();
ret = spi_xfer(spi, 8, NULL, status, 0);
- if (ret)
+ if (ret) {
+ spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
return -1;
+ }
- if ((status poll_bit) == check_status)
+ if ((status poll_bit) == check_status) {
+ out_of_time = 0;
break;
+ }
} while (get_timer(timebase) timeout);
spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
- if ((status poll_bit) == check_status)
- return 0;
+ if (out_of_time) {
+ /* Timed out */
+ debug(SF: time out!\n);
+ if (cmd == CMD_FLAG_STATUS) {
+ if (spi_flash_cmd_clear_flag_status(spi) 0)
+ debug(SF: clear flag status failed\n);
+ }
+ ret = -1;
+ }
+#ifdef CONFIG_SPI_FLASH_STMICRO
+ else if (cmd == CMD_FLAG_STATUS) {
+ if (!(status (STATUS_PROT | STATUS_ERASE))) {
+ ret = 0;
+ } else {
+ debug(SF: flag status error);
+ ret = -1;
+ }
- /* Timed out */
- debug(SF: time out!\n);
- return -1;
+ if (spi_flash_cmd_clear_flag_status(spi) 0) {
+ debug(SF: clear flag status failed\n);
+ ret = -1;
+ }
+ }
+#endif
+ return ret;
}
int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long timeout)
@@ -252,7 +276,7 @@ int spi_flash_write_common(struct spi_flash *flash, const
u8 *cmd,
ret = spi_flash_cmd_wait_ready(flash, timeout);
if (ret 0) {
- debug(SF: write %s timed out\n,
+ debug(SF: write %s failed\n,
timeout == SPI_FLASH_PROG_TIMEOUT ?
program : page erase);
return ret;
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2015.07 released
Dear Tom, In message 20150714175627.GJ23886@bill-the-cat you wrote: I've pushed v2015.07 out to the repository and tarballs should exist soon. Here finally the release statistics - sorry this took so long. For the full list please see [1]. [1] http://www.denx.de/wiki/U-Boot/UbootStat_2015_07 Processed 1563 csets from 156 developers 24 employers found A total of 176355 lines added, 44130 removed (delta 132225) Developers with the most changesets Simon Glass311 (19.9%) Joe Hershberger111 (7.1%) Hans de Goede 106 (6.8%) Tim Harvey 77 (4.9%) Masahiro Yamada 68 (4.4%) Bin Meng56 (3.6%) Jagannadh Teki 44 (2.8%) Przemyslaw Marczak 43 (2.8%) Paul Kocialkowski 42 (2.7%) Kishon Vijay Abraham I 41 (2.6%) ... Developers with the most changed lines Masahiro Yamada 56181 (28.7%) Simon Glass 22872 (11.7%) Hans de Goede 19807 (10.1%) Kishon Vijay Abraham I15720 (8.0%) Joe Hershberger 13351 (6.8%) Prabhakar Kushwaha6857 (3.5%) Przemyslaw Marczak6471 (3.3%) Stefan Roese 3275 (1.7%) Bin Meng 3114 (1.6%) Haikun Wang 3058 (1.6%) ... Developers with the most lines removed Andreas Bießmann 2018 (4.6%) Angelo Dureghello 1628 (3.7%) Stefan Roese 1117 (2.5%) Peter Robinson1105 (2.5%) Jagannadh Teki1001 (2.3%) Ian Campbell 354 (0.8%) Valentin Longchamp 116 (0.3%) Lars Poeschel 52 (0.1%) Jagannadha Sutradharudu Teki 41 (0.1%) Stephen Warren 15 (0.0%) ... Developers with the most signoffs (total 302) Tom Warren 60 (19.9%) Hans de Goede 55 (18.2%) Michal Simek19 (6.3%) York Sun19 (6.3%) Tom Rini10 (3.3%) Nishanth Menon 9 (3.0%) Rabeeh Khoury8 (2.6%) Andre Przywara 6 (2.0%) Rob Herring 5 (1.7%) Radha Mohan Chintakuntla 5 (1.7%) ... Developers with the most reviews (total 486) Simon Glass101 (20.8%) Marek Vasut 88 (18.1%) Tom Rini80 (16.5%) York Sun50 (10.3%) Łukasz Majewski41 (8.4%) Bin Meng38 (7.8%) Hans de Goede 15 (3.1%) Joe Hershberger 14 (2.9%) Jagannadha Sutradharudu Teki 13 (2.7%) Jagannadh Teki 12 (2.5%) ... Developers with the most test credits (total 127) Simon Glass 17 (13.4%) Kevin Smith 14 (11.0%) Dirk Eibach 13 (10.2%) Thierry Reding 11 (8.7%) Ian Campbell11 (8.7%) Vagrant Cascadian9 (7.1%) Jagannadh Teki 8 (6.3%) Haikun Wang 6 (4.7%) Bin Meng 4 (3.1%) Joe Hershberger 3 (2.4%) ... Developers who gave the most tested-by credits (total 127) Stefan Roese27 (21.3%) Jan Kiszka 18 (14.2%) Fabio Estevam 11 (8.7%) Przemyslaw Marczak 11 (8.7%) Simon Glass 8 (6.3%) Haikun Wang 8 (6.3%) Ian Campbell 6 (4.7%) Jagannadh Teki 5 (3.9%) Heiko Schocher 4 (3.1%) Bin Meng 3 (2.4%) ... Developers with the most report credits (total 21) Simon Glass 5 (23.8%) Joe Hershberger 2 (9.5%) Ingrid Viitanen 2 (9.5%) Haikun Wang 1 (4.8%) Bin Meng 1 (4.8%) Tim Harvey 1 (4.8%) Michal Simek 1 (4.8%) Pavel Machek 1 (4.8%) Vagrant Cascadian1 (4.8%) Maxin B. John1 (4.8%) ... Developers who gave the most report credits (total 21) Simon Glass 7 (33.3%) Joe Hershberger 5 (23.8%) Lokesh Vutla 3 (14.3%) Fabio Estevam2 (9.5%) Tom Rini 1 (4.8%) Jagannadha Sutradharudu Teki1 (4.8%) Daniel Schwierzeck 1 (4.8%) Hans de Goede1 (4.8%) Top changeset contributors by employer (Unknown) 571 (36.5%) Google, Inc. 312 (20.0%) Freescale 151 (9.7%) National Instruments 111 (7.1%) Red Hat106 (6.8%) Texas Instruments 81 (5.2%) DENX Software Engineering 73 (4.7%) Samsung 65 (4.2%) Xilinx 25 (1.6%) Siemens 14 (0.9%) ... Top lines changed by employer (Unknown) 86637 (44.3%) Google, Inc. 22901 (11.7%) Red Hat 19807 (10.1%) Freescale 19443 (9.9%) Texas Instruments 17540 (9.0%) National Instruments 13351 (6.8%) Samsung 6796 (3.5%) DENX
Re: [U-Boot] [PATCH 2/4] net: fec: do not access reserved register for i.MX6UL
Hi Peng, On 07/08/2015 03:08, Peng Fan wrote: I considered using if (!is_cpu_type(MXC_CPU_MX6UL)), but this will cause i.MX7 fail to complile successfully, because i.MX7 does not support the macro MXC_CPU_MX6UL. It looks like we have a problem in design - we have to move this macros to make available to all i.MXes. In fact, it is even plausible that MX35 code runs is_cpu_type(MXC_CPU_MX6UL), and the macros must return false. Having these checks working for some SOCs vanifies the goal: check at runtime if a SOC is of a certain type. I checked related code for i.MX25/28/31/35/5x/6x. We can add following define in imx-common/xxx.h #define MXC_CPU_MX35 0x35 #define MXC_CPU_MX31 0x31 #define MXC_CPU_MX25 0x25 #define MXC_CPU_MX23 #define MXC_CPU_MX28 About i.mx23/28, I am not sure, since they have different get_cpu_rev implementation. As far as I understand, the chip id is retrieved and then converted as 23 or 28 (see get_cpu_type). I think it is plausible to define them in this way as well as using the waqy in get_cpu_type() to identify the SOC. get_cpu_rev() in MX23/MX28 is also not compliant with the rest of SOCs. It returns a string intead of a u32. Also they have different chipid layout. To i.MX31, we can do following change: return mx31_cpu_type[i].v | 0x31000; to replace return mx31_cpu_type[i].v; Then we can use: #define is_cpu_type(xxx) (((get_cpu_rev() 0xFF000) 12) == xxx) To i.MX23/28, they have different get_cpu_rev() prototype, maybe need to rewrite the function? Agree - it is an exception in U-Boot for i.MXEs, and it defines a different prototype for the function. I am not familar with SoCs prior to i.MX6, not sure whether this ok. IMHO it looks ok ;-) The way I can think out is to refactor the code to support DM or FDT, using compatible string to figure out which SoC. But now I do not have much time to refactor the driver. So I just use the #if !defined way which is not good solution. It is not - anyway, making macros commonly available to all i.MXes could be done with a smaller effort. Currently, macros are available only to mx6 (define in sys_proto.h). We have to move them in a header in arch/arm/include/asm/imx-common/, that is accessible by all SOCs. Maybe need to add sys_proto.h in arch/arm/include/asm/imx-common. +1 Right - we have several sys_proto.h, iun most cases they have prototypes for the same functions. 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
[U-Boot] [PATCH V3 2/6] power: regulator use node name when no regulator-name
If there is no property named 'regulator-name' for regulators,
choose node name instead, but not directly return failure value.
Signed-off-by: Peng Fan peng@freescale.com
Cc: Przemyslaw Marczak p.marc...@samsung.com
Cc: Simon Glass s...@chromium.org
---
Changes v3:
None.
Changes v2:
None. The comments update patch, see 3/6.
drivers/power/regulator/regulator-uclass.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/power/regulator/regulator-uclass.c
b/drivers/power/regulator/regulator-uclass.c
index 12e141b..d4f06d5 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -256,7 +256,9 @@ static int regulator_post_bind(struct udevice *dev)
if (!uc_pdata-name) {
debug(%s: dev: %s has no property 'regulator-name'\n,
__func__, dev-name);
- return -EINVAL;
+ uc_pdata-name = fdt_get_name(blob, offset, NULL);
+ if (!uc_pdata-name)
+ return -EINVAL;
}
if (regulator_name_is_unique(dev, uc_pdata-name))
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 1/6] power: pfuze100 correct SWBST macro definition
According to datasheet, SWBST_MODE starts from bit 2 and it occupies 2 bits.
So SWBST_MODE_MASK should be 0xC, and SWBST_MODE_xx should be ([mode] 2).
Signed-off-by: Peng Fan peng@freescale.com
Cc: Przemyslaw Marczak p.marc...@samsung.com
Cc: Stefano Babic sba...@denx.de
Reviewed-by: Simon Glass s...@chromium.org
---
Changes v3:
None
Changes v2:
None
include/power/pfuze100_pmic.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/power/pfuze100_pmic.h b/include/power/pfuze100_pmic.h
index 57b9ca9..cb10605 100644
--- a/include/power/pfuze100_pmic.h
+++ b/include/power/pfuze100_pmic.h
@@ -193,11 +193,11 @@ enum {
#define SWBST_5_15V3
#define SWBST_VOL_MASK 0x3
-#define SWBST_MODE_MASK0x6
-#define SWBST_MODE_OFF (2 0)
-#define SWBST_MODE_PFM (2 1)
+#define SWBST_MODE_MASK0xC
+#define SWBST_MODE_OFF (0 2)
+#define SWBST_MODE_PFM (1 2)
#define SWBST_MODE_AUTO(2 2)
-#define SWBST_MODE_APS (2 3)
+#define SWBST_MODE_APS (3 2)
/*
* Regulator Mode Control
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 0/5] power: pfuze100: support driver model and regulator
This patch set is to support driver model for pfuze100 and implement regulator driver for pfuze100. Patches has been tested on i.MX7D validation board. Here registeres for standby mode are not touched, all operation read/write register are for NORMAL state. For example, to pfuze100, sw1volt is for controlling voltage for normal state, sw1stdby is for controlling voltage for standby state. The driver only read/write sw1volt, but not touch sw1stdby. This will be done later, since I do not come up with a good idea to operate sw1stdby. This pfuze driver model part and regulator driver use max77686 driver as a reference. Changes V3: Mainly discard the double pointer. See changelog in each patch. Changes v2: Addressed comments from Simon and Przemyslaw. Detailed changelog see each patch. Peng Fan (5): power: pfuze100 correct SWBST macro definition power: regulator use node name when no regulator-name power: pmic: pfuze100 support driver model power: regulator: add pfuze100 support fsl: common: pfuze: no use original pfuze code if DM_PMIC board/freescale/common/pfuze.c | 2 + drivers/power/pmic/Kconfig | 7 + drivers/power/pmic/Makefile| 1 + drivers/power/pmic/pfuze100.c | 99 + drivers/power/regulator/Kconfig| 8 + drivers/power/regulator/Makefile | 1 + drivers/power/regulator/pfuze100.c | 568 + drivers/power/regulator/regulator-uclass.c | 4 +- include/power/pfuze100_pmic.h | 33 +- 9 files changed, 716 insertions(+), 7 deletions(-) create mode 100644 drivers/power/pmic/pfuze100.c create mode 100644 drivers/power/regulator/pfuze100.c -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] x86: microcode-tool: Write pure data to the dtsi file
Currently the microcode-tool writes microcode into a data block as well as the device tree properties which represents the first 48 bytes in the microcode data. Now we change the tool to only write the microcode without device tree stuff so that multiple microcode data blocks can be included in a single property. Signed-off-by: Bin Meng bmeng...@gmail.com --- tools/microcode-tool.py | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/tools/microcode-tool.py b/tools/microcode-tool.py index 71c2e91..5522ffc 100755 --- a/tools/microcode-tool.py +++ b/tools/microcode-tool.py @@ -173,20 +173,21 @@ def CreateFile(date, license_text, mcodes, outfile): * node. * * Date: %s + * + * Device tree properties for this microcode: + * + * compatible = intel,microcode; + * intel,header-version = %d; + * intel,update-revision = %#x; + * intel,date-code = %#x; + * intel,processor-signature = %#x; + * intel,checksum = %#x; + * intel,loader-revision = %d; + * intel,processor-flags = %#x; */ -compatible = intel,microcode; -intel,header-version = %d; -intel,update-revision = %#x; -intel,date-code = %#x; -intel,processor-signature = %#x; -intel,checksum = %#x; -intel,loader-revision = %d; -intel,processor-flags = %#x; - /* The first 48-bytes are the public header which repeats the above data */ -data = %s -\t;''' +%s''' words = '' add_comments = len(mcodes) 1 for mcode in mcodes: -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] x86: Update microcode dtsi and board dts files per microcode-tool
As the updated microcode-tool doesn't write dts properties into the
microcode dtsi files, update the existing dtsi and board dts files
to keep sync with the tool. Note for FSP based boards, add a new
property intel,fsp-parser which indicates it will be consumed by
Intel FSP and the properties for a single microcode are removed.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
arch/x86/dts/bayleybay.dts| 5 +
arch/x86/dts/chromebook_link.dts | 11 +++
arch/x86/dts/crownbay.dts | 5 +
arch/x86/dts/microcode/m0130673322.dtsi | 23 ---
arch/x86/dts/microcode/m0220661105_cv.dtsi| 23 ---
arch/x86/dts/microcode/m0230671117.dtsi | 23 ---
arch/x86/dts/microcode/m12206a7_0029.dtsi | 25 ++---
arch/x86/dts/microcode/m12306a9_001b.dtsi | 25 ++---
arch/x86/dts/minnowmax.dts| 5 +
9 files changed, 90 insertions(+), 55 deletions(-)
diff --git a/arch/x86/dts/bayleybay.dts b/arch/x86/dts/bayleybay.dts
index 0ca7c3e..ea27537 100644
--- a/arch/x86/dts/bayleybay.dts
+++ b/arch/x86/dts/bayleybay.dts
@@ -230,7 +230,12 @@
microcode {
update@0 {
+ compatible = intel,microcode;
+ intel,fsp-parser;
+
+ data =
#include microcode/m0230671117.dtsi
+ ;
};
};
diff --git a/arch/x86/dts/chromebook_link.dts b/arch/x86/dts/chromebook_link.dts
index ad390bf..b5cea9d 100644
--- a/arch/x86/dts/chromebook_link.dts
+++ b/arch/x86/dts/chromebook_link.dts
@@ -239,7 +239,18 @@
microcode {
update@0 {
+ compatible = intel,microcode;
+ intel,header-version = 1;
+ intel,update-revision = 0x1b;
+ intel,date-code = 0x5292014;
+ intel,processor-signature = 0x306a9;
+ intel,checksum = 0x579ae07a;
+ intel,loader-revision = 1;
+ intel,processor-flags = 0x12;
+
+ data =
#include microcode/m12306a9_001b.dtsi
+ ;
};
};
diff --git a/arch/x86/dts/crownbay.dts b/arch/x86/dts/crownbay.dts
index 3af9cc3..6b36c87 100644
--- a/arch/x86/dts/crownbay.dts
+++ b/arch/x86/dts/crownbay.dts
@@ -83,7 +83,12 @@
microcode {
update@0 {
+ compatible = intel,microcode;
+ intel,fsp-parser;
+
+ data =
#include microcode/m0220661105_cv.dtsi
+ ;
};
};
diff --git a/arch/x86/dts/microcode/m0130673322.dtsi
b/arch/x86/dts/microcode/m0130673322.dtsi
index 90bf2fb..0482397 100644
--- a/arch/x86/dts/microcode/m0130673322.dtsi
+++ b/arch/x86/dts/microcode/m0130673322.dtsi
@@ -4,19 +4,21 @@
* node.
*
* Date:
+ *
+ * Device tree properties for this microcode:
+ *
+ * compatible = intel,microcode;
+ * intel,header-version = 1;
+ * intel,update-revision = 0x322;
+ * intel,date-code = 0x4012014;
+ * intel,processor-signature = 0x30673;
+ * intel,checksum = 0x17b0d914;
+ * intel,loader-revision = 1;
+ * intel,processor-flags = 0x1;
*/
-compatible = intel,microcode;
-intel,header-version = 1;
-intel,update-revision = 0x322;
-intel,date-code = 0x4012014;
-intel,processor-signature = 0x30673;
-intel,checksum = 0x17b0d914;
-intel,loader-revision = 1;
-intel,processor-flags = 0x1;
-
/* The first 48-bytes are the public header which repeats the above data */
-data =
+
0x0100 0x2203 0x14200104 0x73060300
0x14d9b017 0x0100 0x0100 0xd0cb
0x00cc 0x 0x 0x
@@ -3281,4 +3283,3 @@ data =
0x1e176b9c 0xe3fcb69f 0x17a2eee9 0xa9e6467f
0xbf6b0246 0x6a08c0fb 0x7fb943b6 0xb8f67c0e
0x2b3b4ffc 0xb155d20c 0x4eb5de53 0xf078715b
- ;
diff --git a/arch/x86/dts/microcode/m0220661105_cv.dtsi
b/arch/x86/dts/microcode/m0220661105_cv.dtsi
index ada8bfc..b2f7642 100644
--- a/arch/x86/dts/microcode/m0220661105_cv.dtsi
+++ b/arch/x86/dts/microcode/m0220661105_cv.dtsi
@@ -32,19 +32,21 @@
* node.
*
* Date: Sat Sep 13 22:51:38 CST 2014
+ *
+ * Device tree properties for this microcode:
+ *
+ * compatible = intel,microcode;
+ * intel,header-version = 1;
+ * intel,update-revision = 0x105;
+ * intel,date-code = 0x7182011;
+ * intel,processor-signature = 0x20661;
+ * intel,checksum = 0x52558795;
+ * intel,loader-revision = 1;
+ * intel,processor-flags = 0x2;
*/
-compatible = intel,microcode;
-intel,header-version = 1;
-intel,update-revision = 0x105;
-intel,date-code = 0x7182011;
-intel,processor-signature = 0x20661;
Re: [U-Boot] Wrong release date for v2015.10 on the denx.de
Dear Bin, In message caeuhbmv0hvpovzksztnyy-34caav7fxuyuou3zr8tej+vox...@mail.gmail.com you wrote: Also I noticed that there is no statistics for v2015.07 release on this page. Is it coming? Thanks for the reminder. Fixed now, see http://www.denx.de/wiki/U-Boot/UbootStat_2015_07 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Genitiv ins Wasser, weil's Dativ ist! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx6 move TARGET_xx Kconfig option to mx6 specific Kconfig file
On 07.08.2015 03:17, Peng Fan wrote: On Thu, Aug 06, 2015 at 11:34:16AM +0200, Soeren Moch wrote: On 08/06/15 07:43, Peng Fan wrote: Move TARGET_xx Kconfig option based on mx6 to arch/arm/cpu/armv7/mx6/Kconfig. Add enable CONFIG_ARCH_MX6 for boards based on mx6. Then we can choose target boards using make ARCH=arm menuconfig with ARCH_MX6 defined. If using original way, we have no chance to enable ARCH_MX6 when make menuconfig. Even define CONFIG_ARCH_MX6=y in xx_defconfig, kconfig will complains arch/../configs/platinum_titanium_defconfig:3: warning: override: TARGET_PLATINUM_TITANIUM changes choice state Signed-off-by: Peng Fan peng@freescale.com Cc: Stefano Babic sba...@denx.de Cc: Heiko Schocher h...@denx.de Cc: Tim Harvey thar...@gateworks.com Cc: Eric Bénard e...@eukrea.com Cc: Fabio Estevam fabio.este...@freescale.com Cc: Eric Nelson eric.nel...@boundarydevices.com Cc: Marek Vasut ma...@denx.de Cc: Christian Gmeiner christian.gmei...@gmail.com Cc: Stefan Roese s...@denx.de Cc: Soeren Moch sm...@web.de Cc: Otavio Salvador ota...@ossystems.com.br Signed-off-by: Peng Fan peng@freescale.com --- [...] index dce7ffc..b7481e7 100644 --- a/arch/arm/cpu/armv7/mx6/Kconfig +++ b/arch/arm/cpu/armv7/mx6/Kconfig @@ -46,6 +46,113 @@ config TARGET_SECOMX6 config TARGET_TQMA6 bool TQ Systems TQMa6 board +config TARGET_UDOO + bool Support udoo + select CPU_V7 + select SUPPORT_SPL + +config TARGET_OT1200 + bool Bachmann OT1200 + select CPU_V7 + select SUPPORT_SPL + +config TARGET_WANDBOARD + bool Support wandboard + select CPU_V7 + select SUPPORT_SPL + +config TARGET_WARP + bool Support WaRP + select CPU_V7 + +config TARGET_MX6CUBOXI + bool Support Solid-run mx6 boards + select CPU_V7 + select SUPPORT_SPL + +config TARGET_MX6SLEVK + bool Support mx6slevk + select CPU_V7 + +config TARGET_MX6SXSABRESD + bool Support mx6sxsabresd + select CPU_V7 + select SUPPORT_SPL + select DM + select DM_THERMAL + +config TARGET_MX6UL_14X14_EVK + bool Support mx6ul_14x14_evk + select CPU_V7 + select DM + select DM_THERMAL + select SUPPORT_SPL + +config TARGET_MX6QARM2 + bool Support mx6qarm2 + select CPU_V7 + +config TARGET_MX6QSABREAUTO + bool Support mx6qsabreauto + select CPU_V7 + select DM + select DM_THERMAL + +config TARGET_MX6SABRESD + bool Support mx6sabresd + select CPU_V7 + select SUPPORT_SPL + select DM + select DM_THERMAL + +config TARGET_GW_VENTANA + bool Support gw_ventana + select CPU_V7 + select SUPPORT_SPL + +config TARGET_TITANIUM + bool Support titanium + select CPU_V7 + +config TARGET_NITROGEN6X + bool Support nitrogen6x + select CPU_V7 + +config TARGET_CGTQMX6EVAL + bool Support cgtqmx6eval + select CPU_V7 + +config TARGET_EMBESTMX6BOARDS + bool Support embestmx6boards + select CPU_V7 + +config TARGET_ARISTAINETOS + bool Support aristainetos + select CPU_V7 + +config TARGET_ARISTAINETOS2 + bool Support aristainetos2 + select CPU_V7 + +config TARGET_KOSAGI_NOVENA + bool Support Kosagi Novena + select CPU_V7 + select SUPPORT_SPL + +config TARGET_TBS2910 + bool Support tbs2910 + select CPU_V7 + +config TARGET_PLATINUM_PICON + bool Support platinum-picon + select CPU_V7 + select SUPPORT_SPL + +config TARGET_PLATINUM_TITANIUM + bool Support platinum-titanium + select CPU_V7 + select SUPPORT_SPL + endchoice config SYS_SOC [...] [...] Also I think we don't need Support in the board select options, unfortunately this is already not consistent in arch/arm/cpu/armv7/mx6/Kconfig . Would you please more clear about this? I can not follow you. The reason I did this patch is that we can not select ARCH_MX6, if all the board target options in arch/arm/Kconfig. Since we can not select ARCH_MX6, the Kconfig options in arch/arm/cpu/armv7/mx6/Kconfig will not effect. Peng, Sorry for being unclear here. In your patch you add several options in arch/arm/cpu/armv7/mx6/Kconfig under MX6 board select. Some of these options are named Support boardname (e.g. Support udoo), while others are simply called boardname (e.g. Bachmann OT1200). I would prefer the simple boardname naming style for all options and remove the word Support from all description strings. But this is only my personal opinion and a minor cosmetic change. Regards, Soeren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 6/6] fsl: common: pfuze: no use original pfuze code if DM_PMIC
If enable DM PMIC and REGULATOR, we should not use original power
framework. So need to comment out the pfuze code for original power
framework, when CONFIG_DM_PMIC_PFUZE100 defined.
Signed-off-by: Peng Fan peng@freescale.com
Cc: Przemyslaw Marczak p.marc...@samsung.com
Cc: Simon Glass s...@chromium.org
Cc: Stefano Babic sba...@denx.de
Reviewed-by: Simon Glass s...@chromium.org
---
Changes v3:
None
Changes v2:
None
board/freescale/common/pfuze.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/board/freescale/common/pfuze.c b/board/freescale/common/pfuze.c
index d6a209e..783c46d 100644
--- a/board/freescale/common/pfuze.c
+++ b/board/freescale/common/pfuze.c
@@ -9,6 +9,7 @@
#include power/pmic.h
#include power/pfuze100_pmic.h
+#ifndef CONFIG_DM_PMIC_PFUZE100
int pfuze_mode_init(struct pmic *p, u32 mode)
{
unsigned char offset, i, switch_num;
@@ -90,3 +91,4 @@ struct pmic *pfuze_common_init(unsigned char i2cbus)
return p;
}
+#endif
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 3/6] power: regulator: update comments for regulator-name
We do not need that regulator-name property must be provided in dts.
If regulator-name property is not provided in dts, node name
will chosen for settings '.name' field of uc_pdata.
Signed-off-by: Peng Fan peng@freescale.com
Cc: Przemyslaw Marczak p.marc...@samsung.com
Cc: Simon Glass s...@chromium.org
---
Changes v3:
Keep regulator-name = VDD_MMC_1.8V; (must be unique for proper bind)
addressing Przemyslaw's comments.
Changes v2:
New patch. Update comments for regulator-name property.
doc/device-tree-bindings/regulator/regulator.txt | 19 ---
include/power/regulator.h| 1 +
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/doc/device-tree-bindings/regulator/regulator.txt
b/doc/device-tree-bindings/regulator/regulator.txt
index 68b02a8..2cf4b9d 100644
--- a/doc/device-tree-bindings/regulator/regulator.txt
+++ b/doc/device-tree-bindings/regulator/regulator.txt
@@ -15,15 +15,8 @@ For the node name e.g.: prefix[:alpha:]num { ... }:
Example the prefix ldo will pass for: ldo1, ldo@1, LDO1, LDOREG@1...
-Required properties:
-- regulator-name: a string, required by the regulator uclass
-
-Note
-The regulator-name constraint is used for setting the device's uclass
-platform data '.name' field. And the regulator device name is set from
-it's node name.
-
Optional properties:
+- regulator-name: a string, required by the regulator uclass
- regulator-min-microvolt: a minimum allowed Voltage value
- regulator-max-microvolt: a maximum allowed Voltage value
- regulator-min-microamp: a minimum allowed Current value
@@ -31,6 +24,12 @@ Optional properties:
- regulator-always-on: regulator should never be disabled
- regulator-boot-on: enabled by bootloader/firmware
+Note
+The regulator-name constraint is used for setting the device's uclass
+platform data '.name' field. And the regulator device name is set from
+it's node name. If regulator-name is not provided in dts, node name
+is chosen for setting the device's uclass platform data '.name' field.
+
Other kernel-style properties, are currently not used.
Note:
@@ -41,10 +40,8 @@ For the regulator autoset from constraints, the framework
expects that:
Example:
ldo0 {
- /* Mandatory */
- regulator-name = VDDQ_EMMC_1.8V;
-
/* Optional */
+ regulator-name = VDDQ_EMMC_1.8V;
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-min-microamp = 10;
diff --git a/include/power/regulator.h b/include/power/regulator.h
index 0152290..1a51c3f 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -46,6 +46,7 @@
* Note: For the proper operation, at least name constraint is needed, since
* it can be used when calling regulator_get_by_platname(). And the mandatory
* rule for this name is, that it must be globally unique for the single dts.
+ * If regulator-name property is not provided, node name will be chosen.
*
* Regulator bind:
* For each regulator device, the device_bind() should be called with passed
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 4/6] power: pmic: pfuze100 support driver model
1. Support driver model for pfuze100.
2. Introduce a new Kconfig entry DM_PMIC_PFUZE100 for pfuze100
3. This driver intends to support PF100, PF200 and PF3000, so add
the device id into the udevice_id array.
4. Rename PMIC_NUM_OF_REGS macro to PFUZE100_NUM_OF_REGS.
Signed-off-by: Peng Fan peng@freescale.com
Cc: Przemyslaw Marczak p.marc...@samsung.com
Cc: Simon Glass s...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
---
Changes v3:
Addressed Przemyslaw's comments:
Keep the original driver.
Use CONFIG_DM_PMIC_PFUZE100 in Makefile to cover the new driver.
Discard the type cast for driver data.
Changes v2:
Addressed Przemyslaw's comments:
Rename PMIC_NUM_OF_REGS to PFUZE100_NUM_OF_REGS
Sort variables' order
Define PFUZE100_REGULATOR_DRIVER for pfuze100_regulator in header file.
drivers/power/pmic/Kconfig| 7
drivers/power/pmic/Makefile | 1 +
drivers/power/pmic/pfuze100.c | 96 +++
include/power/pfuze100_pmic.h | 7 +++-
4 files changed, 110 insertions(+), 1 deletion(-)
create mode 100644 drivers/power/pmic/pfuze100.c
diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index 164f421..0df91be 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -10,6 +10,13 @@ config DM_PMIC
- 'drivers/power/pmic/pmic-uclass.c'
- 'include/power/pmic.h'
+config DM_PMIC_PFUZE100
+ bool Enable Driver Model for PMIC PFUZE100
+ depends on DM_PMIC
+ ---help---
+ This config enables implementation of driver-model pmic uclass features
+ for PMIC PFUZE100. The driver implements read/write operations.
+
config DM_PMIC_MAX77686
bool Enable Driver Model for PMIC MAX77686
depends on DM_PMIC
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 8c1ce3d..f49b236 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -7,6 +7,7 @@
obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
+obj-$(CONFIG_DM_PMIC_PFUZE100) += pfuze100.o
obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
obj-$(CONFIG_POWER_LTC3676) += pmic_ltc3676.o
obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
diff --git a/drivers/power/pmic/pfuze100.c b/drivers/power/pmic/pfuze100.c
new file mode 100644
index 000..3beb48e
--- /dev/null
+++ b/drivers/power/pmic/pfuze100.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2015 Freescale Semiconductor, Inc
+ * Peng Fan peng@freescale.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include fdtdec.h
+#include errno.h
+#include dm.h
+#include i2c.h
+#include power/pmic.h
+#include power/regulator.h
+#include power/pfuze100_pmic.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct pmic_child_info pmic_children_info[] = {
+ /* sw[x], swbst */
+ { .prefix = s, .driver = PFUZE100_REGULATOR_DRIVER },
+ /* vgen[x], vsnvs, vcc, v33, vcc_sd */
+ { .prefix = v, .driver = PFUZE100_REGULATOR_DRIVER },
+ { },
+};
+
+static int pfuze100_reg_count(struct udevice *dev)
+{
+ return PFUZE100_NUM_OF_REGS;
+}
+
+static int pfuze100_write(struct udevice *dev, uint reg, const uint8_t *buff,
+ int len)
+{
+ if (dm_i2c_write(dev, reg, buff, len)) {
+ error(write error to device: %p register: %#x!, dev, reg);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int pfuze100_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
+{
+ if (dm_i2c_read(dev, reg, buff, len)) {
+ error(read error from device: %p register: %#x!, dev, reg);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int pfuze100_bind(struct udevice *dev)
+{
+ int children;
+ int regulators_node;
+ const void *blob = gd-fdt_blob;
+
+ regulators_node = fdt_subnode_offset(blob, dev-of_offset,
+regulators);
+ if (regulators_node = 0) {
+ debug(%s: %s regulators subnode not found!, __func__,
+ dev-name);
+ return -ENXIO;
+ }
+
+ debug(%s: '%s' - found regulators subnode\n, __func__, dev-name);
+
+ children = pmic_bind_children(dev, regulators_node, pmic_children_info);
+ if (!children)
+ debug(%s: %s - no child found\n, __func__, dev-name);
+
+ /* Always return success for this device */
+ return 0;
+}
+
+static struct dm_pmic_ops pfuze100_ops = {
+ .reg_count = pfuze100_reg_count,
+ .read = pfuze100_read,
+ .write = pfuze100_write,
+};
+
+static const struct udevice_id pfuze100_ids[] = {
+ { .compatible = fsl,pfuze100, .data = PFUZE100, },
+ { .compatible = fsl,pfuze200, .data = PFUZE200, },
+ { .compatible = fsl,pfuze3000, .data = PFUZE3000, },
+ { }
+};
+
+U_BOOT_DRIVER(pmic_pfuze100) = {
+ .name = pfuze100 pmic,
+ .id =
[U-Boot] [PATCH V3 5/6] power: regulator: add pfuze100 support
1. Add new regulator driver pfuze100.
* Introduce struct pfuze100_regulator_desc for maintaining info
for one regulator.
2. Add new Kconfig entry DM_REGULATOR_PFUZE100 for pfuze100.
3. This driver intends to support PF100, PF200 and PF3000.
4. Add related macro definition in pfuze header file.
Signed-off-by: Peng Fan peng@freescale.com
Cc: Przemyslaw Marczak p.marc...@samsung.com
Cc: Simon Glass s...@chromium.org
---
Changes v3:
Discard the double pointer, using struct pfuze100_regulator_platdata
following Simon's suggestion.
Changes v2:
Addressed Simon's comments.
1. Use pmic_reg_read/pmic_reg_write/pmic_clrsetbits
2. blank line between declarations and rest
drivers/power/regulator/Kconfig| 8 +
drivers/power/regulator/Makefile | 1 +
drivers/power/regulator/pfuze100.c | 568 +
include/power/pfuze100_pmic.h | 24 +-
4 files changed, 597 insertions(+), 4 deletions(-)
create mode 100644 drivers/power/regulator/pfuze100.c
diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index 6289b83..b854773 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -16,6 +16,14 @@ config DM_REGULATOR
for this purpose if PMIC I/O driver is implemented or dm_scan_fdt_node()
otherwise. Detailed information can be found in the header file.
+config DM_REGULATOR_PFUZE100
+ bool Enable Driver Model for REGULATOR PFUZE100
+ depends on DM_REGULATOR DM_PMIC_PFUZE100
+ ---help---
+ This config enables implementation of driver-model regulator uclass
+ features for REGULATOR PFUZE100. The driver implements get/set api for:
+ value, enable and mode.
+
config DM_REGULATOR_MAX77686
bool Enable Driver Model for REGULATOR MAX77686
depends on DM_REGULATOR DM_PMIC_MAX77686
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index 96aa624..9f8f17b 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -7,5 +7,6 @@
obj-$(CONFIG_DM_REGULATOR) += regulator-uclass.o
obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
+obj-$(CONFIG_DM_REGULATOR_PFUZE100) += pfuze100.o
obj-$(CONFIG_DM_REGULATOR_FIXED) += fixed.o
obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
diff --git a/drivers/power/regulator/pfuze100.c
b/drivers/power/regulator/pfuze100.c
new file mode 100644
index 000..4702161
--- /dev/null
+++ b/drivers/power/regulator/pfuze100.c
@@ -0,0 +1,568 @@
+#include common.h
+#include fdtdec.h
+#include errno.h
+#include dm.h
+#include i2c.h
+#include power/pmic.h
+#include power/regulator.h
+#include power/pfuze100_pmic.h
+
+/**
+ * struct pfuze100_regulator_desc - regulator descriptor
+ *
+ * @name: Identify name for the regulator.
+ * @type: Indicates the regulator type.
+ * @uV_step: Voltage increase for each selector.
+ * @vsel_reg: Register for adjust regulator voltage for normal.
+ * @vsel_mask: Mask bit for setting regulator voltage for normal.
+ * @stby_reg: Register for adjust regulator voltage for standby.
+ * @stby_mask: Mask bit for setting regulator voltage for standby.
+ * @volt_table: Voltage mapping table (if table based mapping).
+ * @voltage: Current voltage for REGULATOR_TYPE_FIXED type regulator.
+ */
+struct pfuze100_regulator_desc {
+ char *name;
+ enum regulator_type type;
+ unsigned int uV_step;
+ unsigned int vsel_reg;
+ unsigned int vsel_mask;
+ unsigned int stby_reg;
+ unsigned int stby_mask;
+ unsigned int *volt_table;
+ unsigned int voltage;
+};
+
+/**
+ * struct pfuze100_regulator_platdata - platform data for pfuze100
+ *
+ * @desc: Points the description entry of one regulator of pfuze100
+ */
+struct pfuze100_regulator_platdata {
+ struct pfuze100_regulator_desc *desc;
+};
+
+#define PFUZE100_FIXED_REG(_name, base, vol) \
+ { \
+ .name = #_name, \
+ .type = REGULATOR_TYPE_FIXED, \
+ .voltage= (vol), \
+ }
+
+#define PFUZE100_SW_REG(_name, base, step) \
+ { \
+ .name = #_name, \
+ .type = REGULATOR_TYPE_BUCK,\
+ .uV_step= (step), \
+ .vsel_reg = (base) + PFUZE100_VOL_OFFSET, \
+ .vsel_mask = 0x3F, \
+ .stby_reg = (base) + PFUZE100_STBY_OFFSET, \
+ .stby_mask = 0x3F, \
+ }
+
+#define PFUZE100_SWB_REG(_name, base, mask, step, voltages)\
+
[U-Boot] [PATCH 4/4] x86: baytrail: Support multiple microcode copies
Intel FSP has the capability to walk through the microcode blocks which are passed as the TempRamInit() parameter from U-Boot and finds the most appropriate microcode which is suitable for the cpu on which it is running. Now we've seen several steppings for Intel BayTrail series processors, adding those microcodes to the Intel BayleyBay and MinnowMax board device tree files. Signed-off-by: Bin Meng bmeng...@gmail.com --- arch/x86/dts/bayleybay.dts | 2 ++ arch/x86/dts/minnowmax.dts | 1 + 2 files changed, 3 insertions(+) diff --git a/arch/x86/dts/bayleybay.dts b/arch/x86/dts/bayleybay.dts index ea27537..bceef60 100644 --- a/arch/x86/dts/bayleybay.dts +++ b/arch/x86/dts/bayleybay.dts @@ -235,6 +235,8 @@ data = #include microcode/m0230671117.dtsi +#include microcode/m0130673322.dtsi +#include microcode/m0130679901.dtsi ; }; }; diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts index 5711510..2af67e4 100644 --- a/arch/x86/dts/minnowmax.dts +++ b/arch/x86/dts/minnowmax.dts @@ -198,6 +198,7 @@ data = #include microcode/m0130673322.dtsi +#include microcode/m0130679901.dtsi ; }; }; -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12] sniper: Serial number support, obtained from die ID
Le mardi 04 août 2015 à 14:27 -0400, Tom Rini a écrit :
On Tue, Aug 04, 2015 at 08:22:39PM +0200, Paul Kocialkowski wrote:
Le mardi 04 août 2015 à 14:16 -0400, Tom Rini a écrit :
On Tue, Aug 04, 2015 at 08:02:40PM +0200, Paul Kocialkowski wrote:
Le lundi 03 août 2015 à 22:08 -0400, Tom Rini a écrit :
On Mon, Jul 20, 2015 at 03:17:13PM +0200, Paul Kocialkowski wrote:
The OMAP3 has some die-specific ID bits that we can use to give the
device a
(more or less) unique serial number. This is particularly useful
for e.g. USB.
Signed-off-by: Paul Kocialkowski cont...@paulk.fr
---
board/lge/sniper/sniper.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/board/lge/sniper/sniper.c b/board/lge/sniper/sniper.c
index 44d422d..f26855d 100644
--- a/board/lge/sniper/sniper.c
+++ b/board/lge/sniper/sniper.c
@@ -70,7 +70,9 @@ int board_init(void)
int misc_init_r(void)
{
+ char serial_string[17] = { 0 };
char reboot_mode[2] = { 0 };
+ u32 dieid[4] = { 0 };
/* Reboot mode */
@@ -82,6 +84,17 @@ int misc_init_r(void)
omap_reboot_mode_clear();
}
+ /* Serial number */
+
+ get_dieid((u32 *)dieid);
+
+ if (!getenv(serial#)) {
+ snprintf(serial_string, sizeof(serial_string),
+ %08x%08x, dieid[0], dieid[3]);
+
+ setenv(serial#, serial_string);
+ }
+
return 0;
}
Shouldn't this be in more generic code so everyone gets this set now?
Thanks!
Well, we had a similar discussion for sunxi, and the outcome was that
serial number could be obtained from other places on other devices (e.g.
EEPROM) or be calculated from the dieid bits in a different way, so I
prefer to keep this board-specific instead of omap3-generic for now.
This merely matches what is done on Android OMAP devices, but one could
do it another way, too.
What do you think?
I think, ug,
arch/arm/cpu/armv7/omap-common/utils.c::usb_set_serial_num_from_die_id()
should be called set_serial_num_from_die_id() and we can use that for
this board too even if it's not ideal.
Oh okay then, I don't have any problem with making this code common,
especially if it's not called by every omap3 board then.
I agree with your proposal. Should I submit a v2 with a patch in that
direction?
Sounds good, thanks!
Taking a closer look at things, it appears that various (non-omap3)
boards are grabbing the Die ID bits on their own and then calling those
functions (usb_fake_mac_from_die_id, usb_set_serial_num_from_die_id).
IMHO, we should have a common naming scheme for the function to get the
dieid (omap_dieid), define that for each omap platform and have it
called in omap-common code (with one function for the serial number and
one for the fake mac), just like what I did with omap_sys_boot_device.
Then, each board would simply call those functions directly, without
having to care about how to obtain the die id bits.
This seems like a series that would deserve to live on its own, so I
suggest that you merge Optimus Black support as-is for now and I'll
submit another series to implement that behaviour on top.
What do you think?
--
Paul Kocialkowski, Replicant developer
Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.
Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/
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] imx: mx6 move TARGET_xx Kconfig option to mx6 specific Kconfig file
On Friday, August 07, 2015 at 09:33:02 AM, Stefano Babic wrote: Hi Peng, Soeren, Hi, On 07/08/2015 09:19, Soeren Moch wrote: Peng, Sorry for being unclear here. In your patch you add several options in arch/arm/cpu/armv7/mx6/Kconfig under MX6 board select. Some of these options are named Support boardname (e.g. Support udoo), while others are simply called boardname (e.g. Bachmann OT1200). I would prefer the simple boardname naming style for all options and remove the word Support from all description strings. But this is only my personal opinion and a minor cosmetic change. Checking in other architecture, I see there is no rule about this. Even in the same Kconfig (AT91), there is a mix with and without Support. Both are ok - decide yourself. The Support is implicit (you won't select it if you didn't want to support that board, would you?), so please use just the board name. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2015.07 released
Dear Jagan, In message CAD6G_RTB0KyiYMWv5_jQ0VPzJ3P+5vYPgrYwsLUAX=gygof...@mail.gmail.com you wrote: Any idea why would openedev missing on employer, does we need to indicate some where as all code was s-o-b openedev.com openedev.com has no entry in the domain-map. What should I add? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When the ax entered the forest, the trees said, The handle is one of us! -- Turkish proverb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/t1024qds: Add missing T1024QDS_DDR4_defconfig
T1024QDS with DDR4 has been supported. Add the missing defconfig. Signed-off-by: York Sun york...@freescale.com CC: Shengzhou Liu shengzhou@freescale.com --- configs/T1024QDS_DDR4_defconfig |5 + 1 file changed, 5 insertions(+) create mode 100644 configs/T1024QDS_DDR4_defconfig diff --git a/configs/T1024QDS_DDR4_defconfig b/configs/T1024QDS_DDR4_defconfig new file mode 100644 index 000..174fbca --- /dev/null +++ b/configs/T1024QDS_DDR4_defconfig @@ -0,0 +1,5 @@ +CONFIG_PPC=y +CONFIG_MPC85xx=y +CONFIG_TARGET_T102XQDS=y +CONFIG_SYS_EXTRA_OPTIONS=PPC_T1024,SYS_FSL_DDR4 +CONFIG_SPI_FLASH=y -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/6] power: regulator use node name when no regulator-name
On 7 August 2015 at 02:43, Peng Fan peng@freescale.com wrote: If there is no property named 'regulator-name' for regulators, choose node name instead, but not directly return failure value. Signed-off-by: Peng Fan peng@freescale.com Cc: Przemyslaw Marczak p.marc...@samsung.com Cc: Simon Glass s...@chromium.org --- Changes v3: None. Changes v2: None. The comments update patch, see 3/6. drivers/power/regulator/regulator-uclass.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Acked-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 1/2] gpio: Add DW APB GPIO driver
Hi Marek, On 5 August 2015 at 19:49, Marek Vasut ma...@denx.de wrote: On Wednesday, August 05, 2015 at 04:39:33 PM, Simon Glass wrote: Hi Marek, Hi Simon, On 2 August 2015 at 18:16, Marek Vasut ma...@denx.de wrote: On Monday, August 03, 2015 at 01:38:28 AM, Simon Glass wrote: Hi Marek, Hi Simon, [...] + if (!fdtdec_get_bool(blob, node, gpio-controller)) + continue; + + plat = NULL; + plat = calloc(1, sizeof(*plat)); I suppose this should use devm_alloc() now. Is that even in u-boot/master ? Also, I'm not sure it's a good idea to put this in if I use this driver in SPL. Yes it's very new. Only in dm/master. It's only compiled in when enabled, so you can still use it in SPL. Up to you. At some point I think we should convert all driver allocs to use devm so that we know what allocation is going on. When is this landing in master ? I don't mind either way, but I can do a linting pass on the socfpga when things settle down too. Hopefully I'll have a pull request out on Friday. Cool! + if (!plat) + return -ENOMEM; + + plat-base = base; + plat-bank = bank; + plat-pins = fdtdec_get_int(blob, node, snps,nr-gpios, 0); + snprintf(plat-name, sizeof(plat-name) - 1, %s-bank%i-, + name, bank); Why such a long name? That's going to be a pain to type in the 'gpio' command. Do you have a suggestion please ? A, B, C is good if you have =26 banks. Tegra does that. Exynos does PA0, PA1, PB0, PC0, PC1, etc. How do I identify which one is PA0/PA1/PA2 , shall I perform some transformation on the register address of the GPIO block or example ? But how can I assure that if the next SoCFPGA has these addresses completely different, these GPIO numbers will be stable ? Isn't it better to be explicit about the GPIO block ID then ? It's up to you. Normally each bank has a name and the datasheet specifies it. In your case if not you could think about a naming scheme. Can you please take a look into arch/arm/dts/socfpga.dtsi ? The system has three GPIO controllers (look for gpio0, gpio1, gpio2) and each of these controllers has one bank (porta, portb, portc) . I can name my gpios portxN , where x is either of a,b,c and N is the GPIO number. The problem is, I cannot determine in dwapb_gpio_bind() which one is porta, portb and portc because all I have is the physical addess of the GPIO controller and the index of the bank in the namespace of that controller. Sure, I can do some sort of global counting in the driver, but I would like to avoid that sort of thing. I can also add some kind of ad-hoc DT prop, but that's also not a good idea I think. Do you have any suggestion for me please ? One option is to use the device tree node name but it isn't very friendly - gpio0@x. You could perhaps add a new property like 'bank-name'? Also, remember that I have an FPGA in the same package, which has a lot of I/O. Also, I can as well use gpio operation N , where N is a number. What about this ? How does indexing the GPIOs with plain number fit into the picture please ? Driver model GPIO handles this automatically. If you can add different numbers of GPIO blocks you might consider adding them as different GPIO banks with their own names. The global number depends on the probe order which depends on the bind order (i.e. device tree node order). But names are safer than numbers - a small change can change all the numbers. There is a function to get the global number given a GPIO device and offset. I see, thanks for clarifying! Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] driver model is not smp safe
Hi Bin, On 5 August 2015 at 02:43, Bin Meng bmeng...@gmail.com wrote: Hi Simon, Tom, On Tue, Aug 4, 2015 at 3:27 AM, Simon Glass s...@chromium.org wrote: Hi Tom, On 3 August 2015 at 13:06, Tom Rini tr...@konsulko.com wrote: On Mon, Aug 03, 2015 at 12:52:19PM -0600, Simon Glass wrote: Hi Tom, On 31 July 2015 at 08:31, Tom Rini tr...@konsulko.com wrote: On Thu, Jul 30, 2015 at 12:12:03PM +0800, Bin Meng wrote: Hi Simon, When adding x86 multi-cpu initialization on a board with 4 cores, I found: = cpu list 0: cpu@0 Genuine Intel(R) CPU @ 1.58GHz 1: cpu@1 Genuine Intel(R) CPU @ 1.58GHz 2: cpu@2 Genuine Intel(R) CPU @ 1.58GHz 2: cpu@3 Genuine Intel(R) CPU @ 1.58GHz cpu@2 and cpu@3 have the same sequence number, which indicates they are running parallelly to get the same sequence number. The call chain on an ap is: mp_init_cpu() - device_probe() - uclass_resolve_seq(). Apparently ap2 and ap3 are running at the same time to get the same number. Note so far all x86 boards that we have enabled x86 multi-cpu initialization on only have 2 cores, which will not expose such issue as there is no parallel execution among aps. So what exactly are we doing with these additional cores? My recollection of what we do on other arches when we even deal with other cores is that we bring them up and then usually put them in a holding pattern for the real OS to deal with _or_ it's one of those cases where we have multiple OSes running and we do what we need to load and release those other OSes. In this case they end up at stop_this_cpu() which is just a hlt instruction in each case. So do we really have to be doing anything here? Or is this just pre-emptive work for an async MP type setup down the road? We could probably live with this with a big comment noting why we know it's misbehaving. I think we should fix it - I suggested some options above and Bin may have ideas also. Bin may be able to send a patch since he can repeat the problem. Yes we should fix it. But IMHO, just fixing the seq number only resolves the surface problem. What concerns me is that multiple cpu running the same piece of codes (in this case, the DM core codes) without any protection. I have no idea whether these core structures (like the device list) still look good from the DM core perspective. Although right now it seems that it only exposes the seq number issue, we don't know if there are other potential DM issues. Thus I was thinking fundamentally we are using DM CPU uclass in a wrong way. We don't add devices when running on the AP CPUs - we only scan lists. So long as the boot CPU creates all the devices and then waits for them to populate, we are OK. I don't see any fundamental problem. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_DM_ETH USB_ETHER_ASIX Reception Issue on Tegra
Hi Marcel, On 7 August 2015 at 00:41, Marcel Ziswiler mar...@ziswiler.com wrote: On Thu, 2015-08-06 at 23:29 -0600, Simon Glass wrote: The memalign() function arguments are around the wrong way! I assume you meant that one: diff --git a/drivers/usb/eth/usb_ether.c b/drivers/usb/eth/usb_ether.c index 3c3e082..11d26be 100644 --- a/drivers/usb/eth/usb_ether.c +++ b/drivers/usb/eth/usb_ether.c @@ -73,7 +73,7 @@ int usb_ether_register(struct udevice *dev, struct ueth_data *ueth, int rxsize) } ueth-rxsize = rxsize; - ueth-rxbuf = memalign(rxsize, ARCH_DMA_MINALIGN); + ueth-rxbuf = memalign(ARCH_DMA_MINALIGN, rxsize); if (!ueth-rxbuf) return -ENOMEM; Definitely worth seeing if that fixes it. For some reason rpi and minnowboard seem to work even with this error. Unfortunately still the same: U-Boot SPL 2015.10-rc1-00188-gfac971b-dirty (Aug 07 2015 - 06:34:28) U-Boot 2015.10-rc1-00188-gfac971b-dirty (Aug 07 2015 - 06:34:28 +) TEGRA20 Model: Toradex Colibri T20 Board: Toradex Colibri T20 DRAM: 512 MiB NAND: 1024 MiB MMC: Tegra SD/MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 Colibri T20 # usb start starting USB... USB0: USB EHCI 1.00 USB1: USB EHCI 1.00 USB2: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning bus 2 for devices... Warning: asix_eth using MAC address from ROM 2 USB Device(s) found scanning bus 0 for devices... 1 USB Device(s) found Colibri T20 # dhcp BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 EHCI timed out on TD - token=0x8008d80 Rx: failed to receive: -5 BOOTP broadcast 4 BOOTP broadcast 5 EHCI timed out on TD - token=0x88008d80 Rx: failed to receive: -5 BOOTP broadcast 6 BOOTP broadcast 7 EHCI timed out on TD - token=0x8008d80 Rx: failed to receive: -5 BOOTP broadcast 8 BOOTP broadcast 9 EHCI timed out on TD - token=0x88008d80 Rx: failed to receive: -5 Retry time exceeded; starting again Colibri T20 # One point to make is that I have seen this on and off for a while. When I tested the driver model EHCI support I found this bug. But then when I turned off driver model it was still there. So I decided it was pre-existing. Also I'm not sure that this error is handled correctly. The code that times out does not retry properly. Marek do Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] Allow arch-specific setting of global_data in board_init_f_mem()
Hi Bin,
On 6 August 2015 at 01:15, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Mon, Aug 3, 2015 at 8:10 AM, Simon Glass s...@chromium.org wrote:
At present we have a simple assignment to gd. With some archs this is
implemented as a register or through some other means; a simple assignment
does not suit in all cases.
Change this to a function and add documentation to describe how this all
works.
Signed-off-by: Simon Glass s...@chromium.org
---
common/board_f.c | 14 +++---
include/common.h | 40
2 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index a947770..3d1f305 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -1024,15 +1024,23 @@ void board_init_f_r(void)
#endif /* CONFIG_X86 */
#ifndef CONFIG_X86
-ulong board_init_f_mem(ulong top)
+__weak void arch_setup_gdt(struct global_data *gd_ptr)
{
+ gd = gd_ptr;
+}
+
+ulong board_init_f_mem(ulong top, ulong reserve_size)
What is reserve_size? I don't see it is used by this function. If we
change the signature, we need also update arc and ppc4xx start.S
otherwise they will break.
Actually that should have been reverted. I decided to introduce it
later if needed, but found a way around it for x86.
+{
+ struct global_data *gd_ptr;
+
/* 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));
+ gd_ptr = (struct global_data *)top;
+ memset(gd_ptr, '\0', sizeof(*gd));
+ arch_setup_gdt(gd_ptr);
gdt? Should be just arch_setup_gd()?
Yes
#ifdef CONFIG_SYS_MALLOC_F_LEN
top -= CONFIG_SYS_MALLOC_F_LEN;
diff --git a/include/common.h b/include/common.h
index fcc9ae7..029eb1f 100644
--- a/include/common.h
+++ b/include/common.h
@@ -217,6 +217,46 @@ extern char console_buffer[];
/* arch/$(ARCH)/lib/board.c */
void board_init_f(ulong);
void board_init_r(gd_t *, ulong) __attribute__ ((noreturn));
+
+/**
+ * board_init_f_mem() - Allocate global data and set stack position
+ *
+ * This function is called by each architecture very early in the start-up
+ * code to set up the environment for board_init_f(). It allocates space for
+ * global_data (see include/asm-generic/global_data.h) and places the stack
+ * below this.
+ *
+ * This function requires a stack[1] Normally this is at @top. The function
+ * starts allocating space from 64 bytes below @top. First it creates space
+ * for global_data. then it calls arch_setup_gd() which sets gd to point to
Nits: . - ,
+ * the global_data space and can reserve additional bytes of space if
+ * required). Finally it allocates early malloc() memory
+ * (CONFIG_SYS_MALLOC_F_LEN). The new top of the stack is just below this,
+ * and it returned by this function.
+ *
+ * [1] Strictly speaking it would be possible to implement this function
+ * in C on many archs such that it does not require a stack. However this
+ * does not seem hugely important as only 64 byte are wasted.
Where is the 64 bytes it uses? I only see a variable gd_ptr on the stack.
It's the subtraction at the top of board_init_f_mem().
+ *
+ * @top: Top of available memory, also normally the top of the stack
+ * @return:New stack location
+ */
+ulong board_init_f_mem(ulong top, ulong reserve_size);
I don't like the name board_init_f_mem(). It actually does two things:
creates global data pointer and reserve the early malloc() memory
size. Also it looks like it's more like an arch thing instead of a
board's. How about setup_gd_f_mem()?
The name is the same as before. It's intended to imply that it gets
the memory ready for board_init_f(). It may expand in future to do
additional setup (e.g. to allocate some other type of space). If we
change the name we would perhaps have to change it again later. At
least this name describes its purpose.
+
+/**
+ * arch_setup_gdt() - Set up the global_data pointer
+ *
+ * This pointer is special in some architectures and cannot easily be
assigned
+ * to. For example on x86 it is implemented by adding a specific record to
its
+ * Global Descriptor Table! So we we provide a function to carry out this
task.
+ * For most architectures this can simply be:
+ *
+ *gd = gd_ptr;
+ *
+ * @gd_ptr:Pointer to global data
+ */
+void arch_setup_gdt(gd_t *gd_ptr);
+
int checkboard(void);
int show_board_info(void);
int checkflash(void);
--
Regards,
Bin
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 5/6] power: regulator: add pfuze100 support
On 7 August 2015 at 02:43, Peng Fan peng@freescale.com wrote: 1. Add new regulator driver pfuze100. * Introduce struct pfuze100_regulator_desc for maintaining info for one regulator. 2. Add new Kconfig entry DM_REGULATOR_PFUZE100 for pfuze100. 3. This driver intends to support PF100, PF200 and PF3000. 4. Add related macro definition in pfuze header file. Signed-off-by: Peng Fan peng@freescale.com Cc: Przemyslaw Marczak p.marc...@samsung.com Cc: Simon Glass s...@chromium.org --- Changes v3: Discard the double pointer, using struct pfuze100_regulator_platdata following Simon's suggestion. Changes v2: Addressed Simon's comments. 1. Use pmic_reg_read/pmic_reg_write/pmic_clrsetbits 2. blank line between declarations and rest drivers/power/regulator/Kconfig| 8 + drivers/power/regulator/Makefile | 1 + drivers/power/regulator/pfuze100.c | 568 + include/power/pfuze100_pmic.h | 24 +- 4 files changed, 597 insertions(+), 4 deletions(-) create mode 100644 drivers/power/regulator/pfuze100.c Acked-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] x86: baytrail: Add all IDE/SATA PCI device IDs
On 6 August 2015 at 03:36, Bin Meng bmeng...@gmail.com wrote: The BayTrail SoC has 4 different PCI devices IDs regarding to IDE and AHCI. Add these IDs in pci_ids.h and also add the other SATA ID in the Bayley Bay and MinnowMax board configuration header. Signed-off-by: Bin Meng bmeng...@gmail.com --- include/configs/bayleybay.h | 3 ++- include/configs/minnowmax.h | 6 -- include/pci_ids.h | 5 - 3 files changed, 10 insertions(+), 4 deletions(-) Acked-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 1/2] gpio: Add DW APB GPIO driver
On Friday, August 07, 2015 at 09:13:45 PM, Simon Glass wrote: Hi Marek, Hi! On 5 August 2015 at 19:49, Marek Vasut ma...@denx.de wrote: On Wednesday, August 05, 2015 at 04:39:33 PM, Simon Glass wrote: Hi Marek, Hi Simon, [...] It's up to you. Normally each bank has a name and the datasheet specifies it. In your case if not you could think about a naming scheme. Can you please take a look into arch/arm/dts/socfpga.dtsi ? The system has three GPIO controllers (look for gpio0, gpio1, gpio2) and each of these controllers has one bank (porta, portb, portc) . I can name my gpios portxN , where x is either of a,b,c and N is the GPIO number. The problem is, I cannot determine in dwapb_gpio_bind() which one is porta, portb and portc because all I have is the physical addess of the GPIO controller and the index of the bank in the namespace of that controller. Sure, I can do some sort of global counting in the driver, but I would like to avoid that sort of thing. I can also add some kind of ad-hoc DT prop, but that's also not a good idea I think. Do you have any suggestion for me please ? One option is to use the device tree node name but it isn't very friendly - gpio0@x. That's what I do now pretty much. You could perhaps add a new property like 'bank-name'? Do we want to add ad-hoc DT nodes which are a) Not describing hardware b) Not part of the official DT bindings for that platform ? Is that really a way to go ? [...] Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] arm: socfpga: scan: Factor out IO chain programming
On 8/3/15 9:22 AM, Marek Vasut wrote: Factor out the code which sends JTAG instruction followed by data into separate function to tidy the code up a little. Signed-off-by: Marek Vasut ma...@denx.de --- arch/arm/mach-socfpga/scan_manager.c | 113 +-- 1 file changed, 42 insertions(+), 71 deletions(-) Acked-by: Dinh Nguyen dingu...@opensource.altera.com Thanks, Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/16] drivers/net/vsc9953: Remove 'CONFIG_' from macros' name
Hi York, On Fri, Aug 7, 2015 at 4:02 PM, York Sun york...@freescale.com wrote: On 08/07/2015 01:17 PM, Joe Hershberger wrote: Hi Codrin, On Fri, Jul 24, 2015 at 8:52 AM, Codrin Ciubotariu codrin.ciubota...@freescale.com wrote: Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com --- Acked-by: Joe Hershberger joe.hershber...@ni.com Joe, Do you want to take them in, or leave them to me? They are only used on your platform, right? So it will probably be faster tested in that branch. I think you should take them, but notice that there is an issue with patch 7. Maybe you can fix it inline and not resend the series. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/16] drivers/net/vsc9953: Fix missing reserved register
Hi Codrin, On Fri, Jul 24, 2015 at 8:55 AM, Codrin Ciubotariu codrin.ciubota...@freescale.com wrote: The VSC9953 DS reserves a register between vlan_mask and anag_efil registers. Signed-off-by: Johnson Leung johnson.le...@freescale.com Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com --- Changes for v2: - removed Change-id field; Changes for v3: - added signature; include/vsc9953.h | 1 + 1 file changed, 1 insertion(+) Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/16] drivers/net/vsc9953: Cleanup patch
Hi Codrin, On Fri, Jul 24, 2015 at 8:52 AM, Codrin Ciubotariu codrin.ciubota...@freescale.com wrote: This patch groups some macros defined for registers and replaces some magic numbers from vsc9953 with macros. Also, port and port_nr words are replaced with port_no, puts each variable declaration on a line and removes unnecessary tabs. Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com --- Changes for v2: - removed Change-id field; Changes for v3: - each variable is declared on a separate line, without using tabs - some functions return macros from errno.h insted of 1 or -1 - removed duplicate of macro CONFIG_VSC9953_PAUSE_CFG - code that fixed a small bug was moved in a new patch; drivers/net/vsc9953.c | 144 +- include/vsc9953.h | 121 ++ 2 files changed, 147 insertions(+), 118 deletions(-) Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/16] drivers/net/vsc9953: Remove 'CONFIG_' from macros' name
Hi Codrin, On Fri, Jul 24, 2015 at 8:52 AM, Codrin Ciubotariu codrin.ciubota...@freescale.com wrote: Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com --- Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/16] drivers/net/vsc9953: Fix bug when enabling a port
Hi Codrin, On Fri, Jul 24, 2015 at 8:52 AM, Codrin Ciubotariu codrin.ciubota...@freescale.com wrote: When a port is enabled at init time, the initializing function touches more bits than necessary to enable a port (also touches reserved bits and default bit values). This patch fixes this issue by changing the value of the define used to enable the port and assures that no other bits are changes by replacing out_le32() with setbits_le32(). Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com --- Dhanges for v3: - none; new patch; drivers/net/vsc9953.c | 4 ++-- include/vsc9953.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] arm: socfpga: scan: Clean up scan_chain_engine_is_idle()
On 8/3/15 9:22 AM, Marek Vasut wrote: Rework this function so it's clear that it is only polling for certain bits to be cleared. Add kerneldoc. Fix it's return value to be either 0 on success and -ETIMEDOUT on error and propagate this through the scan manager code. Signed-off-by: Marek Vasut ma...@denx.de --- arch/arm/mach-socfpga/include/mach/scan_manager.h | 9 arch/arm/mach-socfpga/scan_manager.c | 53 +++ 2 files changed, 34 insertions(+), 28 deletions(-) [...] @@ -16,26 +28,26 @@ static const struct socfpga_scan_manager *scan_manager_base = static const struct socfpga_freeze_controller *freeze_controller_base = (void *)(SOCFPGA_SYSMGR_ADDRESS + SYSMGR_FRZCTRL_ADDRESS); -/* +/** + * scan_chain_engine_is_idle() - Check if the JTAG scan chain is idle + * @max_iter:Maximum number of iterations to wait for idle + * * Function to check IO scan chain engine status and wait if the engine is * is active. Poll the IO scan chain engine till maximum iteration reached. */ -static inline uint32_t scan_chain_engine_is_idle(uint32_t max_iter) +static u32 scan_chain_engine_is_idle(uint32_t max_iter) Should you go ahead and change this to u32? Only comment, otherwise: Acked-by: Dinh Nguyen dingu...@opensource.altera.com Thanks, Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_DM_ETH USB_ETHER_ASIX Reception Issue on Tegra
On Friday, August 07, 2015 at 09:09:15 PM, Simon Glass wrote: Hi Marcel, On 7 August 2015 at 00:41, Marcel Ziswiler mar...@ziswiler.com wrote: On Thu, 2015-08-06 at 23:29 -0600, Simon Glass wrote: The memalign() function arguments are around the wrong way! I assume you meant that one: diff --git a/drivers/usb/eth/usb_ether.c b/drivers/usb/eth/usb_ether.c index 3c3e082..11d26be 100644 --- a/drivers/usb/eth/usb_ether.c +++ b/drivers/usb/eth/usb_ether.c @@ -73,7 +73,7 @@ int usb_ether_register(struct udevice *dev, struct ueth_data *ueth, int rxsize) } ueth-rxsize = rxsize; - ueth-rxbuf = memalign(rxsize, ARCH_DMA_MINALIGN); + ueth-rxbuf = memalign(ARCH_DMA_MINALIGN, rxsize); if (!ueth-rxbuf) return -ENOMEM; Definitely worth seeing if that fixes it. For some reason rpi and minnowboard seem to work even with this error. Unfortunately still the same: U-Boot SPL 2015.10-rc1-00188-gfac971b-dirty (Aug 07 2015 - 06:34:28) U-Boot 2015.10-rc1-00188-gfac971b-dirty (Aug 07 2015 - 06:34:28 +) TEGRA20 Model: Toradex Colibri T20 Board: Toradex Colibri T20 DRAM: 512 MiB NAND: 1024 MiB MMC: Tegra SD/MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 Colibri T20 # usb start starting USB... USB0: USB EHCI 1.00 USB1: USB EHCI 1.00 USB2: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning bus 2 for devices... Warning: asix_eth using MAC address from ROM 2 USB Device(s) found scanning bus 0 for devices... 1 USB Device(s) found Colibri T20 # dhcp BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 EHCI timed out on TD - token=0x8008d80 Rx: failed to receive: -5 BOOTP broadcast 4 BOOTP broadcast 5 EHCI timed out on TD - token=0x88008d80 Rx: failed to receive: -5 BOOTP broadcast 6 BOOTP broadcast 7 EHCI timed out on TD - token=0x8008d80 Rx: failed to receive: -5 BOOTP broadcast 8 BOOTP broadcast 9 EHCI timed out on TD - token=0x88008d80 Rx: failed to receive: -5 Retry time exceeded; starting again Colibri T20 # One point to make is that I have seen this on and off for a while. When I tested the driver model EHCI support I found this bug. But then when I turned off driver model it was still there. So I decided it was pre-existing. Also I'm not sure that this error is handled correctly. The code that times out does not retry properly. Marek do I think there's a bit of this sentence missing. But the fix I pushed was for enumeration, not for this. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/18] dm: eth: Avoid blocking on packet reception
Hi Simon, On Mon, Jul 6, 2015 at 5:47 PM, Simon Glass s...@chromium.org wrote: Some devices can take a long time to work out whether they have a new packet or now. For example the ASIX USB Ethernet dongle can take 5 seconds to do this, since it waits until it gets a new packet on the wire before allowing the USB bulk read packet to be submitted. At present with driver mode the Ethernet receive code reads 32 packets. This can take a very long time if we must wait for all 32 packets. The old code (before driver model) worked by reading a single set of packets from the USB device, then processing all the packets with in. It would be nice to use the same behaviour with driver model. Add a flag to the receive method which indicates that the driver should try to find a packet if available, by consulting the hardware. When the flag is not set, it should just return any packet data it has already received. If there is none, it should return -EAGAIN so that the loop will terminate. Signed-off-by: Simon Glass s...@chromium.org --- Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/16] drivers/net/vsc9953: Remove 'CONFIG_' from macros' name
On 08/07/2015 01:17 PM, Joe Hershberger wrote: Hi Codrin, On Fri, Jul 24, 2015 at 8:52 AM, Codrin Ciubotariu codrin.ciubota...@freescale.com wrote: Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com --- Acked-by: Joe Hershberger joe.hershber...@ni.com Joe, Do you want to take them in, or leave them to me? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/16] drivers/net/vsc9953: Remove 'CONFIG_' from macros' name
On 08/07/2015 02:07 PM, Joe Hershberger wrote: Hi York, On Fri, Aug 7, 2015 at 4:02 PM, York Sun york...@freescale.com wrote: On 08/07/2015 01:17 PM, Joe Hershberger wrote: Hi Codrin, On Fri, Jul 24, 2015 at 8:52 AM, Codrin Ciubotariu codrin.ciubota...@freescale.com wrote: Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com --- Acked-by: Joe Hershberger joe.hershber...@ni.com Joe, Do you want to take them in, or leave them to me? They are only used on your platform, right? So it will probably be faster tested in that branch. I think you should take them, but notice that there is an issue with patch 7. Maybe you can fix it inline and not resend the series. I will take care of them. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] x86: baytrail: Configure FSP UPD from device tree
Hi Bin,
On 08/07 08:23, Bin Meng wrote:
Hi Andrew,
On Fri, Aug 7, 2015 at 4:08 AM, Andrew Bradford
and...@bradfordembedded.com wrote:
From: Andrew Bradford andrew.bradf...@kodakalaris.com
Allow for configuration of FSP UPD from the device tree which will
override any settings which the FSP was built with itself.
Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
settings from the Intel FSPv4 Gold release to the respective dts files,
with the condition that the memory-down parameters for MinnowMax are
also used.
Thanks for updating BayleyBay dts as well :)
You're welcome :)
My custom board actually boots with the Bayley Bay configuration, once I
change out the dts to use your D0 stepping microcode patch, so that was
a good check for me.
Signed-off-by: Andrew Bradford andrew.bradf...@kodakalaris.com
---
Reviewed-by: Bin Meng bmeng...@gmail.com
Tested-by: Bin Meng bmeng...@gmail.com
But please see some comments/nits below.
Would it be best if I fix your comments/nits and send a v4?
Changes from v2:
- Switch to using booleans in dts, where appropriate.
- Add Bayley Bay dts modifications.
- Clarify docs to show bool versus int properties.
- Include enable-igt property from FSPv4.
Changes from v1:
- Use - rather than _ in dt property names.
- Use Bay Trail for the formal name of the Intel product family.
- Use an fsp, prefix for dt property names for clarity.
- Fix minor code indentation issues.
- Create a dt subnode for the memory-down-params.
- Clarify documentation that dt overrides the FSP's config, so we don't
use booleans.
arch/x86/cpu/baytrail/fsp_configs.c| 167
+
arch/x86/dts/bayleybay.dts | 40 +
arch/x86/dts/minnowmax.dts | 58 +++
.../misc/intel,baytrail-fsp.txt| 158
+++
include/fdtdec.h | 2 +
lib/fdtdec.c | 2 +
6 files changed, 397 insertions(+), 30 deletions(-)
create mode 100644 doc/device-tree-bindings/misc/intel,baytrail-fsp.txt
diff --git a/arch/x86/cpu/baytrail/fsp_configs.c
b/arch/x86/cpu/baytrail/fsp_configs.c
index 86b6926..1e5656f 100644
--- a/arch/x86/cpu/baytrail/fsp_configs.c
+++ b/arch/x86/cpu/baytrail/fsp_configs.c
@@ -1,14 +1,18 @@
/*
* Copyright (C) 2013, Intel Corporation
* Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ * Copyright (C) 2015, Kodak Alaris, Inc
*
* SPDX-License-Identifier:Intel
*/
#include common.h
+#include fdtdec.h
#include asm/arch/fsp/azalia.h
#include asm/fsp/fsp_support.h
+DECLARE_GLOBAL_DATA_PTR;
+
/* ALC262 Verb Table - 10EC0262 */
static const uint32_t verb_table_data13[] = {
/* Pin Complex (NID 0x11) */
@@ -116,41 +120,144 @@ const struct pch_azalia_config azalia_config = {
.reset_wait_timer_us = 300
};
+/**
+ * Override the FSP's UPD.
+ * If the device tree does not specify a integer setting, use the default
Nits: an integer
+ * provided in Intel's Baytrail_FSP_Gold4.tgz release FSP/BayleyBayFsp.bsf
file.
+ */
void update_fsp_upd(struct upd_region *fsp_upd)
{
struct memory_down_data *mem;
+ const void *blob = gd-fdt_blob;
+ int node;
- /*
-* Configure everything here to avoid the poor hard-pressed user
-* needing to run Intel's binary configuration tool. It may also
allow
-* us to support the 1GB single core variant easily.
-*
-* TODO(s...@chromium.org): Move to device tree
-*/
- fsp_upd-mrc_init_tseg_size = 8;
- fsp_upd-mrc_init_mmio_size = 0x800;
One general comment: I think we should replace these hardcoded numbers
with meaningful macros (eg: 0x800 means MMIO uses 2GB space, that's
why we see previous the pci does not work on a 4GB DIMM as FSP only
maps 2GB RAM per this setting). See Intel's Baytrail_FSP_Gold4.tgz
release FSP/BayleyBayFsp.bsf file, it has the details of how each
magic number maps to what meaning. Will you do a follow-up patch for
this? I can do that as well.
I can do this.
For Quark, I see that there's both include/dt-bindings/mrc/quark.h (for
the dts to use) and arch/x86/include/asm/arch-quark/mrc.h (for code to
use). These two files seem to duplicate some of the same #defines. For
the FSP on Bay Trail, would it be recommended to follow a similar pair
of header files as are used for MRC on Quark or should there just be a
single header file defining the FSP magic numbers?
Regarding the MMIO region, the other choices in the FSP are 1 GB, 1.5
GB, and 2 GB. Any of those choices will cause issues when the system
has 4 GB of SDRAM, unless I'm mistaken. Although I'm fairly sure we
have some u-boot things hard coded to 0x8000 for the RAM top in 32
bit mode, so changing
[U-Boot] [PATCH 1/4] armv8: ls2085a: Update serdes1_cfg_tbl for 0x33 0x35 protocol
Update 0x33 and 0x35 serdes protocol as per updated SoC document
in array serdes1_cfg_tbl.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
arch/arm/cpu/armv8/fsl-lsch3/ls2085a_serdes.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/ls2085a_serdes.c
b/arch/arm/cpu/armv8/fsl-lsch3/ls2085a_serdes.c
index 098745b..0b79a50 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/ls2085a_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-lsch3/ls2085a_serdes.c
@@ -32,9 +32,9 @@ static struct serdes_config serdes1_cfg_tbl[] = {
{0x2A, {XFI8, XFI7, XFI6, XFI5, XFI4, XFI3, XFI2, XFI1 } },
{0x2B, {SGMII8, SGMII7, SGMII6, SGMII5, XAUI1, XAUI1, XAUI1, XAUI1 } },
{0x32, {XAUI2, XAUI2, XAUI2, XAUI2, XAUI1, XAUI1, XAUI1, XAUI1 } },
- {0x33, {PCIE2, PCIE2, PCIE2, PCIE2, QSGMII_D, QSGMII_C, QSGMII_B,
- QSGMII_A} },
- {0x35, {QSGMII_D, QSGMII_C, QSGMII_B, PCIE2, XFI4, XFI3, XFI2, XFI1 } },
+ {0x33, {PCIE2, PCIE2, PCIE2, PCIE2, QSGMII_C, QSGMII_D, QSGMII_A,
+ QSGMII_B} },
+ {0x35, {QSGMII_C, QSGMII_D, QSGMII_A, PCIE2, XFI4, XFI3, XFI2, XFI1 } },
{}
};
static struct serdes_config serdes2_cfg_tbl[] = {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
From: Andrew Bradford andrew.bradf...@kodakalaris.com
Allow for configuration of FSP UPD from the device tree which will
override any settings which the FSP was built with itself.
Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
settings from the Intel FSPv4 Gold release to the respective dts files,
with the condition that the memory-down parameters for MinnowMax are
also used.
Signed-off-by: Andrew Bradford andrew.bradf...@kodakalaris.com
---
Changes from v3:
- Fix small typographical issues (lowercase hex numbers, grammar, etc),
no functional changes.
Changes from v2:
- Switch to using booleans in dts, where appropriate.
- Add Bayley Bay dts modifications.
- Clarify docs to show bool versus int properties.
- Include enable-igt property from FSPv4.
Changes from v1:
- Use - rather than _ in dt property names.
- Use Bay Trail for the formal name of the Intel product family.
- Use an fsp, prefix for dt property names for clarity.
- Fix minor code indentation issues.
- Create a dt subnode for the memory-down-params.
- Clarify documentation that dt overrides the FSP's config, so we don't
use booleans.
arch/x86/cpu/baytrail/fsp_configs.c| 167 +
arch/x86/dts/bayleybay.dts | 40 +
arch/x86/dts/minnowmax.dts | 58 +++
.../misc/intel,baytrail-fsp.txt| 158 +++
include/fdtdec.h | 2 +
lib/fdtdec.c | 2 +
6 files changed, 397 insertions(+), 30 deletions(-)
create mode 100644 doc/device-tree-bindings/misc/intel,baytrail-fsp.txt
diff --git a/arch/x86/cpu/baytrail/fsp_configs.c
b/arch/x86/cpu/baytrail/fsp_configs.c
index 86b6926..ba56ebb 100644
--- a/arch/x86/cpu/baytrail/fsp_configs.c
+++ b/arch/x86/cpu/baytrail/fsp_configs.c
@@ -1,14 +1,18 @@
/*
* Copyright (C) 2013, Intel Corporation
* Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ * Copyright (C) 2015, Kodak Alaris, Inc
*
* SPDX-License-Identifier:Intel
*/
#include common.h
+#include fdtdec.h
#include asm/arch/fsp/azalia.h
#include asm/fsp/fsp_support.h
+DECLARE_GLOBAL_DATA_PTR;
+
/* ALC262 Verb Table - 10EC0262 */
static const uint32_t verb_table_data13[] = {
/* Pin Complex (NID 0x11) */
@@ -116,41 +120,144 @@ const struct pch_azalia_config azalia_config = {
.reset_wait_timer_us = 300
};
+/**
+ * Override the FSP's UPD.
+ * If the device tree does not specify an integer setting, use the default
+ * provided in Intel's Baytrail_FSP_Gold4.tgz release FSP/BayleyBayFsp.bsf
file.
+ */
void update_fsp_upd(struct upd_region *fsp_upd)
{
struct memory_down_data *mem;
+ const void *blob = gd-fdt_blob;
+ int node;
- /*
-* Configure everything here to avoid the poor hard-pressed user
-* needing to run Intel's binary configuration tool. It may also allow
-* us to support the 1GB single core variant easily.
-*
-* TODO(s...@chromium.org): Move to device tree
-*/
- fsp_upd-mrc_init_tseg_size = 8;
- fsp_upd-mrc_init_mmio_size = 0x800;
- fsp_upd-emmc_boot_mode = 0xff;
- fsp_upd-enable_sdio = 1;
- fsp_upd-enable_sdcard = 1;
- fsp_upd-enable_hsuart0 = 1;
fsp_upd-azalia_config_ptr = (uint32_t)azalia_config;
- fsp_upd-enable_i2_c0 = 0;
- fsp_upd-enable_i2_c2 = 0;
- fsp_upd-enable_i2_c3 = 0;
- fsp_upd-enable_i2_c4 = 0;
- fsp_upd-enable_xhci = 0;
- fsp_upd-igd_render_standby = 1;
+
+ node = fdtdec_next_compatible(blob, 0, COMPAT_INTEL_BAYTRAIL_FSP);
+ if (node 0) {
+ debug(%s: Cannot find FSP node\n, __func__);
+ return;
+ }
+
+ fsp_upd-mrc_init_tseg_size = fdtdec_get_int(blob, node,
+fsp,mrc-init-tseg-size,
+0);
+ fsp_upd-mrc_init_mmio_size = fdtdec_get_int(blob, node,
+fsp,mrc-init-mmio-size,
+0x800);
+ fsp_upd-mrc_init_spd_addr1 = fdtdec_get_int(blob, node,
+fsp,mrc-init-spd-addr1,
+0xa0);
+ fsp_upd-mrc_init_spd_addr2 = fdtdec_get_int(blob, node,
+fsp,mrc-init-spd-addr2,
+0xa2);
+ fsp_upd-emmc_boot_mode = fdtdec_get_int(blob, node,
+fsp,emmc-boot-mode, 2);
+ fsp_upd-enable_sdio = fdtdec_get_bool(blob, node, fsp,enable-sdio);
+ fsp_upd-enable_sdcard = fdtdec_get_bool(blob, node,
+fsp,enable-sdcard);
+ fsp_upd-enable_hsuart0 = fdtdec_get_bool(blob, node,
[U-Boot] [PATCH 2/4] armv8: fsl-lsch3: Initiaze 4 MACs per QSGMII in dpmac_info
Every QSGMII SerDes Protocol usage 4 MACs.
So add/repeat QSGMII information for 4 MACs in dpmac_info strucuture.
Signed-off-by: King Chung l...@freescale.com kingchun...@freescale.com
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
arch/arm/cpu/armv8/fsl-lsch3/fsl_lsch3_serdes.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/fsl_lsch3_serdes.c
b/arch/arm/cpu/armv8/fsl-lsch3/fsl_lsch3_serdes.c
index 02ca126..ae08343 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/fsl_lsch3_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-lsch3/fsl_lsch3_serdes.c
@@ -90,7 +90,38 @@ void serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, u32
sd_prctl_shift,
else {
serdes_prtcl_map[lane_prtcl] = 1;
#ifdef CONFIG_FSL_MC_ENET
- wriop_init_dpmac(sd, lane + 1, (int)lane_prtcl);
+ switch (lane_prtcl) {
+ case QSGMII_A:
+ wriop_init_dpmac(sd, 5, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 6, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 7, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 8, (int)lane_prtcl);
+ break;
+ case QSGMII_B:
+ wriop_init_dpmac(sd, 1, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 2, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 3, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 4, (int)lane_prtcl);
+ break;
+ case QSGMII_C:
+ wriop_init_dpmac(sd, 13, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 14, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 15, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 16, (int)lane_prtcl);
+ break;
+ case QSGMII_D:
+ wriop_init_dpmac(sd, 9, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 10, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 11, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 12, (int)lane_prtcl);
+ break;
+ default:
+if (lane_prtcl = SGMII1
+ lane_prtcl = SGMII16)
+ wriop_init_dpmac(sd, lane + 1,
+(int)lane_prtcl);
+ break;
+ }
#endif
}
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] x86: baytrail: Configure FSP UPD from device tree
Hi Andrew, On Fri, Aug 7, 2015 at 8:11 PM, Andrew Bradford and...@bradfordembedded.com wrote: Hi Bin, On 08/07 08:23, Bin Meng wrote: Hi Andrew, On Fri, Aug 7, 2015 at 4:08 AM, Andrew Bradford and...@bradfordembedded.com wrote: From: Andrew Bradford andrew.bradf...@kodakalaris.com Allow for configuration of FSP UPD from the device tree which will override any settings which the FSP was built with itself. Modify the MinnowMax and BayleyBay boards to transfer sensible UPD settings from the Intel FSPv4 Gold release to the respective dts files, with the condition that the memory-down parameters for MinnowMax are also used. Thanks for updating BayleyBay dts as well :) You're welcome :) My custom board actually boots with the Bayley Bay configuration, once I change out the dts to use your D0 stepping microcode patch, so that was a good check for me. Signed-off-by: Andrew Bradford andrew.bradf...@kodakalaris.com --- Reviewed-by: Bin Meng bmeng...@gmail.com Tested-by: Bin Meng bmeng...@gmail.com But please see some comments/nits below. Would it be best if I fix your comments/nits and send a v4? Yep, please send a v4 to address these. Changes from v2: - Switch to using booleans in dts, where appropriate. - Add Bayley Bay dts modifications. - Clarify docs to show bool versus int properties. - Include enable-igt property from FSPv4. Changes from v1: - Use - rather than _ in dt property names. - Use Bay Trail for the formal name of the Intel product family. - Use an fsp, prefix for dt property names for clarity. - Fix minor code indentation issues. - Create a dt subnode for the memory-down-params. - Clarify documentation that dt overrides the FSP's config, so we don't use booleans. [snip] - /* -* Configure everything here to avoid the poor hard-pressed user -* needing to run Intel's binary configuration tool. It may also allow -* us to support the 1GB single core variant easily. -* -* TODO(s...@chromium.org): Move to device tree -*/ - fsp_upd-mrc_init_tseg_size = 8; - fsp_upd-mrc_init_mmio_size = 0x800; One general comment: I think we should replace these hardcoded numbers with meaningful macros (eg: 0x800 means MMIO uses 2GB space, that's why we see previous the pci does not work on a 4GB DIMM as FSP only maps 2GB RAM per this setting). See Intel's Baytrail_FSP_Gold4.tgz release FSP/BayleyBayFsp.bsf file, it has the details of how each magic number maps to what meaning. Will you do a follow-up patch for this? I can do that as well. I can do this. Thanks! For Quark, I see that there's both include/dt-bindings/mrc/quark.h (for the dts to use) and arch/x86/include/asm/arch-quark/mrc.h (for code to use). These two files seem to duplicate some of the same #defines. For the FSP on Bay Trail, would it be recommended to follow a similar pair of header files as are used for MRC on Quark or should there just be a single header file defining the FSP magic numbers? I am not sure. Maybe Simon can comment. Regarding the MMIO region, the other choices in the FSP are 1 GB, 1.5 GB, and 2 GB. Any of those choices will cause issues when the system has 4 GB of SDRAM, unless I'm mistaken. Although I'm fairly sure we have some u-boot things hard coded to 0x8000 for the RAM top in 32 bit mode, so changing that FSP configuration may cause issues... Sorry but I did not test the MMIO region with 1G/1.5G configuration. When I was checking the bsf file for the magic number 0x800, it occurred to me that issue you previously met :) [snip] Thanks for the review! :) You are welcome. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm/ls102xa:add hwconfig setting to support disable unused devices.
DEVDISRn registers provides a mechanism for gating clocks of IP blocks
that are not used. Here we implement hwconfig option to allow users
to disable unused peripherals on the board.
For ex. If eSDHC/qDMA/eDMA are unused and with disabled status in dts,
User can also enable CONFIG_DEVICE_DISABLE and set devdis:esdhc,qdma,edma
in hwconfig, thus ESDHC controller eDMA/qDMA will be clock gated to
save more power.
Signed-off-by: Zhuoyu Zhang zhuoyu.zh...@freescale.com
---
arch/arm/include/asm/arch-ls102xa/ls102xa_devdis.h | 52 ++
board/freescale/ls1021aqds/ls1021aqds.c| 5 +++
board/freescale/ls1021atwr/ls1021atwr.c| 5 +++
drivers/misc/Makefile | 1 +
drivers/misc/fsl_devdis.c | 29
include/configs/ls1021aqds.h | 4 +-
include/configs/ls1021atwr.h | 4 +-
include/fsl_devdis.h | 18
8 files changed, 116 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/include/asm/arch-ls102xa/ls102xa_devdis.h
create mode 100644 drivers/misc/fsl_devdis.c
create mode 100644 include/fsl_devdis.h
diff --git a/arch/arm/include/asm/arch-ls102xa/ls102xa_devdis.h
b/arch/arm/include/asm/arch-ls102xa/ls102xa_devdis.h
new file mode 100644
index 000..3e9e9ea
--- /dev/null
+++ b/arch/arm/include/asm/arch-ls102xa/ls102xa_devdis.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __FSL_LS102XA_DEVDIS_H_
+#define __FSL_LS102XA_DEVDIS_H_
+
+#include fsl_devdis.h
+
+const struct devdis_table devdis_tbl[] = {
+ { pbl, 0x0, 0x8000 }, /* PBL */
+ { esdhc, 0x0, 0x2000 }, /* eSDHC*/
+ { qdma, 0x0, 0x80 }, /* qDMA */
+ { edma, 0x0, 0x40 }, /* eDMA */
+ { usb3, 0x0, 0x84000 }, /* USB3.0 controller and PHY*/
+ { usb2, 0x0, 0x4 }, /* USB2.0 controller*/
+ { sata, 0x0, 0x8000 },/* SATA */
+ { sec, 0x0, 0x200 }, /* SEC */
+ { dcu, 0x0, 0x2 },/* Display controller Unit */
+ { qe, 0x0, 0x1 }, /* QUICC Engine */
+ { etsec1, 0x1, 0x8000 }, /* eTSEC1 controller*/
+ { etesc2, 0x1, 0x4000 }, /* eTSEC2 controller*/
+ { etsec3, 0x1, 0x2000 }, /* eTSEC3 controller*/
+ { pex1, 0x2, 0x8000 },/* PCIE controller 1*/
+ { pex2, 0x2, 0x4000 },/* PCIE controller 2*/
+ { duart1, 0x3, 0x2000 }, /* DUART1 */
+ { duart2, 0x3, 0x1000 }, /* DUART2 */
+ { qspi, 0x3, 0x800 }, /* QSPI */
+ { ddr, 0x4, 0x8000 }, /* DDR */
+ { ocram1, 0x4, 0x800 }, /* OCRAM1 */
+ { ifc, 0x4, 0x80 }, /* IFC */
+ { gpio, 0x4, 0x40 }, /* GPIO */
+ { dbg, 0x4, 0x20 }, /* DBG */
+ { can1, 0x4, 0x8 }, /* FlexCAN1 */
+ { can2_4, 0x4, 0x4 }, /* FlexCAN2_3_4 */
+ { ftm2_8, 0x4, 0x2 }, /* FlexTimer2_3_4_5_6_7_8 */
+ { secmon, 0x4, 0x4000 }, /* Security Monitor */
+ { wdog1_2, 0x4, 0x400 }, /* WatchDog1_2 */
+ { i2c2_3, 0x4, 0x200 }, /* I2C2_3 */
+ { sai1_4, 0x4, 0x100 }, /* SAI1_2_3_4 */
+ { lpuart2_6, 0x4, 0x80 }, /* LPUART2_3_4_5_6 */
+ { dspi1_2, 0x4, 0x40 }, /* DSPI1_2 */
+ { asrc, 0x4, 0x20 }, /* ASRC */
+ { spdif, 0x4, 0x10 }, /* SPDIF*/
+ { i2c1, 0x4, 0x4 }, /* I2C1 */
+ { lpuart1, 0x4, 0x2 },/* LPUART1 */
+ { ftm1, 0x4, 0x1 }, /* FlexTimer1 */
+};
+
+#endif
diff --git a/board/freescale/ls1021aqds/ls1021aqds.c
b/board/freescale/ls1021aqds/ls1021aqds.c
index d6ef6ba..b7049f7 100644
--- a/board/freescale/ls1021aqds/ls1021aqds.c
+++ b/board/freescale/ls1021aqds/ls1021aqds.c
@@ -12,12 +12,14 @@
#include asm/arch/clock.h
#include asm/arch/fsl_serdes.h
#include asm/arch/ls102xa_stream_id.h
+#include asm/arch/ls102xa_devdis.h
#include hwconfig.h
#include mmc.h
#include fsl_esdhc.h
#include fsl_ifc.h
#include fsl_sec.h
#include spl.h
+#include fsl_devdis.h
#include ../common/sleep.h
#include ../common/qixis.h
@@ -530,6 +532,9 @@ int misc_init_r(void)
else if (hwconfig(sdhc))
config_board_mux(MUX_TYPE_SDHC);
+#ifdef CONFIG_DEVICE_DISABLE
+ device_disable(devdis_tbl, ARRAY_SIZE(devdis_tbl));
+#endif
#ifdef CONFIG_FSL_CAAM
return sec_init();
#endif
diff --git a/board/freescale/ls1021atwr/ls1021atwr.c
b/board/freescale/ls1021atwr/ls1021atwr.c
index b7458a9..ed96cae 100644
--- a/board/freescale/ls1021atwr/ls1021atwr.c
+++ b/board/freescale/ls1021atwr/ls1021atwr.c
@@ -12,6
[U-Boot] [PATCH 4/4] armv8: ls2085qds: Add support of X-QSGMII-16PORT riser card
The X-QSGMII-16PORT is a 4xQSGMII/8xSGMII riser card with eighth SerDes
interfaces implemented in PCIe form factor board.
It supports followings
- Card can operate with up to 4 QSGMII lane simultaneously
- Card can operate with up to 8 SGMII lane simultaneously
Add support of X-QSGMII-16PORT riser card.
This patch also take care of back-ward compatiblity with old SGMII rise cards
used on LS2085QDS Platform.
Signed-off-by: King Chung l...@freescale.com kingchun...@freescale.com
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
board/freescale/ls2085aqds/README | 81 +++
board/freescale/ls2085aqds/eth.c | 466 +-
include/configs/ls2085aqds.h | 17 ++
3 files changed, 553 insertions(+), 11 deletions(-)
diff --git a/board/freescale/ls2085aqds/README
b/board/freescale/ls2085aqds/README
index 11b2e79..e4a6f69 100644
--- a/board/freescale/ls2085aqds/README
+++ b/board/freescale/ls2085aqds/README
@@ -146,3 +146,84 @@ below:
earlycon=uart8250,mmio,0x21c0600,115200 default_hugepagesz=2m hugepagesz=2m
hugepages=16 mem=2048M'
+
+X-QSGMII-16PORT riser card
+
+The X-QSGMII-16PORT is a 4xQSGMII/8xSGMII riser card with eighth SerDes
+interfaces implemented in PCIe form factor board.
+It supports followings
+ - Card can operate with up to 4 QSGMII lane simultaneously
+ - Card can operate with up to 8 SGMII lane simultaneously
+
+Supported card configuration
+ - CSEL : ON ON ON ON
+ - MSEL1 : ON ON ON ON OFF OFF OFF OFF
+ - MSEL2 : OFF OFF OFF OFF ON ON ON ON
+
+To enable this card: modify hwconfig to add xqsgmii variable.
+
+Supported PHY addresses during SGMII:
+#define XQSGMII_CARD_PHY1_PORT0_ADDR 0x0
+#define XQSGMII_CARD_PHY1_PORT2_ADDR 0x2
+#define XQSGMII_CARD_PHY2_PORT0_ADDR 0x4
+#define XQSGMII_CARD_PHY2_PORT2_ADDR 0x6
+#define XQSGMII_CARD_PHY3_PORT0_ADDR 0x8
+#define XQSGMII_CARD_PHY3_PORT2_ADDR 0xa
+#define XQSGMII_CARD_PHY4_PORT0_ADDR 0xc
+#define XQSGMII_CARD_PHY4_PORT2_ADDR 0xe
+
+Mapping DPMACx to PHY during QSGMII
+DPMAC1 - PHY1-P0
+DPMAC2 - PHY2-P0
+DPMAC3 - PHY3-P0
+DPMAC4 - PHY4-P0
+DPMAC5 - PHY3-P2
+DPMAC6 - PHY1-P2
+DPMAC7 - PHY4-P1
+DPMAC8 - PHY2-P2
+DPMAC9 - PHY1-P0
+DPMAC10 - PHY2-P0
+DPMAC11 - PHY3-P0
+DPMAC12 - PHY4-P0
+DPMAC13 - PHY3-P2
+DPMAC14 - PHY1-P2
+DPMAC15 - PHY4-P1
+DPMAC16 - PHY2-P2
+
+
+Supported PHY address during QSGMII
+#define XQSGMII_CARD_PHY1_PORT0_ADDR 0x0
+#define XQSGMII_CARD_PHY1_PORT1_ADDR 0x1
+#define XQSGMII_CARD_PHY1_PORT2_ADDR 0x2
+#define XQSGMII_CARD_PHY1_PORT3_ADDR 0x3
+#define XQSGMII_CARD_PHY2_PORT0_ADDR 0x4
+#define XQSGMII_CARD_PHY2_PORT1_ADDR 0x5
+#define XQSGMII_CARD_PHY2_PORT2_ADDR 0x6
+#define XQSGMII_CARD_PHY2_PORT3_ADDR 0x7
+#define XQSGMII_CARD_PHY3_PORT0_ADDR 0x8
+#define XQSGMII_CARD_PHY3_PORT1_ADDR 0x9
+#define XQSGMII_CARD_PHY3_PORT2_ADDR 0xa
+#define XQSGMII_CARD_PHY3_PORT3_ADDR 0xb
+#define XQSGMII_CARD_PHY4_PORT0_ADDR 0xc
+#define XQSGMII_CARD_PHY4_PORT1_ADDR 0xd
+#define XQSGMII_CARD_PHY4_PORT2_ADDR 0xe
+#define XQSGMII_CARD_PHY4_PORT3_ADDR 0xf
+
+Mapping DPMACx to PHY during QSGMII
+DPMAC1 - PHY1-P3
+DPMAC2 - PHY1-P2
+DPMAC3 - PHY1-P1
+DPMAC4 - PHY1-P0
+DPMAC5 - PHY2-P3
+DPMAC6 - PHY2-P2
+DPMAC7 - PHY2-P1
+DPMAC8 - PHY2-P0
+DPMAC9 - PHY3-P0
+DPMAC10 - PHY3-P1
+DPMAC11 - PHY3-P2
+DPMAC12 - PHY3-P3
+DPMAC13 - PHY4-P0
+DPMAC14 - PHY4-P1
+DPMAC15 - PHY4-P2
+DPMAC16 - PHY4-P3
+
diff --git a/board/freescale/ls2085aqds/eth.c b/board/freescale/ls2085aqds/eth.c
index 1f8a31f..007b433 100644
--- a/board/freescale/ls2085aqds/eth.c
+++ b/board/freescale/ls2085aqds/eth.c
@@ -9,9 +9,12 @@
#include asm/io.h
#include asm/arch/fsl_serdes.h
#include asm/arch-fsl-lsch3/immap_lsch3.h
+#include hwconfig.h
#include fsl_mdio.h
#include malloc.h
#include fm_eth.h
+#include i2c.h
+#include miiphy.h
#include fsl-mc/ldpaa_wriop.h
#include ../common/qixis.h
@@ -30,6 +33,10 @@
* maps to something other than a board slot.
*/
+static u8 lane_to_slot_fsm1[] = {
+ 0, 0, 0, 0, 0, 0, 0, 0
+};
+
static u8 lane_to_slot_fsm2[] = {
0, 0, 0, 0, 0, 0, 0, 0
};
@@ -37,7 +44,19 @@ static u8 lane_to_slot_fsm2[] = {
/* On the Vitesse VSC8234XHG SGMII riser card there are 4 SGMII PHYs
* housed.
*/
-static int riser_phy_addr[] = {
+
+static int xqsgii_riser_phy_addr[] = {
+ XQSGMII_CARD_PHY1_PORT0_ADDR,
+ XQSGMII_CARD_PHY2_PORT0_ADDR,
+ XQSGMII_CARD_PHY3_PORT0_ADDR,
+ XQSGMII_CARD_PHY4_PORT0_ADDR,
+ XQSGMII_CARD_PHY3_PORT2_ADDR,
+ XQSGMII_CARD_PHY1_PORT2_ADDR,
+ XQSGMII_CARD_PHY4_PORT2_ADDR,
+ XQSGMII_CARD_PHY2_PORT2_ADDR,
+};
+
+static int sgmii_riser_phy_addr[] = {
SGMII_CARD_PORT1_PHY_ADDR,
SGMII_CARD_PORT2_PHY_ADDR,
SGMII_CARD_PORT3_PHY_ADDR,
@@ -70,6 +89,236 @@ struct ls2085a_qds_mdio {
struct mii_dev *realbus;
};
+static void sgmii_configure_repeater(int serdes_port)
+{
+ struct mii_dev *bus;
+ uint8_t a = 0xf;
+ int i, j, ret;
+
[U-Boot] [PATCH 3/4] net: phy/vitesse: Add support for VSC8584 phy
Add support of VSC8584 phy placed on new QSGMII/SGMII ethernet riser cards
used on LS2085QDS platforms.
Signed-off-by: King Chung l...@freescale.com kingchun...@freescale.com
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
drivers/net/phy/vitesse.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index 20a6746..941d076 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -347,6 +347,16 @@ static struct phy_driver VSC8514_driver = {
.shutdown = genphy_shutdown,
};
+static struct phy_driver VSC8584_driver = {
+ .name = Vitesse VSC8584,
+ .uid = 0x707c0,
+ .mask = 0x0,
+ .features = PHY_GBIT_FEATURES,
+ .config = vsc8574_config,
+ .startup = vitesse_startup,
+ .shutdown = genphy_shutdown,
+};
+
static struct phy_driver VSC8601_driver = {
.name = Vitesse VSC8601,
.uid = 0x70420,
@@ -417,6 +427,7 @@ int phy_vitesse_init(void)
phy_register(VSC8211_driver);
phy_register(VSC8221_driver);
phy_register(VSC8574_driver);
+ phy_register(VSC8584_driver);
phy_register(VSC8514_driver);
phy_register(VSC8662_driver);
phy_register(VSC8664_driver);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] armv8: fsl-lsch3: Initiaze 4 MACs per QSGMII in dpmac_info
Every QSGMII SerDes Protocol usage 4 MACs.
So add/repeat QSGMII information for 4 MACs in dpmac_info strucuture.
Signed-off-by: King Chung l...@freescale.com kingchun...@freescale.com
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
arch/arm/cpu/armv8/fsl-lsch3/fsl_lsch3_serdes.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/fsl_lsch3_serdes.c
b/arch/arm/cpu/armv8/fsl-lsch3/fsl_lsch3_serdes.c
index 02ca126..ae08343 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/fsl_lsch3_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-lsch3/fsl_lsch3_serdes.c
@@ -90,7 +90,38 @@ void serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, u32
sd_prctl_shift,
else {
serdes_prtcl_map[lane_prtcl] = 1;
#ifdef CONFIG_FSL_MC_ENET
- wriop_init_dpmac(sd, lane + 1, (int)lane_prtcl);
+ switch (lane_prtcl) {
+ case QSGMII_A:
+ wriop_init_dpmac(sd, 5, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 6, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 7, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 8, (int)lane_prtcl);
+ break;
+ case QSGMII_B:
+ wriop_init_dpmac(sd, 1, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 2, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 3, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 4, (int)lane_prtcl);
+ break;
+ case QSGMII_C:
+ wriop_init_dpmac(sd, 13, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 14, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 15, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 16, (int)lane_prtcl);
+ break;
+ case QSGMII_D:
+ wriop_init_dpmac(sd, 9, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 10, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 11, (int)lane_prtcl);
+ wriop_init_dpmac(sd, 12, (int)lane_prtcl);
+ break;
+ default:
+if (lane_prtcl = SGMII1
+ lane_prtcl = SGMII16)
+ wriop_init_dpmac(sd, lane + 1,
+(int)lane_prtcl);
+ break;
+ }
#endif
}
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] imx: mx6 move TARGET_xx Kconfig option to mx6 specific Kconfig file
Move TARGET_xx Kconfig option based on mx6 to arch/arm/cpu/armv7/mx6/Kconfig. Add enable CONFIG_ARCH_MX6 for boards based on mx6. Then we can choose target boards using make ARCH=arm menuconfig with ARCH_MX6 defined. If using original way, we have no chance to enable ARCH_MX6 when make menuconfig. Even define CONFIG_ARCH_MX6=y in xx_defconfig, kconfig will complains arch/../configs/platinum_titanium_defconfig:3: warning: override: TARGET_PLATINUM_TITANIUM changes choice state Signed-off-by: Peng Fan peng@freescale.com Cc: Stefano Babic sba...@denx.de Cc: Heiko Schocher h...@denx.de Cc: Tim Harvey thar...@gateworks.com Cc: Eric Bénard e...@eukrea.com Cc: Fabio Estevam fabio.este...@freescale.com Cc: Eric Nelson eric.nel...@boundarydevices.com Cc: Marek Vasut ma...@denx.de Cc: Christian Gmeiner christian.gmei...@gmail.com Cc: Stefan Roese s...@denx.de Cc: Soeren Moch sm...@web.de Cc: Otavio Salvador ota...@ossystems.com.br Acked-by: Stefano Babic sba...@denx.de Acked-by: Soeren Moch sm...@web.de --- Changes v2: Sort the TARGET option and included files from 'source' alphabetically, using sed -ne '/TARGET/'p arch/arm/cpu/armv7/mx6/Kconfig | sort. Included files are sorted using same way using 'source' to replace 'TARGET' in command. Discard Support Add Acked-by from Stefano and Soeren. Pass building using ./MAKEALL -s mx6 arch/arm/Kconfig| 128 -- arch/arm/cpu/armv7/mx6/Kconfig | 132 +++- configs/aristainetos2_defconfig | 1 + configs/aristainetos_defconfig | 1 + configs/cgtqmx6qeval_defconfig | 1 + configs/gwventana_defconfig | 1 + configs/marsboard_defconfig | 1 + configs/mx6cuboxi_defconfig | 1 + configs/mx6dlarm2_defconfig | 1 + configs/mx6dlarm2_lpddr2_defconfig | 1 + configs/mx6dlsabreauto_defconfig| 1 + configs/mx6dlsabresd_defconfig | 1 + configs/mx6qarm2_defconfig | 1 + configs/mx6qarm2_lpddr2_defconfig | 1 + configs/mx6qpsabreauto_defconfig| 1 + configs/mx6qsabreauto_defconfig | 1 + configs/mx6qsabrelite_defconfig | 1 + configs/mx6qsabresd_defconfig | 1 + configs/mx6sabresd_spl_defconfig| 1 + configs/mx6slevk_defconfig | 1 + configs/mx6slevk_spinor_defconfig | 1 + configs/mx6sxsabresd_defconfig | 1 + configs/mx6sxsabresd_spl_defconfig | 1 + configs/mx6ul_14x14_evk_defconfig | 1 + configs/nitrogen6dl2g_defconfig | 1 + configs/nitrogen6dl_defconfig | 1 + configs/nitrogen6q2g_defconfig | 1 + configs/nitrogen6q_defconfig| 1 + configs/nitrogen6s1g_defconfig | 1 + configs/nitrogen6s_defconfig| 1 + configs/novena_defconfig| 1 + configs/ot1200_defconfig| 1 + configs/ot1200_spl_defconfig| 1 + configs/platinum_picon_defconfig| 1 + configs/platinum_titanium_defconfig | 1 + configs/riotboard_defconfig | 1 + configs/tbs2910_defconfig | 1 + configs/udoo_defconfig | 1 + configs/wandboard_defconfig | 1 + configs/warp_defconfig | 1 + 40 files changed, 168 insertions(+), 130 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 5d54604..d28b50b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -508,113 +508,6 @@ config TARGET_VISION2 bool Support vision2 select CPU_V7 -config TARGET_UDOO - bool Support udoo - select CPU_V7 - select SUPPORT_SPL - -config TARGET_WANDBOARD - bool Support wandboard - select CPU_V7 - select SUPPORT_SPL - -config TARGET_WARP - bool Support WaRP - select CPU_V7 - -config TARGET_TITANIUM - bool Support titanium - select CPU_V7 - -config TARGET_NITROGEN6X - bool Support nitrogen6x - select CPU_V7 - -config TARGET_CGTQMX6EVAL - bool Support cgtqmx6eval - select CPU_V7 - -config TARGET_EMBESTMX6BOARDS - bool Support embestmx6boards - select CPU_V7 - -config TARGET_ARISTAINETOS - bool Support aristainetos - select CPU_V7 - -config TARGET_ARISTAINETOS2 - bool Support aristainetos2 - select CPU_V7 - -config TARGET_MX6QARM2 - bool Support mx6qarm2 - select CPU_V7 - -config TARGET_MX6QSABREAUTO - bool Support mx6qsabreauto - select CPU_V7 - select DM - select DM_THERMAL - -config TARGET_MX6SABRESD - bool Support mx6sabresd - select CPU_V7 - select SUPPORT_SPL - select DM - select DM_THERMAL - -config TARGET_MX6CUBOXI - bool Support Solid-run mx6 boards - select CPU_V7 - select SUPPORT_SPL - -config TARGET_MX6SLEVK - bool Support mx6slevk - select CPU_V7 - -config TARGET_MX6SXSABRESD - bool Support mx6sxsabresd - select CPU_V7 - select SUPPORT_SPL - select DM - select
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford and...@bradfordembedded.com wrote: From: Andrew Bradford andrew.bradf...@kodakalaris.com Allow for configuration of FSP UPD from the device tree which will override any settings which the FSP was built with itself. Modify the MinnowMax and BayleyBay boards to transfer sensible UPD settings from the Intel FSPv4 Gold release to the respective dts files, with the condition that the memory-down parameters for MinnowMax are also used. Signed-off-by: Andrew Bradford andrew.bradf...@kodakalaris.com --- Reviewed-by: Bin Meng bmeng...@gmail.com Tested-by: Bin Meng bmeng...@gmail.com [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot FIT image support
On 08/07/2015 03:47 PM, Simon Glass wrote: Hi York, On 7 August 2015 at 14:48, York Sun york...@freescale.com wrote: Simon, I was doing an experiment to put the load address and entry address of Linux to higher than 32-bit address. I found it is broken to process more than 32-bit addresses. When I attempted to fix it, I was troubled by those code used for both host and target, like common/image-fit.c. For example, to process 64-bit address, the function int fit_image_get_load(const void *fit, int noffset, ulong *load) should be converted to int fit_image_get_load(const void *fit, int noffset, uint64_t *load) ulong is 64-bit for 64-bit target such as ARMv8, but it can be 32-bit on host. If I use uint64_t, all related code in bootm and others need to change. Before I go too far, I'd like to check if anyone has tried to enable this in FIT image. #address-cells = 2; I can try to use uint64_t in place of ulong for all related code if that's right. That will be a lot of change. Perhaps I misunderstand something, but I think ulong should be OK on the host. I just needs to hold a machine address. On a 32-bit host this cannot be 64-bit. Can you explain the problem a bit more? I have not need #address-cells in a FIT. It would be better to use ulong for addresses in U-Boot I think. It is safe and efficient on both 32- and 64-bit machines. Simon, Considering this situation, building FIT image on an ubuntu 12.04 32-bit host, for ARMv8 target. I believe ulong is OK on 64-bit target. But it is not for the host mkimage. To proper deal with address cell = 2, the function fit_image_get_load() and fit_image_get_entry() need to make 64-bit address from FIT image. mkimage runs on 32-bit host doesn't take ulong as 64-bit, does it? So I can generate a FIT image with the address cell and load/entry address I need, but I cannot display it correctly with mkimage. I think I can use the image on 64-bit target after fixing some parsing code as I mentioned. The background for this experiment is I am trying to shift DDR to a continuous space. For ARMv8, DDR can have three regions, with only 2GB under 32-bit address space. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
