Hi Wolfgang,
Le 02/12/2010 08:34, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4cf743e6.60...@free.fr> you wrote:
>>
>> Starting with the fact that the linker issue is only for one board,
>> omap3_evm, I looked up the board-specific code. First thing that I
>> noticed was
>>
>>
Dear Mark Underwood,
In message <1291273748.31320.3.ca...@bertha> you wrote:
>
> I've got an sbc6000x from www.armkits.com. I've been working through how
> to put debian onto this board and was making some progress (im just a
> beginner), but now I
> dont have network access when at the U-boot pr
Dear Albert ARIBAUD,
In message <4cf743e6.60...@free.fr> you wrote:
>
> Starting with the fact that the linker issue is only for one board,
> omap3_evm, I looked up the board-specific code. First thing that I
> noticed was
>
> static u8 omap3_evm_version;
>
> I changed this to
>
>
Dear Jason Liu,
In message you
wrote:
>
> I have one problem when support more than 4GB NAND flash in u-boot. I
> found that there used ulong type in common/cmd_nand.c,
> but it turned out that ulong is 32bit in my build environment, the gcc
> version is as the following? Does anyone meet the s
Hi,
I've got an sbc6000x from www.armkits.com. I've been working through how
to put debian onto this board and was making some progress (im just a
beginner), but now I
dont have network access when at the U-boot prompt. The Board is
connected to the network as the link light is on on the interface
> -Original Message-
> From: Lei Wen [mailto:adrian.w...@gmail.com]
> Sent: Thursday, December 02, 2010 12:29 PM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Eric Miao; Manas Saksena; Lei Wen; Yu Tang;
> Ashish Karkare; Kiran Vedere; Prabhanjan Sarnaik
> Subject: Re: [U-Boot] [PATC
Le 01/12/2010 22:39, Albert ARIBAUD a écrit :
> This one is a conundrum.
>
> Using 2010q1, building omap3_evm causes a linker warning
> "arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8f0 overlaps
> previous sections" while building omap3_beagle does not cause any linker
> warning.
>
>
Hi Prafulla,
On Thu, Dec 2, 2010 at 2:54 PM, Prafulla Wadaskar wrote:
>
>
>> -Original Message-
>> From: Lei Wen [mailto:adrian.w...@gmail.com]
>> Sent: Wednesday, December 01, 2010 7:51 PM
>> To: Prafulla Wadaskar
>> Cc: u-boot@lists.denx.de; Eric Miao; Manas Saksena; Lei Wen; Yu Tang;
>
> -Original Message-
> From: Lei Wen [mailto:adrian.w...@gmail.com]
> Sent: Wednesday, December 01, 2010 7:51 PM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Eric Miao; Manas Saksena; Lei Wen; Yu Tang;
> Ashish Karkare; Kiran Vedere; Prabhanjan Sarnaik
> Subject: Re: [U-Boot] [PATC
Hi there,
I have one problem when support more than 4GB NAND flash in u-boot. I
found that there used ulong type in common/cmd_nand.c,
but it turned out that ulong is 32bit in my build environment, the gcc
version is as the following? Does anyone meet the same problem?
r64...@r64343-desktop:~/wo
The following commit:
commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4
Author: Peter Tyser
Date: Tue Nov 3 17:52:07 2009 -0600
tsec: Force TBI PHY to 1000Mbps full duplex in SGMII mode
Removed setting Auto-Neg by default, however this is believed to be
proper default configuration for init
On Nov 17, 2010, at 11:01 PM, Peter Tyser wrote:
> On Wed, 2010-11-17 at 21:13 -0700, Li Yang-R58472 wrote:
>>> Subject: Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps full
>>> duplex in SGMII mode"
>>>
>>> Hi Zhao,
>>>
In message <1289986984-2314-1-git-send-email-b26...@free
Sorry for the two successive posts, I looked at the disassembly...
On Wed, Dec 1, 2010 at 1:26 AM, 奥刘 wrote:
> Dear All:
>
> Recently , i have build a embedded environment with Uboot . And My Chip
> is adm5120 , mips4kc code.
>
> In the file .\cpu\mips\cache.s , i found some code confounded .
hello,
On Wed, Dec 1, 2010 at 10:27 AM, Andrew Dyer wrote:
> On Dec 1, 2010 12:26 AM, "奥刘" wrote:
>
>> In the file .\cpu\mips\cache.s , i found some code confounded .
>>
>> line 152 to line 156 :
>>
>> cache_op Index_Store_Tag_I t0
>> PTR_ADDU t0, a2
On Wed, 01 Dec 2010 17:28:28 -0600
Timur Tabi wrote:
> Scott Wood wrote:
> >> You told me that since I'm doing a read following a write to uncached
> >> memory,
> >> > that I don't need a sync.
> > No, I was talking about a write followed by a read, to the same location.
>
> That's what I said.
Scott Wood wrote:
>> You told me that since I'm doing a read following a write to uncached memory,
>> > that I don't need a sync.
> No, I was talking about a write followed by a read, to the same location.
That's what I said. Read following write == write followed by read.
> out_8 should be fixed
On Wed, 01 Dec 2010 16:45:57 -0600
Timur Tabi wrote:
> Wood Scott-B07421 wrote:
> >
> > Careful with the barriers.
> >
> > You've got a raw readback, which means it's not going to wait for
> > completion with the twi/isync hack.
>
> You told me that since I'm doing a read following a write to
Wood Scott-B07421 wrote:
>
> Careful with the barriers.
>
> You've got a raw readback, which means it's not going to wait for
> completion with the twi/isync hack.
You told me that since I'm doing a read following a write to uncached memory,
that I don't need a sync.
And what twi/isync hack are
Below is a catalog of all our lists and the corresponding prices:
note: all lists are optin and sold with unlimited use rights
HEALTH RELATED LISTS
Any Individual list below $109 ea OR 2 for $179 (Only until Friday)
-> Complete US Physicians Database
-> Chiropractic Doctors in the USA
-> America
This one is a conundrum.
Using 2010q1, building omap3_evm causes a linker warning
"arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8f0 overlaps
previous sections" while building omap3_beagle does not cause any linker
warning.
Both boards use the same armv7 u-boot.lds and have a .bss
Dear "Premi, Sanjeev",
In message you
wrote:
>
> 1) why the current metod produces different errors across
> different toolchain versions.
Different tool chains may prvide different quality of optimizations
(and bugs), resulting in differnt variable locations. With one memory
map y
Dear "Premi, Sanjeev",
In message you
wrote:
>
> The u-boot built after this change alone gets stuck somewhere after
> dram_init(). However, removing the "sort" from LIBS (as suggested
> by Wolfgang), the u-boot comes up fine on the omap3_evm.
I did NOT suggest that. This was just intended as d
On Mon, 29 Nov 2010 22:42:00 +0100
Anatolij Gustschin wrote:
> CONFIG_FSL_DIU_LOGO_BMP has been removed while refactoring
> MPC8610 and MPC5121 DIU code, so remove it.
>
> Signed-off-by: Anatolij Gustschin
> ---
> include/configs/aria.h |1 -
> 1 files changed, 0 insertions(+), 1 deletions
On Mon, 29 Nov 2010 22:28:02 +0100
Anatolij Gustschin wrote:
> Since the driver is used not only on Freescale boards,
> we move it to a common place for video drivers as
> suggested by Wolfgang. The patch also cleans up the
> top level Makefile.
>
> Signed-off-by: Anatolij Gustschin
> ---
> Ma
[for v2010.12]
The following changes since commit 49733aa0b9d29803384ad4bce74985f4bbe7e9aa:
Merge branch 'master' of /home/wd/git/u-boot/custodians (2010-11-30 22:13:32
+0100)
are available in the git repository at:
git://git.denx.de/u-boot-mpc85xx master
Haiying Wang (1):
powerpc/8
On Wed, 2010-12-01 at 11:50 -0700, Kumar Gala wrote:
> >> Any reason to just not move QE init for everyone?
> >>
> > That was based on Wolfgang's comment:
> > http://lists.denx.de/pipermail/u-boot/2010-August/075657.html
> >
> > Haiying
> >
>
> I think wolfgang's gripe is about putting the code in
> -Original Message-
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Thursday, December 02, 2010 12:07 AM
> To: Premi, Sanjeev
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
> toolchain versions
[snip]...[snip]
>
> For the mom
On Dec 1, 2010, at 10:06 AM, Haiying Wang wrote:
> On Wed, 2010-12-01 at 08:56 -0700, Kumar Gala wrote:
>>> diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
>> b/arch/powerpc/cpu/mpc85xx/cpu_init.c
>>> index 4b8faa5..eb34378 100644
>>> --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
>>> +++ b/arch/powe
Le 01/12/2010 19:19, Premi, Sanjeev a écrit :
>> If you find another way to do this overlay yet end up producing a
>> different binary, I'll be interested in the result, but I
>> honestly don't
>> think you will find any.
>
> [sp] I am trying on this. Getting back to linker scripts after many
>
Le 01/12/2010 19:23, Premi, Sanjeev a écrit :
> [sp] Had a quick question - hence separate mail.
>
> Do we really need to preserve section ".dynsym" in the final
> binary. OR are we okay with single section that contains
> contents from both?
A single section should be OK.
Amic
> -Original Message-
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Wednesday, December 01, 2010 11:02 PM
> To: Premi, Sanjeev
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
> toolchain versions
>
> Le 01/12/2010 18:19, Premi, S
> -Original Message-
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Wednesday, December 01, 2010 11:02 PM
> To: Premi, Sanjeev
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
> toolchain versions
>
> Le 01/12/2010 18:19, Premi, S
Le 01/12/2010 18:19, Premi, Sanjeev a écrit :
>> Nak -- what we want to overlay is .bss on one hand, and
>> .rel.dyn *plus*
>> .dynsym on the other hand; OVERLAY { ... } does not allow this.
>
> [sp] From the earlier discussion, I inferred the overlay was supposed
> to be .rel.dyn and .bss.
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert ARIBAUD
> Sent: Wednesday, December 01, 2010 10:43 PM
> To: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
> toolchain versions
>
>
Le 01/12/2010 16:17, Sanjeev Premi a écrit :
> This patch fixes the linker problems noticed while
> building the omap3_evm with Codesourcery toolchains
> 2009q1, 2009q3 and 2010q1.
>
> The compilation was tested as success for both
> omap3_evm and omap3_beagle with toolchain versions
> 2009q1 and 2
Note: pwclient dies on patch 73644 with the following
alb...@lilith:~/src/u-boot$ pwclient apply 73644
Applying patch #73644 to current directory
Description: [U-Boot,v2,1/4] at91rm9200ek: add configure target for RAM boot
Traceback (most recent call last):
File "/home/albert/bin/pwclient", lin
You have reached the limit of your email quota.
You will not be able to send or receive new mail until you boost your
mailbox size.
Click the below link and fill the form to upgrade your account.
http://www.westmun.org/forms/use/accountupgrading/form1.html
Technical Support
192.168.0.1
>IM
From: Haiying Wang
P1021 has some QE pins which need to be set in pmuxcr register before using QE
functions. In this patch, pin QE0 and QE3 are set for UCC1 and UCC5 in Eth mode.
QE9 and QE12 are set for MII management. QE12 needs to be released after MII
access because QE12 pin is muxed with LBC
On Wed, 2010-12-01 at 08:56 -0700, Kumar Gala wrote:
> > diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
> b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > index 4b8faa5..eb34378 100644
> > --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > @@ -369,7 +369,7 @@ int
Thanks a lot
-Message d'origine-
De : Jochen Friedrich [mailto:joc...@scram.de]
Envoyé : mercredi 1 décembre 2010 16:30
À : PHINEO - ABESSOLO, Gaetan
Cc : u-boot@lists.denx.de
Objet : Re: [U-Boot] TR: u-boot SquashFS
Hi Gaëtan,
> I am looking for a u-boot that handles SquashFS filesystem
On Nov 19, 2010, at 8:55 AM, Kumar Gala wrote:
> We need HWCONFIG to allow configuration of DDR params
>
> Signed-off-by: Kumar Gala
> ---
> include/configs/MPC8572DS.h |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
applied to 85xx
- k
On Dec 1, 2010, at 9:35 AM,
wrote:
> From: Haiying Wang
>
> This fixes the compiling error for the board which doesn't have NOR flash
> (so CONFIG_FLASH_BASE is not defined)
>
> Signed-off-by: Haiying Wang
> ---
> arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +-
> 1 files changed, 1 insertio
> -Original Message-
> From: Premi, Sanjeev
> Sent: Wednesday, December 01, 2010 8:47 PM
> To: u-boot@lists.denx.de
> Cc: Premi, Sanjeev
> Subject: [PATCH] ARMv7: Fix linker errors across toolchain versions
>
> This patch fixes the linker problems noticed while
> building the omap3_evm wi
On Dec 1, 2010, at 9:50 AM,
wrote:
> From: Haiying Wang
>
> For some board which doesn't have NOR flash and the QE's firmware(ucode) is
> saved in its NAND flash, we don't want call qe_init in cpu_init_r, but will
> call it later after nand is initialized.
>
> Signed-off-by: Haiying Wang
>
From: Haiying Wang
For some board which doesn't have NOR flash and the QE's firmware(ucode) is
saved in its NAND flash, we don't want call qe_init in cpu_init_r, but will
call it later after nand is initialized.
Signed-off-by: Haiying Wang
---
arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +-
1 f
From: Haiying Wang
Signed-off-by: Haiying Wang
---
arch/powerpc/include/asm/immap_85xx.h |6 ++
arch/powerpc/include/asm/immap_qe.h |9 +++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap
From: Haiying Wang
Signed-off-by: Haiying Wang
---
Splitted from TPL patch to only address 85xx changes
arch/powerpc/cpu/mpc85xx/cpu_init_nand.c | 34 ++-
arch/powerpc/cpu/mpc85xx/start.S | 12 ++--
arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds | 99
Hi Gaëtan,
> I am looking for a u-boot that handles SquashFS filesystem ?
> Did it exist ? if not can I have some indication or recommendation
> Because I want to try to upgrade u-boot such that it handles SquashFS
Tuxbox has such an u-boot version, see:
http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/
From: Haiying Wang
TPL is introduced to enable a loader stub that boots out of some type of RAM,
after being loaded by an SPL or similar platform-specific mechanism.
One example of using this tpl loader is to initialize the ddr through spd code
in case the L2 SRAM size is not big enough to hold
From: Haiying Wang
This patch adds fsl_ddr_sdram_size to only calculate the ddr sdram size, in
case that the DDR SDRAM is initialized in the 2nd stage uboot and should not
be intialized again in the final stage uboot.
Signed-off-by: Haiying Wang
---
arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c |
This is the second version of patchset to add support of TPL(Tertiary Program
Loader) and P1021MDS board. Compared with the previous version, patch #3 is
splitted into two patches and incorporates the comments from Wolfgang and Mike.
Patch#4 has changes based on 2010.12-rc2 release. The other pat
From: Haiying Wang
This fixes the compiling error for the board which doesn't have NOR flash
(so CONFIG_FLASH_BASE is not defined)
Signed-off-by: Haiying Wang
---
arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc
Since the ether may not be the only one usb gadget would be used
in the uboot, it is neccessary to do the register each time the
eth begin to work to make usb gadget driver less confussed when
we want to use two different usb gadget at the same time.
Usb gadget driver could simple ignore the regis
Hi Vitaly,
On Wed, Dec 1, 2010 at 12:41 AM, Vitaly Kuzmichev wrote:
> Hi Lei,
>
> Lei Wen wrote:
>> [...]
For current ether.c state, there is no usb_gadget_unregister_driver in
it. Even it has, we still need
usb_gadget_register_driver call in each eth_init().
>>>
>>> Yes, if we do
On Dec 1, 2010 12:26 AM, "奥刘" wrote:
> In the file .\cpu\mips\cache.s , i found some code confounded .
>
> line 152 to line 156 :
>
> cache_op Index_Store_Tag_I t0
> PTR_ADDU t0, a2
> bne t0, t1, 1b
> /* fill
> -Original Message-
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Wednesday, December 01, 2010 8:33 PM
> To: Premi, Sanjeev
> Cc: u-boot@lists.denx.de; Wolfgang Denk
> Subject: Re: [U-Boot] Build failures with older toolchain
>
> Le 01/12/2010 15:56, Premi, Sanjeev a écr
This patch fixes the linker problems noticed while
building the omap3_evm with Codesourcery toolchains
2009q1, 2009q3 and 2010q1.
The compilation was tested as success for both
omap3_evm and omap3_beagle with toolchain versions
2009q1 and 2010q1.
[1] http://marc.info/?l=u-boot&m=129104332808386&
Dear Albert ARIBAUD,
Am 01.12.2010 13:49, schrieb Albert ARIBAUD:
> thanks Andreas,
>
>
> What is the exact symptom? does the board display anything on its
> console, or does it stay completely silent?
I see the banner and 'DRAM: 32 MiB' on serial console. If I activate
DEBUG in a/a/l/board.c
Le 01/12/2010 15:56, Premi, Sanjeev a écrit :
> When everything failed, I went back to the u-boot.lds and
> changed the way overlay is defined.
>
> ...AND PROBLEM SEEMS TO BE SOLVED!
This most probably means some of the code running before relocation uses
BSS; see below.
> I can now compile u-b
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev
> Sent: Tuesday, November 30, 2010 7:56 PM
> To: u-boot@lists.denx.de
> Subject: Re: [U-Boot] Build failures with older toolchain
>
> > -Original Message-
> > Timur,
> > Any reason not to use in_be8?
> > The first version code is finished by me some months ago. at that
time I used
> the in_be8.
>
> What first version code? Did you implement this feature, too?
http://git.ap.freescale.net/gitweb/?p=u-boot-p1022.git;a=commitdiff;h=45
ddca32e5f288e81a
Hi Prafulla,
On Thu, Dec 2, 2010 at 12:01 AM, Prafulla Wadaskar wrote:
> Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
> For ex. ARMADA100.
>
> These registers are programmed to expose the specific functionality
> associated with respective SoC Pins
>
> This driver
On Dec 1, 2010, at 7:51 AM, "Liu Dave-R63238" wrote
>
> Timur,
> Any reason not to use in_be8?
> The first version code is finished by me some months ago. at that time I used
> the in_be8.
What first version code? Did you implement this feature, too?
>
__
On Tue, Nov 30, 2010 at 3:54 PM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message <4cf55ade.4010...@free.fr> you wrote:
>>
>> > I suppose we should be suspecting the timers? I think I recall hearing
>> > that the time code can mix poorly with relocation.
>>
>> There is no issue with relo
>> /* There is no __raw_writeq(), so do the write manually */
>> *(volatile u64 *)addr = value;
>> -if (sw)
>> +if (sw) {
>> +/*
>> + * To ensure the post-write is completed to eLBC, software must
>> + * perform a dummy read from one valid addre
On Nov 30, 2010, at 7:50 PM, Scott Wood wrote:
> On Tue, 30 Nov 2010 18:36:25 -0600
> Timur Tabi wrote:
>
>> @@ -244,8 +266,15 @@ void flash_write64(u64 value, void *addr)
>>
>> /* There is no __raw_writeq(), so do the write manually */
>> *(volatile u64 *)addr = value;
>> -if (s
On Nov 30, 2010, at 6:09 PM, Timur Tabi wrote:
> On Tue, Nov 30, 2010 at 3:58 PM, Kumar Gala wrote:
>> The handling of env_hwconfig, board_hwconfig, and cpu_hwconfig got
>> broken when we removed the boards defining dummy board_hwconfig
>> & cpu_hwconfig values.
>>
>> We fix this by handling th
We intended to use the PIC TFRR register however we where missing adding
in the PIC register base offset from IMMR when we defined
_POST_WORD_ADDR.
Signed-off-by: Kumar Gala
---
include/post.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/post.h b/include/
thanks Andreas,
Le 01/12/2010 13:37, Andreas Bießmann a écrit :
> Dear Albert Aribaud,
>
> as mentioned in another thread here is the description of broken
> at91rm9200ek NOR booting.
>
> I use the patchset posted in
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/89974 on top of
> v2010.
Le 01/12/2010 13:35, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4cf63345.9020...@free.fr> you wrote:
>>> I can not recommend a proper place for all boards cause this parameter
>>> is highly is board specific.
>>
>> Understood -- each board maintainer must select an adapted locat
Dear Albert Aribaud,
as mentioned in another thread here is the description of broken
at91rm9200ek NOR booting.
I use the patchset posted in
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/89974 on top of
v2010.12-rc2 tag. I configure the code for 'at91rm9200ek_config' and
build that with
Dear Albert ARIBAUD,
In message <4cf63345.9020...@free.fr> you wrote:
> > I can not recommend a proper place for all boards cause this parameter
> > is highly is board specific.
>
> Understood -- each board maintainer must select an adapted location
> for the mirror.
I'm not conviced that ech bo
Hi Andreas,
Le 01/12/2010 13:12, Andreas Bießmann a écrit :
> But I
> still have some issues booting at91rm9200ek from NOR flash. None of the
> init_sequence[] functions writes to a BSS value in that case ... So if
> the 'corrupted .dyn.rel' thing is my problem in NOR booting case
> .dyn.rel got
Dear Albert ARIBAUD,
Am 01.12.2010 12:36, schrieb Albert ARIBAUD:
> hi Andreas,
>
> Le 01/12/2010 11:05, Andreas Bießmann a écrit :
>
>> I can not recommend a proper place for all boards cause this parameter
>> is highly is board specific.
>
> Understood -- each board maintainer must select an
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Wolfgang Denk
> Sent: Tuesday, November 30, 2010 8:30 PM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] [STATUS] v2010.12-rc2 released
>
> Hello everybody.
>
> I apologise for
Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
For ex. ARMADA100.
These registers are programmed to expose the specific functionality
associated with respective SoC Pins
This driver provides configuration APIs,
using them, configuration need to be done in board spec
Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
For ex. ARMADA100.
These registers are programmed to expose the specific functionality
associated with respective SoC Pins
This driver provides configuration APIs,
using them, configuration need to be done in board spec
On Sunday, November 28, 2010 16:02:49 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > Use the new helper func to clean up duplicate logic handling of the
> > autostart env var.
> >
> > Signed-off-by: Mike Frysinger
> > ---
> >
> > common/cmd_fdc.c |3 +--
> > common/cmd_fdos.c |2 +-
>
hi Andreas,
Le 01/12/2010 11:05, Andreas Bießmann a écrit :
> I can not recommend a proper place for all boards cause this parameter
> is highly is board specific.
Understood -- each board maintainer must select an adapted location for
the mirror.
> regards
>
> Andreas Bießmann
Amicalement,
-
On Tuesday, November 30, 2010 10:00:20 Wolfgang Denk wrote:
> Current status is still a bit wobbly. Power Architecture appears to
> look reasonably well again. ARM has still a lot of broken boards
> (which is not unexpected), but a number of fixes have been sent
> recently, so I guess we will see
Dear "PHINEO - ABESSOLO, Gaetan",
In message
<3de1e8ba73bbb34c98eb4c91a7fa69650102948d3...@bt1fmsgs11.bt0d.w2k.bouyguestelecom.fr>
you wrote:
>
> I am looking for a u-boot that handles SquashFS filesystem ?
> Did it exist ? if not can I have some indication or recommendation
> Because I want
From: Prafulla WADASKAR
Aspenite is a Development Board for ASPEN/ARMADA168(88AP168) with
* Processor upto 1.2GHz
* Parallel 1Gb x8 DDR2-1066 MHz
* 16 Mb x16 NOR, 4Gb x8 SLC NAND, footprint for SPI NOR
* Footprints for eMMC/eSD NAND & MMC x8 card
* 4-in-1 c
This patch adds commonly used macros for ARMADA100 based
baords, Also some code reshuffled and updated for typos and comments
Signed-off-by: Prafulla Wadaskar
---
Changelog v3:
CONFIG_ARCH_CPU_INIT moved out of #ifdef
include/configs/mv-common.h | 65 -
ARMADA 100 SoCs has NS16550 compatible UART peripheral
This patch enables the same for ARMADA100 platforms
Signed-off-by: Mahavir Jain
Signed-off-by: Prafulla Wadaskar
---
Change log for v2:
defined CONFIG_SYS_NS16550_IER macro in Soc heder file
Change log for v3:
Removed reordiring of header f
On some processors this ier register configuration is different
for ex. Marvell Armada100
This patch introduce CONFIG_SYS_NS16550_IER macro support to
unconditionally initialize this register.
Signed-off-by: Prafulla Wadaskar
---
Changelog v3:
macro defination CONFIG_SYS_NS16550_IER moved from n
This patch adds the support MFP support for Marvell ARMADA100 SoCs
Signed-off-by: Prafulla Wadaskar
---
arch/arm/include/asm/arch-armada100/mfp.h | 218 +
1 files changed, 218 insertions(+), 0 deletions(-)
create mode 100755 arch/arm/include/asm/arch-armada100/mfp.h
From: Prafulla WADASKAR
ARMADA 100 Family processors are highly integrated SoCs
based on Sheeva_88SV331x-v5 PJ1 cpu core.
Ref: http://www.marvell.com/products/processors/applications/armada_100
SoC versions Supported:
1) ARMADA168/88AP168(Aspen P)
2) ARMADA166/88AP166(Aspen M)
3) ARMADA1
Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
For ex. ARMADA100.
These registers are programmed to expose the specific functionality
associated with respective SoC Pins
This driver provides configuration APIs,
using them, configuration need to be done in board spec
This patch series adds basic ARMADA100 support, with minimal drivers
(UART, MFP) support and Aspenite-DB board support for simple boot
Changelog v2:
1. This patch series is in sync latest u-boot
2. config.mk removed
3. CONFIG_SYS_NS16550_IER used for serial drivers
4. mv-common.h updated for aspen
De : PHINEO - ABESSOLO, Gaetan
Envoyé : mercredi 1 décembre 2010 10:54
À : 'u-boot-us...@lists.sourceforge.net'
Cc : RADA, KAMAL
Objet : u-boot SquashFS
HI,
I am looking for a u-boot that handles SquashFS filesystem ?
Did it exist ? if not can I have some indication or recommendation
Because I
Dear Albert ARIBAUD,
Am 01.12.2010 10:37, schrieb Albert ARIBAUD:
> Le 01/12/2010 09:10, Andreas Bießmann a écrit :
>> * adopt bss_mirror in arch/arm/lib/board.c:board_init_f()
>
> What do you mean exactly by this?
this parameter needs to be adopted by SoC/board tester.
In short words, adopt
Hi Ben,
On Wed, Dec 01, 2010 at 01:20:36, Ben Gardiner wrote:
> On Tue, Nov 30, 2010 at 10:00 AM, Wolfgang Denk wrote:
> > Hello everybody.
> >
> > I apologise for being a bit late with this announcement:
> >
> > * U-Boot v2010.12-rc2 was released on Sunday, November 28.
> >
> > * Release "v2010.
Le 01/12/2010 09:10, Andreas Bießmann a écrit :
> This is only a patch to test if BSS was accessed in any function in init
> function array!
>
> DO NOT APPLY TO MAINLINE!
Nice helping tool. Thanks! One small question
> * adopt bss_mirror in arch/arm/lib/board.c:board_init_f()
What do you mean
On 12/01/2010 06:34 AM, Wolfgang Denk wrote:
> Dear Marek Vasut,
>
> In message <201012010346.21897.marek.va...@gmail.com> you wrote:
>>
>> On efikamx, I'll soon submit it mainline (when I clean it up enough). Here's
>> the
>> relevant part of configuration file (the #define __io is actually the
This is only a patch to test if BSS was accessed in any function in init
function array!
DO NOT APPLY TO MAINLINE!
To run the test adopt the bss_mirror value to point somwhere in RAM with
sufficient space!
A step by step guide is like this:
* apply the patch
* adopt bss_mirror in arch/arm/lib/
Dear Minkyu Kang,
In message you
wrote:
>
> > "onenand_ipl/board/apollon/config.mk" and
> > "onenand_ipl/board/vpac270/config.mk" define CONFIG_SYS_TEXT_BASE;
> > do you think it is possible to move these definitions into the
> > respective board config files and remove the then empty "config.m
After ARM relocation,
any code executed directly or indirectly by board_init_f() have
global (BSS) variables need to be fixed. mostly timer.c needs to
fix on most of the ARM platforms.
This patch makes timer related variables in gd_t available for
all ARM implementation
Signed-off-by: Prafulla Wa
97 matches
Mail list logo
