Re: [U-Boot] Set up stdio earlier when using driver model --- breaks sbc8548 booting.
[Re: Set up stdio earlier when using driver model --- breaks sbc8548 booting.] On 23/03/2015 (Mon 17:01) Simon Glass wrote: Hi Paul, On 16 March 2015 at 19:41, Paul Gortmaker paul.gortma...@windriver.com wrote: Testing latest master on sbc8548 (ppc e500v2 single core) and it hangs at the Net: line; a working boot shows the full Net: line as: - PCI: Host, 64 bit, 66 MHz, sync, arbiter 00:01.0 - 8086:1026 - Network controller PCI1: Bus 00 - 00 PCIe1: disabled In:serial Out: serial Err: serial Net: eTSEC0 [PRIME], eTSEC1 Hit any key to stop autoboot: 0 - So we never see the eTSEC0 or any other output after Net: . My 1st bisect led to my own commit: - commit 2bf4207b8a452476a591d733c6b8f09b337acc08 Author: Paul Gortmaker paul.gortma...@windriver.com AuthorDate: Thu Aug 14 10:42:52 2014 -0400 Commit: York Sun york...@freescale.com CommitDate: Fri Nov 14 11:12:13 2014 -0800 sbc8548: enable and test CONFIG_SYS_GENERIC_BOARD - ...but that is a red herring, since I'd tested it on master at Aug14, but it wasn't committed to master until three months later. So the breakage is in that 3 month window. Since I recorded the original baseline I'd tested on, I restarted the bisect with that baseline as good and the above 2bf42 as bad, and just added the oneline change for CONFIG_SYS_GENERIC_BOARD manually at each bisect point. Doing that led me unequivocally to: - commit 294b91a5817147d4b7f47be2ac69bac2a1f26491 Author: Simon Glass s...@chromium.org Date: Wed Sep 3 17:37:00 2014 -0600 Set up stdio earlier when using driver model - Based on a part of that commit log, it says Should there be any problems with this approach they can be dealt with as boards are converted over to use driver model for serial. So maybe the sbc8548 is just missing some additional conversion? Oddly it seems it is dying at network device probing and not in/out/err that use serial as stdio. Any hints on what to look at next to solve this would be appreciated. I had a look at this link: http://www.denx.de/wiki/U-Boot/DriverModel ..but wasn't sure where to go from there, since I'm still unsure what the real root of the breakage is. Yes it is certainly odd. The driver init for serial is over by then, so I don't see why it would hang. Also the code has changed further since that commit. So there is no board wide conversion to some new API needed from this change, i.e. things should have stayed working as is? My suggestion would be to dig into the network init and see if you figure out where it hangs. Do you have an ICE? Ugh. I could probably find an ICE and the associated software, but I've never really liked using the things, which is why I bisected my way here to identify the commit that caused the regression, hoping that once it was identified, that the author of the changeset would know what happened... :-( P. -- Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] dm: ls1021a: Bring in ls1021a dts files from linux kernel
From: haikun haikun.w...@freescale.com
Bring in required device tree files for ls1021a from Linux.
These are initially unchanged and have a number of pieces not needed by U-Boot.
Signed-off-by: Haikun Wang haikun.w...@freescale.com
---
arch/arm/dts/Makefile| 3 +
arch/arm/dts/ls1021a-qds.dts | 201 +++
arch/arm/dts/ls1021a-twr.dts | 88 ++
arch/arm/dts/ls1021a.dtsi| 370 +++
4 files changed, 662 insertions(+)
create mode 100644 arch/arm/dts/ls1021a-qds.dts
create mode 100644 arch/arm/dts/ls1021a-twr.dts
create mode 100644 arch/arm/dts/ls1021a.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cbe5b86..67b821a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -54,6 +54,9 @@ dtb-$(CONFIG_SOCFPGA) += \
socfpga_cyclone5_socdk.dtb \
socfpga_cyclone5_socrates.dtb
+dtb-$(CONFIG_TARGET_LS1021AQDS) += ls1021a-qds.dtb
+dtb-$(CONFIG_TARGET_LS1021ATWR) += ls1021a-twr.dtb
+
targets += $(dtb-y)
DTC_FLAGS += -R 4 -p 0x1000
diff --git a/arch/arm/dts/ls1021a-qds.dts b/arch/arm/dts/ls1021a-qds.dts
new file mode 100644
index 000..c89f85e
--- /dev/null
+++ b/arch/arm/dts/ls1021a-qds.dts
@@ -0,0 +1,201 @@
+/*
+ * Freescale ls1021a QDS board device tree source
+ *
+ * Copyright 2013-2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+#include ls1021a.dtsi
+
+/ {
+ model = LS1021A QDS Board;
+
+ aliases {
+ enet0_rgmii_phy = rgmii_phy1;
+ enet1_rgmii_phy = rgmii_phy2;
+ enet2_rgmii_phy = rgmii_phy3;
+ enet0_sgmii_phy = sgmii_phy1c;
+ enet1_sgmii_phy = sgmii_phy1d;
+ };
+};
+
+dspi0 {
+ bus-num = 0;
+ status = okay;
+
+ dspiflash: at45db021d@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = atmel,at45db021d, atmel,at45,
atmel,dataflash;
+ spi-max-frequency = 1600;
+ spi-cpol;
+ spi-cpha;
+ reg = 0;
+ };
+};
+
+i2c0 {
+ status = okay;
+
+ pca9547: mux@77 {
+ reg = 0x77;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ i2c@0 {
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x0;
+
+ ds3232: rtc@68 {
+ compatible = dallas,ds3232;
+ reg = 0x68;
+ interrupts = GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH;
+ };
+ };
+
+ i2c@2 {
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x2;
+
+ ina220@40 {
+ compatible = ti,ina220;
+ reg = 0x40;
+ shunt-resistor = 1000;
+ };
+
+ ina220@41 {
+ compatible = ti,ina220;
+ reg = 0x41;
+ shunt-resistor = 1000;
+ };
+ };
+
+ i2c@3 {
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x3;
+
+ eeprom@56 {
+ compatible = atmel,24c512;
+ reg = 0x56;
+ };
+
+ eeprom@57 {
+ compatible = atmel,24c512;
+ reg = 0x57;
+ };
+
+ adt7461a@4c {
+ compatible = adi,adt7461a;
+ reg = 0x4c;
+ };
+ };
+ };
+};
+
+ifc {
+ #address-cells = 2;
+ #size-cells = 1;
+ /* NOR, NAND Flashes and FPGA on board */
+ ranges = 0x0 0x0 0x0 0x6000 0x0800
+ 0x2 0x0 0x0 0x7e80 0x0001
+ 0x3 0x0 0x0 0x7fb0 0x0100;
+ status = okay;
+
+ nor@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x800;
+ bank-width = 2;
+ device-width = 1;
+ };
+
+ fpga: board-control@3,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = simple-bus;
+ reg = 0x3 0x0 0x100;
+ bank-width = 1;
+ device-width = 1;
+ ranges = 0 3 0 0x100;
+
+ mdio-mux-emi1 {
+ compatible = mdio-mux-mmioreg;
+
Re: [U-Boot] arm: mx5: Add support for USB armory board
Hi Vagrant,
On Sat, Mar 21, 2015 at 08:12:28AM -0700, Vagrant Cascadian wrote:
On 2015-03-19, Andrej Rosano wrote:
On Thu, Mar 19, 2015 at 09:55:26AM -0700, Vagrant Cascadian wrote:
On 2015-02-24, and...@inversepath.com wrote:
Add support for Inverse Path USB armory board, an open source
flash-drive sized computer based on Freescale i.MX53 SoC.
...
Would you consider patches that include config_distro_defaults.h and
config_distro_bootcmd.h, documented in doc/README.distro? It may require
adding several variables such as fdt_addr_r, fdtfile, ramdisk_addr_r,
ramdiskfile, kernel_addr_r, bootfile, pxe_addr_r and scriptaddr,
documented in README and doc/README.distro. I'd be happy to work on
patches.
...
Sure, it would be nice to have this included in the patch.
I didn't know about this, I will take a look as well. Let me know if
you need any help from my side.
Ok, here's a quick patch on top of your existing patch. It compiles, but
I haven't tested that it boots (waiting on some header pins to hook up
the serial console).
I tried to preserve default behavior, the only difference is that it
will first check for extlinux.conf and boot.scr before running the
default boot action, and has a 2 second rather than 1 second bootdelay.
Many of the things defined in config_distro_defaults.h were redundant.
Not sure if CONFIG_LOADADDR needs to be different from
kernel_addr_r/scriptaddr/pxefile_addr_r, if they can all be the same,
then they could be defined with CONFIG_LOADADDR. Hopefully
ramdisk_addr_r is at a reasonable location so it won't be clobbered by
the fdt or kernel being loaded to a lower address. It may require
removing the default bootargs to work with boot scripts.
Tested and it works as expected. I have just submitted an updated patch (v3).
Thanks
Andrej
diff --git a/include/configs/usbarmory.h b/include/configs/usbarmory.h
index e00ec7b..7e4cc68 100644
--- a/include/configs/usbarmory.h
+++ b/include/configs/usbarmory.h
@@ -22,12 +22,10 @@
#include asm/arch/imx-regs.h
#include config_cmd_default.h
+#include config_distro_defaults.h
/* U-Boot commands */
-#define CONFIG_CMD_BOOTZ
-#define CONFIG_CMD_FAT
#define CONFIG_CMD_MEMTEST
-#define CONFIG_CMD_EXT2
#undef CONFIG_CMD_IMLS
/* U-Boot environment */
@@ -39,14 +37,10 @@
#define CONFIG_SYS_MMC_ENV_DEV 0
/* U-Boot general configurations */
-#define CONFIG_SYS_LONGHELP
-#define CONFIG_SYS_HUSH_PARSER
-#define CONFIG_AUTO_COMPLETE
#define CONFIG_SYS_CBSIZE512
#define CONFIG_SYS_PBSIZE(CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT)
+ 16)
#define CONFIG_SYS_MAXARGS 16
#define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE
-#define CONFIG_CMDLINE_EDITING
/* UART */
#define CONFIG_MXC_UART
@@ -61,7 +55,6 @@
#define CONFIG_SYS_FSL_ESDHC_NUM 2
#define CONFIG_MMC
#define CONFIG_GENERIC_MMC
-#define CONFIG_DOS_PARTITION
/* USB */
#define CONFIG_CMD_USB
@@ -82,7 +75,6 @@
#define CONFIG_FSL_IIM
/* Linux boot */
-#define CONFIG_BOOTDELAY 1
#define CONFIG_LOADADDR 0x7200
#define CONFIG_SYS_TEXT_BASE 0x7780
#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR
@@ -90,8 +82,28 @@
#define CONFIG_BOOTARGS \
console=ttymxc0,115200 root=/dev/mmcblk0p1 rootwait rw
#define CONFIG_BOOTCOMMAND \
- ext2load mmc 0:1 0x7080 /boot/uImage; ext2load mmc 0:1 \
- 0x7100 /boot/imx53-usbarmory.dtb; bootm 0x7080 - 0x7100
+ run distro_bootcmd; \
+ ext2load mmc 0:1 ${kernel_addr_r} /boot/uImage; \
+ ext2load mmc 0:1 ${fdt_addr_r} /boot/${fdtfile}; \
+ bootm ${kernel_addr_r} - ${fdt_addr_r}
+
+#define BOOT_TARGET_DEVICES(func) \
+ func(MMC, mmc, 0)
+
+#include config_distro_bootcmd.h
+
+#define MEM_LAYOUT_ENV_SETTINGS \
+ kernel_addr_r=0x7080\0 \
+ fdt_addr_r=0x7100\0 \
+ scriptaddr=0x7080\0 \
+ pxefile_addr_r=0x7080\0 \
+ ramdisk_addr_r=0x7300\0
+
+#define CONFIG_EXTRA_ENV_SETTINGS\
+ MEM_LAYOUT_ENV_SETTINGS \
+ fdtfile=imx53-usbarmory.dtb\0 \
+ console=ttymxc0,115200\0 \
+ BOOTENV
/* Physical Memory Map */
#define CONFIG_NR_DRAM_BANKS 1
live well,
vagrant
--
Andrej Rosano Inverse Path Srl
and...@inversepath.com http://www.inversepath.com
0x01939B215BB8 574E 68E8 D841 E18F D5E9 CEAD E0CF 0193 9B21
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] sunxi A10s HDMI output problem
Hello, I tried to connect the A10s olinuxino to a screen with dual DVI input and while the display mostly works I get red console background instead of black. Sending get-edid output from PC connected to the other DVI connector obtained using a VBE call. If you need more information please specify how to obtain it. Thanks Michal screen-edid Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5 v1] dm: ls1021a: dts: Change address_cells and size_cells from 2 to 1
From: haikun haikun.w...@freescale.com
Change address_cells and size_cells of root node and 'soc' node
from 2 to 1.
We backport ls1021a device tree source files from kernel to u-boot.
Kernel files set address_cells and size_cells to 2 in order to access
more than 4GB space.
But we don't have this requirement now and u-boot fdtdec_get_xxx interfaces
can't support property whose size is 'u64' completely.
So make this change.
Signed-off-by: Haikun Wang haikun.w...@freescale.com
---
arch/arm/dts/ls1021a-qds.dts | 6 ++--
arch/arm/dts/ls1021a-twr.dts | 2 +-
arch/arm/dts/ls1021a.dtsi| 72 ++--
3 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/arch/arm/dts/ls1021a-qds.dts b/arch/arm/dts/ls1021a-qds.dts
index c89f85e..7454ac6 100644
--- a/arch/arm/dts/ls1021a-qds.dts
+++ b/arch/arm/dts/ls1021a-qds.dts
@@ -101,9 +101,9 @@
#address-cells = 2;
#size-cells = 1;
/* NOR, NAND Flashes and FPGA on board */
- ranges = 0x0 0x0 0x0 0x6000 0x0800
- 0x2 0x0 0x0 0x7e80 0x0001
- 0x3 0x0 0x0 0x7fb0 0x0100;
+ ranges = 0x0 0x0 0x6000 0x0800
+ 0x2 0x0 0x7e80 0x0001
+ 0x3 0x0 0x7fb0 0x0100;
status = okay;
nor@0,0 {
diff --git a/arch/arm/dts/ls1021a-twr.dts b/arch/arm/dts/ls1021a-twr.dts
index 34ac82d..2f0481d 100644
--- a/arch/arm/dts/ls1021a-twr.dts
+++ b/arch/arm/dts/ls1021a-twr.dts
@@ -46,7 +46,7 @@
#address-cells = 2;
#size-cells = 1;
/* NOR Flash on board */
- ranges = 0x0 0x0 0x0 0x6000 0x0800;
+ ranges = 0x0 0x0 0x6000 0x0800;
status = okay;
nor@0,0 {
diff --git a/arch/arm/dts/ls1021a.dtsi b/arch/arm/dts/ls1021a.dtsi
index 434b938..064d10c 100644
--- a/arch/arm/dts/ls1021a.dtsi
+++ b/arch/arm/dts/ls1021a.dtsi
@@ -6,7 +6,7 @@
* SPDX-License-Identifier:GPL-2.0+
*/
-#include skeleton64.dtsi
+#include skeleton.dtsi
#include dt-bindings/interrupt-controller/arm-gic.h
/ {
@@ -58,8 +58,8 @@
soc {
compatible = simple-bus;
- #address-cells = 2;
- #size-cells = 2;
+ #address-cells = 1;
+ #size-cells = 1;
device_type = soc;
interrupt-parent = gic;
ranges;
@@ -68,29 +68,29 @@
compatible = arm,cortex-a7-gic;
#interrupt-cells = 3;
interrupt-controller;
- reg = 0x0 0x1401000 0x0 0x1000,
- 0x0 0x1402000 0x0 0x1000,
- 0x0 0x1404000 0x0 0x2000,
- 0x0 0x1406000 0x0 0x2000;
+ reg = 0x1401000 0x1000,
+ 0x1402000 0x1000,
+ 0x1404000 0x2000,
+ 0x1406000 0x2000;
interrupts = GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_HIGH);
};
ifc: ifc@153 {
compatible = fsl,ifc, simple-bus;
- reg = 0x0 0x153 0x0 0x1;
+ reg = 0x153 0x1;
interrupts = GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH;
};
dcfg: dcfg@1ee {
compatible = fsl,ls1021a-dcfg, syscon;
- reg = 0x0 0x1ee 0x0 0x1;
+ reg = 0x1ee 0x1;
big-endian;
};
esdhc: esdhc@156 {
compatible = fsl,esdhc;
- reg = 0x0 0x156 0x0 0x1;
+ reg = 0x156 0x1;
interrupts = GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH;
clock-frequency = 0;
voltage-ranges = 1800 1800 3300 3300;
@@ -102,14 +102,14 @@
scfg: scfg@157 {
compatible = fsl,ls1021a-scfg, syscon;
- reg = 0x0 0x157 0x0 0x1;
+ reg = 0x157 0x1;
big-endian;
};
clockgen: clocking@1ee1000 {
#address-cells = 1;
#size-cells = 1;
- ranges = 0x0 0x0 0x1ee1000 0x1;
+ ranges = 0x0 0x1ee1000 0x1;
sysclk: sysclk {
compatible = fixed-clock;
@@ -148,7 +148,7 @@
compatible = fsl,vf610-dspi;
#address-cells = 1;
#size-cells = 0;
- reg = 0x0 0x210 0x0 0x1;
+ reg = 0x210 0x1;
interrupts = GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH;
[U-Boot] [PATCH v3] arm: mx5: Add support for USB armory board
From: Andrej Rosano and...@inversepath.com Add support for Inverse Path USB armory board, an open source flash-drive sized computer based on Freescale i.MX53 SoC. http://inversepath.com/usbarmory Signed-off-by: Andrej Rosano and...@inversepath.com Cc: Stefano Babic sba...@denx.de Cc: Chris Kuethe chris.kue...@gmail.com Cc: Fabio Estevam feste...@gmail.com Cc: Vagrant Cascadian vagr...@debian.org --- Changes for v3: - Add config_distro support Changes for v2: - Fix double print_cpuinfo() call - Fix CONFIG_BOOTCOMMAND typo - Fix CONFIG_SYS_FSL_ESDHC_NUM to 1 arch/arm/Kconfig |5 + board/inversepath/usbarmory/Kconfig | 15 + board/inversepath/usbarmory/MAINTAINERS |6 + board/inversepath/usbarmory/Makefile | 10 + board/inversepath/usbarmory/imximage.cfg | 82 ++ board/inversepath/usbarmory/usbarmory.c | 439 ++ configs/usbarmory_defconfig |3 + include/configs/usbarmory.h | 127 + 8 files changed, 687 insertions(+) create mode 100644 board/inversepath/usbarmory/Kconfig create mode 100644 board/inversepath/usbarmory/MAINTAINERS create mode 100644 board/inversepath/usbarmory/Makefile create mode 100644 board/inversepath/usbarmory/imximage.cfg create mode 100644 board/inversepath/usbarmory/usbarmory.c create mode 100644 configs/usbarmory_defconfig create mode 100644 include/configs/usbarmory.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b9ebee1..a490084 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -462,6 +462,10 @@ config TARGET_MX53SMD bool Support mx53smd select CPU_V7 +config TARGET_USBARMORY + bool Support USB armory + select CPU_V7 + config TARGET_MX51_EFIKAMX bool Support mx51_efikamx select CPU_V7 @@ -819,6 +823,7 @@ source board/h2200/Kconfig source board/hale/tt01/Kconfig source board/icpdas/lp8x4x/Kconfig source board/imx31_phycore/Kconfig +source board/inversepath/usbarmory/Kconfig source board/isee/igep0033/Kconfig source board/jornada/Kconfig source board/karo/tx25/Kconfig diff --git a/board/inversepath/usbarmory/Kconfig b/board/inversepath/usbarmory/Kconfig new file mode 100644 index 000..254b6c9 --- /dev/null +++ b/board/inversepath/usbarmory/Kconfig @@ -0,0 +1,15 @@ +if TARGET_USBARMORY + +config SYS_BOARD + default usbarmory + +config SYS_VENDOR + default inversepath + +config SYS_SOC + default mx5 + +config SYS_CONFIG_NAME + default usbarmory + +endif diff --git a/board/inversepath/usbarmory/MAINTAINERS b/board/inversepath/usbarmory/MAINTAINERS new file mode 100644 index 000..71a3dd4 --- /dev/null +++ b/board/inversepath/usbarmory/MAINTAINERS @@ -0,0 +1,6 @@ +USBARMORY BOARD +M: Andrej Rosano and...@inversepath.com +S: Maintained +F: board/inversepath/usbarmory/ +F: include/configs/usbarmory.h +F: configs/usbarmory_defconfig diff --git a/board/inversepath/usbarmory/Makefile b/board/inversepath/usbarmory/Makefile new file mode 100644 index 000..9b8bd80 --- /dev/null +++ b/board/inversepath/usbarmory/Makefile @@ -0,0 +1,10 @@ +# +# USB armory MkI board Makefile +# http://inversepath.com/usbarmory +# +# Copyright (C) 2015, Inverse Path +# Andrej Rosano and...@inversepath.com +# +# SPDX-License-Identifier:|GPL-2.0+ + +obj-y := usbarmory.o diff --git a/board/inversepath/usbarmory/imximage.cfg b/board/inversepath/usbarmory/imximage.cfg new file mode 100644 index 000..392d2f9 --- /dev/null +++ b/board/inversepath/usbarmory/imximage.cfg @@ -0,0 +1,82 @@ +/* + * USB armory MkI board imximage configuration + * http://inversepath.com/usbarmory + * + * Copyright (C) 2015, Inverse Path + * Andrej Rosano and...@inversepath.com + * + * SPDX-License-Identifier:|GPL-2.0+ + */ + +IMAGE_VERSION 2 +BOOT_FROM sd + + +/* IOMUX */ + +DATA 4 0x53fa86f4 0x /* GRP_DDRMODE_CTL */ +DATA 4 0x53fa8714 0x /* GRP_DDRMODE */ +DATA 4 0x53fa86fc 0x /* GRP_DDRPKE */ +DATA 4 0x53fa8724 0x0400 /* GRP_DDR_TYPE*/ + +DATA 4 0x53fa872c 0x0030 /* GRP_B3DS */ +DATA 4 0x53fa8554 0x0030 /* DRAM_DQM3 */ +DATA 4 0x53fa8558 0x00300040 /* DRAM_SDQS3 */ + +DATA 4 0x53fa8728 0x0030 /* GRP_B2DS */ +DATA 4 0x53fa8560 0x0030 /* DRAM_DQM2 */ +DATA 4 0x53fa8568 0x00300040 /* DRAM_SDQS2 */ + +DATA 4 0x53fa871c 0x0030 /* GRP_B1DS */ +DATA 4 0x53fa8594 0x0030 /* DRAM_DQM1 */ +DATA 4 0x53fa8590 0x00300040 /* DRAM_SDQS1 */ + +DATA 4 0x53fa8718 0x0030 /* GRP_B0DS */ +DATA 4 0x53fa8584 0x0030 /* DRAM_DQM0 */ +DATA 4 0x53fa857c 0x00300040 /* DRAM_SDQS0 */ + +DATA 4 0x53fa8578 0x0030 /* DRAM_SDCLK0 */ +DATA 4 0x53fa8570 0x0030 /* DRAM_SDCLK1 */ + +DATA 4 0x53fa8574 0x0030 /* DRAM_CAS */ +DATA 4 0x53fa8588 0x0030 /* DRAM_RAS */ +DATA 4 0x53fa86f0 0x0030 /* GRP_ADDS */ +DATA 4 0x53fa8720 0x0030 /* GRP_CTLDS */ + +DATA 4 0x53fa8564 0x00300040 /* DRAM_SDODT1 */ +DATA 4
[U-Boot] [PATCH 4/5 v1] dm: ls1021a: dts: Update DSPI node to support DM SPI
Update DSPI controller node in ls1021a.dtsi.
Update flash device node in ls1021a-qds.dts.
Ls1021a-twr board doesn't support DSPI, so remove DSPI node
in ls1021a-twr.dts.
Signed-off-by: Haikun Wang haikun.w...@freescale.com
---
arch/arm/dts/ls1021a-qds.dts | 3 ++-
arch/arm/dts/ls1021a-twr.dts | 15 ---
arch/arm/dts/ls1021a.dtsi| 4 ++--
3 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/arch/arm/dts/ls1021a-qds.dts b/arch/arm/dts/ls1021a-qds.dts
index 7454ac6..8971c18 100644
--- a/arch/arm/dts/ls1021a-qds.dts
+++ b/arch/arm/dts/ls1021a-qds.dts
@@ -18,6 +18,7 @@
enet2_rgmii_phy = rgmii_phy3;
enet0_sgmii_phy = sgmii_phy1c;
enet1_sgmii_phy = sgmii_phy1d;
+ spi1 = dspi0;
};
};
@@ -28,7 +29,7 @@
dspiflash: at45db021d@0 {
#address-cells = 1;
#size-cells = 1;
- compatible = atmel,at45db021d, atmel,at45,
atmel,dataflash;
+ compatible = spi-flash;
spi-max-frequency = 1600;
spi-cpol;
spi-cpha;
diff --git a/arch/arm/dts/ls1021a-twr.dts b/arch/arm/dts/ls1021a-twr.dts
index 2f0481d..3d9f23b 100644
--- a/arch/arm/dts/ls1021a-twr.dts
+++ b/arch/arm/dts/ls1021a-twr.dts
@@ -19,21 +19,6 @@
};
};
-dspi1 {
- bus-num = 0;
- status = okay;
-
- dspiflash: s25fl064k@0 {
- #address-cells = 1;
- #size-cells = 1;
- compatible = spansion,s25fl064k;
- spi-max-frequency = 1600;
- spi-cpol;
- spi-cpha;
- reg = 0;
- };
-};
-
i2c0 {
status = okay;
};
diff --git a/arch/arm/dts/ls1021a.dtsi b/arch/arm/dts/ls1021a.dtsi
index 064d10c..8b3c557 100644
--- a/arch/arm/dts/ls1021a.dtsi
+++ b/arch/arm/dts/ls1021a.dtsi
@@ -152,7 +152,7 @@
interrupts = GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH;
clock-names = dspi;
clocks = platform_clk 1;
- spi-num-chipselects = 5;
+ num-cs = 6;
big-endian;
status = disabled;
};
@@ -165,7 +165,7 @@
interrupts = GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH;
clock-names = dspi;
clocks = platform_clk 1;
- spi-num-chipselects = 5;
+ num-cs = 6;
big-endian;
status = disabled;
};
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/8] lpc32xx: mtd: nand: add MLC NAND controller
Hi Scott, Le Mon, 23 Mar 2015 20:20:50 -0500, Scott Wood scottw...@freescale.com a écrit : On Mon, 2015-03-23 at 09:45 +0100, Albert ARIBAUD wrote: Bonjour Scott, Le Fri, 20 Mar 2015 17:41:11 -0500, Scott Wood scottw...@freescale.com a écrit : On Fri, 2015-03-20 at 10:35 +0100, Albert ARIBAUD wrote: BTW, is there a standard way to ask a NAND chip which page(s) in a bad block should be checked? Yes and no: http://lists.infradead.org/pipermail/linux-mtd/2011-November/038419.html ... right. How about this: the driver expects a driver-specific configuration option which tells it which page(s) in a block, and which byte in a page's OOB area, should be scanned for bad block markers, and my board provides a value for said option. It looks like the common NAND code will set NAND_BBT_SCANLASTPAGE/NAND_BBT_SCAN2NDPAGE automatically if it sees certain manufacturer IDs, so I don't think drivers should be setting them at all (and currently, none do). Ok. That still leaves the question of what to do in SPL. For simplicity you could check every page as you do the normal read. Ok. Patch series v7 to follow... as soon as I have completed it. This leads me to a half-OT question: so those SPL, while too tiny to handle non-raw images, still do include the whole common/spl/spl.c No, there's no room for that. Ok. If you want to do this, just put a comment in explaining why you're skipping in that situation. Ok -- I will go with the 'option' method then, and add a (lengthy, I'm afraid) comment in common/spl/spl.c explaining that skipping the raw image handling is required when chainloading from NAND and the NAND driver considers totally unreadable sectors bad, in order not to confuse a missing image header with a raw image. Skipping raw wouldn't be needed for all NAND drivers, only those that aren't guaranteed to halt on a legitimate unrecoverable ECC error. Understood. -Scott Cordialement, Albert ARIBAUD 3ADEV ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5 v1] dm: arm: Bring in skeleton64 device tree file from Linux
Backport of kernel commits:
7c14f6c719de092d69c81877786e83ce7ae1a860
35faad2a1563b3d4dc983a82ac41033fe053870c
Signed-off-by: Haikun Wang haikun.w...@freescale.com
---
arch/arm/dts/skeleton64.dtsi | 13 +
1 file changed, 13 insertions(+)
create mode 100644 arch/arm/dts/skeleton64.dtsi
diff --git a/arch/arm/dts/skeleton64.dtsi b/arch/arm/dts/skeleton64.dtsi
new file mode 100644
index 000..b5d7f36
--- /dev/null
+++ b/arch/arm/dts/skeleton64.dtsi
@@ -0,0 +1,13 @@
+/*
+ * Skeleton device tree in the 64 bits version; the bare minimum
+ * needed to boot; just include and add a compatible value. The
+ * bootloader will typically populate the memory node.
+ */
+
+/ {
+ #address-cells = 2;
+ #size-cells = 2;
+ chosen { };
+ aliases { };
+ memory { device_type = memory; reg = 0 0 0 0; };
+};
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5 v1] dm: ls1021a: dts: Add QSPI dts node
Add QSPI controller dts node in ls1021a.dtsi.
Add QSPI slave device dts node in ls1021a-twr.dts and ls1021a-qds.dts.
Signed-off-by: Haikun Wang haikun.w...@freescale.com
---
arch/arm/dts/ls1021a-qds.dts | 14 ++
arch/arm/dts/ls1021a-twr.dts | 14 ++
arch/arm/dts/ls1021a.dtsi| 11 +++
3 files changed, 39 insertions(+)
diff --git a/arch/arm/dts/ls1021a-qds.dts b/arch/arm/dts/ls1021a-qds.dts
index 8971c18..8367811 100644
--- a/arch/arm/dts/ls1021a-qds.dts
+++ b/arch/arm/dts/ls1021a-qds.dts
@@ -18,6 +18,7 @@
enet2_rgmii_phy = rgmii_phy3;
enet0_sgmii_phy = sgmii_phy1c;
enet1_sgmii_phy = sgmii_phy1d;
+ spi0 = qspi;
spi1 = dspi0;
};
};
@@ -37,6 +38,19 @@
};
};
+qspi {
+ bus-num = 0;
+ status = okay;
+
+ qflash0: s25fl128s@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = spi-flash;
+ spi-max-frequency = 2000;
+ reg = 0;
+ };
+};
+
i2c0 {
status = okay;
diff --git a/arch/arm/dts/ls1021a-twr.dts b/arch/arm/dts/ls1021a-twr.dts
index 3d9f23b..0e61c07 100644
--- a/arch/arm/dts/ls1021a-twr.dts
+++ b/arch/arm/dts/ls1021a-twr.dts
@@ -16,6 +16,20 @@
enet2_rgmii_phy = rgmii_phy1;
enet0_sgmii_phy = sgmii_phy2;
enet1_sgmii_phy = sgmii_phy0;
+ spi0 = qspi;
+ };
+};
+
+qspi {
+ bus-num = 0;
+ status = okay;
+
+ qflash0: n25q128a13@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = spi-flash;
+ spi-max-frequency = 2000;
+ reg = 0;
};
};
diff --git a/arch/arm/dts/ls1021a.dtsi b/arch/arm/dts/ls1021a.dtsi
index 8b3c557..7fadd7c 100644
--- a/arch/arm/dts/ls1021a.dtsi
+++ b/arch/arm/dts/ls1021a.dtsi
@@ -170,6 +170,17 @@
status = disabled;
};
+ qspi: quadspi@155 {
+ compatible = fsl,vf610-qspi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x155 0x1,
+ 0x4000 0x400;
+ num-cs = 2;
+ big-endian;
+ status = disabled;
+ };
+
i2c0: i2c@218 {
compatible = fsl,vf610-i2c;
#address-cells = 1;
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] dm: spi: Convert Freescale DSPI driver to driver model
Move the Freescale DSPI driver over to driver model.
Signed-off-by: Haikun Wang haikun.w...@freescale.com
---
Changes in v3:
- Coding style cleanup
- Remove cur_slave_plat in structure fsl_dspi_priv
- Change arguments of 'claim_bus' and 'release_bus'
- Remove 'fsl_dspi_child_post_remove'
- Add support NO-DM SPI
- Add 'cpu_dspi_xxx' platform speical configure interface
Changes in v2:
- Coding style cleanup
- Add some comments
- Use structures for I/O access
- Handle timeout case in 'dspi_tx' and 'dspi_rx'
- Move some register configurations from 'set_mode' to 'claim_bus'
- Rename structure fsl_dspi_platdata's member baudrate
- Remove some redundancy code
Changes in v1: None
drivers/spi/Makefile | 1 +
drivers/spi/fsl_dspi.c | 737 +
include/fsl_dspi.h | 150 ++
3 files changed, 888 insertions(+)
create mode 100644 drivers/spi/fsl_dspi.c
create mode 100644 include/fsl_dspi.h
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index edbd520..9c2b8de 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -49,3 +49,4 @@ obj-$(CONFIG_TI_QSPI) += ti_qspi.o
obj-$(CONFIG_XILINX_SPI) += xilinx_spi.o
obj-$(CONFIG_ZYNQ_SPI) += zynq_spi.o
obj-$(CONFIG_FSL_QSPI) += fsl_qspi.o
+obj-$(CONFIG_FSL_DSPI) += fsl_dspi.o
diff --git a/drivers/spi/fsl_dspi.c b/drivers/spi/fsl_dspi.c
new file mode 100644
index 000..6476f91
--- /dev/null
+++ b/drivers/spi/fsl_dspi.c
@@ -0,0 +1,737 @@
+/*
+ * (C) Copyright 2000-2003
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * Copyright (C) 2004-2009, 2015 Freescale Semiconductor, Inc.
+ * TsiChung Liew (tsi-chung.l...@freescale.com)
+ * Chao Fu (b44...@freescale.com)
+ * Haikun Wang (b53...@freescale.com)
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include dm.h
+#include errno.h
+#include common.h
+#include spi.h
+#include malloc.h
+#include asm/io.h
+#include fdtdec.h
+#ifndef CONFIG_M68K
+#include asm/arch/clock.h
+#endif
+#include fsl_dspi.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* fsl_dspi_platdata flags */
+#define DSPI_FLAG_REGMAP_ENDIAN_BIG(1 0)
+
+/* idle data value */
+#define DSPI_IDLE_VAL 0x0
+
+/* max chipselect signals number */
+#define FSL_DSPI_MAX_CHIPSELECT6
+
+/* default SCK frequency, unit: HZ */
+#define FSL_DSPI_DEFAULT_SCK_FREQ 1000
+
+/* tx/rx data wait timeout value, unit: us */
+#define DSPI_TXRX_WAIT_TIMEOUT 100
+
+/* CTAR register pre-configure value */
+#define DSPI_CTAR_DEFAULT_VALUE(DSPI_CTAR_TRSZ(7) | \
+ DSPI_CTAR_PCSSCK_1CLK | \
+ DSPI_CTAR_PASC(0) | \
+ DSPI_CTAR_PDT(0) | \
+ DSPI_CTAR_CSSCK(0) | \
+ DSPI_CTAR_ASC(0) | \
+ DSPI_CTAR_DT(0))
+
+/* CTAR register pre-configure mask */
+#define DSPI_CTAR_SET_MODE_MASK(DSPI_CTAR_TRSZ(15) | \
+ DSPI_CTAR_PCSSCK(3) | \
+ DSPI_CTAR_PASC(3) | \
+ DSPI_CTAR_PDT(3) | \
+ DSPI_CTAR_CSSCK(15) | \
+ DSPI_CTAR_ASC(15) | \
+ DSPI_CTAR_DT(15))
+
+/**
+ * struct fsl_dspi_platdata - platform data for Freescale DSPI
+ *
+ * @flags: Flags for DSPI DSPI_FLAG_...
+ * @speed_hz: Default SCK frequency
+ * @num_chipselect: Number of DSPI chipselect signals
+ * @regs_addr: Base address of DSPI registers
+ */
+struct fsl_dspi_platdata {
+ uint flags;
+ uint speed_hz;
+ uint num_chipselect;
+ fdt_addr_t regs_addr;
+};
+
+/**
+ * struct fsl_dspi_priv - private data for Freescale DSPI
+ *
+ * @flags: Flags for DSPI DSPI_FLAG_...
+ * @mode: SPI mode to use for slave device (see SPI mode flags)
+ * @mcr_val: MCR register configure value
+ * @bus_clk: DSPI input clk frequency
+ * @speed_hz: Default SCK frequency
+ * @charbit: How many bits in every transfer
+ * @num_chipselect: Number of DSPI chipselect signals
+ * @ctar_val: CTAR register configure value of per chipselect slave device
+ * @regs: Point to DSPI register structure for I/O access
+ */
+struct fsl_dspi_priv {
+ uint flags;
+ uint mode;
+ uint mcr_val;
+ uint bus_clk;
+ uint speed_hz;
+ uint charbit;
+ uint num_chipselect;
+ uint ctar_val[FSL_DSPI_MAX_CHIPSELECT];
+ struct dspi *regs;
+};
+
+#ifndef CONFIG_DM_SPI
+struct fsl_dspi {
+ struct spi_slave slave;
+ struct fsl_dspi_priv priv;
+};
+#endif
+
+__weak void cpu_dspi_port_conf(void)
+{
+}
+
+__weak int cpu_dspi_claim_bus(uint bus, uint cs)
+{
+ return 0;
+}
+
+__weak void cpu_dspi_release_bus(uint bus, uint cs)
+{
+}
+
+static uint dspi_read32(uint flags, uint *addr)
+{
+ return
[U-Boot] [PATCH] tegra: pinmux: fix FUNCMUX_NDFLASH_KBC_8_BIT
From: Lucas Stach d...@lynxeye.de Even the 8-bit case needs KBCB configured, as pin D7 is located in this pingroup. Also pingroup ATC seems to come out of reset with config set to NAND, so we need to explictly configure some other function to this group in order to avoid clashing settings. Signed-off-by: Lucas Stach d...@lynxeye.de Signed-off-by: Marcel Ziswiler mar...@ziswiler.com Tested-by: Marcel Ziswiler mar...@ziswiler.com --- arch/arm/mach-tegra/tegra20/funcmux.c | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/mach-tegra/tegra20/funcmux.c b/arch/arm/mach-tegra/tegra20/funcmux.c index 0df4a07..f9b6214 100644 --- a/arch/arm/mach-tegra/tegra20/funcmux.c +++ b/arch/arm/mach-tegra/tegra20/funcmux.c @@ -252,17 +252,25 @@ int funcmux_select(enum periph_id id, int config) break; case FUNCMUX_NDFLASH_KBC_8_BIT: pinmux_set_func(PMUX_PINGRP_KBCA, PMUX_FUNC_NAND); + pinmux_set_func(PMUX_PINGRP_KBCB, PMUX_FUNC_NAND); pinmux_set_func(PMUX_PINGRP_KBCC, PMUX_FUNC_NAND); pinmux_set_func(PMUX_PINGRP_KBCD, PMUX_FUNC_NAND); pinmux_set_func(PMUX_PINGRP_KBCE, PMUX_FUNC_NAND); pinmux_set_func(PMUX_PINGRP_KBCF, PMUX_FUNC_NAND); pinmux_tristate_disable(PMUX_PINGRP_KBCA); + pinmux_tristate_disable(PMUX_PINGRP_KBCB); pinmux_tristate_disable(PMUX_PINGRP_KBCC); pinmux_tristate_disable(PMUX_PINGRP_KBCD); pinmux_tristate_disable(PMUX_PINGRP_KBCE); pinmux_tristate_disable(PMUX_PINGRP_KBCF); + /* +* configure pingroup ATC to something unrelated to +* avoid ATC overriding KBC +*/ + pinmux_set_func(PMUX_PINGRP_ATC, PMUX_FUNC_GMI); + bad_config = 0; break; } -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 64Bit device tree compilation
Hi, Maybe a dumb question, why do we need to have a 64-bit U-Boot for arm64? I don't see we ever created 64-bit U-Boot for ppc64. In ARMv8 it's not possible to change the register width at an exception level (i.e. you can't change 64-32 or vice-versa), and lower exception levels cannot be wider (so if your code at EL3 is 32-bit, you cannot run 64-bit code at EL3, EL2, EL1, or EL0). Therefore you need a purely 64-bit path from EL3 to EL2 or EL1N in order to boot a 64-bit kernel, so the bootloader needs to be 64-bit. Mark. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: phy: micrel: add support for KSZ8081MNX
This patch adds a support for KSZ8081MNX in MII mode.
Signed-off-by: Luca Ellero luca.ell...@brickedbrain.com
---
drivers/net/phy/micrel.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 1815b29..49f444a 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -22,6 +22,16 @@ static struct phy_driver KSZ804_driver = {
.shutdown = genphy_shutdown,
};
+static struct phy_driver KSZ8081_driver = {
+ .name = Micrel KSZ8081,
+ .uid = 0x221560,
+ .mask = 0xf0,
+ .features = PHY_BASIC_FEATURES,
+ .config = genphy_config,
+ .startup = genphy_startup,
+ .shutdown = genphy_shutdown,
+};
+
/**
* KSZ8895
*/
@@ -272,6 +282,7 @@ static struct phy_driver ksz9031_driver = {
int phy_micrel_init(void)
{
phy_register(KSZ804_driver);
+ phy_register(KSZ8081_driver);
#ifdef CONFIG_PHY_MICREL_KSZ9021
phy_register(ksz9021_driver);
#else
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: phy: micrel: add support for KSZ8081MNX
On Tue 2015-03-24 11:32:24, Luca Ellero wrote: This patch adds a support for KSZ8081MNX in MII mode. Signed-off-by: Luca Ellero luca.ell...@brickedbrain.com Acked-by: Pavel Machek pa...@denx.de -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/7] generic-board: move __HAVE_ARCH_GENERIC_BOARD to Kconfig
On Mon, 2015-03-23 at 15:33 -0600, Simon Glass wrote: On 19 March 2015 at 04:42, Masahiro Yamada yamada.masah...@socionext.com wrote: Move the option to Kconfig renaming it to CONFIG_HAVE_GENERIC_BOARD. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- Changes in v2: None Makefile | 2 +- README| 6 +++--- arch/Kconfig | 14 ++ arch/arc/config.mk| 3 --- arch/arm/config.mk| 3 --- arch/avr32/config.mk | 3 --- arch/blackfin/config.mk | 3 --- arch/m68k/config.mk | 3 --- arch/microblaze/config.mk | 1 - arch/mips/config.mk | 2 -- arch/nios2/config.mk | 2 -- arch/powerpc/config.mk| 3 --- arch/sandbox/config.mk| 3 --- arch/x86/config.mk| 3 --- doc/README.generic-board | 12 +++- 15 files changed, 25 insertions(+), 38 deletions(-) Reviewed-by: Simon Glass s...@chromium.org Reviewed-by: Alexey Brodkin abrod...@synopsys.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/7] generic-board: select SYS_GENERIC_BOARD for some architectures
On Mon, 2015-03-23 at 15:33 -0600, Simon Glass wrote: On 19 March 2015 at 04:42, Masahiro Yamada yamada.masah...@socionext.com wrote: We have done with the generic board conversion for all the boards of ARC, Blackfin, M68000, MicroBlaze, MIPS, NIOS2, Sandbox, X86. Let's select SYS_GENERIC_BOARD for those architectures, so we can tell which architecture has finished the conversion at a glance. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- Changes in v2: None arch/Kconfig | 12 arch/arc/include/asm/config.h| 1 - arch/blackfin/include/asm/config.h | 1 - arch/m68k/include/asm/config.h | 1 - arch/microblaze/include/asm/config.h | 1 - arch/nios2/include/asm/config.h | 1 - arch/sandbox/config.mk | 2 +- arch/x86/include/asm/config.h| 1 - include/configs/amcore.h | 2 -- include/configs/dbau1x00.h | 1 - include/configs/malta.h | 1 - include/configs/pb1x00.h | 1 - include/configs/qemu-mips.h | 1 - include/configs/qemu-mips64.h| 1 - include/configs/vct.h| 1 - 15 files changed, 13 insertions(+), 15 deletions(-) Reviewed-by: Simon Glass s...@chromium.org Reviewed-by: Alexey Brodkin abrod...@synopsys.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_sf: Fix recovery default
The u-boot environment is redundantly stored in a NOR flash on our boards.
Redundant means that there are two places to store the environment. But only
one of the two is active. I discovered that on one board the u-boot (env_sf)
uses the environment from the second place and the Kernel (fw_printenv) uses
the environment from the first place.
To decide which is the active environment there is a byte inside the
environment. 1 means active and 0 means obsolete. But on that board both
environments had have a 1. This can happen if a power loss or reset occurs
during writing the environment. In this situation the u-boot (env_sf)
implementation uses the second environment as default. But the Kernel
(fw_printenv) implementation uses the first environment as default.
This commit corrects the default in the u-boot env_sf implementation when a
problem was detected. Now the recovery default is the same like in all other
environment implementations. E.g. fw_printenv and env_flash. This ensures that
u-boot and Kernel use the same environment.
Signed-off-by: Mario Schuknecht mario.schukne...@dresearch-fe.de
---
common/env_sf.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/common/env_sf.c b/common/env_sf.c
index 5e3729c..e928f57 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -188,15 +188,17 @@ void env_relocate_spec(void)
tmp_env2-flags == ACTIVE_FLAG) {
gd-env_valid = 2;
} else if (tmp_env1-flags == tmp_env2-flags) {
- gd-env_valid = 2;
+ gd-env_valid = 1;
} else if (tmp_env1-flags == 0xFF) {
+ gd-env_valid = 1;
+ } else if (tmp_env2-flags == 0xFF) {
gd-env_valid = 2;
} else {
/*
* this differs from code in env_flash.c, but I think a sane
* default path is desirable.
*/
- gd-env_valid = 2;
+ gd-env_valid = 1;
}
if (gd-env_valid == 1)
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm:ls1021a: Reserve secure code into RAM instead of OCRAM
For ls1021a, Reserve secure code in to memory in case OCRAM is needed by other usage. Signed-off-by: Zhuoyu Zhang zhuoyu.zh...@freescale.com --- include/configs/ls1021aqds.h | 1 - include/configs/ls1021atwr.h | 1 - 2 files changed, 2 deletions(-) diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h index 3dc4da3..42439a4 100644 --- a/include/configs/ls1021aqds.h +++ b/include/configs/ls1021aqds.h @@ -554,7 +554,6 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_LS102XA_NS_ACCESS #define CONFIG_SMP_PEN_ADDR0x01ee0200 #define CONFIG_TIMER_CLK_FREQ 1250 -#define CONFIG_ARMV7_SECURE_BASE OCRAM_BASE_S_ADDR #define CONFIG_HWCONFIG #define HWCONFIG_BUFFER_SIZE 128 diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index a13876b..dccc661 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -347,7 +347,6 @@ #define CONFIG_LS102XA_NS_ACCESS #define CONFIG_SMP_PEN_ADDR0x01ee0200 #define CONFIG_TIMER_CLK_FREQ 1250 -#define CONFIG_ARMV7_SECURE_BASE OCRAM_BASE_S_ADDR #define CONFIG_HWCONFIG #define HWCONFIG_BUFFER_SIZE 128 -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] ARM: DRA7XX: Enable Fastboot
- Fastboot is enable by default for DRA7XX - This is based on following patch modified accordingly http://git.omapzoom.org/?p=repo/u-boot.git;a=commit;h=b2e04f92b5d91c708b6fd6b79d2266966ac51f4b Signed-off-by: Angela Stegmaier angelaba...@ti.com Signed-off-by: Dileep Katta dileep.ka...@linaro.org --- Changes in v2: - Merged the header file content to existing dra7xx_evm.h to avoid duplication - Removed unnecessary definitions as per comments Changes in v3: - Added the changes on dwc3_gadget developer branch of DFU tree - Added the changes as part of existing dra7xx_evm_defconfig - Enabled fastboot by default - Kept fastboot aware VID/PID only - reverted change made for U-Boot offset include/configs/dra7xx_evm.h | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h index e94b618..7acd907 100644 --- a/include/configs/dra7xx_evm.h +++ b/include/configs/dra7xx_evm.h @@ -84,6 +84,14 @@ DFU_ALT_INFO_EMMC \ DFU_ALT_INFO_RAM +/* Fastboot */ +#define CONFIG_CMD_FASTBOOT +#define CONFIG_ANDROID_BOOT_IMAGE +#define CONFIG_USB_FASTBOOT_BUF_ADDRCONFIG_SYS_LOAD_ADDR +#define CONFIG_USB_FASTBOOT_BUF_SIZE0x2F00 +#define CONFIG_FASTBOOT_FLASH +#define CONFIG_FASTBOOT_FLASH_MMC_DEV 1 + #include configs/ti_omap5_common.h /* Enhance our eMMC support / experience. */ @@ -181,8 +189,8 @@ #define CONFIG_USBDOWNLOAD_GADGET #define CONFIG_USB_GADGET_VBUS_DRAW 2 #define CONFIG_G_DNL_MANUFACTURER Texas Instruments -#define CONFIG_G_DNL_VENDOR_NUM 0x0403 -#define CONFIG_G_DNL_PRODUCT_NUM 0xBD00 +#define CONFIG_G_DNL_VENDOR_NUM 0x0451 +#define CONFIG_G_DNL_PRODUCT_NUM 0xd022 #define CONFIG_USB_GADGET_DUALSPEED /* USB Device Firmware Update support */ -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: mx5: Add support for USB armory board
On 2015-03-24, and...@inversepath.com wrote:
Add support for Inverse Path USB armory board, an open source
flash-drive sized computer based on Freescale i.MX53 SoC.
Thanks!
Unfortunately, this fails to build with numerous errors such as:
CC arch/arm/lib/asm-offsets.s
In file included from include/config.h:6:0,
from /«BUILDDIR»/u-boot-2015.04~rc4+dfsg1/include/common.h:18,
from /«BUILDDIR»/u-boot-2015.04~rc4+dfsg1/lib/asm-offsets.c:15:
/«BUILDDIR»/u-boot-2015.04~rc4+dfsg1/include/configs/usbarmory.h:86:0: warning:
CONFIG_BOOTCOMMAND redefined
#define CONFIG_BOOTCOMMAND \
^
In file included from
/«BUILDDIR»/u-boot-2015.04~rc4+dfsg1/include/configs/usbarmory.h:27:0,
from include/config.h:6,
from /«BUILDDIR»/u-boot-2015.04~rc4+dfsg1/include/common.h:18,
from /«BUILDDIR»/u-boot-2015.04~rc4+dfsg1/lib/asm-offsets.c:15:
/«BUILDDIR»/u-boot-2015.04~rc4+dfsg1/include/config_distro_bootcmd.h:232:0:
note: this is the location of the previous definition
#define CONFIG_BOOTCOMMAND run distro_bootcmd
^
It is caused by including config_distro_bootcmd.h too early, and
config_distro_bootcmd.h defines CONFIG_BOOTCOMMAND before it is set in
include/configs/usbarmory.h.
The include for config_distro_bootcmd.h should be *after*
CONFIG_BOOTCOMMAND and BOOT_TARGET_DEVICES are defined, at least. There
are also other conditionals that may be impacted but are more subtle.
So here's a tested trivial patch to fix that:
Index: u-boot/include/configs/usbarmory.h
===
--- u-boot.orig/include/configs/usbarmory.h
+++ u-boot/include/configs/usbarmory.h
@@ -24,7 +24,6 @@
#include config_cmd_default.h
#include config_distro_defaults.h
-#include config_distro_bootcmd.h
/* U-Boot commands */
#define CONFIG_CMD_MEMTEST
@@ -92,6 +91,8 @@
#define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0)
+#include config_distro_bootcmd.h
+
#define MEM_LAYOUT_ENV_SETTINGS \
kernel_addr_r=0x7080\0 \
fdt_addr_r=0x7100\0 \
I'd like to propose only setting bootargs when the default action is
kicking in to allow for a different root device, or root device
discovery from an initramfs, or boot scripts, etc... Something along
these lines (untested):
Index: u-boot/include/configs/usbarmory.h
===
--- u-boot.orig/include/configs/usbarmory.h
+++ u-boot/include/configs/usbarmory.h
@@ -80,10 +80,9 @@
#define CONFIG_SYS_TEXT_BASE 0x7780
#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR
#define CONFIG_HOSTNAMEusbarmory
-#define CONFIG_BOOTARGS \
- console=ttymxc0,115200 root=/dev/mmcblk0p1 rootwait rw
#define CONFIG_BOOTCOMMAND \
run distro_bootcmd; \
+ setenv bootargs console=${console} ${bootargs_default}; \
ext2load mmc 0:1 ${kernel_addr_r} /boot/uImage; \
ext2load mmc 0:1 ${fdt_addr_r} /boot/${fdtfile}; \
bootm ${kernel_addr_r} - ${fdt_addr_r}
@@ -102,6 +101,7 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
MEM_LAYOUT_ENV_SETTINGS \
+ bootargs_default=root=/dev/mmcblk0p1 rootwait rw\0 \
fdtfile=imx53-usbarmory.dtb\0 \
console=ttymxc0,115200\0 \
BOOTENV
live well,
vagrant
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] ARM: DRA7: Set serial number environment variable
This patch populates serial number environment variable from
die_id_0 and die_id_1 register values for DRA7xx boards.
The function is added in omap common code so that this can be re-used.
Serial# environment variable will be useful to show correct
information in fastboot devices commands.
Ref:
http://git.omapzoom.org/?p=repo/u-boot.git;a=commit;h=a6bcaaf67f6e4bcd97808f53d0ceb4b0c04d583c
Signed-off-by: Angela Stegmaier angelaba...@ti.com
Signed-off-by: Dileep Katta dileep.ka...@linaro.org
---
Changes in v2:
- None
Changes in v3:
- corrected the error in the computation of serial# variable
- Made it more generic and reusable as per the comments
arch/arm/cpu/armv7/omap-common/utils.c | 13 +
arch/arm/cpu/armv7/omap5/prcm-regs.c | 4
arch/arm/include/asm/omap_common.h | 5 +
board/ti/dra7xx/evm.c | 6 ++
4 files changed, 28 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap-common/utils.c
b/arch/arm/cpu/armv7/omap-common/utils.c
index 1696c2d..df5f817 100644
--- a/arch/arm/cpu/armv7/omap-common/utils.c
+++ b/arch/arm/cpu/armv7/omap-common/utils.c
@@ -60,3 +60,16 @@ void __weak usb_fake_mac_from_die_id(u32 *id)
eth_setenv_enetaddr(usbethaddr, device_mac);
}
}
+
+void __weak usb_set_serial_num_from_die_id(u32 *id)
+{
+ char serialno[72];
+ uint32_t serialno_lo, serialno_hi;
+
+ if (!getenv(serial#)) {
+ serialno_hi = id[0];
+ serialno_lo = id[1];
+ sprintf(serialno, %08x%08x, serialno_hi, serialno_lo);
+ setenv(serial#, serialno);
+ }
+}
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 440bb40..f80d36d 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -440,6 +440,10 @@ struct omap_sys_ctrl_regs const dra7xx_ctrl = {
.control_emif1_sdram_config_ext = 0x4AE0C144,
.control_emif2_sdram_config_ext = 0x4AE0C148,
.control_wkup_ldovbb_mpu_voltage_ctrl = 0x4AE0C158,
+ .control_std_fuse_die_id_0 = 0x4AE0C200,
+ .control_std_fuse_die_id_1 = 0x4AE0C208,
+ .control_std_fuse_die_id_2 = 0x4AE0C20C,
+ .control_std_fuse_die_id_3 = 0x4AE0C210,
.control_padconf_mode = 0x4AE0C5A0,
.control_xtal_oscillator= 0x4AE0C5A4,
.control_i2c_2 = 0x4AE0C5A8,
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index bd43099..13a57ab 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -362,6 +362,10 @@ struct omap_sys_ctrl_regs {
u32 control_core_control_io1;
u32 control_core_control_io2;
u32 control_id_code;
+ u32 control_std_fuse_die_id_0;
+ u32 control_std_fuse_die_id_1;
+ u32 control_std_fuse_die_id_2;
+ u32 control_std_fuse_die_id_3;
u32 control_std_fuse_opp_bgap;
u32 control_ldosram_iva_voltage_ctrl;
u32 control_ldosram_mpu_voltage_ctrl;
@@ -578,6 +582,7 @@ void abb_setup(u32 fuse, u32 ldovbb, u32 setup, u32 control,
s8 abb_setup_ldovbb(u32 fuse, u32 ldovbb);
void usb_fake_mac_from_die_id(u32 *id);
+void usb_set_serial_num_from_die_id(u32 *id);
/* ABB */
#define OMAP_ABB_NOMINAL_OPP 0
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 3089fa2..cadff5a 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -93,10 +93,16 @@ int board_init(void)
int board_late_init(void)
{
#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+ u32 id[4];
+
if (omap_revision() == DRA722_ES1_0)
setenv(board_name, dra72x);
else
setenv(board_name, dra7xx);
+
+ id[0] = readl((*ctrl)-control_std_fuse_die_id_0);
+ id[1] = readl((*ctrl)-control_std_fuse_die_id_1);
+ usb_set_serial_num_from_die_id(id);
#endif
return 0;
}
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] fastboot: ARM: OMAP5: Enable reboot-bootloader
Implemented fb_set_reboot_flag() for OMAP5 to set
an environment variable 'dofastboot' when reboot-bootloader called.
This environment variable will be checked in boot command and fastboot
will be called if the variable is set.
If the bootcmd env variable of OMAP5 common is overwritten with board-specific
command, then these changes will not apply.
This was originally intended for DRA7 platform, but now applies to all OMAP5.
Ref:
http://git.omapzoom.org/?p=repo/u-boot.git;a=commit;h=19da2e436e9806259cf1f4988b9e046ab256bf2c
Signed-off-by: Angela Stegmaier angelaba...@ti.com
Signed-off-by: Dileep Katta dileep.ka...@linaro.org
---
Changes in v2:
- None
Changes in v3:
- Changed the implementation to be more abstract
- Used environment variable instead of board-specific registers
- Moved the code to OMAP5
arch/arm/cpu/armv7/omap-common/boot-common.c | 11 +++
include/configs/ti_omap5_common.h| 7 +++
2 files changed, 18 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c
b/arch/arm/cpu/armv7/omap-common/boot-common.c
index 17500f2..1aff7c8 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -162,3 +162,14 @@ void arch_preboot_os(void)
ahci_reset(DWC_AHSATA_BASE);
}
#endif
+
+#ifdef CONFIG_CMD_FASTBOOT
+int fb_set_reboot_flag(void)
+{
+ printf(Setting reboot to fastboot flag ...\n);
+ setenv(dofastboot, 1);
+ saveenv();
+ udelay(60);
+ return 0;
+}
+#endif
diff --git a/include/configs/ti_omap5_common.h
b/include/configs/ti_omap5_common.h
index cd92454..c5d97ea 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -141,13 +141,20 @@
loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0 \
DFUARGS \
+
#define CONFIG_BOOTCOMMAND \
+ if test ${dofastboot} -eq 1; then \
+ echo Boot fastboot requested, resetting dofastboot ...; \
+ setenv dofastboot 0; saveenv; sleep 1; \
+ echo Booting into fastboot ...; fastboot; \
+ fi; \
run findfdt; \
run mmcboot; \
setenv mmcdev 1; \
setenv bootpart 1:2; \
setenv mmcroot /dev/mmcblk0p2 rw; \
run mmcboot; \
+
/*
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] armv8/mmu: Set bits marked RES1 in TCR
-Original Messages-
From: Thierry Reding thierry.red...@gmail.com
Sent Time: 2015-03-20 19:47:51 (Friday)
To: u-boot@lists.denx.de
Cc: Marc Zyngier marc.zyng...@arm.com
Subject: [U-Boot] [PATCH 4/6] armv8/mmu: Set bits marked RES1 in TCR
From: Thierry Reding tred...@nvidia.com
For EL3 and EL2, the documentation says that bits 31 and 23 are reserved
but should be written as 1.
For EL1, only bit 23 is not reserved, so only write bit 31 as 1.
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Marc Zyngier marc.zyng...@arm.com
Signed-off-by: Thierry Reding tred...@nvidia.com
---
arch/arm/cpu/armv8/cache_v8.c| 6 +++---
arch/arm/include/asm/armv8/mmu.h | 4
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 254a629a3b8c..f9b04057f696 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -50,15 +50,15 @@ static void mmu_setup(void)
el = current_el();
if (el == 1) {
set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
- TCR_FLAGS | TCR_EL1_IPS_BITS,
+ TCR_EL1_RSVD | TCR_FLAGS | TCR_EL1_IPS_BITS,
MEMORY_ATTRIBUTES);
} else if (el == 2) {
set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
- TCR_FLAGS | TCR_EL2_IPS_BITS,
+ TCR_EL2_RSVD | TCR_FLAGS | TCR_EL2_IPS_BITS,
MEMORY_ATTRIBUTES);
} else {
set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
- TCR_FLAGS | TCR_EL3_IPS_BITS,
+ TCR_EL3_RSVD | TCR_FLAGS | TCR_EL3_IPS_BITS,
MEMORY_ATTRIBUTES);
}
/* enable the mmu */
diff --git a/arch/arm/include/asm/armv8/mmu.h
b/arch/arm/include/asm/armv8/mmu.h
index 6d42f5533a74..8e577b34e4ba 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -109,6 +109,10 @@
TCR_IRGN_WBWA | \
TCR_T0SZ(VA_BITS))
+#define TCR_EL1_RSVD (1 31)
+#define TCR_EL2_RSVD (1 31 | 1 23)
+#define TCR_EL3_RSVD (1 31 | 1 23)
+
#ifndef __ASSEMBLY__
void set_pgtable_section(u64 *page_table, u64 index,
u64 section, u64 memory_type);
--
2.3.2
Acked-by: david.feng feng...@phytium.com.cn
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Vexpress64: Fix the compiling error when CONFIG_ARMV8_MULTIENTRY defined
+/* SMP Spin Table Definitions */
+#ifdef CONFIG_BASE_FVP
+#define CPU_RELEASE_ADDR (CONFIG_SYS_SDRAM_BASE +
0x03f0)
+#else
+#define CPU_RELEASE_ADDR (CONFIG_SYS_SDRAM_BASE + 0x7fff0)
+#endif
Where are these address defines coming from?
It's just hard coded and should be the same value with that in DTS.
I look in the DTS from the Linux kernel:
arch/arm64/boot/dts/arm/foundation-v8.dts:
cpu@0 {
device_type = cpu;
compatible = arm,armv8;
reg = 0x0 0x0;
enable-method = spin-table;
cpu-release-addr = 0x0 0x8000fff8;
next-level-cache = L2_0;
};
cpu@1 {
device_type = cpu;
compatible = arm,armv8;
reg = 0x0 0x1;
enable-method = spin-table;
cpu-release-addr = 0x0 0x8000fff8;
next-level-cache = L2_0;
};
(...)
It's not the same addres for what I can tell,
CONFIG_SYS_SDRAM_BASE + 0x03f0 = 0x83f0
but the DTS cpu-release-addr is 0x8000fff8...
Curiously we also have an ontology problem here: the DTS in
the Linux kernel does use spin tables, but there is another set of
DTS files in the ARM Trusted Firmware distribution, for the same
simulator, stating PSCI as CPU release mechanism. These are
the only ones that work properly when using ARM TF.
FWIW in the bootwrapper we inject the relevant PSCI properties into the
DTB if the bootwrapper is configured to use PSCI, and we should really
do the same for spin-table.
Given the enable-method is entirely dependent on the FW, it would be
better for FW to fill in an appropriate value (where possible), leaving
those out of the dts.
Mark.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/28] drivers/fsl-mc: Changed MC firmware loading for new boot architecture
On Tue, 24 Mar 2015 10:14:39 -0500
Rivera Jose-B46482 german.riv...@freescale.com wrote:
From: Kim Phillips [mailto:kim.phill...@freescale.com]
Sent: Monday, March 23, 2015 5:06 PM
On Mon, 23 Mar 2015 16:15:56 -0500
Rivera Jose-B46482 german.riv...@freescale.com wrote:
From: Kim Phillips [mailto:kim.phill...@freescale.com]
Sent: Monday, March 23, 2015 3:34 PM
On Mon, 23 Mar 2015 15:06:11 -0500
Rivera Jose-B46482 german.riv...@freescale.com wrote:
From: Kim Phillips [mailto:kim.phill...@freescale.com]
Sent: Thursday, March 19, 2015 12:53 PM
On Thu, 19 Mar 2015 09:45:45 -0700 York Sun
york...@freescale.com wrote:
From: J. German Rivera german.riv...@freescale.com
Changed MC firmware loading to comply with the new MC boot
architecture.
Flush D-cache hierarchy after loading MC images. Add
environment variables mcboottimeout for MC boot timeout in
milliseconds, mcmemsize for MC DRAM block size. Check MC
boot status before calling flib functions.
Can we just assign actual and/or optimal values for
'mcboottimeout'
and 'mcmemsize' instead of making them environment variables?
Having environment variables gives us the flexibility if these
values need to be changed for a given customer configuration. The
actual
what defines a 'customer configuration,' and how does that manifest
itself at u-boot boot time?
A DPL (data path layout - a device-tree-like structure describing The
DPAA2 objects created at boot time and their connections)
Is it the amount of time it takes to load (and execute?) firmare?
Yes, bigger DPLs take longer to process by the MC.
Why isn't customer-specific firmware being loaded via linux? All
u-boot needs is basic networking, pretty static
setup: fixed numbers for both memsize timeout.
This is not customer-specific firmware. What is customer-specific is
just the DPL.
In order to have networking in u-boot, we need to load the MC firmware
in u-boot, For cases in which the target system has only DPAA2-based
network interfaces.
ok, for that case, when time comes for u-boot to do some DPAA2 networking
arrives (i.e., we shouldn't have to be loading firmware at board boot-
time), then we should load a minimal DPL for the number of singular, non-
virtual/switch, etc., interfaces for that board just to tftp: this
shouldn't be a big DPL at all, and its time complexity is fixed.
It is up to the customer to decide what kind of DPL they want to have.
true, but in this case the 'customer' is the average upstream u-boot
user, presumably whose DPL is the simplest ethernet use-case for
tftp'ing kernels.
boot time of the MC and the amount of memory needed by the MC is
dependent on how big/complex is the DPL used. Also, the memory
needed by the MC needs to account for how much memory is needed
for AIOP programs, which may depend on how big/complex they are.
ok, that helps (modulo not knowing what 'DPL' is), but still, the
massive customer configurations should be being loaded via linux'
firmware loading infrastructure: u-boot should be using a static
image for u-boot's needs.
+static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr) {
+ u32 reg_gsr;
+ u32 mc_fw_boot_status;
+ unsigned long timeout_ms = get_mc_boot_timeout_ms();
+ struct mc_ccsr_registers __iomem *mc_ccsr_regs =
+MC_CCSR_BASE_ADDR;
+
+ dmb();
+ debug(Polling mc_ccsr_regs-reg_gsr ...\n);
+ assert(timeout_ms 0);
+ for (;;) {
+ udelay(1000); /* throttle polling */
does this really need to be a whole 1ms?
It is unlikely that the MC fw will boot in less than 1 ms.
is wait_for_mc() only called for the boot command, or all commands?
I see: there's a udelay(500) in mc_send_command(), which is too high,
too, IMO, but I'm not that familiar with the h/w: How long does the
shortest command take?
Can you answer this?
So, checking more frequently than 1 ms is not necessary.
yes it is, because e.g., if it takes 1.1ms we will have wasted 0.9ms
on this.
How significant is to save 0.9ms of the whole boot time?
Why waste 0.9ms of boot time when there's no need? It already takes the
boards *way* too long to boot, and now I'm understanding
mc_send_command's delay should probably be adjusted, too.
I have not heard any complain about RDB/QDS boards taking too long to boot
Due to this wasteds 0.9ms.
I'm complaining now :)
And it's not just about this singleton constant; it's about the
general approach to not optimizing the code, vis-a-vis the
mc_send_command() delay I bring up above.
Can you support your statement about LS2 RDB/QDS boards taking too long to
boot
with actual numbers? Otherwise, I will not
Re: [U-Boot] [PATCH v5 24/28] armv8/ls2085aqds: NAND boot support
On 03/23/2015 06:34 PM, Scott Wood wrote: On Fri, 2015-03-20 at 19:28 -0700, York Sun wrote: +Generage NAND image +--- +To form the NAND image, build u-boot with LS2085AQDS_NAND_defconfig. +Append u-boot-with-spl.bin after RCW image. The RCW image should +have these PBI commands + +1) CCSR 4-byte write to 0x00e00404, data=0x +2) CCSR 4-byte write to 0x00e00400, data=0x1800a000 +3) Block Copy: SRC=0x0104, SRC_ADDR=0x00c0, DEST_ADDR=0x1800a000, +BLOCK_SIZE=0x00014000 The RCW source should probably be 0x107, not 0x104. Bit 0x002 requests first/last bad block markers rather than first/second, and bit 0x001 enables ECC. Also, this documentation is LS2085A-specific (most of it will probably apply to all chips with this chassis), not RDB or QDS specific, with the exception of the RCW source ID which depends on the specific NAND chip. It would be better to put it in one place rather than duplicate it, with a table of RCW source IDs for each board. Also, you have RDB as having SRC=0x104, but that (as well as 0x107) is for a 2K-page NAND chip. RDB has a 4K-page NAND, so I think you want RCW source to be 0x111. I will try your suggestion. I use the value from the original RCW we created during bring-up. Oddly it still works if it is wrong. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] armv8: Implement CONFIG_SYS_MALLOC_F_LEN support
hi Thierry, -Original Messages- From: Thierry Reding thierry.red...@gmail.com Sent Time: 2015-03-20 19:47:49 (Friday) To: u-boot@lists.denx.de Cc: Marc Zyngier marc.zyng...@arm.com Subject: [U-Boot] [PATCH 2/6] armv8: Implement CONFIG_SYS_MALLOC_F_LEN support From: Thierry Reding tred...@nvidia.com Implement early malloc() support in a similar way as on 32-bit ARM. This is required for 64-bit Tegra SoCs that initialize from the device tree just like the earlier 32-bit SoCs. Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Marc Zyngier marc.zyng...@arm.com Signed-off-by: Thierry Reding tred...@nvidia.com --- arch/arm/include/asm/config.h | 4 arch/arm/lib/crt0_64.S| 16 ++-- 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h index be80434dee4d..7a34a0186cb1 100644 --- a/arch/arm/include/asm/config.h +++ b/arch/arm/include/asm/config.h @@ -7,10 +7,6 @@ #ifndef _ASM_CONFIG_H_ #define _ASM_CONFIG_H_ -#ifdef __aarch64__ -#define CONFIG_SYS_GENERIC_GLOBAL_DATA -#endif - #define CONFIG_LMB #define CONFIG_SYS_BOOT_RAMDISK_HIGH diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S index 77563967e517..010efdbf8f3f 100644 --- a/arch/arm/lib/crt0_64.S +++ b/arch/arm/lib/crt0_64.S @@ -62,9 +62,21 @@ ENTRY(_main) * Set up initial C runtime environment and call board_init_f(0). */ ldr x0, =(CONFIG_SYS_INIT_SP_ADDR) + mov x1, x0 sub x0, x0, #GD_SIZE/* allocate one GD above SP */ - bic sp, x0, #0xf/* 16-byte alignment for ABI compliance */ - mov x18, sp /* GD is above SP */ + bic x0, x0, #0xf/* 16-byte alignment for ABI compliance */ + mov x18, x0 /* GD is above SP */ + mov sp, x0 +clr_gd: + str xzr, [x0], #8 + cmp x0, x1 + b.loclr_gd +#if defined(CONFIG_SYS_MALLOC_F_LEN) + ldr x0, =CONFIG_SYS_MALLOC_F_LEN + sub x0, sp, x0 + str x0, [x18, #GD_MALLOC_BASE] sp should substract CONFIG_SYS_MALLOC_F_LEN also. Actually my previous patch did the same work, but got no reply. +#endif +3: mov x0, #0 bl board_init_f -- 2.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] armv8/mmu: Clean up TCR programming
-Original Messages- From: Thierry Reding thierry.red...@gmail.com Sent Time: 2015-03-20 19:47:50 (Friday) To: u-boot@lists.denx.de Cc: Marc Zyngier marc.zyng...@arm.com Subject: [U-Boot] [PATCH 3/6] armv8/mmu: Clean up TCR programming From: Thierry Reding tred...@nvidia.com Use the inner shareable attribute for memory, which makes more sense considering that this code is called when caches are being enabled. While at it, fix the values for the shareability attribute field to match the documentation. Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Marc Zyngier marc.zyng...@arm.com Signed-off-by: Thierry Reding tred...@nvidia.com --- arch/arm/include/asm/armv8/mmu.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h index 4b9cb5296572..6d42f5533a74 100644 --- a/arch/arm/include/asm/armv8/mmu.h +++ b/arch/arm/include/asm/armv8/mmu.h @@ -93,8 +93,8 @@ #define TCR_ORGN_WBNWA (3 10) #define TCR_ORGN_MASK(3 10) #define TCR_SHARED_NON (0 12) -#define TCR_SHARED_OUTER (1 12) -#define TCR_SHARED_INNER (2 12) +#define TCR_SHARED_OUTER (2 12) +#define TCR_SHARED_INNER (3 12) #define TCR_TG0_4K (0 14) #define TCR_TG0_64K (1 14) #define TCR_TG0_16K (2 14) @@ -102,9 +102,9 @@ #define TCR_EL2_IPS_BITS (3 16) /* 42 bits physical address */ #define TCR_EL3_IPS_BITS (3 16) /* 42 bits physical address */ -/* PTWs cacheable, inner/outer WBWA and non-shareable */ +/* PTWs cacheable, inner/outer WBWA and inner shareable */ #define TCR_FLAGS(TCR_TG0_64K | \ - TCR_SHARED_NON |\ + TCR_SHARED_INNER | \ TCR_ORGN_WBWA | \ TCR_IRGN_WBWA | \ TCR_T0SZ(VA_BITS)) -- 2.3.2 Acked-by: david.feng feng...@phytium.com.cn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] armv8/cache: Fix page table creation
-Original Messages-
From: Thierry Reding thierry.red...@gmail.com
Sent Time: 2015-03-20 19:47:48 (Friday)
To: u-boot@lists.denx.de
Cc: Marc Zyngier marc.zyng...@arm.com
Subject: [U-Boot] [PATCH 1/6] armv8/cache: Fix page table creation
From: Thierry Reding tred...@nvidia.com
While generating the page tables, a running integer index is shifted by
SECTION_SHIFT (29) and causes overflow for any integer bigger than 7.
The page tables therefore alias to the same 8 sections and cause U-Boot
to hang once the MMU is enabled.
Fix this by making the index a 64-bit unsigned integer and so avoid the
overflow.
Acked-by: david.feng feng...@phytium.com.cn
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Marc Zyngier marc.zyng...@arm.com
Signed-off-by: Thierry Reding tred...@nvidia.com
---
arch/arm/cpu/armv8/cache_v8.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index c5ec5297cd39..254a629a3b8c 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -25,9 +25,9 @@ void set_pgtable_section(u64 *page_table, u64 index, u64
section,
/* to activate the MMU we need to set up virtual memory */
static void mmu_setup(void)
{
- int i, j, el;
bd_t *bd = gd-bd;
- u64 *page_table = (u64 *)gd-arch.tlb_addr;
+ u64 *page_table = (u64 *)gd-arch.tlb_addr, i, j;
+ int el;
/* Setup an identity-mapping for all spaces */
for (i = 0; i (PGTABLE_SIZE 3); i++) {
--
2.3.2
A previous patch did the same work, but got no reply.
Yours.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Vexpress64: Fix the compiling error when CONFIG_ARMV8_MULTIENTRY defined
hi Linus,
-Original Messages-
From: Linus Walleij linus.wall...@linaro.org
Sent Time: 2015-03-20 17:39:48 (Friday)
To: FengHua feng...@phytium.com.cn
Cc: U-Boot Mailing List u-boot@lists.denx.de, albert.u.boot
albert.u.b...@aribaud.net
Subject: Re: Re: [PATCH] Vexpress64: Fix the compiling error when
CONFIG_ARMV8_MULTIENTRY defined
On Wed, Mar 11, 2015 at 2:08 PM, FengHua feng...@phytium.com.cn wrote:
(...)
As asked earlier: how can I test this with FVP or the base model?
I usually use Foundation Model.
OK... That is the same as the FVP I'm using I guess:
$ Foundation_v8pkg/models/Linux64_GCC-4.1/Foundation_v8 --version
ARM V8 Foundation Model r0p0 (model build 9.0.24)
Copyright 2013 ARM Limited.
All Rights Reserved.
Correct?
Yes
I'm very interested in doing this as I guess it involves starting U-Boot
at EL3 on bare metal and I really want to try this.
+/* SMP Spin Table Definitions */
+#ifdef CONFIG_BASE_FVP
+#define CPU_RELEASE_ADDR (CONFIG_SYS_SDRAM_BASE +
0x03f0)
+#else
+#define CPU_RELEASE_ADDR (CONFIG_SYS_SDRAM_BASE + 0x7fff0)
+#endif
Where are these address defines coming from?
It's just hard coded and should be the same value with that in DTS.
I look in the DTS from the Linux kernel:
arch/arm64/boot/dts/arm/foundation-v8.dts:
cpu@0 {
device_type = cpu;
compatible = arm,armv8;
reg = 0x0 0x0;
enable-method = spin-table;
cpu-release-addr = 0x0 0x8000fff8;
next-level-cache = L2_0;
};
cpu@1 {
device_type = cpu;
compatible = arm,armv8;
reg = 0x0 0x1;
enable-method = spin-table;
cpu-release-addr = 0x0 0x8000fff8;
next-level-cache = L2_0;
};
(...)
It's not the same addres for what I can tell,
CONFIG_SYS_SDRAM_BASE + 0x03f0 = 0x83f0
but the DTS cpu-release-addr is 0x8000fff8...
Curiously we also have an ontology problem here: the DTS in
the Linux kernel does use spin tables, but there is another set of
DTS files in the ARM Trusted Firmware distribution, for the same
simulator, stating PSCI as CPU release mechanism. These are
the only ones that work properly when using ARM TF.
(Well obviously you don't use these...)
PSCI is prefered by Linux.
Do these spin tables exist in a standard ARM FVP or base model?
I get the impression that a secondary operating system is being booted
on the secondary CPU at one of these addresses, but why is it running
at these addresses specifically, and is that something coming with these
simulators, or is it some image that is loaded on the side, that the
community does not have access to?
PSCI is not implemented in uboot-armv8.
Nope. But it is implemented in ARM Trusted Firmware for ARMv8.
ARM TF install the PSCI handlers before U-Boot is executed.
If booting u-boot on bare-metal
only spin table can be used. All we do is describing booting
method(spin table) and cpu release
address in DTS. Linux kernel get cpu release address from DTS also.
Yep, I want to try this method...
I just cannot even get U-Boot to run on the foundation model.
I alter CONFIG_SYS_TEXT_BASE to 0x0:
#define CONFIG_SYS_TEXT_BASE0x
Then I run the simulator like so:
Foundation_v8pkg/models/Linux64_GCC-4.1/Foundation_v8 \
--cores=4 \
--no-secure-memory\
--visualization \
--gicv3 \
--data=u-boot-fvp-semi.bin@0x
Do you do this as well? Or how do you kick your simulator to
run U-Boot on bare metal?
CONFIG_SYS_TEXT_BASE should be defined as 0x8000.
The reset PC value is 0x8000 on Foundation Model.
and I use --image=u-boot.bin instead of --data=
Yours,
David.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: pinmux: fix FUNCMUX_NDFLASH_KBC_8_BIT
On 03/24/2015 06:29 AM, Marcel Ziswiler wrote: From: Lucas Stach d...@lynxeye.de Even the 8-bit case needs KBCB configured, as pin D7 is located in this pingroup. Also pingroup ATC seems to come out of reset with config set to NAND, so we need to explictly configure some other function to this group in order to avoid clashing settings. I would rather not touch ATC like this; see below. diff --git a/arch/arm/mach-tegra/tegra20/funcmux.c b/arch/arm/mach-tegra/tegra20/funcmux.c Note that this will conflict with: 09f455dca749 ARM: tegra: collect SoC sources into mach-tegra ... which moved that file. @@ -252,17 +252,25 @@ int funcmux_select(enum periph_id id, int config) ... case FUNCMUX_NDFLASH_KBC_8_BIT: ... + /* +* configure pingroup ATC to something unrelated to +* avoid ATC overriding KBC +*/ + pinmux_set_func(PMUX_PINGRP_ATC, PMUX_FUNC_GMI); What if ATC is actually used for some purpose other than GMI? This will corrupt the pinmux for that pingroup, and prevent the other peripheral from working. For example, PERIPH_ID_SDMMC4/FUNCMUX_SDMMC4_ATC_ATD_8BIT actively uses ATC, and this change might break it if both are used together on one board. The best approach is to simply not use funcmux at all, but rather program the entire pinmux from a table. That guarantees no conflicts. Boards using later SoCs take this approach. Alternatively, have the board code (rather than funcmux) select some other value for ATC. This allows the board code to select the exact correct value for that pingroup once (thus avoiding multiple changes to the pinmux for that pingroup, which could cause glitches), and guarantees that the common code will never corrupt that setting. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci-hcd: fix warnings on 64-bit builds
On Tuesday, March 24, 2015 at 12:36:55 AM, Rob Herring wrote: On Fri, Mar 20, 2015 at 8:19 AM, Marek Vasut ma...@denx.de wrote: On Tuesday, March 17, 2015 at 09:46:37 PM, Rob Herring wrote: Change addresses to unsigned long to be compatible with 64-bit builds. Regardless of fixing warnings, the device is still only 32-bit capable. Signed-off-by: Rob Herring r...@kernel.org Cc: Marek Vasut ma...@denx.de --- drivers/usb/host/ehci-hcd.c | 82 ++--- 1 file changed, 41 insertions(+), 41 deletions(-) Hi, I will handle those patches in a couple of days. I got similar fix from Thierry today in a patchset, this is the subject: [PATCH 11/13] usb: ehci-hcd: Build warning fixes for 64-bit I would obviously like to pick Rob's one, since it came first, but I will need to check if they're really the same. Moreover, shall I pick this for the current release or is it OK to apply for the next one ? For me, after the release is fine. Thierry may feel otherwise. I'm fine either way, so Thierry, what is your feeling please ? 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 3/3] Kconfig: i2c: add entry for driver-model software i2c
Hi.
2015-03-10 19:30 GMT+09:00 Przemyslaw Marczak p.marc...@samsung.com:
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Masahiro Yamada yamad...@jp.panasonic.com
I am no longer working for Panasonic.
The old email address will get unavailable at the end of March.
Going forward, please use my new address, yamada.masah...@socionext.com
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 0a52ed9..dd7eb3c 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -13,6 +13,49 @@ config DM_I2C_COMPAT
to convert all code for a board in a single commit. It should not
be enabled for any board in an official release.
+config DM_I2C_SOFT
+ bool Enable Driver Model for Software I2C Driver
+ depends on DM_I2C
+ help
+ Enable the i2c bus driver emulation by using GPIO.
Very nice!
+ The bus configuration is given by the device-tree, like below.
+
+ /* First, define the alias number to have continuous bus numbering
*/
+ aliases {
+ [...]
+ i2c5 = /i2c@1350;
+ i2c6 = /soft-i2c@1;
+ [...]
+ }
This description is not specific to this CONFIG option.
The relation between the aliases node and the sequence number
is well-documented in doc/driver-model/README.txt.
Should we repeat it here?
+ /* And next define the basic bus attributes */
+ soft-i2c@1 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = soft-i2c;
+ clock-frequency = 5;
+ /* Define the proper GPIO pins */
+ clock-pin = gpa0 0 GPIO_ACTIVE_HIGH;
+ data-pin = gpa0 1 GPIO_ACTIVE_HIGH;
+
+ /* Optionally, define some driver node (bus child) */
+ somedev@0x44 {
+ compatible = somedev;
+ reg = 0x44;
+ [...]
+ };
+ }
This is binding information, right?
Stuff like that is usually documented in a separate text file.
In Linux, Documentation/devicetree/bindings/i2c/
In U-boot, doc/device-tree-bindings/i2c/
+ The device can be accessed by the i2c command:
+ # i2c dev 8 (bus number set by alias)
+ # i2c probe 0x44(address is optionally)
+ # i2c md 0x44 0x0 (dump dev registers at address 0x0)
+ # Valid chip addresses: 0x44 (success!)
+ ...
This is the usage of i2c command.
It is not specific to this option, either.
+ Driving the bus lines is done by dm gpio calls in the preprocessor
+ macros. Each, can be redefined by the user.
+
config SYS_I2C_UNIPHIER
bool UniPhier I2C driver
depends on ARCH_UNIPHIER DM_I2C
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] usb: dwc2: use phys_to_bus/bus_to_phys
Use of these APIs is required on the Raspberry Pi. With this change, USB on RPi1 should be more reliable, and USB on the RPi2 will start working. Signed-off-by: Stephen Warren swar...@wwwdotorg.org --- We likely should enable use of these functions for mbox, SDHCI, and LCD display too. However, I haven't validated those yet. --- drivers/usb/host/dwc2.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index 5f4ca7abf7bf..8f7c269dd1a5 100644 --- a/drivers/usb/host/dwc2.c +++ b/drivers/usb/host/dwc2.c @@ -9,6 +9,7 @@ #include errno.h #include usb.h #include malloc.h +#include phys2bus.h #include usbroothubdes.h #include asm/io.h @@ -795,7 +796,8 @@ int chunk_msg(struct usb_device *dev, unsigned long pipe, int *pid, int in, if (!in) memcpy(aligned_buffer, (char *)buffer + done, len); - writel((uint32_t)aligned_buffer, hc_regs-hcdma); + writel(phys_to_bus((unsigned long)aligned_buffer), + hc_regs-hcdma); /* Set host channel enable after all other setup is complete. */ clrsetbits_le32(hc_regs-hcchar, DWC2_HCCHAR_MULTICNT_MASK | -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] m68k: remove arch/m68k/lib/board.c
Hi Angelo, 2015-03-17 15:55 GMT+09:00 Angelo Dureghello ang...@sysam.it: On 17/03/2015 04:35, Masahiro Yamada wrote: All the M68000 boards have switched to Generic Board. This file is no longer necessary. Hi Masahiro, thanks. Afaik, me and Alison converted and tested actually only 2 boards (adding #define CONFIG_SYS_GENERIC_BOARD inside /include/configs/...) Is this a problem ? Afaik, the user going to build the board will get a warning that he needs to switch to generic board. So the same user will be the tester that all works. Correct ? As a rule of generic board, people are supposed to do run-test and then send a patch. BTW, M68K is the last architecture that adopts per-board linker script. M68K should switch to per-soc linker scripts like the other architecures. It means all the followings should be merged into the single linker script arch/m68k/cpu/u-boot.lds. board/freescale/m52277evb/u-boot.lds board/freescale/m5235evb/u-boot.lds board/cobra5272/u-boot.lds board/BuS/eb_cpu5282/u-boot.lds board/freescale/m5208evbe/u-boot.lds board/freescale/m5249evb/u-boot.lds board/freescale/m5253demo/u-boot.lds board/freescale/m5272c3/u-boot.lds board/freescale/m5275evb/u-boot.lds board/freescale/m5282evb/u-boot.lds board/sysam/amcore/u-boot.lds board/astro/mcf5373l/u-boot.lds board/freescale/m53017evb/u-boot.lds board/freescale/m5329evb/u-boot.lds board/freescale/m5373evb/u-boot.lds board/freescale/m54418twr/u-boot.lds board/freescale/m54451evb/u-boot.lds board/freescale/m54455evb/u-boot.lds board/freescale/m547xevb/u-boot.lds board/freescale/m548xevb/u-boot.lds Is this possible for you? (or for someone else?) If there is no volunteer, it would be much easier to remove all the M68K boards except the two you and Alison can maintain. Maintain or Remove! -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: at91: at91sam9n12ek: save the environment to a fat file in MMC card
Hi Josh,
On 03/24/2015 04:10 PM, Josh Wu wrote:
Insteading in mmc's raw sectors, this patch will save the environment
in a fat file (uboot.env) in mmc card's first FAT patition.
Signed-off-by: Josh Wu josh...@atmel.com
Thanks for your patch.
Acked-by: Bo Shen voice.s...@atmel.com
---
include/configs/at91sam9n12ek.h | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/include/configs/at91sam9n12ek.h b/include/configs/at91sam9n12ek.h
index f02fce9..94ba37c 100644
--- a/include/configs/at91sam9n12ek.h
+++ b/include/configs/at91sam9n12ek.h
@@ -201,11 +201,12 @@
#else /* CONFIG_SYS_USE_MMC */
/* bootstrap + u-boot + env + linux in mmc */
-#define CONFIG_ENV_IS_IN_MMC
-/* For FAT system, most cases it should be in the reserved sector */
-#define CONFIG_ENV_OFFSET 0x2000
-#define CONFIG_ENV_SIZE0x1000
-#define CONFIG_SYS_MMC_ENV_DEV 0
+#define CONFIG_ENV_IS_IN_FAT
+#define CONFIG_FAT_WRITE
+#define FAT_ENV_INTERFACE mmc
+#define FAT_ENV_FILE uboot.env
+#define FAT_ENV_DEVICE_AND_PART0
+#define CONFIG_ENV_SIZE0x4000
#define CONFIG_BOOTCOMMAND\
setenv bootargs ${console} ${mtdparts} ${bootargs_mmc}; \
fatload mmc 0:1 0x2100 dtb; \
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ARM: tegra: Prepare for 64-bit support
Hi. 2015-03-21 1:24 GMT+09:00 Stephen Warren swar...@wwwdotorg.org: On 03/20/2015 06:24 AM, Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com Move various selects from the TEGRA symbol to the symbols for 32-bit Tegra boards. This is necessary because these settings do not extend to U-Boot for 64-bit Tegra SoCs. Also tie the private libgcc build to SPL, it isn't needed on 64-bit Tegra. I vaguely recall Masahiro enabling SPL for all Tegra builds recently for some reason... Yes. I enabled the private library for the U-boot proper of Tegra as well as SPL. This change happened when we stitched into the single .config configuration as CONFIG_SPL_BUILD no longer appears in Kconfig. This thread: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/212545/focus=212771 As for Kconfig side, this patch looks good to me. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/13] ARM: UniPhier: enable CONFIG_SPL_DM with some clean-ups
Hi Simon, 2015-03-24 7:47 GMT+09:00 Simon Glass s...@chromium.org: Hi Masahiro, On 23 March 2015 at 09:19, Masahiro Yamada yamada.masah...@socionext.com wrote: 2015-03-23 0:07 GMT+09:00 Masahiro Yamada yamada.masah...@socionext.com: Masahiro Yamada (13): ARM: UniPhier: include PH1-LD4 Makefile from PH1-sLD8 ARM: UniPhier: move platform devices to SPL ARM: UniPhier: move UART pin settings to SPL ARM: UniPhier: enable CONFIG_PANIC_HANG ARM: UniPhier: enable Driver Model and UART on SPL ARM: UniPhier: use CONFIG_SPL_STACK to define SPL stack pointer ARM: UniPhier: add CONFIG_SPL_MAX_FOOTPRINT ARM: UniPhier: move init stack area just below TEXT_BASE ARM: UniPhier: add empty lowlevel_init to U-boot proper ARM: UniPhier: fix typos in comments ARM: UniPhier: optimize kicking secondary CPUs code ARM: UniPhier: disable L2 cache by lowlevel_init of U-Boot proper ARM: UniPhier: remove unnecessary ifdef conditional Applied to u-boot-uniphier/master. Great! Also you could look at my series here: http://lists.denx.de/pipermail/u-boot/2015-February/206581.html The device tree method is not good, I think we need a tool that chops the device tree down automatically for SPL. But otherwise, the support is there for device tree in SPL. Amazing! It is very nice that OF_CONTROL can be available with such small memory footprint. I can use 64KB for SPL on my boards, so it will surely work for me. I will check it out! Thanks for your hard work all the time! -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mii: add read-modify-write option to mii command
Hi Tim,
On Fri, Feb 27, 2015 at 8:25 AM, Tim James tim.ja...@macltd.com wrote:
When accessing PHY registers it is often desirable to only update
selected bits, so it is necessary to first read the current value
before writing back an modified value with the relevant bits
updated.
To simplify this and to allow such operations to be incorporated
into simple shell scripts propose adding a 'modify' option to the
existing mii command, which takes a mask indicating the bits to
be updated in addition to a data value containing the new bits,
ie, updated = (data mask) | (current ~mask).
Signed-off-by: Tim James tim.ja...@macltd.com
Cc: Nobuhiro Iwamatsu iwama...@nigauri.org
Looks reasonable, but please run scripts/checkpatch.pl against your patch
and fix the failures.
--- a/common/cmd_mii.c
+++ b/common/cmd_mii.c
@@ -249,6 +249,7 @@
static uint last_addr_hi;
static uint last_reg_lo;
static uint last_reg_hi;
+static uint last_mask;
static void extract_range(
char * input,
@@ -272,7 +273,7 @@
charop[2];
unsigned char addrlo, addrhi, reglo, reghi;
unsigned char addr, reg;
- unsigned short data;
+ unsigned short data, mask;
int rcode = 0;
const char *devname;
@@ -294,6 +295,7 @@
reglo = last_reg_lo;
reghi = last_reg_hi;
data = last_data;
+ mask = last_mask;
if ((flag CMD_FLAG_REPEAT) == 0) {
op[0] = argv[1][0];
@@ -308,6 +310,8 @@
extract_range(argv[3], reglo, reghi);
if (argc = 5)
data = simple_strtoul (argv[4], NULL, 16);
+ if (argc = 6)
+ mask = simple_strtoul (argv[5], NULL, 16);
}
/* use current device */
@@ -375,6 +379,24 @@
}
}
}
+ } else if (op[0] == 'm') {
+ for (addr = addrlo; addr = addrhi; addr++) {
+ for (reg = reglo; reg = reghi; reg++) {
+ unsigned short current = 0;
+ if (miiphy_read (devname, addr, reg,
current) != 0) {
+ printf(Error reading from the
PHY addr=%02x reg=%02x\n,
+ addr, reg);
+ rcode = 1;
+ } else {
+ unsigned short updated = (data
mask) | (current ~mask);
+ if (miiphy_write (devname, addr,
reg, 0x updated) != 0) {
+ printf(Error writing to
the PHY addr=%02x reg=%02x\n,
+ addr, reg);
+ rcode = 1;
+ }
+ }
+ }
+ }
} else if (strncmp(op, du, 2) == 0) {
ushort regs[6];
int ok = 1;
@@ -417,6 +439,7 @@
last_reg_lo = reglo;
last_reg_hi = reghi;
last_data= data;
+ last_mask= mask;
return rcode;
}
@@ -424,13 +447,15 @@
/***/
U_BOOT_CMD(
- mii,5, 1, do_mii,
+ mii, 6, 1, do_mii,
MII utility commands,
- device - list available devices\n
- mii device devname - set current device\n
- mii info addr - display MII PHY info\n
- mii read addr reg- read MII PHY addr register
reg\n
- mii write addr reg data - write MII PHY addr register
reg\n
- mii dump addr reg- pretty-print addr reg (0-5
only)\n
+ device - list available devices\n
+ mii device devname - set current device\n
+ mii info addr - display MII PHY info\n
+ mii read addr reg - read MII PHY addr
register reg\n
+ mii write addr reg data- write MII PHY addr
register reg\n
+ mii modify addr reg data mask - modify MII PHY addr
register reg\n
+ updating bits identified
in mask\n
+ mii dump addr reg - pretty-print addr
reg (0-5 only)\n
Addr and/or reg may be ranges, e.g. 2-7.
);
--
Scanned by iCritical.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Add support for stm32f429-discovery board
Hi Kamil, I tested this patch-set in STM32 Discovery board. After applied this patch-set on latest u-boot, I could not see the normal u-boot log. I saw broken console log. I used the USART1 port (pa9, pa10 gpio pin). Could you give me a tip to resolve this issue? Best Regards, Chanwoo Choi 2015년 3월 1일 일요일, Kamil Lulkore...@wp.pl님이 작성한 메시지: The following patches implement basic support for the ARMv7-M microcontroller architecture. Additionally, stm32f429-discovery board support is added with tested ability to boot uClinux from the embedded Flash memory. Kamil Lulko (4): ARM: Add ARMv7-M support ARMv7M: Add STM32F4 support stm32f4: Add serial driver stm32f4: Add support for stm32f429-discovery board arch/arm/Kconfig | 9 + arch/arm/cpu/armv7m/Makefile | 11 + arch/arm/cpu/armv7m/config.mk | 8 + arch/arm/cpu/armv7m/cpu.c | 35 +++ arch/arm/cpu/armv7m/start.S| 15 ++ arch/arm/cpu/armv7m/stm32f4/Makefile | 11 + arch/arm/cpu/armv7m/stm32f4/clock.c| 209 +++ arch/arm/cpu/armv7m/stm32f4/flash.c| 143 ++ arch/arm/cpu/armv7m/stm32f4/soc.c | 37 +++ arch/arm/cpu/armv7m/stm32f4/timer.c| 118 + arch/arm/include/asm/arch-stm32f4/fmc.h| 75 ++ arch/arm/include/asm/arch-stm32f4/gpio.h | 116 + arch/arm/include/asm/arch-stm32f4/stm32.h | 108 arch/arm/include/asm/armv7m.h | 60 + arch/arm/lib/Makefile | 8 +- arch/arm/lib/crt0.S| 30 +++ arch/arm/lib/interrupts_m.c| 95 +++ arch/arm/lib/relocate.S| 13 + arch/arm/lib/vectors_m.S | 57 board/st/stm32f429-discovery/Kconfig | 19 ++ board/st/stm32f429-discovery/MAINTAINERS | 6 + board/st/stm32f429-discovery/Makefile | 12 + board/st/stm32f429-discovery/led.c | 35 +++ board/st/stm32f429-discovery/stm32f429-discovery.c | 288 + configs/stm32f429-discovery_defconfig | 2 + drivers/gpio/Makefile | 1 + drivers/gpio/stm32_gpio.c | 199 ++ drivers/serial/Makefile| 1 + drivers/serial/serial.c| 2 + drivers/serial/serial_stm32.c | 117 + include/configs/stm32f429-discovery.h | 106 include/flash.h| 2 + 32 files changed, 1946 insertions(+), 2 deletions(-) create mode 100644 arch/arm/cpu/armv7m/Makefile create mode 100644 arch/arm/cpu/armv7m/config.mk create mode 100644 arch/arm/cpu/armv7m/cpu.c create mode 100644 arch/arm/cpu/armv7m/start.S create mode 100644 arch/arm/cpu/armv7m/stm32f4/Makefile create mode 100644 arch/arm/cpu/armv7m/stm32f4/clock.c create mode 100644 arch/arm/cpu/armv7m/stm32f4/flash.c create mode 100644 arch/arm/cpu/armv7m/stm32f4/soc.c create mode 100644 arch/arm/cpu/armv7m/stm32f4/timer.c create mode 100644 arch/arm/include/asm/arch-stm32f4/fmc.h create mode 100644 arch/arm/include/asm/arch-stm32f4/gpio.h create mode 100644 arch/arm/include/asm/arch-stm32f4/stm32.h create mode 100644 arch/arm/include/asm/armv7m.h create mode 100644 arch/arm/lib/interrupts_m.c create mode 100644 arch/arm/lib/vectors_m.S create mode 100644 board/st/stm32f429-discovery/Kconfig create mode 100644 board/st/stm32f429-discovery/MAINTAINERS create mode 100644 board/st/stm32f429-discovery/Makefile create mode 100644 board/st/stm32f429-discovery/led.c create mode 100644 board/st/stm32f429-discovery/stm32f429-discovery.c create mode 100644 configs/stm32f429-discovery_defconfig create mode 100644 drivers/gpio/stm32_gpio.c create mode 100644 drivers/serial/serial_stm32.c create mode 100644 include/configs/stm32f429-discovery.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de javascript:; http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5 v1] dm: ls1021a: dts: Change address_cells and size_cells from 2 to 1
On 24 March 2015 at 07:16, Haikun Wang haikun.w...@freescale.com wrote: From: haikun haikun.w...@freescale.com Change address_cells and size_cells of root node and 'soc' node from 2 to 1. We backport ls1021a device tree source files from kernel to u-boot. Kernel files set address_cells and size_cells to 2 in order to access more than 4GB space. But we don't have this requirement now and u-boot fdtdec_get_xxx interfaces can't support property whose size is 'u64' completely. So make this change. Or we could add that feature if you like. 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/5 v1] dm: arm: Bring in skeleton64 device tree file from Linux
On 24 March 2015 at 07:12, Haikun Wang haikun.w...@freescale.com wrote: Backport of kernel commits: 7c14f6c719de092d69c81877786e83ce7ae1a860 35faad2a1563b3d4dc983a82ac41033fe053870c Signed-off-by: Haikun Wang haikun.w...@freescale.com --- arch/arm/dts/skeleton64.dtsi | 13 + 1 file changed, 13 insertions(+) create mode 100644 arch/arm/dts/skeleton64.dtsi 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 2/5] dm: ls1021a: Bring in ls1021a dts files from linux kernel
Hi, On 24 March 2015 at 07:13, Haikun Wang haikun.w...@freescale.com wrote: From: haikun haikun.w...@freescale.com Bring in required device tree files for ls1021a from Linux. These are initially unchanged and have a number of pieces not needed by U-Boot. Signed-off-by: Haikun Wang haikun.w...@freescale.com --- arch/arm/dts/Makefile| 3 + arch/arm/dts/ls1021a-qds.dts | 201 +++ arch/arm/dts/ls1021a-twr.dts | 88 ++ arch/arm/dts/ls1021a.dtsi| 370 +++ 4 files changed, 662 insertions(+) create mode 100644 arch/arm/dts/ls1021a-qds.dts create mode 100644 arch/arm/dts/ls1021a-twr.dts create mode 100644 arch/arm/dts/ls1021a.dtsi diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index cbe5b86..67b821a 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -54,6 +54,9 @@ dtb-$(CONFIG_SOCFPGA) += \ socfpga_cyclone5_socdk.dtb \ socfpga_cyclone5_socrates.dtb +dtb-$(CONFIG_TARGET_LS1021AQDS) += ls1021a-qds.dtb +dtb-$(CONFIG_TARGET_LS1021ATWR) += ls1021a-twr.dtb Can we avoid having particular targets here? Can you use a broader architecture definition as elsewhere in the file? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config: peach: Correct memory layout environment settings
Hi Sjoerd, On 24 March 2015 at 01:46, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: Hey Simon, On Mon, 2015-03-23 at 15:04 -0600, Simon Glass wrote: Hi Sjoerd, On 12 March 2015 at 15:33, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: The peach boards have their SDRAM start address at 0x2000 instead of 0x4000 which seems common for all other exynos5 based boards. This means the layout set in exynos5-common.h causes the kernel be loaded more then 128MB (at 0x4200) away from memory start which breaks booting kernels with CONFIG_AUTO_ZRELADDR Define a custom MEM_LAYOUT_ENV_SETTINGS for both peach boards which uses the same offsets from start of memory as the common exynos5 settings. This fixes booting via bootz and PXE snip It would be great if we could have this in the device tree. I haven't merged this patch yet, but it goes some of the way: http://patchwork.ozlabs.org/patch/402714/ I think it would be awesome to have this via device tree as well as that would be another step closer to allowing one u-boot binary for a group of boards. However, that's clearly much more work. So for the short term (and ideally the coming release) i'd quite prefer this minimal change to go in to unbreak bootz and PXE on these boards. OK. Reviewed-by: Simon Glass s...@chromium.org Who is going to apply this? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] ARM: at91: atmel_nand: Support flash based BBT
Hi, David Thanks for the patch. On 3/20/2015 5:52 PM, David Dueck wrote: Add support for on-flash bad block table. This makes U-Boot handle an existing BBT correctly. Signed-off-by: David Dueck davidcdu...@googlemail.com Reviewed-by: Boris BREZILLON boris.brezil...@free-electrons.com CC: Boris BREZILLON boris.brezil...@free-electrons.com CC: Josh Wu josh...@atmel.com CC: Andreas Bießmann andreas.de...@googlemail.com CC: Scott Wood scottw...@freescale.com Acked-by: Josh Wu josh...@atmel.com Best Regards, Josh Wu --- Changes since v1: - improve commit message - add Reviewed-by tag drivers/mtd/nand/atmel_nand.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c index b16e3aa..a2016e7 100644 --- a/drivers/mtd/nand/atmel_nand.c +++ b/drivers/mtd/nand/atmel_nand.c @@ -1456,6 +1456,9 @@ int board_nand_init(struct nand_chip *nand) nand-dev_ready = at91_nand_wait_ready; #endif nand-chip_delay = 20; +#ifdef CONFIG_SYS_NAND_USE_FLASH_BBT + nand-bbt_options |= NAND_BBT_USE_FLASH; +#endif #ifdef CONFIG_ATMEL_NAND_HWECC #ifdef CONFIG_ATMEL_NAND_HW_PMECC @@ -1522,6 +1525,9 @@ int atmel_nand_chip_init(int devnum, ulong base_addr) nand-dev_ready = at91_nand_ready; #endif nand-chip_delay = 75; +#ifdef CONFIG_SYS_NAND_USE_FLASH_BBT + nand-bbt_options |= NAND_BBT_USE_FLASH; +#endif ret = nand_scan_ident(mtd, CONFIG_SYS_NAND_MAX_CHIPS, NULL); if (ret) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: at91: at91sam9n12ek: save the environment to a fat file in MMC card
Hi Josh,
On 03/24/2015 05:07 PM, Josh Wu wrote:
Insteading in mmc's raw sectors, this patch will save the environment
in a fat file (uboot.env) in mmc card's first FAT patition by default.
If you want to save in mmc's raw sectors, you only need to define
CONFIG_ENV_IS_IN_MMC.
Signed-off-by: Josh Wu josh...@atmel.com
Thanks for your patch. I think this one is better than v1.
Acked-by: Bo Shen voice.s...@atmel.com
---
Changes in v2:
- not remove the code to save env in mmc's raw sectors.
- we can define CONFIG_ENV_IS_IN_MMC to enable raw sectors saving.
include/configs/at91sam9n12ek.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/configs/at91sam9n12ek.h b/include/configs/at91sam9n12ek.h
index f02fce9..058e0e4 100644
--- a/include/configs/at91sam9n12ek.h
+++ b/include/configs/at91sam9n12ek.h
@@ -201,11 +201,22 @@
#else /* CONFIG_SYS_USE_MMC */
/* bootstrap + u-boot + env + linux in mmc */
-#define CONFIG_ENV_IS_IN_MMC
-/* For FAT system, most cases it should be in the reserved sector */
+
+#ifdef CONFIG_ENV_IS_IN_MMC
+/* Use raw reserved sectors to save environment */
#define CONFIG_ENV_OFFSET 0x2000
#define CONFIG_ENV_SIZE 0x1000
#define CONFIG_SYS_MMC_ENV_DEV0
+#else
+/* Use file in FAT file to save environment */
+#define CONFIG_ENV_IS_IN_FAT
+#define CONFIG_FAT_WRITE
+#define FAT_ENV_INTERFACE mmc
+#define FAT_ENV_FILE uboot.env
+#define FAT_ENV_DEVICE_AND_PART0
+#define CONFIG_ENV_SIZE0x4000
+#endif
+
#define CONFIG_BOOTCOMMAND\
setenv bootargs ${console} ${mtdparts} ${bootargs_mmc}; \
fatload mmc 0:1 0x2100 dtb; \
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: mx5: Add support for USB armory board
On Tue, Mar 24, 2015 at 4:25 PM, Vagrant Cascadian vagr...@debian.org wrote: Unfortunately, this fails to build with numerous errors such as: Heh. I was just about to go investigate that. ... +#include config_distro_bootcmd.h + #define MEM_LAYOUT_ENV_SETTINGS \ This section works for me. I'd like to propose only setting bootargs when the default action is kicking in to allow for a different root device, or root device discovery from an initramfs, or boot scripts, etc... Something along these lines (untested): This section also untested by me. -- GDB has a 'break' feature; why doesn't it have 'fix' too? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] ARM: bcm2835: implement phys_to_bus/bus_to_phys
The BCM283[56] contain both a L1 and L2 cache between the GPU (a/k/a
VideoCore CPU?) and DRAM. DMA-capable peripherals can also optionally
access DRAM via this same L2 cache (although they always bypass the L1
cache). Peripherals select whether to use or bypass the cache via the
top two bits of the bus address.
An IOMMU exists between the ARM CPU and the rest of the system. This
controls whether the ARM CPU's accesses use or bypass the L1 and/or L2
cache. This IOMMU is configured/controlled exclusively by the VideoCore
CPU.
In order for DRAM accesses made by the ARM core to be coherent with
accesses made by other DMA peripherals, we must program a bus address
into those peripherals that causes the peripheral's accesses to use the
same set of caches that the ARM core's accesses will use.
On the RPi1, the VideoCore firmware sets up the IOMMU to enable use of
the L2 cache. This corresponds to addresses based at 0x4000.
On the RPi2, the VideoCore firmware sets up the IOMMU to disable use of
the L2 cache. This corresponds to addresses based at 0xc000.
This patch implements U-Boot's phys_to_bus/bus_to_phys APIs according
to those rules.
For full details of this setup, please see Dom Cobley's description at:
http://lists.denx.de/pipermail/u-boot/2015-March/208201.html
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/215038
https://www.mail-archive.com/u-boot@lists.denx.de/msg166568.html
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
arch/arm/cpu/arm1176/bcm2835/Kconfig| 3 +++
arch/arm/cpu/arm1176/bcm2835/Makefile | 1 +
arch/arm/cpu/arm1176/bcm2835/phys2bus.c | 22 ++
arch/arm/cpu/armv7/bcm2835/Makefile | 1 +
4 files changed, 27 insertions(+)
create mode 100644 arch/arm/cpu/arm1176/bcm2835/phys2bus.c
diff --git a/arch/arm/cpu/arm1176/bcm2835/Kconfig
b/arch/arm/cpu/arm1176/bcm2835/Kconfig
index 73cc72b41185..3181747fbfd7 100644
--- a/arch/arm/cpu/arm1176/bcm2835/Kconfig
+++ b/arch/arm/cpu/arm1176/bcm2835/Kconfig
@@ -9,4 +9,7 @@ config DM_SERIAL
config DM_GPIO
default y
+config PHYS_TO_BUS
+ default y
+
endif
diff --git a/arch/arm/cpu/arm1176/bcm2835/Makefile
b/arch/arm/cpu/arm1176/bcm2835/Makefile
index 7e5dbe1fdeaf..6d1b74158773 100644
--- a/arch/arm/cpu/arm1176/bcm2835/Makefile
+++ b/arch/arm/cpu/arm1176/bcm2835/Makefile
@@ -6,3 +6,4 @@
obj-y := lowlevel_init.o
obj-y += init.o reset.o timer.o mbox.o
+obj-y += phys2bus.o
diff --git a/arch/arm/cpu/arm1176/bcm2835/phys2bus.c
b/arch/arm/cpu/arm1176/bcm2835/phys2bus.c
new file mode 100644
index ..fc1c29905de3
--- /dev/null
+++ b/arch/arm/cpu/arm1176/bcm2835/phys2bus.c
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2015 Stephen Warren
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include config.h
+#include phys2bus.h
+
+unsigned long phys_to_bus(unsigned long phys)
+{
+#ifdef CONFIG_BCM2836
+ return 0xc000 | phys;
+#else
+ return 0x4000 | phys;
+#endif
+}
+
+unsigned long bus_to_phys(unsigned long bus)
+{
+ return bus ~0xc000;
+}
diff --git a/arch/arm/cpu/armv7/bcm2835/Makefile
b/arch/arm/cpu/armv7/bcm2835/Makefile
index ed1ee4753d49..5d14d8bdcac3 100644
--- a/arch/arm/cpu/armv7/bcm2835/Makefile
+++ b/arch/arm/cpu/armv7/bcm2835/Makefile
@@ -11,3 +11,4 @@ obj-y += $(src_dir)/init.o
obj-y += $(src_dir)/reset.o
obj-y += $(src_dir)/timer.o
obj-y += $(src_dir)/mbox.o
+obj-y += $(src_dir)/phys2bus.o
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] Create API to map between CPU physical and bus addresses
On some SoCs, DMA-capable peripherals see a different address space to
the CPU's physical address space. Create an API to allow platform-agnostic
drivers to convert between the two address spaces when programming DMA
operations.
This API will exist on all platforms, but will have a dummy implementation
when this feature is not required. Other platforms will enable
CONFIG_PHYS_TO_BUS and provide the required implementation.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
These patches depend on previous DWC2 rework that's in the topic/dwc2
branch of the USB repo.
These patches conflict with patches Masahiro has posted to move
arch/arm/cpu/arm1176/bcm2835 to arch/arm/mach-bcm283x(?).
I expect I'll have to rebase this series after the upcoming release once
those two things are merged into u-boot.git. Still, reviews could begin
before that.
---
drivers/Kconfig| 8
include/phys2bus.h | 25 +
2 files changed, 33 insertions(+)
create mode 100644 include/phys2bus.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index dcce532e2df2..941aa0c2612a 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -53,3 +53,11 @@ source drivers/crypto/Kconfig
source drivers/thermal/Kconfig
endmenu
+
+config PHYS_TO_BUS
+ bool
+ help
+ Some SoCs use a different address map for CPU physical addresses and
+ peripheral DMA master accesses. If yours does, select this option in
+ your platform's Kconfig, and implement the appropriate mapping
+ functions in your platform's support code.
diff --git a/include/phys2bus.h b/include/phys2bus.h
new file mode 100644
index ..87b6d69aa617
--- /dev/null
+++ b/include/phys2bus.h
@@ -0,0 +1,25 @@
+/*
+ * Copyright 2015 Stephen Warren
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _BUS_ADDR_H
+#define _BUS_ADDR_H
+
+#ifdef CONFIG_PHYS_TO_BUS
+unsigned long phys_to_bus(unsigned long phys);
+unsigned long bus_to_phys(unsigned long bus);
+#else
+static inline unsigned long phys_to_bus(unsigned long phys)
+{
+ return phys;
+}
+
+static inline unsigned long bus_to_phys(unsigned long bus)
+{
+ return bus;
+}
+#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] [PATCH] config: peach: Correct memory layout environment settings
On Mon, Mar 23, 2015 at 03:04:48PM -0600, Simon Glass wrote: Hi Sjoerd, On 12 March 2015 at 15:33, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: The peach boards have their SDRAM start address at 0x2000 instead of 0x4000 which seems common for all other exynos5 based boards. This means the layout set in exynos5-common.h causes the kernel be loaded more then 128MB (at 0x4200) away from memory start which breaks booting kernels with CONFIG_AUTO_ZRELADDR Define a custom MEM_LAYOUT_ENV_SETTINGS for both peach boards which uses the same offsets from start of memory as the common exynos5 settings. This fixes booting via bootz and PXE Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- include/configs/peach-pi.h | 8 include/configs/peach-pit.h | 8 2 files changed, 16 insertions(+) diff --git a/include/configs/peach-pi.h b/include/configs/peach-pi.h index f04f061..e3cb09e 100644 --- a/include/configs/peach-pi.h +++ b/include/configs/peach-pi.h @@ -16,6 +16,14 @@ #define CONFIG_ENV_OFFSET (FLASH_SIZE - CONFIG_BL2_SIZE) #define CONFIG_SPI_BOOTING +#define MEM_LAYOUT_ENV_SETTINGS \ + bootm_size=0x1000\0 \ + kernel_addr_r=0x2200\0 \ + fdt_addr_r=0x2300\0 \ + ramdisk_addr_r=0x2330\0 \ + scriptaddr=0x3000\0 \ + pxefile_addr_r=0x3100\0 + #include configs/exynos5420-common.h #include configs/exynos5-dt-common.h diff --git a/include/configs/peach-pit.h b/include/configs/peach-pit.h index b5efbdc..3ee42ef 100644 --- a/include/configs/peach-pit.h +++ b/include/configs/peach-pit.h @@ -16,6 +16,14 @@ #define CONFIG_ENV_OFFSET (FLASH_SIZE - CONFIG_BL2_SIZE) #define CONFIG_SPI_BOOTING +#define MEM_LAYOUT_ENV_SETTINGS \ + bootm_size=0x1000\0 \ + kernel_addr_r=0x2200\0 \ + fdt_addr_r=0x2300\0 \ + ramdisk_addr_r=0x2330\0 \ + scriptaddr=0x3000\0 \ + pxefile_addr_r=0x3100\0 + #include configs/exynos5420-common.h #include configs/exynos5-dt-common.h It would be great if we could have this in the device tree. I understand what you're thinking but this is environment. And really this is not board specific, this is SoC family specific which is why the similar part for TI stuff is in ti_armv7_common.h :) -- 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 v2] ARM: at91: at91sam9n12ek: save the environment to a fat file in MMC card
Insteading in mmc's raw sectors, this patch will save the environment
in a fat file (uboot.env) in mmc card's first FAT patition by default.
If you want to save in mmc's raw sectors, you only need to define
CONFIG_ENV_IS_IN_MMC.
Signed-off-by: Josh Wu josh...@atmel.com
---
Changes in v2:
- not remove the code to save env in mmc's raw sectors.
- we can define CONFIG_ENV_IS_IN_MMC to enable raw sectors saving.
include/configs/at91sam9n12ek.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/configs/at91sam9n12ek.h b/include/configs/at91sam9n12ek.h
index f02fce9..058e0e4 100644
--- a/include/configs/at91sam9n12ek.h
+++ b/include/configs/at91sam9n12ek.h
@@ -201,11 +201,22 @@
#else /* CONFIG_SYS_USE_MMC */
/* bootstrap + u-boot + env + linux in mmc */
-#define CONFIG_ENV_IS_IN_MMC
-/* For FAT system, most cases it should be in the reserved sector */
+
+#ifdef CONFIG_ENV_IS_IN_MMC
+/* Use raw reserved sectors to save environment */
#define CONFIG_ENV_OFFSET 0x2000
#define CONFIG_ENV_SIZE0x1000
#define CONFIG_SYS_MMC_ENV_DEV 0
+#else
+/* Use file in FAT file to save environment */
+#define CONFIG_ENV_IS_IN_FAT
+#define CONFIG_FAT_WRITE
+#define FAT_ENV_INTERFACE mmc
+#define FAT_ENV_FILE uboot.env
+#define FAT_ENV_DEVICE_AND_PART0
+#define CONFIG_ENV_SIZE0x4000
+#endif
+
#define CONFIG_BOOTCOMMAND \
setenv bootargs ${console} ${mtdparts} ${bootargs_mmc}; \
fatload mmc 0:1 0x2100 dtb; \
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready
On 3/24/2015 9:33 AM, Andrew Gabbasov wrote: Hi Troy, From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] Sent: Monday, March 23, 2015 11:09 PM To: Gabbasov, Andrew; peng@freescale.com; u-boot@lists.denx.de Cc: Eric Nelson Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready On 3/23/2015 12:38 AM, Andrew Gabbasov wrote: Hi Troy, From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] Sent: Friday, March 20, 2015 9:39 PM To: peng@freescale.com; Gabbasov, Andrew; u-boot@lists.denx.de Cc: Eric Nelson Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready [skipped] Here's another patch that solves the problem a little earlier. It has this disadvantage of being slightly bigger, though it makes the code look better. https://github.com/boundarydevices/u-boot-imx6/commit/c0260ca I have a couple of doubts regarding that patch. First, my personal taste objects to such duplicating of the code (I mean setting of version, ocr, rca, etc fields of mmc structure). If we'll have to change or add anything to these settings, we'll have to make the same change in 2 different place, which is error-prone and extremely inconvenient from maintenance point of view. Second, what about SPI mode? Doesn't this patch skip retrieving of OCR register with a special command for SPI host case (thus setting ocr field incorrectly), if the card comes to ready state with the first attempt? That's a good argument for a subroutine to be doing that work instead of in two places. In some sense the second function of these two (mmc_complete_op_cond()) is exactly such subroutine ;-) It is doing this work of final settings and actions after making OCR polling. Although completing the polling itself in some cases too. Actually, it seems that introducing of one more service function would make the code a little too chopped into too small pieces, and also further less similar to SD (as opposed to MMC) case. Thanks. I've already said that I'm fine with any patch that fixes the problem, so there is no need to convince me of anything. I just wanted to show that setting the pending flag, when the command is actually complete, does not make a lot of sense. Thanks Troy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Set up stdio earlier when using driver model --- breaks sbc8548 booting.
Hi Paul, On 24 March 2015 at 07:33, Paul Gortmaker paul.gortma...@windriver.com wrote: [Re: Set up stdio earlier when using driver model --- breaks sbc8548 booting.] On 23/03/2015 (Mon 17:01) Simon Glass wrote: Hi Paul, On 16 March 2015 at 19:41, Paul Gortmaker paul.gortma...@windriver.com wrote: Testing latest master on sbc8548 (ppc e500v2 single core) and it hangs at the Net: line; a working boot shows the full Net: line as: - PCI: Host, 64 bit, 66 MHz, sync, arbiter 00:01.0 - 8086:1026 - Network controller PCI1: Bus 00 - 00 PCIe1: disabled In:serial Out: serial Err: serial Net: eTSEC0 [PRIME], eTSEC1 Hit any key to stop autoboot: 0 - So we never see the eTSEC0 or any other output after Net: . My 1st bisect led to my own commit: - commit 2bf4207b8a452476a591d733c6b8f09b337acc08 Author: Paul Gortmaker paul.gortma...@windriver.com AuthorDate: Thu Aug 14 10:42:52 2014 -0400 Commit: York Sun york...@freescale.com CommitDate: Fri Nov 14 11:12:13 2014 -0800 sbc8548: enable and test CONFIG_SYS_GENERIC_BOARD - ...but that is a red herring, since I'd tested it on master at Aug14, but it wasn't committed to master until three months later. So the breakage is in that 3 month window. Since I recorded the original baseline I'd tested on, I restarted the bisect with that baseline as good and the above 2bf42 as bad, and just added the oneline change for CONFIG_SYS_GENERIC_BOARD manually at each bisect point. Doing that led me unequivocally to: - commit 294b91a5817147d4b7f47be2ac69bac2a1f26491 Author: Simon Glass s...@chromium.org Date: Wed Sep 3 17:37:00 2014 -0600 Set up stdio earlier when using driver model - Based on a part of that commit log, it says Should there be any problems with this approach they can be dealt with as boards are converted over to use driver model for serial. So maybe the sbc8548 is just missing some additional conversion? Oddly it seems it is dying at network device probing and not in/out/err that use serial as stdio. Any hints on what to look at next to solve this would be appreciated. I had a look at this link: http://www.denx.de/wiki/U-Boot/DriverModel ..but wasn't sure where to go from there, since I'm still unsure what the real root of the breakage is. Yes it is certainly odd. The driver init for serial is over by then, so I don't see why it would hang. Also the code has changed further since that commit. So there is no board wide conversion to some new API needed from this change, i.e. things should have stayed working as is? Right. My suggestion would be to dig into the network init and see if you figure out where it hangs. Do you have an ICE? Ugh. I could probably find an ICE and the associated software, but I've never really liked using the things, which is why I bisected my way here to identify the commit that caused the regression, hoping that once it was identified, that the author of the changeset would know what happened... :-( The author does not know and has racked his brains trying to imagine what the problem might be. But since it happens after the console is running, he is at a loss. Once you find the problem the author will likely experience a revelatory moment. Break out the ICE :-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 24/28] armv8/ls2085aqds: NAND boot support
-Original Message- From: Sun York-R58495 Sent: Tuesday, March 24, 2015 9:15 PM To: Wood Scott-B07421 Cc: u-boot@lists.denx.de; Kushwaha Prabhakar-B32579 Subject: Re: [PATCH v5 24/28] armv8/ls2085aqds: NAND boot support On 03/23/2015 06:34 PM, Scott Wood wrote: On Fri, 2015-03-20 at 19:28 -0700, York Sun wrote: +Generage NAND image +--- +To form the NAND image, build u-boot with LS2085AQDS_NAND_defconfig. +Append u-boot-with-spl.bin after RCW image. The RCW image should +have these PBI commands + +1) CCSR 4-byte write to 0x00e00404, data=0x +2) CCSR 4-byte write to 0x00e00400, data=0x1800a000 +3) Block Copy: SRC=0x0104, SRC_ADDR=0x00c0, +DEST_ADDR=0x1800a000, +BLOCK_SIZE=0x00014000 The RCW source should probably be 0x107, not 0x104. Bit 0x002 requests first/last bad block markers rather than first/second, and bit 0x001 enables ECC. Also, this documentation is LS2085A-specific (most of it will probably apply to all chips with this chassis), not RDB or QDS specific, with the exception of the RCW source ID which depends on the specific NAND chip. It would be better to put it in one place rather than duplicate it, with a table of RCW source IDs for each board. Also, you have RDB as having SRC=0x104, but that (as well as 0x107) is for a 2K-page NAND chip. RDB has a 4K-page NAND, so I think you want RCW source to be 0x111. for RDB. I think RCW source should be 0x119. bad block at first/last page(ONFI requirement) and 4bit ECC -prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 24/28] armv8/ls2085aqds: NAND boot support
On Tue, 2015-03-24 at 11:34 -0500, Kushwaha Prabhakar-B32579 wrote: -Original Message- From: Sun York-R58495 Sent: Tuesday, March 24, 2015 9:15 PM To: Wood Scott-B07421 Cc: u-boot@lists.denx.de; Kushwaha Prabhakar-B32579 Subject: Re: [PATCH v5 24/28] armv8/ls2085aqds: NAND boot support On 03/23/2015 06:34 PM, Scott Wood wrote: On Fri, 2015-03-20 at 19:28 -0700, York Sun wrote: +Generage NAND image +--- +To form the NAND image, build u-boot with LS2085AQDS_NAND_defconfig. +Append u-boot-with-spl.bin after RCW image. The RCW image should +have these PBI commands + +1) CCSR 4-byte write to 0x00e00404, data=0x +2) CCSR 4-byte write to 0x00e00400, data=0x1800a000 +3) Block Copy: SRC=0x0104, SRC_ADDR=0x00c0, +DEST_ADDR=0x1800a000, +BLOCK_SIZE=0x00014000 The RCW source should probably be 0x107, not 0x104. Bit 0x002 requests first/last bad block markers rather than first/second, and bit 0x001 enables ECC. Also, this documentation is LS2085A-specific (most of it will probably apply to all chips with this chassis), not RDB or QDS specific, with the exception of the RCW source ID which depends on the specific NAND chip. It would be better to put it in one place rather than duplicate it, with a table of RCW source IDs for each board. Also, you have RDB as having SRC=0x104, but that (as well as 0x107) is for a 2K-page NAND chip. RDB has a 4K-page NAND, so I think you want RCW source to be 0x111. for RDB. I think RCW source should be 0x119. bad block at first/last page(ONFI requirement) and 4bit ECC Yes, sorry. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 24/28] armv8/ls2085aqds: NAND boot support
On 03/24/2015 09:34 AM, Kushwaha Prabhakar-B32579 wrote: -Original Message- From: Sun York-R58495 Sent: Tuesday, March 24, 2015 9:15 PM To: Wood Scott-B07421 Cc: u-boot@lists.denx.de; Kushwaha Prabhakar-B32579 Subject: Re: [PATCH v5 24/28] armv8/ls2085aqds: NAND boot support On 03/23/2015 06:34 PM, Scott Wood wrote: On Fri, 2015-03-20 at 19:28 -0700, York Sun wrote: +Generage NAND image +--- +To form the NAND image, build u-boot with LS2085AQDS_NAND_defconfig. +Append u-boot-with-spl.bin after RCW image. The RCW image should +have these PBI commands + +1) CCSR 4-byte write to 0x00e00404, data=0x +2) CCSR 4-byte write to 0x00e00400, data=0x1800a000 +3) Block Copy: SRC=0x0104, SRC_ADDR=0x00c0, +DEST_ADDR=0x1800a000, +BLOCK_SIZE=0x00014000 The RCW source should probably be 0x107, not 0x104. Bit 0x002 requests first/last bad block markers rather than first/second, and bit 0x001 enables ECC. Also, this documentation is LS2085A-specific (most of it will probably apply to all chips with this chassis), not RDB or QDS specific, with the exception of the RCW source ID which depends on the specific NAND chip. It would be better to put it in one place rather than duplicate it, with a table of RCW source IDs for each board. Also, you have RDB as having SRC=0x104, but that (as well as 0x107) is for a 2K-page NAND chip. RDB has a 4K-page NAND, so I think you want RCW source to be 0x111. for RDB. I think RCW source should be 0x119. bad block at first/last page(ONFI requirement) and 4bit ECC I think 0x119 is correct. It is the same value I read back from rcw_src. I just verified it boots OK. I have been using 0x104 as the source id incorrectly but it also boots. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready
Hi Troy, From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] Sent: Monday, March 23, 2015 11:09 PM To: Gabbasov, Andrew; peng@freescale.com; u-boot@lists.denx.de Cc: Eric Nelson Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready On 3/23/2015 12:38 AM, Andrew Gabbasov wrote: Hi Troy, From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] Sent: Friday, March 20, 2015 9:39 PM To: peng@freescale.com; Gabbasov, Andrew; u-boot@lists.denx.de Cc: Eric Nelson Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready [skipped] Here's another patch that solves the problem a little earlier. It has this disadvantage of being slightly bigger, though it makes the code look better. https://github.com/boundarydevices/u-boot-imx6/commit/c0260ca I have a couple of doubts regarding that patch. First, my personal taste objects to such duplicating of the code (I mean setting of version, ocr, rca, etc fields of mmc structure). If we'll have to change or add anything to these settings, we'll have to make the same change in 2 different place, which is error-prone and extremely inconvenient from maintenance point of view. Second, what about SPI mode? Doesn't this patch skip retrieving of OCR register with a special command for SPI host case (thus setting ocr field incorrectly), if the card comes to ready state with the first attempt? That's a good argument for a subroutine to be doing that work instead of in two places. In some sense the second function of these two (mmc_complete_op_cond()) is exactly such subroutine ;-) It is doing this work of final settings and actions after making OCR polling. Although completing the polling itself in some cases too. Actually, it seems that introducing of one more service function would make the code a little too chopped into too small pieces, and also further less similar to SD (as opposed to MMC) case. Thanks. Best regards, Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mtd: vf610_nfc: mark page as dirty on block erase
The driver tries to re-use the page buffer by storing the page number of the current page in the buffer. The page is only read if the requested page number is not currently in the buffer. When a block is erased, the page number is marked as invalid if the erased page equals the one currently in the cache. However, since a erase block consists of multiple pages, also other page numbers could be affected. The commands to reproduce this issue (on a written page): nand dump 0x800 nand erase 0x0 0x2 nand dump 0x800 The second nand dump command returns the data from the buffer, while in fact the page is erased (0xff). Avoid the hassle to calculate whether the page is affected or not, but set the page buffer unconditionally to invalid instead. Signed-off-by: Stefan Agner ste...@agner.ch --- This are two bug fixes which would be nice if they would still make it into 2015.04... drivers/mtd/nand/vf610_nfc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c index 928d58b..9de971c 100644 --- a/drivers/mtd/nand/vf610_nfc.c +++ b/drivers/mtd/nand/vf610_nfc.c @@ -369,8 +369,7 @@ static void vf610_nfc_command(struct mtd_info *mtd, unsigned command, break; case NAND_CMD_ERASE1: - if (nfc-page == page) - nfc-page = -1; + nfc-page = -1; vf610_nfc_send_commands(nfc-regs, command, NAND_CMD_ERASE2, ERASE_CMD_CODE); vf610_nfc_addr_cycle(mtd, column, page); -- 2.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mtd: vf610_nfc: specify transfer size before each transfer
Testing showed, that commands like STATUS made the buffer dirty
when executed with NFC_SECSZ set to the page size. It looks
like the controller transfers bogus data when this register
is configured. When setting it to 0, the buffer does not get
altered while the status command still seems to work flawless.
Signed-off-by: Stefan Agner ste...@agner.ch
---
drivers/mtd/nand/vf610_nfc.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index 9de971c..d98dd28 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -146,6 +146,7 @@ struct vf610_nfc {
void __iomem *regs;
uint column;
intspareonly;
+ intpage_sz;
intpage;
/* Status and ID are in alternate locations. */
intalt_buf;
@@ -329,6 +330,11 @@ static void vf610_nfc_addr_cycle(struct mtd_info *mtd, int
column, int page)
ROW_ADDR_SHIFT, page);
}
+static inline void vf610_nfc_transfer_size(void __iomem *regbase, int size)
+{
+ __raw_writel(size, regbase + NFC_SECTOR_SIZE);
+}
+
/* Send command to NAND chip */
static void vf610_nfc_command(struct mtd_info *mtd, unsigned command,
int column, int page)
@@ -342,12 +348,14 @@ static void vf610_nfc_command(struct mtd_info *mtd,
unsigned command,
switch (command) {
case NAND_CMD_PAGEPROG:
nfc-page = -1;
+ vf610_nfc_transfer_size(nfc-regs, nfc-page_sz);
vf610_nfc_send_commands(nfc-regs, NAND_CMD_SEQIN,
command, PROGRAM_PAGE_CMD_CODE);
vf610_nfc_addr_cycle(mtd, column, page);
break;
case NAND_CMD_RESET:
+ vf610_nfc_transfer_size(nfc-regs, 0);
vf610_nfc_send_command(nfc-regs, command, RESET_CMD_CODE);
break;
/*
@@ -363,6 +371,7 @@ static void vf610_nfc_command(struct mtd_info *mtd,
unsigned command,
if (nfc-page == page)
return;
nfc-page = page;
+ vf610_nfc_transfer_size(nfc-regs, nfc-page_sz);
vf610_nfc_send_commands(nfc-regs, NAND_CMD_READ0,
NAND_CMD_READSTART, READ_PAGE_CMD_CODE);
vf610_nfc_addr_cycle(mtd, column, page);
@@ -370,6 +379,7 @@ static void vf610_nfc_command(struct mtd_info *mtd,
unsigned command,
case NAND_CMD_ERASE1:
nfc-page = -1;
+ vf610_nfc_transfer_size(nfc-regs, 0);
vf610_nfc_send_commands(nfc-regs, command,
NAND_CMD_ERASE2, ERASE_CMD_CODE);
vf610_nfc_addr_cycle(mtd, column, page);
@@ -377,11 +387,13 @@ static void vf610_nfc_command(struct mtd_info *mtd,
unsigned command,
case NAND_CMD_READID:
nfc-alt_buf = ALT_BUF_ID;
+ vf610_nfc_transfer_size(nfc-regs, 0);
vf610_nfc_send_command(nfc-regs, command, READ_ID_CMD_CODE);
break;
case NAND_CMD_STATUS:
nfc-alt_buf = ALT_BUF_STAT;
+ vf610_nfc_transfer_size(nfc-regs, 0);
vf610_nfc_send_command(nfc-regs, command,
STATUS_READ_CMD_CODE);
break;
@@ -579,7 +591,6 @@ static int vf610_nfc_nand_init(int devnum, void __iomem
*addr)
struct nand_chip *chip;
struct vf610_nfc *nfc;
int err = 0;
- int page_sz;
struct vf610_nfc_config cfg = {
.hardware_ecc = 1,
#ifdef CONFIG_SYS_NAND_BUSWIDTH_16BIT
@@ -633,9 +644,8 @@ static int vf610_nfc_nand_init(int devnum, void __iomem
*addr)
chip-bbt_td = bbt_main_descr;
chip-bbt_md = bbt_mirror_descr;
- page_sz = PAGE_2K + OOB_64;
- page_sz += cfg.width == 16 ? 1 : 0;
- vf610_nfc_write(mtd, NFC_SECTOR_SIZE, page_sz);
+ nfc-page_sz = PAGE_2K + OOB_64;
+ nfc-page_sz += cfg.width == 16 ? 1 : 0;
/* Set configuration register. */
vf610_nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_ADDR_AUTO_INCR_BIT);
@@ -664,16 +674,15 @@ static int vf610_nfc_nand_init(int devnum, void __iomem
*addr)
chip-ecc.mode = NAND_ECC_SOFT; /* default */
- page_sz = mtd-writesize + mtd-oobsize;
+ nfc-page_sz = mtd-writesize + mtd-oobsize;
/* Single buffer only, max 256 OOB minus ECC status */
- if (page_sz PAGE_2K + 256 - 8) {
+ if (nfc-page_sz PAGE_2K + 256 - 8) {
dev_err(nfc-dev, Unsupported flash size\n);
err = -ENXIO;
goto error;
}
- page_sz += cfg.width == 16 ? 1 : 0;
- vf610_nfc_write(mtd, NFC_SECTOR_SIZE, page_sz);
+ nfc-page_sz += cfg.width == 16 ? 1 :
[U-Boot] [PATCH v7 24/28] armv8/ls2085aqds: NAND boot support
From: Scott Wood scottw...@freescale.com
This adds NAND boot support for LS2085AQDS, using SPL framework.
Details of forming NAND image can be found in README.
Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: York Sun york...@freescale.com
---
Changes in v7:
Move NAND boot instruction to fsl-lsch3/README.
Update board setting to put RCW and u-boot in different NAND block.
Changes in v6: None
Changes in v5:
Update LS2085AQDS README to include instructions to form NAND image
Changes in v4:
Update MAINTAINERS file
Changes in v3: None
Changes in v2: None
arch/arm/Kconfig |1 +
arch/arm/cpu/armv8/fsl-lsch3/README | 37 +++
arch/arm/cpu/armv8/fsl-lsch3/soc.c| 48 +
arch/arm/cpu/armv8/{u-boot.lds = u-boot-spl.lds} | 74 +
arch/arm/include/asm/arch-fsl-lsch3/config.h |9 +++
arch/arm/lib/crt0_64.S|7 ++
board/freescale/ls2085aqds/MAINTAINERS|1 +
board/freescale/ls2085aqds/ddr.c |4 ++
common/spl/spl.c |2 +-
common/spl/spl_nand.c |2 +-
configs/ls2085aqds_nand_defconfig |4 ++
drivers/misc/fsl_ifc.c| 12
drivers/mtd/nand/fsl_ifc_spl.c|2 +-
include/configs/ls2085a_common.h | 29
include/configs/ls2085aqds.h | 50 --
15 files changed, 231 insertions(+), 51 deletions(-)
copy arch/arm/cpu/armv8/{u-boot.lds = u-boot-spl.lds} (57%)
create mode 100644 configs/ls2085aqds_nand_defconfig
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6ba4b8d..f73541c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -652,6 +652,7 @@ config TARGET_LS2085AQDS
bool Support ls2085aqds
select ARM64
select ARMV8_MULTIENTRY
+ select SUPPORT_SPL
help
Support for Freescale LS2085AQDS platform
The LS2085A Development System (QDS) is a high-performance
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/README
b/arch/arm/cpu/armv8/fsl-lsch3/README
index 4f36e2a..eee0228 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/README
+++ b/arch/arm/cpu/armv8/fsl-lsch3/README
@@ -95,3 +95,40 @@ mcboottimeout: MC boot timeout in milliseconds. If
this variable is not defined
mcmemsize: MC DRAM block size. If this variable is not defined, the value
CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE will be assumed.
+
+Booting from NAND
+---
+Booting from NAND requires two images, RCW and u-boot-with-spl.bin.
+The difference between NAND boot RCW image and NOR boot image is the PBI
+command sequence. Below is one example for PBI commands.
+
+1) CCSR 4-byte write to 0x00e00404, data=0x
+2) CCSR 4-byte write to 0x00e00400, data=0x1800a000
+The above two commands set bootloc register to 0x_1800a000 where
+the u-boot code will be running in OCRAM.
+
+3) Block Copy: SRC=0x0119, SRC_ADDR=0x0008, DEST_ADDR=0x1800a000,
+BLOCK_SIZE=0x00014000
+This command copies u-boot image from NAND device into OCRAM. The values need
+to adjust accordingly.
+
+SRCshould match the cfg_rcw_src, the reset config pins.
+SRC_ADDR is the offset of u-boot image in NAND device. It should match
+ CONFIG_SYS_NAND_U_BOOT_OFFS. In the example above, it is 512KB.
+DEST_ADDR is fixed at 0x1800a000, matching bootloc set above.
+BLOCK_SIZE is the size to be copied by PBI.
+
+RCW image should be written to the beginning of NAND device. Example of using
+u-boot command
+
+nand write rcw image in memory 0 size of rcw image
+
+To form the NAND image, build u-boot with NAND config, for example,
+ls2085aqds_nand_defconfig. The image needed is u-boot-with-spl.bin.
+
+The u-boot image should be written to the offset CONFIG_SYS_NAND_U_BOOT_OFFS,
+in above example 0x8.
+
+nand write u-boot image in memory 8 size of u-boot image
+
+With these two images in NAND device, the board can boot from NAND.
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/soc.c
b/arch/arm/cpu/armv8/fsl-lsch3/soc.c
index 17700ef..ca00108 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/soc.c
+++ b/arch/arm/cpu/armv8/fsl-lsch3/soc.c
@@ -6,8 +6,13 @@
#include common.h
#include fsl_ifc.h
+#include nand.h
+#include spl.h
#include asm/arch-fsl-lsch3/soc.h
#include asm/io.h
+#include asm/global_data.h
+
+DECLARE_GLOBAL_DATA_PTR;
static void erratum_a008751(void)
{
@@ -18,8 +23,51 @@ static void erratum_a008751(void)
#endif
}
+static void erratum_rcw_src(void)
+{
+#if defined(CONFIG_SPL)
+ u32 __iomem *dcfg_ccsr = (u32 __iomem *)DCFG_BASE;
+ u32 __iomem *dcfg_dcsr = (u32 __iomem *)DCFG_DCSR_BASE;
+ u32 val;
+
+ val = in_le32(dcfg_ccsr + DCFG_PORSR1 / 4);
+ val = ~DCFG_PORSR1_RCW_SRC;
+ val |= DCFG_PORSR1_RCW_SRC_NOR;
+
Re: [U-Boot] [PATCH v7 24/28] armv8/ls2085aqds: NAND boot support
On Tue, 2015-03-24 at 12:25 -0700, York Sun wrote:
From: Scott Wood scottw...@freescale.com
This adds NAND boot support for LS2085AQDS, using SPL framework.
Details of forming NAND image can be found in README.
Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: York Sun york...@freescale.com
---
Changes in v7:
Move NAND boot instruction to fsl-lsch3/README.
Update board setting to put RCW and u-boot in different NAND block.
Changes in v6: None
Changes in v5:
Update LS2085AQDS README to include instructions to form NAND image
Changes in v4:
Update MAINTAINERS file
Changes in v3: None
Changes in v2: None
arch/arm/Kconfig |1 +
arch/arm/cpu/armv8/fsl-lsch3/README | 37 +++
arch/arm/cpu/armv8/fsl-lsch3/soc.c| 48 +
arch/arm/cpu/armv8/{u-boot.lds = u-boot-spl.lds} | 74
+
arch/arm/include/asm/arch-fsl-lsch3/config.h |9 +++
arch/arm/lib/crt0_64.S|7 ++
board/freescale/ls2085aqds/MAINTAINERS|1 +
board/freescale/ls2085aqds/ddr.c |4 ++
common/spl/spl.c |2 +-
common/spl/spl_nand.c |2 +-
configs/ls2085aqds_nand_defconfig |4 ++
drivers/misc/fsl_ifc.c| 12
drivers/mtd/nand/fsl_ifc_spl.c|2 +-
include/configs/ls2085a_common.h | 29
include/configs/ls2085aqds.h | 50 --
15 files changed, 231 insertions(+), 51 deletions(-)
copy arch/arm/cpu/armv8/{u-boot.lds = u-boot-spl.lds} (57%)
create mode 100644 configs/ls2085aqds_nand_defconfig
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6ba4b8d..f73541c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -652,6 +652,7 @@ config TARGET_LS2085AQDS
bool Support ls2085aqds
select ARM64
select ARMV8_MULTIENTRY
+ select SUPPORT_SPL
help
Support for Freescale LS2085AQDS platform
The LS2085A Development System (QDS) is a high-performance
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/README
b/arch/arm/cpu/armv8/fsl-lsch3/README
index 4f36e2a..eee0228 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/README
+++ b/arch/arm/cpu/armv8/fsl-lsch3/README
@@ -95,3 +95,40 @@ mcboottimeout: MC boot timeout in milliseconds. If
this variable is not defined
mcmemsize: MC DRAM block size. If this variable is not defined, the value
CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE will be assumed.
+
+Booting from NAND
+---
+Booting from NAND requires two images, RCW and u-boot-with-spl.bin.
+The difference between NAND boot RCW image and NOR boot image is the PBI
+command sequence. Below is one example for PBI commands.
+
+1) CCSR 4-byte write to 0x00e00404, data=0x
+2) CCSR 4-byte write to 0x00e00400, data=0x1800a000
+The above two commands set bootloc register to 0x_1800a000 where
+the u-boot code will be running in OCRAM.
+
+3) Block Copy: SRC=0x0119, SRC_ADDR=0x0008, DEST_ADDR=0x1800a000,
+BLOCK_SIZE=0x00014000
+This command copies u-boot image from NAND device into OCRAM. The values need
+to adjust accordingly.
+
+SRC should match the cfg_rcw_src, the reset config pins.
You should make it clear that this value depends on the type of NAND
chip, and that the value for the QDS board is 0x107...
+SRC_ADDR is the offset of u-boot image in NAND device. It should match
+ CONFIG_SYS_NAND_U_BOOT_OFFS. In the example above, it is 512KB.
+DEST_ADDRis fixed at 0x1800a000, matching bootloc set above.
+BLOCK_SIZE is the size to be copied by PBI.
+
+RCW image should be written to the beginning of NAND device. Example of using
+u-boot command
+
+nand write rcw image in memory 0 size of rcw image
+
+To form the NAND image, build u-boot with NAND config, for example,
+ls2085aqds_nand_defconfig. The image needed is u-boot-with-spl.bin.
...especially since this makes it look like the above example is for
QDS.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 24/28] armv8/ls2085aqds: NAND boot support
On 03/24/2015 12:49 PM, Scott Wood wrote: On Tue, 2015-03-24 at 12:47 -0700, York Sun wrote: +Booting from NAND +--- +Booting from NAND requires two images, RCW and u-boot-with-spl.bin. +The difference between NAND boot RCW image and NOR boot image is the PBI +command sequence. Below is one example for PBI commands for QDS. + +1) CCSR 4-byte write to 0x00e00404, data=0x +2) CCSR 4-byte write to 0x00e00400, data=0x1800a000 +The above two commands set bootloc register to 0x_1800a000 where +the u-boot code will be running in OCRAM. + +3) Block Copy: SRC=0x0107, SRC_ADDR=0x0010, DEST_ADDR=0x1800a000, +BLOCK_SIZE=0x00014000 +This command copies u-boot image from NAND device into OCRAM. The values need +to adjust accordingly. + +SRC should match the cfg_rcw_src, the reset config pins. It depends +on the NAND device. See reference manual for cfg_rcw_src. +SRC_ADDRis the offset of u-boot image in NAND device. It should match +CONFIG_SYS_NAND_U_BOOT_OFFS. In the example above, it is 1MB. Why 1 MiB? I got it wrong. I though the erase size is 1MB, but actually it is 128KB. I will fix it. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready
From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] Sent: Tuesday, March 24, 2015 9:03 PM To: Gabbasov, Andrew; peng@freescale.com; u-boot@lists.denx.de Cc: Eric Nelson Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready On 3/24/2015 9:33 AM, Andrew Gabbasov wrote: Hi Troy, From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] Sent: Monday, March 23, 2015 11:09 PM To: Gabbasov, Andrew; peng@freescale.com; u-boot@lists.denx.de Cc: Eric Nelson Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready On 3/23/2015 12:38 AM, Andrew Gabbasov wrote: Hi Troy, From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] Sent: Friday, March 20, 2015 9:39 PM To: peng@freescale.com; Gabbasov, Andrew; u-boot@lists.denx.de Cc: Eric Nelson Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready [skipped] Here's another patch that solves the problem a little earlier. It has this disadvantage of being slightly bigger, though it makes the code look better. https://github.com/boundarydevices/u-boot-imx6/commit/c0260ca I have a couple of doubts regarding that patch. First, my personal taste objects to such duplicating of the code (I mean setting of version, ocr, rca, etc fields of mmc structure). If we'll have to change or add anything to these settings, we'll have to make the same change in 2 different place, which is error-prone and extremely inconvenient from maintenance point of view. Second, what about SPI mode? Doesn't this patch skip retrieving of OCR register with a special command for SPI host case (thus setting ocr field incorrectly), if the card comes to ready state with the first attempt? That's a good argument for a subroutine to be doing that work instead of in two places. In some sense the second function of these two (mmc_complete_op_cond()) is exactly such subroutine ;-) It is doing this work of final settings and actions after making OCR polling. Although completing the polling itself in some cases too. Actually, it seems that introducing of one more service function would make the code a little too chopped into too small pieces, and also further less similar to SD (as opposed to MMC) case. Thanks. I've already said that I'm fine with any patch that fixes the problem, so there is no need to convince me of anything. I just wanted to show that setting the pending flag, when the command is actually complete, does not make a lot of sense. I absolutely agree. In fact, this flag in current implementation just indicates the branch that the MMC card case is being processed. If the version field, differing SD and MMC cases, would be set a little earlier, for example, directly in mmc_start_init(), we could just use !IS_SD() instead of this pending flag. And thinking further, it's not quite clear why the splitting of OCR polling was done for MMC case only, but not for SD too. So, there is still the room for further improving the code, may be even some reorganizing, but I had to stop somewhere, unless there is the direct necessity ;-) Thanks. Best regards, Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7 26/28] armv8/ls2085ardb: Enable NAND SPL support
From: Scott Wood scottw...@freescale.com
Enable NAND boot support using SPL framework. To boot from
NAND, either use DIP switches on board, or qixis_reset nand
command. Details of forming NAND image can be found in README.
Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: York Sun york...@freescale.com
---
Changes in v7:
Move NAND boot instruction to fsl-lsch3/README.
Update board setting to put RCW and u-boot in different NAND block.
Changes in v6: None
Changes in v5:
Fix signed-off-by signature
Update LS2085ARDB README to include instructions to form NAND image
Changes in v4:
Update MAINTAINERS file
Changes in v3: None
Changes in v2: None
arch/arm/Kconfig |1 +
board/freescale/ls2085ardb/MAINTAINERS |1 +
board/freescale/ls2085ardb/ddr.c |4
configs/ls2085ardb_nand_defconfig |4
include/configs/ls2085ardb.h | 40
5 files changed, 45 insertions(+), 5 deletions(-)
create mode 100644 configs/ls2085ardb_nand_defconfig
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f73541c..cf291c8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -663,6 +663,7 @@ config TARGET_LS2085ARDB
bool Support ls2085ardb
select ARM64
select ARMV8_MULTIENTRY
+ select SUPPORT_SPL
help
Support for Freescale LS2085ARDB platform.
The LS2085A Reference design board (RDB) is a high-performance
diff --git a/board/freescale/ls2085ardb/MAINTAINERS
b/board/freescale/ls2085ardb/MAINTAINERS
index 436039f..d5cce40 100644
--- a/board/freescale/ls2085ardb/MAINTAINERS
+++ b/board/freescale/ls2085ardb/MAINTAINERS
@@ -5,3 +5,4 @@ F: board/freescale/ls2085ardb/
F: board/freescale/ls2085a/ls2085ardb.c
F: include/configs/ls2085ardb.h
F: configs/ls2085ardb_defconfig
+F: configs/ls2085ardb_nand_defconfig
diff --git a/board/freescale/ls2085ardb/ddr.c b/board/freescale/ls2085ardb/ddr.c
index 6cd5e8b..8d71ae1 100644
--- a/board/freescale/ls2085ardb/ddr.c
+++ b/board/freescale/ls2085ardb/ddr.c
@@ -147,9 +147,13 @@ phys_size_t initdram(int board_type)
{
phys_size_t dram_size;
+#if defined(CONFIG_SPL) !defined(CONFIG_SPL_BUILD)
+ return fsl_ddr_sdram_size();
+#else
puts(Initializing DDRusing SPD\n);
dram_size = fsl_ddr_sdram();
+#endif
return dram_size;
}
diff --git a/configs/ls2085ardb_nand_defconfig
b/configs/ls2085ardb_nand_defconfig
new file mode 100644
index 000..39ba8c5
--- /dev/null
+++ b/configs/ls2085ardb_nand_defconfig
@@ -0,0 +1,4 @@
++S:CONFIG_SYS_EXTRA_OPTIONS=SYS_FSL_DDR4,NAND
++S:CONFIG_SPL=y
++S:CONFIG_ARM=y
++S:CONFIG_TARGET_LS2085ARDB=y
diff --git a/include/configs/ls2085ardb.h b/include/configs/ls2085ardb.h
index 0a5873b..ae5c2a9 100644
--- a/include/configs/ls2085ardb.h
+++ b/include/configs/ls2085ardb.h
@@ -139,11 +139,13 @@ unsigned long get_board_sys_clk(void);
#define QIXIS_LBMAP_SHIFT 0
#define QIXIS_LBMAP_DFLTBANK 0x00
#define QIXIS_LBMAP_ALTBANK0x04
+#define QIXIS_LBMAP_NAND 0x09
#define QIXIS_RST_CTL_RESET0x31
#define QIXIS_RST_CTL_RESET_EN 0x30
#define QIXIS_RCFG_CTL_RECONFIG_IDLE 0x20
#define QIXIS_RCFG_CTL_RECONFIG_START 0x21
#define QIXIS_RCFG_CTL_WATCHDOG_ENBLE 0x08
+#define QIXIS_RCW_SRC_NAND 0x119
#defineQIXIS_RST_FORCE_MEM 0x01
#define CONFIG_SYS_CSPR3_EXT (0x0)
@@ -169,6 +171,33 @@ unsigned long get_board_sys_clk(void);
FTIM2_GPCM_TWP(0x3E))
#define CONFIG_SYS_CS3_FTIM3 0x0
+#if defined(CONFIG_SPL) defined(CONFIG_NAND)
+#define CONFIG_SYS_CSPR2_EXT CONFIG_SYS_NOR0_CSPR_EXT
+#define CONFIG_SYS_CSPR2 CONFIG_SYS_NOR0_CSPR_EARLY
+#define CONFIG_SYS_CSPR2_FINAL CONFIG_SYS_NOR0_CSPR
+#define CONFIG_SYS_AMASK2 CONFIG_SYS_NOR_AMASK
+#define CONFIG_SYS_CSOR2 CONFIG_SYS_NOR_CSOR
+#define CONFIG_SYS_CS2_FTIM0 CONFIG_SYS_NOR_FTIM0
+#define CONFIG_SYS_CS2_FTIM1 CONFIG_SYS_NOR_FTIM1
+#define CONFIG_SYS_CS2_FTIM2 CONFIG_SYS_NOR_FTIM2
+#define CONFIG_SYS_CS2_FTIM3 CONFIG_SYS_NOR_FTIM3
+#define CONFIG_SYS_CSPR0_EXT CONFIG_SYS_NAND_CSPR_EXT
+#define CONFIG_SYS_CSPR0 CONFIG_SYS_NAND_CSPR
+#define CONFIG_SYS_AMASK0 CONFIG_SYS_NAND_AMASK
+#define CONFIG_SYS_CSOR0 CONFIG_SYS_NAND_CSOR
+#define CONFIG_SYS_CS0_FTIM0 CONFIG_SYS_NAND_FTIM0
+#define CONFIG_SYS_CS0_FTIM1 CONFIG_SYS_NAND_FTIM1
+#define CONFIG_SYS_CS0_FTIM2 CONFIG_SYS_NAND_FTIM2
+#define CONFIG_SYS_CS0_FTIM3 CONFIG_SYS_NAND_FTIM3
+
+#define CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_OFFSET (2048 * 1024)
+#define CONFIG_ENV_SECT_SIZE 0x2
+#define CONFIG_ENV_SIZE0x2000
+#define CONFIG_SPL_PAD_TO
Re: [U-Boot] [PATCH v7 24/28] armv8/ls2085aqds: NAND boot support
On 03/24/2015 12:30 PM, Scott Wood wrote:
On Tue, 2015-03-24 at 12:25 -0700, York Sun wrote:
From: Scott Wood scottw...@freescale.com
This adds NAND boot support for LS2085AQDS, using SPL framework.
Details of forming NAND image can be found in README.
Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: York Sun york...@freescale.com
---
Changes in v7:
Move NAND boot instruction to fsl-lsch3/README.
Update board setting to put RCW and u-boot in different NAND block.
Changes in v6: None
Changes in v5:
Update LS2085AQDS README to include instructions to form NAND image
Changes in v4:
Update MAINTAINERS file
Changes in v3: None
Changes in v2: None
arch/arm/Kconfig |1 +
arch/arm/cpu/armv8/fsl-lsch3/README | 37 +++
arch/arm/cpu/armv8/fsl-lsch3/soc.c| 48 +
arch/arm/cpu/armv8/{u-boot.lds = u-boot-spl.lds} | 74
+
arch/arm/include/asm/arch-fsl-lsch3/config.h |9 +++
arch/arm/lib/crt0_64.S|7 ++
board/freescale/ls2085aqds/MAINTAINERS|1 +
board/freescale/ls2085aqds/ddr.c |4 ++
common/spl/spl.c |2 +-
common/spl/spl_nand.c |2 +-
configs/ls2085aqds_nand_defconfig |4 ++
drivers/misc/fsl_ifc.c| 12
drivers/mtd/nand/fsl_ifc_spl.c|2 +-
include/configs/ls2085a_common.h | 29
include/configs/ls2085aqds.h | 50 --
15 files changed, 231 insertions(+), 51 deletions(-)
copy arch/arm/cpu/armv8/{u-boot.lds = u-boot-spl.lds} (57%)
create mode 100644 configs/ls2085aqds_nand_defconfig
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6ba4b8d..f73541c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -652,6 +652,7 @@ config TARGET_LS2085AQDS
bool Support ls2085aqds
select ARM64
select ARMV8_MULTIENTRY
+select SUPPORT_SPL
help
Support for Freescale LS2085AQDS platform
The LS2085A Development System (QDS) is a high-performance
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/README
b/arch/arm/cpu/armv8/fsl-lsch3/README
index 4f36e2a..eee0228 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/README
+++ b/arch/arm/cpu/armv8/fsl-lsch3/README
@@ -95,3 +95,40 @@ mcboottimeout:MC boot timeout in milliseconds. If
this variable is not defined
mcmemsize: MC DRAM block size. If this variable is not defined, the value
CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE will be assumed.
+
+Booting from NAND
+---
+Booting from NAND requires two images, RCW and u-boot-with-spl.bin.
+The difference between NAND boot RCW image and NOR boot image is the PBI
+command sequence. Below is one example for PBI commands.
+
+1) CCSR 4-byte write to 0x00e00404, data=0x
+2) CCSR 4-byte write to 0x00e00400, data=0x1800a000
+The above two commands set bootloc register to 0x_1800a000 where
+the u-boot code will be running in OCRAM.
+
+3) Block Copy: SRC=0x0119, SRC_ADDR=0x0008, DEST_ADDR=0x1800a000,
+BLOCK_SIZE=0x00014000
+This command copies u-boot image from NAND device into OCRAM. The values
need
+to adjust accordingly.
+
+SRC should match the cfg_rcw_src, the reset config pins.
You should make it clear that this value depends on the type of NAND
chip, and that the value for the QDS board is 0x107...
OK. I will 0x107 here and add 0x119 with RDB patch.
+SRC_ADDRis the offset of u-boot image in NAND device. It should match
+CONFIG_SYS_NAND_U_BOOT_OFFS. In the example above, it is 512KB.
+DEST_ADDR is fixed at 0x1800a000, matching bootloc set above.
+BLOCK_SIZE is the size to be copied by PBI.
+
+RCW image should be written to the beginning of NAND device. Example of
using
+u-boot command
+
+nand write rcw image in memory 0 size of rcw image
+
+To form the NAND image, build u-boot with NAND config, for example,
+ls2085aqds_nand_defconfig. The image needed is u-boot-with-spl.bin.
...especially since this makes it look like the above example is for
QDS.
Make sense.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 24/28] armv8/ls2085aqds: NAND boot support
From: Scott Wood scottw...@freescale.com
This adds NAND boot support for LS2085AQDS, using SPL framework.
Details of forming NAND image can be found in README.
Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: York Sun york...@freescale.com
---
Changes in v8:
Update README to match the example for QDS NAND boot.
Changes in v7:
Move NAND boot instruction to fsl-lsch3/README.
Update board setting to put RCW and u-boot in different NAND block.
Changes in v6: None
Changes in v5:
Update LS2085AQDS README to include instructions to form NAND image
Changes in v4:
Update MAINTAINERS file
Changes in v3: None
Changes in v2: None
arch/arm/Kconfig |1 +
arch/arm/cpu/armv8/fsl-lsch3/README | 38 +++
arch/arm/cpu/armv8/fsl-lsch3/soc.c| 48 +
arch/arm/cpu/armv8/{u-boot.lds = u-boot-spl.lds} | 74 +
arch/arm/include/asm/arch-fsl-lsch3/config.h |9 +++
arch/arm/lib/crt0_64.S|7 ++
board/freescale/ls2085aqds/MAINTAINERS|1 +
board/freescale/ls2085aqds/ddr.c |4 ++
common/spl/spl.c |2 +-
common/spl/spl_nand.c |2 +-
configs/ls2085aqds_nand_defconfig |4 ++
drivers/misc/fsl_ifc.c| 12
drivers/mtd/nand/fsl_ifc_spl.c|2 +-
include/configs/ls2085a_common.h | 29
include/configs/ls2085aqds.h | 50 --
15 files changed, 232 insertions(+), 51 deletions(-)
copy arch/arm/cpu/armv8/{u-boot.lds = u-boot-spl.lds} (57%)
create mode 100644 configs/ls2085aqds_nand_defconfig
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6ba4b8d..f73541c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -652,6 +652,7 @@ config TARGET_LS2085AQDS
bool Support ls2085aqds
select ARM64
select ARMV8_MULTIENTRY
+ select SUPPORT_SPL
help
Support for Freescale LS2085AQDS platform
The LS2085A Development System (QDS) is a high-performance
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/README
b/arch/arm/cpu/armv8/fsl-lsch3/README
index 4f36e2a..76fa9b1 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/README
+++ b/arch/arm/cpu/armv8/fsl-lsch3/README
@@ -95,3 +95,41 @@ mcboottimeout: MC boot timeout in milliseconds. If
this variable is not defined
mcmemsize: MC DRAM block size. If this variable is not defined, the value
CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE will be assumed.
+
+Booting from NAND
+---
+Booting from NAND requires two images, RCW and u-boot-with-spl.bin.
+The difference between NAND boot RCW image and NOR boot image is the PBI
+command sequence. Below is one example for PBI commands for QDS.
+
+1) CCSR 4-byte write to 0x00e00404, data=0x
+2) CCSR 4-byte write to 0x00e00400, data=0x1800a000
+The above two commands set bootloc register to 0x_1800a000 where
+the u-boot code will be running in OCRAM.
+
+3) Block Copy: SRC=0x0107, SRC_ADDR=0x0010, DEST_ADDR=0x1800a000,
+BLOCK_SIZE=0x00014000
+This command copies u-boot image from NAND device into OCRAM. The values need
+to adjust accordingly.
+
+SRCshould match the cfg_rcw_src, the reset config pins. It depends
+ on the NAND device. See reference manual for cfg_rcw_src.
+SRC_ADDR is the offset of u-boot image in NAND device. It should match
+ CONFIG_SYS_NAND_U_BOOT_OFFS. In the example above, it is 1MB.
+DEST_ADDR is fixed at 0x1800a000, matching bootloc set above.
+BLOCK_SIZE is the size to be copied by PBI.
+
+RCW image should be written to the beginning of NAND device. Example of using
+u-boot command
+
+nand write rcw image in memory 0 size of rcw image
+
+To form the NAND image, build u-boot with NAND config, for example,
+ls2085aqds_nand_defconfig. The image needed is u-boot-with-spl.bin.
+
+The u-boot image should be written to the offset CONFIG_SYS_NAND_U_BOOT_OFFS,
+in above example 0x10.
+
+nand write u-boot image in memory 10 size of u-boot image
+
+With these two images in NAND device, the board can boot from NAND.
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/soc.c
b/arch/arm/cpu/armv8/fsl-lsch3/soc.c
index 17700ef..ca00108 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/soc.c
+++ b/arch/arm/cpu/armv8/fsl-lsch3/soc.c
@@ -6,8 +6,13 @@
#include common.h
#include fsl_ifc.h
+#include nand.h
+#include spl.h
#include asm/arch-fsl-lsch3/soc.h
#include asm/io.h
+#include asm/global_data.h
+
+DECLARE_GLOBAL_DATA_PTR;
static void erratum_a008751(void)
{
@@ -18,8 +23,51 @@ static void erratum_a008751(void)
#endif
}
+static void erratum_rcw_src(void)
+{
+#if defined(CONFIG_SPL)
+ u32 __iomem *dcfg_ccsr = (u32 __iomem *)DCFG_BASE;
+ u32 __iomem *dcfg_dcsr = (u32 __iomem
[U-Boot] [PATCH v8 26/28] armv8/ls2085ardb: Enable NAND SPL support
From: Scott Wood scottw...@freescale.com
Enable NAND boot support using SPL framework. To boot from
NAND, either use DIP switches on board, or qixis_reset nand
command. Details of forming NAND image can be found in README.
Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: York Sun york...@freescale.com
---
Changes in v8:
Update README to add example for RDB NAND boot.
Changes in v7:
Move NAND boot instruction to fsl-lsch3/README.
Update board setting to put RCW and u-boot in different NAND block.
Changes in v6: None
Changes in v5:
Fix signed-off-by signature
Update LS2085ARDB README to include instructions to form NAND image
Changes in v4:
Update MAINTAINERS file
Changes in v3: None
Changes in v2: None
arch/arm/Kconfig |1 +
arch/arm/cpu/armv8/fsl-lsch3/README| 13 +++
board/freescale/ls2085ardb/MAINTAINERS |1 +
board/freescale/ls2085ardb/ddr.c |4
configs/ls2085ardb_nand_defconfig |4
include/configs/ls2085ardb.h | 40
6 files changed, 58 insertions(+), 5 deletions(-)
create mode 100644 configs/ls2085ardb_nand_defconfig
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f73541c..cf291c8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -663,6 +663,7 @@ config TARGET_LS2085ARDB
bool Support ls2085ardb
select ARM64
select ARMV8_MULTIENTRY
+ select SUPPORT_SPL
help
Support for Freescale LS2085ARDB platform.
The LS2085A Reference design board (RDB) is a high-performance
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/README
b/arch/arm/cpu/armv8/fsl-lsch3/README
index 76fa9b1..de53380 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/README
+++ b/arch/arm/cpu/armv8/fsl-lsch3/README
@@ -133,3 +133,16 @@ in above example 0x10.
nand write u-boot image in memory 10 size of u-boot image
With these two images in NAND device, the board can boot from NAND.
+
+Another example for RDB boards,
+
+1) CCSR 4-byte write to 0x00e00404, data=0x
+2) CCSR 4-byte write to 0x00e00400, data=0x1800a000
+3) Block Copy: SRC=0x0119, SRC_ADDR=0x0008, DEST_ADDR=0x1800a000,
+BLOCK_SIZE=0x00014000
+
+nand write rcw image in memory 0 size of rcw image
+nand write u-boot image in memory 8 size of u-boot image
+
+Notice the difference from QDS is SRC, SRC_ADDR and the offset of u-boot image
+to match board NAND device.
diff --git a/board/freescale/ls2085ardb/MAINTAINERS
b/board/freescale/ls2085ardb/MAINTAINERS
index 436039f..d5cce40 100644
--- a/board/freescale/ls2085ardb/MAINTAINERS
+++ b/board/freescale/ls2085ardb/MAINTAINERS
@@ -5,3 +5,4 @@ F: board/freescale/ls2085ardb/
F: board/freescale/ls2085a/ls2085ardb.c
F: include/configs/ls2085ardb.h
F: configs/ls2085ardb_defconfig
+F: configs/ls2085ardb_nand_defconfig
diff --git a/board/freescale/ls2085ardb/ddr.c b/board/freescale/ls2085ardb/ddr.c
index 6cd5e8b..8d71ae1 100644
--- a/board/freescale/ls2085ardb/ddr.c
+++ b/board/freescale/ls2085ardb/ddr.c
@@ -147,9 +147,13 @@ phys_size_t initdram(int board_type)
{
phys_size_t dram_size;
+#if defined(CONFIG_SPL) !defined(CONFIG_SPL_BUILD)
+ return fsl_ddr_sdram_size();
+#else
puts(Initializing DDRusing SPD\n);
dram_size = fsl_ddr_sdram();
+#endif
return dram_size;
}
diff --git a/configs/ls2085ardb_nand_defconfig
b/configs/ls2085ardb_nand_defconfig
new file mode 100644
index 000..39ba8c5
--- /dev/null
+++ b/configs/ls2085ardb_nand_defconfig
@@ -0,0 +1,4 @@
++S:CONFIG_SYS_EXTRA_OPTIONS=SYS_FSL_DDR4,NAND
++S:CONFIG_SPL=y
++S:CONFIG_ARM=y
++S:CONFIG_TARGET_LS2085ARDB=y
diff --git a/include/configs/ls2085ardb.h b/include/configs/ls2085ardb.h
index 0a5873b..ae5c2a9 100644
--- a/include/configs/ls2085ardb.h
+++ b/include/configs/ls2085ardb.h
@@ -139,11 +139,13 @@ unsigned long get_board_sys_clk(void);
#define QIXIS_LBMAP_SHIFT 0
#define QIXIS_LBMAP_DFLTBANK 0x00
#define QIXIS_LBMAP_ALTBANK0x04
+#define QIXIS_LBMAP_NAND 0x09
#define QIXIS_RST_CTL_RESET0x31
#define QIXIS_RST_CTL_RESET_EN 0x30
#define QIXIS_RCFG_CTL_RECONFIG_IDLE 0x20
#define QIXIS_RCFG_CTL_RECONFIG_START 0x21
#define QIXIS_RCFG_CTL_WATCHDOG_ENBLE 0x08
+#define QIXIS_RCW_SRC_NAND 0x119
#defineQIXIS_RST_FORCE_MEM 0x01
#define CONFIG_SYS_CSPR3_EXT (0x0)
@@ -169,6 +171,33 @@ unsigned long get_board_sys_clk(void);
FTIM2_GPCM_TWP(0x3E))
#define CONFIG_SYS_CS3_FTIM3 0x0
+#if defined(CONFIG_SPL) defined(CONFIG_NAND)
+#define CONFIG_SYS_CSPR2_EXT CONFIG_SYS_NOR0_CSPR_EXT
+#define CONFIG_SYS_CSPR2 CONFIG_SYS_NOR0_CSPR_EARLY
+#define CONFIG_SYS_CSPR2_FINAL CONFIG_SYS_NOR0_CSPR
+#define CONFIG_SYS_AMASK2 CONFIG_SYS_NOR_AMASK
+#define CONFIG_SYS_CSOR2
Re: [U-Boot] [PATCH v8 24/28] armv8/ls2085aqds: NAND boot support
On Tue, 2015-03-24 at 12:47 -0700, York Sun wrote: +Booting from NAND +--- +Booting from NAND requires two images, RCW and u-boot-with-spl.bin. +The difference between NAND boot RCW image and NOR boot image is the PBI +command sequence. Below is one example for PBI commands for QDS. + +1) CCSR 4-byte write to 0x00e00404, data=0x +2) CCSR 4-byte write to 0x00e00400, data=0x1800a000 +The above two commands set bootloc register to 0x_1800a000 where +the u-boot code will be running in OCRAM. + +3) Block Copy: SRC=0x0107, SRC_ADDR=0x0010, DEST_ADDR=0x1800a000, +BLOCK_SIZE=0x00014000 +This command copies u-boot image from NAND device into OCRAM. The values need +to adjust accordingly. + +SRC should match the cfg_rcw_src, the reset config pins. It depends + on the NAND device. See reference manual for cfg_rcw_src. +SRC_ADDR is the offset of u-boot image in NAND device. It should match + CONFIG_SYS_NAND_U_BOOT_OFFS. In the example above, it is 1MB. Why 1 MiB? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] multi-image uImage with fitImage
Hi Simon,
On 24/03/15 10:14, Simon Glass wrote:
Hi,
On 23 March 2015 at 00:40, fat loser george.clun...@gmail.com wrote:
Hi all,
I am currently attempting to port my combined uImage and ramdisk image +
dtb over to the fitImage format. I am creating a linux kernel + ramdisk
with buildroot and dt blob with buildroot. The .its I am using to create a
fitImage is below:
/dts-v1/;
/ {
description = Linux kernel;
#address-cells = 1;
images {
kernel@1 {
description = Linux kernel;
data = /incbin/(/tftpboot/uImage);
arch = arm;
os = linux;
type = multi;
What is multi? Do you want kernel or kernel_noload?
I read somewhere that multi can represent a kernel+ramdisk uImage (image with
ramdisk linked in.) If try to use kernel here, I get an error like: ERROR:
new format image overwritten - must RESET the board to recover
resetting ...
compression = none;
load = 0x89008000;
entry = 0x89008000;
};
fdt@1 {
description = Flattened Device Tree blob;
data = /incbin/(/tftpboot/arm.dtb);
type = flat_dt;
arch = arm;
compression = none;
};
};
configurations {
default = conf@1;
conf@1 {
description = Boot Linux kernel;
kernel = kernel@1;
fdt = fdt@1;
};
};
};
After tftp'ing the .itb over to address 0x8900 and running bootm, I get:
# bootm
## Loading kernel from FIT Image at 8900 ...
Using 'conf@1' configuration
Trying 'kernel@1' kernel subimage
Description: Linux kernel
Type: Multi-File Image
Compression: uncompressed
Data Start: 0x89d0
Data Size:28604352 Bytes = 27.3 MiB
Verifying Hash Integrity ... OK
No Linux ARM Kernel Image Image
ERROR: can't get kernel image!
The images work perfectly before I try to combine them into a fitImage.
Is there a special configuration option for multi-file (combined
ramdisk-kernel) images in fitImage?
Regards,
George.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Andre Wolokita (andre.wolok...@analog.com)
Design Engineer, Analog Devices Australia Pty Ltd
Unit 3, 97 Lewis Road, Wantirna, Victoria, 3152, AUSTRALIA
Direct: +61 3 9881 9933 Main: +61 3 9881
Fax: +61 3 9881 9988 Web: www.analog.com/au
Embedded DSP software for multimedia telecommunications.
This communication is proprietary and confidential.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1] net: Update hardware MAC address if it changes in env
When the ethaddr changes in the env, the hardware should also be updated
so that MAC filtering will work properly without resetting U-Boot.
Also remove the manual calls to set the hwaddr that was included in a
few drivers as a result of the framework not doing it.
Reported-by: Michal Simek michal.si...@xilinx.com
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
drivers/net/bcm-sf2-eth.c | 6 --
drivers/net/designware.c | 4
drivers/net/macb.c| 9 -
net/eth.c | 15 +--
4 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/net/bcm-sf2-eth.c b/drivers/net/bcm-sf2-eth.c
index 5252d49..9ae88d3 100644
--- a/drivers/net/bcm-sf2-eth.c
+++ b/drivers/net/bcm-sf2-eth.c
@@ -154,12 +154,6 @@ static int bcm_sf2_eth_open(struct eth_device *dev, bd_t
*bt)
debug(Enabling BCM SF2 Ethernet.\n);
- /* Set MAC address from env */
- if (bcm_sf2_eth_write_hwaddr(dev) != 0) {
- error(%s: MAC set error when opening !\n, __func__);
- return -1;
- }
-
eth-enable_mac();
/* enable tx and rx DMA */
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index cc01604..d35236b 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -244,10 +244,6 @@ static int dw_eth_init(struct eth_device *dev, bd_t *bis)
mdelay(100);
};
- /* Soft reset above clears HW address registers.
-* So we have to set it here once again */
- dw_write_hwaddr(dev);
-
rx_descs_init(dev);
tx_descs_init(dev);
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 170ff06..7d5b36b 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -525,7 +525,6 @@ static int macb_phy_init(struct macb_device *macb)
return 1;
}
-static int macb_write_hwaddr(struct eth_device *dev);
static int macb_init(struct eth_device *netdev, bd_t *bd)
{
struct macb_device *macb = to_macb(netdev);
@@ -594,14 +593,6 @@ static int macb_init(struct eth_device *netdev, bd_t *bd)
#endif /* CONFIG_RMII */
}
- /* update the ethaddr */
- if (is_valid_ether_addr(netdev-enetaddr)) {
- macb_write_hwaddr(netdev);
- } else {
- printf(%s: mac address is not valid\n, netdev-name);
- return -1;
- }
-
if (!macb_phy_init(macb))
return -1;
diff --git a/net/eth.c b/net/eth.c
index 13b7723..776fd2f 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -258,13 +258,24 @@ int eth_init(void)
if (device_active(current)) {
uchar env_enetaddr[6];
struct eth_pdata *pdata = current-platdata;
+ int enetaddr_changed = 0;
/* Sync environment with network device */
if (eth_getenv_enetaddr_by_index(eth, current-seq,
-env_enetaddr))
+env_enetaddr)) {
+ enetaddr_changed = memcmp(pdata-enetaddr,
+ env_enetaddr, 6);
memcpy(pdata-enetaddr, env_enetaddr, 6);
- else
+ } else {
+ memset(env_enetaddr, 0, 6);
+ enetaddr_changed = memcmp(pdata-enetaddr,
+ env_enetaddr, 6);
memset(pdata-enetaddr, 0, 6);
+ }
+ if (enetaddr_changed
+ eth_get_ops(current)-write_hwaddr) {
+ eth_get_ops(current)-write_hwaddr(current);
+ }
ret = eth_get_ops(current)-start(current);
if (ret = 0) {
--
1.7.11.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] net: Update hardware MAC address if it changes in env
On Tue, Mar 24, 2015 at 1:49 AM, Joe Hershberger joe.hershber...@ni.com wrote: When the ethaddr changes in the env, the hardware should also be updated so that MAC filtering will work properly without resetting U-Boot. Also remove the manual calls to set the hwaddr that was included in a few drivers as a result of the framework not doing it. Reported-by: Michal Simek michal.si...@xilinx.com Signed-off-by: Joe Hershberger joe.hershber...@ni.com --- drivers/net/bcm-sf2-eth.c | 6 -- drivers/net/designware.c | 4 drivers/net/macb.c| 9 - net/eth.c | 15 +-- 4 files changed, 13 insertions(+), 21 deletions(-) This requires dm/next ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] dm: i2c soft: enable driver model for software i2c driver
Hello Simon, Przemyslaw,
Am 24.03.2015 00:38, schrieb Simon Glass:
Hi Przemyslaw,
On 10 March 2015 at 04:30, Przemyslaw Marczak p.marc...@samsung.com wrote:
This change adds driver model support to software emulated
i2c bus driver. To bind the driver, proper device-tree node
must be defined, with the following attributes:
- alias: to keep proper bus order
- compatible: 'soft-i2c'
- clock-frequency [Hz]
- clock-pin, data-pin: gpio phandles
/* Define the alias number to keep bus numbering order */
aliases {
[...]
i2c5 = /i2c@1350;
i2c6 = /soft-i2c@1;
[...]
};
/* Define the basic bus attributes */
soft-i2c@1 {
#address-cells = 1;
#size-cells = 0;
compatible = soft-i2c;
clock-frequency = 5;
/* Define the proper GPIO pins */
clock-pin = gpa0 0 GPIO_ACTIVE_HIGH;
data-pin = gpa0 1 GPIO_ACTIVE_HIGH;
/* Optionally, define some driver node (bus child) */
somedev@0x44 {
compatible = somedev;
reg = 0x44;
[...]
};
};
The device can be accessed by the i2c command:
i2c dev 8 (bus number set by alias)
i2c probe 0x44(address is optionally)
i2c md 0x44 0x0 (dump dev registers at address 0x0)
Valid chip addresses: 0x44 (success!)
...
The previous driver functionality stays unchanged. Driving the bus lines
is done by dm gpio calls in the preprocessor macros. Each, can be redefined
by the user as previous.
Tested on Trats2 and Odroid U3.
Is the intention to retire the old (non-driver-model) code? What boards use it?
I think not ... Hmm ... maybe you move the new code into
a new file?
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Mike Frysinger vap...@gentoo.org
Cc: Simon Glass s...@chromium.org
Cc: Heiko Schocher h...@denx.de
Hups... seems I missed this patches ...
---
drivers/i2c/Makefile | 1 +
drivers/i2c/soft_i2c.c | 410 +++--
2 files changed, 400 insertions(+), 11 deletions(-)
Thanks for this work!
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 774bc94..7039b6d 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -6,6 +6,7 @@
#
obj-$(CONFIG_DM_I2C) += i2c-uclass.o
obj-$(CONFIG_DM_I2C_COMPAT) += i2c-uclass-compat.o
+obj-$(CONFIG_DM_I2C_SOFT) += soft_i2c.o
obj-$(CONFIG_SYS_I2C_ADI) += adi_i2c.o
obj-$(CONFIG_I2C_MV) += mv_i2c.o
diff --git a/drivers/i2c/soft_i2c.c b/drivers/i2c/soft_i2c.c
index db9b402..7afae0b 100644
--- a/drivers/i2c/soft_i2c.c
+++ b/drivers/i2c/soft_i2c.c
@@ -1,4 +1,7 @@
/*
+ * (C) Copyright 2015, Samsung Electronics
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
* (C) Copyright 2009
* Heiko Schocher, DENX Software Engineering, h...@denx.de.
* Changes for multibus/multiadapter I2C support.
@@ -14,6 +17,11 @@
*/
#include common.h
+#include errno.h
+#include dm.h
+#include i2c.h
+#include div64.h
+#include asm/gpio.h
#ifdef CONFIG_MPC8260 /* only valid for MPC8260 */
#include ioports.h
#include asm/io.h
@@ -32,11 +40,9 @@
#if defined(CONFIG_MPC852T) || defined(CONFIG_MPC866)
#include asm/io.h
#endif
-#include i2c.h
+#if defined(CONFIG_SYS_I2C)
#if defined(CONFIG_SOFT_I2C_GPIO_SCL)
-# include asm/gpio.h
-
# ifndef I2C_GPIO_SYNC
# define I2C_GPIO_SYNC
# endif
@@ -85,6 +91,7 @@
# endif
#endif
+#endif
/* #define DEBUG_I2C */
@@ -109,6 +116,65 @@ DECLARE_GLOBAL_DATA_PTR;
#define CONFIG_SYS_I2C_SOFT_SLAVE CONFIG_SYS_I2C_SLAVE
#endif
+/* DM SOFT I2C */
+#ifdef CONFIG_DM_I2C_SOFT
+# ifndef I2C_GPIO_SYNC
+# define I2C_GPIO_SYNC(gpio)
+# endif
+
+# ifndef I2C_INIT
+# define I2C_INIT(scl, sda) \
+ do { } while (0)
+# endif
+
+# ifndef I2C_ACTIVE
+# define I2C_ACTIVE(sda) \
+ do { } while (0)
+# endif
+
+# ifndef I2C_TRISTATE
+# define I2C_TRISTATE(sda) \
+ do { } while (0)
+# endif
+
+# ifndef I2C_READ
+# define I2C_READ(sda) dm_gpio_get_value(sda);
+# endif
+
+# ifndef I2C_SDA
+# define I2C_SDA(sda, bit) \
+ do { \
+ if (bit) { \
+ sda-flags = ~GPIOD_IS_OUT; \
+ sda-flags |= GPIOD_IS_IN; \
+ dm_gpio_set_dir(sda); \
+ } else { \
+ sda-flags = ~GPIOD_IS_IN; \
+ sda-flags |= GPIOD_IS_OUT; \
+ dm_gpio_set_dir(sda); \
+ dm_gpio_set_value(sda, 0); \
+ } \
+ I2C_GPIO_SYNC(sda); \
+ } while (0)
+# endif
+
+# ifndef I2C_SCL
+# define I2C_SCL(scl, bit) \
+ do { \
+ scl-flags = ~GPIOD_IS_IN; \
+ scl-flags |= GPIOD_IS_OUT; \
+ dm_gpio_set_dir(scl); \
+ dm_gpio_set_value(scl, bit); \
+ I2C_GPIO_SYNC(scl); \
+ } while
[U-Boot] [PATCH] Change defconfigs to include driver model (required after v2015.01), and fix typo in EEProm config format.
Signed-off-by: Gilles Gameiro gil...@gigadevices.com
---
board/birdland/bav335x/board.h | 2 +-
configs/birdland_bav335a_defconfig | 356 -
configs/birdland_bav335b_defconfig | 356 -
3 files changed, 709 insertions(+), 5 deletions(-)
diff --git a/board/birdland/bav335x/board.h b/board/birdland/bav335x/board.h
index b598ce1..1ea681e 100644
--- a/board/birdland/bav335x/board.h
+++ b/board/birdland/bav335x/board.h
@@ -33,7 +33,7 @@ struct board_eeconfig {
unsigned int magic;
char name[HDR_NAME_LEN];/* BAV3354 */
char version[4];/* 0B20 - Rev.B2 */
- char serial[12];
+ char serial[16];
char config[32];
char mac_addr[HDR_NO_OF_MAC_ADDR][HDR_ETH_ALEN];
};
diff --git a/configs/birdland_bav335a_defconfig
b/configs/birdland_bav335a_defconfig
index 60df411..09aea16 100644
--- a/configs/birdland_bav335a_defconfig
+++ b/configs/birdland_bav335a_defconfig
@@ -1,5 +1,357 @@
-CONFIG_SPL=y
-CONFIG_SYS_EXTRA_OPTIONS=SERIAL1,CONS_INDEX=1
+#
+# Automatically generated file; DO NOT EDIT.
+# U-Boot 2015.04-rc4 Configuration
+#
+# CONFIG_ARC is not set
CONFIG_ARM=y
+# CONFIG_AVR32 is not set
+# CONFIG_BLACKFIN is not set
+# CONFIG_M68K is not set
+# CONFIG_MICROBLAZE is not set
+# CONFIG_MIPS is not set
+# CONFIG_NDS32 is not set
+# CONFIG_NIOS2 is not set
+# CONFIG_OPENRISC is not set
+# CONFIG_PPC is not set
+# CONFIG_SANDBOX is not set
+# CONFIG_SH is not set
+# CONFIG_SPARC is not set
+# CONFIG_X86 is not set
+CONFIG_SYS_ARCH=arm
+CONFIG_SYS_CPU=armv7
+CONFIG_SYS_SOC=am33xx
+CONFIG_SYS_VENDOR=birdland
+CONFIG_SYS_BOARD=bav335x
+CONFIG_SYS_CONFIG_NAME=bav335x
+# CONFIG_USE_PRIVATE_LIBGCC is not set
+
+#
+# ARM architecture
+#
+CONFIG_HAS_VBAR=y
+CONFIG_CPU_V7=y
+# CONFIG_SEMIHOSTING is not set
+# CONFIG_TARGET_INTEGRATORAP_CM720T is not set
+# CONFIG_TARGET_INTEGRATORAP_CM920T is not set
+# CONFIG_TARGET_INTEGRATORCP_CM920T is not set
+# CONFIG_ARCH_AT91 is not set
+# CONFIG_TARGET_EDB93XX is not set
+# CONFIG_TARGET_SCB9328 is not set
+# CONFIG_TARGET_VCMA9 is not set
+# CONFIG_TARGET_SMDK2410 is not set
+# CONFIG_TARGET_INTEGRATORAP_CM926EJS is not set
+# CONFIG_TARGET_INTEGRATORCP_CM926EJS is not set
+# CONFIG_TARGET_ASPENITE is not set
+# CONFIG_TARGET_GPLUGD is not set
+# CONFIG_ARCH_DAVINCI is not set
+# CONFIG_KIRKWOOD is not set
+# CONFIG_TARGET_DB_MV784MP_GP is not set
+# CONFIG_TARGET_MAXBCM is not set
+# CONFIG_TARGET_DEVKIT3250 is not set
+# CONFIG_TARGET_MX25PDK is not set
+# CONFIG_TARGET_TX25 is not set
+# CONFIG_TARGET_ZMX25 is not set
+# CONFIG_TARGET_APF27 is not set
+# CONFIG_TARGET_IMX27LITE is not set
+# CONFIG_TARGET_MAGNESIUM is not set
+# CONFIG_TARGET_APX4DEVKIT is not set
+# CONFIG_TARGET_XFI3 is not set
+# CONFIG_TARGET_M28EVK is not set
+# CONFIG_TARGET_MX23EVK is not set
+# CONFIG_TARGET_MX28EVK is not set
+# CONFIG_TARGET_MX23_OLINUXINO is not set
+# CONFIG_TARGET_BG0900 is not set
+# CONFIG_TARGET_SANSA_FUZE_PLUS is not set
+# CONFIG_TARGET_SC_SPS_1 is not set
+# CONFIG_ARCH_NOMADIK is not set
+# CONFIG_ORION5X is not set
+# CONFIG_TARGET_SPEAR300 is not set
+# CONFIG_TARGET_SPEAR310 is not set
+# CONFIG_TARGET_SPEAR320 is not set
+# CONFIG_TARGET_SPEAR600 is not set
+# CONFIG_TARGET_STV0991 is not set
+# CONFIG_TARGET_X600 is not set
+# CONFIG_ARCH_VERSATILE is not set
+# CONFIG_TARGET_INTEGRATORCP_CM1136 is not set
+# CONFIG_TARGET_IMX31_PHYCORE is not set
+# CONFIG_TARGET_QONG is not set
+# CONFIG_TARGET_MX31ADS is not set
+# CONFIG_TARGET_MX31PDK is not set
+# CONFIG_TARGET_TT01 is not set
+# CONFIG_TARGET_IMX31_LITEKIT is not set
+# CONFIG_TARGET_WOODBURN is not set
+# CONFIG_TARGET_WOODBURN_SD is not set
+# CONFIG_TARGET_FLEA3 is not set
+# CONFIG_TARGET_MX35PDK is not set
+# CONFIG_TARGET_RPI is not set
+# CONFIG_TARGET_RPI_2 is not set
+# CONFIG_TARGET_INTEGRATORAP_CM946ES is not set
+# CONFIG_TARGET_INTEGRATORCP_CM946ES is not set
+# CONFIG_TARGET_VEXPRESS_CA15_TC2 is not set
+# CONFIG_TARGET_VEXPRESS_CA5X2 is not set
+# CONFIG_TARGET_VEXPRESS_CA9X4 is not set
+# CONFIG_TARGET_KWB is not set
+# CONFIG_TARGET_TSERIES is not set
+# CONFIG_TARGET_CM_T335 is not set
+# CONFIG_TARGET_PEPPER is not set
+# CONFIG_TARGET_AM335X_IGEP0033 is not set
+# CONFIG_TARGET_PCM051 is not set
+# CONFIG_TARGET_DRACO is not set
+# CONFIG_TARGET_DXR2 is not set
+# CONFIG_TARGET_PXM2 is not set
+# CONFIG_TARGET_RUT is not set
+# CONFIG_TARGET_PENGWYN is not set
+# CONFIG_TARGET_AM335X_EVM is not set
+# CONFIG_TARGET_AM43XX_EVM is not set
CONFIG_TARGET_BAV335X=y
+# CONFIG_TARGET_TI814X_EVM is not set
+# CONFIG_TARGET_TI816X_EVM is not set
+# CONFIG_TARGET_BCM28155_AP is not set
+# CONFIG_TARGET_BCMCYGNUS is not set
+# CONFIG_TARGET_BCMNSP is not set
+# CONFIG_ARCH_EXYNOS is not set
+# CONFIG_ARCH_S5PC1XX is not set
+# CONFIG_ARCH_HIGHBANK is not set
+# CONFIG_ARCH_KEYSTONE is not set
+# CONFIG_TARGET_M53EVK is not set
+# CONFIG_TARGET_IMA3_MX53 is
[U-Boot] [PATCH 0/1] Adding Support for the BAV335x boards.
This patch adds support for the BAV335x Network Processor boards. It supports both the Rev.A 10/100GB, and Rev.B with GB ethernet. Gilles Gameiro (1): Change defconfigs to include driver model (required after v2015.01), and fix typo in EEProm config format. board/birdland/bav335x/board.h | 2 +- configs/birdland_bav335a_defconfig | 356 - configs/birdland_bav335b_defconfig | 356 - 3 files changed, 709 insertions(+), 5 deletions(-) -- 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 5/7] malloc_f: enable SYS_MALLOC_F by default if DM is on
On 03/19/2015 11:42 AM, Masahiro Yamada wrote: This option has a bool type, not hex. Fix it and enable it if CONFIG_DM is on because Driver Model always requires malloc memory. Devices are scanned twice, before/after relocation. CONFIG_SYS_MALLOC_F should be enabled to use malloc memory before relocation. As it is board-independent, handle it globally. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com Acked-by: Stephen Warren swar...@wwwdotorg.org Acked-by: Robert Baldyga r.bald...@samsung.com --- Changes in v2: - Fix a typo s/not board-independent/board-independent/ Kconfig | 2 +- arch/arm/cpu/armv7/exynos/Kconfig | 3 --- arch/arm/cpu/armv7/omap3/Kconfig | 3 --- arch/arm/mach-tegra/Kconfig | 3 --- arch/arm/mach-uniphier/Kconfig| 3 --- arch/x86/Kconfig | 3 --- board/amcc/canyonlands/Kconfig| 4 board/ti/am335x/Kconfig | 3 --- configs/Linksprite_pcDuino3_fdt_defconfig | 1 - configs/am335x_igep0033_defconfig | 1 - configs/cm_fx6_defconfig | 1 - configs/cm_t335_defconfig | 1 - configs/mx6dlsabreauto_defconfig | 1 - configs/mx6qsabreauto_defconfig | 1 - configs/mx6qsabresd_defconfig | 1 - configs/mx6sxsabresd_defconfig| 1 - configs/nokia_rx51_defconfig | 1 - configs/pcm051_rev1_defconfig | 1 - configs/pcm051_rev3_defconfig | 1 - configs/pengwyn_defconfig | 1 - configs/pepper_defconfig | 1 - configs/rpi_2_defconfig | 1 - configs/rpi_defconfig | 1 - configs/s5p_goni_defconfig| 1 - configs/sandbox_defconfig | 1 - configs/smdkc100_defconfig| 1 - configs/snapper9260_defconfig | 1 - configs/snapper9g20_defconfig | 1 - configs/stv0991_defconfig | 1 - include/configs/rcar-gen2-common.h| 2 -- 30 files changed, 1 insertion(+), 46 deletions(-) diff --git a/Kconfig b/Kconfig index 8f96c94..b5968d7 100644 --- a/Kconfig +++ b/Kconfig @@ -54,7 +54,7 @@ config CC_OPTIMIZE_FOR_SIZE config SYS_MALLOC_F bool Enable malloc() pool before relocation - default 0x400 + default y if DM help Before relocation memory is very limited on many platforms. Still, we can provide a small malloc() pool if needed. Driver model in diff --git a/arch/arm/cpu/armv7/exynos/Kconfig b/arch/arm/cpu/armv7/exynos/Kconfig index 9e47ed3..bd7540a 100644 --- a/arch/arm/cpu/armv7/exynos/Kconfig +++ b/arch/arm/cpu/armv7/exynos/Kconfig @@ -80,9 +80,6 @@ config DM_SPI_FLASH config DM_GPIO default y -config SYS_MALLOC_F - default y - source board/samsung/smdkv310/Kconfig source board/samsung/trats/Kconfig source board/samsung/universal_c210/Kconfig diff --git a/arch/arm/cpu/armv7/omap3/Kconfig b/arch/arm/cpu/armv7/omap3/Kconfig index aa2ff46..1f96498 100644 --- a/arch/arm/cpu/armv7/omap3/Kconfig +++ b/arch/arm/cpu/armv7/omap3/Kconfig @@ -106,9 +106,6 @@ config DM_GPIO config DM_SERIAL default y if DM -config SYS_MALLOC_F - default y if DM - config SYS_SOC default omap3 diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig index fccfd79..fce1c1d 100644 --- a/arch/arm/mach-tegra/Kconfig +++ b/arch/arm/mach-tegra/Kconfig @@ -17,9 +17,6 @@ config TEGRA124 endchoice -config SYS_MALLOC_F - default y - config SYS_MALLOC_F_LEN default 0x1800 diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig index b6dc75f..20e20a5 100644 --- a/arch/arm/mach-uniphier/Kconfig +++ b/arch/arm/mach-uniphier/Kconfig @@ -48,9 +48,6 @@ config DCC_MICRO_SUPPORT_CARD endchoice -config SYS_MALLOC_F - default y - config CMD_PINMON bool Enable boot mode pins monitor command default y diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 35d24e4..da27115 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -76,9 +76,6 @@ config DM_GPIO config DM_SERIAL default y -config SYS_MALLOC_F - default y - config SYS_MALLOC_F_LEN default 0x800 diff --git a/board/amcc/canyonlands/Kconfig b/board/amcc/canyonlands/Kconfig index c0dbd18..46efa7a 100644 --- a/board/amcc/canyonlands/Kconfig +++ b/board/amcc/canyonlands/Kconfig @@ -39,8 +39,4 @@ config DM config DM_SERIAL default y -config SYS_MALLOC_F - bool - default y - endif diff --git a/board/ti/am335x/Kconfig b/board/ti/am335x/Kconfig index 8c45892..7cb006f 100644 --- a/board/ti/am335x/Kconfig +++ b/board/ti/am335x/Kconfig @@ -47,7 +47,4 @@ config DM_GPIO config DM_SERIAL default y if DM -config SYS_MALLOC_F - default y if DM
Re: [U-Boot] [PATCH v3 4/7] malloc_f: remove redundant defalut values of CONFIG_SYS_MALLOC_F_LEN
On 03/19/2015 11:42 AM, Masahiro Yamada wrote: The default value of CONFIG_SYS_MALLOC_F_LEN is defined by ./Kconfig as 0x400. Each defconfig or Kconfig need not repeat the same value. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com Acked-by: Stephen Warren swar...@wwwdotorg.org Acked-by: Robert Baldyga r.bald...@samsung.com --- Changes in v2: None arch/arm/cpu/armv7/exynos/Kconfig | 3 --- arch/arm/cpu/armv7/omap3/Kconfig | 3 --- arch/arm/mach-uniphier/Kconfig| 3 --- board/amcc/canyonlands/Kconfig| 4 board/ti/am335x/Kconfig | 3 --- configs/Linksprite_pcDuino3_fdt_defconfig | 1 - configs/am335x_igep0033_defconfig | 1 - configs/cm_fx6_defconfig | 1 - configs/cm_t335_defconfig | 1 - configs/gwventana_defconfig | 1 - configs/mx6dlsabreauto_defconfig | 1 - configs/mx6qsabreauto_defconfig | 1 - configs/mx6qsabresd_defconfig | 1 - configs/mx6sxsabresd_defconfig| 1 - configs/nokia_rx51_defconfig | 1 - configs/pcm051_rev1_defconfig | 1 - configs/pcm051_rev3_defconfig | 1 - configs/pengwyn_defconfig | 1 - configs/pepper_defconfig | 1 - configs/rpi_2_defconfig | 1 - configs/rpi_defconfig | 1 - configs/s5p_goni_defconfig| 1 - configs/sandbox_defconfig | 1 - configs/smdkc100_defconfig| 1 - configs/snapper9260_defconfig | 1 - configs/snapper9g20_defconfig | 1 - 26 files changed, 37 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/Kconfig b/arch/arm/cpu/armv7/exynos/Kconfig index eb86a7f..9e47ed3 100644 --- a/arch/arm/cpu/armv7/exynos/Kconfig +++ b/arch/arm/cpu/armv7/exynos/Kconfig @@ -83,9 +83,6 @@ config DM_GPIO config SYS_MALLOC_F default y -config SYS_MALLOC_F_LEN - default 0x400 - source board/samsung/smdkv310/Kconfig source board/samsung/trats/Kconfig source board/samsung/universal_c210/Kconfig diff --git a/arch/arm/cpu/armv7/omap3/Kconfig b/arch/arm/cpu/armv7/omap3/Kconfig index 65da6e2..aa2ff46 100644 --- a/arch/arm/cpu/armv7/omap3/Kconfig +++ b/arch/arm/cpu/armv7/omap3/Kconfig @@ -109,9 +109,6 @@ config DM_SERIAL config SYS_MALLOC_F default y if DM -config SYS_MALLOC_F_LEN - default 0x400 if DM - config SYS_SOC default omap3 diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig index 8335685..b6dc75f 100644 --- a/arch/arm/mach-uniphier/Kconfig +++ b/arch/arm/mach-uniphier/Kconfig @@ -51,9 +51,6 @@ endchoice config SYS_MALLOC_F default y -config SYS_MALLOC_F_LEN - default 0x400 - config CMD_PINMON bool Enable boot mode pins monitor command default y diff --git a/board/amcc/canyonlands/Kconfig b/board/amcc/canyonlands/Kconfig index 848e08f..c0dbd18 100644 --- a/board/amcc/canyonlands/Kconfig +++ b/board/amcc/canyonlands/Kconfig @@ -43,8 +43,4 @@ config SYS_MALLOC_F bool default y -config SYS_MALLOC_F_LEN - hex - default 0x400 - endif diff --git a/board/ti/am335x/Kconfig b/board/ti/am335x/Kconfig index 722f9d5..8c45892 100644 --- a/board/ti/am335x/Kconfig +++ b/board/ti/am335x/Kconfig @@ -50,7 +50,4 @@ config DM_SERIAL config SYS_MALLOC_F default y if DM -config SYS_MALLOC_F_LEN - default 0x400 if DM - endif diff --git a/configs/Linksprite_pcDuino3_fdt_defconfig b/configs/Linksprite_pcDuino3_fdt_defconfig index 1504664..87dd38f 100644 --- a/configs/Linksprite_pcDuino3_fdt_defconfig +++ b/configs/Linksprite_pcDuino3_fdt_defconfig @@ -14,4 +14,3 @@ CONFIG_DRAM_CLK=480 CONFIG_DRAM_ZQ=122 CONFIG_DRAM_EMR1=4 CONFIG_SYS_MALLOC_F=y -CONFIG_SYS_MALLOC_F_LEN=0x400 diff --git a/configs/am335x_igep0033_defconfig b/configs/am335x_igep0033_defconfig index 8d38e26..a439298 100644 --- a/configs/am335x_igep0033_defconfig +++ b/configs/am335x_igep0033_defconfig @@ -4,4 +4,3 @@ CONFIG_SPL_STACK_R_ADDR=0x8200 CONFIG_ARM=y CONFIG_TARGET_AM335X_IGEP0033=y CONFIG_SYS_MALLOC_F=y -CONFIG_SYS_MALLOC_F_LEN=0x400 diff --git a/configs/cm_fx6_defconfig b/configs/cm_fx6_defconfig index 2fd21cf..00cbdd2 100644 --- a/configs/cm_fx6_defconfig +++ b/configs/cm_fx6_defconfig @@ -6,4 +6,3 @@ CONFIG_DM=y CONFIG_DM_GPIO=y CONFIG_DM_SERIAL=y CONFIG_SYS_MALLOC_F=y -CONFIG_SYS_MALLOC_F_LEN=0x400 diff --git a/configs/cm_t335_defconfig b/configs/cm_t335_defconfig index 086e526..31705f2 100644 --- a/configs/cm_t335_defconfig +++ b/configs/cm_t335_defconfig @@ -2,4 +2,3 @@ CONFIG_SPL=y CONFIG_ARM=y CONFIG_TARGET_CM_T335=y CONFIG_SYS_MALLOC_F=y -CONFIG_SYS_MALLOC_F_LEN=0x400 diff --git a/configs/gwventana_defconfig b/configs/gwventana_defconfig index 6eab019..d6bbdc1 100644 ---
Re: [U-Boot] [PATCH 6/6] armv8: Allow SoCs to override the generic timer
hi Thierry, -Original Messages- From: Thierry Reding thierry.red...@gmail.com Sent Time: 2015-03-20 19:47:53 (Friday) To: u-boot@lists.denx.de Cc: Marc Zyngier marc.zyng...@arm.com Subject: [U-Boot] [PATCH 6/6] armv8: Allow SoCs to override the generic timer From: Thierry Reding tred...@nvidia.com Some SoCs come with a custom timer interface, so allow them to use that instead. Arch timer is always available when core running, It's better to use arch timer instead of other custom timer interface. Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Marc Zyngier marc.zyng...@arm.com Signed-off-by: Thierry Reding tred...@nvidia.com --- arch/arm/cpu/armv8/generic_timer.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/armv8/generic_timer.c b/arch/arm/cpu/armv8/generic_timer.c index 223b95e210ed..ab8573fc7cef 100644 --- a/arch/arm/cpu/armv8/generic_timer.c +++ b/arch/arm/cpu/armv8/generic_timer.c @@ -9,6 +9,7 @@ #include command.h #include asm/system.h +#ifndef CONFIG_SYS_TIMER_COUNTER /* * Generic timer implementation of get_tbclk() */ @@ -29,3 +30,4 @@ unsigned long timer_read_counter(void) asm volatile(mrs %0, cntpct_el0 : =r (cntpct)); return cntpct; } +#endif -- 2.3.2 Yours. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 3/3] rpi: add support for Raspberry Pi 2 model B
On 02/19/2015 01:50 AM, Masahiro Yamada wrote: On Wed, 18 Feb 2015 23:00:36 -0700 Stephen Warren swar...@wwwdotorg.org wrote: On 02/17/2015 01:22 PM, Tom Rini wrote: On Tue, Feb 17, 2015 at 12:35:41PM -0700, Stephen Warren wrote: On 02/16/2015 06:03 PM, Tom Rini wrote: On Mon, Feb 16, 2015 at 12:16:15PM -0700, Stephen Warren wrote: USB doesn't seem to work yet; the controller detects the on-board Hub/ Ethernet device but can't read the descriptors from it. I haven't investigated yet. Signed-off-by: Stephen Warren swar...@wwwdotorg.org --- v3: Rebased on top of u-boot-dm merge. v2: Implement new board_rev decoding scheme, to avoid hard-coding the board revision onthe RPi 2. +(rpi_2) make[3]: *** No rule to make target `arch/arm/cpu/armv7/bcm2835/../../arm1176/bcm2835//init.o', needed by `arch/arm/cpu/armv7/bcm2835/built-in.o'. Stop. +(rpi_2) make[2]: *** [arch/arm/cpu/armv7/bcm2835] Error 2 +(rpi_2) make[1]: *** [arch/arm/cpu/armv7] Error 2 When I try and build it with buildman. Something get left out somewhere? Thanks! I've reproduced this error on my machine at work, where I previously worked out the right stuff to put into ~/.buildman. Now that I try the regular build process (in-tree build using just make) multiple times after a git clean -f -d -x , I see the same error that way too, sometimes, so it's nothing to do with buildman. However, I don't always get the error with either plain make or with buildman, and it doesn't always complain about the same file: +make[1]: *** No rule to make target `arch//cpu/u-boot.lds', needed by `u-boot.lds'. Stop. +make[3]: *** No rule to make target `arch/arm/cpu/armv7/bcm2835/../../arm1176/bcm2835//init.o', needed by `arch/arm/cpu/armv7/bcm2835/built-in.o'. Stop. This isn't anything to do with these patches; I can see the exact same issue building the following existing boards in unmodified u-boot/master: rpi (arm1176, no SPL) tnetv107x_evm_defconfigs (arm1176 no SPL) mx35pdk_defconfig (arm1136, no SPL) nhk8815_defconfig (arm926ejs, no SPL) imx27lite_defconfig (arm926ejs, SPL) vexpress_ca15_tc2_defconfig (ARMv7, no SPL) Strangely I don't see the issue for: seaboard (ARMv7, SPL) maxbcm_defconfig (ARMv7, SPL) I wonder if bisecting would show up where this issue was introduced. I bet it will and I bet it's when we switch to Kconfig. Masahiro, any ideas? Yes, a git bisect (running up to 100 successful builds to test each commit, or failing on the first failure) says: first bad commit: [51148790f26e42ef1fd4a1a8d056bf0252539525] kconfig: switch to Kconfig (which was applied at the end of July last year) Interesting: The problem never seems to happen on my laptop (where I do all my rpi dev work), but is quite easy to reproduce on my faster machine at work. I would guess it only affects parallel builds in certain timing circumstances, but haven't checked that. Sorry for my late reply and inconveniene about this. I recongnize this problem is the same as what has been reported by some people for a few months. Although I have never been able to reproduce this problem (I guess my computer is too slow...), I do understand this is a real, significant and urgent problem. I bet the root cause of this issue is the following lines. autoconf_is_current := $(if $(wildcard $(KCONFIG_CONFIG)),$(shell find . \ -path ./include/config/auto.conf -newer $(KCONFIG_CONFIG))) ifneq ($(autoconf_is_current),) include $(srctree)/config.mk include $(srctree)/arch/$(ARCH)/Makefile endif This comes from the difference about how ARCH is given. In Linux, ARCH is given from the command line by the user, so the correct arch/$(ARCH)/Makefile can be always included. In U-boot, on the other hand, ARCH is decided by Kconfig. It is impossible to include arch/$(ARCH)/Makefile until Kconfig creates the include/configs/auto.conf for the target board, i.e. make silentoldconfig is done. I do not know the reason exactly, but $(autoconf_is_current) might not be set correctly in some cases depending on some race condition. Of course, if we adopted the ARCH from the command line, this problem would immediately go away, but I am not sure how many people are happy about the more typing every time, considering that most of the target boards of U-Boot use cross-compiling. I will take a closer look on it, but I am doing some big changes for the build system. - single .config switch ( I have just posted the series.) - Moving SoC directoryarch/arm/cpu/$(CPU)/$(SOC) - arch/arm/mach-$(SOC) As usual, I'd like to solve the problems one by one, so as not to mess up things by big conflicts. Was there any progress on this front? I'm still seeing the problem in latest u-boot.git master branch. I've been hitting it a little more often today; not sure if the repro frequency has changed or if I just did a few more builds than usual? ___ U-Boot mailing list U-Boot@lists.denx.de
[U-Boot] [PATCH v3 08/17] dm: regulator: add regulator command
This command is based on driver model regulator api.
User interface features:
- list - list UCLASS regulator devices
- regulator dev [id] - show or [set] operating regulator device
- regulator [info] - print constraints info
- regulator [status] - print operating status
- regulator [value] [-f] - print/[set] voltage value [uV] (force)
- regulator [current]- print/[set] current value [uA]
- regulator [mode_id]- print/[set] operating mode id
- regulator [enable] - enable the regulator output
- regulator [disable]- disable the regulator output
The 'force' option can be used for setting the value which exceeds the limits,
which are found in device-tree and are keept in regulators info structure.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes v3:
- new file
- Kconfig entry
---
common/Kconfig | 22 +++
common/Makefile| 1 +
common/cmd_regulator.c | 385 +
3 files changed, 408 insertions(+)
create mode 100644 common/cmd_regulator.c
diff --git a/common/Kconfig b/common/Kconfig
index 1125e6d..48f360f 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -348,5 +348,27 @@ config DM_PMIC_CMD
- pmic read address - read byte of register at address
- pmic write address - write byte to register at address
The only one change for this command is 'dev' subcommand.
+
+config DM_REGULATOR_CMD
+ bool Enable Driver Model REGULATOR command
+ depends on DM_REGULATOR
+ help
+ This command is based on driver model regulator api.
+ User interface features:
+ - list - list UCLASS regulator devices
+ - regulator dev [id] - show or [set] operating regulator device
+ - regulator [info] - print constraints info
+ - regulator [status] - print operating status
+ - regulator [value] [-f] - print/[set] voltage value [uV] (force)
+ - regulator [current]- print/[set] current value [uA]
+ - regulator [mode_id]- print/[set] operating mode id
+ - regulator [enable] - enable the regulator output
+ - regulator [disable]- disable the regulator output
+
+ The 'force' option can be used for setting the value which exceeds
+ the limit which are found in device-tree and are keept in regulators
+ info structure.
+
endmenu
+
endmenu
diff --git a/common/Makefile b/common/Makefile
index d908851..d63fe12 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -211,6 +211,7 @@ obj-$(CONFIG_CMD_GPT) += cmd_gpt.o
# Power
obj-$(CONFIG_DM_PMIC_CMD) += cmd_pmic.o
+obj-$(CONFIG_DM_REGULATOR_CMD) += cmd_regulator.o
endif
ifdef CONFIG_SPL_BUILD
diff --git a/common/cmd_regulator.c b/common/cmd_regulator.c
new file mode 100644
index 000..d388b14
--- /dev/null
+++ b/common/cmd_regulator.c
@@ -0,0 +1,385 @@
+/*
+ * Copyright (C) 2014-2015 Samsung Electronics
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include common.h
+#include linux/types.h
+#include linux/ctype.h
+#include fdtdec.h
+#include dm.h
+#include power/pmic.h
+#include power/regulator.h
+#include dm/device-internal.h
+#include dm/uclass-internal.h
+#include dm/root.h
+#include dm/lists.h
+#include i2c.h
+#include compiler.h
+#include errno.h
+
+#define LIMIT_SEQ 3
+#define LIMIT_DEVNAME 20
+#define LIMIT_OFNAME 20
+#define LIMIT_INFO 12
+
+static struct udevice *reg_curr;
+
+static int failed(const char *getset, const char *thing,
+ const char *for_dev, int ret)
+{
+ printf(Can't %s %s %s.\nError: %d (%s)\n, getset, thing, for_dev,
+ ret, errno_str(ret));
+ return CMD_RET_FAILURE;
+}
+
+static int do_dev(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ struct dm_regulator_info *info;
+ int seq, ret = CMD_RET_FAILURE;
+
+ switch (argc) {
+ case 2:
+ seq = simple_strtoul(argv[1], NULL, 0);
+ uclass_get_device_by_seq(UCLASS_REGULATOR, seq, reg_curr);
+ case 1:
+ ret = regulator_info(reg_curr, info);
+ if (ret)
+ return failed(get, the, device, ret);
+
+ printf(dev: %d @ %s\n, reg_curr-seq, info-name);
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
+static int get_curr_dev_and_info(struct udevice **devp,
+struct dm_regulator_info **infop)
+{
+ int ret = -ENODEV;
+
+ *devp = reg_curr;
+ if (!*devp)
+ return failed(get, current, device, ret);
+
+ ret = regulator_info(*devp, infop);
+ if (ret)
+ return failed(get, reg_curr-name, info, ret);
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_list(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ struct dm_regulator_info
[U-Boot] [PATCH v3 10/17] dm: pmic: add max77686 pmic driver
This is the implementation of driver model uclass pmic driver.
The max77686 pmic driver implements read/write operations and driver
bind method - to bind other pmic uclass devices as a parent pmic device.
This driver provides pmic_platdata for also for child regulator.
This driver will try to bind the regulator device with regulator driver.
This should succeed if regulator driver is compiled.
If no regulator driver found, then the pmic can still provide read/write
operations, and can be used with pmic framework function calls.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes V2:
- add implementation of pmic read/write
- max77686: add new operations
- max77686: header: change PMIC_NUM_OF_REGS to MAX77686_NUM_OF_REGS
Changes V3:
- pmic/max77686.c: call pmic_child_node_scan() to bind regulator device
- remove use of pmic platdata
- remove unused endian conversions
- Kconfig: add max77686 pmic entry
---
drivers/power/Kconfig | 7
drivers/power/pmic/Makefile| 1 +
drivers/power/pmic/max77686.c | 76 ++
drivers/power/pmic/pmic_max77686.c | 2 +-
include/power/max77686_pmic.h | 2 +-
5 files changed, 86 insertions(+), 2 deletions(-)
create mode 100644 drivers/power/pmic/max77686.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 1e73c7a..c4d4c72 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -66,6 +66,13 @@ config DM_PMIC
So the call will looks like below:
'pmic_write(regulator-parent, addr, value, len);'
+config DM_PMIC_MAX77686
+ bool Enable Driver Model for PMIC MAX77686
+ depends on DM_PMIC
+ ---help---
+ This config enables implementation of driver-model pmic uclass features
+ for PMIC MAX77686. The driver implements read/write operations/
+
config DM_REGULATOR
bool Enable Driver Model for REGULATOR drivers (UCLASS_REGULATOR)
depends on DM
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 985cfdb..242c767 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
+obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
obj-$(CONFIG_POWER_PFUZE100) += pmic_pfuze100.o
obj-$(CONFIG_POWER_TPS65090_I2C) += pmic_tps65090.o
obj-$(CONFIG_POWER_TPS65090_EC) += pmic_tps65090_ec.o
diff --git a/drivers/power/pmic/max77686.c b/drivers/power/pmic/max77686.c
new file mode 100644
index 000..3193c73
--- /dev/null
+++ b/drivers/power/pmic/max77686.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright (C) 2014-2015 Samsung Electronics
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include fdtdec.h
+#include i2c.h
+#include dm.h
+#include power/pmic.h
+#include dm/device-internal.h
+#include dm/uclass-internal.h
+#include dm/root.h
+#include dm/lists.h
+#include power/max77686_pmic.h
+#include errno.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int max77686_write(struct udevice *dev, uint reg, 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 max77686_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 max77686_bind(struct udevice *pmic)
+{
+ int ret;
+
+ ret = pmic_child_node_scan(pmic, voltage-regulators,
+regulator-compatible);
+ if (ret 0)
+ debug(%s: %s subnode scan error: %d.\n, __func__, pmic-name,
+ ret);
+ else
+ debug(%s: %s subnode found %d childs.\n, __func__, pmic-name,
+ ret);
+
+ /* Always return success for this device */
+ return 0;
+}
+
+static struct dm_pmic_ops max77686_ops = {
+ .reg_count = MAX77686_NUM_OF_REGS,
+ .read = max77686_read,
+ .write = max77686_write,
+};
+
+static const struct udevice_id max77686_ids[] = {
+ { .compatible = maxim,max77686},
+ { }
+};
+
+U_BOOT_DRIVER(pmic_max77686) = {
+ .name = max77686 pmic,
+ .id = UCLASS_PMIC,
+ .of_match = max77686_ids,
+ .bind = max77686_bind,
+ .ops = max77686_ops,
+};
diff --git a/drivers/power/pmic/pmic_max77686.c
b/drivers/power/pmic/pmic_max77686.c
index 95b1a57..1ad810a 100644
--- a/drivers/power/pmic/pmic_max77686.c
+++ b/drivers/power/pmic/pmic_max77686.c
@@ -295,7 +295,7 @@ int
[U-Boot] [PATCH v3 12/17] dm: regulator: add fixed voltage regulator driver
This driver implements regulator uclass features for fixed value regulators.
For getting the basic regulator device-tree node constraints, this driver calls
function 'regulator_ofdata_to_platdata()'. The typical fixed regulator node
provides few additional properties:
- gpio
- gpio-open-drain
- enable-active-high
- startup-delay-us
All above are checked and keept in structure of type 'fixed_regulator_priv',
which is private for each fixed-regulator device (dev-priv).
The driver implements only three of regulator uclass features:
- get_value
- get_enable
- set_enable
The regulator calls and command line features can be used for fixed-regulator,
and the proper error will be returned for prohibited.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Changes v3:
- new file
- Kconfig add fixed-regulator entry
---
drivers/power/Kconfig| 8 +++
drivers/power/regulator/Makefile | 1 +
drivers/power/regulator/fixed.c | 124 +++
3 files changed, 133 insertions(+)
create mode 100644 drivers/power/regulator/fixed.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 97abbf0..da1e866 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -120,6 +120,14 @@ config DM_REGULATOR_MAX77686
features for REGULATOR MAX77686. The driver implements get/set api for:
value, enable and mode.
+config DM_REGULATOR_FIXED
+ bool Enable Driver Model for REGULATOR Fixed value
+ depends on DM_REGULATOR
+ ---help---
+ This config enables implementation of driver-model regulator uclass
+ features for fixed value regulators. The driver implements get/set api
+ for enable and get only for voltage value.
+
config AXP221_DCDC1_VOLT
int axp221 dcdc1 voltage
depends on AXP221_POWER
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index 9d282e3..0a6a6d9 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -5,4 +5,5 @@
# SPDX-License-Identifier: GPL-2.0+
#
+obj-$(CONFIG_DM_REGULATOR_FIXED) += fixed.o
obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
diff --git a/drivers/power/regulator/fixed.c b/drivers/power/regulator/fixed.c
new file mode 100644
index 000..45e9f84
--- /dev/null
+++ b/drivers/power/regulator/fixed.c
@@ -0,0 +1,124 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics
+ *
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include fdtdec.h
+#include i2c.h
+#include dm.h
+#include asm/gpio.h
+#include power/pmic.h
+#include power/regulator.h
+#include errno.h
+#include dm.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct fixed_regulator_priv {
+ struct gpio_desc gpio;
+ bool gpio_open_drain;
+ bool enable_active_high;
+ unsigned startup_delay_us;
+};
+
+static int fixed_regulator_ofdata_to_platdata(struct udevice *dev)
+{
+ struct dm_regulator_info *info = dev-uclass_priv;
+ struct fixed_regulator_priv *priv = dev-priv;
+ int ret, offset = dev-of_offset;
+
+ /* Get the basic regulator constraints */
+ ret = regulator_ofdata_to_platdata(dev);
+ if (ret) {
+ error(Can't get regulator constraints for %s, dev-name);
+ return ret;
+ }
+
+ /* Get fixed regulator gpio desc */
+ ret = gpio_request_by_name_nodev(gd-fdt_blob, offset, gpio, 0,
+priv-gpio, GPIOD_IS_OUT);
+ if (ret) {
+ error(Fixed regulator gpio - not found! Error: %d, ret);
+ return ret;
+ }
+
+ /* Get fixed regulator addidional constraints */
+ priv-gpio_open_drain = fdtdec_get_bool(gd-fdt_blob, offset,
+ gpio-open-drain);
+ priv-enable_active_high = fdtdec_get_bool(gd-fdt_blob, offset,
+ enable-active-high);
+ priv-startup_delay_us = fdtdec_get_int(gd-fdt_blob, offset,
+ startup-delay-us, 0);
+
+ /* Set type to fixed - used by regulator command */
+ info-type = REGULATOR_TYPE_FIXED;
+
+ debug(%s:%d\n, __func__, __LINE__);
+ debug( name:%s, boot_on:%d, active_hi: %d start_delay:%u\n,
+ info-name, info-boot_on, priv-enable_active_high,
+ priv-startup_delay_us);
+
+ return 0;
+}
+
+static int fixed_regulator_get_value(struct udevice *dev)
+{
+ struct dm_regulator_info *info;
+ int ret;
+
+ ret = regulator_info(dev, info);
+ if (ret)
+ return ret;
+
+ if (info-min_uV == info-max_uV)
+ return info-min_uV;
+
+ error(Invalid constraints for: %s\n, info-name);
+
+ return -EINVAL;
+}
+
+static bool fixed_regulator_get_enable(struct udevice *dev)
+{
+ struct fixed_regulator_priv *priv = dev-priv;
+
+ return
[U-Boot] [PATCH v3 05/17] dm: pmic: add implementation of driver model pmic uclass
This is an introduction to driver-model multi uclass PMIC support. It starts with UCLASS_PMIC - a common PMIC devices uclass type to provide device read/write operations only. Beside two basic operations the pmic platform data is introduced, which provides basic informations about the pmic device I/O interface and is shared with all childs (and should also for childs new uclass types in the future). Usually PMIC devices provides various functionalities with single or multiple I/O interfaces. Using this new framework and new uclass types introduced in the future, it can be handle like this: _ root device | |_ BUS 0 device (e.g. I2C0)- UCLASS_I2C/SPI/... | |_ PMIC device 1 (read/write ops)- UCLASS_PMIC | |_ REGULATOR device (ldo/buck/... ops) - UCLASS_REGULATOR | |_ CHARGER device (charger ops)- UCLASS_CHARGER (in the future) | |_ MUIC device (microUSB con ops) - UCLASS_MUIC(in the future) | |_ ... | |_ BUS 1 device (e.g. I2C1)- UCLASS_I2C/SPI/... |_ PMIC device 2 (read/write ops)- UCLASS_PMIC |_ RTC device (rtc ops)- UCLASS_MUIC (in the future) For each PMIC device interface, new UCLASS_PMIC device is bind with proper pmic driver, and it's child devices provides some specified operations. All new definitions can be found in file: - 'include/power/pmic.h' Uclass file: - pmic-uclass.c - provides a common code for UCLASS_PMIC device drivers The old pmic framework is still kept and is independent. Changes: - new uclass-id: UCLASS_PMIC - new config: CONFIG_DM_PMIC New pmic api is documented in: doc/driver-model/pmic-framework.txt Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com --- Changes V2: - pmic uclass: adjust uclass code to the mainline changes - pmic uclass: remove pmic_i2c and pmic_spi - pmic uclass: modify pmic_platdata - pmic uclass: add pmic_if_* functions - pmic uclass: remove pmic_init_dm() - pmic uclass: cleanup - pmic.h: define pmic ops structure (read/write operations) - pmic.h: add comments to functions Changes V3: - pmic-uclass.c and pmic.h: -- remove pmic_if_* functions -- add new function pmic_child_node_scan() - add Kconfig entry --- drivers/power/Kconfig | 68 ++ drivers/power/Makefile | 1 + drivers/power/pmic-uclass.c | 130 +++ include/dm/uclass-id.h | 3 + include/power/pmic.h| 210 5 files changed, 412 insertions(+) create mode 100644 drivers/power/pmic-uclass.c diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index f8f0239..3513b46 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -1,3 +1,71 @@ +config DM_PMIC + bool Enable Driver Model for PMIC drivers (UCLASS_PMIC) + depends on DM + ---help--- + This config enables the driver-model multi uclass PMIC support. + Its basic uclass type is: UCLASS_PMIC, which is designed to provide + a common I/O interface for pmic child devices of various uclass types. + + Usually PMIC IC's provides more than one functionality, which means + that we should implement new uclass operations for each one. Usually + PMIC's provide those various functionalities by one or more interfaces. + And this could looks like this: + + root device + |_ BUS 0 device (e.g. I2C0) - UCLASS_I2C/SPI/... + | |_ PMIC device (READ/WRITE ops) - UCLASS_PMIC + | | (pmic sub-devices) + | |_ REGULATOR device (ldo/buck/... ops) - UCLASS_REGULATOR + | |_ CHARGER device (charger ops) - UCLASS_CHARGER (future) + | |_ MUIC device (microUSB connector ops) - UCLASS_MUIC(future) + | |_ ... + | + |_ BUS 1 device (e.g. I2C1) - UCLASS_I2C/SPI/... + |_ PMIC device (READ/WRITE ops) - UCLASS_PMIC +| (pmic sub-devices) +|_ RTC device (rtc ops)- UCLASS_MUIC (future) + + From the I/O interface point of view, there can be found two PMIC types: + - single I/O interface - then UCLASS_PMIC device should be a parent of + all pmic sub-devices, where each is usually different uclass type, but + need to access the same interface + + - multiple I/O interfaces - for each interface the UCLASS_PMIC device + should be a parent of only those devices (different uclass types), + which needs to access the specified interface. + + For each case, binding should be done automatically. If only device tree + nodes/subnodes are proper defined, then: + |_ the ROOT driver will bind the device for I2C/SPI node: + |_ the I2C/SPI driver should bind a device for pmic node: + |_ the PMIC driver should bind devices for its childs: + | (pmic sub-devices) + |_ regulator (child) + |_ charger (child) + |_
[U-Boot] [PATCH v3 09/17] pmic: max77686 set the same compatible as in the kernel
This commit also updates the proper dts files.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
arch/arm/dts/exynos4412-odroid.dts | 2 +-
arch/arm/dts/exynos4412-trats2.dts | 2 +-
arch/arm/dts/exynos5250-smdk5250.dts | 2 +-
arch/arm/dts/exynos5250-snow.dts | 2 +-
lib/fdtdec.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/dts/exynos4412-odroid.dts
b/arch/arm/dts/exynos4412-odroid.dts
index 582f6e5..5507d9a 100644
--- a/arch/arm/dts/exynos4412-odroid.dts
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -36,7 +36,7 @@
status = okay;
max77686_pmic@09 {
- compatible = maxim,max77686_pmic;
+ compatible = maxim,max77686;
interrupts = 7 0;
reg = 0x09 0 0;
#clock-cells = 1;
diff --git a/arch/arm/dts/exynos4412-trats2.dts
b/arch/arm/dts/exynos4412-trats2.dts
index dd238df..5c0bb91 100644
--- a/arch/arm/dts/exynos4412-trats2.dts
+++ b/arch/arm/dts/exynos4412-trats2.dts
@@ -41,7 +41,7 @@
status = okay;
max77686_pmic@09 {
- compatible = maxim,max77686_pmic;
+ compatible = maxim,max77686;
interrupts = 7 0;
reg = 0x09 0 0;
#clock-cells = 1;
diff --git a/arch/arm/dts/exynos5250-smdk5250.dts
b/arch/arm/dts/exynos5250-smdk5250.dts
index 9273562..3cebfc2 100644
--- a/arch/arm/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/dts/exynos5250-smdk5250.dts
@@ -68,7 +68,7 @@
i2c@12c6 {
pmic@9 {
reg = 0x9;
- compatible = maxim,max77686_pmic;
+ compatible = maxim,max77686;
};
};
diff --git a/arch/arm/dts/exynos5250-snow.dts b/arch/arm/dts/exynos5250-snow.dts
index 7d8be69..dda6b34 100644
--- a/arch/arm/dts/exynos5250-snow.dts
+++ b/arch/arm/dts/exynos5250-snow.dts
@@ -107,7 +107,7 @@
i2c@12c6 {
pmic@9 {
reg = 0x9;
- compatible = maxim,max77686_pmic;
+ compatible = maxim,max77686;
};
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 1a0268a..261ec90 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -55,7 +55,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS_DWMMC, samsung,exynos-dwmmc),
COMPAT(SAMSUNG_EXYNOS_MMC, samsung,exynos-mmc),
COMPAT(SAMSUNG_EXYNOS_SERIAL, samsung,exynos4210-uart),
- COMPAT(MAXIM_MAX77686_PMIC, maxim,max77686_pmic),
+ COMPAT(MAXIM_MAX77686_PMIC, maxim,max77686),
COMPAT(GENERIC_SPI_FLASH, spi-flash),
COMPAT(MAXIM_98095_CODEC, maxim,max98095-codec),
COMPAT(INFINEON_SLB9635_TPM, infineon,slb9635-tpm),
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 02/17] fdt_ro.c: add new function: fdt_node_check_prop_compatible()
This commit:
- moves fdt_node_check_compatible() code to fdt_node_check_prop_compatible()
- adds call to fdt_node_check_prop_compatible() in fdt_node_check_compatible()
with 'compatible' as the name of compatible property.
The function: fdt_node_check_compatible() - works the same as previous.
The function fdt_node_check_prop_compatible() - allows for checking compatible
string in given property name.
If some fdt node uses different name for compatible property, than 'compatible',
then the function fdt_node_check_prop_compatible() can be used with the custom
compatible property name as an argument.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
include/libfdt.h| 27 +++
lib/libfdt/fdt_ro.c | 14 +++---
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/include/libfdt.h b/include/libfdt.h
index f3cbb63..0ff91b6 100644
--- a/include/libfdt.h
+++ b/include/libfdt.h
@@ -807,6 +807,33 @@ int fdt_node_offset_by_prop_value(const void *fdt, int
startoffset,
int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle);
/**
+ * fdt_node_check_prop_compatible: check a node's 'property_name' for
compatible
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of a tree node
+ * @property_name: name of property within looking for the 'compatible' string
+ * @compatible: string to match against
+ *
+ *
+ * fdt_node_check_prop_compatible() returns 0 if the given node contains a
+ * 'compatible' property with the given string as one of its elements,
+ * it returns non-zero otherwise, or on error.
+ *
+ * returns:
+ * 0, if the node has a 'compatible' property listing the given string
+ * 1, if the node has a 'compatible' property, but it does not list
+ * the given string
+ * -FDT_ERR_NOTFOUND, if the given node has no 'compatible' property
+ * -FDT_ERR_BADOFFSET, if nodeoffset does not refer to a BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_check_prop_compatible(const void *fdt, int nodeoffset,
+ const char *property_name,
+ const char *compatible);
+
+/**
* fdt_node_check_compatible: check a node's compatible property
* @fdt: pointer to the device tree blob
* @nodeoffset: offset of a tree node
diff --git a/lib/libfdt/fdt_ro.c b/lib/libfdt/fdt_ro.c
index 03733e5..a3f4f8a 100644
--- a/lib/libfdt/fdt_ro.c
+++ b/lib/libfdt/fdt_ro.c
@@ -567,13 +567,14 @@ int fdt_get_string(const void *fdt, int node, const char
*property,
return fdt_get_string_index(fdt, node, property, 0, output);
}
-int fdt_node_check_compatible(const void *fdt, int nodeoffset,
- const char *compatible)
+int fdt_node_check_prop_compatible(const void *fdt, int nodeoffset,
+ const char *prop_name,
+ const char *compatible)
{
const void *prop;
int len;
- prop = fdt_getprop(fdt, nodeoffset, compatible, len);
+ prop = fdt_getprop(fdt, nodeoffset, prop_name, len);
if (!prop)
return len;
if (fdt_stringlist_contains(prop, len, compatible))
@@ -582,6 +583,13 @@ int fdt_node_check_compatible(const void *fdt, int
nodeoffset,
return 1;
}
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+ const char *compatible)
+{
+ return fdt_node_check_prop_compatible(fdt, nodeoffset, compatible,
+ compatible);
+}
+
int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
const char *compatible)
{
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 03/17] dm: core: lists.c: add new function lists_bind_fdt_by_prop()
This change adds new function: lists_bind_fdt_by_prop(), which can be used
for bind the devices by custom property name for the compatible string.
The function lists_bind_fdt() works the same as previous.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
drivers/core/lists.c | 28 +++-
include/dm/lists.h | 18 ++
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index ff115c4..d96040a 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -99,14 +99,17 @@ int device_bind_driver(struct udevice *parent, const char
*drv_name,
* @param blob:Device tree pointer
* @param offset: Offset of node in device tree
* @param of_match:List of compatible strings to match
+ * @param prop:Name of compatible string property
* @param of_idp: Returns the match that was found
* @return 0 if there is a match, -ENOENT if no match, -ENODEV if the node
* does not have a compatible string, other error 0 if there is a device
* tree error
*/
-static int driver_check_compatible(const void *blob, int offset,
- const struct udevice_id *of_match,
- const struct udevice_id **of_idp)
+static int driver_check_prop_compatible(const void *blob,
+ int offset,
+ const char *prop,
+ const struct udevice_id *of_match,
+ const struct udevice_id **of_idp)
{
int ret;
@@ -115,8 +118,8 @@ static int driver_check_compatible(const void *blob, int
offset,
return -ENOENT;
while (of_match-compatible) {
- ret = fdt_node_check_compatible(blob, offset,
- of_match-compatible);
+ ret = fdt_node_check_prop_compatible(blob, offset, prop,
+of_match-compatible);
if (!ret) {
*of_idp = of_match;
return 0;
@@ -131,8 +134,8 @@ static int driver_check_compatible(const void *blob, int
offset,
return -ENOENT;
}
-int lists_bind_fdt(struct udevice *parent, const void *blob, int offset,
- struct udevice **devp)
+int lists_bind_fdt_by_prop(struct udevice *parent, const void *blob, int
offset,
+ const char *prop, struct udevice **devp)
{
struct driver *driver = ll_entry_start(struct driver, driver);
const int n_ents = ll_entry_count(struct driver, driver);
@@ -148,8 +151,8 @@ int lists_bind_fdt(struct udevice *parent, const void
*blob, int offset,
if (devp)
*devp = NULL;
for (entry = driver; entry != driver + n_ents; entry++) {
- ret = driver_check_compatible(blob, offset, entry-of_match,
- id);
+ ret = driver_check_prop_compatible(blob, offset, prop,
+ entry-of_match, id);
name = fdt_get_name(blob, offset, NULL);
if (ret == -ENOENT) {
continue;
@@ -183,4 +186,11 @@ int lists_bind_fdt(struct udevice *parent, const void
*blob, int offset,
return result;
}
+
+int lists_bind_fdt(struct udevice *parent, const void *blob, int offset,
+ struct udevice **devp)
+{
+ return lists_bind_fdt_by_prop(parent, blob, offset, compatible, devp);
+
+}
#endif
diff --git a/include/dm/lists.h b/include/dm/lists.h
index 1b50af9..c63757b 100644
--- a/include/dm/lists.h
+++ b/include/dm/lists.h
@@ -45,6 +45,24 @@ struct uclass_driver *lists_uclass_lookup(enum uclass_id id);
int lists_bind_drivers(struct udevice *parent, bool pre_reloc_only);
/**
+ * lists_bind_fdt_by_prop() - bind a device tree node by the given compatible
+ * property name.
+ *
+ * This creates a new device bound to the given device tree node, with
+ * @parent as its parent.
+ *
+ * @parent: parent device (root)
+ * @blob: device tree blob
+ * @offset: offset of this device tree node
+ * @prop: fdt property name within looking for the driver compatible string
+ * @devp: if non-NULL, returns a pointer to the bound device
+ * @return 0 if device was bound, -EINVAL if the device tree is invalid,
+ * other -ve value on error
+ */
+int lists_bind_fdt_by_prop(struct udevice *parent, const void *blob, int
offset,
+ const char *prop, struct udevice **devp);
+
+/**
* lists_bind_fdt() - bind a device tree node
*
* This creates a new device bound to the given device tree node, with
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 14/17] dm: board:samsung: power_init_board: add requirement of CONFIG_DM_PMIC
In the power_init_board function call, regulator driver init is called,
so before compile, make sure that any power framework is defined.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
board/samsung/common/board.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 2e17da8..c4cbb63 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -21,9 +21,9 @@
#include asm/arch/pinmux.h
#include asm/arch/power.h
#include asm/arch/system.h
-#include power/pmic.h
#include asm/arch/sromc.h
#include lcd.h
+#include i2c.h
#include samsung/misc.h
DECLARE_GLOBAL_DATA_PTR;
@@ -168,7 +168,7 @@ int board_early_init_f(void)
}
#endif
-#if defined(CONFIG_POWER)
+#if defined(CONFIG_POWER) || defined(CONFIG_DM_PMIC)
int power_init_board(void)
{
set_ps_hold_ctrl();
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 15/17] odroid: board: add support to dm pmic api
This commit change the old pmic framework calls with the new ones.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes v2:
- remove board_init_i2c() call
- update regulator calls
- update headers
- samsung/misc.c: include required header
Changes v3:
- adjust regulator calls to new api
---
board/samsung/common/misc.c | 1 +
board/samsung/odroid/odroid.c | 113 +-
2 files changed, 91 insertions(+), 23 deletions(-)
diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index 1a77c82..f0d69d4 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -16,6 +16,7 @@
#include asm/arch/cpu.h
#include asm/gpio.h
#include linux/input.h
+#include dm.h
#include power/pmic.h
#include mmc.h
diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
index ae41c29..aa3b0ff 100644
--- a/board/samsung/odroid/odroid.c
+++ b/board/samsung/odroid/odroid.c
@@ -12,7 +12,9 @@
#include asm/arch/gpio.h
#include asm/gpio.h
#include asm/arch/cpu.h
+#include dm.h
#include power/pmic.h
+#include power/regulator.h
#include power/max77686_pmic.h
#include errno.h
#include mmc.h
@@ -405,15 +407,62 @@ static void board_gpio_init(void)
static int pmic_init_max77686(void)
{
- struct pmic *p = pmic_get(MAX77686_PMIC);
+ struct udevice *dev;
+ int ret;
- if (pmic_probe(p))
- return -ENODEV;
+ ret = regulator_get(VDDQ_EMMC_1.8V, dev);
+ if (ret) {
+ error(Regulator get error: %d, ret);
+ return ret;
+ }
+
+ ret = regulator_set_value(dev, 180);
+ if (ret) {
+ error(Regulator %s value setting error: %d, dev-name, ret);
+ return ret;
+ }
+
+ ret = regulator_set_enable(dev, true);
+ if (ret) {
+ error(Regulator %s enable error: %d, dev-name, ret);
+ return ret;
+ }
+
+ ret = regulator_get(TFLASH_2.8V, dev);
+ if (ret) {
+ error(Regulator get error: %d, ret);
+ return ret;
+ }
+
+ ret = regulator_set_value(dev, 280);
+ if (ret) {
+ error(Regulator %s value setting error: %d, dev-name, ret);
+ return ret;
+ }
+
+ ret = regulator_set_enable(dev, true);
+ if (ret) {
+ error(Regulator %s enable error: %d, dev-name, ret);
+ return ret;
+ }
+
+ ret = regulator_get(VDDQ_EMMC_2.8V, dev);
+ if (ret) {
+ error(Regulator get error: %d, ret);
+ return ret;
+ }
- /* Set LDO Voltage */
- max77686_set_ldo_voltage(p, 20, 180); /* LDO20 eMMC */
- max77686_set_ldo_voltage(p, 21, 280); /* LDO21 SD */
- max77686_set_ldo_voltage(p, 22, 280); /* LDO22 eMMC */
+ ret = regulator_set_value(dev, 280);
+ if (ret) {
+ error(Regulator %s value setting error: %d, dev-name, ret);
+ return ret;
+ }
+
+ ret = regulator_set_enable(dev, true);
+ if (ret) {
+ error(Regulator %s enable error: %d, dev-name, ret);
+ return ret;
+ }
return 0;
}
@@ -434,7 +483,6 @@ int exynos_init(void)
int exynos_power_init(void)
{
- pmic_init(0);
pmic_init_max77686();
return 0;
@@ -443,19 +491,20 @@ int exynos_power_init(void)
#ifdef CONFIG_USB_GADGET
static int s5pc210_phy_control(int on)
{
- struct pmic *p_pmic;
-
- p_pmic = pmic_get(MAX77686_PMIC);
- if (!p_pmic)
- return -ENODEV;
+ struct udevice *dev;
+ int ret;
- if (pmic_probe(p_pmic))
- return -1;
+ ret = regulator_get(VDD_UOTG_3.0V, dev);
+ if (ret) {
+ error(Regulator get error: %d, ret);
+ return ret;
+ }
if (on)
- return max77686_set_ldo_mode(p_pmic, 12, OPMODE_ON);
+ return regulator_set_mode(dev, OPMODE_ON);
else
- return max77686_set_ldo_mode(p_pmic, 12, OPMODE_LPM);
+ return regulator_set_mode(dev, OPMODE_LPM);
+
}
struct s3c_plat_otg_data s5pc210_otg_data = {
@@ -472,7 +521,8 @@ struct s3c_plat_otg_data s5pc210_otg_data = {
int board_usb_init(int index, enum usb_init_type init)
{
#ifdef CONFIG_CMD_USB
- struct pmic *p_pmic;
+ struct udevice *dev;
+ int ret;
/* Set Ref freq 0 = 24MHz, 1 = 26MHz*/
/* Odroid Us have it at 24MHz, Odroid Xs at 26MHz */
@@ -490,14 +540,31 @@ int board_usb_init(int index, enum usb_init_type init)
/* Power off and on BUCK8 for LAN9730 */
debug(LAN9730 - Turning power buck 8 OFF and ON.\n);
- p_pmic = pmic_get(MAX77686_PMIC);
- if (p_pmic !pmic_probe(p_pmic)) {
- max77686_set_buck_voltage(p_pmic, 8, 75);
- max77686_set_buck_voltage(p_pmic, 8,
[U-Boot] [PATCH v3 07/17] dm: pmic: add pmic command
This is new command for the pmic devices based on driver model pmic api.
Command features are unchanged:
- list - list UCLASS pmic devices
- pmic dev [id] - show or [set] operating pmic device (NEW)
- pmic dump - dump registers
- pmic read address - read byte of register at address
- pmic write address - write byte to register at address
The only one change for this command is 'dev' subcommand.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Changes v3:
- new file
- add Kconfig
---
common/Kconfig| 14
common/Makefile | 3 +
common/cmd_pmic.c | 210 ++
3 files changed, 227 insertions(+)
create mode 100644 common/cmd_pmic.c
diff --git a/common/Kconfig b/common/Kconfig
index e662774..1125e6d 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -335,4 +335,18 @@ config CMD_SETGETDCR
endmenu
+menu Power commands
+config DM_PMIC_CMD
+ bool Enable Driver Model PMIC command
+ depends on DM_PMIC
+ help
+ This is new command for the pmic devices based on driver model pmic
api.
+ Command features are unchanged:
+ - list - list UCLASS pmic devices
+ - pmic dev [id] - show or [set] operating pmic device (NEW)
+ - pmic dump - dump registers
+ - pmic read address - read byte of register at address
+ - pmic write address - write byte to register at address
+ The only one change for this command is 'dev' subcommand.
+endmenu
endmenu
diff --git a/common/Makefile b/common/Makefile
index 7216a13..d908851 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -208,6 +208,9 @@ 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
+
+# Power
+obj-$(CONFIG_DM_PMIC_CMD) += cmd_pmic.o
endif
ifdef CONFIG_SPL_BUILD
diff --git a/common/cmd_pmic.c b/common/cmd_pmic.c
new file mode 100644
index 000..978a94a
--- /dev/null
+++ b/common/cmd_pmic.c
@@ -0,0 +1,210 @@
+/*
+ * Copyright (C) 2014-2015 Samsung Electronics
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include common.h
+#include linux/types.h
+#include linux/ctype.h
+#include fdtdec.h
+#include dm.h
+#include power/pmic.h
+#include power/regulator.h
+#include dm/device-internal.h
+#include dm/uclass-internal.h
+#include dm/root.h
+#include dm/lists.h
+#include i2c.h
+#include compiler.h
+#include errno.h
+
+#define LIMIT_SEQ 3
+#define LIMIT_DEVNAME 20
+
+static struct udevice *pmic_curr;
+
+static int failed(const char *getset, const char *thing,
+ const char *for_dev, int ret)
+{
+ printf(Can't %s %s %s.\nError: %d (%s)\n, getset, thing, for_dev,
+ ret, errno_str(ret));
+ return CMD_RET_FAILURE;
+}
+
+static int do_dev(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ int seq, ret = -ENODEV;
+
+ switch (argc) {
+ case 2:
+ seq = simple_strtoul(argv[1], NULL, 0);
+ ret = uclass_get_device_by_seq(UCLASS_PMIC, seq, pmic_curr);
+ case 1:
+ if (!pmic_curr)
+ return failed(get, the, device, ret);
+
+ printf(dev: %d @ %s\n, pmic_curr-seq, pmic_curr-name);
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_list(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ struct udevice *dev;
+ const char *parent_uc;
+ int ret;
+
+ printf(|%*s | %-*.*s| %-*.*s| %s @ %s\n,
+ LIMIT_SEQ, Seq,
+ LIMIT_DEVNAME, LIMIT_DEVNAME, Name,
+ LIMIT_DEVNAME, LIMIT_DEVNAME, Parent name,
+ Parent uclass, seq);
+
+ for (ret = uclass_first_device(UCLASS_PMIC, dev); dev;
+ret = uclass_next_device(dev)) {
+ if (!dev)
+ continue;
+
+ /* Parent uclass name*/
+ parent_uc = dev-parent-uclass-uc_drv-name;
+
+ printf(|%*d | %-*.*s| %-*.*s| %s @ %d\n,
+ LIMIT_SEQ, dev-seq,
+ LIMIT_DEVNAME, LIMIT_DEVNAME, dev-name,
+ LIMIT_DEVNAME, LIMIT_DEVNAME, dev-parent-name,
+ parent_uc, dev-parent-seq);
+ }
+
+ if (ret)
+ return CMD_RET_FAILURE;
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_dump(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ struct udevice *dev;
+ int regs, ret;
+ uint8_t value;
+ uint reg;
+
+ if (!pmic_curr)
+ return failed(get, current, device, -ENODEV);
+
+ dev = pmic_curr;
+
+ printf(Dump pmic: %s registers\n, dev-name);
+
+ regs = pmic_reg_count(dev);
+ reg = 0;
+ while (reg regs) {
+ ret = pmic_read(dev, reg, value, 1);
+
[U-Boot] [PATCH v3 11/17] dm: regulator: add max77686 regulator driver
This commit adds support to max77686 regulator driver
based on a uclass regulator driver-model api, which
provides implementation of all uclass regulator api
function calls.
New file: drivers/power/regulator/max77686.c
New config: CONFIG_DM_REGULATOR_MAX77686
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes V2:
- change debug() to error()
- code cleanup
- fix data types
- ldo/buck state implementation
- adjust to new uclass api
Changes V3:
- regulator/max77686.c:
-- adjust to api changes
-- add separeted drivers for buck and ldo
-- bind regulators by its compatibles
- Kconfig: add regulator max77686 entry
---
Makefile | 1 +
drivers/power/Kconfig | 8 +
drivers/power/Makefile | 1 -
drivers/power/regulator/Makefile | 8 +
drivers/power/regulator/max77686.c | 876 +
include/power/max77686_pmic.h | 24 +-
6 files changed, 914 insertions(+), 4 deletions(-)
create mode 100644 drivers/power/regulator/Makefile
create mode 100644 drivers/power/regulator/max77686.c
diff --git a/Makefile b/Makefile
index 1b3ebe7..9ecf3bb 100644
--- a/Makefile
+++ b/Makefile
@@ -632,6 +632,7 @@ libs-y += drivers/power/ \
drivers/power/fuel_gauge/ \
drivers/power/mfd/ \
drivers/power/pmic/ \
+ drivers/power/regulator/ \
drivers/power/battery/
libs-y += drivers/spi/
libs-$(CONFIG_FMAN_ENET) += drivers/net/fm/
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index c4d4c72..97abbf0 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -112,6 +112,14 @@ config DM_REGULATOR
Say y here to enable support for the axp221 / axp223 pmic found on most
sun6i (A31) / sun8i (A23) boards.
+config DM_REGULATOR_MAX77686
+ bool Enable Driver Model for REGULATOR MAX77686
+ depends on DM_REGULATOR DM_PMIC_MAX77686
+ ---help---
+ This config enables implementation of driver-model regulator uclass
+ features for REGULATOR MAX77686. The driver implements get/set api for:
+ value, enable and mode.
+
config AXP221_DCDC1_VOLT
int axp221 dcdc1 voltage
depends on AXP221_POWER
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index a6b7012..f206bdd 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -15,7 +15,6 @@ obj-$(CONFIG_TPS6586X_POWER) += tps6586x.o
obj-$(CONFIG_TWL4030_POWER)+= twl4030.o
obj-$(CONFIG_TWL6030_POWER)+= twl6030.o
obj-$(CONFIG_PALMAS_POWER) += palmas.o
-
obj-$(CONFIG_POWER) += power_core.o
obj-$(CONFIG_DIALOG_POWER) += power_dialog.o
obj-$(CONFIG_POWER_FSL) += power_fsl.o
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
new file mode 100644
index 000..9d282e3
--- /dev/null
+++ b/drivers/power/regulator/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright (C) 2014 Samsung Electronics
+# Przemyslaw Marczak p.marc...@samsung.com
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
diff --git a/drivers/power/regulator/max77686.c
b/drivers/power/regulator/max77686.c
new file mode 100644
index 000..496c70a
--- /dev/null
+++ b/drivers/power/regulator/max77686.c
@@ -0,0 +1,876 @@
+/*
+ * Copyright (C) 2012-2015 Samsung Electronics
+ *
+ * Rajeshwari Shinde rajeshwar...@samsung.com
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include fdtdec.h
+#include i2c.h
+#include dm.h
+#include power/pmic.h
+#include power/regulator.h
+#include power/max77686_pmic.h
+#include errno.h
+#include dm.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define MODE(_id, _val, _name) { \
+ .id = _id, \
+ .register_value = _val, \
+ .name = _name, \
+}
+
+/* LDO: 1,3,4,5,9,17,18,19,20,21,22,23,24,26,26,27 */
+static struct dm_regulator_mode max77686_ldo_mode_standby1[] = {
+ MODE(OPMODE_OFF, MAX77686_LDO_MODE_OFF, OFF),
+ MODE(OPMODE_LPM, MAX77686_LDO_MODE_LPM, LPM),
+ MODE(OPMODE_STANDBY_LPM, MAX77686_LDO_MODE_STANDBY_LPM, ON/LPM),
+ MODE(OPMODE_ON, MAX77686_LDO_MODE_ON, ON),
+};
+
+/* LDO: 2,6,7,8,10,11,12,14,15,16 */
+static struct dm_regulator_mode max77686_ldo_mode_standby2[] = {
+ MODE(OPMODE_OFF, MAX77686_LDO_MODE_OFF, OFF),
+ MODE(OPMODE_STANDBY, MAX77686_LDO_MODE_STANDBY, ON/OFF),
+ MODE(OPMODE_STANDBY_LPM, MAX77686_LDO_MODE_STANDBY_LPM, ON/LPM),
+ MODE(OPMODE_ON, MAX77686_LDO_MODE_ON, ON),
+};
+
+/* Buck: 1 */
+static struct dm_regulator_mode max77686_buck_mode_standby[] = {
+ MODE(OPMODE_OFF, MAX77686_BUCK_MODE_OFF, OFF),
+ MODE(OPMODE_STANDBY, MAX77686_BUCK_MODE_STANDBY, ON/OFF),
+ MODE(OPMODE_ON, MAX77686_BUCK_MODE_ON, ON),
+};
+
+/* Buck: 2,3,4 */
+static struct dm_regulator_mode max77686_buck_mode_lpm[] = {
+ MODE(OPMODE_OFF, MAX77686_BUCK_MODE_OFF, OFF),
+ MODE(OPMODE_STANDBY, MAX77686_BUCK_MODE_STANDBY, ON/OFF),
+
[U-Boot] [PATCH v3 13/17] doc: driver-model: pmic and regulator uclass documentation
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com --- Changes v2, V3: - update documentation with the framework api changes - remove doc file name 'dm' prefix --- doc/driver-model/pmic-framework.txt | 350 1 file changed, 350 insertions(+) create mode 100644 doc/driver-model/pmic-framework.txt diff --git a/doc/driver-model/pmic-framework.txt b/doc/driver-model/pmic-framework.txt new file mode 100644 index 000..72651dc --- /dev/null +++ b/doc/driver-model/pmic-framework.txt @@ -0,0 +1,350 @@ +# +# (C) Copyright 2014-2015 Samsung Electronics +# Przemyslaw Marczak p.marc...@samsung.com +# +# SPDX-License-Identifier: GPL-2.0+ +# + +PMIC framework based on Driver Model + +TOC: +1. Introduction +2. How does it work +3. Pmic driver api +4. Pmic driver +5. Pmic command +6. Regulator driver api +7. Regulator driver +8. Regulator command + +1. Introduction +=== +This is an introduction to driver-model multi uclass PMIC devices support. +At present it is based on two uclass types: + +- UCLASS_PMIC - basic uclass type for PMIC I/O, which provides common + read/write interface. +- UCLASS_REGULATOR - additional uclass type for specific PMIC features, which + are various voltage regulators. + +New files: +UCLASS_PMIC: +- drivers/power/pmic-uclass.c +- include/power/pmic.h +UCLASS_REGULATOR: +- drivers/power/regulator-uclass.c +- include/power/regulator.h + +Commands: +- lib/cmd_pmic.c +- lib/cmd_regulator.c + +2. How doees it work + +The Power Management Integrated Circuits (PMIC) are used in embedded systems +to provide stable, precise and specific voltage power source with over-voltage +and thermal protection circuits. + +The single PMIC can provide various functionalities with single or multiple +interfaces, like in the example below. + +-- SoC + | + |__ + | BUS 0 | Multi interface PMIC IC|-- LDO out 1 + | e.g.I2C0 | |-- LDO out N + |---| PMIC device 0 (READ/WRITE ops) | + | or SPI0 ||_ REGULATOR device (ldo/... ops) |-- BUCK out 1 + | ||_ CHARGER device (charger ops) |-- BUCK out M + | ||_ MUIC device (microUSB con ops) | + | BUS 1 ||_ ...|--- BATTERY + | e.g.I2C1 | | + |---| PMIC device 1 (READ/WRITE ops) |--- USB in 1 + . or SPI1 ||_ RTC device (rtc ops) |--- USB in 2 + . |__|--- USB out + . + +Since U-Boot provides driver model features for I2C and SPI bus drivers, +the PMIC devices should also support this. With the new basic uclass types +for PMIC I/O and regulator features, PMIC drivers can simply provide common +features, with multiple interface and instance support. + +Basic design assumptions: + +- Common I/O api - UCLASS_PMIC +The main assumption is to use UCLASS_PMIC device to provide I/O interface, +for devices other uclass types. It is no matter what is the type of device +physical I/O interface. Usually PMIC devices are using SPI or I2C interface, +but use of any other interface (e.g. when PMIC is not directly connected +to the SoC) - is now possible. Drivers can use the same read/write api. + +- Common regulator api - UCLASS_REGULATOR +For setting the attributes of verious types of regulators with common api, +this uclass can be implemented. This allows to drive the each regulator output +value, on/off state and custom defined operation modes. It also provides the +user interface for all operations. +For the very simple implementation, the regulator drivers are not required, +so the code could base on pmic read/write only. + +When board device-tree file includes pmic subnode and the U_Boot compatible +driver exists, then the pmic device bind should looks like this: + +|_ root - will bind the device for I2C/SPI bus node + |_ i2c/spi - should bind a device for pmic node +|_ pmic (parent) - should bind child devices for its features + |_ regulator (child) + |_ charger (child) + |_ other (child) + +Usually PMIC design provides: + - single I/O interface (single UCLASS_PMIC driver) + Then UCLASS_PMIC device should be a parent of all pmic devices, where each + is usually different uclass type, but need to access the same interface + + - multiple I/O interfaces (UCLASS_PMIC driver for each) + For each interface the UCLASS_PMIC device should be a parent of only those + devices (different uclass types), which needs to access the specified + interface. + +3. Pmic driver api +=== +To use the pmic API, config: CONFIG_DM_PMIC is required. +The new driver API is very simple and is based on 'struct dm_pmic_ops', +which define two basic operations: device read and write. + +The platform data is
[U-Boot] [PATCH v3 17/17] odroid: config: enable dm pmic, dm regulator and max77686 driver
This change enables the configs required to init and setup max77686 regulator driver, using the new driver model pmic and regulator API. This commits enables: - CONFIG_ERRNO_STR - CONFIG_DM_PMIC - CONFIG_DM_PMIC_CMD - CONFIG_DM_PMIC_MAX77686 - CONFIG_DM_REGULATOR - CONFIG_DM_REGULATOR_CMD - CONFIG_DM_REGULATOR_MAX77686 And removes the unused: - CONFIG_DM_I2C_COMPAT - CONFIG_POWER - CONFIG_POWER_I2C - CONFIG_POWER_MAX77686 Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com --- Changes V2: - config: enable dm i2c; cleanup - remove CONFIG_DM_I2C_COMPAT - enable regulator command Changes V3: - move options to defconfig --- configs/odroid_defconfig | 8 +++- include/configs/odroid.h | 5 - 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/configs/odroid_defconfig b/configs/odroid_defconfig index d32b5b5..1e29abe 100644 --- a/configs/odroid_defconfig +++ b/configs/odroid_defconfig @@ -4,5 +4,11 @@ CONFIG_TARGET_ODROID=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE=exynos4412-odroid CONFIG_DM_I2C=y -CONFIG_DM_I2C_COMPAT=y # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set +CONFIG_ERRNO_STR=y +CONFIG_DM_PMIC=y +CONFIG_DM_PMIC_CMD=y +CONFIG_DM_PMIC_MAX77686=y +CONFIG_DM_REGULATOR=y +CONFIG_DM_REGULATOR_CMD=y +CONFIG_DM_REGULATOR_MAX77686=y diff --git a/include/configs/odroid.h b/include/configs/odroid.h index 5ee0abe..3874baa 100644 --- a/include/configs/odroid.h +++ b/include/configs/odroid.h @@ -182,11 +182,6 @@ #define CONFIG_SYS_I2C_S3C24X0_SPEED 10 #define CONFIG_SYS_I2C_S3C24X0_SLAVE 0 -/* POWER */ -#define CONFIG_POWER -#define CONFIG_POWER_I2C -#define CONFIG_POWER_MAX77686 - /* GPT */ #define CONFIG_RANDOM_UUID -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 16/17] odroid: dts: add 'voltage-regulators' description to max77686 node
Adding regulators subnode to fdt max77686 node, allows properly init
regulators by the max77686 regulator driver. This enables the complete
functionality of the regulator command.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes V2:
- odroid: dts: remove pmic alias
Changes V3:
- none
---
arch/arm/dts/exynos4412-odroid.dts | 247 +
1 file changed, 247 insertions(+)
diff --git a/arch/arm/dts/exynos4412-odroid.dts
b/arch/arm/dts/exynos4412-odroid.dts
index 5507d9a..bc516a0 100644
--- a/arch/arm/dts/exynos4412-odroid.dts
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -40,6 +40,253 @@
interrupts = 7 0;
reg = 0x09 0 0;
#clock-cells = 1;
+
+ voltage-regulators {
+ ldo1_reg: ldo1 {
+ regulator-compatible = LDO1;
+ regulator-name = VDD_ALIVE_1.0V;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-compatible = LDO2;
+ regulator-name = VDDQ_VM1M2_1.2V;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-compatible = LDO3;
+ regulator-name = VCC_1.8V_AP;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-compatible = LDO4;
+ regulator-name = VDDQ_MMC2_2.8V;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-compatible = LDO5;
+ regulator-name = VDDQ_MMC0/1/3_1.8V;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-compatible = LDO6;
+ regulator-name = VMPLL_1.0V;
+ regulator-min-microvolt = 110;
+ regulator-max-microvolt = 110;
+ };
+
+ ldo7_reg: ldo7 {
+ regulator-compatible = LDO7;
+ regulator-name = VPLL_1.1V;
+ regulator-min-microvolt = 110;
+ regulator-max-microvolt = 110;
+ };
+
+ ldo8_reg: ldo8 {
+ regulator-compatible = LDO8;
+ regulator-name = VDD_MIPI/HDMI_1.0V;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ };
+
+ ldo9_reg: ldo9 {
+ regulator-compatible = LDO9;
+ regulator-name = nc;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo10_reg: ldo10 {
+ regulator-compatible = LDO10;
+ regulator-name = VDD_MIPI/HDMI_1.8V;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo11_reg: ldo11 {
+ regulator-compatible = LDO11;
+ regulator-name = VDD_ABB1_1.8V;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+
Re: [U-Boot] [PATCH 0/1] Adding Support for the BAV335x boards.
Folks, I'm so sorry, I just realized that this patch went out with a somewhat incorrect commit comment. The patch is correct but the comment is that of a prior patch (Not sure why it didn't use that of git yet, maybe because I had an older patch laying around in the same directory before running patman). Should I repost with the proper comment or just leave it as is? Cheers, Gilles . On Mar 23, 2015, at 23:13 , Gilles Gameiro gguess...@gmail.com wrote: This patch adds support for the BAV335x Network Processor boards. It supports both the Rev.A 10/100GB, and Rev.B with GB ethernet. Gilles Gameiro (1): Change defconfigs to include driver model (required after v2015.01), and fix typo in EEProm config format. board/birdland/bav335x/board.h | 2 +- configs/birdland_bav335a_defconfig | 356 - configs/birdland_bav335b_defconfig | 356 - 3 files changed, 709 insertions(+), 5 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board/p2020rdb: fix the FDT_ERR_NOTFOUND issue
From: Ying Zhang b40...@freescale.com
Because the function ft_board_setup() delete the USB2 device node, it
leads to can't find the device node and hung up.
In fact only P1020RDB needs to delete the USB2 node, this patch fixes
this issue.
Signed-off-by: Ying Zhang b40...@freescale.com
---
board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 4
1 file changed, 4 insertions(+)
diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 3f47cfb..0c60fc3 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -428,8 +428,10 @@ int ft_board_setup(void *blob, bd_t *bd)
{
phys_addr_t base;
phys_size_t size;
+#if defined(CONFIG_P1020RDB_PD) || defined(CONFIG_P1020RDB_PC)
const char *soc_usb_compat = fsl-usb2-dr;
int err, usb1_off, usb2_off;
+#endif
ft_cpu_setup(blob, bd);
@@ -473,6 +475,7 @@ int ft_board_setup(void *blob, bd_t *bd)
}
#endif
+#if defined(CONFIG_P1020RDB_PD) || defined(CONFIG_P1020RDB_PC)
/* Delete USB2 node as it is muxed with eLBC */
usb1_off = fdt_node_offset_by_compatible(blob, -1,
soc_usb_compat);
@@ -494,6 +497,7 @@ int ft_board_setup(void *blob, bd_t *bd)
return err;
}
+#endif
return 0;
}
#endif
--
1.8.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v9 24/28] armv8/ls2085aqds: NAND boot support
From: Scott Wood scottw...@freescale.com
This adds NAND boot support for LS2085AQDS, using SPL framework.
Details of forming NAND image can be found in README.
Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: York Sun york...@freescale.com
---
Changes in v9:
Update README for QDS NAND boot offset, page size, block size.
Fix nand block size in QDS board header file.
Changes in v8:
Update README to match the example for QDS NAND boot.
Changes in v7:
Move NAND boot instruction to fsl-lsch3/README.
Update board setting to put RCW and u-boot in different NAND block.
Changes in v6: None
Changes in v5:
Update LS2085AQDS README to include instructions to form NAND image
Changes in v4:
Update MAINTAINERS file
Changes in v3: None
Changes in v2: None
arch/arm/Kconfig |1 +
arch/arm/cpu/armv8/fsl-lsch3/README | 38 +++
arch/arm/cpu/armv8/fsl-lsch3/soc.c| 48 +
arch/arm/cpu/armv8/{u-boot.lds = u-boot-spl.lds} | 74 +
arch/arm/include/asm/arch-fsl-lsch3/config.h |9 +++
arch/arm/lib/crt0_64.S|7 ++
board/freescale/ls2085aqds/MAINTAINERS|1 +
board/freescale/ls2085aqds/ddr.c |4 ++
common/spl/spl.c |2 +-
common/spl/spl_nand.c |2 +-
configs/ls2085aqds_nand_defconfig |4 ++
drivers/misc/fsl_ifc.c| 12
drivers/mtd/nand/fsl_ifc_spl.c|2 +-
include/configs/ls2085a_common.h | 29
include/configs/ls2085aqds.h | 50 --
15 files changed, 232 insertions(+), 51 deletions(-)
copy arch/arm/cpu/armv8/{u-boot.lds = u-boot-spl.lds} (57%)
create mode 100644 configs/ls2085aqds_nand_defconfig
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6ba4b8d..f73541c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -652,6 +652,7 @@ config TARGET_LS2085AQDS
bool Support ls2085aqds
select ARM64
select ARMV8_MULTIENTRY
+ select SUPPORT_SPL
help
Support for Freescale LS2085AQDS platform
The LS2085A Development System (QDS) is a high-performance
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/README
b/arch/arm/cpu/armv8/fsl-lsch3/README
index 4f36e2a..15a1549 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/README
+++ b/arch/arm/cpu/armv8/fsl-lsch3/README
@@ -95,3 +95,41 @@ mcboottimeout: MC boot timeout in milliseconds. If
this variable is not defined
mcmemsize: MC DRAM block size. If this variable is not defined, the value
CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE will be assumed.
+
+Booting from NAND
+---
+Booting from NAND requires two images, RCW and u-boot-with-spl.bin.
+The difference between NAND boot RCW image and NOR boot image is the PBI
+command sequence. Below is one example for PBI commands for QDS which uses
+NAND device with 2KB/page, block size 128KB.
+
+1) CCSR 4-byte write to 0x00e00404, data=0x
+2) CCSR 4-byte write to 0x00e00400, data=0x1800a000
+The above two commands set bootloc register to 0x_1800a000 where
+the u-boot code will be running in OCRAM.
+
+3) Block Copy: SRC=0x0107, SRC_ADDR=0x0002, DEST_ADDR=0x1800a000,
+BLOCK_SIZE=0x00014000
+This command copies u-boot image from NAND device into OCRAM. The values need
+to adjust accordingly.
+
+SRCshould match the cfg_rcw_src, the reset config pins. It depends
+ on the NAND device. See reference manual for cfg_rcw_src.
+SRC_ADDR is the offset of u-boot-with-spl.bin image in NAND device. In
+ the example above, 128KB. For easy maintenance, we put it at
+ the beginning of next block from RCW.
+DEST_ADDR is fixed at 0x1800a000, matching bootloc set above.
+BLOCK_SIZE is the size to be copied by PBI.
+
+RCW image should be written to the beginning of NAND device. Example of using
+u-boot command
+
+nand write rcw image in memory 0 size of rcw image
+
+To form the NAND image, build u-boot with NAND config, for example,
+ls2085aqds_nand_defconfig. The image needed is u-boot-with-spl.bin.
+The u-boot image should be written to match SRC_ADDR, in above example 0x2.
+
+nand write u-boot image in memory 20 size of u-boot image
+
+With these two images in NAND device, the board can boot from NAND.
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/soc.c
b/arch/arm/cpu/armv8/fsl-lsch3/soc.c
index 17700ef..ca00108 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/soc.c
+++ b/arch/arm/cpu/armv8/fsl-lsch3/soc.c
@@ -6,8 +6,13 @@
#include common.h
#include fsl_ifc.h
+#include nand.h
+#include spl.h
#include asm/arch-fsl-lsch3/soc.h
#include asm/io.h
+#include asm/global_data.h
+
+DECLARE_GLOBAL_DATA_PTR;
static void erratum_a008751(void)
{
@@ -18,8 +23,51 @@ static void
[U-Boot] [PATCH v9 26/28] armv8/ls2085ardb: Enable NAND SPL support
From: Scott Wood scottw...@freescale.com
Enable NAND boot support using SPL framework. To boot from
NAND, either use DIP switches on board, or qixis_reset nand
command. Details of forming NAND image can be found in README.
Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: York Sun york...@freescale.com
---
Changes in v9:
Update README to add nand page size and block size.
Changes in v8:
Update README to add example for RDB NAND boot.
Changes in v7:
Move NAND boot instruction to fsl-lsch3/README.
Update board setting to put RCW and u-boot in different NAND block.
Changes in v6: None
Changes in v5:
Fix signed-off-by signature
Update LS2085ARDB README to include instructions to form NAND image
Changes in v4:
Update MAINTAINERS file
Changes in v3: None
Changes in v2: None
arch/arm/Kconfig |1 +
arch/arm/cpu/armv8/fsl-lsch3/README| 13 +++
board/freescale/ls2085ardb/MAINTAINERS |1 +
board/freescale/ls2085ardb/ddr.c |4
configs/ls2085ardb_nand_defconfig |4
include/configs/ls2085ardb.h | 40
6 files changed, 58 insertions(+), 5 deletions(-)
create mode 100644 configs/ls2085ardb_nand_defconfig
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f73541c..cf291c8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -663,6 +663,7 @@ config TARGET_LS2085ARDB
bool Support ls2085ardb
select ARM64
select ARMV8_MULTIENTRY
+ select SUPPORT_SPL
help
Support for Freescale LS2085ARDB platform.
The LS2085A Reference design board (RDB) is a high-performance
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/README
b/arch/arm/cpu/armv8/fsl-lsch3/README
index 15a1549..37f07fb 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/README
+++ b/arch/arm/cpu/armv8/fsl-lsch3/README
@@ -133,3 +133,16 @@ The u-boot image should be written to match SRC_ADDR, in
above example 0x2.
nand write u-boot image in memory 20 size of u-boot image
With these two images in NAND device, the board can boot from NAND.
+
+Another example for RDB boards,
+
+1) CCSR 4-byte write to 0x00e00404, data=0x
+2) CCSR 4-byte write to 0x00e00400, data=0x1800a000
+3) Block Copy: SRC=0x0119, SRC_ADDR=0x0008, DEST_ADDR=0x1800a000,
+BLOCK_SIZE=0x00014000
+
+nand write rcw image in memory 0 size of rcw image
+nand write u-boot image in memory 8 size of u-boot image
+
+Notice the difference from QDS is SRC, SRC_ADDR and the offset of u-boot image
+to match board NAND device with 4KB/page, block size 512KB.
diff --git a/board/freescale/ls2085ardb/MAINTAINERS
b/board/freescale/ls2085ardb/MAINTAINERS
index 436039f..d5cce40 100644
--- a/board/freescale/ls2085ardb/MAINTAINERS
+++ b/board/freescale/ls2085ardb/MAINTAINERS
@@ -5,3 +5,4 @@ F: board/freescale/ls2085ardb/
F: board/freescale/ls2085a/ls2085ardb.c
F: include/configs/ls2085ardb.h
F: configs/ls2085ardb_defconfig
+F: configs/ls2085ardb_nand_defconfig
diff --git a/board/freescale/ls2085ardb/ddr.c b/board/freescale/ls2085ardb/ddr.c
index 6cd5e8b..8d71ae1 100644
--- a/board/freescale/ls2085ardb/ddr.c
+++ b/board/freescale/ls2085ardb/ddr.c
@@ -147,9 +147,13 @@ phys_size_t initdram(int board_type)
{
phys_size_t dram_size;
+#if defined(CONFIG_SPL) !defined(CONFIG_SPL_BUILD)
+ return fsl_ddr_sdram_size();
+#else
puts(Initializing DDRusing SPD\n);
dram_size = fsl_ddr_sdram();
+#endif
return dram_size;
}
diff --git a/configs/ls2085ardb_nand_defconfig
b/configs/ls2085ardb_nand_defconfig
new file mode 100644
index 000..39ba8c5
--- /dev/null
+++ b/configs/ls2085ardb_nand_defconfig
@@ -0,0 +1,4 @@
++S:CONFIG_SYS_EXTRA_OPTIONS=SYS_FSL_DDR4,NAND
++S:CONFIG_SPL=y
++S:CONFIG_ARM=y
++S:CONFIG_TARGET_LS2085ARDB=y
diff --git a/include/configs/ls2085ardb.h b/include/configs/ls2085ardb.h
index 0a5873b..ae5c2a9 100644
--- a/include/configs/ls2085ardb.h
+++ b/include/configs/ls2085ardb.h
@@ -139,11 +139,13 @@ unsigned long get_board_sys_clk(void);
#define QIXIS_LBMAP_SHIFT 0
#define QIXIS_LBMAP_DFLTBANK 0x00
#define QIXIS_LBMAP_ALTBANK0x04
+#define QIXIS_LBMAP_NAND 0x09
#define QIXIS_RST_CTL_RESET0x31
#define QIXIS_RST_CTL_RESET_EN 0x30
#define QIXIS_RCFG_CTL_RECONFIG_IDLE 0x20
#define QIXIS_RCFG_CTL_RECONFIG_START 0x21
#define QIXIS_RCFG_CTL_WATCHDOG_ENBLE 0x08
+#define QIXIS_RCW_SRC_NAND 0x119
#defineQIXIS_RST_FORCE_MEM 0x01
#define CONFIG_SYS_CSPR3_EXT (0x0)
@@ -169,6 +171,33 @@ unsigned long get_board_sys_clk(void);
FTIM2_GPCM_TWP(0x3E))
#define CONFIG_SYS_CS3_FTIM3 0x0
+#if defined(CONFIG_SPL) defined(CONFIG_NAND)
+#define CONFIG_SYS_CSPR2_EXT CONFIG_SYS_NOR0_CSPR_EXT
+#define CONFIG_SYS_CSPR2 CONFIG_SYS_NOR0_CSPR_EARLY
+#define
[U-Boot] [PATCH v3 00/17] Power(full) framework based on Driver Model
Hello, Here is the third RFC version of the new PMIC framework.Big thanks to Simon Glass, your comments were really helpful, and I think, that this version is much more better to discuss, than the previous. The changes made in this version are described below each commit. Sorry that I didn't reply to each patch, I agreed with most and just started the work. Best regards Przemyslaw Marczak (17): exynos5: fix build break by adding CONFIG_POWER fdt_ro.c: add new function: fdt_node_check_prop_compatible() dm: core: lists.c: add new function lists_bind_fdt_by_prop() lib: Kconfig: add entry for errno_str() function dm: pmic: add implementation of driver model pmic uclass dm: regulator: add implementation of driver model regulator uclass dm: pmic: add pmic command dm: regulator: add regulator command pmic: max77686 set the same compatible as in the kernel dm: pmic: add max77686 pmic driver dm: regulator: add max77686 regulator driver dm: regulator: add fixed voltage regulator driver doc: driver-model: pmic and regulator uclass documentation dm: board:samsung: power_init_board: add requirement of CONFIG_DM_PMIC odroid: board: add support to dm pmic api odroid: dts: add 'voltage-regulators' description to max77686 node odroid: config: enable dm pmic, dm regulator and max77686 driver Makefile | 1 + arch/arm/dts/exynos4412-odroid.dts | 249 +- arch/arm/dts/exynos4412-trats2.dts | 2 +- arch/arm/dts/exynos5250-smdk5250.dts | 2 +- arch/arm/dts/exynos5250-snow.dts | 2 +- board/samsung/common/board.c | 4 +- board/samsung/common/misc.c | 1 + board/samsung/odroid/odroid.c| 113 - common/Kconfig | 36 ++ common/Makefile | 4 + common/cmd_pmic.c| 210 + common/cmd_regulator.c | 385 +++ configs/odroid_defconfig | 8 +- doc/driver-model/pmic-framework.txt | 350 ++ drivers/core/lists.c | 28 +- drivers/power/Kconfig| 124 - drivers/power/Makefile | 3 +- drivers/power/pmic-uclass.c | 130 ++ drivers/power/pmic/Makefile | 1 + drivers/power/pmic/max77686.c| 76 +++ drivers/power/pmic/pmic_max77686.c | 2 +- drivers/power/regulator-uclass.c | 219 + drivers/power/regulator/Makefile | 9 + drivers/power/regulator/fixed.c | 124 + drivers/power/regulator/max77686.c | 876 +++ include/configs/exynos5-common.h | 4 + include/configs/odroid.h | 5 - include/dm/lists.h | 18 + include/dm/uclass-id.h | 4 + include/libfdt.h | 27 ++ include/power/max77686_pmic.h| 26 +- include/power/pmic.h | 210 + include/power/regulator.h| 259 +++ lib/Kconfig | 8 + lib/fdtdec.c | 2 +- lib/libfdt/fdt_ro.c | 14 +- 36 files changed, 3481 insertions(+), 55 deletions(-) create mode 100644 common/cmd_pmic.c create mode 100644 common/cmd_regulator.c create mode 100644 doc/driver-model/pmic-framework.txt create mode 100644 drivers/power/pmic-uclass.c create mode 100644 drivers/power/pmic/max77686.c create mode 100644 drivers/power/regulator-uclass.c create mode 100644 drivers/power/regulator/Makefile create mode 100644 drivers/power/regulator/fixed.c create mode 100644 drivers/power/regulator/max77686.c create mode 100644 include/power/regulator.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 01/17] exynos5: fix build break by adding CONFIG_POWER
Move the configs listed below from exynos5-dt-common.h to exynos5-common.h: - CONFIG_POWER - CONFIG_POWER_I2C fixes build break for Arndale and Smdk5250 boards. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com --- include/configs/exynos5-common.h | 4 1 file changed, 4 insertions(+) diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-common.h index 3ab8d55..3ee9482 100644 --- a/include/configs/exynos5-common.h +++ b/include/configs/exynos5-common.h @@ -149,6 +149,10 @@ #define CONFIG_OF_SPI #endif +/* Power */ +#define CONFIG_POWER +#define CONFIG_POWER_I2C + #ifdef CONFIG_ENV_IS_IN_SPI_FLASH #define CONFIG_ENV_SPI_MODESPI_MODE_0 #define CONFIG_ENV_SECT_SIZE CONFIG_ENV_SIZE -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: rpi: fix RPi1 board rev detection for warranty bit
On Mon, Mar 23, 2015 at 11:00:25PM -0600, Stephen Warren wrote: Apparently the firmware's board rev response includes both the board revision and some other data even on the RPi1. In particular, the warranty bit is bit 24. We need to mask that out when looking up the board ID. Signed-off-by: Stephen Warren swar...@wwwdotorg.org 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
