On 01/02/2013 17:44, Tomas Novotny wrote:
Signed-off-by: Tomas Novotny to...@novotny.cz
Cc: Tom Rini tr...@ti.com
Cc: Stefano Babic sba...@denx.de
---
The second patch in this series adds pinmux for the da830. This pinmux
is selected when CONFIG_SOC_DA850 is not set. Although ea20 has its
Hello Albert,
On 02.02.2013 18:02, Albert ARIBAUD wrote:
Refactor linker-generated array code so that symbols
which were previously linker-generated are now compiler-
generated. This causes relocation records of type
R_ARM_ABS32 to become R_ARM_RELATIVE, which makes
code which uses LGA able
Hi Sebastian,
On Mon, 4 Feb 2013 07:11:30 +, Priebe, Sebastian
sebastian.pri...@cadcon.de wrote:
Hello,
So it seems to be, that patch at least solves this issue.
Sebastian: can you check if this is resolved also resolved for your board
after applying
Hi Heiko,
On Mon, 04 Feb 2013 09:21:02 +0100, Heiko Schocher h...@denx.de wrote:
Hello Albert,
On 02.02.2013 18:02, Albert ARIBAUD wrote:
Refactor linker-generated array code so that symbols
which were previously linker-generated are now compiler-
generated. This causes relocation
Hi Gurucharan,
On Mon, 04 Feb 2013 11:25:35 +0530, Gurucharan Ch
guruchara...@uurmi.com wrote:
Hi Everyone,
I know how to initialise watchdog registers
and how to change delay using WLDR reg, but I'm not getting how to use
pre-scalar(i.e. WCLR reg), and one
Hello,
Did you try to 'apply --reject' the patch to 2012.10 and see how this goes?
This only adds a newline in command.c.
Regards,
Sebastian
==
CADCON
Ingenieurgesellschaft mbH Co. KG
Geschaeftsfuehrer: Robert Bauer, Andreas Gundel
Sitz der
Hi Mike and Tom,
please pull these sf changes to your tree.
Tom: I have sent private email to Mike but I haven't got any response
from him. Also I haven't got reactions on mailing list.
That's why I am not sure if Mike still cares about this subsystem.
If not, please let me know who is
Hi Tom,
please pull all these changes to your tree.
The major change is remove really ancient i2c driver + helper files
for this driver.
Thanks,
Michal
The following changes since commit 6ad77d88e57f6ab815ec7e85c5ac329054318c73:
Marek Vasut (1):
vfat: Fix mkcksum argument sizes
are
Hi Sebastian,
On Mon, 4 Feb 2013 11:28:26 +, Priebe, Sebastian
sebastian.pri...@cadcon.de wrote:
Hello,
Did you try to 'apply --reject' the patch to 2012.10 and see how this goes?
This only adds a newline in command.c.
Do you mean the only change you see at all is this new line
If the BMP headers are located in unaligned addresses, accessing them
directly may lead to a data abort on some architectures. Use the safer
bmp_layout API instead.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Anatolij Gustschin
Currently code that displays BMP files does two things:
* assume that any address is a valid load address for a BMP
* access in-memory BMP header fields directly
Since some BMP header fields are 32 bit wide, this has a potential
for causing data aborts when these fields are placed in unaligned
If the BMP headers are located in unaligned addresses, accessing them
directly may lead to a data abort on some architectures. Use the safer
bmp_layout API instead.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Anatolij Gustschin
If the BMP headers are located in unaligned addresses, accessing them
directly may lead to a data abort on some architectures. Use the safer
bmp_layout API instead.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Anatolij Gustschin
When configuring U-Boot to display a splash image, the user is free to
designate whatever address they see fit as the in-memory location of BMP
file. Unfortunately, this makes it easy to place the BMP header fields in
unaligned addresses, which will cause a data abort on architectures which
can't
If the BMP headers are located in unaligned addresses, accessing them
directly may lead to a data abort on some architectures. Use the safer
bmp_layout API instead.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Anatolij Gustschin
Hi Nikita,
On Mon, 4 Feb 2013 13:39:34 +0200, Nikita Kiryanov
nik...@compulab.co.il wrote:
When configuring U-Boot to display a splash image, the user is free to
designate whatever address they see fit as the in-memory location of BMP
file. Unfortunately, this makes it easy to place the BMP
Hi Albert,
On 02/04/2013 01:57 PM, Albert ARIBAUD wrote:
IIRC, you has submitted a fix so that BMP loads would result in
correctly aligned fields and thus no need for accessors. Why this
change of mind?
I did mention that I consider that fix as temporary. I believe this fix
is better
Hi Albert,
On 02.02.2013 18:02, Albert ARIBAUD wrote:
Refactor linker-generated array code so that symbols
which were previously linker-generated are now compiler-
generated. This causes relocation records of type
R_ARM_ABS32 to become R_ARM_RELATIVE, which makes
code which uses LGA able to
another observation from my weekend perusal of all of the
common/cmd_*.c files is that, despite its cmd_ filename prefix, the
source file cmd_disk.c doesn't define any actual u-boot commands.
according to what i see as u-boot filename naming conventions, it
shouldn't be named cmd_*,
Hi All,
I am trying to boot U-boot on Intel platform.. I want to clarify following
Questions, Please help to me..
1) If U-boot supports for Intel, then How can we create and flash U-boot
image on Intel host machine. and also what configuration file i can use?
2) i go through the U-boot source
Hi rajesh,
On Mon, 4 Feb 2013 04:30:16 -0800, rajesh n nrajesh.se...@gmail.com
wrote:
Hi All,
I am trying to boot U-boot on Intel platform.. I want to clarify following
Questions, Please help to me..
1) If U-boot supports for Intel, then How can we create and flash U-boot
image on Intel
Hi Nikita,
On Mon, 04 Feb 2013 14:37:06 +0200, Nikita Kiryanov
nik...@compulab.co.il wrote:
Hi Albert,
On 02/04/2013 01:57 PM, Albert ARIBAUD wrote:
IIRC, you has submitted a fix so that BMP loads would result in
correctly aligned fields and thus no need for accessors. Why this
From: Lokesh Vutla lokeshvu...@ti.com
Removing the duplicated code in ddr3 initialization.
Also creating structure for lpddr2 mode registers to
avoid unnessecary revision checks.
These change reduces code addition for future Socs.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by:
This series is intended to cleanup code which is duplicated
across soc specific files. This is accomplished by moving soc
specifc data to one place and having the code common. This
helps in avoiding un necessary cpu checks and minimal
code addition for future socs.
Tested this on OMAP5 ES1.0,
From: Lokesh Vutla lokeshvu...@ti.com
There is some code duplication in the ddr io settings code.
This is avoided by moving the data to a Soc specific place and
letting the code generic.
This avoids unnessecary code addition for future socs.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
From: Lokesh Vutla lokeshvu...@ti.com
Now SDRAM initialization is done on the basis of omap revision.
Instead this should be done on basis of SDRAM type read from
EMIF_SDRAM_CONFIG register. This will be helpful to avoid
unnessecary cpu checks for new boards
Signed-off-by: R Sricharan
The pmic code is duplicated for OMAP 4 and 5.
Instead move the data to Soc specific place and
share the code.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
[V2] Addressed Tom Rini's tr...@ti.com comments
From: Lokesh Vutla lokeshvu...@ti.com
A seperate omap_sys_ctrl_regs structure is defined for
omap4 5. If there is any change in control module for
any of the ES versions, a new structure needs to be created.
In order to remove this dependency, making the register
structure generic for all the
Hi Andreas,
On Mon, 04 Feb 2013 13:41:09 +0100, Andreas Bießmann
andreas.de...@googlemail.com wrote:
Hi Albert,
On 02.02.2013 18:02, Albert ARIBAUD wrote:
Refactor linker-generated array code so that symbols
which were previously linker-generated are now compiler-
generated. This
Hello,
Do you mean the only change you see at all is this new line addition? I
suspect there are other changes, which you missed, maybe because they apply
fine. What does a 'git status' produce?
We are using svn, not git. There are too many differences. I can't apply the
patch. There is no
Hi Robert,
On Mon, 04 Feb 2013 07:53:43 -0500, Robert P. J. Day
rpj...@crashcourse.ca wrote:
another observation from my weekend perusal of all of the
common/cmd_*.c files is that, despite its cmd_ filename prefix, the
source file cmd_disk.c doesn't define any actual u-boot commands.
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap5/hwinit.c | 13 +++--
arch/arm/include/asm/arch-omap5/omap.h |2 ++
arch/arm/include/asm/armv7.h |1 +
ES2.0 is the latest silicon revision for OMAP543X socs. The SOC
supports enhanced opps for MPU (up to 1.5GHz). This series essentially
adds the support for both 5430 and 5432 versions.
This is on top of the below U-Boot cleanup series.
PRCM register addresses are changed from ES1.0 to ES2.0 due to
PER power domain getting moved to CORE power domain.
So adding the nessecary register changes for the same.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap5/hw_data.c |5 +
From: Lokesh Vutla lokeshvu...@ti.com
After power-up SRCOMP cells are by-passed by default in OMAP5.
Software has to enable these SRCOMP sells.
For ES2: All 5 SRCOMP cells needs to be enabled.
For ES1: Only 4 SRCOMP cells in core power domain are enabled.
The 1 in wkup domain is not
From: Lokesh Vutla lokeshvu...@ti.com
Add pre calculated timing settings of LPDDR2 and DDR3 memories
present in OMAP5430 and OMAP5432 ES2.0 versions.
Also adding the DDR pad io settings required for
OMAP543X SOCs here.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla
Change OPP settings as per the latest 0.4 version of
addendum for OMAP5430 ES2.0
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |4 +
arch/arm/cpu/armv7/omap4/hw_data.c | 142
Hi Sebastian,
On Mon, 4 Feb 2013 14:23:17 +, Priebe, Sebastian
sebastian.pri...@cadcon.de wrote:
Hello,
Do you mean the only change you see at all is this new line addition? I
suspect there are other changes, which you missed, maybe because they apply
fine. What does a 'git
Enable DCC driver for arm zynq platform to be compiled.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
boards.cfg |1 +
include/configs/zynq.h |5 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/boards.cfg b/boards.cfg
index 98f7a14..1d30a18
The patch provides slcr base address initialization support
and a support to reset the cpu through slcr driver,
hence removed the reset_cpu() from board.c.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Do lowlevel initialization directly in C. Zynq do not
require to do it in asm.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
arch/arm/cpu/armv7/zynq/cpu.c | 26 +++-
arch/arm/include/asm/arch-zynq/hardware.h | 46 -
2 files
Quoting Albert ARIBAUD albert.u.b...@aribaud.net:
Hi Robert,
On Mon, 04 Feb 2013 07:53:43 -0500, Robert P. J. Day
rpj...@crashcourse.ca wrote:
another observation from my weekend perusal of all of the
common/cmd_*.c files is that, despite its cmd_ filename prefix, the
source file
On 02/04/2013 04:19 PM, Albert ARIBAUD wrote:
Hi Nikita,
On Mon, 04 Feb 2013 14:37:06 +0200, Nikita Kiryanov
nik...@compulab.co.il wrote:
Hi Albert,
On 02/04/2013 01:57 PM, Albert ARIBAUD wrote:
IIRC, you has submitted a fix so that BMP loads would result in
correctly aligned fields and
Hi Robert, Albert,
Robert P. J. Day wrote:
just to be clear, i have no strong opinion on this either way, but
my understanding is that source files with the name of common/cmd_*.c
typically define at least one u-boot command with the U_BOOT_CMD macro.
as far as i can tell, cmd_disk.c is
Hi Robert,
On Mon, 04 Feb 2013 10:04:20 -0500, Robert P. J. Day
rpj...@crashcourse.ca wrote:
Quoting Albert ARIBAUD albert.u.b...@aribaud.net:
Hi Robert,
On Mon, 04 Feb 2013 07:53:43 -0500, Robert P. J. Day
rpj...@crashcourse.ca wrote:
another observation from my weekend
On Mon, Feb 04, 2013 at 07:51:58PM +0530, R Sricharan wrote:
This series is intended to cleanup code which is duplicated
across soc specific files. This is accomplished by moving soc
specifc data to one place and having the code common. This
helps in avoiding un necessary cpu checks and
Hi Nikita,
On Mon, 04 Feb 2013 17:07:05 +0200, Nikita Kiryanov
nik...@compulab.co.il wrote:
On 02/04/2013 04:19 PM, Albert ARIBAUD wrote:
Hi Nikita,
On Mon, 04 Feb 2013 14:37:06 +0200, Nikita Kiryanov
nik...@compulab.co.il wrote:
Hi Albert,
On 02/04/2013 01:57 PM, Albert ARIBAUD
i know i mentioned it this weekend but the only reason i tripped
over that cmd_disk.c thingie is that i built myself a cmd_*.c
reference list, matching source files with defined commands and
any preprocessor conditions that defined them here:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/04/2013 09:22 AM, R Sricharan wrote:
The current PRCM structure prototype directly matches the hardware
register layout. So there is a need to change this for every new
silicon revision which has register space changes.
Avoiding this by
Hi Mats,
On Mon, 4 Feb 2013 15:17:17 +, Mats Kärrman
mats.karr...@tritech.se wrote:
Hi Robert, Albert,
Robert P. J. Day wrote:
just to be clear, i have no strong opinion on this either way, but
my understanding is that source files with the name of common/cmd_*.c
typically
Hello,
(maybe you should set your mailing tool to wrap at ~70 characters)
Apperently I can't. The mailing tool (MS Outlook) setting are restricted by my
companys IT.
I have no root rights on my windows machine. I develop only on my linux
machine.
If there is no linker_list.h, then the patch
Hi Albert,
Albert ARIBAUD wrote:
Maybe, but the problem you state is not about cmd_disk (or I am
missing the point). USB commands are in USB related files, e.g.
do_usbboot() is in cmd_usb.c, so that's where a conditional should be
put if you want to compile the command out, rather than in
On Mon, Feb 04, 2013 at 07:51:59PM +0530, R Sricharan wrote:
From: Lokesh Vutla lokeshvu...@ti.com
Now SDRAM initialization is done on the basis of omap revision.
Instead this should be done on basis of SDRAM type read from
EMIF_SDRAM_CONFIG register. This will be helpful to avoid
On Mon, Feb 04, 2013 at 07:52:01PM +0530, R Sricharan wrote:
Currently there is quite a lot of code which
is duplicated in the clocks code for OMAP 4 and 5
Socs. Avoiding this here by moving the clocks
data to a SOC specific place and the sharing the
common code.
This helps in addition of
On Mon, Feb 04, 2013 at 07:52:02PM +0530, R Sricharan wrote:
The pmic code is duplicated for OMAP 4 and 5.
Instead move the data to Soc specific place and
share the code.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Reviewed-by: Tom Rini
On Mon, Feb 04, 2013 at 07:52:03PM +0530, R Sricharan wrote:
From: Lokesh Vutla lokeshvu...@ti.com
Removing the duplicated code in ddr3 initialization.
Also creating structure for lpddr2 mode registers to
avoid unnessecary revision checks.
These change reduces code addition for future
On Mon, Feb 04, 2013 at 07:52:04PM +0530, R Sricharan wrote:
From: Lokesh Vutla lokeshvu...@ti.com
A seperate omap_sys_ctrl_regs structure is defined for
omap4 5. If there is any change in control module for
any of the ES versions, a new structure needs to be created.
In order to remove
On Mon, Feb 04, 2013 at 07:52:05PM +0530, R Sricharan wrote:
From: Lokesh Vutla lokeshvu...@ti.com
There is some code duplication in the ddr io settings code.
This is avoided by moving the data to a Soc specific place and
letting the code generic.
This avoids unnessecary code addition
On Mon, Feb 04, 2013 at 07:59:20PM +0530, R Sricharan wrote:
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan r.sricha...@ti.com
[snip]
/* To be verified */
#define OMAP5430_CONTROL_ID_CODE_ES1_0 0x0B94202F
+#define
On Mon, Feb 04, 2013 at 07:59:21PM +0530, R Sricharan wrote:
PRCM register addresses are changed from ES1.0 to ES2.0 due to
PER power domain getting moved to CORE power domain.
So adding the nessecary register changes for the same.
Signed-off-by: R Sricharan r.sricha...@ti.com
On Mon, Feb 04, 2013 at 07:59:22PM +0530, R Sricharan wrote:
Change OPP settings as per the latest 0.4 version of
addendum for OMAP5430 ES2.0
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
Reviewed-by: Tom Rini tr...@ti.com
--
Tom
On Mon, Feb 04, 2013 at 07:59:23PM +0530, R Sricharan wrote:
From: Lokesh Vutla lokeshvu...@ti.com
Add pre calculated timing settings of LPDDR2 and DDR3 memories
present in OMAP5430 and OMAP5432 ES2.0 versions.
Also adding the DDR pad io settings required for
OMAP543X SOCs here.
On Mon, Feb 04, 2013 at 07:59:24PM +0530, R Sricharan wrote:
From: Lokesh Vutla lokeshvu...@ti.com
After power-up SRCOMP cells are by-passed by default in OMAP5.
Software has to enable these SRCOMP sells.
For ES2: All 5 SRCOMP cells needs to be enabled.
For ES1: Only 4 SRCOMP cells in core
i mentioned this this weekend as well, can someone clarify this?
the source file cmd_df.c looks weird:
U_BOOT_CMD(
sf, 2, 1, do_serial_flash,
Serial flash sub-system,
probe [bus:]cs - init flash device on given SPI bus and CS)
so the source file
Hi Robert,
On Mon, 04 Feb 2013 10:54:05 -0500, Robert P. J. Day
rpj...@crashcourse.ca wrote:
i mentioned this this weekend as well, can someone clarify this?
the source file cmd_df.c looks weird:
U_BOOT_CMD(
sf, 2, 1, do_serial_flash,
Serial flash
Hi Mats,
On Mon, 4 Feb 2013 15:42:17 +, Mats Kärrman
mats.karr...@tritech.se wrote:
Hi Albert,
Albert ARIBAUD wrote:
Maybe, but the problem you state is not about cmd_disk (or I am
missing the point). USB commands are in USB related files, e.g.
do_usbboot() is in cmd_usb.c, so
Some expansion boards now ship with at24 eeproms that need to communicate
via 16bit addressing.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
---
board/ti/beagle/beagle.c |8
1 file changed, 8 insertions(+)
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
http://www.lsr.com/wireless-products/com6l
The eeprom on this expansion board requires 16bit addressing.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
---
board/ti/beagle/beagle.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/board/ti/beagle/beagle.c
On Thu, Dec 13, 2012 at 10:48:29PM -0800, Simon Glass wrote:
The previous generic board series hit a snag in that we needed generic
code to access some of the architecture-specific fields in global_data.
The solution eventually arrived at was to move these fields into a
separate structure,
On Thu, Jan 03, 2013 at 01:02:46AM -, Alexey Brodkin wrote:
Currently we have unsigned long blkcnt which is fine with
CONFIG_SYS_64BIT_LBA undefined because lbaint_t is basically the same
unsigned long.
If CONFIG_SYS_64BIT_LBA gets defined lbaint_t is defined as unsigned
long long.
On Wed, Nov 07, 2012 at 07:39:29AM -, Ashok wrote:
Remove unused macro CONFIG_DISCOVER_PHY from configs.
Signed-off-by: Ashok Kumar Reddy ashokkourla2...@gmail.com
Acked-by: Stefano Babic sba...@denx.de
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital
On Wed, Nov 07, 2012 at 07:39:29AM -, Ashok wrote:
Remove unused macro CONFIG_DISCOVER_PHY from configs.
Signed-off-by: Ashok Kumar Reddy ashokkourla2...@gmail.com
Acked-by: Stefano Babic sba...@denx.de
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital
On Tue, Jan 08, 2013 at 05:36:11AM -, Fabio Estevam wrote:
Using the __weak annotation can make the code cleaner.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
Acked-by: Marek Vasut ma...@denx.de
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital
On Sun, Jan 06, 2013 at 11:04:25PM -, Gabor Juhos wrote:
The execution order of the bootm subcommands is fixed.
Although here is a sanity check in the state machine
which should prevent running the subcommands in wrong
order but it does not catch all possible errors.
It is possible to
On Wed, Dec 12, 2012 at 04:48:56AM -, Jagannadha Sutradharudu Teki wrote:
Add support for Numonyx N25Q064 SPI flash.
Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital signature
On Tue, Jan 08, 2013 at 01:35:53PM -, Jeroen Hofstee wrote:
cc: Heiko Schocher h...@denx.de
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
board/sc3/init.S |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Applied to u-boot/master, thanks!
--
Tom
signature.asc
On Thu, Jan 24, 2013 at 01:05:55AM -, Jim Lin wrote:
Autoboot timeout defined by CONFIG_BOOTDELAY will not be accurate if
CONFIG_USB_KEYBOARD and CONFIG_SYS_USB_EVENT_POLL are defined in
configuration file and when tstc() function for checking key pressed
takes longer time than 10 ms
On Tue, Jan 22, 2013 at 11:40:06PM -, Michal Simek wrote:
CONFIG_ARM_DCC_MULTI should be also removed in the patch
serial: Remove CONFIG_SERIAL_MULTI from serial drivers
(sha1: a3827250606895ec2dd4b8d867342b7cabf3692f)
Because the driver defines serial_* functions
which cause conflict
On Mon, Dec 03, 2012 at 06:28:28AM -, Richard Genoud wrote:
As far as every arch has a get_timer function,
run_command_and_time_it code can now disappear.
Signed-off-by: Richard Genoud richard.gen...@gmail.com
Acked-By: Che-Liang Chiou clch...@chromium.org
Applied to u-boot/master,
On Thu, Dec 13, 2012 at 12:47:36AM -, Richard Genoud wrote:
toupper/tolower function are already declared, so use them.
Signed-off-by: Richard Genoud richard.gen...@gmail.com
Acked-by: Marek Vasut ma...@denx.de
Acked-by: Stefano Babic sba...@denx.de
Applied to u-boot/master, thanks!
On Thu, Dec 13, 2012 at 03:30:10AM -, Richard Genoud wrote:
ifdefs in the code are making it harder to read.
The use of simple if(vfat_enabled) makes no more code and is cleaner.
(the code is discarded by the compiler instead of the preprocessor.)
NB: if -O0 is used, the code won't be
On Mon, Feb 04, 2013 at 12:26:08PM +0100, Michal Simek wrote:
Hi Tom,
please pull all these changes to your tree.
The major change is remove really ancient i2c driver + helper files
for this driver.
Thanks,
Michal
The following changes since commit
2013/2/4 Tom Rini tr...@ti.com:
On Mon, Feb 04, 2013 at 12:26:08PM +0100, Michal Simek wrote:
Hi Tom,
please pull all these changes to your tree.
The major change is remove really ancient i2c driver + helper files
for this driver.
Thanks,
Michal
The following changes since commit
This mux is not currently used and appears to be a carry-over from the
am335x evm code.
Cc: Lars Poeschel poesc...@lemonage.de
Signed-off-by: Tom Rini tr...@ti.com
---
board/phytec/pcm051/mux.c |5 -
1 file changed, 5 deletions(-)
diff --git a/board/phytec/pcm051/mux.c
Dear Michal Simek,
was this ever applied?
From: Jagannadha Sutradharudu Teki jaga...@xilinx.com
This patch corrected the first byte of idcode1 for S25FL256S SPI flash.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Hi,
was this ever applied? I see SPI flash patches are completely ignored.
This is a S25FL064A successor. It supports up to 104MHz bus
speed.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Mike Frysinger vap...@gentoo.org
Cc: Scott Wood
Hi,
2013/2/4 Marek Vasut ma...@denx.de:
Dear Michal Simek,
was this ever applied?
I have sent pull request to Tom and Mike. All patches around cf are here.
http://git.denx.de/?p=u-boot/u-boot-microblaze.git;a=shortlog;h=refs/heads/mainline/sf
Interesting that Tom applied this patch and
On Thu, Jan 24, 2013 at 4:39 PM, Marek Vasut ma...@denx.de wrote:
PATCH:
diff --git a/tools/mxsboot.c b/tools/mxsboot.c
index 6c05aa4..d92c39f 100644
--- a/tools/mxsboot.c
+++ b/tools/mxsboot.c
@@ -551,7 +551,7 @@ static int mx28_create_sd_image(int infd, int outfd)
fsize =
On Mon, Feb 4, 2013 at 4:12 PM, Fabio Estevam feste...@gmail.com wrote:
On Thu, Jan 24, 2013 at 4:39 PM, Marek Vasut ma...@denx.de wrote:
PATCH:
diff --git a/tools/mxsboot.c b/tools/mxsboot.c
index 6c05aa4..d92c39f 100644
--- a/tools/mxsboot.c
+++ b/tools/mxsboot.c
@@ -551,7 +551,7 @@
Dear Fabio Estevam,
[...]
@@ -574,8 +574,8 @@ static int mx28_create_sd_image(int infd, int outfd)
cb-drv_info[0].chip_num = 0x0;
cb-drv_info[0].drive_type = 0x0;
cb-drv_info[0].tag = 0x1;
- cb-drv_info[0].first_sector_number = sd_sector + 1;
-
Dear Otavio Salvador,
On Mon, Feb 4, 2013 at 4:12 PM, Fabio Estevam feste...@gmail.com wrote:
On Thu, Jan 24, 2013 at 4:39 PM, Marek Vasut ma...@denx.de wrote:
PATCH:
diff --git a/tools/mxsboot.c b/tools/mxsboot.c
index 6c05aa4..d92c39f 100644
--- a/tools/mxsboot.c
+++
On Mon, Feb 4, 2013 at 4:46 PM, Marek Vasut ma...@denx.de wrote:
Dear Otavio Salvador,
On Mon, Feb 4, 2013 at 4:12 PM, Fabio Estevam feste...@gmail.com wrote:
On Thu, Jan 24, 2013 at 4:39 PM, Marek Vasut ma...@denx.de wrote:
PATCH:
diff --git a/tools/mxsboot.c b/tools/mxsboot.c
index
Dear Nikita Kiryanov,
In message 1359977979-28585-2-git-send-email-nik...@compulab.co.il you wrote:
Currently code that displays BMP files does two things:
* assume that any address is a valid load address for a BMP
* access in-memory BMP header fields directly
Since some BMP header fields
On 19:59-20130204, R Sricharan wrote:
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap5/hwinit.c | 13 +++--
arch/arm/include/asm/arch-omap5/omap.h |2 ++
arch/arm/include
On 02/02/2013 09:04:39 AM, Marek Vasut wrote:
Dear Benoît Thébaudeau,
Hi Marek,
On Tuesday, January 8, 2013 12:18:05 PM, Benoît Thébaudeau wrote:
Dear Marek Vasut,
On Tuesday, January 8, 2013 12:05:26 PM, Marek Vasut wrote:
Dear Benoît Thébaudeau,
[...]
I wonder if
Hello,
The following changes since commit 1071e736ae1bfb4550dfac25ca865b06ef79c00e:
Merge 'u-boot/master' (v2013.01.01) into 'u-boot-arm/master' (2013-02-03
15:30:20 +0100)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to
On 19:59-20130204, R Sricharan wrote:
Change OPP settings as per the latest 0.4 version of
addendum for OMAP5430 ES2.0
--please be clear that these are for OPP_NOM. FYI, latest documentation
is 0.5 rev which was released in Jan, considering this patch was send in
Feb, might be good to cross
commit d2d6bdaaef5f7eb39551e2288164b710021125fd
Author: Reinhard Arlt reinhard.a...@esd.eu
Date: Mon Feb 4 19:45:16 2013 +0100
Fix broken bootvx command.
Signed-off-by: Reinhard Arlt reinhard.a...@esd.eu
diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index a667a46..ab9c7e3 100644
---
Dear Nikita Kiryanov,
In message 510fab72.3050...@compulab.co.il you wrote:
I did mention that I consider that fix as temporary. I believe this fix
is better because it addresses the issue everywhere and does so in a
more maintainable way (does not require the address fix to be duplicated
Dear Albert ARIBAUD,
In message 20130204151956.0c0e8486@lilith you wrote:
I actually like the new fix less, as it adds an API where there is no
need of one -- it's not like the implementation of BMP is at risk of
changing. What is the problem in fixing the load address at load time
and then
1 - 100 of 126 matches
Mail list logo
