Signed-off-by: Aneesh V
Cc: Dirk Behme
Cc: Sandeep Paulraj
---
include/configs/omap4_panda.h |2 +-
include/configs/omap4_sdp4430.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h
index e313231..814f15
This patch adds support for generic GPIO driver framework for Marvell
SoC Armada100.
Signed-off-by: Ajay Bhargav
---
arch/arm/include/asm/arch-armada100/armada100.h |4 ++
arch/arm/include/asm/arch-armada100/gpio.h | 54 +++
2 files changed, 58 insertions(+), 0 del
This patch adds generic GPIO driver framework support for Marvell SoCs.
To enable GPIO driver define CONFIG_MARVELL_GPIO and for GPIO commands
define CONFIG_CMD_GPIO in your board configuration file.
v3 - Added file mvgpio.h for common defines based on CPU core
subversion. Arch related stuff shou
Hi Dirk,
On Saturday 06 August 2011 12:01 AM, Dirk Behme wrote:
> From: Dirk Behme
>
> The patch "omap: reuse omap3 gpio support in omap4" moves
> arch/arm/include/asm/arch-omap3/gpio.h to
> arch/arm/include/asm/omap_gpio.h but misses to touch all
> users of arch-omap3/gpio.h. This results in vari
Hi Dirk,
I can fix it. We have more SRAM available in 4430. I can increase the
SRAM budget. I will send a patch shortly.
br,
Aneesh
On Saturday 06 August 2011 12:24 AM, Dirk Behme wrote:
>
> Building the SPL for omap4_sdp4430 and omap4_panda in recent mainline is
> broken due to a resulting imag
Hi,
We need to make this sticky or add it into some wiki page.
Nice explanation for beginners.
Regards
Gururaja
On Mon, Aug 08, 2011 at 01:58:32, Jerry Van Baren wrote:
> On 08/07/2011 02:55 PM, Rakesh Modi wrote:
> > Hi,
> > I am new to linux and u-boot. Please answer my following questions.
>
After DMA operation, we need to maintain D-Cache coherency.
So that the DCache must be invalidated (hence CPU will fetch
data written by DMA controller from RAM).
Tested on AT91SAM9261EK with Peripheral DMA controller.
Signed-off-by: Hong Xu
Tested-by: Elen Song
CC: Albert Aribaud
CC: Aneesh V
This allows the Blackfin UART driver to be tested via post.
Signed-off-by: Mike Frysinger
---
arch/blackfin/cpu/serial.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/blackfin/cpu/serial.c b/arch/blackfin/cpu/serial.c
index
Make it easy for any Blackfin board to enable led/push button tests.
Signed-off-by: Mike Frysinger
---
arch/blackfin/include/asm/config.h | 18 +++
arch/blackfin/lib/Makefile |1 +
arch/blackfin/lib/post.c | 85 +++
board/bf537-stamp/
Update the define names for the new common code, and improve the range
used on the bf548-ezkit.
Signed-off-by: Mike Frysinger
---
include/configs/bf537-stamp.h |4 ++--
include/configs/bf548-ezkit.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/configs/b
The few tests that are Blackfin-specific have been migrated to common
code or been rewritten with the existing "bsp-specific" defines.
Signed-off-by: Mike Frysinger
---
arch/blackfin/lib/Makefile|1 -
arch/blackfin/lib/tests.c | 250 -
inc
Now that the pending POST and Blackfin changes have been merged, I can
post this series which migrates much of the Blackfin-specific POST logic
to the common stuff.
This will be for the next merge window.
Mike Frysinger (6):
Blackfin: bf537-stamp: convert to gpio post hotkey
Blackfin: post: d
The flash code has been generalized for everyone, and the uart stub
is simply useless.
Signed-off-by: Mike Frysinger
---
board/bf537-stamp/post.c | 54 --
1 files changed, 0 insertions(+), 54 deletions(-)
diff --git a/board/bf537-stamp/post.c b/boar
No need for our custom implementations now that common code supports
the generic gpio layer.
Signed-off-by: Mike Frysinger
---
board/bf537-stamp/post-memory.c | 63 +--
board/bf537-stamp/post.c| 33
include/configs/bf537-stamp.
On Monday, July 25, 2011 01:50:29 Hebbar, Gururaja wrote:
> We have an upcoming SOC with Ethernet controller which has registers with
> offsets crossing 0x110. In order to access these registers, we use
> miiphy_read() & miiphy_write() api provided by Standard u-boot mii phy
> util code (common/mii
On Saturday, July 30, 2011 13:28:49 Zhong Hongbo wrote:
> From: seedshope
>
> setenv is defined common.h. We do not need re-defined it
>
> Zhong hongbo
please fix your git env. it is setting the author field to "seedshope" which
clearly is incorrect. it should be your name.
-mike
signatur
Dear Albert,
Albert ARIBAUD wrote:
> Custodians should remove this tag from their respective repos, except
> Scott McNutt of course, who owns The Vote as far as keeping NIOS2-5_0_0
> in u-boot-nios is concerned. :)
The tag no longer serves any practical purpose.
Regards,
--Scott
_
On 08/07/2011 02:55 PM, Rakesh Modi wrote:
> Hi,
> I am new to linux and u-boot. Please answer my following questions.
> 1) what is u-boot? why it require?
It initializes and configures the hardware (processor, RAM,
peripherals), it loads linux (or other OS) from storage (flash, hard
drive, ethe
Hi,
I am new to linux and u-boot. Please answer my following questions.
1) what is u-boot? why it require?
2) why we can not load linux kernel directly without use of u-boot?
3) How does any processor sequence starts when power is on?
--
Thanks & Regards
Rakesh Modi
__
On Aug 7, 2011, at 6:52 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 05-08-2011 18:44, Kumar Gala wrote:
>
>> From: Poonam Aggrwal
>
>> For an IFC Erratum (A-003399) we will need to access IFC registers in
>> cpu_init_early_f() so expand the TLB covering CCSR to 1M.
>
>> Since we need a TLB to
Am 28.07.2011 15:19, schrieb Holger Brunck:
> Hi Aneesh,
> today I did a rebase of my development branch to current u-boot master. And I
> saw on our km_kirkwood board that our egiga0 interface isn't working anymore.
>
> The CPU is a:
> SoC: Kirkwood 88F6281_A0
>
> After bisecting the current tre
Am 28.07.2011 15:19, schrieb Holger Brunck:
> Hi Aneesh,
> today I did a rebase of my development branch to current u-boot master. And I
> saw on our km_kirkwood board that our egiga0 interface isn't working anymore.
>
> The CPU is a:
> SoC: Kirkwood 88F6281_A0
>
> After bisecting the current tre
Hello all,
This tag NIOS2-5_0_0 keeps lingering in ARM repositories and should not
be there. I regularly have to remove it from u-boot-arm because I keep
catching it occasionally when recreating my u-boot-arm local copy and
then fetching another ARM repo such as u-boot-atmel, u-boot-marvell,
Hello.
On 05-08-2011 18:44, Kumar Gala wrote:
> From: Poonam Aggrwal
> For an IFC Erratum (A-003399) we will need to access IFC registers in
> cpu_init_early_f() so expand the TLB covering CCSR to 1M.
> Since we need a TLB to cover 1M we move to using TLB1 array for all the
> early mappings so
Hi Larry,
Le 05/08/2011 05:13, larry a écrit :
> As your suggestion for me,Albert,I upgrade to uboot-v2011.06-rc3 by
> Git.This is the latest version i found on Git .And modified some places
> to make uboot buildable.Now arm-linux-readelf has no longer warns
> "segmentation fault", but after i bu
Hi Mike, Marek,
On 07/08/11 10:54, Graeme Russ wrote:
> Hi Mike, Marek,
>
> On 07/08/11 09:43, Mike Frysinger wrote:
>> On Sat, Aug 6, 2011 at 05:49, Marek Vasut wrote:
>>> On Saturday, August 06, 2011 01:22:38 PM Mike Frysinger wrote:
disclaimer: i have like 0 u-boot experience on x86. but
Hi Dirk,
Le 05/08/2011 20:54, Dirk Behme a écrit :
> Does anybody have a quick solution for this fixing the build of these
> boards for the -rc cycle? Else I'm about to send a patch like [2]
> disabling the SPL build until a patch to reduce the image size is
> available.
> [2]
>include/confi
Hi Dirk,
Le 06/08/2011 08:48, Dirk Behme a écrit :
> From: Dirk Behme
>
> Use the boards from boards.cfg for building ./MAKEALL ARMV7.
>
> Signed-off-by: Dirk Behme
>
> ---
> Changes in v3: Instead of touching all ARMx boards, only update
> ARMV7. Current LIST_ARMV7 builds 19 boards while -c armv7
Hi there
Please do let me know when you are looking at advertising next - we represent
some interesting niche print and online titles here in London, all of which hit
the top 5% of the AB demographic in Europe.
Best, John Winters
Introductions Director
SKS Media London
www.niche-advertising.c
Hi Bill,
Le 06/08/2011 01:04, J. William Campbell a écrit :
> Hi All,
> I am interested in this last statement in particular, that
> Linux allows non-cache aligned buffers for DMA. In a previous discussion
> series, we demonstrated why it was IMPOSSIBLE for a non-cache aligned
> DMA buf
30 matches
Mail list logo