Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090417195540.ga9...@game.jcrosoft.org you wrote:
please pull
The following changes since commit 7ee38c044ca5041d3378d6507580ea4ec344af96:
David Brownell (1):
fix DaVinci NS16550_REG_SIZE regression
are available in the git
Blocks compressed with zlib are not handled correctly.
gunzip decompress blocks with the gzip header, but ubi blocks
dont have header.
---
fs/ubifs/ubifs.c | 43 ++-
fs/ubifs/ubifs.h |2 --
2 files changed, 42 insertions(+), 3 deletions(-)
diff --git
---
fs/ubifs/ubifs.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 0708d90..4dc315e 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -646,6 +646,8 @@ int ubifs_load(char *filename, u32 addr, u32 size)
ui =
Hello all
Sorry for the error in the numbers. There are just 2, not 9!
Regards
--
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
This patch includes support for the LPC2468 processor from NXP.
Signed-off-by: Remco Poelstra remco.poelstra+u-b...@duran-audio.com
---
A working board example will be submitted when this patch is found to be OK.
This patch is against latest git.
The previous problem with PUTx vs. writex is
Dear Remco Poelstra,
In message 49f1a92f.9070...@duran-audio.com you wrote:
This patch includes support for the LPC2468 processor from NXP.
Thanks.
Here a few comments:
--- a/cpu/arm720t/cpu.c
+++ b/cpu/arm720t/cpu.c
@@ -75,7 +75,7 @@ int cleanup_before_linux (void)
/* go to high
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
With this patch this type parameter is not needed anymore. The user can
now select the partition
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
syntax without the flash type parameter (nor|nand|onenand).
Signed-off-by: Stefan Roese
On Friday 24 April 2009, Ricardo Ribalda Delgado wrote:
Blocks compressed with zlib are not handled correctly.
gunzip decompress blocks with the gzip header, but ubi blocks
dont have header.
---
Again, Signed-off-by missing.
More comments below.
fs/ubifs/ubifs.c | 43
I'm referring to the palatte and bitmap structs.
thanks again,
Steve
Steven Zedeck wrote:
Hi,
It seems that UBoot needs two data structures to display a bitmap in the
framebuffer. Is there a utility that converts a Windows bitmap (BMP?) file
and creates the 2 data structures that I can
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!
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
---
v2: remove unused parts..
This series contains 2 specific updates:
- 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.
Thanks to Dirk Behme [dirk.be...@googlemail.com]
for converting a
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
---
If the memory used to copy the link_make is dirty the string wont
be ended with Zero, throwing out multiple memory bugs.
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
---
v2: better doc and remove duplicated memcpy
fs/ubifs/ubifs.c |1 +
1 files changed, 1 insertions(+), 0
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
On Friday 24 April 2009, 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!
Signed-off-by: Ricardo Ribalda
On Fri, Apr 24, 2009 at 02:57:52PM +0900, Kyungmin Park wrote:
Actually, I don't like the CONFIG_SYS_MONITOR_LEN approaches, now you
are consider the bad block at 1.
But we can also consider the bad block 2, if there two consecutive 2
bad block at block 1, 2, we should define the
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!
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
---
v3: return is not a
On Fri, Apr 24, 2009 at 04:00:19PM +0200, Stefan Roese 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
With this patch this type
Hi,
I am trying to debug u-boot using arm-elf-gdb on the PDK board. I have been
succesfully using this gdb to a great extent. However, when i try my
vanilla u-boot image with debug, i get a segfault.
$ arm-elf-gdb u-boot
GNU gdb 5.3 (eCosCentric)
Copyright 2002 Free Software Foundation, Inc.
GDB
On Thu, 16 Apr 2009 23:31:12 -0700
David Brownell davi...@pacbell.net wrote:
On Thursday 16 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 15:44 Sun 12 Apr , David Brownell wrote:
could you split it in more logical change please
I'll fragment it a bit more, ok. later.
On 11:07 Fri 24 Apr , alfred steele wrote:
Hi,
I am trying to debug u-boot using arm-elf-gdb on the PDK board. I have been
succesfully using this gdb to a great extent. However, when i try my
vanilla u-boot image with debug, i get a segfault.
which ICE do you use?
$ arm-elf-gdb u-boot
On 20:21 Fri 24 Apr , Sanjeev Premi wrote:
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.
I've
On 20:22 Fri 24 Apr , Sanjeev Premi wrote:
The function display_board_info() displays incorrect
silicon revision - based on the return value from
function get_cpu_rev().
This patch fixes the problem.
two comment on the omap3
first for the cp15 we have the get/set_cr API it will be nice
Sanjeev Premi wrote:
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
Dear Jean-Christophe,
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 20:21 Fri 24 Apr , Sanjeev Premi wrote:
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
Dear Steven Zedeck,
In message 23217700.p...@talk.nabble.com you wrote:
I'm referring to the palatte and bitmap structs.
thanks again,
Are you talking about the logo support? Noite that this is different
from plain bitmap support.
It seems that UBoot needs two data structures to display a
On Friday 24 April 2009, Scott Wood wrote:
On Fri, Apr 24, 2009 at 04:00:19PM +0200, Stefan Roese 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
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
With this patch this type parameter is not needed anymore. The user can
now select the partition
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090424164644.gc2...@game.jcrosoft.org you wrote:
On 20:22 Fri 24 Apr , Sanjeev Premi wrote:
The function display_board_info() displays incorrect
silicon revision - based on the return value from
function get_cpu_rev().
This patch
On Friday 24 April 2009, Hugo Villeneuve wrote:
I would suggest renaming (or adding) CONFIG_SOC_DM6446
to CONFIG_SOC_DM644x
The updated patchset I sent includes CONFIG_SOC_DM644X:
http://lists.denx.de/pipermail/u-boot/2009-April/051051.html
I decided to keep the X uppercase for consistency
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090424164422.gb2...@game.jcrosoft.org you wrote:
On 20:21 Fri 24 Apr , Sanjeev Premi wrote:
The board-types defined in struct omap3_sysinfo seem to be
unused. The function display_board_info() is passed
board type as an argument;
Dear Ben,
In message 20090403215728.930be8379...@gemini.denx.de I wrote:
Dear Ben,
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.
On 21:34 Fri 24 Apr , Wolfgang Denk wrote:
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090424164422.gb2...@game.jcrosoft.org you wrote:
On 20:21 Fri 24 Apr , Sanjeev Premi wrote:
The board-types defined in struct omap3_sysinfo seem to be
unused. The function
On 18:59 Fri 24 Apr , Dirk Behme wrote:
Dear Jean-Christophe,
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 20:21 Fri 24 Apr , Sanjeev Premi wrote:
The board-types defined in struct omap3_sysinfo seem to be
unused. The function display_board_info() is passed
board type as an argument;
On 18:49 Fri 24 Apr , Dirk Behme wrote:
Sanjeev Premi wrote:
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
Signed-off-by:
On 11:48 Fri 24 Apr , alfred steele wrote:
Thanks !
which ICE do you use?
I use the the BDI3000. Could there be something wrong with the
U-boot image or the way u-boot doing a partial u-boot initialization.
The fact is that it does not even show the entry point/reset vector
address
On Fri, 24 Apr 2009 06:50:45 +0200
Heiko Schocher h...@denx.de wrote:
if using CONFIG_BOOTCOUNT_LIMIT feature on a MPC8360 CPU
in the muram-data node, the reg entry needs to be updated.
This is done in fdt_fixup_muram(), but we should use
the compatible fsl,qe-muram-data for searching the
Wolfgang Denk,
Please pull a couple of fixes for 83xx:
The following changes since commit 7ee38c044ca5041d3378d6507580ea4ec344af96:
David Brownell (1):
fix DaVinci NS16550_REG_SIZE regression
are available in the git repository at:
git://git.denx.de/u-boot-mpc83xx.git master
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 will prevent to apply them. But please correct if I
overlooked anything or add what (patches? comments?) I missed.
1. OMAP3: Beagle: Set
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.
I only have a build environment for powerpc boards so it'd be much
appreciated if other architectures could do some basic
Many boards/controllers/drivers don't support an I2C slave interface,
however CONFIG_SYS_I2C_SLAVE is used in common code so provide a
default
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
common/cmd_eeprom.c|4
cpu/mpc8260/i2c.c |3 ---
The following changes were made, primarily to bring the Marvell i2c
driver in line with U-Boot's current I2C API:
- Made i2c_init() globally accessible
- Made i2c_read() and i2c_write() return an integer
- Updated i2c_init() calls to pass in CONFIG_SYS_I2C_SLAVE in the
offhand chance someone
Add standard CONFIG_SYS_I2C_SPEED define for the mpc7448hpc2 so that
it can use the common 'i2c speed' command. Note that the I2C controller
utilized by the mpc7448hpc2 has a fixed speed and cannot be changed
dynamically.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Add the i2c_init() function so that the tsi108_i2c.c driver fits
U-Boot's standard I2C API which is utilized by cmd_i2c.c
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
drivers/i2c/tsi108_i2c.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git
Dear Jean-Christophe,
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 18:49 Fri 24 Apr , Dirk Behme wrote:
Sanjeev Premi wrote:
The function display_board_info() displays incorrect
silicon revision - based on the return value from
function get_cpu_rev().
This patch fixes the problem.
Board Certified Medical Doctors in America
Lots of Physicians in specialties like Orthopedics, Surgery, Radiology,
Dermatology, Neurology, General Practice etc..
you can sort by many different fields like city, state or zip
Price for this week only = $392
* You will also get these at
This prevents the compilation warning:
ncb.c: In function 'main':
ncb.c:32: warning: ignoring return value of ‘write’, declared with
attribute warn_unused_result
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
tools/ncb.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff
Add basic error handling to fread() function calls. This prevents
compililation warnings such as:
bmp_logo.c: In function ‘main’:
bmp_logo.c:71: warning: ignoring return value of ‘fread’, declared with
attribute warn_unused_result
...
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090424200323.gd2...@game.jcrosoft.org you wrote:
What exactly do you mean by move the STD API?
In which way should the STD API be moved, and what exactly is the
STD API you are referring to?
extract of arm init function
#if
+#include status_led.h
+#endif
#include asm/io.h
#include asm/arch/mem.h
#include asm/arch/mux.h
@@ -78,7 +81,6 @@ int board_init (void)
#if defined(CONFIG_STATUS_LED) defined(STATUS_LED_BOOT)
status_led_set (STATUS_LED_BOOT, STATUS_LED_ON);
#endif
-
return 0;
}
On 12:33 Fri 24 Apr , David Brownell wrote:
On Friday 24 April 2009, Hugo Villeneuve wrote:
I would suggest renaming (or adding) CONFIG_SOC_DM6446
to CONFIG_SOC_DM644x
The updated patchset I sent includes CONFIG_SOC_DM644X:
On 13:57 Fri 24 Apr , Remco Poelstra wrote:
This patch includes support for the LPC2468 processor from NXP.
Signed-off-by: Remco Poelstra remco.poelstra+u-b...@duran-audio.com
---
A working board example will be submitted when this patch is found to be OK.
This patch is against latest
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090424213824.gd32...@game.jcrosoft.org you wrote:
...
[FULL QUOTE DELETED]
It makes no sense to quote the complete patch when you just want to
add one line of comment at the end!
+ . = ALIGN(4);
+ .rodata : {
Dear Jean-Christophe PLAGNIOL-VILLARD,
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 have the ack of Stefan
No, not really.
On Friday 24 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 12:33 Fri 24 Apr , David Brownell wrote:
(Note: that series of five patches goes with two
patches which seem not to have merged yet:
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series
Hi Wolfgang,
Wolfgang Denk wrote:
Dear Ben,
In message 20090403215728.930be8379...@gemini.denx.de I wrote:
Dear Ben,
In message 49a641e4.8000...@denx.de you wrote:
[PATCH v2] netloop: updates for NetLoop
Fix some issues introduced from commit:
Hi Wolfgang,
Wolfgang Denk wrote:
Dear Wolfgang Denk,
In message 20090403215440.d21298379...@gemini.denx.de I wrote:
Dear Ben,
In message 49a4d6bc.3010...@renesas.com Yoshihiro Shimoda wrote:
Fix the problem that cannot access actual data when CPU data cache enabled.
Detlev-san,
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)
Dear Jean-Christophe,
David Brownell wrote:
...
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next
I see that branch now exists ... thanks! :)
Could you clarify the current merge cycle for me, by the way?
I
Short status update after scanning the recent mails:
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 will prevent to apply them. But please correct if I
overlooked
61 matches
Mail list logo
