Re: [U-Boot] [PATCH 1/4] gpio: Adds GPIO driver support for Armada100

[Lei Wen]

Hi Ajay,

On Tue, Jul 19, 2011 at 12:23 PM, Ajay Bhargav
 wrote:
>
> - "Prafulla Wadaskar"  wrote:
>
>> You should define all GPIO register in a single struct
>> And point them with base address offsets
>>
>
>>
>> I suggest you to add mvgpio.c instead of armada100_gpio.c
>> This will be used in future by other Marvell SoCs.
>>
> GPIO registers might vary for other Marvell SoCs? How to deal with
> that?

I could tell you that for the pxa series branch, the gpio register arrangement
not change for years, and still keep it valid for the next generation product.

So mvgpio.c could be used by pxa168(aspen), pxa910(td), pxa610(mmp2),
pxa620(mmp3).

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

Re: [U-Boot] [PATCH 1/4] gpio: Adds GPIO driver support for Armada100

[Lei Wen]

Hi Ajay,

On Tue, Jul 19, 2011 at 6:29 PM, Ajay Bhargav
 wrote:
> Hi Prafulla,
>
>> I checked datasheet and for most GPIOs, AF1 is given as GPIO but for few
>> its not, so adding a glue logic to check for specific GPIOs wont be a good 
>> idea.
>> That's the reason i thought its good to keep MFP out of this. Please give 
>> suggestions.
>
> correcting my previous message, I meant AF0.
> adding to this.. I checked Linux kernel source and they are simply validating 
> if gpio number
> is within max limits so request returns 0.
>
> And you told me to use MAX_MFP instead of using ARMD_MAX_GPIO, but MAX_MFP is 
> defined lesser
> than the actual number of GPIO e.g. in case of armada100 MAX_MFP is defined 
> 117 whereas max
> GPIOs are around 123.
>
> Please give me some suggestion.

Actually, as uboot target at small size, I tend to don't add too much
logic to it. So there is no need to
check the "MAX", if one need to set the gpio, he should notice by
himself, the gpio number he specified
is a valid gpio address in the system.

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

Re: [U-Boot] [PATCH 1/4] gpio: Adds GPIO driver support for Armada100

[Ajay Bhargav]

Hi Lei,

> Actually, as uboot target at small size, I tend to don't add too much
> logic to it. So there is no need to
> check the "MAX", if one need to set the gpio, he should notice by
> himself, the gpio number he specified
> is a valid gpio address in the system.

Yeah so i made this assumption already that gpio entered has to be valid.
But do you think checking MFP setup for each gpio requested is good? this way
we are mixing MFP with GPIO again. If a person want to use a GPIO he should
know that MFP has to be configured before using as GPIO. That's the reason we
have a mfp driver.

and I don't think MFP logic written once for one series can be applied to all 
series
to find out if Selected function is GPIO or not. In Armada100 series not all 
MFPs have
AF0 as GPIO. That's the reason I left gpio_request function returning only 0.

Even in Linux kernel source if you see, gpio_request just checks for valid pin 
gpio number
nothing more than that. I seriously need some input to move ahead.

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

Re: [U-Boot] [PATCH 1/4] gpio: Adds GPIO driver support for Armada100

[Lei Wen]

On Wed, Jul 20, 2011 at 3:14 PM, Ajay Bhargav
 wrote:
> Hi Lei,
>
>> Actually, as uboot target at small size, I tend to don't add too much
>> logic to it. So there is no need to
>> check the "MAX", if one need to set the gpio, he should notice by
>> himself, the gpio number he specified
>> is a valid gpio address in the system.
>
> Yeah so i made this assumption already that gpio entered has to be valid.
> But do you think checking MFP setup for each gpio requested is good? this way
> we are mixing MFP with GPIO again. If a person want to use a GPIO he should
> know that MFP has to be configured before using as GPIO. That's the reason we
> have a mfp driver.
>
I am not mixing those two concept together, and in our pratice, we
also do as you said,
use mfp to set that pin to GPIO state, and use gpio function to
manupulate the gpio.
So there is no need checking MFP setting for gpio requreset. Directly
set would be ok.
BTW, why there is need the gpio_request function?

> and I don't think MFP logic written once for one series can be applied to all 
> series
> to find out if Selected function is GPIO or not. In Armada100 series not all 
> MFPs have
> AF0 as GPIO. That's the reason I left gpio_request function returning only 0.

Actually, we use the same gpio driver for several series till now.
And configure pin as GPIO(AF0 or whatever) is the business of MFP.

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

Re: [U-Boot] [PATCH 1/4] gpio: Adds GPIO driver support for Armada100

[Ajay Bhargav]

Hi Lei,

> I am not mixing those two concept together, and in our pratice, we
> also do as you said,
> use mfp to set that pin to GPIO state, and use gpio function to
> manupulate the gpio.
> So there is no need checking MFP setting for gpio requreset. Directly
> set would be ok.

exactly... so here is code snip from my patch and Prafulla's reply.
---
> > +int gpio_request(int gp, const char *label)
> > +{
> > +/*
> > + * Assumes corresponding MFP is configured peoperly
> > + * for use as GPIO
> > + */
> 
> NAK, you should check here, respective MFP is being configured as GPIO, if 
> not you should return error
> 
> > +return 0;
> > +}
> > +
---

> BTW, why there is need the gpio_request function?
> 
You can request a pin as GPIO for using within your code. In Linux Kernel
source this function checks for valid number and if requested pin is in use
or not. To check this they have used a very simple logic.
..pseudo code..
if(pin_label == NULL)
pin is free
else
pin in use

I think I should do the same thing in my request function rather than going for
complicated stuff, what you say?

> 
> Actually, we use the same gpio driver for several series till now.
> And configure pin as GPIO(AF0 or whatever) is the business of MFP.
> 
right.. 

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

Re: [U-Boot] [PATCH 1/4] gpio: Adds GPIO driver support for Armada100

[Lei Wen]

On Wed, Jul 20, 2011 at 3:29 PM, Ajay Bhargav
 wrote:
> Hi Lei,
>
>> I am not mixing those two concept together, and in our pratice, we
>> also do as you said,
>> use mfp to set that pin to GPIO state, and use gpio function to
>> manupulate the gpio.
>> So there is no need checking MFP setting for gpio requreset. Directly
>> set would be ok.
>
> exactly... so here is code snip from my patch and Prafulla's reply.
> ---
>> > +int gpio_request(int gp, const char *label)
>> > +{
>> > +        /*
>> > +         * Assumes corresponding MFP is configured peoperly
>> > +         * for use as GPIO
>> > +         */
>>
>> NAK, you should check here, respective MFP is being configured as GPIO, if 
>> not you should return error
>>
>> > +        return 0;
>> > +}
>> > +
> ---
>
>> BTW, why there is need the gpio_request function?
>>
> You can request a pin as GPIO for using within your code. In Linux Kernel
> source this function checks for valid number and if requested pin is in use
> or not. To check this they have used a very simple logic.
> ..pseudo code..
> if(pin_label == NULL)
>    pin is free
> else
>    pin in use
>
> I think I should do the same thing in my request function rather than going 
> for
> complicated stuff, what you say?
>

I mean why there has to be one request() function call is need?
Is this mandatory for the gpio general framwork as you said?

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

Re: [U-Boot] [PATCH] integrator: convert to new build system

[Linus Walleij]

On Tue, Jul 19, 2011 at 10:04 PM, Wolfgang Denk  wrote:

> [Me]
>>  include/configs/integratorap.h              |    3 +
>>  include/configs/integratorap_cm720t.h       |    1 +
>>  include/configs/integratorap_cm920t.h       |    1 +
>>  include/configs/integratorap_cm926ejs.h     |    1 +
>>  include/configs/integratorap_cm946es.h      |    1 +
>>  include/configs/integratorcp.h              |    2 +
>>  include/configs/integratorcp_cm1136.h       |    1 +
>>  include/configs/integratorcp_cm920t.h       |    1 +
>>  include/configs/integratorcp_cm926ejs.h     |    1 +
>>  include/configs/integratorcp_cm946es.h      |    1 +
>
> It appears that all the new board config files just include
> integrator[ac]p.h, without any additional stuff.

Yes, that's how it works...

> Would it not make
> sense to omit these file alltogether then, and let the entries in
> boards.cfg point to the generic files integratorap.h resp.
> integratorcp.h instead?

This row in the global Makefile is the reason:

sinclude $(obj).boards.depend
$(obj).boards.depend:   boards.cfg
awk '(NF && $$1 !~ /^#/) { print $$1 ": " $$1 "_config;
$$(MAKE)" }' $< > $@

It requires one *_config per board variant.

The boards are just two variants, but the CPU column differs for all of
them, depending on what CPU Module (CM) you plug into the board.

So I define these different boards just to get the right value of CPU into
$(obj)/include/config.mk

I haven't quite figured out how that file is generated, but to avoid any
more configure options being passed in it seemed like the only way
forward without revamping the build system.

Hacking Makefile to support several boards using the same *_config
seems pretty daunting, but if this is what you want I can try.

Any hints?

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

Re: [U-Boot] [PATCH v4 5/9] arm: adjust PLATFORM_LIBS for SPL

[Aneesh V]

Dear Wolfgang,

On Tuesday 19 July 2011 09:21 PM, Daniel Schwierzeck wrote:
> From: Aneesh V
>
> Signed-off-by: Aneesh V
> Cc: Albert ARIBAUD
> ---
> Changes since RFC v1:
> - none
>
> Changes since RFC v2:
> - none
>
> Changes since v3:
> - improved comment

I think this was the final change requested. Will you be pulling this
now?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] gpio: Adds GPIO driver support for Armada100

[Ajay Bhargav]

- "Lei Wen"  wrote:

> I mean why there has to be one request() function call is need?
> Is this mandatory for the gpio general framwork as you said?
> 
> Best regards,
> Lei
> 

If you're enabling GPIO command support (CONFIG_CMD_GPIO), Its necessary. and 
yes its a
part of framework.

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

[U-Boot] [PATCH] integratorcp: make the board compile

[Linus Walleij]

This defines the requires CONFIG_SYS_* variables to make the
Integrator CP board compile.

Signed-off-by: Linus Walleij 
---
This complements the other Integrator patches so that the CP
variants also build cleanly with the new build system.
---
 include/configs/integratorcp.h |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/include/configs/integratorcp.h b/include/configs/integratorcp.h
index 210bc9d..e9b68c6 100644
--- a/include/configs/integratorcp.h
+++ b/include/configs/integratorcp.h
@@ -142,6 +142,12 @@ SIB at Block62 End Block62 address 0x24f8
 #define CONFIG_NR_DRAM_BANKS   1   /* we have 1 bank of DRAM */
 #define PHYS_SDRAM_1   0x  /* SDRAM Bank #1 */
 #define PHYS_SDRAM_1_SIZE  0x0800  /* 128 MB */
+#define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM_1
+#define CONFIG_SYS_INIT_RAM_SIZE PHYS_SDRAM_1_SIZE
+#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_SDRAM_BASE + \
+   CONFIG_SYS_INIT_RAM_SIZE - \
+   GENERATED_GBL_DATA_SIZE)
+#define CONFIG_SYS_INIT_SP_ADDR CONFIG_SYS_GBL_DATA_OFFSET
 
 /*---
  * FLASH and environment organization
-- 
1.7.6

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

[U-Boot] [PATCH v2] MAINTAINERS: integrator+versatile boards

[Linus Walleij]

- Take maintainership of the unlisted integratorap, and the
  integratorcp boards
- Orphan the versatile maintained by Peter Pearse, as he has retired
  from ARM

Cc: Philippe Robin 
Signed-off-by: Linus Walleij 
---
Changes v1->v2: take care also of the integratorcp board(s).
---
 MAINTAINERS |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 143f31b..4ba93ae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -550,6 +550,9 @@ Unknown / orphaned boards:
 
EVB64260MPC7xx_74xx
 
+   versatile   ARM926EJ-S
+   versatile   ARM926EJ-S
+
 
 #
 # ARM Systems: #
@@ -777,11 +780,9 @@ Sandeep Paulraj 
davinci_dm365evmARM926EJS
davinci_dm6467evm   ARM926EJS
 
-Peter Pearse 
-   integratorcpAll current ARM supplied & supported core modules
-   -see 
http://www.arm.com/products/DevTools/Hardware_Platforms.html
-   versatile   ARM926EJ-S
-   versatile   ARM926EJ-S
+Linus Walleij 
+   integratorapvarious
+   integratorcpvarious
 
 Dave Peverley 
 
-- 
1.7.6

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

[U-Boot] [PATCH v2] i2c:gpio:s5p: I2C GPIO Software implementation (via soft_i2c)

[Lukasz Majewski]

This patch adds support for software I2C for GONI reference target.
It adds support for access to GPIOs by number, not as it is present,
by bank and offset.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
Cc: Minkyu Kang 
Cc: Heiko Schocher 

---
Changes for v2:
- Generic GPIO code added to arch/arm/gpio.h
- Platform dependent GPIO code added to board/samsung/goni.c
- Code cleanup
---
 arch/arm/include/asm/arch-s5pc1xx/gpio.h |   36 ++
 board/samsung/goni/goni.c|   30 +++-
 include/configs/s5p_goni.h   |   13 ++
 3 files changed, 77 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-s5pc1xx/gpio.h 
b/arch/arm/include/asm/arch-s5pc1xx/gpio.h
index 903de9c..8d2e2e9 100644
--- a/arch/arm/include/asm/arch-s5pc1xx/gpio.h
+++ b/arch/arm/include/asm/arch-s5pc1xx/gpio.h
@@ -134,6 +134,40 @@ unsigned int s5p_gpio_get_value(struct s5p_gpio_bank 
*bank, int gpio);
 void s5p_gpio_set_pull(struct s5p_gpio_bank *bank, int gpio, int mode);
 void s5p_gpio_set_drv(struct s5p_gpio_bank *bank, int gpio, int mode);
 void s5p_gpio_set_rate(struct s5p_gpio_bank *bank, int gpio, int mode);
+struct s5p_gpio_bank *s5p_gpio_get_bank(int nr);
+int s5p_gpio_get_pin(int nr);
+
+static inline int gpio_request(int gpio, const char *label)
+{
+   return 0;
+}
+
+static inline int gpio_direction_input(int nr)
+{
+   s5p_gpio_direction_input(s5p_gpio_get_bank(nr),
+s5p_gpio_get_pin(nr));
+   return 0;
+}
+
+static inline int gpio_direction_output(int nr, int value)
+{
+   s5p_gpio_direction_output(s5p_gpio_get_bank(nr),
+ s5p_gpio_get_pin(nr), value);
+   return 0;
+}
+
+static inline int gpio_get_value(int nr)
+{
+   return (int) s5p_gpio_get_value(s5p_gpio_get_bank(nr),
+   s5p_gpio_get_pin(nr));
+}
+
+static inline void gpio_set_value(int nr, int value)
+{
+   s5p_gpio_set_value(s5p_gpio_get_bank(nr),
+  s5p_gpio_get_pin(nr), value);
+}
+
 #endif
 
 /* Pin configurations */
@@ -155,4 +189,6 @@ void s5p_gpio_set_rate(struct s5p_gpio_bank *bank, int 
gpio, int mode);
 #define GPIO_DRV_FAST  0x0
 #define GPIO_DRV_SLOW  0x1
 
+/* GPIO pins per bank  */
+#define GPIO_PER_BANK 8
 #endif
diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c
index e24cd29..d1ff956 100644
--- a/board/samsung/goni/goni.c
+++ b/board/samsung/goni/goni.c
@@ -1,7 +1,8 @@
 /*
- *  Copyright (C) 2008-2009 Samsung Electronics
+ *  Copyright (C) 2008-2011 Samsung Electronics
  *  Minkyu Kang 
  *  Kyungmin Park 
+ *  Lukasz Majewski 
  *
  * See file CREDITS for list of people who contributed to this
  * project.
@@ -28,7 +29,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static struct s5pc110_gpio *s5pc110_gpio;
+struct s5pc110_gpio *s5pc110_gpio;
 
 int board_init(void)
 {
@@ -96,3 +97,28 @@ int board_mmc_init(bd_t *bis)
return s5p_mmc_init(0, 4);
 }
 #endif
+
+#ifdef CONFIG_SOFT_I2C
+void i2c_init_board(void) {}
+/* Platform dependent functions for extracting GPIO number */
+int s5p_gpio_get_nr(void *gp_ptr, int gpio)
+{
+   unsigned int offset = gp_ptr - (void *) s5pc110_gpio;
+   offset /= sizeof(struct s5p_gpio_bank);
+
+   return (offset * GPIO_PER_BANK) + gpio;
+}
+
+struct s5p_gpio_bank *s5p_gpio_get_bank(int nr)
+{
+   int bank = nr / GPIO_PER_BANK;
+   bank *= sizeof(struct s5p_gpio_bank);
+
+   return (struct s5p_gpio_bank *) ((void *) s5pc110_gpio + bank);
+}
+
+int s5p_gpio_get_pin(int nr)
+{
+   return nr % GPIO_PER_BANK;
+}
+#endif
diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index 010428b..7af1b5f 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -224,4 +224,17 @@
 
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR - 0x100)
 
+#include 
+/*
+ * I2C Settings
+ */
+#define S5PC110_GPIO_J3  (S5PC110_GPIO_BASE + 0x2C0)
+#define CONFIG_SOFT_I2C_GPIO_SCL s5p_gpio_get_nr(S5PC110_GPIO_J3, 3)
+#define CONFIG_SOFT_I2C_GPIO_SDA s5p_gpio_get_nr(S5PC110_GPIO_J3, 0)
+
+#define CONFIG_SOFT_I2C1
+#define CONFIG_SYS_I2C_SPEED   5
+#define CONFIG_I2C_MULTI_BUS
+#define CONFIG_SYS_MAX_I2C_BUS 7
+
 #endif /* __CONFIG_H */
-- 
1.7.2.3

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

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

[Aneesh V]

Hi Anton,

On Tuesday 19 July 2011 11:44 PM, Anton Staaf wrote:
[snip ..]

>  There are a number of possible solutions:
>
>  1) Modify the invalidate code to first read the partial cache line
>  and then invalidate and then write back just the valid part of the
>  line.  This suffers from a race condition with concurrent code in
>  interrupt handlers or other CPUs.

How do you propose to implement this?

Are you suggesting something like momentarily turning off D-cache, read
the memory content into registers, enable cache again, mix the memory
content in registers with the cache content and then flush, or
something like that? I am afraid this will be way too complex if at all
viable.

I don't see any other easy option. Am I missing something?

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

Re: [U-Boot] Please Pull u-boot-ti/master (see note, custodians please read )

[Albert ARIBAUD]

(to : ARM custodians, for action)
(cc: Wolfgang and Scott, for info)

Hi Sandeep,

Le 19/07/2011 17:22, Paulraj, Sandeep a écrit :
>
>
>>
>> Note that u-boot-ti still has a tag, "2009.01-rc2", which should be
>> removed from the repository, see
>> .
>>
>> (there is also a "NIOS2-5_0_0" tag which I am not sure of;maybe it
>> should be removed too)
>>
> Albert,
>
> I regularly rebase with mainline u-boot and these tags are present in 
> mainline u-boot I believe. This is how I have the tags in my repository.

Actually no, they are not in mainline any more, that's the point of the 
mail I referred you to.

I have just cloned a fresh u-boot, and neither "2009.01-rc2" nor 
"NIOS2-5_0_0" are in there. The latter was still in u-boot-arm, and 
there being no reason for it there, I just removed it by 'git push -f 
ssh://gu-...@git.denx.de/u-boot-arm :NIOS2-5_0_0'

Note that both spurious tags are also present in u-boot-atmel, 
u-boot-imx, u-boot-marvell, u-boot-pxa, and u-boot-samsung (and possibly 
others? I only checked the ones I have as remotes) -- custodians added 
in To: list. Both should be removed, as the NIOS tag should appear only 
in Scott's u-boot-nios repository (Scott CC:ed for info).

Note: rebasing your repo will not 'pull tag removals', i.e. if a tag is 
removed from a remote it will not automatically be removed from your 
local repo, and besides, if you remove it locally it will not be removed 
from your official repo on the denx server unless you explicitly tell 
'git push' to do it, like I did. To make sure you are completely rid of 
a tag, you have to do both a 'git tag -d TAGTOREMOVE' for local removal, 
and a 'git push ... :TAGTOREMOVE' (or use 'git push --mirror' or 'git 
push --delete', with care)

> Regards,
> Sandeep

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

Re: [U-Boot] [PATCH 4/7] mmc: rescan fails on empty slot

[Michael Jones]

Hi Jaehoon Chung,

On 07/19/2011 04:06 AM, Jaehoon Chung wrote:
> 
> Hi Michael.
> 
> I have some question. there are some mmc_init().
> But you are only checked there..
> Did you have any special reason?
> 
> Regards,
> Jaehoon Chung

The purpose of my patch was to enable an if/else to detect whether there
was a card in the slot. Among the available mmc commands, I thought 'mmc
rescan' was the most logical to be able to use to detect whether a slot
was empty or not.

Below is a survey of other places where a similar check could be done. I
think that if a similar check is to be made in these cases, they could
be in separate patch(es) from this one.

- 'mmc read/write': These commands should fail anyway if the slot were
empty.
- 'mmc part' prints "## Unknown partition table" if the slot is empty,
although the command itself still returns successfully. I suppose the
check could make sense here.
- 'mmc dev': I thought there was perhaps a use case where it makes sense
to switch to a mmc device which is currently empty. If that is not true,
it would probably make sense to do the same check there.
- 'mmcinfo': Currently this basically prints '0' for all the fields when
the slot is empty. It probably would be more logical to print "device
init failed" or similar instead.

-Michael

> 
> Michael Jones wrote:
>> Fail in 'mmc rescan' if mmc_init() returns error
>>
>> Signed-off-by: Michael Jones 
>> ---
>>  common/cmd_mmc.c |6 --
>>  1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
>> index 176646d..28918f6 100644
>> --- a/common/cmd_mmc.c
>> +++ b/common/cmd_mmc.c
>> @@ -165,9 +165,11 @@ int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, 
>> char * const argv[])
>>  }
>>  
>>  mmc->has_init = 0;
>> -mmc_init(mmc);
>>  
>> -return 0;
>> +if (mmc_init(mmc))
>> +return 1;
>> +else
>> +return 0;
>>  } else if (strncmp(argv[1], "part", 4) == 0) {
>>  block_dev_desc_t *mmc_dev;
>>  struct mmc *mmc = find_mmc_device(curr_device);
> 


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

[Albert ARIBAUD]

Hi David,

Le 20/07/2011 08:29, David Jander a écrit :
> On Tue, 19 Jul 2011 14:10:48 +0200
> David Jander  wrote:
>
>> On Tue, 19 Jul 2011 13:20:26 +0200
>> Wolfgang Denk  wrote:
>>
>>> Dear David Jander,
>>>
>>> In message<20110719131744.403a81e6@archvile>  you wrote:

 Now I finally know what's wrong and am working on a proposed fix to make
 this one driver cache-aware.
>>>
>>> I would just like to point out that these efforts are highly
>>> appreciated!
>>
>> Thanks.
>> I'll try my best, but I am running out of time, and it is still not as it
>> should. I still have trouble identifying the right place where receive buffer
>> descriptors should be cache-invalidated. At one point, a magic
>> flush_dcache_all() at a certain place in code made it work, but that can't be
>> entirely correct, and if I replace it with only the necessary ranges, it
>> doesn't work correctly anymore, so I guess this flush is also invalidating
>> something I need elsewhere :-(
>> I keep searching through the IMO fairly convoluted network code.
>
> Ok, that was not such a problem. I found few nice spots, where
> cache-maintenance code should go IMO:
>
> In fec_rx_task_enable() cleaned RX BD's should be flushed.
> In fec_tx_task_enable() dirty TX BD's should be flushed, as well as data
> buffers.
> In fec_send() Invalidate BD status fields before reading, also in the while
> loop.
> In fec_recv() Invalidate BD and data buffers just before every read.
>
> And of course align all buffers to cache-line size and pad around the end of
> each buffer to cache-line size.
>
> Problem: It doesn't work (tftp transfer stops after a few packets)! :-(
> I am giving up!
>
> Plan B: I'll now try to allocate all buffers in internal RAM (which is not
> cached AFAIK).
>
> Any ideas?

Yes, one: I had issues with the Marvell Ethernet adapter, which has DMA 
as well, not because of cache (it was not active at the time) but 
because of instruction reordering done by the compiler when optimizing, 
which resulted in out-of-order accesses to the descritpors and DMA 
registered, so that the DMA start was written before the descriptors 
were set up. The (proper and clean) solution was to introduce memory 
barriers at strategic points of the driver to ensure that specific DMA 
starts were done only after all writes to the descriptors (and possibly 
buffers).

See drivers/net/mvgbe.c, and llok for 'isb()' instructions.

> Best regards,

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

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

[David Jander]

On Wed, 20 Jul 2011 10:56:07 +0200
Albert ARIBAUD  wrote:

> Hi David,
> 
> Le 20/07/2011 08:29, David Jander a écrit :
> > On Tue, 19 Jul 2011 14:10:48 +0200
> > David Jander  wrote:
> >
> >> On Tue, 19 Jul 2011 13:20:26 +0200
> >> Wolfgang Denk  wrote:
> >>
> >>> Dear David Jander,
> >>>
> >>> In message<20110719131744.403a81e6@archvile>  you wrote:
> 
>  Now I finally know what's wrong and am working on a proposed fix to make
>  this one driver cache-aware.
> >>>
> >>> I would just like to point out that these efforts are highly
> >>> appreciated!
> >>
> >> Thanks.
> >> I'll try my best, but I am running out of time, and it is still not as it
> >> should. I still have trouble identifying the right place where receive
> >> buffer descriptors should be cache-invalidated. At one point, a magic
> >> flush_dcache_all() at a certain place in code made it work, but that
> >> can't be entirely correct, and if I replace it with only the necessary
> >> ranges, it doesn't work correctly anymore, so I guess this flush is also
> >> invalidating something I need elsewhere :-(
> >> I keep searching through the IMO fairly convoluted network code.
> >
> > Ok, that was not such a problem. I found few nice spots, where
> > cache-maintenance code should go IMO:
> >
> > In fec_rx_task_enable() cleaned RX BD's should be flushed.
> > In fec_tx_task_enable() dirty TX BD's should be flushed, as well as data
> > buffers.
> > In fec_send() Invalidate BD status fields before reading, also in the while
> > loop.
> > In fec_recv() Invalidate BD and data buffers just before every read.
> >
> > And of course align all buffers to cache-line size and pad around the end
> > of each buffer to cache-line size.
> >
> > Problem: It doesn't work (tftp transfer stops after a few packets)! :-(
> > I am giving up!
> >
> > Plan B: I'll now try to allocate all buffers in internal RAM (which is not
> > cached AFAIK).
> >
> > Any ideas?
> 
> Yes, one: I had issues with the Marvell Ethernet adapter, which has DMA 
> as well, not because of cache (it was not active at the time) but 
> because of instruction reordering done by the compiler when optimizing, 
> which resulted in out-of-order accesses to the descritpors and DMA 
> registered, so that the DMA start was written before the descriptors 
> were set up. The (proper and clean) solution was to introduce memory 
> barriers at strategic points of the driver to ensure that specific DMA 
> starts were done only after all writes to the descriptors (and possibly 
> buffers).

Hmmm. I know that issue, but AFAICS, the driver already uses readX() and
writeX() macros when accessing register and DMA memory. Those macros have
compiler barriers included and armv7 is still in-order execution ;-)
Thanks for the suggestion anyway :-)

Best regards,

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

Re: [U-Boot] [PATCH 4/7] mmc: rescan fails on empty slot

[Jaehoon Chung]

Hi Michael

Thanks for your explanation. :)

Regards,
Jaehoon Chung

Michael Jones wrote:
> Hi Jaehoon Chung,
> 
> On 07/19/2011 04:06 AM, Jaehoon Chung wrote:
>> Hi Michael.
>>
>> I have some question. there are some mmc_init().
>> But you are only checked there..
>> Did you have any special reason?
>>
>> Regards,
>> Jaehoon Chung
> 
> The purpose of my patch was to enable an if/else to detect whether there
> was a card in the slot. Among the available mmc commands, I thought 'mmc
> rescan' was the most logical to be able to use to detect whether a slot
> was empty or not.
> 
> Below is a survey of other places where a similar check could be done. I
> think that if a similar check is to be made in these cases, they could
> be in separate patch(es) from this one.
> 
> - 'mmc read/write': These commands should fail anyway if the slot were
> empty.
> - 'mmc part' prints "## Unknown partition table" if the slot is empty,
> although the command itself still returns successfully. I suppose the
> check could make sense here.
> - 'mmc dev': I thought there was perhaps a use case where it makes sense
> to switch to a mmc device which is currently empty. If that is not true,
> it would probably make sense to do the same check there.
> - 'mmcinfo': Currently this basically prints '0' for all the fields when
> the slot is empty. It probably would be more logical to print "device
> init failed" or similar instead.
> 
> -Michael
> 
>> Michael Jones wrote:
>>> Fail in 'mmc rescan' if mmc_init() returns error
>>>
>>> Signed-off-by: Michael Jones 
>>> ---
>>>  common/cmd_mmc.c |6 --
>>>  1 files changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
>>> index 176646d..28918f6 100644
>>> --- a/common/cmd_mmc.c
>>> +++ b/common/cmd_mmc.c
>>> @@ -165,9 +165,11 @@ int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, 
>>> char * const argv[])
>>> }
>>>  
>>> mmc->has_init = 0;
>>> -   mmc_init(mmc);
>>>  
>>> -   return 0;
>>> +   if (mmc_init(mmc))
>>> +   return 1;
>>> +   else
>>> +   return 0;
>>> } else if (strncmp(argv[1], "part", 4) == 0) {
>>> block_dev_desc_t *mmc_dev;
>>> struct mmc *mmc = find_mmc_device(curr_device);
> 
> 
> MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
> Registergericht: Amtsgericht Stuttgart, HRB 271090
> Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard 
> Meier
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

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

Re: [U-Boot] [PATCH 1/4] gpio: Adds GPIO driver support for Armada100

[Lei Wen]

Hi Ajay,

On Wed, Jul 20, 2011 at 2:36 PM, Ajay Bhargav
 wrote:
> Dear Wolfgang,
>
>>
>> Is there any specific reason for not using u32 for the padding as
>> well?
>>
> nothing specific. It makes easy to find number of bytes than words.
>
>>
>> Why would you need this BASE + OFFSET notation when using a C struct
>> for the registers? Thi smakes little sense to me.
>>
>
> Well I did use the C struct method, if you see my patches submitted earlier
> but according to Prafulla and Lie structure size is too big. so they want me
> to use a mix of C struct and BASE + OFFSET notation. so I thought to break 
> the big
> C struct into smaller grouped structures pointing each group with GPIO base + 
> group
> offset. I would be glad if you can suggest me something better or smarter.
>

I think we make thing complicated here. For GPIO driver, the only
structure we need to
define is the GPIO register itself, like GPIO_PLR, GPIO_PDR, etc...

For the previous long huge structure and include your recent short
version is still not good
enough. What we want to get is the base address, and based on the
register structure
to do explicit work. So either get the base address based on MACRO, or
get from a function
I think both should be ok for me. But please not continue work on how
to define the base
address into a structure.

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

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

[Aneesh V]

Hi David,

On Wednesday 20 July 2011 02:51 PM, David Jander wrote:
> On Wed, 20 Jul 2011 10:56:07 +0200

[snip ..]

>>> Any ideas?
>>
>> Yes, one: I had issues with the Marvell Ethernet adapter, which has DMA
>> as well, not because of cache (it was not active at the time) but
>> because of instruction reordering done by the compiler when optimizing,
>> which resulted in out-of-order accesses to the descritpors and DMA
>> registered, so that the DMA start was written before the descriptors
>> were set up. The (proper and clean) solution was to introduce memory
>> barriers at strategic points of the driver to ensure that specific DMA
>> starts were done only after all writes to the descriptors (and possibly
>> buffers).
>
> Hmmm. I know that issue, but AFAICS, the driver already uses readX() and
> writeX() macros when accessing register and DMA memory. Those macros have
> compiler barriers included and armv7 is still in-order execution ;-)

1. armv7 is not necessarily in-order. Cortex-A8 is in-order while
Cortex-A9 is out-of-order.
2. I am not sure if in-order execution guarantees memory ordering. My
understanding is that it doesn't.
3. In u-boot's implementation of MMU for ARM, the register
space(everything other than SDRAM) is 'strongly-ordered' memory.
Strongly ordered accesses will be correctly ordered w.r.to all other
accesses in program order.
4. Compiler barriers prevent the compiler from doing certain
optimizations, but doesn't help in these situations.

In short, I think you don't need to worry about ordering, but not
because of compiler barriers or armv7 being in-order.

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

Re: [U-Boot] [PATCH 1/4] gpio: Adds GPIO driver support for Armada100

[Ajay Bhargav]

Hi Lei,

> I think we make thing complicated here. For GPIO driver, the only
> structure we need to
> define is the GPIO register itself, like GPIO_PLR, GPIO_PDR, etc...
> 

I got your point, but lemme show you where the problem is..
GPIO_PLR00x
GPIO_PLR10x0004
GPIO_PLR20x0008
GPIO_PLR30x0100

till 3 registers its fine... fourth register is way out of league.

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

[U-Boot] [PATCH v2 1/5] omap4: add omap4460 revision detection

[Aneesh V]

Signed-off-by: Aneesh V 
---
 arch/arm/cpu/armv7/omap4/board.c|3 +++
 arch/arm/include/asm/arch-omap4/omap4.h |1 +
 arch/arm/include/asm/armv7.h|1 +
 3 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap4/board.c b/arch/arm/cpu/armv7/omap4/board.c
index 2e5739a..17e731a 100644
--- a/arch/arm/cpu/armv7/omap4/board.c
+++ b/arch/arm/cpu/armv7/omap4/board.c
@@ -140,6 +140,9 @@ static void init_omap4_revision(void)
case MIDR_CORTEX_A9_R1P3:
*omap4_revision = OMAP4430_ES2_3;
break;
+   case MIDR_CORTEX_A9_R2P10:
+   *omap4_revision = OMAP4460_ES1_0;
+   break;
default:
*omap4_revision = OMAP4430_SILICON_ID_INVALID;
break;
diff --git a/arch/arm/include/asm/arch-omap4/omap4.h 
b/arch/arm/include/asm/arch-omap4/omap4.h
index 563544f..7ff46d7 100644
--- a/arch/arm/include/asm/arch-omap4/omap4.h
+++ b/arch/arm/include/asm/arch-omap4/omap4.h
@@ -143,6 +143,7 @@ struct s32ktimer {
 #define OMAP4430_ES2_1 0x44300210
 #define OMAP4430_ES2_2 0x44300220
 #define OMAP4430_ES2_3 0x44300230
+#define OMAP4460_ES1_0 0x44600100
 
 /* ROM code defines */
 /* Boot device */
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index b5784d8..9adc563 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -29,6 +29,7 @@
 #define MIDR_CORTEX_A9_R0P10x410FC091
 #define MIDR_CORTEX_A9_R1P20x411FC092
 #define MIDR_CORTEX_A9_R1P30x411FC093
+#define MIDR_CORTEX_A9_R2P10   0x412FC09A
 
 /* CCSIDR */
 #define CCSIDR_LINE_SIZE_OFFSET0
-- 
1.7.0.4

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

[U-Boot] [PATCH v2 0/5] arm: omap4: omap4460 support

[Aneesh V]

OMAP4460 is the latest addition to the OMAP4 family.
OMAP4460 has dual core Cortex-A9 CPUs that can be clocked upto
1.5 GHz

The memory architecture has been improved to provide better
performance and there several other minor improvements in various
modules.

This series depends on the OMAP4 spl series [1] and the SPL framework
series [2]

[1] http://marc.info/?l=u-boot&m=131082102506002&w=2
[2] http://marc.info/?l=u-boot&m=131056990001719&w=2

Changes in V2:
* Added missing file in the patch 3/5
* Corrected subject lines of patches

Aneesh V (5):
  omap4: add omap4460 revision detection
  omap4: sdram init changes for omap4460
  omap: reuse omap3 gpio support in omap4
  omap4: support TPS programming
  omap4: clock init support for omap4460

 arch/arm/cpu/armv7/omap-common/Makefile|1 +
 arch/arm/cpu/armv7/{omap3 => omap-common}/gpio.c   |   41 +++
 arch/arm/cpu/armv7/omap3/Makefile  |1 -
 arch/arm/cpu/armv7/omap3/board.c   |   12 ++
 arch/arm/cpu/armv7/omap4/board.c   |   19 +++
 arch/arm/cpu/armv7/omap4/clocks.c  |  128 +---
 arch/arm/cpu/armv7/omap4/emif.c|   39 ---
 arch/arm/include/asm/arch-omap3/cpu.h  |   26 
 arch/arm/include/asm/arch-omap4/clocks.h   |   28 -
 arch/arm/include/asm/arch-omap4/cpu.h  |   26 
 arch/arm/include/asm/arch-omap4/emif.h |   10 ++-
 arch/arm/include/asm/arch-omap4/mux_omap4.h|1 +
 arch/arm/include/asm/arch-omap4/omap4.h|9 ++
 arch/arm/include/asm/armv7.h   |1 +
 .../include/asm/{arch-omap3/gpio.h => omap_gpio.h} |   27 +
 15 files changed, 284 insertions(+), 85 deletions(-)
 rename arch/arm/cpu/armv7/{omap3 => omap-common}/gpio.c (76%)
 rename arch/arm/include/asm/{arch-omap3/gpio.h => omap_gpio.h} (67%)

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

[U-Boot] [PATCH v2 2/5] omap4: sdram init changes for omap4460

[Aneesh V]

Signed-off-by: Aneesh V 
---
 arch/arm/cpu/armv7/omap4/emif.c|   39 ++--
 arch/arm/include/asm/arch-omap4/emif.h |   10 ++-
 2 files changed, 30 insertions(+), 19 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap4/emif.c b/arch/arm/cpu/armv7/omap4/emif.c
index 1234a7e..487ec42 100644
--- a/arch/arm/cpu/armv7/omap4/emif.c
+++ b/arch/arm/cpu/armv7/omap4/emif.c
@@ -151,22 +151,13 @@ static void emif_update_timings(u32 base, const struct 
emif_regs *regs)
writel(regs->zq_config, &emif->emif_zq_config);
writel(regs->temp_alert_config, &emif->emif_temp_alert_config);
writel(regs->emif_ddr_phy_ctlr_1, &emif->emif_ddr_phy_ctrl_1_shdw);
-   /*
-* Workaround:
-* In a specific situation, the OCP interface between the DMM and
-* EMIF may hang.
-* 1. A TILER port is used to perform 2D burst writes of
-*   width 1 and height 8
-* 2. ELLAn port is used to perform reads
-* 3. All accesses are routed to the same EMIF controller
-*
-* Work around to avoid this issue REG_SYS_THRESH_MAX value should
-* be kept higher than default 0x7. As per recommondation 0x0A will
-* be used for better performance with REG_LL_THRESH_MAX = 0x00
-*/
-   if (omap_revision() == OMAP4430_ES1_0) {
-   writel(EMIF_L3_CONFIG_VAL_SYS_THRESH_0A_LL_THRESH_00,
-  &emif->emif_l3_config);
+
+   if (omap_revision() >= OMAP4460_ES1_0) {
+   writel(EMIF_L3_CONFIG_VAL_SYS_10_MPU_3_LL_0,
+   &emif->emif_l3_config);
+   } else {
+   writel(EMIF_L3_CONFIG_VAL_SYS_10_LL_0,
+   &emif->emif_l3_config);
}
 }
 
@@ -504,7 +495,7 @@ static u32 get_read_idle_ctrl_reg(u8 volt_ramp)
 {
u32 idle = 0, val = 0;
if (volt_ramp)
-   val = ns_2_cycles(READ_IDLE_INTERVAL_DVFS) / 64 + 1;
+   val = ns_2_cycles(READ_IDLE_INTERVAL_DVFS) / 64 - 1;
else
/*Maximum value in normal conditions - suggested by hw team */
val = 0x1FF;
@@ -1237,6 +1228,20 @@ static void dmm_init(u32 base)
&hw_lisa_map_regs->dmm_lisa_map_1);
writel(lisa_map_regs->dmm_lisa_map_0,
&hw_lisa_map_regs->dmm_lisa_map_0);
+
+   if (omap_revision() >= OMAP4460_ES1_0) {
+   hw_lisa_map_regs =
+   (struct dmm_lisa_map_regs *)OMAP44XX_MA_LISA_MAP_BASE;
+
+   writel(lisa_map_regs->dmm_lisa_map_3,
+   &hw_lisa_map_regs->dmm_lisa_map_3);
+   writel(lisa_map_regs->dmm_lisa_map_2,
+   &hw_lisa_map_regs->dmm_lisa_map_2);
+   writel(lisa_map_regs->dmm_lisa_map_1,
+   &hw_lisa_map_regs->dmm_lisa_map_1);
+   writel(lisa_map_regs->dmm_lisa_map_0,
+   &hw_lisa_map_regs->dmm_lisa_map_0);
+   }
 }
 
 /*
diff --git a/arch/arm/include/asm/arch-omap4/emif.h 
b/arch/arm/include/asm/arch-omap4/emif.h
index a167508..37ad1fd 100644
--- a/arch/arm/include/asm/arch-omap4/emif.h
+++ b/arch/arm/include/asm/arch-omap4/emif.h
@@ -248,6 +248,8 @@
 /* OCP_CONFIG */
 #define OMAP44XX_REG_SYS_THRESH_MAX_SHIFT  24
 #define OMAP44XX_REG_SYS_THRESH_MAX_MASK   (0xf << 24)
+#define OMAP44XX_REG_MPU_THRESH_MAX_SHIFT  20
+#define OMAP44XX_REG_MPU_THRESH_MAX_MASK   (0xf << 20)
 #define OMAP44XX_REG_LL_THRESH_MAX_SHIFT   16
 #define OMAP44XX_REG_LL_THRESH_MAX_MASK(0xf << 16)
 #define OMAP44XX_REG_PR_OLD_COUNT_SHIFT0
@@ -472,6 +474,9 @@
 /* DMM */
 #define OMAP44XX_DMM_LISA_MAP_BASE 0x4E40
 
+/* Memory Adapter (4460 onwards) */
+#define OMAP44XX_MA_LISA_MAP_BASE  0x482AF040
+
 /* DMM_LISA_MAP */
 #define OMAP44XX_SYS_ADDR_SHIFT24
 #define OMAP44XX_SYS_ADDR_MASK (0xff << 24)
@@ -774,8 +779,9 @@ struct control_lpddr2io_regs {
((REG_PD_TIM << OMAP44XX_REG_PD_TIM_SHDW_SHIFT)\
& OMAP44XX_REG_PD_TIM_SHDW_MASK))
 
-/* EMIF_L3_CONFIG register value for ES1*/
-#define EMIF_L3_CONFIG_VAL_SYS_THRESH_0A_LL_THRESH_00  0x0AFF
+/* EMIF_L3_CONFIG register value */
+#define EMIF_L3_CONFIG_VAL_SYS_10_LL_0 0x0AFF
+#define EMIF_L3_CONFIG_VAL_SYS_10_MPU_3_LL_0   0x0A30
 /*
  * Value of bits 12:31 of DDR_PHY_CTRL_1 register:
  * All these fields have magic values dependent on frequency and
-- 
1.7.0.4

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

[U-Boot] [PATCH v2 3/5] omap: reuse omap3 gpio support in omap4

[Aneesh V]

Signed-off-by: Aneesh V 
---
V2:
* Added a new file that was accidentally missing in v1
---
 arch/arm/cpu/armv7/omap-common/Makefile|1 +
 arch/arm/cpu/armv7/{omap3 => omap-common}/gpio.c   |   41 
 arch/arm/cpu/armv7/omap3/Makefile  |1 -
 arch/arm/cpu/armv7/omap3/board.c   |   12 ++
 arch/arm/cpu/armv7/omap4/board.c   |   12 ++
 arch/arm/cpu/armv7/omap4/clocks.c  |2 +-
 arch/arm/include/asm/arch-omap3/cpu.h  |   26 
 arch/arm/include/asm/arch-omap4/cpu.h  |   26 
 arch/arm/include/asm/arch-omap4/omap4.h|8 
 .../include/asm/{arch-omap3/gpio.h => omap_gpio.h} |   27 +---
 10 files changed, 105 insertions(+), 51 deletions(-)
 rename arch/arm/cpu/armv7/{omap3 => omap-common}/gpio.c (76%)
 rename arch/arm/include/asm/{arch-omap3/gpio.h => omap_gpio.h} (67%)

diff --git a/arch/arm/cpu/armv7/omap-common/Makefile 
b/arch/arm/cpu/armv7/omap-common/Makefile
index 0708796..ea9f8ec 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -29,6 +29,7 @@ SOBJS := reset.o
 
 COBJS  := timer.o
 COBJS  += utils.o
+COBJS  += gpio.o
 
 ifdef CONFIG_SPL_BUILD
 COBJS  += spl.o
diff --git a/arch/arm/cpu/armv7/omap3/gpio.c 
b/arch/arm/cpu/armv7/omap-common/gpio.c
similarity index 76%
rename from arch/arm/cpu/armv7/omap3/gpio.c
rename to arch/arm/cpu/armv7/omap-common/gpio.c
index aeb6066..f4c3479 100644
--- a/arch/arm/cpu/armv7/omap3/gpio.c
+++ b/arch/arm/cpu/armv7/omap-common/gpio.c
@@ -36,24 +36,13 @@
  * published by the Free Software Foundation.
  */
 #include 
-#include 
+#include 
 #include 
 #include 
 
-static struct gpio_bank gpio_bank_34xx[6] = {
-   { (void *)OMAP34XX_GPIO1_BASE, METHOD_GPIO_24XX },
-   { (void *)OMAP34XX_GPIO2_BASE, METHOD_GPIO_24XX },
-   { (void *)OMAP34XX_GPIO3_BASE, METHOD_GPIO_24XX },
-   { (void *)OMAP34XX_GPIO4_BASE, METHOD_GPIO_24XX },
-   { (void *)OMAP34XX_GPIO5_BASE, METHOD_GPIO_24XX },
-   { (void *)OMAP34XX_GPIO6_BASE, METHOD_GPIO_24XX },
-};
-
-static struct gpio_bank *gpio_bank = &gpio_bank_34xx[0];
-
-static inline struct gpio_bank *get_gpio_bank(int gpio)
+static inline const struct gpio_bank *get_gpio_bank(int gpio)
 {
-   return &gpio_bank[gpio >> 5];
+   return &omap_gpio_bank[gpio >> 5];
 }
 
 static inline int get_gpio_index(int gpio)
@@ -79,14 +68,15 @@ static int check_gpio(int gpio)
return 0;
 }
 
-static void _set_gpio_direction(struct gpio_bank *bank, int gpio, int is_input)
+static void _set_gpio_direction(const struct gpio_bank *bank, int gpio,
+   int is_input)
 {
void *reg = bank->base;
u32 l;
 
switch (bank->method) {
case METHOD_GPIO_24XX:
-   reg += OMAP24XX_GPIO_OE;
+   reg += OMAP_GPIO_OE;
break;
default:
return;
@@ -101,7 +91,7 @@ static void _set_gpio_direction(struct gpio_bank *bank, int 
gpio, int is_input)
 
 void omap_set_gpio_direction(int gpio, int is_input)
 {
-   struct gpio_bank *bank;
+   const struct gpio_bank *bank;
 
if (check_gpio(gpio) < 0)
return;
@@ -109,7 +99,8 @@ void omap_set_gpio_direction(int gpio, int is_input)
_set_gpio_direction(bank, get_gpio_index(gpio), is_input);
 }
 
-static void _set_gpio_dataout(struct gpio_bank *bank, int gpio, int enable)
+static void _set_gpio_dataout(const struct gpio_bank *bank, int gpio,
+   int enable)
 {
void *reg = bank->base;
u32 l = 0;
@@ -117,9 +108,9 @@ static void _set_gpio_dataout(struct gpio_bank *bank, int 
gpio, int enable)
switch (bank->method) {
case METHOD_GPIO_24XX:
if (enable)
-   reg += OMAP24XX_GPIO_SETDATAOUT;
+   reg += OMAP_GPIO_SETDATAOUT;
else
-   reg += OMAP24XX_GPIO_CLEARDATAOUT;
+   reg += OMAP_GPIO_CLEARDATAOUT;
l = 1 << gpio;
break;
default:
@@ -132,7 +123,7 @@ static void _set_gpio_dataout(struct gpio_bank *bank, int 
gpio, int enable)
 
 void omap_set_gpio_dataout(int gpio, int enable)
 {
-   struct gpio_bank *bank;
+   const struct gpio_bank *bank;
 
if (check_gpio(gpio) < 0)
return;
@@ -142,7 +133,7 @@ void omap_set_gpio_dataout(int gpio, int enable)
 
 int omap_get_gpio_datain(int gpio)
 {
-   struct gpio_bank *bank;
+   const struct gpio_bank *bank;
void *reg;
 
if (check_gpio(gpio) < 0)
@@ -151,7 +142,7 @@ int omap_get_gpio_datain(int gpio)
reg = bank->base;
switch (bank->method) {
case METHOD_GPIO_24XX:
-   reg += OMAP24XX_GPIO_DATAIN;
+   reg += OMAP_GPIO_DATAIN;
break;
default:
return -EIN

[U-Boot] [PATCH v2 4/5] omap4: support TPS programming

[Aneesh V]

TPS62361 is the new power supply used in OMAP4460 that
supplies vdd_mpu.

VCORE1 from Phoenix supplies vdd_core and VCORE2 supplies
vdd_iva. VCORE3 is not used in OMAP4460.

Signed-off-by: Aneesh V 
---
 arch/arm/cpu/armv7/omap4/board.c|4 ++
 arch/arm/cpu/armv7/omap4/clocks.c   |   65 ---
 arch/arm/include/asm/arch-omap4/clocks.h|   16 +++
 arch/arm/include/asm/arch-omap4/mux_omap4.h |1 +
 4 files changed, 79 insertions(+), 7 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap4/board.c b/arch/arm/cpu/armv7/omap4/board.c
index 3c61b1c..5943d61 100644
--- a/arch/arm/cpu/armv7/omap4/board.c
+++ b/arch/arm/cpu/armv7/omap4/board.c
@@ -90,6 +90,10 @@ static void set_muxconf_regs_essential(void)
do_set_mux(CONTROL_PADCONF_WKUP, wkup_padconf_array_essential,
   sizeof(wkup_padconf_array_essential) /
   sizeof(struct pad_conf_entry));
+
+   /* gpio_wk7 is used for controlling TPS on 4460 */
+   if (omap_revision() >= OMAP4460_ES1_0)
+   writew(M3, CONTROL_WKUP_PAD1_FREF_CLK4_REQ);
 }
 
 static void set_mux_conf_regs(void)
diff --git a/arch/arm/cpu/armv7/omap4/clocks.c 
b/arch/arm/cpu/armv7/omap4/clocks.c
index 660b329..0db9d18 100644
--- a/arch/arm/cpu/armv7/omap4/clocks.c
+++ b/arch/arm/cpu/armv7/omap4/clocks.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifndef CONFIG_SPL_BUILD
 /*
@@ -421,6 +422,34 @@ static void setup_non_essential_dplls(void)
do_setup_dpll(&prcm->cm_clkmode_dpll_abe, params, DPLL_LOCK);
 }
 
+static void do_scale_tps62361(u32 reg, u32 volt_mv)
+{
+   u32 temp, step;
+
+   step = volt_mv - TPS62361_BASE_VOLT_MV;
+   step /= 10;
+
+   /*
+* Select SET1 in TPS62361:
+* VSEL1 is grounded on board. So the following selects
+* VSEL1 = 0 and VSEL0 = 1
+*/
+   omap_set_gpio_direction(TPS62361_VSEL0_GPIO, 0);
+   omap_set_gpio_dataout(TPS62361_VSEL0_GPIO, 1);
+
+   temp = TPS62361_I2C_SLAVE_ADDR |
+   (reg << PRM_VC_VAL_BYPASS_REGADDR_SHIFT) |
+   (step << PRM_VC_VAL_BYPASS_DATA_SHIFT) |
+   PRM_VC_VAL_BYPASS_VALID_BIT;
+   debug("do_scale_tps62361: volt - %d step - 0x%x\n", volt_mv, step);
+
+   writel(temp, &prcm->prm_vc_val_bypass);
+   if (!wait_on_value(PRM_VC_VAL_BYPASS_VALID_BIT, 0,
+   &prcm->prm_vc_val_bypass, LDELAY)) {
+   puts("Scaling voltage failed for vdd_mpu from TPS\n");
+   }
+}
+
 static void do_scale_vcore(u32 vcore_reg, u32 volt_mv)
 {
u32 temp, offset_code;
@@ -461,7 +490,7 @@ static void do_scale_vcore(u32 vcore_reg, u32 volt_mv)
  */
 static void scale_vcores(void)
 {
-   u32 volt, sys_clk_khz, cycles_hi, cycles_low, temp;
+   u32 volt, sys_clk_khz, cycles_hi, cycles_low, temp, omap4_rev;
 
sys_clk_khz = get_sys_clk_freq() / 1000;
 
@@ -481,23 +510,45 @@ static void scale_vcores(void)
/* Disable high speed mode and all advanced features */
writel(0x0, &prcm->prm_vc_cfg_i2c_mode);
 
+   omap4_rev = omap_revision();
+   /* TPS - supplies vdd_mpu on 4460 */
+   if (omap4_rev >= OMAP4460_ES1_0) {
+   volt = 1430;
+   do_scale_tps62361(TPS62361_REG_ADDR_SET1, volt);
+   }
+
/*
-* VCORE 1 - 4430 : supplies vdd_mpu
+* VCORE 1
+*
+* 4430 : supplies vdd_mpu
 * Setting a high voltage for Nitro mode as smart reflex is not enabled.
 * We use the maximum possible value in the AVS range because the next
 * higher voltage in the discrete range (code >= 0b111010) is way too
 * high
+*
+* 4460 : supplies vdd_core
 */
-   volt = 1417;
-   do_scale_vcore(SMPS_REG_ADDR_VCORE1, volt);
+   if (omap4_rev < OMAP4460_ES1_0) {
+   volt = 1417;
+   do_scale_vcore(SMPS_REG_ADDR_VCORE1, volt);
+   } else {
+   volt = 1200;
+   do_scale_vcore(SMPS_REG_ADDR_VCORE1, volt);
+   }
 
/* VCORE 2 - supplies vdd_iva */
volt = 1200;
do_scale_vcore(SMPS_REG_ADDR_VCORE2, volt);
 
-   /* VCORE 3 - supplies vdd_core */
-   volt = 1200;
-   do_scale_vcore(SMPS_REG_ADDR_VCORE3, volt);
+   /*
+* VCORE 3
+* 4430 : supplies vdd_core
+* 4460 : not connected
+*/
+   if (omap4_rev < OMAP4460_ES1_0) {
+   volt = 1200;
+   do_scale_vcore(SMPS_REG_ADDR_VCORE3, volt);
+   }
 }
 
 static inline void enable_clock_domain(u32 *const clkctrl_reg, u32 enable_mode)
diff --git a/arch/arm/include/asm/arch-omap4/clocks.h 
b/arch/arm/include/asm/arch-omap4/clocks.h
index 37bdcee..5d9cb50 100644
--- a/arch/arm/include/asm/arch-omap4/clocks.h
+++ b/arch/arm/include/asm/arch-omap4/clocks.h
@@ -618,6 +618,7 @@ struct omap4_prcm_regs {
 #define PRM_VC_VAL_BYPASS_DATA_SHIFT   16
 #define PRM_VC_VAL_BYPASS_DATA_MASK   

[U-Boot] [PATCH v2 5/5] omap4: clock init support for omap4460

[Aneesh V]

---
 arch/arm/cpu/armv7/omap4/clocks.c|   61 ++---
 arch/arm/include/asm/arch-omap4/clocks.h |   12 +-
 2 files changed, 65 insertions(+), 8 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap4/clocks.c 
b/arch/arm/cpu/armv7/omap4/clocks.c
index 0db9d18..eda960c 100644
--- a/arch/arm/cpu/armv7/omap4/clocks.c
+++ b/arch/arm/cpu/armv7/omap4/clocks.c
@@ -66,7 +66,18 @@ static const u32 sys_clk_array[8] = {
  * Please use this tool for creating the table for any new frequency.
  */
 
-/* dpll locked at 1584 MHz - MPU clk at 792 MHz(OPP Turbo) */
+/* dpll locked at 1840 MHz MPU clk at 920 MHz(OPP Turbo 4460) - DCC OFF */
+static const struct dpll_params mpu_dpll_params_1840mhz[NUM_SYS_CLKS] = {
+   {230, 2, 1, -1, -1, -1, -1, -1},/* 12 MHz   */
+   {920, 12, 1, -1, -1, -1, -1, -1},   /* 13 MHz   */
+   {219, 3, 1, -1, -1, -1, -1, -1},/* 16.8 MHz */
+   {575, 11, 1, -1, -1, -1, -1, -1},   /* 19.2 MHz */
+   {460, 12, 1, -1, -1, -1, -1, -1},   /* 26 MHz   */
+   {920, 26, 1, -1, -1, -1, -1, -1},   /* 27 MHz   */
+   {575, 23, 1, -1, -1, -1, -1, -1}/* 38.4 MHz */
+};
+
+/* dpll locked at 1584 MHz - MPU clk at 792 MHz(OPP Turbo 4430) */
 static const struct dpll_params mpu_dpll_params_1584mhz[NUM_SYS_CLKS] = {
{66, 0, 1, -1, -1, -1, -1, -1}, /* 12 MHz   */
{792, 12, 1, -1, -1, -1, -1, -1},   /* 13 MHz   */
@@ -320,6 +331,47 @@ u32 omap4_ddr_clk(void)
return ddr_clk;
 }
 
+/*
+ * Lock MPU dpll
+ *
+ * Resulting MPU frequencies:
+ * 4430 ES1.0  : 600 MHz
+ * 4430 ES2.x  : 792 MHz (OPP Turbo)
+ * 4460: 920 MHz (OPP Turbo) - DCC disabled
+ */
+void configure_mpu_dpll(void)
+{
+   const struct dpll_params *params;
+   struct dpll_regs *mpu_dpll_regs;
+   u32 omap4_rev, sysclk_ind;
+
+   omap4_rev = omap_revision();
+   sysclk_ind = get_sys_clk_index();
+
+   if (omap4_rev == OMAP4430_ES1_0)
+   params = &mpu_dpll_params_1200mhz[sysclk_ind];
+   else if (omap4_rev < OMAP4460_ES1_0)
+   params = &mpu_dpll_params_1584mhz[sysclk_ind];
+   else
+   params = &mpu_dpll_params_1840mhz[sysclk_ind];
+
+   /* DCC and clock divider settings for 4460 */
+   if (omap4_rev >= OMAP4460_ES1_0) {
+   mpu_dpll_regs =
+   (struct dpll_regs *)&prcm->cm_clkmode_dpll_mpu;
+   bypass_dpll(&prcm->cm_clkmode_dpll_mpu);
+   clrbits_le32(&prcm->cm_mpu_mpu_clkctrl,
+   MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_MASK);
+   setbits_le32(&prcm->cm_mpu_mpu_clkctrl,
+   MPU_CLKCTRL_CLKSEL_ABE_DIV_MODE_MASK);
+   clrbits_le32(&mpu_dpll_regs->cm_clksel_dpll,
+   CM_CLKSEL_DCC_EN_MASK);
+   }
+
+   do_setup_dpll(&prcm->cm_clkmode_dpll_mpu, params, DPLL_LOCK);
+   debug("MPU DPLL locked\n");
+}
+
 static void setup_dplls(void)
 {
u32 sysclk_ind, temp;
@@ -349,12 +401,7 @@ static void setup_dplls(void)
debug("PER DPLL locked\n");
 
/* MPU dpll */
-   if (omap_revision() == OMAP4430_ES1_0)
-   params = &mpu_dpll_params_1200mhz[sysclk_ind];
-   else
-   params = &mpu_dpll_params_1584mhz[sysclk_ind];
-   do_setup_dpll(&prcm->cm_clkmode_dpll_mpu, params, DPLL_LOCK);
-   debug("MPU DPLL locked\n");
+   configure_mpu_dpll();
 }
 
 static void setup_non_essential_dplls(void)
diff --git a/arch/arm/include/asm/arch-omap4/clocks.h 
b/arch/arm/include/asm/arch-omap4/clocks.h
index 5d9cb50..374e064 100644
--- a/arch/arm/include/asm/arch-omap4/clocks.h
+++ b/arch/arm/include/asm/arch-omap4/clocks.h
@@ -105,9 +105,11 @@ struct omap4_prcm_regs {
u32 cm_ssc_deltamstep_dpll_ddrphy;
u32 pad014[5];
u32 cm_shadow_freq_config1;
+   u32 pad0141[47];
+   u32 cm_mpu_mpu_clkctrl;
 
/* cm1.dsp */
-   u32 pad015[103];
+   u32 pad015[55];
u32 cm_dsp_clkstctrl;
u32 pad016[7];
u32 cm_dsp_dsp_clkctrl;
@@ -515,6 +517,8 @@ struct omap4_prcm_regs {
 #define CM_CLKSEL_DPLL_M_MASK  (0x7FF << 8)
 #define CM_CLKSEL_DPLL_N_SHIFT 0
 #define CM_CLKSEL_DPLL_N_MASK  0x7F
+#define CM_CLKSEL_DCC_EN_SHIFT 22
+#define CM_CLKSEL_DCC_EN_MASK  (1 << 22)
 
 #define OMAP4_DPLL_MAX_N   127
 
@@ -596,6 +600,12 @@ struct omap4_prcm_regs {
 /* CM_L3INIT_USBPHY_CLKCTRL */
 #define USBPHY_CLKCTRL_OPTFCLKEN_PHY_48M_MASK  8
 
+/* CM_MPU_MPU_CLKCTRL */
+#define MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_SHIFT 24
+#define MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_MASK  (1 << 24)
+#define MPU_CLKCTRL_CLKSEL_ABE_DIV_MODE_SHIFT  25
+#define MPU_CLKCTRL_CLKSEL_ABE_DIV_MODE_MASK   (1 << 25)
+
 /* Clock frequencies */
 #define OMAP_SYS_CLK_FREQ_38_4_MHZ 3840
 #define OMAP_SYS_CLK_IND_38_4_MHZ  6
-- 
1.7.0.4

__

Re: [U-Boot] ARM POST Tests.

[Valentin Longchamp]

On 07/19/2011 08:45 PM, Wolfgang Denk wrote:
> Dear Valentin Longchamp,
> 
> In message <4e25a2d0.1090...@keymile.com> you wrote:
>>
>> With the memory test, that takes place before the relocation, it is extremly
>> slow (even if I reduce the size of the memory tested to a very small 
>> portion).
>> Is it something you have noticed as well ?
> 
> This might be due to caches not being turned on yet?
> 

This may explain one part of the issue.

I have done a little bit of profiling this morning, and the main culprit is the
call to getenv_f in post_get_flags for the four environment variables:

"post_poweron", "post_normal", "post_slowtest" "post_critical"

This is extremly slow on my system (before relocation). The goal of these env
variables is, I guess, to define the name of the tests that have to be run for
each post level, right ? Is this the only way to define which tests are to be 
run ?

-- 
Valentin Longchamp
Embedded Software Engineer
Hardware and Chip Integration
__
KEYMILE AG
Schwarzenburgstr. 73
CH-3097 Liebefeld
Phone +41 31 377 1318
Fax   +41 31 377 1212
valentin.longch...@keymile.com
www.keymile.com
__
KEYMILE: A Specialist as a Partner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

[David Jander]

Hi Aneesh,

On Wed, 20 Jul 2011 15:59:42 +0530
Aneesh V  wrote:
> On Wednesday 20 July 2011 02:51 PM, David Jander wrote:
> > On Wed, 20 Jul 2011 10:56:07 +0200
> 
> [snip ..]
> 
> >>> Any ideas?
> >>
> >> Yes, one: I had issues with the Marvell Ethernet adapter, which has DMA
> >> as well, not because of cache (it was not active at the time) but
> >> because of instruction reordering done by the compiler when optimizing,
> >> which resulted in out-of-order accesses to the descritpors and DMA
> >> registered, so that the DMA start was written before the descriptors
> >> were set up. The (proper and clean) solution was to introduce memory
> >> barriers at strategic points of the driver to ensure that specific DMA
> >> starts were done only after all writes to the descriptors (and possibly
> >> buffers).
> >
> > Hmmm. I know that issue, but AFAICS, the driver already uses readX() and
> > writeX() macros when accessing register and DMA memory. Those macros have
> > compiler barriers included and armv7 is still in-order execution ;-)
> 
> 1. armv7 is not necessarily in-order. Cortex-A8 is in-order while
> Cortex-A9 is out-of-order.
> 2. I am not sure if in-order execution guarantees memory ordering. My
> understanding is that it doesn't.
> 3. In u-boot's implementation of MMU for ARM, the register
> space(everything other than SDRAM) is 'strongly-ordered' memory.
> Strongly ordered accesses will be correctly ordered w.r.to all other
> accesses in program order.

Wow, I hadn't noticed dcache_enable() also enables the MMU. Cool. One step
closer to splitting the mapping between a cached and uncached, strongly-ordered
region of RAM.

> 4. Compiler barriers prevent the compiler from doing certain
> optimizations, but doesn't help in these situations.

Thanks for this excellent summary!

> In short, I think you don't need to worry about ordering, but not
> because of compiler barriers or armv7 being in-order.

Well, I do need to worry about the buffer-descriptors and buffers then, since
they are in SDRAM, right?

Best regards,

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

Re: [U-Boot] [PATCH] powerpc/8xxx: Update USB mode device tree fixup

[Wolfgang Denk]

Dear Mehresh Ramneek-B31383,

In message 
<16867771548d2f469f1a8f817f38278820a...@039-sn1mpn1-003.039d.mgd.msft.net> you 
wrote:
> 
> I just checked that this error comes when you don't have any of the following 
> defined in the board file:
> CONFIG_USB_UHCI
> CONFIG_USB_OHCI
> CONFIG_USB_EHCI
> CONFIG_USB_OHCI_NEW
> ...
> MPC837xRDB has EHCI host controller. Hence, CONFIG_USB_EHCI and its relevant 
> support macros should be defined in include/configs/MPC837XERDB.h file.

No, I disagree.  It must be possible to configure such a port without
USB as well.  Not all boards based on this processer ever want to use
USB (or even have it on their boards).

Please fix this in a way that no such definitions are ever mandatory.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Your csh still thinks true is false. Write to your vendor  today  and
tell them that next year Configure ought to "rm /bin/csh" unless they
fix  their blasted shell. :-)
 - Larry Wall in Configure from the perl distribution
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

[Aneesh V]

Hi David,

On Wednesday 20 July 2011 05:01 PM, David Jander wrote:
>
> Hi Aneesh,
>
> On Wed, 20 Jul 2011 15:59:42 +0530
> Aneesh V  wrote:
>> On Wednesday 20 July 2011 02:51 PM, David Jander wrote:
>>> On Wed, 20 Jul 2011 10:56:07 +0200
>>
>> [snip ..]
>>
> Any ideas?

 Yes, one: I had issues with the Marvell Ethernet adapter, which has DMA
 as well, not because of cache (it was not active at the time) but
 because of instruction reordering done by the compiler when optimizing,
 which resulted in out-of-order accesses to the descritpors and DMA
 registered, so that the DMA start was written before the descriptors
 were set up. The (proper and clean) solution was to introduce memory
 barriers at strategic points of the driver to ensure that specific DMA
 starts were done only after all writes to the descriptors (and possibly
 buffers).
>>>
>>> Hmmm. I know that issue, but AFAICS, the driver already uses readX() and
>>> writeX() macros when accessing register and DMA memory. Those macros have
>>> compiler barriers included and armv7 is still in-order execution ;-)
>>
>> 1. armv7 is not necessarily in-order. Cortex-A8 is in-order while
>> Cortex-A9 is out-of-order.
>> 2. I am not sure if in-order execution guarantees memory ordering. My
>> understanding is that it doesn't.
>> 3. In u-boot's implementation of MMU for ARM, the register
>> space(everything other than SDRAM) is 'strongly-ordered' memory.
>> Strongly ordered accesses will be correctly ordered w.r.to all other
>> accesses in program order.
>
> Wow, I hadn't noticed dcache_enable() also enables the MMU. Cool. One step
> closer to splitting the mapping between a cached and uncached, 
> strongly-ordered
> region of RAM.

Yes. MMU is enabled with an identity mapping. Please note that ARMv6
onwards D-cache can not be enabled when MMU is disabled. I-cache works
without MMU enabled.

>
>> 4. Compiler barriers prevent the compiler from doing certain
>> optimizations, but doesn't help in these situations.
>
> Thanks for this excellent summary!
>
>> In short, I think you don't need to worry about ordering, but not
>> because of compiler barriers or armv7 being in-order.
>
> Well, I do need to worry about the buffer-descriptors and buffers then, since
> they are in SDRAM, right?

Yes, you need to worry about buffers and descriptors. Here are the
rules-of-thumb to take care of them:

1. Flush before initiating memory to peripheral DMA(this applies to
descriptors too)
2. Invalidate after peripheral to memory DMA (before the CPU reads
the buffer)
3. Make sure that any buffer that you have to invalidate is cache-line
aligned at the beginning and at the end.

br,
Aneesh

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

Re: [U-Boot] [PATCH 1/4] gpio: Adds GPIO driver support for Armada100

[Wolfgang Denk]

Dear Ajay Bhargav,

In message <794341286.33968.1311143785027.javamail.r...@ahm.einfochips.com> you 
wrote:
> 
> > Is there any specific reason for not using u32 for the padding as
> > well?
> > 
> nothing specific. It makes easy to find number of bytes than words.

If there is no specific reason (which I could not think of either),
then please use u32 consistently.

If you think in number of bytes, feel free to write

u32 reserved[128/sizeof(u32)];

> > Why would you need this BASE + OFFSET notation when using a C struct
> > for the registers? Thi smakes little sense to me.
> 
> Well I did use the C struct method, if you see my patches submitted earlier
> but according to Prafulla and Lie structure size is too big. so they want me

Who cares about the size of the struct?  We never alocate any memory
for such a structure - it is just an overlay over the existing
register space, so nobody cares if this is 16 kB of 16 MB.

> to use a mix of C struct and BASE + OFFSET notation. so I thought to break 
> the big
> C struct into smaller grouped structures pointing each group with GPIO base + 
> group
> offset. I would be glad if you can suggest me something better or smarter.

This may make sense of you have separate, logically independent IP
blocks.  But the reason for such a desicion is if the data belong
together in any way or not.

The "size" of such a structure is completely irrelevant.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Pray to God, but keep rowing to shore. - Russian Proverb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] integrator: convert to new build system

[Wolfgang Denk]

Dear Linus Walleij,

In message  
you wrote:
>
> > Would it not make
> > sense to omit these file alltogether then, and let the entries in
> > boards.cfg point to the generic files integratorap.h resp.
> > integratorcp.h instead?
> 
> This row in the global Makefile is the reason:
> 
> sinclude $(obj).boards.depend
> $(obj).boards.depend:   boards.cfg
> awk '(NF && $$1 !~ /^#/) { print $$1 ": " $$1 "_config;
> $$(MAKE)" }' $< > $@
> 
> It requires one *_config per board variant.

Right.  But it does NOT require that each board has it's own file in
include/configs/.h

> Any hints?

Well, for example, the following different boards and board
configurations all shar the same board config file
(include/configs/TQM823L.h) : TQM823L, TQM823L_LCD, TTTech and wtk

The same should be done for the integrator boards, too.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
As in certain cults it is possible to kill a process if you know  its
true name.  -- Ken Thompson and Dennis M. Ritchie
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] gpio: Adds GPIO driver support for Armada100

[Lei Wen]

Hi Ajay,

On Wed, Jul 20, 2011 at 6:43 PM, Ajay Bhargav
 wrote:
> Hi Lei,
>
>> I think we make thing complicated here. For GPIO driver, the only
>> structure we need to
>> define is the GPIO register itself, like GPIO_PLR, GPIO_PDR, etc...
>>
>
> I got your point, but lemme show you where the problem is..
> GPIO_PLR0    0x
> GPIO_PLR1    0x0004
> GPIO_PLR2    0x0008
> GPIO_PLR3    0x0100
>
> till 3 registers its fine... fourth register is way out of league.
>

I know this is a bit tricky, but couldn't be included in a logic
hidden by MACRO or funcion?

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

Re: [U-Boot] [PATCH 1/4] gpio: Adds GPIO driver support for Armada100

[Wolfgang Denk]

Dear Ajay Bhargav,

In message <1499501074.35394.1311158638174.javamail.r...@ahm.einfochips.com> 
you wrote:
> Hi Lei,
> 
> > I think we make thing complicated here. For GPIO driver, the only
> > structure we need to
> > define is the GPIO register itself, like GPIO_PLR, GPIO_PDR, etc...
> > 
> 
> I got your point, but lemme show you where the problem is..
> GPIO_PLR00x
> GPIO_PLR10x0004
> GPIO_PLR20x0008
> GPIO_PLR30x0100
> 
> till 3 registers its fine... fourth register is way out of league.

In which way?  Just because there is a gap between?  No problem.
Insert a filler element to your struct.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
How many seconds are there in a year? If I tell you there are 3.155 x
10^7, you won't even try to remember it. On the other hand, who could
forget that, to within half a percent, pi seconds is  a  nanocentury.
   -- Tom Duff, Bell Labs
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM POST Tests.

[Wolfgang Denk]

Dear Valentin Longchamp,

In message <4e26b523.3070...@keymile.com> you wrote:
>
> I have done a little bit of profiling this morning, and the main culprit is 
> the
> call to getenv_f in post_get_flags for the four environment variables:
> 
> "post_poweron", "post_normal", "post_slowtest" "post_critical"
> 
> This is extremly slow on my system (before relocation). The goal of these env

Are you by chance reading the environment from I2C attached EEPROM or
so?  This is indeed a speed killer.

> variables is, I guess, to define the name of the tests that have to be run for
> each post level, right ? Is this the only way to define which tests are to be 
> run ?

To define the tests to be run, and the reaction that is needed if a
test fails.

If your environment accesses are so slow, you should fix that anyway.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You don't need a weatherman to know which way the wind blows.
  - Bob Dylan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] gpio: Adds GPIO driver support for Armada100

[Ajay Bhargav]

- "Lei Wen"  wrote:

> Hi Ajay,
> 
> On Wed, Jul 20, 2011 at 6:43 PM, Ajay Bhargav
>  wrote:
> > Hi Lei,
> >
> >> I think we make thing complicated here. For GPIO driver, the only
> >> structure we need to
> >> define is the GPIO register itself, like GPIO_PLR, GPIO_PDR,
> etc...
> >>
> >
> > I got your point, but lemme show you where the problem is..
> > GPIO_PLR0    0x
> > GPIO_PLR1    0x0004
> > GPIO_PLR2    0x0008
> > GPIO_PLR3    0x0100
> >
> > till 3 registers its fine... fourth register is way out of league.
> >
> 
> I know this is a bit tricky, but couldn't be included in a logic
> hidden by MACRO or funcion?
> 
> Best regards,
> Lei
> 

Hi Lei,

I am rewriting the whole logic. Will submit the patch soon :)
I will use function to get base address.

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

Re: [U-Boot] ARM POST Tests.

[Valentin Longchamp]

On 07/20/2011 02:20 PM, Wolfgang Denk wrote:
> Dear Valentin Longchamp,
> 
> In message <4e26b523.3070...@keymile.com> you wrote:
>>
>> I have done a little bit of profiling this morning, and the main culprit is 
>> the
>> call to getenv_f in post_get_flags for the four environment variables:
>>
>> "post_poweron", "post_normal", "post_slowtest" "post_critical"
>>
>> This is extremly slow on my system (before relocation). The goal of these env
> 
> Are you by chance reading the environment from I2C attached EEPROM or
> so?  This is indeed a speed killer.


Yeah I had just figured that out by myself: our environement variables are in an
I2C EEPROM, so every read is extremely slow at this poin in the boot process.
For the second POST run (from RAM this time), the environment is then in RAM
(thanks to env_relocate) and thus the calls to getenv_f much quicker.

> 
>> variables is, I guess, to define the name of the tests that have to be run 
>> for
>> each post level, right ? Is this the only way to define which tests are to 
>> be run ?
> 
> To define the tests to be run, and the reaction that is needed if a
> test fails.
> 
> If your environment accesses are so slow, you should fix that anyway.
> 

We are currently planning to move away from I2C EEPROM for environment (for
future hardware), but what would you advise me to do for our current hardware
where the environment is in this EEPROM ?

-- 
Valentin Longchamp
Embedded Software Engineer
Hardware and Chip Integration
__
KEYMILE AG
Schwarzenburgstr. 73
CH-3097 Liebefeld
Phone +41 31 377 1318
Fax   +41 31 377 1212
valentin.longch...@keymile.com
www.keymile.com
__
KEYMILE: A Specialist as a Partner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

[Albert ARIBAUD]

Le 19/07/2011 22:11, J. William Campbell a écrit :

> If this is true, then it means that the cache is of type write-back (as
> opposed to write-thru). From a (very brief) look at the arm7 manuals, it
> appears that both types of cache may be present in the cpu. Do you know
> how this operates?

Usually, copyback (rather than writeback) and writethough are modes of 
operation, not cache types.

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

Re: [U-Boot] ARM POST Tests.

[Wolfgang Denk]

Dear Valentin Longchamp,

In message <4e26cad9.3090...@keymile.com> you wrote:
>
> We are currently planning to move away from I2C EEPROM for environment (for
> future hardware), but what would you advise me to do for our current hardware
> where the environment is in this EEPROM ?

This depends on the specific features of your hardware.2s

Eventually you can increase the I2C clock.

Or use a h/w I2C driver instead of the soft-I2C driver.

Eventually you have plenty of memory that is available early (say,
several MB of L2 cache or so :-) and you can read the whole
environment into "RAM" in one rush.

Except for that there is little we can do. I2C is a PITA, also
reliability-wise.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I'm a soldier, not a diplomat.  I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] powerpc/8xxx: Update USB mode device tree fixup

[Mehresh Ramneek-B31383]

Hi Wolfgang,

I agree with you that there may be some boards that have USB (on soc) but do 
not use it.

But in that case, they should not define CONFIG_HAS_FSL_DR_USB in their board 
file.

usb.h file has a logic that if this file is included, and the USB protocol is 
not defined then it throws compilation error (which is correct because the 
driver will not be able to perform low level initialization which is specific 
to a protocol)

The issue here is that we have some boards that are declaring that they have 
USB (by defining CONFIG_HAS_FSL_DR_USB), but they are not defining the protocol 
itself. This issue is not related to including  file or using any macro 
from within it.

What's the point of declaring the availability of an IP on a board without 
mentioning the protocol being used by this IP !!

In case the board is not using USB, CONFIG_HAS_FSL_DR_USB should not be defined 
in the board file itself.

Even if I make changes for not using a macro defined in  file, the issue 
will still remain for boards defining CONFIG_HAS_FSL_DR_USB (without defining 
protocol) and using  file...

Thanks and Regards,
Ramneek 

-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de] 
Sent: Wednesday, July 20, 2011 5:35 PM
To: Mehresh Ramneek-B31383
Cc: Phillips Kim-R1AAHA; Gala Kumar-B11780; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] powerpc/8xxx: Update USB mode device tree fixup

Dear Mehresh Ramneek-B31383,

In message 
<16867771548d2f469f1a8f817f38278820a...@039-sn1mpn1-003.039d.mgd.msft.net> you 
wrote:
> 
> I just checked that this error comes when you don't have any of the following 
> defined in the board file:
> CONFIG_USB_UHCI
> CONFIG_USB_OHCI
> CONFIG_USB_EHCI
> CONFIG_USB_OHCI_NEW
> ...
> MPC837xRDB has EHCI host controller. Hence, CONFIG_USB_EHCI and its relevant 
> support macros should be defined in include/configs/MPC837XERDB.h file.

No, I disagree.  It must be possible to configure such a port without USB as 
well.  Not all boards based on this processer ever want to use USB (or even 
have it on their boards).

Please fix this in a way that no such definitions are ever mandatory.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Your 
csh still thinks true is false. Write to your vendor  today  and tell them that 
next year Configure ought to "rm /bin/csh" unless they fix  their blasted 
shell. :-)
 - Larry Wall in Configure from the perl distribution


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

[U-Boot] [RFC PATCH] armv7: setup vector

[Aneesh V]

The vector is not correctly setup in armv7 except for OMAP3.
Correcting this.

Signed-off-by: Aneesh V 
Cc: Albert Aribaud 
---
 arch/arm/cpu/armv7/start.S |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 89ea01f..9ffdfe2 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 .globl _start
 _start: b  reset
@@ -143,6 +144,15 @@ reset:
orr r0, r0, #0xd3
msr cpsr,r0
 
+   /* Set V=0 in CP15 SCTRL register - for VBAR to point to vector */
+   mrc p15, 0, r0, c1, c0, 0   @ Read CP15 SCTRL Register
+   bic r0, #CR_V   @ V = 0
+   mcr p15, 0, r0, c1, c0, 0   @ Write CP15 SCTRL Register
+
+   /* Set vector address in CP15 VBAR register */
+   ldr r0, =_start
+   mcr p15, 0, r0, c12, c0, 0  @Set VBAR
+
 #if defined(CONFIG_OMAP34XX)
/* Copy vectors to mask ROM indirect addr */
adr r0, _start  @ r0 <- current position of code
-- 
1.7.0.4

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

[U-Boot] [PATCH] [v3] [upstream] powerpc/85xx: Adding configuration for DCSRCR to enable 32M access

[Stephen George]

Configuring DCSRCR to define the DCSR space to be 1G instead
of the default 4M. DCSRCR only allows selection of either 4M
or 1G.
Most DCSR registers are within 4M but the Nexus trace buffer
is located at offset 16M within the DCSR.

Configuring the LAW to be 32M to allow access to the Nexus
trace buffer. No TLB modification is required since accessing
the Nexus trace buffer from within u-boot is not required.

Signed-off-by: Stephen George 
---
 arch/powerpc/cpu/mpc85xx/cpu_init.c   |   11 +++
 arch/powerpc/include/asm/immap_85xx.h |7 ++-
 board/freescale/corenet_ds/law.c  |3 ++-
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 6becd5b..36d5cf5 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -223,6 +223,10 @@ static void corenet_tb_init(void)
 void cpu_init_f (void)
 {
extern void m8560_cpm_reset (void);
+#ifdef CONFIG_SYS_DCSRBAR_PHYS
+   ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+#endif
+
 #ifdef CONFIG_MPC8548
ccsr_local_ecm_t *ecm = (void *)(CONFIG_SYS_MPC85xx_ECM_ADDR);
uint svr = get_svr();
@@ -270,6 +274,13 @@ void cpu_init_f (void)
 
/* Invalidate the CPC before DDR gets enabled */
invalidate_cpc();
+
+ #ifdef CONFIG_SYS_DCSRBAR_PHYS
+   /* set DCSRCR so that DCSR space is 1G */
+   setbits_be32(&gur->dcsrcr, FSL_CORENET_DCSR_SZ_1G);
+   in_be32(&gur->dcsrcr);
+#endif
+
 }
 
 /* Implement a dummy function for those platforms w/o SERDES */
diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index abba9f5..398d9d2 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1772,7 +1772,8 @@ typedef struct ccsr_gur {
u32 cgencrl;/* Core general control */
u8  res31[184];
u32 sriopstecr; /* SRIO prescaler timer enable control */
-   u8  res32[1788];
+   u32 dcsrcr; /* DCSR Control register */
+   u8  res32[1784];
u32 pmuxcr; /* Pin multiplexing control */
u8  res33[60];
u32 iovselsr;   /* I/O voltage selection status */
@@ -1785,6 +1786,10 @@ typedef struct ccsr_gur {
u8  res37[380];
 } ccsr_gur_t;
 
+#define FSL_CORENET_DCSR_SZ_MASK   0x0003
+#define FSL_CORENET_DCSR_SZ_4M 0x0
+#define FSL_CORENET_DCSR_SZ_1G 0x3
+
 /*
  * On p4080 we have an LIODN for msg unit (rmu) but not maintenance
  * everything after has RMan thus msg unit LIODN is used for maintenance
diff --git a/board/freescale/corenet_ds/law.c b/board/freescale/corenet_ds/law.c
index dd6f6f7..58f23c5 100644
--- a/board/freescale/corenet_ds/law.c
+++ b/board/freescale/corenet_ds/law.c
@@ -37,7 +37,8 @@ struct law_entry law_table[] = {
 #endif
SET_LAW(PIXIS_BASE_PHYS, LAW_SIZE_4K, LAW_TRGT_IF_LBC),
 #ifdef CONFIG_SYS_DCSRBAR_PHYS
-   SET_LAW(CONFIG_SYS_DCSRBAR_PHYS, LAW_SIZE_4M, LAW_TRGT_IF_DCSR),
+   /* Limit DCSR to 32M to access NPC Trace Buffer */
+   SET_LAW(CONFIG_SYS_DCSRBAR_PHYS, LAW_SIZE_32M, LAW_TRGT_IF_DCSR),
 #endif
 #ifdef CONFIG_SYS_NAND_BASE_PHYS
SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
-- 
1.7.1


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

Re: [U-Boot] Uboot tool Makefile patch for Mac OSX Snow leopard

[sungyeon hwang]

Dear Jeroen.

The patch file that i uploaded before is for u-boot tools for snow leopard 
10.6.8.
I think http://patchwork.ozlabs.org/patch/105538/ will resolve for snow leopard 
environment.

Regards
sungyeon.

On Jul 19, 2011, at 11:38 PM, Jeroen wrote:

> Hello Sungyeon / Mike,
> 
> I am not sure what the exact purpose of this patch is, but seems like the 
> issue
> I encountered with .depends (not finding the files in the correct path).
> 
> http://patchwork.ozlabs.org/patch/98316/
> 
> You might want to check if this helps:
> http://patchwork.ozlabs.org/patch/105538/
> 
> Mike:
> "could you provide some real details as to what the problem is you're hitting
> and why/how this fixes things ?  2011.03 builds fine for me on leopard (10.5).
> -mike"
> 
> Which sed version are you using on the mac? I don't know, but I am tempted to
> think it doesn't ship sed with GNU extension by default.
> 
> Regards,
> Jeroen
> 
> 
> 
> 
> 
> 

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

Re: [U-Boot] [PATCH] [v3] [upstream] powerpc/85xx: Adding configuration for DCSRCR to enable 32M access

[Kumar Gala]

On Jul 20, 2011, at 9:47 AM, Stephen George wrote:

> Configuring DCSRCR to define the DCSR space to be 1G instead
> of the default 4M. DCSRCR only allows selection of either 4M
> or 1G.
> Most DCSR registers are within 4M but the Nexus trace buffer
> is located at offset 16M within the DCSR.
> 
> Configuring the LAW to be 32M to allow access to the Nexus
> trace buffer. No TLB modification is required since accessing
> the Nexus trace buffer from within u-boot is not required.
> 
> Signed-off-by: Stephen George 
> ---
> arch/powerpc/cpu/mpc85xx/cpu_init.c   |   11 +++
> arch/powerpc/include/asm/immap_85xx.h |7 ++-
> board/freescale/corenet_ds/law.c  |3 ++-
> 3 files changed, 19 insertions(+), 2 deletions(-)

in the future:

1. when posting upstream (reset internal counter [v3])
2. don't CC internal list
3. dont need [upstream] in the subject

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

[U-Boot] Get these great inspirational books and songs

[Great Promos Inc]

 Hi, 
“The determination to explore new ways of doing things, especially by reading
important life changing books, easily brings about a sustainable progressive
and successful life” --G.P.I.

Among these great highly motivational and inspirational books are;-
 
‘WAYS OF ATTAINING BUSINESS SUCCESSES’
‘Achieving True Love And Lasting Relationship’
‘DISCOVERING SECRETS OF SUCCESS AND RICHES’
‘OVERCOMING LIFE DIFFICULTIES’
‘IMPOSSIBILITY TO POSSIBILITY’
‘RELATIONSHIPS THAT WORK’
‘CAREER DEVELOPMENT AND MANAGEMENT’
‘IDEAS THAT CREATE WEALTH’
‘TACKLING PROBLEMS IN RELATIONSHIPS’
‘GREAT SUCCESS HABITS’
 
Written by the renowned multi-talented writer, Ambrose Nwaopara Jr., are
available online for the development of all categories of people. 
Follow Ambrose at  www.myspace.com/4ambrose. At the upper left general
information section, click on the website link to down load the new e-book
version of the books. For the print version, go to:  www.wordclay.com , click
on bookstore and search for ‘Ambrose Nwaopara Jr. books’ or visit: 
www.amazon.com  and search. 
 
The books are also available in India at:  www.flipkart.com 

Make that choice today for a better future and try to be part of the great
life changing benefits of the books. 

Also available, are the highly inspirational songs from the 2011 album ‘Arise
and shine’, which can be found at:  http://www.cdbaby.com/cd/chidiambrose1 or
http://www.amazon.co.uk/Chidi-Ambrose/dp/B004I03AAK
 or http://itunes.apple.com/us/album/arise-and-shine/id413225675 
 
Hurry now and get the promotional copies.
 
Best wishes and have a great well fulfilled and lovely life.
 
Message Powered by:
Great Promos Inc.

Please note that this very important life improvement message is for public
good and not intended as a spam. Any one can take advantage of the benefits of
the message, or may be kindly ignored for anyone that may not be interested.

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

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

[J. William Campbell]

On 7/20/2011 7:35 AM, Albert ARIBAUD wrote:
> Le 20/07/2011 16:01, J. William Campbell a écrit :
>> On 7/20/2011 6:02 AM, Albert ARIBAUD wrote:
>>> Le 19/07/2011 22:11, J. William Campbell a écrit :
>>>
 If this is true, then it means that the cache is of type write-back 
 (as
 opposed to write-thru). From a (very brief) look at the arm7 
 manuals, it
 appears that both types of cache may be present in the cpu. Do you 
 know
 how this operates?
>>> Usually, copyback (rather than writeback) and writethough are modes of
>>> operation, not cache types.
>> Hi Albert,
>> One some CPUs both cache modes are available. On many other CPUs (I
>> would guess most), you have one fixed mode available, but not both. I
>> have always seen the two modes described as write-back and
>> write-through, but I am sure we are talking about the same things.
>
> We are. Copy-back is another name for write-back, not used by ARM but 
> by some others.
>
>> The
>> examples that have both modes that I am familiar with have the mode as a
>> "global" setting. It is not controlled by bits in the TLB or anything
>> like that. How does it work on ARM? Is it fixed, globally, globally
>> controlled, or controlled by memory management?
>
> Well, it's a bit complicated, because it depends on the architecture 
> version *and* implementation -- ARM themselves do not mandate things, 
> and it is up to the SoC designer to specify what cache they want and 
> what mode it supports, both at L1 and L2, in their specific instance 
> of ARM cores. And yes, you can have memory areas that are write-back 
> and others that are write-through in the same system.
>
>> If it is controlled by memory management, it looks to me like lots of
>> problems could be avoided by operating with input type buffers set as
>> write-through. One probably isn't going to be writing to input buffers
>> much under program control anyway, so the performance loss should be
>> minimal. This gets rid of the alignment restrictions on these buffers
>> but not the invalidate/flush requirements.
>
> There's not much you can do about alignment issues except align to 
> cache line boundaries.
>
>> However, if memory management
>> is required to set the cache mode, it might be best to operate with the
>> buffers and descriptors un-cached. That gets rid of the flush/invalidate
>> requirement at the expense of slowing down copying from read buffers.
>
> That makes 'best' a subjective choice, doesn't it? :)
Hi All,
 Yes,it probably depends on the usage.
>
>> Probably a reasonable price to pay for the associated simplicity.
>
> Others would say that spending some time setting up alignments and 
> flushes and invalidates is a reasonable price to pay for increased 
> performance... That's an open debate where no solution is The Right 
> One(tm).
>
> For instance, consider the TFTP image reading. People would like the 
> image to end up in cached memory because we'll do some checksumming on 
> it before we give it control, and having it cached makes this step 
> quite faster; but we'll lose that if we put it in non-cached memory 
> because it comes through the Ethernet controller's DMA; and it would 
> be worse to receive packets in non-cached memory only to move their 
> contents into cached memory later on.
>
> I think properly aligning descriptors and buffers is enough to avoid 
> the mixed flush/invalidate line issue, and wisely putting instruction 
> barriers should be enough to get the added performance of cache 
> without too much of the hassle of memory management.
I am pretty sure that all the drivers read the input data into 
intermediate buffers in all cases. There is no practical way to be sure 
the next packet received is the "right one" for the tftp. Plus there are 
headers involved, and furthermore there is no way to ensure that a tftp 
destination is located on a sector boundary. In short, you are going to 
copy from an input buffer to a destination.
However, it is still correct that copying from an non-cached area is 
slower than from cached areas, because of burst reads vs. individual 
reads. However, I doubt that the u-boot user can tell the difference, as 
the network latency will far exceed the difference in copy time. The 
question is, which is easier to do, and that is probably a matter of 
opinion. However, it is safe to say that so far a cached solution has 
eluded us. That may be changing, but it would still be nice to know how 
to allocate a section of un-cached RAM in the ARM processor, in so far 
as the question has a single answer! That would allow easy portability 
of drivers that do not know about caches, of which there seems to be many.

Best Regards,
Bill Campbell
>
>> Best Regards,
>> Bill Campbell
>
> Amicalement,

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

Re: [U-Boot] [PATCH v2 0/5] arm: omap4: omap4460 support

[Paulraj, Sandeep]

> 
> OMAP4460 is the latest addition to the OMAP4 family.
> OMAP4460 has dual core Cortex-A9 CPUs that can be clocked upto
> 1.5 GHz
> 
> The memory architecture has been improved to provide better
> performance and there several other minor improvements in various
> modules.
> 
> This series depends on the OMAP4 spl series [1] and the SPL framework
> series [2]
> 
> [1] http://marc.info/?l=u-boot&m=131082102506002&w=2
> [2] http://marc.info/?l=u-boot&m=131056990001719&w=2

Wolfgang, Albert,

If it is OK with you I'd like to pull in all the 3 patch sets into u-boot-ti.

This would also include the patch set to update the SPL framework.


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

[U-Boot] We Have Been Trying To Reach You!!!

[rpleal]

Nokia has Approved you of GBP £750,000.00. For claim contact: Mr. David Bassett
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] command "sspi": add write-only flag '.w' (discard read data)

[Andreas Pretzsch]

Am Montag, den 18.07.2011, 13:49 -0400 schrieb Mike Frysinger:
> On Sat, Jul 16, 2011 at 13:32, Andreas Pretzsch wrote:
> > The sspi command writes the given data out on SPI and prints the data it
> > reads to the console. For write-only slaves (i.e. a SPI-connected latch
> > used as output expander), this is pointless and clutters the console.
> > When called as "sspi.w", this output is omitted.
> >
> > The flag is optional and backwards compatible, previous sspi revisions
> > would simply ignore the flag (checked back to 2011.03).
> 
> i think the flag is misleading.  "sspi.w" makes it sound like it'd
> call the SPI layer with a NULL read buffer and not simply omit the
> output.  what you describe is more like a "quiet" flag.

Correct, strictly speaking.
I chose it from a usage perspective, hence the "write", but ".q" for
quiet or similar would also have been possible. "write" just felt more
natural to me.

I also thought about passing NULL for the read buffer, but a quick
browse through the code showed that most, but not all SPI drivers are
prepared for that. And as there is already a static rx buffer in the spi
command code, I preferred to keep a few needless byte copies over fixing
all the spi drivers...

On the long run, the sspi command should be reworked anyway, as today
the read data is not usable in a script, it's just dumped to the
console.
Following the common U-Boot way to do this, I'd suggest
sspi [:][.]   [din_env_var]
and either never print the read result to the console (my favorite) or
only if no env variable to store is passed. To be defined, comments
welcome.

The issue here is that the current sspi command would barf due to excess
argument, hence "new" sspi usage in an env script won't work on older
U-Boot revisions, whereas this is fine with the ".w" approach.
Not really that of a problem, admittedly. Maybe I was a bit too deep in
the "don't break it if not really necessary" mode...


> along these lines, doesnt the general shell provide basic output
> redirection to support "silencing" all commands rather than having to
> add a "quiet" flag to them all ?  then your script could simply do
> "sspi ... >/dev/null" (or however u-boot does it).

Not that I know of. Just tried on hush parser, no effect. Also looks
like the whole redirect code is disabled by a #ifndef __U_BOOT__.
Maybe one could change env stdout before and after, might work, but I'd
call that grotesque...

-- 

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas Pretzsch  Tel. +49-(0)731-5521572
Hahnengasse 3 Fax: +49-(0)731-5521573
89073 Ulm, Germanyemail: a...@cn-eng.de

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

Re: [U-Boot] [PATCH] mxc_nand: fix a problem writing more than 32MB

[Scott Wood]

On Wed, 20 Jul 2011 08:55:00 +0200
Helmut Raiger  wrote:

> On 07/06/2011 07:04 PM, helmut.rai...@hale.at wrote:
> > From: Helmut Raiger
> >
> > When writing 0x4000 to the unlockend_blkaddr register, large writes to
> > a 2k page NAND sometimes fail. The current kernel driver writes 0x
> > to this register for V2 of the nand controller.
> >
> > However on an i.MX31 this also fixes writes larger than 32MB.
> > The datasheet is very unspecific, but (0x4000=16384)*2000
> > roughly fits the limits we're encountering with NAND writes.
> > This problem might be NAND chip specific.
> Any comments?

I'll apply it (with a minor formatting fix), if nobody has any more
specific information about this register.

-Scott

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

Re: [U-Boot] [PATCH] mxc_nand: fixed some typos (cosmetic)

[Scott Wood]

On Wed, 20 Jul 2011 08:53:48 +0200
Helmut Raiger  wrote:

> I know it's only typos, but could someone ack please.
> 
> Helmut

I'll apply it soon, sorry for the delay.

-Scott

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

Re: [U-Boot] [RFC] gpio command: return value on write, additional actions

[Andreas Pretzsch]

Am Donnerstag, den 07.07.2011, 12:15 +0200 schrieb Detlev Zundel:
> Hi Wolfgang,
> 
> > Dear Detlev Zundel,
> >
> > In message  you wrote:
> >> 
> >> > I'd say clear/set/toggle are changeable, don't see any legit
> >> > return-value-usage here. For 100% backward compatibility, one could
> >> > leave them as they are and use 0|1 as new actions with return 0, as
> >> > proposed.
> >
> > Hm... I think it would be beneficial to bee able to get information
> > about the current settings. For "clear" and "set" the result is known,
> > but for "toggle" it would be helpful if we returned the current port
> > state.  Eventually we should add a "test" command (or "read" ?) that
> > returns the current setting?

Regarding toggle, the typical usage would be clocking or switch some LED
or similar. In all these cases, the new value is irrelevant or could be
read by the "get value" subcommand later.
( Which implies some "get output buffer" or "switch to input", depending
on GPIO hardware structure. But this might be the case also for the
low-level GPIO driver. )
All other "clever" direct usage of the new output value of toggle sounds
to me like "write a driver" cases...
So I'd opt for "return success", as with clear/0 and set/1.

Regarding test/read, see below.


> In general the "current state" actually are three things:
> 
> 1. Port Mode: Disabled (i.e. not connected to an external pin), Input,
>Output

Already handled by the gpio_request() resp. gpio_direction_input() and
gpio_direction_output() calls. At least, it should be this way, didn't
check.

> 2. Port output value

Read by "gpio value", as output latch is always readable.

> 3. (Actually read-in) input value

Either via "gpio value" (read pin value or output latch, depending on
hardware, essentially the return of gpio_get_value()) or via "gpio
input", which would set the port to input and return its value.

> The current commands mix these aspects, i.e. they implicitely change the
> port mode.  Differentiating between 2 and 3 will not always be possible
> but is - I've seen that on e.g. an i.mx31.

Most better GPIO blocks have a register both for output latch and for
pin real value, as they have hardware toggle support.


> >> > So these variants:
> >> >   gpio clear|0 => set to output, write 0, return success
> >> >   gpio set|1   => set to output, write 1, return success
> >> >   gpio toggle  => (set to output), toggle output, return success
> >> >   gpio input   => set to input, return pin value
> >> >   gpio value   => return current pin/latch/whatever value

As I understand, this proposal is still complete and valid.
The only question (beside toggle return value) is the naming of the last
command, either "value" or "get". I'd opt for value, as get implies for
me (to some extent) switch to input.


> >> I'd propose to fix the commands to be sensible now.  Actually I believe
> >> that they should not be in heavy use "in the wild" and so we should take
> >> the opportunity and declare the current behaviour as buggy and fix it.
> >> Rather now than later ;)
> >
> > Agreed.

Great. So I'll go ahead and send a patch after we decided what exactly
to do.


> >> Actually I would expect the "output" commands to return true when they
> >> were able to do what was requestes from them, i.e. drive the requested
> >> value to the output.  I guess this cannot be done in the general case,
> >> but for a "weak output" that can be read back, this would be the most
> >> sensible thing to do.

Even with a decent GPIO module where you can read back the real pin
value also in output mode, it's not always sufficient to read back
directly (a few ns/us) after you set the output. For example, depending
on the load attached to the output, it might take some time to charge to
target level.
Beside that, you demand from the low-level GPIO layer that it won't
switch back to input by itself for a read.
While it's a neat idea at the first sight, I think it's going too far
for a script-used gpio command.


> > For consistency I would prefer to have all commands return the same
> > type of information, i. e. either an error status (like we do with all
> > other commands - any result values would then have to be passed as
> > environment settings), or we return the current port state (also for
> > the "output" commands -  see my comments for "toggle").
> 
> Actually I would prefer to return an error status for all cases and
> return "valuable information" in the environment so we can easily use it
> subsequently.  As we do not have a back-tick operator in the shell, I
> believe that return codes are only useful as error codes.

True for now, beside one usage:
if gpio value  ; then ; else ; fi
Of course, the same could be achieved with
gpio value  ; if test $? -eq 1 ; then ; else ; fi


While we're at it, adding another optional parameter to store the value
read in an environment variable sounds sensible:
gpio   [env_var]


Another point: I'd like to quiet down the gpio comman

[U-Boot] [PATCH v2 0/3] improve build for UNIX like non GNU platforms

[Jeroen Hofstee]

Changes for v2:
- updated mkconfig patch to make minimal changes and changed commit 
  message, since it now relies on GNU and BSD extensions.

Jeroen Hofstee (3):
  include/compiler.h: typedef ulong for FreeBSD
  rules.mk: replace GNU specific \w with POSIX equivalant
  mkconfig: also create CONFIG defines with BSD sed

-- 
1.7.5.4

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

[U-Boot] [PATCH v2 0/3] improve build for UNIX like non GNU platforms

[Jeroen Hofstee]

Changes for v2:
- updated mkconfig patch to make minimal changes and changed commit 
  message, since it now relies on GNU and BSD extensions.

Jeroen Hofstee (3):
  include/compiler.h: typedef ulong for FreeBSD
  rules.mk: replace GNU specific \w with POSIX equivalant
  mkconfig: also create CONFIG defines with BSD sed

-- 
1.7.5.4

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

[U-Boot] [PATCH v2 3/3] mkconfig: also create CONFIG defines with BSD sed

[Jeroen Hofstee]

Parsing of boards.cfg fails on FreeBSD with the error:

sed: 1: "/=/ {s/=/\t/;q } ; { s/ ...": extra characters at the end
of q command

BSD sed expects commands to be on seperate 'lines', hence it expects
an additional ; before the closing brackets.
BSD sed does not support \t, replaced by literal tab.

Signed-off-by: Jeroen Hofstee 
Cc: Marek Vasut 
---
 mkconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mkconfig b/mkconfig
index 6ff533f..ecb6d4e 100755
--- a/mkconfig
+++ b/mkconfig
@@ -148,7 +148,7 @@ fi
 echo "/* Automatically generated - do not edit */" >>config.h
 
 for i in ${TARGETS} ; do
-   i="`echo ${i} | sed '/=/ {s/=/\t/;q } ; { s/$/\t1/ }'`"
+   i="`echo ${i} | sed '/=/ {s/=/  /;q; } ; { s/$/ 1/; }'`"
echo "#define CONFIG_${i}" >>config.h ;
 done
 
-- 
1.7.5.4

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

[U-Boot] POST - Hardware Diagnose Commands methodologies

[Vega, Ferdinand (ESEA MESA)]

Hi,

 

I would like to know if there's any methodology or requirement documentation
available for the POST Hardware Diagnose Commands from U-Boot, for
microprocessor MPC8378?   

 

Thanks,

Ferdinand Vega

Systems Engineer II (ESEA MESA)

Honeywell Aerospace

San Antonio Industrial Park 

Road #110 North  Km. 5.9

Aguadilla, PR 00604

( 787-658-2265

*   ferdinand.v...@honeywell.com 

 

This e-mail message and any attachments are for the use of the intended
recipient(s) and may be controlled by U.S. export control laws. Any
unauthorized review, use, disclosure or distribution of this communication
in whole or in part without the express written consent of Honeywell, or the
U.S. Government as required, is prohibited. If you are not the intended
recipient(s), please contact the sender by reply e-mail and destroy the
original message and any copies of the message as well as any attachment(s)
to the original message.

 

 

 

P We have a responsibility to the environment.
Before printing this e-mail or any other document, let's ask ourselves
whether we really need a hard copy.

 



smime.p7s
Description: S/MIME cryptographic signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/5] arm: omap4: omap4460 support

[Wolfgang Denk]

Dear "Paulraj, Sandeep",

In message  you wrote:
> 
> > This series depends on the OMAP4 spl series [1] and the SPL framework
> > series [2]
> > 
> > [1] http://marc.info/?l=u-boot&m=131082102506002&w=2
> > [2] http://marc.info/?l=u-boot&m=131056990001719&w=2
> 
> Wolfgang, Albert,
> 
> If it is OK with you I'd like to pull in all the 3 patch sets into u-boot-ti.
> 
> This would also include the patch set to update the SPL framework.

I can only comment on the SPL series hier.

For this you have my:

Acked-by: Wolfgang Denk 

[I have it on my list, too, but a short glace at my desk tells me
that you will most probably be much faster than me, so please go
ahead. And thanks!]

Best regards,

Wolfgang Denk

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

Re: [U-Boot] [PATCH 0/6] Drop obsolete at91rm9200 support

[Reinhard Meyer]

Dear Wolfgang,

On 18.07.2011 21:41, Andreas Bießmann wrote:
> The series "ARM: remove broken boards" deletes the last few boards which used
> the obsolete arm920t/at91rm9200 arch code.
> This series completes it and removes the now obsolete at91rm9200 arch code
> completely. Additionally ther are some more cleanup in documentation and
> surrounding code.
>
> This series applies on top of the "ARM: remove broken boards".
>
> Andreas Bießmann (6):
>ARM: remove obsolete at91rm9200
>MAKEALL: remove obsolete at91rm9200 soc
>a/a/c/arm920t/cpu.c: remove CONFIG_AT91_LEGACY warning
>README.at91-soc: remove AT91(RM9200) joining notice
>net/eth.c: drop obsolete at91rm9200 support
>README: fix arm920t/at91 path
>
>   MAKEALL   |1 -
>   README|2 +-
>   arch/arm/cpu/arm920t/at91rm9200/Makefile  |   56 --
>   arch/arm/cpu/arm920t/at91rm9200/bcm5221.c |  232 --
>   arch/arm/cpu/arm920t/at91rm9200/dm9161.c  |  225 --
>   arch/arm/cpu/arm920t/at91rm9200/ether.c   |  316 
>   arch/arm/cpu/arm920t/at91rm9200/i2c.c |  192 -
>   arch/arm/cpu/arm920t/at91rm9200/ks8721.c  |  249 ---
>   arch/arm/cpu/arm920t/at91rm9200/lowlevel_init.S   |  169 -
>   arch/arm/cpu/arm920t/at91rm9200/lxt972.c  |  192 -
>   arch/arm/cpu/arm920t/at91rm9200/reset.c   |   71 --
>   arch/arm/cpu/arm920t/at91rm9200/spi.c |  151 
>   arch/arm/cpu/arm920t/at91rm9200/timer.c   |  160 
>   arch/arm/cpu/arm920t/at91rm9200/usb.c |   53 --
>   arch/arm/cpu/arm920t/cpu.c|4 -
>   arch/arm/include/asm/arch-at91rm9200/AT91RM9200.h |  812 
> -
>   arch/arm/include/asm/arch-at91rm9200/hardware.h   |   75 --
>   doc/README.at91-soc   |   22 -
>   net/eth.c |4 -
>   19 files changed, 1 insertions(+), 2985 deletions(-)
>   delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/Makefile
>   delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/bcm5221.c
>   delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/dm9161.c
>   delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/ether.c
>   delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/i2c.c
>   delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/ks8721.c
>   delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/lowlevel_init.S
>   delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/lxt972.c
>   delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/reset.c
>   delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/spi.c
>   delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/timer.c
>   delete mode 100644 arch/arm/cpu/arm920t/at91rm9200/usb.c
>   delete mode 100644 arch/arm/include/asm/arch-at91rm9200/AT91RM9200.h
>   delete mode 100644 arch/arm/include/asm/arch-at91rm9200/hardware.h
>

I think it would be good to apply those patches removing the old,
superseded at91rm9200 files to master instead of next.

Would that be ok?

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

Re: [U-Boot] POST - Hardware Diagnose Commands methodologies

[Wolfgang Denk]

Dear "Vega, Ferdinand (ESEA MESA)",

In message 
<7c815335a6382547a0240c3fa5f33bc9ac5...@de08ev804.global.ds.honeywell.com> you 
wrote:
> 
> I would like to know if there's any methodology or requirement documentation
> available for the POST Hardware Diagnose Commands from U-Boot, for
> microprocessor MPC8378?   

POST code is inherently very closely hardware specific.  If you read
doc/README.POST you will see that the original design of the code was
done for a MPC823E based system (LWMON, to be specific), and later it
got extended to other boards and processors as needed.

There are generic (per architecture) tests, CPU model specific tests,
SoC specific tests, standard peripheral tests, and board specific
tests.

The requirement documentation for the tests comes from your own
project - we cannot know what you need.  You can then either match
your requirements to existing code and reuse it unchanged, or youmay
have to extend / mdify it, or you may have to add completely new
pieces.

This depends on _your_ requirements.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Why can you only have two doors on a chicken coop? If it had four  it
would be a chicken sedan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/6] Drop obsolete at91rm9200 support

[Wolfgang Denk]

Dear Reinhard Meyer,

In message <4e273239.10...@emk-elektronik.de> you wrote:
>
> > The series "ARM: remove broken boards" deletes the last few boards which 
> > used
> > the obsolete arm920t/at91rm9200 arch code.
> > This series completes it and removes the now obsolete at91rm9200 arch code
> > completely. Additionally ther are some more cleanup in documentation and
> > surrounding code.
...
> I think it would be good to apply those patches removing the old,
> superseded at91rm9200 files to master instead of next.
> 
> Would that be ok?

Yes, I appreciate this.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
This was an  amazing  creation  using  small  squares  of  compressed
vegetable  matter on which letters were made by means of small carbon
particles from a stylus, giving an effect similar to the  traditional
word-processor  screen. It seemed amazingly portable and I never once
saw him have to change the batteries.
- Terry Pratchett & Stephen Briggs, _The Discworld Companion_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] mkconfig: also create CONFIG defines with BSD sed

[Mike Frysinger]

On Wed, Jul 20, 2011 at 14:38, Jeroen Hofstee wrote:
> Parsing of boards.cfg fails on FreeBSD with the error:
>
> sed: 1: "/=/ {s/=/\t/;q } ; { s/ ...": extra characters at the end
> of q command
>
> BSD sed expects commands to be on seperate 'lines', hence it expects
> an additional ; before the closing brackets.
> BSD sed does not support \t, replaced by literal tab.

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

Re: [U-Boot] [PATCH v2 0/5] arm: omap4: omap4460 support

[Paulraj, Sandeep]

> 
> Dear "Paulraj, Sandeep",
> 
> In message  you
> wrote:
> >
> > > This series depends on the OMAP4 spl series [1] and the SPL framework
> > > series [2]
> > >
> > > [1] http://marc.info/?l=u-boot&m=131082102506002&w=2
> > > [2] http://marc.info/?l=u-boot&m=131056990001719&w=2
> >
> > Wolfgang, Albert,
> >
> > If it is OK with you I'd like to pull in all the 3 patch sets into u-
> boot-ti.
> >
> > This would also include the patch set to update the SPL framework.
> 
> I can only comment on the SPL series hier.
> 
> For this you have my:
> 
> Acked-by: Wolfgang Denk 
> 
Thanks,

I'll send in a pull request tomorrow morning

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

Re: [U-Boot] [PATCH v2 0/5] arm: omap4: omap4460 support

[Paulraj, Sandeep]

> 
> OMAP4460 is the latest addition to the OMAP4 family.
> OMAP4460 has dual core Cortex-A9 CPUs that can be clocked upto
> 1.5 GHz
> 
> The memory architecture has been improved to provide better
> performance and there several other minor improvements in various
> modules.
> 
> This series depends on the OMAP4 spl series [1] and the SPL framework
> series [2]
> 
> [1] http://marc.info/?l=u-boot&m=131082102506002&w=2
> [2] http://marc.info/?l=u-boot&m=131056990001719&w=2


There is a v3 version of the SPL framework series.
You are pointing to the RFC series.

I hope your patches are based on the v3 patch series of the SPL framework.

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

Re: [U-Boot] [PATCH v3 0/9] Add initial support for a generic SPL framework

[Paulraj, Sandeep]

> 
> This is the finalized version for the SPL framework:
> http://marc.info/?l=u-boot&m=131056990001719&w=2
> 
> Changes since RFC v1:
> - added documentation for SPL framework
> - enable garbage collect of unused sections for SPL unconditionally
> 
> Changes since RFC v2:
> - renamed CONFIG_SYS_SPL_LDSCRIPT to CONFIG_SPL_LDSCRIPT
> - added missing documentation for CONFIG_SPL_LDSCRIPT
> 
> Aneesh V (3):
>   arm: adjust PLATFORM_LIBS for SPL
>   scaled down version of generic libraries for SPL
>   replace CONFIG_PRELOADER with CONFIG_SPL_BUILD
> 
> Daniel Schwierzeck (6):
>   Use ALL-y style instead of ifeq blocks for better readability
>   spl: add initial support for a generic SPL framework
>   Extend build-system for SPL framework
>   Hook SPL build-system into toplevel Makefile
>   spl: Add support for common libraries and drivers
>   spl: add support for omap-common libraries
> 

Pushed this series to u-boot-ti

http://git.denx.de/?p=u-boot/u-boot-ti.git;a=summary


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

Re: [U-Boot] [PATCH v4 00/12] U-Boot MMC SPL for OMAP4

[Paulraj, Sandeep]

> Aneesh V (11):
>   omap4: utility function to identify the context of hw init
>   omap4: cleanup pin mux data
>   omap4: add OMAP4430 revision check
>   omap4: add clock support
>   omap4: add sdram init support
>   omap4: calculate EMIF register values
>   omap4: automatic sdram detection
>   armv7: start.S: fixes and enhancements for SPL
>   omap: add basic SPL support
>   Correct ih_os for u-boot.img
>   omap: add MMC and FAT support to SPL
> 
> John Rigby (1):
>   mkimage: Add OMAP boot image support


Patch #8 of this seires does not apply on the current u-boot-ti
U-boot-ti now has the updated SPL framework

Please rebase with u-boot-ti and send updated patch sets for both your series.

Regards,
Sandeep

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

[U-Boot] [PATCH] ppc460: read get_sys_info from CPR registers instead of STRP registers

[Mike Williams]

This code has been changed to read the CPU speed information from the
CPR registers rather than the bootstrap registers. This is useful when
changing the clock speed to something other than the default on boot.

Signed-off-by: Mike Williams 
---
 arch/powerpc/cpu/ppc4xx/speed.c|   33 +--
 arch/powerpc/include/asm/ppc460ex_gt.h |   15 +-
 2 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/cpu/ppc4xx/speed.c b/arch/powerpc/cpu/ppc4xx/speed.c
index 09d6671..2643fc0 100644
--- a/arch/powerpc/cpu/ppc4xx/speed.c
+++ b/arch/powerpc/cpu/ppc4xx/speed.c
@@ -328,38 +328,33 @@ void get_sys_info(sys_info_t *sysInfo)
  */
 void get_sys_info (sys_info_t * sysInfo)
 {
-   unsigned long strp0;
-   unsigned long strp1;
+   unsigned long pllc, plld, plbed, opbd, perd;
unsigned long temp;
unsigned long m;
unsigned long plbedv0;
 
/* Extract configured divisors */
-   mfsdr(SDR0_SDSTP0, strp0);
-   mfsdr(SDR0_SDSTP1, strp1);
-
-   temp = ((strp0 & PLLSYS0_FWD_DIV_A_MASK) >> 4);
-   sysInfo->pllFwdDivA = get_cpr0_fwdv(temp);
-
-   temp = (strp0 & PLLSYS0_FWD_DIV_B_MASK);
-   sysInfo->pllFwdDivB = get_cpr0_fwdv(temp);
 
-   temp = (strp0 & PLLSYS0_FB_DIV_MASK) >> 8;
-   sysInfo->pllFbkDiv = get_cpr0_fbdv(temp);
+   mfcpr(CPR0_PLLD, plld);
+   sysInfo->pllFwdDivA = get_cpr0_fwdv((plld & PLLD_FWDVA_MASK) >> 16);
+   sysInfo->pllFwdDivB = get_cpr0_fwdv((plld & PLLD_FWDVB_MASK) >> 8);
+   sysInfo->pllFbkDiv = get_cpr0_fbdv((plld & PLLD_FBDV_MASK) >> 24);
 
-   temp = (strp1 & PLLSYS0_OPB_DIV_MASK) >> 26;
+   mfcpr(CPR0_OPBD0, opbd);
+   temp = ((opbd & OPBDV_MASK) >> 24);
sysInfo->pllOpbDiv = temp ? temp : 4;
 
-   /* AMCC_TODO: verify the SDR0_SDSTP1.PERDV0 value sysInfo->pllExtBusDiv 
*/
-   temp = (strp1 & PLLSYS0_PERCLK_DIV_MASK) >> 24;
+   mfcpr(CPR0_PERD, perd);
+   temp = ((perd & PERDV_MASK) >> 24);
sysInfo->pllExtBusDiv = temp ? temp : 4;
 
-   temp = (strp1 & PLLSYS0_PLBEDV0_DIV_MASK) >> 29;
-   plbedv0 = temp ? temp: 8;
+   mfcpr(CPR0_PLBED, plbed);
+   temp = ((plbed & PLBEDDV_MASK) >> 24);
+   plbedv0 = temp ? temp : 8;
 
/* Calculate 'M' based on feedback source */
-   temp = (strp0 & PLLSYS0_SEL_MASK) >> 27;
-   if (temp == 0) {
+   mfcpr(CPR0_PLLC, pllc);
+   if (((pllc & PLLC_FBSEL_MASK) >> 24) == 0) {
/* PLL internal feedback */
m = sysInfo->pllFbkDiv;
} else {
diff --git a/arch/powerpc/include/asm/ppc460ex_gt.h 
b/arch/powerpc/include/asm/ppc460ex_gt.h
index 732fcac..25954b9 100644
--- a/arch/powerpc/include/asm/ppc460ex_gt.h
+++ b/arch/powerpc/include/asm/ppc460ex_gt.h
@@ -211,11 +211,24 @@
 #define PLLSYS0_PERCLK_DIV_MASK 0x0300 /* Peripheral Clk Divisor */
 #define PLLSYS0_SEL_MASK   0x1800  /* 0 = PLL, 1 = PerClk */
 
-#define CPR0_ICFG_RLI_MASK 0x8000
+#define CPR0_PLBED  0x0080 /* PLL PLB Ealry Clock Divider */
+
+#define CPR0_ICFG_RLI_MASK 0x8000 /* CPR Reset Load Inhibit */
 
 #define CPR0_PLLC_RST  0x8000
 #define CPR0_PLLC_ENG  0x4000
 
+#define PLLC_FBSEL_MASK 0x0300  /* PLLC Feedback Selection */
+
+#define PLLD_FBDV_MASK 0xff00  /* PLL Feedback Divisor  */
+#define PLLD_FWDVA_MASK0x000f  /* PLL Forward Divisor A */
+#define PLLD_FWDVB_MASK0x0700  /* PLL Forward Divisor B */
+
+#define PLBEDDV_MASK0x0700  /* PLB Early Divisor */
+#define OPBDV_MASK 0x0300  /* OPB Clock Divisor Register */
+#define PERDV_MASK 0x0300  /* Periferal Clock Divisor */
+#define SPCID_MASK 0x0300  /* Sync PCI Divisor  */
+
 #define PCIL0_BRDGOPT1 (PCIL0_CFGBASE + 0x0040)
 #define PCIL0_BRDGOPT2 (PCIL0_CFGBASE + 0x0044)
 
-- 
1.7.3.4

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

[U-Boot] SAUDARA

[Cindy]

-- 
Saya anak tunggal dari orang tua saya.

Apa yang terjadi sekarang? Orang tua saya telah meninggal karena 
kecelakaan mobil. Ayah saya ternyata telah menikah dua istri. Ibu dari 
Indonesia. Kami bahagia hidup bersama di Pulau Sumatra sebelum gempa 
bumi. Setelah gempa, kami memutuskan untuk pindah ke negaranya , 
Inggris. Ini adalah pilihan ayah saya. Ternyata dia benar-benar ada 
istri lain di Inggris.

Sejak kami tiba di London, masalah datang pada setiap hari. Ayah saya 
dan ibu saya lalu meninggal pada kecelakaan motor. Sekarang ibu tiri 
saya memperlakukan saya dengan kejam. Ayah saya memiliki uang yang 
disimpan dengan nama saya di sini di Inggris. Menurut dia, uang itu bisa 
diberikan untuk saya hanya ketika saya menikah atau dengan saudara saya 
di Indonesia.

Saya butuh informasi Anda sekarang. Anda bantu saya sebagai adik saya 
atau suami saya sehingga dana bisa dilkeluarkan. Saya berjuang di neraka 
hidup untuk makan dan menjadi manusia. Tolong bantu saya karena saya di 
dalam perang kehidupan yang besar dalam bentuk emosional dan kehidupan.

SEKARANG untuk membantu saya.

Dari seorang yang butuh bantuan.
Cindy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ppc460: read get_sys_info from CPR registers instead of STRP registers

[Wolfgang Denk]

Dear Mike Williams,

In message <1311197713-13010-1-git-send-email-m...@mikebwilliams.com> you wrote:
> This code has been changed to read the CPU speed information from the
> CPR registers rather than the bootstrap registers. This is useful when
> changing the clock speed to something other than the default on boot.
...
> --- a/arch/powerpc/include/asm/ppc460ex_gt.h
> +++ b/arch/powerpc/include/asm/ppc460ex_gt.h
> @@ -211,11 +211,24 @@
>  #define PLLSYS0_PERCLK_DIV_MASK 0x0300   /* Peripheral Clk Divisor */
>  #define PLLSYS0_SEL_MASK 0x1800  /* 0 = PLL, 1 = PerClk */
>  
> -#define CPR0_ICFG_RLI_MASK   0x8000
> +#define CPR0_PLBED  0x0080 /* PLL PLB Ealry Clock Divider */

s/Ealry/Early/


And please use TABs for vertical alignment.

> +#define PERDV_MASK   0x0300  /* Periferal Clock Divisor */

s/Periferal/Peripheral/

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Hiring experienced unix people is  like  a  built-in  filter  against
idiots. Hiring experienced NT people provides no such guarantee.
-- Miguel Cruz in WgL96.349$cc.122...@typhoon2.ba-dsg.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] command "sspi": add write-only flag '.w' (discard read data)

[Mike Frysinger]

On Wednesday, July 20, 2011 13:04:47 Andreas Pretzsch wrote:
> I also thought about passing NULL for the read buffer, but a quick
> browse through the code showed that most, but not all SPI drivers are
> prepared for that. And as there is already a static rx buffer in the spi
> command code, I preferred to keep a few needless byte copies over fixing
> all the spi drivers...

those drivers are broken.  the SPI API requires them to handle NULL rx or tx 
buffers.  do not cater to broken code by avoiding fixing common code because 
of bugs in drivers.

> Following the common U-Boot way to do this, I'd suggest
>   sspi [:][.]   [din_env_var]
> and either never print the read result to the console (my favorite) or
> only if no env variable to store is passed. To be defined, comments
> welcome.

is this the common u-boot approach ?  seems like extending every random func 
to take a supplementary env var is the wrong way.  if the hush shell simply 
supported syntax like:
foo="`sspi ..`"
then every command would get this for free

> > along these lines, doesnt the general shell provide basic output
> > redirection to support "silencing" all commands rather than having to
> > add a "quiet" flag to them all ?  then your script could simply do
> > "sspi ... >/dev/null" (or however u-boot does it).
> 
> Not that I know of. Just tried on hush parser, no effect. Also looks
> like the whole redirect code is disabled by a #ifndef __U_BOOT__.
> Maybe one could change env stdout before and after, might work, but I'd
> call that grotesque...

yes, playing with stdout would be awful, but it would work today ;)
-mike


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

[U-Boot] [RFC] mmc:saveenv problem

[Song, Elen]

Hello Dear Andy:
I found in env_mmc.c, mmc_get_env_addr(...)only do *env_addr = 
CONFIG_ENV_OFFSET.If CONFIG_ENV_OFFSET is defined in partition space,the raw 
data may cover the env.IF CONFIG_ENV_OFFSET = 0,will it damage MBR?Should it do 
some protection methods?

Thank you very much
Elen.song 


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

[U-Boot] [PATCH 3/3] powerpc/85xx: Handle the lack of L2 cache on P2040/P2040E

[Kumar Gala]

The P2040/P2040E have no L2 cache.  So we utilize the SVR to determine
if we are one of these devices and skip the L2 init code in cpu_init.c
and release.  For the device tree we skip the updating of the L2 cache
properties but we still update the chain of caches so the CPC/L3 node
can be properly updated.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/cpu/mpc85xx/cpu_init.c |7 +++
 arch/powerpc/cpu/mpc85xx/fdt.c  |   23 +++
 arch/powerpc/cpu/mpc85xx/release.S  |   15 ++-
 3 files changed, 36 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 6becd5b..cb63f49 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -389,6 +389,12 @@ int cpu_init_r(void)
puts("enabled\n");
}
 #elif defined(CONFIG_BACKSIDE_L2_CACHE)
+   if ((SVR_SOC_VER(get_svr()) == SVR_P2040) ||
+   (SVR_SOC_VER(get_svr()) == SVR_P2040_E)) {
+   puts("N/A\n");
+   goto skip_l2;
+   }
+
u32 l2cfg0 = mfspr(SPRN_L2CFG0);
 
/* invalidate the L2 cache */
@@ -412,6 +418,7 @@ int cpu_init_r(void)
 #else
puts("disabled\n");
 #endif
+skip_l2:
 
enable_cpc();
 
diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index 0e8aed4..b237776 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -228,6 +228,12 @@ static inline void ft_fixup_l2cache(void *blob)
u32 *ph;
u32 l2cfg0 = mfspr(SPRN_L2CFG0);
u32 size, line_size, num_ways, num_sets;
+   int has_l2 = 1;
+
+   /* P2040/P2040E has no L2, so dont set any L2 props */
+   if ((SVR_SOC_VER(get_svr()) == SVR_P2040) ||
+   (SVR_SOC_VER(get_svr()) == SVR_P2040_E))
+   has_l2 = 0;
 
size = (l2cfg0 & 0x3fff) * 64 * 1024;
num_ways = ((l2cfg0 >> 14) & 0x1f) + 1;
@@ -250,21 +256,22 @@ static inline void ft_fixup_l2cache(void *blob)
goto next;
}
 
+   if (has_l2) {
 #ifdef CONFIG_SYS_CACHE_STASHING
-   {
u32 *reg = (u32 *)fdt_getprop(blob, off, "reg", 0);
if (reg)
fdt_setprop_cell(blob, l2_off, "cache-stash-id",
 (*reg * 2) + 32 + 1);
-   }
 #endif
 
-   fdt_setprop(blob, l2_off, "cache-unified", NULL, 0);
-   fdt_setprop_cell(blob, l2_off, "cache-block-size", line_size);
-   fdt_setprop_cell(blob, l2_off, "cache-size", size);
-   fdt_setprop_cell(blob, l2_off, "cache-sets", num_sets);
-   fdt_setprop_cell(blob, l2_off, "cache-level", 2);
-   fdt_setprop(blob, l2_off, "compatible", "cache", 6);
+   fdt_setprop(blob, l2_off, "cache-unified", NULL, 0);
+   fdt_setprop_cell(blob, l2_off, "cache-block-size",
+   line_size);
+   fdt_setprop_cell(blob, l2_off, "cache-size", size);
+   fdt_setprop_cell(blob, l2_off, "cache-sets", num_sets);
+   fdt_setprop_cell(blob, l2_off, "cache-level", 2);
+   fdt_setprop(blob, l2_off, "compatible", "cache", 6);
+   }
 
if (l3_off < 0) {
ph = (u32 *)fdt_getprop(blob, l2_off, 
"next-level-cache", 0);
diff --git a/arch/powerpc/cpu/mpc85xx/release.S 
b/arch/powerpc/cpu/mpc85xx/release.S
index 56a853e..6678ed4 100644
--- a/arch/powerpc/cpu/mpc85xx/release.S
+++ b/arch/powerpc/cpu/mpc85xx/release.S
@@ -1,5 +1,5 @@
 /*
- * Copyright 2008-2010 Freescale Semiconductor, Inc.
+ * Copyright 2008-2011 Freescale Semiconductor, Inc.
  * Kumar Gala 
  *
  * See file CREDITS for list of people who contributed to this
@@ -144,6 +144,18 @@ __secondary_start_page:
 #endif
 
 #ifdef CONFIG_BACKSIDE_L2_CACHE
+   /* skip L2 setup on P2040/P2040E as they have no L2 */
+   mfspr   r2,SPRN_SVR
+   lis r3,SVR_P2040@h
+   ori r3,r3,SVR_P2040@l
+   cmpwr2,r3
+   beq 3f
+
+   lis r3,SVR_P2040_E@h
+   ori r3,r3,SVR_P2040_E@l
+   cmpwr2,r3
+   beq 3f
+
/* Enable/invalidate the L2 cache */
msync
lis r2,(L2CSR0_L2FI|L2CSR0_L2LFC)@h
@@ -169,6 +181,7 @@ __secondary_start_page:
andis.  r1,r3,L2CSR0_L2E@h
beq 2b
 #endif
+3:
 
 #define EPAPR_MAGIC(0x45504150)
 #define ENTRY_ADDR_UPPER   0
-- 
1.7.3.4

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

[U-Boot] [PATCH 0/3] Fixups for P2041/P2040 support

[Kumar Gala]

We have a few minor differences between P2041 & P2040 that we need to
handle or we run into issues.  We also rename a few things to make the
P2041 the superset device.

P2040 is a reduced P2041 (missing 10g/XAUI and L2-cache).

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

[U-Boot] [PATCH 1/3] powerpc/85xx: Rename P2040 id & SERDES to P2041

[Kumar Gala]

P2041 is the superset part that covers both P2040 & P2041.  The only
difference between the two devices is that P2041 supports 10g/XAUI and
has an L2 cache.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/cpu/mpc85xx/Makefile   |6 +-
 arch/powerpc/cpu/mpc85xx/p2040_ids.c|  109 ---
 arch/powerpc/cpu/mpc85xx/p2040_serdes.c |   90 -
 arch/powerpc/cpu/mpc85xx/p2041_ids.c|  109 +++
 arch/powerpc/cpu/mpc85xx/p2041_serdes.c |   90 +
 5 files changed, 202 insertions(+), 202 deletions(-)
 delete mode 100644 arch/powerpc/cpu/mpc85xx/p2040_ids.c
 delete mode 100644 arch/powerpc/cpu/mpc85xx/p2040_serdes.c
 create mode 100644 arch/powerpc/cpu/mpc85xx/p2041_ids.c
 create mode 100644 arch/powerpc/cpu/mpc85xx/p2041_serdes.c

diff --git a/arch/powerpc/cpu/mpc85xx/Makefile 
b/arch/powerpc/cpu/mpc85xx/Makefile
index 222ea7e..d6ec611 100644
--- a/arch/powerpc/cpu/mpc85xx/Makefile
+++ b/arch/powerpc/cpu/mpc85xx/Makefile
@@ -78,8 +78,8 @@ COBJS-$(CONFIG_PCI)   += pci.o
 COBJS-$(CONFIG_SYS_DPAA_QBMAN) += portals.o
 
 # various SoC specific assignments
-COBJS-$(CONFIG_PPC_P2040) += p2040_ids.o
-COBJS-$(CONFIG_PPC_P2041) += p2040_ids.o
+COBJS-$(CONFIG_PPC_P2040) += p2041_ids.o
+COBJS-$(CONFIG_PPC_P2041) += p2041_ids.o
 COBJS-$(CONFIG_PPC_P3041) += p3041_ids.o
 COBJS-$(CONFIG_PPC_P4080) += p4080_ids.o
 COBJS-$(CONFIG_PPC_P5020) += p5020_ids.o
@@ -113,7 +113,7 @@ COBJS-$(CONFIG_P1024)   += p1021_serdes.o
 COBJS-$(CONFIG_P1025)  += p1021_serdes.o
 COBJS-$(CONFIG_P2010)  += p2020_serdes.o
 COBJS-$(CONFIG_P2020)  += p2020_serdes.o
-COBJS-$(CONFIG_PPC_P2040) += p2040_serdes.o
+COBJS-$(CONFIG_PPC_P2040) += p2041_serdes.o
 COBJS-$(CONFIG_PPC_P2041) += p2041_serdes.o
 COBJS-$(CONFIG_PPC_P3041) += p3041_serdes.o
 COBJS-$(CONFIG_PPC_P4080) += p4080_serdes.o
diff --git a/arch/powerpc/cpu/mpc85xx/p2040_ids.c 
b/arch/powerpc/cpu/mpc85xx/p2040_ids.c
deleted file mode 100644
index 112ea56..000
--- a/arch/powerpc/cpu/mpc85xx/p2040_ids.c
+++ /dev/null
@@ -1,109 +0,0 @@
-/*
- * Copyright 2011 Freescale Semiconductor, Inc.
- *
- * 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 
-
-#ifdef CONFIG_SYS_DPAA_QBMAN
-struct qportal_info qp_info[CONFIG_SYS_QMAN_NUM_PORTALS] = {
-   /* dqrr liodn, frame data liodn, liodn off, sdest */
-   SET_QP_INFO( 1,  2,  1, 0),
-   SET_QP_INFO( 3,  4,  2, 1),
-   SET_QP_INFO( 5,  6,  3, 2),
-   SET_QP_INFO( 7,  8,  4, 3),
-   SET_QP_INFO( 9, 10,  5, 4),
-   SET_QP_INFO( 0,  0,  0, 5),
-   SET_QP_INFO( 0,  0,  0, 6),
-   SET_QP_INFO( 0,  0,  0, 7),
-   SET_QP_INFO( 0,  0,  0, 0), /* for now sdest to 0 */
-   SET_QP_INFO( 0,  0,  0, 0), /* for now sdest to 0 */
-};
-#endif
-
-struct liodn_id_table liodn_tbl[] = {
-#ifdef CONFIG_SYS_DPAA_QBMAN
-   SET_QMAN_LIODN(31),
-   SET_BMAN_LIODN(32),
-#endif
-
-   SET_SDHC_LIODN(1, 64),
-
-   SET_PME_LIODN(117),
-
-   SET_USB_LIODN(1, "fsl-usb2-mph", 125),
-   SET_USB_LIODN(2, "fsl-usb2-dr", 126),
-
-   SET_SATA_LIODN(1, 127),
-   SET_SATA_LIODN(2, 128),
-
-   SET_PCI_LIODN("fsl,qoriq-pcie-v2.2", 1, 193),
-   SET_PCI_LIODN("fsl,qoriq-pcie-v2.2", 2, 194),
-   SET_PCI_LIODN("fsl,qoriq-pcie-v2.2", 3, 195),
-
-   SET_DMA_LIODN(1, 197),
-   SET_DMA_LIODN(2, 198),
-
-   SET_GUTS_LIODN("fsl,rapidio-delta", 199, rio1liodnr, 0),
-   SET_GUTS_LIODN(NULL, 200, rio2liodnr, 0),
-   SET_GUTS_LIODN(NULL, 201, rio1maintliodnr, 0),
-   SET_GUTS_LIODN(NULL, 202, rio2maintliodnr, 0),
-};
-int liodn_tbl_sz = ARRAY_SIZE(liodn_tbl);
-
-#ifdef CONFIG_SYS_DPAA_FMAN
-struct liodn_id_table fman1_liodn_tbl[] = {
-   SET_FMAN_RX_1G_LIODN(1, 0, 10),
-   SET_FMAN_RX_1G_LIODN(1, 1, 11),
-   SET_FMAN_RX_1G_LIODN(1, 2, 12),
-   SET_FMAN_RX_1G_LIODN(1, 3, 13),
-   SET_FMAN_RX_1G_LIODN(1, 4, 14),
-#if (CONFIG_SYS_NUM_FM1_10GEC == 1)
-   SET_FMAN_RX_10G_LIODN(1, 0, 15),
-#endif
-};
-int fman1_liodn_tbl_sz = ARRAY_SIZE(fman1_liodn_tbl);
-#endif
-
-struct liodn_id_table sec_liodn_tbl[] = {
-   SET_SEC_JR_LIODN_ENTRY(0, 129, 130),
-   SET_SEC_JR_LIODN_ENTRY(1, 131, 132),
-   

[U-Boot] [PATCH 2/3] powerpc/85xx: Add support for P2041[e] XAUI in SERDES

[Kumar Gala]

We add XAUI_FM1 into the SERDES tables for P2041[e] devices.  However
for the P2040[e] devices that dont support XAUI we handle this at
runtime via SVR checks.  If we are on a P2040[e] device the SERDES
functions will behave as follows:

is_serdes_prtcl_valid() will always report invalid if prtcl passed in is
XAUI_FM1.

serdes_get_prtcl() will report NONE if the prtcl in the table is set to
XAUI_FM1.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/cpu/mpc85xx/p2041_serdes.c |   26 +-
 1 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/p2041_serdes.c 
b/arch/powerpc/cpu/mpc85xx/p2041_serdes.c
index 83bc82f..f68f281 100644
--- a/arch/powerpc/cpu/mpc85xx/p2041_serdes.c
+++ b/arch/powerpc/cpu/mpc85xx/p2041_serdes.c
@@ -37,8 +37,8 @@ static u8 serdes_cfg_tbl[][SRDS_MAX_LANES] = {
PCIE2, PCIE2, PCIE2, NONE, NONE, NONE, NONE, SATA1,
SATA2, NONE, NONE, NONE, NONE, },
[0x9] = {NONE, NONE, SGMII_FM1_DTSEC1, SGMII_FM1_DTSEC2, PCIE2,
-   PCIE2, PCIE2, PCIE2, NONE, NONE, NONE, NONE,
-   NONE, NONE, NONE, NONE, NONE, NONE, },
+   PCIE2, PCIE2, PCIE2, NONE, NONE, XAUI_FM1, XAUI_FM1,
+   XAUI_FM1, XAUI_FM1, NONE, NONE, NONE, NONE, },
[0xa] = {NONE, NONE, SGMII_FM1_DTSEC1, SGMII_FM1_DTSEC2, PCIE2,
PCIE2, PCIE2, PCIE2, NONE, NONE, PCIE3, PCIE3, PCIE3,
PCIE3, NONE, NONE, NONE, NONE, },
@@ -53,8 +53,8 @@ static u8 serdes_cfg_tbl[][SRDS_MAX_LANES] = {
SGMII_FM1_DTSEC4, NONE, NONE, NONE, NONE, SATA1, SATA2, NONE,
NONE, NONE, NONE, },
[0x17] = {NONE, NONE, PCIE1, PCIE3, PCIE2, PCIE2, SGMII_FM1_DTSEC3,
-   SGMII_FM1_DTSEC4, NONE, NONE, NONE, NONE, NONE,
-   NONE, NONE, NONE, NONE, NONE, },
+   SGMII_FM1_DTSEC4, NONE, NONE, XAUI_FM1, XAUI_FM1, XAUI_FM1,
+   XAUI_FM1, NONE, NONE, NONE, NONE, },
[0x19] = {NONE, NONE, SGMII_FM1_DTSEC1, SGMII_FM1_DTSEC2, PCIE2,
PCIE2, SGMII_FM1_DTSEC3, SGMII_FM1_DTSEC4, NONE, NONE,
NONE, NONE, SATA1, SATA2, NONE, NONE, NONE, NONE, },
@@ -68,19 +68,35 @@ static u8 serdes_cfg_tbl[][SRDS_MAX_LANES] = {
 
 enum srds_prtcl serdes_get_prtcl(int cfg, int lane)
 {
+   enum srds_prtcl prtcl;
+   u32 svr = get_svr();
+   u32 ver = SVR_SOC_VER(svr);
+
if (!serdes_lane_enabled(lane))
return NONE;
 
-   return serdes_cfg_tbl[cfg][lane];
+   prtcl = serdes_cfg_tbl[cfg][lane];
+
+   /* P2040[e] does not support XAUI */
+   if (((ver == SVR_P2040) || (ver == SVR_P2040_E)) && (prtcl == XAUI_FM1))
+   prtcl = NONE;
+
+   return prtcl;
 }
 
 int is_serdes_prtcl_valid(u32 prtcl)
 {
int i;
+   u32 svr = get_svr();
+   u32 ver = SVR_SOC_VER(svr);
 
if (prtcl > ARRAY_SIZE(serdes_cfg_tbl))
return 0;
 
+   /* P2040[e] does not support XAUI */
+   if (((ver == SVR_P2040) || (ver == SVR_P2040_E)) && (prtcl == XAUI_FM1))
+   return 0;
+
for (i = 0; i < SRDS_MAX_LANES; i++) {
if (serdes_cfg_tbl[prtcl][i] != NONE)
return 1;
-- 
1.7.3.4

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

[U-Boot] [PATCH 1/2] gpio: Add GPIO driver framework for Marvell SoCs

[Ajay Bhargav]

This patch adds generic GPIO driver framework support for Marvell SoCs.

To enable GPIO driver define CONFIG_MV_GPIO and for GPIO commands
define CONFIG_CMD_GPIO in your board configuration file.

Signed-off-by: Ajay Bhargav 
---
 drivers/gpio/Makefile |1 +
 drivers/gpio/mvgpio.c |  125 +
 include/mvgpio.h  |   52 
 3 files changed, 178 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpio/mvgpio.c
 create mode 100644 include/mvgpio.h

diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 62ec97d..c6f652f 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -28,6 +28,7 @@ LIB   := $(obj)libgpio.o
 COBJS-$(CONFIG_AT91_GPIO)  += at91_gpio.o
 COBJS-$(CONFIG_KIRKWOOD_GPIO)  += kw_gpio.o
 COBJS-$(CONFIG_MARVELL_MFP)+= mvmfp.o
+COBJS-$(CONFIG_MV_GPIO)+= mvgpio.o
 COBJS-$(CONFIG_MXC_GPIO)   += mxc_gpio.o
 COBJS-$(CONFIG_PCA953X)+= pca953x.o
 COBJS-$(CONFIG_S5P)+= s5p_gpio.o
diff --git a/drivers/gpio/mvgpio.c b/drivers/gpio/mvgpio.c
new file mode 100644
index 000..d64f0db
--- /dev/null
+++ b/drivers/gpio/mvgpio.c
@@ -0,0 +1,125 @@
+/*
+ * (C) Copyright 2011
+ * eInfochips Ltd. 
+ * Written-by: Ajay Bhargav 
+ *
+ * (C) Copyright 2010
+ * Marvell Semiconductor 
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+char gpio_names[MV_MAX_GPIO][GPIO_LABEL_MAX];
+
+static int get_gpio_base(int bank)
+{
+   switch (bank) {
+   case 0:
+   return GPIO_BANK0_BASE;
+   case 1:
+   return GPIO_BANK1_BASE;
+   case 2:
+   return GPIO_BANK2_BASE;
+   case 3:
+   return GPIO_BANK3_BASE;
+   }
+   return 0;
+}
+
+int gpio_request(int gp, const char *label)
+{
+   if (gp >= MV_MAX_GPIO)
+   return -EINVAL;
+
+   if (strlen(gpio_names[gp]) == 0) {
+   strncpy(gpio_names[gp], label, GPIO_LABEL_MAX);
+   gpio_names[gp][GPIO_LABEL_MAX - 1] = '\0';
+   } else {
+   return -EBUSY;
+   }
+   return 0;
+}
+
+void gpio_free(int gp)
+{
+   gpio_names[gp][0] = '\0';
+}
+
+void gpio_toggle_value(int gp)
+{
+   gpio_set_value(gp, !gpio_get_value(gp));
+}
+
+int gpio_direction_input(int gp)
+{
+   struct gpio_reg *gpio_reg_bank;
+
+   if (gp >= MV_MAX_GPIO)
+   return -EINVAL;
+
+   gpio_reg_bank = (struct gpio_reg *) get_gpio_base(GPIO_TO_REG(gp));
+   writel(GPIO_TO_BIT(gp), &gpio_reg_bank->gcdr);
+   return 0;
+}
+
+int gpio_direction_output(int gp, int value)
+{
+   struct gpio_reg *gpio_reg_bank;
+
+   if (gp >= MV_MAX_GPIO)
+   return -EINVAL;
+
+   gpio_reg_bank = (struct gpio_reg *) get_gpio_base(GPIO_TO_REG(gp));
+   writel(GPIO_TO_BIT(gp), &gpio_reg_bank->gsdr);
+   gpio_set_value(gp, value);
+   return 0;
+}
+
+int gpio_get_value(int gp)
+{
+   struct gpio_reg *gpio_reg_bank;
+   u32 gp_val;
+
+   if (gp >= MV_MAX_GPIO)
+   return -EINVAL;
+
+   gpio_reg_bank = (struct gpio_reg *) get_gpio_base(GPIO_TO_REG(gp));
+   gp_val = readl(&gpio_reg_bank->gplr);
+
+   return GPIO_VAL(gp, gp_val);
+}
+
+void gpio_set_value(int gp, int value)
+{
+   struct gpio_reg *gpio_reg_bank;
+
+   if (gp >= MV_MAX_GPIO)
+   return;
+
+   gpio_reg_bank = (struct gpio_reg *) get_gpio_base(GPIO_TO_REG(gp));
+   if (value)
+   writel(GPIO_TO_BIT(gp), &gpio_reg_bank->gpsr);
+   else
+   writel(GPIO_TO_BIT(gp), &gpio_reg_bank->gpcr);
+}
diff --git a/include/mvgpio.h b/include/mvgpio.h
new file mode 100644
index 000..7d0258f
--- /dev/null
+++ b/include/mvgpio.h
@@ -0,0 +1,52 @@
+/*
+ * (C) Copyright 2011
+ * eInfochips Ltd. 
+ * Written-by: Ajay Bhargav 
+ *
+ * (C) Copyright 2010
+ * Marvell Semiconductor 
+ *
+ * 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 

[U-Boot] [PATCH 2/2] gpio: Add GPIO driver for Marvell SoC Armada100

[Ajay Bhargav]

This patch adds support for generic GPIO driver framework for Marvell
SoC Armada100.

Signed-off-by: Ajay Bhargav 
---
 arch/arm/include/asm/arch-armada100/gpio.h |   71 
 1 files changed, 71 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-armada100/gpio.h

diff --git a/arch/arm/include/asm/arch-armada100/gpio.h 
b/arch/arm/include/asm/arch-armada100/gpio.h
new file mode 100644
index 000..4dd0179
--- /dev/null
+++ b/arch/arm/include/asm/arch-armada100/gpio.h
@@ -0,0 +1,71 @@
+/*
+ * (C) Copyright 2011
+ * eInfochips Ltd. 
+ * Written-by: Ajay Bhargav 
+ *
+ * (C) Copyright 2010
+ * Marvell Semiconductor 
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#ifndef _ASM_ARCH_GPIO_H
+#define _ASM_ARCH_GPIO_H
+
+#include 
+
+/*
+ * GPIO register map
+ * Refer Datasheet Appendix A.36
+ */
+struct gpio_reg {
+   u32 gplr;   /* Pin Level Register */
+   u32 pad0[2];
+   u32 gpdr;   /* Pin Direction Register */
+   u32 pad1[2];
+   u32 gpsr;   /* Pin Output Set Register */
+   u32 pad2[2];
+   u32 gpcr;   /* Pin Output Clear Register */
+   u32 pad3[2];
+   u32 grer;   /* Rising-Edge Detect Enable Register */
+   u32 pad4[2];
+   u32 gfer;   /* Falling-Edge Detect Enable Register */
+   u32 pad5[2];
+   u32 gedr;   /* Edge Detect Status Register */
+   u32 pad6[2];
+   u32 gsdr;   /* Bitwise Set of GPIO Direction Register */
+   u32 pad7[2];
+   u32 gcdr;   /* Bitwise Clear of GPIO Direction Register */
+   u32 pad8[2];
+   u32 gsrer;  /* Bitwise Set of Rising-Edge Detect Enable
+  Register */
+   u32 pad9[2];
+   u32 gcrer;  /* Bitwise Clear of Rising-Edge Detect Enable
+  Register */
+   u32 pad10[2];
+   u32 gsfer;  /* Bitwise Set of Falling-Edge Detect Enable
+  Register */
+   u32 pad11[2];
+   u32 gcfer;  /* Bitwise Clear of Falling-Edge Detect Enable
+  Register */
+   u32 pad12[2];
+   u32 apmask; /* Bitwise Mask of Edge Detect Register */
+};
+
+#endif /* _ASM_ARCH_GPIO_H */
-- 
1.7.0.4

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

Re: [U-Boot] [PATCH v4 00/12] U-Boot MMC SPL for OMAP4

[V, Aneesh]

Hi Sandeep,

On Thu, Jul 21, 2011 at 3:01 AM, Paulraj, Sandeep  wrote:
>> Aneesh V (11):
>>   omap4: utility function to identify the context of hw init
>>   omap4: cleanup pin mux data
>>   omap4: add OMAP4430 revision check
>>   omap4: add clock support
>>   omap4: add sdram init support
>>   omap4: calculate EMIF register values
>>   omap4: automatic sdram detection
>>   armv7: start.S: fixes and enhancements for SPL
>>   omap: add basic SPL support
>>   Correct ih_os for u-boot.img
>>   omap: add MMC and FAT support to SPL
>>
>> John Rigby (1):
>>   mkimage: Add OMAP boot image support
>
>
> Patch #8 of this seires does not apply on the current u-boot-ti
> U-boot-ti now has the updated SPL framework

There was v4 for just two of the patches of the framework series: 2/9 and 5/9.

I think you missed them. Can you correct this?

>
> Please rebase with u-boot-ti and send updated patch sets for both your series.

Sure. I will do that.

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

Re: [U-Boot] [PATCH 1/2] gpio: Add GPIO driver framework for Marvell SoCs

[Lei Wen]

Hi Ajay,

On Thu, Jul 21, 2011 at 1:39 PM, Ajay Bhargav
 wrote:
> This patch adds generic GPIO driver framework support for Marvell SoCs.
>
> To enable GPIO driver define CONFIG_MV_GPIO and for GPIO commands
> define CONFIG_CMD_GPIO in your board configuration file.
>
> Signed-off-by: Ajay Bhargav 
> ---
>  drivers/gpio/Makefile |    1 +
>  drivers/gpio/mvgpio.c |  125 
> +
>  include/mvgpio.h      |   52 
>  3 files changed, 178 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/gpio/mvgpio.c
>  create mode 100644 include/mvgpio.h
>
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 62ec97d..c6f652f 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -28,6 +28,7 @@ LIB   := $(obj)libgpio.o
>  COBJS-$(CONFIG_AT91_GPIO)      += at91_gpio.o
>  COBJS-$(CONFIG_KIRKWOOD_GPIO)  += kw_gpio.o
>  COBJS-$(CONFIG_MARVELL_MFP)    += mvmfp.o
> +COBJS-$(CONFIG_MV_GPIO)                += mvgpio.o
>  COBJS-$(CONFIG_MXC_GPIO)       += mxc_gpio.o
>  COBJS-$(CONFIG_PCA953X)                += pca953x.o
>  COBJS-$(CONFIG_S5P)            += s5p_gpio.o
> diff --git a/drivers/gpio/mvgpio.c b/drivers/gpio/mvgpio.c
> new file mode 100644
> index 000..d64f0db
> --- /dev/null
> +++ b/drivers/gpio/mvgpio.c
> @@ -0,0 +1,125 @@
> +/*
> + * (C) Copyright 2011
> + * eInfochips Ltd. 
> + * Written-by: Ajay Bhargav 
> + *
> + * (C) Copyright 2010
> + * Marvell Semiconductor 
> + *
> + * 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., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301 USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +char gpio_names[MV_MAX_GPIO][GPIO_LABEL_MAX];
> +
> +static int get_gpio_base(int bank)
> +{
> +       switch (bank) {
> +       case 0:
> +               return GPIO_BANK0_BASE;
> +       case 1:
> +               return GPIO_BANK1_BASE;
> +       case 2:
> +               return GPIO_BANK2_BASE;
> +       case 3:
> +               return GPIO_BANK3_BASE;
> +       }
> +       return 0;
> +}

Please put this get_gpio_base into arch's self directory, since
different soc may have
different number of banks. For example, mmp3 has 6 banks.

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

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

[David Jander]

On Wed, 20 Jul 2011 08:36:12 -0700
"J. William Campbell"  wrote:

> On 7/20/2011 7:35 AM, Albert ARIBAUD wrote:
> > Le 20/07/2011 16:01, J. William Campbell a écrit :
> >> On 7/20/2011 6:02 AM, Albert ARIBAUD wrote:
> >>> Le 19/07/2011 22:11, J. William Campbell a écrit :
> >>>
>  If this is true, then it means that the cache is of type write-back 
>  (as
>  opposed to write-thru). From a (very brief) look at the arm7 
>  manuals, it
>  appears that both types of cache may be present in the cpu. Do you 
>  know
>  how this operates?
> >>> Usually, copyback (rather than writeback) and writethough are modes of
> >>> operation, not cache types.
> >> Hi Albert,
> >> One some CPUs both cache modes are available. On many other CPUs (I
> >> would guess most), you have one fixed mode available, but not both. I
> >> have always seen the two modes described as write-back and
> >> write-through, but I am sure we are talking about the same things.
> >
> > We are. Copy-back is another name for write-back, not used by ARM but 
> > by some others.
> >
> >> The
> >> examples that have both modes that I am familiar with have the mode as a
> >> "global" setting. It is not controlled by bits in the TLB or anything
> >> like that. How does it work on ARM? Is it fixed, globally, globally
> >> controlled, or controlled by memory management?
> >
> > Well, it's a bit complicated, because it depends on the architecture 
> > version *and* implementation -- ARM themselves do not mandate things, 
> > and it is up to the SoC designer to specify what cache they want and 
> > what mode it supports, both at L1 and L2, in their specific instance 
> > of ARM cores. And yes, you can have memory areas that are write-back 
> > and others that are write-through in the same system.
> >
> >> If it is controlled by memory management, it looks to me like lots of
> >> problems could be avoided by operating with input type buffers set as
> >> write-through. One probably isn't going to be writing to input buffers
> >> much under program control anyway, so the performance loss should be
> >> minimal. This gets rid of the alignment restrictions on these buffers
> >> but not the invalidate/flush requirements.
> >
> > There's not much you can do about alignment issues except align to 
> > cache line boundaries.
> >
> >> However, if memory management
> >> is required to set the cache mode, it might be best to operate with the
> >> buffers and descriptors un-cached. That gets rid of the flush/invalidate
> >> requirement at the expense of slowing down copying from read buffers.
> >
> > That makes 'best' a subjective choice, doesn't it? :)
> Hi All,
>  Yes,it probably depends on the usage.
> >
> >> Probably a reasonable price to pay for the associated simplicity.
> >
> > Others would say that spending some time setting up alignments and 
> > flushes and invalidates is a reasonable price to pay for increased 
> > performance... That's an open debate where no solution is The Right 
> > One(tm).
> >
> > For instance, consider the TFTP image reading. People would like the 
> > image to end up in cached memory because we'll do some checksumming on 
> > it before we give it control, and having it cached makes this step 
> > quite faster; but we'll lose that if we put it in non-cached memory 
> > because it comes through the Ethernet controller's DMA; and it would 
> > be worse to receive packets in non-cached memory only to move their 
> > contents into cached memory later on.
> >
> > I think properly aligning descriptors and buffers is enough to avoid 
> > the mixed flush/invalidate line issue, and wisely putting instruction 
> > barriers should be enough to get the added performance of cache 
> > without too much of the hassle of memory management.
> I am pretty sure that all the drivers read the input data into 
> intermediate buffers in all cases. There is no practical way to be sure 
> the next packet received is the "right one" for the tftp. Plus there are 
> headers involved, and furthermore there is no way to ensure that a tftp 
> destination is located on a sector boundary. In short, you are going to 
> copy from an input buffer to a destination.
> However, it is still correct that copying from an non-cached area is 
> slower than from cached areas, because of burst reads vs. individual 
> reads. However, I doubt that the u-boot user can tell the difference, as 
> the network latency will far exceed the difference in copy time. The 
> question is, which is easier to do, and that is probably a matter of 
> opinion. However, it is safe to say that so far a cached solution has 
> eluded us. That may be changing, but it would still be nice to know how 
> to allocate a section of un-cached RAM in the ARM processor, in so far 
> as the question has a single answer! That would allow easy portability 
> of drivers that do not know about caches, of which there seems to be many.

I agree. Unfortunately, my time is up for now, and

Re: [U-Boot] [PATCH 1/2] gpio: Add GPIO driver framework for Marvell SoCs

[Ajay Bhargav]

- "Lei Wen"  wrote:

> Hi Ajay,
> 
> Please put this get_gpio_base into arch's self directory, since
> different soc may have
> different number of banks. For example, mmp3 has 6 banks.
> 
> Best regards,
> Lei
> 

was out of my mind... I think having a macro for this would be better
coz individual arch can have their own macros. Anymore comments?

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