Re: [U-Boot] [PATCH v3 00/11] mx6: SPL NAND support
On Wed, May 7, 2014 at 10:16 PM, Tim Harvey thar...@gateworks.com wrote: This series adds some necessary framework for IMX6 SPL support. The series includes support for NAND SPL and has been tested with MMC as well. I have tested this on five differing Ventana baseboards with a variety of memory (32bit 512MB, 32bit 1024MB, 64bit 1024MB) and CPU configurations (IMX6Q, IMX6DL, IMX6S). This is based on top of Mashahiro Yamada's patch that consolidates arch/arm/include/asm/arch-*/spl.h [1] v3: - re-ordered calls in board_init_f - replace imx_iomux_v3_setup_multiple_pads_array with additional intelligence in imx_iomux_v3_setup_multiple_pads - added ifdef's around cpu specific mmdc iocfg functions for code-reduction with single-variant board configs - added checks for IMX6D - added Freescale copyright to boot device support function - fixed typo s/IMX6SLD/IMX6SDL - encorporated cleanups in mxs_nand_spl.c per feedback v2: - use compatible linker script instead of creating new one - remove structure passing data from SPL to u-boot - remove dependence on mtdpart, mtdcore, nand_util, nand_ecc, nand_base and nand_bbt to bring SPL down in size. This reduced codesize by about 32k where now mxs_spl_nand is about 12k total - adjust CONFIG_SPL_TEXT_BASE, CONFIG_SPL_STACK and CONFIG_SPL_MAX_SIZE to accomodate the IMX6SOLO/DUALLITE which have half the iRAM of the IMX6DUAL/IMX6QUAD - move boot dev detection into imx-common/spl.c - move macros for using pinmux array into iomux-v3.h - remove missing/unnecessary include - revert mtdparts change - use get_ram_size() to detect memory - add support for MX6SOLO and MX6DUAL - set CS0_END for 4GB so get_ram_size() works - updated DDR3 calibration values for ventana boards - fixed build issue - only compile spl if doing spl build - fixed line length issue in README - remove CONFIG_SPL* conditions and conditionally compile instead - removed prints for CPU type and DRAM size/width - uboot will print these l - removed unused gw_ventana_spl.cfg - use common read_eeprom function - added MMC support to SPL - added Masahiro Yamada's boot mode consolidation patch http://patchwork.ozlabs.org/patch/341817 and rebase on top of it [1] http://patchwork.ozlabs.org/patch/341817/ Tim Harvey (11): SPL: NAND: remove CONFIG_SYS_NAND_PAGE_SIZE SPL: NAND: add support for mxs nand MX6: add common SPL configuration MX6: add boot device support for SPL IMX: add comments and remove unused struct fields MX6: add structs for mmdc and ddr iomux registers MX6: add mmdc configuration for MX6Q/MX6DL IMX: iomux: add macros to setup iomux for multiple SoC types IMX: ventana: split read_eeprom into standalone file IMX: ventana: auto-configure for IMX6Q vs IMX6DL IMX: ventana: switch to SPL arch/arm/cpu/armv7/mx6/Makefile | 1 + arch/arm/cpu/armv7/mx6/ddr.c| 473 ++ arch/arm/imx-common/Makefile| 1 + arch/arm/imx-common/cpu.c | 16 +- arch/arm/imx-common/iomux-v3.c | 16 +- arch/arm/imx-common/spl.c | 81 arch/arm/include/asm/arch-mx6/mx6-ddr.h | 231 +++ arch/arm/include/asm/imx-common/iomux-v3.h | 25 ++ board/gateworks/gw_ventana/Makefile | 3 +- board/gateworks/gw_ventana/README | 92 +++-- board/gateworks/gw_ventana/eeprom.c | 89 + board/gateworks/gw_ventana/gw_ventana.c | 591 +++- board/gateworks/gw_ventana/gw_ventana.cfg | 15 - board/gateworks/gw_ventana/gw_ventana_spl.c | 419 board/gateworks/gw_ventana/ventana_eeprom.h | 11 + boards.cfg | 6 +- common/spl/spl_nand.c | 2 +- drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/mxs_nand_spl.c | 231 +++ include/configs/gw_ventana.h| 11 + include/configs/imx6_spl.h | 71 21 files changed, 2047 insertions(+), 339 deletions(-) create mode 100644 arch/arm/cpu/armv7/mx6/ddr.c create mode 100644 arch/arm/imx-common/spl.c create mode 100644 board/gateworks/gw_ventana/eeprom.c create mode 100644 board/gateworks/gw_ventana/gw_ventana_spl.c create mode 100644 drivers/mtd/nand/mxs_nand_spl.c create mode 100644 include/configs/imx6_spl.h -- 1.8.3.2 Stefano, Any comments on this series? I realize you've applied the first one and I'll remove that from any subsequent posts. Regards, Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting armv8 kernel on uboot
Hi, Thanks for the inputs. On 21 May 2014 21:04, Mark Rutland mark.rutl...@arm.com wrote: On Wed, May 21, 2014 at 04:28:53PM +0100, Tom Rini wrote: On Wed, May 21, 2014 at 10:40:38AM +0100, Mark Rutland wrote: On Wed, May 21, 2014 at 09:46:35AM +0100, Vishal Bhoj wrote: Hi , Hi, I have added mmc driver into the vexpress64 board file for uboot and tested it on FVP base model. I tried booting a kernel on that but it is aborting with the following message: Final value for argc=3 Loading Kernel Image ... OK kernel loaded at 0x0008, end = 0x00827024 using: FDT reserving fdt memory region: addr=8000 size=1 ## initrd_high = 0x, copy_to_ram = 1 ramdisk load start = 0x, ramdisk load end = 0x ## device tree at 90008000 ... 9000a850 (len=22609 [0x5851]) Loading Device Tree to 9fffa000, end 9850 ... OK Initial value for argc=3 Final value for argc=3 ## Transferring control to Linux (at address 8)... Starting kernel ... Synchronous Abort handler, esr 0x0200 That ESR_ELx value means Unknown/uncategorized. It would be fantastic if U-Boot would tell us what EL it's branching to the kernel at as a matter of course -- it's not really possible to debug from logs otherwise. Which EL are you loading the kernel at? So, this I suspect is one of the problems I was trying to describe to you back at ELC which turned out to be loading things at the very wrong address (0x8 rather than 0x8008). That would certainly explain it. From the lines above stating that the kernel had been loaded to 0x8 I assumed that memory had been configured there. Vishal, cay you apply: http://patchwork.ozlabs.org/patch/345746/ http://patchwork.ozlabs.org/patch/345748/ http://patchwork.ozlabs.org/patch/345749/ http://patchwork.ozlabs.org/patch/345747/ Included these patches. I need to do a v2 still to address some feedback, and then also say we require Mark's recent series to add an image size field (and other cleanups) and make use of that (and the rest of the series changes/clarifications). Can you please share the patches. I am currently booting 3.10 Linaro stable kernel which works with ARM's trusted firmware + UEFI. The same kernel with the above patches doesn't boot on u-boot. Is there any specific kernel tree you suggest I should use which is known to boot on uboot + models ? I have generated uImage with loadaddress as 0x8008 and tried booting but doesn't boot. Here are the logs: http://pastebin.com/T882rK3P I'll try to get a v2 out on my series shortly, it'd be nice to have as soon as possible. :) Cheers, Mark. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/11] mx6: SPL NAND support
Hi Tim, On 22/05/2014 08:14, Tim Harvey wrote: Stefano, Any comments on this series? I realize you've applied the first one and I'll remove that from any subsequent posts. Right. I think we have a very good point (nice work !) and we are near to merge the patchset. If I am not wrong, you want to post an update for the MMDC config patch, do you ? Patch 2 should be acked by Scott because it belongs to his area of competence. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm:board:exynos4: add CONFIG_SYS_GENERIC_BOARD
Add CONFIG_SYS_GENERIC_BOARD for all Exynos4 boards. Signed-off-by: Piotr Wilczek p.wilc...@samsung.com Cc: Przemyslaw Marczak p.marc...@samsung.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- include/configs/exynos4-dt.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/exynos4-dt.h b/include/configs/exynos4-dt.h index 0c560ae..44e6ab4 100644 --- a/include/configs/exynos4-dt.h +++ b/include/configs/exynos4-dt.h @@ -20,6 +20,7 @@ #define CONFIG_DISPLAY_CPUINFO #define CONFIG_DISPLAY_BOARDINFO #define CONFIG_BOARD_COMMON +#define CONFIG_SYS_GENERIC_BOARD /* Enable fdt support */ #define CONFIG_OF_CONTROL -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] am33xx: report silicon revision instead of code
As revision code 1 is for silicon revision 2.0, it is easily confused with
silicon revision 1.0.
Device type report also reworked in same style.
Signed-off-by: Sergey Alyoshin alyoshi...@gmail.com
---
arch/arm/cpu/armv7/am33xx/sys_info.c | 41 +++---
1 file changed, 23 insertions(+), 18 deletions(-)
diff --git a/arch/arm/cpu/armv7/am33xx/sys_info.c
b/arch/arm/cpu/armv7/am33xx/sys_info.c
index 50eb598..2ce682f 100644
--- a/arch/arm/cpu/armv7/am33xx/sys_info.c
+++ b/arch/arm/cpu/armv7/am33xx/sys_info.c
@@ -79,12 +79,24 @@ u32 get_sysboot_value(void)
}
#ifdef CONFIG_DISPLAY_CPUINFO
+static char *cpu_revs[] = {
+ 1.0,
+ 2.0,
+ 2.1};
+
+
+static char *dev_types[] = {
+ TST,
+ EMU,
+ HS,
+ GP};
+
/**
* Print CPU information
*/
int print_cpuinfo(void)
{
- char *cpu_s, *sec_s;
+ char *cpu_s, *sec_s, *rev_s;
switch (get_cpu_type()) {
case AM335X:
@@ -94,28 +106,21 @@ int print_cpuinfo(void)
cpu_s = TI81XX;
break;
default:
- cpu_s = Unknown cpu type;
+ cpu_s = Unknown CPU type;
break;
}
- switch (get_device_type()) {
- case TST_DEVICE:
- sec_s = TST;
- break;
- case EMU_DEVICE:
- sec_s = EMU;
- break;
- case HS_DEVICE:
- sec_s = HS;
- break;
- case GP_DEVICE:
- sec_s = GP;
- break;
- default:
+ if (get_cpu_rev() ARRAY_SIZE(cpu_revs))
+ rev_s = cpu_revs[get_cpu_rev()];
+ else
+ rev_s = ?;
+
+ if (get_device_type() ARRAY_SIZE(dev_types))
+ sec_s = dev_types[get_device_type()];
+ else
sec_s = ?;
- }
- printf(%s-%s rev %d\n, cpu_s, sec_s, get_cpu_rev());
+ printf(%s-%s rev %s\n, cpu_s, sec_s, rev_s);
return 0;
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ppc] qemu-ppce500 howto
On 22.05.14 09:52, Alon Bar-Lev wrote: Hi, Trying to run the qemu-ppce500 within qemu. I am using -bios u-boot.bin and no luck, I get live signal. I am using latest u-boot master and qemu master. Command: $ ./qemu-system-ppc -M ppce500 -nographic -bios u-boot.bin Tried to load u-boot as well, same. Yes, that command should work with the right patches :). Unfortunately they are not in master yet, but instead waiting in my queue: https://github.com/agraf/qemu Please give things a try with the ppc-next branch in there. That should get things working for you. If you also want to run this using KVM, please keep in mind that you need a few extra patches that are in my kvm-ppc-queue branch as well. Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] drivers: net: cpsw: add support for using second port as ethernet
Add support for using the second slave port of cpsw
to be used as primary ethernet.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/cpsw.c | 8 +---
include/cpsw.h | 1 +
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index bd5fba2..8ec5161 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -211,6 +211,8 @@ struct cpdma_chan {
#define chan_read(chan, fld) __raw_readl((chan)-fld)
#define chan_read_ptr(chan, fld) ((void *)__raw_readl((chan)-fld))
+#define for_active_slave(slave, priv) \
+ slave = (priv)-slaves + (priv)-data.active_slave; if (slave)
#define for_each_slave(slave, priv) \
for (slave = (priv)-slaves; slave != (priv)-slaves + \
(priv)-data.slaves; slave++)
@@ -609,7 +611,7 @@ static int cpsw_update_link(struct cpsw_priv *priv)
int link = 0;
struct cpsw_slave *slave;
- for_each_slave(slave, priv)
+ for_active_slave(slave, priv)
cpsw_slave_update_link(slave, priv, link);
priv-mdio_link = readl(mdio_regs-link);
return link;
@@ -785,7 +787,7 @@ static int cpsw_init(struct eth_device *dev, bd_t *bis)
ALE_SECURE);
cpsw_ale_add_mcast(priv, NetBcastAddr, 1 priv-host_port);
- for_each_slave(slave, priv)
+ for_active_slave(slave, priv)
cpsw_slave_init(slave, priv);
cpsw_update_link(priv);
@@ -1013,7 +1015,7 @@ int cpsw_register(struct cpsw_platform_data *data)
cpsw_mdio_init(dev-name, data-mdio_base, data-mdio_div);
priv-bus = miiphy_get_dev_by_name(dev-name);
- for_each_slave(slave, priv)
+ for_active_slave(slave, priv)
cpsw_phy_init(dev, slave);
return 1;
diff --git a/include/cpsw.h b/include/cpsw.h
index a73843d..547b40c 100644
--- a/include/cpsw.h
+++ b/include/cpsw.h
@@ -44,6 +44,7 @@ struct cpsw_platform_data {
struct cpsw_slave_data *slave_data;
void(*control)(int enabled);
u32 host_port_num;
+ u32 active_slave;
u8 version;
};
--
1.9.2.459.g68773ac
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] ARM: DRA72x: Add CPSW Ethernet support for DRA72x SoC
CPSW Ethernet second port is pinned out as default Ethernet, so adding support for CPSW ethernet for downloading images via Ethernet. Mugunthan V N (3): drivers: net: cpsw: add support for using second port as ethernet ARM: DRA7xx: Add cpsw second port pinmux ARM: dra7_evm: Add Ethernet support for dra72x platform board/ti/dra7xx/evm.c | 7 ++- board/ti/dra7xx/mux_data.h | 12 drivers/net/cpsw.c | 8 +--- include/cpsw.h | 1 + 4 files changed, 24 insertions(+), 4 deletions(-) -- 1.9.2.459.g68773ac ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] ARM: DRA7xx: Add cpsw second port pinmux
Add cpsw second slave port pinmux to use it as primary ethernet port
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
board/ti/dra7xx/mux_data.h | 12
1 file changed, 12 insertions(+)
diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 38de9d5..56cda07 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -51,6 +51,18 @@ const struct pad_conf_entry core_padconf_array_essential[] =
{
{RGMII0_RXD2, (IEN | M0) },
{RGMII0_RXD1, (IEN | M0) },
{RGMII0_RXD0, (IEN | M0) },
+ {VIN2A_D12, (M3) },
+ {VIN2A_D13, (M3) },
+ {VIN2A_D14, (M3) },
+ {VIN2A_D15, (M3) },
+ {VIN2A_D16, (M3) },
+ {VIN2A_D17, (M3) },
+ {VIN2A_D18, (IEN | M3)},
+ {VIN2A_D19, (IEN | M3)},
+ {VIN2A_D20, (IEN | M3)},
+ {VIN2A_D21, (IEN | M3)},
+ {VIN2A_D22, (IEN | M3)},
+ {VIN2A_D23, (IEN | M3)},
{GPMC_A13, (IEN | PDIS | M1)}, /* QSPI1_RTCLK */
{GPMC_A14, (IEN | PDIS | M1)}, /* QSPI1_D[3] */
{GPMC_A15, (IEN | PDIS | M1)}, /* QSPI1_D[2] */
--
1.9.2.459.g68773ac
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] ARM: dra7_evm: Add Ethernet support for dra72x platform
Set the active_slave to 1 as slave 1 is pinned out in dra72x base board
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
board/ti/dra7xx/evm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 073d151..955c16f 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -157,6 +157,8 @@ int spl_start_uboot(void)
#define VIN2A_D15_DLY_VAL ((0x4 5) + 0x0)
#define VIN2A_D14_DLY_VAL ((0x4 5) + 0x0)
+extern u32 *const omap_si_rev;
+
static void cpsw_control(int enabled)
{
/* VTP can be added here */
@@ -183,7 +185,7 @@ static struct cpsw_platform_data cpsw_data = {
.mdio_div = 0xff,
.channels = 8,
.cpdma_reg_ofs = 0x800,
- .slaves = 1,
+ .slaves = 2,
.slave_data = cpsw_slaves,
.ale_reg_ofs= 0xd00,
.ale_entries= 1024,
@@ -254,6 +256,9 @@ int board_eth_init(bd_t *bis)
ctrl_val |= 0x22;
writel(ctrl_val, (*ctrl)-control_core_control_io1);
+ if (*omap_si_rev == DRA722_ES1_0)
+ cpsw_data.active_slave = 1;
+
ret = cpsw_register(cpsw_data);
if (ret 0)
printf(Error %d registering CPSW switch\n, ret);
--
1.9.2.459.g68773ac
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] ARM: DRA72x: Add CPSW Ethernet support for DRA72x SoC
On Thursday 22 May 2014 02:37 PM, Mugunthan V N wrote: CPSW Ethernet second port is pinned out as default Ethernet, so adding support for CPSW ethernet for downloading images via Ethernet. Mugunthan V N (3): drivers: net: cpsw: add support for using second port as ethernet ARM: DRA7xx: Add cpsw second port pinmux ARM: dra7_evm: Add Ethernet support for dra72x platform board/ti/dra7xx/evm.c | 7 ++- board/ti/dra7xx/mux_data.h | 12 drivers/net/cpsw.c | 8 +--- include/cpsw.h | 1 + 4 files changed, 24 insertions(+), 4 deletions(-) This patch series depends on the following patch set http://lists.denx.de/pipermail/u-boot/2014-May/179549.html Regards Mugunthan V N ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] Introduction of new board Peach-Pit
This board is based on Exynos5420 and is similar to SMDK5420 board. Adding new and refactoring existing DT and config files to support both SMDK5420 and Peach-Pit. Changes since v1: - Added Acked-by. Akshay Saraswat (2): Exynos5420: Introduce support for the Peach-Pit board Exynos5420: Let macros be used for exynos5420 arch/arm/cpu/armv7/exynos/exynos5_setup.h | 6 +- arch/arm/dts/Makefile | 3 +- arch/arm/dts/exynos5420-peach-pit.dts | 127 + arch/arm/dts/exynos5420-smdk5420.dts | 23 + arch/arm/dts/exynos5420.dtsi | 70 -- arch/arm/dts/exynos54xx.dtsi | 151 ++ boards.cfg| 1 + include/configs/exynos5420.h | 46 + include/configs/peach-pit.h | 27 ++ include/configs/smdk5420.h| 49 ++ 10 files changed, 367 insertions(+), 136 deletions(-) create mode 100644 arch/arm/dts/exynos5420-peach-pit.dts delete mode 100644 arch/arm/dts/exynos5420.dtsi create mode 100644 arch/arm/dts/exynos54xx.dtsi create mode 100644 include/configs/exynos5420.h create mode 100644 include/configs/peach-pit.h -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] Exynos5420: Introduce support for the Peach-Pit board
While the Exynos5420 chip is used in both Smdk5420 and in the Peach-Pit
line of devices, there could be other boards using the same chip, so a
common configuration file is being added (exynos5420.h) as well
as two common device tree files (exynos54xx.dtsi exynos5420.dtsi).
The peach board as declared in boards.cfg is a copy of smdk5420
declaration. The configuration files are similar, but define different
default device trees, console serial ports and prompts.
The device tree files for smdk5420 and peach-pit inherit from the same
common file.
Signed-off-by: Vadim Bendebury vben...@chromium.org
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/exynos5420-peach-pit.dts | 127
arch/arm/dts/exynos5420-smdk5420.dts | 23 +-
arch/arm/dts/exynos5420.dtsi | 70
arch/arm/dts/exynos54xx.dtsi | 151 ++
boards.cfg| 1 +
include/configs/exynos5420.h | 46 +++
include/configs/peach-pit.h | 27 ++
include/configs/smdk5420.h| 49 ++-
9 files changed, 364 insertions(+), 133 deletions(-)
create mode 100644 arch/arm/dts/exynos5420-peach-pit.dts
delete mode 100644 arch/arm/dts/exynos5420.dtsi
create mode 100644 arch/arm/dts/exynos54xx.dtsi
create mode 100644 include/configs/exynos5420.h
create mode 100644 include/configs/peach-pit.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5554615..933a464 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -6,7 +6,8 @@ dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb \
dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5250-snow.dtb \
exynos5250-smdk5250.dtb \
- exynos5420-smdk5420.dtb
+ exynos5420-smdk5420.dtb \
+ exynos5420-peach-pit.dtb
dtb-$(CONFIG_MX6) += imx6q-sabreauto.dtb
dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra20-medcom-wide.dtb \
diff --git a/arch/arm/dts/exynos5420-peach-pit.dts
b/arch/arm/dts/exynos5420-peach-pit.dts
new file mode 100644
index 000..8d148af
--- /dev/null
+++ b/arch/arm/dts/exynos5420-peach-pit.dts
@@ -0,0 +1,127 @@
+/*
+ * SAMSUNG/GOOGLE Peach-Pit board device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/include/ exynos54xx.dtsi
+
+/ {
+ model = Samsung/Google Peach Pit board based on Exynos5420;
+
+ compatible = google,pit-rev#, google,pit,
+ google,peach, samsung,exynos5420, samsung,exynos5;
+
+ config {
+ google,bad-wake-gpios = gpio 0x56 0; /* gpx0-6 */
+ hwid = PIT TEST A-A 7848;
+ lazy-init = 1;
+ };
+
+ aliases {
+ serial0 = /serial@12C3;
+ console = /serial@12C3;
+ pmic = /i2c@12ca;
+ };
+
+ dmc {
+ mem-manuf = samsung;
+ mem-type = ddr3;
+ clock-frequency = 8;
+ arm-frequency = 17;
+ };
+
+ tmu@1006 {
+ samsung,min-temp= 25;
+ samsung,max-temp= 125;
+ samsung,start-warning = 95;
+ samsung,start-tripping = 105;
+ samsung,hw-tripping = 110;
+ samsung,efuse-min-value = 40;
+ samsung,efuse-value = 55;
+ samsung,efuse-max-value = 100;
+ samsung,slope = 274761730;
+ samsung,dc-value= 25;
+ };
+
+ /* MAX77802 is on i2c bus 4 */
+ i2c@12ca {
+ clock-frequency = 40;
+ power-regulator@9 {
+ compatible = maxim,max77802-pmic;
+ reg = 0x9;
+ };
+ };
+
+ i2c@12cd { /* i2c7 */
+ clock-frequency = 10;
+ soundcodec@20 {
+ reg = 0x20;
+ compatible = maxim,max98090-codec;
+ };
+ };
+
+sound@383 {
+samsung,codec-type = max98090;
+};
+
+ i2c@12e1 { /* i2c9 */
+ clock-frequency = 40;
+tpm@20 {
+compatible = infineon,slb9645-tpm;
+reg = 0x20;
+ };
+ };
+
+ spi@12d3 { /* spi1 */
+ spi-max-frequency = 5000;
+ firmware_storage_spi: flash@0 {
+ reg = 0;
+
+ /*
+* A region for the kernel to store a panic event
+* which the firmware will add to the log.
+ */
+ elog-panic-event-offset = 0x01e0 0x10;
+
[U-Boot] [PATCH v2 2/2] Exynos5420: Let macros be used for exynos5420
Macros defined in exynos5_setup.h specific to SMDK5420 are required for Peach-Pit too. Hence, replacing CONFIG_SMDK5420 with CONFIG_EXYNOS5420 to enable these macros for all the boards based on Exynos5420. Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org --- arch/arm/cpu/armv7/exynos/exynos5_setup.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/exynos5_setup.h b/arch/arm/cpu/armv7/exynos/exynos5_setup.h index 53b0ace..db8ea86 100644 --- a/arch/arm/cpu/armv7/exynos/exynos5_setup.h +++ b/arch/arm/cpu/armv7/exynos/exynos5_setup.h @@ -431,10 +431,10 @@ /* * Definitions that differ with SoC's. - * Below is the part defining macros for smdk5250. - * Else part introduces macros for smdk5420. + * Below is the part defining macros for Exynos5250. + * Else part introduces macros for Exynos5420. */ -#ifndef CONFIG_SMDK5420 +#ifndef CONFIG_EXYNOS5420 /* APLL_CON1 */ #define APLL_CON1_VAL (0x00203800) -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] Exynos5: Update dmc init
This patch series introduces few updates with respect to ddr3 init function definition and read leveling. Akshay Saraswat (3): Exynos5: DMC: Modify the definition of ddr3_mem_ctrl_init Exynos5420: Remove code for enabling read leveling Exynos5420: DMC: Add software read leveling Doug Anderson (1): DMC: exynos5420: Gate CLKM to when reading PHY_CON13 arch/arm/cpu/armv7/exynos/dmc_common.c| 5 +- arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 368 +++--- arch/arm/cpu/armv7/exynos/exynos5_setup.h | 14 +- arch/arm/include/asm/arch-exynos/dmc.h| 3 + arch/arm/include/asm/arch-exynos/power.h | 4 +- 5 files changed, 299 insertions(+), 95 deletions(-) -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] Exynos5: DMC: Modify the definition of ddr3_mem_ctrl_init
Passing fewer arguments is better and mem_iv_size is never
used. Let's keep only one argument and make it cleaner.
Signed-off-by: Hatim Ali hatim...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/exynos/dmc_common.c| 5 +
arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 10 ++
arch/arm/cpu/armv7/exynos/exynos5_setup.h | 8 +---
3 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/dmc_common.c
b/arch/arm/cpu/armv7/exynos/dmc_common.c
index cca925e..acc9e25 100644
--- a/arch/arm/cpu/armv7/exynos/dmc_common.c
+++ b/arch/arm/cpu/armv7/exynos/dmc_common.c
@@ -155,14 +155,11 @@ void dmc_config_prech(struct mem_timings *mem, uint32_t
*directcmd)
void mem_ctrl_init(int reset)
{
struct spl_machine_param *param = spl_get_machine_params();
- struct mem_timings *mem;
int ret;
- mem = clock_get_mem_timings();
-
/* If there are any other memory variant, add their init call below */
if (param-mem_type == DDR_MODE_DDR3) {
- ret = ddr3_mem_ctrl_init(mem, param-mem_iv_size, reset);
+ ret = ddr3_mem_ctrl_init(reset);
if (ret) {
/* will hang if failed to init memory control */
while (1)
diff --git a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
index 487e6f4..a89930b 100644
--- a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
+++ b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
@@ -28,18 +28,19 @@ static void reset_phy_ctrl(void)
writel(DDR3PHY_CTRL_PHY_RESET, clk-lpddr3phy_ctrl);
}
-int ddr3_mem_ctrl_init(struct mem_timings *mem, unsigned long mem_iv_size,
- int reset)
+int ddr3_mem_ctrl_init(int reset)
{
unsigned int val;
struct exynos5_phy_control *phy0_ctrl, *phy1_ctrl;
struct exynos5_dmc *dmc;
+ struct mem_timings *mem;
int i;
phy0_ctrl = (struct exynos5_phy_control *)samsung_get_base_dmc_phy();
phy1_ctrl = (struct exynos5_phy_control *)(samsung_get_base_dmc_phy()
+ DMC_OFFSET);
dmc = (struct exynos5_dmc *)samsung_get_base_dmc_ctrl();
+ mem = clock_get_mem_timings();
if (reset)
reset_phy_ctrl();
@@ -221,8 +222,7 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, unsigned
long mem_iv_size,
#endif
#ifdef CONFIG_EXYNOS5420
-int ddr3_mem_ctrl_init(struct mem_timings *mem, unsigned long mem_iv_size,
- int reset)
+int ddr3_mem_ctrl_init(int reset)
{
struct exynos5420_clock *clk =
(struct exynos5420_clock *)samsung_get_base_clock();
@@ -231,6 +231,7 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, unsigned
long mem_iv_size,
struct exynos5420_phy_control *phy0_ctrl, *phy1_ctrl;
struct exynos5420_dmc *drex0, *drex1;
struct exynos5420_tzasc *tzasc0, *tzasc1;
+ struct mem_timings *mem;
uint32_t val, n_lock_r, n_lock_w_phy0, n_lock_w_phy1;
int chip;
int i;
@@ -244,6 +245,7 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, unsigned
long mem_iv_size,
tzasc0 = (struct exynos5420_tzasc *)samsung_get_base_dmc_tzasc();
tzasc1 = (struct exynos5420_tzasc *)(samsung_get_base_dmc_tzasc()
+ DMC_OFFSET);
+ mem = clock_get_mem_timings();
/* Enable PAUSE for DREX */
setbits_le32(clk-pause, ENABLE_BIT);
diff --git a/arch/arm/cpu/armv7/exynos/exynos5_setup.h
b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
index 53b0ace..b50af2f 100644
--- a/arch/arm/cpu/armv7/exynos/exynos5_setup.h
+++ b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
@@ -890,16 +890,10 @@ enum {
/*
* Memory variant specific initialization code for DDR3
*
- * @param mem Memory timings for this memory type.
- * @param mem_iv_size Memory interleaving size is a configurable parameter
- * which the DMC uses to decide how to split a memory
- * chunk into smaller chunks to support concurrent
- * accesses; may vary across boards.
* @param reset Reset DDR PHY during initialization.
* @return 0 if ok, SETUP_ERR_... if there is a problem
*/
-int ddr3_mem_ctrl_init(struct mem_timings *mem, unsigned long mem_iv_size,
- int reset);
+int ddr3_mem_ctrl_init(int reset);
/* Memory variant specific initialization code for LPDDR3 */
void lpddr3_mem_ctrl_init(void);
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] Exynos5420: Remove code for enabling read leveling
This patch intends to remove all code which enables hardware read
leveling. All characterization environments may not cope up with
h/w read leveling enabled, hence, we need to disable this.
Also, disabling h/w read leveling improves the MIF LVcc value
(LVcc value is the value at which DDR will fail to work properly).
Improving LVcc means we have enough voltage margin for MIF.
When h/w leveling is enabled, we have almost zero volatge margin.
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 71 ---
1 file changed, 71 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
index a89930b..0822323 100644
--- a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
+++ b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
@@ -524,77 +524,6 @@ int ddr3_mem_ctrl_init(int reset)
drex1-directcmd);
}
- if (mem-read_leveling_enable) {
- /* Set Read DQ Calibration */
- val = (0x3 DIRECT_CMD_BANK_SHIFT) | 0x4;
- for (chip = 0; chip mem-chips_to_configure; chip++) {
- writel(val | (chip DIRECT_CMD_CHIP_SHIFT),
- drex0-directcmd);
- writel(val | (chip DIRECT_CMD_CHIP_SHIFT),
- drex1-directcmd);
- }
-
- val = readl(phy0_ctrl-phy_con1);
- val |= READ_LEVELLING_DDR3;
- writel(val, phy0_ctrl-phy_con1);
- val = readl(phy1_ctrl-phy_con1);
- val |= READ_LEVELLING_DDR3;
- writel(val, phy1_ctrl-phy_con1);
-
- val = readl(phy0_ctrl-phy_con2);
- val |= (RDLVL_EN | RDLVL_INCR_ADJ);
- writel(val, phy0_ctrl-phy_con2);
- val = readl(phy1_ctrl-phy_con2);
- val |= (RDLVL_EN | RDLVL_INCR_ADJ);
- writel(val, phy1_ctrl-phy_con2);
-
- setbits_le32(drex0-rdlvl_config,
-CTRL_RDLVL_DATA_ENABLE);
- i = TIMEOUT;
- while (((readl(drex0-phystatus) RDLVL_COMPLETE_CHO)
-!= RDLVL_COMPLETE_CHO) (i 0)) {
- /*
-* TODO(waihong): Comment on how long this take
-* to timeout
-*/
- sdelay(100);
- i--;
- }
- if (!i)
- return SETUP_ERR_RDLV_COMPLETE_TIMEOUT;
-
- clrbits_le32(drex0-rdlvl_config,
-CTRL_RDLVL_DATA_ENABLE);
- setbits_le32(drex1-rdlvl_config,
-CTRL_RDLVL_DATA_ENABLE);
- i = TIMEOUT;
- while (((readl(drex1-phystatus) RDLVL_COMPLETE_CHO)
-!= RDLVL_COMPLETE_CHO) (i 0)) {
- /*
-* TODO(waihong): Comment on how long this take
-* to timeout
-*/
- sdelay(100);
- i--;
- }
- if (!i)
- return SETUP_ERR_RDLV_COMPLETE_TIMEOUT;
-
- clrbits_le32(drex1-rdlvl_config,
-CTRL_RDLVL_DATA_ENABLE);
-
- val = (0x3 DIRECT_CMD_BANK_SHIFT);
- for (chip = 0; chip mem-chips_to_configure; chip++) {
- writel(val | (chip DIRECT_CMD_CHIP_SHIFT),
- drex0-directcmd);
- writel(val | (chip DIRECT_CMD_CHIP_SHIFT),
- drex1-directcmd);
- }
-
- update_reset_dll(drex0-phycontrol0, DDR_MODE_DDR3);
- update_reset_dll(drex1-phycontrol0, DDR_MODE_DDR3);
- }
-
/* Common Settings for Leveling */
val = PHY_CON12_RESET_VAL;
writel((val + n_lock_w_phy0), phy0_ctrl-phy_con12);
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] DMC: exynos5420: Gate CLKM to when reading PHY_CON13
From: Doug Anderson diand...@chromium.org
From experiments it appears that PHY_CON13 is glitchy if we sample it
when CLKM is running. If we stop CLKM when sampling it the glitches
all go away, so we'll do that.
We also check the is it locked bits of PHY_CON13 and loop until they
show that the value sampled actually represents a locked value. It
doesn't appear that the glitching and is it locked are related, but
it seems wise to wait until the PHY tells us the value is good before
we use it. In practice we will not loop more than a couple times (and
usually won't loop at all).
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 43 +++
arch/arm/cpu/armv7/exynos/exynos5_setup.h | 1 +
2 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
index 0822323..0654c6a 100644
--- a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
+++ b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
@@ -233,6 +233,7 @@ int ddr3_mem_ctrl_init(int reset)
struct exynos5420_tzasc *tzasc0, *tzasc1;
struct mem_timings *mem;
uint32_t val, n_lock_r, n_lock_w_phy0, n_lock_w_phy1;
+ uint32_t lock0_info, lock1_info;
int chip;
int i;
@@ -396,7 +397,41 @@ int ddr3_mem_ctrl_init(int reset)
*/
dmc_config_mrs(mem, drex0-directcmd);
dmc_config_mrs(mem, drex1-directcmd);
- } else {
+ }
+
+ /*
+* Get PHY_CON13 from both phys. Gate CLKM around reading since
+* PHY_CON13 is glitchy when CLKM is running. We're paranoid and
+* wait until we get a fine lock, though a coarse lock is probably
+* OK (we only use the coarse numbers below). We try to gate the
+* clock for as short a time as possible in case SDRAM is somehow
+* sensitive. sdelay(10) in the loop is arbitrary to make sure
+* there is some time for PHY_CON13 to get updated. In practice
+* no delay appears to be needed.
+*/
+ val = readl(clk-gate_bus_cdrex);
+ while (true) {
+ writel(val ~0x1, clk-gate_bus_cdrex);
+ lock0_info = readl(phy0_ctrl-phy_con13);
+ writel(val, clk-gate_bus_cdrex);
+
+ if ((lock0_info CTRL_FINE_LOCKED) == CTRL_FINE_LOCKED)
+ break;
+
+ sdelay(10);
+ }
+ while (true) {
+ writel(val ~0x2, clk-gate_bus_cdrex);
+ lock1_info = readl(phy1_ctrl-phy_con13);
+ writel(val, clk-gate_bus_cdrex);
+
+ if ((lock1_info CTRL_FINE_LOCKED) == CTRL_FINE_LOCKED)
+ break;
+
+ sdelay(10);
+ }
+
+ if (!reset) {
/*
* During Suspend-Resume S/W-Reset, as soon as PMU releases
* pad retention, CKE goes high. This causes memory contents
@@ -447,15 +482,13 @@ int ddr3_mem_ctrl_init(int reset)
val |= (RDLVL_PASS_ADJ_VAL RDLVL_PASS_ADJ_OFFSET);
writel(val, phy1_ctrl-phy_con1);
- n_lock_r = readl(phy0_ctrl-phy_con13);
- n_lock_w_phy0 = (n_lock_r CTRL_LOCK_COARSE_MASK) 2;
+ n_lock_w_phy0 = (lock0_info CTRL_LOCK_COARSE_MASK) 2;
n_lock_r = readl(phy0_ctrl-phy_con12);
n_lock_r = ~CTRL_DLL_ON;
n_lock_r |= n_lock_w_phy0;
writel(n_lock_r, phy0_ctrl-phy_con12);
- n_lock_r = readl(phy1_ctrl-phy_con13);
- n_lock_w_phy1 = (n_lock_r CTRL_LOCK_COARSE_MASK) 2;
+ n_lock_w_phy1 = (lock1_info CTRL_LOCK_COARSE_MASK) 2;
n_lock_r = readl(phy1_ctrl-phy_con12);
n_lock_r = ~CTRL_DLL_ON;
n_lock_r |= n_lock_w_phy1;
diff --git a/arch/arm/cpu/armv7/exynos/exynos5_setup.h
b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
index b50af2f..1cf9caf 100644
--- a/arch/arm/cpu/armv7/exynos/exynos5_setup.h
+++ b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
@@ -284,6 +284,7 @@
#define CTRL_DLL_ON(1 5)
#define CTRL_FORCE_MASK(0x7F 8)
#define CTRL_LOCK_COARSE_MASK (0x7F 10)
+#define CTRL_FINE_LOCKED 0x7
#define CTRL_OFFSETD_RESET_VAL 0x8
#define CTRL_OFFSETD_VAL 0x7F
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] Exynos5420: DMC: Add software read leveling
Sometimes Read DQ and DQS are not in phase. Since, this
phase shift differs from board to board, we need to
calibrate it at DRAM init phase, that's read DQ calibration.
This patch adds SW Read DQ calibration routine to compensate
this skew.
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 244 +-
arch/arm/cpu/armv7/exynos/exynos5_setup.h | 5 +-
arch/arm/include/asm/arch-exynos/dmc.h| 3 +
arch/arm/include/asm/arch-exynos/power.h | 4 +-
4 files changed, 252 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
index 0654c6a..a4f6099 100644
--- a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
+++ b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
@@ -6,6 +6,7 @@
* SPDX-License-Identifier:GPL-2.0+
*/
+#include common.h
#include config.h
#include asm/io.h
#include asm/arch/clock.h
@@ -16,7 +17,12 @@
#include exynos5_setup.h
#include clock_init.h
-#define TIMEOUT1
+#define TIMEOUT1
+#define NUM_BYTE_LANES 4
+#define DEFAULT_DQS8
+#define DEFAULT_DQS_X4 0x08080808
+#define FALSE 0
+#define TRUE 1
#ifdef CONFIG_EXYNOS5250
static void reset_phy_ctrl(void)
@@ -222,6 +228,219 @@ int ddr3_mem_ctrl_init(int reset)
#endif
#ifdef CONFIG_EXYNOS5420
+/*
+ * RAM address to use in the test.
+ *
+ * We'll use 4 words at this address and 4 at this address + 0x80 (Ares
+ * interleaves channels every 128 bytes). This will allow us to evaluate all
of
+ * the chips in a 1 chip per channel (2GB) system and half the chips in a 2
+ * chip per channel (4GB) system. We can't test the 2nd chip since we need to
+ * do tests before the 2nd chip is enabled. Looking at the 2nd chip isn't
+ * critical because the 1st and 2nd chip have very similar timings (they'd
+ * better have similar timings, since there's only a single adjustment that is
+ * shared by both chips).
+ */
+const unsigned int test_addr = 0x2000;
+
+/* Test pattern with which RAM will be tested */
+static const unsigned int test_pattern[] = {
+ 0x5A5A5A5A,
+ 0xA5A5A5A5,
+ 0xF0F0F0F0,
+ 0x0F0F0F0F,
+};
+
+/*
+ * This function is a test vector for sw read leveling,
+ * it compares the read data with the written data.
+ *
+ * @param ch DMC channel number
+ * @param byte_lanewhich DQS byte offset,
+ * possible values are 0,1,2,3
+ * @returnsTRUE if memory was good, FALSE if not.
+ */
+static int dmc_valid_window_test_vector(int ch, int byte_lane)
+{
+ unsigned int read_data;
+ unsigned int mask;
+ int i;
+
+ mask = 0xFF (8 * byte_lane);
+
+ for (i = 0; i ARRAY_SIZE(test_pattern); i++) {
+ read_data = readl(test_addr + i*4 + ch*0x80);
+ if ((read_data mask) != (test_pattern[i] mask))
+ return FALSE;
+ }
+
+ return TRUE;
+}
+
+/*
+ * This function returns current read offset value.
+ *
+ * @param phy_ctrl pointer to the current phy controller
+ */
+static unsigned int dmc_get_read_offset_value(struct exynos5420_phy_control
+ *phy_ctrl)
+{
+ return readl(phy_ctrl-phy_con4);
+}
+
+/*
+ * This function performs resync, so that slave DLL is updated.
+ *
+ * @param phy_ctrl pointer to the current phy controller
+ */
+static void ddr_phy_set_do_resync(struct exynos5420_phy_control *phy_ctrl)
+{
+ setbits_le32(phy_ctrl-phy_con10, PHY_CON10_CTRL_OFFSETR3);
+ clrbits_le32(phy_ctrl-phy_con10, PHY_CON10_CTRL_OFFSETR3);
+}
+
+/*
+ * This function sets read offset value register with 'offset'.
+ *
+ * ...we also call call ddr_phy_set_do_resync().
+ *
+ * @param phy_ctrl pointer to the current phy controller
+ * @param offset offset to read DQS
+ */
+static void dmc_set_read_offset_value(struct exynos5420_phy_control *phy_ctrl,
+ unsigned int offset)
+{
+ writel(offset, phy_ctrl-phy_con4);
+ ddr_phy_set_do_resync(phy_ctrl);
+}
+
+/*
+ * Convert a 2s complement byte to a byte with a sign bit.
+ *
+ * NOTE: you shouldn't use normal math on the number returned by this function.
+ * As an example, -10 = 0xf6. After this function -10 = 0x8a. If you wanted
+ * to do math and get the average of 10 and -10 (should be 0):
+ * 0x8a + 0xa = 0x94 (-108)
+ * 0x94 / 2 = 0xca (-54)
+ * ...and 0xca = sign bit plus 0x4a, or -74
+ *
+ * Also note that you lose the ability to represent -128 since there are two
+ * representations of 0.
+ *
+ * @param bThe byte to convert in two's complement.
+ * @returnsThe 7-bit value + sign bit.
+ */
+
+unsigned char make_signed_byte(signed char b)
+{
+ if (b 0)
+ return
[U-Boot] Build problem - ppmc7xx configuration
Hi, I'm trying to compile the v2014.04 tag using ppmc7xx configuration on Ubuntu using powerpc-none-eabi toolchain. I'm running the following: make CROSS_COMPILE=powerpc-none-eabi- O=out/ ppmc7xx_config make CROSS_COMPILE=powerpc-none-eabi- O=out/ And receiving the following error: [...] LDS u-boot.lds LD u-boot powerpc-none-eabi-ld.bfd: /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(_lshrdi3.o): compiled normally and linked with modules compiled with -mrelocatable powerpc-none-eabi-ld.bfd: failed to merge target specific data of file /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(_lshrdi3.o) powerpc-none-eabi-ld.bfd: /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(_ashldi3.o): compiled normally and linked with modules compiled with -mrelocatable powerpc-none-eabi-ld.bfd: failed to merge target specific data of file /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(_ashldi3.o) powerpc-none-eabi-ld.bfd: /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(crtresxgpr.o): compiled normally and linked with modules compiled with -mrelocatable powerpc-none-eabi-ld.bfd: failed to merge target specific data of file /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(crtresxgpr.o) make[1]: *** [u-boot] Error 1 make: *** [sub-make] Error 2 Can anyone please assist me in understanding the problem? Is something wrong with my toolchain? (I've built it myself) Best regards, Vasili ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] dfu: Introduction of the dfu_hash_algo env variable for checksum method setting
Hi Heiko, Hello Lukasz, Am 16.05.2014 10:58, schrieb Lukasz Majewski: Hi Wolfgang, Tom, Hi Wolfgang, Dear Lukasz, In message20140515090904.32f1d13d@amdc2363 you wrote: What I complained about is the change in behaviour. I asked to make the existing behaviour the default, so unaware users will not be affected. Only if you intentionally want some other behaviour you can then enable this by setting the env variable. Well, looking at mainline usage of DFU, Lukasz is speaking for about half of the users / implementors. Since Denx is working with the other half, can you shed some light on actual use vs theoretical possibilities? I don't want to urge anybody on making any conclusion here :-), but I would be very grateful if we could come up with an agreement. As I've stated previously, my opinion is similar to the one presented by Tom in this message. For me it would be best to not calculate any checksum on default and only enable it when needed. I asked Heiko to run some actual tests on the boards where he has to maintain DFU for. For a 288 MiB image he did not measure any difference - with your patch applied, both with and without CRC enabled, we would get the same (slow) 1:54 minutes download time. As I've spoken with Heiko, am33xx uses NAND memory. I deal with eMMC. Moreover, the size of chunks are different - 1 MiB and 32 MiB. I must double check for the rationale for chunk size of 32 MiB at Trats/Trats2 boards. I suspect, that eMMC write performance depend on that. I will perform some performance tests with 1 MiB chunk size and share the result. Unfortunately the 32 MiB is fixed for our platform. since lthor uses it by default. This reinforces my speculation that you are actually addressing the wrong problem. Instead of adding new code and environment variables and making the system even more complex, we should just leave everything as is, During working on this patch I've replaced the crc32() method with the call to hash_method(), which IMHO is welcome. I also don't personally like the crc32, hence I like the choice which this patch gives me to use other algorithm (for which I've got HW support on my platform - e.g. MD5). and you should try to find out why the CRC calculation is so low for you. Checking if caches are enabled is probably among the things that should be done first. L1 is enabled. L2 has been disabled on purpose (power consumption reduction). Regarding L2 - our platform requires SMC calls to enable and manage L2 cache. In my opinion support for this in u-boot is an overkill. Can we conclude this whole discussion? The main point was if we should keep calculating and displaying crc32 as default for DFU transfers. I'm for the option to NOT display and calculate it by default (PATCH v3). I talked with the siemens board customer, they also do not check/use the displayed value from U-Boot ... So, for me it is OK to not display this value ... Applied this patch (with no default CRC32 calculation - v3) to u-boot-dfu tree. but we should add to DFU such a check ... or? bye, Heiko -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot PATCH 0/5] ARM: DRA72x: Add support for DRA72x SoC
On Thursday 15 May 2014 11:08 AM, Lokesh Vutla wrote: DRA72x devices are single core Cortex A15 devices belonging to the DRA7xx family. This series adds support for DRA72x family Socs and the data for DRA722 ES1.0 soc. Tested on: DRA722 ES1.0 Verfied MAKEALL -s omap Keerthy (1): ARM: DRA72x: volt: Update the pmic offsets Lokesh Vutla (4): ARM: DRA72x: Add Silicon ID support ARM: DRA72x: clocks: Update the hwdata ARM: DRA72x: Update EMIF data ARM: DRA7xx: ctrl: Fix efuse register addresses arch/arm/cpu/armv7/omap-common/emif-common.c |6 ++-- arch/arm/cpu/armv7/omap5/hw_data.c | 40 ++ arch/arm/cpu/armv7/omap5/hwinit.c|3 ++ arch/arm/cpu/armv7/omap5/prcm-regs.c |8 +++--- arch/arm/cpu/armv7/omap5/sdram.c | 19 +++- arch/arm/include/asm/arch-omap5/omap.h |1 + arch/arm/include/asm/omap_common.h |1 + 7 files changed, 71 insertions(+), 7 deletions(-) Tested-by: Mugunthan V N mugunthan...@ti.com Regards Mugunthan V N ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/t2080: add serdes2 protocol 0x27
Add a new serdes2 protocol 0x27.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
arch/powerpc/cpu/mpc85xx/t2080_serdes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/cpu/mpc85xx/t2080_serdes.c
b/arch/powerpc/cpu/mpc85xx/t2080_serdes.c
index 2b7c698..7138bb4 100644
--- a/arch/powerpc/cpu/mpc85xx/t2080_serdes.c
+++ b/arch/powerpc/cpu/mpc85xx/t2080_serdes.c
@@ -170,6 +170,7 @@ static const struct serdes_config serdes2_cfg_tbl[] = {
{0x29, {SRIO2, SRIO2, SRIO2, SRIO2, SRIO1, SRIO1, SRIO1, SRIO1} },
{0x2D, {SRIO2, SRIO2, SRIO2, SRIO2, SRIO1, SRIO1, SRIO1, SRIO1} },
{0x15, {PCIE1, PCIE1, PCIE1, PCIE1, PCIE2, PCIE2, SATA1, SATA2} },
+ {0x27, {PCIE1, PCIE1, PCIE1, PCIE1, NONE, NONE, SATA1, SATA2} },
{0x18, {PCIE1, PCIE1, PCIE1, PCIE1, AURORA, AURORA, SATA1, SATA2} },
{0x02, {PCIE1, PCIE1, PCIE1, PCIE1, PCIE1, PCIE1, PCIE1, PCIE1} },
{0x36, {SRIO2, SRIO2, SRIO2, SRIO2, AURORA, AURORA, SATA1, SATA2} },
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: fix some issues with reads/uploads
Hi Stephen,
From: Stephen Warren swar...@nvidia.com
DFU read support appears to rely upon dfu-read_medium() updating the
passed-by-reference len parameter to indicate the remaining size
available for reading.
dfu_read_medium_mmc() never does this, and the implementation of
dfu_read_medium_nand() will only work if called just once; it
hard-codes the value to the total size of the NAND device
irrespective of read offset.
I believe that overloading dfu-read_medium() is confusing. As such,
this patch introduces a new function dfu-get_medium_size() which can
be used to explicitly find out the medium size, and nothing else.
dfu_read() is modified to use this function to set the initial value
for dfu-r_left, rather than attempting to use the side-effects of
dfu-read_medium() for this purpose.
Due to this change, dfu_read() must initially set dfu-b_left to 0,
since no data has been read.
dfu_read_buffer_fill() must also be modified not to adjust dfu-r_left
when simply copying data from dfu-i_buf_start to the upload request
buffer. r_left represents the amount of data left to be read from HW.
That value is not affected by the memcpy(), but only by calls to
dfu-read_medium().
After this change, I can read from either a 4MB or 1.5MB chunk of a
4MB eMMC boot partion with CONFIG_SYS_DFU_DATA_BUF_SIZE==1MB. Without
this change, attempting to do that would result in DFU read returning
no data at all due to r_left never being set.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/dfu/dfu.c | 9 ++---
drivers/dfu/dfu_mmc.c | 6 ++
drivers/dfu/dfu_nand.c | 7 ++-
drivers/dfu/dfu_ram.c | 11 ++-
include/dfu.h | 2 ++
5 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index a93810934ac9..af97234390c7 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -241,7 +241,6 @@ static int dfu_read_buffer_fill(struct dfu_entity
*dfu, void *buf, int size) dfu-crc = crc32(dfu-crc, buf, chunk);
dfu-i_buf += chunk;
dfu-b_left -= chunk;
- dfu-r_left -= chunk;
size -= chunk;
buf += chunk;
readn += chunk;
@@ -287,11 +286,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) if (dfu-i_buf_start == NULL)
return -ENOMEM;
- ret = dfu-read_medium(dfu, 0, dfu-i_buf_start,
dfu-r_left);
- if (ret != 0) {
- debug(%s: failed to get r_left\n,
__func__);
- return ret;
- }
+ dfu-r_left = dfu-get_medium_size(dfu);
debug(%s: %s %ld [B]\n, __func__, dfu-name,
dfu-r_left);
@@ -300,7 +295,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) dfu-offset = 0;
dfu-i_buf_end = dfu_get_buf() + dfu_buf_size;
dfu-i_buf = dfu-i_buf_start;
- dfu-b_left = min(dfu_buf_size, dfu-r_left);
+ dfu-b_left = 0;
dfu-bad_skip = 0;
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 63cc876612c9..aa077c052f39 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -196,6 +196,11 @@ int dfu_flush_medium_mmc(struct dfu_entity *dfu)
return ret;
}
+long dfu_get_medium_size_mmc(struct dfu_entity *dfu)
Those could be defined as static
+{
+ return dfu-data.mmc.lba_size * dfu-data.mmc.lba_blk_size;
+}
+
int dfu_read_medium_mmc(struct dfu_entity *dfu, u64 offset, void
*buf, long *len)
{
@@ -316,6 +321,7 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu,
char *s) }
dfu-dev_type = DFU_DEV_MMC;
+ dfu-get_medium_size = dfu_get_medium_size_mmc;
dfu-read_medium = dfu_read_medium_mmc;
dfu-write_medium = dfu_write_medium_mmc;
dfu-flush_medium = dfu_flush_medium_mmc;
diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
index ccdbef6b75f2..e1c9a8849246 100644
--- a/drivers/dfu/dfu_nand.c
+++ b/drivers/dfu/dfu_nand.c
@@ -114,6 +114,11 @@ static int dfu_write_medium_nand(struct
dfu_entity *dfu, return ret;
}
+long dfu_get_medium_size_nand(struct dfu_entity *dfu)
Those could be defined as static
+{
+ return dfu-data.nand.size;
+}
+
static int dfu_read_medium_nand(struct dfu_entity *dfu, u64 offset,
void *buf, long *len)
{
@@ -121,7 +126,6 @@ static int dfu_read_medium_nand(struct dfu_entity
*dfu, u64 offset, void *buf,
switch (dfu-layout) {
case DFU_RAW_ADDR:
- *len = dfu-data.nand.size;
ret = nand_block_read(dfu, offset, buf, len);
break;
default:
@@ -220,6 +224,7 @@ int dfu_fill_entity_nand(struct dfu_entity *dfu,
char *s) return -1;
}
+ dfu-get_medium_size = dfu_get_medium_size_nand;
dfu-read_medium =
[U-Boot] [RFC,PATCH v2 2/4] lib, rbtree: resync with Linux-3.14
resync with linux:
commit 455c6fdbd219161bd09b1165f11699d6d73de11c
Author: Linus Torvalds torva...@linux-foundation.org
Date: Sun Mar 30 20:40:15 2014 -0700
Linux 3.14
Needed for the MTD/UBI/UBIFS resync
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Marek Vasut ma...@denx.de
Cc: Sergey Lapin sla...@ossfans.org
Cc: Scott Wood scottw...@freescale.com
---
- changes for v2:
none
include/linux/rbtree.h | 147 +++--
include/linux/rbtree_augmented.h | 220 +
lib/rbtree.c | 684 ---
3 files changed, 698 insertions(+), 353 deletions(-)
create mode 100644 include/linux/rbtree_augmented.h
diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index ad892d1..b5994e3 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -1,7 +1,7 @@
/*
Red Black Trees
(C) 1999 Andrea Arcangeli and...@suse.de
-
+
* SPDX-License-Identifier:GPL-2.0+
linux/include/linux/rbtree.h
@@ -11,138 +11,89 @@
I know it's not the cleaner way, but in C (not in C++) to get
performances and genericity...
- Some example of insert and search follows here. The search is a plain
- normal search over an ordered tree. The insert instead must be implemented
- int two steps: as first thing the code must insert the element in
- order as a red leaf in the tree, then the support library function
- rb_insert_color() must be called. Such function will do the
- not trivial work to rebalance the rbtree if necessary.
-
-static inline struct page * rb_search_page_cache(struct inode * inode,
-unsigned long offset)
-{
- struct rb_node * n = inode-i_rb_page_cache.rb_node;
- struct page * page;
-
- while (n)
- {
- page = rb_entry(n, struct page, rb_page_cache);
-
- if (offset page-offset)
- n = n-rb_left;
- else if (offset page-offset)
- n = n-rb_right;
- else
- return page;
- }
- return NULL;
-}
-
-static inline struct page * __rb_insert_page_cache(struct inode * inode,
- unsigned long offset,
- struct rb_node * node)
-{
- struct rb_node ** p = inode-i_rb_page_cache.rb_node;
- struct rb_node * parent = NULL;
- struct page * page;
-
- while (*p)
- {
- parent = *p;
- page = rb_entry(parent, struct page, rb_page_cache);
-
- if (offset page-offset)
- p = (*p)-rb_left;
- else if (offset page-offset)
- p = (*p)-rb_right;
- else
- return page;
- }
-
- rb_link_node(node, parent, p);
-
- return NULL;
-}
-
-static inline struct page * rb_insert_page_cache(struct inode * inode,
-unsigned long offset,
-struct rb_node * node)
-{
- struct page * ret;
- if ((ret = __rb_insert_page_cache(inode, offset, node)))
- goto out;
- rb_insert_color(node, inode-i_rb_page_cache);
- out:
- return ret;
-}
+ See Documentation/rbtree.txt for documentation and samples.
*/
#ifndef_LINUX_RBTREE_H
#define_LINUX_RBTREE_H
+#define __UBOOT__
+#ifndef __UBOOT__
+#include linux/kernel.h
+#endif
#include linux/stddef.h
-struct rb_node
-{
- unsigned long rb_parent_color;
-#defineRB_RED 0
-#defineRB_BLACK1
+struct rb_node {
+ unsigned long __rb_parent_color;
struct rb_node *rb_right;
struct rb_node *rb_left;
} __attribute__((aligned(sizeof(long;
/* The alignment might seem pointless, but allegedly CRIS needs it */
-struct rb_root
-{
+struct rb_root {
struct rb_node *rb_node;
};
-#define rb_parent(r) ((struct rb_node *)((r)-rb_parent_color ~3))
-#define rb_color(r) ((r)-rb_parent_color 1)
-#define rb_is_red(r) (!rb_color(r))
-#define rb_is_black(r) rb_color(r)
-#define rb_set_red(r) do { (r)-rb_parent_color = ~1; } while (0)
-#define rb_set_black(r) do { (r)-rb_parent_color |= 1; } while (0)
-
-static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)
-{
- rb-rb_parent_color = (rb-rb_parent_color 3) | (unsigned long)p;
-}
-static inline void rb_set_color(struct rb_node *rb, int color)
-{
- rb-rb_parent_color = (rb-rb_parent_color ~1) | color;
-}
+#define rb_parent(r) ((struct rb_node *)((r)-__rb_parent_color ~3))
#define RB_ROOT(struct rb_root) { NULL, }
#definerb_entry(ptr, type, member) container_of(ptr, type, member)
-#define
[U-Boot] [RFC, PATCH v2 3/4] lib, list_sort: add list_sort from linux 3.14
from linux 3.14:
commit 455c6fdbd219161bd09b1165f11699d6d73de11c
Author: Linus Torvalds torva...@linux-foundation.org
Date: Sun Mar 30 20:40:15 2014 -0700
Linux 3.14
Needed for the MTD/UBI/UBIFS resync
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Marek Vasut ma...@denx.de
Cc: Sergey Lapin sla...@ossfans.org
Cc: Scott Wood scottw...@freescale.com
---
- changes for v2:
none
include/linux/list_sort.h | 11 ++
lib/Makefile | 1 +
lib/list_sort.c | 298 ++
3 files changed, 310 insertions(+)
create mode 100644 include/linux/list_sort.h
create mode 100644 lib/list_sort.c
diff --git a/include/linux/list_sort.h b/include/linux/list_sort.h
new file mode 100644
index 000..1a2df2e
--- /dev/null
+++ b/include/linux/list_sort.h
@@ -0,0 +1,11 @@
+#ifndef _LINUX_LIST_SORT_H
+#define _LINUX_LIST_SORT_H
+
+#include linux/types.h
+
+struct list_head;
+
+void list_sort(void *priv, struct list_head *head,
+ int (*cmp)(void *priv, struct list_head *a,
+ struct list_head *b));
+#endif
diff --git a/lib/Makefile b/lib/Makefile
index 27e4f78..71b7fb8 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -40,6 +40,7 @@ obj-y += strmhz.o
obj-$(CONFIG_TPM) += tpm.o
obj-$(CONFIG_RBTREE) += rbtree.o
obj-$(CONFIG_BITREVERSE) += bitrev.o
+obj-y += list_sort.o
endif
ifdef CONFIG_SPL_BUILD
diff --git a/lib/list_sort.c b/lib/list_sort.c
new file mode 100644
index 000..81de0a1
--- /dev/null
+++ b/lib/list_sort.c
@@ -0,0 +1,298 @@
+#define __UBOOT__
+#ifndef __UBOOT__
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#else
+#include linux/compat.h
+#include common.h
+#include malloc.h
+#endif
+#include linux/list.h
+#include linux/list_sort.h
+
+#define MAX_LIST_LENGTH_BITS 20
+
+/*
+ * Returns a list organized in an intermediate format suited
+ * to chaining of merge() calls: null-terminated, no reserved or
+ * sentinel head node, prev links not maintained.
+ */
+static struct list_head *merge(void *priv,
+ int (*cmp)(void *priv, struct list_head *a,
+ struct list_head *b),
+ struct list_head *a, struct list_head *b)
+{
+ struct list_head head, *tail = head;
+
+ while (a b) {
+ /* if equal, take 'a' -- important for sort stability */
+ if ((*cmp)(priv, a, b) = 0) {
+ tail-next = a;
+ a = a-next;
+ } else {
+ tail-next = b;
+ b = b-next;
+ }
+ tail = tail-next;
+ }
+ tail-next = a?:b;
+ return head.next;
+}
+
+/*
+ * Combine final list merge with restoration of standard doubly-linked
+ * list structure. This approach duplicates code from merge(), but
+ * runs faster than the tidier alternatives of either a separate final
+ * prev-link restoration pass, or maintaining the prev links
+ * throughout.
+ */
+static void merge_and_restore_back_links(void *priv,
+ int (*cmp)(void *priv, struct list_head *a,
+ struct list_head *b),
+ struct list_head *head,
+ struct list_head *a, struct list_head *b)
+{
+ struct list_head *tail = head;
+
+ while (a b) {
+ /* if equal, take 'a' -- important for sort stability */
+ if ((*cmp)(priv, a, b) = 0) {
+ tail-next = a;
+ a-prev = tail;
+ a = a-next;
+ } else {
+ tail-next = b;
+ b-prev = tail;
+ b = b-next;
+ }
+ tail = tail-next;
+ }
+ tail-next = a ? : b;
+
+ do {
+ /*
+* In worst cases this loop may run many iterations.
+* Continue callbacks to the client even though no
+* element comparison is needed, so the client's cmp()
+* routine can invoke cond_resched() periodically.
+*/
+ (*cmp)(priv, tail-next, tail-next);
+
+ tail-next-prev = tail;
+ tail = tail-next;
+ } while (tail-next);
+
+ tail-next = head;
+ head-prev = tail;
+}
+
+/**
+ * list_sort - sort a list
+ * @priv: private data, opaque to list_sort(), passed to @cmp
+ * @head: the list to sort
+ * @cmp: the elements comparison function
+ *
+ * This function implements merge sort, which has O(nlog(n))
+ * complexity.
+ *
+ * The comparison function @cmp must return a negative value if @a
+ * should sort before @b, and a positive value if @a should sort after
+ * @b. If @a and @b are equivalent, and their original relative
+ * ordering is to be preserved, @cmp must return 0.
+ */
+void list_sort(void
[U-Boot] [RFC,PATCH v2 1/4] dm: rename device struct to udevice
using UBI and DM together leads in compiler error, as
both define a struct device, so rename struct device
in include/dm/device.h to struct udevice, as we use
linux code (MTD/UBI/UBIFS some USB code,...) and cannot
change the linux struct device
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Simon Glass s...@chromium.org
Cc: Marek Vasut ma...@denx.de
---
- changes for v2:
none
arch/sandbox/include/asm/gpio.h | 8
common/cmd_demo.c | 4 ++--
common/cmd_gpio.c | 4 ++--
doc/driver-model/README.txt | 8
drivers/core/device.c | 32
drivers/core/lists.c | 8
drivers/core/root.c | 2 +-
drivers/core/uclass.c | 31 ---
drivers/demo/demo-shape.c | 6 +++---
drivers/demo/demo-simple.c| 4 ++--
drivers/demo/demo-uclass.c| 6 +++---
drivers/gpio/gpio-uclass.c| 28 ++--
drivers/gpio/sandbox.c| 34 +-
include/asm-generic/global_data.h | 2 +-
include/asm-generic/gpio.h| 22 +++---
include/dm-demo.h | 10 +-
include/dm/device-internal.h | 16
include/dm/device.h | 20 ++--
include/dm/lists.h| 4 ++--
include/dm/root.h | 4 ++--
include/dm/test.h | 12 ++--
include/dm/uclass-internal.h | 10 +-
include/dm/uclass.h | 18 +-
test/dm/cmd_dm.c | 10 +-
test/dm/core.c| 32
test/dm/gpio.c| 2 +-
test/dm/test-driver.c | 20 ++--
test/dm/test-fdt.c| 10 +-
test/dm/test-main.c | 2 +-
test/dm/test-uclass.c | 15 ---
30 files changed, 193 insertions(+), 191 deletions(-)
diff --git a/arch/sandbox/include/asm/gpio.h b/arch/sandbox/include/asm/gpio.h
index 95b59da..8317db1 100644
--- a/arch/sandbox/include/asm/gpio.h
+++ b/arch/sandbox/include/asm/gpio.h
@@ -29,7 +29,7 @@
* @param gp GPIO number
* @return -1 on error, 0 if GPIO is low, 0 if high
*/
-int sandbox_gpio_get_value(struct device *dev, unsigned int offset);
+int sandbox_gpio_get_value(struct udevice *dev, unsigned int offset);
/**
* Set the simulated value of a GPIO (used only in sandbox test code)
@@ -38,7 +38,7 @@ int sandbox_gpio_get_value(struct device *dev, unsigned int
offset);
* @param valuevalue to set (0 for low, non-zero for high)
* @return -1 on error, 0 if ok
*/
-int sandbox_gpio_set_value(struct device *dev, unsigned int offset, int value);
+int sandbox_gpio_set_value(struct udevice *dev, unsigned int offset, int
value);
/**
* Return the simulated direction of a GPIO (used only in sandbox test code)
@@ -46,7 +46,7 @@ int sandbox_gpio_set_value(struct device *dev, unsigned int
offset, int value);
* @param gp GPIO number
* @return -1 on error, 0 if GPIO is input, 0 if output
*/
-int sandbox_gpio_get_direction(struct device *dev, unsigned int offset);
+int sandbox_gpio_get_direction(struct udevice *dev, unsigned int offset);
/**
* Set the simulated direction of a GPIO (used only in sandbox test code)
@@ -55,7 +55,7 @@ int sandbox_gpio_get_direction(struct device *dev, unsigned
int offset);
* @param output 0 to set as input, 1 to set as output
* @return -1 on error, 0 if ok
*/
-int sandbox_gpio_set_direction(struct device *dev, unsigned int offset,
+int sandbox_gpio_set_direction(struct udevice *dev, unsigned int offset,
int output);
#endif
diff --git a/common/cmd_demo.c b/common/cmd_demo.c
index a3bba7f..652c61c 100644
--- a/common/cmd_demo.c
+++ b/common/cmd_demo.c
@@ -11,7 +11,7 @@
#include dm-demo.h
#include asm/io.h
-struct device *demo_dev;
+struct udevice *demo_dev;
static int do_demo_hello(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
@@ -41,7 +41,7 @@ static int do_demo_status(cmd_tbl_t *cmdtp, int flag, int
argc,
int do_demo_list(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
- struct device *dev;
+ struct udevice *dev;
int i, ret;
puts(Demo uclass entries:\n);
diff --git a/common/cmd_gpio.c b/common/cmd_gpio.c
index aff0445..4634f91 100644
--- a/common/cmd_gpio.c
+++ b/common/cmd_gpio.c
@@ -30,7 +30,7 @@ static const char * const gpio_function[] = {
unknown,
};
-static void show_gpio(struct device *dev, const char *bank_name, int offset)
+static void show_gpio(struct udevice *dev, const char *bank_name, int offset)
{
struct dm_gpio_ops *ops = gpio_get_ops(dev);
char buf[80];
@@ -62,7 +62,7 @@ static void show_gpio(struct device *dev, const char
*bank_name, int offset)
[U-Boot] [RFC, PATCH v2 0/4] mtd, ubi, ubifs: resync with Linux-3.14
resync mtd, ubi and ubifs subsystem with linux:
commit 455c6fdbd219161bd09b1165f11699d6d73de11c
Author: Linus Torvalds torva...@linux-foundation.org
Date: Sun Mar 30 20:40:15 2014 -0700
Linux 3.14
Main reason for this sync is, we now have UBI fastmap support
in U-Boot.
Tested it on am33xx, imx6 and mpc83xx boards. MAKEALL for arm and powerpc
compiles clean.
Tested UBI fastmap on a board with 512 MiB nand flash. Attach time
from old U-Boot was 2 seconds, reduced with UBI fastmap to 0.2 seconds.
Please test this patchserie!
The patches
lib, rbtree: resync with Linux-3.14
lib, list_sort: add list_sort from linux 3.14
mtd, ubi, ubifs: resync with Linux-3.14
are not checkpatch clean, as they use code from Linux and
I do not want to change this.
Remarks:
- UBI Fastmap is now availiable in U-Boot
activate it with CONFIG_MTD_UBI_FASTMAP
- replace UBI_LINUX in current UBI code from U-Boot with
__UBOOT__ as this define is used in other places in U-Boot
where code from other projects is used.
- move a lot of defines from include/ubi_uboot.h to
include/linux/compat.h, as this is the correcter place for it.
- add usb device to linux device, so usb uses struct device
from linux/compat.h
- onenand changes only compile tested.
- Following Code in drivers/mtd/nand/nand_base.c nand_do_write_ops()
adapted for U-Boot:
+#ifndef __UBOOT__
/* Reject writes, which are not page aligned */
if (NOTALIGNED(to) || NOTALIGNED(ops-len)) {
+else
+ /* Reject writes, which are not page aligned */
+ if (NOTALIGNED(to)) {
+endif
as the original linux code leads in not working use of the env
var filesize. For example a nand write 8000 8 ${filesize}
would not work with it ...
- add CONFIG_MTD_NAND_VERIFY_WRITE from U-Boot code
(only compile tested)
- Documented the config defines in README
- kmalloc now uses memalign for allocating memory. This prevented
crashes when tested ubi/ubifs on imx6 board.
- To produce this patch I did three steps:
- copied the linux source files to U-Boot tree - commit this
- adapt license text in each file - commit this
- make the code again compile clean and working - commit this
Then squashed this three patches to this patch, to not break
bisectability. To make further sync with linux easier, the
above three patches can be found in:
http://git.denx.de/?p=u-boot/u-boot-testing.git;a=shortlog;h=refs/heads/update-mtd%2Bubi-linux-v3.14
This branch is only thought for further linux syncs! Please
do not use this branch for testing this patchseries!
- Hope I get all U-Boot specific changes ... so please, test,
test, test ...
- changes for v2:
- add lib/linux_compat.c as Joerg Krause detected
Cc: Marek Vasut ma...@denx.de
Cc: Sergey Lapin sla...@ossfans.org
Cc: Scott Wood scottw...@freescale.com
Cc: Wolfgang Denk w...@denx.de
Cc: Joerg Krause jkra...@posteo.de
Heiko Schocher (4):
dm: rename device struct to udevice
lib, rbtree: resync with Linux-3.14
lib, list_sort: add list_sort from linux 3.14
mtd, ubi, ubifs: resync with Linux-3.14
README | 61 +
arch/sandbox/include/asm/gpio.h |8 +-
board/prodrive/alpr/nand.c |4 +
board/socrates/nand.c |6 +
board/tqc/tqm8272/nand.c|4 +
common/cmd_demo.c |4 +-
common/cmd_gpio.c |4 +-
common/cmd_ubi.c| 29 +-
common/cmd_ubifs.c |2 +-
doc/driver-model/README.txt |8 +-
drivers/core/device.c | 32 +-
drivers/core/lists.c|8 +-
drivers/core/root.c |2 +-
drivers/core/uclass.c | 31 +-
drivers/demo/demo-shape.c |6 +-
drivers/demo/demo-simple.c |4 +-
drivers/demo/demo-uclass.c |6 +-
drivers/gpio/gpio-uclass.c | 28 +-
drivers/gpio/sandbox.c | 34 +-
drivers/mtd/mtdconcat.c | 230 ++-
drivers/mtd/mtdcore.c | 1112 -
drivers/mtd/mtdcore.h | 23 +
drivers/mtd/mtdpart.c | 521 +-
drivers/mtd/nand/fsl_elbc_nand.c|4 +
drivers/mtd/nand/fsl_ifc_nand.c |4 +
drivers/mtd/nand/fsl_upm.c |4 +
drivers/mtd/nand/mpc5121_nfc.c |4 +
drivers/mtd/nand/mxc_nand.c |8 +
drivers/mtd/nand/nand_base.c| 1897 +++--
drivers/mtd/nand/nand_bbt.c | 296 ++--
drivers/mtd/nand/nand_ids.c | 256 +--
drivers/mtd/nand/nand_util.c|3 +
drivers/mtd/nand/ndfc.c |4 +
drivers/mtd/onenand/onenand_base.c |1 +
drivers/mtd/onenand/onenand_bbt.c |1 -
drivers/mtd/onenand/samsung.c | 10 +-
drivers/mtd/ubi/Makefile|3 +-
drivers/mtd/ubi/attach.c| 1754
drivers/mtd/ubi/build.c | 812 ++---
Re: [U-Boot] [PATCH v2] mmc: postponed needless timer initialization
Hi Pantelis,
mmc_init() doesn't call get_timer() anymore if MMC is already
initialized.
Signed-off-by: Mateusz Zalega m.zal...@samsung.com
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
---
Detached from earlier DFU, MMC, Gadget, Goni, misc. series because
of lack of relevance to other patches.
v2:
- deleted change-id line from commit message, sorry!
---
drivers/mmc/mmc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 16051e5..c93dc24 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1310,15 +1310,18 @@ static int mmc_complete_init(struct mmc *mmc)
int mmc_init(struct mmc *mmc)
{
int err = IN_PROGRESS;
- unsigned start = get_timer(0);
+ unsigned start;
if (mmc-has_init)
return 0;
+
+ start = get_timer(0);
+
if (!mmc-init_in_progress)
err = mmc_start_init(mmc);
-
if (!err || err == IN_PROGRESS)
err = mmc_complete_init(mmc);
+
debug(%s: %d, time %lu\n, __func__, err, get_timer(start));
return err;
}
Would you find some time to review this patch?
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] test:dfu: Add test script for testing DFU regression
This commit adds test script for testing if any commit has introduced
regression to the DFU.
It uses md5 to test if sent and received file is correct.
The test detailed description is available at DESCRIPTION.TXT file.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
test/dfu/DESCRIPTION.TXT| 27 ++
test/dfu/dfu_gadget_test.sh | 86 +++
2 files changed, 113 insertions(+)
create mode 100644 test/dfu/DESCRIPTION.TXT
create mode 100755 test/dfu/dfu_gadget_test.sh
diff --git a/test/dfu/DESCRIPTION.TXT b/test/dfu/DESCRIPTION.TXT
new file mode 100644
index 000..48da06b
--- /dev/null
+++ b/test/dfu/DESCRIPTION.TXT
@@ -0,0 +1,27 @@
+DFU TEST CASE DESCRIPTION:
+
+For running test script one needs to create:
+./log and ./bkp
+
+One also need to generate with dd following files:
+
+dat_*
+
+(e.g. dat_127B.img dat_128B.img dat_129B.img dat_33M.img dat_4095B.img
+dat_4096B.img dat_4097B.img dat_63B.img dat_64B.img dat_65B.img
+dat_960.img dat_97M.img)
+
+The size is only important (so if=/dev/urandom), especially corner cases of
+DFU EP0's size of packet (64B). This is very helpful for fixing UDC driver
+regressions.
+
+Moreover on a target device the dfu_alt_info env variable should be extended
+to have dfu_test.bin fat 0 6; \ entry [1].
+One can use fat, ext4 or any other supported file system.
+
+As a prerequisite one must also create proper partition with file system on it.
+
+Example usage:
+./dfu_gadget_test.sh 11
+
+where 11 is the mumber of alt setting corresponding to entry [1].
\ No newline at end of file
diff --git a/test/dfu/dfu_gadget_test.sh b/test/dfu/dfu_gadget_test.sh
new file mode 100755
index 000..ebde2ff
--- /dev/null
+++ b/test/dfu/dfu_gadget_test.sh
@@ -0,0 +1,86 @@
+#! /bin/bash
+set -e # any command return not equal to zero
+clear
+
+DIR=./
+SUFFIX=img
+RCV_DIR=rcv/
+LOG_FILE=./log/log-`date +%d-%m-%Y_%H-%M-%S`
+
+cleanup () {
+rm -rf $RCV_DIR
+}
+
+die () {
+ printf\33[31m FAILED \33[0m \n
+ cleanup
+ exit 1
+}
+
+calculate_md5sum () {
+MD5SUM=`md5sum $1`
+MD5SUM=`echo $MD5SUM | cut -d ' ' -f1`
+echo md5sum:$MD5SUM
+}
+
+dfu_test_file () {
+printf
\33[32m=
\33[0m\n
+printf File:\33[32m %s \33[0m\n $1
+
+# dfu-util -D $1 -a $TARGET_ALT_SETTING /dev/null 21
+dfu-util -D $1 -a $TARGET_ALT_SETTING $LOG_FILE 21 || die $?
+
+echo -n TX:
+calculate_md5sum $1
+
+MD5_TX=$MD5SUM
+
+N_FILE=$DIR$RCV_DIR${1:2}_rcv
+
+# dfu-util -U $N_FILE -a $TARGET_ALT_SETTING /dev/null 21
+dfu-util -U $N_FILE -a $TARGET_ALT_SETTING $LOG_FILE 21 || die $?
+
+echo -n RX:
+calculate_md5sum $N_FILE
+MD5_RX=$MD5SUM
+
+if [ $MD5_TX == $MD5_RX ]
+ then
+ printf\33[32m --- OK \33[0m \n
+ else
+ printf\33[31m --- FAILED \33[0m \n
+ cleanup
+ exit 1
+fi
+
+#echo $N_FILE
+}
+
+printf
\33[32m=
\33[0m\n
+echo DFU EP0 transmission test program
+echo Trouble shoot - disable DBG (even the KERN_DEBUG) in the UDC driver
+echo @ - TRATS # dfu mmc 0
+mkdir -p $RCV_DIR
+touch $LOG_FILE
+
+if [ $# -eq 0 ]
+then
+ printf\33[31m Please pass alt setting number!! \33[0m \n
+ exit 0
+fi
+
+TARGET_ALT_SETTING=$1
+
+if [ -n $2 ]
+then
+ dfu_test_file $2
+else
+ for file in $DIR*.$SUFFIX
+ do
+ dfu_test_file $file
+ done
+fi
+
+cleanup
+
+exit 0
\ No newline at end of file
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ppc] qemu-ppce500 howto
Hi, Trying to run the qemu-ppce500 within qemu. I am using -bios u-boot.bin and no luck, I get live signal. I am using latest u-boot master and qemu master. Command: $ ./qemu-system-ppc -M ppce500 -nographic -bios u-boot.bin Tried to load u-boot as well, same. Are there any patches pending or any tweak that should be done? Is there any way to provide more information? I tried: $ ./qemu-system-ppc -M ppce500 -nographic -M ppce500 -m 256 -s -S $ gdb (gdb) target remote :1234 Remote debugging using :1234 warning: Can not parse XML target description; XML support was disabled at compile time 0x in ?? () (gdb) load u-boot Loading section .bootpg, size 0x2f4 lma 0xf0 Load failed How can I inject the firmware using gdb? Thanks! Alon Bar-Lev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Exynos: Make sure ps_hold gets set in the SPL
From: Doug Anderson diand...@chromium.org
Setting ps_hold ought to be one of the first things we do when we
first boot up. If we wait until the main u-boot runs we won't set it
in time and the PMIC may power us back off.
Moving ps_hold setup into the generic power_init() which
should contain code that's currently duplicated in the
board_power_init() of several boards.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/exynos/lowlevel_init.c | 6 +-
arch/arm/cpu/armv7/exynos/power.c | 14 ++
arch/arm/include/asm/arch-exynos/power.h | 8
3 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
index 11fe5b8..ed966bc 100644
--- a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
+++ b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
@@ -39,6 +39,7 @@ enum {
DO_CLOCKS = 1 1,
DO_MEM_RESET= 1 2,
DO_UART = 1 3,
+ DO_POWER= 1 4,
};
int do_lowlevel_init(void)
@@ -60,9 +61,12 @@ int do_lowlevel_init(void)
break;
default:
/* This is a normal boot (not a wake from sleep) */
- actions = DO_CLOCKS | DO_MEM_RESET;
+ actions = DO_CLOCKS | DO_MEM_RESET | DO_POWER;
}
+ if (actions DO_POWER)
+ power_init();
+
if (actions DO_CLOCKS) {
system_clock_init();
mem_ctrl_init(actions DO_MEM_RESET);
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c
index 563abd7..8999fb9 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -112,6 +112,12 @@ static void exynos5_set_ps_hold_ctrl(void)
EXYNOS_PS_HOLD_CONTROL_DATA_HIGH);
}
+/*
+ * Set ps_hold data driving value high
+ * This enables the machine to stay powered on
+ * after the initial power-on condition goes away
+ * (e.g. power button).
+ */
void set_ps_hold_ctrl(void)
{
if (cpu_is_exynos5())
@@ -196,3 +202,11 @@ void power_exit_wakeup(void)
else
exynos4_power_exit_wakeup();
}
+
+int power_init(void)
+{
+ /* Assert PS_HOLD to indicate that we're up and running */
+ set_ps_hold_ctrl();
+
+ return 0;
+}
diff --git a/arch/arm/include/asm/arch-exynos/power.h
b/arch/arm/include/asm/arch-exynos/power.h
index c9609a2..aa32d44 100644
--- a/arch/arm/include/asm/arch-exynos/power.h
+++ b/arch/arm/include/asm/arch-exynos/power.h
@@ -1726,4 +1726,12 @@ uint32_t get_reset_status(void);
/* Read the resume function and call it */
void power_exit_wakeup(void);
+
+/**
+ * SoC level power init
+ *
+ * @return Return 0 if ok, else -1
+ */
+int power_init(void);
+
#endif
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting armv8 kernel on uboot
On Thu, May 22, 2014 at 11:18:24AM +0530, Vishal Bhoj wrote: Hi, Thanks for the inputs. On 21 May 2014 21:04, Mark Rutland mark.rutl...@arm.com wrote: On Wed, May 21, 2014 at 04:28:53PM +0100, Tom Rini wrote: On Wed, May 21, 2014 at 10:40:38AM +0100, Mark Rutland wrote: On Wed, May 21, 2014 at 09:46:35AM +0100, Vishal Bhoj wrote: Hi , Hi, I have added mmc driver into the vexpress64 board file for uboot and tested it on FVP base model. I tried booting a kernel on that but it is aborting with the following message: Final value for argc=3 Loading Kernel Image ... OK kernel loaded at 0x0008, end = 0x00827024 using: FDT reserving fdt memory region: addr=8000 size=1 ## initrd_high = 0x, copy_to_ram = 1 ramdisk load start = 0x, ramdisk load end = 0x ## device tree at 90008000 ... 9000a850 (len=22609 [0x5851]) Loading Device Tree to 9fffa000, end 9850 ... OK Initial value for argc=3 Final value for argc=3 ## Transferring control to Linux (at address 8)... Starting kernel ... Synchronous Abort handler, esr 0x0200 That ESR_ELx value means Unknown/uncategorized. It would be fantastic if U-Boot would tell us what EL it's branching to the kernel at as a matter of course -- it's not really possible to debug from logs otherwise. Which EL are you loading the kernel at? So, this I suspect is one of the problems I was trying to describe to you back at ELC which turned out to be loading things at the very wrong address (0x8 rather than 0x8008). That would certainly explain it. From the lines above stating that the kernel had been loaded to 0x8 I assumed that memory had been configured there. Vishal, cay you apply: http://patchwork.ozlabs.org/patch/345746/ http://patchwork.ozlabs.org/patch/345748/ http://patchwork.ozlabs.org/patch/345749/ http://patchwork.ozlabs.org/patch/345747/ Included these patches. I need to do a v2 still to address some feedback, and then also say we require Mark's recent series to add an image size field (and other cleanups) and make use of that (and the rest of the series changes/clarifications). Can you please share the patches. I am currently booting 3.10 Linaro stable kernel which works with ARM's trusted firmware + UEFI. The same kernel with the above patches doesn't boot on u-boot. Is there any specific kernel tree you suggest I should use which is known to boot on uboot + models ? I have generated uImage with loadaddress as 0x8008 and tried booting but doesn't boot. Here are the logs: http://pastebin.com/T882rK3P What are your bootargs? Can you add in earlyprintk=pl011,0x1c09 consolelog=9 ? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cannot source LVDS from SATA on MX6DL/SOLO
On Wed, May 21, 2014 at 11:40 AM, Fabio Estevam feste...@gmail.com wrote: Hi Marek, About the following piece of code in enable_pcie_clock: int enable_pcie_clock(void) * Switch LVDS clock source to SATA (0xb), disable clock INPUT and * enable clock OUTPUT. This is important for PCI express link that * is clocked from the i.MX6. */ #define ANADIG_ANA_MISC1_LVDSCLK1_IBEN(1 12) #define ANADIG_ANA_MISC1_LVDSCLK1_OBEN(1 10) #define ANADIG_ANA_MISC1_LVDS1_CLK_SEL_MASK0x001F clrsetbits_le32(anatop_regs-ana_misc1, ANADIG_ANA_MISC1_LVDSCLK1_IBEN | ANADIG_ANA_MISC1_LVDS1_CLK_SEL_MASK, ANADIG_ANA_MISC1_LVDSCLK1_OBEN | 0xb); 0xb is not a valid value for MX6DL/SOLO as they do not have the SATA controller. Just checked with the FSL folks: 0xb is also valid for MX6DL/SOLO and this setting should be included in its reference manual. The name of the clock should be Ref_100M instead of SATA though. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build problem - ppmc7xx configuration
Dear Vasili, In message CA+gZxsOZun38nNFgTGBYFMTJ7fYM_jvdOjYe8XT2B1e-=ni...@mail.gmail.com you wrote: I'm trying to compile the v2014.04 tag using ppmc7xx configuration on Ubuntu using powerpc-none-eabi toolchain. I'm running the following: ... And receiving the following error: [...] LDS u-boot.lds LD u-boot powerpc-none-eabi-ld.bfd: /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(_lshrdi3.o): compiled normally and linked with modules compiled with -mrelocatable ^ Well, is this not a pretty self-explanatory error message? Can anyone please assist me in understanding the problem? Is something wrong with my toolchain? (I've built it myself) It appears your version of libgcc is not compatible. You can either use a known to be workign tool chain (ELDK comes to mind :-), or you can use U-Boot's own version of the libgcc libraries by adding the CONFIG_USE_PRIVATE_LIBGCC=y command line option. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I have often regretted my speech, never my silence. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting armv8 kernel on uboot
Hi, On 22 May 2014 18:09, Tom Rini tr...@ti.com wrote: On Thu, May 22, 2014 at 11:18:24AM +0530, Vishal Bhoj wrote: Hi, Thanks for the inputs. On 21 May 2014 21:04, Mark Rutland mark.rutl...@arm.com wrote: On Wed, May 21, 2014 at 04:28:53PM +0100, Tom Rini wrote: On Wed, May 21, 2014 at 10:40:38AM +0100, Mark Rutland wrote: On Wed, May 21, 2014 at 09:46:35AM +0100, Vishal Bhoj wrote: Hi , Hi, I have added mmc driver into the vexpress64 board file for uboot and tested it on FVP base model. I tried booting a kernel on that but it is aborting with the following message: Final value for argc=3 Loading Kernel Image ... OK kernel loaded at 0x0008, end = 0x00827024 using: FDT reserving fdt memory region: addr=8000 size=1 ## initrd_high = 0x, copy_to_ram = 1 ramdisk load start = 0x, ramdisk load end = 0x ## device tree at 90008000 ... 9000a850 (len=22609 [0x5851]) Loading Device Tree to 9fffa000, end 9850 ... OK Initial value for argc=3 Final value for argc=3 ## Transferring control to Linux (at address 8)... Starting kernel ... Synchronous Abort handler, esr 0x0200 That ESR_ELx value means Unknown/uncategorized. It would be fantastic if U-Boot would tell us what EL it's branching to the kernel at as a matter of course -- it's not really possible to debug from logs otherwise. Which EL are you loading the kernel at? So, this I suspect is one of the problems I was trying to describe to you back at ELC which turned out to be loading things at the very wrong address (0x8 rather than 0x8008). That would certainly explain it. From the lines above stating that the kernel had been loaded to 0x8 I assumed that memory had been configured there. Vishal, cay you apply: http://patchwork.ozlabs.org/patch/345746/ http://patchwork.ozlabs.org/patch/345748/ http://patchwork.ozlabs.org/patch/345749/ http://patchwork.ozlabs.org/patch/345747/ Included these patches. I need to do a v2 still to address some feedback, and then also say we require Mark's recent series to add an image size field (and other cleanups) and make use of that (and the rest of the series changes/clarifications). Can you please share the patches. I am currently booting 3.10 Linaro stable kernel which works with ARM's trusted firmware + UEFI. The same kernel with the above patches doesn't boot on u-boot. Is there any specific kernel tree you suggest I should use which is known to boot on uboot + models ? I have generated uImage with loadaddress as 0x8008 and tried booting but doesn't boot. Here are the logs: http://pastebin.com/T882rK3P What are your bootargs? Can you add in earlyprintk=pl011,0x1c09 consolelog=9 ? That helps. I could get some logs. Here is the logs: http://pastebin.com/eAjWDS8t I see few things going wrong: [0.00] GIC CPU mask not found - kernel will fail to boot. [ 113.978373] swapper/0[1]: undefined instruction: pc=ffc88008 [ 113.978454] Code: d402 d65f03c0 (d403) [ 113.978510] Internal error: Oops - undefined instruction: 0 [#1] SMP [ 113.978553] Modules linked in: [ 113.978610] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.39 #2 [ 113.978673] task: ffc07dc85440 ti: ffc07dc88000 task.ti: ffc07dc88000 [ 113.978749] PC is at __invoke_psci_fn_smc+0x0/0x8 [ 113.978815] LR is at psci_cpu_on+0x2c/0x54 - It looks like kernel is trying to communicate to the ARM's trusted firmware. I am not an expert, please correct me if this assumption is wrong. Is there a way to run uboot above ARM trusted firmware ? -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] doc:git-mailrc: Add entry for dfu subsystem
Entry for dfu subsystem have been added to doc/git-mailrc file Signed-off-by: Lukasz Majewski l.majew...@samsung.com --- doc/git-mailrc |2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/git-mailrc b/doc/git-mailrc index 251586e..e53c888 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -22,6 +22,7 @@ alias jaganJagannadha Sutradharudu Teki jagannadh.t...@gmail.com alias jasonjin Jason Jin jason@freescale.com alias jhersh Joe Hershberger joe.hershber...@gmail.com alias kimphill Kim Phillips kim.phill...@freescale.com +alias lukma Lukasz Majewski l.majew...@samsung.com alias macpaulMacpaul Lin macp...@andestech.com alias marex Marek Vasut ma...@denx.de alias monstr Michal Simek mon...@monstr.eu @@ -101,6 +102,7 @@ alias x86uboot, sjg, gruss # Subsystem aliases alias cfiuboot, stroese +alias dfuuboot, lukma alias kerneldoc uboot, marex alias fdtuboot, Jerry Van Baren vanba...@cideas.com alias i2cuboot, hs -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] armv8 relocation questions
On 14-05-16 06:47 AM, feng...@phytium.com.cn wrote: hi Darwin, It's a little late. I'm hoping someone can help answer these questions about armv8 relocation. The CONFIG_SYS_TEXT_BASE seems to be be usually setup to a decent amount of alignment. For the purposes of this discussion, let's say it would normally be 0x8800 and all is well. The relocation address moves to near the end of memory, to say, 0xfffa8000. So far so good. Now let's say I want to shift the image a bit so that I can add a small 32-byte header required by a previous bootloader. So I set CONFIG_SYS_TEXT_BASE to 0x8820, and the relocated address is still 0xfffa8000 and the relocated vectors should be at 0xfffa9000. The image crashes so after some debugging, I find that the code appears to be relocated fine, but some sections have symbols that are not relocated properly. The vectors try to relocate to 0xfffa8fe0 and rodata.str1.1 printf format strings are also 0x20 off. There are likely other offset sections with issues as well. The relocation offset is 0x77fa7fe0 due to the calculations in arch/arm/lib/board.c. Simplifying, they look like this: addr = CONFIG_SYS_SDRAM_BASE + gd-ram_size; /* round down to next 4 kB limit */ addr = ~(4096 - 1); debug(Top of RAM usable for U-Boot at: %08lx\n, addr); /* * reserve memory for U-Boot code, data bss * round down to next 4 kB limit */ addr -= gd-mon_len; addr = ~(4096 - 1); addr += 0x20; // hack to adjust relocaddr to aligned address... snip gd-relocaddr = addr; gd-start_addr_sp = addr_sp; gd-reloc_off = addr - _TEXT_BASE; debug(relocation Offset is: %08lx\n, gd-reloc_off); Since _TEXT_BASE is 0x8820 and addr is 0xfffa8000, the reloc_off is a number like 0x77fa7fe0. Now if I add 0x20 to 'addr' above just before the snip, relocaddr becomes 0x77fa8000 and the relocation works perfectly and no more crashes happen. So my question - is the CONFIG_SYS_TEXT_BASE alignment requirement related to to any assumptions in the linker itself about image base alignment, specifically referring to creation of the rela.dyn sections and their use for image relocation? A related question is if CONFIG_SYS_TEXT_BASE needs to be at a specific alignment. The maximum alignment in the armv8 code base is .align 11 which I believe means 0x800 or 2048. Note that an armv7 target appears to relocate properly with smaller offsets such as 0x20. Thanks. I traced the problem you described and found it is caused by 'adrp' instruction. 'adrp' instruction produces 4kb aligned address of a label. So, if CONFIG_SYS_TEXT_BASE is not 4kb aligned the address produced by 'adrp' and following 'add' instruction will be incorrect. For example, if CONFIG_SYS_TEXT_BASE = 0x20 then address of '_start' is 0x20 and address of '_end_ofs' is 0x30, where u-boot access variable '_end_ofs' gcc generate code as following: adrp x0, ... add x0, x0, 0x30 We noticed that 0x30 is added to 'x0' to produce the address of '_end_ofs'. So when CONFIG_SYS_TEXT_BASE=0x20 and relocated destination address is not 0x020 register x0 contain incorrect address of '_end_ofs'. Thank you David. I agree that the adrp will cause problems if the string sections and label used are not relocated to correct boundaries. The adrp used before the relocation works because the symbols are on aligned boundaries. I think I have a way to explain this problem better now. 1. Working generic code: CONFIG_SYS_TEXT_BASE = 0x8800 unrelocated vectors = 0x888001000 relocation address = 0xfffa8000 = 0xfffa8000 - 0x8800 relocation offset = 77fa8000 relocated vectors = 0xfffa9000 (0x800 alignment, but pushed to fffa9000 because of code after 0xfffa8800) Now in this case, the .align directive for the vectors section wants the vectors sitting at 0x800 alignment, which they are. When the symbols are relocated, the vectors are now at 0xfffa9000 which is aligned properly. 2. Failing offset case: CONFIG_SYS_TEXT_BASE = 0x8820 unrelocated vectors = 0x888001000 (respecting .align 11 directive) relocation address = 0xfffa8000 relocation offset = 77fa7fe0 = 0xfffa8000 - 0x8820 relocated vectors = 0xfffa8fe0 (BAD ALIGNMENT) Now the relocated rodata.str1.1 string tables are not aligned, which I believe breaks the adrp instruction. The strings are offset by 0x20 and the printf fails. 3. Fixed offset case: CONFIG_SYS_TEXT_BASE = 0x8820 unrelocated vectors = 0x888001000 (respecting .align 11 directive) relocation address = 0xfffa8020 relocation offset = 77fa8000 = 0xfffa8020 - 0x8820 relocated vectors = 0xfffa9000 (GOOD ALIGNMENT, respects .align 11 after relocation) So in this fixed offset case, the adrp label is
Re: [U-Boot] Booting armv8 kernel on uboot
Hi , I have added mmc driver into the vexpress64 board file for uboot and tested it on FVP base model. I tried booting a kernel on that but it is aborting with the following message: Final value for argc=3 Loading Kernel Image ... OK kernel loaded at 0x0008, end = 0x00827024 using: FDT reserving fdt memory region: addr=8000 size=1 ## initrd_high = 0x, copy_to_ram = 1 ramdisk load start = 0x, ramdisk load end = 0x ## device tree at 90008000 ... 9000a850 (len=22609 [0x5851]) Loading Device Tree to 9fffa000, end 9850 ... OK Initial value for argc=3 Final value for argc=3 ## Transferring control to Linux (at address 8)... Starting kernel ... Synchronous Abort handler, esr 0x0200 ELR: 8 LR: fff90fc8 x0 : 9fffa000 x1 : 1c09 x2 : 1c09 x3 : 0020 x4 : fff6b834 x5 : x6 : fff6bb40 x7 : ffd0 x8 : 000f x9 : 7ff8e000 x10: fffb7188 x11: x12: 6000 x13: 0004 x14: 0003 x15: fffc7c20 x16: x17: x18: fff6beb8 x19: 0008 x20: fffc7a70 x21: x22: x23: fff6d8d8 x24: x25: fffc2630 x26: x27: 80008000 x28: x29: fff6bb40 Can anyone please provide the procedure on how to boot the kernel with u-boot on armv8 models ? I always use mkimage converting kernel to uImage and booting it. It works fine. Wish this help you. David ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: zero cntvoff_el2
Currently cntvoff_el2 is initialised with an arbitrary bag of bits derived from the initial value of cnthctl_el2 on the current CPU. This is somewhat odd and problematic as some of these bits are UNKNOWN at reset and may differ across CPUs (which may cause an OS at EL1 to observe time going backwards across CPUs). This patch instead initialises cntvoff_el2 with xzr, giving the register a consistent value of zero on all CPUs. Signed-off-by: Mark Rutland mark.rutl...@arm.com Acked-by: Marc Zyngier marc.zyng...@arm.com Acked-by: Catalin Marinas catalin.mari...@arm.com Cc: Scott Wood scottw...@freescale.com Cc: David Feng feng...@phytium.com.cn Cc: Tom Rini tr...@ti.com --- arch/arm/cpu/armv8/transition.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S index e0a5946..38dea5c 100644 --- a/arch/arm/cpu/armv8/transition.S +++ b/arch/arm/cpu/armv8/transition.S @@ -43,7 +43,7 @@ ENTRY(armv8_switch_to_el1) mrs x0, cnthctl_el2 orr x0, x0, #0x3/* Enable EL1 access to timers */ msr cnthctl_el2, x0 - msr cntvoff_el2, x0 + msr cntvoff_el2, xzr mrs x0, cntkctl_el1 orr x0, x0, #0x3/* Enable EL0 access to timers */ msr cntkctl_el1, x0 -- 1.9.1 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 v2] esdhc/usdhc: Fix PIO mode bug in fsl_esdhc driver
Hi there,
On Feb 20, 2014, at 12:00 PM, Ye.Li wrote:
From: Ye.Li b37...@freescale.com
When configure the fsl_esdhc driver to PIO mode by defining
CONFIG_SYS_FSL_ESDHC_USE_PIO, the SD/MMC read and write will fail.
Two bugs in the driver to cause the issue:
1. The read buffer was invalidated after reading from DATAPORT register,
which should be only applied to DMA mode. The valid data in cache was
overwritten by physical memory.
2. The watermarks are not set in PIO mode, will cause according state not
be set.
Signed-off-by: Ye.Li b37...@freescale.com
---
Changes for V2:
-Address the comments from Stefano Babic and Albert ARIBAUD to modify the
subject
drivers/mmc/fsl_esdhc.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 7b146a3..5bd0df3 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -174,7 +174,7 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
int timeout;
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg-esdhc_base;
-#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
+
uint wml_value;
wml_value = data-blocksize/4;
@@ -184,12 +184,15 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
wml_value = WML_RD_WML_MAX_VAL;
esdhc_clrsetbits32(regs-wml, WML_RD_WML_MASK, wml_value);
+#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
esdhc_write32(regs-dsaddr, (u32)data-dest);
+#endif
} else {
+#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
flush_dcache_range((ulong)data-src,
(ulong)data-src+data-blocks
*data-blocksize);
-
+#endif
if (wml_value WML_WR_WML_MAX)
wml_value = WML_WR_WML_MAX_VAL;
if ((esdhc_read32(regs-prsstat) PRSSTAT_WPSPL) == 0) {
@@ -199,19 +202,10 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
esdhc_clrsetbits32(regs-wml, WML_WR_WML_MASK,
wml_value 16);
+#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
esdhc_write32(regs-dsaddr, (u32)data-src);
+#endif
}
-#else/* CONFIG_SYS_FSL_ESDHC_USE_PIO */
- if (!(data-flags MMC_DATA_READ)) {
- if ((esdhc_read32(regs-prsstat) PRSSTAT_WPSPL) == 0) {
- printf(\nThe SD card is locked.
- Can not write to a locked card.\n\n);
- return TIMEOUT;
- }
- esdhc_write32(regs-dsaddr, (u32)data-src);
- } else
- esdhc_write32(regs-dsaddr, (u32)data-dest);
-#endif /* CONFIG_SYS_FSL_ESDHC_USE_PIO */
esdhc_write32(regs-blkattr, data-blocks 16 | data-blocksize);
@@ -393,9 +387,10 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
if (irqstat DATA_ERR)
return COMM_ERR;
} while ((irqstat DATA_COMPLETE) != DATA_COMPLETE);
-#endif
+
if (data-flags MMC_DATA_READ)
check_and_invalidate_dcache_range(cmd, data);
+#endif
}
esdhc_write32(regs-irqstat, -1);
--
1.7.9.5
Applied, thanks
Acked-by: Pantelis Antoniou pa...@antoniou-consulting.com
___
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 V2] cmd_mmc.c: check mmc_init() during mmc dev
On 05/21/2014 07:41 PM, Jaehoon Chung wrote: On 05/22/2014 01:18 AM, Stephen Warren wrote: On 05/20/2014 11:40 PM, Jaehoon Chung wrote: Hi, Stephen. i didn't apply your patch. Which repository do you use? It's based on u-boot.git master branch. The latest u-boot-mmc.git master branch is already included in that branch, and it looks like some changes have been applied to cmd_mmc.c in u-boot/master that aren't in u-boot-mmc/master. I have pulled the latest u-boot.git, but it didn't apply this patch. If i missed something, let me know plz. Ah, I guess I hadn't noticed there's an interaction (context changes) with some other MMC-related patches that I sent: http://patchwork.ozlabs.org/patch/346771/ [U-Boot,1/4] cmd_part: fix type in part command help text http://patchwork.ozlabs.org/patch/346770/ [U-Boot,2/4] disk: support devices with HW partitions http://patchwork.ozlabs.org/patch/346768/ [U-Boot,3/4] mmc: provide a select_hwpart implementation for get_device() http://patchwork.ozlabs.org/patch/346769/ [U-Boot,4/4] cmd_mmc: use new mmc_select_hwpart() function So, you can either apply those first, or use git am -3 rather than git am, plus declare int ret; patch 4/4 above does that. Well, if you want to check, can be used if (mmc_init(mmc)). And i'm not sure whether this code is really need or not. Why not? This code is required to solve the problem described in the commit description: I will try to reproduce the problem described in the commit-msg. Because, i didn't reproduce it, so i'm not sure. But to control the return value, it's reasonable, right? Yes, I think so. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting armv8 kernel on uboot
On Thu, May 22, 2014 at 10:26:17PM +0800, feng...@phytium.com.cn wrote: Hi , I have added mmc driver into the vexpress64 board file for uboot and tested it on FVP base model. I tried booting a kernel on that but it is aborting with the following message: Final value for argc=3 Loading Kernel Image ... OK kernel loaded at 0x0008, end = 0x00827024 using: FDT reserving fdt memory region: addr=8000 size=1 ## initrd_high = 0x, copy_to_ram = 1 ramdisk load start = 0x, ramdisk load end = 0x ## device tree at 90008000 ... 9000a850 (len=22609 [0x5851]) Loading Device Tree to 9fffa000, end 9850 ... OK Initial value for argc=3 Final value for argc=3 ## Transferring control to Linux (at address 8)... Starting kernel ... Synchronous Abort handler, esr 0x0200 ELR: 8 LR: fff90fc8 x0 : 9fffa000 x1 : 1c09 x2 : 1c09 x3 : 0020 x4 : fff6b834 x5 : x6 : fff6bb40 x7 : ffd0 x8 : 000f x9 : 7ff8e000 x10: fffb7188 x11: x12: 6000 x13: 0004 x14: 0003 x15: fffc7c20 x16: x17: x18: fff6beb8 x19: 0008 x20: fffc7a70 x21: x22: x23: fff6d8d8 x24: x25: fffc2630 x26: x27: 80008000 x28: x29: fff6bb40 Can anyone please provide the procedure on how to boot the kernel with u-boot on armv8 models ? I always use mkimage converting kernel to uImage and booting it. It works fine. Wish this help you. Which version of the model are you using and which kernel tree? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: fix some issues with reads/uploads
On 05/22/2014 04:20 AM, Lukasz Majewski wrote: Hi Stephen, From: Stephen Warren swar...@nvidia.com DFU read support appears to rely upon dfu-read_medium() updating the passed-by-reference len parameter to indicate the remaining size available for reading. dfu_read_medium_mmc() never does this, and the implementation of dfu_read_medium_nand() will only work if called just once; it hard-codes the value to the total size of the NAND device irrespective of read offset. I believe that overloading dfu-read_medium() is confusing. As such, this patch introduces a new function dfu-get_medium_size() which can be used to explicitly find out the medium size, and nothing else. dfu_read() is modified to use this function to set the initial value for dfu-r_left, rather than attempting to use the side-effects of dfu-read_medium() for this purpose. Due to this change, dfu_read() must initially set dfu-b_left to 0, since no data has been read. dfu_read_buffer_fill() must also be modified not to adjust dfu-r_left when simply copying data from dfu-i_buf_start to the upload request buffer. r_left represents the amount of data left to be read from HW. That value is not affected by the memcpy(), but only by calls to dfu-read_medium(). After this change, I can read from either a 4MB or 1.5MB chunk of a 4MB eMMC boot partion with CONFIG_SYS_DFU_DATA_BUF_SIZE==1MB. Without this change, attempting to do that would result in DFU read returning no data at all due to r_left never being set. ... I've tested it with trats2. It introduces regression with my tests setup. I think that it is the highest time to share my test setup for DFU. Proper patches would be prepared ASAP. Ah, your test scripts imply you're testing using files on a filesystem, whereas I've only tested with raw MMC partitions: setenv dfu_alt_info boot0 raw 0 0x2000 mmcpart 1\;boot1 raw 0 0x2000 mmcpart 2; dfu 0 mmc 0 (I test on alt info boot1) Can you re-run your tests on a raw partition and validate they work OK for you? That would at least prove the concept of the patches. I'm not convinced tests on raw partitions would work with or without my patches. I can see why my patches made files rather than raw partitions fail; I only wrote dfu_get_medium_size_mmc() to support raw partitions, so it needs extra code to work for files. Solving the same problem for files rather than raw partitions might be painful; I guess I'll see! As an aside, mmc_file_op() doesn't seem to support files larger than the DFU buffer, size no offset information is ever passed to the fatload/fatwrite commands. Is that intentional? I'm also puzzled why the file IO code is part of dfu_mmc.c; commands like fat_load (or the internal U-Boot filesystem APIs) support more than just MMC. Wouldn't it be better to have the following separate backends to DFU: * MMC (raw IO only) * NAND (raw IO only) * RAM (raw IO only) * Filesystem (anything that fs/fat/ext* load/write can support) That way, DFU could be applied to e.g. USB mass storage, IDE, SATA, ... devices too. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting armv8 kernel on uboot
Hi, On 22 May 2014 22:06, Tom Rini tr...@ti.com wrote: On Thu, May 22, 2014 at 10:26:17PM +0800, feng...@phytium.com.cn wrote: Hi , I have added mmc driver into the vexpress64 board file for uboot and tested it on FVP base model. I tried booting a kernel on that but it is aborting with the following message: Final value for argc=3 Loading Kernel Image ... OK kernel loaded at 0x0008, end = 0x00827024 using: FDT reserving fdt memory region: addr=8000 size=1 ## initrd_high = 0x, copy_to_ram = 1 ramdisk load start = 0x, ramdisk load end = 0x ## device tree at 90008000 ... 9000a850 (len=22609 [0x5851]) Loading Device Tree to 9fffa000, end 9850 ... OK Initial value for argc=3 Final value for argc=3 ## Transferring control to Linux (at address 8)... Starting kernel ... Synchronous Abort handler, esr 0x0200 ELR: 8 LR: fff90fc8 x0 : 9fffa000 x1 : 1c09 x2 : 1c09 x3 : 0020 x4 : fff6b834 x5 : x6 : fff6bb40 x7 : ffd0 x8 : 000f x9 : 7ff8e000 x10: fffb7188 x11: x12: 6000 x13: 0004 x14: 0003 x15: fffc7c20 x16: x17: x18: fff6beb8 x19: 0008 x20: fffc7a70 x21: x22: x23: fff6d8d8 x24: x25: fffc2630 x26: x27: 80008000 x28: x29: fff6bb40 Can anyone please provide the procedure on how to boot the kernel with u-boot on armv8 models ? I always use mkimage converting kernel to uImage and booting it. It works fine. Wish this help you. Which version of the model are you using and which kernel tree? Thanks! I am using 3.10 Linaro stable kernel which is boots up on UEFI [1]. I will give a try with the mainline kernel next. This is the FVP model version: FVP_VE_AEMv8A -v Fast Models [0.8.5202 (Oct 22 2013)] Copyright 2000-2013 ARM Limited. All Rights Reserved. Top component name: FVP_Base_AEMv8A_AEMv8A [1] https://git.linaro.org/kernel/linux-linaro-stable.git/ -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/12] exynos5: support tps65090 pmic
Hi Minkyu, On 21 May 2014 15:20, Minkyu Kang mk7.k...@samsung.com wrote: On 22/05/14 03:58, Simon Glass wrote: Hi Minkyu, On 21 May 2014 00:05, Minkyu Kang mk7.k...@samsung.com wrote: On 20/05/14 20:47, Simon Glass wrote: Hi Minkyu, On 15 May 2014 00:51, Minkyu Kang mk7.k...@samsung.com wrote: On 03/04/14 08:24, Simon Glass wrote: From: Aaron Durbin adur...@chromium.org The TSP65090 is a PMIC on some exynos5 boards. The init function is called for the TPS65090 pmic. If that device is not a part of the device tree (returns -ENODEV) then continue. Otherwise return a failure. Signed-off-by: Aaron Durbin adur...@chromium.org Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Simon Glass s...@chromium.org --- Changes in v2: - Move code to exynos5-dt.c - Fix comment style - Add #ifdef around tps65090 code board/samsung/smdk5250/exynos5-dt.c | 13 + 1 file changed, 13 insertions(+) diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c index 1a64b9b..2c1cf8a 100644 --- a/board/samsung/smdk5250/exynos5-dt.c +++ b/board/samsung/smdk5250/exynos5-dt.c @@ -20,6 +20,7 @@ #include asm/arch/sromc.h #include power/pmic.h #include power/max77686_pmic.h +#include power/tps65090_pmic.h #include tmu.h DECLARE_GLOBAL_DATA_PTR; @@ -164,7 +165,19 @@ int exynos_power_init(void) #ifdef CONFIG_POWER_MAX77686 ret = max77686_init(); + if (ret) + return ret; #endif +#ifdef CONFIG_POWER_TPS65090 + /* + * The TPS65090 may not be in the device tree. If so, it is not + * an error. Then, how we can initialise the tps65090? It is initialised if a suitable node is found in the device tree. If the device tree does not have it, then the hardware is assumed to not have this chip. then I think, it's an error. Why you said, it is not an error? I may be misunderstanding your question, but I'll try to answer what I think you are asking. The device tree contains nodes for hardware in the machine that you want to initialise, and information about each one. Devices can be enabled or disabled by including or removing this information from the device tree (or marking a device disabled with a status = disabled property in the node). The tps65090 chip is not used in all exynos5-dt boards, but is used in some. For example smdk5250 does not have it, but snow does. So we use the device tree to specify the difference, including (on snow) things like the tps65090, the display bridge chip, etc. Hm, it doesn't make sense. Then it(#define CONFIG_POWER_TPS65090) should go into each config files. Not in exynos5-dt.h. Please modify it and patch 6/12 also. The way it works at present is that there is a single exynos5-dt.h file which is used by all exynos5 boards. To the extent possible we have avoided putting particular features in things like snow.h and smdk5250.h - they just include exynos5-dt.h without changes. The idea is that we can have one U-Boot binary that runs on any exynos5 device, rather than lots of different options. This makes it much easier to test changes sine we only need to build it once. If every exynos5 board has different #defines then there are more combinations to build and test. This is similar to what the kernel does with arch/arm/mach-exynos/mach-exynos5-dt.c. Using this approach the only differences between smdk5250, daisy, snow, spring, etc. are in the device tree. I'd really like to avoid changing this now. It is easy enough for people to add their own private variants of these locally if they want to, but for mainline I believe it is better to be more generic. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] fpga: Added support to load bit stream from SD/MMC
On Thu, May 15, 2014 at 10:39:26AM +0200, Michal Simek wrote: From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com Added support to load a bitstream image in chunks by reading it in chunks from SD/MMC. Command format: loadfs [dev] [address] [image size] [blocksize] interface [dev[:part]] filename Example: fpga loadfs 0 100 3dbafc 4000 mmc 0 fpga.bin Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com Acked-by: Tom Rini tr...@ti.com Go ahead and move this in via the fpga tree, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building under Cygwin - -ansi flag?
Hello Vasili, On wo, 2014-05-21 at 11:50 +0300, Vasili Galka wrote: This pattern is a result of the original decision from 2004 to prioritize the host include paths over the paths from U-Boot tree. any reference? This decision is a part of the above mentioned commit: e1a3f6b (July 2004) I don't know how much the original committer was aware of its long term implications. If the only valid reason is Fix host tools building in Cygwin environment as mentioned in the original commit, then I am all in favor of dropping it and finding a decent solution for cygwin. I see this happening again and again with different headers in the future. So here comes the question, is it really the right thing prioritize the include paths this way? Why do host paths MUST come first? I'll try reverting this locally and looking what breaks and what alternative solutions exist. I have no idea why it is the way it is, but keep in mind that e.g. stdio headers in u-boot is quite something different then stdio for the target userland. Sure. I'll keep it in mind while I'm designing a solution here. I'm afraid there is no easy way to fix it though. This is easier than it sounds. U-boot is build with -nostdinc for the binary itself. And it tries to get the compiler related includes back with isystem $(shell $(CC) -print-file-name=include. (and the printf declaration and friends are actually in common.h for the loader, which makes it even harder to do it wrong by accident). Can you check what arm-none-eabi-gcc -print-file-name=include returns on cygwin? mmm, this one might be also be a challenge for cygwin: dirname `arm-none-eabi-gcc -print-libgcc-file-name`, but you will likely get linker errors if that contains spaces / backslashes or simply fails. But perhaps even easier, can you post the problems you encounter if you remove the idirafter. Likely easier then guessing what can go wrong in a cygwin build. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/12] exynos5: support tps65090 pmic
On 14-05-22 11:27 AM, Simon Glass wrote: Hi Minkyu, On 21 May 2014 15:20, Minkyu Kang mk7.k...@samsung.com wrote: On 22/05/14 03:58, Simon Glass wrote: Hi Minkyu, On 21 May 2014 00:05, Minkyu Kang mk7.k...@samsung.com wrote: On 20/05/14 20:47, Simon Glass wrote: Hi Minkyu, On 15 May 2014 00:51, Minkyu Kang mk7.k...@samsung.com wrote: On 03/04/14 08:24, Simon Glass wrote: From: Aaron Durbin adur...@chromium.org The TSP65090 is a PMIC on some exynos5 boards. The init function is called for the TPS65090 pmic. If that device is not a part of the device tree (returns -ENODEV) then continue. Otherwise return a failure. Signed-off-by: Aaron Durbin adur...@chromium.org Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Simon Glass s...@chromium.org --- Changes in v2: - Move code to exynos5-dt.c - Fix comment style - Add #ifdef around tps65090 code board/samsung/smdk5250/exynos5-dt.c | 13 + 1 file changed, 13 insertions(+) diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c index 1a64b9b..2c1cf8a 100644 --- a/board/samsung/smdk5250/exynos5-dt.c +++ b/board/samsung/smdk5250/exynos5-dt.c @@ -20,6 +20,7 @@ #include asm/arch/sromc.h #include power/pmic.h #include power/max77686_pmic.h +#include power/tps65090_pmic.h #include tmu.h DECLARE_GLOBAL_DATA_PTR; @@ -164,7 +165,19 @@ int exynos_power_init(void) #ifdef CONFIG_POWER_MAX77686 ret = max77686_init(); + if (ret) + return ret; #endif +#ifdef CONFIG_POWER_TPS65090 + /* + * The TPS65090 may not be in the device tree. If so, it is not + * an error. Then, how we can initialise the tps65090? It is initialised if a suitable node is found in the device tree. If the device tree does not have it, then the hardware is assumed to not have this chip. then I think, it's an error. Why you said, it is not an error? I may be misunderstanding your question, but I'll try to answer what I think you are asking. The device tree contains nodes for hardware in the machine that you want to initialise, and information about each one. Devices can be enabled or disabled by including or removing this information from the device tree (or marking a device disabled with a status = disabled property in the node). The tps65090 chip is not used in all exynos5-dt boards, but is used in some. For example smdk5250 does not have it, but snow does. So we use the device tree to specify the difference, including (on snow) things like the tps65090, the display bridge chip, etc. Hm, it doesn't make sense. Then it(#define CONFIG_POWER_TPS65090) should go into each config files. Not in exynos5-dt.h. Please modify it and patch 6/12 also. The way it works at present is that there is a single exynos5-dt.h file which is used by all exynos5 boards. To the extent possible we have avoided putting particular features in things like snow.h and smdk5250.h - they just include exynos5-dt.h without changes. The idea is that we can have one U-Boot binary that runs on any exynos5 device, rather than lots of different options. This makes it much easier to test changes sine we only need to build it once. If every exynos5 board has different #defines then there are more combinations to build and test. This is similar to what the kernel does with arch/arm/mach-exynos/mach-exynos5-dt.c. Using this approach the only differences between smdk5250, daisy, snow, spring, etc. are in the device tree. I'd really like to avoid changing this now. It is easy enough for people to add their own private variants of these locally if they want to, but for mainline I believe it is better to be more generic. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Simon, Would you say that we are approaching a state where *all* exynos 5 boards will be ready? I ask because I have the Universal5420 aka sm-t520 and I could really use a bootloader for it so I am eacer to assist any way neccessary. (but i need a little direction because i am a noob) Regards David. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/12] Enable LCD display on snow
On Tue, May 20, 2014 at 06:01:31AM -0600, Simon Glass wrote: This series adds a driver for TPS65090 and plumbs it in to get the LCD working correctly on snow. The display driver is already present, but needs information about the display to be provided in the device tree. The backlight also needs to be enabled - it is controlled by a FET on the TPS65090. Note that the TPS65090 is controlled by the device tree so will only be present if the board's device tree file specifies it. At present this is only the case for snow, but other exynos5 boards will use it (e.g. pit). Note: the TPS65090 driver was sent to the list around the middle of last year but was never applied. Looks fine to me, I would expect all of this to come via the samsung tree then arm. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build problem - ppmc7xx configuration
On Thu, May 22, 2014 at 12:45:11PM +0300, Vasili Galka wrote: Hi, I'm trying to compile the v2014.04 tag using ppmc7xx configuration on Ubuntu using powerpc-none-eabi toolchain. I'm running the following: make CROSS_COMPILE=powerpc-none-eabi- O=out/ ppmc7xx_config make CROSS_COMPILE=powerpc-none-eabi- O=out/ And receiving the following error: [...] LDS u-boot.lds LD u-boot powerpc-none-eabi-ld.bfd: /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(_lshrdi3.o): compiled normally and linked with modules compiled with -mrelocatable powerpc-none-eabi-ld.bfd: failed to merge target specific data of file /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(_lshrdi3.o) powerpc-none-eabi-ld.bfd: /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(_ashldi3.o): compiled normally and linked with modules compiled with -mrelocatable powerpc-none-eabi-ld.bfd: failed to merge target specific data of file /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(_ashldi3.o) powerpc-none-eabi-ld.bfd: /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(crtresxgpr.o): compiled normally and linked with modules compiled with -mrelocatable powerpc-none-eabi-ld.bfd: failed to merge target specific data of file /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(crtresxgpr.o) make[1]: *** [u-boot] Error 1 make: *** [sub-make] Error 2 Can anyone please assist me in understanding the problem? Is something wrong with my toolchain? (I've built it myself) It's unhappy about toolchain provided libraries, so I lean yes, possible toolchain issue. How did you generate your toolchain? By hand? crosstool-ng? other? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
On Tue, May 20, 2014 at 10:57:08AM +0200, Albert ARIBAUD wrote: Hello Tom, The following changes since commit d7782d06534fe4fa47a49fa7c106de5ba85a9687: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-05-16 18:30:33 -0400) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to 05d134b084590684bcf4d832c0035952727b7cd9: Merge remote-tracking branch 'u-boot/master' (2014-05-20 10:05:42 +0200) Note: there still is a Zynq PR pending right now, but I wanted to get re-synchronized with mainline first; a further PR with Zynq and individual patches will arrive soon. Akshay Saraswat (3): Exynos5: config: Enable FIT S5P: Exynos: Add GPIO pin numbering and rename definitions S5P: Exynos: Config: Enable GPIO CMD config Albert ARIBAUD (12): arm1136: move cache code from start.S to cache.c arm: move reset_cpu from start.S into cpu.c arm: pxa: move SP check from start.S to cpuinfo.c arm: remove unused _end_vect and _vectors_end symbols arm: move exception handling out of start.S files Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' Merge branch 'u-boot-tegra/master' into 'u-boot-arm/master' Merge branch 'u-boot-ti/master' into 'u-boot-arm/master' Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' Merge remote-tracking branch 'u-boot-sh/rmobile' boards.cfg: reformat Merge remote-tracking branch 'u-boot/master' Ash Charles (1): am335x: pepper: Add Gumstix Pepper AM335x-based machine Belisko Marek (1): mtd: nand: omap_gpmc: Fix update of read_ecc in oob Christian Riesch (1): arm, davinci: Use CONFIG_SPL_PAD_TO for padding the SPL in an ais image Dmitry Lifshitz (3): ARM: OMAP5: add UART4 support ARM: OMAP5: Power: add LDO2 support for Palmas driver ARM: OMAP5: add CKO buffer control mask Egli, Samuel (7): siemens: cosmetic: remove unused and rename defines siemens: update DDR3 parameters for dxr2 siemens: add led cmd for flexible LED control siemens: change LED indication in DFU mode siemens: cosmetic: rename project_dir siemens:cosmetic, dxr2: rename dxr2 to draco siemens, draco: add new target Eric Benard (8): imx-common: add board_video_skip nitrogen6x: use common board_video_skip mx6sabresd: use common board_video_skip RiOTboard and MarSBoard: add new boards support imx-common/video: add detect_hdmi nitrogen6x: use common detect_hdmi mx6sabresd: use common detect_hdmi embest/mx6boards: use common detect_hdmi Eric Nelson (1): ARM: imx6: nitrogen6x: Enable CONFIG_SYS_GENERIC_BOARD Fabio Estevam (11): wandboard: Convert to generic board mx53loco: Convert to generic board mx6sabre_common: Convert to generic board mx53ard: Convert to generic board mx53smd: Convert to generic board mx53evk: Convert to generic board udoo: Convert to generic board hummingboard: Convert to generic board mx6slevk: Add SPI NOR flash support nitrogen6x: Fix the PAD settings for the ECSPI chipselect iomux-v3: Add support for mx6sl LVE bit Inha Song (1): samsung: misc: add env default option to lcd menu Jaehoon Chung (1): ARM: exynos: remove the unused code Khoronzhuk, Ivan (1): config: k2hk_evm: Add generic board support Marek Vasut (1): arm: mxs: Enable CONFIG_SYS_GENERIC_BOARD Mateusz Zalega (1): ARM: Samsung: s5p_goni: maintainer update Nobuhiro Iwamatsu (22): arm: rmobile: Coordinate the common part of the header file of r8a7790 and r8a7791 arm: rmobile: r8a779x: Fix L2 cache init and latency setting arm: rmobile: koelsch: Change name of structure arm: rmobile: koelsch: Remove NOR-Flash support arm: rmobile: lager: Change name of the structure arm: rmobile: lager: Remove NOR-Flash support arm: rmobile: Merge functions to get the CPU information of R8A7790 and R8A7791 arm: rmobile: Add 1 to value of the CPU revision in rmobile_get_cpu_rev_integer() arm: rmobile: Add rmobile_get_cpu_rev_fraction() for R-Car SoCs arm: rmobile: Add prototype for function to get the CPU information to rmobile.h arm: rmobile: Update print_cpuinfo function arm: rmobile: r8a7790: Add support ES2 revision arm: rmobile: r8a7791: Add support ES2 revision arm: rmobile: keolsch: Add support ES2 revision of R8A7791 arm: rmobile: lager: Update QoS initialization to version 0.955 arm: rmobile: koelsch: Update QoS initialization arm: rmobile: koelsch: Update calculation of CONFIG_SH_TMU_CLK_FREQ arm: rmobile: Add register infomation of PLL regsiter arm: rmobile: koelsch: Change to maximum CPU frequency
Re: [U-Boot] [PULL] u-boot-usb/master
On Thu, May 15, 2014 at 12:20:31AM +0200, Marek Vasut wrote:
I will have one more PR lined up later on after this is in.
The following changes since commit 173d294b94cfec10063a5be40934d6d8fb7981ce:
Merge branch 'serial' of git://www.denx.de/git/u-boot-microblaze
(2014-05-06
14:55:45 -0400)
are available in the git repository at:
git://git.denx.de/u-boot-usb.git master
for you to fetch changes up to fc25fa27e5f439705e9ca42182014e2d75d9f0ae:
dfu, nand: add medium specific polltimeout function (2014-05-08 10:38:30
+0200)
Heiko Schocher (2):
musb-new, dfu: first send request answer then call completions
dfu, nand: add medium specific polltimeout function
Rob Herring (1):
arm: beagle: enable Android fastboot support
Sebastian Siewior (2):
image: add support for Android's boot image format
usb/gadget: add the fastboot gadget
Stephen Warren (11):
usb: ci_udc: allow multiple buffer allocs per ep
usb: ums: remove ci_udc special case
usb: ums: add error handling for failed registration
ums: support block devices not MMC devices
ums: remove UMS_{NUM,START}_SECTORS + UMS_START_SECTOR
ums: remove error-checking of MMC device size
ums: remove ums_disk_init()
ums: move IO support code to common location
ums: use get_device() not find_mmc_device();
ums: move all variable declarations to the start of the block
ums: allow the user to specify the device type
README | 22 +
board/samsung/common/Makefile | 1 -
board/samsung/common/ums.c | 74 ---
common/Makefile| 3 +
common/cmd_bootm.c | 23 -
common/cmd_fastboot.c | 36 +++
common/cmd_usb_mass_storage.c | 91 +++---
common/image-android.c | 84 +
common/image.c | 20 +++-
doc/README.android-fastboot| 91 ++
doc/README.android-fastboot-protocol | 170
+
drivers/dfu/dfu_nand.c | 13 +++
drivers/usb/gadget/Makefile| 1 +
drivers/usb/gadget/ci_udc.c| 180
+++
drivers/usb/gadget/ci_udc.h| 17 +++-
drivers/usb/gadget/f_dfu.c | 10 +-
drivers/usb/gadget/f_fastboot.c| 513
+++
drivers/usb/gadget/storage_common.c| 4 -
drivers/usb/musb-new/musb_gadget_ep0.c | 8 +-
include/android_image.h| 69 ++
include/configs/omap3_beagle.h | 10 ++
include/dfu.h | 1 +
include/image.h| 13 +++
include/usb_mass_storage.h | 13 +--
24 files changed, 1289 insertions(+), 178 deletions(-)
delete mode 100644 board/samsung/common/ums.c
create mode 100644 common/cmd_fastboot.c
create mode 100644 common/image-android.c
create mode 100644 doc/README.android-fastboot
create mode 100644 doc/README.android-fastboot-protocol
create mode 100644 drivers/usb/gadget/f_fastboot.c
create mode 100644 include/android_image.h
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
Re: [U-Boot] [GIT PULL] Fpga changes - next round
On Tue, May 20, 2014 at 03:54:22PM +0200, Michal Simek wrote: Hi Tom, here is the next round of fpga patches. Please pull them to your tree. Thanks, Michal [u-boot]$ ./tools/buildman/buildman -b fpga zynq x600 omap3_mvblx mt_ventoux iocon grsim grsim_leon2 coreboot balloon3 astro_mcf5373l alpr MVSMR MVBLM7 MVBC_P GEN860T matrix_vision -sSed Summary of 8 commits for 22 boards (4 threads, 1 job per thread) 01: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx m68k: + astro_mcf5373l powerpc: + alpr iocon +/mnt/disk/fpga/.bm-work/00/arch/m68k/cpu/mcf532x/cpu_init.c: In function 'cpu_init_f': +/mnt/disk/fpga/.bm-work/00/arch/m68k/cpu/mcf532x/cpu_init.c:211:10: warning: unused variable 'wdog' [-Wunused-variable] +/mnt/disk/fpga/.bm-work/00/arch/m68k/lib/bootm.c: In function 'do_bootm_linux': +/mnt/disk/fpga/.bm-work/00/arch/m68k/lib/bootm.c:53:8: warning: unused variable 'rd_len' [-Wunused-variable] +/mnt/disk/fpga/.bm-work/00/arch/m68k/lib/bootm.c:99:12: warning: 'initrd_start' may be used uninitialized in this function [-Wuninitialized] +/mnt/disk/fpga/.bm-work/00/arch/m68k/lib/bootm.c:99:12: warning: 'initrd_end' may be used uninitialized in this function [-Wuninitialized] +/mnt/disk/fpga/.bm-work/00/arch/m68k/lib/bootm.c:99:12: warning: 'cmd_start' may be used uninitialized in this function [-Wuninitialized] +/mnt/disk/fpga/.bm-work/00/arch/m68k/lib/bootm.c:99:12: warning: 'cmd_end' may be used uninitialized in this function [-Wuninitialized] +/mnt/disk/fpga/.bm-work/00/board/astro/mcf5373l/mcf5373l.c: In function 'initdram': +/mnt/disk/fpga/.bm-work/00/board/astro/mcf5373l/mcf5373l.c:83:5: warning: pointer targets in passing argument 1 of 'get_ram_size' differ in signedness [-Wpointer-sign] +/mnt/disk/fpga/.bm-work/00/include/common.h:470:6: note: expected 'long int *' but argument is of type 'long unsigned int *' +/mnt/disk/fpga/.bm-work/00/board/astro/mcf5373l/fpga.c:168:2: warning: initialization from incompatible pointer type [enabled by default] +/mnt/disk/fpga/.bm-work/00/board/astro/mcf5373l/fpga.c:168:2: warning: (near initialization for 'altera_fns.write') [enabled by default] +/mnt/disk/fpga/.bm-work/00/board/astro/mcf5373l/fpga.c: In function 'astro5373l_altera_load': +/mnt/disk/fpga/.bm-work/00/board/astro/mcf5373l/fpga.c:196:20: warning: assignment from incompatible pointer type [enabled by default] +powerpc-unknown-linux-gnu-ld: section .bootpg [f000 - f27f] overlaps section .reloc [c600 - f02b] +powerpc-unknown-linux-gnu-ld: u-boot: section .text vma 0xfffc overlaps previous sections +powerpc-unknown-linux-gnu-ld: u-boot: section .rodata vma 0x14b8 overlaps previous sections +powerpc-unknown-linux-gnu-ld: u-boot: section .reloc vma 0xc600 overlaps previous sections +powerpc-unknown-linux-gnu-ld: u-boot: section .bootpg vma 0xf000 overlaps previous sections +powerpc-unknown-linux-gnu-ld: u-boot: section .data vma 0xf02c overlaps previous sections +powerpc-unknown-linux-gnu-ld: u-boot: section .resetvec vma 0xfffc overlaps previous sections +powerpc-unknown-linux-gnu-ld: u-boot: section `.text' can't be allocated in segment 0 +LOAD: .u_boot_list .text .rodata .reloc .bootpg .data .resetvec +powerpc-unknown-linux-gnu-ld: final link failed: Bad value +make[1]: *** [u-boot] Error 1 +make: *** [sub-make] Error 2 +powerpc-unknown-linux-gnu-ld: u-boot: section .rodata vma 0x6ed0 overlaps previous sections +LOAD: .reloc .data .u_boot_list .text .rodata .resetvec 02: configs: iocom: Fix typo on CMD_FPGA command -powerpc-unknown-linux-gnu-ld: u-boot: section .rodata vma 0x6ed0 overlaps previous sections +powerpc-unknown-linux-gnu-ld: u-boot: section .rodata vma 0x6dac overlaps previous sections 03: fpga: Guard the LOADMK functionality with CMD_FPGA_LOADMK powerpc: (for 6/8 boards) all -94.7 data -5.3 text -89.3 MERGERBOX : all -568 data -32 text -536 04: fpga: Define bitstream type based on command selection -powerpc-unknown-linux-gnu-ld: u-boot: section .rodata vma 0x14b8 overlaps previous sections +powerpc-unknown-linux-gnu-ld: u-boot: section .rodata vma 0x14c0 overlaps previous sections powerpc: (for 6/8 boards) all +21.3 text +21.3 MVSMR : all +32 text +32 GEN860T: all +32 text +32 GEN860T_SC : all +32 text +32 MVBC_P : all +16 text +16 MVBLM7 : all +16 text +16 m68k: (for 1/1 boards) all +40.0 text +40.0 astro_mcf5373l : all +40 text +40 arm: (for 10/10 boards) all +33.2 bss +0.8 text +32.4 mt_ventoux : all +68 bss +32 text +36 zynq_microzed : all +64 bss +28 text +36 zynq_zc770_xm013: all +36 text +36 zynq_zc770_xm012: all +36 text +36
Re: [U-Boot] [PULL] u-boot-usb/pr-15052014
On Thu, May 15, 2014 at 12:28:23AM +0200, Marek Vasut wrote:
This applies _after_ my previous u-boot-usb/master PR please.
The following changes since commit 2072e7262965bb48d7fffb1e283101e6ed8b21a8:
mvtwsi: Remove unnecessary twsi_baud_rate and twsi_slave_address globals
(2014-05-14 12:59:12 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-usb.git pr-15052014
for you to fetch changes up to c8151b4a5de136ea2c2a0e6e9aec481810ee0460:
dfu: mmc: Provide support for eMMC boot partition access (2014-05-15
00:24:24
+0200)
Heiko Schocher (2):
musb-new, dfu: first send request answer then call completions
dfu, nand: add medium specific polltimeout function
Lukasz Majewski (1):
dfu: mmc: Provide support for eMMC boot partition access
Marek Vasut (1):
Merge remote-tracking branch 'u-boot/master' into test
Przemyslaw Marczak (2):
drivers:dfu: dfu_flush(): add raw data flush to complete dfu write
usb:gadget:f_thor: download_tail(): remove dfu_write with 0 size
Rob Herring (1):
arm: beagle: enable Android fastboot support
Sebastian Siewior (2):
image: add support for Android's boot image format
usb/gadget: add the fastboot gadget
Stephen Warren (15):
usb: ci_udc: allow multiple buffer allocs per ep
usb: ums: remove ci_udc special case
usb: ums: add error handling for failed registration
ums: support block devices not MMC devices
ums: remove UMS_{NUM,START}_SECTORS + UMS_START_SECTOR
ums: remove error-checking of MMC device size
ums: remove ums_disk_init()
ums: move IO support code to common location
ums: use get_device() not find_mmc_device();
ums: move all variable declarations to the start of the block
ums: allow the user to specify the device type
usb: tegra: fix PHY selection code
usb: tegra: refactor PHY type selection
usb: tegra: support device mode
usb: ci_udc: parse QTD before over-writing it
README | 22 +
arch/arm/include/asm/arch-tegra/usb.h | 2 +
board/samsung/common/Makefile | 1 -
board/samsung/common/ums.c | 74 ---
common/Makefile| 3 +
common/cmd_bootm.c | 23 -
common/cmd_fastboot.c | 36 +++
common/cmd_usb_mass_storage.c | 91 +++---
common/image-android.c | 84 +
common/image.c | 20 +++-
doc/README.android-fastboot| 91 ++
doc/README.android-fastboot-protocol | 170
+
drivers/dfu/dfu.c | 4 +
drivers/dfu/dfu_mmc.c | 46 +
drivers/dfu/dfu_nand.c | 13 +++
drivers/usb/gadget/Makefile| 1 +
drivers/usb/gadget/ci_udc.c| 182
+++
drivers/usb/gadget/ci_udc.h| 17 +++-
drivers/usb/gadget/f_dfu.c | 10 +-
drivers/usb/gadget/f_fastboot.c| 513
+++
drivers/usb/gadget/f_thor.c| 12 +--
drivers/usb/gadget/storage_common.c| 4 -
drivers/usb/host/ehci-tegra.c | 165
drivers/usb/musb-new/musb_gadget_ep0.c | 8 +-
include/android_image.h| 69 ++
include/configs/omap3_beagle.h | 10 ++
include/dfu.h | 4 +
include/image.h| 13 +++
include/usb_mass_storage.h | 13 +--
29 files changed, 1454 insertions(+), 247 deletions(-)
delete mode 100644 board/samsung/common/ums.c
create mode 100644 common/cmd_fastboot.c
create mode 100644 common/image-android.c
create mode 100644 doc/README.android-fastboot
create mode 100644 doc/README.android-fastboot-protocol
create mode 100644 drivers/usb/gadget/f_fastboot.c
create mode 100644 include/android_image.h
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
Re: [U-Boot] Build problem - ppmc7xx configuration
On Thu, May 22, 2014 at 10:05 PM, Tom Rini tr...@ti.com wrote: On Thu, May 22, 2014 at 12:45:11PM +0300, Vasili Galka wrote: Hi, I'm trying to compile the v2014.04 tag using ppmc7xx configuration on Ubuntu using powerpc-none-eabi toolchain. I'm running the following: make CROSS_COMPILE=powerpc-none-eabi- O=out/ ppmc7xx_config make CROSS_COMPILE=powerpc-none-eabi- O=out/ And receiving the following error: [...] LDS u-boot.lds LD u-boot powerpc-none-eabi-ld.bfd: /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(_lshrdi3.o): compiled normally and linked with modules compiled with -mrelocatable powerpc-none-eabi-ld.bfd: failed to merge target specific data of file /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(_lshrdi3.o) powerpc-none-eabi-ld.bfd: /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(_ashldi3.o): compiled normally and linked with modules compiled with -mrelocatable powerpc-none-eabi-ld.bfd: failed to merge target specific data of file /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(_ashldi3.o) powerpc-none-eabi-ld.bfd: /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(crtresxgpr.o): compiled normally and linked with modules compiled with -mrelocatable powerpc-none-eabi-ld.bfd: failed to merge target specific data of file /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/libgcc.a(crtresxgpr.o) make[1]: *** [u-boot] Error 1 make: *** [sub-make] Error 2 Can anyone please assist me in understanding the problem? Is something wrong with my toolchain? (I've built it myself) It's unhappy about toolchain provided libraries, so I lean yes, possible toolchain issue. How did you generate your toolchain? By hand? crosstool-ng? other? -- Tom By hand. I wonder what exactly is wrong with it... arm-none-eabi toolchain generated by exactly same method works fine. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3: DNS320 support 0/4] Add a new kirkwook board
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Hi,
A rebase of an old patch set from Jamie Lentin.
Source is available here:
http://jamie.lentin.co.uk/devices/dlink-dns325/
Please apply
Changelog:
[V2] Use git option -M
[V3] Fix a mismerge in boards.cfg
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Jamie Lentin j...@lentin.co.uk
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Stefan Herbrechtsmeier ste...@code.herbrechtsmeier.net
Jamie Lentin (4):
kirkwood: Rename dns325 to dnskw
kirkwood: Add support for the D-Link DNS-320
kirkwood: Set unused SD pins back to GPIO for DNS-320 DNS-325
kirkwood: Shorten DNS-325 IDENT_STRING to match DNS-320
board/d-link/dns325/dns325.h | 32
board/d-link/{dns325 = dnskw}/Makefile| 2 +-
board/d-link/{dns325/dns325.c = dnskw/dnskw.c}| 30 +--
board/d-link/dnskw/dnskw.h | 42 +
board/d-link/dnskw/kwbimage.dns320.cfg | 207 +
.../kwbimage.cfg = dnskw/kwbimage.dns325.cfg} | 0
boards.cfg | 3 +-
include/configs/{dns325.h = dnskw.h} | 23 ++-
8 files changed, 286 insertions(+), 53 deletions(-)
delete mode 100644 board/d-link/dns325/dns325.h
rename board/d-link/{dns325 = dnskw}/Makefile (93%)
rename board/d-link/{dns325/dns325.c = dnskw/dnskw.c} (84%)
create mode 100644 board/d-link/dnskw/dnskw.h
create mode 100644 board/d-link/dnskw/kwbimage.dns320.cfg
rename board/d-link/{dns325/kwbimage.cfg = dnskw/kwbimage.dns325.cfg} (100%)
rename include/configs/{dns325.h = dnskw.h} (86%)
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3: DNS320 support 1/4] kirkwood: Rename dns325 to dnskw
From: Jamie Lentin j...@lentin.co.uk
So we can re-use DNS-325 configuration for the DNS-320 without things getting
confusing, rename all common parts from dns325 to dnskw, and use a config
option to configure DNS-325 specifics.
Signed-off-by: Jamie Lentin j...@lentin.co.uk
Cc: prafu...@marvell.com
Cc: albert.u.b...@aribaud.net
---
board/d-link/{dns325 = dnskw}/Makefile| 2 +-
board/d-link/{dns325/dns325.c = dnskw/dnskw.c}| 10 -
board/d-link/{dns325/dns325.h = dnskw/dnskw.h}| 24 +-
.../kwbimage.cfg = dnskw/kwbimage.dns325.cfg} | 0
boards.cfg | 2 +-
include/configs/{dns325.h = dnskw.h} | 11 +++---
6 files changed, 29 insertions(+), 20 deletions(-)
rename board/d-link/{dns325 = dnskw}/Makefile (93%)
rename board/d-link/{dns325/dns325.c = dnskw/dnskw.c} (93%)
rename board/d-link/{dns325/dns325.h = dnskw/dnskw.h} (52%)
rename board/d-link/{dns325/kwbimage.cfg = dnskw/kwbimage.dns325.cfg} (100%)
rename include/configs/{dns325.h = dnskw.h} (94%)
diff --git a/board/d-link/dns325/Makefile b/board/d-link/dnskw/Makefile
similarity index 93%
rename from board/d-link/dns325/Makefile
rename to board/d-link/dnskw/Makefile
index b8a5ea1..85cebf7 100644
--- a/board/d-link/dns325/Makefile
+++ b/board/d-link/dnskw/Makefile
@@ -10,4 +10,4 @@
# SPDX-License-Identifier: GPL-2.0+
#
-obj-y := dns325.o
+obj-y := dnskw.o
diff --git a/board/d-link/dns325/dns325.c b/board/d-link/dnskw/dnskw.c
similarity index 93%
rename from board/d-link/dns325/dns325.c
rename to board/d-link/dnskw/dnskw.c
index ff70e94..22b0ffb 100644
--- a/board/d-link/dns325/dns325.c
+++ b/board/d-link/dnskw/dnskw.c
@@ -17,15 +17,15 @@
#include asm/arch/kirkwood.h
#include asm/arch/mpp.h
#include asm/arch/gpio.h
-#include dns325.h
+#include dnskw.h
DECLARE_GLOBAL_DATA_PTR;
int board_early_init_f(void)
{
/* Gpio configuration */
- kw_config_gpio(DNS325_OE_VAL_LOW, DNS325_OE_VAL_HIGH,
- DNS325_OE_LOW, DNS325_OE_HIGH);
+ kw_config_gpio(DNSKW_OE_VAL_LOW, DNSKW_OE_VAL_HIGH,
+ DNSKW_OE_LOW, DNSKW_OE_HIGH);
/* Multi-Purpose Pins Functionality configuration */
static const u32 kwmpp_config[] = {
@@ -83,9 +83,9 @@ int board_early_init_f(void)
};
kirkwood_mpp_conf(kwmpp_config, NULL);
- kw_gpio_set_blink(DNS325_GPIO_LED_POWER , 1);
+ kw_gpio_set_blink(DNSKW_GPIO_LED_POWER , 1);
- kw_gpio_set_value(DNS325_GPIO_SATA0_EN , 1);
+ kw_gpio_set_value(DNSKW_GPIO_SATA0_EN , 1);
return 0;
}
diff --git a/board/d-link/dns325/dns325.h b/board/d-link/dnskw/dnskw.h
similarity index 52%
rename from board/d-link/dns325/dns325.h
rename to board/d-link/dnskw/dnskw.h
index f7b25f2..8d2e2b1 100644
--- a/board/d-link/dns325/dns325.h
+++ b/board/d-link/dnskw/dnskw.h
@@ -10,18 +10,22 @@
* SPDX-License-Identifier:GPL-2.0+
*/
-#ifndef __DNS325_H
-#define __DNS325_H
+#ifndef __DNSKW_H
+#define __DNSKW_H
/* GPIO configuration */
-#define DNS325_OE_LOW 0x
-#define DNS325_OE_HIGH 0x00039604
-#define DNS325_OE_VAL_LOW 0x3800 /* disable leds */
-#define DNS325_OE_VAL_HIGH 0x0800 /* disable leds */
+#define DNSKW_OE_LOW 0x
+#define DNSKW_OE_HIGH 0x00039604
-#define DNS325_GPIO_LED_POWER 26
-#define DNS325_GPIO_SATA0_EN 39
-#define DNS325_GPIO_SATA1_EN 40
+#define DNSKW_GPIO_LED_POWER 26
+#define DNSKW_GPIO_SATA0_EN39
+#define DNSKW_GPIO_SATA1_EN40
+
+/* DNS-325 specific configuration */
+#ifdef CONFIG_BOARD_IS_DNS325
+#define DNSKW_OE_VAL_LOW 0x3800 /* disable leds */
+#define DNSKW_OE_VAL_HIGH 0x0800 /* disable leds */
+#endif /* CONFIG_BOARD_IS_DNS325 */
/* PHY related */
#define MV88E1116_MAC_CTRL_REG 21
@@ -29,4 +33,4 @@
#define MV88E1116_RGMII_TXTM_CTRL (1 4)
#define MV88E1116_RGMII_RXTM_CTRL (1 5)
-#endif /* __DNS325_H */
+#endif /* __DNSKW_H */
diff --git a/board/d-link/dns325/kwbimage.cfg
b/board/d-link/dnskw/kwbimage.dns325.cfg
similarity index 100%
rename from board/d-link/dns325/kwbimage.cfg
rename to board/d-link/dnskw/kwbimage.dns325.cfg
diff --git a/boards.cfg b/boards.cfg
index 0497a91..2c555da 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -168,7 +168,7 @@ Active arm arm926ejs davinci omicron
calimain
Active arm arm926ejs kirkwoodbuffalo lsxl
lschlv2 lsxl:LSCHLV2
Michael Walle mich...@walle.cc
Active arm arm926ejs kirkwoodbuffalo lsxl
lsxhl lsxl:LSXHL
[U-Boot] [PATCH v3: DNS320 support 2/4] kirkwood: Add support for the D-Link DNS-320
From: Jamie Lentin j...@lentin.co.uk Extend dnskw to support the D-Link DNS-320 ShareCenter NAS also. For more information on this NAS, see:- http://jamie.lentin.co.uk/devices/dlink-dns320 http://dns323.kood.org/dns-320 http://sharecenter.dlink.com/products/DNS-320 Changes since V1: * Shorten CONFIG_IDENT_STRING [Prafulla Wadaskar] Changes since V2: * Correct a mismerge conflict Signed-off-by: Jamie Lentin j...@lentin.co.uk Cc: prafu...@marvell.com Cc: albert.u.b...@aribaud.net Cc: ste...@herbrechtsmeier.net --- board/d-link/dnskw/dnskw.c | 8 +- board/d-link/dnskw/dnskw.h | 6 + board/d-link/dnskw/kwbimage.dns320.cfg | 207 + boards.cfg | 1 + include/configs/dnskw.h| 10 ++ 5 files changed, 228 insertions(+), 4 deletions(-) create mode 100644 board/d-link/dnskw/kwbimage.dns320.cfg diff --git a/board/d-link/dnskw/dnskw.c b/board/d-link/dnskw/dnskw.c index 22b0ffb..a9fa9a2 100644 --- a/board/d-link/dnskw/dnskw.c +++ b/board/d-link/dnskw/dnskw.c @@ -42,8 +42,8 @@ int board_early_init_f(void) MPP10_UART0_TXD, MPP11_UART0_RXD, MPP12_SD_CLK, - MPP13_SD_CMD, - MPP14_SD_D0, + MPP13_UART1_TXD,/* Custom ...*/ + MPP14_UART1_RXD,/* ... controller */ MPP15_SD_D1, MPP16_SD_D2, MPP17_SD_D3, @@ -58,13 +58,13 @@ int board_early_init_f(void) MPP26_GPIO, /* power led */ MPP27_GPIO, /* sata0(right) error led */ MPP28_GPIO, /* sata1(left) error led */ - MPP29_GPIO, /* usb error led */ + MPP29_GPIO, /* usb error led (dns-325) */ MPP30_GPIO, MPP31_GPIO, MPP32_GPIO, MPP33_GPIO, MPP34_GPIO, /* power key */ - MPP35_GPIO, + MPP35_GPIO, /* usb error led (dns-320) */ MPP36_GPIO, MPP37_GPIO, MPP38_GPIO, diff --git a/board/d-link/dnskw/dnskw.h b/board/d-link/dnskw/dnskw.h index 8d2e2b1..f87f02c 100644 --- a/board/d-link/dnskw/dnskw.h +++ b/board/d-link/dnskw/dnskw.h @@ -27,6 +27,12 @@ #define DNSKW_OE_VAL_HIGH 0x0800 /* disable leds */ #endif /* CONFIG_BOARD_IS_DNS325 */ +/* DNS-320 specific configuration */ +#ifdef CONFIG_BOARD_IS_DNS320 +#define DNSKW_OE_VAL_LOW 0x3800 /* disable leds */ +#define DNSKW_OE_VAL_HIGH 0x0808 /* disable leds */ +#endif /* CONFIG_BOARD_IS_DNS320 */ + /* PHY related */ #define MV88E1116_MAC_CTRL_REG 21 #define MV88E1116_PGADR_REG22 diff --git a/board/d-link/dnskw/kwbimage.dns320.cfg b/board/d-link/dnskw/kwbimage.dns320.cfg new file mode 100644 index 000..b515bf2 --- /dev/null +++ b/board/d-link/dnskw/kwbimage.dns320.cfg @@ -0,0 +1,207 @@ +# +# Copyright (C) 2012 +# Jamie Lentin j...@lentin.co.uk +# +# Based on dns325 support: +# Copyright (C) 2011 +# Stefan Herbrechtsmeier ste...@code.herbrechtsmeier.net +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# +# Refer docs/README.kwimage for more details about how-to configure +# and create kirkwood boot image +# + +# Boot Media configurations +BOOT_FROM nand +NAND_ECC_MODE default +NAND_PAGE_SIZE 0x0800 + +# SOC registers configuration using bootrom header extension +# Maximum KWBIMAGE_MAX_CONFIG configurations allowed + +# Configure RGMII-0 interface pad voltage to 1.8V +DATA 0xFFD100e0 0x1b1b1b9b + +#Dram initalization for SINGLE x16 CL=3 @ 200MHz +DATA 0xFFD01400 0x43000618 # DDR Configuration register +# bit13-0: 0x618 DDR2 clks refresh rate +# bit23-14: 0 required +# bit24:1, enable exit self refresh mode on DDR access +# bit25:1 required +# bit29-26: 0 required +# bit31-30: 0b01 required + +DATA 0xFFD01404 0x35143000 # DDR Controller Control Low +# bit3-0: 0 required +# bit4: 0, addr/cmd in smame cycle +# bit5: 0, clk is driven during self refresh, we don't care for APX +# bit6: 0, use
[U-Boot] [PATCH v3: DNS320 support 3/4] kirkwood: Set unused SD pins back to GPIO for DNS-320 DNS-325
From: Jamie Lentin j...@lentin.co.uk Neither device makes any use of the SD reader functionalty, so as suggested by Stefan Herbrechtsmeier, set the pins to GPIO instead to make this more obvious. Label MPP10 MPP11's use whilst here. Signed-off-by: Jamie Lentin j...@lentin.co.uk Cc: prafu...@marvell.com Cc: albert.u.b...@aribaud.net Cc: ste...@herbrechtsmeier.net --- board/d-link/dnskw/dnskw.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/board/d-link/dnskw/dnskw.c b/board/d-link/dnskw/dnskw.c index a9fa9a2..90cb92e 100644 --- a/board/d-link/dnskw/dnskw.c +++ b/board/d-link/dnskw/dnskw.c @@ -39,14 +39,14 @@ int board_early_init_f(void) MPP7_GPO, MPP8_TW_SDA, MPP9_TW_SCK, - MPP10_UART0_TXD, - MPP11_UART0_RXD, - MPP12_SD_CLK, + MPP10_UART0_TXD,/* 5 pin ...*/ + MPP11_UART0_RXD,/* ... console header */ + MPP12_GPO, MPP13_UART1_TXD,/* Custom ...*/ MPP14_UART1_RXD,/* ... controller */ - MPP15_SD_D1, - MPP16_SD_D2, - MPP17_SD_D3, + MPP15_GPIO, + MPP16_GPIO, + MPP17_GPIO, MPP18_NF_IO0, MPP19_NF_IO1, MPP20_SATA1_ACTn, /* sata1(left) status led */ -- 2.0.0.rc2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3: DNS320 support 4/4] kirkwood: Shorten DNS-325 IDENT_STRING to match DNS-320
From: Jamie Lentin j...@lentin.co.uk You should already know you're using a D-link device. Signed-off-by: Jamie Lentin j...@lentin.co.uk --- include/configs/dnskw.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/dnskw.h b/include/configs/dnskw.h index e55fdc4..7058873 100644 --- a/include/configs/dnskw.h +++ b/include/configs/dnskw.h @@ -19,7 +19,7 @@ #ifdef CONFIG_BOARD_IS_DNS325 #define MACH_TYPE_DNS325 3800 #define CONFIG_MACH_TYPE MACH_TYPE_DNS325 -#define CONFIG_IDENT_STRING\nD-Link DNS-325 +#define CONFIG_IDENT_STRING\nDNS-325 #define CONFIG_SYS_KWD_CONFIG $(SRCTREE)/$(CONFIG_BOARDDIR)/kwbimage.dns325.cfg -- 2.0.0.rc2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/12] Enable LCD display on snow
+Minkyu Hi Tom, On 22 May 2014 08:37, Tom Rini tr...@ti.com wrote: On Tue, May 20, 2014 at 06:01:31AM -0600, Simon Glass wrote: This series adds a driver for TPS65090 and plumbs it in to get the LCD working correctly on snow. The display driver is already present, but needs information about the display to be provided in the device tree. The backlight also needs to be enabled - it is controlled by a FET on the TPS65090. Note that the TPS65090 is controlled by the device tree so will only be present if the board's device tree file specifies it. At present this is only the case for snow, but other exynos5 boards will use it (e.g. pit). Note: the TPS65090 driver was sent to the list around the middle of last year but was never applied. Looks fine to me, I would expect all of this to come via the samsung tree then arm. Thanks! OK understood, that will include the power and initcall tweaks also. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/12] exynos5: support tps65090 pmic
Hi David, On 22 May 2014 08:24, David Nelson djhenj...@gmail.com wrote: On 14-05-22 11:27 AM, Simon Glass wrote: Hi Minkyu, On 21 May 2014 15:20, Minkyu Kang mk7.k...@samsung.com wrote: On 22/05/14 03:58, Simon Glass wrote: Hi Minkyu, On 21 May 2014 00:05, Minkyu Kang mk7.k...@samsung.com wrote: On 20/05/14 20:47, Simon Glass wrote: Hi Minkyu, On 15 May 2014 00:51, Minkyu Kang mk7.k...@samsung.com wrote: On 03/04/14 08:24, Simon Glass wrote: From: Aaron Durbin adur...@chromium.org The TSP65090 is a PMIC on some exynos5 boards. The init function is called for the TPS65090 pmic. If that device is not a part of the device tree (returns -ENODEV) then continue. Otherwise return a failure. Signed-off-by: Aaron Durbin adur...@chromium.org Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Simon Glass s...@chromium.org --- Changes in v2: - Move code to exynos5-dt.c - Fix comment style - Add #ifdef around tps65090 code board/samsung/smdk5250/exynos5-dt.c | 13 + 1 file changed, 13 insertions(+) diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c index 1a64b9b..2c1cf8a 100644 --- a/board/samsung/smdk5250/exynos5-dt.c +++ b/board/samsung/smdk5250/exynos5-dt.c @@ -20,6 +20,7 @@ #include asm/arch/sromc.h #include power/pmic.h #include power/max77686_pmic.h +#include power/tps65090_pmic.h #include tmu.h DECLARE_GLOBAL_DATA_PTR; @@ -164,7 +165,19 @@ int exynos_power_init(void) #ifdef CONFIG_POWER_MAX77686 ret = max77686_init(); + if (ret) + return ret; #endif +#ifdef CONFIG_POWER_TPS65090 + /* + * The TPS65090 may not be in the device tree. If so, it is not + * an error. Then, how we can initialise the tps65090? It is initialised if a suitable node is found in the device tree. If the device tree does not have it, then the hardware is assumed to not have this chip. then I think, it's an error. Why you said, it is not an error? I may be misunderstanding your question, but I'll try to answer what I think you are asking. The device tree contains nodes for hardware in the machine that you want to initialise, and information about each one. Devices can be enabled or disabled by including or removing this information from the device tree (or marking a device disabled with a status = disabled property in the node). The tps65090 chip is not used in all exynos5-dt boards, but is used in some. For example smdk5250 does not have it, but snow does. So we use the device tree to specify the difference, including (on snow) things like the tps65090, the display bridge chip, etc. Hm, it doesn't make sense. Then it(#define CONFIG_POWER_TPS65090) should go into each config files. Not in exynos5-dt.h. Please modify it and patch 6/12 also. The way it works at present is that there is a single exynos5-dt.h file which is used by all exynos5 boards. To the extent possible we have avoided putting particular features in things like snow.h and smdk5250.h - they just include exynos5-dt.h without changes. The idea is that we can have one U-Boot binary that runs on any exynos5 device, rather than lots of different options. This makes it much easier to test changes sine we only need to build it once. If every exynos5 board has different #defines then there are more combinations to build and test. This is similar to what the kernel does with arch/arm/mach-exynos/mach-exynos5-dt.c. Using this approach the only differences between smdk5250, daisy, snow, spring, etc. are in the device tree. I'd really like to avoid changing this now. It is easy enough for people to add their own private variants of these locally if they want to, but for mainline I believe it is better to be more generic. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Simon, Would you say that we are approaching a state where *all* exynos 5 boards will be ready? I ask because I have the Universal5420 aka sm-t520 and I could really use a bootloader for it so I am eacer to assist any way neccessary. (but i need a little direction because i am a noob) I'm not familiar with that board. It doesn't seem to be in mainline / have a device tree file in U-Boot or Linux. You may be able to get it to boot just by trying one of the existing configs. If you need to change a device tree file, you could send a patch. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH v2 1/4] dm: rename device struct to udevice
+Tom Hi Heiko, On 22 May 2014 00:43, Heiko Schocher h...@denx.de wrote: using UBI and DM together leads in compiler error, as both define a struct device, so rename struct device in include/dm/device.h to struct udevice, as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux struct device Signed-off-by: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org Cc: Marek Vasut ma...@denx.de I'm not 100% comfortable with this but if we really want to avoid changing kernel code that moves into U-Boot it is either this or a '#define device ldevice' at the top of the linux code/in a header. I'm not sure which is preferable. If Tom decides to apply this, I'd like to request that it be done soon, since it has wide impact on driver model code. Acked-by: Simon Glass s...@chromium.org Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH v2 1/4] dm: rename device struct to udevice
Yeah, I was just bitten by this problem as well... FWIW, you might also... Acked-by: Jon Loeliger jon.loeli...@oracle.com Thanks, jdl On Thu, May 22, 2014 at 3:34 PM, Simon Glass s...@chromium.org wrote: +Tom Hi Heiko, On 22 May 2014 00:43, Heiko Schocher h...@denx.de wrote: using UBI and DM together leads in compiler error, as both define a struct device, so rename struct device in include/dm/device.h to struct udevice, as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux struct device Signed-off-by: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org Cc: Marek Vasut ma...@denx.de I'm not 100% comfortable with this but if we really want to avoid changing kernel code that moves into U-Boot it is either this or a '#define device ldevice' at the top of the linux code/in a header. I'm not sure which is preferable. If Tom decides to apply this, I'd like to request that it be done soon, since it has wide impact on driver model code. Acked-by: Simon Glass s...@chromium.org Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc85xx: Add workaround for DDR erratum A004508
When the DDR controller is initialized below a junction temperature of 0°C and then operated above a junction temperature of 65°C, the DDR controller may cause receive data errors, resulting ECC errors and/or corrupted data. This erratum applies to the following SoCs and their variants: MPC8536, MPC8569, MPC8572, P1010, P1020, P1021, P1022, P1023, P2020. Signed-off-by: York Sun york...@freescale.com --- arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 +++ arch/powerpc/include/asm/config_mpc85xx.h | 18 ++ drivers/ddr/fsl/ctrl_regs.c |9 + 3 files changed, 30 insertions(+) diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c b/arch/powerpc/cpu/mpc85xx/cmd_errata.c index 3d37a76..f69c834 100644 --- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c +++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c @@ -231,6 +231,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if ((SVR_MAJ(svr) == 1) || IS_SVR_REV(svr, 2, 0)) puts(Work-around for Erratum NMG ETSEC129 enabled\n); #endif +#ifdef CONFIG_SYS_FSL_ERRATUM_A004508 + puts(Work-around for Erratum A004508 enabled\n); +#endif #ifdef CONFIG_SYS_FSL_ERRATUM_A004510 puts(Work-around for Erratum A004510 enabled\n); #endif diff --git a/arch/powerpc/include/asm/config_mpc85xx.h b/arch/powerpc/include/asm/config_mpc85xx.h index 34fc8fb..c9fd2a5 100644 --- a/arch/powerpc/include/asm/config_mpc85xx.h +++ b/arch/powerpc/include/asm/config_mpc85xx.h @@ -38,6 +38,7 @@ #define CONFIG_SYS_PPC_E500_DEBUG_TLB 1 #define CONFIG_SYS_FSL_SEC_COMPAT 2 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70 +#define CONFIG_SYS_FSL_ERRATUM_A004508 #define CONFIG_SYS_FSL_ERRATUM_A005125 #elif defined(CONFIG_MPC8540) @@ -122,6 +123,7 @@ #define CONFIG_SYS_FSL_SRIO_IB_WIN_NUM 5 #define CONFIG_SYS_FSL_RMU #define CONFIG_SYS_FSL_SRIO_MSG_UNIT_NUM 2 +#define CONFIG_SYS_FSL_ERRATUM_A004508 #define CONFIG_SYS_FSL_ERRATUM_A005125 #elif defined(CONFIG_MPC8572) @@ -132,6 +134,7 @@ #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70 #define CONFIG_SYS_FSL_ERRATUM_DDR_115 #define CONFIG_SYS_FSL_ERRATUM_DDR111_DDR134 +#define CONFIG_SYS_FSL_ERRATUM_A004508 #define CONFIG_SYS_FSL_ERRATUM_A005125 #elif defined(CONFIG_P1010) @@ -154,6 +157,7 @@ #define CONFIG_SYS_FSL_ERRATUM_IFC_A003399 #define CONFIG_SYS_FSL_ERRATUM_A005125 #define CONFIG_SYS_FSL_ERRATUM_I2C_A004447 +#define CONFIG_SYS_FSL_ERRATUM_A004508 #define CONFIG_SYS_FSL_ERRATUM_A007075 #define CONFIG_SYS_FSL_ERRATUM_A006261 #define CONFIG_SYS_FSL_A004447_SVR_REV 0x10 @@ -171,6 +175,7 @@ #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70 #define CONFIG_SYS_FSL_ERRATUM_ELBC_A001 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111 +#define CONFIG_SYS_FSL_ERRATUM_A004508 #define CONFIG_SYS_FSL_ERRATUM_A005125 /* P1012 is single core version of P1021 */ @@ -188,6 +193,7 @@ #define QE_MURAM_SIZE 0x6000UL #define MAX_QE_RISC1 #define QE_NUM_OF_SNUM 28 +#define CONFIG_SYS_FSL_ERRATUM_A004508 #define CONFIG_SYS_FSL_ERRATUM_A005125 /* P1013 is single core version of P1022 */ @@ -202,6 +208,7 @@ #define CONFIG_SYS_FSL_ERRATUM_ELBC_A001 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111 #define CONFIG_FSL_SATA_ERRATUM_A001 +#define CONFIG_SYS_FSL_ERRATUM_A004508 #define CONFIG_SYS_FSL_ERRATUM_A005125 #elif defined(CONFIG_P1014) @@ -219,6 +226,7 @@ #define CONFIG_SYS_FSL_ERRATUM_IFC_A002769 #define CONFIG_SYS_FSL_ERRATUM_P1010_A003549 #define CONFIG_SYS_FSL_ERRATUM_IFC_A003399 +#define CONFIG_SYS_FSL_ERRATUM_A004508 /* P1017 is single core version of P1023 */ #elif defined(CONFIG_P1017) @@ -234,6 +242,7 @@ #define CONFIG_SYS_FM_MURAM_SIZE 0x1 #define CONFIG_SYS_FSL_PCIE_COMPAT fsl,qoriq-pcie-v2.2 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff60 +#define CONFIG_SYS_FSL_ERRATUM_A004508 #define CONFIG_SYS_FSL_ERRATUM_A005125 #elif defined(CONFIG_P1020) @@ -246,6 +255,7 @@ #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70 #define CONFIG_SYS_FSL_ERRATUM_ELBC_A001 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111 +#define CONFIG_SYS_FSL_ERRATUM_A004508 #define CONFIG_SYS_FSL_ERRATUM_A005125 #ifndef CONFIG_USB_MAX_CONTROLLER_COUNT #define CONFIG_USB_MAX_CONTROLLER_COUNT2 @@ -264,6 +274,7 @@ #define QE_MURAM_SIZE 0x6000UL #define MAX_QE_RISC1 #define QE_NUM_OF_SNUM 28 +#define CONFIG_SYS_FSL_ERRATUM_A004508 #define CONFIG_SYS_FSL_ERRATUM_A005125 #define CONFIG_USB_MAX_CONTROLLER_COUNT1 @@ -278,6 +289,7 @@ #define CONFIG_SYS_FSL_ERRATUM_ELBC_A001 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111 #define CONFIG_FSL_SATA_ERRATUM_A001 +#define CONFIG_SYS_FSL_ERRATUM_A004508 #define CONFIG_SYS_FSL_ERRATUM_A005125 #elif defined(CONFIG_P1023) @@ -293,6 +305,7 @@ #define CONFIG_SYS_FM_MURAM_SIZE 0x1 #define CONFIG_SYS_FSL_PCIE_COMPAT fsl,qoriq-pcie-v2.2 #define
Re: [U-Boot] [PATCH v3 00/11] mx6: SPL NAND support
On Wed, May 21, 2014 at 11:34 PM, Stefano Babic sba...@denx.de wrote: Hi Tim, On 22/05/2014 08:14, Tim Harvey wrote: Stefano, Any comments on this series? I realize you've applied the first one and I'll remove that from any subsequent posts. Right. I think we have a very good point (nice work !) and we are near to merge the patchset. If I am not wrong, you want to post an update for the MMDC config patch, do you ? Yes, I do have an update for that particular patch, but I don't think anyone has commented on that patch either way. I'll go ahead and respond to that thread with my update as that is the only non-submitted change I have. Thanks, Tim Patch 2 should be acked by Scott because it belongs to his area of competence. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 07/11] mx6: add mmdc configuration for MX6Q/MX6DL
- add function for configuring iomux based on board-specific regs
- add function for configuring mmdc based on board-specific and
chip-specific data
Signed-off-by: Tim Harvey thar...@gateworks.com
---
v4:
- added delay following configure to allow ZQ calibration to complete
- update MMDC configuration to match Freescale RM
v3:
- added ifdef's around cpu specific iocfg functions for code-reduction with
single-variant board configs
- moved portions from previous patch here
- added check for IMX6D
v2:
- split out mmdc and iomux structs into separate patch
---
arch/arm/cpu/armv7/mx6/Makefile | 1 +
arch/arm/cpu/armv7/mx6/ddr.c| 490
arch/arm/include/asm/arch-mx6/mx6-ddr.h | 72 +
3 files changed, 563 insertions(+)
create mode 100644 arch/arm/cpu/armv7/mx6/ddr.c
diff --git a/arch/arm/cpu/armv7/mx6/Makefile b/arch/arm/cpu/armv7/mx6/Makefile
index d7285fc..6dc9f8e 100644
--- a/arch/arm/cpu/armv7/mx6/Makefile
+++ b/arch/arm/cpu/armv7/mx6/Makefile
@@ -8,4 +8,5 @@
#
obj-y := soc.o clock.o
+obj-$(CONFIG_SPL_BUILD) += ddr.o
obj-$(CONFIG_SECURE_BOOT)+= hab.o
diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
new file mode 100644
index 000..0434211
--- /dev/null
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -0,0 +1,490 @@
+/*
+ * Copyright (C) 2014 Gateworks Corporation
+ * Author: Tim Harvey thar...@gateworks.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include linux/types.h
+#include asm/arch/mx6-ddr.h
+#include asm/arch/sys_proto.h
+#include asm/io.h
+#include asm/types.h
+
+#if defined(CONFIG_MX6QDL) || defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
+/* Configure MX6DQ mmdc iomux */
+void mx6dq_dram_iocfg(unsigned width,
+ const struct mx6dq_iomux_ddr_regs *ddr,
+ const struct mx6dq_iomux_grp_regs *grp)
+{
+ volatile struct mx6dq_iomux_ddr_regs *mx6_ddr_iomux;
+ volatile struct mx6dq_iomux_grp_regs *mx6_grp_iomux;
+
+ mx6_ddr_iomux = (struct mx6dq_iomux_ddr_regs *)MX6DQ_IOM_DDR_BASE;
+ mx6_grp_iomux = (struct mx6dq_iomux_grp_regs *)MX6DQ_IOM_GRP_BASE;
+
+ /* DDR IO Type */
+ mx6_grp_iomux-grp_ddr_type = grp-grp_ddr_type;
+ mx6_grp_iomux-grp_ddrpke = grp-grp_ddrpke;
+
+ /* Clock */
+ mx6_ddr_iomux-dram_sdclk_0 = ddr-dram_sdclk_0;
+ mx6_ddr_iomux-dram_sdclk_1 = ddr-dram_sdclk_1;
+
+ /* Address */
+ mx6_ddr_iomux-dram_cas = ddr-dram_cas;
+ mx6_ddr_iomux-dram_ras = ddr-dram_ras;
+ mx6_grp_iomux-grp_addds = grp-grp_addds;
+
+ /* Control */
+ mx6_ddr_iomux-dram_reset = ddr-dram_reset;
+ mx6_ddr_iomux-dram_sdcke0 = ddr-dram_sdcke0;
+ mx6_ddr_iomux-dram_sdcke1 = ddr-dram_sdcke1;
+ mx6_ddr_iomux-dram_sdba2 = ddr-dram_sdba2;
+ mx6_ddr_iomux-dram_sdodt0 = ddr-dram_sdodt0;
+ mx6_ddr_iomux-dram_sdodt1 = ddr-dram_sdodt1;
+ mx6_grp_iomux-grp_ctlds = grp-grp_ctlds;
+
+ /* Data Strobes */
+ mx6_grp_iomux-grp_ddrmode_ctl = grp-grp_ddrmode_ctl;
+ mx6_ddr_iomux-dram_sdqs0 = ddr-dram_sdqs0;
+ mx6_ddr_iomux-dram_sdqs1 = ddr-dram_sdqs1;
+ if (width = 32) {
+ mx6_ddr_iomux-dram_sdqs2 = ddr-dram_sdqs2;
+ mx6_ddr_iomux-dram_sdqs3 = ddr-dram_sdqs3;
+ }
+ if (width = 64) {
+ mx6_ddr_iomux-dram_sdqs4 = ddr-dram_sdqs4;
+ mx6_ddr_iomux-dram_sdqs5 = ddr-dram_sdqs5;
+ mx6_ddr_iomux-dram_sdqs6 = ddr-dram_sdqs6;
+ mx6_ddr_iomux-dram_sdqs7 = ddr-dram_sdqs7;
+ }
+
+ /* Data */
+ mx6_grp_iomux-grp_ddrmode = grp-grp_ddrmode;
+ mx6_grp_iomux-grp_b0ds = grp-grp_b0ds;
+ mx6_grp_iomux-grp_b1ds = grp-grp_b1ds;
+ if (width = 32) {
+ mx6_grp_iomux-grp_b2ds = grp-grp_b2ds;
+ mx6_grp_iomux-grp_b3ds = grp-grp_b3ds;
+ }
+ if (width = 64) {
+ mx6_grp_iomux-grp_b4ds = grp-grp_b4ds;
+ mx6_grp_iomux-grp_b5ds = grp-grp_b5ds;
+ mx6_grp_iomux-grp_b6ds = grp-grp_b6ds;
+ mx6_grp_iomux-grp_b7ds = grp-grp_b7ds;
+ }
+ mx6_ddr_iomux-dram_dqm0 = ddr-dram_dqm0;
+ mx6_ddr_iomux-dram_dqm1 = ddr-dram_dqm1;
+ if (width = 32) {
+ mx6_ddr_iomux-dram_dqm2 = ddr-dram_dqm2;
+ mx6_ddr_iomux-dram_dqm3 = ddr-dram_dqm3;
+ }
+ if (width = 64) {
+ mx6_ddr_iomux-dram_dqm4 = ddr-dram_dqm4;
+ mx6_ddr_iomux-dram_dqm5 = ddr-dram_dqm5;
+ mx6_ddr_iomux-dram_dqm6 = ddr-dram_dqm6;
+ mx6_ddr_iomux-dram_dqm7 = ddr-dram_dqm7;
+ }
+}
+#endif
+
+#if defined(CONFIG_MX6QDL) || defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
+/* Configure MX6SDL mmdc iomux */
+void mx6sdl_dram_iocfg(unsigned width,
+ const struct mx6sdl_iomux_ddr_regs *ddr,
+ const struct mx6sdl_iomux_grp_regs *grp)
+{
+
Re: [U-Boot] [PATCH 1/4] cmd_part: fix type in part command help text
On 05/14/2014 03:29 PM, Pantelis Antoniou wrote: Hi Tom, Sorry about that; It's all on my pile of work to do when I get back home. Did these get applied somewhere? On May 14, 2014, at 2:17 PM, Tom Rini wrote: On Wed, May 14, 2014 at 11:30:35AM -0600, Stephen Warren wrote: On 05/07/2014 12:19 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com All the sub-commands start with the main command anme, but it was missing from one of the help texts. Tom, it looks like I forgot to CC you on these patches. I assume they'll go into the main U-Boot tree. Do you need me to resend them? If not, do they look OK? Acked-by: Tom Rini tr...@ti.com I had tossed the series to Pantelis in patchwork since it's mostly MMC related. -- Tom Regards -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] ARM: DRA72x: Add CPSW Ethernet support for DRA72x SoC
On Thu, May 22, 2014 at 02:37:09PM +0530, Mugunthan V N wrote: CPSW Ethernet second port is pinned out as default Ethernet, so adding support for CPSW ethernet for downloading images via Ethernet. Mugunthan V N (3): drivers: net: cpsw: add support for using second port as ethernet ARM: DRA7xx: Add cpsw second port pinmux ARM: dra7_evm: Add Ethernet support for dra72x platform Can we please update the driver to support both interfaces (cpsw for compat, cpsw1 for the second interface) and then we would just at runtime see if ethact was not set and if so, set it to cpsw1 on the dra72x evm? This would also make using boards which do have both ports a little less surprising as we do set both ethaddrs (so that we update the device tree and pass them along) but can only use one interface. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH v2 1/4] dm: rename device struct to udevice
On Thu, May 22, 2014 at 10:34:33AM -1000, Simon Glass wrote: +Tom Hi Heiko, On 22 May 2014 00:43, Heiko Schocher h...@denx.de wrote: using UBI and DM together leads in compiler error, as both define a struct device, so rename struct device in include/dm/device.h to struct udevice, as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux struct device Signed-off-by: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org Cc: Marek Vasut ma...@denx.de I'm not 100% comfortable with this but if we really want to avoid changing kernel code that moves into U-Boot it is either this or a '#define device ldevice' at the top of the linux code/in a header. I'm not sure which is preferable. If Tom decides to apply this, I'd like to request that it be done soon, since it has wide impact on driver model code. Acked-by: Simon Glass s...@chromium.org I like it, I'm going to grab it Monday and I'm going to kick out -rc2 on Monday as well, which should be a semi-handy branching off point too then. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH v2 1/4] dm: rename device struct to udevice
Hi Tom, On 22 May 2014 14:43, Tom Rini tr...@ti.com wrote: On Thu, May 22, 2014 at 10:34:33AM -1000, Simon Glass wrote: +Tom Hi Heiko, On 22 May 2014 00:43, Heiko Schocher h...@denx.de wrote: using UBI and DM together leads in compiler error, as both define a struct device, so rename struct device in include/dm/device.h to struct udevice, as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux struct device Signed-off-by: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org Cc: Marek Vasut ma...@denx.de I'm not 100% comfortable with this but if we really want to avoid changing kernel code that moves into U-Boot it is either this or a '#define device ldevice' at the top of the linux code/in a header. I'm not sure which is preferable. If Tom decides to apply this, I'd like to request that it be done soon, since it has wide impact on driver model code. Acked-by: Simon Glass s...@chromium.org I like it, I'm going to grab it Monday and I'm going to kick out -rc2 on Monday as well, which should be a semi-handy branching off point too then. Thanks, that sounds good. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv5 09/14] mmc: support the DDR mode for eMMC
On 05/21/2014 08:52 PM, Hector Palacios wrote: On 05/21/2014 04:20 AM, Jaehoon Chung wrote: Hi, Hector. On 05/21/2014 01:37 AM, Hector Palacios wrote: Hi, On 05/16/2014 06:59 AM, Jaehoon Chung wrote: Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Tested-by: Lukasz Majewski l.majew...@samsung.com Acked-by: Lukasz Majewski l.majew...@samsung.com What platforms did you test DDR mode on? I have tested DDR mode with exynos board. I tried this on an Freescale i.MX6 based platform but the driver returned error code COM_ERR (-18) when trying to switch to any of the DDR modes. I guess the fsl_esdhc.c driver needs some adaptation for DDR to work. I didn't know how work DDR mode at fsl_esdhc.c.(If you share the host controller TRM, it's helpful to me.) Host controller also need to change the DDR mode. I wonder your board didn't work not to enable the DDR mode? Thank you, yes the fsl_esdhc.c driver does not yet support enabling of DDR mode. I think it should be easy to implement, I believe it is just a question of changing the clock frequency. I need to change the clock frequency, too. I guess that if controller support the DDR mode, there is a register relevant to DDR mode. Best Regards, Jaehoon Chung Best regards, -- Hector Palacios ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH v2 1/4] dm: rename device struct to udevice
Hello Simon, Am 22.05.2014 22:34, schrieb Simon Glass: +Tom Hi Heiko, On 22 May 2014 00:43, Heiko Schocherh...@denx.de wrote: using UBI and DM together leads in compiler error, as both define a struct device, so rename struct device in include/dm/device.h to struct udevice, as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux struct device Signed-off-by: Heiko Schocherh...@denx.de Cc: Simon Glasss...@chromium.org Cc: Marek Vasutma...@denx.de I'm not 100% comfortable with this but if we really want to avoid changing kernel code that moves into U-Boot it is either this or a I vote for this, as we want to sync with newer linux code from time to time, and not changing linux code in U-Boot makes this easier. '#define device ldevice' at the top of the linux code/in a header. I'm not sure which is preferable. Some USB Code (more too?) is also from linux ... Marek? What do you think? I just did not change the current situation, but if we decide to go in this direction, I can try it ... but what, if a source code file uses the U-Boot driver model and linux code? Could we fall into such a case? If Tom decides to apply this, I'd like to request that it be done soon, since it has wide impact on driver model code. Another possibility is, to move driver model specific vars into the linux struct device ... which leads in a bigger struct device for the driver model ... Acked-by: Simon Glasss...@chromium.org Regards, Simon bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] tools/env: add support for ubi volume chardev
Hi!
fw_printenv/fw_setenv in tools/env currently doesn't support
readring/writing directly from UBI volumes, which is supported in
U-Boot itself since commit 2b74433f365fa677a60431a80e524b5d8d04e995.
At that time gluebi mtd devices were widely used though never meant to
be more than a legacy-hack. Kconfig clearly states
Do not enable this unless you use legacy software.
Using gluebi with fw_printenv/fw_setenv is also quite dangerous, as
numbering (and thus device names) of gluebi-emulated mtd devices is
not consistent.
As of today, ubiblock provides a much more conveniant way to access
squashfs filesystems in UBI volumes and was included in linux.git
in commit 9d54c8a33eec78289b1b3f6e10874719c27ce0a7.
Most likely this is going to further reduce the use-cases where gluebi
is needed. ubiblock devices, however, are read-only and cannot be used
for fw_setenv.
In the attempt to build a legacy-free system without gluebi, I added
support for reading/writing the U-Boot environment directly from/to
a UBI volume character device using libubi from mtd-utils
http://git.infradead.org/mtd-utils.git/tree/HEAD:/ubi-utils
The library is currently used only internally by ubi-utils and thus
not installed or available for linking right now.
Can mtd-utils/ubi-utils be changed to install libubi.a and the
required headers so U-Boot's env-tool could link it?
If not, the remaining options are to either clone libubi (or the
needed parts of it) into the U-Boot sources or directly call that bunch
of ioctls in the tool without using libubi at all.
Which of these options would be preferable?
I'm also not clear about how to properly integrate that into U-Boot's
build system and currently use an additional make variable which
allows to select whether or not to build support for UBI volumes.
I tried to implement this in a way that makes it easy to verify that
the existing codepaths are not hurt in case UBI support is disabled.
Thank you for your advise!
Daniel
--
Signed-off-by: Daniel Golle dan...@makrotopia.org
---
tools/env/Makefile | 5
tools/env/fw_env.c | 74 ++
2 files changed, 69 insertions(+), 10 deletions(-)
diff --git a/tools/env/Makefile b/tools/env/Makefile
index f5368bc..d006a93 100644
--- a/tools/env/Makefile
+++ b/tools/env/Makefile
@@ -20,6 +20,11 @@ ifeq ($(MTD_VERSION),old)
HOST_EXTRACFLAGS += -DMTD_OLD
endif
+ifeq ($(UBI),y)
+HOST_EXTRACFLAGS += -DUBI
+HOST_LOADLIBES = -lubi
+endif
+
always := fw_printenv
hostprogs-y := fw_printenv_unstripped
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 30d5b03..5c0acd5 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -29,6 +29,9 @@
# include mtd/mtd-user.h
#endif
+#ifdef UBI
+# include libubi.h
+#endif
#include fw_env.h
#include aes.h
@@ -809,6 +812,11 @@ static int flash_write_buf (int dev, int fd, void *buf,
size_t count,
off_t top_of_range; /* end of the last block we may use */
loff_t blockstart; /* running start of the current block -
MEMGETBADBLOCK needs 64 bits */
+#ifdef UBI
+ libubi_t *libubi = NULL;/* pointer to libubi struct */
+#else
+ void *libubi = NULL;
+#endif
int rc;
/*
@@ -914,7 +922,30 @@ static int flash_write_buf (int dev, int fd, void *buf,
size_t count,
continue;
}
- if (mtd_type != MTD_ABSENT) {
+#ifdef UBI
+ if (mtd_type == MTD_UBIVOLUME) {
+ struct ubi_vol_info volinfo;
+ libubi = libubi_open();
+ if (libubi)
+ rc = !ubi_get_vol_info(libubi,
+ DEVNAME(dev_current), volinfo);
+ if (libubi !rc) {
+ erasesize = volinfo.leb_size;
+ int leb = blockstart / erasesize;
+ if (volinfo.type != UBI_STATIC_VOLUME)
+ rc = ubi_leb_change_start(libubi, fd,
+ leb, erasesize);
+ else
+ rc = ubi_update_start(libubi, fd,
+ erasesize);
+ }
+ if (libubi rc) {
+ libubi_close(libubi);
+ libubi = NULL;
+ }
+ }
+#endif
+ if (!libubi mtd_type != MTD_ABSENT) {
erase.start = blockstart;
ioctl(fd, MEMUNLOCK, erase);
/* These do not need an explicit erase cycle */
@@ -931,7 +962,8 @@ static int flash_write_buf (int dev, int fd, void *buf,
size_t count,
fprintf (stderr,
Seek error on %s: %s\n,
Re: [U-Boot] Booting armv8 kernel on uboot
Hi, fenghua: I always use mkimage converting kernel to uImage and booting it. It works fine. Wish this help you. I followed these steps : 1. git clone git://git.linaro.org/kernel/linaro-aarch64.git 2. compiled it % make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- distclean vexpress_defconfig % make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j4 Image 3. got the Image from arch\arm64\boot dir 4. use mkimage to package Image to uImage ./mkimage -n 'linux-3.12' -A arm64 -O linux -T kernel -C none -a 0xC8 -e 0xC8 -d Image uimage 5. run it with FVP model.(free charge licensed ver) /home/lion/ARMv8/Foundation_v8pkg/models/Linux64_GCC-4.1/Foundation_v8 --cores=2 --no-gicv3 --data=./build/fvp/debug/bl1.bin@0x0 --data=./build/fvp/debug/fip.bin@0x0800 --data=foundation-v8.dtb@0x8200 --data=uimage@0x0008 Then, got the same Synchronous Abort as Bhoj. So, could you describe your explicit steps to get correct uimage? Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
