Dear Sebastien,
Am 15.11.2010 um 12:43 schrieb Sebastien Carlier:
> Dear Andreas,
>
> On 2010-11-15 12:09:58, Andreas Bießmann wrote:
>>
>> arm920t/at91 is ongoing. I may need your help these days but first I
>> need some time to get my last linker related issues fixed properly
>> (segfault whe
2010/11/16 Wolfgang Denk :
> Dear Jason Liu,
>
> In message you
> wrote:
>>
>> Do you have any good method to put the mac address into one structure
>> and use that filed to access it?
>> Currently, we only use the MAC fuse, there is a lot of fuse not used?
>> if we defined as bellow, what your
Dear Jason Liu,
In message you
wrote:
>
> Do you have any good method to put the mac address into one structure
> and use that filed to access it?
> Currently, we only use the MAC fuse, there is a lot of fuse not used?
> if we defined as bellow, what your comments?
>
> struct iim_regs {
>
>
>> diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
>> b/arch/arm/include/asm/arch-mx5/imx-regs.h
>> index 0b6249a..93eef48 100644
>> --- a/arch/arm/include/asm/arch-mx5/imx-regs.h
>> +++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
>> @@ -205,6 +205,9 @@
>> #define BOARD_REV_1_0 0
Dear Steve Sakoman,
On 29 October 2010 02:17, Steve Sakoman wrote:
> From: Alagu Sankar
>
> This patch adds multi-block read support for the generic MMC
> driver. Large reads are broken into chunks of 65535 blocks to
> ensure that the code works with controllers having a 16 bit block counter.
>
> For now, I would like to ask all CUSTODIANS to register as users at
> patchwork.ozlabs.org, so we can arrange that the appropriate
> privileges will be granted to you.
>
Registered as 'macpaul'.
Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.
Since we set #define MORECORE_CLEARS 1, the code assumes 'sbrk' always
returns zero'd out memory. However since its possible that free()
returns memory back to sbrk() via malloc_trim we could possible get
non-zero'd memory from sbrk(). This is a problem for when code might
call calloc() and expec
On Nov 15, 2010, at 4:06 PM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <1289854274-7006-1-git-send-email-ga...@kernel.crashing.org> you
> wrote:
>> Since we set #define MORECORE_CLEARS 1, the code assumes 'sbrk' always
>> returns zero'd out memory. However since its possible that
> Wouldn't the fact that you're accessing the same address -- and
> that it's cache inhibited -- eliminate the need for a sync instruction
> between the stw and lwz?
You are right. If st and ld the same address, e300 core have a address
collision inside.
It will make sure the order. Here we don't
Typo from 4b29bdb0ed08412d225a8be94f61fc6c37a59dd5
Signed-off-by: Matthew McClintock
---
drivers/net/e1000.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 18584ef..60b04c2 100644
--- a/drivers/net/e1000.c
+++ b/drivers/n
On Thu, 11 Nov 2010 11:37:36 +0800
Xiangfu Liu wrote:
> From: Xiangfu Liu
>
> Signed-off-by: Xiangfu Liu
> ---
> drivers/mtd/nand/jz4740_nand.c | 250
>
> 1 files changed, 250 insertions(+), 0 deletions(-)
> create mode 100644 drivers/mtd/nand/jz474
On Thu, 11 Nov 2010 11:37:35 +0800
Xiangfu Liu wrote:
> +$(nandobj)u-boot-spl-16k.bin: $(nandobj)u-boot-spl.bin
> + dd bs=1024 count=8 if=/dev/zero of=$(nandobj)junk1
> + cat $< $(nandobj)junk1 > $(nandobj)junk2
> + dd bs=1024 count=8 if=$(nandobj)junk2 of=$(nandobj)junk3
> + cat
Dear Kumar Gala,
In message <1289854274-7006-1-git-send-email-ga...@kernel.crashing.org> you
wrote:
> Since we set #define MORECORE_CLEARS 1, the code assumes 'sbrk' always
> returns zero'd out memory. However since its possible that free()
> returns memory ack to sbrk() via malloc_trim we could
On Monday, November 15, 2010 15:51:14 Kumar Gala wrote:
> returns memory ack to sbrk() via malloc_trim we could possible get
"ack" -> "back"
> The following code problems an example test to show the issue.
i dont understand this sentence
> we
> could possible get non-zero'd memory from sbrk() i
Since we set #define MORECORE_CLEARS 1, the code assumes 'sbrk' always
returns zero'd out memory. However since its possible that free()
returns memory ack to sbrk() via malloc_trim we could possible get
non-zero'd memory from sbrk() if it allocates back memory that was
previously freed to it.
Th
Le 15/11/2010 21:46, Albert Aribaud a écrit :
> older ld emitted all ELF relocations in input sections named
> .rel.dyn, whereas newer ld uses names of the form .rel*. The
> linker script only collected .rel.dyn input sections. Rewrite
> to collect all .rel* input sections.
>
> Signed-off-by: Albe
older ld emitted all ELF relocations in input sections named
.rel.dyn, whereas newer ld uses names of the form .rel*. The
linker script only collected .rel.dyn input sections. Rewrite
to collect all .rel* input sections.
Signed-off-by: Albert Aribaud
---
nand_spl/board/karo/tx25/u-boot.lds | 4
older ld emitted all ELF relocations in input sections named
.rel.dyn, whereas newer ld uses names of the form .rel*. The
linker script only collected .rel.dyn input sections. Rewrite
to collect all .rel* input sections.
Signed-off-by: Albert Aribaud
---
V1 Initial submission
V2 arm926e
On Nov 15, 2010, at 2:39 PM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <9d70a5ef-48ad-4d65-85d6-b81ce0a0d...@kernel.crashing.org> you
> wrote:
>>
>> Here's an example test case that fails if execute right after:
>
> I confirm that the test case shows errors for me, too (tested on
Dear Kumar Gala,
In message <9d70a5ef-48ad-4d65-85d6-b81ce0a0d...@kernel.crashing.org> you wrote:
>
> Here's an example test case that fails if execute right after:
I confirm that the test case shows errors for me, too (tested on
TQM8555). I also confirm that switching MORECORE_CLEARS to 0 fixes
Dear =?ISO-8859-1?Q?Per_Dal=E9n?=,
In message you
wrote:
>
> What can be course of my ProgramCheck exception and how should I
> proceed with my tests?
Re-check your memory initialization.
See http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation
Best regards,
Wolfgang Denk
--
DENX So
On Nov 13, 2010, at 10:34 AM, Kumar Gala wrote:
> I've been debugging a "memory corruption" issue and it seems to come down to
> how we set MORECORE_CLEARS
>
> from malloc.h:
>
> MORECORE (default: sbrk)
> The name of the routine to call to obtain more memory from the sys
On Monday, November 15, 2010 03:09:50 Sebastien Carlier wrote:
> On 2010-11-15 08:51:29, Wolfgang Denk wrote:
> > In message <20101110080708.ga8...@safe.home.local> you wrote:
> > > Good suggestion, done in v3:
> > I have to admit that I lost a bit of overview of the current state of
> > this work.
On Sat, 13 Nov 2010 17:33:02 +
Miguel José Amez Riendas wrote:
> Hi list,
>
> this is my first post on u-boot list.
> I'm trying to write function "board_nand_init" for a Pollux VR3520F SoC
> based board.
> I'm having some troubles and really don't know very good where to start and
> which p
The Blackfin on-chip BootROM requires that fill operations (which is
used for the bss) be aligned to 4 bytes (base addr and total len).
Plus, the Blackfin early init asm code assumes the same thing. So
rather than making things work for no real gain, make sure the bss
len is padded to 4 bytes in t
This lets the linker garbage collect these functions when they aren't
actually used by placing them into the standard .text. section.
Signed-off-by: Mike Frysinger
---
arch/blackfin/lib/ins.S |1 +
arch/blackfin/lib/outs.S |4
2 files changed, 5 insertions(+), 0 deletions(-)
diff
On Mon, Nov 15, 2010 at 03:15:53PM +0100, Daniel Hobi wrote:
> Did you locally fix arch/arm/cpu/arm926ejs/kirkwood/timer.c to not
> access uninitialized data (variables timestamp and lastdec) before
> relocation?
I didn't before, but now I have made that change (moved the static
vars in timer.c to
[Responding here rather than directly to Dave since his e-mail showed
up blank here for some reason]
On Mon, 15 Nov 2010 18:30:46 +0100
Joakim Tjernlund wrote:
> >
> > > The experts found an issue within init code and it looks like a proper
> > > patch will be added to mainline shortly.
> > > Th
Hi,
I am currently trying to get u-boot working on our new P2020E card.
The card is using 512 Mbyte DDR3 memmory and a 128 MByte NOR flash.
For my tests I also have a P2020-RDB card and a BDI3000.
I have been able to get u-boot working from flash, but the problems
begin when the in_ram function is
On Sat, 13 Nov 2010 11:43:23 +0800
terry wrote:
> and the following is part of malloc after disassembled, you can find the
> detailed content of malloc in the attachment malloc.dis file(I'm not
> sure which part could be useful,so I attached whole malloc).
>
> 61 33f8fb84: 9a04bls 33f
>
> > The experts found an issue within init code and it looks like a proper
> > patch will be added to mainline shortly.
> > The discussion of the proper fix is right in this thread ...
>
> It should be timing issue in the SoC, software did not have a proper
> process to handle
> IMMR registers ac
> The experts found an issue within init code and it looks like a proper
> patch will be added to mainline shortly.
> The discussion of the proper fix is right in this thread ...
It should be timing issue in the SoC, software did not have a proper
process to handle
IMMR registers accessing.
I agr
Am 15.11.2010 17:16, schrieb Wolfgang Denk:
> Dear Andre Schwarz,
>
> In message<4ce1572c.6080...@matrix-vision.de> you wrote:
> This doesn't seem quite right, the MPC837x has USB controllers.
>
yes, it has - and it is working fine.
But USB register range 0x00-0xff is reserved an
Dear Andre Schwarz,
In message <4ce1572c.6080...@matrix-vision.de> you wrote:
>
> >>> This doesn't seem quite right, the MPC837x has USB controllers.
> >>>
> >> yes, it has - and it is working fine.
> >> But USB register range 0x00-0xff is reserved and hangs the CPU.
> >>
> >> With this pa
Wolfgang,
> Dear Andre Schwarz,
>
> In message<4ce14e3e.7060...@matrix-vision.de> you wrote:
>
>>
>>> This doesn't seem quite right, the MPC837x has USB controllers.
>>>
>> yes, it has - and it is working fine.
>> But USB register range 0x00-0xff is reserved and hangs the CPU.
>
On Mon, Nov 15, 2010 at 4:46 AM, Stefano Babic wrote:
>
> This board uses the OMAP-L138 SOM stacked on a
> custom baseboard. It supports SPI Flash, Ethernet
> with RMII.
>
> Signed-off-by: Stefano Babic
> ---
> Changes since V2:
> - Rebased on the following patch(Sughosh Ganu):
> [...]
> diff --
On Mon, Nov 15, 2010, Albert ARIBAUD wrote:
> I assume that the -kernel option indicates the executable to run.
Correct, IOW u-boot.bin
> Would it take an ELF executable? a binary?
You can pass an ELF as well
>How would one go about
> testing runnin
Dear Andre Schwarz,
In message <4ce14e3e.7060...@matrix-vision.de> you wrote:
>
> > This doesn't seem quite right, the MPC837x has USB controllers.
>
> yes, it has - and it is working fine.
> But USB register range 0x00-0xff is reserved and hangs the CPU.
>
> With this patch USB is working fine
Kumar,
>> Signed-off-by: Andre Schwarz
>> ---
>> arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
> This doesn't seem quite right, the MPC837x has USB controllers.
>
> - k
>
yes, it has - and it is working fine.
But USB register range 0
On Nov 13, 2010, at 12:22 PM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message you
> wrote:
>>
>> I'd like to move cpu_init_r to after env_relocate(). This is desirable
>> on 85xx based systems to deal with an issue when we boot from NAND (and
>> probably SPI or SDHC/MMC) in which we u
On Nov 14, 2010, at 4:24 PM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <1289556786-15201-1-git-send-email-ga...@kernel.crashing.org> you
> wrote:
>> nic and hw structures are allocated via malloc i.e. return memory
>> is not zero initialized. Because of this few structure member li
On Nov 15, 2010, at 8:53 AM, Andre Schwarz wrote:
>
> Signed-off-by: Andre Schwarz
> ---
> arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
This doesn't seem quite right, the MPC837x has USB controllers.
- k
>
> diff --git a/arch/powerpc/cpu/m
On Nov 14, 2010, at 7:18 AM, terry wrote:
> 在 2010-11-13六的 10:24 -0600，Kumar Gala写道：
>> On Nov 12, 2010, at 9:43 PM, terry wrote:
>>
>
> by the way,I cann't find the prototype of malloc in the whole project,it
> seems that it is encapsulated in some libs.
It's in common/m
Dave,
> I notice this is hot thread for 83xx in these days.
> Anybody can share more background for the issue?
> I would like have a look the issue.
>
during MPC8377 board bring up we couldn't get U-Boot up and running -
the serial line has been dead.
Using a bdi2000 debugger told us the CPU
Fine by me
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: 14 November 2010 20:58
> To: Peter Pearse
> Cc: Himanshu Chauhan; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] CONFIG_SYS_SDRAM and
> CONFIG_SYS_INIT_SP_ADDR defines for versatile boards.
>
> De
> Has anyone else tested 83xx on NOR?
> My guess is that cache line crossing shifted so that now the CPU
> doesn't need to read in a new cache at the critical part.
I notice this is hot thread for 83xx in these days.
Anybody can share more background for the issue?
I would like have a look the iss
Signed-off-by: Andre Schwarz
---
arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c
b/arch/powerpc/cpu/mpc83xx/cpu_init.c
index 7a1cae7..cfead18 100644
--- a/arch/powerpc/cpu/mpc83xx/cpu_init.c
+++ b/
Le 15/11/2010 15:15, Daniel Hobi a écrit :
> @Albert: If your patch is applied without fixing the accesses to BSS
> before relocation, some ARM ports will be broken even when compiling
> with ELDK 4.2.
Thanks for pointing this out.
Indeed, my patch is actively based on the assumption that BSS is
Le 15/11/2010 15:06, Loïc Minier a écrit :
> So I'm afraid I couldn't find a fully working combination of U-Boot
> supported board + QEMU, but I didn't try QEMU tip; I'm Cc:ing Peter who
> cares for QEMU in Linaro, maybe he has more idea or is tempted to try a
> tip QEMU :-)
Not sure I g
Hi Eric,
On 10.11.2010 00:43, Eric Cooper wrote:
> I have been periodically rebasing my patches for the Seagate DockStar
> on master. But ever since the elf_reloc changes were merged, I have
> been unable to get a working build. First I saw symptoms similar to
> what Alexander Holler reported (f
On Mon, Nov 15, 2010, Wolfgang Denk wrote:
> Do you have a working qemu setup and/or documentation how to run
> U-Boot on such an ARM config?
Sometimes I do ;-)
I use either:
* Ubuntu QEMU packages - qemu-kvm-extras package has qemu-system-arm;
it's usually fairly old because it's built fr
On Monday, November 15, 2010 07:38:28 Mike Frysinger wrote:
> some of this is simply due to change in linking order and the implicit
> padding in between each symbol for alignment requirements
>
> you can check how much this adds with the attached script:
this version fixes handling with defined
On Mon, 15 Nov 2010 12:49:58 +0100, Albert ARIBAUD
wrote:
>
>> Do you think you could convert the remaining CPUs to ELF relocation as
>> well? That would probably provide the best base for any further work.
>
> I can make the changes for other cpus, but I cannot perform even basic
> testing b
On Monday, November 15, 2010 07:38:28 Mike Frysinger wrote:
> replace the '$7 == "3"' check with whatever section number you want to
> check. in my case, 3 is ".text".
err, ignore this outdated comment
-mike
signature.asc
Description: This is a digitally signed message part.
On Monday, November 15, 2010 07:13:03 Sebastien Carlier wrote:
> On 2010-11-15 11:54:07, Wolfgang Denk wrote:
> > I notice that the patch affects the size of the resulting U-Boot
> > images.
> >
> > For example:
> >
> > Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
> >
> >text
On Monday, November 15, 2010 06:33:40 Mike Frysinger wrote:
> On Monday, November 15, 2010 05:54:07 Wolfgang Denk wrote:
> > Sebastien Carlier wrote:
> > > I just uploaded the revised patch here:
> > > http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-
arch
> > > iv e-libraries-
Le 15/11/2010 13:02, Wolfgang Denk a écrit :
>> Besides, while I can reasonably provide a V5 patch by this evening
>> for the five cpus which already support ELF, I won't be able to
>> provide fixes for the whole of arch/arm/cpu/* until thursday
>> evening/friday morning. Is that ok?
>
> Th
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
>
> I notice that the patch affects the size of the resulting U-Boot
> images.
>
> For example:
>
> Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
>textdata bss dec hex filename
> 358144 35208 303248 696600 aa118
Dear =?iso-8859-1?Q?Lo=EFc?= Minier,
In message <20101115115556.ga13...@bee.dooz.org> you wrote:
> On Mon, Nov 15, 2010, Albert ARIBAUD wrote:
> > I can make the changes for other cpus, but I cannot perform even basic =
>
> > testing beyond making sure it still builds.
>
> Would qemu be of any
Dear Albert ARIBAUD,
In message <4ce11e66.5060...@free.fr> you wrote:
>
> > Do you think you could convert the remaining CPUs to ELF relocation as
> > well? That would probably provide the best base for any further work.
>
> I can make the changes for other cpus, but I cannot perform even basic
Dear Albert ARIBAUD,
>>> ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136,
>>> arm1176, armv7 and pxa) have ELF relocation support. Others still use
>>> GOT relocation (or the older fixed-location scheme maybe), which IIUC
>>> means all boards using these other cpus are broken
On Mon, Nov 15, 2010, Albert ARIBAUD wrote:
> I can make the changes for other cpus, but I cannot perform even basic
> testing beyond making sure it still builds.
Would qemu be of any help there? You could use e.g. versatile or
integrator, and pretend that they use any CPU by changing their co
Le 15/11/2010 12:13, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4ce11314.50...@free.fr> you wrote:
>>
>> ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136,
>> arm1176, armv7 and pxa) have ELF relocation support. Others still use
>> GOT relocation (or the olde
On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote:
> This commit changes all Makefiles to use partial linking (ld -r) instead of
> creating library archives, which forces all symbols to participate in
> linking, allowing non-weak symbols to override weak symbols as intended.
> This app
Dear Andreas,
On 2010-11-15 12:09:58, Andreas Bießmann wrote:
>
> arm920t/at91 is ongoing. I may need your help these days but first I
> need some time to get my last linker related issues fixed properly
> (segfault when linking empty weak symbol with -pie).
Can you please try the attached patch
Dear Claudio Mignanti,
> 2010/11/13 Reinhard Meyer :
>>> The problem is related to the new MMC driver, simple the mmc driver
>>> don't recognize my cards and also "mmc info" returns no info.
>> Just a blind shot:
>> is your MCI on port B (like it is on the at91sam9xxx-ek)?
>> Then define CONFIG_ATM
On Sunday, November 14, 2010 16:59:33 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > > > Seems this was not a fix, but introduced an error. Dp you agree to
> > > > > revert that commit?
> > > >
> > > > of course i disagree. this change is a fix in my mind.
> > >
> > > Please reconsider. Th
Dear Wolfgang,
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
>
> I notice that the patch affects the size of the resulting U-Boot
> images.
>
> For example:
>
> Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
>textdata bss dec hex filename
> 358144 35208 303248
On Monday, November 15, 2010 05:54:07 Wolfgang Denk wrote:
> Sebastien Carlier wrote:
> > I just uploaded the revised patch here:
> > http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archiv
> > e-libraries-to-partial-linking-v4.patch
> >
> > Version 4:
> > Bring in Linux
Dear Reinhard Meyer
2010/11/13 Reinhard Meyer :
>>
>> The problem is related to the new MMC driver, simple the mmc driver
>> don't recognize my cards and also "mmc info" returns no info.
>
> Just a blind shot:
> is your MCI on port B (like it is on the at91sam9xxx-ek)?
> Then define CONFIG_ATMEL_M
Dear Albert ARIBAUD,
In message <4ce11314.50...@free.fr> you wrote:
>
> ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136,
> arm1176, armv7 and pxa) have ELF relocation support. Others still use
> GOT relocation (or the older fixed-location scheme maybe), which IIUC
> means
Dear Albert ARIBAUD,
Am 15.11.2010 12:01, schrieb Albert ARIBAUD:
> I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136,
> arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board
> maintainers who want to fix their board support for ELF relocs may have
> to
On 15/11/10 07:05, Albert ARIBAUD wrote:
> Le 14/11/2010 20:34, Graeme Russ a écrit :
>> On 15/11/10 06:23, Wolfgang Denk wrote:
>>> Dear Albert ARIBAUD,
>>>
>>> In message<4ce0221a.7030...@free.fr> you wrote:
Alright, then I think we should document how we comply, or do not
comply,
Am Mittwoch, 13. Oktober 2010, um 06:53:37 schrieb Michal Simek:
> Dear Wolfgang,
>
> 2010/10/13 Wolfgang Denk
>
> > Dear Michal Simek,
> >
> > In message <4cb406ba.6030...@monstr.eu> you wrote:
> > > The following changes since commit
> >
> > bfc7bea6adc46e1db2f5a5e3464d7652ed67c864:
> > > --snip
Le 14/11/2010 22:22, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4cdba515.3050...@free.fr> you wrote:
>>
>> Alright. I'll prepare a V5 patch set with fixes to all ARM cpus.
>> Wolfgang, is a single *patch* for all cpus ok or do you want a single
>> *patchset* with one patch per c
Dear Sebastien Carlier,
In message <20101115080950.ga26...@safe.home.local> you wrote:
>
> I just uploaded the revised patch here:
>
>
> http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archive-libraries-to-partial-linking-v4.patch
>
> Version 4:
> Bring in Linux comme
Fixes build breakage in da830evm after commit
97003756249bd790910417eb66f0039bbf06a02c "da8xx: fixup ARM
relocation support"
The da8xx fixup commit changed da830/da850 common code to make
relocation work in da850, but didn't add the required defines
to da830evm_config.h resulting in build failure
On 11/11/2010 01:24 PM, Andre Schwarz wrote:
> Kim, Timur,
>
> some comments on this from your side would really help !
>
>
> The issue can be summarized like this :
>
> - MPC8377 based board is basically running fine with both U-Boot and Linux.
> - Activating USB support within U-Boot leads to *ve
> The following three device controller inside a320 SoC are Soft IP which are
> also used by other SoC products. Here we suggest to move those header files
> out from a320 SoC folder into drivers folder. This change should provide
> header file sharing with multiple SoC.
>
> Macpaul Lin (3):
> f
On 11/14/2010 11:18 PM, Wolfgang Denk wrote:
> Dear Sergiy Kibrik,
>
> In message <4cd27f08.8060...@globallogic.com> you wrote:
>> Improved default config for OMAP4 Pandaboard for faster boot:
>> -reduced environment size to speed up memory initialization;
>> -USB TTY driver turned off;
Andre Schwarz wrote on 2010/11/15 10:57:30:
>
> On 11/12/2010 08:31 PM, Scott Wood wrote:
> > On Fri, 12 Nov 2010 13:26:17 -0600
> > Kumar Gala wrote:
> >
> >
> >> On Nov 12, 2010, at 11:22 AM, Scott Wood wrote:
> >>
> >>
> >>> On Fri, 12 Nov 2010 09:58:53 -0600
> >>> Kumar Gala wrote:
> >>>
> >
On 11/12/2010 08:31 PM, Scott Wood wrote:
> On Fri, 12 Nov 2010 13:26:17 -0600
> Kumar Gala wrote:
>
>
>> On Nov 12, 2010, at 11:22 AM, Scott Wood wrote:
>>
>>
>>> On Fri, 12 Nov 2010 09:58:53 -0600
>>> Kumar Gala wrote:
>>>
We only do the 'twi' for loads/in_beX not stores/
This board uses the OMAP-L138 SOM stacked on a
custom baseboard. It supports SPI Flash, Ethernet
with RMII.
Signed-off-by: Stefano Babic
---
Changes since V2:
- Rebased on the following patch(Sughosh Ganu):
Sughosh Ganu: Move and rename common headers from under board/davinci
This patch requir
On 11/15/2010 08:36 AM, Sughosh Ganu wrote:
> hi Stefano,
>
Hi,
> I had sent a patch some time back to move the misc.h under
> arm/include/asm/arch-davinci/davinci_misc.h. Should this patch be
> based off of that.
>
> [PATCH 1/3 V5] Move and rename common headers from under
> board/da
Wolfgang Denk wrote:
> For now, I would like to ask all CUSTODIANS to register as users at
> patchwork.ozlabs.org, so we can arrange that the appropriate
> privileges will be granted to you.
>
>
Registered as "daniel"
Regards,
Daniel Hellstrom
___
Dear Wolfgang,
On 2010-11-15 08:51:29, Wolfgang Denk wrote:
>
> In message <20101110080708.ga8...@safe.home.local> you wrote:
>
> > Good suggestion, done in v3:
>
> I have to admit that I lost a bit of overview of the current state of
> this work. My understanding is that you are preparing a n
86 matches
Mail list logo
