From: David Brownell dbrown...@users.sourceforge.net
The console: unify printing current devices patch goofed:
CONFIG_SYS_CONSOLE_INFO_QUIET is supposed to *REMOVE* boot
time noise, not add it. Said patch changed the #ifndefs
to #ifdef; this one restores them to the proper sense.
Signed-off
On Wednesday 02 September 2009, John Rigby wrote:
Sandeep and all interested parties:
I am trying to understand davinci 4-bit nand options for u-boot and
linux.
In flux just now. The techinical issue is an ECC engine that's a
bit rough to work with except on small page chips. Summary of
On Sunday 31 May 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 19:46 Sun 03 May , Thomas Lange wrote:
NAND module should not modify EMIF registers unrelated to CS2
that is used for NAND, i.e. do not modify EWAIT config register
or registers for other Chip Selects.
Without this
For some reason the AT91rm9200 lowlevel init writes to a bunch of
reserved or read-only addresses. All the boards seem to define the
value-to-be-written values as zero ... but they shouldn't actually
be writing *anything* there.
If there's a real need to write these locations, like an erratum
) failed ... copying *way* over 15 MBytes, and trashing
the DRAM image of U-Boot that was running. (Compiler issue?)
Sending this along anyway; it basically works, bugs can be fixed later.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
NOTE: depends on cpu/arm920t/at91rm9200
On Saturday 13 June 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
The machine_is_X() macros are automatically #ifdeffed in
the header; no size impact. Read asm/mach-types.h ...
If I use this pacth on the rm9200ek the u-boot.bin size will increase
for nothing
I'm not following you. The
On Saturday 13 June 2009, Mike Frysinger wrote:
See above. There already *IS* such an #ifdef, but it's just not
cluttering up the guts of that driver.
you adding MUST have NO size impact on other board
if we apply you code as it we will increase the size of u-boot for
This is still in my mailbox, don't know that I'll get around to
it any time soon, but another requirement came to mind.
On Wednesday 22 April 2009, Scott Wood wrote:
On Tue, Apr 21, 2009 at 07:38:27PM -0700, David Brownell wrote:
I was hoping that I could use that to test some NAND code
On Wednesday 17 June 2009, Ben Warren wrote:
Applied to net repo.
Thanks. Random question: is that driver going to move
into drivers/net or will it stay in cpu/arm920t? I thought
I saw you moving things out of cpu/* a while back.
- Dave
___
U-Boot
On Thursday 25 June 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 14:58 Fri 12 Jun , David Brownell wrote:
Add support for csb337, an older at91rm9200 board. These boards
originally shipped with MicroMonitor, not U-Boot. This config
supports boot from Ethernet, and talks over I2C
On Monday 29 June 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
- USB didn't work; the software wouldn't detect usb-storage devices.
So it's not yet enabled.
what is the power on the USB?
I don't understand the question. 5V of course. Not switchable.
is the usb provide
a followup
patch?
That should have been CONFIG_SOC_DM644X in the first place, yes.
== CUT HERE
From: David Brownell dbrown...@users.sourceforge.net
Typo fix: use CONFIG_SOC_DM644X, not CONFIG_SOC_DM646.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
drivers/mtd/nand
On Friday 10 July 2009, Wolfgang Denk wrote:
Dear David Brownell,
In message 200906282241.54948.davi...@pacbell.net you wrote:
On Tuesday 09 June 2009, David Brownell wrote:
Meanwhile, here's a patch/RFC disabling what seems to be bogosity.
If it's eventually a go, the supporting
For some reason the AT91rm9200 lowlevel init writes to a bunch of
reserved or read-only addresses. All the boards seem to define the
value-to-be-written values as zero ... but they shouldn't actually
be writing *anything* there.
No documented erratum justifies these accesses. It looks like
.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
DIFFERS FROM SANDEEP'S PATCH: (a) 64-bit VSPRINTf, (b) no MLC hooks,
(c) environment in block 0, which would otherwise be wasted, (d) no
dependency on dubious remove SZ_* symbols patches, (e) buildfix
board/davinci/dm355evm
On Monday 05 October 2009, Tom wrote:
In general it is better to break patches that do multiple things into
multiple patches. When you resubmit, please break this patch into its
logical parts :
1. NAND
2. Environment
Hmm, my *original* patch necessarily disabled both
because there was no
On Monday 05 October 2009, Paulraj, Sandeep wrote:
I have already ack-ed Sandeep's patch that contains this
fix for the warning. Please check with him.
That is correct, I did not add it to my tree because you ACK'ed
this patch only after I sent a pull request. So obviously I cannot
add a
On Monday 05 October 2009, Paulraj, Sandeep wrote:
I guess that happened after I prepared the patch but before I sent
it in. I'll look; there were some differences still. Notably to
store the environment in the otherwise-unused block zero,
That is because most users who have used
On Saturday 07 November 2009, Paulraj, Sandeep wrote:
Quick head up.
I submitted this patch to the u-boot mailing list on David Brownell's behalf.
Sandeep
You should *NEVER* forge From addresses like spammers do.
___
U-Boot mailing list
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 then discarding every one.
Using the right Ethernet address is a big win.
Signed-off-by: David Brownell dbrown
From: David Brownell dbrown...@users.sourceforge.net
Update the DaVinci DM6446 boards to use the new convention
for CONFIG_SYS_NS16550_REG_SIZE ... the size hasn't changed
from the original 4 bytes, but these chips are little-endian.
(Resolves a regression added recently by the include/ns16550.h
From: David Brownell dbrown...@users.sourceforge.net
Minor cleanup to clock-related defines for DaVinci DM6446 boards:
- CONFIG_SYS_CLK_FREQ is unused; remove it.
- CONFIG_SYS_NS16550_CLK must be the same as CONFIG_SYS_HZ_CLOCK
On DM6446 both of those peripheral clocks actually come from
From: David Brownell dbrown...@users.sourceforge.net
Chips without the EMAC controller won't need the utilities
it uses to read an Ethernet address from EEPROM; so don't
include them needlessly.
Use is_valid_ether() to validate the address from EEPROM.
All-zero addresses aren't the only invalid
From: David Brownell dbrown...@users.sourceforge.net
Start updating DaVinci board support to reduce dependencies on
dm644x chips and EVM-like boards ... beginning with psc.c,
which hosts a bunch of those dependencies:
- Pinmux registers and their contents are SoC-specific, and
are also
From: David Brownell dbrown...@users.sourceforge.net
Don't needlessly include lowlevel init code; that's only really
needed with boot-from NOR (not boot-from-NAND). The 2nd stage
loader (UBL) handles that before it loads U-Boot.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
On Sunday 12 April 2009, David Brownell wrote:
... read six bytes, instead of reading twelve
bytes then discarding every one.
Urgh, editing goof. Should read discarding every other one.
___
U-Boot mailing list
U-Boot@lists.denx.de
http
From: David Brownell dbrown...@users.sourceforge.net
Fix dependency goofage: it should certainly be possible to have the
partition support without bringing in UBI commands.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
drivers/mtd/Makefile |2 +-
1 file changed, 1
On Monday 13 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
please move this to the Makefile
= CUT HERE
From: David Brownell dbrown...@users.sourceforge.net
Don't needlessly include lowlevel init code; that's only really
needed with boot-from NOR (not boot-from-NAND). The 2nd stage
On Tuesday 14 April 2009, Wolfgang Denk wrote:
Please don't do it like this. Please use the same style like
everybody else.
Having to guess .. you mean don't indent?
== CUT HERE
From: David Brownell dbrown...@users.sourceforge.net
Don't needlessly include lowlevel init code; that's
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 dbrown...@users.sourceforge.net
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -1314,7
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 other one.
Using the right Ethernet address is a big win.
Signed-off-by: David
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.
@@ -129,10 +122,12 @@ void davinci_enable_uart0(void)
lpsc_on
On Thursday 16 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
please move the Makefile to SOBJS-y COBJS-y
I'm not following. A quick scan of boards I've used shows
most of them using SOBJS, rather than SOBJS-y.
And how would you propose making a *negative* config option
(as in $SUBJECT)
On Friday 17 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
could you split it in more logical change please
I'll fragment it a bit more, ok. later.
Re-worked version coming in X parts, which also include a
patch changing the cpu/arm926ejs/davinci directory to use
the conditional
From: David Brownell dbrown...@users.sourceforge.net
Move DaVinci PSC support from board/* to cpu/* where it belongs.
The PSC module manages clocks and resets for all DaVinci-family
SoCs, and isn't at all board-specific.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
board
From: David Brownell dbrown...@users.sourceforge.net
Fix two buglets in the dm644x support: don't set two must-be-zero
bits in the UART management register; and only include the I2C hooks
if the I2C driver is being included.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
cpu
From: David Brownell dbrown...@users.sourceforge.net
Split out DaVinci DM6446-specific bits from more generic bits:
- Add a CONFIG_SOC_DM644X. All current boards use DM6446 chips;
DM6443 and DM6441 chips differ in available peripherals.
- Move most DM644X-specific bits from psc.c to a new
From: David Brownell dbrown...@users.sourceforge.net
Add some basic declarations for DaVinci DM355/DM350/DM335 support,
keyed on CONFIG_SOC_DM355. (DM35X isn't quite right because the
DM357 is very different; while the DM355 is like a DM355 without
the MPEG/JPEG coprocessor).
These have
From: David Brownell dbrown...@users.sourceforge.net
Update cpu/arm926ejs/davinci/Makefile to use COBJ-y type syntax.
Add the first conditional: for EMAC driver support. Not all
chips have an EMAC; and boards might not use it, anyway.
This doesn't touch PHY configuration; that should eventually
I was hoping that I could use that to test some NAND code, but
then I noticed it wasn't implemented. I would have expected that
U-Boot command wouldn't exist until they're implemented...
I'm hoping someone has an implementation. With at least these
characteristics:
- Doesn't toggle the same
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
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
On Friday 24 April 2009, Dirk Behme wrote:
Btw.: Now that -next exists, I can't find patch linked above in it,
though :(
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next
shows it ... respects SKIP_LOWLEVEL_INIT. Make sure
to look at the next branch there; you can
On Friday 24 April 2009, Ben Warren wrote:
My approach is that once the merge window closes, new patches that are not
bug fixes go into 'next', which is for the release after the current one (in
this case 07).
Then I'm curious how that dm9000 EEPROM reading bugfix
landed in net/next ... or is
On Saturday 25 April 2009, Ben Warren wrote:
Then I'm curious how that dm9000 EEPROM reading bugfix
landed in net/next ... or is the point that the merge
window for 2009.05 is still open, since RC1 hasn't yet
been tagged?
In this case a pretty good argument could be made that it's a
Hi Wolfgang,
On Saturday 25 April 2009, Wolfgang Denk wrote:
in message 200904250555.17450.davi...@pacbell.net you wrote:
I think the questions on this topic reflect a reality that
such status updates aren't yet visible enough. (The original
question was generic, not ARM-specific.)
On Saturday 25 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
For me when the first version of a [patch] is send after the close of the
merge and
it's not a bug fix, then it will go to the next MW. The only exception will be
if the patch come from an announce or a thread discussion
I was looking at the DaVinci NAND support in current U-Boot
code (i.e. 2009.03 plus patches merged since that release),
and am puzzled by the above-named config option.
Before I submit a patch to remove it from U-Boot GIT (nothing
there enables it, and it will nastify 4-bit support), I thought
On Sunday 26 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
Before I submit a patch to remove it from U-Boot GIT (nothing
there enables it, and it will nastify 4-bit support), I thought
I'd see if anyone knows exactly what software it was trying to
emulate. ...
maybe
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
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
On Tuesday 28 April 2009, Ben Warren wrote:
The driver has been renamed dm644x_emac.c
Let me suggest davinci_emac.c ... the same controller
is in some non-dm644x DaVinci silicon (like dm365), and
a gigabit flavor is in the dm6467 chip.
-COBJS = timer.o ether.o lxt972.o dp83848.o
+COBJS
From: David Brownell dbrown...@users.sourceforge.net
Minor cleanup for DaVinci NAND code:
- Use I/O addresses from nand_chip; CONFIG_SYS_NAND_BASE won't
be defined when there are multiple chipselect lines in use
(as with common 2 GByte chips).
- Cleanup handling of EMIF control
From: David Brownell dbrown...@users.sourceforge.net
Remove CONFIG_SYS_DAVINCI_BROKEN_ECC option. It's not just nasty;
it's also unused by any current boards, and doesn't even match the
main U-Boot distributions from TI (which use soft ECC, or 4-bit ECC
on newer chips that support it).
DaVinci
On Tuesday 28 April 2009, s-paul...@ti.com wrote:
The CLE and ALE for DaVinci DM644x is not the same as DM646x. This patch
adds 2 CONFIG_ options to the config.h header files to all the DM6446 based
boards. These values are then used by the driver.
I had been thinking that the davinci_nand
On Tuesday 28 April 2009, s-paul...@ti.com wrote:
Patch adds support for DaVinci DM357. This SOC is very similar to the DM644x.
The DM357 EVM has 2 NANDs, one small page NAND and another large page NAND.
But the device can only boot of the small page NAND. It does not have NOR
support. This
On Tuesday 28 April 2009, s-paul...@ti.com wrote:
Makefile | 3 +
include/configs/davinci_dm357_evm.h | 159
+++
2 files changed, 162 insertions(+), 0 deletions(-)
I believe that will be insufficient with the current
U-Boot
(in 2.6.30-rc) should
handle this fine, though.
- Dave
Thanks,
Sandeep
-Original Message-
From: David Brownell [mailto:davi...@pacbell.net]
Sent: Tuesday, April 28, 2009 5:57 PM
To: Paulraj, Sandeep; u-boot@lists.denx.de
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Subject
Hi Sandeep,
On Tuesday 28 April 2009, Paulraj, Sandeep wrote:
I had been thinking that the davinci_nand driver should
probably change to let board_nand_init() really become a
board-specific function...
It would call a driver routine to init the callback functions
and set up
From: David Brownell dbrown...@users.sourceforge.net
Initial U-Boot support for the DaVinci DM355 EVM. This is a board
from Spectrum Digital. Board docs include schematic and firmware
for its microcontroller:
http://c6000.spectrumdigital.com/evmdm355/
Most of the DM355 chip is fully
On Wednesday 29 April 2009, s-paul...@ti.com wrote:
+.globl dv_board_init
+dv_board_init:
+
+ mov pc, lr
Surely you can eliminate a file containing only such a
useless NOP function...
+#define CONFIG_SOC_DM644X
Hmm, I'd have expected a CONFIG_SOC_DM357. No DSP
(and so why were
On Wednesday 29 April 2009, Paulraj, Sandeep wrote:
Any other comments?
Not for now
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
From: David Brownell dbrown...@users.sourceforge.net
Make the DaVinci clock display code work on the dm355 too ... there
are pre- and post- dividers on its PLLs, which most other DaVinci
processors don't use; and it uses different PLL dividers. Stubbed
in support for the DM6467 too. Verified
On Tuesday 28 April 2009, Ben Warren wrote:
This patch set is an untested attempt at cleaning up the Davinci Ethernet
driver. Since I don't have any real hardware, I've tried to keep the logical
flow as similar to the original as possible and haven't touched any of the
hardware access code.
From: David Brownell dbrown...@users.sourceforge.net
This updates the optional (non-default!) NAND support for the
DaVinci DM6446 EVM:
- include MTD partitioning, defaulting to what Linux uses
- use a flash-based BBT, which among other things speeds bootup
This matches code that's now queued
On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 15:38 Wed 29 Apr , David Brownell wrote:
From: David Brownell dbrown...@users.sourceforge.net
Make the DaVinci clock display code work on the dm355 too ... there
are pre- and post- dividers on its PLLs, which most
On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
as the clock function could be move to cpu.c it will have the stringly-link
function
I'll stuff that in a new cpu.c file, but those
clock status display routines aren't mandatory.
On Thursday 30 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 23:35 Wed 29 Apr , David Brownell wrote:
On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
my idea is more this
the lowlovel will init the pll (lowlevel_init.S or other stage bootloader)
Right
On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
too long please split
Update below.
=== CUT HERE
From: David Brownell dbrown...@users.sourceforge.net
This updates the optional (non-default!) NAND support for the
DaVinci DM6446 EVM:
- include MTD partitioning, defaulting
On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
cpu.c will be better
Here's a followup patch that applies on top of this one,
and creates the cpu.c you wanted.
=== CUT HERE
From: David Brownell dbrown...@users.sourceforge.net
Move the clock-rate dumping code into the cpu
On Sunday 03 May 2009, Stephen Irons wrote:
Does this help at all
Not quite; since when I looked at the MontaVista code,
I didn't see anything like that brokeness. It's possible
that some old MV kernels had that. If so, more recent
stuff seems to have been cured.
at any rate, it is a bit of
On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 22:11 Tue 28 Apr 2009, David Brownell wrote:
Initial U-Boot support for the DaVinci DM355 EVM
MAKEALL|1
Makefile |3
board/davinci/dm355evm
Minor nit: for consistency with dvevm and dm355evm,
I suggest removing the underscore from dm357_evm in the
directory name.
--- /dev/null
+++ b/include/configs/davinci_dm357_evm.h
@@ -0,0 +1,155 @@
+...
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+#include asm/sizes.h
+#include
On Monday 11 May 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
+#define BIT(x) (1 (x))
please remove
or use set_bit
I think that should probably be added to all the bitops.h headers,
or someplace similar. But, OK; __{set,clear}_bit() work here too.
+/*#define CONFIG_SYS_NAND_SMALLPAGE
From: David Brownell dbrown...@users.sourceforge.net
Initial U-Boot support for the DaVinci DM355 EVM. This is a board
from Spectrum Digital. Board docs include schematic and firmware
for its microcontroller:
http://c6000.spectrumdigital.com/evmdm355/revd/
Most of the DM355 chip is fully
75 matches
Mail list logo
