date:20120322

Re: [U-Boot] Patchwork housekeeping

2012-03-22 Thread Marek Vasut

Dear Graeme Russ,

 Hello Custodians and Mailing List Aficionados,
 
 I don't know if anyone has noticed, but patchwork is starting to collect
 a rather large amount of cruft.
 
 I occasionally jump onto patchwork and do a little housekeeping by marking
 updated patches as 'Superceeded' and anything applied by Wolfgang as
 'Accepted' (There may be a few patches that have been applied to custodian
 tress that I marked as 'Accepted' when really they should have been marked
 as 'Awaiting Upstream')
 
 I really don't mind doing this housekeeping, but I would like to make a
 few suggestions that will make the work a little easier:
 
  - If you are a custodian:
 o When you apply a patch to your repo, can you please assign it to
   yourself in patchwork and set it to 'Awaiting Upstream'
 o Reply to the ML with 'Applied to repo/branch'
 o When you send a pull request, create a bundle with all the patches
   that are to be pulled (you can create the bundle early and add
   patches as you apply them)
 o When Wolfgang pulls your repo, go to the bundle and mark all the
   patches 'Accepted'
 
  - If you are a patch submitter:
 o Visit http://patchwork.ozlabs.org/project/uboot/list/
 o Search for your patches by following the 'Filters'link and entering
   your name
 o Send and email (with 'patchwork' somewhere in the subject) to the ML
   with a list of patches that you submitted say more than one month
   ago. For each patch, please indicate if the patch is:
 * Superseded - By another patch (either by you or someone else)
 * Not Applicable - The patch can be ignored (was an RFC, was due
   to a misunderstanding, another patch did the same thing, etc)
 * Applied - Has been applied (state the repo and branch)
 * Rejected - Patch has been officially rejected
 * Waiting - You believe the patch is still valid but has not been
   applied (send a ping as a reply to the patch on the mailing list
   as well
 * Other - Please describe what state you feel the patch is in
 
 Once I get the raw list down to a manageable level, I'll start to look at
 the leftovers...

WAT ? Yet another ruleset ... and a long one while at that. Maybe we should 
cobble together an U-Boot contributors guidebook ... printed edition with 1k 
pages ;-D

We really need to make it easier for people to contribute to u-boot, these long 
rulesets only ward people away.

 
 Regards,
 
 Your friendly Patchwork janitor Graeme

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 14/21] mvgbe: remove warning for unused methods

2012-03-22 Thread Holger Brunck

Hi Prafulla,

On 03/21/2012 05:30 PM, Prafulla Wadaskar wrote:
 Subject: [PATCH 14/21] mvgbe: remove warning for unused methods

 From: Stefan Bigler stefan.big...@keymile.com

 Some baords may use the GBE interface but they have no
 phy connected to the interface and a direct MAC/MAC interface.
 For them we need to get rid of compiler warnings.

 Signed-off-by: Stefan Bigler stefan.big...@keymile.com
 cc: Valentin Longchamp valentin.longch...@keymile.com
 cc: Gerlando Falauto gerlando.fala...@keymile.com
 cc: Prafulla Wadaskar prafu...@marvell.com
 cc: Holger Brunck holger.bru...@keymile.com
 ---
  drivers/net/mvgbe.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

 Pls post this as standalone patch, does not have any dependency.

it has a dependency. Without this patch our new boards submitted in this patch
series will throw compiler warnings. But if you still insist, I can do this...

Regards
Holger

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

Re: [U-Boot] [PATCH v6] mx6: Read silicon revision from register

2012-03-22 Thread Dirk Behme


On 21.03.2012 09:41, Stefano Babic wrote:

On 20/03/2012 15:21, Fabio Estevam wrote:

Instead of hardcoding the mx6 silicon revision, read it in run-time.

Also, besides the silicon version print the mx6 variant type: quad,dual/solo 
or solo-lite.


Tested on a mx6qsabrelite, where it shows:

CPU:   Freescale i.MX6Q rev1.0 at 792 MHz  


Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---


Applied to u-boot-imx, thanks.


Thanks!

Sounds like this

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

would be a good candidate to put it on top of this, now?

Best regards

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

Re: [U-Boot] [PATCH 10/21] spi/kirkwood: add weak functions board_spi_bus_claim/release

2012-03-22 Thread Holger Brunck

Hi Prafulla,

On 03/21/2012 05:30 PM, Prafulla Wadaskar wrote:
 Subject: [PATCH 10/21] spi/kirkwood: add weak functions
 board_spi_bus_claim/release

 From: Valentin Longchamp valentin.longch...@keymile.com

 Some kirkwood based boards may need to implement such function due to
 some HW designs.

 Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
 cc: Gerlando Falauto gerlando.fala...@keymile.com
 cc: Prafulla Wadaskar prafu...@marvell.com
 cc: Holger Brunck holger.bru...@keymile.com
 ---

 Pls post this as standalone patch, does not have any dependency.
 Exclude from this patch series.

hm, without this patch this patchserie will end up in boards wich are not able
to work properly. So for me there is a dependancy. But if you still insist...

Regards
Holger

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

Re: [U-Boot] [PATCH v6] mx6: Read silicon revision from register

2012-03-22 Thread Stefano Babic

On 22/03/2012 08:48, Dirk Behme wrote:
 On 21.03.2012 09:41, Stefano Babic wrote:
 On 20/03/2012 15:21, Fabio Estevam wrote:
 Instead of hardcoding the mx6 silicon revision, read it in run-time.

 Also, besides the silicon version print the mx6 variant type:
 quad,dual/solo or solo-lite.

 Tested on a mx6qsabrelite, where it shows:

 CPU:   Freescale i.MX6Q rev1.0 at 792 MHz 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

 Applied to u-boot-imx, thanks.
 
 Thanks!
 
 Sounds like this
 
 http://patchwork.ozlabs.org/patch/147669/

It is already acked, I leave always some days for later comments before
applying a patch - sure, it will be applied, too.

Best regards,
Stefano

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

Re: [U-Boot] [PATCH 14/21] mvgbe: remove warning for unused methods

2012-03-22 Thread Prafulla Wadaskar



 -Original Message-
 From: Holger Brunck [mailto:holger.bru...@keymile.com]
 Sent: 22 March 2012 13:20
 To: Prafulla Wadaskar
 Cc: u-boot@lists.denx.de; Stefan Bigler; Valentin Longchamp; Gerlando
 Falauto
 Subject: Re: [PATCH 14/21] mvgbe: remove warning for unused methods
 
 Hi Prafulla,
 
 On 03/21/2012 05:30 PM, Prafulla Wadaskar wrote:
  Subject: [PATCH 14/21] mvgbe: remove warning for unused methods
 
  From: Stefan Bigler stefan.big...@keymile.com
 
  Some baords may use the GBE interface but they have no
  phy connected to the interface and a direct MAC/MAC interface.
  For them we need to get rid of compiler warnings.
 
  Signed-off-by: Stefan Bigler stefan.big...@keymile.com
  cc: Valentin Longchamp valentin.longch...@keymile.com
  cc: Gerlando Falauto gerlando.fala...@keymile.com
  cc: Prafulla Wadaskar prafu...@marvell.com
  cc: Holger Brunck holger.bru...@keymile.com
  ---
   drivers/net/mvgbe.c |2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)
 
 
  Pls post this as standalone patch, does not have any dependency.
 
 
 it has a dependency. Without this patch our new boards submitted in
 this patch
 series will throw compiler warnings. But if you still insist, I can do
 this...

This should be okay, please post t separately

Regards..
Prafulla . . .


 
 Regards
 Holger

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

[U-Boot] patchwork: net/eth.c: fix eth_write_hwaddr() to use dev-enetaddr as fall back

2012-03-22 Thread Dirk Behme



Waiting: http://patchwork.ozlabs.org/patch/136789/


This mail is according to

http://lists.denx.de/pipermail/u-boot/2012-March/120778.html

Best regards

Dirk

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

[U-Boot] patchwork: miiphyutil: Add Micrel KSZ9021 support to miiphy_speed

2012-03-22 Thread Dirk Behme



Superseded:

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

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

Updated patch applied instead:

http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commit;h=8682aba7da2af2842296710acca7c03fcebafd5c


This mail is according to

http://lists.denx.de/pipermail/u-boot/2012-March/120778.html

Best regards

Dirk


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

Re: [U-Boot] [PATCH] USB: ehci-mx6: Add proper IO accessors

2012-03-22 Thread Liu Hui-R64343

-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
On Behalf Of Fabio Estevam
Sent: Tuesday, March 20, 2012 6:36 AM
To: u-boot@lists.denx.de
Cc: ma...@denx.de; Estevam Fabio-R49496; w...@denx.de
Subject: [U-Boot] [PATCH] USB: ehci-mx6: Add proper IO accessors

Add proper IO accessors for mx6 usb registers.

Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
This patch depends on [PATCH v5] mx6: Read silicon revision from register

 drivers/usb/host/ehci-mx6.c |   13 -
 1 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c index
b7bf49d..5dec673 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -46,13 +46,9 @@
 #define USBPHY_CTRL_ENUTMILEVEL3  0x8000
 #define USBPHY_CTRL_ENUTMILEVEL2  0x4000

-#define ANADIG_USB2_CHRG_DETECT   0x0210
 #define ANADIG_USB2_CHRG_DETECT_EN_B  0x0010
 #define ANADIG_USB2_CHRG_DETECT_CHK_CHRG_B0x0008

-#define ANADIG_USB2_PLL_480_CTRL  0x0020
-#define ANADIG_USB2_PLL_480_CTRL_SET  0x0024
-#define ANADIG_USB2_PLL_480_CTRL_CLR  0x0028
 #define ANADIG_USB2_PLL_480_CTRL_BYPASS   0x0001
 #define ANADIG_USB2_PLL_480_CTRL_ENABLE   0x2000
 #define ANADIG_USB2_PLL_480_CTRL_POWER0x1000
@@ -77,8 +73,7 @@ static void usbh1_internal_phy_clock_gate(int on)

 static void usbh1_power_config(void)
 {
-  void __iomem *anatop_base = (void __iomem *)ANATOP_BASE_ADDR;
-
+  struct anatop_regs *anatop = (struct anatop_regs
*)ANATOP_BASE_ADDR;
   /*
* Some phy and power's special controls for host1
* 1. The external charger detector needs to be disabled @@ -89,15
+84,15 @@ static void usbh1_power_config(void)
*/
   __raw_writel(ANADIG_USB2_CHRG_DETECT_EN_B |
ANADIG_USB2_CHRG_DETECT_CHK_CHRG_B,
-   anatop_base + ANADIG_USB2_CHRG_DETECT);
+   anatop-usb2_chrg_detect);

   __raw_writel(ANADIG_USB2_PLL_480_CTRL_BYPASS,
-   anatop_base + ANADIG_USB2_PLL_480_CTRL_CLR);
+   anatop-usb2_pll_480_ctrl);

   __raw_writel(ANADIG_USB2_PLL_480_CTRL_ENABLE |
ANADIG_USB2_PLL_480_CTRL_POWER |
ANADIG_USB2_PLL_480_CTRL_EN_USB_CLKS,
-   anatop_base + ANADIG_USB2_PLL_480_CTRL_SET);
+   anatop-usb2_pll_480_ctrl_set);
 }

 static int usbh1_phy_enable(void)

Acked-by: Jason Liu r64...@freescale.com

--
1.7.1

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


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

[U-Boot] reminder for [PATCH 0/5] Support for qualcomm msm7630 board

2012-03-22 Thread mohamed.haneef

From: Mohamed Haneef mohamed.han...@lntinfotech.com

This is a humbel reminder for review  of patch series for msm7630 board after 
making the changes proposed by u-boot community. The Patches contain the 
following support
* low speed uart for msm7630
* interprocessor communication
* qc_mmc microcontroller
* msm7630 soc
* msm7630 surf board


The contents of this e-mail and any attachment(s) may contain confidential or 
privileged information for the intended recipient(s). Unintended recipients are 
prohibited from taking action on the basis of information in this e-mail and  
using or disseminating the information,  and must notify the sender and delete 
it from their system. LT Infotech will not accept responsibility or liability 
for the accuracy or completeness of, or the presence of any virus or disabling 
code in this e-mail
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 05/14] cfb_console: Fix function console_scrollup

2012-03-22 Thread Pali Rohár

On Wednesday 21 March 2012 23:58:10 Anatolij Gustschin wrote:
 On Wed, 21 Mar 2012 19:50:34 +0100
 Pali Rohár pali.ro...@gmail.com wrote:
 ...

  Hi, can you show me how to fix this? How to correctly use
  framebuffer?

 Hi,

 Not really. This would be a new project to rewrite U-Boot driver
 for OMAP3 DSS. There is a driver under drivers/video/omap3_dss.c,
 but it doesn't do what we need here. You can try to set
 gdev.frameAdrs to point to another address range in RAM which is
 not used by U-Boot. Then get OMAP3430 TRM and read DSS
 documentation how to configure the display controller so that is
 displays frame buffer data from this address range. Currently I do
 not have time nor resources to rewrite the existing omap3_dss
 driver.

 Thanks,
 Anatolij

Do you think that mapped address of framebuffer is only problem? Why
then framebuffer output on n900 screen working without problem if I
do NOT read framebuffer memory? Problem with garbaged display output
seems happends only for read operations (console_scrollup, negation
of pixels for cursor,...) but not for write-only operations (clear
console, clear line, set black/white cursror, render fonsts...). I
think if there is problem with address space, then garbaged screen
should be also for framebuffer write operations...

--
Pali Rohár
pali.ro...@gmail.com

signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] BOOT: Add RAW ramdisk support to bootz

2012-03-22 Thread Marek Vasut

Dear Rob Herring,

 From: Marek Vasut marek.va...@gmail.com
 
 This patch allows loading RAW ramdisk via bootz command. The raw ramdisk is
 loaded only in case it's size is specified:
 
   bootz kernel addr ramdisk addr:ramdisk size fdt addr
 
 For example:
 
   bootz 0x4200 0x4300:0x12345 0x4400
 
 Signed-off-by: Marek Vasut ma...@denx.de
 Signed-off-by: Rob Herring rob.herr...@calxeda.com
 Cc: Tom Warren twar...@nvidia.com
 Cc: albert.u.b...@aribaud.net
 Cc: aflem...@gmail.com
 Cc: Simon Glass s...@chromium.org
 Cc: Stephen Warren swar...@nvidia.com
 Cc: Nicolas Pitre n...@fluxnic.net
 Cc: Wolfgang Denk w...@denx.de
 Cc: Detlev Zundel d...@denx.de

Doesn't this still colide with CONFIG_FIT? Aka. in case of CONFIG_FIT enabled, 
you can't use raw ramdisk?

btw. maybe we should use @ instead of : and be done with it?

 ---
 V3:
 - fix operation when CONFIG_FIT is enabled as FIT images use
   addr[:subimage]
 
  README |5 +
  common/cmd_bootm.c |6 --
  common/image.c |   15 ---
  3 files changed, 21 insertions(+), 5 deletions(-)
 
 diff --git a/README b/README
 index 5141751..068ec71 100644
 --- a/README
 +++ b/README
 @@ -4330,6 +4330,11 @@ On some platforms, it's possible to boot Linux
 zImage. This is done using the bootz command. The syntax of bootz
 command is the same as the syntax of bootm command.
 
 +Note, defining the CONFIG_SUPPORT_INITRD_RAW allows user to supply
 +kernel with raw initrd images. The syntax is slightly different, the
 +address of the initrd must be augmented by it's size, in the following
 +format: initrd addres:initrd size.
 +
 
  Standalone HOWTO:
  =
 diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
 index b49d4f7..2f9b214 100644
 --- a/common/cmd_bootm.c
 +++ b/common/cmd_bootm.c
 @@ -1634,9 +1634,11 @@ static int do_bootz(cmd_tbl_t *cmdtp, int flag, int
 argc, char * const argv[]) U_BOOT_CMD(
   bootz,  CONFIG_SYS_MAXARGS, 1,  do_bootz,
   boot Linux zImage image from memory,
 - [addr [initrd] [fdt]]\n- boot Linux zImage stored in memory\n
 + [addr [initrd[:size]] [fdt]]\n
 + - boot Linux zImage stored in memory\n
   \tThe argument 'initrd' is optional and specifies the address\n
 - \tof the initrd in memory.\n
 + \tof the initrd in memory. The optional argument ':size' allows\n
 + \tspecifying the size of RAW initrd.\n
  #if defined(CONFIG_OF_LIBFDT)
   \tWhen booting a Linux kernel which requires a flat device-tree\n
   \ta third argument is required which is the address of the\n
 diff --git a/common/image.c b/common/image.c
 index 77ca6e4..2a25f5f 100644
 --- a/common/image.c
 +++ b/common/image.c
 @@ -796,6 +796,7 @@ int boot_get_ramdisk(int argc, char * const argv[],
 bootm_headers_t *images, ulong rd_addr, rd_load;
   ulong rd_data, rd_len;
   const image_header_t *rd_hdr;
 + char *end;
  #if defined(CONFIG_FIT)
   void*fit_hdr;
   const char  *fit_uname_config = NULL;
 @@ -989,9 +990,17 @@ int boot_get_ramdisk(int argc, char * const argv[],
 bootm_headers_t *images, break;
  #endif
   default:
 - puts(Wrong Ramdisk Image Format\n);
 - rd_data = rd_len = rd_load = 0;
 - return 1;
 +#ifdef CONFIG_SUPPORT_RAW_INITRD
 + if (argc = 3  (end = strchr(argv[2], ':'))) {
 + rd_len = simple_strtoul(++end, NULL, 16);
 + rd_data = rd_addr;
 + } else
 +#endif
 + {
 + puts(Wrong Ramdisk Image Format\n);
 + rd_data = rd_len = rd_load = 0;
 + return 1;
 + }
   }
   } else if (images-legacy_hdr_valid 
   image_check_type(images-legacy_hdr_os_copy,

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 10/21] spi/kirkwood: add weak functions board_spi_bus_claim/release

2012-03-22 Thread Prafulla Wadaskar

 -Original Message-
 From: Holger Brunck [mailto:holger.bru...@keymile.com]
 Sent: 22 March 2012 13:28
 To: Prafulla Wadaskar
 Cc: u-boot@lists.denx.de; Valentin Longchamp; Gerlando Falauto
 Subject: Re: [PATCH 10/21] spi/kirkwood: add weak functions
 board_spi_bus_claim/release

 Hi Prafulla,

 On 03/21/2012 05:30 PM, Prafulla Wadaskar wrote:
  Subject: [PATCH 10/21] spi/kirkwood: add weak functions
  board_spi_bus_claim/release

  From: Valentin Longchamp valentin.longch...@keymile.com

  Some kirkwood based boards may need to implement such function due
 to
  some HW designs.

  Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
  cc: Gerlando Falauto gerlando.fala...@keymile.com
  cc: Prafulla Wadaskar prafu...@marvell.com
  cc: Holger Brunck holger.bru...@keymile.com
  ---

  Pls post this as standalone patch, does not have any dependency.
  Exclude from this patch series.

 hm, without this patch this patchserie will end up in boards wich are
 not able
 to work properly. So for me there is a dependancy. But if you still
 insist...

You may mention this as dependency, you can always test your board by applying 
this patch, whereas this is specific to SPI and I think should go separately 
(may be through other custodian).

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

Re: [U-Boot] [PATCH] NAND: TI: fix warnings in omap_gpmc.c

2012-03-22 Thread Stefano Babic

On 21/03/2012 19:42, Scott Wood wrote:
 On 03/21/2012 06:33 AM, Stefano Babic wrote:
 The following warnings are reported for boards using SOFT ECC.

 omap_gpmc.c:33:30: warning: 'hw_nand_oob' defined but not used
 omap_gpmc.c:78:13: warning: 'omap_hwecc_init' defined but not used
 omap_gpmc.c:116:12: warning: 'omap_correct_data' defined but not used
 omap_gpmc.c:182:12: warning: 'omap_calculate_ecc' defined but not used
 omap_gpmc.c:208:13: warning: 'omap_enable_hwecc' defined but not used

 Signed-off-by: Stefano Babic sba...@denx.de
 Cc: Tom Rini tr...@ti.com
 Cc: Scott Wood scottw...@freescale.com
 ---
  drivers/mtd/nand/omap_gpmc.c |6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)

 diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
 index 1dfe074..3a9baff 100644
 --- a/drivers/mtd/nand/omap_gpmc.c
 +++ b/drivers/mtd/nand/omap_gpmc.c
 @@ -30,7 +30,10 @@
  #include nand.h
  
  static uint8_t cs;
 +#if !defined(CONFIG_SPL_BUILD) || \
 +(defined(CONFIG_SPL_BUILD)  !defined(CONFIG_SPL_NAND_SOFTECC))
  static struct nand_ecclayout hw_nand_oob = GPMC_NAND_HW_ECC_LAYOUT;
 +#endif
  
  /*
   * omap_nand_hwcontrol - Set the address pointers corretly for the
 @@ -69,6 +72,8 @@ int omap_spl_dev_ready(struct mtd_info *mtd)
  }
  #endif
  
 +#if !defined(CONFIG_SPL_BUILD) || \
 +(defined(CONFIG_SPL_BUILD)  !defined(CONFIG_SPL_NAND_SOFTECC))
  /*
   * omap_hwecc_init - Initialize the Hardware ECC for NAND flash in
   *   GPMC controller
 @@ -231,6 +236,7 @@ static void omap_enable_hwecc(struct mtd_info *mtd, 
 int32_t mode)
  break;
  }
  }
 +#endif
  
  #ifndef CONFIG_SPL_BUILD
  /*
 
 Maybe just use __attribute__((unused))?

Of yourse, you are right. We have already the macro __maybe_unused, I
will use it !

Stefano

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

[U-Boot] [PATCH V2] NAND: TI: fix warnings in omap_gpmc.c

2012-03-22 Thread Stefano Babic

The following warnings are reported for boards using SOFT ECC.

omap_gpmc.c:33:30: warning: 'hw_nand_oob' defined but not used
omap_gpmc.c:78:13: warning: 'omap_hwecc_init' defined but not used
omap_gpmc.c:116:12: warning: 'omap_correct_data' defined but not used
omap_gpmc.c:182:12: warning: 'omap_calculate_ecc' defined but not used
omap_gpmc.c:208:13: warning: 'omap_enable_hwecc' defined but not used

Signed-off-by: Stefano Babic sba...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Scott Wood scottw...@freescale.com
---

Changes since V1:
- drop #ifdef and use  __attribute__((unused) (Scott Wood)

 drivers/mtd/nand/omap_gpmc.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 1dfe074..ca868ef 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -27,10 +27,12 @@
 #include asm/arch/mem.h
 #include asm/arch/omap_gpmc.h
 #include linux/mtd/nand_ecc.h
+#include linux/compiler.h
 #include nand.h
 
 static uint8_t cs;
-static struct nand_ecclayout hw_nand_oob = GPMC_NAND_HW_ECC_LAYOUT;
+static __maybe_unused struct nand_ecclayout hw_nand_oob =
+   GPMC_NAND_HW_ECC_LAYOUT;
 
 /*
  * omap_nand_hwcontrol - Set the address pointers corretly for the
@@ -75,7 +77,7 @@ int omap_spl_dev_ready(struct mtd_info *mtd)
  * @mtd:MTD device structure
  *
  */
-static void omap_hwecc_init(struct nand_chip *chip)
+static void __maybe_unused omap_hwecc_init(struct nand_chip *chip)
 {
/*
 * Init ECC Control Register
@@ -113,7 +115,7 @@ static uint32_t gen_true_ecc(uint8_t *ecc_buf)
  *
  * @return 0 if data is OK or corrected, else returns -1
  */
-static int omap_correct_data(struct mtd_info *mtd, uint8_t *dat,
+static int __maybe_unused omap_correct_data(struct mtd_info *mtd, uint8_t *dat,
uint8_t *read_ecc, uint8_t *calc_ecc)
 {
uint32_t orig_ecc, new_ecc, res, hm;
@@ -179,8 +181,8 @@ static int omap_correct_data(struct mtd_info *mtd, uint8_t 
*dat,
  *  @dat:  unused
  *  @ecc_code: ecc_code buffer
  */
-static int omap_calculate_ecc(struct mtd_info *mtd, const uint8_t *dat,
-   uint8_t *ecc_code)
+static int __maybe_unused omap_calculate_ecc(struct mtd_info *mtd,
+   const uint8_t *dat, uint8_t *ecc_code)
 {
u_int32_t val;
 
@@ -205,7 +207,7 @@ static int omap_calculate_ecc(struct mtd_info *mtd, const 
uint8_t *dat,
  * @mtd:MTD device structure
  * @mode:   Read/Write mode
  */
-static void omap_enable_hwecc(struct mtd_info *mtd, int32_t mode)
+static void __maybe_unused omap_enable_hwecc(struct mtd_info *mtd, int32_t 
mode)
 {
struct nand_chip *chip = mtd-priv;
uint32_t val, dev_width = (chip-options  NAND_BUSWIDTH_16)  1;
-- 
1.7.5.4

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

Re: [U-Boot] patchwork: miiphyutil: Add Micrel KSZ9021 support to miiphy_speed

2012-03-22 Thread Graeme Russ

Hi Dirk,

On 03/22/2012 07:40 PM, Dirk Behme wrote:
 
 Superseded:
 
 http://patchwork.ozlabs.org/patch/135813/
 
 http://patchwork.ozlabs.org/patch/136834/
 
 Updated patch applied instead:
 
 http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commit;h=8682aba7da2af2842296710acca7c03fcebafd5c

Updated in patchwork

Thanks,

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

Re: [U-Boot] patchwork: net/eth.c: fix eth_write_hwaddr() to use dev-enetaddr as fall back

2012-03-22 Thread Graeme Russ

Hi Dirk,

On 03/22/2012 07:31 PM, Dirk Behme wrote:
 
 Waiting: http://patchwork.ozlabs.org/patch/136789/
 

Assigned to Wolfgang and changed state to 'Under Review' (seemed most
appropriate status)

Regards,

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

Re: [U-Boot] Patchwork housekeeping

2012-03-22 Thread Graeme Russ

Hi Marek,

On 03/22/2012 05:45 PM, Marek Vasut wrote:
 Dear Graeme Russ,
 
 Hello Custodians and Mailing List Aficionados,

 I don't know if anyone has noticed, but patchwork is starting to collect
 a rather large amount of cruft.

 I occasionally jump onto patchwork and do a little housekeeping by marking
 updated patches as 'Superceeded' and anything applied by Wolfgang as
 'Accepted' (There may be a few patches that have been applied to custodian
 tress that I marked as 'Accepted' when really they should have been marked
 as 'Awaiting Upstream')

 I really don't mind doing this housekeeping, but I would like to make a
 few suggestions that will make the work a little easier:

  - If you are a custodian:
 o When you apply a patch to your repo, can you please assign it to
   yourself in patchwork and set it to 'Awaiting Upstream'
 o Reply to the ML with 'Applied to repo/branch'
 o When you send a pull request, create a bundle with all the patches
   that are to be pulled (you can create the bundle early and add
   patches as you apply them)
 o When Wolfgang pulls your repo, go to the bundle and mark all the
   patches 'Accepted'

  - If you are a patch submitter:
 o Visit http://patchwork.ozlabs.org/project/uboot/list/
 o Search for your patches by following the 'Filters'link and entering
   your name
 o Send and email (with 'patchwork' somewhere in the subject) to the ML
   with a list of patches that you submitted say more than one month
   ago. For each patch, please indicate if the patch is:
 * Superseded - By another patch (either by you or someone else)
 * Not Applicable - The patch can be ignored (was an RFC, was due
   to a misunderstanding, another patch did the same thing, etc)
 * Applied - Has been applied (state the repo and branch)
 * Rejected - Patch has been officially rejected
 * Waiting - You believe the patch is still valid but has not been
   applied (send a ping as a reply to the patch on the mailing list
   as well
 * Other - Please describe what state you feel the patch is in

 Once I get the raw list down to a manageable level, I'll start to look at
 the leftovers...
 
 WAT ? Yet another ruleset ... and a long one while at that. Maybe we should 
 cobble together an U-Boot contributors guidebook ... printed edition with 
 1k 
 pages ;-D

The submission rules (http://www.denx.de/wiki/U-Boot/Patches) are pretty
clear and concise (I've added a not about starting the subject with a tag)

 We really need to make it easier for people to contribute to u-boot, these 
 long 
 rulesets only ward people away.

This patchwork cleanup should really only be a once off to try and get
things cleaned up a bit. There are patches in patchwork from 2009, if we
can get some of the stale patches cleaned out (and contact the submitters
to see if they are interested in resubmitting or verifying re-based
patches) then we will all be better off.

Nothing is more discouraging to patch submitters than patches that get ignored.

Regards,

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

Re: [U-Boot] Patchwork housekeeping

2012-03-22 Thread Marek Vasut

Dear Graeme Russ,

 Hi Marek,
 
 On 03/22/2012 05:45 PM, Marek Vasut wrote:
  Dear Graeme Russ,
  
  Hello Custodians and Mailing List Aficionados,
  
  I don't know if anyone has noticed, but patchwork is starting to collect
  a rather large amount of cruft.
  
  I occasionally jump onto patchwork and do a little housekeeping by
  marking updated patches as 'Superceeded' and anything applied by
  Wolfgang as 'Accepted' (There may be a few patches that have been
  applied to custodian tress that I marked as 'Accepted' when really they
  should have been marked as 'Awaiting Upstream')
  
  I really don't mind doing this housekeeping, but I would like to make a
  
  few suggestions that will make the work a little easier:
   - If you are a custodian:
  o When you apply a patch to your repo, can you please assign it to
  
yourself in patchwork and set it to 'Awaiting Upstream'
  
  o Reply to the ML with 'Applied to repo/branch'
  o When you send a pull request, create a bundle with all the patches
  
that are to be pulled (you can create the bundle early and add
patches as you apply them)
  
  o When Wolfgang pulls your repo, go to the bundle and mark all the
  
patches 'Accepted'
   
   - If you are a patch submitter:
  o Visit http://patchwork.ozlabs.org/project/uboot/list/
  o Search for your patches by following the 'Filters'link and
  entering
  
your name
  
  o Send and email (with 'patchwork' somewhere in the subject) to the
  ML
  
with a list of patches that you submitted say more than one month

ago. For each patch, please indicate if the patch is:
  * Superseded - By another patch (either by you or someone else)
  * Not Applicable - The patch can be ignored (was an RFC, was due
  
to a misunderstanding, another patch did the same thing, etc)
  
  * Applied - Has been applied (state the repo and branch)
  * Rejected - Patch has been officially rejected
  * Waiting - You believe the patch is still valid but has not
  been
  
applied (send a ping as a reply to the patch on the mailing
list as well
  
  * Other - Please describe what state you feel the patch is in
  
  Once I get the raw list down to a manageable level, I'll start to look
  at the leftovers...
  
  WAT ? Yet another ruleset ... and a long one while at that. Maybe we
  should cobble together an U-Boot contributors guidebook ... printed
  edition with 1k pages ;-D
 
 The submission rules (http://www.denx.de/wiki/U-Boot/Patches) are pretty
 clear and concise (I've added a not about starting the subject with a tag)

Some distilled down version for first-time comers won't hurt of that page.
 
  We really need to make it easier for people to contribute to u-boot,
  these long rulesets only ward people away.
 
 This patchwork cleanup should really only be a once off to try and get
 things cleaned up a bit. There are patches in patchwork from 2009, if we
 can get some of the stale patches cleaned out (and contact the submitters
 to see if they are interested in resubmitting or verifying re-based
 patches) then we will all be better off.

Agreed
 
 Nothing is more discouraging to patch submitters than patches that get
 ignored.

Yes
 
 Regards,
 
 Graeme

Thanks for working on this, Graeme, I really appreciate that

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] BOOT: Add RAW ramdisk support to bootz

2012-03-22 Thread Rob Herring

On 03/22/2012 04:10 AM, Marek Vasut wrote:
 Dear Rob Herring,
 
 From: Marek Vasut marek.va...@gmail.com

 This patch allows loading RAW ramdisk via bootz command. The raw ramdisk is
 loaded only in case it's size is specified:

   bootz kernel addr ramdisk addr:ramdisk size fdt addr

 For example:

   bootz 0x4200 0x4300:0x12345 0x4400

 Signed-off-by: Marek Vasut ma...@denx.de
 Signed-off-by: Rob Herring rob.herr...@calxeda.com
 Cc: Tom Warren twar...@nvidia.com
 Cc: albert.u.b...@aribaud.net
 Cc: aflem...@gmail.com
 Cc: Simon Glass s...@chromium.org
 Cc: Stephen Warren swar...@nvidia.com
 Cc: Nicolas Pitre n...@fluxnic.net
 Cc: Wolfgang Denk w...@denx.de
 Cc: Detlev Zundel d...@denx.de
 
 Doesn't this still colide with CONFIG_FIT? Aka. in case of CONFIG_FIT 
 enabled, 
 you can't use raw ramdisk?

No. All the parsing now is done after trying to read the image type.
Only if a valid legacy or FIT uImage is not found, do we hit the raw
image code and parse the size. I tested both with and without CONFIG_FIT
enabled.

 
 btw. maybe we should use @ instead of : and be done with it?

Sub images will have an @ in the name. I thought about parsing for that,
but DT has no requirement that you have to have an @ in the node name
and it's not clear to me if u-boot convention requires it or not. Then I
came up with the current patch, so it doesn't matter.

Rob

 
 ---
 V3:
 - fix operation when CONFIG_FIT is enabled as FIT images use
   addr[:subimage]

  README |5 +
  common/cmd_bootm.c |6 --
  common/image.c |   15 ---
  3 files changed, 21 insertions(+), 5 deletions(-)

 diff --git a/README b/README
 index 5141751..068ec71 100644
 --- a/README
 +++ b/README
 @@ -4330,6 +4330,11 @@ On some platforms, it's possible to boot Linux
 zImage. This is done using the bootz command. The syntax of bootz
 command is the same as the syntax of bootm command.

 +Note, defining the CONFIG_SUPPORT_INITRD_RAW allows user to supply
 +kernel with raw initrd images. The syntax is slightly different, the
 +address of the initrd must be augmented by it's size, in the following
 +format: initrd addres:initrd size.
 +

  Standalone HOWTO:
  =
 diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
 index b49d4f7..2f9b214 100644
 --- a/common/cmd_bootm.c
 +++ b/common/cmd_bootm.c
 @@ -1634,9 +1634,11 @@ static int do_bootz(cmd_tbl_t *cmdtp, int flag, int
 argc, char * const argv[]) U_BOOT_CMD(
  bootz,  CONFIG_SYS_MAXARGS, 1,  do_bootz,
  boot Linux zImage image from memory,
 -[addr [initrd] [fdt]]\n- boot Linux zImage stored in memory\n
 +[addr [initrd[:size]] [fdt]]\n
 +- boot Linux zImage stored in memory\n
  \tThe argument 'initrd' is optional and specifies the address\n
 -\tof the initrd in memory.\n
 +\tof the initrd in memory. The optional argument ':size' allows\n
 +\tspecifying the size of RAW initrd.\n
  #if defined(CONFIG_OF_LIBFDT)
  \tWhen booting a Linux kernel which requires a flat device-tree\n
  \ta third argument is required which is the address of the\n
 diff --git a/common/image.c b/common/image.c
 index 77ca6e4..2a25f5f 100644
 --- a/common/image.c
 +++ b/common/image.c
 @@ -796,6 +796,7 @@ int boot_get_ramdisk(int argc, char * const argv[],
 bootm_headers_t *images, ulong rd_addr, rd_load;
  ulong rd_data, rd_len;
  const image_header_t *rd_hdr;
 +char *end;
  #if defined(CONFIG_FIT)
  void*fit_hdr;
  const char  *fit_uname_config = NULL;
 @@ -989,9 +990,17 @@ int boot_get_ramdisk(int argc, char * const argv[],
 bootm_headers_t *images, break;
  #endif
  default:
 -puts(Wrong Ramdisk Image Format\n);
 -rd_data = rd_len = rd_load = 0;
 -return 1;
 +#ifdef CONFIG_SUPPORT_RAW_INITRD
 +if (argc = 3  (end = strchr(argv[2], ':'))) {
 +rd_len = simple_strtoul(++end, NULL, 16);
 +rd_data = rd_addr;
 +} else
 +#endif
 +{
 +puts(Wrong Ramdisk Image Format\n);
 +rd_data = rd_len = rd_load = 0;
 +return 1;
 +}
  }
  } else if (images-legacy_hdr_valid 
  image_check_type(images-legacy_hdr_os_copy,
 
 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] BOOT: Add RAW ramdisk support to bootz

2012-03-22 Thread Marek Vasut

Dear Rob Herring,

 On 03/22/2012 04:10 AM, Marek Vasut wrote:
  Dear Rob Herring,
  
  From: Marek Vasut marek.va...@gmail.com
  
  This patch allows loading RAW ramdisk via bootz command. The raw ramdisk
  is
  
  loaded only in case it's size is specified:
bootz kernel addr ramdisk addr:ramdisk size fdt addr
  
  For example:
bootz 0x4200 0x4300:0x12345 0x4400
  
  Signed-off-by: Marek Vasut ma...@denx.de
  Signed-off-by: Rob Herring rob.herr...@calxeda.com
  Cc: Tom Warren twar...@nvidia.com
  Cc: albert.u.b...@aribaud.net
  Cc: aflem...@gmail.com
  Cc: Simon Glass s...@chromium.org
  Cc: Stephen Warren swar...@nvidia.com
  Cc: Nicolas Pitre n...@fluxnic.net
  Cc: Wolfgang Denk w...@denx.de
  Cc: Detlev Zundel d...@denx.de
  
  Doesn't this still colide with CONFIG_FIT? Aka. in case of CONFIG_FIT
  enabled, you can't use raw ramdisk?
 
 No. All the parsing now is done after trying to read the image type.
 Only if a valid legacy or FIT uImage is not found, do we hit the raw
 image code and parse the size. I tested both with and without CONFIG_FIT
 enabled.
 
  btw. maybe we should use @ instead of : and be done with it?
 
 Sub images will have an @ in the name. I thought about parsing for that,
 but DT has no requirement that you have to have an @ in the node name
 and it's not clear to me if u-boot convention requires it or not. Then I
 came up with the current patch, so it doesn't matter.

Dear Wolfgang Denk, are we OK with applying this and bootz patch please? Can we 
get it into .04 release please?

 
 Rob
 
  ---
  V3:
  - fix operation when CONFIG_FIT is enabled as FIT images use
  
addr[:subimage]
   
   README |5 +
   common/cmd_bootm.c |6 --
   common/image.c |   15 ---
   3 files changed, 21 insertions(+), 5 deletions(-)
  
  diff --git a/README b/README
  index 5141751..068ec71 100644
  --- a/README
  +++ b/README
  @@ -4330,6 +4330,11 @@ On some platforms, it's possible to boot Linux
  zImage. This is done using the bootz command. The syntax of bootz
  command is the same as the syntax of bootm command.
  
  +Note, defining the CONFIG_SUPPORT_INITRD_RAW allows user to supply
  +kernel with raw initrd images. The syntax is slightly different, the
  +address of the initrd must be augmented by it's size, in the following
  +format: initrd addres:initrd size.
  +
  
   Standalone HOWTO:
   =
  
  diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
  index b49d4f7..2f9b214 100644
  --- a/common/cmd_bootm.c
  +++ b/common/cmd_bootm.c
  @@ -1634,9 +1634,11 @@ static int do_bootz(cmd_tbl_t *cmdtp, int flag,
  int argc, char * const argv[]) U_BOOT_CMD(
  
 bootz,  CONFIG_SYS_MAXARGS, 1,  do_bootz,
 boot Linux zImage image from memory,
  
  -  [addr [initrd] [fdt]]\n- boot Linux zImage stored in memory\n
  +  [addr [initrd[:size]] [fdt]]\n
  +  - boot Linux zImage stored in memory\n
  
 \tThe argument 'initrd' is optional and specifies the address\n
  
  -  \tof the initrd in memory.\n
  +  \tof the initrd in memory. The optional argument ':size' allows\n
  +  \tspecifying the size of RAW initrd.\n
  
   #if defined(CONFIG_OF_LIBFDT)
   
 \tWhen booting a Linux kernel which requires a flat device-tree\n
 \ta third argument is required which is the address of the\n
  
  diff --git a/common/image.c b/common/image.c
  index 77ca6e4..2a25f5f 100644
  --- a/common/image.c
  +++ b/common/image.c
  @@ -796,6 +796,7 @@ int boot_get_ramdisk(int argc, char * const argv[],
  bootm_headers_t *images, ulong rd_addr, rd_load;
  
 ulong rd_data, rd_len;
 const image_header_t *rd_hdr;
  
  +  char *end;
  
   #if defined(CONFIG_FIT)
   
 void*fit_hdr;
 const char  *fit_uname_config = NULL;
  
  @@ -989,9 +990,17 @@ int boot_get_ramdisk(int argc, char * const argv[],
  bootm_headers_t *images, break;
  
   #endif
   
 default:
  -  puts(Wrong Ramdisk Image Format\n);
  -  rd_data = rd_len = rd_load = 0;
  -  return 1;
  +#ifdef CONFIG_SUPPORT_RAW_INITRD
  +  if (argc = 3  (end = strchr(argv[2], ':'))) {
  +  rd_len = simple_strtoul(++end, NULL, 16);
  +  rd_data = rd_addr;
  +  } else
  +#endif
  +  {
  +  puts(Wrong Ramdisk Image Format\n);
  +  rd_data = rd_len = rd_load = 0;
  +  return 1;
  +  }
  
 }
 
 } else if (images-legacy_hdr_valid 
 
 image_check_type(images-legacy_hdr_os_copy,
  
  Best regards,
  Marek Vasut

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

[U-Boot] Question: Installing U-Boot on the Karo TX25

2012-03-22 Thread Züger Martin

Hi everybody

My name is Martin and I'm new to this mailing list. I hope this is the right 
place to ask my question.
I'd like to install U-Boot on a Karo TX25. From the Denx FTP server I've 
downloaded the 2011.12 release of U-Boot and compiled it using the 
arm-linux-gnueabi-gcc (4.4.5) from Debian:
  $ make tx25_config
  $ CROSS_COMPILE=arm-linux-gnueabi- make all
After compiling I've downloaded the u-boot.bin file to the board using the 
pre-installed RedBoot:
  RedBoot load -r -b 0x8010 -h 192.168.1.101 u-boot.bin
  Using default protocol (TFTP)
  Raw file loaded 0x8010-0x80129617, assumed entry at 0x8010
Finally I tried to start U-Boot directly from RAM:
  RedBoot exec
  Using base address 0x8010 and length 0x00029618
After that, the board (or at least the serial connection) stops working. I also 
tried the same with the pre-compiled binaries from here: 
http://www.denx-cs.de/sites/all/files/tx25.zip but with the same result.

May someone can explain me, how to download U-Boot to the Karo TX25 using the 
already installed RedBoot and execute it directly? Is this even possible? My 
final target is to replace RedBoot with U-Boot, so I'd like to write U-Boot to 
flash in a second step. Does I've to use the u-boot-nand.bin file instead of 
u-boot.bin for this?

Thanks!

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

[U-Boot] AT91RM9200DK Support

2012-03-22 Thread Jordan Bouyat


Hi !
I have an AT91RM9200DK board and I want tu upgrade U-Boot (I have the  
0.3.2 version) on it.

But the AT91RM9200DK is no longer supported, could someone explain me why ?
The commit message is here :  
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=1c8575225825b507573d0cac9c51b3611949ba01

Is there any solution tu upgrade U-Boot ?

Thank you !

Jordan.



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

[U-Boot] exporting the U-Boot functions to standalone application

2012-03-22 Thread Haneef Mohamed

Hi,

I wanted to make use of the uboot command functions like do_bdinfo and do_mmc. 

when I used do_bdinfo(NULL, 0, 0,NULL);in application program after linking 
common/cmd_bdinfo.o in make file it worked.

but when I did the same for do_mmc i got a lot of linking errors.

So after looking arround in common/main.c what i did was i made use of  cmd 
=mmc rescan; run_command(cmd,0); 
but no output at all. 

I read the README.standalone but of no use could some one please let me know 
how should i go about it. 

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

Re: [U-Boot] AT91RM9200DK Support

2012-03-22 Thread Andreas Bießmann

Hi,

On 22.03.2012 12:44, Jordan Bouyat wrote:
 Hi !
 I have an AT91RM9200DK board and I want tu upgrade U-Boot (I have the
 0.3.2 version) on it.
 But the AT91RM9200DK is no longer supported, could someone explain me why ?
 The commit message is here :
 http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=1c8575225825b507573d0cac9c51b3611949ba01
 
 Is there any solution tu upgrade U-Boot ?

just do the migration job ...

The at91rm9200ek is still in tree (but currently not fully functional).
There are some issues with the older atmel emac driver is not working
with D-cache enabled (see
http://mid.gmane.org/1314768973-94711-1-git-send-email-andreas.de...@googlemail.com
). I haven't had time to investigate that issue further but will do
sometimes this year ;)
Beside that at91rm9200ek should work, this could be a good starting
point for you.

best regards

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

Re: [U-Boot] Question: Installing U-Boot on the Karo TX25

2012-03-22 Thread Stefano Babic

On 22/03/2012 09:08, Züger Martin wrote:
 Hi everybody
 
 My name is Martin and I'm new to this mailing list. I hope this is the right 
 place to ask my question.
 I'd like to install U-Boot on a Karo TX25. From the Denx FTP server I've 
 downloaded the 2011.12 release of U-Boot and compiled it using the 
 arm-linux-gnueabi-gcc (4.4.5) from Debian:
   $ make tx25_config
   $ CROSS_COMPILE=arm-linux-gnueabi- make all
 After compiling I've downloaded the u-boot.bin file to the board using the 
 pre-installed RedBoot:

Wait - as far as I know, the tx25 boots from NAND, and you need also the
SPL part to replace Redboot.

   RedBoot load -r -b 0x8010 -h 192.168.1.101 u-boot.bin
   Using default protocol (TFTP)
   Raw file loaded 0x8010-0x80129617, assumed entry at 0x8010
 Finally I tried to start U-Boot directly from RAM:

u-boot for TX25 is linked at address 0x8120, not 0x8010. Try
with the correct address.

 
 May someone can explain me, how to download U-Boot to the Karo TX25 using the 
 already installed RedBoot and execute it directly? Is this even possible? My 
 final target is to replace RedBoot with U-Boot, so I'd like to write U-Boot 
 to flash in a second step. Does I've to use the u-boot-nand.bin file instead 
 of u-boot.bin for this?

The correct way (but one-way if you have not a JTAG debugger) is to
replace the redboot code in NAND with u-boot, that is u-boot-nand.bin.
But try with the correct address, if it works you have all u-boot
commands to store u-boot itself in NAND.

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

2012-03-22 Thread Wolfgang Denk

Dear Simon Glass,

In message CAPnjgZ1u8paSeKxozWz1D5YoJaJ2um_q0dWQo=k5_+hedkh...@mail.gmail.com 
you wrote:
 
  OK, so revert that commit?
 
  It hasn't hit mainline yet, or has it?
 
 Yes, it is there, sorry.

Which commit is that?

  This is why initializing the serial console has always been one of the
  very, very first initialization steps in U-Boot.
 
 So if actually you want a pre-console panic() to be silent then that's fine.

I do not _want_ it.

This is a simple matter of facts that cannot be avoided.  If we cannot
initialize the consolem then we cannot print anything.

 It's a little unfriendly though - so would you be interested in
 keeping board_pre_console_putc() around if we could solve this
 entirely with code in there? It turns out that Tegra has a setting for
 console UART in the hardware parameters that we can access.( I won't
 ask you about how to handle a panic() in SPL yet).

If you can initialize the console in a way that allows sending
characters, then just do this - do this as part of the recular
fconsole init code, so we do have a working console, and we do not
need ay pre-console stuff.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It is common sense to take a method and try it. If it fails, admit it
frankly and try another. But above all, try something.
  - Franklin D. Roosevelt
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] BOOT: Add RAW ramdisk support to bootz

2012-03-22 Thread Wolfgang Denk

Dear Marek,

In message 201203221345.55217.marek.va...@gmail.com you wrote:
 
  Sub images will have an @ in the name. I thought about parsing for that,
  but DT has no requirement that you have to have an @ in the node name
  and it's not clear to me if u-boot convention requires it or not. Then I
  came up with the current patch, so it doesn't matter.
 
 Dear Wolfgang Denk, are we OK with applying this and bootz patch please? Can 
 we 
 get it into .04 release please?

this - which patch version exactly are you referring to?

In any case this has been submitted long after the close of the MW, so
this is stuff for next.

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
Today is the yesterday you worried about tomorrow.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] exporting the U-Boot functions to standalone application

2012-03-22 Thread Wolfgang Denk

Dear Haneef Mohamed,

In message 1332421701.4976.yahoomail...@web193301.mail.sg3.yahoo.com you 
wrote:
 
 I wanted to make use of the uboot command functions like do_bdinfo and 
 do_mmc. 

You cannot do this in standalone code.

If you want to access U-Boot features in access to the exported
(intentionally very narrow) interface, then link your code with
U-Boot.  Standalone applications cannot do that.

 I read the README.standalone but of no use could some one please let
 me know how should i go about it. 

Link your code with the U-Boot image.

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
Murder is contrary to the laws of man and God.
-- M-5 Computer, The Ultimate Computer, stardate 4731.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] cmd_fat: add FAT write command

2012-03-22 Thread Maximilian Schwerin

Once CONFIG_FAT_WRITE is defined, users can invoke 'fatwrite' command
that saves data in RAM as a FAT file.

This patch was originally part of

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/121847

Reported-by: Donggeun Kim dg77@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
---
 README   |8 +-
 common/cmd_fat.c |   57 ++
 2 files changed, 63 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 1f8bd20..fe077b9 100644
--- a/README
+++ b/README
@@ -1250,8 +1250,12 @@ The following options need to be configured:
 
 - FAT(File Allocation Table) filesystem write function support:
CONFIG_FAT_WRITE
-   Support for saving memory data as a file
-   in FAT formatted partition
+
+   Define this to enable support for saving memory data as a
+   file in FAT formatted partition.
+
+   This will also enable the command fatwrite enabling the
+   user to write files to FAT.
 
 - Keyboard Support:
CONFIG_ISA_KEYBOARD
diff --git a/common/cmd_fat.c b/common/cmd_fat.c
index 0220494..fef1c82 100644
--- a/common/cmd_fat.c
+++ b/common/cmd_fat.c
@@ -184,3 +184,60 @@ U_BOOT_CMD(
interface dev[:part]\n
- print information about filesystem from 'dev' on 'interface'
 );
+
+#ifdef CONFIG_FAT_WRITE
+static int do_fat_fswrite(cmd_tbl_t *cmdtp, int flag,
+   int argc, char * const argv[])
+{
+   long size;
+   unsigned long addr;
+   unsigned long count;
+   block_dev_desc_t *dev_desc = NULL;
+   int dev = 0;
+   int part = 1;
+   char *ep;
+
+   if (argc  5)
+   return cmd_usage(cmdtp);
+
+   dev = (int)simple_strtoul(argv[2], ep, 16);
+   dev_desc = get_dev(argv[1], dev);
+   if (dev_desc == NULL) {
+   puts(\n** Invalid boot device **\n);
+   return 1;
+   }
+   if (*ep) {
+   if (*ep != ':') {
+   puts(\n** Invalid boot device, use `dev[:part]' **\n);
+   return 1;
+   }
+   part = (int)simple_strtoul(++ep, NULL, 16);
+   }
+   if (fat_register_device(dev_desc, part) != 0) {
+   printf(\n** Unable to use %s %d:%d for fatwrite **\n,
+   argv[1], dev, part);
+   return 1;
+   }
+   addr = simple_strtoul(argv[3], NULL, 16);
+   count = simple_strtoul(argv[5], NULL, 16);
+
+   size = file_fat_write(argv[4], (void *)addr, count);
+   if (size == -1) {
+   printf(\n** Unable to write \%s\ from %s %d:%d **\n,
+   argv[4], argv[1], dev, part);
+   return 1;
+   }
+
+   printf(%ld bytes write\n, size);
+
+   return 0;
+}
+
+U_BOOT_CMD(
+   fatwrite,   6,  0,  do_fat_fswrite,
+   write file into a dos filesystem,
+   interface dev[:part] addr filename bytes\n
+   - write file 'filename' from the address 'addr' in RAM\n
+ to 'dev' on 'interface'
+);
+#endif
-- 
1.7.0.4

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

Re: [U-Boot] exporting the U-Boot functions to standalone application

2012-03-22 Thread Haneef Mohamed



Dear wolfgang Denk,

How do we link with u-boot? i did not understand.


Thanks and Regards,
Mohamed Haneef M.A


From: Wolfgang Denk w...@denx.de
To: Haneef Mohamed haneef_ker...@yahoo.in 
Cc: u-boot@lists.denx.de u-boot@lists.denx.de 
Sent: Thursday, 22 March 2012 7:06 PM
Subject: Re: [U-Boot] exporting the U-Boot functions to standalone application

Dear Haneef Mohamed,

In message 1332421701.4976.yahoomail...@web193301.mail.sg3.yahoo.com you 
wrote:
 
 I wanted to make use of the uboot command functions like do_bdinfo and 
 do_mmc. 

You cannot do this in standalone code.

If you want to access U-Boot features in access to the exported
(intentionally very narrow) interface, then link your code with
U-Boot.  Standalone applications cannot do that.

 I read the README.standalone but of no use could some one please let
 me know how should i go about it. 

Link your code with the U-Boot image.

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
Murder is contrary to the laws of man and God.
    -- M-5 Computer, The Ultimate Computer, stardate 4731.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] README.mx28: add

2012-03-22 Thread Wolfgang Denk

Dear Otavio Salvador,

please keep the ML on Cc:

In message cap9odkq+t+qapq+gmhfpy6b4vzyfwo0pje652t1s_+fctvd...@mail.gmail.com 
you wrote:
 
 On Wed, Mar 21, 2012 at 12:38, Wolfgang Denk w...@denx.de wrote:
  Can we please split this document in a generic and board specific
  part?  For now, while there are only very few boards, this can
  probably be done in a single document.
 
 I think it makes harder for user to gasp the need information if it is
 splitted on many files; a single file has the same problem as the
 naming can not imply the board or reference he is looking at. I had
 this problem and took me some time to find m28 as a base documentation
 to my work on mx28evk.

We are not talking about many files - just two files would be
relevant for a specific board: one with the common stuff, and one
with the board specific stuff.

Copying the same stuff again and again and again is definitely a much
bigger problem.


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
Those who do not  understand  Unix  are  condemned  to  reinvent  it,
poorly.  - Henry Spencer, University of Toronto Unix hack
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.

2012-03-22 Thread Simon Glass

Hi Wolfgang,

On Thu, Mar 22, 2012 at 6:25 AM, Wolfgang Denk w...@denx.de wrote:
Dear Simon Glass,

In message
CAPnjgZ1u8paSeKxozWz1D5YoJaJ2um_q0dWQo=k5_+hedkh...@mail.gmail.com you
wrote:

OK, so revert that commit?

It hasn't hit mainline yet, or has it?

Yes, it is there, sorry.

Which commit is that?

It was 295d3942: Add board_pre_console_putc to deal with early console output

The discussion threads are around here:

http://lists.denx.de/pipermail/u-boot/2011-August/099620.html

If you are looking for a revert :-)

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

This is why initializing the serial console has always been one of the
very, very first initialization steps in U-Boot.

So if actually you want a pre-console panic() to be silent then that's fine.

I do not _want_ it.

This is a simple matter of facts that cannot be avoided. If we cannot
initialize the consolem then we cannot print anything.

It's a little unfriendly though - so would you be interested in
keeping board_pre_console_putc() around if we could solve this
entirely with code in there? It turns out that Tegra has a setting for
console UART in the hardware parameters that we can access.( I won't
ask you about how to handle a panic() in SPL yet).

If you can initialize the console in a way that allows sending
characters, then just do this - do this as part of the recular
fconsole init code, so we do have a working console, and we do not
need ay pre-console stuff.

OK, let's leave it for now, I don't see a way of achieving this in the
case of an early panic.

Regards,
Simon

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It is common sense to take a method and try it. If it fails, admit it
frankly and try another. But above all, try something.
- Franklin D. Roosevelt
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

77 matches

Mail list logo