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)
>>
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 f
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 th
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
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 | 2
U-boot binary size increase made u-boot-spl copy only part
of u-boot from NAND to RAM, missing part of the relocation
data. Increase u-boot NAND size to match current build size
plus a bit of slack.
Signed-off-by: Albert Aribaud
---
include/configs/tx25.h |2 +-
1 files changed, 1 insertions
Hi Albert,
> -Original Message-
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Tuesday, November 02, 2010 12:02 PM
> To: V, Aneesh
> Cc: h...@denx.de; Alexander Holler; Darius Augulis; u-
> b...@lists.denx.de
> Subject: Re: arm: wrong Relocation and not cleared BSS
>
> Le
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 flags:0x mapping:000
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
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:a8000
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 perha
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
F
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 (nand_spl code)
Why is this relocation
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
> interfac
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 pa
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
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
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_B
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 relo
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, no
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:53, V, Aneesh a écrit :
> My .rel.dyn was not empty even before taking your fix.
>
> This is what puzzled me. When I dumped the ELF headers with 'objdump -h'
> ..rel.dyn seemed to have some content: Please see the diff of objdump's
> output before and after applying your patch.
>
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 th
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)
>
Hi,
On Tue, 02 Nov 2010 07:40:04 +0100
Stefano Babic 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,
> > "panel_
hi Heiko,
On Tue Nov 02, 2010 at 09:55:46AM +0100, Heiko Schocher wrote:
> 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
Dear Albert ARIBAUD,
> 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_BOO
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
proble
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. Wha
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 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
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 t
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
> t
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
> li
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
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 Stein
> ---
> arch/arm/include/asm/arch-at91/at91cap9.h| 12
> arch/arm/include/asm/arch-at91/at91sa
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_ST_STA
'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 addit
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
> > > acce
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
---
common/cmd_bdinfo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bdinfo.c b/com
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. Th
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
On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUD 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
>> image, it caus
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 alo
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
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 Stein
...
>> #define AT91_MATRIX_BASE 0xee00
> can we just use one naming scheme here? I
Hi,
2010/11/2 Anatolij Gustschin :
> 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
> s
Hi,
2010/11/2 Anatolij Gustschin :
> '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
On Tue, Nov 2, 2010 at 6:49 AM, Stefan Roese 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 you
wrote:
>
> > + if (dev->descriptor.idVendor == 0x930 &&
> > + dev->descriptor.idProduct == 0x6545 &&
> > + dev->parent->descriptor.idVendor == 0x424 &&
> > + dev->parent->descriptor.idProduct == 0x2514)
> > + wai
On Wed, Oct 27, 2010 at 10:32 AM, Paulraj, Sandeep 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 boa
line 64 and 65 in include/command.h
extern cmd_tbl_t __u_boot_cmd_start;
extern cmd_tbl_t __u_boot_cmd_end;
definition of cmd_tbl_t is just one line above these. Why "extern" is used?
Thanks,
struct cmd_tbl_s {
char*name; /* Command Name */
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 t
Hi Wolfgang,
2010/11/2 Wolfgang Denk :
> Dear Remy Bohmer,
>
> In message you
> wrote:
>>
>> > + if (dev->descriptor.idVendor == 0x930 &&
>> > + dev->descriptor.idProduct == 0x6545 &&
>> > + dev->parent->descriptor.idVendor == 0x424 &&
>> > + dev->parent->desc
Le 02/11/2010 14:08, Steve Sakoman a écrit :
> On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUD
> 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
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: An
On Tue, Nov 2, 2010 at 9:28 AM, Albert ARIBAUD wrote:
> Le 02/11/2010 14:08, Steve Sakoman a écrit :
>>
>> On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUD
>> 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
>
Albert ARIBAUD writes:
> Le 02/11/2010 14:08, Steve Sakoman a écrit :
>> On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUD
>> 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.
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_bdinf
Le 02/11/2010 18:00, Måns Rullgård a écrit :
> Albert ARIBAUD writes:
>
>> Le 02/11/2010 14:08, Steve Sakoman a écrit :
>>> On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUD
>>> 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 th
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
Dear Remy,
In message 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.
Sorry - we don;t have a USB protocol analyzer that does hi
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
Hi,
2010/11/2 Wolfgang Denk :
> Dear Remy,
>
> In message 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.
>
> Sorry - we don
Dear Remy Bohmer,
In message 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 domain, and while
I'm trying to explain the situation to you, I
From: Matt Waddel
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
arch/arm/include/asm/arch-a
From: Matt Waddel
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 to that one.
- Renamed
From: Matt Waddel
Fixed "pointer from integer without a cast" warnings in Vexpress.
Signed-off-by: Matt Waddel
---
board/armltd/vexpress/ca9x4_ct_vxp.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/board/armltd/vexpress/ca9x4_ct_vxp.c
b/board/armltd/vexpress
Hello Stefano Babic,
On Tue, Nov 2, 2010 at 4:40 AM, Stefano Babic 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 vision2, also?
Hello Stefano B,
On Tue, Nov 2, 2010 at 4:57 AM, Stefano Babic 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 text.
I'll submit
Hello Stefano B,
On Tue, Nov 2, 2010 at 5:05 AM, Stefano Babic 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 introduced co
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 st
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!
Shuy
From: Renato Frias
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
---
Changes for v2:
- Removed fix.id string
- Removed NBITS calculation from debug message
drivers/vide
From: Renato Frias
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
---
Changes for v2:
- Removed trail
From: Renato Frias
Adds arguments to the mx51_fb_init call.
Signed-off-by: Renato Frias
---
Changes for v2:
- Includes fix to vision2 (this commit) on the patch set
board/ttcontrol/vision2/vision2.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/ttc
> -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.
>
> -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
> Beagl
> > -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 s
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 Caviu
Dear Reinhard, Wolfgang,
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-
> boun...@lists.denx.de] On Behalf Of Reinhard Meyer
> Sent: Tuesday, November 02, 2010 3:04 PM
> To: Albert ARIBAUD
> Cc: u-boot@lists.denx.de; h...@denx.de
> Subject: Re: [U-Boot] [RFC] ar
84 matches
Mail list logo
