* Re: 'make ARCH=ppc defconfig' failing for cross-compile
From: Michael Ellerman @ 2006-09-14 3:12 UTC (permalink / raw)
To: Judith Lebzelter; +Cc: linuxppc-dev
In-Reply-To: <20060912174814.GA29226@shell0.pdx.osdl.net>
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
On Tue, 2006-09-12 at 10:48 -0700, Judith Lebzelter wrote:
> On Tue, Sep 12, 2006 at 10:21:46AM -0700, Christian wrote:
> > On Fri, 8 Sep 2006, Judith Lebzelter wrote:
> > > I have been doing cross-compiles for ppc and powerpc on my i686 system.
> > > In order to do this I generate the .config file like this:
> > >
> > > make ARCH=ppc defconfig
> > > (or make ARCH=powerpc defconfig)
> >
> > Seems like defconfig has been removed, because there are so many
> > sub-platforms for ppc:
>
> I build these in OSDL's cross compile build farm (PLM) as a code check.
> Our scripts are generalized to work for various architectures, so it is
> disappointing that 'defconfig' no longer works for ppc the way it does
> in other achitectures. Are there plans to make plain 'defconfig' work
> again, at least in the new 'powerpc' directory? (The 'ppc64_defconfig'
> target looks good to me.:)
Perhaps you need to rework the scripts to cope for the fact that there
are different platforms under the architecture? There will never be a
defconfig for powerpc that builds all the code for all platforms, so to
get full test coverage you'll need to build more than one config anyway.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* vanamali invites you to join Zorpia
From: vanamali @ 2006-09-14 4:40 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 784 bytes --]
Hi linuxppc-embedded!
Your friend vanamali from Bangalore India, just invited you to his online photo albums and journals at Zorpia.com.
So what is Zorpia?
It is an online community that allows you to upload unlimited amount of photos, write journals and make friends. We also have a variety of skins in store for you so that you can customize your homepage freely.
Join now for free! Please click the following link to join Zorpia:
http://www.zorpia.com/cgi/signup.cgi?invitation_key=9256bcc0a8c38008263d30b9603f6cda&referral=mail2gvs
This message was delivered with the vanamali's initiation.
If you wish to discontinue receiving invitations from us, please click the following link:
http://www.zorpia.com/cgi/signup.cgi?action=optout&email=linuxppc-embedded@ozlabs.org
[-- Attachment #2: Type: text/html, Size: 6106 bytes --]
^ permalink raw reply
* [POWERPC] iseries: eliminate a couple of warnings
From: Stephen Rothwell @ 2006-09-14 5:00 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Copy and paste bug in io.h
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/asm-powerpc/io.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
index 212428d..e235025 100644
--- a/include/asm-powerpc/io.h
+++ b/include/asm-powerpc/io.h
@@ -74,8 +74,8 @@ #define outl(data,addr) writel(data,((v
* for older code.
*/
#define insb(port, buf, ns) _insb((u8 __iomem *)((port)+pci_io_base), (buf), (ns))
-#define insw(port, buf, ns) _insw_ns((u8 __iomem *)((port)+pci_io_base), (buf), (ns))
-#define insl(port, buf, nl) _insl_ns((u8 __iomem *)((port)+pci_io_base), (buf), (nl))
+#define insw(port, buf, ns) _insw_ns((u16 __iomem *)((port)+pci_io_base), (buf), (ns))
+#define insl(port, buf, nl) _insl_ns((u32 __iomem *)((port)+pci_io_base), (buf), (nl))
#define insw_ns(port, buf, ns) _insw_ns((u16 __iomem *)((port)+pci_io_base), (buf), (ns))
#define insl_ns(port, buf, nl) _insl_ns((u32 __iomem *)((port)+pci_io_base), (buf), (nl))
#else
--
1.4.1.1
^ permalink raw reply related
* [POWERPC] silence a warning
From: Stephen Rothwell @ 2006-09-14 7:01 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Left over from the constifying of get_property.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/powermac/cpufreq_64.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/powermac/cpufreq_64.c b/arch/powerpc/platforms/powermac/cpufreq_64.c
index 167cd3c..d30466d 100644
--- a/arch/powerpc/platforms/powermac/cpufreq_64.c
+++ b/arch/powerpc/platforms/powermac/cpufreq_64.c
@@ -89,7 +89,7 @@ static DEFINE_MUTEX(g5_switch_mutex);
#ifdef CONFIG_PMAC_SMU
-static u32 *g5_pmode_data;
+static const u32 *g5_pmode_data;
static int g5_pmode_max;
static struct smu_sdbp_fvt *g5_fvt_table; /* table of op. points */
--
1.4.1.1
^ permalink raw reply related
* [PATCH] aoa: add locking to tas codec
From: Johannes Berg @ 2006-09-14 8:06 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
Looks like I completely forgot to do this. This patch adds locking to
the tas codec so two userspace programs can't hit the controls at the
same time. Tested on my powerbook, but I obviously can't find any
problems even without it since it doesn't do SMP.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
--- a/sound/aoa/codecs/snd-aoa-codec-tas.c 2006-09-13 22:05:49.849647141 +0200
+++ b/sound/aoa/codecs/snd-aoa-codec-tas.c 2006-09-13 22:06:16.859647141 +0200
@@ -66,6 +66,8 @@
#include <asm/prom.h>
#include <linux/delay.h>
#include <linux/module.h>
+#include <linux/mutex.h>
+
MODULE_AUTHOR("Johannes Berg <johannes@sipsolutions.net>");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("tas codec driver for snd-aoa");
@@ -91,6 +93,10 @@ struct tas {
u8 bass, treble;
u8 acr;
int drc_range;
+ /* protects hardware access against concurrency from
+ * userspace when hitting controls and during
+ * codec init/suspend/resume */
+ struct mutex mtx;
};
static int tas_reset_init(struct tas *tas);
@@ -231,8 +237,10 @@ static int tas_snd_vol_get(struct snd_kc
{
struct tas *tas = snd_kcontrol_chip(kcontrol);
+ mutex_lock(&tas->mtx);
ucontrol->value.integer.value[0] = tas->cached_volume_l;
ucontrol->value.integer.value[1] = tas->cached_volume_r;
+ mutex_unlock(&tas->mtx);
return 0;
}
@@ -241,14 +249,18 @@ static int tas_snd_vol_put(struct snd_kc
{
struct tas *tas = snd_kcontrol_chip(kcontrol);
+ mutex_lock(&tas->mtx);
if (tas->cached_volume_l == ucontrol->value.integer.value[0]
- && tas->cached_volume_r == ucontrol->value.integer.value[1])
+ && tas->cached_volume_r == ucontrol->value.integer.value[1]) {
+ mutex_unlock(&tas->mtx);
return 0;
+ }
tas->cached_volume_l = ucontrol->value.integer.value[0];
tas->cached_volume_r = ucontrol->value.integer.value[1];
if (tas->hw_enabled)
tas_set_volume(tas);
+ mutex_unlock(&tas->mtx);
return 1;
}
@@ -276,8 +288,10 @@ static int tas_snd_mute_get(struct snd_k
{
struct tas *tas = snd_kcontrol_chip(kcontrol);
+ mutex_lock(&tas->mtx);
ucontrol->value.integer.value[0] = !tas->mute_l;
ucontrol->value.integer.value[1] = !tas->mute_r;
+ mutex_unlock(&tas->mtx);
return 0;
}
@@ -286,14 +300,18 @@ static int tas_snd_mute_put(struct snd_k
{
struct tas *tas = snd_kcontrol_chip(kcontrol);
+ mutex_lock(&tas->mtx);
if (tas->mute_l == !ucontrol->value.integer.value[0]
- && tas->mute_r == !ucontrol->value.integer.value[1])
+ && tas->mute_r == !ucontrol->value.integer.value[1]) {
+ mutex_unlock(&tas->mtx);
return 0;
+ }
tas->mute_l = !ucontrol->value.integer.value[0];
tas->mute_r = !ucontrol->value.integer.value[1];
if (tas->hw_enabled)
tas_set_volume(tas);
+ mutex_unlock(&tas->mtx);
return 1;
}
@@ -322,8 +340,10 @@ static int tas_snd_mixer_get(struct snd_
struct tas *tas = snd_kcontrol_chip(kcontrol);
int idx = kcontrol->private_value;
+ mutex_lock(&tas->mtx);
ucontrol->value.integer.value[0] = tas->mixer_l[idx];
ucontrol->value.integer.value[1] = tas->mixer_r[idx];
+ mutex_unlock(&tas->mtx);
return 0;
}
@@ -334,15 +354,19 @@ static int tas_snd_mixer_put(struct snd_
struct tas *tas = snd_kcontrol_chip(kcontrol);
int idx = kcontrol->private_value;
+ mutex_lock(&tas->mtx);
if (tas->mixer_l[idx] == ucontrol->value.integer.value[0]
- && tas->mixer_r[idx] == ucontrol->value.integer.value[1])
+ && tas->mixer_r[idx] == ucontrol->value.integer.value[1]) {
+ mutex_unlock(&tas->mtx);
return 0;
+ }
tas->mixer_l[idx] = ucontrol->value.integer.value[0];
tas->mixer_r[idx] = ucontrol->value.integer.value[1];
if (tas->hw_enabled)
tas_set_mixer(tas);
+ mutex_unlock(&tas->mtx);
return 1;
}
@@ -375,7 +399,9 @@ static int tas_snd_drc_range_get(struct
{
struct tas *tas = snd_kcontrol_chip(kcontrol);
+ mutex_lock(&tas->mtx);
ucontrol->value.integer.value[0] = tas->drc_range;
+ mutex_unlock(&tas->mtx);
return 0;
}
@@ -384,12 +410,16 @@ static int tas_snd_drc_range_put(struct
{
struct tas *tas = snd_kcontrol_chip(kcontrol);
- if (tas->drc_range == ucontrol->value.integer.value[0])
+ mutex_lock(&tas->mtx);
+ if (tas->drc_range == ucontrol->value.integer.value[0]) {
+ mutex_unlock(&tas->mtx);
return 0;
+ }
tas->drc_range = ucontrol->value.integer.value[0];
if (tas->hw_enabled)
tas3004_set_drc(tas);
+ mutex_unlock(&tas->mtx);
return 1;
}
@@ -417,7 +447,9 @@ static int tas_snd_drc_switch_get(struct
{
struct tas *tas = snd_kcontrol_chip(kcontrol);
+ mutex_lock(&tas->mtx);
ucontrol->value.integer.value[0] = tas->drc_enabled;
+ mutex_unlock(&tas->mtx);
return 0;
}
@@ -426,12 +458,16 @@ static int tas_snd_drc_switch_put(struct
{
struct tas *tas = snd_kcontrol_chip(kcontrol);
- if (tas->drc_enabled == ucontrol->value.integer.value[0])
+ mutex_lock(&tas->mtx);
+ if (tas->drc_enabled == ucontrol->value.integer.value[0]) {
+ mutex_unlock(&tas->mtx);
return 0;
+ }
tas->drc_enabled = ucontrol->value.integer.value[0];
if (tas->hw_enabled)
tas3004_set_drc(tas);
+ mutex_unlock(&tas->mtx);
return 1;
}
@@ -463,7 +499,9 @@ static int tas_snd_capture_source_get(st
{
struct tas *tas = snd_kcontrol_chip(kcontrol);
+ mutex_lock(&tas->mtx);
ucontrol->value.enumerated.item[0] = !!(tas->acr & TAS_ACR_INPUT_B);
+ mutex_unlock(&tas->mtx);
return 0;
}
@@ -471,15 +509,21 @@ static int tas_snd_capture_source_put(st
struct snd_ctl_elem_value *ucontrol)
{
struct tas *tas = snd_kcontrol_chip(kcontrol);
- int oldacr = tas->acr;
+ int oldacr;
+
+ mutex_lock(&tas->mtx);
+ oldacr = tas->acr;
tas->acr &= ~TAS_ACR_INPUT_B;
if (ucontrol->value.enumerated.item[0])
tas->acr |= TAS_ACR_INPUT_B;
- if (oldacr == tas->acr)
+ if (oldacr == tas->acr) {
+ mutex_unlock(&tas->mtx);
return 0;
+ }
if (tas->hw_enabled)
tas_write_reg(tas, TAS_REG_ACR, 1, &tas->acr);
+ mutex_unlock(&tas->mtx);
return 1;
}
@@ -518,7 +562,9 @@ static int tas_snd_treble_get(struct snd
{
struct tas *tas = snd_kcontrol_chip(kcontrol);
+ mutex_lock(&tas->mtx);
ucontrol->value.integer.value[0] = tas->treble;
+ mutex_unlock(&tas->mtx);
return 0;
}
@@ -527,12 +573,16 @@ static int tas_snd_treble_put(struct snd
{
struct tas *tas = snd_kcontrol_chip(kcontrol);
- if (tas->treble == ucontrol->value.integer.value[0])
+ mutex_lock(&tas->mtx);
+ if (tas->treble == ucontrol->value.integer.value[0]) {
+ mutex_unlock(&tas->mtx);
return 0;
+ }
tas->treble = ucontrol->value.integer.value[0];
if (tas->hw_enabled)
tas_set_treble(tas);
+ mutex_unlock(&tas->mtx);
return 1;
}
@@ -560,7 +610,9 @@ static int tas_snd_bass_get(struct snd_k
{
struct tas *tas = snd_kcontrol_chip(kcontrol);
+ mutex_lock(&tas->mtx);
ucontrol->value.integer.value[0] = tas->bass;
+ mutex_unlock(&tas->mtx);
return 0;
}
@@ -569,12 +621,16 @@ static int tas_snd_bass_put(struct snd_k
{
struct tas *tas = snd_kcontrol_chip(kcontrol);
- if (tas->bass == ucontrol->value.integer.value[0])
+ mutex_lock(&tas->mtx);
+ if (tas->bass == ucontrol->value.integer.value[0]) {
+ mutex_unlock(&tas->mtx);
return 0;
+ }
tas->bass = ucontrol->value.integer.value[0];
if (tas->hw_enabled)
tas_set_bass(tas);
+ mutex_unlock(&tas->mtx);
return 1;
}
@@ -628,16 +684,16 @@ static int tas_reset_init(struct tas *ta
tmp = TAS_MCS_SCLK64 | TAS_MCS_SPORT_MODE_I2S | TAS_MCS_SPORT_WL_24BIT;
if (tas_write_reg(tas, TAS_REG_MCS, 1, &tmp))
- return -ENODEV;
+ goto outerr;
tas->acr |= TAS_ACR_ANALOG_PDOWN | TAS_ACR_B_MONAUREAL |
TAS_ACR_B_MON_SEL_RIGHT;
if (tas_write_reg(tas, TAS_REG_ACR, 1, &tas->acr))
- return -ENODEV;
+ goto outerr;
tmp = 0;
if (tas_write_reg(tas, TAS_REG_MCS2, 1, &tmp))
- return -ENODEV;
+ goto outerr;
tas3004_set_drc(tas);
@@ -649,9 +705,11 @@ static int tas_reset_init(struct tas *ta
tas->acr &= ~TAS_ACR_ANALOG_PDOWN;
if (tas_write_reg(tas, TAS_REG_ACR, 1, &tas->acr))
- return -ENODEV;
+ goto outerr;
return 0;
+ outerr:
+ return -ENODEV;
}
static int tas_switch_clock(struct codec_info_item *cii, enum clock_switch clock)
@@ -666,11 +724,13 @@ static int tas_switch_clock(struct codec
break;
case CLOCK_SWITCH_SLAVE:
/* Clocks are back, re-init the codec */
+ mutex_lock(&tas->mtx);
tas_reset_init(tas);
tas_set_volume(tas);
tas_set_mixer(tas);
tas->hw_enabled = 1;
tas->codec.gpio->methods->all_amps_restore(tas->codec.gpio);
+ mutex_unlock(&tas->mtx);
break;
default:
/* doesn't happen as of now */
@@ -684,19 +744,23 @@ static int tas_switch_clock(struct codec
* our i2c device is suspended, and then take note of that! */
static int tas_suspend(struct tas *tas)
{
+ mutex_lock(&tas->mtx);
tas->hw_enabled = 0;
tas->acr |= TAS_ACR_ANALOG_PDOWN;
tas_write_reg(tas, TAS_REG_ACR, 1, &tas->acr);
+ mutex_unlock(&tas->mtx);
return 0;
}
static int tas_resume(struct tas *tas)
{
/* reset codec */
+ mutex_lock(&tas->mtx);
tas_reset_init(tas);
tas_set_volume(tas);
tas_set_mixer(tas);
tas->hw_enabled = 1;
+ mutex_unlock(&tas->mtx);
return 0;
}
@@ -739,11 +803,14 @@ static int tas_init_codec(struct aoa_cod
return -EINVAL;
}
+ mutex_lock(&tas->mtx);
if (tas_reset_init(tas)) {
printk(KERN_ERR PFX "tas failed to initialise\n");
+ mutex_unlock(&tas->mtx);
return -ENXIO;
}
tas->hw_enabled = 1;
+ mutex_unlock(&tas->mtx);
if (tas->codec.soundbus_dev->attach_codec(tas->codec.soundbus_dev,
aoa_get_card(),
@@ -822,6 +889,7 @@ static int tas_create(struct i2c_adapter
if (!tas)
return -ENOMEM;
+ mutex_init(&tas->mtx);
tas->i2c.driver = &tas_driver;
tas->i2c.adapter = adapter;
tas->i2c.addr = addr;
@@ -850,6 +918,7 @@ static int tas_create(struct i2c_adapter
detach:
i2c_detach_client(&tas->i2c);
fail:
+ mutex_destroy(&tas->mtx);
kfree(tas);
return -EINVAL;
}
@@ -908,6 +977,7 @@ static int tas_i2c_detach(struct i2c_cli
/* power down codec chip */
tas_write_reg(tas, TAS_REG_ACR, 1, &tmp);
+ mutex_destroy(&tas->mtx);
kfree(tas);
return 0;
}
^ permalink raw reply
* Re: Ethernet driver for Linux kernel 2.6 running on ML403
From: David H. Lynch Jr. @ 2006-09-14 11:18 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <528646bc0609131852s41a8bc4ev44b84d68f51b1d2d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]
Grant Likely wrote:
> On 9/13/06, Aleck Lin <aleck@gdatech.com> wrote:
>
>> Hi,
>>
>> I'm able to boot Linux 2.6 on ML403 board (with a ramdisk file system).
>>
>> However, during the kernel booting, it complains that "No network devices
>> available," So I figured I probably didn't enable the ethernet driver in the
>> kernel.
>>
>> >From doing "make menuconfig", under "Device Drivers" --> "Network device
>> support" --> "Ethernet(10 or 100Mbit)", I checked the box of both "Ethernet
>> (10 or 100Mbit)" and "PowerPC 4xx on-chip Ethernet support." I then
>> save/exit the menuconfig to compile the kernel again. I've attached the
>> error output at the bottom.
>>
>
> The virtex eth device is not the same as 4xx on-chip Ethernet, so
> CONFIG_IBM_EMAC will not work. You need the xilinx_enet driver (which
> is not in mainline). It might be in MontaVista's 2.6 tree.
>
> I think people have posted patches for it to this list, so try
> searching the archives. (I don't have a link off the top of my head.)
>
The MV 2.6 Xilinx_edk based TEMAC driver has been posted to this
list several times.
As of the last incarnation I tried it had no MII/PHY support and you
had to manully change the speed of the driver 10/100/1000 by editing the
code.
Otherwise it worked with the PLB FIFO TEMAC, that I am using, and
should with others.
I have a polled driver that works with the LL TEMAC.
I am nearly finished a PLB FIFO TEMAC driver that includes working
autonegotiation and does not use the Xilinx_edk.
But right now it has a receive problem - packets come in they look
good but linux silently discards them.
I have virtually the same code working under GHS Integrity.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 2992 bytes --]
^ permalink raw reply
* Measure Interrupt Latency on MPC5200B
From: Syed Amer Gilani @ 2006-09-14 12:00 UTC (permalink / raw)
To: Linuxppc-embedded
We have a MPC5200B(ppc) Board from Phytec, running with a 2.6 Linux
Kernel. For Documentation purposes and testings how patches to the
Kernel affects real time capabilities we want to measure the Interrupt
Latency.
I only found tools for other arches or patches for far to old kernels.
Does somebody know a way for a 2.6 kernel on ppc? I already thought of
generating a signal on an Output of the Board and measure it with a
Oscilloscope but i don't find that method satisfying.
Thank you in advance,
Syed Amer Gilani
^ permalink raw reply
* cpm_uart non-console problem with write on 2nd open..
From: Alexandros Kostopoulos @ 2006-09-14 13:30 UTC (permalink / raw)
To: linuxppc-dev
I'm experiencing a problem with the 2.6.13 cpm_uart driver. When opening=
=
the device for the second time after the driver was inserted, if only a =
=
few bytes are sent for transmission and the device is then closed, the =
tx_empty routine called by shutdown returns 0 and the latter hangs in th=
e =
while loop with the call to cpm_uart_tx_empty. No bytes are actually =
transmitted from the uart.
I found out that the difference between the first and subsequent open =
calls is that during the first time (and until the first shutdown) the =
transmitter is enabled in GSMRL. From this point on, the transmitter is =
=
initially disabled on startup. Thus, if only a few bytes are queued for =
=
transmission before shutdown and a TX interrupt is not triggered, the =
bytes are never sent, and thus the shutdown function hangs on the =
cpm_uart_tx_empty loop.
The fix that works for me is the following:
Index: drivers/serial/cpm_uart/cpm_uart_core.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- drivers/serial/cpm_uart/cpm_uart_core.c (revision 106)
+++ drivers/serial/cpm_uart/cpm_uart_core.c (working copy)
@@ -394,7 +394,7 @@ static int cpm_uart_startup(struct uart_
pinfo->smcp->smc_smcmr |=3D SMCMR_REN;
} else {
pinfo->sccp->scc_sccm |=3D UART_SCCM_RX;
- pinfo->sccp->scc_gsmrl |=3D (SCC_GSMRL_ENR);
+ pinfo->sccp->scc_gsmrl |=3D (SCC_GSMRL_ENR | SCC_GSMRL_ENT);
}
Any comments would be greatly appreciated
thank you
Alex
^ permalink raw reply
* Re: cpm_uart non-console problem with write on 2nd open..
From: Vitaly Bordug @ 2006-09-14 13:37 UTC (permalink / raw)
To: Alexandros Kostopoulos; +Cc: linuxppc-dev
In-Reply-To: <op.tfvehinanhx3hy@draco>
On Thu, 14 Sep 2006 16:30:44 +0300
"Alexandros Kostopoulos" <akostop@inaccessnetworks.com> wrote:
> I'm experiencing a problem with the 2.6.13 cpm_uart driver. When opening
> the device for the second time after the driver was inserted, if only a
> few bytes are sent for transmission and the device is then closed, the
> tx_empty routine called by shutdown returns 0 and the latter hangs in the
> while loop with the call to cpm_uart_tx_empty. No bytes are actually
> transmitted from the uart.
>
It was addressed a while ago, fix should be in the latest stable kernel rev. for certain.
The snippet below was not the only thing to get problem completely resolved;
You may glance at the code within current kernel, if still experiencing problems.
Thanks, Vitaly
> I found out that the difference between the first and subsequent open
> calls is that during the first time (and until the first shutdown) the
> transmitter is enabled in GSMRL. From this point on, the transmitter is
> initially disabled on startup. Thus, if only a few bytes are queued for
> transmission before shutdown and a TX interrupt is not triggered, the
> bytes are never sent, and thus the shutdown function hangs on the
> cpm_uart_tx_empty loop.
>
> The fix that works for me is the following:
>
> Index: drivers/serial/cpm_uart/cpm_uart_core.c
> ===================================================================
> --- drivers/serial/cpm_uart/cpm_uart_core.c (revision 106)
> +++ drivers/serial/cpm_uart/cpm_uart_core.c (working copy)
>
> @@ -394,7 +394,7 @@ static int cpm_uart_startup(struct uart_
> pinfo->smcp->smc_smcmr |= SMCMR_REN;
> } else {
> pinfo->sccp->scc_sccm |= UART_SCCM_RX;
> - pinfo->sccp->scc_gsmrl |= (SCC_GSMRL_ENR);
> + pinfo->sccp->scc_gsmrl |= (SCC_GSMRL_ENR | SCC_GSMRL_ENT);
>
> }
>
> Any comments would be greatly appreciated
>
> thank you
>
> Alex
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Ethernet driver for Linux kernel 2.6 running on ML403
From: Michael Galassi @ 2006-09-14 13:53 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <45093A94.2080407@dlasys.net>
>> The virtex eth device is not the same as 4xx on-chip Ethernet, so
>> CONFIG_IBM_EMAC will not work. You need the xilinx_enet driver (which
>> is not in mainline). It might be in MontaVista's 2.6 tree.
>>
>> I think people have posted patches for it to this list, so try
>> searching the archives. (I don't have a link off the top of my head.)
>>
> The MV 2.6 Xilinx_edk based TEMAC driver has been posted to this
>list several times.
>
> As of the last incarnation I tried it had no MII/PHY support and you
>had to manully change the speed of the driver 10/100/1000 by editing the
>code.
It is also worth noting that as released in MVL pro 4.0.1 it only
supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
tagged as deprecated in the current version (8.2.01i) of Xilinx's
EDK. The current version of {plb,hard}_temac (3.00.a) goes to great
lengths to break compatibility with older versions. This will
presumably be fixed next month when it is rumored that wonderful new
things will come from Xilinx. In the mean-time it is possible, though
neither simple, nor fun, to create Virtex4 designs with the older IP.
-michael
^ permalink raw reply
* Re: Linux on custom Xilinx board with PPC405 hangs on boot
From: Peter N. Andreasen @ 2006-09-14 14:13 UTC (permalink / raw)
To: Andrei Konovalov, linuxppc-dev
In-Reply-To: <4506D7DE.9070800@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
Thank you for the advice.
Now I have been able to insert instructions to display a number on an
attached display which means that I can now see that the code runs until the
file head_4xx.S in the line where the comment is "Now turn on the MMU for
real" and then calls start_kernel by way of an rfi instruction. The
processor then ends up in the Instruction storage exception where I have
placed another write to the display.
Do you have any idea how to find out what happened here?
cheers
Peter
On 9/12/06, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
>
>
> "console=ttyS0" (not "/dev/ttyS0" BTW) is for 16x50 compatible UART.
> UartLite needs something like "console=ttl0".
>
>
[-- Attachment #2: Type: text/html, Size: 1027 bytes --]
^ permalink raw reply
* Re: Ethernet driver for Linux kernel 2.6 running on ML403
From: Grant Likely @ 2006-09-14 14:34 UTC (permalink / raw)
To: Michael Galassi; +Cc: linuxppc-embedded
In-Reply-To: <200609141353.k8EDrkPN065101@penguin.ncube.com>
On 9/14/06, Michael Galassi <mgalassi@c-cor.com> wrote:
> It is also worth noting that as released in MVL pro 4.0.1 it only
> supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
> tagged as deprecated in the current version (8.2.01i) of Xilinx's
> EDK. The current version of {plb,hard}_temac (3.00.a) goes to great
> lengths to break compatibility with older versions. This will
> presumably be fixed next month when it is rumored that wonderful new
> things will come from Xilinx. In the mean-time it is possible, though
> neither simple, nor fun, to create Virtex4 designs with the older IP.
So what direction do we (as the community) want to go for supporting
Xilinx IP in the Linux kernel?
IIRC, Xilinx intends to get drivers submitted into mainline. (Based
on their cross-platform driver support code). It is unknown which and
how many drivers for different IP versions will be submitted.
However, the xilinx driver code is verbose and does not match well
with the rest of the Linux code base. (due to the cross platform
support) Plus, the Xilinx tool work flow is geared towards the EDK
tool overwriting the driver code in the kernel tree with code for the
generated design. In which case, does it even make sense to accept
Xilinx drivers into the Linux tree when they are just going to get
overwritten by the toolchain anyway? Unfortunately, regenerating
drivers has it's own problems considering that the license on the
generated code is not GPL compatible at the moment.
If we reject the Xilinx driver code, then we either have to do without
Xilinx support in mainline, or we need to write new drivers that
address the above issues (support multiple IP versions, etc). The
Xilinx support in mainline right now does not use any Xilinx code.
(Xilinx PIC and UART).
Thoughts?
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] powerpc: minor fix of numa message
From: Geoff Levand @ 2006-09-14 15:17 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, anton
This is a very minor fix that effects no current system. The NUMA startup
message values for 'Top of RAM' and 'Memory hole size' were reported
incorrectly if more than one lmb region was added.
A comment in the lmb code states that lmb_analyze() must be called before
lmb_phys_mem_size().
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Index: cell--common--4/arch/powerpc/mm/numa.c
===================================================================
--- cell--common--4.orig/arch/powerpc/mm/numa.c
+++ cell--common--4/arch/powerpc/mm/numa.c
@@ -483,10 +483,14 @@
static void __init setup_nonnuma(void)
{
- unsigned long top_of_ram = lmb_end_of_DRAM();
- unsigned long total_ram = lmb_phys_mem_size();
+ unsigned long top_of_ram;
+ unsigned long total_ram;
unsigned int i;
+ lmb_analyze();
+ top_of_ram = lmb_end_of_DRAM();
+ total_ram = lmb_phys_mem_size();
+
printk(KERN_DEBUG "Top of RAM: 0x%lx, Total RAM: 0x%lx\n",
top_of_ram, total_ram);
printk(KERN_DEBUG "Memory hole size: %ldMB\n",
^ permalink raw reply
* Re: Ethernet driver for Linux kernel 2.6 running on ML403
From: Keith J Outwater @ 2006-09-14 15:47 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <528646bc0609140734j2f7b008fy815f221677c5ac74@mail.gmail.com>
Grant,
You bring up excellent points, and I am having to deal with these
issues in my 2.4.x kernel and U-Boot ports to VirtexII Pro FPGAs
as well.
> On 9/14/06, Michael Galassi <mgalassi@c-cor.com> wrote:
> > It is also worth noting that as released in MVL pro 4.0.1 it only
> > supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
> > tagged as deprecated in the current version (8.2.01i) of Xilinx's
> > EDK. The current version of {plb,hard}_temac (3.00.a) goes to great
> > lengths to break compatibility with older versions. This will
> > presumably be fixed next month when it is rumored that wonderful new
> > things will come from Xilinx. In the mean-time it is possible, though
> > neither simple, nor fun, to create Virtex4 designs with the older IP.
I think the general case is that Xilinx IP will be constantly evolving,
and
Xilinx driver code, when released under the GPL, will appear sporadically.
Maybe it's best to resign ourselves to the fact that this situation
probably won't change, and then try to deal with it in a way that does
not depend so heavily on Xilinx drivers.
>
> So what direction do we (as the community) want to go for supporting
> Xilinx IP in the Linux kernel?
I don't know about anyone else, but running Linux on Virtex FPGAs is
something I simply have to be able to do. With or without Xilinx
drivers, I think the kernel needs to support Xilinx hardware.
>
> IIRC, Xilinx intends to get drivers submitted into mainline. (Based
> on their cross-platform driver support code). It is unknown which and
> how many drivers for different IP versions will be submitted.
That's part of the problem: we seem to get support for some
IP cores, but not all. Xilinx takes a piecemeal approach
to releasing drivers under the GPL.
>
> However, the xilinx driver code is verbose and does not match well
> with the rest of the Linux code base. (due to the cross platform
> support) Plus, the Xilinx tool work flow is geared towards the EDK
> tool overwriting the driver code in the kernel tree with code for the
> generated design. In which case, does it even make sense to accept
> Xilinx drivers into the Linux tree when they are just going to get
> overwritten by the toolchain anyway? Unfortunately, regenerating
> drivers has it's own problems considering that the license on the
> generated code is not GPL compatible at the moment.
Same complaints apply for Xilinx drivers in the U-Boot bootloader.
It is proving very difficult to get Xilinx code into U-Boot which means
BSPs that use the code are hard to get submitted as well.
The Xilinx approach of overwriting the source tree just feels wrong, and
no one seems to want to do it that way.
>
> If we reject the Xilinx driver code, then we either have to do without
> Xilinx support in mainline, or we need to write new drivers that
> address the above issues (support multiple IP versions, etc). The
> Xilinx support in mainline right now does not use any Xilinx code.
> (Xilinx PIC and UART).
>
> Thoughts?
As painful as it may be, maybe we just write drivers from scratch and
try to track changes in the IP.
Regards,
Keith Outwater
^ permalink raw reply
* RE: Ethernet driver for Linux kernel 2.6 running on ML403
From: John Bonesio @ 2006-09-14 16:40 UTC (permalink / raw)
To: Keith J Outwater, linuxppc-embedded
Hi,
I just saw this thread. The next version of EDK 8.2.2 will have a temac
v3.00a driver for linux 2.6. Our plan is to begin our code freeze stage
tomorrow. If people really need the driver right away, and can't wait a
few weeks for the release, I could possibly provide a patch (or use some
other distribution method) for the driver.
=20
Here at Xilinx, we have been in talks about having our drivers more
readily available in the open source repositories. As far as I know,
everyone seems to think that this would be a good thing for us. Right
now the plan is to have a 3rd party check our drivers into the main
repository as we have limited resources here. (Basically we're up to our
eyeballs in work right now.)
I do know that Xilinx would rather play a principle role in developing
and maintaining these open source drivers, rather than having a separate
group go off and implement a separate set.
<< Same complaints apply for Xilinx drivers in the U-Boot bootloader.
It is proving very difficult to get Xilinx code into U-Boot which means
BSPs that use the code are hard to get submitted as well.>>
I've only touched on U-Boot a little bit. Have any thoughts on how to
make this easier?
<< The Xilinx approach of overwriting the source tree just feels wrong,
and
no one seems to want to do it that way.>>
I am in the group that has control over how this is done. What would you
propose be done different? Keep in mind that we are trying to support a
process where someone builds a hardware design and the later changes it
with new peripherals or perhaps makes minor tweaks. We want to make the
updating of the Linux kernel to reflect these hardware changes easy for
people.
Having the ability to make rapid hardware changes, I think, is a bit
different from what most folks are used to.
Cheers,
- John
-----Original Message-----
From: linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org] On
Behalf Of Keith J Outwater
Sent: Thursday, September 14, 2006 9:48 AM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Ethernet driver for Linux kernel 2.6 running on ML403
Grant,
You bring up excellent points, and I am having to deal with these
issues in my 2.4.x kernel and U-Boot ports to VirtexII Pro FPGAs
as well.
> On 9/14/06, Michael Galassi <mgalassi@c-cor.com> wrote:
> > It is also worth noting that as released in MVL pro 4.0.1 it only
> > supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
> > tagged as deprecated in the current version (8.2.01i) of Xilinx's
> > EDK. The current version of {plb,hard}_temac (3.00.a) goes to great
> > lengths to break compatibility with older versions. This will
> > presumably be fixed next month when it is rumored that wonderful new
> > things will come from Xilinx. In the mean-time it is possible,
though
> > neither simple, nor fun, to create Virtex4 designs with the older
IP.
I think the general case is that Xilinx IP will be constantly evolving,=20
and
Xilinx driver code, when released under the GPL, will appear
sporadically.
Maybe it's best to resign ourselves to the fact that this situation
probably won't change, and then try to deal with it in a way that does
not depend so heavily on Xilinx drivers.
>=20
> So what direction do we (as the community) want to go for supporting
> Xilinx IP in the Linux kernel?
I don't know about anyone else, but running Linux on Virtex FPGAs is
something I simply have to be able to do. With or without Xilinx
drivers, I think the kernel needs to support Xilinx hardware.
>=20
> IIRC, Xilinx intends to get drivers submitted into mainline. (Based
> on their cross-platform driver support code). It is unknown which and
> how many drivers for different IP versions will be submitted.
That's part of the problem: we seem to get support for some
IP cores, but not all. Xilinx takes a piecemeal approach
to releasing drivers under the GPL.
>=20
> However, the xilinx driver code is verbose and does not match well
> with the rest of the Linux code base. (due to the cross platform
> support) Plus, the Xilinx tool work flow is geared towards the EDK
> tool overwriting the driver code in the kernel tree with code for the
> generated design. In which case, does it even make sense to accept
> Xilinx drivers into the Linux tree when they are just going to get
> overwritten by the toolchain anyway? Unfortunately, regenerating
> drivers has it's own problems considering that the license on the
> generated code is not GPL compatible at the moment.
Same complaints apply for Xilinx drivers in the U-Boot bootloader.
It is proving very difficult to get Xilinx code into U-Boot which means
BSPs that use the code are hard to get submitted as well.
The Xilinx approach of overwriting the source tree just feels wrong, and
no one seems to want to do it that way.
>=20
> If we reject the Xilinx driver code, then we either have to do without
> Xilinx support in mainline, or we need to write new drivers that
> address the above issues (support multiple IP versions, etc). The
> Xilinx support in mainline right now does not use any Xilinx code.
> (Xilinx PIC and UART).
>=20
> Thoughts?
As painful as it may be, maybe we just write drivers from scratch and
try to track changes in the IP.
Regards,
Keith Outwater
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: Ethernet driver for Linux kernel 2.6 running on ML403
From: Keith J Outwater @ 2006-09-14 17:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <2FE3DBF1797A1443AAB3FA0EF6BF4EEC021EA645@XSJ-EXCHVS1.xlnx.xilinx.com>
> Hi,
>
> I just saw this thread. The next version of EDK 8.2.2 will have a temac
> v3.00a driver for linux 2.6. Our plan is to begin our code freeze stage
> tomorrow. If people really need the driver right away, and can't wait a
> few weeks for the release, I could possibly provide a patch (or use some
> other distribution method) for the driver.
>
> Here at Xilinx, we have been in talks about having our drivers more
> readily available in the open source repositories. As far as I know,
> everyone seems to think that this would be a good thing for us. Right
> now the plan is to have a 3rd party check our drivers into the main
> repository as we have limited resources here. (Basically we're up to our
> eyeballs in work right now.)
I know that MontaVista is you preferred Linux partner - if they do the
released, then we have to wait for them. If individual designers can
get the driver sources, you can bet it will make it's way into the
mainline kernel.
>
> I do know that Xilinx would rather play a principle role in developing
> and maintaining these open source drivers, rather than having a separate
> group go off and implement a separate set.
You may end up having to serve multiple customer bases then, to keep
things from forking. The are lots of us who want to have lots of
fine-grained control over our source trees and the way in which we do
builds.
>
> << Same complaints apply for Xilinx drivers in the U-Boot bootloader.
> It is proving very difficult to get Xilinx code into U-Boot which means
> BSPs that use the code are hard to get submitted as well.>>
>
> I've only touched on U-Boot a little bit. Have any thoughts on how to
> make this easier?
My perspective on this is that of a hardware designer who also develops
code. I understand that is a good thing from the Xilinx point of view
to make it as easy as possible for designers to develop designs using
EDK with automatic BSP generation. It's great for
doing stand alone (no OS) designs or to get "instant gratification"
as in "gee, I just booted Linux!" (a la Xilinx XAPP765).
When you do that, though, invariably
you end up having to make decisions that constrain how the design flow
works for the user and then it's hard for the user to deviate from that
flow.
For example, the idea of having a user auto-generate source code for a BSP
that overwrites the bootloader or kernel source tree. The problem
is that it's hard to "take the training wheels off" if I want or need
to have a stable source base of if I want to use the mainline kernel
or the mainline bootloader (U-Boot). What if the source code bases
for the kernel or bootloader get re-arranged?
What I'd really like to have is "out of the box"
kernel support for all the
primary peripheral devices like communications and interface stuff
and U-Boot support for those devices as well. I don't want to
have to generate BSPs and overwrite the source trees.
The whole licensing thing is another issue. As I stated to someone
else at Xilinx: These are just drivers, not the crown jewels. GPL it
all and make it easier for designers to incorporate the code into
open source projects. Dual license if you have customers who have
to have things locked up.
For U-Boot, I'm getting push-back from the maintainer on the
size and "verbosity" of the code. Sounds like this might be an
issue for the kernel as well.
>
> << The Xilinx approach of overwriting the source tree just feels wrong,
> and
> no one seems to want to do it that way.>>
>
> I am in the group that has control over how this is done. What would you
> propose be done different? Keep in mind that we are trying to support a
> process where someone builds a hardware design and the later changes it
> with new peripherals or perhaps makes minor tweaks. We want to make the
> updating of the Linux kernel to reflect these hardware changes easy for
> people.
A noble goal, and clearly the right thing to do from a user-success point
of view, but do the hardware peripherals (i.e. the IP cores) change that
much?
See my comment below: Can you create a system that allows software drivers
to verify that they (the drivers) are compatible with a particular IP
version? For the novice user, the "full auto" system probably works
fine, but for (some, at least) experienced users, it tends to be an
additional layer or complexity (or opacity) that would be nice to get rid
of.
>
> Having the ability to make rapid hardware changes, I think, is a bit
> different from what most folks are used to.
I agree. I think we all need to agree how best to manage the
driver code so that as IP versions change, the drivers can be properly
matched to the IP. Also, as more and more people port Linux to their
Virtex designs, we can (hopefully) expect more "out of the box"
support for Xilinx hardware. That's basically the situation you have
with more conventional peripheral devices.
I don't think that there are any "version" registers in the Xilinx
IP cores that a driver could check to determine compatibility. That
would be very cheap to implement in hardware and you could then
develop more universal drivers.
>
> Cheers,
>
> - John
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+jbonesio=xilinx.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+jbonesio=xilinx.com@ozlabs.org] On
> Behalf Of Keith J Outwater
> Sent: Thursday, September 14, 2006 9:48 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Ethernet driver for Linux kernel 2.6 running on ML403
>
> Grant,
> You bring up excellent points, and I am having to deal with these
> issues in my 2.4.x kernel and U-Boot ports to VirtexII Pro FPGAs
> as well.
>
> > On 9/14/06, Michael Galassi <mgalassi@c-cor.com> wrote:
> > > It is also worth noting that as released in MVL pro 4.0.1 it only
> > > supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
> > > tagged as deprecated in the current version (8.2.01i) of Xilinx's
> > > EDK. The current version of {plb,hard}_temac (3.00.a) goes to great
> > > lengths to break compatibility with older versions. This will
> > > presumably be fixed next month when it is rumored that wonderful new
> > > things will come from Xilinx. In the mean-time it is possible,
> though
> > > neither simple, nor fun, to create Virtex4 designs with the older
> IP.
>
> I think the general case is that Xilinx IP will be constantly evolving,
> and
> Xilinx driver code, when released under the GPL, will appear
> sporadically.
> Maybe it's best to resign ourselves to the fact that this situation
> probably won't change, and then try to deal with it in a way that does
> not depend so heavily on Xilinx drivers.
>
> >
> > So what direction do we (as the community) want to go for supporting
> > Xilinx IP in the Linux kernel?
>
> I don't know about anyone else, but running Linux on Virtex FPGAs is
> something I simply have to be able to do. With or without Xilinx
> drivers, I think the kernel needs to support Xilinx hardware.
>
> >
> > IIRC, Xilinx intends to get drivers submitted into mainline. (Based
> > on their cross-platform driver support code). It is unknown which and
> > how many drivers for different IP versions will be submitted.
>
> That's part of the problem: we seem to get support for some
> IP cores, but not all. Xilinx takes a piecemeal approach
> to releasing drivers under the GPL.
>
> >
> > However, the xilinx driver code is verbose and does not match well
> > with the rest of the Linux code base. (due to the cross platform
> > support) Plus, the Xilinx tool work flow is geared towards the EDK
> > tool overwriting the driver code in the kernel tree with code for the
> > generated design. In which case, does it even make sense to accept
> > Xilinx drivers into the Linux tree when they are just going to get
> > overwritten by the toolchain anyway? Unfortunately, regenerating
> > drivers has it's own problems considering that the license on the
> > generated code is not GPL compatible at the moment.
>
> Same complaints apply for Xilinx drivers in the U-Boot bootloader.
> It is proving very difficult to get Xilinx code into U-Boot which means
> BSPs that use the code are hard to get submitted as well.
>
> The Xilinx approach of overwriting the source tree just feels wrong, and
> no one seems to want to do it that way.
>
> >
> > If we reject the Xilinx driver code, then we either have to do without
> > Xilinx support in mainline, or we need to write new drivers that
> > address the above issues (support multiple IP versions, etc). The
> > Xilinx support in mainline right now does not use any Xilinx code.
> > (Xilinx PIC and UART).
> >
> > Thoughts?
>
> As painful as it may be, maybe we just write drivers from scratch and
> try to track changes in the IP.
>
> Regards,
> Keith Outwater
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* RE: Ethernet driver for Linux kernel 2.6 running on ML403
From: John Bonesio @ 2006-09-14 17:52 UTC (permalink / raw)
To: Keith J Outwater, linuxppc-embedded
More comments below...
-----Original Message-----
From: linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org] On
Behalf Of Keith J Outwater
Sent: Thursday, September 14, 2006 11:36 AM
To: linuxppc-embedded@ozlabs.org
Subject: RE: Ethernet driver for Linux kernel 2.6 running on ML403
> Hi,
>=20
> I just saw this thread. The next version of EDK 8.2.2 will have a
temac
> v3.00a driver for linux 2.6. Our plan is to begin our code freeze
stage
> tomorrow. If people really need the driver right away, and can't wait
a
> few weeks for the release, I could possibly provide a patch (or use
some
> other distribution method) for the driver.
>=20
> Here at Xilinx, we have been in talks about having our drivers more
> readily available in the open source repositories. As far as I know,
> everyone seems to think that this would be a good thing for us. Right
> now the plan is to have a 3rd party check our drivers into the main
> repository as we have limited resources here. (Basically we're up to
our
> eyeballs in work right now.)
I know that MontaVista is you preferred Linux partner - if they do the
released, then we have to wait for them. If individual designers can
get the driver sources, you can bet it will make it's way into the
mainline kernel.
>=20
> I do know that Xilinx would rather play a principle role in developing
> and maintaining these open source drivers, rather than having a
separate
> group go off and implement a separate set.
You may end up having to serve multiple customer bases then, to keep
things from forking. The are lots of us who want to have lots of
fine-grained control over our source trees and the way in which we do=20
builds.
[John]
One thing that may help you, is that you can clear out the 'target_dir'
setting in xps. That will let you generate the BSP and then simply copy
over the files you need.
>=20
> << Same complaints apply for Xilinx drivers in the U-Boot bootloader.
> It is proving very difficult to get Xilinx code into U-Boot which
means
> BSPs that use the code are hard to get submitted as well.>>
>=20
> I've only touched on U-Boot a little bit. Have any thoughts on how to
> make this easier?
My perspective on this is that of a hardware designer who also develops
code. I understand that is a good thing from the Xilinx point of view
to make it as easy as possible for designers to develop designs using
EDK with automatic BSP generation. It's great for
doing stand alone (no OS) designs or to get "instant gratification"
as in "gee, I just booted Linux!" (a la Xilinx XAPP765).
When you do that, though, invariably
you end up having to make decisions that constrain how the design flow
works for the user and then it's hard for the user to deviate from that=20
flow.
For example, the idea of having a user auto-generate source code for a
BSP
that overwrites the bootloader or kernel source tree. The problem
is that it's hard to "take the training wheels off" if I want or need
to have a stable source base of if I want to use the mainline kernel
or the mainline bootloader (U-Boot). What if the source code bases
for the kernel or bootloader get re-arranged?
What I'd really like to have is "out of the box"
kernel support for all the
primary peripheral devices like communications and interface stuff
and U-Boot support for those devices as well. I don't want to
have to generate BSPs and overwrite the source trees.
[John]
See my comment above.
The whole licensing thing is another issue. As I stated to someone
else at Xilinx: These are just drivers, not the crown jewels. GPL it
all and make it easier for designers to incorporate the code into
open source projects. Dual license if you have customers who have
to have things locked up.
[John]
I believe this is our intention going forward.
For U-Boot, I'm getting push-back from the maintainer on the
size and "verbosity" of the code. Sounds like this might be an
issue for the kernel as well.
>=20
> << The Xilinx approach of overwriting the source tree just feels
wrong,
> and
> no one seems to want to do it that way.>>
>=20
> I am in the group that has control over how this is done. What would
you
> propose be done different? Keep in mind that we are trying to support
a
> process where someone builds a hardware design and the later changes
it
> with new peripherals or perhaps makes minor tweaks. We want to make
the
> updating of the Linux kernel to reflect these hardware changes easy
for
> people.
A noble goal, and clearly the right thing to do from a user-success
point
of view, but do the hardware peripherals (i.e. the IP cores) change that
much?
See my comment below: Can you create a system that allows software
drivers
to verify that they (the drivers) are compatible with a particular IP
version? For the novice user, the "full auto" system probably works
fine, but for (some, at least) experienced users, it tends to be an
additional layer or complexity (or opacity) that would be nice to get
rid
of.
>=20
> Having the ability to make rapid hardware changes, I think, is a bit
> different from what most folks are used to.
I agree. I think we all need to agree how best to manage the
driver code so that as IP versions change, the drivers can be properly
matched to the IP. Also, as more and more people port Linux to their
Virtex designs, we can (hopefully) expect more "out of the box"
support for Xilinx hardware. That's basically the situation you have
with more conventional peripheral devices.
[John]
Yep, we'd like this too.
I don't think that there are any "version" registers in the Xilinx=20
IP cores that a driver could check to determine compatibility. That
would be very cheap to implement in hardware and you could then
develop more universal drivers.
[John]
We've examined doing this in the past, and gotten some push back due to
the use of bram or other resources. Conceptually, it's a great idea, I
just don't know if this is likely to happen any time soon.
>=20
> Cheers,
>=20
> - John
>=20
> -----Original Message-----
> From: linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org] On
> Behalf Of Keith J Outwater
> Sent: Thursday, September 14, 2006 9:48 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Ethernet driver for Linux kernel 2.6 running on ML403
>=20
> Grant,
> You bring up excellent points, and I am having to deal with these
> issues in my 2.4.x kernel and U-Boot ports to VirtexII Pro FPGAs
> as well.
>=20
> > On 9/14/06, Michael Galassi <mgalassi@c-cor.com> wrote:
> > > It is also worth noting that as released in MVL pro 4.0.1 it only
> > > supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
> > > tagged as deprecated in the current version (8.2.01i) of Xilinx's
> > > EDK. The current version of {plb,hard}_temac (3.00.a) goes to
great
> > > lengths to break compatibility with older versions. This will
> > > presumably be fixed next month when it is rumored that wonderful
new
> > > things will come from Xilinx. In the mean-time it is possible,
> though
> > > neither simple, nor fun, to create Virtex4 designs with the older
> IP.
>=20
> I think the general case is that Xilinx IP will be constantly
evolving,=20
> and
> Xilinx driver code, when released under the GPL, will appear
> sporadically.
> Maybe it's best to resign ourselves to the fact that this situation
> probably won't change, and then try to deal with it in a way that does
> not depend so heavily on Xilinx drivers.
>=20
> >=20
> > So what direction do we (as the community) want to go for supporting
> > Xilinx IP in the Linux kernel?
>=20
> I don't know about anyone else, but running Linux on Virtex FPGAs is
> something I simply have to be able to do. With or without Xilinx
> drivers, I think the kernel needs to support Xilinx hardware.
>=20
> >=20
> > IIRC, Xilinx intends to get drivers submitted into mainline. (Based
> > on their cross-platform driver support code). It is unknown which
and
> > how many drivers for different IP versions will be submitted.
>=20
> That's part of the problem: we seem to get support for some
> IP cores, but not all. Xilinx takes a piecemeal approach
> to releasing drivers under the GPL.
>=20
> >=20
> > However, the xilinx driver code is verbose and does not match well
> > with the rest of the Linux code base. (due to the cross platform
> > support) Plus, the Xilinx tool work flow is geared towards the EDK
> > tool overwriting the driver code in the kernel tree with code for
the
> > generated design. In which case, does it even make sense to accept
> > Xilinx drivers into the Linux tree when they are just going to get
> > overwritten by the toolchain anyway? Unfortunately, regenerating
> > drivers has it's own problems considering that the license on the
> > generated code is not GPL compatible at the moment.
>=20
> Same complaints apply for Xilinx drivers in the U-Boot bootloader.
> It is proving very difficult to get Xilinx code into U-Boot which
means
> BSPs that use the code are hard to get submitted as well.
>=20
> The Xilinx approach of overwriting the source tree just feels wrong,
and
> no one seems to want to do it that way.
>=20
> >=20
> > If we reject the Xilinx driver code, then we either have to do
without
> > Xilinx support in mainline, or we need to write new drivers that
> > address the above issues (support multiple IP versions, etc). The
> > Xilinx support in mainline right now does not use any Xilinx code.
> > (Xilinx PIC and UART).
> >=20
> > Thoughts?
>=20
> As painful as it may be, maybe we just write drivers from scratch and
> try to track changes in the IP.
>=20
> Regards,
> Keith Outwater
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: 11-16-05 2.6.14 on AMCC Yosemite boar d(PCI-IDE card boot error)
From: David Hawkins @ 2006-09-14 18:01 UTC (permalink / raw)
To: stonepine; +Cc: linuxppc-embedded
In-Reply-To: <450996FB.5050408@126.com>
> The problem was addressed with your help, and I do really appreciate your help.
Great!
I hope you learned your lesson though: when something breaks, make
sure to re-test using the head of the git repo. Of course that may
break something too, but most other developers will also be working
from the head, so can probably reproduce your problem.
(Or will be more likely to listen to any complaints).
Also its worth writing a couple of simple drivers; one that
maps a PCI IO memory space and another that maps PCI memory
space. That way you can cause the machine check in a very
basic driver, i.e., your problem had nothing to do with
your specific card.
Take a look at the LNX-723 document and code, I wrote
it while using a Yosemite board, but have moved on
to a Freescale MPC8349E device, since the 440EP wasn't
going to work for my application:
http://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html
Here's a copy of my test notes:
http://www.ovro.caltech.edu/~dwh/powerpc_440ep.pdf
Cheers
Dave
^ permalink raw reply
* Uncompressing Linux failure
From: wei.li4 @ 2006-09-14 18:15 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I got the following error when I ported linux 2.6.18-rc2-g73a589b5 to
my board(MPC875), my bootloader is working fine with linux 2.6.13, and
I am using same cross-tools from ELDK 4.0:
loaded at: 00400000 00529124
board data at: 00FFFEA8 00FFFF2C
relocated to: 00404068 004040EC
zimage at: 00404EE1 00526337
avail ram: 0052A000 01000000
Uncompressing Linux...inflate returned FFFFFFFE
exit
Can you advise me? thanks.
Wei
^ permalink raw reply
* Re: 11-16-05 2.6.14 on AMCC Yosemite boar d(PCI-IDE card boot error)
From: stonepine @ 2006-09-14 17:52 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <4508A606.90505@ovro.caltech.edu>
Hi Dave,
The problem was addressed with your help, and I do really appreciate your help.
David Hawkins wrote:
>Stephen Yee wrote:
>
>
>>Hi All,
>>
>>I have tested and debuged the ELDK's kernel 2.6.14 with PDC20269 PCI-IDE
>>card, the system paniced when it run the 'ide_pci_setup_ports' funcation
>>[drivers/ide/setup_pci.c], the attached files included the entry log
>>messages, and ksysoops messages when the kernel paniced, and my kernel
>>configuration file and BDI2000 configuration file.
>>
>>would you please give some advice about this issue?
>>
>>
>
>When I was testing this board, I received a machine check
>in earlier kernels due to;
>
> The kernel header for the Yosemite board has an error that
> incorrectly sets the base address for PCI I/O space. The define
> for the 36-bit PCI I/O base address in the file
> arch/ppc/platforms/4xx/yosemite.h needs to be set to
>
>#define YOSEMITE_PCI_IO_BASE 0x00000000e8000000ULL
>
>Check your kernel source, perhaps that is the issue.
>
>Stephan at Denx found and fixed this a while back (over 6 months
>ago). So when in doubt, use the latest-and-greatest kernel, eg.,
>use git and access the Denx repo.
>
>Dave
>
>
>
>
>
>
^ permalink raw reply
* Re: help on finding xilinx_enet for 2.6
From: David H. Lynch Jr @ 2006-09-14 19:06 UTC (permalink / raw)
To: Aleck Lin, linuxppc-embedded
In-Reply-To: <001601c6d82d$675af520$800101df@monstertop>
[-- Attachment #1: Type: text/plain, Size: 3884 bytes --]
Aleck Lin wrote:
>
> David,
>
>
>
> I saw your post from last year
> (http://ozlabs.org/pipermail/linuxppc-embedded/2005-November/021090.html)
>
>
>
> And I have a couple of questions.
>
> 1. Were you able to use the Xilinx_enet from 2.4 tree for kernel 2.6??
> 2. I'm assuming that you've probably have made it work by now. Can
> I get some hints on making the ethernet driver for 2.6?
>
>
>
> Thanks!
>
>
>
> Aleck
>
Aleck;
I have been doing board bringup for the Pico E1x series of boards.
They are Xilinx V4 boards.
I started with the Linux 2.6 kernel.org tree before there was any
Xilinx V4 support - I have subsequently conformed
my code to Grant's patches.
I looked at the MV xilinx_edk stuff for UartLite and Ethernet and
decided their code just looked too gnarly.
I wrote a UartLite driver of my own from scratch. It was fairly
simple and I have Uartlite support from the early boot code on.
I started the TEMAC much later. Pico had me work with the LocalLink
TEMAC at first. That was an almost from scratch driver.
It was just barely working when they switched gears and decided to
use the PLB FIFO TEMAC.
I pulled the MV 2.6 TEMAC driver from the patches posted on this
list - NOT from the 2.4 tree - though there is an obvious common heritage.
That driver works fine - given the caveat I listed - it does NOT
have PHY/MII autonegotiation support. It is not difficult to hardcode
for whatever
fixed speed you want, but the caveat is still there. Purportedly,
proper support is complete or nearly complete - but I have not seen it
posted.
In the interim I started a from scratch PLB FIFO TEMAC driver. It
does NOT support SG DMA - I think Xilinx is now insisting you build the
PLB TEMAC one way or the other, but you can't build it both. As such
I do not beleive the driver should be designed to be able to dynamic
mode switching
on a condition that can not change dynamically - byt the
MV/Xilinx_EDK driver does.
I also had another motive for doing a from scratch driver - I had a
contract to write basically the same driver for GHS Integrity.
I basically took the Linux driver gutted the Linux specific
interfaces, added the GHS interfaces and created a Linux like sk_buff
shim for GHS and had the thing working in fairly
short order. In fact the GHS driver works better than the Linux
driver at the moment. It was also a higher priority.
I am only just getting back to cleaning up and fixing the Linux
driver - so it still has a few minor problems and I need to pick up some
improvements that occured as it
moved forward to GHS.
My from scratch driver very loosely used the EDK code as a starting
point. It drew atleast as much from my LL TEMAC. Right now it sends
fine. Autonegotiates
10/100/1000 FD. It appears to receive fine, but Linux silently
dropps the received packets without reporting an error.
Whatever the problem is - it is with my driver. It is almost
certainly trivial. It is also almost certainly going to be a bear to find.
I had hoped someone with a similar problem (on any driver) might
have given me a clue how they fixed it. But so far no joy.
I only recently got back to work on the Linux driver. I do expect it
will be complete soon.
In the meantime the posted MV Xilinx_edk based driver works - within
its limits.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 7748 bytes --]
^ permalink raw reply
* Re: Please pull powerpc.git 'merge' branch
From: Linus Torvalds @ 2006-09-14 19:14 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17671.64971.450232.870486@cargo.ozlabs.ibm.com>
On Wed, 13 Sep 2006, Paul Mackerras wrote:
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
Hmm. I'm not at all sure this pull caused the problem, and it may have
started long before, but right now I have problems printing on my G5
machine.
I'll get around to trying to bisect it at some point, but before I even
start, I should probably check if anybody recognizes this immediately.
I blamed cupsd at first, because the problem ends up being that it just
hangs in running state, and I just assumed it was broken user space as
usual. But straceing the dang thing shows something strange, like this:
...
time(NULL) = 1024 <0.000009>
select(1024, [7 8 9 10 11 12 13 14], [], NULL, {1, 0}) = 0 (Timeout) <0.000006>
time(NULL) = 1024 <0.000006>
select(1024, [7 8 9 10 11 12 13 14], [], NULL, {1, 0}) = 0 (Timeout) <0.000004>
time(NULL) = 1024 <0.000007>
select(1024, [7 8 9 10 11 12 13 14], [], NULL, {1, 0}) = 0 (Timeout) <0.000006>
time(NULL) = 1024 <0.000007>
select(1024, [7 8 9 10 11 12 13 14], [], NULL, {1, 0}) = 0 (Timeout) <0.000005>
...
which actually looks like something is broken (it says timeout in 5
microseconds, even though the timeout structure is shown as being one
second).
Now, it's entirely possible that the _broken_ thing is actually strrace
itself (that return value from "time()" looks a bit strange too), and that
it's some tracing problem with rinning 32-bit programs on a 64-bit kernel.
But I thought I'd ask if somebody recognizes this before I start wasting
any more time on it..
Linus
^ permalink raw reply
* [PATCH] Add AT_PLATFORM value for Xilinx Virtex-4 FX
From: Peter Bergner @ 2006-09-14 19:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jakub Jelinek
Jakub noticed the cputable.c entry for Xilinx Virtex-4 FX was missing
a .platform value, so the AT_PLATFORM value wouldn't be set correctly.
This patch adds it.
Peter
Signed-off-by: Peter Bergner <bergner@vnet.ibm.com>
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 272e436..518b808 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -929,6 +929,7 @@ struct cpu_spec cpu_specs[] = {
PPC_FEATURE_HAS_MMU | PPC_FEATURE_HAS_4xxMAC,
.icache_bsize = 32,
.dcache_bsize = 32,
+ .platform = "ppc405",
},
{ /* 405EP */
.pvr_mask = 0xffff0000,
^ permalink raw reply related
* RE: Ethernet driver for Linux kernel 2.6 running on ML403
From: T Ziomek @ 2006-09-14 22:02 UTC (permalink / raw)
To: Keith J Outwater, john.bonesio; +Cc: linuxppc-embedded
In-Reply-To: <OF1385C39A.BEB9B9E6-ON072571E9.005DAC98-072571E9.0060ABAE@mck.us.ray.com>
>> << The Xilinx approach of overwriting the source tree just feels wrong,
>> and
>> no one seems to want to do it that way.>>
>>
>> I am in the group that has control over how this is done. What would you
>> propose be done different? Keep in mind that we are trying to support a
>> process where someone builds a hardware design and the later changes it
>> with new peripherals or perhaps makes minor tweaks. We want to make the
>> updating of the Linux kernel to reflect these hardware changes easy for
>> people.
>
> A noble goal, and clearly the right thing to do from a user-success point
> of view, but do the hardware peripherals (i.e. the IP cores) change that
> much?
Driver-per-version (i.e. separate drivers for 'xilinx_emac_1_00_b', 1_00_c,
etc.) is the most obvious but unlikely to be accepted, and it would lead to
lots of duplicated code. How about having a single driver that supports
all versions of xilinx_emac, and adding the specific IP version info in the
kernel config? So we would have, for example, CONFIG_XILINX_ENET_1_00_C,
or whatever, in addition to or in place of CONFIG_XILINX_ENET. The neces-
sary adjustments would generally be made via conditionally compiled code in
the driver source, or in the driver's Makefile when the version differences
are larger in scope.
>From what I've seen this is pretty consistent with The Kernel Way... And
it'd force the kernel builder to be aware of what IP version(s) are in
their hardware.
Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: Ethernet driver for Linux kernel 2.6 running on ML403
From: Grant Likely @ 2006-09-14 22:49 UTC (permalink / raw)
To: John Bonesio; +Cc: linuxppc-embedded
In-Reply-To: <2FE3DBF1797A1443AAB3FA0EF6BF4EEC021EA645@XSJ-EXCHVS1.xlnx.xilinx.com>
On 9/14/06, John Bonesio <john.bonesio@xilinx.com> wrote:
<snip>
> << Same complaints apply for Xilinx drivers in the U-Boot bootloader.
> It is proving very difficult to get Xilinx code into U-Boot which means
> BSPs that use the code are hard to get submitted as well.>>
>
> I've only touched on U-Boot a little bit. Have any thoughts on how to
> make this easier?
U-Boot has the same issues as Linux
- Xilinx drivers don't match the coding style
- The license boilerplate is not GPL compatible
- The IP can change rapidly, so do the drivers belong in the u-boot
mainline tree?
- Current code is not set up to support multiple drivers in the code
base. (I know it's possible, but it's not being done at the moment)
(and see my comments on Linux below)
>
> << The Xilinx approach of overwriting the source tree just feels wrong,
> and no one seems to want to do it that way.>>
>
> I am in the group that has control over how this is done. What would you
> propose be done different? Keep in mind that we are trying to support a
> process where someone builds a hardware design and the later changes it
> with new peripherals or perhaps makes minor tweaks. We want to make the
> updating of the Linux kernel to reflect these hardware changes easy for
> people.
Simply generating code and inserting it into the kernel tree itself is
okay on the surface, but the current scheme is distasteful. I would
make the following recommendations to make it more palatable:
- Keep generated code in a single sub-directory. Don't scatter it all
over the kernel source. ie. generate all code into /xilinx-bsp
instead of bits into /arch/ppc and /drivers.
- Don't overwrite *anything* that from the mainline tree. (Hence the
/xilinx-bsp suggestion above). If you need to modify files in the
tree, like in /arch/ppc, then submit patches for the needed changes
and *don't* try to modify them from within EDK.
- If you want something in mainline; make sure it can coexist with
drivers for other versions of the same IP, or make it support multiple
versions.
- Corollary to the above two points; once a Xilinx provided
patch/driver is accepted into mainline, treat it like the rest of
mainline and don't let EDK overwrite it.
- Regardless of Xilinx's intentions, 3rd party drivers will probably
be written and accepted into mainline. Be prepared to coexist with
them also.
- Stop requiring xparameters.h to be mangled! Generate it correctly
the first time! I think I'll scream if I get handed another xparams
file from an FPGA engineer which was generated as a no-os target. The
Linux redefines are useful, why aren't they in xparameters.h for all
targets?
Unfortunately, generating the drivers ends up being a one way street.
If the code is not in mainline, it will not keep up with changes to
the kernel API, and it is more difficult to get bug fixes into the
driver code from 3rd parties (ie. users need to wait for the next EDK
release cycle before the changes appear in generated code). This is
probably the major reason why writing new 3rd party drivers for
inclusion in mainline is attractive to me.
>
> Having the ability to make rapid hardware changes, I think, is a bit
> different from what most folks are used to.
Different, but manageable.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ 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