Re: [U-Boot] Pull request - fpga

[Michal Simek]

Hi Tom,

please pull these 3 changes to your tree.

Thanks,
Michal


The following changes since commit e5a9a4076f1fb9fb9ce53c2aec32422073bbc66a:

  pxe: fix handling of absolute paths (2013-11-04 11:24:22 -0500)

are available in the git repository at:

  git://www.denx.de/git/u-boot-microblaze.git fpga

for you to fetch changes up to 32d7cdd366a1516fa498464c261851f3a76a62ef:

  fpga: Add support for gzip images with bitstreams (2013-11-06 09:15:12 +0100)


Jagannadha Sutradharudu Teki (1):
  fpga: zynqpl: Add dcache flush support

Michal Simek (2):
  fpga: zynqpl: Do not place bitstream below 1MB
  fpga: Add support for gzip images with bitstreams

 common/cmd_fpga.c | 22 +++---
 drivers/fpga/zynqpl.c | 15 +--
 2 files changed, 32 insertions(+), 5 deletions(-)

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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

Re: [U-Boot] [PATCH] serial: zynq: Remove unused #defines

[Michal Simek]

Hi Tom,

On 10/30/2013 03:49 PM, Michal Simek wrote:
> From: Soren Brinkmann 
> 
> Signed-off-by: Soren Brinkmann 
> Signed-off-by: Michal Simek 
> ---
>  drivers/serial/serial_zynq.c | 4 
>  1 file changed, 4 deletions(-)

Can you please add this patch to your tree?

If you like, I can send you pull request but this is just
single patch which could go through directly.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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

[U-Boot] Pull request - arm/zynq

[Michal Simek]

Hi Albert,

please pull these two patches to your arm next branch.
It depends on "zynq: Use arch_cpu_init() instead of lowlevel_init()"
(sha1: 262f08d6ea18a62f827b8ccb60f355ca2eaf6e2b) patch
which you have in your branch that's why I have rebased them
on the top.

Thanks,
Michal


The following changes since commit c0e5dd88c438a41bf180dde0c2dc4c67dcd8058d:

  Merge branch 'u-boot-atmel/master' into 'u-boot-arm/master' (2013-11-05 
20:50:39 +0100)

are available in the git repository at:


  git://www.denx.de/git/u-boot-microblaze.git zynq

for you to fetch changes up to b5f05b063413245e3d29186739fb5db98d137dfd:

  arm: zynq : Revert TZ_DDR_RAM to secure. (2013-11-06 09:24:06 +0100)


Michal Simek (1):
  arm: zynq: Do not remap OCM to high address

Radhey Shyam Pandey (1):
  arm: zynq : Revert TZ_DDR_RAM to secure.

 arch/arm/cpu/armv7/zynq/cpu.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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

Re: [U-Boot] [PATCH v4 0/8] Provide a mechanism to avoid using #ifdef everywhere

[Stefan Roese]

Hi Wolfgang,

On 06.11.2013 08:24, Wolfgang Denk wrote:



>   if (autoconf_version_variable())
>   setenv("ver", version_string);  /* set version variable */
> 
> By chance I ran about "include/linux/kconfig.h" in the Linux kernel
> tree, which provides (among other things) the IS_ENABLED() macro that
> implements essentially the very same feature.  Using this, the same
> code would be written as:
> 
>   if (IS_ENABLED(CONFIG_VERSION_VARIABLE))
>   setenv("ver", version_string);  /* set version variable */
> 
> I agree that this does not solve some of the isses that have been
> raised about this change (indentation level increses - which may in
> turn require reformatting of bigger parts of the code; code becomes
> less readable), but on the other hand it avoids the need for a new
> autoconf header file, and it should be possible to introduce this
> easily step by step.
> 
> And I really like the idea of re-using existing code that is already
> known to Linux hackers, especially as we we are currently having our
> eyes on the Kconfig stuff anyway.

I just recently also noticed this IS_ENABLED() feature (in barebox btw)
and thought directly about Simon's patchset regarding this matter. And I
personally would favor IS_ENABLED() to the newly created autoconf_xxx names.

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

Re: [U-Boot] [RFC PATCH 2/2] usb: dfu: correct dfu buffer inited value

[Lukasz Majewski]

Hi Bo,

First of all, sorry for a little delay.

> Hi Lukasz,
> 
> On 11/4/2013 18:17, Lukasz Majewski wrote:
> > Hi Bo,
> >
> >> After dfu buffer is initialized, the buffer should be all
> >> available, while not 0. Initialize its value to min(dfu_buf_size,
> >> dfu->r_left).
> >>
> >> Signed-off-by: Bo Shen 
> >>
> >> ---
> >>   drivers/dfu/dfu.c |2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> >> index 65c6984..b8c8aa4 100644
> >> --- a/drivers/dfu/dfu.c
> >> +++ b/drivers/dfu/dfu.c
> >> @@ -288,7 +288,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
> >> int size, int blk_seq_num) dfu->offset = 0;
> >>dfu->i_buf_end = dfu_get_buf() + dfu_buf_size;
> >>dfu->i_buf = dfu->i_buf_start;
> >> -  dfu->b_left = 0;
> >> +  dfu->b_left = min(dfu_buf_size, dfu->r_left);
> >>
> >
> > I've testd in on Trats. It causes dfu read to be performed two
> > times.
> 
> Have you apply these two patches together:
> [RFC PATCH 1/2] usb: dfu: decrease dfu->r_left along with the transfer
> [RFC PATCH 2/2] usb: dfu: correct dfu buffer inited value
> 

I did a "little" mistake when applying those patches. When both patches
are applied dfu works fine.

I've tested it on Trats (Exynos4210).

For:
[RFC PATCH 1/2] usb: dfu: decrease dfu->r_left along with the transfer
[RFC PATCH 2/2] usb: dfu: correct dfu buffer inited value

Tested-by: Lukasz Majewski 
Acked-by: Lukasz Majewski 

@ Marek,

Since I'm still struggling with internal firewall - Marek could you
apply those two patches to u-boot-usb tree?

Also please apply Heiko's patch:

[PATCH v3 3/5] usb, g_dnl: make iSerialNumber board configurable

Thanks in advance.


> I test this with dfu mmc.
> 
> Without these two patches, it will read file two times.
> --->8---
> U-Boot> dfu mmc 0
> GADGET DRIVER: usb_dnl_dfu
> reading image.bin
> 3049120 bytes read in 628 ms (4.6 MiB/s)
> reading image.bin
> 3049120 bytes read in 628 ms (4.6 MiB/s)
> ---8<---
> 
> with these two patches, it only read file one time.
> --->8---
> U-Boot> dfu mmc 0
> GADGET DRIVER: usb_dnl_dfu
> reading image.bin
> 3049120 bytes read in 628 ms (4.6 MiB/s)
> ---8<---
> 
> The result is opposite.
> 
> > Could you write a more verbose message to explain the problem that
> > you are trying to solve? I can _only_ suppose that you want to
> > read/write data from/to NAND memory.
> >
> > So, I'm curious why dfu-util breaks with your setup but works at
> > am335x. Both chips are supposed to use dfu_nand.c for performing
> > NAND read/write.
> 
> For the NAND upload, if without patch: [U-Boot,RFC] usb: dfu: make
> nand upload working (http://patchwork.ozlabs.org/patch/283886/)
> It doesn't work at my side. more information as following:
> --->8---
> $ ./dfu-util -l
> dfu-util 0.7
> 
> Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
> Copyright 2010-2012 Tormod Volden and Stefan Schmidt
> This program is Free Software and has ABSOLUTELY NO WARRANTY
> Please report bugs to dfu-u...@lists.gnumonks.org
> 
> Found Runtime: [413c:8187] devnum=0, cfg=1, intf=3, alt=0,
> name="UNDEFINED" Found DFU: [03eb:6156] devnum=0, cfg=1, intf=0,
> alt=0, name="sama5d34ek.dtb" Found DFU: [03eb:6156] devnum=0, cfg=1,
> intf=0, alt=1, name="uImage" Found DFU: [03eb:6156] devnum=0, cfg=1,
> intf=0, alt=2, name="rootfs.ubi"
> 
> $ ./dfu-util -d 03eb:6156 -U kernel.image -a 1
> dfu-util 0.7
> 
> Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
> Copyright 2010-2012 Tormod Volden and Stefan Schmidt
> This program is Free Software and has ABSOLUTELY NO WARRANTY
> Please report bugs to dfu-u...@lists.gnumonks.org
> 
> Filter on vendor = 0x03eb product = 0x6156
> Opening DFU capable USB device... ID 03eb:6156
> WARNING: Can not find cached DFU functional descriptor
> Warning: Assuming DFU version 1.0
> Run-time device DFU version 0100
> Found DFU: [03eb:6156] devnum=0, cfg=1, intf=0, alt=1, name="uImage"
> Claiming USB DFU Interface...
> Setting Alternate Setting #1 ...
> Determining device status: state = dfuUPLOAD-IDLE, status = 0
> aborting previous incomplete transfer
> Determining device status: state = dfuIDLE, status = 0
> dfuIDLE, continuing
> Error obtaining cached DFU functional descriptor
> DFU mode device DFU version 0110
> Device returned transfer size 4096
> bytes_per_hash=4096
> Copying data from DFU device to PC
> Starting upload: [] finished!
> ---8<---
> 
> It doesn't transfer anything.
> 
> After apply the patch for NAND upload, it works OK. And only perform
> one time reading.
> 
> >
> >>dfu->bad_skip = 0;
> >>
> 
> Best Regards,
> Bo Shen
> 



-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] [PATCH V2 0/6] Add support for SPI based DataImage LCD panel

[Nikita Kiryanov]

Perhaps we should try his other email address; he seems to be using it
more than the gmail one now (added Cc).

On 11/04/2013 10:49 PM, Tom Rini wrote:

On Wed, Oct 16, 2013 at 05:23:23PM +0300, Nikita Kiryanov wrote:


This patch ports the Linux driver for DataImage SCF0403852GGU04 and
SCF0403526GGU20 LCD panels into U-Boot. As a preparation step, variable SPI word
length support is added to omap3_spi and the generic SPI interface.
Finally, the driver is used in cm_t35 board.

The SPI changes were tested with a Beagle I2C/SPI/MDIO Protocol Analyzer, and
also with a DataImage SCF0403 lcd as part of the DataImage driver test.

Patch number 6 depends on http://patchwork.ozlabs.org/patch/275283/

Cc: Tom Rini 
Cc: Anatolij Gustschin 
Cc: Igor Grinberg 
Cc: Jagannadha Sutradharudu Teki 

Changes in V2:
- Rebased on top of latest U-Boot
- New patches:
 1) spi: omap3: remove semicolon from #define
 2) spi: define SPI_XFER_ONCE
 3) omap3_dss: define DSS_ONOFF
1 is a preliminary cleanup suggested by Gerhard Sittig and Igor Grinberg
2 and 3 are splitting off some new #defines to separate patches
- Moved wordlen to generic spi_slave struct, and added generic
implementation for spi_set_wordlen which only updates the struct without
touching the hardware (Igor Grinberg)
- Updated wordlen in hardware just before doing SPI transactions, not
when changing wordlen (Igor Grinberg)
- OMAP3 specific check of wordlen value from old implementation of
spi_set_wordlen moved to xfer. It refines the more general check done
in the new spi_set_wordlen.
- Fixed comment style in spi.h following a rebase on top of latest
U-Boot
- Added SPDX-License-Identifier to all new files (Anatolij Gustschin)
- s/printf/puts for not formatted strings in scf0403 driver (Anatolij
Gustschin)
- Do not fail scf0403 driver init if an invalid reset_gpio is given
(Igor Grinberg)

Nikita Kiryanov (6):
   spi: omap3: remove semicolon from #define
   spi: omap3: add support for more word lengths
   spi: define SPI_XFER_ONCE
   lcd: add DataImage SCF0403x LCD panel support
   omap3_dss: define DSS_ONOFF
   cm_t35: use scf0403 driver

  arch/arm/include/asm/arch-omap3/dss.h |   9 +-
  board/compulab/cm_t35/cm_t35.c|  12 ++
  board/compulab/common/omap3_display.c |  46 +-
  drivers/spi/omap3_spi.c   |  71 +---
  drivers/spi/omap3_spi.h   |   8 +-
  drivers/spi/spi.c |  13 ++
  drivers/video/Makefile|   1 +
  drivers/video/scf0403_lcd.c   | 296 ++
  include/configs/cm_t35.h  |   3 +
  include/scf0403_lcd.h |  11 ++
  include/spi.h |  17 ++
  11 files changed, 456 insertions(+), 31 deletions(-)
  create mode 100644 drivers/video/scf0403_lcd.c
  create mode 100644 include/scf0403_lcd.h


Did the mailing list eat the CC?  I expect these changes to come in via
the spi tree, since Anatolij acked the other parts.  Thanks!




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

Re: [U-Boot] [PATCH v8 0/5] mtd: nand: omap: optimize and clean-up of OMAP NAND driver

[matti kaasinen]

Hi Pekon,
Thanks to Tom Rini's hint I have tried to execute your patch sets (
http://patchwork.ozlabs.org/project/uboot/list/?submitter=17320&state=*) in
order to get Linux and U-Boot working with same NAND flash. Set-up is
pretty much like Mathias has before in this chain. Latest problem I faced
with is that last versions of 1)  "[U-Boot,v8,3/5] mtd: nand: omap:
optimize chip->ecc.calculate() for H/W ECC
schemes"
and 2)
"[U-Boot,v2,2/3] mtd: nand: omap: add support for BCH16_ECC - NAND driver
updates"  are not compatible any
more. As I told in
https://groups.google.com/forum/#!topic/beagleboard/7ofbE_Rrn_s versions
v5..v7 of 1) could possibly be compatible.
Regards,
Matti


2013/11/1 Matthias Fuchs 

> Hi Pekon,
>
> should I consider the U-Boot and Linux am335x NAND implementation to be
> compatible?
> So are the ECC schemes in a way identical that I can nandwrite a kernel
> image from
> Linux and "nand read" it from U-Boot? I tested with the 3.8.13 beaglebone
> kernel (which
> is of course not very representative) and it does not work. If it should
> work,
> do you know it that was already the case before your patches and with
> which Linux kernel?
>
> Regards,
> Matthias
>
> On 10/10/2013 01:00 PM, Pekon Gupta wrote:
> > *changes in v8*
> > [PATCH 1/5] incorporated following feedbacks from Scott Wood <
> scottw...@freescale.com>
> >   - using symbolic names (enums) as values of
> CONFIG_NAND_OMAP_ECCSCHEME
> >   - updated omap_select_ecc_scheme(): perform ecc-scheme
> compatibility
> >   checks before updating nand_chip.ecc fields. This avoids
> >   corrupting of existing ecc-scheme in case of switching
> failures.
> >   - code clean-up (removed fall-back on omap_select_ecc_scheme()
> failures)
> > [PATCH 2/5], [PATCH 3/5], [PATCH 4/5] minor code clean-up
> > [PATCH 5/5] 
> >
> >
> > *changes in v7*
> > [PATCH 1/5]
> >   - omap_gpmc.c: fix: free bytes in OOB
> (ecclayout->oobfree[0].length)
> >   - omap_gpmc.c: cleanup: redundant code added in previous patch
> versions
> >   - am335x_evm.h: cleanup: redundant code added in previous patch
> versions
> >   - tricorder.h: fix: CONFIG_NAND_OMAP_ECCSCHEME
> > [PATCH 2/5] removed: re-configuration of gpmc.config1[dev_width] added in
> >   previous version of patch
> > [PATCH 3/5] 
> > [PATCH 4/5] 
> > [PATCH 5/5] minor fix: missing '$' in ${loadaddr}
> >
> >
> > *changes in v6*
> > [PATCH 1/5] incorporated feedbacks from Scott Wood <
> scottw...@freescale.com>
> >   - renamed CONFIG_SYS_NAND_ECCSCHEME to CONFIG_NAND_OMAP_ECCSCHEME
> >   - updated omap_select_ecc_scheme() to handle error conditions
> without
> >   depending on caller.
> >   - renamed OMAP_ECC_HAM1_CODE_HW_ROMCODE to OMAP_ECC_HAM1_CODE_HW
> >   to keep it naming compatible to linux kernel
> >   - updated doc/README.nand and doc/README.omap3
> > [PATCH 2/5] minor code clean-up
> > [PATCH 3/5] minor code clean-up
> > [PATCH 4/5] 
> > [PATCH 5/5] 
> >
> >
> > *changes in v5*
> > This version of patch is tested on am335x-evm with x8 NAND device, and
> boots
> > SPL and u-boot from NAND
> > [PATCH 1/5]
> >   - re-added omap_read_page_bch(): needed proper sequence of while
> reading
> >   DATA and ECC from NAND page, so that calc_ecc generated from GPMC
> >   is understood by ELM.
> >   - added check to see if NAND OOB can accomodate ECC for entire page
> > [PATCH 2/5] fixed device-width in GPMC_CONFIG1_X to support x16 devices
> > [PATCH 3/5] code clean-up for OMAP_ECC_BCH8_CODE_HW_DETECTION_SW mode
> > [PATCH 4/5]
> >   - fixed omap_correct_data_bch() for correcting bit-flips using ELM
> >   - code-cleanup + added omap_reverse_list()
> > [PATCH 5/5] incorporated feedbacks from Peter Korsgaard <
> jac...@sunsite.dk>
> >
> >
> > *changes in v4*
> > [PATCH 1/5]
> >   - removed omap_read_page_bch(): chip->ecc.read_page uses default
> API
> >   nand_read_page_hwecc() in nand_base.c
> >   - updated tricorder.h: added new CONFIGS for ECCSCHEME &
> ONFI_DETECTION
> >   - converted printf("ECC-SCHEME") to debug("ECC-SCHEME")
> > [PATCH 2/5] minor code clean-up
> > [PATCH 3/5] 
> > [PATCH 4/5] 
> > [PATCH 5/5] updated README as per feedbacks from tr...@ti.com
> >
> >
> > *changes in v3*
> > [PATCH 1/5] (complete change)
> >   - ecc-scheme is selection is controller by s/w, not CONFIG_NAND_xx
> >   - added omap_select_ecc_scheme(), as common function to handle all
> > ecc-scheme related configurations for both board_nand_init() &
> > omap_nand_switch_ecc().
> >   - removed un-used defines from asm/arch-am33xx/omap_gpmc.h
> >   - updated doc/REAME.nand
> > [PATCH 2/5] removed un-used defines from asm/omap_gpmc.h
> > [PATCH 3/5] removed omap_calculate_ecc_bch_sw() and omap_calculate_ecc()
> >   and merged their logic into omap_calculat

Re: [U-Boot] [PATCH V2 0/6] Add support for SPI based DataImage LCD panel

[Anatolij Gustschin]

On Mon, 4 Nov 2013 15:49:57 -0500
Tom Rini  wrote:

> On Wed, Oct 16, 2013 at 05:23:23PM +0300, Nikita Kiryanov wrote:
> 
> > This patch ports the Linux driver for DataImage SCF0403852GGU04 and
> > SCF0403526GGU20 LCD panels into U-Boot. As a preparation step, variable SPI 
> > word
> > length support is added to omap3_spi and the generic SPI interface.
> > Finally, the driver is used in cm_t35 board.
> > 
> > The SPI changes were tested with a Beagle I2C/SPI/MDIO Protocol Analyzer, 
> > and
> > also with a DataImage SCF0403 lcd as part of the DataImage driver test.
> > 
> > Patch number 6 depends on http://patchwork.ozlabs.org/patch/275283/
> > 
> > Cc: Tom Rini 
> > Cc: Anatolij Gustschin 
> > Cc: Igor Grinberg 
> > Cc: Jagannadha Sutradharudu Teki 
> > 
> > Changes in V2:
> > - Rebased on top of latest U-Boot
> > - New patches:
> >  1) spi: omap3: remove semicolon from #define
> >  2) spi: define SPI_XFER_ONCE
> >  3) omap3_dss: define DSS_ONOFF
> > 1 is a preliminary cleanup suggested by Gerhard Sittig and Igor Grinberg
> > 2 and 3 are splitting off some new #defines to separate patches
> > - Moved wordlen to generic spi_slave struct, and added generic
> > implementation for spi_set_wordlen which only updates the struct without
> > touching the hardware (Igor Grinberg)
> > - Updated wordlen in hardware just before doing SPI transactions, not
> > when changing wordlen (Igor Grinberg)
> > - OMAP3 specific check of wordlen value from old implementation of
> > spi_set_wordlen moved to xfer. It refines the more general check done
> > in the new spi_set_wordlen.
> > - Fixed comment style in spi.h following a rebase on top of latest
> > U-Boot
> > - Added SPDX-License-Identifier to all new files (Anatolij Gustschin)
> > - s/printf/puts for not formatted strings in scf0403 driver (Anatolij
> > Gustschin)
> > - Do not fail scf0403 driver init if an invalid reset_gpio is given
> > (Igor Grinberg)
> > 
> > Nikita Kiryanov (6):
> >   spi: omap3: remove semicolon from #define
> >   spi: omap3: add support for more word lengths
> >   spi: define SPI_XFER_ONCE
> >   lcd: add DataImage SCF0403x LCD panel support
> >   omap3_dss: define DSS_ONOFF
> >   cm_t35: use scf0403 driver
> > 
> >  arch/arm/include/asm/arch-omap3/dss.h |   9 +-
> >  board/compulab/cm_t35/cm_t35.c|  12 ++
> >  board/compulab/common/omap3_display.c |  46 +-
> >  drivers/spi/omap3_spi.c   |  71 +---
> >  drivers/spi/omap3_spi.h   |   8 +-
> >  drivers/spi/spi.c |  13 ++
> >  drivers/video/Makefile|   1 +
> >  drivers/video/scf0403_lcd.c   | 296 
> > ++
> >  include/configs/cm_t35.h  |   3 +
> >  include/scf0403_lcd.h |  11 ++
> >  include/spi.h |  17 ++
> >  11 files changed, 456 insertions(+), 31 deletions(-)
> >  create mode 100644 drivers/video/scf0403_lcd.c
> >  create mode 100644 include/scf0403_lcd.h
> 
> Did the mailing list eat the CC?  I expect these changes to come in via
> the spi tree, since Anatolij acked the other parts.  Thanks!

The patch this series depends on is not in u-boot.git/master branch
yet (but in u-boot-arm.git tree already). So, after the arm tree
is merged to master this series can be applied. I can push it via
the video tree if nobody objects.

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

Re: [U-Boot] [PATCH v5 06/16] dm: Add README for driver model

[Pavel Herrmann]

Hi

On Tuesday 05 of November 2013 14:34:03 Simon Glass wrote:
> >> +Declaring Uclasses
> >> +--
> >> +
> >> +The demo uclass is declared like this:
> >> +
> >> +U_BOOT_CLASS(demo) = {
> >> + .id = UCLASS_DEMO,
> >> +};
> >> +
> >> +It is also possible to specify special methods for probe, etc. The
> >> uclass
> >> +numbering comes from include/dm/uclass.h. To add a new uclass, add to
> >> the
> >> +end of the enum there, then declare your uclass as above.
> > 
> > I wonder if we cannot even automate the numbering here ;-)
> 
> We could but it would need some lookup mechanism. String search? I'll
> leave it as is at the moment but add something to the bottom of the
> README.

please keep in mind that the original design was done with the possibility of 
loading drivers as modules at runtime, while only having certain uclasses 
compiled in. having dynamic ID numbers would complicate things (more 
precisely, no dynamic uclass loading, uclass id map would be part of the 
driver ABI).

if you have ditched the whole idea of runtime loading then please ignore me, i 
havent cought up with all the changes

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

Re: [U-Boot] [PATCH 00/10 V6] EXYNOS5420: Add SMDK5420 board support

[Rajeshwari Birje]

Hi Minkyu Kang,

On Thu, Oct 31, 2013 at 2:12 PM, Rajeshwari Birje
 wrote:
> Hi Minkyu Kang,
>
> Kindly do review the patch set and do let me know if any review comments.
> Pantelis Antoniou has merged the patch 10 (DWMMC: SMDK5420: Disable
> SMU for eMMC) into mmc tree.
>
We have merge window in next three days, this patches are acked by Simon.
Can you please have a look and get it merged if no review comments
from your end, or
please do let me know if some rework needed.

-- 
Regards,
Rajeshwari Shinde
> Regards,
> Rajeshwari Shinde.
>
> On Tue, Oct 29, 2013 at 12:53 PM, Rajeshwari S Shinde
>  wrote:
>> This patch adds basic board support for SMDK5420 board.
>> These patches are tested for booting fine on EVT1 SMDK5420.
>>
>> Changes in V2:
>> - Corrected a compilation issue for SMDK5420.
>>
>> Changes in V3:
>> - Add patch to support variable size SPL support
>> - Add patch to disable SMU for eMMC.
>>
>> Changes in V4:
>> - Added check for MAX77686 pmic compilation.
>> - Added correct calculation of gpio based addresses.
>> - Rebased on the latest u-boot code.
>> - Removed patches for UART and TZPC changes as
>> they were not needed.
>> - Added flag to disable SMU for eMMC.
>>
>> Changes in V5:
>> - Moved functions board_mmc_init and board_eth_init
>> to common/board.c in case of device tree support.
>>
>> Changes in V6:
>> - Rebased on the latest mainline branch.
>> - Moved the definitions for SMU to arch/arm dwmmc.h
>>
>> Rajeshwari S Shinde (10):
>>   EXYNOS5: Create a common board file
>>   Exynos5420: Add base addresses for 5420
>>   Exynos5420: Add clock initialization for 5420
>>   Exynos5420: Add DDR3 initialization for 5420
>>   Exynos5420: Add support for 5420 in pinmux and gpio
>>   Exynos5420: Add base patch for SMDK5420
>>   DTS: Add dts support for SMDK5420
>>   Config: Add initial config for SMDK5420
>>   SPL: EXYNOS: Prepare for variable size SPL support
>>   DWMMC: SMDK5420: Disable SMU for eMMC
>>
>>  arch/arm/cpu/armv7/exynos/clock.c  | 270 -
>>  arch/arm/cpu/armv7/exynos/clock_init.h |  17 +
>>  arch/arm/cpu/armv7/exynos/clock_init_exynos5.c | 352 +++-
>>  arch/arm/cpu/armv7/exynos/dmc_common.c |  10 +-
>>  arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c  | 421 +-
>>  arch/arm/cpu/armv7/exynos/exynos5_setup.h  | 740 
>> +++--
>>  arch/arm/cpu/armv7/exynos/pinmux.c | 241 +++-
>>  arch/arm/dts/exynos5.dtsi  | 211 +++
>>  arch/arm/dts/exynos5250.dtsi   | 178 +-
>>  arch/arm/dts/exynos5420.dtsi   |  74 +++
>>  arch/arm/include/asm/arch-exynos/board.h   |  17 +
>>  arch/arm/include/asm/arch-exynos/clk.h |   1 +
>>  arch/arm/include/asm/arch-exynos/clock.h   | 494 +
>>  arch/arm/include/asm/arch-exynos/cpu.h |  53 +-
>>  arch/arm/include/asm/arch-exynos/dmc.h | 121 ++--
>>  arch/arm/include/asm/arch-exynos/dwmmc.h   |  13 +
>>  arch/arm/include/asm/arch-exynos/gpio.h| 143 -
>>  arch/arm/include/asm/arch-exynos/periph.h  |   3 +
>>  board/samsung/common/Makefile  |   4 +
>>  board/samsung/common/board.c   | 407 ++
>>  board/samsung/dts/exynos5420-smdk5420.dts  | 172 ++
>>  board/samsung/smdk5250/exynos5-dt.c| 361 +---
>>  board/samsung/smdk5250/smdk5250.c  | 182 +-
>>  board/samsung/smdk5420/Makefile|  34 ++
>>  board/samsung/smdk5420/smdk5420.c  | 159 ++
>>  board/samsung/smdk5420/smdk5420_spl.c  |  52 ++
>>  boards.cfg |   1 +
>>  drivers/mmc/dw_mmc.c   |  11 +
>>  drivers/mmc/exynos_dw_mmc.c|   3 +
>>  include/configs/exynos5-dt.h   | 302 ++
>>  include/configs/exynos5250-dt.h| 317 +--
>>  include/configs/smdk5420.h |  56 ++
>>  include/dwmmc.h|   3 +
>>  spl/Makefile   |   7 +-
>>  tools/Makefile |   2 +
>>  tools/mkexynosspl.c| 167 --
>>  36 files changed, 4271 insertions(+), 1328 deletions(-)
>>  create mode 100644 arch/arm/dts/exynos5.dtsi
>>  create mode 100644 arch/arm/dts/exynos5420.dtsi
>>  create mode 100644 arch/arm/include/asm/arch-exynos/board.h
>>  create mode 100644 board/samsung/common/board.c
>>  create mode 100644 board/samsung/dts/exynos5420-smdk5420.dts
>>  create mode 100644 board/samsung/smdk5420/Makefile
>>  create mode 100644 board/samsung/smdk5420/smdk5420.c
>>  create mode 100644 board/samsung/smdk5420/smdk5420_spl.c
>>  create mode 100644 include/configs/exynos5-dt.h
>>  create mode 100644 include/configs/smdk5420.h
>>
>> --
>> 1.7.12.4
>>
>> ___

[U-Boot] A question about unconfigured pads check in omap24xx_i2c

[Nikita Kiryanov]

In drivers/i2c/omap24xx_i2c.c there are a few checks that attempt to
detect unconfigured pads for the i2c bus in use. These checks are
all in the form of

if (status == I2C_STAT_XRDY) {
printf("unconfigured pads\n");
return -1;
}

This check seems peculiar to me since the meaning of I2C_STAT_XRDY is
that new data is requested for transmission. Why is that indication that
the bus is not padconf'd for I2C?

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

Re: [U-Boot] [PATCH V2 0/6] Add support for SPI based DataImage LCD panel

[Nikita Kiryanov]

On 11/06/2013 12:14 PM, Anatolij Gustschin wrote:

On Mon, 4 Nov 2013 15:49:57 -0500
Tom Rini  wrote:



Did the mailing list eat the CC?  I expect these changes to come in via
the spi tree, since Anatolij acked the other parts.  Thanks!


The patch this series depends on is not in u-boot.git/master branch
yet (but in u-boot-arm.git tree already). So, after the arm tree
is merged to master this series can be applied. I can push it via
the video tree if nobody objects.


Fine by me.



Thanks,
Anatolij




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

Re: [U-Boot] [PATCH v2 0/5] arm, am33xx: update for the am33xx based siemens boards

[Vaibhav Bedia]

Hi Heiko,

On Mon, Nov 4, 2013 at 10:30 PM, Heiko Schocher  wrote:
> Hello Vaibhav Bedia,
>
> Am 04.11.2013 20:45, schrieb Vaibhav Bedia:
>
>> Hi Marek,
>>
>> On Mon, Nov 4, 2013 at 12:34 PM, Marek Vasut  wrote:
>>>
>>> Dear Vaibhav Bedia,
>>>
 On Mon, Nov 4, 2013 at 8:15 AM, Heiko Schocher  wrote:
 [...]

> Hups, missed this EMail ... :-(


 No problem. Happens all the time :)

> Hmm.. some boards from siemens do not use the RTC, so this approach
> is not possible here ...


 By unused do you mean it's not powered up or is it simply not
 programmed?

 Even if the RTC is not programmed the register would still be there. I
 don't have a
 board with me to check the behavior but i am guessing the RTC
 functionality doesn't
 need to be used to make use of the scratchpad registers.
>>>
>>>
>>> If your hardware's IP block's clock are not ungated, the register access
>>> to that
>>> IP block will usually not work.
>>>
>> Yes, i understand that. However, in this case AFAICT the interface clock
>> is always present and hence it should be possible to use the RTC
>> registers.
>> Moreover, i just noticed Tom applied a bootcount patch for AM335x [1]
>> which
>> does use the scratchpad register that i am pointing to. So unless there's
>> some other board level difference that i am missing it should work.
>
>
> We see for example on the dxr2 board, that we cannot access the RTC
> registers ... also, they use it on other boards without RTC and all
> siemens boards should have the same manner.
>
> There is also a possibility to disable the RTC on am335x based boards,
> see:
>
> http://processors.wiki.ti.com/index.php/AM335x_Schematic_Checklist#RTC
>

Yeah, if the RTC is completely disabled as documented above then
the registers can't be accessed. In other cases i would expect the
register access to still work.

I just wanted to make sure that the usage of RTC for the bootcount
has been considered. With the recent changes by Tom at least the
other AM335x platforms use it so that's good.

If it's about keeping the approaches consistent on the Siemens boards
then i am fine with this.

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

[U-Boot] [PATCH] MAKEALL: fix awk warning

[Andreas Bießmann]

This fixes following warning:

---8<---
abiessmann@punisher % ./MAKEALL -m at91rm9200ek
at91rm9200ek:awk: warning: escape sequence `\ ' treated as plain ` '
awk: warning: escape sequence `\ ' treated as plain ` '
andreas.de...@gmail.com
--->8---

Signed-off-by: Andreas Bießmann 
Cc: Albert Aribaud 
---
tested with gawk 4.0.1 here

 MAKEALL |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAKEALL b/MAKEALL
index a9253d3..b03f87b 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -518,7 +518,7 @@ get_target_location() {
local vendor=""
 
# Automatic mode
-   local line=`awk -F '\ +' '\$7 == "'"$target"'" { print \$0 }' 
boards.cfg`
+   local line=`awk -F ' +' '\$7 == "'"$target"'" { print \$0 }' boards.cfg`
if [ -z "${line}" ] ; then echo "" ; return ; fi
 
set ${line}
@@ -556,7 +556,7 @@ get_target_location() {
 get_target_maintainers() {
local name=`echo $1 | cut -d : -f 3`
 
-   local line=`awk -F '\ +' '\$7 == "'"$target"'" { print \$0 }' 
boards.cfg`
+   local line=`awk -F ' +' '\$7 == "'"$target"'" { print \$0 }' boards.cfg`
if [ -z "${line}" ]; then
echo ""
return ;
-- 
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 01/14] ARM: AM43xx: Update the base addresses of modules

[Vaibhav Bedia]

HI Lokesh :)

On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
> PRCM, timer base addresses and offsets are different from
> AM33xx. Updating the same.
>
> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/include/asm/arch-am33xx/cpu.h |   17 +++--
>  arch/arm/include/asm/arch-am33xx/hardware.h|8 
>  arch/arm/include/asm/arch-am33xx/hardware_am33xx.h |3 +++
>  arch/arm/include/asm/arch-am33xx/hardware_am43xx.h |3 +++
>  arch/arm/include/asm/arch-am33xx/hardware_ti814x.h |3 +++
>  arch/arm/include/asm/arch-am33xx/hardware_ti816x.h |3 +++
>  6 files changed, 23 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h 
> b/arch/arm/include/asm/arch-am33xx/cpu.h
> index 52fa128..f463b27 100644
> --- a/arch/arm/include/asm/arch-am33xx/cpu.h
> +++ b/arch/arm/include/asm/arch-am33xx/cpu.h
> @@ -237,6 +237,14 @@ struct cm_perpll {
> unsigned int cpswclkstctrl; /* offset 0x144 */
> unsigned int lcdcclkstctrl; /* offset 0x148 */
>  };
> +
> +/* Encapsulating Display pll registers */
> +struct cm_dpll {
> +   unsigned int resv1[2];
> +   unsigned int clktimer2clk;  /* offset 0x08 */
> +   unsigned int resv2[10];
> +   unsigned int clklcdcpixelclk;   /* offset 0x34 */
> +};
>  #else
>  /* Encapsulating core pll registers */
>  struct cm_wkuppll {
> @@ -392,15 +400,12 @@ struct cm_perpll {
> unsigned int resv40[7];
> unsigned int cpgmac0clkctrl;/* offset 0xB20 */
>  };
> -#endif /* CONFIG_AM43XX */
>
> -/* Encapsulating Display pll registers */
>  struct cm_dpll {
> -   unsigned int resv1[2];
> -   unsigned int clktimer2clk;  /* offset 0x08 */
> -   unsigned int resv2[10];
> -   unsigned int clklcdcpixelclk;   /* offset 0x34 */
> +   unsigned int resv1;
> +   unsigned int clktimer2clk;  /* offset 0x04 */
>  };
> +#endif /* CONFIG_AM43XX */
>
>  /* Control Module RTC registers */
>  struct cm_rtc {
> diff --git a/arch/arm/include/asm/arch-am33xx/hardware.h 
> b/arch/arm/include/asm/arch-am33xx/hardware.h
> index ee5fce0..b6db731 100644
> --- a/arch/arm/include/asm/arch-am33xx/hardware.h
> +++ b/arch/arm/include/asm/arch-am33xx/hardware.h
> @@ -38,7 +38,6 @@
>  #define DM_TIMER7_BASE 0x4804A000
>
>  /* GPIO Base address */
> -#define GPIO0_BASE 0x48032000

Going by the patch description this looks an unrelated change.
Moreover, this base address looks wrong! GPIO0 is in wkup
domain for both AM335x and AM437x. I wonder how the
VTT control is working on AM335x. IIRC that was using a pin
from GPIO0.

>  #define GPIO1_BASE 0x4804C000
>
>  /* BCH Error Location Module */
> @@ -48,13 +47,6 @@
>  #define EMIF4_0_CFG_BASE   0x4C00
>  #define EMIF4_1_CFG_BASE   0x4D00
>
> -/* PLL related registers */
> -#define CM_DPLL0x44E00500
> -#define CM_DEVICE  0x44E00700
> -#define CM_RTC 0x44E00800
> -#define CM_CEFUSE  0x44E00A00
> -#define PRM_DEVICE 0x44E00F00
> -
>  /* DDR Base address */
>  #define DDR_CTRL_ADDR  0x44E10E04
>  #define DDR_CONTROL_BASE_ADDR  0x44E11404
> diff --git a/arch/arm/include/asm/arch-am33xx/hardware_am33xx.h 
> b/arch/arm/include/asm/arch-am33xx/hardware_am33xx.h
> index e4231c8..ad9d7dd 100644
> --- a/arch/arm/include/asm/arch-am33xx/hardware_am33xx.h
> +++ b/arch/arm/include/asm/arch-am33xx/hardware_am33xx.h
> @@ -17,6 +17,7 @@
>  #define UART0_BASE 0x44E09000
>
>  /* GPIO Base address */
> +#define GPIO0_BASE 0x48032000
>  #define GPIO2_BASE 0x481AC000
>
>  /* Watchdog Timer */
> @@ -30,6 +31,8 @@
>  #define PRCM_BASE  0x44E0
>  #define CM_PER 0x44E0
>  #define CM_WKUP0x44E00400
> +#define CM_DPLL0x44E00500
> +#define CM_RTC 0x44E00800
>
>  #define PRM_RSTCTRL(PRCM_BASE + 0x0F00)
>  #define PRM_RSTST  (PRM_RSTCTRL + 8)
> diff --git a/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h 
> b/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
> index 3b665e6..4dbc789 100644
> --- a/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
> +++ b/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
> @@ -17,6 +17,7 @@
>  #define UART0_BASE 0x44E09000
>
>  /* GPIO Base address */
> +#define GPIO0_BASE 0x44E07000

Looks like this address is same for AM335x (what the code has
right now is incorrect) and AM437x. So you can move it back to
hardware.h if that's the general convention.

>  #define GPIO2_BASE 0x481AC000
>
>  /* Watchdog Timer */
> @@ -30,6 +31,8 @@
>  #define PRCM_BASE  0x44DF
>  #def

Re: [U-Boot] [PATCH 02/14] ARM: AM43xx: Adapt to ti_armv7_common.h config file

[Vaibhav Bedia]

On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
> Use ti_armv7_common.h config file to inclde the common
> configs.

[...]


> +/* Clock Defines */
> +#define V_OSCK 2400  /* Clock output from T2 */
> +#define V_SCLK (V_OSCK)

I know this is slightly unrelated but i don't think hardcoding the osc freq
is a good idea. We should be reading the PRCM register to detect the
sysboot settings and then use that similar to the kernel. Follow up patch?

>
> -/* Unsupported features */
> -#undef CONFIG_USE_IRQ
> +/* NS16550 Configuration */
> +#define CONFIG_SYS_NS16550_COM10x44e09000  /* Base EVM 
> has UART0 */

I think the comment on base EVM is not applicable here ;)

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

Re: [U-Boot] [PATCH 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM

[Vaibhav Bedia]

On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
> From: Sekhar Nori 
>
> Add support for reading onboard EEPROM to enable
> board detection.
>
> Signed-off-by: Sekhar Nori 
> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/include/asm/arch-am33xx/omap.h |2 ++
>  board/ti/am43xx/board.c |   46 
> +++
>  board/ti/am43xx/board.h |   32 +
>  include/configs/am43xx_evm.h|7 +
>  4 files changed, 87 insertions(+)
>
> diff --git a/arch/arm/include/asm/arch-am33xx/omap.h 
> b/arch/arm/include/asm/arch-am33xx/omap.h
> index 2250721..10f05c9 100644
> --- a/arch/arm/include/asm/arch-am33xx/omap.h
> +++ b/arch/arm/include/asm/arch-am33xx/omap.h
> @@ -27,5 +27,7 @@
>  #define NON_SECURE_SRAM_START  0x402F0400
>  #define NON_SECURE_SRAM_END0x4034
>  #define SRAM_SCRATCH_SPACE_ADDR0x4033C000
> +#define AM4372_BOARD_NAME_STARTSRAM_SCRATCH_SPACE_ADDR
> +#define AM4372_BOARD_NAME_END  SRAM_SCRATCH_SPACE_ADDR + 0xC
>  #endif
>  #endif
> diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
> index dcd8cbb..4fc1a40 100644
> --- a/board/ti/am43xx/board.c
> +++ b/board/ti/am43xx/board.c
> @@ -9,6 +9,8 @@
>   */
>
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -17,6 +19,50 @@
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> +/*
> + * Read header information from EEPROM into global structure.
> + */
> +static int read_eeprom(struct am43xx_board_id *header)
> +{
> +   /* Check if baseboard eeprom is available */
> +   if (i2c_probe(CONFIG_SYS_I2C_EEPROM_ADDR)) {
> +   printf("Could not probe the EEPROM at 0x%x\n",
> +  CONFIG_SYS_I2C_EEPROM_ADDR);
> +   return -ENODEV;
> +   }
> +
> +   /* read the eeprom using i2c */
> +   if (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0, 2, (uchar *)header,
> +sizeof(struct am43xx_board_id))) {
> +   printf("Could not read the EEPROM\n");
> +   return -EIO;
> +   }
> +
> +   if (header->magic != 0xEE3355AA) {

Why is the header the same as AM335x? Shouldn't it be something
like 0xEE3344AA or whatever?

> +   /*
> +* read the eeprom using i2c again,
> +* but use only a 1 byte address
> +*/
> +   if (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0, 1, (uchar 
> *)header,
> +sizeof(struct am43xx_board_id))) {
> +   printf("Could not read the EEPROM at 0x%x\n",
> +  CONFIG_SYS_I2C_EEPROM_ADDR);
> +   return -EIO;
> +   }
> +
> +   if (header->magic != 0xEE3355AA) {

Same here.

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

Re: [U-Boot] [PATCH 07/14] ARM: AM43xx: Select clk source for Timer2

[Vaibhav Bedia]

On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
> Selecting the Master osc clk as Timer2 clock source.

I obviously missed the first round of patches for AM43xx here. Why is
timer2 being used here? Don't we use the synctimer and timer1 in the kernel?

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

Re: [U-Boot] [PATCH 09/14] ARM: AM43xx: mux: Update mux data

[Vaibhav Bedia]

On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
> Updating the mux data for UART, and adding data for i2c0 and mmc.
>
> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/include/asm/arch-am33xx/mux_am43xx.h |4 +++-
>  board/ti/am43xx/mux.c |   24 ++--
>  2 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h 
> b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
> index 0206912..e95efdd 100644
> --- a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
> +++ b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
> @@ -16,7 +16,9 @@
> __raw_writel(value, (CTRL_BASE + offset));
>
>  /* PAD Control Fields */
> -#define SLEWCTRL   (0x1 << 19)
> +#define DSPULLUDEN (0x1 << 27) /* DS0 mode Pull-Up/Down enable */
> +#define DSPULLUDDIS(0x0 << 27) /* DS0 mode Pull-Up/Down Disable */
> +#define SLEWCTRL   (0x1 << 19) /* Slow slew rate selection */
>  #define RXACTIVE   (0x1 << 18)
>  #define PULLDOWN_EN(0x0 << 17) /* Pull Down Selection */
>  #define PULLUP_EN  (0x1 << 17) /* Pull Up Selection */
> diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
> index 700e9a7..818a046 100644
> --- a/board/ti/am43xx/mux.c
> +++ b/board/ti/am43xx/mux.c
> @@ -12,8 +12,26 @@
>  #include "board.h"
>
>  static struct module_pin_mux uart0_pin_mux[] = {
> -   {OFFSET(uart0_rxd), (MODE(0) | RXACTIVE)},  /* UART0_RXD */
> -   {OFFSET(uart0_txd), (MODE(0))}, /* UART0_TXD */
> +   {OFFSET(uart0_rxd),
> +(MODE(0) | PULLUP_EN | RXACTIVE | SLEWCTRL | DSPULLUDEN)},
> +   {OFFSET(uart0_txd),
> +(MODE(0) | PULLUDDIS | PULLUP_EN | SLEWCTRL | DSPULLUDEN)},
> +   {-1},
> +};
> +
> +static struct module_pin_mux mmc0_pin_mux[] = {
> +   {OFFSET(mmc0_clk), (MODE(0) | PULLUDDIS | RXACTIVE | DSPULLUDEN)},
> +   {OFFSET(mmc0_cmd), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
> +   {OFFSET(mmc0_dat0), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
> +   {OFFSET(mmc0_dat1), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
> +   {OFFSET(mmc0_dat2), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
> +   {OFFSET(mmc0_dat3), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
> +   {-1},

Hmm i don't think updating the DSPULL here is a good idea. Since not
all the pins
are used in U-Boot, this is just partially updating the pulls for the
low power state.
I would suggest leaving this bit for the kernel where things can be
updated without
updating the bootloader.

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

Re: [U-Boot] [PATCH 10/14] ARM: AM43xx: clocks: Update DPLL details for EPOS EVM

[Vaibhav Bedia]

On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
> Updating the Multiplier and Dividers values for all DPLLs for EPOS EVM.
> Following are the DPLL locking frequencies at OPP NOM:
> MPU locks at 600MHz
> Core locks at 1000MHz
> Per locks at 960MHz
> DDR locks at 266MHz
>

Why is this not reading the eFuses to detect what speeds are actually supported
on a device? If the eFuses are not currently blown it's much much safer to start
off from the slowest OPP. Things might be working fine now but dialing to a high
frequency without detecting the supported rates is going to come back to haunt
us later.

> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/cpu/armv7/am33xx/clock.c|   12 +++---
>  arch/arm/cpu/armv7/am33xx/clock_am33xx.c |   15 
>  arch/arm/cpu/armv7/am33xx/clock_am43xx.c |8 +--
>  arch/arm/include/asm/arch-am33xx/clock.h |7 +++---
>  board/ti/am43xx/board.c  |   38 
> +++---
>  board/ti/am43xx/board.h  |1 +
>  board/ti/am43xx/mux.c|5 
>  7 files changed, 69 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/am33xx/clock.c 
> b/arch/arm/cpu/armv7/am33xx/clock.c
> index 8e5f3c6..0672798 100644
> --- a/arch/arm/cpu/armv7/am33xx/clock.c
> +++ b/arch/arm/cpu/armv7/am33xx/clock.c
> @@ -101,9 +101,15 @@ void do_setup_dpll(const struct dpll_regs *dpll_regs,
>  static void setup_dplls(void)
>  {
> const struct dpll_params *params;
> -   do_setup_dpll(&dpll_core_regs, &dpll_core);
> -   do_setup_dpll(&dpll_mpu_regs, &dpll_mpu);
> -   do_setup_dpll(&dpll_per_regs, &dpll_per);
> +
> +   params = get_dpll_core_params();
> +   do_setup_dpll(&dpll_core_regs, params);
> +
> +   params = get_dpll_mpu_params();
> +   do_setup_dpll(&dpll_mpu_regs, params);
> +
> +   params = get_dpll_per_params();
> +   do_setup_dpll(&dpll_per_regs, params);
> writel(0x300, &cmwkup->clkdcoldodpllper);
>
> params = get_dpll_ddr_params();
> diff --git a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c 
> b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
> index fabe259..92142c8 100644
> --- a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
> +++ b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
> @@ -62,6 +62,21 @@ const struct dpll_params dpll_core = {
>  const struct dpll_params dpll_per = {
> 960, OSC-1, 5, -1, -1, -1, -1};
>
> +const struct dpll_params *get_dpll_mpu_params(void)
> +{
> +   return &dpll_mpu;
> +}
> +
> +const struct dpll_params *get_dpll_core_params(void)
> +{
> +   return &dpll_core;
> +}
> +
> +const struct dpll_params *get_dpll_per_params(void)
> +{
> +   return &dpll_per;
> +}
> +
>  void setup_clocks_for_console(void)
>  {
> clrsetbits_le32(&cmwkup->wkclkstctrl, CD_CLKCTRL_CLKTRCTRL_MASK,
> diff --git a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c 
> b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
> index 22963b7..97c00b4 100644
> --- a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
> +++ b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
> @@ -48,15 +48,9 @@ const struct dpll_regs dpll_ddr_regs = {
> .cm_idlest_dpll = CM_WKUP + 0x5A4,
> .cm_clksel_dpll = CM_WKUP + 0x5AC,
> .cm_div_m2_dpll = CM_WKUP + 0x5B0,
> +   .cm_div_m4_dpll = CM_WKUP + 0x5B8,
>  };
>
> -const struct dpll_params dpll_mpu = {
> -   -1, -1, -1, -1, -1, -1, -1};
> -const struct dpll_params dpll_core = {
> -   -1, -1, -1, -1, -1, -1, -1};
> -const struct dpll_params dpll_per = {
> -   -1, -1, -1, -1, -1, -1, -1};
> -
>  void setup_clocks_for_console(void)
>  {
> /* Do not add any spl_debug prints in this function */
> diff --git a/arch/arm/include/asm/arch-am33xx/clock.h 
> b/arch/arm/include/asm/arch-am33xx/clock.h
> index 519249e..7637457 100644
> --- a/arch/arm/include/asm/arch-am33xx/clock.h
> +++ b/arch/arm/include/asm/arch-am33xx/clock.h
> @@ -98,13 +98,12 @@ extern const struct dpll_regs dpll_mpu_regs;
>  extern const struct dpll_regs dpll_core_regs;
>  extern const struct dpll_regs dpll_per_regs;
>  extern const struct dpll_regs dpll_ddr_regs;
> -extern const struct dpll_params dpll_mpu;
> -extern const struct dpll_params dpll_core;
> -extern const struct dpll_params dpll_per;
> -extern const struct dpll_params dpll_ddr;
>
>  extern struct cm_wkuppll *const cmwkup;
>
> +const struct dpll_params *get_dpll_mpu_params(void);
> +const struct dpll_params *get_dpll_core_params(void);
> +const struct dpll_params *get_dpll_per_params(void);
>  const struct dpll_params *get_dpll_ddr_params(void);
>  void do_setup_dpll(const struct dpll_regs *, const struct dpll_params *);
>  void prcm_init(void);
> diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
> index 723d0ca..e28e844 100644
> --- a/board/ti/am43xx/board.c
> +++ b/board/ti/am43xx/board.c
> @@ -65,12 +65,44 @@ static int read_eeprom(struct am43xx_board_id *header)
>
>  #ifdef CONFIG_SPL_BUILD

Re: [U-Boot] [PATCH 11/14] ARM: AM43xx: clocks: Add DPLL data for GP EVM

[Vaibhav Bedia]

On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
> Adding DPLLs Multiplier and DIvider values for GP EVM
> Following are the DPLL locking frequencies at OPP NOM
> MPU locks at 600MHz
> Core locks at 1000MHz
> Per locks at 960MHz
> DDR locks at 400MHz
>

Comment on getting the data from eFuse or falling back to lower freq
applies here too.

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

Re: [U-Boot] [PATCH 12/14] ARM: AM43xx: EPOS_EVM: Add support for LPDDR2

[Vaibhav Bedia]

On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
> AM4372 EPOS EVM has 1GB LPDDR2(Part no: MT42L256M32D2LG-25 WT:A)
> Adding LPDDR2 init sequence and register details for the same.
> Below is the brief description of LPDDR2 init sequence:
> -> Configure VTP
> -> Configure DDR IO settings
> -> Disable initialization and refreshes until EMIF registers are programmed.
> -> Program Timing registers
> -> Program PHY control and Temp alert and ZQ config registers.
> -> Enable initialization and refreshes and configure SDRAM CONFIG register
> -> Wait till initialization is complete and the configure MR registers.
>

Is there any public documentation to go with this?
I would suggest sprinkling the code with comments
to mention the different stages.

BTW, no IO powerdown setting for now?

[...]
>
> +ifeq ($(CONFIG_AM43XX),)
> +COBJS  += ddr.o
> +COBJS  += emif4.o
> +endif
> +COBJS-$(CONFIG_AM43XX) += emif4d5.o
> +

Are the steps really different enough to warrant a new file? Can't the changes
be handled properly in the code? How has this been handled in OMAPx where
DDR3 and LPDDR both are supported?

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

[U-Boot] [PATCH] ARM: imx6: Add Bachmann electronic ot1205 mr board

[Christian Gmeiner]

Add basic support for the Bachmann electronic ot1205 board. It
is powered by an imx6d and will come in different flavours. This
patch adds support for the mr flavour. It has a front panel with
some LEDs and some keys.

Signed-off-by: Christian Gmeiner 
---
 board/bachmann/ot1205/Makefile |9 ++
 board/bachmann/ot1205/ot1205.c |  236 
 boards.cfg |1 +
 include/configs/ot1205.h   |  231 +++
 4 files changed, 477 insertions(+)
 create mode 100644 board/bachmann/ot1205/Makefile
 create mode 100644 board/bachmann/ot1205/ot1205.c
 create mode 100644 include/configs/ot1205.h

diff --git a/board/bachmann/ot1205/Makefile b/board/bachmann/ot1205/Makefile
new file mode 100644
index 000..75933c4
--- /dev/null
+++ b/board/bachmann/ot1205/Makefile
@@ -0,0 +1,9 @@
+#
+# Copyright (C) 2012-2013, Guennadi Liakhovetski 
+# (C) Copyright 2012-2013 Freescale Semiconductor, Inc.
+# Copyright (C) 2013, Boundary Devices 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  := ot1205.o
diff --git a/board/bachmann/ot1205/ot1205.c b/board/bachmann/ot1205/ot1205.c
new file mode 100644
index 000..37c6159
--- /dev/null
+++ b/board/bachmann/ot1205/ot1205.c
@@ -0,0 +1,236 @@
+/*
+ * Copyright (C) 2010-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2013, Bachmann electronic GmbH
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define UART_PAD_CTRL  (PAD_CTL_PUS_100K_UP |  \
+   PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
+   PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
+
+#define USDHC_PAD_CTRL (PAD_CTL_PUS_47K_UP |   \
+   PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \
+   PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
+
+#define ENET_PAD_CTRL  (PAD_CTL_PUS_100K_UP |  \
+   PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
+
+#define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED |\
+   PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
+
+#define I2C_PAD_CTRL   (PAD_CTL_PUS_100K_UP |  \
+   PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS |   \
+   PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+
+#define OUTPUT_40OHM (PAD_CTL_SPEED_MED|PAD_CTL_DSE_40ohm)
+
+int dram_init(void)
+{
+   gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
+
+   return 0;
+}
+
+iomux_v3_cfg_t const uart1_pads[] = {
+   MX6_PAD_CSI0_DAT10__UART1_TXD | MUX_PAD_CTRL(UART_PAD_CTRL),
+   MX6_PAD_CSI0_DAT11__UART1_RXD | MUX_PAD_CTRL(UART_PAD_CTRL),
+};
+
+
+static void setup_iomux_uart(void)
+{
+   imx_iomux_v3_setup_multiple_pads(uart1_pads,
+   ARRAY_SIZE(uart1_pads));
+}
+
+int board_early_init_f(void)
+{
+   setup_iomux_uart();
+
+   return 0;
+}
+
+iomux_v3_cfg_t const ecspi1_pads[] = {
+   MX6_PAD_DISP0_DAT3__ECSPI3_SS0  | MUX_PAD_CTRL(SPI_PAD_CTRL),
+   MX6_PAD_DISP0_DAT4__ECSPI3_SS1  | MUX_PAD_CTRL(SPI_PAD_CTRL),
+   MX6_PAD_DISP0_DAT2__ECSPI3_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
+   MX6_PAD_DISP0_DAT1__ECSPI3_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
+   MX6_PAD_DISP0_DAT0__ECSPI3_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),
+};
+
+void setup_spi(void)
+{
+   imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
+ARRAY_SIZE(ecspi1_pads));
+}
+
+/*
+ * Do not overwrite the console
+ * Use always serial for U-Boot console
+ */
+int overwrite_console(void)
+{
+   return 1;
+}
+
+iomux_v3_cfg_t const usdhc3_pads[] = {
+   MX6_PAD_SD3_CLK__USDHC3_CLK   | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD3_CMD__USDHC3_CMD   | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD3_DAT0__USDHC3_DAT0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD3_DAT1__USDHC3_DAT1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD3_DAT2__USDHC3_DAT2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD3_DAT3__USDHC3_DAT3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD3_DAT4__USDHC3_DAT4 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD3_DAT5__USDHC3_DAT5 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD3_DAT6__USDHC3_DAT6 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD3_DAT7__USDHC3_DAT7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD3_RST__USDHC3_RST | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+};
+
+int board_mmc_getcd(struct mmc *mmc)
+{
+   // returns -1 to indicate that no card-detection mechanism is 
implemented;
+   // 0 indicates that no card is present and
+   // 1 is returned if it was detected that a card is present.
+   return 1;
+}
+
+struct fsl_esdhc_cfg usdhc_cfg[] = {
+   {USDHC3_BASE_ADDR},
+};
+
+int board_mmc_init(bd_t *bis)
+{
+   s32 status = 0;

Re: [U-Boot] [PATCH 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3

[Vaibhav Bedia]

On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
> GP EVM has 1GB DDR3 attached(Part no: MT47H128M16RT-187E:C).
> Adding details for the same.
> Below is the brief description of DDR3 init sequence(SW leveling):
> -> Enable VTT regulator
> -> Configure VTP
> -> Configure DDR IO settings
> -> Disable initialization and refreshes until EMIF registers are programmed.
> -> Program Timing registers
> -> Program leveling registers
> -> Program PHY control and Temp alert and ZQ config registers.

Temp alert? Is that really relevant here?

> -> Enable initialization and refreshes and configure SDRAM CONFIG register
>
> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/cpu/armv7/am33xx/emif4d5.c |8 ++-
>  arch/arm/include/asm/arch-am33xx/ddr_defs.h |   10 ++-
>  board/ti/am43xx/board.c |   89 
> ++-
>  3 files changed, 101 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/am33xx/emif4d5.c 
> b/arch/arm/cpu/armv7/am33xx/emif4d5.c
> index eea1fa3..8bac0f2 100644
> --- a/arch/arm/cpu/armv7/am33xx/emif4d5.c
> +++ b/arch/arm/cpu/armv7/am33xx/emif4d5.c
> @@ -120,7 +120,7 @@ static void configure_mr(u32 base, u32 cs)
>
>  void do_sdram_init(const struct ctrl_ioregs *ioregs,
>const struct emif_regs *regs,
> -  const u32 *ext_phy_ctrl_const_regs)
> +  const u32 *ext_phy_ctrl_const_regs, u32 sdram_type)
>  {
> struct emif_reg_struct *emif = (struct emif_reg_struct *)EMIF1_BASE;
>
> @@ -178,6 +178,8 @@ void do_sdram_init(const struct ctrl_ioregs *ioregs,
> writel(regs->sdram_config, &emif->emif_sdram_config);
> writel(regs->ref_ctrl, &emif->emif_sdram_ref_ctrl);
>
> -   configure_mr(EMIF1_BASE, 0);
> -   configure_mr(EMIF1_BASE, 1);
> +   if (sdram_type == EMIF_SDRAM_TYPE_LPDDR2) {
> +   configure_mr(EMIF1_BASE, 0);
> +   configure_mr(EMIF1_BASE, 1);
> +   }
>  }
> diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h 
> b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> index 1880415..796e9df 100644
> --- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> +++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> @@ -134,6 +134,14 @@
>  #define  LPDDR2_DATA2_IOCTRL_VALUE   0x2294
>  #define  LPDDR2_DATA3_IOCTRL_VALUE   0x2294
>
> +#define  DDR3_ADDRCTRL_WD0_IOCTRL_VALUE 0x
> +#define  DDR3_ADDRCTRL_WD1_IOCTRL_VALUE 0x
> +#define  DDR3_ADDRCTRL_IOCTRL_VALUE   0x84
> +#define  DDR3_DATA0_IOCTRL_VALUE   0x84
> +#define  DDR3_DATA1_IOCTRL_VALUE   0x84
> +#define  DDR3_DATA2_IOCTRL_VALUE   0x84
> +#define  DDR3_DATA3_IOCTRL_VALUE   0x84
> +
>  /**
>   * Configure DMM
>   */
> @@ -333,5 +341,5 @@ void config_ddr(unsigned int pll, unsigned int ioctrl,
>
>  void do_sdram_init(const struct ctrl_ioregs *ioregs,
>const struct emif_regs *emif_regs,
> -  const u32 *ext_phy_ctrl_const_regs);
> +  const u32 *ext_phy_ctrl_const_regs, u32 ddr_type);
>  #endif  /* _DDR_DEFS_H */
> diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
> index 83d184d..a943b45 100644
> --- a/board/ti/am43xx/board.c
> +++ b/board/ti/am43xx/board.c
> @@ -140,6 +140,57 @@ const u32 
> ext_phy_ctrl_const_base_lpddr2[EMIF_EXT_PHY_CTRL_CONST_REG] = {
> 0x08102040
>  };
>
> +const struct ctrl_ioregs ioregs_ddr3 = {
> +   .cm0ioctl   = DDR3_ADDRCTRL_IOCTRL_VALUE,
> +   .cm1ioctl   = DDR3_ADDRCTRL_WD0_IOCTRL_VALUE,
> +   .cm2ioctl   = DDR3_ADDRCTRL_WD1_IOCTRL_VALUE,
> +   .dt0ioctl   = DDR3_DATA0_IOCTRL_VALUE,
> +   .dt1ioctl   = DDR3_DATA0_IOCTRL_VALUE,
> +   .dt2ioctrl  = DDR3_DATA0_IOCTRL_VALUE,
> +   .dt3ioctrl  = DDR3_DATA0_IOCTRL_VALUE,
> +   .emif_sdram_config_ext  = 0x0043,
> +};
> +
> +const struct emif_regs ddr3_emif_regs_400Mhz = {
> +   .sdram_config   = 0x638413B2,
> +   .ref_ctrl   = 0x0C30,
> +   .sdram_tim1 = 0xEAAAD4DB,
> +   .sdram_tim2 = 0x266B7FDA,
> +   .sdram_tim3 = 0x107F8678,
> +   .read_idle_ctrl = 0x0005,
> +   .zq_config  = 0x50074BE4,
> +   .temp_alert_config  = 0x0,
> +   .emif_ddr_phy_ctlr_1= 0x0E084007,
> +   .emif_ddr_ext_phy_ctrl_1= 0x08020080,
> +   .emif_ddr_ext_phy_ctrl_2= 0x00400040,
> +   .emif_ddr_ext_phy_ctrl_3= 0x00400040,
> +   .emif_ddr_ext_phy_ctrl_4= 0x00400040,
> +   .emif_ddr_ext_phy_ctrl_5= 0x00400040
> +};
> +
> +const u32 ext_phy_ctrl_const_base_ddr3[EMIF_EXT_PHY_CTRL_CONST_REG] = {
> +   0x00400040,
> +   0x00350035,
> +   0x00350035,
> +   0x00350035,
> +   0x00350035,
> +   0x00350035,
> +   0x,
> +   0x,
> +   0x,
> +

Re: [U-Boot] [PATCH 01/14] ARM: AM43xx: Update the base addresses of modules

[Lokesh Vutla]

Hi Vibhav,
Thanks for the review...:)
On Wednesday 06 November 2013 05:58 PM, Vaibhav Bedia wrote:
> HI Lokesh :)
> 
> On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
>> PRCM, timer base addresses and offsets are different from
>> AM33xx. Updating the same.
>>
>> Signed-off-by: Lokesh Vutla 
>> ---
>>  arch/arm/include/asm/arch-am33xx/cpu.h |   17 +++--
>>  arch/arm/include/asm/arch-am33xx/hardware.h|8 
>>  arch/arm/include/asm/arch-am33xx/hardware_am33xx.h |3 +++
>>  arch/arm/include/asm/arch-am33xx/hardware_am43xx.h |3 +++
>>  arch/arm/include/asm/arch-am33xx/hardware_ti814x.h |3 +++
>>  arch/arm/include/asm/arch-am33xx/hardware_ti816x.h |3 +++
>>  6 files changed, 23 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h 
>> b/arch/arm/include/asm/arch-am33xx/cpu.h
>> index 52fa128..f463b27 100644
>> --- a/arch/arm/include/asm/arch-am33xx/cpu.h
>> +++ b/arch/arm/include/asm/arch-am33xx/cpu.h
>> @@ -237,6 +237,14 @@ struct cm_perpll {
>> unsigned int cpswclkstctrl; /* offset 0x144 */
>> unsigned int lcdcclkstctrl; /* offset 0x148 */
>>  };
>> +
>> +/* Encapsulating Display pll registers */
>> +struct cm_dpll {
>> +   unsigned int resv1[2];
>> +   unsigned int clktimer2clk;  /* offset 0x08 */
>> +   unsigned int resv2[10];
>> +   unsigned int clklcdcpixelclk;   /* offset 0x34 */
>> +};
>>  #else
>>  /* Encapsulating core pll registers */
>>  struct cm_wkuppll {
>> @@ -392,15 +400,12 @@ struct cm_perpll {
>> unsigned int resv40[7];
>> unsigned int cpgmac0clkctrl;/* offset 0xB20 */
>>  };
>> -#endif /* CONFIG_AM43XX */
>>
>> -/* Encapsulating Display pll registers */
>>  struct cm_dpll {
>> -   unsigned int resv1[2];
>> -   unsigned int clktimer2clk;  /* offset 0x08 */
>> -   unsigned int resv2[10];
>> -   unsigned int clklcdcpixelclk;   /* offset 0x34 */
>> +   unsigned int resv1;
>> +   unsigned int clktimer2clk;  /* offset 0x04 */
>>  };
>> +#endif /* CONFIG_AM43XX */
>>
>>  /* Control Module RTC registers */
>>  struct cm_rtc {
>> diff --git a/arch/arm/include/asm/arch-am33xx/hardware.h 
>> b/arch/arm/include/asm/arch-am33xx/hardware.h
>> index ee5fce0..b6db731 100644
>> --- a/arch/arm/include/asm/arch-am33xx/hardware.h
>> +++ b/arch/arm/include/asm/arch-am33xx/hardware.h
>> @@ -38,7 +38,6 @@
>>  #define DM_TIMER7_BASE 0x4804A000
>>
>>  /* GPIO Base address */
>> -#define GPIO0_BASE 0x48032000
> 
> Going by the patch description this looks an unrelated change.
> Moreover, this base address looks wrong! GPIO0 is in wkup
> domain for both AM335x and AM437x. I wonder how the
> VTT control is working on AM335x. IIRC that was using a pin
> from GPIO0.
Should have added GPIO also in patch description.
> 
>>  #define GPIO1_BASE 0x4804C000
>>
>>  /* BCH Error Location Module */
>> @@ -48,13 +47,6 @@
>>  #define EMIF4_0_CFG_BASE   0x4C00
>>  #define EMIF4_1_CFG_BASE   0x4D00
>>
>> -/* PLL related registers */
>> -#define CM_DPLL0x44E00500
>> -#define CM_DEVICE  0x44E00700
>> -#define CM_RTC 0x44E00800
>> -#define CM_CEFUSE  0x44E00A00
>> -#define PRM_DEVICE 0x44E00F00
>> -
>>  /* DDR Base address */
>>  #define DDR_CTRL_ADDR  0x44E10E04
>>  #define DDR_CONTROL_BASE_ADDR  0x44E11404
>> diff --git a/arch/arm/include/asm/arch-am33xx/hardware_am33xx.h 
>> b/arch/arm/include/asm/arch-am33xx/hardware_am33xx.h
>> index e4231c8..ad9d7dd 100644
>> --- a/arch/arm/include/asm/arch-am33xx/hardware_am33xx.h
>> +++ b/arch/arm/include/asm/arch-am33xx/hardware_am33xx.h
>> @@ -17,6 +17,7 @@
>>  #define UART0_BASE 0x44E09000
>>
>>  /* GPIO Base address */
>> +#define GPIO0_BASE 0x48032000
>>  #define GPIO2_BASE 0x481AC000
>>
>>  /* Watchdog Timer */
>> @@ -30,6 +31,8 @@
>>  #define PRCM_BASE  0x44E0
>>  #define CM_PER 0x44E0
>>  #define CM_WKUP0x44E00400
>> +#define CM_DPLL0x44E00500
>> +#define CM_RTC 0x44E00800
>>
>>  #define PRM_RSTCTRL(PRCM_BASE + 0x0F00)
>>  #define PRM_RSTST  (PRM_RSTCTRL + 8)
>> diff --git a/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h 
>> b/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
>> index 3b665e6..4dbc789 100644
>> --- a/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
>> +++ b/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
>> @@ -17,6 +17,7 @@
>>  #define UART0_BASE 0x44E09000
>>
>>  /* GPIO Base address */
>> +#define GPIO0_BASE 0x44E07000
> 
> Looks like this address is same for AM335x (wh

Re: [U-Boot] [PATCH 02/14] ARM: AM43xx: Adapt to ti_armv7_common.h config file

[Lokesh Vutla]

Hi Vaibhav,

On Wednesday 06 November 2013 06:04 PM, Vaibhav Bedia wrote:
> On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
>> Use ti_armv7_common.h config file to inclde the common
>> configs.
> 
> [...]
> 
> 
>> +/* Clock Defines */
>> +#define V_OSCK 2400  /* Clock output from T2 */
>> +#define V_SCLK (V_OSCK)
> 
> I know this is slightly unrelated but i don't think hardcoding the osc freq
> is a good idea. We should be reading the PRCM register to detect the
> sysboot settings and then use that similar to the kernel. Follow up patch?
This is how it is done in all other OMAPs and AMXX. But you are correct,
it can be done from reading the register. Will discuss with Tom and update 
about a separate patch but not in this series..:)

Thanks and regards,
Lokesh 
> 
>>
>> -/* Unsupported features */
>> -#undef CONFIG_USE_IRQ
>> +/* NS16550 Configuration */
>> +#define CONFIG_SYS_NS16550_COM10x44e09000  /* Base EVM 
>> has UART0 */
> 
> I think the comment on base EVM is not applicable here ;)
> 
> Regards,
> Vaibhav
> 

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

Re: [U-Boot] [PATCH 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM

[Lokesh Vutla]

On Wednesday 06 November 2013 06:08 PM, Vaibhav Bedia wrote:
> On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
>> From: Sekhar Nori 
>>
>> Add support for reading onboard EEPROM to enable
>> board detection.
>>
>> Signed-off-by: Sekhar Nori 
>> Signed-off-by: Lokesh Vutla 
>> ---
>>  arch/arm/include/asm/arch-am33xx/omap.h |2 ++
>>  board/ti/am43xx/board.c |   46 
>> +++
>>  board/ti/am43xx/board.h |   32 +
>>  include/configs/am43xx_evm.h|7 +
>>  4 files changed, 87 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/arch-am33xx/omap.h 
>> b/arch/arm/include/asm/arch-am33xx/omap.h
>> index 2250721..10f05c9 100644
>> --- a/arch/arm/include/asm/arch-am33xx/omap.h
>> +++ b/arch/arm/include/asm/arch-am33xx/omap.h
>> @@ -27,5 +27,7 @@
>>  #define NON_SECURE_SRAM_START  0x402F0400
>>  #define NON_SECURE_SRAM_END0x4034
>>  #define SRAM_SCRATCH_SPACE_ADDR0x4033C000
>> +#define AM4372_BOARD_NAME_STARTSRAM_SCRATCH_SPACE_ADDR
>> +#define AM4372_BOARD_NAME_END  SRAM_SCRATCH_SPACE_ADDR + 0xC
>>  #endif
>>  #endif
>> diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
>> index dcd8cbb..4fc1a40 100644
>> --- a/board/ti/am43xx/board.c
>> +++ b/board/ti/am43xx/board.c
>> @@ -9,6 +9,8 @@
>>   */
>>
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -17,6 +19,50 @@
>>
>>  DECLARE_GLOBAL_DATA_PTR;
>>
>> +/*
>> + * Read header information from EEPROM into global structure.
>> + */
>> +static int read_eeprom(struct am43xx_board_id *header)
>> +{
>> +   /* Check if baseboard eeprom is available */
>> +   if (i2c_probe(CONFIG_SYS_I2C_EEPROM_ADDR)) {
>> +   printf("Could not probe the EEPROM at 0x%x\n",
>> +  CONFIG_SYS_I2C_EEPROM_ADDR);
>> +   return -ENODEV;
>> +   }
>> +
>> +   /* read the eeprom using i2c */
>> +   if (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0, 2, (uchar *)header,
>> +sizeof(struct am43xx_board_id))) {
>> +   printf("Could not read the EEPROM\n");
>> +   return -EIO;
>> +   }
>> +
>> +   if (header->magic != 0xEE3355AA) {
> 
> Why is the header the same as AM335x? Shouldn't it be something
> like 0xEE3344AA or whatever?
No, the header is still same. It is 0xEE3355AA.

Thanks and regards,
Lokesh
> 
>> +   /*
>> +* read the eeprom using i2c again,
>> +* but use only a 1 byte address
>> +*/
>> +   if (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0, 1, (uchar 
>> *)header,
>> +sizeof(struct am43xx_board_id))) {
>> +   printf("Could not read the EEPROM at 0x%x\n",
>> +  CONFIG_SYS_I2C_EEPROM_ADDR);
>> +   return -EIO;
>> +   }
>> +
>> +   if (header->magic != 0xEE3355AA) {
> 
> Same here.
> 
> Regards,
> Vaibhav
> 

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

Re: [U-Boot] A question about unconfigured pads check in omap24xx_i2c

[Lubomir Popov]

On 06-Nov-13 14:12, Nikita Kiryanov wrote:

In drivers/i2c/omap24xx_i2c.c there are a few checks that attempt to
detect unconfigured pads for the i2c bus in use. These checks are
all in the form of

if (status == I2C_STAT_XRDY) {
printf("unconfigured pads\n");
return -1;
}

This check seems peculiar to me since the meaning of I2C_STAT_XRDY is
that new data is requested for transmission. Why is that indication that
the bus is not padconf'd for I2C?

Hi Nikita,

This has been empirically confirmed on OMAP4 and OMAP5. When the pads 
are not
configured, the I2C controller is actually disconnected from the bus. 
The clock
input for its state machine has to come from the bus however due to 
stretching
etc., although it is internally generated. So actually nothing changes 
within

the controller after a transaction attempt is made, and it keeps its initial
state with XRDY set only (ready to accept transmit data). I use this as an
indicator. Not perfect, but works in most cases.

Regards,
Lubo


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

Re: [U-Boot] [PATCH 09/14] ARM: AM43xx: mux: Update mux data

[Lokesh Vutla]

On Wednesday 06 November 2013 06:13 PM, Vaibhav Bedia wrote:
> On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
>> Updating the mux data for UART, and adding data for i2c0 and mmc.
>>
>> Signed-off-by: Lokesh Vutla 
>> ---
>>  arch/arm/include/asm/arch-am33xx/mux_am43xx.h |4 +++-
>>  board/ti/am43xx/mux.c |   24 
>> ++--
>>  2 files changed, 25 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h 
>> b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
>> index 0206912..e95efdd 100644
>> --- a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
>> +++ b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
>> @@ -16,7 +16,9 @@
>> __raw_writel(value, (CTRL_BASE + offset));
>>
>>  /* PAD Control Fields */
>> -#define SLEWCTRL   (0x1 << 19)
>> +#define DSPULLUDEN (0x1 << 27) /* DS0 mode Pull-Up/Down enable */
>> +#define DSPULLUDDIS(0x0 << 27) /* DS0 mode Pull-Up/Down Disable */
>> +#define SLEWCTRL   (0x1 << 19) /* Slow slew rate selection */
>>  #define RXACTIVE   (0x1 << 18)
>>  #define PULLDOWN_EN(0x0 << 17) /* Pull Down Selection */
>>  #define PULLUP_EN  (0x1 << 17) /* Pull Up Selection */
>> diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
>> index 700e9a7..818a046 100644
>> --- a/board/ti/am43xx/mux.c
>> +++ b/board/ti/am43xx/mux.c
>> @@ -12,8 +12,26 @@
>>  #include "board.h"
>>
>>  static struct module_pin_mux uart0_pin_mux[] = {
>> -   {OFFSET(uart0_rxd), (MODE(0) | RXACTIVE)},  /* UART0_RXD */
>> -   {OFFSET(uart0_txd), (MODE(0))}, /* UART0_TXD */
>> +   {OFFSET(uart0_rxd),
>> +(MODE(0) | PULLUP_EN | RXACTIVE | SLEWCTRL | DSPULLUDEN)},
>> +   {OFFSET(uart0_txd),
>> +(MODE(0) | PULLUDDIS | PULLUP_EN | SLEWCTRL | DSPULLUDEN)},
>> +   {-1},
>> +};
>> +
>> +static struct module_pin_mux mmc0_pin_mux[] = {
>> +   {OFFSET(mmc0_clk), (MODE(0) | PULLUDDIS | RXACTIVE | DSPULLUDEN)},
>> +   {OFFSET(mmc0_cmd), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
>> +   {OFFSET(mmc0_dat0), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
>> +   {OFFSET(mmc0_dat1), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
>> +   {OFFSET(mmc0_dat2), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
>> +   {OFFSET(mmc0_dat3), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
>> +   {-1},
> 
> Hmm i don't think updating the DSPULL here is a good idea. Since not
> all the pins
> are used in U-Boot, this is just partially updating the pulls for the
> low power state.
> I would suggest leaving this bit for the kernel where things can be
> updated without
> updating the bootloader.
These are the preferred settings given to me.
Any way if kernel is updating it overwrites these settings, it shouldn't matter 
I guess..:)

Thanks and regards,
Lokesh
> 
> Regards,
> Vaibhav
> 

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

Re: [U-Boot] [PATCH 10/14] ARM: AM43xx: clocks: Update DPLL details for EPOS EVM

[Lokesh Vutla]

On Wednesday 06 November 2013 06:18 PM, Vaibhav Bedia wrote:
> On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
>> Updating the Multiplier and Dividers values for all DPLLs for EPOS EVM.
>> Following are the DPLL locking frequencies at OPP NOM:
>> MPU locks at 600MHz
>> Core locks at 1000MHz
>> Per locks at 960MHz
>> DDR locks at 266MHz
>>
> 
> Why is this not reading the eFuses to detect what speeds are actually 
> supported
> on a device? If the eFuses are not currently blown it's much much safer to 
> start
> off from the slowest OPP. Things might be working fine now but dialing to a 
> high
> frequency without detecting the supported rates is going to come back to haunt
> us later.
Currently these values are not blown in eFuse. Both EPOS and GP evms support 
OPP NOM. So there is no harm in booting at OPP NOM here.
Shekar can comment more on this.

Thanks and regards,
Lokesh
> 
>> Signed-off-by: Lokesh Vutla 
>> ---
>>  arch/arm/cpu/armv7/am33xx/clock.c|   12 +++---
>>  arch/arm/cpu/armv7/am33xx/clock_am33xx.c |   15 
>>  arch/arm/cpu/armv7/am33xx/clock_am43xx.c |8 +--
>>  arch/arm/include/asm/arch-am33xx/clock.h |7 +++---
>>  board/ti/am43xx/board.c  |   38 
>> +++---
>>  board/ti/am43xx/board.h  |1 +
>>  board/ti/am43xx/mux.c|5 
>>  7 files changed, 69 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/am33xx/clock.c 
>> b/arch/arm/cpu/armv7/am33xx/clock.c
>> index 8e5f3c6..0672798 100644
>> --- a/arch/arm/cpu/armv7/am33xx/clock.c
>> +++ b/arch/arm/cpu/armv7/am33xx/clock.c
>> @@ -101,9 +101,15 @@ void do_setup_dpll(const struct dpll_regs *dpll_regs,
>>  static void setup_dplls(void)
>>  {
>> const struct dpll_params *params;
>> -   do_setup_dpll(&dpll_core_regs, &dpll_core);
>> -   do_setup_dpll(&dpll_mpu_regs, &dpll_mpu);
>> -   do_setup_dpll(&dpll_per_regs, &dpll_per);
>> +
>> +   params = get_dpll_core_params();
>> +   do_setup_dpll(&dpll_core_regs, params);
>> +
>> +   params = get_dpll_mpu_params();
>> +   do_setup_dpll(&dpll_mpu_regs, params);
>> +
>> +   params = get_dpll_per_params();
>> +   do_setup_dpll(&dpll_per_regs, params);
>> writel(0x300, &cmwkup->clkdcoldodpllper);
>>
>> params = get_dpll_ddr_params();
>> diff --git a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c 
>> b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
>> index fabe259..92142c8 100644
>> --- a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
>> +++ b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
>> @@ -62,6 +62,21 @@ const struct dpll_params dpll_core = {
>>  const struct dpll_params dpll_per = {
>> 960, OSC-1, 5, -1, -1, -1, -1};
>>
>> +const struct dpll_params *get_dpll_mpu_params(void)
>> +{
>> +   return &dpll_mpu;
>> +}
>> +
>> +const struct dpll_params *get_dpll_core_params(void)
>> +{
>> +   return &dpll_core;
>> +}
>> +
>> +const struct dpll_params *get_dpll_per_params(void)
>> +{
>> +   return &dpll_per;
>> +}
>> +
>>  void setup_clocks_for_console(void)
>>  {
>> clrsetbits_le32(&cmwkup->wkclkstctrl, CD_CLKCTRL_CLKTRCTRL_MASK,
>> diff --git a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c 
>> b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
>> index 22963b7..97c00b4 100644
>> --- a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
>> +++ b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
>> @@ -48,15 +48,9 @@ const struct dpll_regs dpll_ddr_regs = {
>> .cm_idlest_dpll = CM_WKUP + 0x5A4,
>> .cm_clksel_dpll = CM_WKUP + 0x5AC,
>> .cm_div_m2_dpll = CM_WKUP + 0x5B0,
>> +   .cm_div_m4_dpll = CM_WKUP + 0x5B8,
>>  };
>>
>> -const struct dpll_params dpll_mpu = {
>> -   -1, -1, -1, -1, -1, -1, -1};
>> -const struct dpll_params dpll_core = {
>> -   -1, -1, -1, -1, -1, -1, -1};
>> -const struct dpll_params dpll_per = {
>> -   -1, -1, -1, -1, -1, -1, -1};
>> -
>>  void setup_clocks_for_console(void)
>>  {
>> /* Do not add any spl_debug prints in this function */
>> diff --git a/arch/arm/include/asm/arch-am33xx/clock.h 
>> b/arch/arm/include/asm/arch-am33xx/clock.h
>> index 519249e..7637457 100644
>> --- a/arch/arm/include/asm/arch-am33xx/clock.h
>> +++ b/arch/arm/include/asm/arch-am33xx/clock.h
>> @@ -98,13 +98,12 @@ extern const struct dpll_regs dpll_mpu_regs;
>>  extern const struct dpll_regs dpll_core_regs;
>>  extern const struct dpll_regs dpll_per_regs;
>>  extern const struct dpll_regs dpll_ddr_regs;
>> -extern const struct dpll_params dpll_mpu;
>> -extern const struct dpll_params dpll_core;
>> -extern const struct dpll_params dpll_per;
>> -extern const struct dpll_params dpll_ddr;
>>
>>  extern struct cm_wkuppll *const cmwkup;
>>
>> +const struct dpll_params *get_dpll_mpu_params(void);
>> +const struct dpll_params *get_dpll_core_params(void);
>> +const struct dpll_params *get_dpll_per_params(void);
>>  const struct dpll_params *ge

Re: [U-Boot] [PATCH 12/14] ARM: AM43xx: EPOS_EVM: Add support for LPDDR2

[Lokesh Vutla]

On Wednesday 06 November 2013 06:27 PM, Vaibhav Bedia wrote:
> On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
>> AM4372 EPOS EVM has 1GB LPDDR2(Part no: MT42L256M32D2LG-25 WT:A)
>> Adding LPDDR2 init sequence and register details for the same.
>> Below is the brief description of LPDDR2 init sequence:
>> -> Configure VTP
>> -> Configure DDR IO settings
>> -> Disable initialization and refreshes until EMIF registers are programmed.
>> -> Program Timing registers
>> -> Program PHY control and Temp alert and ZQ config registers.
>> -> Enable initialization and refreshes and configure SDRAM CONFIG register
>> -> Wait till initialization is complete and the configure MR registers.
>>
> 
> Is there any public documentation to go with this?
> I would suggest sprinkling the code with comments
> to mention the different stages.
Yep ll add the comments in the code..
> 
> BTW, no IO powerdown setting for now?
You mean DDR IO settings?
> 
> [...]
>>
>> +ifeq ($(CONFIG_AM43XX),)
>> +COBJS  += ddr.o
>> +COBJS  += emif4.o
>> +endif
>> +COBJS-$(CONFIG_AM43XX) += emif4d5.o
>> +
> 
> Are the steps really different enough to warrant a new file? Can't the changes
> be handled properly in the code? How has this been handled in OMAPx where
> DDR3 and LPDDR both are supported?
Initially Tom also suggested not to use a new file. I tried with not to add a 
new file,
but I ended up with many #ifdefs. EMIF is new IP(reused from OMAP5) very 
different from AM33xx EMIF IP.
So to make things more cleaner I had to use a new file..

Thanks and regards,
Lokesh

> 
> Regards,
> Vaibhav
> 

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

[U-Boot] [PATCH V2 1/2] driver:usb:s3c_udc: add support for Exynos4x12

[Piotr Wilczek]

This patch add new defines for usb phy for Exynos4x12.

Signed-off-by: Piotr Wilczek 
Signed-off-by: Kyungmin Park 
CC: Minkyu Kang 
---
Changes for v2:
 - no changes

 drivers/usb/gadget/regs-otg.h|5 +
 drivers/usb/gadget/s3c_udc_otg.c |   10 --
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/regs-otg.h b/drivers/usb/gadget/regs-otg.h
index 84bfcc5..ac5d112 100644
--- a/drivers/usb/gadget/regs-otg.h
+++ b/drivers/usb/gadget/regs-otg.h
@@ -226,6 +226,11 @@ struct s3c_usbotg_reg {
 #define CLK_SEL_12MHZ   (0x2 << 0)
 #define CLK_SEL_48MHZ   (0x0 << 0)
 
+#define EXYNOS4X12_ID_PULLUP0  (0x01 << 3)
+#define EXYNOS4X12_COMMON_ON_N0(0x01 << 4)
+#define EXYNOS4X12_CLK_SEL_12MHZ   (0x02 << 0)
+#define EXYNOS4X12_CLK_SEL_24MHZ   (0x05 << 0)
+
 /* Device Configuration Register DCFG */
 #define DEV_SPEED_HIGH_SPEED_20 (0x0 << 0)
 #define DEV_SPEED_FULL_SPEED_20 (0x1 << 0)
diff --git a/drivers/usb/gadget/s3c_udc_otg.c b/drivers/usb/gadget/s3c_udc_otg.c
index 7e20209..cecd280 100644
--- a/drivers/usb/gadget/s3c_udc_otg.c
+++ b/drivers/usb/gadget/s3c_udc_otg.c
@@ -36,6 +36,7 @@
 #include "regs-otg.h"
 #include 
 
+
 /***/
 
 #define OTG_DMA_MODE   1
@@ -167,8 +168,13 @@ void otg_phy_init(struct s3c_udc *dev)
writel((readl(&phy->phypwr) &~(OTG_DISABLE_0 | ANALOG_PWRDOWN)
&~FORCE_SUSPEND_0), &phy->phypwr);
 
-   writel((readl(&phy->phyclk) &~(ID_PULLUP0 | COMMON_ON_N0)) |
-  CLK_SEL_24MHZ, &phy->phyclk); /* PLL 24Mhz */
+   if (s5p_cpu_id == 0x4412)
+   writel((readl(&phy->phyclk) & ~(EXYNOS4X12_ID_PULLUP0 |
+   EXYNOS4X12_COMMON_ON_N0)) | EXYNOS4X12_CLK_SEL_24MHZ,
+  &phy->phyclk); /* PLL 24Mhz */
+   else
+   writel((readl(&phy->phyclk) & ~(ID_PULLUP0 | COMMON_ON_N0)) |
+  CLK_SEL_24MHZ, &phy->phyclk); /* PLL 24Mhz */
 
writel((readl(&phy->rstcon) &~(LINK_SW_RST | PHYLNK_SW_RST))
   | PHY_SW_RST0, &phy->rstcon);
-- 
1.7.9.5

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

[U-Boot] [PATCH V2 2/2] trats2: enable ums support on Trats2

[Piotr Wilczek]

This patch adds support for USB and enables 'ums' command on Trats2 board.

Signed-off-by: Piotr Wilczek 
Signed-off-by: Kyungmin Park 
CC: Minkyu Kang 
---
This patch depends on the lated u-boot-usb/master.

Changes for v2:
 - rebased on current USB tree
 - removed unnecessary pmic probing

 board/samsung/trats2/trats2.c |   92 +
 include/configs/trats2.h  |   18 
 2 files changed, 110 insertions(+)

diff --git a/board/samsung/trats2/trats2.c b/board/samsung/trats2/trats2.c
index d44d825..41a7310 100644
--- a/board/samsung/trats2/trats2.c
+++ b/board/samsung/trats2/trats2.c
@@ -25,6 +25,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -308,6 +311,95 @@ int board_mmc_init(bd_t *bis)
return err0 & err2;
 }
 
+#ifdef CONFIG_USB_GADGET
+static int s5pc210_phy_control(int on)
+{
+   int ret = 0;
+   unsigned int val;
+   struct pmic *p, *p_pmic, *p_muic;
+
+   p_pmic = pmic_get("MAX77686_PMIC");
+   if (!p_pmic)
+   return -ENODEV;
+
+   if (pmic_probe(p_pmic))
+   return -1;
+
+   p_muic = pmic_get("MAX77693_MUIC");
+   if (!p_muic)
+   return -ENODEV;
+
+   if (pmic_probe(p_muic))
+   return -1;
+
+   if (on) {
+   ret = max77686_set_ldo_mode(p_pmic, 12, OPMODE_ON);
+   if (ret)
+   return -1;
+
+   p = pmic_get("MAX77693_PMIC");
+   if (!p)
+   return -ENODEV;
+
+   if (pmic_probe(p))
+   return -1;
+
+   /* SAFEOUT */
+   ret = pmic_reg_read(p, MAX77693_SAFEOUT, &val);
+   if (ret)
+   return -1;
+
+   val |= MAX77693_ENSAFEOUT1;
+   ret = pmic_reg_write(p, MAX77693_SAFEOUT, val);
+   if (ret)
+   return -1;
+
+   /* PATH: USB */
+   ret = pmic_reg_write(p_muic, MAX77693_MUIC_CONTROL1,
+   MAX77693_MUIC_CTRL1_DN1DP2);
+
+   } else {
+   ret = max77686_set_ldo_mode(p_pmic, 12, OPMODE_LPM);
+   if (ret)
+   return -1;
+
+   /* PATH: UART */
+   ret = pmic_reg_write(p_muic, MAX77693_MUIC_CONTROL1,
+   MAX77693_MUIC_CTRL1_UT1UR2);
+   }
+
+   if (ret)
+   return -1;
+
+
+   return 0;
+}
+
+struct s3c_plat_otg_data s5pc210_otg_data = {
+   .phy_control= s5pc210_phy_control,
+   .regs_phy   = EXYNOS4X12_USBPHY_BASE,
+   .regs_otg   = EXYNOS4X12_USBOTG_BASE,
+   .usb_phy_ctrl   = EXYNOS4X12_USBPHY_CONTROL,
+   .usb_flags  = PHY0_SLEEP,
+};
+
+int board_usb_init(int index, enum usb_init_type init)
+{
+   debug("USB_udc_probe\n");
+   return s3c_udc_probe(&s5pc210_otg_data);
+}
+
+#ifdef CONFIG_USB_CABLE_CHECK
+int usb_cable_connected(void)
+{
+   struct pmic *muic = pmic_get("MAX77693_MUIC");
+   int cable_connected = muic->chrg->chrg_type(muic);
+
+   return !!cable_connected;
+}
+#endif
+#endif
+
 static int pmic_init_max77686(void)
 {
struct pmic *p = pmic_get("MAX77686_PMIC");
diff --git a/include/configs/trats2.h b/include/configs/trats2.h
index 0e93836..66b1c95 100644
--- a/include/configs/trats2.h
+++ b/include/configs/trats2.h
@@ -113,6 +113,16 @@
 #define CONFIG_CMD_EXT4
 #define CONFIG_CMD_EXT4_WRITE
 
+/* USB Composite download gadget - g_dnl */
+#define CONFIG_USBDOWNLOAD_GADGET
+#define CONFIG_DFU_FUNCTION
+#define CONFIG_DFU_MMC
+
+/* USB Samsung's IDs */
+#define CONFIG_G_DNL_VENDOR_NUM 0x04E8
+#define CONFIG_G_DNL_PRODUCT_NUM 0x6601
+#define CONFIG_G_DNL_MANUFACTURER "Samsung"
+
 /* To use the TFTPBOOT over USB, Please enable the CONFIG_CMD_NET */
 #undef CONFIG_CMD_NET
 
@@ -293,6 +303,11 @@
 #define CONFIG_POWER_MUIC_MAX77693
 #define CONFIG_POWER_FG_MAX77693
 #define CONFIG_POWER_BATTERY_TRATS2
+#define CONFIG_USB_GADGET
+#define CONFIG_USB_GADGET_S3C_UDC_OTG
+#define CONFIG_USB_GADGET_DUALSPEED
+#define CONFIG_USB_GADGET_VBUS_DRAW2
+#define CONFIG_USB_CABLE_CHECK
 
 /* LCD */
 #define CONFIG_EXYNOS_FB
@@ -305,6 +320,9 @@
 #define CONFIG_VIDEO_BMP_GZIP
 #define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE ((500 * 250 * 4) + (1 << 12))
 
+#define CONFIG_CMD_USB_MASS_STORAGE
+#define CONFIG_USB_GADGET_MASS_STORAGE
+
 /* Pass open firmware flat tree */
 #define CONFIG_OF_LIBFDT1
 
-- 
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 07/34] zynq: Add UART0, UART1 configs support

[Dinh Nguyen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


On 11/6/13 12:45 AM, Michal Simek wrote:
> On 11/06/2013 05:17 AM, Dinh Nguyen wrote:
>>
>> On 11/5/13 11:46 AM, Jagannadha Sutradharudu Teki wrote:
>>> Zynq uart controller support two serial ports like
>>> CONFIG_ZYNQ_SERIAL_UART0 and CONFIG_ZYNQ_SERIAL_UART1
>>> enabled both so-that the respective board will define
>>> these macros based on their usage.
>>>
>>> Signed-off-by: Jagannadha Sutradharudu Teki 
>>> ---
>>>  include/configs/zynq.h | 20 
>>>  1 file changed, 16 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/include/configs/zynq.h b/include/configs/zynq.h
>>> index f32008b..1bcb28d 100644
>>> --- a/include/configs/zynq.h
>>> +++ b/include/configs/zynq.h
>>> @@ -33,10 +33,22 @@
>>>  {300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200,
230400}
>>> 
>>>  /* Zynq Serial driver */
>>> -#define CONFIG_ZYNQ_SERIAL
>>> -#define CONFIG_ZYNQ_SERIAL_BASEADDR00xE0001000
>>> -#define CONFIG_ZYNQ_SERIAL_BAUDRATE0CONFIG_BAUDRATE
>>> -#define CONFIG_ZYNQ_SERIAL_CLOCK05000
>>> +#define CONFIG_ZYNQ_SERIAL_UART1
>>> +#ifdef CONFIG_ZYNQ_SERIAL_UART0
>>> +# define CONFIG_ZYNQ_SERIAL_BASEADDR00xE000
>>> +# define CONFIG_ZYNQ_SERIAL_BAUDRATE0CONFIG_BAUDRATE
>> Why couldn't you just use CONFIG_BAUDRATE? Why do you need to add
>> another define?
>
> If we start to use the same CONFIG_BAUDRATE(or better gd->baudrate)
> in the driver then we lose config options to setup different baudrate
> for every single device.
>
> I haven't seen any code for SERIAL_MULTI if you want to configure
> 2 serial drivers but on different baudrate.
> If there is better way how to do it please let us know.
I guess the question then is what would be the use case for supporting
different baudrates on different device?

Dinh
>
>
> Thanks,
> Michal
>

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJSekkTAAoJEBmUBAuBoyj03s8QAKZ/t9Ou2JAlcy8kg1Dqh1P5
CnBgoqekXEVJf8prPrK3sCx5l4bvmCY4yx84O7pqQFYW7uSWW3M7m6yxBoaQbDmx
nH6fDnd8aiAd1YgTpzbsoFI/ZJQ2hla/xnjFwzfjIfPtWrdqmqvltDmgKnRT1Zxi
HDQCgnQSQQKAvz7wZ+/U5i8xXI9nSEPALqvHrSpKrgBLWSAwbVCVf+FNYcPIoMh9
cZ9QNUW5FVmC9eLdCNUKr3mZoe2RIdrWS7/FPSQge9OjW84syoY6JPH7L0e4toDM
Wmf84+3/rbBw87aC6hbBYvX1jpeb/St7ylxJqTZQ/6HUKlDmWSR9H5isfz3ndaej
uT9pmK4dLDBaWRwdlSzogjsJEfbntiFYKiQsJmcL6ykB7yJCqiD4+ErF8SLCDAsD
1Dtvl+Kd6MeVXnoWuPc6XI0pJjabgGyJIHfZaEX3XfI3ybokedYxQpnavGrU2Dyz
YYQqRgnmaQQwzEI1eYjwazNNAqfdkM6s0olBYelON20yc685/3gQcLjNNs13U9i7
rT5ck+7oaW7+8jazDFjvYynuvdVAeeSwh0cSP3ZSHRYwS3ddAi8EG+HhOkrr3trZ
Hmbso2nF33ofjPe4ZJqQDfVyhBAeTcMx2p5L0d1piEkHKi77MTehpU1Fp3LAvSZ5
NUq9dEtCltJNFD0Cgd9Q
=O22Y
-END PGP SIGNATURE-

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

Re: [U-Boot] [RFC PATCH 2/2] usb: dfu: correct dfu buffer inited value

[Marek Vasut]

Dear Lukasz Majewski,

> Hi Bo,
> 
> First of all, sorry for a little delay.
> 
> > Hi Lukasz,
> > 
> > On 11/4/2013 18:17, Lukasz Majewski wrote:
> > > Hi Bo,
> > > 
> > >> After dfu buffer is initialized, the buffer should be all
> > >> available, while not 0. Initialize its value to min(dfu_buf_size,
> > >> dfu->r_left).
> > >> 
> > >> Signed-off-by: Bo Shen 
> > >> 
> > >> ---
> > >> 
> > >>   drivers/dfu/dfu.c |2 +-
> > >>   1 file changed, 1 insertion(+), 1 deletion(-)
> > >> 
> > >> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> > >> index 65c6984..b8c8aa4 100644
> > >> --- a/drivers/dfu/dfu.c
> > >> +++ b/drivers/dfu/dfu.c
> > >> @@ -288,7 +288,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
> > >> int size, int blk_seq_num) dfu->offset = 0;
> > >> 
> > >>  dfu->i_buf_end = dfu_get_buf() + dfu_buf_size;
> > >>  dfu->i_buf = dfu->i_buf_start;
> > >> 
> > >> -dfu->b_left = 0;
> > >> +dfu->b_left = min(dfu_buf_size, dfu->r_left);
> > > 
> > > I've testd in on Trats. It causes dfu read to be performed two
> > > times.
> > 
> > Have you apply these two patches together:
> > [RFC PATCH 1/2] usb: dfu: decrease dfu->r_left along with the transfer
> > [RFC PATCH 2/2] usb: dfu: correct dfu buffer inited value
> 
> I did a "little" mistake when applying those patches. When both patches
> are applied dfu works fine.
> 
> I've tested it on Trats (Exynos4210).
> 
> For:
> [RFC PATCH 1/2] usb: dfu: decrease dfu->r_left along with the transfer
> [RFC PATCH 2/2] usb: dfu: correct dfu buffer inited value
> 
> Tested-by: Lukasz Majewski 
> Acked-by: Lukasz Majewski 
> 
> @ Marek,
> 
> Since I'm still struggling with internal firewall - Marek could you
> apply those two patches to u-boot-usb tree?
> 
> Also please apply Heiko's patch:
> 
> [PATCH v3 3/5] usb, g_dnl: make iSerialNumber board configurable
> 
> Thanks in advance.

Roger that, all done, thanks!

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

Re: [U-Boot] [PATCH 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3

[Lokesh Vutla]

On Wednesday 06 November 2013 06:32 PM, Vaibhav Bedia wrote:
> On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
>> GP EVM has 1GB DDR3 attached(Part no: MT47H128M16RT-187E:C).
>> Adding details for the same.
>> Below is the brief description of DDR3 init sequence(SW leveling):
>> -> Enable VTT regulator
>> -> Configure VTP
>> -> Configure DDR IO settings
>> -> Disable initialization and refreshes until EMIF registers are programmed.
>> -> Program Timing registers
>> -> Program leveling registers
>> -> Program PHY control and Temp alert and ZQ config registers.
> 
> Temp alert? Is that really relevant here?
Yes, Need to configure all the emif registers before accessing SDRAM.
> 
>> -> Enable initialization and refreshes and configure SDRAM CONFIG register
>>
>> Signed-off-by: Lokesh Vutla 
>> ---
>>  arch/arm/cpu/armv7/am33xx/emif4d5.c |8 ++-
>>  arch/arm/include/asm/arch-am33xx/ddr_defs.h |   10 ++-
>>  board/ti/am43xx/board.c |   89 
>> ++-
>>  3 files changed, 101 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/am33xx/emif4d5.c 
>> b/arch/arm/cpu/armv7/am33xx/emif4d5.c
>> index eea1fa3..8bac0f2 100644
>> --- a/arch/arm/cpu/armv7/am33xx/emif4d5.c
>> +++ b/arch/arm/cpu/armv7/am33xx/emif4d5.c
>> @@ -120,7 +120,7 @@ static void configure_mr(u32 base, u32 cs)
>>
>>  void do_sdram_init(const struct ctrl_ioregs *ioregs,
>>const struct emif_regs *regs,
>> -  const u32 *ext_phy_ctrl_const_regs)
>> +  const u32 *ext_phy_ctrl_const_regs, u32 sdram_type)
>>  {
>> struct emif_reg_struct *emif = (struct emif_reg_struct *)EMIF1_BASE;
>>
>> @@ -178,6 +178,8 @@ void do_sdram_init(const struct ctrl_ioregs *ioregs,
>> writel(regs->sdram_config, &emif->emif_sdram_config);
>> writel(regs->ref_ctrl, &emif->emif_sdram_ref_ctrl);
>>
>> -   configure_mr(EMIF1_BASE, 0);
>> -   configure_mr(EMIF1_BASE, 1);
>> +   if (sdram_type == EMIF_SDRAM_TYPE_LPDDR2) {
>> +   configure_mr(EMIF1_BASE, 0);
>> +   configure_mr(EMIF1_BASE, 1);
>> +   }
>>  }
>> diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h 
>> b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
>> index 1880415..796e9df 100644
>> --- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
>> +++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
>> @@ -134,6 +134,14 @@
>>  #define  LPDDR2_DATA2_IOCTRL_VALUE   0x2294
>>  #define  LPDDR2_DATA3_IOCTRL_VALUE   0x2294
>>
>> +#define  DDR3_ADDRCTRL_WD0_IOCTRL_VALUE 0x
>> +#define  DDR3_ADDRCTRL_WD1_IOCTRL_VALUE 0x
>> +#define  DDR3_ADDRCTRL_IOCTRL_VALUE   0x84
>> +#define  DDR3_DATA0_IOCTRL_VALUE   0x84
>> +#define  DDR3_DATA1_IOCTRL_VALUE   0x84
>> +#define  DDR3_DATA2_IOCTRL_VALUE   0x84
>> +#define  DDR3_DATA3_IOCTRL_VALUE   0x84
>> +
>>  /**
>>   * Configure DMM
>>   */
>> @@ -333,5 +341,5 @@ void config_ddr(unsigned int pll, unsigned int ioctrl,
>>
>>  void do_sdram_init(const struct ctrl_ioregs *ioregs,
>>const struct emif_regs *emif_regs,
>> -  const u32 *ext_phy_ctrl_const_regs);
>> +  const u32 *ext_phy_ctrl_const_regs, u32 ddr_type);
>>  #endif  /* _DDR_DEFS_H */
>> diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
>> index 83d184d..a943b45 100644
>> --- a/board/ti/am43xx/board.c
>> +++ b/board/ti/am43xx/board.c
>> @@ -140,6 +140,57 @@ const u32 
>> ext_phy_ctrl_const_base_lpddr2[EMIF_EXT_PHY_CTRL_CONST_REG] = {
>> 0x08102040
>>  };
>>
>> +const struct ctrl_ioregs ioregs_ddr3 = {
>> +   .cm0ioctl   = DDR3_ADDRCTRL_IOCTRL_VALUE,
>> +   .cm1ioctl   = DDR3_ADDRCTRL_WD0_IOCTRL_VALUE,
>> +   .cm2ioctl   = DDR3_ADDRCTRL_WD1_IOCTRL_VALUE,
>> +   .dt0ioctl   = DDR3_DATA0_IOCTRL_VALUE,
>> +   .dt1ioctl   = DDR3_DATA0_IOCTRL_VALUE,
>> +   .dt2ioctrl  = DDR3_DATA0_IOCTRL_VALUE,
>> +   .dt3ioctrl  = DDR3_DATA0_IOCTRL_VALUE,
>> +   .emif_sdram_config_ext  = 0x0043,
>> +};
>> +
>> +const struct emif_regs ddr3_emif_regs_400Mhz = {
>> +   .sdram_config   = 0x638413B2,
>> +   .ref_ctrl   = 0x0C30,
>> +   .sdram_tim1 = 0xEAAAD4DB,
>> +   .sdram_tim2 = 0x266B7FDA,
>> +   .sdram_tim3 = 0x107F8678,
>> +   .read_idle_ctrl = 0x0005,
>> +   .zq_config  = 0x50074BE4,
>> +   .temp_alert_config  = 0x0,
>> +   .emif_ddr_phy_ctlr_1= 0x0E084007,
>> +   .emif_ddr_ext_phy_ctrl_1= 0x08020080,
>> +   .emif_ddr_ext_phy_ctrl_2= 0x00400040,
>> +   .emif_ddr_ext_phy_ctrl_3= 0x00400040,
>> +   .emif_ddr_ext_phy_ctrl_4= 0x00400040,
>> +   .emif_ddr_ext_phy_ctrl_5= 0x00400040
>> +};
>> +
>> +const u32 ext_phy_ctrl_const

[U-Boot] [PATCH] cm-t35: use gpio_led driver for status led

[Igor Grinberg]

Switch to using the generic gpio_led driver instead of the private to
cm_t35 board led implementation.

Signed-off-by: Igor Grinberg 
Tested-by: Nikita Kiryanov 
---
 board/compulab/cm_t35/Makefile |  2 +-
 board/compulab/cm_t35/leds.c   | 33 -
 include/configs/cm_t35.h   |  9 +
 3 files changed, 6 insertions(+), 38 deletions(-)
 delete mode 100644 board/compulab/cm_t35/leds.c

diff --git a/board/compulab/cm_t35/Makefile b/board/compulab/cm_t35/Makefile
index 213423e..4b1d591 100644
--- a/board/compulab/cm_t35/Makefile
+++ b/board/compulab/cm_t35/Makefile
@@ -11,7 +11,7 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)lib$(BOARD).o
 
-COBJS  := cm_t35.o leds.o $(COBJS-y)
+COBJS  := cm_t35.o $(COBJS-y)
 
 SRCS   := $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS))
diff --git a/board/compulab/cm_t35/leds.c b/board/compulab/cm_t35/leds.c
deleted file mode 100644
index 7e2803e..000
--- a/board/compulab/cm_t35/leds.c
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * (C) Copyright 2011 - 2013 CompuLab, Ltd. 
- *
- * Author: Igor Grinberg 
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-
-static unsigned int leds[] = { GREEN_LED_GPIO };
-
-void __led_init(led_id_t mask, int state)
-{
-   if (gpio_request(leds[mask], "") != 0) {
-   printf("%s: failed requesting GPIO%u\n", __func__, leds[mask]);
-   return;
-   }
-
-   gpio_direction_output(leds[mask], 0);
-}
-
-void __led_set(led_id_t mask, int state)
-{
-   gpio_set_value(leds[mask], state == STATUS_LED_ON);
-}
-
-void __led_toggle(led_id_t mask)
-{
-   gpio_set_value(leds[mask], !gpio_get_value(leds[mask]));
-}
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index eff35b9..db73c48 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -303,12 +303,13 @@
 /* Status LED */
 #define CONFIG_STATUS_LED  /* Status LED enabled */
 #define CONFIG_BOARD_SPECIFIC_LED
-#define STATUS_LED_GREEN   0
-#define STATUS_LED_BIT STATUS_LED_GREEN
+#define CONFIG_GPIO_LED
+#define GREEN_LED_GPIO 186 /* CM-T35 Green LED is GPIO186 */
+#define GREEN_LED_DEV  0
+#define STATUS_LED_BIT GREEN_LED_GPIO
 #define STATUS_LED_STATE   STATUS_LED_ON
 #define STATUS_LED_PERIOD  (CONFIG_SYS_HZ / 2)
-#define STATUS_LED_BOOTSTATUS_LED_BIT
-#define GREEN_LED_GPIO 186 /* CM-T35 Green LED is GPIO186 */
+#define STATUS_LED_BOOTGREEN_LED_DEV
 
 #define CONFIG_SPLASHIMAGE_GUARD
 
-- 
1.8.1.5

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

Re: [U-Boot] [PATCH] cm-t35: move the leds code to common place

[Igor Grinberg]

Hi Tom,

Please, disregard this patch in favor to the new one I've just sent.

Thanks and sorry for the noise!

On 11/05/13 10:23, Igor Grinberg wrote:
> Compulab boards can use the same leds code, so move the leds related
> code to live under board/compulab/common directory.
> 
> Signed-off-by: Igor Grinberg 
> Tested-by: Nikita Kiryanov 
> ---
> Tom,
> 
> AFAIU the merge window closes on Thursday.
> Can we please have this patch in for 2014.01?
> 
> Thanks!
> 
> Sorry, if anyone gets this message twice...
> I had a problem with my mailer...
> 
> 
>  board/compulab/cm_t35/Makefile   | 2 +-
>  board/compulab/common/Makefile   | 1 +
>  board/compulab/{cm_t35 => common}/leds.c | 0
>  3 files changed, 2 insertions(+), 1 deletion(-)
>  rename board/compulab/{cm_t35 => common}/leds.c (100%)
> 
> diff --git a/board/compulab/cm_t35/Makefile b/board/compulab/cm_t35/Makefile
> index 213423e..4b1d591 100644
> --- a/board/compulab/cm_t35/Makefile
> +++ b/board/compulab/cm_t35/Makefile
> @@ -11,7 +11,7 @@ include $(TOPDIR)/config.mk
>  
>  LIB  = $(obj)lib$(BOARD).o
>  
> -COBJS:= cm_t35.o leds.o $(COBJS-y)
> +COBJS:= cm_t35.o $(COBJS-y)
>  
>  SRCS := $(COBJS:.o=.c)
>  OBJS := $(addprefix $(obj),$(COBJS))
> diff --git a/board/compulab/common/Makefile b/board/compulab/common/Makefile
> index b399c8f..312d955 100644
> --- a/board/compulab/common/Makefile
> +++ b/board/compulab/common/Makefile
> @@ -16,6 +16,7 @@ LIB = $(obj)lib$(VENDOR).o
>  
>  COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += eeprom.o
>  COBJS-$(CONFIG_LCD) += omap3_display.o
> +COBJS-$(CONFIG_STATUS_LED) += leds.o
>  
>  COBJS:= $(COBJS-y)
>  SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> diff --git a/board/compulab/cm_t35/leds.c b/board/compulab/common/leds.c
> similarity index 100%
> rename from board/compulab/cm_t35/leds.c
> rename to board/compulab/common/leds.c
> 

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

[U-Boot] [PATCH 4/5] ARM: OMAP5: Add SATA platform glue

[Roger Quadros]

Add platform glue logic for the SATA controller.

Signed-off-by: Roger Quadros 
---
 arch/arm/cpu/armv7/omap-common/Makefile |  3 ++
 arch/arm/cpu/armv7/omap-common/sata.c   | 78 +
 arch/arm/include/asm/arch-omap5/sata.h  | 48 
 3 files changed, 129 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/omap-common/sata.c
 create mode 100644 arch/arm/include/asm/arch-omap5/sata.h

diff --git a/arch/arm/cpu/armv7/omap-common/Makefile 
b/arch/arm/cpu/armv7/omap-common/Makefile
index 6e4a0f0..0535b62 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -23,6 +23,9 @@ endif
 
 ifneq ($(CONFIG_OMAP54XX),)
 COBJS  += pipe3-phy.o
+ifdef CONFIG_SCSI_AHCI_PLAT
+COBJS  += sata.o
+endif
 endif
 
 ifeq ($(CONFIG_OMAP34XX),)
diff --git a/arch/arm/cpu/armv7/omap-common/sata.c 
b/arch/arm/cpu/armv7/omap-common/sata.c
new file mode 100644
index 000..eb079c3
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/sata.c
@@ -0,0 +1,78 @@
+/*
+ * TI SATA platform driver
+ *
+ * (C) Copyright 2013
+ * Texas Instruments, 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pipe3-phy.h"
+
+#if defined(CONFIG_SCSI_AHCI_PLAT)
+
+static struct pipe3_dpll_map dpll_map_sata[] = {
+   {1200, {1000, 7, 4, 6, 0} },/* 12 MHz */
+   {1680, {714, 7, 4, 6, 0} }, /* 16.8 MHz */
+   {1920, {625, 7, 4, 6, 0} }, /* 19.2 MHz */
+   {2000, {600, 7, 4, 6, 0} }, /* 20 MHz */
+   {2600, {461, 7, 4, 6, 0} }, /* 26 MHz */
+   {3840, {312, 7, 4, 6, 0} }, /* 38.4 MHz */
+   { },/* Terminator */
+};
+
+struct omap_pipe3 sata_phy = {
+   .pll_ctrl_base = (void __iomem *)TI_SATA_PLLCTRL_BASE,
+   /* .power_reg is updated at runtime */
+   .dpll_map = dpll_map_sata,
+};
+
+int omap_sata_init(void)
+{
+   int ret;
+   u32 val;
+
+   u32 const clk_domains_sata[] = {
+   0
+   };
+
+   u32 const clk_modules_hw_auto_sata[] = {
+   (*prcm)->cm_l3init_ocp2scp3_clkctrl,
+   0
+   };
+
+   u32 const clk_modules_explicit_en_sata[] = {
+   (*prcm)->cm_l3init_sata_clkctrl,
+   0
+   };
+
+   do_enable_clocks(clk_domains_sata,
+   clk_modules_hw_auto_sata,
+   clk_modules_explicit_en_sata,
+   0);
+
+   /* Enable optional functional clock for SATA */
+   setbits_le32((*prcm)->cm_l3init_sata_clkctrl,
+   SATA_CLKCTRL_OPTFCLKEN_MASK);
+
+   sata_phy.power_reg = (void __iomem *)(*ctrl)->control_phy_power_sata;
+
+   /* Power up the PHY */
+   phy_pipe3_power_on(&sata_phy);
+
+   /* Enable SATA module, No Idle, No Standby */
+   val = TI_SATA_IDLE_NO | TI_SATA_STANDBY_NO;
+   writel(val, TI_SATA_WRAPPER_BASE + TI_SATA_SYSCONFIG);
+
+   ret = ahci_init(DWC_AHSATA_BASE);
+   scsi_scan(1);
+
+   return ret;
+}
+#endif
diff --git a/arch/arm/include/asm/arch-omap5/sata.h 
b/arch/arm/include/asm/arch-omap5/sata.h
new file mode 100644
index 000..2ca8947
--- /dev/null
+++ b/arch/arm/include/asm/arch-omap5/sata.h
@@ -0,0 +1,48 @@
+/*
+ * SATA Wrapper Register map
+ *
+ * (C) Copyright 2013
+ * Texas Instruments, 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _TI_SATA_H
+#define _TI_SATA_H
+
+/* SATA Wrapper module */
+#define TI_SATA_WRAPPER_BASE   (OMAP54XX_L4_CORE_BASE + 0x141100)
+/* SATA PHY Module */
+#define TI_SATA_PLLCTRL_BASE   (OMAP54XX_L4_CORE_BASE + 0x96800)
+
+/* SATA Wrapper register offsets */
+#define TI_SATA_SYSCONFIG  0x00
+#define TI_SATA_CDRLOCK0x04
+
+/* Register Set */
+#define TI_SATA_SYSCONFIG_OVERRIDE0(1 << 16)
+#define TI_SATA_SYSCONFIG_STANDBY_MASK (0x3 << 4)
+#define TI_SATA_SYSCONFIG_IDLE_MASK(0x3 << 2)
+
+/* Standby modes */
+#define TI_SATA_STANDBY_FORCE  0x0
+#define TI_SATA_STANDBY_NO (0x1 << 4)
+#define TI_SATA_STANDBY_SMART_WAKE (0x3 << 4)
+#define TI_SATA_STANDBY_SMART  (0x2 << 4)
+
+/* Idle modes */
+#define TI_SATA_IDLE_FORCE 0x0
+#define TI_SATA_IDLE_NO(0x1 << 2)
+#define TI_SATA_IDLE_SMART_WAKE(0x3 << 2)
+#define TI_SATA_IDLE_SMART (0x2 << 2)
+
+#ifdef CONFIG_SCSI_AHCI_PLAT
+int omap_sata_init(void);
+#else
+static inline int omap_sata_init(void)
+{
+   return 0;
+}
+#endif /* CONFIG_SCSI_AHCI_PLAT */
+
+#endif /* _TI_SATA_H */
-- 
1.8.3.2

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

[U-Boot] [RFC][PATCH 0/5] SATA support for OMAP5 uevm

[Roger Quadros]

Hi,

This series adds SATA support for OMAP5 uevm board.

This is an RFC patchset for review only. Patches are based
on v2013.10.

cheers,
-roger

---
Roger Quadros (5):
  ahci: Error out with message on malloc() failure
  ARM: OMAP5: Add Pipe3 PHY driver
  ARM: OMAP5: Add PRCM and Control information for SATA
  ARM: OMAP5: Add SATA platform glue
  ARM: omap5_uevm: Add SATA support

 arch/arm/cpu/armv7/omap-common/Makefile|   7 +
 arch/arm/cpu/armv7/omap-common/pipe3-phy.c | 233 +
 arch/arm/cpu/armv7/omap-common/pipe3-phy.h |  36 +
 arch/arm/cpu/armv7/omap-common/sata.c  |  78 ++
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |   5 +
 arch/arm/include/asm/arch-omap5/clock.h|   3 +
 arch/arm/include/asm/arch-omap5/omap.h |   3 +
 arch/arm/include/asm/arch-omap5/sata.h |  48 ++
 arch/arm/include/asm/omap_common.h |   3 +
 board/ti/omap5_uevm/evm.c  |   7 +
 drivers/block/ahci.c   |  16 +-
 include/configs/omap5_uevm.h   |  10 ++
 12 files changed, 447 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.c
 create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.h
 create mode 100644 arch/arm/cpu/armv7/omap-common/sata.c
 create mode 100644 arch/arm/include/asm/arch-omap5/sata.h

-- 
1.8.3.2

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

[U-Boot] [PATCH 2/5] ARM: OMAP5: Add Pipe3 PHY driver

[Roger Quadros]

Pipe3 PHY is used by SATA, USB3 and PCIe modules. This is
a driver for the Pipe3 PHY.

Signed-off-by: Roger Quadros 
---
 arch/arm/cpu/armv7/omap-common/Makefile|   4 +
 arch/arm/cpu/armv7/omap-common/pipe3-phy.c | 233 +
 arch/arm/cpu/armv7/omap-common/pipe3-phy.h |  36 +
 3 files changed, 273 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.c
 create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.h

diff --git a/arch/arm/cpu/armv7/omap-common/Makefile 
b/arch/arm/cpu/armv7/omap-common/Makefile
index 75b3753..6e4a0f0 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -21,6 +21,10 @@ COBJS+= vc.o
 COBJS  += abb.o
 endif
 
+ifneq ($(CONFIG_OMAP54XX),)
+COBJS  += pipe3-phy.o
+endif
+
 ifeq ($(CONFIG_OMAP34XX),)
 COBJS  += boot-common.o
 SOBJS  += lowlevel_init.o
diff --git a/arch/arm/cpu/armv7/omap-common/pipe3-phy.c 
b/arch/arm/cpu/armv7/omap-common/pipe3-phy.c
new file mode 100644
index 000..2756bed
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/pipe3-phy.c
@@ -0,0 +1,233 @@
+/*
+ * TI PIPE3 PHY
+ *
+ * (C) Copyright 2013
+ * Texas Instruments, 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pipe3-phy.h"
+
+/* PLLCTRL Registers */
+#define PLL_STATUS  0x0004
+#define PLL_GO  0x0008
+#define PLL_CONFIGURATION1  0x000C
+#define PLL_CONFIGURATION2  0x0010
+#define PLL_CONFIGURATION3  0x0014
+#define PLL_CONFIGURATION4  0x0020
+
+#define PLL_REGM_MASK   0x001FFE00
+#define PLL_REGM_SHIFT  9
+#define PLL_REGM_F_MASK 0x0003
+#define PLL_REGM_F_SHIFT0
+#define PLL_REGN_MASK   0x01FE
+#define PLL_REGN_SHIFT  1
+#define PLL_SELFREQDCO_MASK 0x000E
+#define PLL_SELFREQDCO_SHIFT1
+#define PLL_SD_MASK 0x0003FC00
+#define PLL_SD_SHIFT10
+#define SET_PLL_GO  0x1
+#define PLL_TICOPWDNBIT(16)
+#define PLL_LDOPWDN BIT(15)
+#define PLL_LOCK0x2
+#define PLL_IDLE0x1
+
+/* PHY POWER CONTROL Register */
+#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK 0x003FC000
+#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT0xE
+
+#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK0xFFC0
+#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT   0x16
+
+#define OMAP_CTRL_PIPE3_PHY_TX_RX_POWERON   0x3
+#define OMAP_CTRL_PIPE3_PHY_TX_RX_POWEROFF  0x0
+
+
+#define PLL_IDLE_TIME   100 /* in milliseconds */
+#define PLL_LOCK_TIME   100 /* in milliseconds */
+
+#define perror(fmt, args...) printf("%s: " fmt, __func__ , ##args)
+
+static inline u32 omap_pipe3_readl(void __iomem *addr, unsigned offset)
+{
+   return __raw_readl(addr + offset);
+}
+
+static inline void omap_pipe3_writel(void __iomem *addr, unsigned offset,
+   u32 data)
+{
+   __raw_writel(data, addr + offset);
+}
+
+static struct pipe3_dpll_params *omap_pipe3_get_dpll_params(struct omap_pipe3
+   *pipe3)
+{
+   u32 rate;
+   struct pipe3_dpll_map *dpll_map = pipe3->dpll_map;
+
+   rate = get_sys_clk_freq();
+
+   for (; dpll_map->rate; dpll_map++) {
+   if (rate == dpll_map->rate)
+   return &dpll_map->params;
+   }
+
+   perror("%s: No DPLL configuration for %u Hz SYS CLK\n",
+   __func__, rate);
+   return NULL;
+}
+
+
+static int omap_pipe3_wait_lock(struct omap_pipe3 *phy)
+{
+   u32 val;
+   int timeout = PLL_LOCK_TIME;
+
+   do {
+   mdelay(1);
+   val = omap_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS);
+   if (val & PLL_LOCK)
+   break;
+   } while (--timeout);
+
+   if (!(val & PLL_LOCK)) {
+   perror("%s: DPLL failed to lock\n", __func__);
+   return -EBUSY;
+   }
+
+   return 0;
+}
+
+static int omap_pipe3_dpll_program(struct omap_pipe3 *phy)
+{
+   u32 val;
+   struct pipe3_dpll_params *dpll_params;
+
+   dpll_params = omap_pipe3_get_dpll_params(phy);
+   if (!dpll_params) {
+   perror("%s: Invalid DPLL parameters\n", __func__);
+   return -EINVAL;
+   }
+
+   val = omap_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION1);
+   val &= ~PLL_REGN_MASK;
+   val |= dpll_params->n << PLL_REGN_SHIFT;
+   omap_pipe3_writel(phy->pll_ctrl_base, PLL_CONFIGURATION1, val);
+
+   val = omap_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2);
+   val &= ~PLL_SELFREQDCO_MASK;
+   val |= dpll_params->freq << PLL_SELFREQDCO_SHIFT;
+   omap_pipe3_writel(phy->pll_ctrl_base, PLL_CONFIGURATION2, val);
+
+   val = omap_

[U-Boot] [PATCH 1/5] ahci: Error out with message on malloc() failure

[Roger Quadros]

If malloc() fails, we don't want to continue in ahci_init() and
ahci_init_one(). Also print a more informative error message on
malloc() failures.

CC: Rob Herring 
Signed-off-by: Roger Quadros 
---
 drivers/block/ahci.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 0daad36..e24d634 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -379,6 +379,11 @@ static int ahci_init_one(pci_dev_t pdev)
int rc;
 
probe_ent = malloc(sizeof(struct ahci_probe_ent));
+   if (!probe_ent) {
+   printf("%s: No memory for probe_ent\n", __func__);
+   return -ENOMEM;
+   }
+
memset(probe_ent, 0, sizeof(struct ahci_probe_ent));
probe_ent->dev = pdev;
 
@@ -503,7 +508,7 @@ static int ahci_port_start(u8 port)
mem = (u32) malloc(AHCI_PORT_PRIV_DMA_SZ + 2048);
if (!mem) {
free(pp);
-   printf("No mem for table!\n");
+   printf("%s: No mem for table!\n", __func__);
return -ENOMEM;
}
 
@@ -638,8 +643,10 @@ static int ata_scsiop_inquiry(ccb *pccb)
/* Read id from sata */
port = pccb->target;
tmpid = malloc(ATA_ID_WORDS * 2);
-   if (!tmpid)
+   if (!tmpid) {
+   printf("%s: No memory for tmpid\n", __func__);
return -ENOMEM;
+   }
 
if (ahci_device_data_io(port, (u8 *) &fis, sizeof(fis), (u8 *)tmpid,
ATA_ID_WORDS * 2, 0)) {
@@ -889,6 +896,11 @@ int ahci_init(u32 base)
u32 linkmap;
 
probe_ent = malloc(sizeof(struct ahci_probe_ent));
+   if (!probe_ent) {
+   printf("%s: No memory for probe_ent\n", __func__);
+   return -ENOMEM;
+   }
+
memset(probe_ent, 0, sizeof(struct ahci_probe_ent));
 
probe_ent->host_flags = ATA_FLAG_SATA
-- 
1.8.3.2

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

[U-Boot] [PATCH 3/5] ARM: OMAP5: Add PRCM and Control information for SATA

[Roger Quadros]

Adds the necessary PRCM and Control register information for
SATA on OMAP5.

Signed-off-by: Roger Quadros 
---
 arch/arm/cpu/armv7/omap5/prcm-regs.c| 5 +
 arch/arm/include/asm/arch-omap5/clock.h | 3 +++
 arch/arm/include/asm/arch-omap5/omap.h  | 3 +++
 arch/arm/include/asm/omap_common.h  | 3 +++
 4 files changed, 14 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 764620d..78fd7ec 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -203,8 +203,10 @@ struct prcm_regs const omap5_es1_prcm = {
.cm_l3init_hsusbotg_clkctrl = 0x4a009360,
.cm_l3init_hsusbtll_clkctrl = 0x4a009368,
.cm_l3init_p1500_clkctrl = 0x4a009378,
+   .cm_l3init_sata_clkctrl = 0x4a009388,
.cm_l3init_fsusb_clkctrl = 0x4a0093d0,
.cm_l3init_ocp2scp1_clkctrl = 0x4a0093e0,
+   .cm_l3init_ocp2scp3_clkctrl = 0x4a0093e8,
 
/* cm2.l4per */
.cm_l4per_clkstctrl = 0x4a009400,
@@ -295,6 +297,7 @@ struct prcm_regs const omap5_es1_prcm = {
 struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_status = 0x4A002134,
.control_std_fuse_opp_vdd_mpu_2 = 0x4A0021B4,
+   .control_phy_power_sata = 0x4A002374,
.control_padconf_core_base  = 0x4A002800,
.control_paconf_global  = 0x4A002DA0,
.control_paconf_mode= 0x4A002DA4,
@@ -696,8 +699,10 @@ struct prcm_regs const omap5_es2_prcm = {
.cm_l3init_hsusbotg_clkctrl = 0x4a009660,
.cm_l3init_hsusbtll_clkctrl = 0x4a009668,
.cm_l3init_p1500_clkctrl = 0x4a009678,
+   .cm_l3init_sata_clkctrl = 0x4a009688,
.cm_l3init_fsusb_clkctrl = 0x4a0096d0,
.cm_l3init_ocp2scp1_clkctrl = 0x4a0096e0,
+   .cm_l3init_ocp2scp3_clkctrl = 0x4a0096e8,
 
/* prm irqstatus regs */
.prm_irqstatus_mpu_2 = 0x4ae06014,
diff --git a/arch/arm/include/asm/arch-omap5/clock.h 
b/arch/arm/include/asm/arch-omap5/clock.h
index 9a2166c..aa934fb 100644
--- a/arch/arm/include/asm/arch-omap5/clock.h
+++ b/arch/arm/include/asm/arch-omap5/clock.h
@@ -137,6 +137,9 @@
 #define HSMMC_CLKCTRL_CLKSEL_MASK  (1 << 24)
 #define HSMMC_CLKCTRL_CLKSEL_DIV_MASK  (1 << 25)
 
+/* CM_L3INIT_SATA_CLKCTRL */
+#define SATA_CLKCTRL_OPTFCLKEN_MASK(1 << 8)
+
 /* CM_WKUP_GPTIMER1_CLKCTRL */
 #define GPTIMER1_CLKCTRL_CLKSEL_MASK   (1 << 24)
 
diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 414d37a..150db0f 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -64,6 +64,9 @@
 /* QSPI */
 #define QSPI_BASE  0x4B30
 
+/* SATA */
+#define DWC_AHSATA_BASE0x4A14
+
 /*
  * Hardware Register Details
  */
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 3a998cc..cffcb93 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -224,8 +224,10 @@ struct prcm_regs {
u32 cm_l3init_hsusbotg_clkctrl;
u32 cm_l3init_hsusbtll_clkctrl;
u32 cm_l3init_p1500_clkctrl;
+   u32 cm_l3init_sata_clkctrl;
u32 cm_l3init_fsusb_clkctrl;
u32 cm_l3init_ocp2scp1_clkctrl;
+   u32 cm_l3init_ocp2scp3_clkctrl;
 
u32 prm_irqstatus_mpu_2;
 
@@ -361,6 +363,7 @@ struct omap_sys_ctrl_regs {
u32 control_ldosram_mpu_voltage_ctrl;
u32 control_ldosram_core_voltage_ctrl;
u32 control_usbotghs_ctrl;
+   u32 control_phy_power_sata;
u32 control_padconf_core_base;
u32 control_paconf_global;
u32 control_paconf_mode;
-- 
1.8.3.2

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

[U-Boot] [PATCH 5/5] ARM: omap5_uevm: Add SATA support

[Roger Quadros]

The uevm has a SATA port. Inititialize the SATA controller.

Signed-off-by: Roger Quadros 
---
 board/ti/omap5_uevm/evm.c|  7 +++
 include/configs/omap5_uevm.h | 10 ++
 2 files changed, 17 insertions(+)

diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 4706330..86622c3 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DIE_ID_REG_BASE (OMAP54XX_L4_CORE_BASE + 0x2000)
 #define DIE_ID_REG_OFFSET  0x200
@@ -67,6 +68,12 @@ int board_init(void)
return 0;
 }
 
+int board_late_init(void)
+{
+   omap_sata_init();
+   return 0;
+}
+
 int board_eth_init(bd_t *bis)
 {
return 0;
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 4d3a800..2f128b8 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -69,4 +69,14 @@
 /* Max time to hold reset on this board, see doc/README.omap-reset-time */
 #define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC   16296
 
+#define CONFIG_BOARD_LATE_INIT
+#define CONFIG_CMD_SCSI
+#define CONFIG_LIBATA
+#define CONFIG_SCSI_AHCI
+#define CONFIG_SCSI_AHCI_PLAT
+#define CONFIG_SYS_SCSI_MAX_SCSI_ID1
+#define CONFIG_SYS_SCSI_MAX_LUN1
+#define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \
+   CONFIG_SYS_SCSI_MAX_LUN)
+
 #endif /* __CONFIG_OMAP5_EVM_H */
-- 
1.8.3.2

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

[U-Boot] Pull request: u-boot-coldfire

[Zhengxiong Jin]

Hi Tom,

Please pull from u-boot-coldfire.git, thanks!

The following changes since commit e5a9a4076f1fb9fb9ce53c2aec32422073bbc66a:

  pxe: fix handling of absolute paths (2013-11-04 11:24:22 -0500)

are available in the git repository at:
  git://git.denx.de/u-boot-coldfire.git master

Jens Scharsig (BuS Elektronik) (1):
  coldfire: cpu5282: increase malloc space to fix crash on start u-boot

jason (1):
  ColdFire: fix some typoes for CF platform

 include/configs/M5253DEMO.h  |2 +-
 include/configs/M54455EVB.h  |2 +-
 include/configs/eb_cpu5282.h |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

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

[U-Boot] [PATCH] README: remove wrong config name

[Igor Grinberg]

There is no CONFIG_PCA953X_INFO symbol.
U-Boot uses CONFIG_CMD_PCA953X_INFO instead, which is described in
"Monitor Functions" section and thus no need to be repeated in the
"GPIO Support" section.
Remove the whole line.

Signed-off-by: Igor Grinberg 
---
 README | 1 -
 1 file changed, 1 deletion(-)

diff --git a/README b/README
index 09662a4..d93ae11 100644
--- a/README
+++ b/README
@@ -1027,7 +1027,6 @@ The following options need to be configured:
 
 - GPIO Support:
CONFIG_PCA953X  - use NXP's PCA953X series I2C GPIO
-   CONFIG_PCA953X_INFO - enable pca953x info command
 
The CONFIG_SYS_I2C_PCA953X_WIDTH option specifies a list of
chip-ngpio pairs that tell the PCA953X driver the number of
-- 
1.8.1.5

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

Re: [U-Boot] [PATCH] ARM: imx6: Add Bachmann electronic ot1205 mr board

[Wolfgang Denk]

Dear Christian Gmeiner,

In message <1383742312-10922-1-git-send-email-christian.gmei...@gmail.com> you 
wrote:
> Add basic support for the Bachmann electronic ot1205 board. It
> is powered by an imx6d and will come in different flavours. This
> patch adds support for the mr flavour. It has a front panel with
> some LEDs and some keys.
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  board/bachmann/ot1205/Makefile |9 ++
>  board/bachmann/ot1205/ot1205.c |  236 
> 
>  boards.cfg |1 +
>  include/configs/ot1205.h   |  231 +++
>  4 files changed, 477 insertions(+)
>  create mode 100644 board/bachmann/ot1205/Makefile
>  create mode 100644 board/bachmann/ot1205/ot1205.c
>  create mode 100644 include/configs/ot1205.h

Please run your patch through checkpatch and fix the reported issues.

Thanks.

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
All I ask is a chance to prove that money can't make me happy.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: imx6: Add Bachmann electronic ot1205 mr board

[Eric Nelson]

Hi Christian,

On 11/06/2013 05:51 AM, Christian Gmeiner wrote:

Add basic support for the Bachmann electronic ot1205 board. It
is powered by an imx6d and will come in different flavours. This
patch adds support for the mr flavour. It has a front panel with
some LEDs and some keys.


...

+
+iomux_v3_cfg_t const uart1_pads[] = {
+   MX6_PAD_CSI0_DAT10__UART1_TXD | MUX_PAD_CTRL(UART_PAD_CTRL),
+   MX6_PAD_CSI0_DAT11__UART1_RXD | MUX_PAD_CTRL(UART_PAD_CTRL),
+};
+


Depending on which applies, first, you may need to change the
names of these pad registers as shown in this patch:
http://lists.denx.de/pipermail/u-boot/2013-November/166162.html

Regards,


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

Re: [U-Boot] ARM: interrupt_init before relocation, write fails

[Joe Kulikauskas]

Hi,

Rob, yes that's correct.

To Albert's question: the disassembled instruction I had showed
LDR   R3,ff0a0fc0 is load of r3 with address of the variable holding
the stack address;  "this write" is the str which I've now copied in below.
IRQ_STACK_START_IN = gd->irq_sp + 8;
ff0a0fb0: e5992044 ldr r2, [r9, #68] ; 0x44
ff0a0fb4: e2822008 add r2, r2, #8
ff0a0fb8: e5832000 str r2, [r3]


For my target, IIRC the write to flash caused problem in the flash
controller hardware, breaking further instruction fetches.  On other
platforms the write to flash may fail silently.  But the issue is that
interrupt_init() moving into board_init_f (i.e. before relocation)
generally just doesn't work right.

Joe


On Tue, Nov 5, 2013 at 12:46 PM, Rob Herring  wrote:

> On 11/05/2013 01:17 PM, Albert ARIBAUD wrote:
> > Hi Rob,
> >
> > On Tue, 5 Nov 2013 10:22:24 -0600, Rob Herring 
> > wrote:
> >
> >> On Thu, Oct 24, 2013 at 4:37 PM, Andrew Ruder  wrote:
> >>> On Wed, Oct 23, 2013 at 11:41:45AM -0600, Joe Kulikauskas wrote:
> >
> > (putting back more context)
> >
>  v2013.10-rc1 (and after) has a patch (
>  http://lists.denx.de/pipermail/u-boot/2013-June/156298.html)
>  which sets up the abort stack before relocation. However, what
>  I am seeing: IRQ_STACK_START_IN
>  is in flash at that time, so this write fails.
> >
> > Hmm... Which one exactly is "this write"? The instructions below are
> > reads, not writes.
> >
>  interrupt_init:
>  FF0A0FA8 e59f3010   LDR   R3,ff0a0fc0
>  (ff0a0050=IRQ_STACK_START_IN)
> >>>
>  Before this patch, abort stack setup was done after relocation, so
>  target location is in RAM and writeable.
> >>>
>  interrupt_init:
>  9FFB4020 e59f3010   LDR   R3,9ffb4038
>  (9ffb3054=IRQ_STACK_START_IN)
> >>>
>  If I revert that patch, I don't see that problem.
> >
> > That problem only happens when there actually is an abort before
> > relocation, right?
>
> Not as I understand it. The address here is the address of the variable
> holding the stack address. So we are trying to write the stack address
> to flash which I guess does more that just get ignored.
>
> Rob
>
> >
> >>> FWIW, I am working on a PXA270 target, and have had to revert this
> patch
> >>> as well.  I hadn't gotten around to tracking down where and why I was
> >>> crashing though so hadn't emailed in a bug report yet.  Now seeing as
> >>> there's someone else now seeing it too I thought I would chime in with
> >>> a "me too".
> >>>
> >>> Rob: CC'd you since you were the author and might have some insight.
> >>> Full email in entirety below.
> >>
> >> Other than doing stack setup in a completely different way by setting
> >> the mode in the CPSR and setting up SP_irq and SP_abt directly, I
> >> don't see an easy fix. So we should revert this change. It works for
> >> me because I run from RAM before relocation.
> >>
> >> Albert or Tom, can you please revert commit 0f5141e9c57e96de11642a.
> >
> > I'm ok with reverting in the ARM repo (I'll PR to mainline after I get
> > Atmel and IMX in), as soon as I get a clear understanding of the exact
> > issue.
> >
> >> Rob
> >
> > Amicalement,
> >
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM

[Vaibhav Bedia]

On Wed, Nov 6, 2013 at 8:25 AM, Lokesh Vutla  wrote:
> On Wednesday 06 November 2013 06:08 PM, Vaibhav Bedia wrote:
>> On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
>>> From: Sekhar Nori 
>>>
>>> Add support for reading onboard EEPROM to enable
>>> board detection.
>>>
>>> Signed-off-by: Sekhar Nori 
>>> Signed-off-by: Lokesh Vutla 
>>> ---
>>>  arch/arm/include/asm/arch-am33xx/omap.h |2 ++
>>>  board/ti/am43xx/board.c |   46 
>>> +++
>>>  board/ti/am43xx/board.h |   32 +
>>>  include/configs/am43xx_evm.h|7 +
>>>  4 files changed, 87 insertions(+)
>>>
>>> diff --git a/arch/arm/include/asm/arch-am33xx/omap.h 
>>> b/arch/arm/include/asm/arch-am33xx/omap.h
>>> index 2250721..10f05c9 100644
>>> --- a/arch/arm/include/asm/arch-am33xx/omap.h
>>> +++ b/arch/arm/include/asm/arch-am33xx/omap.h
>>> @@ -27,5 +27,7 @@
>>>  #define NON_SECURE_SRAM_START  0x402F0400
>>>  #define NON_SECURE_SRAM_END0x4034
>>>  #define SRAM_SCRATCH_SPACE_ADDR0x4033C000
>>> +#define AM4372_BOARD_NAME_STARTSRAM_SCRATCH_SPACE_ADDR
>>> +#define AM4372_BOARD_NAME_END  SRAM_SCRATCH_SPACE_ADDR + 0xC
>>>  #endif
>>>  #endif
>>> diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
>>> index dcd8cbb..4fc1a40 100644
>>> --- a/board/ti/am43xx/board.c
>>> +++ b/board/ti/am43xx/board.c
>>> @@ -9,6 +9,8 @@
>>>   */
>>>
>>>  #include 
>>> +#include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -17,6 +19,50 @@
>>>
>>>  DECLARE_GLOBAL_DATA_PTR;
>>>
>>> +/*
>>> + * Read header information from EEPROM into global structure.
>>> + */
>>> +static int read_eeprom(struct am43xx_board_id *header)
>>> +{
>>> +   /* Check if baseboard eeprom is available */
>>> +   if (i2c_probe(CONFIG_SYS_I2C_EEPROM_ADDR)) {
>>> +   printf("Could not probe the EEPROM at 0x%x\n",
>>> +  CONFIG_SYS_I2C_EEPROM_ADDR);
>>> +   return -ENODEV;
>>> +   }
>>> +
>>> +   /* read the eeprom using i2c */
>>> +   if (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0, 2, (uchar *)header,
>>> +sizeof(struct am43xx_board_id))) {
>>> +   printf("Could not read the EEPROM\n");
>>> +   return -EIO;
>>> +   }
>>> +
>>> +   if (header->magic != 0xEE3355AA) {
>>
>> Why is the header the same as AM335x? Shouldn't it be something
>> like 0xEE3344AA or whatever?
> No, the header is still same. It is 0xEE3355AA.
>

My question was why ;)
What's the point of adding the same magic value for a different SoC?
Unless there's a good reason for doing so i think this needs to be fixed
in the EEPROM programmer.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 09/14] ARM: AM43xx: mux: Update mux data

[Vaibhav Bedia]

On Wed, Nov 6, 2013 at 8:32 AM, Lokesh Vutla  wrote:
> On Wednesday 06 November 2013 06:13 PM, Vaibhav Bedia wrote:
>> On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
>>> Updating the mux data for UART, and adding data for i2c0 and mmc.
>>>
>>> Signed-off-by: Lokesh Vutla 
>>> ---
>>>  arch/arm/include/asm/arch-am33xx/mux_am43xx.h |4 +++-
>>>  board/ti/am43xx/mux.c |   24 
>>> ++--
>>>  2 files changed, 25 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h 
>>> b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
>>> index 0206912..e95efdd 100644
>>> --- a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
>>> +++ b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
>>> @@ -16,7 +16,9 @@
>>> __raw_writel(value, (CTRL_BASE + offset));
>>>
>>>  /* PAD Control Fields */
>>> -#define SLEWCTRL   (0x1 << 19)
>>> +#define DSPULLUDEN (0x1 << 27) /* DS0 mode Pull-Up/Down enable */
>>> +#define DSPULLUDDIS(0x0 << 27) /* DS0 mode Pull-Up/Down Disable */
>>> +#define SLEWCTRL   (0x1 << 19) /* Slow slew rate selection */
>>>  #define RXACTIVE   (0x1 << 18)
>>>  #define PULLDOWN_EN(0x0 << 17) /* Pull Down Selection */
>>>  #define PULLUP_EN  (0x1 << 17) /* Pull Up Selection */
>>> diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
>>> index 700e9a7..818a046 100644
>>> --- a/board/ti/am43xx/mux.c
>>> +++ b/board/ti/am43xx/mux.c
>>> @@ -12,8 +12,26 @@
>>>  #include "board.h"
>>>
>>>  static struct module_pin_mux uart0_pin_mux[] = {
>>> -   {OFFSET(uart0_rxd), (MODE(0) | RXACTIVE)},  /* UART0_RXD */
>>> -   {OFFSET(uart0_txd), (MODE(0))}, /* UART0_TXD */
>>> +   {OFFSET(uart0_rxd),
>>> +(MODE(0) | PULLUP_EN | RXACTIVE | SLEWCTRL | DSPULLUDEN)},
>>> +   {OFFSET(uart0_txd),
>>> +(MODE(0) | PULLUDDIS | PULLUP_EN | SLEWCTRL | DSPULLUDEN)},
>>> +   {-1},
>>> +};
>>> +
>>> +static struct module_pin_mux mmc0_pin_mux[] = {
>>> +   {OFFSET(mmc0_clk), (MODE(0) | PULLUDDIS | RXACTIVE | DSPULLUDEN)},
>>> +   {OFFSET(mmc0_cmd), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
>>> +   {OFFSET(mmc0_dat0), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
>>> +   {OFFSET(mmc0_dat1), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
>>> +   {OFFSET(mmc0_dat2), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
>>> +   {OFFSET(mmc0_dat3), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
>>> +   {-1},
>>
>> Hmm i don't think updating the DSPULL here is a good idea. Since not
>> all the pins
>> are used in U-Boot, this is just partially updating the pulls for the
>> low power state.
>> I would suggest leaving this bit for the kernel where things can be
>> updated without
>> updating the bootloader.
> These are the preferred settings given to me.
> Any way if kernel is updating it overwrites these settings, it shouldn't 
> matter I guess..:)
>
It's better to clearly list down what configuration a particular
entity in the system is
responsible for. Doing partial updates her just makes issues harder to debug.

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

Re: [U-Boot] [PATCH 12/14] ARM: AM43xx: EPOS_EVM: Add support for LPDDR2

[Vaibhav Bedia]

On Wed, Nov 6, 2013 at 8:45 AM, Lokesh Vutla  wrote:
> On Wednesday 06 November 2013 06:27 PM, Vaibhav Bedia wrote:
>> On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
>>> AM4372 EPOS EVM has 1GB LPDDR2(Part no: MT42L256M32D2LG-25 WT:A)
>>> Adding LPDDR2 init sequence and register details for the same.
>>> Below is the brief description of LPDDR2 init sequence:
>>> -> Configure VTP
>>> -> Configure DDR IO settings
>>> -> Disable initialization and refreshes until EMIF registers are programmed.
>>> -> Program Timing registers
>>> -> Program PHY control and Temp alert and ZQ config registers.
>>> -> Enable initialization and refreshes and configure SDRAM CONFIG register
>>> -> Wait till initialization is complete and the configure MR registers.
>>>
>>
>> Is there any public documentation to go with this?
>> I would suggest sprinkling the code with comments
>> to mention the different stages.
> Yep ll add the comments in the code..
>>
>> BTW, no IO powerdown setting for now?
> You mean DDR IO settings?

Yeah. I assume you have configured the dynamic power down bit properly.
Can't tell without looking at the TRM.

>>
>> [...]
>>>
>>> +ifeq ($(CONFIG_AM43XX),)
>>> +COBJS  += ddr.o
>>> +COBJS  += emif4.o
>>> +endif
>>> +COBJS-$(CONFIG_AM43XX) += emif4d5.o
>>> +
>>
>> Are the steps really different enough to warrant a new file? Can't the 
>> changes
>> be handled properly in the code? How has this been handled in OMAPx where
>> DDR3 and LPDDR both are supported?
> Initially Tom also suggested not to use a new file. I tried with not to add a 
> new file,
> but I ended up with many #ifdefs. EMIF is new IP(reused from OMAP5) very 
> different from AM33xx EMIF IP.
> So to make things more cleaner I had to use a new file..
>

It really looks a step backward. The new IP should be an update to the old
version and not just a complete overhaul of the programming model that folks
are familiar with.

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

Re: [U-Boot] [PATCH 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3

[Vaibhav Bedia]

On Wed, Nov 6, 2013 at 8:54 AM, Lokesh Vutla  wrote:
> On Wednesday 06 November 2013 06:32 PM, Vaibhav Bedia wrote:
>> On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
>>> GP EVM has 1GB DDR3 attached(Part no: MT47H128M16RT-187E:C).
>>> Adding details for the same.
>>> Below is the brief description of DDR3 init sequence(SW leveling):
>>> -> Enable VTT regulator
>>> -> Configure VTP
>>> -> Configure DDR IO settings
>>> -> Disable initialization and refreshes until EMIF registers are programmed.
>>> -> Program Timing registers
>>> -> Program leveling registers
>>> -> Program PHY control and Temp alert and ZQ config registers.
>>
>> Temp alert? Is that really relevant here?
> Yes, Need to configure all the emif registers before accessing SDRAM.

Ok. What's done on an AM437x system when the temp goes beyond a threshold?

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

Re: [U-Boot] [PATCH] ARM: imx6: Add Bachmann electronic ot1205 mr board

[Stefano Babic]

Hi Christian,

On 06/11/2013 13:51, Christian Gmeiner wrote:
> Add basic support for the Bachmann electronic ot1205 board. It
> is powered by an imx6d and will come in different flavours. This
> patch adds support for the mr flavour. It has a front panel with
> some LEDs and some keys.

Maybe it helps if you add here a short list of peripheral that are
supported. From code, I see at least SDHC and ethernet.

> diff --git a/board/bachmann/ot1205/ot1205.c b/board/bachmann/ot1205/ot1205.c
> new file mode 100644
> index 000..37c6159
> --- /dev/null
> +++ b/board/bachmann/ot1205/ot1205.c
> @@ -0,0 +1,236 @@
> +/*
> + * Copyright (C) 2010-2013 Freescale Semiconductor, Inc.
> + * Copyright (C) 2013, Bachmann electronic GmbH
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define UART_PAD_CTRL  (PAD_CTL_PUS_100K_UP |\
> + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
> + PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
> +
> +#define USDHC_PAD_CTRL (PAD_CTL_PUS_47K_UP | \
> + PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \
> + PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
> +
> +#define ENET_PAD_CTRL  (PAD_CTL_PUS_100K_UP |\
> + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
> +
> +#define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED |  \
> + PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
> +
> +#define I2C_PAD_CTRL (PAD_CTL_PUS_100K_UP |  \
> + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS |   \
> + PAD_CTL_ODE | PAD_CTL_SRE_FAST)
> +
> +#define OUTPUT_40OHM (PAD_CTL_SPEED_MED|PAD_CTL_DSE_40ohm)
> +
> +int dram_init(void)
> +{
> + gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
> +
> + return 0;
> +}
> +
> +iomux_v3_cfg_t const uart1_pads[] = {
> + MX6_PAD_CSI0_DAT10__UART1_TXD | MUX_PAD_CTRL(UART_PAD_CTRL),
> + MX6_PAD_CSI0_DAT11__UART1_RXD | MUX_PAD_CTRL(UART_PAD_CTRL),
> +};
> +
> +
> +static void setup_iomux_uart(void)
> +{
> + imx_iomux_v3_setup_multiple_pads(uart1_pads,
> + ARRAY_SIZE(uart1_pads));
> +}
> +
> +int board_early_init_f(void)
> +{
> + setup_iomux_uart();
> +
> + return 0;
> +}
> +
> +iomux_v3_cfg_t const ecspi1_pads[] = {
> + MX6_PAD_DISP0_DAT3__ECSPI3_SS0  | MUX_PAD_CTRL(SPI_PAD_CTRL),
> + MX6_PAD_DISP0_DAT4__ECSPI3_SS1  | MUX_PAD_CTRL(SPI_PAD_CTRL),
> + MX6_PAD_DISP0_DAT2__ECSPI3_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
> + MX6_PAD_DISP0_DAT1__ECSPI3_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
> + MX6_PAD_DISP0_DAT0__ECSPI3_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),
> +};
> +
> +void setup_spi(void)
> +{
> + imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
> +  ARRAY_SIZE(ecspi1_pads));
> +}
> +
> +/*
> + * Do not overwrite the console
> + * Use always serial for U-Boot console
> + */
> +int overwrite_console(void)
> +{
> + return 1;
> +}

You do not add video capabilities: you can simply drop  overwrite_console().

> +
> +iomux_v3_cfg_t const usdhc3_pads[] = {
> + MX6_PAD_SD3_CLK__USDHC3_CLK   | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD3_CMD__USDHC3_CMD   | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD3_DAT0__USDHC3_DAT0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD3_DAT1__USDHC3_DAT1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD3_DAT2__USDHC3_DAT2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD3_DAT3__USDHC3_DAT3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD3_DAT4__USDHC3_DAT4 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD3_DAT5__USDHC3_DAT5 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD3_DAT6__USDHC3_DAT6 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD3_DAT7__USDHC3_DAT7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD3_RST__USDHC3_RST | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> +};
> +
> +int board_mmc_getcd(struct mmc *mmc)
> +{
> + // returns -1 to indicate that no card-detection mechanism is 
> implemented;
> + // 0 indicates that no card is present and
> + // 1 is returned if it was detected that a card is present.

As codestyle we do not use C++ comments

> +int board_eth_init(bd_t *bis)
> +{
> + setup_iomux_enet();
> + fecmxc_initialize(bis);
> +
> + return 0;
> +}

There is not special hndling in this board function. You could move
setup_iomux_enet() into board_early_init() to setup the pinmux and drop
this function. It is then responsability of cpu_eth_init() the
initialization of the FEC controller.

> +
> +#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
> +
> +/* I2C2 - EDID */
> +struct i2c_pads_info i2c_pad_info1 = {
> +.scl = {
> +.i2c_mode = M

Re: [U-Boot] [PATCH 1/1] ARM: config: USB: Tegra30/114: Fix EHCI timeout issue on "bootp"

[Stephen Warren]

On 11/05/2013 11:03 PM, Jim Lin wrote:
> Fix the timeout issue after running "bootp" command in u-boot
> console. For example you see "EHCI timed out on TD- token=0x...".
> TXFIFOTHRES bits of TXFILLTUNING register should be set to 0x10
> after a controller reset and before RUN bit is set
> (per technical reference manual).

Tested-by: Stephen Warren 

(I wasn't experiencing any time-out issues myself on those platforms,
but everything certainly still works fine after this patch)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 07/34] zynq: Add UART0, UART1 configs support

[Michal Simek]

On 11/06/2013 02:50 PM, Dinh Nguyen wrote:
> 
> 
> On 11/6/13 12:45 AM, Michal Simek wrote:
>> On 11/06/2013 05:17 AM, Dinh Nguyen wrote:
>>>
>>> On 11/5/13 11:46 AM, Jagannadha Sutradharudu Teki wrote:
 Zynq uart controller support two serial ports like
 CONFIG_ZYNQ_SERIAL_UART0 and CONFIG_ZYNQ_SERIAL_UART1
 enabled both so-that the respective board will define
 these macros based on their usage.

 Signed-off-by: Jagannadha Sutradharudu Teki 
 ---
  include/configs/zynq.h | 20 
  1 file changed, 16 insertions(+), 4 deletions(-)

 diff --git a/include/configs/zynq.h b/include/configs/zynq.h
 index f32008b..1bcb28d 100644
 --- a/include/configs/zynq.h
 +++ b/include/configs/zynq.h
 @@ -33,10 +33,22 @@
  {300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200,
> 230400}

  /* Zynq Serial driver */
 -#define CONFIG_ZYNQ_SERIAL
 -#define CONFIG_ZYNQ_SERIAL_BASEADDR00xE0001000
 -#define CONFIG_ZYNQ_SERIAL_BAUDRATE0CONFIG_BAUDRATE
 -#define CONFIG_ZYNQ_SERIAL_CLOCK05000
 +#define CONFIG_ZYNQ_SERIAL_UART1
 +#ifdef CONFIG_ZYNQ_SERIAL_UART0
 +# define CONFIG_ZYNQ_SERIAL_BASEADDR00xE000
 +# define CONFIG_ZYNQ_SERIAL_BAUDRATE0CONFIG_BAUDRATE
>>> Why couldn't you just use CONFIG_BAUDRATE? Why do you need to add
>>> another define?
> 
>> If we start to use the same CONFIG_BAUDRATE(or better gd->baudrate)
>> in the driver then we lose config options to setup different baudrate
>> for every single device.
> 
>> I haven't seen any code for SERIAL_MULTI if you want to configure
>> 2 serial drivers but on different baudrate.
>> If there is better way how to do it please let us know.
> I guess the question then is what would be the use case for supporting
> different baudrates on different device?

I don't have any particular case in my mind but based on my experience
with various customer they could have intention to replace old subsystem
by fpga and one serial console can go to standard output which is logged
by default and different serial output for debug purpose and both
can run on different baudrates.

I just think that with SERIAL_MULTI support various baudrate should be supported
and doing it through macros is one way to go.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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

Re: [U-Boot] [PATCH] ARM: imx6: Add Bachmann electronic ot1205 mr board

[Fabio Estevam]

On Wed, Nov 6, 2013 at 10:51 AM, Christian Gmeiner
 wrote:

> +int dram_init(void)
> +{
> +   gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
> +
> +   return 0;
> +}
> +
> +iomux_v3_cfg_t const uart1_pads[] = {

You can make it static.

> +int board_early_init_f(void)
> +{
> +   setup_iomux_uart();
> +
> +   return 0;
> +}
> +
> +iomux_v3_cfg_t const ecspi1_pads[] = {

Ditto.

> +/*
> + * Do not overwrite the console
> + * Use always serial for U-Boot console
> + */
> +int overwrite_console(void)
> +{
> +   return 1;
> +}

This can be removed.

> +iomux_v3_cfg_t const usdhc3_pads[] = {

static

> +int board_mmc_getcd(struct mmc *mmc)
> +{
> +   // returns -1 to indicate that no card-detection mechanism is 
> implemented;
> +   // 0 indicates that no card is present and
> +   // 1 is returned if it was detected that a card is present.
> +   return 1;

No // style comments.

> +int board_mmc_init(bd_t *bis)
> +{
> +   s32 status = 0;
> +
> +   usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
> +   usdhc_cfg[0].max_bus_width = 8;
> +
> +   imx_iomux_v3_setup_multiple_pads(
> +   usdhc3_pads, ARRAY_SIZE(usdhc3_pads));
> +
> +   status |= fsl_esdhc_initialize(bis, &usdhc_cfg[0]);
> +
> +   return status;

You can get rid of the status variable and just do:

return fsl_esdhc_initialize(bis, &usdhc_cfg[0]);


> +}
> +
> +iomux_v3_cfg_t const enet_pads[] = {

static

> +/* I2C2 - EDID */
> +struct i2c_pads_info i2c_pad_info1 = {

static

> +.scl = {
> +.i2c_mode = MX6_PAD_EIM_EB2__I2C2_SCL | PC,
> +.gpio_mode = MX6_PAD_EIM_EB2__GPIO_2_30 | PC,
> +.gp = IMX_GPIO_NR(2, 30)
> +},
> +.sda = {
> +.i2c_mode = MX6_PAD_EIM_D16__I2C2_SDA | PC,
> +.gpio_mode = MX6_PAD_EIM_D16__GPIO_3_16 | PC,
> +.gp = IMX_GPIO_NR(3, 16)
> +}
> +};
> +
> +/* I2C3 - keys, led, temp sensor */
> +struct i2c_pads_info i2c_pad_info2 = {

static

> +   .scl = {
> +   .i2c_mode = MX6_PAD_EIM_D17__I2C3_SCL | PC,
> +   .gpio_mode = MX6_PAD_EIM_D17__GPIO_3_17 | PC,
> +   .gp = IMX_GPIO_NR(3, 17)
> +   },
> +   .sda = {
> +   .i2c_mode = MX6_PAD_EIM_D18__I2C3_SDA | PC,
> +   .gpio_mode = MX6_PAD_EIM_D18__GPIO_3_18 | PC,
> +   .gp = IMX_GPIO_NR(3, 18)
> +   }
> +};
> +
> +iomux_v3_cfg_t const pwm_pad[] = {

static

> +++ b/include/configs/ot1205.h
> @@ -0,0 +1,231 @@
> +/*
> + * Copyright (C) 2010-2013 Freescale Semiconductor, Inc.
> + * Copyright (C) 2013, Bachmann electronic GmbH
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#ifndef __CONFIG_H
> +#define __CONFIG_H
> +
> +#define CONFIG_MX6
> +#define CONFIG_MX6Q

If you pass the mx6 version in boards.cfg, then it will make things
easier when you add support for the other board variants you have.

> +#define CONFIG_DISPLAY_CPUINFO
> +#define CONFIG_DISPLAY_BOARDINFO
> +
> +#include 
> +#include 
> +
> +#define CONFIG_CMDLINE_TAG
> +#define CONFIG_SETUP_MEMORY_TAGS
> +#define CONFIG_INITRD_TAG
> +#define CONFIG_REVISION_TAG
> +
> +/* Size of malloc() pool */
> +#define CONFIG_SYS_MALLOC_LEN   (10 * 1024 * 1024)

If you do not have video support you can use a smaller region, such as 2MB.

> +/* OCOTP Configs */
> +#define CONFIG_CMD_IMXOTP
> +#ifdef CONFIG_CMD_IMXOTP
> +#define CONFIG_IMX_OTP
> +#define IMX_OTP_BASEOCOTP_BASE_ADDR
> +#define IMX_OTP_ADDR_MAX0x7F
> +#define IMX_OTP_DATA_ERROR_VAL  0xBADABADA

Why do you need this? Not used anywehere.

Regards,

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

Re: [U-Boot] [PATCH v8 0/5] mtd: nand: omap: optimize and clean-up of OMAP NAND driver

[Gupta, Pekon]

Hi Matti and Matthias

Sorry I was away from my mailbox so couldn't reply you earlier.
I'm still away from my setup and other boards, so cannot replicate
the issue below until early next week. But I'll surely do so asap..

However, please see my replies below, which might help you someway.


> From: matti kaasinen [mailto:matti.kaasi...@gmail.com] 
> Hi Pekon,
> Thanks to Tom Rini's hint I have tried to execute your patch sets
> (http://patchwork.ozlabs.org/project/uboot/list/?submitter=17320&state=*)
>  in order to get Linux and U-Boot working with same NAND flash.
> Set-up is pretty much like Mathias has before in this chain.
> Latest problem I faced with is that last versions of
>  1)  "[U-Boot,v8,3/5] mtd: nand: omap: optimize chip->ecc.calculate() for H/W 
> ECC schemes"
>  and 2) "[U-Boot,v2,2/3] mtd: nand: omap: add support for BCH16_ECC - NAND 
> driver updates"
> are not compatible any more. As I told in
> https://groups.google.com/forum/#!topic/beagleboard/7ofbE_Rrn_s
> versions v5..v7 of 1) could possibly be compatible. 

There is no change in ECC layout or other functional updates between
v7 and v8 of this patch, so if there is any incompatibility then it would
be in all versions of the patch..
Few questions.. 
(1) Which ECC scheme are you using ?
- u-boot 
CONFIG_NAND_OMAP_ECCSCHEME as per doc/README.nand
http://lists.denx.de/pipermail/u-boot/2013-October/164646.html
- kernel
OMAP_ECC_BCH8_CODE_HW
OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
Or any other..


(2) Is the problem related to incorrect read/write access to x16 NAND ?
Or 
Is it incompatibility in ecc.layout ?
You can check this by dumping raw nand page via 'nand dump' command
from both u-boot and kernel.


(3) you should not pick BCH16 patch-series
- because I have not rebased this patch, and re-tested since other
   base patch-series on which BCH16 will be build, is still not accepted.
- Also BCH16 ecc scheme would work only for 
   NAND device with pagesize=4K and oobsize=224.
   whereas current beaglebone capes have
   NAND device with pagesize=2K and oobsize=64, so you can only use
   BCH8 with current NAND capes (for now)..



> > 2013/11/1 Matthias Fuchs 
> > Hi Pekon,
> >
> > should I consider the U-Boot and Linux am335x NAND
> > implementation to be compatible? So are the ECC schemes
> > in a way identical that I can nandwrite a kernel image from
> > Linux and "nand read" it from U-Boot? I tested with the 3.8.13
> > beaglebone kernel (which is of course not very representative)
> >  and it does not work. If it should work, do you know it that was
> > already the case before your patches and with which Linux kernel?

I don't think any earlier kernel versions ever supported beaglebone
Its only recently that a major patch-series of NAND driver was
accepted and  tested on beaglebone.
The patches  are currently in l2-mtd.git tree which should make into
3.13 kernel, before being in linux-next for sometime.
(a) Reference: 
http://lists.infradead.org/pipermail/linux-mtd/2013-October/049462.html

(b) In addition to above series, you might need beaglebone DTS updates
which you can refer from below ..
http://lists.infradead.org/pipermail/linux-mtd/2013-October/049438.html


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

Re: [U-Boot] [PATCH 12/14] ARM: AM43xx: EPOS_EVM: Add support for LPDDR2

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/06/2013 11:44 AM, Vaibhav Bedia wrote:
> On Wed, Nov 6, 2013 at 8:45 AM, Lokesh Vutla 
> wrote:
>> On Wednesday 06 November 2013 06:27 PM, Vaibhav Bedia wrote:
[snip]
>>> Are the steps really different enough to warrant a new file?
>>> Can't the changes be handled properly in the code? How has this
>>> been handled in OMAPx where DDR3 and LPDDR both are supported?
>> Initially Tom also suggested not to use a new file. I tried with
>> not to add a new file, but I ended up with many #ifdefs. EMIF is
>> new IP(reused from OMAP5) very different from AM33xx EMIF IP. So
>> to make things more cleaner I had to use a new file..
>> 
> 
> It really looks a step backward. The new IP should be an update to
> the old version and not just a complete overhaul of the programming
> model that folks are familiar with.

It sounds like we need to re-think the EMIF code here since it's not
all THAT different between the OMAP parts, the am33xx parts, the
am43xx parts and the ti81xx parts (and even the am35xx parts, but I'm
OK setting that aside).

And no, I'm not 100% happy with the OMAP code either, but that's
mainly the bits where we say OMAP rev FOO means memory chip BAR.

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

iQIcBAEBAgAGBQJSerQdAAoJENk4IS6UOR1WD9QP/jhANTw5BKPyxtHFjGHymSUL
+d4jJ5VwvCsWYLOv/zQ961EtWn3FGedNxiqFjTI2ZUQk9Xge9zycp0ZaHscBybJF
65A+RqUBEJ+jBVdtV7oT/zHq8KLsE4m9yYV9qU8L5bHLbzATulX7mG2waRB+lZcZ
Qz/nFKYQ0cyvW92JAUbf2/Iza4GxIAQ0ZIjJdcEE86VBVJD0E+udVJZtP7RdryMg
usyuxaQOBxM5I9XTCuuV6K1ZFGGOWEOebhfKEegH5MTjn7/apQXY0ufP4u7+IJGl
Ss1vDwTEUQ8qNIZwbGoiiA24wE0E8Ou8Vtn29KNpiWWt0pTYR/VUaGJHK0CdhHEd
MlKlIsmjbpXfLAhm3oCeoPSRJLUcb7QXHyJvhjMmMOxVs7FCvy3H2LRogcXk+I/c
SO5wn7JvlSj12VhGgmc4IYw9I8wqLHxUP9tMVNC5V3D5yVZTOl3YjJGql35hkZmR
mWGIUEqGs4uwD1P4hEonUPFFpn9bNGZLBdFpk9ytuS58ZHGD09WEFqWy8aqKHNC0
2TlPUl3T/YK6jk8PZyz962jwX8ropKKWsOZ2mGBB9ix5OHCeMzF22QYmd7d9dD3B
tt9blk1w817QeWiglMc2ErT2tWIMhlAR+0+3RkVKrBOda8pkBEyRp32uV6Pb7lks
gcky1J0tdq6ViMYX3Pt/
=KnCE
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/06/2013 11:39 AM, Vaibhav Bedia wrote:
> On Wed, Nov 6, 2013 at 8:25 AM, Lokesh Vutla  wrote:
>> On Wednesday 06 November 2013 06:08 PM, Vaibhav Bedia wrote:
>>> On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla  wrote:
 From: Sekhar Nori 

 Add support for reading onboard EEPROM to enable
 board detection.

 Signed-off-by: Sekhar Nori 
 Signed-off-by: Lokesh Vutla 
 ---
  arch/arm/include/asm/arch-am33xx/omap.h |2 ++
  board/ti/am43xx/board.c |   46 
 +++
  board/ti/am43xx/board.h |   32 +
  include/configs/am43xx_evm.h|7 +
  4 files changed, 87 insertions(+)

 diff --git a/arch/arm/include/asm/arch-am33xx/omap.h 
 b/arch/arm/include/asm/arch-am33xx/omap.h
 index 2250721..10f05c9 100644
 --- a/arch/arm/include/asm/arch-am33xx/omap.h
 +++ b/arch/arm/include/asm/arch-am33xx/omap.h
 @@ -27,5 +27,7 @@
  #define NON_SECURE_SRAM_START  0x402F0400
  #define NON_SECURE_SRAM_END0x4034
  #define SRAM_SCRATCH_SPACE_ADDR0x4033C000
 +#define AM4372_BOARD_NAME_STARTSRAM_SCRATCH_SPACE_ADDR
 +#define AM4372_BOARD_NAME_END  SRAM_SCRATCH_SPACE_ADDR + 0xC
  #endif
  #endif
 diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
 index dcd8cbb..4fc1a40 100644
 --- a/board/ti/am43xx/board.c
 +++ b/board/ti/am43xx/board.c
 @@ -9,6 +9,8 @@
   */

  #include 
 +#include 
 +#include 
  #include 
  #include 
  #include 
 @@ -17,6 +19,50 @@

  DECLARE_GLOBAL_DATA_PTR;

 +/*
 + * Read header information from EEPROM into global structure.
 + */
 +static int read_eeprom(struct am43xx_board_id *header)
 +{
 +   /* Check if baseboard eeprom is available */
 +   if (i2c_probe(CONFIG_SYS_I2C_EEPROM_ADDR)) {
 +   printf("Could not probe the EEPROM at 0x%x\n",
 +  CONFIG_SYS_I2C_EEPROM_ADDR);
 +   return -ENODEV;
 +   }
 +
 +   /* read the eeprom using i2c */
 +   if (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0, 2, (uchar *)header,
 +sizeof(struct am43xx_board_id))) {
 +   printf("Could not read the EEPROM\n");
 +   return -EIO;
 +   }
 +
 +   if (header->magic != 0xEE3355AA) {
>>>
>>> Why is the header the same as AM335x? Shouldn't it be something
>>> like 0xEE3344AA or whatever?
>> No, the header is still same. It is 0xEE3355AA.
>>
> 
> My question was why ;)
> What's the point of adding the same magic value for a different SoC?
> Unless there's a good reason for doing so i think this needs to be fixed
> in the EEPROM programmer.

A magic value is sufficiently magical, I don't think we'll get anyone to
change it at this point.

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

iQIcBAEBAgAGBQJSeraOAAoJENk4IS6UOR1W/JgP/jShfGcdKDNKJ8EcwAgdy+iU
uFlC02b3f/I4cx7B4s0W3GWJVfHAlPlddSevzSE+I81/f+XRVy9w9Aso3J5hvD3e
XJ/deA5xSpKMV4kZjhE0mOO62iemH4r5ewiM1WFbzUUoWIa1Jf+C8pjygvac5UJb
DCIE40VigasMjl/bJbMOyZPKbrRbHIh+N7fFZNbo+WUp76ZM2dv0S1JWRaY/Zhpq
08wplMmlONGrOkRQmbVYTp2SPrSiYkxq98cIjyzqrzW2pAPDpWP9z7T5hlfI5iWz
It9AENzEkJhmzHTt2P6wq4R9z+giAGweRlFe08tB4lIawX5MaNYOU6TilZee7uf2
PbE5QP2ZXpXCH2Yme59syev/PVqrI02Z8zmZAvvUYQslkEXiXN4mCgWhGXVmZePE
+o+O2bACVAbaRANUZv4vosrPkFI5ooBCn9DR7ME7lZu93nIziMk+xRnzmYacSdQK
k2+GSQSmJ4zd0NCDNaYQ0Svhd3KY6jLZ/RaaYjN4ylNiEkNv8Skk+Vz8l4R8bctY
VZPJeZI/slNH4LfMV6pDuWjmVirJwrj8CmbrpBbWuILjcFjmwvDXt9mGZDlari9z
kK5s4TsAib29bGOPJIjBedmTLuQbaOy6GFppAYQCU063z+n/Jzsyp1ICQGtA5b6P
0PE9WmzQtC7+X15bIL5d
=l8oP
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] ARM: OMAP5: Add Pipe3 PHY driver

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/06/2013 09:47 AM, Roger Quadros wrote:
> Pipe3 PHY is used by SATA, USB3 and PCIe modules. This is
> a driver for the Pipe3 PHY.
> 
> Signed-off-by: Roger Quadros 
[snip]
> +#define perror(fmt, args...) printf("%s: " fmt, __func__ , ##args)

Please use the debug macro.

[snip[
> + perror("%s: No DPLL configuration for %u Hz SYS CLK\n",
> + __func__, rate);

Indent is wrong, we do like the kernel (and checkpatch.pl is in tools/
and will catch these).  Thanks.

Code itself seems fine tho, thanks.

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

iQIcBAEBAgAGBQJSerkvAAoJENk4IS6UOR1WoscQAJPuEI2msKOndDsaVdQcD8oQ
zy2H6hXl4o9FwZd9B6Q3xigjUcjJ9a/g8dBxEprB96pv+8s52R5QUfvP88kFrAJ7
Nq/Yb0EeHVNmsQoOAaFrmeYd6iJ+XFJv93G0bD1cSVTPoynnIl0kyeicN8rf2lNV
ZbU8qdxyYwxK3BaBMyh+jarCx+glXmDuQgcRMJ8t7KWOKKvOpiVzpksoZvoSucrN
gIKfxyPbvUSEFwx95oN0VfAvAhOzrnHF1ghp7CSnatVWuqGWpseqqIC0oosRe1ob
GFUOxWYK3jUIwE8KYgbcHl0Zie7jEWegYOlkOxurivRZS8AcOoi9IycJlTGGO/vX
REgdHSKm6O5NxHBW6X6rBrL44YuR0WnVKmBLVeGcGxqSfpgkXRG+6Pa8XBSmYDgU
k26tb2JXSkpUwMRu9omKn96nbaWAAo3IUnB/ErWuPjvhADRZcERYH1UdNnSY3BvW
PsgeUEL7j67/s9EHShwtPLBRN22CJVgefnV1oxBgK7I1IZkgiUS3EVN53Z/edFTw
XKR+sN8SRM9pAV4DzGVElK5njdoy11ez9Xc1cG7lenLJJv1MTCo1NVqG136NvldS
OURc8Hp0G92OBGUBts5gDDeJTgn1fEnfSizZZ9JJP8B2I7WXV41rzGvswHR12tgE
EP0V6CqWSWjeOoj9DFhS
=tTZq
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/5] ARM: OMAP5: Add SATA platform glue

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/06/2013 09:47 AM, Roger Quadros wrote:
> Add platform glue logic for the SATA controller.
> 
> Signed-off-by: Roger Quadros 
[snip]
> diff --git a/arch/arm/cpu/armv7/omap-common/Makefile 
> b/arch/arm/cpu/armv7/omap-common/Makefile
> index 6e4a0f0..0535b62 100644
> --- a/arch/arm/cpu/armv7/omap-common/Makefile
> +++ b/arch/arm/cpu/armv7/omap-common/Makefile
> @@ -23,6 +23,9 @@ endif
>  
>  ifneq ($(CONFIG_OMAP54XX),)
>  COBJS+= pipe3-phy.o
> +ifdef CONFIG_SCSI_AHCI_PLAT
> +COBJS+= sata.o
> +endif

This should be:
COBJS-$(CONFIG_SCSI_AHCI_PLAT) += sata.o, or obj-... with the recent changes.

>  endif
>  
>  ifeq ($(CONFIG_OMAP34XX),)
> diff --git a/arch/arm/cpu/armv7/omap-common/sata.c 
> b/arch/arm/cpu/armv7/omap-common/sata.c
> new file mode 100644
> index 000..eb079c3
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/omap-common/sata.c
[snip]
> +#if defined(CONFIG_SCSI_AHCI_PLAT)

The file already depends on this symbol to be built at all.

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

iQIcBAEBAgAGBQJSer6VAAoJENk4IS6UOR1WU9kQAJfE+9wrba5C8Js5hpYdK7Bp
ql3F84xgHTlfj0bkzm/r7EiCvnJDH7GutkSBXsStGPq2HuWhScB1GSU/z2e3+wRU
du5rYC5Ny26wwBOMpcUGVwf35OlI5jQqG53NPYgoHs3cMo7wVE+jMcoxjWvDgEjE
bSdd2XKrJGpN426X0CIs2e9bNRy9ScvYcNlTn2/M4Q8UKoqHa9PxvudA1Qv1ldA5
DPbL27QLz0CbKBHXn/E2OteGYuGRwoIv/0HWTiBfKcnpcz3/9netEmkb98U429bw
rH+74SMF1NgrXaVbVmFwKI7w0IIfN0aI4sFqzIls2Dxk18VHfaf4HMobSg2sK1IP
LFxNu4MPfRGOTsuZquoSJgllgw+xEcALQreZs8VbwyFrd4hfv7tFxtZKMHjFXg59
ar4xMQWFqLA25AawUhG7vmQGgdAKkCDSCzUrk1tMC6Egoklsj9dAKQtPa2EVObJZ
zTJrpTOZUYXkifYaE4+y8k98an8lJkXGm2NIhdFXnWrK2iJLedGCs9JbLFezmje8
U1UQULyK1QQ+riB4OiDxW9BNnFuJPO/qte0LDcK9xpv3cJBkc/0aeMdtr3lt+Siz
bikFwFTn5+HzPaoLED3n6A2M/vj3Gkzj1HwL71G6idJrBye8mL3DCxQSZce964CQ
BCl7h31OklOJfMdkgrrd
=kiAz
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/4] udoo: Improve stability of DDR3 setting

[Giuseppe Pagano]

Move udoo configuration files to board/udoo/ folder.
Align clock configuration and DDR3 calibration to Seco suggested value
to increase system stability.

Signed-off-by: Giuseppe Pagano 
Cc: sba...@denx.de

...

diff -uNr a/board/udoo/1066mhz_4x256mx16.cfg
b/board/udoo/1066mhz_4x256mx16.cfg
--- a/board/udoo/1066mhz_4x256mx16.cfg
+++ b/board/udoo/1066mhz_4x256mx16.cfg
@@ -0,0 +1,56 @@
+/*
+ * Copyright (C) 2013 Boundary Devices
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+
+DATA 4, MX6_MMDC_P0_MDPDC, 0x00020036
+DATA 4, MX6_MMDC_P0_MDOTC, 0x09444040
+
+DATA 4, MX6_MMDC_P0_MDCFG0, 0x54597955
+DATA 4, MX6_MMDC_P0_MDCFG1, 0xFF328F64
+DATA 4, MX6_MMDC_P0_MDCFG2, 0x01FF00DB
+
+DATA 4, MX6_MMDC_P0_MDMISC, 0x1740
+DATA 4, MX6_MMDC_P0_MDSCR,  0x8000
+DATA 4, MX6_MMDC_P0_MDRWD,  0x26D2
+
+DATA 4, MX6_MMDC_P0_MDOR,  0x00591023
+DATA 4, MX6_MMDC_P0_MDASP, 0x0027
+DATA 4, MX6_MMDC_P0_MDCTL, 0x831A
+
+DATA 4, MX6_MMDC_P0_MDSCR, 0x04088032
+DATA 4, MX6_MMDC_P0_MDSCR, 0x8033
+
+DATA 4, MX6_MMDC_P0_MDSCR, 0x00048031
+DATA 4, MX6_MMDC_P0_MDSCR, 0x09408030
+DATA 4, MX6_MMDC_P0_MDSCR, 0x04008040
+DATA 4, MX6_MMDC_P0_MPZQHWCTRL, 0xA1380003
+DATA 4, MX6_MMDC_P1_MPZQHWCTRL, 0xA1380003
+DATA 4, MX6_MMDC_P0_MDREF, 0x5800
+DATA 4, MX6_MMDC_P0_MPODTCTRL, 0x0007
+DATA 4, MX6_MMDC_P1_MPODTCTRL, 0x0007
+
+DATA 4, MX6_MMDC_P0_MPDGCTRL0, 0x43510360
+DATA 4, MX6_MMDC_P0_MPDGCTRL1, 0x0342033F
+DATA 4, MX6_MMDC_P1_MPDGCTRL0, 0x033F033F
+DATA 4, MX6_MMDC_P1_MPDGCTRL1, 0x03290266
+
+DATA 4, MX6_MMDC_P0_MPRDDLCTL, 0x4B3E4141
+DATA 4, MX6_MMDC_P1_MPRDDLCTL, 0x47413B4A
+DATA 4, MX6_MMDC_P0_MPWRDLCTL, 0x42404843
+DATA 4, MX6_MMDC_P1_MPWRDLCTL, 0x4C3F4C45
+
+DATA 4, MX6_MMDC_P0_MPWLDECTRL0, 0x00350035
+DATA 4, MX6_MMDC_P0_MPWLDECTRL1, 0x001F001F
+DATA 4, MX6_MMDC_P1_MPWLDECTRL0, 0x00010001
+DATA 4, MX6_MMDC_P1_MPWLDECTRL1, 0x00010001
+
+DATA 4, MX6_MMDC_P0_MPMUR0, 0x0800
+DATA 4, MX6_MMDC_P1_MPMUR0, 0x0800
+
+DATA 4, MX6_MMDC_P0_MDPDC, 0x00025576
+DATA 4, MX6_MMDC_P0_MAPSR, 0x00011006
+DATA 4, MX6_MMDC_P0_MDSCR, 0x
+
diff -uNr a/board/udoo/clocks.cfg b/board/udoo/clocks.cfg
--- a/board/udoo/clocks.cfg
+++ b/board/udoo/clocks.cfg
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2013 Boundary Devices
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Device Configuration Data (DCD)
+ *
+ * Each entry must have the format:
+ * Addr-type   AddressValue
+ *
+ * where:
+ *  Addr-type register length (1,2 or 4 bytes)
+ *  Address   absolute address of the register
+ *  value value to be stored in the register
+ */
+
+/* set the default clock gate to save power */
+DATA 4, CCM_CCGR0, 0x00C03F3F
+DATA 4, CCM_CCGR1, 0x0030FC03
+DATA 4, CCM_CCGR2, 0x0FFFC000
+DATA 4, CCM_CCGR3, 0x3FF0
+DATA 4, CCM_CCGR4, 0x00FFF300
+DATA 4, CCM_CCGR5, 0x0FC3
+DATA 4, CCM_CCGR6, 0x03FF
+
+/* enable AXI cache for VDOA/VPU/IPU */
+DATA 4, MX6_IOMUXC_GPR4, 0xF0FF
+
+/* set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 */
+DATA 4, MX6_IOMUXC_GPR6, 0x007F007F
+DATA 4, MX6_IOMUXC_GPR7, 0x007F007F
+
diff -uNr a/board/udoo/ddr-setup.cfg b/board/udoo/ddr-setup.cfg
--- a/board/udoo/ddr-setup.cfg
+++ b/board/udoo/ddr-setup.cfg
@@ -0,0 +1,87 @@
+/*
+ * Copyright (C) 2013 Boundary Devices
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Device Configuration Data (DCD)
+ *
+ * Each entry must have the format:
+ * Addr-type   AddressValue
+ *
+ * where:
+ *  Addr-type register length (1,2 or 4 bytes)
+ *  Address   absolute address of the register
+ *  value value to be stored in the register
+ */
+
+/*
+ * DDR3 settings
+ * MX6Qddr is limited to 1066 Mhz  currently 1056 MHz(528 MHz
clock),
+ *memory bus width: 64 bitsx16/x32/x64
+ * MX6DL   ddr is limited to 800 MHz(400 MHz clock)
+ *memory bus width: 64 bitsx16/x32/x64
+ * MX6SOLO ddr is limited to 800 MHz(400 MHz clock)
+ *memory bus width: 32 bitsx16/x32
+ */
+DATA 4, MX6_IOM_DRAM_SDQS0, 0x0030
+DATA 4, MX6_IOM_DRAM_SDQS1, 0x0030
+DATA 4, MX6_IOM_DRAM_SDQS2, 0x0030
+DATA 4, MX6_IOM_DRAM_SDQS3, 0x0030
+DATA 4, MX6_IOM_DRAM_SDQS4, 0x0030
+DATA 4, MX6_IOM_DRAM_SDQS5, 0x0030
+DATA 4, MX6_IOM_DRAM_SDQS6, 0x0030
+DATA 4, MX6_IOM_DRAM_SDQS7, 0x0030
+
+DATA 4, MX6_IOM_GRP_B0DS, 0x0030
+DATA 4, MX6_IOM_GRP_B1DS, 0x0030
+DATA 4, MX6_IOM_GRP_B2DS, 0x0030
+DATA 4, MX6_IOM_GRP_B3DS, 0x0030
+DATA 4, MX6_IOM_GRP_B4DS, 0x0030
+DATA 4, MX6_IOM_GRP_B5DS, 0x0030
+DATA 4, MX6_IOM_GRP_B6DS, 0x0030
+DATA 4, MX6_IOM_GRP_B7DS, 0x0030
+DATA 4, MX6_IOM_GRP_ADDDS, 0x0030
+/* 40 Ohm drive strength for cs0/1,sdba2,cke0/1,sdwe */
+DATA 4, MX6_IOM_GRP_CTLDS, 0x0030
+
+DATA 4, MX6_IOM_DRAM_DQM0, 0x00020030
+DATA 4, MX6_IOM_DRAM_DQM1, 0x00020030
+DATA 4, MX6_IOM_DRAM_DQM2, 0x00020030
+DATA 4, MX6_IOM_DRAM_DQM3, 0x00020030
+DATA 4, MX6_IOM_DRAM_DQM4, 0x00020030
+DATA 4, MX6_IOM_DRAM_DQM5, 0x000200

[U-Boot] [PATCH 1/4] udoo: Add Ethernet support.

[Giuseppe Pagano]

Add Ethernet and networking support on uDoo board (FEC + phy Micrel)


Signed-off-by: Giuseppe Pagano 
Cc: sba...@denx.de

---

diff -uNr a/board/udoo/udoo.c b/board/udoo/udoo.c
--- a/board/udoo/udoo.c
+++ b/board/udoo/udoo.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,6 +19,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -25,6 +29,9 @@
PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
 
+#define ENET_PAD_CTRL  (PAD_CTL_PUS_100K_UP |   \
+   PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
+
 #define USDHC_PAD_CTRL (PAD_CTL_PUS_47K_UP |   \
PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \
PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
@@ -58,6 +65,99 @@
MX6_PAD_EIM_D19__GPIO_3_19,
 };
 
+int mx6_rgmii_rework(struct phy_device *phydev)
+{
+   /* To advertise only 10 Mbs */
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x4, 0x61);
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x9, 0x0c00);
+
+   /* enable master mode, force phy to 100Mbps */
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x9, 0x1c00);
+
+   /* min rx data delay */
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x0b, 0x8105);
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x0c, 0x);
+
+   /* max rx/tx clock delay, min rx/tx control delay */
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x0b, 0x8104);
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x0c, 0xf0f0);
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x0b, 0x104);
+
+   /* min rx data delay */
+   ksz9021_phy_extended_write(phydev,
+  MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW, 0x0);
+   /* min tx data delay */
+   ksz9021_phy_extended_write(phydev,
+  MII_KSZ9021_EXT_RGMII_TX_DATA_SKEW, 0x0);
+   /* max rx/tx clock delay, min rx/tx control */
+   ksz9021_phy_extended_write(phydev,
+  MII_KSZ9021_EXT_RGMII_CLOCK_SKEW, 0x03FF);
+   return 0;
+}
+
+static iomux_v3_cfg_t const enet_pads1[] = {
+   MX6_PAD_ENET_MDIO__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_ENET_MDC__ENET_MDC  | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII_TXC__ENET_RGMII_TXC   | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII_TD0__ENET_RGMII_TD0   | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII_TD1__ENET_RGMII_TD1   | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII_TD2__ENET_RGMII_TD2   | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII_TD3__ENET_RGMII_TD3   | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL  | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_ENET_REF_CLK__ENET_TX_CLK   | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII_RXC__ENET_RGMII_RXC   | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   /* RGMII reset */
+   MX6_PAD_EIM_D23__GPIO_3_23  | MUX_PAD_CTRL(NO_PAD_CTRL),
+   /* alimentazione ethernet*/
+   MX6_PAD_EIM_EB3__GPIO_2_31  | MUX_PAD_CTRL(NO_PAD_CTRL),
+   /* pin 32 - 1 - (MODE0) all */
+   MX6_PAD_RGMII_RD0__GPIO_6_25| MUX_PAD_CTRL(NO_PAD_CTRL),
+   /* pin 31 - 1 - (MODE1) all */
+   MX6_PAD_RGMII_RD1__GPIO_6_27| MUX_PAD_CTRL(NO_PAD_CTRL),
+   /* pin 28 - 1 - (MODE2) all */
+   MX6_PAD_RGMII_RD2__GPIO_6_28| MUX_PAD_CTRL(NO_PAD_CTRL),
+   /* pin 27 - 1 - (MODE3) all */
+   MX6_PAD_RGMII_RD3__GPIO_6_29| MUX_PAD_CTRL(NO_PAD_CTRL),
+   /* pin 33 - 1 - (CLK125_EN) 125Mhz clockout enabled */
+   MX6_PAD_RGMII_RX_CTL__GPIO_6_24 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
+static iomux_v3_cfg_t const enet_pads2[] = {
+   MX6_PAD_RGMII_RD0__ENET_RGMII_RD0   | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII_RD1__ENET_RGMII_RD1   | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII_RD2__ENET_RGMII_RD2   | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII_RD3__ENET_RGMII_RD3   | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII_RX_CTL__RGMII_RX_CTL  | MUX_PAD_CTRL(ENET_PAD_CTRL),
+};
+
+static void setup_iomux_enet(void)
+{
+   imx_iomux_v3_setup_multiple_pads(enet_pads1, ARRAY_SIZE(enet_pads1));
+   udelay(20);
+   gpio_direction_output(IMX_GPIO_NR(2, 31), 1); /* Power on of enet */
+
+   gpio_direction_output(IMX_GPIO_NR(3, 23), 0); /* SABRE Lite PHY rst */
+
+   gpio_direction_output(IMX_GPIO_NR(6, 24), 1);
+   gpio_direction_output(IMX_GPIO_NR(6, 25), 1);
+   gpio_direction_output(IMX_GPIO_NR(6, 27), 1);
+   gpio_direction_output(IMX_GPIO_NR(6, 28), 1);
+   gpio_direction_output(IMX_GPIO_NR(6, 29), 1);
+   udelay(1000 * 10);
+
+   gpio_set_value(IMX_GPIO_NR(3, 23), 1); /* SABRE Lite PHY rst */
+   /* Need delay 100ms according to KSZ9031 spec */
+   udelay(1000 * 100);
+
+  

[U-Boot] [PATCH 4/4] udoo: fix watchdog setting

[Giuseppe Pagano]

To have watchdog quiet during kernel boot it is necessary to
change gpio wdt trigger direction.


Signed-off-by: Giuseppe Pagano 
Cc: sba...@denx.de

---

diff -uNr a/board/udoo/udoo.c b/board/udoo/udoo.c
--- a/board/udoo/udoo.c 2013-11-06 18:47:26.0 +0100
+++ b/board/udoo/udoo.c 2013-11-06 18:54:46.0 +0100
@@ -168,6 +168,7 @@
imx_iomux_v3_setup_multiple_pads(wdog_pads,
ARRAY_SIZE(wdog_pads));
gpio_direction_output(WDT_TRG, 0);
gpio_direction_output(WDT_EN, 1);
+   gpio_direction_input(WDT_TRG);
 }
 
 static struct fsl_esdhc_cfg usdhc_cfg = { USDHC3_BASE_ADDR };


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

[U-Boot] [PATCH 2/4] udoo: Add SATA disk support.

[Giuseppe Pagano]

Add Sata support on uDoo Board.

Signed-off-by: Giuseppe Pagano 
Cc: sba...@denx.de

---

diff -uNr a/board/udoo/udoo.c b/board/udoo/udoo.c
--- a/board/udoo/udoo.c 2013-11-06 18:45:22.0 +0100
+++ b/board/udoo/udoo.c 2013-11-06 18:46:00.0 +0100
@@ -208,6 +208,32 @@
return 0;
 }
 
+#ifdef CONFIG_CMD_SATA
+int setup_sata(void)
+{
+   struct iomuxc_base_regs *const iomuxc_regs
+   = (struct iomuxc_base_regs *)IOMUXC_BASE_ADDR;
+
+   int ret = enable_sata_clock();
+   if (ret)
+   return ret;
+
+   clrsetbits_le32(&iomuxc_regs->gpr[13],
+   IOMUXC_GPR13_SATA_MASK,
+   IOMUXC_GPR13_SATA_PHY_8_RXEQ_3P0DB
+   |IOMUXC_GPR13_SATA_PHY_7_SATA2M
+   |IOMUXC_GPR13_SATA_SPEED_3G
+   |(3bi_boot_params = PHYS_SDRAM + 0x100;
 
+#ifdef CONFIG_CMD_SATA
+   setup_sata();
+#endif
return 0;
 }
 
diff -uNr a/include/configs/udoo.h b/include/configs/udoo.h
--- a/include/configs/udoo.h2013-11-06 18:45:22.0 +0100
+++ b/include/configs/udoo.h2013-11-06 18:46:27.0 +0100
@@ -34,6 +34,19 @@
 #define CONFIG_MXC_UART
 #define CONFIG_MXC_UART_BASE   UART2_BASE
 
+#define CONFIG_CMD_SATA
+/*
+ * SATA Configs
+ */
+#ifdef CONFIG_CMD_SATA
+#define CONFIG_DWC_AHSATA
+#define CONFIG_SYS_SATA_MAX_DEVICE 1
+#define CONFIG_DWC_AHSATA_PORT_ID  0
+#define CONFIG_DWC_AHSATA_BASE_ADDRSATA_ARB_BASE_ADDR
+#define CONFIG_LBA48
+#define CONFIG_LIBATA
+#endif
+
 /* Network support */
 
 #define CONFIG_CMD_PING


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

[U-Boot] [PATCH 3/4] udoo: Adjust default boot envirnment

[Giuseppe Pagano]

Change u-boot default environment for uDoo board to:
  - mount /dev/mmcblk0p1 partition
  - activate hdmi monitor by default (instead of nothing)

Signed-off-by: Giuseppe Pagano 
Cc: sba...@denx.de

---

diff -uNr a/include/configs/udoo.h b/include/configs/udoo.h
--- a/include/configs/udoo.h2013-11-06 18:51:57.0 +0100
+++ b/include/configs/udoo.h2013-11-06 18:52:16.0 +0100
@@ -100,7 +100,7 @@
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
-   "uimage=uImage\0" \
+   "uimage=/boot/uImage\0" \
"console=ttymxc1\0" \
"splashpos=m,m\0" \
"fdt_high=0x\0" \
@@ -111,7 +111,7 @@
"ip_dyn=yes\0" \
"mmcdev=0\0" \
"mmcpart=1\0" \
-   "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
+   "mmcroot=/dev/mmcblk0p1 rootwait rw\0" \
"update_sd_firmware_filename=u-boot.imx\0" \
"update_sd_firmware=" \
"if test ${ip_dyn} = yes; then " \
@@ -127,13 +127,14 @@
"fi; "  \
"fi\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
-   "root=${mmcroot}\0" \
+   "root=${mmcroot} rootwait rw " \
+   "fbmem=24M video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24\0" \
"loadbootscript=" \
-   "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
+   "ext2load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
"source\0" \
-   "loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0"
\
-   "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
+   "loaduimage=ext2load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0"
\
+   "loadfdt=ext2load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0"
\
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
@@ -189,7 +190,7 @@
 /* Miscellaneous configurable options */
 #define CONFIG_SYS_LONGHELP
 #define CONFIG_SYS_HUSH_PARSER
-#define CONFIG_SYS_PROMPT "=> "
+#define CONFIG_SYS_PROMPT  "uDoo board >"
 #define CONFIG_AUTO_COMPLETE
 #define CONFIG_SYS_CBSIZE  256
 


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

Re: [U-Boot] Pull request: u-boot-coldfire

[Tom Rini]

On Wed, Nov 06, 2013 at 03:08:54PM +, Zhengxiong Jin wrote:

> Hi Tom,
> 
> Please pull from u-boot-coldfire.git, thanks!
> 
> The following changes since commit e5a9a4076f1fb9fb9ce53c2aec32422073bbc66a:
> 
>   pxe: fix handling of absolute paths (2013-11-04 11:24:22 -0500)
> 
> are available in the git repository at:
>   git://git.denx.de/u-boot-coldfire.git master
> 
> Jens Scharsig (BuS Elektronik) (1):
>   coldfire: cpu5282: increase malloc space to fix crash on start u-boot
> 
> jason (1):
>   ColdFire: fix some typoes for CF platform
> 
>  include/configs/M5253DEMO.h  |2 +-
>  include/configs/M54455EVB.h  |2 +-
>  include/configs/eb_cpu5282.h |2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Pull request - fpga

[Tom Rini]

On Wed, Nov 06, 2013 at 09:17:00AM +0100, Michal Simek wrote:

> Hi Tom,
> 
> please pull these 3 changes to your tree.
> 
> Thanks,
> Michal
> 
> 
> The following changes since commit e5a9a4076f1fb9fb9ce53c2aec32422073bbc66a:
> 
>   pxe: fix handling of absolute paths (2013-11-04 11:24:22 -0500)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-microblaze.git fpga
> 
> for you to fetch changes up to 32d7cdd366a1516fa498464c261851f3a76a62ef:
> 
>   fpga: Add support for gzip images with bitstreams (2013-11-06 09:15:12 
> +0100)
> 
> 
> Jagannadha Sutradharudu Teki (1):
>   fpga: zynqpl: Add dcache flush support
> 
> Michal Simek (2):
>   fpga: zynqpl: Do not place bitstream below 1MB
>   fpga: Add support for gzip images with bitstreams
> 
>  common/cmd_fpga.c | 22 +++---
>  drivers/fpga/zynqpl.c | 15 +--
>  2 files changed, 32 insertions(+), 5 deletions(-)

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] freescale: p1_p2_rdb_pc: rename COBJS-y to obj-y

[Tom Rini]

On Tue, Nov 05, 2013 at 05:03:22PM +0900, Masahiro Yamada wrote:

> Signed-off-by: Masahiro Yamada 
> 
> ---
> board/freescale/p1_p2_rdb_pc/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/board/freescale/p1_p2_rdb_pc/Makefile 
> b/board/freescale/p1_p2_rdb_pc/Makefile
> index 8e20073..a2a1f92 100644
> --- a/board/freescale/p1_p2_rdb_pc/Makefile
> +++ b/board/freescale/p1_p2_rdb_pc/Makefile
> @@ -18,7 +18,7 @@ obj-y   += spl_minimal.o tlb.o law.o
>  
>  else
>  ifdef CONFIG_SPL_BUILD
> -COBJS-y += spl.o
> +obj-y += spl.o
>  endif
>  
>  obj-y+= p1_p2_rdb_pc.o

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Makfile: fix a rule to build u-boot.sb

[Tom Rini]

On Tue, Nov 05, 2013 at 05:09:02PM +0900, Masahiro Yamada wrote:

> Signed-off-by: Masahiro Yamada 
> 
> ---
> This is a follow-up patch of the series:
> First step towards Kbuild: Use Kbuild style makefiles
> 
> The series broke the build rule of u-boot.sb
> 
> u-boot.sb is never automatically generated.
> (u-boot.sb is not added to ALL-y)
> 
> That's why I could detect the bug of the former series
> by MAKEALL or patman test.
> 
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index a2fd7f6..1f499c5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -490,7 +490,7 @@ $(obj)u-boot.ais:   $(obj)spl/u-boot-spl.bin 
> $(obj)u-boot.img
>  
>  
>  $(obj)u-boot.sb:   $(obj)u-boot.bin $(obj)spl/u-boot-spl.bin
> - $(MAKE) -C $(SRCTREE)/$(CPUDIR)/$(SOC)/ $(OBJTREE)/u-boot.sb
> + $(MAKE) $(build) $(SRCTREE)/$(CPUDIR)/$(SOC)/ 
> $(OBJTREE)/u-boot.sb
>  
>  # On x600 (SPEAr600) U-Boot is appended to U-Boot SPL.
>  # Both images are created using mkimage (crc etc), so that the ROM

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 00/10 V6] EXYNOS5420: Add SMDK5420 board support

[Minkyu Kang]

Hi,

On 06/11/13 20:42, Rajeshwari Birje wrote:
> Hi Minkyu Kang,
> 
> On Thu, Oct 31, 2013 at 2:12 PM, Rajeshwari Birje
>  wrote:
>> Hi Minkyu Kang,
>>
>> Kindly do review the patch set and do let me know if any review comments.
>> Pantelis Antoniou has merged the patch 10 (DWMMC: SMDK5420: Disable
>> SMU for eMMC) into mmc tree.
>>
> We have merge window in next three days, this patches are acked by Simon.
> Can you please have a look and get it merged if no review comments
> from your end, or
> please do let me know if some rework needed.
> 

Since my working schedule, I were away from mailing list.
I have plan to review pending patches at next week.
So, please wait few days.

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

Re: [U-Boot] [PATCH V2 2/2] trats2: enable ums support on Trats2

[Jaehoon Chung]

Acked-by: Jaehoon Chung 

On 11/06/2013 10:46 PM, Piotr Wilczek wrote:
> This patch adds support for USB and enables 'ums' command on Trats2 board.
> 
> Signed-off-by: Piotr Wilczek 
> Signed-off-by: Kyungmin Park 
> CC: Minkyu Kang 
> ---
> This patch depends on the lated u-boot-usb/master.
> 
> Changes for v2:
>  - rebased on current USB tree
>  - removed unnecessary pmic probing
> 
>  board/samsung/trats2/trats2.c |   92 
> +
>  include/configs/trats2.h  |   18 
>  2 files changed, 110 insertions(+)
> 
> diff --git a/board/samsung/trats2/trats2.c b/board/samsung/trats2/trats2.c
> index d44d825..41a7310 100644
> --- a/board/samsung/trats2/trats2.c
> +++ b/board/samsung/trats2/trats2.c
> @@ -25,6 +25,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -308,6 +311,95 @@ int board_mmc_init(bd_t *bis)
>   return err0 & err2;
>  }
>  
> +#ifdef CONFIG_USB_GADGET
> +static int s5pc210_phy_control(int on)
> +{
> + int ret = 0;
> + unsigned int val;
> + struct pmic *p, *p_pmic, *p_muic;
> +
> + p_pmic = pmic_get("MAX77686_PMIC");
> + if (!p_pmic)
> + return -ENODEV;
> +
> + if (pmic_probe(p_pmic))
> + return -1;
> +
> + p_muic = pmic_get("MAX77693_MUIC");
> + if (!p_muic)
> + return -ENODEV;
> +
> + if (pmic_probe(p_muic))
> + return -1;
> +
> + if (on) {
> + ret = max77686_set_ldo_mode(p_pmic, 12, OPMODE_ON);
> + if (ret)
> + return -1;
> +
> + p = pmic_get("MAX77693_PMIC");
> + if (!p)
> + return -ENODEV;
> +
> + if (pmic_probe(p))
> + return -1;
> +
> + /* SAFEOUT */
> + ret = pmic_reg_read(p, MAX77693_SAFEOUT, &val);
> + if (ret)
> + return -1;
> +
> + val |= MAX77693_ENSAFEOUT1;
> + ret = pmic_reg_write(p, MAX77693_SAFEOUT, val);
> + if (ret)
> + return -1;
> +
> + /* PATH: USB */
> + ret = pmic_reg_write(p_muic, MAX77693_MUIC_CONTROL1,
> + MAX77693_MUIC_CTRL1_DN1DP2);
> +
> + } else {
> + ret = max77686_set_ldo_mode(p_pmic, 12, OPMODE_LPM);
> + if (ret)
> + return -1;
> +
> + /* PATH: UART */
> + ret = pmic_reg_write(p_muic, MAX77693_MUIC_CONTROL1,
> + MAX77693_MUIC_CTRL1_UT1UR2);
> + }
> +
> + if (ret)
> + return -1;
> +
> +
> + return 0;
> +}
> +
> +struct s3c_plat_otg_data s5pc210_otg_data = {
> + .phy_control= s5pc210_phy_control,
> + .regs_phy   = EXYNOS4X12_USBPHY_BASE,
> + .regs_otg   = EXYNOS4X12_USBOTG_BASE,
> + .usb_phy_ctrl   = EXYNOS4X12_USBPHY_CONTROL,
> + .usb_flags  = PHY0_SLEEP,
> +};
> +
> +int board_usb_init(int index, enum usb_init_type init)
> +{
> + debug("USB_udc_probe\n");
> + return s3c_udc_probe(&s5pc210_otg_data);
> +}
> +
> +#ifdef CONFIG_USB_CABLE_CHECK
> +int usb_cable_connected(void)
> +{
> + struct pmic *muic = pmic_get("MAX77693_MUIC");
> + int cable_connected = muic->chrg->chrg_type(muic);
> +
> + return !!cable_connected;
> +}
> +#endif
> +#endif
> +
>  static int pmic_init_max77686(void)
>  {
>   struct pmic *p = pmic_get("MAX77686_PMIC");
> diff --git a/include/configs/trats2.h b/include/configs/trats2.h
> index 0e93836..66b1c95 100644
> --- a/include/configs/trats2.h
> +++ b/include/configs/trats2.h
> @@ -113,6 +113,16 @@
>  #define CONFIG_CMD_EXT4
>  #define CONFIG_CMD_EXT4_WRITE
>  
> +/* USB Composite download gadget - g_dnl */
> +#define CONFIG_USBDOWNLOAD_GADGET
> +#define CONFIG_DFU_FUNCTION
> +#define CONFIG_DFU_MMC
> +
> +/* USB Samsung's IDs */
> +#define CONFIG_G_DNL_VENDOR_NUM 0x04E8
> +#define CONFIG_G_DNL_PRODUCT_NUM 0x6601
> +#define CONFIG_G_DNL_MANUFACTURER "Samsung"
> +
>  /* To use the TFTPBOOT over USB, Please enable the CONFIG_CMD_NET */
>  #undef CONFIG_CMD_NET
>  
> @@ -293,6 +303,11 @@
>  #define CONFIG_POWER_MUIC_MAX77693
>  #define CONFIG_POWER_FG_MAX77693
>  #define CONFIG_POWER_BATTERY_TRATS2
> +#define CONFIG_USB_GADGET
> +#define CONFIG_USB_GADGET_S3C_UDC_OTG
> +#define CONFIG_USB_GADGET_DUALSPEED
> +#define CONFIG_USB_GADGET_VBUS_DRAW  2
> +#define CONFIG_USB_CABLE_CHECK
>  
>  /* LCD */
>  #define CONFIG_EXYNOS_FB
> @@ -305,6 +320,9 @@
>  #define CONFIG_VIDEO_BMP_GZIP
>  #define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE ((500 * 250 * 4) + (1 << 12))
>  
> +#define CONFIG_CMD_USB_MASS_STORAGE
> +#define CONFIG_USB_GADGET_MASS_STORAGE
> +
>  /* Pass open firmware flat tree */
>  #define CONFIG_OF_LIBFDT1
>  
> 

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

Re: [U-Boot] [PATCH V2 1/2] driver:usb:s3c_udc: add support for Exynos4x12

[Jaehoon Chung]

Dear Piotr.

On 11/06/2013 10:46 PM, Piotr Wilczek wrote:
> This patch add new defines for usb phy for Exynos4x12.
> 
> Signed-off-by: Piotr Wilczek 
> Signed-off-by: Kyungmin Park 
> CC: Minkyu Kang 
> ---
> Changes for v2:
>  - no changes
> 
>  drivers/usb/gadget/regs-otg.h|5 +
>  drivers/usb/gadget/s3c_udc_otg.c |   10 --
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/regs-otg.h b/drivers/usb/gadget/regs-otg.h
> index 84bfcc5..ac5d112 100644
> --- a/drivers/usb/gadget/regs-otg.h
> +++ b/drivers/usb/gadget/regs-otg.h
> @@ -226,6 +226,11 @@ struct s3c_usbotg_reg {
>  #define CLK_SEL_12MHZ   (0x2 << 0)
>  #define CLK_SEL_48MHZ   (0x0 << 0)
>  
> +#define EXYNOS4X12_ID_PULLUP0(0x01 << 3)
> +#define EXYNOS4X12_COMMON_ON_N0  (0x01 << 4)
> +#define EXYNOS4X12_CLK_SEL_12MHZ (0x02 << 0)
> +#define EXYNOS4X12_CLK_SEL_24MHZ (0x05 << 0)
> +
>  /* Device Configuration Register DCFG */
>  #define DEV_SPEED_HIGH_SPEED_20 (0x0 << 0)
>  #define DEV_SPEED_FULL_SPEED_20 (0x1 << 0)
> diff --git a/drivers/usb/gadget/s3c_udc_otg.c 
> b/drivers/usb/gadget/s3c_udc_otg.c
> index 7e20209..cecd280 100644
> --- a/drivers/usb/gadget/s3c_udc_otg.c
> +++ b/drivers/usb/gadget/s3c_udc_otg.c
> @@ -36,6 +36,7 @@
>  #include "regs-otg.h"
>  #include 
>  
> +
remove white-space.

>  /***/
>  
>  #define OTG_DMA_MODE 1
> @@ -167,8 +168,13 @@ void otg_phy_init(struct s3c_udc *dev)
>   writel((readl(&phy->phypwr) &~(OTG_DISABLE_0 | ANALOG_PWRDOWN)
>   &~FORCE_SUSPEND_0), &phy->phypwr);
>  
> - writel((readl(&phy->phyclk) &~(ID_PULLUP0 | COMMON_ON_N0)) |
> -CLK_SEL_24MHZ, &phy->phyclk); /* PLL 24Mhz */
> + if (s5p_cpu_id == 0x4412)
> + writel((readl(&phy->phyclk) & ~(EXYNOS4X12_ID_PULLUP0 |
> + EXYNOS4X12_COMMON_ON_N0)) | EXYNOS4X12_CLK_SEL_24MHZ,
> +&phy->phyclk); /* PLL 24Mhz */
> + else
> + writel((readl(&phy->phyclk) & ~(ID_PULLUP0 | COMMON_ON_N0)) |
> +CLK_SEL_24MHZ, &phy->phyclk); /* PLL 24Mhz */
>  
>   writel((readl(&phy->rstcon) &~(LINK_SW_RST | PHYLNK_SW_RST))
>  | PHY_SW_RST0, &phy->rstcon);
> 

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

Re: [U-Boot] A question about unconfigured pads check in omap24xx_i2c

[Heiko Schocher]

Hello Lubomir,

Am 06.11.2013 14:19, schrieb Lubomir Popov:

On 06-Nov-13 14:12, Nikita Kiryanov wrote:

In drivers/i2c/omap24xx_i2c.c there are a few checks that attempt to
detect unconfigured pads for the i2c bus in use. These checks are
all in the form of

if (status == I2C_STAT_XRDY) {
printf("unconfigured pads\n");
return -1;
}

This check seems peculiar to me since the meaning of I2C_STAT_XRDY is
that new data is requested for transmission. Why is that indication that
the bus is not padconf'd for I2C?

Hi Nikita,

This has been empirically confirmed on OMAP4 and OMAP5. When the pads are not
configured, the I2C controller is actually disconnected from the bus. The clock
input for its state machine has to come from the bus however due to stretching
etc., although it is internally generated. So actually nothing changes within
the controller after a transaction attempt is made, and it keeps its initial
state with XRDY set only (ready to accept transmit data). I use this as an
indicator. Not perfect, but works in most cases.


Thanks for this explanation! Maybe we can document this somewhere in
the code?

bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [U-boot] CONFIG_LOGBUFFER and _POST_WORD_ADDR

[TigerLiu]

Hi, experts:

I tried to turn on log buffer function by defined CONFIG_LOGBUFFER.

When compiled source code, it tips:

Should define _POST_WORD_ADDR .

 

But i think:

_POST_WORD_ADDR is not related with CONFIG_LOGBUFFER.

_POST_WORD_ADDR is justed related with CONFIG_POST

 

So, should revise include/post.h file.

 

Best wishes,

 

 

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

[U-Boot] [PATCH v2] usb: dfu: make nand upload working

[Bo Shen]

Nowhere pass a value to len, which always 0, make no transfer which
cause uploading failed.

This patch make nand upload working. However it needs enough malloc
buffer to store read data, that means the buffer at least equal to
the upload partition size, or else it doesn't work.

Signed-off-by: Bo Shen 
---
Changes in v2:
  - Move code to nand part, or else it will break mmc

 drivers/dfu/dfu_nand.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
index 1c2e03b..cf082e2 100644
--- a/drivers/dfu/dfu_nand.c
+++ b/drivers/dfu/dfu_nand.c
@@ -121,6 +121,7 @@ static int dfu_read_medium_nand(struct dfu_entity *dfu, u64 
offset, void *buf,
 
switch (dfu->layout) {
case DFU_RAW_ADDR:
+   *len = dfu->data.nand.size;
ret = nand_block_read(dfu, offset, buf, len);
break;
default:
-- 
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 V2 1/2] driver:usb:s3c_udc: add support for Exynos4x12

[Piotr Wilczek]

Dear Jaehoon,

> -Original Message-
> From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
> Sent: Thursday, November 07, 2013 5:49 AM
> To: Piotr Wilczek; u-boot@lists.denx.de
> Cc: Kyungmin Park
> Subject: Re: [U-Boot] [PATCH V2 1/2] driver:usb:s3c_udc: add support
> for Exynos4x12
> 
> Dear Piotr.
> 
> On 11/06/2013 10:46 PM, Piotr Wilczek wrote:
> > This patch add new defines for usb phy for Exynos4x12.
> >
> > Signed-off-by: Piotr Wilczek 
> > Signed-off-by: Kyungmin Park 
> > CC: Minkyu Kang 
> > ---
> > Changes for v2:
> >  - no changes
> >
> >  drivers/usb/gadget/regs-otg.h|5 +
> >  drivers/usb/gadget/s3c_udc_otg.c |   10 --
> >  2 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/regs-otg.h
> > b/drivers/usb/gadget/regs-otg.h index 84bfcc5..ac5d112 100644
> > --- a/drivers/usb/gadget/regs-otg.h
> > +++ b/drivers/usb/gadget/regs-otg.h
> > @@ -226,6 +226,11 @@ struct s3c_usbotg_reg {
> >  #define CLK_SEL_12MHZ   (0x2 << 0)
> >  #define CLK_SEL_48MHZ   (0x0 << 0)
> >
> > +#define EXYNOS4X12_ID_PULLUP0  (0x01 << 3)
> > +#define EXYNOS4X12_COMMON_ON_N0(0x01 << 4)
> > +#define EXYNOS4X12_CLK_SEL_12MHZ   (0x02 << 0)
> > +#define EXYNOS4X12_CLK_SEL_24MHZ   (0x05 << 0)
> > +
> >  /* Device Configuration Register DCFG */
> >  #define DEV_SPEED_HIGH_SPEED_20 (0x0 << 0)
> >  #define DEV_SPEED_FULL_SPEED_20 (0x1 << 0)
> > diff --git a/drivers/usb/gadget/s3c_udc_otg.c
> > b/drivers/usb/gadget/s3c_udc_otg.c
> > index 7e20209..cecd280 100644
> > --- a/drivers/usb/gadget/s3c_udc_otg.c
> > +++ b/drivers/usb/gadget/s3c_udc_otg.c
> > @@ -36,6 +36,7 @@
> >  #include "regs-otg.h"
> >  #include 
> >
> > +
> remove white-space.
I will, thanks for review.

> 
> >  /***/
> >
> >  #define OTG_DMA_MODE   1
> > @@ -167,8 +168,13 @@ void otg_phy_init(struct s3c_udc *dev)
> > writel((readl(&phy->phypwr) &~(OTG_DISABLE_0 |
> ANALOG_PWRDOWN)
> > &~FORCE_SUSPEND_0), &phy->phypwr);
> >
> > -   writel((readl(&phy->phyclk) &~(ID_PULLUP0 | COMMON_ON_N0)) |
> > -  CLK_SEL_24MHZ, &phy->phyclk); /* PLL 24Mhz */
> > +   if (s5p_cpu_id == 0x4412)
> > +   writel((readl(&phy->phyclk) & ~(EXYNOS4X12_ID_PULLUP0 |
> > +   EXYNOS4X12_COMMON_ON_N0)) |
EXYNOS4X12_CLK_SEL_24MHZ,
> > +  &phy->phyclk); /* PLL 24Mhz */
> > +   else
> > +   writel((readl(&phy->phyclk) & ~(ID_PULLUP0 | COMMON_ON_N0))
> |
> > +  CLK_SEL_24MHZ, &phy->phyclk); /* PLL 24Mhz */
> >
> > writel((readl(&phy->rstcon) &~(LINK_SW_RST | PHYLNK_SW_RST))
> >| PHY_SW_RST0, &phy->rstcon);
> >

Best regards,
Piotr Wilczek


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

[U-Boot] [PATCH 2/3] cm_t335: add support for status LED

[Ilya Ledvich]

Add support for status LED. Use the STATUS_LED APIs for indicating a
boot progress.

Signed-off-by: Ilya Ledvich 
Signed-off-by: Igor Grinberg 
---
 board/compulab/cm_t335/cm_t335.c |3 +++
 board/compulab/cm_t335/mux.c |6 ++
 include/configs/cm_t335.h|   10 ++
 3 files changed, 19 insertions(+)

diff --git a/board/compulab/cm_t335/cm_t335.c b/board/compulab/cm_t335/cm_t335.c
index a318962..01019e8 100644
--- a/board/compulab/cm_t335/cm_t335.c
+++ b/board/compulab/cm_t335/cm_t335.c
@@ -31,6 +31,9 @@ int board_init(void)
 
gpmc_init();
 
+#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT)
+   status_led_set(STATUS_LED_BOOT, STATUS_LED_OFF);
+#endif
return 0;
 }
 
diff --git a/board/compulab/cm_t335/mux.c b/board/compulab/cm_t335/mux.c
index 998d304..7d2beb0 100644
--- a/board/compulab/cm_t335/mux.c
+++ b/board/compulab/cm_t335/mux.c
@@ -94,6 +94,11 @@ static struct module_pin_mux eth_phy_rst_pin_mux[] = {
{-1},
 };
 
+static struct module_pin_mux status_led_pin_mux[] = {
+   {OFFSET(gpmc_csn3), (MODE(7) | PULLUDEN)},  /* GPIO2_0 */
+   {-1},
+};
+
 void set_uart_mux_conf(void)
 {
configure_module_pin_mux(uart0_pin_mux);
@@ -108,4 +113,5 @@ void set_mux_conf_regs(void)
configure_module_pin_mux(eth_phy_rst_pin_mux);
configure_module_pin_mux(mmc0_pin_mux);
configure_module_pin_mux(nand_pin_mux);
+   configure_module_pin_mux(status_led_pin_mux);
 }
diff --git a/include/configs/cm_t335.h b/include/configs/cm_t335.h
index e4eba02..fbdead2 100644
--- a/include/configs/cm_t335.h
+++ b/include/configs/cm_t335.h
@@ -156,5 +156,15 @@
 /* GPIO pin + bank to pin ID mapping */
 #define GPIO_PIN(_bank, _pin)  ((_bank << 5) + _pin)
 
+/* Status LED */
+#define CONFIG_STATUS_LED
+#define CONFIG_GPIO_LED
+#define CONFIG_BOARD_SPECIFIC_LED
+#define STATUS_LED_BIT GPIO_PIN(2, 0)
+/* Status LED polarity is inversed, so init it in the "off" state */
+#define STATUS_LED_STATE   STATUS_LED_OFF
+#define STATUS_LED_PERIOD  (CONFIG_SYS_HZ / 2)
+#define STATUS_LED_BOOT0
+
 #endif /* __CONFIG_CM_T335_H */
 
-- 
1.7.9.5

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

[U-Boot] [PATCH 0/3] Add support for CM-T335 board

[Ilya Ledvich]

This patch series adds support for the Compulab CM-T335 board.
The board is based on TI Sitara AM3352/4 SoC and provides folowing features:
 - 128MB to 512MB DDR3
 - 128MB to 1GB NAND as a main storage
 - Micro SD/MMC card as a secondary storage
 - USB2.0 x4 host ports or USB2.0 x1 OTG port
 - Gigabit Ethernet, WiFi 802.11, Bluetooth, CAN bus, UART
 - LCD/DVI/LVDS display, touchscreen
 - Analog audio

Ilya Ledvich (3):
  cm_t335: add cm_t335 board support
  cm_t335: add support for status LED
  cm_t335: add support for pca9555 i2c gpio extender

 arch/arm/include/asm/arch-am33xx/ddr_defs.h |6 +
 board/compulab/cm_t335/Makefile |   32 +
 board/compulab/cm_t335/cm_t335.c|  162 
 board/compulab/cm_t335/mux.c|  117 +
 board/compulab/cm_t335/spl.c|  110 
 board/compulab/cm_t335/u-boot.lds   |  101 +++
 boards.cfg  |1 +
 include/configs/cm_t335.h   |  182 +++
 8 files changed, 711 insertions(+)
 create mode 100644 board/compulab/cm_t335/Makefile
 create mode 100644 board/compulab/cm_t335/cm_t335.c
 create mode 100644 board/compulab/cm_t335/mux.c
 create mode 100644 board/compulab/cm_t335/spl.c
 create mode 100644 board/compulab/cm_t335/u-boot.lds
 create mode 100644 include/configs/cm_t335.h

-- 
1.7.9.5

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

[U-Boot] [PATCH 1/3] cm_t335: add cm_t335 board support

[Ilya Ledvich]

Add cm_t335 board directory, config file. Enable build.

Signed-off-by: Ilya Ledvich 
Signed-off-by: Igor Grinberg 
---
 arch/arm/include/asm/arch-am33xx/ddr_defs.h |6 +
 board/compulab/cm_t335/Makefile |   32 ++
 board/compulab/cm_t335/cm_t335.c|  159 ++
 board/compulab/cm_t335/mux.c|  111 +++
 board/compulab/cm_t335/spl.c|  110 ++
 board/compulab/cm_t335/u-boot.lds   |  101 +
 boards.cfg  |1 +
 include/configs/cm_t335.h   |  160 +++
 8 files changed, 680 insertions(+)
 create mode 100644 board/compulab/cm_t335/Makefile
 create mode 100644 board/compulab/cm_t335/cm_t335.c
 create mode 100644 board/compulab/cm_t335/mux.c
 create mode 100644 board/compulab/cm_t335/spl.c
 create mode 100644 board/compulab/cm_t335/u-boot.lds
 create mode 100644 include/configs/cm_t335.h

diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h 
b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
index fe48b5f..f56d1e0 100644
--- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
+++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
@@ -58,6 +58,12 @@
 #define MT41J128MJT125_PHY_FIFO_WE 0x100
 #define MT41J128MJT125_IOCTRL_VALUE0x18B
 
+/* Micron MT41J64M16JT-125 */
+#define MT41J64MJT125_EMIF_SDCFG   0x61C04A32
+
+/* Micron MT41J256M16JT-125 */
+#define MT41J256MJT125_EMIF_SDCFG  0x61C04B32
+
 /* Micron MT41J256M8HX-15E */
 #define MT41J256M8HX15E_EMIF_READ_LATENCY  0x06
 #define MT41J256M8HX15E_EMIF_TIM1  0x0888A39B
diff --git a/board/compulab/cm_t335/Makefile b/board/compulab/cm_t335/Makefile
new file mode 100644
index 000..bb50d4c
--- /dev/null
+++ b/board/compulab/cm_t335/Makefile
@@ -0,0 +1,32 @@
+#
+# Copyright (C) 2013 Compulab Ltd - http://compulab.co.il/
+#
+# Author: Ilya Ledvich 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y:= $(BOARD).o
+COBJS-$(CONFIG_SPL_BUILD) += mux.o spl.o
+
+COBJS  := $(sort $(COBJS-y))
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
+
diff --git a/board/compulab/cm_t335/cm_t335.c b/board/compulab/cm_t335/cm_t335.c
new file mode 100644
index 000..a318962
--- /dev/null
+++ b/board/compulab/cm_t335/cm_t335.c
@@ -0,0 +1,159 @@
+/*
+ * Board functions for Compulab CM-T335 board
+ *
+ * Copyright (C) 2013, Compulab Ltd - http://compulab.co.il/
+ *
+ * Author: Ilya Ledvich 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "../common/eeprom.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Basic board specific setup.  Pinmux has been handled already.
+ */
+int board_init(void)
+{
+   gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
+
+   gpmc_init();
+
+   return 0;
+}
+
+#if defined (CONFIG_DRIVER_TI_CPSW) && !defined(CONFIG_SPL_BUILD)
+static void cpsw_control(int enabled)
+{
+   /* VTP can be added here */
+   return;
+}
+
+static struct cpsw_slave_data cpsw_slave = {
+   .slave_reg_ofs  = 0x208,
+   .sliver_reg_ofs = 0xd80,
+   .phy_id = 0,
+   .phy_if = PHY_INTERFACE_MODE_RGMII,
+};
+
+static struct cpsw_platform_data cpsw_data = {
+   .mdio_base  = CPSW_MDIO_BASE,
+   .cpsw_base  = CPSW_BASE,
+   .mdio_div   = 0xff,
+   .channels   = 8,
+   .cpdma_reg_ofs  = 0x800,
+   .slaves = 1,
+   .slave_data = &cpsw_slave,
+   .ale_reg_ofs= 0xd00,
+   .ale_entries= 1024,
+   .host_port_reg_ofs  = 0x108,
+   .hw_stats_reg_ofs   = 0x900,
+   .bd_ram_ofs = 0x2000,
+   .mac_control= (1 << 5),
+   .control= cpsw_control,
+   .host_port_num  = 0,
+   .version= CPSW_CTRL_VERSION_2,
+};
+
+/* PHY reset GPIO */
+#define GPIO_PHY_RST   GPIO_PIN(3, 7)
+
+static void board_phy_init(void)
+{
+   gpio_request(GPIO_PHY_RST, "phy_rst");
+   gpio_direction_output(GPIO_PHY_RST, 0);
+   mdelay(2);
+   gpio_set_value(GPIO_PHY_RST, 1);
+   mdelay(2);
+}
+
+static void get_efuse_mac_addr(uchar *enetaddr)
+{
+   uint32_t mac_hi, mac_lo;
+   struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
+
+   mac_lo = readl(&cdev->macid

[U-Boot] [PATCH 3/3] cm_t335: add support for pca9555 i2c gpio extender

[Ilya Ledvich]

Add support for the 16 bits pca9555 i2c to gpio extender featured
by the SB-T335 baseboard.

Signed-off-by: Ilya Ledvich 
Signed-off-by: Igor Grinberg 
---
 include/configs/cm_t335.h |   12 
 1 file changed, 12 insertions(+)

diff --git a/include/configs/cm_t335.h b/include/configs/cm_t335.h
index fbdead2..56e9a8e 100644
--- a/include/configs/cm_t335.h
+++ b/include/configs/cm_t335.h
@@ -166,5 +166,17 @@
 #define STATUS_LED_PERIOD  (CONFIG_SYS_HZ / 2)
 #define STATUS_LED_BOOT0
 
+#ifndef CONFIG_SPL_BUILD
+/*
+ * Enable PCA9555 at I2C0-0x26.
+ * First select the I2C0 bus with "i2c dev 0", then use "pca953x" command.
+ */
+#define CONFIG_PCA953X
+#define CONFIG_CMD_PCA953X
+#define CONFIG_CMD_PCA953X_INFO
+#define CONFIG_SYS_I2C_PCA953X_ADDR0x26
+#define CONFIG_SYS_I2C_PCA953X_WIDTH   { {0x26, 16} }
+#endif /* CONFIG_SPL_BUILD */
+
 #endif /* __CONFIG_CM_T335_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] A question about unconfigured pads check in omap24xx_i2c

[Lubomir Popov]

Hi Heiko,

On 07-Nov-13 7:14, Heiko Schocher wrote:

Hello Lubomir,

Am 06.11.2013 14:19, schrieb Lubomir Popov:

On 06-Nov-13 14:12, Nikita Kiryanov wrote:

In drivers/i2c/omap24xx_i2c.c there are a few checks that attempt to
detect unconfigured pads for the i2c bus in use. These checks are
all in the form of

if (status == I2C_STAT_XRDY) {
printf("unconfigured pads\n");
return -1;
}

This check seems peculiar to me since the meaning of I2C_STAT_XRDY is
that new data is requested for transmission. Why is that indication 
that

the bus is not padconf'd for I2C?

Hi Nikita,

This has been empirically confirmed on OMAP4 and OMAP5. When the pads 
are not
configured, the I2C controller is actually disconnected from the bus. 
The clock
input for its state machine has to come from the bus however due to 
stretching
etc., although it is internally generated. So actually nothing 
changes within
the controller after a transaction attempt is made, and it keeps its 
initial
state with XRDY set only (ready to accept transmit data). I use this 
as an

indicator. Not perfect, but works in most cases.


Thanks for this explanation! Maybe we can document this somewhere in
the code?

bye,
Heiko

You are right, it would be good to document it. Unfortunately I have not
been on the U-Boot wave for some months now due to very heavy engagement
with other stuff; have even unsubscribed from the list. I think however
that in order to give definite statements and improve the driver, a new
round of experiments has to be made to cover the two major types of design
flaws (software and/or hardware): incorrect pad configuration, and missing
pullups (internal or external). I wrote this driver more that 6 months ago
with the goal to have something working properly (the then existing one was,
mildly put, not good), and this detection is just a bonus side effect.

In summary, the professional approach would require some more effort, which
I'm not sure when I could afford. Otherwise, if just an explanation for the
current algo is to be given, no problem - I can just add some comments.

What do you think?

Regards,
Lubo

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