* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Benjamin Herrenschmidt @ 2006-03-09 22:11 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <15153.1141912297@www026.gmx.net>
On Thu, 2006-03-09 at 14:51 +0100, Gerhard Pircher wrote:
> Hi,
>
> I'm trying to implement non-coherent DMA for PPC desktop systems (like the
> AmigaOne with G3/G4 CPU). For this I want to use the code in
> arch/ppc/kernel/dma-mapping.c. The DMA memory allocation function
> implemented in this file allocates pages with alloc_pages() and maps them to
> its own linear address space, but without unmapping the allocated pages from
> the kernel linear addressing. Due to this the pages are mapped twice, which
> results in a conflict between the different WIMG settings of the pages.
>
> Is there an API that can be used to unmap the allocated pages from the
> kernel linear addressing? I thought about using kunmap() and
> flush_all_zero_pkmaps(), but I'm not sure if this is the right approach and
> HIGHMEM doesn't work on the AmigaOne too (the highmem base is occupied by
> the PCI/ISA I/O space!). Wouldn't it be possible to just clear the valid (V)
> bit of the PTE and do a TLB cache flush?
The main problem is that the mappings may be covered by a BAT and thus
pages may not be unmappable individually...
What I would suggest is that your dig in the low level RAM mapping code
and limit it at boot to RAM minus a pool of the size you want.
Ben.
^ permalink raw reply
* Re: Virtex-4 TEMAC device driver available?
From: Yoshio Kashiwagi @ 2006-03-09 18:10 UTC (permalink / raw)
To: S. Egbert, linuxppc-embedded
In-Reply-To: <JS200602192039433.11799406@co-nss.co.jp>
Hello Steve San,
Although I was performing porting for the reference design of
xapp902 shown in the following URL, I have noticed that the
temac circuit of this xapp902 cannot perform control of PHY.
The temac circuit of this xapp902 does not have control of PHY.
http://direct.xilinx.com/bvdocs/appnotes/xapp902.pdf
As a result of consulting with our client, our client newly
creates their original temac based on xapp807 design of the
following URL. It is because the function is insufficient
using Linux in this xapp897 design.
http://www.xilinx.com/bvdocs/appnotes/xapp807.pdf
Since I created the temac driver of their design, the release
of the driver to ML became impossible to me.
Best Regaeds,
Yoshio kashiwagi - Nissin Systems
> Hello Steve San,
>
> Strictly, GSRD differs from TEMAC.
> Although both are embedded TEMAC is used in Virtex4, GSRD accesses
> direct memory through MPMC. MPMC is a multi-port memory controller
> for GSRD to access direct memory.
>
> http://www.xilinx.com/esp/wired/optical/xlnx_net/gsrd_download.htm
>
> Download of GSRD is linked out of the above-mentioned URL, and
> becomes a place to be logged in (Registration for downloading the
> reference design short cut).
> http://www.xilinx.com/xlnx/xil_entry2.jsp?sMode=login&group=gsrd
>
> Linux2.4 driver is contained in this GSRD. However, this Linux2.4
> driver (adapter.c) has the fault which does not operate correctly,
> when a 100BASE hub is connected. In order to correct this problem,
> it is necessary to add the interrupt handling routine of PHY.
> Although this GSRD is a reference design more nearly high-speed
> than TEMAC, many FPGA resources are used for it.
>
> I am going to create a TEMAC driver (Linux2.6) by a scratch, I
> cannot make time for it now. Since it is due to make by the end of
> this month, if it is completed, I'll announce it to this mailing
> list.
>
> I'll write the Linux2.6 TEMAC driver corresponding to the following
> reference designs.
> http://direct.xilinx.com/bvdocs/appnotes/xapp902.pdf
> http://www.xilinx.com/bvdocs/appnotes/xapp902.zip
> (The Linux driver is not contained in this reference design)
>
> Best Regards,
>
> Yoshio Kashiwagi - Nissin Systems
>
> > Dear Kashiwagi-San,
> >
> > I noticed in your posting over at linuxppc-embedded in Jan 2006
about
> a
> > Xilinx demo code for the TEMAC driver.
> >
> > So, I pulled the
> > http://www.xilinx.co.jp/ise/embedded/EDK/71i/mpmc_7_1_2.zip file and
> > browsed it.
> >
> > Do you know where one can get a patch for Linux 2.4?
> >
> > Thank you,
> >
> > Steve Egbert
> >
> > --
> > -----BEGIN GEEK CODE BLOCK-----
> > Version: 3.12
> > GAT d- s++: !a C+++ UL++++ P+++ L+++ E W+++ N+ o++ K+++ w--
> > O- M+ V- PS PE++ Y+ PGP++ t++ 5++ X++ R tv- b++ DI+ D+
> > G++ e* h++ r+++ z
> > ------END GEEK CODE BLOCK------
> > GPG Public Key: http://www.egbert.net/pgp
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
------------------------------------------------------------
柏木良夫
株式会社日新システムズ 基礎技術部
Linuxプロフェショナルグループ
〒600-8482 京都市下京区堀川通四条下ル東側 堀川四条ビル
TEL 075-344-7950 FAX 075-344-7887
E-Mail kashiwagi@co-nss.co.jp HTTP http://www.co-nss.co.jp/
------------------------------------------------------------
^ permalink raw reply
* System time accuracy
From: Brent Cook @ 2006-03-09 14:57 UTC (permalink / raw)
To: linuxppc-dev
I'm having a puzzling problem. On every 7448-based Linux system that I have
worked on so far, including:
Mac Mini, 1.5 Ghz
Various PMC boards - MV64460 system controller
Freescale HPC II - TSI108 system controller
, the system clock loses approx 1 second every 5 minutes. In fact, I have been
unable to even get NTP to sync these system clocks properly; it just doesn't
adjust fast enough to keep up with the lag, leading to big drifts and adjtimex
just doesn't keep up. Eventually the systems get more than 180 seconds out of
sync and NTP stops trying.
Is this normal behavior, and if so, what have you done to work around it? Is
this a general issue with PPC arch, Linux 2.6 (tried 2.6.11 - 2.6.15), or
specific to the platforms I have tried so far?
Here is the result of running openntpd on a freshly synced system (this
particular one is the HPC II running 2.6.11):
ntpd -sd
192.168.1.1: offset 0.000066 delay 0.000352, next query 5s
reply from 192.168.1.1: offset 0.010422 delay 0.000242, next query 5s
peer 192.168.1.1 now valid
reply from 192.168.1.1: offset 0.020899 delay 0.000256, next query 5s
reply from 192.168.1.1: offset 0.031362 delay 0.000306, next query 5s
reply from 192.168.1.1: offset 0.041838 delay 0.000316, next query 5s
reply from 192.168.1.1: offset 0.052244 delay 0.000226, next query 287s
reply from 192.168.1.1: offset 0.652178 delay 0.000343, next query 30s
adjusting local clock by 0.052244s
reply from 192.168.1.1: offset 0.684853 delay 0.000275, next query 30s
reply from 192.168.1.1: offset 0.725305 delay 0.000257, next query 30s
reply from 192.168.1.1: offset 0.788057 delay 0.000397, next query 30s
reply from 192.168.1.1: offset 0.850732 delay 0.000291, next query 30s
reply from 192.168.1.1: offset 0.913406 delay 0.000233, next query 30s
reply from 192.168.1.1: offset 0.976180 delay 0.000369, next query 30s
reply from 192.168.1.1: offset 1.038846 delay 0.000279, next query 30s
adjusting local clock by 0.913406s
reply from 192.168.1.1: offset 1.071584 delay 0.000309, next query 30s
reply from 192.168.1.1: offset 1.104273 delay 0.000289, next query 30s
reply from 192.168.1.1: offset 1.136919 delay 0.000273, next query 30s
reply from 192.168.1.1: offset 1.169708 delay 0.000342, next query 30s
reply from 192.168.1.1: offset 1.202390 delay 0.000295, next query 30s
reply from 192.168.1.1: offset 1.235082 delay 0.000252, next query 30s
adjusting local clock by 1.235082s
reply from 192.168.1.1: offset 1.267829 delay 0.000320, next query 30s
For comparison, this is an x86 PC doing the same thing:
ntpd -sd
ntp engine ready
reply from 192.168.1.1: offset -0.025448 delay 0.000618, next query 5s
reply from 192.168.1.1: offset -0.025973 delay 0.000285, next query 9s
reply from 192.168.1.1: offset -0.030136 delay 0.000248, next query 5s
peer 192.168.1.1 now valid
reply from 192.168.1.1: offset -0.033057 delay 0.000293, next query 6s
reply from 192.168.1.1: offset -0.036570 delay 0.000321, next query 5s
reply from 192.168.1.1: offset -0.039546 delay 0.000231, next query 5s
reply from 192.168.1.1: offset -0.042481 delay 0.000289, next query 34s
reply from 192.168.1.1: offset -0.062430 delay 0.000264, next query 32s
adjusting local clock by -0.039546s
reply from 192.168.1.1: offset -0.049193 delay 0.000264, next query 307s
reply from 192.168.1.1: offset -0.052205 delay 0.000299, next query 307s
reply from 192.168.1.1: offset -0.078816 delay 0.000284, next query 309s
reply from 192.168.1.1: offset -0.010273 delay 0.000336, next query 326s
reply from 192.168.1.1: offset -0.038518 delay 0.000279, next query 323s
reply from 192.168.1.1: offset -0.066434 delay 0.000314, next query 312s
adjusting local clock by -0.049193s
Now, none of these PPC systems has /dev/rtc (the x86 does), but that should
not matter, since the real-time clock is usually used in Linux a boot or
shutdown.
^ permalink raw reply
* Re: [PATCH] Fix platform_notify functions marked __init
From: Mark A. Greer @ 2006-03-09 17:36 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-dev
In-Reply-To: <1141855821.28095.18.camel@localhost.localdomain>
On Wed, Mar 08, 2006 at 10:10:20PM +0000, Adrian Cox wrote:
> While adding USB support to an MV64360 based board this week, I
> discovered that all MV64x60 boards in the kernel have platform_notify
> functions marked with __init. This causes an oops if a device is added
> after boot.
>
> The patch below removes the __init markers. I do not have all these
> boards to test on, but the change seems very unlikely to break anything
> else.
Arg... I realized this a long time ago and fixed it in my tree.
Somewhere along the line, I dropped it, I guess.
Thanks for the patch Adrian.
Mark
^ permalink raw reply
* Unmapping pages from the linear addressing without HIGHMEM support
From: Gerhard Pircher @ 2006-03-09 13:51 UTC (permalink / raw)
To: linuxppc-dev, debian-powerpc
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1048 bytes --]
Hi,
I'm trying to implement non-coherent DMA for PPC desktop systems (like the
AmigaOne with G3/G4 CPU). For this I want to use the code in
arch/ppc/kernel/dma-mapping.c. The DMA memory allocation function
implemented in this file allocates pages with alloc_pages() and maps them to
its own linear address space, but without unmapping the allocated pages from
the kernel linear addressing. Due to this the pages are mapped twice, which
results in a conflict between the different WIMG settings of the pages.
Is there an API that can be used to unmap the allocated pages from the
kernel linear addressing? I thought about using kunmap() and
flush_all_zero_pkmaps(), but I'm not sure if this is the right approach and
HIGHMEM doesn't work on the AmigaOne too (the highmem base is occupied by
the PCI/ISA I/O space!). Wouldn't it be possible to just clear the valid (V)
bit of the PTE and do a TLB cache flush?
Any suggestions?
Thanks!
Regards,
Gerhard
--
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
^ permalink raw reply
* Re: [Patch] Fix compile error for ML300/403
From: Andrei Konovalov @ 2006-03-09 13:33 UTC (permalink / raw)
To: Grant Likely; +Cc: Paul Mackerras, linuxppc-embedded list
In-Reply-To: <528646bc0603081507t24c7e2f5u8e2823931200a857@mail.gmail.com>
Hi Grant,
Grant Likely wrote:
> Fix compile error due to changes in ppc_sys.c. This is needed in the
> powerpc.git tree
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> ---
> commit 75ec8a6ff8410c30f459e5e1c924ce811f8b1e25
> tree 87f29c44458d2966bf208f9ea25432b26faa2eb5
> parent 126dddf2535520cbeafb7069ce092b80beb8558a
> author Grant Likely <grant.likely@secretlab.ca> Wed, 08 Mar 2006 16:03:56 -0700
> committer <grant@weasley-twins.(none)> Wed, 08 Mar 2006 16:03:56 -0700
>
> arch/ppc/platforms/4xx/virtex.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virtex.h
> index 2a2a65c..4d893ef 100644
> --- a/arch/ppc/platforms/4xx/virtex.h
> +++ b/arch/ppc/platforms/4xx/virtex.h
> @@ -27,7 +27,7 @@
> /* Device type enumeration for platform bus definitions */
> #ifndef __ASSEMBLY__
> enum ppc_sys_devices {
> - VIRTEX_UART, VIRTEX_FB,
> + VIRTEX_UART, VIRTEX_FB, NUM_PPC_SYS_DEVS,
AFAIK there is no VIRTEX_FB in the powerpc.git tree yet.
Otherwise I confirm that adding NUM_PPC_SYS_DEVS is necessary.
Thanks,
Andrei
> };
> #endif
>
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Yosemite board ala, PPC405EP
From: Stefan Roese @ 2006-03-09 13:18 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Jeff.Fellin
In-Reply-To: <440F4DA2.3040706@ovro.caltech.edu>
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]
On Wednesday, 8. March 2006 22:33, David Hawkins wrote:
> > Sorry, I was confused. I have a PPC405EP. not a Yosemite board.
>
> Ok, sorry then, I can't help.
>
> Take a look at the Denx web site, they have a bunch of
> BDI2000 configuration files, I'm not sure whether they
> have a 405EP, but take a look.
Yes, we have. Take a look at the attached bubinga config file (AMCC 405EP
evaluation board).
The 405EP is quite different from the 405GP(r) regarding it initialization.
The PLL is setup normally not via strapping pins as on the 405GP(r) but by
reading values from a EEPROM. This can behavior can be configured by one
strapping pin (don't know which one right now). Please take a look at the PLL
setup in the BDI config file.
Best regards,
Stefan
[-- Attachment #2: bubinga.cfg --]
[-- Type: text/plain, Size: 4625 bytes --]
;bdiGDB configuration file for PPChameleonEVB for U-Boot
; ------------------------------------------------------
;
[INIT]
; init core register
WSPR 954 0x00000000 ;DCWR: Disable data cache write-thru
WSPR 1018 0x00000000 ;DCCR: Disable data cache
WSPR 1019 0x00000000 ;ICCR: Disable instruction cache
WSPR 982 0xFFF80000 ;EVPR: Exception Vector Table @0x00000000
;
WDCR 0x0F9 0x08000000
; Setup PLL
; CPU=133MHz
; PLB=133MHz
; OPB=66MHz
; EBC=33MHz
WDCR 0x0F0 0x00001203
WDCR 0x0F4 0x8042223E
; Setup Peripheral Bus
; CS0 (default mode)
WDCR 18 0x00000010 ;Select PB0AP
WDCR 19 0x92015480 ;PB0AP: NOR Flash/SRAM
WDCR 18 0x00000000 ;Select PB0CR
;WDCR 19 0xFFC5A000 ;PB0CR: BAS=0xFFC,BS=4MB,BU=R/W,BW=16bit
WDCR 19 0xFFC58000 ;PB0CR: BAS=0xFFC,BS=4MB,BU=R/W,BW=8bit
WDCR 18 0x00000011 ;Select PB1AP
WDCR 19 0x92015480 ;PB1AP: SRAM/NOR Flash
WDCR 18 0x00000001 ;Select PB1CR
WDCR 19 0xFF85A000 ;PB1CR: BAS=0xFF8,BS=4MB,BU=R/W,BW=16bit
;WDCR 18 0x00000011 ;Select PB1AP
;WDCR 19 0x02815480 ;PB1AP: NVRAM and RTC
;WDCR 18 0x00000001 ;Select PB1CR
;WDCR 19 0xF0018000 ;PB1CR: 1MB at 0xF0000000, r/w, 8bit
;WDCR 18 0x00000012 ;Select PB2AP
;WDCR 19 0x04815A80 ;PB2AP: Keyboard and Mouse
;WDCR 18 0x00000002 ;Select PB2CR
;WDCR 19 0xF0118000 ;PB2CR: 1MB at 0xF0100000, r/w, 8bit
;WDCR 18 0x00000013 ;Select PB3AP
;WDCR 19 0x01815280 ;PB3AP: IRDA
;WDCR 18 0x00000003 ;Select PB3CR
;WDCR 19 0xF0218000 ;PB3CR: 1MB at 0xF0200000, r/w, 8bit
;WDCR 18 0x00000017 ;Select PB7AP
;WDCR 19 0x01815280 ;PB7AP: FPGA
;WDCR 18 0x00000007 ;Select PB7CR
;WDCR 19 0xF0318000 ;PB7CR: 1MB at 0xF0300000, r/w, 8bit
; Setup SDRAM Controller
WDCR 16 0x00000080 ;Select SDTR1
WDCR 17 0x01074015 ;SDTR1: SDRAM Timing Register
WDCR 16 0x00000040 ;Select MB0CF
WDCR 17 0x00084001 ;MB0CF: 16MB @ 0x00000000
WDCR 16 0x00000030 ;Select RTR
WDCR 17 0x07f00000 ;RTR: Refresh Timing Register
WDCR 16 0x00000020 ;Select MCOPT1
WDCR 17 0x80800000 ;MCOPT1: Enable SDRAM Controller
; Setup MMU info - these lines must be uncommented to debug Linux kernel
;WM32 0x000000f4 0x00000000 ;invalidate kernel page table base
;WM32 0x000000f8 0x00000000 ;invalidate process page table base
;WM32 0x000000f0 0xc00000f4 ;invalidate page table base
; Setup OCM
WDCR 0x01A 0xEC000000
WDCR 0x01B 0xC0000000
[TARGET]
JTAGCLOCK 0 ;use 16 MHz JTAG clock
CPUTYPE 405 ;the used target CPU type
BDIMODE AGENT ;the BDI working mode (LOADONLY | AGENT)
WAKEUP 2000 ;wakeup time after reset
BREAKMODE HARD ;SOFT or HARD, HARD uses PPC hardware breakpoint
STEPMODE HWBP ;JTAG or HWBP, HWPB uses one or two hardware breakpoints
;VECTOR CATCH ;catch unhandled exceptions
;MMU XLAT 0xC0000000 ;enable virtual address mode
;PTBASE 0x000000f0 ;address where kernel/user stores pointer to page table
;SIO 7 9600 ;TCP port for serial IO
;REGLIST SPR ;select register to transfer to GDB
REGLIST ALL ;select register to transfer to GDB
;SCANPRED 2 2 ;JTAG devices connected before PPC400
;SCANSUCC 3 3 ;JTAG devices connected after PPC400
[HOST]
IP 192.168.1.1
FORMAT BIN
FILE /tftpboot/bubinga/u-boot.bin
LOAD MANUAL ;load code MANUAL or AUTO after reset
DEBUGPORT 2001
PROMPT PPC405EP>
[FLASH]
; ###FIXME### - workspace does not work with onchip memory
WORKSPACE 0x100000 ;workspace in on-chip SRAM for fast programming algorithm
; WORKSPACE 0 ;workspace in on-chip SRAM for fast programming algorithm
;CHIPTYPE AM29BX16 ;Flash type (AM29F | AM29BX8 | AM29BX16 | I28BX8 | I28BX16)
;CHIPSIZE 0x400000 ;The size of one flash chip in bytes (e.g. AM29F040 = 0x80000)
;BUSWIDTH 16 ;The width of the flash memory bus in bits (8 | 16 | 32)
CHIPTYPE AM29F ;Flash type (AM29F | AM29BX8 | AM29BX16 | I28BX8 | I28BX16)
CHIPSIZE 0x80000 ;The size of one flash chip in bytes (e.g. AM29F040 = 0x80000)
BUSWIDTH 8 ;The width of the flash memory bus in bits (8 | 16 | 32)
FILE /tftpboot/bubinga/u-boot.bin
FORMAT BIN 0xFFFC0000
; erase whole Flash
;ERASE 0xFFC00000 CHIP
; Erase just the last seven blocks for U-Boot
ERASE 0xFFFC0000
ERASE 0xFFFD0000
ERASE 0xFFFE0000
ERASE 0xFFFF0000
[REGS]
IDCR1 0x010 0x011 ;MEMCFGADR and MEMCFGDATA
IDCR2 0x012 0x013 ;EBCCFGADR and EBCCFGDATA
;IDCR3 0x014 0x015 ;KIAR and KIDR
FILE /tftpboot/BDI2000/reg405ep.def
^ permalink raw reply
* Re: linux DMA capabilities in MV64460
From: Phil Nitschke @ 2006-03-09 8:02 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-embedded
In-Reply-To: <1141857378.28095.22.camel@localhost.localdomain>
On Wed, 2006-03-08 at 22:36 +0000, Adrian Cox wrote:
> On Mon, 2006-03-06 at 14:39 +1030, Phil Nitschke wrote:
> > How is a DMA controlled (from a device driver writer's perspective) when
> > a third-party (i.e. in the bridge) DMA controller needs to do the work
> > to get the data from a PCI Target into main memory?
> >
> > What kernel API should be provided by the DMA Controller Driver?
>
> There is no current API for this in the kernel, but there are some
> proposals. From Intel, we have I/OAT, which targets network operations:
> http://lkml.org/lkml/2006/3/3/219
>
> There's some overlap with the ADMA feature set, which is intended to
> accelerate RAID operations:
> http://lkml.org/lkml/2006/2/2/442
>
Thanks, Adrian, these are the sorts of APIs I was asking about. At a
quick glance, they look a little "bleeding edge" for my comfort zone.
(And not an exact match for what I'm trying to do...) Nonetheless, I'll
take a closer look at them.
Thanks,
--
Phil Nitschke <Phil.Nitschke@avalon.com.au>
Avalon Systems Pty Ltd
^ permalink raw reply
* RE: [PATCH] Fix MPC8548CDS rebooting procedure
From: Haruki Dai-r35557 @ 2006-03-09 4:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Wednesday, March 08, 2006 9:14 PM
> To: Haruki Dai-r35557
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Fix MPC8548CDS rebooting procedure
>=20
>=20
> On Mar 8, 2006, at 1:24 PM, Haruki Dai-r35557 wrote:
>=20
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >> Sent: Wednesday, March 08, 2006 12:33 PM
> >> To: Haruki Dai-r35557
> >> Cc: linuxppc-dev@ozlabs.org
> >> Subject: Re: [PATCH] Fix MPC8548CDS rebooting procedure
> >>
> >>
> >> On Mar 8, 2006, at 11:22 AM, Haruki Dai-r35557 wrote:
> >>
> >>> This patch fixes the MPC8548 CDS rebooting procedure.
> >>> Without this patche, issuing reboot from shell doesn't reboot the=20
> >>> machine.
> >>>
> >>> Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
> >>
> >> Dai, I'm avoid taking patches for 85xx that effect new=20
> functionality. =20
> >> If you want change this to work with arch/powerpc and make=20
> it a run=20
> >> time check for 8548.
> >
> > Hi Kumar, what kind of new feature is affected by this bug=20
> fix? 8548=20
> > requires reboot to set the hardware reset bits. The mpc85xx_restart
> > () is
> > not ported to arch/powerpc yet. Which portion of the=20
> arch/powerpc code=20
> > should be modified in order to restart the machine correctly?
> > And how do you want me to do run time check? Check SVR?
>=20
> Restart has never worked properly on the 85xx boards from=20
> freescale since they never provided a reasonable way to reset=20
> the systems in software. So I consider this new=20
> functionality at this point.
>=20
> The powerpc.git tree has an=20
> arch/powerpc/platforms/85xx/misc.c that has a mpc85xx_restart() in it.
Thanks. I didn't work on the powerpc.git tree. I will submit the patch
based on the powerpc.git tree.
>=20
> As for run time checking, yes use something like SVR or PVR=20
> to determine the feature. In this case its probably best to=20
> using something like PVR and check for E500r1. I imagine=20
> 8540, 8541, 8555, 8560 don't support this feature (all=20
> e500r1), but all future 8548 and newer parts will (e500r2, etc.)
OK. I will modify it as you suggest.=20
regards,
Dai.
>=20
> - kumar
>=20
^ permalink raw reply
* Re: [PATCH] Fix MPC8548CDS rebooting procedure
From: Kumar Gala @ 2006-03-09 3:13 UTC (permalink / raw)
To: Haruki Dai-r35557; +Cc: linuxppc-dev
In-Reply-To: <18AEF66AFDF06F4CAAA1D419D000FD332ECDEA@az33exm24.fsl.freescale.net>
On Mar 8, 2006, at 1:24 PM, Haruki Dai-r35557 wrote:
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Wednesday, March 08, 2006 12:33 PM
>> To: Haruki Dai-r35557
>> Cc: linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH] Fix MPC8548CDS rebooting procedure
>>
>>
>> On Mar 8, 2006, at 11:22 AM, Haruki Dai-r35557 wrote:
>>
>>> This patch fixes the MPC8548 CDS rebooting procedure.
>>> Without this patche, issuing reboot from shell doesn't reboot the
>>> machine.
>>>
>>> Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
>>
>> Dai, I'm avoid taking patches for 85xx that effect new
>> functionality. If you want change this to work with
>> arch/powerpc and make it a run time check for 8548.
>
> Hi Kumar, what kind of new feature is affected by this bug fix? 8548
> requires reboot to set the hardware reset bits. The mpc85xx_restart
> () is
> not ported to arch/powerpc yet. Which portion of the arch/powerpc code
> should be modified in order to restart the machine correctly?
> And how do you want me to do run time check? Check SVR?
Restart has never worked properly on the 85xx boards from freescale
since they never provided a reasonable way to reset the systems in
software. So I consider this new functionality at this point.
The powerpc.git tree has an arch/powerpc/platforms/85xx/misc.c that
has a mpc85xx_restart() in it.
As for run time checking, yes use something like SVR or PVR to
determine the feature. In this case its probably best to using
something like PVR and check for E500r1. I imagine 8540, 8541, 8555,
8560 don't support this feature (all e500r1), but all future 8548 and
newer parts will (e500r2, etc.)
- kumar
^ permalink raw reply
* Re: please pull powerpc-merge.git
From: Paul Mackerras @ 2006-03-09 0:55 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, torvalds
In-Reply-To: <20060308080816.GA16866@suse.de>
Olaf Hering writes:
> On Wed, Mar 08, Paul Mackeras wrote:
>
> > powerpc: incorrect rmo_top handling in prom_init
>
> I would leave this one out. It gives the false impression that ibook1
> works ok, while later it will likely eat your filesystem. Its not a
> regression in that sense because 2.6.15 was also broken and noone
> complained.
Ben H and I agree that the fix makes sense and is correct and should
go in for 2.6.16. Your iBook crashes are a separate problem.
Paul.
^ permalink raw reply
* [Patch] Fix compile error for ML300/403
From: Grant Likely @ 2006-03-08 23:07 UTC (permalink / raw)
To: linuxppc-embedded list, Matt Porter, Paul Mackerras
Fix compile error due to changes in ppc_sys.c. This is needed in the
powerpc.git tree
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
commit 75ec8a6ff8410c30f459e5e1c924ce811f8b1e25
tree 87f29c44458d2966bf208f9ea25432b26faa2eb5
parent 126dddf2535520cbeafb7069ce092b80beb8558a
author Grant Likely <grant.likely@secretlab.ca> Wed, 08 Mar 2006 16:03:56 -=
0700
committer <grant@weasley-twins.(none)> Wed, 08 Mar 2006 16:03:56 -0700
arch/ppc/platforms/4xx/virtex.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virte=
x.h
index 2a2a65c..4d893ef 100644
--- a/arch/ppc/platforms/4xx/virtex.h
+++ b/arch/ppc/platforms/4xx/virtex.h
@@ -27,7 +27,7 @@
/* Device type enumeration for platform bus definitions */
#ifndef __ASSEMBLY__
enum ppc_sys_devices {
- VIRTEX_UART, VIRTEX_FB,
+ VIRTEX_UART, VIRTEX_FB, NUM_PPC_SYS_DEVS,
};
#endif
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply related
* Re: linux DMA capabilities in MV64460
From: Adrian Cox @ 2006-03-08 22:36 UTC (permalink / raw)
To: Phil.Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <kwlkvomcxp.fsf@lamorak.int.avalon.com.au>
On Mon, 2006-03-06 at 14:39 +1030, Phil Nitschke wrote:
> How is a DMA controlled (from a device driver writer's perspective) when
> a third-party (i.e. in the bridge) DMA controller needs to do the work
> to get the data from a PCI Target into main memory?
>
> What kernel API should be provided by the DMA Controller Driver?
There is no current API for this in the kernel, but there are some
proposals. From Intel, we have I/OAT, which targets network operations:
http://lkml.org/lkml/2006/3/3/219
There's some overlap with the ADMA feature set, which is intended to
accelerate RAID operations:
http://lkml.org/lkml/2006/2/2/442
--
Adrian Cox <adrian@humboldt.co.uk>
^ permalink raw reply
* [PATCH] Fix platform_notify functions marked __init
From: Adrian Cox @ 2006-03-08 22:10 UTC (permalink / raw)
To: linuxppc-dev
While adding USB support to an MV64360 based board this week, I
discovered that all MV64x60 boards in the kernel have platform_notify
functions marked with __init. This causes an oops if a device is added
after boot.
The patch below removes the __init markers. I do not have all these
boards to test on, but the change seems very unlikely to break anything
else.
Signed-off-by: Adrian Cox <adrian@humboldt.co.uk>
diff --git a/arch/ppc/platforms/cpci690.c b/arch/ppc/platforms/cpci690.c
index 6ca7bca..ad1a21e 100644
--- a/arch/ppc/platforms/cpci690.c
+++ b/arch/ppc/platforms/cpci690.c
@@ -290,7 +290,7 @@ cpci690_fixup_mpsc_pdata(struct platform
pdata->brg_clk_freq = cpci690_get_bus_freq();
}
-static int __init
+static int
cpci690_platform_notify(struct device *dev)
{
static struct {
diff --git a/arch/ppc/platforms/ev64260.c b/arch/ppc/platforms/ev64260.c
index ffde8f6..fea4cf8 100644
--- a/arch/ppc/platforms/ev64260.c
+++ b/arch/ppc/platforms/ev64260.c
@@ -416,7 +416,7 @@ ev64260_fixup_mpsc_pdata(struct platform
return;
}
-static int __init
+static int
ev64260_platform_notify(struct device *dev)
{
static struct {
diff --git a/arch/ppc/platforms/ev64360.c b/arch/ppc/platforms/ev64360.c
index b9d844f..e8cc999 100644
--- a/arch/ppc/platforms/ev64360.c
+++ b/arch/ppc/platforms/ev64360.c
@@ -300,7 +300,7 @@ ev64360_fixup_eth_pdata(struct platform_
}
#endif
-static int __init
+static int
ev64360_platform_notify(struct device *dev)
{
static struct {
diff --git a/arch/ppc/platforms/hdpu.c b/arch/ppc/platforms/hdpu.c
index 50039a2..c79e589 100644
--- a/arch/ppc/platforms/hdpu.c
+++ b/arch/ppc/platforms/hdpu.c
@@ -354,7 +354,7 @@ static void __init hdpu_fixup_cpustate_p
}
#endif
-static int __init hdpu_platform_notify(struct device *dev)
+static int hdpu_platform_notify(struct device *dev)
{
static struct {
char *bus_id;
diff --git a/arch/ppc/platforms/katana.c b/arch/ppc/platforms/katana.c
index 6e58e30..b655e53 100644
--- a/arch/ppc/platforms/katana.c
+++ b/arch/ppc/platforms/katana.c
@@ -598,7 +598,7 @@ katana_fixup_mv64xxx_pdata(struct platfo
}
#endif
-static int __init
+static int
katana_platform_notify(struct device *dev)
{
static struct {
diff --git a/arch/ppc/platforms/radstone_ppc7d.c b/arch/ppc/platforms/radstone_ppc7d.c
index 872c0a3..d5c3e92 100644
--- a/arch/ppc/platforms/radstone_ppc7d.c
+++ b/arch/ppc/platforms/radstone_ppc7d.c
@@ -712,7 +712,7 @@ ppc7d_fixup_i2c_pdata(struct platform_de
}
#endif
-static int __init ppc7d_platform_notify(struct device *dev)
+static int ppc7d_platform_notify(struct device *dev)
{
static struct {
char *bus_id;
--
Adrian Cox <adrian@humboldt.co.uk>
^ permalink raw reply related
* Re: Yosemite board ala, PPC405EP
From: David Hawkins @ 2006-03-08 21:33 UTC (permalink / raw)
To: Jeff.Fellin; +Cc: linuxppc-embedded
In-Reply-To: <OF983EDDB6.1E8E12C2-ON8525712B.00750324@teal.com>
> Sorry, I was confused. I have a PPC405EP. not a Yosemite board.
Ok, sorry then, I can't help.
Take a look at the Denx web site, they have a bunch of
BDI2000 configuration files, I'm not sure whether they
have a 405EP, but take a look.
Dave
^ permalink raw reply
* Re: Yosemite board ala, PPC405EP
From: Jeff.Fellin @ 2006-03-08 21:18 UTC (permalink / raw)
To: dwh; +Cc: linuxppc-embedded
Sorry, I was confused. I have a PPC405EP. not a Yosemite board.
Jeff Fellin
RFL Electronics
Jeff.Fellin@rflelect.com
973 334-3100, x 327
David Hawkins
<dwh@ovro.caltech To: Jeff.Fellin@rflelect.com
.edu> cc: linuxppc-embedded@ozlabs.org
Subject: Re: Yosemite board ala, PPC405EP
03/08/2006 15:27
Jeff.Fellin@rflelect.com wrote:
> I have been using an Albatron BDI for a PPC405GP board in a project.
> According to the documentation I've read the Yosemite board is identical
> register wise to the 405GP, except for two sets of EMAC registers.
>
> My problem is when I use the Albatron BDI using the register definitions
> for the 405GP, the BDI cannot communicate with the 405EP.
>
> Anyone have experience with usingg the BDI for the PPC 405EP?
Hey Jeff,
Can you please clarify;
Are you using a Yosemite board (440EP) or are you using a 405EP board
(which is *not* the Yosemite board)?
If you are using the Yosemite board, then I have one here,
and my BDI2000 just arrived. I haven't had a chance to test
the BDI2000, but I can let you know the results when I do.
Dave
^ permalink raw reply
* Re: Yosemite board ala, PPC405EP
From: David Hawkins @ 2006-03-08 20:27 UTC (permalink / raw)
To: Jeff.Fellin; +Cc: linuxppc-embedded
In-Reply-To: <OFFBE09E88.DB8A5C68-ON8525712B.006C3D78@teal.com>
Jeff.Fellin@rflelect.com wrote:
> I have been using an Albatron BDI for a PPC405GP board in a project.
> According to the documentation I've read the Yosemite board is identical
> register wise to the 405GP, except for two sets of EMAC registers.
>
> My problem is when I use the Albatron BDI using the register definitions
> for the 405GP, the BDI cannot communicate with the 405EP.
>
> Anyone have experience with usingg the BDI for the PPC 405EP?
Hey Jeff,
Can you please clarify;
Are you using a Yosemite board (440EP) or are you using a 405EP board
(which is *not* the Yosemite board)?
If you are using the Yosemite board, then I have one here,
and my BDI2000 just arrived. I haven't had a chance to test
the BDI2000, but I can let you know the results when I do.
Dave
^ permalink raw reply
* Re: Yosemite board ala, PPC405EP
From: Eugene Surovegin @ 2006-03-08 20:21 UTC (permalink / raw)
To: Jeff.Fellin; +Cc: linuxppc-embedded
In-Reply-To: <OFFBE09E88.DB8A5C68-ON8525712B.006C3D78@teal.com>
On Wed, Mar 08, 2006 at 02:45:54PM -0500, Jeff.Fellin@rflelect.com wrote:
>
> I have been using an Albatron BDI for a PPC405GP board in a project.
> According to the documentation I've read the Yosemite board is identical
> register wise to the 405GP, except for two sets of EMAC registers.
>
> My problem is when I use the Albatron BDI using the register definitions
> for the 405GP, the BDI cannot communicate with the 405EP.
>
> Anyone have experience with usingg the BDI for the PPC 405EP?
AFAIK, Yosemite is 440EP, not 405EP. And 440EP is quite different from
405GP.
--
Eugene
^ permalink raw reply
* Yosemite board ala, PPC405EP
From: Jeff.Fellin @ 2006-03-08 19:45 UTC (permalink / raw)
To: linuxppc-embedded
I have been using an Albatron BDI for a PPC405GP board in a project.
According to the documentation I've read the Yosemite board is identical
register wise to the 405GP, except for two sets of EMAC registers.
My problem is when I use the Albatron BDI using the register definitions
for the 405GP, the BDI cannot communicate with the 405EP.
Anyone have experience with usingg the BDI for the PPC 405EP?
Thank you in advance for you help.
Jeff Fellin
RFL Electronics
Jeff.Fellin@rflelect.com
973 334-3100, x 327
^ permalink raw reply
* [PATCH] add a raw dump command to xmon
From: Olaf Hering @ 2006-03-08 19:40 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Dump a stream of rawbytes with a new 'dr' command.
Produces less output and it is simpler to feed the output to scripts.
Also, dr has no dumpsize limits.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/xmon/xmon.c | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+)
Index: linux-2.6.16-rc5-olh/arch/powerpc/xmon/xmon.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/xmon/xmon.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/xmon/xmon.c
@@ -191,6 +191,7 @@ Commands:\n\
di dump instructions\n\
df dump float values\n\
dd dump double values\n\
+ dr dump stream of raw bytes\n\
e print exception information\n\
f flush cache\n\
la lookup symbol+offset of specified address\n\
@@ -1938,6 +1939,28 @@ bsesc(void)
return c;
}
+static void xmon_rawdump (unsigned long adrs, long ndump)
+{
+ long n, m, r, nr;
+ unsigned char temp[16];
+
+ for (n = ndump; n > 0;) {
+ r = n < 16? n: 16;
+ nr = mread(adrs, temp, r);
+ adrs += nr;
+ for (m = 0; m < r; ++m) {
+ if (m < nr)
+ printf("%.2x", temp[m]);
+ else
+ printf("%s", fault_chars[fault_type]);
+ }
+ n -= r;
+ if (nr < r)
+ break;
+ }
+ printf("\n");
+}
+
#define isxdigit(c) (('0' <= (c) && (c) <= '9') \
|| ('a' <= (c) && (c) <= 'f') \
|| ('A' <= (c) && (c) <= 'F'))
@@ -1960,6 +1983,13 @@ dump(void)
nidump = MAX_DUMP;
adrs += ppc_inst_dump(adrs, nidump, 1);
last_cmd = "di\n";
+ } else if (c == 'r') {
+ scanhex(&ndump);
+ if (ndump == 0)
+ ndump = 64;
+ xmon_rawdump(adrs, ndump);
+ adrs += ndump;
+ last_cmd = "dr\n";
} else {
scanhex(&ndump);
if (ndump == 0)
^ permalink raw reply
* RE: [PATCH] Fix MPC8548CDS rebooting procedure
From: Haruki Dai-r35557 @ 2006-03-08 19:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Wednesday, March 08, 2006 12:33 PM
> To: Haruki Dai-r35557
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Fix MPC8548CDS rebooting procedure
>=20
>=20
> On Mar 8, 2006, at 11:22 AM, Haruki Dai-r35557 wrote:
>=20
> > This patch fixes the MPC8548 CDS rebooting procedure.
> > Without this patche, issuing reboot from shell doesn't reboot the=20
> > machine.
> >
> > Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
>=20
> Dai, I'm avoid taking patches for 85xx that effect new=20
> functionality. If you want change this to work with=20
> arch/powerpc and make it a run time check for 8548.
Hi Kumar, what kind of new feature is affected by this bug fix? 8548
requires reboot to set the hardware reset bits. The mpc85xx_restart() is
not ported to arch/powerpc yet. Which portion of the arch/powerpc code
should be modified in order to restart the machine correctly?=20
And how do you want me to do run time check? Check SVR?=20
Dai=20
>=20
> - kumar
>=20
> > ---
> >
> > arch/ppc/syslib/ppc85xx_setup.c | 5 +++++
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > 8f095006923385c3546165b0e10d73d3e057c120
> > diff --git a/arch/ppc/syslib/ppc85xx_setup.c=20
> > b/arch/ppc/syslib/ppc85xx_setup.c index e4dda43..45b1b2b 100644
> > --- a/arch/ppc/syslib/ppc85xx_setup.c
> > +++ b/arch/ppc/syslib/ppc85xx_setup.c
> > @@ -115,6 +115,11 @@ mpc85xx_early_serial_map(void) void =20
> > mpc85xx_restart(char *cmd) {
> > +#ifdef CONFIG_MPC8548
> > + volatile unsigned int *rstcr;
> > + u32 *pMem =3D (u32*) ioremap((BOARD_CCSRBAR + 0xe00b0),0x100);
> > + *pMem =3D 0x2; /* Set HRESET_REQ flag */ #endif
> > local_irq_disable();
> > abort();
> > }
> > --
> > 1.2.4
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
>=20
^ permalink raw reply
* Re: [PATCH] Fix MPC8548CDS rebooting procedure
From: Kumar Gala @ 2006-03-08 18:33 UTC (permalink / raw)
To: Haruki Dai-r35557; +Cc: linuxppc-dev
In-Reply-To: <18AEF66AFDF06F4CAAA1D419D000FD332ECDA6@az33exm24.fsl.freescale.net>
On Mar 8, 2006, at 11:22 AM, Haruki Dai-r35557 wrote:
> This patch fixes the MPC8548 CDS rebooting procedure.
> Without this patche, issuing reboot from shell doesn't reboot the
> machine.
>
> Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
Dai, I'm avoid taking patches for 85xx that effect new
functionality. If you want change this to work with arch/powerpc and
make it a run time check for 8548.
- kumar
> ---
>
> arch/ppc/syslib/ppc85xx_setup.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> 8f095006923385c3546165b0e10d73d3e057c120
> diff --git a/arch/ppc/syslib/ppc85xx_setup.c
> b/arch/ppc/syslib/ppc85xx_setup.c
> index e4dda43..45b1b2b 100644
> --- a/arch/ppc/syslib/ppc85xx_setup.c
> +++ b/arch/ppc/syslib/ppc85xx_setup.c
> @@ -115,6 +115,11 @@ mpc85xx_early_serial_map(void)
> void
> mpc85xx_restart(char *cmd)
> {
> +#ifdef CONFIG_MPC8548
> + volatile unsigned int *rstcr;
> + u32 *pMem = (u32*) ioremap((BOARD_CCSRBAR + 0xe00b0),0x100);
> + *pMem = 0x2; /* Set HRESET_REQ flag */
> +#endif
> local_irq_disable();
> abort();
> }
> --
> 1.2.4
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] Fix MPC8548CDS rebooting procedure
From: Haruki Dai-r35557 @ 2006-03-08 17:22 UTC (permalink / raw)
To: linuxppc-dev
This patch fixes the MPC8548 CDS rebooting procedure.
Without this patche, issuing reboot from shell doesn't reboot the
machine.=20
Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
---
arch/ppc/syslib/ppc85xx_setup.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
8f095006923385c3546165b0e10d73d3e057c120
diff --git a/arch/ppc/syslib/ppc85xx_setup.c
b/arch/ppc/syslib/ppc85xx_setup.c
index e4dda43..45b1b2b 100644
--- a/arch/ppc/syslib/ppc85xx_setup.c
+++ b/arch/ppc/syslib/ppc85xx_setup.c
@@ -115,6 +115,11 @@ mpc85xx_early_serial_map(void)
void
mpc85xx_restart(char *cmd)
{
+#ifdef CONFIG_MPC8548
+ volatile unsigned int *rstcr;
+ u32 *pMem =3D (u32*) ioremap((BOARD_CCSRBAR + 0xe00b0),0x100);
+ *pMem =3D 0x2; /* Set HRESET_REQ flag */
+#endif
local_irq_disable();
abort();
}
--=20
1.2.4
^ permalink raw reply related
* RE: Stable Linux kernel 2.6 for MPC8XX
From: Fillod Stephane @ 2006-03-08 14:29 UTC (permalink / raw)
To: Laurent Lagrange, linuxppc-embedded
>I would want to use a linux kernel 2.6 on a custom MPC8xx board.
>Which stable kernel release must or can I use ?
http://www.denx.de/wiki/bin/view/Know/Linux24vs26
--=20
SF
^ permalink raw reply
* Stable Linux kernel 2.6 for MPC8XX
From: Laurent Lagrange @ 2006-03-08 14:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000201c63c44$14a9c1b0$5201a8c0@GEG2400>
Hello,
I would want to use a linux kernel 2.6 on a custom MPC8xx board.
Which stable kernel release must or can I use ?
Thanks
Laurent
^ 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