Re: [U-Boot] [PATCH] Exynos5250: Enable PXE Support

[Chander Kashyap]

ping

On 5 September 2012 16:08, Chander Kashyap  wrote:
> Add PXE support for the Exynos5250.
>
> Signed-off-by: Chander Kashyap 
> ---
>  include/configs/smdk5250.h |6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
> index 27dab76..2029ad3 100644
> --- a/include/configs/smdk5250.h
> +++ b/include/configs/smdk5250.h
> @@ -216,6 +216,12 @@
>  #define CONFIG_ENV_SROM_BANK   1
>  #endif /*CONFIG_CMD_NET*/
>
> +/* Enable PXE Support */
> +#ifdef CONFIG_CMD_NET
> +#define CONFIG_CMD_PXE
> +#define CONFIG_MENU
> +#endif
> +
>  /* Enable devicetree support */
>  #define CONFIG_OF_LIBFDT
>
> --
> 1.7.9.5
>



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

Re: [U-Boot] [PATCH 13/71] serial: microblaze: Move serial registration from serial_initialize()

[Michal Simek]

On 09/17/2012 01:20 AM, Marek Vasut wrote:

Move the registration of xuartlite_serialN_device ports from
default serial_initialize() into driver specific function called from
serial_initialize(). This slims down the serial_initialize() call
to a bare tracker of all possible serial port registration routines
in U-Boot.

The newly implemented xuartlite_serial_initialize() function, which is
implemented inside of the serial_xuartlite driver allows encapsulation
of xuartlite_serialN_device within the serial_xuartlite driver itself.

Also, remove the exports of xuartlite_serialN_device from include/serial.h
as they are no longer needed. This is simply because the implementation of
default_serial_console() is wrapped into the serial_xuartlite driver and
the default console is picked by CONFIG_SERIAL macro in config file.

Signed-off-by: Marek Vasut 
Cc: Marek Vasut 
Cc: Tom Rini 
Cc: Michal Simek 
---
  common/serial.c   |   16 ++--
  drivers/serial/serial_xuartlite.c |   16 
  include/serial.h  |7 ---
  3 files changed, 18 insertions(+), 21 deletions(-)

diff --git a/common/serial.c b/common/serial.c
index c021c3f..e19a17f 100644
--- a/common/serial.c
+++ b/common/serial.c
@@ -44,6 +44,7 @@ serial_initfunc(mpc8xx_serial_initialize);
  serial_initfunc(pxa_serial_initialize);
  serial_initfunc(s3c24xx_serial_initialize);
  serial_initfunc(s5p_serial_initialize);
+serial_initfunc(uartlite_serial_initialize);

  void serial_register(struct serial_device *dev)
  {
@@ -97,20 +98,7 @@ void serial_initialize(void)
  #if defined(CONFIG_SYS_BFIN_UART)
serial_register_bfin_uart();
  #endif
-#if defined(CONFIG_XILINX_UARTLITE)
-# ifdef XILINX_UARTLITE_BASEADDR
-   serial_register(&uartlite_serial0_device);
-# endif /* XILINX_UARTLITE_BASEADDR */
-# ifdef XILINX_UARTLITE_BASEADDR1
-   serial_register(&uartlite_serial1_device);
-# endif /* XILINX_UARTLITE_BASEADDR1 */
-# ifdef XILINX_UARTLITE_BASEADDR2
-   serial_register(&uartlite_serial2_device);
-# endif /* XILINX_UARTLITE_BASEADDR2 */
-# ifdef XILINX_UARTLITE_BASEADDR3
-   serial_register(&uartlite_serial3_device);
-# endif /* XILINX_UARTLITE_BASEADDR3 */
-#endif /* CONFIG_XILINX_UARTLITE */
+   uartlite_serial_initialize();
serial_assign(default_serial_console()->name);
  }

diff --git a/drivers/serial/serial_xuartlite.c 
b/drivers/serial/serial_xuartlite.c
index 2b869c1..d90c42d 100644
--- a/drivers/serial/serial_xuartlite.c
+++ b/drivers/serial/serial_xuartlite.c
@@ -177,4 +177,20 @@ __weak struct serial_device *default_serial_console(void)
return &uartlite_serial3_device;
  # endif /* XILINX_UARTLITE_BASEADDR3 */
  }
+
+void uartlite_serial_initialize(void)
+{
+#ifdef XILINX_UARTLITE_BASEADDR
+   serial_register(&uartlite_serial0_device);
+#endif /* XILINX_UARTLITE_BASEADDR */
+#ifdef XILINX_UARTLITE_BASEADDR1
+   serial_register(&uartlite_serial1_device);
+#endif /* XILINX_UARTLITE_BASEADDR1 */
+#ifdef XILINX_UARTLITE_BASEADDR2
+   serial_register(&uartlite_serial2_device);
+#endif /* XILINX_UARTLITE_BASEADDR2 */
+#ifdef XILINX_UARTLITE_BASEADDR3
+   serial_register(&uartlite_serial3_device);
+#endif /* XILINX_UARTLITE_BASEADDR3 */
+}
  #endif /* CONFIG_SERIAL_MULTI */
diff --git a/include/serial.h b/include/serial.h
index 08a9287..73991a6 100644
--- a/include/serial.h
+++ b/include/serial.h
@@ -49,13 +49,6 @@ extern struct serial_device serial4_device;
  extern struct serial_device serial6_device;
  #endif

-#if defined(CONFIG_XILINX_UARTLITE)
-extern struct serial_device uartlite_serial0_device;
-extern struct serial_device uartlite_serial1_device;
-extern struct serial_device uartlite_serial2_device;
-extern struct serial_device uartlite_serial3_device;
-#endif
-
  #if defined(CONFIG_OMAP3_ZOOM2)
  extern struct serial_device zoom2_serial_device0;
  extern struct serial_device zoom2_serial_device1;



Acked-by: Michal Simek 

Thanks,
Michal


--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 03/71] serial: Properly spell out the structure member names of serial_driver

[Michal Simek]

On 09/17/2012 01:20 AM, Marek Vasut wrote:

Properly spell out the whole structure member names when an initialized
varible is instantiated from the struct serial_driver. In case the
structure definition for struct serial_driver undergoes reordering,
there will be no impact on variables defined based on this structure.

Signed-off-by: Marek Vasut 
Cc: Marek Vasut 
Cc: Tom Rini 
Cc: Anatolij Gustschin 
Cc: Stefan Roese 
Cc: Mike Frysinger 
Cc: C Nauman 
Cc: Minkyu Kang 
Cc: Michal Simek 
---
  arch/powerpc/cpu/mpc512x/serial.c  |   18 +-
  arch/powerpc/cpu/mpc5xxx/serial.c  |   32 
  arch/powerpc/cpu/mpc8xx/serial.c   |   32 
  board/logicpd/zoom2/zoom2_serial.h |   16 
  drivers/serial/serial.c|   19 ++-
  drivers/serial/serial_pxa.c|   16 
  drivers/serial/serial_s3c24x0.c|   18 +-
  drivers/serial/serial_s5p.c|   19 ++-
  drivers/serial/serial_xuartlite.c  |   19 ++-
  9 files changed, 96 insertions(+), 93 deletions(-)


Uartlite part looks good to me.
Acked-by: Michal Simek 

Thanks,
Michal


--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] common/i2c: Add i2c write command

[York Sun]

On 09/17/2012 06:36 PM, Tom Rini wrote:

On Mon, Sep 17, 2012 at 11:29:00PM +, sun york-R58495 wrote:


Tom,

It's like eeprom write but it writes to general devices, not specificly to 
system eeprom. I would have to use i2c mw command a lot without this.


Right.  I guess what I'm getting at is, are you writing to some sort
of other device or writing bits to storage attached to i2c?  Does it
really not make sense to just use 'eeprom write' even if it's not
technically for The System EEPROM but rather some storage (or a number
of storage chips) attached via i2c?

I'm not objecting to i2c write mind you, I was wishing for something
like this when I stumbled on CONFIG_CMD_EEPROM which did what I needed.



Tom,

I have a case under debugging where I need to use i2c write to devices. 
One device (EEPROM) has two-byte address length and most others 
(including other EEPROMs) have one byte address length. I also have 
other non-storage devices but I wouldn't use "i2c write" because "i2c 
mw" will be sufficient. eeprom command has its limitation for the case 
of variable device address and variable address length.


York


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

[U-Boot] [PATCH] board/freescale/common:QIXIS:Fix magic number usage

[Prabhakar Kushwaha]

QIXIS FPGA layout defines the  address of registers but The actual register bit
implementation is board-specific,

So avoid use of magic numbers as it may vary across different boards's QIXIS
FPGA implementation.
Also, Avoid board specific defines in common/qixis.h

Signed-off-by: Prabhakar Kushwaha 
---
 Based upon git://git.denx.de/u-boot.git branch master

 board/freescale/common/qixis.c |   13 +++--
 board/freescale/common/qixis.h |6 --
 2 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/board/freescale/common/qixis.c b/board/freescale/common/qixis.c
index 6cd7e51..e336b32 100644
--- a/board/freescale/common/qixis.c
+++ b/board/freescale/common/qixis.c
@@ -32,22 +32,22 @@ void qixis_write(unsigned int reg, u8 value)
 
 void qixis_reset(void)
 {
-   QIXIS_WRITE(rst_ctl, 0x83);
+   QIXIS_WRITE(rst_ctl, QIXIS_RST_CTL_RESET);
 }
 
 void qixis_bank_reset(void)
 {
-   QIXIS_WRITE(rcfg_ctl, 0x20);
-   QIXIS_WRITE(rcfg_ctl, 0x21);
+   QIXIS_WRITE(rcfg_ctl, QIXIS_RCFG_CTL_RECONFIG_IDLE);
+   QIXIS_WRITE(rcfg_ctl, QIXIS_RCFG_CTL_RECONFIG_START);
 }
 
-/* Set the boot bank to the power-on default bank0 */
+/* Set the boot bank to the power-on default bank */
 void clear_altbank(void)
 {
u8 reg;
 
reg = QIXIS_READ(brdcfg[0]);
-   reg = reg & ~QIXIS_LBMAP_MASK;
+   reg = (reg & ~QIXIS_LBMAP_MASK) | QIXIS_LBMAP_DFLTBANK;
QIXIS_WRITE(brdcfg[0], reg);
 }
 
@@ -115,7 +115,8 @@ int qixis_reset_cmd(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
for (i = 0; i < ARRAY_SIZE(period); i++) {
if (strcmp(argv[2], period[i]) == 0) {
/* disable watchdog */
-   QIXIS_WRITE(rcfg_ctl, rcfg & ~0x08);
+   QIXIS_WRITE(rcfg_ctl,
+   rcfg & ~QIXIS_RCFG_CTL_WATCHDOG_ENBLE);
QIXIS_WRITE(watch, ((i<<2) - 1));
QIXIS_WRITE(rcfg_ctl, rcfg);
return 0;
diff --git a/board/freescale/common/qixis.h b/board/freescale/common/qixis.h
index 7a0268a..83a3b69 100644
--- a/board/freescale/common/qixis.h
+++ b/board/freescale/common/qixis.h
@@ -86,12 +86,6 @@ struct qixis {
u8 res15[16];
 };
 
-#define QIXIS_BASE 0xffdf
-#define QIXIS_LBMAP_SWITCH 7
-#define QIXIS_LBMAP_MASK   0x0f
-#define QIXIS_LBMAP_SHIFT  0
-#define QIXIS_LBMAP_ALTBANK0x04
-
 u8 qixis_read(unsigned int reg);
 void qixis_write(unsigned int reg, u8 value);
 
-- 
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] mx51evk: Add CONFIG_REVISION_TAG

[Fabio Estevam]

Hi Benoît ,

On Mon, Sep 17, 2012 at 4:04 PM, Benoît Thébaudeau
 wrote:

> +u32 get_board_rev(void)
> +{
> +   return get_cpu_rev();
> +}

Is this enough?  Looking at FSL U-boot there is also a:

static inline void set_board_rev(void)
{
if ((__REG(GPIO1_BASE_ADDR + 0x0) & (0x1 << 22)) == 0)
system_rev |= BOARD_REV_2_0 << BOARD_VER_OFFSET;

}

On mx53loco I had very weird problems when kernel was running and it
took me sometime to find out that it was due to wrong detection of the
board revision, so I suggest to double check this to avoid this kind
of problem on mx51evk too.

Regards,

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

Re: [U-Boot] [GIT PULL] mpc83xx: mpc8308rdb enhancements

[Ira W. Snyder]

On Mon, Sep 17, 2012 at 06:18:12PM -0700, Tom Rini wrote:
> On Mon, Sep 17, 2012 at 06:36:56PM -0500, Kim Phillips wrote:
> > Hi Tom,
> > 
> > Ira improved mpc8308rdb h/w support by making it more comprehensive.
> > Please pull:
> > 
> > The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721:
> > 
> >   Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 
> > 09:17:27 +0200)
> > 
> > are available in the git repository at:
> > 
> > 
> >   git://git.denx.de/u-boot-mpc83xx.git master
> > 
> > for you to fetch changes up to 014d1dfc669ab2295d7fa4ec4b9f00a4004917a0:
> > 
> >   mpc8308rdb: add support for eSDHC MMC controller (2012-09-17 17:47:12 
> > -0500)
> > 
> > 
> > Ira W. Snyder (5):
> >   mpc8xxx_spi: fix SPI support on MPC8308RDB
> >   mpc8308rdb: add support for Spansion SPI flash on header J8
> >   spansion: add support for S25FL256S1
> >   mpc8308rdb: add support for FIT images
> >   mpc8308rdb: add support for eSDHC MMC controller
> > 
> >  board/freescale/mpc8308rdb/mpc8308rdb.c | 58 
> > +
> >  drivers/mtd/spi/spansion.c  |  8 +
> >  drivers/spi/mpc8xxx_spi.c   |  4 +++
> >  include/configs/MPC8308RDB.h| 31 ++
> >  4 files changed, 101 insertions(+)
> 
> A number of boards (P2020RDB-PC_36BIT is the one I looked at the log in)
> now fail:
> spansion.c:74:3: error: unknown field 'page_size' specified in
> initializer
> 
> Rejected, please fix, sorry.
> 
> -- 
> Tom

Tom,

Go ahead and drop the patch "spansion: add support for S25FL256S1" from
the series. The rest should apply without any trouble.

Michal Simek beat me to it in "sf: spansion: Add support for S25FL256S"
(4a4cb4e1114). He got the idcode1 wrong (it should be 0x0219 instead of
0x2019), but I saw a followup patch on the mailing list to fix it.

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

Re: [U-Boot] [PATCH] video: cfb_console: flush dcache for frame buffer in DRAM

[Eric Nelson]

Hi Anatolij,

I hate to come in late to the discussion, but while testing [1] with cache 
enabled, I started down the path of fixing up code paths within 
drivers/video/cfb_console.c that are followed by SABRE Lite as you did in [2].


[1] [PATCH V2 0/2] i.MX6: mx6qsabrelite: Add splash screen  support
http://lists.denx.de/pipermail/u-boot/2012-September/134241.html
[2] [PATCH] video: cfb_console: flush dcache for frame buffer in DRAM
http://lists.denx.de/pipermail/u-boot/2012-April/12.html

That code essentially looks like this:

void video_drawchars(...)
{
...
   switch (VIDEO_DATA_FORMAT) {
 case GDF__8BIT_INDEX:
 case GDF__8BIT_332RGB:
 case GDF_15BIT_555RGB:
 case GDF_16BIT_565RGB:
... cache not flushed in these cases

 case GDF_32BIT_X888RGB:
... cache is flushed here
}

SABRE Lite (ipu3) code happens to use the RGB565 frame buffer format, so
it needs additional fixup.

Continuing this pattern seems to be a mistake though. There are a lot of
cases, with all sorts of different alignments (most of which won't sync
with cache line boundaries) and it seems that there's little to no
benefit in the fine granularity. It seems that by the time we fix up all
of the individual spots where we're writing to a line in the frame
buffer, the cache can never get dirty in the first place.

It seems much more sensible to simply use flush_dcache_range() on the
entire frame buffer in each of the public calls and let the MMU figure
out what needs flushing.

Is there something I'm missing?

My other immediate thought was that we should really place the frame buffer
in un-cacheable memory, but then we really will be doing more memory accesses.

Please advise,


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

Re: [U-Boot] [PATCH] gpio:fix: Proper handling of GPIO subsystem parts at Samsung devices

[Minkyu Kang]

Dear Lukasz Majewski,

On 13 September 2012 22:45, Lukasz Majewski  wrote:
> Hi Minkyu,
>
>> Now proper GPIO parts numbering is handled at Samsung devices.
>> This fix is necessary for code using GPIO located at other banks
>> than first.
>>
>> Test HW:
>> - Exynos4210 - Trats
>> - S5PC110 - goni
>>
>> Signed-off-by: Lukasz Majewski 
>> Signed-off-by: Kyungmin Park 
>> Cc: Minkyu Kang 
>> ---
>>  arch/arm/include/asm/arch-exynos/gpio.h  |   19 +++
>>  arch/arm/include/asm/arch-s5pc1xx/gpio.h |7 ++-
>>  drivers/gpio/s5p_gpio.c  |6 --
>>  3 files changed, 29 insertions(+), 3 deletions(-)
>>

applied to u-boot-samsung.

Thanks.
Minkyu Kang.
-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 12/71] serial: s5p: Move serial registration from serial_initialize()

[Minkyu Kang]

Dear Marek,

On 17 September 2012 08:20, Marek Vasut  wrote:
> Move the registration of s5p_serialN_device ports from default
> serial_initialize() into driver specific function called from
> serial_initialize(). This slims down the serial_initialize() call
> to a bare tracker of all possible serial port registration routines
> in U-Boot.
>
> The newly implemented s5p_serial_initialize() function, which is
> implemented inside of the serial_s5p driver allows encapsulation
> of s5p_serialN_device within the serial_s5p driver itself.
>
> Also, remove the exports of s5p_serialN_device from include/serial.h
> as they are no longer needed. This is simply because the implementation of
> default_serial_console() is wrapped into the serial_s5p driver and
> the default console is picked by CONFIG_SERIAL macro in config file.
>
> Signed-off-by: Marek Vasut 
> Cc: Marek Vasut 
> Cc: Tom Rini 
> Cc: Minkyu Kang 
> ---
>  common/serial.c |8 ++--
>  drivers/serial/serial_s5p.c |8 
>  include/serial.h|7 ---
>  3 files changed, 10 insertions(+), 13 deletions(-)
>
>

Acked-by: Minkyu Kang 

Thanks.
Minkyu Kang.
-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 47/71] serial: arm: Implement CONFIG_SERIAL_MULTI into s3c64xx serial driver

[Minkyu Kang]

On 17 September 2012 08:21, Marek Vasut  wrote:
> Implement support for CONFIG_SERIAL_MULTI into s3c64xx serial driver.
> This driver was so far only usable directly, but this patch also adds
> support for the multi method. This allows using more than one serial
> driver alongside the s3c64xx driver. Also, add a weak implementation
> of default_serial_console() returning this driver.
>
> Signed-off-by: Marek Vasut 
> Cc: Marek Vasut 
> Cc: Tom Rini 
> Cc: John Rigby 
> Cc: Minkyu Kang 
> ---
>  common/serial.c  |2 ++
>  drivers/serial/s3c64xx.c |   65 
> +-
>  2 files changed, 61 insertions(+), 6 deletions(-)
>

Acked-by: Minkyu Kang 

Thanks.
--
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request: nand flash

[Scott Wood]

The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721:

  Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 09:17:27 
+0200)

are available in the git repository at:


  git://git.denx.de/u-boot-nand-flash.git master

for you to fetch changes up to 9c60e75e05dab5a0197728b6a940aaac02762936:

  mxc nand: Homogenize IP revisions with Linux (2012-09-17 19:51:45 -0500)


Benoît Thébaudeau (12):
  mxc nand: Merge mtd and spl register definitions
  mxc nand: cosmectic: Light cleanup
  spl mxc nand: Merge duplicated code
  spl mxc nand: Remove duplicated code
  spl mxc nand: Set symmetric mode
  mxc nand: Access all ecc_status_result fields
  spl mxc nand: Fix broken boot for correctable ECC errors
  mtd mxc nand: Use _mxc_nand_enable_hwecc()
  mtd mxc nand: Fix ECC state after read_page_raw_syndrome()
  mtd mxc nand: Merge init functions
  mxc nand: Let driver detect IP revision
  mxc nand: Homogenize IP revisions with Linux

Joe Hershberger (4):
  nand: Add support for unlock.invert
  nand: Change ulong to loff_t and size_t
  nand: consolidate duplicated constants
  nand: Make NAND lock status compatible with Micron

Marek Vasut (1):
  mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver

Matthieu CASTET (1):
  mtd: support ONFI multi lun NAND

 common/cmd_nand.c|   21 ++-
 doc/README.nand  |2 +
 drivers/mtd/nand/mxc_nand.c  |  335 +++---
 drivers/mtd/nand/nand_base.c |   10 +-
 drivers/mtd/nand/nand_util.c |   26 ++--
 include/configs/flea3.h  |1 -
 include/configs/mx35pdk.h|1 -
 include/configs/tx25.h   |1 -
 include/fsl_nfc.h|  113 +++---
 include/linux/mtd/nand.h |5 +-
 include/nand.h   |6 +-
 nand_spl/nand_boot_fsl_nfc.c |  121 ---
 12 files changed, 251 insertions(+), 391 deletions(-)

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

Re: [U-Boot] [PATCH 00/13] mxc nand: Add support for i.MX5

[Scott Wood]

On Mon, Aug 13, 2012 at 10:47:56PM +0200, Benoît Thébaudeau wrote:
> Hi all,
> 
> This series aims at adding support for i.MX5 to the mxc nand mtd and spl
> drivers. It also fixes several issues and cleans up the code a little bit.

Applied patches 1-12 to u-boot-nand-flash.  For patch 13 I'm waiting to
see what Tom says, and for an answer regarding what board uses this (i.e.
how can I build-test it?).

-Scott

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

Re: [U-Boot] [GIT PULL] mpc83xx: mpc8308rdb enhancements

[Tom Rini]

On Mon, Sep 17, 2012 at 06:36:56PM -0500, Kim Phillips wrote:
> Hi Tom,
> 
> Ira improved mpc8308rdb h/w support by making it more comprehensive.
> Please pull:
> 
> The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 
> 09:17:27 +0200)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-mpc83xx.git master
> 
> for you to fetch changes up to 014d1dfc669ab2295d7fa4ec4b9f00a4004917a0:
> 
>   mpc8308rdb: add support for eSDHC MMC controller (2012-09-17 17:47:12 -0500)
> 
> 
> Ira W. Snyder (5):
>   mpc8xxx_spi: fix SPI support on MPC8308RDB
>   mpc8308rdb: add support for Spansion SPI flash on header J8
>   spansion: add support for S25FL256S1
>   mpc8308rdb: add support for FIT images
>   mpc8308rdb: add support for eSDHC MMC controller
> 
>  board/freescale/mpc8308rdb/mpc8308rdb.c | 58 
> +
>  drivers/mtd/spi/spansion.c  |  8 +
>  drivers/spi/mpc8xxx_spi.c   |  4 +++
>  include/configs/MPC8308RDB.h| 31 ++
>  4 files changed, 101 insertions(+)

A number of boards (P2020RDB-PC_36BIT is the one I looked at the log in)
now fail:
spansion.c:74:3: error: unknown field 'page_size' specified in
initializer

Rejected, please fix, sorry.

-- 
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] net: sh_eth: Add support R8A7740 of rmobile (arm core)

[Nobuhiro Iwamatsu]

Hi, Joe.

Could you pick this patch to your repository?

Best regards,
  Nobuhiro

On Fri, Aug 3, 2012 at 5:08 PM, Nobuhiro Iwamatsu
 wrote:
> R8A7740 of rmobile has ethernet device, and this is same IP of
> sh-ether. This support R8A7740 of rmobile.
>
> Signed-off-by: Hideyuki Sano 
> Signed-off-by: Nobuhiro Iwamatsu 
> ---
>  drivers/net/sh_eth.c |2 +-
>  drivers/net/sh_eth.h |   14 --
>  2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
> index 09af860..2d9cc32 100644
> --- a/drivers/net/sh_eth.c
> +++ b/drivers/net/sh_eth.c
> @@ -394,7 +394,7 @@ static int sh_eth_config(struct sh_eth_dev *eth, bd_t *bd)
> sh_eth_write(eth, TPAUSER_TPAUSE, TPAUSER);
>  #endif
>
> -#if defined(CONFIG_CPU_SH7734)
> +#if defined(CONFIG_CPU_SH7734) || defined(CONFIG_R8A7740)
> sh_eth_write(eth, CONFIG_SH_ETHER_SH7734_MII, RMII_MII);
>  #endif
> /* Configure phy */
> diff --git a/drivers/net/sh_eth.h b/drivers/net/sh_eth.h
> index 3703c55..61d2df9 100644
> --- a/drivers/net/sh_eth.h
> +++ b/drivers/net/sh_eth.h
> @@ -1,8 +1,8 @@
>  /*
>   * sh_eth.h - Driver for Renesas SuperH ethernet controler.
>   *
> - * Copyright (C) 2008, 2011 Renesas Solutions Corp.
> - * Copyright (c) 2008, 2011 Nobuhiro Iwamatsu
> + * Copyright (C) 2008 - 2012 Renesas Solutions Corp.
> + * Copyright (c) 2008 - 2012 Nobuhiro Iwamatsu
>   * Copyright (c) 2007 Carlos Munoz 
>   *
>   * This program is free software; you can redistribute it and/or modify
> @@ -25,6 +25,7 @@
>
>  #define SHETHER_NAME "sh_eth"
>
> +#if defined(CONFIG_SH)
>  /* Malloc returns addresses in the P1 area (cacheable). However we need to
> use area P2 (non-cacheable) */
>  #define ADDR_TO_P2(addr)   int)(addr) & ~0xe000) | 0xa000))
> @@ -35,6 +36,12 @@
>  #else
>  #define ADDR_TO_PHY(addr)  ((int)(addr) & ~0xe000)
>  #endif
> +#elif defined(CONFIG_ARM)
> +#define inlreadl
> +#define outl   writel
> +#define ADDR_TO_PHY(addr)  ((int)(addr))
> +#define ADDR_TO_P2(addr)   (addr)
> +#endif /* defined(CONFIG_SH) */
>
>  /* Number of supported ports */
>  #define MAX_PORT_NUM   2
> @@ -292,6 +299,9 @@ static const u16 
> sh_eth_offset_fast_sh4[SH_ETH_MAX_REGISTER_OFFSET] = {
>  #elif defined(CONFIG_CPU_SH7724)
>  #define SH_ETH_TYPE_ETHER
>  #define BASE_IO_ADDR   0xA460
> +#elif defined(CONFIG_R8A7740)
> +#define SH_ETH_TYPE_GETHER
> +#define BASE_IO_ADDR   0xE9A0
>  #endif
>
>  /*
> --
> 1.7.10
>



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sh: ap_sh4a_4a: Fixed initialization value of DDR memory

[Nobuhiro Iwamatsu]

Appled, thanks.

Best regards,
  NObuhiro

On Thu, Sep 6, 2012 at 9:36 AM, Nobuhiro Iwamatsu
 wrote:
> The wrong value was set as value of column of DDR memory for ap_sh4a_4a.
> 10 is the right value. This fixed this problem.
>
> Signed-off-by: Nobuhiro Iwamatsu 
> ---
>  board/alphaproject/ap_sh4a_4a/lowlevel_init.S |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/alphaproject/ap_sh4a_4a/lowlevel_init.S 
> b/board/alphaproject/ap_sh4a_4a/lowlevel_init.S
> index f04b36b..cf9c225 100644
> --- a/board/alphaproject/ap_sh4a_4a/lowlevel_init.S
> +++ b/board/alphaproject/ap_sh4a_4a/lowlevel_init.S
> @@ -330,7 +330,7 @@ init_dbsc3_ctrl_533:
>  DBKIND_A:  .long   0xFE800020
>  DBKIND_D:  .long   0x0005
>  DBCONF_A:  .long   0xFE800024
> -DBCONF_D:  .long   0x0D020901
> +DBCONF_D:  .long   0x0D020A01
>
>  DBTR0_A:   .long   0xFE800040
>  DBTR0_D_533:.long  0x0004
> --
> 1.7.10.4
>



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 13/13] mxc nand: Add support for i.MX5

[Scott Wood]

On Tue, Aug 21, 2012 at 11:04:14PM +0200, Benoît Thébaudeau wrote:
> Signed-off-by: Benoît Thébaudeau 
> Cc: Scott Wood 
> Cc: Stefano Babic 
> ---
> Changes for v2:
>  - Fix warning for unused tmp variable in board_nand_init() for NFC V1.
> 
>  .../arch/arm/include/asm/arch-mx5/imx-regs.h   |9 +
>  .../drivers/mtd/nand/mxc_nand.c|  219 
> +++-
>  .../include/fsl_nfc.h  |  149 -
>  .../nand_spl/nand_boot_fsl_nfc.c   |  114 +++---
>  4 files changed, 365 insertions(+), 126 deletions(-)

Is there a board that uses this?

-Scott

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

Re: [U-Boot] [PATCH 61/71] serial: sh: Implement CONFIG_SERIAL_MULTI into sh serial driver

[Nobuhiro Iwamatsu]

On Mon, Sep 17, 2012 at 8:21 AM, Marek Vasut  wrote:
> Implement support for CONFIG_SERIAL_MULTI into sh serial driver.
> This driver was so far only usable directly, but this patch also adds
> support for the multi method. This allows using more than one serial
> driver alongside the sh driver. Also, add a weak implementation
> of default_serial_console() returning this driver.
>
> Signed-off-by: Marek Vasut 
> Cc: Marek Vasut 
> Cc: Tom Rini 
> Cc: Phil Edworthy 
> Cc: Nobuhiro Iwamatsu 

Acked-by: Nobuhiro Iwamatsu 

> ---
>  common/serial.c|2 ++
>  drivers/serial/serial_sh.c |   65 
> 
>  2 files changed, 61 insertions(+), 6 deletions(-)
>
> diff --git a/common/serial.c b/common/serial.c
> index 3dae01b..631af65 100644
> --- a/common/serial.c
> +++ b/common/serial.c
> @@ -91,6 +91,7 @@ serial_initfunc(netarm_serial_initialize);
>  serial_initfunc(pl01x_serial_initialize);
>  serial_initfunc(s3c44b0_serial_initialize);
>  serial_initfunc(sa1100_serial_initialize);
> +serial_initfunc(sh_serial_initialize);
>
>  void serial_register(struct serial_device *dev)
>  {
> @@ -160,6 +161,7 @@ void serial_initialize(void)
> pl01x_serial_initialize();
> s3c44b0_serial_initialize();
> sa1100_serial_initialize();
> +   sh_serial_initialize();
>
> serial_assign(default_serial_console()->name);
>  }
> diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
> index 13919c6..8c30397 100644
> --- a/drivers/serial/serial_sh.c
> +++ b/drivers/serial/serial_sh.c
> @@ -55,13 +55,13 @@ static struct uart_port sh_sci = {
> .type   = SCIF_BASE_PORT,
>  };
>
> -void serial_setbrg(void)
> +static void sh_serial_setbrg(void)
>  {
> DECLARE_GLOBAL_DATA_PTR;
> sci_out(&sh_sci, SCBRR, SCBRR_VALUE(gd->baudrate, 
> CONFIG_SYS_CLK_FREQ));
>  }
>
> -int serial_init(void)
> +static int sh_serial_init(void)
>  {
> sci_out(&sh_sci, SCSCR , SCSCR_INIT(&sh_sci));
> sci_out(&sh_sci, SCSCR , SCSCR_INIT(&sh_sci));
> @@ -127,21 +127,21 @@ void serial_raw_putc(const char c)
> sci_out(&sh_sci, SCxSR, sci_in(&sh_sci, SCxSR) & 
> ~SCxSR_TEND(&sh_sci));
>  }
>
> -void serial_putc(const char c)
> +static void sh_serial_putc(const char c)
>  {
> if (c == '\n')
> serial_raw_putc('\r');
> serial_raw_putc(c);
>  }
>
> -void serial_puts(const char *s)
> +static void sh_serial_puts(const char *s)
>  {
> char c;
> while ((c = *s++) != 0)
> serial_putc(c);
>  }
>
> -int serial_tstc(void)
> +static int sh_serial_tstc(void)
>  {
> return serial_rx_fifo_level() ? 1 : 0;
>  }
> @@ -167,7 +167,7 @@ int serial_getc_check(void)
> return status & (SCIF_DR | SCxSR_RDxF(&sh_sci));
>  }
>
> -int serial_getc(void)
> +static int sh_serial_getc(void)
>  {
> unsigned short status;
> char ch;
> @@ -187,3 +187,56 @@ int serial_getc(void)
> handle_error();
> return ch;
>  }
> +
> +#ifdef CONFIG_SERIAL_MULTI
> +static struct serial_device sh_serial_drv = {
> +   .name   = "sh_serial",
> +   .start  = sh_serial_init,
> +   .stop   = NULL,
> +   .setbrg = sh_serial_setbrg,
> +   .putc   = sh_serial_putc,
> +   .puts   = sh_serial_puts,
> +   .getc   = sh_serial_getc,
> +   .tstc   = sh_serial_tstc,
> +};
> +
> +void sh_serial_initialize(void)
> +{
> +   serial_register(&sh_serial_drv);
> +}
> +
> +__weak struct serial_device *default_serial_console(void)
> +{
> +   return &sh_serial_drv;
> +}
> +#else
> +int serial_init(void)
> +{
> +   return sh_serial_init();
> +}
> +
> +void serial_setbrg(void)
> +{
> +   sh_serial_setbrg();
> +}
> +
> +void serial_putc(const char c)
> +{
> +   sh_serial_putc(c);
> +}
> +
> +void serial_puts(const char *s)
> +{
> +   sh_serial_puts(s);
> +}
> +
> +int serial_getc(void)
> +{
> +   return sh_serial_getc();
> +}
> +
> +int serial_tstc(void)
> +{
> +   return sh_serial_tstc();
> +}
> +#endif
> --
> 1.7.10.4
>

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 10/10] i2c: sh_i2c: use setbits/clrbits macro

[Nobuhiro Iwamatsu]

On Fri, Sep 14, 2012 at 2:08 PM, Tetsuyuki Kobayashi  wrote:
> Use setbits/clrbits macro when read-modify-write register.
>
> Signed-off-by: Tetsuyuki Kobayashi 
> ---
> Changes for v3:
>  - new
>
>  drivers/i2c/sh_i2c.c |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/sh_i2c.c b/drivers/i2c/sh_i2c.c
> index afcb503..44ba90e 100644
> --- a/drivers/i2c/sh_i2c.c
> +++ b/drivers/i2c/sh_i2c.c
> @@ -98,8 +98,8 @@ static int i2c_set_addr(struct sh_i2c *base, u8 id, u8 reg, 
> int stop)
>  {
> u8 icic = SH_IC_TACK;
>
> -   writeb(readb(&base->iccr) & ~SH_I2C_ICCR_ICE, &base->iccr);
> -   writeb(readb(&base->iccr) | SH_I2C_ICCR_ICE, &base->iccr);
> +   clrbits_8(&base->iccr, SH_I2C_ICCR_ICE);
> +   setbits_8(&base->iccr, SH_I2C_ICCR_ICE);
>
> writeb(iccl & 0xff, &base->iccl);
> writeb(icch & 0xff, &base->icch);
> @@ -114,7 +114,7 @@ static int i2c_set_addr(struct sh_i2c *base, u8 id, u8 
> reg, int stop)
> writeb((SH_I2C_ICCR_ICE|SH_I2C_ICCR_RTS|SH_I2C_ICCR_BUSY), 
> &base->iccr);
> irq_dte(base);
>
> -   writeb(readb(&base->icsr) & ~SH_IC_TACK, &base->icsr);
> +   clrbits_8(&base->icsr, SH_IC_TACK);
> writeb(id << 1, &base->icdr);
> if (irq_dte_with_tack(base) != 0)
> return -1;
> @@ -131,7 +131,7 @@ static int i2c_set_addr(struct sh_i2c *base, u8 id, u8 
> reg, int stop)
>  static void i2c_finish(struct sh_i2c *base)
>  {
> writeb(0, &base->icsr);
> -   writeb(readb(&base->iccr) & ~SH_I2C_ICCR_ICE, &base->iccr);
> +   clrbits_8(&base->iccr, SH_I2C_ICCR_ICE);
>  }
>
>  static int i2c_raw_write(struct sh_i2c *base, u8 id, u8 reg, u8 val)
> --
> 1.7.9.5

Acked-by: Nobuhiro Iwamatsu 

Thanks!

Nobuhiro

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

Re: [U-Boot] [PATCH 06/13] mxc nand: Access all ecc_status_result fields

[Scott Wood]

On 09/17/2012 07:39:35 PM, Scott Wood wrote:

On Mon, Aug 13, 2012 at 10:49:42PM +0200, Benoît Thébaudeau wrote:
> On the NFC IP 1.1, the 32-bit ecc_status_result value comes from 2
> consecutive 16-bit registers. This patch reads all the fields of  
this value,

> which makes a difference for 4-kiB NF pages.
>
> Signed-off-by: Benoît Thébaudeau 
> Cc: Scott Wood 
> Cc: Stefano Babic 
> ---
>  .../drivers/mtd/nand/mxc_nand.c|2 +-
>  .../include/fsl_nfc.h  |3 +--
>  .../nand_spl/nand_boot_fsl_nfc.c   |4 
>  3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git u-boot-4d3c95f.orig/drivers/mtd/nand/mxc_nand.c  
u-boot-4d3c95f/drivers/mtd/nand/mxc_nand.c

> index 62d8c6b..4564b25 100644
> --- u-boot-4d3c95f.orig/drivers/mtd/nand/mxc_nand.c
> +++ u-boot-4d3c95f/drivers/mtd/nand/mxc_nand.c
> @@ -653,7 +653,7 @@ static int mxc_nand_correct_data(struct  
mtd_info *mtd, u_char *dat,

>  {
>struct nand_chip *nand_chip = mtd->priv;
>struct mxc_nand_host *host = nand_chip->priv;
> -  uint16_t ecc_status = readw(&host->regs->ecc_status_result);
> +  uint32_t ecc_status = readl(&host->regs->ecc_status_result);
>int subpages = mtd->writesize / nand_chip->subpagesize;
>int pg2blk_shift = nand_chip->phys_erase_shift -
>   nand_chip->page_shift;
> diff --git u-boot-4d3c95f.orig/include/fsl_nfc.h  
u-boot-4d3c95f/include/fsl_nfc.h

> index 1c16c71..c248cef 100644
> --- u-boot-4d3c95f.orig/include/fsl_nfc.h
> +++ u-boot-4d3c95f/include/fsl_nfc.h
> @@ -94,8 +94,7 @@ struct fsl_nfc_regs {
>u16 flash_addr;
>u16 flash_cmd;
>u16 config;
> -  u16 ecc_status_result;
> -  u16 ecc_status_result2;
> +  u32 ecc_status_result;
>u16 spare_area_size;
>u16 wrprot;
>u16 reserved3[2];
> diff --git u-boot-4d3c95f.orig/nand_spl/nand_boot_fsl_nfc.c  
u-boot-4d3c95f/nand_spl/nand_boot_fsl_nfc.c

> index 842943c..4c5a7fe 100644
> --- u-boot-4d3c95f.orig/nand_spl/nand_boot_fsl_nfc.c
> +++ u-boot-4d3c95f/nand_spl/nand_boot_fsl_nfc.c
> @@ -139,7 +139,11 @@ static void nfc_nand_data_output(void)
>
>  static int nfc_nand_check_ecc(void)
>  {
> +#if defined(MXC_NFC_V1)
>return readw(&nfc->ecc_status_result);
> +#elif defined(MXC_NFC_V1_1)
> +  return readl(&nfc->ecc_status_result);
> +#endif
>  }

On MXC_NFC_V1 you're using readw() on a u32 -- that's not OK, even if  
the
ARM accessors let you get away with it.  Use a union or #ifdef the  
struct
definition, or just always readl() if you can get away with it, or do  
two

readw()s on V1_1.


Never mind, didn't notice that the struct definition is under #ifdef  
MXC_NFC_V1_1.


The ARM accessors still should be fixed to do type checking...

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

Re: [U-Boot] [PATCH V2 2/2] i.MX6: mx6qsabrelite: Add splash screen support

[Eric Nelson]

On 09/17/2012 05:08 PM, Eric Nelson wrote:

Hi Fabio,

On 09/17/2012 04:43 PM, Fabio Estevam wrote:

Hi Eric,




+int board_late_init(void)
+{
+ setenv("stdout", "serial");
+ return 0;
+}


Please see my previous comment on v1 about this.

Wolfgang nacked this method and Stefano has proposed a nice way for
keeping the console in serial. Check mx53loco and mx51evk.



Thanks. I'll look into it.



Like this?
http://lists.denx.de/pipermail/u-boot/2012-August/129967.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 2/2] i.MX6: mx6qsabrelite: Add splash screen support

[Fabio Estevam]

On Mon, Sep 17, 2012 at 9:43 PM, Eric Nelson
 wrote:
> Like this?
> http://lists.denx.de/pipermail/u-boot/2012-August/129967.html

Yes, correct.

Regards,

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

Re: [U-Boot] [PATCH 06/13] mxc nand: Access all ecc_status_result fields

[Scott Wood]

On Mon, Aug 13, 2012 at 10:49:42PM +0200, Benoît Thébaudeau wrote:
> On the NFC IP 1.1, the 32-bit ecc_status_result value comes from 2
> consecutive 16-bit registers. This patch reads all the fields of this value,
> which makes a difference for 4-kiB NF pages.
> 
> Signed-off-by: Benoît Thébaudeau 
> Cc: Scott Wood 
> Cc: Stefano Babic 
> ---
>  .../drivers/mtd/nand/mxc_nand.c|2 +-
>  .../include/fsl_nfc.h  |3 +--
>  .../nand_spl/nand_boot_fsl_nfc.c   |4 
>  3 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git u-boot-4d3c95f.orig/drivers/mtd/nand/mxc_nand.c 
> u-boot-4d3c95f/drivers/mtd/nand/mxc_nand.c
> index 62d8c6b..4564b25 100644
> --- u-boot-4d3c95f.orig/drivers/mtd/nand/mxc_nand.c
> +++ u-boot-4d3c95f/drivers/mtd/nand/mxc_nand.c
> @@ -653,7 +653,7 @@ static int mxc_nand_correct_data(struct mtd_info *mtd, 
> u_char *dat,
>  {
>   struct nand_chip *nand_chip = mtd->priv;
>   struct mxc_nand_host *host = nand_chip->priv;
> - uint16_t ecc_status = readw(&host->regs->ecc_status_result);
> + uint32_t ecc_status = readl(&host->regs->ecc_status_result);
>   int subpages = mtd->writesize / nand_chip->subpagesize;
>   int pg2blk_shift = nand_chip->phys_erase_shift -
>  nand_chip->page_shift;
> diff --git u-boot-4d3c95f.orig/include/fsl_nfc.h 
> u-boot-4d3c95f/include/fsl_nfc.h
> index 1c16c71..c248cef 100644
> --- u-boot-4d3c95f.orig/include/fsl_nfc.h
> +++ u-boot-4d3c95f/include/fsl_nfc.h
> @@ -94,8 +94,7 @@ struct fsl_nfc_regs {
>   u16 flash_addr;
>   u16 flash_cmd;
>   u16 config;
> - u16 ecc_status_result;
> - u16 ecc_status_result2;
> + u32 ecc_status_result;
>   u16 spare_area_size;
>   u16 wrprot;
>   u16 reserved3[2];
> diff --git u-boot-4d3c95f.orig/nand_spl/nand_boot_fsl_nfc.c 
> u-boot-4d3c95f/nand_spl/nand_boot_fsl_nfc.c
> index 842943c..4c5a7fe 100644
> --- u-boot-4d3c95f.orig/nand_spl/nand_boot_fsl_nfc.c
> +++ u-boot-4d3c95f/nand_spl/nand_boot_fsl_nfc.c
> @@ -139,7 +139,11 @@ static void nfc_nand_data_output(void)
>  
>  static int nfc_nand_check_ecc(void)
>  {
> +#if defined(MXC_NFC_V1)
>   return readw(&nfc->ecc_status_result);
> +#elif defined(MXC_NFC_V1_1)
> + return readl(&nfc->ecc_status_result);
> +#endif
>  }

On MXC_NFC_V1 you're using readw() on a u32 -- that's not OK, even if the
ARM accessors let you get away with it.  Use a union or #ifdef the struct
definition, or just always readl() if you can get away with it, or do two
readw()s on V1_1.

-Scott

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

Re: [U-Boot] [PATCH v2 13/13] mxc nand: Add support for i.MX5

[Scott Wood]

On Tue, Aug 21, 2012 at 11:04:14PM +0200, Benoît Thébaudeau wrote:
> Signed-off-by: Benoît Thébaudeau 
> Cc: Scott Wood 
> Cc: Stefano Babic 
> ---
> Changes for v2:
>  - Fix warning for unused tmp variable in board_nand_init() for NFC V1.
> 
>  .../arch/arm/include/asm/arch-mx5/imx-regs.h   |9 +
>  .../drivers/mtd/nand/mxc_nand.c|  219 
> +++-
>  .../include/fsl_nfc.h  |  149 -
>  .../nand_spl/nand_boot_fsl_nfc.c   |  114 +++---
>  4 files changed, 365 insertions(+), 126 deletions(-)

Unless Tom or Wolfgang object, I'm inclined to drop the objection to
adding new hardware support to nand_spl in this case.  I'd rather see the
support be merged rather than ignored because a contributor has time for
a small job but not a large one.  Plus, this code will likely be reused
by the new SPL support, if this platform is space constrained, so it's
not dead-end effort.

It would be nice, though, if the writenfc/readnfc conversion, comment
reformatting, etc. were separate from the behavioral changes.

-Scott

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

Re: [U-Boot] [PATCH v6 3/4] OMAP: networking support for SPL

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/17/12 13:26, Ilya Yanok wrote:
> This patch adds support for networking in SPL. Some devices are 
> capable of loading SPL via network so it makes sense to load the 
> main U-Boot binary via network too. This patch tries to use 
> existing network code as much as possible. Unfortunately, it
> depends on environment which in turn depends on other code so SPL
> size is increased significantly. No effort was done to decouple
> network code and environment so far.
> 
> Signed-off-by: Ilya Yanok 
[snip]
> diff --git a/include/config_uncmd_spl.h
> b/include/config_uncmd_spl.h new file mode 100644 index
> 000..8ad6045 --- /dev/null +++ b/include/config_uncmd_spl.h @@
> -0,0 +1,24 @@ +/* + * We don't use any commands in SPL, but generic
> networking code + * has some features enabled/disabled based on
> CONFIG_CMD_* + * options. As we want a minimal set of features
> included + * into network SPL image, we undefine some config
> options here. + */ + +#ifndef __CONFIG_UNCMD_SPL_H__ +#define
> __CONFIG_UNCMD_SPL_H__ + +#ifdef CONFIG_SPL_BUILD +/* SPL needs
> only BOOTP + TFTP so undefine other stuff to save space */ +#undef
> CONFIG_CMD_CDP +#undef CONFIG_CMD_DHCP +#undef CONFIG_CMD_DNS 
> +#undef CONFIG_CMD_LINK_LOCAL +#undef CONFIG_CMD_NFS +#undef
> CONFIG_CMD_PING +#undef CONFIG_CMD_RARP +#undef CONFIG_CMD_SNTP 
> +#undef CONFIG_CMD_TFTPPUT +#undef CONFIG_CMD_TFTPSRV +#endif /*
> CONFIG_SPL_BUILD */ +#endif /* __CONFIG_UNCMD_SPL_H__ */

Please add a GPLv2+ header to the file, thanks.

> diff --git a/lib/vsprintf.c b/lib/vsprintf.c index e38a4b7..6bb819c
> 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -784,7 +784,7
> @@ void panic(const char *fmt, ...) vprintf(fmt, args); 
> putc('\n'); va_end(args); -#if defined (CONFIG_PANIC_HANG) +#if
> defined (CONFIG_PANIC_HANG) || defined(CONFIG_SPL_BUILD) hang(); 
> #else udelay (10);/* allow messages to go out */

Oh no, this change...  Do we still really need this?

> diff --git a/net/tftp.c b/net/tftp.c index 59a8ebb..baba8f3 100644 
> --- a/net/tftp.c +++ b/net/tftp.c @@ -7,6 +7,10 @@ */
> 
> #include  +#ifdef CONFIG_SPL_BUILD +#undef
> CONFIG_CMD_TFTPPUT +#undef CONFIG_CMD_TFTPSRV +#endif #include
>  #include  #include "tftp.h"

Missed this.

Also I saw a few manual inclusions of , please fix
those since mkconfig adds it always.  Thanks.

- -- 
Tom

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

iQIcBAEBAgAGBQJQV721AAoJENk4IS6UOR1WHnUP+wdiliv2T4GUH/Z39TYoW0uo
WqAREC3pHZ9YMYKSZgGGOHwlAOuk2az5GPAqiCaXLLIgx43h5tkQnjbBHlB0T9rv
R+uqy4LF0Lxyz86ITSf4nmpkn66gnd5L6ET2b46Siof+PFIzNLEnM0Z0sWpnsWAU
ZlKnwS/Y/VAKDiwW5rxWiXTbs1vMHn8BWU+wTVrMLE80Sm3yE/C5mpzOBl42+O+V
kmo/nUNIiTK4C8VmlvL7+w+mqMPDtB4nSFFmmjmH7z8991RBhLJ0Nmlg26wmtXDL
Vyy5Jg6SQRSuyDJFplvoPu7FVhgI2umRxOIl6SEONKzSQQSBQmMqtIZV4pW4hFVZ
3RO5wrr0RKpJJy4Izb2MoGqvUv4fDIK9K2xiQihBUkc4X7UCpPMMqBpLwKVSoIdW
1y7o+2LzUAlBU9q/nP+ZHBzZFL9jYZHEDaYkuY+MT7i+tLcW2T6dV0Q4KsXTwHhx
D9zbU6tEXbgRZr/n8gUMeSWu7r6F2tr3a4UiTMsAP8lkVyXUPmYnfUhpxQrUuIx/
yuGmpigYPNicvP1hiU/quX2Fxxx2kuy3gDLVIc7tZv0VSmW6NI+WZC8inGBhk4Bb
GsZaYkoZnv799Z7GJy8wqCszSqb4BmI9wB3Hzz49jiwurvz/n7tDKEOtjjcIWCZc
MXsKY53Ulu6dW0vk5qQK
=2lLS
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 2/2] i.MX6: mx6qsabrelite: Add splash screen support

[Eric Nelson]

Hi Fabio,

On 09/17/2012 04:43 PM, Fabio Estevam wrote:

Hi Eric,

On Mon, Sep 17, 2012 at 8:14 PM, Eric Nelson
  wrote:

Adds support for the Hannstar 1024 x 768 LVDS panel (Freescale part
number MCIMX-LVDS1) to SABRE-Lite board.

This commit is a rebase Fabio Estevan's patch from 5/31 to


s/Estevan/Estevam



Oops, sorry...


+int board_late_init(void)
+{
+   setenv("stdout", "serial");
+   return 0;
+}


Please see my previous comment on v1 about this.

Wolfgang nacked this method and Stefano has proposed a nice way for
keeping the console in serial. Check mx53loco and mx51evk.



Thanks. I'll look into it.

I'll also look into this:
http://lists.denx.de/pipermail/u-boot/2012-July/129556.html

Regards,


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

Re: [U-Boot] mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver

[Scott Wood]

On 09/17/2012 07:01:39 PM, Marek Vasut wrote:

Dear Scott Wood,

> On Thu, Aug 30, 2012 at 01:39:38PM -, Marek Vasut wrote:
> > This is based on Linux kernel -next:
> >
> > commit a1256b0e087ed3cdb584c683acb966ee885f733c
> > Author: Brian Norris 
> > Date:   Fri Jul 13 09:28:24 2012 -0700
> >
> > mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver
> >
> > The NAND_CHIPOPTIONS_MSK has limited utility and is causing  
real
> > bugs. It silently masks off at least one flag that might be  
set by
> > the driver (NAND_NO_SUBPAGE_WRITE). This breaks the GPMI NAND  
driver

> > and possibly others.
> >
> > Really, as long as driver writers exercise a small amount of  
care
> > with NAND_* options, this mask is not necessary at all; it  
was only
> > here to prevent certain options from accidentally being set  
by the

> > driver. But the original thought turns out to be a bad idea
> > occasionally. Thus, kill it.
> >
> > Note, this patch fixes some major gpmi-nand breakage.
> >
> > Signed-off-by: Marek Vasut 
> > Cc: Brian Norris 
> > Cc: Eric Nelson 
> > Cc: Fabio Estevam 
> > Cc: Otavio Salvador 
> > Cc: Scott Wood 
>
> Applied to u-boot-nand-flash with the SHA1 updated based on current
> linux-next: 14f44abf1dafc20ba42ce8616a8fc8fbd1b3712b

Thanks ... I think the sha1 is irrelevant as next is being constantly  
rebased

anyway :/


They're at -rc6 or so, so maybe this'll be the final one. :-)

The SHA1 should only change if the tree it was pulled from got rebased.


btw. this should definitelly go to current release.


Yes.

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

Re: [U-Boot] mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver

[Marek Vasut]

Dear Scott Wood,

> On Thu, Aug 30, 2012 at 01:39:38PM -, Marek Vasut wrote:
> > This is based on Linux kernel -next:
> > 
> > commit a1256b0e087ed3cdb584c683acb966ee885f733c
> > Author: Brian Norris 
> > Date:   Fri Jul 13 09:28:24 2012 -0700
> > 
> > mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver
> > 
> > The NAND_CHIPOPTIONS_MSK has limited utility and is causing real
> > bugs. It silently masks off at least one flag that might be set by
> > the driver (NAND_NO_SUBPAGE_WRITE). This breaks the GPMI NAND driver
> > and possibly others.
> > 
> > Really, as long as driver writers exercise a small amount of care
> > with NAND_* options, this mask is not necessary at all; it was only
> > here to prevent certain options from accidentally being set by the
> > driver. But the original thought turns out to be a bad idea
> > occasionally. Thus, kill it.
> > 
> > Note, this patch fixes some major gpmi-nand breakage.
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Brian Norris 
> > Cc: Eric Nelson 
> > Cc: Fabio Estevam 
> > Cc: Otavio Salvador 
> > Cc: Scott Wood 
> 
> Applied to u-boot-nand-flash with the SHA1 updated based on current
> linux-next: 14f44abf1dafc20ba42ce8616a8fc8fbd1b3712b

Thanks ... I think the sha1 is irrelevant as next is being constantly rebased 
anyway :/

btw. this should definitelly go to current release.

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

Re: [U-Boot] mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver

[Scott Wood]

On Thu, Aug 30, 2012 at 01:39:38PM -, Marek Vasut wrote:
> This is based on Linux kernel -next:
> 
> commit a1256b0e087ed3cdb584c683acb966ee885f733c
> Author: Brian Norris 
> Date:   Fri Jul 13 09:28:24 2012 -0700
> 
> mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver
> 
> The NAND_CHIPOPTIONS_MSK has limited utility and is causing real bugs. It
> silently masks off at least one flag that might be set by the driver
> (NAND_NO_SUBPAGE_WRITE). This breaks the GPMI NAND driver and possibly
> others.
> 
> Really, as long as driver writers exercise a small amount of care with
> NAND_* options, this mask is not necessary at all; it was only here to
> prevent certain options from accidentally being set by the driver. But the
> original thought turns out to be a bad idea occasionally. Thus, kill it.
> 
> Note, this patch fixes some major gpmi-nand breakage.
> 
> Signed-off-by: Marek Vasut 
> Cc: Brian Norris 
> Cc: Eric Nelson 
> Cc: Fabio Estevam 
> Cc: Otavio Salvador 
> Cc: Scott Wood 

Applied to u-boot-nand-flash with the SHA1 updated based on current
linux-next: 14f44abf1dafc20ba42ce8616a8fc8fbd1b3712b

-Scott

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

Re: [U-Boot] [PATCH V2 2/2] i.MX6: mx6qsabrelite: Add splash screen support

[Fabio Estevam]

Hi Eric,

On Mon, Sep 17, 2012 at 8:14 PM, Eric Nelson
 wrote:
> Adds support for the Hannstar 1024 x 768 LVDS panel (Freescale part
> number MCIMX-LVDS1) to SABRE-Lite board.
>
> This commit is a rebase Fabio Estevan's patch from 5/31 to

s/Estevan/Estevam


> +int board_late_init(void)
> +{
> +   setenv("stdout", "serial");
> +   return 0;
> +}

Please see my previous comment on v1 about this.

Wolfgang nacked this method and Stefano has proposed a nice way for
keeping the console in serial. Check mx53loco and mx51evk.

Regards,

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

[U-Boot] [GIT PULL] mpc83xx: mpc8308rdb enhancements

[Kim Phillips]

Hi Tom,

Ira improved mpc8308rdb h/w support by making it more comprehensive.
Please pull:

The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721:

  Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 09:17:27 
+0200)

are available in the git repository at:


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

for you to fetch changes up to 014d1dfc669ab2295d7fa4ec4b9f00a4004917a0:

  mpc8308rdb: add support for eSDHC MMC controller (2012-09-17 17:47:12 -0500)


Ira W. Snyder (5):
  mpc8xxx_spi: fix SPI support on MPC8308RDB
  mpc8308rdb: add support for Spansion SPI flash on header J8
  spansion: add support for S25FL256S1
  mpc8308rdb: add support for FIT images
  mpc8308rdb: add support for eSDHC MMC controller

 board/freescale/mpc8308rdb/mpc8308rdb.c | 58 +
 drivers/mtd/spi/spansion.c  |  8 +
 drivers/spi/mpc8xxx_spi.c   |  4 +++
 include/configs/MPC8308RDB.h| 31 ++
 4 files changed, 101 insertions(+)

Thanks,

Kim

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

Re: [U-Boot] [PATCH] common/i2c: Add i2c write command

[Tom Rini]

On Mon, Sep 17, 2012 at 11:29:00PM +, sun york-R58495 wrote:

> Tom,
> 
> It's like eeprom write but it writes to general devices, not specificly to 
> system eeprom. I would have to use i2c mw command a lot without this.

Right.  I guess what I'm getting at is, are you writing to some sort
of other device or writing bits to storage attached to i2c?  Does it
really not make sense to just use 'eeprom write' even if it's not
technically for The System EEPROM but rather some storage (or a number
of storage chips) attached via i2c?

I'm not objecting to i2c write mind you, I was wishing for something
like this when I stumbled on CONFIG_CMD_EEPROM which did what I needed.

-- 
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 0/5] mpc8308rdb: improved hardware support

[Kim Phillips]

On Wed, 12 Sep 2012 14:17:30 -0700
"Ira W. Snyder"  wrote:

> From: "Ira W. Snyder" 
> 
> This series improves the hardware support for the Freescale MPC8308RDB board.
> 
> Optional support for the SPI pins routed to header J8 is added for testing SPI
> flash chips. This was tested with a Spansion S25FL256S1. This is not enabled
> by default, because it breaks TSEC2 due to a pinmux conflict.
> 
> Support for the onboard eSDHC MMC/SD controller is added.
> 
> The SPI controller driver is fixed so that it works with MPC8308RDB (probably
> all 83xx boards are broken before this fix). Without the fix, the waveforms
> generated by the driver are incorrect (confirmed with an oscilloscope).
> 
> Ira W. Snyder (5):
>   mpc8xxx_spi: fix SPI support on MPC8308RDB
>   mpc8308rdb: add support for Spansion SPI flash on header J8
>   spansion: add support for S25FL256S1
>   mpc8308rdb: add support for FIT images
>   mpc8308rdb: add support for eSDHC MMC controller
> 
>  board/freescale/mpc8308rdb/mpc8308rdb.c |   57 
> +++
>  drivers/mtd/spi/spansion.c  |8 
>  drivers/spi/mpc8xxx_spi.c   |4 ++
>  include/configs/MPC8308RDB.h|   31 +
>  4 files changed, 100 insertions(+), 0 deletions(-)

all 5 patches applied to mpc83xx master, after adding #include the
fsl_esdhc header to prevent implicit declarations of
fsl_esdhc_mmc_init() and fdt_fixup_esdhc().

Note: couldn't find a dedicated maintainer for mtd/spi, so carried
those with since they looked pretty straightforward.

Thanks Ira,

Kim

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

Re: [U-Boot] [PATCH] common/i2c: Add i2c write command

[sun york-R58495]

Tom,

It's like eeprom write but it writes to general devices, not specificly to 
system eeprom. I would have to use i2c mw command a lot without this.

York

 Original Message 
From: Tom Rini
Sent: Mon, Sep 17, 2012 05:16 PM
To: sun york-R58495
CC: u-boot@lists.denx.de; u-boot-rele...@linux.freescale.net; Heiko Schocher
Subject: Re: [U-Boot] [PATCH] common/i2c: Add i2c write command


On Sun, Sep 16, 2012 at 01:02:30PM -0500, York Sun wrote:

> Add i2c write command to write data from memory to i2c devices.
>
> Signed-off-by: York Sun 

This feels like eeprom write, to an i2c-connected eeprom.  Is that what
you have this for, or something else?

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

[U-Boot] [PATCH V2 0/2] i.MX6: mx6qsabrelite: Add splash screen support

[Eric Nelson]

Series includes one patch to fix a register name in imx6/crm_regs.h
and a second that's a re-base of Fabio's patch from 5/31.
http://patchwork.ozlabs.org/patch/162206/

 arch/arm/include/asm/arch-mx6/crm_regs.h  |6 ++-
 board/freescale/mx6qsabrelite/mx6qsabrelite.c |   90 +
 include/configs/mx6qsabrelite.h   |   14 -
 3 files changed, 108 insertions(+), 2 deletions(-)

V2 rebased against u-boot-imx/master.

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

[U-Boot] [PATCH V2 1/2] i.MX6: change register name for CCM_CHSCCDR to match ref. manual

[Eric Nelson]

Register CCM_CHSCCDR (offset 0x34 in CCM) is named CCM_CHSCCDR in
reference manual, but was named chscdr in struct mxc_ccm_reg.

Signed-off-by: Eric Nelson 
---
 arch/arm/include/asm/arch-mx6/crm_regs.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h 
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 0e605c2..8388e38 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -34,7 +34,7 @@ struct mxc_ccm_reg {
u32 cs1cdr;
u32 cs2cdr;
u32 cdcdr;  /* 0x0030 */
-   u32 chscdr;
+   u32 chsccdr;
u32 cscdr2;
u32 cscdr3;
u32 cscdr4; /* 0x0040 */
-- 
1.7.9

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

[U-Boot] [PATCH V2 2/2] i.MX6: mx6qsabrelite: Add splash screen support

[Eric Nelson]

Adds support for the Hannstar 1024 x 768 LVDS panel (Freescale part
number MCIMX-LVDS1) to SABRE-Lite board.

This commit is a rebase Fabio Estevan's patch from 5/31 to
u-boot-video/master:
http://patchwork.ozlabs.org/patch/162206/

Modifications include:
removal of i2c setup (unneeded)
cleanup of lcd_iomux to use struct mxc_ccm_reg and anatop_regs
and associated constants

Signed-off-by: Eric Nelson 
---
 arch/arm/include/asm/arch-mx6/crm_regs.h  |4 +
 board/freescale/mx6qsabrelite/mx6qsabrelite.c |   90 +
 include/configs/mx6qsabrelite.h   |   14 -
 3 files changed, 107 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h 
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 8388e38..cffc0a1 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -294,6 +294,10 @@ struct mxc_ccm_reg {
 #define MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK  (0x7)
 #define MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET0
 
+#define CHSCCDR_CLK_SEL_LDB_DI03
+#define CHSCCDR_PODF_DIVIDE_BY_3   2
+#define CHSCCDR_IPU_PRE_CLK_540M_PFD   5
+
 /* Define the bits in register CSCDR2 */
 #define MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK (0x3F << 19)
 #define MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET   19
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c 
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 4b4e89b..1632e7b 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -36,6 +36,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 DECLARE_GLOBAL_DATA_PTR;
 
 #define UART_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |   \
@@ -195,6 +198,10 @@ static iomux_v3_cfg_t button_pads[] = {
MX6Q_PAD_GPIO_18__GPIO_7_13 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
 };
 
+iomux_v3_cfg_t lcd_gpio[] = {
+   MX6Q_PAD_SD1_CMD__GPIO_1_18 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
 static void setup_iomux_enet(void)
 {
gpio_direction_output(IMX_GPIO_NR(3, 23), 0);
@@ -372,10 +379,84 @@ int setup_sata(void)
 }
 #endif
 
+static struct fb_videomode lvds_xga = {
+   .name   = "Hannstar-XGA",
+   .refresh= 60,
+   .xres   = 1024,
+   .yres   = 768,
+   .pixclock   = 15385,
+   .left_margin= 220,
+   .right_margin   = 40,
+   .upper_margin   = 21,
+   .lower_margin   = 7,
+   .hsync_len  = 60,
+   .vsync_len  = 10,
+   .sync   = FB_SYNC_EXT,
+   .vmode  = FB_VMODE_NONINTERLACED
+};
+
+void lcd_iomux(void)
+{
+   struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+   struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+
+   int reg;
+   /* Turn on GPIO backlight */
+   imx_iomux_v3_setup_multiple_pads(lcd_gpio, ARRAY_SIZE(lcd_gpio));
+   gpio_direction_output(18, 1);
+
+   /* Turn on LDB0,IPU,IPU DI0 clocks */
+   reg = __raw_readl(&mxc_ccm->CCGR3);
+   reg |= 0x300F;
+   writel(reg, &mxc_ccm->CCGR3);
+
+   /* set PFD3_FRAC to 0x13 == 455 MHz (480*18)/0x13 */
+   writel(0x3F00, &anatop->pfd_480_clr);
+   writel(0x1300, &anatop->pfd_480_set);
+
+   /* set LDB0, LDB1 clk select to 011/011 */
+   reg = readl(&mxc_ccm->cs2cdr);
+   reg &= ~(MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_MASK
+|MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_MASK);
+   reg |= (3cscmr2);
+   reg |= MXC_CCM_CSCMR2_LDB_DI0_IPU_DIV;
+   writel(reg, &mxc_ccm->cscmr2);
+
+   reg = readl(&mxc_ccm->chsccdr);
+   reg &= ~(MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_MASK
+   |MXC_CCM_CHSCCDR_IPU1_DI0_PODF_MASK
+   |MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK);
+   /* derive clock from LDB_DI0 */
+   /* divide by 3 */
+   /* derive clock from 540M PFD */
+   reg |= (CHSCCDR_CLK_SEL_LDB_DI0
+   

Re: [U-Boot] [PATCH 00/71] serial: Massive rework of the serial subsystem

[Marek Vasut]

Dear Tom Rini,

> On Mon, Sep 17, 2012 at 01:20:25AM +0200, Marek Vasut wrote:
> > This patchset is a STAGE 1 of preparation of the stdio and serial subsys
> > for the driver model.
> 
> [snip]
> 
> > 6) Remove unused code used for the non-multi operation
> > 
> >Remove code that was used when CONFIG_SERIAL_MULTI was not selected.
> >Also remove all occurances of CONFIG_SERIAL_MULTI throughout the
> >source tree. Some parts of the code must have been adjusted to cope
> >with this since they were initially only written for non-multi
> >operation. These were minor adjustments mostly in macros though.
> 
> So we've simplified the code in that now we only have one way of talking
> with the serial ports.  And the drivers are a bit more uniform as well.
> Making the difference between drivers be "here is how you poke the
> hardware" rather than "here is how I implemented a serial driver and oh,
> here is how you poke the hardware" is good.

Correct

> But what's the next step?

So...

2) Rework stdio, make the creation of struct stdio_dev static instead of dynamic
3) struct serial_device is superset of struct stdio_dev ... make use of it, 
make 
stdio and serial subsystems closer
4) The massive list of callbacks in serial.c is stupid, pull out the linker 
section maker thingie (thing used to make driver lists there, similar to 
command 
lists from u-boot) from the DM tree and allow generation of list of serial 
drivers automagically.
===
5) Flip over to DM, it's only one step away

> Have you any thoughts on trying to be clever and in the case of only one
> port anyways getting the size back?

This has been on my mind for a while after seeing those extra 3k of code all 
around. Yet, I'm afraid this won't play well with the DM's pile of pointers.

On the other hand, my stdio rework (step 2) managed to trim down the size a 
bit, 
so that might be small compensation.

> 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 00/71] serial: Massive rework of the serial subsystem

[Tom Rini]

On Mon, Sep 17, 2012 at 01:20:25AM +0200, Marek Vasut wrote:

> This patchset is a STAGE 1 of preparation of the stdio and serial subsys
> for the driver model.
[snip]
> 6) Remove unused code used for the non-multi operation
>Remove code that was used when CONFIG_SERIAL_MULTI was not selected.
>Also remove all occurances of CONFIG_SERIAL_MULTI throughout the source
>tree. Some parts of the code must have been adjusted to cope with this
>since they were initially only written for non-multi operation. These
>were minor adjustments mostly in macros though.

So we've simplified the code in that now we only have one way of talking
with the serial ports.  And the drivers are a bit more uniform as well.
Making the difference between drivers be "here is how you poke the
hardware" rather than "here is how I implemented a serial driver and oh,
here is how you poke the hardware" is good.  But what's the next step?
Have you any thoughts on trying to be clever and in the case of only one
port anyways getting the size back?  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 42/71] serial: arm: Implement CONFIG_SERIAL_MULTI into lpc32xx serial driver

[Vladimir Zapolskiy]

On 17.09.2012 02:21, Marek Vasut wrote:

Implement support for CONFIG_SERIAL_MULTI into lpc32xx serial driver.
This driver was so far only usable directly, but this patch also adds
support for the multi method. This allows using more than one serial
driver alongside the lpc32xx driver. Also, add a weak implementation
of default_serial_console() returning this driver.

Signed-off-by: Marek Vasut 
Cc: Marek Vasut 
Cc: Tom Rini 
Cc: Vladimir Zapolskiy 


Acked-by: Vladimir Zapolskiy 

Thanks,
Vladimir


---
  common/serial.c |2 ++
  drivers/serial/lpc32xx_hsuart.c |   71 ++-
  2 files changed, 50 insertions(+), 23 deletions(-)

diff --git a/common/serial.c b/common/serial.c
index b880303..8bc26d8 100644
--- a/common/serial.c
+++ b/common/serial.c
@@ -72,6 +72,7 @@ serial_initfunc(p3mx_serial_initialize);
  serial_initfunc(altera_jtag_serial_initialize);
  serial_initfunc(altera_serial_initialize);
  serial_initfunc(atmel_serial_initialize);
+serial_initfunc(lpc32xx_serial_initialize);

  void serial_register(struct serial_device *dev)
  {
@@ -122,6 +123,7 @@ void serial_initialize(void)
altera_jtag_serial_initialize();
altera_serial_initialize();
atmel_serial_initialize();
+   lpc32xx_serial_initialize();

serial_assign(default_serial_console()->name);
  }
diff --git a/drivers/serial/lpc32xx_hsuart.c b/drivers/serial/lpc32xx_hsuart.c
index 8ce3382..536fd46 100644
--- a/drivers/serial/lpc32xx_hsuart.c
+++ b/drivers/serial/lpc32xx_hsuart.c
@@ -22,12 +22,14 @@
  #include
  #include
  #include
+#include
+#include

  DECLARE_GLOBAL_DATA_PTR;

  static struct hsuart_regs *hsuart = (struct hsuart_regs *)HS_UART_BASE;

-static void lpc32xx_hsuart_set_baudrate(void)
+static void lpc32xx_serial_setbrg(void)
  {
u32 div;

@@ -39,7 +41,7 @@ static void lpc32xx_hsuart_set_baudrate(void)
writel(div,&hsuart->rate);
  }

-static int lpc32xx_hsuart_getc(void)
+static int lpc32xx_serial_getc(void)
  {
while (!(readl(&hsuart->level)&  HSUART_LEVEL_RX))
/* NOP */;
@@ -47,7 +49,7 @@ static int lpc32xx_hsuart_getc(void)
return readl(&hsuart->rx)&  HSUART_RX_DATA;
  }

-static void lpc32xx_hsuart_putc(const char c)
+static void lpc32xx_serial_putc(const char c)
  {
writel(c,&hsuart->tx);

@@ -56,7 +58,7 @@ static void lpc32xx_hsuart_putc(const char c)
/* NOP */;
  }

-static int lpc32xx_hsuart_tstc(void)
+static int lpc32xx_serial_tstc(void)
  {
if (readl(&hsuart->level)&  HSUART_LEVEL_RX)
return 1;
@@ -64,49 +66,72 @@ static int lpc32xx_hsuart_tstc(void)
return 0;
  }

-static void lpc32xx_hsuart_init(void)
+static int lpc32xx_serial_init(void)
  {
-   lpc32xx_hsuart_set_baudrate();
+   lpc32xx_serial_setbrg();

/* Disable hardware RTS and CTS flow control, set up RX and TX FIFO */
writel(HSUART_CTRL_TMO_16 | HSUART_CTRL_HSU_OFFSET(20) |
   HSUART_CTRL_HSU_RX_TRIG_32 | HSUART_CTRL_HSU_TX_TRIG_0,
&hsuart->ctrl);
+   return 0;
  }

-void serial_setbrg(void)
+static void lpc32xx_serial_puts(const char *s)
  {
-   return lpc32xx_hsuart_set_baudrate();
+   while (*s)
+   serial_putc(*s++);
  }

-void serial_putc(const char c)
+#ifdef CONFIG_SERIAL_MULTI
+static struct serial_device lpc32xx_serial_drv = {
+   .name   = "lpc32xx_serial",
+   .start  = lpc32xx_serial_init,
+   .stop   = NULL,
+   .setbrg = lpc32xx_serial_setbrg,
+   .putc   = lpc32xx_serial_putc,
+   .puts   = lpc32xx_serial_puts,
+   .getc   = lpc32xx_serial_getc,
+   .tstc   = lpc32xx_serial_tstc,
+};
+
+void lpc32xx_serial_initialize(void)
  {
-   lpc32xx_hsuart_putc(c);
+   serial_register(&lpc32xx_serial_drv);
+}

-   /* If \n, also do \r */
-   if (c == '\n')
-   lpc32xx_hsuart_putc('\r');
+__weak struct serial_device *default_serial_console(void)
+{
+   return&lpc32xx_serial_drv;
+}
+#else
+int serial_init(void)
+{
+   return lpc32xx_serial_init();
  }

-int serial_getc(void)
+void serial_setbrg(void)
  {
-   return lpc32xx_hsuart_getc();
+   lpc32xx_serial_setbrg();
  }

-void serial_puts(const char *s)
+void serial_putc(const char c)
  {
-   while (*s)
-   serial_putc(*s++);
+   lpc32xx_serial_putc(c);
  }

-int serial_tstc(void)
+void serial_puts(const char *s)
  {
-   return lpc32xx_hsuart_tstc();
+   lpc32xx_serial_puts(s);
  }

-int serial_init(void)
+int serial_getc(void)
  {
-   lpc32xx_hsuart_init();
+   return lpc32xx_serial_getc();
+}

-   return 0;
+int serial_tstc(void)
+{
+   return lpc32xx_serial_tstc();
  }
+#endif

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

Re: [U-Boot] [PATCH v2 4/4] nand: Make NAND lock status compatible with Micron

[Scott Wood]

On Wed, Aug 22, 2012 at 04:49:45PM -0500, Joe Hershberger wrote:
> Micron NAND flash (e.g. MT29F4G08ABADAH4) BLOCK LOCK READ STATUS is not
> the same as others.  Instead of bit 1 being lock, it is #lock_tight.
> To make the driver support either format, ignore bit 1 and use only
> bit 0 and bit 2.
> 
> Signed-off-by: Joe Hershberger 
> ---
> Changes in v2:
> - Added comment about NAND status work-around
> 
>  common/cmd_nand.c| 8 +++-
>  drivers/mtd/nand/nand_util.c | 2 --
>  include/nand.h   | 1 -
>  3 files changed, 7 insertions(+), 4 deletions(-)

Applied to u-boot-nand-flash.

-Scott

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

Re: [U-Boot] [PATCH v2 3/4] nand: consolidate duplicated constants

[Scott Wood]

On Wed, Aug 22, 2012 at 04:49:44PM -0500, Joe Hershberger wrote:
> NAND_CMD_ constants for lock/unlock should be in the header
> 
> Signed-off-by: Joe Hershberger 
> ---
> 
>  drivers/mtd/nand/nand_util.c | 6 --
>  include/linux/mtd/nand.h | 2 ++
>  2 files changed, 2 insertions(+), 6 deletions(-)

Applied to u-boot-nand-flash.

-Scott

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

Re: [U-Boot] [PATCH v2 2/4] nand: Change ulong to loff_t and size_t

[Scott Wood]

On Wed, Aug 22, 2012 at 04:49:43PM -0500, Joe Hershberger wrote:
> Missed in previous cleanup.
> 
> Signed-off-by: Joe Hershberger 
> ---
> Changes in v2:
> - Added loff_t cleanup to series
> 
>  drivers/mtd/nand/nand_util.c | 5 +++--
>  include/nand.h   | 3 ++-
>  2 files changed, 5 insertions(+), 3 deletions(-)

Applied to u-boot-nand-flash.

-Scott

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

Re: [U-Boot] [PATCH v2 1/4] nand: Add support for unlock.invert

[Scott Wood]

On Wed, Aug 22, 2012 at 04:49:42PM -0500, Joe Hershberger wrote:
> NAND unlock command allows an invert bit to be set to unlock all but
> the selected page range.
> 
> Signed-off-by: Joe Hershberger 
> ---
> Changes in v2:
> - Changed invert to allexcept
> - Changed unlock printf to debug print
> - Dropped cast in unlock debug print
> 
>  common/cmd_nand.c| 13 ++---
>  drivers/mtd/nand/nand_util.c | 10 +++---
>  include/nand.h   |  4 ++--
>  3 files changed, 19 insertions(+), 8 deletions(-)

Applied to u-boot-nand-flash with the diff below.  Do you know if all
chips that support locking support the invert bit?  If not, we should at
least update the documentation to mention this (though runtime detection
would be good if practical).

--- a/doc/README.nand
+++ b/doc/README.nand
@@ -228,6 +228,8 @@ NAND locking command (for chips with active LOCKPRE pin)
   "nand unlock [offset] [size]"
   unlock consecutive area (can be called multiple times for different areas)
 
+  "nand unlock.allexcept [offset] [size]"
+  unlock all except specified consecutive area
 
 I have tested the code with board containing 128MiB NAND large page chips
 and 32MiB small page chips.
diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index 21a011c..c66eeef 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -370,8 +370,15 @@ int nand_unlock(struct mtd_info *mtd, ulong start, ulong 
length, int allexcept)
 
/* submit ADDRESS of LAST page to unlock */
page += (int)(length >> chip->page_shift);
+
+   /*
+* Page addresses for unlocking are supposed to be block-aligned.
+* At least some NAND chips use the low bit to indicate that the
+* page range should be inverted.
+*/
if (allexcept)
page |= 1;
+
chip->cmdfunc(mtd, NAND_CMD_UNLOCK2, -1, page & chip->pagemask);
 
/* call wait ready function */

-Scott

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

Re: [U-Boot] [PATCH] mtd: support ONFI multi lun NAND

[Scott Wood]

On 09/17/2012 04:21:09 PM, Matthieu CASTET wrote:

With onfi a flash is organized into one or more logical units (LUNs).
A logical unit (LUN) is the minimum unit that can independently  
execute

commands and report status.

Mtd does not exploit LUN, so make it see a big single flash where  
size is

lun_size * number_of_lun.

Without this patch MT29F8G08ADBDAH4 size is 512MiB instead of 1GiB.

Artem: split long line on 2 shorter ones.

This is commit 637957551c0ac80de8dfc7650d320c5a98c2c0c0 from Linux

Signed-off-by: Matthieu Castet 
Acked-by: Florian Fainelli 
Signed-off-by:  Artem Bityutskiy 
Signed-off-by: David Woodhouse 
[scottw...@freescale.com: picked from Linux into U-Boot]
Reported-by: Rafael Beims 
Signed-off-by: Scott Wood 


Sigh, this was posted by me, not Matthieu -- I forgot to fix up the  
output of git format-patch before running mutt on it.  Please don't  
reply to Matthieu (at least regarding anything U-Boot specific).


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

Re: [U-Boot] [PATCH] common/i2c: Add i2c write command

[Tom Rini]

On Sun, Sep 16, 2012 at 01:02:30PM -0500, York Sun wrote:

> Add i2c write command to write data from memory to i2c devices.
> 
> Signed-off-by: York Sun 

This feels like eeprom write, to an i2c-connected eeprom.  Is that what
you have this for, or something else?

-- 
Tom


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

[U-Boot] [PATCH] mtd: support ONFI multi lun NAND

[Matthieu CASTET]

With onfi a flash is organized into one or more logical units (LUNs).
A logical unit (LUN) is the minimum unit that can independently execute
commands and report status.

Mtd does not exploit LUN, so make it see a big single flash where size is
lun_size * number_of_lun.

Without this patch MT29F8G08ADBDAH4 size is 512MiB instead of 1GiB.

Artem: split long line on 2 shorter ones.

This is commit 637957551c0ac80de8dfc7650d320c5a98c2c0c0 from Linux

Signed-off-by: Matthieu Castet 
Acked-by: Florian Fainelli 
Signed-off-by:  Artem Bityutskiy 
Signed-off-by: David Woodhouse 
[scottw...@freescale.com: picked from Linux into U-Boot]
Reported-by: Rafael Beims 
Signed-off-by: Scott Wood 
---
Rafael submitted http://patchwork.ozlabs.org/patch/168820/ to fix this,
but the patch was corrupt so I picked the equivalent fix out of Linux
(better to have them synced anyway).

Applied to u-boot-nand-flash.

 drivers/mtd/nand/nand_base.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index bfd668f..50bfb65 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2573,7 +2573,8 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, 
struct nand_chip *chip,
mtd->writesize = le32_to_cpu(p->byte_per_page);
mtd->erasesize = le32_to_cpu(p->pages_per_block) * mtd->writesize;
mtd->oobsize = le16_to_cpu(p->spare_bytes_per_page);
-   chip->chipsize = (uint64_t)le32_to_cpu(p->blocks_per_lun) * 
mtd->erasesize;
+   chip->chipsize = le32_to_cpu(p->blocks_per_lun);
+   chip->chipsize *= (uint64_t)mtd->erasesize * p->lun_count;
*busw = 0;
if (le16_to_cpu(p->features) & 1)
*busw = NAND_BUSWIDTH_16;
-- 
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 08/16] pmic:muic: Support for MUIC built into MAX8997 device

[Lukasz Majewski]

Hi Stefano,

> On 14/09/2012 17:40, Lukasz Majewski wrote:
> > Support for MUIC (Micro USB Integrated Circuit) built into the
> > MAX8997 power management device.
> > 
> > The MUIC device will work with redesigned PMIC framework.
> > 
> > Signed-off-by: Lukasz Majewski 
> > Signed-off-by: Kyungmin Park 
> > Cc: Stefano Babic 
> > ---
> 
> Hi Lukasz,
> 
> >  drivers/misc/Makefile|1 +
> >  drivers/misc/muic_max8997.c  |   80
> > ++
> > include/power/max8997_muic.h |   61
> >  include/power/power_chrg.h   |
> > 1 + 4 files changed, 143 insertions(+), 0 deletions(-) create mode
> > 100644 drivers/misc/muic_max8997.c create mode 100644
> > include/power/max8997_muic.h
> > 
> 
> I see now with this patch, but we have a mix between drivers/misc and
> drivers/power. I think this was done because the power directory was
> introduced later, but really all pmics under drivers/misc should be
> moved into drivers/power.

Yes, I agree about that. PMIC (or in the future POWER) related code
shall be moved to drivers/power/{subdir_per_PMIC_device}

Please also keep in mind, that I plan to rename the "pmic"
command/framework to "power" to better reflect its purpose.

> 
> Maybe belong this one also to drivers/power ?
> 
> You added several "add-ons" for MAX8997. Maybe it is clearer if
> everything goes into a separate directory, such as power/max8997/

Very good idea.
I've already proposed a little "cleanup" with putting all power related
includes to ./include/power/ directory.

> 
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index 271463c..f08a800 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -41,6 +41,7 @@ COBJS-$(CONFIG_PMIC_I2C) += pmic_i2c.o
> >  COBJS-$(CONFIG_PMIC_SPI) += pmic_spi.o
> >  COBJS-$(CONFIG_PMIC_MAX8998) += pmic_max8998.o
> >  COBJS-$(CONFIG_PMIC_MAX8997) += pmic_max8997.o
> > +COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
> >  
> >  COBJS  := $(COBJS-y)
> >  SRCS   := $(COBJS:.o=.c)
> > diff --git a/drivers/misc/muic_max8997.c
> > b/drivers/misc/muic_max8997.c new file mode 100644
> > index 000..d332c09
> > --- /dev/null
> > +++ b/drivers/misc/muic_max8997.c
> > @@ -0,0 +1,80 @@
> > +/*
> > + *  Copyright (C) 2012 Samsung Electronics
> > + *  Lukasz Majewski 
> > + *
> > + * See file CREDITS for list of people who contributed to this
> > + * project.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of
> > + * the License, or (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public
> > License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> > + * MA 02111-1307 USA
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +int power_muic_init(unsigned int bus)
> 
> You add a different function to initialize it, but this is a version
> opf pmic_init(). Why cannot we consider this one as all other pmics,
> avoiding to introduce new and undocumented functions ?
> 
> If I do not misunderstand, you use the different functions to select
> the pmic. In other words, calling power_update_battery() in the trats
> code selects automatically the fulel-gauge, because this code
> implements this function. But this is against the goal of your
> patches, that is to add multi instances of the pmics (and maybe a
> second instance of fuel_gauge..).
> 
> I think this should be solved moving this function to the general API
> and calling it via pointer. For example, something like:
> 
>   p = pmic_get("MAX_8997);
>   p->read(...);
>   
>   p = pmic_get("MAX17042_FG");
>   p->power_update_battery(..);
> 
> What do you think ?

I will think about that and give you an answer.
> 
> Best regards,
> Stefano Babic
> 
> 

Regards,
Lukasz

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

Re: [U-Boot] [PATCH 09/16] pmic:fuel-gauge: Support for MAX17042 fuel-gauge

[Lukasz Majewski]

Hi Tom ,

> On Fri, Sep 14, 2012 at 05:40:08PM +0200, Lukasz Majewski wrote:
> 
> > Support for MAX17042 fuel-gauge (FG), which is built into the
> > MAX8997 power management device.
> > Special file - fg_battery_cell_params.h with cells characteristics
> > added.
> [snip]
> > +#ifndef __FG_BATTERY_CELL_PARAMS_H_
> > +#define __FG_BATTERY_CELL_PARAMS_H_
> > +
> > +#if  defined(CONFIG_POWER_FG_MAX17042) && defined(CONFIG_TRATS)
> > +
> > +/* Cell characteristics - Exynos4 TRATS development board */
> > +
> > +u16 cell_character0[16]  /* Shall be written to addr 0x80h */
> > += { 0xA2A0,
> 
> This (and the rest of the file) should be:
> /* Shall be written to addr 0x80h */
> u16 cell_character0[16] = {
>   0xA2A0,
> ...
> 


Ok, I will fix this.
> Thanks.
> 
> Also:
> [snip]
> > +   MAX17042_AVG_CURRENT= 0x0B,
> > +   MAX17042_SOCMIX = 0x0D,
> > +   MAX17042_SOCAV  = 0x0E,
> 
> I assume this is just odd formatting in the mail and once applied it's
> aligned.  If not, please fix (and check the rest of the series).
> Thanks!
> 

I will double check that. Nether checkpatch nor emac's
whitespace-cleanup weren't complaining.

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

Re: [U-Boot] [PATCH 10/16] pmic:max8997: Function for calculating LDO internal register value

[Lukasz Majewski]

On Fri, 14 Sep 2012 10:24:49 -0700
Tom Rini  wrote:

> On Fri, Sep 14, 2012 at 05:40:09PM +0200, Lukasz Majewski wrote:
> 
> > Function for calculating LDO internal register value from passed
> > micro Volt.
> > 
> > Signed-off-by: Lukasz Majewski 
> > Signed-off-by: Kyungmin Park 
> > Cc: Stefano Babic 
> > ---
> >  drivers/misc/pmic_max8997.c |   17 +
> >  1 files changed, 17 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/misc/pmic_max8997.c
> > b/drivers/misc/pmic_max8997.c index 4e8283a..a4158e2 100644
> > --- a/drivers/misc/pmic_max8997.c
> > +++ b/drivers/misc/pmic_max8997.c
> > @@ -42,3 +42,20 @@ int pmic_init(unsigned char bus)
> >  
> > return 0;
> >  }
> > +
> > +unsigned char max8997_reg_ldo(int uV)
> > +{
> > +   unsigned char ret;
> > +   if (uV <= 80)
> > +   return 0;
> > +   if (uV >= 395)
> > +   return 0x3f;
> > +   ret = (uV - 80) / 5;
> > +   if (ret > 0x3f) {
> > +   printf("MAX8997 LDO SETTING ERROR (%duV) -> %u\n",
> > uV, ret);
> > +   ret = 0x3f;
> > +   }
> 
> Can we get a comment to point at the doc that says what these values
> are?  Maybe even a #define for the return values.
> 

Yes, explanation will be provided.

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

Re: [U-Boot] [PATCH 13/16] arm:trats:pmic: Enable fuel-gauge (MAX17042) at Samsung's TRATS board

[Lukasz Majewski]

Hi Tom,


> On Fri, Sep 14, 2012 at 05:40:12PM +0200, Lukasz Majewski wrote:
> 
> > FG IC built into the MAX8997 device (compliant to MAX17042) is
> > enabled at TRATS.
> [snip]
> > +#define CONFIG_POWER_FG
> > +#define CONFIG_POWER_FG_MAX17042
> >  #define CONFIG_POWER_MUIC
> >  #define CONFIG_POWER_MUIC_MAX8997
> > +
> > +
> >  #define CONFIG_USB_GADGET
> 
> Double space? :)
> 

Will be fixed :-)

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

Re: [U-Boot] [PATCH 15/16] arm:trats:pmic: Support for charging battery at Samsung's TRATS board

[Lukasz Majewski]

Hi Tom ,

> If I read this right we'll pause in the middle of start up to charge
> the battery for possibly a long time right?  And this could be a
> while loop even, yes?  If so to the first one, this really should be
> under some sort of CONFIG option.

This is one of the options. Other option is to extend the pmic/power
command to:

pmic charger on/off to recharge battery when needed.

I think, that above is a better solution.

> I know the value of showing proof of concept
> type examples in development boards but that should still be an opt-in
> thing I would think.

Yes, indeed this shall be regarded as a proof-of-concept to show that
battery is automatically charged when needed.

Instead, I think, that it would be a good idea to write a warning on
the u-boot starting (when PMIC driver is initialized):

e.g. WARNING: Battery needs charging (voltage: 3.5V capacity: 8%)

And then user can on its own decide if he/she will charge the battery or
not.

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

Re: [U-Boot] [PATCH 00/16] pmic: Redesign PMIC framework to support multiple instances of devices

[Lukasz Majewski]

Hi Tom,

> On Fri, Sep 14, 2012 at 05:39:59PM +0200, Lukasz Majewski wrote:
> 
> > PMIC framework has been redesigned to support multiple instances of
> > power related devices (e.g. fuel gauge, PMICs, chargers, micro USB
> > IC).
> > 
> > Due to that, code at other architectures and boards have been
> > adjusted properly.
> > 
> > New power_board_init() method at ./lib/board.c file has been
> > introduced. It is meant to be an architecture dependent function to
> > support advanced power management. Since PMIC framework uses lists
> > internally to link different devices, its initialization must be
> > done just after malloc initialization.
> 
> The framework itself looks OK, but I'd appreciate others reviewing as
> well.
> 
That was my intention to start a discussion. I'm welcome for other
opinions.

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

Re: [U-Boot] [PATCH 03/16] pmic:max8997: Switch the MAX8997 PMIC to be used with multibus I2C

[Lukasz Majewski]

Hi Stefano,

> On 14/09/2012 17:40, Lukasz Majewski wrote:
> > PMIC MAX8997 is now ready to work with single and multibus soft I2C
> > implementation.
> > 
> > Signed-off-by: Lukasz Majewski 
> > Signed-off-by: Kyungmin Park 
> > ---
> >  drivers/misc/pmic_max8997.c |3 ++-
> >  1 files changed, 2 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/misc/pmic_max8997.c
> > b/drivers/misc/pmic_max8997.c index 62dbc05..4943f66 100644
> > --- a/drivers/misc/pmic_max8997.c
> > +++ b/drivers/misc/pmic_max8997.c
> > @@ -24,6 +24,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  int pmic_init(void)
> >  {
> > @@ -37,7 +38,7 @@ int pmic_init(void)
> > p->number_of_regs = PMIC_NUM_OF_REGS;
> > p->hw.i2c.addr = MAX8997_I2C_ADDR;
> > p->hw.i2c.tx_num = 1;
> > -   p->bus = I2C_PMIC;
> > +   p->bus = I2C_0;
> >  
> 
> I do not see so useful to add an enum for each instance of the I2C
> bus. And we have to add it if the number of i2c busses grows. IMHO it
> is better to use directly the constant, so later in another patch
> pmic_init(5) instead of pmic(I2C_5).
> 

This problem has been already discussed with Heiko:

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

I think, that we will have to have an enum of available I2C_x busses at
 header file.

In the case of Trats and PMIC framework, the I2C_0 is done on purpose
to keep the trats board working (since the PMIC is in reality connected
to I2C_5). This numbering (I2C_0) needs to be there until prerequisite
patches aren't accepted (the multibus I2C support on trats board)

Regards,
Lukasz Majewski

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

Re: [U-Boot] [PATCH 02/16] pmic:i2c: Add I2C byte order to PMIC framework

[Lukasz Majewski]

Hi Stefano,

> On 14/09/2012 17:40, Lukasz Majewski wrote:
> > Since the pmic_reg_read is the u32 value, the order in which bytes
> > are placed to form u32 value is important.
> > 
> > This commit adds the reverse (which is default) and normal byte
> > order.
> > 
> > Signed-off-by: Lukasz Majewski 
> > Signed-off-by: Kyungmin Park 
> > ---
> 
> Hi,
> 
> >  drivers/misc/pmic_i2c.c |   31 ---
> >  include/pmic.h  |3 +++
> >  2 files changed, 27 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/misc/pmic_i2c.c b/drivers/misc/pmic_i2c.c
> > index e74c372..1aa5b7b 100644
> > --- a/drivers/misc/pmic_i2c.c
> > +++ b/drivers/misc/pmic_i2c.c
> > @@ -40,13 +40,24 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32
> > val) 
> > switch (pmic_i2c_tx_num) {
> > case 3:
> > -   buf[0] = (val >> 16) & 0xff;
> > -   buf[1] = (val >> 8) & 0xff;
> > -   buf[2] = val & 0xff;
> > +   if (pmic_i2c_byte_order == PMIC_BYTE_ORDER_NORMAL)
> > {
> > +   buf[2] = (val >> 16) & 0xff;
> > +   buf[1] = (val >> 8) & 0xff;
> > +   buf[0] = val & 0xff;
> > +   } else {
> > +   buf[0] = (val >> 16) & 0xff;
> > +   buf[1] = (val >> 8) & 0xff;
> > +   buf[2] = val & 0xff;
> > +   }
> > break;
> > case 2:
> > -   buf[0] = (val >> 8) & 0xff;
> > -   buf[1] = val & 0xff;
> > +   if (pmic_i2c_byte_order == PMIC_BYTE_ORDER_NORMAL)
> > {
> > +   buf[1] = (val >> 8) & 0xff;
> > +   buf[0] = val & 0xff;
> > +   } else {
> > +   buf[0] = (val >> 8) & 0xff;
> > +   buf[1] = val & 0xff;
> > +   }
> > break;
> > case 1:
> > buf[0] = val & 0xff;
> > @@ -75,10 +86,16 @@ int pmic_reg_read(struct pmic *p, u32 reg, u32
> > *val) 
> > switch (pmic_i2c_tx_num) {
> > case 3:
> > -   ret_val = buf[0] << 16 | buf[1] << 8 | buf[2];
> > +   if (pmic_i2c_byte_order == PMIC_BYTE_ORDER_NORMAL)
> > +   ret_val = buf[2] << 16 | buf[1] << 8 |
> > buf[0];
> > +   else
> > +   ret_val = buf[0] << 16 | buf[1] << 8 |
> > buf[2]; break;
> > case 2:
> > -   ret_val = buf[0] << 8 | buf[1];
> > +   if (pmic_i2c_byte_order == PMIC_BYTE_ORDER_NORMAL)
> > +   ret_val = buf[1] << 8 | buf[0];
> > +   else
> > +   ret_val = buf[0] << 8 | buf[1];
> > break;
> > case 1:
> > ret_val = buf[0];
> > diff --git a/include/pmic.h b/include/pmic.h
> > index 6a05b40..2166f73 100644
> > --- a/include/pmic.h
> > +++ b/include/pmic.h
> > @@ -27,11 +27,13 @@
> >  enum { PMIC_I2C, PMIC_SPI, };
> >  enum { I2C_PMIC, I2C_NUM, };
> >  enum { PMIC_READ, PMIC_WRITE, };
> > +enum { PMIC_BYTE_ORDER_REVERSED, PMIC_BYTE_ORDER_NORMAL, };
> >  
> >  struct p_i2c {
> > unsigned char addr;
> > unsigned char *buf;
> > unsigned char tx_num;
> > +   unsigned char byte_order;
> 
> I can imagine we could have the same issue with SPI and not only with
> I2C. The byte order is not strictly related to the interface type,
> and I think this should add to the "struct pmic" instead of the
> "struct p_i2c".
> 

Thanks for reply. 

Good point. I will move this to struct pmic.

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

Re: [U-Boot] using initrd with U-boot on the imx28evk

[Fabio Estevam]

Bill,

On Mon, Sep 17, 2012 at 6:31 PM, Marek Vasut  wrote:
> Dear Bill,
>
> I'm CCing Fabio ... he might have some idea for you.

What about starting a thread in linux-arm-kernel for this?

Regards,

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

Re: [U-Boot] Cache alignment warnings on Tegra (ARM)

[Simon Glass]

Hi Thierry,

On Sat, Sep 15, 2012 at 11:49 PM, Thierry Reding
 wrote:
> On Sat, Sep 15, 2012 at 07:45:30PM -0700, Simon Glass wrote:
>> Hi,
>>
>> On Sat, Sep 15, 2012 at 1:41 PM, Thierry Reding
>>  wrote:
>> > On Sat, Sep 15, 2012 at 10:11:54PM +0200, Marek Vasut wrote:
>> >> Dear Thierry Reding,
>> >>
>> >> > On Fri, Sep 14, 2012 at 08:53:32AM -0700, Simon Glass wrote:
>> >> > > Hi,
>> >> > >
>> >> > > On Wed, Sep 12, 2012 at 4:42 PM, Marek Vasut  wrote:
>> >> > > > Dear Stephen Warren,
>> >> > > >
>> >> > > >> On 09/12/2012 04:38 PM, Marek Vasut wrote:
>> >> > > >> > Dear Stephen Warren,
>> >> > > >> >
>> >> > > >> >> On 09/12/2012 10:19 AM, Tom Warren wrote:
>> >> > > >> >>> Folks,
>> >> > > >> >>>
>> >> > > >> >>> Stephen Warren has posted an internal bug regarding the cache
>> >> > > >> >>> alignment 'warnings' seen on Tegra20 boards when accessing MMC.
>> >> > > >> >>> Here's the gist:
>> >> > > >> >>>
>> >> > > >> >>> Executing "mmc dev 0" still yields cache warnings:
>> >> > > >> >>>
>> >> > > >> >>> Tegra20 (Harmony) # mmc dev 0
>> >> > > >> >>> ERROR: v7_dcache_inval_range- stop address is not aligned-
>> >> > > >> >>> 0x3fb69908 mmc0 is current device
>> >> > > >> >>
>> >> > > >> >> ...
>> >> > > >> >>
>> >> > > >> >>> There have been patches in the past (IIRC) that have tried to
>> >> > > >> >>> ensure all callers (FS, MMC driver, USB driver, etc.) force 
>> >> > > >> >>> their
>> >> > > >> >>> buffers to the appropriate alignment, but I don't know that we
>> >> > > >> >>> can ever correct every instance, now or in the future.
>> >> > > >> >>>
>> >> > > >> >>> Can we start a discussion about what we can do about this 
>> >> > > >> >>> warning?
>> >> > > >> >>> Adding an appropriate #ifdef
>> >> > > >> >>> (CONFIG_SYS_NO_CACHE_ALIGNMENT_WARNINGS, etc.) where Stephen 
>> >> > > >> >>> put
>> >> > > >> >>> his #if 0's would be one approach, or changing the printf() to 
>> >> > > >> >>> a
>> >> > > >> >>> debug(), perhaps. As far as I can tell, these alignment 
>> >> > > >> >>> 'errors'
>> >> > > >> >>> don't seem to produce bad data in the transfer.
>> >> > > >> >>
>> >> > > >> >> I don't think simply turning off the warning is the correct
>> >> > > >> >> approach; I believe they represent real problems that can in 
>> >> > > >> >> fact
>> >> > > >> >> cause data corruption. I don't believe we have any choice other
>> >> > > >> >> than to fully solve the root-cause.
>> >> > >
>> >> > > Yes I agree, and I think it is pretty close - certainly much better
>> >> > > than it used to be. The good thing about them being annoying is that
>> >> > > they will likely get fixed :-)
>> >> >
>> >> > I think I traced this to the copying of CSD a while back. The problem is
>> >> > that the transferred buffer is 8 bytes, so there's no way to make it
>> >> > aligned properly. Unfortunately the entailing discussion did not yield a
>> >> > solution at the time.
>> >>
>> >> And how exactly does the MMC bounce buffer not help here?
>> >
>> > The problem solved by the bounce buffer is that it is properly cache-
>> > line aligned. However the issue here is not that the buffer is not
>> > properly aligned but rather that the transfer is too small.
>> >
>> > When the MMC core transfers the SCR, it requests 8 bytes. The buffer
>> > used to store these 8 bytes is properly allocated. However, those 8
>> > bytes eventually end up as the size of the range that is to be
>> > invalidated. This is the reason for the warning. Address x of the buffer
>> > is cache-line aligned, but x + 8 is never properly aligned and therefore
>> > the code complains.
>>
>> Would it be too dreadful to define a minimum MMC transfer size, and
>> set that to the cache line size?
>
> I did try setting the data size to the cache line size back then, but
> that resulted in an error. After that I gave up. I think what we really
> need to do is separate the invalidation size from the transfer size in
> order to properly handle these situations. Or alternatively pass an
> additional buffer size so the code knows how much needs to be
> invalidated. AFAICT this is the only location where this actually
> happens. All other transfers are typically block sized so they'll be a
> multiple of the cache line anyway.

I suppose the requirement is that the buffer size is large enough, and
is aligned. Even if fewer bytes are transferred than the size of the
buffer, that still solves the problem. As you say, if we had a way of
saying 'here is a 64-byte buffer but only 16 bytes need to be
transferred' then we would be good. If this is really just an MMC
problem then perhaps the fix can be localised there.

Regards,
Simon

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

Re: [U-Boot] using initrd with U-boot on the imx28evk

[Marek Vasut]

Dear Bill,

I'm CCing Fabio ... he might have some idea for you.

> Marek,
> 
>  Yes, I checked the kernel and it is  enabled for ramdisk support in
> Linux, gzip compression, and loop back block driver.  I did find some
> other posts where some folks added the address of the ram drive.  So I
> changed the kernel arguments from:
> 
>   setenv bootargs console=ttyAM0,115200n8 debug root=/dev/ram rw ip=dhcp 
> fec_mac= TO:
> 
>   setenv bootargs console=ttyAM0,115200n8 debug root=/dev/ram rw
> initrd=0x4300,40K   ip=dhcp  fec_mac=
> 
> 
> And now  the kernel output generates a additional error line from RAMDISK:
> 
> ...
> ...
> ...
> RAMDISK: Couldn't find valid RAM disk image starting at 0.  This
> line now appears on the console
> List of all partitions:
> b300 3872256 mmcblk0 driver: mmcblk
>b3011024 mmcblk0p1
> 0800  503808 sda driver: sd
>0801  503792 sda1
> No filesystem could mount root, tried:  ext3 ext2 vfat msdos iso9660
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(1,0)
> ...
> ...
> ...
> 
> 
> Is it something with the RAM disk format or the uboot tool mkimage
> parameters?
> 
> Thanks,
> Bill
> 
> On 9/12/2012 6:44 PM, Marek Vasut wrote:
> > Dear Bill,
> > 
> >> I'm using U-boot version:  U-Boot 2012.07
> >> 
> >> Through googling, I've come across several variations of using a
> >> ramdisk.  So I selected some things that looked good.  So basically, I
> >> 
> >> am building  a rootfs as a ramdisk by:
> >>  dd if=/dev/zero of=./myinitrd.img bs=1M count=35
> >>  mke2fs -m 1 ./myinitrd.img
> >>  mkdir ./myinitrd
> >>  mount -t ext2 ./myinitrd.img ./myinitrd -o loop
> >>  cp -r rootfs/*  ./myinitrd/.
> >>  umount ./myinitrd/
> >>  gzip ./myinitrd.img
> >>  rm -rf myinitrd
> >> 
> >> Then I use the u-boot tool to prepare it for use with u-boot by:
> >>u-boot-imx/tools/mkimage  -n 'MyRamDisk' -A arm -O linux -T
> >> 
> >> ramdisk -C none -d ./myinitrd.img.gz rootfs-initrd
> >> 
> >> I place both both my uImage and rootfs-initrd on a USB stick and insert
> >> 
> >> it into the imx28evk and enter u-boot command line.  I then do:
> >>  usb start
> >>  fatload usb 0 0x4200 uimage
> >>  fatload usb 0 0x4300 rootfs-initrd
> >>  setenv bootargs console=ttyAM0,115200n8 debug root=/dev/ram rw
> >> 
> >> ip=dhcp  fec_mac=
> >> 
> >>  bootm 0x4200 0x4300
> >> 
> >> u-boot then starts booting with:
> >> 
> >> ## Booting kernel from Legacy Image at 4200 ...
> >> 
> >>  Image Name:   Linux-2.6.35.3-571-gcca29a0-g45b
> >>  Created:  2012-09-08  22:31:46 UTC
> >>  Image Type:   ARM Linux Kernel Image (uncompressed)
> >>  Data Size:2582304 Bytes = 2.5 MiB
> >>  Load Address: 40008000
> >>  Entry Point:  40008000
> >>  Verifying Checksum ... OK
> >> 
> >> ## Loading init Ramdisk from Legacy Image at 4300 ...
> >> 
> >>  Image Name:   MyRamDisk
> >>  Created:  2012-09-12  20:51:35 UTC
> >>  Image Type:   ARM Linux RAMDisk Image (uncompressed)
> >>  Data Size:37774 Bytes = 36.9 KiB
> >>  Load Address: 
> >>  Entry Point:  
> >>  Verifying Checksum ... OK
> >>  Loading Kernel Image ... OK
> >> 
> >> OK
> >> 
> >> Starting kernel ...
> >> 
> >> Uncompressing Linux... done, booting the kernel.
> >> Linux version 2.6.35.3-571-gcca29a0-g45b53d0-dirty (blsousan@ubuntu)
> >> (gcc version 4.4.4 (4.4.4_09.06.2010) ) #13 PREEMPT Sat Sep 8 14:06:34
> >> PDT 2012
> >> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
> >> CPU: VIVT data cache, VIVT instruction cache
> >> Machine: Freescale MX28EVK board
> >> 
> >> 
> >> 
> >> 
> >> The kernel starts to boot, I get all the kernel output, and at the end
> >> it does not find the rootfs.  I get:
> >> 
> >> ...
> >> ...
> >> ...
> >> 
> >> List of all partitions:
> >> b300 3872256 mmcblk0 driver: mmcblk
> >> 
> >> b3011024 mmcblk0p1
> >> 
> >> 0800  503808 sda driver: sd
> >> 
> >> 0801  503792 sda1
> >> 
> >> No filesystem could mount root, tried:  ext3 ext2 vfat msdos iso9660
> >> Kernel panic - not syncing: VFS: Unable to mount root fs on
> >> unknown-block(1,0)
> >> Backtrace:
> >> 
> >> 
> >> I not sure how the kernel knows where the ramdisk lives in memory (
> >> 0x4300) where the the uboot put it ?
> >> 
> >> 
> >> Thanks,
> >> Bill
> >> 
> >> On 9/12/2012 5:29 PM, Marek Vasut wrote:
> >>> Dear Bill,
> >>> 
>  Has anyone used U-boot on the imx28evk with initrd to setup a small
>  rootfs in RAM?  I need the ability to do have a small temp rootfs to
>  assist in mounting a full rootfs from a USB for field upgrade
>  purposes.
> >>> 
> >>> Yes, it's a linux thingie though. What's the problem? What version of
> >>> uboot do you use?
> > 
> > Some ancient kernel you have ... did you enable ramdisk support in Linux?
> > And gz

Re: [U-Boot] [PATCH 15/16] arm:trats:pmic: Support for charging battery at Samsung's TRATS board

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/17/12 13:55, Lukasz Majewski wrote:
> Hi Tom ,
> 
>> If I read this right we'll pause in the middle of start up to
>> charge the battery for possibly a long time right?  And this
>> could be a while loop even, yes?  If so to the first one, this
>> really should be under some sort of CONFIG option.
> 
> This is one of the options. Other option is to extend the
> pmic/power command to:
> 
> pmic charger on/off to recharge battery when needed.
> 
> I think, that above is a better solution.
> 
>> I know the value of showing proof of concept type examples in
>> development boards but that should still be an opt-in thing I
>> would think.
> 
> Yes, indeed this shall be regarded as a proof-of-concept to show
> that battery is automatically charged when needed.
> 
> Instead, I think, that it would be a good idea to write a warning
> on the u-boot starting (when PMIC driver is initialized):
> 
> e.g. WARNING: Battery needs charging (voltage: 3.5V capacity: 8%)
> 
> And then user can on its own decide if he/she will charge the
> battery or not.

Yes, sounds good, thanks!

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

iQIcBAEBAgAGBQJQV5XMAAoJENk4IS6UOR1WnXYP/iZdtirR6Rflcp/YZSna/ld0
SsW0cW8fGT+Hy44T2pOsd4m0ne/WnTq6EUPJqQ1xs+ZIjj55Uh2ngLdc3/PpMC10
mi+vzm3E1wi8Wm83205r+7DAWnD20JXE413WimaBnP+EbVJzBjtZDFyFwtpvKnFd
G2SyVyUsyBATsMFpfz7yFwNPYB9JoG/XgsLK64nP3wCVt/gSB6hE+ZBrRQgKvvsn
AvQV3JhZbPMSWIj9Qq1qY8ReA2fC5SXBft/mcOt6cee7dTlaTzXkK3dxDQkmzOF8
l1Lhm3h/QMQ6/+mlghk9tZmfR7kXH54Ak0tZWLXQiT86namTymvgQ/SyOE8B0Rf8
p0+rD6X9WcuirhyeoKOmQS/cx6S1evNuPXJiRRGN3Y52nwWEnYlsDyDWEOqqLa70
466hdJhLm14HguJCsRbjs2l+rJ4pRj0WaKio7dq3uk0ojwueZRqSZyI6UEBQLMQU
NBZExliUI+6TNBFVdmpaRe9cKVaDIbmtFWH8yl6xNAsU0MgOH15OsZOdQUO3bTgb
sZPKHWKhiZbS16kMGGdvcb18up1qA/oXZJcnPD/rmyCQ4Tq/Z6eOt9CRwZyLss9p
cUVb2PXJ6X4r6eTaK9HMAAk9zYZkk0pcmZcczsdcNhVv3MJlxwmNEfYY6RXfRdaI
Dh3242syeDsez5ZQ3Uou
=v4oy
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] video/powerpc: don't touch DIU registers that we don't need

[Timur Tabi]

Several DIU registers were being initialized either unnecessarily or to
wrong values.

1) All interrupts were enabled even though there's no interrupt handler.
   Interrupts were left enabled when booting Linux.

2) Don't configure a dummy area descriptor, since we don't support ADs
   in U-Boot.

3) Don't configure any write-back buffer registers, since we don't use
   that mode.

4) The default values for the THRESHOLDS, SYN_POL, and PLUT registers
   should be used, so don't touch those registers either.

Signed-off-by: Timur Tabi 
---
 drivers/video/fsl_diu_fb.c |   21 ++---
 1 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/video/fsl_diu_fb.c b/drivers/video/fsl_diu_fb.c
index 648ffa3..a98cb67 100644
--- a/drivers/video/fsl_diu_fb.c
+++ b/drivers/video/fsl_diu_fb.c
@@ -271,7 +271,6 @@ int fsl_diu_init(u16 xres, u16 yres, u32 pixel_format, int 
gamma_fix)
struct diu *hw = (struct diu *)CONFIG_SYS_DIU_ADDR;
u8 *gamma_table_base;
unsigned int i, j;
-   struct diu_ad *dummy_ad;
struct diu_addr gamma;
struct diu_addr cursor;
 
@@ -302,14 +301,6 @@ int fsl_diu_init(u16 xres, u16 yres, u32 pixel_format, int 
gamma_fix)
return -1;
}
 
-   /* The AD struct for the dummy framebuffer and the FB itself */
-   dummy_ad = allocate_fb(2, 4, 4, NULL);
-   if (!dummy_ad) {
-   printf("DIU:   Out of memory\n");
-   return -1;
-   }
-   dummy_ad->pix_fmt = 0x3316;
-
/* read mode info */
info.var.xres = fsl_diu_mode_db->xres;
info.var.yres = fsl_diu_mode_db->yres;
@@ -376,10 +367,7 @@ int fsl_diu_init(u16 xres, u16 yres, u32 pixel_format, int 
gamma_fix)
out_be32(&hw->gamma, gamma.paddr);
out_be32(&hw->cursor, cursor.paddr);
out_be32(&hw->bgnd, 0x007F7F7F);
-   out_be32(&hw->bgnd_wb, 0);
out_be32(&hw->disp_size, info.var.yres << 16 | info.var.xres);
-   out_be32(&hw->wb_size, 0);
-   out_be32(&hw->wb_mem_addr, 0);
out_be32(&hw->hsyn_para, info.var.left_margin << 22 |
info.var.hsync_len << 11 |
info.var.right_margin);
@@ -388,18 +376,13 @@ int fsl_diu_init(u16 xres, u16 yres, u32 pixel_format, 
int gamma_fix)
info.var.vsync_len << 11 |
info.var.lower_margin);
 
-   out_be32(&hw->syn_pol, 0);
-   out_be32(&hw->thresholds, 0x00037800);
-   out_be32(&hw->int_status, 0);
-   out_be32(&hw->int_mask, 0);
-   out_be32(&hw->plut, 0x01F5F666);
/* Pixel Clock configuration */
diu_set_pixel_clock(info.var.pixclock);
 
/* Set the frame buffers */
out_be32(&hw->desc[0], virt_to_phys(ad));
-   out_be32(&hw->desc[1], virt_to_phys(dummy_ad));
-   out_be32(&hw->desc[2], virt_to_phys(dummy_ad));
+   out_be32(&hw->desc[1], 0);
+   out_be32(&hw->desc[2], 0);
 
/* Enable the DIU, set display to all three planes */
out_be32(&hw->diu_mode, 1);
-- 
1.7.3.4


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

Re: [U-Boot] [PATCH 0/2] i.MX6: mx6qsabrelite: Add splash screen support

[Anatolij Gustschin]

Hi Eric,

On Mon, 17 Sep 2012 13:20:49 -0700
Eric Nelson  wrote:

> Series includes one patch to fix a register name in imx6/crm_regs.h
> and a second that's a re-base of Fabio's patch from 5/31.
> http://patchwork.ozlabs.org/patch/162206/
> 
> Note that I'm not sure whether this should have been based on 
> u-boot-video because it's video-related or u-boot imx because
> the bulk of the patch set is board-specific. 

It should be based on u-boot-imx since it touches board files.

Thanks,

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

Re: [U-Boot] [PATCH v3 2/4] usb: ehci: rework to take advantage of new lowlevel interface

[Marek Vasut]

Dear Lucas Stach,

[...]

> diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c
> index 6e21669..a74c1c2 100644
> --- a/drivers/usb/host/ehci-mxs.c
> +++ b/drivers/usb/host/ehci-mxs.c
> @@ -27,7 +27,6 @@
>  #include 
>  #include 
> 
> -#include "ehci-core.h"
>  #include "ehci.h"
> 
>  #if  (CONFIG_EHCI_MXS_PORT != 0) && (CONFIG_EHCI_MXS_PORT != 1)
> @@ -70,7 +69,7 @@ int mxs_ehci_get_port(struct ehci_mxs *mxs_usb, int port)
>  #define  HW_DIGCTL_CTRL_USB0_CLKGATE (1 << 2)
>  #define  HW_DIGCTL_CTRL_USB1_CLKGATE (1 << 16)
> 
> -int ehci_hcd_init(void)
> +int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor
> **hcor) {
> 
>   int ret;
> @@ -107,28 +106,35 @@ int ehci_hcd_init(void)
>   &ehci_mxs.phy_regs->hw_usbphy_ctrl_set);
> 
>   usb_base = ((uint32_t)ehci_mxs.usb_regs) + 0x100;
> - hccr = (struct ehci_hccr *)usb_base;
> + *hccr = (struct ehci_hccr *)usb_base;
> 
> - cap_base = ehci_readl(&hccr->cr_capbase);
> - hcor = (struct ehci_hcor *)(usb_base + HC_LENGTH(cap_base));
> + cap_base = ehci_readl(&(*hccr)->cr_capbase);
> + *hcor = (struct ehci_hcor *)(usb_base + HC_LENGTH(cap_base));
> 
>   return 0;
>  }
> 
> -int ehci_hcd_stop(void)
> +int ehci_hcd_stop(int index)
>  {
>   int ret;
> - uint32_t tmp;
> - struct mxs_register_32 *digctl_ctrl =
> - (struct mxs_register_32 *)HW_DIGCTL_CTRL;
> - struct mxs_clkctrl_regs *clkctrl_regs =
> - (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
> + uint32_t usb_base, cap_base, tmp;
> + struct mx28_register_32 *digctl_ctrl =
> + (struct mx28_register_32 *)HW_DIGCTL_CTRL;
> + struct mx28_clkctrl_regs *clkctrl_regs =
> + (struct mx28_clkctrl_regs *)MXS_CLKCTRL_BASE;

What is this crap in here ?! It broke build. Did you even bother to 
compile-test 
the series?

Discarding the whole patchset, please resubmit something that's not broken.

> + struct ehci_hccr *hccr;
> + struct ehci_hcor *hcor;
> 
>   ret = mxs_ehci_get_port(&ehci_mxs, CONFIG_EHCI_MXS_PORT);
>   if (ret)
>   return ret;
> 
>   /* Stop the USB port */
> + usb_base = ((uint32_t)ehci_mxs.usb_regs) + 0x100;
> + hccr = (struct ehci_hccr *)usb_base;
> + cap_base = ehci_readl(&hccr->cr_capbase);
> + hcor = (struct ehci_hcor *)(usb_base + HC_LENGTH(cap_base));
> +
>   tmp = ehci_readl(&hcor->or_usbcmd);
>   tmp &= ~CMD_RUN;
>   ehci_writel(tmp, &hcor->or_usbcmd);

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

Re: [U-Boot] [PATCH 2/2] i.MX6: mx6qsabrelite: Add splash screen support

[Fabio Estevam]

Hi Eric,

On Mon, Sep 17, 2012 at 5:20 PM, Eric Nelson
 wrote:

> +int board_late_init(void)
> +{
> +   setenv("stdout", "serial");
> +   return 0;
> +}

I was told not to do this way.

Please follow this approach instead:

commit 3e0773708dd4e502c127a589be5779708eb7ba69
Author: Stefano Babic 
Date:   Sun Aug 5 00:18:53 2012 +

MX5: mx53loco: do not overwrite the console

On this board, the console is always set to the serial line.
Do not allow to overwrite it when video is enabled.

Signed-off-by: Stefano Babic 
CC: Fabio Estevam 
Tested-by: Fabio Estevam 

Regards,

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

[U-Boot] [PATCH 2/2] i.MX6: mx6qsabrelite: Add splash screen support

[Eric Nelson]

Adds support for the Hannstar 1024 x 768 LVDS panel (Freescale part 
number MCIMX-LVDS1) to SABRE-Lite board.

This commit is a rebase Fabio Estevan's patch from 5/31 to
u-boot-video/master:
http://patchwork.ozlabs.org/patch/162206/

Modifications include:
removal of i2c setup (unneeded)
cleanup of lcd_iomux to use struct mxc_ccm_reg and anatop_regs
and associated constants

Signed-off-by: Eric Nelson 
---
 arch/arm/include/asm/arch-mx6/crm_regs.h  |4 +
 board/freescale/mx6qsabrelite/mx6qsabrelite.c |   90 +
 include/configs/mx6qsabrelite.h   |   14 -
 3 files changed, 107 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h 
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 8388e38..cffc0a1 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -294,6 +294,10 @@ struct mxc_ccm_reg {
 #define MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK  (0x7)
 #define MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET0
 
+#define CHSCCDR_CLK_SEL_LDB_DI03
+#define CHSCCDR_PODF_DIVIDE_BY_3   2
+#define CHSCCDR_IPU_PRE_CLK_540M_PFD   5
+
 /* Define the bits in register CSCDR2 */
 #define MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK (0x3F << 19)
 #define MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET   19
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c 
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 909ccca..22943b1 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -36,6 +36,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 DECLARE_GLOBAL_DATA_PTR;
 
 #define UART_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |   \
@@ -195,6 +198,10 @@ static iomux_v3_cfg_t button_pads[] = {
MX6Q_PAD_GPIO_18__GPIO_7_13 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
 };
 
+iomux_v3_cfg_t lcd_gpio[] = {
+   MX6Q_PAD_SD1_CMD__GPIO_1_18 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
 static void setup_iomux_enet(void)
 {
gpio_direction_output(87, 0);  /* GPIO 3-23 */
@@ -372,10 +379,84 @@ int setup_sata(void)
 }
 #endif
 
+static struct fb_videomode lvds_xga = {
+   .name   = "Hannstar-XGA",
+   .refresh= 60,
+   .xres   = 1024,
+   .yres   = 768,
+   .pixclock   = 15385,
+   .left_margin= 220,
+   .right_margin   = 40,
+   .upper_margin   = 21,
+   .lower_margin   = 7,
+   .hsync_len  = 60,
+   .vsync_len  = 10,
+   .sync   = FB_SYNC_EXT,
+   .vmode  = FB_VMODE_NONINTERLACED
+};
+
+void lcd_iomux(void)
+{
+   struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+   struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+
+   int reg;
+   /* Turn on GPIO backlight */
+   imx_iomux_v3_setup_multiple_pads(lcd_gpio, ARRAY_SIZE(lcd_gpio));
+   gpio_direction_output(18, 1);
+
+   /* Turn on LDB0,IPU,IPU DI0 clocks */
+   reg = __raw_readl(&mxc_ccm->CCGR3);
+   reg |= 0x300F;
+   writel(reg, &mxc_ccm->CCGR3);
+
+   /* set PFD3_FRAC to 0x13 == 455 MHz (480*18)/0x13 */
+   writel(0x3F00, &anatop->pfd_480_clr);
+   writel(0x1300, &anatop->pfd_480_set);
+
+   /* set LDB0, LDB1 clk select to 011/011 */
+   reg = readl(&mxc_ccm->cs2cdr);
+   reg &= ~(MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_MASK
+|MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_MASK);
+   reg |= (3cscmr2);
+   reg |= MXC_CCM_CSCMR2_LDB_DI0_IPU_DIV;
+   writel(reg, &mxc_ccm->cscmr2);
+
+   reg = readl(&mxc_ccm->chsccdr);
+   reg &= ~(MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_MASK
+   |MXC_CCM_CHSCCDR_IPU1_DI0_PODF_MASK
+   |MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK);
+   /* derive clock from LDB_DI0 */
+   /* divide by 3 */
+   /* derive clock from 540M PFD */
+   reg |= (CHSCCDR_CLK_SEL_LDB_DI0
+   

[U-Boot] [PATCH 1/2] i.MX6: change register name for CCM_CHSCCDR to match ref. manual

[Eric Nelson]

Register CCM_CHSCCDR (offset 0x34 in CCM) is named CCM_CHSCCDR in
reference manual, but was named chscdr in struct mxc_ccm_reg.

Signed-off-by: Eric Nelson 
---
 arch/arm/include/asm/arch-mx6/crm_regs.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h 
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 0e605c2..8388e38 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -34,7 +34,7 @@ struct mxc_ccm_reg {
u32 cs1cdr;
u32 cs2cdr;
u32 cdcdr;  /* 0x0030 */
-   u32 chscdr;
+   u32 chsccdr;
u32 cscdr2;
u32 cscdr3;
u32 cscdr4; /* 0x0040 */
-- 
1.7.9

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

[U-Boot] [PATCH 0/2] i.MX6: mx6qsabrelite: Add splash screen support

[Eric Nelson]

Series includes one patch to fix a register name in imx6/crm_regs.h
and a second that's a re-base of Fabio's patch from 5/31.
http://patchwork.ozlabs.org/patch/162206/

Note that I'm not sure whether this should have been based on 
u-boot-video because it's video-related or u-boot imx because
the bulk of the patch set is board-specific. 

 arch/arm/include/asm/arch-mx6/crm_regs.h  |6 ++-
 board/freescale/mx6qsabrelite/mx6qsabrelite.c |   90 +
 include/configs/mx6qsabrelite.h   |   14 -
 3 files changed, 108 insertions(+), 2 deletions(-)

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

[U-Boot] [PATCH v6 1/4] net/bootp: add VCI support for BOOTP also

[Ilya Yanok]

Vendor Class Identifier option is common to BOOTP and DHCP and
can be useful without PXE. So send VCI in both BOOTP and DHCP
requests if CONFIG_BOOTP_VCI_STRING is defined.

Signed-off-by: Ilya Yanok 

---
Changes in v4:
 - used strlen instead of sizeof
 - moved vci_strlen var inside macro

 net/bootp.c |   22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/net/bootp.c b/net/bootp.c
index c9b8349..35b2e77 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -341,6 +341,15 @@ BootpTimeout(void)
}
 }
 
+#define put_vci(e, str)\
+   do {\
+   size_t vci_strlen = strlen(str);\
+   *e++ = 60;  /* Vendor Class Identifier */   \
+   *e++ = vci_strlen;  \
+   memcpy(e, str, vci_strlen); \
+   e += vci_strlen;\
+   } while (0)
+
 /*
  * Initialize BOOTP extension fields in the request.
  */
@@ -352,7 +361,6 @@ static int DhcpExtended(u8 *e, int message_type, IPaddr_t 
ServerID,
u8 *cnt;
 #if defined(CONFIG_BOOTP_PXE)
char *uuid;
-   size_t vci_strlen;
u16 clientarch;
 #endif
 
@@ -437,12 +445,10 @@ static int DhcpExtended(u8 *e, int message_type, IPaddr_t 
ServerID,
printf("Invalid pxeuuid: %s\n", uuid);
}
}
+#endif
 
-   *e++ = 60;  /* Vendor Class Identifier */
-   vci_strlen = strlen(CONFIG_BOOTP_VCI_STRING);
-   *e++ = vci_strlen;
-   memcpy(e, CONFIG_BOOTP_VCI_STRING, vci_strlen);
-   e += vci_strlen;
+#ifdef CONFIG_BOOTP_VCI_STRING
+   put_vci(e, CONFIG_VCI_STRING);
 #endif
 
 #if defined(CONFIG_BOOTP_VENDOREX)
@@ -529,6 +535,10 @@ static int BootpExtended(u8 *e)
*e++ = (576 - 312 + OPT_FIELD_SIZE) & 0xff;
 #endif
 
+#ifdef CONFIG_BOOTP_VCI_STRING
+   put_vci(e, CONFIG_VCI_STRING);
+#endif
+
 #if defined(CONFIG_BOOTP_SUBNETMASK)
*e++ = 1;   /* Subnet mask request */
*e++ = 4;
-- 
1.7.9.5

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

[U-Boot] [PATCH v6 3/4] OMAP: networking support for SPL

[Ilya Yanok]

This patch adds support for networking in SPL. Some devices are
capable of loading SPL via network so it makes sense to load the
main U-Boot binary via network too. This patch tries to use
existing network code as much as possible. Unfortunately, it depends
on environment which in turn depends on other code so SPL size
is increased significantly. No effort was done to decouple network
code and environment so far.

Signed-off-by: Ilya Yanok 

---
Changes in v3:
 - use BOOTP in SPL regardless of CONFIG_CMD_DHCP
 - add support for setting different VCI in SPL

Changes in v4:
 - fix compilation of SPL's libcommon with CONFIG_HUSH_PARSER
   and CONFIG_BOOTD defined
 - rename spl_eth.c to spl_net.c
 - set ethact variable if device name is passed

Changes in v5:
 - set up guards in cmd_nvedit.c more carefully
 - now we don't need command.c and only need main.c for
   show_boot_progress() so defined it to be noop and remove
   both files from SPL sources
 - SPL guards in command.c and main.c are no longer needed
 - add some guards in env_common.c
 - qsort.c is no longer needed
 - add guard to hashtable.c to save some space
 - undefine unneeded CONFIG_CMD_* while building SPL to save space

Changes in v6:
 - remove some unneeded changes introduced by earlier versions
 - switch clauses and use ifdef instead of ifndef
 - create new header config_uncmd_spl.h which undefines CONFIG_CMD_*
   options unneeded in SPL and include it last from config.h
 - remove explicit undefs from net/net.c and net/bootp.c

 arch/arm/cpu/armv7/omap-common/Makefile  |3 ++
 arch/arm/cpu/armv7/omap-common/spl.c |9 ++
 arch/arm/cpu/armv7/omap-common/spl_net.c |   52 ++
 arch/arm/include/asm/omap_common.h   |4 +++
 common/Makefile  |4 +++
 common/cmd_nvedit.c  |8 +
 common/env_common.c  |7 ++--
 include/bootstage.h  |6 +++-
 include/config_uncmd_spl.h   |   24 ++
 lib/Makefile |9 --
 lib/hashtable.c  |2 ++
 lib/vsprintf.c   |2 +-
 mkconfig |1 +
 net/bootp.c  |7 +++-
 net/tftp.c   |4 +++
 spl/Makefile |3 ++
 16 files changed, 138 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap-common/spl_net.c
 create mode 100644 include/config_uncmd_spl.h

diff --git a/arch/arm/cpu/armv7/omap-common/Makefile 
b/arch/arm/cpu/armv7/omap-common/Makefile
index d37b22d..f042078 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -53,6 +53,9 @@ endif
 ifdef CONFIG_SPL_YMODEM_SUPPORT
 COBJS  += spl_ymodem.o
 endif
+ifdef CONFIG_SPL_NET_SUPPORT
+COBJS  += spl_net.o
+endif
 endif
 
 ifndef CONFIG_SPL_BUILD
diff --git a/arch/arm/cpu/armv7/omap-common/spl.c 
b/arch/arm/cpu/armv7/omap-common/spl.c
index f0d766c..53b9261 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -178,6 +178,15 @@ void board_init_r(gd_t *id, ulong dummy)
spl_ymodem_load_image();
break;
 #endif
+#ifdef CONFIG_SPL_ETH_SUPPORT
+   case BOOT_DEVICE_CPGMAC:
+#ifdef CONFIG_SPL_ETH_DEVICE
+   spl_net_load_image(CONFIG_SPL_ETH_DEVICE);
+#else
+   spl_net_load_image(NULL);
+#endif
+   break;
+#endif
default:
printf("SPL: Un-supported Boot Device - %d!!!\n", boot_device);
hang();
diff --git a/arch/arm/cpu/armv7/omap-common/spl_net.c 
b/arch/arm/cpu/armv7/omap-common/spl_net.c
new file mode 100644
index 000..cbb3087
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/spl_net.c
@@ -0,0 +1,52 @@
+/*
+ * (C) Copyright 2000-2004
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * (C) Copyright 2012
+ * Ilya Yanok 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.
+ */
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void spl_net_load_image(const char *device)
+{
+   int rv;
+
+   env_init();
+   env_relocate();
+   setenv("autoload", "yes");
+   

[U-Boot] [PATCH v6 4/4] am335x_evm: enable networking in SPL

[Ilya Yanok]

This patch adds support for networking in SPL on TI AM335x based
boards. Vendor Class Identifier used by SPL during BOOTP is
"AM335x U-Boot SPL".

Signed-off-by: Ilya Yanok 

---
Changes in v3:
 - set Vendor Class Identifier for SPL

Changes in v4:
 - SPL_BOARD_INIT is not needed anymore

 include/configs/am335x_evm.h |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index a3752bc..1d69125 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -194,7 +194,7 @@
 /* Defines for SPL */
 #define CONFIG_SPL
 #define CONFIG_SPL_TEXT_BASE   0x402F0400
-#define CONFIG_SPL_MAX_SIZE(46 * 1024)
+#define CONFIG_SPL_MAX_SIZE(101 * 1024)
 #define CONFIG_SPL_STACK   CONFIG_SYS_INIT_SP_ADDR
 
 #define CONFIG_SPL_BSS_START_ADDR  0x8000
@@ -214,6 +214,9 @@
 #define CONFIG_SPL_SERIAL_SUPPORT
 #define CONFIG_SPL_GPIO_SUPPORT
 #define CONFIG_SPL_YMODEM_SUPPORT
+#define CONFIG_SPL_NET_SUPPORT
+#define CONFIG_SPL_NET_VCI_STRING  "AM335x U-Boot SPL"
+#define CONFIG_SPL_ETH_SUPPORT
 #define CONFIG_SPL_LDSCRIPT"$(CPUDIR)/omap-common/u-boot-spl.lds"
 
 /*
-- 
1.7.9.5

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

[U-Boot] [PATCH v6 0/4] OMAP: SPL networking support

[Ilya Yanok]

These series provides support for networking in SPL.
In this version some effort is done to minimize the resulting SPL
size and now Net-only SPL is <50KB in size. So theoretically it
can be used on boards with enough SRAM space like AM3517.
But real testing was done only on AM335x.


Changes in v3:
 - use BOOTP in SPL regardless of CONFIG_CMD_DHCP
 - add support for setting different VCI in SPL
 - set Vendor Class Identifier for SPL

Changes in v4:
 - used strlen instead of sizeof
 - moved vci_strlen var inside macro
 - fix compilation of SPL's libcommon with CONFIG_HUSH_PARSER
   and CONFIG_BOOTD defined
 - rename spl_eth.c to spl_net.c
 - set ethact variable if device name is passed
 - SPL_BOARD_INIT is not needed anymore

Changes in v5:
 - set up guards in cmd_nvedit.c more carefully
 - now we don't need command.c and only need main.c for
   show_boot_progress() so defined it to be noop and remove
   both files from SPL sources
 - SPL guards in command.c and main.c are no longer needed
 - add some guards in env_common.c
 - qsort.c is no longer needed
 - add guard to hashtable.c to save some space
 - undefine unneeded CONFIG_CMD_* while building SPL to save space

Changes in v6:
 - fix typo in patch name
 - remove some unneeded changes introduced by earlier versions
 - switch clauses and use ifdef instead of ifndef
 - create new header config_uncmd_spl.h which undefines CONFIG_CMD_*
   options unneeded in SPL and include it last from config.h
 - remove explicit undefs from net/net.c and net/bootp.c

Ilya Yanok (4):
  net/bootp: add VCI support for BOOTP also
  OMAP: spl: call timer_init() from SPL
  OMAP: networking support for SPL
  am335x_evm: enable networking in SPL

 arch/arm/cpu/armv7/omap-common/Makefile  |3 ++
 arch/arm/cpu/armv7/omap-common/spl.c |   11 +++
 arch/arm/cpu/armv7/omap-common/spl_net.c |   52 ++
 arch/arm/include/asm/omap_common.h   |4 +++
 common/Makefile  |4 +++
 common/cmd_nvedit.c  |8 +
 common/env_common.c  |7 ++--
 include/bootstage.h  |6 +++-
 include/config_uncmd_spl.h   |   24 ++
 include/configs/am335x_evm.h |5 ++-
 lib/Makefile |9 --
 lib/hashtable.c  |2 ++
 lib/vsprintf.c   |2 +-
 mkconfig |1 +
 net/bootp.c  |   27 
 net/tftp.c   |4 +++
 spl/Makefile |3 ++
 17 files changed, 159 insertions(+), 13 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap-common/spl_net.c
 create mode 100644 include/config_uncmd_spl.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 v6 2/4] OMAP: spl: call timer_init() from SPL

[Ilya Yanok]

We need to initialize timer properly, otherwise all delays
inside SPL will be wrong.

Signed-off-by: Ilya Yanok 

---
Changes in v6:
 - fix typo in patch name

 arch/arm/cpu/armv7/omap-common/spl.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap-common/spl.c 
b/arch/arm/cpu/armv7/omap-common/spl.c
index 4d1ac85..f0d766c 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -152,6 +152,8 @@ void board_init_r(gd_t *id, ulong dummy)
mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
CONFIG_SYS_SPL_MALLOC_SIZE);
 
+   timer_init();
+
 #ifdef CONFIG_SPL_BOARD_INIT
spl_board_init();
 #endif
-- 
1.7.9.5

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

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

[Tom Rini]

On Mon, Sep 17, 2012 at 07:52:26PM +0200, Marek Vasut wrote:
> I'm not sure if we want them in current release or next, I'll leave that to 
> you 
> to decide. I don't see much danger for current though.
> 
> The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 
> 09:17:27 
> +0200)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 8187c2dcbd3e47ecfef406468c8eee1fe746b8e7:
> 
>   usb: do explicit unaligned accesses (2012-09-06 08:02:08 +0200)
> 
> 
> Lucas Stach (5):
>   usb: lowlevel interface change to support multiple controllers
>   usb: ehci: rework to take advantage of new lowlevel interface
>   usb: add support for multiple usb controllers
>   tegra20: port to new ehci interface
>   usb: do explicit unaligned accesses
> 
> ??ukasz Majewski (2):
>   dfu:usb: Support for ext4
>   dfu:usb:fix: Read the "filesize" environment variable only when file 
> read
> 
>  arch/arm/cpu/arm920t/s3c24x0/usb_ohci.c   |4 +--
>  arch/arm/cpu/armv7/tegra20/usb.c  |   15 +++--
>  arch/arm/include/asm/arch-tegra20/usb.h   |4 +--
>  arch/arm/include/asm/ehci-omap.h  |   10 +-
>  arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.c |4 +--
>  arch/powerpc/cpu/mpc5xxx/usb_ohci.c   |4 +--
>  arch/powerpc/cpu/ppc4xx/usb_ohci.c|4 +--
>  arch/sparc/cpu/leon3/usb_uhci.c   |4 +--
>  arch/sparc/lib/bootm.c|2 +-
>  board/htkw/mcx/mcx.c  |6 ++--
>  board/mpl/common/usb_uhci.c   |4 +--
>  board/technexion/twister/twister.c|6 ++--
>  board/teejet/mt_ventoux/mt_ventoux.c  |6 ++--
>  board/ti/beagle/beagle.c  |6 ++--
>  board/ti/panda/panda.c|6 ++--
>  common/cmd_usb.c  |   16 ++---
>  common/usb.c  |  108 
> +
>  common/usb_hub.c  |   16 +
>  common/usb_storage.c  |2 +-
>  drivers/dfu/dfu_mmc.c |   34 +++
>  drivers/usb/eth/usb_ether.c   |2 +-
>  drivers/usb/host/ehci-armada100.c |   15 -
>  drivers/usb/host/ehci-atmel.c |   11 +++
>  drivers/usb/host/ehci-core.h  |   29 -
>  drivers/usb/host/ehci-exynos.c|   15 -
>  drivers/usb/host/ehci-fsl.c   |   11 +++
>  drivers/usb/host/ehci-hcd.c   |  131 
> +-
>  drivers/usb/host/ehci-ixp4xx.c|   15 -
>  drivers/usb/host/ehci-marvell.c   |   15 -
>  drivers/usb/host/ehci-mpc512x.c   |   25 ++
>  drivers/usb/host/ehci-mx5.c   |   11 +++
>  drivers/usb/host/ehci-mx6.c   |   11 +++
>  drivers/usb/host/ehci-mxc.c   |   11 +++
>  drivers/usb/host/ehci-mxs.c   |   28 +---
>  drivers/usb/host/ehci-omap.c  |   10 +++---
>  drivers/usb/host/ehci-pci.c   |   15 -
>  drivers/usb/host/ehci-ppc4xx.c|   11 +++
>  drivers/usb/host/ehci-tegra.c |   14 
>  drivers/usb/host/ehci-vct.c   |9 +++---
>  drivers/usb/host/ehci.h   |4 +--
>  drivers/usb/host/isp116x-hcd.c|4 +--
>  drivers/usb/host/ohci-hcd.c   |4 +--
>  drivers/usb/host/r8a66597-hcd.c   |4 +--
>  drivers/usb/host/sl811-hcd.c  |4 +--
>  drivers/usb/musb/musb_hcd.c   |4 +--
>  include/usb.h |   10 --
>  include/usb/mv_udc.h  |2 +-
>  47 files changed, 352 insertions(+), 334 deletions(-)
>  delete mode 100644 drivers/usb/host/ehci-core.h

This breaks at least:
ARM: m28evk apx4devkit sc_sps_1 mx28evk
PowerPC: Everything that uses ehci-fsl.c, the first of which I saw was
P2020RDB_36BIT but there's approx 141 boards total broken with MAKEALL
-a powerpc.

Rejected, please re-work.

-- 
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 v2 10/11] Add u-boot-ubl.bin target to the Makefile

[Wolfgang Denk]

Dear Tom Rini,

In message <505763a5.1030...@ti.com> you wrote:
>
> Right.  So I'm saying we need to set new expectations for everyone and
> some human helper symlinks to help.  A new top-level out or images or
> something, with symlinks inside.

Why would we need that?

For the end user, any name is good enough, as long as it's clearly
documented which file to use, and what exactly to do with it.  There
are so many different boot formatrequirements, that we canot expect to
come up with "good" names for all of these in any way that matches all
people's expectations because everything is completely
self-explanatory.

Make it simple, and handle it in the documentation.

> I think we're running into PowerPC vs ARM "fun".  We've got 7 or so
> different "whack the image for this SoC for this medium" type things
> already.

I don't think it's an PPC versus ARM issue  It's more an "good old
times" versus "brave new world" thing.  Actually Shakespeare's verses
apply fully to many of teh recent SoC designs - be these PPC or ARM or
whatever based:

O wonder!
How many goodly creatures are there here!
How beauteous mankind is! O brave new world,
That has such people in't.
—William Shakespeare, The Tempest, Act V, Scene I, ll. 203—6

Thinking about features, boot image formats, boot device selection and
other boot requirements of the ROM boot loaders of any recent SoC
indeed makes me wonder "How many goodly creatures are there here!"

PS: The "good" in this reference is to be understood in the same
sense as the "best" in the name of the MPC5200 BestComm DMA
controller.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"In the long run, every program becomes rococo, and then rubble."
- Alan Perlis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Marek Vasut]

Dear Tom Rini,

> On 09/17/12 10:52, Marek Vasut wrote:
> > I'm not sure if we want them in current release or next, I'll
> > leave that to you to decide. I don't see much danger for current
> > though.
> 
> I believe all of this made it by the merge window and looks good.

It's been stuck in there for a while, yes.

> But
> in the future please only pull request code you believe to be ready
> for mainline.  If you aren't sure, test it more, review it more and be
> sure.  I'm relying on all of the custodians and their judgement of
> what is, and is not, ready to go.  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] Fix checkpatch warnings about externs in *.c

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/16/12 05:59, Pavel Herrmann wrote:
> On Sunday 16 September 2012 14:37:16 Marek Vasut wrote:
>> Dear Pavel Herrmann, ... Won't include/sata.h work just fine ?
> 
> I feel include/sata.h is a "consumer-facing" header, and
> implementation details such as the array used for all
> data-retention for command and drivers should not be there.

But it needs to be in sync with common/cmd_sata.c which is where both
that and sata_curr_device are defined.  So please use sata.h.  I will
also state this doesn't seem to be ideal but it's how our sata
"subsystem" is setup currently.

- -- 
Tom

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

iQIcBAEBAgAGBQJQV3RiAAoJENk4IS6UOR1WszYP/jK3Llu0R1H4a57Me1k56Afu
qniSbmI9pNr8eA6Bf5NxC7clvnK6HOBHWMegX6V42P4Dxy2/Bhod0K24RppsWaFs
Wj604F+3gWWy/fhCojw6kVyzjV2WBlBse51XBHEMjNa5Ftf33lOKxr2mHNG5XrSD
IL9uxRTwlwhKhs/WJ8HwH3C4Eo/zBG2AoIXbqmoyvqr/7gqGcERdo7NWtHPUrLwB
smgJkL6t91MULlZc/RMwGTtX7CoKv0YbM+swWqY3rBQ7jQrP31vH8e6R9CfDr9nV
ynZarYwTC4gy+qC7z7dLbutJHPdHcVv7SPJXh1fKUlpgOssbRKB7bxG/Gw9k52Pf
ZtvnOP91pIKckAZ6EpgFrpYDf7B6fujjg4Z8hbCORBx3l45tmYxAbCnaAeO0Gn/r
fbW78jElfOewr0QDpbTor1yorK9Qidf8Y2lujs9VtR7Gek2jIYIedtL/hPcG7Awa
7yI0qfLXPe/wo6eoQphoARtFf/oM2URlPAzyB1smJB85ytn8AR8J98O1JnzPbY+E
2foQ9g/wcKCeWRZohCjOyVK7cJ2kX618GJOukLXKzQVIxRQBkf2fdDocE2FbD9LW
uAbSL0k6HT7TKugBh8FNolhNfOggyFONK/A4UQ+rQmsgTZ2dWvvDnr53Lyv5KagS
1OJ5YAkwIxUJpiaCQNLl
=0CLe
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] mx51evk: Add CONFIG_REVISION_TAG

[Benoît Thébaudeau]

FSL 2.6.35 kernel assumes that the bootloader passes the CONFIG_REVISION_TAG
information.

If this data is not present, the kernel misconfigures the TZIC, which results in
the timer interrupt handler never being called, so the kernel deadlocks while
calibrating its delay.

Suggested-by: Greg Topmiller 
Signed-off-by: Benoît Thébaudeau 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
 .../board/freescale/mx51evk/mx51evk.c  |5 +
 .../include/configs/mx51evk.h  |1 +
 2 files changed, 6 insertions(+)

diff --git u-boot-imx-1d9b033.orig/board/freescale/mx51evk/mx51evk.c 
u-boot-imx-1d9b033/board/freescale/mx51evk/mx51evk.c
index 7a0682a..2e877c1 100644
--- u-boot-imx-1d9b033.orig/board/freescale/mx51evk/mx51evk.c
+++ u-boot-imx-1d9b033/board/freescale/mx51evk/mx51evk.c
@@ -60,6 +60,11 @@ int dram_init(void)
return 0;
 }
 
+u32 get_board_rev(void)
+{
+   return get_cpu_rev();
+}
+
 static void setup_iomux_uart(void)
 {
unsigned int pad = PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE |
diff --git u-boot-imx-1d9b033.orig/include/configs/mx51evk.h 
u-boot-imx-1d9b033/include/configs/mx51evk.h
index ba4a4a6..7b027b4 100644
--- u-boot-imx-1d9b033.orig/include/configs/mx51evk.h
+++ u-boot-imx-1d9b033/include/configs/mx51evk.h
@@ -44,6 +44,7 @@
 #define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_INITRD_TAG
+#define CONFIG_REVISION_TAG
 
 #define CONFIG_OF_LIBFDT
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/17/12 11:34, José Miguel Gonçalves wrote:
> On 17-09-2012 19:27, Tom Rini wrote:
>> On Mon, Sep 17, 2012 at 07:05:48PM +0100, Jos? Miguel Gon?alves
>> wrote:
>>> On 17-09-2012 18:56, Tom Rini wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 09/17/12 10:08, Jos? Miguel Gon?alves wrote:
> On 17-09-2012 17:57, Tom Rini wrote:
>> On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel
>> Gon?alves wrote:
>>> On 09/14/2012 08:01 PM, Tom Rini wrote:
 On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos?
 Miguel Gon?alves wrote:
> On 14-09-2012 19:21, Marek Vasut wrote:
>> Dear Jos? Miguel Gon?alves,
>> 
>>> NAND Flash driver with HW ECC for the S3C24XX
>>> SoCs. Currently it only supports SLC NAND
>>> chips.
>>> 
>>> Signed-off-by: Jos? Miguel Gon?alves 
>>> 
>> [...]
>> 
>>> +#include  +#include 
>>> +#include  +#include
>>>  +#include 
>>>  + +#define MAX_CHIPS2 +static
>>> int nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef 
>>> CONFIG_SPL_BUILD +#define printf(arg...) do {}
>>> while (0)
>> This doesn't seem quite right ...
>> 
>> 1) this should be in CPU directory 2) should be
>> enabled only if CONFIG_SPL_SERIAL_SUPPORT is not
>> set 3) should be inline function, not a macro
> 1) and 3) OK. Don't quite understand 2). I want to
> remove the printfs in the SPL build, as it would
> blown up the internal SoC RAM space available. So
> why add a condition with
> CONFIG_SPL_SERIAL_SUPPORT?
 You've got 8KB, based on the final patch in the
 series.  At least in my SPL series that's still
 enough to get you printf/puts (I believe 4kb was the
 cutoff where that had to be dropped).
 
>>> Barely:
>>> 
>>> $ size u-boot-spl text   databss
>>> dec hexfilename 3337  8588
>>> 3933 f5du-boot-spl
>>> 
>>> $ size u-boot-spl-printf text   databss
>>> dec hexfilename 7968  8604
>>> 8580 2184 u-boot-spl-printf
>>> 
>>> The printf is not so important that justifies
>>> exhausting the IRAM space available and preventing any
>>> future SPL expansion...
>> There's two parts to this: - What else can you do in a
>> single binary, in theory?  Is there boot medium detection
>> and you would want to have, for example, NAND and SD
>> support in the same binary?  I would say memory is meant
>> for using, but this is a board maintainer decision and
>> that's you :)
> That's exactly what I've got in mind when I talked about a
> future expansion! Being able to boot also from an SD card.
> With only 8KB for .text and .data, I can not use printfs in
> the SPL for this platform (at least with the present printf
> support for SPL).
> 
>> - We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT)
>> that toggles printf or no printf.  If we really need to
>> say yes to LIBCOMMON_SUPPORT and no to printf, we need
>> finer grained config options and then a do-nothing printf
>> is used for SPL.  Doing the opt-out driver by driver just
>> punts this problem down the road to the next developer
>> and that's not very nice (and adding 
>> CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch,
>> modify a few Makefiles, update a bunch of config files,
>> add common/spl/dummy_funcs.c and a __weak printf).
 OK, so please take a stab at option two, on top of my SPL
 series, keeping in mind what Scott has said (which makes
 sense) because otherwise you'll be changing a lot of MMC
 files too to drop out printf :)
>>> The solution that I sorted out on the current SPL framework was
>>> to add this:
>>> 
>>> #ifdef CONFIG_SPL_BUILD #define printf(arg...) do {} while (0) 
>>> #ifdef CONFIG_SPL_SERIAL_SUPPORT #define puts(arg)
>>> serial_puts(arg) #endif #endif
>>> 
>>> on a CPU specific header. Marek told me to not use macros, but
>>> to use inline functions instead, but has I told earlier on this
>>> thread, I am unable to do that. Suggestions for doing this in a
>>> better way are welcome...
>> It's gotta go in , and something like /* Big comment
>> what / why */ #if !defined(CONFIG_SPL_BUILD) || \ 
>> (CONFIG_SPL_BUILD && CONFIG_SPL_PRINTF_SUPPORT) void putc(...); 
>> void puts(...); int printf(); #else #define putc(c)
>> serial_putc(c) #define puts(s) serial_puts(s) #define
>> printf(arg...) do {} while (0) #endif
>> 
> 
> Are macros OK to remove printf() and to replace putc()/puts() by 
> serial_putc()/serial_puts() in the SPL? Shouldn’t we be using
> inline functions instead?

As Scott pointed out, inline won't remove the string constants from
the binary so it will still be possibly too l

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

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/17/12 10:52, Marek Vasut wrote:

> I'm not sure if we want them in current release or next, I'll
> leave that to you to decide. I don't see much danger for current
> though.

I believe all of this made it by the merge window and looks good.  But
in the future please only pull request code you believe to be ready
for mainline.  If you aren't sure, test it more, review it more and be
sure.  I'm relying on all of the custodians and their judgement of
what is, and is not, ready to go.  Thanks!

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

iQIcBAEBAgAGBQJQV2/qAAoJENk4IS6UOR1WlDcP+QExUWs63LzKcahlUrOsFftZ
1kx06ZquDPYPt2suR54VxV81bo7Iuf3i/XO6NU/jOQpBBPsuixB8ij1oRGB/glpd
H05QckOhh8FYJYvoXpVEctHN2z/Tm3PcWR1gWfcVC8RmtDASpn8pxzLBC9x3iiSe
qD0z8JBvSBghC5F/u7LW8twDXyDitL7VZEE59sbzKrSvpHW/nH+1rMbvQzXX57QQ
abogaI+XNNJWUskm7BRXqfE5tPwE2pABXkVXv7pFEqMAXl53iJVWBEvskFyHsBwv
UdzCxMHMs3ktbBpAX1vtBxsCPIW0Egc1pLdq9CZxisTHsaQ0C6fUcxYIJFHlSiaB
dhCZfMhp+v90HdDm8p5ZhDJPEwUosYVGUqiSqgVQLcgFT3xfsq7uP1JsAIay6jDG
DtlKMKkFOkiQgM1lt7RP6DnG9CyHojqOFUQ5Rlv7dP7e3o2utf5F51pyPGvrOR3S
HOIVS/MH9AIPNrNeVywYmROPCBtOmESCsHogDpY/iil/qRgL0+YFUumWc2vadRvT
MoL81OwLBmMDOfC6X6krz4XYswHIAhHGWyoOrMo+KZQIFrQxZOYoqNGGvsh5lklc
dDwAaOl0HCEOGuv53oi/UrdR/gcNlt3L+obhPzngJjRUwavns2i6M2MPqPsakTE0
13vCk0tMCfQ7yARkiT/6
=Dnsj
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-boot's stack space on a Sequoia board

[Wolfgang Denk]

Dear Corey Ashford,

In message <50575cb3.20...@linux.vnet.ibm.com> you wrote:
>
> > Please update, then try again.

> OK, and thank you for your quick reply.  I don't have physical access to 
> this board, but I'll ask around to find if this is something we can do.

No physical access is needed for such an update (unless you botch it
and need to access the BDI3000, or to switch the jumpers to boot the
backup version from NAND - if you were clever enough to install one
there first).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Be careful what you wish for. You never know who will be listening.
  - Terry Pratchett, _Soul Music_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 4/5] OMAP: networking support for SPL

[Ilya Yanok]

On Mon, Sep 17, 2012 at 1:55 PM, Ilya Yanok
wrote:

> > +#include 
>> > +#include 
>> > +#include 
>>
>> What in here needs this header?
>>
>
> Looks like it's unneeded. Thanks, I'll remove it.
>

Nope, it's needed for spl_parse_image_header.

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

Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver

[José Miguel Gonçalves]

On 17-09-2012 19:27, Tom Rini wrote:

On Mon, Sep 17, 2012 at 07:05:48PM +0100, Jos? Miguel Gon?alves wrote:

On 17-09-2012 18:56, Tom Rini wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/17/12 10:08, Jos? Miguel Gon?alves wrote:

On 17-09-2012 17:57, Tom Rini wrote:

On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves
wrote:

On 09/14/2012 08:01 PM, Tom Rini wrote:

On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel
Gon?alves wrote:

On 14-09-2012 19:21, Marek Vasut wrote:

Dear Jos? Miguel Gon?alves,


NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.

Signed-off-by: Jos? Miguel Gon?alves


[...]


+#include  +#include  +#include
 +#include  +#include
 + +#define MAX_CHIPS2 +static int
nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef
CONFIG_SPL_BUILD +#define printf(arg...) do {} while
(0)

This doesn't seem quite right ...

1) this should be in CPU directory 2) should be enabled
only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be
inline function, not a macro

1) and 3) OK. Don't quite understand 2). I want to remove
the printfs in the SPL build, as it would blown up the
internal SoC RAM space available. So why add a condition
with CONFIG_SPL_SERIAL_SUPPORT?

You've got 8KB, based on the final patch in the series.  At
least in my SPL series that's still enough to get you
printf/puts (I believe 4kb was the cutoff where that had to
be dropped).


Barely:

$ size u-boot-spl text   databssdec
hexfilename 3337  8588   3933
f5du-boot-spl

$ size u-boot-spl-printf text   databssdec
hexfilename 7968  8604   8580
2184 u-boot-spl-printf

The printf is not so important that justifies exhausting the
IRAM space available and preventing any future SPL
expansion...

There's two parts to this: - What else can you do in a single
binary, in theory?  Is there boot medium detection and you would
want to have, for example, NAND and SD support in the same
binary?  I would say memory is meant for using, but this is a
board maintainer decision and that's you :)

That's exactly what I've got in mind when I talked about a future
expansion! Being able to boot also from an SD card. With only 8KB
for .text and .data, I can not use printfs in the SPL for this
platform (at least with the present printf support for SPL).


- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
toggles printf or no printf.  If we really need to say yes to
LIBCOMMON_SUPPORT and no to printf, we need finer grained config
options and then a do-nothing printf is used for SPL.  Doing the
opt-out driver by driver just punts this problem down the road to
the next developer and that's not very nice (and adding
CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
Makefiles, update a bunch of config files, add
common/spl/dummy_funcs.c and a __weak printf).

OK, so please take a stab at option two, on top of my SPL series,
keeping in mind what Scott has said (which makes sense) because
otherwise you'll be changing a lot of MMC files too to drop out printf :)

The solution that I sorted out on the current SPL framework was to add this:

#ifdef CONFIG_SPL_BUILD
#define printf(arg...) do {} while (0)
#ifdef CONFIG_SPL_SERIAL_SUPPORT
#define puts(arg) serial_puts(arg)
#endif
#endif

on a CPU specific header. Marek told me to not use macros, but to
use inline functions instead, but has I told earlier on this thread,
I am unable to do that. Suggestions for doing this in a better way
are welcome...

It's gotta go in , and something like
/* Big comment what / why */
#if !defined(CONFIG_SPL_BUILD) || \
(CONFIG_SPL_BUILD && CONFIG_SPL_PRINTF_SUPPORT)
void putc(...);
void puts(...);
int printf();
#else
#define putc(c) serial_putc(c)
#define puts(s) serial_puts(s)
#define printf(arg...) do {} while (0)
#endif



Are macros OK to remove printf() and to replace putc()/puts() by 
serial_putc()/serial_puts() in the SPL?

Shouldn’t we be using inline functions instead?

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

Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver

[Tom Rini]

On Mon, Sep 17, 2012 at 07:05:48PM +0100, Jos? Miguel Gon?alves wrote:
> On 17-09-2012 18:56, Tom Rini wrote:
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA1
> >
> >On 09/17/12 10:08, Jos? Miguel Gon?alves wrote:
> >>On 17-09-2012 17:57, Tom Rini wrote:
> >>>On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves
> >>>wrote:
> On 09/14/2012 08:01 PM, Tom Rini wrote:
> >On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel
> >Gon?alves wrote:
> >>On 14-09-2012 19:21, Marek Vasut wrote:
> >>>Dear Jos? Miguel Gon?alves,
> >>>
> NAND Flash driver with HW ECC for the S3C24XX SoCs.
> Currently it only supports SLC NAND chips.
> 
> Signed-off-by: Jos? Miguel Gon?alves
> 
> >>>[...]
> >>>
> +#include  +#include  +#include
>  +#include  +#include
>  + +#define MAX_CHIPS2 +static int
> nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef
> CONFIG_SPL_BUILD +#define printf(arg...) do {} while
> (0)
> >>>This doesn't seem quite right ...
> >>>
> >>>1) this should be in CPU directory 2) should be enabled
> >>>only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be
> >>>inline function, not a macro
> >>1) and 3) OK. Don't quite understand 2). I want to remove
> >>the printfs in the SPL build, as it would blown up the
> >>internal SoC RAM space available. So why add a condition
> >>with CONFIG_SPL_SERIAL_SUPPORT?
> >You've got 8KB, based on the final patch in the series.  At
> >least in my SPL series that's still enough to get you
> >printf/puts (I believe 4kb was the cutoff where that had to
> >be dropped).
> >
> Barely:
> 
> $ size u-boot-spl text   databssdec
> hexfilename 3337  8588   3933
> f5du-boot-spl
> 
> $ size u-boot-spl-printf text   databssdec
> hexfilename 7968  8604   8580
> 2184 u-boot-spl-printf
> 
> The printf is not so important that justifies exhausting the
> IRAM space available and preventing any future SPL
> expansion...
> >>>There's two parts to this: - What else can you do in a single
> >>>binary, in theory?  Is there boot medium detection and you would
> >>>want to have, for example, NAND and SD support in the same
> >>>binary?  I would say memory is meant for using, but this is a
> >>>board maintainer decision and that's you :)
> >>That's exactly what I've got in mind when I talked about a future
> >>expansion! Being able to boot also from an SD card. With only 8KB
> >>for .text and .data, I can not use printfs in the SPL for this
> >>platform (at least with the present printf support for SPL).
> >>
> >>>- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
> >>>toggles printf or no printf.  If we really need to say yes to
> >>>LIBCOMMON_SUPPORT and no to printf, we need finer grained config
> >>>options and then a do-nothing printf is used for SPL.  Doing the
> >>>opt-out driver by driver just punts this problem down the road to
> >>>the next developer and that's not very nice (and adding
> >>>CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
> >>>Makefiles, update a bunch of config files, add
> >>>common/spl/dummy_funcs.c and a __weak printf).
> >OK, so please take a stab at option two, on top of my SPL series,
> >keeping in mind what Scott has said (which makes sense) because
> >otherwise you'll be changing a lot of MMC files too to drop out printf :)
> 
> The solution that I sorted out on the current SPL framework was to add this:
> 
> #ifdef CONFIG_SPL_BUILD
> #define printf(arg...) do {} while (0)
> #ifdef CONFIG_SPL_SERIAL_SUPPORT
> #define puts(arg) serial_puts(arg)
> #endif
> #endif
> 
> on a CPU specific header. Marek told me to not use macros, but to
> use inline functions instead, but has I told earlier on this thread,
> I am unable to do that. Suggestions for doing this in a better way
> are welcome...

It's gotta go in , and something like
/* Big comment what / why */
#if !defined(CONFIG_SPL_BUILD) || \
   (CONFIG_SPL_BUILD && CONFIG_SPL_PRINTF_SUPPORT)
void putc(...);
void puts(...);
int printf();
#else
#define putc(c) serial_putc(c)
#define puts(s) serial_puts(s)
#define printf(arg...) do {} while (0)
#endif

-- 
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] Problem Booting RTEMS with u-boot on Phycore LPC3250

[SAeeD]

Dear Wolfgang,

Where exactly did you get the U-Boot source code from?


Various sources in fact:
http://bitshrine.org/gpp/u-boot-1.3.3-lpc32xx.patch
http://git.lpclinux.com/?p=uboot-2009.03-lpc32xx.git;a=summary
http://git.lpclinux.com/?p=uboot-2011.12-lpc32xx.git;a=summary
https://github.com/sobczyk/u-boot

I think the problem might be related to the big size of .Work section.
(About 63 MB while board's SRAM is 64 MB!)
Is it possible that clearing .Work, collapses U-Boot which is stored in
SRAM at 0x83fc?
BTW, it is a little weird that U-Boot loads .start @ 0x8000 and then
clears .vector at the same address:
Loading .start @ 0x8000 (1120 bytes)

Clearing .vector @ 0x8000 (5952 bytes)
Might the problem be related to the wrong structure of my ELF file?

Thanks,
SAeeD

On Mon, Sep 17, 2012 at 9:47 AM, Wolfgang Denk  wrote:

> Dear SAeeD,
>
> In message  abwhnxtog9rkwspnpqq8uzqtqot+_mtleu3-hr...@mail.gmail.com> you wrote:
> >
> > I have built an RTEMS 4.10.2 elf image for Phycore LPC3250. I am using
> ...
> > I have tried both u-boot 1.3.3 and u-boot 2009.03 and have not found any
> > improvements.
>
> These are two very old versions.  Forthermore, it appears that the
> Phycore LPC3250 is not supported in mainline U-Boot (mr what would the
> exact board name be?).
>
> Where exactly did you get the U-Boot source code from?
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> If A equals success, then the formula is A = X + Y + Z. X is work.  Y
> is play. Z is keep your mouth shut. - Albert Einstein
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 4/5] OMAP: networking support for SPL

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/17/12 11:10, Ilya Yanok wrote:
> 
> 
> On Mon, Sep 17, 2012 at 10:07 PM, Tom Rini  > wrote:
> 
>> That's not really about garbage collection in this case
>> (net-spl). I want to disable some functionality of generic net
>> code not some stuff used only by commands implementation. The
>> confusion comes from the fact that this code is protected by
>> CONFIG_CMD_* defines.
> 
> So I guess the code construct is roughly: function_we_need(...) { 
> #ifdef CONFIG_CMD_A ... stuff_spl_does_not_need(); #endif ... }
> 
> ?  Otherwise we would end up building files we don't use, but then
> all of the un-used code gets garbage collected.
> 
> 
> Exactly.

OK, config_uncmd_spl.h, nice big comment and v6, thanks :)

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

iQIcBAEBAgAGBQJQV2m7AAoJENk4IS6UOR1WxuEP/RFkI74bRCQeKKjTTEjIhRJo
d1GQdX0GPJ0eFoMZ8ZX4Q1vo/j1VobTPABPu6DT0t/40biKrZvQu1EAf+i7Kct8c
P/90xoWI60L6gYo9/mKdxu5TDULbyg306RUr8D2KoXhmMm1w57Ug4LK/MXH3WcLk
rVMNJT6WXNDuAaHy8fM7ZxLIdDyuVlo4rqf6CgjKA4iE1LEyNf3RHE9PQn9780QJ
Eun4/sLN3ulBc94s6+I+OAY4HeBwXCxOlVjxu5ta/NnmY5OEMfMbwVl7ka2sLspt
R58ZxOJ3oSZbVL/joQ6zk6JnmWCX6Dku8M/V7eiryXMwx+F8rdYX+mcL3/0Jk337
2AzScXTzKMVQnv1IFuG+SlHMH0jEcsPsd/sa9C+mDQIfcwNby86uFs0Khj2kNAwq
0GWPdOvP+KKmdiaKpgth2vcvmJcln10p9YyB8K8MVwByDP9Mw+mlS4cxvr/yGf5V
3kDntGP9mpn6L1qp8MceKyz27gE9HkbTYGVk5r4TEwwwdahHiQ500UswivLDtO4V
IH1hzZsachaYyGlptiAvxw3ZpRQwQ2j7P/2s6G2uW1b4VoSYcDiT0uzYYYVqKi1u
u3jmpgH3Qse62rcZPg3gSqrwPFFhYV/6Ol+evcI6dk1I3o2a8wbMRJnSBZyqe0UV
/05A2dMTsdnNwpUe9f54
=QB8w
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile

[Scott Wood]

On 09/17/2012 12:53:41 PM, Tom Rini wrote:

On 09/17/12 10:32, Scott Wood wrote:
> On 09/17/2012 11:51:52 AM, Tom Rini wrote:
>> On 09/17/12 09:27, Scott Wood wrote:
>> > On 09/17/2012 04:24:34 AM, José Miguel Gonçalves wrote:
>> [snip]
>> >> If no one else has anything against, I will change the name of  
the new

>> >> target to u-boot-pad.bin
>> >
>> > What exactly is u-boot-pad.bin supposed to be?  I hope that's  
not being

>> > proposed as the final output file the user sees.
>> >
>> > With old nand_spl we had u-boot-nand.bin for the final  
concatenated
>> > binary, but that's not appropriate for a generic spl.  I think  
it would

>> > be better for the user to see "u-boot.bin" as the actual image to
>> put on
>> > the boot device, regardless of implementation details like spl,  
if
>> > there's no requirement of a specific file format.  The second  
stage
>> > could become "u-boot-main.bin" or similar on builds where spl is  
used.

>>
>> We need some name that means "U-Boot SPL with U-Boot tacked on at  
the
>> end".  This can optionally be padded to a defined size to make  
writing
>> to hardware easier.  We also have the problem that "u-boot.bin"  
already

>> means something so it needs to be clear.
>
> u-boot.bin has traditionally (except for nand_spl and derivatives)  
meant

> the final image ready to put into flash, after any platform-specific
> layout issues are taken care of (e.g. on mpc83xx it will have a  
reset
> control word embedded, on mpc85xx it will be padded to 512K with a  
reset
> vector at the end, etc.).  That we did the tweaking in the linker  
script
> rather than after linking seems like an inconsequential  
implementation

> detail.

Right, but it's also just objcopy (with OBJCFLAGS) -O binary of, and
this is the biggie to me, just U-Boot.

>> I further fear that even if we
>> made an "out" directory if we put u-boot.bin in there and it's not  
the
>> same as the objcopy -O binary u-boot u-boot.bin as before we've  
violated
>> the rule of least surprise and the end user problems from people  
that

>> read "the" document (that happened to be out of date) will be our
>> problem.
>
> In this case I think you can't meet one user's expectations without
> violating another's.  I think it's more important to make it clear  
to

> the user what file they're supposed to put into flash.  Users of
> platforms that are currently supported by nand_spl would probably  
like

> to continue seeing u-boot-nand.bin -- it's a tradeoff of historical
> stability versus current consistency.

Right.  So I'm saying we need to set new expectations for everyone and
some human helper symlinks to help.  A new top-level out or images or
something, with symlinks inside.


How about something like "u-boot-final.bin"[1], "u-boot-all.bin",  
"u-boot-image.bin", etc. as the end-user output, with ".bin" changed to  
something else if it's a well known file type?  At least for the boards  
that only require one output file.


-Scott

[1] Though then LDFLAGS_FINAL becomes confusing...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 4/5] OMAP: networking support for SPL

[Ilya Yanok]

BTW, I'm going to repost this serie soon. Shouldn't I rebase it on top of
your SPL rework patches? Where can I find the tree?

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

Re: [U-Boot] [PATCH v5 4/5] OMAP: networking support for SPL

[Ilya Yanok]

On Mon, Sep 17, 2012 at 10:07 PM, Tom Rini  wrote:

> > That's not really about garbage collection in this case (net-spl).
> > I want to disable some functionality of generic net code not some
> > stuff used only by commands implementation. The confusion comes
> > from the fact that this code is protected by CONFIG_CMD_* defines.
>
> So I guess the code construct is roughly:
> function_we_need(...) {
> #ifdef CONFIG_CMD_A
>   ... stuff_spl_does_not_need();
> #endif
> ...
> }
>
> ?  Otherwise we would end up building files we don't use, but then all
> of the un-used code gets garbage collected.
>

Exactly.

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

Re: [U-Boot] [PATCH v3 5/7] gpt: Support for GPT (GUID Partition Table) restoration

[Stephen Warren]

On 09/13/2012 02:10 AM, Lukasz Majewski wrote:
> The restoration of GPT table (both primary and secondary) is now possible.
> Simple GUID generation is supported.

> diff --git a/include/part.h b/include/part.h

> +int set_gpt_table(block_dev_desc_t *dev_desc,
> +   gpt_header *gpt_h, gpt_entry *gpt_e);

The API here isn't very generic; it requires the caller to have
formatted the GPT entirely by itself, which means having complete
knowledge of how to lay out a GPT header and partition table entry.
Right now, all that knowledge is contained inside the implementation of
the "gpt" command - what if some other unrelated code wanted to write a
GPT; it'd have to duplicate everything.

I was thinking of a much more generic interface, where each partition is
described using abstract structs, and the creation of the actual on-disk
layout is handling inside the set_gpt_table() function. That would
presumably allow the same abstract structs to be passed to e.g.
set_mbr_partition_table() and a generic "ptable create" command to be
created.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 4/5] OMAP: networking support for SPL

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/17/12 10:54, Ilya Yanok wrote:
> Hi Tom,
> 
> On Mon, Sep 17, 2012 at 9:04 PM, Tom Rini  > wrote:
> 
>> I agree it's not the best place... config_cmd_spl.h sounds a
>> little bit crazy as we don't have any commands at all in SPL...
> 
> 
> How about config_uncmd_spl.h then and a nice big comment up top
> 
> 
> Well, it will be at least less confusing...
> 
> 
> explaining what we're doing.  Or can we take another stab at
> seeing why some stuff isn't being garbage collected?  If 
> garbage_collected_func_a calls never_seen_while_linking_func, we
> still succeed since we garbage collect the first func.  There's
> just the gcc issue I've noted before about strings.
> 
> 
> That's not really about garbage collection in this case (net-spl).
> I want to disable some functionality of generic net code not some
> stuff used only by commands implementation. The confusion comes
> from the fact that this code is protected by CONFIG_CMD_* defines.

So I guess the code construct is roughly:
function_we_need(...) {
#ifdef CONFIG_CMD_A
  ... stuff_spl_does_not_need();
#endif
...
}

?  Otherwise we would end up building files we don't use, but then all
of the un-used code gets garbage collected.

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

iQIbBAEBAgAGBQJQV2bQAAoJENk4IS6UOR1WXNAP+MLdJeSu0x5xpbKEyURT6ISc
hKwYFO9esQRTnssp+0efz+RlYgAV1fet5pxhtn+RqMvA5XfWT413yZoEOg7XzsBE
TYcVs63TRuTDI5o0qgOryAQifY6GTFj1hw4BecAvODErJl7D6dtyGJjg4QWVUP4M
C1AFb0132ILlj5MSXCAC3d0ZYVNDqkIGl0BNGUSwOmZ8OT7IHi/x1tOUaKibOin6
wytrPXFwNxjvNeDVXe1Ot89Kx/t+kbNh6LDJLoIPK8SasuKdrtDxiQLCMMGGxT7R
vAS7//AqupWuzyWPdcQvM+YJetDKk/iYCy1FpYeo0yY1nKBHgh85lr6yBqjRnwKV
Tbh9ny41J1xd4AhIbRvEXirReZ/Zu3vEr01Qe+ddqgY+2mol0wucyhY2dgWlAn5G
jRCARRpEd8tIgzWBN5lxosHq+v7iltAOXZT/hHZpv19zzZ2KK3xG4CiqaZZvRS2B
DHWj2dOZW7CJGhCpYapLtCmxhh+M4X6YGflNCkiuQV9NGZjE3PhGh0N9QRQXBQjU
CzmY/cqWXG7QZ6NIlKyEG9nZMuFggSW2miHINGmk4G68rH6QfCpGilucOkN2LDjt
sE60qAIxRmkW2emn12V9dBU5CTyhgVetr0nYBD0PGO366Z+Xoq9sODG2aiQYdNTF
250WBWG235mtco6BNUw=
=v55G
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver

[José Miguel Gonçalves]

On 17-09-2012 18:56, Tom Rini wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/17/12 10:08, José Miguel Gonçalves wrote:

On 17-09-2012 17:57, Tom Rini wrote:

On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves
wrote:

On 09/14/2012 08:01 PM, Tom Rini wrote:

On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel
Gon?alves wrote:

On 14-09-2012 19:21, Marek Vasut wrote:

Dear Jos? Miguel Gon?alves,


NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.

Signed-off-by: Jos? Miguel Gon?alves


[...]


+#include  +#include  +#include
 +#include  +#include
 + +#define MAX_CHIPS2 +static int
nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef
CONFIG_SPL_BUILD +#define printf(arg...) do {} while
(0)

This doesn't seem quite right ...

1) this should be in CPU directory 2) should be enabled
only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be
inline function, not a macro

1) and 3) OK. Don't quite understand 2). I want to remove
the printfs in the SPL build, as it would blown up the
internal SoC RAM space available. So why add a condition
with CONFIG_SPL_SERIAL_SUPPORT?

You've got 8KB, based on the final patch in the series.  At
least in my SPL series that's still enough to get you
printf/puts (I believe 4kb was the cutoff where that had to
be dropped).


Barely:

$ size u-boot-spl text   databssdec
hexfilename 3337  8588   3933
f5du-boot-spl

$ size u-boot-spl-printf text   databssdec
hexfilename 7968  8604   8580
2184 u-boot-spl-printf

The printf is not so important that justifies exhausting the
IRAM space available and preventing any future SPL
expansion...

There's two parts to this: - What else can you do in a single
binary, in theory?  Is there boot medium detection and you would
want to have, for example, NAND and SD support in the same
binary?  I would say memory is meant for using, but this is a
board maintainer decision and that's you :)

That's exactly what I've got in mind when I talked about a future
expansion! Being able to boot also from an SD card. With only 8KB
for .text and .data, I can not use printfs in the SPL for this
platform (at least with the present printf support for SPL).


- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
toggles printf or no printf.  If we really need to say yes to
LIBCOMMON_SUPPORT and no to printf, we need finer grained config
options and then a do-nothing printf is used for SPL.  Doing the
opt-out driver by driver just punts this problem down the road to
the next developer and that's not very nice (and adding
CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
Makefiles, update a bunch of config files, add
common/spl/dummy_funcs.c and a __weak printf).

OK, so please take a stab at option two, on top of my SPL series,
keeping in mind what Scott has said (which makes sense) because
otherwise you'll be changing a lot of MMC files too to drop out printf :)


The solution that I sorted out on the current SPL framework was to add this:

#ifdef CONFIG_SPL_BUILD
#define printf(arg...) do {} while (0)
#ifdef CONFIG_SPL_SERIAL_SUPPORT
#define puts(arg) serial_puts(arg)
#endif
#endif

on a CPU specific header. Marek told me to not use macros, but to use inline 
functions instead, but has I told earlier on this thread, I am unable to do that. 
Suggestions for doing this in a better way are welcome...

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

Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/17/12 10:48, Marek Vasut wrote:
> Dear Tom Rini,
> 
>> On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote:
>>> Dear Tom Rini,
>>> 
 On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
> Dear Jos? Miguel Gon?alves,
> 
>> On 09/16/2012 11:06 AM, Marek Vasut wrote:
>>> Dear Jos? Miguel Gon?alves,
>>> 
 On 09/15/2012 07:03 PM, Marek Vasut wrote:
> Dear Jos? Miguel Gon?alves,
> 
>> Jumping to board_init_r is not performed due to a
>> bug on address computation.
> 
> Is your CONFIG_SYS_TEXT_BASE configured correctly?
> I don't detect any misbehavior on my arm926
> boards.
 
 Maybe because you are not using it to build an SPL?
>>> 
>>> I do ... and I use CONFIG_SPL_TEXT_BASE properly .
>>> 
 Please check the same chunk of code in other start.S
 for arm1176 and armv7. They have the same code that I
 put for arm926ejs.
>>> 
>>> Please wait and please first explain what is the
>>> issue.
>> 
>> The issue is what I've explained in the patch comments.
> 
> "Jumping to board_init_r is not performed due to a bug on
> address computation."
> 
> Ok, I don't know how to replicate the bug from this comment
> or what effects it causes or ... well, anything. So please,
> try to be more elaborate in your patch description next
> time. Anyway ..
> 
>> Without this change the code never reaches board_init_r
>> in the SPL and I think I have all the configurations
>> correctly set.
> 
> I wonder why you'd ever want to reach board_init_r in the
> SPL. SPL is there only to load the real U-Boot from
> whatever media, so you usually use either NAND SPL
 
 Here's a good point for me to jump in, I think.  There's two
 things to understand: - In the current in-tree SPL
 implementations the code flow is
 
 board_init_f calls relocate_code() to clear the BSS _and_ get
 our jump to board_init_r.  It does not actually relocate the
 running U-Boot, just clears the BSS.  board_init_r is what
 calls the things to load and boot the next stage (U-Boot or
 Linux).
 
 - In my series this has been changed slightly to be
 board_init_f calls
 
 memset and then board_init_r directly.  So this patch should
 not be needed once rebased on that series.
>>> 
>>> Do we need to do all the relocation in assembler code btw? Can
>>> it not be moved into C code and made generic across all
>>> platforms (module the stack adjustment and a few minor things)
>>> ?
>> 
>> I think people have posted patches for this before and yes, once 
>> CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in
>> C, so long as it doesn't grow in size or doesn't grow in size
>> that would be problematic (remember the 4kb people).
> 
> How does MANUAL_RELOC interfere with that? Eg. on ARM, it can
> already be shifted to C. Then if we made it generic enough, those
> MANUAL_RELOC platforms could simply adopt the C code.

Yes, one of the platforms that already has C code for ELF relocation
(x86, iirc) could be made more generic and I think someone (Graeme?)
already started this a long time ago as part of making a generic set
of functions for board_init_{f,r}.  Just can't make it for all
platforms until everyone has ELF is the point I was poorly making.

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

iQIcBAEBAgAGBQJQV2VKAAoJENk4IS6UOR1W3McP/1htBzFzXXPULGOO+1zanoaO
T2tmJZ9f4gHNIY6gnCdU7SlW4mhZPEFlwHD+JwPmIS7ZhGcPxVn9Vgl+r0fpEZHW
VBY1bGeSGmaLhziiT+9MmaUqKUx6IFN5nZX0ypYcHS1ZTo1JztvLSUrSdOnOYHWx
DXXPwNIreUctwIpyjNrhu93e39ep1AYb1ZW+o57Sj4+uGqt8+G9FpEjdxMQrjKqh
r88j7XRgfWNPiqLwuGy+7HHEXnQGDum3Aml/ojO3WSzpZYXZQ4zC4MTND+TwzSi6
h3+nB3OfYktPgFWRDYQt8VyWPl9beVHzhac3o6sF5SiclQyya0liCCNsSbDSKf/G
Zjpjg5cOAmPMMUs1ZXq2Ve5wMxb0alArzxZuMZ/ZA1gRDjazFErvYCUzAQFkDAZz
zB6YMNc1+iCaYyaeNOqvJdMOZXAIoGLx5bbv9dzsnYc45jeU1ScDywcOQC2jTYFf
jnzmqzh/6EJW2gfWW33XdxbHsDOZeEfCzJFmK7/vEbVW0TrkiCMJjHzf/jdguABQ
jhusLwYYJr5yNlwq16RmiPxIaUhBrCFLY5cxLiSTd4v0DdbqyaTC7MEadjKQLpBW
/LA5ImhXr/ORhfNTrVQjDSRhAGdmi2L0GVTurHJ2I6SCIVesu/ioMCGY3sy+aizK
H3jl0yobGtRNFamgK+Ld
=ncZ8
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 3/7] gpt:doc: GPT (GUID Partition Table) documentation

[Stephen Warren]

On 09/13/2012 02:10 AM, Lukasz Majewski wrote:
> Documentation of the GPT format.

> diff --git a/doc/README.gpt b/doc/README.gpt

> +Example usage:
> +==
> +
> +To restore GUID partition table one needs to:
> +1. at ./include/configs/{board}.h
> +   - define "partitions=" environment variable with format:
> + "name=u-boot,size=60M;name=kernel,size=60M;name=platform,size=1G;"
> +   - define GPT_PARTS_NUM with actual number of partitions (as defined above)

That seems unfortunate; the partitions variable and GPT_PARTS_NUM define
could easily become out-of-sync (what if the user edited the variable in
order to create an alternative disk layout, or what if a developer
simply forgot to update GPT_PARTS_NUM when editing the hard-coded value?).

Instead, can't GPT_PARTS_NUM be removed, and the code simply count the
number of entries in the partitions variable?

> +   - #define CONFIG_EFI_PARTITION and #define CONFIG_CMD_GPT
> +
> +2. From u-boot prompt type:
> +   gpt mmc 0 uuid_disk=ec2cddf2-fbf5-11e1-af3a-001fd09285c0, \
> +   uuid1=ed09c4b0-fbf5-11e1-9a95-001fd09285c0, \
> +   uuid2=edd6d93c-fbf5-11e1-875a-001fd09285c0, \
> +   uuid3=f0485114-fbf5-11e1-a3ae-001fd09285c0 ...
> +
> +   UUIDs shall be defined up to GPT_PARTS_NUM. Smaller number is acceptable.
> +   When UUIDs are NOT provided, internal (rather weak) GUID generator will be
> +   used instead

Hmmm. It's a little unfortunate to provide the partitions list through
one mechanism (environment variable with a hard-coded name), and the
UUIDs through a different mechanism (command-line). Surely these two
mechanisms can be combined; rather than the command reading an
environment variable, you could at least require the user to pass the
appropriate data on the command-line, and optionally have them pass the
environment variable if they want to use the pre-defined layout, e.g.:

pre-defined:
gpt mmc 0 ${partitions}

manual/custom layout:
gpt mmc 0 name=u-boot,size=60M;name=kernel,size=60M;...

Then, I wonder if you couldn't define the partitions environment
variable as:

partitions=\
name=u-boot,size=60M,uuid=${uuid_gpt_u_boot};\
name=kernel,size=60M,uuid=${uuid_gpt_kernel};...

and have the environment variables expanded as in:

setenv uuid_gpt_u_boot=ed09c4b0-fbf5-11e1-9a95-001fd09285c0
setenv uuid_gpt_kernel=...
gpt mmc 0 ${partitions}

That way, the gpt command would read everything from the command-line,
yet the partition layout and UUID names could be specified separately,
so as to allow the user to define them at different times or places.

The implementation of "gpt" would have to scan all the variables it
extracted from the command-line, and expand any environment variable
references in them for this to work, since I assume the shell doesn't do
recursive variable expansions like make does.

Oh, and don't you want the "gpt" command to take a sub-command like
"create", so that "gpt" could do different things in the future, e.g.
take an existing GPT layout, and edit, say, one partition's name:

gpt create mmc 0 ${partitions}
gpt set-name mmc 0 ${partition-id} ${new-name}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/17/12 10:08, José Miguel Gonçalves wrote:
> On 17-09-2012 17:57, Tom Rini wrote:
>> On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves
>> wrote:
>>> On 09/14/2012 08:01 PM, Tom Rini wrote:
 On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel
 Gon?alves wrote:
> On 14-09-2012 19:21, Marek Vasut wrote:
>> Dear Jos? Miguel Gon?alves,
>> 
>>> NAND Flash driver with HW ECC for the S3C24XX SoCs. 
>>> Currently it only supports SLC NAND chips.
>>> 
>>> Signed-off-by: Jos? Miguel Gon?alves
>>> 
>> [...]
>> 
>>> +#include  +#include  +#include
>>>  +#include  +#include
>>>  + +#define MAX_CHIPS2 +static int
>>> nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef
>>> CONFIG_SPL_BUILD +#define printf(arg...) do {} while
>>> (0)
>> This doesn't seem quite right ...
>> 
>> 1) this should be in CPU directory 2) should be enabled
>> only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be
>> inline function, not a macro
> 1) and 3) OK. Don't quite understand 2). I want to remove
> the printfs in the SPL build, as it would blown up the
> internal SoC RAM space available. So why add a condition
> with CONFIG_SPL_SERIAL_SUPPORT?
 You've got 8KB, based on the final patch in the series.  At
 least in my SPL series that's still enough to get you
 printf/puts (I believe 4kb was the cutoff where that had to
 be dropped).
 
>>> Barely:
>>> 
>>> $ size u-boot-spl text   databssdec
>>> hexfilename 3337  8588   3933
>>> f5du-boot-spl
>>> 
>>> $ size u-boot-spl-printf text   databssdec
>>> hexfilename 7968  8604   8580
>>> 2184 u-boot-spl-printf
>>> 
>>> The printf is not so important that justifies exhausting the
>>> IRAM space available and preventing any future SPL
>>> expansion...
>> There's two parts to this: - What else can you do in a single
>> binary, in theory?  Is there boot medium detection and you would
>> want to have, for example, NAND and SD support in the same
>> binary?  I would say memory is meant for using, but this is a
>> board maintainer decision and that's you :)
> 
> That's exactly what I've got in mind when I talked about a future 
> expansion! Being able to boot also from an SD card. With only 8KB
> for .text and .data, I can not use printfs in the SPL for this
> platform (at least with the present printf support for SPL).
> 
>> - We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
>> toggles printf or no printf.  If we really need to say yes to 
>> LIBCOMMON_SUPPORT and no to printf, we need finer grained config 
>> options and then a do-nothing printf is used for SPL.  Doing the 
>> opt-out driver by driver just punts this problem down the road to
>> the next developer and that's not very nice (and adding 
>> CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few 
>> Makefiles, update a bunch of config files, add 
>> common/spl/dummy_funcs.c and a __weak printf).

OK, so please take a stab at option two, on top of my SPL series,
keeping in mind what Scott has said (which makes sense) because
otherwise you'll be changing a lot of MMC files too to drop out printf :)

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

iQIcBAEBAgAGBQJQV2Q+AAoJENk4IS6UOR1W0VMP/1ToNzW5XmNApUGYIZi1d779
hJ6MieZoiTHOCnrHiRMMMAfOnPNnt+63TozmXWkhNhlPVRCs1Irx8nCpzMabjevr
ZENjnewtKsvgBsICak5rSQLbfyQBUG8tL3iBMPnYwyNhDf8CgED6rNCnxhV8Lr7j
o0gELaNHPRD7bJwglXo3TN0BxNtTrww3uSArSYh4WMVaOP908Mk7p7y8qEVSvNeh
BrdbVZK1oPmhlke9EUXfCQYqn/JdJ7mtdW1q5PdST7GFtnLZmqpj+FuOEwN3OioA
DE6J461Aqr95mGVUnUr7PxglytL6zLKJcE8YpIhu9nL6r9QRg0wm4HIKr3uTKLl5
WBs4ziJsLtm5IAZ7xg2FOsPrCkrAiL3bVQg0+7xVc1cVzKIGmtMR6oGVS+nI38Q6
lzmz0AQSuobeLkiP4+tL8C7kFkwMcj9I5LByN968ZMvbTftecIsdgYSkluOdGU5w
dwKPjplU4t8yy6d1TXbh0Xdw7q8cBZ3bjqbAKi3uo9BpEHgCDOwHp7oOTuJTDB/7
C6WxXHdQFHh7m0hxf1zkawOeh+oqd5MHAxjlckQ/zmg5UsmNWDA6RmmYgWrOBw9m
jCvN/lhe1soBnxaz2byUKwEkPIDwmBl+JgtSL7DMZ7bLfS59daXiaMNac2JPstG3
j0lBvj7SCVnQrE6SJxxa
=71I1
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 4/5] OMAP: networking support for SPL

[Ilya Yanok]

Hi Tom,

On Mon, Sep 17, 2012 at 9:04 PM, Tom Rini  wrote:

> > I agree it's not the best place... config_cmd_spl.h sounds a little
> > bit crazy as we don't have any commands at all in SPL...
>
>
> How about config_uncmd_spl.h then and a nice big comment up top
>

Well, it will be at least less confusing...


> explaining what we're doing.  Or can we take another stab at seeing
> why some stuff isn't being garbage collected?  If
> garbage_collected_func_a calls never_seen_while_linking_func, we still
> succeed since we garbage collect the first func.  There's just the gcc
> issue I've noted before about strings.
>

That's not really about garbage collection in this case (net-spl). I want
to disable some functionality of generic net code not some stuff used only
by commands implementation. The confusion comes from the fact that this
code is protected by CONFIG_CMD_* defines.

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

Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile

[Tom Rini]

On 09/17/12 10:32, Scott Wood wrote:
> On 09/17/2012 11:51:52 AM, Tom Rini wrote:
>> On 09/17/12 09:27, Scott Wood wrote:
>> > On 09/17/2012 04:24:34 AM, José Miguel Gonçalves wrote:
>> [snip]
>> >> If no one else has anything against, I will change the name of the new
>> >> target to u-boot-pad.bin
>> >
>> > What exactly is u-boot-pad.bin supposed to be?  I hope that's not being
>> > proposed as the final output file the user sees.
>> >
>> > With old nand_spl we had u-boot-nand.bin for the final concatenated
>> > binary, but that's not appropriate for a generic spl.  I think it would
>> > be better for the user to see "u-boot.bin" as the actual image to
>> put on
>> > the boot device, regardless of implementation details like spl, if
>> > there's no requirement of a specific file format.  The second stage
>> > could become "u-boot-main.bin" or similar on builds where spl is used.
>>
>> We need some name that means "U-Boot SPL with U-Boot tacked on at the
>> end".  This can optionally be padded to a defined size to make writing
>> to hardware easier.  We also have the problem that "u-boot.bin" already
>> means something so it needs to be clear.
> 
> u-boot.bin has traditionally (except for nand_spl and derivatives) meant
> the final image ready to put into flash, after any platform-specific
> layout issues are taken care of (e.g. on mpc83xx it will have a reset
> control word embedded, on mpc85xx it will be padded to 512K with a reset
> vector at the end, etc.).  That we did the tweaking in the linker script
> rather than after linking seems like an inconsequential implementation
> detail.

Right, but it's also just objcopy (with OBJCFLAGS) -O binary of, and
this is the biggie to me, just U-Boot.

>> I further fear that even if we
>> made an "out" directory if we put u-boot.bin in there and it's not the
>> same as the objcopy -O binary u-boot u-boot.bin as before we've violated
>> the rule of least surprise and the end user problems from people that
>> read "the" document (that happened to be out of date) will be our
>> problem.
> 
> In this case I think you can't meet one user's expectations without
> violating another's.  I think it's more important to make it clear to
> the user what file they're supposed to put into flash.  Users of
> platforms that are currently supported by nand_spl would probably like
> to continue seeing u-boot-nand.bin -- it's a tradeoff of historical
> stability versus current consistency.

Right.  So I'm saying we need to set new expectations for everyone and
some human helper symlinks to help.  A new top-level out or images or
something, with symlinks inside.

>> In short, at least a few people have said something along the lines of
>> "We need generic output nameo $mediums and targets" but there's two hard
>> problems, one of which is that every SoC _needs_ things tweaked just so
>> (no header? no boot!), sometimes wants things tweaked further (pad the
>> final image out to be easier to write to $medium) and sometimes needs
>> multiple files (the whole of 'SPL' will be read so it must fit into
>> $SMALL_MEMORY).  The other is naming.
> 
> A simple concatenation of a padded SPL plus the main U-Boot was good
> enough for all the nand_spl boards AFAIK, so it's not quite every SoC
> that needs something special here.  For those that do require a special
> format (or multiple files) with a file extension that is familiar to
> people working with that platform, using that extension makes sense. 
> "pad" does not, and a proliferation of SoC-specific suffixes isn't much
> better.

I think we're running into PowerPC vs ARM "fun".  We've got 7 or so
different "whack the image for this SoC for this medium" type things
already.

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

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

[Marek Vasut]

I'm not sure if we want them in current release or next, I'll leave that to you 
to decide. I don't see much danger for current though.

The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721:

  Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 09:17:27 
+0200)

are available in the git repository at:


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

for you to fetch changes up to 8187c2dcbd3e47ecfef406468c8eee1fe746b8e7:

  usb: do explicit unaligned accesses (2012-09-06 08:02:08 +0200)


Lucas Stach (5):
  usb: lowlevel interface change to support multiple controllers
  usb: ehci: rework to take advantage of new lowlevel interface
  usb: add support for multiple usb controllers
  tegra20: port to new ehci interface
  usb: do explicit unaligned accesses

Łukasz Majewski (2):
  dfu:usb: Support for ext4
  dfu:usb:fix: Read the "filesize" environment variable only when file read

 arch/arm/cpu/arm920t/s3c24x0/usb_ohci.c   |4 +--
 arch/arm/cpu/armv7/tegra20/usb.c  |   15 +++--
 arch/arm/include/asm/arch-tegra20/usb.h   |4 +--
 arch/arm/include/asm/ehci-omap.h  |   10 +-
 arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.c |4 +--
 arch/powerpc/cpu/mpc5xxx/usb_ohci.c   |4 +--
 arch/powerpc/cpu/ppc4xx/usb_ohci.c|4 +--
 arch/sparc/cpu/leon3/usb_uhci.c   |4 +--
 arch/sparc/lib/bootm.c|2 +-
 board/htkw/mcx/mcx.c  |6 ++--
 board/mpl/common/usb_uhci.c   |4 +--
 board/technexion/twister/twister.c|6 ++--
 board/teejet/mt_ventoux/mt_ventoux.c  |6 ++--
 board/ti/beagle/beagle.c  |6 ++--
 board/ti/panda/panda.c|6 ++--
 common/cmd_usb.c  |   16 ++---
 common/usb.c  |  108 
+
 common/usb_hub.c  |   16 +
 common/usb_storage.c  |2 +-
 drivers/dfu/dfu_mmc.c |   34 +++
 drivers/usb/eth/usb_ether.c   |2 +-
 drivers/usb/host/ehci-armada100.c |   15 -
 drivers/usb/host/ehci-atmel.c |   11 +++
 drivers/usb/host/ehci-core.h  |   29 -
 drivers/usb/host/ehci-exynos.c|   15 -
 drivers/usb/host/ehci-fsl.c   |   11 +++
 drivers/usb/host/ehci-hcd.c   |  131 
+-
 drivers/usb/host/ehci-ixp4xx.c|   15 -
 drivers/usb/host/ehci-marvell.c   |   15 -
 drivers/usb/host/ehci-mpc512x.c   |   25 ++
 drivers/usb/host/ehci-mx5.c   |   11 +++
 drivers/usb/host/ehci-mx6.c   |   11 +++
 drivers/usb/host/ehci-mxc.c   |   11 +++
 drivers/usb/host/ehci-mxs.c   |   28 +---
 drivers/usb/host/ehci-omap.c  |   10 +++---
 drivers/usb/host/ehci-pci.c   |   15 -
 drivers/usb/host/ehci-ppc4xx.c|   11 +++
 drivers/usb/host/ehci-tegra.c |   14 
 drivers/usb/host/ehci-vct.c   |9 +++---
 drivers/usb/host/ehci.h   |4 +--
 drivers/usb/host/isp116x-hcd.c|4 +--
 drivers/usb/host/ohci-hcd.c   |4 +--
 drivers/usb/host/r8a66597-hcd.c   |4 +--
 drivers/usb/host/sl811-hcd.c  |4 +--
 drivers/usb/musb/musb_hcd.c   |4 +--
 include/usb.h |   10 --
 include/usb/mv_udc.h  |2 +-
 47 files changed, 352 insertions(+), 334 deletions(-)
 delete mode 100644 drivers/usb/host/ehci-core.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Weekly status

[Marek Vasut]

Dear Tom Rini,

> Hey all,
> 
> I had intended to send this last thing Friday but it slipped my mind.
> But with my intention to do -rc1 this Friday, this works too.  That
> said...
> 
> Here's where I'm at so far:
> - Locally, I believe I have all outstanding pull requets queued up and
>   MAKEALL'd when there's an ELDK toolchain.

You're getting them MAKEALL's around 6 hours after you push it to master for 
PPC 
and ARM with ELDK4.2 and 5.2 ;-)

> - Working out the access issues with Detlev.
> - I've given the first two pages of patchwork a read and assign pass.
>   If you're a custodian I've probably assigned a few patches to you that
>   look like your area.  I've also done my best to spot superseded
>   patches and things which have been accepted but I'm sure I missed a
>   few.
> - If you have assigned me items in patchwork and sent me an email, I
>   have read it and will act on it shortly if I haven't already (just
>   don't want the queue of "I have applied this" messages locally to get
>   too large).

I think I have a few more USB patches holed up in my usb tree, I'll send you a 
pullRQ now.

> I expect to be able to snap -rc1 on my previously announced schedule.
> Once I do the usual rules about next will open and I would encourage
> custodians to open up a next branch as well.

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 v2 01/11] ARM: fix relocation on ARM926EJS

[Marek Vasut]

Dear Tom Rini,

> On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote:
> > Dear Tom Rini,
> > 
> > > On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
> > > > Dear Jos? Miguel Gon?alves,
> > > > 
> > > > > On 09/16/2012 11:06 AM, Marek Vasut wrote:
> > > > > > Dear Jos? Miguel Gon?alves,
> > > > > > 
> > > > > >> On 09/15/2012 07:03 PM, Marek Vasut wrote:
> > > > > >>> Dear Jos? Miguel Gon?alves,
> > > > > >>> 
> > > > >  Jumping to board_init_r is not performed due to a bug on
> > > > >  address computation.
> > > > > >>> 
> > > > > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't
> > > > > >>> detect any misbehavior on my arm926 boards.
> > > > > >> 
> > > > > >> Maybe because you are not using it to build an SPL?
> > > > > > 
> > > > > > I do ... and I use CONFIG_SPL_TEXT_BASE properly .
> > > > > > 
> > > > > >> Please check the same chunk of code in other start.S for arm1176
> > > > > >> and armv7. They have the same code that I put for arm926ejs.
> > > > > > 
> > > > > > Please wait and please first explain what is the issue.
> > > > > 
> > > > > The issue is what I've explained in the patch comments.
> > > > 
> > > > "Jumping to board_init_r is not performed due to a bug on address
> > > > computation."
> > > > 
> > > > Ok, I don't know how to replicate the bug from this comment or what
> > > > effects it causes or ... well, anything. So please, try to be more
> > > > elaborate in your patch description next time. Anyway ..
> > > > 
> > > > > Without this
> > > > > change the code never reaches board_init_r in the SPL and I think I
> > > > > have all the configurations correctly set.
> > > > 
> > > > I wonder why you'd ever want to reach board_init_r in the SPL. SPL is
> > > > there only to load the real U-Boot from whatever media, so you
> > > > usually use either NAND SPL
> > > 
> > > Here's a good point for me to jump in, I think.  There's two things to
> > > understand:
> > > - In the current in-tree SPL implementations the code flow is
> > > 
> > >   board_init_f calls relocate_code() to clear the BSS _and_ get our
> > >   jump to board_init_r.  It does not actually relocate the running
> > >   U-Boot, just clears the BSS.  board_init_r is what calls the things
> > >   to load and boot the next stage (U-Boot or Linux).
> > > 
> > > - In my series this has been changed slightly to be board_init_f calls
> > > 
> > >   memset and then board_init_r directly.  So this patch should not be
> > >   needed once rebased on that series.
> > 
> > Do we need to do all the relocation in assembler code btw? Can it not be
> > moved into C code and made generic across all platforms (module the
> > stack adjustment and a few minor things) ?
> 
> I think people have posted patches for this before and yes, once
> CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in C, so
> long as it doesn't grow in size or doesn't grow in size that would be
> problematic (remember the 4kb people).

How does MANUAL_RELOC interfere with that? Eg. on ARM, it can already be 
shifted 
to C. Then if we made it generic enough, those MANUAL_RELOC platforms could 
simply adopt the C code.

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 v2 01/11] ARM: fix relocation on ARM926EJS

[Tom Rini]

On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote:
> Dear Tom Rini,
> 
> > On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
> > > Dear Jos? Miguel Gon?alves,
> > > 
> > > > On 09/16/2012 11:06 AM, Marek Vasut wrote:
> > > > > Dear Jos? Miguel Gon?alves,
> > > > > 
> > > > >> On 09/15/2012 07:03 PM, Marek Vasut wrote:
> > > > >>> Dear Jos? Miguel Gon?alves,
> > > > >>> 
> > > >  Jumping to board_init_r is not performed due to a bug on address
> > > >  computation.
> > > > >>> 
> > > > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect
> > > > >>> any misbehavior on my arm926 boards.
> > > > >> 
> > > > >> Maybe because you are not using it to build an SPL?
> > > > > 
> > > > > I do ... and I use CONFIG_SPL_TEXT_BASE properly .
> > > > > 
> > > > >> Please check the same chunk of code in other start.S for arm1176 and
> > > > >> armv7. They have the same code that I put for arm926ejs.
> > > > > 
> > > > > Please wait and please first explain what is the issue.
> > > > 
> > > > The issue is what I've explained in the patch comments.
> > > 
> > > "Jumping to board_init_r is not performed due to a bug on address
> > > computation."
> > > 
> > > Ok, I don't know how to replicate the bug from this comment or what
> > > effects it causes or ... well, anything. So please, try to be more
> > > elaborate in your patch description next time. Anyway ..
> > > 
> > > > Without this
> > > > change the code never reaches board_init_r in the SPL and I think I
> > > > have all the configurations correctly set.
> > > 
> > > I wonder why you'd ever want to reach board_init_r in the SPL. SPL is
> > > there only to load the real U-Boot from whatever media, so you usually
> > > use either NAND SPL
> > 
> > Here's a good point for me to jump in, I think.  There's two things to
> > understand:
> > - In the current in-tree SPL implementations the code flow is
> >   board_init_f calls relocate_code() to clear the BSS _and_ get our jump
> >   to board_init_r.  It does not actually relocate the running U-Boot,
> >   just clears the BSS.  board_init_r is what calls the things to load
> >   and boot the next stage (U-Boot or Linux).
> > 
> > - In my series this has been changed slightly to be board_init_f calls
> >   memset and then board_init_r directly.  So this patch should not be
> >   needed once rebased on that series.
> 
> Do we need to do all the relocation in assembler code btw? Can it not be 
> moved 
> into C code and made generic across all platforms (module the stack 
> adjustment 
> and a few minor things) ?

I think people have posted patches for this before and yes, once
CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in C, so
long as it doesn't grow in size or doesn't grow in size that would be
problematic (remember the 4kb people).

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

Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile

[Scott Wood]

On 09/17/2012 11:51:52 AM, Tom Rini wrote:

On 09/17/12 09:27, Scott Wood wrote:
> On 09/17/2012 04:24:34 AM, José Miguel Gonçalves wrote:
[snip]
>> If no one else has anything against, I will change the name of the  
new

>> target to u-boot-pad.bin
>
> What exactly is u-boot-pad.bin supposed to be?  I hope that's not  
being

> proposed as the final output file the user sees.
>
> With old nand_spl we had u-boot-nand.bin for the final concatenated
> binary, but that's not appropriate for a generic spl.  I think it  
would
> be better for the user to see "u-boot.bin" as the actual image to  
put on

> the boot device, regardless of implementation details like spl, if
> there's no requirement of a specific file format.  The second stage
> could become "u-boot-main.bin" or similar on builds where spl is  
used.


We need some name that means "U-Boot SPL with U-Boot tacked on at the
end".  This can optionally be padded to a defined size to make writing
to hardware easier.  We also have the problem that "u-boot.bin"  
already

means something so it needs to be clear.


u-boot.bin has traditionally (except for nand_spl and derivatives)  
meant the final image ready to put into flash, after any  
platform-specific layout issues are taken care of (e.g. on mpc83xx it  
will have a reset control word embedded, on mpc85xx it will be padded  
to 512K with a reset vector at the end, etc.).  That we did the  
tweaking in the linker script rather than after linking seems like an  
inconsequential implementation detail.



I further fear that even if we
made an "out" directory if we put u-boot.bin in there and it's not the
same as the objcopy -O binary u-boot u-boot.bin as before we've  
violated

the rule of least surprise and the end user problems from people that
read "the" document (that happened to be out of date) will be our  
problem.


In this case I think you can't meet one user's expectations without  
violating another's.  I think it's more important to make it clear to  
the user what file they're supposed to put into flash.  Users of  
platforms that are currently supported by nand_spl would probably like  
to continue seeing u-boot-nand.bin -- it's a tradeoff of historical  
stability versus current consistency.



In short, at least a few people have said something along the lines of
"We need generic output nameo $mediums and targets" but there's two  
hard
problems, one of which is that every SoC _needs_ things tweaked just  
so

(no header? no boot!), sometimes wants things tweaked further (pad the
final image out to be easier to write to $medium) and sometimes needs
multiple files (the whole of 'SPL' will be read so it must fit into
$SMALL_MEMORY).  The other is naming.


A simple concatenation of a padded SPL plus the main U-Boot was good  
enough for all the nand_spl boards AFAIK, so it's not quite every SoC  
that needs something special here.  For those that do require a special  
format (or multiple files) with a file extension that is familiar to  
people working with that platform, using that extension makes sense.   
"pad" does not, and a proliferation of SoC-specific suffixes isn't much  
better.


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