Le 02/11/2010 07:29, Heiko Schocher a écrit :
- preloader copies first page of nand (nand_spl code) to
0xbb00 (some cpu internal mem) and jumps to this address
- nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl code)
- from there, it copies u-boot code from nand to
On 11/02/2010 06:15 AM, Frias Renato-B13784 wrote:
This patch adds flexibility to mxc_ipuv3_fb.c by allowing the display
interface and pixel format to be passed to mx51_fb_init.
Signed-off-by: Renato Frias renato.fr...@freescale.com
Hi Renato,
you patch seems to be corrupted and does not
On 11/02/2010 06:16 AM, Frias Renato-B13784 wrote:
Adds video support to mx51evk board, this board allows different displays.
This patch enables the WVGA TFT LCD panel only, remove comments from
include/configs/mx51evk.h to use it.
This patch is corrupted as the first one by your mailer.
Hello Albert,
Albert ARIBAUD wrote:
Le 02/11/2010 07:29, Heiko Schocher a écrit :
- preloader copies first page of nand (nand_spl code) to
0xbb00 (some cpu internal mem) and jumps to this address
- nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl
code)
- from
Le 01/11/2010 23:11, Wolfgang Denk a écrit :
__got_start = .;
. = ALIGN(4);
.got : { *(.got) }
Do we still need this GOT entry?
Indeed no, and we do not need the datarel entries either. I'm reposting
a V2 patch set with these plus minor fixes to the arm926ejs linker file
Hello Albert,
Albert ARIBAUD wrote:
Le 01/11/2010 23:11, Wolfgang Denk a écrit :
__got_start = .;
. = ALIGN(4);
.got : { *(.got) }
Do we still need this GOT entry?
Indeed no, and we do not need the datarel entries either. I'm reposting
a V2 patch set with these plus minor
Le 02/11/2010 08:18, V, Aneesh a écrit :
Thanks. This helps. I did the .lds change and it seems to be booting
now.
Good!
However, I can't still explain my earlier observation because even in
the absence of this fix .rel.dyn had some content and the offsets
should have been different if I
Le 02/11/2010 08:37, sywang a écrit :
While U-boot loads the Linux image, I have the following error. Do you
have any suggestions on this?
detected lzma initramfs
initramfs: LZMA lc=3,lp=0,pb=2,dictSize=8388608,origSize=12677632
Bad page state in process 'swapper'
page:a87b3418
Le 02/11/2010 05:05, Steve Sakoman a écrit :
I've been using gcc 4.3.3, so I haven't run into the issue that this
patch is attempting to fix.
I tested this patch using gcc 4.3.3, and while it produces a usable
image, it causes the size of the image to grow from 227K to 433K!
So perhaps we
Albert,
Thanks for your reply. My log is shown below. What you say is right. The
error information is from Linux. I guess that what parameters passed to
Linux by u-boot may be not right. However, I don't know how to identify?
TFTP from server 192.168.5.101; our IP address is 192.168.5.22
Dear Stefano Babic,
In message 4ccfb244.2000...@denx.de you wrote:
Consider this, I do not think the actual computation in lcd_setmem() is
correct. We need to compute the maximum amount of memory to be reserved
to the framebuffer, not the value requested by the current display
interface. We
Dear sywang,
In message 20101102073757.0c5e828...@theia.denx.de you wrote:
While U-boot loads the Linux image, I have the following error. Do you
have any suggestions on this?
detected lzma initramfs
initramfs: LZMA lc=3,lp=0,pb=2,dictSize=8388608,origSize=12677632
Bad page state in
Dear sywang,
In message 20101102081321.0571d28...@theia.denx.de you wrote:
Image is not signed; verifying checksum... passed
do_tftpboot, Linux image has been verified: pass
do_tftpboot, going to do_bootoctlinux
octeon_phy_mem_block_free addr: 0x10, size: 0x800
ELF file is 64 bit
Albert,
-Original Message-
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Tuesday, November 02, 2010 1:11 PM
To: V, Aneesh
Cc: dar...@theia.denx.de; h...@denx.de; u-boot@lists.denx.de; Augulis
Subject: Re: arm: wrong Relocation and not cleared BSS
Le 02/11/2010 08:18,
Hello Wolfgang,
Wolfgang Denk wrote:
Dear Heiko Schocher,
In message 4ccfafe4.3000...@denx.de you wrote:
- preloader copies first page of nand (nand_spl code) to
0xbb00 (some cpu internal mem) and jumps to this address
- nand_spl does lowlevelinit, relocate itself to TEXT_BASE
Dear Heiko Schocher,
But there is a possibility to prevent one copy, if TEXT_BASE =
relocation address = CONFIG_SYS_NAND_U_BOOT_DST
In this case nand_spl code copies u-boot from nand to
CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address,
no need to copy code in
On 11/02/2010 09:35 AM, Wolfgang Denk wrote:
Dear Stefano Babic,
In message 4ccfb244.2000...@denx.de you wrote:
Consider this, I do not think the actual computation in lcd_setmem() is
correct. We need to compute the maximum amount of memory to be reserved
to the framebuffer, not the value
Hello all,
I am trying to get the ELF relocation working with the arm920t, and I
have applied the patch recently posted to the list by Andreas
Bießmann.
I found that adding these two sections to the linker script gets rid
of both assert failures:
.plt : { *(.plt) }
.rel.plt : {
Le 02/11/2010 09:57, Reinhard Meyer a écrit :
Dear Heiko Schocher,
But there is a possibility to prevent one copy, if TEXT_BASE =
relocation address = CONFIG_SYS_NAND_U_BOOT_DST
In this case nand_spl code copies u-boot from nand to
CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the
Hi Heiko,
On Tuesday 02 November 2010 09:55:46 Heiko Schocher wrote:
- preloader copies first page of nand (nand_spl code) to
0xbb00 (some cpu internal mem) and jumps to this address
- nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl
code)
Why is this
Hi,
On Tue, 02 Nov 2010 07:40:04 +0100
Stefano Babic sba...@denx.de wrote:
...
There is also a second issue where I would like to know your thoughts. Very
early on system initialization, when LCD is enabled, there is a call to
lcd_setmem from board.c. By that time, the video variables,
Dear Reinhard Meyer,
In message 4ccfd27e.3080...@emk-elektronik.de you wrote:
I would recommend that we add code to check for overlapping relocation into
board.c and print a panic message if an overlap is detected.
Why should we try to detect a problem when we can as well avoid the
problem?
Le 02/11/2010 10:34, Reinhard Meyer a écrit :
My original message was: please to not give people the idea that they can
avoid relocation by loading u-boot at the exact address the relocation would
calculate. That is bound to *really* break at the slightest change to u-boot.
Oh, I see. What
Dear Stefano Babic,
In message 4ccfd2fb.6060...@denx.de you wrote:
Why cannot you determine the exact amount needed at runtime?
Agree, we can do it, and it is better - I do not think we need really to
change dinamically (I mean, in the same u-boot session) the LCD
connected to the
Le 02/11/2010 10:38, Wolfgang Denk a écrit :
Dear Reinhard Meyer,
In message4ccfd27e.3080...@emk-elektronik.de you wrote:
I would recommend that we add code to check for overlapping relocation into
board.c and print a panic message if an overlap is detected.
Why should we try to detect a
On 11/02/2010 10:42 AM, Wolfgang Denk wrote:
Dear Stefano Babic,
Hi Wolfgang,
We could introduce a weak function, that a board maintainer can decide
to implement or not. This maintains the compatibility with the most
drivers where vpanel is static initialized.
In which way is this board
Leif,
I have managed to flashed a 36-bits u-boot to my p4080 board.
I have put in two 4Gb dimm into the board but it doesn't work.
I got the following from u-boot.
[snip]
DRAM: Initializing
Error: DDR_SDRAM_CFG[RD_EN] and DDR_SDRAM_CFG[2T_EN] should not be set at
the same
hi Albert,
On Tue Nov 02, 2010 at 10:47:49AM +0100, Albert ARIBAUD wrote:
Now a solution would be that the actual u-boot size be flashed along
with it, for instance as a literal defined as '.word _end - _start'
right after the vectors. The SPL could load a first NAND block, read the
Hello,
Am 02.11.2010 05:05, schrieb Steve Sakoman:
I've been using gcc 4.3.3, so I haven't run into the issue that this
patch is attempting to fix.
just to correct this, the problem is a change in binutils and not, as I
wrongly assumed earlier, gcc. Using ld from binutils 2.20.1 leads to
Checking the status field of the qTD token in the current code
do not take into acount cases where endpoint stall (halted) bit
is set together with XactErr status bit. As a result clearing
stall on an endpoint won't be done if this status bit was also
set. Check for halted bit and report
'usb start' command often fails with Toshiba USB stick 0x930/0x6545
connected to the SMSC USB 2.0 hub 0x424/0x2514. Debugging the
issue showed that while bulk IN transfers with length of 13 or
18 the status field of the qTD token sometimes indicates trans-
action error (XactErr) and sometimes
Hi Wolfgang,
On Monday 01 November 2010 20:06:31 Wolfgang Denk wrote:
I'm a bit biased here - from standard Unix command usage it seems
natural that you have to manually umount first, but then we have very
smple device handling in U-Boot, with always only one device in
access. Would
There was a prototype change from do_bdinfo(.. char *) to do_bdinfo(.. char *
const). This patch respect this change for AVR32 architecture.
Signed-off-by: Andreas Bießmann biessm...@corscience.de
---
common/cmd_bdinfo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
Le 02/11/2010 10:56, Sughosh Ganu a écrit :
hi Albert,
On Tue Nov 02, 2010 at 10:47:49AM +0100, Albert ARIBAUD wrote:
Now a solution would be that the actual u-boot size be flashed along
with it, for instance as a literal defined as '.word _end - _start'
right after the vectors. The SPL
On Tue Nov 02, 2010 at 12:16:55PM +0100, Albert ARIBAUD wrote:
Le 02/11/2010 10:56, Sughosh Ganu a écrit :
hi Albert,
On Tue Nov 02, 2010 at 10:47:49AM +0100, Albert ARIBAUD wrote:
Now a solution would be that the actual u-boot size be flashed along
with it, for instance as a literal
On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUD albert.arib...@free.fr wrote:
Le 02/11/2010 05:05, Steve Sakoman a écrit :
I've been using gcc 4.3.3, so I haven't run into the issue that this
patch is attempting to fix.
I tested this patch using gcc 4.3.3, and while it produces a usable
Dear Albert ARIBAUD,
In message 4ccfde45.3060...@free.fr you wrote:
These is a valid point that the SPL isn't necessarily rebuilt and
flashed every time u-boot itself is built and flashed, so whatever
constant the SPL would carry would only be valid for the u-boot that was
built
Dear Stefano Babic,
In message 4ccfdeba.2070...@denx.de you wrote:
We could introduce a weak function, that a board maintainer can decide
to implement or not. This maintains the compatibility with the most
drivers where vpanel is static initialized.
In which way is this board
Reinhard Meyer schrieb:
Dear All concerned,
On Monday 01 November 2010, 11:57:14 Andreas Bießmann wrote:
Am 01.11.2010 um 09:29 schrieb Alexander Stein:
Signed-off-by: Alexander Steinalexander.st...@systec-electronic.com
...
#define AT91_MATRIX_BASE 0xee00
can we just use one naming
Hi,
2010/11/2 Anatolij Gustschin ag...@denx.de:
Checking the status field of the qTD token in the current code
do not take into acount cases where endpoint stall (halted) bit
is set together with XactErr status bit. As a result clearing
stall on an endpoint won't be done if this status bit
Hi,
2010/11/2 Anatolij Gustschin ag...@denx.de:
'usb start' command often fails with Toshiba USB stick 0x930/0x6545
connected to the SMSC USB 2.0 hub 0x424/0x2514. Debugging the
issue showed that while bulk IN transfers with length of 13 or
18 the status field of the qTD token sometimes
On Tue, Nov 2, 2010 at 6:49 AM, Stefan Roese s...@denx.de wrote:
Hi Wolfgang,
On Monday 01 November 2010 20:06:31 Wolfgang Denk wrote:
I'm a bit biased here - from standard Unix command usage it seems
natural that you have to manually umount first, but then we have very
smple device
Dear Remy Bohmer,
In message aanlktikqeftb=xeav1g6xyvoy3hw3imcpifild0kv...@mail.gmail.com you
wrote:
+ if (dev-descriptor.idVendor == 0x930
+ dev-descriptor.idProduct == 0x6545
+ dev-parent-descriptor.idVendor == 0x424
+
On Wed, Oct 27, 2010 at 10:32 AM, Paulraj, Sandeep s-paul...@ti.com wrote:
On Wed, 2010-10-27 at 17:11 +0200, Wolfgang Denk wrote:
Dear Paulraj, Sandeep,
In message 0554bef07d437848af01b9c9b5f0bc5da9d89...@dlee01.ent.ti.com
you wrote:
Test this patch on my beagle board, works
On 11/02/2010 02:34 PM, Wolfgang Denk wrote:
Because each board uses a different LCD with a different resolution, and
this requires a different amount of memory. This is not different as we
see in Linux, because the framebuffer properties are set in the board
file before to be passed to the
Hi Wolfgang,
2010/11/2 Wolfgang Denk w...@denx.de:
Dear Remy Bohmer,
In message aanlktikqeftb=xeav1g6xyvoy3hw3imcpifild0kv...@mail.gmail.com you
wrote:
+ if (dev-descriptor.idVendor == 0x930
+ dev-descriptor.idProduct == 0x6545
+
Le 02/11/2010 14:08, Steve Sakoman a écrit :
On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUDalbert.arib...@free.fr
wrote:
Le 02/11/2010 05:05, Steve Sakoman a écrit :
I've been using gcc 4.3.3, so I haven't run into the issue that this
patch is attempting to fix.
I tested this patch
Dear Andreas Bießmann,
Your e-Mail is:
Content-Transfer-Encoding: quoted-printable
That means ' ' comes as =20, '=' comes as =3D
There was a prototype change from do_bdinfo(.. char *) to do_bdinfo(.. char *
const). This patch respect this change for AVR32 architecture.
Signed-off-by:
On Tue, Nov 2, 2010 at 9:28 AM, Albert ARIBAUD albert.arib...@free.fr wrote:
Le 02/11/2010 14:08, Steve Sakoman a écrit :
On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUDalbert.arib...@free.fr
wrote:
Le 02/11/2010 05:05, Steve Sakoman a écrit :
I've been using gcc 4.3.3, so I haven't run
Albert ARIBAUD albert.arib...@free.fr writes:
Le 02/11/2010 14:08, Steve Sakoman a écrit :
On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUDalbert.arib...@free.fr
wrote:
Le 02/11/2010 05:05, Steve Sakoman a écrit :
I've been using gcc 4.3.3, so I haven't run into the issue that this
patch
Dear Reinhard Meyer,
Am 02.11.2010 um 17:34 schrieb Reinhard Meyer:
Dear Andreas Bießmann,
Your e-Mail is:
Content-Transfer-Encoding: quoted-printable
That means ' ' comes as =20, '=' comes as =3D
grr .. I wonder which part of the chain it was, will fix that.
I see that cmd_bdinfo.c
Le 02/11/2010 18:00, Måns Rullgård a écrit :
Albert ARIBAUDalbert.arib...@free.fr writes:
Le 02/11/2010 14:08, Steve Sakoman a écrit :
On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUDalbert.arib...@free.fr
wrote:
Le 02/11/2010 05:05, Steve Sakoman a écrit :
I've been using gcc 4.3.3, so
Dear Stefano Babic,
In message 4cd035f7.9070...@denx.de you wrote:
And then the calculation depends only on the current setting - which
is _not_ board dependent.
Yes, calculation is not board dependent and must remain in lcd_setmem().
What I meant as board dependent is really the LCD
Dear Remy,
In message aanlktimtzosbtobm_og304gbrcpcm1wjet0xqo+mg...@mail.gmail.com you
wrote:
I have no idea what has been done, and has not been done. I have not
been debugging this issue. I have no idea if a USB protocol analyser
has shown something weird or something we could work on.
Dear Reinhard Meyer,
In message 4cd03d9c.6070...@emk-elektronik.de you wrote:
I see that cmd_bdinfo.c has lots of coding style violations, but
some architectures have them fixed.
Could we at least fix them in the AVR32 part, if we touch it anyway?
See the BLACKFIN example ;)
Or is it OK
Hi,
2010/11/2 Wolfgang Denk w...@denx.de:
Dear Remy,
In message aanlktimtzosbtobm_og304gbrcpcm1wjet0xqo+mg...@mail.gmail.com you
wrote:
I have no idea what has been done, and has not been done. I have not
been debugging this issue. I have no idea if a USB protocol analyser
has shown
Dear Remy Bohmer,
In message aanlktik0bxxfe8d5+96gy_=+cu0h_fkeyutfyo=cr...@mail.gmail.com you
wrote:
As U-boot project-owner you know you have the last word in this.
This is a pretty precious resource that should be used wisely, and not
without real need. This topic is clearly in your
From: Matt Waddel matt.wad...@linaro.org
These patches fix several build errors and warnings. A successful build for
this platform depends on Steve Sakoman's ARMV7: Fix build for non-OMAP3
boards patch.
Matt Waddel (2):
ARMV7: Vexpress build errors
ARMV7: Vexpress compile warnings
From: Matt Waddel matt.wad...@linaro.org
This patch fixes build errors in the vexpress system:
- syslib.c requires sys_proto.h file, used the example from /arch-mx5/.
- The linker script was missing required sections. Found the default
armv7 linker script can be used by vexpress. Switched
From: Matt Waddel matt.wad...@linaro.org
Fixed pointer from integer without a cast warnings in Vexpress.
Signed-off-by: Matt Waddel matt.wad...@linaro.org
---
board/armltd/vexpress/ca9x4_ct_vxp.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git
Hello Stefano Babic,
On Tue, Nov 2, 2010 at 4:40 AM, Stefano Babic sba...@denx.de wrote:
However, it is really better to make the modification for the vision2
inside the same patchset. This guarantees that both boards work when
your patches go to mainline.
Ok! Should I send the patch for
Hello Stefano B,
On Tue, Nov 2, 2010 at 4:57 AM, Stefano Babic sba...@denx.de wrote:
you patch seems to be corrupted and does not apply. It seems your mailer
is responsible for this. It puts html code in the mail, too:
Shame on me! I apologize for the mess, I configured Outlook for plain
Hello Stefano B,
On Tue, Nov 2, 2010 at 5:05 AM, Stefano Babic sba...@denx.de wrote:
This patch is corrupted as the first one by your mailer.
I'm really sorry, I'll submit again.
It seems you start with trailing whitespaces instead of tabs
I will fix on the next patch.
With the vision2 I
Dear Darius,
I noticed that you’re also working on porting u-boot to FriendlyARM's
mini6410. Can I know the status of porting? I met some problem, for
which I bleive lies in nand_spl relocation support, after rebased my
uboot patch for mini6410 to current u-boot master. Thank you very
much!
Best
Hi,
I found that vmalloc is not able to allocate the memory. What parameters
from u-boot are not right?
Thanks!
Shuyou
-Original Message-
From: sywang [mailto:syw...@dongniannetworks.com]
Sent: 2010年11月2日 16:13
To: 'Albert ARIBAUD'
Cc: 'u-boot@lists.denx.de'
Subject: RE: Bad page
Hi Wolfgang,
Although the error is reported by Linux, I think that the linux is booted by
u-boot. Or the issue at least is the extension issue of u-boot.
I believe that there are guys who fixed my issues in our community. So send
the sos email. Thanks for your understanding.
Thanks!
From: Renato Frias renato.fr...@freescale.com
This patch adds flexibility to mxc_ipuv3_fb.c by allowing the display
interface and pixel format to be passed to mx51_fb_init.
Signed-off-by: Renato Frias renato.fr...@freescale.com
---
Changes for v2:
- Removed fix.id string
-
From: Renato Frias renato.fr...@freescale.com
Adds video support to mx51evk board, this board allows different displays.
This patch enables the WVGA TFT LCD panel only, on Display interface 1.
Remove comments from include/configs/mx51evk.h to use it.
Signed-off-by: Renato Frias
From: Renato Frias renato.fr...@freescale.com
Adds arguments to the mx51_fb_init call.
Signed-off-by: Renato Frias renato.fr...@freescale.com
---
Changes for v2:
- Includes fix to vision2 (this commit) on the patch set
board/ttcontrol/vision2/vision2.c |4 ++--
1 files changed, 2
-Original Message-
From: Premi, Sanjeev
Sent: Friday, October 29, 2010 9:35 PM
To: u-boot@lists.denx.de
Cc: Premi, Sanjeev
Subject: [RFCv2 0/3] Add support for quick boot
This series attempts to address specific feedback[1] from
Wolfgang Denk to my previous submission.
Since
-Original Message-
From: Premi, Sanjeev
Sent: Wednesday, October 20, 2010 4:21 PM
To: u-boot@lists.denx.de
Cc: Premi, Sanjeev
Subject: [PATCH] omap3evm: Fix mechanism to identify board revision
[snip]
Sandeep,
Pinging for status...
~sanjeev
-Original Message-
From: Premi, Sanjeev
Sent: Tuesday, October 19, 2010 4:00 PM
To: u-boot@lists.denx.de
Cc: Premi, Sanjeev
Subject: [PATCH] omap3evm: Support relocation
This patch adds relocation support for omap3evm.
Content of the patch is based on changes for
Beagleboard.
-Original Message-
From: Premi, Sanjeev
Sent: Tuesday, October 19, 2010 6:36 PM
To: u-boot@lists.denx.de
Cc: Premi, Sanjeev
Subject: [PATCH] omap3evm: Wrap function under CONFIG_USB_OMAP3
The function omap3_evm_need_extvbus() is required
only when USB support is
Le 03/11/2010 02:00, sywang a écrit :
Hi,
I found that vmalloc is not able to allocate the memory. What parameters
from u-boot are not right?
Hi Shuyou,
As Wolfgang said, we cannot tell because the code you're using as a
bootloader is not mainline u-boot, but a version modified by Cavium.
74 matches
Mail list logo
