Re: [U-Boot] [PATCH 2/2] mtd: denali: recover the same function prototypes as Linux Kernel
Hi Masahiro,
On Fri, 2014-04-18 at 20:30 +0900, Masahiro Yamada wrote:
This patch is a review feedback against Denali NAND controller driver.
http://patchwork.ozlabs.org/patch/333077/
This is not applicable to the mainline.
--
This driver code has diverged too much from that of Linux Kernel.
The main cause was to drop struct denali_nand_info *denali
from the most of functions and to replace denali-foo with denali.foo.
But is it necessary?
I think it just resulted in the difficulty of diffing and re-use of
the Linux code.
This patch revives struct denali_nand_info *denali and denali-foo.
Sure, definitely we can fix this too.
I forget what is the reason I changed that previously. I suspect it
might because I try to prevent to use malloc. As this driver will be
used through the whole run time, it won't be free during the run. With
that, its much better to convert it to BSS. I can prompt the warning
during build time instead hitting error during run time :) I believe
kernel can do that as kernel can unload the module. Just my 2 cents
thought
Thanks
Chin Liang
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Chin Liang See cl...@altera.com
Cc: Artem Bityutskiy artem.bityuts...@linux.intel.com
Cc: David Woodhouse david.woodho...@intel.com
Cc: Brian Norris computersforpe...@gmail.com
Cc: Scott Wood scottw...@freescale.com
---
drivers/mtd/nand/denali.c | 608
+-
1 file changed, 327 insertions(+), 281 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index dcde3e6..565ca9e 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -7,6 +7,7 @@
*/
#include common.h
+#include malloc.h
#include nand.h
#include asm/errno.h
#include asm/io.h
@@ -15,7 +16,6 @@
#define NAND_DEFAULT_TIMINGS -1
-static struct denali_nand_info denali;
static int onfi_timing_mode = NAND_DEFAULT_TIMINGS;
/* We define a macro here that combines all interrupts this driver uses into
@@ -40,6 +40,12 @@ static int onfi_timing_mode = NAND_DEFAULT_TIMINGS;
#define SUPPORT_8BITECC 1
+/*
+ * this macro allows us to convert from an MTD structure to our own
+ * device context (denali) structure.
+ */
+#define mtd_to_denali(m) (((struct nand_chip *)mtd-priv)-priv)
+
/* These constants are defined by the driver to enable common driver
* configuration options. */
#define SPARE_ACCESS 0x41
@@ -66,44 +72,53 @@ static int onfi_timing_mode = NAND_DEFAULT_TIMINGS;
#define BANK(x) ((x) 24)
/* Interrupts are cleared by writing a 1 to the appropriate status bit */
-static inline void clear_interrupt(uint32_t irq_mask)
+static inline void clear_interrupt(struct denali_nand_info *denali,
+ uint32_t irq_mask)
{
- uint32_t intr_status_reg = 0;
- intr_status_reg = INTR_STATUS(denali.flash_bank);
- writel(irq_mask, denali.flash_reg + intr_status_reg);
+ uint32_t intr_status_reg;
+
+ intr_status_reg = INTR_STATUS(denali-flash_bank);
+
+ writel(irq_mask, denali-flash_reg + intr_status_reg);
}
-static uint32_t read_interrupt_status(void)
+static uint32_t read_interrupt_status(struct denali_nand_info *denali)
{
- uint32_t intr_status_reg = 0;
- intr_status_reg = INTR_STATUS(denali.flash_bank);
- return readl(denali.flash_reg + intr_status_reg);
+ uint32_t intr_status_reg;
+
+ intr_status_reg = INTR_STATUS(denali-flash_bank);
+
+ return readl(denali-flash_reg + intr_status_reg);
}
-static void clear_interrupts(void)
+static void clear_interrupts(struct denali_nand_info *denali)
{
- uint32_t status = 0;
- status = read_interrupt_status();
- clear_interrupt(status);
- denali.irq_status = 0;
+ uint32_t status;
+
+ status = read_interrupt_status(denali);
+ clear_interrupt(denali, status);
+
+ denali-irq_status = 0;
}
-static void denali_irq_enable(uint32_t int_mask)
+static void denali_irq_enable(struct denali_nand_info *denali,
+ uint32_t int_mask)
{
int i;
- for (i = 0; i denali.max_banks; ++i)
- writel(int_mask, denali.flash_reg + INTR_EN(i));
+
+ for (i = 0; i denali-max_banks; ++i)
+ writel(int_mask, denali-flash_reg + INTR_EN(i));
}
-static uint32_t wait_for_irq(uint32_t irq_mask)
+static uint32_t wait_for_irq(struct denali_nand_info *denali, uint32_t
irq_mask)
{
unsigned long timeout = 100;
uint32_t intr_status;
do {
- intr_status = read_interrupt_status() DENALI_IRQ_ALL;
+ intr_status = read_interrupt_status(denali) DENALI_IRQ_ALL;
if (intr_status irq_mask) {
- denali.irq_status = ~irq_mask;
+ denali-irq_status = ~irq_mask;
Re: [U-Boot] [PATCH v7] nand/denali: Adding Denali NAND driver support
Hi Masahiro, On Fri, 2014-04-18 at 20:41 +0900, Masahiro Yamada wrote: Hi Chin, I found another fatal problem in v7. nand markbad command does not work at all. I think write_oob_data() is buggy. I believe I already comment that on the previous mail. In short, its working for me as I am using the BBT within the flash. And I made nand bad command much faster. And other misc feedbacks. Actually, its only happen when new chip is used. But this code improved the speed, its a nice enhancement to put into v8. How about squashing http://patchwork.ozlabs.org/patch/340277/ http://patchwork.ozlabs.org/patch/340278/ to v7 and posting v8. If you are ok with the comments, I can go ahead to create the v8 with below changes 1. Change denali.xx to denali-xx 2. Enhancement of nand bad bad block scanning function Thanks Chin Liang Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mtd: denali: improve nand_read_oob and fix nand_write_oob
On Tue, 2014-04-22 at 14:12 -0500, Scott Wood wrote: On Tue, 2014-04-22 at 10:04 +0900, Masahiro Yamada wrote: Hi Scott, It is really really painful to wait more than 10 seconds just for bad block scanning to boot Linux. Making bad block scans faster is a good thing, but why do you need to scan them just to boot Linux? Aren't you using an on-flash BBT? I did not know that. I thought all blocks must be scanned. Could you teach me the better way? If you use NAND_BBT_USE_FLASH, and NAND_BBT_CREATE is present in the bbt descriptor (this is true of the default descriptors), then the scanning should only need to happen on first use. On subsequent boots only the bad block table should need to be read. Yup, I agreed with this statement :) I believe this bad block table can be used by kernel in later stage. Probably someone can comment if I am wrong. Thanks Chin Liang -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mtd: denali: improve nand_read_oob and fix nand_write_oob
Hi Masahiro,
I am back :)
Sorry for late reply as I was aways for few weeks.
On Fri, 2014-04-18 at 20:30 +0900, Masahiro Yamada wrote:
This patch is a review feedback against Denali NAND controller driver.
http://patchwork.ozlabs.org/patch/333077/
This is not applicable to the mainline.
---
Hi Chin,
This patch fixes some issues.
[1] Fix denali_write_oob() handler.
As for v7, nand markbad did not work at all.
With this patch, it works.
Actually this was tested before.
Here is the test result (as this was written as SOCFPGA documentation)
SOCFPGA_CYCLONE5 # nand markbad 0
Bad block table written to 0x3ffe, version 0x02
Bad block table written to 0x3ffc, version 0x02
block 0x successfully marked as bad
SOCFPGA_CYCLONE5 # nand bad
Device 0 bad blocks:
3ff8
3ffa
3ffc
3ffe
SOCFPGA_CYCLONE5 #
[2] Make denali_read_oob() 10x faster.
One of the fatal issues of v7 is nand bad command is extremely slow.
This is the benchmark of v7
= time nand bad
Device 0 bad blocks:
time: 11.300 seconds, 11300 ticks
It is really really painful to wait more than 10 seconds just for bad block
scanning to boot Linux.
In v7, denali_read_oob() calls denali_read_page_raw().
This causes the transfering main area data and memcpy of it,
which leads to significant performance regression.
Like Linux Kernel, dedicated denali_read_oob() must be impilemented.
With this patch, nand bad command gets much faster!
This is my benchmark:
= time nand bad
Device 0 bad blocks:
time: 0.998 seconds, 998 ticks
I believe the bad block scanning would be required for new chip only.
This is when the bad block table is not existing within the NAND chip.
Once its available, the scanning would not be required as the BBT would
be loaded into memory. From there, the read and write would run much
much faster. Nevertheless, these code will help to speed up the bad
block scanning for the first time. I can apply this to v8 once I get
your feedback on other comments.
[3] Remove false comment
/* Writes OOB data to the device.
* This code unused under normal U-Boot console as normally page write raw
* to be used for write oob data with main data.
*/
static int write_oob_data(struct mtd_info *mtd, uint8_t *buf, int page)
This comment is telling a lie.
write_oob_data() is called from nand markbad command.
It must be deleted.
Actually this comment is correct during integration into 2013 release. I
set the option to use NAND_USE_FLASH_BBT where it will not call
nand_do_write_oob. Do note that we will always write bad block info into
bad block table which are located at last 4 blocks of the NAND flash.
In latest code, the function nand_do_write_oob will be called if
write_oob is set (where NAND_BBT_NO_OOB_BBM is clear). From the
description of NAND_BBT_NO_OOB_BBM, user need to set it if we don't want
the bad block table located at OOB.
For our case, it should be true as we are using HW ECC. Our data might
span into OOB region. Definitely we don't want this bad block table
overwritten our data then. Wonder is this match with your understanding.
In short, the function write_oob_data shouldn't be called for our case.
Thanks
Chin Liang
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Chin Liang See cl...@altera.com
Cc: Artem Bityutskiy artem.bityuts...@linux.intel.com
Cc: David Woodhouse david.woodho...@intel.com
Cc: Brian Norris computersforpe...@gmail.com
Cc: Scott Wood scottw...@freescale.com
---
drivers/mtd/nand/denali.c | 136
+++---
1 file changed, 91 insertions(+), 45 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 348e244..dcde3e6 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -527,46 +527,34 @@ static void setup_ecc_for_xfer(bool ecc_en, bool
transfer_spare)
static int denali_send_pipeline_cmd(bool ecc_en, bool transfer_spare,
int access_type, int op)
{
- uint32_t addr = 0x0, cmd = 0x0, irq_status = 0, irq_mask = 0;
- uint32_t page_count = 1;/* always read a page */
-
- if (op == DENALI_READ)
- irq_mask = INTR_STATUS__LOAD_COMP;
- else if (op == DENALI_WRITE)
- irq_mask = INTR_STATUS__PROGRAM_COMP |
- INTR_STATUS__PROGRAM_FAIL;
- else
- BUG();
+ uint32_t addr = 0x0, cmd = 0x0, irq_status;
+ static uint32_t page_count = 1;
+
+ setup_ecc_for_xfer(ecc_en, transfer_spare);
/* clear interrupts */
clear_interrupts();
- /* setup ECC and transfer spare reg */
- setup_ecc_for_xfer(ecc_en, transfer_spare);
-
addr = BANK(denali.flash_bank) | denali.page;
/* setup the acccess type */
cmd = MODE_10 | addr;
- index_addr((uint32_t)cmd, access_type);
+ index_addr(cmd,
[U-Boot] [PATCH 1/4] imx25: Add new hardware registers
From: Thomas Diener die...@gmx.de
Signed-off-by: Thomas Diener die...@gmx.de
---
arch/arm/include/asm/arch-mx25/imx-regs.h | 175 +
1 file changed, 175 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index a17f828..3dffa4a 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -161,6 +161,126 @@ struct aips_regs {
u32 mpr_0_7;
u32 mpr_8_15;
};
+/* LCD controller registers */
+struct lcdc_regs {
+ u32 lssar; /* Screen Start Address */
+ u32 lsr;/* Size */
+ u32 lvpwr; /* Virtual Page Width */
+ u32 lcpr; /* Cursor Position */
+ u32 lcwhb; /* Cursor Width Height and Blink */
+ u32 lccmr; /* Color Cursor Mapping */
+ u32 lpcr; /* Panel Configuration */
+ u32 lhcr; /* Horizontal Configuration */
+ u32 lvcr; /* Vertical Configuration */
+ u32 lpor; /* Panning Offset */
+ u32 lscr; /* Sharp Configuration */
+ u32 lpccr; /* PWM Contrast Control */
+ u32 ldcr; /* DMA Control */
+ u32 lrmcr; /* Refresh Mode Control */
+ u32 licr; /* Interrupt Configuration */
+ u32 lier; /* Interrupt Enable */
+ u32 lisr; /* Interrupt Status */
+ u32 res0[3];
+ u32 lgwsar; /* Graphic Window Start Address */
+ u32 lgwsr; /* Graphic Window Size */
+ u32 lgwvpwr;/* Graphic Window Virtual Page Width Regist */
+ u32 lgwpor; /* Graphic Window Panning Offset */
+ u32 lgwpr; /* Graphic Window Position */
+ u32 lgwcr; /* Graphic Window Control */
+ u32 lgwdcr; /* Graphic Window DMA Control */
+ u32 res1[5];
+ u32 lauscr; /* AUS Mode Control */
+ u32 lausccr;/* AUS mode Cursor Control */
+ u32 res2[31 + 64*7];
+ u32 bglut; /* Background Lookup Table */
+ u32 gwlut; /* Graphic Window Lookup Table */
+};
+
+/* Wireless External Interface Module Registers */
+struct weim_regs {
+ u32 cscr0u; /* Chip Select 0 Upper Register */
+ u32 cscr0l; /* Chip Select 0 Lower Register */
+ u32 cscr0a; /* Chip Select 0 Addition Register */
+ u32 pad0;
+ u32 cscr1u; /* Chip Select 1 Upper Register */
+ u32 cscr1l; /* Chip Select 1 Lower Register */
+ u32 cscr1a; /* Chip Select 1 Addition Register */
+ u32 pad1;
+ u32 cscr2u; /* Chip Select 2 Upper Register */
+ u32 cscr2l; /* Chip Select 2 Lower Register */
+ u32 cscr2a; /* Chip Select 2 Addition Register */
+ u32 pad2;
+ u32 cscr3u; /* Chip Select 3 Upper Register */
+ u32 cscr3l; /* Chip Select 3 Lower Register */
+ u32 cscr3a; /* Chip Select 3 Addition Register */
+ u32 pad3;
+ u32 cscr4u; /* Chip Select 4 Upper Register */
+ u32 cscr4l; /* Chip Select 4 Lower Register */
+ u32 cscr4a; /* Chip Select 4 Addition Register */
+ u32 pad4;
+ u32 cscr5u; /* Chip Select 5 Upper Register */
+ u32 cscr5l; /* Chip Select 5 Lower Register */
+ u32 cscr5a; /* Chip Select 5 Addition Register */
+ u32 pad5;
+ u32 wcr;/* WEIM Configuration Register */
+};
+
+/* Multi-Master Memory Interface */
+struct m3if_regs {
+ u32 ctl;/* Control Register */
+ u32 wcfg0; /* Watermark Configuration Register 0 */
+ u32 wcfg1; /* Watermark Configuration Register1 */
+ u32 wcfg2; /* Watermark Configuration Register2 */
+ u32 wcfg3; /* Watermark Configuration Register 3 */
+ u32 wcfg4; /* Watermark Configuration Register 4 */
+ u32 wcfg5; /* Watermark Configuration Register 5 */
+ u32 wcfg6; /* Watermark Configuration Register 6 */
+ u32 wcfg7; /* Watermark Configuration Register 7 */
+ u32 wcsr; /* Watermark Control and Status Register */
+ u32 scfg0; /* Snooping Configuration Register 0 */
+ u32 scfg1; /* Snooping Configuration Register 1 */
+ u32 scfg2; /* Snooping Configuration Register 2 */
+ u32 ssr0; /* Snooping Status Register 0 */
+ u32 ssr1; /* Snooping Status Register 1 */
+ u32 res0;
+ u32 mlwe0; /* Master Lock WEIM CS0 Register */
+ u32 mlwe1; /* Master Lock WEIM CS1 Register */
+ u32 mlwe2; /* Master Lock WEIM CS2 Register */
+ u32 mlwe3; /* Master Lock WEIM CS3 Register */
+ u32 mlwe4; /* Master Lock WEIM CS4 Register */
+ u32 mlwe5; /* Master Lock WEIM CS5 Register */
+};
+
+/* Pulse width modulation */
+struct pwm_regs {
+ u32 cr; /* Control Register */
+ u32 sr; /* Status Register */
+ u32 ir; /* Interrupt Register */
+ u32 sar;/*
[U-Boot] [PATCH] exynos: usb: Fix data abort on boards w/o vbus-gpio node in the DT
Commit 4a271cb1b4ff doesn't take into account that fdtdec_setup_gpio() returns success when the gpio passed to it is FDT_GPIO_NONE (no gpio node found in the fdtdec_decode_gpio() call). This results in calling gpio_direction_output() on invalid gpio. For this reason executing usb start command on Arndale causes data abort in the ehci-exynos driver. Add the fdt_gpio_isvalid() check to fix that problem. Signed-off-by: Andrey Konovalov andrey.konova...@linaro.org Cc: Julius Werner jwer...@chromium.org Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com Cc: Marek Vasut ma...@denx.de --- drivers/usb/host/ehci-exynos.c |3 ++- drivers/usb/host/xhci-exynos5.c |3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c index 9356878..edd91a8 100644 --- a/drivers/usb/host/ehci-exynos.c +++ b/drivers/usb/host/ehci-exynos.c @@ -197,7 +197,8 @@ int ehci_hcd_init(int index, enum usb_init_type init, #ifdef CONFIG_OF_CONTROL /* setup the Vbus gpio here */ - if (!fdtdec_setup_gpio(ctx-vbus_gpio)) + if (fdt_gpio_isvalid(ctx-vbus_gpio) + !fdtdec_setup_gpio(ctx-vbus_gpio)) gpio_direction_output(ctx-vbus_gpio.gpio, 1); #endif diff --git a/drivers/usb/host/xhci-exynos5.c b/drivers/usb/host/xhci-exynos5.c index 1146d10..b4946a3 100644 --- a/drivers/usb/host/xhci-exynos5.c +++ b/drivers/usb/host/xhci-exynos5.c @@ -298,7 +298,8 @@ int xhci_hcd_init(int index, struct xhci_hccr **hccr, struct xhci_hcor **hcor) #ifdef CONFIG_OF_CONTROL /* setup the Vbus gpio here */ - if (!fdtdec_setup_gpio(ctx-vbus_gpio)) + if (fdt_gpio_isvalid(ctx-vbus_gpio) + !fdtdec_setup_gpio(ctx-vbus_gpio)) gpio_direction_output(ctx-vbus_gpio.gpio, 1); #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] video: Add support for imx25 lcd controller
From: Thomas Diener die...@gmx.de
This patch adds support for the imx25 lcd display controller.
Signed-off-by: Thomas Diener die...@gmx.de
---
drivers/video/Makefile|1 +
drivers/video/imx25lcdc.c | 123 +
2 files changed, 124 insertions(+)
create mode 100644 drivers/video/imx25lcdc.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index c527029..945f35d 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_VIDEO_BCM2835) += bcm2835.o
obj-$(CONFIG_VIDEO_COREBOOT) += coreboot_fb.o
obj-$(CONFIG_VIDEO_CT69000) += ct69000.o videomodes.o
obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
+obj-$(CONFIG_VIDEO_IMX25LCDC) += imx25lcdc.o videomodes.o
obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
obj-$(CONFIG_VIDEO_MB86R0xGDC) += mb86r0xgdc.o videomodes.o
obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
diff --git a/drivers/video/imx25lcdc.c b/drivers/video/imx25lcdc.c
new file mode 100644
index 000..3b45472
--- /dev/null
+++ b/drivers/video/imx25lcdc.c
@@ -0,0 +1,123 @@
+/*
+ * (C) Copyright 2011
+ * Matthias Weisser weiss...@arcor.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * imx25lcdc.c - Graphic interface for i.MX25 lcd controller
+ */
+
+#include common.h
+
+#include malloc.h
+#include asm/io.h
+#include asm/arch/imx-regs.h
+#include video_fb.h
+#include videomodes.h
+
+/*
+ * 4MB (at the end of system RAM)
+ */
+#define VIDEO_MEM_SIZE 0x40
+
+#define FB_SYNC_CLK_INV(116) /* pixel clock inverted */
+
+/*
+ * Graphic Device
+ */
+static GraphicDevice imx25fb;
+
+void *video_hw_init(void)
+{
+ struct lcdc_regs *lcdc = (struct lcdc_regs *)IMX_LCDC_BASE;
+ struct ccm_regs *ccm = (struct ccm_regs *)IMX_CCM_BASE;
+ GraphicDevice *pGD = imx25fb;
+ char *s;
+ u32 *videomem;
+
+ memset(pGD, 0, sizeof(GraphicDevice));
+
+ pGD-gdfIndex = GDF_16BIT_565RGB;
+ pGD-gdfBytesPP = 2;
+ pGD-memSize = VIDEO_MEM_SIZE;
+ pGD-frameAdrs = PHYS_SDRAM + PHYS_SDRAM_SIZE - VIDEO_MEM_SIZE;
+
+ videomem = (u32 *)pGD-frameAdrs;
+
+ s = getenv(videomode);
+ if (s != NULL) {
+ struct ctfb_res_modes var_mode;
+ u32 lsr, lpcr, lhcr, lvcr;
+ unsigned long div;
+ int bpp;
+
+ /* Disable all clocks of the LCDC */
+ writel(readl(ccm-cgr0) ~((17) | (124)), ccm-cgr0);
+ writel(readl(ccm-cgr1) ~(129), ccm-cgr1);
+
+ bpp = video_get_params(var_mode, s);
+
+ if (bpp == 0) {
+ var_mode.xres = 320;
+ var_mode.yres = 240;
+ var_mode.pixclock = 154000;
+ var_mode.left_margin = 68;
+ var_mode.right_margin = 20;
+ var_mode.upper_margin = 4;
+ var_mode.lower_margin = 18;
+ var_mode.hsync_len = 40;
+ var_mode.vsync_len = 6;
+ var_mode.sync = 0;
+ var_mode.vmode = 0;
+ }
+
+ /* Fill memory with white */
+ memset(videomem, 0xFF, var_mode.xres * var_mode.yres * 2);
+
+ imx25fb.winSizeX = var_mode.xres;
+ imx25fb.winSizeY = var_mode.yres;
+
+ /* LCD base clock is 66.6MHZ. We do calculations in kHz */
+ div = 66000 / (10L / var_mode.pixclock);
+ if (div 63)
+ div = 63;
+ if (0 == div)
+ div = 1;
+
+ lsr = ((var_mode.xres / 16) 20) |
+ var_mode.yres;
+ lpcr = (1 31) |
+ (1 30) |
+ (5 25) |
+ (1 23) |
+ (1 22) |
+ (1 19) |
+ (1 7) |
+ div;
+ lhcr = (var_mode.right_margin 0) |
+ (var_mode.left_margin 8) |
+ (var_mode.hsync_len 26);
+
+ lvcr = (var_mode.lower_margin 0) |
+ (var_mode.upper_margin 8) |
+ (var_mode.vsync_len 26);
+
+ writel((uint32_t)videomem, lcdc-lssar);
+ writel(lsr, lcdc-lsr);
+ writel(var_mode.xres * 2 / 4, lcdc-lvpwr);
+ writel(lpcr, lcdc-lpcr);
+ writel(lhcr, lcdc-lhcr);
+ writel(lvcr, lcdc-lvcr);
+ writel(0x00040060, lcdc-ldcr);
+
+ writel(0xA90300, lcdc-lpccr);
+
+ /* Ensable all clocks of the LCDC */
+ writel(readl(ccm-cgr0) | ((17) | (124)), ccm-cgr0);
+ writel(readl(ccm-cgr1) | (129), ccm-cgr1);
+ }
+
+ return pGD;
+}
+
+
--
1.7.9.5
[U-Boot] [PATCH 0/4] imx25: Add hardware support
From: Thomas Diener die...@gmx.de This patchset adds support for the imx25 lcd controller and support for variants of cpu and base boards with drivers. Thomas Diener (4): imx25: Add new hardware registers video: Add support for imx25 lcd controller zmx25: Add extended support for the cpu board and belonging base boards Update of the company logo arch/arm/include/asm/arch-mx25/imx-regs.h | 175 ++ arch/arm/include/asm/arch-mx25/iomux-mx25.h | 25 +- arch/arm/include/asm/imx-common/iomux-v3.h | 13 +- arch/arm/lib/asm-offsets.c |9 + board/syteco/zmx25/Makefile |2 +- board/syteco/zmx25/fma1125.c| 193 ++ board/syteco/zmx25/fma1125.h| 19 + board/syteco/zmx25/lowlevel_init.S | 20 + board/syteco/zmx25/mpr121.c | 204 ++ board/syteco/zmx25/mpr121.h | 20 + board/syteco/zmx25/polytouch.c | 123 board/syteco/zmx25/polytouch.h | 19 + board/syteco/zmx25/zmx25.c | 897 +-- drivers/video/Makefile |1 + drivers/video/imx25lcdc.c | 123 include/configs/zmx25.h | 47 +- tools/logos/syteco.bmp | Bin 11414 - 11414 bytes 17 files changed, 1830 insertions(+), 60 deletions(-) create mode 100644 board/syteco/zmx25/fma1125.c create mode 100644 board/syteco/zmx25/fma1125.h create mode 100644 board/syteco/zmx25/mpr121.c create mode 100644 board/syteco/zmx25/mpr121.h create mode 100644 board/syteco/zmx25/polytouch.c create mode 100644 board/syteco/zmx25/polytouch.h create mode 100644 drivers/video/imx25lcdc.c -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] Update of the company logo
From: Thomas Diener die...@gmx.de
Signed-off-by: Thomas Diener die...@gmx.de
---
tools/logos/syteco.bmp | Bin 11414 - 11414 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/tools/logos/syteco.bmp b/tools/logos/syteco.bmp
index
9a994fe3e3812bdc2d63f7045d2740d931b2a42a..14031f2c8c5eaee2e961a89b684ac3c986329673
100644
GIT binary patch
literal 11414
zcmeI0OOD(i5Qb^bSc;U3%pU?AnW81xk)eQ1UXONtWyOB*Nc}y-K~+4JOD=kDmh5
z^Xt#QAI_(r@6LTd?h~Hh@Lb$CUypzOeh{+q5;$0xhp*P`}KOg-)^@%rcjTz^Eov*
zW8kaC!1^lb(wNpHkIIef1C2#}Ec@Wlcz9MY+T;T+f%AAT2MYgDf{X{C4Y^K
z{5=Becw{zY0Sia@NVlN=gHNFVc^q(wd-%lT4O19R|VCB879E9D7IX+K{q}aEuX-
zArOJ#7AAIPLAGjWO7(DW4SMKf%EySraLZEmO|6pS_|hnhL5_nqcKJ~4uKdL!yE@
z#KIWn=#LQ-V**F#(%^x`c3miR?U!{mM(9)oIMg8YxHmRB-Lsg73bJLD|*fmgM(t=
zM32$eGeco(Vd!5G?d?Abj`srav%nWQnu_rSv`p2kQf;di$j7WPn8UUNDhtR?_+9d
zOb!83ale~kbirX^SRlCDW7@|PgHb~{-^hVCRIWtg9dBaH?y|sp%t0U0Z?=XaE@k@
zP~SGVrd@6!B)G#2|%tw1z5jv_?bQ+g_Ji--mG!N0n?uRv*l0XnSY$s5mF)=;q`I
zqMUk=;D9V1EtsAiAO6T367x1^YsXdyaER*GLs`+i0OxnhovfoFEmCf`LvdtJ)Jg
zPt(nuap=2%ycaW@HmeHu3g*o=(IHlc;y$g0Mb5t-ID2n!+Wn4J#hMyK?KJJQsuBg
zsET^Z#Tv;GKXSO2-`D7x5}tEJV*nF0Rp{9tSVQ3fgnqYWVw#Ds04Q2qF9;tVOe
zRYt~K$vA_8ON{D_CorHzAuNQ^O#*qg44($KD8!7+B8Vw43Z9UQ4CiP3!^n_1V
zS@^+FJOd#3XG_%c4^mGAe|hNAe3!)`C0{hXeivZgS)u}7-kE{?_I$T=(3E08{p
z#n7YVE^m_{!yNJQoOfwk1jr}{9{aYVS}g||Om6noHZxK*l%%#tcPI3mVT5OUES
z;n*bgX~MzdaA?k+lB30iZKIZM4L+*vF^muoB3W0ewe00sR!ce5Sos8z`kjh=
HO-23#-#?T?
literal 11414
zcmeI0%Z=PH42HG#1PG8ua@cbU$T=w@oy;*6q@L+)mXs`;FTE_mvj`+$Vm-;vzbIOp
zpTGaTJ70docj*7zwrA7zc=^Q_v1f*zJ*`xcs`%*@pwSxpm#${eIu-^Dz~e3QPqq
zP~cWsoRbp=!%6e0_7xyYP4OUX;?@v`BYqNM)uXM3F5j;XIMfWw|7cYm)1ac^7M
zc`7S$9X#t+$oJxgPAoJxGGi`HnkfBtwoA;ZR9u;?jzeRD@naCCtPjCEmR=eG!^
zQa#o$6?*72zqx*tjm)3O-Cii`K?hHog62(Mq~7HoB}a0x;ak7h=tM3(Hiv#sH4S
zt-*xFPF-j;ofqc}3yq2ZhcZIbyZa#nZ-J!3uVH0wB!+kgJR%EA9Aq12N0O(PQ6eZ
z$UlR1A~BJAO?q0HtBQ^pBvVkAH;4hgb*DpU|ea%cHA5XnatM%u`(qfa3l0mz
z0RTB%VAF#qXYSRB?sP6xgtpp8mxKWY_v`ft;lEfTC{zc{EXkA}`|*TXPu)+dZQZ
zgA|@|G1F8VBm0_P(XUdBNj6{-geK6xd-7}#_!8sX@ZYD%W$HnK1FD!u)I1x
zeAfRI96^!Sk$B3J)NRItNOh05iELAIfp)pd)w*{-%RbN;-EZcML*E7Dy$EK2
z$8j8R?b=?CzP9E7ul#}*KeLKt!U_dGEEL2fqGb5W%s56gg}Vs-k}7Y(s!AY~2{
zgq@kJTQ#USJV*tH0RpQ?tSVR84!UwXYWVjRRoIBr5JVzIL=MTiRfCLU2dUx^iU^FJ
z{1KDStW3%NQ^#?xSH;Z($MZ;!O@pbG0K9I29A9yiP6K58OnTXurac$YB3XG_%
zc4_xmAdMW7Ahd0F0Se*g#-Qz+~i0*OpRzmOp8Kk#dnS0HU1i=ju(U3yG{baTYZ
zbK0dnB0zdMFzwrpO1JUlOuePN-phj2GYk7Fh(fS#St;if{=@D566LV9^}}v+N=(L
v-!AOjQj8HG2a6m=FVaZmJGf;QwXdp^U*bbS~I1ozV-x`b|atPencepjJ52
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: consolidate arch/arm/include/asm/arch-*/spl.h
On 04/16/2014 08:44 AM, Masahiro Yamada wrote:
arch/arm/include/asm/spl.h requires all SoCs to have
arch/arm/include/asm/arch-*/spl.h.
But many of them just define BOOT_DEVICE_* macros.
Those macros are used in the switch (boot_device) { ... }
statement in common/spl/spl.c.
So they should not be archtecture specific, but described as
a simpile enumeration.
This commit merge most of arch/arm/include/asm/arch-*/spl.h
into arch/arm/include/asm/spl.h.
With a little more effort, arch-zynq/spl.h and arch-socfpga/spl.h
will be merged, while I am not sure about OMAP and Exynos.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Tom Rini tr...@ti.com
Cc: Michal Simek michal.si...@xilinx.com
Cc: Andreas Bießmann andreas.de...@googlemail.com
Acked-by: Andreas Bießmann andreas.de...@googlemail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/3] mkconfig: Do not define CONFIG_SYS_{ARCH, CPU, SOC, VENDOR, BOARD} in config.h.
Hi Masahiro, This commit modifies mkconfig not to define CONFIG_SYS_ARCH, CONFIG_SYS_CPU, CONFIG_SYS_SOC, CONFIG_SYS_VENDOR, CONFIG_SYS_BOARD. They are still used in some board files. Tegra family, OMAP-Panda board, some Samsung boards. Add CONFIG_SYS_SOC, CONFIG_SYS_BOARD definition to their header files to keep the same behavior. For trats board: Acked-by: Lukasz Majewski l.majew...@samsung.com -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: consolidate arch/arm/include/asm/arch-*/spl.h
On Tue, Apr 15, 2014 at 11:44 PM, Masahiro Yamada
yamad...@jp.panasonic.com wrote:
arch/arm/include/asm/spl.h requires all SoCs to have
arch/arm/include/asm/arch-*/spl.h.
But many of them just define BOOT_DEVICE_* macros.
Those macros are used in the switch (boot_device) { ... }
statement in common/spl/spl.c.
So they should not be archtecture specific, but described as
a simpile enumeration.
This commit merge most of arch/arm/include/asm/arch-*/spl.h
into arch/arm/include/asm/spl.h.
With a little more effort, arch-zynq/spl.h and arch-socfpga/spl.h
will be merged, while I am not sure about OMAP and Exynos.
snip
--- a/arch/arm/include/asm/spl.h
+++ b/arch/arm/include/asm/spl.h
@@ -7,9 +7,27 @@
#ifndef_ASM_SPL_H_
#define_ASM_SPL_H_
+#if defined(CONFIG_OMAP) || defined(CONFIG_SOCFPGA) || defined(CONFIG_ZYNQ) \
+ || defined(CONFIG_EXYNOS4) || defined(CONFIG_EXYNOS5)
/* Platform-specific defines */
#include asm/arch/spl.h
+#else
+enum {
+ BOOT_DEVICE_RAM,
+ BOOT_DEVICE_MMC1,
+ BOOT_DEVICE_MMC2,
+ BOOT_DEVICE_MMC2_2,
+ BOOT_DEVICE_NAND,
+ BOOT_DEVICE_ONENAND,
+ BOOT_DEVICE_NOR,
+ BOOT_DEVICE_UART,
+ BOOT_DEVICE_SPI,
+ BOOT_DEVICE_I2C,
+ BOOT_DEVICE_NONE
+};
+#endif
+
Masahiro,
This is great! If you can add BOOT_DEVICE_SATA I can use this for imx,
then you can add my:
Acked-by: Tim Harvey thar...@gateworks.com
Thanks,
Tim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: make imxheader size align on page size
Hi Stefano, Am 2014-04-17 10:50, schrieb Stefano Babic: On 16/04/2014 15:36, Stefan Agner wrote: Can you better explain this ? There is only one board in mainline with vf610. CONFIG_SYS_TEXT_BASE is set to 0x3f008000. I cannot get the offset in your example. Are you referring to NAND page ? But if the header must be aligned with the NAND page, this is pretty bad because we have to adjust the header depending on the selected NAND chip. I do not see this limitation in the manual. I've not submitted my board yet, I altered it to use 0x3f400800 as CONFIG_SYS_TEXT_BASE. I just realize that a header length of 0x7fc doesn't fit with 0x3f400404 even though (that would be 0x3f44 if anything). But the mkimage utility reports Load Address: 3f400420 Entry Point: 3f400800 I'm a bit confused now, why is the header only 0x400 now? Ok I checked this again, the header total size is _not_ 0x7fc, thats imximage_init_loadsize, which is the header size + flash load size (0x400 for NAND). The header total size is 0x3fc (sizeof(imx_header_v2_t)) right now. This patch would make alter it to be exactly 0x400. This renforces my suspect. Making the image bigger, it seems that the SOC loads more data as before. However, reading in the manual, the initial load image (what the SOC should load initially) is 4K (Table 19.37), and adding 4 bytes should have no influence. I'm still trying to figure out what the real problem is here. I could not alter the FCB to boot the default IMX V2 image (with IVT header). Inside the FCB one can only specify the page offset where the image starts. Within that page, the Boot ROM expects a IVT header at exactly 0x400. However, on NAND, the IVT header _is_ exactly at 0x400. I also think the Boot ROM can read the IVT header but the jump to the entry point of U-Boot fails somehow. If the IVT header is not correct, the Boot ROM usually enters serial loader, in my case this doesn't happen. I have no JTAG environment ready, so I can't easily debug this. I also try shorter versions of the IVT header by alter the dcd_addr_data_t array inside dcd_v2_t. interesting is, that a total length of 0x3f8 works, while 0x3fc or 0x3f4 do not work. In case this discussion ends up adding this padding word, I will send a new patch with correct numbers and better description. It is not clear what is the cause of the issue and then which is the solution. Adding the pad at the moment seems only a work-around for you. For me it seems as if Vybrid requires the header base in memory requires to be at 8 byte boundary. Probably there is also a nicer solution enforce this rather than just extend the struct. -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/t208x: enable errata A006261, A006593, A006379
Enable errata A006261, A006593, A006379 for T208x. Additionally enable CONFIG_CMD_ERRATA for T2080RDB. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- based on 'next' branch of u-boot-mpc85xx. arch/powerpc/include/asm/config_mpc85xx.h | 3 +++ include/configs/T208xRDB.h| 1 + 2 files changed, 4 insertions(+) diff --git a/arch/powerpc/include/asm/config_mpc85xx.h b/arch/powerpc/include/asm/config_mpc85xx.h index 9bb0123..8a7d4d8 100644 --- a/arch/powerpc/include/asm/config_mpc85xx.h +++ b/arch/powerpc/include/asm/config_mpc85xx.h @@ -804,6 +804,9 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022) #define CONFIG_SYS_FSL_SFP_VER_3_0 #define CONFIG_SYS_FSL_ISBC_VER2 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111 +#define CONFIG_SYS_FSL_ERRATUM_A006261 +#define CONFIG_SYS_FSL_ERRATUM_A006593 +#define CONFIG_SYS_FSL_ERRATUM_A006379 #define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE diff --git a/include/configs/T208xRDB.h b/include/configs/T208xRDB.h index 73d82ed..ef22199 100644 --- a/include/configs/T208xRDB.h +++ b/include/configs/T208xRDB.h @@ -721,6 +721,7 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_CMD_DHCP #define CONFIG_CMD_ELF +#define CONFIG_CMD_ERRATA #define CONFIG_CMD_MII #define CONFIG_CMD_I2C #define CONFIG_CMD_PING -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] High Assurance Booting
Hello, I would like to know what changes should I make in u-boot 2013 source code to generate hab.o file in u-boot/arch/arm/cpu/armv7/mx6 directory. Regards Jyoti Dubey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] usb:gadget:f_thor: code cleanup in function download_tail()
In thor's download_tail() function, dfu_get_entity() is called
before each dfu_write() call and the returned entity pointers
are the same. So dfu_get_entity() can be called just once and
this patch changes this.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Tom Rini tr...@ti.com
---
Changes v2:
- separate fix and cleanup into two commits
Changes v3:
- download_tail(): add exit label
---
drivers/usb/gadget/f_thor.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index f5c0224..1190c74 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -204,17 +204,17 @@ static long long int download_head(unsigned long long
total,
static int download_tail(long long int left, int cnt)
{
+ struct dfu_entity *dfu_entity = dfu_get_entity(alt_setting_num);
void *transfer_buffer = dfu_get_buf();
int ret;
debug(%s: left: %llu cnt: %d\n, __func__, left, cnt);
if (left) {
- ret = dfu_write(dfu_get_entity(alt_setting_num),
- transfer_buffer, left, cnt++);
+ ret = dfu_write(dfu_entity, transfer_buffer, left, cnt++);
if (ret) {
error(DFU write failed [%d]: left: %llu, ret, left);
- return ret;
+ goto exit;
}
}
@@ -225,11 +225,11 @@ static int download_tail(long long int left, int cnt)
* This also frees memory malloc'ed by dfu_get_buf(), so no explicit
* need fo call dfu_free_buf() is needed.
*/
- ret = dfu_write(dfu_get_entity(alt_setting_num),
- transfer_buffer, 0, cnt);
+ ret = dfu_write(dfu_entity, transfer_buffer, 0, cnt);
if (ret)
error(DFU write failed [%d] cnt: %d, ret, cnt);
+exit:
return ret;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] usb:gadget:f_thor: fix write to filesystem by add dfu_flush()
Since dfu read/write operations needs to be flushed manually,
writing to filesystem on MMC by thor was broken. MMC raw write
actually is working fine because current dfu_flush() function
writes filesystem only. This commit adds dfu_flush() to f_thor
and now filesystem write is working.
This change was tested on Trats2 board.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Tom Rini tr...@ti.com
---
Changes v2:
- separate fix and cleanup into two commits
Changes v3:
- none
---
drivers/usb/gadget/f_thor.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index 1190c74..1420606 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -226,8 +226,14 @@ static int download_tail(long long int left, int cnt)
* need fo call dfu_free_buf() is needed.
*/
ret = dfu_write(dfu_entity, transfer_buffer, 0, cnt);
- if (ret)
+ if (ret) {
error(DFU write failed [%d] cnt: %d, ret, cnt);
+ goto exit;
+ }
+
+ ret = dfu_flush(dfu_entity, transfer_buffer, 0, cnt);
+ if (ret)
+ error(DFU flush failed!);
exit:
return ret;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/5] usb: musb: fill in usb_gadget_unregister_driver
Hi Rob,
From: Rob Herring r...@kernel.org
Add missing missing disconnect and unbind calls to the musb gadget
^^^ I suppose that one missing is redundant.
driver's usb_gadget_unregister_driver function. Otherwise, any gadget
drivers fail to uninitialize and run a 2nd time.
Signed-off-by: Rob Herring r...@kernel.org
---
drivers/usb/musb-new/musb_uboot.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb-new/musb_uboot.c
b/drivers/usb/musb-new/musb_uboot.c index 0512680..0d7b89f 100644
--- a/drivers/usb/musb-new/musb_uboot.c
+++ b/drivers/usb/musb-new/musb_uboot.c
@@ -204,7 +204,10 @@ int usb_gadget_register_driver(struct
usb_gadget_driver *driver)
int usb_gadget_unregister_driver(struct usb_gadget_driver *driver)
{
- /* TODO: implement me */
+ if (driver-disconnect)
+ driver-disconnect(gadget-g);
+ if (driver-unbind)
+ driver-unbind(gadget-g);
return 0;
}
#endif /* CONFIG_MUSB_GADGET */
Despite the minor problem with commit message, the rest seems correct.
Reviewed-by: Lukasz Majewski l.majew...@samsung.com
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/5] usb/gadget: add the fastboot gadget
Hi Rob,
From: Sebastian Siewior bige...@linutronix.de
This patch contains an implementation of the fastboot protocol on the
device side and documentation. This is based on USB download gadget
infrastructure. The fastboot function implements the getvar, reboot,
download and reboot commands. What is missing is the flash handling
i.e. writting the image to media.
v3 (Rob Herring):
This is based on http://patchwork.ozlabs.org/patch/126798/ with the
following changes:
- Rebase to current mainline and updates for current gadget API
- Use SPDX identifiers for licenses
- Traced the history and added missing copyright to cmd_fastboot.c
- Use load_addr/load_size for transfer buffer
- Allow vendor strings to be optional
- Set vendor/product ID from config defines
- Allow Ctrl-C to exit fastboot mode
v4:
- Major re-write to use the USB download gadget. Consolidated function
code to a single file.
- Moved globals into single struct.
- Use puts and putc as appropriate.
- Added CONFIG_USB_FASTBOOT_BUF_ADDR and CONFIG_USB_FASTBOOT_BUF_SIZE
to set the fastboot transfer buffer.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
Signed-off-by: Rob Herring r...@kernel.org
---
common/Makefile | 2 +
common/cmd_fastboot.c| 36 +++
doc/README.android-fastboot | 91 ++
doc/README.android-fastboot-protocol | 170
drivers/usb/gadget/Makefile | 1 +
drivers/usb/gadget/f_fastboot.c | 518
+++
drivers/usb/gadget/g_dnl.c | 6 +
include/fastboot.h | 22 ++ 8 files changed, 846
insertions(+) create mode 100644 common/cmd_fastboot.c
create mode 100644 doc/README.android-fastboot
create mode 100644 doc/README.android-fastboot-protocol
create mode 100644 drivers/usb/gadget/f_fastboot.c
create mode 100644 include/fastboot.h
diff --git a/common/Makefile b/common/Makefile
index da208f3..fe1d8b9 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -167,6 +167,8 @@ obj-y += cmd_usb.o
obj-y += usb.o usb_hub.o
obj-$(CONFIG_USB_STORAGE) += usb_storage.o
endif
+obj-$(CONFIG_CMD_FASTBOOT) += cmd_fastboot.o
+
obj-$(CONFIG_CMD_USB_MASS_STORAGE) += cmd_usb_mass_storage.o
obj-$(CONFIG_CMD_THOR_DOWNLOAD) += cmd_thordown.o
obj-$(CONFIG_CMD_XIMG) += cmd_ximg.o
diff --git a/common/cmd_fastboot.c b/common/cmd_fastboot.c
new file mode 100644
index 000..ce7e198
--- /dev/null
+++ b/common/cmd_fastboot.c
@@ -0,0 +1,36 @@
+/*
+ * Copyright 2008 - 2009 Windriver, www.windriver.com
+ * Author: Tom Rix tom@windriver.com
+ *
+ * (C) Copyright 2014 Linaro, Ltd.
+ * Rob Herring r...@kernel.org
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+#include common.h
+#include command.h
+#include g_dnl.h
+
+static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int argc, char
*const argv[]) +{
+ int ret;
+
+ ret = g_dnl_register(fastboot);
+ if (ret)
+ return ret;
+
+ while (1) {
+ if (ctrlc())
+ break;
+ usb_gadget_handle_interrupts();
+ }
+
+ g_dnl_unregister();
+ return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(
+ fastboot, 1, 1, do_fastboot,
+ fastboot - enter USB Fastboot protocol,
+
+);
diff --git a/doc/README.android-fastboot b/doc/README.android-fastboot
new file mode 100644
index 000..f1d128c
--- /dev/null
+++ b/doc/README.android-fastboot
@@ -0,0 +1,91 @@
+Android Fastboot
+
+
+Overview
+
+The protocol that is used over USB is described in
+README.android-fastboot-protocol in same directory.
+
+The current implementation does not yet support the flash and erase
+commands.
+
+Client installation
+===
+The counterpart to this gadget is the fastboot client which can
+be found in Android's platform/system/core repository in the fastboot
+folder. It runs on Windows, Linux and even OSX. Linux user are lucky
since +they only need libusb.
+Windows users need to bring some time until they have Android SDK
(currently +http://dl.google.com/android/installer_r12-windows.exe)
installed. You +need to install ADB package which contains the
required glue libraries for +accessing USB. Also you need Google USB
driver package and SDK platform +tools. Once installed the usb
driver is placed in your SDK folder under +extras\google\usb_driver.
The android_winusb.inf needs a line like +
+ %SingleBootLoaderInterface% = USB_Install, USB\VID_0451PID_D022
+
+either in the [Google.NTx86] section for 32bit Windows or
[Google.NTamd64] +for 64bit Windows. VID and PID should match
whatever the fastboot is +advertising.
+
+Board specific
+==
+The fastboot gadget relies on the USB download gadget, so the
following +options must be configured:
+
+CONFIG_USBDOWNLOAD_GADGET
+CONFIG_G_DNL_VENDOR_NUM
+CONFIG_G_DNL_PRODUCT_NUM
Re: [U-Boot] [RFC PATCH 1/3] env: drop CONFIG_ENV_VARS_UBOOT_CONFIG support
Hi Wolfgang, On Tue, 22 Apr 2014 14:13:44 +0200 Wolfgang Denk w...@denx.de wrote: Dear Masahiro, In message 1398159826-29398-2-git-send-email-yamad...@jp.panasonic.com you wrote: CONFIG_ENV_VARS_UBOOT_CONFIG, if defined, sets environment variables, arch, cpu, board, etc. depending on CONFIG_SYS_ARCH, CONFIG_SYS_CPU, CONFIG_SYS_BOARD, respectively. We are discussing the introduction of Kconfig. In our discussion, we found boolean CONFIG macros are more useful in Kconfig context. That is, CONFIG_ARM=y CONFIG_CPU_ARMv7=y CONFIG_BOARD_HARMONY=y CONFIG_VENDOR_NVIDIA=y rather than CONFIG_SYS_ARCH=arm CONFIG_SYS_CPU=armv7 CONFIG_SYS_BOARD=harmony CONFIG_SYS_VENDOR=nvidia I understand your intention - but does this not mean that we lose all flexibility in assigning board and vendor names? So far, we allow any kind of names, lowercase and uppercase and mixed. Will we not lose this capability? Also, we have '-' characters in a number of board names - would this not also cause trouble? Finally, I don't see what your replacement code would be to create the set of environment settigns - and I think these are needed, as some user defined scripts are processing these? The user who needs such environment setting can add them by using CONFIG_EXTRA_ENV_SETTINGS. For example, #define CONFIG_EXTRA_ENV_SETTINGS \ arch=arm\0 \ cpu=armv7\0 \ soc=tegra20\0 I am not sure this is acceptable. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Exynos5: config: Enable FIT
Adding two configs: * CONFIG_FIT - Enable FIT image support. * CONFIG_FIT_BEST_MATCH - Enable fetching correct DTB from FIT image by comparing compatibles. Signed-off-by: Akshay Saraswat aksha...@samsung.com --- include/configs/exynos5-dt.h | 4 1 file changed, 4 insertions(+) diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h index 414db42..dee53e9 100644 --- a/include/configs/exynos5-dt.h +++ b/include/configs/exynos5-dt.h @@ -288,4 +288,8 @@ #define CONFIG_CMD_BOOTZ +/* Enable FIT support and comparison */ +#define CONFIG_FIT +#define CONFIG_FIT_BEST_MATCH + #endif /* __CONFIG_H */ -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] am33xx : bit-flip correction in oob
CC-ing Pekon Gupta which add those changes in commit: 6e562b1106ea6afc78752f50925e87e9dd14f8b4 On Tue, Apr 15, 2014 at 12:47 PM, Belisko Marek marek.beli...@gmail.com wrote: Hi, we're running 2014.04-rc3 on custom am335x board (same configuration as BBB). When spl is loading u-boot from nand flash we can see a lot of messages in console: nand: bit-flip corrected @oob=0 It is always the same position (seems to be first byte in oob). Anybody experienced same problem? I've tested on 2 different flashes and result is same. I was able to track down that read ecc from gpmc return always first byte as 0xFF (in omap_calculate_ecc()) and thus function omap_correct_data_bch() always trying to repair bit-flips in first oob byte. Can this be caused by flash? Any pointers? In config we're using: #define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW #define CONFIG_NAND_OMAP_ELM BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com Thanks, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] spl: consolidate arch/arm/include/asm/arch-*/spl.h
arch/arm/include/asm/spl.h requires all SoCs to have
arch/arm/include/asm/arch-*/spl.h.
But many of them just define BOOT_DEVICE_* macros.
Those macros are used in the switch (boot_device) { ... }
statement in common/spl/spl.c.
So they should not be archtecture specific, but be described as
a simpile enumeration.
This commit merges most of arch/arm/include/asm/arch-*/spl.h
into arch/arm/include/asm/spl.h.
With a little more effort, arch-zynq/spl.h and arch-socfpga/spl.h
will be merged, while I am not sure about OMAP and Exynos.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Tom Rini tr...@ti.com
Cc: Michal Simek michal.si...@xilinx.com
Cc: Andreas Bießmann andreas.de...@googlemail.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Tom Warren twar...@nvidia.com
CC: Stefano Babic sba...@denx.de
CC: Minkyu Kang mk7.k...@samsung.com
Cc: Dinh Nguyen dingu...@altera.com
Acked-by: Andreas Bießmann andreas.de...@googlemail.com
Acked-by: Michal Simek mon...@monstr.eu
Acked-by: Stefano Babic sba...@denx.de
Acked-by: Stephen Warren swar...@nvidia.com
Acked-by: Tim Harvey thar...@gateworks.com
Tested-by: Bo Shen voice.s...@atmel.com [on sama5d3xek board for at91 part]
---
Changes in v2:
- Add BOOT_DEVICE_SATA (request from Tim Harvey)
- Add || defined(CONFIG_EXYNOS4210)
Most exynos boards define CONFIG_EXYNOS4 or CONFIG_EXYNOS5.
But there is one exception: smdkv310.
This board defines neither CONFIG_EXYNOS4 nor CONFIG_EXYNOS5.
For this board, if defined(CONFIG_EXYNOS4210) should be checked.
arch/arm/cpu/arm720t/tegra-common/spl.c | 2 +-
arch/arm/include/asm/arch-at91/spl.h | 24
arch/arm/include/asm/arch-davinci/spl.h | 16
arch/arm/include/asm/arch-mx35/spl.h | 22 --
arch/arm/include/asm/arch-mx5/spl.h | 13 -
arch/arm/include/asm/arch-tegra114/spl.h | 22 --
arch/arm/include/asm/arch-tegra124/spl.h | 13 -
arch/arm/include/asm/arch-tegra20/spl.h | 12
arch/arm/include/asm/arch-tegra30/spl.h | 12
arch/arm/include/asm/spl.h | 20
board/denx/m53evk/m53evk.c | 2 +-
11 files changed, 22 insertions(+), 136 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-at91/spl.h
delete mode 100644 arch/arm/include/asm/arch-davinci/spl.h
delete mode 100644 arch/arm/include/asm/arch-mx35/spl.h
delete mode 100644 arch/arm/include/asm/arch-mx5/spl.h
delete mode 100644 arch/arm/include/asm/arch-tegra114/spl.h
delete mode 100644 arch/arm/include/asm/arch-tegra124/spl.h
delete mode 100644 arch/arm/include/asm/arch-tegra20/spl.h
delete mode 100644 arch/arm/include/asm/arch-tegra30/spl.h
diff --git a/arch/arm/cpu/arm720t/tegra-common/spl.c
b/arch/arm/cpu/arm720t/tegra-common/spl.c
index 5171a8f..8147806 100644
--- a/arch/arm/cpu/arm720t/tegra-common/spl.c
+++ b/arch/arm/cpu/arm720t/tegra-common/spl.c
@@ -14,7 +14,7 @@
#include asm/arch/pinmux.h
#include asm/arch/tegra.h
#include asm/arch-tegra/board.h
-#include asm/arch/spl.h
+#include asm/spl.h
#include cpu.h
void spl_board_init(void)
diff --git a/arch/arm/include/asm/arch-at91/spl.h
b/arch/arm/include/asm/arch-at91/spl.h
deleted file mode 100644
index d8a87da..000
--- a/arch/arm/include/asm/arch-at91/spl.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * Copyright (C) 2013 Atmel Corporation
- * Bo Shen voice.s...@atmel.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef_ASM_ARCH_SPL_H_
-#define_ASM_ARCH_SPL_H_
-
-enum {
- BOOT_DEVICE_NONE,
-#ifdef CONFIG_SYS_USE_MMC
- BOOT_DEVICE_MMC1,
- BOOT_DEVICE_MMC2,
- BOOT_DEVICE_MMC2_2,
-#elif CONFIG_SYS_USE_NANDFLASH
- BOOT_DEVICE_NAND,
-#elif CONFIG_SYS_USE_SERIALFLASH
- BOOT_DEVICE_SPI,
-#endif
-};
-
-#endif
diff --git a/arch/arm/include/asm/arch-davinci/spl.h
b/arch/arm/include/asm/arch-davinci/spl.h
deleted file mode 100644
index 5afe0d4..000
--- a/arch/arm/include/asm/arch-davinci/spl.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/*
- * (C) Copyright 2012
- * Texas Instruments, www.ti.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-#ifndef_ASM_ARCH_SPL_H_
-#define_ASM_ARCH_SPL_H_
-
-#define BOOT_DEVICE_NAND 1
-#define BOOT_DEVICE_SPI2
-#define BOOT_DEVICE_MMC1 3
-#define BOOT_DEVICE_MMC2 4 /* dummy */
-#define BOOT_DEVICE_MMC2_2 5 /* dummy */
-
-#endif
diff --git a/arch/arm/include/asm/arch-mx35/spl.h
b/arch/arm/include/asm/arch-mx35/spl.h
deleted file mode 100644
index d0efec2..000
--- a/arch/arm/include/asm/arch-mx35/spl.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/*
- * (C) Copyright 2012
- * Texas Instruments, www.ti.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-#ifndef_ASM_ARCH_SPL_H_
-#define_ASM_ARCH_SPL_H_
-
-#define BOOT_DEVICE_NONE 0
-#define BOOT_DEVICE_XIP1
-#define BOOT_DEVICE_XIPWAIT
Re: [U-Boot] [PATCH v3 2/2] usb:gadget:f_thor: fix write to filesystem by add dfu_flush()
Hi Przemyslaw,
Since dfu read/write operations needs to be flushed manually,
writing to filesystem on MMC by thor was broken. MMC raw write
actually is working fine because current dfu_flush() function
writes filesystem only. This commit adds dfu_flush() to f_thor
and now filesystem write is working.
This change was tested on Trats2 board.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Tom Rini tr...@ti.com
---
Changes v2:
- separate fix and cleanup into two commits
Changes v3:
- none
---
drivers/usb/gadget/f_thor.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index 1190c74..1420606 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -226,8 +226,14 @@ static int download_tail(long long int left, int
cnt)
* need fo call dfu_free_buf() is needed.
*/
ret = dfu_write(dfu_entity, transfer_buffer, 0, cnt);
I think this dfu_write() call can be now removed, since what we
expect now is to call the dfu_flush() here.
After this change please accordingly update the above comment.
- if (ret)
+ if (ret) {
error(DFU write failed [%d] cnt: %d, ret, cnt);
+ goto exit;
+ }
+
+ ret = dfu_flush(dfu_entity, transfer_buffer, 0, cnt);
+ if (ret)
+ error(DFU flush failed!);
exit:
return ret;
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Revert build: Use filechk rules to create and update u-boot.lds
On Mon, Apr 21, 2014 at 11:33:07AM +0900, Masahiro Yamada wrote: This reverts commit a8b993eb81c142a439c24b871a2317f765fe5397. Commit a8b993eb claims it fixes u-boot.lds rule by replacing $(call if_changed) with $(call filechk). But the problem had already been fixed by commit 395e60cd a few days before commit a8b993eb was posted. There is no reason to apply commit a8b993eb. What is worse is $(call filechk) is too strong to fix the problem and looks weird. Date of the two patches: [1] commit 395e60cdc292dc0183c6867d34b43f14a373df55 Author: Masahiro Yamada yamad...@jp.panasonic.com AuthorDate: Wed Apr 9 20:10:43 2014 +0900 Commit: Tom Rini tr...@ti.com CommitDate: Fri Apr 11 10:08:42 2014 -0400 replaces $(call if_changed) - $(call if_changed_dep) [2] commit a8b993eb81c142a439c24b871a2317f765fe5397 Author: Jon Loeliger jon.loeli...@oracle.com AuthorDate: Tue Apr 15 16:09:37 2014 -0500 Commit: Tom Rini tr...@ti.com CommitDate: Fri Apr 18 16:14:16 2014 -0400 replaces $(call if_changed) - $(call filechk) A conflict must have happened when applying [2], but somehow it was applied, sadly. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Jon Loeliger jon.loeli...@oracle.com Cc: Andreas Bießmann andreas.de...@googlemail.com Cc: Tom Rini tr...@ti.com Whoops, 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 v3 2/2] usb:gadget:f_thor: fix write to filesystem by add dfu_flush()
On Wednesday, April 23, 2014 at 02:40:52 PM, Lukasz Majewski wrote: Hi Przemyslaw, Since dfu read/write operations needs to be flushed manually, writing to filesystem on MMC by thor was broken. MMC raw write actually is working fine because current dfu_flush() function writes filesystem only. This commit adds dfu_flush() to f_thor and now filesystem write is working. This change was tested on Trats2 board. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Marek Vasut ma...@denx.de Cc: Heiko Schocher h...@denx.de Cc: Tom Rini tr...@ti.com Please submit new patches on top of u-boot-usb/master , 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 v4 4/5] usb/gadget: add the fastboot gadget
On Wednesday, April 23, 2014 at 01:02:13 PM, Lukasz Majewski wrote:
[...]
+#include linux/usb/composite.h
+
+#ifdef CONFIG_CMD_FASTBOOT
+int fastboot_add(struct usb_configuration *c);
+#else
+static int fastboot_add(struct usb_configuration *c)
+{
+ return 0;
+}
+#endif
+
+#endif
One more remark regarding your patches.
There is an ongoing work done by Mateusz Zalega (CC'ed).
Patch series
[PATCH v4 00/13] DFU, MMC, Gadget, Goni, misc.
embracing below patch:
http://patchwork.ozlabs.org/patch/339263/
is changing the g_dnl interface.
I'm not the USB maintainer :-) (Marek Vasut is), but for me it seems
that above patches are more likely to be earlier accepted to u-boot-usb
tree.
Marek, is this a correct assumption?
Depends on Mateusz, surely we will see V5 of his set.
If Marek don't mind, I'd like to ask you to rebase yours patches on top
of Mateusz work.
btw Please learn to trim the message to only the relevant bits.
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] exynos: usb: Fix data abort on boards w/o vbus-gpio node in the DT
On Tuesday, April 22, 2014 at 07:23:49 PM, andrey.konova...@linaro.org wrote: Commit 4a271cb1b4ff doesn't take into account that fdtdec_setup_gpio() returns success when the gpio passed to it is FDT_GPIO_NONE (no gpio node found in the fdtdec_decode_gpio() call). This results in calling gpio_direction_output() on invalid gpio. For this reason executing usb start command on Arndale causes data abort in the ehci-exynos driver. Add the fdt_gpio_isvalid() check to fix that problem. Signed-off-by: Andrey Konovalov andrey.konova...@linaro.org Cc: Julius Werner jwer...@chromium.org Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com Cc: Marek Vasut ma...@denx.de Applied, thanks. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [UBOOT][PATCH] mtd: spi: fix quad bit set path
Currently, flash quad bit is set in spi_flash_validate_params and later
at the end in the same api, we write 0 to status register for few flashes,
thereby overriding the quad bit set. This fix moves the quad bit setting
outside this api in spi_flash_probe_slave
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
drivers/mtd/spi/sf_probe.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 0a46fe3..8482f08 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -197,16 +197,6 @@ static struct spi_flash *spi_flash_validate_params(struct
spi_slave *spi,
/* Go for default supported write cmd */
flash-write_cmd = CMD_PAGE_PROGRAM;
- /* Set the quad enable bit - only for quad commands */
- if ((flash-read_cmd == CMD_READ_QUAD_OUTPUT_FAST) ||
- (flash-read_cmd == CMD_READ_QUAD_IO_FAST) ||
- (flash-write_cmd == CMD_QUAD_PAGE_PROGRAM)) {
- if (spi_flash_set_qeb(flash, idcode[0])) {
- debug(SF: Fail to set QEB for %02x\n, idcode[0]);
- return NULL;
- }
- }
-
/* Read dummy_byte: dummy byte is determined based on the
* dummy cycles of a particular command.
* Fast commands - dummy_byte = dummy_cycles/8
@@ -327,6 +317,16 @@ static struct spi_flash *spi_flash_probe_slave(struct
spi_slave *spi)
if (!flash)
goto err_read_id;
+ /* Set the quad enable bit - only for quad commands */
+ if ((flash-read_cmd == CMD_READ_QUAD_OUTPUT_FAST) ||
+ (flash-read_cmd == CMD_READ_QUAD_IO_FAST) ||
+ (flash-write_cmd == CMD_QUAD_PAGE_PROGRAM)) {
+ if (spi_flash_set_qeb(flash, idcode[0])) {
+ debug(SF: Fail to set QEB for %02x\n, idcode[0]);
+ return NULL;
+ }
+ }
+
#ifdef CONFIG_OF_CONTROL
if (spi_flash_decode_fdt(gd-fdt_blob, flash)) {
debug(SF: FDT decode error\n);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 0/2] Add atmel ROM code image
This series add atmelimage support to mkimage. An atmelimage is a quite dumb image type cause it has no real header. The file is mostly unmodified but the 6'th ARM vector gets replaced by the image size to load. Heiko, I know your approach setting the vector in start.S but I think this solution is a bit smarter. We would need to patch at least 2 start.S files (arm926ejs and armv7), maybe also the arm920t one too. In fact is the conversion of executable BLOB to ROM detected executable BLOB something that should really be done afterwards as all other SoC vendors do. Andreas Bießmann (2): mkimage: add atmelimage arm:at91: enable ROM loadable atmel image arch/arm/cpu/armv7/at91/config.mk | 10 + common/image.c|1 + include/image.h |1 + spl/Makefile |5 +++ tools/Makefile|1 + tools/atmelimage.c| 88 + tools/imagetool.c |2 + tools/imagetool.h |1 + 8 files changed, 109 insertions(+) create mode 100644 arch/arm/cpu/armv7/at91/config.mk create mode 100644 tools/atmelimage.c -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 1/2] mkimage: add atmelimage
The new atmelimage converts a machine code BLOB to bootable ROM image. Atmel
ROM has no sophisticated image format, it only checks the first 7 ARM vectors.
The vectors can contain valid B or LDR opcodes, the 6'th vector contains the
image size to load. The image size must not exceed 64 KiB.
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---
common/image.c |1 +
include/image.h|1 +
tools/Makefile |1 +
tools/atmelimage.c | 88
tools/imagetool.c |2 ++
tools/imagetool.h |1 +
6 files changed, 94 insertions(+)
create mode 100644 tools/atmelimage.c
diff --git a/common/image.c b/common/image.c
index 9c6bec5..86bcd10 100644
--- a/common/image.c
+++ b/common/image.c
@@ -138,6 +138,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_STANDALONE, standalone, Standalone Program, },
{ IH_TYPE_UBLIMAGE, ublimage, Davinci UBL image,},
{ IH_TYPE_MXSIMAGE, mxsimage, Freescale MXS Boot Image,},
+ { IH_TYPE_ATMELIMAGE, atmelimage, ATMEL ROM-Boot Image,},
{ -1, , , },
};
diff --git a/include/image.h b/include/image.h
index 2508d7d..542c90d 100644
--- a/include/image.h
+++ b/include/image.h
@@ -224,6 +224,7 @@ struct lmb;
#define IH_TYPE_KERNEL_NOLOAD 14 /* OS Kernel Image, can run from any
load address */
#define IH_TYPE_PBLIMAGE 15 /* Freescale PBL Boot Image */
#define IH_TYPE_MXSIMAGE 16 /* Freescale MXSBoot Image */
+#define IH_TYPE_ATMELIMAGE 17 /* ATMEL ROM bootable Image */
/*
* Compression Types
diff --git a/tools/Makefile b/tools/Makefile
index c34df4f..003727e 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -69,6 +69,7 @@ RSA_OBJS-$(CONFIG_FIT_SIGNATURE) := rsa-sign.o rsa-verify.o
rsa-checksum.o
# common objs for dumpimage and mkimage
dumpimage-mkimage-objs := aisimage.o \
+ atmelimage.o \
$(FIT_SIG_OBJS-y) \
crc32.o \
default_image.o \
diff --git a/tools/atmelimage.c b/tools/atmelimage.c
new file mode 100644
index 000..21436d3
--- /dev/null
+++ b/tools/atmelimage.c
@@ -0,0 +1,88 @@
+/*
+ * (C) Copyright 2014
+ * Andreas Bießmann andreas.de...@googlemail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include imagetool.h
+#include image.h
+
+static int atmel_check_image_type(uint8_t type)
+{
+ if (type == IH_TYPE_ATMELIMAGE)
+ return EXIT_SUCCESS;
+ else
+ return EXIT_FAILURE;
+}
+
+static int atmel_verify_header(unsigned char *ptr, int image_size,
+ struct image_tool_params *params)
+{
+ uint32_t *ints = (uint32_t *)ptr;
+ size_t pos;
+
+ /* The size must not exceed 64 Kbytes */
+ if (image_size = 64 * 1024)
+ return 1;
+
+ for (pos = 0; pos 7; pos++) {
+ /*
+* all vectors except the 6'th one must contain valid
+* LDR or B Opcode
+*/
+ if (pos == 5)
+ /* 6'th vector has image size set, check later */
+ continue;
+ if ((ints[pos] 0xff00) == 0xea00)
+ /* valid B Opcode */
+ continue;
+ if ((ints[pos] 0xf000) == 0xe59ff000)
+ /* valid LDR (I=0, P=1, U=1, B=0, W=0, L=1) */
+ continue;
+ /* ouch, one of the checks has missed ... */
+ return 1;
+ }
+ return ints[5] != image_size;
+}
+
+static void atmel_print_header(const void *ptr)
+{
+ printf(Image Type: ATMEL ROM-Boot Image\n);
+}
+
+static void atmel_set_header(void *ptr, struct stat *sbuf, int ifd,
+ struct image_tool_params *params)
+{
+ /* just save the image size into 6'th interrupt vector */
+ uint32_t *ints = (uint32_t *)ptr;
+
+ /* The size must not exceed 64 Kbytes */
+ if (sbuf-st_size 64 * 1024)
+ ints[5] = sbuf-st_size;
+}
+
+static int atmel_check_params(struct image_tool_params *params)
+{
+ return !(!params-eflag
+ !params-fflag
+ !params-xflag
+ ((params-dflag !params-lflag) ||
+(params-lflag !params-dflag)));
+}
+
+static struct image_type_params atmelimage_params = {
+ .name = ATMEL ROM-Boot Image support,
+ .header_size= 0,
+ .hdr= NULL,
+ .check_image_type = atmel_check_image_type,
+ .verify_header = atmel_verify_header,
+ .print_header = atmel_print_header,
+ .set_header = atmel_set_header,
+ .check_params = atmel_check_params,
+};
+
+void init_atmel_image_type(void)
+{
+ register_image_type(atmelimage_params);
+}
[U-Boot] [RFC PATCH 2/2] arm:at91: enable ROM loadable atmel image
For sama5d3xek we need to modify the SPL image for correct detection by ROM code. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- arch/arm/cpu/armv7/at91/config.mk | 10 ++ spl/Makefile |5 + 2 files changed, 15 insertions(+) create mode 100644 arch/arm/cpu/armv7/at91/config.mk diff --git a/arch/arm/cpu/armv7/at91/config.mk b/arch/arm/cpu/armv7/at91/config.mk new file mode 100644 index 000..09eab70 --- /dev/null +++ b/arch/arm/cpu/armv7/at91/config.mk @@ -0,0 +1,10 @@ +# +# Copyright (C) 2014, Andreas Bießmann andreas.de...@googlemail.com +# +# SPDX-License-Identifier: GPL-2.0+ +# +ifdef CONFIG_SPL_BUILD +ALL-y += boot.bin +else +ALL-y += u-boot.img +endif diff --git a/spl/Makefile b/spl/Makefile index 6fec252..031bf54 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -182,6 +182,11 @@ MKIMAGEFLAGS_MLO.byteswap = -T omapimage -n byteswap -a $(CONFIG_SPL_TEXT_BASE) MLO MLO.byteswap: $(obj)/u-boot-spl.bin $(call if_changed,mkimage) +MKIMAGEFLAGS_boot.bin = -T atmelimage + +boot.bin: $(obj)/u-boot-spl.bin + $(call if_changed,mkimage) + ALL-y += $(obj)/$(SPL_BIN).bin ifdef CONFIG_SAMSUNG -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/5] Android Fastboot support
On Mon, Apr 21, 2014 at 10:13 AM, Marek Vasut ma...@denx.de wrote: On Friday, April 18, 2014 at 06:14:26 PM, Wolfgang Denk wrote: Dear Rob, In message 1397829272-22266-1-git-send-email-robherri...@gmail.com you wrote: [...] ...I don't see the README in the list of modified files - but new CONFIG options _must_ be documented there. So please add the missing documentation. I reviewed the patches again. I am with WD on this, please add the changes to the README file. Okay, will do. Other than that, I applied 1/5 and 3/5 now as they are clearly fixes and can go in. Please rebase on top of u-boot-usb/master and re-submit the rest. It does not appear you have pushed out those 2 patches to your tree. Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sandbox: move source files from board/ to arch/sandbox/
Hi Masahiro,
On 21 April 2014 19:00, Masahiro Yamada yamad...@jp.panasonic.com wrote:
Hi Simon,
On Mon, 21 Apr 2014 15:02:20 -0600
Simon Glass s...@chromium.org wrote:
Hi Masahiro,
On 21 April 2014 03:39, Masahiro Yamada yamad...@jp.panasonic.com wrote:
Prior to commit 33a02da0, all boards must have board/${BOARD}/
or board/${VENDOR}/${BOARD}/ directory.
Now this rule is obsolete.
It looks weird that sandbox defines vendor and board just for
meeting the old U-Boot directory structure.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Simon Glass s...@chromium.org
---
Simon,
I moved board/sandbox/sandbox/sandbox.c to arch/sandbox/lib/sandbox.c
But if there is a more suitable place or file-name, please move.
I like the README move, but I worry about not having a sandbox board,
from the point of view of discoverability. How will people find it?
I am not sure if this is necessary.
I just personaly thought the board directory seems odd for Sandbox
because it is not a real board.
If you don't like this patch, feel free to reject it.
I think it is better to have board/sandbox. Is it possible to have a
null vendor, so we don't need board/sandbox/sandbox?
Regards,
Simon
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] u-boot-mips/master
On Sun, Apr 20, 2014 at 01:28:53PM +0200, Daniel Schwierzeck wrote: The following changes since commit b149c4c399b111cec1ff7505ca9fabbeeb4fe394: ARM:tegra20: Remove aes debug prints (2014-04-18 16:14:17 -0400) are available in the git repository at: git://git.denx.de/u-boot-mips.git master for you to fetch changes up to ed638b6af2e9089bc998500db7e9c655c02c2493: MAKEALL: remove hard-coded MIPS boards (2014-04-20 13:16:43 +0200) Daniel Schwierzeck (3): MIPS: always keep all sections in u-boot ELF binary. MIPS: drop incaip board MAKEALL: remove hard-coded MIPS boards Masahiro Yamada (2): mips: xburst: remove remainders of dead board cosmetic: README: add some entries to Directory Hierarchy Paul Burton (7): MIPS: stub interrupt_init function MIPS: move mips_io_port_base out of board.c MIPS: define __init_end in u-boot.lds board_f: call init_func_ram on MIPS board_f: call timer_init on MIPS MIPS: allow use of generic board MIPS: Malta: convert to generic board 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] tools: make imxheader size align on page size
Hi Stefan, On 23/04/2014 04:34, Stefan Agner wrote: The header total size is 0x3fc (sizeof(imx_header_v2_t)) right now. This patch would make alter it to be exactly 0x400. This renforces my suspect. Making the image bigger, it seems that the SOC loads more data as before. However, reading in the manual, the initial load image (what the SOC should load initially) is 4K (Table 19.37), and adding 4 bytes should have no influence. I'm still trying to figure out what the real problem is here. I could not alter the FCB to boot the default IMX V2 image (with IVT header). Inside the FCB one can only specify the page offset where the image starts. Within that page, the Boot ROM expects a IVT header at exactly 0x400. However, on NAND, the IVT header _is_ exactly at 0x400. I also think the Boot ROM can read the IVT header but the jump to the entry point of U-Boot fails somehow. If the IVT header is not correct, the Boot ROM usually enters serial loader, in my case this doesn't happen. I have no JTAG environment ready, so I can't easily debug this. That is true - another possible cause could be that for some unknown reason to us, the IVT header is read but reading the whole U-Boot image fails. We could also know if the IVT header is read and parsed correctly if the DRAM controller is set up even when boot fails. That means that the DCD data is read and applied. Rather I have no idea how to proof this without a JTAG debugger. I also try shorter versions of the IVT header by alter the dcd_addr_data_t array inside dcd_v2_t. interesting is, that a total length of 0x3f8 works, while 0x3fc or 0x3f4 do not work. Strange enough - sure I have seen not 8-byte alignment on other i.MXes. In case this discussion ends up adding this padding word, I will send a new patch with correct numbers and better description. It is not clear what is the cause of the issue and then which is the solution. Adding the pad at the moment seems only a work-around for you. For me it seems as if Vybrid requires the header base in memory requires to be at 8 byte boundary. Probably there is also a nicer solution enforce this rather than just extend the struct. Have you tried to ask Freescale about this issue ? It is quite strage and it seems Vybrid-related. 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 07/11] MX6: use macro building for MX6Q/MX6DL iomux regs
Hi Tim,
On 09/04/2014 17:46, Tim Harvey wrote:
On Wed, Apr 9, 2014 at 7:57 AM, Nikita Kiryanov nik...@compulab.co.il wrote:
Hi Tim,
On 04/03/2014 09:01 AM, Tim Harvey wrote:
This is an attempt at using a macro to allow mx6dl-ddr.h and
mx6q-ddr.h registers to be used together which is needed for an SPL
bootloader
that can run on either CPU's and must configure MMDC iomux dynamically.
I am trying to come up with a solution similar to Eric's approach with the
similar issue regarding IMX pinmux but this approach is broken in that
imximage
will choke on the cfgtmp file due to the fact that the pre-processor won't
use the enum's as it did the #defines. I'm looking for some positive
suggestions here or perhaps someone else can come up with a solution for
this
particular issue which I haven't been able to resolve.
It seems that this patch breaks all other boards. I tried myself and
after preprocessing the .cfg file, the resulting file contains
structures that mkimage cannot process.
For example, building udoo:
MKIMAGE u-boot.imx
Invalid imximage commands Type - valid names are: BOOT_FROM,
BOOT_OFFSET, DATA, CSF, IMAGE_VERSION
Error: board/udoo/udoo.cfg.cfgtmp[44] - Invalid command(struct)
In fact, board/udoo/udoo.cfg.cfgtmp contains the structures from
/mx6-ddr.h (this patch):
# 15 include/config.h 2
# 23 board/udoo/udoo.cfg 2
# 1
/home/stefano/Projects/imx/u-boot-imx/arch/arm/include/asm/arch/mx6-ddr.h
1
# 15
/home/stefano/Projects/imx/u-boot-imx/arch/arm/include/asm/arch/mx6-ddr.h
struct mx6_mmdc_ioregs {
u32 mmdc_dram_dqm0;
u32 mmdc_dram_dqm1;
u32 mmdc_dram_dqm2;
u32 mmdc_dram_dqm3;
u32 mmdc_dram_dqm4;
u32 mmdc_dram_dqm5;
u32 mmdc_dram_dqm6;
u32 mmdc_dram_dqm7;
u32 mmdc_dram_cas;
u32 mmdc_dram_ras;
and then mkimage stops.
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] tools: make imxheader size align on page size
Hi Stefano, Am 2014-04-23 17:19, schrieb Stefano Babic: Hi Stefan, On 23/04/2014 04:34, Stefan Agner wrote: The header total size is 0x3fc (sizeof(imx_header_v2_t)) right now. This patch would make alter it to be exactly 0x400. This renforces my suspect. Making the image bigger, it seems that the SOC loads more data as before. However, reading in the manual, the initial load image (what the SOC should load initially) is 4K (Table 19.37), and adding 4 bytes should have no influence. I'm still trying to figure out what the real problem is here. I could not alter the FCB to boot the default IMX V2 image (with IVT header). Inside the FCB one can only specify the page offset where the image starts. Within that page, the Boot ROM expects a IVT header at exactly 0x400. However, on NAND, the IVT header _is_ exactly at 0x400. I also think the Boot ROM can read the IVT header but the jump to the entry point of U-Boot fails somehow. If the IVT header is not correct, the Boot ROM usually enters serial loader, in my case this doesn't happen. I have no JTAG environment ready, so I can't easily debug this. That is true - another possible cause could be that for some unknown reason to us, the IVT header is read but reading the whole U-Boot image fails. We could also know if the IVT header is read and parsed correctly if the DRAM controller is set up even when boot fails. That means that the DCD data is read and applied. Rather I have no idea how to proof this without a JTAG debugger. FYI, on Vybrid, there is enough internal RAM for U-Boot. I don't have to use a DCD table to setup the DRAM controller. I also try shorter versions of the IVT header by alter the dcd_addr_data_t array inside dcd_v2_t. interesting is, that a total length of 0x3f8 works, while 0x3fc or 0x3f4 do not work. Strange enough - sure I have seen not 8-byte alignment on other i.MXes. I forgot to mention: This issue is _only_ when booting from NAND. I can load and run the very same image using serial loader (over USB or UART). The JUMP command that the serial loader sends at the end jumps to ...404 (IVT Header start in Memory). Also booting from SD-Card works with all images. This isolates the problem to the NAND image loader part of the ROM. The fact that Vybrid's NAND peripheral is not the same as on other i.MXes goes well with that assumption too (since other i.MXes don't have that limitation). In case this discussion ends up adding this padding word, I will send a new patch with correct numbers and better description. It is not clear what is the cause of the issue and then which is the solution. Adding the pad at the moment seems only a work-around for you. For me it seems as if Vybrid requires the header base in memory requires to be at 8 byte boundary. Probably there is also a nicer solution enforce this rather than just extend the struct. Have you tried to ask Freescale about this issue ? It is quite strage and it seems Vybrid-related. No not yet. I need to setup an example. However, in the end they will not change the ROM anyway, especially not on Vybrids already delivered ;-) -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Exynos5: config: Enable FIT
On 23 April 2014 06:05, Akshay Saraswat aksha...@samsung.com wrote: Adding two configs: * CONFIG_FIT - Enable FIT image support. * CONFIG_FIT_BEST_MATCH - Enable fetching correct DTB from FIT image by comparing compatibles. Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] env: drop CONFIG_ENV_VARS_UBOOT_CONFIG support
On 04/23/2014 06:03 AM, Masahiro Yamada wrote: On Tue, 22 Apr 2014 14:13:44 +0200 Wolfgang Denk w...@denx.de wrote: In message 1398159826-29398-2-git-send-email-yamad...@jp.panasonic.com you wrote: CONFIG_ENV_VARS_UBOOT_CONFIG, if defined, sets environment variables, arch, cpu, board, etc. depending on CONFIG_SYS_ARCH, CONFIG_SYS_CPU, CONFIG_SYS_BOARD, respectively. We are discussing the introduction of Kconfig. In our discussion, we found boolean CONFIG macros are more useful in Kconfig context. That is, CONFIG_ARM=y CONFIG_CPU_ARMv7=y CONFIG_BOARD_HARMONY=y CONFIG_VENDOR_NVIDIA=y rather than CONFIG_SYS_ARCH=arm CONFIG_SYS_CPU=armv7 CONFIG_SYS_BOARD=harmony CONFIG_SYS_VENDOR=nvidia I understand your intention - but does this not mean that we lose all flexibility in assigning board and vendor names? So far, we allow any kind of names, lowercase and uppercase and mixed. Will we not lose this capability? Also, we have '-' characters in a number of board names - would this not also cause trouble? Finally, I don't see what your replacement code would be to create the set of environment settigns - and I think these are needed, as some user defined scripts are processing these? The user who needs such environment setting can add them by using CONFIG_EXTRA_ENV_SETTINGS. For example, #define CONFIG_EXTRA_ENV_SETTINGS \ arch=arm\0 \ cpu=armv7\0 \ soc=tegra20\0 I am not sure this is acceptable. Right now, we get the values set up automatically for free. It seems like a regression to force the board maintainer to set these all up manually instead. Kconfig supports string variables. The Linux kernel stores the ARM debug_ll include filename in one for example. Perhaps using that technique would resolve the issue. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: vf610: add DDR_SEL_PAD_CONTR register
From: Stefan Agner ste...@agner.ch Set DDR_SEL_PAD_CONTR register explicitly to DDR3 which solves RAM issues with newer silicon (1.1). This register was added in revision 4 of the Vybrid Reference Manual. Signed-off-by: Stefan Agner ste...@agner.ch --- arch/arm/include/asm/arch-vf610/imx-regs.h | 1 + board/freescale/vf610twr/vf610twr.c| 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h b/arch/arm/include/asm/arch-vf610/imx-regs.h index c2f9761..0c28e1b 100644 --- a/arch/arm/include/asm/arch-vf610/imx-regs.h +++ b/arch/arm/include/asm/arch-vf610/imx-regs.h @@ -215,6 +215,7 @@ #define DDRMC_CR139_PHY_WRLV_EN(v) ((v) 0xff) #define DDRMC_CR154_PAD_ZQ_EARLY_CMP_EN_TIMER(v) (((v) 0x1f) 27) #define DDRMC_CR154_PAD_ZQ_MODE(v) (((v) 0x3) 21) +#define DDRMC_CR154_DDR_SEL_PAD_CONTR(v) (((v) 0x3) 18) #define DDRMC_CR155_AXI0_AWCACHE (1 10) #define DDRMC_CR155_PAD_ODT_BYTE1(v) ((v) 0x7) #define DDRMC_CR158_TWR(v) ((v) 0x3f) diff --git a/board/freescale/vf610twr/vf610twr.c b/board/freescale/vf610twr/vf610twr.c index 4ee74c0..d64d3aa 100644 --- a/board/freescale/vf610twr/vf610twr.c +++ b/board/freescale/vf610twr/vf610twr.c @@ -217,7 +217,8 @@ void ddr_ctrl_init(void) ddrmr-cr[139]); writel(DDRMC_CR154_PAD_ZQ_EARLY_CMP_EN_TIMER(13) | - DDRMC_CR154_PAD_ZQ_MODE(1), ddrmr-cr[154]); + DDRMC_CR154_PAD_ZQ_MODE(1) | + DDRMC_CR154_DDR_SEL_PAD_CONTR(3), ddrmr-cr[154]); writel(DDRMC_CR155_AXI0_AWCACHE | DDRMC_CR155_PAD_ODT_BYTE1(2), ddrmr-cr[155]); writel(DDRMC_CR158_TWR(6), ddrmr-cr[158]); -- 1.9.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spl: consolidate arch/arm/include/asm/arch-*/spl.h
On 04/23/2014 06:20 AM, Masahiro Yamada wrote:
arch/arm/include/asm/spl.h requires all SoCs to have
arch/arm/include/asm/arch-*/spl.h.
But many of them just define BOOT_DEVICE_* macros.
Those macros are used in the switch (boot_device) { ... }
statement in common/spl/spl.c.
So they should not be archtecture specific, but be described as
a simpile enumeration.
This commit merges most of arch/arm/include/asm/arch-*/spl.h
into arch/arm/include/asm/spl.h.
With a little more effort, arch-zynq/spl.h and arch-socfpga/spl.h
will be merged, while I am not sure about OMAP and Exynos.
Acked-by: Stephen Warren swar...@nvidia.com
(Not that I'm the Tegra maintainer)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] boards.cfg: update highbank maintainer email
From: Rob Herring r...@kernel.org My Calxeda email is gone, so update my email address. Signed-off-by: Rob Herring r...@kernel.org --- boards.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boards.cfg b/boards.cfg index b4203f1..d6eb3ea 100644 --- a/boards.cfg +++ b/boards.cfg @@ -293,7 +293,7 @@ Active arm armv7 exynos samsung smdkv310 Active arm armv7 exynos samsung trats trats- Lukasz Majewski l.majew...@samsung.com Active arm armv7 exynos samsung trats2 trats2 - Piotr Wilczek p.wilc...@samsung.com Active arm armv7 exynos samsung universal_c210 s5pc210_universal- Przemyslaw Marczak p.marc...@samsung.com -Active arm armv7 highbank- highbank highbank - Rob Herring rob.herr...@calxeda.com +Active arm armv7 highbank- highbank highbank - Rob Herring r...@kernel.org Active arm armv7 mx5 denxm53evk m53evk m53evk:IMX_CONFIG=board/denx/m53evk/imximage.cfg Marek Vasut marek.va...@gmail.com Active arm armv7 mx5 esg ima3-mx53 ima3-mx53 ima3-mx53:IMX_CONFIG=board/esg/ima3-mx53/imximage.cfg - Active arm armv7 mx5 freescale mx51evk mx51evk mx51evk:IMX_CONFIG=board/freescale/mx51evk/imximage.cfg Stefano Babic sba...@denx.de -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/5] Android Fastboot support
On Wednesday, April 23, 2014 at 04:36:04 PM, Rob Herring wrote: On Mon, Apr 21, 2014 at 10:13 AM, Marek Vasut ma...@denx.de wrote: On Friday, April 18, 2014 at 06:14:26 PM, Wolfgang Denk wrote: Dear Rob, In message 1397829272-22266-1-git-send-email-robherri...@gmail.com you wrote: [...] ...I don't see the README in the list of modified files - but new CONFIG options _must_ be documented there. So please add the missing documentation. I reviewed the patches again. I am with WD on this, please add the changes to the README file. Okay, will do. Other than that, I applied 1/5 and 3/5 now as they are clearly fixes and can go in. Please rebase on top of u-boot-usb/master and re-submit the rest. It does not appear you have pushed out those 2 patches to your tree. Fixed, thanks for bringing this to my attention. 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 07/11] MX6: use macro building for MX6Q/MX6DL iomux regs
Hi Tim, hi Nikita, On 10/04/2014 16:08, Nikita Kiryanov wrote: The cfg files are currently all written to use the IOMUX register names as MX6_ (no Q vs DL) so that a single cfg file can be used for a build-time configuration of IMX6Q or IMX6DL. OK now I understand. It seems to me that you only have this problem because you are using these address #defines as values for mx6_mmdc_ioregs structs to define a register mapping. You can also define this mapping by using a struct template that matches the register layout and a base address, both of which change between CPU types. Reason to do in this way is the thought that the layout among the processsors can be completely different, thing that for other area is also true. This was discussed also in a previous RFC by Eric: http://lists.denx.de/pipermail/u-boot/2013-November/15.html Tim, what about to repost in your patchset Eric's patch ? It completes your patchset and add documentation that is now missing (added Eric in CC if he will complain about this..) However, if we can recognize the same layout for all three variations (I have only check some registers in 6Q and 6DL layout), using the same structure with a different base address can be even more readable. I admit I have not checked deeply, but it seems at first glance that mx6dq_ctrl and mx6sdl_ctrl in 7/11 share the same layout. You can find an example of this in the Wandboard SPL implementation. It's not in mainline ATM so you'll have to download their BSP. The template + base addr method also doesn't use up additional memory to define this layout, which is a point in its favor. If the layout is exactly the same, you could make the structure available to all imx6 flavors. 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 10/11] ventana: auto-configure for IMX6Q vs IMX6DL
On 03/04/2014 08:01, Tim Harvey wrote:
use the new iomux function and a macro to create a multi-dimensional array
of iomux values without duplicating the defintions.
Signed-off-by: Tim Harvey thar...@gateworks.com
---
board/gateworks/gw_ventana/gw_ventana.c | 497
1 file changed, 316 insertions(+), 181 deletions(-)
diff --git a/board/gateworks/gw_ventana/gw_ventana.c
b/board/gateworks/gw_ventana/gw_ventana.c
index 2113740..ebf7e7d 100644
--- a/board/gateworks/gw_ventana/gw_ventana.c
+++ b/board/gateworks/gw_ventana/gw_ventana.c
@@ -40,6 +40,17 @@
DECLARE_GLOBAL_DATA_PTR;
+#define IOMUX(x) (MX6Q_##x), (MX6DL_##x)
+#define SETUP_PAD(def) \
+if (is_cpu_type(MXC_CPU_MX6Q)) { \
+ imx_iomux_v3_setup_pad(MX6Q_##def); \
+} else { \
+ imx_iomux_v3_setup_pad(MX6DL_##def); \
+}
This macro should be available for other boards, too.
+#define SETUP_PADS(x) \
+ imx_iomux_v3_setup_multiple_pads_array(x, \
+ ARRAY_SIZE(x)/2, is_cpu_type(MXC_CPU_MX6Q) ? 0 : 1, 2)
+
/* GPIO's common to all baseboards */
#define GP_PHY_RST IMX_GPIO_NR(1, 30)
#define GP_USB_OTG_PWR IMX_GPIO_NR(3, 22)
@@ -94,109 +105,145 @@ int board_type;
/* UART1: Function varies per baseboard */
iomux_v3_cfg_t const uart1_pads[] = {
- MX6_PAD_SD3_DAT6__UART1_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
- MX6_PAD_SD3_DAT7__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
+ IOMUX(PAD_SD3_DAT6__UART1_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
+ IOMUX(PAD_SD3_DAT7__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
};
/* UART2: Serial Console */
iomux_v3_cfg_t const uart2_pads[] = {
- MX6_PAD_SD4_DAT7__UART2_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
- MX6_PAD_SD4_DAT4__UART2_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
+ IOMUX(PAD_SD4_DAT7__UART2_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
+ IOMUX(PAD_SD4_DAT4__UART2_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
};
#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
/* I2C1: GSC */
-struct i2c_pads_info i2c_pad_info0 = {
+struct i2c_pads_info mx6q_i2c_pad_info0 = {
.scl = {
- .i2c_mode = MX6_PAD_EIM_D21__I2C1_SCL | PC,
- .gpio_mode = MX6_PAD_EIM_D21__GPIO3_IO21 | PC,
+ .i2c_mode = MX6Q_PAD_EIM_D21__I2C1_SCL | PC,
+ .gpio_mode = MX6Q_PAD_EIM_D21__GPIO3_IO21 | PC,
What have you changed here ?
.gp = IMX_GPIO_NR(3, 21)
},
.sda = {
- .i2c_mode = MX6_PAD_EIM_D28__I2C1_SDA | PC,
- .gpio_mode = MX6_PAD_EIM_D28__GPIO3_IO28 | PC,
+ .i2c_mode = MX6Q_PAD_EIM_D28__I2C1_SDA | PC,
+ .gpio_mode = MX6Q_PAD_EIM_D28__GPIO3_IO28 | PC,
+ .gp = IMX_GPIO_NR(3, 28)
+ }
+};
+struct i2c_pads_info mx6dl_i2c_pad_info0 = {
+ .scl = {
+ .i2c_mode = MX6DL_PAD_EIM_D21__I2C1_SCL | PC,
+ .gpio_mode = MX6DL_PAD_EIM_D21__GPIO3_IO21 | PC,
+ .gp = IMX_GPIO_NR(3, 21)
+ },
+ .sda = {
+ .i2c_mode = MX6DL_PAD_EIM_D28__I2C1_SDA | PC,
+ .gpio_mode = MX6DL_PAD_EIM_D28__GPIO3_IO28 | PC,
.gp = IMX_GPIO_NR(3, 28)
}
};
/* I2C2: PMIC/PCIe Switch/PCIe Clock/Mezz */
-struct i2c_pads_info i2c_pad_info1 = {
+struct i2c_pads_info mx6q_i2c_pad_info1 = {
+ .scl = {
+ .i2c_mode = MX6Q_PAD_KEY_COL3__I2C2_SCL | PC,
+ .gpio_mode = MX6Q_PAD_KEY_COL3__GPIO4_IO12 | PC,
+ .gp = IMX_GPIO_NR(4, 12)
+ },
+ .sda = {
+ .i2c_mode = MX6Q_PAD_KEY_ROW3__I2C2_SDA | PC,
+ .gpio_mode = MX6Q_PAD_KEY_ROW3__GPIO4_IO13 | PC,
+ .gp = IMX_GPIO_NR(4, 13)
+ }
+};
+struct i2c_pads_info mx6dl_i2c_pad_info1 = {
.scl = {
- .i2c_mode = MX6_PAD_KEY_COL3__I2C2_SCL | PC,
- .gpio_mode = MX6_PAD_KEY_COL3__GPIO4_IO12 | PC,
+ .i2c_mode = MX6DL_PAD_KEY_COL3__I2C2_SCL | PC,
+ .gpio_mode = MX6DL_PAD_KEY_COL3__GPIO4_IO12 | PC,
.gp = IMX_GPIO_NR(4, 12)
},
.sda = {
- .i2c_mode = MX6_PAD_KEY_ROW3__I2C2_SDA | PC,
- .gpio_mode = MX6_PAD_KEY_ROW3__GPIO4_IO13 | PC,
+ .i2c_mode = MX6DL_PAD_KEY_ROW3__I2C2_SDA | PC,
+ .gpio_mode = MX6DL_PAD_KEY_ROW3__GPIO4_IO13 | PC,
.gp = IMX_GPIO_NR(4, 13)
}
};
/* I2C3: Misc/Expansion */
-struct i2c_pads_info i2c_pad_info2 = {
+struct i2c_pads_info mx6q_i2c_pad_info2 = {
.scl = {
- .i2c_mode = MX6_PAD_GPIO_3__I2C3_SCL | PC,
- .gpio_mode = MX6_PAD_GPIO_3__GPIO1_IO03 | PC,
+ .i2c_mode = MX6Q_PAD_GPIO_3__I2C3_SCL | PC,
+ .gpio_mode = MX6Q_PAD_GPIO_3__GPIO1_IO03 | PC,
.gp = IMX_GPIO_NR(1, 3)
},
.sda = {
- .i2c_mode = MX6_PAD_GPIO_6__I2C3_SDA | PC,
- .gpio_mode = MX6_PAD_GPIO_6__GPIO1_IO06 | PC,
+ .i2c_mode =
Re: [U-Boot] [PATCH 11/11] ventana: switch to SPL
Hi Tim, On 03/04/2014 08:01, Tim Harvey wrote: Switch to an SPL image. The SPL for Ventana does the following: - setup i2c and read the factory programmed EEPROM to obtain DRAM config and model for board-specific calibration data - configure DRAM per CPU/size/layout/devices/calibration - load u-boot.img from NAND and jump to it This allows for a single SPL+u-boot.img to replace the previous multiple board configurations. Signed-off-by: Tim Harvey thar...@gateworks.com --- board/gateworks/gw_ventana/Makefile | 2 +- board/gateworks/gw_ventana/README | 91 +++--- board/gateworks/gw_ventana/gw_ventana.c | 5 +- board/gateworks/gw_ventana/gw_ventana.cfg | 15 - board/gateworks/gw_ventana/gw_ventana_spl.c | 394 ++ board/gateworks/gw_ventana/gw_ventana_spl.cfg | 29 ++ boards.cfg| 6 +- include/config/uboot.release | 1 + include/configs/gw_ventana.h | 13 +- 9 files changed, 500 insertions(+), 56 deletions(-) create mode 100644 board/gateworks/gw_ventana/gw_ventana_spl.c create mode 100644 board/gateworks/gw_ventana/gw_ventana_spl.cfg create mode 100644 include/config/uboot.release diff --git a/board/gateworks/gw_ventana/Makefile b/board/gateworks/gw_ventana/Makefile index e8dab89..8b239ae 100644 --- a/board/gateworks/gw_ventana/Makefile +++ b/board/gateworks/gw_ventana/Makefile @@ -6,5 +6,5 @@ # SPDX-License-Identifier: GPL-2.0+ # -obj-y := gw_ventana.o gsc.o +obj-y := gw_ventana.o gsc.o gw_ventana_spl.o I think that gw_ventana_spl.o is always built. Should we use instead : obj-$(CONFIG_SPL_BUILD) += gw_ventana_spl.o diff --git a/board/gateworks/gw_ventana/README b/board/gateworks/gw_ventana/README index 9e697d6..c45d4b8 100644 --- a/board/gateworks/gw_ventana/README +++ b/board/gateworks/gw_ventana/README @@ -3,53 +3,80 @@ U-Boot for the Gateworks Ventana Product Family boards This file contains information for the port of U-Boot to the Gateworks Ventana Product family boards. -1. Boot source, boot from NAND +1. Secondary Program Loader (SPL) +- + +The i.MX6 has a BOOT ROM PPL (Primary Program Loader) which supports loading +an executable image from various boot devices. + +The Gateworks Ventana board config uses an SPL build configuration. This +will build the following artifacts from u-boot source: + - SPL - Secondary Program Loader that the i.MX6 BOOT ROM (Primary Program + Loader) boots. This detects CPU/DRAM configuration, configures + The DRAM controller, loads u-boot.img from the detected boot device, + and jumps to it. As this is booted from the PPL, it has an IVT/DCD + table. + - u-boot.img - The main u-boot core which is u-boot.bin with a image header. + + +2. Build + + +To build U-Boot for the Gateworks Ventana product family: + + make gwventana_config + make + + +3. Boot source, boot from NAND -- The i.MX6 BOOT ROM expects some structures that provide details of NAND layout and bad block information (referred to as 'bootstreams') which are replicated -multiple times in NAND. The number of replications is configurable through -board strapping options and eFUSE settings. The Freescale 'kobs-ng' -application from the Freescale LTIB BSP, which runs under Linux, must be used -to program the bootstream in order to setup the replicated headers correctly. +multiple times in NAND. The number of replications and their spacing (referred +to as search stride) is configurable through board strapping options and/or +eFUSE settings (BOOT_SEARCH_COUNT / Pages in block from BOOT_CFG2). In +addition, the i.MX6 BOOT ROM Flash Configuration Block (FCB) supports two +copies of a bootloader in flash in the case that a bad block has corrupted one. The Freescale 'kobs-ng' application from the Freescale LTIB BSP, which runs Line too long ? +under Linux and operates on an MTD partition, must be used to program the +bootstream in order to setup this flash structure correctly. The Gateworks Ventana boards with NAND flash have been factory programmed such that their eFUSE settings expect 2 copies of the boostream (this is specified by providing kobs-ng with the --search_exponent=1 argument). Once in -Linux with MTD support for the NAND on /dev/mtd0 you can program the boostream +Linux with MTD support for the NAND on /dev/mtd0 you can program the SPL with: -kobs-ng init -v -x --search_exponent=1 u-boot.imx +kobs-ng init -v -x --search_exponent=1 SPL -The kobs-ng application uses an imximage (u-boot.imx) which contains the -Image Vector Table (IVT) and Device Configuration Data (DCD) structures that -the i.MX6 BOOT ROM requires to boot. The kobs-ng adds the Firmware -Configuration Block (FCB) and Discovered Bad Block Table
Re: [U-Boot] [PATCH] tools: make imxheader size align on page size
Hi Stefan, On 23/04/2014 11:55, Stefan Agner wrote: Have you tried to ask Freescale about this issue ? It is quite strage and it seems Vybrid-related. No not yet. I need to setup an example. However, in the end they will not change the ROM anyway, especially not on Vybrids already delivered ;-) Of course, they won't do. Anyway, we need to identify exactly the problem and its cause, If Freescale will confirm that Vybrid needs a 8-byte alignment for NAND booting, we are sure that this can be a fix and we are not hiding the real cause. 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] am33xx : bit-flip correction in oob
Hello Marek,
From: Belisko Marek [mailto:marek.beli...@gmail.com]
CC-ing Pekon Gupta which add those changes in commit:
6e562b1106ea6afc78752f50925e87e9dd14f8b4
On Tue, Apr 15, 2014 at 12:47 PM, Belisko Marek marek.beli...@gmail.com
wrote:
Hi,
we're running 2014.04-rc3 on custom am335x board (same configuration as BBB).
When spl is loading u-boot from nand flash we can see a lot of
messages in console:
nand: bit-flip corrected @oob=0
It is always the same position (seems to be first byte in oob).
Anybody experienced same problem?
I've tested on 2 different flashes and result is same.
I was able to track down that read ecc from gpmc return always first
byte as 0xFF (in omap_calculate_ecc())
This shouldn't be the case if the page is programmed.
Following is the expected ECC layout of BCH8
OOB[0]: Bad block marker
OOB[1]: Bad block marker
OOB[2]: ecc_sector0_byte[0] = read_ecc[0] ---
OOB[3]: ecc_sector0_byte[1]
OOB[4]: ecc_sector0_byte[2]
OOB[5]: ecc_sector0_byte[3]
OOB[6]: ecc_sector0_byte[4]
OOB[7]: ecc_sector0_byte[5]
OOB[8]: ecc_sector0_byte[6]
OOB[9]: ecc_sector0_byte[7]
OOB[10]: ecc_sector0_byte[8]
OOB[11]: ecc_sector0_byte[9]
OOB[12]: ecc_sector0_byte[10]
OOB[13]: ecc_sector0_byte[11]
OOB[14]: ecc_sector0_byte[12]
OOB[15]: ecc_sector0_byte[13]
OOB[13]: reserved (0x00)
OOB[14]: ecc_sector1_byte[0]
OOB[15]: ecc_sector1_byte[1]
OOB[16]: ecc_sector2_byte[2]
OOB[17]: ecc_sector3_byte[3]
and thus function omap_correct_data_bch() always trying to repair
bit-flips in first oob byte. Can this be caused by
flash? Any pointers?
In config we're using:
#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW
#define CONFIG_NAND_OMAP_ELM
Something seems to be wrong elsewhere.
(1) please use 'nand dump' to check above layout
(2) Also please send me your device datasheet
(3) If you using x16 device, then you might need to pull-in following patch
series..
http://lists.denx.de/pipermail/u-boot/2014-April/176834.html
OR
Use below hack, just for testing (only for x16 devices)..
---
diff --git a/arch/arm/cpu/armv7/am33xx/mem.c b/arch/arm/cpu/armv7/am33xx/mem.c
index 56c9e7d..b166a94 100644
--- a/arch/arm/cpu/armv7/am33xx/mem.c
+++ b/arch/arm/cpu/armv7/am33xx/mem.c
@@ -64,7 +64,7 @@ void gpmc_init(void)
u32 base = CONFIG_SYS_FLASH_BASE;
#elif defined(CONFIG_NAND)
/* configure GPMC for NAND */
- const u32 gpmc_regs[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG1,
+ const u32 gpmc_regs[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG1 | 0x1000,
M_NAND_GPMC_CONFIG2,
M_NAND_GPMC_CONFIG3,
M_NAND_GPMC_CONFIG4,
---
with regards, pekon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] am33xx : bit-flip correction in oob
Fixed some copy paste typos in ECC layout below..
From: Gupta, Pekon
Hello Marek,
From: Belisko Marek [mailto:marek.beli...@gmail.com]
CC-ing Pekon Gupta which add those changes in commit:
6e562b1106ea6afc78752f50925e87e9dd14f8b4
On Tue, Apr 15, 2014 at 12:47 PM, Belisko Marek marek.beli...@gmail.com
wrote:
Hi,
we're running 2014.04-rc3 on custom am335x board (same configuration as
BBB).
When spl is loading u-boot from nand flash we can see a lot of
messages in console:
nand: bit-flip corrected @oob=0
It is always the same position (seems to be first byte in oob).
Anybody experienced same problem?
I've tested on 2 different flashes and result is same.
I was able to track down that read ecc from gpmc return always first
byte as 0xFF (in omap_calculate_ecc())
This shouldn't be the case if the page is programmed.
Following is the expected ECC layout of BCH8
OOB[0]: Bad block marker
OOB[1]: Bad block marker
OOB[2]: ecc_sector0_byte[0] = read_ecc[0] ---
OOB[3]: ecc_sector0_byte[1]
OOB[4]: ecc_sector0_byte[2]
OOB[5]: ecc_sector0_byte[3]
OOB[6]: ecc_sector0_byte[4]
OOB[7]: ecc_sector0_byte[5]
OOB[8]: ecc_sector0_byte[6]
OOB[9]: ecc_sector0_byte[7]
OOB[10]: ecc_sector0_byte[8]
OOB[11]: ecc_sector0_byte[9]
OOB[12]: ecc_sector0_byte[10]
OOB[13]: ecc_sector0_byte[11]
OOB[14]: ecc_sector0_byte[12]
OOB[15]: reserved (0x00) = read_ecc[13] ---
OOB[16]: ecc_sector1_byte[0]
OOB[17]: ecc_sector1_byte[1]
OOB[18]: ecc_sector2_byte[2]
OOB[19]: ecc_sector3_byte[3]
and thus function omap_correct_data_bch() always trying to repair
bit-flips in first oob byte. Can this be caused by
flash? Any pointers?
In config we're using:
#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW
#define CONFIG_NAND_OMAP_ELM
Something seems to be wrong elsewhere.
(1) please use 'nand dump' to check above layout
(2) Also please send me your device datasheet
(3) If you using x16 device, then you might need to pull-in following patch
series..
http://lists.denx.de/pipermail/u-boot/2014-April/176834.html
OR
Use below hack, just for testing (only for x16 devices)..
---
diff --git a/arch/arm/cpu/armv7/am33xx/mem.c b/arch/arm/cpu/armv7/am33xx/mem.c
index 56c9e7d..b166a94 100644
--- a/arch/arm/cpu/armv7/am33xx/mem.c
+++ b/arch/arm/cpu/armv7/am33xx/mem.c
@@ -64,7 +64,7 @@ void gpmc_init(void)
u32 base = CONFIG_SYS_FLASH_BASE;
#elif defined(CONFIG_NAND)
/* configure GPMC for NAND */
- const u32 gpmc_regs[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG1,
+ const u32 gpmc_regs[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG1 | 0x1000,
M_NAND_GPMC_CONFIG2,
M_NAND_GPMC_CONFIG3,
M_NAND_GPMC_CONFIG4,
---
with regards, pekon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/2] mtd: nand: omap: add support for BCH16_ECC
This patch series should be picked above [1] http://lists.denx.de/pipermail/u-boot/2014-April/177231.html *changes v2 - v3* - dropped [PATCH] am33xx: elm: add support for BCH16_ECC - ELM driver updates re-using existing code in omap_elm.c - rebased and refreshed above [1] and u-boot-2014.04 - Documentation updated in doc/nand.README *changes v1 - v2* - rebased for http://lists.denx.de/pipermail/u-boot/2013-September/162107.html - minor code cleanup *original v1* This patch series add support of BCH16_ECC scheme. As BCH16_ECC scheme generates 26bytes of ECC syndrome per 512B data, hence this scheme is usable only for NAND devices having 4K or above page-size, as their OOB/spare area has enough space to accomodate ECC. This patch series is applicable over an above following series: http://lists.denx.de/pipermail/u-boot/2013-September/161859.html Pekon Gupta (2): mtd: nand: omap: add support for BCH16_ECC - NAND driver updates am335x: update README for BCH16 doc/README.nand | 42 +++ drivers/mtd/nand/omap_gpmc.c | 78 ++- include/linux/mtd/omap_gpmc.h | 8 + 3 files changed, 127 insertions(+), 1 deletion(-) -- 1.8.5.1.163.gd7aced9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] am335x: update README for BCH16
updates documentation with explanation on how to select ECC schemes. Signed-off-by: Pekon Gupta pe...@ti.com --- doc/README.nand | 42 ++ 1 file changed, 42 insertions(+) diff --git a/doc/README.nand b/doc/README.nand index 90d857e..a5d20bc 100644 --- a/doc/README.nand +++ b/doc/README.nand @@ -240,6 +240,48 @@ Platform specific options 8-bit BCH code with - ecc calculation using GPMC hardware engine, - error detection using ELM hardware engine. + OMAP_ECC_BCH16_CODE_HW + 16-bit BCH code with + - ecc calculation using GPMC hardware engine, + - error detection using ELM hardware engine. + + How to select ECC scheme on OMAP and AMxx platforms ? + - + Though higher ECC schemes have more capability to detect and correct + bit-flips, but still selection of ECC scheme is dependent on following + - hardware engines present in SoC. + Some legacy OMAP SoC do not have ELM h/w engine thus such + SoC cannot support BCHx_HW ECC schemes. + - size of OOB/Spare region + With higher ECC schemes, more OOB/Spare area is required to + store ECC. So choice of ECC scheme is limited by NAND oobsize. + + In general following expression can help: + NAND_OOBSIZE = 2 + (NAND_PAGESIZE / 512) * ECC_BYTES + where + NAND_OOBSIZE= number of bytes available in + OOB/spare area per NAND page. + NAND_PAGESIZE = bytes in main-area of NAND page. + ECC_BYTES = number of ECC bytes generated to + protect 512 bytes of data, which is: + 3 for HAM1_xx ecc schemes + 7 for BCH4_xx ecc schemes + 14 for BCH8_xx ecc schemes + 26 for BCH16_xx ecc schemes + + example to check for BCH16 on 2K page NAND + NAND_PAGESIZE = 2048 + NAND_OOBSIZE = 64 + 2 + (2048 / 512) * 26 = 106 NAND_OOBSIZE + Thus BCH16 cannot be supported on 2K page NAND. + + However, for 4K pagesize NAND + NAND_PAGESIZE = 4096 + NAND_OOBSIZE = 64 + ECC_BYTES = 26 + 2 + (4096 / 512) * 26 = 210 NAND_OOBSIZE + Thus BCH16 can be supported on 4K page NAND. + NOTE: = -- 1.8.5.1.163.gd7aced9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] mtd: nand: omap: add support for BCH16_ECC - NAND driver updates
This patch add support for BCH16_ECC to omap_gpmc driver.
*need to BCH16 ECC scheme*
With newer SLC Flash technologies and MLC NAND, and large densities, pagesizes
Flash devices have become more suspectible to bit-flips. Thus stronger
ECC schemes are required for protecting the data.
But stronger ECC schemes have come with larger-sized ECC syndromes which require
more space in OOB/Spare. This puts constrains like;
(a) BCH16_ECC can correct 16 bit-flips per 512Bytes of data.
(b) BCH16_ECC generates 26-bytes of ECC syndrome / 512B.
Due to (b) this scheme can only be used with NAND devices which have enough
OOB to satisfy following equation:
OOBsize per page = 26 * (page-size / 512)
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/nand/omap_gpmc.c | 78 ++-
include/linux/mtd/omap_gpmc.h | 8 +
2 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index ba7ac2b..5bd5d91 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -224,6 +224,19 @@ static void omap_enable_hwecc(struct mtd_info *mtd,
int32_t mode)
eccsize1 = 2; /* non-ECC bits in nibbles per sector */
}
break;
+ case OMAP_ECC_BCH16_CODE_HW:
+ ecc_algo = 0x1;
+ bch_type = 0x2;
+ if (mode == NAND_ECC_WRITE) {
+ bch_wrapmode = 0x01;
+ eccsize0 = 0; /* extra bits in nibbles per sector */
+ eccsize1 = 52; /* OOB bits in nibbles per sector */
+ } else {
+ bch_wrapmode = 0x01;
+ eccsize0 = 52; /* ECC bits in nibbles per sector */
+ eccsize1 = 0; /* non-ECC bits in nibbles per sector */
+ }
+ break;
default:
return;
}
@@ -290,6 +303,29 @@ static int omap_calculate_ecc(struct mtd_info *mtd, const
uint8_t *dat,
ptr--;
}
break;
+ case OMAP_ECC_BCH16_CODE_HW:
+ val = readl(gpmc_cfg-bch_result_4_6[0].bch_result_x[2]);
+ ecc_code[i++] = (val 8) 0xFF;
+ ecc_code[i++] = (val 0) 0xFF;
+ val = readl(gpmc_cfg-bch_result_4_6[0].bch_result_x[1]);
+ ecc_code[i++] = (val 24) 0xFF;
+ ecc_code[i++] = (val 16) 0xFF;
+ ecc_code[i++] = (val 8) 0xFF;
+ ecc_code[i++] = (val 0) 0xFF;
+ val = readl(gpmc_cfg-bch_result_4_6[0].bch_result_x[0]);
+ ecc_code[i++] = (val 24) 0xFF;
+ ecc_code[i++] = (val 16) 0xFF;
+ ecc_code[i++] = (val 8) 0xFF;
+ ecc_code[i++] = (val 0) 0xFF;
+ for (j = 3; j = 0; j--) {
+ val = readl(gpmc_cfg-bch_result_0_3[0].bch_result_x[j]
+ );
+ ecc_code[i++] = (val 24) 0xFF;
+ ecc_code[i++] = (val 16) 0xFF;
+ ecc_code[i++] = (val 8) 0xFF;
+ ecc_code[i++] = (val 0) 0xFF;
+ }
+ break;
default:
return -EINVAL;
}
@@ -308,6 +344,8 @@ static int omap_calculate_ecc(struct mtd_info *mtd, const
uint8_t *dat,
case OMAP_ECC_BCH8_CODE_HW:
ecc_code[chip-ecc.bytes - 1] = 0x00;
break;
+ case OMAP_ECC_BCH16_CODE_HW:
+ break;
default:
return -EINVAL;
}
@@ -333,7 +371,7 @@ static int omap_correct_data_bch(struct mtd_info *mtd,
uint8_t *dat,
struct omap_nand_info *info = chip-priv;
struct nand_ecc_ctrl *ecc = chip-ecc;
uint32_t error_count = 0, error_max;
- uint32_t error_loc[8];
+ uint32_t error_loc[ELM_MAX_ERROR_COUNT];
enum bch_level bch_type;
uint32_t i, ecc_flag = 0;
uint8_t count, err = 0;
@@ -365,6 +403,9 @@ static int omap_correct_data_bch(struct mtd_info *mtd,
uint8_t *dat,
bch_type = BCH_8_BIT;
omap_reverse_list(calc_ecc, ecc-bytes - 1);
break;
+ case OMAP_ECC_BCH16_CODE_HW:
+ omap_reverse_list(calc_ecc, ecc-bytes);
+ break;
default:
return -EINVAL;
}
@@ -381,6 +422,9 @@ static int omap_correct_data_bch(struct mtd_info *mtd,
uint8_t *dat,
/* 14th byte in ECC is reserved to match ROM layout */
error_max = SECTOR_BYTES + (ecc-bytes - 1);
break;
+ case OMAP_ECC_BCH16_CODE_HW:
+ error_max = SECTOR_BYTES + ecc-bytes;
+ break;
default:
return -EINVAL;
}
Re: [U-Boot] [PATCH 07/11] MX6: use macro building for MX6Q/MX6DL iomux regs
Hi Stefano, On 04/23/2014 10:07 AM, Stefano Babic wrote: Hi Tim, hi Nikita, On 10/04/2014 16:08, Nikita Kiryanov wrote: The cfg files are currently all written to use the IOMUX register names as MX6_ (no Q vs DL) so that a single cfg file can be used for a build-time configuration of IMX6Q or IMX6DL. OK now I understand. It seems to me that you only have this problem because you are using these address #defines as values for mx6_mmdc_ioregs structs to define a register mapping. You can also define this mapping by using a struct template that matches the register layout and a base address, both of which change between CPU types. Reason to do in this way is the thought that the layout among the processsors can be completely different, thing that for other area is also true. This was discussed also in a previous RFC by Eric: http://lists.denx.de/pipermail/u-boot/2013-November/15.html Tim, what about to repost in your patchset Eric's patch ? It completes your patchset and add documentation that is now missing (added Eric in CC if he will complain about this..) I have no problem with this, but when I did some follow-on work to bring up SPL on Nitrogen6x boards, I recall finding some bugs in that patch set. I didn't follow up with updates because I ran into some other snags. In particular, our use of SPI-NOR makes it crucial that we be able to download a secondary U-Boot over USB. However, if we can recognize the same layout for all three variations (I have only check some registers in 6Q and 6DL layout), using the same structure with a different base address can be even more readable. I admit I have not checked deeply, but it seems at first glance that mx6dq_ctrl and mx6sdl_ctrl in 7/11 share the same layout. There's a lot of commonality, but a quick diff of arch-mx6/mx6q-ddr.h and arch-mx6/mx6dl-ddr.h will show the problem areas. You can find an example of this in the Wandboard SPL implementation. It's not in mainline ATM so you'll have to download their BSP. The template + base addr method also doesn't use up additional memory to define this layout, which is a point in its favor. If the layout is exactly the same, you could make the structure available to all imx6 flavors. Unfortunately, I don't believe it is. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] env: drop CONFIG_ENV_VARS_UBOOT_CONFIG support
Dear Masahiro,
In message 20140423210335.18ee.aa925...@jp.panasonic.com you wrote:
Finally, I don't see what your replacement code would be to create the
set of environment settigns - and I think these are needed, as some
user defined scripts are processing these?
The user who needs such environment setting can
add them by using CONFIG_EXTRA_ENV_SETTINGS.
For example,
#define CONFIG_EXTRA_ENV_SETTINGS \
arch=arm\0 \
cpu=armv7\0 \
soc=tegra20\0
I am not sure this is acceptable.
Neither am I. What I can see is that this is less flexible - as is,
we can easily derive these names from the make target name. Your
implementation would either be static, or require #ifdefs ?
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
If you want strict real-time behavior, run in the real time schedu-
ling class. But there are no seatbelts or airbags; main(){for(;;);}
can hard hang your system. -- Bart Smaalders
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc: Increase u-boot size for selected boards
These boards have compiling error with latest change in u-boot. The image grows and exceeds the preconfigured size. This patch only address the compiling error. It is not verified on the boards. The affected boards are MPC8572DS, dlvision, io, iocon, neo Signed-off-by: York Sun york...@freescale.com CC: Dirk Eibach eib...@gdsys.de CC: Kumar Gala ga...@kernel.crashing.org --- include/configs/MPC8572DS.h|2 +- include/configs/dlvision-10g.h |2 +- include/configs/io.h |2 +- include/configs/iocon.h|2 +- include/configs/neo.h |2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/configs/MPC8572DS.h b/include/configs/MPC8572DS.h index 7b63945..3a30feb 100644 --- a/include/configs/MPC8572DS.h +++ b/include/configs/MPC8572DS.h @@ -30,7 +30,7 @@ #endif #ifndef CONFIG_SYS_TEXT_BASE -#define CONFIG_SYS_TEXT_BASE 0xeff8 +#define CONFIG_SYS_TEXT_BASE 0xeff4 #endif #ifndef CONFIG_RESET_VECTOR_ADDRESS diff --git a/include/configs/dlvision-10g.h b/include/configs/dlvision-10g.h index 7877897..47484d8 100644 --- a/include/configs/dlvision-10g.h +++ b/include/configs/dlvision-10g.h @@ -11,7 +11,7 @@ #define CONFIG_405EP 1 /* this is a PPC405 CPU */ #define CONFIG_DLVISION_10G1 /* on a DLVision-10G board */ -#defineCONFIG_SYS_TEXT_BASE0xFFFC +#defineCONFIG_SYS_TEXT_BASE0xFFF8 /* * Include common defines/options for all AMCC eval boards diff --git a/include/configs/io.h b/include/configs/io.h index 9da6cc6..c7f0ded 100644 --- a/include/configs/io.h +++ b/include/configs/io.h @@ -11,7 +11,7 @@ #define CONFIG_405EP 1 /* this is a PPC405 CPU */ #define CONFIG_IO 1 /* on a Io board */ -#defineCONFIG_SYS_TEXT_BASE0xFFFC +#defineCONFIG_SYS_TEXT_BASE0xFFF8 /* * Include common defines/options for all AMCC eval boards diff --git a/include/configs/iocon.h b/include/configs/iocon.h index f36c2a3..09fa1fb 100644 --- a/include/configs/iocon.h +++ b/include/configs/iocon.h @@ -11,7 +11,7 @@ #define CONFIG_405EP 1 /* this is a PPC405 CPU */ #define CONFIG_IOCON 1 /* on a IoCon board */ -#defineCONFIG_SYS_TEXT_BASE0xFFFC +#defineCONFIG_SYS_TEXT_BASE0xFFF8 /* * Include common defines/options for all AMCC eval boards diff --git a/include/configs/neo.h b/include/configs/neo.h index d549985..c23eafe 100644 --- a/include/configs/neo.h +++ b/include/configs/neo.h @@ -12,7 +12,7 @@ #define CONFIG_405EP 1 /* this is a PPC405 CPU */ #define CONFIG_NEO 1 /* on a Neo board */ -#defineCONFIG_SYS_TEXT_BASE0xFFFC +#defineCONFIG_SYS_TEXT_BASE0xFFF8 /* * Include common defines/options for all AMCC eval boards -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FIT image AES support and PPC4xx/85xx boards
On 04/18/2014 09:04 AM, Tom Rini wrote: On Fri, Apr 18, 2014 at 08:38:32AM -0700, York Sun wrote: On 04/18/2014 05:36 AM, Tom Rini wrote: Hey guys, Adding AES256 support to FIT images means that a handful of boards (ion, MPC8572DS, others) now don't link because of growth in the binary. Can we come up with something to fix these boards again? Thanks! Tom, Freescale board maintainers have been increasing the image size on some boards to 768KB. How many are still broken if adding AES256 support? Not many: io neo iocon MPC8572DS MPC8572DS_36BIT dlvision-10g Tom, I sent a patch to increase the size for these boards. Please review http://patchwork.ozlabs.org/patch/342009/. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/6] PPC 85xx: Add support for QEMU's ppce500 PV machine
On 04/11/2014 08:09 AM, Alexander Graf wrote: In QEMU we implement a PV machine type called ppce500. That board is able to run any e500+ FSL cores (e500v2, e500mc, e5500, e6500). It is heavily inspired by the MPC8544DS SoC and board combination, but implements only the bare minimum to make Linux happy enough to drive a virtual machine. This patch set implements support for this PV machine type in U-Boot, enabling users to run their virtual machines with netboot, u-boot payload binaries or other fun things they come up with. Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot-release] [PATCH 0/0][v2] powerpc: Add support 2 stage boot loader for corenet platform
On 04/08/2014 06:41 AM, Prabhakar Kushwaha wrote: Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- This patch set contains:- [PATCH 1/10] powerpc/mpc85xx: Move LAW_EN define outside of config [PATCH 2/10] powerpc/mpc85xx: Avoid hardcoding in SPL linker script [PATCH 3/10] powerpc:Add support of SPL non-relocation [PATCH 4/10] powerpc/mpc85xx:Disable non DDR LAWs before init_law [PATCH 5/10] driver/ifc: define nand_spl_load_image() for SPL [PATCH 6/10] driver/mtd/spi:Read 8KB data chunk during u-boot load in SPL [PATCH 7/10] driver: Add support of image load for MMC SPI in SPL [PATCH 8/10] Makefile: Add support of RAMBOOT_SPLPBL [PATCH 9/10] board/b4qds:Add support of 2 stage NAND boot-loader [PATCH 10/10] board/t104xrdb: Add support of NAND, SD, SPI boot for T1040RDB Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/2] powerpc/mpc85xx:Avoid fix address of bootpg section
On 03/31/2014 03:01 AM, Prabhakar Kushwaha wrote: It is not necessary for bootpg to be present at text + 512KB. With increase of u-boot size (768KB), bootpg section's address cannot be fixed. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx: Remove QE firmware copy from NAND
On 04/20/2014 10:16 PM, Prabhakar Kushwaha wrote: qe_init() does not use data copied from NAND. Thise code is not tested or complied causing compilation error during NAND boot So, remove QE firmware copy from NAND to ddr. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/mpc85xx:Update MONITOR_LEN for 768KB u-boot size
On 03/31/2014 03:01 AM, Prabhakar Kushwaha wrote: U-boot binary size has been increased from 512KB to 768KB. So update CONFIG_SYS_MONITOR_LEN to reflect the same. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- include/configs/B4860QDS.h |2 +- include/configs/BSC9131RDB.h |2 +- include/configs/BSC9132QDS.h |2 +- include/configs/C29XPCIE.h |2 +- include/configs/P1010RDB.h |2 +- include/configs/P1022DS.h |2 +- include/configs/P1023RDB.h |2 +- include/configs/P1023RDS.h |2 +- include/configs/P1_P2_RDB.h|2 +- include/configs/P2020DS.h |2 +- include/configs/P2041RDB.h |2 +- include/configs/T1040QDS.h |2 +- include/configs/T104xRDB.h |2 +- include/configs/T208xQDS.h |2 +- include/configs/T208xRDB.h |2 +- include/configs/corenet_ds.h |2 +- include/configs/p1_p2_rdb_pc.h |2 +- include/configs/p1_twr.h |2 +- include/configs/t4qds.h|2 +- 19 files changed, 19 insertions(+), 19 deletions(-) Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/t1042rdb_pi: Disable CONFIG_QE and CONFIG_U_QE
On 04/20/2014 10:17 PM, Prabhakar Kushwaha wrote: T1042RDB_PI board does not have QE connector. So disable CONFIG_QE and CONFIG_U_QE for T1042RDB_PI Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx:Update FM1 clock select and shift for B4420
On 04/20/2014 10:17 PM, Prabhakar Kushwaha wrote: B4420 is a personality of B4860. It should have same FM1_CLK_SEK and FM1_CLK_SHIFT as B4860 Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] driver/ddr/fsl: Add DDR4 support to Freescale DDR driver
On 03/27/2014 05:54 PM, York Sun wrote: Mostly reusing DDR3 driver, this patch adds DDR4 SPD handling, register calculation and programming. Signed-off-by: York Sun york...@freescale.com --- Applied to u-boot-mpc85xx/master. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mpc85xx/T1040QDS_D4: Add DDR4 support
On 03/27/2014 05:54 PM, York Sun wrote: T1040QDS_D4 is a variant of T1040QDS, with additional circuit to support DDR4 memory. Signed-off-by: York Sun york...@freescale.com --- Applied to u-boot-mpc85xx/master. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl/usb: Workaround for USB erratum-A007075
On 02/26/2014 04:13 AM, Nikhil Badola wrote: Put a delay of 5 millisecond after reset so that ULPI phy gets enough time to come out of reset. Erratum A007075 applies to following SOCs and their variants, if any P1010 rev 1.0 B4860 rev 1.0, 2.0 P4080 rev 2.0, 3.0 Signed-off-by: Nikhil Badola nikhil.bad...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v2] board/b4860qds:Slow MDC clock to comply IEEE specs in PBI config
On 03/08/2014 03:15 AM, Prabhakar Kushwaha wrote: The MDC generate by default value of MDIO_CLK_DIV is too high i.e. higher than 2.5 MHZ. It violates the IEEE specs. So Slow MDC clock to comply IEEE specs Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Changes for v2: Update commit message Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] powerpc/t208xqds: fix nor chip selection when nand boot
On 03/12/2014 07:19 PM, Shengzhou Liu wrote: NOR flash is on CS1 instead of CS2 when NAND boot. So correct NOR chip selection to CS1 from CS2. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] driver/mmc: fix compile warnings
On 03/31/2014 03:02 AM, Prabhakar Kushwaha wrote: Fix following compile warnings fsl_esdhc_spl.c: In function 'mmc_boot': fsl_esdhc_spl.c:35:10: warning: unused variable 'byte_num' [-Wunused-variable] fsl_esdhc_spl.c:35:7: warning: unused variable 'i' [-Wunused-variable] fsl_esdhc_spl.c:34:8: warning: unused variable 'val' [-Wunused-variable] fsl_esdhc_spl.c:33:6: warning: unused variable 'blklen' [-Wunused-variable] fsl_esdhc_spl.c:105:7: warning: 'tmp_buf' may be used uninitialized in this function [-Wuninitialized] Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl/usb: Increase TXFIFOTHRESH value for usb write in T4 Rev 2.0
On 04/06/2014 08:16 PM, Nikhil Badola wrote: Increase TXFIFOTHRES field value in TXFILLTUNING register of usb for T4 Rev 2.0. This decreases data burst rate with which data packets are posted from the TX latency FIFO to compensate for latencies in DDR pipeline during DMA. This avoids Tx buffer underruns and leads to successful usb writes Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com Signed-off-by: Nikhil Badola nikhil.bad...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v2] driver/net/fm/memac_phy: Initialize mdio_clock for SoCs wih FMANv3
On 04/07/2014 10:25 PM, Priyanka Jain wrote: MDIO clock needs to be initialized in u-boot code for SoCs having FMAN-v3(v3H or v3L) controller due to below reasons -On SoCs that have FMAN-v3H like B4860, default value of MDIO_CLK_DIV bits in mdio_stat(mdio_cfg) register generates mdio clock too high (much higher than 2.5MHz), violating the IEEE specs. -On SOCs that have FMAN-v3L like T1040, default value of MDIO_CLK_DIV bits is zero, so MDIO clock is disabled. So, for proper functioninig of MDIO, MDIO_CLK_DIV bits needs to be properly initialized. Also this type of initialization is generally done in PBI(pre-bootloader) phase using rcw.But for chips like T1040 which support deep-sleep, such type of initialization cannot be done in PBI phase due to the limitation that during deep-sleep resume, FMAN (MDIO) registers are not accessible in PBI phase. So, mdio clock initailization must be done as part of u-boot. This initialization code is implemented in memac_phy.c which gets compiled only for SoCs having FMANv3, so no extra compilation flag is required. Signed-off-by: Priyanka Jain priyanka.j...@freescale.com --- Changes for v2: Corrected Signed-off footer Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] powerpc/T208xRDB: add mtdparts suppport
On 04/01/2014 11:28 PM, Shengzhou Liu wrote: We use dynamical mtdparts partition instead of directly puting mtd partitions nodes in device tree. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- v2: update nand name to u64. Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] powerpc/T208xQDS: add mtdparts suppport
On 04/01/2014 11:28 PM, Shengzhou Liu wrote: We use dynamical mtdparts partition instead of directly puting mtd partitions nodes in device tree. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- v2: update nand name to u64. Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] [PATCH v3] powerpc/t104xrdb: Unification of T104xRDB header files
On 03/30/2014 11:16 PM, Vijay Rai wrote: T1040RDB, T1042RDB header files are very similar so merged into new header file T104xRDB. T104xRDB header file can support both T1040RDB and T1042RDB_PI header. Patch makes following changes -Update Boards.cfg file for T1040RDB and T1042RDB_PI -Add new T104xRDB header file -Delete T1040RDB, T1042RDB_PI header file Signed-off-by: Vijay Rai vijay@freescale.com Signed-off-by: Priyanka Jain priyanka.j...@freescale.com --- v3: - Rebasing to top of the tree Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/T1040: add mtdparts suppport for T104xRDB and T1040QDS
On 04/02/2014 04:56 AM, Prabhakar Kushwaha wrote: We use dynamical mtdparts partition instead of directly puting mtd partitions nodes in device tree. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] powerpc/cpu/mpc85xx: Add MAC address for layer 2 switch
On 03/28/2014 09:57 AM, Codrin Ciubotariu wrote: T1040RDB and T1040QDS boards have an integrated l2 switch. The switch needs a MAC address for Layer 2 protocols (MSTP, LLDP, LACP, etc). Setting a MAC address on l2switchaddr will add a MAC in device-tree, under node l2switch. Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com Cc: York Sun york...@freescale.com --- Changes v2: - replaced board macros with SoC macro; - added more comments; Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot-release] [PATCH][v5] board/t104xrdb: Add support of CPLD
On 04/03/2014 04:20 AM, Prabhakar Kushwaha wrote: T1040RDB and T1042RDB_PI has CPLD. Here CPLD controls board mux/features. This support of CPLD includes - files and register defintion - Commands to swtich alternate bank and default bank Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Changes for v2: - Updated the cpld command Changes for v3: - fix typo Changes for v4: - fix typo Changes for v5: - fix cpld registers while printing - rebased on top of below patch powerpc/t104xrdb: Unification of T104xRDB header files http://patchwork.ozlabs.org/patch/335207/ Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 1/3] QE/FMAN: modify CONFIG_SYS_QE_FMAN_FW_ADDR to CONFIG_SYS_FMAN_FW_ADDR and CONFIG_SYS_QE_FW_ADDR
On 03/21/2014 01:21 AM, Zhao Qiang wrote: CONFIG_SYS_QE_FMAN_FW_ADDR is used to both Fman and QE for microcode address. Now using CONFIG_SYS_FMAN_FW_ADDR for Fman microcode address, and CONFIG_SYS_QE_FW_ADDR for QE microcode address. Signed-off-by: Zhao Qiang b45...@freescale.com --- Changes for v2: - no Changes for v3: - no Changes for v4: - no Changes for v5: - modify CONFIG_SYS_QE_FW_ADDR to CONFIG_SYS_FMAN_FW_ADDR for kmp204x Changes for v6: - rebase Changes for v7: - no Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 2/3] QE/U-QE: Add U-QE support
On 03/21/2014 01:21 AM, Zhao Qiang wrote: Modify code to adapt to both u-qe and qe. U_QE is a kind of cutted QE. the differences between U_QE and QE 1. UCC: U_QE supports 2 UCCs while QE supports up to 8 UCCs. 2. IMMR: have different immr base addr. 3. iopin: U_QE doesn't need to config iopin. Signed-off-by: Zhao Qiang b45...@freescale.com --- Changes for v2: - modify CONFIG_SYS_QE_FMAN_FW_ADDR to CONFIG_SYS_FMAN_FW_ADDR and CONFIG_SYS_QE_FW_ADDR Changes for v3: - use CONFIG_U_QE instead of CONFIG_PPC_T1040 Changes for v4: - ifdef CONFIG_U_QE, include ../../../../drivers/qe/qe.h Changes for v5: - no Changes for v6: - rebase Changes for v7: - split to two patches, the one to support u-qe and the other is to add u-qe to t1040qds Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] t1040rdb/qe: add QE support for T1040RDB
On 03/13/2014 07:11 PM, Zhao Qiang wrote: add CONFIG_QE, CONFIG_U_QE and CONFIG_SYS_QE_FW_ADDR into include/configs/T1040RDB.h Signed-off-by: Zhao Qiang b45...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 3/3] T1040QDS/U-QE: Add u-qe support to t1040qds
On 03/21/2014 01:21 AM, Zhao Qiang wrote: Add u-qe support for t1040qds Signed-off-by: Zhao Qiang b45...@freescale.com --- Changes for v2: - modify CONFIG_SYS_QE_FMAN_FW_ADDR to CONFIG_SYS_FMAN_FW_ADDR and CONFIG_SYS_QE_FW_ADDR Changes for v3: - use CONFIG_U_QE instead of CONFIG_PPC_T1040 Changes for v4: - ifdef CONFIG_U_QE, include ../../../../drivers/qe/qe.h Changes for v5: - no Changes for v6: - rebase Changes for v7: - split to two patches, the one to support u-qe and the other is to add u-qe to t1040qds Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v2] powerpc/p1010rdb: SECURE BOOT enabled for NAND
On 03/07/2014 05:42 AM, Aneesh Bansal wrote: In case of secure boot from NAND, the DDR is initialized by the BootROM using the config words (CF_WORDS) in the CF_HEADER and u-boot image is copied from NAND to DDR by the BootROM. So, CONFIG_SYS_RAMBOOT has been defined for Secure Boot from NAND. Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] powerpc/p1010rdb: SECURE BOOT- enable workaround for IFC errata A003399
On 01/20/2014 01:27 AM, Aneesh Bansal wrote: The workaround for IFC errata A003399 was not enabled in case of secure boot. So, secure boot from NOR was not working. Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v2] powerpc/mpc8xxx: SECURE BOOT- Disable law 0 for non PBL platforms
On 03/11/2014 10:51 AM, Aneesh Bansal wrote: ISBC creates a LAW 0 entry for non PBL platforms, which is not disabled before transferring the control to uboot. The LAW 0 entry has to be disabled. Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for BSC9132QDS
On 03/11/2014 11:37 AM, Aneesh Bansal wrote: Add NOR, SPI and SD secure boot targets for BSC9132QDS. Changes: - Debug TLB entry is not required for Secure Boot Target. Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4][v7] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
On 03/18/2014 11:10 AM, Aneesh Bansal wrote: Changes: 1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation from start.S 2. Clear the LAW and corresponding configuration for CPC. Boot ROM code uses it as hosekeeping area. 3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening in cpu_init_r. As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes. Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx: SECURE BOOT- Add NAND secure boot target for BSC9132QDS
On 03/12/2014 09:30 AM, Aneesh Bansal wrote: In case of secure boot from NAND, the DDR is initialized by the BootROM using the config words (CF_WORDS) in the CF_HEADER and u-boot image is copied from NAND to DDR by the BootROM. So, CONFIG_SYS_RAMBOOT has been defined for Secure Boot from NAND Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for T4240QDS and T4160QDS
On 03/18/2014 11:10 AM, Aneesh Bansal wrote: Secure Boot Target is added for T4240QDS and T4160QDS Changes: For Secure boot, CPC is configured as SRAM and used as house keeping area which needs to be disabled. So CONFIG_SYS_CPC_REINIT_F is defined for CONFIG_T4240QDS. Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for T1040QDS and T1040RDB
On 03/18/2014 11:11 AM, Aneesh Bansal wrote: Secure Boot Target is added for T1040QDS and T1040RDB Changes: For Secure boot, CPC is configured as SRAM and used as house keeping area which needs to be disabled. So CONFIG_SYS_CPC_REINIT_F is defined for CONFIG_T1040QDS and CONFIG_T1040RDB Signed-off-by: Gaurav Rana gaurav.r...@freescale.com Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for T2080QDS
On 03/18/2014 11:10 AM, Aneesh Bansal wrote: Secure Boot Target is added for T2080QDS Changes: For Secure boot, CPC is configured as SRAM and used as house keeping area which needs to be disabled. So CONFIG_SYS_CPC_REINIT_F is defined for CONFIG_T2080QDS. Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl/usb: Fix phy type for Second USB controller
On 12/18/2013 09:38 PM, Nikhil Badola wrote: Set correct phy_type value for second USB controller. This is required for supporting SOCs having 2 USB controllers working simultaneously, one with UTMI phy and other with ULPI phy Signed-off-by: Nikhil Badola b46...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] driver/fsl_ifc: Add a function to finalize CS0 address binding
On 03/19/2014 01:52 PM, York Sun wrote: For fsl-lsch3 NOR flash boot, IFC CS0 needs to be binded with address within 32-bit at fist. After u-boot relocates to DDR, CS0 can be binded to higher address to support large space. Signed-off-by: York Sun york...@freescale.com CC: Prabhakar Kushwaha prabha...@freescale.com --- Applied to u-boot-mpc85xx/master. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Fix e6500 L2 cache stash IDs
On 03/26/2014 06:30 PM, Scott Wood wrote: The value written to L2CSR1 didn't match the value written to the device tree. Signed-off-by: Scott Wood scottw...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/phy: Fix PHY id for VSC8514
On 03/26/2014 09:13 AM, Codrin Ciubotariu wrote: In the current Datasheet for VSC8514 there is a mistake, saying that the PHY id is 0x70570. The real value in the identifier registers is 0x70670. Linux PHY driver uses 0x70670 also. Signed-off-by: Codrin Ciubotariu codrin.ciubota...@freescale.com Cc: York Sun york...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Powerpc/mpc8536DS: Increase SPI/SD uboot Image size to 768K
On 04/09/2014 08:16 PM, Haijun Zhang wrote: u-boot binary size for Freescale mpc8536DS platforms is 512KB. This has been reached to upper limit of the platforms and causig linker error. So increase the u-boot binary size to 768KB. Signed-off-by: Haijun Zhang haijun.zh...@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2] drivers/ddr: Fix possible out of bounds error
On 04/16/2014 06:31 PM, York Sun wrote: This is a theoretical possible out of bounds error in DDR driver. Adding check before using array index. Also change some runtime conditions to pre-compiling conditions. Signed-off-by: York Sun york...@freescale.com --- Change log: v2: Revise subject and commit message Applied to u-boot-mpc85xx/master. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/t1040rdb: added a break in switch case
On 04/10/2014 09:12 PM, shh@gmail.com wrote: From: Shaohui Xie shaohui@freescale.com There should be a break for case PHY_INTERFACE_MODE_SGMII, otherwise it will fall into case PHY_INTERFACE_MODE_RGMII. Signed-off-by: Shaohui Xie shaohui@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Enhance get_sys_info() to check clocking mode
On 04/14/2014 11:04 PM, Vijay Rai wrote: T1040 and it's variants provide Single Oscillator Source Reference Clock Mode. In this mode, single onboard oscillator(DIFF_SYSCLK) can provide the reference clock (100MHz) to the following PLLs: • Platform PLL • Core PLLs • USB PLL • DDR PLL, etc The cfg_eng_use0 of porsr1 register identifies whether the SYSCLK (single-ended) or DIFF_SYSCLK (differential) is selected as the clock input to the chip. get_sys_info has been enhanced to add the diff_sysclk so that the various drivers can be made aware of ths diff sysclk configuration and act accordingly. Other changes: -single_src to ddr_refclk_sel, as it is use for checking ddr reference clock -Removed the print of single_src from get_sys_info as this will be -printed whenever somebody calls get_sys_info which is not appropriate. -Add print of single_src in checkcpu as it is called only once during initialization Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Priyanka Jain priyanka.j...@freescale.com Signed-off-by: Vijay Rai vijay@freescale.com --- Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v2] powerpc/mpc85xx: Add Differential SYSCLK config support T1040
On 04/15/2014 02:14 AM, Nikhil Badola wrote: Adds support for clock sourcing from sysclk(100MHz) for usb on T104xRDB and T1040QDS. This requires changing reference divisor and multiplication factor to derive usb clock from sysclk. Signed-off-by: Nikhil Badola nikhil.bad...@freescale.com --- Dependency on patch http://patchwork.ozlabs.org/patch/339164/ Changes for v2: - Changed patch heading Applied to u-boot-mpc85xx/master, thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
