Re: [U-Boot] Porting a freescale sabrelite-like board to master ?
Hi Eric Are you referring to **another** manufacturer? We have support for SABRE Lite in main-line and are actively maintaining it. What about i.MX6DL SABRE Auto ? Is it in main-line too ? If yes, which config file should I use ? By looking at boards.cfg, I could find mx6qsabreauto, ma6dlsabrelite, nitrogen6dl..., but there is no something like mx6dlsabreauto. The support of it is also in freesacle git mentioned by Thierry http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/?h=imx_v2009.08_3.0.35_4.1.0id=c9b49bf8b7c64e628ce2625272e4deb65b8c8720 Thanks, Miao As that freescale version is too old for me (that is, it does not have support for USB or splashscreen), I would like to use the latest version of mainline u-boot. You should start by using a board file based on Nitrogen6x (which contains support for both Nitrogen6x and SABRE Lite by looking at one pin: http://git.denx.de/?p=u- boot.git;a=blob;f=board/boundary/nitrogen6x/nitrogen6x.c;h=d9c05b07bfa e83466513735cbec95c7f949de7a5;hb=HEAD#l736 I am a little puzzled, when I see that sabrelite support has been removed from main, it seems to have been replaced by the nitrogen board, so my manufacturer patch -badly- applies, especially due to the disparition of flash_header.S ... The differences are minor and explained in more detail here: http://boundarydevices.com/differences-sabre-lite-nitrogen6x I quickly found out that attempting a git rebase of rel_imx_3.0.35_4.1.0 to master was a bad idea, too. So what would be the easiest and time less costing option to achieve what I want to do ? I'd recommend starting with main-line Nitrogen6x code base, and update as needed for your particulars. Regards, Eric ___ 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 1/2] nand/denali: Adding Denali NAND driver support
Hello Michal, These files were imported from Linux Kernel. (drivers/mtd/nand/denali.[ch]) I guess Chin does not want to change the code unless it is really necessary. (And I like this way. We can easily find which parts were adjusted by diffing.) But, good catch! I think your feedback is highly appreciated for Linux folks. Can you post your feedback to Linux Kernel? --- /dev/null +++ b/drivers/mtd/nand/denali_nand.c @@ -0,0 +1,1166 @@ +/* + * Copyright (C) 2013 Altera Corporation www.altera.com What about 2014? I agree that this part should be fixed at the next version. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] nand/denali: Adding Denali NAND driver support
Hi Masahiro. On 02/24/2014 09:06 AM, Masahiro Yamada wrote: Hello Michal, These files were imported from Linux Kernel. (drivers/mtd/nand/denali.[ch]) then they should be fixed too. Or better fix kernel driver first and then add these changes to u-boot. Checkpatch in the u-boot is just the same as is in the kernel. I guess Chin does not want to change the code unless it is really necessary. (And I like this way. We can easily find which parts were adjusted by diffing.) I have no problem that you want to keep that code synchronized for easier diffing but adding incorrect code is just really bad. And you shouldn't just copy what's wrong. But, good catch! I think your feedback is highly appreciated for Linux folks. Can you post your feedback to Linux Kernel? The driver is in mainline from 2010 that's why go and fix it. Make no sense for me to send this to linux kernel because the reaction will be that I should fix it and I have no interest to fix it. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 05/12] board:samsung:common: remove unused max77686 init function
On 24/02/14 15:39, Piotr Wilczek wrote: Dear Minkyu Kang, -Original Message- From: Minkyu Kang [mailto:mk7.k...@samsung.com] Sent: Saturday, February 22, 2014 8:38 AM To: Rajeshwari Birje; Piotr Wilczek; Rajeshwari S Shinde Cc: Jaehoon Chung; u-boot@lists.denx.de; Kyungmin Park Subject: Re: [U-Boot] [PATCH V2 05/12] board:samsung:common: remove unused max77686 init function Dear Rajeshwari and Piotr, On 14/02/14 20:40, Rajeshwari Birje wrote: Hi Piotr, On Fri, Feb 14, 2014 at 3:18 PM, Piotr Wilczek p.wilc...@samsung.com wrote: Hi Rajeshwari, -Original Message- From: Rajeshwari Birje [mailto:rajeshwari.bi...@gmail.com] Sent: Friday, February 14, 2014 6:32 AM To: Piotr Wilczek Cc: u-boot@lists.denx.de; Jaehoon Chung; Kyungmin Park; Rajeshwari S Shinde Subject: Re: [U-Boot] [PATCH V2 05/12] board:samsung:common: remove unused max77686 init function Hi Piotr, On Thu, Feb 13, 2014 at 7:40 PM, Piotr Wilczek p.wilc...@samsung.com wrote: This patch removes currently unused max77686_init function. Despite being not used, it's implementation is board specific. MAX77686 is required for 5250, but missed it somehow when adding 5420 support and making a common config file for both. It is my mistake will correct the same You can refer: [U-Boot] [PATCH V5 0/6] SMDK5420: Add S2MPS11 pmic support to SMDK5420 by Leela Krishna Amudala It adds a generic way for PMIC support. http://lists.denx.de/pipermail/u-boot/2014-January/171113.html MAX77686 is also used at Trats2 so max77686_init must be either generic based on DT or moved to the board file. Generic in the sense you want all registers to be set and there values have to come from DT file? Which ever you feel OK is fine with me. So.. do you agree to apply this patch? or need another discussion? I will move max77686_init to smdk5250 board file and prepare v3 of this patch series. Do you have any other comments to this series? No. looks good to me. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/6] zynq: Do not use SPL OF initialization
Disable CONFIG_OF_CONTROL for SPL compilation. Signed-off-by: Michal Simek michal.si...@xilinx.com --- Changes in v2: - Do not init SPL from DTB - not supported now - New patch in this series include/configs/zynq-common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h index 14f0b90..731e69b 100644 --- a/include/configs/zynq-common.h +++ b/include/configs/zynq-common.h @@ -242,6 +242,7 @@ #ifdef CONFIG_SPL_BUILD #define CONFIG_SYS_DCACHE_OFF #undef CONFIG_FPGA +#undef CONFIG_OF_CONTROL #endif /* MMC support */ -- 1.8.2.3 pgp2Md229lBbh.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/6] mmc: zynq: Add OF initialization support
Enable initialize sdhci from DTB.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v2: None
arch/arm/include/asm/arch-zynq/sys_proto.h | 1 +
drivers/mmc/zynq_sdhci.c | 29 +
2 files changed, 30 insertions(+)
diff --git a/arch/arm/include/asm/arch-zynq/sys_proto.h
b/arch/arm/include/asm/arch-zynq/sys_proto.h
index 0a2ba05..a68e1b3 100644
--- a/arch/arm/include/asm/arch-zynq/sys_proto.h
+++ b/arch/arm/include/asm/arch-zynq/sys_proto.h
@@ -19,5 +19,6 @@ extern void zynq_ddrc_init(void);
/* Driver extern functions */
extern int zynq_sdhci_init(u32 regbase);
+extern int zynq_sdhci_of_init(const void *blob);
#endif /* _SYS_PROTO_H_ */
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 72a272f..fdce2c2 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -7,6 +7,8 @@
*/
#include common.h
+#include fdtdec.h
+#include libfdt.h
#include malloc.h
#include sdhci.h
#include asm/arch/sys_proto.h
@@ -32,3 +34,30 @@ int zynq_sdhci_init(u32 regbase)
add_sdhci(host, 5200, 5200 9);
return 0;
}
+
+#ifdef CONFIG_OF_CONTROL
+int zynq_sdhci_of_init(const void *blob)
+{
+ int offset = 0;
+ u32 ret = 0;
+ u32 reg;
+
+ debug(ZYNQ SDHCI: Initialization\n);
+
+ do {
+ offset = fdt_node_offset_by_compatible(blob, offset,
+ arasan,sdhci-8.9a);
+ if (offset != -1) {
+ reg = fdtdec_get_addr(blob, offset, reg);
+ if (reg != FDT_ADDR_T_NONE) {
+ ret |= zynq_sdhci_init(reg);
+ } else {
+ debug(ZYNQ SDHCI: Can't get base address\n);
+ return -1;
+ }
+ }
+ } while (offset != -1);
+
+ return ret;
+}
+#endif
--
1.8.2.3
pgpAEVuYKcTJC.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/6] net: emaclite: Fix OF initialization
- Add xilinx_emaclite_of_init to netdev.h
- Remove global data pointer from the driver
- Add better handling for error state.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v2:
- Remove bis parameter which was causing compilation error
drivers/net/xilinx_emaclite.c | 17 +
include/netdev.h | 1 +
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index 0a5209d..2a5cc44 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -14,8 +14,6 @@
#include asm/io.h
#include fdtdec.h
-DECLARE_GLOBAL_DATA_PTR;
-
#undef DEBUG
#define ENET_ADDR_LENGTH 6
@@ -364,24 +362,27 @@ int xilinx_emaclite_initialize(bd_t *bis, unsigned long
base_addr,
}
#ifdef CONFIG_OF_CONTROL
-int xilinx_emaclite_init(bd_t *bis)
+int xilinx_emaclite_of_init(const void *blob)
{
int offset = 0;
u32 ret = 0;
u32 reg;
do {
- offset = fdt_node_offset_by_compatible(gd-fdt_blob, offset,
+ offset = fdt_node_offset_by_compatible(blob, offset,
xlnx,xps-ethernetlite-1.00.a);
if (offset != -1) {
- reg = fdtdec_get_addr(gd-fdt_blob, offset, reg);
+ reg = fdtdec_get_addr(blob, offset, reg);
if (reg != FDT_ADDR_T_NONE) {
- u32 rxpp = fdtdec_get_int(gd-fdt_blob, offset,
+ u32 rxpp = fdtdec_get_int(blob, offset,
xlnx,rx-ping-pong, 0);
- u32 txpp = fdtdec_get_int(gd-fdt_blob, offset,
+ u32 txpp = fdtdec_get_int(blob, offset,
xlnx,tx-ping-pong, 0);
- ret |= xilinx_emaclite_initialize(bis, reg,
+ ret |= xilinx_emaclite_initialize(NULL, reg,
txpp, rxpp);
+ } else {
+ debug(EMACLITE: Can't get base address\n);
+ return -1;
}
}
} while (offset != -1);
diff --git a/include/netdev.h b/include/netdev.h
index 3705629..c684014 100644
--- a/include/netdev.h
+++ b/include/netdev.h
@@ -86,6 +86,7 @@ int uli526x_initialize(bd_t *bis);
int armada100_fec_register(unsigned long base_addr);
int xilinx_axiemac_initialize(bd_t *bis, unsigned long base_addr,
unsigned long dma_addr);
+int xilinx_emaclite_of_init(const void *blob);
int xilinx_emaclite_initialize(bd_t *bis, unsigned long base_addr,
int txpp, int rxpp);
int xilinx_ll_temac_eth_init(bd_t *bis, unsigned long base_addr, int flags,
--
1.8.2.3
pgpAqYJje4Lj8.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/6] zynq: Add OF ram initialization support
Read ram size directly from DTB.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v2: None
board/xilinx/zynq/board.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 82f2345..485a5e4 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -5,6 +5,7 @@
*/
#include common.h
+#include fdtdec.h
#include netdev.h
#include zynqpl.h
#include asm/arch/hardware.h
@@ -134,8 +135,27 @@ int board_mmc_init(bd_t *bd)
int dram_init(void)
{
+#ifdef CONFIG_OF_CONTROL
+ int node;
+ fdt_addr_t addr;
+ fdt_size_t size;
+ const void *blob = gd-fdt_blob;
+
+ node = fdt_node_offset_by_prop_value(blob, -1, device_type,
+memory, 7);
+ if (node == -FDT_ERR_NOTFOUND) {
+ debug(ZYNQ DRAM: Can't get memory node\n);
+ return -1;
+ }
+ addr = fdtdec_get_addr_size(blob, node, reg, size);
+ if (addr == FDT_ADDR_T_NONE || size == 0) {
+ debug(ZYNQ DRAM: Can't get base address or size\n);
+ return -1;
+ }
+ gd-ram_size = size;
+#else
gd-ram_size = CONFIG_SYS_SDRAM_SIZE;
-
+#endif
zynq_ddrc_init();
return 0;
--
1.8.2.3
pgpn0tl60ot0p.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/6] net: gem: Add OF initialization support
Gem can be directly initialized from DTB.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v2: None
drivers/net/zynq_gem.c | 42 ++
include/netdev.h | 1 +
2 files changed, 43 insertions(+)
diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 6d4001b..101489c 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -12,6 +12,8 @@
#include common.h
#include net.h
#include config.h
+#include fdtdec.h
+#include libfdt.h
#include malloc.h
#include asm/io.h
#include phy.h
@@ -534,3 +536,43 @@ int zynq_gem_initialize(bd_t *bis, int base_addr, int
phy_addr, u32 emio)
return 1;
}
+
+#ifdef CONFIG_OF_CONTROL
+int zynq_gem_of_init(const void *blob)
+{
+ int offset = 0;
+ u32 ret = 0;
+ u32 reg, phy_reg;
+
+ debug(ZYNQ GEM: Initialization\n);
+
+ do {
+ offset = fdt_node_offset_by_compatible(blob, offset,
+ xlnx,ps7-ethernet-1.00.a);
+ if (offset != -1) {
+ reg = fdtdec_get_addr(blob, offset, reg);
+ if (reg != FDT_ADDR_T_NONE) {
+ offset = fdtdec_lookup_phandle(blob, offset,
+ phy-handle);
+ if (offset != -1)
+ phy_reg = fdtdec_get_addr(blob, offset,
+ reg);
+ else
+ phy_reg = 0;
+
+ debug(ZYNQ GEM: addr %x, phyaddr %x\n,
+ reg, phy_reg);
+
+ ret |= zynq_gem_initialize(NULL, reg,
+ phy_reg, 0);
+
+ } else {
+ debug(ZYNQ GEM: Can't get base address\n);
+ return -1;
+ }
+ }
+ } while (offset != -1);
+
+ return ret;
+}
+#endif
diff --git a/include/netdev.h b/include/netdev.h
index c684014..32b5073 100644
--- a/include/netdev.h
+++ b/include/netdev.h
@@ -91,6 +91,7 @@ int xilinx_emaclite_initialize(bd_t *bis, unsigned long
base_addr,
int txpp, int rxpp);
int xilinx_ll_temac_eth_init(bd_t *bis, unsigned long base_addr, int flags,
unsigned long ctrl_addr);
+int zynq_gem_of_init(const void *blob);
int zynq_gem_initialize(bd_t *bis, int base_addr, int phy_addr, u32 emio);
/*
* As long as the Xilinx xps_ll_temac ethernet driver has not its own interface
--
1.8.2.3
pgpWH65gl3Tj9.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/6] serial: zynq: Add OF initialization support
Add console selection from DTB which is enough to have
OF driven solution.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v2: None
drivers/serial/serial_zynq.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/serial/serial_zynq.c b/drivers/serial/serial_zynq.c
index 22c6bf0..53a8af0 100644
--- a/drivers/serial/serial_zynq.c
+++ b/drivers/serial/serial_zynq.c
@@ -6,6 +6,7 @@
*/
#include common.h
+#include fdtdec.h
#include watchdog.h
#include asm/io.h
#include linux/compiler.h
@@ -13,6 +14,8 @@
#include asm/arch/clk.h
#include asm/arch/hardware.h
+DECLARE_GLOBAL_DATA_PTR;
+
#define ZYNQ_UART_SR_TXFULL0x0010 /* TX FIFO full */
#define ZYNQ_UART_SR_RXEMPTY 0x0002 /* RX FIFO empty */
@@ -182,6 +185,30 @@ DECLARE_PSSERIAL_FUNCTIONS(1);
struct serial_device uart_zynq_serial1_device =
INIT_PSSERIAL_STRUCTURE(1, ttyPS1);
+#ifdef CONFIG_OF_CONTROL
+__weak struct serial_device *default_serial_console(void)
+{
+ const void *blob = gd-fdt_blob;
+ int node;
+ unsigned int base_addr;
+
+ node = fdt_path_offset(blob, serial0);
+ if (node 0)
+ return NULL;
+
+ base_addr = fdtdec_get_addr(blob, node, reg);
+ if (base_addr == FDT_ADDR_T_NONE)
+ return NULL;
+
+ if (base_addr == ZYNQ_SERIAL_BASEADDR0)
+ return uart_zynq_serial0_device;
+
+ if (base_addr == ZYNQ_SERIAL_BASEADDR1)
+ return uart_zynq_serial1_device;
+
+ return NULL;
+}
+#else
__weak struct serial_device *default_serial_console(void)
{
#if defined(CONFIG_ZYNQ_SERIAL_UART0)
@@ -194,6 +221,7 @@ __weak struct serial_device *default_serial_console(void)
#endif
return NULL;
}
+#endif
void zynq_serial_initalize(void)
{
--
1.8.2.3
pgp02OJEIpEZm.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kbuild: fix SPL link bug when USE_PRIVATE_LIBGCC is yes
Commit 6825a95 (kbuild: use Linux Kernel build scripts) changed the behavior of linkage when USE_PRIAVATE_LIBGCC is defined as yes. (It dropped arch/arm/lib/eabi_compat.o from the target library.) Affected boards are all Tegra boards. This commit gets back the same behavior as before Kbuild series. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Tom Warren twar...@nvidia.com Cc: Tom Rini tr...@ti.com --- Hello Tom(Rini), I made a serious mistake in the Kbuild series. (Commit 6825a95) Sorry. This patch fixes the problem and gets back the originial link behavior. Please pick this. spl/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/spl/Makefile b/spl/Makefile index da1c3c0..346d0aa 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -133,7 +133,8 @@ libs-y := $(patsubst %/, %/built-in.o, $(libs-y)) # Add GCC lib ifeq ($(USE_PRIVATE_LIBGCC), yes) -PLATFORM_LIBS := $(SPLTREE)/arch/$(ARCH)/lib/lib.a +PLATFORM_LIBGCC = $(SPLTREE)/arch/$(ARCH)/lib/lib.a +PLATFORM_LIBS := $(filter-out %/lib.a, $(filter-out -lgcc, $(PLATFORM_LIBS))) $(PLATFORM_LIBGCC) endif u-boot-spl-init := $(head-y) -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/15] kbuild: move asm-offsets.h rules to ./Kbuild
Hello Wolfgang, Can we use here documents in cases like this, so the number of shell command executions could be greatly reduced? Does something like this work? define cmd_generic-offsets\ cat _END_ $@\ #ifndef __GENERIC_ASM_OFFSETS_H__ \ #define __GENERIC_ASM_OFFSETS_H__ \ /*\ * DO NOT MODIFY \ *\ * This file was generated by Kbuild \ */ \ $$(sed -ne $(sed-y) $) \ #endif\ _END_ ? No. I tried your code but it did not work. Kbuild created an empty file include/generated/generic-asm-offsets.h. I tried to debug but finally I gave up. Here document ( cat END ... END) syntax is really nightmare in Makefile. I've never seen that syntax in Makefile. For example, if you see the top Makefile of Linux Kernel, it always uses echo command. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Tom, On Fri, 21 Feb 2014 14:16:45 -0500, Tom Rini tr...@ti.com wrote: Hey, The following changes since commit 3e11350255d9c5d4bd03c2a65769da84c05d3294: Merge branch 'u-boot/master' into 'u-boot-arm/master' (2014-02-20 13:16:05 +0100) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to 11f296870659e1375e7116a859458b254cc3156f: ti814x: Fix illegal use of FP ops in clock_ti814x.c (2014-02-21 14:03:44 -0500) Dave Gerlach (1): ARM: AM43xx: GP-EVM: Correct GPIO used for VTT regulator control Hannes Petermaier (2): board: Add support for BR T-Series Motherboard Add support for BR KWB Motherboard Janne Grunau (1): ARM: OMAP4: fix DDR timings for OMAP4430 ES2.0 Lothar Felten (1): am335x: Initial support for Silica Pengwyn board Måns Rullgård (1): ti814x: Fix illegal use of FP ops in clock_ti814x.c Nishanth Menon (2): DRA7: fix ABB efuse offset for OPP_NOM omap4_common: config: remove I2C for SPL mode Stefan Roese (2): arm: omap3: Fix tao3530/omap3_ha SPL boot hangup (GPIO clocks not enabled) arm: omap: cm_t35: Remove CONFIG_SYS_BOOTMAPSZ to fix FDT Linux booting Stefano Babic (3): OMAP3: add missing gpio clock init and fix NAND SPL for mcx board omap3: fix pinmux for mcx board OMAP3: fix default environment for mcx board Tom Rini (3): am335x_evm: Enable GPT commands am43xx_evm: Enable GPT commands dra7xx_evm: Enable GPT commands arch/arm/cpu/armv7/am33xx/board.c |6 +- arch/arm/cpu/armv7/am33xx/clock_am43xx.c|2 + arch/arm/cpu/armv7/am33xx/clock_ti814x.c|5 +- arch/arm/cpu/armv7/omap4/hw_data.c | 18 ++ arch/arm/cpu/armv7/omap5/prcm-regs.c|2 +- arch/arm/include/asm/arch-am33xx/cpu.h | 12 +- arch/arm/include/asm/arch-am33xx/ddr_defs.h | 16 ++ arch/arm/include/asm/arch-am33xx/gpio.h |4 +- board/BuR/common/bur_common.h | 22 +++ board/BuR/common/common.c | 216 ++ board/BuR/kwb/Makefile | 12 ++ board/BuR/kwb/board.c | 240 board/BuR/kwb/mux.c | 195 board/BuR/tseries/Makefile | 14 ++ board/BuR/tseries/board.c | 147 +++ board/BuR/tseries/mux.c | 225 +++ board/htkw/mcx/mcx.h|2 - board/silica/pengwyn/Makefile | 13 ++ board/silica/pengwyn/board.c| 207 + board/silica/pengwyn/board.h| 15 ++ board/silica/pengwyn/mux.c | 98 ++ board/ti/am43xx/board.c | 16 +- board/ti/am43xx/mux.c |6 +- boards.cfg |5 + include/configs/am335x_evm.h| 13 ++ include/configs/am43xx_evm.h|9 + include/configs/bur_am335x_common.h | 197 include/configs/cm_t35.h|7 - include/configs/dra7xx_evm.h| 11 ++ include/configs/kwb.h | 128 + include/configs/mcx.h |9 +- include/configs/pengwyn.h | 208 + include/configs/tao3530.h |7 + include/configs/ti_am335x_common.h |1 - include/configs/ti_omap4_common.h |6 + include/configs/tseries.h | 265 +++ 36 files changed, 2323 insertions(+), 36 deletions(-) create mode 100644 board/BuR/common/bur_common.h create mode 100644 board/BuR/common/common.c create mode 100644 board/BuR/kwb/Makefile create mode 100644 board/BuR/kwb/board.c create mode 100644 board/BuR/kwb/mux.c create mode 100644 board/BuR/tseries/Makefile create mode 100644 board/BuR/tseries/board.c create mode 100644 board/BuR/tseries/mux.c create mode 100644 board/silica/pengwyn/Makefile create mode 100644 board/silica/pengwyn/board.c create mode 100644 board/silica/pengwyn/board.h create mode 100644 board/silica/pengwyn/mux.c create mode 100644 include/configs/bur_am335x_common.h create mode 100644 include/configs/kwb.h create mode 100644 include/configs/pengwyn.h create mode 100644 include/configs/tseries.h Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] power: fix: Do not execute pmic command when not all necessary parameters are passed
Lack of this check resulted in a data abort when CPU tried to execute the following command (without further mandatory input): 'pmic MAX77686_PMIC'. Only the 'pmic list' command requires one passed parameter. Other require at least two valid parameters for correct operation. Signed-off-by: Lukasz Majewski l.majew...@samsung.com --- drivers/power/power_core.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/power/power_core.c b/drivers/power/power_core.c index 29ccc83..fe1f316 100644 --- a/drivers/power/power_core.c +++ b/drivers/power/power_core.c @@ -140,6 +140,9 @@ int do_pmic(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) return CMD_RET_SUCCESS; } + if (argc 3) + return CMD_RET_USAGE; + name = argv[1]; cmd = argv[2]; -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] x86: coreboot: delete unused coreboot/config.mk
HOSTCFLAGS_autoconf.mk.dep was added by commit 422322f but it has never been used. Cc: Vadim Bendebury vben...@chromium.org Cc: Simon Glass s...@chromium.org Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Hello Vadim, Simon. I cannot understand what the hell this macro is used for. Why HOSTCFLAGS_...? Why not CFLAGS_... ? Can you explain? board/chromebook-x86/coreboot/config.mk | 7 --- 1 file changed, 7 deletions(-) delete mode 100644 board/chromebook-x86/coreboot/config.mk diff --git a/board/chromebook-x86/coreboot/config.mk b/board/chromebook-x86/coreboot/config.mk deleted file mode 100644 index 0c05dd0..000 --- a/board/chromebook-x86/coreboot/config.mk +++ /dev/null @@ -1,7 +0,0 @@ -# -# Copyright (c) 2011 The Chromium OS Authors. All rights reserved. -# -# SPDX-License-Identifier: GPL-2.0 BSD-3-Clause -# - -HOSTCFLAGS_autoconf.mk.dep = -Wno-variadic-macros -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: delete unused macro CONFIG_ARCH_DEVICE_TREE
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Tom Warren twar...@nvidia.com Cc: Stephen Warren swar...@nvidia.com Cc: Rajeshwari Birje rajeshwar...@samsung.com Cc: Inderpal Singh inderpal.si...@linaro.org --- Hi. I grepped the whole tree and found arch/arm/cpu/armv7/tegra124/config.mk include/configs/arndale.h include/configs/smdk5420.h define CONFIG_ARCH_DEVICE_TREE, but it is never used anywhere. I cannot understand what this macro was added for. If I am doing a wrong thing, please stop me. arch/arm/cpu/armv7/tegra124/config.mk | 10 -- include/configs/arndale.h | 2 -- include/configs/smdk5420.h| 2 -- 3 files changed, 14 deletions(-) delete mode 100644 arch/arm/cpu/armv7/tegra124/config.mk diff --git a/arch/arm/cpu/armv7/tegra124/config.mk b/arch/arm/cpu/armv7/tegra124/config.mk deleted file mode 100644 index 2f1c645..000 --- a/arch/arm/cpu/armv7/tegra124/config.mk +++ /dev/null @@ -1,10 +0,0 @@ -# -# (C) Copyright 2013 -# NVIDIA Corporation www.nvidia.com -# (C) Copyright 2002 -# Gary Jennejohn, DENX Software Engineering, ga...@denx.de -# -# SPDX-License-Identifier: GPL-2.0+ -# - -CONFIG_ARCH_DEVICE_TREE := tegra124 diff --git a/include/configs/arndale.h b/include/configs/arndale.h index 9584d82..515facf 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -22,8 +22,6 @@ #define CONFIG_DISPLAY_CPUINFO #define CONFIG_DISPLAY_BOARDINFO -/* Enable fdt support for Exynos5250 */ -#define CONFIG_ARCH_DEVICE_TREEexynos5250 #define CONFIG_OF_CONTROL #define CONFIG_OF_SEPARATE diff --git a/include/configs/smdk5420.h b/include/configs/smdk5420.h index 447f8e5..b96eea8 100644 --- a/include/configs/smdk5420.h +++ b/include/configs/smdk5420.h @@ -17,8 +17,6 @@ #undef CONFIG_DEFAULT_DEVICE_TREE #define CONFIG_DEFAULT_DEVICE_TREE exynos5420-smdk5420 -#define CONFIG_ARCH_DEVICE_TREEexynos5420 - #define CONFIG_VAR_SIZE_SPL #define CONFIG_SYS_SDRAM_BASE 0x2000 -- 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/2] kbuild: Move linker sciript check to prepare1
Same as the previous commit. Move sanity check to prepare1 target to avoid nasty troubles. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Makefile | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index fffeb7e..b034a36 100644 --- a/Makefile +++ b/Makefile @@ -518,9 +518,6 @@ ifndef LDSCRIPT # We don't expect a Makefile here LDSCRIPT_MAKEFILE_DIR = endif - ifeq ($(wildcard $(LDSCRIPT)),) -$(error could not find linker script) - endif endif else @@ -996,6 +993,10 @@ ifeq ($(CONFIG_SYS_GENERIC_BOARD),y) @/bin/false endif endif +ifeq ($(wildcard $(LDSCRIPT)),) + @echo 2 Could not find linker script. + @/bin/false +endif archprepare: prepare1 scripts_basic -- 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/2] Kbuild: Fix a false error of sanity check
Masahiro Yamada (2): kbuild: Fix a false error of generic board support kbuild: Move linker sciript check to prepare1 Makefile | 22 +++--- 1 file changed, 11 insertions(+), 11 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/2] kbuild: Fix a false error of generic board support
Before this commit, make terminated with an error where it shouldn't under some condition. This bug happened when we built a board unsupporting generic board right after building with generic board. For example, the following sequence failed. (harmony uses generic board but microblaze-generic does not support it) $ make harmony_config Configuring for harmony board... $ make CROSS_COMPILE=arm-linux-gnueabi- [ Build succeed ] $ make microblaze-generic_config Configuring for microblaze-generic board... $ make CROSS_COMPILE=microblaze-linux- Makefile:488: *** Your architecture does not support generic board. Please undefined CONFIG_SYS_GENERIC_BOARD in your board config file. Stop. We had to do make mrproper before building the microblaze board. This commit fixes this unconvenience. Move generic board sanity check to prepare1 target, which is run after generation of include/autoconf.mk. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Makefile | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 84d6db4..fffeb7e 100644 --- a/Makefile +++ b/Makefile @@ -485,13 +485,6 @@ ifeq ($(wildcard include/config.mk),) $(error System not configured - see README) endif -ifeq ($(__HAVE_ARCH_GENERIC_BOARD),) -ifneq ($(CONFIG_SYS_GENERIC_BOARD),) -$(error Your architecture does not support generic board. \ -Please undefined CONFIG_SYS_GENERIC_BOARD in your board config file) -endif -endif - # If board code explicitly specified LDSCRIPT or CONFIG_SYS_LDSCRIPT, use # that (or fail if absent). Otherwise, search for a linker script in a # standard location. @@ -996,7 +989,13 @@ endif prepare2: prepare3 outputmakefile prepare1: prepare2 $(version_h) $(timestamp_h) - @: +ifeq ($(__HAVE_ARCH_GENERIC_BOARD),) +ifeq ($(CONFIG_SYS_GENERIC_BOARD),y) + @echo 2 Your architecture does not support generic board. + @echo 2 Please undefine CONFIG_SYS_GENERIC_BOARD in your board config file. + @/bin/false +endif +endif archprepare: prepare1 scripts_basic -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64 patch: gicv3 support
-Original Messages- From: Albert ARIBAUD albert.u.b...@aribaud.net Sent Time: 2014-02-22 00:38:05 (Saturday) To: feng...@phytium.com.cn Cc: u-boot@lists.denx.de, tr...@ti.com Subject: Re: [PATCH] arm64 patch: gicv3 support Hi feng...@phytium.com.cn, On Wed, 15 Jan 2014 16:10:56 +0800, feng...@phytium.com.cn wrote: From: David Feng feng...@phytium.com.cn This patch add gicv3 support to uboot armv8 platform. Modifications cover 4 source files, as follows: gic.S: gicv3 initialization and sgi interrupt raising. goc.h: gicv3 register definitions. vexpress_aemv8a.h: add CONFIG_GICV2/CONFIG_GICV3 switch. start.S: set SCR_EL3.NS bit to 1, gicv3 register of ICC_SRE_EL2 could be accessed only when SCR_EL3.NS=1. set SCR_EL3.IRQ|FIQ|EA bits, reroute all interrupts to el3 at all cores, slaves could be waken up by interrupt only when the interrupt is routed to it when running at el3. Note: please use the latest gcc 4.8 compiler from linaro which support gicv3 system register assembling. Signed-off-by: David Feng feng...@phytium.com.cn --- I am not well-versed enough in aarch64 and GIC, be it v2 or v3, so... Is this patch OK as it is, or should a V2 follow with common GIVv2/GICv3 code merged? Amicalement, hi Albert, I am preparing the V2, there are some optimizations. But it's still Armv8 specific. I would like to consider common Gicv2/Gicv3 code working across armv7 and armv8. It's not easy and I have no armv7 test environment. Thank you! Best Regards, David ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] boards.cfg: Keep arc entries sorted
Run tools/reformat.py -i -d '-' -s 8 boards.cfg boards0.cfg mv boards0.cfg boards.cfg in order to keep arc entries sorted. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- boards.cfg | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/boards.cfg b/boards.cfg index c90bb2b..8ce130a 100644 --- a/boards.cfg +++ b/boards.cfg @@ -44,6 +44,9 @@ ### Active aarch64 armv8 - armltd vexpress64 vexpress_aemv8a vexpress_aemv8a:ARM64 David Feng feng...@phytium.com.cn +Active arc arc700 - synopsys- arcangel4- Alexey Brodkin abrod...@synopsys.com +Active arc arc700 - synopsys- axs101 - Alexey Brodkin abrod...@synopsys.com +Active arc arc700 - synopsysarcangel4 arcangel4-be - Alexey Brodkin abrod...@synopsys.com Active arm arm1136- armltd integrator integratorcp_cm1136 integratorcp:CM1136 Linus Walleij linus.wall...@linaro.org Active arm arm1136mx31- - imx31_phycore- - Active arm arm1136mx31davedenx- qong - Wolfgang Denk w...@denx.de @@ -1220,9 +1223,6 @@ Active sparc leon3 - gaisler - Active sparc leon3 - gaisler - gr_xc3s_1500 - - Active sparc leon3 - gaisler - grsim- - Active x86 x86corebootchromebook-x86 coreboot coreboot-x86 coreboot:SYS_TEXT_BASE=0x0111 - -Active arc arc700 - synopsys- axs101 - Alexey Brodkin abrod...@synopsys.com -Active arc arc700 - synopsys- arcangel4- Alexey Brodkin abrod...@synopsys.com -Active arc arc700 - synopsysarcangel4 arcangel4-be- Alexey Brodkin abrod...@synopsys.com Orphan arm arm1136mx31- imx31_phycore imx31_phycore_eetimx31_phycore:IMX31_PHYCORE_EET (resigned) Guennadi Liakhovetski g.liakhovet...@gmx.de Orphan arm arm1136mx31freescale - mx31ads - (resigned) Guennadi Liakhovetski g.liakhovet...@gmx.de Orphan arm pxa- - - lubbock -
Re: [U-Boot] [linux-sunxi] Re: [PATCH v2 3/3] ahci: provide sunxi SATA driver using AHCI platform framework
On Thu, 2014-02-20 at 14:06 -0600, Rob Herring wrote:
On Thu, Feb 20, 2014 at 10:06 AM, Ian Campbell i...@hellion.org.uk wrote:
On Thu, 2014-02-20 at 09:24 -0600, Rob Herring wrote:
+#define AHCI_PHYCS0R 0x00c0
+#define AHCI_PHYCS1R 0x00c4
+#define AHCI_PHYCS2R 0x00c8
[...]
+#define AHCI_RWCR 0x00fc
These registers are not sunxi specific, but part of a certain vendor's
IP found in several SOCs. I can't tell you who, but it shouldn't be
too hard to figure out.
Actually, only the 4 above are used here and if I'm guessing which
certain vendor you mean correctly then the code for those has these in
its register map as reserved and doesn't touch them (this is true in
both of the similar drivers I looked at).
The rest of the registers in that list did look a lot the DW part
(judging from the existing u-boot drivers) though.
There may be others that do this setup in firmware.
Someone pointed me to http://linux-sunxi.org/Used_IP_cores which
suggests that while the SATA block is DW the PHY might be Allwinner's
own -- that would fit with having found a bunch of unusual registers in
a gap in the DW address map...
In v3 I'll drop all the unused #defines, which apart from being the sane
thing to do ought to make it look less like I'm duplicating DW stuff
here.
+#define BIT(x) (1x)
+static u32 sunxi_getbits(u8 *reg, u8 mask, u8 shift)
+{
+ return (readl(reg) shift) mask;
+}
+
+static int sunxi_ahci_phy_init(u32 base)
+{
[...magic...]
+
I would guess this code or something very similar already exists in u-boot.
I've had a look in the most obvious files in drivers/block/ and I don't
see anything. Perhaps I should look harder.
FWIW I also couldn't find anything similar in linux/drivers/ata.
I thought iMX needed something like this, but it doesn't look like it
now. Perhaps they figured out the bootrom is doing all this and it is
not really necessary to redo.
I don't really have any concrete suggestions here. I'm just
highlighting potential duplication.
Thanks for doing so, I don't want to be responsible for YASD (Yet
Another SATA Driver...)
We already have 2 AHCI drivers in
u-boot. I think dwc_ahsata.c is the cleaner implementation, but ahci.c
is probably more well tested now. The Chromium folks have done various
fixes as has Calxeda. I think dwc_ahsata.c is only used for i.MX and
SATA is not the primary storage interface for most i.MX designs.
It looked to me like the ahci.c one was a better bet going forward,
since it seems more generic etc and it supports the platform ahci
model, which was a good fit. Also I knew ahci.c was good from my use on
the Calxeda platforms.
I could try switching to dwc_ahsata.c if people strongly prefer.
Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] [PATCH] rewrite doc/README.arm-unaligned-accesses
On Sat, Feb 22, 2014 at 01:17:50PM +0100, Albert ARIBAUD wrote: [snip] Again -- I do insist -- I understand your viewpoint, which is that compilers can always be made to produce correct code from packed structs with unaligned fields, therefore such unaligned fields are not a problem and we should just let the compilers deal with it by passing them adequate options, which in the case of ARM means pasing gcc -mno-unaligned-access at least when it is not the default already. OK, good. I made a mistake when I accepted the ARM change that moved us away from -mno-unaligned-access + -march=armv7 (or armv6 but we don't have that tune atm). To be clear, our project policy is not a strict C99 implementation. We use that to guide us in many cases (and frankly, we may let C11 guide us as needed and things mature). We rely upon certain gcc behaviors. In this case we rely on access to packed structs and unaligned members working seamlessly. ARM must be corrected to work here as all other architectures do. And I would agree with this viewpoint if I did not want us to catch unaligned accesses in the source code which we don't know about yet. This is wrong. Every case we see on ARMv7 now is the case of compiler was told unaligned access needs no special handling, perform no special handling here. For _all_ architectures gcc would look at this code and then based on what it's been told about CPU capabilities make a decision that it believes would not lead to a fault. My viewpoint is that not all unaligned accesses are wanted, and we should catch those that we did not and either remove them or make them explicit. And I think that is the gist of the kernel doc -- if relying on the compiler was enough, put/get_unaligned would not be suggested. No, this isn't quite right. The gist of the kernel doc is that there are some cases where the compiler cannot know if the addresses will be aligned or not, and _those_ require special care. Most cases however the compiler does take care to align pointers or break down the accesses when it can know things are unaligned. [snip] The way I see it, if we follow the kernel doc advice of always making unaligned accesses explicit in the source code (and we should), then -munaligned-access only has advantages over -mno-unaligned-access, because both behave the same way for wanted unaligned accesses, but -munaligned-access will catch unwanted ones whereas -mno-unaligned-access won't. This glosses over the very important part where, in short, __packed structs may look dangerous at first glance, but they aren't, with respect to the constraints the kernel (and ourself) place upon the compiler. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Regression][ext4] Regression at EXT4 filesystem code
Dear All, In the newest master u-boot (SHA1: 1674df60d17e0e72396c961d5390bb62b184ad95) I've found a regression with writing to EXT4 file system: Writing uImage to ext4 partition - created with Debian's mkfs.ext4 /dev/sdd2 (size 58M) dfu-util -R -a2 -D arch/arm/boot/uImage uImage size - 4.8 MiB GADGET DRIVER: usb_dnl_dfu USB PHY0 Enable #Extent Error ext4fs_devread read outside partition 4294967294 Extent Error ext4fs_devread read outside partition 4294967294 File System is consistent Extent Error part_offset is 26624 total_sector is 131072 error: overflow occurs Extent Error ext4fs_devread read outside partition 4294967294 Extent Error ext4fs_devread read outside partition 4294967294 Extent Error ext4fs_devread read outside partition 4294967294 Extent Error ext4fs_devread read outside partition 4294967294 Extent Error ext4fs_devread read outside partition 4294967294 Extent Error ext4fs_devread read outside partition 4294967294 Extent Error ext4fs_devread read outside partition 4294967294 Extent Error ext4fs_devread read outside partition 4294967294 Extent Error ext4fs_devread read outside partition 4294967294 Extent Error ext4fs_devread read outside partition 4294967294 Extent Error ext4fs_devread read outside partition 4294967294 Extent Error ext4fs_devread read outside partition 4294967294 Extent Error ext4fs_devread read outside partition 4294967294 Extent Error ext4fs_devread read outside partition 4294967294 Extent Error Extent Error Extent Error Extent Error Extent Error Extent Error Extent Error Extent Error Extent Error Extent Error Extent Error Extent Error Extent Error Extent Error ext4fs_devread read outside partition 4294967294 part_offset is 26624 total_sector is 131072 error: overflow occurs Extent Error part_offset is 26624 total_sector is 131072 error: overflow occurs Extent Error part_offset is 26624 total_sector is 131072 error: overflow occurs Extent Error part_offset is 26624 total_sector is 131072 error: overflow occurs Extent Error part_offset is 26624 total_sector is 131072 error: overflow occurs Extent Error part_offset is 26624 total_sector is 131072 error: overflow occurs Extent Error part_offset is 26624 total_sector is 131072 error: overflow occurs Extent Error part_offset is 26624 total_sector is 131072 error: overflow occurs Extent Error part_offset is 26624 total_sector is 131072 error: overflow occurs Extent Error part_offset is 26624 total_sector is 131072 error: overflow occurs Extent Error Extent Error ext4fs_devread read outside partition 4294967294 part_offset is 26624 total_sector is 131072 error: overflow occurs update journal finished Extent Error ext4fs_devread read outside partition 4294967294 part_offset is 26624 total_sector is 131072 error: overflow occurs DFU complete CRC32: 0x3875a108 DOWNLOAD ... OK Ctrl+C to exit ... resetting ... The old file is still present on the partition. After reverting following patch: Commit: ext4fs: Add ext4 extent cache for read operations SHA1: fc0fc50f38a4d7d0554558076a79dfe8b0d78cd5 I am able to store files on the ext4 partition: USB PHY0 Enable #File System is consistent file found deleting update journal finished File System is consistent update journal finished DFU complete CRC32: 0x3875a108 DOWNLOAD ... OK Ctrl+C to exit ... resetting ... Any ideas how to fix it? -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] part_efi: fix protective mbr struct allocation
Hi Tom,
The calloc() call was allocating space for the sizeof the struct
pointer rather than for the struct contents.
Besides, since this buffer is passed to mmc for writing and some
platforms may use cache, the legacy_mbr struct should be
cache-aligned.
Is there any problem with this patch?
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
Notes:
Changes since V1:
- Cache-align declaration of p_mbr pointer
- Use *p_mbr in sizeof() to match kernel CodingStyle
disk/part_efi.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 5dfaf490c89a..42936e04fb67 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -229,10 +229,10 @@ int test_part_efi(block_dev_desc_t * dev_desc)
*/
static int set_protective_mbr(block_dev_desc_t *dev_desc)
{
- legacy_mbr *p_mbr;
-
/* Setup the Protective MBR */
- p_mbr = calloc(1, sizeof(p_mbr));
+ ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, p_mbr, 1);
+ memset(p_mbr, 0, sizeof(*p_mbr));
+
if (p_mbr == NULL) {
printf(%s: calloc failed!\n, __func__);
return -1;
@@ -247,11 +247,9 @@ static int set_protective_mbr(block_dev_desc_t
*dev_desc) if (dev_desc-block_write(dev_desc-dev, 0, 1, p_mbr) !=
1) { printf(** Can't write to device %d **\n,
dev_desc-dev);
- free(p_mbr);
return -1;
}
- free(p_mbr);
return 0;
}
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] part_efi: fix protective mbr struct allocation
On Mon, Feb 24, 2014 at 04:46:05PM +0100, Lukasz Majewski wrote: Hi Tom, The calloc() call was allocating space for the sizeof the struct pointer rather than for the struct contents. Besides, since this buffer is passed to mmc for writing and some platforms may use cache, the legacy_mbr struct should be cache-aligned. Is there any problem with this patch? Just started re-reviewing this one today in fact, good timing. -- 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 V2] disk:efi: avoid unaligned access on efi partition
Hi Tom,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/19/2014 10:03 AM, Tom Rini wrote:
On 02/19/2014 09:56 AM, Hector Palacios wrote:
On 01/28/2014 01:46 PM, Piotr Wilczek wrote:
This patch fixes part_efi code to avoid unaligned access exception
on some ARM platforms.
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Tom Rini tr...@ti.com
CC: Albert ARIBAUD albert.u.b...@aribaud.net
---
Chnages for V2:
- used put_unaligned to copy value;
- use __aligned to align local array;
disk/part_efi.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 9c33ae7..eb2cd57 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -225,7 +225,7 @@ static int set_protective_mbr(block_dev_desc_t
*dev_desc)
p_mbr-signature = MSDOS_MBR_SIGNATURE;
p_mbr-partition_record[0].sys_ind =
EFI_PMBR_OSTYPE_EFI_GPT; p_mbr-partition_record[0].start_sect =
1;
-p_mbr-partition_record[0].nr_sects = (u32) dev_desc-lba;
+put_unaligned(dev_desc-lba,
p_mbr-partition_record[0].nr_sects);
/* Write MBR sector to the MMC device */
if (dev_desc-block_write(dev_desc-dev, 0, 1, p_mbr) != 1)
{ @@ -361,6 +361,8 @@ int gpt_fill_pte(gpt_header *gpt_h,
gpt_entry *gpt_e, #ifdef CONFIG_PARTITION_UUIDS
char *str_uuid;
#endif
+static efi_guid_t basic_guid __aligned(0x04) =
+PARTITION_BASIC_DATA_GUID;
for (i = 0; i parts; i++) {
/* partition starting lba */
@@ -388,8 +390,7 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry
*gpt_e, gpt_e[i].ending_lba = cpu_to_le64(offset - 1);
/* partition type GUID */
-memcpy(gpt_e[i].partition_type_guid.b,
-PARTITION_BASIC_DATA_GUID, 16);
+gpt_e[i].partition_type_guid = basic_guid;
#ifdef CONFIG_PARTITION_UUIDS
str_uuid = partitions[i].uuid;
Sorry, I sent my tested-by on a different thread:
http://patchwork.ozlabs.org/patch/319649/
Tested on i.MX6 (armv7) custom board and it is working fine without
the -mno-unaligned-access flag.
Tested-by: Hector Palacios hector.palac...@digi.com
Replying to Tom's question in that other thread, regarding the
issue:
Can you give me some steps on how to hit this bug? I believe
it's a bug and I believe we need to fix it, I just want to
investigate a few things while we've got a trigger case right
now. Thanks!
GPT partition table needs to write a protective MBR to sector 0.
The MBR structure has four partition entries (each occupying 16
bytes) at unaligned offsets +1BEh, +1CEh, +1DEh, +1EEh (see [1]).
The structure of each partition entry is defined at
include/part_efi.h
struct partition {
u8 boot_ind;/* 0x80 - active */
u8 head;/* starting head */
u8 sector;/* starting sector */
u8 cyl;/* starting cylinder */
u8 sys_ind;/* What partition type */
u8 end_head;/* end head */
u8 end_sector;/* end sector */
u8 end_cyl;/* end cylinder */
__le32 start_sect;/* starting sector counting from 0 */
__le32 nr_sects;/* nr of sectors in partition */
} __packed;
showing eight 1-byte fields and two 4-byte fields. Since the
offsets for each partition entry are unaligned, the last two
fields (which are 32bit) are unaligned as well. But it's not an
error, it's just the specification of the MBR requires these
fields to be at those exact offsets. So the usage of unaligned
macros for accessing those fields is justified.
Right. I would have sworn I used the GPT commands since we've
dropped -mno-unaligned-access but I'll just go re-test locally now
then, thanks.
Indeed I hadn't re-tested recently enough, thanks.
Have you managed to reproduce the problem on your setup?
I've reproduced it on Trats/Trats2 with ELDK 5.4 (gcc 4.7.2 armv7a
toolchain).
This patch fixes the problem.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTBMxeAAoJENk4IS6UOR1WmKAP/05tEc0Ix4vrbI+WEYv4s26v
Up3Uj1yMHBgHhCmdUops6C6eNjoSX2Z2TzfFx8jQ1YCTrGXO229CSi0U/oXkTWCB
lbdMxQ6IyKh1v+Z4MdEJBq43XxcGMVE8g75Z8Eb/7B74kHRvsLeLGIDMg4A3z1yB
b95HOCaifhSykBELsrqWXpMhJr4KMkn+GT9lNA5umLJdHT/1A2pEglbkZWAu4tAt
ybDpdpXI3Ai8eVg9NuMJXEAcYEGezlg55esFv57gJfLfBPM/e0WLF4MtZYyFJmC/
0SLe46OG19E6JzHMKrHngZbyVSC+Iwzh5Mw6vY40IyVxA6fpXZEZ119AyxLtP4m8
BiWjjRAO65KC6qzRJJYzXKoXSD8Ky+VJ3ATWzUhVSeLQRHeE2am8JsT8ENj5dngC
f93pzqTmOp9LPqOB81dlIbu+R8QoruX0mOQxygNy+7tpTTijLn+UUu23z165j42b
qsBzrAddgFZzUxqfyJLHIr/bvrVqBpEP6BGv2i+5eA6Q/dPHMvVLV3hTZjnxtK52
I6RVfK2R4uTX8mK+yN2HzBdqZhCJqDgxbWYUMuDIkVq7QeY5rtPBaFlOguLPqwx2
+i38rtGj5abZcqr9ASDcmrfIoe1mIAj2NPuJejNLzbwyipyqRVO0CT+GG/FwXLLG
Re: [U-Boot] [PATCH v4 2/2] ventana: Add Gateworks Ventana family support
Hi Stefano, On Wed, Feb 19, 2014 at 10:19 AM, Tom Rini tr...@ti.com wrote: I see now in patchworks that PF100's patch is assigned to Tom - this makes sense because it is not strictly i.MX code. I can apply it myself if Tom agrees. Go ahead and take it, thanks! Will PF100 PMIC support enter into 2014.04 release? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] ventana: Add Gateworks Ventana family support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/24/2014 11:09 AM, Fabio Estevam wrote: Hi Stefano, On Wed, Feb 19, 2014 at 10:19 AM, Tom Rini tr...@ti.com wrote: I see now in patchworks that PF100's patch is assigned to Tom - this makes sense because it is not strictly i.MX code. I can apply it myself if Tom agrees. Go ahead and take it, thanks! Will PF100 PMIC support enter into 2014.04 release? I am agreeable to this, yes. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTC3GoAAoJENk4IS6UOR1W7cEP/A/OfAoco7+OoYc8SPsPOtI0 RfTH36B8WwdWvIW6e61mmapBXm1OW7W9Dbt5/44RktWBE62U3x7+QZXW7BKdUIzM eE5rPNw18jD+FZLTzfM99EFjxuLe1wR/jdicKidRypTrs7KA3RadgAJkKifYIY4S w4swxsX1GlHU92ZOQa1RAU/98trgmx3rI0Qy6JQzUEH6Y5WTjUKphUBL2qr+hVrx DAHF1apnZ5sBSq3ZPE53gNe/6zd/mIN7qn+v5ArLTPeyinszF8BR0ICDnGemCuvX 9kQCb3imCceG5EVmaMqJO6/rQXAWI8tbrgC6E1cudJKs/xwLYmmY8E6PJxvZsT9T 0IA3Bq6sF41ajykfkLmqqsYyqQmpdWpbCHVfy7KeH0/gEi61XzE1aSyKp+B6QD0R HIs9VrEhWn6B8iw73ZKk5ha81Qyl66WE4TKGMQrBk8wMb2Wi3nHjwCVnhItIUsxk vaiZ7YpuPaUJDNpjDrCQJS77BPI+vBp0t+CbVtJbXGplud1NH86IfziJpmk5FVNX Jrh2/SZRiwSIUhi/eIEnuXGGL+Ox6JOvTgJ0rd0Vdk1oVAHpjK3nbsfqqjhgw2HZ cghgNRHFY1DksTx+QIpR3b8OVLclzIDpifuhNrkp5dkAcgehwExY6MDt4x9myfn4 WMQLtloJybOpbvl3uc4/ =i4Ej -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] disk:efi: avoid unaligned access on efi partition
On Mon, Feb 24, 2014 at 04:56:57PM +0100, Lukasz Majewski wrote:
Hi Tom,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/19/2014 10:03 AM, Tom Rini wrote:
On 02/19/2014 09:56 AM, Hector Palacios wrote:
On 01/28/2014 01:46 PM, Piotr Wilczek wrote:
This patch fixes part_efi code to avoid unaligned access exception
on some ARM platforms.
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Tom Rini tr...@ti.com
CC: Albert ARIBAUD albert.u.b...@aribaud.net
---
Chnages for V2:
- used put_unaligned to copy value;
- use __aligned to align local array;
disk/part_efi.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 9c33ae7..eb2cd57 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -225,7 +225,7 @@ static int set_protective_mbr(block_dev_desc_t
*dev_desc)
p_mbr-signature = MSDOS_MBR_SIGNATURE;
p_mbr-partition_record[0].sys_ind =
EFI_PMBR_OSTYPE_EFI_GPT; p_mbr-partition_record[0].start_sect =
1;
-p_mbr-partition_record[0].nr_sects = (u32) dev_desc-lba;
+put_unaligned(dev_desc-lba,
p_mbr-partition_record[0].nr_sects);
/* Write MBR sector to the MMC device */
if (dev_desc-block_write(dev_desc-dev, 0, 1, p_mbr) != 1)
{ @@ -361,6 +361,8 @@ int gpt_fill_pte(gpt_header *gpt_h,
gpt_entry *gpt_e, #ifdef CONFIG_PARTITION_UUIDS
char *str_uuid;
#endif
+static efi_guid_t basic_guid __aligned(0x04) =
+PARTITION_BASIC_DATA_GUID;
for (i = 0; i parts; i++) {
/* partition starting lba */
@@ -388,8 +390,7 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry
*gpt_e, gpt_e[i].ending_lba = cpu_to_le64(offset - 1);
/* partition type GUID */
-memcpy(gpt_e[i].partition_type_guid.b,
-PARTITION_BASIC_DATA_GUID, 16);
+gpt_e[i].partition_type_guid = basic_guid;
#ifdef CONFIG_PARTITION_UUIDS
str_uuid = partitions[i].uuid;
Sorry, I sent my tested-by on a different thread:
http://patchwork.ozlabs.org/patch/319649/
Tested on i.MX6 (armv7) custom board and it is working fine without
the -mno-unaligned-access flag.
Tested-by: Hector Palacios hector.palac...@digi.com
Replying to Tom's question in that other thread, regarding the
issue:
Can you give me some steps on how to hit this bug? I believe
it's a bug and I believe we need to fix it, I just want to
investigate a few things while we've got a trigger case right
now. Thanks!
GPT partition table needs to write a protective MBR to sector 0.
The MBR structure has four partition entries (each occupying 16
bytes) at unaligned offsets +1BEh, +1CEh, +1DEh, +1EEh (see [1]).
The structure of each partition entry is defined at
include/part_efi.h
struct partition {
u8 boot_ind;/* 0x80 - active */
u8 head;/* starting head */
u8 sector;/* starting sector */
u8 cyl;/* starting cylinder */
u8 sys_ind;/* What partition type */
u8 end_head;/* end head */
u8 end_sector;/* end sector */
u8 end_cyl;/* end cylinder */
__le32 start_sect;/* starting sector counting from 0 */
__le32 nr_sects;/* nr of sectors in partition */
} __packed;
showing eight 1-byte fields and two 4-byte fields. Since the
offsets for each partition entry are unaligned, the last two
fields (which are 32bit) are unaligned as well. But it's not an
error, it's just the specification of the MBR requires these
fields to be at those exact offsets. So the usage of unaligned
macros for accessing those fields is justified.
Right. I would have sworn I used the GPT commands since we've
dropped -mno-unaligned-access but I'll just go re-test locally now
then, thanks.
Indeed I hadn't re-tested recently enough, thanks.
Have you managed to reproduce the problem on your setup?
I've reproduced it on Trats/Trats2 with ELDK 5.4 (gcc 4.7.2 armv7a
toolchain).
This patch fixes the problem.
Yes, which is why I've renewed my effort to correct our behavior with
respect to gcc generating unaligned access faults where we don't need
them, and this shall be resolved for v2014.04-rc2.
--
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] [Regression][ext4] Regression at EXT4 filesystem code
Hi, On 24.02.2014 16:13, ext Lukasz Majewski wrote: Dear All, In the newest master u-boot (SHA1: 1674df60d17e0e72396c961d5390bb62b184ad95) I've found a regression with writing to EXT4 file system: Writing uImage to ext4 partition - created with Debian's mkfs.ext4 /dev/sdd2 (size 58M) dfu-util -R -a2 -D arch/arm/boot/uImage uImage size - 4.8 MiB GADGET DRIVER: usb_dnl_dfu USB PHY0 Enable #Extent Error ext4fs_devread read outside partition 4294967294 Extent Error Ugh ... It's pretty stupid, but my patch is completely ignoring the write path. The error occurs because in read_allocated_block() I'm trying to use the extent cache, but this extent cache is only built in ext4fs_read_file(). After reverting following patch: Commit: ext4fs: Add ext4 extent cache for read operations SHA1: fc0fc50f38a4d7d0554558076a79dfe8b0d78cd5 I am able to store files on the ext4 partition: USB PHY0 Enable #File System is consistent file found deleting update journal finished File System is consistent update journal finished DFU complete CRC32: 0x3875a108 DOWNLOAD ... OK Ctrl+C to exit ... resetting ... Any ideas how to fix it? I guess the best solution for the moment is to revert the patch and I'll try to come up with an updated version which doesn't break the write functionality. Sorry about this. Regards, Ionut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/t104xrdb: Update DDR initialization related settings
On 02/21/2014 03:27 AM, Priyanka Jain wrote:
@@ -62,11 +60,18 @@ static const struct board_specific_parameters udimm0[] = {
* num| hi| rank| clk| wrlvl | wrlvl | wrlvl | cpo |wrdata|2T
* ranks| mhz| GB |adjst| start | ctl2| ctl3 | |delay |
*/
- {2, 1066, 4, 8, 4, 0x05070609, 0x08090a08, 0xff,2, 0},
- {2, 1350, 4, 4, 8, 0x0809090b, 0x0c0c0d0a, 0xff,2, 0},
- {2, 1350, 0, 5, 7, 0x0709090b, 0x0c0c0d09, 0xff,2, 0},
- {2, 1666, 4, 4, 8, 0x080a0a0d, 0x0d10100b, 0xff,2, 0},
- {2, 1666, 0, 5, 7, 0x080a0a0c, 0x0d0d0e0a, 0xff,2, 0},
+ {2, 833, 4, 4, 6, 0x06060607, 0x08080807, 0xff,2, 0},
+ {2, 833, 0, 4, 6, 0x06060607, 0x08080807, 0xff,2, 0},
+ {2, 1350, 4, 4, 7, 0x0708080A, 0x0A0B0C09, 0xff,2, 0},
+ {2, 1350, 0, 4, 7, 0x0708080A, 0x0A0B0C09, 0xff,2, 0},
+ {2, 1666, 4, 4, 7, 0x0808090B, 0x0C0D0E0A, 0xff,2, 0},
+ {2, 1666, 0, 4, 7, 0x0808090B, 0x0C0D0E0A, 0xff,2, 0},
+ {1, 833, 4, 4, 6, 0x06060607, 0x08080807, 0xff,2, 0},
+ {1, 833, 0, 4, 6, 0x06060607, 0x08080807, 0xff,2, 0},
+ {1, 1350, 4, 4, 7, 0x0708080A, 0x0A0B0C09, 0xff,2, 0},
+ {1, 1350, 0, 4, 7, 0x0708080A, 0x0A0B0C09, 0xff,2, 0},
+ {1, 1666, 4, 4, 7, 0x0808090B, 0x0C0D0E0A, 0xff,2, 0},
+ {1, 1666, 0, 4, 7, 0x0808090B, 0x0C0D0E0A, 0xff,2, 0},
{}
};
As reviewed internally, please remove the cpo, wrdata_delay, and 2T, because
they are not used any more.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/t104xRDB:remove CONFIG_SYS_FLASH_USE_BUFFER_WRITE for NOR
On 02/20/2014 03:25 AM, Prabhakar Kushwaha wrote: Micron NOR flash present on T1040RDB and T1042RDB_PI do not support write read command running at same time. CONFIG_SYS_FLASH_USE_BUFFER_WRITE reads NOR flash before performing write. So, remove CONFIG_SYS_FLASH_USE_BUFFER_WRITE Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com As reviewed internally, please find the root cause of your issue. Removing CONFIG_SYS_FLASH_USE_BUFFER_WRITE is not the right solution. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: delete unused macro CONFIG_ARCH_DEVICE_TREE
On 02/24/2014 05:45 AM, Masahiro Yamada wrote: Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Commit description? Acked-by: Stephen Warren swar...@nvidia.com FWIW, this config option was used prior to: 8ad723acd7e9 dts/Makefile: don't define ARCH_CPU_DTS, BOARD_DTS 6e8e0311ccc7 dt: don't use ARCH_CPU_DTS ... 6c5be646b47e Tegra: fdt: Change /include/ to #include for C preprocessor I evidently forgot to remove some of the places where Exynos boards defined CONFIG_ARCH_DEVICE_TREE, and when sending the Tegra124 patches recently, didn't notice that I didn't need the file that defined it there. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot.dtb vs. dts/dt.dtb output filename, also O= vs BUILD_DIR=
Masahiro, Prior the to kbuild conversion, U-Boot used to produce file u-boot.dtb in the root of the object tree. Now it doesn't, but I think puts the same file in dts/dt.dtb instead. Was this a deliberate change? We have some flashing utilities that build U-Boot, then copy this result file. This utility no longer works because the file it's looking for no longer exists. I'd rather fix the U-Boot build process so its output filenames don't change, than fix the utility to look for a variety of different output filenames. Are you OK with a patch reverting the output filename change? Related, I also found that pre-Kbuild, I could make BUILD_DIR=..., but now I have to make O= That's also an external change in behaviour. Was that intentional? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kbuild: fix SPL link bug when USE_PRIVATE_LIBGCC is yes
On 02/24/2014 04:44 AM, Masahiro Yamada wrote: Commit 6825a95 (kbuild: use Linux Kernel build scripts) changed the behavior of linkage when USE_PRIAVATE_LIBGCC is defined as yes. (It dropped arch/arm/lib/eabi_compat.o from the target library.) Affected boards are all Tegra boards. This commit gets back the same behavior as before Kbuild series. Tested-by: Stephen Warren swar...@nvidia.com ... although interestingly, at least with the Ubuntu 12.10 ARM cross-compiler, the resultant U-Boot works fine with or without this patch. I'd have expected it to fail without this patch since it sounds like USE_PRIVATE_LIBGCC might not be honored correctly, but perhaps the linker cmdline order works out such that the custom libgcc happens to be picked up anyway, just not in the way intended. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] usb: eth: introduce support for Moschip USB ethernet
On Sunday, February 23, 2014 at 09:16:20 PM, Gerhard Sittig wrote:
On Mon, Feb 17, 2014 at 21:57 +0100, Marek Vasut wrote:
On Monday, February 17, 2014 at 08:35:23 PM, Gerhard Sittig wrote:
[...]
+int mcs7830_eth_get_info(struct usb_device *dev, struct ueth_data *ss,
+ struct eth_device *eth)
+{
+ debug(%s()\n, __func__);
+ if (!eth) {
+ debug(%s: missing parameter.\n, __func__);
+ return 0;
+ }
+
+ snprintf(eth-name, sizeof(eth-name), %s%d,
+ MCS7830_BASE_NAME, mcs7830_iface_idx++);
+ eth-init = mcs7830_init;
+ eth-send = mcs7830_send;
+ eth-recv = mcs7830_recv;
+ eth-halt = mcs7830_halt;
+ eth-write_hwaddr = mcs7830_write_mac;
+ eth-priv = ss;
+
+ if (mcs7830_basic_reset(ss))
+ return 0;
+
+#ifdef DEBUG
+ (void)mcs7830_read_config(eth);
So this is debug-only function? You might want to put the entire function
into #ifdef DEBUG and then have an #else , where you define the function
as an empty one. The GCC shall handle the rest then as well, but you
won't have this ugly ifdef in a function.
I thought about this for a while.
Usually you'd expect separate control and status registers in
hardware. Where you write to control, and read back from status.
Here those two aspects appear to have been mixed into one
config register, and only in hindsight the reading became
unused. It's not so much an intent, but more of a byproduct.
During development (before the driver became operational), I
could not tell whether I had to read-modify-write that config
register. Following the Linux driver's approach, currently only
fixed values get written to the adapter and nothing gets read
back.
Later the shadow in the driver's private data was introduced,
such that updates neither need to read back what was written
before. And since neither multicast nor promiscuous mode may
apply to bootloader operation, even those updates may never need
not occur.
In the meantime I'd even tend to support the removal of the
config register read routine. Adding code just in case is a
programmer's sin that may not be acceptable in U-Boot, since the
cost outweights the benefit.
The current implementation (v3, with maybe unused decoration)
might be acceptable. But should feedback suggest that v4 is
needed, I will remove that routine as well.
If you feel like removing the routine, then please remove it .
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 03/14] yaffs: Remove private list implementation
On Monday, February 17, 2014 at 11:06:37 PM, Simon Glass wrote:
U-Boot already has a list implementation, and files which include both
that and the yaffs implementation will get errors:
In file included from ydirectenv.h:80:0,
from yportenv.h:81,
from yaffs_guts.h:19,
from yaffs_allocator.h:19,
from yaffs_allocator.c:14:
yaffs_list.h:32:8: error: redefinition of ‘struct list_head’
struct list_head {
^
Remove the yaffs implementation.
Signed-off-by: Simon Glass s...@chromium.org
---
Tom, can you please pick this up separatelly ?
Thanks
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/22/2014 01:20 AM, Dennis Gilmore wrote:
On Wed, 19 Feb 2014 10:40:15 -0700 Stephen Warren swar...@wwwdotorg.org
wrote:
On 02/17/2014 10:56 AM, Dennis Gilmore wrote:
diff --git a/include/config_distro_bootcmd.h
+#define BOOTCMDS_COMMON \
+ rootpart=1\0 \
We should really stop hard-coding that. I meant to (but evidently
never got around to) re-write the commands so that they could
automatically determine which partition to use, based on the MBR
bootable flag or GPT partition flags.
Still, we can probably make that enhancement separately later.
I fully agree, we should be able to work it out later. I also renamed
it to bootpart since it is where we will boot from, which may or may
not be the root filesystem
Just as some history, when I first wrote these boot scripts for Tegra, I
was actually using that variable both inside the environment scripts to
find/load boot.scr, and within boot.scr to set the kernel root=
command-line option. More recently, I've moved to using root=PARTUUID=
or root=UUID= on the kernel command-line, so rootpart has become less
relevant, and indeed renaming it bootpart does make a lot more sense, as
you say.
+ scan_boot=
\
+ echo Scanning ${devtype} ${devnum}...;
\
+ for prefix in ${boot_prefixes}; do
\
+ run sysboot_boot;
\
+ run envimport;
\
+ run script_boot;
\
This isn't quite right for the Raspberry Pi at least.
What I wanted was for uEnv.txt to *always* be loaded from SD card
before any other boot activity. The SD card is known to exist on this
platform, since it's the only place the SoC's boot ROM can load the
initial binary firmware from.
I know some distros use commands in uEnv.txt to boot, or at the least
they set variables and load a boot.scr I was trying to make sure we
cover those people. The definition of what uEnv.txt is and how it
should be used is pretty murky to me. I have seen it used in a few
different ways. I know some people really want them. So probably best
to work out a better way to support it.
http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-uEnv.txtbasedbootscript
for instance specifies all the boot commands in uEnv.txt really I would
rather people just use a extlinux.conf file, I just do not want to take
away the option to use something people see as valuable.
I'd suggest not touching uEnv.txt in config_distro_bootcmd.h, since it's
really not a part of the new standard we want to create. Instead, have
each board define CONFIG_PREBOOT to load it if they want it. I assume
that a very small number of boards will need uEnv.txt once we've
switched to this new scheme; just those that have nowhere to store a
persistent environment.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/3] usb: tegra: combine header file
On 02/22/2014 01:53 PM, Stefan Agner wrote: Combine the Tegra USB header file into one header file for all SoCs. Use ifdef to account for the difference, especially Tegra20 is quite different from newer SoCs. This avoids duplication especially between Tegra30 and newer devices. Reviewed-by: Stephen Warren swar...@nvidia.com Signed-off-by: Stefan Agner ste...@agner.ch --- arch/arm/include/asm/arch-tegra/usb.h| 214 +++ arch/arm/include/asm/arch-tegra114/usb.h | 156 -- arch/arm/include/asm/arch-tegra20/usb.h | 160 --- arch/arm/include/asm/arch-tegra30/usb.h | 168 board/nvidia/common/board.c | 1 - drivers/usb/host/ehci-tegra.c| 1 - Are you planning on sending a later patch which removes arch/arm/include/asm/arch-tegra124/usb.h too? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 03/14] yaffs: Remove private list implementation
Hi Marek,
On 24 February 2014 09:54, Marek Vasut ma...@denx.de wrote:
On Monday, February 17, 2014 at 11:06:37 PM, Simon Glass wrote:
U-Boot already has a list implementation, and files which include both
that and the yaffs implementation will get errors:
In file included from ydirectenv.h:80:0,
from yportenv.h:81,
from yaffs_guts.h:19,
from yaffs_allocator.h:19,
from yaffs_allocator.c:14:
yaffs_list.h:32:8: error: redefinition of ‘struct list_head’
struct list_head {
^
Remove the yaffs implementation.
Signed-off-by: Simon Glass s...@chromium.org
---
Tom, can you please pick this up separatelly ?
I could issue a pull request for the series if that would help Tom.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/3] mpc85xx: Add deep sleep framework support
On Mon, 2014-02-24 at 15:47 +0800, Tang Yuantian-B29983 wrote:
On 2014/2/15 星期六 6:21, Scott Wood wrote:
On Thu, 2014-02-13 at 01:05 -0600, Tang Yuantian-B29983 wrote:
Thanks for your review. Please see the reply inline.
Thanks,
Yuantian
-Original Message-
From: Wood Scott-B07421
Sent: 2014年2月13日 星期四 8:44
To: Tang Yuantian-B29983
Cc: Sun York-R58495; Wood Scott-B07421; Li Yang-Leo-R58472;
t...@theia.denx.de; u-boot@lists.denx.de; Kushwaha Prabhakar-B32579; Jin
Zhengxiong-R64188
Subject: Re: [U-Boot,2/3] mpc85xx: Add deep sleep framework support
On Sun, Jan 26, 2014 at 02:00:40PM +0800, tang yuantian wrote:
From: Tang Yuantian yuantian.t...@freescale.com
When system wakes up from warm reset, control is passed to the primary
core that starts executing uboot. After re-initialized some IP blocks,
like DDRC, kernel will take responsibility to continue to restore
environment it leaves before.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
Is this for some specific mpc85xx chip (e.g. T1040)? I'm pretty sure
this isn't necessary for deep sleep on mpc8536, for example.
Currently, it is used by t1040. But we want it to be more general so that
It can be used by later new chips.
But the mechanism is not the same for all mpc85xx derivatives. You'll
need a more specific name.
OK, will name it as t104x
+#ifdef CONFIG_DEEP_SLEEP
CONFIG symbols need to be documented in README...
Where should I add this README?
Under 85xx CPU Options in the top-level README.
Thanks.
+/* disable the console if boot from warm reset */
+if (in_be32(gur-scrtsr[0]) (1 3))
+gd-flags |=
+GD_FLG_SILENT | GD_FLG_WARM_BOOT |
GD_FLG_DISABLE_CONSOLE; #endif
...and it should probably be a more specific CONFIG_SYS symbol that
indicates the presence of this guts bit.
where should I put this CONFIG_SYS_'s definition?
Under 85xx CPU Options in the top-level README. :-)
diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c
b/arch/powerpc/cpu/mpc85xx/fdt.c index 33bc900..b3b9250 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -24,6 +24,9 @@ DECLARE_GLOBAL_DATA_PTR; extern void
ft_qe_setup(void *blob); extern void ft_fixup_num_cores(void *blob);
extern void ft_srio_setup(void *blob);
+#ifdef CONFIG_DEEP_SLEEP
+extern ulong __bss_end;
+#endif
Don't ifdef declarations.
#ifdef CONFIG_MP
#include mp.h
@@ -35,6 +38,9 @@ void ft_fixup_cpu(void *blob, u64 memory_limit)
u32 bootpg = determine_mp_bootpg(NULL);
u32 id = get_my_id();
const char *enable_method;
+#ifdef CONFIG_DEEP_SLEEP
+ulong len;
+#endif
off = fdt_node_offset_by_prop_value(blob, -1, device_type,
cpu,
4);
while (off != -FDT_ERR_NOTFOUND) {
@@ -77,6 +83,25 @@ void ft_fixup_cpu(void *blob, u64 memory_limit)
device_type, cpu, 4);
}
+#ifdef CONFIG_DEEP_SLEEP
+/*
+ * reserve the memory space for warm reset.
+ * This space will be re-used next time when boot from deep
sleep.
+ * The space includes bd_t, gd_t, stack and uboot image.
+ * Reserve 1K for stack.
+ */
+len = sizeof(bd_t) + sizeof(gd_t) + (1 10);
+/* round up to 4K */
+len = (len + (4096 - 1)) ~(4096 - 1);
+
+off = fdt_add_mem_rsv(blob, gd-relocaddr - len,
+len + ((ulong)__bss_end - gd-relocaddr));
+if (off 0)
+printf(Failed to reserve memory for warm reset: %s\n,
+fdt_strerror(off));
+
+#endif
Why do you need to reserve memory for this? We didn't need to for deep
sleep on MPC8313ERDB, which also goes through U-Boot on wake. On
MPC8313ERDB we transfer control to the kernel before relocating, so U-
Boot never touches DDR. bd_t, gd_t, and the stack should be in locked
L1 cache, and the u-boot image should be in flash (or locked CPC if this
is not a NOR flash boot).
In deep sleep many IP blocks are powered off like DDRC, LIODN, cpu. These
IPs
are re-initialized after relocating.
So, we must jump to kernel after relocating.
The DDR controller is initialized before relocating -- and of course the
CPU is powered off on MPC8313ERDB deep sleep as well.
LIODNs are a new concern for deep sleep, but that doesn't mean we should
go through a bunch of unrelated code to get there. Refactor the LIODN
code to be usable before relocation, and not be tied to fdt fixups.
There are other IP blocks that need to be re-initialized, like SerDes,
SMP, PCIe and
a lot of Errata. I don't want to refactor one by one.
Besides, coding in this way will not change the current execute flow.
Changing the execution flow is better than adding a bunch of special
cases to the current execution
Re: [U-Boot] [U-Boot, 2/3] mpc85xx: Add deep sleep framework support
On Mon, 2014-02-24 at 14:44 +0800, Tang Yuantian-B29983 wrote: On 2014/2/18 星期二 3:18, Scott Wood wrote: On Sun, 2014-02-16 at 21:35 -0600, Tang Yuantian-B29983 wrote: -Original Message- From: Wood Scott-B07421 To: Tang Yuantian-B29983 Cc: Sun York-R58495; Li Yang-Leo-R58472; u-boot@lists.denx.de; Kushwaha Prabhakar-B32579; Jin Zhengxiong-R64188 Subject: Re: [U-Boot,2/3] mpc85xx: Add deep sleep framework support On Thu, 2014-02-13 at 02:12 -0600, Tang Yuantian-B29983 wrote: Use an I/O accessor. In_be64?? No such function. Why do you need in_be64() rather than two in_be32()s? Avoid ECC error. Although, according to my test, in_be32() works too. Why would you get an ECC error? -Scott DDR operation is always in 64bits. if writing a 32bits to memory, you need to read a 32bits first, and combine it to form a 64bits. when the new 64bits is written to memory, ECC occurs. I was required to do so by hardware team. U-Boot on PPC is a 32-bit binary (even on 64-bit hardware), so the compiler is already turning that into two 32-bit writes. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] socfpga: Add socfpga preloader signing to mkimage
Hello Wolfgang On Monday 24 February 2014 19:48:36 Wolfgang Denk wrote: Dear Charles, In message 1393194939-29786-1-git-send-email-cdhmann...@gmail.com you wrote: Like many platforms, the Altera socfpga platform requires that the preloader be signed in a certain way or the built-in boot ROM will not boot the code. This change automatically creates an appropriately signed preloader from an SPL image. Signed-off-by: Charles Manning cdhmann...@gmail.com --- Changes for v3: - Fix some coding style issues. - Move from a standalone tool to the mkimgae framework. Changes for v4: - Fix more coding style issues. - Fix typos in Makefile. - Rebase on master (previous version was not on master, but on a working socfpga branch). There may be perfectly valid reasons why you might decide to ingore a review comments - sch comments may be wrong, too, after all. But in such a case it is always a good idea to provide feedback to the reviewer why you decided not to follow his advice. Otherwise he might think you just missed or ignored the comment. I am sorry, I must have missed some of the comments. I have intended to implement them all, except one by Gerhard. And this is what is happeneing (again) in your patch... diff --git a/spl/Makefile b/spl/Makefile index bf98024..90faaa6 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -181,6 +181,14 @@ $(objtree)/SPL : $(obj)/u-boot-spl.bin ALL-y += $(obj)/$(SPL_BIN).bin +$(OBJTREE)/socfpga-signed-preloader.bin: $(obj)/u-boot-spl.bin + $(OBJTREE)/tools/mkimage -T socfpgaimage -d $ $@ + + One blank line is sufficient. Ok, a blank line. I can delete that. I asked before: socfpga-signed-preloader.bin is a terribly long name. Can we find a better one? +ifdef CONFIG_SOCFPGA +ALL-y += $(OBJTREE)/socfpga-signed-preloader.bin +endif I asked before: Can we not use ALL-$(CONFIG_SOCFPGA) and avoid the ifdef ? I am sorry, I had developed this code in a different (older) branch where socfpga actually works. It is broken in master. This I shall fix. + * Reference doc http://www.altera.com.cn/literature/hb/cyclone-v/cv_5400A.pdf + * Note this doc is not entirely accurate. I aseked before: Would you care to explain the errors in the document that might cause problems to the reader? Noting that something contains errors without mentioning what these are is really not helpful. Ok, I shall mention the errors pertinent to the code. Other errors I shall ignore. + * This uses the CRC32 calc out of the well known Apple + * crc32.c code. CRC32 algorithms do not produce the same results. + * We need this one. Sorry about the coade bloat. Both Gerhard and me asked before: Why exactly do we need another implementation of CRC32. We already have some - why cannot we use these? Well I would have thought that obvious from the comment I put in the code, but email is an imperfect communications medium, so I shall explain in further detail here. As I am sure you are aware, there are many different crc32 calculations. Indeed Wikipedia lists 5 and there are most likely others. Even when they use the same polynomial, they give differences when you stuff the bits through the shift register lsb-first or msb-first. Now from what I see looking through the u-boot lib/ directory u-boot provides just one crc32 version - Adler (and a bit flipped version thereof for use by jffs2). If there are others I did not see them. Now as I expect you are aware, the purpose of a signer is to massage the code so that it is in a form that the boot ROM accepts. One of those criteria is that the crc in the code matches the crc the boot ROM is expecting. If not, the boot ROM refuses to execute the code. It would be nice to use the Adler code. Indeed this is my favourite crc. However, this is not what the boot ROM wants. The boot ROM does not enter into rational discussions, so we must, unfortunately, bow to its whims. If it wants a different CRC calculation then we must supply it. I did much experimentation to find the crc that worked. I tried the zlib crc - no luck. I tried different many things until I found something that worked. + * Copyright for the CRC code: + * + * COPYRIGHT (C) 1986 Gary S. Brown. You may use this program, or + * code or tables extracted from it, as desired without restriction. I asked before: Please provide _exact_ reference. See http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sig n for instructions how to do this. As it was, I had attributed this incorrectly. This is a file I generated myself, though I had used this as a reference during my research. The values will look the same as some other code floating out there, but that is because that is the way things have to be. I shall fix this wen I make another file. I also commented before: If you really need this copied code (i. e. you canot use one of the
Re: [U-Boot] u-boot.dtb vs. dts/dt.dtb output filename, also O= vs BUILD_DIR=
On Mon, Feb 24, 2014 at 10:44:04AM -0700, Stephen Warren wrote: Masahiro, Prior the to kbuild conversion, U-Boot used to produce file u-boot.dtb in the root of the object tree. Now it doesn't, but I think puts the same file in dts/dt.dtb instead. Was this a deliberate change? Not exactly, no. There's a patch to restore this, which depends on the 15 part follow-up series. I'll be re-reviewing that shortly (got another batch of changes atm) and making sure really everyone is OK there, and pulling it in along with some other stuff. Temporary glitch, just don't support v2014.04-rc1 (-rc2 shall be fixed) in the external tools. Thanks/sorry! -- 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 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On Mon, Feb 24, 2014 at 11:40:02AM -0700, Stephen Warren wrote: On 02/22/2014 01:20 AM, Dennis Gilmore wrote: [snip] I fully agree, we should be able to work it out later. I also renamed it to bootpart since it is where we will boot from, which may or may not be the root filesystem Just as some history, when I first wrote these boot scripts for Tegra, I was actually using that variable both inside the environment scripts to find/load boot.scr, and within boot.scr to set the kernel root= command-line option. More recently, I've moved to using root=PARTUUID= or root=UUID= on the kernel command-line, so rootpart has become less relevant, and indeed renaming it bootpart does make a lot more sense, as you say. For distro, this, oh my yes, this, is pretty nearly a must. This dislodged something in my brain which reminded me of a pain point we have on some TI parts, which is which MMC device will the kernel have as mmc0 vs mmc1 as because of regulartors, deferred probing and all of that, it's board design dependent. But passing in root=UUID= like commodity distros have done for ages makes this irrelevant. We need to do this such that either can be used, probably as root= being something that's given to us, rather than assumed by us. But I would be sad if everyone stopped using root=UUID= and started using /dev/mmcblk* names in the commodity distro area. -- 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 v4] socfpga: Add socfpga preloader signing to mkimage
Hello Wolfgang I have some further observations to my last email... Your input would be vastly appreciated. Please see below. On Tue, Feb 25, 2014 at 8:18 AM, Charles Manning cdhmann...@gmail.comwrote: Hello Wolfgang On Monday 24 February 2014 19:48:36 Wolfgang Denk wrote: Dear Charles, In message 1393194939-29786-1-git-send-email-cdhmann...@gmail.com you wrote: Like many platforms, the Altera socfpga platform requires that the preloader be signed in a certain way or the built-in boot ROM will not boot the code. This change automatically creates an appropriately signed preloader from an SPL image. Signed-off-by: Charles Manning cdhmann...@gmail.com --- Changes for v3: - Fix some coding style issues. - Move from a standalone tool to the mkimgae framework. Changes for v4: - Fix more coding style issues. - Fix typos in Makefile. - Rebase on master (previous version was not on master, but on a working socfpga branch). There may be perfectly valid reasons why you might decide to ingore a review comments - sch comments may be wrong, too, after all. But in such a case it is always a good idea to provide feedback to the reviewer why you decided not to follow his advice. Otherwise he might think you just missed or ignored the comment. I am sorry, I must have missed some of the comments. I have intended to implement them all, except one by Gerhard. And this is what is happeneing (again) in your patch... diff --git a/spl/Makefile b/spl/Makefile index bf98024..90faaa6 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -181,6 +181,14 @@ $(objtree)/SPL : $(obj)/u-boot-spl.bin ALL-y += $(obj)/$(SPL_BIN).bin +$(OBJTREE)/socfpga-signed-preloader.bin: $(obj)/u-boot-spl.bin + $(OBJTREE)/tools/mkimage -T socfpgaimage -d $ $@ + + One blank line is sufficient. Ok, a blank line. I can delete that. I asked before: socfpga-signed-preloader.bin is a terribly long name. Can we find a better one? +ifdef CONFIG_SOCFPGA +ALL-y += $(OBJTREE)/socfpga-signed-preloader.bin +endif I asked before: Can we not use ALL-$(CONFIG_SOCFPGA) and avoid the ifdef ? I am sorry, I had developed this code in a different (older) branch where socfpga actually works. It is broken in master. This I shall fix. I can certainly avoid the ifdef, but there is already another one three lines down for the SAMSUNG case: ifdef CONFIG_SOCFPGA ALL-y += $(OBJTREE)/socfpga-signed-preloader.bin endif ifdef CONFIG_SAMSUNG ALL-y+= $(obj)/$(BOARD)-spl.bin endif It seems odd to me that you would want different conventions in the same Makefile, but if that is what you want then that is what you will get. + * Reference doc http://www.altera.com.cn/literature/hb/cyclone-v/cv_5400A.pdf + * Note this doc is not entirely accurate. I aseked before: Would you care to explain the errors in the document that might cause problems to the reader? Noting that something contains errors without mentioning what these are is really not helpful. Ok, I shall mention the errors pertinent to the code. Other errors I shall ignore. + * This uses the CRC32 calc out of the well known Apple + * crc32.c code. CRC32 algorithms do not produce the same results. + * We need this one. Sorry about the coade bloat. Both Gerhard and me asked before: Why exactly do we need another implementation of CRC32. We already have some - why cannot we use these? Well I would have thought that obvious from the comment I put in the code, but email is an imperfect communications medium, so I shall explain in further detail here. As I am sure you are aware, there are many different crc32 calculations. Indeed Wikipedia lists 5 and there are most likely others. Even when they use the same polynomial, they give differences when you stuff the bits through the shift register lsb-first or msb-first. Now from what I see looking through the u-boot lib/ directory u-boot provides just one crc32 version - Adler (and a bit flipped version thereof for use by jffs2). If there are others I did not see them. Now as I expect you are aware, the purpose of a signer is to massage the code so that it is in a form that the boot ROM accepts. One of those criteria is that the crc in the code matches the crc the boot ROM is expecting. If not, the boot ROM refuses to execute the code. It would be nice to use the Adler code. Indeed this is my favourite crc. However, this is not what the boot ROM wants. The boot ROM does not enter into rational discussions, so we must, unfortunately, bow to its whims. If it wants a different CRC calculation then we must supply it. I did much experimentation to find the crc that worked. I tried the zlib crc - no luck. I tried different many things until I found something that worked. The actual table values I am using are also found in
Re: [U-Boot] [PATCH v3] powerpc/t2081qds: Add T2081 QDS board support
On 02/20/2014 09:16 PM, Shengzhou Liu wrote: T2081 QDS is a high-performance computing evaluation, development and test platform supporting the T2081 QorIQ Power Architecture processor. T2081QDS board Overview --- - T2081 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz - 2MB shared L2 and 512KB L3 CoreNet platform cache (CPC) - CoreNet fabric supporting coherent and noncoherent transactions with prioritization and bandwidth allocation - 32-/64-bit DDR3/DDR3LP SDRAM memory controller with ECC and interleaving - Ethernet interfaces: - Two on-board 10M/100M/1G bps RGMII ports - Two 10Gbps XFI with on-board SFP+ cage - 1Gbps/2.5Gbps SGMII Riser card - 10Gbps XAUI Riser card - Accelerator: - DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC - SerDes: - 8 lanes up to 10.3125GHz - Supports SGMII, HiGig, XFI, XAUI and Aurora debug, - IFC: - 512MB NOR Flash, 2GB NAND Flash, PromJet debug port and Qixis FPGA - eSPI: - Three SPI flash (16MB N25Q128A + 16MB EN25S64 + 512KB SST25WF040) - USB: - Two USB2.0 ports with internal PHY (one Type-A + one micro Type mini-AB) - PCIe: - Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0 with SR-IOV) - eSDHC: - Supports various SD/SDHC/SDXC/eMMC devices with adapter cards and voltage translators - I2C: - Four I2C controllers. - UART: - Dual 4-pins UART serial ports Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- v3: add fixup devicetree for t2081qds. v2: some update for serdes and network configuration. board/freescale/t2080qds/Makefile | 12 - board/freescale/t2080qds/ddr.c| 119 - board/freescale/t2080qds/ddr.h| 72 --- board/freescale/t2080qds/eth_t2080qds.c | 517 --- board/freescale/t2080qds/law.c| 34 -- board/freescale/t2080qds/pci.c| 23 - board/freescale/t2080qds/t2080_pbi.cfg| 41 -- board/freescale/t2080qds/t2080_rcw.cfg| 8 - board/freescale/t2080qds/t2080qds.c | 378 -- board/freescale/t2080qds/t2080qds.h | 13 - board/freescale/t2080qds/t2080qds_qixis.h | 47 -- board/freescale/t2080qds/tlb.c| 146 -- board/freescale/t208xqds/Makefile | 14 + board/freescale/t208xqds/ddr.c| 119 + board/freescale/t208xqds/ddr.h| 72 +++ board/freescale/t208xqds/eth_t208xqds.c | 648 board/freescale/t208xqds/law.c| 34 ++ board/freescale/t208xqds/pci.c| 23 + board/freescale/t208xqds/t2080_rcw.cfg| 8 + board/freescale/t208xqds/t2081_rcw.cfg| 8 + board/freescale/t208xqds/t208x_pbi.cfg| 41 ++ board/freescale/t208xqds/t208xqds.c | 459 + board/freescale/t208xqds/t208xqds.h | 13 + board/freescale/t208xqds/t208xqds_qixis.h | 49 ++ board/freescale/t208xqds/tlb.c| 146 ++ boards.cfg| 15 +- include/configs/T2080QDS.h| 804 - include/configs/T208xQDS.h| 817 ++ 28 files changed, 2461 insertions(+), 2219 deletions(-) delete mode 100644 board/freescale/t2080qds/Makefile delete mode 100644 board/freescale/t2080qds/ddr.c delete mode 100644 board/freescale/t2080qds/ddr.h delete mode 100644 board/freescale/t2080qds/eth_t2080qds.c delete mode 100644 board/freescale/t2080qds/law.c delete mode 100644 board/freescale/t2080qds/pci.c delete mode 100644 board/freescale/t2080qds/t2080_pbi.cfg delete mode 100644 board/freescale/t2080qds/t2080_rcw.cfg delete mode 100644 board/freescale/t2080qds/t2080qds.c delete mode 100644 board/freescale/t2080qds/t2080qds.h delete mode 100644 board/freescale/t2080qds/t2080qds_qixis.h delete mode 100644 board/freescale/t2080qds/tlb.c create mode 100644 board/freescale/t208xqds/Makefile create mode 100644 board/freescale/t208xqds/ddr.c create mode 100644 board/freescale/t208xqds/ddr.h create mode 100644 board/freescale/t208xqds/eth_t208xqds.c create mode 100644 board/freescale/t208xqds/law.c create mode 100644 board/freescale/t208xqds/pci.c create mode 100644 board/freescale/t208xqds/t2080_rcw.cfg create mode 100644 board/freescale/t208xqds/t2081_rcw.cfg create mode 100644 board/freescale/t208xqds/t208x_pbi.cfg create mode 100644 board/freescale/t208xqds/t208xqds.c create mode 100644 board/freescale/t208xqds/t208xqds.h create mode 100644 board/freescale/t208xqds/t208xqds_qixis.h create mode 100644 board/freescale/t208xqds/tlb.c delete mode 100644 include/configs/T2080QDS.h create mode 100644 include/configs/T208xQDS.h Next time, please format the patch with this command git format-patch -M -C --find-copies-harder It will generate a patch with detection of moving and copies code, so your change set will be much smaller. York
Re: [U-Boot] [PATCH] powerpc/usb: Workaround for erratum-A006261
On 01/30/2014 11:13 AM, Scott Wood wrote:
On Thu, 2014-01-30 at 10:42 +0530, Suresh Gupta wrote:
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006261
+static inline bool has_erratum_a006261(void)
+{
+u32 svr = get_svr();
+u32 soc = SVR_SOC_VER(svr);
+
+switch (soc) {
+case SVR_P1010:
+return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 2, 0);
+case SVR_P2041:
+return IS_SVR_REV(svr, 1, 0) ||
+IS_SVR_REV(svr, 1, 1) || IS_SVR_REV(svr, 2, 1);
+case SVR_P3041:
+return IS_SVR_REV(svr, 1, 0) ||
+IS_SVR_REV(svr, 1, 1) ||
+IS_SVR_REV(svr, 2, 0) || IS_SVR_REV(svr, 2, 1);
+case SVR_P5020:
+return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 2, 0);
+case SVR_T4240:
+case SVR_T4160:
+return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 2, 0);
+case SVR_T1040:
+return IS_SVR_REV(svr, 1, 0);
+case SVR_P5040:
+return IS_SVR_REV(svr, 1, 0);
+}
P2040? P5010? P5021?
Please update your patch to support these variants. I understand they don't show
up on the errata document, but they are valid variants if you check SVRs.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/t1040qds: Add Video - HDMI support
On 01/30/2014 02:10 AM, Priyanka Jain wrote: T1040 has internal display interface unit (DIU) for driving video. T1040QDS supports video mode via -LCD using TI enconder -HDMI type interface via HDMI encoder Chrontel, CH7301C encoder which is I2C programmable is used as HDMI connector on T1040QDS. This patch add support to -enable Video interface for T1040QDS -route qixis multiplexing to enable DIU-HDMI interface on board -program DIU pixel clock gerenartor for T1040 -program HDMI encoder via I2C on board Signed-off-by: Priyanka Jain priyanka.j...@freescale.com --- This patch has compiling warning. Please fix. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] powerpc/t2081qds: Add T2081 QDS board support
On 02/20/2014 09:16 PM, Shengzhou Liu wrote: T2081 QDS is a high-performance computing evaluation, development and test platform supporting the T2081 QorIQ Power Architecture processor. T2081QDS board Overview --- - T2081 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz - 2MB shared L2 and 512KB L3 CoreNet platform cache (CPC) - CoreNet fabric supporting coherent and noncoherent transactions with prioritization and bandwidth allocation - 32-/64-bit DDR3/DDR3LP SDRAM memory controller with ECC and interleaving - Ethernet interfaces: - Two on-board 10M/100M/1G bps RGMII ports - Two 10Gbps XFI with on-board SFP+ cage - 1Gbps/2.5Gbps SGMII Riser card - 10Gbps XAUI Riser card - Accelerator: - DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC - SerDes: - 8 lanes up to 10.3125GHz - Supports SGMII, HiGig, XFI, XAUI and Aurora debug, - IFC: - 512MB NOR Flash, 2GB NAND Flash, PromJet debug port and Qixis FPGA - eSPI: - Three SPI flash (16MB N25Q128A + 16MB EN25S64 + 512KB SST25WF040) - USB: - Two USB2.0 ports with internal PHY (one Type-A + one micro Type mini-AB) - PCIe: - Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0 with SR-IOV) - eSDHC: - Supports various SD/SDHC/SDXC/eMMC devices with adapter cards and voltage translators - I2C: - Four I2C controllers. - UART: - Dual 4-pins UART serial ports Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- v3: add fixup devicetree for t2081qds. v2: some update for serdes and network configuration. Applied to u-boot-mpc85xx/master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] powerpc/t208x: some update to support t2081
On 01/20/2014 10:11 PM, Shengzhou Liu wrote: - fix serdes definition for t2081. - fix clock speed for t2081. - update ids, as CONFIG_FSL_SATA_V2 is needed only for t2080, T2081 has no SATA. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- Applied to u-boot-mpc85xx/master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 v2] SPL: powerpc: expand SPL's length to 128K
On 01/23/2014 11:50 PM, ying.zh...@freescale.com wrote: From: Ying Zhang b40...@freescale.com 1. The SPL's length of SDCARD boot has not enough,expand the SPL's length to 128K. 2. deleted unused symbol: CONFIG_SYS_RUN_INDDR Signed-off-by: Ying Zhang b40...@freescale.com --- Change from v1: - No change. Applied to u-boot-mpc85xx/master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4 v2] SPL: P1022DS: fix the problem booting from spi flash
On 01/23/2014 11:50 PM, ying.zh...@freescale.com wrote: From: Ying Zhang b40...@freescale.com There was no enough memory for malloc in SPL booting from spi flash, so relayout the memory in SPL: reduce the memory for global data from 16K Bytes to 4K Bytes, save the space for malloc. Signed-off-by: Ying Zhang b40...@freescale.com --- Change from v1: - Move the content about P2020RDB to 2 of patchset. Applied to u-boot-mpc85xx/master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4 v2] powerpc: p1010rdb: Enable p1010rdb to start from NAND/SD/SPI flash with SPL
On 01/23/2014 11:50 PM, ying.zh...@freescale.com wrote: From: Ying Zhang b40...@freescale.com In the previous patches, we introduced the SPL/TPL fraamework. For SD/SPI flash booting way, we introduce the SPL to enable a loader stub. The SPL was loaded by the code from the internal on-chip ROM. The SPL initializes the DDR according to the SPD and loads the final uboot image into DDR, then jump to the DDR to begin execution. For NAND booting way, the nand SPL has size limitation on some board(e.g. P1010RDB), it can not be more than 8KB, we can call it minimal SPL, So the dynamic DDR driver doesn't fit into this minimum SPL. We added the TPL that is loaded by the the minimal SPL. The TPL initializes the DDR according to the SPD and loads the final uboot image into DDR,then jump to the DDR to begin execution. This patch enabled SPL/TPL for P1010RDB to support starting from NAND/SD/SPI flash with SPL framework and initializing the DDR according to SPD in the SPL/TPL. Because the minimal SPL load the TPL to L2 SRAM and the jump to the L2 SRAM to execute, so the section .resetvec is no longer needed. Signed-off-by: Ying Zhang b40...@freescale.com --- Change from v1: - No change. Applied to u-boot-mpc85xx/master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4 v2] SPL: P2020RDB: fix the problem booting from spi flash
On 01/23/2014 11:50 PM, ying.zh...@freescale.com wrote: From: Ying Zhang b40...@freescale.com There was no enough stack in SPL, so the buffer needed in SPL is to malloc from memory pool and to repalce the temporary variable. Signed-off-by: Ying Zhang b40...@freescale.com --- Change from v1: - The malloc size expand to 364K bytes. Applied to u-boot-mpc85xx/master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ar8031/8033/phy:enable autonegotiation for ar8031/8033
On 12/22/2013 11:51 PM, Zhao Qiang wrote: Function genphy_parse_link() used if (mii_reg BMSR_ANEGCAPABLE) before while if (phydev-supported SUPPORTED_Autoneg) now. So assign phydev-supported to phydev-drv-features for ar8031/8033 to enable autonegotiation. Signed-off-by: Zhao Qiang b45...@freescale.com --- drivers/net/phy/atheros.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c index b20b4df..1ee2226 100644 --- a/drivers/net/phy/atheros.c +++ b/drivers/net/phy/atheros.c @@ -13,6 +13,7 @@ static int ar8021_config(struct phy_device *phydev) phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05); phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x3D47); + phydev-supported = phydev-drv-features; return 0; } Joe, This patch has been floating for a while. If it is OK, I'd like to take it in with other 85xx patches. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc8536DS:Increase binary size for mpc8536DS board
On 02/12/2014 05:03 PM, Haijun Zhang wrote: u-boot binary size for Freescale mpc8536DS platforms is 512KB. This has been reached to upper limit of the platforms and causig linker error. So increase the u-boot binary size to 768KB. Signed-off-by: Haijun Zhang haijun.zh...@freescale.com --- Applied to u-boot-mpc85xx/master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v2] fsl/usb: Limit phy_type comparison to first four characters
On 02/17/2014 03:28 AM, Nikhil Badola wrote: Use first four characters for phy_type comparison. Strcmp() should not be used to check the phy_type string which maybe parsed by hwconfig_subarg(). Hwconfig_subarg() returns part of hwconfig string starting from phy_type value till the end of the string. Since phy_type could be either utmi or ulpi, strncmp() should be used so that a comparison of utmi;fsl_ddr:bank_intlv=auto with utmi will succeed. Signed-off-by: Shaohui Xie shaohui@freescale.com Signed-off-by: Nikhil Badola nikhil.bad...@freescale.com --- Changes for v2: - Changed patch heading - Changed patch commit message Applied to u-boot-mpc85xx/master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] kbuild: Fix a false error of generic board support
Hello Tom, On Mon, 24 Feb 2014 22:11:45 +0900 Masahiro Yamada yamad...@jp.panasonic.com wrote: Before this commit, make terminated with an error where it shouldn't under some condition. This bug happened when we built a board unsupporting generic board right after building with generic board. For example, the following sequence failed. (harmony uses generic board but microblaze-generic does not support it) $ make harmony_config Configuring for harmony board... $ make CROSS_COMPILE=arm-linux-gnueabi- [ Build succeed ] $ make microblaze-generic_config Configuring for microblaze-generic board... $ make CROSS_COMPILE=microblaze-linux- Makefile:488: *** Your architecture does not support generic board. Please undefined CONFIG_SYS_GENERIC_BOARD in your board config file. Stop. We had to do make mrproper before building the microblaze board. I've noticed a mistake here in commit log. make mrproper should be make clean. So, correct description is: We had to do make clean before building the microblaze board. If possible, could you directly edit the commit log on your queue? Or better to submit v2 ? Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: delete unused macro CONFIG_ARCH_DEVICE_TREE
Hello Stephen On Mon, 24 Feb 2014 10:26:46 -0700 Stephen Warren swar...@wwwdotorg.org wrote: On 02/24/2014 05:45 AM, Masahiro Yamada wrote: Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Commit description? This patch looked trivial so I did not write commit description. Sorry for my laziness.. Best Regards Masahiro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kbuild: fix SPL link bug when USE_PRIVATE_LIBGCC is yes
Hello Stephen, On Mon, 24 Feb 2014 11:02:25 -0700 Stephen Warren swar...@wwwdotorg.org wrote: On 02/24/2014 04:44 AM, Masahiro Yamada wrote: Commit 6825a95 (kbuild: use Linux Kernel build scripts) changed the behavior of linkage when USE_PRIAVATE_LIBGCC is defined as yes. (It dropped arch/arm/lib/eabi_compat.o from the target library.) Affected boards are all Tegra boards. This commit gets back the same behavior as before Kbuild series. Tested-by: Stephen Warren swar...@nvidia.com ... although interestingly, at least with the Ubuntu 12.10 ARM cross-compiler, the resultant U-Boot works fine with or without this patch. I'd have expected it to fail without this patch since it sounds like USE_PRIVATE_LIBGCC might not be honored correctly, but perhaps the linker cmdline order works out such that the custom libgcc happens to be picked up anyway, just not in the way intended. Thanks for your test. It's good to know your boards are already working. (But I am not sure the build will pass with all sorts of cross tools.) So it turned out it works with or without arch/arm/lib/eabi_compat.c. I am not a compiler expert. Nor do I know what eabi_compat.o is needed for. Anyway, just in case, we'd better to keep the same link behavior as before Kbuild. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot.dtb vs. dts/dt.dtb output filename, also O= vs BUILD_DIR=
Hello Stephen, Prior the to kbuild conversion, U-Boot used to produce file u-boot.dtb in the root of the object tree. Now it doesn't, but I think puts the same file in dts/dt.dtb instead. Was this a deliberate change? The patch is already on Patchwork and I think it should be applied soon. Sorry for the inconvenience. We have some flashing utilities that build U-Boot, then copy this result file. This utility no longer works because the file it's looking for no longer exists. I'd rather fix the U-Boot build process so its output filenames don't change, than fix the utility to look for a variety of different output filenames. Are you OK with a patch reverting the output filename change? Related, I also found that pre-Kbuild, I could make BUILD_DIR=..., but now I have to make O= That's also an external change in behaviour. Was that intentional? make O=... are always supported before and after Kbuild. (I guess many peaple use it for less typing.) And yes, BUILD_DIR was replaced with KBUILD_OUTPUT when I impored many build scripts from Linux Kernel. All overridable variables in Kbuild are prefixed with KBUILD_, so I am following this rule. I hesitate to rename only KBUILD_OUTPUT inconsistently. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: omap: delete unincluded omap-common/config.mk
arch/arm/cpu/armv7/omap-common/config.mk is never included because omap-common is not SoC name. If we want to add OMAP-specific compiler flags, they must be added to omap3/config.mk, omap4/config.mk, omap5/config.mk. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Tom Rini tr...@ti.com --- arch/arm/cpu/armv7/omap-common/config.mk | 9 - 1 file changed, 9 deletions(-) delete mode 100644 arch/arm/cpu/armv7/omap-common/config.mk diff --git a/arch/arm/cpu/armv7/omap-common/config.mk b/arch/arm/cpu/armv7/omap-common/config.mk deleted file mode 100644 index 3a36ab6..000 --- a/arch/arm/cpu/armv7/omap-common/config.mk +++ /dev/null @@ -1,9 +0,0 @@ -# -# (C) Copyright 2002 -# Gary Jennejohn, DENX Software Engineering, ga...@denx.de -# -# SPDX-License-Identifier: GPL-2.0+ -# - -# Make ARMv5 to allow more compilers to work, even though its v7a. -PLATFORM_CPPFLAGS += -march=armv5 -- 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] board/t104xrdb: Add support of CPLD
T1040RDB and T1042RDB_PI has CPLD. Here CPLD controls board mux/features.
This support of CPLD includes
- files and register defintion
- Commands to swtich alternate bank and default bank
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
Changes for v2:
- Updated the cpld command
board/freescale/t104xrdb/Makefile |1 +
board/freescale/t104xrdb/cpld.c | 113 +++
board/freescale/t104xrdb/cpld.h | 40 +
board/freescale/t104xrdb/t104xrdb.c | 13
include/configs/T1040RDB.h |8 +++
include/configs/T1042RDB_PI.h |8 +++
6 files changed, 183 insertions(+)
create mode 100644 board/freescale/t104xrdb/cpld.c
create mode 100644 board/freescale/t104xrdb/cpld.h
diff --git a/board/freescale/t104xrdb/Makefile
b/board/freescale/t104xrdb/Makefile
index e51fb7a..af38d9f 100644
--- a/board/freescale/t104xrdb/Makefile
+++ b/board/freescale/t104xrdb/Makefile
@@ -11,3 +11,4 @@ obj-y += eth.o
obj-$(CONFIG_PCI) += pci.o
obj-y += law.o
obj-y += tlb.o
+obj-y += cpld.o
diff --git a/board/freescale/t104xrdb/cpld.c b/board/freescale/t104xrdb/cpld.c
new file mode 100644
index 000..661816c
--- /dev/null
+++ b/board/freescale/t104xrdb/cpld.c
@@ -0,0 +1,113 @@
+/**
+ * Copyright 2014 Freescale Semiconductor
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * This file provides support for the board-specific CPLD used on some
Freescale
+ * reference boards.
+ *
+ * The following macros need to be defined:
+ *
+ * CONFIG_SYS_CPLD_BASE-The virtual address of the base of the CPLD register
map
+ */
+
+#include common.h
+#include command.h
+#include asm/io.h
+
+#include cpld.h
+
+u8 cpld_read(unsigned int reg)
+{
+ void *p = (void *)CONFIG_SYS_CPLD_BASE;
+
+ return in_8(p + reg);
+}
+
+void cpld_write(unsigned int reg, u8 value)
+{
+ void *p = (void *)CONFIG_SYS_CPLD_BASE;
+
+ out_8(p + reg, value);
+}
+
+/**
+ * Set the boot bank to the alternate bank
+ */
+void cpld_set_altbank(void)
+{
+ u8 reg = CPLD_READ(flash_ctl_status);
+
+ reg = (reg ~CPLD_BANK_SEL_MASK) | CPLD_LBMAP_ALTBANK;
+
+ CPLD_WRITE(flash_ctl_status, reg);
+ CPLD_WRITE(reset_ctl1, CPLD_LBMAP_RESET);
+}
+
+/**
+ * Set the boot bank to the default bank
+ */
+void cpld_set_defbank(void)
+{
+ u8 reg = CPLD_READ(flash_ctl_status);
+
+ reg = (reg ~CPLD_BANK_SEL_MASK) | CPLD_LBMAP_DFLTBANK;
+
+ CPLD_WRITE(flash_ctl_status, reg);
+ CPLD_WRITE(reset_ctl1, CPLD_LBMAP_RESET);
+}
+
+#ifdef DEBUG
+static void cpld_dump_regs(void)
+{
+ printf(cpld_ver = 0x%02x\n, CPLD_READ(cpld_ver));
+ printf(cpld_ver_sub = 0x%02x\n, CPLD_READ(cpld_ver_sub));
+ printf(hw_ver = 0x%02x\n, CPLD_READ(hw_ver));
+ printf(sw_ver = 0x%02x\n, CPLD_READ(sw_ver));
+ printf(reset_ctl[0] = 0x%02x\n, CPLD_READ(reset_ctl[0]));
+ printf(reset_ctl[1] = 0x%02x\n, CPLD_READ(reset_ctl[1]));
+ printf(int_status = 0x%02x\n, CPLD_READ(int_status));
+ printf(misc_ctl_status = 0x%02x\n, CPLD_READ(misc_ctl_status));
+ printf(sfp_ctl_status = 0x%02x\n, CPLD_READ(sfp_ctl_status));
+ printf(flash_ctl_status = 0x%02x\n, CPLD_READ(flash_ctl_status));
+ printf(fan_ctl_status = 0x%02x\n, CPLD_READ(fan_ctl_status));
+ printf(led_ctl_status = 0x%02x\n, CPLD_READ(led_ctl_status));
+ printf(boot_override= 0x%02x\n, CPLD_READ(boot_override));
+ printf(boot_config[0] = 0x%02x\n, CPLD_READ(boot_config[0]));
+ printf(boot_config[1] = 0x%02x\n, CPLD_READ(boot_config[1]));
+ printf(boot_config[2] = 0x%02x\n, CPLD_READ(boot_config[2]));
+ putc('\n');
+}
+#endif
+
+int do_cpld(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ int rc = 0;
+
+ if (argc = 1)
+ return cmd_usage(cmdtp);
+
+ if (strcmp(argv[1], reset) == 0) {
+ if (strcmp(argv[2], altbank) == 0)
+ cpld_set_altbank();
+ else
+ cpld_set_defbank();
+#ifdef DEBUG
+ } else if (strcmp(argv[1], dump) == 0) {
+ cpld_dump_regs();
+#endif
+ } else
+ rc = cmd_usage(cmdtp);
+
+ return rc;
+}
+
+U_BOOT_CMD(
+ cpld, CONFIG_SYS_MAXARGS, 1, do_cpld,
+ Reset the board or alternate bank,
+ reset - hard reset to default bank\n
+ cpld_cmd reset altbank - reset to alternate bank\n
+#ifdef DEBUG
+ cpld_cmd dump - display the CPLD registers\n
+#endif
+ );
diff --git a/board/freescale/t104xrdb/cpld.h b/board/freescale/t104xrdb/cpld.h
new file mode 100644
index 000..463b3db
--- /dev/null
+++ b/board/freescale/t104xrdb/cpld.h
@@ -0,0 +1,40 @@
+/**
+ * Copyright 2013 Freescale Semiconductor
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * This file provides support for the ngPIXIS, a board-specific FPGA used on
+ * some Freescale reference
