* [PATCH] powerpc: mpc832x mds: Fix board PHY reset code
From: Kim Phillips @ 2007-11-20 1:04 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev; +Cc: Li Yang, peter.vanackeren
currently the board-level PHY reset code for the mpc832x MDS messes with
reset configuration words source settings which is plain wrong (it
looks like this board code was cut-n-pasted from the mpc8360 mds code,
which has the PHY reset bits in a different BCSR); this patch points
the PHY reset code to the proper mpc832x mds PHY reset bits in the BCSR.
Signed-off-by: Peter Van Ackeren <peter.vanackeren@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/platforms/83xx/mpc832x_mds.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 972fa85..9e3bfcc 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -90,10 +90,11 @@ static void __init mpc832x_sys_setup_arch(void)
if ((np = of_find_compatible_node(NULL, "network", "ucc_geth"))
!= NULL){
- /* Reset the Ethernet PHY */
- bcsr_regs[9] &= ~0x20;
+ /* Reset the Ethernet PHYs */
+#define BCSR8_FETH_RST 0x50
+ bcsr_regs[8] &= ~BCSR8_FETH_RST;
udelay(1000);
- bcsr_regs[9] |= 0x20;
+ bcsr_regs[8] |= BCSR8_FETH_RST;
iounmap(bcsr_regs);
of_node_put(np);
}
--
1.5.2.2
^ permalink raw reply related
* Re: Revisited, audio codec device tree entries.
From: David Gibson @ 2007-11-20 0:59 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40711191128i59245403g3e15e3b6c545b6ee@mail.gmail.com>
On Mon, Nov 19, 2007 at 12:28:02PM -0700, Grant Likely wrote:
> On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > You might be stuck with using either a platform_device or an
> > > of_platform_device as a stepping stone to creating the device on the
> > > ALSA fabric driver.
> >
> > I also concluded that I need a of_platform stepping stone.
> >
> > There are several ways this could be done, which one is the right one?
> > a) fabric is global, create a global device node for it and implement
> > it as a of_platform device
>
> This is really board level description stuff. I'd make the node
> global off the root myself and use whatever linkage you think
> appropriate to get you to the codec nodes (phandle's most likely)
No. I think this is the whole damn point we've been spiralling
around.
An of_platform device is appropriate *only* if there is an OF node for
the device. There should be an OF node for the device only if it it
really is a well-defined hardware component which implements it.
As far as I can understand, the "fabric" driver is really just a
catchall to cover whatever various interconnections there are between
audio components on the board.
Those interconnections could (and probably should) be described in the
OF tree. But that description would be to describe each of those
interconnections individually e.g. codecs have links to "sound PHY"
devices (speakers) or whatever, codecs, i2s AC97 and so forth devices
have links between them appropriate to the type of device. Not as
some imaginary "fabric device".
Therefore the fabric driver cannot be instantiated as an of_platfornm
device.
Therfore arch code will have to instantiate the fabric driver some
other way. There are a couple of options here:
1) We have a "universal" device-tree-based fabric driver which
parses all the above-described interconnection information in the
device tree and handles any situation. Cool, but probably a lot of
work and fiddly to get right.
2) Or, the platform code instantiates an appopriate fabric
driver for the board (which will probably make assumptions about how
things are interconnected). Platform code can optionally examine
board level model properties or other device information to select the
correct fabric driver and/or options. The fabric driver can
optionally look at some parts of the device tree information to
configure details of its operation.
Option (2) is a hack, but it's a reasonably well-contained hack. It
works for now, and doesn't preclude switching to option (1) later -
without changes to the device tree, and on a board-by-board basis. It
can also handle the (almost inevitable) case of device trees with
missing or incorrect detailed audio interconnection information.
The basic thing is that we have a mismatch between the Linux driver
model and the device tree model. Rather than hacking the device tree
to match the Linux model, we should provide whatever glue code is
necessary to instantiate the necessary Linux drivers from the device
tree information we have. This is, essentially, the exact purpose for
which platform code exists.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Looking for small form factor with HDLC
From: Kenneth Porter @ 2007-11-20 0:20 UTC (permalink / raw)
To: linuxppc-embedded
I'm attempting to create a middleware system that talks to one of my
vendor's motion control products. My vendor has an FPGA capable of perhaps
10 megabit performance, and RS485 full-duplex tranceivers. I want to be
able to send commands and receive events and bulk data efficiently. I'll
also add electrical isolation, possibly with suitable 485 transceivers.
I'm thinking that HDLC is a natural fit for the bit-level protocol, so I'm
looking for an SBC and Linux OS with natural HDLC support. Ideally the SBC
would fit in a 3"x3"x1" volume, and include Ethernet. It will go on a
backplane along with the motion control box.
The Freescale chips look like many have the hardware to do HDLC, so I'm
wondering what's available for boards and drivers.
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: David Gibson @ 2007-11-20 0:33 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <4741BA7D.10608@genesi-usa.com>
On Mon, Nov 19, 2007 at 04:31:57PM +0000, Matt Sealey wrote:
> David Gibson wrote:
> > On Sun, Nov 18, 2007 at 11:31:13PM +0000, Matt Sealey wrote:
> >
> > Gah! For the benefit of others on this list who may be misled.
> >
> > *Neither* of you correctly understands the device tree, what I've seen
> > of *both* your suggested approaches is crap.
> >
> > The device tree describes the _hardware_. If you start reasoning
> > about how to lay out the device tree based on your driver model,
> > you're already wrong.
> >
> > Matt, the various properties you list do not mean what you think they
> > mean.
>
> No, David, I understand exactly what they mean, in the context of a
> guy who works on Open Firmware, real Open Firmware, as was
> standardised 12 years ago.
No, you really don't. Either your knowledge of OF is out of date, or
you've forgotten what you thought you knew.
> Not your whacky newspeak device trees, which to be fair, are a good
> idea, but it seems you all have tried to change something for the
> sake of changing something.
With a couple of tiny exceptions, everything I've said applies equally
to real OF trees.
[snip]
> > device_type - indicates the open firmware method interface for the
> > device. Therefore, meaningless in flattened trees. No new driver
> > should use this.
>
> .. you seem to think you must only design for the guys making Linux
> flattened device trees. I'm sorry, but I am not one of those guys and
> I am much more concerned with how this will affect the OF device tree
> and the usage for anyone else.
No, which is exactly why it's wrong to organize the device tree so
that it's convenient for loading this "fabric driver" thing (which
AFAICT is a Linux-specific driver model limitation).
> Meaningless in flattened device trees, but useful information in real
> OF device trees, do you implement it or not? I'd say, yes. Even if
> you don't agree with "real firmware", you can't just ignore it, shrug
> it away and say it doesn't matter.
Useful information in a real OF tree *if* an OF runtime interface for
the device is defined and implemented.
[snip]
> > compatible - *this* is the one for driver selection. It describes the
> > hardware level interface(s) of the device.
>
> Compatible is meant to list alternative, compatible devices as a
> *supplement* to device_type. device_type is your "primary" and
> compatible is your "secondary". In this case, device_type is
> exactly what Jon wants, something to mark out that the audio device
> is his board design and requires special work (it is not merely an
> i2s bus that you can just "use" - although throwing PCM data at it
> would work, who knows what mixer it goes to, and what controls are
> needed to define the bitrate or other features)
No, as Segher explains, that's Just Plain Wrong. Originally "name"
did perform the function you think device_type had. But the generic
names convention, which has been very well established for a long time
now means that the register-level (or equivalent) programming
interface is described by "compatible". Period.
> > model - usually just for debugging / diagnosis / human-readable
> > purposes, describes exact model / revision of the hardware. It can be
> > used to enable driver quirks / workarounds for when various devices
> > are supposed to be compatible (as encoded in 'compatible') but
> > aren't, due to hardware bugs. However, you should never aim to use it
> > this way in design.
>
> I don't see why "model" can't encode the particular revision of the
> hardware in this way when it comes to the audio group of features on
> his board. After all, if you are looking at a "digispeaker,flinger"
> (I made that name up) then you need to know depending on the board
> or even based on weird configurability options of the board, what
> certain things may be - Apple used layout-id and a number. Why NOT
> encode the "model" in the "model"?
>
> Why choose some magical, new property, which then has to be further
> standardised for no reason?
>
> I also think that specifying an audio codec - after all the Open
> Firmware standard defines an audio interface and device tree
> requirements for it, even if they are methods that we don't
> implement and you don't care about - as a function of it's
> control interface is so backwards it doesn't bare thinking about.
Sure, it's fine for a firmware to implement the OF method interface
and put in the relevant device_type for audio in the appropriate place
(although with complex sound systems with many components, the right
place may be non-obvious or even not well defined). It's *not* fine
to make up random new device_type values because you think it's
convenient.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: David Gibson @ 2007-11-20 0:22 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: PowerPC dev list
In-Reply-To: <f334e85d77c624ef0112437a4049a3cd@kernel.crashing.org>
On Mon, Nov 19, 2007 at 01:48:40PM +0100, Segher Boessenkool wrote:
> > Matt, the various properties you list do not mean what you think they
> > mean.
> >
> > name - should be named according to the generic names convention.
> > It's pretty much arbitrary, meant for human readability of the device
> > tree. Drivers should not depend on it (some do, historically, but new
> > drivers and trees should not).
>
> It is not arbitrary, there is a single well-defined name for every
> common
> "class" of device. It _is_ machine-readable (but shouldn't be used for
> driver matching, indeed -- it says nothing about the programming model).
Sorry, that was an (over?) simplification on my part. Yes, there are
conventions as to what devices should be called by class (usually, but
not universally observed), yes they can be used machine-readable under
some circumstances.
My point is that since driver matching is *not* done off name, and
machine-readable uses are not common, the name tends not to matter
very much. Plus if an incorrect name is used, it's usually not too
bad to fix.
> > device_type - indicates the open firmware method interface for the
> > device.
>
> Not "method interface", just "interface".
Right, I say "method interface" just to emphasise the fact that we're
talking about the runtime OF-call interface, rather than
register-level or other programming interface.
> > Therefore, meaningless in flattened trees.
>
> Even in flat trees, a "device_type" of for example "block" indicates the
> node will have the required properties for that device type, for example
> "block-size". Such properties are perfectly useful. OTOH, it isn't
> very
> useful to search for device with a specific device type from within the
> kernel, since it currently has no firmware interaction to speak of (flat
> trees don't interact, and the kernel kills "real" OF dead as soon as
> possible).
Uh... it was you who convinced me that device_type was not appropriate
for new flat-tree devices.
> > No new driver should use this.
>
> Not without very good rationalisation, anyway.
>
> > compatible - *this* is the one for driver selection. It describes the
> > hardware level interface(s) of the device.
> >
> > model - usually just for debugging / diagnosis / human-readable
> > purposes, describes exact model / revision of the hardware. It can be
> > used to enable driver quirks / workarounds for when various devices
> > are supposed to be compatible (as encoded in 'compatible') but
> > aren't, due to hardware bugs. However, you should never aim to use it
> > this way in design.
>
> Yeah. Any non-workaround value a driver would derive from "model" is
> usually better described using a separate property.
Well, yes, if the need for the workaround is known when the device
tree is created. But by their nature workarounds tend not to be
planned, so from the driver's perspective it's legitimate to use *any*
reliable-in-practice information to activate a workaround (even if
it's not reliable in theory, if there's no other option). That
includes both everything in the device tree, and any information the
driver can probe from the hardware.
My point above is that iIt's reasonably common in such cases for
"model" to be a decent choice.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: 2.6 kernel hangs after loading device tree
From: abhi_linux @ 2007-11-20 0:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa84b3da0708290938l40d8f543oc0e34fa9bea806a4@mail.gmail.com>
Hello
Did u get a solution to this? I have similar issues. How do u enable
debugging in UBoot?
Thanks
charanya venkatraman wrote:
>
> Hi all
> Sorry about the previous mail.Got sent by mistake.
>
> Iam using the 2.6.22.5 kernel on MPC 8560 and MPC8540 on my custom
> board.Mykernel hangs after loading the device tree in both the
> processors .There is
> no output on the serial port after loading the device tree.Am using U-boot
> 1.2.0 as the bootloader.After enabling debug in u-boot i could see that
> the
> control is getting transferred to the kernel after which it hangs.Earlier
> i
> tried using 2.6.21 which also hangs at the same point.The config files
> used
> were MPC8540ADS_defconfig and MPC8560ADS_defconfig under powerpc
> directory.
> The changes that were made to the device tree are:
> 1.The reg and ranges properties of the soc node have been changed to
> account
> for the change in CCSRBAR of my board.
> 2.Removed the PCI,mdio nodes and ethernet nodes since i dont need support
> for these as of now.
>
> I have tried the following console arguments:
> MPC8540: bootargs root=/dev/ram rw console=ttyS0,115200
> MPC8560:bootargs root=/dev/ram rw console=ttyCPM0,115200
>
> Any help on this issue??
>
> Thanks.
> Charanya.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
View this message in context: http://www.nabble.com/2.6-kernel-hangs-after-loading-device-tree-tf4348921.html#a13848328
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Kim Phillips @ 2007-11-19 23:36 UTC (permalink / raw)
To: Li Yang, Kumar Gala, netdev, linuxppc-dev, paulus, jgarzik
In-Reply-To: <20071105121530.5c38fbb7.kim.phillips@freescale.com>
On Mon, 5 Nov 2007 12:15:30 -0600
Kim Phillips <kim.phillips@freescale.com> wrote:
> Hello all,
>
> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> according to erratum #2 (erratum text included below). Basically the
> most intrusive part is the addition of two new RGMII Internal Delay
> modes; one for TX delay only, and the other for RX delay only (i.e, not
> both at the same time).
>
> Please review, and since this affects both netdev and powerpc trees,
> one maintainer should ack them for the other to push upstream (i.e,
> Kumar acks them, and Leo picks them up to go through netdev or the
> other way around; either way is fine with me). I'm hoping they're
> trivial enough to go in 2.6.24.
>
Kumar, Leo,
re-ping due to (a) it's been 2 weeks and (b) Anton Vorontsov has since
issued his Tested-by.
Might I suggest Kumar ack the powerpc patches, and Leo/Jeff apply 5/5
to go through netdev?
Kim
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Christoph Lameter @ 2007-11-19 22:50 UTC (permalink / raw)
To: root
Cc: Trond Myklebust, Peter Zijlstra, LKML, Torsten Kaiser,
Kamalesh Babulal, linuxppc-dev, nfs, Ingo Molnar, Jan Blunck,
Andrew Morton, Balbir Singh
In-Reply-To: <20071117230049.GA25905@dyad>
On Sun, 18 Nov 2007, root wrote:
> @@ -2155,6 +2155,7 @@ static struct kmem_cache_node *early_kme
> {
> struct page *page;
> struct kmem_cache_node *n;
> + unsigned long flags;
>
> BUG_ON(kmalloc_caches->size < sizeof(struct kmem_cache_node));
>
Well local_irq_save is a bit of an overkill. We know that interrupts are
enabled during this phase of the boot sequence.
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-19 22:37 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <4741BDA7.8020106@freescale.com>
On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
>
> > Now how do I pick which fabric driver to initialize?
>
> I'm doing it via a Kconfig option. For ASoC V1, I think that's the only way
> that works.
I believe that is your only choice on v1. V1 is not set up to
correctly handle for device trees. It is fixed in v2 except for the
problem with how to load the fabric; no one has address that problem
yet. The sound portion of the code is pretty much the same between v1
and v2, it is all the driver setup code that has been reworked.
>
>
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Please pull from 'for-2.6.24' branch of 4xx tree
From: Josh Boyer @ 2007-11-19 21:26 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.24
to pick up a few bug fixes for 2.6.24. The AC97 change is fairly
harmless and is required to get AC97 working on Virtex boards.
josh
Joachim Foerster (1):
[POWERPC] Xilinx: Register AC97 Controller Reference with the platform bus
Jon Loeliger (1):
[POWERPC] 4xx: Replace #includes of asm/of_platform.h with linux/of_platfo
Josh Boyer (1):
[POWERPC] 4xx: Use virtual PVR value to init FPU on arch/ppc 440EP
Roel Kluin (1):
[POWERPC] 4xx: balance ioremap/ioumap calls for Yucca
Valentine Barshak (1):
[POWERPC] 4xx: UIC add mask_ack callback
arch/powerpc/platforms/40x/walnut.c | 3 ++-
arch/powerpc/platforms/44x/bamboo.c | 3 ++-
arch/powerpc/platforms/44x/ebony.c | 3 ++-
arch/powerpc/platforms/44x/sequoia.c | 3 ++-
arch/powerpc/sysdev/uic.c | 18 +++++++++++++++++-
arch/ppc/kernel/setup.c | 7 +++++++
arch/ppc/platforms/4xx/yucca.c | 1 +
arch/ppc/syslib/virtex_devices.c | 31 +++++++++++++++++++++++++++++++
8 files changed, 64 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: Problem with uboot on lite5200
From: Wolfgang Denk @ 2007-11-19 21:13 UTC (permalink / raw)
To: Clemens Koller; +Cc: Leo Hendrawan, linuxppc-embedded
In-Reply-To: <47403C73.9040506@anagramm.de>
In message <47403C73.9040506@anagramm.de> you wrote:
>
> How should people get a glue what's current, when in the section
> "Latest News" at http://sourceforge.net/projects/u-boot/ the people
> still find a more or less official looking "u-boot-1.1.5" release.
Maybe by reading the very first two lines on the SF page:
...
NOTE: current source code is available from DENX git
repository and FTP server; see http://www.denx.de/en/Software/GIT
or by looking at the project page http://u-boot.sourceforge.net/ which
redirects you to http://www.denx.de/wiki/UBoot which has all the
significant information?
The problem is that you cannot really "shut down" a SourceForge
project (please correct me if I'm wrong).
> (And they don't want to use scm repositories because they are afraid
> of using anything unstable.)
I guess there is no real cure for this. [Same people will happily
download any temproray test version from a FTP server, though.]
> > Current U-Boot is 1.3.0-rc4. Please wake up.
>
> Well... maybe it's better to remove all references to the old
> releases at sourceforge and point them to ftp://ftp.denx.de/pub/u-boot/
Can you please teach me how to do that?
> instead. Btw. 1.3.0-rc4 isn't there as well. :-P
Indeed. But there is a "snapshot" link on the gitweb page...
And 1.3.0 will be out in less than 2 hours from now :-)
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I am an atheist, thank God!
^ permalink raw reply
* Re: Problem with 64-bit variables on ppc405
From: David Hawkins @ 2007-11-19 20:46 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-embedded
In-Reply-To: <13844837.post@talk.nabble.com>
Hi Mirek,
> Doubles and long long are 8 bytes long but the byte order differs
> on my host linux Intel PC from this what I have on the target
> linux ppc 405.
That would be due to the difference in endianness of the
processors.
http://en.wikipedia.org/wiki/Endianness
If you want to work on data on both an Intel machine, and a
PowerPC, then you have to transfer the data between the machines
using a machine-independent binary format.
There are several around:
1. Network byte order = big-endian.
2. XDR
http://en.wikipedia.org/wiki/External_Data_Representation
used by NFS,
3. Common Data Representation
http://en.wikipedia.org/wiki/Common_Data_Representation
Which is implemented in the ACE C++ library.
The nice thing about CDR is that the 'reader makes right',
so its only when the endianness of the reader is different
that it has to use CPU cycles to reformat the data.
Its not only processors that have subtle endian issues.
I use little-endian x86 host CPUs in a little-endian PCI
backplane talking to big-endian PowerPC processors.
Data transferred between the processors is first encoded
into a CDR data stream and then decoded. I write binary
data files using the same stream formatters, and then
use mex routines written in C++ to pull the data into
MATLAB data structures.
MATLAB data files are also an example of a machine independent
binary format. But I don't use them.
Cheers,
Dave
^ permalink raw reply
* Problem with 64-bit variables on ppc405
From: Mirek23 @ 2007-11-19 20:37 UTC (permalink / raw)
To: linuxppc-embedded
Dear All,
I have successfully build crosstools (gcc-4.0.2-glibc-2.3.2) for my ppc 405
processor (part of xilinx virtex-4). I have compiled the Linux kernel
2.6.23rc2 and busy box 1.4.2.
All together works fin but I am facing the problem with the variables
declared in C as double and long long.
Doubles and long long are 8 bytes long but the byte order
differs on my host linux Intel PC from this what I have on the target linux
ppc 405.
double , long long byte order looks like below:
linux intel x86 ppc405
1,2,3,4,5,6,7,8 5,6,7,8,1,2,3,4
int and long types in 'C' (4 byte variables) have the same byte order on
both platforms.
It seems to be that 64-bit variables have different order. I do not know if
it comes from:
1. the configuration of the crosstools (ie. the way how the gcc and glibc is
built)
2. the kernel configuration.
The ppc 405 does not have the FPU built in so I have set in the kernel:
processor->math emulation
I did not set anything concerning FPU in Crosstools.
The Crosstools configuration file demo-powerpc-405.sh looks like:
#!/bin/sh
# This script has one line for each known working toolchain
# for this architecture. Uncomment the one you want.
# Generated by generate-demo.pl from buildlogs/all.dats.txt
set -ex
TARBALLS_DIR=$HOME/downloads
RESULT_TOP=/opt/crosstool
export TARBALLS_DIR RESULT_TOP
GCC_LANGUAGES="c,c++"
export GCC_LANGUAGES
# Really, you should do the mkdir before running this,
# and chown /opt/crosstool to yourself so you don't need to run as root.
mkdir -p $RESULT_TOP
eval `cat powerpc-405.dat gcc-4.0.2-glibc-2.3.2.dat` sh all.sh --notest
Does anybody have an idea how to sort out this problem to have byte order
for
64-bit variables on ppc405 the same as for linux on intel x86.
Best Regards
Mirek
--
View this message in context: http://www.nabble.com/Problem-with-64-bit-variables-on-ppc405-tf4839313.html#a13844837
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Fix 8xx build breakage due to _tlbie changes
From: Benjamin Herrenschmidt @ 2007-11-19 19:50 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071119060623.67387f2c@vader.jdub.homelinux.org>
> > Index: linux-work/arch/powerpc/mm/mmu_decl.h
> > ===================================================================
> > --- linux-work.orig/arch/powerpc/mm/mmu_decl.h 2007-11-15 14:09:16.000000000 +1100
> > +++ linux-work/arch/powerpc/mm/mmu_decl.h 2007-11-15 14:14:29.000000000 +1100
> > @@ -56,7 +56,7 @@ extern unsigned long total_lowmem;
> > * architectures. -- Dan
> > */
> > #if defined(CONFIG_8xx)
> > -#define flush_HPTE(X, va, pg) _tlbie(va)
> > +#define flush_HPTE(X, va, pg) _tlbie(va, 0, /* 8xx doesn't care about PID */)
>
> Spurious ','?
Weird, it did build ...
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 1/9] powerpc: Make isa_mem_base common to 32 and 64 bits
From: Benjamin Herrenschmidt @ 2007-11-19 19:49 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20071119103254.GA19708@lst.de>
On Mon, 2007-11-19 at 11:32 +0100, Christoph Hellwig wrote:
> On Mon, Nov 19, 2007 at 07:25:00PM +1100, Benjamin Herrenschmidt wrote:
> > +/* ISA Memory physical address (or 0 if none) */
> > +resource_size_t isa_mem_base = 0;
>
> No need to initialize this.
True. I copy/pasted as-is but you are right, I can remove the
initializer.
Ben.
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Grant Likely @ 2007-11-19 19:28 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <9e4733910711191120l45d9257bwf4ccf8c7365393d0@mail.gmail.com>
On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > You might be stuck with using either a platform_device or an
> > of_platform_device as a stepping stone to creating the device on the
> > ALSA fabric driver.
>
> I also concluded that I need a of_platform stepping stone.
>
> There are several ways this could be done, which one is the right one?
> a) fabric is global, create a global device node for it and implement
> it as a of_platform device
This is really board level description stuff. I'd make the node
global off the root myself and use whatever linkage you think
appropriate to get you to the codec nodes (phandle's most likely)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-19 19:20 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40711190933r3cbeb51bw7b9073a40f8396ed@mail.gmail.com>
On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > > On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> > > > > > Jon Smirl wrote:
> > > > > >
> > > > > > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > > > > > A fabric driver tells specifically how a generic codec is wired into
> > > > > > > the board. What I haven't been able figure out is how to load the
> > > > > > > right fabric driver.
> > > > > >
> > > > > > Do not use the device tree to load the fabric driver!
> > > > >
> > > > > Heh, technically you can't use the device tree to load any device
> > > > > drivers, it's just a data structure. :-)
> > > > >
> > > > > You probably mean "don't use the of_platform bus to load the fabric
> > > > > driver". He still needs to use the data in the device tree to decide
> > > > > what fabric drivers to use. of_platform_bus would be awkward to use
> > > > > for this because the node describing the fabric doesn't cleanly sit on
> > > > > any particular bus (ie. it describes the board; it does not describe
> > > > > the device).
> > > > >
> > > > > In this case; it probably is appropriate to have the platform code
> > > > > instantiate a platform_device for the fabric (instead of an
> > > > > of_platform device) which the fabric driver can bind against.
> > > >
> > > > First, I have platform bus turned off in my builds. Platform bus is a
> > > > place where cruft accumulates that really belongs somewhere else. For
> > > > example when I turned it off I discovered that there was a PC speaker
> > > > driver in my kernel and well as several drivers from 82xx chips.
> > > >
> > > > ALSA creates it own bus like i2c. My fabric driver sits on this bus.,
> > > > Kconfig attributes control if it is built-in. I've altered the i2c
> > > > code to look for child device tree nodes and then load the appropriate
> > > > drivers.
> > >
> > > Can't you then instantiate the ALSA bus device in your board platform
> > > code? Then when the driver is registered, the bus should call it's
> > > probe routine.
> >
> > Yes, I can do that. I have just been resisting creating a code linkage
> > from arch/powerpc/platform/xx to sound/alsa/soc/powerpc. I also need
> > to create the fabric driver after alsa has made the bus,
> > subsys_initcall(asoc_bus_init);
>
> Hmmm, you could add a drivers_initcall to the platform code, but that
> only works if the ALSA code is compiled statically. It doesn't work
> for modules. :-(
>
> You might be stuck with using either a platform_device or an
> of_platform_device as a stepping stone to creating the device on the
> ALSA fabric driver.
I also concluded that I need a of_platform stepping stone.
There are several ways this could be done, which one is the right one?
a) fabric is global, create a global device node for it and implement
it as a of_platform device
b) fabric is per audio bus, make it an attribute or child node under
i2s, ac97, spi. This is messy since it can appear in many places. This
is the apple layout-id scheme.
c) fabric is per codec entry. make it an attribute or child node under
the codec node.
d) after I load the codec node, walk up the device tree to the root
node and then use the compatible string in the root node to trigger
the specific fabric driver. This one avoids making obviously redundant
attributes down lower in the tree.
I need things to initialize in this order. All of these can be modules.
1) alsa subsystem
2) i2c ac97 bus
3) codec driver
4) fabric - it then glues everything together in alsa.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 4/21] ide/Kconfig: fix mpc8xx host driver dependencies
From: Sergei Shtylyov @ 2007-11-19 18:58 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <200711182315.19408.bzolnier@gmail.com>
Bartlomiej Zolnierkiewicz wrote:
> Only LWMON, IVMS8, IVML24 and TQM8xxL platforms have the needed
> defines (IDE0_BASE_OFFSET and friends) in the platform header file.
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
MBR, Sergei
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Grant Likely @ 2007-11-19 18:55 UTC (permalink / raw)
To: Scott Wood; +Cc: PowerPC dev list
In-Reply-To: <20071119170521.GA4368@loki.buserror.net>
On 11/19/07, Scott Wood <scottwood@freescale.com> wrote:
> On Mon, Nov 19, 2007 at 04:31:57PM +0000, Matt Sealey wrote:
> > I never said drivers should depend on it but why do you want to name
> > an i2s bus as "i2s" or the i2c bus as "i2c"?
>
> Because that's what they are?
>
> > There are far, far more descriptive names that can be used. i2s is
> > basically audio, so why not "audio" or "sound" or "headphone"?
>
> For i2s, that may be reasonable, but i2c can have several devices under it.
>
> > Why is gpt a "gpt" and not a "timer", it defeats the whole object
> > of having a name for it. Since drivers never switch on it, why not
> > give them real names?
>
> That one *should* be timer. Ask whoever did the device tree for it. :-P
That one's my fault.
sorry.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: [PATCH] Xilinx TEMAC driver
From: Koss, Mike (Mission Systems) @ 2007-11-19 18:07 UTC (permalink / raw)
To: John Williams, Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <47392A2A.7020200@itee.uq.edu.au>
>> On 7/24/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>>=20
>>> Hopefully this is not too much of a mess.
>> Hooray! Thanks for posting your work. I'm keen to try this on my=20
>> platform. Comments below.
>>=20
> [snip]
> Any progress on the ll_temac driver since July? In EDK9.2, ll_temac
is really the only supported ethernet solution, apart from ethernet lite
(yuck).
> If there's a PPC version in a reasonable state, i'm happy to see
what's requierd to port it across to MicroBlaze.
> cheers,
> John
John,
I have a ll_temac for CDMAC version that I made for >2.6.19 that used
the old wrapper from a MontaVista 2.4 kernel. It was tested (not overly
stressed) and working at speeds > 100Mb. I plan on moving it to a
unified source once I had a LocalLink TEMAC that would support my
hardware. Xilinx did not support ll_temac w/ RGMII or SGMII which are
both found on the ML410 for Gigabit.
I currently use David's driver with much success now for the plb_temac.
I have a modified version that has been mostly cleaned up. I did remove
the ll stuff since it was for a Pico(??) LocalLink TEMAC that I could
not find, and not the Xilinx LocalLink TEMAC w/ CDMAC, which is what I
was interested in. If interested, I could finish the clean-up on it and
post a patch for it (once I figure out how to actually make the patch
:P). Right now what mainly remains is finish grouping the functions for
FIFO and starting support for DMA.
-- Mike
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Torsten Kaiser @ 2007-11-19 18:24 UTC (permalink / raw)
To: Andrew Morton
Cc: Jan Blunck, Peter Zijlstra, steved, LKML, Kamalesh Babulal,
linuxppc-dev, nfs, Ingo Molnar, Trond Myklebust, Balbir Singh
In-Reply-To: <20071119010002.9387d36b.akpm@linux-foundation.org>
On Nov 19, 2007 10:00 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Mon, 19 Nov 2007 08:15:48 +0100 "Torsten Kaiser" <just.for.lkml@googlemail.com> wrote:
> > On Nov 18, 2007 8:18 PM, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> > > I had already fixed that one in my own stack. Attached are the 3 patches
> > > that I've got. 1 from SteveD, 2 fixes.
> >
> > Moving the init_waitqueue_head() like patch
> > linux-2.6.24-006-fix_to_fix_sillyrename_bug_on_umount.dif and applying
> > linux-2.6.24-007-fix_nfs_free_unlinkdata.dif lets my testcase work.
> > Also lockdep no longer complains about the non-static key.
>
> Thanks.
>
> To avoid goofups, could you please send the full fix against 2.6.24-rc2-mm1?
Umm... As I applied this changes manually there is a not insignificant
change of goofups on my part...
For the hang problem I think Tronds suggestion with replacing the
patches from -mm with fresh versions would be the best.
Anyway, currently I have the patch from
http://lkml.org/lkml/2007/11/16/74 to fix the can't-create-files-bug.
To fix the hang bug I used Tronds
linux-2.6.24-007-fix_nfs_free_unlinkdata.dif and the first two hunks
from linux-2.6.24-006-fix_to_fix_sillyrename_bug_on_umount.dif.
Torsten
The needed 2 hunks for reference:
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -594,9 +594,6 @@ static int nfs_init_server(struct nfs_server *server,
/* Create a client RPC handle for the NFSv3 ACL management interface */
nfs_init_server_aclclient(server);
- init_waitqueue_head(&server->active_wq);
- atomic_set(&server->active, 0);
-
dprintk("<-- nfs_init_server() = 0 [new %p]\n", clp);
return 0;
@@ -736,6 +733,9 @@ static struct nfs_server *nfs_alloc_server(void)
INIT_LIST_HEAD(&server->client_link);
INIT_LIST_HEAD(&server->master_link);
+ init_waitqueue_head(&server->active_wq);
+ atomic_set(&server->active, 0);
+
server->io_stats = nfs_alloc_iostats();
if (!server->io_stats) {
kfree(server);
^ permalink raw reply
* Re: hangs after "Freeing unused kernel memory"
From: Linas Vepstas @ 2007-11-19 17:51 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D7F73FC8@corpexc01.corp.networkrobots.com>
On Thu, Nov 15, 2007 at 04:00:09PM -0800, Siva Prasad wrote:
> Hi,
>
> This sounds like a familiar problem, but could not get answers in posts
> that came up in google search.
>
> My system hangs after printing the message "Freeing unused kernel
> memory". It should execute init after that, but not sure what exactly is
> happening. Appreciate if some one can throw few ideas to try out.
It might not be a hang, it might be simply that you loose the console.
If this is a redhat system, and you didn't tweak initrd and udev just
right, this can happen.
Try doing this:
mount --bind / /mnt
cp -a /dev/null /mnt/dev
cp -a /dev/console /mnt/dev
cp -a /dev/hv* /mnt/dev
umount /mnt
> Seems it is actually hanging when it makes the call "
> run_init_process(ramdisk_execute_command)" in init/main.c
Then again, your initrd might be corrupted.
--linas
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Grant Likely @ 2007-11-19 17:33 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <9e4733910711190851g3e1f2ef9k5f87c7c2dae929ef@mail.gmail.com>
On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> > > > > Jon Smirl wrote:
> > > > >
> > > > > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > > > > A fabric driver tells specifically how a generic codec is wired into
> > > > > > the board. What I haven't been able figure out is how to load the
> > > > > > right fabric driver.
> > > > >
> > > > > Do not use the device tree to load the fabric driver!
> > > >
> > > > Heh, technically you can't use the device tree to load any device
> > > > drivers, it's just a data structure. :-)
> > > >
> > > > You probably mean "don't use the of_platform bus to load the fabric
> > > > driver". He still needs to use the data in the device tree to decide
> > > > what fabric drivers to use. of_platform_bus would be awkward to use
> > > > for this because the node describing the fabric doesn't cleanly sit on
> > > > any particular bus (ie. it describes the board; it does not describe
> > > > the device).
> > > >
> > > > In this case; it probably is appropriate to have the platform code
> > > > instantiate a platform_device for the fabric (instead of an
> > > > of_platform device) which the fabric driver can bind against.
> > >
> > > First, I have platform bus turned off in my builds. Platform bus is a
> > > place where cruft accumulates that really belongs somewhere else. For
> > > example when I turned it off I discovered that there was a PC speaker
> > > driver in my kernel and well as several drivers from 82xx chips.
> > >
> > > ALSA creates it own bus like i2c. My fabric driver sits on this bus.,
> > > Kconfig attributes control if it is built-in. I've altered the i2c
> > > code to look for child device tree nodes and then load the appropriate
> > > drivers.
> >
> > Can't you then instantiate the ALSA bus device in your board platform
> > code? Then when the driver is registered, the bus should call it's
> > probe routine.
>
> Yes, I can do that. I have just been resisting creating a code linkage
> from arch/powerpc/platform/xx to sound/alsa/soc/powerpc. I also need
> to create the fabric driver after alsa has made the bus,
> subsys_initcall(asoc_bus_init);
Hmmm, you could add a drivers_initcall to the platform code, but that
only works if the ALSA code is compiled statically. It doesn't work
for modules. :-(
You might be stuck with using either a platform_device or an
of_platform_device as a stepping stone to creating the device on the
ALSA fabric driver.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Scott Wood @ 2007-11-19 17:05 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <4741BA7D.10608@genesi-usa.com>
On Mon, Nov 19, 2007 at 04:31:57PM +0000, Matt Sealey wrote:
> I never said drivers should depend on it but why do you want to name
> an i2s bus as "i2s" or the i2c bus as "i2c"?
Because that's what they are?
> There are far, far more descriptive names that can be used. i2s is
> basically audio, so why not "audio" or "sound" or "headphone"?
For i2s, that may be reasonable, but i2c can have several devices under it.
> Why is gpt a "gpt" and not a "timer", it defeats the whole object
> of having a name for it. Since drivers never switch on it, why not
> give them real names?
That one *should* be timer. Ask whoever did the device tree for it. :-P
> > device_type - indicates the open firmware method interface for the
> > device. Therefore, meaningless in flattened trees. No new driver
> > should use this.
>
> .. you seem to think you must only design for the guys making Linux
> flattened device trees. I'm sorry, but I am not one of those guys and
> I am much more concerned with how this will affect the OF device tree
> and the usage for anyone else.
>
> Meaningless in flattened device trees, but useful information in real
> OF device trees, do you implement it or not? I'd say, yes.
Yes, if you have real OF and provide the corresponding method interface.
That doesn't mean the driver should match on it if it doesn't depend on the
method interface.
> > compatible - *this* is the one for driver selection. It describes the
> > hardware level interface(s) of the device.
>
> Compatible is meant to list alternative, compatible devices as a
> *supplement* to device_type. device_type is your "primary" and
> compatible is your "secondary".
No, please read the spec:
“compatible”
Standard property name to define alternate “name” property values.
No mention of device_type anywhere in the definition.
The generic names recommendation further suggests that compatible always be
used for matching.
> I don't see why "model" can't encode the particular revision of the
> hardware in this way when it comes to the audio group of features on
> his board. After all, if you are looking at a "digispeaker,flinger"
> (I made that name up) then you need to know depending on the board
> or even based on weird configurability options of the board, what
> certain things may be - Apple used layout-id and a number. Why NOT
> encode the "model" in the "model"?
>
> Why choose some magical, new property, which then has to be further
> standardised for no reason?
"compatible" is not a magical, new property. I'm not going to defend what
Apple did...
> I also think that specifying an audio codec - after all the Open
> Firmware standard defines an audio interface and device tree
> requirements for it, even if they are methods that we don't
> implement and you don't care about - as a function of it's
> control interface is so backwards it doesn't bare thinking about.
It's how the device tree works. Devices go underneath the bus (or other
attachment interface) that they're on. If you have an audio codec that has
an i2c interface and an soc interface, then you have two nodes, because
you're on two buses.
> If you want to output audio you do it through most audio
> controllers as a simple transfer of PCM data. Be it Creative
> or Freescale I2S or AC97, you push data at some port/fifo
> and it plays a sound. It is NOT defined by i2c control ports,
> you don't ever use those to *play* audio.
You certainly do use the i2c ports in order to do anything with the device
underneath the i2c bus.
> It may also be very, very true that a codec DOES NOT REQUIRE
> implementation of it's control interface, or that control interface could
> be connected to some other chip which handles initial configuration (like
> a boot sequencer eeprom) and not to a system bus.
Sure... in that case, then that's *not the bus it's on*. There's still some
register set somewhere that software uses to shove data at the codec; that's
where the node should go.
-Scott
^ permalink raw reply
* Re: Oops: of_platform_serial_probe
From: Arnd Bergmann @ 2007-11-19 16:56 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <474193B8.9060007@anagramm.de>
On Monday 19 November 2007, Clemens Koller wrote:
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xc018f03c
> Oops: Kernel access of bad area, sig: 11 [#1]
> MPC85xx ADS
> Modules linked in:
> NIP: c018f03c LR: c018f00c CTR: c00127b4
> REGS: c0821cf0 TRAP: 0300 =A0 Not tainted =A0(2.6.24-rc2-ge6a5c27f)
> MSR: 00029000 <EE,ME> =A0CR: 42022088 =A0XER: 20000000
> DEAR: 00000000, ESR: 00000000
> TASK =3D c081e000[1] 'swapper' THREAD: c0820000
> GPR00: b1000000 c0821da0 c081e000 c0833e10 00000004 c0821d80 c03d3064 c05=
eea80
> GPR08: 00000200 00000002 0000002a 13ab6680 82022042 00000000 c03318a4 c03=
3188c
> GPR16: c0331908 c03318f0 c03a0e30 c0331930 c033191c 007fff00 0ffeccbc c03=
a0000
> GPR24: c0821dc4 00000000 00000003 c0934cf8 cffffba8 00000000 c0833e00 c07=
fdc6c
> NIP [c018f03c] of_platform_serial_probe+0x118/0x1e4
> LR [c018f00c] of_platform_serial_probe+0xe8/0x1e4
> Call Trace:
Ok, that is a NULL pointer access, probably somewhere in the
of_platform_serial_setup that can be inlined. Please post the
device tree entries for your serial ports so we can see what
goes wrong there.
One potential problem that I can see is a missing 'current-speed'
property in your tree, which would cause this behavior. It looks
like many device trees set this, but it is not required by all
bindings. If that's the case, the patch below should fix your
problem, but you probably want to set the current-speed anyway,
according to your boot loader settings.
Arnd <><
=2D-- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -56,7 +56,8 @@ static int __devinit of_platform_serial_setup(struct of_d=
evice *ofdev,
port->flags =3D UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
| UPF_FIXED_PORT;
port->dev =3D &ofdev->dev;
=2D port->custom_divisor =3D *clk / (16 * (*spd));
+ if (spd)
+ port->custom_divisor =3D *clk / (16 * (*spd));
return 0;
}
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox