[U-Boot] [PATCH v2] usb: gadget: fastboot: improve download progress bar
When download is ongoing, if the actual size of one transfer
is not the same as BTYES_PER_DOT, which will cause the dot
won't print anymore. Then it will let the user thinking it
is stuck, actually it is transfering without dot printed.
So, improve the method to show the progress bar (print dot).
Signed-off-by: Bo Shen voice.s...@atmel.com
---
Changes in v2:
- get rid of the global variable.
- avoid the dot print after showing the total download length.
drivers/usb/gadget/f_fastboot.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 7a1acb9..dda9d1c 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -380,6 +380,7 @@ static void rx_handler_dl_image(struct usb_ep *ep, struct
usb_request *req)
unsigned int transfer_size = download_size - download_bytes;
const unsigned char *buffer = req-buf;
unsigned int buffer_size = req-actual;
+ unsigned int pre_dot_num, now_dot_num;
if (req-status != 0) {
printf(Bad status: %d\n, req-status);
@@ -392,7 +393,15 @@ static void rx_handler_dl_image(struct usb_ep *ep, struct
usb_request *req)
memcpy((void *)CONFIG_USB_FASTBOOT_BUF_ADDR + download_bytes,
buffer, transfer_size);
+ pre_dot_num = download_bytes / BYTES_PER_DOT;
download_bytes += transfer_size;
+ now_dot_num = download_bytes / BYTES_PER_DOT;
+
+ if (pre_dot_num != now_dot_num) {
+ putc('.');
+ if (!(now_dot_num % 74))
+ putc('\n');
+ }
/* Check if transfer is done */
if (download_bytes = download_size) {
@@ -414,11 +423,6 @@ static void rx_handler_dl_image(struct usb_ep *ep, struct
usb_request *req)
req-length = ep-maxpacket;
}
- if (download_bytes !(download_bytes % BYTES_PER_DOT)) {
- putc('.');
- if (!(download_bytes % (74 * BYTES_PER_DOT)))
- putc('\n');
- }
req-actual = 0;
usb_ep_queue(ep, req, 0);
}
--
2.1.0.24.g4109c28
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,1/2] ARM: atmel: sama5d3xek: add nor flash init function
Dear Bo Shen, Bo Shen voice.s...@atmel.com writes: Add NOR flash hardware init function, including SMC and PIO configuration. Signed-off-by: Bo Shen voice.s...@atmel.com Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com --- Changes in v2: None board/atmel/sama5d3xek/sama5d3xek.c | 58 + 1 file changed, 58 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mtd: atmel-nand: use pmecc_readl(b)/pmecc_writel to access the pmecc register
Dear Josh Wu, Josh Wu josh...@atmel.com writes: We defined the macro pmecc_readl(b)/pmecc_writel for pmecc register access. But in the driver we also use the readl(b)/writel. To keep consistent, this patch make all use pmecc_readl(b)/pmecc_writel. Signed-off-by: Josh Wu josh...@atmel.com Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com --- drivers/mtd/nand/atmel_nand.c | 21 +++-- drivers/mtd/nand/atmel_nand_ecc.h |3 +++ 2 files changed, 14 insertions(+), 10 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] compulab trimslice build error due to 52658fda7abc (compulab: eeprom: add support for defining eeprom i2c bus)
Hi Stephen, On 09/18/14 20:21, Stephen Warren wrote: After commit 52658fda7abc (compulab: eeprom: add support for defining eeprom i2c bus), the trimslice board fails to build with: .../board/compulab/common/eeprom.c: In function ‘cl_eeprom_read’: .../board/compulab/common/eeprom.c:37:24: error: ‘CONFIG_SYS_I2C_EEPROM_BUS’ undeclared (first use in this function) .../board/compulab/common/eeprom.c:37:24: note: each undeclared identifier is reported only once for each function it appears in I have no idea if this EEPROM code should even run on TrimSlice or not. Can you take a look at the correct fix? We have already submitted a temporary fix, see [1]. The intend is to switch to Kconfig for all CompuLab boards and that will bring the proper fix for the problem. After this, the temporary fixes can be removed. [1] https://patchwork.ozlabs.org/patch/390381/ -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,2/2] ARM: atmel: sama5d3xek: enable NOR flash support
Dear Bo Shen, Bo Shen voice.s...@atmel.com writes: Signed-off-by: Bo Shen voice.s...@atmel.com --- Changes in v2: - Add CONFIG_SYS_FLASH_PROTECTION - Correct the max sector number include/configs/sama5d3xek.h | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,4/4] USB: ehci-atmel: use pcr to enable or disable clock
Dear Bo Shen, Bo Shen voice.s...@atmel.com writes: If the SoC has pcr, we use pcr (peripheral control register) to enable or disable clock. Signed-off-by: Bo Shen voice.s...@atmel.com --- drivers/usb/host/ehci-atmel.c | 8 1 file changed, 8 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/4] ARM: atmel: use pcr to enable or disable peripheral clock
Dear Bo Shen, Bo Shen voice.s...@atmel.com writes: When use pcr (peripheral control register), then we won't need to care about the peripheral ID. Signed-off-by: Bo Shen voice.s...@atmel.com --- arch/arm/cpu/armv7/at91/clock.c | 24 arch/arm/include/asm/arch-at91/at91_pmc.h | 4 arch/arm/include/asm/arch-at91/clk.h | 1 + 3 files changed, 25 insertions(+), 4 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: atmel: sama5d3: add timings register
Dear Bo Shen, Bo Shen voice.s...@atmel.com writes: Signed-off-by: Bo Shen voice.s...@atmel.com Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com --- arch/arm/include/asm/arch-at91/sama5d3_smc.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,3/4] USB: ohci-at91: use pcr to enable or disable clock
Dear Bo Shen, Bo Shen voice.s...@atmel.com writes: If the SoC has pcr, we use pcr (peripheral control register) to enable or disable clock. Signed-off-by: Bo Shen voice.s...@atmel.com --- drivers/usb/host/ohci-at91.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/4] ARM: atmel: add pcr related definition
Dear Bo Shen, Bo Shen voice.s...@atmel.com writes: Using CPU_HAS_PCR micro to present the SoC has pcr (peripheral control register). Signed-off-by: Bo Shen voice.s...@atmel.com --- arch/arm/include/asm/arch-at91/at91_pmc.h | 2 +- arch/arm/include/asm/arch-at91/sama5d3.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mtd: atmel_nand: Disable subpage NAND write when using Atmel PMECC
Dear Boris BREZILLON, Boris BREZILLON boris.brezil...@free-electrons.com writes: Disable subpage write when using PMECC to prevent buggy partial page write. This fix has been taken from linux sources (see commit 90445ff6241e2a13445310803e2efa606c61f276) Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com Acked-by: Josh Wu josh...@atmel.com --- Hi, Here is a link to the linux commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mtd/nand/atmel_nand.c?id=90445ff6241e2a13445310803e2efa606c61f276 Best Regards, Boris drivers/mtd/nand/atmel_nand.c | 1 + 1 file changed, 1 insertion(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: at91sam9rlek: convert to generic board support
Dear Josh Wu, Josh Wu josh...@atmel.com writes: Signed-off-by: Josh Wu josh...@atmel.com --- include/configs/at91sam9rlek.h | 2 ++ 1 file changed, 2 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: at91sam9n12ek: convert to generic board support
Dear Josh Wu, Josh Wu josh...@atmel.com writes: Signed-off-by: Josh Wu josh...@atmel.com --- include/configs/at91sam9n12ek.h | 1 + 1 file changed, 1 insertion(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-atmel/master - u-boot-arm/master
Dear Albert Aribaud, please pull the following changes into u-boot-arm/master. The following changes since commit 9170818a4e004af7893fa0113f6e5b4afafded55: kconfiglib: change SPDX-License-Identifier to ISC (2014-09-17 21:03:18 -0400) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master for you to fetch changes up to 015b18c642d9b0f92d1b35f6d6ed73a6a0b29675: ARM: at91sam9rlek: convert to generic board support (2014-09-19 00:11:24 +0200) Bo Shen (7): ARM: atmel: sama5d3xek: add nor flash init function ARM: atmel: sama5d3xek: enable NOR flash support ARM: atmel: sama5d3: add timings register ARM: atmel: use pcr to enable or disable peripheral clock ARM: atmel: add pcr related definition USB: ohci-at91: use pcr to enable or disable clock USB: ehci-atmel: use pcr to enable or disable clock Boris BREZILLON (1): mtd: atmel_nand: Disable subpage NAND write when using Atmel PMECC Wu, Josh (3): mtd: atmel-nand: use pmecc_readl(b)/pmecc_writel to access the pmecc register ARM: at91sam9n12ek: convert to generic board support ARM: at91sam9rlek: convert to generic board support arch/arm/cpu/armv7/at91/clock.c | 24 +-- arch/arm/include/asm/arch-at91/at91_pmc.h|6 ++- arch/arm/include/asm/arch-at91/clk.h |1 + arch/arm/include/asm/arch-at91/sama5d3.h |1 + arch/arm/include/asm/arch-at91/sama5d3_smc.h |3 +- board/atmel/sama5d3xek/sama5d3xek.c | 58 ++ drivers/mtd/nand/atmel_nand.c| 22 +- drivers/mtd/nand/atmel_nand_ecc.h|3 ++ drivers/usb/host/ehci-atmel.c|8 drivers/usb/host/ohci-at91.c |8 ++-- include/configs/at91sam9n12ek.h |1 + include/configs/at91sam9rlek.h |2 + include/configs/sama5d3xek.h | 13 +- 13 files changed, 129 insertions(+), 21 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A minor question on a Driver Model function
On 09/18/14 18:46, Bill Pringlemeir wrote:
On 12 September 2014 05:25, Masahiro Yamada
yamad...@jp.panasonic.com wrote:
I have a qustion about lists_driver_lookup_name() function.
On 09/14/14 21:28, Simon Glass wrote:
I would suggest still using strncmp as it is safer,
but count also the '\0', so something like:
On 17 Sep 2014, grinb...@compulab.co.il wrote:
Why safer?
Could you give me more detailed explanation?
On 09/17/14 11:18, Masahiro Yamada wrote:
Well, I'm not an expert in s/w security, but I'll try to explain...
[snip]
But, again, I'm not an expert in this area, so its only a
suggestion.
On 09/17/14 18:25, Bill Pringlemeir wrote:
I thought it was fairly apparent that the current code supports
passing a string that is *NOT* null terminated. This can be
convenient if you extract a sub-string from a command line and do not
need to make a copy that is NULL terminate or perform 'strtok()' type
magic.
On 18 Sep 2014, grinb...@compulab.co.il wrote:
Here is the whole function:
--cut--
struct driver *lists_driver_lookup_name(const char *name)
{
struct driver *drv =
ll_entry_start(struct driver, driver);
const int n_ents = ll_entry_count(struct driver, driver);
struct driver *entry;
int len;
if (!drv || !n_ents)
return NULL;
len = strlen(name);
for (entry = drv; entry != drv + n_ents; entry++) {
if (strncmp(name, entry-name, len))
continue;
/* Full match */
if (len == strlen(entry-name))
return entry;
/* Not found */
return NULL;
--cut--
and... no, the code does not support passing a string that is
not null terminated.
Then using the strncmp() seems useless for security reasons? The 'len'
is not passed in by the caller and 'strlen()' will have the same
problems that 'strcmp()' would for read buffer overflows? I would guess
the code was cribbed from where 'len' was passed? In that case, it
would support strings that are not null terminated.
Yes, that is correct.
Since we are dealing with device/driver names here.
I think the best would be to define a sane name length limit
(say 20 or more characters) and use it as the maximal length
if no '\0' found before the limit.
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/3] spi:rewrite the Freescale DSPI driver.
From: Chao Fu b44...@freescale.com
Freescale DSPI module is used on both the ColdFire platform and the ARM
platform. The original DSPI driver is written for ColdFire platform only,
this patch rewrite the driver to make it be used across the platforms.
Some files, functions, variables and macros were changed accordingly for
some ColdFire boards and Arm boards.
The rewrite including the following changes:
Rename the file name :
cf_spi.c - fsl_dspi.c
Move the file:
arch/m68k/include/asm/coldfire/dspi.h - include/fsl_dspi.h
Rename the functions and variables:
cfxxx - dspixxx
Renamed macros:
CONFIG_CF_DSPI - CONFIG_FSL_DSPI
Keep the following functions for ColdFire:
cfspi_port_conf()
cfspi_claim_bus()
cfspi_release_bus()
Add function for ColdFire:
get_dspi_clk()
Add endian convert for different platform.
dspi_write32()
dspi_read32()
Tested on board M54455EVB, ls1021a-qds and VF610-twr.
Signed-off-by: Chao Fu b44...@freescale.com
Signed-off-by: Alison Wang huan.w...@freescale.com
---
Change in v2:
Merge m68k update and driver update into the patch.
Change in v3:
Remove some unstandard coding style.
Change in v4:
Add two-endian support, and ls1021a support.
arch/m68k/cpu/mcf5227x/cpu_init.c | 3 +-
arch/m68k/cpu/mcf5227x/speed.c| 7 +
arch/m68k/cpu/mcf52x2/speed.c | 7 +
arch/m68k/cpu/mcf5445x/cpu_init.c | 3 +-
arch/m68k/cpu/mcf5445x/speed.c| 7 +
arch/m68k/include/asm/coldfire/dspi.h | 142 -
arch/m68k/include/asm/immap_5227x.h | 1 -
arch/m68k/include/asm/immap_5301x.h | 1 -
arch/m68k/include/asm/immap_5441x.h | 1 -
arch/m68k/include/asm/immap_5445x.h | 1 -
arch/m68k/include/asm/immap_547x_8x.h | 1 -
drivers/spi/Makefile | 2 +-
drivers/spi/cf_spi.c | 347 ---
drivers/spi/fsl_dspi.c| 373 ++
include/configs/M52277EVB.h | 3 +-
include/configs/M54418TWR.h | 3 +-
include/configs/M54451EVB.h | 3 +-
include/configs/M54455EVB.h | 3 +-
include/fsl_dspi.h| 142 +
19 files changed, 545 insertions(+), 505 deletions(-)
delete mode 100644 arch/m68k/include/asm/coldfire/dspi.h
delete mode 100644 drivers/spi/cf_spi.c
create mode 100644 drivers/spi/fsl_dspi.c
create mode 100644 include/fsl_dspi.h
diff --git a/arch/m68k/cpu/mcf5227x/cpu_init.c
b/arch/m68k/cpu/mcf5227x/cpu_init.c
index 91b5fad..bd0b4ab 100644
--- a/arch/m68k/cpu/mcf5227x/cpu_init.c
+++ b/arch/m68k/cpu/mcf5227x/cpu_init.c
@@ -16,6 +16,7 @@
#include asm/io.h
#include asm/rtc.h
#include linux/compiler.h
+#include fsl_dspi.h
/*
* Breath some life into the CPU...
@@ -139,7 +140,7 @@ void uart_port_conf(int port)
}
}
-#ifdef CONFIG_CF_DSPI
+#ifdef CONFIG_FSL_DSPI
void cfspi_port_conf(void)
{
gpio_t *gpio = (gpio_t *) MMAP_GPIO;
diff --git a/arch/m68k/cpu/mcf5227x/speed.c b/arch/m68k/cpu/mcf5227x/speed.c
index 44de4a6..2bfff13 100644
--- a/arch/m68k/cpu/mcf5227x/speed.c
+++ b/arch/m68k/cpu/mcf5227x/speed.c
@@ -124,3 +124,10 @@ int get_clocks(void)
return (0);
}
+
+#ifdef CONFIG_FSL_DSPI
+int get_dspi_clk(void)
+{
+ return gd-bus_clk;
+}
+#endif
diff --git a/arch/m68k/cpu/mcf52x2/speed.c b/arch/m68k/cpu/mcf52x2/speed.c
index c5961d4..69b49c7 100644
--- a/arch/m68k/cpu/mcf52x2/speed.c
+++ b/arch/m68k/cpu/mcf52x2/speed.c
@@ -83,3 +83,10 @@ int get_clocks (void)
return (0);
}
+
+#ifdef CONFIG_FSL_DSPI
+int get_dspi_clk(void)
+{
+ return gd-bus_clk;
+}
+#endif
diff --git a/arch/m68k/cpu/mcf5445x/cpu_init.c
b/arch/m68k/cpu/mcf5445x/cpu_init.c
index 9c324dc..bb7a4cd 100644
--- a/arch/m68k/cpu/mcf5445x/cpu_init.c
+++ b/arch/m68k/cpu/mcf5445x/cpu_init.c
@@ -16,6 +16,7 @@
#include asm/rtc.h
#include asm/io.h
#include linux/compiler.h
+#include fsl_dspi.h
#if defined(CONFIG_CMD_NET)
#include config.h
@@ -423,7 +424,7 @@ int fecpin_setclear(struct eth_device *dev, int setclear)
}
#endif
-#ifdef CONFIG_CF_DSPI
+#ifdef CONFIG_FSL_DSPI
void cfspi_port_conf(void)
{
gpio_t *gpio = (gpio_t *) MMAP_GPIO;
diff --git a/arch/m68k/cpu/mcf5445x/speed.c b/arch/m68k/cpu/mcf5445x/speed.c
index 07a9b35..29c858e 100644
--- a/arch/m68k/cpu/mcf5445x/speed.c
+++ b/arch/m68k/cpu/mcf5445x/speed.c
@@ -279,3 +279,10 @@ int get_clocks(void)
return (0);
}
+
+#ifdef CONFIG_FSL_DSPI
+int get_dspi_clk(void)
+{
+ return gd-bus_clk;
+}
+#endif
diff --git a/arch/m68k/include/asm/coldfire/dspi.h
b/arch/m68k/include/asm/coldfire/dspi.h
deleted file mode 100644
index fda7138..000
--- a/arch/m68k/include/asm/coldfire/dspi.h
+++ /dev/null
@@ -1,142 +0,0 @@
-/*
- * MCF5227x Internal Memory Map
- *
- * Copyright (C) 2004-2007 Freescale Semiconductor, Inc.
- * TsiChung Liew (tsi-chung.l...@freescale.com)
- *
- *
[U-Boot] [PATCH v4 3/3] arm:vf610:vf610-twr:Enable the DSPI for Freesacale vf610-twr board
From: Chao Fu b44...@freescale.com
Enable DSPI iomux for vf610twr board.
Add the SPI configuration for vf610twr board.
Signed-off-by: Chao Fu b44...@freescale.com
---
Change in v2 :
New.
Change in v3 :
None.
Change in v4 :
None.
board/freescale/vf610twr/vf610twr.c | 15 ++-
include/configs/vf610twr.h | 13 +
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/board/freescale/vf610twr/vf610twr.c
b/board/freescale/vf610twr/vf610twr.c
index 54a9f2c..08200b5 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -298,6 +298,18 @@ static void setup_iomux_qspi(void)
imx_iomux_v3_setup_multiple_pads(qspi0_pads, ARRAY_SIZE(qspi0_pads));
}
+static void setup_iomux_dspi(void)
+{
+ static const iomux_v3_cfg_t dspi0_pads[] = {
+ VF610_PAD_PTB19__DSPI0_CS0,
+ VF610_PAD_PTB20__DSPI0_SIN,
+ VF610_PAD_PTB21__DSPI0_SOUT,
+ VF610_PAD_PTB22__DSPI0_SCK,
+ };
+
+ imx_iomux_v3_setup_multiple_pads(dspi0_pads, ARRAY_SIZE(dspi0_pads));
+}
+
#ifdef CONFIG_FSL_ESDHC
struct fsl_esdhc_cfg esdhc_cfg[1] = {
{ESDHC1_BASE_ADDR},
@@ -335,7 +347,7 @@ static void clock_init(void)
struct anadig_reg *anadig = (struct anadig_reg *)ANADIG_BASE_ADDR;
clrsetbits_le32(ccm-ccgr0, CCM_REG_CTRL_MASK,
- CCM_CCGR0_UART1_CTRL_MASK);
+ CCM_CCGR0_UART1_CTRL_MASK | CCM_CCGR0_DSPI0_CTRL_MASK);
clrsetbits_le32(ccm-ccgr1, CCM_REG_CTRL_MASK,
CCM_CCGR1_PIT_CTRL_MASK | CCM_CCGR1_WDOGA5_CTRL_MASK);
clrsetbits_le32(ccm-ccgr2, CCM_REG_CTRL_MASK,
@@ -411,6 +423,7 @@ int board_early_init_f(void)
setup_iomux_enet();
setup_iomux_i2c();
setup_iomux_qspi();
+ setup_iomux_dspi();
return 0;
}
diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h
index 0342550..8c89a6b 100644
--- a/include/configs/vf610twr.h
+++ b/include/configs/vf610twr.h
@@ -80,6 +80,19 @@
#define CONFIG_SYS_FSL_QSPI_LE
#endif
+/* DSPI Configs */
+#ifdef CONFIG_FSL_DSPI
+#define MMAP_DSPI SPI0_BASE_ADDR
+#define CONFIG_SYS_FSL_DSPI_LE
+#define CONFIG_SYS_DSPI_CTAR0 (DSPI_CTAR_TRSZ(7) | \
+DSPI_CTAR_PCSSCK_1CLK | \
+DSPI_CTAR_PASC(0) | \
+DSPI_CTAR_PDT(0) | \
+DSPI_CTAR_CSSCK(0) | \
+DSPI_CTAR_ASC(0) | \
+DSPI_CTAR_DT(0))
+#endif
+
/* I2C Configs */
#define CONFIG_CMD_I2C
#define CONFIG_SYS_I2C
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A minor question on a Driver Model function
On Fri, 19 Sep 2014 09:34:53 +0300
Igor Grinberg grinb...@compulab.co.il wrote:
On 09/18/14 18:46, Bill Pringlemeir wrote:
On 12 September 2014 05:25, Masahiro Yamada
yamad...@jp.panasonic.com wrote:
I have a qustion about lists_driver_lookup_name() function.
On 09/14/14 21:28, Simon Glass wrote:
I would suggest still using strncmp as it is safer,
but count also the '\0', so something like:
On 17 Sep 2014, grinb...@compulab.co.il wrote:
Why safer?
Could you give me more detailed explanation?
On 09/17/14 11:18, Masahiro Yamada wrote:
Well, I'm not an expert in s/w security, but I'll try to explain...
[snip]
But, again, I'm not an expert in this area, so its only a
suggestion.
On 09/17/14 18:25, Bill Pringlemeir wrote:
I thought it was fairly apparent that the current code supports
passing a string that is *NOT* null terminated. This can be
convenient if you extract a sub-string from a command line and do not
need to make a copy that is NULL terminate or perform 'strtok()' type
magic.
On 18 Sep 2014, grinb...@compulab.co.il wrote:
Here is the whole function:
--cut--
struct driver *lists_driver_lookup_name(const char *name)
{
struct driver *drv =
ll_entry_start(struct driver, driver);
const int n_ents = ll_entry_count(struct driver, driver);
struct driver *entry;
int len;
if (!drv || !n_ents)
return NULL;
len = strlen(name);
for (entry = drv; entry != drv + n_ents; entry++) {
if (strncmp(name, entry-name, len))
continue;
/* Full match */
if (len == strlen(entry-name))
return entry;
/* Not found */
return NULL;
--cut--
and... no, the code does not support passing a string that is
not null terminated.
Then using the strncmp() seems useless for security reasons? The 'len'
is not passed in by the caller and 'strlen()' will have the same
problems that 'strcmp()' would for read buffer overflows? I would guess
the code was cribbed from where 'len' was passed? In that case, it
would support strings that are not null terminated.
Yes, that is correct.
Since we are dealing with device/driver names here.
I think the best would be to define a sane name length limit
(say 20 or more characters) and use it as the maximal length
if no '\0' found before the limit.
I disagre.
The argument name of this function may be derived from a device tree,
that is, it is possibly not NULL-terminated
if U-Boot is accidentally given a corrupted device tree.
On the other hand, entry-name originates in
a U_BOOT_DRIVER() instance.
For example, something like this
U_BOOT_DRIVER(root_driver) = {
.name = root_driver,
.id = UCLASS_ROOT,
};
The .name member of U_BOOT_DRIVER is guaranteed
to be NULL-terminated.
I'd say, strcmp(name, entry-name) is always safe.
(In the current code,
len = strlen(name); is *NOT* safe,
but,
len = strlen(entry-name); is safe
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/3] arm:vf610:Enable the DSPI for Freescale vf610 platform
From: Chao Fu b44...@freescale.com
This patch enable the DSPI moudle on VF610 platform with following udpate:
Add get_dspi_clk() function and enable DPSI clock gate.
Add DSPI iomux definition and set the iomux for DSPI.
Signed-off-by: Chao Fu b44...@freescale.com
---
Change in v2:
Separated vf610-twr update into patch 3/4.
Change in v3:
None.
Change in v4:
None.
arch/arm/cpu/armv7/vf610/generic.c| 7 +++
arch/arm/include/asm/arch-vf610/clock.h | 1 +
arch/arm/include/asm/arch-vf610/crm_regs.h| 1 +
arch/arm/include/asm/arch-vf610/iomux-vf610.h | 8
arch/arm/include/asm/imx-common/iomux-v3.h| 2 ++
5 files changed, 19 insertions(+)
diff --git a/arch/arm/cpu/armv7/vf610/generic.c
b/arch/arm/cpu/armv7/vf610/generic.c
index a26d63e..266343e 100644
--- a/arch/arm/cpu/armv7/vf610/generic.c
+++ b/arch/arm/cpu/armv7/vf610/generic.c
@@ -196,6 +196,11 @@ static u32 get_i2c_clk(void)
return get_ipg_clk();
}
+static u32 get_dspi_clk(void)
+{
+ return get_ipg_clk();
+}
+
unsigned int mxc_get_clock(enum mxc_clock clk)
{
switch (clk) {
@@ -213,6 +218,8 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
return get_fec_clk();
case MXC_I2C_CLK:
return get_i2c_clk();
+ case MXC_DSPI_CLK:
+ return get_dspi_clk();
default:
break;
}
diff --git a/arch/arm/include/asm/arch-vf610/clock.h
b/arch/arm/include/asm/arch-vf610/clock.h
index 535adad..e5a5c6d 100644
--- a/arch/arm/include/asm/arch-vf610/clock.h
+++ b/arch/arm/include/asm/arch-vf610/clock.h
@@ -17,6 +17,7 @@ enum mxc_clock {
MXC_ESDHC_CLK,
MXC_FEC_CLK,
MXC_I2C_CLK,
+ MXC_DSPI_CLK,
};
void enable_ocotp_clk(unsigned char enable);
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 724682c..54fb748 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -189,6 +189,7 @@ struct anadig_reg {
#define CCM_REG_CTRL_MASK 0x
#define CCM_CCGR0_UART0_CTRL_MASK (0x3 14)
#define CCM_CCGR0_UART1_CTRL_MASK (0x3 16)
+#define CCM_CCGR0_DSPI0_CTRL_MASK (0x3 24)
#define CCM_CCGR1_PIT_CTRL_MASK(0x3 14)
#define CCM_CCGR1_WDOGA5_CTRL_MASK (0x3 28)
#define CCM_CCGR2_QSPI0_CTRL_MASK (0x3 8)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index 7464da8..fdb7e40 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -29,6 +29,10 @@
#define VF610_QSPI_PAD_CTRL(PAD_CTL_SPEED_HIGH | PAD_CTL_DSE_150ohm | \
PAD_CTL_PUS_22K_UP | PAD_CTL_OBE_IBE_ENABLE)
+#define VF610_DSPI_PAD_CTRL(PAD_CTL_OBE | PAD_CTL_DSE_25ohm | \
+ PAD_CTL_SPEED_MED)
+#define VF610_DSPI_SIN_PAD_CTRL(PAD_CTL_IBE | PAD_CTL_DSE_25ohm | \
+ PAD_CTL_SPEED_MED)
enum {
VF610_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x, 0x, 2,
__NA_, 0, VF610_ENET_PAD_CTRL),
@@ -63,6 +67,10 @@ enum {
VF610_PAD_PTA29__ESDHC1_DAT3= IOMUX_PAD(0x004c, 0x004c, 5,
__NA_, 0, VF610_SDHC_PAD_CTRL),
VF610_PAD_PTB14__I2C0_SCL = IOMUX_PAD(0x0090, 0x0090, 2,
0x033c, 1, VF610_I2C_PAD_CTRL),
VF610_PAD_PTB15__I2C0_SDA = IOMUX_PAD(0x0094, 0x0094, 2,
0x0340, 1, VF610_I2C_PAD_CTRL),
+ VF610_PAD_PTB19__DSPI0_CS0 = IOMUX_PAD(0x00a4, 0x00a4, 1,
__NA_, 0, VF610_DSPI_PAD_CTRL),
+ VF610_PAD_PTB20__DSPI0_SIN = IOMUX_PAD(0x00a8, 0x00a8, 1,
__NA_, 0, VF610_DSPI_SIN_PAD_CTRL),
+ VF610_PAD_PTB21__DSPI0_SOUT = IOMUX_PAD(0x00ac, 0x00ac, 1,
__NA_, 0, VF610_DSPI_PAD_CTRL),
+ VF610_PAD_PTB22__DSPI0_SCK = IOMUX_PAD(0x00b0, 0x00b0, 1,
__NA_, 0, VF610_DSPI_PAD_CTRL),
VF610_PAD_PTD31__NF_IO15= IOMUX_PAD(0x00fc, 0x00fc, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
VF610_PAD_PTD30__NF_IO14= IOMUX_PAD(0x0100, 0x0100, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
VF610_PAD_PTD29__NF_IO13= IOMUX_PAD(0x0104, 0x0104, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h
b/arch/arm/include/asm/imx-common/iomux-v3.h
index 70ee86c..afade7e 100644
--- a/arch/arm/include/asm/imx-common/iomux-v3.h
+++ b/arch/arm/include/asm/imx-common/iomux-v3.h
@@ -152,6 +152,8 @@ typedef u64 iomux_v3_cfg_t;
#define PAD_CTL_PUS_47K_UP (1 4 | PAD_CTL_PUE)
#define PAD_CTL_PUS_100K_UP(2 4 | PAD_CTL_PUE)
#define PAD_CTL_PUS_22K_UP (3 4 | PAD_CTL_PUE)
+#define PAD_CTL_OBE(1 1)
+#define PAD_CTL_IBE(1 0)
#define PAD_CTL_ODE(1 3)
--
Re: [U-Boot] [PATCH v2] usb: gadget: fastboot: improve download progress bar
On Friday, September 19, 2014 at 08:15:12 AM, Bo Shen wrote: When download is ongoing, if the actual size of one transfer is not the same as BTYES_PER_DOT, which will cause the dot won't print anymore. Then it will let the user thinking it is stuck, actually it is transfering without dot printed. So, improve the method to show the progress bar (print dot). Signed-off-by: Bo Shen voice.s...@atmel.com I didn't test it, but it looks OK: Acked-by: Marek Vasut ma...@denx.de 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 0/3] ARM: atmel: add sama5d4ek board support
On 16/09/2014 09:57, Bo Shen : This patch series add sama5d4ek board support which supports following features: - Boot media support: NAND flash/SD card/SPI flash - Support LCD display - Support ethernet - Support USB mass storage This patch series depends on the series [1]: ARM: atmel: use pcr to enable or disable peripheral clock. [1] http://patchwork.ozlabs.org/patch/376960/ Bo Shen (2): net: macb: enable GMAC IP without GE feature support ARM: atmel: add sama5d4ek board support Josh Wu (1): atmel_nand: if don't have gf table in rom code we will build it runtime For the whole series: Acked-by: Nicolas Ferre nicolas.fe...@atmel.com Thanks, best regards, arch/arm/Kconfig | 4 + arch/arm/cpu/armv7/at91/timer.c | 3 +- arch/arm/include/asm/arch-at91/at91_pmc.h | 6 +- arch/arm/include/asm/arch-at91/clk.h | 29 +++ arch/arm/include/asm/arch-at91/hardware.h | 2 + arch/arm/include/asm/arch-at91/sama5d4.h | 199 ++ board/atmel/sama5d4ek/Kconfig | 18 ++ board/atmel/sama5d4ek/MAINTAINERS | 8 + board/atmel/sama5d4ek/Makefile| 15 ++ board/atmel/sama5d4ek/sama5d4ek.c | 322 ++ configs/sama5d4ek_mmc_defconfig | 3 + configs/sama5d4ek_nandflash_defconfig | 3 + configs/sama5d4ek_spiflash_defconfig | 3 + drivers/mtd/nand/atmel_nand.c | 127 +++- drivers/net/macb.c| 8 +- include/configs/sama5d4ek.h | 215 16 files changed, 959 insertions(+), 6 deletions(-) create mode 100644 arch/arm/include/asm/arch-at91/sama5d4.h create mode 100644 board/atmel/sama5d4ek/Kconfig create mode 100644 board/atmel/sama5d4ek/MAINTAINERS create mode 100644 board/atmel/sama5d4ek/Makefile create mode 100644 board/atmel/sama5d4ek/sama5d4ek.c create mode 100644 configs/sama5d4ek_mmc_defconfig create mode 100644 configs/sama5d4ek_nandflash_defconfig create mode 100644 configs/sama5d4ek_spiflash_defconfig create mode 100644 include/configs/sama5d4ek.h -- Nicolas Ferre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] Rename some defines containing FAT in their name to be filesystem generic MMCSD_MODE_FAT = MMCSD_MODE_FS CONFIG_SPL_FAT_LOAD_ARGS_NAME = CONFIG_SPL_FS_LOAD_ARGS_NAME CONFIG_SPL_
Rename some defines containing FAT in their name to be filesystem generic:
MMCSD_MODE_FAT = MMCSD_MODE_FS
CONFIG_SPL_FAT_LOAD_ARGS_NAME = CONFIG_SPL_FS_LOAD_ARGS_NAME
CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME = CONFIG_SPL_FS_LOAD_PAYLOAD_NAME
CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION = CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION
Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Stefano Babic sba...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Michal Simek mon...@monstr.eu
Cc: Andreas Bießmann andreas.de...@googlemail.com
---
arch/arm/cpu/arm1136/mx35/generic.c | 2 +-
arch/arm/cpu/armv7/omap-common/boot-common.c | 4 ++--
arch/arm/cpu/armv7/omap3/board.c | 2 +-
arch/arm/cpu/armv7/zynq/spl.c| 2 +-
arch/arm/cpu/at91-common/spl.c | 2 +-
arch/arm/imx-common/spl.c| 2 +-
common/spl/spl_fat.c | 6 +++---
common/spl/spl_mmc.c | 8
common/spl/spl_sata.c| 2 +-
common/spl/spl_usb.c | 2 +-
include/configs/am3517_crane.h | 4 ++--
include/configs/am3517_evm.h | 4 ++--
include/configs/cm_t35.h | 4 ++--
include/configs/devkit8000.h | 8
include/configs/imx6_spl.h | 4 ++--
include/configs/mcx.h| 4 ++--
include/configs/omap3_evm.h | 4 ++--
include/configs/omap3_evm_quick_mmc.h| 4 ++--
include/configs/sama5d3_xplained.h | 4 ++--
include/configs/sama5d3xek.h | 4 ++--
include/configs/siemens-am33x-common.h | 4 ++--
include/configs/tao3530.h| 4 ++--
include/configs/ti814x_evm.h | 4 ++--
include/configs/ti816x_evm.h | 4 ++--
include/configs/ti_armv7_common.h| 8
include/configs/tricorder.h | 4 ++--
include/configs/zynq-common.h| 10 +-
include/spl.h| 2 +-
28 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/arch/arm/cpu/arm1136/mx35/generic.c
b/arch/arm/cpu/arm1136/mx35/generic.c
index 8d3f92c..bc98edd 100644
--- a/arch/arm/cpu/arm1136/mx35/generic.c
+++ b/arch/arm/cpu/arm1136/mx35/generic.c
@@ -531,7 +531,7 @@ u32 spl_boot_mode(void)
switch (spl_boot_device()) {
case BOOT_DEVICE_MMC1:
#ifdef CONFIG_SPL_FAT_SUPPORT
- return MMCSD_MODE_FAT;
+ return MMCSD_MODE_FS;
#else
return MMCSD_MODE_RAW;
#endif
diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c
b/arch/arm/cpu/armv7/omap-common/boot-common.c
index 3033564..fb535eb 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -81,8 +81,8 @@ u32 spl_boot_mode(void)
if (val == MMCSD_MODE_RAW)
return MMCSD_MODE_RAW;
- else if (val == MMCSD_MODE_FAT)
- return MMCSD_MODE_FAT;
+ else if (val == MMCSD_MODE_FS)
+ return MMCSD_MODE_FS;
else
#ifdef CONFIG_SUPPORT_EMMC_BOOT
return MMCSD_MODE_EMMCBOOT;
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 667e77f..9bcca9d 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -65,7 +65,7 @@ u32 spl_boot_mode(void)
case BOOT_DEVICE_MMC2:
return MMCSD_MODE_RAW;
case BOOT_DEVICE_MMC1:
- return MMCSD_MODE_FAT;
+ return MMCSD_MODE_FS;
break;
default:
puts(spl: ERROR: unknown device - can't select boot mode\n);
diff --git a/arch/arm/cpu/armv7/zynq/spl.c b/arch/arm/cpu/armv7/zynq/spl.c
index 9ff2ef2..31627f9 100644
--- a/arch/arm/cpu/armv7/zynq/spl.c
+++ b/arch/arm/cpu/armv7/zynq/spl.c
@@ -63,7 +63,7 @@ u32 spl_boot_device(void)
#ifdef CONFIG_SPL_MMC_SUPPORT
u32 spl_boot_mode(void)
{
- return MMCSD_MODE_FAT;
+ return MMCSD_MODE_FS;
}
#endif
diff --git a/arch/arm/cpu/at91-common/spl.c b/arch/arm/cpu/at91-common/spl.c
index cbb5a52..674a470 100644
--- a/arch/arm/cpu/at91-common/spl.c
+++ b/arch/arm/cpu/at91-common/spl.c
@@ -102,7 +102,7 @@ u32 spl_boot_mode(void)
switch (spl_boot_device()) {
#ifdef CONFIG_SYS_USE_MMC
case BOOT_DEVICE_MMC1:
- return MMCSD_MODE_FAT;
+ return MMCSD_MODE_FS;
break;
#endif
case BOOT_DEVICE_NONE:
diff --git a/arch/arm/imx-common/spl.c b/arch/arm/imx-common/spl.c
index 9a02a64..9d3c31a 100644
--- a/arch/arm/imx-common/spl.c
+++ b/arch/arm/imx-common/spl.c
@@ -68,7 +68,7 @@ u32 spl_boot_mode(void)
case BOOT_DEVICE_MMC1:
case BOOT_DEVICE_MMC2:
#ifdef CONFIG_SPL_FAT_SUPPORT
- return MMCSD_MODE_FAT;
+ return MMCSD_MODE_FS;
#else
[U-Boot] [PATCH 0/5] Add EXT filesystem support to SPL
Hi, This patch set adds EXT filesystem support to SPL and enables it for OMAP4 boards. Build is succesful on all omap4 and omap5 boards. Note that some OMAP3 boards (omap3_beagle and omap3_overo) may need to disable some functions in order to support EXT in SPL, otherwise the MLO (SPL) may be too big to fit in SRAM. I tested it succesfully on a Pandaboard (rev. A3) and on a Beagleboard xM (rev. B). Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Stefano Babic sba...@denx.de Cc: Tom Rini tr...@ti.com Cc: Michal Simek mon...@monstr.eu Cc: Andreas Bießmann andreas.de...@googlemail.com Regards, Guillaume --- Guillaume GARDET (5): Rename some defines containing FAT in their name to be filesystem generic MMCSD_MODE_FAT = MMCSD_MODE_FS CONFIG_SPL_FAT_LOAD_ARGS_NAME = CONFIG_SPL_FS_LOAD_ARGS_NAME CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME = CONFIG_SPL_FS_LOAD_PAYLOAD_NAME CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION = CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION spl: Add EXT support to SPL doc: Update documentation according to the EXT SPL support patch set spl: do not hang in spl_register_fat_device but return error value. It allows to use both CONFIG_SPL_FAT_SUPPORT and CONFIG_SPL_EXT_SUPPORT. TI:OMAP4: enable EXT support in SPL for OMAP4 boards README | 17 ++-- arch/arm/cpu/arm1136/mx35/generic.c | 2 +- arch/arm/cpu/armv7/omap-common/boot-common.c | 4 +- arch/arm/cpu/armv7/omap3/board.c | 2 +- arch/arm/cpu/armv7/zynq/spl.c| 2 +- arch/arm/cpu/at91-common/spl.c | 2 +- arch/arm/imx-common/spl.c| 2 +- common/spl/Makefile | 1 + common/spl/spl_ext.c | 138 +++ common/spl/spl_fat.c | 8 +- common/spl/spl_mmc.c | 24 - common/spl/spl_sata.c| 2 +- common/spl/spl_usb.c | 2 +- doc/README.SPL | 1 + fs/Makefile | 1 + include/configs/am3517_crane.h | 4 +- include/configs/am3517_evm.h | 4 +- include/configs/cm_t35.h | 4 +- include/configs/devkit8000.h | 8 +- include/configs/imx6_spl.h | 4 +- include/configs/mcx.h| 4 +- include/configs/omap3_evm.h | 4 +- include/configs/omap3_evm_quick_mmc.h| 4 +- include/configs/sama5d3_xplained.h | 4 +- include/configs/sama5d3xek.h | 4 +- include/configs/siemens-am33x-common.h | 4 +- include/configs/tao3530.h| 4 +- include/configs/ti814x_evm.h | 4 +- include/configs/ti816x_evm.h | 4 +- include/configs/ti_armv7_common.h| 8 +- include/configs/ti_omap4_common.h| 3 + include/configs/tricorder.h | 4 +- include/configs/zynq-common.h| 10 +- include/spl.h| 6 +- 34 files changed, 232 insertions(+), 67 deletions(-) create mode 100644 common/spl/spl_ext.c -- 1.8.4.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] spl: Add EXT support to SPL
Add EXT filesystem support to SPL.
Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Stefano Babic sba...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Michal Simek mon...@monstr.eu
Cc: Andreas Bießmann andreas.de...@googlemail.com
---
common/spl/Makefile | 1 +
common/spl/spl_ext.c | 138 +++
common/spl/spl_mmc.c | 18 ++-
fs/Makefile | 1 +
include/spl.h| 4 ++
5 files changed, 160 insertions(+), 2 deletions(-)
create mode 100644 common/spl/spl_ext.c
diff --git a/common/spl/Makefile b/common/spl/Makefile
index 64569c2..10a4589 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -18,5 +18,6 @@ obj-$(CONFIG_SPL_NET_SUPPORT) += spl_net.o
obj-$(CONFIG_SPL_MMC_SUPPORT) += spl_mmc.o
obj-$(CONFIG_SPL_USB_SUPPORT) += spl_usb.o
obj-$(CONFIG_SPL_FAT_SUPPORT) += spl_fat.o
+obj-$(CONFIG_SPL_EXT_SUPPORT) += spl_ext.o
obj-$(CONFIG_SPL_SATA_SUPPORT) += spl_sata.o
endif
diff --git a/common/spl/spl_ext.c b/common/spl/spl_ext.c
new file mode 100644
index 000..7342268
--- /dev/null
+++ b/common/spl/spl_ext.c
@@ -0,0 +1,138 @@
+/*
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include spl.h
+#include asm/u-boot.h
+#include ext4fs.h
+#include image.h
+
+#ifdef CONFIG_SPL_EXT_SUPPORT
+int spl_load_image_ext(block_dev_desc_t *block_dev,
+ int partition,
+ const char *filename)
+{
+ s32 err;
+ struct image_header *header;
+ int filelen;
+ disk_partition_t part_info = {};
+
+ header = (struct image_header *)(CONFIG_SYS_TEXT_BASE -
+ sizeof(struct image_header));
+
+ if (get_partition_info(block_dev,
+ partition, part_info)) {
+ printf(spl: no partition table found\n);
+ goto end;
+ }
+
+ ext4fs_set_blk_dev(block_dev, part_info);
+
+ err = ext4fs_mount(0);
+ if (!err) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+ printf(%s: ext4fs mount err - %d\n, __func__, err);
+#endif
+ goto end;
+ }
+
+ filelen = err = ext4fs_open(filename);
+ if (err 0) {
+ puts(spl: ext4fs_open failed\n);
+ goto end;
+ }
+ err = ext4fs_read((char *)header, sizeof(struct image_header));
+ if (err = 0) {
+ puts(spl: ext4fs_read failed\n);
+ goto end;
+ }
+
+ spl_parse_image_header(header);
+
+ err = ext4fs_read((char *)spl_image.load_addr, filelen);
+
+end:
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+ if (err = 0)
+ printf(%s: error reading image %s, err - %d\n,
+ __func__, filename, err);
+#endif
+
+ return (err = 0);
+}
+
+#ifdef CONFIG_SPL_OS_BOOT
+int spl_load_image_ext_os(block_dev_desc_t *block_dev, int partition)
+{
+ int err;
+ int filelen;
+ disk_partition_t part_info = {};
+ __maybe_unused char *file;
+
+ if (get_partition_info(block_dev,
+ partition, part_info)) {
+ printf(spl: no partition table found\n);
+ return -1;
+ }
+
+ ext4fs_set_blk_dev(block_dev, part_info);
+
+ err = ext4fs_mount(0);
+ if (!err) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+ printf(%s: ext4fs mount err - %d\n, __func__, err);
+#endif
+ return -1;
+ }
+
+#if defined(CONFIG_SPL_ENV_SUPPORT) defined(CONFIG_SPL_OS_BOOT)
+ file = getenv(falcon_args_file);
+ if (file) {
+ filelen = err = ext4fs_open(file);
+ if (err 0) {
+ puts(spl: ext4fs_open failed\n);
+ goto defaults;
+ }
+ err = ext4fs_read( (void *)CONFIG_SYS_SPL_ARGS_ADDR, filelen);
+ if (err = 0) {
+ printf(spl: error reading image %s, err - %d, falling
back to default\n,
+ file, err);
+ goto defaults;
+ }
+ file = getenv(falcon_image_file);
+ if (file) {
+ err = spl_load_image_ext(block_dev, partition, file);
+ if (err != 0) {
+ puts(spl: falling back to default\n);
+ goto defaults;
+ }
+
+ return 0;
+ } else
+ puts(spl: falcon_image_file not set in environment,
falling back to default\n);
+ } else
+ puts(spl: falcon_args_file not set in environment, falling
back to default\n);
+
+defaults:
+#endif
+
+ filelen = err = ext4fs_open(CONFIG_SPL_FS_LOAD_ARGS_NAME);
+ if (err 0) {
+ puts(spl: ext4fs_open failed\n);
+ }
+
[U-Boot] [PATCH 5/5] TI:OMAP4: enable EXT support in SPL for OMAP4 boards
Enable EXT support in SPL for OMAP4 boards. Build tested for duovero, omap4_sdp4430 and omap4_panda. Run time tested on omap4_panda. Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Stefano Babic sba...@denx.de Cc: Tom Rini tr...@ti.com Cc: Michal Simek mon...@monstr.eu Cc: Andreas Bießmann andreas.de...@googlemail.com --- include/configs/ti_omap4_common.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/ti_omap4_common.h b/include/configs/ti_omap4_common.h index 8c7310c..7b911c4 100644 --- a/include/configs/ti_omap4_common.h +++ b/include/configs/ti_omap4_common.h @@ -167,6 +167,9 @@ #define CONFIG_SYS_SPL_ARGS_ADDR (CONFIG_SYS_SDRAM_BASE + \ (128 20)) +/* SPL: Allow to use an EXT partition */ +#define CONFIG_SPL_EXT_SUPPORT + #ifdef CONFIG_NAND #define CONFIG_SPL_NAND_AM33XX_BCH /* ELM support */ #endif -- 1.8.4.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] spl: do not hang in spl_register_fat_device but return error value. It allows to use both CONFIG_SPL_FAT_SUPPORT and CONFIG_SPL_EXT_SUPPORT.
Do not hang in spl_register_fat_device but return an error value. It allows to use both CONFIG_SPL_FAT_SUPPORT and CONFIG_SPL_EXT_SUPPORT. If FAT load fails, then EXT load is tried. Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Stefano Babic sba...@denx.de Cc: Tom Rini tr...@ti.com Cc: Michal Simek mon...@monstr.eu Cc: Andreas Bießmann andreas.de...@googlemail.com --- common/spl/spl_fat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c index 91481fc..350f7d9 100644 --- a/common/spl/spl_fat.c +++ b/common/spl/spl_fat.c @@ -30,7 +30,7 @@ static int spl_register_fat_device(block_dev_desc_t *block_dev, int partition) #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT printf(%s: fat register err - %d\n, __func__, err); #endif - hang(); + return err; } fat_registered = 1; -- 1.8.4.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] doc: Update documentation according to the EXT SPL support patch set
Update documentation according to the EXT SPL support patch set. Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Stefano Babic sba...@denx.de Cc: Tom Rini tr...@ti.com Cc: Michal Simek mon...@monstr.eu Cc: Andreas Bießmann andreas.de...@googlemail.com --- README | 17 ++--- doc/README.SPL | 1 + 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/README b/README index 0a0f528..30a2008 100644 --- a/README +++ b/README @@ -3525,7 +3525,7 @@ FIT uImage format: CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR, CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS, - CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION + CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION Address, size and partition on the MMC to load U-Boot from when the MMC is being used in raw mode. @@ -3542,16 +3542,19 @@ FIT uImage format: CONFIG_SPL_FAT_SUPPORT Support for fs/fat/libfat.o in SPL binary - CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME - Filename to read to load U-Boot when reading from FAT + CONFIG_SPL_EXT_SUPPORT + Support for EXT filesystem in SPL binary - CONFIG_SPL_FAT_LOAD_KERNEL_NAME + CONFIG_SPL_FS_LOAD_PAYLOAD_NAME + Filename to read to load U-Boot when reading from filesystem + + CONFIG_SPL_FS_LOAD_KERNEL_NAME Filename to read to load kernel uImage when reading - from FAT (for Falcon mode) + from filesystem (for Falcon mode) - CONFIG_SPL_FAT_LOAD_ARGS_NAME + CONFIG_SPL_FS_LOAD_ARGS_NAME Filename to read to load kernel argument parameters - when reading from FAT (for Falcon mode) + when reading from filesystem (for Falcon mode) CONFIG_SPL_MPC83XX_WAIT_FOR_NAND Set this for NAND SPL on PPC mpc83xx targets, so that diff --git a/doc/README.SPL b/doc/README.SPL index c283dcf..3ba313c 100644 --- a/doc/README.SPL +++ b/doc/README.SPL @@ -54,6 +54,7 @@ CONFIG_SPL_SERIAL_SUPPORT (drivers/serial/libserial.o) CONFIG_SPL_SPI_FLASH_SUPPORT (drivers/mtd/spi/libspi_flash.o) CONFIG_SPL_SPI_SUPPORT (drivers/spi/libspi.o) CONFIG_SPL_FAT_SUPPORT (fs/fat/libfat.o) +CONFIG_SPL_EXT_SUPPORT CONFIG_SPL_LIBGENERIC_SUPPORT (lib/libgeneric.o) CONFIG_SPL_POWER_SUPPORT (drivers/power/libpower.o) CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/libnand.o) -- 1.8.4.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] socfpga: Enable DWMMC for SOCFPGA
To enable the DesignWare MMC controller driver support for SOCFPGA Cyclone5 dev kit Signed-off-by: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc: Pavel Machek pa...@denx.de Cc: Marek Vasut ma...@denx.de Cc: Tom Rini tr...@ti.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Wolfgang Denk w...@denx.de --- include/configs/socfpga_cyclone5.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/include/configs/socfpga_cyclone5.h b/include/configs/socfpga_cyclone5.h index 32175b7..f9fafac 100644 --- a/include/configs/socfpga_cyclone5.h +++ b/include/configs/socfpga_cyclone5.h @@ -252,6 +252,24 @@ /* Clocks source frequency to watchdog timer */ #define CONFIG_DW_WDT_CLOCK_KHZ25000 +/* + * MMC support + */ +#define CONFIG_MMC +#ifdef CONFIG_MMC +#define CONFIG_CMD_MMC +#define CONFIG_SDMMC_BASE (SOCFPGA_SDMMC_ADDRESS) +#define CONFIG_SDMMC_HOST_HS +#define CONFIG_GENERIC_MMC 1 +#define CONFIG_DWMMC +#define CONFIG_SOCFPGA_DWMMC +#define CONFIG_SOCFPGA_DWMMC_FIFO_DEPTH1024 +#define CONFIG_SOCFPGA_DWMMC_DRVSEL3 +#define CONFIG_SOCFPGA_DWMMC_SMPSEL0 +#define CONFIG_BOUNCE_BUFFER +/* using smaller max blk cnt to avoid flooding the limited stack we have */ +#define CONFIG_SYS_MMC_MAX_BLK_COUNT 256 +#endif /* CONFIG_MMC */ /* * SPL Second Program Loader aka Initial Software -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
Hi Marek, On Wed, 2014-09-17 at 14:39 +0200, ma...@denx.de wrote: On Wednesday, September 17, 2014 at 02:00:42 PM, Chin Liang See wrote: On Wed, 2014-09-17 at 13:52 +0200, ma...@denx.de wrote: On Wednesday, September 17, 2014 at 01:29:15 PM, Chin Liang See wrote: 3. MMC is not enabled in SocFPGA. I recall there is a patch from Pavel. I believe its pending for v2 due to some comments. This should be in the tree in fact. Is CONFIG_CMD_MMC defined ? I didn't see any MMC configuration at include/configs/socfpga_cyclone5 at mainline nor the new patch series. Wonder I might miss out any ACKed patch? Oh I see. I have this enabled in the repository here, but I didn't submit that change since it needs more work. The code is there , added in the patch arm: socfpga: misc: Add SD controller init The change for the SoCFPGA config file is missing though. Yup, I just submit the patch to add that socfpga: Enable DWMMC for SOCFPGA. With this added, the SDMMC is working well at U-Boot. This including all the 35 patches from you. Something to cheer during the weekend :) Here is the printout: SOCFPGA_CYCLONE5 # fatls mmc 0:1 194168 u-boot.img 16289 socfpga.dtb 3202824 zimage 3 file(s), 0 dir(s) SOCFPGA_CYCLONE5 # mmc read 8000 0 1 MMC read: dev # 0, block # 0, count 1 ... 1 blocks read: OK SOCFPGA_CYCLONE5 # md 8000 8000: 8010: 8020: 8030: 8040: 8050: 8060: 8070: 8080: 8090: 80a0: 80b0: 80c0: 80d0: 80e0: 80f0: SOCFPGA_CYCLONE5 # 8100: 8110: 8120: 8130: 8140: 8150: 8160: 8170: 8180: 8190: 81a0: 81b0: 479bf7be 0100...G 81c0: 3c0b0001 003e093e 937e ...~. 81d0: 3c830a01 93bc133e 93bc .. 81e0: 3ca21401 27781d3e 93bc0001 x' 81f0: aa55..U. SOCFPGA_CYCLONE5 # Thanks Chin Liang 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 00/35][RFC] arm: socfpga: Usability fixes
Dear Wolfgang, On Wed, 2014-09-17 at 16:11 +0200, ZY - wd wrote: Dear Chin Liang See, In message 1410952049.7769.11.ca...@clsee-virtualbox.altera.com you wrote: Hmmm... actually I can get it works well for my Altera dev kit. The get_dram_size would take in the argument PHYS_SDRAM_1_SIZE. From here, the function will ensure the memory specified can read and writable. If its failing here, probably the SDRAM access might have issue. FYI, PHYS_SDRAM_1_SIZE is 0x4000 for 1GB. Normally, get_dram_size() would be called with a size argument that is _larger_ (twice as big) as the biggest possible memory configuration on the respective device. Otherwise it can only detect smaller memory sizes, but would fail to detect if a bigger memory device is installed by accident. Yup, you are right. But currently, the memory space after the SDRAM is a bridge to FPGA. We will get data abort when trying to read that area (for a blank FPGA). I believe Marek's suggestion to work around the DABT and memory detection would work around SOCFPGA memory detection. Its something we would work closely with Marek to enable this auto detection. Thanks Chin Liang Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Hi guys, On Wed, 2014-09-17 at 06:54 -0500, Chin Liang See wrote: On Tue, 2014-09-16 at 11:56 +0200, ZY - pavel wrote: Hi! I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place. I maintain a linux git repo at git://git.rocketboards.org/linux-socfpga-next.git. It would be trivial for us to maintain a u-boot repo at the same location. a large flurry of patches flying around? Funny, that I have not been CCed on any of these patches. Chin-Liang, have you been? I'm sorry about that. I understood you are working on Linux, and only seen u-boot patches from Chin-Liang, so I cc-ed him.. Hi guys, To move things forward, I would propose myself to act as the custodian for the SOCFPGA repository after discussing with Dinh. I have been active on U-Boot forum and hopefully build up some credibility :). At same time, this will enforce someone from Altera (Dinh, Vince and myself) to review and ack each submitted patch. We would also able to help to test and offer any troubleshooting assistant to the patch submitter. Hopefully would get a green light from everyone. We really appreciate Marek's suggestion as the repo is a great idea to speed up the SOCFPGA patch submission process. It will offload some of Albert's heavy load too as currently we heavily rely for Albert to integrate SOCFPGA patches. Due to that, to benefit everyone, we would like to have this repo as soon as possible. Thanks Chin Liang Wonder any green light on this? The repo would help to speed up the SOCFPGA development especially for the on-going reviewing and testing of Marek's patches. Thanks Chin Liang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/16] samsung: Enable device tree for s5p_goni
Hi,
On 09/15/2014 12:12 AM, Simon Glass wrote:
Change this board to add a device tree.
This also adds a pinmux header file although it is not used as yet.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Avoid using a common file, and just add a device tree
- Fix device tree base addresses
arch/arm/dts/Makefile | 1 +
arch/arm/dts/s5pc1xx-goni.dts | 28 ++
arch/arm/include/asm/arch-s5pc1xx/periph.h | 61
++
arch/arm/include/asm/arch-s5pc1xx/pinmux.h | 50
drivers/mmc/s5p_sdhci.c| 2 -
include/configs/s5p_goni.h | 7 +++-
6 files changed, 146 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/dts/s5pc1xx-goni.dts
create mode 100644 arch/arm/include/asm/arch-s5pc1xx/periph.h
create mode 100644 arch/arm/include/asm/arch-s5pc1xx/pinmux.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f72207d..8a8ee56 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1,3 +1,4 @@
+dtb-$(CONFIG_S5PC110) += s5pc1xx-goni.dtb
dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
exynos4210-universal_c210.dtb \
diff --git a/arch/arm/dts/s5pc1xx-goni.dts b/arch/arm/dts/s5pc1xx-goni.dts
new file mode 100644
index 000..64d6bd3
--- /dev/null
+++ b/arch/arm/dts/s5pc1xx-goni.dts
@@ -0,0 +1,28 @@
+/*
+ * Samsung's S5PC110-based Goni board device tree source
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+/dts-v1/;
+
+#include skeleton.dtsi
+
+/ {
+ model = Samsung Goni based on S5PC110;
+ compatible = samsung,goni, samsung,s5pc110;
+
+ aliases {
+ serial0 = /serial@e290;
+ console = /serial@e290;
+ };
+
+ serial@e290 {
+ compatible = samsung,exynos4210-uart;
+ reg = 0xe290 0x100;
+ interrupts = 0 51 0;
+ id = 0;
+ };
At goni platform default serial used for console is uart2, so it should
be rather like this:
+ aliases {
+ serial2 = /serial@e2900800;
+ console = /serial@e2900800;
+ };
+
+ serial@e2900800 {
+ compatible = samsung,exynos4210-uart;
+ reg = 0xe2900800 0x400;
+ id = 2;
+ };
+};
diff --git a/arch/arm/include/asm/arch-s5pc1xx/periph.h
b/arch/arm/include/asm/arch-s5pc1xx/periph.h
new file mode 100644
index 000..5c1c3d4
--- /dev/null
+++ b/arch/arm/include/asm/arch-s5pc1xx/periph.h
@@ -0,0 +1,61 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ * Rajeshwari Shinde rajeshwar...@samsung.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __ASM_ARM_ARCH_PERIPH_H
+#define __ASM_ARM_ARCH_PERIPH_H
+
+/*
+ * Peripherals required for pinmux configuration. List will
+ * grow with support for more devices getting added.
+ * Numbering based on interrupt table.
+ *
+ */
+enum periph_id {
+ PERIPH_ID_UART0 = 51,
+ PERIPH_ID_UART1,
+ PERIPH_ID_UART2,
+ PERIPH_ID_UART3,
+ PERIPH_ID_I2C0 = 56,
+ PERIPH_ID_I2C1,
+ PERIPH_ID_I2C2,
+ PERIPH_ID_I2C3,
+ PERIPH_ID_I2C4,
+ PERIPH_ID_I2C5,
+ PERIPH_ID_I2C6,
+ PERIPH_ID_I2C7,
+ PERIPH_ID_SPI0 = 68,
+ PERIPH_ID_SPI1,
+ PERIPH_ID_SPI2,
+ PERIPH_ID_SDMMC0 = 75,
+ PERIPH_ID_SDMMC1,
+ PERIPH_ID_SDMMC2,
+ PERIPH_ID_SDMMC3,
+ PERIPH_ID_I2C8 = 87,
+ PERIPH_ID_I2C9,
+ PERIPH_ID_I2S0 = 98,
+ PERIPH_ID_I2S1 = 99,
+
+ /* Since following peripherals do
+ * not have shared peripheral interrupts (SPIs)
+ * they are numbered arbitiraly after the maximum
+ * SPIs Exynos has (128)
+ */
+ PERIPH_ID_SROMC = 128,
+ PERIPH_ID_SPI3,
+ PERIPH_ID_SPI4,
+ PERIPH_ID_SDMMC4,
+ PERIPH_ID_PWM0,
+ PERIPH_ID_PWM1,
+ PERIPH_ID_PWM2,
+ PERIPH_ID_PWM3,
+ PERIPH_ID_PWM4,
+ PERIPH_ID_I2C10 = 203,
+
+ PERIPH_ID_NONE = -1,
+};
+
+#endif /* __ASM_ARM_ARCH_PERIPH_H */
diff --git a/arch/arm/include/asm/arch-s5pc1xx/pinmux.h
b/arch/arm/include/asm/arch-s5pc1xx/pinmux.h
new file mode 100644
index 000..0b91ef6
--- /dev/null
+++ b/arch/arm/include/asm/arch-s5pc1xx/pinmux.h
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ * Abhilash Kesavan a.kesa...@samsung.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __ASM_ARM_ARCH_PINMUX_H
+#define __ASM_ARM_ARCH_PINMUX_H
+
+#include periph.h
+
+/*
+ * Flags for setting specific configarations of peripherals.
+ * List will grow with support for more devices getting added.
+ */
+enum {
+ PINMUX_FLAG_NONE= 0x,
+
+ /* Flags for eMMC */
+ PINMUX_FLAG_8BIT_MODE = 1 0, /* SDMMC 8-bit mode */
+
+ /* Flags for SROM
[U-Boot] [PATCH] armv7: s5pc1xx: improve cache handling
Move cache handling code to C file, and add enable_caches() and
disable_caches() functions.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
arch/arm/cpu/armv7/s5pc1xx/cache.S | 30
arch/arm/cpu/armv7/s5pc1xx/cache.c | 47 ++
2 files changed, 47 insertions(+), 30 deletions(-)
delete mode 100644 arch/arm/cpu/armv7/s5pc1xx/cache.S
create mode 100644 arch/arm/cpu/armv7/s5pc1xx/cache.c
diff --git a/arch/arm/cpu/armv7/s5pc1xx/cache.S
b/arch/arm/cpu/armv7/s5pc1xx/cache.S
deleted file mode 100644
index 3089592..000
--- a/arch/arm/cpu/armv7/s5pc1xx/cache.S
+++ /dev/null
@@ -1,30 +0,0 @@
-/*
- * Copyright (C) 2009 Samsung Electronics
- * Minkyu Kang mk7.k...@samsung.com
- *
- * based on arch/arm/cpu/armv7/omap3/cache.S
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-.align 5
-
-#include linux/linkage.h
-
-#ifndef CONFIG_SYS_L2CACHE_OFF
-ENTRY(v7_outer_cache_enable)
- push{r0, r1, r2, lr}
- mrc 15, 0, r3, cr1, cr0, 1
- orr r3, r3, #2
- mcr 15, 0, r3, cr1, cr0, 1
- pop {r1, r2, r3, pc}
-ENDPROC(v7_outer_cache_enable)
-
-ENTRY(v7_outer_cache_disable)
- push{r0, r1, r2, lr}
- mrc 15, 0, r3, cr1, cr0, 1
- bic r3, r3, #2
- mcr 15, 0, r3, cr1, cr0, 1
- pop {r1, r2, r3, pc}
-ENDPROC(v7_outer_cache_disable)
-#endif
diff --git a/arch/arm/cpu/armv7/s5pc1xx/cache.c
b/arch/arm/cpu/armv7/s5pc1xx/cache.c
new file mode 100644
index 000..51af299
--- /dev/null
+++ b/arch/arm/cpu/armv7/s5pc1xx/cache.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright (C) 2014 Samsung Electronics
+ * Minkyu Kang mk7.k...@samsung.com
+ * Robert Baldyga r.bald...@samsung.com
+ *
+ * based on arch/arm/cpu/armv7/omap3/cache.S
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+
+#ifndef CONFIG_SYS_DCACHE_OFF
+void enable_caches(void)
+{
+ dcache_enable();
+}
+
+void disable_caches(void)
+{
+ dcache_disable();
+}
+#endif
+
+#ifndef CONFIG_SYS_L2CACHE_OFF
+void v7_outer_cache_enable(void)
+{
+ __asm(
+ push{r0, r1, r2, lr}\n\t
+ mrc 15, 0, r3, cr1, cr0, 1\n\t
+ orr r3, r3, #2\n\t
+ mcr 15, 0, r3, cr1, cr0, 1\n\t
+ pop {r1, r2, r3, pc}
+ );
+}
+
+void v7_outer_cache_disable(void)
+{
+ __asm(
+ push{r0, r1, r2, lr}\n\t
+ mrc 15, 0, r3, cr1, cr0, 1\n\t
+ bic r3, r3, #2\n\t
+ mcr 15, 0, r3, cr1, cr0, 1\n\t
+ pop {r1, r2, r3, pc}
+ );
+}
+#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] socfpga: Enable SDMMC boot for SOCFPGA U-Boot
To enable the SDMMC boot as default boot for SOCFPGA
U-Boot dev kit. Enabled the bootz command as
zImage is used instead uImage.
Signed-off-by: Chin Liang See cl...@altera.com
Cc: Dinh Nguyen dingu...@altera.com
Cc: Pavel Machek pa...@denx.de
Cc: Marek Vasut ma...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Wolfgang Denk w...@denx.de
---
include/configs/socfpga_cyclone5.h | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/include/configs/socfpga_cyclone5.h
b/include/configs/socfpga_cyclone5.h
index f9fafac..3d1b78f 100644
--- a/include/configs/socfpga_cyclone5.h
+++ b/include/configs/socfpga_cyclone5.h
@@ -93,6 +93,8 @@
#include config_cmd_default.h
/* FAT file system support */
#define CONFIG_CMD_FAT
+/* bootz command support */
+#define CONFIG_CMD_BOOTZ
/*
@@ -117,24 +119,36 @@
#define CONFIG_SYS_PROMPT_HUSH_PS2
#define CONFIG_CMD_RUN
+#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
#define CONFIG_BOOTCOMMAND run ramboot
+#else
+#define CONFIG_BOOTCOMMAND run mmcload; run mmcboot
+#endif
/*
* arguments passed to the bootm command. The value of
* CONFIG_BOOTARGS goes into the environment value bootargs.
* Do note the value will overide also the chosen node in FDT blob.
*/
-#define CONFIG_BOOTARGS console=ttyS0,57600,mem=256M@0x0
+#define CONFIG_BOOTARGS console=ttyS0, __stringify(CONFIG_BAUDRATE)
#define CONFIG_EXTRA_ENV_SETTINGS \
verify=n\0 \
loadaddr= __stringify(CONFIG_SYS_LOAD_ADDR) \0 \
ramboot=setenv bootargs CONFIG_BOOTARGS ; \
bootm ${loadaddr} - ${fdt_addr}\0 \
- bootimage=uImage\0 \
+ bootimage=zImage\0 \
fdt_addr=100\0 \
+ fdtimage=socfpga.dtb\0 \
fsloadcmd=ext2load\0 \
- bootm ${loadaddr} - ${fdt_addr}\0 \
+ bootm ${loadaddr} - ${fdt_addr}\0 \
+ mmcroot=/dev/mmcblk0p2\0 \
+ mmcboot=setenv bootargs CONFIG_BOOTARGS \
+root=${mmcroot} rw rootwait; \
+ bootz ${loadaddr} - ${fdt_addr}\0 \
+ mmcload=mmc rescan; \
+ fatload mmc 0:1 ${loadaddr} ${bootimage}; \
+ fatload mmc 0:1 ${fdt_addr} ${fdtimage}\0 \
qspiroot=/dev/mtdblock0\0 \
qspirootfstype=jffs2\0 \
qspiboot=setenv bootargs CONFIG_BOOTARGS \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
Hi guys, On Fri, 2014-09-19 at 04:32 -0500, Chin Liang See wrote: Hi Marek, On Wed, 2014-09-17 at 14:39 +0200, ma...@denx.de wrote: On Wednesday, September 17, 2014 at 02:00:42 PM, Chin Liang See wrote: On Wed, 2014-09-17 at 13:52 +0200, ma...@denx.de wrote: On Wednesday, September 17, 2014 at 01:29:15 PM, Chin Liang See wrote: 3. MMC is not enabled in SocFPGA. I recall there is a patch from Pavel. I believe its pending for v2 due to some comments. This should be in the tree in fact. Is CONFIG_CMD_MMC defined ? I didn't see any MMC configuration at include/configs/socfpga_cyclone5 at mainline nor the new patch series. Wonder I might miss out any ACKed patch? Oh I see. I have this enabled in the repository here, but I didn't submit that change since it needs more work. The code is there , added in the patch arm: socfpga: misc: Add SD controller init The change for the SoCFPGA config file is missing though. Yup, I just submit the patch to add that socfpga: Enable DWMMC for SOCFPGA. With this added, the SDMMC is working well at U-Boot. This including all the 35 patches from you. Something to cheer during the weekend :) I just submitted a patch socfpga: Enable SDMMC boot for SOCFPGA U-Boot. This will enable the SDMMC boot as default boot for Altera dev kit. With that, I am able to success boot till Linux 3.10 LTSi successfully :) Thanks Chin Liang U-Boot 2014.10-rc2-00126-g77676b6 (Sep 19 2014 - 05:28:06) CPU: Altera SoCFPGA Platform BOARD: Altera SoCFPGA Cyclone5 Board DRAM: 1 GiB WARNING: Caches not enabled MMC: SOCFPGA DWMMC: 0 Using default environment In:serial Out: serial Err: serial Net: dwmac.ff702000 Error: dwmac.ff702000 address not set. Warning: Your board does not use generic board. Please read doc/README.generic-board and take action. Boards not upgraded by the late 2014 may break or be removed. Hit any key to stop autoboot: 0 reading zImage 3525736 bytes read in 196 ms (17.2 MiB/s) reading socfpga.dtb 19247 bytes read in 8 ms (2.3 MiB/s) Kernel image @ 0x007fc0 [ 0x00 - 0x35cc68 ] ## Flattened Device Tree blob at 0100 Booting using the fdt blob at 0x000100 Loading Device Tree to 0fff7000, end 0fffeb2e ... OK Starting kernel ... Booting Linux on physical CPU 0x0 Initializing cgroup subsys cpuset Linux version 3.10.31-ltsi (jdasilva@sj-interactive3) (gcc version 4.8.3 20140401 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.04 - Linaro GCC 4.8-2014.04) ) #1 SMP Wed Sep 17 00:24:24 PDT 2014 CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: Altera SOCFPGA, model: Altera SOCFPGA Cyclone V Memory policy: ECC disabled, Data cache writealloc PERCPU: Embedded 8 pages/cpu @80f7 s11200 r8192 d13376 u32768 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1024MB = 1024MB total Memory: 1031884k/1031884k available, 16692k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xc080 - 0xff00 (1000 MB) lowmem : 0x8000 - 0xc000 (1024 MB) modules : 0x7f00 - 0x8000 ( 16 MB) .text : 0x80008000 - 0x8068cab0 (6675 kB) .init : 0x8068d000 - 0x806e3bc0 ( 347 kB) .data : 0x806e4000 - 0x807204d0 ( 242 kB) .bss : 0x807204d0 - 0x80761cb4 ( 262 kB) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Hierarchical RCU implementation. NR_IRQS:16 nr_irqs:16 16 sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 42949ms Console: colour dummy device 80x30 Calibrating delay loop... 1836.64 BogoMIPS (lpj=9183232) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok ftrace: allocating 17914 entries in 53 pages CPU0: thread -1, cpu 0, socket 0, mpidr 8000 Setting up static identity map for 0x804d39c8 - 0x804d3a20 CPU1: Booted secondary processor CPU1: thread -1, cpu 1, socket 0, mpidr 8001 Brought up 2 CPUs SMP: Total of 2 processors activated (3679.84 BogoMIPS). CPU: All CPU(s) started in SVC mode. devtmpfs: initialized NET: Registered protocol family 16 fpga bridge driver DMA: preallocated 256 KiB pool for atomic coherent allocations L310 cache controller enabled l2x0: 8 ways, CACHE_ID 0x410030c9, AUX_CTRL 0x3246, Cache size: 524288 B syscon fffef000.l2-cache: regmap [mem 0xfffef000-0xfffe] registered syscon ffd05000.rstmgr: regmap [mem 0xffd05000-0xffd05fff] registered syscon ffc25000.sdrctl: regmap [mem 0xffc25000-0xffc25fff] registered syscon ff80.l3regs:
Re: [U-Boot] [PATCH] socfpga: Enable SDMMC boot for SOCFPGA U-Boot
On Friday, September 19, 2014 at 12:33:19 PM, Chin Liang See wrote:
To enable the SDMMC boot as default boot for SOCFPGA
U-Boot dev kit. Enabled the bootz command as
zImage is used instead uImage.
Signed-off-by: Chin Liang See cl...@altera.com
Cc: Dinh Nguyen dingu...@altera.com
Cc: Pavel Machek pa...@denx.de
Cc: Marek Vasut ma...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Wolfgang Denk w...@denx.de
---
include/configs/socfpga_cyclone5.h | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/include/configs/socfpga_cyclone5.h
b/include/configs/socfpga_cyclone5.h index f9fafac..3d1b78f 100644
--- a/include/configs/socfpga_cyclone5.h
+++ b/include/configs/socfpga_cyclone5.h
@@ -93,6 +93,8 @@
#include config_cmd_default.h
/* FAT file system support */
#define CONFIG_CMD_FAT
+/* bootz command support */
+#define CONFIG_CMD_BOOTZ
/*
@@ -117,24 +119,36 @@
#define CONFIG_SYS_PROMPT_HUSH_PS2
#define CONFIG_CMD_RUN
+#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
#define CONFIG_BOOTCOMMAND run ramboot
+#else
+#define CONFIG_BOOTCOMMAND run mmcload; run mmcboot
+#endif
/*
* arguments passed to the bootm command. The value of
* CONFIG_BOOTARGS goes into the environment value bootargs.
* Do note the value will overide also the chosen node in FDT blob.
*/
-#define CONFIG_BOOTARGS console=ttyS0,57600,mem=256M@0x0
+#define CONFIG_BOOTARGS console=ttyS0, __stringify(CONFIG_BAUDRATE)
#define CONFIG_EXTRA_ENV_SETTINGS \
verify=n\0 \
loadaddr= __stringify(CONFIG_SYS_LOAD_ADDR) \0 \
ramboot=setenv bootargs CONFIG_BOOTARGS ; \
bootm ${loadaddr} - ${fdt_addr}\0 \
- bootimage=uImage\0 \
+ bootimage=zImage\0 \
fdt_addr=100\0 \
+ fdtimage=socfpga.dtb\0 \
fsloadcmd=ext2load\0 \
- bootm ${loadaddr} - ${fdt_addr}\0 \
+ bootm ${loadaddr} - ${fdt_addr}\0 \
+ mmcroot=/dev/mmcblk0p2\0 \
+ mmcboot=setenv bootargs CONFIG_BOOTARGS \
+ root=${mmcroot} rw rootwait; \
+ bootz ${loadaddr} - ${fdt_addr}\0 \
+ mmcload=mmc rescan; \
+ fatload mmc 0:1 ${loadaddr} ${bootimage}; \
+ fatload mmc 0:1 ${fdt_addr} ${fdtimage}\0 \
This doesn't scale, we should start using CONFIG_CMD_FS_GENERIC + the load
command. I'll cook a patch for that and submit it alongside V2 of the patches.
qspiroot=/dev/mtdblock0\0 \
qspirootfstype=jffs2\0 \
qspiboot=setenv bootargs CONFIG_BOOTARGS \
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 00/35][RFC] arm: socfpga: Usability fixes
On Friday, September 19, 2014 at 12:36:41 PM, Chin Liang See wrote: Hi guys, On Fri, 2014-09-19 at 04:32 -0500, Chin Liang See wrote: Hi Marek, On Wed, 2014-09-17 at 14:39 +0200, ma...@denx.de wrote: On Wednesday, September 17, 2014 at 02:00:42 PM, Chin Liang See wrote: On Wed, 2014-09-17 at 13:52 +0200, ma...@denx.de wrote: On Wednesday, September 17, 2014 at 01:29:15 PM, Chin Liang See wrote: 3. MMC is not enabled in SocFPGA. I recall there is a patch from Pavel. I believe its pending for v2 due to some comments. This should be in the tree in fact. Is CONFIG_CMD_MMC defined ? I didn't see any MMC configuration at include/configs/socfpga_cyclone5 at mainline nor the new patch series. Wonder I might miss out any ACKed patch? Oh I see. I have this enabled in the repository here, but I didn't submit that change since it needs more work. The code is there , added in the patch arm: socfpga: misc: Add SD controller init The change for the SoCFPGA config file is missing though. Yup, I just submit the patch to add that socfpga: Enable DWMMC for SOCFPGA. With this added, the SDMMC is working well at U-Boot. This including all the 35 patches from you. Something to cheer during the weekend :) I just submitted a patch socfpga: Enable SDMMC boot for SOCFPGA U-Boot. This will enable the SDMMC boot as default boot for Altera dev kit. With that, I am able to success boot till Linux 3.10 LTSi successfully :) We still have a few bugs in the DWMMC driver when using eMMC card, but that's a problem with a particular eMMC card I think. I'll have to look into it. I will pick your patch and re-post the entire bulk today or tomorrow with the suggested changes. 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] socfpga: Enable DWMMC for SOCFPGA
On Friday, September 19, 2014 at 11:28:23 AM, Chin Liang See wrote: To enable the DesignWare MMC controller driver support for SOCFPGA Cyclone5 dev kit Signed-off-by: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc: Pavel Machek pa...@denx.de Cc: Marek Vasut ma...@denx.de Cc: Tom Rini tr...@ti.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Wolfgang Denk w...@denx.de --- include/configs/socfpga_cyclone5.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/include/configs/socfpga_cyclone5.h b/include/configs/socfpga_cyclone5.h index 32175b7..f9fafac 100644 --- a/include/configs/socfpga_cyclone5.h +++ b/include/configs/socfpga_cyclone5.h @@ -252,6 +252,24 @@ /* Clocks source frequency to watchdog timer */ #define CONFIG_DW_WDT_CLOCK_KHZ 25000 +/* + * MMC support + */ +#define CONFIG_MMC +#ifdef CONFIG_MMC +#define CONFIG_CMD_MMC +#define CONFIG_SDMMC_BASE(SOCFPGA_SDMMC_ADDRESS) This symbol doesn't exist. +#define CONFIG_SDMMC_HOST_HS This symbol doesn't exist. +#define CONFIG_GENERIC_MMC 1 You don't actually need to define this to have a value. +#define CONFIG_DWMMC +#define CONFIG_SOCFPGA_DWMMC +#define CONFIG_SOCFPGA_DWMMC_FIFO_DEPTH 1024 +#define CONFIG_SOCFPGA_DWMMC_DRVSEL 3 +#define CONFIG_SOCFPGA_DWMMC_SMPSEL 0 +#define CONFIG_BOUNCE_BUFFER +/* using smaller max blk cnt to avoid flooding the limited stack we have */ +#define CONFIG_SYS_MMC_MAX_BLK_COUNT 256 This is something I am wondering about (btw. you might have seen a FIXME tag in my repository right next to this code). Do we really need this in U-Boot or is this portion SPL specific ? Or do we even need this limit at all ? [...] Anyway, I will pick them in my tree and add a bit more magic sause to them , then re-post the whole series. 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 00/35][RFC] arm: socfpga: Usability fixes
On Friday, September 19, 2014 at 11:44:48 AM, Chin Liang See wrote: Dear Wolfgang, On Wed, 2014-09-17 at 16:11 +0200, ZY - wd wrote: Dear Chin Liang See, In message 1410952049.7769.11.ca...@clsee-virtualbox.altera.com you wrote: Hmmm... actually I can get it works well for my Altera dev kit. The get_dram_size would take in the argument PHYS_SDRAM_1_SIZE. From here, the function will ensure the memory specified can read and writable. If its failing here, probably the SDRAM access might have issue. FYI, PHYS_SDRAM_1_SIZE is 0x4000 for 1GB. Normally, get_dram_size() would be called with a size argument that is _larger_ (twice as big) as the biggest possible memory configuration on the respective device. Otherwise it can only detect smaller memory sizes, but would fail to detect if a bigger memory device is installed by accident. Yup, you are right. But currently, the memory space after the SDRAM is a bridge to FPGA. We will get data abort when trying to read that area (for a blank FPGA). This is good, no ? If you reliably get DABT if the H2F bridge is disabled, you can place the trampoline into the DABT vector and detect DRAM size. I'll have to test this. I believe Marek's suggestion to work around the DABT and memory detection would work around SOCFPGA memory detection. Its something we would work closely with Marek to enable this auto detection. OK ;-) 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 00/35][RFC] arm: socfpga: Usability fixes
On Friday, September 19, 2014 at 01:12:23 PM, Marek Vasut wrote: On Friday, September 19, 2014 at 11:44:48 AM, Chin Liang See wrote: Dear Wolfgang, On Wed, 2014-09-17 at 16:11 +0200, ZY - wd wrote: Dear Chin Liang See, In message 1410952049.7769.11.ca...@clsee-virtualbox.altera.com you wrote: Hmmm... actually I can get it works well for my Altera dev kit. The get_dram_size would take in the argument PHYS_SDRAM_1_SIZE. From here, the function will ensure the memory specified can read and writable. If its failing here, probably the SDRAM access might have issue. FYI, PHYS_SDRAM_1_SIZE is 0x4000 for 1GB. Normally, get_dram_size() would be called with a size argument that is _larger_ (twice as big) as the biggest possible memory configuration on the respective device. Otherwise it can only detect smaller memory sizes, but would fail to detect if a bigger memory device is installed by accident. Yup, you are right. But currently, the memory space after the SDRAM is a bridge to FPGA. We will get data abort when trying to read that area (for a blank FPGA). This is good, no ? If you reliably get DABT if the H2F bridge is disabled, you can place the trampoline into the DABT vector and detect DRAM size. I'll have to test this. Aw snap, on my hardware, when I access past SDRAM, I am getting a wrap around. What's worse is that I can reliably read and write from that location. This renders get_ram_size() unusable. All right, guys, ideas ? 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 v4 2/6] serial: add UniPhier serial driver
Hi Simon,
On Fri, 5 Sep 2014 10:41:54 -0600
Simon Glass s...@chromium.org wrote:
Do you think we could use driver model instead? We have the serial
infrastructure in place and I will likely merge it next week.
It moves the \r\n logic to a higher level.
It also removes the need for all the horrible #define stuff you have
here to deal with multiple serial ports.
I am seeing serial_find_console_or_panic() func
in drivers/serial/serial-uclass.c
static void serial_find_console_or_panic(void)
{
int node;
/* Check for a chosen console */
node = fdtdec_get_chosen_node(gd-fdt_blob, stdout-path);
if (node 0)
node = fdtdec_get_alias_node(gd-fdt_blob, console);
if (!uclass_get_device_by_of_offset(UCLASS_SERIAL, node, cur_dev))
return;
/*
* If the console is not marked to be bound before relocation, bind
* it anyway.
*/
if (node 0
!lists_bind_fdt(gd-dm_root, gd-fdt_blob, node, cur_dev)) {
if (!device_probe(cur_dev))
return;
cur_dev = NULL;
}
It looks like CONFIG_DM_SERIAL depends on CONFIG_OF_CONTROL.
UniPhier SoCs do not support device tree control.
Is the driver model serial still available?
What will happen if gd-fdt_blob is not set?
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Many questions about U-Boot's Driver Model
Hi.
I am digging into the driver model.
I fear this triggers a controversy, but, first,
it looks like the driver model of U-Boot is pretty different from
the Linux's one, in spite of the fact that U-Boot has ported lots of
Linux sources and ideas (looks like U-Boot is getting a mirror of Linux)
and most of U-Boot developers are also working on Linux development.
This seems kind of unfortunate because
we have to study a new driver model in addition to Linux's one.
(Perhaps isn't it an obstacle in the future?)
[1] Why is usage (needed to be) different?
I expect the usage is something like this:
static int foo_init(void)
{
return foo_driver_register(vendorA_foo_driver);
}
module_init(foo_init)
I mean, something is triggered by registering something
in each init function.
[2] Why uclass?
In Linux, struct device_driver is something like a superclass
of each driver such platform_driver, uart_driver, usb_driver.
Usually, struct foo_device includes(inherits) struct device
and struct foo_driver includes struct device_driver.
|| |--|
|| | |
| struct device | | struct device_driver |
|| | |
|| |--|
/|\ /|\
| | include (inherit)
| |
|| |---|
| struct | | struct|
| platform_device | | platform_driver |
|| | |
|| |---|
struct uclass is a totally different approach.
For ex.
int demo_hello(struct udevice *dev, int ch)
takes a pointer to struct udevice, but it must be the one of
DEMO class.
We can still pass a udevice belonging to GPIO class,
which the compiler never complains about, but it will crash at run time.
I'd like to know the philosophy in the background of this approach.
[3] Is platform driver(device) a special case?
I am not sure if I understood correctly,
but it looks like platform data in U-Boot is a special case.
I do not understand well the difference between
platdata and priv (private data).
The platform driver(platform device) is derived from
device_driver(device), isn't it?
[4] What does struct driver_info stand for?
I cannot understand the following comment block at all.
/**
* struct driver_info - Information required to instantiate a device
*
* @name: Device name
* @platdata: Driver-specific platform data
*/
struct driver_info {
const char *name;
const void *platdata;
};
Does this structure give information of a driver or a device?
My first guess was the former because of the name driver_info.
But this comment says, the name member of struct drive_info
means Device name.
Moreover, U_BOOT_DEVICE macro is a shorthand of struct driver_info.
U_BOOT_DEVICE(demo0) = {
.name = demo_shape_drv,
.platdata = red_square,
};
U_BOOT_DEVICE(demo1) = {
.name = demo_simple_drv,
.platdata = red_square,
};
U_BOOT_DEVICE(demo2) = {
.name = demo_shape_drv,
.platdata = green_triangle,
};
looks like instances of devices, not drivers.
I am wordering if struct driver_info should have been named struct
device_info?
I found another confusing part.
/**
* lists_bind_drivers() - search for and bind all drivers to parent
*
* This searches the U_BOOT_DEVICE() structures and creates new devices for
* each one. The devices will have @parent as their parent.
*
* @parent: parent driver (root)
* @early_only: If true, bind only drivers with the DM_INIT_F flag. If false
* bind all drivers.
*/
int lists_bind_drivers(struct udevice *parent, bool pre_reloc_only)
This comment says, the parent argument is parent driver.
^^^
So, do you mean, struct udevice is a driver?
It is absolutely a device, right?
I think comments and namings are confusing.
Sorry if I am wrong.
Perhaps I am writing this mail without understaing the code correctly.
But I do not feel comfortable to move forward base on something I cannot
understand.
Also, I want to be sure if this is the right direction we should go to
before lots of conversions occur.
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARNDALE: Enhance arndale config to be more flexible on boot.
This patch enhances the boot of arndale board by adding support to bootz,
initrd, bootenv loading and boot script.
It still keeps the previous mmc load command if boot script fails.
Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr
Cc: Minkyu Kang mk7.k...@samsung.com
---
include/configs/arndale.h | 38 ++
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/include/configs/arndale.h b/include/configs/arndale.h
index 75f9933..edf9ee6 100644
--- a/include/configs/arndale.h
+++ b/include/configs/arndale.h
@@ -72,9 +72,6 @@
stdout=serial\0 \
stderr=serial\0
-#define CONFIG_EXTRA_ENV_SETTINGS \
- EXYNOS_DEVICE_SETTINGS
-
/* SD/MMC configuration */
#define CONFIG_GENERIC_MMC
#define CONFIG_MMC
@@ -103,8 +100,11 @@
#define CONFIG_CMD_MMC
#define CONFIG_CMD_EXT2
#define CONFIG_CMD_FAT
+#define CONFIG_CMD_FS_GENERIC
#define CONFIG_CMD_NET
#define CONFIG_CMD_HASH
+#define CONFIG_SUPPORT_RAW_INITRD
+#define CONFIG_CMD_BOOTZ
#define CONFIG_BOOTDELAY 3
#define CONFIG_ZERO_BOOTDELAY_CHECK
@@ -130,7 +130,37 @@
#define CONFIG_SPL_TEXT_BASE 0x02023400
#define CONFIG_SPL_MAX_FOOTPRINT (14 * 1024)
-#define CONFIG_BOOTCOMMAND mmc read 40007000 451 2000; bootm 40007000
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ EXYNOS_DEVICE_SETTINGS \
+ loadaddr=0x40007000\0 \
+ rdaddr=0x4f00\0 \
+ kerneladdr=0x40007000\0 \
+ ramdiskaddr=0x4f00\0 \
+ console=ttySAC2,115200n8\0 \
+ mmcdev=1\0 \
+ bootenv=uEnv.txt\0 \
+ loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
+ importbootenv=echo Importing environment from mmc ...; \
+ env import -t $loadaddr $filesize\0 \
+ loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr\0 \
+ bootscript=echo Running bootscript from mmc${mmcdev} ...; \
+ source ${loadaddr}\0
+#define CONFIG_BOOTCOMMAND \
+ if mmc rescan; then \
+ echo SD/MMC found on device ${mmcdev}; \
+ if run loadbootenv; then \
+ echo Loaded environment from ${bootenv}; \
+ run importbootenv; \
+ fi; \
+ if test -n $uenvcmd; then \
+ echo Running uenvcmd ...; \
+ run uenvcmd; \
+ fi; \
+ if run loadbootscript; then \
+ run bootscript; \
+ fi; \
+ fi; \
+ mmc read ${loadaddr} 451 2000; bootm ${loadaddr}
/* Miscellaneous configurable options */
#define CONFIG_SYS_LONGHELP/* undef to save memory */
--
1.8.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ORIGEN: Enhance origen config to be more flexible on boot.
This patch enhances the boot of origen board by adding support to ext2, bootz,
initrd, bootenv loading and boot script.
It still keeps the previous mmc load command if boot script fails.
Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr
Cc: Minkyu Kang mk7.k...@samsung.com
---
include/configs/origen.h | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/include/configs/origen.h b/include/configs/origen.h
index 5d24916..2117fe1 100644
--- a/include/configs/origen.h
+++ b/include/configs/origen.h
@@ -61,6 +61,10 @@
#undef CONFIG_CMD_PING
#define CONFIG_CMD_ELF
#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_BOOTZ
+#define CONFIG_SUPPORT_RAW_INITRD
#undef CONFIG_CMD_NET
#undef CONFIG_CMD_NFS
@@ -68,7 +72,36 @@
#define COPY_BL2_FNPTR_ADDR0x02020030
#define CONFIG_SPL_TEXT_BASE 0x02021410
-#define CONFIG_BOOTCOMMAND fatload mmc 0 40007000 uImage; bootm 40007000
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ loadaddr=0x40007000\0 \
+ rdaddr=0x4800\0 \
+ kerneladdr=0x40007000\0 \
+ ramdiskaddr=0x4800\0 \
+ console=ttySAC2,115200n8\0 \
+ mmcdev=0\0 \
+ bootenv=uEnv.txt\0 \
+ loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
+ importbootenv=echo Importing environment from mmc ...; \
+ env import -t $loadaddr $filesize\0 \
+ loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr\0 \
+ bootscript=echo Running bootscript from mmc${mmcdev} ...; \
+ source ${loadaddr}\0
+#define CONFIG_BOOTCOMMAND \
+ if mmc rescan; then \
+ echo SD/MMC found on device ${mmcdev}; \
+ if run loadbootenv; then \
+ echo Loaded environment from ${bootenv}; \
+ run importbootenv; \
+ fi; \
+ if test -n $uenvcmd; then \
+ echo Running uenvcmd ...; \
+ run uenvcmd; \
+ fi; \
+ if run loadbootscript; then \
+ run bootscript; \
+ fi; \
+ fi; \
+ load mmc ${mmcdev} ${loadaddr} uImage; bootm ${loadaddr}
#define CONFIG_IDENT_STRING for ORIGEN
--
1.8.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ORIGEN: Enhance origen config to be more flexible on boot.
This patch enhances the boot of origen board by adding support to ext2, bootz,
initrd, bootenv loading and boot script.
It still keeps the previous mmc load command if boot script fails.
Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr
Cc: Minkyu Kang mk7.k...@samsung.com
---
include/configs/origen.h | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/include/configs/origen.h b/include/configs/origen.h
index 5d24916..2117fe1 100644
--- a/include/configs/origen.h
+++ b/include/configs/origen.h
@@ -61,6 +61,10 @@
#undef CONFIG_CMD_PING
#define CONFIG_CMD_ELF
#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_BOOTZ
+#define CONFIG_SUPPORT_RAW_INITRD
#undef CONFIG_CMD_NET
#undef CONFIG_CMD_NFS
@@ -68,7 +72,36 @@
#define COPY_BL2_FNPTR_ADDR0x02020030
#define CONFIG_SPL_TEXT_BASE 0x02021410
-#define CONFIG_BOOTCOMMAND fatload mmc 0 40007000 uImage; bootm 40007000
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ loadaddr=0x40007000\0 \
+ rdaddr=0x4800\0 \
+ kerneladdr=0x40007000\0 \
+ ramdiskaddr=0x4800\0 \
+ console=ttySAC2,115200n8\0 \
+ mmcdev=0\0 \
+ bootenv=uEnv.txt\0 \
+ loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
+ importbootenv=echo Importing environment from mmc ...; \
+ env import -t $loadaddr $filesize\0 \
+ loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr\0 \
+ bootscript=echo Running bootscript from mmc${mmcdev} ...; \
+ source ${loadaddr}\0
+#define CONFIG_BOOTCOMMAND \
+ if mmc rescan; then \
+ echo SD/MMC found on device ${mmcdev}; \
+ if run loadbootenv; then \
+ echo Loaded environment from ${bootenv}; \
+ run importbootenv; \
+ fi; \
+ if test -n $uenvcmd; then \
+ echo Running uenvcmd ...; \
+ run uenvcmd; \
+ fi; \
+ if run loadbootscript; then \
+ run bootscript; \
+ fi; \
+ fi; \
+ load mmc ${mmcdev} ${loadaddr} uImage; bootm ${loadaddr}
#define CONFIG_IDENT_STRING for ORIGEN
--
1.8.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A minor question on a Driver Model function
On 09/19/14 09:54, Masahiro Yamada wrote:
On Fri, 19 Sep 2014 09:34:53 +0300
Igor Grinberg grinb...@compulab.co.il wrote:
On 09/18/14 18:46, Bill Pringlemeir wrote:
On 12 September 2014 05:25, Masahiro Yamada
yamad...@jp.panasonic.com wrote:
I have a qustion about lists_driver_lookup_name() function.
On 09/14/14 21:28, Simon Glass wrote:
I would suggest still using strncmp as it is safer,
but count also the '\0', so something like:
On 17 Sep 2014, grinb...@compulab.co.il wrote:
Why safer?
Could you give me more detailed explanation?
On 09/17/14 11:18, Masahiro Yamada wrote:
Well, I'm not an expert in s/w security, but I'll try to explain...
[snip]
But, again, I'm not an expert in this area, so its only a
suggestion.
On 09/17/14 18:25, Bill Pringlemeir wrote:
I thought it was fairly apparent that the current code supports
passing a string that is *NOT* null terminated. This can be
convenient if you extract a sub-string from a command line and do not
need to make a copy that is NULL terminate or perform 'strtok()' type
magic.
On 18 Sep 2014, grinb...@compulab.co.il wrote:
Here is the whole function:
--cut--
struct driver *lists_driver_lookup_name(const char *name)
{
struct driver *drv =
ll_entry_start(struct driver, driver);
const int n_ents = ll_entry_count(struct driver, driver);
struct driver *entry;
int len;
if (!drv || !n_ents)
return NULL;
len = strlen(name);
for (entry = drv; entry != drv + n_ents; entry++) {
if (strncmp(name, entry-name, len))
continue;
/* Full match */
if (len == strlen(entry-name))
return entry;
/* Not found */
return NULL;
--cut--
and... no, the code does not support passing a string that is
not null terminated.
Then using the strncmp() seems useless for security reasons? The 'len'
is not passed in by the caller and 'strlen()' will have the same
problems that 'strcmp()' would for read buffer overflows? I would guess
the code was cribbed from where 'len' was passed? In that case, it
would support strings that are not null terminated.
Yes, that is correct.
Since we are dealing with device/driver names here.
I think the best would be to define a sane name length limit
(say 20 or more characters) and use it as the maximal length
if no '\0' found before the limit.
I disagre.
The argument name of this function may be derived from a device tree,
that is, it is possibly not NULL-terminated
if U-Boot is accidentally given a corrupted device tree.
If this can happen, then the name length limit is even more sensible...
On the other hand, entry-name originates in
a U_BOOT_DRIVER() instance.
For example, something like this
U_BOOT_DRIVER(root_driver) = {
.name = root_driver,
.id = UCLASS_ROOT,
};
The .name member of U_BOOT_DRIVER is guaranteed
to be NULL-terminated.
I'd say the chances for _not_ having .name null terminated are
quite low, but I fail to find something that guarantees this.
May be I'm missing something, but you still can mess with
the .name field, right?
I'd say, strcmp(name, entry-name) is always safe.
(In the current code,
len = strlen(name); is *NOT* safe,
but,
len = strlen(entry-name); is safe
Yes, this was actually the first though that came into my mind, but
I wanted to take it a step further.
I agree that running strlen(entry-name) is better than
running it with name argument.
Yet, having a strong limit will prevent various corner cases.
Or, I'm just being too much paranoid/pedantic, and using
entry-name as an argument would be enough...
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] After relocate the printf not working
Hi!
I have a LPC1788 board with 32Mbyte RAM and NAND flash and I followed the
nxp instructions:
http://www.lpcware.com/content/project/lpc177x8x-u-boot-port/u-boot-build-procedure
The result is:
U-Boot 2011.06 (Aug 16 2011 - 16:47:50)
NXP LPC1788 Cortex-M3
DRAM: 32 MiB
Flash: e1z K!A
NAND: y2x#Mi
#foeid !f pide 65472+ vedsigz 0@1
#fojd !f pide 65408+ vedsigz 0@1
pro!whoe sadiyg fd hocK!tae
naf_rued_Zbt:8@adnaf_rued_Zbt:8@ad``lokk ad40x0012ztae
naf_rued_Zbt:8@ad``lokk ad40x00140x00ztae
naf_rued_Zbt:8@adnaf_rued_Zbt:8@ad``lokk ad40x0018
tae
naf_rued_Zbt:8@ad``lokk ad40x001aztae
naf_rued_Zbt:8@adnaf_rued_Zbt:8@ad``lokk ad40x001eztae
sd rom(kffpt 4 fa9xed***0Wa
{viznm-|tdenv() failedL!usYxg `fa}{t
In: serial
Out: serial
Err: serial
uboot
I send a 'help' command:
uboot he
Uncmow0coMkan0'he'x9 trl 'uboot
uboot
I switch on the debug mode and I realized the printf and vsprintf not
working correctly after the relocated on the ram. The puts function is
works fine all the time. I tried the u-boot.hex from the nxp and the result
is same. I have no idea whats the problem. Please help me!
--
View this message in context:
http://u-boot.10912.n7.nabble.com/After-relocate-the-printf-not-working-tp189814.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] arm: ls102xa: Add SD boot support for LS1021AQDS board
Hi Huan,
On Thu, 18 Sep 2014 15:15:54 +, Huan Wang
alison.w...@freescale.com wrote:
Hi, Albert,
On Thu, 18 Sep 2014 13:47:18 +0800, Alison Wang b18...@freescale.com
wrote:
+
+ . = ALIGN(4);
+ .u_boot_list : {
+ KEEP(*(SORT(.u_boot_list*_i2c_*)));
+ }
IS this required? And if it is, could it not be added to the
arch/arm/cpu/u-boot-spl.lds file? This way you would not need an .lds
file at all.
[Alison Wang] Yes, it is required.
Ok -- what for? :)
I would like to add it in arch/arm/cpu/u-boot-spl.lds. I was not sure
adding it in arch/arm/cpu/u-boot-spl.lds is acceptable or not.
(assuming the reason why it is needed is valid) If it causes no change
to boards which do not use it right now (and I mean 'no change' ad
'binary identical') then this is acceptable. Make sure you check the
binary invariance and that you mention it in the commit.
Best Regards,
Alison Wang
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: ls102xa: Fixed a register definition error
Hi Yuantian,
On Fri, 19 Sep 2014 01:45:52 +, Yuantian Tang
yuantian.t...@freescale.com wrote:
-Original Message-
From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
Sent: Thursday, September 18, 2014 7:25 PM
To: Tang Yuantian-B29983
Cc: Wang Huan-B18965; Lu Jingchang-B35083; Jin Zhengxiong-R64188;
Kushwaha Prabhakar-B32579; u-boot@lists.denx.de
Subject: Re: [PATCH] arm: ls102xa: Fixed a register definition error
Hi Tang,
On Thu, 18 Sep 2014 17:12:06 +0800, Tang Yuantian
yuantian.t...@freescale.com wrote:
There are 8 SCFG_SPARECR registers in SCFG memory block, not just one.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 7995fe2..b5db720 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -182,7 +182,7 @@ struct ccsr_scfg {
u32 etsecmcr;
u32 sdhciovserlcr;
u32 resv14[61];
- u32 sparecr;
+ u32 sparecr[8];
};
/* Clocking */
Obviously the original code was not problematic as sparecr was not used. Is
your
change dictated by a patch or series that you are preparing and that will
use
sparecr?
Yes, they will be used by deep sleep patches I am preparing.
Then please post them inside the deep sleep patch series.
Thanks,
Yuantian
Amicalement,
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] ARMv8: PSCI: Add linker section to hold PSCI code
Hi Marc,
On Thu, 18 Sep 2014 16:28:52 +0100, Marc Zyngier marc.zyng...@arm.com
wrote:
On Thu, Sep 18 2014 at 10:12:17 AM, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:
Hi Arnab,
On Thu, 28 Aug 2014 01:59:57 +0530, Arnab Basu
arnab.b...@freescale.com wrote:
A separate linker section makes it possible to keep this code either
in DDR or in some secure memory location provided specifically for the
purpose.
So far no one is using this section.
Signed-off-by: Arnab Basu arnab.b...@freescale.com
Reviewed-by: Bhupesh Sharma bhupesh.sha...@freescale.com
Cc: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/config.mk|2 +-
arch/arm/cpu/armv8/u-boot.lds | 30 ++
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index c339e6d..9272e9c 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -111,7 +111,7 @@ endif
# limit ourselves to the sections we want in the .bin.
ifdef CONFIG_ARM64
-OBJCOPYFLAGS += -j .text -j .rodata -j .data -j .u_boot_list -j .rela.dyn
+OBJCOPYFLAGS += -j .text -j .secure_text -j .rodata -j .data -j
.u_boot_list -j .rela.dyn
else
OBJCOPYFLAGS += -j .text -j .secure_text -j .rodata -j .hash -j .data -j
.got.plt -j .u_boot_list -j .rel.dyn
endif
diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index 4c1..bd95fff 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -8,6 +8,8 @@
* SPDX-License-Identifier: GPL-2.0+
*/
+#include config.h
+
OUTPUT_FORMAT(elf64-littleaarch64, elf64-littleaarch64,
elf64-littleaarch64)
OUTPUT_ARCH(aarch64)
ENTRY(_start)
@@ -23,6 +25,34 @@ SECTIONS
*(.text*)
}
+#ifdef CONFIG_ARMV8_PSCI
+
+#ifndef CONFIG_ARMV8_SECURE_BASE
+#define CONFIG_ARMV8_SECURE_BASE
+#endif
+
+ .__secure_start : {
+ . = ALIGN(0x1000);
+ *(.__secure_start)
+ }
+
+ .secure_text CONFIG_ARMV8_SECURE_BASE :
+ AT(ADDR(.__secure_start) + SIZEOF(.__secure_start))
+ {
+ *(._secure.text)
+ }
+
+ . = LOADADDR(.__secure_start) +
+ SIZEOF(.__secure_start) +
+ SIZEOF(.secure_text);
+
+ __secure_end_lma = .;
+ .__secure_end : AT(__secure_end_lma) {
+ *(.__secure_end)
+ LONG(0x1d1071c);/* Must output something to reset LMA */
Can you explain in more detail what issue this fixes?
If you use AT to force a new load address (LMA), you must ensure that
you actually output something at this address. Here, if *(.__secure_end)
ends up being empty, whatever follows would be as if the AT never
happened, ending up at the wrong LMA.
The workaround is to force the output of a dummy value in all
cases, ensuring that the rest of the text is at a sensible LMA. This is
an issue that has been in GNU ld for years, and this workaround is a
copy/paste of the same one in the ARMv7 ld script.
I see. Does the ld bug have an identifier that we could mention in a
comment in the linker script as a reference?
Thanks,
M.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/3] spi:rewrite the Freescale DSPI driver.
Hi, On 18 September 2014 23:31, Chao Fu b44...@freescale.com wrote: From: Chao Fu b44...@freescale.com Freescale DSPI module is used on both the ColdFire platform and the ARM platform. The original DSPI driver is written for ColdFire platform only, this patch rewrite the driver to make it be used across the platforms. Some files, functions, variables and macros were changed accordingly for some ColdFire boards and Arm boards. The rewrite including the following changes: If you are doing this, would it not be better to target driver model instead? The current SPI implementation is at u-boot-dm.git branch 'working', although there are patches on the list also. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/6] serial: add UniPhier serial driver
HI Masahiro,
On 19 September 2014 06:15, Masahiro Yamada yamad...@jp.panasonic.com
wrote:
Hi Simon,
On Fri, 5 Sep 2014 10:41:54 -0600
Simon Glass s...@chromium.org wrote:
Do you think we could use driver model instead? We have the serial
infrastructure in place and I will likely merge it next week.
It moves the \r\n logic to a higher level.
It also removes the need for all the horrible #define stuff you have
here to deal with multiple serial ports.
I am seeing serial_find_console_or_panic() func
in drivers/serial/serial-uclass.c
static void serial_find_console_or_panic(void)
{
int node;
/* Check for a chosen console */
node = fdtdec_get_chosen_node(gd-fdt_blob, stdout-path);
if (node 0)
node = fdtdec_get_alias_node(gd-fdt_blob, console);
if (!uclass_get_device_by_of_offset(UCLASS_SERIAL, node, cur_dev))
return;
/*
* If the console is not marked to be bound before relocation, bind
* it anyway.
*/
if (node 0
!lists_bind_fdt(gd-dm_root, gd-fdt_blob, node, cur_dev)) {
if (!device_probe(cur_dev))
return;
cur_dev = NULL;
}
It looks like CONFIG_DM_SERIAL depends on CONFIG_OF_CONTROL.
UniPhier SoCs do not support device tree control.
Is the driver model serial still available?
What will happen if gd-fdt_blob is not set?
Please this patch.
http://patchwork.ozlabs.org/patch/390433/
I haven't got to a pull request yet for DM, but will do this in the next
few days.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] After relocate the printf not working
Hello Viktor?
On 19-09-14 16:01, nohabviktor wrote:
I have a LPC1788 board with 32Mbyte RAM and NAND flash and I followed the
nxp instructions:
http://www.lpcware.com/content/project/lpc177x8x-u-boot-port/u-boot-build-procedure
The result is:
U-Boot 2011.06 (Aug 16 2011 - 16:47:50)
NXP LPC1788 Cortex-M3
DRAM: 32 MiB
Flash: e1z K!A
NAND: y2x#Mi
#foeid !f pide 65472+ vedsigz 0@1
#fojd !f pide 65408+ vedsigz 0@1
pro!whoe sadiyg fd hocK!tae
naf_rued_Zbt:8@adnaf_rued_Zbt:8@ad``lokk ad40x0012ztae
naf_rued_Zbt:8@ad``lokk ad40x00140x00ztae
naf_rued_Zbt:8@adnaf_rued_Zbt:8@ad``lokk ad40x0018
tae
naf_rued_Zbt:8@ad``lokk ad40x001aztae
naf_rued_Zbt:8@adnaf_rued_Zbt:8@ad``lokk ad40x001eztae
sd rom(kffpt 4 fa9xed***0Wa
{viznm-|tdenv() failedL!usYxg `fa}{t
In: serial
Out: serial
Err: serial
uboot
I send a 'help' command:
uboot he
Uncmow0coMkan0'he'x9 trl 'uboot
uboot
I switch on the debug mode and I realized the printf and vsprintf not
working correctly after the relocated on the ram. The puts function is
works fine all the time. I tried the u-boot.hex from the nxp and tthe result
is same. I have no idea whats the problem. Please help me!
I doubt there are NXP people active over here, so you might need
to ask it themselves. Google says [1] might have support for mentioned
board. (I have no idea though if it builds or boots).
Regards,
Jeroen
[1]
https://github.com/EmcraftSystems/u-boot/blob/master/board/nxp/ea-lpc1788/board.c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: avoid dev-req_seq overflow
Hi Robert,
On 18 September 2014 23:25, Robert Baldyga r.bald...@samsung.com wrote:
On 09/18/2014 08:00 PM, Simon Glass wrote:
Hi Robert,
On 18 September 2014 09:13, Robert Baldyga r.bald...@samsung.com
mailto:r.bald...@samsung.com wrote:
Since dev-req_seq value is initialized from reg property of fdt node,
there is posibility, that address value contained in fdt is greater than
INT_MAX, and then value in dev-req_seq is negative which led to probe()
fail.
This patch fix this problem by ensuring that req_seq is positive, unless
it's one of errno codes.
Wouldn't this be a bug in the device tree file? What does it mean to
have a -ve value?
Device tree seems to be ok. We have:
pinctrl0: pinctrl@e020 {
compatible = samsung,s5pc110-pinctrl;
reg = 0xe020 0x1000;
};
So when we take address from reg as dev-req_seq, then value
0xe020 after casting to int gives -534773760. Function
uclass_resolve_seq() returns it as proper seq number, because it's
unique. But then in file drivers/core/device.c, in function
device_probe() we have:
seq = uclass_resolve_seq(dev);
if (seq 0) {
ret = seq;
goto fail;
}
And it will obviously fail.
Using reg value as req_seq doesn't work when this value is greater
than INT_MAX.
OK I see. Thanks for the clear explanation. We don't really want
req_seq for things that are not buses, but there is no real concept of
that in DM at this stage. Let's see how things pan out. For now, this
patch is a good solution.
Acked-by: Simon Glass s...@chromium.org
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Many questions about U-Boot's Driver Model
Hi Masahiro,
On 19 September 2014 07:22, Masahiro Yamada yamad...@jp.panasonic.com wrote:
Hi.
I am digging into the driver model.
Great! It would be good to add patches to the driver model README.txt
file with some of the results of this thread.
I fear this triggers a controversy, but, first,
it looks like the driver model of U-Boot is pretty different from
the Linux's one, in spite of the fact that U-Boot has ported lots of
Linux sources and ideas (looks like U-Boot is getting a mirror of Linux)
and most of U-Boot developers are also working on Linux development.
This seems kind of unfortunate because
we have to study a new driver model in addition to Linux's one.
(Perhaps isn't it an obstacle in the future?)
I believe what you are seeing in general is more that some of the
things which are driver-specific in Linux are catered for in the
framework in U-Boot. For example:
- nearly every device has private state, in Linux you have to allocate
memory for it, although the devm_... functions try to make the patern
more common. In U-Boot it is a built-in feature, partly to reduce code
size. You can of course ignore this and do your own memory allocation
if you prefer
- many devices want to translate ofdata to platform data. In Linux you
call that as part of probe, but in U-Boot it is a separate method.
- the rename of struct device to struct udevice is actually supposed
to make it easier to port Linux code
- the bind/unbind allows you to have devices which are known to the
system, but not yet probed. This is important in a boot loader (e.g.
we don't want to probe devices until they are actually needed, and
some will never be probed during a boot), although not really
necessary in an OS
[1] Why is usage (needed to be) different?
I expect the usage is something like this:
static int foo_init(void)
{
return foo_driver_register(vendorA_foo_driver);
}
module_init(foo_init)
I mean, something is triggered by registering something
in each init function.
This is done with platform data or device tree nodes. U-Boot does not
have modules, but if it does get them one day, the device would be
registered automatically when added. You can call device_bind() to
bind a new device, but in most cases you don't need to.
[2] Why uclass?
In Linux, struct device_driver is something like a superclass
of each driver such platform_driver, uart_driver, usb_driver.
Usually, struct foo_device includes(inherits) struct device
and struct foo_driver includes struct device_driver.
|| |--|
|| | |
| struct device | | struct device_driver |
|| | |
|| |--|
/|\ /|\
| | include (inherit)
| |
|| |---|
| struct | | struct|
| platform_device | | platform_driver |
|| | |
|| |---|
struct uclass is a totally different approach.
For ex.
int demo_hello(struct udevice *dev, int ch)
takes a pointer to struct udevice, but it must be the one of
DEMO class.
We can still pass a udevice belonging to GPIO class,
which the compiler never complains about, but it will crash at run time.
I'd like to know the philosophy in the background of this approach.
It seems we need to expand the README on this point.
Linux effectively has the concept of a uclass, but it is not built
into the infrastructure. For example, if you have a RTC driver you
call rtc_device_register() and rtc_device_unregister(). But from
outside the RTC subsystem how do you find the RTC? How would you
implement a command to list the RTCs. Given a device tree node, how do
you find the device(s) associated with it? How do you implement a
command that wants to operate on device #2 out of the list (for any
given class of devices).
In fact Linux does have the concept of classes (see struct class), and
it almost feels like it is edging towards having some sort of
registration framework for them. But if so it is not there yet.
Re the struct udevice, you can of course create these sorts of
included structs, but I'm not sure what it buys you. Where did you get
the udevice from? Normally it would come from
uclass_first_device(UCLASS_DEMO, dev) or similar. Are you worried
about getting a device from one uclass and passing it to another? I
suppose we could add checks for that. I have certainly thought about
having magic numbers/datatype IDs in the structures for debugging
purposes, but have not implemented it.
[3] Is platform driver(device) a special case?
I am not sure if I understood correctly,
but it looks like platform data in U-Boot is a special case.
I do not
Re: [U-Boot] [PATCH 2/3] fdt: add fdt_add_display_timings(..) and friends
HI Christian,
On 15 September 2014 07:06, Christian Gmeiner christian.gmei...@gmail.com
wrote:
This new function is used to set all display-timings
properties based on fb_videomode.
display-timings {
timing0 {
clock-frequency = 2500;
hactive = 640;
vactive = 480;
hback-porch = 48;
hfront-porch = 16;
vback-porch = 31;
vfront-porch = 12;
hsync-len = 96;
vsync-len = 2;
};
};
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
Thanks for the patch. There are a few style violations and I have a few
minor comments below.
$ ./tools/patman/patman -c1 -n
Cleaned 1 patches
0 errors, 4 warnings, 0 checks for
0001-fdt-add-fdt_add_display_timings-.-and-friends.patch:
warning: common/fdt_support.c,1400: line over 80 characters
warning: common/fdt_support.c,1406: braces {} are not necessary for single
statement blocks
warning: common/fdt_support.c,1412: braces {} are not necessary for single
statement blocks
warning: include/fdt_support.h,96: line over 80 characters
checkpatch.pl found 0 error(s), 4 warning(s), 0 checks(s)
---
common/fdt_support.c | 56
+++
include/fdt_support.h | 5 +
2 files changed, 61 insertions(+)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 784a570..72004a3 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -11,6 +11,7 @@
#include stdio_dev.h
#include linux/ctype.h
#include linux/types.h
+#include linux/fb.h
#include asm/global_data.h
#include libfdt.h
#include fdt_support.h
@@ -1373,6 +1374,61 @@ err_size:
#endif
/*
+* fdt_find_display_timings: finde node containing display-timings
+*
+* @fdt: fdt to device tree
+* @compat: compatiable string to match
+* @parent: parent node containing display-timings
or -ve error code FDT_ERROR_...
+*/
+int fdt_find_display_timings(void *fdt, const char *compat, const char
*parent)
+{
+ int coff = fdt_node_offset_by_compatible(fdt, -1, compat);
+ int poff = fdt_subnode_offset(fdt, coff, parent);
+ int noff = fdt_subnode_offset(fdt, poff, display-timings);
+
Can we return an error when we see one? Here it will return a somewhat
meaningless error if (say) the first call finds no node.
+ return noff;
+}
+
+/*
+* fdt_update_display_timings: update display-timings properties
+*
+* @fdt: fdt to device tree
+* @compat: compatiable string to match
compatible
+* @parent: parent node containing display-timings
@parent: parent node containing display-timings subnode
+* @mode: ptr to fb_videomode
Well we know that from the code. Perhaps display timings to add to the
device tree
+*/
This function is exported so the comment should go in the header file.
+int fdt_update_display_timings(void *fdt, const char *compat, const char
*parent,
+ struct fb_videomode *mode)
+{
+ int noff = fdt_find_display_timings(fdt, compat, parent);
+
+ /* check if display-timings subnode does exist */
+ if (noff == -FDT_ERR_NOTFOUND) {
if (noff 0)
would be better
+ return noff;
+ }
+
+ /* check if timing0 subnode exists */
+ noff = fdt_subnode_offset(fdt, noff, timing0);
+ if (noff == -FDT_ERR_NOTFOUND) {
same here
+ return noff;
+ }
+
+ /* set all needed properties */
+ fdt_setprop_u32(fdt, noff, clock-frequency,
+ PICOS2KHZ(mode-pixclock) * 1000);
+ fdt_setprop_u32(fdt, noff, hactive, mode-xres);
+ fdt_setprop_u32(fdt, noff, vactive, mode-yres);
+ fdt_setprop_u32(fdt, noff, hback-porch, mode-left_margin);
+ fdt_setprop_u32(fdt, noff, hfront-porch, mode-right_margin);
+ fdt_setprop_u32(fdt, noff, vback-porch, mode-upper_margin);
+ fdt_setprop_u32(fdt, noff, vfront-porch, mode-lower_margin);
+ fdt_setprop_u32(fdt, noff, hsync-len, mode-hsync_len);
+ fdt_setprop_u32(fdt, noff, vsync-len, mode-vsync_len);
Should you have error checking here? We might run out of space.
+
+ return 0;
+}
+
+/*
* Verify the physical address of device tree node for a given alias
*
* This function locates the device tree node of a given alias, and then
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 1bda686..4222ab4 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -91,6 +91,11 @@ int fdt_set_phandle(void *fdt, int nodeoffset, uint32_t
phandle);
unsigned int fdt_create_phandle(void *fdt, int nodeoffset);
int fdt_add_edid(void *blob, const char *compat, unsigned char *buf);
+struct fb_videomode;
+int fdt_find_display_timings(void *fdt, const char *compat, const char
*parent);
+int fdt_update_display_timings(void *fdt, const char *compat, const
Re: [U-Boot] [U-Boot, 2/3] image: move all function comments to header file
Hi Tom, On 23 August 2014 11:48, Tom Rini tr...@ti.com wrote: On Sat, Aug 23, 2014 at 08:42:51AM -0400, Tom Rini wrote: On Fri, Aug 15, 2014 at 01:55:27PM -0700, Bryan Wu wrote: Several functions comments are C file with function definition, they should be moved to header file with function declaration. Also update genimg_get_kernel_addr() comments for CONFIG_FIT case. Signed-off-by: Bryan Wu pe...@nvidia.com Applied to u-boot/master, thanks! OK, that's not true. I had intended to I believe but git am --skip'd over and didn't manually fix it up, so it's not there yet. Did this get applied? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: f_mass_storage: set removable flag in do_inquiry based on LUN
Without this flag, tools like Alex Page's USB Image Tool won't see drives exposed over USB Gadget as removable, and won't allow access to them. http://www.alexpage.de/usb-image-tool/ The code was pulled from the main-line kernel: drivers/usb/gadget/function/f_mass_storage.c Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- drivers/usb/gadget/f_mass_storage.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/f_mass_storage.c b/drivers/usb/gadget/f_mass_storage.c index f274d96..e045957 100644 --- a/drivers/usb/gadget/f_mass_storage.c +++ b/drivers/usb/gadget/f_mass_storage.c @@ -1110,6 +1110,7 @@ static int do_inquiry(struct fsg_common *common, struct fsg_buffhd *bh) memset(buf, 0, 8); buf[0] = TYPE_DISK; + buf[1] = curlun-removable ? 0x80 : 0; buf[2] = 2; /* ANSI SCSI level 2 */ buf[3] = 2; /* SCSI-2 INQUIRY data format */ buf[4] = 31;/* Additional length */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/3] image: move all function comments to header file
Hi. I vote for comments near the implementation. I have been digging into the driver model code recently, but I have to admit it is unreadable because most of comments are placed in its header files. (and I am planning to send a patch to move comments to C sources.) I really want to know what does this function do? and How is it used? things before I start to read the detailed implementation. If they are written separately, I need to open two windows of my editor, one for reading the comments in a header file, the other for reading the implementation in a C source. I am really unhappy about that. I guess people often use tag jump utilities. (I like GNU Global, someone may use ctags/etags, cscope, etc. I don't know..) Such utilities allow us to jump over to the implementation place. If comments are not there, we have to look for comments by hand. I think we should keep in our mind this: source files are much more read than written. I believe we put the readers' benefits at the top priority. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
