Hi Dirk,
Le 21/12/2010 08:11, Dirk Behme a écrit :
> But the issue with drivers/mtd/nand/omap_gpmc.c (i.e. the additional
> ldrbr3, [r3]) is still open? Has anybody tried to replace it with
> a nop in the binary to be sure this is the root cause?
Can you try and preprocess the C file for bot
On 21.12.2010 01:46, John Rigby wrote:
> On Mon, Dec 20, 2010 at 5:25 PM, John Rigby wrote:
>> On Mon, Dec 20, 2010 at 10:12 AM, Alexander Holler
>> wrote:
>>
>>> There must be more problems. Using gcc 4.5.1, the read*/write*-patch and
>>> your hack, my kernel doesn't boot. Using gcc 4.3.5 and t
Hi Martin,
2010/12/17 Martin Mueller :
> Hi Gavin,
>
>> > detection might work without PCI slave-initiated transfer and the
>> > root hub is OHCI internal. But - just guessing. If you have double
>> > checked the window there are no more ideas from my side.
>>
>> Do you setup host bridge window ba
Le 21/12/2010 02:27, John Rigby a écrit :
> It can be optimised out by the compiler otherwise resulting
> in obscure errors like a board not booting.
>
> This has been documented in README since 2006 when these were
> first fixed up for GCC 4.x.
>
> Signed-off-by: John Rigby
> ---
I think this sho
Dear Mike Frysinger,
In message <201012201924.42903.vap...@gentoo.org> you wrote:
>
> > I have nothing to add. Please get rid of this unnecessary config.mk file.
>
> so you agree with my statement, or you're going to prevent any new Blackfin
> boards from being merged until something you consid
It can be optimised out by the compiler otherwise resulting
in obscure errors like a board not booting.
This has been documented in README since 2006 when these were
first fixed up for GCC 4.x.
Signed-off-by: John Rigby
---
arch/arm/cpu/armv7/mx5/speed.c |4 ++--
arch/blackfin/cpu/seri
Wolfgang,
Please pull u-boot-ti/next
The DaVinci MMC/SD patches were acked by Andy long ago but never made it
to any tree. Please look at
http://www.mail-archive.com/u-boot@lists.denx.de/msg32375.html
I am trying to upstream the patches as the original author
seems busy
Regards,
Sandeep
The f
On Mon, Dec 20, 2010 at 5:25 PM, John Rigby wrote:
> On Mon, Dec 20, 2010 at 10:12 AM, Alexander Holler
> wrote:
>
>> There must be more problems. Using gcc 4.5.1, the read*/write*-patch and
>> your hack, my kernel doesn't boot. Using gcc 4.3.5 and the same source to
>> compile u-boot the kernel
On Mon, Dec 20, 2010 at 10:12 AM, Alexander Holler wrote:
> There must be more problems. Using gcc 4.5.1, the read*/write*-patch and
> your hack, my kernel doesn't boot. Using gcc 4.3.5 and the same source to
> compile u-boot the kernel comes up. Here is the output for the non-working
> u-boot:
>
We have config_defaults.h which are random configuration settings that
everyone gets by default. We also have config_cmd_default.h which is a
recommended list of defaults but boards have to opt into. Now we have
config_cmd_defaults.h which is a list of defaults that everyone gets
and has to activ
On Monday, December 20, 2010 17:56:38 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > note that these issues shouldnt hold up merging a board which is working
> > the way it should as the other boards.
>
> I have nothing to add. Please get rid of this unnecessary config.mk file.
so you agree wi
Dear Mike Frysinger,
In message <201012201731.47283.vap...@gentoo.org> you wrote:
>
> note that these issues shouldnt hold up merging a board which is working the
> way it should as the other boards.
I have nothing to add. Please get rid of this unnecessary config.mk file.
Best regards,
Wolfg
On Monday, December 20, 2010, Loïc Minier wrote:
> Hey
>
> There is now a u-boot package in Debian and Ubuntu and it fails to
> build the i386 eNET board with:
> gcc -DDO_DEPS_ONLY \
> -g -Os -ffunction-sections -fvisibility=hidden
> -D__KERNEL__ -DCONFIG_SYS_TEXT_BA
On Monday, December 20, 2010 16:05:20 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > And why cannot it be set in the board config file like every other
> > > board doing it?
> >
> > ive explained in the past why. one of the reasons why i think config.mk
> > makes more sense is this setting is
Dear Mike Frysinger,
In message <201012201436.49709.vap...@gentoo.org> you wrote:
>
> > > as for the cpu selection, obviously that cannot be in any common file
> > > since the cpu variant and silicon rev is about as board specific as you
> > > could possibly get.
I did not ask for moving it into
On Monday, December 20, 2010 05:49:22 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > > no, that doesnt make any sense. just because i want some of the
> > > > boards i maintain to favor speed over size doesnt mean every board
> > > > maintainer should. thus the settings are in the board-specif
Hello,
Am 20.12.2010 07:07, schrieb John Rigby:
> With your patch and the following hack nand works:
>
>
> diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
> index 99b9cef..5e94155 100644
> --- a/drivers/mtd/nand/omap_gpmc.c
> +++ b/drivers/mtd/nand/omap_gpmc.c
> @@ -29,6 +
Thanks for the cleanup. What branch should this series be applied to?
And are there prerequisites? I'm having issues applying them to test
and review.
On Fri, 2010-12-17 at 17:50 -0600, Kumar Gala wrote:
> Remove duplicated code in MPC8572 DS board and utliize the common
> fsl_pcie_init_board().
It might be useful to see what compiler version was used to compile u-boot.
---
arch/arm/lib/board.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 96c0e30..df90b5e 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/boa
On Monday, December 20, 2010 8:39 PM, Robert Mortimer wrote:
> First off I aplogise for top posting. It is common on some of the
> groups I am in You will be glad to know I have registerd our board
> with the ARM registry I have updated my local git repo to reflect the
> number we were given. None
On Mon, Dec 20, 2010 at 9:08 AM, John Rigby wrote:
> Earlier in this thread Alexander said:
>> I haven't add the definitions which are using a memory barrier because I
>> haven't found
>> a place in the kernel where they were actually enabled
>> (CONFIG_ARM_DMA_MEM_BUFFERABLE).
>
> I think this i
Earlier in this thread Alexander said:
> I haven't add the definitions which are using a memory barrier because I
> haven't found
> a place in the kernel where they were actually enabled
> (CONFIG_ARM_DMA_MEM_BUFFERABLE).
I think this is the problem because it is indeed defined for all v6
and v7
Dear vijay dixit,
In message you
wrote:
>
> I am bit new to this field and my query here is understandably a
> bit vague. I am particularly interested in how any of you, who have had
> experience with uBoot and a JTAG debugger (like a Lauterbach), have gone
> about tackling and resolvin
Hello,
I am bit new to this field and my query here is understandably a
bit vague. I am particularly interested in how any of you, who have had
experience with uBoot and a JTAG debugger (like a Lauterbach), have gone
about tackling and resolving an issue within uBoot.
Specifically, I wou
First off I aplogise for top posting. It is common on some of the groups I am
in
You will be glad to know I have registerd our board with the ARM registry
I have updated my local git repo to reflect the number we were given.
None of the porting guides I found round the internet seemed to incl
Dear Robert Mortimer,
In message
<1259520402.588.1292850598306.javamail.r...@mailserver.xen.bluechiptechnology.co.uk>
you wrote:
>
> I am porting a board similar to the Beagle to U-Boot. The Beagle config works
> but needs further pin MUXing . I have copied the Beagle board config to a new
> n
Hi,
I am porting a board similar to the Beagle to U-Boot. The Beagle config works
but needs further pin MUXing . I have copied the Beagle board config to a new
name and when compiled the binary performs as per the Beale one. My issue is
when I change the line
51: gd->bd->bi_arch_number = MA
Hey
There is now a u-boot package in Debian and Ubuntu and it fails to
build the i386 eNET board with:
gcc -DDO_DEPS_ONLY \
-g -Os -ffunction-sections -fvisibility=hidden -D__KERNEL__
-DCONFIG_SYS_TEXT_BASE=0x0600
-I/build/buildd-u-boot_2010.12~rc3-1-i386-qoDl82
Dear "T K, Sunil Kumar",
In message <674d2c24c8992f46817bbbf3ecae914f4ec0a9f...@blr-sms-exch01.digi.com>
you wrote:
>
> I downloaded freescale Android2.2 package for my IMX51 board. According to
> the instructions provided in the manual i loaded u-boot onto my device. But
> after this activity,
Dear Mike Frysinger,
In message <201012191818.56840.vap...@gentoo.org> you wrote:
>
> > > no, that doesnt make any sense. just because i want some of the boards i
> > > maintain to favor speed over size doesnt mean every board maintainer
> > > should. thus the settings are in the board-specific c
Only these 2 call sites depends on fixups for my mpc8321 based
board.
Signed-off-by: Joakim Tjernlund
---
arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
arch/powerpc/lib/board.c|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init
link_off calculates the difference between link address and
actual load address. This is a must for true PIC u-boot.
Signed-off-by: Joakim Tjernlund
---
arch/powerpc/cpu/mpc83xx/start.S | 26 ++
include/common.h |7 +++
2 files changed, 33 insert
By copying the GOT to the end of the INIT_RAM(dcache)
and relocating it there, it is much esier to
support true PIC on u-boot. This cannot handle
FIXUP so C code that depends on fixups before relocation to RAM
must use LINK_OFF to calculate the difference.
This depends on the upcoming single-pic-b
Remove dependencies on link address. Use GOT and
add an new function to calculate the actual address.
Signed-off-by: Joakim Tjernlund
---
arch/powerpc/cpu/mpc83xx/start.S | 35 +++
1 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/cpu/
Hi,
I downloaded freescale Android2.2 package for my IMX51 board. According to the
instructions provided in the manual i loaded u-boot onto my device. But after
this activity, its strange to see that my device is not getting started with
the newly loaded u-boot of Freescale's Android2.2.
Can y
From: Po-Yu Chuang
timer.c used static data and are called before relocation.
Move all static variables into global_data structure. Also cleanup
timer.c from unused stubs and make it truly use 64 bit tick values.
Based on Reinhard Meyer 's patch
5dca710a3d7703e41da0e9894f2d71f9e25bea6b
Signed-o
From: Po-Yu Chuang
* add CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR
* do not update gd->bd in dram_init() because bd is unavailable then
* move CONFIG_SYS_TEXT_BASE from config.mk to a320evb.h
* remove config.mk
Signed-off-by: Po-Yu Chuang
---
v2:
rebase
remove config.mk
board/faraday/
37 matches
Mail list logo
