Hi Jean
Thanks for your review feedback
Pls see my in lined comments
-Original Message-
From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com]
Sent: Monday, April 27, 2009 4:06 AM
To: Prafulla Wadaskar
Cc: u-boot@lists.denx.de; Ashish Karkare; Ronen Shitrit;
On Friday 24 April 2009 10:36:05 Ricardo Ribalda Delgado wrote:
If the memory used to copy the link_make is dirty the string wont
be ended with Zero, throwing out multiple memory bugs.
use NULL or NUL, not Zero. same goes for subject.
+ link_name[ui-data_len]='\0';
need spaces
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 be a
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
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 ricardo.riba...@uam.es
---
v3: s/ZERO/NULL/, s/=/ = /
v2: better doc and remove duplicated memcpy
fs/ubifs/ubifs.c |1 +
1 files
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 the
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 other flash and need to
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 found
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 ricardo.riba...@uam.es
Acked-by: Stefan Roese s...@denx.de
Thanks.
Best
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 do
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 s...@denx.de wrote:
On Monday 27 April 2009, Mike Frysinger wrote:
Who is in charge of the lib_generic stuff?
if
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 straight
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
appreciated
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 ricardo.riba...@uam.es
---
lib_generic/gunzip.c | 27 ---
1 files changed, 20 insertions(+), 7 deletions(-)
diff
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
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 so we
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 h...@denx.de
---
board/ids8247/ids8247.c | 92 +
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 Denk
Dear Ricardo,
In message aa76a2be0904270234y4635b4dbj7de80cac751a2...@mail.gmail.com 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
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: Blocks
Dear Ricardo Ribalda Delgado,
In message aa76a2be0904270317h531e626bn4be3423963aa...@mail.gmail.com 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
Dear Ricardo Ribalda Delgado,
In message aa76a2be0904270234y4635b4dbj7de80cac751a2...@mail.gmail.com 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
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/2 hasn't
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 ricardo.riba...@uam.es
---
fs/ubifs/ubifs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/ubifs/ubifs.c
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
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 ricardo.riba...@uam.es
---
v3: rename patch 2- patch 3
v2: remove unused parts..
fs/ubifs/ubifs.c |7 +--
fs/ubifs/ubifs.h
Dear Ricardo Ribalda Delgado,
In message aa76a2be0904270333j75bc9489p74071622499db...@mail.gmail.com 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
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-off-by:
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-compression.
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
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.
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
-
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 pr...@ti.com
---
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 pr...@ti.com
---
cpu/arm_cortexa8/cpu.c |4 ++--
cpu/arm_cortexa8/omap3/clock.c |5
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
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
positively packed (1)
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
Linux process
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
several
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't
On Apr 24, 2009, at 9:11 AM, Joakim Tjernlund wrote:
Scott Wood scottw...@freescale.com 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
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
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 values - if
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 which
Dear Jean-Christophe,
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 17:29 Tue 21 Apr , Dirk Behme wrote:
From: Manikandan Pillai mani.pil...@ti.com
Signed-off-by: Dirk Behme dirk.be...@googlemail.com
Signed-off-by: Manikandan Pillai mani.pil...@ti.com
---
as Request precedently switch to
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 OMAP3EVM
with
-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 contains 3
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 it
-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
-Original
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 specific
On Monday 27 April 2009, Wolfgang Denk wrote:
#include ubifs.h
+#include u-boot/zlib.h
#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 zunzip(void
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
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 pr...@ti.com
---
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 ricardo.riba...@uam.es
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 this
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 Dirk
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:
Mike
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 ricardo.riba...@uam.es
---
v3: link_make - link_name
fs/ubifs/ubifs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff
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
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 ricardo.riba...@uam.es
---
v3: Move the prototype to the header file
fs/ubifs/ubifs.c |5 +++--
fs/ubifs/ubifs.h |3 ++-
2
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
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
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
code (i.e.
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 correct and we
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. Anything
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 the
Dear Detlev,
In message m2hc0aqetd@ohwell.denx.de 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
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 alfred.jaq...@gmail.com:
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
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
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.
*/
static int
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 assertion.
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_SIZE
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 plagn...@jcrosoft.com
The Subject: indicates a mere formal change (a rename of a function
name), but the patch actually does other
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 pending OMAP3
Dear Ben,
In message 49d68311.4090...@gmail.com you wrote:
Wolfgang Denk wrote:
Dear Ben,
In message gijdmd$vh...@ger.gmane.org 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
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_nvedit.c
-
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 vap...@gentoo.org
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 shimoda.yoshih...@renesas.com
---
drivers/net/rtl8169.c | 11 ++-
1 files changed, 10
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 the
Dear Marco,
In message 49e2236f.1050...@gmail.com you wrote:
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
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 \
+
Dear David Brownell,
In message 200904162315.15209.davi...@pacbell.net you wrote:
From: David Brownell dbrown...@users.sourceforge.net
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
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 dbrown...@users.sourceforge.net
Minor cleanup to clock-related defines for DaVinci DM6446 boards:
-
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 dbrown...@users.sourceforge.net
Chips without the EMAC controller won't need the utilities
it
Dear Dave Liu,
In message 1239691055-8360-1-git-send-email-dave...@freescale.com you wrote:
From: Gao Guanhua b22...@freescale.com
The filelen should be signed type, not unsigned type.
otherwise, The condition as below never take.
if (filelen 0)
Signed-off-by: Gao Guanhua
Dear Stefan Roese,
In message 1239724281-18241-1-git-send-email...@denx.de you wrote:
--===0864082046==
I missed removing this file while implementing the UBIFS support. It's
not referenced at all, so let's remove it. Thanks to Artem Bityutskiy
for spotting.
Signed-off-by:
Dear Peter Tyser,
In message 1239749550.24099.147.ca...@localhost.localdomain you wrote:
...
#1 is ugly in that 99.99% of the time an empty os_support.c file is
processed.
#2 is ugly in that the Makefile method to determine a target OS is
somewhat hokey and will only get hokier if/when
Dear Shinya Kuribayashi,
In message 49e68f07.5050...@necel.com you wrote:
sa1100.h is not used anywhere, then remove it.
$ find . -name '*.h' -empty -print
./include/sa1100.h
$ git grep 'sa1100.h' .
$
Signed-off-by: Shinya Kuribayashi shinya.kuribaya...@necel.com
---
include/sa1100.h
Hi Wolfgang,
#1 is ugly in that 99.99% of the time an empty os_support.c file is
processed.
#2 is ugly in that the Makefile method to determine a target OS is
somewhat hokey and will only get hokier if/when additional OS targets
are supported.
I'd vote for #1 as I think the
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 1238927618-15438-2-git-send-email-plagn...@jcrosoft.com you wrote:
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
...
#if defined(CONFIG_CMD_NET)
print_eth(0);
- printf (ip_addr = %pI4\n, bd-bi_ip_addr);
Dear David Brownell,
In message 200904161955.48211.davi...@pacbell.net you wrote:
From: David Brownell dbrown...@users.sourceforge.net
Make the headers in the mtdparts command output line up
with their columns ... strike the extra TAB character.
Signed-off-by: David Brownell
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090417060137.go31...@game.jcrosoft.org you wrote:
On 19:59 Mon 06 Apr , Minkyu Kang wrote:
CONFIG_S3C6400 is must defined at config header file
That definition is unnecessary at this file
Signed-off-by: Minkyu Kang
Dear Peter Tyser,
In message 1240243726-17065-1-git-send-email-pty...@xes-inc.com you wrote:
__attribute__ follows gcc's documented syntax and is generally more
common than __attribute. This change is only asthetic and should not
affect functionality.
Signed-off-by: Peter Tyser
1 - 100 of 122 matches
Mail list logo
