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
U-
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 us
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
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
data.
Signed-off-by: David Brownell
---
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/dm355evm.c
On Wednesday 02 September 2009, John Rigby wrote:
> Thanks David, I'm less confused now. I think part of my misunderstanding is
> this comment about the new nand_read_page_hwecc_oob_first function in
> nand_base.c:
>
> * Hardware ECC for large page chips, require OOB to be read first.
> * For t
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
From: David Brownell
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-by: David Brownell
-
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 maybe
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
David, any thoughts? If this is in error, could you send a followup
> patch?
That should have been CONFIG_SOC_DM644X in the first place, yes.
== CUT HERE
From: David Brownell
Typo fix: use CONFIG_SOC_DM644X, not CONFIG_SOC_DM646.
Signed-off-by: David Brownell
---
drivers/mtd/nan
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.
>
>
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 fro
On Tuesday 09 June 2009, David Brownell wrote:
> 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 *anythin
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
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
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
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 ...
>
> If I use this pacth on the rm9200ek the u-boot.bin size will increase
> for nothing
I'm not following you. The lines a
a kernel
(1.4 MB) 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
---
NOTE: depends on cpu/arm920t/at91rm9200/ether.c pat
On Friday 12 June 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 11:14 Tue 09 Jun , David Brownell wrote:
> I'm not really a fan of this
> but ok if I see the csn337 board patch
I meant to send that in before, thanks for the reminder.
The email I just sent has that.
If you
CSB337 boards originally shipped with MicroMonitor, not U-Boot;
and with a version using a different convention for recording
Ethernet addresses than anyone else. To avoid breaking Linux
when it uses U-Boot, have it use the same convention on that
hardware.
Signed-off-by: David Brownell
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
tha
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.
> >
> > With
From: David Brownell
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 documented by TI, the most
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_S
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
> +#include
Brea
From: David Brownell
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 documented by TI, the most
From: David Brownell
Update chipselect handling in davinci_nand.c so that it can
handle 2 GByte chips the same way Linux does: as one device,
even though it has two halves with independent chip selects.
For such chips the "nand info" command reports:
Device 0: 2x nand0, sector si
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
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 o
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
Move the clock-rate dumping code into the cpu/.../davinci area
On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> too long please split
Update below.
=== CUT HERE
From: David Brownell
This updates the optional (non-default!) NAND support for the
DaVinci DM6446 EVM:
- include MTD partitioning, defaulting to what Linux uses
- us
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.
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 ...
> so instead of hardcoding the PPLDIV read it in the register
> and then calculate the clock rate
That's all this cod
On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> as all other recent board patch
> please unify the lds and please be aware of ben patch
Erm, could you elaborate? Which "ben patch"
would that be, and what do you mean by unifying
the lds?
I'm guessing the latter means move th
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 Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 15:38 Wed 29 Apr , David Brownell wrote:
> > From: David Brownell
> >
> > Make the DaVinci clock display code work on the dm355 too ... there
> > are pre- and post- dividers on its PLL
From: David Brownell
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 for mainline Linux, and
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
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 dm355 and dm6446.
Signe
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
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 w
From: David Brownell
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 documented by TI, the most notable
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
ve the current NAND driver (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, S
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 a
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:
> 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 d
From: David Brownell
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 GIT kernels si
From: David Brownell
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 registers
* Only need one po
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
> +C
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 o
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 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.
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
I'd
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 an
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-speci
On Saturday 25 April 2009, Wolfgang Denk wrote:
> > Yes. The issue is needing to guess what's up ... so for
> > example, I seem to observe that "merge window closed" must
> > not be the same as "first RC is out", which isn't how the
> > Linux process works. But that's the only example I've
> > se
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 th
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
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 c
On Friday 24 April 2009, Ben Warren wrote:
>
> >> http://lists.denx.de/pipermail/u-boot/2009-April/050800.html
> >>
> > this is throw Ben tree
> >
> >
> Actually, I asked you to pick it up:
>
> http://lists.denx.de/pipermail/u-boot/2009-April/051076.html
>
> If that's a problem let me
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-
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 consisten
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 bi
From: David Brownell
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
become conditiona
From: David Brownell
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 different peripherals than the D
From: David Brownell
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 dm644x.c file,
which is
From: David Brownell
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
---
cpu/arm926ejs/davinci/dm644x.c |4 +++-
1 file chang
From: David Brownell
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
---
board/davinci/common/Makefile |2
board/davinci/c
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 condi
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) f
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
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 right Ethernet address is a big win.
Signed-off-by: David Brownell
---
drivers/net/dm9000x.c
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
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -1314,7 +1314,7 @@ static void list_parti
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
Don't needlessly include lowlevel init code; that's on
On Monday 13 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> please move this to the Makefile
= CUT HERE
From: David Brownell
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) handle
From: David Brownell
Fix dependency goofage: it should certainly be possible to have the
partition support without bringing in UBI commands.
Signed-off-by: David Brownell
---
drivers/mtd/Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/mtd/Makefile
+++ b
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@li
From: David Brownell
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
--- a/cpu/arm926ejs/davinci/lowlevel_init.S
+++ b/cpu
From: David Brownell
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 unrelated to the Power
From: David Brownell
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 addresses.
From: David Brownell
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 the
same source, the primary
From: David Brownell
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
patch to "Unify
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 then discarding every one.
Using the right Ethernet address is a big win.
Signed-off-by: David Brownell
---
drivers/net/dm9000x.c | 12
85 matches
Mail list logo