Re: [U-Boot] [U-Boot, v1, 2/2] i2c: zynq: Add support for the second i2c controller
Hello Michael, Am 13.01.2014 08:53, schrieb Michal Simek: On 01/13/2014 08:32 AM, Heiko Schocher wrote: Hello Michel, Am 03.01.2014 10:45, schrieb Michal Simek: From: Michael Burr Initialize the second i2c controller. Signed-off-by: Michael Burr Signed-off-by: Michal Simek --- Changes in v1: - Based on original thread from Michael Burr http://lists.denx.de/pipermail/u-boot/2013-October/165017.html Heiko did some changes in this mainline patch "i2c, zynq: convert zynq i2c driver to new multibus/multiadapter framework" (sha1: 0bdffe71fddeaa46768a39305797e4512dee0f15) - MS rebase on latest&greatest drivers/i2c/zynq_i2c.c | 46 -- include/configs/zynq.h | 7 +++ 2 files changed, 31 insertions(+), 22 deletions(-) I could not apply your patch on top of current tree commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca Merge: 8401bfa 10a147b Author: Tom Rini Date: Fri Jan 10 10:56:00 2014 -0500 Merge branch 'master' of git://git.denx.de/u-boot-arm Problem is the change in "include/configs/zynq.h", as this file does not longer exist in mainline ... I think, your change should be done in "include/configs/zynq-common.h", right? Is it OK, if I fix this, or would you send a v2 (prefered, as I could not test this)? yes, zynq.h was renamed to zynq-common.h. That will be great if you can fix it yourself. Done, see: http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=commit;h=8e0b3c020057b3f7345b6696029a80eaf162e7f3 Please test and give me feedback. If my fix is not perfect, please post a v2, thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v1, 2/2] i2c: zynq: Add support for the second i2c controller
On 01/13/2014 09:10 AM, Heiko Schocher wrote: > Hello Michael, > > Am 13.01.2014 08:53, schrieb Michal Simek: >> On 01/13/2014 08:32 AM, Heiko Schocher wrote: >>> Hello Michel, >>> >>> Am 03.01.2014 10:45, schrieb Michal Simek: From: Michael Burr Initialize the second i2c controller. Signed-off-by: Michael Burr Signed-off-by: Michal Simek --- Changes in v1: - Based on original thread from Michael Burr http://lists.denx.de/pipermail/u-boot/2013-October/165017.html Heiko did some changes in this mainline patch "i2c, zynq: convert zynq i2c driver to new multibus/multiadapter framework" (sha1: 0bdffe71fddeaa46768a39305797e4512dee0f15) - MS rebase on latest&greatest drivers/i2c/zynq_i2c.c | 46 -- include/configs/zynq.h | 7 +++ 2 files changed, 31 insertions(+), 22 deletions(-) >>> >>> I could not apply your patch on top of current tree >>> >>> commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca >>> Merge: 8401bfa 10a147b >>> Author: Tom Rini >>> Date: Fri Jan 10 10:56:00 2014 -0500 >>> >>> Merge branch 'master' of git://git.denx.de/u-boot-arm >>> >>> Problem is the change in "include/configs/zynq.h", as this file does >>> not longer exist in mainline ... I think, your change should be done >>> in "include/configs/zynq-common.h", right? >>> >>> Is it OK, if I fix this, or would you send a v2 (prefered, as I could >>> not test this)? >> >> yes, zynq.h was renamed to zynq-common.h. >> That will be great if you can fix it yourself. > > Done, see: > http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=commit;h=8e0b3c020057b3f7345b6696029a80eaf162e7f3 > > Please test and give me feedback. If my fix is not perfect, please > post a v2, thanks! Looks good to me. We will test it and I will let you know if we see any problem. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nand: fix reading after switching ecc
Hi Jeroen, > >The omap_gpmc allows switching ecc at runtime. Since >the NAND_SUBPAGE_READ flag is only set, it is kept when >switching to hw ecc, which is not correct. This leads to >calling chip->ecc.read_subpage which is not a valid >pointer. Therefore also clear the flag so reading in >hw mode works again. > >Cc: Scott Wood >Cc: Pekon Gupta >Cc: Nikita Kiryanov >Signed-off-by: Jeroen Hofstee >--- > drivers/mtd/nand/nand_base.c | 2 ++ > 1 file changed, 2 insertions(+) > >diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c >index 1ce55fd..0762a19 100644 >--- a/drivers/mtd/nand/nand_base.c >+++ b/drivers/mtd/nand/nand_base.c >@@ -3354,6 +3354,8 @@ int nand_scan_tail(struct mtd_info *mtd) > /* Large page NAND with SOFT_ECC should support subpage reads */ > if ((chip->ecc.mode == NAND_ECC_SOFT) && (chip->page_shift > 9)) > chip->options |= NAND_SUBPAGE_READ; >+ else >+ chip->options &= ~NAND_SUBPAGE_READ; > I don't think it's good to add OMAP specific changes to nand_base.c. It's better if you can add this as part of omap_select_ecc_scheme() in omap_gpmc.c with regards, pekon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board
Hi Pavel,
On Mon, 11 Nov 2013 20:26:02 +0100, Pavel Machek wrote:
>
> Altera Cyclone 5 board is very different board (big, rectangular,
> expensive) than EBV Socrates (small, circular, cheap) board. Different
> parts are used there, too, but same configuration of u-boot works on
> both. Nevertheless, printing wrong name confuses users.
>
> Therefore this splits the configuration so that u-boot knows they are
> different. So far it is only used for correcting the puts, but there
> may be other uses in future.
>
> Signed-off-by: Pavel Machek
[weird: I don't see the commit separation line here ("---"). Not that it
matters much, just surprising.]
I assume the discussion on this patch is not actually related to the
change itself, which is thus OK.
However, it does not apply cleanly on current ARM tree.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [OT] CC:s in commits (was: [PATCH 1/2] socfpga: Adding Scan Manager driver)
On Wed, 13 Nov 2013 11:34:10 -0600, Chin Liang See wrote: > Scan Manager driver will be called to configure the IOCSR > scan chain. This configuration will setup the IO buffer settings > > Signed-off-by: Chin Liang See > Cc: Dinh Nguyen > Cc: Wolfgang Denk > CC: Pavel Machek > Cc: Tom Rini > Cc: Albert Aribaud > --- Not sure what the point is of these CC:s in the commit message. Do I miss some use of these? Can I, should I, should I not remove them from the commit when applying to my tree? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: merge commonly-defined PLATFORM_RELFLAGS
Hi Masahiro,
On Thu, 14 Nov 2013 09:25:55 +0900, Masahiro Yamada
wrote:
> All arch/arm/cpu/${CPU}/config.mk had the same
> PLATFORM_RELFLAGS definitions.
> This commit merges them into arch/arm/config.mk.
>
> Signed-off-by: Masahiro Yamada
> ---
This does not apply cleanly on ARM tree. Can you please rebase and
submit v2?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net/fm: revert commit 732dfe090d50af53bb682d0c8971784f8de1f90f
This patch reverts patch 'add ft_fixup_xgec to support 3rd and 4th 10GEC'.
When dual-role MAC acts as 10G,it still uses fsl,fman-port-1g-rx/tx as before.
Signed-off-by: Shengzhou Liu
---
drivers/net/fm/init.c | 53 +--
1 file changed, 1 insertion(+), 52 deletions(-)
diff --git a/drivers/net/fm/init.c b/drivers/net/fm/init.c
index 74c72d3..cd787f4 100644
--- a/drivers/net/fm/init.c
+++ b/drivers/net/fm/init.c
@@ -276,64 +276,13 @@ static void ft_fixup_port(void *blob, struct fm_eth_info
*info, char *prop)
"status", "disabled", strlen("disabled") + 1, 1);
}
-#ifdef CONFIG_SYS_FMAN_V3
-static int ft_fixup_xgec(void *blob, struct fm_eth_info *info)
-{
- int off, i, ci;
-#define FM1_10GEC3_RX_PORT_ADDR(CONFIG_SYS_CCSRBAR_PHYS + 0x488000)
-#define FM1_10GEC3_TX_PORT_ADDR(CONFIG_SYS_CCSRBAR_PHYS + 0x4a8000)
-#define FM1_10GEC3_MAC_ADDR(CONFIG_SYS_CCSRBAR_PHYS + 0x4e)
-
- if ((info->port == FM1_10GEC3) || (info->port == FM1_10GEC4)) {
- ci = (info->port == FM1_10GEC3) ? 2 : 3;
- i = (info->port == FM1_10GEC3) ? 0 : 1;
-
- off = fdt_node_offset_by_compat_reg(blob, "fsl,fman-port-1g-rx",
- FM1_10GEC3_RX_PORT_ADDR +
- i * 0x1000);
- if (off > 0) {
- fdt_setprop(blob, off, "cell-index", &ci, sizeof(int));
- fdt_setprop(blob, off, "compatible",
- "fsl,fman-port-10g-rx", 20);
- } else {
- goto err;
- }
-
- off = fdt_node_offset_by_compat_reg(blob, "fsl,fman-port-1g-tx",
- FM1_10GEC3_TX_PORT_ADDR +
- i * 0x1000);
- if (off > 0) {
- fdt_setprop(blob, off, "cell-index", &ci, sizeof(int));
- fdt_setprop(blob, off, "compatible",
- "fsl,fman-port-10g-tx", 20);
- } else {
- goto err;
- }
-
- off = fdt_node_offset_by_compat_reg(blob, "fsl,fman-memac",
- FM1_10GEC3_MAC_ADDR +
- i * 0x2000);
- if (off > 0)
- fdt_setprop(blob, off, "cell-index", &ci, sizeof(int));
- else
- goto err;
- }
- return 0;
-err:
- printf("WARNING: Fail to find the node\n");
- return -1;
-}
-#endif
-
void fdt_fixup_fman_ethernet(void *blob)
{
int i;
#ifdef CONFIG_SYS_FMAN_V3
- for (i = 0; i < ARRAY_SIZE(fm_info); i++) {
+ for (i = 0; i < ARRAY_SIZE(fm_info); i++)
ft_fixup_port(blob, &fm_info[i], "fsl,fman-memac");
- ft_fixup_xgec(blob, &fm_info[i]);
- }
#else
for (i = 0; i < ARRAY_SIZE(fm_info); i++) {
if (fm_info[i].type == FM_ETH_1G_E)
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: versatile: pass correct machine type for Versatile AB
Hi Linus,
On Wed, 27 Nov 2013 10:33:32 +0100, Linus Walleij
wrote:
> When U-Boot is configured for Versatile AB, it will still pass
> the machine ID of Versatile PB to the kernel. After this simple
> fix the system boots correctly.
>
> Cc: Stefano Babic
> Cc: Marek Vasut
> Signed-off-by: Linus Walleij
> ---
> board/armltd/versatile/versatile.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/board/armltd/versatile/versatile.c
> b/board/armltd/versatile/versatile.c
> index 30a3b904db4c..4e2d3421d8b1 100644
> --- a/board/armltd/versatile/versatile.c
> +++ b/board/armltd/versatile/versatile.c
> @@ -52,7 +52,11 @@ int board_early_init_f (void)
> int board_init (void)
> {
> /* arch number of Versatile Board */
> +#ifdef CONFIG_ARCH_VERSATILE_AB
> + gd->bd->bi_arch_number = MACH_TYPE_VERSATILE_AB;
> +#else
> gd->bd->bi_arch_number = MACH_TYPE_VERSATILE_PB;
> +#endif
>
> /* adress of boot parameters */
> gd->bd->bi_boot_params = 0x0100;
Applied to u-boot-arm/next, thanks!
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: versatile: pass console setting to the kernel
Hi Linus, On Wed, 27 Nov 2013 10:33:49 +0100, Linus Walleij wrote: > The Versatiles come up with the primary UART set to ttyAMA0 at > 38400 baud, and unless we pass this to the kernel it will assume > it is set to 9600 baud which will be quite awkward for the > terminal, let's try to be helpful and inform the kernel what > setting is used. > > Cc: Stefano Babic > Cc: Marek Vasut > Signed-off-by: Linus Walleij > --- > include/configs/versatile.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/configs/versatile.h b/include/configs/versatile.h > index 10738ac24be0..29c32fee5178 100644 > --- a/include/configs/versatile.h > +++ b/include/configs/versatile.h > @@ -101,7 +101,8 @@ > > #define CONFIG_BOOTDELAY 2 > #define CONFIG_BOOTARGS "root=/dev/nfs mem=128M ip=dhcp "\ > - "netdev=25,0,0xf101,0xf1010010,eth0" > + "netdev=25,0,0xf101,0xf1010010,eth0 "\ > + "console=ttyAMA0,38400n1" > > /* > * Static configuration when assigning fixed address Applied to u-boot-arm/next, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] 2014.01: two ARM boards left with CONFIG_SYS_HZ warning
Hello, As we are about to release 2014.01, there are still two boards left which have the following warning: time.c:14:2: warning: #warning "CONFIG_SYS_HZ must be 1000 and should not be defined by platforms" [-Wcpp] ISTR work was underway to fix these. Is there, actually, and if not, what do we do with these boards? I don't like having builds where there are warnings left. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: New stack pointer is already aligned
Hi Wolfgang, On Fri, 29 Nov 2013 07:14:13 +0100, Wolfgang Denk wrote: > Dear Tom Rini, > > In message <1385580930-9830-1-git-send-email-tr...@ti.com> you wrote: > > The code in arch/arm/lib/board.c::board_init_f that sets > > gd->start_addr_sp has already make sure we're 8-byte aligned, so we > > don't need to do that again. > > > > Cc: Albert ARIBAUD > > Signed-off-by: Tom Rini > > --- > > arch/arm/lib/crt0.S |1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S > > index ac54b93..6b5ec01 100644 > > --- a/arch/arm/lib/crt0.S > > +++ b/arch/arm/lib/crt0.S > > @@ -82,7 +82,6 @@ ENTRY(_main) > > */ > > > > ldr sp, [r9, #GD_START_ADDR_SP] /* sp = gd->start_addr_sp */ > > - bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ > > ldr r9, [r9, #GD_BD]/* r9 = gd->bd */ > > sub r9, r9, #GD_SIZE/* new GD is below bd */ > > I recommend to keep this instruction. It's just a bit of defensive > programming, and removing it does not save any measurable amount of > memory footprint nor execution time. I would even go further: it is the setting of SP in C code which should not be kept. I doubt the C specification mentions what should / might happen when changing the stack pointer on the fly in code which might need the stack at any point. > Best regards, > > Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ums: wait for usb cable connection before enter ums mode
Hello everyone,
On 01/07/2014 03:08 PM, Przemyslaw Marczak wrote:
Before this change ums mode can not be entered when device
was using the same usb port for usb/uart communication.
Switching USB cable from UART to USB always causes ums exit.
Signed-off-by: Przemyslaw Marczak
---
common/cmd_usb_mass_storage.c | 24
include/usb_mass_storage.h|3 +++
2 files changed, 27 insertions(+)
diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c
index 99487f4..5f557d5 100644
--- a/common/cmd_usb_mass_storage.c
+++ b/common/cmd_usb_mass_storage.c
@@ -42,6 +42,30 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
g_dnl_register("ums");
+ /* Timeout unit: seconds */
+ int cable_ready_timeout = UMS_CABLE_READY_TIMEOUT;
+
+ if (!usb_cable_connected()) {
+ puts("Please connect USB cable.\n");
+
+ while (!usb_cable_connected()) {
+ if (ctrlc()) {
+ puts("\rCTRL+C - Operation aborted.\n");
+ goto exit;
+ }
+ if (!cable_ready_timeout) {
+ puts("\rUSB cable not detected.\n" \
+"Command exit.\n");
+ goto exit;
+ }
+
+ printf("\rAuto exit in: %.2d s.", cable_ready_timeout);
+ mdelay(1000);
+ cable_ready_timeout--;
+ }
+ puts("\r\n");
+ }
+
while (1) {
usb_gadget_handle_interrupts();
diff --git a/include/usb_mass_storage.h b/include/usb_mass_storage.h
index 9df3adc..058dcf1 100644
--- a/include/usb_mass_storage.h
+++ b/include/usb_mass_storage.h
@@ -20,6 +20,9 @@
#define UMS_NUM_SECTORS 0
#endif
+/* Wait at maximum 60 seconds for cable connection */
+#define UMS_CABLE_READY_TIMEOUT60
+
struct ums {
int (*read_sector)(struct ums *ums_dev,
ulong start, lbaint_t blkcnt, void *buf);
I was send some very useful fix to the ums. It is required for users who
are using the same usb port for USB and UART purposes. Without this fix
such users just can't use ums because it will always exit to prompt when
user change the cable.
So I have few questions...
Marek, could you review this patch?
And what about the release, are you going to send pull request before
the release?
If not, then is it possible to apply this patch directly to
u-boot/master by Tom Rini?
Thank you,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] net/designware: make driver compatible with data cache
Up until now this driver only worked with data cache disabled.
To make it work with enabled data cache following changes were required:
* Flush Tx/Rx buffer descriptors their modification
* Invalidate Tx/Rx buffer descriptors before reading its values
* Flush cache for data passed from CPU to GMAC
* Invalidate cache for data passed from GMAC to CPU
Signed-off-by: Alexey Brodkin
Cc: Joe Hershberger
Cc: Vipin Kumar
Cc: Stefan Roese
Cc: Mischa Jonker
Compared to v1:
1. Dropped all extra "readl"/"writel" since it makes no sense in terms
of data access via D$.
2. Added flush/invalidation of buffer descriptors after/before its data
access.
---
drivers/net/designware.c | 53 +---
1 file changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 22155b4..53a95bf 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -51,6 +51,11 @@ static void tx_descs_init(struct eth_device *dev)
/* Correcting the last pointer of the chain */
desc_p->dmamac_next = &desc_table_p[0];
+ /* Flush all Tx buffer descriptors at once */
+ flush_dcache_range((unsigned int)priv->tx_mac_descrtable,
+ (unsigned int)priv->tx_mac_descrtable +
+ sizeof(priv->tx_mac_descrtable));
+
writel((ulong)&desc_table_p[0], &dma_p->txdesclistaddr);
}
@@ -63,6 +68,15 @@ static void rx_descs_init(struct eth_device *dev)
struct dmamacdescr *desc_p;
u32 idx;
+ /* Before passing buffers to GMAC we need to make sure zeros
+* written there right after "priv" structure allocation were
+* flushed into RAM.
+* Otherwise there's a chance to get some of them flushed in RAM when
+* GMAC is already pushing data to RAM via DMA. This way incoming from
+* GMAC data will be corrupted. */
+ flush_dcache_range((unsigned int)rxbuffs, (unsigned int)rxbuffs +
+ RX_TOTAL_BUFSIZE);
+
for (idx = 0; idx < CONFIG_RX_DESCR_NUM; idx++) {
desc_p = &desc_table_p[idx];
desc_p->dmamac_addr = &rxbuffs[idx * CONFIG_ETH_BUFSIZE];
@@ -78,6 +92,11 @@ static void rx_descs_init(struct eth_device *dev)
/* Correcting the last pointer of the chain */
desc_p->dmamac_next = &desc_table_p[0];
+ /* Flush all Rx buffer descriptors at once */
+ flush_dcache_range((unsigned int)priv->rx_mac_descrtable,
+ (unsigned int)priv->rx_mac_descrtable +
+ sizeof(priv->rx_mac_descrtable));
+
writel((ulong)&desc_table_p[0], &dma_p->rxdesclistaddr);
}
@@ -197,6 +216,11 @@ static int dw_eth_send(struct eth_device *dev, void
*packet, int length)
u32 desc_num = priv->tx_currdescnum;
struct dmamacdescr *desc_p = &priv->tx_mac_descrtable[desc_num];
+ /* Invalidate only "status" field for the following check */
+ invalidate_dcache_range((unsigned long)&desc_p->txrx_status,
+ (unsigned long)&desc_p->txrx_status +
+ sizeof(desc_p->txrx_status));
+
/* Check if the descriptor is owned by CPU */
if (desc_p->txrx_status & DESC_TXSTS_OWNBYDMA) {
printf("CPU not owner of tx frame\n");
@@ -205,6 +229,10 @@ static int dw_eth_send(struct eth_device *dev, void
*packet, int length)
memcpy((void *)desc_p->dmamac_addr, packet, length);
+ /* Flush data to be sent */
+ flush_dcache_range((unsigned long)desc_p->dmamac_addr,
+ (unsigned long)desc_p->dmamac_addr + length);
+
#if defined(CONFIG_DW_ALTDESCRIPTOR)
desc_p->txrx_status |= DESC_TXSTS_TXFIRST | DESC_TXSTS_TXLAST;
desc_p->dmamac_cntl |= (length << DESC_TXCTRL_SIZE1SHFT) & \
@@ -220,6 +248,10 @@ static int dw_eth_send(struct eth_device *dev, void
*packet, int length)
desc_p->txrx_status = DESC_TXSTS_OWNBYDMA;
#endif
+ /* Flush modified buffer descriptor */
+ flush_dcache_range((unsigned long)desc_p,
+ (unsigned long)desc_p + sizeof(struct dmamacdescr));
+
/* Test the wrap-around condition. */
if (++desc_num >= CONFIG_TX_DESCR_NUM)
desc_num = 0;
@@ -235,18 +267,28 @@ static int dw_eth_send(struct eth_device *dev, void
*packet, int length)
static int dw_eth_recv(struct eth_device *dev)
{
struct dw_eth_dev *priv = dev->priv;
- u32 desc_num = priv->rx_currdescnum;
+ u32 status, desc_num = priv->rx_currdescnum;
struct dmamacdescr *desc_p = &priv->rx_mac_descrtable[desc_num];
-
- u32 status = desc_p->txrx_status;
int length = 0;
+ /* Invalidate entire buffer descriptor */
+ invalidate_dcache_range((unsigned long)desc_p,
+ (unsigned long)desc_p +
+ sizeof(struct dmamacde
Re: [U-Boot] [PATCH v2] fuelgauge: max17042: fix i2c read issue which causes infinity loop.
Hello Minkyu, On 12/30/2013 11:31 AM, Przemyslaw Marczak wrote: Hello, On 12/30/2013 11:24 AM, Przemyslaw Marczak wrote: Issues: - reading i2c data by passing u16 pointer causes errors in read data. - max17042 status register fields have not only Power On Reset meaning so using proper mask is required. Changes: - read i2c data to type u32 instead of u16 - avoids buffer overflow - compare FG status register using mask not just one bit value - add checking return value to functions fg read/write - add model lock and model check count - add debug msg Signed-off-by: Przemyslaw Marczak Cc: Lukasz Majewski Cc: Minkyu Kang --- Changes v2: - add checking return value to functions fg read/write - add model lock and model check count - add status msg - change logical AND to bitwise AND when checking status register To test this patch, it is required to apply trats i2c fix by Piotr Wilczek: "[PATCH] board:trats1:trats2: fix adapter number" which can be found at u-boot list. In other way FG will be not initialized. Regards, Could you review this patch, please? Is it possible to apply this before the release? It is useful fix. Thank you, -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net/designware: add explicit reset of {tx|rx}_currdescnum
Driver "init" function might be called multiple times.
On every "init" Tx/Rx buffer descriptors are initialized: "descs_init"
-> "{tx|rx}_descs_init".
In its turn those init functions set MAC's "{tx|rx}desclistaddr" to
point on the first buffer descriptor in the list.
So CPU to start operation from the first buffer descriptor as well after
every "init" we have to reset "{tx|rx}_currdescnum".
Signed-off-by: Alexey Brodkin
Cc: Joe Hershberger
Cc: Vipin Kumar
Cc: Stefan Roese
Cc: Mischa Jonker
---
drivers/net/designware.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 53a95bf..d1cc25b 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -57,6 +57,7 @@ static void tx_descs_init(struct eth_device *dev)
sizeof(priv->tx_mac_descrtable));
writel((ulong)&desc_table_p[0], &dma_p->txdesclistaddr);
+ priv->tx_currdescnum = 0;
}
static void rx_descs_init(struct eth_device *dev)
@@ -98,6 +99,7 @@ static void rx_descs_init(struct eth_device *dev)
sizeof(priv->rx_mac_descrtable));
writel((ulong)&desc_table_p[0], &dma_p->rxdesclistaddr);
+ priv->rx_currdescnum = 0;
}
static void descs_init(struct eth_device *dev)
--
1.8.4.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] arm: vf610: Add QSPI support for VF610
Hi Alison Wang, On Monday 13 January 2014 02:24 PM, Huan Wang wrote: Hi, Jagan, I tested my driver based on your sf quad changes, and it is ok. For the sf quad functions, I didn' t test, because my driver doesn't support sf quad now. Thanks for the test. Just for confirmation, is it u-boot-spi/master-quad correct? Thanks. Best Regards, Alison Wang -Original Message- From: Jagan Teki [mailto:jagannadha.sutradharudu-t...@xilinx.com] Sent: Monday, January 13, 2014 2:39 PM To: Wang Huan-B18965; jagannadha.sutradharudu-t...@xilinx.com; sba...@denx.de Cc: u-boot@lists.denx.de Subject: Re: [PATCH 0/3] arm: vf610: Add QSPI support for VF610 Hi, Thanks for the series. I will review once the today release done. And is it possible to test these changes on sf quad changes, if OK will send the details. On Monday 13 January 2014 11:02 AM, Alison Wang wrote: This series contain QSPI support for Freescale Vybrid VF610. The QSPI(Quad Serial Peripheral Interface) acts as an interface to one single or two external serial flash devices, each with up to 4 bidirectional data lines. QSPI has a Look-update-table(LUT) which consists of a number of pre-programmed sequences. Each sequence is basically a sequence of instruction-operand pairs which when executed sequentially generates a valid serial flash transaction. This driver has been tested on VF610TWR. Alison Wang (3): arm: imx: Add two macros for VF610 in IOMUX_PAD structure arm: vf610: Add QSPI support for VF610TWR arm: vf610: Add QSPI driver support arch/arm/include/asm/arch-vf610/crm_regs.h| 11 ++- arch/arm/include/asm/arch-vf610/imx-regs.h| 4 +- arch/arm/include/asm/arch-vf610/iomux-vf610.h | 14 +++ arch/arm/include/asm/imx-common/iomux-v3.h| 2 + board/freescale/vf610twr/vf610twr.c | 29 ++- drivers/spi/Makefile | 1 + drivers/spi/fsl_qspi.c| 482 +++ drivers/spi/fsl_qspi.h| 127 +++ include/configs/vf610twr.h| 11 +++ 9 files changed, 677 insertions(+), 4 deletions(-) create mode 100644 drivers/spi/fsl_qspi.c create mode 100644 drivers/spi/fsl_qspi.h -- Thanks, Jagan. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- Thanks, Jagan. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 01/17] sf: Add extended read commands support
On Sun, Jan 12, 2014 at 22:29 +0530, Jagannadha Sutradharudu Teki wrote: > > Current sf uses FAST_READ command, this patch adds support to > use the different/extended read command. > > This implementation will determine the fastest command by taking > the supported commands from the flash and the controller, controller > is always been a priority. I don't quite get this. You have a combination of several components which all have to participate appropriately when you want the total of it to work correctly. How can one specific component "be a priority" there? Isn't the lowest common denominator required instead? The strength of a chain is determined by its weakest link after all. The other issue I have here (as well as in Linux kernel changes and discussions) is that people seem to forget that the board is involved as well. Your commit message suggests that "parallel" communication is used as soon as - the SPI controller has such a feature - a flash chip was detected which according to a fixed database supports this feature This decision is automatic. Neither is there a "how is the board wired?" condition involved, nor can users or even developers adjust this behaviour (say, by optionally setting a maximum width). I'd suggest to provide a "maximum number of lines to use" option, for the same reasons that we may want to limit transfer rates instead of always using the maximum of what individual chips could do (the reasons: the number of lines connected as well as their electrical and mechanical properties do have an impact). Alternatively one may implement auto-detection, starting at the most capable feature and falling back until a working condition was found. But this is fragile if the communication used at detection time does not involve all potentially used lines (and in all directions, mind you). This won't solve potential bugs in chips either which the user may want to override. Or EMI related restrictions which a developer may want to apply despite the chips' and board's being more capable. Or pin mux settings which dedicate unused "upper SPI data lines" to other features (as we have seen with MMC cards recently). virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 00/17] sf: Add support for quad and dual_flash
On Sun, Jan 12, 2014 at 22:29 +0530, Jagannadha Sutradharudu Teki wrote: > > This series is a combo of quad cmds and dual_flash support > Refer [1] and [2] for more functional description about this changes. > > [ ... ] > > Please let me know for any issues/concerns/questions. > > -- > Thanks, > Jagan. > > Changes for v7: > - cmdsz on read_ops > - sf param flags are placed spi_flash.h > - code cleanup > - updated dual_flash with BAR support > [ ... ] Mail setup related nits: Please don't do this. The dash line correctly separates your signature, which is good (and not a given either). But putting more context below that line will make it look like it's part of the signature, and thus probably will get lost (either by automatic trimming, or folding, or colorization and/or mental filtering). Then I noticed that the series and your cover letter aren't "connected". The series should be a reply to the cover letter, while you seem to create and send them out in separate steps. Which breaks their relation, and has them appear in random order and with other messages in between them. And the recipient list suggests that there is an issue with inappropriately quoted entries, there's another nonexistent @theia address as has been in the past. Please fix this (I did upon reply, check your original message). virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BCH8 support when we do not have ELM h/w engine.
Hi Enric, > >Hi Pekon, > >2013/12/10 Gupta, Pekon : >> Hi Enric, >> >> Sorry I missed your earlier mail, so din't check this.. >> >>>From: Enric Balletbo Serra [mailto:eballe...@gmail.com] I saw that the OOB layout is not the same when I flash the rootfs from the u-boot or from the kernel. For example: If the rootfs is flashed from the kernel the OOB data is like that: U-Boot # nand dump.oob 0x68 Page 0068 dump: OOB: ff ff 79 43 68 64 3b 80 b2 46 49 4d 58 2a 6d ff 52 3f 7d 2a 7f a2 98 70 57 32 30 35 c7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff If the rootfs is flashed for the u-boot the OOB data is like data: Page 0068 dump: OOB: ff ff 79 43 68 64 3b 80 b2 46 49 4d 58 2a 6d 52 3f 7d 2a 7f a2 98 70 57 32 30 35 c7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Note that look the same except after byte number 16. In the first case is ff 52 3f 7d 2a 7f a2 98 70 and in the second case is 52 3f 7d 2a 7f a2 98 70 It's possible that something is wrong writting the OOB data ? Any clue ? I'm in the right direction or completely wrong ? >> Yes, there seems to be an mis-match between u-boot and kernel >> ecc-layout. Give me a day's time, and I'll try to root cause this. >> However, don't have OMAP3 boards, so I can test this only on other boards. >> >> with regards, pekon > >If I can help somehow just let me know. > I have posted the patches to fix this regression between u-boot and kernel. And was expecting if you could test it confirm if this solves regression on your OMAP3 board. http://lists.infradead.org/pipermail/linux-mtd/2014-January/051384.html You can download the patch from [1] [1] http://lists.infradead.org/pipermail/linux-mtd/2013-December/050944.html with regards, pekon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] arm: vf610: Add QSPI support for VF610
Hi, Jagan, I tested my driver based on your sf quad changes, and it is ok. For the sf quad functions, I didn' t test, because my driver doesn't support sf quad now. Thanks. Best Regards, Alison Wang > -Original Message- > From: Jagan Teki [mailto:jagannadha.sutradharudu-t...@xilinx.com] > Sent: Monday, January 13, 2014 2:39 PM > To: Wang Huan-B18965; jagannadha.sutradharudu-t...@xilinx.com; > sba...@denx.de > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH 0/3] arm: vf610: Add QSPI support for VF610 > > Hi, > > Thanks for the series. > I will review once the today release done. > > And is it possible to test these changes on sf quad changes, if OK will > send the details. > > On Monday 13 January 2014 11:02 AM, Alison Wang wrote: > > This series contain QSPI support for Freescale Vybrid VF610. > > > > The QSPI(Quad Serial Peripheral Interface) acts as an interface to > one > > single or two external serial flash devices, each with up to 4 > bidirectional data lines. > > > > QSPI has a Look-update-table(LUT) which consists of a number of > > pre-programmed sequences. Each sequence is basically a sequence of > > instruction-operand pairs which when executed sequentially generates > a valid serial flash transaction. > > > > This driver has been tested on VF610TWR. > > > > > > Alison Wang (3): > >arm: imx: Add two macros for VF610 in IOMUX_PAD structure > >arm: vf610: Add QSPI support for VF610TWR > >arm: vf610: Add QSPI driver support > > > > arch/arm/include/asm/arch-vf610/crm_regs.h| 11 ++- > > arch/arm/include/asm/arch-vf610/imx-regs.h| 4 +- > > arch/arm/include/asm/arch-vf610/iomux-vf610.h | 14 +++ > > arch/arm/include/asm/imx-common/iomux-v3.h| 2 + > > board/freescale/vf610twr/vf610twr.c | 29 ++- > > drivers/spi/Makefile | 1 + > > drivers/spi/fsl_qspi.c| 482 > +++ > > > drivers/spi/fsl_qspi.h| 127 > +++ > > include/configs/vf610twr.h| 11 +++ > > 9 files changed, 677 insertions(+), 4 deletions(-) > > create mode 100644 drivers/spi/fsl_qspi.c > > create mode 100644 drivers/spi/fsl_qspi.h > > > > > > -- > Thanks, > Jagan. > > > This email and any attachments are intended for the sole use of the > named recipient(s) and contain(s) confidential information that may be > proprietary, privileged or copyrighted under applicable law. If you are > not the intended recipient, do not read, copy, or forward this email > message or any attachments. Delete this email message and any > attachments immediately. > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Quickstart-Manual for u-boot?
Hi, I already found - the sources in GIT - the config-name of my board - the (really huge) manual Since all I want to do is just compile MLO/u-boot.img for BeagleBone Black the latter seems to be totally oversized for me. So my question: is there some kind of quick-start/cookbook available that just describes the steps to compile U-Boot for a single platform? Cheers Fred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 9/9] USB: gadget: added a saner gadget downloader registration API
Hi Mateusz,
> Preprocessor definitions and hardcoded implementation selection in
> g_dnl core were replaced by a linker list made of {usb_function_name,
> bind_callback) pairs.
Tested-by: Lukasz Majewski
Tested at: Exynos4210 - TRATS.
Acked-by: Lukasz Majewski
>
> Change-Id: I4e0515e7fd61ff19793e9ac9a6c48b07c616c9dc
> Signed-off-by: Mateusz Zalega
> Cc: Lukasz Majewski
> Cc: Kyungmin Park
> ---
> common/cmd_dfu.c| 3 +-
> common/cmd_thordown.c | 3 +-
> common/cmd_usb_mass_storage.c | 2 +-
> drivers/usb/gadget/f_dfu.c | 11 --
> drivers/usb/gadget/f_mass_storage.c | 6 +++
> drivers/usb/gadget/f_thor.c | 5 +++
> drivers/usb/gadget/g_dnl.c | 74
> +
> include/dfu.h | 7
> include/g_dnl.h | 11 ++
> include/thor.h | 8
> include/usb_mass_storage.h | 8 11 files changed, 66
> insertions(+), 72 deletions(-)
>
> diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c
> index 5547678..a03538d 100644
> --- a/common/cmd_dfu.c
> +++ b/common/cmd_dfu.c
> @@ -22,7 +22,6 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[]) char *interface = argv[2];
> char *devstring = argv[3];
>
> - char *s = "dfu";
> int ret, i = 0;
>
> ret = dfu_init_env_entities(interface,
> simple_strtoul(devstring, @@ -38,7 +37,7 @@ static int
> do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) int
> controller_index = simple_strtoul(usb_controller, NULL, 0);
> board_usb_init(controller_index, USB_INIT_DEVICE);
> - g_dnl_register(s);
> + g_dnl_register("usb_dnl_dfu");
> while (1) {
> if (dfu_reset())
> /*
> diff --git a/common/cmd_thordown.c b/common/cmd_thordown.c
> index c4b3511..2dd7509 100644
> --- a/common/cmd_thordown.c
> +++ b/common/cmd_thordown.c
> @@ -22,7 +22,6 @@ int do_thor_down(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[]) char *interface = argv[2];
> char *devstring = argv[3];
>
> - const char *s = "thor";
> int ret;
>
> puts("TIZEN \"THOR\" Downloader\n");
> @@ -40,7 +39,7 @@ int do_thor_down(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[]) goto exit;
> }
>
> - g_dnl_register(s);
> + g_dnl_register("usb_dnl_thor");
>
> ret = thor_init();
> if (ret) {
> diff --git a/common/cmd_usb_mass_storage.c
> b/common/cmd_usb_mass_storage.c index 99487f4..c8e152c 100644
> --- a/common/cmd_usb_mass_storage.c
> +++ b/common/cmd_usb_mass_storage.c
> @@ -40,7 +40,7 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
> return CMD_RET_FAILURE;
> }
>
> - g_dnl_register("ums");
> + g_dnl_register("usb_dnl_ums");
>
> while (1) {
> usb_gadget_handle_interrupts();
> diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
> index a045864..cde1895 100644
> --- a/drivers/usb/gadget/f_dfu.c
> +++ b/drivers/usb/gadget/f_dfu.c
> @@ -18,12 +18,14 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> #include
>
> #include
> +#include
> #include "f_dfu.h"
>
> struct f_dfu {
> @@ -768,9 +770,7 @@ static int dfu_bind_config(struct
> usb_configuration *c)
> int dfu_add(struct usb_configuration *c)
> {
> - int id;
> -
> - id = usb_string_id(c->cdev);
> + int id = usb_string_id(c->cdev);
> if (id < 0)
> return id;
> strings_dfu_generic[0].id = id;
> @@ -781,3 +781,8 @@ int dfu_add(struct usb_configuration *c)
>
> return dfu_bind_config(c);
> }
> +
> +/* export dfu_add to g_dnl.o */
> +ll_entry_declare(struct g_dnl_bind_callback, dfu_bind_callback,
> + g_dnl_bind_callbacks) = { .usb_function_name =
> "usb_dnl_dfu",
> + .fptr = dfu_add };
> diff --git a/drivers/usb/gadget/f_mass_storage.c
> b/drivers/usb/gadget/f_mass_storage.c index b1fe8bd..b7d03f2 100644
> --- a/drivers/usb/gadget/f_mass_storage.c
> +++ b/drivers/usb/gadget/f_mass_storage.c
> @@ -243,6 +243,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -255,6 +256,7 @@
> #include
> #include
> #include
> +#include
>
> /**/
>
> @@ -2778,3 +2780,7 @@ int fsg_init(struct ums *ums_dev)
>
> return 0;
> }
> +
> +ll_entry_declare(struct g_dnl_bind_callback, fsg_bind_callback,
> + g_dnl_bind_callbacks) = { .usb_function_name =
> "usb_dnl_ums",
> + .fptr = fsg_add };
> diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
> index c4c9909..3f428c8 100644
> --- a/drivers/usb/gadget/f_thor.c
> +++ b/drivers/usb/gadget/f_thor.c
> @@ -17,6 +17,7 @@
>
> #include
> #include
> +#include
> #include
> #include
Re: [U-Boot] [PATCH 8/9] ums: always initialize mmc before ums_disk_init()
Hi Mateusz,
> In some cases MMC was still uninitialized while media capacity check,
> leading to broken ums command.
>
> Change-Id: I4b86c2c59e430fb8b55272ea14f00316d8cb3dca
> Signed-off-by: Mateusz Zalega
> Cc: Lukasz Majewski
> Cc: Minkyu Kang
> Cc: Kyungmin Park
> ---
> board/samsung/common/ums.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/board/samsung/common/ums.c b/board/samsung/common/ums.c
> index dc155ad..0d8f30d 100644
> --- a/board/samsung/common/ums.c
> +++ b/board/samsung/common/ums.c
> @@ -37,6 +37,9 @@ static struct ums ums_dev = {
>
> static struct ums *ums_disk_init(struct mmc *mmc)
> {
> + if (mmc_init(mmc))
> + return NULL;
> +
> uint64_t mmc_end_sector = mmc->capacity / SECTOR_SIZE;
> uint64_t ums_end_sector = UMS_NUM_SECTORS + UMS_START_SECTOR;
>
Tested-by: Lukasz Majewski
Tested at: Exynos4210 - TRATS.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH REPOST3 1/2] ARM: rpi_b: power on SDHCI and USB HW modules
Hi Stephen, On Thu, 26 Dec 2013 19:47:19 -0700, Stephen Warren wrote: > Send RPC commands to the VideoCore to turn on the SDHCI and USB modules. > For SDHCI this isn't needed in practice, since the firmware already > turned on the power in order to load U-Boot. However, it's best to be > explicit. For USB, this is necessary, since the module isn't powered > otherwise. This will allow the kernel USB driver to work. > > Signed-off-by: Stephen Warren > --- > arch/arm/include/asm/arch-bcm2835/mbox.h | 48 > ++ > board/raspberrypi/rpi_b/rpi_b.c | 34 - > 2 files changed, 81 insertions(+), 1 deletion(-) As there is no history, I am not sure why there were reposts. Are these rebases? pings? Which one should I take in? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] mx6: Add initial support for the Hummingboard solo
Hi Fabio, On 13/01/2014 00:04, Fabio Estevam wrote: > Hi Stefano, > > On Fri, Jan 3, 2014 at 3:55 PM, Fabio Estevam wrote: >> From: Fabio Estevam >> >> SolidRun has designed the Hummingboard board based on mx6q/dl/solo. >> >> Add the initial support for the mx6 solo variant. >> >> More information about this hardware can be found at: >> http://imx.solid-run.com/wiki/index.php?title=Carrier-One_Hardware >> >> (Carrier-One was the previous name of Hummingboard). >> >> Based on the work from Jon Nettleton . >> >> Signed-off-by: Jon Nettleton >> Signed-off-by: Fabio Estevam >> --- >> Changes since v1: >> - Addressed many of Stefano's comments about v1 > > Please let me know if you are happy with v2. > I have not open issue with your patch - it looks great to me. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 01/17] sf: Add extended read commands support
Hi Gerhard Sittig, Thanks for your comments, please see below On Mon, Jan 13, 2014 at 3:04 PM, Gerhard Sittig wrote: > On Sun, Jan 12, 2014 at 22:29 +0530, Jagannadha Sutradharudu Teki wrote: >> >> Current sf uses FAST_READ command, this patch adds support to >> use the different/extended read command. >> >> This implementation will determine the fastest command by taking >> the supported commands from the flash and the controller, controller >> is always been a priority. > > I don't quite get this. You have a combination of several > components which all have to participate appropriately when you > want the total of it to work correctly. > > How can one specific component "be a priority" there? Isn't the > lowest common denominator required instead? The strength of a > chain is determined by its weakest link after all. > > > The other issue I have here (as well as in Linux kernel changes > and discussions) is that people seem to forget that the board is > involved as well. > > Your commit message suggests that "parallel" communication is > used as soon as > - the SPI controller has such a feature > - a flash chip was detected which according to a fixed database > supports this feature > > This decision is automatic. Neither is there a "how is the > board wired?" condition involved, nor can users or even > developers adjust this behaviour (say, by optionally setting a > maximum width). > > I'd suggest to provide a "maximum number of lines to use" option, > for the same reasons that we may want to limit transfer rates > instead of always using the maximum of what individual chips > could do (the reasons: the number of lines connected as well as > their electrical and mechanical properties do have an impact). > > Alternatively one may implement auto-detection, starting at the > most capable feature and falling back until a working condition > was found. But this is fragile if the communication used at > detection time does not involve all potentially used lines (and > in all directions, mind you). This won't solve potential bugs in > chips either which the user may want to override. Or EMI related > restrictions which a developer may want to apply despite the > chips' and board's being more capable. Or pin mux settings which > dedicate unused "upper SPI data lines" to other features (as we > have seen with MMC cards recently). Yes the main reason for going maximum or based on controller setting transfer is to improve sf performance. I missed your point as didn't see much use cases from board to connected flash perceptive. I thought we have two options to meet this requirement. 1. dynamic - auto-detection: Get the max_nof_lines based on the board to connected flash. So-that we can configure the transfer mode based on the lines. no idea yet, how to get the max_nof_lines dynamically - any inputs. 2. static: from user level we may give the max_nof_lines ex: sf probe probe [[[bus:]cs]:max_nof_line] [hz] [mode] If user can't input max_nof_line so-that driver will go with single and the rest case transfer modes assigned based on the given input. Please comment? -- Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] wandboard: Return from cpu_eth_init() directly
On 04/01/2014 20:36, Fabio Estevam wrote: > From: Fabio Estevam > > There is no need to print an error message when cpu_eth_init() fails because > net/eth.c already prints it. > > In order to simplify the code, just return the value from cpu_eth_init(bis) > directly. > > Signed-off-by: Fabio Estevam > --- Applied (whole series) to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] mx6slevk: Include "mx6_common.h"
On 09/01/2014 11:57, Fabio Estevam wrote: > From: Fabio Estevam > > Include "mx6_common.h" so that some ARM errata are applied and also the > vddsoc regulator can be changed. > > Signed-off-by: Fabio Estevam > --- > Changes since v2: > - Discarded 1/2 and now all 3 errata are also applied to mx6solo-lite. > Changes since v1: > - None > > include/configs/mx6slevk.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h > index 7abad08..b29f78c 100644 > --- a/include/configs/mx6slevk.h > +++ b/include/configs/mx6slevk.h > @@ -11,6 +11,7 @@ > > #include > #include > +#include "mx6_common.h" > > #define CONFIG_MX6 > #define CONFIG_DISPLAY_CPUINFO > Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] imx6: make use of lldiv(..)
On 08/01/2014 08:24, Christian Gmeiner wrote: > Commit 762a88ccf8540948fbf8c31b40a29d1e0684a25b introduces > a 64-bit division without using the lldiv() function, > which pulls in previously unused libgcc stuff. > > Signed-off-by: Måns Rullgård > Signed-off-by: Christian Gmeiner > --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/3] wandboard: Set default environment to use zImage
On 06/01/2014 16:27, Otavio Salvador wrote: > From: John Weber > > Change the default environment to use zImage instead of uImage, this > requires changes to the default environment to load a file named > zImage instead of uImage, and to use the 'bootz' command instead of > 'bootm' when booting the kernel. > > The zImage works for FSL Linux's kernel fork versions 3.0.35, 3.10.9, > and 3.10.17; this also works fine for mainline kernels. > > Signed-off-by: John Weber > Signed-off-by: Otavio Salvador > --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/3] mx6sabresd: Add eMMC specific environment to allow U-Boot update
On 06/01/2014 16:27, Otavio Salvador wrote: > A new 'update_emmc_firmware' target is added to allow for easy U-Boot > update in the eMMC as it has secury boot partition and this needs > specific handling on how to program the specific partition. > > Signed-off-by: Otavio Salvador > --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 00/17] sf: Add support for quad and dual_flash
Hi, On Mon, Jan 13, 2014 at 3:15 PM, Gerhard Sittig wrote: > On Sun, Jan 12, 2014 at 22:29 +0530, Jagannadha Sutradharudu Teki wrote: >> >> This series is a combo of quad cmds and dual_flash support >> Refer [1] and [2] for more functional description about this changes. >> >> [ ... ] >> >> Please let me know for any issues/concerns/questions. >> >> -- >> Thanks, >> Jagan. >> >> Changes for v7: >> - cmdsz on read_ops >> - sf param flags are placed spi_flash.h >> - code cleanup >> - updated dual_flash with BAR support >> [ ... ] > > Mail setup related nits: > > Please don't do this. The dash line correctly separates your > signature, which is good (and not a given either). But putting > more context below that line will make it look like it's part of > the signature, and thus probably will get lost (either by > automatic trimming, or folding, or colorization and/or mental > filtering). Yes - will take this input. > > Then I noticed that the series and your cover letter aren't > "connected". The series should be a reply to the cover letter, > while you seem to create and send them out in separate steps. > Which breaks their relation, and has them appear in random order > and with other messages in between them. Probably the random order appearance is some issue on my host server side. Will fix to encounter all the mails properly. > > And the recipient list suggests that there is an issue with > inappropriately quoted entries, there's another nonexistent > @theia address as has been in the past. Please fix this (I did > upon reply, check your original message). Try many times to fix this, any idea would appreciate. -- Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/3] wandboard: add Future Eletronics 7" WVGA LCD extension board
Hi Otavio, On 06/01/2014 16:27, Otavio Salvador wrote: > This adds support for the 7" WVGA produced by Future Eletronics and > make it dynamically detect if it is connected or not based on the > touchscreen controller. > > Signed-off-by: Otavio Salvador > --- > Changes in v5: None I would really prefer to apply this after factorizing the common function. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Quickstart-Manual for u-boot?
On Mon, 13 Jan 2014, Fred Fisch wrote: > Hi, > > I already found > > - the sources in GIT > - the config-name of my board > - the (really huge) manual > > Since all I want to do is just compile MLO/u-boot.img for BeagleBone > Black the latter seems to be totally oversized for me. > > So my question: is there some kind of quick-start/cookbook available > that just describes the steps to compile U-Boot for a single > platform? a while back, i wrote a number of wiki pages for boards including the BBB, and here's the basic recipe for u-boot for the BBB: http://www.crashcourse.ca/wiki/index.php/U-Boot_on_the_BBB#Building_a_stock_u-boot_for_the_BBB last time i looked, that recipe worked just fine. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] mx6: Add initial support for the Hummingboard solo
Hi Fbio, hi Joe, On 13/01/2014 11:41, Stefano Babic wrote: > Hi Fabio, > > On 13/01/2014 00:04, Fabio Estevam wrote: >> Hi Stefano, >> >> On Fri, Jan 3, 2014 at 3:55 PM, Fabio Estevam wrote: >>> From: Fabio Estevam >>> >>> SolidRun has designed the Hummingboard board based on mx6q/dl/solo. >>> >>> Add the initial support for the mx6 solo variant. >>> >>> More information about this hardware can be found at: >>> http://imx.solid-run.com/wiki/index.php?title=Carrier-One_Hardware >>> >>> (Carrier-One was the previous name of Hummingboard). >>> >>> Based on the work from Jon Nettleton . >>> >>> Signed-off-by: Jon Nettleton >>> Signed-off-by: Fabio Estevam >>> --- >>> Changes since v1: >>> - Addressed many of Stefano's comments about v1 >> >> Please let me know if you are happy with v2. >> > > I have not open issue with your patch - it looks great to me. > I discussed last week via IIRC with Otavio about if the patch can still flow into the coming release. He pointed me out that the original patch was sent a lot of time ago as "carrier-one": http://patchwork.ozlabs.org/patch/288017/ I could then consider your patch as a resubmit of the original patch and push it to -master, it does not matter if the subject was changed. The patch itself is not dangerous at all for other boards, so we are running on the safest way. However, it makes sense only if patch3/3 will be applied by Joe in the current release. http://patchwork.ozlabs.org/patch/306640/ Joe, do you plan to apply it for this release or is it already deferred to -next ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net/designware - switch driver to phylib usage
With this change driver will benefit from existing phylib and thus
custom phy functionality implemented in the driver will go away:
* Instantiation of the driver is now much shorter - 2 parameters
instead of 4.
* Simplified phy management/functoinality in driver is replaced with
rich functionality of phylib.
* Support of custom phy initialization is now done with existing
"board_phy_config".
Note that after this change some previously used config options
(driver-specific PHY configuration) will be obsolete and they are simply
substituted with similar options of phylib.
For example:
* CONFIG_DW_AUTONEG - no need in this one. Autonegotiation is enabled
by default.
* CONFIG_DW_SEARCH_PHY - if one wants to specify attached phy
explicitly CONFIG_PHY_ADDR board config option has to be used, otherwise
automatically the first discovered on MDIO bus phy will be used
I believe there's no need now in "doc/README.designware_eth" because
user only needs to instantiate the driver with "designware_initialize"
whose prototype exists in "include/netdev.h".
Signed-off-by: Alexey Brodkin
Cc: Joe Hershberger
Cc: Vipin Kumar
Cc: Stefan Roese
Cc: Mischa Jonker
---
board/bf609-ezkit/bf609-ezkit.c | 4 +-
board/spear/spear300/spear300.c | 3 +-
board/spear/spear310/spear310.c | 3 +-
board/spear/spear320/spear320.c | 3 +-
board/spear/spear600/spear600.c | 3 +-
board/spear/x600/x600.c | 25 +--
doc/README.designware_eth | 25 ---
drivers/net/designware.c| 462 +---
drivers/net/designware.h| 18 +-
include/configs/bf609-ezkit.h | 3 +-
include/configs/spear-common.h | 4 +-
include/configs/spear6xx_evb.h | 3 +
include/netdev.h| 2 +-
13 files changed, 179 insertions(+), 379 deletions(-)
delete mode 100644 doc/README.designware_eth
diff --git a/board/bf609-ezkit/bf609-ezkit.c b/board/bf609-ezkit/bf609-ezkit.c
index 0388226..19853fc 100644
--- a/board/bf609-ezkit/bf609-ezkit.c
+++ b/board/bf609-ezkit/bf609-ezkit.c
@@ -40,12 +40,12 @@ int board_eth_init(bd_t *bis)
if (CONFIG_DW_PORTS & 1) {
static const unsigned short pins[] = P_RMII0;
if (!peripheral_request_list(pins, "emac0"))
- ret += designware_initialize(0, EMAC0_MACCFG, 1, 0);
+ ret += designware_initialize(EMAC0_MACCFG, 0);
}
if (CONFIG_DW_PORTS & 2) {
static const unsigned short pins[] = P_RMII1;
if (!peripheral_request_list(pins, "emac1"))
- ret += designware_initialize(1, EMAC1_MACCFG, 1, 0);
+ ret += designware_initialize(EMAC1_MACCFG, 0);
}
return ret;
diff --git a/board/spear/spear300/spear300.c b/board/spear/spear300/spear300.c
index e25aba2..6b6bd9f 100644
--- a/board/spear/spear300/spear300.c
+++ b/board/spear/spear300/spear300.c
@@ -53,8 +53,7 @@ int board_eth_init(bd_t *bis)
#if defined(CONFIG_DESIGNWARE_ETH)
u32 interface = PHY_INTERFACE_MODE_MII;
- if (designware_initialize(0, CONFIG_SPEAR_ETHBASE, CONFIG_DW0_PHY,
- interface) >= 0)
+ if (designware_initialize(CONFIG_SPEAR_ETHBASE, interface) >= 0)
ret++;
#endif
return ret;
diff --git a/board/spear/spear310/spear310.c b/board/spear/spear310/spear310.c
index 70f9aa1..a4c6a8e 100644
--- a/board/spear/spear310/spear310.c
+++ b/board/spear/spear310/spear310.c
@@ -54,8 +54,7 @@ int board_eth_init(bd_t *bis)
#if defined(CONFIG_DESIGNWARE_ETH)
u32 interface = PHY_INTERFACE_MODE_MII;
- if (designware_initialize(0, CONFIG_SPEAR_ETHBASE, CONFIG_DW0_PHY,
- interface) >= 0)
+ if (designware_initialize(CONFIG_SPEAR_ETHBASE, interface) >= 0)
ret++;
#endif
#if defined(CONFIG_MACB)
diff --git a/board/spear/spear320/spear320.c b/board/spear/spear320/spear320.c
index f6b1fdd..ab732a7 100644
--- a/board/spear/spear320/spear320.c
+++ b/board/spear/spear320/spear320.c
@@ -65,8 +65,7 @@ int board_eth_init(bd_t *bis)
#if defined(CONFIG_DESIGNWARE_ETH)
u32 interface = PHY_INTERFACE_MODE_MII;
- if (designware_initialize(0, CONFIG_SPEAR_ETHBASE, CONFIG_DW0_PHY,
- interface) >= 0)
+ if (designware_initialize(CONFIG_SPEAR_ETHBASE, interface) >= 0)
ret++;
#endif
#if defined(CONFIG_MACB)
diff --git a/board/spear/spear600/spear600.c b/board/spear/spear600/spear600.c
index e996a0e..8472002 100644
--- a/board/spear/spear600/spear600.c
+++ b/board/spear/spear600/spear600.c
@@ -51,8 +51,7 @@ int board_eth_init(bd_t *bis)
#if defined(CONFIG_DW_AUTONEG)
interface = PHY_INTERFACE_MODE_GMII;
#endif
- if (designware_initialize(0, CONFIG_SPEAR_ETHBASE, CONFIG_DW0_PHY,
- interface) >= 0)
+ if (designware_initialize(CONFIG_SPEAR_ETHBASE, interface) >= 0)
ret
Re: [U-Boot] [PATCH v15 07/10] arm64: core support
Hi David,
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Bhupesh Sharma
> Sent: Tuesday, December 03, 2013 3:33 PM
> To: 'FengHua'
> Cc: 'tr...@ti.com'; 'u-boot@lists.denx.de'; Wood Scott-B07421
> Subject: Re: [U-Boot] [PATCH v15 07/10] arm64: core support
>
> > -Original Message-
> > From: FengHua [mailto:feng...@phytium.com.cn]
> > Sent: Sunday, December 01, 2013 7:48 PM
> > To: Sharma Bhupesh-B45370
> > Cc: 'Bhupesh SHARMA'; 'u-boot@lists.denx.de'; 'tr...@ti.com'; Wood
> > Scott-
> > B07421
> > Subject: Re: RE: Re: [U-Boot] [PATCH v15 07/10] arm64: core support
> >
> >
> > > > -Original Message-
> > > > From: FengHua [mailto:feng...@phytium.com.cn]
> > > > Sent: Friday, November 29, 2013 7:05 PM
> > > > To: Bhupesh SHARMA
> > > > Cc: u-boot@lists.denx.de; Sharma Bhupesh-B45370; tr...@ti.com;
> > > > Wood
> > > > Scott-B07421
> > > > Subject: Re: Re: [U-Boot] [PATCH v15 07/10] arm64: core support
> > > >
> > > >
> > > > hi Bhupesh,
> > > > Thank you for reviewing of the patch.
> > > >
> > > > > > +/*
> > > > > > + * Generic timer implementation of timer_read_counter() */
> > > > > > +unsigned long timer_read_counter(void) {
> > > > > > + unsigned long cntpct;
> > > > > > + isb();
> > > > > > + asm volatile("mrs %0, cntpct_el0" : "=r" (cntpct));
> > > > > > + return cntpct;
> > > > > > +}
> > > > > > diff --git a/arch/arm/cpu/armv8/gic.S
> > > > > > b/arch/arm/cpu/armv8/gic.S
> > > > >
> > > > > The ARMv8 foundation model has support for GICv2 while GICv3 is
> > > > > actually compatible to ARMv8. So although you mention in the
> > > > > cover letter that this is currently GICv2 support, now while
> > > > > trying to add
> > > > > GICv3 support it will be difficult to envision GICv2 code in
> > > > 'arch/arm/cpu/armv8/'
> > > > > directory.
> > > > >
> > > > > Infact GICv2 is compatible with ARMv7 and as secure and
> > > > > non-secure copies of GIC registers are equally applicable to
> > > > > ARMv7, would it make sense to keep the GICv2 code at a place
> > > > > where both ARMv7 and
> > > > > ARMv8 can use it?
> > > > >
> > > > > Can we reuse something from [1] for GICv2:
> > > > >
> > > > > [1]
> > > > > http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/non
> > > > > se
> > > > > c_vi
> > > > > rt.S;h=24b4c18bd452fa155bcd5ed94c755aa05a33efe7;hb=HEAD#l88
> > > > >
> > > >
> > > > Gicv2 only support maximum 8 cores, but still could be used with
> > > > armv8 processors if the processor contains less than 8 cores.
> > > > AMCC's
> > > > armv8 processor use Gicv2.
> > > > Yes, as you said it would be better to abstract a few common
> > > > routines of
> > > > Gicv2 and Gicv3 code and place them at a common place (such as
> > > > arm/lib) so that both ARMv7 and ARMv8 could use it.
> > > >
> > > > > > + /* Cache/BPB/TLB Invalidate */
> > > > > > + bl __asm_flush_dcache_all /* dCache
> > clean&invalidate */
> > > > > > + bl __asm_invalidate_icache_all /* iCache invalidate */
> > > > > > + bl __asm_invalidate_tlb_all/* invalidate TLBs */
> > > > > > +
> > > > > > + /* Processor specific initialization */
> > > > > > + bl lowlevel_init
> > > > >
> > > > > Shouldn't this call be protected inside a '#ifndef
> > > > > CONFIG_SKIP_LOWLEVEL_INIT'?
> > > > >
> > > > We could do so when it is actually needed.
> > > >
> > > > > > +WEAK(lowlevel_init)
> > > > >
> > > > > Ok, so this means that a specific SoC lowlevel_init
> > > > > implementation can override this generic implementation. Because
> > > > > I sure other secure/non-secure settings need to be put into
> > > > > place for ARM IPs like SMMU-500.
> > > > >
> > > >
> > > > > > +ENTRY(armv8_switch_to_el2)
> > > > >
> > > > > Do we need a switch to Secure Monitor here? I am not able to
> > > > > relate how this with the present ARMv7 code (see [2]):
> > > > >
> > > > > [2]
> > > > > http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/non
> > > > > se
> > > > > c_vi
> > > > > rt.S;h=24b4c18bd452fa155bcd5ed94c755aa05a33efe7;hb=HEAD#l29
> > > > >
> > > > Armv8 processor reset at el3(if it support security extension). So
> > > > we need to switch the processor to el2 or el1 before u-boot jump
> > > > to linux kernel due to linux-aarch64 only run at el2 or el1.
> > > >
> > >
> > > Hi David,
> > >
> > > As per ARMv8 Arch Reference Manual (ARM), Monitor mode is provided
> > > to support switching between Secure and Non-secure states. For
> > > switching from secure to non secure state the usual mechanism is an
> > > exception return. To return to Non-secure state (EL1/EL2), software
> > > executing in
> > Monitor mode(EL3) sets SCR.NS to 1 and then performs the exception
> > return.
> > >
> > > The implementation already in place for ARMv7 (see:
> > > http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/nonsec_
> > > vi rt.S;h=24b4c18bd452fa155bcd5ed94c755aa05a33efe7;hb=HEAD#l29),
> > > do
Re: [U-Boot] [PATCH] net/designware - switch driver to phylib usage
Completely forgot to mention that there's a prerequisite (http://patchwork.ozlabs.org/patch/309319/): == [PATCH] net: execute "miiphy_init" if CONFIG_PHYLIB defined == This makes sure that phylib will be correctly initialized even if there's no explicit mention of either entry in board configuration: * CONFIG_MII * CONFIG_CMD_MII Even though all existing boards do have CONFIG_MII set still it's good to have all missing parts in place. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ums: wait for usb cable connection before enter ums mode
On Monday, January 13, 2014 at 10:18:51 AM, Przemyslaw Marczak wrote:
> Hello everyone,
>
> On 01/07/2014 03:08 PM, Przemyslaw Marczak wrote:
> > Before this change ums mode can not be entered when device
> > was using the same usb port for usb/uart communication.
> > Switching USB cable from UART to USB always causes ums exit.
> >
> > Signed-off-by: Przemyslaw Marczak
> >
> > ---
> >
> > common/cmd_usb_mass_storage.c | 24
> > include/usb_mass_storage.h|3 +++
> > 2 files changed, 27 insertions(+)
> >
> > diff --git a/common/cmd_usb_mass_storage.c
> > b/common/cmd_usb_mass_storage.c index 99487f4..5f557d5 100644
> > --- a/common/cmd_usb_mass_storage.c
> > +++ b/common/cmd_usb_mass_storage.c
> > @@ -42,6 +42,30 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
> >
> > g_dnl_register("ums");
> >
> > + /* Timeout unit: seconds */
> > + int cable_ready_timeout = UMS_CABLE_READY_TIMEOUT;
> > +
> > + if (!usb_cable_connected()) {
> > + puts("Please connect USB cable.\n");
> > +
> > + while (!usb_cable_connected()) {
> > + if (ctrlc()) {
> > + puts("\rCTRL+C - Operation aborted.\n");
> > + goto exit;
> > + }
> > + if (!cable_ready_timeout) {
> > + puts("\rUSB cable not detected.\n" \
> > +"Command exit.\n");
> > + goto exit;
> > + }
> > +
> > + printf("\rAuto exit in: %.2d s.", cable_ready_timeout);
> > + mdelay(1000);
> > + cable_ready_timeout--;
> > + }
> > + puts("\r\n");
> > + }
> > +
> >
> > while (1) {
> >
> > usb_gadget_handle_interrupts();
> >
> > diff --git a/include/usb_mass_storage.h b/include/usb_mass_storage.h
> > index 9df3adc..058dcf1 100644
> > --- a/include/usb_mass_storage.h
> > +++ b/include/usb_mass_storage.h
> > @@ -20,6 +20,9 @@
> >
> > #define UMS_NUM_SECTORS 0
> > #endif
> >
> > +/* Wait at maximum 60 seconds for cable connection */
> > +#define UMS_CABLE_READY_TIMEOUT60
> > +
> >
> > struct ums {
> >
> > int (*read_sector)(struct ums *ums_dev,
> >
> >ulong start, lbaint_t blkcnt, void *buf);
>
> I was send some very useful fix to the ums. It is required for users who
> are using the same usb port for USB and UART purposes. Without this fix
> such users just can't use ums because it will always exit to prompt when
> user change the cable.
Can you please share the schematic of such a cable in public? How does this
"sharing" of USB and UART work? I am very curious here :-)
> So I have few questions...
> Marek, could you review this patch?
On it!
> And what about the release, are you going to send pull request before
> the release?
> If not, then is it possible to apply this patch directly to
> u-boot/master by Tom Rini?
PR will happen once I am through the load of patches in my mailbox.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ums: wait for usb cable connection before enter ums mode
On Tuesday, January 07, 2014 at 03:08:37 PM, Przemyslaw Marczak wrote: > Before this change ums mode can not be entered when device > was using the same usb port for usb/uart communication. > Switching USB cable from UART to USB always causes ums exit. > > Signed-off-by: Przemyslaw Marczak Applied, thanks. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/2] Add usb ethernet support for Arndale
On Wednesday, January 08, 2014 at 04:49:55 AM, Inderpal Singh wrote: > Arndale board has AX88760, which is USB 2.0 Hub & USB 2.0 Ethernet Combo > controller, connected to HSIC Phy of USB host controller via USB3503 hub. > > This patchset adds support for this usb ethernet controllor. > > Changes in v2: > - removed setting preboot environment in patch 2 > Changes in v3: > - used generic board_usb_init > > Inderpal Singh (2): > usb: ehci: exynos: set/reset hsic phys > usb: exynos5: arndale: Add network support > > arch/arm/include/asm/arch-exynos/ehci.h | 14 +++ > board/samsung/arndale/arndale.c | 21 > drivers/usb/host/ehci-exynos.c | 41 > +++ include/configs/arndale.h | > 4 +++ > 4 files changed, 80 insertions(+) Applied both, thanks. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-pxa/master
Minor fixes, please apply for 2014.01 The following changes since commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca: Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 10:56:00 -0500) are available in the git repository at: git://git.denx.de/u-boot-pxa.git master for you to fetch changes up to 4efd69250f6118ebd783867b3809001a1886ce9e: ARM: pxa: Fix OneNAND window access on VPAC270 (2014-01-13 12:39:10 +0100) Marek Vasut (2): ARM: pxa: Fix OneNAND SPL builds ARM: pxa: Fix OneNAND window access on VPAC270 arch/arm/cpu/pxa/config.mk | 13 + board/vpac270/u-boot-spl.lds | 1 + include/configs/vpac270.h| 2 +- 3 files changed, 15 insertions(+), 1 deletion(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
Minor fixes, please apply for 2014.01 The following changes since commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca: Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 10:56:00 -0500) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 3603e31db54ddba820b7a7b9c7659e272f8c65de: usb: ums: wait for usb cable connection before enter ums mode (2014-01-13 12:29:12 +0100) Inderpal Singh (2): usb: ehci: exynos: set/reset hsic phys usb: exynos5: arndale: Add network support Kuo-Jung Su (2): usb: gadget: fotg210: add w1c interrupt status support usb: gadget: fotg210: EP0 fifo empty indication is non-reliable Przemyslaw Marczak (1): usb: ums: wait for usb cable connection before enter ums mode arch/arm/include/asm/arch-exynos/ehci.h | 14 ++ board/samsung/arndale/arndale.c | 21 + common/cmd_usb_mass_storage.c | 24 drivers/usb/gadget/fotg210.c| 15 +++ drivers/usb/host/ehci-exynos.c | 41 + include/configs/arndale.h | 4 include/usb_mass_storage.h | 3 +++ 7 files changed, 122 insertions(+) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBIFS seeing corrupt blank pages when image flashed via u-boot
Hi, On Fri, Jan 3, 2014 at 6:29 PM, Artem Bityutskiy wrote: > > Hi Pekon, > > On Fri, 2014-01-03 at 11:45 +, Gupta, Pekon wrote: > > *_Case-1_ Flashing UBIFS image from u-boot using 'nand write' utility* > > > > For a partially written erased-block.. > > (a) 1st page is written with 'erase-header' > > (b) 2nd page is written with 'volume-header' > > (c) '3rd page' is written with 'some data' > > (d) '4th to last-page of block' should be left blank, but they are written > > with 0xFF. > > As a effect of (d), the ECC calculated for (all 0xff data) is written to > > OOB area of all pages from 4th-page till last-page of the PEB. > > Yup. > If the 4th to last-page are left blank and not covered with ECC, what will happen in case of bit flips on the blank pages? There was an issue reported some time back. http://lists.infradead.org/pipermail/linux-mtd/2012-January/039256.html Does UBI/UBIFS take care of this now? Thanks, Calvin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 01/17] sf: Add extended read commands support
Hi, On Mon, Jan 13, 2014 at 4:26 PM, Jagan Teki wrote: > Hi Gerhard Sittig, > > Thanks for your comments, please see below > > On Mon, Jan 13, 2014 at 3:04 PM, Gerhard Sittig wrote: >> On Sun, Jan 12, 2014 at 22:29 +0530, Jagannadha Sutradharudu Teki wrote: >>> >>> Current sf uses FAST_READ command, this patch adds support to >>> use the different/extended read command. >>> >>> This implementation will determine the fastest command by taking >>> the supported commands from the flash and the controller, controller >>> is always been a priority. >> >> I don't quite get this. You have a combination of several >> components which all have to participate appropriately when you >> want the total of it to work correctly. >> >> How can one specific component "be a priority" there? Isn't the >> lowest common denominator required instead? The strength of a >> chain is determined by its weakest link after all. >> >> >> The other issue I have here (as well as in Linux kernel changes >> and discussions) is that people seem to forget that the board is >> involved as well. >> >> Your commit message suggests that "parallel" communication is >> used as soon as >> - the SPI controller has such a feature >> - a flash chip was detected which according to a fixed database >> supports this feature >> >> This decision is automatic. Neither is there a "how is the >> board wired?" condition involved, nor can users or even >> developers adjust this behaviour (say, by optionally setting a >> maximum width). >> >> I'd suggest to provide a "maximum number of lines to use" option, >> for the same reasons that we may want to limit transfer rates >> instead of always using the maximum of what individual chips >> could do (the reasons: the number of lines connected as well as >> their electrical and mechanical properties do have an impact). >> >> Alternatively one may implement auto-detection, starting at the >> most capable feature and falling back until a working condition >> was found. But this is fragile if the communication used at >> detection time does not involve all potentially used lines (and >> in all directions, mind you). This won't solve potential bugs in >> chips either which the user may want to override. Or EMI related >> restrictions which a developer may want to apply despite the >> chips' and board's being more capable. Or pin mux settings which >> dedicate unused "upper SPI data lines" to other features (as we >> have seen with MMC cards recently). > > Yes the main reason for going maximum or based on controller setting > transfer is to improve sf performance. I missed your point as didn't > see much use cases from board to connected flash perceptive. > > I thought we have two options to meet this requirement. > 1. dynamic - auto-detection: > Get the max_nof_lines based on the board to connected flash. > So-that we can configure the transfer mode based on the lines. > no idea yet, how to get the max_nof_lines dynamically - any inputs. > 2. static: from user level we may give the max_nof_lines > ex: sf probe probe [[[bus:]cs]:max_nof_line] [hz] [mode] > If user can't input max_nof_line so-that driver will go with single and > the rest case transfer modes assigned based on the given input. As this change involves mostly on the driver parts I a thinking to go-ahead and try to push this series to master. yes I would mark this as my TODO list and will trigger one more thread. Hope this idea sounds valid, let me know for any issues. -- Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBIFS seeing corrupt blank pages when image flashed via u-boot
On Mon, 2014-01-13 at 17:49 +0530, Calvin Johnson wrote: > If the 4th to last-page are left blank and not covered with ECC, what > will happen in case of bit flips on the blank pages? There was an > issue reported some time back. > http://lists.infradead.org/pipermail/linux-mtd/2012-January/039256.html > > Does UBI/UBIFS take care of this now? No. UBIFS still assumes that blank pages are ECC-protected by the driver. No one stepped in and took care of changing this yet. -- Best Regards, Artem Bityutskiy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-pxa/master
Hi Marek, On Mon, 13 Jan 2014 12:42:35 +0100, Marek Vasut wrote: > Minor fixes, please apply for 2014.01 > > The following changes since commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca: > > > > > > Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 10:56:00 > -0500) > > > are available in the git repository at: > > > git://git.denx.de/u-boot-pxa.git master > > for you to fetch changes up to 4efd69250f6118ebd783867b3809001a1886ce9e: > > ARM: pxa: Fix OneNAND window access on VPAC270 (2014-01-13 12:39:10 +0100) > > > Marek Vasut (2): > ARM: pxa: Fix OneNAND SPL builds > ARM: pxa: Fix OneNAND window access on VPAC270 > > arch/arm/cpu/pxa/config.mk | 13 + > board/vpac270/u-boot-spl.lds | 1 + > include/configs/vpac270.h| 2 +- > 3 files changed, 15 insertions(+), 1 deletion(-) Tom: please hold the release. I'll send you this plus a bugfix patch in an hour or so. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBIFS seeing corrupt blank pages when image flashed via u-boot
Hi Calvin, >From: Artem Bityutskiy [mailto:artem.bityuts...@linux.intel.com] >>On Mon, 2014-01-13 at 17:49 +0530, Calvin Johnson wrote: >> If the 4th to last-page are left blank and not covered with ECC, what >> will happen in case of bit flips on the blank pages? There was an >> issue reported some time back. >> http://lists.infradead.org/pipermail/linux-mtd/2012-January/039256.html >> >> Does UBI/UBIFS take care of this now? > >No. UBIFS still assumes that blank pages are ECC-protected by the >driver. No one stepped in and took care of changing this yet. > Yes, it's true that in newer technologies (specially < 28nm flash), we are seeing lot of erased-pages having bit-flips. And due to which UBIFS is cribbing. But as there is no ECC stored in an erased-page, bit-flips in erased-page cannot be corrected, unless you compare each byte of read_data. However, there are other way of handling bit-flips in erased-page. Following are few ways in which OMAP NAND driver handles bit-flips in erased-page: *Case-1*: If bit-flips are found in data-region of an erased-page. (1) An erased-page implicitly means that its data-region should *only* contain 0xff, so its safe to fill read_buf() with 0xff. But the controller driver should report the correctable/un-correctable bit-flips to upper-layer, so that upper-layers like UBI take corrective action by re-erase this block before using it. (Refer) http://lists.infradead.org/pipermail/linux-mtd/2014-January/051368.html *Case-2*: If bit-flips are found in oob-region of an erased-page. This is bit trivial, because if there are bit-flips in ecc-layout (OOB region) of erased-page, it would be difficult to differentiate between an erased-page v/s programmed-page. Though you can keep a 'marker' in ecc-layout reserved for detecting Programmed-pages, but that marker byte itself can be subjected to bit-flips (assuming on MLC and newer technology NAND bit-flips are common). So, OMAP NAND driver takes probabilistic approach. (Refer) http://lists.infradead.org/pipermail/linux-mtd/2014-January/051367.html --- This patch 'assumes' any page to be 'erased': (a) ifall(read_ecc) == 0xff (b) else if all(read_data) == 0xff --- Currently both UBI and UBIFS layer checks for erased-page to be all(0xff), But I think its over-kill to put this burden on UBI or UBIFS layer, because low-level controller drivers can handle this easily. So, if Artem and Brian agree to above approaches, then I can a submit patch for removal of: - "ubi_self_check_all_ff()" from UBI layer. - checking of 'buf == 0xff' from ubifs_scan_leb() in UBIFS layer. with regards, pekon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ums: wait for usb cable connection before enter ums mode
Hello,
On 01/13/2014 12:14 PM, Marek Vasut wrote:
On Monday, January 13, 2014 at 10:18:51 AM, Przemyslaw Marczak wrote:
Hello everyone,
On 01/07/2014 03:08 PM, Przemyslaw Marczak wrote:
Before this change ums mode can not be entered when device
was using the same usb port for usb/uart communication.
Switching USB cable from UART to USB always causes ums exit.
Signed-off-by: Przemyslaw Marczak
---
common/cmd_usb_mass_storage.c | 24
include/usb_mass_storage.h|3 +++
2 files changed, 27 insertions(+)
diff --git a/common/cmd_usb_mass_storage.c
b/common/cmd_usb_mass_storage.c index 99487f4..5f557d5 100644
--- a/common/cmd_usb_mass_storage.c
+++ b/common/cmd_usb_mass_storage.c
@@ -42,6 +42,30 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
g_dnl_register("ums");
+ /* Timeout unit: seconds */
+ int cable_ready_timeout = UMS_CABLE_READY_TIMEOUT;
+
+ if (!usb_cable_connected()) {
+ puts("Please connect USB cable.\n");
+
+ while (!usb_cable_connected()) {
+ if (ctrlc()) {
+ puts("\rCTRL+C - Operation aborted.\n");
+ goto exit;
+ }
+ if (!cable_ready_timeout) {
+ puts("\rUSB cable not detected.\n" \
+"Command exit.\n");
+ goto exit;
+ }
+
+ printf("\rAuto exit in: %.2d s.", cable_ready_timeout);
+ mdelay(1000);
+ cable_ready_timeout--;
+ }
+ puts("\r\n");
+ }
+
while (1) {
usb_gadget_handle_interrupts();
diff --git a/include/usb_mass_storage.h b/include/usb_mass_storage.h
index 9df3adc..058dcf1 100644
--- a/include/usb_mass_storage.h
+++ b/include/usb_mass_storage.h
@@ -20,6 +20,9 @@
#define UMS_NUM_SECTORS 0
#endif
+/* Wait at maximum 60 seconds for cable connection */
+#define UMS_CABLE_READY_TIMEOUT60
+
struct ums {
int (*read_sector)(struct ums *ums_dev,
ulong start, lbaint_t blkcnt, void *buf);
I was send some very useful fix to the ums. It is required for users who
are using the same usb port for USB and UART purposes. Without this fix
such users just can't use ums because it will always exit to prompt when
user change the cable.
Can you please share the schematic of such a cable in public?
Unfortunately I am not allowed to share such information.
How does this
"sharing" of USB and UART work? I am very curious here :-)
Regarding the USB sharing explanation - please refer to FSA9480 data
sheet. It is available on the Internet.
I can also recommend looking into newest kernel code support for Trats2
device.
So I have few questions...
Marek, could you review this patch?
On it!
And what about the release, are you going to send pull request before
the release?
If not, then is it possible to apply this patch directly to
u-boot/master by Tom Rini?
PR will happen once I am through the load of patches in my mailbox.
Thank you for patch apply.
Regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/9] dfu:mmc: raw data write fix
On 01/10/14 06:03, Jaehoon Chung wrote:
> This patch should be separated with dfu and mmc.
ACK, because we're going to remove the bl_len assertion, see below.
> On 01/09/2014 11:31 PM, Mateusz Zalega wrote:
>> When user attempted to perform a raw write using DFU (vide
>> dfu_fill_entity_mmc) with MMC interface not initialized before,
>> get_mmc_blk_size() reported invalid (zero) block size - it wasn't
>> possible to write ie. a new u-boot image.
>>
>> This commit fixes that by initializing device in get_mmc_blk_size() when
>> needed.
>>
>> Tested on Samsung Goni.
>>
>> v2 changes:
>> - code cleanup
>> - minor dfu_alt_info format change
>>
>> v3 changes:
>> - moved invalid block length check to mmc core
>> - removed redundant 'has_init' check
>>
>> Change-Id: Icb50bb9f805a9a78848acd19f682fad474cb9082
>> Signed-off-by: Mateusz Zalega
>> Signed-off-by: Kyungmin Park
>> Reviewed-by: Lukasz Majewski
>> Cc: Minkyu Kang
>> ---
>> drivers/dfu/dfu_mmc.c| 106
>> ++-
>> drivers/mmc/mmc.c| 13 --
>> include/configs/am335x_evm.h | 8 ++--
>> include/configs/trats.h | 2 +-
>> include/configs/trats2.h | 2 +-
>> include/dfu.h| 5 --
>> 6 files changed, 80 insertions(+), 56 deletions(-)
>>
>> diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
(...)
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index e1461a9..f2fa230 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -15,6 +15,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include "mmc_private.h"
>>
>> /* Set block count limit because of 16 bit register limit on some hardware*/
>> @@ -1266,17 +1267,23 @@ static int mmc_complete_init(struct mmc *mmc)
>>
>> int mmc_init(struct mmc *mmc)
>> {
>> +if (mmc->has_init)
>> +return 0;
>> +
> What difference before?
It doesn't have to go through get_timer(). The effect, although
negligible, saves some cycles.
>> int err = IN_PROGRESS;
>> unsigned start = get_timer(0);
>>
>> -if (mmc->has_init)
>> -return 0;
>> if (!mmc->init_in_progress)
>> err = mmc_start_init(mmc);
>> -
> Need not to change.
>
>> if (!err || err == IN_PROGRESS)
>> err = mmc_complete_init(mmc);
>> +
> Ditto.
NAK, it improves code readability.
>> debug("%s: %d, time %lu\n", __func__, err, get_timer(start));
>> +
>> +if (!mmc->read_bl_len || !mmc->write_bl_len) {
>> +error("invalid block length\n");
>> +return -ENODEV;
>> +}
> I know mmc->read_bl_len and write_bl_len is set at init time.
> Why this condition needs?
I added it as a countermeasure after fixing the bug and mistook its
purpose when writing a late update to this patch, my bad.
Given the circumstances it might be a sound assertion, but we shouldn't
clobber the codebase that we aim to optimize for size, should we.
ACK, will remove.
>> return err;
>> }
>>
>> diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
>> index 8af4d6a..d76962f 100644
>> --- a/include/configs/am335x_evm.h
>> +++ b/include/configs/am335x_evm.h
>> @@ -312,10 +312,10 @@
>> "boot part 0 1;" \
>> "rootfs part 0 2;" \
>> "MLO fat 0 1;" \
>> -"MLO.raw mmc 100 100;" \
>> -"u-boot.img.raw mmc 300 400;" \
>> -"spl-os-args.raw mmc 80 80;" \
>> -"spl-os-image.raw mmc 900 2000;" \
>> +"MLO.raw mmc 0x100 0x100;" \
>> +"u-boot.img.raw mmc 0x300 0x400;" \
>> +"spl-os-args.raw mmc 0x80 0x80;" \
>> +"spl-os-image.raw mmc 0x900 0x2000;" \
>> "spl-os-args fat 0 1;" \
>> "spl-os-image fat 0 1;" \
>> "u-boot.img fat 0 1;" \
>> diff --git a/include/configs/trats.h b/include/configs/trats.h
>> index 6cd15c2..ed3b278 100644
>> --- a/include/configs/trats.h
>> +++ b/include/configs/trats.h
>> @@ -140,7 +140,7 @@
>> "name="PARTS_UMS",size=-,uuid=${uuid_gpt_"PARTS_UMS"}\0" \
>>
>> #define CONFIG_DFU_ALT \
>> -"u-boot mmc 80 400;" \
>> +"u-boot raw 0x80 0x400;" \
>> "uImage ext4 0 2;" \
>> "exynos4210-trats.dtb ext4 0 2;" \
>> ""PARTS_ROOT" part 0 5\0"
>> diff --git a/include/configs/trats2.h b/include/configs/trats2.h
>> index 5d86a3d..a22be63 100644
>> --- a/include/configs/trats2.h
>> +++ b/include/configs/trats2.h
>> @@ -169,7 +169,7 @@
>> "name="PARTS_UMS",size=-,uuid=${uuid_gpt_"PARTS_UMS"}\0" \
>>
>> #define CONFIG_DFU_ALT \
>> -"u-boot mmc 80 800;" \
>> +"u-boot mmc 0x80 0x800;" \
>
> u-boot mmc? u-boot raw? what's correct?
raw - ACK
>> "uImage ext4 0 2;" \
>> "exynos4412-trats2.dtb ext4 0 2;" \
>> ""PARTS_ROOT" part 0 5\0"
>> diff --git a/include/dfu.h b/include/dfu.h
>> index f973426..f2e83db 100644
>> --- a/include/dfu.h
>> +++ b/include/dfu.h
>> @@ -64,11 +64,6 @@ struct ram_internal_data {
>> unsigned intsize;
>> };
>>
>> -static inline unsigned int get_mmc_blk_size(int dev)
>> -{
>> -return
Re: [U-Boot] [PATCH] arm: New stack pointer is already aligned
On Mon, Jan 13, 2014 at 10:07:50AM +0100, Albert ARIBAUD wrote: > Hi Wolfgang, > > On Fri, 29 Nov 2013 07:14:13 +0100, Wolfgang Denk wrote: > > > Dear Tom Rini, > > > > In message <1385580930-9830-1-git-send-email-tr...@ti.com> you wrote: > > > The code in arch/arm/lib/board.c::board_init_f that sets > > > gd->start_addr_sp has already make sure we're 8-byte aligned, so we > > > don't need to do that again. > > > > > > Cc: Albert ARIBAUD > > > Signed-off-by: Tom Rini > > > --- > > > arch/arm/lib/crt0.S |1 - > > > 1 file changed, 1 deletion(-) > > > > > > diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S > > > index ac54b93..6b5ec01 100644 > > > --- a/arch/arm/lib/crt0.S > > > +++ b/arch/arm/lib/crt0.S > > > @@ -82,7 +82,6 @@ ENTRY(_main) > > > */ > > > > > > ldr sp, [r9, #GD_START_ADDR_SP] /* sp = gd->start_addr_sp */ > > > - bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ > > > ldr r9, [r9, #GD_BD]/* r9 = gd->bd */ > > > sub r9, r9, #GD_SIZE/* new GD is below bd */ > > > > I recommend to keep this instruction. It's just a bit of defensive > > programming, and removing it does not save any measurable amount of > > memory footprint nor execution time. > > I would even go further: it is the setting of SP in C code which > should not be kept. I doubt the C specification mentions what should / > might happen when changing the stack pointer on the fly in code which > might need the stack at any point. I'm fine with dropping this patch (I noticed as I was tracing something else). But please note that in C we're just setting gd->start_addr_sp and aligning it there, we don't modify sp at all until the snippet of asm above. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc:Rename CONFIG_PBLRCW_CONFIG & CONFIG_SYS_FSL_PBL_PBI
Dear Prabhakar, In message <52d37cf5.2090...@freescale.com> you wrote: > > > What is the reason for the reenaming? Especially, why changing from > > CONFIG_ to CONFIG_SYS_ ? > > CONFIG_PBLRCW_CONFIG has 2 CONFIG. it is slightly confusing. > > Reason for moving CONFIG_ to CONFIG_SYS: These defines enables of > adding RCW(power on reset configuration) and > PBI(pre boot loader commands) in u-boot image. These information will be > used by SoC hardware for NAND, SD, SPI boot. > As these configuration will be used by SoC hardware. I thought of adding > CONFIG_SYS. CONFIG_ means stuff that can be freely adjusted by the end user to match his likings, like adding one command and removing another. CONFIG_SYS_ means stuff that is determined by the hardware configuration, i. e. that has to be adjusted according to specific properties to make U-Boot working on some hardware, and which can (or should) not be "adjusted" by the end user. I don;t understand your intentions enough to say which applies here; IIRC at least PBI might be more of the CONFIG_ type. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de How many hardware guys does it take to change a light bulb? "Well the diagnostics say it's fine buddy, so it's a software problem." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot 3/3] spl: common: Support for USB MSD FAT image loading
On 01/10/2014 07:02 AM, Dan Murphy wrote: > Add SPL support to be able to detect a USB Mass Storage device > connected to a USB host. Once a USB Mass storage device is detected > the SPL will load the u-boot.img from a FAT partition to target address. > > Signed-off-by: Dan Murphy > --- > arch/arm/include/asm/arch-am33xx/spl.h | 14 ++-- > common/Makefile|4 +++ > common/spl/Makefile|1 + > common/spl/spl.c |5 +++ > common/spl/spl_fat.c | 16 - > common/spl/spl_usb.c | 58 > > include/spl.h |3 ++ > spl/Makefile |2 ++ > 8 files changed, 92 insertions(+), 11 deletions(-) > create mode 100644 common/spl/spl_usb.c > > diff --git a/arch/arm/include/asm/arch-am33xx/spl.h > b/arch/arm/include/asm/arch-am33xx/spl.h > index 95de9aa..cd1d88d 100644 > --- a/arch/arm/include/asm/arch-am33xx/spl.h > +++ b/arch/arm/include/asm/arch-am33xx/spl.h > @@ -20,6 +20,7 @@ > #if defined(CONFIG_AM33XX) || defined(CONFIG_AM43XX) > #define BOOT_DEVICE_MMC1 8 > #define BOOT_DEVICE_MMC2 9 /* eMMC or daughter card */ > +#define BOOT_DEVICE_USB 13 After a rebase it appears this does not get merged to the right spot. I can submit a V2 if the maintainer wants me to or it can be a fix up once applied. -- -- Dan Murphy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] arm: put .hash, .got.plt and .machine_param back in binaries
Some targets will build fine but not boot if sections .hash and
.got.plt are not present in the binary. Add them back.
Also, Exynos machines require .machine_param section in SPL.
Add it.
Signed-off-by: Albert ARIBAUD
---
V3: rebase
V2: remove SREC generation for SPL
arch/arm/config.mk | 2 +-
arch/arm/cpu/armv7/exynos/config.mk | 7 +++
arch/arm/cpu/u-boot.lds | 3 +--
spl/Makefile| 2 +-
4 files changed, 10 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/cpu/armv7/exynos/config.mk
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 329c7a7..cfa4209 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -109,5 +109,5 @@ endif
ifdef CONFIG_ARM64
OBJCFLAGS += -j .text -j .rodata -j .data -j .u_boot_list -j .rela.dyn
else
-OBJCFLAGS += -j .text -j .rodata -j .data -j .u_boot_list -j .rel.dyn
+OBJCFLAGS += -j .text -j .rodata -j .hash -j .data -j .got.plt -j .u_boot_list
-j .rel.dyn
endif
diff --git a/arch/arm/cpu/armv7/exynos/config.mk
b/arch/arm/cpu/armv7/exynos/config.mk
new file mode 100644
index 000..ee0d2da
--- /dev/null
+++ b/arch/arm/cpu/armv7/exynos/config.mk
@@ -0,0 +1,7 @@
+#
+# Copyright (C) Albert ARIBAUD
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+SPL_OBJCFLAGS += -j .machine_param
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 9463a33..4da5d24 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -92,8 +92,6 @@ SECTIONS
}
.dynsym _end : { *(.dynsym) }
- .hash : { *(.hash) }
- .got.plt : { *(.got.plt) }
.dynbss : { *(.dynbss) }
.dynstr : { *(.dynstr*) }
.dynamic : { *(.dynamic*) }
@@ -101,4 +99,5 @@ SECTIONS
.interp : { *(.interp*) }
.gnu : { *(.gnu*) }
.ARM.exidx : { *(.ARM.exidx*) }
+ .gnu.linkonce.armexidx : { *(.gnu.linkonce.armexidx.*) }
}
diff --git a/spl/Makefile b/spl/Makefile
index 003956e..5e5472d 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -165,7 +165,7 @@ $(obj)$(BOARD)-spl.bin: $(obj)u-boot-spl.bin
endif
$(obj)$(SPL_BIN).bin: $(obj)$(SPL_BIN)
- $(OBJCOPY) $(OBJCFLAGS) -O binary $< $@
+ $(OBJCOPY) $(OBJCFLAGS) $(SPL_OBJCFLAGS) -O binary $< $@
GEN_UBOOT = \
cd $(obj) && $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $(__START) \
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ums: wait for usb cable connection before enter ums mode
On Monday, January 13, 2014 at 02:31:58 PM, Przemyslaw Marczak wrote:
> Hello,
>
> On 01/13/2014 12:14 PM, Marek Vasut wrote:
> > On Monday, January 13, 2014 at 10:18:51 AM, Przemyslaw Marczak wrote:
> >> Hello everyone,
> >>
> >> On 01/07/2014 03:08 PM, Przemyslaw Marczak wrote:
> >>> Before this change ums mode can not be entered when device
> >>> was using the same usb port for usb/uart communication.
> >>> Switching USB cable from UART to USB always causes ums exit.
> >>>
> >>> Signed-off-by: Przemyslaw Marczak
> >>>
> >>> ---
> >>>
> >>>common/cmd_usb_mass_storage.c | 24
> >>>include/usb_mass_storage.h|3 +++
> >>>2 files changed, 27 insertions(+)
> >>>
> >>> diff --git a/common/cmd_usb_mass_storage.c
> >>> b/common/cmd_usb_mass_storage.c index 99487f4..5f557d5 100644
> >>> --- a/common/cmd_usb_mass_storage.c
> >>> +++ b/common/cmd_usb_mass_storage.c
> >>> @@ -42,6 +42,30 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
> >>>
> >>> g_dnl_register("ums");
> >>>
> >>> + /* Timeout unit: seconds */
> >>> + int cable_ready_timeout = UMS_CABLE_READY_TIMEOUT;
> >>> +
> >>> + if (!usb_cable_connected()) {
> >>> + puts("Please connect USB cable.\n");
> >>> +
> >>> + while (!usb_cable_connected()) {
> >>> + if (ctrlc()) {
> >>> + puts("\rCTRL+C - Operation aborted.\n");
> >>> + goto exit;
> >>> + }
> >>> + if (!cable_ready_timeout) {
> >>> + puts("\rUSB cable not detected.\n" \
> >>> + "Command exit.\n");
> >>> + goto exit;
> >>> + }
> >>> +
> >>> + printf("\rAuto exit in: %.2d s.", cable_ready_timeout);
> >>> + mdelay(1000);
> >>> + cable_ready_timeout--;
> >>> + }
> >>> + puts("\r\n");
> >>> + }
> >>> +
> >>>
> >>> while (1) {
> >>>
> >>> usb_gadget_handle_interrupts();
> >>>
> >>> diff --git a/include/usb_mass_storage.h b/include/usb_mass_storage.h
> >>> index 9df3adc..058dcf1 100644
> >>> --- a/include/usb_mass_storage.h
> >>> +++ b/include/usb_mass_storage.h
> >>> @@ -20,6 +20,9 @@
> >>>
> >>>#define UMS_NUM_SECTORS0
> >>>#endif
> >>>
> >>> +/* Wait at maximum 60 seconds for cable connection */
> >>> +#define UMS_CABLE_READY_TIMEOUT 60
> >>> +
> >>>
> >>>struct ums {
> >>>
> >>> int (*read_sector)(struct ums *ums_dev,
> >>>
> >>> ulong start, lbaint_t blkcnt, void *buf);
> >>
> >> I was send some very useful fix to the ums. It is required for users who
> >> are using the same usb port for USB and UART purposes. Without this fix
> >> such users just can't use ums because it will always exit to prompt when
> >> user change the cable.
> >
> > Can you please share the schematic of such a cable in public?
>
> Unfortunately I am not allowed to share such information.
Is the trats2 so similar to galaxy SIII or what ? :)
> > How does this
> > "sharing" of USB and UART work? I am very curious here :-)
>
> Regarding the USB sharing explanation - please refer to FSA9480 data
> sheet. It is available on the Internet.
Thanks.
> I can also recommend looking into newest kernel code support for Trats2
> device.
Yes, this is helpful, thanks!
> >> So I have few questions...
> >> Marek, could you review this patch?
> >
> > On it!
> >
> >> And what about the release, are you going to send pull request before
> >> the release?
> >> If not, then is it possible to apply this patch directly to
> >> u-boot/master by Tom Rini?
> >
> > PR will happen once I am through the load of patches in my mailbox.
>
> Thank you for patch apply.
>
> Regards,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ext4fs: use EXT2_BLOCK_SIZE instead of fs->blksz
Using fs->blksz in ext4fs_get_extent_block() is not
correct since fs->blksz is not initialized on the
read path. Use EXT2_BLOCK_SIZE() instead which will
produce the desired output.
Signed-off-by: Ionut Nicu
Signed-off-by: Mathias Rulf
---
fs/ext4/ext4_common.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 352943e..37b6c46 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -1414,7 +1414,7 @@ static struct ext4_extent_header *ext4fs_get_extent_block
{
struct ext4_extent_idx *index;
unsigned long long block;
- struct ext_filesystem *fs = get_fs();
+ int blksz = EXT2_BLOCK_SIZE(data);
int i;
while (1) {
@@ -1438,7 +1438,7 @@ static struct ext4_extent_header *ext4fs_get_extent_block
block = le16_to_cpu(index[i].ei_leaf_hi);
block = (block << 32) + le32_to_cpu(index[i].ei_leaf_lo);
- if (ext4fs_devread((lbaint_t)block << log2_blksz, 0, fs->blksz,
+ if (ext4fs_devread((lbaint_t)block << log2_blksz, 0, blksz,
buf))
ext_block = (struct ext4_extent_header *)buf;
else
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Prefetch abort exception
Hello, I have added interrupt support for armv7 platform, by implementing the do_irq and irq_install_handler and arch_interrupt_init functions. Initially default_isr is the handler function installed for all the interrupts. >From my standalone application, I am enabling the interrupts and installing the handler to be called for my peripheral interrupt. If I don't install my handler, U-Boot executes default_isr successfully. If I use my handler, when the interrupt occurs I am getting the prefetch abort exception with the following dump prefetch abort pc : [] lr : [] sp : bfeef200 ip : bfeef358 fp : bfef1d48 r10: bfef1d78 r9 : 0002 r8 : bfeeff58 r7 : bffac284 r6 : 6153 r5 : bffbb5c0 r4 : r3 : bffab29c r2 : r1 : 03e8 r0 : 8500178c Flags: nZCv IRQs off FIQs off Mode IRQ_32 Resetting CPU ... resetting ... U-Boot SPL 2013.01.-rc1-3-g43ee87a-dirty (Jan 10 2014 - 16:04:35) OMAP4460 ES1.1 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img Can any one please help me to solve this? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ext4fs: fix "invalid extent block" error
For files where we actually have extent indexes following an extent header (ext_block->eh_depth != 0), the do/while loop from ext4fs_get_extent_block() does not select the proper extent index structure. For example, if we have: ext_block->eh_depth = 1 ext_block->eh_entries = 1 fileblock = 0 index[0].ei_block = 0 the do/while loop will exit with i set to 0 and the ext4fs_get_extent_block() function will return 0, even if there was a valid extent index structure following the header. Signed-off-by: Ionut Nicu Signed-off-by: Mathias Rulf --- fs/ext4/ext4_common.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c index 37b6c46..e543478 100644 --- a/fs/ext4/ext4_common.c +++ b/fs/ext4/ext4_common.c @@ -1430,7 +1430,7 @@ static struct ext4_extent_header *ext4fs_get_extent_block i++; if (i >= le16_to_cpu(ext_block->eh_entries)) break; - } while (fileblock > le32_to_cpu(index[i].ei_block)); + } while (fileblock >= le32_to_cpu(index[i].ei_block)); if (--i < 0) return 0; -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [OT] CC:s in commits (was: [PATCH 1/2] socfpga: Adding Scan Manager driver)
Dear Albert, On Mon, 2014-01-13 at 09:34 +0100, ZY - albert.u.boot wrote: > On Wed, 13 Nov 2013 11:34:10 -0600, Chin Liang See > wrote: > > > Scan Manager driver will be called to configure the IOCSR > > scan chain. This configuration will setup the IO buffer settings > > > > Signed-off-by: Chin Liang See > > Cc: Dinh Nguyen > > Cc: Wolfgang Denk > > CC: Pavel Machek > > Cc: Tom Rini > > Cc: Albert Aribaud > > --- > > Not sure what the point is of these CC:s in the commit message. Do I > miss some use of these? Can I, should I, should I not remove them > from the commit when applying to my tree? > Actually these Cc will be helpful when using git send-email. It will auto cc to these mailing list when the patch is send out for review (instead entering the names manually every time). Thanks Chin Liang > Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] ums: always initialize mmc before ums_disk_init()
On 01/10/14 06:08, Jaehoon Chung wrote:
>> index dc155ad..0d8f30d 100644
>> --- a/board/samsung/common/ums.c
>> +++ b/board/samsung/common/ums.c
>> @@ -37,6 +37,9 @@ static struct ums ums_dev = {
>>
>> static struct ums *ums_disk_init(struct mmc *mmc)
>> {
>> +if (mmc_init(mmc))
>> +return NULL;
>> +
>> uint64_t mmc_end_sector = mmc->capacity / SECTOR_SIZE;
>> uint64_t ums_end_sector = UMS_NUM_SECTORS + UMS_START_SECTOR;
>
> --> if (mmc_init(mmc))
> return NULL;
>
> Locate this point.
If you're asking to put this if() block after variable declaration, NAK.
It's perfectly fine C99 code. I'm not aware of any existing U-Boot style
guidelines that would forbid me to leave it this way.
These variables are only meaningful when mmc_init() returns a valid pointer.
Regards,
--
Mateusz Zalega
Samsung R&D Institute Poland
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] ums: always initialize mmc before ums_disk_init()
Hi
On Mon, Jan 13, 2014 at 3:39 PM, Mateusz Zalega wrote:
> On 01/10/14 06:08, Jaehoon Chung wrote:
>>> index dc155ad..0d8f30d 100644
>>> --- a/board/samsung/common/ums.c
>>> +++ b/board/samsung/common/ums.c
>>> @@ -37,6 +37,9 @@ static struct ums ums_dev = {
>>>
>>> static struct ums *ums_disk_init(struct mmc *mmc)
>>> {
>>> +if (mmc_init(mmc))
>>> +return NULL;
>>> +
>>> uint64_t mmc_end_sector = mmc->capacity / SECTOR_SIZE;
>>> uint64_t ums_end_sector = UMS_NUM_SECTORS + UMS_START_SECTOR;
>>
>> --> if (mmc_init(mmc))
>> return NULL;
>>
>> Locate this point.
>
> If you're asking to put this if() block after variable declaration, NAK.
>
I don't understand your point
> It's perfectly fine C99 code. I'm not aware of any existing U-Boot style
> guidelines that would forbid me to leave it this way.
>
> These variables are only meaningful when mmc_init() returns a valid pointer.
>
http://www.denx.de/wiki/U-Boot/CodingStyle
Michael
> Regards,
> --
> Mateusz Zalega
> Samsung R&D Institute Poland
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] arm:goni:dfu Add support for DFU to Goni target
On 01/10/14 05:55, Jaehoon Chung wrote:
> On 01/09/2014 11:31 PM, Mateusz Zalega wrote:
>> Proper adjustment for supporting DFU at GONI target has been made.
>> The s5p_goni.h file has been updated. Moreover, the code for low level
>> USB initialization has been added to Goni board code.
>>
>> The malloc pool has been enlarged in order to support larger buffer
>> sizes needed by DFU implementation.
>>
>> Change-Id: I7812f395a3ee3660cec31f4d8c954057c0149863
>> Signed-off-by: Arkadiusz Wlodarczyk
>> Signed-off-by: Kyungmin Park
>> Signed-off-by: Mateusz Zalega
>> Tested-by: Arkadiusz Wlodarczyk
>> Tested-by: Mateusz Zalega
>> Cc: Minkyu Kang
>> ---
>> board/samsung/goni/goni.c | 10 +
>> include/configs/s5p_goni.h | 54
>> --
>> 2 files changed, 53 insertions(+), 11 deletions(-)
>>
>> diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c
>> index 366f648..5498daa 100644
>> --- a/board/samsung/goni/goni.c
>> +++ b/board/samsung/goni/goni.c
>> @@ -13,6 +13,9 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> +
>> DECLARE_GLOBAL_DATA_PTR;
>>
>> static struct s5pc110_gpio *s5pc110_gpio;
>> @@ -172,4 +175,11 @@ struct s3c_plat_otg_data s5pc110_otg_data = {
>> .regs_otg = S5PC110_OTG_BASE,
>> .usb_phy_ctrl = S5PC110_USB_PHY_CONTROL,
>> };
>> +
>> +int board_usb_init(int index, enum usb_init_type init)
>> +{
>> +debug("USB_udc_probe\n");
>> +s3c_udc_probe(&s5pc110_otg_data);
>> +return 0;
> Always return 0? return s3c_udc_probe(&s5pc110_otg_data);
ACK, will fix.
>> +}
>> #endif
>> diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
>> index 1d2dcc0..24a0fcc 100644
>> --- a/include/configs/s5p_goni.h
>> +++ b/include/configs/s5p_goni.h
>> @@ -39,7 +39,7 @@
>> #define CONFIG_CMDLINE_EDITING
>>
>> /* Size of malloc() pool.*/
>> -#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + SZ_1M)
>> +#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 80 * SZ_1M)
>>
>> /*
>> * select serial console configuration
>> @@ -70,14 +70,18 @@
>> #define CONFIG_CMD_CACHE
>> #define CONFIG_CMD_REGINFO
>> #define CONFIG_CMD_ONENAND
>> -#define CONFIG_CMD_MTDPARTS
>> #define CONFIG_CMD_MMC
>> +#define CONFIG_CMD_DFU
>>
>> -#define CONFIG_BOOTDELAY1
>> -#define CONFIG_ZERO_BOOTDELAY_CHECK
>> +/* USB Composite download gadget - g_dnl */
>> +#define CONFIG_USBDOWNLOAD_GADGET
>> +#define CONFIG_DFU_FUNCTION
>> +#define CONFIG_DFU_MMC
>>
>> -#define CONFIG_MTD_DEVICE
>> -#define CONFIG_MTD_PARTITIONS
>> +/* USB Samsung's IDs */
>> +#define CONFIG_G_DNL_VENDOR_NUM 0x04E8
>> +#define CONFIG_G_DNL_PRODUCT_NUM 0x6601
>> +#define CONFIG_G_DNL_MANUFACTURER "Samsung"
>>
>> /* Actual modem binary size is 16MiB. Add 2MiB for bad block handling */
>> #define MTDIDS_DEFAULT "onenand0=samsung-onenand"
>> @@ -90,7 +94,34 @@
>> ",12m(modem)"\
>> ",60m(qboot)\0"
>>
>> -#define NORMAL_MTDPARTS_DEFAULT MTDPARTS_DEFAULT
>> +#define CONFIG_BOOTDELAY1
>> +#define CONFIG_ZERO_BOOTDELAY_CHECK
>> +
>> +/* partitions definitions */
>> +#define PARTS_CSA "csa-mmc"
>> +#define PARTS_BOOTLOADER"u-boot"
>> +#define PARTS_BOOT "boot"
>> +#define PARTS_ROOT "platform"
>> +#define PARTS_DATA "data"
>> +#define PARTS_CSC "csc"
>> +#define PARTS_UMS "ums"
>> +
>> +#define CONFIG_DFU_ALT \
>> +"u-boot raw 0x80 0x400;" \
>> +"uImage ext4 0 2;" \
>> +"exynos3-goni.dtb ext4 0 2;" \
> exynos3-goni.dtb?
Correct. It's a DFU entry for the relevant devicetree blob.
(...)
Regards,
--
Mateusz Zalega
Samsung R&D Institute Poland
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] ums: always initialize mmc before ums_disk_init()
On 01/13/14 15:43, Michael Trimarchi wrote:
> On Mon, Jan 13, 2014 at 3:39 PM, Mateusz Zalega wrote:
>> On 01/10/14 06:08, Jaehoon Chung wrote:
index dc155ad..0d8f30d 100644
--- a/board/samsung/common/ums.c
+++ b/board/samsung/common/ums.c
@@ -37,6 +37,9 @@ static struct ums ums_dev = {
static struct ums *ums_disk_init(struct mmc *mmc)
{
+if (mmc_init(mmc))
+return NULL;
+
uint64_t mmc_end_sector = mmc->capacity / SECTOR_SIZE;
uint64_t ums_end_sector = UMS_NUM_SECTORS + UMS_START_SECTOR;
>>>
>>> --> if (mmc_init(mmc))
>>> return NULL;
>>>
>>> Locate this point.
>>
>> If you're asking to put this if() block after variable declaration, NAK.
>>
>
> I don't understand your point
>
>> It's perfectly fine C99 code. I'm not aware of any existing U-Boot style
>> guidelines that would forbid me to leave it this way.
>>
>> These variables are only meaningful when mmc_init() returns a valid pointer.
>>
>
> http://www.denx.de/wiki/U-Boot/CodingStyle
>
> Michael
touché
OK, I'll move declarations to the beginning of the closure, C89 style.
Thanks,
--
Mateusz Zalega
Samsung R&D Institute Poland
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBIFS seeing corrupt blank pages when image flashed via u-boot
On Mon, 2014-01-13 at 13:16 +, Gupta, Pekon wrote: > Currently both UBI and UBIFS layer checks for erased-page to be > all(0xff), > But I think its over-kill to put this burden on UBI or UBIFS layer, > because > low-level controller drivers can handle this easily. > So, if Artem and Brian agree to above approaches, then I can a submit > patch > for removal of: > - "ubi_self_check_all_ff()" from UBI layer. Well, this is just debugging and sanity check stuff. > - checking of 'buf == 0xff' from ubifs_scan_leb() in UBIFS layer. I do not think this is a good idea. Let me do some quick braindump, thankfully I still remember the reasons behind this. > This is about the recovery, and this is the code path where we actually do these checks. Just like in defensive programming you try to assume the worst, we tried to assume the worst too. And the worst is - you cannot make any assumption about what is on the media. Now, we wanted to make UBIFS robust in a sense that you can cut the power off at any point, and you can be sure the UBIFS driver is still able to mount your flash. You can lose some data because it did not make it to the media yet by the time of power cut. But you never lose the data which made it to the media before the power cut. And the file-system should mount the media without any user-space tools like 'ckfs.ubifs'. The system should recover itself (detect half-written garbage and get rid of it, preparing "clean" blank flash area for writing new data). When you mount a file-system, UBIFS scans the journal. Suppose it hits a corrupted data node. At this point UBIFS need to make a decision whether this is a node which was corrupted because of a power cut, or this is a piece of data which has to be correct, but got corrupted because of, say, under-voltage problems, or NAND wear, or radiation, etc. In the first case - you recover silently, and you do not bother the user with warnings. In the second case - you report loudly. You do not do anything because you risk of losing important user data (an expensive bitcoin!) Right? So you gotta be very careful, because this is user data. To put it differently, we specifically targeted a special type of corruptions - power-cut related corruptions. We made related assumptions. And we were very careful about validating these assumptions. So UBIFS always starts with fully erased LEBs. Then it writes there sequentially, NAND page-by-page, from beginning to the end. (Well, it is a bit more complex than that, but this is not important in this discussion. The complexity is that there are several journal heads, so UBIFS writes to more than one LEBs, but it is sequetial anyway. Also, we write in so-called "max. write units", which are usually the same as NAND page in case of NAND anyway). When UBIFS mounts a file-system, it scans the journal. When it meets a corrupted node in NAND page X, it looks at NAND page X+1 and checks if it is blank or not. If it is blank, this looks normal, and X was just the NAND page UBIFS presumably was writing to just before the power cut. If NAND page X+1 contains something, then page X cannot be corrupted due to power cut, and this is something else. And we, the FS authors, do not know how to deal with this, we did not think about this type of corruptions. So just we complain and exit. This is better then trying to erase something and make you lose your data, right? That's the logic. And of course people are welcome to extend it and improve it. Conclusion: all UBIFS needs is a way to ask the driver - is this NAND page blank or not? UBIFS does not really has to compare to all 0xFFs. -- Best Regards, Artem Bityutskiy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/9] Further support for the kmp204x architecture
This patch series refines the support for the kmp204x designs. The main additions are: - further support of the QRIO CPLD (bootcounter and GPIO) - support of the new kmcoge4 board based on kmp204x - support of I2C deblocking - support for FPGA configuration (PCIe FPGA) - various fixes and smaller enhancements Rainer Boschung (2): kmp204x: support for QRIO1 bootcounter kmp204x: I2C deblocking for I2C-bus1 added Valentin Longchamp (7): kmp204x: introduce QRIO GPIO functions kmp204x: implement workaround for A-006559 kmp204x: add support for the kmcoge4 board kmp204x: update I2C field of RCW KM: add the KM_UBI_PART_BOOT_OPTS #define kmp204x: enable support for SPANSION SPI NOR kmp204x: initial support for PCIe FPGA configuration board/keymile/kmp204x/Makefile| 2 +- board/keymile/kmp204x/kmp204x.c | 124 ++-- board/keymile/kmp204x/kmp204x.h | 10 +++ board/keymile/kmp204x/pbi.cfg | 10 +++ board/keymile/kmp204x/pci.c | 85 board/keymile/kmp204x/qrio.c | 147 ++ board/keymile/kmp204x/rcw_kmp204x.cfg | 2 +- boards.cfg| 1 + include/configs/km/keymile-common.h | 10 ++- include/configs/km/kmp204x-common.h | 15 include/configs/kmp204x.h | 7 +- 11 files changed, 345 insertions(+), 68 deletions(-) create mode 100644 board/keymile/kmp204x/qrio.c -- 1.8.0.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/9] kmp204x: update I2C field of RCW
On the previous HW revision (now unsupported), there was a need for
external DMA signals and thus the I2C3/4 signals were used
DMA1_DONE/ACK/REQ.
These signals now are configured as GPIO[16:19].
Signed-off-by: Valentin Longchamp
---
board/keymile/kmp204x/rcw_kmp204x.cfg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/keymile/kmp204x/rcw_kmp204x.cfg
b/board/keymile/kmp204x/rcw_kmp204x.cfg
index f2b7fe3..2d4c48c 100644
--- a/board/keymile/kmp204x/rcw_kmp204x.cfg
+++ b/board/keymile/kmp204x/rcw_kmp204x.cfg
@@ -7,5 +7,5 @@ aa55aa55 010e0100
#64 bytes RCW data
1460 2820
148E70CF CFC02000 5800 4100
- F4428002
+ F0428002
--
1.8.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/9] kmp204x: support for QRIO1 bootcounter
From: Rainer Boschung
- make use of the QRIO1 32bit register at 0x20 as bootcounter register
- check for BOOTCOUNT_MAGIC pattern when before bootcounter value is read
Signed-off-by: Rainer Boschung
Signed-off-by: Valentin Longchamp
Acked-by: Valentin Longchamp
---
board/keymile/kmp204x/kmp204x.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/board/keymile/kmp204x/kmp204x.c b/board/keymile/kmp204x/kmp204x.c
index f02642a..b41929a 100644
--- a/board/keymile/kmp204x/kmp204x.c
+++ b/board/keymile/kmp204x/kmp204x.c
@@ -134,22 +134,25 @@ void qrio_prstcfg(u8 bit, u8 mode)
}
-#define BOOTCOUNT_OFF 0x12
+#define BOOTCOUNT_OFF 0x20
void bootcount_store(ulong counter)
{
- u8 val;
void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
- val = (counter <= 255) ? (u8)counter : 255;
- out_8(qrio_base + BOOTCOUNT_OFF, val);
+ out_be32(qrio_base + BOOTCOUNT_OFF, counter);
}
ulong bootcount_load(void)
{
- u8 val;
+ u32 val;
void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
- val = in_8(qrio_base + BOOTCOUNT_OFF);
+ val = in_be32(qrio_base + BOOTCOUNT_OFF + 4);
+
+ if (val == BOOTCOUNT_MAGIC)
+ val = in_be32(qrio_base + BOOTCOUNT_OFF);
+ else
+ val = 0;
return val;
}
--
1.8.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/9] kmp204x: enable support for SPANSION SPI NOR
The new prototype and the final series was moved from Micron to Spansion to have a better reset sequence that is easier to support. Signed-off-by: Valentin Longchamp --- include/configs/km/kmp204x-common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/km/kmp204x-common.h b/include/configs/km/kmp204x-common.h index 935aa7e..f0e7d15 100644 --- a/include/configs/km/kmp204x-common.h +++ b/include/configs/km/kmp204x-common.h @@ -301,6 +301,7 @@ int get_scl(void); #define CONFIG_SPI_FLASH #define CONFIG_SPI_FLASH_BAR /* 4 byte-addressing */ #define CONFIG_SPI_FLASH_STMICRO +#define CONFIG_SPI_FLASH_SPANSION #define CONFIG_CMD_SF #define CONFIG_SF_DEFAULT_SPEED 2000 #define CONFIG_SF_DEFAULT_MODE 0 -- 1.8.0.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/9] KM: add the KM_UBI_PART_BOOT_OPTS #define
This define can be used if the ubi boot partition (defined for all
Keymile boards with KM_UBI_PARTITION_NAME_BOOT #define to ubi0) needs
some additionnal boot options.
This is the case for the kmp204x boards since u-boot does not support
NAND Flash subpage accesses on this platform, an additionnal argument
that defines the VID offstet must be given to the kernel.
The UBI cmd line option now looks like this "ubi.mtd=ubi0,2048" on this
platform.
Signed-off-by: Valentin Longchamp
---
include/configs/km/keymile-common.h | 10 --
include/configs/km/kmp204x-common.h | 4
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/configs/km/keymile-common.h
b/include/configs/km/keymile-common.h
index 2a15ad4..a4e0f7c 100644
--- a/include/configs/km/keymile-common.h
+++ b/include/configs/km/keymile-common.h
@@ -99,11 +99,16 @@
#define CONFIG_KM_UBI_PARTITION_NAME_BOOT "ubi0"
#endif /* CONFIG_KM_UBI_PARTITION_NAME_BOOT */
+#ifndef CONFIG_KM_UBI_PART_BOOT_OPTS
+#define CONFIG_KM_UBI_PART_BOOT_OPTS ""
+#endif /* CONFIG_KM_UBI_PART_BOOT_OPTS */
+
#ifndef CONFIG_KM_UBI_PARTITION_NAME_APP
/* one flash chip only called boot */
/* boot: CONFIG_KM_UBI_PARTITION_NAME_BOOT */
# define CONFIG_KM_UBI_LINUX_MTD \
- "ubi.mtd=" CONFIG_KM_UBI_PARTITION_NAME_BOOT
+ "ubi.mtd=" CONFIG_KM_UBI_PARTITION_NAME_BOOT\
+ CONFIG_KM_UBI_PART_BOOT_OPTS
# define CONFIG_KM_DEV_ENV_FLASH_BOOT_UBI \
"ubiattach=ubi part " CONFIG_KM_UBI_PARTITION_NAME_BOOT "\0"
#else /* CONFIG_KM_UBI_PARTITION_NAME_APP */
@@ -111,7 +116,8 @@
/* boot: CONFIG_KM_UBI_PARTITION_NAME_BOOT */
/* app: CONFIG_KM_UBI_PARTITION_NAME_APP */
# define CONFIG_KM_UBI_LINUX_MTD \
- "ubi.mtd=" CONFIG_KM_UBI_PARTITION_NAME_BOOT " "\
+ "ubi.mtd=" CONFIG_KM_UBI_PARTITION_NAME_BOOT\
+ CONFIG_KM_UBI_PART_BOOT_OPTS " "\
"ubi.mtd=" CONFIG_KM_UBI_PARTITION_NAME_APP
# define CONFIG_KM_DEV_ENV_FLASH_BOOT_UBI \
"ubiattach=if test ${boot_bank} -eq 0; then; " \
diff --git a/include/configs/km/kmp204x-common.h
b/include/configs/km/kmp204x-common.h
index b4242e5..935aa7e 100644
--- a/include/configs/km/kmp204x-common.h
+++ b/include/configs/km/kmp204x-common.h
@@ -15,6 +15,10 @@
#define CONFIG_KM_DEF_NETDEV "netdev=eth0\0"
+/* an additionnal option is required for UBI as subpage access is
+ * supported in u-boot */
+#define CONFIG_KM_UBI_PART_BOOT_OPTS ",2048"
+
#define CONFIG_NAND_ECC_BCH
/* common KM defines */
--
1.8.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 9/9] kmp204x: initial support for PCIe FPGA configuration
The PEXHC PCIe configuration mechanism ensures that the FPGA get
configured at power-up. Since all the PCIe devices should be configured
when the kernel start, u-boot has to take care that the FPGA gets
configured also in other reset scenarios, mostly because of possible
configuration change.
The used mechanism is taken from the km_kirkwood design and adapted to
the kmp204x case (slightly different HW and PCIe configuration).
Signed-off-by: Valentin Longchamp
---
board/keymile/kmp204x/kmp204x.c | 7 +++-
board/keymile/kmp204x/pci.c | 85 +
2 files changed, 91 insertions(+), 1 deletion(-)
diff --git a/board/keymile/kmp204x/kmp204x.c b/board/keymile/kmp204x/kmp204x.c
index 141d7ee..4814efb 100644
--- a/board/keymile/kmp204x/kmp204x.c
+++ b/board/keymile/kmp204x/kmp204x.c
@@ -101,6 +101,7 @@ int board_early_init_f(void)
int board_early_init_r(void)
{
+ int ret = 0;
/* Flush d-cache and invalidate i-cache of any FLASH data */
flush_dcache();
invalidate_icache();
@@ -108,7 +109,11 @@ int board_early_init_r(void)
set_liodns();
setup_portals();
- return 0;
+ ret = trigger_fpga_config();
+ if (ret)
+ printf("error triggering PCIe FPGA config\n");
+
+ return ret;
}
unsigned long get_board_sys_clk(unsigned long dummy)
diff --git a/board/keymile/kmp204x/pci.c b/board/keymile/kmp204x/pci.c
index ec20c8a..a484eb5 100644
--- a/board/keymile/kmp204x/pci.c
+++ b/board/keymile/kmp204x/pci.c
@@ -14,18 +14,103 @@
#include
#include
#include
+#include
#include "kmp204x.h"
+#define PROM_SEL_L 11
+/* control the PROM_SEL_L signal*/
+static void toggle_fpga_eeprom_bus(bool cpu_own)
+{
+ qrio_gpio_direction_output(GPIO_A, PROM_SEL_L, !cpu_own);
+}
+
+#define CONF_SEL_L 10
+#define FPGA_PROG_L19
+#define FPGA_DONE 18
+#define FPGA_INIT_L17
+
+int trigger_fpga_config(void)
+{
+ int ret = 0, init_l;
+ /* approx 10ms */
+ u32 timeout = 1;
+
+ /* make sure the FPGA_can access the EEPROM */
+ toggle_fpga_eeprom_bus(false);
+
+ /* assert CONF_SEL_L to be able to drive FPGA_PROG_L */
+ qrio_gpio_direction_output(GPIO_A, CONF_SEL_L, 0);
+
+ /* trigger the config start */
+ qrio_gpio_direction_output(GPIO_A, FPGA_PROG_L, 0);
+
+ /* small delay for INIT_L line */
+ udelay(10);
+
+ /* wait for FPGA_INIT to be asserted */
+ do {
+ init_l = qrio_get_gpio(GPIO_A, FPGA_INIT_L);
+ if (timeout-- == 0) {
+ printf("FPGA_INIT timeout\n");
+ ret = -EFAULT;
+ break;
+ }
+ udelay(10);
+ } while (init_l);
+
+ /* deassert FPGA_PROG, config should start */
+ qrio_set_gpio(GPIO_A, FPGA_PROG_L, 1);
+
+ return ret;
+}
+
+/* poll the FPGA_DONE signal and give the EEPROM back to the QorIQ */
+static int wait_for_fpga_config(void)
+{
+ int ret = 0, done;
+ /* approx 5 s */
+ u32 timeout = 50;
+
+ printf("PCIe FPGA config:");
+ do {
+ done = qrio_get_gpio(GPIO_A, FPGA_DONE);
+ if (timeout-- == 0) {
+ printf(" FPGA_DONE timeout\n");
+ ret = -EFAULT;
+ goto err_out;
+ }
+ udelay(10);
+ } while (!done);
+
+ printf(" done\n");
+
+err_out:
+ /* deactive CONF_SEL and give the CPU conf EEPROM access */
+ qrio_set_gpio(GPIO_A, CONF_SEL_L, 1);
+ toggle_fpga_eeprom_bus(true);
+
+ return ret;
+}
+
#define PCIE_SW_RST14
+#define PEXHC_SW_RST 13
#define HOOPER_SW_RST 12
void pci_init_board(void)
{
+ /* first wait for the PCIe FPGA to be configured
+* it has been triggered earlier in board_early_init_r */
+ int ret = wait_for_fpga_config();
+ if (ret)
+ printf("error finishing PCIe FPGA config\n");
+
qrio_prst(PCIE_SW_RST, false, false);
+ qrio_prst(PEXHC_SW_RST, false, false);
qrio_prst(HOOPER_SW_RST, false, false);
/* Hooper is not direcly PCIe capable */
mdelay(50);
+
fsl_pcie_init_board(0);
}
--
1.8.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/9] kmp204x: I2C deblocking for I2C-bus1 added
From: Rainer Boschung
-uses common deblocking algorithm from ../common/common.c
-supports deblocking of of I2C-bus1 by means of QRIO GPIO
- SCL1 = GPIO_A16
- SDA1 = GPIO_A17
QRIO GPIOs act in an open-drain-like manner, for 0 GPIO drives
low and for 1 the GPIO is an input and must be pulled up externaly!
Signed-off-by: Rainer Boschung
Signed-off-by: Valentin Longchamp
Acked-by: Valentin Longchamp
---
board/keymile/kmp204x/kmp204x.c | 53 ++---
include/configs/km/kmp204x-common.h | 10 +++
2 files changed, 60 insertions(+), 3 deletions(-)
diff --git a/board/keymile/kmp204x/kmp204x.c b/board/keymile/kmp204x/kmp204x.c
index dae5378..141d7ee 100644
--- a/board/keymile/kmp204x/kmp204x.c
+++ b/board/keymile/kmp204x/kmp204x.c
@@ -33,12 +33,51 @@ int checkboard(void)
return 0;
}
-/* TODO: implement the I2C deblocking function */
-int i2c_make_abort(void)
+/* I2C deblocking uses the algorithm defined in ../common/common.c, which
+ * makes use of 2 QRIO GPIOs to act on the SCL and SDA signals of an I2C bus.
+ * According to the standard I2C IOs must not drive HI-Levels, so the
+ * QRIO GPIOs are used in open-drain fashion:
+ * -> 0 GPIO configured as output that drives low
+ * -> 1 GPIO configured as input pull-up ties high
+ */
+
+/* GPIOs used for deblocking I2C bus 1 */
+#define DBLK_PORT1 GPIO_A
+#define DBLK_SCL1 16
+#define DBLK_SDA1 17
+
+/* By default deblock GPIOs are floating */
+static void i2c_deblock_gpio_cfg(void)
+{
+ /* set I2C bus 1 deblocking GPIOs input, but 0 value for open drain */
+ qrio_gpio_direction_input(DBLK_PORT1, DBLK_SCL1);
+ qrio_gpio_direction_input(DBLK_PORT1, DBLK_SDA1);
+
+ qrio_set_gpio(DBLK_PORT1, DBLK_SCL1, 0);
+ qrio_set_gpio(DBLK_PORT1, DBLK_SDA1, 0);
+}
+
+void set_sda(int state)
+{
+ qrio_set_opendrain_gpio(DBLK_PORT1, DBLK_SDA1, state);
+}
+
+void set_scl(int state)
+{
+ qrio_set_opendrain_gpio(DBLK_PORT1, DBLK_SCL1, state);
+}
+
+int get_sda(void)
+{
+ return qrio_get_gpio(DBLK_PORT1, DBLK_SDA1);
+}
+
+int get_scl(void)
{
- return 1;
+ return qrio_get_gpio(DBLK_PORT1, DBLK_SCL1);
}
+
#define ZL30158_RST8
#define ZL30343_RST9
@@ -77,6 +116,14 @@ unsigned long get_board_sys_clk(unsigned long dummy)
return ;
}
+int misc_init_f(void)
+{
+ /* configure QRIO pis for i2c deblocking */
+ i2c_deblock_gpio_cfg();
+
+ return 0;
+}
+
#define BOOTCOUNT_OFF 0x20
void bootcount_store(ulong counter)
diff --git a/include/configs/km/kmp204x-common.h
b/include/configs/km/kmp204x-common.h
index 50330cc..b4242e5 100644
--- a/include/configs/km/kmp204x-common.h
+++ b/include/configs/km/kmp204x-common.h
@@ -209,6 +209,7 @@ unsigned long get_board_sys_clk(unsigned long dummy);
#define CONFIG_BOARD_EARLY_INIT_F
#define CONFIG_BOARD_EARLY_INIT_R /* call board_early_init_r function */
+#define CONFIG_MISC_INIT_F
#define CONFIG_MISC_INIT_R
#define CONFIG_LAST_STAGE_INIT
@@ -264,7 +265,10 @@ unsigned long get_board_sys_clk(unsigned long dummy);
#define CONFIG_FIT_VERBOSE /* enable fit_format_{error,warning}() */
/* I2C */
+
#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_INIT_BOARD
+#define CONFIG_SYS_I2C_SPEED 10 /* deblocking */
#define CONFIG_SYS_NUM_I2C_BUSES 3
#define CONFIG_SYS_I2C_MAX_HOPS1
#define CONFIG_SYS_I2C_FSL /* Use FSL I2C driver */
@@ -277,6 +281,12 @@ unsigned long get_board_sys_clk(unsigned long dummy);
{0, {{I2C_MUX_PCA9547, 0x70, 1 } } }, \
{0, {{I2C_MUX_PCA9547, 0x70, 2 } } }, \
}
+#ifndef __ASSEMBLY__
+void set_sda(int state);
+void set_scl(int state);
+int get_sda(void);
+int get_scl(void);
+#endif
#define CONFIG_KM_IVM_BUS 1 /* I2C1 (Mux-Port 1)*/
--
1.8.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/9] kmp204x: introduce QRIO GPIO functions
The QRIO GPIO functions can be of general interest. They are thus added
to a qrio.c and their prototype are available from kmp204x.h. The QRIO
prst function are also included in this file, as well as the functions
required for the I2C deblocking support (open-drain).
Signed-off-by: Valentin Longchamp
---
board/keymile/kmp204x/Makefile | 2 +-
board/keymile/kmp204x/kmp204x.c | 57
board/keymile/kmp204x/kmp204x.h | 10 +++
board/keymile/kmp204x/qrio.c| 147
4 files changed, 158 insertions(+), 58 deletions(-)
create mode 100644 board/keymile/kmp204x/qrio.c
diff --git a/board/keymile/kmp204x/Makefile b/board/keymile/kmp204x/Makefile
index 3e69ee2..c57ca08 100644
--- a/board/keymile/kmp204x/Makefile
+++ b/board/keymile/kmp204x/Makefile
@@ -8,5 +8,5 @@
# SPDX-License-Identifier: GPL-2.0+
#
-obj-y := kmp204x.o ddr.o eth.o tlb.o pci.o law.o \
+obj-y := kmp204x.o ddr.o eth.o tlb.o pci.o law.o qrio.o \
../common/common.o ../common/ivm.o
diff --git a/board/keymile/kmp204x/kmp204x.c b/board/keymile/kmp204x/kmp204x.c
index b41929a..dae5378 100644
--- a/board/keymile/kmp204x/kmp204x.c
+++ b/board/keymile/kmp204x/kmp204x.c
@@ -77,63 +77,6 @@ unsigned long get_board_sys_clk(unsigned long dummy)
return ;
}
-#define WDMASK_OFF 0x16
-
-static void qrio_wdmask(u8 bit, bool wden)
-{
- u16 wdmask;
- void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
-
- wdmask = in_be16(qrio_base + WDMASK_OFF);
-
- if (wden)
- wdmask |= (1 << bit);
- else
- wdmask &= ~(1 << bit);
-
- out_be16(qrio_base + WDMASK_OFF, wdmask);
-}
-
-#define PRST_OFF 0x1a
-
-void qrio_prst(u8 bit, bool en, bool wden)
-{
- u16 prst;
- void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
-
- qrio_wdmask(bit, wden);
-
- prst = in_be16(qrio_base + PRST_OFF);
-
- if (en)
- prst &= ~(1 << bit);
- else
- prst |= (1 << bit);
-
- out_be16(qrio_base + PRST_OFF, prst);
-}
-
-#define PRSTCFG_OFF0x1c
-
-void qrio_prstcfg(u8 bit, u8 mode)
-{
- u32 prstcfg;
- u8 i;
- void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
-
- prstcfg = in_be32(qrio_base + PRSTCFG_OFF);
-
- for (i = 0; i < 2; i++) {
- if (mode & (1<
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+
+#include "../common/common.h"
+#include "kmp204x.h"
+
+/* QRIO GPIO register offsets */
+#define DIRECT_OFF 0x18
+#define GPRT_OFF 0x1c
+
+int qrio_get_gpio(u8 port_off, u8 gpio_nr)
+{
+ u32 gprt;
+
+ void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
+
+ gprt = in_be32(qrio_base + port_off + GPRT_OFF);
+
+ return (gprt >> gpio_nr) & 1U;
+}
+
+void qrio_set_gpio(u8 port_off, u8 gpio_nr, bool value)
+{
+ u32 gprt, mask;
+
+ void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
+
+ mask = 1U << gpio_nr;
+
+ gprt = in_be32(qrio_base + port_off + GPRT_OFF);
+ if (value)
+ gprt |= mask;
+ else
+ gprt &= ~mask;
+
+ out_be32(qrio_base + port_off + GPRT_OFF, gprt);
+}
+
+void qrio_gpio_direction_output(u8 port_off, u8 gpio_nr, bool value)
+{
+ u32 direct, mask;
+
+ void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
+
+ mask = 1U << gpio_nr;
+
+ direct = in_be32(qrio_base + port_off + DIRECT_OFF);
+ direct |= mask;
+ out_be32(qrio_base + port_off + DIRECT_OFF, direct);
+
+ qrio_set_gpio(port_off, gpio_nr, value);
+}
+
+void qrio_gpio_direction_input(u8 port_off, u8 gpio_nr)
+{
+ u32 direct, mask;
+
+ void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
+
+ mask = 1U << gpio_nr;
+
+ direct = in_be32(qrio_base + port_off + DIRECT_OFF);
+ direct &= ~mask;
+ out_be32(qrio_base + port_off + DIRECT_OFF, direct);
+}
+
+void qrio_set_opendrain_gpio(u8 port_off, u8 gpio_nr, u8 val)
+{
+ u32 direct, mask;
+
+ void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
+
+ mask = 1U << gpio_nr;
+
+ direct = in_be32(qrio_base + port_off + DIRECT_OFF);
+ if (val == 0)
+ /* set to output -> GPIO drives low */
+ direct |= mask;
+ else
+ /* set to input -> GPIO floating */
+ direct &= ~mask;
+
+ out_be32(qrio_base + port_off + DIRECT_OFF, direct);
+}
+
+#define WDMASK_OFF 0x16
+
+static void qrio_wdmask(u8 bit, bool wden)
+{
+ u16 wdmask;
+ void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
+
+ wdmask = in_be16(qrio_base + WDMASK_OFF);
+
+ if (wden)
+ wdmask |= (1 << bit);
+ else
+ wdmask &= ~(1 << bit);
+
+ out_be16(qrio_base + WDMASK_OFF, wdmask);
+}
+
+#define PRST_OFF 0x1a
+
+void qrio_prst(u8 bit, bool en, bool wden)
+{
+ u16 prst;
+
[U-Boot] [PATCH 4/9] kmp204x: implement workaround for A-006559
According to the errata, some bits of an undocumented register in the DCSR must be set for every core in order to avoid a possible data or instruction corruption. This is required for the 2.0 revision of the P2041 that should be used as soon as available in our design. Signed-off-by: Valentin Longchamp --- board/keymile/kmp204x/pbi.cfg | 10 ++ 1 file changed, 10 insertions(+) diff --git a/board/keymile/kmp204x/pbi.cfg b/board/keymile/kmp204x/pbi.cfg index f38dcf9..9af8bd5 100644 --- a/board/keymile/kmp204x/pbi.cfg +++ b/board/keymile/kmp204x/pbi.cfg @@ -8,6 +8,16 @@ # #PBI commands +#Workaround for A-006559 needed for rev 2.0 of P2041 silicon +#Freescale's errarta sheet suggests it may be done with PBI +0910 +0914 +0918 81d0 +09021008 f000 +09021028 f000 +09021048 f000 +09021068 f000 +0918 #Initialize CPC1 as 1MB SRAM 0901 00200400 09138000 -- 1.8.0.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/9] kmp204x: add support for the kmcoge4 board
The kmcoge4 board is the product board derived from the kmlion1
prototype. The main difference between the 2 boards is that the kmcoge4
does not configure the Local Bus controller for LCS2.
Signed-off-by: Valentin Longchamp
---
boards.cfg| 1 +
include/configs/kmp204x.h | 7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/boards.cfg b/boards.cfg
index d177f82..4198ccf 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -991,6 +991,7 @@ Active powerpc mpc85xx- gdsys
p1022
Active powerpc mpc85xx- gdsys p1022
controlcenterd_TRAILBLAZER controlcenterd:TRAILBLAZER,SPIFLASH
Dirk Eibach
Active powerpc mpc85xx- gdsys p1022
controlcenterd_TRAILBLAZER_DEVELOP
controlcenterd:TRAILBLAZER,SPIFLASH,DEVELOP
Dirk Eibach
Active powerpc mpc85xx- keymile kmp204x
kmlion1 kmp204x:KMLION1
Valentin Longchamp
+Active powerpc mpc85xx- keymile kmp204x
kmcoge4 kmp204x:KMCOGE4
Valentin Longchamp
Active powerpc mpc85xx- stx stxgp3
stxgp3 -
Dan Malek
Active powerpc mpc85xx- stx stxssa
stxssa stxssa
Dan Malek
Active powerpc mpc85xx- stx stxssa
stxssa_4Mstxssa:STXSSA_4M
Dan Malek
diff --git a/include/configs/kmp204x.h b/include/configs/kmp204x.h
index 4158c8d..8bb3571 100644
--- a/include/configs/kmp204x.h
+++ b/include/configs/kmp204x.h
@@ -13,6 +13,11 @@
#define CONFIG_HOSTNAMEkmlion1
#define CONFIG_KM_BOARD_NAME "kmlion1"
+/* KMCOGE4 */
+#elif defined(CONFIG_KMCOGE4)
+#define CONFIG_HOSTNAMEkmcoge4
+#define CONFIG_KM_BOARD_NAME "kmcoge4"
+
#else
#error ("Board not supported")
#endif
@@ -42,6 +47,7 @@
#define CONFIG_SYS_BR2_PRELIM CONFIG_SYS_LBAPP1_BR_PRELIM
/* Local bus app1 Options */
#define CONFIG_SYS_OR2_PRELIM CONFIG_SYS_LBAPP1_OR_PRELIM
+#endif
/* App2 Local bus */
#define CONFIG_SYS_LBAPP2_BASE 0xE000
@@ -63,6 +69,5 @@
#define CONFIG_SYS_BR3_PRELIM CONFIG_SYS_LBAPP2_BR_PRELIM
/* Local bus app2 Options */
#define CONFIG_SYS_OR3_PRELIM CONFIG_SYS_LBAPP2_OR_PRELIM
-#endif
#endif /* __CONFIG_H */
--
1.8.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [OT] CC:s in commits (was: [PATCH 1/2] socfpga: Adding Scan Manager driver)
Hi Chin, On Mon, 13 Jan 2014 08:34:36 -0600, Chin Liang See wrote: > Dear Albert, > > On Mon, 2014-01-13 at 09:34 +0100, ZY - albert.u.boot wrote: > > On Wed, 13 Nov 2013 11:34:10 -0600, Chin Liang See > > wrote: > > > > > Scan Manager driver will be called to configure the IOCSR > > > scan chain. This configuration will setup the IO buffer settings > > > > > > Signed-off-by: Chin Liang See > > > Cc: Dinh Nguyen > > > Cc: Wolfgang Denk > > > CC: Pavel Machek > > > Cc: Tom Rini > > > Cc: Albert Aribaud > > > --- > > > > Not sure what the point is of these CC:s in the commit message. Do I > > miss some use of these? Can I, should I, should I not remove them > > from the commit when applying to my tree? > > > > Actually these Cc will be helpful when using git send-email. It will > auto cc to these mailing list when the patch is send out for review > (instead entering the names manually every time). Thanks That is useful to the sender, but useless to anyone else. Aren't patman's Series-CC tags fulfilling the same function without cluttering the commit message on the receiving/applying end? > Chin Liang Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-pxa/master
Hi Albert, On Mon, 13 Jan 2014 14:16:22 +0100, Albert ARIBAUD wrote: > Hi Marek, > > On Mon, 13 Jan 2014 12:42:35 +0100, Marek Vasut wrote: > > > Minor fixes, please apply for 2014.01 > > > > The following changes since commit > > 7f673c99c2d8d1aa21996c5b914f06d784b080ca: > > > > > > > > > > Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 > > 10:56:00 > > -0500) > > > > > > are available in the git repository at: > > > > > > git://git.denx.de/u-boot-pxa.git master > > > > for you to fetch changes up to 4efd69250f6118ebd783867b3809001a1886ce9e: > > > > ARM: pxa: Fix OneNAND window access on VPAC270 (2014-01-13 12:39:10 +0100) > > > > > > Marek Vasut (2): > > ARM: pxa: Fix OneNAND SPL builds > > ARM: pxa: Fix OneNAND window access on VPAC270 > > > > arch/arm/cpu/pxa/config.mk | 13 + > > board/vpac270/u-boot-spl.lds | 1 + > > include/configs/vpac270.h| 2 +- > > 3 files changed, 15 insertions(+), 1 deletion(-) > > Tom: please hold the release. I'll send you this plus a bugfix patch in > an hour or so. > > Amicalement, Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Call for participation in the U-Boot Mini Summit 2014
Hi, as already indicated, we are looking forward to our next U-Boot Mini Summit at Embedded Linux Conference Europe 2014 which will take place in Düsseldorf, Germany from October 13 - 15. The call for papers of the main conference is now open[1] and if you want to submit a talk for the main tracks, you should note the deadline of July 11. For our U-Boot Mini Summit, I'd like to get the schedule completed synchronized to the schedule release of the main event, which is August 12. So please submit talk proposals here with at least me on CC. To coordinate the event better, I have setup another wiki page[2] that can and _should_ be edited by the interested parties. Feel free for example to add yourself to the "interested participants" so that we get an idea of how many of the U-Boot developers will be there. Best wishes Detlev [1] http://events.linuxfoundation.org/events/embedded-linux-conference-europe/program/cfp [2] http://www.denx.de/wiki/U-Boot/MiniSummitELCE2014 -- Blaming Snowden for causing problems for the US cloud industry is like blaming Al Gore for the global warming. -- Mikko Hypponen -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [OT] CC:s in commits (was: [PATCH 1/2] socfpga: Adding Scan Manager driver)
Hi Albert, On Mon, 2014-01-13 at 17:39 +0100, ZY - albert.u.boot wrote: > Hi Chin, > > On Mon, 13 Jan 2014 08:34:36 -0600, Chin Liang See > wrote: > > > Dear Albert, > > > > On Mon, 2014-01-13 at 09:34 +0100, ZY - albert.u.boot wrote: > > > On Wed, 13 Nov 2013 11:34:10 -0600, Chin Liang See > > > wrote: > > > > > > > Scan Manager driver will be called to configure the IOCSR > > > > scan chain. This configuration will setup the IO buffer settings > > > > > > > > Signed-off-by: Chin Liang See > > > > Cc: Dinh Nguyen > > > > Cc: Wolfgang Denk > > > > CC: Pavel Machek > > > > Cc: Tom Rini > > > > Cc: Albert Aribaud > > > > --- > > > > > > Not sure what the point is of these CC:s in the commit message. Do I > > > miss some use of these? Can I, should I, should I not remove them > > > from the commit when applying to my tree? > > > > > > > Actually these Cc will be helpful when using git send-email. It will > > auto cc to these mailing list when the patch is send out for review > > (instead entering the names manually every time). Thanks > > That is useful to the sender, but useless to anyone else. > > Aren't patman's Series-CC tags fulfilling the same function without > cluttering the commit message on the receiving/applying end? The patman script looks cool. Let me learn up this and using this when submitting future patches. At same time, sorry for the hassle as I am not aware the git send-email method not helpful for maintainer. For this patch, wonder is it ok for you to manually remove the Ccs? Thanks and appreciate again for your helps. Chin Liang > > > Chin Liang > > Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nand: fix reading after switching ecc
On Mon, 2014-01-13 at 08:29 +, Gupta, Pekon wrote: > Hi Jeroen, > > > > >The omap_gpmc allows switching ecc at runtime. Since > >the NAND_SUBPAGE_READ flag is only set, it is kept when > >switching to hw ecc, which is not correct. This leads to > >calling chip->ecc.read_subpage which is not a valid > >pointer. Therefore also clear the flag so reading in > >hw mode works again. > > > >Cc: Scott Wood > >Cc: Pekon Gupta > >Cc: Nikita Kiryanov > >Signed-off-by: Jeroen Hofstee > >--- > > drivers/mtd/nand/nand_base.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > >diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c > >index 1ce55fd..0762a19 100644 > >--- a/drivers/mtd/nand/nand_base.c > >+++ b/drivers/mtd/nand/nand_base.c > >@@ -3354,6 +3354,8 @@ int nand_scan_tail(struct mtd_info *mtd) > > /* Large page NAND with SOFT_ECC should support subpage reads */ > > if ((chip->ecc.mode == NAND_ECC_SOFT) && (chip->page_shift > 9)) > > chip->options |= NAND_SUBPAGE_READ; > >+else > >+chip->options &= ~NAND_SUBPAGE_READ; NACK; this breaks NAND_SUBPAGE_READ with hardware ECC for drivers that support it. > I don't think it's good to add OMAP specific changes to nand_base.c. > It's better if you can add this as part of omap_select_ecc_scheme() in > omap_gpmc.c Yes, clear it from the OMAP switching code if OMAP can't do subpage reads with hardware ECC. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc:Rename CONFIG_PBLRCW_CONFIG & CONFIG_SYS_FSL_PBL_PBI
On Mon, 2014-01-13 at 14:48 +0100, Wolfgang Denk wrote: > Dear Prabhakar, > > In message <52d37cf5.2090...@freescale.com> you wrote: > > > > > What is the reason for the reenaming? Especially, why changing from > > > CONFIG_ to CONFIG_SYS_ ? > > > > CONFIG_PBLRCW_CONFIG has 2 CONFIG. it is slightly confusing. > > > > Reason for moving CONFIG_ to CONFIG_SYS: These defines enables of > > adding RCW(power on reset configuration) and > > PBI(pre boot loader commands) in u-boot image. These information will be > > used by SoC hardware for NAND, SD, SPI boot. > > As these configuration will be used by SoC hardware. I thought of adding > > CONFIG_SYS. > > CONFIG_ means stuff that can be freely adjusted by the end user to > match his likings, like adding one command and removing another. > CONFIG_SYS_ means stuff that is determined by the hardware > configuration, i. e. that has to be adjusted according to specific > properties to make U-Boot working on some hardware, and which can (or > should) not be "adjusted" by the end user. > > I don;t understand your intentions enough to say which applies here; > IIRC at least PBI might be more of the CONFIG_ type. I think they belong in CONFIG_SYS -- they can be adjusted to some extent if you know what you're doing, but they are not general user knobs. As far as end users are concerned, they should use the PBI/PBL files that match their hardware. The PBI file will mainly contain errata workarounds, and/or hardware initialization necessary for certain types of non-NOR booting (the user knob in the latter case is elsewhere, to tell U-Boot what boot source to target). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-spi/master
Hi Tom, PR have quad and dual_flash change set also includes few fixes. Tested these changes on spansion, stmicro and sst flash devices. -- Thanks, Jagan. The following changes since commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca: Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 10:56:00 -0500) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to 35a55fb57fffb615e6b20980fb317e162076adb4: sf: params: Removed flag SECT_4K for Micron N25Q128 (2014-01-12 21:40:23 +0530) Axel Lin (1): spi: sh_spi: Use sh_spi_clear_bit() instead of open-coded Jagannadha Sutradharudu Teki (17): sf: Add extended read commands support sf: Add quad read/write commands support sf: ops: Add configuration register writing support sf: Set quad enable bit support sf: probe: Enable RD_FULL and WR_QPP sf: Separate the flash params table sf: Add QUAD_IO_FAST read support sf: Discover read dummy_byte sf: Add macronix set QEB support sf: probe: Enable macronix quad read/write cmds support sf: Divide flash register ops from QEB code sf: Code cleanups sf: ops: Unify read_ops bank configuration sf: Add dual memories support - DUAL_STACKED sf: Add dual memories support - DUAL_PARALLEL sf: Add CONFIG_SF_DUAL_FLASH doc: SPI: Update status.txt Kuo-Jung Su (1): spi: Add Faraday SPI controller support Simon Glass (1): sandbox: spi: Adjust 'sf test' to work on sandbox Siva Durga Prasad Paladugu (1): sf: params: Removed flag SECT_4K for Micron N25Q128 README | 6 + common/cmd_sf.c | 14 +- doc/SPI/README.dual-flash| 92 +++ doc/SPI/README.ftssp010_spi_test | 41 doc/SPI/status.txt | 11 +- drivers/mtd/spi/Makefile | 4 +- drivers/mtd/spi/sf.c | 4 + drivers/mtd/spi/sf_internal.h| 34 ++- drivers/mtd/spi/sf_ops.c | 157 +--- drivers/mtd/spi/sf_params.c | 130 ++ drivers/mtd/spi/sf_probe.c | 274 +++-- drivers/spi/Makefile | 1 + drivers/spi/ftssp010_spi.c | 508 +++ drivers/spi/sh_spi.c | 10 +- include/spi.h| 26 ++ include/spi_flash.h | 57 + 16 files changed, 1171 insertions(+), 198 deletions(-) create mode 100644 doc/SPI/README.dual-flash create mode 100644 doc/SPI/README.ftssp010_spi_test create mode 100644 drivers/mtd/spi/sf_params.c create mode 100644 drivers/spi/ftssp010_spi.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sf: params: Removed flag SECT_4K for Micron N25Q128
On Wed, Jan 8, 2014 at 11:27 AM, Siva Durga Prasad Paladugu
wrote:
> Remove the flag SECT_4K for device N25Q128 as the 4K-byte
> sub sector erase granularity is available only for top/bottom
> 8 sectors in some of the N25Q128 chips.
>
> Signed-off-by: Siva Durga Prasad Paladugu
> ---
> drivers/mtd/spi/sf_params.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
> index 4cdb4c2..daf8fe7 100644
> --- a/drivers/mtd/spi/sf_params.c
> +++ b/drivers/mtd/spi/sf_params.c
> @@ -73,8 +73,8 @@ const struct spi_flash_params spi_flash_params_table[] = {
> {"N25Q32A",0x20bb16, 0x0, 64 * 1024,64, RD_FULL,
> WR_QPP | SECT_4K},
> {"N25Q64", 0x20ba17, 0x0, 64 * 1024, 128, RD_FULL,
> WR_QPP | SECT_4K},
> {"N25Q64A",0x20bb17, 0x0, 64 * 1024, 128, RD_FULL,
> WR_QPP | SECT_4K},
> - {"N25Q128",0x20ba18, 0x0, 64 * 1024, 256, RD_FULL,
> WR_QPP | SECT_4K},
> - {"N25Q128A", 0x20bb18, 0x0, 64 * 1024, 256, RD_FULL,
> WR_QPP | SECT_4K},
> + {"N25Q128",0x20ba18, 0x0, 64 * 1024, 256, RD_FULL,
>WR_QPP},
> + {"N25Q128A", 0x20bb18, 0x0, 64 * 1024, 256, RD_FULL,
>WR_QPP},
> {"N25Q256",0x20ba19, 0x0, 64 * 1024, 512, RD_FULL,
> WR_QPP | SECT_4K},
> {"N25Q256A", 0x20bb19, 0x0, 64 * 1024, 512, RD_FULL,
> WR_QPP | SECT_4K},
> {"N25Q512",0x20ba20, 0x0, 64 * 1024, 1024, RD_FULL,
> WR_QPP | E_FSR | SECT_4K},
> --
> 1.7.4
Applied to u-boot-spi/master
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-arm/master
Hello Tom, The following changes since commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca: Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 10:56:00 -0500) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to 4efd69250f6118ebd783867b3809001a1886ce9e: ARM: pxa: Fix OneNAND window access on VPAC270 (2014-01-13 12:39:10 +0100) Marek Vasut (2): ARM: pxa: Fix OneNAND SPL builds ARM: pxa: Fix OneNAND window access on VPAC270 arch/arm/cpu/pxa/config.mk | 13 + board/vpac270/u-boot-spl.lds | 1 + include/configs/vpac270.h| 2 +- 3 files changed, 15 insertions(+), 1 deletion(-) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Mon, Jan 13, 2014 at 12:42:30PM +0100, Marek Vasut wrote: > Minor fixes, please apply for 2014.01 > > The following changes since commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca: > > Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 10:56:00 > -0500) > > are available in the git repository at: > > > git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to 3603e31db54ddba820b7a7b9c7659e272f8c65de: > > usb: ums: wait for usb cable connection before enter ums mode (2014-01-13 > 12:29:12 +0100) > > > Inderpal Singh (2): > usb: ehci: exynos: set/reset hsic phys > usb: exynos5: arndale: Add network support > > Kuo-Jung Su (2): > usb: gadget: fotg210: add w1c interrupt status support > usb: gadget: fotg210: EP0 fifo empty indication is non-reliable > > Przemyslaw Marczak (1): > usb: ums: wait for usb cable connection before enter ums mode > > arch/arm/include/asm/arch-exynos/ehci.h | 14 ++ > board/samsung/arndale/arndale.c | 21 + > common/cmd_usb_mass_storage.c | 24 > drivers/usb/gadget/fotg210.c| 15 +++ > drivers/usb/host/ehci-exynos.c | 41 > + > include/configs/arndale.h | 4 > include/usb_mass_storage.h | 3 +++ > 7 files changed, 122 insertions(+) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-video/master
On Sun, Jan 12, 2014 at 11:41:10PM +0100, Anatolij Gustschin wrote: > Hey Tom, > > please pull two minor fixes for release. Thanks! > > Anatolij > > The following changes since commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca: > > Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 10:56:00 > -0500) > > are available in the git repository at: > > > git://git.denx.de/u-boot-video.git master > > for you to fetch changes up to d47c961695dd60ed7e54dc61c16ef3f3173fe3ea: > > video: ipu reg: Correct reserved array size in struct ipu_idmac (2014-01-12 > 23:00:06 +0100) > > > Liu Ying (2): > video: ipu reg: Correct reserved1 array size in struct ipu_cm > video: ipu reg: Correct reserved array size in struct ipu_idmac > > drivers/video/ipu_regs.h |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-spi/master
On Tue, Jan 14, 2014 at 12:05:32AM +0530, Jagannadha Sutradharudu Teki wrote: > Hi Tom, > > PR have quad and dual_flash change set also includes few fixes. > Tested these changes on spansion, stmicro and sst flash devices. > > -- > Thanks, > Jagan. > > The following changes since commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca: > > Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 10:56:00 > -0500) > > are available in the git repository at: > > > git://git.denx.de/u-boot-spi.git master > > for you to fetch changes up to 35a55fb57fffb615e6b20980fb317e162076adb4: > > sf: params: Removed flag SECT_4K for Micron N25Q128 (2014-01-12 21:40:23 > +0530) > > > Axel Lin (1): > spi: sh_spi: Use sh_spi_clear_bit() instead of open-coded > > Jagannadha Sutradharudu Teki (17): > sf: Add extended read commands support > sf: Add quad read/write commands support > sf: ops: Add configuration register writing support > sf: Set quad enable bit support > sf: probe: Enable RD_FULL and WR_QPP > sf: Separate the flash params table > sf: Add QUAD_IO_FAST read support > sf: Discover read dummy_byte > sf: Add macronix set QEB support > sf: probe: Enable macronix quad read/write cmds support > sf: Divide flash register ops from QEB code > sf: Code cleanups > sf: ops: Unify read_ops bank configuration > sf: Add dual memories support - DUAL_STACKED > sf: Add dual memories support - DUAL_PARALLEL > sf: Add CONFIG_SF_DUAL_FLASH > doc: SPI: Update status.txt > > Kuo-Jung Su (1): > spi: Add Faraday SPI controller support > > Simon Glass (1): > sandbox: spi: Adjust 'sf test' to work on sandbox > > Siva Durga Prasad Paladugu (1): > sf: params: Removed flag SECT_4K for Micron N25Q128 > > README | 6 + > common/cmd_sf.c | 14 +- > doc/SPI/README.dual-flash| 92 +++ > doc/SPI/README.ftssp010_spi_test | 41 > doc/SPI/status.txt | 11 +- > drivers/mtd/spi/Makefile | 4 +- > drivers/mtd/spi/sf.c | 4 + > drivers/mtd/spi/sf_internal.h| 34 ++- > drivers/mtd/spi/sf_ops.c | 157 +--- > drivers/mtd/spi/sf_params.c | 130 ++ > drivers/mtd/spi/sf_probe.c | 274 +++-- > drivers/spi/Makefile | 1 + > drivers/spi/ftssp010_spi.c | 508 > +++ > drivers/spi/sh_spi.c | 10 +- > include/spi.h| 26 ++ > include/spi_flash.h | 57 + > 16 files changed, 1171 insertions(+), 198 deletions(-) > create mode 100644 doc/SPI/README.dual-flash > create mode 100644 doc/SPI/README.ftssp010_spi_test > create mode 100644 drivers/mtd/spi/sf_params.c > create mode 100644 drivers/spi/ftssp010_spi.c Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ANN] v2014.01-rc3
Hey all, I've put v2014.01-rc3 out and we should have a tarball soon. Here's where we're at, I feel. We got some big changes in, which had been due for a while, on Friday. I don't think it's a good idea to release today, so I'm going to push things out a week. Here's what I expect for the release, change-wise: - Any regressions people report - Either removal of mini2440 and mx1ads or CONFIG_SYS_HZ fixes for them (Albert is working a removal patch now, or soon). - Fixes for i.mx platforms using hardfp toolchains (which means do_div being called instead). The patch exists, lets get this through please. Thanks all! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
On Mon, Jan 13, 2014 at 07:49:26PM +0100, Albert ARIBAUD wrote: > Hello Tom, > > The following changes since commit > 7f673c99c2d8d1aa21996c5b914f06d784b080ca: > > Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 > 10:56:00 -0500) > > are available in the git repository at: > > > git://git.denx.de/u-boot-arm master > > for you to fetch changes up to 4efd69250f6118ebd783867b3809001a1886ce9e: > > ARM: pxa: Fix OneNAND window access on VPAC270 (2014-01-13 12:39:10 > +0100) > > > Marek Vasut (2): > ARM: pxa: Fix OneNAND SPL builds > ARM: pxa: Fix OneNAND window access on VPAC270 > > arch/arm/cpu/pxa/config.mk | 13 + > board/vpac270/u-boot-spl.lds | 1 + > include/configs/vpac270.h| 2 +- > 3 files changed, 15 insertions(+), 1 deletion(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] mx6: Add initial support for the Hummingboard solo
Hi Stefano, On Mon, Jan 13, 2014 at 9:11 AM, Stefano Babic wrote: > I discussed last week via IIRC with Otavio about if the patch can still > flow into the coming release. He pointed me out that the original patch > was sent a lot of time ago as "carrier-one": > > http://patchwork.ozlabs.org/patch/288017/ > > I could then consider your patch as a resubmit of the original patch and > push it to -master, it does not matter if the subject was changed. The > patch itself is not dangerous at all for other boards, so we are running > on the safest way. That would be excellent, thanks. > > However, it makes sense only if patch3/3 will be applied by Joe in the > current release. > > http://patchwork.ozlabs.org/patch/306640/ > > Joe, do you plan to apply it for this release or is it already deferred > to -next ? Hopefully Joe can apply it for the upcoming release. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mini2440: remove board support
Signed-off-by: Albert ARIBAUD
---
board/friendlyarm/mini2440/Makefile | 8 --
board/friendlyarm/mini2440/mini2440.c | 118
board/friendlyarm/mini2440/mini2440.h | 144 --
boards.cfg| 1 -
doc/README.mini2440 | 28 ---
doc/README.scrapyard | 5 +-
6 files changed, 3 insertions(+), 301 deletions(-)
delete mode 100644 board/friendlyarm/mini2440/Makefile
delete mode 100644 board/friendlyarm/mini2440/mini2440.c
delete mode 100644 board/friendlyarm/mini2440/mini2440.h
delete mode 100644 doc/README.mini2440
diff --git a/board/friendlyarm/mini2440/Makefile
b/board/friendlyarm/mini2440/Makefile
deleted file mode 100644
index f367107..000
--- a/board/friendlyarm/mini2440/Makefile
+++ /dev/null
@@ -1,8 +0,0 @@
-#
-# (C) Copyright 2012
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-obj-y := mini2440.o
diff --git a/board/friendlyarm/mini2440/mini2440.c
b/board/friendlyarm/mini2440/mini2440.c
deleted file mode 100644
index 59ed054..000
--- a/board/friendlyarm/mini2440/mini2440.c
+++ /dev/null
@@ -1,118 +0,0 @@
-/*
- * (C) Copyright 2002
- * Sysgo Real-Time Solutions, GmbH
- * Marius Groeger
- *
- * (C) Copyright 2002
- * David Mueller, ELSOFT AG,
- *
- * (C) Copyright 2009
- * Michel Pollet
- *
- * (C) Copyright 2012
- * Gabriel Huau
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "mini2440.h"
-
-DECLARE_GLOBAL_DATA_PTR;
-
-static inline void pll_delay(unsigned long loops)
-{
- __asm__ volatile ("1:\n"
- "subs %0, %1, #1\n"
- "bne 1b" : "=r" (loops) : "0" (loops));
-}
-
-int board_early_init_f(void)
-{
- struct s3c24x0_clock_power * const clk_power =
- s3c24x0_get_base_clock_power();
-
- /* to reduce PLL lock time, adjust the LOCKTIME register */
- clk_power->locktime = 0xFF; /* Max PLL Lock time count */
- clk_power->clkdivn = CLKDIVN_VAL;
-
- /* configure UPLL */
- clk_power->upllcon = ((U_M_MDIV << 12) + (U_M_PDIV << 4) + U_M_SDIV);
- /* some delay between MPLL and UPLL */
- pll_delay(100);
-
- /* configure MPLL */
- clk_power->mpllcon = ((M_MDIV << 12) + (M_PDIV << 4) + M_SDIV);
-
- /* some delay between MPLL and UPLL */
- pll_delay(1);
-
- return 0;
-}
-
-/*
- * Miscellaneous platform dependent initialisations
- */
-int board_init(void)
-{
- struct s3c24x0_gpio * const gpio = s3c24x0_get_base_gpio();
-
- /* IOMUX Port H : UART Configuration */
- gpio->gphcon = IOMUXH_nCTS0 | IOMUXH_nRTS0 | IOMUXH_TXD0 | IOMUXH_RXD0 |
- IOMUXH_TXD1 | IOMUXH_RXD1 | IOMUXH_TXD2 | IOMUXH_RXD2;
-
- gpio_direction_output(GPH8, 0);
- gpio_direction_output(GPH9, 0);
- gpio_direction_output(GPH10, 0);
-
- /* adress of boot parameters */
- gd->bd->bi_boot_params = CONFIG_BOOT_PARAM_ADDR;
-
- return 0;
-}
-
-int dram_init(void)
-{
- struct s3c24x0_memctl *memctl = s3c24x0_get_base_memctl();
-
- /*
-* Configuring bus width and timing
-* Initialize clocks for each bank 0..5
-* Bank 3 and 4 are used for DM9000
-*/
- writel(BANK_CONF, &memctl->bwscon);
- writel(B0_CONF, &memctl->bankcon[0]);
- writel(B1_CONF, &memctl->bankcon[1]);
- writel(B2_CONF, &memctl->bankcon[2]);
- writel(B3_CONF, &memctl->bankcon[3]);
- writel(B4_CONF, &memctl->bankcon[4]);
- writel(B5_CONF, &memctl->bankcon[5]);
-
- /* Bank 6 and 7 are used for DRAM */
- writel(SDRAM_64MB, &memctl->bankcon[6]);
- writel(SDRAM_64MB, &memctl->bankcon[7]);
-
- writel(MEM_TIMING, &memctl->refresh);
- writel(BANKSIZE_CONF, &memctl->banksize);
- writel(B6_MRSR, &memctl->mrsrb6);
- writel(B7_MRSR, &memctl->mrsrb7);
-
- gd->ram_size = get_ram_size((void *) CONFIG_SYS_SDRAM_BASE,
- PHYS_SDRAM_SIZE);
- return 0;
-}
-
-int board_eth_init(bd_t *bis)
-{
-#ifdef CONFIG_DRIVER_DM9000
- return dm9000_initialize(bis);
-#else
- return 0;
-#endif
-}
diff --git a/board/friendlyarm/mini2440/mini2440.h
b/board/friendlyarm/mini2440/mini2440.h
deleted file mode 100644
index db386ea..000
--- a/board/friendlyarm/mini2440/mini2440.h
+++ /dev/null
@@ -1,144 +0,0 @@
-#ifndef __MINI2440_BOARD_CONF_H__
-#define __MINI2440_BOARD_CONF_H__
-
-/* PLL Parameters */
-#define CLKDIVN_VAL7
-#define M_MDIV 0x7f
-#define M_PDIV 0x2
-#define M_SDIV 0x1
-
-#define U_M_MDIV 0x38
-#define U_M_PDIV 0x2
-#define U_M_SDIV 0x2
-
-/* BWSCON */
-#define DW80x0
-#define DW16 0x1
-#define DW32 0x2
-#define WAIT (0x1<<2)
-
[U-Boot] [PATCH 2/2] mx1ads: remove board support
Signed-off-by: Albert ARIBAUD
---
board/mx1ads/Makefile| 16 ---
board/mx1ads/lowlevel_init.S | 68 --
board/mx1ads/mx1ads.c| 178 -
board/mx1ads/syncflash.c | 307 ---
boards.cfg | 1 -
doc/README.scrapyard | 1 +
include/configs/mx1ads.h | 163 ---
7 files changed, 1 insertion(+), 733 deletions(-)
delete mode 100644 board/mx1ads/Makefile
delete mode 100644 board/mx1ads/lowlevel_init.S
delete mode 100644 board/mx1ads/mx1ads.c
delete mode 100644 board/mx1ads/syncflash.c
delete mode 100644 include/configs/mx1ads.h
diff --git a/board/mx1ads/Makefile b/board/mx1ads/Makefile
deleted file mode 100644
index 6dfd18e..000
--- a/board/mx1ads/Makefile
+++ /dev/null
@@ -1,16 +0,0 @@
-#
-# board/mx1ads/Makefile
-#
-# (C) Copyright 2006
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# (c) Copyright 2004
-# Techware Information Technology, Inc.
-# http://www.techware.com.tw/
-#
-# Ming-Len Wu
-#
-# SPDX-License-Identifier: GPL-2.0+
-
-obj-y := mx1ads.o syncflash.o
-obj-y += lowlevel_init.o
diff --git a/board/mx1ads/lowlevel_init.S b/board/mx1ads/lowlevel_init.S
deleted file mode 100644
index d1e472a..000
--- a/board/mx1ads/lowlevel_init.S
+++ /dev/null
@@ -1,68 +0,0 @@
-/*
- * board/mx1ads/lowlevel_init.S
- *
- * (c) Copyright 2004
- * Techware Information Technology, Inc.
- * http://www.techware.com.tw/
- *
- * Ming-Len Wu
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include
-#include
-
-#define SDCTL0 0x221000
-#define SDCTL1 0x221004
-
-
-_TEXT_BASE:
- .word CONFIG_SYS_TEXT_BASE
-
-.globl lowlevel_init
-lowlevel_init:
-/* memory controller init */
-
- ldr r1, =SDCTL0
-
-/* Set Precharge Command */
-
- ldr r3, =0x92120200
-/* ldr r3, =0x92120251
-*/
- str r3, [r1]
-
-/* Issue Precharge All Commad */
- ldr r3, =0x820
- ldr r2, [r3]
-
-/* Set AutoRefresh Command */
- ldr r3, =0xA2120200
- str r3, [r1]
-
-/* Issue AutoRefresh Command */
- ldr r3, =0x800
- ldr r2, [r3]
- ldr r2, [r3]
- ldr r2, [r3]
- ldr r2, [r3]
- ldr r2, [r3]
- ldr r2, [r3]
- ldr r2, [r3]
- ldr r2, [r3]
-
-/* Set Mode Register */
- ldr r3, =0xB2120200
- str r3, [r1]
-
-/* Issue Mode Register Command */
- ldr r3, =0x08111800/* Mode Register Value */
- ldr r2, [r3]
-
-/* Set Normal Mode */
- ldr r3, =0x82124200
- str r3, [r1]
-
-/* everything is fine now */
- mov pc, lr
diff --git a/board/mx1ads/mx1ads.c b/board/mx1ads/mx1ads.c
deleted file mode 100644
index 4266048..000
--- a/board/mx1ads/mx1ads.c
+++ /dev/null
@@ -1,178 +0,0 @@
-/*
- * board/mx1ads/mx1ads.c
- *
- * (c) Copyright 2004
- * Techware Information Technology, Inc.
- * http://www.techware.com.tw/
- *
- * Ming-Len Wu
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include
-#include
-/*#include */
-#include
-#include
-
-DECLARE_GLOBAL_DATA_PTR;
-
-#define FCLK_SPEED 1
-
-#if FCLK_SPEED==0 /* Fout = 203MHz, Fin = 12MHz for Audio */
-#define M_MDIV 0xC3
-#define M_PDIV 0x4
-#define M_SDIV 0x1
-#elif FCLK_SPEED==1/* Fout = 202.8MHz */
-#define M_MDIV 0xA1
-#define M_PDIV 0x3
-#define M_SDIV 0x1
-#endif
-
-#define USB_CLOCK 1
-
-#if USB_CLOCK==0
-#define U_M_MDIV 0xA1
-#define U_M_PDIV 0x3
-#define U_M_SDIV 0x1
-#elif USB_CLOCK==1
-#define U_M_MDIV 0x48
-#define U_M_PDIV 0x3
-#define U_M_SDIV 0x2
-#endif
-
-#if 0
-
-static inline void delay (unsigned long loops)
-{
- __asm__ volatile ("1:\n"
- "subs %0, %1, #1\n"
- "bne 1b":"=r" (loops):"0" (loops));
-}
-
-#endif
-
-/*
- * Miscellaneous platform dependent initialisations
- */
-
-void SetAsynchMode (void)
-{
- __asm__ ("mrc p15,0,r0,c1,c0,0 \n"
-"mov r2, #0xC000 \n"
-"orr r0,r2,r0 \n" "mcr p15,0,r0,c1,c0,0 \n");
-}
-
-static u32 mc9328sid;
-
-int board_early_init_f(void)
-{
- mc9328sid = SIDR;
-
- GPCR = 0x03AB; /* I/O pad driving strength */
-
- /* MX1_CS1U= 0x0A00; */ /* SRAM initialization
*/
-/* MX1_CS1L= 0x0601; */
-
- MPCTL0 = 0x04632410;/* setting for 150 MHz MCU PLL CLK */
-
-/* set FCLK divider 1 (i.e. FCLK to MCU PLL CLK) and
- * BCLK divider to 2 (i.e. BCLK to 48 MHz)
- */
- CSCR = 0xAF000403;
-
- CSCR |= 0x0020; /* Trigger the restart bit(bit 21) */
- CSCR &= 0x7FFF; /* Program PRESC bit(bit 15) to 0 to
divide-by-1 */
-
-/* setup cs4 for cs8900 ethernet */
-
- CS4U = 0x0F00; /* Initialize
[U-Boot] Bug in TOP860 code with gcc 4.8.1
Dear Reinhard, attempting to build the TOP860 code with a GCC 4.8.1 based tool chain (say ELDK v5.5 or Yocto 1.5) gives the following errors: -> ./MAKEALL TOP860 Configuring for TOP860 board... textdata bss dec hex filename 165471 21020 17316 203807 31c1f ./u-boot ../common/flash.c: In function 'flash_init': ../common/flash.c:336:20: warning: iteration 128u invokes undefined behavior [-Waggressive-loop-optimizations] info->start[i] = (ulong)addr + 0x1 * i; ^ ../common/flash.c:334:4: note: containing loop for (i = 0; i < info->sector_count; i++) ^ ... Can you please provide a fix - or is this old hardware and the code should be removed from the U-Boot tree? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Life would be so much easier if everyone read the manual. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [OT] CC:s in commits (was: [PATCH 1/2] socfpga: Adding Scan Manager driver)
Dear Albert, In message <20140113173924.684ce548@lilith> you wrote: > > > Actually these Cc will be helpful when using git send-email. It will > > auto cc to these mailing list when the patch is send out for review > > (instead entering the names manually every time). Thanks > > That is useful to the sender, but useless to anyone else. This is not correct. It is also an indicatioin who was explicitly addressed when the patch was submitted, so you can later still see from the commit message who was invited to commend and refrained from doing so. This may help a lot in discussions like "but I never had a chance to see this patch". Please keep these. The are really useful. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A metaphor is like a simile. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [OT] CC:s in commits (was: [PATCH 1/2] socfpga: Adding Scan Manager driver)
Dear Chin Liang See, In message <1389634896.9425.4.ca...@clsee-virtualbox.altera.com> you wrote: > > The patman script looks cool. Let me learn up this and using this when > submitting future patches. At same time, sorry for the hassle as I am > not aware the git send-email method not helpful for maintainer. For this > patch, wonder is it ok for you to manually remove the Ccs? Thanks and > appreciate again for your helps. Patman and the Cc: in the commit message may overlap, but they may also include different lists of addresses. For documentation purposes, the Cc in the commit message are useful and should be kept. Just my $ 0.02 ... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de On the subject of C program indentation: "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." - Blair P. Houghton ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [OT] CC:s in commits (was: [PATCH 1/2] socfpga: Adding Scan Manager driver)
Hi Wolfgang, On Mon, 2014-01-13 at 22:08 +0100, ZY - wd wrote: > Dear Albert, > > In message <20140113173924.684ce548@lilith> you wrote: > > > > > Actually these Cc will be helpful when using git send-email. It will > > > auto cc to these mailing list when the patch is send out for review > > > (instead entering the names manually every time). Thanks > > > > That is useful to the sender, but useless to anyone else. > > This is not correct. It is also an indicatioin who was explicitly > addressed when the patch was submitted, so you can later still see > from the commit message who was invited to commend and refrained from > doing so. This may help a lot in discussions like "but I never had a > chance to see this patch". > > Please keep these. The are really useful. I'm glad you weighed in on this. I have done this CC: field many times in patches sent to kernel.org, and have not received any feedbacks to remove it. Some patches can include quite a few entries. So I was kinda surprised to see a comment about it here on the u-boot list. Dinh > > Best regards, > > Wolfgang Denk > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [OT] CC:s in commits (was: [PATCH 1/2] socfpga: Adding Scan Manager driver)
Hi Wolfgang, On Mon, 13 Jan 2014 22:08:15 +0100, Wolfgang Denk wrote: > Dear Albert, > > In message <20140113173924.684ce548@lilith> you wrote: > > > > > Actually these Cc will be helpful when using git send-email. It will > > > auto cc to these mailing list when the patch is send out for review > > > (instead entering the names manually every time). Thanks > > > > That is useful to the sender, but useless to anyone else. > > This is not correct. It is also an indicatioin who was explicitly > addressed when the patch was submitted, so you can later still see > from the commit message who was invited to commend and refrained from > doing so. This may help a lot in discussions like "but I never had a > chance to see this patch". > > Please keep these. The are really useful. Thanks Wolfgang. I hadn't considered this 'traceability' aspect -- I haven't been involved in enough such discussions, obviously. Chin Liang See: apologies for the noise. > Best regards, > > Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] v2014.01-rc3
Hi Tom, On 13/01/2014 20:42, Tom Rini wrote: Hey all, I've put v2014.01-rc3 out and we should have a tarball soon. Here's where we're at, I feel. We got some big changes in, which had been due for a while, on Friday. I don't think it's a good idea to release today, so I'm going to push things out a week. Here's what I expect for the release, change-wise: - Any regressions people report - Either removal of mini2440 and mx1ads or CONFIG_SYS_HZ fixes for them (Albert is working a removal patch now, or soon). - Fixes for i.mx platforms using hardfp toolchains (which means do_div being called instead). The patch exists, lets get this through please. Patch is already merged into u-boot-imx. It will be part of next (last) pull request. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mx1ads: remove board support
On 13/01/2014 21:06, Albert ARIBAUD wrote:
Signed-off-by: Albert ARIBAUD
---
board/mx1ads/Makefile| 16 ---
board/mx1ads/lowlevel_init.S | 68 --
board/mx1ads/mx1ads.c| 178 -
board/mx1ads/syncflash.c | 307 ---
boards.cfg | 1 -
doc/README.scrapyard | 1 +
include/configs/mx1ads.h | 163 ---
7 files changed, 1 insertion(+), 733 deletions(-)
delete mode 100644 board/mx1ads/Makefile
delete mode 100644 board/mx1ads/lowlevel_init.S
delete mode 100644 board/mx1ads/mx1ads.c
delete mode 100644 board/mx1ads/syncflash.c
delete mode 100644 include/configs/mx1ads.h
diff --git a/board/mx1ads/Makefile b/board/mx1ads/Makefile
deleted file mode 100644
index 6dfd18e..000
--- a/board/mx1ads/Makefile
+++ /dev/null
@@ -1,16 +0,0 @@
-#
-# board/mx1ads/Makefile
-#
-# (C) Copyright 2006
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# (c) Copyright 2004
-# Techware Information Technology, Inc.
-# http://www.techware.com.tw/
-#
-# Ming-Len Wu
-#
-# SPDX-License-Identifier: GPL-2.0+
-
-obj-y := mx1ads.o syncflash.o
-obj-y += lowlevel_init.o
diff --git a/board/mx1ads/lowlevel_init.S b/board/mx1ads/lowlevel_init.S
deleted file mode 100644
index d1e472a..000
--- a/board/mx1ads/lowlevel_init.S
+++ /dev/null
@@ -1,68 +0,0 @@
-/*
- * board/mx1ads/lowlevel_init.S
- *
- * (c) Copyright 2004
- * Techware Information Technology, Inc.
- * http://www.techware.com.tw/
- *
- * Ming-Len Wu
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include
-#include
-
-#define SDCTL0 0x221000
-#define SDCTL1 0x221004
-
-
-_TEXT_BASE:
- .word CONFIG_SYS_TEXT_BASE
-
-.globl lowlevel_init
-lowlevel_init:
-/* memory controller init */
-
- ldr r1, =SDCTL0
-
-/* Set Precharge Command */
-
- ldr r3, =0x92120200
-/* ldr r3, =0x92120251
-*/
- str r3, [r1]
-
-/* Issue Precharge All Commad */
- ldr r3, =0x820
- ldr r2, [r3]
-
-/* Set AutoRefresh Command */
- ldr r3, =0xA2120200
- str r3, [r1]
-
-/* Issue AutoRefresh Command */
- ldr r3, =0x800
- ldr r2, [r3]
- ldr r2, [r3]
- ldr r2, [r3]
- ldr r2, [r3]
- ldr r2, [r3]
- ldr r2, [r3]
- ldr r2, [r3]
- ldr r2, [r3]
-
-/* Set Mode Register */
- ldr r3, =0xB2120200
- str r3, [r1]
-
-/* Issue Mode Register Command */
- ldr r3, =0x08111800/* Mode Register Value */
- ldr r2, [r3]
-
-/* Set Normal Mode */
- ldr r3, =0x82124200
- str r3, [r1]
-
-/* everything is fine now */
- mov pc, lr
diff --git a/board/mx1ads/mx1ads.c b/board/mx1ads/mx1ads.c
deleted file mode 100644
index 4266048..000
--- a/board/mx1ads/mx1ads.c
+++ /dev/null
@@ -1,178 +0,0 @@
-/*
- * board/mx1ads/mx1ads.c
- *
- * (c) Copyright 2004
- * Techware Information Technology, Inc.
- * http://www.techware.com.tw/
- *
- * Ming-Len Wu
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include
-#include
-/*#include */
-#include
-#include
-
-DECLARE_GLOBAL_DATA_PTR;
-
-#define FCLK_SPEED 1
-
-#if FCLK_SPEED==0 /* Fout = 203MHz, Fin = 12MHz for Audio */
-#define M_MDIV 0xC3
-#define M_PDIV 0x4
-#define M_SDIV 0x1
-#elif FCLK_SPEED==1/* Fout = 202.8MHz */
-#define M_MDIV 0xA1
-#define M_PDIV 0x3
-#define M_SDIV 0x1
-#endif
-
-#define USB_CLOCK 1
-
-#if USB_CLOCK==0
-#define U_M_MDIV 0xA1
-#define U_M_PDIV 0x3
-#define U_M_SDIV 0x1
-#elif USB_CLOCK==1
-#define U_M_MDIV 0x48
-#define U_M_PDIV 0x3
-#define U_M_SDIV 0x2
-#endif
-
-#if 0
-
-static inline void delay (unsigned long loops)
-{
- __asm__ volatile ("1:\n"
- "subs %0, %1, #1\n"
- "bne 1b":"=r" (loops):"0" (loops));
-}
-
-#endif
-
-/*
- * Miscellaneous platform dependent initialisations
- */
-
-void SetAsynchMode (void)
-{
- __asm__ ("mrc p15,0,r0,c1,c0,0 \n"
-"mov r2, #0xC000 \n"
-"orr r0,r2,r0 \n" "mcr p15,0,r0,c1,c0,0 \n");
-}
-
-static u32 mc9328sid;
-
-int board_early_init_f(void)
-{
- mc9328sid = SIDR;
-
- GPCR = 0x03AB; /* I/O pad driving strength */
-
- /* MX1_CS1U= 0x0A00; */ /* SRAM initialization
*/
-/* MX1_CS1L= 0x0601; */
-
- MPCTL0 = 0x04632410;/* setting for 150 MHz MCU PLL CLK */
-
-/* set FCLK divider 1 (i.e. FCLK to MCU PLL CLK) and
- * BCLK divider to 2 (i.e. BCLK to 48 MHz)
- */
- CSCR = 0xAF000403;
-
- CSCR |= 0x0020; /* Trigger the restart bit(bit 21) */
- CSCR &= 0x7FFF; /* Program PRESC bit(bit 15) to 0 to divide-by-1 */
-
-/* setup cs4 for cs8900 ether
Re: [U-Boot] [OT] CC:s in commits (was: [PATCH 1/2] socfpga: Adding Scan Manager driver)
Dear Wolfgang, On Mon, 2014-01-13 at 22:09 +0100, ZY - wd wrote: > Dear Chin Liang See, > > In message <1389634896.9425.4.ca...@clsee-virtualbox.altera.com> you wrote: > > > > The patman script looks cool. Let me learn up this and using this when > > submitting future patches. At same time, sorry for the hassle as I am > > not aware the git send-email method not helpful for maintainer. For this > > patch, wonder is it ok for you to manually remove the Ccs? Thanks and > > appreciate again for your helps. > > Patman and the Cc: in the commit message may overlap, but they may > also include different lists of addresses. For documentation > purposes, the Cc in the commit message are useful and should be kept. > Just my $ 0.02 ... > Thanks for the explanation. It definitely worth more than 2 cents. :) 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] [OT] CC:s in commits (was: [PATCH 1/2] socfpga: Adding Scan Manager driver)
Dear Albert, On Mon, 2014-01-13 at 23:07 +0100, ZY - albert.u.boot wrote: > Hi Wolfgang, > > On Mon, 13 Jan 2014 22:08:15 +0100, Wolfgang Denk wrote: > > > Dear Albert, > > > > In message <20140113173924.684ce548@lilith> you wrote: > > > > > > > Actually these Cc will be helpful when using git send-email. It will > > > > auto cc to these mailing list when the patch is send out for review > > > > (instead entering the names manually every time). Thanks > > > > > > That is useful to the sender, but useless to anyone else. > > > > This is not correct. It is also an indicatioin who was explicitly > > addressed when the patch was submitted, so you can later still see > > from the commit message who was invited to commend and refrained from > > doing so. This may help a lot in discussions like "but I never had a > > chance to see this patch". > > > > Please keep these. The are really useful. > > Thanks Wolfgang. I hadn't considered this 'traceability' aspect -- I > haven't been involved in enough such discussions, obviously. > > Chin Liang See: apologies for the noise. No worries. We learned something today :) Chin Liang > > > Best regards, > > > > Wolfgang Denk > > Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
