Dear Joonyoung Shim,
On 29 March 2010 11:56, Joonyoung Shim jy0922.s...@samsung.com wrote:
This patch adds the new board SMDK6442 that uses s5p6442 SoC.
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
Dear Joonyoung Shim,
On 29 March 2010 11:56, Joonyoung Shim jy0922.s...@samsung.com wrote:
This patch is for serial support of s5p6442 SoC.
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
Dear Joonyoung Shim,
On 29 March 2010 11:56, Joonyoung Shim jy0922.s...@samsung.com wrote:
This patch adds support s5p6442 SoC. The s5p6442 SoC is ARM1176
processor.
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Joonyoung Shim
Hi Frans,
Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
Looks good, so
Acked-by: Detlev Zundel d...@denx.de
Cheers
Detlev
--
Restrict Digital Restrictions Management:
If you can't copy it - don't buy it
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev
Hi Frans,
Forgot this disclaimer, thought I added it, sry.
NOTE:
This code is untested as I have no board with onenand support.
However, it compiles properly (tested by building opap3_evm, which uses this).
The changes I did are purely splitting do_onenand in separate
functions and add the
Hi zs,
SMDK2416 # U-Boot 1.1.6 (Sep 24 2009 - 10:24:40) for SMDK2416
Unknown command 'U-Boot' - try 'help'
U-Boot 1.1.6 is _really old_. Please try with a recent version of
U-Boot from the git repository.
Also it somewhat looks like you're UART is in loopback mode if it
interprets the U-Boot
Hi Alexander,
may I ask if there is reason why merge commits don't have a summary?
Yes, you may. Actually this is a good question.
I find those summaries (enabled with git config [--global] merge.summary
true) very hand to see what was changed with the merge commit.
I didn't even know
Hi Frans,
2010/3/29 Detlev Zundel d...@denx.de:
Hi Frans,
Forgot this disclaimer, thought I added it, sry.
NOTE:
This code is untested as I have no board with onenand support.
However, it compiles properly (tested by building opap3_evm, which uses
this).
The changes I did are purely
Wolfgang,
U-Boot v2010.03-rc3 has been released.
Please help testing, and send any feedback / last minute patches ASAP.
if there's any chance that you'll apply this patch we can include the
latest code in our long term test site and report any possible issues
related with U-Boot @ MPC5200.
Hi all,
I am sorry, but I had to reset the next branch as an incorrect
commit had sneeked in. I apologize for any inconveniences this may be
causing.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5,
In message m2mxxreamw@ohwell.denx.de Detlev Zundel wrote:
may I ask if there is reason why merge commits don't have a summary?
Yes, you may. Actually this is a good question.
I find those summaries (enabled with git config [--global] merge.summary
true) very hand to see what was
Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,
In message 1269856412.5008.48.ca...@swa-m460 you wrote:
Please help testing, and send any feedback / last minute patches ASAP.
if there's any chance that you'll apply this patch we can include the
latest code in our long term test site and report any
Wolfgang,
Please help testing, and send any feedback / last minute patches ASAP.
if there's any chance that you'll apply this patch we can include the
latest code in our long term test site and report any possible issues
related with U-Boot @ MPC5200.
Booting a Multi-File Image including a linux kernel, ramdisk and
fdt, generated with
mkimage -A ppc \
-O linux \
-T multi \
-C gzip \
-a \
-e \
-n kernel-2.6+initrd+dtb \
-d vmlinux.bin.gz:ramdisk_image.gz:board.dtb \
multi.bin
actually fails,
Hello Wolfgang,
please pull for next branch the following changes for i2c:
The following changes since commit 0020db3f0da61f3e2c8a459a87598e07594dc8ac:
Wolfgang Denk (1):
Merge remote branch 'origin/master' into next
are available in the git repository at:
Dear Andre Schwarz,
In message 4bb0987d.7050...@matrix-vision.de you wrote:
This is new code - posted just a couple of days ago. It will certainly
not go into the upcoming release any more.
Hmm - it's just another board making use of existing mpc5xxx code and
some common matrix-vision
commit 4b142febff71eabdb7ddbb125c7b583b24ddc434 (common: delete
CONFIG_SYS_64BIT_VSPRINTF and CONFIG_SYS_64BIT_STRTOUL) breaks printf on my
arm/pxa270 board. For example, the code
int a = 128;
printf(a= %d\n, a);
will print zero on the console. The problem reproduced on gcc
Dear Heiko Schocher,
In message 4bb08be4@denx.de you wrote:
Booting a Multi-File Image including a linux kernel, ramdisk and
fdt, generated with
mkimage -A ppc \
-O linux \
-T multi \
-C gzip \
-a \
-e \
-n kernel-2.6+initrd+dtb \
-d
Dear Heiko Schocher,
In message 4bb090c0.4060...@denx.de you wrote:
Hello Wolfgang,
please pull for next branch the following changes for i2c:
The following changes since commit 0020db3f0da61f3e2c8a459a87598e07594dc8ac:
Wolfgang Denk (1):
Merge remote branch 'origin/master'
Vipin KUMAR wrote:
On 3/29/2010 3:21 AM, Tom wrote:
Vipin KUMAR wrote:
SMI driver fails because of low timeout values. Increasing the erase
and write
timeouts to 3 seconds
This is a huge timeout change.
2ms to 3000ms.
If something goes wrong, it will seem like the board is hung.
Is this
2010/3/29 Heiko Schocher h...@denx.de:
Hello Wolfgang,
please pull for next branch the following changes for i2c:
The following changes since commit 0020db3f0da61f3e2c8a459a87598e07594dc8ac:
Wolfgang Denk (1):
Merge remote branch 'origin/master' into next
are available in the git
Heiko Schocher wrote:
$ ./MAKEALL suen3
jffs2_1pass.c: In function 'get_fl_mem':
jffs2_1pass.c:399: warning: unused variable 'id'
jffs2_1pass.c: In function 'get_node_mem':
jffs2_1pass.c:423: warning: unused variable 'id'
Signed-off-by: Heiko Schocher h...@denx.de
This change does silence
This patch is based on custom u-boot-1.1.2 version produced by voipac
(http://www.voipac.com) and board/trizepsiv files from current u-boot.
Up to now only PXA270 DIMM module with NOR flash is tested.
Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com
---
Makefile
Matthias Fuchs wrote:
This patch is part of migrating the AT91 support towards
using C struct for all SOC access.
It removes one more CONFIG_AT91_LEGACY warning.
at91_pmc.h needs cleanup after migration of the drivers
has been done.
Yes.
All the #if-def-ing will be removed when the
Wolfgang,
This is new code - posted just a couple of days ago. It will certainly
not go into the upcoming release any more.
Hmm - it's just another board making use of existing mpc5xxx code and
some common matrix-vision code already present.
There are no mods to any code possibly
Hi, This is hari,working in inforce computing in india.i want small help
from u r side on das u-boot loader.We developed a new NIC card based on the
Caviun octeon 2 CN63xx processor which is communicating through PCIe
protocal to Host.I already downloaded new u-boot-2010.03-rc1 source code.can
u
Dear Hari Babu,
In message e05b45b91003290607r7aa794c8iea484a36e9e81...@mail.gmail.com you
wrote:
Hi, This is hari,working in inforce computing in india.i want small help
from u r side on das u-boot loader.We developed a new NIC card based on the
Please don't try to be keewl - don't use
This patch fixes a problem introduced with patch eb5eb2b0
[ppc4xx: Cleanup PPC4xx I2C infrastructure]. We need to assign the I2C
base address to the i2c pointer inside of the controller loop.
Otherwise controller 0 is initialized multiple times instead of
initializing each I2C controller
Hello Stefan,
Stefan Roese wrote:
This patch fixes a problem introduced with patch eb5eb2b0
[ppc4xx: Cleanup PPC4xx I2C infrastructure]. We need to assign the I2C
base address to the i2c pointer inside of the controller loop.
Otherwise controller 0 is initialized multiple times instead of
Hi Heiko,
On Monday 29 March 2010 15:43:50 Heiko Schocher wrote:
Heiko, I just noticed that this PPC4xx I2C driver is still in the
cpu/ppc4xx directory. I suggest that we move it into drivers/i2c
after the next release. Is this ok for you? I can provide a patch
for this soon.
Yep, that
Hello Stefan,
Stefan Roese wrote:
On Monday 29 March 2010 15:43:50 Heiko Schocher wrote:
Heiko, I just noticed that this PPC4xx I2C driver is still in the
cpu/ppc4xx directory. I suggest that we move it into drivers/i2c
after the next release. Is this ok for you? I can provide a patch
for
Hello,
This question is for the LPC3250 (phy3250 board).
Is there any plans for make the u-boot ready so it does not need the S1l.
I do see that there is started some work on it, but the code is stub.
Best Regards
Bjørnar Syverstad
___
U-Boot mailing
Hi Heiko,
On Monday 29 March 2010 15:57:22 Heiko Schocher wrote:
Please let me know if you see any problems with this patch. I would
really like to push it into this release, since it really is a bug
fix.
It looks Ok for me.
Good. If nobody else objects, I'll push it into
Hello Stefan,
Stefan Roese wrote:
On Monday 29 March 2010 15:57:22 Heiko Schocher wrote:
Please let me know if you see any problems with this patch. I would
really like to push it into this release, since it really is a bug
fix.
It looks Ok for me.
Good. If nobody else objects, I'll push it
Hi!
I want to save and retrieve environment variables from a file in MMC. Can I get
some pointers towards this?
Whether env_relocate_spec() and other such functions, has some implementation
for MMC also?
regards
-Nitin
Get your preferred Email name!
Now you can @ymail.com and
On Monday 29 March 2010 11:21:22 Nitin Mahajan wrote:
I want to save and retrieve environment variables from a file in MMC. Can I
get some pointers towards this?
Whether env_relocate_spec() and other such functions, has some
implementation for MMC also?
search the archives. some people
After determining how much DDR is actually in the system, adjust DBAT0 and
IBAT0 accordingly. This ensures that the CPU won't attempt to access
(via speculation) addresses outside of actual memory.
On 86xx systems, DBAT0 and IBAT0 (the BATs for DDR) are initialized to 2GB and
kept that way. If
This driver uses the internal RTT as RTC like the linux driver.
To enable it, these defines are needed:
#define CONFIG_CMD_DATE
#define CONFIG_RTC_AT91SAM9
#define CONFIG_RTC_AT91SAM9_RTT AT91_RTT0_BASE /* for AT91SAM9263 */
#define CONFIG_RTC_AT91SAM9_RTT AT91_RTT_BASE /* AT91SAM9260 or
Based on the linux driver.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
README |1 +
drivers/rtc/Makefile |1 +
drivers/rtc/at91sam9-rtc.c | 162
3 files changed, 164 insertions(+), 0 deletions(-)
create
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
include/asm-arm/arch-at91/at91sam9260.h |2 ++
include/asm-arm/arch-at91/at91sam9261.h |2 ++
include/asm-arm/arch-at91/at91sam9263.h |3 +++
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git
Joonyoung Shim wrote:
This patch is for onenand support of s5p6442 SoC.
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
Acked-by: Scott Wood scottw...@freescale.com
-Scott
The current ARM1176 CPU specific code is too specific to the SMDK6400
architecture. The following changes were necessary prerequisites for the
addition of other SoCs based on ARM1176.
Existing board's (SMDK6400) configuration has been modified to keep behavior
unchanged despite these changes.
TNETV107X is a Texas Instruments SoC based on an ARM1176 core, and with a
bunch on on-chip integrated peripherals. This patch series generalizes current
ARM1176 code to allow for the addition of new ARM1176 SOCs. The remaining
patches in this series add arch and board support.
The contents of
TNETV107X is a Texas Instruments SoC based on an ARM1176 core, and with a
bunch on on-chip integrated peripherals. This patch adds support for the
TNETV107X EVM board.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
MAKEALL |1 +
Makefile
Uups,
looks like I have corrupted the set date functionality with one of my
last minute changes (as I've just discovered). I will send a fixed patch
2/2 tomorrow.
Regards,
Alexander Holler
___
U-Boot mailing list
U-Boot@lists.denx.de
On Mar 29, 2010, at 12:51 PM, Timur Tabi wrote:
After determining how much DDR is actually in the system, adjust
DBAT0 and
IBAT0 accordingly. This ensures that the CPU won't attempt to access
(via speculation) addresses outside of actual memory.
On 86xx systems, DBAT0 and IBAT0 (the
On Mon, Mar 29, 2010 at 5:09 PM, Becky Bruce bec...@kernel.crashing.org wrote:
--- a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
+++ b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
@@ -72,6 +72,8 @@ initdram(int board_type)
dram_size = fixed_sdram();
#endif
+ adjust_ddr_bat(dram_size);
On Mar 29, 2010, at 6:07 PM, Timur Tabi wrote:
On Mon, Mar 29, 2010 at 5:09 PM, Becky Bruce bec...@kernel.crashing.org
wrote:
snip
I think you need to adjust how much usable ram u-boot thinks it has
if
you can't map it all.
I tried that. The problem is that U-Boot uses this
From: Timur Tabi ti...@freescale.com
After determining how much DDR is actually in the system, set DBAT0 and
IBAT0 accordingly. This ensures that the CPU won't attempt to access
(via speculation) addresses outside of actual memory.
On 86xx systems, DBAT0 and IBAT0 (the BATs for DDR) are
On Mon, Mar 29, 2010 at 10:02 PM, Kumar Gala ga...@kernel.crashing.org wrote:
+ * We also assume that the XBL bits are ignored by the processor (even if
set)
+ * if extended BAT addressing is disabled.
Since we don't read/modify/write that BATs, this comment is probably
not true any more.
On Mar 29, 2010, at 10:40 PM, Timur Tabi wrote:
On Mon, Mar 29, 2010 at 10:02 PM, Kumar Gala ga...@kernel.crashing.org
wrote:
+ * We also assume that the XBL bits are ignored by the processor (even if
set)
+ * if extended BAT addressing is disabled.
Since we don't read/modify/write
initialize mac address with the value from ethaddr, before
doing some network commands. This is not in line with u-boot
design principle not to initalize not used devices, and
maybe should go away, if there is a solution for passing
the mac address to arm linux kernels.
Tested on the magnesium
initialize mac address with the value from ethaddr, before
doing some network commands. This is not in line with u-boot
design principle not to initalize not used devices, and
maybe should go away, if there is a solution for passing
the mac address to arm linux kernels.
Tested on the suen3 board.
53 matches
Mail list logo
