Hi Ran,
Le 15/02/2011 07:35, Ran Shalit a écrit :
> Hello,
>
> I'm working on OMAPL138 EVM board, with the U-BOOT.
> I'm trying to access and write into the register (which have write bits),
> but I always read 0 in all the map space of the mcBSP0 and mcBSP1.
> (0x01d1 - 0x1d10800, 0x01d11000
Hello,
I'm working on OMAPL138 EVM board, with the U-BOOT.
I'm trying to access and write into the register (which have write bits),
but I always read 0 in all the map space of the mcBSP0 and mcBSP1.
(0x01d1 - 0x1d10800, 0x01d11000 - 0x1d11800).
I wonder what I missed here. any ideas are welco
Dear Scott Wood,
In message <20110214174607.2b56d...@schlenkerla.am.freescale.net> you wrote:
>
> The 'next' branch is old, since I haven't pushed anything to it yet this
> cycle. Base it on Wolfgang's 'next'.
I don't have a "next" yet. I will create it when -rc2 is out.
Best regards,
Wolfga
Dear Marcel Janssen,
> Hi Remy and Reinhard,
>
>> To make it easy for you: It is up to you if you choose '
>> rework_110202'
...
> It looks like if at91sam9g45.h has not been updated. Is that right ?
> If so, should all be changed to ATMEL_ID and ATMEL_BASE ?
That is correct. Only 9260/1/3 are re
On Mon, 14 Feb 2011 16:48:01 +0100
Florian Fainelli wrote:
> From: Florian Fainelli
>
> This patch adds support for reading an ONFI page parameter from a NAND
> device supporting it. If this is the case, struct nand_chip onfi_version
> member contains the supported ONFI version, 0 otherwise.
>
Wolfgang,
> Please be careful in the use of terms. It appears you are using
> "relocating" when you actually mean "copying". Keep in mind that
> these are two very different operations.
I understand. Sorry for the confusion.
> Note that there is no guarantee that such an approach will continue
Dear Tim Kryger,
In message you wrote:
>
> My memory map is fixed but my board specific U-Boot code is still under
> development and if I can't guarantee the address U-Boot is loaded will be
> exactly the same as the computed address I am in trouble. If it changes ever
> so
> slightly, I could
Albert,
Thank you for your advice.
> Note that even if you can compute the address, you would save a copy,
> but you would still need to go through the relocation code, which takes
> a while too.
This is a really good point and I need investigate how much time could really be
saved by avoidin
Wolfgang,
Thanks for the prompt reply.
> > Since this computation attempts to back off from the end of RAM the
> > resulting
> > address varies when U-Boot changes size. On my board I have an earlier
>
> It varies not only then. It may also vary when you are for example
> using features like p
This fixes cases like this one, there hush used to return 0 :
=> if foo ; then do something ; exit 1 ; fi ; echo RC=$?
Unknown command 'foo' - try 'help'
RC=1
Adapted from Barebox commit 2477fb1
From: Sascha Hauer
Date: Tue, 23 Mar 2010 15:33:43 +0100
Signed-off-by: Wolf
Running empty lists causes wrong return status
Adapted from Barebox commit 4596d2b
Author: Sascha Hauer
Date: Thu Sep 17 11:11:51 2009 +0200
Signed-off-by: Wolfgang Denk
---
common/hush.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/common/hush.c b/common/hu
Dear Tim Kryger,
In message you wrote:
>
> After looking at code, searching the mailing list archive, and reviewing the
> git
> commit log, I now understand that for ARM relocation is performed unless
> U-Boot
> is already running at its final destination as computed within board_init_f.
> Si
Hi Tim,
Le 14/02/2011 18:01, Tim Kryger a écrit :
> Hello,
>
> After looking at code, searching the mailing list archive, and reviewing the
> git
> commit log, I now understand that for ARM relocation is performed unless
> U-Boot
> is already running at its final destination as computed within b
I cloned the latest u-boot.git,
set my tool chain prefix to m68k-uclinux-
set the config to M5235EVB
and ran make all.
The below shows the results. Later, I changed to the makefile to use -m5307
instead of -mcpu= and the make chokes on the assembly keyword %RAMBAR1. I
changed this to %RAMBAR, a
Hello,
After looking at code, searching the mailing list archive, and reviewing the git
commit log, I now understand that for ARM relocation is performed unless U-Boot
is already running at its final destination as computed within board_init_f.
Since this computation attempts to back off from the
Marcel,
On Sun, Feb 13, 2011 at 12:08 PM, Anton Staaf wrote:
> Hi Marcel,
> I think your best bet right now is to use the nvflash tool provided in
> the Chromium chroot. That's what the burn-u-boot script uses (by the way,
> that script recently changed to write_tegra_bios (I know, bad name)
From: Andreas Gaeer
Davinci_emac driver uses EMAC channel 0 for communication, so it should
also teardown EMAC channel 0 in davinci_eth_ch_teardown instead of 1.
Signed-off-by: Andreas Gaeer
---
drivers/net/davinci_emac.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --gi
From: Florian Fainelli
This patch adds support for reading an ONFI page parameter from a NAND
device supporting it. If this is the case, struct nand_chip onfi_version
member contains the supported ONFI version, 0 otherwise.
This allows NAND drivers past nand_scan_ident to set the best timings fo
Dear Madhavi Manchala,
In message you
wrote:
>
> I have a J-Link JTAG and J-LinkGDBServer software tool for debugging
> the code which are purchased from segger.com. The board consists of
> Samsung S3C2510A MCU, Flash memory, SD RAM and UARTS. Here, my work is
> to load the OS image (like OpenWR
On 02/14/2011 01:08 PM, RONETIX - Asen Dimov wrote:
> Hello,
>
Hi,
> Have anybody made the nand support for mpc5125, especially commads for
> flashing first stage boot loader and U-Boot:
> nand_e, nand_w and nand_loader, which are implemented in
> /fscale/cys/git-freescale/u-boot-2009.03/drivers
Hello,
Have anybody made the nand support for mpc5125, especially commads for
flashing first stage boot loader and U-Boot:
nand_e, nand_w and nand_loader, which are implemented in
/fscale/cys/git-freescale/u-boot-2009.03/drivers/mtd/nand/mpc5125_nfc_mtc.c.
The BSP from Freescale has these command
Le 14/02/2011 00:38, Michael Schwingen a écrit :
> Am 02/13/2011 11:03 PM, schrieb Wolfgang Denk:
>> Dear Graeme Russ,
>>
>> In message
>> you wrote:
>>> For multi-patch series, you only need to put the revision history in the
>>> [00/nn] file - No need to individually annotate each and every pat
Removed clearing of L2 cache as SRAM as it is not necessary without ECC.
This also speeds up the booting process.
Signed-off-by: Fabian Cenedese
Cc: Kumar Gala
---
arch/powerpc/cpu/mpc85xx/cpu_init_nand.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/powerp
Hi David,
Le 14/02/2011 11:59, Schade, David a écrit :
>> I got trouble with U-Boot, which "forget" configuration in the gd->bd
>> ->bi_dram[0].start and .size.
>> At first I used the branch git://arago-project.org/git/projects/u-boot-
>> omap3.git;protocol=git with revision
>> 7683ca6af43c17cf
Hello again,
Now we are using the angstrom-2008.1.conf file of OpenEmbedded, which includes:
ANGSTROM_GCC_VERSION ?= "4.3.3"
The U-Boot compiled by this GCC without any source changes (with volatile)
works perfect, we got
DRAM: 256 MB
## Booting kernel from Legac
On Mon, Feb 14, 2011 at 2:16 PM, Wolfgang Denk wrote:
> Dear Madhavi Manchala,
>
> In message you
> wrote:
>>
>> Actually, I want to load the "u-boot" file into SDRAM area and run
>> from the SD RAM only instead of FLASH area. Here, the RAM address
>> starts from 0x in our board. I tried
Le 14/02/2011 10:05, Andre Schwarz a écrit :
> Wolfgang,
>
>
>
>>> Have I missed anything ?
>>> Is there a way to get automagically merged whatever there might be to
>>> merge ?
>> Sorry, I have no idea what happenend of your system. I can see no
>> issues on our side.
>
> thank - will clone
Wolfgang,
>> Have I missed anything ?
>> Is there a way to get automagically merged whatever there might be to
>> merge ?
> Sorry, I have no idea what happenend of your system. I can see no
> issues on our side.
thank - will clone a new repo an pull in my local branches.
--
Regards,
A
Dear Madhavi Manchala,
In message you
wrote:
>
> Actually, I want to load the "u-boot" file into SDRAM area and run
> from the SD RAM only instead of FLASH area. Here, the RAM address
> starts from 0x in our board. I tried to modify some of the
> macros like PHYS_SDRAM_1 and its size. Ho
29 matches
Mail list logo
