Re: [U-Boot] [PATCH v3 3/4] kirkwood: implement kw_sdram_size_adjust

[Holger Brunck]

On 09/07/2012 01:20 AM, Prafulla Wadaskar wrote:
> 
> 
>> -Original Message-
>> From: Prafulla Wadaskar
>> Sent: 20 July 2012 12:10
>> To: 'Holger Brunck'; u-boot@lists.denx.de
>> Cc: Gerlando Falauto; Valentin Longchamp; Marek Vasut
>> Subject: RE: [PATCH v3 3/4] kirkwood: implement kw_sdram_size_adjust
>>
>>
>>
>>> -Original Message-
>>> From: Holger Brunck [mailto:holger.bru...@keymile.com]
>>> Sent: 20 July 2012 18:04
>>> To: u-boot@lists.denx.de
>>> Cc: Gerlando Falauto; Holger Brunck; Prafulla Wadaskar; Valentin
>>> Longchamp; Marek Vasut
>>> Subject: [PATCH v3 3/4] kirkwood: implement kw_sdram_size_adjust
>>>
>>> From: Gerlando Falauto 
>>>
>>> Size of the SDRAM chips might differ between any two (otherwise
>>> identical) instances of the same board. So add a function which
>> reads
>>> out the current ram size and set them in the SDRAM size register of
>>> kirkwood.
>>>
>>> Signed-off-by: Gerlando Falauto 
>>> Signed-off-by: Holger Brunck 
>>> cc: Prafulla Wadaskar 
>>> cc: Valentin Longchamp 
>>> cc: Marek Vasut 
>>> ---
>>> chages for v3:
>>>   - rename dram_size_fixup to kw_sdramsize_adjust and move them to
>>> kirkwood/dram.c
>>>
>>> changes for v2:
>>>   - rebase to current u-boot-marvell.git master branch
>>>
>>>  arch/arm/cpu/arm926ejs/kirkwood/dram.c   |   11 +++
>>>  arch/arm/include/asm/arch-kirkwood/cpu.h |1 +
>>>  2 files changed, 12 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
>>> b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
>>> index 5e2f9d8..9f97964 100644
>>> --- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
>>> +++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
>>> @@ -97,6 +97,17 @@ u32 kw_sdram_bs(enum memory_bank bank)
>>> return result;
>>>  }
>>>
>>> +void kw_sdram_size_adjust(void)
>>
>> I think you must pass bank_id to this function so that one can tune
>> any/all of the four available DRAM banks.
> 
> Hi Hogler
> This has not yet closed hence not pulled this patch series.
> 
> Do you have any comments on this?
> 

updates concerning these change request were send long time ago. The references 
are:

http://lists.denx.de/pipermail/u-boot/2012-July/129116.html
http://lists.denx.de/pipermail/u-boot/2012-July/129117.html

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

Re: [U-Boot] gpt: GUID/UUID - GPT restoration - open questions

[Lukasz Majewski]

Hi Stephen,

> On 09/06/2012 08:14 AM, Lukasz Majewski wrote:
> > Hi Rob,
> > 
> >> The question I'm asking is why we need partition creation support
> >> in u-boot in the first place? 
> > 
> > Please consider following scenarios:
> > 
> > 1. eMMC content is exported to the user (via UMS USB Mass Storage).
> > Then user by chance or on purpose will corrupt MBR/GPT.
> > 
> > 2. misuse of "mmc" command - user by chance writes mmc erase 0.
> > 
> > To unbrick the device one would simply use "gpt/part restore"
> > command with already defined at ./include/config/{target}.h default
> > settings for partitions.
> > 
> >> Next you need filesystem creation too?
> > 
> > I can use UMS to export eMMC to host PC (with restored partitions)
> > and then use mkfs.* to create proper file system.
> 
> In that case, wouldn't you be exposing the entire eMMC device over
> UMS, and hence the user could just run fdisk/parted/... on the host,
> just like you're proposing they run mkfs on the host?

This would be one option for restoring GPT table.

However, I believe, that there also should be a separate gpt command to
do the trick and restore default GPT (with default partitions) only
from u-boot (with no UMS interaction).

Additionally it is far more user friendly, when one type "gpt default"
and default partitions are restored for a particular board (stored
at ./include/configs/{board}.h .

-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] MIPS: 1Mb U-Boot?

[Stefan Roese]

Hi David,

On 09/07/2012 12:31 AM, Downey, David (c) wrote:
> I'm David Downey, a software engineer at MIPS Technologies.
> 
> Currently, our Malta and SEAD-3 dev boards use YAMON, MIPS' in-house
> open source PROM monitor, as a boot loader.  We are looking to migrate
> YAMON's functionality to U-Boot.

Welcome. :)

> YAMON contains many features beyond the scope of a boot loader (e.g.
> bi-endianess, a EJTAG/GDB interface, a disassembler, etc.) that we
> would still like to make available to our customers.  As you might
> expect, these features result in a large image size.  (YAMON is 1 Mb,
> which is significantly larger than U-Boot's stated design max. of 256 Kb.)
> 
> Would there be any objection (legal or otherwise) to offering a "lean"
> (> 256 Kb) version of U-Boot for Malta/SEAD-3 through denx.de and a
> "deluxe" (~1 Mb) version of U-Boot (open source, of course) through
> developer.mips.com?  If there are objections, do you have any suggestions
> on how we can still offer these features to our customers while not
> breaking U-Boot's 256 Kb design rule?

AFAIK, there is no 256KiB design rule in U-Boot. At least none that is
strict. I maintain many U-Boot board ports. Some of them are even bigger
than 512KiB (enabling features like USB, UBI, UBIFS are quite "expensive").

And I don't see a problem with supporting your "deluxe" features in the
mainline U-Boot git repository at denx.de. As far as the code is in good
shape (see [1] and [2]). But you are of course entitled to host your own
git repository, if this is the way you prefer to handle it. Even though
such out-of-tree ports/features are a maintenance nightmare.

Best regards,
Stefan

[1] http://www.denx.de/wiki/U-Boot/CodingStyle
[2] http://www.denx.de/wiki/view/U-Boot/Patches

--
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: Change Tegra20 to Tegra in common code, prep for T30

[Stephen Warren]

On 09/06/2012 03:27 PM, Tom Warren wrote:
> Convert TEGRA20_ defines to either TEGRA_ or NV_PA_ where appropriate.
> Convert tegra20_ source file and function names to tegra_, also.
> 
> Upcoming Tegra30 port will use common code/defines/names where possible.
> 
> Signed-off-by: Tom Warren 

I think this is basically OK so,
Acked-by: Stephen Warren 

Just a few small comments/thoughts below...

> diff --git a/arch/arm/cpu/tegra20-common/board.c 
> b/arch/arm/cpu/tegra20-common/board.c

>  static int uart_configs[] = {
> -#if defined(CONFIG_TEGRA20_UARTA_UAA_UAB)
> +#if defined(CONFIG_TEGRA_UARTA_UAA_UAB)
>   FUNCMUX_UART1_UAA_UAB,
> -#elif defined(CONFIG_TEGRA20_UARTA_GPU)
> +#elif defined(CONFIG_TEGRA_UARTA_GPU)
>   FUNCMUX_UART1_GPU,
> -#elif defined(CONFIG_TEGRA20_UARTA_SDIO1)
> +#elif defined(CONFIG_TEGRA_UARTA_SDIO1)
>   FUNCMUX_UART1_SDIO1,
>  #else
>   FUNCMUX_UART1_IRRX_IRTX,

All those options probably are Tegra20-specific, because the set of
pin-/group-names isn't the same on Tegra20 and Tegra30, so the same
options won't be available. Still, this probably won't actually cause
any name collisions, so it's probably OK to rename these.

> diff --git a/arch/arm/include/asm/arch-tegra20/tegra20.h 
> b/arch/arm/include/asm/arch-tegra20/tegra20.h

>  #define NV_PA_GPIO_BASE  0x6000D000
>  #define NV_PA_EVP_BASE   0x6000F000
>  #define NV_PA_APB_MISC_BASE  0x7000
> -#define TEGRA20_APB_MISC_GP_BASE (NV_PA_APB_MISC_BASE + 0x0800)
> +#define NV_PA_APB_MISC_GP_BASE   (NV_PA_APB_MISC_BASE + 0x0800)
>  #define NV_PA_APB_UARTA_BASE (NV_PA_APB_MISC_BASE + 0x6000)
>  #define NV_PA_APB_UARTB_BASE (NV_PA_APB_MISC_BASE + 0x6040)
>  #define NV_PA_APB_UARTC_BASE (NV_PA_APB_MISC_BASE + 0x6200)
>  #define NV_PA_APB_UARTD_BASE (NV_PA_APB_MISC_BASE + 0x6300)
>  #define NV_PA_APB_UARTE_BASE (NV_PA_APB_MISC_BASE + 0x6400)
> -#define TEGRA20_NAND_BASE(NV_PA_APB_MISC_BASE + 0x8000)
> -#define TEGRA20_SPI_BASE (NV_PA_APB_MISC_BASE + 0xC380)
> -#define TEGRA20_PMC_BASE (NV_PA_APB_MISC_BASE + 0xE400)
> -#define TEGRA20_FUSE_BASE(NV_PA_APB_MISC_BASE + 0xF800)
> +#define NV_PA_NAND_BASE  (NV_PA_APB_MISC_BASE + 0x8000)
> +#define NV_PA_SPI_BASE   (NV_PA_APB_MISC_BASE + 0xC380)
> +#define NV_PA_PMC_BASE   (NV_PA_APB_MISC_BASE + 0xE400)
> +#define NV_PA_FUSE_BASE  (NV_PA_APB_MISC_BASE + 0xF800)
>  #define NV_PA_CSITE_BASE 0x7004
>  #define TEGRA_USB1_BASE  0xC500
>  #define TEGRA_USB3_BASE  0xC5008000
>  #define TEGRA_USB_ADDR_MASK  0xC000

Many of these values will be different between Tegra20 and Tegra30.
Hence, the values are all SoC-specific. I suppose you're planning on
having both tegra20.h and tegra30.h define the same set of names, just
with different values? I guess that's fine. It's plausible that
different SoCs might have a different number of instances of some
controllers. I suppose most of these defines should eventually be
replaced by device tree anyway though.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4] PXE: FDT: Add support for fdt in PXE

[Chander Kashyap]

Now DT support is becoming common for all new SoC's. Hence it is better
to have option for getting specific FDT from the remote server.

This patch adds support for new label i.e. 'fdt'. This will allow to
retrieve 'fdt blob' from the remote server. This patch take care for
the following scenarios.

The usage of fdt is optional.
The 'fdt blob' can be retrieved from tftp or can be available locally
or can be absent.

If 'fdt_addr_r' environment variable is set and 'fdt' label is defined
retrieve 'fdt blob' from tftp. 'fdt_addr_r' is then passed along bootm
command.

If 'fdt_addr' is set and 'fdt blob' is not retrieved from the tftp pass
'fdt_addr' to bootm command. In this case 'fdt blob' will be available
at 'fdt_addr'.

If 'fdt_addr' is not set and 'fdt blob' is not retrieve from tftp pass
NULL to boot command. In this case 'fdt blob' is not required and absent.

Signed-off-by: Chander Kashyap 
---
Changes in v2:
- Removed the duplicate code.
changes in v3:
- Added documentation for "fdt" lable in doc/README.pxe
changes in v4:
- Added New environment variable 'fdt_addr_r' for 'fdt blob'
- Add more descriptive documentation for the 'fdt' retrieval.

 common/cmd_pxe.c |   39 ---
 doc/README.pxe   |   14 --
 2 files changed, 48 insertions(+), 5 deletions(-)

diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
index 6b31dea..ee75db9 100644
--- a/common/cmd_pxe.c
+++ b/common/cmd_pxe.c
@@ -450,6 +450,7 @@ struct pxe_label {
char *kernel;
char *append;
char *initrd;
+   char *fdt;
int attempted;
int localboot;
struct list_head list;
@@ -517,6 +518,9 @@ static void label_destroy(struct pxe_label *label)
if (label->initrd)
free(label->initrd);
 
+   if (label->fdt)
+   free(label->fdt);
+
free(label);
 }
 
@@ -541,6 +545,9 @@ static void label_print(void *data)
 
if (label->initrd)
printf("\t\tinitrd: %s\n", label->initrd);
+
+   if (label->fdt)
+   printf("\tfdt: %s\n", label->fdt);
 }
 
 /*
@@ -628,10 +635,29 @@ static void label_boot(struct pxe_label *label)
bootm_argv[1] = getenv("kernel_addr_r");
 
/*
-* fdt usage is optional.  If there is an fdt_addr specified, we will
-* pass it along to bootm, and adjust argc appropriately.
+* fdt usage is optional:
+* It handles the following scenarios. All scenarios are exclusive
+*
+* Scenario 1: If fdt_addr_r specified and "fdt" label is defined in
+* pxe file, retrieve fdt blob from server. Pass fdt_addr_r to bootm,
+* and adjust argc appropriately.
+*
+* Scenario 2: If there is an fdt_addr specified, pass it along to
+* bootm, and adjust argc appropriately.
+*
+* Scenario 3: fdt blob is not available.
 */
-   bootm_argv[3] = getenv("fdt_addr");
+   bootm_argv[3] = getenv("fdt_addr_r");
+
+   /* if fdt label is defined then get fdt from server */
+   if (bootm_argv[3] && label->fdt) {
+   if (get_relfile_envaddr(label->fdt, "fdt_addr_r") < 0) {
+   printf("Skipping %s for failure retrieving fdt\n",
+   label->name);
+   return;
+   }
+   } else
+   bootm_argv[3] = getenv("fdt_addr");
 
if (bootm_argv[3])
bootm_argc = 4;
@@ -658,6 +684,7 @@ enum token_type {
T_DEFAULT,
T_PROMPT,
T_INCLUDE,
+   T_FDT,
T_INVALID
 };
 
@@ -685,6 +712,7 @@ static const struct token keywords[] = {
{"append", T_APPEND},
{"initrd", T_INITRD},
{"include", T_INCLUDE},
+   {"fdt", T_FDT},
{NULL, T_INVALID}
 };
 
@@ -1074,6 +1102,11 @@ static int parse_label(char **c, struct pxe_menu *cfg)
err = parse_sliteral(c, &label->initrd);
break;
 
+   case T_FDT:
+   if (!label->fdt)
+   err = parse_sliteral(c, &label->fdt);
+   break;
+
case T_LOCALBOOT:
err = parse_integer(c, &label->localboot);
break;
diff --git a/doc/README.pxe b/doc/README.pxe
index 2bbf53d..f00f280 100644
--- a/doc/README.pxe
+++ b/doc/README.pxe
@@ -93,8 +93,13 @@ pxe boot
  be passed to the bootm command to boot the kernel. These environment
  variables are required to be set.
 
- fdt_addr - the location of a fdt blob. If this is set, it will be passed
- to bootm when booting a kernel.
+ fdt_addr_r - location in RAM at which 'pxe boot' will store the fdt blob 
it
+ retrieves from tftp. The retrieval is possible if 'fdt' label is defined 
in
+ pxe file and 'fdt_addr_r' is set. If retrieval is possible, 'fdt_addr_r'
+ will be passed to bootm 

Re: [U-Boot] [PATCH 1/6] davinci: ea20: reorganisation LCD startup

[Bastian . Ruppert]

Hello Tom,


> Re: [U-Boot] [PATCH 1/6] davinci: ea20: reorganisation LCD startup
>
> On Wed, Aug 15, 2012 at 09:55:40AM -0700, Tom Rini wrote:
> > On Fri, Aug 10, 2012 at 09:26:41AM +0200, Bastian Ruppert wrote:
> >
> > > Signed-off-by: Bastian Ruppert 
> > > CC: Tom Rini 
> > > CC: Stefano Babic 
> >
> > For the series, I'm fine with the davinci side of the changes but want
> > Anatolij and Stefano to ack as well before I pull into u-boot-ti,
> > thanks!
>
> Still waiting for Anatolij (thanks Stefano!) before I take this, FYI.
>

with the version 3 for this patches, Anatolij seems to be pleased.

Thanks,

Bastian.

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

Re: [U-Boot] [PATCH v3] PXE: FDT: Add support for fdt in PXE

[Chander Kashyap]

Hi Jason

On 6 September 2012 21:07, Jason Hobbs  wrote:
> Chander,
>
> Comments inline.
>
> On Thu, Sep 06, 2012 at 01:40:04AM -0400, Chander Kashyap wrote:
>> Now DT support is becomming common for all new SoC's. Hence it is better to
>> have option for getting specific FDT from the remote server.
>>
>> This patch adds support for new lable i.e. fdt. If fdt_addr is specified
>> then load fdt blob from the remote server to fdt_address.
>
> If a fdt label is provided AND fdt_addr is specified, then load the blob
> from the remote server to fdt_addr. fdt_addr alone still works on its
> own if the fdt_blob has already been loaded some other way
>
Yes will add it.
>>
>> Signed-off-by: Chander Kashyap 
>> ---
>> Changes in v2:
>>   - Removed the duplicate code.
>> changes in v3:
>>   - Added documentation for "fdt" lable in doc/README.pxe
>
> s/lable/label - fix globally
Will fix it
>
>>
>>  common/cmd_pxe.c |   23 +++
>>  doc/README.pxe   |   10 --
>>  2 files changed, 31 insertions(+), 2 deletions(-)
>>
>> diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
>> index 6b31dea..0c81e08 100644
>> --- a/common/cmd_pxe.c
>> +++ b/common/cmd_pxe.c
>> @@ -450,6 +450,7 @@ struct pxe_label {
>>   char *kernel;
>>   char *append;
>>   char *initrd;
>> + char *fdt;
>>   int attempted;
>>   int localboot;
>>   struct list_head list;
>> @@ -517,6 +518,9 @@ static void label_destroy(struct pxe_label *label)
>>   if (label->initrd)
>>   free(label->initrd);
>>
>> + if (label->fdt)
>> + free(label->fdt);
>> +
>>   free(label);
>>  }
>>
>> @@ -541,6 +545,9 @@ static void label_print(void *data)
>>
>>   if (label->initrd)
>>   printf("\t\tinitrd: %s\n", label->initrd);
>> +
>> + if (label->fdt)
>> + printf("\tfdt: %s\n", label->fdt);
>>  }
>>
>>  /*
>> @@ -633,6 +640,15 @@ static void label_boot(struct pxe_label *label)
>>*/
>>   bootm_argv[3] = getenv("fdt_addr");
>>
>> + /* if fdt label is defined then get fdt from server */
>> + if (bootm_argv[3] && label->fdt) {
>> + if (get_relfile_envaddr(label->fdt, "fdt_addr") < 0) {
>> + printf("Skipping %s for failure retrieving fdt\n",
>> + label->name);
>> + return;
>> + }
>> + }
>> +
>>   if (bootm_argv[3])
>>   bootm_argc = 4;
>>
>> @@ -658,6 +674,7 @@ enum token_type {
>>   T_DEFAULT,
>>   T_PROMPT,
>>   T_INCLUDE,
>> + T_FDT,
>>   T_INVALID
>>  };
>>
>> @@ -685,6 +702,7 @@ static const struct token keywords[] = {
>>   {"append", T_APPEND},
>>   {"initrd", T_INITRD},
>>   {"include", T_INCLUDE},
>> + {"fdt", T_FDT},
>>   {NULL, T_INVALID}
>>  };
>>
>> @@ -1074,6 +1092,11 @@ static int parse_label(char **c, struct pxe_menu *cfg)
>>   err = parse_sliteral(c, &label->initrd);
>>   break;
>>
>> + case T_FDT:
>> + if (!label->fdt)
>> + err = parse_sliteral(c, &label->fdt);
>> + break;
>> +
>>   case T_LOCALBOOT:
>>   err = parse_integer(c, &label->localboot);
>>   break;
>> diff --git a/doc/README.pxe b/doc/README.pxe
>> index 2bbf53d..835ca5a 100644
>> --- a/doc/README.pxe
>> +++ b/doc/README.pxe
>> @@ -93,8 +93,9 @@ pxe boot
>>   be passed to the bootm command to boot the kernel. These environment
>>   variables are required to be set.
>>
>> - fdt_addr - the location of a fdt blob. If this is set, it will be 
>> passed
>> - to bootm when booting a kernel.
>> + fdt_addr - locations in RAM at which 'pxe boot' will store the fdt blob
>> + it retrieves from tftp, if "fdt" lable is defined in pxe file. If this 
>> is
>> + set, it will be passed to bootm when booting a kernel.
>
> Thinking about this some more, I don't think you can use fdt_addr as the
> place to store the blob. fdt_addr isn't garaunteed to be writeable RAM -
> it could be a read only non volatile memory like NOR flash.
>
> If you notice, all of the other tftp retrievals go to "_r" suffixed
> variables, which are garaunteed (by convention) to be in writeable RAM.
>
> You may need to take an approach where an addition fdt_addr_r variable
> is used to point at the location to store the fdt blob.
>
Sure, I will take care for this
> Your description also makes it less clear that if fdt_addr is set, it
> points to the blob, whether or not it was retrieved from tftp.
Will make it more clear

>
>>
>>  pxe file format
>>  ===
>> @@ -156,6 +157,11 @@ initrd - if this label is chosen, use 
>> tftp to retrieve the initrd
>> the initrd_addr_r environment variable, and that address
>> will be passed to bootm.
>>
>> +fdt- if this label is chosen, use tftp to re

[U-Boot] [PATCH] mpc85xx: make gpio_direction_output respect value

[Chris Packham]

From: Chris Packham 

Users of familiar with the Linux gpiolib API expect that value parameter
to gpio_direction_output reflects the initial state of the output pin.
gpio_direction_output was always driving the output low, now it drives
it high or low according to the value provided.

Signed-off-by: Chris Packham 
Cc: Kyle Moffett 
Cc: Andy Fleming 
Cc: Peter Tyser 
Cc: Kumar Gala 
---
 arch/powerpc/include/asm/mpc85xx_gpio.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/mpc85xx_gpio.h 
b/arch/powerpc/include/asm/mpc85xx_gpio.h
index 5a608a5..2aed514 100644
--- a/arch/powerpc/include/asm/mpc85xx_gpio.h
+++ b/arch/powerpc/include/asm/mpc85xx_gpio.h
@@ -98,7 +98,10 @@ static inline int gpio_direction_input(unsigned gpio)
 
 static inline int gpio_direction_output(unsigned gpio, int value)
 {
-   mpc85xx_gpio_set_low(1U << gpio);
+   if (value)
+   mpc85xx_gpio_set_high(1U << gpio);
+   else
+   mpc85xx_gpio_set_low(1U << gpio);
return 0;
 }
 
-- 
1.7.12.rc2.16.g034161a

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

Re: [U-Boot] [PATCH] mmc: Remove incorrect cmd->flags usage

[Marek Vasut]

Dear Marek Vasut,

> Dear Andy Fleming,
> 
> > There were a couple of drivers that were actually using the flags
> > field of the cmd structure, despite the fact that no one ever
> > *set* that field. When we removed the field, those drivers failed
> > to compile. Replaced the references with the correct usage of
> > resp_type.
> 
> I'll run duts tests on this on M28, stay tuned.

[...]

Ok, seems to work on M28.

Tested-by: Marek Vasut 

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 4/5] usb: ulpi: add indicator configuration function

[Marek Vasut]

Dear Lucas Stach,

> Hi Tom,
> 
> Am Mittwoch, den 05.09.2012, 09:25 -0700 schrieb Tom Warren:
> > Igor/Marek,
> > 
> > > -Original Message-
> > > From: Marek Vasut [mailto:ma...@denx.de]
> > > Sent: Wednesday, September 05, 2012 1:52 AM
> > > To: Igor Grinberg
> > > Cc: Lucas Stach; u-boot@lists.denx.de; Stephen Warren; Tom Warren
> > > Subject: Re: [PATCH v2 4/5] usb: ulpi: add indicator configuration
> > > function
> > > 
> > > Dear Igor Grinberg,
> > > 
> > > > Hi Lucas, Tom,
> > > > 
> > > > I'm sorry for the late reply.
> > > > I understand, that Tom has already applied this to tegra/next, but as
> > > > the changes/follow up patches are required, may be we can do this in
> > > > another fashion...
> > > > 
> > > > 1) Thanks for the patch and working on extending the generic
> > > > framework! 2) This patch has no dependencies on tegra specific
> > > > patches, so
> > > > 
> > > >I think, it should go through Marex usb tree, but doing this will
> > > >require the right merge order, so bisectability will not suffer.
> > > >So, Marek, Tom, you should decide which way is fine with you both.
> > 
> > I'm not sure how the USB and Tegra repos can coordinate on patches like
> > this, since I don't pull from/rebase against USB, and AFAIK Marek
> > doesn't reference Tegra when he updates his repo. I'm a sub-repo of ARM,
> > which is a sub-repo of TOT (u-boot/master). What I usually do (and have
> > always done) is to take the entire patchset that includes a Tegra
> > component (USB, mmc, SPI, etc.) and hope (pray?) that anyone merging my
> > changes upstream of me will be able to resolve the
> > conflicts/pre-existing patches. So far, I haven't heard from anyone
> > (Albert or Wolfgang) that's had a problem with that, perhaps because
> > it's pretty rare. AFAICT, there's no other procedure outlined in the
> > U-Boot wiki custodian's page.  If there's a better procedure I should be
> > following, let's get it documented and I'll be glad to hew to the line.
> > I'm still on the learning curve for git merging, rebasing, etc.
> 
> I thought about how we could merge all this without loosing our sanity.
> I've already wrote this a bit hidden in a reply to the multi controller
> thread: I think it's best to handle all USB related changes through the
> u-boot-usb tree, as all this stuff should really be under drivers/usb.

Let's extend this a bit. Since I'm really under heavy load now, why don't you 
prepare a patchset (that includes all the tegra goo, stuff that Tom will drop 
etc) that I can pick, submit it (and Cc me) and I'll just pick it all ? That 
way 
we'll have a proper ordering and nothing will be lost and all will be tested.

> This means: I'll split out the clock output related changes, so they can
> go in the Tegra tree. Everything touching USB goes into the u-boot-usb
> tree and I'll rebase my changes accordingly. This also means commit "dm:
> Tegra: Staticize local functions" should be removed from the Tegra tree
> and move over to the USB tree.

Drop the dm: from it along the way.

> This way we won't get any build breakages and there should be no merge
> conflicts. It also opens the possibility to move the Tegra USB
> implementation to the right location in the source tree a bit later in
> this cycle, without messing up the merge.
> 
> Thanks,
> Lucas

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 v4 1/2] Loop block device for sandbox

[Marek Vasut]

Dear Pavel Herrmann,

> This driver uses files as block devices, can be used for testing disk
> operations on sandbox.
> A new command "sata_loop" is introduced to load files in runtime.

WARNING: externs should be avoided in .c files
#141: FILE: drivers/block/sata_loopback.c:39:
+extern block_dev_desc_t sata_dev_desc[];

total: 0 errors, 1 warnings, 231 lines checked

NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX 
MULTISTATEMENT_MACRO_USE_DO_WHILE

> Signed-off-by: Pavel Herrmann 
> CC: Marek Vasut 
> CC: Mike Frysinger 
> ---
> Changes for v4:
>   checkpatch fixes
>   use NULLs instead of ""
>   extend sata_loop command
> 
> Changes for v3:
>   introduce sata_loop command
> 
> Changes for v2:
>   split sandbox config off into separate patch (2/2)
>   rename file to signify exported API
>   style fixes
>   show end of long filenames rather than beginning
>   check for lseek errors to indicate non-regular file
> 
>  drivers/block/Makefile|   1 +
>  drivers/block/sata_loopback.c | 212
> ++ include/configs/sandbox.h |
>   8 ++
>  3 files changed, 221 insertions(+)
>  create mode 100644 drivers/block/sata_loopback.c
> 
> diff --git a/drivers/block/Makefile b/drivers/block/Makefile
> index f1ebdcc..c95651a 100644
> --- a/drivers/block/Makefile
> +++ b/drivers/block/Makefile
> @@ -40,6 +40,7 @@ COBJS-$(CONFIG_SATA_SIL) += sata_sil.o
>  COBJS-$(CONFIG_IDE_SIL680) += sil680.o
>  COBJS-$(CONFIG_SCSI_SYM53C8XX) += sym53c8xx.o
>  COBJS-$(CONFIG_SYSTEMACE) += systemace.o
> +COBJS-${CONFIG_SATA_LOOP} += sata_loopback.o
> 
>  COBJS:= $(COBJS-y)
>  SRCS := $(COBJS:.o=.c)
> diff --git a/drivers/block/sata_loopback.c b/drivers/block/sata_loopback.c
> new file mode 100644
> index 000..600fbdc
> --- /dev/null
> +++ b/drivers/block/sata_loopback.c
> @@ -0,0 +1,212 @@
> +/*
> + * (C) Copyright 2012
> + * Pavel Herrmann 
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const char revision[] = "0.0";
> +static const char vendor[] = "SATA loopback";
> +
> +/* this will be auto-initialized to NULLs */
> +static char *filenames[CONFIG_SYS_SATA_MAX_DEVICE];
> +
> +extern block_dev_desc_t sata_dev_desc[];
> +
> +static inline int range_check(int dev)
> +{
> + return  (dev < 0) || (dev >= CONFIG_SYS_SATA_MAX_DEVICE);
> +}
> +
> +int init_sata(int dev)
> +{
> + block_dev_desc_t *pdev = &sata_dev_desc[dev];
> + int fd, old_fd;
> +
> + if (range_check(dev)) {
> + printf("File index %d is out of range.\n", dev);
> + return -EINVAL;
> + }
> +
> + if (filenames[dev])
> + fd = os_open(filenames[dev], OS_O_RDWR);
> + else
> + fd = -1;
> +
> + old_fd = (long) pdev->priv;
> + /* This is ugly, but saves allocation for 1 int. */
> + pdev->priv = (void *) (long) fd;
> +
> + if ((old_fd > 2) || (old_fd < 0))
> + os_close(old_fd);
> +
> + return 0;
> +}
> +
> +lbaint_t sata_read(int dev, lbaint_t start, lbaint_t blkcnt, void *buffer)
> +{
> + block_dev_desc_t *pdev = &sata_dev_desc[dev];
> + int fd = (long) pdev->priv;
> + lbaint_t start_byte = ATA_SECT_SIZE * start;
> + lbaint_t length_byte = ATA_SECT_SIZE * blkcnt;
> + lbaint_t retval;
> +
> + if (os_lseek(fd, start_byte, OS_SEEK_SET) != start_byte)
> + return -1;
> +
> + retval = os_read(fd, buffer, length_byte);
> +
> + return retval / ATA_SECT_SIZE;
> +}
> +
> +lbaint_t sata_write(int dev, lbaint_t start, lbaint_t blkcnt, void
> *buffer) +{
> + block_dev_desc_t *pdev = &sata_dev_desc[dev];
> + int fd = (long) pdev->priv;
> + lbaint_t start_byte = ATA_SECT_SIZE * start;
> + lbaint_t length_byte = ATA_SECT_SIZE * blkcnt;
> + lbaint_t retval;
> +
> + if (os_lseek(fd, start_byte, OS_SEEK_SET) != start_byte)
> + return -1;
> +
> + retval = os_write(fd, buffer, length_byte);
> +
> + return retval / ATA_SECT_SIZE;
> +}
> +
> +int scan_sata(int dev)
> +{
> + block_dev_desc_t *pdev = &sata_dev_desc[dev];
> + 

Re: [U-Boot] [PATCH] mmc: Remove incorrect cmd->flags usage

[Marek Vasut]

Dear Andy Fleming,

> There were a couple of drivers that were actually using the flags
> field of the cmd structure, despite the fact that no one ever
> *set* that field. When we removed the field, those drivers failed
> to compile. Replaced the references with the correct usage of
> resp_type.

I'll run duts tests on this on M28, stay tuned.

> Signed-off-by: Andy Fleming 
> ---
> I've gone and applied this to the mmc repository, as it's more
> correct than the current implementation. I don't anticipate any
> problems, but the pl180 and pxa folks should make sure their
> drivers still work.
> 
>  drivers/mmc/arm_pl180_mmci.c |2 +-
>  drivers/mmc/pxa_mmc_gen.c|8 +---
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
> index db2c7ab..af1380a 100644
> --- a/drivers/mmc/arm_pl180_mmci.c
> +++ b/drivers/mmc/arm_pl180_mmci.c
> @@ -52,7 +52,7 @@ static int wait_for_command_end(struct mmc *dev, struct
> mmc_cmd *cmd) debug("CMD%d time out\n", cmd->cmdidx);
>   return TIMEOUT;
>   } else if ((hoststatus & SDI_STA_CCRCFAIL) &&
> -(cmd->flags & MMC_RSP_CRC)) {
> +(cmd->resp_type & MMC_RSP_CRC)) {
>   printf("CMD%d CRC error\n", cmd->cmdidx);
>   return -EILSEQ;
>   }
> diff --git a/drivers/mmc/pxa_mmc_gen.c b/drivers/mmc/pxa_mmc_gen.c
> index 2c5bf17..b3ec441 100644
> --- a/drivers/mmc/pxa_mmc_gen.c
> +++ b/drivers/mmc/pxa_mmc_gen.c
> @@ -118,7 +118,7 @@ static int pxa_mmc_start_cmd(struct mmc *mmc, struct
> mmc_cmd *cmd, int ret;
> 
>   /* The card can send a "busy" response */
> - if (cmd->flags & MMC_RSP_BUSY)
> + if (cmd->resp_type & MMC_RSP_BUSY)
>   cmdat |= MMC_CMDAT_BUSY;
> 
>   /* Inform the controller about response type */
> @@ -181,9 +181,11 @@ static int pxa_mmc_cmd_done(struct mmc *mmc, struct
> mmc_cmd *cmd) /* The command response didn't arrive */
>   if (stat & MMC_STAT_TIME_OUT_RESPONSE)
>   return -ETIMEDOUT;
> - else if (stat & MMC_STAT_RES_CRC_ERROR && cmd->flags & MMC_RSP_CRC) {
> + else if (stat & MMC_STAT_RES_CRC_ERROR
> + && cmd->resp_type & MMC_RSP_CRC) {
>  #ifdef   PXAMMC_CRC_SKIP
> - if (cmd->flags & MMC_RSP_136 && cmd->response[0] & (1 << 31))
> + if (cmd->resp_type & MMC_RSP_136
> + && cmd->response[0] & (1 << 31))
>   printf("Ignoring CRC, this may be dangerous!\n");
>   else
>  #endif

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

[U-Boot] MIPS: 1Mb U-Boot?

[Downey, David (c)]

Hello U-Boot community,

I'm David Downey, a software engineer at MIPS Technologies.

Currently, our Malta and SEAD-3 dev boards use YAMON, MIPS' in-house open 
source PROM monitor, as a boot loader.  We are looking to migrate YAMON's 
functionality to U-Boot.

YAMON contains many features beyond the scope of a boot loader (e.g. 
bi-endianess, a EJTAG/GDB interface, a disassembler, etc.) that we would still 
like to make available to our customers.  As you might expect, these features 
result in a large image size.  (YAMON is 1 Mb, which is significantly larger 
than U-Boot's stated design max. of 256 Kb.)

Would there be any objection (legal or otherwise) to offering a "lean" (> 256 
Kb) version of U-Boot for Malta/SEAD-3 through denx.de and a "deluxe" (~1 Mb) 
version of U-Boot (open source, of course) through developer.mips.com?  If 
there are objections, do you have any suggestions on how we can still offer 
these features to our customers while not breaking U-Boot's 256 Kb design rule?

Thanks in advance!

Looking forward to working with you,
David
dav...@mips.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 3/4] kirkwood: implement kw_sdram_size_adjust

[Prafulla Wadaskar]

> -Original Message-
> From: Prafulla Wadaskar
> Sent: 20 July 2012 12:10
> To: 'Holger Brunck'; u-boot@lists.denx.de
> Cc: Gerlando Falauto; Valentin Longchamp; Marek Vasut
> Subject: RE: [PATCH v3 3/4] kirkwood: implement kw_sdram_size_adjust
> 
> 
> 
> > -Original Message-
> > From: Holger Brunck [mailto:holger.bru...@keymile.com]
> > Sent: 20 July 2012 18:04
> > To: u-boot@lists.denx.de
> > Cc: Gerlando Falauto; Holger Brunck; Prafulla Wadaskar; Valentin
> > Longchamp; Marek Vasut
> > Subject: [PATCH v3 3/4] kirkwood: implement kw_sdram_size_adjust
> >
> > From: Gerlando Falauto 
> >
> > Size of the SDRAM chips might differ between any two (otherwise
> > identical) instances of the same board. So add a function which
> reads
> > out the current ram size and set them in the SDRAM size register of
> > kirkwood.
> >
> > Signed-off-by: Gerlando Falauto 
> > Signed-off-by: Holger Brunck 
> > cc: Prafulla Wadaskar 
> > cc: Valentin Longchamp 
> > cc: Marek Vasut 
> > ---
> > chages for v3:
> >   - rename dram_size_fixup to kw_sdramsize_adjust and move them to
> > kirkwood/dram.c
> >
> > changes for v2:
> >   - rebase to current u-boot-marvell.git master branch
> >
> >  arch/arm/cpu/arm926ejs/kirkwood/dram.c   |   11 +++
> >  arch/arm/include/asm/arch-kirkwood/cpu.h |1 +
> >  2 files changed, 12 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> > b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> > index 5e2f9d8..9f97964 100644
> > --- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> > +++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> > @@ -97,6 +97,17 @@ u32 kw_sdram_bs(enum memory_bank bank)
> > return result;
> >  }
> >
> > +void kw_sdram_size_adjust(void)
> 
> I think you must pass bank_id to this function so that one can tune
> any/all of the four available DRAM banks.

Hi Hogler
This has not yet closed hence not pulled this patch series.

Do you have any comments on this?

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

Re: [U-Boot] [PATCH v4 2/3] ARM: add support for Network Space v2 Lite and Mini

[Prafulla Wadaskar]

> -Original Message-
> From: Simon Guinot [mailto:simon.gui...@sequanux.org]
> Sent: 06 September 2012 13:52
> To: Prafulla Wadaskar; Albert ARIBAUD
> Cc: u-boot@lists.denx.de; Simon Guinot
> Subject: [PATCH v4 2/3] ARM: add support for Network Space v2 Lite and
> Mini
> 
> This patch adds support for the LaCie boards Network Space v2 (Lite
> and
> Mini). This two boards are derived from the Network Space v2 and a lot
> of hardware caracteristics are shared.
> 
> - CPU: Marvell 88F6192 800Mhz
> - SDRAM memory: 128MB DDR2 200Mhz
> - 1 SATA port: internal
> - Gigabit ethernet: PHY Marvell 88E1318
> - Flash memory: SPI NOR 512KB (Macronix MX25L4005A)
> - i2c EEPROM: 512 bytes (24C04 type)
> - 2 USB2 ports (Lite only): host and host/device
> - 1 push button
> - 1 SATA LED (bi-color, blue and red)
> 
> Signed-off-by: Simon Guinot 
> ---
> Changes for v4:
>  - Include missing MACH_TYPE_ in configs/lacie_kw.h.
> 
> No changes for v3.
> 
> Changes for v2:
>  - Move mach-types update into a separate patch.
> 
>  board/LaCie/common/common.c   |   36 ++-
>  board/LaCie/common/common.h   |1 +
>  board/LaCie/netspace_v2/kwbimage-ns2l.cfg |  162
> +

Hi Simon,

You have added one more cfg file in this patch
Now you have three cfg files in this folder that just diff from each other for 
DRAM configuration.

Whereas you can delete two of them, use maximum dram setting in cfg file, and 
then in board specific file you can tune the configuration for required size.

You may look for this optimization.
FYI: pls see the captured log of diff

[prafulla@pe-dt061 u-boot-marvell.git (master)]$ diff 
board/LaCie/netspace_v2/kwbimage-ns2l.cfg board/LaCie/netspace_v2/kwbimage.cfg
44c44
< DATA 0xFFD01404 0x34143000# DDR Controller Control Low
---
> DATA 0xFFD01404 0x35143000# DDR Controller Control Low
72c72
< DATA 0xFFD01410 0x#  DDR Address Control
---
> DATA 0xFFD01410 0x000C#  DDR Address Control
74c74
< # bit3-2:   10, Cs0size=512Mb
---
> # bit3-2:   11, Cs0size=1Gb
133c133
< DATA 0xFFD01504 0x07F1# CS[0]n Size
---
> DATA 0xFFD01504 0x0FF1# CS[0]n Size
[prafulla@pe-dt061 u-boot-marvell.git (master)]$ diff 
board/LaCie/netspace_v2/kwbimage-ns2l.cfg board/LaCie/netspace_v2/kwbimage
kwbimage.cfg   kwbimage-is2.cfg   kwbimage-ns2l.cfg
[prafulla@pe-dt061 u-boot-marvell.git (master)]$ diff 
board/LaCie/netspace_v2/kwbimage-ns2l.cfg 
board/LaCie/netspace_v2/kwbimage-is2.cfg
44c44
< DATA 0xFFD01404 0x34143000# DDR Controller Control Low
---
> DATA 0xFFD01404 0x35143000# DDR Controller Control Low
72c72
< DATA 0xFFD01410 0x#  DDR Address Control
---
> DATA 0xFFD01410 0x0008#  DDR Address Control
[prafulla@pe-dt061 u-boot-marvell.git (master)]$ diff 
board/LaCie/netspace_v2/kwbimage-is2.cfg board/LaCie/netspace_v2/kwbimage.cfg
72c72
< DATA 0xFFD01410 0x0008#  DDR Address Control
---
> DATA 0xFFD01410 0x000C#  DDR Address Control
74c74
< # bit3-2:   10, Cs0size=512Mb
---
> # bit3-2:   11, Cs0size=1Gb
133c133
< DATA 0xFFD01504 0x07F1# CS[0]n Size
---
> DATA 0xFFD01504 0x0FF1# CS[0]n Size

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

Re: [U-Boot] [NEXT PATCH v1 2/7] NAND: added NAND type to nand_ids

[Scott Wood]

On 09/06/2012 03:04 AM, Stefano Babic wrote:
> Signed-off-by: Stefano Babic 
> ---
>  drivers/mtd/nand/nand_ids.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
> index 3953549..fe75686 100644
> --- a/drivers/mtd/nand/nand_ids.c
> +++ b/drivers/mtd/nand/nand_ids.c
> @@ -131,6 +131,8 @@ const struct nand_flash_dev nand_flash_ids[] = {
>   /* 128 Gigabit */
>   {"NAND 16GiB 1,8V 8-bit",   0x1A, 0, 16384, 0, LP_OPTIONS},
>   {"NAND 16GiB 3,3V 8-bit",   0x3A, 0, 16384, 0, LP_OPTIONS},
> + {"NAND 16GiB 3,3V 8-bit",   0x48, 4096, 16384, 0x10,
> + LP_OPTIONS},
>   {"NAND 16GiB 1,8V 16-bit",  0x2A, 0, 16384, 0, LP_OPTIONS16},
>   {"NAND 16GiB 3,3V 16-bit",  0x4A, 0, 16384, 0, LP_OPTIONS16},
>  
> 

Why does this NAND chip need things specified that are zeroes for other
chips?

-Scott


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

Re: [U-Boot] [PATCH 01/10] dm: arm: Remove support for lpc2292

[Marek Vasut]

Dear Tom Rini,

> On 09/05/2012 07:44 PM, Marek Vasut wrote:
> > Dear Tom Rini,
> > 
> >> On Sun, Sep 02, 2012 at 06:15:02PM +0200, Marek Vasut wrote:
> >>> Dear Wolfgang Denk,
> >>> 
>  Dear Albert,
>  
>  In message <1342882947-9174-1-git-send-email-ma...@denx.de> Marek
>  Vasut
> > 
> > wrote:
> > This stuff has been rotting in the tree for a year now. Remove it.
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Wolfgang Denk 
> > Cc: Albert Aribaud 
> > Cc: U-Boot DM 
>  
>  In case you are going to apply any of these patches, please do make
>  sure to drop the "dm: " string from all these subjects.
> >>> 
> >>> At least add some ID so I can mine these patches back when we finish
> >>> the project. If you drop them, I won't have any way to tell.
> >> 
> >> You shouldn't need any.  At the end of the project just do:
> >> $ git log --author=(regex|that|catches|everyone) --since=project-start
> > 
> > What about me generating gazilion of other patches?
> 
> Use your denx.de for work and your gmail or university email for the
> project?

I don't have university email ... but I'll figure it out somehow.

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

Re: [U-Boot] cuImage doesn't boot with u-boot 2009.11 version

[Scott Wood]

On 09/03/2012 01:08 PM, narayanasami vijayaraghavan wrote:
> Hello uboot experts,
> ( I am new to board level debugging. So, please excuse if I am asking any
> basic question).
> 
> Is cuImage format supported with u-boot-2009.11 version?
> 
> I am running linux 2.6.32 with powerpc P1020 (freescale) board.  The board
> has u-boot version 2009.11.
> When I build the uImage and device tree blob separately, it is booting from
> u-boot.
> But, if I build cuImage format, it doesn't boot, and stops at
> "Uncompressing Kernel Image ... OK":

Why are you using cuImage with P1020?  cuImage is for old boards with
old U-Boots that don't support device trees.

-Scott


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

Re: [U-Boot] [PATCH] kirkwood: fix mpp.h coding style

[Prafulla Wadaskar]

> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-
> boun...@lists.denx.de] On Behalf Of Luka Perkov
> Sent: 05 September 2012 11:08
> To: u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH] kirkwood: fix mpp.h coding style
> 
> 
> Signed-off-by: Luka Perkov 
> ---
> 
>  arch/arm/include/asm/arch-kirkwood/mpp.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/arch-kirkwood/mpp.h
> b/arch/arm/include/asm/arch-kirkwood/mpp.h
> index 8e50ee7..8ceea7b 100644
> --- a/arch/arm/include/asm/arch-kirkwood/mpp.h
> +++ b/arch/arm/include/asm/arch-kirkwood/mpp.h
> @@ -85,7 +85,7 @@
>  #define MPP7_SPI_SCn MPP(  7, 0x2, 0, 1, 1,   1,   1,   1)
>  #define MPP7_PTP_TRIG_GENMPP(  7, 0x3, 0, 1, 1,   1,   1,   1
> )
> 
> -#define MPP8_GPIOMPP(  8, 0x0, 1, 1, 1,1,  1,   1)
> +#define MPP8_GPIOMPP(  8, 0x0, 1, 1, 1,   1,   1,   1)
>  #define MPP8_TW_SDA  MPP(  8, 0x1, 1, 1, 1,   1,   1,   1)
>  #define MPP8_UART0_RTS   MPP(  8, 0x2, 0, 1, 1,   1,   1,   1
> )
>  #define MPP8_UART1_RTS   MPP(  8, 0x3, 0, 1, 1,   1,   1,   1
> )

Applied to u-boot-marvell.git master branch

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

Re: [U-Boot] [PATCH v4 0/3] Board support and feature for LaCie devices

[Prafulla Wadaskar]

> -Original Message-
> From: Simon Guinot [mailto:simon.gui...@sequanux.org]
> Sent: 06 September 2012 13:52
> To: Prafulla Wadaskar; Albert ARIBAUD
> Cc: u-boot@lists.denx.de; Simon Guinot
> Subject: [PATCH v4 0/3] Board support and feature for LaCie devices
> 
> Changes for v4:
>  - Drop patch "ARM: add netspace_mini_v2 to mach-types.h".
>  - Include missing MACH_TYPE_ in configs/lacie_kw.h.
> 
> Changes for v3:
>  - Rebased against u-boot-mv/master and u-boot-arm/master.
> 
> Changes for v2:
>  - Move board support and feature into a separate patch set.
>  - Move mach-types update into a separate patch.
> 
> Simon Guinot (3):
>   lacie_kw: add support for EFI partitions
>   ARM: add support for Network Space v2 Lite and Mini
>   ARM: add support for d2 Network v2
> 
>  board/LaCie/common/common.c   |   36 ++-
>  board/LaCie/common/common.h   |1 +
>  board/LaCie/netspace_v2/kwbimage-ns2l.cfg |  162
> +
>  board/LaCie/netspace_v2/netspace_v2.c |4 +
>  boards.cfg|3 +
>  include/configs/lacie_kw.h|   44 ++--
>  6 files changed, 241 insertions(+), 9 deletions(-)
>  create mode 100644 board/LaCie/netspace_v2/kwbimage-ns2l.cfg
> 

Applied this entire patch series to u-boot-marvell.git master branch

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

Re: [U-Boot] [PATCH V2 4/4] cmd_part: add partition-related command

[Tom Rini]

On 09/06/2012 11:46 AM, Stephen Warren wrote:
> On 09/06/2012 11:12 AM, Tom Rini wrote:
>> On Wed, Sep 05, 2012 at 08:38:26PM -0600, Stephen Warren wrote:
>>> On 09/05/2012 05:51 PM, Rob Herring wrote:
 On 09/05/2012 05:03 PM, Stephen Warren wrote:
> From: Stephen Warren 
>
> This implements the following:
>
> part uuid mmc 0:1
>   -> print partition UUID
> part uuid mmc 0:1 uuid
>   -> set environment variable to partition UUID

 What's the reason to not always both print out and set the uuid env var?

 Perhaps the env name should be partuuid or part_uuid as you could have
 uuid's for other purposes?
>>>
>>> The idea is that if you're running the command interactively, you won't
>>> pass a variable name on the command-line, so the command will print out
>>> the UUID for you to read. In this case, it's pointless to set any
>>> environment variable.
>>>
>>> However, if you're writing a script, you want to capture the UUID into
>>> an environment variable, and it's quite unlikely you want to litter
>>> stdout with that content too. Hence, either-or, not both.
>>
>> Do other commands have a "I'm being scripted, probably, don't stdout"
>> and "I'm being interactive, use stdout" distinction like this?  IMHO,
>> always printing out makes sense so you can "see" that your script is
>> working as you expect.
> 
> In general, as a script writer, yes you do have the ability to choose.
> Typically, I'd write:
> 
> part uuid 
> 
> vs.
> 
> var=`part uuid `
> 
> in order to control this. However, U-Boot's shell doesn't support
> backticks. As a script writer, I certainly desire the ability to control
> what commands spam to the console, and really don't think it's useful to
> print the UUID from a script (does the user really care, and any script
> developer can just echo it for debugging if they need it).
> 
> I'm not aware of other U-Boot commands whose purpose it is to set
> environment variables, so can't really compare.
> 
> Still, if you're insistent on this point, I can change the code to
> always print, and optionally write an environment variable.

No, you make a good point.  Thanks!

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

Re: [U-Boot] Specifying flash page sizes

[Scott Wood]

On 08/29/2012 03:48 AM, Ellis Andrew wrote:
> Hi
> 
> 
> I have been using uboot to with a number of devices

Using U-Boot to do what with a number of devices?

> which have a 256
> byte page. Currently I'm using a device with a 512 byte page. I have
> had problems getting Linux to run on my system, the initial problem
> was caused by the flash drivers in linux specifying a page of 256
> bytes and not 512. I am still having numerous issues with Linux, and
> I'm wondering whether it is because the kernel flash images are not
> being programmed correctly? Ho do I specify the flash page size in
> uboot source code? I've not been able to find how to do that.

What kind of flash are you talking about?  NOR? NAND? SPI?

I'm not too familiar with SPI flash, but NOR flash has much larger erase
blocks than that (and no pages for read/write), and 256-byte-page NAND
chips are listed as "museum" pieces in the code.

Or do you mean some sort of compact flash with integrated controller,
that looks like an IDE device?  Or something else?

What sort of boards are you using?  Is there any U-Boot question here,
or did you mean to post this to a Linux list?

There's just not enough information in this e-mail to give a helpful
response.

-Scott

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

Re: [U-Boot] [NEXT PATCH v1 5/7] SPL: Added MLO for mx35 SOC to SPL Makefile

[stefano babic]

Am 06/09/2012 22:48, schrieb Tom Rini:
> On 09/06/2012 12:59 PM, Stefano Babic wrote:
>> On 06/09/2012 19:49, Tom Rini wrote:
>>> On 09/06/2012 01:04 AM, Stefano Babic wrote:
 Signed-off-by: Stefano Babic 
 ---
  spl/Makefile |6 ++
  1 file changed, 6 insertions(+)

 diff --git a/spl/Makefile b/spl/Makefile
 index f96c08e..77fc405 100644
 --- a/spl/Makefile
 +++ b/spl/Makefile
 @@ -109,6 +109,12 @@ $(OBJTREE)/MLO:   $(obj)u-boot-spl.bin
-a $(CONFIG_SPL_TEXT_BASE) -d $< $@
  endif
  
 +ifneq ($(CONFIG_IMX_CONFIG),)
 +$(OBJTREE)/MLO:   $(obj)u-boot-spl.bin
 +  $(OBJTREE)/tools/mkimage -n  $(SRCTREE)/$(CONFIG_IMX_CONFIG) -T 
 imximage \
 +  -e $(CONFIG_SPL_TEXT_BASE) -d $< $@
 +endif
 +
  ALL-y += $(obj)u-boot-spl.bin
  
  ifdef CONFIG_SAMSUNG
>>>
>>> Is that really the name you want?  MLO comes from some part or another
>>> (I've read it, just can3't recall off-hand) of the IT ROM docs saying it
>>> will read a file named MLO.
>>
>> I know...
>>
>>>  Is mx35 in the same boat?
>>>  Or just looking
>>> for a common name?  
>>
>> Right. It makes no sense that the binary for Freescale's SOCs has a
>> name, for TI another one, for...we can generates less confusion if we
>> uses the same name.
> 
> Agreed.  I guess what I'm asking is, in the TI case the ROM reads FAT
> and must find 'MLO'.  Does mx35 do the same or

No. And not only the MX35, but also the MX5/MX6.

> is the post-build step
> "dd if=MLO of=/dev/... ..." and the filename doesn't matter?

Exactly. The ROM does not understand a filesystem, and the SPL must be
stored at a fixed address in the SD card. The filename does not matter,
and the SPL is not seen as file, but as a raw image.

>  I'm fine
> with the change now, just looking for the full details.  Thanks!

As for Freescale the filename does not matter while for TI does, we can
use for both MLO ;-)

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] Tegra: Change Tegra20 to Tegra in common code, prep for T30

[Tom Warren]

Convert TEGRA20_ defines to either TEGRA_ or NV_PA_ where appropriate.
Convert tegra20_ source file and function names to tegra_, also.

Upcoming Tegra30 port will use common code/defines/names where possible.

Signed-off-by: Tom Warren 
---
 arch/arm/cpu/arm720t/tegra20/cpu.c |8 ++--
 arch/arm/cpu/armv7/tegra20/cmd_enterrcm.c  |2 +-
 arch/arm/cpu/tegra20-common/Makefile   |2 +-
 arch/arm/cpu/tegra20-common/ap20.c |6 ++--
 arch/arm/cpu/tegra20-common/board.c|   14 
 arch/arm/cpu/tegra20-common/warmboot.c |   14 
 arch/arm/cpu/tegra20-common/warmboot_avp.c |2 +-
 arch/arm/include/asm/arch-tegra20/ap20.h   |3 --
 arch/arm/include/asm/arch-tegra20/mmc.h|8 ++--
 arch/arm/include/asm/arch-tegra20/sys_proto.h  |4 +-
 arch/arm/include/asm/arch-tegra20/tegra20.h|   14 
 .../arm/include/asm/arch-tegra20}/tegra_mmc.h  |   12 +++---
 arch/arm/include/asm/arch-tegra20/tegra_spi.h  |2 +-
 arch/arm/include/asm/arch-tegra20/timer.h  |4 +-
 board/avionic-design/common/tamonten.c |2 +-
 board/compal/paz00/paz00.c |4 +-
 board/compulab/trimslice/trimslice.c   |4 +-
 board/nvidia/common/board.c|8 ++--
 board/nvidia/harmony/harmony.c |4 +-
 board/nvidia/seaboard/seaboard.c   |4 +-
 board/nvidia/whistler/whistler.c   |4 +-
 drivers/gpio/tegra_gpio.c  |8 ++--
 drivers/i2c/tegra_i2c.c|   12 +++---
 drivers/input/Makefile |2 +-
 drivers/mmc/tegra_mmc.c|   34 ++--
 drivers/spi/tegra_spi.c|6 ++--
 include/configs/harmony.h  |   10 +++---
 include/configs/medcom.h   |6 ++--
 include/configs/paz00.h|6 ++--
 include/configs/plutux.h   |6 ++--
 include/configs/seaboard.h |   20 ++--
 include/configs/tec.h  |8 ++--
 .../{tegra20-common-post.h => tegra-common-post.h} |   12 +++---
 include/configs/tegra20-common.h   |   12 +++---
 include/configs/trimslice.h|8 ++--
 include/configs/ventana.h  |6 ++--
 include/configs/whistler.h |8 ++--
 37 files changed, 143 insertions(+), 146 deletions(-)
 rename {drivers/mmc => arch/arm/include/asm/arch-tegra20}/tegra_mmc.h (96%)
 rename include/configs/{tegra20-common-post.h => tegra-common-post.h} (96%)

diff --git a/arch/arm/cpu/arm720t/tegra20/cpu.c 
b/arch/arm/cpu/arm720t/tegra20/cpu.c
index 6d4d66b..ddf8d97 100644
--- a/arch/arm/cpu/arm720t/tegra20/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra20/cpu.c
@@ -105,14 +105,14 @@ static void enable_cpu_clock(int enable)
 
 static int is_cpu_powered(void)
 {
-   struct pmc_ctlr *pmc = (struct pmc_ctlr *)TEGRA20_PMC_BASE;
+   struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
 
return (readl(&pmc->pmc_pwrgate_status) & CPU_PWRED) ? 1 : 0;
 }
 
 static void remove_cpu_io_clamps(void)
 {
-   struct pmc_ctlr *pmc = (struct pmc_ctlr *)TEGRA20_PMC_BASE;
+   struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
u32 reg;
 
/* Remove the clamps on the CPU I/O signals */
@@ -126,7 +126,7 @@ static void remove_cpu_io_clamps(void)
 
 static void powerup_cpu(void)
 {
-   struct pmc_ctlr *pmc = (struct pmc_ctlr *)TEGRA20_PMC_BASE;
+   struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
u32 reg;
int timeout = IO_STABILIZATION_DELAY;
 
@@ -157,7 +157,7 @@ static void powerup_cpu(void)
 
 static void enable_cpu_power_rail(void)
 {
-   struct pmc_ctlr *pmc = (struct pmc_ctlr *)TEGRA20_PMC_BASE;
+   struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
u32 reg;
 
reg = readl(&pmc->pmc_cntrl);
diff --git a/arch/arm/cpu/armv7/tegra20/cmd_enterrcm.c 
b/arch/arm/cpu/armv7/tegra20/cmd_enterrcm.c
index 75cadb0..925f841 100644
--- a/arch/arm/cpu/armv7/tegra20/cmd_enterrcm.c
+++ b/arch/arm/cpu/armv7/tegra20/cmd_enterrcm.c
@@ -46,7 +46,7 @@
 static int do_enterrcm(cmd_tbl_t *cmdtp, int flag, int argc,
   char * const argv[])
 {
-   struct pmc_ctlr *pmc = (struct pmc_ctlr *)TEGRA20_PMC_BASE;
+   struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
 
puts("Entering RCM...\n");
udelay(5);
diff --git a/arch/arm/cpu/tegra20-common/Makefile 
b/arch/arm/cpu/tegra20-common/Makefile
index 43c96c6..9e91e5c 100644
--- a/arch/arm/cpu/tegra20-common/Makefile
+++ b/arch/arm/cpu/tegra20-common/Makefile
@@ -33,7 +33,7 @@ LIB   = $(obj)lib$(SOC)-common.o
 
 SOBJS += low

Re: [U-Boot] How to manage RMOBILE patches?

[Tom Rini]

On 09/06/2012 12:28 PM, Albert ARIBAUD wrote:
> Hi Nobuhiro,
> 
> On Thu, 6 Sep 2012 08:20:59 +0900, Nobuhiro Iwamatsu
>  wrote:
> 
>> Hi, Tom.
>>
>> On Wed, Sep 5, 2012 at 11:17 PM, Tom Rini  wrote:
>>> On 09/05/2012 04:18 AM, Albert ARIBAUD wrote:
 Hi Nobuhiro,

 On Wed, 5 Sep 2012 11:26:37 +0900, Nobuhiro Iwamatsu
  wrote:

> Hi,
>
> On Wed, Sep 5, 2012 at 2:36 AM, Tom Rini  wrote:
>> On Mon, Sep 03, 2012 at 09:15:56PM +0200, Wolfgang Denk wrote:
>>> Dear Nobuhiro Iwamatsu,
>>>
>>> In message
>>> 
>>> you wrote:

 I am working supporting  Renesas RMOBILE to U-Boot.
 Renesas's RMOBILE SoC family contains an ARM Cortex-A9, and
 this uses the same IP as SH.
 (For example, timer, ether, serial, etc.)
 I already sent to patches of rmobile, I got review from some
 developers. And the patch is managed by the arm/rmobile branch
 of u-boot-sh[0] which I have maintained, now.
 Since I had you take the patch of rmobile into an ARM
 repository, I consulted with Albert about the
 future development approach.

 We thought two methods are considered.
 One is Albert picks up a patch from ML to ARM repository,
>>>
>>> As this is ARM code, this appears the most natural approach to
>>> me
>>>
 Another is whether to have pull from the repository by having a
 repository for rmobile made.
>>>
>>> If this is an ARM SoC, then it should go through the ARM repo -
>>> even if we should later decide that there is so much traffic
>>> that a separate rmobile repo would be sustified, thi would
>>> still be a sub-repo, which Albert would pull from.
>>
>> Another option, which Mike is using for, iirc, sf and blackfin,
>> is just to add rmobile-master / rmobile-next as branches to the
>> u-boot-sh repository.
>
> Yes, this is one of easy way. But Albert won't  pull form
> u-boot-sh, if If my understanding is not wrong.

 This just means that they'll end up on u-boot/master from
 u-boot.sh (and from there into u-boot-arm later on).
>>>
>>> To be clear, what I'm saying is just add a few more branches to
>>> u-boot-sh that Albert will pull (since they're ARM stuff).  Say
>>> u-boot-sh/rmobile/master and u-boot-sh/rmobile/next.  Then not get
>>> too hung up on which repository a merge message comes from. :)
>>>
>>
>> I was going to do by how to explain you.
>> However, I think that Albert mistook by my shortage of explanation.
>> Thank you for following up.
>>
>> Nobuhiro
> 
> I understand that some ARM patches would be stored in some branch
> (say rmobile/master) of the u-boot-sh repo and pull-requested to me
> from there.
> 
> What I still don't understand is *why* this should be done. Before they
> get on this branch, the patches would still have to go through the
> mailing list for review, just like the ARM patches that end up applied
> to u-boot-arm/master, except they'd have to do through an intermediate
> branch. If there are benefits in this, someone will have to lay them
> out for me, because right now I don't see them.

I think the answer is, given how you wish to work, there's not.  It's a
workflow problem only.  If it's no easier for you to get a pull request
from Nobuhiro once the patches have been reviewed than for you to pull
them out of patchwork once they have been reviewed, then since your
preference is for patchwork, via patchwork and into u-boot-arm is how
they'll work.

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

[U-Boot] Please pull u-boot-mmc.git

[Andy Fleming]

  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://www.denx.de/git/u-boot-mmc.git master

for you to fetch changes up to 95b01c47ed97a7ca8b59308e35fb8c21e8d996a5:

  mmc: Remove incorrect cmd->flags usage (2012-09-06 15:23:13 -0500)


Andy Fleming (1):
  mmc: Remove incorrect cmd->flags usage

Benoît Thébaudeau (2):
  mmc_get_dev: Return error if mmc_init fails
  mmcinfo: Fix help message

Jaehoon Chung (3):
  mmc: s5p_sdhci: set the SDHCI_QUIRK_BROKEN_R1B
  mmc: s5p_sdhci: fixed wrong function argument
  mmc: s5p_sdhci: add the set_mmc_clk for cmu control

Joe Hershberger (2):
  mmc: Fix version check for clock API in sdhci driver
  mmc: Add a SDHCI quirk for boards that have no CD

Jongman Heo (1):
  mmc: fix wrong timeout check in mmc_send_status()

Mikhail Kshevetskiy (1):
  MMC: u-boot-spl may be compiled without partition support

Stephen Warren (3):
  mmc: detect boot sectors using EXT_CSD_BOOT_MULT too
  env_mmc: allow environment to be in an eMMC partition
  tegra: put eMMC environment into the boot sectors

Yoshihiro Shimoda (2):
  mmc: sh_mmcif: enable MMC_MODE_HC
  mmc: fix capacity calculation when EXT_CSD_SEC_CNT is used

 arch/arm/include/asm/arch-exynos/mmc.h  |4 +-
 arch/arm/include/asm/arch-s5pc1xx/mmc.h |4 +-
 common/cmd_mmc.c|3 +-
 common/env_mmc.c|   64 +++
 drivers/mmc/arm_pl180_mmci.c|2 +-
 drivers/mmc/mmc.c   |   20 +-
 drivers/mmc/pxa_mmc_gen.c   |8 ++--
 drivers/mmc/s5p_sdhci.c |   18 -
 drivers/mmc/sdhci.c |   30 +++
 drivers/mmc/sh_mmcif.c  |2 +-
 include/configs/paz00.h |3 +-
 include/configs/seaboard.h  |3 +-
 include/configs/trats.h |1 +
 include/configs/ventana.h   |3 +-
 include/configs/whistler.h  |3 +-
 include/mmc.h   |1 +
 include/sdhci.h |9 -
 17 files changed, 129 insertions(+), 49 deletions(-)

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

[U-Boot] [PATCH] mmc: Remove incorrect cmd->flags usage

[Andy Fleming]

There were a couple of drivers that were actually using the flags
field of the cmd structure, despite the fact that no one ever
*set* that field. When we removed the field, those drivers failed
to compile. Replaced the references with the correct usage of
resp_type.

Signed-off-by: Andy Fleming 
---
I've gone and applied this to the mmc repository, as it's more
correct than the current implementation. I don't anticipate any
problems, but the pl180 and pxa folks should make sure their
drivers still work.

 drivers/mmc/arm_pl180_mmci.c |2 +-
 drivers/mmc/pxa_mmc_gen.c|8 +---
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index db2c7ab..af1380a 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -52,7 +52,7 @@ static int wait_for_command_end(struct mmc *dev, struct 
mmc_cmd *cmd)
debug("CMD%d time out\n", cmd->cmdidx);
return TIMEOUT;
} else if ((hoststatus & SDI_STA_CCRCFAIL) &&
-  (cmd->flags & MMC_RSP_CRC)) {
+  (cmd->resp_type & MMC_RSP_CRC)) {
printf("CMD%d CRC error\n", cmd->cmdidx);
return -EILSEQ;
}
diff --git a/drivers/mmc/pxa_mmc_gen.c b/drivers/mmc/pxa_mmc_gen.c
index 2c5bf17..b3ec441 100644
--- a/drivers/mmc/pxa_mmc_gen.c
+++ b/drivers/mmc/pxa_mmc_gen.c
@@ -118,7 +118,7 @@ static int pxa_mmc_start_cmd(struct mmc *mmc, struct 
mmc_cmd *cmd,
int ret;
 
/* The card can send a "busy" response */
-   if (cmd->flags & MMC_RSP_BUSY)
+   if (cmd->resp_type & MMC_RSP_BUSY)
cmdat |= MMC_CMDAT_BUSY;
 
/* Inform the controller about response type */
@@ -181,9 +181,11 @@ static int pxa_mmc_cmd_done(struct mmc *mmc, struct 
mmc_cmd *cmd)
/* The command response didn't arrive */
if (stat & MMC_STAT_TIME_OUT_RESPONSE)
return -ETIMEDOUT;
-   else if (stat & MMC_STAT_RES_CRC_ERROR && cmd->flags & MMC_RSP_CRC) {
+   else if (stat & MMC_STAT_RES_CRC_ERROR
+   && cmd->resp_type & MMC_RSP_CRC) {
 #ifdef PXAMMC_CRC_SKIP
-   if (cmd->flags & MMC_RSP_136 && cmd->response[0] & (1 << 31))
+   if (cmd->resp_type & MMC_RSP_136
+   && cmd->response[0] & (1 << 31))
printf("Ignoring CRC, this may be dangerous!\n");
else
 #endif
-- 
1.7.9.7


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

[U-Boot] [PATCH v4 3/3] ARM: add support for d2 Network v2

[Simon Guinot]

This patch adds support for the LaCie board d2 Network v2 which share
a lot of hardware caracteristics with the 2Big Network v2.

- CPU: Marvell 88F6281 1200Mhz
- SDRAM memory: 256MB DDR2 400Mhz
- 2 SATA ports: internal and eSATA
- Gigabit ethernet: PHY Marvell 88E1116R
- Flash memory: SPI NOR 512KB (Macronix MX25L4005A)
- i2c EEPROM: 512 bytes (24C04 type)
- 2 USB2 ports: host and host/device
- 1 push button
- 1 power switch
- 1 SATA LED (bi-color, blue and red)

Signed-off-by: Simon Guinot 
---
No changes for v4.

Changes for v3:
 - Rebased against u-boot-mv/master and u-boot-arm/master.

No changes for v2.

 boards.cfg |1 +
 include/configs/lacie_kw.h |   10 --
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index e4613a9..2c7d351 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -160,6 +160,7 @@ kmnusa   arm arm926ejs   km_arm 
 keymile
 mgcoge3unarm arm926ejs   km_arm  
keymilekirkwoodkm_kirkwood:KM_MGCOGE3UN
 kmcoge5unarm arm926ejs   km_arm  
keymilekirkwoodkm_kirkwood:KM_COGE5UN
 portl2   arm arm926ejs   km_arm  
keymilekirkwoodkm_kirkwood:KM_PORTL2
+d2net_v2 arm arm926ejs   net2big_v2  LaCie 
 kirkwoodlacie_kw:D2NET_V2
 inetspace_v2 arm arm926ejs   netspace_v2 LaCie 
 kirkwood   lacie_kw:INETSPACE_V2
 net2big_v2   arm arm926ejs   net2big_v2  LaCie 
 kirkwood   lacie_kw:NET2BIG_V2
 netspace_lite_v2 arm arm926ejs   netspace_v2 LaCie 
 kirkwood   lacie_kw:NETSPACE_LITE_V2
diff --git a/include/configs/lacie_kw.h b/include/configs/lacie_kw.h
index 878d2a3..09b5798 100644
--- a/include/configs/lacie_kw.h
+++ b/include/configs/lacie_kw.h
@@ -38,6 +38,9 @@
 #elif defined(CONFIG_NETSPACE_MAX_V2)
 #define CONFIG_MACH_TYPE   MACH_TYPE_NETSPACE_MAX_V2
 #define CONFIG_IDENT_STRING" NS Max v2"
+#elif defined(CONFIG_D2NET_V2)
+#define CONFIG_MACH_TYPE   MACH_TYPE_D2NET_V2
+#define CONFIG_IDENT_STRING" D2 v2"
 #elif defined(CONFIG_NET2BIG_V2)
 #define CONFIG_MACH_TYPE   MACH_TYPE_NET2BIG_V2
 #define CONFIG_IDENT_STRING" 2Big v2"
@@ -108,7 +111,9 @@
 #define CONFIG_ENV_SPI_MAX_HZ   2000 /* 20Mhz */
 #define CONFIG_SYS_IDE_MAXBUS   1
 #define CONFIG_SYS_IDE_MAXDEVICE1
-#if defined(CONFIG_NET2BIG_V2)
+#if defined(CONFIG_D2NET_V2)
+#define CONFIG_SYS_PROMPT  "d2v2> "
+#elif defined(CONFIG_NET2BIG_V2)
 #define CONFIG_SYS_PROMPT  "2big2> "
 #else
 #define CONFIG_SYS_PROMPT  "ns2> "
@@ -128,7 +133,8 @@
  */
 #ifdef CONFIG_MVSATA_IDE
 #define CONFIG_SYS_ATA_IDE0_OFFSET  MV_SATA_PORT0_OFFSET
-#if defined(CONFIG_NETSPACE_MAX_V2) || defined(CONFIG_NET2BIG_V2)
+#if defined(CONFIG_NETSPACE_MAX_V2) || defined(CONFIG_D2NET_V2) || \
+   defined(CONFIG_NET2BIG_V2)
 #define CONFIG_SYS_ATA_IDE1_OFFSET  MV_SATA_PORT1_OFFSET
 #endif
 #endif /* CONFIG_MVSATA_IDE */
-- 
1.7.10

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

[U-Boot] [PATCH v4 2/3] ARM: add support for Network Space v2 Lite and Mini

[Simon Guinot]

This patch adds support for the LaCie boards Network Space v2 (Lite and
Mini). This two boards are derived from the Network Space v2 and a lot
of hardware caracteristics are shared.

- CPU: Marvell 88F6192 800Mhz
- SDRAM memory: 128MB DDR2 200Mhz
- 1 SATA port: internal
- Gigabit ethernet: PHY Marvell 88E1318
- Flash memory: SPI NOR 512KB (Macronix MX25L4005A)
- i2c EEPROM: 512 bytes (24C04 type)
- 2 USB2 ports (Lite only): host and host/device
- 1 push button
- 1 SATA LED (bi-color, blue and red)

Signed-off-by: Simon Guinot 
---
Changes for v4:
 - Include missing MACH_TYPE_ in configs/lacie_kw.h.

No changes for v3.

Changes for v2:
 - Move mach-types update into a separate patch.

 board/LaCie/common/common.c   |   36 ++-
 board/LaCie/common/common.h   |1 +
 board/LaCie/netspace_v2/kwbimage-ns2l.cfg |  162 +
 board/LaCie/netspace_v2/netspace_v2.c |4 +
 boards.cfg|2 +
 include/configs/lacie_kw.h|   28 -
 6 files changed, 226 insertions(+), 7 deletions(-)
 create mode 100644 board/LaCie/netspace_v2/kwbimage-ns2l.cfg

diff --git a/board/LaCie/common/common.c b/board/LaCie/common/common.c
index 78d0edc..a62bf9f 100644
--- a/board/LaCie/common/common.c
+++ b/board/LaCie/common/common.c
@@ -13,10 +13,11 @@
 
 #if defined(CONFIG_CMD_NET) && defined(CONFIG_RESET_PHY_R)
 
+#define MII_MARVELL_PHY_PAGE   22
+
 #define MV88E1116_LED_FCTRL_REG10
 #define MV88E1116_CPRSP_CR3_REG21
 #define MV88E1116_MAC_CTRL_REG 21
-#define MV88E1116_PGADR_REG22
 #define MV88E1116_RGMII_TXTM_CTRL  (1 << 4)
 #define MV88E1116_RGMII_RXTM_CTRL  (1 << 5)
 
@@ -31,15 +32,44 @@ void mv_phy_88e1116_init(const char *name, u16 phyaddr)
 * Enable RGMII delay on Tx and Rx for CPU port
 * Ref: sec 4.7.2 of chip datasheet
 */
-   miiphy_write(name, phyaddr, MV88E1116_PGADR_REG, 2);
+   miiphy_write(name, phyaddr, MII_MARVELL_PHY_PAGE, 2);
miiphy_read(name, phyaddr, MV88E1116_MAC_CTRL_REG, ®);
reg |= (MV88E1116_RGMII_RXTM_CTRL | MV88E1116_RGMII_TXTM_CTRL);
miiphy_write(name, phyaddr, MV88E1116_MAC_CTRL_REG, reg);
-   miiphy_write(name, phyaddr, MV88E1116_PGADR_REG, 0);
+   miiphy_write(name, phyaddr, MII_MARVELL_PHY_PAGE, 0);
 
if (miiphy_reset(name, phyaddr) == 0)
printf("88E1116 Initialized on %s\n", name);
 }
+
+void mv_phy_88e1318_init(const char *name, u16 phyaddr)
+{
+   u16 reg;
+
+   if (miiphy_set_current_dev(name))
+   return;
+
+   /*
+* Set control mode 4 for LED[0].
+*/
+   miiphy_write(name, phyaddr, MII_MARVELL_PHY_PAGE, 3);
+   miiphy_read(name, phyaddr, 16, ®);
+   reg |= 0xf;
+   miiphy_write(name, phyaddr, 16, reg);
+
+   /*
+* Enable RGMII delay on Tx and Rx for CPU port
+* Ref: sec 4.7.2 of chip datasheet
+*/
+   miiphy_write(name, phyaddr, MII_MARVELL_PHY_PAGE, 2);
+   miiphy_read(name, phyaddr, MV88E1116_MAC_CTRL_REG, ®);
+   reg |= (MV88E1116_RGMII_TXTM_CTRL | MV88E1116_RGMII_RXTM_CTRL);
+   miiphy_write(name, phyaddr, MV88E1116_MAC_CTRL_REG, reg);
+   miiphy_write(name, phyaddr, MII_MARVELL_PHY_PAGE, 0);
+
+   if (miiphy_reset(name, phyaddr) == 0)
+   printf("88E1318 Initialized on %s\n", name);
+}
 #endif /* CONFIG_CMD_NET && CONFIG_RESET_PHY_R */
 
 #if defined(CONFIG_CMD_I2C) && defined(CONFIG_SYS_I2C_EEPROM_ADDR)
diff --git a/board/LaCie/common/common.h b/board/LaCie/common/common.h
index 2edd5ab..85e433c 100644
--- a/board/LaCie/common/common.h
+++ b/board/LaCie/common/common.h
@@ -12,6 +12,7 @@
 
 #if defined(CONFIG_CMD_NET) && defined(CONFIG_RESET_PHY_R)
 void mv_phy_88e1116_init(const char *name, u16 phyaddr);
+void mv_phy_88e1318_init(const char *name, u16 phyaddr);
 #endif
 #if defined(CONFIG_CMD_I2C) && defined(CONFIG_SYS_I2C_EEPROM_ADDR)
 int lacie_read_mac_address(uchar *mac);
diff --git a/board/LaCie/netspace_v2/kwbimage-ns2l.cfg 
b/board/LaCie/netspace_v2/kwbimage-ns2l.cfg
new file mode 100644
index 000..d008eb0
--- /dev/null
+++ b/board/LaCie/netspace_v2/kwbimage-ns2l.cfg
@@ -0,0 +1,162 @@
+#
+# Copyright (C) 2011 Simon Guinot 
+#
+# Based on Kirkwood support:
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Prafulla Wadaskar 
+#
+# 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.

[U-Boot] [PATCH v4 1/3] lacie_kw: add support for EFI partitions

[Simon Guinot]

Defines CONFIG_EFI_PARTITION for LaCie boards.

Additionally this patch defines CONFIG_DOS_PARTITION. Note that this
definition is implicit in mv_common.h when CONFIG_CMD_USB is enabled.

Signed-off-by: Simon Guinot 
---
No changes for v2, v3 and v4.

 include/configs/lacie_kw.h |6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/configs/lacie_kw.h b/include/configs/lacie_kw.h
index c35c2db..08aec04 100644
--- a/include/configs/lacie_kw.h
+++ b/include/configs/lacie_kw.h
@@ -130,6 +130,12 @@
 #endif /* CONFIG_CMD_I2C */
 
 /*
+ * Partition support
+ */
+#define CONFIG_DOS_PARTITION
+#define CONFIG_EFI_PARTITION
+
+/*
  * File systems support
  */
 #define CONFIG_CMD_EXT2
-- 
1.7.10

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

[U-Boot] [PATCH v4 0/3] Board support and feature for LaCie devices

[Simon Guinot]

Changes for v4:
 - Drop patch "ARM: add netspace_mini_v2 to mach-types.h".
 - Include missing MACH_TYPE_ in configs/lacie_kw.h.

Changes for v3:
 - Rebased against u-boot-mv/master and u-boot-arm/master.

Changes for v2:
 - Move board support and feature into a separate patch set.
 - Move mach-types update into a separate patch.

Simon Guinot (3):
  lacie_kw: add support for EFI partitions
  ARM: add support for Network Space v2 Lite and Mini
  ARM: add support for d2 Network v2

 board/LaCie/common/common.c   |   36 ++-
 board/LaCie/common/common.h   |1 +
 board/LaCie/netspace_v2/kwbimage-ns2l.cfg |  162 +
 board/LaCie/netspace_v2/netspace_v2.c |4 +
 boards.cfg|3 +
 include/configs/lacie_kw.h|   44 ++--
 6 files changed, 241 insertions(+), 9 deletions(-)
 create mode 100644 board/LaCie/netspace_v2/kwbimage-ns2l.cfg

-- 
1.7.10

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

Re: [U-Boot] [PATCH 5/5] fix for MMC write issue

[Andy Fleming]

Please copy me on MMC patches.

On Mon, Aug 13, 2012 at 3:13 AM, Srikanth Reddy Vintha
 wrote:
> From: Shrinivas Sahukar 
>
> Signed-off-by: Shrinivas Sahukar 
> ---
>  drivers/mmc/qc_mmc.c |   71 +++--


This driver isn't in the tree, so NAK

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

Re: [U-Boot] [NEXT PATCH v1 5/7] SPL: Added MLO for mx35 SOC to SPL Makefile

[Tom Rini]

On 09/06/2012 12:59 PM, Stefano Babic wrote:
> On 06/09/2012 19:49, Tom Rini wrote:
>> On 09/06/2012 01:04 AM, Stefano Babic wrote:
>>> Signed-off-by: Stefano Babic 
>>> ---
>>>  spl/Makefile |6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/spl/Makefile b/spl/Makefile
>>> index f96c08e..77fc405 100644
>>> --- a/spl/Makefile
>>> +++ b/spl/Makefile
>>> @@ -109,6 +109,12 @@ $(OBJTREE)/MLO:$(obj)u-boot-spl.bin
>>> -a $(CONFIG_SPL_TEXT_BASE) -d $< $@
>>>  endif
>>>  
>>> +ifneq ($(CONFIG_IMX_CONFIG),)
>>> +$(OBJTREE)/MLO:$(obj)u-boot-spl.bin
>>> +   $(OBJTREE)/tools/mkimage -n  $(SRCTREE)/$(CONFIG_IMX_CONFIG) -T 
>>> imximage \
>>> +   -e $(CONFIG_SPL_TEXT_BASE) -d $< $@
>>> +endif
>>> +
>>>  ALL-y  += $(obj)u-boot-spl.bin
>>>  
>>>  ifdef CONFIG_SAMSUNG
>>
>> Is that really the name you want?  MLO comes from some part or another
>> (I've read it, just can't recall off-hand) of the IT ROM docs saying it
>> will read a file named MLO.
> 
> I know...
> 
>>  Is mx35 in the same boat?
>>  Or just looking
>> for a common name?  
> 
> Right. It makes no sense that the binary for Freescale's SOCs has a
> name, for TI another one, for...we can generates less confusion if we
> uses the same name.

Agreed.  I guess what I'm asking is, in the TI case the ROM reads FAT
and must find 'MLO'.  Does mx35 do the same or is the post-build step
"dd if=MLO of=/dev/... ..." and the filename doesn't matter?  I'm fine
with the change now, just looking for the full details.  Thanks!

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

Re: [U-Boot] msm7630 mainline request

[Andy Fleming]

On Mon, May 28, 2012 at 6:28 AM, Srikanth Reddy
 wrote:
>
> Hi,
>
> The patch for msm7630 was released to the u-boot community on 16-Feb-2-2012 
> can this be mainlined in v2012.07 release.The Patches contain the following 
> support
> * low speed uart for msm7630
> * inter processor communication
> * qc_mmc microcontroller

I see that you've got patches that modify the qc_mmc code. It sounded
familiar, so I looked it up. Looks like I marked the patch as
"deferred". My recollection is that this is because I sent a large
review of the patch, and the response was that two things were fixed,
and then a large patch. I had a number of questions which were
unanswered, plus the new patch did nothing to clarify any of my
questions. And some of the issues I mentioned were silently ignored.

Also, it sets "flags" which has just been removed.

Please re-base the qc_mmc patch against top of tree (u-boot-mmc)


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

Re: [U-Boot] [NEXT PATCH v1 5/7] SPL: Added MLO for mx35 SOC to SPL Makefile

[Stefano Babic]

On 06/09/2012 19:49, Tom Rini wrote:
> On 09/06/2012 01:04 AM, Stefano Babic wrote:
>> Signed-off-by: Stefano Babic 
>> ---
>>  spl/Makefile |6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/spl/Makefile b/spl/Makefile
>> index f96c08e..77fc405 100644
>> --- a/spl/Makefile
>> +++ b/spl/Makefile
>> @@ -109,6 +109,12 @@ $(OBJTREE)/MLO: $(obj)u-boot-spl.bin
>>  -a $(CONFIG_SPL_TEXT_BASE) -d $< $@
>>  endif
>>  
>> +ifneq ($(CONFIG_IMX_CONFIG),)
>> +$(OBJTREE)/MLO: $(obj)u-boot-spl.bin
>> +$(OBJTREE)/tools/mkimage -n  $(SRCTREE)/$(CONFIG_IMX_CONFIG) -T 
>> imximage \
>> +-e $(CONFIG_SPL_TEXT_BASE) -d $< $@
>> +endif
>> +
>>  ALL-y   += $(obj)u-boot-spl.bin
>>  
>>  ifdef CONFIG_SAMSUNG
> 
> Is that really the name you want?  MLO comes from some part or another
> (I've read it, just can't recall off-hand) of the IT ROM docs saying it
> will read a file named MLO.

I know...

>  Is mx35 in the same boat?
>  Or just looking
> for a common name?  

Right. It makes no sense that the binary for Freescale's SOCs has a
name, for TI another one, for...we can generates less confusion if we
uses the same name.

Stefano

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

Re: [U-Boot] How to manage RMOBILE patches?

[Albert ARIBAUD]

Hi Nobuhiro,

On Thu, 6 Sep 2012 08:20:59 +0900, Nobuhiro Iwamatsu
 wrote:

> Hi, Tom.
> 
> On Wed, Sep 5, 2012 at 11:17 PM, Tom Rini  wrote:
> > On 09/05/2012 04:18 AM, Albert ARIBAUD wrote:
> >> Hi Nobuhiro,
> >>
> >> On Wed, 5 Sep 2012 11:26:37 +0900, Nobuhiro Iwamatsu
> >>  wrote:
> >>
> >>> Hi,
> >>>
> >>> On Wed, Sep 5, 2012 at 2:36 AM, Tom Rini  wrote:
>  On Mon, Sep 03, 2012 at 09:15:56PM +0200, Wolfgang Denk wrote:
> > Dear Nobuhiro Iwamatsu,
> >
> > In message
> > 
> > you wrote:
> >>
> >> I am working supporting  Renesas RMOBILE to U-Boot.
> >> Renesas's RMOBILE SoC family contains an ARM Cortex-A9, and
> >> this uses the same IP as SH.
> >> (For example, timer, ether, serial, etc.)
> >> I already sent to patches of rmobile, I got review from some
> >> developers. And the patch is managed by the arm/rmobile branch
> >> of u-boot-sh[0] which I have maintained, now.
> >> Since I had you take the patch of rmobile into an ARM
> >> repository, I consulted with Albert about the
> >> future development approach.
> >>
> >> We thought two methods are considered.
> >> One is Albert picks up a patch from ML to ARM repository,
> >
> > As this is ARM code, this appears the most natural approach to
> > me
> >
> >> Another is whether to have pull from the repository by having a
> >> repository for rmobile made.
> >
> > If this is an ARM SoC, then it should go through the ARM repo -
> > even if we should later decide that there is so much traffic
> > that a separate rmobile repo would be sustified, thi would
> > still be a sub-repo, which Albert would pull from.
> 
>  Another option, which Mike is using for, iirc, sf and blackfin,
>  is just to add rmobile-master / rmobile-next as branches to the
>  u-boot-sh repository.
> >>>
> >>> Yes, this is one of easy way. But Albert won't  pull form
> >>> u-boot-sh, if If my understanding is not wrong.
> >>
> >> This just means that they'll end up on u-boot/master from
> >> u-boot.sh (and from there into u-boot-arm later on).
> >
> > To be clear, what I'm saying is just add a few more branches to
> > u-boot-sh that Albert will pull (since they're ARM stuff).  Say
> > u-boot-sh/rmobile/master and u-boot-sh/rmobile/next.  Then not get
> > too hung up on which repository a merge message comes from. :)
> >
> 
> I was going to do by how to explain you.
> However, I think that Albert mistook by my shortage of explanation.
> Thank you for following up.
> 
> Nobuhiro

I understand that some ARM patches would be stored in some branch
(say rmobile/master) of the u-boot-sh repo and pull-requested to me
from there.

What I still don't understand is *why* this should be done. Before they
get on this branch, the patches would still have to go through the
mailing list for review, just like the ARM patches that end up applied
to u-boot-arm/master, except they'd have to do through an intermediate
branch. If there are benefits in this, someone will have to lay them
out for me, because right now I don't see them.

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

Re: [U-Boot] gpt: GUID/UUID - GPT restoration - open questions

[Stephen Warren]

On 09/06/2012 08:14 AM, Lukasz Majewski wrote:
> Hi Rob,
> 
>> The question I'm asking is why we need partition creation support in
>> u-boot in the first place? 
> 
> Please consider following scenarios:
> 
> 1. eMMC content is exported to the user (via UMS USB Mass Storage). Then
> user by chance or on purpose will corrupt MBR/GPT.
> 
> 2. misuse of "mmc" command - user by chance writes mmc erase 0.
> 
> To unbrick the device one would simply use "gpt/part restore" command
> with already defined at ./include/config/{target}.h default settings
> for partitions.
> 
>> Next you need filesystem creation too?
> 
> I can use UMS to export eMMC to host PC (with restored partitions) and
> then use mkfs.* to create proper file system.

In that case, wouldn't you be exposing the entire eMMC device over UMS,
and hence the user could just run fdisk/parted/... on the host, just
like you're proposing they run mkfs on the host?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/6] gpt: Support for GPT (GUID Partition Table) restoration

[Stephen Warren]

On 09/06/2012 05:19 AM, Lukasz Majewski wrote:
> Hi Stephen,
> 
>> On 08/24/2012 02:13 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,
>>> +  int parts, unsigned int *blocks, char *name[]);
>>
>> That interface seems very limiting; what if you want to select
>> specific type UUIDs, set the partition attributes, leave gaps between
>> the partitions, have the physical order of partitions (their block
>> numbers) be different to the partition table ordering, etc.
>>
>> I wonder if it wouldn't be better to take an array of structures here,
>> and have each entry define all the properties of the partition. That
>> would allow fields to be added to the structure to describe more
>> information as we add more functionality.
> 
> I agree.
> 
> I'd propose following approach:
> 
> - set_gpt_table will receive a table with pointers to partition entries
>   (up to 128 entries in this table). In this way one can easily define
>   partition properties (which can be different for different
>   commands/boards).
> 
> - I think, that Legacy MBR, and Primary/Secondary GPT shall be
>   generated in the set_gpt_table function. However I expect a problem
>   with one Primary/Secondary GPT field
>   - the Disk GUID. We can read it from environment, generate it or
>   hardcode it at ./include/boards/{target}.h
> 
> 
> What is your opinion?

Perhaps rather than /just/ taking a pointer to a table of partitions,
take a pointer to a struct, which can hold both global properties and a
pointer to the list of partitions?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 4/6] video: cfb_console: add function to plot the logo area black

[Anatolij Gustschin]

Hi,

On Thu, 6 Sep 2012 08:07:37 +0200
Bastian Ruppert  wrote:

> Signed-off-by: Bastian Ruppert 
> CC: Anatolij Gustschin 
> CC: Tom Rini 
> CC: Stefano Babic 
> ---
>  drivers/video/cfb_console.c |   46 +++---
>  1 files changed, 42 insertions(+), 4 deletions(-)


Acked-by: Anatolij Gustschin 

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

Re: [U-Boot] [PATCH v3 3/6] video: cfb_console: logo can be positioned via the splashpos variable

[Anatolij Gustschin]

Hi,

On Thu, 6 Sep 2012 08:07:36 +0200
Bastian Ruppert  wrote:

> Extend the driver for placing the video/bmp logo as specified
> by "splashpos" environment variable.
> 
> Signed-off-by: Bastian Ruppert 
> Signed-off-by: Anatolij Gustschin 
> CC: Tom Rini 
> CC: Stefano Babic 
> ---
> v3:
>  - logo offset calculation is no longer based on BMP_ALIGN_CENTER
>if "m" specifier is used in splashpos
> 
> v2:
>  - remove some ifdefs
>  - revise commit log
>  - adjust video_logo_height by video_logo_ypos and thus
>fix return address for video console offset
>  - add BMP_ALIGN_CENTER case to logo_plot() for proper logo
>offset calculation if "m" specifier is used in splashpos
> ---
>  drivers/video/cfb_console.c |   93 +++---
>  1 files changed, 68 insertions(+), 25 deletions(-)

Acked-by: Anatolij Gustschin 

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

Re: [U-Boot] [PATCH 2/6] gpt: Replace the leXX_to_int() calls with ones defined at

[Stephen Warren]

On 09/06/2012 04:20 AM, Lukasz Majewski wrote:
> Hi Stephen,
> 
>> On 08/24/2012 02:13 AM, Lukasz Majewski wrote:
>>> Custom definitions of le_XX_to_int functions have been replaced with
>>> standard ones, defined at 
>>>
>>> Signed-off-by: Chang Hyun Park 
>>> Signed-off-by: Lukasz Majewski 
>>> Signed-off-by: Kyungmin Park 
>>
>> Did Chang Hyun Park write this? If so, shouldn't git have generated a
>> "From" header for him, to reflect his authorship upstream. I'm not
>> sure how Kyungmin Park's S-o-b plays into this, since he's not
>> sending the patch.
> 
> My work (for those patches) was based on Mr. Chang Hyum Park patches.
> However I had to modify his work for patches submission.
> 
> Therefore I've added Mr. Chang in a first place to credit his effort to
> this patch series creation.
> 
> Shall I do it in a different way?

To be honest, I'm not really sure. When I've done this, I've kept the
original author in the git "author" field to show this, and then listed
what I changed in the commit description. Whether that's the right way
to go perhaps depends on the size of your changes. If your changes are
so large that it doesn't make sense to do that, perhaps his S-o-b should
be removed and replaced with a simple note "based on work by Chang Hyun
Park "?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 4/4] cmd_part: add partition-related command

[Stephen Warren]

On 09/06/2012 11:12 AM, Tom Rini wrote:
> On Wed, Sep 05, 2012 at 08:38:26PM -0600, Stephen Warren wrote:
>> On 09/05/2012 05:51 PM, Rob Herring wrote:
>>> On 09/05/2012 05:03 PM, Stephen Warren wrote:
 From: Stephen Warren 

 This implements the following:

 part uuid mmc 0:1
   -> print partition UUID
 part uuid mmc 0:1 uuid
   -> set environment variable to partition UUID
>>>
>>> What's the reason to not always both print out and set the uuid env var?
>>>
>>> Perhaps the env name should be partuuid or part_uuid as you could have
>>> uuid's for other purposes?
>>
>> The idea is that if you're running the command interactively, you won't
>> pass a variable name on the command-line, so the command will print out
>> the UUID for you to read. In this case, it's pointless to set any
>> environment variable.
>>
>> However, if you're writing a script, you want to capture the UUID into
>> an environment variable, and it's quite unlikely you want to litter
>> stdout with that content too. Hence, either-or, not both.
> 
> Do other commands have a "I'm being scripted, probably, don't stdout"
> and "I'm being interactive, use stdout" distinction like this?  IMHO,
> always printing out makes sense so you can "see" that your script is
> working as you expect.

In general, as a script writer, yes you do have the ability to choose.
Typically, I'd write:

part uuid 

vs.

var=`part uuid `

in order to control this. However, U-Boot's shell doesn't support
backticks. As a script writer, I certainly desire the ability to control
what commands spam to the console, and really don't think it's useful to
print the UUID from a script (does the user really care, and any script
developer can just echo it for debugging if they need it).

I'm not aware of other U-Boot commands whose purpose it is to set
environment variables, so can't really compare.

Still, if you're insistent on this point, I can change the code to
always print, and optionally write an environment variable.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/4] Board support and feature for LaCie devices

[Prafulla Wadaskar]

> -Original Message-
> From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
> Sent: 06 September 2012 08:07
> To: U-Boot
> Cc: Simon Guinot; Prafulla Wadaskar
> Subject: Re: [PATCH v3 0/4] Board support and feature for LaCie
> devices
> 
> Hi Simon,
> 
> On Thu, 6 Sep 2012 13:27:19 +0200, Simon Guinot
>  wrote:
> 
> > On Thu, Sep 06, 2012 at 11:25:23AM +0200, Simon Guinot wrote:
> > > Changes for v3:
> > >  - Rebased against u-boot-mv/master and u-boot-arm/master.
> > >
> > > Changes for v2:
> > >  - Move board support and feature into a separate patch set.
> > >  - Move mach-types update into a separate patch.
> > >
> > > Simon Guinot (4):
> > >   lacie_kw: add support for EFI partitions
> > >   ARM: add netspace_mini_v2 to mach-types.h
> > >   ARM: add support for Network Space v2 Lite and Mini
> > >   ARM: add support for d2 Network v2
> > >
> > >  arch/arm/include/asm/mach-types.h |   13 +++
> > >  board/LaCie/common/common.c   |   36 ++-
> > >  board/LaCie/common/common.h   |1 +
> > >  board/LaCie/netspace_v2/kwbimage-ns2l.cfg |  162
> > > +
> > > board/LaCie/netspace_v2/netspace_v2.c |4 +
> > > boards.cfg|3 +
> > > include/configs/lacie_kw.h|   42 ++-- 7 files
> > > changed, 252 insertions(+), 9 deletions(-) create mode 100644
> > > board/LaCie/netspace_v2/kwbimage-ns2l.cfg
> >
> > Hi Albert and Prafulla,
> >
> > I thinks I miss the point with this v3 patch series. I understand
> now,
> > I have to drop the patch: "ARM: add netspace_mini_v2 to mach-
> types.h"
> >
> > The problem is that the boards netspace_mini_v2, and more recently
> > netspace_lite_v2, have been removed from the Linux mach-types file.
> > As a temporary solution, I could include the missing MACH_TYPE_
> > definitions to the header configs/lacie_kw.h.
> >
> > Is that correct ?
> 
> Correct. Boards which are being dropped from Linux mach-types have not
> necessarily died or stopped using (older) Linux or U-Boot, so we need
> to keep their mach-types around, in their board config headers.
> 
> I will pull the mach-types file myself and either remove redundant
> mach
> types from config header files or Cc: maintainers of boards the
> machine
> type of which have been dropped so that they fix their boards.
> 
> > If yes, do you want me to resend the whole patch
> > series or just an update for the patch "ARM: add support for Network
> > Space v2 Lite and Mini" ?
> 
> Only updating that patch in the series is fine with me. Prafulla ?

If the MACHINE ID is not available in the mach_types.h, then we can define in 
the board specific file instead of updating mach_types.h?

Hi Simon, can you take care of this and post v4?

Regards...
Prafulla . . .

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

Re: [U-Boot] [NEXT PATCH v1 5/7] SPL: Added MLO for mx35 SOC to SPL Makefile

[Tom Rini]

On 09/06/2012 01:04 AM, Stefano Babic wrote:
> Signed-off-by: Stefano Babic 
> ---
>  spl/Makefile |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/spl/Makefile b/spl/Makefile
> index f96c08e..77fc405 100644
> --- a/spl/Makefile
> +++ b/spl/Makefile
> @@ -109,6 +109,12 @@ $(OBJTREE)/MLO:  $(obj)u-boot-spl.bin
>   -a $(CONFIG_SPL_TEXT_BASE) -d $< $@
>  endif
>  
> +ifneq ($(CONFIG_IMX_CONFIG),)
> +$(OBJTREE)/MLO:  $(obj)u-boot-spl.bin
> + $(OBJTREE)/tools/mkimage -n  $(SRCTREE)/$(CONFIG_IMX_CONFIG) -T 
> imximage \
> + -e $(CONFIG_SPL_TEXT_BASE) -d $< $@
> +endif
> +
>  ALL-y+= $(obj)u-boot-spl.bin
>  
>  ifdef CONFIG_SAMSUNG

Is that really the name you want?  MLO comes from some part or another
(I've read it, just can't recall off-hand) of the IT ROM docs saying it
will read a file named MLO.  Is mx35 in the same boat?  Or just looking
for a common name?  Thanks!

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

Re: [U-Boot] [PATCH 2/2] patman: Do not sort changlog items order

[Otavio Salvador]

On Sun, Sep 2, 2012 at 5:23 PM, Wolfgang Denk  wrote:
> Dear Fabio,
>
> In message 
>  you 
> wrote:
>>
>> > I cannot really parse this, not even if I assume we should s/of/if/
>> > here.  What exactly do you mean?
>>
>> Looks like Otavio meant to do the same as this patch from Ilya Yanok,
>> which is now applied:
>
> This is my guess, too.  But I'd like to be sure.

Yes; you're both right. Same fix but I didn't change the uniq handle
as I think it is nice to have.

-- 
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 4/4] cmd_part: add partition-related command

[Tom Rini]

On Wed, Sep 05, 2012 at 08:38:26PM -0600, Stephen Warren wrote:
> On 09/05/2012 05:51 PM, Rob Herring wrote:
> > On 09/05/2012 05:03 PM, Stephen Warren wrote:
> >> From: Stephen Warren 
> >>
> >> This implements the following:
> >>
> >> part uuid mmc 0:1
> >>   -> print partition UUID
> >> part uuid mmc 0:1 uuid
> >>   -> set environment variable to partition UUID
> > 
> > What's the reason to not always both print out and set the uuid env var?
> > 
> > Perhaps the env name should be partuuid or part_uuid as you could have
> > uuid's for other purposes?
> 
> The idea is that if you're running the command interactively, you won't
> pass a variable name on the command-line, so the command will print out
> the UUID for you to read. In this case, it's pointless to set any
> environment variable.
> 
> However, if you're writing a script, you want to capture the UUID into
> an environment variable, and it's quite unlikely you want to litter
> stdout with that content too. Hence, either-or, not both.

Do other commands have a "I'm being scripted, probably, don't stdout"
and "I'm being interactive, use stdout" distinction like this?  IMHO,
always printing out makes sense so you can "see" that your script is
working as you expect.

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

Re: [U-Boot] [PATCH 4/5] powerpc/85xx: Add P5040 processor support

[Scott Wood]

On 08/31/2012 03:25 PM, Timur Tabi wrote:
> + SET_PCI_LIODN_BASE(CONFIG_SYS_FSL_PCIE_COMPAT, 1, 193),
> + SET_PCI_LIODN_BASE(CONFIG_SYS_FSL_PCIE_COMPAT, 2, 194),
> + SET_PCI_LIODN_BASE(CONFIG_SYS_FSL_PCIE_COMPAT, 3, 195),

You're only allowing for one LIODN per PCIe controller, which defeats
the purpose of the new PCIe LIODN mechanism.

Please allocate several contiguous LIODNs per controller, set the base
to the first one, and enumerate the rest in a device tree property for
the OS to use.

-Scott


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

Re: [U-Boot] [PATCH 01/10] dm: arm: Remove support for lpc2292

[Tom Rini]

On 09/05/2012 07:44 PM, Marek Vasut wrote:
> Dear Tom Rini,
> 
>> On Sun, Sep 02, 2012 at 06:15:02PM +0200, Marek Vasut wrote:
>>> Dear Wolfgang Denk,
>>>
 Dear Albert,

 In message <1342882947-9174-1-git-send-email-ma...@denx.de> Marek Vasut 
> wrote:
> This stuff has been rotting in the tree for a year now. Remove it.
>
> Signed-off-by: Marek Vasut 
> Cc: Wolfgang Denk 
> Cc: Albert Aribaud 
> Cc: U-Boot DM 

 In case you are going to apply any of these patches, please do make
 sure to drop the "dm: " string from all these subjects.
>>>
>>> At least add some ID so I can mine these patches back when we finish the
>>> project. If you drop them, I won't have any way to tell.
>>
>> You shouldn't need any.  At the end of the project just do:
>> $ git log --author=(regex|that|catches|everyone) --since=project-start
> 
> What about me generating gazilion of other patches?

Use your denx.de for work and your gmail or university email for the
project?

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

Re: [U-Boot] [PATCH v3] PXE: FDT: Add support for fdt in PXE

[Jason Hobbs]

Chander,

Comments inline.

On Thu, Sep 06, 2012 at 01:40:04AM -0400, Chander Kashyap wrote:
> Now DT support is becomming common for all new SoC's. Hence it is better to
> have option for getting specific FDT from the remote server.
> 
> This patch adds support for new lable i.e. fdt. If fdt_addr is specified
> then load fdt blob from the remote server to fdt_address.

If a fdt label is provided AND fdt_addr is specified, then load the blob
from the remote server to fdt_addr. fdt_addr alone still works on its
own if the fdt_blob has already been loaded some other way

> 
> Signed-off-by: Chander Kashyap 
> ---
> Changes in v2:
>   - Removed the duplicate code.
> changes in v3:
>   - Added documentation for "fdt" lable in doc/README.pxe 

s/lable/label - fix globally

> 
>  common/cmd_pxe.c |   23 +++
>  doc/README.pxe   |   10 --
>  2 files changed, 31 insertions(+), 2 deletions(-)
> 
> diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
> index 6b31dea..0c81e08 100644
> --- a/common/cmd_pxe.c
> +++ b/common/cmd_pxe.c
> @@ -450,6 +450,7 @@ struct pxe_label {
>   char *kernel;
>   char *append;
>   char *initrd;
> + char *fdt;
>   int attempted;
>   int localboot;
>   struct list_head list;
> @@ -517,6 +518,9 @@ static void label_destroy(struct pxe_label *label)
>   if (label->initrd)
>   free(label->initrd);
>  
> + if (label->fdt)
> + free(label->fdt);
> +
>   free(label);
>  }
>  
> @@ -541,6 +545,9 @@ static void label_print(void *data)
>  
>   if (label->initrd)
>   printf("\t\tinitrd: %s\n", label->initrd);
> +
> + if (label->fdt)
> + printf("\tfdt: %s\n", label->fdt);
>  }
>  
>  /*
> @@ -633,6 +640,15 @@ static void label_boot(struct pxe_label *label)
>*/
>   bootm_argv[3] = getenv("fdt_addr");
>  
> + /* if fdt label is defined then get fdt from server */
> + if (bootm_argv[3] && label->fdt) {
> + if (get_relfile_envaddr(label->fdt, "fdt_addr") < 0) {
> + printf("Skipping %s for failure retrieving fdt\n",
> + label->name);
> + return;
> + }
> + }
> +
>   if (bootm_argv[3])
>   bootm_argc = 4;
>  
> @@ -658,6 +674,7 @@ enum token_type {
>   T_DEFAULT,
>   T_PROMPT,
>   T_INCLUDE,
> + T_FDT,
>   T_INVALID
>  };
>  
> @@ -685,6 +702,7 @@ static const struct token keywords[] = {
>   {"append", T_APPEND},
>   {"initrd", T_INITRD},
>   {"include", T_INCLUDE},
> + {"fdt", T_FDT},
>   {NULL, T_INVALID}
>  };
>  
> @@ -1074,6 +1092,11 @@ static int parse_label(char **c, struct pxe_menu *cfg)
>   err = parse_sliteral(c, &label->initrd);
>   break;
>  
> + case T_FDT:
> + if (!label->fdt)
> + err = parse_sliteral(c, &label->fdt);
> + break;
> +
>   case T_LOCALBOOT:
>   err = parse_integer(c, &label->localboot);
>   break;
> diff --git a/doc/README.pxe b/doc/README.pxe
> index 2bbf53d..835ca5a 100644
> --- a/doc/README.pxe
> +++ b/doc/README.pxe
> @@ -93,8 +93,9 @@ pxe boot
>   be passed to the bootm command to boot the kernel. These environment
>   variables are required to be set.
>  
> - fdt_addr - the location of a fdt blob. If this is set, it will be passed
> - to bootm when booting a kernel.
> + fdt_addr - locations in RAM at which 'pxe boot' will store the fdt blob
> + it retrieves from tftp, if "fdt" lable is defined in pxe file. If this 
> is
> + set, it will be passed to bootm when booting a kernel.

Thinking about this some more, I don't think you can use fdt_addr as the
place to store the blob. fdt_addr isn't garaunteed to be writeable RAM -
it could be a read only non volatile memory like NOR flash.

If you notice, all of the other tftp retrievals go to "_r" suffixed
variables, which are garaunteed (by convention) to be in writeable RAM.

You may need to take an approach where an addition fdt_addr_r variable
is used to point at the location to store the fdt blob.

Your description also makes it less clear that if fdt_addr is set, it
points to the blob, whether or not it was retrieved from tftp.

>  
>  pxe file format
>  ===
> @@ -156,6 +157,11 @@ initrd - if this label is chosen, use tftp 
> to retrieve the initrd
> the initrd_addr_r environment variable, and that address
> will be passed to bootm.
>  
> +fdt- if this label is chosen, use tftp to retrieve the fdt blob
> +   at . it will be stored at the address indicated in
> +   the fdt_addr environment variable, and that address will
> +   be passed to bootm.
> +

again, this should be changed to fdt_addr_r.


>  localboo

Re: [U-Boot] [v3] arm: Fixed the offset for the no relocation.

[Zhong Hongbo]

On 06/09/12 03:22, Stefano Babic wrote:
> On 05/09/2012 16:45, Zhong Hongbo wrote:
>> On 04/09/12 23:57, Stefano Babic wrote:
>>> On 04/09/2012 16:03, Zhong Hongbo wrote:
 On 03/09/12 08:14, Marek Vasut wrote:
> Dear Zhong Hongbo,
>
>> From: Zhong Hongbo 
>>
>> When the u-boot address of destination equal to  __start,
>> no relocation. relocation offset(r9) = 0.
>
> Good, now what kind of issue does this patch fix?
 Hi Marek

 When you adopt CONFIG_SPL_BUILD framework, no CONFIG_NAND_SPL, if the
 addr of destination is equal to _start, we should skip u-boot relocation.

 In the last, u-boot will count the dest addr, see the below:


 adr r1, _start
 add lr, r0, r1
 add lr, lr, r9

 Here, lr = lr + r9, r9 is the offset of u-boot, So when it do not neet
 to reolocat, we need to set the zero value for r9 register.

 /* setup parameters for board_init_r */
 mov r0, r5  /* gd_t */
 mov r1, r6  /* dest_addr */
 /* jump to it ... */
 mov pc, lr
>>>
>>> I can confirm this issue - I see this when I ported SPL to a MX35 board.
>>> However, clearing r9 was not enough. I had to fix also _rel_dyn_* to
>>> make SPL working, and I did changing the start.S in the same way start.S
>>> for arv7 is built.
>>>
>>> Do you not have these issues ?
>> Hi Stefano,
>>
>> That is enough for my smdk6400 board.
> 
> 
Hi Stefano,

> Ok, thanks. Then I will post a patch on top of yours, but here my:
> 
> Tested-by: Stefano Babic 
> 
> Tested on a i.MX35 board (ARM1136) with SPL.

Ok, Thanks,

BR,
hongbo
> 
> Regards,
> Stefano
> 
> 

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

Re: [U-Boot] [PATCH v3 0/4] Board support and feature for LaCie devices

[Albert ARIBAUD]

Hi Simon,

On Thu, 6 Sep 2012 13:27:19 +0200, Simon Guinot
 wrote:

> On Thu, Sep 06, 2012 at 11:25:23AM +0200, Simon Guinot wrote:
> > Changes for v3:
> >  - Rebased against u-boot-mv/master and u-boot-arm/master.
> > 
> > Changes for v2:
> >  - Move board support and feature into a separate patch set.
> >  - Move mach-types update into a separate patch.
> > 
> > Simon Guinot (4):
> >   lacie_kw: add support for EFI partitions
> >   ARM: add netspace_mini_v2 to mach-types.h
> >   ARM: add support for Network Space v2 Lite and Mini
> >   ARM: add support for d2 Network v2
> > 
> >  arch/arm/include/asm/mach-types.h |   13 +++
> >  board/LaCie/common/common.c   |   36 ++-
> >  board/LaCie/common/common.h   |1 +
> >  board/LaCie/netspace_v2/kwbimage-ns2l.cfg |  162
> > +
> > board/LaCie/netspace_v2/netspace_v2.c |4 +
> > boards.cfg|3 +
> > include/configs/lacie_kw.h|   42 ++-- 7 files
> > changed, 252 insertions(+), 9 deletions(-) create mode 100644
> > board/LaCie/netspace_v2/kwbimage-ns2l.cfg
> 
> Hi Albert and Prafulla,
> 
> I thinks I miss the point with this v3 patch series. I understand now,
> I have to drop the patch: "ARM: add netspace_mini_v2 to mach-types.h"
> 
> The problem is that the boards netspace_mini_v2, and more recently
> netspace_lite_v2, have been removed from the Linux mach-types file.
> As a temporary solution, I could include the missing MACH_TYPE_
> definitions to the header configs/lacie_kw.h.
> 
> Is that correct ?

Correct. Boards which are being dropped from Linux mach-types have not
necessarily died or stopped using (older) Linux or U-Boot, so we need
to keep their mach-types around, in their board config headers.

I will pull the mach-types file myself and either remove redundant mach
types from config header files or Cc: maintainers of boards the machine
type of which have been dropped so that they fix their boards.

> If yes, do you want me to resend the whole patch
> series or just an update for the patch "ARM: add support for Network
> Space v2 Lite and Mini" ?

Only updating that patch in the series is fine with me. Prafulla ?

> Regards,
> 
> Simon

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

Re: [U-Boot] gpt: GUID/UUID - GPT restoration - open questions

[Lukasz Majewski]

Hi Rob,

> The question I'm asking is why we need partition creation support in
> u-boot in the first place? 

Please consider following scenarios:

1. eMMC content is exported to the user (via UMS USB Mass Storage). Then
user by chance or on purpose will corrupt MBR/GPT.

2. misuse of "mmc" command - user by chance writes mmc erase 0.

To unbrick the device one would simply use "gpt/part restore" command
with already defined at ./include/config/{target}.h default settings
for partitions.

> Next you need filesystem creation too?

I can use UMS to export eMMC to host PC (with restored partitions) and
then use mkfs.* to create proper file system.


-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] [PATCH 5/6] gpt: Support for new "gpt" command

[Lukasz Majewski]

Hi Stephen,

> On 08/24/2012 02:13 AM, Lukasz Majewski wrote:
> > New command - "gpt" is now supported. It shows and restores the GPT
> > partition table.
> > It looks into the "partitions" environment variable for partitions
> > definition. It can be enabled at target configuration file with
> > CONFIG_CMD_GPT.
> 
> > diff --git a/common/cmd_gpt.c b/common/cmd_gpt.c
> 
> > +int set_gpt_info(block_dev_desc_t *dev_desc)
> > +{
> > +   char *ps[GPT_PARTS_NUM], *name[GPT_PARTS_NUM];
> > +   unsigned int size[GPT_PARTS_NUM];
> > +   char *tok, *t, *p, *s, *ss;
> > +   int i, ret;
> > +
> > +   s = getenv("partitions");
> > +   if (s == NULL) {
> > +   printf("%s: \"partitions\" env variable not
> > defined!\n",
> > +  __func__);
> > +   return -1;
> > +   }
> 
> It'd be nice to be able to pass the partition definition on the
> command-line instead of (or perhaps as an alternative to) reading an
> environment variable.
> 
> Some documentation of the expected format of the partitions variable
> would be useful. From the following patch, the format appears to be:
> 
> 8M(csa-mmc),60M(u-boot),60M(kernel),...
> 
> That's not particularly extensible (think about allowing partition
> type UUID to or attributes to be specified), and the brackets are a
> bit painful. Can we use key/value for defining the values, and have a
> simple separate separator between fields and partitions, e.g.
> something like:
> 
> size=8M,name=csa-mmc;size=60M,name=u-boot;size=60M,name=kernel;...
This approach looks reasonable, but...

> 
> That would allow us to very easily allow new fields to be specified
> per partition in the future, e.g.:
> 
> uuid=X,size=512M,name=boot,type=21686148-6449-6E6F-744E-656564454649,attrs=2;uuid=Y,size=7000M,name=root,type=0FC63DAF-8483-4772-8E79-3D69D8477DE4,attrs=0;...

it would be a pain to paste so long string to u-boot command line.
Suppose we have 8 partitions to define. Then the definition string grows
considerable.

For default restoration, it would be good to define the environment
variable (like "partitions") to perform quick default restoration.

However there is a problem with passing UUID - size, name and
attributes can be defined at ./include/config/{board}.h
(partitions=size=8M,name=csa-mmc;size=60M,name=u-boot;size=60M,name=kernel)
, but UUID shall be passed by user via command line or generated
internally at u-boot (as it is proposed in this patch).

When passing from user it would look like:

gpt default uuid1 uuid2  uuid8

But we shall also think about using guid_gen() function (reimplemented)
for handy and quick gpt restoration.


> 
> > +U_BOOT_CMD(
> > +   gpt,CONFIG_SYS_MAXARGS, 1, do_gpt,
> > +   "GUID Partition Table",
> ...
> > +   "gpt restore - reset GPT partition to defaults\n"
> > +   "gpt dev #num - set device number\n"
> ...
> > +static void set_gpt_dev(int dev)
> > +{
> > +   gpt_dev = dev;
> > +}
> > +
> 
> Hmmm. I think it'd be better to specify the device each time the gpt
> command was invoked. That would be simpler to use, more flexible, and
> more consistent with how other commands such as "ext2load" operate.
> 
> In other words, I would get rid of "gpt dev" completely, and instead
> of implementing "gpt restore", implement "gpt restore mmc 0".

Agree - the same approach is in dfu.

> 
> I'm not sure "restore" is the correct name, given that the command can
> write arbitrary new partition layouts, rather than just restoring some
> specific hard-coded table from e.g. a backup image.
> 
> I'm not sure that "gpt" is even the best command name; it'd be nice if
> this were generic and could be extended to work with e.g. FAT in the
> future - something like:
> 
> part write usb 1 gpt uuid=X,size=512M,name=boot,...
> part write mmc 0 fat size=512M,attrs=0x80;...

I'm open for discussion. Since part command is not yet finished, I will
use the gpt command for version 2 of this patch series. When we agree
with rest of GPT implementation we can decide if gpt or part command
will be used. OK?
> 
> > +U_BOOT_CMD(
> > +   gpt,CONFIG_SYS_MAXARGS, 1, do_gpt,
> > +   "GUID Partition Table",
> > +   "show - show GPT\n"
> 
> s/show/gpt show/
> 
> > +static void gpt_show(void)
> > +{
> > +   struct mmc *mmc = find_mmc_device(gpt_dev);
> > +
> > +   print_part_efi(&mmc->block_dev);
> > +}
> 
> Do we really need another way of showing partition tables; "mmc part",
> "usb part", ... already exist. I think if we want another way, it'd be
> better to add this functionality to my proposed "part" command, i.e.
> "part show mmc 0".

I agree that "gpt show" is not needed. Instead "mmc part" can be used.
> 
> > +static int gpt_default(void)
> > +{
> > +   struct mmc *mmc = find_mmc_device(gpt_dev);
> > +
> > +   if (mmc == NULL) {
> > +   printf("%s: mmc dev %d NOT available\n", __func__,
> > gpt_dev);
> > +   return CMD_RET_FAILURE;
> > +   }
> 
> Why only allow mmc devices; what about USB for example? Other commands
> 

[U-Boot] [Patch V6 4/4] MIPS: add board qemu-mips64 support

[Zhizhou Zhang]

Both big-endian and little-endian are tested with below commands:
Rom version: (Default, Now we config it as rom version)
qemu-system-mips64el -M mips -bios u-boot.bin -cpu MIPS64R2-generic -nographic
qemu-system-mips64 -M mips -bios u-boot.bin -cpu MIPS64R2-generic -nographic
Ram version:
qemu-system-mips64el -M mips -cpu MIPS64R2-generic -kernel u-boot -nographic
qemu-system-mips64 -M mips -cpu MIPS64R2-generic -kernel u-boot -nographic

Signed-off-by: Zhizhou Zhang 
---
 arch/mips/cpu/mips64/Makefile |   45 +++
 arch/mips/cpu/mips64/cache.S  |  229 +
 arch/mips/cpu/mips64/config.mk|   40 ++
 arch/mips/cpu/mips64/cpu.c|  111 
 arch/mips/cpu/mips64/interrupts.c |   34 +
 arch/mips/cpu/mips64/start.S  |  256 +
 arch/mips/cpu/mips64/time.c   |   87 +
 board/qemu-mips/u-boot.lds|8 ++
 boards.cfg|2 +
 examples/standalone/mips64.lds|   59 +
 include/configs/qemu-mips64.h |  175 +
 11 files changed, 1046 insertions(+)
 create mode 100644 arch/mips/cpu/mips64/Makefile
 create mode 100644 arch/mips/cpu/mips64/cache.S
 create mode 100644 arch/mips/cpu/mips64/config.mk
 create mode 100644 arch/mips/cpu/mips64/cpu.c
 create mode 100644 arch/mips/cpu/mips64/interrupts.c
 create mode 100644 arch/mips/cpu/mips64/start.S
 create mode 100644 arch/mips/cpu/mips64/time.c
 create mode 100644 examples/standalone/mips64.lds
 create mode 100644 include/configs/qemu-mips64.h

diff --git a/arch/mips/cpu/mips64/Makefile b/arch/mips/cpu/mips64/Makefile
new file mode 100644
index 000..be38664
--- /dev/null
+++ b/arch/mips/cpu/mips64/Makefile
@@ -0,0 +1,45 @@
+#
+# (C) Copyright 2003-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(CPU).o
+
+START  = start.o
+COBJS-y= cpu.o interrupts.o time.o cache.o
+
+SRCS   := $(START:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
+START  := $(addprefix $(obj),$(START))
+
+all:   $(obj).depend $(START) $(LIB)
+
+$(LIB):$(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
diff --git a/arch/mips/cpu/mips64/cache.S b/arch/mips/cpu/mips64/cache.S
new file mode 100644
index 000..036f035
--- /dev/null
+++ b/arch/mips/cpu/mips64/cache.S
@@ -0,0 +1,229 @@
+/*
+ *  Cache-handling routined for MIPS CPUs
+ *
+ *  Copyright (c) 2003 Wolfgang Denk 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RA t9
+
+/*
+ * 16kB is the maximum size of instruction and data caches on MIPS 4K,
+ * 64kB is on 4KE, 24K, 5K, etc. Set bigger size for convenience.
+ *
+ * Note that the above size is the maximum size of primary cache. U-Boot
+ * doesn't have L2 cache support for now.
+ */
+#define MIPS_MAX_CACHE_SIZE0x1
+
+#define INDEX_BASE CKSEG0
+
+   .macro  cache_op op addr
+   .setpush
+   .setnoreorder
+   .setmips3
+   cache   \op, 0(\addr)
+   .setpop
+   .endm
+
+   .macro  f_fill64 dst, offset, val
+   LONG_S

[U-Boot] [Patch V6 2/4] MIPS: change address related header files

[Zhizhou Zhang]

Prepare for upcoming mips64 support. This patch add mips64 address
support.

Signed-off-by: Zhizhou Zhang 
---
 arch/mips/include/asm/addrspace.h   |2 +-
 arch/mips/include/asm/io.h  |   16 
 arch/mips/include/asm/posix_types.h |6 ++
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/arch/mips/include/asm/addrspace.h 
b/arch/mips/include/asm/addrspace.h
index 3a1e6d6..b768bb5 100644
--- a/arch/mips/include/asm/addrspace.h
+++ b/arch/mips/include/asm/addrspace.h
@@ -136,7 +136,7 @@
cannot access physical memory directly from core */
 #define UNCACHED_SDRAM(a) (((unsigned long)(a)) | 0x2000)
 #else  /* !CONFIG_SOC_AU1X00 */
-#define UNCACHED_SDRAM(a) KSEG1ADDR(a)
+#define UNCACHED_SDRAM(a) CKSEG1ADDR(a)
 #endif /* CONFIG_SOC_AU1X00 */
 #endif /* __ASSEMBLY__ */
 
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 025012a..80eab75 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -120,12 +120,20 @@ static inline void set_io_port_base(unsigned long base)
  */
 extern inline phys_addr_t virt_to_phys(volatile void * address)
 {
+#ifndef CONFIG_64BIT
return CPHYSADDR(address);
+#else
+   return XPHYSADDR(address);
+#endif
 }
 
 extern inline void * phys_to_virt(unsigned long address)
 {
+#ifndef CONFIG_64BIT
return (void *)KSEG0ADDR(address);
+#else
+   return (void *)CKSEG0ADDR(address);
+#endif
 }
 
 /*
@@ -133,12 +141,20 @@ extern inline void * phys_to_virt(unsigned long address)
  */
 extern inline unsigned long virt_to_bus(volatile void * address)
 {
+#ifndef CONFIG_64BIT
return CPHYSADDR(address);
+#else
+   return XPHYSADDR(address);
+#endif
 }
 
 extern inline void * bus_to_virt(unsigned long address)
 {
+#ifndef CONFIG_64BIT
return (void *)KSEG0ADDR(address);
+#else
+   return (void *)CKSEG0ADDR(address);
+#endif
 }
 
 /*
diff --git a/arch/mips/include/asm/posix_types.h 
b/arch/mips/include/asm/posix_types.h
index 879aae2..6566ad0 100644
--- a/arch/mips/include/asm/posix_types.h
+++ b/arch/mips/include/asm/posix_types.h
@@ -24,9 +24,15 @@ typedef int  __kernel_pid_t;
 typedef int__kernel_ipc_pid_t;
 typedef int__kernel_uid_t;
 typedef int__kernel_gid_t;
+#ifndef CONFIG_MIPS64
 typedef unsigned int   __kernel_size_t;
 typedef int__kernel_ssize_t;
 typedef int__kernel_ptrdiff_t;
+#else
+typedef unsigned long  __kernel_size_t;
+typedef long   __kernel_ssize_t;
+typedef long   __kernel_ptrdiff_t;
+#endif
 typedef long   __kernel_time_t;
 typedef long   __kernel_suseconds_t;
 typedef long   __kernel_clock_t;
-- 
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] MIPS: remove board/qemu-mips/config.mk

[Zhizhou Zhang]

We define CONFIG_SYS_TEXT_BASE in board's specified header file.
So config.mk is useless, then remove it.

Signed-off-by: Zhizhou Zhang 
---
 board/qemu-mips/config.mk   |   10 --
 include/configs/qemu-mips.h |1 +
 2 files changed, 1 insertion(+), 10 deletions(-)
 delete mode 100644 board/qemu-mips/config.mk

diff --git a/board/qemu-mips/config.mk b/board/qemu-mips/config.mk
deleted file mode 100644
index 27cd34a..000
--- a/board/qemu-mips/config.mk
+++ /dev/null
@@ -1,10 +0,0 @@
-#
-# Qemu -M mips system emulator
-# See http://fabrice.bellard.free.fr/qemu
-#
-
-# ROM version
-CONFIG_SYS_TEXT_BASE = 0xbfc0
-
-# RAM version
-#CONFIG_SYS_TEXT_BASE = 0x80001000
diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
index b8b9705..f45f78b 100644
--- a/include/configs/qemu-mips.h
+++ b/include/configs/qemu-mips.h
@@ -137,6 +137,7 @@
  */
 
 /* The following #defines are needed to get flash environment right */
+#define CONFIG_SYS_TEXT_BASE   0xbfc0 /* Rom version */
 #define CONFIG_SYS_MONITOR_BASECONFIG_SYS_TEXT_BASE
 #define CONFIG_SYS_MONITOR_LEN (192 << 10)
 
-- 
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 1/4] MIPS: don't use camel-case style

[Zhizhou Zhang]

Replace camel-case style with upper-case style globally.

Signed-off-by: Zhizhou Zhang 
---
 arch/mips/cpu/mips32/cache.S |   10 ++---
 arch/mips/cpu/mips32/cpu.c   |8 ++--
 arch/mips/cpu/xburst/cpu.c   |   12 +++---
 arch/mips/cpu/xburst/start.S |4 +-
 arch/mips/include/asm/asm.h  |2 +-
 arch/mips/include/asm/cacheops.h |   82 +++---
 6 files changed, 59 insertions(+), 59 deletions(-)

diff --git a/arch/mips/cpu/mips32/cache.S b/arch/mips/cpu/mips32/cache.S
index e683e8b..64dfad0 100644
--- a/arch/mips/cpu/mips32/cache.S
+++ b/arch/mips/cpu/mips32/cache.S
@@ -85,17 +85,17 @@ LEAF(mips_init_icache)
/* clear tag to invalidate */
PTR_LI  t0, INDEX_BASE
PTR_ADDUt1, t0, a1
-1: cache_opIndex_Store_Tag_I t0
+1: cache_opINDEX_STORE_TAG_I t0
PTR_ADDUt0, a2
bne t0, t1, 1b
/* fill once, so data field parity is correct */
PTR_LI  t0, INDEX_BASE
-2: cache_opFill t0
+2: cache_opFILL t0
PTR_ADDUt0, a2
bne t0, t1, 2b
/* invalidate again - prudent but not strictly neccessary */
PTR_LI  t0, INDEX_BASE
-1: cache_opIndex_Store_Tag_I t0
+1: cache_opINDEX_STORE_TAG_I t0
PTR_ADDUt0, a2
bne t0, t1, 1b
 9: jr  ra
@@ -110,7 +110,7 @@ LEAF(mips_init_dcache)
/* clear all tags */
PTR_LI  t0, INDEX_BASE
PTR_ADDUt1, t0, a1
-1: cache_opIndex_Store_Tag_D t0
+1: cache_opINDEX_STORE_TAG_D t0
PTR_ADDUt0, a2
bne t0, t1, 1b
/* load from each line (in cached space) */
@@ -120,7 +120,7 @@ LEAF(mips_init_dcache)
bne t0, t1, 2b
/* clear all tags */
PTR_LI  t0, INDEX_BASE
-1: cache_opIndex_Store_Tag_D t0
+1: cache_opINDEX_STORE_TAG_D t0
PTR_ADDUt0, a2
bne t0, t1, 1b
 9: jr  ra
diff --git a/arch/mips/cpu/mips32/cpu.c b/arch/mips/cpu/mips32/cpu.c
index 7b49e1b..50bb248 100644
--- a/arch/mips/cpu/mips32/cpu.c
+++ b/arch/mips/cpu/mips32/cpu.c
@@ -61,8 +61,8 @@ void flush_cache(ulong start_addr, ulong size)
return;
 
while (1) {
-   cache_op(Hit_Writeback_Inv_D, addr);
-   cache_op(Hit_Invalidate_I, addr);
+   cache_op(HIT_WRITEBACK_INV_D, addr);
+   cache_op(HIT_INVALIDATE_I, addr);
if (addr == aend)
break;
addr += lsize;
@@ -76,7 +76,7 @@ void flush_dcache_range(ulong start_addr, ulong stop)
unsigned long aend = (stop - 1) & ~(lsize - 1);
 
while (1) {
-   cache_op(Hit_Writeback_Inv_D, addr);
+   cache_op(HIT_WRITEBACK_INV_D, addr);
if (addr == aend)
break;
addr += lsize;
@@ -90,7 +90,7 @@ void invalidate_dcache_range(ulong start_addr, ulong stop)
unsigned long aend = (stop - 1) & ~(lsize - 1);
 
while (1) {
-   cache_op(Hit_Invalidate_D, addr);
+   cache_op(HIT_INVALIDATE_D, addr);
if (addr == aend)
break;
addr += lsize;
diff --git a/arch/mips/cpu/xburst/cpu.c b/arch/mips/cpu/xburst/cpu.c
index ddcbfaa..cc190df 100644
--- a/arch/mips/cpu/xburst/cpu.c
+++ b/arch/mips/cpu/xburst/cpu.c
@@ -84,8 +84,8 @@ void flush_cache(ulong start_addr, ulong size)
unsigned long aend = (start_addr + size - 1) & ~(lsize - 1);
 
for (; addr <= aend; addr += lsize) {
-   cache_op(Hit_Writeback_Inv_D, addr);
-   cache_op(Hit_Invalidate_I, addr);
+   cache_op(HIT_WRITEBACK_INV_D, addr);
+   cache_op(HIT_INVALIDATE_I, addr);
}
 }
 
@@ -96,7 +96,7 @@ void flush_dcache_range(ulong start_addr, ulong stop)
unsigned long aend = (stop - 1) & ~(lsize - 1);
 
for (; addr <= aend; addr += lsize)
-   cache_op(Hit_Writeback_Inv_D, addr);
+   cache_op(HIT_WRITEBACK_INV_D, addr);
 }
 
 void invalidate_dcache_range(ulong start_addr, ulong stop)
@@ -106,7 +106,7 @@ void invalidate_dcache_range(ulong start_addr, ulong stop)
unsigned long aend = (stop - 1) & ~(lsize - 1);
 
for (; addr <= aend; addr += lsize)
-   cache_op(Hit_Invalidate_D, addr);
+   cache_op(HIT_INVALIDATE_D, addr);
 }
 
 void flush_icache_all(void)
@@ -118,7 +118,7 @@ void flush_icache_all(void)
 
for (addr = CKSEG0; addr < CKSEG0 + CONFIG_SYS_ICACHE_SIZE;
 addr += CONFIG_SYS_CACHELINE_SIZE) {
-   cache_op(Index_Store_Tag_I, addr);
+   cache_op(INDEX_STORE_TAG_I, addr);
}
 
/* invalidate btb */
@@ -139,7 +139,7 @@ void flush_dcache_all

[U-Boot] [Patch V6 0/4] add mips64 cpus support

[Zhizhou Zhang]

I'm so sorry, because of my careless, I made a serious fault in last 
version. I wish everything is ok in this version.

Changes in V6:
  - reorganise patch
  - add flash support
Changes in V5:
  - omit camel-case style
  - avoid running "git bisect" failed
  - some code style problem corrected
Changes in V4:
  - Add both big-endian and little-endian support
  - Remove cache probe
  - Add standalone support for mips64
Changes in V3:
  - merge related files into one patch, no longer one file one patch.
  - add detailed commit message.
  - remove standalone example. it's too complicate.

Zhizhou Zhang (4):
  MIPS: don't use camel-case style
  MIPS: change address related header files
  MIPS: remove board/qemu-mips/config.mk
  MIPS: add board qemu-mips64 support
Zhizhou Zhang (4):
  MIPS: don't use camel-case style
  MIPS: change address related header files
  MIPS: remove board/qemu-mips/config.mk
  MIPS: add board qemu-mips64 support

 arch/mips/cpu/mips32/cache.S|   10 +-
 arch/mips/cpu/mips32/cpu.c  |8 +-
 arch/mips/cpu/mips64/Makefile   |   45 ++
 arch/mips/cpu/mips64/cache.S|  229 +++
 arch/mips/cpu/mips64/config.mk  |   40 ++
 arch/mips/cpu/mips64/cpu.c  |  111 +++
 arch/mips/cpu/mips64/interrupts.c   |   34 +
 arch/mips/cpu/mips64/start.S|  256 +++
 arch/mips/cpu/mips64/time.c |   87 
 arch/mips/cpu/xburst/cpu.c  |   12 +-
 arch/mips/cpu/xburst/start.S|4 +-
 arch/mips/include/asm/addrspace.h   |2 +-
 arch/mips/include/asm/asm.h |2 +-
 arch/mips/include/asm/cacheops.h|   82 +--
 arch/mips/include/asm/io.h  |   16 +++
 arch/mips/include/asm/posix_types.h |6 +
 board/qemu-mips/config.mk   |   10 --
 board/qemu-mips/u-boot.lds  |8 ++
 boards.cfg  |2 +
 examples/standalone/mips64.lds  |   59 
 include/configs/qemu-mips.h |1 +
 include/configs/qemu-mips64.h   |  175 
 22 files changed, 1129 insertions(+), 70 deletions(-)
 create mode 100644 arch/mips/cpu/mips64/Makefile
 create mode 100644 arch/mips/cpu/mips64/cache.S
 create mode 100644 arch/mips/cpu/mips64/config.mk
 create mode 100644 arch/mips/cpu/mips64/cpu.c
 create mode 100644 arch/mips/cpu/mips64/interrupts.c
 create mode 100644 arch/mips/cpu/mips64/start.S
 create mode 100644 arch/mips/cpu/mips64/time.c
 delete mode 100644 board/qemu-mips/config.mk
 create mode 100644 examples/standalone/mips64.lds
 create mode 100644 include/configs/qemu-mips64.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 v4 1/2] Loop block device for sandbox

[Pavel Herrmann]

This driver uses files as block devices, can be used for testing disk
operations on sandbox.
A new command "sata_loop" is introduced to load files in runtime.

Signed-off-by: Pavel Herrmann 
CC: Marek Vasut 
CC: Mike Frysinger 
---
Changes for v4:
  checkpatch fixes
  use NULLs instead of ""
  extend sata_loop command

Changes for v3:
  introduce sata_loop command

Changes for v2:
  split sandbox config off into separate patch (2/2)
  rename file to signify exported API
  style fixes
  show end of long filenames rather than beginning
  check for lseek errors to indicate non-regular file

 drivers/block/Makefile|   1 +
 drivers/block/sata_loopback.c | 212 ++
 include/configs/sandbox.h |   8 ++
 3 files changed, 221 insertions(+)
 create mode 100644 drivers/block/sata_loopback.c

diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index f1ebdcc..c95651a 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -40,6 +40,7 @@ COBJS-$(CONFIG_SATA_SIL) += sata_sil.o
 COBJS-$(CONFIG_IDE_SIL680) += sil680.o
 COBJS-$(CONFIG_SCSI_SYM53C8XX) += sym53c8xx.o
 COBJS-$(CONFIG_SYSTEMACE) += systemace.o
+COBJS-${CONFIG_SATA_LOOP} += sata_loopback.o
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/block/sata_loopback.c b/drivers/block/sata_loopback.c
new file mode 100644
index 000..600fbdc
--- /dev/null
+++ b/drivers/block/sata_loopback.c
@@ -0,0 +1,212 @@
+/*
+ * (C) Copyright 2012
+ * Pavel Herrmann 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const char revision[] = "0.0";
+static const char vendor[] = "SATA loopback";
+
+/* this will be auto-initialized to NULLs */
+static char *filenames[CONFIG_SYS_SATA_MAX_DEVICE];
+
+extern block_dev_desc_t sata_dev_desc[];
+
+static inline int range_check(int dev)
+{
+   return  (dev < 0) || (dev >= CONFIG_SYS_SATA_MAX_DEVICE);
+}
+
+int init_sata(int dev)
+{
+   block_dev_desc_t *pdev = &sata_dev_desc[dev];
+   int fd, old_fd;
+
+   if (range_check(dev)) {
+   printf("File index %d is out of range.\n", dev);
+   return -EINVAL;
+   }
+
+   if (filenames[dev])
+   fd = os_open(filenames[dev], OS_O_RDWR);
+   else
+   fd = -1;
+
+   old_fd = (long) pdev->priv;
+   /* This is ugly, but saves allocation for 1 int. */
+   pdev->priv = (void *) (long) fd;
+
+   if ((old_fd > 2) || (old_fd < 0))
+   os_close(old_fd);
+
+   return 0;
+}
+
+lbaint_t sata_read(int dev, lbaint_t start, lbaint_t blkcnt, void *buffer)
+{
+   block_dev_desc_t *pdev = &sata_dev_desc[dev];
+   int fd = (long) pdev->priv;
+   lbaint_t start_byte = ATA_SECT_SIZE * start;
+   lbaint_t length_byte = ATA_SECT_SIZE * blkcnt;
+   lbaint_t retval;
+
+   if (os_lseek(fd, start_byte, OS_SEEK_SET) != start_byte)
+   return -1;
+
+   retval = os_read(fd, buffer, length_byte);
+
+   return retval / ATA_SECT_SIZE;
+}
+
+lbaint_t sata_write(int dev, lbaint_t start, lbaint_t blkcnt, void *buffer)
+{
+   block_dev_desc_t *pdev = &sata_dev_desc[dev];
+   int fd = (long) pdev->priv;
+   lbaint_t start_byte = ATA_SECT_SIZE * start;
+   lbaint_t length_byte = ATA_SECT_SIZE * blkcnt;
+   lbaint_t retval;
+
+   if (os_lseek(fd, start_byte, OS_SEEK_SET) != start_byte)
+   return -1;
+
+   retval = os_write(fd, buffer, length_byte);
+
+   return retval / ATA_SECT_SIZE;
+}
+
+int scan_sata(int dev)
+{
+   block_dev_desc_t *pdev = &sata_dev_desc[dev];
+   int fd = (long) pdev->priv;
+   int namelen;
+   char *filename;
+   lbaint_t bytes = 0;
+
+   if (range_check(dev)) {
+   printf("File index %d is out of range.\n", dev);
+   return -EINVAL;
+   }
+
+   if (filenames[dev])
+   filename = filenames[dev];
+   else
+   filename = "";
+
+   memcpy(pdev->vendor, vendor, sizeof(vendor));
+   memcpy(pdev->revision, revision, sizeof(revision));
+   namelen = strlen(filename);
+
+   if (namelen > 20) {
+

Re: [U-Boot] gpt: GUID/UUID - GPT restoration - open questions

[Rob Herring]

On 08/24/2012 03:48 AM, Lukasz Majewski wrote:
> Hi Stephen,
> 
> I'm writing to you, since I've posted a patch series regarding GPT
> support for Samsung Trats board (you were on the CC).
> 
> e.g. http://patchwork.ozlabs.org/patch/179785/
> 
> I think, that we can cooperate to provide better EFI/GPT support.
> 
> In mine implementation the "gpt" command (with several sub commands) has
> been proposed
> - we can discuss if this is a correct way to go.
> 
> Moreover, at this patch series a "weak" GUID generator is implemented.
> For now it is "good enough", since I consider the restoration as an
> emergency situation.
> However,I wonder how can we provide better GUID (and in general random
> numbers pool) generator for u-boot.
> 
> 
> Maybe md5sum command can be used with some running clock (WDT, or
> system clock from u-boot start up) data to provide better entropy?
> 
> Any ideas?

The question I'm asking is why we need partition creation support in
u-boot in the first place? Next you need filesystem creation too?

Rob

> 
> Regards,
> Lukasz
> 
>> This patch series provides a new command - "gpt" for eMMC partition
>> table (in the GPT format) restoration and display.
>>
>> As a pre-work, some cleanup at the part_efi.c file was performed to 
>> remove custom macros and make GPT related structures more readable. 
>>
>> The GPT detailed description has been written to README.gpt file.
>>
>> Tested at:
>>  - Exynos4210 rev.1 - TRATS Samsung development board
>>
>> Lukasz Majewski (6):
>>   gpt:doc: GPT (GUID Partition Table) documentation
>>   gpt: Replace the leXX_to_int() calls with ones defined at
>> 
>>   gpt: Replacement of GPT structures members with ones indicating
>> endianness and size
>>   gpt: Support for GPT (GUID Partition Table) restoration
>>   gpt: Support for new "gpt" command
>>   gpt: Enable support for GPT partition table restoration at Samsung's
>> Trats
>>
>>  common/Makefile |1 +
>>  common/cmd_gpt.c|  182 ++
>>  disk/part_efi.c |  334
>> +--
>> disk/part_efi.h |   85 ++-- doc/README.gpt
>> |  199  include/configs/trats.h |   23
>> +++- include/part.h  |2 +
>>  7 files changed, 715 insertions(+), 111 deletions(-)
>>  create mode 100644 common/cmd_gpt.c
>>  create mode 100644 doc/README.gpt
>>
> 

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

Re: [U-Boot] [PATCH] mx31: Define default SoC input clock frequencies

[Stefano Babic]

On 21/08/2012 23:06, Benoît Thébaudeau wrote:
> Define default SoC input clock frequencies for i.MX31 in order to get rid of
> duplicated definitions.
> 
> Signed-off-by: Benoît Thébaudeau 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> Cc: Wolfgang Denk 
> Cc: Helmut Raiger 
> ---

Applied to u-boot-imx, thanks.

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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] MX28: SPI: Fix the DMA DCache race condition

[Stefano Babic]

On 01/09/2012 04:07, Marek Vasut wrote:
> This patch fixes dcache-related problem. The problem manifested
> when dcache was enabled and the following command issued twice:
> 
> mw 0x4200 0 0x4000 ; sf probe ; sf read 0x4200 0x0 0x1 ; sha1sum 
> 0x4200 0x1
> 
> The SHA1 checksum was correct during the first call. Yet with
> every subsequent call of the above command, it differed and was
> wrong.
> 
> It turns out this was because of a race condition. On the first
> time the command was called, no cacheline contained any data from
> the destination memory location. The DMA transfered data into the
> location and the cache above the location was invalidated. Then the
> checksum was computed, but that meant the data were loaded into data
> cache.
> 
> On any subsequent call, the DMA again transfered data into the same
> destination. Yet during the transfer, some of the DCache lines were
> evicted and written back into the main memory. Once the DMA transfer
> completed, the data cache was invalidated over the memory location as
> usual. But the data that were to be loaded back into the data cache
> by subsequent SHA1 checksuming were corrupted.
> 
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Otavio Salvador 
> Cc: Stefano Babic 
> ---

Applied to u-boot-imx, thanks.

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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] MX28: MMC: Avoid DMA DCache race condition

[Stefano Babic]

On 01/09/2012 04:18, Marek Vasut wrote:
> This patch prevents dcache-related problem. The problem manifested
> itself on the SPI driver, this is just a port to the MMC driver.
> 
> The scenario is the same. In case an "mmc read" is issued to a
> buffer which was written right before it and data cache is enabled,
> the cache eviction might happen during the DMA transfer into the
> buffer, therefore corrupting the buffer. Clear any cache lines that
> might contain the buffer to prevent such issue.
> 
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Otavio Salvador 
> Cc: Stefano Babic 
> ---

Applied to u-boot-imx, thanks.

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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] MX28: SPI: Fix the DMA chaining

[Stefano Babic]

On 01/09/2012 04:08, Marek Vasut wrote:
> It turns out that in order for the SPI DMA to properly support
> continuous transfers longer than 65280 bytes, there are some very
> important parts that were left out from the documentation.
> 
> Firstly, the XFER_SIZE register is not written with the whole length
> of a transfer, but is written by each and every chained descriptor
> with the length of the descriptors data buffer.
> 
> Next, unlike the demo code supplied by FSL, which only writes one PIO
> word per descriptor, this does not apply if the descriptors are chained,
> since the XFER_SIZE register must be written. Therefore, it is essential
> to use four PIO words, CTRL0, CMD0, CMD1, XFER_SIZE. CMD0 and CMD1 are
> written with zero, since they don't apply. The DMA programs the PIO words
> in an incrementing order, so four PIO words.
> 
> Finally, unlike the demo code supplied by FSL, the SSP_CTRL0_IGNORE_CRC
> must not be set during the whole transfer, but it must be set only on the
> last descriptor in the chain.
> 
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Otavio Salvador 
> Cc: Stefano Babic 
> ---


Applied to u-boot-imx, thanks.

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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/4] Board support and feature for LaCie devices

[Simon Guinot]

On Thu, Sep 06, 2012 at 11:25:23AM +0200, Simon Guinot wrote:
> Changes for v3:
>  - Rebased against u-boot-mv/master and u-boot-arm/master.
> 
> Changes for v2:
>  - Move board support and feature into a separate patch set.
>  - Move mach-types update into a separate patch.
> 
> Simon Guinot (4):
>   lacie_kw: add support for EFI partitions
>   ARM: add netspace_mini_v2 to mach-types.h
>   ARM: add support for Network Space v2 Lite and Mini
>   ARM: add support for d2 Network v2
> 
>  arch/arm/include/asm/mach-types.h |   13 +++
>  board/LaCie/common/common.c   |   36 ++-
>  board/LaCie/common/common.h   |1 +
>  board/LaCie/netspace_v2/kwbimage-ns2l.cfg |  162 
> +
>  board/LaCie/netspace_v2/netspace_v2.c |4 +
>  boards.cfg|3 +
>  include/configs/lacie_kw.h|   42 ++--
>  7 files changed, 252 insertions(+), 9 deletions(-)
>  create mode 100644 board/LaCie/netspace_v2/kwbimage-ns2l.cfg

Hi Albert and Prafulla,

I thinks I miss the point with this v3 patch series. I understand now,
I have to drop the patch: "ARM: add netspace_mini_v2 to mach-types.h"

The problem is that the boards netspace_mini_v2, and more recently
netspace_lite_v2, have been removed from the Linux mach-types file.
As a temporary solution, I could include the missing MACH_TYPE_
definitions to the header configs/lacie_kw.h.

Is that correct ? If yes, do you want me to resend the whole patch
series or just an update for the patch "ARM: add support for Network
Space v2 Lite and Mini" ?

Regards,

Simon

> 
> -- 
> 1.7.10


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] gpt: GUID/UUID - GPT restoration - open questions

[Lukasz Majewski]

Hi Stephen,

> On 08/24/2012 02:48 AM, Lukasz Majewski wrote:
> > Hi Stephen,
> > 
> > I'm writing to you, since I've posted a patch series regarding GPT
> > support for Samsung Trats board (you were on the CC).
> > 
> > e.g. http://patchwork.ozlabs.org/patch/179785/
> > 
> > I think, that we can cooperate to provide better EFI/GPT support.
> > 
> > In mine implementation the "gpt" command (with several sub
> > commands) has been proposed
> > - we can discuss if this is a correct way to go.
> > 
> > Moreover, at this patch series a "weak" GUID generator is
> > implemented. For now it is "good enough", since I consider the
> > restoration as an emergency situation.
> 
> I think that (perhaps optionally) allowing the user to specify their
> own UUIDs would be a good idea; whatever was generating the script
> being executed might have access to a better entropy source.

I think, that passing UUID as the command argument would be a better
option than inventing own GUID generator, especially when tools like
uuid were available.

> 
> > However,I wonder how can we provide better GUID (and in general
> > random numbers pool) generator for u-boot.
> > 
> > Maybe md5sum command can be used with some running clock (WDT, or
> > system clock from u-boot start up) data to provide better entropy?
> 
> If there's a standard way of retrieving wall-clock, MAC address, ...
> it'd definitely be a good idea to include those entropy sources.
> 

-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] [PATCH 4/6] gpt: Support for GPT (GUID Partition Table) restoration

[Lukasz Majewski]

Hi Stephen,

> On 08/24/2012 02:13 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,
> > +  int parts, unsigned int *blocks, char *name[]);
> 
> That interface seems very limiting; what if you want to select
> specific type UUIDs, set the partition attributes, leave gaps between
> the partitions, have the physical order of partitions (their block
> numbers) be different to the partition table ordering, etc.
> 
> I wonder if it wouldn't be better to take an array of structures here,
> and have each entry define all the properties of the partition. That
> would allow fields to be added to the structure to describe more
> information as we add more functionality.

I agree.

I'd propose following approach:

- set_gpt_table will receive a table with pointers to partition entries
  (up to 128 entries in this table). In this way one can easily define
  partition properties (which can be different for different
  commands/boards).

- I think, that Legacy MBR, and Primary/Secondary GPT shall be
  generated in the set_gpt_table function. However I expect a problem
  with one Primary/Secondary GPT field
  - the Disk GUID. We can read it from environment, generate it or
  hardcode it at ./include/boards/{target}.h


What is your opinion?

> 
> I didn't review the implementation.


-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] [PATCH 0/6] add zip command support for uboot

[Marek Vasut]

Dear Lukasz Majewski,

[...]

> > Ok, that means we can make use of this command ?
> 
> I cannot promise, that I will provide the "zip" support straightaway in
> the DFU.
> 
> On the one hand if DFU is the only user of this command we are adding in
> fact a "dead" code.
> On the other hand we can use proper #define CONFIG_CMD_ZIP to not
> compile it until we "really" use this.

I'd rather see a user and code added, not the other way.

> Are there any other potential "users" of this functionality (ZIP
> compression/decompression) in u-boot?

None that I know of. Is it really zip or is it gzip ?

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 0/6] add zip command support for uboot

[Lukasz Majewski]

Hi Marek,

> Dear Lukasz Majewski,
> 
> > Dear Marek and Lei,
> > 
> > > Dear Lei Wen,
> > > 
> > > > Hi Marek,
> > > > 
> > > > On Thu, Sep 6, 2012 at 12:18 PM, Marek Vasut
> > > > 
> > > >  wrote:
> > > > > Dear adrian.w...@gmail.com,
> > > > > 
> > > > >> From: Lei Wen 
> > > > > 
> > > > > Lei? Long time no see :)
> > > > 
> > > > Long time no see. :)
> > > 
> > > Yep, you're doing well?
> > > 
> > > > >> This patch set add zip command support for uboot.
> > > > >> The first two patches import deflate and trees functions from
> > > > >> zlib 1.2.5 without any change. While the third patch did the
> > > > >> necessary change to make the import file could be built
> > > > >> passed in uboot environment.
> > > > >> 
> > > > >> The fourth patch make us could zip the memory from 0 in the
> > > > >> address space.
> > > > >> 
> > > > >> The latter fifth and sixth patch does the adding gzip lib
> > > > >> function exporting and zip command support.
> > > > >> 
> > > > >> Patch set test with zip&unzip and compared with original
> > > > >> memory content.
> > > > >> 
> > > > >> Lei Wen (6):
> > > > >>   lib: zlib: import deflate source file from 1.2.5
> > > > >>   lib: zlib: import trees file from 1.2.5
> > > > >>   lib: zlib: include deflate into zlib build
> > > > >>   lib: zlib: remove the limitation for cannot using 0 as
> > > > >> start lib: add gzip lib function callback
> > > > >>   common: add zip command support
> > > > >>  
> > > > >>  common/Makefile   |1 +
> > > > >>  common/cmd_zip.c  |   60 ++
> > > > >>  include/common.h  |7 +
> > > > >>  include/u-boot/zlib.h |   40 +-
> > > > >>  lib/Makefile  |1 +
> > > > >>  lib/gzip.c|  143 
> > > > >>  lib/zlib/deflate.c| 1831
> > > > >> 
> > > > >> +
> > > > >> lib/zlib/deflate.h | 342 +
> > > > >> 
> > > > >>  lib/zlib/trees.c  | 1244
> > > > >> + lib/zlib/trees.h  |
> > > > >> 128  lib/zlib/zlib.c   |8 +
> > > > >>  lib/zlib/zutil.h  |4 +
> > > > >>  12 files changed, 3804 insertions(+), 5 deletions(-)
> > > > >>  create mode 100644 common/cmd_zip.c
> > > > >>  create mode 100644 lib/gzip.c
> > > > >>  create mode 100644 lib/zlib/deflate.c
> > > > >>  create mode 100644 lib/zlib/deflate.h
> > > > >>  create mode 100644 lib/zlib/trees.c
> > > > >>  create mode 100644 lib/zlib/trees.h
> > > > > 
> > > > > Are there any users for this code? What is it for ?
> > > > 
> > > > This patch was intended to compress the memory when uploading
> > > > through USB. So that uploaded image could be smaller.
> > > > Maybe there are some other usage, like memory testing?
> > > 
> > > CCing Lukasz, maybe he can find some use for this in the DFU
> > > series?
> > 
> > I think, that there is a possibility to gzip the host DFU data and
> > uncompress it after USB transmission (especially when "zip" command
> > is available from command line).
> 
> Ok, that means we can make use of this command ?

I cannot promise, that I will provide the "zip" support straightaway in
the DFU.

On the one hand if DFU is the only user of this command we are adding in
fact a "dead" code.
On the other hand we can use proper #define CONFIG_CMD_ZIP to not
compile it until we "really" use this.

Are there any other potential "users" of this functionality (ZIP
compression/decompression) in u-boot?

-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] [PATCH 3/6] gpt: Replacement of GPT structures members with ones indicating endianness and size

[Lukasz Majewski]

Hi Stephen,

> On 08/24/2012 02:13 AM, Lukasz Majewski wrote:
> > Replacement of several GPT related structures members with ones
> > indicating its endianness and proper size.
> 
> This patch seems reasonable to me, but I'm surprised it doesn't
> require /any/ changes to the code that uses these structures in order
> to avoid warnings/errors. Is git bisect maintained by this series?

As I've written for Patch 2/6, this patch will be merged with patch 2/6 

-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] [PATCH 2/6] gpt: Replace the leXX_to_int() calls with ones defined at

[Lukasz Majewski]

Hi Stephen,

> On 08/24/2012 02:13 AM, Lukasz Majewski wrote:
> > Custom definitions of le_XX_to_int functions have been replaced with
> > standard ones, defined at 
> > 
> > Signed-off-by: Chang Hyun Park 
> > Signed-off-by: Lukasz Majewski 
> > Signed-off-by: Kyungmin Park 
> 
> Did Chang Hyun Park write this? If so, shouldn't git have generated a
> "From" header for him, to reflect his authorship upstream. I'm not
> sure how Kyungmin Park's S-o-b plays into this, since he's not
> sending the patch.

My work (for those patches) was based on Mr. Chang Hyum Park patches.
However I had to modify his work for patches submission.

Therefore I've added Mr. Chang in a first place to credit his effort to
this patch series creation.

Shall I do it in a different way?

-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] [PATCH 2/6] gpt: Replace the leXX_to_int() calls with ones defined at

[Lukasz Majewski]

Hi Stephen,

> On 08/24/2012 02:13 AM, Lukasz Majewski wrote:
> > Custom definitions of le_XX_to_int functions have been replaced with
> > standard ones, defined at 
> 
> > diff --git a/disk/part_efi.c b/disk/part_efi.c
> 
> > -/* Convert char[8] in little endian format to the host format
> > integer
> > - */
> > -static inline unsigned long long le64_to_int(unsigned char *le64)
> > -{
> 
> So this original function takes a pointer to the value ...
> 
> > /* Check the first_usable_lba and last_usable_lba are
> > within the disk. */ lastlba = (unsigned long long)dev_desc->lba;
> > -   if (le64_to_int(pgpt_head->first_usable_lba) > lastlba) {
> > +   if (le64_to_cpu(pgpt_head->first_usable_lba) > lastlba) {
> 
> At this point in the series, first_usable_lba is a char[8], so this is
> passing the address of the first byte to both the original function
> le64_to_int(), and the replacement function le64_to_cpu(). However,
> le64_to_cpu() expects to receive the 64-bit value to swap, not a
> pointer to it - from compiler.h:
> 
> #define _uswap_64(x, sfx) \
> x) & 0xff00##sfx) >> 56) | \
> ...
> # define uswap_64(x) _uswap_64(x, ull)
> 
> le:
> # define le64_to_cpu(x) (x)
> be:
> # define le64_to_cpu(x) uswap_64(x)
> 
> So I think this patch breaks the code, and then the next patch fixes
> it, since it changes the type of first_usable_lba from char[8] to
> __le64?

First of all, thanks for very thorough review. 

You are right, my fault. Patch 2/6 and 3/6 shall be squashed together.
When squashed, no errors and warnings appear.

I've unnecessary separated them to show this two step change. For the
sake of bisecting - those shall be squashed. 


-- 
Best regards,

Lukasz Majewski

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

[U-Boot] [PATCH v3 4/4] ARM: add support for d2 Network v2

[Simon Guinot]

This patch adds support for the LaCie board d2 Network v2 which share
a lot of hardware caracteristics with the 2Big Network v2.

- CPU: Marvell 88F6281 1200Mhz
- SDRAM memory: 256MB DDR2 400Mhz
- 2 SATA ports: internal and eSATA
- Gigabit ethernet: PHY Marvell 88E1116R
- Flash memory: SPI NOR 512KB (Macronix MX25L4005A)
- i2c EEPROM: 512 bytes (24C04 type)
- 2 USB2 ports: host and host/device
- 1 push button
- 1 power switch
- 1 SATA LED (bi-color, blue and red)

Signed-off-by: Simon Guinot 
---
Changes for v3:
 - Rebased against u-boot-mv/master and u-boot-arm/master.

No changes for v2.

 boards.cfg |1 +
 include/configs/lacie_kw.h |   10 --
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index e4613a9..2c7d351 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -160,6 +160,7 @@ kmnusa   arm arm926ejs   km_arm 
 keymile
 mgcoge3unarm arm926ejs   km_arm  
keymilekirkwoodkm_kirkwood:KM_MGCOGE3UN
 kmcoge5unarm arm926ejs   km_arm  
keymilekirkwoodkm_kirkwood:KM_COGE5UN
 portl2   arm arm926ejs   km_arm  
keymilekirkwoodkm_kirkwood:KM_PORTL2
+d2net_v2 arm arm926ejs   net2big_v2  LaCie 
 kirkwoodlacie_kw:D2NET_V2
 inetspace_v2 arm arm926ejs   netspace_v2 LaCie 
 kirkwood   lacie_kw:INETSPACE_V2
 net2big_v2   arm arm926ejs   net2big_v2  LaCie 
 kirkwood   lacie_kw:NET2BIG_V2
 netspace_lite_v2 arm arm926ejs   netspace_v2 LaCie 
 kirkwood   lacie_kw:NETSPACE_LITE_V2
diff --git a/include/configs/lacie_kw.h b/include/configs/lacie_kw.h
index b00c352..3c0f838 100644
--- a/include/configs/lacie_kw.h
+++ b/include/configs/lacie_kw.h
@@ -36,6 +36,9 @@
 #elif defined(CONFIG_NETSPACE_MAX_V2)
 #define CONFIG_MACH_TYPE   MACH_TYPE_NETSPACE_MAX_V2
 #define CONFIG_IDENT_STRING" NS Max v2"
+#elif defined(CONFIG_D2NET_V2)
+#define CONFIG_MACH_TYPE   MACH_TYPE_D2NET_V2
+#define CONFIG_IDENT_STRING" D2 v2"
 #elif defined(CONFIG_NET2BIG_V2)
 #define CONFIG_MACH_TYPE   MACH_TYPE_NET2BIG_V2
 #define CONFIG_IDENT_STRING" 2Big v2"
@@ -106,7 +109,9 @@
 #define CONFIG_ENV_SPI_MAX_HZ   2000 /* 20Mhz */
 #define CONFIG_SYS_IDE_MAXBUS   1
 #define CONFIG_SYS_IDE_MAXDEVICE1
-#if defined(CONFIG_NET2BIG_V2)
+#if defined(CONFIG_D2NET_V2)
+#define CONFIG_SYS_PROMPT  "d2v2> "
+#elif defined(CONFIG_NET2BIG_V2)
 #define CONFIG_SYS_PROMPT  "2big2> "
 #else
 #define CONFIG_SYS_PROMPT  "ns2> "
@@ -126,7 +131,8 @@
  */
 #ifdef CONFIG_MVSATA_IDE
 #define CONFIG_SYS_ATA_IDE0_OFFSET  MV_SATA_PORT0_OFFSET
-#if defined(CONFIG_NETSPACE_MAX_V2) || defined(CONFIG_NET2BIG_V2)
+#if defined(CONFIG_NETSPACE_MAX_V2) || defined(CONFIG_D2NET_V2) || \
+   defined(CONFIG_NET2BIG_V2)
 #define CONFIG_SYS_ATA_IDE1_OFFSET  MV_SATA_PORT1_OFFSET
 #endif
 #endif /* CONFIG_MVSATA_IDE */
-- 
1.7.10

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

[U-Boot] [PATCH v3 3/4] ARM: add support for Network Space v2 Lite and Mini

[Simon Guinot]

This patch adds support for the LaCie boards Network Space v2 (Lite and
Mini). This two boards are derived from the Network Space v2 and a lot
of hardware caracteristics are shared.

- CPU: Marvell 88F6192 800Mhz
- SDRAM memory: 128MB DDR2 200Mhz
- 1 SATA port: internal
- Gigabit ethernet: PHY Marvell 88E1318
- Flash memory: SPI NOR 512KB (Macronix MX25L4005A)
- i2c EEPROM: 512 bytes (24C04 type)
- 2 USB2 ports (Lite only): host and host/device
- 1 push button
- 1 SATA LED (bi-color, blue and red)

Signed-off-by: Simon Guinot 
---
No changes for v3.

Changes for v2:
 - Move mach-types update into a separate patch.

 board/LaCie/common/common.c   |   36 ++-
 board/LaCie/common/common.h   |1 +
 board/LaCie/netspace_v2/kwbimage-ns2l.cfg |  162 +
 board/LaCie/netspace_v2/netspace_v2.c |4 +
 boards.cfg|2 +
 include/configs/lacie_kw.h|   26 -
 6 files changed, 224 insertions(+), 7 deletions(-)
 create mode 100644 board/LaCie/netspace_v2/kwbimage-ns2l.cfg

diff --git a/board/LaCie/common/common.c b/board/LaCie/common/common.c
index 78d0edc..a62bf9f 100644
--- a/board/LaCie/common/common.c
+++ b/board/LaCie/common/common.c
@@ -13,10 +13,11 @@
 
 #if defined(CONFIG_CMD_NET) && defined(CONFIG_RESET_PHY_R)
 
+#define MII_MARVELL_PHY_PAGE   22
+
 #define MV88E1116_LED_FCTRL_REG10
 #define MV88E1116_CPRSP_CR3_REG21
 #define MV88E1116_MAC_CTRL_REG 21
-#define MV88E1116_PGADR_REG22
 #define MV88E1116_RGMII_TXTM_CTRL  (1 << 4)
 #define MV88E1116_RGMII_RXTM_CTRL  (1 << 5)
 
@@ -31,15 +32,44 @@ void mv_phy_88e1116_init(const char *name, u16 phyaddr)
 * Enable RGMII delay on Tx and Rx for CPU port
 * Ref: sec 4.7.2 of chip datasheet
 */
-   miiphy_write(name, phyaddr, MV88E1116_PGADR_REG, 2);
+   miiphy_write(name, phyaddr, MII_MARVELL_PHY_PAGE, 2);
miiphy_read(name, phyaddr, MV88E1116_MAC_CTRL_REG, ®);
reg |= (MV88E1116_RGMII_RXTM_CTRL | MV88E1116_RGMII_TXTM_CTRL);
miiphy_write(name, phyaddr, MV88E1116_MAC_CTRL_REG, reg);
-   miiphy_write(name, phyaddr, MV88E1116_PGADR_REG, 0);
+   miiphy_write(name, phyaddr, MII_MARVELL_PHY_PAGE, 0);
 
if (miiphy_reset(name, phyaddr) == 0)
printf("88E1116 Initialized on %s\n", name);
 }
+
+void mv_phy_88e1318_init(const char *name, u16 phyaddr)
+{
+   u16 reg;
+
+   if (miiphy_set_current_dev(name))
+   return;
+
+   /*
+* Set control mode 4 for LED[0].
+*/
+   miiphy_write(name, phyaddr, MII_MARVELL_PHY_PAGE, 3);
+   miiphy_read(name, phyaddr, 16, ®);
+   reg |= 0xf;
+   miiphy_write(name, phyaddr, 16, reg);
+
+   /*
+* Enable RGMII delay on Tx and Rx for CPU port
+* Ref: sec 4.7.2 of chip datasheet
+*/
+   miiphy_write(name, phyaddr, MII_MARVELL_PHY_PAGE, 2);
+   miiphy_read(name, phyaddr, MV88E1116_MAC_CTRL_REG, ®);
+   reg |= (MV88E1116_RGMII_TXTM_CTRL | MV88E1116_RGMII_RXTM_CTRL);
+   miiphy_write(name, phyaddr, MV88E1116_MAC_CTRL_REG, reg);
+   miiphy_write(name, phyaddr, MII_MARVELL_PHY_PAGE, 0);
+
+   if (miiphy_reset(name, phyaddr) == 0)
+   printf("88E1318 Initialized on %s\n", name);
+}
 #endif /* CONFIG_CMD_NET && CONFIG_RESET_PHY_R */
 
 #if defined(CONFIG_CMD_I2C) && defined(CONFIG_SYS_I2C_EEPROM_ADDR)
diff --git a/board/LaCie/common/common.h b/board/LaCie/common/common.h
index 2edd5ab..85e433c 100644
--- a/board/LaCie/common/common.h
+++ b/board/LaCie/common/common.h
@@ -12,6 +12,7 @@
 
 #if defined(CONFIG_CMD_NET) && defined(CONFIG_RESET_PHY_R)
 void mv_phy_88e1116_init(const char *name, u16 phyaddr);
+void mv_phy_88e1318_init(const char *name, u16 phyaddr);
 #endif
 #if defined(CONFIG_CMD_I2C) && defined(CONFIG_SYS_I2C_EEPROM_ADDR)
 int lacie_read_mac_address(uchar *mac);
diff --git a/board/LaCie/netspace_v2/kwbimage-ns2l.cfg 
b/board/LaCie/netspace_v2/kwbimage-ns2l.cfg
new file mode 100644
index 000..d008eb0
--- /dev/null
+++ b/board/LaCie/netspace_v2/kwbimage-ns2l.cfg
@@ -0,0 +1,162 @@
+#
+# Copyright (C) 2011 Simon Guinot 
+#
+# Based on Kirkwood support:
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Prafulla Wadaskar 
+#
+# 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.
+#
+# Refer docs/README.kwimage for more details about how-to configu

[U-Boot] [PATCH v3 2/4] ARM: add netspace_mini_v2 to mach-types.h

[Simon Guinot]

This patch adds the Network Space Mini v2 machine to mach-types.h.

Signed-off-by: Simon Guinot 
---
No changes for v3.

 arch/arm/include/asm/mach-types.h |   13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/include/asm/mach-types.h 
b/arch/arm/include/asm/mach-types.h
index 2d5c3bc..36c108d 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -471,6 +471,7 @@ extern unsigned int __machine_arch_type;
 #define MACH_TYPE_EUKREA_CPUIMX35SD2821
 #define MACH_TYPE_EUKREA_CPUIMX51SD2822
 #define MACH_TYPE_EUKREA_CPUIMX51  2823
+#define MACH_TYPE_NETSPACE_MINI_V2 2831
 #define MACH_TYPE_SMDKC210 2838
 #define MACH_TYPE_OMAP3_BRAILLO2839
 #define MACH_TYPE_SPYPLUG  2840
@@ -6614,6 +6615,18 @@ extern unsigned int __machine_arch_type;
 # define machine_is_eukrea_cpuimx51()  (0)
 #endif
 
+#ifdef CONFIG_MACH_NETSPACE_MINI_V2
+# ifdef machine_arch_type
+#  undef machine_arch_type
+#  define machine_arch_type __machine_arch_type
+# else
+#  define machine_arch_type MACH_TYPE_NETSPACE_MINI_V2
+# endif
+# define machine_is_netspace_mini_v2()  (machine_arch_type == 
MACH_TYPE_NETSPACE_MINI_V2)
+#else
+# define machine_is_netspace_mini_v2()  (0)
+#endif
+
 #ifdef CONFIG_MACH_SMDKC210
 # ifdef machine_arch_type
 #  undef machine_arch_type
-- 
1.7.10

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

[U-Boot] [PATCH v3 1/4] lacie_kw: add support for EFI partitions

[Simon Guinot]

Defines CONFIG_EFI_PARTITION for LaCie boards.

Additionally this patch defines CONFIG_DOS_PARTITION. Note that this
definition is implicit in mv_common.h when CONFIG_CMD_USB is enabled.

Signed-off-by: Simon Guinot 
---
No changes for v2 and v3.

 include/configs/lacie_kw.h |6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/configs/lacie_kw.h b/include/configs/lacie_kw.h
index c35c2db..08aec04 100644
--- a/include/configs/lacie_kw.h
+++ b/include/configs/lacie_kw.h
@@ -130,6 +130,12 @@
 #endif /* CONFIG_CMD_I2C */
 
 /*
+ * Partition support
+ */
+#define CONFIG_DOS_PARTITION
+#define CONFIG_EFI_PARTITION
+
+/*
  * File systems support
  */
 #define CONFIG_CMD_EXT2
-- 
1.7.10

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

[U-Boot] [PATCH v3 0/4] Board support and feature for LaCie devices

[Simon Guinot]

Changes for v3:
 - Rebased against u-boot-mv/master and u-boot-arm/master.

Changes for v2:
 - Move board support and feature into a separate patch set.
 - Move mach-types update into a separate patch.

Simon Guinot (4):
  lacie_kw: add support for EFI partitions
  ARM: add netspace_mini_v2 to mach-types.h
  ARM: add support for Network Space v2 Lite and Mini
  ARM: add support for d2 Network v2

 arch/arm/include/asm/mach-types.h |   13 +++
 board/LaCie/common/common.c   |   36 ++-
 board/LaCie/common/common.h   |1 +
 board/LaCie/netspace_v2/kwbimage-ns2l.cfg |  162 +
 board/LaCie/netspace_v2/netspace_v2.c |4 +
 boards.cfg|3 +
 include/configs/lacie_kw.h|   42 ++--
 7 files changed, 252 insertions(+), 9 deletions(-)
 create mode 100644 board/LaCie/netspace_v2/kwbimage-ns2l.cfg

-- 
1.7.10

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

Re: [U-Boot] [PATCH 1/6] gpt:doc: GPT (GUID Partition Table) documentation

[Lukasz Majewski]

Hi Stephen,

> On 08/24/2012 02:13 AM, Lukasz Majewski wrote:
> > Documentation of the GPT table format.
> 
> > +++ b/doc/README.gpt
> 
> > +Glossary:
> > +
> > +- UUID -(Universally Unique Identifier)
> > +- GUID - (Globally Unique ID)
> > +- EFI - (Extensible Firmware Interface)
> > +- UEFI - (Unified EFI) - EFI evolution
> > +- GPT (GUID Page Table) - it is the EFI standard part
> 
> GUID Partition Table, not Page.
> 
> > +- partitions - lists of availavle partitions (defined at u-boot):
> > +  ./include/configs/{target}.h
> > +
> > +Introduction:
> > +=
> > +This document describes the GPT partition table format when used
> > with u-boot. +
> > +
> > +UUID introduction[5]:
> > +
> 
> What is "[5]"?
> 
> > +For instance, GUID of Linux data partition:
> > EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 +For u-boot GPT hyphens are
> > omitted.
> 
> I don't think U-Boot should omit any of the hyphens; it makes the
> UUIDs far more readable, and the strings can then be cut/paste
> to/from other applications that use/print UUIDs, without any manual
> conversion.
> 
> > +Historically there are 5 methods to generate this number. The
> > oldest one is +combining machine's MAC address and timer (epoch)
> > value. +
> > +Successive versions are using MD5 hash, random numbers and SHA-1
> > hash. All major +OSes and programming languages are providing
> > libraries to compute UUID. +
> > +However it costs in terms of the computational power and memory
> > footprint. +Therefore u-boot uses the crc32 with reading random
> > block (512B) from MMC +storage device to generate UUID/GUID.
> 
> That doesn't seem particularly relevant to general documentation about
> GPT; it's an implementation detail of the GPT creation command in a
> later patch, and could easily be changed.
> 
> In fact, I wonder why not require the user to concoct UUIDs and pass
> them to your GPT creation command, rather than forming them using some
> non-standard process.

I think that it is a good idea. User can use standard uuid command and
store its output as an environment variable.

> 
> > +GUID brief explanation:
> 
> Not "GUID", but "GPT".
> 
> > +==
> > +
> > +   Layout:
> > +   ---
> > +
> > +   --
> > +   LBA 0  |Protective MBR   |
> > +   --
> > +   LBA 1  |Primary GPT Header   | Primary
> > +   -- GPT
> > +   LBA 2  |Entry 1|Entry 2| Entry 3| Entry 4|
> > +   --
> > +   LBA 3  |Entries 5 - 128  |
> > +  | |
> > +  | |
> > +   ---
> > +   LBA 34  |Partition 1  |
> 
> The indentation looks inconsistent in this diagram

Strange, my emacs shows it correctly. I'll investigate the issue.
> 
> > +  | |
> > +  ---
> > +  |Partition 2  |
> > +  | |
> > +  ---
> > +  |Partition n  |
> > +  | |
> 
> > +   ---
> > +   LBA -34 |Entry 1|Entry 2| Entry 3| Entry 4|
> > Secondary
> > +   --- (bkp)
> > +   LBA 34  |Partition 1  |
> > +  | |
> > +  ---
> > +  |Partition 2  |
> > +  | |
> > +  ---
> > +  |Partition n  |
> > +  | |
> 
> That part of the diagram appears duplicated.
> 
> > +   ---
> > +   LBA -34 |Entry 1|Entry 2| Entry 3| Entry 4|
> > Secondary
> > +   --- (bkp)
> > +   LBA -33 |Entries 5 - 128  | GPT
> > +  | |
> > +  | |
> > +   LBA -2  | |
> > +   ---
> > +   LBA -1  |Secondary GPT Header |
> > +   ---
> > +
> 
> > +  Attribute flags (Don't used 

Re: [U-Boot] [PATCH v3 1/4] kirkwood: use c-struct for access to SDRAM addr decode registers

[Marek Vasut]

Dear Holger Brunck,

> Hi Prafulla,
> 
> On 07/20/2012 02:34 PM, Holger Brunck wrote:
> > Remove the defines and do this with a C-struct.
> > 
> > Signed-off-by: Holger Brunck 
> > cc: Prafulla Wadaskar 
> > cc: Valentin Longchamp 
> > cc: Gerlando Falauto 
> > cc: Marek Vasut 
> > ---
> > 
> > changes for v3:
> >   - new patch as requested on the ML
> >  
> >  arch/arm/cpu/arm926ejs/kirkwood/dram.c |   23 +--
> >  1 files changed, 17 insertions(+), 6 deletions(-)
> 
> I saw your pull request for the mavell git branch. This patch serie is not
> included in your branch but already reviewed and acked. Did you miss this
> serie?

I assigned it to PW in PW ( :-D ) and bumped his email.

> Regards
> Holger

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

Re: [U-Boot] ima3-mx53:Rename CONFIG_PRIME => CONFIG_ETHPRME, remove unused macro CONFIG_DISCOVER_PHY

[Stefano Babic]

On 05/09/2012 18:50, Ashok wrote:
> From 2d37e7db8adc529ce00e09158710292c3beffe94 Mon Sep 17 00:00:00 2001
> From: Ashok Kumar Reddy 
> Date: Wed, 5 Sep 2012 22:09:37 +0530
> Subject: [PATCH] ima3-mx53:Rename CONFIG_PRIME => CONFIG_ETHPRME, remove
>  unused macro CONFIG_DISCOVER_PHY
> 
> Signed-off-by: Ashok Kumar Reddy 
> ---
>  include/configs/ima3-mx53.h |3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/include/configs/ima3-mx53.h b/include/configs/ima3-mx53.h
> index 567061a..dbc59b9 100644
> --- a/include/configs/ima3-mx53.h
> +++ b/include/configs/ima3-mx53.h
> @@ -64,7 +64,6 @@
>  /* Ethernet on FEC */
>  #define CONFIG_NET_MULTI
>  #define CONFIG_MII
> -#define CONFIG_DISCOVER_PHY
> 
>  #define CONFIG_FEC_MXC
>  #define IMX_FEC_BASEFEC_BASE_ADDR
> @@ -72,7 +71,7 @@
>  #define CONFIG_PHY_ADDRCONFIG_FEC_MXC_PHYADDR
>  #define CONFIG_RESET_PHY_R
>  #define CONFIG_FEC_MXC_NO_ANEG
> -#define CONFIG_PRIME"FEC0"
> +#define CONFIG_ETHPRIME"FEC0"
> 
>  /* SPI */
>  #define CONFIG_HARD_SPI

Acked-by: Stefano Babic 

Thanks,
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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Fix mx31_decode_pll

[Stefano Babic]

On 14/08/2012 20:43, Benoît Thébaudeau wrote:
> The MFN bit-field of the PLL registers represents a signed value. See the
> reference manual.
> 
> Signed-off-by: Benoît Thébaudeau 
> Cc: Stefano Babic 
> ---

Applied to u-boot-imx, thanks.

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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] mx35: Fix decode_pll

[Stefano Babic]

On 14/08/2012 22:32, Benoît Thébaudeau wrote:
> The MFN bit-field of the PLL registers represents a signed value. See the
> reference manual.
> 
> Signed-off-by: Benoît Thébaudeau 
> Cc: Stefano Babic 
> ---

Applied to u-boot-imx, thanks.

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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mx25: Define default SoC input clock frequencies

[Stefano Babic]

On 21/08/2012 23:05, Benoît Thébaudeau wrote:
> Define default SoC input clock frequencies for i.MX25 in order to get rid of
> duplicated definitions.
> 
> Signed-off-by: Benoît Thébaudeau 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> Cc: Matthias Weisser 
> ---


Applied to u-boot-imx, thanks.

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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/7] mx35: Fix clock dividers

[Stefano Babic]

On 14/08/2012 22:33, Benoît Thébaudeau wrote:
> The clock dividers that were used do not match at all the reference manual. 
> They
> were either completely broken, or came from an early silicon revision
> incompatible with the current one.
> 
> Signed-off-by: Benoît Thébaudeau 
> Cc: Stefano Babic 
> ---

Applied to u-boot-imx, thanks.

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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/7] mx35: Add definitions for clock gate values

[Stefano Babic]

On 14/08/2012 22:33, Benoît Thébaudeau wrote:
> Signed-off-by: Benoît Thébaudeau 
> Cc: Stefano Babic 
> ---

Applied to u-boot-imx, thanks.

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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/7] mx35: Fix clock dividers

[Stefano Babic]

On 03/09/2012 17:55, Stefano Babic wrote:

> Yes, make this small change - then from my point of view I am ready to
> merge it.

Nevermind - this is really a detail. I prefer to fix soon the bugs.
Thanks for having discovered and fixed. I merge the series now.

Regards,
Stefano


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

Re: [U-Boot] [PATCH v3 1/4] kirkwood: use c-struct for access to SDRAM addr decode registers

[Holger Brunck]

Hi Prafulla,

On 07/20/2012 02:34 PM, Holger Brunck wrote:
> Remove the defines and do this with a C-struct.
> 
> Signed-off-by: Holger Brunck 
> cc: Prafulla Wadaskar 
> cc: Valentin Longchamp 
> cc: Gerlando Falauto 
> cc: Marek Vasut 
> ---
> changes for v3:
>   - new patch as requested on the ML
> 
>  arch/arm/cpu/arm926ejs/kirkwood/dram.c |   23 +--
>  1 files changed, 17 insertions(+), 6 deletions(-)
> 

I saw your pull request for the mavell git branch. This patch serie is not
included in your branch but already reviewed and acked. Did you miss this serie?

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

Re: [U-Boot] [PATCH 0/6] add zip command support for uboot

[Marek Vasut]

Dear Lukasz Majewski,

> Dear Marek and Lei,
> 
> > Dear Lei Wen,
> > 
> > > Hi Marek,
> > > 
> > > On Thu, Sep 6, 2012 at 12:18 PM, Marek Vasut
> > > 
> > >  wrote:
> > > > Dear adrian.w...@gmail.com,
> > > > 
> > > >> From: Lei Wen 
> > > > 
> > > > Lei? Long time no see :)
> > > 
> > > Long time no see. :)
> > 
> > Yep, you're doing well?
> > 
> > > >> This patch set add zip command support for uboot.
> > > >> The first two patches import deflate and trees functions from
> > > >> zlib 1.2.5 without any change. While the third patch did the
> > > >> necessary change to make the import file could be built passed
> > > >> in uboot environment.
> > > >> 
> > > >> The fourth patch make us could zip the memory from 0 in the
> > > >> address space.
> > > >> 
> > > >> The latter fifth and sixth patch does the adding gzip lib
> > > >> function exporting and zip command support.
> > > >> 
> > > >> Patch set test with zip&unzip and compared with original memory
> > > >> content.
> > > >> 
> > > >> Lei Wen (6):
> > > >>   lib: zlib: import deflate source file from 1.2.5
> > > >>   lib: zlib: import trees file from 1.2.5
> > > >>   lib: zlib: include deflate into zlib build
> > > >>   lib: zlib: remove the limitation for cannot using 0 as start
> > > >>   lib: add gzip lib function callback
> > > >>   common: add zip command support
> > > >>  
> > > >>  common/Makefile   |1 +
> > > >>  common/cmd_zip.c  |   60 ++
> > > >>  include/common.h  |7 +
> > > >>  include/u-boot/zlib.h |   40 +-
> > > >>  lib/Makefile  |1 +
> > > >>  lib/gzip.c|  143 
> > > >>  lib/zlib/deflate.c| 1831
> > > >> 
> > > >> +
> > > >> lib/zlib/deflate.h | 342 +
> > > >> 
> > > >>  lib/zlib/trees.c  | 1244 +
> > > >>  lib/zlib/trees.h  |  128 
> > > >>  lib/zlib/zlib.c   |8 +
> > > >>  lib/zlib/zutil.h  |4 +
> > > >>  12 files changed, 3804 insertions(+), 5 deletions(-)
> > > >>  create mode 100644 common/cmd_zip.c
> > > >>  create mode 100644 lib/gzip.c
> > > >>  create mode 100644 lib/zlib/deflate.c
> > > >>  create mode 100644 lib/zlib/deflate.h
> > > >>  create mode 100644 lib/zlib/trees.c
> > > >>  create mode 100644 lib/zlib/trees.h
> > > > 
> > > > Are there any users for this code? What is it for ?
> > > 
> > > This patch was intended to compress the memory when uploading
> > > through USB. So that uploaded image could be smaller.
> > > Maybe there are some other usage, like memory testing?
> > 
> > CCing Lukasz, maybe he can find some use for this in the DFU series?
> 
> I think, that there is a possibility to gzip the host DFU data and
> uncompress it after USB transmission (especially when "zip" command is
> available from command line).

Ok, that means we can make use of this command ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/2] Loop block device for sandbox

[Marek Vasut]

Dear Pavel Herrmann,

> On Thursday 06 of September 2012 03:08:42 Marek Vasut wrote:
> > Dear Pavel Herrmann,
> > 
> > > On Wednesday 05 of September 2012 14:48:40 Marek Vasut wrote:
> > > > Dear Pavel Herrmann,
> > > > 
> > > > [...]
> > > > 
> > > > > > besides, I think it'd be much systematic to just scream at user
> > > > > > to call "sata rescan" and bail out instead of doing it for him.
> > > > > 
> > > > > i dont actually need a sata rescan, i just need to make sure i have
> > > > > dynamically allocated names
> > > > 
> > > > Sorry, I can't parse this ... but ...
> > > > 
> > > > > , so i can safely call free() later, otherwise
> > > > > this segfaults when called before sata scan
> > > > 
> > > > The free() function frees the memory space pointed to by ptr, which
> > > > must have been returned by a previous call to malloc(), calloc() or
> > > > realloc().
> > > > Otherwise, or if free(ptr) has already been called before, undefined
> > > > behavior  occurs. If ptr is NULL, no operation is performed.
> > > > 
> > > > So if you call free() on null pointer, nothing happens. Where's the
> > > > real problem?
> > > 
> > > if you called "sata init" before setting all the loops you would get to
> > > open(NULL) and a strlen(NULL). i think its easier to supply valid empty
> > > string then check for NULL at every access.
> > 
> > I'd say check for null on every access ... you'd lower memory
> > requirements and the increase in code requirement should really be very
> > minor. Also, it'd remove the "zeroed" static variable altogether,
> > correct?
> 
> OK, fine by me
> 
> > > > > > Make this "info" part mandatory. Than you can cut the whole argc
> > > > > > loop
> > > > > > into simple "if argc != 2 ; then fail" . And do simple checking
> > > > > > for the first letter of the argument being either i or d .
> > > > > 
> > > > > wont help, still need argc 3 or 4
> > > > 
> > > > Makes is simpler, you can bail out if it's not 3 or 4
> > > 
> > > still, i should have a "sata_loop info" work on all files, so theres a
> > > valid command with argc 2
> > 
> > Understood.
> > 
> > > > > > > + "sata_loop load devnum file - load file from host FS into
> > > > > > > loop devnum"
> > > > > > 
> > > > > > sata_loop is redundant above.
> > > > > 
> > > > > really? how do you figure?
> > > > 
> > > > Run "help sata_loop" and see the result ...
> > > 
> > > =>help sata_loop
> > > sata_loop - SATA loopback
> > > 
> > > Usage:
> > > sata_loop [info] devnum - show info about loop devnum
> > > sata_loop load devnum file - load file from host FS into loop devnum
> > > 
> > > i dont see your problem
> > 
> > Ewww ... nevermind ... I just detected yet another stupid issue in the
> > codebase. I'd say this "sata_loop" should be either omitted and filled by
> > the macro or something. But that's for other time to solve ... so I'm
> > fine with this now.
> 
> it actually is, but only to the first line (as both lines are in one
> string). In my opinion it should either add this for each line (with some
> magic string modification) or none at all, to keep it consistent

Keep it as is now, but it's something that should eventually be resolved.

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

Re: [U-Boot] [PATCH v3 1/2] Loop block device for sandbox

[Pavel Herrmann]

On Thursday 06 of September 2012 03:08:42 Marek Vasut wrote:
> Dear Pavel Herrmann,
> 
> > On Wednesday 05 of September 2012 14:48:40 Marek Vasut wrote:
> > > Dear Pavel Herrmann,
> > > 
> > > [...]
> > > 
> > > > > besides, I think it'd be much systematic to just scream at user to
> > > > > call "sata rescan" and bail out instead of doing it for him.
> > > > 
> > > > i dont actually need a sata rescan, i just need to make sure i have
> > > > dynamically allocated names
> > > 
> > > Sorry, I can't parse this ... but ...
> > > 
> > > > , so i can safely call free() later, otherwise
> > > > this segfaults when called before sata scan
> > > 
> > > The free() function frees the memory space pointed to by ptr, which must
> > > have been returned by a previous call to malloc(), calloc() or
> > > realloc().
> > > Otherwise, or if free(ptr) has already been called before, undefined
> > > behavior  occurs. If ptr is NULL, no operation is performed.
> > > 
> > > So if you call free() on null pointer, nothing happens. Where's the real
> > > problem?
> > 
> > if you called "sata init" before setting all the loops you would get to
> > open(NULL) and a strlen(NULL). i think its easier to supply valid empty
> > string then check for NULL at every access.
> 
> I'd say check for null on every access ... you'd lower memory requirements
> and the increase in code requirement should really be very minor. Also,
> it'd remove the "zeroed" static variable altogether, correct?

OK, fine by me

> > > > > Make this "info" part mandatory. Than you can cut the whole argc
> > > > > loop
> > > > > into simple "if argc != 2 ; then fail" . And do simple checking for
> > > > > the first letter of the argument being either i or d .
> > > > 
> > > > wont help, still need argc 3 or 4
> > > 
> > > Makes is simpler, you can bail out if it's not 3 or 4
> > 
> > still, i should have a "sata_loop info" work on all files, so theres a
> > valid command with argc 2
> 
> Understood.
> 
> > > > > > +   "sata_loop load devnum file - load file from host FS into loop
> > > > > > devnum"
> > > > > 
> > > > > sata_loop is redundant above.
> > > > 
> > > > really? how do you figure?
> > > 
> > > Run "help sata_loop" and see the result ...
> > 
> > =>help sata_loop
> > sata_loop - SATA loopback
> > 
> > Usage:
> > sata_loop [info] devnum - show info about loop devnum
> > sata_loop load devnum file - load file from host FS into loop devnum
> > 
> > i dont see your problem
> 
> Ewww ... nevermind ... I just detected yet another stupid issue in the
> codebase. I'd say this "sata_loop" should be either omitted and filled by
> the macro or something. But that's for other time to solve ... so I'm fine
> with this now.

it actually is, but only to the first line (as both lines are in one string). 
In my opinion it should either add this for each line (with some magic string 
modification) or none at all, to keep it consistent


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

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

[Albert ARIBAUD]

Hi Prafulla, Simon,

On Wed, 5 Sep 2012 18:21:47 -0700, Prafulla Wadaskar
 wrote:

> 
> 
> > -Original Message-
> > From: Simon Guinot [mailto:simon.gui...@sequanux.org]
> > Sent: 05 September 2012 12:57
> > To: Prafulla Wadaskar
> > Cc: Albert ARIBAUD; 'u-boot@lists.denx.de'; 'wolfg...@theia.denx.de;
> > Ashish Karkare; Prabhanjan Sarnaik
> > Subject: Re: [U-Boot] Pull request for u-boot-marvell.git
> > 
> > On Mon, Sep 03, 2012 at 02:20:19AM -0700, Prafulla Wadaskar wrote:
> > > Dear Albert,
> > >
> > > Please pull
> > > The following changes since commit
> > 6e2fbdea1b26d75314d87c380a36b0015bf824cf:
> > >   Wolfgang Denk (1):
> > > Merge branch 'ag...@denx.de' of git://git.denx.de/u-boot-
> > staging
> > 
> > Hi Prafulla,
> > 
> > Do you have some news about the board patches I sent you in early
> > June ?
> > 
> > Here are the patchwork urls:
> > http://patchwork.ozlabs.org/patch/163192/
> 
> This looks Okay
> 
> > http://patchwork.ozlabs.org/patch/163193/
> 
> This change should go differently, ARM Maintainer should pull
> mach_types, we cannot modify this file locally.

I will do the Linux machine type pulling (including clean up of any
board configs if their locally defined machine type is now part of the
Linux list) and warn board maintainers about dropped machine types if
any.

> > http://patchwork.ozlabs.org/patch/163195/
> 
> > http://patchwork.ozlabs.org/patch/163194/
> > 
> > Thanks in advance.
> 
> Hi Simon
> Thanks for pointing this out,
> I will pull them, but I doubt they will be applicable on latest
> u-boot, may you please confirm?
> 
> Or it would be good if you can repost new patch series.

... rebased on u-boot-arm/master.

> Regards...
> Prafulla . . .

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

[U-Boot] [PATCH] at91sam9x5: set default EBI I/O drive configuration.

[Josh Wu]

This patch configure at91sam9x5's EBI drive I/O. Without this, When SD card 
boot, the nand flash read/write are not stable. Which will cause kernel MTD 
test fail (Since mainline kernel doesn't configure the EBI register).

Signed-off-by: Josh Wu 
---
 board/atmel/at91sam9x5ek/at91sam9x5ek.c |4 
 1 file changed, 4 insertions(+)

diff --git a/board/atmel/at91sam9x5ek/at91sam9x5ek.c 
b/board/atmel/at91sam9x5ek/at91sam9x5ek.c
index ae408bc..06028aa 100644
--- a/board/atmel/at91sam9x5ek/at91sam9x5ek.c
+++ b/board/atmel/at91sam9x5ek/at91sam9x5ek.c
@@ -62,6 +62,10 @@ static void at91sam9x5ek_nand_hw_init(void)
csa |= AT91_MATRIX_EBI_CS3A_SMC_SMARTMEDIA;
/* NAND flash on D16 */
csa |= AT91_MATRIX_NFD0_ON_D16;
+
+   /* Configure IO drive */
+   csa &= ~AT91_MATRIX_EBI_EBI_IOSR_NORMAL;
+
writel(csa, &matrix->ebicsa);
 
/* Configure SMC CS3 for NAND/SmartMedia */
-- 
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 0/6] add zip command support for uboot

[Lukasz Majewski]

Dear Marek and Lei,

> Dear Lei Wen,
> 
> > Hi Marek,
> > 
> > On Thu, Sep 6, 2012 at 12:18 PM, Marek Vasut
> >  wrote:
> > > Dear adrian.w...@gmail.com,
> > > 
> > >> From: Lei Wen 
> > > 
> > > Lei? Long time no see :)
> > 
> > Long time no see. :)
> 
> Yep, you're doing well?
> 
> > >> This patch set add zip command support for uboot.
> > >> The first two patches import deflate and trees functions from
> > >> zlib 1.2.5 without any change. While the third patch did the
> > >> necessary change to make the import file could be built passed
> > >> in uboot environment.
> > >> 
> > >> The fourth patch make us could zip the memory from 0 in the
> > >> address space.
> > >> 
> > >> The latter fifth and sixth patch does the adding gzip lib
> > >> function exporting and zip command support.
> > >> 
> > >> Patch set test with zip&unzip and compared with original memory
> > >> content.
> > >> 
> > >> Lei Wen (6):
> > >>   lib: zlib: import deflate source file from 1.2.5
> > >>   lib: zlib: import trees file from 1.2.5
> > >>   lib: zlib: include deflate into zlib build
> > >>   lib: zlib: remove the limitation for cannot using 0 as start
> > >>   lib: add gzip lib function callback
> > >>   common: add zip command support
> > >>  
> > >>  common/Makefile   |1 +
> > >>  common/cmd_zip.c  |   60 ++
> > >>  include/common.h  |7 +
> > >>  include/u-boot/zlib.h |   40 +-
> > >>  lib/Makefile  |1 +
> > >>  lib/gzip.c|  143 
> > >>  lib/zlib/deflate.c| 1831
> > >> 
> > >> +
> > >> lib/zlib/deflate.h | 342 +
> > >> 
> > >>  lib/zlib/trees.c  | 1244 +
> > >>  lib/zlib/trees.h  |  128 
> > >>  lib/zlib/zlib.c   |8 +
> > >>  lib/zlib/zutil.h  |4 +
> > >>  12 files changed, 3804 insertions(+), 5 deletions(-)
> > >>  create mode 100644 common/cmd_zip.c
> > >>  create mode 100644 lib/gzip.c
> > >>  create mode 100644 lib/zlib/deflate.c
> > >>  create mode 100644 lib/zlib/deflate.h
> > >>  create mode 100644 lib/zlib/trees.c
> > >>  create mode 100644 lib/zlib/trees.h
> > > 
> > > Are there any users for this code? What is it for ?
> > 
> > This patch was intended to compress the memory when uploading
> > through USB. So that uploaded image could be smaller.
> > Maybe there are some other usage, like memory testing?
> 
> CCing Lukasz, maybe he can find some use for this in the DFU series?
> 

I think, that there is a possibility to gzip the host DFU data and
uncompress it after USB transmission (especially when "zip" command is
available from command line).

> > > Best regards,
> > > Marek Vasut
> > 
> > Thanks,
> > Lei
> 
> Best regards,
> Marek Vasut


-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] [PATCH v4 1/2] i2c:soft:multi: Support for multiple soft I2C buses at Samsung boards

[Lukasz Majewski]

Hi Heiko,

Thanks for comments.

> Hello Lukasz,
> 
> On 05.09.2012 11:15, Lukasz Majewski wrote:
> > Support for multiple soft I2C buses.
> >
> > Multibus I2C support is achieved by defining get_multi_{sda|scl}_pin
> > functions to switch between multiple "soft" I2C buses.
> >
> > Common definition of I2C_X I2C buses is provided at.
> >
> > TEST HW:
> >   Samsung's Exynos4210 evt.0.1 - Trats development board
> >
> > Signed-off-by: Lukasz Majewski
> > Signed-off-by: Kyungmin Park
> > Cc: Heiko Schocher
> > Cc: Minkyu Kang
> >
> > ---
> > Changes for v2:
> > - Common Samsung code has been put to
> > board/samsung/common/multi_i2c.c file
> > - I2C_{4|5} have been renamed to I2C_{0|1}
> > - *soft_i2c_name[] table has been removed
> > Changes for v3:
> > - None
> > Changes for v4:
> > - Common definitions of available I2C buses are now defined
> > at
> > - Compatibility layer (I2C_0) has been added temporarily to not
> > break the Trats I2C communication with PMIC. It will be removed
> > when redesigned PMIC will be posted
> > ---
> >   board/samsung/common/Makefile|   43 +
> >   board/samsung/common/multi_i2c.c |   65
> > ++
> > include/i2c.h|   12 +++ 3 files changed,
> > 120 insertions(+), 0 deletions(-) create mode 100644
> > board/samsung/common/Makefile create mode 100644
> > board/samsung/common/multi_i2c.c
> >
> [...]
> > +#
> > diff --git a/board/samsung/common/multi_i2c.c
> > b/board/samsung/common/multi_i2c.c new file mode 100644
> > index 000..d6c3d37
> > --- /dev/null
> > +++ b/board/samsung/common/multi_i2c.c
> > @@ -0,0 +1,65 @@
> [...]
> > +/* Handle multiple I2C buses instances */
> > +int get_multi_scl_pin(void)
> > +{
> > +   unsigned int bus = I2C_GET_BUS();
> > +
> > +   switch (bus) {
> > +   case I2C_0: /* I2C_0 definition - compatibility layer */
> > +   case I2C_5:
> 
> Is this correct, that you want to use 2 i2c busses on the same pin?

Yes, this is correct.

Let me share with you the "master" plan for this.
The I2C_0 is needed to keep the TRATS working with current PMIC
implementation. 

I'm working on redesign of current PMIC implementation to support other
devices responsible for power management (e.g. fuel gauge, charger,
PMIC), which in case of TRATS are connected via multiple I2C buses
(I2C_5 and I2C_9).

The I2C_0 case is for preserving correct operation of TRATS board until
PMIC 2.0 wont be introduced to u-boot mailing list. 

It will be removed just after PMIC 2.0 acceptance.

I hope, that I've expressed my intentions clearly.

> 
> Beside of that, you get my:
> 
> Acked-by: Heiko Schocher 
> 
> bye,
> Heiko

-- 
Best regards,

Lukasz Majewski

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

[U-Boot] [NEXT PATCH v1 7/7] MX35: add support for woodburn board

[Stefano Babic]

The woodburn board is based on the MX35 SOC.
Support for both external (NOR) and internal
(SD Card) boot mode are added. It uses the
generic SPL framework to implement the internal boot
mode.

The following peripherals are supported:
- Ethernet (FEC)
- SD Card
- NAND (16 Gb)
- NOR Flash

In the internal boot mode, a simple imximage header
file is generated to set the address in internal RAM
where the SOC must copy the SPL code. The initial setup
is then demanded to the SPL itself.

Signed-off-by: Stefano Babic 
---
 MAINTAINERS|1 +
 arch/arm/include/asm/arch-mx35/sys_proto.h |2 +
 board/woodburn/Makefile|   43 
 board/woodburn/imximage.cfg|4 +
 board/woodburn/lowlevel_init.S |   93 
 board/woodburn/mx35_sdram.c|  137 
 board/woodburn/woodburn.c  |  240 +
 boards.cfg |2 +
 include/configs/woodburn.h |   33 +++
 include/configs/woodburn_common.h  |  322 
 include/configs/woodburn_sd.h  |   65 ++
 11 files changed, 942 insertions(+)
 create mode 100644 board/woodburn/Makefile
 create mode 100644 board/woodburn/imximage.cfg
 create mode 100644 board/woodburn/lowlevel_init.S
 create mode 100644 board/woodburn/mx35_sdram.c
 create mode 100644 board/woodburn/woodburn.c
 create mode 100644 include/configs/woodburn.h
 create mode 100644 include/configs/woodburn_common.h
 create mode 100644 include/configs/woodburn_sd.h

diff --git a/MAINTAINERS b/MAINTAINERS
index c5a6f2f..f6ee8d1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -585,6 +585,7 @@ Stefano Babic 
trizepsiv   xscale/pxa
twister omap3
vision2 i.MX51
+   woodburni.MX35
 
 Jason Liu 
 
diff --git a/arch/arm/include/asm/arch-mx35/sys_proto.h 
b/arch/arm/include/asm/arch-mx35/sys_proto.h
index 422eb52..887f74b 100644
--- a/arch/arm/include/asm/arch-mx35/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx35/sys_proto.h
@@ -25,6 +25,8 @@
 #define _SYS_PROTO_H_
 
 u32 get_cpu_rev(void);
+void mx3_setup_sdram_bank(u32 start_address, u32 ddr2_config,
+   u32 row, u32 col, u32 dsize, u32 refresh);
 #define is_soc_rev(rev)((get_cpu_rev() & 0xFF) - rev)
 void sdelay(unsigned long);
 
diff --git a/board/woodburn/Makefile b/board/woodburn/Makefile
new file mode 100644
index 000..09caf63
--- /dev/null
+++ b/board/woodburn/Makefile
@@ -0,0 +1,43 @@
+#
+# Copyright (C) 2007, Guennadi Liakhovetski 
+#
+# (C) Copyright 2008-2009 Freescale Semiconductor, Inc.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := woodburn.o mx35_sdram.o
+SOBJS  := lowlevel_init.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/woodburn/imximage.cfg b/board/woodburn/imximage.cfg
new file mode 100644
index 000..b4cc8ec
--- /dev/null
+++ b/board/woodburn/imximage.cfg
@@ -0,0 +1,4 @@
+BOOT_FROM  sd
+
+# DDR2 init
+DATA 4 0xB8001010 0x0304
diff --git a/board/woodburn/lowlevel_init.S b/board/woodburn/lowlevel_init.S
new file mode 100644
index 000..e8f2dd3
--- /dev/null
+++ b/board/woodburn/lowlevel_init.S
@@ -0,0 +1,93 @@
+/*
+ * Copyright (C) 2007, Guennadi Liakhovetski 
+ *
+ * (C) Copyright 2008-2010 Freescale Semiconductor, Inc.
+ *
+ * Copyright (C) 2011, Stefano Babic 
+ *
+ * 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

[U-Boot] [NEXT PATCH v1 5/7] SPL: Added MLO for mx35 SOC to SPL Makefile

[Stefano Babic]

Signed-off-by: Stefano Babic 
---
 spl/Makefile |6 ++
 1 file changed, 6 insertions(+)

diff --git a/spl/Makefile b/spl/Makefile
index f96c08e..77fc405 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -109,6 +109,12 @@ $(OBJTREE)/MLO:$(obj)u-boot-spl.bin
-a $(CONFIG_SPL_TEXT_BASE) -d $< $@
 endif
 
+ifneq ($(CONFIG_IMX_CONFIG),)
+$(OBJTREE)/MLO:$(obj)u-boot-spl.bin
+   $(OBJTREE)/tools/mkimage -n  $(SRCTREE)/$(CONFIG_IMX_CONFIG) -T 
imximage \
+   -e $(CONFIG_SPL_TEXT_BASE) -d $< $@
+endif
+
 ALL-y  += $(obj)u-boot-spl.bin
 
 ifdef CONFIG_SAMSUNG
-- 
1.7.9.5

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

[U-Boot] [NEXT PATCH v1 4/7] MX35: Add soc_boot_mode and soc_boot_device to MX35

[Stefano Babic]

The functions are required to use the generic
SPL Framework.

Signed-off-by: Stefano Babic 
---
 arch/arm/cpu/arm1136/mx35/generic.c   |   80 +
 arch/arm/cpu/arm1136/u-boot-spl.lds   |   62 +++
 arch/arm/include/asm/arch-mx35/mmc_host_def.h |   31 ++
 arch/arm/include/asm/arch-mx35/spl.h  |   38 
 4 files changed, 211 insertions(+)
 create mode 100644 arch/arm/cpu/arm1136/u-boot-spl.lds
 create mode 100644 arch/arm/include/asm/arch-mx35/mmc_host_def.h
 create mode 100644 arch/arm/include/asm/arch-mx35/spl.h

diff --git a/arch/arm/cpu/arm1136/mx35/generic.c 
b/arch/arm/cpu/arm1136/mx35/generic.c
index 986b1f9..8fbe09b 100644
--- a/arch/arm/cpu/arm1136/mx35/generic.c
+++ b/arch/arm/cpu/arm1136/mx35/generic.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define CLK_CODE(arm, ahb, sel) (((arm) << 16) + ((ahb) << 8) + (sel))
 #define CLK_CODE_ARM(c)(((c) >> 16) & 0xFF)
@@ -488,3 +489,82 @@ void reset_cpu(ulong addr)
struct wdog_regs *wdog = (struct wdog_regs *)WDOG_BASE_ADDR;
writew(4, &wdog->wcr);
 }
+
+#define RCSR_MEM_CTL_WEIM  0
+#define RCSR_MEM_CTL_NAND  1
+#define RCSR_MEM_CTL_SD2
+#define RCSR_MEM_TYPE_NOR  0
+#define RCSR_MEM_TYPE_ONENAND  2
+#define RCSR_MEM_TYPE_SD   0
+#define RCSR_MEM_TYPE_I2C  2
+#define RCSR_MEM_TYPE_SPI  3
+
+u32 spl_boot_device(void)
+{
+   puts("spl_boot_device\n");
+   struct ccm_regs *ccm =
+   (struct ccm_regs *)IMX_CCM_BASE;
+
+#if 1
+   return BOOT_DEVICE_MMC1;
+#endif
+
+   u32 rcsr = readl(&ccm->rcsr);
+   u32 mem_type, mem_ctl;
+
+   /* In external mode, no boot device is returned */
+   if ((rcsr >> 10) & 0x03)
+   return BOOT_DEVICE_NONE;
+
+   mem_ctl = (rcsr >> 25) & 0x03;
+   mem_type = (rcsr >> 23) & 0x03;
+
+   switch (mem_ctl) {
+   case RCSR_MEM_CTL_WEIM:
+   switch (mem_type) {
+   case RCSR_MEM_TYPE_NOR:
+   return BOOT_DEVICE_NOR;
+   case RCSR_MEM_TYPE_ONENAND:
+   return BOOT_DEVICE_ONE_NAND;
+   default:
+   return BOOT_DEVICE_NONE;
+   }
+   case RCSR_MEM_CTL_NAND:
+   return BOOT_DEVICE_NAND;
+   case RCSR_MEM_CTL_SD:
+   switch (mem_type) {
+   case RCSR_MEM_TYPE_SD:
+   return BOOT_DEVICE_MMC1;
+   case RCSR_MEM_TYPE_I2C:
+   return BOOT_DEVICE_I2C;
+   case RCSR_MEM_TYPE_SPI:
+   return BOOT_DEVICE_SPI;
+   default:
+   return BOOT_DEVICE_NONE;
+   }
+   }
+
+   return BOOT_DEVICE_NONE;
+}
+
+#ifdef CONFIG_SPL_BUILD
+u32 spl_boot_mode(void)
+{
+   puts("spl_boot_mode\n");
+   switch (spl_boot_device()) {
+   case BOOT_DEVICE_MMC1:
+#ifdef CONFIG_SPL_FAT_SUPPORT
+   return MMCSD_MODE_FAT;
+#else
+   return MMCSD_MODE_RAW;
+#endif
+   break;
+   case BOOT_DEVICE_NAND:
+   return 0;
+   break;
+   default:
+   puts("spl: ERROR:  unsupported device\n");
+   hang();
+   }
+}
+#endif
diff --git a/arch/arm/cpu/arm1136/u-boot-spl.lds 
b/arch/arm/cpu/arm1136/u-boot-spl.lds
new file mode 100644
index 000..a0462ab
--- /dev/null
+++ b/arch/arm/cpu/arm1136/u-boot-spl.lds
@@ -0,0 +1,62 @@
+/*
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering, 
+ *
+ * (C) Copyright 2010
+ * Texas Instruments, 
+ * Aneesh V 
+ *
+ * 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
+ */
+
+MEMORY { .sram : ORIGIN = CONFIG_SPL_TEXT_BASE,\
+   LENGTH = CONFIG_SPL_MAX_SIZE }
+MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR, \
+   LENGTH = CONFIG_SPL_BSS_MAX_SIZE }
+
+OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
+OUTPUT_ARCH(arm)
+ENTRY(_start)
+SECTIONS
+{
+   .text  :
+   {
+   __start = .;
+ arch/arm/cpu/arm1136/start.o  (.text)
+ *(.text*)
+   } >.sram
+
+   . = ALIGN(4);
+   .r

[U-Boot] [NEXT PATCH v1 6/7] ARM: Add MLO target to arm1136

[Stefano Babic]

Signed-off-by: Stefano Babic 
---
 arch/arm/cpu/arm1136/config.mk |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/cpu/arm1136/config.mk b/arch/arm/cpu/arm1136/config.mk
index efee0d1..a6c1178 100644
--- a/arch/arm/cpu/arm1136/config.mk
+++ b/arch/arm/cpu/arm1136/config.mk
@@ -31,3 +31,6 @@ PLATFORM_CPPFLAGS += -march=armv5
 # =
 PF_RELFLAGS_SLB_AT := $(call cc-option,-mshort-load-bytes,$(call 
cc-option,-malignment-traps,))
 PLATFORM_RELFLAGS += $(PF_RELFLAGS_SLB_AT)
+ifdef CONFIG_SPL_BUILD
+ALL-y  += $(OBJTREE)/MLO
+endif
-- 
1.7.9.5

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

[U-Boot] [NEXT PATCH v1 3/7] MX35: add LOW_LEVEL_SRAM_STACK to use SPL_FRAMEWORK

[Stefano Babic]

Signed-off-by: Stefano Babic 
---
 arch/arm/include/asm/arch-mx35/imx-regs.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx35/imx-regs.h 
b/arch/arm/include/asm/arch-mx35/imx-regs.h
index 3146006..6cd6460 100644
--- a/arch/arm/include/asm/arch-mx35/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx35/imx-regs.h
@@ -31,6 +31,8 @@
 #define IRAM_BASE_ADDR 0x1000  /* internal ram */
 #define IRAM_SIZE  0x0002  /* 128 KB */
 
+#define LOW_LEVEL_SRAM_STACK   0x1001E000
+
 /*
  * AIPS 1
  */
-- 
1.7.9.5

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

[U-Boot] [NEXT PATCH v1 2/7] NAND: added NAND type to nand_ids

[Stefano Babic]

Signed-off-by: Stefano Babic 
---
 drivers/mtd/nand/nand_ids.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 3953549..fe75686 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -131,6 +131,8 @@ const struct nand_flash_dev nand_flash_ids[] = {
/* 128 Gigabit */
{"NAND 16GiB 1,8V 8-bit",   0x1A, 0, 16384, 0, LP_OPTIONS},
{"NAND 16GiB 3,3V 8-bit",   0x3A, 0, 16384, 0, LP_OPTIONS},
+   {"NAND 16GiB 3,3V 8-bit",   0x48, 4096, 16384, 0x10,
+   LP_OPTIONS},
{"NAND 16GiB 1,8V 16-bit",  0x2A, 0, 16384, 0, LP_OPTIONS16},
{"NAND 16GiB 3,3V 16-bit",  0x4A, 0, 16384, 0, LP_OPTIONS16},
 
-- 
1.7.9.5

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