Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat driver

[Chris Kiick]

Hi,
  Thanks for the reply. This is my first patch to u-boot. Any advice is 
appreciated. Comments in-line below.

 
- Original Message 

> From: Scott Wood 
> To: Chris Kiick 
> Cc: u-boot@lists.denx.de
> Sent: Wed, December 19, 2012 1:02:52 PM
> Subject: Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat 
>driver
> 
> On 12/18/2012 05:27:00 PM, Chris Kiick wrote:
> > Allow boards to set their  own ECC layouts and functions in NAND_PLAT_INIT
> > without being stomped on  by nand_base.c intialization.
> > 
> > Signed-off-by: ckiick 
> > ---
> >  drivers/mtd/nand/nand_base.c |11 +++
> >  drivers/mtd/nand/nand_plat.c |4  ++--
> >  include/configs/qong.h   |2  +-
> >  3 files changed, 10 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/nand_base.c  b/drivers/mtd/nand/nand_base.c
> > index a2d06be..614fc72 100644
> > ---  a/drivers/mtd/nand/nand_base.c
> > +++  b/drivers/mtd/nand/nand_base.c
> > @@ -3035,8 +3035,10 @@ int  nand_scan_tail(struct mtd_info *mtd)
> >   chip->ecc.mode = NAND_ECC_SOFT;
> > 
> >  case  NAND_ECC_SOFT:
> > -chip->ecc.calculate =  nand_calculate_ecc;
> > -chip->ecc.correct =  nand_correct_data;
> > +if  (!chip->ecc.calculate)
> > + chip->ecc.calculate = nand_calculate_ecc;
> > + if (!chip->ecc.correct)
> > + chip->ecc.correct = nand_correct_data;
> >   chip->ecc.read_page = nand_read_page_swecc;
> >   chip->ecc.read_subpage =  nand_read_subpage;
> >   chip->ecc.write_page = nand_write_page_swecc;
> > @@ -3044,9 +3046,10 @@  int nand_scan_tail(struct mtd_info *mtd)
> >   chip->ecc.write_page_raw = nand_write_page_raw;
> >   chip->ecc.read_oob = nand_read_oob_std;
> >   chip->ecc.write_oob = nand_write_oob_std;
> >  -if (!chip->ecc.size)
> > + if (!chip->ecc.size) {
> >   chip->ecc.size = 256;
> > - chip->ecc.bytes = 3;
> > + chip->ecc.bytes = 3;
> > + }
> >  break;
> > 
> >   case NAND_ECC_SOFT_BCH:
> 
> How is this part specific to nand  plat?

OK, it's not, but if you are using nand plat, then you are forced to go through 
this code path with no chance of making any changes after because of the way 
board_nand_init() is written. I seem to see  other nand drivers setting up ecc 
layouts and then calling nand_scan_tail(), I'm not sure how they are  getting 
around this.
I reasoned that the change was safe for existing code because if something was 
not setting its own ecc layout, it would still use the default, but it if was, 
then it had to be after the call to nand_scan_tail() and that would override 
whatever was set there anyway.

> I'm not sure how specifying your own ECC functions fits with the  purpose of 
>either NAND_ECC_SOFT or nand plat.
Well, NAND_ECC_SOFT is the only scheme that does fit with custom ECC 
algorithms. 
You have to pick one of the existing ECC schemes, and SOFT is the scheme that 
allows you to do your own ECC, if you setup the layout, calculate and correct 
parts. Looking at the code, that's what I thought it was for.

Is there another way to implement custom ECC algorithms, done in software?

As for the plat driver, it shouldn't care what ECC I'm using.  It's just 
running 
the low-level byte-bang part of the driver for me, so I don't have to duplicate 
the code. Isn't that its purpose?  Do I have to re-write a driver interface 
that 
does the same thing as nand plat just because my ECC isn't the default?

If I'm going in the wrong direction, I'd appreciate advice on how it's supposed 
to be done.

> > diff --git  a/drivers/mtd/nand/nand_plat.c b/drivers/mtd/nand/nand_plat.c
> > index  37a0206..b3bda11 100644
> > --- a/drivers/mtd/nand/nand_plat.c
> > +++  b/drivers/mtd/nand/nand_plat.c
> > @@ -8,7 +8,7 @@
> >  /* Your  board must implement the following macros:
> >   *   NAND_PLAT_WRITE_CMD(chip, cmd)
> >   *  NAND_PLAT_WRITE_ADR(chip,  cmd)
> > - *  NAND_PLAT_INIT()
> > + *   NAND_PLAT_INIT(nand)
> >   *
> >   * It may also implement the  following:
> >   *  NAND_PLAT_DEV_READY(chip)
> > @@ -53,7  +53,7 @@ int board_nand_init(struct nand_chip *nand)
> >   #endif
> > 
> >  #ifdef NAND_PLAT_INIT
> > - NAND_PLAT_INIT();
> > +NAND_PLAT_INIT(nand);
> >   #endif
> > 
> >  nand->cmd_ctrl =  plat_cmd_ctrl;
> > diff --git a/include/configs/qong.h  b/include/configs/qong.h
> > index d9bf201..077cbae 100644
> > ---  a/include/configs/qong.h
> > +++ b/include/configs/qong.h
> > @@ -226,7  +226,7 @@ extern int qong_nand_rdy(void *chip);
> >  #define  CONFIG_NAND_PLAT
> >  #define CONFIG_SYS_MAX_NAND_DEVICE  1
> >  #define CONFIG_SYS_NAND_BASECS3_BASE
> >  -#define NAND_PLAT_INIT() qong_nand_plat_init(nand)
> > +#define  NAND_PLAT_INIT(nand) qong_nand_plat_init(nand)
> > 
> >  #define  QONG_NAND_CLE(chip) ((unsigned long)(chip)->IO_ADDR_W | (1 <<  
24))
> >  #define QONG_NAND_ALE(chip) ((unsigned  long)

Re: [U-Boot] [PATCH] mv-common.h: increase malloc arena to 4MiB

[Prafulla Wadaskar]

> -Original Message-
> From: Andreas Bießmann [mailto:andreas.de...@googlemail.com]
> Sent: 30 October 2012 05:29
> To: U-Boot List
> Cc: Andreas Bießmann; Prafulla Wadaskar; dimax.m...@gmail.com
> Subject: [PATCH] mv-common.h: increase malloc arena to 4MiB
> 
> This will fix the following error:
> 
> ---8<---
> UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume
> 'ubi:root' errno=-12!
> --->8---
> 
> Signed-off-by: Andreas Bießmann 
> Cc: prafu...@marvell.com
> Cc: dimax.m...@gmail.com
> ---
>  include/configs/mv-common.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/mv-common.h b/include/configs/mv-common.h
> index 7086d1d..405a842 100644
> --- a/include/configs/mv-common.h
> +++ b/include/configs/mv-common.h
> @@ -92,7 +92,7 @@
>  /*
>   * Size of malloc() pool
>   */
> -#define CONFIG_SYS_MALLOC_LEN(1024 * 1024) /* 1MiB for malloc()
> */
> +#define CONFIG_SYS_MALLOC_LEN(1024 * 1024 * 4) /* 4MiB for
> malloc() */
> 
>  /*
>   * Other required minimal configurations
> --
> 1.7.10.4

Applied to u-boot-marvell.git master branch

Regards...
Prafulla . . .

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

Re: [U-Boot] [PATCH] mv-common.h: increase malloc arena to 4MiB

[Andreas Bießmann]

Dear Prafulla Wadaskar,

On 20.12.2012 10:31, Prafulla Wadaskar wrote:
> 
> 
>> -Original Message-
>> From: Andreas Bießmann [mailto:andreas.de...@googlemail.com]
>> Sent: 30 October 2012 05:29
>> To: U-Boot List
>> Cc: Andreas Bießmann; Prafulla Wadaskar; dimax.m...@gmail.com
>> Subject: [PATCH] mv-common.h: increase malloc arena to 4MiB
>>
>> This will fix the following error:
>>
>> ---8<---
>> UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume
>> 'ubi:root' errno=-12!
>> --->8---



> Applied to u-boot-marvell.git master branch

I've just seen you requested a pull before this add. Would be great to
have this patch in 2013.01

Best regards

Andreas Bießmann

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

Re: [U-Boot] [PATCH] mv-common.h: increase malloc arena to 4MiB

[Prafulla Wadaskar]

> -Original Message-
> From: Andreas Bießmann [mailto:andreas.de...@googlemail.com]
> Sent: 20 December 2012 15:19
> To: Prafulla Wadaskar
> Cc: Andreas Bießmann; U-Boot List; dimax.m...@gmail.com
> Subject: Re: [PATCH] mv-common.h: increase malloc arena to 4MiB
> 
> Dear Prafulla Wadaskar,
> 
> On 20.12.2012 10:31, Prafulla Wadaskar wrote:
> >
> >
> >> -Original Message-
> >> From: Andreas Bießmann [mailto:andreas.de...@googlemail.com]
> >> Sent: 30 October 2012 05:29
> >> To: U-Boot List
> >> Cc: Andreas Bießmann; Prafulla Wadaskar; dimax.m...@gmail.com
> >> Subject: [PATCH] mv-common.h: increase malloc arena to 4MiB
> >>
> >> This will fix the following error:
> >>
> >> ---8<---
> >> UBIFS error (pid 0): ubifs_mount: Error reading superblock on
> volume
> >> 'ubi:root' errno=-12!
> >> --->8---
> 
> 
> 
> > Applied to u-boot-marvell.git master branch
> 
> I've just seen you requested a pull before this add. Would be great to
> have this patch in 2013.01
> 
> Best regards
> 
> Andreas Bießmann

Dear Andreas,
Sure
I will resend the pull request.

Regards...
Prafulla . . .

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

Re: [U-Boot] Pull request for u-boot-marvell.git

[Prafulla Wadaskar]

Dear Albert
Please discard my earlier pull request and please pull
The following changes since commit b8a7c467960ffb4d5a5e1eef5f7783fb6f594542:
  Albert ARIBAUD (1):
Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'

are available in the git repository at:

  u-boot-marvell.git master branch.

Albert ARIBAUD (3):
  mv88e61xx: refactor PHY and SWITCH level-code
  kirkwood: make MPP arrays static const
  ARM: lacie_kw: add support for WIRELESS_SPACE

Holger Brunck (3):
  arm/km: fix memory settings
  km/common: drop unneeded std* environment variables
  km/common: cosmetic change reported from checkpatch

Luke Lowrey (1):
  arch-kirkwood: Ethernet port macro returning incorrect address

Michael Walle (1):
  lsxl: unset ncip for rescue mode

Valentin Longchamp (1):
  arm/km: remove duplicate code

andreas.de...@googlemail.com (1):
  mv-common.h: increase malloc arena to 4MiB

 arch/arm/cpu/arm926ejs/kirkwood/mpp.c   |2 +-
 arch/arm/include/asm/arch-kirkwood/cpu.h|2 +-
 arch/arm/include/asm/arch-kirkwood/mpp.h|2 +-
 board/LaCie/net2big_v2/net2big_v2.c |2 +-
 board/LaCie/netspace_v2/netspace_v2.c   |2 +-
 board/LaCie/wireless_space/Makefile |   46 +++
 board/LaCie/wireless_space/kwbimage.cfg |   82 
 board/LaCie/wireless_space/wireless_space.c |  176 
 board/Marvell/dreamplug/dreamplug.c |2 +-
 board/Marvell/guruplug/guruplug.c   |2 +-
 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |2 +-
 board/Marvell/openrd/openrd.c   |2 +-
 board/Marvell/rd6281a/rd6281a.c |2 +-
 board/Marvell/sheevaplug/sheevaplug.c   |2 +-
 board/Seagate/dockstar/dockstar.c   |2 +-
 board/buffalo/lsxl/lsxl.c   |7 +-
 board/cloudengines/pogo_e02/pogo_e02.c  |2 +-
 board/d-link/dns325/dns325.c|2 +-
 board/iomega/iconnect/iconnect.c|2 +-
 board/karo/tk71/tk71.c  |2 +-
 board/keymile/common/common.c   |2 +-
 board/keymile/km_arm/km_arm.c   |   16 +-
 board/keymile/km_arm/kwbimage-memphis.cfg   |6 +-
 board/keymile/km_arm/kwbimage.cfg   |6 +-
 board/keymile/km_arm/kwbimage_128M16_1.cfg  |   25 +-
 board/keymile/km_arm/kwbimage_256M8_1.cfg   |   25 +-
 board/raidsonic/ib62x0/ib62x0.c |2 +-
 boards.cfg  |1 +
 drivers/net/phy/mv88e61xx.c |  495 ++
 drivers/net/phy/mv88e61xx.h |   39 ++-
 drivers/spi/kirkwood_spi.c  |   12 +-
 include/configs/km/keymile-common.h |3 -
 include/configs/lsxl.h  |2 +-
 include/configs/mv-common.h |2 +-
 include/configs/wireless_space.h|  194 +
 include/netdev.h|   21 +-
 36 files changed, 896 insertions(+), 298 deletions(-)
 create mode 100644 board/LaCie/wireless_space/Makefile
 create mode 100644 board/LaCie/wireless_space/kwbimage.cfg
 create mode 100644 board/LaCie/wireless_space/wireless_space.c
 create mode 100644 include/configs/wireless_space.h

Regards...
Prafulla . . .


> -Original Message-
> From: Prafulla Wadaskar
> Sent: 20 December 2012 12:27
> To: 'Albert ARIBAUD'
> Cc: 'u-boot@lists.denx.de'; Ashish Karkare; Prabhanjan Sarnaik;
> 'Wolfgang Denk'
> Subject: Pull request for u-boot-marvell.git
> 
> Dear Albert,
> 
> Please pull
> The following changes since commit
> b8a7c467960ffb4d5a5e1eef5f7783fb6f594542:
>   Albert ARIBAUD (1):
> Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'
> 
> are available in the git repository at:
> 
>   u-boot-marvell.git master branch.
> 
> Albert ARIBAUD (3):
>   mv88e61xx: refactor PHY and SWITCH level-code
>   kirkwood: make MPP arrays static const
>   ARM: lacie_kw: add support for WIRELESS_SPACE
> 
> Holger Brunck (3):
>   arm/km: fix memory settings
>   km/common: drop unneeded std* environment variables
>   km/common: cosmetic change reported from checkpatch
> 
> Valentin Longchamp (1):
>   arm/km: remove duplicate code
> 
>  arch/arm/cpu/arm926ejs/kirkwood/mpp.c   |2 +-
>  arch/arm/include/asm/arch-kirkwood/mpp.h|2 +-
>  board/LaCie/net2big_v2/net2big_v2.c |2 +-
>  board/LaCie/netspace_v2/netspace_v2.c   |2 +-
>  board/LaCie/wireless_space/Makefile |   46 +++
>  board/LaCie/wireless_space/kwbimage.cfg |   82 
>  board/LaCie/wireless_space/wireless_space.c |  176 
>  board/Marvell/dreamplug/dreamplug.c |2 +-
>  board/Marvell/guruplug/guruplug.c   |2 +-
>  board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |2 +

[U-Boot] [PATCH] lcd: restore ability to display 8 bpp BMPs on 16 bpp LCDs

[Nikita Kiryanov]

Commit fb6a9aab7ae78c (LCD: display 32bpp decompressed bitmap image)
broke the check that allowed U-Boot to display 8 bpp BMPs on a 16
bpp LCD screen, effectively turning this feature off.

Restore this feature by changing the check back to the same meaning
it originally had.
To avoid future confusion, the check has also been rephrased to make
its meaning clear.

Signed-off-by: Nikita Kiryanov 
Signed-off-by: Igor Grinberg 
---
 common/lcd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/lcd.c b/common/lcd.c
index 4c83a8b..cfa1134 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -834,7 +834,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
}
 
/* We support displaying 8bpp BMPs on 16bpp LCDs */
-   if (bpix != bmp_bpix && (bmp_bpix != 8 || bpix != 16 || bpix != 32)) {
+   if (bpix != bmp_bpix && !(bmp_bpix == 8 && bpix == 16)) {
printf ("Error: %d bit/pixel mode, but BMP has %d bit/pixel\n",
bpix,
le16_to_cpu(bmp->header.bit_count));
-- 
1.7.10.4

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

Re: [U-Boot] [PATCH 1/4] Optimized nand_read_buf for kirkwood

[Phil Sutter]

Hi Prafulla,

On Wed, Dec 19, 2012 at 10:44:01PM -0800, Prafulla Wadaskar wrote:
> For your next post of this patch, please do not forget to add version info 
> and changlog to the patch.

Ah yes, indeed! Thanks a lot for the hint and sorry for the confusion
caused.

Best wishes, Phil

-- 
Viprinet Europe GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany

Phone/Zentrale:   +49 6721 49030-0
Direct line/Durchwahl:+49 6721 49030-134
Fax:  +49 6721 49030-109

phil.sut...@viprinet.com
http://www.viprinet.com

Registered office/Sitz der Gesellschaft: Bingen am Rhein, Germany
Commercial register/Handelsregister: Amtsgericht Mainz HRB44090
CEO/Geschäftsführer: Simon Kissel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] please pull u-boot-samsung/resolve

[Albert ARIBAUD]

Hi Stephen,

On Wed, 19 Dec 2012 23:24:07 -0700, Stephen Warren
 wrote:
> On 12/19/2012 10:59 PM, Minkyu Kang wrote:
> > Dear Albert and Stephen,
> > 
> > On 20/12/12 01:28, Albert ARIBAUD wrote:
> ...
> >> Can you answer the question Stephen has asked on this list on 11/12 ?
> >>
> >> 
> > 
> > Comes from u-boot-arm tree.
> > The base of this pull request is u-boot tree, hence some u-boot-arm commits 
> > are included.
> > But it doesn't matter maybe.. because this pull request is for u-boot-arm 
> > tree.
> 
> OK, that might explain it, but isn't there a way to list only the new
> commits?

Yes there is, because when doing the pull request, you don't care where
commits come from, you only care where they'll be pulled into. IOW,
there is no notion of a 'base' for a pull request: you just specify the
destination -- here, u-boot-arm -- and that prints only the needed
commits.

Since pull requests do nothing more than print on the standard output,
and in order to speed my merging, I'll fetch u-boot-samsung and perform
a local pull request from -samsung/master onto -arm/master and check
that the resulting commits are ok.

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

Re: [U-Boot] split nand writes

[Jaap de Jong]

On 12/19/2012 11:47 PM, Scott Wood wrote:

On 12/19/2012 09:43:01 AM, Jaap de Jong wrote:

Hi All,
suppose the image I want to flash is bigger than the available ram in
the unit.
Is there a way to copy the image f.i. in pieces into the flash?
nand write should have a 'continue on last block' option for that
purpose.

Something like that would be nice.

These patches are relevant:
http://patchwork.ozlabs.org/patch/204939/
http://patchwork.ozlabs.org/patch/204940/

That could do the trick also. You would have to do some arithmetic to 
calculate the next startaddress in the flash.

So there is not an out-of-the-box solution at the moment?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Bricked when trying to attach UBI

[Holger Brunck]

Hi Luca,

On 12/19/2012 06:37 PM, Luca Ceresoli wrote:
> I had some days ago, but I double-checked now as you suggested. Indeed
> there is an important difference: attach_by_scanning() (build.c) calls
> ubi_wl_init_scan() and ubi_eba_init_scan() just like Linux does, but in
> a swapped order!
> 
> This swap dates back to:
> 
> commit d63894654df72b010de2abb4b3f07d0d755f65b6
> Author: Holger Brunck 
> Date:   Mon Oct 10 13:08:19 2011 +0200
> 
> UBI: init eba tables before wl when attaching a device
> 
> This fixes that u-boot gets stuck when a bitflip was detected
> during "ubi part ". If a bitflip was detected UBI tries
> to copy the PEB to a different place. This needs that the eba table
> are initialized, but this was done after the wear levelling worker
> detects the bitflip. So changes the initialisation of these two
> tasks in u-boot.
> 
> This is a u-boot specific patch and not needed in the linux layer,
> because due to commit 1b1f9a9d00447d
> UBI: Ensure that "background thread" operations are really executed
> we schedule these tasks in place and not as in linux after the inital
> task which schedule this new task is finished.
> 
> Signed-off-by: Holger Brunck 
> cc: Stefan Roese 
> Signed-off-by: Stefan Roese 
> 
> I tried reverting that commit and... surprise! U-Boot can now attach UBI
> and boot properly!
> 

:-(

> But the cited commit actually fixed a bug that bite our board a few
> months back, so it should not be reverted without thinking twice. Now
> it apparently introduced another bug. :-(
> 

yes definetely.

I didn't read the whole thread, so I don't know what your exact problem is. On
my boards the ubi layer seems to work fine on latest u-boot. But I see a general
problem we have in the ubi layer in u-boot. I try to summarize my view:

The UBI layer was initialy copied from the linux implementation. But the linux
implementation relies for some tasks e.g. fix correctable errors on a background
thread. Due to the fact that u-boot is single threaded there was one commit
which wants to take care that these background tasks are really executed (CC-ing
the author):
commit 1b1f9a9d00  UBI: Ensure that "background thread" operations are really
executed

U-boot executes this background taks immediately but the linux implementation
executes this tasks later with the help of some synchronisation mechanism.
Therefore we have a different order executing these tasks. My fix did now a
change in the initialisation order of eba tables and the wear leveling thread,
to address my problem. But now it seems to cause a new problem on your side.

So the synchronisation mechanism in u-boot for the ubi tasks which are running
on linux in background is incorrect. But how this could be fixed needs to have
some deeper analyses.

Regards
Holger

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

Re: [U-Boot] configuring u-boot for custom board based on beaglebone(am335xx_evm)

[Pavan]

Hi all,

  i am using u-boot-2013.02.rc2 and cross-compiling for target
am335x_evm_uart2_config target its creating MLO and u-boot.img for my
target.buts its not booting on uart2.

is there any configuration i need to change in u-boot source code?

Thanks

Regards
Pavan



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/configuring-u-boot-for-custom-board-based-on-beaglebone-am335xx-evm-tp143228p143311.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V3 0/4] Add support for FIMD and DP on SMDK5250

[Ajay Kumar]

Changes since V2:
-- Add dummy definition to fix compilation dependency on
   CONFIG_EXYNOS_MIPI_DSIM.
-- Create and use new config CONFIG_EXYNOS_LOGO instead of using
   CONFIG_CMD_BMP
-- Remove explicit call for cfg_lcd_gpio and add it as callback.

 [PATCH RESEND V2 1/4] EXYNOS5: Change parent clock of FIMD to MPLL
 [PATCH V3 2/4] EXYNOS: Add dummy definition to fix compilation dependency on
CONFIG_EXYNOS_MIPI_DSIM
 [PATCH V3 3/4] video: Modify exynos_fimd driver to support LCD console
 [PATCH V3 4/4]EXYNOS5: Add support for FIMD and DP

 arch/arm/cpu/armv7/exynos/clock.c|2 +-
 arch/arm/include/asm/arch-exynos/mipi_dsim.h |7 ++
 board/samsung/smdk5250/smdk5250.c|   97 ++
 drivers/video/exynos_fb.c|5 +-
 drivers/video/exynos_fimd.c  |   10 ++-
 include/configs/smdk5250.h   |8 ++
 include/configs/trats.h  |1 +
 7 files changed, 126 insertions(+), 4 deletions(-)

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

[U-Boot] [PATCH V3 2/4] EXYNOS: Add dummy definition to fix compilation dependency on CONFIG_EXYNOS_MIPI_DSIM

[Ajay Kumar]

When only DP is used, we need not enable CONFIG_EXYNOS_MIPI_DSIM.
But if we do not select CONFIG_EXYNOS_MIPI_DSIM, exynos_fb.c throws
error saying exynos_mipi_dsi_init() not defined. So, we add
dummy definition for exynos_mipi_dsi_init when CONFIG_EXYNOS_MIPI_DSIM
is not defined.

Signed-off-by: Ajay Kumar 
---
 arch/arm/include/asm/arch-exynos/mipi_dsim.h |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/arch-exynos/mipi_dsim.h 
b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
index 9a7cbeb..b73263d 100644
--- a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
+++ b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
@@ -358,7 +358,14 @@ struct mipi_dsim_lcd_driver {
void(*mipi_display_on)(struct mipi_dsim_device *dsim_dev);
 };
 
+#ifdef CONFIG_EXYNOS_MIPI_DSIM
 int exynos_mipi_dsi_init(void);
+#else
+int exynos_mipi_dsi_init(void)
+{
+   return 0;
+}
+#endif
 
 /*
  * register mipi_dsim_lcd_driver object defined by lcd panel driver
-- 
1.7.1

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

[U-Boot] [PATCH RESEND V2 1/4] EXYNOS5: Change parent clock of FIMD to MPLL

[Ajay Kumar]

With VPLL as source clock to FIMD,
Exynos DP Initializaton was failing sometimes with unstable clock.
Changing FIMD source to MPLL resolves this issue.

Signed-off-by: Ajay Kumar 
Acked-by: Simon Glass 
---
 arch/arm/cpu/armv7/exynos/clock.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
b/arch/arm/cpu/armv7/exynos/clock.c
index fe61f88..bfcd5f7 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -603,7 +603,7 @@ void exynos5_set_lcd_clk(void)
 */
cfg = readl(&clk->src_disp1_0);
cfg &= ~(0xf);
-   cfg |= 0x8;
+   cfg |= 0x6;
writel(cfg, &clk->src_disp1_0);
 
/*
-- 
1.7.1

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

[U-Boot] [PATCH V3 3/4] video: Modify exynos_fimd driver to support LCD console

[Ajay Kumar]

Currently, exynos FIMD driver is being used to support only TIZEN LOGOs.
In order to get LCD console, we need to enable half word swap feature
of FIMD and use 16 BPP.
LCD console and proprietary Logo cannot be used simultaneously.
You should define CONFIG_EXYNOS_LOGO for proprietary Logo, and if
CONFIG_EXYNOS_LOGO is not defined you get output console on LCD.
CONFIG_EXYNOS_LOGO is added to Trats configuration to keep
existing logo feature intact in Trats.

Signed-off-by: Ajay Kumar 
---
 drivers/video/exynos_fb.c   |5 -
 drivers/video/exynos_fimd.c |   10 --
 include/configs/trats.h |1 +
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index d9a3f9a..c111a09 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -65,6 +65,7 @@ static void exynos_lcd_init(vidinfo_t *vid)
exynos_fimd_lcd_init(vid);
 }
 
+#ifdef CONFIG_EXYNOS_LOGO
 static void draw_logo(void)
 {
int x, y;
@@ -87,6 +88,7 @@ static void draw_logo(void)
addr = panel_info.logo_addr;
bmp_display(addr, x, y);
 }
+#endif
 
 static void lcd_panel_on(vidinfo_t *vid)
 {
@@ -142,12 +144,13 @@ void lcd_ctrl_init(void *lcdbase)
 
 void lcd_enable(void)
 {
+#ifdef CONFIG_EXYNOS_LOGO
if (panel_info.logo_on) {
memset(lcd_base, 0, panel_width * panel_height *
(NBITS(panel_info.vl_bpix) >> 3));
draw_logo();
}
-
+#endif
lcd_panel_on(&panel_info);
 }
 
diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
index 06eae2e..f2e4c27 100644
--- a/drivers/video/exynos_fimd.c
+++ b/drivers/video/exynos_fimd.c
@@ -88,14 +88,20 @@ static void exynos_fimd_set_par(unsigned int win_id)
/* DATAPATH is DMA */
cfg |= EXYNOS_WINCON_DATAPATH_DMA;
 
-   /* bpp is 32 */
+#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
cfg |= EXYNOS_WINCON_WSWP_ENABLE;
+#else  /* To get output console on LCD */
+   cfg |= EXYNOS_WINCON_HAWSWP_ENABLE;
+#endif
 
/* dma burst is 16 */
cfg |= EXYNOS_WINCON_BURSTLEN_16WORD;
 
-   /* pixel format is unpacked RGB888 */
+#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
cfg |= EXYNOS_WINCON_BPPMODE_24BPP_888;
+#else  /* To get output console on LCD */
+   cfg |= EXYNOS_WINCON_BPPMODE_16BPP_565;
+#endif
 
writel(cfg, (unsigned int)&fimd_ctrl->wincon0 +
EXYNOS_WINCON(win_id));
diff --git a/include/configs/trats.h b/include/configs/trats.h
index a24e945..1573573 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -252,6 +252,7 @@
 #define CONFIG_EXYNOS_FB
 #define CONFIG_LCD
 #define CONFIG_CMD_BMP
+#define CONFIG_EXYNOS_LOGO
 #define CONFIG_BMP_32BPP
 #define CONFIG_FB_ADDR 0x52504000
 #define CONFIG_S6E8AX0
-- 
1.7.1

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

[U-Boot] [PATCH V3 4/4] EXYNOS5: Add support for FIMD and DP

[Ajay Kumar]

Add panel_info structure required by LCD driver
and DP panel platdata for SMDK5250.
Add GPIO configuration for LCD.
Enable FIMD and DP support on SMDK5250.
DP Panel size: 2560x1600.
We use 16BPP resolution to get LCD console.

Signed-off-by: Ajay Kumar 
---
 board/samsung/smdk5250/smdk5250.c |   97 +
 include/configs/smdk5250.h|8 +++
 2 files changed, 105 insertions(+), 0 deletions(-)

diff --git a/board/samsung/smdk5250/smdk5250.c 
b/board/samsung/smdk5250/smdk5250.c
index 4c50342..46fd2a5 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -24,12 +24,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -181,6 +184,100 @@ static int board_uart_init(void)
return 0;
 }
 
+void cfg_lcd_gpio(void)
+{
+   struct exynos5_gpio_part1 *gpio1 =
+   (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
+
+   /* For Backlight */
+   s5p_gpio_cfg_pin(&gpio1->b2, 0, GPIO_OUTPUT);
+   s5p_gpio_set_value(&gpio1->b2, 0, 1);
+
+   /* LCD power on */
+   s5p_gpio_cfg_pin(&gpio1->x1, 5, GPIO_OUTPUT);
+   s5p_gpio_set_value(&gpio1->x1, 5, 1);
+
+   /* Set Hotplug detect for DP */
+   s5p_gpio_cfg_pin(&gpio1->x0, 7, GPIO_FUNC(0x3));
+}
+
+vidinfo_t panel_info = {
+   .vl_freq= 60,
+   .vl_col = 2560,
+   .vl_row = 1600,
+   .vl_width   = 2560,
+   .vl_height  = 1600,
+   .vl_clkp= CONFIG_SYS_LOW,
+   .vl_hsp = CONFIG_SYS_LOW,
+   .vl_vsp = CONFIG_SYS_LOW,
+   .vl_dp  = CONFIG_SYS_LOW,
+   .vl_bpix= 4,/* LCD_BPP = 2^4, for output conosle on LCD */
+
+   /* wDP panel timing infomation */
+   .vl_hspw= 32,
+   .vl_hbpd= 80,
+   .vl_hfpd= 48,
+
+   .vl_vspw= 6,
+   .vl_vbpd= 37,
+   .vl_vfpd= 3,
+   .vl_cmd_allow_len = 0xf,
+
+   .win_id = 3,
+   .cfg_gpio   = cfg_lcd_gpio,
+   .backlight_on   = NULL,
+   .lcd_power_on   = NULL,
+   .reset_lcd  = NULL,
+   .dual_lcd_enabled = 0,
+
+   .init_delay = 0,
+   .power_on_delay = 0,
+   .reset_delay= 0,
+   .interface_mode = FIMD_RGB_INTERFACE,
+   .dp_enabled = 1,
+};
+
+static struct edp_device_info edp_info = {
+   .disp_info = {
+   .h_res = 2560,
+   .h_sync_width = 32,
+   .h_back_porch = 80,
+   .h_front_porch = 48,
+   .v_res = 1600,
+   .v_sync_width  = 6,
+   .v_back_porch = 37,
+   .v_front_porch = 3,
+   .v_sync_rate = 60,
+   },
+   .lt_info = {
+   .lt_status = DP_LT_NONE,
+   },
+   .video_info = {
+   .master_mode = 0,
+   .bist_mode = DP_DISABLE,
+   .bist_pattern = NO_PATTERN,
+   .h_sync_polarity = 0,
+   .v_sync_polarity = 0,
+   .interlaced = 0,
+   .color_space = COLOR_RGB,
+   .dynamic_range = VESA,
+   .ycbcr_coeff = COLOR_YCBCR601,
+   .color_depth = COLOR_8,
+   },
+};
+
+static struct exynos_dp_platform_data dp_platform_data = {
+   .phy_enable = set_dp_phy_ctrl,
+   .edp_dev_info   = &edp_info,
+};
+
+void init_panel_info(vidinfo_t *vid)
+{
+   vid->rgb_mode   = MODE_RGB_P,
+
+   exynos_set_dp_platform_data(&dp_platform_data);
+}
+
 #ifdef CONFIG_SYS_I2C_INIT_BOARD
 static int board_i2c_init(void)
 {
diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
index e412da8..a9b3b8b 100644
--- a/include/configs/smdk5250.h
+++ b/include/configs/smdk5250.h
@@ -256,6 +256,14 @@
 #define CONFIG_SOUND_WM8994
 #endif
 
+/* Display */
+#define CONFIG_LCD
+#define CONFIG_EXYNOS_FB
+#define CONFIG_EXYNOS_DP
+#define LCD_XRES   2560
+#define LCD_YRES   1600
+#define LCD_BPPLCD_COLOR16
+
 /* Enable devicetree support */
 #define CONFIG_OF_LIBFDT
 
-- 
1.7.1

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

Re: [U-Boot] [U-Boot, v2 1/6] cmd_sf: Add print messages on flash erase command

[Wolfgang Denk]

Dear Jagan Teki,

In message  
you wrote:
>
> Apart from this sometimes (very rare) due to the slowness of UART or SPI flash
> even if we run the sf commands it will not execute the actual code
> just terminate with showing
> u-boot prompt, so the user assumes that this command is happen
> properly. [but actually command is not done]

But that would be a different thing - if there are errors without
clear error messages, this is a bug that needs fixing.  [But I do not
see which part of your patch would address such an issue.  Am I
missing something?]

Adding verbose progress messages is a different thing, though.

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 much easier to suggest solutions when you know nothing
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 9/9] COMMON: MMC: Command to support eMMC booting

[Amarendra Reddy]

Hi SImon,

Thanks for the review comments.
Please find below the responses for your comments.


Thanks & Regards
Amarendra



On 20 December 2012 08:10, Simon Glass  wrote:

> Hi Amar,
>
> On Mon, Dec 17, 2012 at 3:19 AM, Amar  wrote:
>
> > This patch adds commands to open, close and create partitions on eMMC
> >
> > Signed-off-by: Amar 
> > ---
> >  common/cmd_mmc.c |  101
> > +-
> >  1 files changed, 100 insertions(+), 1 deletions(-)
> >
> > diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
> > index 62a1c22..1fd6b94 100644
> > --- a/common/cmd_mmc.c
> > +++ b/common/cmd_mmc.c
> > @@ -248,6 +248,102 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag,
> int
> > argc, char * const argv[])
> > curr_device, mmc->part_num);
> >
> > return 0;
> > +   } else if (strcmp(argv[1], "open") == 0) {
> > +   int dev;
> > +   struct mmc *mmc;
> > +
> > +   if (argc == 2)
> > +   dev = curr_device;
> > +   else if (argc == 3)
> > +   dev = simple_strtoul(argv[2], NULL, 10);
> > +   else if (argc == 4)
> > +   return 1;
> >
>
> Should this be  CMD_RET_USAGE? What is returning 1 for?
>  Yes. Shall correct it.
> > +
> > +   else
> > +   return CMD_RET_USAGE;
> > +
> > +   mmc = find_mmc_device(dev);
> > +   if (!mmc) {
> > +   printf("no mmc device at slot %x\n", dev);
> > +   return 1;
> > +   }
> > +
> > +   if (IS_SD(mmc)) {
> > +   printf("SD device cannot be opened/closed\n");
> > +   return 1;
> > +   }
> > +
> > +   if (!(mmc_boot_open(mmc))) {
> > +   printf("eMMC OPEN Success.!!\n");
> > +   printf("\t\t\t!!!Notice!!!\n");
> > +   printf("!You must close eMMC boot Partition"
> > +   "after all image
> > writing!\n");
> > +   printf("!eMMC boot partition has continuity"
> > +   "at image writing
> > time.!\n");
> > +   printf("!So, Do not close boot partition,
> Before,"
> > +   "all images is
> > written.!\n");
> >
>
> Maybe:
>
>  So, do not close boot partition before all images are written
> OK.. will change the wordings.

+   } else {
> > +   printf("eMMC OPEN Failed.!!\n");
> >
>
> Is it eMMC or MMC? Lower case or upper case? Your messages should be
> consistent. And you don't need the !!! I think.
>
> OK. Will maintain EMMC consistently every where. Will remove "!!!".
>
 > +   }
> > +   return 0;
> > +
> > +   } else if (strcmp(argv[1], "close") == 0) {
> > +   int dev;
> > +   struct mmc *mmc;
> > +
> > +   if (argc == 2)
> > +   dev = curr_device;
> > +   else if (argc == 3)
> > +   dev = simple_strtoul(argv[2], NULL, 10);
> > +   else if (argc == 4)
> > +   return 1;
> >
>
> Same Q here as above.
>
> Ok, will be addressed.
>

> > +   else
> > +   return CMD_RET_USAGE;
> > +
> > +   mmc = find_mmc_device(dev);
> > +   if (!mmc) {
> > +   printf("no mmc device at slot %x\n", dev);
> > +   return 1;
> > +   }
> > +
> > +   if (IS_SD(mmc)) {
> > +   printf("SD device cannot be opened/closed\n");
> > +   return 1;
> > +   }
> > +
> >
>
> Seems the open/close code is almost the same. Can you combine it?
>
 Ok. Will combine open/close.
>
> > +   if (!(mmc_boot_close(mmc)))
> > +   printf("eMMC CLOSE Success.!!\n");
> > +   else
> > +   printf("eMMC CLOSE Failed.!!\n");
> > +
> > +   return 0;
> > +
> > +   } else if (strcmp(argv[1], "bootpart") == 0) {
> > +   int dev;
> > +   dev = simple_strtoul(argv[2], NULL, 10);
> > +
> > +   struct mmc *mmc = find_mmc_device(dev);
> > +   u32 bootsize = simple_strtoul(argv[3], NULL, 10);
> > +   u32 rpmbsize = simple_strtoul(argv[4], NULL, 10);
> > +
> > +   if (!mmc) {
> > +   printf("no mmc device at slot %x\n", dev);
> > +   return 1;
> > +   }
> > +
> > +   if (IS_SD(mmc)) {
> > +   printf("It is not a eMMC device\n");
> > +   return 1;
> > +   }
> > +
> > +   if (0 == mmc_boot_partition_size_change(mmc,
> > +  

Re: [U-Boot] [PATCH 8/9] SMDK5250: Enable eMMC booting

[Amarendra Reddy]

Hi SImon,

Thanks for the review comments.
Please find below the responses for your comments.

Thanks & Regards
Amarendra

On 20 December 2012 08:05, Simon Glass  wrote:

> Hi Amar,
>
> On Mon, Dec 17, 2012 at 3:19 AM, Amar  wrote:
>
> > This patch adds support for eMMC booting on SMDK5250
> >
> > Signed-off-by: Amar 
> > ---
> >  board/samsung/smdk5250/spl_boot.c |   38
> > -
> >  1 files changed, 37 insertions(+), 1 deletions(-)
> >
> > diff --git a/board/samsung/smdk5250/spl_boot.c
> > b/board/samsung/smdk5250/spl_boot.c
> > index d8f3c1e..2648b4e 100644
> > --- a/board/samsung/smdk5250/spl_boot.c
> > +++ b/board/samsung/smdk5250/spl_boot.c
> > @@ -23,15 +23,40 @@
> >  #include
> >  #include
> >
> > +#include 
> > +#include 
> > +
> > +#define FSYS1_MMC0_DIV_VAL  0x0701
> >
>
> Should go in arch/arm/include/... ?
>
> OK. shall move it.
> > +
> >  enum boot_mode {
> > BOOT_MODE_MMC = 4,
> > +   BOOT_MODE_eMMC = 8, /* eMMC44 */
> >
>
> I think should you use upper case E, although I'm not completely sure.
> OK. will make it upper case to be consistent every where.
>
> > BOOT_MODE_SERIAL = 20,
> > /* Boot based on Operating Mode pin settings */
> > BOOT_MODE_OM = 32,
> > BOOT_MODE_USB,  /* Boot using USB download */
> >  };
> >
> > -   typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
> > +typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
> >
>
> Should avoid adding typedefs.
> Ok.
>
> > +static void set_emmc_clk(void);
> > +
> > +/*
> > +* Set MMC0 clock divisor value.
> > +* So that the mmc0 device operating freq is 50MHz.
> >
>
> Do we only support booting from mmc0? That's fine, but I suggest adding a
> little comment.
> OK.
>
> > +*/
> > +static void set_emmc_clk(void)
> > +{
> > +   struct exynos5_clock *clk = (struct exynos5_clock
> > *)EXYNOS5_CLOCK_BASE;
> > +   unsigned int addr;
> > +   unsigned int div_mmc;
> > +
> > +   addr = (unsigned int) &clk->div_fsys1;
> > +
> > +   div_mmc = readl(addr) & ~FSYS1_MMC0_DIV_MASK;
> > +   div_mmc |= FSYS1_MMC0_DIV_VAL;
> > +   writel(div_mmc, addr);
> >
>
> Can this function go in clock.c?
> This function is used by SPL, only during EMMC boot.
> Hence can be moved into board/samsung/smdk5250/clock_init.c.
>
 Please comment on this.
>


> > +}
> > +
> >
> >  /*
> >  * Copy U-boot from mmc to RAM:
> > @@ -43,6 +68,8 @@ void copy_uboot_to_ram(void)
> > spi_copy_func_t spi_copy;
> > enum boot_mode bootmode;
> > u32 (*copy_bl2)(u32, u32, u32);
> > +   u32 (*copy_bl2_emmc)(u32, u32);
> > +   void (*end_bootop_emmc)(void);
> >
> > bootmode = readl(EXYNOS5_POWER_BASE) & OM_STAT;
> >
> > @@ -57,6 +84,15 @@ void copy_uboot_to_ram(void)
> > copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC_COUNT,
> > CONFIG_SYS_TEXT_BASE);
> > break;
> > +   case BOOT_MODE_eMMC:
> > +   set_emmc_clk();
> > +   end_bootop_emmc = (void *) *(u32
> > *)EMMC44_END_BOOTOP_FNPTR_ADDR;
> > +   copy_bl2_emmc = (void *) *(u32
> > *)EMMC44_COPY_BL2_FNPTR_ADDR;
> >
>
> I think these are pointers to functions in the IROM. Do they have the same
> signature? Is it possible to create a table of them somewhere instead of
> using defines?
> OK.
>
 The signatures are different for different booting devices.
More over, SDMMC / SPI / USB booting requires only one function pointer.
Where as EMMC 4.3/4.4 requires two of those function pointers.

May be something like this can be used to create table
void (*ptr_table[])(void) = {
(void *)0x02020030, /* iROM Function Pointer - SDMMC boot   */
(void *)0x0202003C, /* iROM Function Pointer - EMMC 4.3 boot*/
(void *)0x02020040, /* iROM Function Pointer - EMMC 4.3 end boot op
*/
(void *)0x02020044, /* iROM Function Pointer - EMMC 4.4 boot*/
(void *)0x02020048, /* iROM Function Pointer - EMMC 4.4 end boot op
*/
(void *)0x02020050, /* iROM Function Pointer - EFNAND boot  */
(void *)0x02020058, /* iROM Function Pointer - SPI boot */
(void *)0x02020070  /* iROM Function Pointer - USB boot */
};

Usage:
copy_bl2_from_emmc = (void *) *(u32 *)ptr_table[3];

> end_bootop_from_emmc = (void *) *(u32 *)ptr_table[4];
>


> > +
> > +   copy_bl2_emmc(BL2_SIZE_BLOC_COUNT, CONFIG_SYS_TEXT_BASE);
> > +   end_bootop_emmc();
> > +   break;
> > +
> > default:
> > break;
> > }
> > --
> > 1.7.0.4
> >
> >
> Regards,
> Simon
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 7/9] MMC: APIs to support creation of boot partition

[Amarendra Reddy]

Hi Simon,

Ok. I will ensure to get rid of these little errors.

Thanks & Regards
Amarendra Reddy

On 20 December 2012 08:01, Simon Glass  wrote:

> Hi Amar,
>
> On Mon, Dec 17, 2012 at 3:19 AM, Amar  wrote:
>
> > This pathc adds APIs to open, close and to create boot partiton for eMMC.
> >
> > Signed-off-by: Amar 
> >
>
> I think you should run checkpatch (or patman!) on your patches to get rid
> of little errors. Or maybe you need to upgrade your checkpatch.
>
>
> > ---
> >  drivers/mmc/mmc.c |  118
> > +
> >  include/mmc.h |   16 +++
> >  2 files changed, 134 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > index 5ffd8c5..88b0435 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -1302,3 +1302,121 @@ int mmc_initialize(bd_t *bis)
> >
> > return 0;
> >  }
> > +
> > +int mmc_boot_partition_size_change(struct mmc *mmc, unsigned long
> > bootsize,
> > +   unsigned long rpmbsize)
> > +{
> > +   int err;
> > +   struct mmc_cmd cmd;
> > +
> > +   /* Only use this command for raw eMMC moviNAND */
> > +   /* Enter backdoor mode */
> >
>
> /*
>  * line 1
>  * line 2
>  */
>
> > +   cmd.cmdidx = MMC_CMD_RES_MAN;
> > +   cmd.resp_type = MMC_RSP_R1b;
> > +   cmd.cmdarg = MMC_CMD62_ARG1;
> > +
>
>
> [snip]
>
> Regards,
> Simon
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,1/3] fw_env: fix type of len

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/20/12 00:47, Joe Hershberger wrote:
> Hi Tom,
> 
> On Wed, Dec 19, 2012 at 5:00 PM, Tom Rini  wrote:
>> On Sat, Nov 10, 2012 at 07:47:45PM -, Mike Frysinger wrote:
>> 
>>> This variable is assigned by a size_t, and is printed that way,
>>> but is incorrectly declared as an int.  Which means we get
>>> warnings: fw_env.c: In function 'fw_setenv': fw_env.c:409:5:
>>> warning: format '%zu' expects argument of type 'size_t', but
>>> argument 3 has type 'int' [-Wformat]
>>> 
>>> Signed-off-by: Mike Frysinger  Acked-by: Joe
>>> Hershberger 
>> 
>> For the series, applied to u-boot/master, thanks!
> 
> I NACKed the third in this series.  Did you not see it?

Yeah, I missed that, sorry.

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

iQIcBAEBAgAGBQJQ0x/nAAoJENk4IS6UOR1WJ+IP/2g/Gb25k5WwKLG9LJWGp+ve
h173Xt1GhMWB8tutmEd1zc4Gat/ZhFv8PO6SxlR/3RxTZzNkg7v74SBkNnglHQVa
cvYIgzb72QvpIl7gHITHA38XedcV0UjEIJmlV6alqbZ/z4XBlNr/5Z71lwmI6VdM
H+yopRxmxXAtthTHNfyTyF6+MVItlCY15RkKFTvv93Pof1CRtRLI1jL5+497VtbS
hi7Fao2N/bHBUVkjQDU3hKOyApTNJhMBgxPu9EZszeAYqNLCNMH6FT4HvUNkYIjT
OEyG8bfm5D+v4x79fmLuLwPRg+yaBKu4nVJe7pzeTsQKfM3loIvyoaci2DLm9afS
ybmf97tRafMBYYiOTGJoRH3LXubCs1NZNgQIwCcDC9q59qy1E+uxp2jhBx/xfqGF
ixlz3A+J0c9Ahfjybejf9Y1M3I/3Sbyx6/fJR7jZsQo/lJROkp4W+yJHcmSzLqQO
jufYVZNi5lYo73R11TUa2oXngoBNW7jY4A9JHSA06JoB+GHp8Ze6yTFZD0QviTkY
oAWNHMvTFqzvC4UAHLXOGiiBTuxVaCd8nOR2/z/BzcKEHJuTTJxwe0ABB/FU9o3b
wF1MxwONT3/kfYA5eDItbjGaSa6NyY/66czjFSZjO0YJFZEKwKtLigwcgKw6Krq+
Mfv8c0WC0IXzgYikHFMm
=Fiob
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PULL] u-boot-usb/master

[Tom Rini]

On Tue, Dec 18, 2012 at 07:19:10PM +0100, Marek Vasut wrote:

> I reduced it, DFU will have to wait, sorry.
> 
> The following changes since commit ebbf0d20aa85f623c49b7ed3349ebfea450c152d:
> 
>   Prepare v2013.01-rc2 (2012-12-14 14:43:22 -0700)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 4f8dd5920f52462a9a5d794dc310a9a7a49ca89b:
> 
>   cm_t35: use new low level interface for usb ehci (2012-12-17 15:38:15 +0100)
> 
> 
> Lukasz Dalek (2):
>   pxa25x_udc: Remove usbdescriptors.h
>   h2200: Add USB CDC ethernet support
> 
> Milind Choudhary (1):
>   usb: Clean up newly allocated device nodes in case of configuration 
> failure
> 
> Nikita Kiryanov (2):
>   cm-t35: add USB host support
>   cm_t35: use new low level interface for usb ehci
> 
> Pantelis Antoniou (2):
>   g_dnl: Issue connect/disconnect as appropriate
>   g_dnl: Properly terminate string list.
> 
> Richard Genoud (1):
>   usb documentation: fix typo
> 
> Vincent Palatin (1):
>   usb: properly detect empty mass storage media reader
> 
> Vipin Kumar (1):
>   usbh/ehci: Increase timeout for enumeration
> 
>  board/cm_t35/cm_t35.c   |   77 
> +
>  board/h2200/h2200.c |   11 +++
>  common/usb.c|   12 
>  common/usb_hub.c|   35 ++-
>  common/usb_storage.c|   10 ++
>  doc/README.usb  |2 +-
>  drivers/usb/gadget/g_dnl.c  |   12 +++-
>  drivers/usb/gadget/pxa25x_udc.c |1 -
>  include/configs/cm_t35.h|8 +++-
>  include/configs/h2200.h |   25 +
>  include/usb.h   |1 +
>  11 files changed, 185 insertions(+), 9 deletions(-)

The cm_t35 parts don't compile, NAK.
cm_t35.c: In function 'ehci_hcd_init':
cm_t35.c:522:34: error: 'TWL4030_GPIO_GPIODATADIR1' undeclared (first
use in this function)
cm_t35.c:522:34: note: each undeclared identifier is reported only once
for each function it appears in
cm_t35.c:527:34: error: 'TWL4030_GPIO_SETGPIODATAOUT1' undeclared (first
use in this function)

-- 
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, 1/2] spi: Add progress percentage and write speed to `sf update`

[Tom Rini]

On Wed, Dec 19, 2012 at 05:18:55PM -0800, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, Dec 19, 2012 at 5:03 PM, Tom Rini  wrote:
> > On Thu, Dec 20, 2012 at 12:14:00AM +0100, Wolfgang Denk wrote:
> >> Dear Tom Rini,
> >>
> >> In message <20121219225945.GF14589@bill-the-cat> you wrote:
> >> >
> >> ...
> >> > With this change, applied to u-boot/master.
> >>
> >> Argh :-(
> >>
> >> Can we please undo this somehow?  This does not fit at all
> >> conceptually.  U-Boot is supposed to use the good ols UNIX philosophy
> >> of being terse by default, and special casing one specific storage
> >> device makes no sense at all to me.
> >
> > We need to fix some of the underlying problems so that we're consistent
> > here.  Sometimes we have output (network #), sometimes we don't.
> > Sometimes we have a speed (network, filesystem load), sometimes we
> > don't.  I'd be quite happy to have a uniform output and a uniform ON/OFF
> > switch.
> 
> I'm happy to do something like this. Obviously we want a config, but
> do we also want an env variable to control it? Could be useful.

The biggest blocker I see is that we should start the series by
re-orging things, if we can, so that we don't have this code in N
places.

> And at the risk of killing it with feature creep, perhaps we could
> have two levels of verbosity: progress (which repeatedly updates on
> the same line) and notice (which does not). That might take care of
> Jagannadha's use case also.

If we can do it such that it's (a) clean looking and (b) build-time
configurable too, I don't see why we can't give it a look at least.

-- 
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] Bricked when trying to attach UBI

[Luca Ceresoli]

Hi,

I'm Cc'ing the linux-mtd list as well as the authors of the Linux
commits cited below.

For these new readers: I reported a problem with U-Boot 2012.04.01 not
being able to attach an UBI partition in NAND, while Linux (2.6.37) can
attach and repair it.

It looks like an U-Boot bug, but I discovered strange things around the
chip->badblockbits variable (in the NAND code) by comparing the
relevant code in U-Boot and Linux.

Sorry for Cc'ing so many people, but following this issue I was lead
from one subsystem to another (and from U-Boot to Linux).

Previous discussion is here:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/149624

Luca Ceresoli wrote:

Hi Andreas,

Andreas Bießmann wrote:

Hi Luca,

On 19.12.2012 16:56, Luca Ceresoli wrote:

Hi Andreas,

Andreas Bießmann wrote:
...

Creating 1 MTD partitions on "nand0":
0x0010-0x1000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size:  512
UBI: VID header offset:  512 (aligned 512)
UBI: data offset:2048
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0,
need 1)

Now the device is totally blocked, and power cycling does not change
the result.


have you tried to increase the malloc arena in u-boot
(CONIG_SYS_MALLOC_LEN)?
We had errors like this before [1],[2] and [3], maybe others -
apparently with another error message, but please give it a try. We
know
ubi recovery needs some ram and 1MiB may be not enough.


Thanks for your suggestion.

Unfortunately this does not seem to be the cause of my problem: I tried
increasing my CONFIG_SYS_MALLOC_LEN in include/configs/dig297.h from
(1024 << 10) to both (1024 << 12) and (1024 << 14), but without any
difference.


Well, ok ... Malloc arena is always my first thought if I read about
problems with ubi in u-boot.
Have you looked up the differences in drivers/mtd/ubi/ in your u-boot
and linux tree? Maybe you can see something obviously different in the
ubi_wl_init_scan()?


I had some days ago, but I double-checked now as you suggested. Indeed
there is an important difference: attach_by_scanning() (build.c) calls
ubi_wl_init_scan() and ubi_eba_init_scan() just like Linux does, but in
a swapped order!

This swap dates back to:

commit d63894654df72b010de2abb4b3f07d0d755f65b6
Author: Holger Brunck 
Date:   Mon Oct 10 13:08:19 2011 +0200

 UBI: init eba tables before wl when attaching a device

 This fixes that u-boot gets stuck when a bitflip was detected
 during "ubi part ". If a bitflip was detected UBI tries
 to copy the PEB to a different place. This needs that the eba table
 are initialized, but this was done after the wear levelling worker
 detects the bitflip. So changes the initialisation of these two
 tasks in u-boot.

 This is a u-boot specific patch and not needed in the linux layer,
 because due to commit 1b1f9a9d00447d
 UBI: Ensure that "background thread" operations are really executed
 we schedule these tasks in place and not as in linux after the inital
 task which schedule this new task is finished.

 Signed-off-by: Holger Brunck 
 cc: Stefan Roese 
 Signed-off-by: Stefan Roese 

I tried reverting that commit and... surprise! U-Boot can now attach UBI
and boot properly!

But the cited commit actually fixed a bug that bite our board a few
months back, so it should not be reverted without thinking twice. Now
it apparently introduced another bug. :-(

I'm Cc:ing the commit author for comments.

Nonetheless, I have evidence of a different behaviour between U-Boot
and Linux even before the two swapped functions are called.

What attach_by_scanning() does in Linux is (abbreviated):

static int attach_by_scanning(struct ubi_device *ubi)
{
 si = ubi_scan(ubi);
 ...fill ubi->some_fields...;
 err = ubi_read_volume_table(ubi, si);
 /* MARK */
 err = ubi_eba_init_scan(ubi, si); /* swapped in U-Boot */
 err = ubi_wl_init_scan(ubi, si);  /* swapped in U-Boot */
 ubi_scan_destroy_si(si);
 return 0;
}

See the two swapped calls.

At MARK, I printed some of the peb counters in *ubi, and I got
different results for ubi->avail_pebs between U-Boot and Linux:
U-Boot: UBI: POST_TBL: rsvd=2018, avail=21, beb_rsvd_{pebs,level}=0,0
Linux:  UBI: POST_TBL: rsvd=2018, avail=22, beb_rsvd_{pebs,level}=0,0

The printed values were equal before calling ubi_read_volume_table().
I have no idea about where this difference comes from, nor if this
difference can cause my troubles.
I will better investigate tomorrow looking into ubi_read_volume_table().


After half a day of debugging and an insane amount of printk()s added to
both U-Boot and Linux, I have some more hints to understand the problem.

The two different results quoted above show that U-Boot counted 21
available eraseblocks, while Linux counts

Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat driver

[Chris Kiick]

Hi,
  Well, you are of course 100% correct. I went back and took out the nand plat 
stuff, made my own driver and used NAND_ECC_HW mode.  A few tweaks and it works 
just great. No changes needed to nand base code.

  The mode names are a bit misleading, perhaps someone could document them in 
the README?

  What do I do to withdraw the patch? Or does it just get bounced out of the 
queue.

 
Thanks for the help,
--
Chris J. Kiick ch...@kiicks.net



- Original Message 
> From: Scott Wood 
> To: Chris Kiick 
> Cc: u-boot@lists.denx.de
> Sent: Wed, December 19, 2012 3:40:49 PM
> Subject: Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat 
>driver
> 
> On 12/19/2012 03:16:19 PM, Chris Kiick wrote:
> > Hi,
> >   Thanks  for the reply. This is my first patch to u-boot. Any advice is
> >  appreciated. Comments in-line below.
> > 
> > 
> > - Original  Message 
> > 
> > > From: Scott Wood 
> >  > To: Chris Kiick 
> > > Cc: u-boot@lists.denx.de
> > > Sent:  Wed, December 19, 2012 1:02:52 PM
> > > Subject: Re: [U-Boot] [PATCH]  NAND: allow custom SW ECC when using nand 
>plat
> > >driver
> >  >
> > > On 12/18/2012 05:27:00 PM, Chris Kiick wrote:
> > >  > Allow boards to set their  own ECC layouts and functions in  
>NAND_PLAT_INIT
> > > > without being stomped on  by nand_base.c  intialization.
> > > >
> > > > Signed-off-by: ckiick  
> > > > ---
> > > >   drivers/mtd/nand/nand_base.c |11 +++
> > >  >  drivers/mtd/nand/nand_plat.c |4  ++--
> > >  >  include/configs/qong.h   |2   +-
> > > >  3 files changed, 10 insertions(+), 7  deletions(-)
> > > >
> > > > diff --git  a/drivers/mtd/nand/nand_base.c  
>b/drivers/mtd/nand/nand_base.c
> > >  > index a2d06be..614fc72 100644
> > > > ---   a/drivers/mtd/nand/nand_base.c
> > > > +++   b/drivers/mtd/nand/nand_base.c
> > > > @@ -3035,8 +3035,10 @@  int  nand_scan_tail(struct mtd_info *mtd)
> > > >chip->ecc.mode = NAND_ECC_SOFT;
> > >  >
> > > >  case  NAND_ECC_SOFT:
> >  > > -chip->ecc.calculate =   nand_calculate_ecc;
> > > > - chip->ecc.correct =  nand_correct_data;
> > > > + if  (!chip->ecc.calculate)
> > > > +  chip->ecc.calculate =  nand_calculate_ecc;
> > > > + if  (!chip->ecc.correct)
> > > > +  chip->ecc.correct = nand_correct_data;
> > > >chip->ecc.read_page = nand_read_page_swecc;
> >  > >   chip->ecc.read_subpage =   nand_read_subpage;
> > > >chip->ecc.write_page = nand_write_page_swecc;
> > > > @@ -3044,9  +3046,10 @@  int nand_scan_tail(struct mtd_info *mtd)
> > >  >   chip->ecc.write_page_raw =  nand_write_page_raw;
> > > >chip->ecc.read_oob = nand_read_oob_std;
> > > >chip->ecc.write_oob = nand_write_oob_std;
> > >  >  -if (!chip->ecc.size)
> > >  > + if (!chip->ecc.size) {
> > >  >   chip->ecc.size =  256;
> > > > - chip->ecc.bytes =  3;
> > > > +  chip->ecc.bytes = 3;
> > > > +  }
> > > >  break;
> > >  >
> > > >   case NAND_ECC_SOFT_BCH:
> >  >
> > > How is this part specific to nand  plat?
> > 
> >  OK, it's not, but if you are using nand plat, then you are forced to go  
>through
> > this code path with no chance of making any changes after  because of the 
way
> > board_nand_init() is written.
> 
> nand plat is  meant to be a simple driver for simple hardware that follows a 
>certain  pattern.  If you have hardware that doesn't fit that, don't use nand  
>plat.
> 
> > I seem to see  other nand drivers setting up ecc
> >  layouts and then calling nand_scan_tail(), I'm not sure how they are   
>getting
> > around this.
> 
> They don't use NAND_ECC_SOFT.
> 
> > I  reasoned that the change was safe for existing code because if something 
> >  
>was
> > not setting its own ecc layout, it would still use the default, but  it if 
>was,
> > then it had to be after the call to nand_scan_tail() and that  would 
override
> > whatever was set there anyway.
> 
> It's not a matter  of safety, but rather a sign that you're misusing things.
> 
> > > I'm  not sure how specifying your own ECC functions fits with the  
> > > purpose  
>of
> > >either NAND_ECC_SOFT or nand plat.
> > Well, NAND_ECC_SOFT is  the only scheme that does fit with custom ECC 
>algorithms.
> 
> No, it's the  opposite.  NAND_ECC_SOFT is telling the generic code "please do 
>ECC for  me".  NAND_ECC_HW is telling the generic code "I want to do ECC 
>myself",  usually because you have hardware that implements it.  In your case, 
>it's  because you're trying to maintain compatibility with something.
> 
> > You  have to pick one of the existing ECC schemes, and SOFT is the scheme  
>that
> > allows you to do your own ECC, if you setup the layout, calculate  and 
>correct
> > parts. Looking at the code, that's what I thought it was  for.
> 
> You just described NAND_ECC_HW. :-)
> 
> > Is there another way  to implement custom ECC algorithms, done in 

Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling

[Tom Warren]

On Wed, Dec 19, 2012 at 5:32 PM, Allen Martin  wrote:
> On Wed, Dec 19, 2012 at 02:42:24PM -0800, Albert ARIBAUD wrote:
>> Hi Allen,
>>
>> > Hi Albert, I did a merge of u-boot/master into u-boot-arm/master and
>> > resolved the conflicts and I've pushed the result to:
>> >
>> >  git://github.com/arm000/u-boot.git
>> >  branch: u-boot-arm-merge-resolved
>> >
>> > I resolved all the conflicts, but the only ones I claim I did
>> > correctly were the changes to:
>> >
>> >  include/configs/seaboard.h
>> >  include/configs/tegra-common-post.h
>> >
>> > the other conflicts were not related to tegra.
>> >
>> > If you want a new pull request, you'll first have to unroll the
>> > previously merged tegra patches from u-boot-arm/master so I can give
>> > you a conflict free merge request.
>>
>> Thanks Allen, this branch is what I wanted exactly -- I don't want to
>> ask for a rollback. As soon as I am sure about the samsung branch, I'll
>> merge all "fix" branches into ARM.
>
> Ok, let me know if you have any problems resolving and I'll try to
> help the best I can.
>
> Tom, you'll need to rebase u-boot-tegra/next on top of this, and there
> will be conflicts when you do.  I've resolved those as well for
> reference and pushed to:
>
>   git://github.com/arm000/u-boot.git
>   branch: u-boot-tegra-next-rebased
>
> -Allen

Thanks, Allen, I probably won't get to this before the holiday break,
but I'll pick it up next year and see where we're at. Appreciate your
help with this.

Albert - if you need anything from me, it'll have to be today or
tomorrow, or next year.

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

Re: [U-Boot] Pull request: u-boot-sh/master

[Tom Rini]

On Thu, Dec 20, 2012 at 02:12:32PM +0900, Nobuhiro Iwamatsu wrote:

> Hi Tom,
> 
> Please pull u-boot-sh master branch.
> 
> Best regards,
>   Nobuhiro
> 
> The following changes since commit 095728803eedfce850a2f85828f79500cb09979e:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-net (2012-12-17
> 18:39:50 -0700)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-sh master
> 
> for you to fetch changes up to bb474b8187878181493b4ba1d422fb83df9b4335:
> 
>   serial_sh: Add support Renesas SH7752 (2012-12-20 13:20:17 +0900)
> 
> 
> Yoshihiro Shimoda (2):
>   sh: add support for sh7752evb board
>   serial_sh: Add support Renesas SH7752
> 
>  MAINTAINERS |1 +
>  arch/sh/include/asm/cpu_sh4.h   |2 +
>  arch/sh/include/asm/cpu_sh7752.h|  211
> ++
>  board/renesas/sh7752evb/Makefile|   36 ++
>  board/renesas/sh7752evb/lowlevel_init.S |  460
> +
>  board/renesas/sh7752evb/sh7752evb.c |  330
> 
>  board/renesas/sh7752evb/spi-boot.c  |  116 ++
>  board/renesas/sh7752evb/u-boot.lds  |   97 +
>  boards.cfg  |1 +
>  doc/README.sh7752evb|   67 +
>  drivers/serial/serial_sh.h  |2 +-
>  include/configs/sh7752evb.h |  153
> +++
>  12 files changed, 1475 insertions(+), 1 deletion(-)
>  create mode 100644 arch/sh/include/asm/cpu_sh7752.h
>  create mode 100644 board/renesas/sh7752evb/Makefile
>  create mode 100644 board/renesas/sh7752evb/lowlevel_init.S
>  create mode 100644 board/renesas/sh7752evb/sh7752evb.c
>  create mode 100644 board/renesas/sh7752evb/spi-boot.c
>  create mode 100644 board/renesas/sh7752evb/u-boot.lds
>  create mode 100644 doc/README.sh7752evb
>  create mode 100644 include/configs/sh7752evb.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

[U-Boot] i.mx53 NFC support

[Mark Roy]

Hello folks,

 

I have a custom i.mx53 board with NAND Flash connected using the i.mx53
NAND flash controller.I have been trying to the flash working in
U-boot with no success.  I was looking at the driver mtd/nand/mxc_nand.c
which I thought would work, but it seems that it only supports the older
NFC versions found in the mx25, mx27, and mx35.   

 

Is there a working driver available for the NFC in the mx5 processors?
If not, do you think it would be easier for me to try and patch the
mxc_nand driver to support the newer NFC or to try and port the imx_nand
driver from the Linux kernel?   

 

Best regards,

Mark Roy

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

Re: [U-Boot] i.mx53 NFC support

[Benoît Thébaudeau]

Dear Mark Roy,

On Thursday, December 20, 2012 6:57:29 PM, Mark Roy wrote:
> I have a custom i.mx53 board with NAND Flash connected using the
> i.mx53
> NAND flash controller.I have been trying to the flash working in
> U-boot with no success.  I was looking at the driver
> mtd/nand/mxc_nand.c
> which I thought would work, but it seems that it only supports the
> older
> NFC versions found in the mx25, mx27, and mx35.
> 
> Is there a working driver available for the NFC in the mx5
> processors?
> If not, do you think it would be easier for me to try and patch the
> mxc_nand driver to support the newer NFC or to try and port the
> imx_nand
> driver from the Linux kernel?

Please apply the following patch on u-boot/master:
http://patchwork.ozlabs.org/patch/179176/
http://patchwork.ozlabs.org/patch/179176/raw/

You may also be interested in the following threads:
http://lists.denx.de/pipermail/u-boot/2012-October/138129.html
http://lists.denx.de/pipermail/u-boot/2012-December/142349.html

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

Re: [U-Boot] [PATCH V3 2/4] EXYNOS: Add dummy definition to fix compilation dependency on CONFIG_EXYNOS_MIPI_DSIM

[Simon Glass]

Hi Ajay,

On Thu, Dec 20, 2012 at 4:35 AM, Ajay Kumar wrote:

> When only DP is used, we need not enable CONFIG_EXYNOS_MIPI_DSIM.
> But if we do not select CONFIG_EXYNOS_MIPI_DSIM, exynos_fb.c throws
> error saying exynos_mipi_dsi_init() not defined. So, we add
> dummy definition for exynos_mipi_dsi_init when CONFIG_EXYNOS_MIPI_DSIM
> is not defined.
>
> Signed-off-by: Ajay Kumar 
> ---
>  arch/arm/include/asm/arch-exynos/mipi_dsim.h |7 +++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
> b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
> index 9a7cbeb..b73263d 100644
> --- a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
> +++ b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
> @@ -358,7 +358,14 @@ struct mipi_dsim_lcd_driver {
> void(*mipi_display_on)(struct mipi_dsim_device *dsim_dev);
>  };
>
> +#ifdef CONFIG_EXYNOS_MIPI_DSIM
>  int exynos_mipi_dsi_init(void);
> +#else
> +int exynos_mipi_dsi_init(void)
>

Should this be static inline? I suppose it is included only once, but it
might be a good idea to add this.


> +{
> +   return 0;
> +}
> +#endif
>
>  /*
>   * register mipi_dsim_lcd_driver object defined by lcd panel driver
> --
> 1.7.1
>
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 3/4] video: Modify exynos_fimd driver to support LCD console

[Simon Glass]

Hi,

On Thu, Dec 20, 2012 at 4:35 AM, Ajay Kumar wrote:

> Currently, exynos FIMD driver is being used to support only TIZEN LOGOs.
> In order to get LCD console, we need to enable half word swap feature
> of FIMD and use 16 BPP.
> LCD console and proprietary Logo cannot be used simultaneously.
> You should define CONFIG_EXYNOS_LOGO for proprietary Logo, and if
> CONFIG_EXYNOS_LOGO is not defined you get output console on LCD.
> CONFIG_EXYNOS_LOGO is added to Trats configuration to keep
> existing logo feature intact in Trats.
>
> Signed-off-by: Ajay Kumar 
>

There is nothing in the README, but I suppose this is a chip-specific
patch, so fair enough. But see below.

Acked-by: Simon Glass 



> ---
>  drivers/video/exynos_fb.c   |5 -
>  drivers/video/exynos_fimd.c |   10 --
>  include/configs/trats.h |1 +
>  3 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
> index d9a3f9a..c111a09 100644
> --- a/drivers/video/exynos_fb.c
> +++ b/drivers/video/exynos_fb.c
> @@ -65,6 +65,7 @@ static void exynos_lcd_init(vidinfo_t *vid)
> exynos_fimd_lcd_init(vid);
>  }
>
> +#ifdef CONFIG_EXYNOS_LOGO
>

Do you actually need this #ifdef, and the one below it? You already have
panel_info.logo_on. I suppose you could do, at the top of the file:

+#ifdef CONFIG_EXYNOS_LOGO
#define panal_exynos_logo()  panel_info.logo_on
#else
#define panal_exynos_logo() 0
#endif



>  static void draw_logo(void)
>  {
> int x, y;
> @@ -87,6 +88,7 @@ static void draw_logo(void)
> addr = panel_info.logo_addr;
> bmp_display(addr, x, y);
>  }
> +#endif
>
>  static void lcd_panel_on(vidinfo_t *vid)
>  {
> @@ -142,12 +144,13 @@ void lcd_ctrl_init(void *lcdbase)
>
>  void lcd_enable(void)
>  {
> +#ifdef CONFIG_EXYNOS_LOGO
> if (panel_info.logo_on) {
>

Then could do 'if (panal_exynos_logo())' here and rermove the #ifdefs. Same
below. #ifdefs are considered bad because they create new code paths that
might not always be compiled.

memset(lcd_base, 0, panel_width * panel_height *
> (NBITS(panel_info.vl_bpix) >> 3));
> draw_logo();
> }
> -
> +#endif
> lcd_panel_on(&panel_info);
>  }
>
> diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
> index 06eae2e..f2e4c27 100644
> --- a/drivers/video/exynos_fimd.c
> +++ b/drivers/video/exynos_fimd.c
> @@ -88,14 +88,20 @@ static void exynos_fimd_set_par(unsigned int win_id)
> /* DATAPATH is DMA */
> cfg |= EXYNOS_WINCON_DATAPATH_DMA;
>
> -   /* bpp is 32 */
> +#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
> cfg |= EXYNOS_WINCON_WSWP_ENABLE;
> +#else  /* To get output console on LCD */
> +   cfg |= EXYNOS_WINCON_HAWSWP_ENABLE;
> +#endif
>
> /* dma burst is 16 */
> cfg |= EXYNOS_WINCON_BURSTLEN_16WORD;
>
> -   /* pixel format is unpacked RGB888 */
> +#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
> cfg |= EXYNOS_WINCON_BPPMODE_24BPP_888;
> +#else  /* To get output console on LCD */
> +   cfg |= EXYNOS_WINCON_BPPMODE_16BPP_565;
> +#endif
>
> writel(cfg, (unsigned int)&fimd_ctrl->wincon0 +
> EXYNOS_WINCON(win_id));
> diff --git a/include/configs/trats.h b/include/configs/trats.h
> index a24e945..1573573 100644
> --- a/include/configs/trats.h
> +++ b/include/configs/trats.h
> @@ -252,6 +252,7 @@
>  #define CONFIG_EXYNOS_FB
>  #define CONFIG_LCD
>  #define CONFIG_CMD_BMP
> +#define CONFIG_EXYNOS_LOGO
>  #define CONFIG_BMP_32BPP
>  #define CONFIG_FB_ADDR 0x52504000
>  #define CONFIG_S6E8AX0
> --
> 1.7.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 4/4] EXYNOS5: Add support for FIMD and DP

[Simon Glass]

On Thu, Dec 20, 2012 at 4:35 AM, Ajay Kumar wrote:

> Add panel_info structure required by LCD driver
> and DP panel platdata for SMDK5250.
> Add GPIO configuration for LCD.
> Enable FIMD and DP support on SMDK5250.
> DP Panel size: 2560x1600.
> We use 16BPP resolution to get LCD console.
>
> Signed-off-by: Ajay Kumar 
>

Acked-by: Simon Glass 


> ---
>  board/samsung/smdk5250/smdk5250.c |   97
> +
>  include/configs/smdk5250.h|8 +++
>  2 files changed, 105 insertions(+), 0 deletions(-)
>
> diff --git a/board/samsung/smdk5250/smdk5250.c
> b/board/samsung/smdk5250/smdk5250.c
> index 4c50342..46fd2a5 100644
> --- a/board/samsung/smdk5250/smdk5250.c
> +++ b/board/samsung/smdk5250/smdk5250.c
> @@ -24,12 +24,15 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -181,6 +184,100 @@ static int board_uart_init(void)
> return 0;
>  }
>
> +void cfg_lcd_gpio(void)
> +{
> +   struct exynos5_gpio_part1 *gpio1 =
> +   (struct exynos5_gpio_part1 *)
> samsung_get_base_gpio_part1();
> +
> +   /* For Backlight */
> +   s5p_gpio_cfg_pin(&gpio1->b2, 0, GPIO_OUTPUT);
> +   s5p_gpio_set_value(&gpio1->b2, 0, 1);
> +
> +   /* LCD power on */
> +   s5p_gpio_cfg_pin(&gpio1->x1, 5, GPIO_OUTPUT);
> +   s5p_gpio_set_value(&gpio1->x1, 5, 1);
> +
> +   /* Set Hotplug detect for DP */
> +   s5p_gpio_cfg_pin(&gpio1->x0, 7, GPIO_FUNC(0x3));
> +}
> +
> +vidinfo_t panel_info = {
> +   .vl_freq= 60,
> +   .vl_col = 2560,
> +   .vl_row = 1600,
> +   .vl_width   = 2560,
> +   .vl_height  = 1600,
> +   .vl_clkp= CONFIG_SYS_LOW,
> +   .vl_hsp = CONFIG_SYS_LOW,
> +   .vl_vsp = CONFIG_SYS_LOW,
> +   .vl_dp  = CONFIG_SYS_LOW,
> +   .vl_bpix= 4,/* LCD_BPP = 2^4, for output conosle on
> LCD */
> +
> +   /* wDP panel timing infomation */
> +   .vl_hspw= 32,
> +   .vl_hbpd= 80,
> +   .vl_hfpd= 48,
> +
> +   .vl_vspw= 6,
> +   .vl_vbpd= 37,
> +   .vl_vfpd= 3,
> +   .vl_cmd_allow_len = 0xf,
> +
> +   .win_id = 3,
> +   .cfg_gpio   = cfg_lcd_gpio,
> +   .backlight_on   = NULL,
> +   .lcd_power_on   = NULL,
> +   .reset_lcd  = NULL,
> +   .dual_lcd_enabled = 0,
> +
> +   .init_delay = 0,
> +   .power_on_delay = 0,
> +   .reset_delay= 0,
> +   .interface_mode = FIMD_RGB_INTERFACE,
> +   .dp_enabled = 1,
> +};
> +
> +static struct edp_device_info edp_info = {
> +   .disp_info = {
> +   .h_res = 2560,
> +   .h_sync_width = 32,
> +   .h_back_porch = 80,
> +   .h_front_porch = 48,
> +   .v_res = 1600,
> +   .v_sync_width  = 6,
> +   .v_back_porch = 37,
> +   .v_front_porch = 3,
> +   .v_sync_rate = 60,
> +   },
> +   .lt_info = {
> +   .lt_status = DP_LT_NONE,
> +   },
> +   .video_info = {
> +   .master_mode = 0,
> +   .bist_mode = DP_DISABLE,
> +   .bist_pattern = NO_PATTERN,
> +   .h_sync_polarity = 0,
> +   .v_sync_polarity = 0,
> +   .interlaced = 0,
> +   .color_space = COLOR_RGB,
> +   .dynamic_range = VESA,
> +   .ycbcr_coeff = COLOR_YCBCR601,
> +   .color_depth = COLOR_8,
> +   },
> +};
> +
> +static struct exynos_dp_platform_data dp_platform_data = {
> +   .phy_enable = set_dp_phy_ctrl,
> +   .edp_dev_info   = &edp_info,
> +};
> +
> +void init_panel_info(vidinfo_t *vid)
> +{
> +   vid->rgb_mode   = MODE_RGB_P,
> +
> +   exynos_set_dp_platform_data(&dp_platform_data);
> +}
> +
>  #ifdef CONFIG_SYS_I2C_INIT_BOARD
>  static int board_i2c_init(void)
>  {
> diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
> index e412da8..a9b3b8b 100644
> --- a/include/configs/smdk5250.h
> +++ b/include/configs/smdk5250.h
> @@ -256,6 +256,14 @@
>  #define CONFIG_SOUND_WM8994
>  #endif
>
> +/* Display */
> +#define CONFIG_LCD
> +#define CONFIG_EXYNOS_FB
> +#define CONFIG_EXYNOS_DP
> +#define LCD_XRES   2560
> +#define LCD_YRES   1600
> +#define LCD_BPPLCD_COLOR16
> +
>  /* Enable devicetree support */
>  #define CONFIG_OF_LIBFDT
>
> --
> 1.7.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] env_nand.c: support falling back to redundant env when writing

[Phil Sutter]

On Tue, Dec 11, 2012 at 05:12:32PM -0600, Scott Wood wrote:
> On 12/10/2012 07:41:43 AM, Phil Sutter wrote:
> > On Fri, Dec 07, 2012 at 11:38:11AM -0600, Scott Wood wrote:
> > > On 12/07/2012 10:58:53 AM, Phil Sutter wrote:
> > > > Hmm. Does not look like CONFIG_ENV_OFFSET_OOB is used to select  
> > the
> > > > block(s) within the erase page to save the environment. Looking at
> > > > common/env_nand.c:318, the environment offset saved in the OOB  
> > seems
> > > > to
> > > > be in erase page unit.
> > >
> > > I'm not sure what you mean by "block(s) within the erase page" --
> > > blocks are the unit of erasing, and of bad block marking.
> > 
> > Not always, at least not with NAND flash. Erase pages are mostly  
> > bigger
> > than write pages (or "blocks"). In my case, flash consists of 0x800
> > bytes write pages and 0x2000 bytes erase pages.
> 
> Erase blocks are larger than write pages, yes.  I've never heard erase  
> blocks called "pages" or write pages called "blocks" -- but my main  
> point is that the unit of erasing and the unit of badness are the same.

Ah, OK. Please excuse my humble nomenclature, I never cared enough to
sort out what is called what. Of course, this is not the best basis for
a discussion about these things.

But getting back to the topic: The assumption of blocks getting bad, not
pages within a block means that for any kind of bad block prevention,
multiple blocks need to be used. Although I'm honestly speaking not
really sure why this needs to be like that. Maybe the bad page marking
would disappear when erasing the block it belongs to?

> > > The block to hold the environment is stored in the OOB of block  
> > zero,
> > > which is usually guaranteed to not be bad.
> > 
> > Erase or write block? Note that every write block has it's own OOB.
> 
> "block" means "erase block".
> 
> Every write page has its own OOB, but it is erase blocks that are  
> marked bad.  Typically the block can be marked bad in either the first  
> or the second page of the erase block.

Interesting. I had the impression of pages being marked bad and the
block's badness being taken from whether it contains bad pages. Probably
the 'nand markbad' command tricked me.

> > > > On the other hand, I could not find code that alters this setting
> > > > based
> > > > on bad blocks found or whatever. This seems to simply be an
> > > > alternative
> > > > to setting CONFIG_ENV_OFFSET at build-time.
> > >
> > > It is set by the "nand env.oob" command.  It is currently a manual
> > > process (or rather, automation is left to the user's board  
> > preparation
> > > process rather than being built into U-Boot), as U-Boot wouldn't  
> > know
> > > how to give back unused blocks to other purposes.
> > 
> > So that assumes that any block initially identified 'good' will ever
> > turn 'bad' later on?
> 
> We don't currently have any mechanism for that to happen with the  
> environment -- which could be another good reason to have real  
> redundancy that doesn't get crippled from day one by having one copy  
> land on a factory bad block.  Of course, that requires someone to  
> implement support for redundant environment combined with  
> CONFIG_ENV_OFFSET_OOB.

Well, as long as CONFIG_ENV_OFFSET_REDUND supported falling back to the
other copy in case of error there would be a working system in three of
four cases instead of only one.

> Maybe a better option is to implement support for storing the  
> environment in ubi, although usually if your environment is in NAND  
> that means your U-Boot image is in NAND, so you have the same problem  
> there.  Maybe you could have an SPL that contains ubi support, that  
> fits in the guaranteed-good first block.
> 
> Do you have any data on how often a block might go bad that wasn't  
> factory-bad, to what extent reads versus writes matter, and whether  
> there is anything special about block zero beyond not being factory-bad?

No, sadly not. I'd guess this information depends on what hardware being
used specifically. But I suppose block zero being prone to becoming
worn just like any other block, although it not being erased as often
should help a lot.

Assuming a certain number of erase cycles after each block is worn out
and given the fact that CONFIG_ENV_OFFSET_REDUND has always both blocks
written (unless power failure occurs), they would turn bad at the same
time and therefore rendering the environment useless with or without
fallback. :)

Best wishes, Phil

-- 
Viprinet Europe GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany

Phone/Zentrale:   +49 6721 49030-0
Direct line/Durchwahl:+49 6721 49030-134
Fax:  +49 6721 49030-109

phil.sut...@viprinet.com
http://www.viprinet.com

Registered office/Sitz der Gesellschaft: Bingen am Rhein, Germany
Commercial register/Handelsregister: Amtsgericht Mainz HRB44090
CEO/Geschäftsführer: Simon Kissel
___
U-Boot mailing list
U-Boot@lists.d

Re: [U-Boot] [PATCH 2/4] env_nand.c: support falling back to redundant env when writing

[Scott Wood]

On 12/20/2012 03:28:39 PM, Phil Sutter wrote:

On Tue, Dec 11, 2012 at 05:12:32PM -0600, Scott Wood wrote:
> Erase blocks are larger than write pages, yes.  I've never heard  
erase

> blocks called "pages" or write pages called "blocks" -- but my main
> point is that the unit of erasing and the unit of badness are the  
same.


Ah, OK. Please excuse my humble nomenclature, I never cared enough to
sort out what is called what. Of course, this is not the best basis  
for

a discussion about these things.

But getting back to the topic: The assumption of blocks getting bad,  
not

pages within a block means that for any kind of bad block prevention,
multiple blocks need to be used. Although I'm honestly speaking not
really sure why this needs to be like that. Maybe the bad page marking
would disappear when erasing the block it belongs to?


Yes, it would disappear.  This is why erase operations skip bad blocks,  
unless the scrub option is uesd.



> > > The block to hold the environment is stored in the OOB of block
> > zero,
> > > which is usually guaranteed to not be bad.
> >
> > Erase or write block? Note that every write block has it's own  
OOB.

>
> "block" means "erase block".
>
> Every write page has its own OOB, but it is erase blocks that are
> marked bad.  Typically the block can be marked bad in either the  
first

> or the second page of the erase block.

Interesting. I had the impression of pages being marked bad and the
block's badness being taken from whether it contains bad pages.  
Probably

the 'nand markbad' command tricked me.


Do you mean the lack of error checking if you pass a non-block-aligned  
offset into "nand markbad"?


> > So that assumes that any block initially identified 'good' will  
ever

> > turn 'bad' later on?
>
> We don't currently have any mechanism for that to happen with the
> environment -- which could be another good reason to have real
> redundancy that doesn't get crippled from day one by having one copy
> land on a factory bad block.  Of course, that requires someone to
> implement support for redundant environment combined with
> CONFIG_ENV_OFFSET_OOB.

Well, as long as CONFIG_ENV_OFFSET_REDUND supported falling back to  
the
other copy in case of error there would be a working system in three  
of

four cases instead of only one.


I'm not sure what you mean here -- where do "three", "four", and "one"  
come from?



> Maybe a better option is to implement support for storing the
> environment in ubi, although usually if your environment is in NAND
> that means your U-Boot image is in NAND, so you have the same  
problem

> there.  Maybe you could have an SPL that contains ubi support, that
> fits in the guaranteed-good first block.
>
> Do you have any data on how often a block might go bad that wasn't
> factory-bad, to what extent reads versus writes matter, and whether
> there is anything special about block zero beyond not being  
factory-bad?


No, sadly not. I'd guess this information depends on what hardware  
being

used specifically. But I suppose block zero being prone to becoming
worn just like any other block, although it not being erased as often
should help a lot.

Assuming a certain number of erase cycles after each block is worn out
and given the fact that CONFIG_ENV_OFFSET_REDUND has always both  
blocks

written (unless power failure occurs), they would turn bad at the same
time and therefore rendering the environment useless with or without
fallback. :)


That depends on whether the specified number of erase cycles per block  
is a minimum for any block not marked factory-bad, or whether some  
fraction of non-factory-bad blocks may fail early.


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

[U-Boot] [PATCH v2] env: don't generate callback list entries for SPL

[Scott Wood]

SPL doesn't write to the environment.  These list entries prevent the
functions from being garbage-collected, even though nothing will look at
the list.  This caused several SPL builds (e.g.  P2020RDB-PC_NAND) to
break due to size limitations and/or unresolved symbols.

A static inline function is used to provide a context in which we
can consume the callback, and thus avoid unused function warnings.

Signed-off-by: Scott Wood 
Acked-by: Joe Hershberger 
---
v2: Update commit message to reflect that some SPLs do use the
environment, in a read-only fashion.  Also update commit message
to indicate that the size of the included functions wasn't the only
problem seen.
---
 include/env_callback.h |8 
 1 file changed, 8 insertions(+)

diff --git a/include/env_callback.h b/include/env_callback.h
index 47fdc6f..c583120 100644
--- a/include/env_callback.h
+++ b/include/env_callback.h
@@ -68,8 +68,16 @@ void env_callback_init(ENTRY *var_entry);
  * when associated through the ".callbacks" environment variable, the callback
  * will be executed any time the variable is inserted, overwritten, or deleted.
  */
+#ifdef CONFIG_SPL_BUILD
+#define U_BOOT_ENV_CALLBACK(name, callback) \
+   static inline void _u_boot_env_noop_##name(void) \
+   { \
+   (void)callback; \
+   }
+#else
 #define U_BOOT_ENV_CALLBACK(name, callback) \
ll_entry_declare(struct env_clbk_tbl, name, env_clbk, env_clbk) = \
{#name, callback}
+#endif
 
 #endif /* __ENV_CALLBACK_H__ */
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH] mx53loco: Fix PMIC name

[Robert Nelson]

On Tue, Dec 11, 2012 at 10:36 AM, Fabio Estevam
 wrote:
> commit c73368150 (pmic: Extend PMIC framework to support multiple instances
> of PMIC devices) has incorrectly passed the PMIC name under the FSL PMIC case.
>
> Fix that by passing "FSL_PMIC" as the parameter of pmic_get.
>
> Signed-off-by: Fabio Estevam 
> ---
>  board/freescale/mx53loco/mx53loco.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/freescale/mx53loco/mx53loco.c 
> b/board/freescale/mx53loco/mx53loco.c
> index 81c511c..2c8cb7a 100644
> --- a/board/freescale/mx53loco/mx53loco.c
> +++ b/board/freescale/mx53loco/mx53loco.c
> @@ -374,7 +374,7 @@ static int power_init(void)
> if (retval)
> return retval;
>
> -   p = pmic_get("DIALOG_PMIC");
> +   p = pmic_get("FSL_PMIC");
> if (!p)
> return -ENODEV;
>
> --
> 1.7.9.5

Hi Fabio,

It looks like we need one more fixup after commit c73368150 on the
first run/older (non R, Dialog, bug wired extra Capacitor) version of
this board..  Do you happen to have any in your lab?

U-Boot 2013.01-rc2-dirty (Dec 20 2012 - 15:55:01)

Board: MX53 LOCO
I2C:   ready
DRAM:  1 GiB
pmic_alloc: No available memory for allocation!
pmic_init: POWER allocation error!
CPU:   Freescale i.MX53 family rev2.0 at 800 MHz
Reset cause: POR
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment

(and it just keeps on resetting)

It looks to be failing after calloc...
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/power/power_core.c#l100

 100 p = calloc(sizeof(*p), 1);
 101 if (!p) {
 102 printf("%s: No available memory for
allocation!\n", __func__);
 103 return NULL;
 104 }

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] env: don't generate callback list entries for SPL

[Kim Phillips]

On Thu, 20 Dec 2012 15:51:05 -0600
Scott Wood  wrote:

> SPL doesn't write to the environment.  These list entries prevent the
> functions from being garbage-collected, even though nothing will look at
> the list.  This caused several SPL builds (e.g.  P2020RDB-PC_NAND) to
> break due to size limitations and/or unresolved symbols.
> 
> A static inline function is used to provide a context in which we
> can consume the callback, and thus avoid unused function warnings.
> 
> Signed-off-by: Scott Wood 
> Acked-by: Joe Hershberger 
> ---

Acked-by: Kim Phillips 

Thanks,

Kim

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

Re: [U-Boot] split nand writes

[Scott Wood]

On 12/20/2012 06:35:49 AM, Jaap de Jong wrote:


On 12/19/2012 11:47 PM, Scott Wood wrote:

On 12/19/2012 09:43:01 AM, Jaap de Jong wrote:

Hi All,
suppose the image I want to flash is bigger than the available ram  
in

the unit.
Is there a way to copy the image f.i. in pieces into the flash?
nand write should have a 'continue on last block' option for that
purpose.

Something like that would be nice.

These patches are relevant:
http://patchwork.ozlabs.org/patch/204939/
http://patchwork.ozlabs.org/patch/204940/

That could do the trick also. You would have to do some arithmetic to  
calculate the next startaddress in the flash.

So there is not an out-of-the-box solution at the moment?


There isn't.

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

Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat driver

[Scott Wood]

On 12/20/2012 09:05:49 AM, Chris Kiick wrote:

Hi,
  Well, you are of course 100% correct. I went back and took out the  
nand plat
stuff, made my own driver and used NAND_ECC_HW mode.  A few tweaks  
and it works

just great. No changes needed to nand base code.

  The mode names are a bit misleading, perhaps someone could document  
them in

the README?


Patches welcome. :-)

  What do I do to withdraw the patch? Or does it just get bounced out  
of the

queue.


An e-mail reply is fine (which you just did).

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

Re: [U-Boot] RFC: Secure boot framework

[Fernandes, Joel A]

Hi Simon,

Thanks for your reply.

On Tue, Dec 18, 2012 at 1:37 AM, Simon Glass  wrote:
> Hi Joel,
>
> On Mon, Dec 17, 2012 at 9:11 PM, Fernandes, Joel A  wrote:
>
>> Hi,
>>
>> Can anyone comment on what has been discussed about a framework for secure
>> boot and authentication, if there has been such a discussion, in the
>> community?
>>
>> I have some U-boot code that is based off of a slightly older U-boot which
>> does authentication and/or decryption. The main code that does the
>> cryptography is in the ROM of the SoC. However, I'm sure there will be
>> other U-boot developers requiring the crypto algorithms itself to be
>> supported.
>>
>> My questions are :
>> (1) Would a general framework for performing authentication and/or
>> decryption of signed and/or encrypted images be useful for U-boot? These
>> operations seem to make a lot of sense for a bootloader.
>
>
>> (2) Does such a framework make sense for any of your usecase(s)?
>>
>> (3) Has there been any work or discussions of coming up with such a
>> framework for U-boot?
>>
>
> We have created a secure boot system on top of U-Boot - it is in the
> Chromium tree if you want to take a look. Three ChromeOS devices have
> shipped with this so far. However it is not really suitable for generic
> upstream use, so...
>
> There have been some discussions lately on the list about using the FIT
> format to hold an image which can then be verified using a public key. We
> have put together a possible design for this and I am working on this as I
> make time.

Which Processor and silicon revision is this? Can you point to a security 
hardware specification so that I could take a quick look at the architecture 
you have in mind? Is it [1]?
Also, is it possible to share the design for modification to FIT you have put 
together so far?

>> I imagine a framework like this will atleast consist of:
>>
>> 1. General purposes cryptographic functions in a library (which we might
>> not need for our case), some light weight crypto library.
>> 2. Hooks for board/Soc-specific functions that call into the general
>> crypto lib and do any other board/SoC-specific stuff.
>> 3. General commands (in a cmd_crpto.c) that calls into the callbacks
>> mentioned in 2. for encryption and verification of an image already in
>> memory. (making it commands can allow us to leave bootm alone and do the
>> inplace decryption/verification independently - however for SPL, we don't
>> need the commands and call into 2. directly).
>> 4. Abstract any other change(s) to common boot code in a common place.
>>
>
> Yes that seems reasonable.

Thanks.

> A very basic hashing framework recently went into U-Boot, and this can be
> used to plumb in SOC hashing acceleration code. I suspect we will do the
> same with RSA, supporting a few different key lengths and associated
> padding.
>
> My plan at present is roughly (and in short order) to:
>
> 1. Define how signatures are represented in FIT

Just wondering what architecture / silicon are you using from the ChromiumOS, I 
guess its the Samsun Exynos? Anyway, isn't the representation of the signature 
and the other structure of the image fixed by your ROM or hardware 
specification? For example, to load U-boot SPL, doesn't your ROM or firmware 
expect the image signatures/certificates etc to be in a certain format? Then 
how can you use FIT for the purpose of verification/authentication?

I agree FIT can be possibly modified enough to support this, but what about the 
first-stage loading of U-boot SPL. Does your ROM or architecture understand 
FIT? I agree second-state bootloader loading and then kernel can use FIT but 
I'm not clear on how you do verified-boot for U-boot SPL for example. 
Representing U-boot SPL as FIT is not possible right.

Just a note, we run U-boot SPL from internal SRAM and not a programmable ROM.

> 2. Enhance mkimage to sign an image or a configuration (consisting of image
> +fdt, for example)
> 3. Enhance FIT command to verify an image given a public key

Yeah, this sound like a good plan.

> 4. Support checking of version information against a TPM rollback counter

I have no idea about TPM rollback, can you point to docs for that?

> 5. Work this into the bootm code
> 6. Add RSA2048/4096

cool , ok. For us right now we have ROM API that does all boot-time crypto 
(using hw acceleration where possible), but I guess those details can be 
abstracted for different secure boot architectures, and folks who need a pure 
software implementation can use it.

Thanks,
Joel

[1] 
http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot-crypto
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH RESEND V2 1/4] EXYNOS5: Change parent clock of FIMD to MPLL

[Donghwa Lee]

On 2012년 12월 20일 21:35, Ajay Kumar wrote:

With VPLL as source clock to FIMD,
Exynos DP Initializaton was failing sometimes with unstable clock.
Changing FIMD source to MPLL resolves this issue.

Signed-off-by: Ajay Kumar 
Acked-by: Simon Glass 
---
  arch/arm/cpu/armv7/exynos/clock.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
b/arch/arm/cpu/armv7/exynos/clock.c
index fe61f88..bfcd5f7 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -603,7 +603,7 @@ void exynos5_set_lcd_clk(void)
 */
cfg = readl(&clk->src_disp1_0);
cfg &= ~(0xf);
-   cfg |= 0x8;
+   cfg |= 0x6;
writel(cfg, &clk->src_disp1_0);
  
  	/*

It looks good to me.
Acked-by: Donghwa Lee 

Thank you,
Donghwa Lee
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/4] EXYNOS: Add dummy definition to fix compilation dependency on CONFIG_EXYNOS_MIPI_DSIM

[Donghwa Lee]

On 2012년 12월 20일 21:35, Ajay Kumar wrote:

When only DP is used, we need not enable CONFIG_EXYNOS_MIPI_DSIM.
But if we do not select CONFIG_EXYNOS_MIPI_DSIM, exynos_fb.c throws
error saying exynos_mipi_dsi_init() not defined. So, we add
dummy definition for exynos_mipi_dsi_init when CONFIG_EXYNOS_MIPI_DSIM
is not defined.

Signed-off-by: Ajay Kumar 
---
  arch/arm/include/asm/arch-exynos/mipi_dsim.h |7 +++
  1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/arch-exynos/mipi_dsim.h 
b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
index 9a7cbeb..b73263d 100644
--- a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
+++ b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
@@ -358,7 +358,14 @@ struct mipi_dsim_lcd_driver {
void(*mipi_display_on)(struct mipi_dsim_device *dsim_dev);
  };
  
+#ifdef CONFIG_EXYNOS_MIPI_DSIM

  int exynos_mipi_dsi_init(void);
+#else
+int exynos_mipi_dsi_init(void)
+{
+   return 0;
+}
+#endif
  
  /*

   * register mipi_dsim_lcd_driver object defined by lcd panel driver

It looks good to me.
Acked-by: Donghwa Lee 

Thank you,
Donghwa Lee
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 3/4] video: Modify exynos_fimd driver to support LCD console

[Donghwa Lee]

On 2012년 12월 20일 21:35, Ajay Kumar wrote:

Currently, exynos FIMD driver is being used to support only TIZEN LOGOs.
In order to get LCD console, we need to enable half word swap feature
of FIMD and use 16 BPP.
LCD console and proprietary Logo cannot be used simultaneously.
You should define CONFIG_EXYNOS_LOGO for proprietary Logo, and if
CONFIG_EXYNOS_LOGO is not defined you get output console on LCD.
CONFIG_EXYNOS_LOGO is added to Trats configuration to keep
existing logo feature intact in Trats.

Signed-off-by: Ajay Kumar 
---
  drivers/video/exynos_fb.c   |5 -
  drivers/video/exynos_fimd.c |   10 --
  include/configs/trats.h |1 +
  3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index d9a3f9a..c111a09 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -65,6 +65,7 @@ static void exynos_lcd_init(vidinfo_t *vid)
exynos_fimd_lcd_init(vid);
  }
  
+#ifdef CONFIG_EXYNOS_LOGO

  static void draw_logo(void)
  {
int x, y;
@@ -87,6 +88,7 @@ static void draw_logo(void)
addr = panel_info.logo_addr;
bmp_display(addr, x, y);
  }
+#endif
  
  static void lcd_panel_on(vidinfo_t *vid)

  {
@@ -142,12 +144,13 @@ void lcd_ctrl_init(void *lcdbase)
  
  void lcd_enable(void)

  {
+#ifdef CONFIG_EXYNOS_LOGO
if (panel_info.logo_on) {
memset(lcd_base, 0, panel_width * panel_height *
(NBITS(panel_info.vl_bpix) >> 3));
draw_logo();
}
-
+#endif
lcd_panel_on(&panel_info);
  }
  
diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c

index 06eae2e..f2e4c27 100644
--- a/drivers/video/exynos_fimd.c
+++ b/drivers/video/exynos_fimd.c
@@ -88,14 +88,20 @@ static void exynos_fimd_set_par(unsigned int win_id)
/* DATAPATH is DMA */
cfg |= EXYNOS_WINCON_DATAPATH_DMA;
  
-	/* bpp is 32 */

+#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
cfg |= EXYNOS_WINCON_WSWP_ENABLE;
+#else  /* To get output console on LCD */
+   cfg |= EXYNOS_WINCON_HAWSWP_ENABLE;
+#endif
  
  	/* dma burst is 16 */

cfg |= EXYNOS_WINCON_BURSTLEN_16WORD;
  
-	/* pixel format is unpacked RGB888 */

+#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
cfg |= EXYNOS_WINCON_BPPMODE_24BPP_888;
+#else  /* To get output console on LCD */
+   cfg |= EXYNOS_WINCON_BPPMODE_16BPP_565;
+#endif
  
  	writel(cfg, (unsigned int)&fimd_ctrl->wincon0 +

EXYNOS_WINCON(win_id));
diff --git a/include/configs/trats.h b/include/configs/trats.h
index a24e945..1573573 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -252,6 +252,7 @@
  #define CONFIG_EXYNOS_FB
  #define CONFIG_LCD
  #define CONFIG_CMD_BMP
+#define CONFIG_EXYNOS_LOGO
  #define CONFIG_BMP_32BPP
  #define CONFIG_FB_ADDR0x52504000
  #define CONFIG_S6E8AX0

Hi,

How about use 'if (vid->logo_on)' instead of #ifdef CONFIG_EXYNOS_LOGO?
In the vidinfo_t structure, 'logo_on' flag already exist.

Thank you,
Donghwa Lee

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

Re: [U-Boot] [PATCH v2 1/7] usb: net: asix: Do a fast init if link already established

[Joe Hershberger]

Hi Simon,

On Thu, Dec 13, 2012 at 8:21 PM, Simon Glass  wrote:
> The Asix driver takes the link down during init() and then brings it back up.
> This commit changes this so that if a link has already been established
> successfully we simply check that the link is still good.
>
> Also fix up asix_halt() to actually halt RX on the interface. Previously this
> was not done, so the device would continue to operate evern when halted,
> violating a U-Boot requirement.
>
> This reduces the delay between successive network commands.
> Signed-off-by: Simon Glass 
> ---
> Changes in v2: None

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

Re: [U-Boot] [PATCH v2 5/7] usb: usbeth: smsc95xx: remove EEPROM loaded check

[Joe Hershberger]

Hi Simon,

On Thu, Dec 13, 2012 at 8:21 PM, Simon Glass  wrote:
> From: Michael Spang 
>
> [port of Linux kernel commit bcd218be5aeb by Steve Glendinning]
>
> The eeprom read & write commands currently check the E2P_CMD_LOADED_ bit is
> set before allowing any operations.  This prevents any reading or writing
> unless a correctly programmed EEPROM is installed.
>
> Signed-off-by: Michael Spang 
> Signed-off-by: Simon Glass 
> Acked-by: Marek Vasut 
> ---

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

Re: [U-Boot] [PATCH V3 3/4] video: Modify exynos_fimd driver to support LCD console

[Minkyu Kang]

Dear Ajay,

On 21/12/12 10:53, Donghwa Lee wrote:
> On 2012년 12월 20일 21:35, Ajay Kumar wrote:
>> Currently, exynos FIMD driver is being used to support only TIZEN LOGOs.
>> In order to get LCD console, we need to enable half word swap feature
>> of FIMD and use 16 BPP.
>> LCD console and proprietary Logo cannot be used simultaneously.
>> You should define CONFIG_EXYNOS_LOGO for proprietary Logo, and if
>> CONFIG_EXYNOS_LOGO is not defined you get output console on LCD.
>> CONFIG_EXYNOS_LOGO is added to Trats configuration to keep
>> existing logo feature intact in Trats.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>>   drivers/video/exynos_fb.c   |5 -
>>   drivers/video/exynos_fimd.c |   10 --
>>   include/configs/trats.h |1 +
>>   3 files changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
>> index d9a3f9a..c111a09 100644
>> --- a/drivers/video/exynos_fb.c
>> +++ b/drivers/video/exynos_fb.c
>> @@ -65,6 +65,7 @@ static void exynos_lcd_init(vidinfo_t *vid)
>>   exynos_fimd_lcd_init(vid);
>>   }
>>   +#ifdef CONFIG_EXYNOS_LOGO
>>   static void draw_logo(void)
>>   {
>>   int x, y;
>> @@ -87,6 +88,7 @@ static void draw_logo(void)
>>   addr = panel_info.logo_addr;
>>   bmp_display(addr, x, y);
>>   }
>> +#endif
>> static void lcd_panel_on(vidinfo_t *vid)
>>   {
>> @@ -142,12 +144,13 @@ void lcd_ctrl_init(void *lcdbase)
>> void lcd_enable(void)
>>   {
>> +#ifdef CONFIG_EXYNOS_LOGO
>>   if (panel_info.logo_on) {
>>   memset(lcd_base, 0, panel_width * panel_height *
>>   (NBITS(panel_info.vl_bpix) >> 3));
>>   draw_logo();
>>   }
>> -
>> +#endif
>>   lcd_panel_on(&panel_info);
>>   }
>>   diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
>> index 06eae2e..f2e4c27 100644
>> --- a/drivers/video/exynos_fimd.c
>> +++ b/drivers/video/exynos_fimd.c
>> @@ -88,14 +88,20 @@ static void exynos_fimd_set_par(unsigned int win_id)
>>   /* DATAPATH is DMA */
>>   cfg |= EXYNOS_WINCON_DATAPATH_DMA;
>>   -/* bpp is 32 */
>> +#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
>>   cfg |= EXYNOS_WINCON_WSWP_ENABLE;
>> +#else/* To get output console on LCD */
>> +cfg |= EXYNOS_WINCON_HAWSWP_ENABLE;
>> +#endif
>> /* dma burst is 16 */
>>   cfg |= EXYNOS_WINCON_BURSTLEN_16WORD;
>>   -/* pixel format is unpacked RGB888 */
>> +#ifdef CONFIG_EXYNOS_LOGO /* To get proprietary LOGO */
>>   cfg |= EXYNOS_WINCON_BPPMODE_24BPP_888;
>> +#else/* To get output console on LCD */
>> +cfg |= EXYNOS_WINCON_BPPMODE_16BPP_565;
>> +#endif
>> writel(cfg, (unsigned int)&fimd_ctrl->wincon0 +
>>   EXYNOS_WINCON(win_id));
>> diff --git a/include/configs/trats.h b/include/configs/trats.h
>> index a24e945..1573573 100644
>> --- a/include/configs/trats.h
>> +++ b/include/configs/trats.h
>> @@ -252,6 +252,7 @@
>>   #define CONFIG_EXYNOS_FB
>>   #define CONFIG_LCD
>>   #define CONFIG_CMD_BMP
>> +#define CONFIG_EXYNOS_LOGO
>>   #define CONFIG_BMP_32BPP
>>   #define CONFIG_FB_ADDR0x52504000
>>   #define CONFIG_S6E8AX0
> Hi,
> 
> How about use 'if (vid->logo_on)' instead of #ifdef CONFIG_EXYNOS_LOGO?
> In the vidinfo_t structure, 'logo_on' flag already exist.

I agreed with Donghwa.
Ajay, please check it.

> 
> Thank you,
> Donghwa Lee
> 

Thanks.
Minkyu Kang.

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

[U-Boot] no mtdparted from U-Boot> prompt

[jo...@msli.com]

This is my first post to the list.
I am using u-boot-1.3.4 in buildroot-2011.11
My device is a at91sam9g20-ek
I have a patch adding: include/configs/at91sam9g20ek.h
which I gather acts as a config file for u-boot.

U-Boot> help
does not list mtdparts

But my bootargs does use it:
bootargs=mem=64M console=ttyS0,115200 
mtdparts=atmel_nand:4M(bootstrap/uboot/kernel)ro,60M(rootfs),-(data) 
root=/dev/mtdblock1 rw rootfstype=jffs2

Is there a trick to add the mtdparts command?
Or is there supposed to be a command?

I unsuccessfully added to include/configs/at91sam9g20ek.h
#define CONFIG_JFFS2_NAND 1
#define CONFIG_JFFS2_CMDLINE 1
#define CONFIG_CMD_JFFS2 1 // Required to include cmd_jffs2.c
which did not result in adding the command line.




NOTICE: This email may contain confidential information.  Please see 
http://www.meyersound.com/confidential/ for our complete policy.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/9] EXYNOS5: DWMMC: API to set mmc clock divisor

[Amarendra Reddy]

Hi Simon,

Thanks for your review comments.
Please find the responses below.

Thanks & Regards
Amarendra Reddy

On 20 December 2012 07:54, Simon Glass  wrote:

> Hi Amar,
>
> On Mon, Dec 17, 2012 at 3:19 AM, Amar  wrote:
>
> > This API computes the divisor value based on MPLL clock and
> > writes it into the FSYS1 register.
> >
> > Signed-off-by: Amar 
> > ---
> >  arch/arm/cpu/armv7/exynos/clock.c  |   39
> > ++-
> >  arch/arm/include/asm/arch-exynos/clk.h |1 +
> >  2 files changed, 38 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv7/exynos/clock.c
> > b/arch/arm/cpu/armv7/exynos/clock.c
> > index 731bbff..6517296 100644
> > --- a/arch/arm/cpu/armv7/exynos/clock.c
> > +++ b/arch/arm/cpu/armv7/exynos/clock.c
> > @@ -379,7 +379,7 @@ static unsigned long exynos4_get_mmc_clk(int
> dev_index)
> > (struct exynos4_clock *)samsung_get_base_clock();
> > unsigned long uclk, sclk;
> > unsigned int sel, ratio, pre_ratio;
> > -   int shift;
> > +   int shift = 0;
> >
> > sel = readl(&clk->src_fsys);
> > sel = (sel >> (dev_index << 2)) & 0xf;
> > @@ -428,7 +428,7 @@ static unsigned long exynos5_get_mmc_clk(int
> dev_index)
> > (struct exynos5_clock *)samsung_get_base_clock();
> > unsigned long uclk, sclk;
> > unsigned int sel, ratio, pre_ratio;
> > -   int shift;
> > +   int shift = 0;
> >
> > sel = readl(&clk->src_fsys);
> > sel = (sel >> (dev_index << 2)) & 0xf;
> > @@ -526,6 +526,41 @@ static void exynos5_set_mmc_clk(int dev_index,
> > unsigned int div)
> > writel(val, addr);
> >  }
> >
> > +/* exynos5: set the mmc clock div ratio in fsys1 */
> > +int exynos5_mmc_set_clk_div(int dev_index)
> >
>
> Shouldn't this take a periph_id instead of a dev_index?
>


>  Ok will convert index int to peripheral_id in the calling function.
>
> > +{
> > +   struct exynos5_clock *clk =
> > +   (struct exynos5_clock *)samsung_get_base_clock();
> > +   unsigned int addr;
> > +   unsigned int clock;
> > +   unsigned int tmp;
> > +   unsigned int i;
> > +
> > +   /* get mpll clock */
> > +   clock = get_pll_clk(MPLL) / 100;
> > +
> > +   /*
> > +* CLK_DIV_FSYS1
> > +* MMC0_PRE_RATIO [15:8], MMC0_RATIO [3:0]
> > +* CLK_DIV_FSYS2
> > +* MMC2_PRE_RATIO [15:8], MMC2_RATIO [3:0]
> > +*/
> > +   if (dev_index < 2) {
> > +   addr = (unsigned int)&clk->div_fsys1;
> > +   } else {
> > +   addr = (unsigned int)&clk->div_fsys2;
> > +   }
> > +
> > +   tmp = readl(addr) & ~FSYS1_MMC0_DIV_MASK;
> > +   for (i = 0; i <= 0xf; i++) {
> > +   if ((clock / (i + 1)) <= 400) {
> > +   writel(tmp | i << 0, addr);
> > +   break;
> > +   }
> > +   }
> > +   return 0;
> > +}
> > +
> >  /* get_lcd_clk: return lcd clock frequency */
> >  static unsigned long exynos4_get_lcd_clk(void)
> >  {
> > diff --git a/arch/arm/include/asm/arch-exynos/clk.h
> > b/arch/arm/include/asm/arch-exynos/clk.h
> > index ff155d8..b0ecdd4 100644
> > --- a/arch/arm/include/asm/arch-exynos/clk.h
> > +++ b/arch/arm/include/asm/arch-exynos/clk.h
> > @@ -36,6 +36,7 @@ unsigned long get_pwm_clk(void);
> >  unsigned long get_uart_clk(int dev_index);
> >  unsigned long get_mmc_clk(int deV_index);
> >  void set_mmc_clk(int dev_index, unsigned int div);
> > +int exynos5_mmc_set_clk_div(int dev_index);
> >  unsigned long get_lcd_clk(void);
> >  void set_lcd_clk(void);
> >  void set_mipi_clk(void);
> > --
> > 1.7.0.4
> >
> >
> Regards,
> Simon
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/9] EXYNOS5: DWMMC: Added dt support for DWMMC

[Amarendra Reddy]

Hi Simon,

Thanks for your review comments.
Please find the responses below.

Thanks & Regards
Amarendra Reddy

On 20 December 2012 07:53, Simon Glass  wrote:

> Hi Amar,
>
> On Mon, Dec 17, 2012 at 3:19 AM, Amar  wrote:
>
> > Signed-off-by: Amar 
> >
>
> Good to see this patch! Please can you add a short commit message?
>  Oops.. sorry. I will put the commit msg.
>
> > ---
>
>  arch/arm/include/asm/arch-exynos/dwmmc.h |4 +
> >  drivers/mmc/exynos_dw_mmc.c  |  117
> > --
> >  include/dwmmc.h  |4 +
> >  3 files changed, 119 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-exynos/dwmmc.h
> > b/arch/arm/include/asm/arch-exynos/dwmmc.h
> > index 8acdf9b..92352df 100644
> > --- a/arch/arm/include/asm/arch-exynos/dwmmc.h
> > +++ b/arch/arm/include/asm/arch-exynos/dwmmc.h
> > @@ -27,6 +27,9 @@
> >  #define DWMCI_SET_DRV_CLK(x)   ((x) << 16)
> >  #define DWMCI_SET_DIV_RATIO(x) ((x) << 24)
> >
> > +#ifdef CONFIG_OF_CONTROL
> > +unsigned int exynos_dwmmc_init(const void *blob);
> > +#else
> >  int exynos_dwmci_init(u32 regbase, int bus_width, int index);
> >
> >  static inline unsigned int exynos_dwmmc_init(int index, int bus_width)
> > @@ -34,3 +37,4 @@ static inline unsigned int exynos_dwmmc_init(int index,
> > int bus_width)
> > unsigned int base = samsung_get_base_mmc() + (0x1 * index);
> > return exynos_dwmci_init(base, bus_width, index);
> >  }
> > +#endif
> > diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
> > index 72a31b7..3b3e3e5 100644
> > --- a/drivers/mmc/exynos_dw_mmc.c
> > +++ b/drivers/mmc/exynos_dw_mmc.c
> > @@ -19,23 +19,38 @@
> >   */
> >
> >  #include 
> > -#include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> > +
> > +#defineDWMMC_MAX_CH_NUM4
> > +#defineDWMMC_MAX_FREQ  5200
> > +#defineDWMMC_MIN_FREQ  40
> > +#defineDWMMC_MMC0_CLKSEL_VAL   0x03030001
> > +#defineDWMMC_MMC2_CLKSEL_VAL   0x03020001
> >
>
> What do these last two values mean? I think clock setting should be done in
> clock.c, not here.
>
> In case of non-dt support, these two values are written into respective
clock selection register-CLKSEL, to select the clock for MMC-channel0 and
MMC-channel2.
Will move clock setting into clock.c and the #defines will be moved into
include/asm/arch/clk.h.

>
> >
> >  static char *EXYNOS_NAME = "EXYNOS DWMMC";
> >
> >  static void exynos_dwmci_clksel(struct dwmci_host *host)
> >  {
> > -   u32 val;
> > -   val = DWMCI_SET_SAMPLE_CLK(DWMCI_SHIFT_0) |
> > -   DWMCI_SET_DRV_CLK(DWMCI_SHIFT_0) |
> DWMCI_SET_DIV_RATIO(0);
> > +   dwmci_writel(host, DWMCI_CLKSEL, host->clksel_val);
> > +}
> >
> > -   dwmci_writel(host, DWMCI_CLKSEL, val);
> > +unsigned int exynos_dwmci_get_clk(int dev_index)
> > +{
> > +   return get_mmc_clk(dev_index);
> >  }
> >
> > +#ifdef CONFIG_OF_CONTROL
> > +static int exynos_dwmci_init(u32 regbase, int bus_width,
> > +   int index, u32 *timing)
> > +#else
> >  int exynos_dwmci_init(u32 regbase, int bus_width, int index)
> > +#endif
> >
>
> I'm really not keen on having the same function with different signatures.
> My first question is whether we need to support operation without
> CONFIG_OF_CONTROL. If so, I suggest having an init routine that takes an
> FDT blob as a parameter, and a separate add_port function which can be
> called by non-FDT-enabled board files. The init routine will call the
> add_port function for each port it finds in the FDT.
>
> I think we need support operation without CONFIG_OF_CONTROL atleast untill
the entire FDT is formed.
Hence I will implement it as per your suggestion.


> Also please can you briefly comment non-trivial functions?
>  OK.
>
> >  {
> > struct dwmci_host *host = NULL;
> > host = malloc(sizeof(struct dwmci_host));
> > @@ -44,14 +59,104 @@ int exynos_dwmci_init(u32 regbase, int bus_width,
> int
> > index)
> > return 1;
> > }
> >
> > +   /* set the clock divisor - clk_div_fsys for mmc */
> > +   if (exynos5_mmc_set_clk_div(index)) {
> > +   debug("mmc clock div set failed\n");
> > +   return -1;
> > +   }
> > +
> > host->name = EXYNOS_NAME;
> > host->ioaddr = (void *)regbase;
> > host->buswidth = bus_width;
> > +#ifdef CONFIG_OF_CONTROL
> > +   host->clksel_val = (DWMCI_SET_SAMPLE_CLK(timing[0]) |
> > +   DWMCI_SET_DRV_CLK(timing[1]) |
> > +   DWMCI_SET_DIV_RATIO(timing[2]));
> > +#else
> > +   if (0 == index)
> > +   host->clksel_val = DWMMC_MMC0_CLKSEL_VAL;
> > +   if (2 == index)
> > +   host->clksel_val = DWMMC_MMC2_CLKSEL_VAL;
> > +#endif
> > host->clkse

Re: [U-Boot] [PATCH 6/9] SMDK5250: Enable DWMMC

[Amarendra Reddy]

Hi Simon,

Thanks for the review comments.
Please find the responses below.

Thanks & Regards
Amarendra Reddy

On 20 December 2012 07:59, Simon Glass  wrote:

> Hi Amar,
>
> On Mon, Dec 17, 2012 at 3:19 AM, Amar  wrote:
>
> > This patch enables DWMMC for SMDK5250.
> > Support both dt and non-dt versions.
> >
> > Signed-off-by: Amar 
> > ---
> >  board/samsung/smdk5250/smdk5250.c |   36
> > 
> >  include/configs/exynos5250-dt.h   |9 +
> >  2 files changed, 41 insertions(+), 4 deletions(-)
> >
> > diff --git a/board/samsung/smdk5250/smdk5250.c
> > b/board/samsung/smdk5250/smdk5250.c
> > index 4d24978..7a9c8f6 100644
> > --- a/board/samsung/smdk5250/smdk5250.c
> > +++ b/board/samsung/smdk5250/smdk5250.c
> > @@ -27,6 +27,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -192,16 +193,43 @@ int checkboard(void)
> >  #ifdef CONFIG_GENERIC_MMC
> >  int board_mmc_init(bd_t *bis)
> >  {
> > -   int err;
> > +   int err = 0, ret = 0;
> >
> > +#ifdef CONFIG_OF_CONTROL
> > +   /* dwmmc initializattion for available channels */
> > +   err = exynos_dwmmc_init(gd->fdt_blob);
> > +   if (err) {
> > +   debug("dwmmc init failed\n");
> > +   }
> > +   ret |= err;
> > +#else
> > err = exynos_pinmux_config(PERIPH_ID_SDMMC0,
> > PINMUX_FLAG_8BIT_MODE);
> > if (err) {
> > debug("SDMMC0 not configured\n");
> > -   return err;
> > }
> > +   ret |= err;
> >
>
> Perhaps we need an exynos5-dt.c board file instead of using smdk5250? It
> seems like you will end up with lots of #ifdefs otherwise.
>
> OK.
>


> >
> > -   err = s5p_mmc_init(0, 8);
> > -   return err;
> > +   /*eMMC: dwmmc Channel-0 with 8 bit bus width */
> > +   err = exynos_dwmmc_init(0, 8);
> > +   if (err) {
> > +   debug("dwmmc Channel-0 init failed\n");
> >
>
> Don't need {} here.
> OK.
>
> > +   }
> > +   ret |= err;
> > +
> > +   err = exynos_pinmux_config(PERIPH_ID_SDMMC2, PINMUX_FLAG_NONE);
> > +   if (err) {
> > +   debug("SDMMC2 not configured\n");
> >
>
> and here
> OK.
>
> > +   }
> > +   ret |= err;
> > +
> > +   /*SD: dwmmc Channel-2 with 4 bit bus width */
> > +   err = exynos_dwmmc_init(2, 4);
> > +   if (err) {
> > +   debug("dwmmc Channel-2 init failed\n");
> > +   }
> > +   ret |= err;
> > +#endif
> > +   return ret;
> >  }
> >  #endif
> >
> > diff --git a/include/configs/exynos5250-dt.h
> > b/include/configs/exynos5250-dt.h
> > index 12f555c..3b89e20 100644
> > --- a/include/configs/exynos5250-dt.h
> > +++ b/include/configs/exynos5250-dt.h
> > @@ -84,6 +84,8 @@
> >  #define CONFIG_MMC
> >  #define CONFIG_SDHCI
> >  #define CONFIG_S5P_SDHCI
> > +#define CONFIG_DWMMC
> >
>
> What does this config enable? Is it in a README somewhere?
> CONFIG_DWMMC is for enaling DWMMC. It has to be added into README.
>

> > +#define CONFIG_EXYNOS_DWMMC
> >
> >  #define CONFIG_BOARD_EARLY_INIT_F
> >
> > @@ -116,6 +118,13 @@
> >  #define CONFIG_SPL
> >  #define COPY_BL2_FNPTR_ADDR0x02020030
> >
> > +/* eMMC4.4 SPL */
> > +#define EMMC44_COPY_BL2_FNPTR_ADDR 0x02020044
> > +#define EMMC44_END_BOOTOP_FNPTR_ADDR   0x02020048
> >
>
> What are these for?
>
> These are the IROM function pointers used druing SPL boot.
>  Any how these #defines wii be removed, as a table for all iROM function
> pointers will be maintained in spl_boot.c.
>
> +
> > +#define FSYS1_MMC0_DIV_MASK0xff0f
> >
>
> This seems like something for the SOC headers, not the board header.
>
> FSYS1_MMC0_DIV_MASK will be moved into include/asm/arch/clk.h
>


> > +
> > +
> >  /* specific .lds file */
> >  #define CONFIG_SPL_LDSCRIPT
> >  "board/samsung/smdk5250/smdk5250-uboot-spl.lds"
> >  #define CONFIG_SPL_TEXT_BASE   0x02023400
> > --
> > 1.7.0.4
> >
> >
> Regards,
> Simon
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2 1/6] cmd_sf: Add print messages on flash erase command

[Jagan Teki]

Hi Wolfgang Denk,

On Thu, Dec 20, 2012 at 6:19 PM, Wolfgang Denk  wrote:
> Dear Jagan Teki,
>
> In message 
>  you 
> wrote:
>>
>> Apart from this sometimes (very rare) due to the slowness of UART or SPI 
>> flash
>> even if we run the sf commands it will not execute the actual code
>> just terminate with showing
>> u-boot prompt, so the user assumes that this command is happen
>> properly. [but actually command is not done]
>
> But that would be a different thing - if there are errors without
> clear error messages, this is a bug that needs fixing.  [But I do not
> see which part of your patch would address such an issue.  Am I
> missing something?]

Basically if there is an error while executing these commands,
then this print will show an :ERROR based on the return value from
spi_flash_erase.
 of-course there is a verbose print already if spi_flash_erase
returns 1 (error case).

OK, I agree my patch will show only verbose prints for both in Success
and Failure cases.

I thought it could be a good progress prints for sf read/write/erase
commands as we didn't have
these verbose prints before.

Do you think these are useful/required messages?, please take my above concerns.

Thanks,
Jagan.

>
> Adding verbose progress messages is a different thing, though.
>
> 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 much easier to suggest solutions when you know nothing
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2 1/6] cmd_sf: Add print messages on flash erase command

[Wolfgang Denk]

Dear Jagan Teki,

In message  
you wrote:
> 
> I thought it could be a good progress prints for sf read/write/erase
> commands as we didn't have
> these verbose prints before.
> 
> Do you think these are useful/required messages?, please take my above 
> concerns.

Some people will like such verbocity, others will dislike it.  Also,
some people will dislike th memory footprint that comes with the added
code.  So in any case this should be configurable.

But most of all: SF is just one storage device out of a much larger
list.  If we add such a feature, it should be done in common code and
in a generic way that all similar devices can use as well.

Please see again the other thread, and Simon's response.  I think it
makes sense to handle these things together, as a common set of
patches.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The only person who always got his work done by Friday
 was Robinson Crusoe.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] powerpc/mpc8572ds: Enable bank interleaving to cs0+cs1 for dual-rank DIMMs

[Jia Hongtao]

The controller interleaving only takes the usable memory mapped to cs0. In
the case of bank interleaving not enabled, only half of dual-rank DIMM will
be used.

For single-rank DIMM bank interleaving will be auto disabled.

Signed-off-by: Jia Hongtao 
Signed-off-by: Li Yang 
---
 include/configs/MPC8572DS.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/MPC8572DS.h b/include/configs/MPC8572DS.h
index a62b7d5..d233365 100644
--- a/include/configs/MPC8572DS.h
+++ b/include/configs/MPC8572DS.h
@@ -735,7 +735,7 @@
 #define CONFIG_BAUDRATE115200
 
 #defineCONFIG_EXTRA_ENV_SETTINGS   \
-"hwconfig=fsl_ddr:ctlr_intlv=bank,ecc=off\0"   \
+"hwconfig=fsl_ddr:ctlr_intlv=bank,bank_intlv=cs0_cs1,ecc=off\0"
\
 "netdev=eth0\0"\
 "uboot=" __stringify(CONFIG_UBOOTPATH) "\0"\
 "tftpflash=tftpboot $loadaddr $uboot; "\
-- 
1.7.5.1


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

[U-Boot] [PATCH] powerpc/mpc8544ds: Add USB controller support for MPC8544DS

[Jia Hongtao]

USB controller in uboot is a required feature for MPC8544DS. Without this
support there is no 'usb' command in uboot.

Signed-off-by: Jia Hongtao 
Signed-off-by: Li Yang 
---
 include/configs/MPC8544DS.h |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/include/configs/MPC8544DS.h b/include/configs/MPC8544DS.h
index 83b8668..d5f3c5f 100644
--- a/include/configs/MPC8544DS.h
+++ b/include/configs/MPC8544DS.h
@@ -415,6 +415,18 @@ extern unsigned long get_board_sys_clk(unsigned long 
dummy);
 #define CONFIG_CMD_EXT2
 #endif
 
+/*
+ * USB
+ */
+#define CONFIG_USB_EHCI
+
+#ifdef CONFIG_USB_EHCI
+#define CONFIG_CMD_USB
+#define CONFIG_USB_EHCI_PCI
+#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
+#define CONFIG_USB_STORAGE
+#define CONFIG_PCI_EHCI_DEVICE 0
+#endif
 
 #undef CONFIG_WATCHDOG /* watchdog disabled */
 
-- 
1.7.5.1


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

Re: [U-Boot] [PULL] u-boot-usb/master

[Igor Grinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/20/12 16:30, Tom Rini wrote:
> On Tue, Dec 18, 2012 at 07:19:10PM +0100, Marek Vasut wrote:
> 
>> I reduced it, DFU will have to wait, sorry.
>>
>> The following changes since commit ebbf0d20aa85f623c49b7ed3349ebfea450c152d:
>>
>>   Prepare v2013.01-rc2 (2012-12-14 14:43:22 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.denx.de/u-boot-usb.git master
>>
>> for you to fetch changes up to 4f8dd5920f52462a9a5d794dc310a9a7a49ca89b:
>>
>>   cm_t35: use new low level interface for usb ehci (2012-12-17 15:38:15 
>> +0100)
>>
>> 
>> Lukasz Dalek (2):
>>   pxa25x_udc: Remove usbdescriptors.h
>>   h2200: Add USB CDC ethernet support
>>
>> Milind Choudhary (1):
>>   usb: Clean up newly allocated device nodes in case of configuration 
>> failure
>>
>> Nikita Kiryanov (2):
>>   cm-t35: add USB host support
>>   cm_t35: use new low level interface for usb ehci
>>
>> Pantelis Antoniou (2):
>>   g_dnl: Issue connect/disconnect as appropriate
>>   g_dnl: Properly terminate string list.
>>
>> Richard Genoud (1):
>>   usb documentation: fix typo
>>
>> Vincent Palatin (1):
>>   usb: properly detect empty mass storage media reader
>>
>> Vipin Kumar (1):
>>   usbh/ehci: Increase timeout for enumeration
>>
>>  board/cm_t35/cm_t35.c   |   77 
>> +
>>  board/h2200/h2200.c |   11 +++
>>  common/usb.c|   12 
>>  common/usb_hub.c|   35 ++-
>>  common/usb_storage.c|   10 ++
>>  doc/README.usb  |2 +-
>>  drivers/usb/gadget/g_dnl.c  |   12 +++-
>>  drivers/usb/gadget/pxa25x_udc.c |1 -
>>  include/configs/cm_t35.h|8 +++-
>>  include/configs/h2200.h |   25 +
>>  include/usb.h   |1 +
>>  11 files changed, 185 insertions(+), 9 deletions(-)
> 
> The cm_t35 parts don't compile, NAK.
> cm_t35.c: In function 'ehci_hcd_init':
> cm_t35.c:522:34: error: 'TWL4030_GPIO_GPIODATADIR1' undeclared (first
> use in this function)
> cm_t35.c:522:34: note: each undeclared identifier is reported only once
> for each function it appears in
> cm_t35.c:527:34: error: 'TWL4030_GPIO_SETGPIODATAOUT1' undeclared (first
> use in this function)

In the original pull request, there was another patch:
twl4030: add gpio register offsets

which got dropped somehow...

Marek, can you please, fix this?


- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQ1Af9AAoJEBDE8YO64Efa1vQP/0cG6TEiqzfqqZKyQyi29QRU
+0Wa2t/HoyY8/tscN2PyVln3QW6g7Xtf0lAREegoiJMfKiPIgT1raUAyi2HbjACq
uSaBCNMJjEgSS4fLl7NTgCuxGWZk5cQTnrRrwUATLmhci3pwZ2CsmEE9jqdtoelk
076CzJSLgPUr3X0/cxmKdw7/CNWMOrfLkLET0t9Lmt2ZsJOhzJ9wOWAHk+xiVeHZ
YXVj1DRfBK1YVEd/o/58lt/EZ4mRTVSLR4zfLgGp5VOBj7UcxjIpTYaGhD7KbTCZ
W23zHnrjsGp73qQKopgiawjptAkMnGJpHYZdD8mzSx0IzIXXg4UBgHZfH0gRHlaP
iTg6KAQCk0BSO6oOntKlNYro9xVzoy/8KIKr8pr3FJM0tuh/gGBK4HmbHHl2IVzs
rU1teFvkmKktxTqShlfyEQKJHs4nzefnbsHmzKOzf8DvphnEoKsSjket8+J0dRnk
q4xVFWiq+kj6rBLmnHVrZHTmYugZfXO5U+4r9TvgcH8GR8aIKMuxgw9ofD5ejpib
SC4DV3NHQczXHNN1YoILt87gpDWUUCtbrGYFZvZJ1hXd5MYb/DXitFNdbHqIouSB
/SlgXj8ncHbW6pVwiOdu+P4EclmumD0+pRimIgfZRj1QiEAEaT63d/EvGzDChhWi
QtlYLz8b/BJMKgZUzvOg
=Nw5X
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot