Re: [U-Boot] [PATCH v3 08/10] NET: mvgbe: add support for Dove

[Prafulla Wadaskar]

> -Original Message-
> From: Sebastian Hesselbarth
> [mailto:sebastian.hesselba...@gmail.com]
> Sent: 03 March 2013 17:14
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Rabeeh Khoury; Albert
> Aribaud; Andy Fleming; Joe Hershberger; Daniel Stodden;
> Luka Perkov
> Subject: Re: [PATCH v3 08/10] NET: mvgbe: add support
> for Dove
> 
> On 02/11/2013 04:39 AM, Prafulla Wadaskar wrote:
> >> -Original Message-
> >> From: Sebastian Hesselbarth
> [mailto:sebastian.hesselba...@gmail.com]
> >> Sent: 17 January 2013 00:55
> >> To: Sebastian Hesselbarth
> >> Cc: u-boot@lists.denx.de; Rabeeh Khoury; Albert
> Aribaud; Prafulla
> >> Wadaskar; Andy Fleming; Joe Hershberger; Daniel
> Stodden; Luka Perkov
> >> Subject: [PATCH v3 08/10] NET: mvgbe: add support
> for Dove
> >>
> >> Marvell Dove also uses mvgbe as ethernet driver,
> therefore add support
> >> for Dove to reuse the current driver.
> >>
> >> Signed-off-by: Sebastian
> Hesselbarth
> >> ---
> >> Cc: u-boot@lists.denx.de
> >> Cc: Sebastian
> Hesselbarth
> >> Cc: Rabeeh Khoury
> >> Cc: Albert Aribaud
> >> Cc: Prafulla Wadaskar
> >> Cc: Andy Fleming
> >> Cc: Joe Hershberger
> >> Cc: Daniel Stodden
> >> Cc: Luka Perkov
> >> ---
> >>   drivers/net/mvgbe.c |2 ++
> >>   drivers/net/mvgbe.h |7 +++
> >>   2 files changed, 9 insertions(+)
> >>
> >> diff --git a/drivers/net/mvgbe.c
> b/drivers/net/mvgbe.c
> >> index 192c989..590ea0b 100644
> >> --- a/drivers/net/mvgbe.c
> >> +++ b/drivers/net/mvgbe.c
> >> @@ -43,6 +43,8 @@
> >>   #include
> >>   #elif defined(CONFIG_ORION5X)
> >>   #include
> >> +#elif defined(CONFIG_DOVE)
> >> +#include
> >>   #endif
> >>
> >>   #include "mvgbe.h"
> >> diff --git a/drivers/net/mvgbe.h
> b/drivers/net/mvgbe.h
> >> index d8a5429..7f5d98f 100644
> >> --- a/drivers/net/mvgbe.h
> >> +++ b/drivers/net/mvgbe.h
> >> @@ -308,10 +308,17 @@
> >>   #define EBAR_TARGET_GUNIT0x0007
> >>
> >>   /* Window attrib */
> >> +#if defined(CONFIG_DOVE)
> >> +#define EBAR_DRAM_CS0 0x
> >> +#define EBAR_DRAM_CS1 0x
> >> +#define EBAR_DRAM_CS2 0x
> >> +#define EBAR_DRAM_CS3 0x
> >
> > What does this means?
> > May you please explain?
> 
> These are ORed with other BAR values within mvgbe and
> control access
> of mvgbe bus master to sdram. In contrast to Kirkwood,
> Dove has only
> one sdram target interface with attribute 0x0 while
> Kirkwood has four
> different target IDs each for one sdram bank.
> 

Dear Sebastian
Since dove has only one SDRAM bank
You should do
#undef EBAR_DRAM_CS1/2/3 instead of defining them zero, and manage the same 
effectively in the code.

To me, defining unavailable banks doesn't sound good.

Regards...
Prafulla . . .

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 02/10] GPIO: add gpio driver for Orion SoCs

[Prafulla Wadaskar]

> -Original Message-
> From: Sebastian Hesselbarth
> [mailto:sebastian.hesselba...@gmail.com]
> Sent: 03 March 2013 17:07
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Rabeeh Khoury; Albert
> Aribaud; Andy Fleming; Joe Hershberger; Daniel Stodden;
> Luka Perkov
> Subject: Re: [PATCH v3 02/10] GPIO: add gpio driver for
> Orion SoCs
> 
> On 02/11/2013 04:39 AM, Prafulla Wadaskar wrote:
> >> -Original Message- From: Sebastian
> Hesselbarth
> >> [mailto:sebastian.hesselba...@gmail.com] Sent: 17
> January 2013 00:55 To: Sebastian Hesselbarth
> >> Cc: u-boot@lists.denx.de; Rabeeh Khoury; Albert
> Aribaud; Prafulla Wadaskar; Andy Fleming; Joe
> >> Hershberger; Daniel Stodden; Luka Perkov Subject:
> [PATCH v3 02/10] GPIO: add gpio driver for
> >> Orion SoCs
> >>
> >> This adds a gpio driver for Marvell Orion SoCs, i.e.
> orion5x, kirkwood, dove. This is based on
> >> kw_gpio but as gpio capabilities depend heavily on
> the mpp configuration for dove, it allows to
> >> set gpi/gpo capabilities from mpp. This should be
> compatible with the current kw_gpio and
> >> porting mpp of kirkwood and orion5x is appreciated.
> >
> > Nack, your patch series is for dove, you shouldn't
> add for orion, unless you are using it. If you
> > think this is common framework can be used across the
> other marvell SoCs, we have strategy to
> > name it like mv_***
> >
> > So you may name this driver as mv_gpio
> 
> Prafulla,
> 
> I still think that mv_ as a prefix is too short.
> Remember that Marvell also has
> pxa SoCs and with latest SoCs handling of gpio may
> change dramatically.

Dear Sabastian,
We already have code with this naming convention sitting in u-boot from long, 
so to sync with that we should use "mv".

Pxa is handled separately at this moment, it is outside our scope at this 
moment. In case if it conflicts pxa developer may consider a prefix "mvpxa"
 
> 
> We should rather stick to orion_ for Orion5x, Kirkwood,
> Dove or move to
> mvebu_ for above plus Armada XP/370.

Orion_, Kirkwood_ fine with me, but mvebu doesn't sound good for dove (ebu is 
business unit name), if "dv" does not sound good then you can use "dove" prefix.

Shorter names gives smaller source code :-)

Regards...
Prafulla . . .

> 
> Sebastian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 01/10] ARM: dove: add support for Marvell Dove SoC

[Prafulla Wadaskar]

> -Original Message-
> From: Sebastian Hesselbarth
> [mailto:sebastian.hesselba...@gmail.com]
> Sent: 03 March 2013 17:01
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Rabeeh Khoury; Albert
> Aribaud; Andy Fleming; Joe Hershberger; Daniel Stodden;
> Luka Perkov
> Subject: Re: [PATCH v2 01/10] ARM: dove: add support
> for Marvell Dove SoC
> 
> Prafulla,
> 
> thanks for the review. I added some notes below at your
> comments.
> 
> On 02/11/2013 04:39 AM, Prafulla Wadaskar wrote:
> >>
> >> [...]
> >>
> >> diff --git a/arch/arm/cpu/armv7/dove/mpp.c
> >> b/arch/arm/cpu/armv7/dove/mpp.c
> >> new file mode 100644
> >> index 000..ed24b38
> >> --- /dev/null
> >> +++ b/arch/arm/cpu/armv7/dove/mpp.c
> >> @@ -0,0 +1,318 @@
> >>
> >> [...]
> >>
> >> +/*
> >> + * MPP0-23 have standard MPP register layout
> >> + */
> >> +static void dove_mpp_std_set(u16 config)
> >> +{
> >> + u8 num = MPP_NUM(config);
> >> + u32 off = (num / MPPS_PER_REG) * MPP_BITS;
> >> + u32 shift = (num % MPPS_PER_REG) * MPP_BITS;
> >> + u32 reg;
> >> +
> >> + /* configure standard MPP pin */
> >> + reg  = readl(MPP_CTRL(off));
> >> + reg&= ~(MPP_MASK<<  shift);
> >> + reg |= MPP_SEL(config)<<  shift;
> >> + writel(reg, MPP_CTRL(off));
> >> +
> >> + /* configure gpio capabilities */
> >> + if (MPP_GPIO(config))
> >> + orion_gpio_set_valid(num,
> GPIO_INPUT_OK | GPIO_OUTPUT_OK);
> >> + else
> >> + orion_gpio_set_valid(num, 0);
> >
> > Why it is orion_gpio*? it should be generic API call
> or SoC specific.
> 
> Dove is reusing orion gpio, orion refers to the SoC
> family not orion5x.

So let's rename them as "mv" as per strategy.
I don't have any issue to refer "mv_gpio" in dove code.

> 
> >> +}
> >> +
> >> +/*
> >> + * MPP0-15 also allow to mux PMU functions
> >> + */
> >> +static void dove_mpp_pmu_set(u16 config)
> >> +{
> >> + u8 num = MPP_NUM(config);
> >> +
> >> + if (MPP_SEL(config) == PMU) {
> >> + /* enable PMU on MPP */
> >> + writel(readl(MPP_PMU_GENERAL_CTRL) |
> (1<<  num),
> >> +MPP_PMU_GENERAL_CTRL);
> >> + /* disable gpio capabilities */
> >> + orion_gpio_set_valid(num, 0);
> >
> > I think you are trying to reuse the framework
> implemented by orion,
> > You may move generic part from orion to common area
> so that you can use it. Using other SoC direct calls
> doesn't sound good to me.
> 
> Kirkwood and others using orion_gpio have very regular
> layout of mpp pins and
> gpio functionality, i.e. you have one pin with one mpp
> layout and if you want
> it to be gpio you choose "gpio" as it's mpp function.
> 
> Well, Dove is different here. You first have mpp0-15
> which can be either
> "normal" mpp pins _or_ assigned to power management
> unit (pmu). Then there
> are mpp groups where more than one pin is controlled by
> a single mpp register
> value. As there are some groups that have some of the
> pins configured as gpios
> while others carry a special function, I chose to have
> gpio capabilities
> configured by mpp code not by gpio function.

So we can have generic mv specific APIs and the SoC specific layer can be 
abstracted if possible.
If the integration is not possible with generic code then you can always have 
dove_gpio driver.

> 
> >> [...]
> >>
> >> diff --git a/arch/arm/include/asm/arch-dove/config.h
> >> b/arch/arm/include/asm/arch-dove/config.h
> >> new file mode 100644
> >> index 000..2d94a48
> >> --- /dev/null
> >> +++ b/arch/arm/include/asm/arch-dove/config.h
> >> @@ -0,0 +1,153 @@
> >>
> >> [...]
> >>
> >> +/*
> >> + * By default kwbimage.cfg from board specific
> folder is used
> >
> > I think you should use dvbimage.cfg naming
> convention, since kwb stands for Kirkwood boot image,
> same way it will be dove boot image
> 
> With recent discussion about renaming kwboot to mvboot,
> shouldn't this
> become mvbimage.cfg?

Tool could be mvboot, configuration image can be mv/kw/dvbimage.cfg. But I 
don't have any issue with name mvbimage.cfg

> 
> >> + * If for some board, different configuration file
> need to be used,
> >> + * CONFIG_SYS_KWD_CONFIG should be defined in board
> specific header
> >> file
> >> + */
> >> +#ifndef CONFIG_SYS_KWD_CONFIG
> >> +#define  CONFIG_SYS_KWD_CONFIG
> >>$(SRCTREE)/$(CONFIG_BOARDDIR)/kwbimage.cfg
> >> +#endif /* CONFIG_SYS_KWD_CONFIG */
> >
> > Same: change all references to DOVE, secondly do you
> think DV is better than DOVE to shorten then name
> everywhere like KW for Kirkwood?
> 
> Ditto, rename KWD to MV or MVB?
> 
> >> [...]
> >> +/*
> >> + * SPI Flash configuration
> >> + */
> >> +#ifdef CONFIG_CMD_SF
> >> +#define CONFIG_HARD_SPI  1
> >> +#define CONFIG_ORION_SPI 1
> >> +#define ORION_SPI_BASE
> DOVE_SPI_BASE
> >
> > ???
> 
> Again, Orion refers to SoC family and Dove is reusing
> the driver.

Let's use mv if the code is being shared.

Regards...
Prafulla . . .

>

Re: [U-Boot] [PATCH] mmc:sdhci:fix: Change default interrupts enabled at SDHCI initialization

[Lukasz Majewski]

Dear All,

> Hi Tom,
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > On 02/21/2013 06:33 PM, Jaehoon Chung wrote:
> > > Hi Tom,
> > > 
> > > On 02/22/2013 02:45 AM, Tom Rini wrote: On 02/21/2013 12:21 PM,
> > > Lukasz Majewski wrote:
> >  Dear All,
> >  
> >  I'd like to kindly ask for any feedback on this patch.
> >  
> >  It is now more than month on the u-boot mailing list...
> > > 
> > > OK, sorry, the generic name of the driver threw me for a minute.
> > > I'm fine with this change going up u-boot-samsung -> u-boot-arm ->
> > > master since it's a samsung-only driver right now.  Does this work
> > > for you?
> > >> I think that this driver didn't use samsung-only. going up
> > >> u-boot-samsung? I'm not sure that.
> > 
> > Unless the context got very wrong, it touches drivers/mmc/sdhci.c
> > which is controlled by CONFIG_SDHCI which is only turned on in what
> > look like samsung platforms to me.
> > 
> 
> There is a /asm/arch-pantheon/config.h file which sets the
> CONFIG_SDHCI flag. It was added by Lei Wen (who is CC'ed to this
> thread) and looks like ARM926EJS (Marwell Semiconductor) processor
> based system.
> 
> Other systems are indeed samsung based processors. 
> 
> I don't mind if this patch would go via u-boot-samsung tree.
> 
> Moreover, since this change "touches" Lei system, I think that he
> should have expressed his opinion. Sadly this didn't happened

Any feedback? If not, please pull this patch to u-boot mainline.

Today it is 2 months since this patch has been posted on ML. No reply
from interested people.




-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 2/9] dfu: Support larger than memory transfers.

[Lukasz Majewski]

Hi Tom,

> From: Pantelis Antoniou 
> 
> Previously we didn't support upload/download larger than available
> memory.  This is pretty bad when you have to update your root
> filesystem for example.
> 
> This patch removes that limitation (and the crashes when you
> transfered any file larger than 4MB) by making raw image writes be
> done in chunks and making file maximum size be configurable.
> 
> The sequence number is a 16 bit counter; make sure we handle rollover
> correctly. This fixes the wrong transfers for large (> 256MB) images.
> 
> Also utilize a variable to handle initialization, so that we don't
> rely on just the counter sent by the host.
> 
> Signed-off-by: Pantelis Antoniou 
> Signed-off-by: Tom Rini 

Acked-by: Lukasz Majewski 

Test-hw: Exynos 4210 (Trats)

Tested-by: Lukasz Majewski 

> ---
> Changes in v5:
> - Rework Pantelis' "dfu: Support larger than memory transfers" to not
>   break filesystem writing
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  README|7 ++
>  drivers/dfu/dfu.c |  245
> ++---
> drivers/dfu/dfu_mmc.c |  116 +--
> include/dfu.h |   26 +- 4 files changed, 310
> insertions(+), 84 deletions(-)
> 
> diff --git a/README b/README
> index 900ae5f..154b82f 100644
> --- a/README
> +++ b/README
> @@ -1338,6 +1338,13 @@ The following options need to be configured:
>   CONFIG_DFU_MMC
>   This enables support for exposing (e)MMC devices via
> DFU. 
> + CONFIG_SYS_DFU_MAX_FILE_SIZE
> + When updating files rather than the raw storage
> device,
> + we use a static buffer to copy the file into and
> then write
> + the buffer once we've been given the whole file.
> Define
> + this to the maximum filesize (in bytes) for the
> buffer.
> + Default is 4 MiB if undefined.
> +
>  - Journaling Flash filesystem support:
>   CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF,
> CONFIG_JFFS2_NAND_SIZE, CONFIG_JFFS2_NAND_DEV
> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> index e8477fb..2fecf77 100644
> --- a/drivers/dfu/dfu.c
> +++ b/drivers/dfu/dfu.c
> @@ -44,90 +44,229 @@ static int dfu_find_alt_num(const char *s)
>  static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
>dfu_buf[DFU_DATA_BUF_SIZE];
>  
> +static int dfu_write_buffer_drain(struct dfu_entity *dfu)
> +{
> + long w_size;
> + int ret;
> +
> + /* flush size? */
> + w_size = dfu->i_buf - dfu->i_buf_start;
> + if (w_size == 0)
> + return 0;
> +
> + /* update CRC32 */
> + dfu->crc = crc32(dfu->crc, dfu->i_buf_start, w_size);
> +
> + ret = dfu->write_medium(dfu, dfu->offset, dfu->i_buf_start,
> &w_size);
> + if (ret)
> + debug("%s: Write error!\n", __func__);
> +
> + /* point back */
> + dfu->i_buf = dfu->i_buf_start;
> +
> + /* update offset */
> + dfu->offset += w_size;
> +
> + puts("#");
> +
> + return ret;
> +}
> +
>  int dfu_write(struct dfu_entity *dfu, void *buf, int size, int
> blk_seq_num) {
> - static unsigned char *i_buf;
> - static int i_blk_seq_num;
> - long w_size = 0;
>   int ret = 0;
> + int tret;
> +
> + debug("%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x "
> + "offset: 0x%llx bufoffset: 0x%x\n",
> +__func__, dfu->name, buf, size, blk_seq_num,
> dfu->offset,
> +dfu->i_buf - dfu->i_buf_start);
> +
> + if (!dfu->inited) {
> + /* initial state */
> + dfu->crc = 0;
> + dfu->offset = 0;
> + dfu->i_blk_seq_num = 0;
> + dfu->i_buf_start = dfu_buf;
> + dfu->i_buf_end = dfu_buf + sizeof(dfu_buf);
> + dfu->i_buf = dfu->i_buf_start;
> +
> + dfu->inited = 1;
> + }
>  
> - debug("%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x i_buf:
> 0x%p\n",
> -__func__, dfu->name, buf, size, blk_seq_num, i_buf);
> + if (dfu->i_blk_seq_num != blk_seq_num) {
> + printf("%s: Wrong sequence number! [%d] [%d]\n",
> +__func__, dfu->i_blk_seq_num, blk_seq_num);
> + return -1;
> + }
>  
> - if (blk_seq_num == 0) {
> - i_buf = dfu_buf;
> - i_blk_seq_num = 0;
> + /* DFU 1.1 standard says:
> +  * The wBlockNum field is a block sequence number. It
> increments each
> +  * time a block is transferred, wrapping to zero from
> 65,535. It is used
> +  * to provide useful context to the DFU loader in the
> device."
> +  *
> +  * This means that it's a 16 bit counter that roll-overs at
> +  * 0x -> 0x. By having a typical 4K transfer block
> +  * we roll-over at exactly 256MB. Not very fun to debug.
> +  *
> +  * Handling rollover, and having an inited variable,
> +  * makes things work.
> +  */

[U-Boot] Conflict between mainline and ARM trees on davinci

[Albert ARIBAUD]

Hello,

There is merge conflict between mainline and ARM trees on davinci gpio,
between

commit 03414ac45e119496e2475aeacbb968bb67da24f8
gpio: Build the da8xx_gpio code for the davinci644x device
(mainline)

and

commit b9f56698c7e9bf7ac773b5346c4f6886e214b69b
da8xx: Add the missing pinmux for da830 to the gpio driver
(ARM, from TI tree)

Authors CC:ed, as well as Tom for both TI and mainline tree.

Tom, how do you want to reconcile things?

Manual resolution in the merge commit was frowned upon last time I did
it, because it introduces non-reviewed code changes.

This leaves doing a manual commit on either one of the mainline, ARM or
TI trees so that merge becomes trivial. Mainline tree is preferable I
think, because it avoids added PR.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v1] DOS_PBR block type is also valid dos block type.

[sonic.adi]

From: Sonic Zhang 

- Should return 0 for both DOS_MBR and DOS_PBR block types in test_part_dos().

Signed-off-by: Sonic Zhang 

---
 disk/part_dos.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/disk/part_dos.c b/disk/part_dos.c
index 3fe901b..98f82ca 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -98,7 +98,7 @@ int test_part_dos (block_dev_desc_t *dev_desc)
if (dev_desc->block_read(dev_desc->dev, 0, 1, (ulong *) buffer) != 1)
return -1;
 
-   if (test_block_type(buffer) != DOS_MBR)
+   if (test_block_type(buffer) < 0)
return -1;
 
return 0;
-- 
1.7.0.4


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 2/9] dfu: Support larger than memory transfers.

[Lukasz Majewski]

Hi Tom,


> 
> > From: Pantelis Antoniou 
> > 
> > Previously we didn't support upload/download larger than available
> > memory.  This is pretty bad when you have to update your root
> > filesystem for example.
> > 
> > This patch removes that limitation (and the crashes when you
> > transfered any file larger than 4MB) by making raw image writes be
> > done in chunks and making file maximum size be configurable.
> > 
> > The sequence number is a 16 bit counter; make sure we handle
> > rollover correctly. This fixes the wrong transfers for large (>
> > 256MB) images.
> > 
> > Also utilize a variable to handle initialization, so that we don't
> > rely on just the counter sent by the host.
> > 
> > Signed-off-by: Pantelis Antoniou 
> > Signed-off-by: Tom Rini 
> 
> Acked-by: Lukasz Majewski 
> 
> Test-hw: Exynos 4210 (Trats)
> 
> Tested-by: Lukasz Majewski 

Sorry but, I've found a regression for reading image from a file
system. It happens with EXT4 mmc read (like uImage).

mmc_file_op: ext4load mmc 0:2 /uImage 0x0 0 0x7f95dc98
** File not found 0x0 **
dfu: Read error!

ext4load params:
ext4load - load binary file from a Ext4 filesystem

Usage:
ext4load   [addr] [filename] [bytes]
- load binary file 'filename' from 'dev' on 'interface'
  to address 'addr' from ext4 filesystem.
  All numeric parameters are assumed to be hex.

Some parameters are wrong (buffer - 0x0) and some are switched (address
and filename).

Please find more details below:

> 
> > ---
> > Changes in v5:
> > - Rework Pantelis' "dfu: Support larger than memory transfers" to
> > not break filesystem writing
> > 
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2: None
> > 
> >  README|7 ++
> >  drivers/dfu/dfu.c |  245
> > ++---
> > drivers/dfu/dfu_mmc.c |  116 +--
> > include/dfu.h |   26 +- 4 files changed, 310
> > insertions(+), 84 deletions(-)
> > 

> > +static int dfu_write_buffer_drain(struct dfu_entity *dfu)
> > +{
> > +   long w_size;
> > +   int ret;
> > +
> > +   /* flush size? */
> > +   w_size = dfu->i_buf - dfu->i_buf_start;
> > +   if (w_size == 0)
> > +   return 0;
> > +
> > +   /* update CRC32 */
> > +   dfu->crc = crc32(dfu->crc, dfu->i_buf_start, w_size);
> > +
> > +   ret = dfu->write_medium(dfu, dfu->offset, dfu->i_buf_start,
> > &w_size);
> > +   if (ret)
> > +   debug("%s: Write error!\n", __func__);
> > +
> > +   /* point back */
> > +   dfu->i_buf = dfu->i_buf_start;
> > +
> > +   /* update offset */
> > +   dfu->offset += w_size;
> > +
> > +   puts("#");
> > +
> > +   return ret;
> > +}
> > +
> >  int dfu_write(struct dfu_entity *dfu, void *buf, int size, int
> > blk_seq_num) {
> > -   static unsigned char *i_buf;
> > -   static int i_blk_seq_num;
> > -   long w_size = 0;
> > int ret = 0;
> > +   int tret;
> > +
> > +   debug("%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x "
> > +   "offset: 0x%llx bufoffset: 0x%x\n",
> > +  __func__, dfu->name, buf, size, blk_seq_num,
> > dfu->offset,
> > +  dfu->i_buf - dfu->i_buf_start);
> > +
> > +   if (!dfu->inited) {
> > +   /* initial state */
> > +   dfu->crc = 0;
> > +   dfu->offset = 0;
> > +   dfu->i_blk_seq_num = 0;
> > +   dfu->i_buf_start = dfu_buf;
> > +   dfu->i_buf_end = dfu_buf + sizeof(dfu_buf);
> > +   dfu->i_buf = dfu->i_buf_start;
> > +
> > +   dfu->inited = 1;
> > +   }
> >  
> > -   debug("%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x i_buf:
> > 0x%p\n",
> > -  __func__, dfu->name, buf, size, blk_seq_num, i_buf);
> > +   if (dfu->i_blk_seq_num != blk_seq_num) {
> > +   printf("%s: Wrong sequence number! [%d] [%d]\n",
> > +  __func__, dfu->i_blk_seq_num, blk_seq_num);
> > +   return -1;
> > +   }
> >  
> > -   if (blk_seq_num == 0) {
> > -   i_buf = dfu_buf;
> > -   i_blk_seq_num = 0;
> > +   /* DFU 1.1 standard says:
> > +* The wBlockNum field is a block sequence number. It
> > increments each
> > +* time a block is transferred, wrapping to zero from
> > 65,535. It is used
> > +* to provide useful context to the DFU loader in the
> > device."
> > +*
> > +* This means that it's a 16 bit counter that roll-overs at
> > +* 0x -> 0x. By having a typical 4K transfer block
> > +* we roll-over at exactly 256MB. Not very fun to debug.
> > +*
> > +* Handling rollover, and having an inited variable,
> > +* makes things work.
> > +*/
> > +
> > +   /* handle rollover */
> > +   dfu->i_blk_seq_num = (dfu->i_blk_seq_num + 1) & 0x;
> > +
> > +   /* flush buffer if overflow */
> > +   if ((dfu->i_buf + size) > dfu->i_buf_end) {
> > +   tret = dfu_write_buffer_drain(dfu);
> > +   if (ret == 0)
> > +   ret = tret;
> > }
> >  
> > -   if (i_blk_seq_num++ != blk_seq_num) {
> > -   printf

Re: [U-Boot] [PATCH] powerpc/mpc85xx: add setting of clock-frequency for mpic node

[Wang Dongsheng-B40534]

Hi Andy,

Could you please apply this patch?

- dongsheng

> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Tuesday, March 05, 2013 10:14 AM
> To: 'york...@freescale.com'
> Cc: Fleming Andy-AFLEMING; 'u-boot@lists.denx.de'
> Subject: RE: [PATCH] powerpc/mpc85xx: add setting of clock-frequency for
> mpic node
> 
> Hi york,
> 
> Could you ack this patch?
> 
> Thanks.
> 
> > -Original Message-
> > From: Wang Dongsheng-B40534
> > Sent: Monday, February 25, 2013 2:22 PM
> > To: Fleming Andy-AFLEMING
> > Cc: u-boot@lists.denx.de
> > Subject: RE: [PATCH] powerpc/mpc85xx: add setting of clock-frequency
> > for mpic node
> >
> > Hi Andy,
> >
> > Could you ack this patch?
> >
> > Thanks.
> >
> > > -Original Message-
> > > From: Wang Dongsheng-B40534
> > > Sent: Thursday, January 31, 2013 12:52 PM
> > > To: u-boot@lists.denx.de
> > > Cc: Wang Dongsheng-B40534
> > > Subject: [PATCH] powerpc/mpc85xx: add setting of clock-frequency for
> > mpic
> > > node
> > >
> > > Set the device tree property associated with the mpic source
> > > frequency. The frequency is used for mpic timer.
> > >
> > > Signed-off-by: Wang Dongsheng 
> > > ---
> > >  arch/powerpc/cpu/mpc85xx/fdt.c |5 +
> > >  1 files changed, 5 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c
> > > b/arch/powerpc/cpu/mpc85xx/fdt.c index 3a268aa..f07d1cf 100644
> > > --- a/arch/powerpc/cpu/mpc85xx/fdt.c
> > > +++ b/arch/powerpc/cpu/mpc85xx/fdt.c
> > > @@ -663,6 +663,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)  #ifdef
> > > CONFIG_FSL_CORENET
> > >   do_fixup_by_compat_u32(blob, "fsl,qoriq-clockgen-1.0",
> > >   "clock-frequency", CONFIG_SYS_CLK_FREQ, 1);
> > > + do_fixup_by_compat_u32(blob, "fsl,mpic",
> > > + "clock-frequency", get_bus_freq(0)/2, 1); #else
> > > + do_fixup_by_compat_u32(blob, "fsl,mpic",
> > > + "clock-frequency", get_bus_freq(0), 1);
> > >  #endif
> > >
> > >   fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
> > > --
> > > 1.7.5.1


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards

[Wolfgang Denk]

Dear Eric,

In message <513d18f3.2010...@boundarydevices.com> you wrote:
> 
> I understand the point, but think the pain is manageable and
> mostly ours.

When I say it doesn't scale, I'm not only thinking about yourown
efforts, and your customers.

I also think about things like the increase of build and test time for
_everybody_ who performs tests on U-Boot - instead of one board, we
now have to build - how many? 6? - configurations.  If we allow this
now, others will copy this approach (and we cannot really reject it
then). I really would like to avoid setting such a precedent here.

> While we'd like to snap our fingers and have a "does everything
> right" boot loader, that will take a while ;)

I'm well aware of this.

> Well, at least the use of i.MX plugins to do the job. The general
> response was something along the lines of:
> 
>   **if** we want to support multiple CPU variants in
>   a single binary, then it should be done with SPL.

This may or mayu not make sense.  It certainly depends on the specific
requirements of the SoC / architecture in question.

> This patch set is the simplest implementation we can think
> of that still allows a single board file and directory to
> support multiple CPU options and memory configurations.

I agree that supporting multiple SoCs indeed adds complexity.
However, supporting different memory sizes has been supported by
U-Boot (and actually already by PPCBoot) since day one, so this is not
really considered rocket science.  Also, SPL is not exactly new
technology any more.

> This step has broken things up into parts so that we
> **can** express multiple memory configurations within
> a single board directory, and I hope it moves the ball
> forward a step or two.

It does.  But source base is one thing.  Havnig to deal with a large
number of configurations to build and test is another one, and here
you put additional burdon on a large number of prople.

> Our hope in getting this main-lined was that other upcoming
> Solo and Dual-Lite platforms could share some of the bits.

Understood and appreciated.  But I also see this ias a strong reason
to come up with a clean design, and not create bad examples which
others without doubt will interpret as persuasive precedent.

> I'm sorry if I sound frustrated.

You don't, and if you did I could very well understand how you feel.

I hope you can understand my position, too.

> This is feedback I'd hoped to get to the RFC version back in January,

Sorry I missed it then.

> and it will be some time before we're in a position to add SPL into the mix.
> 
> I'll wait for further feedback before determining if a V3 patch
> is warranted.

I would also apprciate if others could comment - Stefano? Albert? Tom?

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
I program, therefore I am.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] at91sam9x5: mmc: save environment as a file in FAT partition.

[Josh Wu]

On 3/10/2013 11:55 PM, Andreas Bießmann wrote:

Hi, Andreas


Dear Josh Wu,

On 22.02.2013 11:36, Josh Wu wrote:

Hi, Bo Shen

Sorry for the late reply. I am taken over by other stuff. check my
comments below.

On 1/23/2013 5:31 PM, Bo Shen wrote:

Hi Josh,

On 01/22/2013 04:36 PM, Josh Wu wrote:

This patch will save U-Boot environment as a file: uboot.env, in FAT
partition
instead of saving it in raw sector of SD card.
Since saving environment in raw sector has risk of corrupting the SD
card and
only can use very small size.
Save as a FAT file has no above limitation.

Signed-off-by: Josh Wu
---
this patch is based on v2013.01.

  include/configs/at91sam9x5ek.h |   12 +++-
  1 file changed, 7 insertions(+), 5 deletions(-)


When I test this on at91sam9g35ek board, execute "saveenv", it will
report following information, any information for this?


I also tested some sd card, and I meet this issue you met too.
In such situation,  the command "mmc part" will report a unknow
partition error.
I suspect the issue is caused by either mmc driver or FAT partition part
of code.
And I will continue digging this issue. Thanks for report the errors.


Have you an updated version of this patch?


Sorry, I didn't follow up this issue yet. So no update so far. I will 
continue work on it when I have time.


Best Regards,
Josh Wu



Best regards

Andreas Bießmann


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Nand flash (supports ONFI)

[TigerLiu]

Hi, experts:
I want to know which specific nand chip supports ONFI interface spec?
I have googled , but not find any product manual.

Best wishes,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Nand flash (supports ONFI)

[Jagan Teki]

Hi,

On Mon, Mar 11, 2013 at 5:06 PM,   wrote:
> Hi, experts:
> I want to know which specific nand chip supports ONFI interface spec?
> I have googled , but not find any product manual.

Spansion ML series and Micron MT29F series flashes have onfi read
parameter page support.

Thanks,
Jagan.

>
> Best wishes,
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards

[Stefano Babic]

On 11/03/2013 12:15, Wolfgang Denk wrote:
> Dear Eric,
> 

Hi Wolfgang, hi Eric,

sorry to jump late in the discussion.

> In message <513d18f3.2010...@boundarydevices.com> you wrote:
>>
>> I understand the point, but think the pain is manageable and
>> mostly ours.
> 
> When I say it doesn't scale, I'm not only thinking about yourown
> efforts, and your customers.
> 
> I also think about things like the increase of build and test time for
> _everybody_ who performs tests on U-Boot - instead of one board, we
> now have to build - how many? 6? - configurations.  If we allow this
> now, others will copy this approach (and we cannot really reject it
> then). I really would like to avoid setting such a precedent here.
> 
>> While we'd like to snap our fingers and have a "does everything
>> right" boot loader, that will take a while ;)
> 
> I'm well aware of this.
> 
>> Well, at least the use of i.MX plugins to do the job. The general
>> response was something along the lines of:
>>
>>  **if** we want to support multiple CPU variants in
>>  a single binary, then it should be done with SPL.
> 
> This may or mayu not make sense.  It certainly depends on the specific
> requirements of the SoC / architecture in question.
> 
>> This patch set is the simplest implementation we can think
>> of that still allows a single board file and directory to
>> support multiple CPU options and memory configurations.
> 
> I agree that supporting multiple SoCs indeed adds complexity.
> However, supporting different memory sizes has been supported by
> U-Boot (and actually already by PPCBoot) since day one, so this is not
> really considered rocket science.  Also, SPL is not exactly new
> technology any more.

Firstly I sumarize something from your previous posting in this thread.
As remark about first Wolfgangs's post, there is an issue that does not
allow to use get_ram_size() to tune the RAM settings, as we are usual to
do with other architectures. In fact, the processor itself reads these
headers (in i.MX jargon the DCD tables) at the beginning of the image
and sets itself the RAM controller, copying at the end u-boot from
storage to RAM - without any intervention by U-Boot code. When
get_ram_size() is called, the code already runs from RAM - this is has
nothing to do with relocation.

This is why Eric pushes several configuration files, whose changes are
due to the different RAM chips.

The way Troy / Eric tried to manage this was to add the "plugin"
facility to the imximage. However, as you have already read in the
thread, this adds not only complexity, but it is also *very* special for
the i.MX, and cannot be reused at all for other processors. I do not
like that i.MX becomes an island in the U-Boot world and I have
discouraged the usage of i.MX plugins vs SPL.

The roadmap for me is that this complexity can be easy managed (and also
having different SOCs with a single image, if desired) using SPL. This
is now a well known technology and can add some important features
borrowed by other SOCs (falcon mode, booting from different storages,
etc.).

This at the end to explain Wolfgang why I was against adding "plugins"
when the RFC patchset was set - without you have to read the whole
discussion, that was pretty long ;-).


> 
>> This step has broken things up into parts so that we
>> **can** express multiple memory configurations within
>> a single board directory, and I hope it moves the ball
>> forward a step or two.
> 
> It does.  But source base is one thing.  Havnig to deal with a large
> number of configurations to build and test is another one, and here
> you put additional burdon on a large number of prople.
> 
>> Our hope in getting this main-lined was that other upcoming
>> Solo and Dual-Lite platforms could share some of the bits.
> 
> Understood and appreciated.  But I also see this ias a strong reason
> to come up with a clean design, and not create bad examples which
> others without doubt will interpret as persuasive precedent.
> 
>> I'm sorry if I sound frustrated.
> 
> You don't, and if you did I could very well understand how you feel.
> 
> I hope you can understand my position, too.
> 
>> This is feedback I'd hoped to get to the RFC version back in January,
> 
> Sorry I missed it then.
> 
>> and it will be some time before we're in a position to add SPL into the mix.
>>
>> I'll wait for further feedback before determining if a V3 patch
>> is warranted.
> 
> I would also apprciate if others could comment - Stefano? Albert? Tom?
> 

As set previously, my position is, since RFC patches were pushed in
January, that some kind of complexity can be well managed with SPL
instead of with very SOC specific code. However, in the meantime I said
explicitely that I was not against the current patchset in the form Eric
posted now. I understand this can be seen as a temporary solution, but
let's increase the number of users using these boards, and taking into
account that some other pending patches can help to switc

Re: [U-Boot] [PATCH v5 2/9] dfu: Support larger than memory transfers.

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/11/2013 06:03 AM, Lukasz Majewski wrote:
> Hi Tom,
> 
> 
>> 
>>> From: Pantelis Antoniou 
>>> 
>>> Previously we didn't support upload/download larger than
>>> available memory.  This is pretty bad when you have to update
>>> your root filesystem for example.
>>> 
>>> This patch removes that limitation (and the crashes when you 
>>> transfered any file larger than 4MB) by making raw image writes
>>> be done in chunks and making file maximum size be
>>> configurable.
>>> 
>>> The sequence number is a 16 bit counter; make sure we handle 
>>> rollover correctly. This fixes the wrong transfers for large
>>> (> 256MB) images.
>>> 
>>> Also utilize a variable to handle initialization, so that we
>>> don't rely on just the counter sent by the host.
>>> 
>>> Signed-off-by: Pantelis Antoniou
>>>  Signed-off-by: Tom Rini
>>> 
>> 
>> Acked-by: Lukasz Majewski 
>> 
>> Test-hw: Exynos 4210 (Trats)
>> 
>> Tested-by: Lukasz Majewski 
> 
> Sorry but, I've found a regression for reading image from a file 
> system. It happens with EXT4 mmc read (like uImage).

Can you please confirm read works as-is today?  It's possible that
when I tried I was using (what I've now called) a marginal SD card
I've finally written too much to the front sectors on, but it wasn't
working for me at all.  I'll try and reproduce as well.  That said,
there is a problem:

> mmc_file_op: ext4load mmc 0:2 /uImage 0x0 0 0x7f95dc98 ** File not
> found 0x0 ** dfu: Read error!
> 
> ext4load params: ext4load - load binary file from a Ext4
> filesystem
> 
> Usage: ext4load   [addr] [filename] [bytes] 
> - load binary file 'filename' from 'dev' on 'interface' to address
> 'addr' from ext4 filesystem. All numeric parameters are assumed to
> be hex.
> 
> Some parameters are wrong (buffer - 0x0) and some are switched
> (address and filename).

I just noticed last week that ext4load has the syntax backwards from
fatload for address/filename :(  And in this case it's passing in too
many params, so I will fix that.

>>> +  __func__, dfu->name, buf, size, blk_seq_num, 
>>> dfu->i_buf); + +if (!dfu->inited) { +   ret =
>>> dfu->read_medium(dfu, 0, NULL, &dfu->r_left);
>  this call causes read error. I suppose, that it is an
> initial "read". Does it read the whole file at once?

I'll double check what's going on over here.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRPdQ+AAoJENk4IS6UOR1WYzgP/RwNBOTJ7XPM9mrFFU+3UtyA
Z/tUwuyghitC/rBBPuUyoml6Oq+9oVtCd89uZyjYjFUh68HKGSZ6a+XaLl1KC9Yr
n/3m91CXgnJAdh3TcrGoX6Gg9dVPb0vomLZpyZg/UK71PNnXcFI9BAvkXlfwUi1r
KbPDF10WzNq4qACELdwHKP8gumhBvgB+qyCHjFRalD/jk9HS1Nv7rIpgng2eQpbv
kGyRzZRJNmJ5s0/XSlg6G+XP9seE23oAw1eLZRO3bF33PcynC1L2R96iBLU4dIcQ
BHQp3jC+3m7v543eXqNvBaBJDIuABkqm8Or0xdw18T8d0unci+VxRXNvVlI2VrdL
fhhj47cSEKzAEJ6KTzwwvZl4CUnqfExPds/yTWl5CF+PNukw91b7kZca2uOuEtkM
htbQthvt7jzaD5Ji0U8R3FF3cJ39g1XVOARpY1hzPeHMrX83b5dHFPg0LDEj31qK
FWkNElx4MHgu2Cir8cBWGaFwAHxXqyG9VfPX2LwHD6zCLHmKryq+UlH+KfZgi3UE
u0vDxH24jeGccDc6BIXgJdDvt8AN8SQgXtpV6xrCWEPYR90GBpM8/yOIeTbxzuky
hTi2Ke8VxIGYmVWBDQ/YtKoANL1peiZuFB/DmoMA9d6WbQDkZbmgI0lQ+3x6kZxs
WRBsQxgaW4Yf6nIUv5X3
=t1hs
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards

[Fabio Estevam]

Hi Stefano,

On Mon, Mar 11, 2013 at 9:04 AM, Stefano Babic  wrote:

> As set previously, my position is, since RFC patches were pushed in
> January, that some kind of complexity can be well managed with SPL
> instead of with very SOC specific code. However, in the meantime I said
> explicitely that I was not against the current patchset in the form Eric
> posted now. I understand this can be seen as a temporary solution, but
> let's increase the number of users using these boards, and taking into
> account that some other pending patches can help to switch to SPL.
>
> In fact, there also other patchsets that I hope will be merged soon and
> will make the swicth to SPL easier - I mean Benoit's patches regarding
> NAND on MX5 and dropping old spl code from some boards.

Just to make sure I understand the plan:

Do you mean that you are willing to accept current Eric's series for
adding nitrogen support into 2013.04, and after this we should work on
converting it to the SPL mechanism for 2013.07?

Thanks,

Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v5] Addition of btrfs to u-boot

[Adnan Ali]

Adnan Ali (1):
  Introduced btrfs file-system with btrload command

 Makefile   |1 +
 common/Makefile|1 +
 common/cmd_btr.c   |   65 +++
 fs/btrfs/Makefile  |   51 ++
 fs/btrfs/btrfs.c   | 1348 
 fs/btrfs/crc32_c.c |   54 ++
 fs/fs.c|   10 +
 include/btrfs.h|  416 ++
 include/config_fallbacks.h |4 +
 include/fs.h   |1 +
 10 files changed, 1951 insertions(+)
 create mode 100644 common/cmd_btr.c
 create mode 100644 fs/btrfs/Makefile
 create mode 100644 fs/btrfs/btrfs.c
 create mode 100644 fs/btrfs/crc32_c.c
 create mode 100644 include/btrfs.h

-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v5] Introduced btrfs file-system with btrload command

[Adnan Ali]

Introduces btrfs file-system to read file from
volume/sub-volumes with btrload command. This
implementation has read-only support.
This btrfs implementation is based on syslinux btrfs
code, commit 269ebc845ebc8b46ef4b0be7fa0005c7fdb95b8d.

v5: merged with master.
v4: btrls command added.
v3: patch re-formated.
v2: patch error removed.

Signed-off-by: Adnan Ali 
---
 Makefile   |1 +
 common/Makefile|1 +
 common/cmd_btr.c   |   65 +++
 fs/btrfs/Makefile  |   51 ++
 fs/btrfs/btrfs.c   | 1348 
 fs/btrfs/crc32_c.c |   54 ++
 fs/fs.c|   10 +
 include/btrfs.h|  416 ++
 include/config_fallbacks.h |4 +
 include/fs.h   |1 +
 10 files changed, 1951 insertions(+)
 create mode 100644 common/cmd_btr.c
 create mode 100644 fs/btrfs/Makefile
 create mode 100644 fs/btrfs/btrfs.c
 create mode 100644 fs/btrfs/crc32_c.c
 create mode 100644 include/btrfs.h

diff --git a/Makefile b/Makefile
index 55bd55c..b3da594 100644
--- a/Makefile
+++ b/Makefile
@@ -257,6 +257,7 @@ endif
 LIBS-$(CONFIG_OF_EMBED) += dts/libdts.o
 LIBS-y += arch/$(ARCH)/lib/lib$(ARCH).o
 LIBS-y += fs/libfs.o \
+fs/btrfs/libbtrfs.o \
fs/cbfs/libcbfs.o \
fs/cramfs/libcramfs.o \
fs/ext4/libext4fs.o \
diff --git a/common/Makefile b/common/Makefile
index 719fc23..d1fae56 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -73,6 +73,7 @@ COBJS-$(CONFIG_CMD_BEDBUG) += bedbug.o cmd_bedbug.o
 COBJS-$(CONFIG_CMD_BMP) += cmd_bmp.o
 COBJS-$(CONFIG_CMD_BOOTLDR) += cmd_bootldr.o
 COBJS-$(CONFIG_CMD_BOOTSTAGE) += cmd_bootstage.o
+COBJS-$(CONFIG_CMD_BTR) += cmd_btr.o
 COBJS-$(CONFIG_CMD_CACHE) += cmd_cache.o
 COBJS-$(CONFIG_CMD_CBFS) += cmd_cbfs.o
 COBJS-$(CONFIG_CMD_CONSOLE) += cmd_console.o
diff --git a/common/cmd_btr.c b/common/cmd_btr.c
new file mode 100644
index 000..846c0f1
--- /dev/null
+++ b/common/cmd_btr.c
@@ -0,0 +1,65 @@
+/*
+ * (C) Copyright 2013 Codethink Limited
+ * Btrfs port to Uboot by
+ * Adnan Ali 
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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
+ */
+
+/*
+ * Boot support
+ */
+#include 
+#include 
+
+char subvolname[BTRFS_MAX_SUBVOL_NAME];
+
+int do_btr_fsload(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   if (argc > 5)
+   strcpy(subvolname, argv[5]);
+   else
+   strcpy(subvolname, "");
+
+   return do_load(cmdtp, flag, argc, argv, FS_TYPE_BTR, 16);
+}
+
+
+U_BOOT_CMD(
+   btrload,7,  0,  do_btr_fsload,
+   "load binary file from a btr filesystem",
+   " [][subvol_name]\n"
+   "- Load binary file 'filename' from 'dev' on 'interface'\n"
+   "  to address 'addr' from better filesystem.\n"
+   "  the load stops on end of file.\n"
+   "  subvol_name is used read that file from this subvolume.\n"
+   "  All numeric parameters are assumed to be hex."
+);
+
+static int do_btr_ls(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+return do_ls(cmdtp, flag, argc, argv, FS_TYPE_BTR);
+}
+
+U_BOOT_CMD(
+btrls,  4,  1,  do_btr_ls,
+"list files in a directory (default /)",
+" [] [directory]\n"
+"- list files from 'dev' on 'interface' in a 'directory'"
+);
+
diff --git a/fs/btrfs/Makefile b/fs/btrfs/Makefile
new file mode 100644
index 000..f767b2c
--- /dev/null
+++ b/fs/btrfs/Makefile
@@ -0,0 +1,51 @@
+#
+# (C) Copyright 2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2003
+# Pavel Bartusek, Sysgo Real-Time Solutions AG, p...@sysgo.de
+#
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# 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 

Re: [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards

[Eric Nelson]

Thanks Wolfgang,

On 03/11/2013 04:15 AM, Wolfgang Denk wrote:

Dear Eric,

In message <513d18f3.2010...@boundarydevices.com> you wrote:


I understand the point, but think the pain is manageable and
mostly ours.


When I say it doesn't scale, I'm not only thinking about yourown
efforts, and your customers.

I also think about things like the increase of build and test time for
_everybody_ who performs tests on U-Boot - instead of one board, we
now have to build - how many? 6? - configurations.  If we allow this
now, others will copy this approach (and we cannot really reject it
then). I really would like to avoid setting such a precedent here.



Would it help if we restrict the number of boards directly in
boards.cfg?

We can easily have local patches for the non-standard memory
configurations in our repository, and this will at least allow
build tests to include the processor variants.




This step has broken things up into parts so that we
**can** express multiple memory configurations within
a single board directory, and I hope it moves the ball
forward a step or two.


It does.  But source base is one thing.  Havnig to deal with a large
number of configurations to build and test is another one, and here
you put additional burdon on a large number of prople.


Our hope in getting this main-lined was that other upcoming
Solo and Dual-Lite platforms could share some of the bits.


Understood and appreciated.  But I also see this ias a strong reason
to come up with a clean design, and not create bad examples which
others without doubt will interpret as persuasive precedent.



Our hope is that the things we're adding are useful, and not
a burden.

We'll be happy to pursue the SPL route, but this won't be
something that we can devote cycles to in the next few weeks.

Regards,


Eric

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards

[Stefano Babic]

On 11/03/2013 14:18, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Mon, Mar 11, 2013 at 9:04 AM, Stefano Babic  wrote:
> 
>> As set previously, my position is, since RFC patches were pushed in
>> January, that some kind of complexity can be well managed with SPL
>> instead of with very SOC specific code. However, in the meantime I said
>> explicitely that I was not against the current patchset in the form Eric
>> posted now. I understand this can be seen as a temporary solution, but
>> let's increase the number of users using these boards, and taking into
>> account that some other pending patches can help to switch to SPL.
>>
>> In fact, there also other patchsets that I hope will be merged soon and
>> will make the swicth to SPL easier - I mean Benoit's patches regarding
>> NAND on MX5 and dropping old spl code from some boards.
> 
> Just to make sure I understand the plan:
> 
> Do you mean that you are willing to accept current Eric's series for
> adding nitrogen support into 2013.04, and after this we should work on
> converting it to the SPL mechanism for 2013.07?

IMHO, yes. The long term solution is using SPL, as well as it is already
used in other SOCs. But at the moment, I tend to not block the current
series, taking into account that we have not yet a i.MX6 board with SPL.

Best regards,
Stefano


-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards

[Fabio Estevam]

On Mon, Mar 11, 2013 at 10:44 AM, Stefano Babic  wrote:

> IMHO, yes. The long term solution is using SPL, as well as it is already
> used in other SOCs. But at the moment, I tend to not block the current
> series, taking into account that we have not yet a i.MX6 board with SPL.

Thanks, Stefano. Sounds like a good approach.

Regards,

Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards

[Eric Nelson]

Thanks Stefano,

On 03/11/2013 06:44 AM, Stefano Babic wrote:

On 11/03/2013 14:18, Fabio Estevam wrote:

Hi Stefano,

On Mon, Mar 11, 2013 at 9:04 AM, Stefano Babic  wrote:


As set previously, my position is, since RFC patches were pushed in
January, that some kind of complexity can be well managed with SPL
instead of with very SOC specific code. However, in the meantime I said
explicitely that I was not against the current patchset in the form Eric
posted now. I understand this can be seen as a temporary solution, but
let's increase the number of users using these boards, and taking into
account that some other pending patches can help to switch to SPL.

In fact, there also other patchsets that I hope will be merged soon and
will make the swicth to SPL easier - I mean Benoit's patches regarding
NAND on MX5 and dropping old spl code from some boards.


Just to make sure I understand the plan:

Do you mean that you are willing to accept current Eric's series for
adding nitrogen support into 2013.04, and after this we should work on
converting it to the SPL mechanism for 2013.07?


IMHO, yes. The long term solution is using SPL, as well as it is already
used in other SOCs. But at the moment, I tend to not block the current
series, taking into account that we have not yet a i.MX6 board with SPL.



Then I'll forward a V3 (without get_ram_size()).

Do you want me to restrict the number of configurations to the
"standard" memory configurations?

Please advise,


Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards

[Stefano Babic]

On 11/03/2013 15:02, Eric Nelson wrote:
> Thanks Stefano,
> 
> On 03/11/2013 06:44 AM, Stefano Babic wrote:
>> On 11/03/2013 14:18, Fabio Estevam wrote:
>>> Hi Stefano,
>>>
>>> On Mon, Mar 11, 2013 at 9:04 AM, Stefano Babic  wrote:
>>>
 As set previously, my position is, since RFC patches were pushed in
 January, that some kind of complexity can be well managed with SPL
 instead of with very SOC specific code. However, in the meantime I said
 explicitely that I was not against the current patchset in the form
 Eric
 posted now. I understand this can be seen as a temporary solution, but
 let's increase the number of users using these boards, and taking into
 account that some other pending patches can help to switch to SPL.

 In fact, there also other patchsets that I hope will be merged soon and
 will make the swicth to SPL easier - I mean Benoit's patches regarding
 NAND on MX5 and dropping old spl code from some boards.
>>>
>>> Just to make sure I understand the plan:
>>>
>>> Do you mean that you are willing to accept current Eric's series for
>>> adding nitrogen support into 2013.04, and after this we should work on
>>> converting it to the SPL mechanism for 2013.07?
>>
>> IMHO, yes. The long term solution is using SPL, as well as it is already
>> used in other SOCs. But at the moment, I tend to not block the current
>> series, taking into account that we have not yet a i.MX6 board with SPL.
>>
> 
> Then I'll forward a V3 (without get_ram_size()).
> 
> Do you want me to restrict the number of configurations to the
> "standard" memory configurations?

Well, this could avoid that we add now a lot of files with the hope that
later they will be cleanued up, and then this does not happen - and
further configurations will be added later after switching to SPL.

Best regards,
Stefano

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/11/2013 10:30 AM, Stefano Babic wrote:
> On 11/03/2013 15:02, Eric Nelson wrote:
>> Thanks Stefano,
>> 
>> On 03/11/2013 06:44 AM, Stefano Babic wrote:
>>> On 11/03/2013 14:18, Fabio Estevam wrote:
 Hi Stefano,
 
 On Mon, Mar 11, 2013 at 9:04 AM, Stefano Babic
  wrote:
 
> As set previously, my position is, since RFC patches were
> pushed in January, that some kind of complexity can be well
> managed with SPL instead of with very SOC specific code.
> However, in the meantime I said explicitely that I was not
> against the current patchset in the form Eric posted now. I
> understand this can be seen as a temporary solution, but 
> let's increase the number of users using these boards, and
> taking into account that some other pending patches can
> help to switch to SPL.
> 
> In fact, there also other patchsets that I hope will be
> merged soon and will make the swicth to SPL easier - I mean
> Benoit's patches regarding NAND on MX5 and dropping old spl
> code from some boards.
 
 Just to make sure I understand the plan:
 
 Do you mean that you are willing to accept current Eric's
 series for adding nitrogen support into 2013.04, and after
 this we should work on converting it to the SPL mechanism for
 2013.07?
>>> 
>>> IMHO, yes. The long term solution is using SPL, as well as it
>>> is already used in other SOCs. But at the moment, I tend to not
>>> block the current series, taking into account that we have not
>>> yet a i.MX6 board with SPL.
>>> 
>> 
>> Then I'll forward a V3 (without get_ram_size()).
>> 
>> Do you want me to restrict the number of configurations to the 
>> "standard" memory configurations?
> 
> Well, this could avoid that we add now a lot of files with the hope
> that later they will be cleanued up, and then this does not happen
> - and further configurations will be added later after switching to
> SPL.

Lets go this route AND make sure it's well documented enough that
people with their own custom HW can easily adapt the existing examples
to meet their setup (and yes, in the near future, work towards
migration to SPL).

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRPeyfAAoJENk4IS6UOR1WqFYP/RsEjuooD6TzhFc9KoULRFlG
IjkOvlzF8DIAVL3Zm3/Z4AOm6NkJeE5ZH47An4579Xz2ENmWYYHjeUF6ffbBMXmD
7wiwhdY99gnKEgXMJDWBzlqUCBHJucuIWX1bJIZqIElLos0VgC3UCZlwH/TQBHBx
ZaP+m35BZErtElV0Lp6ezLp7HvBbXww9kb7Tif5z/T9fMirXV7biLGVT1Rm0ENVB
OiCHHpF2k7JKviRPXrEGRHuFteyKj0XRi4AY8UQ5OWvi7HYEA0dQ9lAejHzRvBVA
xBU0fsj1/dIasaSGn9bCwcG86A/H96BlAbYMsKlEEw0PIg0NiogGt0FObpAlxtSd
6z3LA6f2KfD3WVTO3hHyv1miMBvOxH12QQZ9jUo5k9AMnxM0zRsUi/fw7+NE1ifr
L+Z9j38HfW9iUPyn1yU2IketMdpj2wYJFUb2GxOJJhLvueQutnlg9OMymBnUeTpk
PoD5ukL1d2WIC3uhxY8lG28PSxqscua5gJKB1AnPJquSId3ST6NYid8vTolyqruT
WXRISvm/XlXoD9If883+JxDJEY+4vt/pagDKfBpLEJRlttZdr1aTUE9+SpPZN3vO
DO+p/NeZ1O6HW+9B6nm6YQGypv3b1bF0lmf1nM+A9FZ7L/vh/mzs4q7U5HmNcg0m
69t+jnn8PZxBQI/SAsQA
=aQs3
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PULL REQUEST] MPC5xxx

[Tom Rini]

On Sat, Mar 09, 2013 at 04:02:35PM +0100, Wolfgang Denk wrote:

> Dear Tom,
> 
> I apologize for being inattentive for so long...
> 
> 
> The following changes since commit fc959081d41aab2d6f4614c5fb3dd1b77ffcdcf4:
> 
>   x86: Enable CONFIG_OF_CONTROL on coreboot (2013-03-04 15:57:52 -0800)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-mpc5xxx master
> 
> for you to fetch changes up to 5a35831b1f427a91ae06c971c2b3b4d9843372a1:
> 
>   mpc512x: pdm360ng: drop not needed memory node fixup (2013-03-09 08:23:08 
> +0100)
> 
> 
> Anatolij Gustschin (8):
>   mpc512x: add common LAW and Chip Select configuration
>   mpc512x: use common code for CSx configuration
>   mpc512x: use common code for clock setting for all mpc512x boards
>   mpc512x: optionally configure DIU, LPC and NFC deviders
>   mpc512x: allow configuring board specific IPS divider
>   mpc512x: add ifm ac14xx board
>   mpc512x: Adjust the DRAM init sequence to the datasheet spec
>   mpc512x: pdm360ng: drop not needed memory node fixup
> 
> Stefan Roese (3):
>   mpc5200: spl_boot.c: Change init oder to first enable printf
>   mpc5200: Add a4m2k board port
>   mpc5200: a4m2k: Implement custom "dynamic" watchdog support
> 
>  MAINTAINERS |   2 +
>  arch/powerpc/cpu/mpc512x/cpu_init.c | 120 +++
>  arch/powerpc/cpu/mpc512x/fixed_sdram.c  |  17 +-
>  arch/powerpc/cpu/mpc512x/iopin.c|  54 +++
>  arch/powerpc/cpu/mpc5xxx/spl_boot.c |  20 +-
>  arch/powerpc/include/asm/immap_512x.h   |  22 ++
>  board/a3m071/README |   2 +-
>  board/a3m071/a3m071.c   | 147 +++-
>  board/a3m071/is46r16320d.h  |  35 ++
>  board/davedenx/aria/aria.c  |  64 
>  board/esd/mecp5123/mecp5123.c   |  54 ---
>  board/freescale/mpc5121ads/mpc5121ads.c |  52 ---
>  board/ifm/ac14xx/Makefile   |  34 ++
>  board/ifm/ac14xx/ac14xx.c   | 617 
> 
>  board/pdm360ng/pdm360ng.c   |  58 ---
>  boards.cfg  |   2 +
>  include/configs/a3m071.h| 118 +++---
>  include/configs/ac14xx.h| 591 ++
>  include/configs/aria.h  |  23 +-
>  include/configs/mecp5123.h  |  24 ++
>  include/configs/mpc5121ads.h|  23 ++
>  include/configs/pdm360ng.h  |  24 +-
>  22 files changed, 1810 insertions(+), 293 deletions(-)
>  create mode 100644 board/a3m071/is46r16320d.h
>  create mode 100644 board/ifm/ac14xx/Makefile
>  create mode 100644 board/ifm/ac14xx/ac14xx.c
>  create mode 100644 include/configs/ac14xx.h

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PULL REQUEST] MPC82xx

[Tom Rini]

On Sat, Mar 09, 2013 at 04:07:24PM +0100, Wolfgang Denk wrote:

> Dear Tom,
> 
> The following changes since commit fc959081d41aab2d6f4614c5fb3dd1b77ffcdcf4:
> 
>   x86: Enable CONFIG_OF_CONTROL on coreboot (2013-03-04 15:57:52 -0800)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-mpc82xx master
> 
> for you to fetch changes up to 8327122b0d25a4be29292ff30293f1241bbcfb5b:
> 
>   powerpc/82xx/km: removed unneeded ifdef (2013-03-09 16:05:00 +0100)
> 
> 
> Holger Brunck (2):
>   powerpc/82xx/km: make handle_mgcoge3un_reset static
>   powerpc/82xx/km: removed unneeded ifdef
> 
>  board/keymile/km82xx/km82xx.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 0/15] Enhance SPI/SPI flash probing, add support for Intel ICH controller

[Simon Glass]

Adding new fields to struct spi_slave and struct spi_flash is painful,
because most drivers don't zero the fields they don't use. Anyway it
seems better to have the SPI/SPI flash infrastructure provide a simple
way of doing this that all drivers can use.

So the first part of this series adds spi_alloc_slave(), for SPI, and
spi_flash_alloc() for SPI flash.

Support is added for the Intel ICH SPI controller, possibly the oddest
SPI controller in U-Boot. It is designed for use with SPI flash only,
and has a number of high-level features which are dedicated to flash.
As such it is a bit of a challenge to get it to behave just like a
normal U-Boot SPI device.

The ICH driver has two interesting features. Firstly it is impossible
to read or write more than 64 bytes at a time! For SPI reading it is
possible to hide this within the SPI driver. For SPI writing it
unfortunately isn't, since the spi_flash layer has to send an unlock
command and a new address for every write. It would be an egregious
hack to try to fake this in the driver. So a new property is added
to spi_flash to allow the maximum transfer size to be set.

Secondly, the ICH SPI flash can be memory mapped. On a lot of x86
devices this improves performance significantly. For example, the standard
driver gets maybe 12Mbps throughput from a 33Mbps dual interface, roughly
20% utilisation. With memory mapping, many platforms can achieve about
40Mbps. To implement memory mapping, a new property is provided in the
device tree to set the memory map address, which varies by platform. Some
x86 platforms will see a speed increase with memory mapping, some won't.
The memory mapping feature only works for reading. When in use, the
spi_flash layer bypasses the SPI driver completely, and just copies the
flash data from the correct place in the memory map.

Changes in v2:
- Use spi_alloc_slave() in bfin_spi6xx.c
- Use spi_alloc_slave() in exynos_spi.c
- Support both 33MHz and 20MHz operation in ich driver
- Replace while() loop with memcpy_to/fromio() in ich driver
- Enable gettime command for coreboot also
- Add new patch to use unsigned type for buffers in 'sf test'

Simon Glass (15):
  fdt: Add fdtdec_get_addr_size() to read reg properties
  spi: Add function to allocate a new SPI slave
  spi: Use spi_alloc_slave() in each SPI driver
  sf: Add spi_flash_alloc() to create a new SPI flash struct
  sf: Use spi_flash_alloc() in each SPI flash driver
  x86: spi: Add Intel ICH driver
  spi: Add parameter for maximum write size
  sf: Respect maximum SPI write size
  x86: spi: Set maximum write size for ICH
  sf: Enable FDT-based configuration and memory mapping
  x86: Move PCI init before SPI init
  x86: Add FDT SPI node for link
  x86: Enable SPI flash support for coreboot
  x86: Enable time command for coreboot
  sf: Use unsigned type for buffers

 arch/x86/lib/board.c  |   8 +-
 board/chromebook-x86/dts/link.dts |  11 +
 common/cmd_sf.c   |   8 +-
 drivers/mtd/spi/atmel.c   |   8 +-
 drivers/mtd/spi/eon.c |   8 +-
 drivers/mtd/spi/macronix.c|   8 +-
 drivers/mtd/spi/ramtron.c |   4 +-
 drivers/mtd/spi/spansion.c|   8 +-
 drivers/mtd/spi/spi_flash.c   |  81 +++-
 drivers/mtd/spi/sst.c |   8 +-
 drivers/mtd/spi/stmicro.c |   8 +-
 drivers/mtd/spi/winbond.c |   8 +-
 drivers/spi/Makefile  |   4 +
 drivers/spi/altera_spi.c  |   4 +-
 drivers/spi/andes_spi.c   |   4 +-
 drivers/spi/armada100_spi.c   |   4 +-
 drivers/spi/atmel_spi.c   |   4 +-
 drivers/spi/bfin_spi.c|   4 +-
 drivers/spi/bfin_spi6xx.c |   4 +-
 drivers/spi/cf_qspi.c |   4 +-
 drivers/spi/cf_spi.c  |   4 +-
 drivers/spi/davinci_spi.c |   4 +-
 drivers/spi/exynos_spi.c  |   4 +-
 drivers/spi/fsl_espi.c|   4 +-
 drivers/spi/ich.c | 755 ++
 drivers/spi/ich.h | 144 
 drivers/spi/kirkwood_spi.c|   5 +-
 drivers/spi/mpc52xx_spi.c |   5 +-
 drivers/spi/mpc8xxx_spi.c |   5 +-
 drivers/spi/mxc_spi.c |   4 +-
 drivers/spi/mxs_spi.c |   4 +-
 drivers/spi/oc_tiny_spi.c |   5 +-
 drivers/spi/omap3_spi.c   |  27 +-
 drivers/spi/sh_spi.c  |   4 +-
 drivers/spi/soft_spi.c|   4 +-
 drivers/spi/spi.c |  39 ++
 drivers/spi/tegra_slink.c |   4 +-
 drivers/spi/tegra_spi.c   |   4 +-
 drivers/spi/xilinx_spi.c  |   4 +-
 include/configs/coreboot.h|  14 +-
 include/fdtdec.h  |  16 +
 include/spi.h |  44 +++
 include/spi_flash.h   |  39 ++
 lib/fdtdec.c  |  27 +-
 44 files changed, 1215 insertions(+), 154 deletions(-)
 create mode 100644 drivers/spi/ich.c
 create mode 100644 drivers/spi/ich.h
 create mode 100644 drivers/spi/spi.c

-- 
1.8.1.3

[U-Boot] [PATCH v2 04/15] sf: Add spi_flash_alloc() to create a new SPI flash struct

[Simon Glass]

At present it is difficult to extend the SPI flash structure since
all devices allocate it themselves, and few of them zero all fields.
Add a new function spi_flash_alloc() which can be used by SPI devices
to perform this allocation, and thus ensure that all devices can
better cope with SPI structure changes.

Signed-off-by: Simon Glass 
---
Changes in v2: None

 drivers/mtd/spi/spi_flash.c | 25 +
 include/spi_flash.h | 38 ++
 2 files changed, 63 insertions(+)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 00aece9..17f3d3c 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -401,6 +401,31 @@ err_claim_bus:
return NULL;
 }
 
+void *spi_flash_do_alloc(int offset, int size, struct spi_slave *spi,
+const char *name)
+{
+   struct spi_flash *flash;
+   void *ptr;
+
+   ptr = malloc(size);
+   if (!ptr) {
+   debug("SF: Failed to allocate memory\n");
+   return NULL;
+   }
+   memset(ptr, '\0', size);
+   flash = (struct spi_flash *)(ptr + offset);
+
+   /* Set up some basic fields - caller will sort out sizes */
+   flash->spi = spi;
+   flash->name = name;
+
+   flash->read = spi_flash_cmd_read_fast;
+   flash->write = spi_flash_cmd_write_multi;
+   flash->erase = spi_flash_cmd_erase;
+
+   return flash;
+}
+
 void spi_flash_free(struct spi_flash *flash)
 {
spi_free_slave(flash->spi);
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 9da9062..030d49c 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -47,6 +47,44 @@ struct spi_flash {
size_t len);
 };
 
+/**
+ * spi_flash_do_alloc - Allocate a new spi flash structure
+ *
+ * The structure is allocated and cleared with default values for
+ * read, write and erase, which the caller can modify. The caller must set
+ * up size, page_size and sector_size.
+ *
+ * Use the helper macro spi_flash_alloc() to call this.
+ *
+ * @offset: Offset of struct spi_slave within slave structure
+ * @size: Size of slave structure
+ * @spi: SPI slave
+ * @name: Name of SPI flash device
+ */
+void *spi_flash_do_alloc(int offset, int size, struct spi_slave *spi,
+const char *name);
+
+/**
+ * spi_flash_alloc - Allocate a new SPI flash structure
+ *
+ * @_struct: Name of structure to allocate (e.g. struct ramtron_spi_fram). This
+ * structure must contain a member 'struct spi_flash *flash'.
+ * @spi: SPI slave
+ * @name: Name of SPI flash device
+ */
+#define spi_flash_alloc(_struct, spi, name) \
+   spi_flash_do_alloc(offsetof(_struct, flash), sizeof(_struct), \
+   spi, name)
+
+/**
+ * spi_flash_alloc_base - Allocate a new SPI flash structure with no private 
data
+ *
+ * @spi: SPI slave
+ * @name: Name of SPI flash device
+ */
+#define spi_flash_alloc_base(spi, name) \
+   spi_flash_do_alloc(0, sizeof(struct spi_flash), spi, name)
+
 struct spi_flash *spi_flash_probe(unsigned int bus, unsigned int cs,
unsigned int max_hz, unsigned int spi_mode);
 void spi_flash_free(struct spi_flash *flash);
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 03/15] spi: Use spi_alloc_slave() in each SPI driver

[Simon Glass]

Rather than each driver having its own way to allocate a SPI slave,
use the new allocation function everywhere. This will make it easier
to extend the interface without breaking drivers.

Signed-off-by: Simon Glass 
---
Changes in v2:
- Use spi_alloc_slave() in bfin_spi6xx.c
- Use spi_alloc_slave() in exynos_spi.c

 drivers/spi/altera_spi.c|  4 +---
 drivers/spi/andes_spi.c |  4 +---
 drivers/spi/armada100_spi.c |  4 +---
 drivers/spi/atmel_spi.c |  4 +---
 drivers/spi/bfin_spi.c  |  4 +---
 drivers/spi/bfin_spi6xx.c   |  4 +---
 drivers/spi/cf_qspi.c   |  4 +---
 drivers/spi/cf_spi.c|  4 +---
 drivers/spi/davinci_spi.c   |  4 +---
 drivers/spi/exynos_spi.c|  4 +---
 drivers/spi/fsl_espi.c  |  4 +---
 drivers/spi/kirkwood_spi.c  |  5 +
 drivers/spi/mpc52xx_spi.c   |  5 +
 drivers/spi/mpc8xxx_spi.c   |  5 +
 drivers/spi/mxc_spi.c   |  4 +---
 drivers/spi/mxs_spi.c   |  4 +---
 drivers/spi/oc_tiny_spi.c   |  5 +
 drivers/spi/omap3_spi.c | 27 ++-
 drivers/spi/sh_spi.c|  4 +---
 drivers/spi/soft_spi.c  |  4 +---
 drivers/spi/tegra_slink.c   |  4 +---
 drivers/spi/tegra_spi.c |  4 +---
 drivers/spi/xilinx_spi.c|  4 +---
 23 files changed, 36 insertions(+), 83 deletions(-)

diff --git a/drivers/spi/altera_spi.c b/drivers/spi/altera_spi.c
index 138d6f4..b53607a 100644
--- a/drivers/spi/altera_spi.c
+++ b/drivers/spi/altera_spi.c
@@ -83,12 +83,10 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
if (!spi_cs_is_valid(bus, cs))
return NULL;
 
-   altspi = malloc(sizeof(*altspi));
+   altspi = spi_alloc_slave(struct altera_spi_slave, bus, cs);
if (!altspi)
return NULL;
 
-   altspi->slave.bus = bus;
-   altspi->slave.cs = cs;
altspi->base = altera_spi_base_list[bus];
debug("%s: bus:%i cs:%i base:%lx\n", __func__,
bus, cs, altspi->base);
diff --git a/drivers/spi/andes_spi.c b/drivers/spi/andes_spi.c
index fdde139..c56377b 100644
--- a/drivers/spi/andes_spi.c
+++ b/drivers/spi/andes_spi.c
@@ -53,12 +53,10 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
if (!spi_cs_is_valid(bus, cs))
return NULL;
 
-   ds = malloc(sizeof(*ds));
+   ds = spi_alloc_slave(struct andes_spi_slave, bus, cs);
if (!ds)
return NULL;
 
-   ds->slave.bus = bus;
-   ds->slave.cs = cs;
ds->regs = (struct andes_spi_regs *)CONFIG_SYS_SPI_BASE;
 
/*
diff --git a/drivers/spi/armada100_spi.c b/drivers/spi/armada100_spi.c
index 7384c9c..afdbe05 100644
--- a/drivers/spi/armada100_spi.c
+++ b/drivers/spi/armada100_spi.c
@@ -120,12 +120,10 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
 {
struct armd_spi_slave *pss;
 
-   pss = malloc(sizeof(*pss));
+   pss = spi_alloc_slave(struct armd_spi_slave, bus, cs);
if (!pss)
return NULL;
 
-   pss->slave.bus = bus;
-   pss->slave.cs = cs;
pss->spi_reg = (struct ssp_reg *)SSP_REG_BASE(CONFIG_SYS_SSP_PORT);
 
pss->cr0 = SSCR0_MOTO | SSCR0_DATASIZE(DEFAULT_WORD_LEN) | SSCR0_SSE;
diff --git a/drivers/spi/atmel_spi.c b/drivers/spi/atmel_spi.c
index ce7d460..f4b1bad 100644
--- a/drivers/spi/atmel_spi.c
+++ b/drivers/spi/atmel_spi.c
@@ -84,12 +84,10 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
if (mode & SPI_CPOL)
csrx |= ATMEL_SPI_CSRx_CPOL;
 
-   as = malloc(sizeof(struct atmel_spi_slave));
+   as = spi_alloc_slave(struct atmel_spi_slave, bus, cs);
if (!as)
return NULL;
 
-   as->slave.bus = bus;
-   as->slave.cs = cs;
as->regs = regs;
as->mr = ATMEL_SPI_MR_MSTR | ATMEL_SPI_MR_MODFDIS
 #if defined(CONFIG_AT91SAM9X5) || defined(CONFIG_AT91SAM9M10G45)
diff --git a/drivers/spi/bfin_spi.c b/drivers/spi/bfin_spi.c
index e080bec..ab2e8b9 100644
--- a/drivers/spi/bfin_spi.c
+++ b/drivers/spi/bfin_spi.c
@@ -182,12 +182,10 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
default: return NULL;
}
 
-   bss = malloc(sizeof(*bss));
+   bss = spi_alloc_slave(struct bfin_spi_slave, bus, cs);
if (!bss)
return NULL;
 
-   bss->slave.bus = bus;
-   bss->slave.cs = cs;
bss->mmr_base = (void *)mmr_base;
bss->ctl = SPE | MSTR | TDBR_CORE;
if (mode & SPI_CPHA) bss->ctl |= CPHA;
diff --git a/drivers/spi/bfin_spi6xx.c b/drivers/spi/bfin_spi6xx.c
index fde3447..c25c4a9 100644
--- a/drivers/spi/bfin_spi6xx.c
+++ b/drivers/spi/bfin_spi6xx.c
@@ -178,12 +178,10 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
return NULL;
}
 
-   bss = malloc(sizeof(*bss));
+   bss = spi_alloc_slave(struct bfin_spi_slave, bus, cs);
if (!bss)
return NULL;
 
-

[U-Boot] [PATCH v2 11/15] x86: Move PCI init before SPI init

[Simon Glass]

It is possible that our PCI bus will provide the SPI controller, so change
the init order to make this work.

Signed-off-by: Simon Glass 
---
Changes in v2: None

 arch/x86/lib/board.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index 2441a66..e727374 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
@@ -163,13 +163,13 @@ init_fnc_t *init_sequence_r[] = {
 #ifndef CONFIG_SYS_NO_FLASH
flash_init_r,
 #endif
-#ifdef CONFIG_SPI
-   init_func_spi;
-#endif
-   env_relocate_r,
 #ifdef CONFIG_PCI
pci_init_r,
 #endif
+#ifdef CONFIG_SPI
+   init_func_spi,
+#endif
+   env_relocate_r,
stdio_init,
jumptable_init_r,
console_init_r,
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 14/15] x86: Enable time command for coreboot

[Simon Glass]

This command is useful for measuring SPI flash load times and the like.
Enable gettime as well to obtain absolute time tick values.

Signed-off-by: Simon Glass 
---
Changes in v2:
- Enable gettime command for coreboot also

 include/configs/coreboot.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h
index 4826756..1a763ab 100644
--- a/include/configs/coreboot.h
+++ b/include/configs/coreboot.h
@@ -179,6 +179,8 @@
 #define CONFIG_CMD_SAVEENV
 #define CONFIG_CMD_SETGETDCR
 #define CONFIG_CMD_SOURCE
+#define CONFIG_CMD_TIME
+#define CONFIG_CMD_GETTIME
 #define CONFIG_CMD_XIMG
 #define CONFIG_CMD_SCSI
 
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 12/15] x86: Add FDT SPI node for link

[Simon Glass]

Add a memory-mapped 8GB SPI chip.

Signed-off-by: Simon Glass 
---
Changes in v2: None

 board/chromebook-x86/dts/link.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/board/chromebook-x86/dts/link.dts 
b/board/chromebook-x86/dts/link.dts
index ae8217d..d0738cb 100644
--- a/board/chromebook-x86/dts/link.dts
+++ b/board/chromebook-x86/dts/link.dts
@@ -21,4 +21,15 @@
 
 chosen { };
 memory { device_type = "memory"; reg = <0 0>; };
+
+   spi {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "intel,ich9";
+   spi-flash@0 {
+   reg = <0>;
+   compatible = "winbond,w25q64", "spi-flash";
+   memory-map = <0xff80 0x0080>;
+   };
+   };
 };
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 05/15] sf: Use spi_flash_alloc() in each SPI flash driver

[Simon Glass]

Rather than each device having its own way to allocate a SPI flash
structure, use the new allocation function everywhere. This will make it
easier to extend the interface without breaking devices.

Signed-off-by: Simon Glass 
---
Changes in v2: None

 drivers/mtd/spi/atmel.c| 8 +---
 drivers/mtd/spi/eon.c  | 8 +---
 drivers/mtd/spi/macronix.c | 8 +---
 drivers/mtd/spi/ramtron.c  | 4 +---
 drivers/mtd/spi/spansion.c | 8 +---
 drivers/mtd/spi/sst.c  | 8 +---
 drivers/mtd/spi/stmicro.c  | 8 +---
 drivers/mtd/spi/winbond.c  | 8 +---
 8 files changed, 8 insertions(+), 52 deletions(-)

diff --git a/drivers/mtd/spi/atmel.c b/drivers/mtd/spi/atmel.c
index 006f6d5..6a92c4b 100644
--- a/drivers/mtd/spi/atmel.c
+++ b/drivers/mtd/spi/atmel.c
@@ -480,15 +480,13 @@ struct spi_flash *spi_flash_probe_atmel(struct spi_slave 
*spi, u8 *idcode)
return NULL;
}
 
-   asf = malloc(sizeof(struct atmel_spi_flash));
+   asf = spi_flash_alloc(struct atmel_spi_flash, spi, params->name);
if (!asf) {
debug("SF: Failed to allocate memory\n");
return NULL;
}
 
asf->params = params;
-   asf->flash.spi = spi;
-   asf->flash.name = params->name;
 
/* Assuming power-of-two page size initially. */
page_size = 1 << params->l2_page_size;
@@ -513,7 +511,6 @@ struct spi_flash *spi_flash_probe_atmel(struct spi_slave 
*spi, u8 *idcode)
asf->flash.erase = dataflash_erase_at45;
page_size += 1 << (params->l2_page_size - 5);
} else {
-   asf->flash.read = spi_flash_cmd_read_fast;
asf->flash.write = dataflash_write_p2;
asf->flash.erase = dataflash_erase_p2;
}
@@ -524,9 +521,6 @@ struct spi_flash *spi_flash_probe_atmel(struct spi_slave 
*spi, u8 *idcode)
 
case DF_FAMILY_AT26F:
case DF_FAMILY_AT26DF:
-   asf->flash.read = spi_flash_cmd_read_fast;
-   asf->flash.write = spi_flash_cmd_write_multi;
-   asf->flash.erase = spi_flash_cmd_erase;
asf->flash.page_size = page_size;
asf->flash.sector_size = 4096;
/* clear SPRL# bit for locked flash */
diff --git a/drivers/mtd/spi/eon.c b/drivers/mtd/spi/eon.c
index 691ed4e..b16e7ab 100644
--- a/drivers/mtd/spi/eon.c
+++ b/drivers/mtd/spi/eon.c
@@ -46,18 +46,12 @@ struct spi_flash *spi_flash_probe_eon(struct spi_slave 
*spi, u8 *idcode)
return NULL;
}
 
-   flash = malloc(sizeof(*flash));
+   flash = spi_flash_alloc_base(spi, params->name);
if (!flash) {
debug("SF: Failed to allocate memory\n");
return NULL;
}
 
-   flash->spi = spi;
-   flash->name = params->name;
-
-   flash->write = spi_flash_cmd_write_multi;
-   flash->erase = spi_flash_cmd_erase;
-   flash->read = spi_flash_cmd_read_fast;
flash->page_size = 256;
flash->sector_size = 256 * 16 * 16;
flash->size = 256 * 16
diff --git a/drivers/mtd/spi/macronix.c b/drivers/mtd/spi/macronix.c
index c97a39d..036c30d 100644
--- a/drivers/mtd/spi/macronix.c
+++ b/drivers/mtd/spi/macronix.c
@@ -97,18 +97,12 @@ struct spi_flash *spi_flash_probe_macronix(struct spi_slave 
*spi, u8 *idcode)
return NULL;
}
 
-   flash = malloc(sizeof(*flash));
+   flash = spi_flash_alloc_base(spi, params->name);
if (!flash) {
debug("SF: Failed to allocate memory\n");
return NULL;
}
 
-   flash->spi = spi;
-   flash->name = params->name;
-
-   flash->write = spi_flash_cmd_write_multi;
-   flash->erase = spi_flash_cmd_erase;
-   flash->read = spi_flash_cmd_read_fast;
flash->page_size = 256;
flash->sector_size = 256 * 16 * 16;
flash->size = flash->sector_size * params->nr_blocks;
diff --git a/drivers/mtd/spi/ramtron.c b/drivers/mtd/spi/ramtron.c
index 0999781..5299a6d 100644
--- a/drivers/mtd/spi/ramtron.c
+++ b/drivers/mtd/spi/ramtron.c
@@ -284,15 +284,13 @@ struct spi_flash *spi_fram_probe_ramtron(struct spi_slave 
*spi, u8 *idcode)
return NULL;
 
 found:
-   sn = malloc(sizeof(*sn));
+   sn = spi_flash_alloc(struct ramtron_spi_fram, spi, params->name);
if (!sn) {
debug("SF: Failed to allocate memory\n");
return NULL;
}
 
sn->params = params;
-   sn->flash.spi = spi;
-   sn->flash.name = params->name;
 
sn->flash.write = ramtron_write;
sn->flash.read = ramtron_read;
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index 9288672..bc558c4 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -128,18 +128,12 @@ struct spi_flash *spi_flash_probe_spansion(struct 
spi_slave *spi, u8 *idcode)
return NULL;
 

[U-Boot] [PATCH v2 02/15] spi: Add function to allocate a new SPI slave

[Simon Glass]

At present it is difficult to extend the SPI structure since all
drivers allocate it themselves, and few of them zero all fields. Add
a new function spi_alloc_slave() which can be used by SPI drivers
to perform this allocation, and thus ensure that all drivers can
better cope with SPI structure changes.

Signed-off-by: Simon Glass 
---
Changes in v2: None

 drivers/spi/Makefile |  3 +++
 drivers/spi/spi.c| 39 +++
 include/spi.h| 41 +
 3 files changed, 83 insertions(+)
 create mode 100644 drivers/spi/spi.c

diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index b8264df..45862ec 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -25,6 +25,9 @@ include $(TOPDIR)/config.mk
 
 LIB:= $(obj)libspi.o
 
+# There are many options which enable SPI, so make this library available
+COBJS-y += spi.o
+
 COBJS-$(CONFIG_ALTERA_SPI) += altera_spi.o
 COBJS-$(CONFIG_ANDES_SPI) += andes_spi.o
 COBJS-$(CONFIG_ARMADA100_SPI) += armada100_spi.o
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
new file mode 100644
index 000..cb36c5e
--- /dev/null
+++ b/drivers/spi/spi.c
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ *
+ * 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 
+
+void *spi_do_alloc_slave(int offset, int size, unsigned int bus,
+unsigned int cs)
+{
+   struct spi_slave *slave;
+   void *ptr;
+
+   ptr = malloc(size);
+   if (ptr) {
+   memset(ptr, '\0', size);
+   slave = (struct spi_slave *)(ptr + offset);
+   slave->bus = bus;
+   slave->cs = cs;
+   }
+
+   return ptr;
+}
diff --git a/include/spi.h b/include/spi.h
index 60e85db..ebc9652 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -62,6 +62,47 @@ struct spi_slave {
  */
 void spi_init(void);
 
+/**
+ * spi_do_alloc_slave - Allocate a new SPI slave (internal)
+ *
+ * Allocate and zero all fields in the spi slave, and set the bus/chip
+ * select. Use the helper macro spi_alloc_slave() to call this.
+ *
+ * @offset: Offset of struct spi_slave within slave structure
+ * @size: Size of slave structure
+ * @bus: Bus ID of the slave chip.
+ * @cs: Chip select ID of the slave chip on the specified bus.
+ */
+void *spi_do_alloc_slave(int offset, int size, unsigned int bus,
+unsigned int cs);
+
+/**
+ * spi_alloc_slave - Allocate a new SPI slave
+ *
+ * Allocate and zero all fields in the spi slave, and set the bus/chip
+ * select.
+ *
+ * @_struct: Name of structure to allocate (e.g. struct tegra_spi). This
+ * structure must contain a member 'struct spi_slave *slave'.
+ * @bus: Bus ID of the slave chip.
+ * @cs: Chip select ID of the slave chip on the specified bus.
+ */
+#define spi_alloc_slave(_struct, bus, cs) \
+   spi_do_alloc_slave(offsetof(_struct, slave), \
+   sizeof(_struct), bus, cs)
+
+/**
+ * spi_alloc_slave_base - Allocate a new SPI slave with no private data
+ *
+ * Allocate and zero all fields in the spi slave, and set the bus/chip
+ * select.
+ *
+ * @bus: Bus ID of the slave chip.
+ * @cs: Chip select ID of the slave chip on the specified bus.
+ */
+#define spi_alloc_slave_base(bus, cs) \
+   spi_do_alloc_slave(0, sizeof(struct spi_slave), bus, cs)
+
 /*---
  * Set up communications parameters for a SPI slave.
  *
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 06/15] x86: spi: Add Intel ICH driver

[Simon Glass]

This supports Intel ICH7/9. The Intel controller is a little unusual in
that it is mostly intended for use with SPI flash, and has some
optimisations and features specifically for that application. In
particular it is not possible to support ongoing transactions that
continue over many calls with SPI_XFER_BEGIN and SPI_XFER_END.

This driver supports writes of up to 64 bytes at a time, the limit
for the controller. Future work will improve this.

Signed-off-by: Bernie Thompson 
Signed-off-by: Duncan Laurie 
Signed-off-by: Bill Richardson 
Signed-off-by: Vadim Bendebury 
Signed-off-by: Gabe Black 
Signed-off-by: Simon Glass 
---
Changes in v2:
- Support both 33MHz and 20MHz operation in ich driver
- Replace while() loop with memcpy_to/fromio() in ich driver

 drivers/spi/Makefile |   1 +
 drivers/spi/ich.c| 750 +++
 drivers/spi/ich.h| 144 ++
 3 files changed, 895 insertions(+)
 create mode 100644 drivers/spi/ich.c
 create mode 100644 drivers/spi/ich.h

diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 45862ec..4268595 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -39,6 +39,7 @@ COBJS-$(CONFIG_CF_SPI) += cf_spi.o
 COBJS-$(CONFIG_CF_QSPI) += cf_qspi.o
 COBJS-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
 COBJS-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
+COBJS-$(CONFIG_ICH_SPI) +=  ich.o
 COBJS-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
 COBJS-$(CONFIG_MPC52XX_SPI) += mpc52xx_spi.o
 COBJS-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
new file mode 100644
index 000..9f8eab2
--- /dev/null
+++ b/drivers/spi/ich.c
@@ -0,0 +1,750 @@
+/*
+ * Copyright (c) 2011-12 The Chromium OS Authors.
+ *
+ * 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
+ *
+ * This file is derived from the flashrom project.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ich.h"
+
+#define SPI_OPCODE_WREN  0x06
+#define SPI_OPCODE_FAST_READ 0x0b
+
+struct ich_ctlr {
+   pci_dev_t dev;  /* PCI device number */
+   int ich_version;/* Controller version, 7 or 9 */
+   int ichspi_lock;
+   int locked;
+   uint8_t *opmenu;
+   int menubytes;
+   void *base; /* Base of register set */
+   uint16_t *preop;
+   uint16_t *optype;
+   uint32_t *addr;
+   uint8_t *data;
+   unsigned databytes;
+   uint8_t *status;
+   uint16_t *control;
+   uint32_t *bbar;
+   uint32_t *pr;   /* only for ich9 */
+   uint8_t *speed; /* pointer to speed control */
+   ulong max_speed;/* Maximum bus speed in MHz */
+};
+
+struct ich_ctlr ctlr;
+
+static inline struct ich_spi_slave *to_ich_spi(struct spi_slave *slave)
+{
+   return container_of(slave, struct ich_spi_slave, slave);
+}
+
+static unsigned int ich_reg(const void *addr)
+{
+   return (unsigned)(addr - ctlr.base) & 0x;
+}
+
+static u8 ich_readb(const void *addr)
+{
+   u8 value = readb(addr);
+
+   debug("read %2.2x from %4.4x\n", value, ich_reg(addr));
+
+   return value;
+}
+
+static u16 ich_readw(const void *addr)
+{
+   u16 value = readw(addr);
+
+   debug("read %4.4x from %4.4x\n", value, ich_reg(addr));
+
+   return value;
+}
+
+static u32 ich_readl(const void *addr)
+{
+   u32 value = readl(addr);
+
+   debug("read %8.8x from %4.4x\n", value, ich_reg(addr));
+
+   return value;
+}
+
+static void ich_writeb(u8 value, void *addr)
+{
+   writeb(value, addr);
+   debug("wrote %2.2x to %4.4x\n", value, ich_reg(addr));
+}
+
+static void ich_writew(u16 value, void *addr)
+{
+   writew(value, addr);
+   debug("wrote %4.4x to %4.4x\n", value, ich_reg(addr));
+}
+
+static void ich_writel(u32 value, void *addr)
+{
+   writel(value, addr);
+   debug("wrote %8.8x to %4.4x\n", value, ich_reg(addr));
+}
+
+static void write_reg(const void *value, void *dest, uint32_t size)
+{
+   memcpy_toio(dest, value, size);
+}
+
+static void read_reg(const void *src, void *value, uint32_t size)
+{
+   memcpy_fromio(value, src, size);
+}
+
+static void ich_set_bbar(struct ich_ctlr *ctlr, uint32_t minaddr)
+{
+   const uint32_t bbar_mask = 0x0000;
+   uint32_t ichspi_bbar;
+
+   minaddr &= b

[U-Boot] [PATCH v2 08/15] sf: Respect maximum SPI write size

[Simon Glass]

Some SPI flash controllers (e.g. Intel ICH) have a limit on the number of
bytes that can be in a write transaction. Support this by breaking the
writes into multiple transactions.

Signed-off-by: Simon Glass 
---
Changes in v2: None

 drivers/mtd/spi/spi_flash.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 17f3d3c..b82011d 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -87,6 +87,9 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32 
offset,
for (actual = 0; actual < len; actual += chunk_len) {
chunk_len = min(len - actual, page_size - byte_addr);
 
+   if (flash->spi->max_write_size)
+   chunk_len = min(chunk_len, flash->spi->max_write_size);
+
cmd[1] = page_addr >> 8;
cmd[2] = page_addr;
cmd[3] = byte_addr;
@@ -111,8 +114,11 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32 
offset,
if (ret)
break;
 
-   page_addr++;
-   byte_addr = 0;
+   byte_addr += chunk_len;
+   if (byte_addr == page_size) {
+   page_addr++;
+   byte_addr = 0;
+   }
}
 
debug("SF: program %s %zu bytes @ %#x\n",
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 07/15] spi: Add parameter for maximum write size

[Simon Glass]

Some SPI controllers (e.g. Intel ICH) have a limit on the number of SPI
bytes that can be written at a time. Add this as a parameter so that
clients of the SPI interface can respect this value.

Signed-off-by: Simon Glass 
---
Changes in v2: None

 include/spi.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/spi.h b/include/spi.h
index ebc9652..3fe2e1e 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -49,10 +49,13 @@
  *
  *   bus:  ID of the bus that the slave is attached to.
  *   cs:   ID of the chip select connected to the slave.
+ *   max_write_size:   If non-zero, the maximum number of bytes which can
+ * be written at once, excluding command bytes.
  */
 struct spi_slave {
unsigned intbus;
unsigned intcs;
+   unsigned int max_write_size;
 };
 
 /*---
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 09/15] x86: spi: Set maximum write size for ICH

[Simon Glass]

This SPI controller can only write 64 bytes at a time. Add this restriction
in so that 'sf write' works correct for blocks larger than 64 bytes.

Signed-off-by: Simon Glass 
---
Changes in v2: None

 drivers/spi/ich.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index 9f8eab2..15213d9 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -147,6 +147,11 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
return NULL;
}
 
+   /*
+* Yes this controller can only write a small number of bytes at
+* once! The limit is typically 64 bytes.
+*/
+   ich->slave.max_write_size = ctlr.databytes;
ich->speed = max_hz;
 
return &ich->slave;
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 15/15] sf: Use unsigned type for buffers

[Simon Glass]

The verify code is broken on archs with signed char. Fix it.

Signed-off-by: Simon Glass 
---
Changes in v2:
- Add new patch to use unsigned type for buffers in 'sf test'

 common/cmd_sf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index b175358..3f0d414 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -369,8 +369,8 @@ static void spi_test_next_stage(struct test_info *test)
  * @param vbuf Verification buffer
  * @return 0 if ok, -1 on error
  */
-static int spi_flash_test(struct spi_flash *flash, char *buf, ulong len,
-  ulong offset, char *vbuf)
+static int spi_flash_test(struct spi_flash *flash, uint8_t *buf, ulong len,
+  ulong offset, uint8_t *vbuf)
 {
struct test_info test;
int i;
@@ -431,9 +431,9 @@ static int do_spi_flash_test(int argc, char * const argv[])
 {
unsigned long offset;
unsigned long len;
-   char *buf = (char *)CONFIG_SYS_TEXT_BASE;
+   uint8_t *buf = (uint8_t *)CONFIG_SYS_TEXT_BASE;
char *endp;
-   char *vbuf;
+   uint8_t *vbuf;
int ret;
 
offset = simple_strtoul(argv[1], &endp, 16);
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 13/15] x86: Enable SPI flash support for coreboot

[Simon Glass]

Turn on SPI flash support and related commands.

Signed-off-by: Simon Glass 
---
Changes in v2: None

 include/configs/coreboot.h | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h
index 49f05de..4826756 100644
--- a/include/configs/coreboot.h
+++ b/include/configs/coreboot.h
@@ -257,10 +257,16 @@
 /*---
  * FLASH configuration
  */
+#define CONFIG_ICH_SPI
+#define CONFIG_SPI_FLASH
+#define CONFIG_SPI_FLASH_MACRONIX
+#define CONFIG_SPI_FLASH_WINBOND
+#define CONFIG_SPI_FLASH_GIGADEVICE
 #define CONFIG_SYS_NO_FLASH
-#undef CONFIG_FLASH_CFI_DRIVER
-#define CONFIG_SYS_MAX_FLASH_SECT  1
-#define CONFIG_SYS_MAX_FLASH_BANKS 1
+#define CONFIG_CMD_SF
+#define CONFIG_CMD_SF_TEST
+#define CONFIG_CMD_SPI
+#define CONFIG_SPI
 
 /*---
  * Environment configuration
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 01/15] fdt: Add fdtdec_get_addr_size() to read reg properties

[Simon Glass]

It is common to have a "reg = " property in the FDT.
Add a function to handle this, similar to the existing
fdtdec_get_addr();

Signed-off-by: Simon Glass 
---
Changes in v2: None

 include/fdtdec.h | 15 +++
 lib/fdtdec.c | 26 +-
 2 files changed, 36 insertions(+), 5 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 77f244f..d86dbe2 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -38,11 +38,13 @@
  */
 #ifdef CONFIG_PHYS_64BIT
 typedef u64 fdt_addr_t;
+typedef u64 fdt_size_t;
 #define FDT_ADDR_T_NONE (-1ULL)
 #define fdt_addr_to_cpu(reg) be64_to_cpu(reg)
 #define fdt_size_to_cpu(reg) be64_to_cpu(reg)
 #else
 typedef u32 fdt_addr_t;
+typedef u32 fdt_size_t;
 #define FDT_ADDR_T_NONE (-1U)
 #define fdt_addr_to_cpu(reg) be32_to_cpu(reg)
 #define fdt_size_to_cpu(reg) be32_to_cpu(reg)
@@ -197,6 +199,19 @@ fdt_addr_t fdtdec_get_addr(const void *blob, int node,
const char *prop_name);
 
 /**
+ * Look up an address property in a node and return it as an address.
+ * The property must hold one address with a length. This is only tested
+ * on 32-bit machines.
+ *
+ * @param blob FDT blob
+ * @param node node to examine
+ * @param prop_namename of property to find
+ * @return address, if found, or FDT_ADDR_T_NONE if not
+ */
+fdt_addr_t fdtdec_get_addr_size(const void *blob, int node,
+   const char *prop_name, fdt_size_t *sizep);
+
+/**
  * Look up a 32-bit integer property in a node and return it. The property
  * must have at least 4 bytes of data. The value of the first cell is
  * returned.
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 3ae348d..e99a4b9 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -65,25 +65,41 @@ const char *fdtdec_get_compatible(enum fdt_compat_id id)
return compat_names[id];
 }
 
-fdt_addr_t fdtdec_get_addr(const void *blob, int node,
-   const char *prop_name)
+fdt_addr_t fdtdec_get_addr_size(const void *blob, int node,
+   const char *prop_name, fdt_size_t *sizep)
 {
const fdt_addr_t *cell;
int len;
 
debug("%s: %s: ", __func__, prop_name);
cell = fdt_getprop(blob, node, prop_name, &len);
-   if (cell && (len == sizeof(fdt_addr_t) ||
+   if (cell && ((!sizep && len == sizeof(fdt_addr_t)) ||
len == sizeof(fdt_addr_t) * 2)) {
-   fdt_addr_t addr = fdt_addr_to_cpu(*cell);
 
-   debug("%p\n", (void *)addr);
+   fdt_addr_t addr = fdt_addr_to_cpu(*cell);
+   if (sizep) {
+   const fdt_size_t *size;
+
+   size = (fdt_size_t *)((char *)cell +
+   sizeof(fdt_addr_t));
+   *sizep = fdt_size_to_cpu(*size);
+   debug("addr=%p, size=%p\n", (void *)addr,
+ (void *)*sizep);
+   } else {
+   debug("%p\n", (void *)addr);
+   }
return addr;
}
debug("(not found)\n");
return FDT_ADDR_T_NONE;
 }
 
+fdt_addr_t fdtdec_get_addr(const void *blob, int node,
+   const char *prop_name)
+{
+   return fdtdec_get_addr_size(blob, node, prop_name, NULL);
+}
+
 s32 fdtdec_get_int(const void *blob, int node, const char *prop_name,
s32 default_val)
 {
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 10/15] sf: Enable FDT-based configuration and memory mapping

[Simon Glass]

Enable device tree control of SPI flash, and use this to implement
memory-mapped SPI flash, which is supported on Intel chips.

Signed-off-by: Simon Glass 
---
Changes in v2: None

 drivers/mtd/spi/spi_flash.c | 46 -
 include/fdtdec.h|  1 +
 include/spi_flash.h |  1 +
 lib/fdtdec.c|  1 +
 4 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index b82011d..85a 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -15,6 +16,8 @@
 
 #include "spi_flash_internal.h"
 
+DECLARE_GLOBAL_DATA_PTR;
+
 static void spi_flash_addr(u32 addr, u8 *cmd)
 {
/* cmd[0] is actual command */
@@ -146,6 +149,10 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, u32 
offset,
 {
u8 cmd[5];
 
+   /* Handle memory-mapped SPI */
+   if (flash->memory_map)
+   memcpy(data, flash->memory_map + offset, len);
+
cmd[0] = CMD_READ_ARRAY_FAST;
spi_flash_addr(offset, cmd);
cmd[4] = 0x00;
@@ -275,6 +282,34 @@ int spi_flash_cmd_write_status(struct spi_flash *flash, u8 
sr)
return 0;
 }
 
+#ifdef CONFIG_OF_CONTROL
+int spi_flash_decode_fdt(const void *blob, struct spi_flash *flash)
+{
+   fdt_addr_t addr;
+   fdt_size_t size;
+   int node;
+
+   /* If there is no node, do nothing */
+   node = fdtdec_next_compatible(blob, 0, COMPAT_GENERIC_SPI_FLASH);
+   if (node < 0)
+   return 0;
+
+   addr = fdtdec_get_addr_size(blob, node, "memory-map", &size);
+   if (addr == FDT_ADDR_T_NONE) {
+   debug("%s: Cannot decode address\n", __func__);
+   return 0;
+   }
+
+   if (flash->size != size) {
+   debug("%s: Memory map must cover entire device\n", __func__);
+   return -1;
+   }
+   flash->memory_map = (void *)addr;
+
+   return 0;
+}
+#endif /* CONFIG_OF_CONTROL */
+
 /*
  * The following table holds all device probe functions
  *
@@ -391,9 +426,18 @@ struct spi_flash *spi_flash_probe(unsigned int bus, 
unsigned int cs,
goto err_manufacturer_probe;
}
 
+#ifdef CONFIG_OF_CONTROL
+   if (spi_flash_decode_fdt(gd->fdt_blob, flash)) {
+   debug("SF: FDT decode error\n");
+   goto err_manufacturer_probe;
+   }
+#endif
printf("SF: Detected %s with page size ", flash->name);
print_size(flash->sector_size, ", total ");
-   print_size(flash->size, "\n");
+   print_size(flash->size, "");
+   if (flash->memory_map)
+   printf(", mapped at %p", flash->memory_map);
+   puts("\n");
 
spi_release_bus(spi);
 
diff --git a/include/fdtdec.h b/include/fdtdec.h
index d86dbe2..a46e51c 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -83,6 +83,7 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS_EHCI, /* Exynos EHCI controller */
COMPAT_SAMSUNG_EXYNOS_USB_PHY,  /* Exynos phy controller for usb2.0 */
COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
+   COMPAT_GENERIC_SPI_FLASH,   /* Generic SPI Flash chip */
 
COMPAT_COUNT,
 };
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 030d49c..3b6a44e 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -39,6 +39,7 @@ struct spi_flash {
/* Erase (sector) size */
u32 sector_size;
 
+   void *memory_map;   /* Address of read-only SPI flash access */
int (*read)(struct spi_flash *flash, u32 offset,
size_t len, void *buf);
int (*write)(struct spi_flash *flash, u32 offset,
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index e99a4b9..2145354 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -56,6 +56,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS_EHCI, "samsung,exynos-ehci"),
COMPAT(SAMSUNG_EXYNOS_USB_PHY, "samsung,exynos-usb-phy"),
COMPAT(MAXIM_MAX77686_PMIC, "maxim,max77686_pmic"),
+   COMPAT(GENERIC_SPI_FLASH, "spi-flash"),
 };
 
 const char *fdtdec_get_compatible(enum fdt_compat_id id)
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] USB patches

[Simon Glass]

Hi Marek,

As requested here is an email about the USB patches. I have put them in a
bundle here:

http://patchwork.ozlabs.org/bundle/sjg/for-marex/

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v8 13/31] arm: Enable generic board support

[Simon Glass]

Hi Tom,


On Sun, Mar 10, 2013 at 6:27 AM, Tom Rini  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/09/2013 01:30 PM, Simon Glass wrote:
> > Hi Otavio,
> >
> > On Sat, Mar 9, 2013 at 4:31 AM, Otavio Salvador
> > mailto:ota...@ossystems.com.br>> wrote:
> >
> > On Fri, Mar 8, 2013 at 8:45 PM, Simon Glass  > > wrote:
> >> This enables generic board support so that ARM boards can define
> >> CONFIG_SYS_GENERIC_BOARD.
> >>
> >> Signed-off-by: Simon Glass  > >
> >> --- Changes in v8: - Define __HAVE_ARCH_GENERIC_BOARD in ARM's
> >> config.mk
> > 
> >>
> >> Changes in v7: None Changes in v6: None Changes in v5: None
> >> Changes in v4: None Changes in v3: None Changes in v2: None
> >>
> >> arch/arm/config.mk | 3 +++
> >> arch/arm/include/asm/u-boot.h | 9 + arch/arm/lib/Makefile
> >> | 3 +++ 3 files changed, 15 insertions(+)
> >>
> >> diff --git a/arch/arm/config.mk 
> > b/arch/arm/config.mk 
> >> index 24b9d7c..a0c89b7 100644 --- a/arch/arm/config.mk
> >>  +++ b/arch/arm/config.mk  @@
> >> -31,6 +31,9 @@ CONFIG_STANDALONE_LOAD_ADDR = 0xc10 endif
> >> endif
> >>
> >> +# Support generic board on ARM +__HAVE_ARCH_GENERIC_BOARD := y
> >> + PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__
> >>
> >> # Choose between ARM/Thumb instruction sets diff --git
> >> a/arch/arm/include/asm/u-boot.h
> > b/arch/arm/include/asm/u-boot.h
> >> index 2ba98bc..8e7e27b 100644 ---
> >> a/arch/arm/include/asm/u-boot.h +++
> >> b/arch/arm/include/asm/u-boot.h @@ -36,6 +36,12 @@ #ifndef
> >> _U_BOOT_H_ #define _U_BOOT_H_ 1
> >>
> >> +#ifdef CONFIG_SYS_GENERIC_BOARD +/* Use the generic board which
> >> requires a unified bd_info */ +#include 
> >> +#else + +#ifndef __ASSEMBLY__ typedef struct bd_info { unsigned
> >> intbi_baudrate;/* serial console baudrate */ ulong
> >> bi_arch_number; /* unique id for this board */ @@ -49,6 +55,9 @@
> >> typedef struct bd_info { ulong size; }
> >> bi_dram[CONFIG_NR_DRAM_BANKS]; } bd_t; +#endif + +#endif /*
> >> nCONFIG_SYS_GENERIC_BOARD */
> >
> > Typo?
> >
> >
> > The 'n' is intended to mean 'not'. Perhaps I should use ! instead?
>
> !CONFIG is the style of the rest of the codebase.  Thanks.
>

OK, I will resend the affected patch(es).

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] fdt: Ensure that libfdt_env.h comes from U-Boot

[Simon Glass]

When building host utilities, we include libfdt.h from the host, not from
U-Boot. This in turn brings in libfdt_env.h from the host, which can mess
up the types and cause a build failure, depending on the host environment.
To fix this, force inclusion of U-Boot's libfdt_env.h so that the types
are correct.

Another way to fix this is to use -nostdinc and -idirafter to ensure that
system includes are included after U-Boot ones. Unfortunately this means
that U-Boot's errno.h gets included instead of the system one. This in
turn requires a hack to errno.h to redirect things, so all in all the
solution in this patch is probably cleaner.

Signed-off-by: Simon Glass 
---
 tools/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index c5952fc..889c897 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -164,7 +164,8 @@ NOPEDOBJS := $(addprefix $(obj),$(NOPED_OBJ_FILES-y))
 # Use native tools and options
 # Define __KERNEL_STRICT_NAMES to prevent typedef overlaps
 #
-HOSTCPPFLAGS = -idirafter $(SRCTREE)/include \
+HOSTCPPFLAGS = -include $(SRCTREE)/include/libfdt_env.h \
+   -idirafter $(SRCTREE)/include \
-idirafter $(OBJTREE)/include2 \
-idirafter $(OBJTREE)/include \
-I $(SRCTREE)/lib/libfdt \
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V7 01/10] FDT: Add compatible string for DWMMC

[Simon Glass]

Hi Amar,

On Tue, Mar 5, 2013 at 5:11 AM, Amar  wrote:

> Add required compatible information for DWMMC driver.
>
> Signed-off-by: Vivek Gautam 
> Signed-off-by: Amar 
> Acked-by: Jaehoon Chung 
> ---
> Changes since V1:
> No change.
>
> Changes since V2:
> 1)Updation of commit message and resubmition of proper patch set.
>
> Changes since V3:
> No change.
>
> Changes since V4:
> No change.
>
> Changes since V5:
> No change.
>
>  include/fdtdec.h | 1 +
>  lib/fdtdec.c | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 77f244f..51ff266 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -81,6 +81,7 @@ enum fdt_compat_id {
> COMPAT_SAMSUNG_EXYNOS_EHCI, /* Exynos EHCI controller */
> COMPAT_SAMSUNG_EXYNOS_USB_PHY,  /* Exynos phy controller for
> usb2.0 */
> COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
> +   COMPAT_SAMSUNG_EXYNOS5_DWMMC,   /* Exynos5 DWMMC controller */
>
> COMPAT_COUNT,
>  };
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index 3ae348d..856f90c 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -56,6 +56,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
> COMPAT(SAMSUNG_EXYNOS_EHCI, "samsung,exynos-ehci"),
> COMPAT(SAMSUNG_EXYNOS_USB_PHY, "samsung,exynos-usb-phy"),
> COMPAT(MAXIM_MAX77686_PMIC, "maxim,max77686_pmic"),
> +   COMPAT(SAMSUNG_EXYNOS5_DWMMC, "samsung,exynos5250-dwmmc"),
>  };
>
>  const char *fdtdec_get_compatible(enum fdt_compat_id id)
>

Will you be resending this series?

Regards,
Simon


> --
> 1.8.0
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mtd: nand: fix the written length when nand_write_skip_bad failed

[Scott Wood]

On 03/09/2013 07:06:54 PM, htbegin wrote:

Hi, Scott

On Fri, Mar 8, 2013 at 6:27 AM, Scott Wood   
wrote:


>> >> I just use "*length -= left_to_write - written_size" to tell  
the upper

>> >> level that what
>> >> had been actually happened. For the current block,  
"written_size" has

>> >> been written to the NAND Flash yet, so left_to_write should be
>> >> subtracted by "written_size".
>> >
>> >
>> > But left_to_write isn't decreased until after this error return,  
so

>> > that's
>> > already the case.  Subtracting written_size from left_to_write  
has the
>> > effect of increasing length by written_size, so the return value  
will

>> > now
>> > look like the error page has been written.
>> >
>> > -Scott
>> No, the returned value doesn't include the length of the error  
page.

>> In no-WITH_YAFFS_OOB case,  when nand_write failed,
>> truncated_write_size has been
>> updated by nand_write to the length which has been successfully
>> written , so it's OK to subtract written_size from left_to_write.
>
>
> OK, but that doesn't explain why the change is needed.  You said  
you wanted
> to find the block with the error.  We only write one block at a  
time in the
> loop.  Why do you need the specific page within the block that  
failed?

>
> -Scott

Yes, you are right it's OK to ignore the written length of the
write-failed block, but as I said before I just wanted to tell the
upper level what had been actually written. So if you insist the
subtraction of written_len is unnecessary, it's alright with me.


Thanks.  I do insist -- it adds complexity.

-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards

[Wolfgang Denk]

Dear Eric,

In message <513dde22.4090...@boundarydevices.com> you wrote:
> 
> Would it help if we restrict the number of boards directly in
> boards.cfg?

Not really.  Thi sjust papers over the problem, but does not solve it.

> We'll be happy to pursue the SPL route, but this won't be
> something that we can devote cycles to in the next few weeks.

Understood.  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
"It is easier to port a shell than a shell script."  - Larry Wall
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v9 09/31] Introduce generic pre-relocation board_f.c

[Simon Glass]

This file handles common pre-relocation init for boards which use
the generic framework.

It starts up the console, DRAM, performs relocation and then jumps
to post-relocation init.

Signed-off-by: Simon Glass 
---
Changes in v9:
- Rebase x86 global_data patch on top of mainline

Changes in v8: None
Changes in v7: None
Changes in v6:
- Tidy up stack reservation code to separate out ARM
- Fix up ordering of dram init (specifically to get ARM SPL boards to boot)
- Add debug() to show RAM top
- Adjust the way the top of memory is calculated

Changes in v5:
- Add fdtdec header file to board_f.c
- Remove setup_global_data_ptr()
- Tidy up stack init
- Put global data on stack in board_init_f()
- Add fdt relocation
- Remove fdt relocation field from x86 arch_global_data
- Deal with change of board_init_f() semantics on ARM
- Save boot_flags in global_data in board_init_f()
- Add print_cpuinfo() prototype to include/common.h

Changes in v4:
- Use asm/sections.h instead of asm-generic/sections.h

Changes in v3:
- Cast away the volatile on gd for memcpy()

Changes in v2: None

 arch/x86/lib/board.c  |   2 +-
 arch/x86/lib/init_helpers.c   |   2 +-
 arch/x86/lib/relocate.c   |   8 +-
 common/Makefile   |   3 +
 common/board_f.c  | 579 ++
 include/asm-generic/global_data.h |   2 +
 include/common.h  |   1 +
 7 files changed, 591 insertions(+), 6 deletions(-)
 create mode 100644 common/board_f.c

diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index 2441a66..555301a 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
@@ -219,7 +219,7 @@ static void do_init_loop(init_fnc_t **init_fnc_ptr)
 
 void board_init_f(ulong boot_flags)
 {
-   gd->fdt_blob = gd->arch.new_fdt = NULL;
+   gd->fdt_blob = gd->new_fdt = NULL;
gd->flags = boot_flags;
 
do_init_loop(init_sequence_f);
diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c
index 414fdcc..7df9536 100644
--- a/arch/x86/lib/init_helpers.c
+++ b/arch/x86/lib/init_helpers.c
@@ -111,7 +111,7 @@ int calculate_relocation_address(void)
 */
if (gd->fdt_blob) {
dest_addr -= fdt_size;
-   gd->arch.new_fdt = (void *)dest_addr;
+   gd->new_fdt = (void *)dest_addr;
dest_addr &= ~15;
}
 #endif
diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c
index 3e370f2..e893c2b 100644
--- a/arch/x86/lib/relocate.c
+++ b/arch/x86/lib/relocate.c
@@ -49,15 +49,15 @@ int copy_uboot_to_ram(void)
 
 int copy_fdt_to_ram(void)
 {
-   if (gd->arch.new_fdt) {
+   if (gd->new_fdt) {
ulong fdt_size;
 
fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32);
 
-   memcpy(gd->arch.new_fdt, gd->fdt_blob, fdt_size);
+   memcpy(gd->new_fdt, gd->fdt_blob, fdt_size);
debug("Relocated fdt from %p to %p, size %lx\n",
-  gd->fdt_blob, gd->arch.new_fdt, fdt_size);
-   gd->fdt_blob = gd->arch.new_fdt;
+  gd->fdt_blob, gd->new_fdt, fdt_size);
+   gd->fdt_blob = gd->new_fdt;
}
 
return 0;
diff --git a/common/Makefile b/common/Makefile
index 719fc23..a5f5b1a 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -36,6 +36,9 @@ COBJS-y += s_record.o
 COBJS-y += xyzModem.o
 COBJS-y += cmd_disk.o
 
+# boards
+COBJS-$(CONFIG_SYS_GENERIC_BOARD) += board_f.o
+
 # core command
 COBJS-y += cmd_boot.o
 COBJS-$(CONFIG_CMD_BOOTM) += cmd_bootm.o
diff --git a/common/board_f.c b/common/board_f.c
new file mode 100644
index 000..d674f9d
--- /dev/null
+++ b/common/board_f.c
@@ -0,0 +1,579 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * (C) Copyright 2002-2006
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH 
+ * Marius Groeger 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Pointer to initial global data area
+ *
+ * Here we initialize it if needed.
+ */
+#

[U-Boot] [PATCH v9 13/31] arm: Enable generic board support

[Simon Glass]

This enables generic board support so that ARM boards can define
CONFIG_SYS_GENERIC_BOARD.

Signed-off-by: Simon Glass 
---
Changes in v9:
- Use !CONFIG instead of nCONFIG

Changes in v8:
- Define __HAVE_ARCH_GENERIC_BOARD in ARM's config.mk

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/config.mk| 3 +++
 arch/arm/include/asm/u-boot.h | 9 +
 arch/arm/lib/Makefile | 3 +++
 3 files changed, 15 insertions(+)

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 24b9d7c..a0c89b7 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -31,6 +31,9 @@ CONFIG_STANDALONE_LOAD_ADDR = 0xc10
 endif
 endif
 
+# Support generic board on ARM
+__HAVE_ARCH_GENERIC_BOARD := y
+
 PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__
 
 # Choose between ARM/Thumb instruction sets
diff --git a/arch/arm/include/asm/u-boot.h b/arch/arm/include/asm/u-boot.h
index 2ba98bc..a33fefa 100644
--- a/arch/arm/include/asm/u-boot.h
+++ b/arch/arm/include/asm/u-boot.h
@@ -36,6 +36,12 @@
 #ifndef _U_BOOT_H_
 #define _U_BOOT_H_ 1
 
+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified bd_info */
+#include 
+#else
+
+#ifndef __ASSEMBLY__
 typedef struct bd_info {
unsigned intbi_baudrate;/* serial console baudrate */
 ulong  bi_arch_number; /* unique id for this board */
@@ -49,6 +55,9 @@ typedef struct bd_info {
ulong size;
 }  bi_dram[CONFIG_NR_DRAM_BANKS];
 } bd_t;
+#endif
+
+#endif /* !CONFIG_SYS_GENERIC_BOARD */
 
 /* For image.h:image_check_target_arch() */
 #define IH_ARCH_DEFAULT IH_ARCH_ARM
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 57111af..24c7e7a 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -39,7 +39,10 @@ GLCOBJS  += div0.o
 SOBJS-y += crt0.o
 
 ifndef CONFIG_SPL_BUILD
+ifndef CONFIG_SYS_GENERIC_BOARD
 COBJS-y+= board.o
+endif
+
 COBJS-y+= bootm.o
 COBJS-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
 SOBJS-$(CONFIG_USE_ARCH_MEMSET) += memset.o
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v9 17/31] ppc: Enable generic board support

[Simon Glass]

This enables generic board support so that ppc boards can define
CONFIG_SYS_GENERIC_BOARD.

Signed-off-by: Simon Glass 
---
Changes in v9:
- Use !CONFIG instead of nCONFIG

Changes in v8:
- Define __HAVE_ARCH_GENERIC_BOARD in PPC's config.mk

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/powerpc/config.mk| 3 +++
 arch/powerpc/include/asm/u-boot.h | 7 +++
 arch/powerpc/lib/Makefile | 2 ++
 3 files changed, 12 insertions(+)

diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
index b706281..e32d2bf 100644
--- a/arch/powerpc/config.mk
+++ b/arch/powerpc/config.mk
@@ -29,6 +29,9 @@ PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections 
-fdata-sections
 PLATFORM_CPPFLAGS += -DCONFIG_PPC -D__powerpc__
 PLATFORM_LDFLAGS  += -n
 
+# Support generic board on PPC
+__HAVE_ARCH_GENERIC_BOARD := y
+
 #
 # When cross-compiling on NetBSD, we have to define __PPC__ or else we
 # will pick up a va_list declaration that is incompatible with the
diff --git a/arch/powerpc/include/asm/u-boot.h 
b/arch/powerpc/include/asm/u-boot.h
index 7229a98..cf972d2 100644
--- a/arch/powerpc/include/asm/u-boot.h
+++ b/arch/powerpc/include/asm/u-boot.h
@@ -34,6 +34,11 @@
  * include/asm-ppc/u-boot.h
  */
 
+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified bd_info */
+#include 
+#else
+
 #ifndef __ASSEMBLY__
 
 typedef struct bd_info {
@@ -144,6 +149,8 @@ typedef struct bd_info {
 
 #endif /* __ASSEMBLY__ */
 
+#endif /* !CONFIG_SYS_GENERIC_BOARD */
+
 /* For image.h:image_check_target_arch() */
 #define IH_ARCH_DEFAULT IH_ARCH_PPC
 
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 86cf02a..59c723b 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -59,8 +59,10 @@ SOBJS-y  += reloc.o
 
 COBJS-$(CONFIG_BAT_RW) += bat_rw.o
 ifndef CONFIG_SPL_BUILD
+ifndef CONFIG_SYS_GENERIC_BOARD
 COBJS-y+= board.o
 endif
+endif
 COBJS-y+= bootm.o
 COBJS-y+= cache.o
 COBJS-y+= extable.o
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v9 21/31] x86: Enable generic board support

[Simon Glass]

This enables generic board support so that x86 boards can define
CONFIG_SYS_GENERIC_BOARD.

Signed-off-by: Simon Glass 
---
Changes in v9:
- Use !CONFIG instead of nCONFIG

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Avoid setting up gd on x86 as it is already done

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/x86/include/asm/u-boot.h | 11 +++
 arch/x86/lib/Makefile |  3 +++
 common/board_r.c  |  2 ++
 3 files changed, 16 insertions(+)

diff --git a/arch/x86/include/asm/u-boot.h b/arch/x86/include/asm/u-boot.h
index 2f45c7b..df759fa 100644
--- a/arch/x86/include/asm/u-boot.h
+++ b/arch/x86/include/asm/u-boot.h
@@ -39,6 +39,13 @@
 #include 
 #include 
 
+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified bd_info */
+#include 
+#else
+
+#ifndef __ASSEMBLY__
+
 typedef struct bd_info {
unsigned long   bi_memstart;/* start of DRAM memory */
phys_size_t bi_memsize; /* size  of DRAM memory in bytes */
@@ -60,6 +67,10 @@ typedef struct bd_info {
}bi_dram[CONFIG_NR_DRAM_BANKS];
 } bd_t;
 
+#endif /* __ASSEMBLY__ */
+
+#endif /* !CONFIG_SYS_GENERIC_BOARD */
+
 /* For image.h:image_check_target_arch() */
 #define IH_ARCH_DEFAULT IH_ARCH_I386
 
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 9b24dc5..ee89354 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -25,7 +25,10 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)lib$(ARCH).o
 
+ifeq ($(CONFIG_SYS_GENERIC_BOARD),)
 COBJS-y+= board.o
+endif
+
 COBJS-y+= bootm.o
 COBJS-y+= cmd_boot.o
 COBJS-y+= gcc.o
diff --git a/common/board_r.c b/common/board_r.c
index 29eccdf..230887d 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -509,11 +509,13 @@ static int show_model_r(void)
 #endif
 
 /* enable exceptions */
+#ifdef CONFIG_ARM
 static int initr_enable_interrupts(void)
 {
enable_interrupts();
return 0;
 }
+#endif
 
 #ifdef CONFIG_CMD_NET
 static int initr_ethaddr(void)
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v9 14/31] Add CONFIG_SYS_SYM_OFFSETS to support offset symbols

[Simon Glass]

Link symbols as created by the link script can either be absolute or
relative to the text start. This option switches between the two options
so that we can support both.

As we convert architectures over to generic board, we can see if this
option is actually needed, or whether it is possible to unify this feature
also.

Signed-off-by: Simon Glass 
---
Changes in v9:
- Rebase to master

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Add offsets support for access to fdt that uses CONFIG_OF_SEPARATE

Changes in v4: None
Changes in v3: None
Changes in v2: None

 README   |  7 +++
 common/board_f.c | 14 ++
 2 files changed, 21 insertions(+)

diff --git a/README b/README
index 2c36e00..a106aaf 100644
--- a/README
+++ b/README
@@ -3221,6 +3221,13 @@ Configuration Settings:
its config.mk file). If you find problems enabling this option on
your board please report the problem and send patches!
 
+- CONFIG_SYS_SYM_OFFSETS
+   This is set by architectures that use offsets for link symbols
+   instead of absolute values. So bss_start is obtained using an
+   offset _bss_start_ofs from CONFIG_SYS_TEXT_BASE, rather than
+   directly. You should not need to touch this setting.
+
+
 The following definitions that deal with the placement and management
 of environment data (variable area); in general, we support the
 following configurations:
diff --git a/common/board_f.c b/common/board_f.c
index 42042cc..b625ccb 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -107,8 +107,13 @@ static int display_text_info(void)
 {
ulong bss_start, bss_end;
 
+#ifdef CONFIG_SYS_SYM_OFFSETS
bss_start = _bss_start_ofs + _TEXT_BASE;
bss_end = _bss_end_ofs + _TEXT_BASE;
+#else
+   bss_start = (ulong)&__bss_start;
+   bss_end = (ulong)&__bss_end;
+#endif
debug("U-Boot code: %08X -> %08lX  BSS: -> %08lX\n",
  CONFIG_SYS_TEXT_BASE, bss_start, bss_end);
 
@@ -174,7 +179,11 @@ static int zero_global_data(void)
 
 static int setup_mon_len(void)
 {
+#ifdef CONFIG_SYS_SYM_OFFSETS
gd->mon_len = _bss_end_ofs;
+#else
+   gd->mon_len = (ulong)&__bss_end - (ulong)&__text_start;
+#endif
return 0;
 }
 
@@ -190,7 +199,11 @@ static int setup_fdt(void)
gd->fdt_blob = _binary_dt_dtb_start;
 #elif defined CONFIG_OF_SEPARATE
/* FDT is at end of image */
+# ifdef CONFIG_SYS_SYM_OFFSETS
gd->fdt_blob = (void *)(_end_ofs + CONFIG_SYS_TEXT_BASE);
+# else
+   gd->fdt_blob = (ulong *)&_end;
+# endif
 #endif
/* Allow the early environment to override the fdt address */
gd->fdt_blob = (void *)getenv_ulong("fdtcontroladdr", 16,
@@ -483,6 +496,7 @@ static int mark_bootstage(void)
 }
 
 static init_fnc_t init_sequence_f[] = {
+   zero_global_data,
setup_fdt,
setup_mon_len,
arch_cpu_init,  /* basic arch cpu dependent setup */
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1] DOS_PBR block type is also valid dos block type.

[Stephen Warren]

On 03/11/2013 03:56 AM, sonic@gmail.com wrote:
> From: Sonic Zhang 
> 
> - Should return 0 for both DOS_MBR and DOS_PBR block types in test_part_dos().

What problem does this solve?

I don't believe this change is correct. The purpose of test_part_dos()
is to determine whether a block device contains an MS-DOS partition table.

Such a partition table is present in an MBR, but not a PBR. A PBR
contains a *FAT file-system, and does not include a partition table.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v6 21/31] x86: Enable generic board support

[Simon Glass]

Hi,

On Tue, Mar 5, 2013 at 4:39 PM, Simon Glass  wrote:

> This enables generic board support so that x86 boards can define
> CONFIG_SYS_GENERIC_BOARD.
>
> Signed-off-by: Simon Glass 
> ---
> Changes in v6: None
> Changes in v5:
> - Avoid setting up gd on x86 as it is already done
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/config.mk|  3 ---
>  arch/x86/include/asm/u-boot.h | 11 +++
>  arch/x86/lib/Makefile |  3 +++
>  common/board_r.c  |  2 ++
>  4 files changed, 16 insertions(+), 3 deletions(-)
>

Unfortunately this patch is missing the __HAVE_ARCH_GENERIC_BOARD change,
so I will resend it as v9.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v10 21/31] x86: Enable generic board support

[Simon Glass]

This enables generic board support so that x86 boards can define
CONFIG_SYS_GENERIC_BOARD.

Signed-off-by: Simon Glass 
---
Changes in v10:
- Define __HAVE_ARCH_GENERIC_BOARD in the correct x86 patch

Changes in v9:
- Use !CONFIG instead of nCONFIG

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Avoid setting up gd on x86 as it is already done

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/x86/config.mk|  3 +++
 arch/x86/include/asm/u-boot.h | 11 +++
 arch/x86/lib/Makefile |  3 +++
 common/board_r.c  |  2 ++
 4 files changed, 19 insertions(+)

diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index 23cacff..168dc24 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -36,6 +36,9 @@ PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_X86)
 PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm
 PLATFORM_CPPFLAGS += -DREALMODE_BASE=0x7c0
 
+# Support generic board on x86
+__HAVE_ARCH_GENERIC_BOARD := y
+
 PLATFORM_RELFLAGS += -ffunction-sections -fvisibility=hidden
 
 PLATFORM_LDFLAGS += --emit-relocs -Bsymbolic -Bsymbolic-functions
diff --git a/arch/x86/include/asm/u-boot.h b/arch/x86/include/asm/u-boot.h
index 2f45c7b..df759fa 100644
--- a/arch/x86/include/asm/u-boot.h
+++ b/arch/x86/include/asm/u-boot.h
@@ -39,6 +39,13 @@
 #include 
 #include 
 
+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified bd_info */
+#include 
+#else
+
+#ifndef __ASSEMBLY__
+
 typedef struct bd_info {
unsigned long   bi_memstart;/* start of DRAM memory */
phys_size_t bi_memsize; /* size  of DRAM memory in bytes */
@@ -60,6 +67,10 @@ typedef struct bd_info {
}bi_dram[CONFIG_NR_DRAM_BANKS];
 } bd_t;
 
+#endif /* __ASSEMBLY__ */
+
+#endif /* !CONFIG_SYS_GENERIC_BOARD */
+
 /* For image.h:image_check_target_arch() */
 #define IH_ARCH_DEFAULT IH_ARCH_I386
 
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 9b24dc5..ee89354 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -25,7 +25,10 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)lib$(ARCH).o
 
+ifeq ($(CONFIG_SYS_GENERIC_BOARD),)
 COBJS-y+= board.o
+endif
+
 COBJS-y+= bootm.o
 COBJS-y+= cmd_boot.o
 COBJS-y+= gcc.o
diff --git a/common/board_r.c b/common/board_r.c
index 29eccdf..230887d 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -509,11 +509,13 @@ static int show_model_r(void)
 #endif
 
 /* enable exceptions */
+#ifdef CONFIG_ARM
 static int initr_enable_interrupts(void)
 {
enable_interrupts();
return 0;
 }
+#endif
 
 #ifdef CONFIG_CMD_NET
 static int initr_ethaddr(void)
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-ti/master

[Tom Rini]

Hello,

The following changes since commit fc959081d41aab2d6f4614c5fb3dd1b77ffcdcf4:

  x86: Enable CONFIG_OF_CONTROL on coreboot (2013-03-04 15:57:52 -0800)

are available in the git repository at:

  git://git.denx.de/u-boot-ti.git master

for you to fetch changes up to 76b40ab41eff1f402ee52ba768b09daad293b9bb:

  Merge u-boot/master into u-boot-ti/master (2013-03-11 12:16:13 -0400)



Enric Balletbo i Serra (4):
  SPL: ONENAND: Fix some ONENAND related defines.
  SPL: ONENAND: Fix onenand_spl_load_image implementation.
  SPL: ONENAND: Support SPL to boot u-boot from OneNAND.
  OMAP3: Initialize gpmc if SPL_ONENAND_SUPPORT is enabled.

Lokesh Vutla (13):
  ARM: OMAP4+: emif: Detect SDRAM from SDRAM config register
  ARM: OMAP4+: Cleanup emif specific files
  ARM: OMAP4+: Make control module register structure generic
  ARM: OMAP5: Clean up iosettings code
  ARM: OMAP5: Add DDR changes required for OMAP543X ES2.0 SOCs
  ARM: OMAP5: srcomp: enable slew rate compensation cells after powerup
  arm: dra7xx: clock: Add the prcm changes
  arm: dra7xx: clock: Add the dplls data
  arm: dra7xx: Add control module changes
  arm: dra7xx: Add DDR related data for DRA752 ES1.0
  arm: dra7xx: Add board files for DRA7XX socs
  arm: dra7xx: Add dra7xx_evm build support
  arm: dra7xx: Add silicon id support for DRA752 soc

Mark Jackson (1):
  Allow AM33xx boards to setup GPMC chipselects.

Mugunthan V N (1):
  am335x: cpsw: optimize cpsw_send to increase network performance

Nikita Kiryanov (14):
  omap: consolidate common mmc definitions
  omap_hsmmc: fix out of bounds array access
  omap_hsmmc: introduce omap_hsmmc_data struct
  omap_hsmmc: implement driver check for card detection
  cm-t35: implement board specific card detect check
  mmc: add support for write protection
  omap_hsmmc: add driver check for write protection
  omap3: add useful dss defines
  omap3: allow dynamic selection of gfx_format
  lcd: add option for board specific splash screen preparation
  cm-t35: add support for dvi displays
  cm-t35: add support for user defined lcd parameters
  lcd: implement a callback for splashimage
  cm_t35: prevent splashimage from being set to a bad value

SRICHARAN R (6):
  ARM: OMAP4+: Change the PRCM structure prototype common for all Socs
  ARM: OMAP4+: Cleanup the clocks layer
  ARM: OMAP4+: Clean up the pmic code
  ARM: OMAP5: Add silicon id support for ES2.0 revision.
  ARM: OMAP5: clock: Add the prcm register changes required for ES2.0
  ARM: OMAP4/5: clocks: Add the required OPP settings as per the latest 
addendum

Tom Rini (8):
  am335x_evm: Never set CONFIG_EXTRA_ENV_SETTINGS in SPL
  am335x_evm: Add am335x_evm_usbspl build target
  am33xx: Update DDR3 EMIF configuration sequence
  am335x_evm: Enable CONFIG_CMD_BOOTZ
  omap5_evm: Enable CONFIG_CMD_BOOTZ
  omap3_beagle: Enable CONFIG_CMD_BOOTZ
  omap4_common: Enable CONFIG_CMD_BOOTZ
  Merge u-boot/master into u-boot-ti/master

The following diffstat is a little "funny" since to generate something
close to correct I had to make a manual merge branch of
u-boot-arm/master + u-boot/master and compare vs that.

 MAINTAINERS |1 +
 README  |   19 +
 arch/arm/cpu/arm1136/mx35/generic.c |2 +-
 arch/arm/cpu/armv7/am33xx/board.c   |4 +-
 arch/arm/cpu/armv7/am33xx/ddr.c |   12 +-
 arch/arm/cpu/armv7/omap-common/boot-common.c|7 +-
 arch/arm/cpu/armv7/omap-common/clocks-common.c  |  312 +---
 arch/arm/cpu/armv7/omap-common/emif-common.c|   73 +-
 arch/arm/cpu/armv7/omap-common/hwinit-common.c  |   23 +-
 arch/arm/cpu/armv7/omap-common/vc.c |   11 +-
 arch/arm/cpu/armv7/omap3/board.c|6 +-
 arch/arm/cpu/armv7/omap4/Makefile   |3 +-
 arch/arm/cpu/armv7/omap4/clocks.c   |  517 
 arch/arm/cpu/armv7/omap4/hw_data.c  |  491 
 arch/arm/cpu/armv7/omap4/hwinit.c   |   36 +-
 arch/arm/cpu/armv7/omap4/prcm-regs.c|  315 
 arch/arm/cpu/armv7/omap4/sdram_elpida.c |   34 +-
 arch/arm/cpu/armv7/omap5/Makefile   |3 +-
 arch/arm/cpu/armv7/omap5/clocks.c   |  494 
 arch/arm/cpu/armv7/omap5/hw_data.c  |  596 ++
 arch/arm/cpu/armv7/omap5/hwinit.c   |  292 ---
 arch/arm/cpu/armv7/omap5/prcm-regs.c|  958 +++
 arch/arm/cpu/armv7/omap5/sdram.c|  214 -
 arch/arm/cpu/armv7/zynq/Makefile|1 +
 arch/arm/cpu/armv7/zynq/cpu.c   |   28 +-
 arch/arm/cpu/armv7/zynq/slcr.c  |   63 ++
 arch/arm/include/asm/

Re: [U-Boot] [U-Boot, PATCHv2, 3/4] SPL: ONENAND: Support SPL to boot u-boot from OneNAND.

[Tom Rini]

On Thu, Feb 07, 2013 at 11:14:48PM -, Enric Balletbo i Serra wrote:

> From: Enric Balletbo i Serra 
> 
> This patch will allow use SPL to boot an u-boot from the OneNAND.
> 
> Tested with IGEPv2 board with a OneNAND from Numonyx
> 
> Signed-off-by: Enric Balletbo i Serra 
> 
> ---
> common/spl/Makefile  |1 +
>  common/spl/spl.c |5 +
>  common/spl/spl_onenand.c |   47 
> ++
>  3 files changed, 53 insertions(+)
>  create mode 100644 common/spl/spl_onenand.c
> 
> diff --git a/common/spl/Makefile b/common/spl/Makefile
> index 5698a23..da2afc1 100644
> --- a/common/spl/Makefile
> +++ b/common/spl/Makefile
> @@ -18,6 +18,7 @@ COBJS-$(CONFIG_SPL_FRAMEWORK) += spl.o
>  COBJS-$(CONFIG_SPL_NOR_SUPPORT) += spl_nor.o
>  COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += spl_ymodem.o
>  COBJS-$(CONFIG_SPL_NAND_SUPPORT) += spl_nand.o
> +COBJS-$(CONFIG_SPL_ONENAND_SUPPORT) += spl_onenand.o
>  COBJS-$(CONFIG_SPL_NET_SUPPORT) += spl_net.o
>  endif
>  
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index ff9ba7b..293c7e1 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -197,6 +197,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>   spl_nand_load_image();
>   break;
>  #endif
> +#ifdef CONFIG_SPL_ONENAND_SUPPORT
> + case BOOT_DEVICE_ONENAND:
> + spl_onenand_load_image();
> + break;
> +#endif
>  #ifdef CONFIG_SPL_NOR_SUPPORT
>   case BOOT_DEVICE_NOR:
>   spl_nor_load_image();
> diff --git a/common/spl/spl_onenand.c b/common/spl/spl_onenand.c
> new file mode 100644
> index 000..a839557
> --- /dev/null
> +++ b/common/spl/spl_onenand.c
> @@ -0,0 +1,47 @@
> +/*
> + * Copyright (C) 2013
> + * ISEE 2007 SL - Enric Balletbo i Serra 
> + *
> + * Based on common/spl/spl_nand.c
> + * Copyright (C) 2011
> + * Corscience GmbH & Co. KG - Simon Schwarz 
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * 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 
> +
> +void spl_onenand_load_image(void)
> +{
> + struct image_header *header;
> +
> + debug("spl: onenand\n");
> +
> + /*use CONFIG_SYS_TEXT_BASE as temporary storage area */
> + header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
> + /* Load u-boot */
> + onenand_spl_load_image(CONFIG_SYS_ONENAND_U_BOOT_OFFS,
> + CONFIG_SYS_ONENAND_PAGE_SIZE, (void *)header);
> + spl_parse_image_header(header);
> + onenand_spl_load_image(CONFIG_SYS_ONENAND_U_BOOT_OFFS,
> + spl_image.size, (void *)spl_image.load_addr);
> +}

With the following change:

diff --git a/include/spl.h b/include/spl.h
index b02f36f..b40be80 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -59,6 +59,9 @@ void spl_display_print(void);
 /* NAND SPL functions */
 void spl_nand_load_image(void);
 
+/* OneNAND SPL functions */
+void spl_onenand_load_image(void);
+
 /* NOR SPL functions */
 void spl_nor_load_image(void);

To fix a warning, applied to u-boot-ti/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 6/7] arm: dra7xx: Add board files for DRA7XX socs

[Tom Rini]

On Tue, Feb 12, 2013 at 09:29:08PM -, Lokesh Vutla wrote:

> Adding new board files for DRA7XX socs.
> The pad registers layout is changed completely from OMAP5
> So introducing the new structure here and also adding the
> minimal data.
> 
> Signed-off-by: Lokesh Vutla 
> Signed-off-by: Nishant Kamat 
> Signed-off-by: R Sricharan 
> Reviewed-by: Tom Rini 

With the following change to adapt to the omap_mmc_init changes I've
also taken into u-boot-ti/master:

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index cd344da..7bbb549 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -96,8 +96,8 @@ void set_muxconf_regs_essential(void)
 #if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
-   omap_mmc_init(0, 0, 0);
-   omap_mmc_init(1, 0, 0);
+   omap_mmc_init(0, 0, 0, -1, -1);
+   omap_mmc_init(1, 0, 0, -1, -1);
return 0;
 }
 #endif

This is now applied to u-boot-ti/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC

[Simon Glass]

Hi Tom,

On Mon, Mar 11, 2013 at 10:03 AM, Simon Glass  wrote:

> This series creates a generic board init implementation which contains
> the essential functions of the major arch/xxx/lib/board.c files. It is
> split into two parts: board_f.c for pre-relocation and board_r.c for
> post-relocation.
>
> What is the motivation for this change?
>
> 1. There is a lot of repeated code in the board.c files. Any change to
> things like setting up the baud rate requires a change in 10 separate
> places.
>
> 2. Since there are 14 separate files, adding a new feature which requires
> initialisation is painful since it must be independently added in 14
> places.
>
> 3. As time goes by the architectures naturely diverge since there is
> limited
> pressure to compare features or even CONFIG options against simiilar things
> in other board.c files.
>
> 4. New architectures must implement all the features all over again, and
> sometimes in subtley different ways. This places an unfair burden on
> getting
> a new architecture fully functional and running with U-Boot.
>
> 5. While it is a bit of a tricky change, I believe it is worthwhile and
> achievable. There is no requirement that all code be common, only that
> the code that is common should be located in common/board.c rather than
> arch/xxx/lib/board.c.
>
> All the functions of board_init_f() and board_init_r() are broken into
> separate function calls so that they can easily be included or excluded
> for a particular architecture. It also makes it easier to adopt Graeme's
> initcall proposal assuming this comes about.
>
> http://lists.denx.de/pipermail/u-boot/2012-January/114499.html
>
> This series is not dependent on generic relocation. So relocation
> happens as one big chunk and is still completely arch-specific. See the
> relocation series for a proposed solution to this for ARM:
>
> http://lists.denx.de/pipermail/u-boot/2011-December/112928.html
>
> or x86's implementation which is in mainline. Unifying relocation is
> probably the next step after this series.
>
> Instead of moving over a whole architecture, this series takes the approach
> of simply enabling generic board support for an architecture. It is then up
> to each board to opt in by defining CONFIG_SYS_GENERIC_BOARD in the board
> config file. If this is not done, then the code will be generated as
> before. This allows both sets of code to co-exist until we are comfortable
> with the generic approach, and enough boards run.
>
> ARM is a relatively large board.c file and one which I can test, therefore
> I think it is a good target for this series. On the other hand, x86 is
> relatively small and simple, but different enough that it introduces a
> few issues to be solved. So I have chosen both ARM and x86 for this series.
> After a suggestion from Wolfgang I have added PPC also. This is the
> largest and most feature-full board, so hopefully we have all bases
> covered in this series. Other archs are mostly a subset of these.
>
> A generic global_data structure is now in mainline, and this is required
> for this series.
>
> Similarly we need a generic bd_info structure, since generic code will
> be accessing it. I have done this with a simple generic file for now.
>
> There was dicussion on the list about passing gd_t around as a parameter
> to pre-relocation init functions. I think this makes sense, but it can
> be done as a separate change, and this series does not require it.
>
> While this series needs to stand on its own, the goal is the unification
> of the board init code. So I hope we can address issues with this in mind,
> rather than focusing too narrowly on particular ARM, x86 or PPC issues.
> I have added TODO markers in places where I think there are opportunities
> to relationalise the board init now it is all in one place, but these don't
> need to be addressed for the feature to work, and are best done as smaller
> patches than can be reviewed by individual arch maintainers, I think.
>
> I have run-tested ARM on Tegra Seaboard and x86/coreboot only. To try it
> out, define CONFIG_SYS_GENERIC_BOARD in your board file and rebuild. Most
> likely on PPC at least it will hang, but if you are lucky it will print
> something first :-) I hope to test an SPL board (snow / exynos5250) when
> I can get that booting from mainline.
>
> I have run this though buildman with CONFIG_SYS_GENERIC_BOARD on for all
> ARM, PPC and x86 boards. The only failure is highbank (an ARM board), which
> seems to use SCSI but scsi_init() is not available.
>
> Code size increases by about 1KB on ARM and about 1.3KB on PPC with generic
> board enabled. This is mostly due to the move to using separate functions
> for each part of the init, which will make it easier to move to a pure
> initcall approach later if we want to.
>
> Since this series was first sent there have been additions to the board
> code for ARM and PPC. I have added in these additions. This is a manual
> process, and I expect that people will find p

[U-Boot] u-Boot from SD card booting

[Alexey Astakhov]

Dear colleagues!
Thank You very much for the u-Boot GIT. It is very useful. I have tried to make 
u-Boot for tms320dm368. It works.
I do have a  questions will You please give Me the advise.

I do have board Spectrumboard. u-Boot is started from NAND there. What I needed 
is to make booting from SD card (SD0). Is it possible to make booting SD card 
from Windows if I do have Windows computer fitted with SD card slot. Where can 
I find some instruction set about the way to do it. Again I do have prepared 
u-Boot file. I need to put it into SD card and make booting from it.
Thanks for consultancy.
Best regards Alexey.___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] Feature Removal: disable "mtest" command by default

[Tom Rini]

On Fri, Mar 08, 2013 at 09:51:32PM +0100, Wolfgang Denk wrote:

> The "mtest" command is of little practical use (if any), and
> experience has shown that a large number of board configurations
> define useless or even dangerous start and end addresses.  If not even
> the board maintainers are able to figure out which memory range can be
> reliably tested, how can we expect such from the end users?  As this
> problem comes up repeatedly, we rather do not enable this command by
> default, so only people who know what they are doing will be
> confronted with it.
> 
> As this changes the user interface, we allow for a grace period
> before this change takes effect. For now, we make "mtest"
> configurable through the CONFIG_CMD_MEMTEST variable, which is defined
> in include/config_cmd_default.h;  we also add an entry to
> doc/feature-removal-schedule.txt which announces the removal of this
> default setting in two releases from now, i. e. with v2013.07.
> 
> Signed-off-by: Wolfgang Denk 
> Cc: Tom Rini 
> ---
> v2: - Fix spelling errors in doc/README.memory-test;
>   kudos to Ira W. Snyder

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Conflict between mainline and ARM trees on davinci

[Tom Rini]

On Mon, Mar 11, 2013 at 10:38:21AM +0100, Albert ARIBAUD wrote:

> Hello,
> 
> There is merge conflict between mainline and ARM trees on davinci gpio,
> between
> 
>   commit 03414ac45e119496e2475aeacbb968bb67da24f8
>   gpio: Build the da8xx_gpio code for the davinci644x device
>   (mainline)
> 
> and
> 
>   commit b9f56698c7e9bf7ac773b5346c4f6886e214b69b
>   da8xx: Add the missing pinmux for da830 to the gpio driver
>   (ARM, from TI tree)
> 
> Authors CC:ed, as well as Tom for both TI and mainline tree.
> 
> Tom, how do you want to reconcile things?
> 
> Manual resolution in the merge commit was frowned upon last time I did
> it, because it introduces non-reviewed code changes.
> 
> This leaves doing a manual commit on either one of the mainline, ARM or
> TI trees so that merge becomes trivial. Mainline tree is preferable I
> think, because it avoids added PR.

This is addressed with the next u-boot-ti/master pull request where I
included the conflict resolution commit.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 4/5] usb: Add multiple controllers support for EHCI PCI

[Simon Glass]

From: Vincent Palatin 

Use the ability to have several active EHCI controller on a system
in the PCI EHCI controller implementation.

Signed-off-by: Simon Glass 
---
Changes in v4:
- Add errno.h header file to ehci-pci

Changes in v3: None
Changes in v2:
- Add blank line before function return

 drivers/usb/host/ehci-pci.c | 53 -
 1 file changed, 47 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 29af02d..c1ff8fc 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -19,6 +19,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -32,30 +33,70 @@ static struct pci_device_id ehci_pci_ids[] = {
{0x12D8, 0x400F},   /* Pericom */
{0, 0}
 };
+#else
+static pci_dev_t ehci_find_class(int index)
+{
+   int bus;
+   int devnum;
+   pci_dev_t bdf;
+   uint32_t class;
+
+   for (bus = 0; bus <= pci_last_busno(); bus++) {
+   for (devnum = 0; devnum < PCI_MAX_PCI_DEVICES-1; devnum++) {
+   pci_read_config_dword(PCI_BDF(bus, devnum, 0),
+ PCI_CLASS_REVISION, &class);
+   if (class >> 16 == 0x)
+   continue;
+
+   for (bdf = PCI_BDF(bus, devnum, 0);
+   bdf <= PCI_BDF(bus, devnum,
+   PCI_MAX_PCI_FUNCTIONS - 1);
+   bdf += PCI_BDF(0, 0, 1)) {
+   pci_read_config_dword(bdf, PCI_CLASS_REVISION,
+ &class);
+   if ((class >> 8 == PCI_CLASS_SERIAL_USB_EHCI)
+   && !index--)
+   return bdf;
+   }
+   }
+   }
+
+   return -ENODEV;
+}
 #endif
 
 /*
  * Create the appropriate control structures to manage
  * a new EHCI host controller.
  */
-int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor)
+int ehci_hcd_init(int index, struct ehci_hccr **ret_hccr,
+   struct ehci_hcor **ret_hcor)
 {
pci_dev_t pdev;
+   struct ehci_hccr *hccr;
+   struct ehci_hcor *hcor;
 
+#ifdef CONFIG_PCI_EHCI_DEVICE
pdev = pci_find_devices(ehci_pci_ids, CONFIG_PCI_EHCI_DEVICE);
+#else
+   pdev = ehci_find_class(index);
+#endif
if (pdev == -1) {
printf("EHCI host controller not found\n");
return -1;
}
 
-   *hccr = (struct ehci_hccr *)pci_map_bar(pdev,
+   hccr = (struct ehci_hccr *)pci_map_bar(pdev,
PCI_BASE_ADDRESS_0, PCI_REGION_MEM);
-   *hcor = (struct ehci_hcor *)((uint32_t) *hccr +
-   HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));
+   hcor = (struct ehci_hcor *)((uint32_t) hccr +
+   HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
 
debug("EHCI-PCI init hccr 0x%x and hcor 0x%x hc_length %d\n",
-   (uint32_t)*hccr, (uint32_t)*hcor,
-   (uint32_t)HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));
+   (uint32_t)hccr, (uint32_t)hcor,
+   (uint32_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
+
+   *ret_hccr = hccr;
+   *ret_hcor = hcor;
 
return 0;
 }
-- 
1.8.1.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] USB patches

[Simon Glass]

Hi Marek,

On Mon, Mar 11, 2013 at 9:16 AM, Simon Glass  wrote:

> Hi Marek,
>
> As requested here is an email about the USB patches. I have put them in a
> bundle here:
>
> http://patchwork.ozlabs.org/bundle/sjg/for-marex/
>
>
But unfortunately I found a problem in patch 4. Here is an updated version
which includes errno.h.

http://patchwork.ozlabs.org/patch/226713/

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v11 10/31] Introduce generic post-relocation board_r.c

[Simon Glass]

This file handles common post-relocation init for boards which use
the generic framework.

Signed-off-by: Simon Glass 
---
Changes in v11:
- Correct Flash output message to remove double printing

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Add code from arch/arm/lib/board.c to control loading of environment
- Put watchdog init function definitions in watchdog.h
- Adjust ppc to work with watchdog.h additions

Changes in v4:
- Use asm/sections.h instead of asm-generic/sections.h

Changes in v3: None
Changes in v2: None

 arch/powerpc/lib/board.c |   3 +-
 common/Makefile  |   1 +
 common/board_r.c | 422 +++
 3 files changed, 425 insertions(+), 1 deletion(-)
 create mode 100644 common/board_r.c

diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
index acb6fdb..422b4a3 100644
--- a/arch/powerpc/lib/board.c
+++ b/arch/powerpc/lib/board.c
@@ -319,7 +319,8 @@ static init_fnc_t *init_sequence[] = {
 #ifdef CONFIG_POST
post_init_f,
 #endif
-   INIT_FUNC_WATCHDOG_RESET init_func_ram,
+   INIT_FUNC_WATCHDOG_RESET
+   init_func_ram,
 #if defined(CONFIG_SYS_DRAM_TEST)
testdram,
 #endif /* CONFIG_SYS_DRAM_TEST */
diff --git a/common/Makefile b/common/Makefile
index a5f5b1a..08af1a8 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -38,6 +38,7 @@ COBJS-y += cmd_disk.o
 
 # boards
 COBJS-$(CONFIG_SYS_GENERIC_BOARD) += board_f.o
+COBJS-$(CONFIG_SYS_GENERIC_BOARD) += board_r.o
 
 # core command
 COBJS-y += cmd_boot.o
diff --git a/common/board_r.c b/common/board_r.c
new file mode 100644
index 000..06b0df0
--- /dev/null
+++ b/common/board_r.c
@@ -0,0 +1,422 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * (C) Copyright 2002-2006
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH 
+ * Marius Groeger 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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 
+#ifdef CONFIG_HAS_DATAFLASH
+#include 
+#endif
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+ulong monitor_flash_len;
+
+
+static int initr_reloc(void)
+{
+   gd->flags |= GD_FLG_RELOC;  /* tell others: relocation done */
+   bootstage_mark_name(BOOTSTAGE_ID_START_UBOOT_R, "board_init_r");
+
+   return 0;
+}
+
+#ifdef CONFIG_ARM
+/*
+ * Some of these functions are needed purely because the functions they
+ * call return void. If we change them to return 0, these stubs can go away.
+ */
+static int initr_caches(void)
+{
+   /* Enable caches */
+   enable_caches();
+   return 0;
+}
+#endif
+
+static int initr_reloc_global_data(void)
+{
+#ifdef CONFIG_SYS_SYM_OFFSETS
+   monitor_flash_len = _end_ofs;
+#else
+   monitor_flash_len = (ulong)&__init_end - gd->dest_addr;
+#endif
+}
+
+static int initr_serial(void)
+{
+   serial_initialize();
+   return 0;
+}
+
+#ifdef CONFIG_LOGBUFFER
+unsigned long logbuffer_base(void)
+{
+   return gd->ram_top - LOGBUFF_LEN;
+}
+
+static int initr_logbuffer(void)
+{
+   logbuff_init_ptrs();
+   return 0;
+}
+#endif
+
+#ifdef CONFIG_POST
+static int initr_post_backlog(void)
+{
+   post_output_backlog();
+   return 0;
+}
+#endif
+
+static int initr_malloc(void)
+{
+   ulong malloc_start;
+
+   /* The malloc area is immediately below the monitor copy in DRAM */
+   malloc_start = gd->dest_addr - TOTAL_MALLOC_LEN;
+   mem_malloc_init(malloc_start, TOTAL_MALLOC_LEN);
+   return 0;
+}
+
+__weak int power_init_board(void)
+{
+   return 0;
+}
+
+static int initr_announce(void)
+{
+   debug("Now running in RAM - U-Boot at: %08lx\n", gd->dest_addr);
+   return 0;
+}
+
+#if !defined(CONFIG_SYS_NO_FLASH)
+static int initr_flash(void)
+{
+   ulong flash_size;
+
+   puts("Flash: ");
+
+   flash_size = flash_init();
+   if (flash_size <= 0) {
+   puts("*** failed ***\n");
+   return -1;
+   }
+   print_size(flash_size, "");
+#ifdef CONFIG_SYS_FLASH_CHECKSUM
+   /*
+   * Compute and print

[U-Boot] [PATCH v11 15/31] Adjust board_f.c for ppc

[Simon Glass]

This adds ppc features to the generic pre-relocation board init.

This is a separate commit so that these features are clearly shown.

Signed-off-by: Simon Glass 
---
Changes in v11:
- Add possible fix for PPC stack alignment problem

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Tidy up stack reservation code to separate out PowerPC

Changes in v5:
- Use watchdog.h for watchdog functions
- Add define to work around __bss_end / __bss_end__ confusion

Changes in v4:
- Updates to sit on top of earlier patches

Changes in v3: None
Changes in v2: None

 common/board_f.c | 334 ++-
 1 file changed, 332 insertions(+), 2 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index b625ccb..1721eed 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -31,10 +31,31 @@
 #include 
 #include 
 #include 
+#if defined(CONFIG_CMD_IDE)
+#include 
+#endif
+#include 
 #include 
 #include 
+
+/* TODO: Can we move these into arch/ headers? */
+#ifdef CONFIG_8xx
+#include 
+#endif
+#ifdef CONFIG_5xx
+#include 
+#endif
+#ifdef CONFIG_MPC5xxx
+#include 
+#endif
+
 #include 
+#include 
+#include 
 #include 
+#ifdef CONFIG_MP
+#include 
+#endif
 #include 
 #include 
 
@@ -97,6 +118,31 @@ void blue_led_off(void) __attribute__((weak, 
alias("__blue_led_off")));
  * Could the CONFIG_SPL_BUILD infection become a flag in gd?
  */
 
+#if defined(CONFIG_WATCHDOG)
+static int init_func_watchdog_init(void)
+{
+   puts("   Watchdog enabled\n");
+   WATCHDOG_RESET();
+
+   return 0;
+}
+
+int init_func_watchdog_reset(void)
+{
+   WATCHDOG_RESET();
+
+   return 0;
+}
+#endif /* CONFIG_WATCHDOG */
+
+void __board_add_ram_info(int use_default)
+{
+   /* please define platform specific board_add_ram_info() */
+}
+
+void board_add_ram_info(int)
+   __attribute__ ((weak, alias("__board_add_ram_info")));
+
 static int init_baud_rate(void)
 {
gd->baudrate = getenv_ulong("baudrate", 10, CONFIG_BAUDRATE);
@@ -134,6 +180,25 @@ static int announce_dram_init(void)
return 0;
 }
 
+#ifdef CONFIG_PPC
+static int init_func_ram(void)
+{
+#ifdef CONFIG_BOARD_TYPES
+   int board_type = gd->board_type;
+#else
+   int board_type = 0; /* use dummy arg */
+#endif
+
+   gd->ram_size = initdram(board_type);
+
+   if (gd->ram_size > 0)
+   return 0;
+
+   puts("*** failed ***\n");
+   return 1;
+}
+#endif
+
 static int show_dram_config(void)
 {
ulong size;
@@ -154,11 +219,24 @@ static int show_dram_config(void)
size = gd->ram_size;
 #endif
 
-   print_size(size, "\n");
+   print_size(size, "");
+   board_add_ram_info(0);
+   putc('\n');
 
return 0;
 }
 
+ulong get_effective_memsize(void)
+{
+#ifndefCONFIG_VERY_BIG_RAM
+   return gd->ram_size;
+#else
+   /* limit stack to what we can reasonable map */
+   return ((gd->ram_size > CONFIG_MAX_MEM_MAPPED) ?
+   CONFIG_MAX_MEM_MAPPED : gd->ram_size);
+#endif
+}
+
 void __dram_init_banksize(void)
 {
 #if defined(CONFIG_NR_DRAM_BANKS) && defined(CONFIG_SYS_SDRAM_BASE)
@@ -170,6 +248,27 @@ void __dram_init_banksize(void)
 void dram_init_banksize(void)
__attribute__((weak, alias("__dram_init_banksize")));
 
+#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SOFT_I2C)
+static int init_func_i2c(void)
+{
+   puts("I2C:   ");
+   i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+   puts("ready\n");
+   return 0;
+}
+#endif
+
+#if defined(CONFIG_HARD_SPI)
+static int init_func_spi(void)
+{
+   puts("SPI:   ");
+   spi_init();
+   puts("ready\n");
+   return 0;
+}
+#endif
+
+__maybe_unused
 static int zero_global_data(void)
 {
memset((void *)gd, '\0', sizeof(gd_t));
@@ -182,7 +281,8 @@ static int setup_mon_len(void)
 #ifdef CONFIG_SYS_SYM_OFFSETS
gd->mon_len = _bss_end_ofs;
 #else
-   gd->mon_len = (ulong)&__bss_end - (ulong)&__text_start;
+   /* TODO: use (ulong)&__bss_end - (ulong)&__text_start; ? */
+   gd->mon_len = (ulong)&__bss_end - CONFIG_SYS_MONITOR_BASE;
 #endif
return 0;
 }
@@ -240,9 +340,20 @@ static int setup_dest_addr(void)
 #ifdef CONFIG_SYS_SDRAM_BASE
gd->ram_top = CONFIG_SYS_SDRAM_BASE;
 #endif
+   gd->ram_top += get_effective_memsize();
gd->ram_top = board_get_usable_ram_top(gd->mon_len);
gd->dest_addr = gd->ram_top;
debug("Ram top: %08lX\n", (ulong)gd->ram_top);
+#if defined(CONFIG_MP) && (defined(CONFIG_MPC86xx) || defined(CONFIG_E500))
+   /*
+* We need to make sure the location we intend to put secondary core
+* boot code is reserved and not used by any part of u-boot
+*/
+   if (gd->dest_addr > determine_mp_bootpg(NULL)) {
+   gd->dest_addr = determine_mp_bootpg(NULL);
+   debug("Reserving MP boot page to %08lx\n", gd->dest_addr);
+   }
+#endif
gd->dest_addr_sp = 

Re: [U-Boot] [PATCH 4/5 v4] gen: Add ACE acceleration to hash

[Kim Phillips]

On Thu, 7 Mar 2013 19:11:16 -0800
Simon Glass  wrote:

> Hi Kim,
> 
> On Thu, Mar 7, 2013 at 6:18 PM, Kim Phillips  
> wrote:
> > On Thu, 7 Mar 2013 17:05:15 -0800
> > Simon Glass  wrote:
> >
> >> On Thu, Mar 7, 2013 at 4:25 PM, Kim Phillips  
> >> wrote:
> >> > On Wed, 6 Mar 2013 18:08:21 -0800
> >> > Simon Glass  wrote:
> >> >
> >> >> On Wed, Mar 6, 2013 at 5:22 PM, Kim Phillips 
> >> >>  wrote:
> >> >> > On Tue, 5 Mar 2013 22:22:09 -0800
> >> >> > Simon Glass  wrote:
> >> >> >
> >> >> >> On Tue, Mar 5, 2013 at 9:04 PM, Kim Phillips 
> >> >> >>  wrote:
> >> >> >> > On Tue, 5 Mar 2013 17:51:00 -0800
> >> >> >> > Simon Glass  wrote:
> >> >> >> >> >> Changes sice v3:
> >> >> >> >> >>   - Changed command names to lower case in algo struct.
> >> >> >> >> >>   - Added generic ace_sha config.
> >> >> >> >> >
> >> >> >> >> > I wouldn't call "ace" a generic name - crypto units other than
> >> >> >> >> > ACE should be able to use this code.
> >> >> >> >>
> >> >> >> >> I don't really understand this comment. A new CONFIG has been 
> >> >> >> >> added,
> >> >> >> >> and this is specific to that unit. Are you suggesting that it be
> >> >> >> >
> >> >> >> > right, and that's the problem - it needn't be specific to that 
> >> >> >> > unit.
> >> >> >>
> >> >> >> Really? I think here we have a patch for an ACE unit, and currently
> >> >> >> the only implementation is in an Exynos chip. It can easily be
> >> >> >
> >> >> > so make the ace_sha.o build depend on whichever level of chip config
> >> >> > applies - CONFIG_S5P, CONFIG_EXYNOS5, or CONFIG_SMDK5250.  No need
> >> >> > for a new define specifically for ACE, right?
> >> >>
> >> >> No, the ACE may appear in multiple chips, and anyway we may want to
> >> >> enable it or disable it. Drivers tend to have their own configs since
> >> >> some boards want to use (for example) USB, crypto, mmc, and some
> >> >> don't.
> >> >
> >> > ok, if you really need the ACE define, restrict it to platform code
> >> > and the driver, but not common code.
> >>
> >> That is in the design of the hash.c module. It is intended to permit
> >> insertion of different algorithm implementations. We could perhaps
> >> introduce a hash_register() function to deal with this, but that's the
> >> way it is at present.
> >
> > ok, well this is the first time a new alternate algorithm
> > implementation is being posted, and it's bringing up a flaw in the
> > design - no vendor-specific stuff in common areas.
> 
> OK so let's look at adding the hash_register() idea. But not in this
> series. That should come later in a revision of the hash.c
> infrastructure, since it needs to adjust sha1, sha255 and crc32.

I don't understand: why not s/ace/hw/g in common/ and include/ on
this patchseries, then move straight to the device model at some
later point?  It's a compromise, but it works fine for the time
being - other vendors can add their hash support without having to
touch common code, code size is not affected, etc.

> >> > the problem is there are only two algorithms for all - the
> >> > accelerated, and the non-.  Presumably we get the acceleration for
> >> > free, so we always will prefer to use the accelerated version, and
> >> > if it doesn't work, then the core s/w implementation.  The
> >> > common/hash.c infrastructure currently doesn't support that: it
> >> > assumes the existence of multiple heterogeneous crypto units will
> >> > exist on a single u-boot instance, each used depending on its
> >> > priority, which is not the case.
> >>
> >> Fair enough, and that might be a good idea, but that is an issue for
> >> the hash infrastructure. It would be good to get a second hardware
> >> accelerator upstream so we can judge where to take this.
> >
> > well right now as it stands the 2nd h/w accelerator would have to
> > duplicate hash entry point function signatures, just changing the
> > ACE in the name to that of its h/w, and then spin on a tough
> > decision: what priority does my h/w have vs. Samsung's ACE??
> 
> I thought you said that only one h/w accelerator would be used on a board?

yes, I was trying to be funny, but as usual, it didn't work.

> >> If you have one in a Freescale SOC can I please request that you send
> >> some patches upstream and we can then evaluate how best to arrange the
> >> code.
> >
> > they'll come, eventually I hope.  Other than the driver internals,
> > the only thing different from the ACE functional capacity provided
> > in this patchseries for the analogous Freescale parts is that the
> > hash infrastructure would need to be adapted for runtime detection
> > of the crypto unit's existence.
> >
> > But let's not use this as an excuse to let things slide, please.
> >
> > this is new infrastructure, right?  It's common to make mistakes
> > without seeing the entire picture, and this patchset represents the
> > next piece.
> 
> I would prefer to invent new infrastructure when we have two users,
> not one, otherwise we run the risk of over-engineering. I alre

Re: [U-Boot] [PATCH 4/5 v4] gen: Add ACE acceleration to hash

[Simon Glass]

Hi Kim,

On Mon, Mar 11, 2013 at 5:44 PM, Kim Phillips wrote:

> On Thu, 7 Mar 2013 19:11:16 -0800
> Simon Glass  wrote:
>
> > Hi Kim,
> >
> > On Thu, Mar 7, 2013 at 6:18 PM, Kim Phillips 
> wrote:
> > > On Thu, 7 Mar 2013 17:05:15 -0800
> > > Simon Glass  wrote:
> > >
> > >> On Thu, Mar 7, 2013 at 4:25 PM, Kim Phillips <
> kim.phill...@freescale.com> wrote:
> > >> > On Wed, 6 Mar 2013 18:08:21 -0800
> > >> > Simon Glass  wrote:
> > >> >
> > >> >> On Wed, Mar 6, 2013 at 5:22 PM, Kim Phillips <
> kim.phill...@freescale.com> wrote:
> > >> >> > On Tue, 5 Mar 2013 22:22:09 -0800
> > >> >> > Simon Glass  wrote:
> > >> >> >
> > >> >> >> On Tue, Mar 5, 2013 at 9:04 PM, Kim Phillips <
> kim.phill...@freescale.com> wrote:
> > >> >> >> > On Tue, 5 Mar 2013 17:51:00 -0800
> > >> >> >> > Simon Glass  wrote:
> > >> >> >> >> >> Changes sice v3:
> > >> >> >> >> >>   - Changed command names to lower case in algo
> struct.
> > >> >> >> >> >>   - Added generic ace_sha config.
> > >> >> >> >> >
> > >> >> >> >> > I wouldn't call "ace" a generic name - crypto units other
> than
> > >> >> >> >> > ACE should be able to use this code.
> > >> >> >> >>
> > >> >> >> >> I don't really understand this comment. A new CONFIG has
> been added,
> > >> >> >> >> and this is specific to that unit. Are you suggesting that
> it be
> > >> >> >> >
> > >> >> >> > right, and that's the problem - it needn't be specific to
> that unit.
> > >> >> >>
> > >> >> >> Really? I think here we have a patch for an ACE unit, and
> currently
> > >> >> >> the only implementation is in an Exynos chip. It can easily be
> > >> >> >
> > >> >> > so make the ace_sha.o build depend on whichever level of chip
> config
> > >> >> > applies - CONFIG_S5P, CONFIG_EXYNOS5, or CONFIG_SMDK5250.  No
> need
> > >> >> > for a new define specifically for ACE, right?
> > >> >>
> > >> >> No, the ACE may appear in multiple chips, and anyway we may want to
> > >> >> enable it or disable it. Drivers tend to have their own configs
> since
> > >> >> some boards want to use (for example) USB, crypto, mmc, and some
> > >> >> don't.
> > >> >
> > >> > ok, if you really need the ACE define, restrict it to platform code
> > >> > and the driver, but not common code.
> > >>
> > >> That is in the design of the hash.c module. It is intended to permit
> > >> insertion of different algorithm implementations. We could perhaps
> > >> introduce a hash_register() function to deal with this, but that's the
> > >> way it is at present.
> > >
> > > ok, well this is the first time a new alternate algorithm
> > > implementation is being posted, and it's bringing up a flaw in the
> > > design - no vendor-specific stuff in common areas.
> >
> > OK so let's look at adding the hash_register() idea. But not in this
> > series. That should come later in a revision of the hash.c
> > infrastructure, since it needs to adjust sha1, sha255 and crc32.
>
> I don't understand: why not s/ace/hw/g in common/ and include/ on
> this patchseries, then move straight to the device model at some
> later point?  It's a compromise, but it works fine for the time
> being - other vendors can add their hash support without having to
> touch common code, code size is not affected, etc.
>

Fine with me. The effect is the same - this is just a rename. Should not be
done in the ace.h file though, only in the naming of the functions called
from hash.c, right?


>
> > >> > the problem is there are only two algorithms for all - the
> > >> > accelerated, and the non-.  Presumably we get the acceleration for
> > >> > free, so we always will prefer to use the accelerated version, and
> > >> > if it doesn't work, then the core s/w implementation.  The
> > >> > common/hash.c infrastructure currently doesn't support that: it
> > >> > assumes the existence of multiple heterogeneous crypto units will
> > >> > exist on a single u-boot instance, each used depending on its
> > >> > priority, which is not the case.
> > >>
> > >> Fair enough, and that might be a good idea, but that is an issue for
> > >> the hash infrastructure. It would be good to get a second hardware
> > >> accelerator upstream so we can judge where to take this.
> > >
> > > well right now as it stands the 2nd h/w accelerator would have to
> > > duplicate hash entry point function signatures, just changing the
> > > ACE in the name to that of its h/w, and then spin on a tough
> > > decision: what priority does my h/w have vs. Samsung's ACE??
> >
> > I thought you said that only one h/w accelerator would be used on a
> board?
>
> yes, I was trying to be funny, but as usual, it didn't work.
>

OK, sorry I missed it.


>
> > >> If you have one in a Freescale SOC can I please request that you send
> > >> some patches upstream and we can then evaluate how best to arrange the
> > >> code.
> > >
> > > they'll come, eventually I hope.  Other than the driver internals,
> > > the only thing different from the ACE functional capacity provided
> > > in this patchseries for the analogous Fr

Re: [U-Boot] [PATCH] SMDK5250: FDT: Retrieve board model via DT

[Minkyu Kang]

On 18/02/13 21:51, Rajeshwari Shinde wrote:
> Print out the board model by parsing the device tree file.
> 
> Signed-off-by: Rajeshwari Shinde 
> ---
>  board/samsung/smdk5250/smdk5250.c |   11 ++-
>  1 files changed, 10 insertions(+), 1 deletions(-)
> 
> diff --git a/board/samsung/smdk5250/smdk5250.c 
> b/board/samsung/smdk5250/smdk5250.c
> index 6f6f2c2..0097b3f 100644
> --- a/board/samsung/smdk5250/smdk5250.c
> +++ b/board/samsung/smdk5250/smdk5250.c
> @@ -336,8 +336,17 @@ int board_eth_init(bd_t *bis)
>  #ifdef CONFIG_DISPLAY_BOARDINFO
>  int checkboard(void)
>  {
> - printf("\nBoard: SMDK5250\n");
> +#ifdef CONFIG_OF_CONTROL
> + const char *board_name;
>  
> + board_name = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
> + if (board_name == NULL)
> + printf("\nUnknown Board\n");
> + else
> + printf("\nBoard: %s\n", board_name);
> +#else
> + printf("\nBoard: SMDK5250\n");
> +#endif
>   return 0;
>  }
>  #endif
> 


applied to u-boot-samsung.

Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] EXYNOS: Correct ordering of SPL machine_params

[Minkyu Kang]

On 19/02/13 15:32, Rajeshwari Shinde wrote:
> From: Simon Glass 
> 
> The mem_manuf is not in the correct order according to the string table.
> This causes cros_bundle_firmware to get the BL2 settings in the wrong
> order. This patch fixes the same.
> 
> Signed-off-by: Simon Glass 
> Signed-off-by: Rajeshwari Shinde 
> ---
>  arch/arm/include/asm/arch-exynos/spl.h |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-exynos/spl.h 
> b/arch/arm/include/asm/arch-exynos/spl.h
> index 306b41d..46b25a6 100644
> --- a/arch/arm/include/asm/arch-exynos/spl.h
> +++ b/arch/arm/include/asm/arch-exynos/spl.h
> @@ -78,11 +78,12 @@ struct spl_machine_param {
>*/
>   u32 uboot_size;
>   enum boot_mode  boot_source;/* Boot device */
> - enum mem_manuf  mem_manuf;  /* Memory Manufacturer */
>   unsignedfrequency_mhz;  /* Frequency of memory in MHz */
>   unsignedarm_freq_mhz;   /* ARM Frequency in MHz */
>   u32 serial_base;/* Serial base address */
>   u32 i2c_base;   /* i2c base address */
> + u32 board_rev_gpios;/* Board revision GPIOs */
> + enum mem_manuf  mem_manuf;  /* Memory Manufacturer */
>  } __attribute__((__packed__));
>  #endif
>  
> 

applied to u-boot-samsung.

Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/13] video: exynos: Add DT support for exynos_fb and exynos_dp drivers

[Minkyu Kang]

Dear Donghwa,

On 22/02/13 18:52, Ajay Kumar wrote:
> Ajay Kumar (13):
>   [PATCH 01/13] video: exynos_fb: Remove callbacks from the driver
>   [PATCH 02/13] video: exynos_dp: Remove callbacks from the driver
>   [PATCH 03/13] video: exynos_fb: Make fimd_ctrl global
>   [PATCH 04/13] EXYNOS: FDT: Add compatible strings for FIMD
>   [PATCH 05/13] video: exynos_fb: add DT support for FIMD driver
>   [PATCH 06/13] EXYNOS5: Add device node for FIMD
>   [PATCH 07/13] SMDK5250: Add device node for FIMD
>   [PATCH 08/13] video: exynos_dp: Make dp_regs global
>   [PATCH 09/13] EXYNOS5: FDT: Add compatible strings for FIMD
>   [PATCH 10/13] video: exynos_dp: Add function to parse DP DT node
>   [PATCH 11/13] EXYNOS5: Add device node for DP
>   [PATCH 12/13] SMDK5250: Add device node for DP
>   [PATCH 13/13] SMDK5250: Use statically defined structures only in non DT 
> case
> 
>  arch/arm/dts/exynos5250.dtsi |  13 ++
>  arch/arm/include/asm/arch-exynos/dp_info.h   |   1 -
>  board/samsung/dts/exynos5250-smdk5250.dts|  40 +
>  board/samsung/smdk5250/smdk5250.c|  16 +-
>  board/samsung/trats/trats.c  |   6 +-
>  board/samsung/universal_c210/universal.c |  23 +--
>  doc/device-tree-bindings/video/exynos-dp.txt |  69 
>  doc/device-tree-bindings/video/exynos-fb.txt |  92 +++
>  drivers/video/exynos_dp.c|  76 -
>  drivers/video/exynos_dp_lowlevel.c   |  69 +++-
>  drivers/video/exynos_dp_lowlevel.h   |   1 +
>  drivers/video/exynos_fb.c| 230 
> +--
>  drivers/video/exynos_fimd.c  |  44 +++--
>  include/fdtdec.h |   2 +
>  include/lcd.h|   9 --
>  lib/fdtdec.c |   2 +
>  16 files changed, 574 insertions(+), 119 deletions(-)
>  create mode 100644 doc/device-tree-bindings/video/exynos-dp.txt
>  create mode 100644 doc/device-tree-bindings/video/exynos-fb.txt
> 

Could you please test this patchset?

Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Nand flash (supports ONFI)

[TigerLiu]

Hi, Jagan:
Got it!
Thank you!
I have downloaded a MT29F16G08A data sheet.

Best wishes,

-邮件原件-
发件人: Jagan Teki [mailto:jagannadh.t...@gmail.com] 
发送时间: 2013年3月11日 19:56
收件人: Tiger Liu
抄送: u-boot@lists.denx.de
主题: Re: [U-Boot] Nand flash (supports ONFI)

Hi,

On Mon, Mar 11, 2013 at 5:06 PM,   wrote:
> Hi, experts:
> I want to know which specific nand chip supports ONFI interface spec?
> I have googled , but not find any product manual.

Spansion ML series and Micron MT29F series flashes have onfi read
parameter page support.

Thanks,
Jagan.

>
> Best wishes,
> ___
> 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 v1] DOS_PBR block type is also valid dos block type.

[Sonic Zhang]

Hi Stephen,

On Tue, Mar 12, 2013 at 1:28 AM, Stephen Warren  wrote:
> On 03/11/2013 03:56 AM, sonic@gmail.com wrote:
>> From: Sonic Zhang 
>>
>> - Should return 0 for both DOS_MBR and DOS_PBR block types in 
>> test_part_dos().
>
> What problem does this solve?
>
> I don't believe this change is correct. The purpose of test_part_dos()
> is to determine whether a block device contains an MS-DOS partition table.
>
> Such a partition table is present in an MBR, but not a PBR. A PBR
> contains a *FAT file-system, and does not include a partition table.

The SD card formated by windows 7 into one FAT partition can't be
initialized correct in u-boot function init_part() after you reuse the
function test_block_type() in function test_part_dos(). So, files on
that partition can't be displayed when running command "fatls mmc 0".

The only difference in your change is to mark dos partition with flag
DOS_PBR invalid.


Regards,

Sonic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 6/7] arm: dra7xx: Add board files for DRA7XX socs

[Lokesh Vutla]

On Tuesday 12 March 2013 12:05 AM, Tom Rini wrote:

On Tue, Feb 12, 2013 at 09:29:08PM -, Lokesh Vutla wrote:


Adding new board files for DRA7XX socs.
The pad registers layout is changed completely from OMAP5
So introducing the new structure here and also adding the
minimal data.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishant Kamat 
Signed-off-by: R Sricharan 
Reviewed-by: Tom Rini 


With the following change to adapt to the omap_mmc_init changes I've
also taken into u-boot-ti/master:

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index cd344da..7bbb549 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -96,8 +96,8 @@ void set_muxconf_regs_essential(void)
  #if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
  int board_mmc_init(bd_t *bis)
  {
-   omap_mmc_init(0, 0, 0);
-   omap_mmc_init(1, 0, 0);
+   omap_mmc_init(0, 0, 0, -1, -1);
+   omap_mmc_init(1, 0, 0, -1, -1);
return 0;
  }
  #endif

This is now applied to u-boot-ti/master, thanks!

Ok..Thanks..

Regards,
Lokesh




___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 6/7] arm: dra7xx: Add board files for DRA7XX socs

[Sricharan R]

On Tuesday 12 March 2013 12:05 AM, Tom Rini wrote:
> On Tue, Feb 12, 2013 at 09:29:08PM -, Lokesh Vutla wrote:
>
>> Adding new board files for DRA7XX socs.
>> The pad registers layout is changed completely from OMAP5
>> So introducing the new structure here and also adding the
>> minimal data.
>>
>> Signed-off-by: Lokesh Vutla 
>> Signed-off-by: Nishant Kamat 
>> Signed-off-by: R Sricharan 
>> Reviewed-by: Tom Rini 
> With the following change to adapt to the omap_mmc_init changes I've
> also taken into u-boot-ti/master:
>
> diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
> index cd344da..7bbb549 100644
> --- a/board/ti/dra7xx/evm.c
> +++ b/board/ti/dra7xx/evm.c
> @@ -96,8 +96,8 @@ void set_muxconf_regs_essential(void)
>  #if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
>  int board_mmc_init(bd_t *bis)
>  {
> - omap_mmc_init(0, 0, 0);
> - omap_mmc_init(1, 0, 0);
> + omap_mmc_init(0, 0, 0, -1, -1);
> + omap_mmc_init(1, 0, 0, -1, -1);
>   return 0;
>  }
>  #endif
>
> This is now applied to u-boot-ti/master, thanks!
>
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Thanks Tom..

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V2] powerpc/85xx: Add workaround for errata USB-14 (enable on P204x/P3041/P50x0)

[xulei]

On P204x/P304x/P50x0 Rev1.0, USB transmit will result in false internal
multi-bit ECC errors, which has impact on performance, so software should
disable all ECC reporting from USB1 and USB2.

In formal release document, the errata number should be USB14 instead of USB138.

Signed-off-by: xulei 
Signed-off-by: Roy Zang 
Signed-off-by: Kumar Gala 
Signed-off-by: xulei 
---
 arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 +++
 arch/powerpc/cpu/mpc85xx/cpu_init.c   |   14 ++
 arch/powerpc/include/asm/config_mpc85xx.h |5 -
 arch/powerpc/include/asm/immap_85xx.h |9 +
 4 files changed, 30 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c 
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 5d72f4c..422782c 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -255,6 +255,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 #ifdef CONFIG_SYS_P4080_ERRATUM_PCIE_A003
puts("Work-around for Erratum PCIe-A003 enabled\n");
 #endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_USB14
+   puts("Work-around for Erratum USB14 enabled\n");
+#endif
return 0;
 }
 
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index de9d916..ab633d0 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -623,6 +623,20 @@ skip_l2:
}
 #endif
 
+#ifdef CONFIG_SYS_FSL_ERRATUM_USB14
+   /* On P204x/P304x/P50x0 Rev1.0, USB transmit will result internal
+* multi-bit ECC errors which has impact on performance, so software
+* should disable all ECC reporting from USB1 and USB2.
+*/
+   if (IS_SVR_REV(get_svr(), 1, 0)) {
+   struct dcsr_dcfg_regs *dcfg = (struct dcsr_dcfg_regs *)
+   (CONFIG_SYS_DCSRBAR + CONFIG_SYS_DCSR_DCFG_OFFSET);
+   setbits_be32(&dcfg->ecccr1,
+   (DCSR_DCFG_ECC_DISABLE_USB1 |
+DCSR_DCFG_ECC_DISABLE_USB2));
+   }
+#endif
+
 #ifdef CONFIG_FMAN_ENET
fman_enet_init();
 #endif
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index d57c178..4236835 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -333,6 +333,7 @@
 #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
 #define CONFIG_SYS_FSL_ERRATUM_NMG_CPU_A011
+#define CONFIG_SYS_FSL_ERRATUM_USB14
 #define CONFIG_SYS_FSL_ERRATUM_CPU_A003999
 #define CONFIG_SYS_FSL_ERRATUM_DDR_A003474
 #define CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER
@@ -365,6 +366,7 @@
 #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
 #define CONFIG_SYS_FSL_ERRATUM_NMG_CPU_A011
+#define CONFIG_SYS_FSL_ERRATUM_USB14
 #define CONFIG_SYS_FSL_ERRATUM_CPU_A003999
 #define CONFIG_SYS_FSL_ERRATUM_DDR_A003474
 #define CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER
@@ -442,6 +444,7 @@
 #define CONFIG_SYS_FSL_USB2_PHY_ENABLE
 #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
+#define CONFIG_SYS_FSL_ERRATUM_USB14
 #define CONFIG_SYS_FSL_ERRATUM_DDR_A003474
 #define CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER
 #define CONFIG_SYS_FSL_SRIO_MAX_PORTS  2
@@ -473,7 +476,7 @@
 #define CONFIG_SYS_FSL_USB2_PHY_ENABLE
 #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
-#define CONFIG_SYS_FSL_ERRATUM_USB138
+#define CONFIG_SYS_FSL_ERRATUM_USB14
 #define CONFIG_SYS_FSL_ERRATUM_DDR_A003
 #define CONFIG_SYS_FSL_ERRATUM_DDR_A003474
 #define CONFIG_SYS_FSL_ERRATUM_A004699
diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index 4eb3f79..a94f748 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -3160,4 +3160,13 @@ struct ccsr_cluster_l2 {
 #define CONFIG_SYS_FSL_CLUSTER_1_L2 \
(CONFIG_SYS_IMMR + CONFIG_SYS_FSL_CLUSTER_1_L2_OFFSET)
 #endif /* CONFIG_SYS_FSL_QORIQ_CHASSIS2 */
+
+#defineCONFIG_SYS_DCSR_DCFG_OFFSET 0X2
+struct dcsr_dcfg_regs {
+   u8  res_0[0x520];
+   u32 ecccr1;
+#defineDCSR_DCFG_ECC_DISABLE_USB1  0x8000
+#defineDCSR_DCFG_ECC_DISABLE_USB2  0x4000
+   u8  res_524[0x1000 - 0x524]; /* 0x524 - 0x1000 */
+};
 #endif /*__IMMAP_85xx__*/
-- 
1.7.0.4


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] I2C: S3C24X0: Bug fixes in i2c_transfer

[Rajeshwari Birje]

Hi Heiko,

Do let me know if you have any comments on this patch.
Would you consider it for I2C branch or should it go through u-boot-samsung?

Regards,
Rajeshwari


On Wed, Mar 6, 2013 at 2:57 PM, Hung-ying Tyan  wrote:
> On Tue, Feb 19, 2013 at 8:19 PM, Rajeshwari Shinde > wrote:
>
>> This patch corrects the following issues
>>
>> 1) Write the correct M/T Stop value to I2CSTAT after i2c write.
>>According to the spec, after finish the data transmission, we should
>>write a M/T Stop (I2C_MODE_MT | I2C_TXRX_ENA) to I2CSTAT instead of
>>a M/R Stop (I2C_MODE_MR | I2C_TXRX_ENA).
>> 2) Not split the write to I2CSTAT into 2 steps in i2c read.
>>According to the spec, we should write the combined M/R Start value to
>>I2CSTAT after setting the slave address to I2CDS
>> 3) Fix the mistake of making an equality check to an assignment.
>>In the case of I2C write with the zero-length address, while tranfering
>> the
>>data, it should be an equality check (==) instead of an assignment (=).
>>
>> Signed-off-by: Tom Wai-Hong Tam 
>> Signed-off-by: Rajeshwari Shinde 
>
>
>  Tested-by: Hung-ying Tyan 
>
> ___
> 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/u-boot

Re: [U-Boot] [PATCH RESEND 0/3] ARM: mmu: Set domain permissions to client access

[Sricharan R]

Hi Albert,

On Tuesday 05 March 2013 11:34 AM, Sricharan R wrote:
> Currently for ARM based cpu's, mmu pagetable attributes are
> set with manager permissions for all 4GB address space.
> Because of this the 'execute never (XN)' permission is
> never checked on read sensitive regions which results in
> speculative aborts.
>
> This series changes the domain permissions of the full 4GB
> space to client access for OMAP socs. This avoids all the
> speculative aborts that are currently seen on OMAP5 secure
> devices.
>
> Tested on OMAP5 SDP (HS) soc.
>
> This is a repost of the older series to include
> Vincent's patch in the same one.
>
> R Sricharan (2):
>   ARM: mmu: Introduce weak dram_bank_setup function
>   ARM: mmu: Set domain permissions to client access
>
> Vincent Stehlé (1):
>   ARM: cache: declare set_section_dcache
>
>  arch/arm/cpu/armv7/cache_v7.c  |3 ++
>  arch/arm/cpu/armv7/omap-common/hwinit-common.c |   35 
> 
>  arch/arm/include/asm/cache.h   |2 ++
>  arch/arm/include/asm/system.h  |   14 ++
>  arch/arm/lib/cache-cp15.c  |   11 +++-
>  5 files changed, 64 insertions(+), 1 deletion(-)
>
 Is this ok to get in now ?

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2 V2] EXYNOS5: Enable Gigabyte device GD25LQ and GD25Q64B

[Rajeshwari Birje]

Hi Minkyu,

Yes it is based on the following patches submitted by Simon Glass and
link for the same.

"sf: Add spi_flash_alloc() to create a new SPI flash struct"
http://patchwork.ozlabs.org/patch/208228/

"sf: Use spi_flash_alloc() in each SPI flash driver":
 http://patchwork.ozlabs.org/patch/226582/

-- 
Regards,
Rajeshwari Shinde

On Fri, Mar 8, 2013 at 6:58 PM, Minkyu Kang  wrote:
> Dear Rajeshwari,
>
> On 23/01/13 15:30, Rajeshwari Shinde wrote:
>> This patch set adds driver for Gigabyte device GD25LQ and GD25Q64B
>> required for Snow board and enables same in config file.
>>
>> Based on following patches submitted by Simon Glass:
>> "sf: Add spi_flash_alloc() to create a new SPI flash struct"
>> "sf: Use spi_flash_alloc() in each SPI flash driver"
>>
>> Changes in V2:
>>   - Added U-Boot copyright header to gigadevice.c
>>   - Removed unnecessary blank lines.
>>
>> Rajeshwari Shinde (2):
>>   SF: Add driver for Gigabyte device GD25LQ and GD25Q64B
>>   SMDK5250: Enable SPI Gigabyte device.
>>Based on following patches submitted by Simon Glass:
>>  drivers/mtd/spi/Makefile |1 +
>>  drivers/mtd/spi/gigadevice.c |   81 
>> ++
>>  drivers/mtd/spi/spi_flash.c  |3 +
>>  drivers/mtd/spi/spi_flash_internal.h |1 +
>>  include/configs/exynos5250-dt.h  |1 +
>>  5 files changed, 87 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/mtd/spi/gigadevice.c
>>
>
> I've got compiler warning and error on this patch.
>
> gigadevice.c: In function 'spi_flash_probe_gigadevice':
> gigadevice.c:68:2: warning: implicit declaration of function 
> 'spi_flash_alloc_base' [-Wimplicit-function-declaration]
> gigadevice.c:68:8: warning: assignment makes pointer from integer without a 
> cast [enabled by default]
> drivers/mtd/spi/libspi_flash.o: In function `spi_flash_probe_gigadevice':
> /home/share/Work/u-boot-samsung/drivers/mtd/spi/gigadevice.c:68: undefined 
> reference to `spi_flash_alloc_base'
>
> There is any dependency with other patches?
> then, please let me know.
>
> Thanks,
> Minkyu Kang.
> ___
> 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 v2 0/4] ARM: atmel: add sama5d3xek board support

[Bo Shen]

This patch series add sama5d3xek board support.

Included features
  - boot from NAND flash, PMECC support, 4bit ECC @ 512 bytes sector
  - boot from SPI flash support
  - boot from SD card support
  - LCD support
  - EMAC support
  - USB support

Will do
  - Add GMAC support
  - Add of control support

Bo Shen (4):
  USB: ohci-at91: support sama5d3x devices
  NET: macb: support sama5d3x devices
  SPI: atmel_spi: support sama5d3x devices
  ARM: atmel: add sama5d3xek support

 MAINTAINERS  |1 +
 arch/arm/cpu/armv7/at91/Makefile |   52 +
 arch/arm/cpu/armv7/at91/clock.c  |  127 
 arch/arm/cpu/armv7/at91/cpu.c|   90 +
 arch/arm/cpu/armv7/at91/reset.c  |   47 +
 arch/arm/cpu/armv7/at91/sama5d3_devices.c|  196 ++
 arch/arm/cpu/armv7/at91/timer.c  |  139 +
 arch/arm/include/asm/arch-at91/at91_common.h |1 +
 arch/arm/include/asm/arch-at91/at91_dbu.h|4 +
 arch/arm/include/asm/arch-at91/at91_pmc.h|   23 +++
 arch/arm/include/asm/arch-at91/clk.h |1 +
 arch/arm/include/asm/arch-at91/hardware.h|2 +
 arch/arm/include/asm/arch-at91/sama5d3.h |  212 
 arch/arm/include/asm/arch-at91/sama5d3_smc.h |   79 
 board/atmel/sama5d3xek/Makefile  |   51 +
 board/atmel/sama5d3xek/sama5d3xek.c  |  277 ++
 boards.cfg   |3 +
 drivers/net/macb.c   |6 +-
 drivers/spi/atmel_spi.c  |3 +-
 drivers/usb/host/ohci-at91.c |   14 +-
 include/configs/sama5d3xek.h |  255 
 21 files changed, 1578 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/at91/Makefile
 create mode 100644 arch/arm/cpu/armv7/at91/clock.c
 create mode 100644 arch/arm/cpu/armv7/at91/cpu.c
 create mode 100644 arch/arm/cpu/armv7/at91/reset.c
 create mode 100644 arch/arm/cpu/armv7/at91/sama5d3_devices.c
 create mode 100644 arch/arm/cpu/armv7/at91/timer.c
 create mode 100644 arch/arm/include/asm/arch-at91/sama5d3.h
 create mode 100644 arch/arm/include/asm/arch-at91/sama5d3_smc.h
 create mode 100644 board/atmel/sama5d3xek/Makefile
 create mode 100644 board/atmel/sama5d3xek/sama5d3xek.c
 create mode 100644 include/configs/sama5d3xek.h

-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [Patch v2 1/4] USB: ohci-at91: support sama5d3x devices

[Bo Shen]

Add OHCI support for sama5d3x devices

Signed-off-by: Bo Shen 
---
change in v2:
  - change #if defined to #ifdef for sama5d3
---
 drivers/usb/host/ohci-at91.c |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index efd711d..086cd0f 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -42,7 +42,7 @@ int usb_cpu_init(void)
while ((readl(&pmc->sr) & AT91_PMC_LOCKB) != AT91_PMC_LOCKB)
;
 #elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \
-   defined(CONFIG_AT91SAM9X5)
+   defined(CONFIG_AT91SAM9X5) || defined(CONFIG_SAMA5D3)
/* Enable UPLL */
writel(readl(&pmc->uckr) | AT91_PMC_UPLLEN | AT91_PMC_BIASEN,
&pmc->uckr);
@@ -54,7 +54,12 @@ int usb_cpu_init(void)
 #endif
 
/* Enable USB host clock. */
+#ifdef CONFIG_SAMA5D3
+   writel(1 << (ATMEL_ID_UHP - 32), &pmc->pcer1);
+#else
writel(1 << ATMEL_ID_UHP, &pmc->pcer);
+#endif
+
 #ifdef CONFIG_AT91SAM9261
writel(ATMEL_PMC_UHP | AT91_PMC_HCK0, &pmc->scer);
 #else
@@ -69,7 +74,12 @@ int usb_cpu_stop(void)
at91_pmc_t *pmc = (at91_pmc_t *)ATMEL_BASE_PMC;
 
/* Disable USB host clock. */
+#ifdef CONFIG_SAMA5D3
+   writel(1 << (ATMEL_ID_UHP - 32), &pmc->pcdr1);
+#else
writel(1 << ATMEL_ID_UHP, &pmc->pcdr);
+#endif
+
 #ifdef CONFIG_AT91SAM9261
writel(ATMEL_PMC_UHP | AT91_PMC_HCK0, &pmc->scdr);
 #else
@@ -83,7 +93,7 @@ int usb_cpu_stop(void)
while ((readl(&pmc->sr) & AT91_PMC_LOCKB) != 0)
;
 #elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \
-   defined(CONFIG_AT91SAM9X5)
+   defined(CONFIG_AT91SAM9X5) || defined(CONFIG_SAMA5D3)
/* Disable UPLL */
writel(readl(&pmc->uckr) & (~AT91_PMC_UPLLEN), &pmc->uckr);
while ((readl(&pmc->sr) & AT91_PMC_LOCKU) == AT91_PMC_LOCKU)
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [Patch v2 2/4] NET: macb: support sama5d3x devices

[Bo Shen]

Add macb support for sama5d3x devices

Signed-off-by: Bo Shen 
---
change in v2:
  No change
---
 drivers/net/macb.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 8bacbda..9e7fbc6 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -469,7 +469,8 @@ static int macb_init(struct eth_device *netdev, bd_t *bd)
 #ifdefined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \
defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) || \
defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \
-   defined(CONFIG_AT91SAM9XE) || defined(CONFIG_AT91SAM9X5)
+   defined(CONFIG_AT91SAM9XE) || defined(CONFIG_AT91SAM9X5) || \
+   defined(CONFIG_SAMA5D3)
macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN));
 #else
macb_writel(macb, USRIO, 0);
@@ -478,7 +479,8 @@ static int macb_init(struct eth_device *netdev, bd_t *bd)
 #ifdefined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \
defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) || \
defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \
-   defined(CONFIG_AT91SAM9XE) || defined(CONFIG_AT91SAM9X5)
+   defined(CONFIG_AT91SAM9XE) || defined(CONFIG_AT91SAM9X5) || \
+   defined(CONFIG_SAMA5D3)
macb_writel(macb, USRIO, MACB_BIT(CLKEN));
 #else
macb_writel(macb, USRIO, MACB_BIT(MII));
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [Patch v2 3/4] SPI: atmel_spi: support sama5d3x devices

[Bo Shen]

Add WDRBT bit support for sama5d3x devices

Signed-off-by: Bo Shen 
---
Change in v2:
  no change
---
 drivers/spi/atmel_spi.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/atmel_spi.c b/drivers/spi/atmel_spi.c
index ce7d460..5e97225 100644
--- a/drivers/spi/atmel_spi.c
+++ b/drivers/spi/atmel_spi.c
@@ -92,7 +92,8 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned 
int cs,
as->slave.cs = cs;
as->regs = regs;
as->mr = ATMEL_SPI_MR_MSTR | ATMEL_SPI_MR_MODFDIS
-#if defined(CONFIG_AT91SAM9X5) || defined(CONFIG_AT91SAM9M10G45)
+#if defined(CONFIG_AT91SAM9X5) || defined(CONFIG_AT91SAM9M10G45) || \
+   defined(CONFIG_SAMA5D3)
| ATMEL_SPI_MR_WDRBT
 #endif
| ATMEL_SPI_MR_PCS(~(1 << cs) & 0xf);
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [Patch v2 4/4] ARM: atmel: add sama5d3xek support

[Bo Shen]

Add sama5d3xek support with following feature
  - boot from NAND flash, PMECC support, 4bit ECC @ 512 bytes sector
  - boot from SPI flash support
  - boot from SD card support
  - LCD support
  - EMAC support
  - USB support (OHCI)

Signed-off-by: Bo Shen 
---
Change in v2:
  - Remove unneeded #undef
  - Using string directly
  - Add missed copyright
  - Using pull up for usart Tx line
  - Using pull up for spi cs
  - make code more readable in clock.c file
  - move LCD higher 8 bit to board file (This is board related)
---
 MAINTAINERS  |1 +
 arch/arm/cpu/armv7/at91/Makefile |   52 +
 arch/arm/cpu/armv7/at91/clock.c  |  127 
 arch/arm/cpu/armv7/at91/cpu.c|   90 +
 arch/arm/cpu/armv7/at91/reset.c  |   47 +
 arch/arm/cpu/armv7/at91/sama5d3_devices.c|  196 ++
 arch/arm/cpu/armv7/at91/timer.c  |  139 +
 arch/arm/include/asm/arch-at91/at91_common.h |1 +
 arch/arm/include/asm/arch-at91/at91_dbu.h|4 +
 arch/arm/include/asm/arch-at91/at91_pmc.h|   23 +++
 arch/arm/include/asm/arch-at91/clk.h |1 +
 arch/arm/include/asm/arch-at91/hardware.h|2 +
 arch/arm/include/asm/arch-at91/sama5d3.h |  212 
 arch/arm/include/asm/arch-at91/sama5d3_smc.h |   79 
 board/atmel/sama5d3xek/Makefile  |   51 +
 board/atmel/sama5d3xek/sama5d3xek.c  |  277 ++
 boards.cfg   |3 +
 include/configs/sama5d3xek.h |  255 
 18 files changed, 1560 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/at91/Makefile
 create mode 100644 arch/arm/cpu/armv7/at91/clock.c
 create mode 100644 arch/arm/cpu/armv7/at91/cpu.c
 create mode 100644 arch/arm/cpu/armv7/at91/reset.c
 create mode 100644 arch/arm/cpu/armv7/at91/sama5d3_devices.c
 create mode 100644 arch/arm/cpu/armv7/at91/timer.c
 create mode 100644 arch/arm/include/asm/arch-at91/sama5d3.h
 create mode 100644 arch/arm/include/asm/arch-at91/sama5d3_smc.h
 create mode 100644 board/atmel/sama5d3xek/Makefile
 create mode 100644 board/atmel/sama5d3xek/sama5d3xek.c
 create mode 100644 include/configs/sama5d3xek.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 175bbe2..cd3cbaf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -910,6 +910,7 @@ Matt Sealey 
 
 Bo Shen 
at91sam9x5ekARM926EJS (AT91SAM9G15,G25,G35,X25,X35 SoC)
+   sama5d3xek  ARMV7 (SAMA5D31, D33, D34, D35 SoC)
 
 Michal Simek 
 
diff --git a/arch/arm/cpu/armv7/at91/Makefile b/arch/arm/cpu/armv7/at91/Makefile
new file mode 100644
index 000..040c67d
--- /dev/null
+++ b/arch/arm/cpu/armv7/at91/Makefile
@@ -0,0 +1,52 @@
+#
+# (C) Copyright 2000-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2013
+# Bo Shen 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# 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 $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(SOC).o
+
+COBJS-$(CONFIG_SAMA5D3)+= sama5d3_devices.o
+COBJS-y += clock.o
+COBJS-y += cpu.o
+COBJS-y += reset.o
+COBJS-y += timer.o
+
+SRCS:= $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+OBJS:= $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
+
+all:   $(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/arch/arm/cpu/armv7/at91/clock.c b/arch/arm/cpu/armv7/at91/clock.c
new file mode 100644
index 000..552c118
--- /dev/null
+++ b/arch/arm/cpu/armv7/at91/clock.c
@@ -0,0 +1,127 @@
+/*
+ * [origin: Linux kernel linux/arch/arm/mach-at91/clock.c]
+ *
+ * Copyright (C) 2005 David Brownell
+ * Copyright (C) 2005 Ivan Kokshaysky
+ * Copyright (C) 2009 Jean-Christophe PLAGNIOL-VILLARD 
+ * Copyright (C) 2013 Bo Shen 
+ *
+ * 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 o

Re: [U-Boot] [PATCH V7 01/10] FDT: Add compatible string for DWMMC

[Amarendra Reddy]

Hi Simon,

I am not planning to resend the series untill a re-base is required.

Thanks & Regards
Amarendra reddy

On 11 March 2013 22:04, Simon Glass  wrote:

> Hi Amar,
>
> On Tue, Mar 5, 2013 at 5:11 AM, Amar  wrote:
>
> > Add required compatible information for DWMMC driver.
> >
> > Signed-off-by: Vivek Gautam 
> > Signed-off-by: Amar 
> > Acked-by: Jaehoon Chung 
> > ---
>


> > Changes since V1:
> > No change.
> >
> > Changes since V2:
> > 1)Updation of commit message and resubmition of proper patch set.
> >
> > Changes since V3:
> > No change.
> >
> > Changes since V4:
> > No change.
> >
> > Changes since V5:
> > No change.
> >
> >  include/fdtdec.h | 1 +
> >  lib/fdtdec.c | 1 +
> >  2 files changed, 2 insertions(+)
> >
> > diff --git a/include/fdtdec.h b/include/fdtdec.h
> > index 77f244f..51ff266 100644
> > --- a/include/fdtdec.h
> > +++ b/include/fdtdec.h
> > @@ -81,6 +81,7 @@ enum fdt_compat_id {
> > COMPAT_SAMSUNG_EXYNOS_EHCI, /* Exynos EHCI controller */
> > COMPAT_SAMSUNG_EXYNOS_USB_PHY,  /* Exynos phy controller for
> > usb2.0 */
> > COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
> > +   COMPAT_SAMSUNG_EXYNOS5_DWMMC,   /* Exynos5 DWMMC controller */
> >
> > COMPAT_COUNT,
> >  };
> > diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> > index 3ae348d..856f90c 100644
> > --- a/lib/fdtdec.c
> > +++ b/lib/fdtdec.c
> > @@ -56,6 +56,7 @@ static const char * const compat_names[COMPAT_COUNT] =
> {
> > COMPAT(SAMSUNG_EXYNOS_EHCI, "samsung,exynos-ehci"),
> > COMPAT(SAMSUNG_EXYNOS_USB_PHY, "samsung,exynos-usb-phy"),
> > COMPAT(MAXIM_MAX77686_PMIC, "maxim,max77686_pmic"),
> > +   COMPAT(SAMSUNG_EXYNOS5_DWMMC, "samsung,exynos5250-dwmmc"),
> >  };
> >
> >  const char *fdtdec_get_compatible(enum fdt_compat_id id)
> >
>
> Will you be resending this series?
>
> Regards,
> Simon
>
>
> > --
> > 1.8.0
> >
> >
>
> ___
> 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