Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`
Hi Simon, On Thu, Dec 20, 2012 at 6:48 AM, Simon Glass wrote: > Hi Tom, > > On Wed, Dec 19, 2012 at 5:03 PM, Tom Rini wrote: >> On Thu, Dec 20, 2012 at 12:14:00AM +0100, Wolfgang Denk wrote: >>> Dear Tom Rini, >>> >>> In message <20121219225945.GF14589@bill-the-cat> you wrote: >>> > >>> ... >>> > With this change, applied to u-boot/master. >>> >>> Argh :-( >>> >>> Can we please undo this somehow? This does not fit at all >>> conceptually. U-Boot is supposed to use the good ols UNIX philosophy >>> of being terse by default, and special casing one specific storage >>> device makes no sense at all to me. >> >> We need to fix some of the underlying problems so that we're consistent >> here. Sometimes we have output (network #), sometimes we don't. >> Sometimes we have a speed (network, filesystem load), sometimes we >> don't. I'd be quite happy to have a uniform output and a uniform ON/OFF >> switch. > > I'm happy to do something like this. Obviously we want a config, but > do we also want an env variable to control it? Could be useful. > > And at the risk of killing it with feature creep, perhaps we could > have two levels of verbosity: progress (which repeatedly updates on > the same line) and notice (which does not). That might take care of > Jagannadha's use case also. > Any plan to add config for verbose messages on cmd_sf.c? seems like you plan for something, because I have some couple of patches which has verbose messages for sf read/erase/write commands. http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149753 Thanks, Jagan. > Regards, > Simon > >> >> -- >> Tom >> >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot >> > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] EXYNOS5: DWMMC: Added dt support for DWMMC
On 12/21/2012 02:16 PM, Amarendra Reddy wrote:
> Hi Simon,
>
> Thanks for your review comments.
> Please find the responses below.
>
> Thanks & Regards
> Amarendra Reddy
>
> On 20 December 2012 07:53, Simon Glass wrote:
>
>> Hi Amar,
>>
>> On Mon, Dec 17, 2012 at 3:19 AM, Amar wrote:
>>
>>> Signed-off-by: Amar
>>>
>>
>> Good to see this patch! Please can you add a short commit message?
>> Oops.. sorry. I will put the commit msg.
>>
>>> ---
>>
>> arch/arm/include/asm/arch-exynos/dwmmc.h |4 +
>>> drivers/mmc/exynos_dw_mmc.c | 117
>>> --
>>> include/dwmmc.h |4 +
>>> 3 files changed, 119 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/arch-exynos/dwmmc.h
>>> b/arch/arm/include/asm/arch-exynos/dwmmc.h
>>> index 8acdf9b..92352df 100644
>>> --- a/arch/arm/include/asm/arch-exynos/dwmmc.h
>>> +++ b/arch/arm/include/asm/arch-exynos/dwmmc.h
>>> @@ -27,6 +27,9 @@
>>> #define DWMCI_SET_DRV_CLK(x) ((x) << 16)
>>> #define DWMCI_SET_DIV_RATIO(x) ((x) << 24)
>>>
>>> +#ifdef CONFIG_OF_CONTROL
>>> +unsigned int exynos_dwmmc_init(const void *blob);
>>> +#else
>>> int exynos_dwmci_init(u32 regbase, int bus_width, int index);
>>>
>>> static inline unsigned int exynos_dwmmc_init(int index, int bus_width)
>>> @@ -34,3 +37,4 @@ static inline unsigned int exynos_dwmmc_init(int index,
>>> int bus_width)
>>> unsigned int base = samsung_get_base_mmc() + (0x1 * index);
>>> return exynos_dwmci_init(base, bus_width, index);
>>> }
>>> +#endif
>>> diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
>>> index 72a31b7..3b3e3e5 100644
>>> --- a/drivers/mmc/exynos_dw_mmc.c
>>> +++ b/drivers/mmc/exynos_dw_mmc.c
>>> @@ -19,23 +19,38 @@
>>> */
>>>
>>> #include
>>> -#include
>>> #include
>>> +#include
>>> +#include
>>> +#include
>>> #include
>>> #include
>>> +#include
>>> +
>>> +#defineDWMMC_MAX_CH_NUM4
>>> +#defineDWMMC_MAX_FREQ 5200
>>> +#defineDWMMC_MIN_FREQ 40
>>> +#defineDWMMC_MMC0_CLKSEL_VAL 0x03030001
>>> +#defineDWMMC_MMC2_CLKSEL_VAL 0x03020001
>>>
>>
>> What do these last two values mean? I think clock setting should be done in
>> clock.c, not here.
>>
>> In case of non-dt support, these two values are written into respective
> clock selection register-CLKSEL, to select the clock for MMC-channel0 and
> MMC-channel2.
> Will move clock setting into clock.c and the #defines will be moved into
> include/asm/arch/clk.h.
I didn't want to move into clk.h. Why do you move there?
It is related with CLKSEL register into DesignWare IP.
>
>>
>>>
>>> static char *EXYNOS_NAME = "EXYNOS DWMMC";
>>>
>>> static void exynos_dwmci_clksel(struct dwmci_host *host)
>>> {
>>> - u32 val;
>>> - val = DWMCI_SET_SAMPLE_CLK(DWMCI_SHIFT_0) |
>>> - DWMCI_SET_DRV_CLK(DWMCI_SHIFT_0) |
>> DWMCI_SET_DIV_RATIO(0);
>>> + dwmci_writel(host, DWMCI_CLKSEL, host->clksel_val);
>>> +}
>>>
>>> - dwmci_writel(host, DWMCI_CLKSEL, val);
>>> +unsigned int exynos_dwmci_get_clk(int dev_index)
>>> +{
>>> + return get_mmc_clk(dev_index);
>>> }
>>>
>>> +#ifdef CONFIG_OF_CONTROL
>>> +static int exynos_dwmci_init(u32 regbase, int bus_width,
>>> + int index, u32 *timing)
>>> +#else
>>> int exynos_dwmci_init(u32 regbase, int bus_width, int index)
>>> +#endif
>>>
>>
>> I'm really not keen on having the same function with different signatures.
>> My first question is whether we need to support operation without
>> CONFIG_OF_CONTROL. If so, I suggest having an init routine that takes an
>> FDT blob as a parameter, and a separate add_port function which can be
>> called by non-FDT-enabled board files. The init routine will call the
>> add_port function for each port it finds in the FDT.
>>
>> I think we need support operation without CONFIG_OF_CONTROL atleast untill
> the entire FDT is formed.
> Hence I will implement it as per your suggestion.
>
>
>> Also please can you briefly comment non-trivial functions?
>> OK.
>>
>>> {
>>> struct dwmci_host *host = NULL;
>>> host = malloc(sizeof(struct dwmci_host));
>>> @@ -44,14 +59,104 @@ int exynos_dwmci_init(u32 regbase, int bus_width,
>> int
>>> index)
>>> return 1;
>>> }
>>>
>>> + /* set the clock divisor - clk_div_fsys for mmc */
>>> + if (exynos5_mmc_set_clk_div(index)) {
>>> + debug("mmc clock div set failed\n");
>>> + return -1;
>>> + }
>>> +
>>> host->name = EXYNOS_NAME;
>>> host->ioaddr = (void *)regbase;
>>> host->buswidth = bus_width;
>>> +#ifdef CONFIG_OF_CONTROL
>>> + host->clksel_val = (DWMCI_SET_SAMPLE_CLK(timing[0]) |
>>> + DWMCI_SET_DRV_CLK(timing[1]) |
>>> + DWMCI_SET_DIV_RATIO(timing[2]))
Re: [U-Boot] [PATCH 2/9] EXYNOS5: FDT: Add DWMMC device node data
On 12/20/2012 10:55 AM, Simon Glass wrote:
> Hi Amar,
>
> On Mon, Dec 17, 2012 at 3:19 AM, Amar wrote:
>> Add DWMMC device node data for exynos5
>>
>> Signed-off-by: Amar
>> ---
>> arch/arm/dts/exynos5250.dtsi | 32
>> +
>> board/samsung/dts/exynos5250-smdk5250.dts | 24 +
>
> Do you also have a binding file for this please?
>
>> 2 files changed, 56 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
>> index 1008797..b701ae5 100644
>> --- a/arch/arm/dts/exynos5250.dtsi
>> +++ b/arch/arm/dts/exynos5250.dtsi
>> @@ -138,4 +138,36 @@
>> reg = <0x131b 0x30>;
>> interrupts = <0 130 0>;
>> };
>> +
>> + dwmmc@1220 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "samsung,exynos5250-dwmmc";
>> + reg = <0x1220 0x1000>;
>> + interrupts = <0 75 0>;
>> + };
>> +
>> + dwmmc@1221 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "samsung,exynos5250-dwmmc";
>> + reg = <0x1221 0x1000>;
>> + interrupts = <0 76 0>;
>> + };
>> +
>> + dwmmc@1222 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "samsung,exynos5250-dwmmc";
>> + reg = <0x1222 0x1000>;
>> + interrupts = <0 77 0>;
>> + };
>> +
>> + dwmmc@1223 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "samsung,exynos5250-dwmmc";
>> + reg = <0x1223 0x1000>;
>> + interrupts = <0 78 0>;
>> + };
>> };
>> diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
>> b/board/samsung/dts/exynos5250-smdk5250.dts
>> index a8e62da..b1b8d71 100644
>> --- a/board/samsung/dts/exynos5250-smdk5250.dts
>> +++ b/board/samsung/dts/exynos5250-smdk5250.dts
>> @@ -30,6 +30,10 @@
>> spi2 = "/spi@12d4";
>> spi3 = "/spi@131a";
>> spi4 = "/spi@131b";
>> + dwmmc0 = "/dwmmc@1220";
>> + dwmmc1 = "/dwmmc@1221";
>> + dwmmc2 = "/dwmmc@1222";
>> + dwmmc3 = "/dwmmc@1223";
>> };
>>
>> sromc@1225 {
>> @@ -59,4 +63,24 @@
>> compatible = "wolfson,wm8994-codec";
>> };
>> };
>> +
>> + dwmmc@1220 {
>> + index = <0>;
>
> Do you really need the index? You have the numbering from the aliaes I think.
>
>> + bus-width = <8>;
>> + timing = <1 3 3>;
>
> Might need a "samsung," prefix on these?
I think better that use the "exynos" instead of "samsung".
how about?
>
>> + };
>> +
>> + dwmmc@1221 {
>> + status = "disabled";
>> + };
>> +
>> + dwmmc@1222 {
>> + index = <2>;
>> + bus-width = <4>;
>> + timing = <1 2 3>;
>> + };
>> +
>> + dwmmc@1223 {
>> + status = "disabled";
>> + };
>> };
>> --
>> 1.7.0.4
>>
>
> Regards,
> Simon
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/10] Add Marvell Dove and SolidRun CuBox
Hi Sebastian, On Sun, 2 Dec 2012 15:36:12 +0100, Sebastian Hesselbarth wrote: > This patch set add support for the Marvell Dove 88AP510 SoC and > the SolidRun CuBox board based on that SoC. The patch set is divided > into the four following sections: > > (1) Patches 1-5: > Add support for the Dove SoC and related drivers. Where possible > drivers from Marvell Kirkwood are reused (mvsata, mvgbe), or > forked to allow more generic usage (SPI, GPIO). The SDHCI driver > is different and a new driver is added for it. The forked drivers > can also be reused on Kirkwood but that would have required patching > existing boards. > > (2) Patches 6-8: > Allow mvgbe to use the phylib API, add support for 88E1310 PHY and > allow Dove to use the driver. > > (3) Patch 9 > Add the SolidRun CuBox as the first board based on Marvell Dove SoC. > > (4) Patch 10 > Add support for different UART boot mode found on Dove. > > Sebastian Hesselbarth (10): > ARM: dove: add support for Marvell Dove SoC > GPIO: add gpio driver for Orion SoCs > MMC: sdhci: Add support for dove sdhci > SPI: Add Orion SPI driver > block: mvsata: add dove include > NET: phy: add 88E1310 PHY initialization > NET: mvgbe: add phylib support > NET: mvgbe: add support for Dove > Boards: Add support for SolidRun CuBox > tools: Add support for Dove to kwboot Just a general remark: as this is a new support patch, it will only go in during next merge window; so when kirkwood or ARM pull requests are sent, make sure your patch set still applies to the new tree tip and if not, fix and submit a new version that does apply. (mentioning this because you're touching files that I'm pretty sure are being modified by changes that *will* go in 2013.01) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] serial/ns16550: check UART mode for TEMT value
On ns16550, the Transmitter Empty (TEMT) Bit is used to
indicate when the Transmitter Holding Register (THR) and
the Transmitter Shift Register (TSR) are both empty.
But ns16550 UART has two operation modes (16450 and FIFO)
and the TEMT bit logic value set is different on each mode.
On 16450, the TEMT bit is set to 1 when both THR and TSR are
empty and is set to 0 on FIFO mode.
So, checking the TEMT value without checking the current mode
and assuming a logical value of 1, can lead to U-Boot to hang
forever if the UART is initialized on FIFO mode by default.
Signed-off-by: Javier Martinez Canillas
---
drivers/serial/ns16550.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index bbd91ca..d75d814 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -36,7 +36,9 @@
void NS16550_init(NS16550_t com_port, int baud_divisor)
{
- while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
+ int mode = serial_in(&com_port->fcr) & UART_FCR_FIFO_EN;
+
+ while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT ^ mode))
;
serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier);
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] no mtdparted from U-Boot> prompt
Hi Johns, On 12/21/2012 07:53 AM, jo...@msli.com wrote: This is my first post to the list. I am using u-boot-1.3.4 in buildroot-2011.11 My device is a at91sam9g20-ek I have a patch adding: include/configs/at91sam9g20ek.h which I gather acts as a config file for u-boot. U-Boot> help does not list mtdparts But my bootargs does use it: bootargs=mem=64M console=ttyS0,115200 mtdparts=atmel_nand:4M(bootstrap/uboot/kernel)ro,60M(rootfs),-(data) root=/dev/mtdblock1 rw rootfstype=jffs2 This mtdparts is defined for Linux kernel NAND driver. Is there a trick to add the mtdparts command? Yes, you need to add "#define CONFIG_CMD_MTDPARTS" in include/configs/at91sam9g20ek.h Or is there supposed to be a command? I unsuccessfully added to include/configs/at91sam9g20ek.h #define CONFIG_JFFS2_NAND 1 #define CONFIG_JFFS2_CMDLINE 1 #define CONFIG_CMD_JFFS2 1 // Required to include cmd_jffs2.c which did not result in adding the command line. NOTICE: This email may contain confidential information. Please see http://www.meyersound.com/confidential/ for our complete policy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 0/4] Add support for FIMD and DP on SMDK5250
Changes since V3: -- Make the dummy definition for "exynos_mipi_dsi_init" static and inline. -- Remove #ifdef, instead use logo_on field to add LCD console support. [PATCH V2 RESEND 1/4] EXYNOS5: Change parent clock of FIMD to MPLL [PATCH V2 2/4] EXYNOS: Add dummy definition to fix compilation dependency on CONFIG_EXYNOS_MIPI_DSIM [PATCH V4 3/4] video: Modify exynos_fimd driver to support LCD console [PATCH V4 4/4] EXYNOS5: Add support for FIMD and DP arch/arm/cpu/armv7/exynos/clock.c|2 +- arch/arm/include/asm/arch-exynos/mipi_dsim.h |7 ++ board/samsung/smdk5250/smdk5250.c| 97 ++ drivers/video/exynos_fb.c|7 ++ drivers/video/exynos_fimd.c | 12 ++- include/configs/smdk5250.h |8 ++ 6 files changed, 128 insertions(+), 5 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 RESEND 1/4] EXYNOS5: Change parent clock of FIMD to MPLL
With VPLL as source clock to FIMD, Exynos DP Initializaton was failing sometimes with unstable clock. Changing FIMD source to MPLL resolves this issue. Signed-off-by: Ajay Kumar Acked-by: Simon Glass Acked-by: Donghwa Lee --- arch/arm/cpu/armv7/exynos/clock.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/clock.c b/arch/arm/cpu/armv7/exynos/clock.c index fe61f88..bfcd5f7 100644 --- a/arch/arm/cpu/armv7/exynos/clock.c +++ b/arch/arm/cpu/armv7/exynos/clock.c @@ -603,7 +603,7 @@ void exynos5_set_lcd_clk(void) */ cfg = readl(&clk->src_disp1_0); cfg &= ~(0xf); - cfg |= 0x8; + cfg |= 0x6; writel(cfg, &clk->src_disp1_0); /* -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/4] EXYNOS: Add dummy definition to fix compilation dependency on CONFIG_EXYNOS_MIPI_DSIM
When only DP is used, we need not enable CONFIG_EXYNOS_MIPI_DSIM.
But if we do not select CONFIG_EXYNOS_MIPI_DSIM, exynos_fb.c throws
error saying exynos_mipi_dsi_init() not defined. So, we add
dummy definition for exynos_mipi_dsi_init when CONFIG_EXYNOS_MIPI_DSIM
is not defined.
Signed-off-by: Ajay Kumar
Acked-by: Simon Glass
Acked-by: Donghwa Lee
---
arch/arm/include/asm/arch-exynos/mipi_dsim.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
index 9a7cbeb..c1c9a35 100644
--- a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
+++ b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
@@ -358,7 +358,14 @@ struct mipi_dsim_lcd_driver {
void(*mipi_display_on)(struct mipi_dsim_device *dsim_dev);
};
+#ifdef CONFIG_EXYNOS_MIPI_DSIM
int exynos_mipi_dsi_init(void);
+#else
+static inline int exynos_mipi_dsi_init(void)
+{
+ return 0;
+}
+#endif
/*
* register mipi_dsim_lcd_driver object defined by lcd panel driver
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 3/4] video: Modify exynos_fimd driver to support LCD console
Currently, exynos FIMD driver is being used to support only TIZEN LOGOs.
In order to get LCD console, we need to enable half word swap feature
of FIMD and use 16 BPP.
LCD console and proprietary Logo cannot be used simultaneously.
We use logo_on field inside vidinfo_t structure to decide whether
user wants Logo or Console.
Signed-off-by: Ajay Kumar
---
drivers/video/exynos_fb.c |7 +++
drivers/video/exynos_fimd.c | 12
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index d9a3f9a..ee916be 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -45,6 +45,13 @@ short console_row;
static unsigned int panel_width, panel_height;
+#ifndef CONFIG_CMD_BMP
+int bmp_display(ulong addr, int x, int y)
+{
+ return 0;
+}
+#endif
+
static void exynos_lcd_init_mem(void *lcdbase, vidinfo_t *vid)
{
unsigned long palette_size;
diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
index 06eae2e..f957dc8 100644
--- a/drivers/video/exynos_fimd.c
+++ b/drivers/video/exynos_fimd.c
@@ -88,14 +88,18 @@ static void exynos_fimd_set_par(unsigned int win_id)
/* DATAPATH is DMA */
cfg |= EXYNOS_WINCON_DATAPATH_DMA;
- /* bpp is 32 */
- cfg |= EXYNOS_WINCON_WSWP_ENABLE;
+ if (pvid->logo_on) /* To get proprietary LOGO */
+ cfg |= EXYNOS_WINCON_WSWP_ENABLE;
+ else /* To get output console on LCD */
+ cfg |= EXYNOS_WINCON_HAWSWP_ENABLE;
/* dma burst is 16 */
cfg |= EXYNOS_WINCON_BURSTLEN_16WORD;
- /* pixel format is unpacked RGB888 */
- cfg |= EXYNOS_WINCON_BPPMODE_24BPP_888;
+ if (pvid->logo_on) /* To get proprietary LOGO */
+ cfg |= EXYNOS_WINCON_BPPMODE_24BPP_888;
+ else /* To get output console on LCD */
+ cfg |= EXYNOS_WINCON_BPPMODE_16BPP_565;
writel(cfg, (unsigned int)&fimd_ctrl->wincon0 +
EXYNOS_WINCON(win_id));
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 4/4] EXYNOS5: Add support for FIMD and DP
Add panel_info structure required by LCD driver
and DP panel platdata for SMDK5250.
Add GPIO configuration for LCD.
Enable FIMD and DP support on SMDK5250.
DP Panel size: 2560x1600.
We use 16BPP resolution to get LCD console.
Signed-off-by: Ajay Kumar
Acked-by: Simon Glass
---
board/samsung/smdk5250/smdk5250.c | 97 +
include/configs/smdk5250.h|8 +++
2 files changed, 105 insertions(+), 0 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index 4c50342..46fd2a5 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -24,12 +24,15 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
@@ -181,6 +184,100 @@ static int board_uart_init(void)
return 0;
}
+void cfg_lcd_gpio(void)
+{
+ struct exynos5_gpio_part1 *gpio1 =
+ (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
+
+ /* For Backlight */
+ s5p_gpio_cfg_pin(&gpio1->b2, 0, GPIO_OUTPUT);
+ s5p_gpio_set_value(&gpio1->b2, 0, 1);
+
+ /* LCD power on */
+ s5p_gpio_cfg_pin(&gpio1->x1, 5, GPIO_OUTPUT);
+ s5p_gpio_set_value(&gpio1->x1, 5, 1);
+
+ /* Set Hotplug detect for DP */
+ s5p_gpio_cfg_pin(&gpio1->x0, 7, GPIO_FUNC(0x3));
+}
+
+vidinfo_t panel_info = {
+ .vl_freq= 60,
+ .vl_col = 2560,
+ .vl_row = 1600,
+ .vl_width = 2560,
+ .vl_height = 1600,
+ .vl_clkp= CONFIG_SYS_LOW,
+ .vl_hsp = CONFIG_SYS_LOW,
+ .vl_vsp = CONFIG_SYS_LOW,
+ .vl_dp = CONFIG_SYS_LOW,
+ .vl_bpix= 4,/* LCD_BPP = 2^4, for output conosle on LCD */
+
+ /* wDP panel timing infomation */
+ .vl_hspw= 32,
+ .vl_hbpd= 80,
+ .vl_hfpd= 48,
+
+ .vl_vspw= 6,
+ .vl_vbpd= 37,
+ .vl_vfpd= 3,
+ .vl_cmd_allow_len = 0xf,
+
+ .win_id = 3,
+ .cfg_gpio = cfg_lcd_gpio,
+ .backlight_on = NULL,
+ .lcd_power_on = NULL,
+ .reset_lcd = NULL,
+ .dual_lcd_enabled = 0,
+
+ .init_delay = 0,
+ .power_on_delay = 0,
+ .reset_delay= 0,
+ .interface_mode = FIMD_RGB_INTERFACE,
+ .dp_enabled = 1,
+};
+
+static struct edp_device_info edp_info = {
+ .disp_info = {
+ .h_res = 2560,
+ .h_sync_width = 32,
+ .h_back_porch = 80,
+ .h_front_porch = 48,
+ .v_res = 1600,
+ .v_sync_width = 6,
+ .v_back_porch = 37,
+ .v_front_porch = 3,
+ .v_sync_rate = 60,
+ },
+ .lt_info = {
+ .lt_status = DP_LT_NONE,
+ },
+ .video_info = {
+ .master_mode = 0,
+ .bist_mode = DP_DISABLE,
+ .bist_pattern = NO_PATTERN,
+ .h_sync_polarity = 0,
+ .v_sync_polarity = 0,
+ .interlaced = 0,
+ .color_space = COLOR_RGB,
+ .dynamic_range = VESA,
+ .ycbcr_coeff = COLOR_YCBCR601,
+ .color_depth = COLOR_8,
+ },
+};
+
+static struct exynos_dp_platform_data dp_platform_data = {
+ .phy_enable = set_dp_phy_ctrl,
+ .edp_dev_info = &edp_info,
+};
+
+void init_panel_info(vidinfo_t *vid)
+{
+ vid->rgb_mode = MODE_RGB_P,
+
+ exynos_set_dp_platform_data(&dp_platform_data);
+}
+
#ifdef CONFIG_SYS_I2C_INIT_BOARD
static int board_i2c_init(void)
{
diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
index e412da8..a9b3b8b 100644
--- a/include/configs/smdk5250.h
+++ b/include/configs/smdk5250.h
@@ -256,6 +256,14 @@
#define CONFIG_SOUND_WM8994
#endif
+/* Display */
+#define CONFIG_LCD
+#define CONFIG_EXYNOS_FB
+#define CONFIG_EXYNOS_DP
+#define LCD_XRES 2560
+#define LCD_YRES 1600
+#define LCD_BPPLCD_COLOR16
+
/* Enable devicetree support */
#define CONFIG_OF_LIBFDT
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] env_nand.c: support falling back to redundant env when writing
On Thu, Dec 20, 2012 at 03:41:37PM -0600, Scott Wood wrote: > On 12/20/2012 03:28:39 PM, Phil Sutter wrote: > > On Tue, Dec 11, 2012 at 05:12:32PM -0600, Scott Wood wrote: > > > Erase blocks are larger than write pages, yes. I've never heard > > erase > > > blocks called "pages" or write pages called "blocks" -- but my main > > > point is that the unit of erasing and the unit of badness are the > > same. > > > > Ah, OK. Please excuse my humble nomenclature, I never cared enough to > > sort out what is called what. Of course, this is not the best basis > > for > > a discussion about these things. > > > > But getting back to the topic: The assumption of blocks getting bad, > > not > > pages within a block means that for any kind of bad block prevention, > > multiple blocks need to be used. Although I'm honestly speaking not > > really sure why this needs to be like that. Maybe the bad page marking > > would disappear when erasing the block it belongs to? > > Yes, it would disappear. This is why erase operations skip bad blocks, > unless the scrub option is uesd. Which is apparently preventing good pages in a block with a bad page from being used, isn't it? > > > > > The block to hold the environment is stored in the OOB of block > > > > zero, > > > > > which is usually guaranteed to not be bad. > > > > > > > > Erase or write block? Note that every write block has it's own > > OOB. > > > > > > "block" means "erase block". > > > > > > Every write page has its own OOB, but it is erase blocks that are > > > marked bad. Typically the block can be marked bad in either the > > first > > > or the second page of the erase block. > > > > Interesting. I had the impression of pages being marked bad and the > > block's badness being taken from whether it contains bad pages. > > Probably > > the 'nand markbad' command tricked me. > > Do you mean the lack of error checking if you pass a non-block-aligned > offset into "nand markbad"? I think the bigger "problem" is 'nand markbad' updating the bad block table along the go. So no real bad block detection occurs as far as I can tell. > > > > So that assumes that any block initially identified 'good' will > > ever > > > > turn 'bad' later on? > > > > > > We don't currently have any mechanism for that to happen with the > > > environment -- which could be another good reason to have real > > > redundancy that doesn't get crippled from day one by having one copy > > > land on a factory bad block. Of course, that requires someone to > > > implement support for redundant environment combined with > > > CONFIG_ENV_OFFSET_OOB. > > > > Well, as long as CONFIG_ENV_OFFSET_REDUND supported falling back to > > the > > other copy in case of error there would be a working system in three > > of > > four cases instead of only one. > > I'm not sure what you mean here -- where do "three", "four", and "one" > come from? Just some quantitative approach: given the environment residing at block A and it's redundant copy at block B, four situations may occur: both blocks good, block A bad, block B bad or both blocks bad. Upstream would fail in all cases but both blocks good. My patch would turn that into failing only if both blocks bad. So working in three of four cases instead of in only one of four. > > > Maybe a better option is to implement support for storing the > > > environment in ubi, although usually if your environment is in NAND > > > that means your U-Boot image is in NAND, so you have the same > > problem > > > there. Maybe you could have an SPL that contains ubi support, that > > > fits in the guaranteed-good first block. > > > > > > Do you have any data on how often a block might go bad that wasn't > > > factory-bad, to what extent reads versus writes matter, and whether > > > there is anything special about block zero beyond not being > > factory-bad? > > > > No, sadly not. I'd guess this information depends on what hardware > > being > > used specifically. But I suppose block zero being prone to becoming > > worn just like any other block, although it not being erased as often > > should help a lot. > > > > Assuming a certain number of erase cycles after each block is worn out > > and given the fact that CONFIG_ENV_OFFSET_REDUND has always both > > blocks > > written (unless power failure occurs), they would turn bad at the same > > time and therefore rendering the environment useless with or without > > fallback. :) > > That depends on whether the specified number of erase cycles per block > is a minimum for any block not marked factory-bad, or whether some > fraction of non-factory-bad blocks may fail early. Sure. Also I'm not sure how "wear" happens, so if blocks get worse or their probability of failure increases from erase to erase. Although the later case would make it hard to guarantee a certain number of erase cycles. Best wishes, Phil -- Viprinet Europe GmbH Mainzer Str. 43 55411 Bingen am Rhein Germany Phon
Re: [U-Boot] [PATCH V4 4/4] EXYNOS5: Add support for FIMD and DP
Hi Ajay
On Fri, Dec 21, 2012 at 4:05 PM, Ajay Kumar wrote:
> Add panel_info structure required by LCD driver
> and DP panel platdata for SMDK5250.
> Add GPIO configuration for LCD.
> Enable FIMD and DP support on SMDK5250.
> DP Panel size: 2560x1600.
> We use 16BPP resolution to get LCD console.
>
> Signed-off-by: Ajay Kumar
> Acked-by: Simon Glass
> ---
> board/samsung/smdk5250/smdk5250.c | 97
> +
> include/configs/smdk5250.h|8 +++
> 2 files changed, 105 insertions(+), 0 deletions(-)
>
> diff --git a/board/samsung/smdk5250/smdk5250.c
> b/board/samsung/smdk5250/smdk5250.c
> index 4c50342..46fd2a5 100644
> --- a/board/samsung/smdk5250/smdk5250.c
> +++ b/board/samsung/smdk5250/smdk5250.c
> @@ -24,12 +24,15 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> +#include
> #include
>
> DECLARE_GLOBAL_DATA_PTR;
> @@ -181,6 +184,100 @@ static int board_uart_init(void)
> return 0;
> }
>
> +void cfg_lcd_gpio(void)
> +{
> + struct exynos5_gpio_part1 *gpio1 =
> + (struct exynos5_gpio_part1 *)
> samsung_get_base_gpio_part1();
> +
> + /* For Backlight */
> + s5p_gpio_cfg_pin(&gpio1->b2, 0, GPIO_OUTPUT);
> + s5p_gpio_set_value(&gpio1->b2, 0, 1);
> +
> + /* LCD power on */
> + s5p_gpio_cfg_pin(&gpio1->x1, 5, GPIO_OUTPUT);
> + s5p_gpio_set_value(&gpio1->x1, 5, 1);
> +
> + /* Set Hotplug detect for DP */
> + s5p_gpio_cfg_pin(&gpio1->x0, 7, GPIO_FUNC(0x3));
> +}
>
Cant this GPIO changes go to pinmux file?
> +
> +vidinfo_t panel_info = {
> + .vl_freq= 60,
> + .vl_col = 2560,
> + .vl_row = 1600,
> + .vl_width = 2560,
> + .vl_height = 1600,
> + .vl_clkp= CONFIG_SYS_LOW,
> + .vl_hsp = CONFIG_SYS_LOW,
> + .vl_vsp = CONFIG_SYS_LOW,
> + .vl_dp = CONFIG_SYS_LOW,
> + .vl_bpix= 4,/* LCD_BPP = 2^4, for output conosle on
> LCD */
> +
> + /* wDP panel timing infomation */
> + .vl_hspw= 32,
> + .vl_hbpd= 80,
> + .vl_hfpd= 48,
> +
> + .vl_vspw= 6,
> + .vl_vbpd= 37,
> + .vl_vfpd= 3,
> + .vl_cmd_allow_len = 0xf,
> +
> + .win_id = 3,
> + .cfg_gpio = cfg_lcd_gpio,
> + .backlight_on = NULL,
> + .lcd_power_on = NULL,
> + .reset_lcd = NULL,
> + .dual_lcd_enabled = 0,
> +
> + .init_delay = 0,
> + .power_on_delay = 0,
> + .reset_delay= 0,
> + .interface_mode = FIMD_RGB_INTERFACE,
> + .dp_enabled = 1,
> +};
> +
> +static struct edp_device_info edp_info = {
> + .disp_info = {
> + .h_res = 2560,
> + .h_sync_width = 32,
> + .h_back_porch = 80,
> + .h_front_porch = 48,
> + .v_res = 1600,
> + .v_sync_width = 6,
> + .v_back_porch = 37,
> + .v_front_porch = 3,
> + .v_sync_rate = 60,
> + },
> + .lt_info = {
> + .lt_status = DP_LT_NONE,
> + },
> + .video_info = {
> + .master_mode = 0,
> + .bist_mode = DP_DISABLE,
> + .bist_pattern = NO_PATTERN,
> + .h_sync_polarity = 0,
> + .v_sync_polarity = 0,
> + .interlaced = 0,
> + .color_space = COLOR_RGB,
> + .dynamic_range = VESA,
> + .ycbcr_coeff = COLOR_YCBCR601,
> + .color_depth = COLOR_8,
> + },
> +};
> +
> +static struct exynos_dp_platform_data dp_platform_data = {
> + .phy_enable = set_dp_phy_ctrl,
> + .edp_dev_info = &edp_info,
> +};
> +
> +void init_panel_info(vidinfo_t *vid)
> +{
> + vid->rgb_mode = MODE_RGB_P,
> +
> + exynos_set_dp_platform_data(&dp_platform_data);
> +}
> +
> #ifdef CONFIG_SYS_I2C_INIT_BOARD
> static int board_i2c_init(void)
> {
> diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
> index e412da8..a9b3b8b 100644
> --- a/include/configs/smdk5250.h
> +++ b/include/configs/smdk5250.h
> @@ -256,6 +256,14 @@
> #define CONFIG_SOUND_WM8994
> #endif
>
> +/* Display */
> +#define CONFIG_LCD
> +#define CONFIG_EXYNOS_FB
> +#define CONFIG_EXYNOS_DP
> +#define LCD_XRES 2560
> +#define LCD_YRES 1600
> +#define LCD_BPPLCD_COLOR16
> +
> /* Enable devicetree support */
> #define CONFIG_OF_LIBFDT
>
> --
> 1.7.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
--
Regards,
Rajeshwari Shinde
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/
Re: [U-Boot] [PATCH V4 4/4] EXYNOS5: Add support for FIMD and DP
Dear Rajeshwari,
On 21/12/12 20:47, Rajeshwari Birje wrote:
> Hi Ajay
>
> On Fri, Dec 21, 2012 at 4:05 PM, Ajay Kumar wrote:
>
>> Add panel_info structure required by LCD driver
>> and DP panel platdata for SMDK5250.
>> Add GPIO configuration for LCD.
>> Enable FIMD and DP support on SMDK5250.
>> DP Panel size: 2560x1600.
>> We use 16BPP resolution to get LCD console.
>>
>> Signed-off-by: Ajay Kumar
>> Acked-by: Simon Glass
>> ---
>> board/samsung/smdk5250/smdk5250.c | 97
>> +
>> include/configs/smdk5250.h|8 +++
>> 2 files changed, 105 insertions(+), 0 deletions(-)
>>
>> diff --git a/board/samsung/smdk5250/smdk5250.c
>> b/board/samsung/smdk5250/smdk5250.c
>> index 4c50342..46fd2a5 100644
>> --- a/board/samsung/smdk5250/smdk5250.c
>> +++ b/board/samsung/smdk5250/smdk5250.c
>> @@ -24,12 +24,15 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> +#include
>> #include
>>
>> DECLARE_GLOBAL_DATA_PTR;
>> @@ -181,6 +184,100 @@ static int board_uart_init(void)
>> return 0;
>> }
>>
>> +void cfg_lcd_gpio(void)
>> +{
>> + struct exynos5_gpio_part1 *gpio1 =
>> + (struct exynos5_gpio_part1 *)
>> samsung_get_base_gpio_part1();
>> +
>> + /* For Backlight */
>> + s5p_gpio_cfg_pin(&gpio1->b2, 0, GPIO_OUTPUT);
>> + s5p_gpio_set_value(&gpio1->b2, 0, 1);
>> +
>> + /* LCD power on */
>> + s5p_gpio_cfg_pin(&gpio1->x1, 5, GPIO_OUTPUT);
>> + s5p_gpio_set_value(&gpio1->x1, 5, 1);
>> +
>> + /* Set Hotplug detect for DP */
>> + s5p_gpio_cfg_pin(&gpio1->x0, 7, GPIO_FUNC(0x3));
>> +}
>>
> Cant this GPIO changes go to pinmux file?
>
No. It is a board specific feature.
So, can't be located in pinmux file.
Thanks.
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 4/4] EXYNOS5: Add support for FIMD and DP
On Friday, December 21, 2012, Rajeshwari Birje wrote:
> Hi Ajay
>
> On Fri, Dec 21, 2012 at 4:05 PM, Ajay Kumar
>
> >wrote:
>
> > Add panel_info structure required by LCD driver
> > and DP panel platdata for SMDK5250.
> > Add GPIO configuration for LCD.
> > Enable FIMD and DP support on SMDK5250.
> > DP Panel size: 2560x1600.
> > We use 16BPP resolution to get LCD console.
> >
> > Signed-off-by: Ajay Kumar >
> > Acked-by: Simon Glass >
> > ---
> > board/samsung/smdk5250/smdk5250.c | 97
> > +
> > include/configs/smdk5250.h|8 +++
> > 2 files changed, 105 insertions(+), 0 deletions(-)
> >
> > diff --git a/board/samsung/smdk5250/smdk5250.c
> > b/board/samsung/smdk5250/smdk5250.c
> > index 4c50342..46fd2a5 100644
> > --- a/board/samsung/smdk5250/smdk5250.c
> > +++ b/board/samsung/smdk5250/smdk5250.c
> > @@ -24,12 +24,15 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > +#include
> > #include
> >
> > DECLARE_GLOBAL_DATA_PTR;
> > @@ -181,6 +184,100 @@ static int board_uart_init(void)
> > return 0;
> > }
> >
> > +void cfg_lcd_gpio(void)
> > +{
> > + struct exynos5_gpio_part1 *gpio1 =
> > + (struct exynos5_gpio_part1 *)
> > samsung_get_base_gpio_part1();
> > +
> > + /* For Backlight */
> > + s5p_gpio_cfg_pin(&gpio1->b2, 0, GPIO_OUTPUT);
> > + s5p_gpio_set_value(&gpio1->b2, 0, 1);
> > +
> > + /* LCD power on */
> > + s5p_gpio_cfg_pin(&gpio1->x1, 5, GPIO_OUTPUT);
> > + s5p_gpio_set_value(&gpio1->x1, 5, 1);
> > +
> > + /* Set Hotplug detect for DP */
> > + s5p_gpio_cfg_pin(&gpio1->x0, 7, GPIO_FUNC(0x3));
> > +}
> >
> Cant this GPIO changes go to pinmux file?
>
>
> No it's smdk5250 specific. Other board has different GPIOs.
Thank you,
Kyungmin Park
> > +
> > +vidinfo_t panel_info = {
> > + .vl_freq= 60,
> > + .vl_col = 2560,
> > + .vl_row = 1600,
> > + .vl_width = 2560,
> > + .vl_height = 1600,
> > + .vl_clkp= CONFIG_SYS_LOW,
> > + .vl_hsp = CONFIG_SYS_LOW,
> > + .vl_vsp = CONFIG_SYS_LOW,
> > + .vl_dp = CONFIG_SYS_LOW,
> > + .vl_bpix= 4,/* LCD_BPP = 2^4, for output conosle on
> > LCD */
> > +
> > + /* wDP panel timing infomation */
> > + .vl_hspw= 32,
> > + .vl_hbpd= 80,
> > + .vl_hfpd= 48,
> > +
> > + .vl_vspw= 6,
> > + .vl_vbpd= 37,
> > + .vl_vfpd= 3,
> > + .vl_cmd_allow_len = 0xf,
> > +
> > + .win_id = 3,
> > + .cfg_gpio = cfg_lcd_gpio,
> > + .backlight_on = NULL,
> > + .lcd_power_on = NULL,
> > + .reset_lcd = NULL,
> > + .dual_lcd_enabled = 0,
> > +
> > + .init_delay = 0,
> > + .power_on_delay = 0,
> > + .reset_delay= 0,
> > + .interface_mode = FIMD_RGB_INTERFACE,
> > + .dp_enabled = 1,
> > +};
> > +
> > +static struct edp_device_info edp_info = {
> > + .disp_info = {
> > + .h_res = 2560,
> > + .h_sync_width = 32,
> > + .h_back_porch = 80,
> > + .h_front_porch = 48,
> > + .v_res = 1600,
> > + .v_sync_width = 6,
> > + .v_back_porch = 37,
> > + .v_front_porch = 3,
> > + .v_sync_rate = 60,
> > + },
> > + .lt_info = {
> > + .lt_status = DP_LT_NONE,
> > + },
> > + .video_info = {
> > + .master_mode = 0,
> > + .bist_mode = DP_DISABLE,
> > + .bist_pattern = NO_PATTERN,
> > + .h_sync_polarity = 0,
> > + .v_sync_polarity = 0,
> > + .interlaced = 0,
> > + .color_space = COLOR_RGB,
> > + .dynamic_range = VESA,
> > + .ycbcr_coeff = COLOR_YCBCR601,
> > + .color_depth = COLOR_8,
> > + },
> > +};
> > +
> > +static struct exynos_dp_platform_data dp_platform_data = {
> > + .phy_enable = set_dp_phy_ctrl,
> > + .edp_dev_info = &edp_info,
> > +};
> > +
> > +void init_panel_info(vidinfo_t *vid)
> > +{
> > + vid->rgb_mode = MODE_RGB_P,
> > +
> > + exynos_set_dp_platform_data(&dp_platform_data);
> > +}
> > +
> > #ifdef CONFIG_SYS_I2C_INIT_BOARD
> > static int board_i2c_init(void)
> > {
> > diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
> > index e412da8..a9b3b8b 100644
> > --- a/inc--
> Regards,
> Rajeshwari Shinde
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 4/4] EXYNOS5: Add support for FIMD and DP
Hi Minkyu,
Thank you for clarification.
On Fri, Dec 21, 2012 at 5:35 PM, Minkyu Kang wrote:
> Dear Rajeshwari,
>
> On 21/12/12 20:47, Rajeshwari Birje wrote:
> > Hi Ajay
> >
> > On Fri, Dec 21, 2012 at 4:05 PM, Ajay Kumar >wrote:
> >
> >> Add panel_info structure required by LCD driver
> >> and DP panel platdata for SMDK5250.
> >> Add GPIO configuration for LCD.
> >> Enable FIMD and DP support on SMDK5250.
> >> DP Panel size: 2560x1600.
> >> We use 16BPP resolution to get LCD console.
> >>
> >> Signed-off-by: Ajay Kumar
> >> Acked-by: Simon Glass
> >> ---
> >> board/samsung/smdk5250/smdk5250.c | 97
> >> +
> >> include/configs/smdk5250.h|8 +++
> >> 2 files changed, 105 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/board/samsung/smdk5250/smdk5250.c
> >> b/board/samsung/smdk5250/smdk5250.c
> >> index 4c50342..46fd2a5 100644
> >> --- a/board/samsung/smdk5250/smdk5250.c
> >> +++ b/board/samsung/smdk5250/smdk5250.c
> >> @@ -24,12 +24,15 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >> +#include
> >> #include
> >>
> >> DECLARE_GLOBAL_DATA_PTR;
> >> @@ -181,6 +184,100 @@ static int board_uart_init(void)
> >> return 0;
> >> }
> >>
> >> +void cfg_lcd_gpio(void)
> >> +{
> >> + struct exynos5_gpio_part1 *gpio1 =
> >> + (struct exynos5_gpio_part1 *)
> >> samsung_get_base_gpio_part1();
> >> +
> >> + /* For Backlight */
> >> + s5p_gpio_cfg_pin(&gpio1->b2, 0, GPIO_OUTPUT);
> >> + s5p_gpio_set_value(&gpio1->b2, 0, 1);
> >> +
> >> + /* LCD power on */
> >> + s5p_gpio_cfg_pin(&gpio1->x1, 5, GPIO_OUTPUT);
> >> + s5p_gpio_set_value(&gpio1->x1, 5, 1);
> >> +
> >> + /* Set Hotplug detect for DP */
> >> + s5p_gpio_cfg_pin(&gpio1->x0, 7, GPIO_FUNC(0x3));
> >> +}
> >>
> > Cant this GPIO changes go to pinmux file?
> >
>
> No. It is a board specific feature.
> So, can't be located in pinmux file.
>
ok
>
> Thanks.
> Minkyu Kang.
>
--
Regards,
Rajeshwari Shinde
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] B4860/B4420 patches and some updates for qixis and T4240QDS
The patchset contains the following patches: Mainly related to B4860/B4420QDS. Some are qixis updates and related additions for B4860/B4420QDS and T4240QDS. [PATCH 01/09] powerpc/mpc85xx: Few updates for B4860 cpu changes [PATCH 02/09] powerpc/mpc85xx:Add support of B4420 SoC [PATCH 03/09] board/freescale/common:Add support of QTAG register [PATCH 04/09] powerpc/mpc85xx:Fix Core cluster configuration loop [PATCH 05/09] powerpc/b4860qds: Added Support for B4860QDS [PATCH 06/09] powerpc/qixis: enable qixis dump command and add switch dumping command [PATCH 07/09] powerpc/b4860qds: Add support to dump switch settings on b4860qds board [PATCH 08/09] powerpc/t4240qds: Add support to dump switch settings on t4240qds board [PATCH 09/09] powerpc/t4240qds: Print FPGA detail version Regards Poonam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/09] powerpc/mpc85xx: Few updates for B4860 cpu changes
- Added some more serdes1 and serdes2 combinations
serdes1= 0x2c, 0x2d, 0x2e
serdes2= 0x7a, 0x8d, 0x98
- Updated Number of DDR controllers to 2.
- Added FMAN file for B4860, drivers/net/fm/b4860.c
Signed-off-by: York Sun
Signed-off-by: Shaveta Leekha
Signed-off-by: Prabhakar Kushwaha
Signed-off-by: Sandeep Singh
Signed-off-by: Poonam Aggrwal
---
Changes in v2: Added Shaveta's, York's, Sandeep's and Prabhakar's signoff.
arch/powerpc/cpu/mpc85xx/b4860_serdes.c | 15 ++
arch/powerpc/include/asm/config_mpc85xx.h |2 +-
drivers/net/fm/b4860.c| 79 +
3 files changed, 95 insertions(+), 1 deletions(-)
create mode 100644 drivers/net/fm/b4860.c
diff --git a/arch/powerpc/cpu/mpc85xx/b4860_serdes.c
b/arch/powerpc/cpu/mpc85xx/b4860_serdes.c
index 9990202..0028280 100644
--- a/arch/powerpc/cpu/mpc85xx/b4860_serdes.c
+++ b/arch/powerpc/cpu/mpc85xx/b4860_serdes.c
@@ -41,6 +41,12 @@ static struct serdes_config serdes1_cfg_tbl[] = {
CPRI4, CPRI3, CPRI2, CPRI1}},
{0x2a, {SGMII_FM1_DTSEC5, SGMII_FM1_DTSEC6,
CPRI6, CPRI5, CPRI4, CPRI3, CPRI2, CPRI1}},
+ {0x2C, {SGMII_FM1_DTSEC5, SGMII_FM1_DTSEC6,
+ CPRI6, CPRI5, CPRI4, CPRI3, CPRI2, CPRI1}},
+ {0x2D, {SGMII_FM1_DTSEC5, SGMII_FM1_DTSEC6,
+ CPRI6, CPRI5, CPRI4, CPRI3, CPRI2, CPRI1}},
+ {0x2E, {SGMII_FM1_DTSEC5, SGMII_FM1_DTSEC6,
+ CPRI6, CPRI5, CPRI4, CPRI3, CPRI2, CPRI1}},
{0x30, {AURORA, AURORA,
SGMII_FM1_DTSEC3, SGMII_FM1_DTSEC4,
CPRI4, CPRI3, CPRI2, CPRI1}},
@@ -84,6 +90,8 @@ static struct serdes_config serdes2_cfg_tbl[] = {
{0x4E, {SGMII_FM1_DTSEC1, SGMII_FM1_DTSEC2,
SGMII_FM1_DTSEC3, AURORA,
SRIO1, SRIO1, SRIO1, SRIO1}},
+ {0x7A, {SRIO2, SRIO2, SRIO2, SRIO2,
+ SRIO1, SRIO1, SRIO1, SRIO1}},
{0x84, {SGMII_FM1_DTSEC1, SGMII_FM1_DTSEC2,
SRIO2, SRIO2, AURORA, AURORA,
XFI_FM1_MAC9, XFI_FM1_MAC10}},
@@ -94,6 +102,9 @@ static struct serdes_config serdes2_cfg_tbl[] = {
SRIO2, SRIO2,
SGMII_FM1_DTSEC3, SGMII_FM1_DTSEC4,
XFI_FM1_MAC9, XFI_FM1_MAC10}},
+ {0x8D, {SRIO2, SRIO2, SRIO2, SRIO2,
+ SGMII_FM1_DTSEC3, SGMII_FM1_DTSEC4,
+ XFI_FM1_MAC9, XFI_FM1_MAC10}},
{0x93, {SGMII_FM1_DTSEC1, SGMII_FM1_DTSEC2,
SGMII_FM1_DTSEC3, SGMII_FM1_DTSEC4,
XAUI_FM1_MAC10, XAUI_FM1_MAC10,
@@ -111,6 +122,10 @@ static struct serdes_config serdes2_cfg_tbl[] = {
{0xC3, {XAUI_FM1_MAC9, XAUI_FM1_MAC9,
XAUI_FM1_MAC9, XAUI_FM1_MAC9,
SRIO1, SRIO1, SRIO1, SRIO1}},
+ {0x98, {XAUI_FM1_MAC9, XAUI_FM1_MAC9,
+ XAUI_FM1_MAC9, XAUI_FM1_MAC9,
+ XAUI_FM1_MAC10, XAUI_FM1_MAC10,
+ XAUI_FM1_MAC10, XAUI_FM1_MAC10}},
{}
};
static struct serdes_config *serdes_cfg_tbl[] = {
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index 0b9638b..856ae95 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -537,7 +537,7 @@
#define CONFIG_SYS_NUM_FMAN1
#define CONFIG_SYS_NUM_FM1_DTSEC 6
#define CONFIG_SYS_NUM_FM1_10GEC 2
-#define CONFIG_NUM_DDR_CONTROLLERS 1
+#define CONFIG_NUM_DDR_CONTROLLERS 2
#define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_4_7
#define CONFIG_SYS_FMAN_V3
#define CONFIG_SYS_FM_MURAM_SIZE 0x6
diff --git a/drivers/net/fm/b4860.c b/drivers/net/fm/b4860.c
new file mode 100644
index 000..8cde7af
--- /dev/null
+++ b/drivers/net/fm/b4860.c
@@ -0,0 +1,79 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Roy Zang
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+u32 port_to_devdisr[] = {
+ [FM1_DTSEC1] = FSL_CORENET_DEVDISR2_DTSEC1_1,
+ [FM1_DTSEC2] = FSL_CORENET_DEVDISR2_DTSEC1_2,
+ [FM1_DTSEC3] = FSL_CORENET_DEVDISR2_DTSEC1_3,
+ [FM1_DTSEC4] = FSL_CORENET_DEVDISR2_DTSEC1_4,
+ [FM1_DTSEC5] = FSL_CORENET_DEVDISR2_DTSEC1_5,
+ [FM1_DTSEC6] = FSL_CORENET_DEVDISR
[U-Boot] [PATCH 03/09] board/freescale/common:Add support of QTAG register
From: Prabhakar Kushwaha
QIXIS FPGA's QIXIS Tag Access register (QTAG) defines TAG, VER, DATE, IMAGE
fields. These fields have FPGA build version, image name and build date
information.
Add support to parse these fields to have complete FPGA image information.
Signed-off-by: York Sun
Signed-off-by: Prabhakar Kushwaha
Signed-off-by: Poonam Aggrwal
---
board/freescale/common/qixis.c | 46
board/freescale/common/qixis.h |3 ++
2 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/board/freescale/common/qixis.c b/board/freescale/common/qixis.c
index c92902a..2cf393b 100644
--- a/board/freescale/common/qixis.c
+++ b/board/freescale/common/qixis.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "qixis.h"
u8 qixis_read(unsigned int reg)
@@ -30,6 +31,51 @@ void qixis_write(unsigned int reg, u8 value)
out_8(p + reg, value);
}
+u16 qixis_read_minor(void)
+{
+ u16 minor;
+
+ /* this data is in little endian */
+ QIXIS_WRITE(tagdata, 5);
+ minor = QIXIS_READ(tagdata);
+ QIXIS_WRITE(tagdata, 6);
+ minor += QIXIS_READ(tagdata) << 8;
+
+ return minor;
+}
+
+char *qixis_read_time(char *result)
+{
+ time_t time = 0;
+ int i;
+
+ /* timestamp is in 32-bit big endian */
+ for (i = 8; i <= 11; i++) {
+ QIXIS_WRITE(tagdata, i);
+ time = (time << 8) + QIXIS_READ(tagdata);
+ }
+
+ return ctime_r(&time, result);
+}
+
+char *qixis_read_tag(char *buf)
+{
+ int i;
+ char tag, *ptr = buf;
+
+ for (i = 16; i <= 63; i++) {
+ QIXIS_WRITE(tagdata, i);
+ tag = QIXIS_READ(tagdata);
+ *(ptr++) = tag;
+ if (!tag)
+ break;
+ }
+ if (i > 63)
+ *ptr = '\0';
+
+ return buf;
+}
+
void qixis_reset(void)
{
QIXIS_WRITE(rst_ctl, QIXIS_RST_CTL_RESET);
diff --git a/board/freescale/common/qixis.h b/board/freescale/common/qixis.h
index b98b180..4d73461 100644
--- a/board/freescale/common/qixis.h
+++ b/board/freescale/common/qixis.h
@@ -88,6 +88,9 @@ struct qixis {
u8 qixis_read(unsigned int reg);
void qixis_write(unsigned int reg, u8 value);
+u16 qixis_read_minor(void);
+char *qixis_read_time(char *result);
+char *qixis_read_tag(char *buf);
#define QIXIS_READ(reg) qixis_read(offsetof(struct qixis, reg))
#define QIXIS_WRITE(reg, value) qixis_write(offsetof(struct qixis, reg), value)
--
1.6.5.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/09] powerpc/mpc85xx:Fix Core cluster configuration loop
From: Prabhakar Kushwaha
Different personalities/derivatives of SoC may have reduced cluster. But it is
not necessary for last valid DCFG_CCSR_TP_CLUSTER register to have
DCFG_CCSR_TP_CLUSTER[EOC] bit set to represent "End of Clusters".
EOC bit can still be set in last DCFG_CCSR_TP_CLUSTER register of orignal SoC
which may not be valid for the personality.
So add initiator type check to find valid cluster.
Signed-off-by: Prabhakar Kushwaha
Signed-off-by: Poonam Aggrwal
---
arch/powerpc/cpu/mpc85xx/cpu_init.c | 30 ++
1 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index d1155e8..cc09300 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -312,19 +312,33 @@ int enable_cluster_l2(void)
/* Look through the remaining clusters, and set up their caches */
do {
+ int j, cluster_valid = 0;
+
l2cache = (void __iomem *)(CONFIG_SYS_FSL_CLUSTER_1_L2 + i *
0x4);
+
cluster = in_be32(&gur->tp_cluster[i].lower);
- /* set stash ID to (cluster) * 2 + 32 + 1 */
- clrsetbits_be32(&l2cache->l2csr1, 0xff, 32 + i * 2 + 1);
+ /* check that at least one core/accel is enabled in cluster */
+ for (j = 0; j < 4; j++) {
+ u32 idx = (cluster >> (j*8)) & TP_CLUSTER_INIT_MASK;
+ u32 type = in_be32(&gur->tp_ityp[idx]);
- printf("enable l2 for cluster %d %p\n", i, l2cache);
+ if (type & TP_ITYP_AV)
+ cluster_valid = 1;
+ }
- out_be32(&l2cache->l2csr0, L2CSR0_L2FI|L2CSR0_L2LFC);
- while ((in_be32(&l2cache->l2csr0) &
- (L2CSR0_L2FI|L2CSR0_L2LFC)) != 0)
- ;
- out_be32(&l2cache->l2csr0, L2CSR0_L2E);
+ if (cluster_valid) {
+ /* set stash ID to (cluster) * 2 + 32 + 1 */
+ clrsetbits_be32(&l2cache->l2csr1, 0xff, 32 + i * 2 + 1);
+
+ printf("enable l2 for cluster %d %p\n", i, l2cache);
+
+ out_be32(&l2cache->l2csr0, L2CSR0_L2FI|L2CSR0_L2LFC);
+ while ((in_be32(&l2cache->l2csr0)
+ & (L2CSR0_L2FI|L2CSR0_L2LFC)) != 0)
+ ;
+ out_be32(&l2cache->l2csr0, L2CSR0_L2E);
+ }
i++;
} while (!(cluster & TP_CLUSTER_EOC));
--
1.6.5.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/09] powerpc/mpc85xx:Add support of B4420 SoC
B4420 is a reduced personality of B4860 with fewer core/clusters(both SC3900
and e6500), fewer DDR controllers, fewer serdes lanes, fewer SGMII interfaces
and
reduced target frequencies.
Key differences between B4860 and B4420
B4420 has:
1. Fewer e6500 cores: 1 cluster with 2 e6500 cores
2. Fewer SC3900 cores/clusters: 1 cluster with 2 SC3900 cores per cluster.
3. Single DDRC
4. 2X 4 lane serdes
5. 3 SGMII interfaces
6. no sRIO
7. no 10G
Signed-off-by: Prabhakar Kushwaha
Signed-off-by: Poonam Aggrwal
---
arch/powerpc/cpu/mpc85xx/Makefile |3 ++
arch/powerpc/cpu/mpc85xx/b4860_ids.c |6
arch/powerpc/cpu/mpc85xx/b4860_serdes.c | 45 +
arch/powerpc/include/asm/config_mpc85xx.h | 21 +
arch/powerpc/include/asm/immap_85xx.h |2 +-
drivers/net/fm/Makefile |1 +
6 files changed, 77 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/Makefile
b/arch/powerpc/cpu/mpc85xx/Makefile
index 4c2b104..95994d3 100644
--- a/arch/powerpc/cpu/mpc85xx/Makefile
+++ b/arch/powerpc/cpu/mpc85xx/Makefile
@@ -83,6 +83,7 @@ COBJS-$(CONFIG_PPC_P4080) += ddr-gen3.o
COBJS-$(CONFIG_PPC_P5020) += ddr-gen3.o
COBJS-$(CONFIG_PPC_P5040) += ddr-gen3.o
COBJS-$(CONFIG_PPC_T4240) += ddr-gen3.o
+COBJS-$(CONFIG_PPC_B4420) += ddr-gen3.o
COBJS-$(CONFIG_PPC_B4860) += ddr-gen3.o
COBJS-$(CONFIG_BSC9131)+= ddr-gen3.o
@@ -100,6 +101,7 @@ COBJS-$(CONFIG_PPC_P4080) += p4080_ids.o
COBJS-$(CONFIG_PPC_P5020) += p5020_ids.o
COBJS-$(CONFIG_PPC_P5040) += p5040_ids.o
COBJS-$(CONFIG_PPC_T4240) += t4240_ids.o
+COBJS-$(CONFIG_PPC_B4420) += b4860_ids.o
COBJS-$(CONFIG_PPC_B4860) += b4860_ids.o
COBJS-$(CONFIG_QE) += qe_io.o
@@ -134,6 +136,7 @@ COBJS-$(CONFIG_PPC_P4080) += p4080_serdes.o
COBJS-$(CONFIG_PPC_P5020) += p5020_serdes.o
COBJS-$(CONFIG_PPC_P5040) += p5040_serdes.o
COBJS-$(CONFIG_PPC_T4240) += t4240_serdes.o
+COBJS-$(CONFIG_PPC_B4420) += b4860_serdes.o
COBJS-$(CONFIG_PPC_B4860) += b4860_serdes.o
COBJS-y+= cpu.o
diff --git a/arch/powerpc/cpu/mpc85xx/b4860_ids.c
b/arch/powerpc/cpu/mpc85xx/b4860_ids.c
index 7d33731..0f4e82e 100644
--- a/arch/powerpc/cpu/mpc85xx/b4860_ids.c
+++ b/arch/powerpc/cpu/mpc85xx/b4860_ids.c
@@ -55,11 +55,13 @@ struct qportal_info qp_info[CONFIG_SYS_QMAN_NUM_PORTALS] = {
};
#endif
+#ifdef CONFIG_SYS_SRIO
struct srio_liodn_id_table srio_liodn_tbl[] = {
SET_SRIO_LIODN_1(1, 307),
SET_SRIO_LIODN_1(2, 387),
};
int srio_liodn_tbl_sz = ARRAY_SIZE(srio_liodn_tbl);
+#endif
struct liodn_id_table liodn_tbl[] = {
#ifdef CONFIG_SYS_DPAA_QBMAN
@@ -76,10 +78,12 @@ struct liodn_id_table liodn_tbl[] = {
SET_DMA_LIODN(1, 147),
SET_DMA_LIODN(2, 227),
+#ifndef CONFIG_PPC_B4420
SET_GUTS_LIODN("fsl,rapidio-delta", 199, rio1liodnr, 0),
SET_GUTS_LIODN(NULL, 200, rio2liodnr, 0),
SET_GUTS_LIODN(NULL, 201, rio1maintliodnr, 0),
SET_GUTS_LIODN(NULL, 202, rio2maintliodnr, 0),
+#endif
/* SET_NEXUS_LIODN(557), -- not yet implemented */
};
@@ -93,8 +97,10 @@ struct liodn_id_table fman1_liodn_tbl[] = {
SET_FMAN_RX_1G_LIODN(1, 3, 91),
SET_FMAN_RX_1G_LIODN(1, 4, 92),
SET_FMAN_RX_1G_LIODN(1, 5, 93),
+#ifndef CONFIG_PPC_B4420
SET_FMAN_RX_10G_LIODN(1, 0, 94),
SET_FMAN_RX_10G_LIODN(1, 1, 95),
+#endif
};
int fman1_liodn_tbl_sz = ARRAY_SIZE(fman1_liodn_tbl);
#endif
diff --git a/arch/powerpc/cpu/mpc85xx/b4860_serdes.c
b/arch/powerpc/cpu/mpc85xx/b4860_serdes.c
index 0028280..bd32342 100644
--- a/arch/powerpc/cpu/mpc85xx/b4860_serdes.c
+++ b/arch/powerpc/cpu/mpc85xx/b4860_serdes.c
@@ -31,6 +31,7 @@ struct serdes_config {
u8 lanes[SRDS_MAX_LANES];
};
+#ifdef CONFIG_PPC_B4860
static struct serdes_config serdes1_cfg_tbl[] = {
/* SerDes 1 */
{0x0D, {CPRI8, CPRI7, CPRI6, CPRI5,
@@ -128,6 +129,50 @@ static struct serdes_config serdes2_cfg_tbl[] = {
XAUI_FM1_MAC10, XAUI_FM1_MAC10}},
{}
};
+#endif
+
+#ifdef CONFIG_PPC_B4420
+static struct serdes_config serdes1_cfg_tbl[] = {
+ {0x0D, {NONE, NONE, CPRI6, CPRI5,
+ CPRI4, CPRI3, NONE, NONE} },
+ {0x0E, {NONE, NONE, CPRI8, CPRI5,
+ CPRI4, CPRI3, NONE, NONE} },
+ {0x0F, {NONE, NONE, CPRI6, CPRI5,
+ CPRI4, CPRI3, NONE, NONE} },
+ {0x18, {NONE, NONE,
+ SGMII_FM1_DTSEC3, SGMII_FM1_DTSEC4,
+ NONE, NONE, NONE, NONE} },
+ {0x1B, {NONE, NONE,
+ SGMII_FM1_DTSEC3, SGMII_FM1_DTSEC4,
+ NONE, NONE, NONE, NONE} },
+ {0x1E, {NONE, NONE, AURORA, AURORA,
+ NONE, NONE, NONE, NONE} },
+ {0x21, {NONE, NONE, AURORA, AURORA,
+ NONE, NONE, NONE, NONE} },
+ {0x3E, {NONE, NONE, CPRI6, CPRI5,
+ CPRI4, CPRI3, NONE, NONE} },
+ {}
+};
+static struct serdes_config se
[U-Boot] [PATCH 06/09] powerpc/qixis: enable qixis dump command and add switch dumping command
From: Shaveta Leekha
Remove #ifdef so that "qixis dump" command is always available
Add "qixis_reset switch" command to dump switch settings
Qixis doesn't have 1:1 switch mapping. We need to reverse engineer from
registers to figure out switch settings. Not all bits are available.
Signed-off-by: York Sun
Signed-off-by: Shaveta Leekha
Signed-off-by: Poonam Aggrwal
---
board/freescale/common/qixis.c | 47 +--
board/freescale/common/qixis.h |1 +
2 files changed, 36 insertions(+), 12 deletions(-)
diff --git a/board/freescale/common/qixis.c b/board/freescale/common/qixis.c
index 2cf393b..f7d2f46 100644
--- a/board/freescale/common/qixis.c
+++ b/board/freescale/common/qixis.c
@@ -76,6 +76,27 @@ char *qixis_read_tag(char *buf)
return buf;
}
+/*
+ * return the string of binary of u8 in the format of
+ * 1010 10_0. The masked bit is filled as underscore.
+ */
+const char *byte_to_binary_mask(u8 val, u8 mask, char *buf)
+{
+ char *ptr;
+ int i;
+
+ ptr = buf;
+ for (i = 0x80; i > 0x08 ; i >>= 1, ptr++)
+ *ptr = (val & i) ? '1' : ((mask & i) ? '_' : '0');
+ *(ptr++) = ' ';
+ for (i = 0x08; i > 0 ; i >>= 1, ptr++)
+ *ptr = (val & i) ? '1' : ((mask & i) ? '_' : '0');
+
+ *ptr = '\0';
+
+ return buf;
+}
+
void qixis_reset(void)
{
QIXIS_WRITE(rst_ctl, QIXIS_RST_CTL_RESET);
@@ -107,7 +128,6 @@ void set_altbank(void)
QIXIS_WRITE(brdcfg[0], reg);
}
-#ifdef DEBUG
static void qixis_dump_regs(void)
{
int i;
@@ -137,7 +157,14 @@ static void qixis_dump_regs(void)
printf("stat_sys = %02x\n", QIXIS_READ(stat_sys));
printf("stat_alrm = %02x\n", QIXIS_READ(stat_alrm));
}
-#endif
+
+static void __qixis_dump_switch(void)
+{
+ puts("Reverse engineering switch is not implemented for this board\n");
+}
+
+void qixis_dump_switch(void)
+ __attribute__((weak, alias("__qixis_dump_switch")));
int qixis_reset_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
@@ -168,16 +195,13 @@ int qixis_reset_cmd(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return 0;
}
}
- }
-
-#ifdef DEBUG
- else if (strcmp(argv[1], "dump") == 0) {
+ } else if (strcmp(argv[1], "dump") == 0) {
qixis_dump_regs();
return 0;
- }
-#endif
-
- else {
+ } else if (strcmp(argv[1], "switch") == 0) {
+ qixis_dump_switch();
+ return 0;
+ } else {
printf("Invalid option: %s\n", argv[1]);
return 1;
}
@@ -192,7 +216,6 @@ U_BOOT_CMD(
"qixis_reset altbank - reset to alternate bank\n"
"qixis watchdog - set the watchdog period\n"
" period: 1s 2s 4s 8s 16s 32s 1min 2min 4min 8min\n"
-#ifdef DEBUG
"qixis_reset dump - display the QIXIS registers\n"
-#endif
+ "qixis_reset switch - display switch\n"
);
diff --git a/board/freescale/common/qixis.h b/board/freescale/common/qixis.h
index 4d73461..2b8f607 100644
--- a/board/freescale/common/qixis.h
+++ b/board/freescale/common/qixis.h
@@ -91,6 +91,7 @@ void qixis_write(unsigned int reg, u8 value);
u16 qixis_read_minor(void);
char *qixis_read_time(char *result);
char *qixis_read_tag(char *buf);
+const char *byte_to_binary_mask(u8 val, u8 mask, char *buf);
#define QIXIS_READ(reg) qixis_read(offsetof(struct qixis, reg))
#define QIXIS_WRITE(reg, value) qixis_write(offsetof(struct qixis, reg), value)
--
1.6.5.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/09] powerpc/b4860qds: Add support to dump switch settings on b4860qds board
From: Shaveta Leekha
This function is called by "qixis_reset switch" command
and switch settings are calculated from FPGA/qixis registers.
Signed-off-by: York Sun
Signed-off-by: Shaveta Leekha
Signed-off-by: Poonam Aggrwal
---
board/freescale/b4860qds/b4860qds.c | 47 +++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/board/freescale/b4860qds/b4860qds.c
b/board/freescale/b4860qds/b4860qds.c
index 88bdc1f..3c470db 100644
--- a/board/freescale/b4860qds/b4860qds.c
+++ b/board/freescale/b4860qds/b4860qds.c
@@ -456,3 +456,50 @@ void ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_board_enet(blob);
#endif
}
+
+/*
+ * Dump board switch settings.
+ * The bits that cannot be read/sampled via some FPGA or some
+ * registers, they will be displayed as
+ * underscore in binary format. mask[] has those bits.
+ * Some bits are calculated differently than the actual switches
+ * if booting with overriding by FPGA.
+ */
+void qixis_dump_switch(void)
+{
+ int i;
+ u8 sw[5];
+
+ /*
+* Any bit with 1 means that bit cannot be reverse engineered.
+* It will be displayed as _ in binary format.
+*/
+ static const u8 mask[] = {0x07, 0, 0, 0xff, 0};
+ char buf[10];
+ u8 brdcfg[16], dutcfg[16];
+
+ for (i = 0; i < 16; i++) {
+ brdcfg[i] = qixis_read(offsetof(struct qixis, brdcfg[0]) + i);
+ dutcfg[i] = qixis_read(offsetof(struct qixis, dutcfg[0]) + i);
+ }
+
+ sw[0] = ((brdcfg[0] & 0x0f) << 4) | \
+ (brdcfg[9] & 0x08);
+ sw[1] = ((dutcfg[1] & 0x01) << 7) | \
+ ((dutcfg[2] & 0x07) << 4) | \
+ ((dutcfg[6] & 0x10) >> 1) | \
+ ((dutcfg[6] & 0x80) >> 5) | \
+ ((dutcfg[1] & 0x40) >> 5) | \
+ (dutcfg[6] & 0x01);
+ sw[2] = dutcfg[0];
+ sw[3] = 0;
+ sw[4] = ((brdcfg[1] & 0x30) << 2) | \
+ ((brdcfg[1] & 0xc0) >> 2) | \
+ (brdcfg[1] & 0x0f);
+
+ puts("DIP switch settings:\n");
+ for (i = 0; i < 5; i++) {
+ printf("SW%d = 0b%s (0x%02x)\n",
+ i + 1, byte_to_binary_mask(sw[i], mask[i], buf), sw[i]);
+ }
+}
--
1.6.5.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/09] powerpc/t4240qds: Add support to dump switch settings on t4240qds board
From: Shaveta Leekha
This function is called by "qixis_reset switch" command and
switch settings are calculated from qixis FPGA registers.
Signed-off-by: York Sun
Signed-off-by: Shaveta Leekha
Signed-off-by: Poonam Aggrwal
---
board/freescale/t4qds/t4qds.c | 60 +
1 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/board/freescale/t4qds/t4qds.c b/board/freescale/t4qds/t4qds.c
index 88b8ced..ac1ce62 100644
--- a/board/freescale/t4qds/t4qds.c
+++ b/board/freescale/t4qds/t4qds.c
@@ -393,3 +393,63 @@ void ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_board_enet(blob);
#endif
}
+
+/*
+ * Reverse engineering switch settings.
+ * Some bits cannot be figured out. They will be displayed as
+ * underscore in binary format. mask[] has those bits.
+ * Some bits are calculated differently than the actual switches
+ * if booting with overriding by FPGA.
+ */
+void qixis_dump_switch(void)
+{
+ int i;
+ u8 sw[9];
+
+ /*
+* Any bit with 1 means that bit cannot be reverse engineered.
+* It will be displayed as _ in binary format.
+*/
+ static const u8 mask[] = {0, 0, 0, 0, 0, 0x1, 0xdf, 0x3f, 0x1f};
+ char buf[10];
+ u8 brdcfg[16], dutcfg[16];
+
+ for (i = 0; i < 16; i++) {
+ brdcfg[i] = qixis_read(offsetof(struct qixis, brdcfg[0]) + i);
+ dutcfg[i] = qixis_read(offsetof(struct qixis, dutcfg[0]) + i);
+ }
+
+ sw[0] = dutcfg[0];
+ sw[1] = (dutcfg[1] << 0x07) | \
+ ((dutcfg[12] & 0xC0) >> 1) | \
+ ((dutcfg[11] & 0xE0) >> 3) | \
+ ((dutcfg[6] & 0x80) >> 6) | \
+ ((dutcfg[1] & 0x80) >> 7);
+ sw[2] = ((brdcfg[1] & 0x0f) << 4) | \
+ ((brdcfg[1] & 0x30) >> 2) | \
+ ((brdcfg[1] & 0x40) >> 5) | \
+ ((brdcfg[1] & 0x80) >> 7);
+ sw[3] = brdcfg[2];
+ sw[4] = ((dutcfg[2] & 0x01) << 7) | \
+ ((dutcfg[2] & 0x06) << 4) | \
+ ((~QIXIS_READ(present)) & 0x10) | \
+ ((brdcfg[3] & 0x80) >> 4) | \
+ ((brdcfg[3] & 0x01) << 2) | \
+ ((brdcfg[6] == 0x62) ? 3 : \
+ ((brdcfg[6] == 0x5a) ? 2 : \
+ ((brdcfg[6] == 0x5e) ? 1 : 0)));
+ sw[5] = ((brdcfg[0] & 0x0f) << 4) | \
+ ((QIXIS_READ(rst_ctl) & 0x30) >> 2) | \
+ ((brdcfg[0] & 0x40) >> 5);
+ sw[6] = (brdcfg[11] & 0x20);
+ sw[7] = (((~QIXIS_READ(rst_ctl)) & 0x40) << 1) | \
+ ((brdcfg[5] & 0x10) << 2);
+ sw[8] = ((brdcfg[12] & 0x08) << 4) | \
+ ((brdcfg[12] & 0x03) << 5);
+
+ puts("DIP switch (reverse-engineering)\n");
+ for (i = 0; i < 9; i++) {
+ printf("SW%d = 0b%s (0x%02x)\n",
+ i + 1, byte_to_binary_mask(sw[i], mask[i], buf), sw[i]);
+ }
+}
--
1.6.5.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/09] powerpc/t4240qds: Print FPGA detail version
From: Prabhakar Kushwaha
Qixis FPGA has tag data contains image name and build date.
It is helpful to identify the FPGA image precisely.
Signed-off-by: York Sun
Acked-by: Timur Tabi
Signed-off-by: Prabhakar Kushwaha
Signed-off-by: Poonam Aggrwal
---
board/freescale/t4qds/t4qds.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/board/freescale/t4qds/t4qds.c b/board/freescale/t4qds/t4qds.c
index ac1ce62..c2a4cef 100644
--- a/board/freescale/t4qds/t4qds.c
+++ b/board/freescale/t4qds/t4qds.c
@@ -44,14 +44,15 @@ DECLARE_GLOBAL_DATA_PTR;
int checkboard(void)
{
+ char buf[64];
u8 sw;
struct cpu_type *cpu = gd->cpu;
ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
unsigned int i;
printf("Board: %sQDS, ", cpu->name);
- printf("Sys ID: 0x%02x, Sys Ver: 0x%02x, FPGA Ver: 0x%02x, ",
- QIXIS_READ(id), QIXIS_READ(arch), QIXIS_READ(scver));
+ printf("Sys ID: 0x%02x, Sys Ver: 0x%02x, ",
+ QIXIS_READ(id), QIXIS_READ(arch));
sw = QIXIS_READ(brdcfg[0]);
sw = (sw & QIXIS_LBMAP_MASK) >> QIXIS_LBMAP_SHIFT;
@@ -65,6 +66,12 @@ int checkboard(void)
else
printf("invalid setting of SW%u\n", QIXIS_LBMAP_SWITCH);
+ printf("FPGA: v%d (%s), build %d",
+ (int)QIXIS_READ(scver), qixis_read_tag(buf),
+ (int)qixis_read_minor());
+ /* the timestamp string contains "\n" at the end */
+ printf(" on %s", qixis_read_time(buf));
+
/* Display the RCW, so that no one gets confused as to what RCW
* we're actually using for this boot.
*/
--
1.6.5.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
Take 3 ... I dropped in the missing twl4030 patch, rebuilt, here you go: The following changes since commit ebbf0d20aa85f623c49b7ed3349ebfea450c152d: Prepare v2013.01-rc2 (2012-12-14 14:43:22 -0700) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 41984e71231c7af4a5617f4f94f372714c64d987: cm_t35: use new low level interface for usb ehci (2012-12-20 17:04:21 +0100) Lukasz Dalek (2): pxa25x_udc: Remove usbdescriptors.h h2200: Add USB CDC ethernet support Milind Choudhary (1): usb: Clean up newly allocated device nodes in case of configuration failure Nikita Kiryanov (3): twl4030: add gpio register offsets cm-t35: add USB host support cm_t35: use new low level interface for usb ehci Pantelis Antoniou (2): g_dnl: Issue connect/disconnect as appropriate g_dnl: Properly terminate string list. Richard Genoud (1): usb documentation: fix typo Vincent Palatin (1): usb: properly detect empty mass storage media reader Vipin Kumar (1): usbh/ehci: Increase timeout for enumeration board/cm_t35/cm_t35.c | 77 + board/h2200/h2200.c | 11 +++ common/usb.c| 12 common/usb_hub.c| 35 ++- common/usb_storage.c| 10 ++ doc/README.usb |2 +- drivers/usb/gadget/g_dnl.c | 12 +++- drivers/usb/gadget/pxa25x_udc.c |1 - include/configs/cm_t35.h|8 +++- include/configs/h2200.h | 25 + include/twl4030.h | 44 include/usb.h |1 + 12 files changed, 229 insertions(+), 9 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: bugfix: Move vector table before jumping relocated code
Hi Tesuyuki and friends, I had a question with this patch. On Wed, Jun 27, 2012 at 8:27 PM, Tetsuyuki Kobayashi wrote: >>> This patch moves vector table before jumping relocated code. >>> >>> Signed-off-by: Tetsuyuki Kobayashi >>> --- >>> arch/arm/cpu/armv7/start.S | 12 >>> 1 file changed, 12 insertions(+) >>> >>> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S >>> index 52f7f6e..5098f7b 100644 >>> --- a/arch/arm/cpu/armv7/start.S >>> +++ b/arch/arm/cpu/armv7/start.S >>> @@ -277,6 +277,18 @@ jump_2_ram: >>> mcr p15, 0, r0, c7, c10, 4 @ DSB >>> mcr p15, 0, r0, c7, c5, 4 @ ISB >>> #endif >>> +/* >>> + * Move vector table >>> + */ >>> +#if !defined(CONFIG_TEGRA2) >>> +#if !(defined(CONFIG_OMAP44XX)&& defined(CONFIG_SPL_BUILD)) >>> >>> + /* Set vector address in CP15 VBAR register */ >>> + ldr r0, =_start >>> + add r0, r0, r9 >>> + mcr p15, 0, r0, c12, c0, 0 @Set VBAR >>> +#endif Why is c12 (VBAR) setup only for SPL builds? Because main u-boot does relocation too, shouldn't we setup c12 to point to new table addr after relocation? Also how do interrupts (irq/fiq) work at all in U-boot if c12 is not setup to point to the new vector table address after relocation? Thanks, Joel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/9] Improve default environment for easy use
This patchset improves the default environment of machines currently
supported in OpenEmbedded and Yocto to make it compatible with
mainline and Freescale BSP Linux kernel.
Otavio Salvador (9):
mx28evk: We shouldn't hardcode a rootfs filesystem type
mx53loco: We shouldn't hardcode a rootfs filesystem type
mx53loco: Change default loadaddr to 0x7200
mx6qsabrelite: Change default loadaddr to 0x1200
mx6qsabre_common: Change default loadaddr to 0x1200
mx28evk: Add support to dynamically choose between ftd use or not
mx53loco: Add support to dynamically choose between ftd use or not
mx6qsabrelite: Add support to dynamically choose between ftd use or
not
mx6qsabre{auto,sd}: Add support to dynamically choose between ftd use
or not
include/configs/mx28evk.h | 22 +++---
include/configs/mx53loco.h | 24
include/configs/mx6qsabre_common.h | 18 ++
include/configs/mx6qsabreauto.h|1 +
include/configs/mx6qsabrelite.h| 18 +++---
include/configs/mx6qsabresd.h |1 +
6 files changed, 62 insertions(+), 22 deletions(-)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/9] mx53loco: We shouldn't hardcode a rootfs filesystem type
For a generic environment, we shouldn't have a fixed rootfs filesystem
so we drop it from env.
Signed-off-by: Otavio Salvador
---
include/configs/mx53loco.h |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index e30502b..5f8f52e 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -120,11 +120,8 @@
"uimage=uImage\0" \
"mmcdev=0\0" \
"mmcpart=2\0" \
- "mmcroot=/dev/mmcblk0p3 rw\0" \
- "mmcrootfstype=ext3 rootwait\0" \
- "mmcargs=setenv bootargs console=ttymxc0,${baudrate} " \
- "root=${mmcroot} " \
- "rootfstype=${mmcrootfstype}\0" \
+ "mmcroot=/dev/mmcblk0p3 rw rootwait\0" \
+ "mmcargs=setenv bootargs console=ttymxc0,${baudrate} root=${mmcroot} " \
"loadbootscript=" \
"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/9] mx53loco: Change default loadaddr to 0x72000000
This allow use of mainline and Freescale BSP Linux kernel with same environment. Signed-off-by: Otavio Salvador --- include/configs/mx53loco.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h index 5f8f52e..4cfdc0b 100644 --- a/include/configs/mx53loco.h +++ b/include/configs/mx53loco.h @@ -112,7 +112,7 @@ #define CONFIG_ETHPRIME"FEC0" -#define CONFIG_LOADADDR0x7080 /* loadaddr env var */ +#define CONFIG_LOADADDR0x7200 /* loadaddr env var */ #define CONFIG_SYS_TEXT_BASE0x7780 #define CONFIG_EXTRA_ENV_SETTINGS \ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/9] mx6qsabre_common: Change default loadaddr to 0x12000000
This allow use of mainline and Freescale BSP Linux kernel with same environment. Signed-off-by: Otavio Salvador --- include/configs/mx6qsabre_common.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/mx6qsabre_common.h b/include/configs/mx6qsabre_common.h index 0f226f7..9a25480 100644 --- a/include/configs/mx6qsabre_common.h +++ b/include/configs/mx6qsabre_common.h @@ -78,7 +78,7 @@ #define CONFIG_BOOTDELAY 1 -#define CONFIG_LOADADDR0x1080 +#define CONFIG_LOADADDR0x1200 #define CONFIG_SYS_TEXT_BASE 0x1780 #define CONFIG_EXTRA_ENV_SETTINGS \ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/9] mx6qsabrelite: Change default loadaddr to 0x12000000
This allow use of mainline and Freescale BSP Linux kernel with same environment. Signed-off-by: Otavio Salvador --- include/configs/mx6qsabrelite.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index 4ce4d4c..0f6bbb4 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -148,7 +148,7 @@ #define CONFIG_PREBOOT "" -#define CONFIG_LOADADDR 0x1080 +#define CONFIG_LOADADDR 0x1200 #define CONFIG_SYS_TEXT_BASE 0x1780 #define CONFIG_EXTRA_ENV_SETTINGS \ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/9] mx53loco: Add support to dynamically choose between ftd use or not
Signed-off-by: Otavio Salvador
---
include/configs/mx53loco.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index 4cfdc0b..505957c 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -118,6 +118,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
"uimage=uImage\0" \
+ "ftd_file=imx53-qsb.dtb\0" \
+ "ftd_addr=0x7100\0" \
"mmcdev=0\0" \
"mmcpart=2\0" \
"mmcroot=/dev/mmcblk0p3 rw rootwait\0" \
@@ -129,13 +131,22 @@
"loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
- "bootm\0" \
+ "if fatload mmc ${mmcdev}:${mmcpart} ${ftd_addr} ${ftd_file};
then " \
+ "bootm ${loadaddr} - ${ftd_addr}; " \
+ "else " \
+ "bootm; " \
+ "fi;\0" \
"netargs=setenv bootargs console=ttymxc0,${baudrate} " \
"root=/dev/nfs " \
"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
"netboot=echo Booting from net ...; " \
"run netargs; " \
- "dhcp ${uimage}; bootm\0" \
+ "dhcp ${uimage}; " \
+ "if dhcp ${ftd_addr} ${ftd_file}; then " \
+ "bootm ${loadaddr} - ${ftd_addr}; " \
+ "else " \
+ "bootm; " \
+ "fi;\0"
#define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/9] mx28evk: We shouldn't hardcode a rootfs filesystem type
For a generic environment, we shouldn't have a fixed rootfs filesystem
so we drop it from env.
Signed-off-by: Otavio Salvador
---
include/configs/mx28evk.h |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 8b89b25..3cc0726 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -292,11 +292,8 @@
"console_mainline=ttyAMA0\0" \
"mmcdev=0\0" \
"mmcpart=2\0" \
- "mmcroot=/dev/mmcblk0p3 rw\0" \
- "mmcrootfstype=ext3 rootwait\0" \
- "mmcargs=setenv bootargs console=${console_mainline},${baudrate} " \
- "root=${mmcroot} " \
- "rootfstype=${mmcrootfstype}\0" \
+ "mmcroot=/dev/mmcblk0p3 rw rootwait\0" \
+ "mmcargs=setenv bootargs console=${console_mainline},${baudrate}
root=${mmcroot}\0" \
"loadbootscript=" \
"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/9] mx28evk: Add support to dynamically choose between ftd use or not
Signed-off-by: Otavio Salvador
---
include/configs/mx28evk.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 3cc0726..5c1c052 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -290,6 +290,8 @@
"uimage=uImage\0" \
"console_fsl=ttyAM0\0" \
"console_mainline=ttyAMA0\0" \
+ "ftd_file=imx28-evk.dtb\0" \
+ "ftd_addr=0x4100\0" \
"mmcdev=0\0" \
"mmcpart=2\0" \
"mmcroot=/dev/mmcblk0p3 rw rootwait\0" \
@@ -301,13 +303,22 @@
"loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
- "bootm\0" \
+ "if fatload mmc ${mmcdev}:${mmcpart} ${ftd_addr} ${ftd_file};
then " \
+ "bootm ${loadaddr} - ${ftd_addr}; " \
+ "else " \
+ "bootm; " \
+ "fi;\0" \
"netargs=setenv bootargs console=${console_mainline},${baudrate} " \
"root=/dev/nfs " \
"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
"netboot=echo Booting from net ...; " \
"run netargs; " \
- "dhcp ${uimage}; bootm\0"
+ "dhcp ${uimage}; " \
+ "if dhcp ${ftd_addr} ${ftd_file}; then " \
+ "bootm ${loadaddr} - ${ftd_addr}; " \
+ "else " \
+ "bootm; " \
+ "fi;\0"
#define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 9/9] mx6qsabre{auto, sd}: Add support to dynamically choose between ftd use or not
Signed-off-by: Otavio Salvador
---
include/configs/mx6qsabre_common.h | 16 +---
include/configs/mx6qsabreauto.h|1 +
include/configs/mx6qsabresd.h |1 +
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/include/configs/mx6qsabre_common.h
b/include/configs/mx6qsabre_common.h
index 9a25480..a7fe15b 100644
--- a/include/configs/mx6qsabre_common.h
+++ b/include/configs/mx6qsabre_common.h
@@ -84,6 +84,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
"uimage=uImage\0" \
+ "ftd_file=" CONFIG_DEFAULT_FTD_FILE "\0" \
+ "ftd_addr=0x1100\0" \
"console=" CONFIG_CONSOLE_DEV "\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
@@ -98,14 +100,22 @@
"source\0" \
"loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
"mmcboot=echo Booting from mmc ...; " \
- "run mmcargs; " \
- "bootm\0" \
+ "if fatload mmc ${mmcdev}:${mmcpart} ${ftd_addr} ${ftd_file};
then " \
+ "bootm ${loadaddr} - ${ftd_addr}; " \
+ "else " \
+ "bootm; " \
+ "fi;\0" \
"netargs=setenv bootargs console=${console},${baudrate} " \
"root=/dev/nfs " \
"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
"netboot=echo Booting from net ...; " \
"run netargs; " \
- "dhcp ${uimage}; bootm\0" \
+ "dhcp ${uimage}; " \
+ "if dhcp ${ftd_addr} ${ftd_file}; then " \
+ "bootm ${loadaddr} - ${ftd_addr}; " \
+ "else " \
+ "bootm; " \
+ "fi;\0"
#define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev};" \
diff --git a/include/configs/mx6qsabreauto.h b/include/configs/mx6qsabreauto.h
index 760f3ce..e255c27 100644
--- a/include/configs/mx6qsabreauto.h
+++ b/include/configs/mx6qsabreauto.h
@@ -15,6 +15,7 @@
#define CONFIG_MACH_TYPE 3529
#define CONFIG_MXC_UART_BASE UART4_BASE
#define CONFIG_CONSOLE_DEV "ttymxc3"
+#define CONFIG_DEFAULT_FTD_FILE"imx6q-sabreauto.dtb"
#define CONFIG_MMCROOT "/dev/mmcblk0p2"
#define PHYS_SDRAM_SIZE(2u * 1024 * 1024 * 1024)
diff --git a/include/configs/mx6qsabresd.h b/include/configs/mx6qsabresd.h
index 771d129..b30dec0 100644
--- a/include/configs/mx6qsabresd.h
+++ b/include/configs/mx6qsabresd.h
@@ -21,6 +21,7 @@
#define CONFIG_MXC_UART_BASE UART1_BASE
#define CONFIG_CONSOLE_DEV "ttymxc0"
#define CONFIG_MMCROOT "/dev/mmcblk1p2"
+#define CONFIG_DEFAULT_FTD_FILE"imx6q-sabresd.dtb"
#define PHYS_SDRAM_SIZE(1u * 1024 * 1024 * 1024)
#include "mx6qsabre_common.h"
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/9] mx6qsabrelite: Add support to dynamically choose between ftd use or not
Signed-off-by: Otavio Salvador
---
include/configs/mx6qsabrelite.h | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h
index 0f6bbb4..c74d75c 100644
--- a/include/configs/mx6qsabrelite.h
+++ b/include/configs/mx6qsabrelite.h
@@ -154,6 +154,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
"uimage=uImage\0" \
+ "ftd_file=imx6q-sabrelite.dtb\0" \
+ "ftd_addr=0x1100\0" \
"console=ttymxc1\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
@@ -169,13 +171,23 @@
"loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
- "bootm\0" \
+ "if fatload mmc ${mmcdev}:${mmcpart} ${ftd_addr} ${ftd_file};
then " \
+ "bootm ${loadaddr} - ${ftd_addr}; " \
+ "else " \
+ "bootm; " \
+ "fi;\0" \
"netargs=setenv bootargs console=${console},${baudrate} " \
"root=/dev/nfs " \
"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
"netboot=echo Booting from net ...; " \
"run netargs; " \
- "dhcp ${uimage}; bootm\0" \
+ "dhcp ${uimage}; " \
+ "if dhcp ${ftd_addr} ${ftd_file}; then " \
+ "bootm ${loadaddr} - ${ftd_addr}; " \
+ "else " \
+ "bootm; " \
+ "fi;\0"
+
#define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev};" \
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`
Hi Jagan,
On Fri, Dec 21, 2012 at 12:46 AM, Jagan Teki wrote:
> Hi Simon,
>
> On Thu, Dec 20, 2012 at 6:48 AM, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, Dec 19, 2012 at 5:03 PM, Tom Rini wrote:
> >> On Thu, Dec 20, 2012 at 12:14:00AM +0100, Wolfgang Denk wrote:
> >>> Dear Tom Rini,
> >>>
> >>> In message <20121219225945.GF14589@bill-the-cat> you wrote:
> >>> >
> >>> ...
> >>> > With this change, applied to u-boot/master.
> >>>
> >>> Argh :-(
> >>>
> >>> Can we please undo this somehow? This does not fit at all
> >>> conceptually. U-Boot is supposed to use the good ols UNIX philosophy
> >>> of being terse by default, and special casing one specific storage
> >>> device makes no sense at all to me.
> >>
> >> We need to fix some of the underlying problems so that we're consistent
> >> here. Sometimes we have output (network #), sometimes we don't.
> >> Sometimes we have a speed (network, filesystem load), sometimes we
> >> don't. I'd be quite happy to have a uniform output and a uniform ON/OFF
> >> switch.
> >
> > I'm happy to do something like this. Obviously we want a config, but
> > do we also want an env variable to control it? Could be useful.
> >
> > And at the risk of killing it with feature creep, perhaps we could
> > have two levels of verbosity: progress (which repeatedly updates on
> > the same line) and notice (which does not). That might take care of
> > Jagannadha's use case also.
> >
>
> Any plan to add config for verbose messages on cmd_sf.c?
> seems like you plan for something, because I have some couple of patches
> which has verbose messages for sf read/erase/write commands.
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149753
Yes there seems to be a plan. Perhaps I will sketch out a few ideas so that
people can comment:
Add two environment variables:
verbose=0|1- if this is 0, then commands complete silently as now. If
>=1 then messages like the ones you propose ('flash successfully erased')
appear
progress=0|1- if this is 0, then commands show no progress when
working. If >=1 then some commands will show progress as they work (all on
a single line like 'sf update')
We also need a CONFIG for each to enable it, like perhaps
CONFIG_SYS_VERBOSE and CONFIG_SYS_PROGRESS.
Then I suppose we need a few functions like:
struct progress_info {
uint count; /* Number of things we are going to count through */
uint upto;/* Current thing we are up to */
int flags;
/* flags like whether to convert to KB/MB/etc., and whether to show
bytes per second */
/* may need to record column position of last message so we can clear it
at the end */
};
void progress_setup(struct progress_info *progress, uint count, int flags);
void progress_update(struct progress_info *progress, uint upto);
void progress_done(struct progress_info *progress)
void verbose_printf()
which compile to nothing if the CONFIG options are not enabled. Will need
to look at each current instance of this sort of code though and make sure
that this covers everything that is needed.
I haven't done anything on this and won't get to it for several weeks,
which is why I am posting ideas here for comment.
Regards,
Simon
>
>
> Thanks,
> Jagan.
>
> > Regards,
> > Simon
> >
> >>
> >> --
> >> Tom
> >>
> >> ___
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de
> >> http://lists.denx.de/mailman/listinfo/u-boot
> >>
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] where is the crc stored?
What area of memory is the crc stored for a partition? I would like to find some detailed documentation on the crc (how big is it, where it is stored, how to invalidate to force the booting from a second area). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] no mtdparted from U-Boot> prompt
On Fri, 2012-12-21 at 17:59 +0800, Bo Shen wrote: > Hi Johns, > > On 12/21/2012 07:53 AM, jo...@msli.com wrote: > > This is my first post to the list. > > I am using u-boot-1.3.4 in buildroot-2011.11 > > My device is a at91sam9g20-ek > > I have a patch adding: include/configs/at91sam9g20ek.h > > which I gather acts as a config file for u-boot. > > > > U-Boot> help > > does not list mtdparts > > > > But my bootargs does use it: > > bootargs=mem=64M console=ttyS0,115200 > > mtdparts=atmel_nand:4M(bootstrap/uboot/kernel)ro,60M(rootfs),-(data) > > root=/dev/mtdblock1 rw rootfstype=jffs2 > > This mtdparts is defined for Linux kernel NAND driver. I had the impression there was also an interactive command-line tool for mtdparts, from the u-boot prompt. > > > > Is there a trick to add the mtdparts command? > > Yes, you need to add "#define CONFIG_CMD_MTDPARTS" in > I added this to include/configs/at91sam9g20ek.h Now it contains: #define CONFIG_JFFS2_NAND 1 #define CONFIG_JFFS2_CMDLINE 1 #define CONFIG_CMD_JFFS2 #define CONFIG_CMD_MTDPARTS" NOTICE: This email may contain confidential information. Please see http://www.meyersound.com/confidential/ for our complete policy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Hello. On Tue, 2012-12-18 at 12:25, Lukasz Majewski wrote: > > > Can you paste the log of your dfu-util session? Are you supplying a > > transfer size for example? > > > > Regards > > u-boot-denx/master (denx.de) repository > > SHA1: fd4d564b3c80b111f18c93adb14233a6a7ddb0e9 > > (without Pantelis patches) > > dfu-util version 0.7 (not working): > > lukma@amdc308:~/work/u-boot-denx(master)$ ../dfu-util/src/dfu-util -V > -v -t 0x1000 -a0 -D u-boot.bin dfu-util 0.7 > > Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc. > Copyright 2010-2012 Tormod Volden and Stefan Schmidt > This program is Free Software and has ABSOLUTELY NO WARRANTY > Please report bugs to dfu-u...@lists.gnumonks.org > > Opening DFU capable USB device... ID 04e8:6601 > Did not find cached descriptor > WARNING: Can not find cached DFU functional descriptor > Warning: Assuming DFU version 1.0 > Run-time device DFU version 0100 > Found DFU: [04e8:6601] devnum=0, cfg=2, intf=0, alt=0, name="u-boot" > Claiming USB DFU Interface... > Setting Alternate Setting #0 ... > Determining device status: state = dfuIDLE, status = 0 > dfuIDLE, continuing > Did not find cached descriptor > Error obtaining cached DFU functional descriptor > Error obtaining DFU functional descriptor > Please report this as a bug! > Warning: Assuming DFU version 1.0 > Warning: Transfer size can not be detected > DFU mode device DFU version 0100 > Error: Transfer size must be specified > > Broken. > > dfu-util version. 0.1+svnexported (available at debian repository > (0.0+r4067-3.1)) > > lukma@amdc308:~/work/u-boot-denx(master)$ dfu-util -v -t 0x1000 -a0 -D > u-boot.bin dfu-util - (C) 2007 by OpenMoko Inc. > This program is Free Software and has ABSOLUTELY NO WARRANTY > > Opening USB Device 0x:0x... > Found Runtime: [0x04e8:0x6601] devnum=77, cfg=0, intf=0, alt=0, > name="u-boot" Claiming USB DFU Interface... > Setting Alternate Setting ... > Determining device status: state = dfuIDLE, status = 0 > dfuIDLE, continuing > Error obtaining DFU functional descriptor: error sending control > message: Broken pipe Transfer Size = 0x1000 > bytes_per_hash=5591 > Starting download: [##] > finished! state(2) = dfuIDLE, status(0) = No error condition is present > Done! > > WORKS. > > Ok, so world has went forward. And I've left behind :-/. > > > With Pantelis Patches: > > lukma@amdc308:~/work/u-boot-denx(NEW_DFU)$ ../dfu-util/src/dfu-util -V > -v -t 0x1000 -a0 -D u-boot.bin dfu-util 0.7 > > Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc. > Copyright 2010-2012 Tormod Volden and Stefan Schmidt > This program is Free Software and has ABSOLUTELY NO WARRANTY > Please report bugs to dfu-u...@lists.gnumonks.org > > Opening DFU capable USB device... ID 04e8:6601 > Did not find cached descriptor > WARNING: Can not find cached DFU functional descriptor > Warning: Assuming DFU version 1.0 > Run-time device DFU version 0100 > Claiming USB DFU Runtime Interface... > Determining device status: state = appIDLE, status = 0 > Device really in Runtime Mode, send DFU detach request... > Resetting USB... > Opening DFU USB Device... > Found DFU: [04e8:6601] devnum=0, cfg=2, intf=0, alt=0, name="u-boot" > Claiming USB DFU Interface... > Setting Alternate Setting #0 ... > Determining device status: state = dfuIDLE, status = 0 > dfuIDLE, continuing > Did not find cached descriptor > Error obtaining cached DFU functional descriptor > DFU mode device DFU version 0110 > Device returned transfer size 4096 > No valid DFU suffix signature > Warning: File has no DFU suffix > bytes_per_hash=6280 > Copying data from PC to DFU device > Starting download: [##] > finished! Sent a total of 314004 bytes > state(2) = dfuIDLE, status(0) = No error condition is present > Done! > > > Ok, so it seems to work (CRC is correct, system boots). The reason > of the turmoil from my side was the VERY OLD version of dfu-utils, > which I've used for testing. Indeed that was the problem. We changed quite a bit in dfu-util to get the actual informations from the USB functional descriptor. And it seems that was not provided correctly from the u-boot DFU implementation before. Good to have that fixed. We are really careful not to introduce regressions when going forward with dfu-util but some stuff is just way to problematic to keep when moving on. I wonder where you actually got such an old version of dfu-util. We work together with packagers to get new versions in all recent distros. Might be worth to fill a bug about updting it for yours. regards Stefan Schmidt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`
Dear Simon,
In message
you wrote:
>
> Yes there seems to be a plan. Perhaps I will sketch out a few ideas so that
> people can comment:
Thanks!
> Add two environment variables:
>
> verbose=0|1- if this is 0, then commands complete silently as now. If
> >=1 then messages like the ones you propose ('flash successfully erased')
> appear
If verbose is not set in the environment, the effect should be the
same as for "verbose=0".
It may even make sense to support other numeric values, too, so you
can even control the level of verbocity.
> progress=0|1- if this is 0, then commands show no progress when
> working. If >=1 then some commands will show progress as they work (all on
> a single line like 'sf update')
Ditto for default if not set.
We should very much try to avoid the use of control sequences
including '\b' or '\r' characters. These are a nightmare when
analyzing log files, not to mention the pain they often cause in
automatic regression test scripts.
If this makes single line output impossible (like when the total file
size is not known in advance so we can adjust the scaling), then I'd
rather see multiple lines (as we have now with the tftp / nfs
commands).
> We also need a CONFIG for each to enable it, like perhaps
> CONFIG_SYS_VERBOSE and CONFIG_SYS_PROGRESS.
This should be no _SYS, as it should be user-selectable.
>/* may need to record column position of last message so we can clear it
> at the end */
Clear? Just print a '\n' and continue on a new line, please.
Thanks.
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
EMACS belongs in : Editor too big!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] where is the crc stored?
Dear John Stile, In message <1356114777.28896.92.camel@genx> you wrote: > What area of memory is the crc stored for a partition? Which sort of partitions are you talking here? > I would like to find some detailed documentation on the crc (how big is > it, where it is stored, how to invalidate to force the booting from a > second area). In general, erasing the whole region will usually work ;-) 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 Q: Why do mountain climbers rope themselves together? A: To prevent the sensible ones from going home. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] : Please pull u-boot-imx
Hi Stefano, On Sat, 08 Dec 2012 15:16:39 +0100, Stefano Babic wrote: > Hi Albert, > > please pull from u-boot-imx, master. Conflicts are fixed, request pull > is generated from u-boot/master, as I merged it (so you see also the > commits you have already merged into u-boot-arm from my previous pull > request): > > The following changes since commit fd4d564b3c80b111f18c93adb14233a6a7ddb0e9: > > Merge branch 'master' of git://git.denx.de/u-boot-x86 (2012-12-07 > 08:47:59 -0700) > > are available in the git repository at: > > > git://www.denx.de/git/u-boot-imx.git master > > for you to fetch changes up to 05a860c228fe6c8f2e7aced8cc8ef88bc1038363: > > Merge branch 'master' of git://git.denx.de/u-boot into master > (2012-12-08 12:02:45 +0100) Hmm, your request says master but the 'up to' points to 'master merge'. As master has a few more commits including changes to woodburn boards that makes them use the new power interface, I guess I should ignore the 'up to' and simply use master (b874df74...)? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] EXYNOS5: FDT: Add DWMMC device node data
Hi,
On Fri, Dec 21, 2012 at 1:19 AM, Jaehoon Chung wrote:
> On 12/20/2012 10:55 AM, Simon Glass wrote:
> > Hi Amar,
> >
> > On Mon, Dec 17, 2012 at 3:19 AM, Amar wrote:
> >> Add DWMMC device node data for exynos5
> >>
> >> Signed-off-by: Amar
> >> ---
> >> arch/arm/dts/exynos5250.dtsi | 32
> +
> >> board/samsung/dts/exynos5250-smdk5250.dts | 24 +
> >
> > Do you also have a binding file for this please?
> >
> >> 2 files changed, 56 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
> >> index 1008797..b701ae5 100644
> >> --- a/arch/arm/dts/exynos5250.dtsi
> >> +++ b/arch/arm/dts/exynos5250.dtsi
> >> @@ -138,4 +138,36 @@
> >> reg = <0x131b 0x30>;
> >> interrupts = <0 130 0>;
> >> };
> >> +
> >> + dwmmc@1220 {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + compatible = "samsung,exynos5250-dwmmc";
> >> + reg = <0x1220 0x1000>;
> >> + interrupts = <0 75 0>;
> >> + };
> >> +
> >> + dwmmc@1221 {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + compatible = "samsung,exynos5250-dwmmc";
> >> + reg = <0x1221 0x1000>;
> >> + interrupts = <0 76 0>;
> >> + };
> >> +
> >> + dwmmc@1222 {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + compatible = "samsung,exynos5250-dwmmc";
> >> + reg = <0x1222 0x1000>;
> >> + interrupts = <0 77 0>;
> >> + };
> >> +
> >> + dwmmc@1223 {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + compatible = "samsung,exynos5250-dwmmc";
> >> + reg = <0x1223 0x1000>;
> >> + interrupts = <0 78 0>;
> >> + };
> >> };
> >> diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
> b/board/samsung/dts/exynos5250-smdk5250.dts
> >> index a8e62da..b1b8d71 100644
> >> --- a/board/samsung/dts/exynos5250-smdk5250.dts
> >> +++ b/board/samsung/dts/exynos5250-smdk5250.dts
> >> @@ -30,6 +30,10 @@
> >> spi2 = "/spi@12d4";
> >> spi3 = "/spi@131a";
> >> spi4 = "/spi@131b";
> >> + dwmmc0 = "/dwmmc@1220";
> >> + dwmmc1 = "/dwmmc@1221";
> >> + dwmmc2 = "/dwmmc@1222";
> >> + dwmmc3 = "/dwmmc@1223";
> >> };
> >>
> >> sromc@1225 {
> >> @@ -59,4 +63,24 @@
> >> compatible = "wolfson,wm8994-codec";
> >> };
> >> };
> >> +
> >> + dwmmc@1220 {
> >> + index = <0>;
> >
> > Do you really need the index? You have the numbering from the aliaes I
> think.
> >
> >> + bus-width = <8>;
> >> + timing = <1 3 3>;
> >
> > Might need a "samsung," prefix on these?
> I think better that use the "exynos" instead of "samsung".
> how about?
>
Well I think you are supposed to use vendor,propname when you define your
own private binding.
> >
> >> + };
> >> +
> >> + dwmmc@1221 {
> >> + status = "disabled";
> >> + };
> >> +
> >> + dwmmc@1222 {
> >> + index = <2>;
> >> + bus-width = <4>;
> >> + timing = <1 2 3>;
> >> + };
> >> +
> >> + dwmmc@1223 {
> >> + status = "disabled";
> >> + };
> >> };
> >> --
> >> 1.7.0.4
> >>
> >
> > Regards,
> > Simon
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] where is the crc stored?
On Fri, 2012-12-21 at 20:54 +0100, Wolfgang Denk wrote: > Dear John Stile, > > In message <1356114777.28896.92.camel@genx> you wrote: > > What area of memory is the crc stored for a partition? > > Which sort of partitions are you talking here? Maybe partition is the wrong word for a memory address region. I am a total new-bee, but I have read there is a crc check in u-boot. The crc check can result in a: Warning: Bad CRC, using default environment The crc is considered during the bootcmd. > > I would like to find some detailed documentation on the crc (how big is > > it, where it is stored, how to invalidate to force the booting from a > > second area). > > In general, erasing the whole region will usually work ;-) > > Best regards, > > Wolfgang Denk > I would like to know where this crc is stored. I would like to know is it 8-bit, 16-bit, and 32-bit, or other. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] : Please pull u-boot-imx
Am 21/12/2012 21:46, schrieb Albert ARIBAUD: > Hi Stefano, > Hi Albert, > Hmm, your request says master but the 'up to' points to 'master merge'. > As master has a few more commits including changes to woodburn boards > that makes them use the new power interface, I guess I should ignore > the 'up to' and simply use master (b874df74...)? Yes, please use master (b874df74af..), thanks. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] driver/mtd/IFC:Wait tWB time, poll R/B before command execution
On Wed, Nov 07, 2012 at 09:52:27PM -, Prabhakar Kushwaha wrote: > IFC_FIR_OP_CMD0 issues command for execution without checking flash > readiness. It may cause problem if flash is not ready. Instead use > IFC_FIR_OP_CW0 which Wait for tWB time and poll R/B to return high or > time-out, before issuing command. > > NAND_CMD_READID command implemention does not fulfill above requirement. So > update its programming. > > Signed-off-by: Prabhakar Kushwaha > Signed-off-by: Hemant Nautiyal > > --- > Please note this patch depends upon following patch: > "driver/mtd:IFC NAND:Initialise internal SRAM before any write" > http://patchwork.ozlabs.org/patch/183550/ > > > drivers/mtd/nand/fsl_ifc_nand.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied to u-boot-nand-flash -- I missed it earlier. Next time please make sure "nand" is in the subject line. Ideally prefix it as "nand/fsl_ifc: wait tWB time..." rather than "driver/mtd/IFC:Wait tWB time...". -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: nand flash
The following changes since commit 42e1321874f8a51373972c293f369c6973c85339: Merge branch 'master' of git://git.denx.de/u-boot-sh (2012-12-20 10:53:20 -0700) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master for you to fetch changes up to ba427678a419a59c091e1c816c13852fa05b24bf: driver/mtd/IFC:Wait tWB time, poll R/B before command execution (2012-12-21 15:34:54 -0600) Prabhakar Kushwaha (1): driver/mtd/IFC:Wait tWB time, poll R/B before command execution drivers/mtd/nand/fsl_ifc_nand.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] no mtdparted from U-Boot> prompt
On Fri, 2012-12-21 at 10:29 -0800, jo...@msli.com wrote: > On Fri, 2012-12-21 at 17:59 +0800, Bo Shen wrote: > > Hi Johns, > > > > On 12/21/2012 07:53 AM, jo...@msli.com wrote: > > > This is my first post to the list. > > > I am using u-boot-1.3.4 in buildroot-2011.11 > > > My device is a at91sam9g20-ek > > > I have a patch adding: include/configs/at91sam9g20ek.h > > > which I gather acts as a config file for u-boot. > > > > > > U-Boot> help > > > does not list mtdparts > > > > > > But my bootargs does use it: > > > bootargs=mem=64M console=ttyS0,115200 > > > mtdparts=atmel_nand:4M(bootstrap/uboot/kernel)ro,60M(rootfs),-(data) > > > root=/dev/mtdblock1 rw rootfstype=jffs2 > > > > This mtdparts is defined for Linux kernel NAND driver. > > I had the impression there was also an interactive command-line tool for > mtdparts, from the u-boot prompt. > This post give me the impression that there should be a uboot mtdparts command in addtion to the kernel option. http://stackoverflow.com/questions/8585864/nand-partitioning-in-u-boot > > > > > > Is there a trick to add the mtdparts command? > > > > Yes, you need to add "#define CONFIG_CMD_MTDPARTS" in > > > I added this to include/configs/at91sam9g20ek.h > > Now it contains: > #define CONFIG_JFFS2_NAND 1 > #define CONFIG_JFFS2_CMDLINE 1 > #define CONFIG_CMD_JFFS2 > #define CONFIG_CMD_MTDPARTS" > > > > NOTICE: This email may contain confidential information. Please see > http://www.meyersound.com/confidential/ for our complete policy. > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] where is the crc stored?
Dear John Stile, In message <1356125251.28896.119.camel@genx> you wrote: > > I am a total new-bee, but I have read there is a crc check in u-boot. Actually there are several such checks, for several different purposes. > The crc check can result in a: > Warning: Bad CRC, using default environment THis is when checking if there is a valid environment. So we are talkign about the CRC which protects the persistent environment copy. The structure of this is defined in "include/environment.h", see struct environment_s - as you can see, this is a CRC32. > The crc is considered during the bootcmd. No, this has absolutely nothing to do with bootcmd. > I would like to know where this crc is stored. In the first 4 bytes of the external representation of the environment. > I would like to know is it 8-bit, 16-bit, and 32-bit, or other. 32 bit. 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 The ultimate barrier is one's viewpoint. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] no mtdparted from U-Boot> prompt
Dear John Stile,
In message <1356130404.28896.135.camel@genx> you wrote:
>
> > I had the impression there was also an interactive command-line tool for
> > mtdparts, from the u-boot prompt.
>
> This post give me the impression that there should be a uboot mtdparts
> command in addtion to the kernel option.
> http://stackoverflow.com/questions/8585864/nand-partitioning-in-u-boot
Yes, there is.
For example:
=> mtdparts -?
mtdparts - define flash/nand partitions
Usage:
mtdparts
- list partition table
mtdparts delall
- delete all partitions
mtdparts del part-id
- delete partition (e.g. part-id = nand0,1)
mtdparts add [@] [] [ro]
- add partition
mtdparts default
- reset partition table to defaults
-
this command uses three environment variables:
'partition' - keeps current partition identifier
partition :=
:= ,part_num
'mtdids' - linux kernel mtd device id <-> u-boot device id mapping
mtdids=[,,...]
:= =
:= 'nand'|'nor'|'onenand'
:= mtd device number, 0...
:= unique device tag used by linux kernel to find mtd device
(mtd->name)
'mtdparts' - partition list
mtdparts=mtdparts=[;...]
:= :[,...]
:= unique device tag used by linux kernel to find mtd device
(mtd->name)
:= [@][][]
:= standard linux memsize OR '-' to denote all remaining space
:= partition start offset within the device
:= '(' NAME ')'
:= when set to 'ro' makes partition read-only (not used, passed to
kernel)
=> mtdparts
device nor0 , # parts = 7
#: namesizeoffset mask_flags
0: firmware0x0010 0x 0
1: dtb 0x0004 0x0010 0
2: kernel 0x0024 0x0014 0
3: small-fs0x0028 0x0038 0
4: initrd 0x0020 0x0060 0
5: misc0x0080 0x0080 0
6: big-fs 0x0100 0x0100 0
active partition: nor0,0 - (firmware) 0x0010 @ 0x
defaults:
mtdids : nor0=fc00.flash
mtdparts:
mtdparts=fc00.flash:1m(firmware),256k(dtb),2304k(kernel),2560k(small-fs),2m(initrd),8m(misc),16m(big-fs)
=>
> > Now it contains:
> > #define CONFIG_JFFS2_NAND 1
> > #define CONFIG_JFFS2_CMDLINE 1
> > #define CONFIG_CMD_JFFS2
> > #define CONFIG_CMD_MTDPARTS"
If this is an exact copy, then please remove this '"'
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're not part of the solution, then you're part of the precipi-
tate.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] no mtdparted from U-Boot> prompt
On Sat, 2012-12-22 at 00:13 +0100, Wolfgang Denk wrote:
> Dear John Stile,
>
> In message <1356130404.28896.135.camel@genx> you wrote:
> >
> > > I had the impression there was also an interactive command-line tool for
> > > mtdparts, from the u-boot prompt.
> >
> > This post give me the impression that there should be a uboot mtdparts
> > command in addtion to the kernel option.
> > http://stackoverflow.com/questions/8585864/nand-partitioning-in-u-boot
>
> Yes, there is.
>
> For example:
>
> => mtdparts -?
> mtdparts - define flash/nand partitions
>
> Usage:
> mtdparts
> - list partition table
> mtdparts delall
> - delete all partitions
> mtdparts del part-id
> - delete partition (e.g. part-id = nand0,1)
> mtdparts add [@] [] [ro]
> - add partition
> mtdparts default
> - reset partition table to defaults
>
> -
>
> this command uses three environment variables:
>
> 'partition' - keeps current partition identifier
>
> partition :=
> := ,part_num
>
> 'mtdids' - linux kernel mtd device id <-> u-boot device id mapping
>
> mtdids=[,,...]
>
> := =
>:= 'nand'|'nor'|'onenand'
> := mtd device number, 0...
>:= unique device tag used by linux kernel to find mtd device
> (mtd->name)
>
> 'mtdparts' - partition list
>
> mtdparts=mtdparts=[;...]
>
> := :[,...]
>:= unique device tag used by linux kernel to find mtd device
> (mtd->name)
> := [@][][]
> := standard linux memsize OR '-' to denote all remaining space
>:= partition start offset within the device
> := '(' NAME ')'
> := when set to 'ro' makes partition read-only (not used, passed to
> kernel)
>
>
>
> => mtdparts
>
> device nor0 , # parts = 7
> #: namesizeoffset mask_flags
> 0: firmware0x0010 0x 0
> 1: dtb 0x0004 0x0010 0
> 2: kernel 0x0024 0x0014 0
> 3: small-fs0x0028 0x0038 0
> 4: initrd 0x0020 0x0060 0
> 5: misc0x0080 0x0080 0
> 6: big-fs 0x0100 0x0100 0
>
> active partition: nor0,0 - (firmware) 0x0010 @ 0x
>
> defaults:
> mtdids : nor0=fc00.flash
> mtdparts:
> mtdparts=fc00.flash:1m(firmware),256k(dtb),2304k(kernel),2560k(small-fs),2m(initrd),8m(misc),16m(big-fs)
> =>
>
>
> > > Now it contains:
> > > #define CONFIG_JFFS2_NAND 1
> > > #define CONFIG_JFFS2_CMDLINE 1
> > > #define CONFIG_CMD_JFFS2
> > > #define CONFIG_CMD_MTDPARTS"
>
> If this is an exact copy, then please remove this '"'
>
It actually reads this:
#define CONFIG_JFFS2_NAND 1
#define CONFIG_JFFS2_CMDLINE 1
#define CONFIG_CMD_JFFS2 1 // Required to include cmd_jffs2.c
#define CONFIG_CMD_MTDPARTS 1 // Required for mtdparts command in uboot
But the command is not available on my system.
Would it help to post my .h or maybe my build log?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] Tegra30: I2C: Enable I2C driver on Cardhu
Tested all 5 'buses', i2c probe enumerates device addresses on all but dev 4 (I2C4) [no devices on that bus on my Cardhu]. Note that this uses the extant tegra_i2c.c driver w/o modification. Signed-off-by: Tom Warren --- include/configs/cardhu.h |9 + include/configs/tegra30-common.h |3 +++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/include/configs/cardhu.h b/include/configs/cardhu.h index 471df6e..aa725ba 100644 --- a/include/configs/cardhu.h +++ b/include/configs/cardhu.h @@ -38,6 +38,15 @@ #define CONFIG_MACH_TYPE MACH_TYPE_CARDHU #define CONFIG_BOARD_EARLY_INIT_F + +/* I2C */ +#define CONFIG_TEGRA_I2C +#define CONFIG_SYS_I2C_INIT_BOARD +#define CONFIG_I2C_MULTI_BUS +#define CONFIG_SYS_MAX_I2C_BUS TEGRA_I2C_NUM_CONTROLLERS +#define CONFIG_SYS_I2C_SPEED 10 +#define CONFIG_CMD_I2C + #define CONFIG_ENV_IS_NOWHERE #include "tegra-common-post.h" diff --git a/include/configs/tegra30-common.h b/include/configs/tegra30-common.h index 282caec..04517e1 100644 --- a/include/configs/tegra30-common.h +++ b/include/configs/tegra30-common.h @@ -83,4 +83,7 @@ #define CONFIG_SPL_LDSCRIPT"$(CPUDIR)/tegra30/u-boot-spl.lds" +/* Total I2C ports on Tegra30 */ +#define TEGRA_I2C_NUM_CONTROLLERS 5 + #endif /* _TEGRA30_COMMON_H_ */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] Tegra30: fdt: Update DT files with I2C info for T30/Cardhu
Note that T30 does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
DVC_I2C is still used to designate the controller intended for
power control (PWR_I2C in the schematics). On Cardhu, it's used
to access the PMU and EEPROM, as well as the audio codec, temp
sensor, and fuel gauge devices from the OS.
Signed-off-by: Tom Warren
---
arch/arm/dts/tegra30.dtsi | 61 +++
board/nvidia/dts/tegra30-cardhu.dts | 41 +++
2 files changed, 102 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
index f568d44..664c397 100644
--- a/arch/arm/dts/tegra30.dtsi
+++ b/arch/arm/dts/tegra30.dtsi
@@ -2,4 +2,65 @@
/ {
compatible = "nvidia,tegra30";
+
+ tegra_car: clock@60006000 {
+ compatible = "nvidia,tegra30-car", "nvidia,tegra20-car";
+ reg = <0x60006000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ osc: clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ };
+ };
+
+ i2c@7000c000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nvidia,tegra30-i2c", "nvidia,tegra20-i2c";
+ reg = <0x7000C000 0x100>;
+ /* PERIPH_ID_I2C1, CLK_M */
+ clocks = <&tegra_car 12>;
+ };
+
+ i2c@7000c400 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nvidia,tegra30-i2c", "nvidia,tegra20-i2c";
+ reg = <0x7000C400 0x100>;
+ /* PERIPH_ID_I2C2, CLK_M */
+ clocks = <&tegra_car 54>;
+ };
+
+ i2c@7000c500 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nvidia,tegra30-i2c", "nvidia,tegra20-i2c";
+ reg = <0x7000C500 0x100>;
+ /* PERIPH_ID_I2C3, CLK_M */
+ clocks = <&tegra_car 67>;
+ };
+
+ i2c@7000c700 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nvidia,tegra30-i2c", "nvidia,tegra20-i2c";
+ reg = <0x7000C700 0x100>;
+ /* PERIPH_ID_I2C4, CLK_M */
+ clocks = <&tegra_car 103>;
+ };
+
+ i2c@7000d000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nvidia,tegra30-i2c", "nvidia,tegra20-i2c";
+ reg = <0x7000D000 0x100>;
+ /* PERIPH_ID_I2C_DVC, CLK_M */
+ clocks = <&tegra_car 47>;
+ };
};
diff --git a/board/nvidia/dts/tegra30-cardhu.dts
b/board/nvidia/dts/tegra30-cardhu.dts
index 2345766..4eddde6 100644
--- a/board/nvidia/dts/tegra30-cardhu.dts
+++ b/board/nvidia/dts/tegra30-cardhu.dts
@@ -6,8 +6,49 @@
model = "NVIDIA Cardhu";
compatible = "nvidia,cardhu", "nvidia,tegra30";
+ aliases {
+ i2c0 = "/i2c@7000d000";
+ i2c1 = "/i2c@7000c000";
+ i2c2 = "/i2c@7000c400";
+ i2c3 = "/i2c@7000c500";
+ i2c4 = "/i2c@7000c700";
+ };
+
memory {
device_type = "memory";
reg = <0x8000 0x4000>;
};
+
+ clocks {
+ clk_32k: clk_32K {
+ clock-frequency = <32768>;
+ };
+ osc {
+ clock-frequency = <1200>;
+ };
+ };
+
+ clock@60006000 {
+ clocks = <&clk_32k &osc>;
+ };
+
+ i2c@7000c000 {
+ clock-frequency = <10>;
+ };
+
+ i2c@7000c400 {
+ clock-frequency = <10>;
+ };
+
+ i2c@7000c500 {
+ clock-frequency = <10>;
+ };
+
+ i2c@7000c700 {
+ clock-frequency = <10>;
+ };
+
+ i2c@7000d000 {
+ clock-frequency = <10>;
+ };
};
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] Add I2C driver for Tegra30 Cardhu
Add/update clock tables and enable I2C driver support for the Tegra30 Cardhu board. This uses the standard Tegra I2C driver. 5 controllers are supported, although all may not have devices behind them on every board. Tom Warren (3): Tegra30: clocks: Fix clock tables for I2C and other periphs Tegra30: fdt: Update DT files with I2C info for T30/Cardhu Tegra30: I2C: Enable I2C driver on Cardhu arch/arm/cpu/tegra30-common/clock.c | 78 -- arch/arm/dts/tegra30.dtsi| 61 + arch/arm/include/asm/arch-tegra30/clock-tables.h |4 + board/nvidia/dts/tegra30-cardhu.dts | 41 +++ include/configs/cardhu.h |9 +++ include/configs/tegra30-common.h |3 + 6 files changed, 162 insertions(+), 34 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] Tegra30: clocks: Fix clock tables for I2C and other periphs
Add 16-bit divider support (I2C) to periph table, annotate and
correct some entries, and fix clk_id lookup function.
Signed-off-by: Tom Warren
---
arch/arm/cpu/tegra30-common/clock.c | 78 --
arch/arm/include/asm/arch-tegra30/clock-tables.h |4 +
2 files changed, 48 insertions(+), 34 deletions(-)
diff --git a/arch/arm/cpu/tegra30-common/clock.c
b/arch/arm/cpu/tegra30-common/clock.c
index 5db9d20..c67a2e1 100644
--- a/arch/arm/cpu/tegra30-common/clock.c
+++ b/arch/arm/cpu/tegra30-common/clock.c
@@ -63,6 +63,7 @@ enum clock_type_id {
CLOCK_TYPE_MCPT,
CLOCK_TYPE_PCM,
CLOCK_TYPE_PCMT,
+ CLOCK_TYPE_PCMT16,
CLOCK_TYPE_PDCT,
CLOCK_TYPE_ACPT,
CLOCK_TYPE_ASPTE,
@@ -114,6 +115,9 @@ static enum clock_id
clock_source[CLOCK_TYPE_COUNT][CLOCK_MAX_MUX+1] = {
{ CLK(PERIPH), CLK(CGENERAL), CLK(MEMORY),CLK(OSC),
CLK(NONE), CLK(NONE), CLK(NONE), CLK(NONE),
MASK_BITS_31_30},
+ { CLK(PERIPH), CLK(CGENERAL), CLK(MEMORY),CLK(OSC),
+ CLK(NONE), CLK(NONE), CLK(NONE), CLK(NONE),
+ MASK_BITS_31_30},
{ CLK(PERIPH), CLK(DISPLAY), CLK(CGENERAL), CLK(OSC),
CLK(NONE), CLK(NONE), CLK(NONE), CLK(NONE),
MASK_BITS_31_30},
@@ -146,15 +150,15 @@ static enum clock_type_id
clock_periph_type[PERIPHC_COUNT] = {
TYPE(PERIPHC_I2S2, CLOCK_TYPE_AXPT),
TYPE(PERIPHC_SPDIF_OUT, CLOCK_TYPE_AXPT),
TYPE(PERIPHC_SPDIF_IN, CLOCK_TYPE_PCM),
- TYPE(PERIPHC_PWM, CLOCK_TYPE_PCST),
+ TYPE(PERIPHC_PWM, CLOCK_TYPE_PCST), /* only PWM uses b29:28 */
TYPE(PERIPHC_NONE, CLOCK_TYPE_NONE),
TYPE(PERIPHC_SBC2, CLOCK_TYPE_PCMT),
TYPE(PERIPHC_SBC3, CLOCK_TYPE_PCMT),
/* 0x08 */
TYPE(PERIPHC_NONE, CLOCK_TYPE_NONE),
- TYPE(PERIPHC_I2C1, CLOCK_TYPE_PCMT),
- TYPE(PERIPHC_DVC_I2C, CLOCK_TYPE_PCMT),
+ TYPE(PERIPHC_I2C1, CLOCK_TYPE_PCMT16),
+ TYPE(PERIPHC_DVC_I2C, CLOCK_TYPE_PCMT16),
TYPE(PERIPHC_NONE, CLOCK_TYPE_NONE),
TYPE(PERIPHC_NONE, CLOCK_TYPE_NONE),
TYPE(PERIPHC_SBC1, CLOCK_TYPE_PCMT),
@@ -177,7 +181,7 @@ static enum clock_type_id clock_periph_type[PERIPHC_COUNT]
= {
TYPE(PERIPHC_VFIR, CLOCK_TYPE_PCMT),
TYPE(PERIPHC_EPP, CLOCK_TYPE_MCPA),
TYPE(PERIPHC_MPE, CLOCK_TYPE_MCPA),
- TYPE(PERIPHC_MIPI, CLOCK_TYPE_PCMT),
+ TYPE(PERIPHC_MIPI, CLOCK_TYPE_PCMT), /* MIPI base-band HSI */
TYPE(PERIPHC_UART1, CLOCK_TYPE_PCMT),
TYPE(PERIPHC_UART2, CLOCK_TYPE_PCMT),
@@ -188,7 +192,7 @@ static enum clock_type_id clock_periph_type[PERIPHC_COUNT]
= {
TYPE(PERIPHC_HDMI, CLOCK_TYPE_PMDACD2T),
TYPE(PERIPHC_NONE, CLOCK_TYPE_NONE),
TYPE(PERIPHC_TVDAC, CLOCK_TYPE_PDCT),
- TYPE(PERIPHC_I2C2, CLOCK_TYPE_PCMT),
+ TYPE(PERIPHC_I2C2, CLOCK_TYPE_PCMT16),
TYPE(PERIPHC_EMC, CLOCK_TYPE_MCPT),
/* 0x28 */
@@ -198,7 +202,7 @@ static enum clock_type_id clock_periph_type[PERIPHC_COUNT]
= {
TYPE(PERIPHC_NONE, CLOCK_TYPE_NONE),
TYPE(PERIPHC_NONE, CLOCK_TYPE_NONE),
TYPE(PERIPHC_SBC4, CLOCK_TYPE_PCMT),
- TYPE(PERIPHC_I2C3, CLOCK_TYPE_PCMT),
+ TYPE(PERIPHC_I2C3, CLOCK_TYPE_PCMT16),
TYPE(PERIPHC_SDMMC3,CLOCK_TYPE_PCMT),
/* 0x30 */
@@ -211,13 +215,13 @@ static enum clock_type_id
clock_periph_type[PERIPHC_COUNT] = {
TYPE(PERIPHC_I2S0, CLOCK_TYPE_AXPT),
TYPE(PERIPHC_NONE, CLOCK_TYPE_NONE),
- /* 0x38h */
+ /* 0x38h */ /* Jumps to reg offset 0x3B0h - new for T30 */
TYPE(PERIPHC_G3D2, CLOCK_TYPE_MCPA),
TYPE(PERIPHC_MSELECT, CLOCK_TYPE_PCMT),
- TYPE(PERIPHC_TSENSOR, CLOCK_TYPE_PCM),
+ TYPE(PERIPHC_TSENSOR, CLOCK_TYPE_PCST), /* s/b PCTS */
TYPE(PERIPHC_I2S3, CLOCK_TYPE_AXPT),
TYPE(PERIPHC_I2S4, CLOCK_TYPE_AXPT),
- TYPE(PERIPHC_I2C4, CLOCK_TYPE_PCMT),
+ TYPE(PERIPHC_I2C4, CLOCK_TYPE_PCMT16),
TYPE(PERIPHC_SBC5, CLOCK_TYPE_PCMT),
TYPE(PERIPHC_SBC6, CLOCK_TYPE_PCMT),
@@ -228,21 +232,25 @@ static enum clock_type_id
clock_periph_type[PERIPHC_COUNT] = {
TYPE(PERIPHC_DAM1, CLOCK_TYPE_ACPT),
TYPE(PERIPHC_DAM2, CLOCK_TYPE_ACPT),
TYPE(PERIPHC_HDA2CODEC2X, CLOCK_TYPE_PCMT),
- TYPE(PERIPHC_ACTMON,CLOCK_TYPE_PCM),
+ TYPE(PERIPHC_ACTMON,CLOCK_TYPE_PCST), /* MASK 31:30 */
TYPE(PERIPHC_EXTPERIPH1, CLOCK_TYPE_ASPTE),
/* 0x48 */
TYPE(PERIPHC_EXTPERIPH2, CLOCK_TYPE_ASPTE),
TYPE(PERIPHC_EXTPERIPH3, CLOCK_TYPE_ASPTE),
TYPE(PERIPHC_NANDSPEED, CLOCK_TYPE_PCMT),
Re: [U-Boot] RFC: Secure boot framework
+Tom, Wolfgang, CL, Vadim Hi Joel, On Thu, Dec 20, 2012 at 3:54 PM, Fernandes, Joel A wrote: > > Hi Simon, > > Thanks for your reply. > > On Tue, Dec 18, 2012 at 1:37 AM, Simon Glass wrote: > > Hi Joel, > > > > On Mon, Dec 17, 2012 at 9:11 PM, Fernandes, Joel A wrote: > > > >> Hi, > >> > >> Can anyone comment on what has been discussed about a framework for secure > >> boot and authentication, if there has been such a discussion, in the > >> community? > >> > >> I have some U-boot code that is based off of a slightly older U-boot which > >> does authentication and/or decryption. The main code that does the > >> cryptography is in the ROM of the SoC. However, I'm sure there will be > >> other U-boot developers requiring the crypto algorithms itself to be > >> supported. > >> > >> My questions are : > >> (1) Would a general framework for performing authentication and/or > >> decryption of signed and/or encrypted images be useful for U-boot? These > >> operations seem to make a lot of sense for a bootloader. > > > > > >> (2) Does such a framework make sense for any of your usecase(s)? > >> > >> (3) Has there been any work or discussions of coming up with such a > >> framework for U-boot? > >> > > > > We have created a secure boot system on top of U-Boot - it is in the > > Chromium tree if you want to take a look. Three ChromeOS devices have > > shipped with this so far. However it is not really suitable for generic > > upstream use, so... > > > > There have been some discussions lately on the list about using the FIT > > format to hold an image which can then be verified using a public key. We > > have put together a possible design for this and I am working on this as I > > make time. > > Which Processor and silicon revision is this? Can you point to a security > hardware specification so that I could take a quick look at the architecture > you have in mind? Is it [1]? > Also, is it possible to share the design for modification to FIT you have put > together so far? It is exynos5250 rev1 - the device is called snow in the source code. I don't have a full description other than what is on chromium.org, but you can ask me questions! For FIT, see below for current proposal. > > >> I imagine a framework like this will atleast consist of: > >> > >> 1. General purposes cryptographic functions in a library (which we might > >> not need for our case), some light weight crypto library. > >> 2. Hooks for board/Soc-specific functions that call into the general > >> crypto lib and do any other board/SoC-specific stuff. > >> 3. General commands (in a cmd_crpto.c) that calls into the callbacks > >> mentioned in 2. for encryption and verification of an image already in > >> memory. (making it commands can allow us to leave bootm alone and do the > >> inplace decryption/verification independently - however for SPL, we don't > >> need the commands and call into 2. directly). > >> 4. Abstract any other change(s) to common boot code in a common place. > >> > > > > Yes that seems reasonable. > > Thanks. > > > A very basic hashing framework recently went into U-Boot, and this can be > > used to plumb in SOC hashing acceleration code. I suspect we will do the > > same with RSA, supporting a few different key lengths and associated > > padding. > > > > My plan at present is roughly (and in short order) to: > > > > 1. Define how signatures are represented in FIT > > Just wondering what architecture / silicon are you using from the ChromiumOS, > I guess its the Samsun Exynos? Anyway, isn't the representation of the > signature and the other structure of the image fixed by your ROM or hardware > specification? For example, to load U-boot SPL, doesn't your ROM or firmware > expect the image signatures/certificates etc to be in a certain format? Then > how can you use FIT for the purpose of verification/authentication? Yes, we will update the firmware. This is not for snow (which already has a verified boot) but for the future. We want to try to implement a general purpose verified boot in U-Boot. > > I agree FIT can be possibly modified enough to support this, but what about > the first-stage loading of U-boot SPL. Does your ROM or architecture > understand FIT? I agree second-state bootloader loading and then kernel can > use FIT but I'm not clear on how you do verified-boot for U-boot SPL for > example. Representing U-boot SPL as FIT is not possible right. > > Just a note, we run U-boot SPL from internal SRAM and not a programmable ROM. We use a read-only SPI flash, where the root keys are stored. After manufacture they cannot be changed without opening the case. > > > 2. Enhance mkimage to sign an image or a configuration (consisting of image > > +fdt, for example) > > 3. Enhance FIT command to verify an image given a public key > > Yeah, this sound like a good plan. > > > 4. Support checking of version information against a TPM rollback counter > > I have no idea about TPM rollback, can you point to docs for
[U-Boot] [PATCH 1/1] OMAP3: add boot status GPIO LED for IGEP boards
This patch adds an GPIO LED boot status for IGEP boards.
The GPIO LED used is the red LED0 while the Linux kernel
uses the green LED0 as the boot status.
By using different GPIO LEDs, the user can know in which
step of the boot process the board currently is.
Signed-off-by: Javier Martinez Canillas
---
board/isee/igep0020/Makefile |4 ++-
board/isee/igep0020/igep0020.c |9 +
board/isee/igep0030/Makefile |4 ++-
board/isee/igep0030/igep0030.c |9 +
board/isee/led.c | 74
include/configs/igep00x0.h | 11 ++
6 files changed, 109 insertions(+), 2 deletions(-)
create mode 100644 board/isee/led.c
diff --git a/board/isee/igep0020/Makefile b/board/isee/igep0020/Makefile
index 00463e1..5ead151 100644
--- a/board/isee/igep0020/Makefile
+++ b/board/isee/igep0020/Makefile
@@ -25,8 +25,10 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS := igep0020.o
+COBJS-y := igep0020.o
+COBJS-$(CONFIG_STATUS_LED) += ../led.o
+COBJS := $(sort $(COBJS-y))
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/isee/igep0020/igep0020.c b/board/isee/igep0020/igep0020.c
index a8257a3..7930f4e 100644
--- a/board/isee/igep0020/igep0020.c
+++ b/board/isee/igep0020/igep0020.c
@@ -21,6 +21,9 @@
* MA 02111-1307 USA
*/
#include
+#ifdef CONFIG_STATUS_LED
+#include
+#endif
#include
#include
#include
@@ -52,9 +55,15 @@ static const u32 gpmc_lan_config[] = {
int board_init(void)
{
gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
+ /* machine type for kernel */
+ gd->bd->bi_arch_number = MACH_TYPE_IGEP0020;
/* boot param addr */
gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
+#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT)
+ status_led_set(STATUS_LED_BOOT, STATUS_LED_ON);
+#endif
+
return 0;
}
diff --git a/board/isee/igep0030/Makefile b/board/isee/igep0030/Makefile
index cbc03d4..1ca011d 100644
--- a/board/isee/igep0030/Makefile
+++ b/board/isee/igep0030/Makefile
@@ -25,8 +25,10 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS := igep0030.o
+COBJS-y := igep0030.o
+COBJS-$(CONFIG_STATUS_LED) += ../led.o
+COBJS := $(sort $(COBJS-y))
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/isee/igep0030/igep0030.c b/board/isee/igep0030/igep0030.c
index 107cb7f..394a6cf 100644
--- a/board/isee/igep0030/igep0030.c
+++ b/board/isee/igep0030/igep0030.c
@@ -21,6 +21,9 @@
* MA 02111-1307 USA
*/
#include
+#ifdef CONFIG_STATUS_LED
+#include
+#endif
#include
#include
#include
@@ -39,9 +42,15 @@ DECLARE_GLOBAL_DATA_PTR;
int board_init(void)
{
gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
+ /* machine type for kernel */
+ gd->bd->bi_arch_number = MACH_TYPE_IGEP0030;
/* boot param addr */
gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
+#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT)
+ status_led_set(STATUS_LED_BOOT, STATUS_LED_ON);
+#endif
+
return 0;
}
diff --git a/board/isee/led.c b/board/isee/led.c
new file mode 100644
index 000..b7a9a02
--- /dev/null
+++ b/board/isee/led.c
@@ -0,0 +1,74 @@
+/*
+ * IGEP boards GPIO LED support
+ *
+ * Author: Javier Martinez Canillas
+ *
+ * Some bits borrowed from board/ti/beagle/led.c
+ *
+ * Copyright (c) 2010 Texas Instruments, Inc.
+ * Jason Kridner
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* GPIO pins for the LED */
+#define IGEP0020_GPIO_LED27
+#define IGEP0030_GPIO_LED16
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int __get_gpio()
+{
+ if (gd->bd->bi_arch_number == MACH_TYPE_IGEP0020)
+ return IGEP0020_GPIO_LED;
+ else
+ return IGEP0030_GPIO_LED;
+}
+
+void __led_init(led_id_t mask, int state)
+{
+ __led_set(mask, state);
+}
+
+void __led_toggle(led_id_t mask)
+{
+ int state, toggle_gpio = 0;
+
+ toggle_gpio = __get_gpio();
+
+ if (!gpio_request(toggle_gpio, "")) {
+ gpio_direction_output(toggle_gpio, 0);
+ state = gpio_get_value(toggle_gpio);
+ gpio_set_value(toggle
Re: [U-Boot] [PATCH 2/4] env_nand.c: support falling back to redundant env when writing
On 12/21/2012 04:34:03 AM, Phil Sutter wrote: On Thu, Dec 20, 2012 at 03:41:37PM -0600, Scott Wood wrote: > On 12/20/2012 03:28:39 PM, Phil Sutter wrote: > > On Tue, Dec 11, 2012 at 05:12:32PM -0600, Scott Wood wrote: > > > Erase blocks are larger than write pages, yes. I've never heard > > erase > > > blocks called "pages" or write pages called "blocks" -- but my main > > > point is that the unit of erasing and the unit of badness are the > > same. > > > > Ah, OK. Please excuse my humble nomenclature, I never cared enough to > > sort out what is called what. Of course, this is not the best basis > > for > > a discussion about these things. > > > > But getting back to the topic: The assumption of blocks getting bad, > > not > > pages within a block means that for any kind of bad block prevention, > > multiple blocks need to be used. Although I'm honestly speaking not > > really sure why this needs to be like that. Maybe the bad page marking > > would disappear when erasing the block it belongs to? > > Yes, it would disappear. This is why erase operations skip bad blocks, > unless the scrub option is uesd. Which is apparently preventing good pages in a block with a bad page from being used, isn't it? Right, plus the knowledge of which pages within the block are bad simply isn't there. > > Interesting. I had the impression of pages being marked bad and the > > block's badness being taken from whether it contains bad pages. > > Probably > > the 'nand markbad' command tricked me. > > Do you mean the lack of error checking if you pass a non-block-aligned > offset into "nand markbad"? I think the bigger "problem" is 'nand markbad' updating the bad block table along the go. So no real bad block detection occurs as far as I can tell. I'm not sure what you mean here. > > Well, as long as CONFIG_ENV_OFFSET_REDUND supported falling back to > > the > > other copy in case of error there would be a working system in three > > of > > four cases instead of only one. > > I'm not sure what you mean here -- where do "three", "four", and "one" > come from? Just some quantitative approach: given the environment residing at block A and it's redundant copy at block B, four situations may occur: both blocks good, block A bad, block B bad or both blocks bad. Upstream would fail in all cases but both blocks good. My patch would turn that into failing only if both blocks bad. So working in three of four cases instead of in only one of four. Those two cases that would suddenly be working would be lacking redundancy -- would you want to ship it like that? If U-Boot is noisy about it, then such units can still have their NAND chips replaced before shipping. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] serial/ns16550: check UART mode for TEMT value
On 12/21/2012 03:21:46 AM, Javier Martinez Canillas wrote:
On ns16550, the Transmitter Empty (TEMT) Bit is used to
indicate when the Transmitter Holding Register (THR) and
the Transmitter Shift Register (TSR) are both empty.
But ns16550 UART has two operation modes (16450 and FIFO)
and the TEMT bit logic value set is different on each mode.
On 16450, the TEMT bit is set to 1 when both THR and TSR are
empty and is set to 0 on FIFO mode.
When you say "on 16450", do you mean "in 16450 mode"?
So, checking the TEMT value without checking the current mode
and assuming a logical value of 1, can lead to U-Boot to hang
forever if the UART is initialized on FIFO mode by default.
From the 16550 docs:
Bit 6 This bit is the Transmitter Empty (TEMT) indicator Bit 6 is set
to a logic 1 whenever the Transmitter Holding Regis- ter (THR) and
the
Transmitter Shift Register (TSR) are both empty It is reset to a
logic
0 whenever either the THR or TSR contains a data character In the
FIFO
mode this bit is set to one whenever the transmitter FIFO and shift
register are both empty
Maybe the 16550 implementation you're using is doing something wrong?
Signed-off-by: Javier Martinez Canillas
---
drivers/serial/ns16550.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index bbd91ca..d75d814 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -36,7 +36,9 @@
void NS16550_init(NS16550_t com_port, int baud_divisor)
{
- while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
+ int mode = serial_in(&com_port->fcr) & UART_FCR_FIFO_EN;
+
+ while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT ^ mode))
;
Please don't make the reader know the relative prededence of & and ^,
and
don't use ^ in obfuscatory ways. It's not even any different from | as
used above -- except that | wouldn't break if TEMT and FIFO_EN had the
same
value -- so why do you need the exclusive form?
BTW, when I saw the problem that necessitated this, FIFO was enabled, so
this is no better than reverting the patch.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] serial/ns16550: check UART mode for TEMT value
Hi Scott, thank you for your feedback.
On 12/22/2012 03:45 AM, Scott Wood wrote:
> On 12/21/2012 03:21:46 AM, Javier Martinez Canillas wrote:
>> On ns16550, the Transmitter Empty (TEMT) Bit is used to
>> indicate when the Transmitter Holding Register (THR) and
>> the Transmitter Shift Register (TSR) are both empty.
>>
>> But ns16550 UART has two operation modes (16450 and FIFO)
>> and the TEMT bit logic value set is different on each mode.
>>
>> On 16450, the TEMT bit is set to 1 when both THR and TSR are
>> empty and is set to 0 on FIFO mode.
>
> When you say "on 16450", do you mean "in 16450 mode"?
>
Yes, that's what I meant. I'm not a native English speaker so sorry if I have
some grammatic errors in my comments.
>> So, checking the TEMT value without checking the current mode
>> and assuming a logical value of 1, can lead to U-Boot to hang
>> forever if the UART is initialized on FIFO mode by default.
>
> From the 16550 docs:
>
>Bit 6 This bit is the Transmitter Empty (TEMT) indicator Bit 6 is set
>to a logic 1 whenever the Transmitter Holding Regis- ter (THR) and
> the
>Transmitter Shift Register (TSR) are both empty It is reset to a
> logic
>0 whenever either the THR or TSR contains a data character In the
> FIFO
>mode this bit is set to one whenever the transmitter FIFO and shift
>register are both empty
>
> Maybe the 16550 implementation you're using is doing something wrong?
>
Could be, I'm using a board with an TI OMAP3 SoC which has an NS16650 UART.
Now I read again the NS16650 documentation [1] and you are right. I
misunderstood and thought that on FIFO mode the TEMT bit was set to 0 when the
both THR and TSR were empty and that this was causing U-Boot to hang.
BTW I realized that this is only an issue for SPL, if you build that check for
the non-SPL build, it works.
With this patch my board boots:
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index bbd91ca..a3ef8a5 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -36,8 +36,10 @@
void NS16550_init(NS16550_t com_port, int baud_divisor)
{
+#ifndef CONFIG_SPL_BUILD
while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
;
+#endif
serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier);
#if (defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)) || \
>> Signed-off-by: Javier Martinez Canillas
>>
>> ---
>> drivers/serial/ns16550.c |4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
>> index bbd91ca..d75d814 100644
>> --- a/drivers/serial/ns16550.c
>> +++ b/drivers/serial/ns16550.c
>> @@ -36,7 +36,9 @@
>>
>> void NS16550_init(NS16550_t com_port, int baud_divisor)
>> {
>> -while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
>> +int mode = serial_in(&com_port->fcr) & UART_FCR_FIFO_EN;
>> +
>> +while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT ^ mode))
>> ;
>
> Please don't make the reader know the relative prededence of & and ^,
> and
> don't use ^ in obfuscatory ways. It's not even any different from | as
> used above -- except that | wouldn't break if TEMT and FIFO_EN had the
> same
> value -- so why do you need the exclusive form?
>
Ok, sorry. I didn't think that knowing the precedence of bitwise operator was
obfuscated and the ^ was because I misunderstood the NS16550 docs and thought
that UART_LSR_TEMT would be 0 in FIFO mode.
> BTW, when I saw the problem that necessitated this, FIFO was enabled, so
> this is no better than reverting the patch.
>
> -Scott
>
Either way works for me, I just want to boot my board :-)
But if I'm the only one having this issue maybe is just my hardware behaving
badly. I'll ask other OMAP3 users if they can boot with mainline U-Boot to
confirm this.
Best regards,
Javier
[1]:http://www.ti.com/lit/ds/symlink/pc16550d.pdf
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
