Fix some issues introduced from commit:
2f70c49e5b9813635ad73666aa30f304c7fdeda9
suggested by Mike Frysinger.
- added some comment for the env_id variable in common_cmd_nvedit.c
- moved some variables in fn scope instead of file scope
- NetInitLoop now static void
Signed-off-by: Heiko Schocher
-
Hi
2009/4/27 alfred steele :
> 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
>
2009/4/28 Wolfgang Denk :
> Dear Marco,
>
> In message <49e61f99.50...@gmail.com> you wrote:
>> From: Marco Stornelli
>>
>> This patch adds, under tools folder, a new command called imls. Its
>> goal is the same of UBoot's imls but it can be used as Linux shell
>> command. It reads from raw mtd pa
From: Wolfgang Denk
Get rid of these warnings:
cmd_ext2.c:247: warning: format '%ld' expects type 'long int', but argument 2
has type 'int'
cmd_ext2.c:248: warning: format '%lX' expects type 'long unsigned int', but
argument 3 has type 'int'
Signed-off-by: Wolfgang Denk
---
common/cmd_ext2.
Dear Stefan Roese,
In message <200904280827.45894...@denx.de> you wrote:
>
> > Into drivers/mtd? Even if it's not a MTD driver? This doesn't make
> > mnuch sense to me.
>
> In the end this driver will be used by the common FLASH user interface
> (cmd_flash.c, cmd_mem.c). So I prefer to have th
Hi Wolfgang,
On Tuesday 28 April 2009, Wolfgang Denk wrote:
> > I took a quick look at the flash "driver". The main functions
> > lpc24xx_flash_erase() and lpc24xx_write_buff() are not even referenced
> > somewhere in this patch. They seem to be used in the 2nd patch (2/2)
> > though. It's hard to
Dear Peter,
In message <1240876395.11057.126.ca...@localhost.localdomain> you wrote:
>
> The copies cc-ed to myself come through just fine as utf-8 fwiw. Does
> that imply the denx.de servers convert unicode messages to base64?
This is in the headers of your message:
Content-Type: text
Dear Stefan Roese,
2009/4/27 Stefan Roese
> 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
Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 09:41 Tue 14 Apr , Tom Rix wrote:
>
>> There is exiting support for red,yellow,green but no blue.
>> The main LED on the zoom2 is a blue LED.
>>
>> Signed-off-by: Tom Rix
>> ---
>>
> Applied to arm/next
>
> Best Regards,
> J.
>
Thanks.
I
On Monday 27 April 2009 19:53:15 Peter Tyser wrote:
> On Mon, 2009-04-27 at 19:41 -0400, Mike Frysinger wrote:
> > On Monday 27 April 2009 19:18:21 Wolfgang Denk wrote:
> > > In message Peter Tyser wrote:
> > > >
> > >
> > > ...
> > >
> > > Please do not post base64 encoded messages. Next time I
On Monday 27 April 2009 18:15:58 Wolfgang Denk wrote:
> In message Mike Frysinger 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.
> >
> > @@ -77,19 +78,55 @@ extern unsigned char environ
On Mon, 2009-04-27 at 19:41 -0400, Mike Frysinger wrote:
> On Monday 27 April 2009 19:18:21 Wolfgang Denk wrote:
> > In message Peter Tyser wrote:
> > >
> > ...
> >
> > Please do not post base64 encoded messages. Next time I will ignore
> > such patches.
>
> it's due to unicode yet again:
>
> >
On Monday 27 April 2009 19:18:21 Wolfgang Denk wrote:
> In message Peter Tyser wrote:
> >
> ...
>
> Please do not post base64 encoded messages. Next time I will ignore
> such patches.
it's due to unicode yet again:
> > bmp_logo.c: In function `main':
those ticks are probably the left & right u
Dear Mike Frysinger,
In message <200904271644.33760.vap...@gentoo.org> you wrote:
>
> that should be a follow up change, but the wrapper already exists today
> regardless of Ricardo's fixes. i dont think his changes should be held up
> to
> address that.
>
> that direction should probably cove
Dear Ricardo Ribalda Delgado,
In message you
wrote:
>
> > 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
Dear Heiko Schocher,
In message <49f57154.1030...@denx.de> you wrote:
> 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 |
Dear Ricardo Ribalda Delgado,
In message <1240816411-16585-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.
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> v3: s/Z
Dear Stefan Roese,
In message <200904270927.29232...@denx.de> you wrote:
>
> I took a quick look at the flash "driver". The main functions
> lpc24xx_flash_erase() and lpc24xx_write_buff() are not even referenced
> somewhere in this patch. They seem to be used in the 2nd patch (2/2) though.
> I
Dear Peter Tyser,
In message <1240606796-32127-1-git-send-email-pty...@xes-inc.com> you wrote:
> QWRkIGJhc2ljIGVycm9yIGhhbmRsaW5nIHRvIGZyZWFkKCkgZnVuY3Rpb24gY2FsbHMuICBUaGlz
> IHByZXZlbnRzCmNvbXBpbGlsYXRpb24gd2FybmluZ3Mgc3VjaCBhczoKCmJtcF9sb2dvLmM6IElu
> IGZ1bmN0aW9uIOKAmG1haW7igJk6CmJtcF9sb2dvLmM
Dear Peter Tyser,
In message <1240606786-32082-1-git-send-email-pty...@xes-inc.com> you wrote:
> VGhpcyBwcmV2ZW50cyB0aGUgY29tcGlsYXRpb24gd2FybmluZzoKCm5jYi5jOiBJbiBmdW5jdGlv
> biAnbWFpbic6Cm5jYi5jOjMyOiB3YXJuaW5nOiBpZ25vcmluZyByZXR1cm4gdmFsdWUgb2Yg4oCY
> d3JpdGXigJksIGRlY2xhcmVkIHdpdGgKYXR0cmlidXR
Dear Stefan Roese,
In message <1240597459-8969-1-git-send-email...@denx.de> you wrote:
> This patch removes the now unnecessary flash type parameter from the
> "ubi part" command. Currently the user has to define the type of flash
> he will be using UBI on. Example:
>
> => ubi part nor partition1
Dear Stefan Roese,
In message <1240581575-640-1-git-send-email...@denx.de> you wrote:
> With this patch the NAND and OneNAND devices are registered in the MTD
> subsystem and can then be referenced by the mtdcore code (e.g.
> get_mtd_device_nm()). This is needed for the new "ubi part" command
> sy
Dear Stefan Roese,
In message <1240581513-522-1-git-send-email...@denx.de> you wrote:
> This patch removes this compilation warning when CONFIG_MTD_PARTITIONS is
> defined:
>
> nand_base.c: In function 'nand_release':
> nand_base.c:2922: warning: implicit declaration of function
> 'del_mtd_parti
Dear Stefan Roese,
In message <1240581619-746-1-git-send-email...@denx.de> you wrote:
> This patch removes the now unnecessary flash type parameter from the
> "ubi part" command. Currently the user has to define the type of flash
> he will be using UBI on. Example:
>
> => ubi part nor partition1
Dear Detlev Zundel,
In message <1240485260-19297-1-git-send-email-...@denx.de> you wrote:
> As the common code also handles baudrate switching, which the board
> specific vct.c driver did not support, this is one of the rare
> occassions where deleting code actually adds a feature :)
>
> Signed-o
Dear Anatolij Gustschin,
In message <1240485443-16924-1-git-send-email-ag...@denx.de> you wrote:
> Fix bug in drawing long version/info strings:
> U-Boot version string like
> "U-Boot 2009.03-05647-g7c51e06 (Apr 23 2009 - 12:40:00) MPC83XX"
> is long and doesn't wrap around correctly while drawing
Dear Ladislav Michl,
In message <20090421002631.ga17...@localhost.localdomain> you wrote:
> On Thu, Mar 19, 2009 at 01:30:36PM +0100, Stefan Roese wrote:
> > Currently the mtdparts commands are included in the jffs2 command support.
> > This doesn't make sense anymore since other commands (e.g. UB
Dear Peter Tyser,
In message <1240244533-22653-1-git-send-email-pty...@xes-inc.com> you wrote:
> The output_data_short() and input_data_short() functions for the
> AmigaOneG3SE are unused and result in compiler warnings.
>
> Signed-off-by: Peter Tyser
> ---
> common/cmd_ide.c | 44 ---
Dear Peter Tyser,
In message <1240244500-22603-1-git-send-email-pty...@xes-inc.com> you wrote:
> Signed-off-by: Peter Tyser
> ---
> include/configs/AmigaOneG3SE.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engi
Dear Peter Tyser,
In message <1240243745-17102-1-git-send-email-pty...@xes-inc.com> you wrote:
> __asm__ follows gcc's documented syntax and is generally more common
> than __asm. This change is only asthetic and should not affect
> functionality.
>
> Signed-off-by: Peter Tyser
> ---
> board/M
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
> --
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 David Brownell,
In message <200904161955.48211.davi...@pacbell.net> you wrote:
> From: David Brownell
>
> Make the headers in the "mtdparts" command output line up
> with their columns ... strike the extra TAB character.
>
> Signed-off-by: David Brownell
Applied, thanks.
Best regards,
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
...
> #if defined(CONFIG_CMD_NET)
> print_eth(0);
> - printf ("ip_addr = %pI4\n", &bd->bi_ip_addr);
> + print
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
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
> ---
> include/sa1100.h |0
> 1 fil
Dear Marco,
In message <49e61f99.50...@gmail.com> you wrote:
> From: Marco Stornelli
>
> This patch adds, under tools folder, a new command called imls. Its
> goal is the same of UBoot's imls but it can be used as Linux shell
> command. It reads from raw mtd partition and prints the list of the
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/whe
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-of
Dear Stefan Roese,
In message <1239724238-18155-1-git-send-email...@denx.de> you wrote:
> From: Adrian Hunter
>
> UBIFS did not recovery in a situation in which it could
> have. The relevant function assumed there could not be
> more nodes in an eraseblock after a corrupted node, but
> in fact t
Dear Dave Liu,
In message <1239691055-8360-1-git-send-email-dave...@freescale.com> you wrote:
> From: Gao Guanhua
>
> The filelen should be signed type, not unsigned type.
> otherwise, The condition as below never take.
> if (filelen < 0)
>
> Signed-off-by: Gao Guanhua
> Signed-off-by: D
Wolfgang Denk wrote:
> 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
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
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 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 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 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 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 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 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 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 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 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 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
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
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,
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
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.
> > > > */
> > >
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
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
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
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
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
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 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
> 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.
___
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
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 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 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
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
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 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
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
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
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
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
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
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 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
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
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
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_
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
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
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
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
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, 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
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
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
> -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
>
>
> > ---
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: 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 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
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
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
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
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 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
1 - 100 of 142 matches
Mail list logo
