On Friday 24 April 2009 10:36:06 Ricardo Ribalda Delgado wrote:
> Blocks compressed with zlib dont have the full gzip header.
>
> This patch adds a new function to properly handle blocks compressed
> with zlib.
>
> Without this patch, block compressed with zlib cannot be readed!
this really should
Hello Mike:
Who is in charge of the lib_generic stuff?
Meanwhile there is no such a function I will leave it as an extra
function. This must be solved ASAP, it is a simply bug that avoid many
fs to be mounted properly.
Best regards
On Mon, Apr 27, 2009 at 08:59, Mike Frysinger wrote:
> On Fri
If the memory used to copy the link_make is "dirty" the string wont
be ended with NULL, throwing out multiple memory bugs.
Signed-off-by: Ricardo Ribalda Delgado
---
v3: s/ZERO/NULL/, s/=/ = /
v2: better doc and remove duplicated memcpy
fs/ubifs/ubifs.c |1 +
1 files changed, 1 insertions(+
> When i do a memtest without any args, it crashes after printing the
> first line.
> => mtest
> Pattern Writing...
> After reboot, when i do and md for the base address 0x0, i get the
> following, which proabbly is the uboot image itself in RAM.
Not exactly. At address 0 you have t
On Saturday 25 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > In message <20090424215804.gc10...@game.jcrosoft.org> you wrote:
> >
> > ...
> >
> > > > +#define COPY_BUFFER_LOCATION 0x4000fde0
> > >
> > > evenif it's soc specific flash support I think they need to be store
> > > with the ot
On Monday 27 April 2009 03:06:26 Ricardo Ribalda Delgado wrote:
fix your top posting. which is to say dont.
> Who is in charge of the lib_generic stuff?
if there is no one specified in the MAINTAINERS file, then Wolfgang maintains
it all. just send it to the u-boot list and someone will pick
On Friday 24 April 2009, Po-Yu Chuang wrote:
> I have a board on which there is a NOR Flash SST39LF040.
>
> Previously, I copied flash.c from other boards.
>
> Now I am trying to migrate NOR Flash driver to use CFI, but it fails
> to program sectors which
> are not on the 0x1 boundaries.
>
> I
On Monday 27 April 2009, Mike Frysinger wrote:
> > Who is in charge of the lib_generic stuff?
>
> if there is no one specified in the MAINTAINERS file, then Wolfgang
> maintains it all. just send it to the u-boot list and someone will pick it
> up.
Yes, Wolfgang is ion charge for all this stuff.
On Monday 27 April 2009, Ricardo Ribalda Delgado wrote:
> If the memory used to copy the link_make is "dirty" the string wont
> be ended with NULL, throwing out multiple memory bugs.
>
> Signed-off-by: Ricardo Ribalda Delgado
Acked-by: Stefan Roese
Thanks.
Best regards,
Stefan
===
Hi Kazuaki Ichinohe,
On Monday 27 April 2009, Kazuaki Ichinohe wrote:
> I sent the SATA patch mail on April 17.
> However, the following content is not confirmed, and there is not a reply
> either. Could you confirm it?
> I re-send the SATA driver patch.
Sorry, I forgot about reviewing it. I'll d
Hello
I am creating a new function (zunzip). Where this function should be
placed. In zlib.c or in gunzip.c?
Best regards
On Mon, Apr 27, 2009 at 09:36, Stefan Roese wrote:
> On Monday 27 April 2009, Mike Frysinger wrote:
>> > Who is in charge of the lib_generic stuff?
>>
>> if there is
On Monday 27 April 2009 03:48:15 Ricardo Ribalda Delgado wrote:
> Hello
you're still top posting. please fix the e-mail composer.
> I am creating a new function (zunzip). Where this function should be
> placed. In zlib.c or in gunzip.c?
probably the latter since the former is more "code strai
Hello Peter,
Peter Tyser wrote:
> Hi Heiko,
> These 5 patches should clean up the compile issues that you noticed
> after application of the "[PATCH v2 0/7] Remove individual I2C commands
> and cleanup" series.
Thanks.
> I only have a build environment for powerpc boards so it'd be much
> apprec
Separate gunzip in
gunzip: Find the end of the header and call zunzip.
zunzip: Inflate gunzip block without header.
Signed-off-by: Ricardo Ribalda Delgado
---
lib_generic/gunzip.c | 27 ---
1 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/lib_generic/gun
Blocks compressed with zlib dont have the full gzip header.
Without this patch, block compressed with zlib cannot be readed!
Signed-off-by: Ricardo Ribalda Delgado
---
v3: Create generic function zunzip
v2: remove unused parts.
fs/ubifs/ubifs.c |7 +--
fs/ubifs/ubifs.h |2 --
2 fil
Hello Wolfgang
UBI fs blocks can be compresed in lzo, zlib or no-compression. The
current implementation of u-boot supported all the compressions but
there was a bug in the implementation of zlib.
UBIFS's Zlib blocks do not have header but they were compressed using
gunzip, a function used to deco
Dear Ricardo Ribalda Delgado,
In message <1240823996-10418-1-git-send-email-ricardo.riba...@uam.es> you wrote:
> Separate gunzip in
>
> gunzip: Find the end of the header and call zunzip.
> zunzip: Inflate gunzip block without header.
What is the needed for? Maybe you should provide a use case s
because legacy NAND support is deprecated converting to current
NAND interface. !This just compile, because I have no more the
hardware to test it.
Signed-off-by: Heiko Schocher
---
board/ids8247/ids8247.c | 92 +
include/configs/IDS8247.h | 55 -
Hello
> Then please write this in the commit message of the patch.
It is already written in the ubifs patch (#2) Shall I also add this to
this patch (#1), that only touches the gunzip file?
Regards
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang De
Dear Ricardo,
In message you
wrote:
>
> UBI fs blocks can be compresed in lzo, zlib or no-compression. The
> current implementation of u-boot supported all the compressions but
> there was a bug in the implementation of zlib.
> UBIFS's Zlib blocks do not have header but they were compressed usi
Sorry for the mess.
There were 2 patch
1/2 ->: BUG realpath string must be ended with NULL" posting?
2/2 ->ubifs: BUG: Blocks commpressed with zlib"
Since 1/2 has been applied. And 2/2 needed to be separated in two patches
1/2 -> lib_generic: gunzip: New function zunzip
2/2 -> ubifs: BUG: Blo
Dear Ricardo Ribalda Delgado,
In message you
wrote:
>
>
> > Then please write this in the commit message of the patch.
>
> It is already written in the ubifs patch (#2) Shall I also add this to
> this patch (#1), that only touches the gunzip file?
How should anybody know why the gunzip file
Dear Ricardo Ribalda Delgado,
In message you
wrote:
>
> UBI fs blocks can be compresed in lzo, zlib or no-compression. The
> current implementation of u-boot supported all the compressions but
> there was a bug in the implementation of zlib.
> UBIFS's Zlib blocks do not have header but they wer
On Monday 27 April 2009, Ricardo Ribalda Delgado wrote:
> There were 2 patch
>
> 1/2 ->: BUG realpath string must be ended with NULL" posting?
>
> 2/2 ->ubifs: BUG: Blocks commpressed with zlib"
>
> Since 1/2 has been applied. And 2/2 needed to be separated in two patches
Just to clarify: Patch 1/
If the memory used to copy the link_make is "dirty" the string wont
be ended with NULL, throwing out multiple memory bugs.
Signed-off-by: Ricardo Ribalda Delgado
---
fs/ubifs/ubifs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
inde
Separate gunzip in
gunzip: Find the end of the header and call zunzip.
zunzip: Inflate gunzip block without header.
UBI fs blocks can be compresed in lzo, zlib or no-compression. The
current implementation of u-boot supported all the compressions but
there was a bug in the implementation of the z
Blocks compressed with zlib dont have the full gzip header.
Without this patch, block compressed with zlib cannot be readed!
Signed-off-by: Ricardo Ribalda Delgado
---
v3: rename patch 2-> patch 3
v2: remove unused parts..
fs/ubifs/ubifs.c |7 +--
fs/ubifs/ubifs.h |2 --
2 files cha
Dear Ricardo Ribalda Delgado,
In message you
wrote:
> Sorry for the mess.
>
>
> There were 2 patch
>
> 1/2 ->: BUG realpath string must be ended with NULL" posting?
>
> 2/2 ->ubifs: BUG: Blocks commpressed with zlib"
>
> Since 1/2 has been applied. And 2/2 needed to be separated in two patc
Hi Wolfgang
>
> In such a situation it would have been much better if you has reposted
> a new patch series consisting of 3 parts (1/3, 2/3 and 3/3).
Just sent a new patch series consisting 3 parts.
Sorry for the top posting...
--
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
Dear Ricardo Ribalda Delgado,
In message <1240831297-15862-1-git-send-email-ricardo.riba...@uam.es> you wrote:
> If the memory used to copy the link_make is "dirty" the string wont
> be ended with NULL, throwing out multiple memory bugs.
What is "link_make" ? Do you mean "link_name" ?
> Signed-o
Dear Ricardo Ribalda Delgado,
In message <1240831297-15862-2-git-send-email-ricardo.riba...@uam.es> you wrote:
> Separate gunzip in
>
> gunzip: Find the end of the header and call zunzip.
> zunzip: Inflate gunzip block without header.
>
> UBI fs blocks can be compresed in lzo, zlib or no-compres
Dear Ricardo Ribalda Delgado,
In message <1240831297-15862-3-git-send-email-ricardo.riba...@uam.es> you wrote:
> Blocks compressed with zlib dont have the full gzip header.
>
> Without this patch, block compressed with zlib cannot be readed!
>
> Signed-off-by: Ricardo Ribalda Delgado
...
> #in
This series contains 3 specific updates:
- Use common API to print cpu and board
related information.
- Remove unused board type definitions.
- Print correct silicon revision in the
board information
These updates have been tested on OMAP3EVM
with ES 3.0 and ES3.1 silicon versions.
Thank
Use the functions print_cpuinfo() and checkboard() to
display the cpu and board specific information.
These functions reuse content from the existing function
display_board_info() - which has been removed.
Also, updated the existig OMAP3 configurations to
define:
- CONFIG_DISPLAY_CPUINFO
- CONF
The board-types defined in struct omap3_sysinfo seem to be
unused. The function display_board_info() is passed
board type as an argument; which is ignored.
This patch removes all uses of board-type, related definitions
and functions.
Signed-off-by: Sanjeev Premi
---
board/omap3/beagle/beagle.h
The function display_board_info() displays incorrect
silicon revision - based on the return value from
function get_cpu_rev().
This patch fixes the problem.
Signed-off-by: Sanjeev Premi
---
cpu/arm_cortexa8/cpu.c |4 ++--
cpu/arm_cortexa8/omap3/clock.c |5 +++--
cpu/arm_
Hi,
In previous versions of U-Boot, there were options for writing JFFS2 file
systems to NAND (i.e., nand write.jffs2).
Is this command no longer supported in the latest U-Boot release or is the
command the same as the nand write command?
In other words, was there something special about the" n
Dear Shinya,
> Detlev Zundel wrote:
>> Instead of special casing the different access patterns, use common
>> code with light macros sprinkled in to accomodate for the different
>> layouts of the register structure.
>>
>> Note that this also changes the types of the registers for the
>> "positive
Wolfgang Denk wrote:
> Dear David Brownell,
>
> In message <200904250105.41050.davi...@pacbell.net> you wrote:
>> Yes. The issue is needing to guess what's up ... so for
>> example, I seem to observe that "merge window closed" must
>> not be the same as "first RC is out", which isn't how the
>> L
Hi experts,
I just wanted to do some testing on ethernet driver in Uboot. I have a
small program that will send a binary file through ethernet. But I don't
have any clue on how to receive those packets in U-boot. I mean what are
the API's to be used. It will be helpful if you could tell me how
Dear Jerry Van Baren,
In message <49f5b6af.5060...@ge.com> you wrote:
>
> > Maybe I pout a little more meaning in the words "release candiate".
> > After the end of a merge window, there is usually still a long
> > backlog of patches that has not been merged, and after that there are
> >
Dear "Muralitharan Perumal",
In message <49f5b80b.2090...@pace.com> you wrote:
>
> I just wanted to do some testing on ethernet driver in Uboot. I have a
You may want to look into the Ethenret related POST code in U-Boot.
> small program that will send a binary file through ethernet. But I don
On Apr 24, 2009, at 9:11 AM, Joakim Tjernlund wrote:
> Scott Wood wrote on 23/04/2009 18:40:01:
>>
>> On Thu, Apr 23, 2009 at 03:32:11PM +0200, Joakim Tjernlund wrote:
>>> Still trying to wrap my head around PCI and I wonder if I need to do
> some
>>> HW init in u-boot in order to use the PCI co
Detlev Zundel wrote:
> To be honest, I did not expect such problems, as I saw no hints from
> comments on why this code was needed. Thinking afresh, it now makes at
> least some sense why the code was. It nevertheless was inconsistent, as
> the word access was only done in an asymmetric way regar
On Sun, Apr 26, 2009 at 11:14:06PM -0400, Mike Frysinger wrote:
> On Tuesday 21 April 2009 07:13:10 Daniel Mack wrote:
> > On Wed, Apr 08, 2009 at 11:57:37PM -0400, Mike Frysinger wrote:
> > > > Not if the MAC is stored in the volatile smc911x registers. Issuing a
> > > > soft reset flushes these v
Short status update after recent merges and patch updates. As usual,
please correct if anything is wrong or missing.
Dirk Behme wrote:
>
> To avoid loosing the overview, here my list of pending OMAP3 patches
> ready to be applied. From my point of view there are no open comments on
> these wh
Dear Jean-Christophe,
Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 17:29 Tue 21 Apr , Dirk Behme wrote:
>> From: Manikandan Pillai
>> Signed-off-by: Dirk Behme
>> Signed-off-by: Manikandan Pillai
>> ---
> as Request precedently switch to 12Mhz source clock or
As answered already in (unansw
Hi Premi,
Sanjeev Premi wrote:
> This series contains 3 specific updates:
> - Use common API to print cpu and board
>related information.
> - Remove unused board type definitions.
> - Print correct silicon revision in the
>board information
>
> These updates have been tested on OMAP3EV
> -Original Message-
> From: Dirk Behme [mailto:dirk.be...@googlemail.com]
> Sent: Monday, April 27, 2009 8:47 PM
> To: Premi, Sanjeev
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates
>
> Hi Premi,
>
> Sanjeev Premi wrote:
> > This series co
Hi Alessandro,
Thanks!
> #define CONFIG_SYS_MEMTEST_START 0 /* memtest works on */
> #define CONFIG_SYS_MEMTEST_END 0x1
So, is the config file wrong?
> So, most likely memtest without arguments has never been used on the
> board.
Is it the cause for the hang, then? I thought
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev
> Sent: Monday, April 27, 2009 8:49 PM
> To: Dirk Behme
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates
>
>
> > ---
Hello Shinya,
> Detlev Zundel wrote:
>> To be honest, I did not expect such problems, as I saw no hints from
>> comments on why this code was needed. Thinking afresh, it now makes at
>> least some sense why the code was. It nevertheless was inconsistent, as
>> the word access was only done in an
Premi, Sanjeev wrote:
>> -Original Message-
>> From: u-boot-boun...@lists.denx.de
>> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev
>> Sent: Monday, April 27, 2009 8:49 PM
>> To: Dirk Behme
>> Cc: u-boot@lists.denx.de
>> Subject: Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board s
On Monday 27 April 2009, Wolfgang Denk wrote:
> > #include "ubifs.h"
> > +#include
> >
> > #if !defined(CONFIG_SYS_64BIT_VSPRINTF)
> > #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output!
> > @@ -33,15 +34,17 @@ DECLARE_GLOBAL_DATA_PTR;
> >
> > /* compress.c */
> >
> > +int zun
Hi Wolfgang,
>> And if we want to make it perfect, each -rc could get a similar
>> announcement, too.
>
> Would ne not just add a lot of noise to the ML, without any real new
> information?
>
> If you want detailed information about each action, please feel free
> and register a RSS feed on the g
On Monday 27 April 2009 10:44:16 Daniel Mack wrote:
> On Sun, Apr 26, 2009 at 11:14:06PM -0400, Mike Frysinger wrote:
> > On Tuesday 21 April 2009 07:13:10 Daniel Mack wrote:
> > > On Wed, Apr 08, 2009 at 11:57:37PM -0400, Mike Frysinger wrote:
> > > > > Not if the MAC is stored in the volatile smc
This series contains 3 specific updates:
- Use common API to print cpu and board
related information.
- Remove unused board type definitions.
- Print correct silicon revision in the
board information.
This series fixes the compile warning
pointed by Dirk Behme.
These updates have been te
Use the functions print_cpuinfo() and checkboard() to
display the cpu and board specific information.
These functions reuse content from the existing function
display_board_info() - which has been removed.
Also, updated the existig OMAP3 configurations to
define:
- CONFIG_DISPLAY_CPUINFO
- CONF
The board-types defined in struct omap3_sysinfo seem to be
unused. The function display_board_info() is passed
board type as an argument; which is ignored.
This patch removes all uses of board-type, related definitions
and functions.
Signed-off-by: Sanjeev Premi
---
board/omap3/beagle/beagle.h
The function display_board_info() displays incorrect
silicon revision - based on the return value from
function get_cpu_rev().
This patch fixes the problem.
Signed-off-by: Sanjeev Premi
---
cpu/arm_cortexa8/cpu.c |4 ++--
cpu/arm_cortexa8/omap3/clock.c |5 +++--
cpu/arm_
On Monday 27 April 2009 08:36:55 Wolfgang Denk wrote:
> In message Ricardo Ribalda Delgado wrote:
> > Blocks compressed with zlib dont have the full gzip header.
> >
> > Without this patch, block compressed with zlib cannot be readed!
> >
> > Signed-off-by: Ricardo Ribalda Delgado
> >
> > - * We n
On Monday 27 April 2009 08:59:11 cmfai...@rockwellcollins.com wrote:
> In previous versions of U-Boot, there were options for writing JFFS2 file
> systems to NAND (i.e., nand write.jffs2).
the name was a misnomer. it didnt do anything jffs2 specific, it just handled
bad block detection.
> Is th
Hello Shinya,
>> If there's no good alternatives, I think reverting is a good idea
>> because there must be other platforms affected by this change.
I just checked again - the "problematic" cases can only be REG_SIZE 2
and 4:
[...@pollux u-boot-testing (master)]$ grep CONFIG_SYS_NS16550_REG_SIZE
Sanjeev Premi wrote:
> This series contains 3 specific updates:
> - Use common API to print cpu and board
>related information.
> - Remove unused board type definitions.
> - Print correct silicon revision in the
>board information.
>
> This series fixes the compile warning
> pointed by
Hello Wolfgang
>
> If the only purpose of zunzip() is to be used here, then why do we not
> make the parameters fit the intended purpose, thus avoiding an
> additional wrapper?
The purpose of zunzip is to use it in more places. Like Mike Frysinger said:
this really should be a common function
If the memory used to copy the link_name is "dirty" the string wont
be ended with NULL, throwing out multiple memory bugs.
Signed-off-by: Ricardo Ribalda Delgado
---
v3: link_make -> link_name
fs/ubifs/ubifs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/ubifs/ubi
Separate gunzip in
gunzip: Find the end of the header and call zunzip.
zunzip: Inflate gunzip block without header.
UBI fs blocks can be compresed in lzo, zlib or no-compression. The
current implementation of u-boot supported all the compressions but
there was a bug in the implementation of the z
Blocks compressed with zlib dont have the full gzip header.
Without this patch, block compressed with zlib cannot be readed!
Signed-off-by: Ricardo Ribalda Delgado
---
v3: Move the prototype to the header file
fs/ubifs/ubifs.c |5 +++--
fs/ubifs/ubifs.h |3 ++-
2 files changed, 5 inser
Mike Frysinger wrote:
> On Monday 27 April 2009 08:59:11 cmfai...@rockwellcollins.com wrote:
>> In previous versions of U-Boot, there were options for writing JFFS2 file
>> systems to NAND (i.e., nand write.jffs2).
>
> the name was a misnomer. it didnt do anything jffs2 specific, it just
> handl
Hi Alfred,
--- On Mon, 4/27/09, alfred steele wrote:
> Please let me know how were able to sucessfully load the
> kernel. My
> bootup sequence too hangs after "Uncompressing
> kernel...done booting
> the kernel".
Since MX31PDK is not in mainline U-boot yet, I am wondering which version are
yo
Hello,
My M5271EVB based board connects the SMI of the FEC PHY to an external entity
and not to the SMI controller of the CPU.
The MII bus is still connected between the CPU and the FEC PHY. The phy is then
bootstrapped to be [100BaseT FullDuplex No AutoNeg].
I wanted to use something similar t
Hi All,
I have a u-boot version for Davinci 6446 and would like to access r/w the
u-boot environment from linux userpace.
I set the /etc/fw_env.config to /dev/mtd0 0
0x4000 0x200
When I execute fw_printenv, I got these error:
Warning: Bad CRC, using default environment
But
On Mon, Apr 27, 2009 at 12:51:29AM +0200, Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> In message <20090426224036.gl32...@game.jcrosoft.org> you wrote:
> > On 11:11 Sun 26 Apr , David Brownell wrote:
> > > I was looking at the DaVinci NAND support in current U-Boot
> > > c
On Mon, Apr 27, 2009 at 11:56:17AM -0400, Mike Frysinger wrote:
> On Monday 27 April 2009 10:44:16 Daniel Mack wrote:
> > On Sun, Apr 26, 2009 at 11:14:06PM -0400, Mike Frysinger wrote:
> > > usually what i suggest to people are things like:
> > > - pass $(ethaddr) via kernel command line and pars
On Monday 27 April 2009 14:32:09 Philip Balister wrote:
> Mike Frysinger wrote:
> > On Monday 27 April 2009 08:59:11 cmfai...@rockwellcollins.com wrote:
> >> This message contains PRIVILEGED AND PROPRIETARY INFORMATION intended
> >
> > please fix your e-mail system so that this bogus crap is not in
On Thursday 23 April 2009 04:01:14 Ladislav Michl wrote:
> On Thu, Apr 23, 2009 at 12:18:00AM +0200, Wolfgang Denk wrote:
> > In message Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > Who needs this, and why and when, and why didn't we need it the past?
> > >
> > > a lot of actual timer are not co
> I think the first step would be to get MX31PDK into mainline U-boot. Are you
> willing to help on that?
Of course, as long as i have it up and running and tested on my
hardware. But in order to do that, i would need your help in answering
my earlier question.
Thanks for your help!
-Alfred.
___
Dear Dirk Behme,
In message <49f5d1b5.8070...@googlemail.com> you wrote:
>
> > Should I re-submit the whole series?
> > OR
> > Is it okay to re-send just the last one.
>
> I'm not a custodian, but last one marked with 'v4' should be
> sufficient from my point of view.
ACK, this is sufficient. A
On Wednesday 22 April 2009 16:49:36 Jean-Christophe PLAGNIOL-VILLARD wrote:
> For all Timer modification a minimun of qualification is mandatory
> as it will impact a lots of part of u-boot.
>
> So for this purpose I'll propose you to use one of this two approche
> to report
Dear Detlev,
In message you wrote:
>
> >> And if we want to make it perfect, each -rc could get a similar
> >> announcement, too.
> >
> > Would ne not just add a lot of noise to the ML, without any real new
> > information?
> >
> > If you want detailed information about each action, please feel
Dear Mike Frysinger,
In message <200904271200.39319.vap...@gentoo.org> you wrote:
>
> > > - * We need a wrapper for gunzip() because the parameters are
> > > + * We need a wrapper for zunzip() because the parameters are
> > > * incompatible with the lzo decompressor.
> > > */
> > > static int
On Monday 27 April 2009, Scott Wood wrote:
> It is for compatibility with a widely-deployed legacy ECC layout -- more
> details can be found in the list archives.
See my original query, which IMO disproves that assertion.
What this option enables differs in two ways from what the
MontaVista code
Hi
2009/4/27 alfred steele :
>> I think the first step would be to get MX31PDK into mainline U-boot. Are you
>> willing to help on that?
> Of course, as long as i have it up and running and tested on my
> hardware. But in order to do that, i would need your help in answering
> my earlier question
David Brownell wrote:
> On Monday 27 April 2009, Scott Wood wrote:
>> It is for compatibility with a widely-deployed legacy ECC layout -- more
>> details can be found in the list archives.
>
> See my original query, which IMO disproves that assertion.
The entire mess was presented as being for co
On Monday 27 April 2009 15:46:25 Wolfgang Denk wrote:
> In message Mike Frysinger wrote:
> > > > - * We need a wrapper for gunzip() because the parameters are
> > > > + * We need a wrapper for zunzip() because the parameters are
> > > > * incompatible with the lzo decompressor.
> > > > */
> > >
Dear Magnus,
Thanks for the reply!
> And we need to know which U-boot patches you're using to boot the PDK
> board.
I am using the internal git tree code supplied to me by freescale. The
tarball is called "uboot-imx-imx_v2009.01.tar.gz". I can boot uboot
out of NAND successfully using that as the
Wolfgang,
Yes, I do see what U-boot is doing. I looked at bmp_logo.c and its output.
It seems that the color palette entries are all 16 bits (unsigned short).
For my application, I have 24 bit color, which expects each pixel to be 32
bits, of which only 24 bits are used. So the palette, I assume,
On Monday 27 April 2009, Scott Wood wrote:
> David Brownell wrote:
> > On Monday 27 April 2009, Scott Wood wrote:
> >> It is for compatibility with a widely-deployed legacy ECC layout -- more
> >> details can be found in the list archives.
> >
> > See my original query, which IMO disproves that as
Dear Kim Phillips,
In message <20090424152306.aac80f94.kim.phill...@freescale.com> you wrote:
> Wolfgang Denk,
>
> Please pull a couple of fixes for 83xx:
>
> The following changes since commit 7ee38c044ca5041d3378d6507580ea4ec344af96:
> David Brownell (1):
> fix DaVinci NS16550_REG_SI
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message <1240047101-6787-1-git-send-email-plagn...@jcrosoft.com> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
The Subject: indicates a mere formal change (a rename of a function
name), but the patch actually does other things as well:
..
Dear Dirk,
In message <49f5c746.6040...@googlemail.com> you wrote:
>
> Short status update after recent merges and patch updates. As usual,
> please correct if anything is wrong or missing.
Thanks for the summary.
> Dirk Behme wrote:
> >
> > To avoid loosing the overview, here my list of pend
Dear Ben,
In message <49d68311.4090...@gmail.com> you wrote:
> Wolfgang Denk wrote:
> > Dear Ben,
> >
> > In message Stefan Althoefer wrote:
> >
> >> Hi,
> >>
> >> I found that IXP425 (big endian ARM) did not work with e1000 network
> >> driver. The reason is broken access to controller regist
Dear Heiko Schocher,
In message <49a641e4.8000...@denx.de> you wrote:
> [PATCH v2] netloop: updates for NetLoop
>
> Fix some issues introduced from commit:
> 2f70c49e5b9813635ad73666aa30f304c7fdeda9
> suggested by Mike Frysinger.
>
> - added some comment for the env_id variable in common_cmd_nve
Dear Mike Frysinger,
In message <1239015670-28314-1-git-send-email-vap...@gentoo.org> you wrote:
> The --binary option to envcrc can be used to export the embedded env as a
> binary blob so that it can be manipulated/examined/whatever externally.
>
> Signed-off-by: Mike Frysinger
> ---
> tools/
Dear Yoshihiro Shimoda,
In message <49a4d6bc.3010...@renesas.com> you wrote:
> Fix the problem that cannot access actual data when CPU data cache enabled.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> drivers/net/rtl8169.c | 11 ++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
Dear Ben,
In message <1239162275-13087-1-git-send-email-mani.pil...@ti.com> Manikandan
Pillai wrote:
> eth_halt() function in the smc911x drivers used to call the
> smc911x_reset() function. eth_halt() used to be called after
> tftp transfers. This used to put the ethernet chip in reset
> while t
Dear Marco,
In message <49e2236f.1050...@gmail.com> you wrote:
> Signed-off-by: Marco Stornelli
Sorry, your patch is corrupt because your mailer wrapped long lines:
...
> +all: $(BINS)
> +
> +$(obj)imls: $(obj)imls.o $(obj)crc32.o $(obj)image.o $(obj)md5.o \
> + $(obj)sha1.o $(LIBF
Dear David Brownell,
In message <200904162315.15209.davi...@pacbell.net> you wrote:
> From: David Brownell
>
> Make the U-Boot dm9000 driver read addresses from EEPROM just
> like Linux does ... read six bytes, instead of reading twelve
> bytes and then discarding every other one.
>
> Using the
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message <20090417053719.gi31...@game.jcrosoft.org> you wrote:
> On 15:40 Sun 12 Apr , David Brownell wrote:
> > From: David Brownell
> >
> > Minor cleanup to clock-related defines for DaVinci DM6446 boards:
> >
> > - CONFIG_SYS_CLK_FREQ is unused;
Dear Jean-Christophe,
In message <49ebf50a.6070...@gmail.com> Ben Warren wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 15:49 Sun 12 Apr , David Brownell wrote:
> >
> >> From: David Brownell
> >>
> >> Chips without the EMAC controller won't need the utilities
> >> it uses to read
1 - 100 of 142 matches
Mail list logo
